@derekwaynecarr @sttts @erictune не обнаружил проблемы для этого, но он уже находится в альфа-

@sttts не могли бы вы предоставить соответствующие ссылки на документы и PR? Думаю, вы ближе всего к этому коду.

@ pweil- @sttts - согласно нашему обсуждению, это функция, которую мы хотели бы спонсировать в Kubernetes 1.6 под @ kubernetes / sig-node

@ pweil- @derekwaynecarr, пожалуйста, подтвердите, что эта функция должна быть установлена ​​на

@idvoretskyi мы планируем перевести его на бета-версию 1.6.

@sttts спасибо.

Похоже, это все еще альфа:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/seccomp.md
https://github.com/kubernetes/kubernetes/blob/master/pkg/api/annotation_key_constants.go#L35

И я не смог найти никакой документации на kubernetes.io/docs.

@ pweil- есть обновления для 1.8? Эта функция все еще готовится к выпуску?

@idvoretskyi это не было приоритетом для 1.8. @ php-coder, можете ли вы добавить сюда карточку для нашего планирования PM? Нам нужно перестать позволять этому проваливаться и перевести его в бета-версию и GA.

@ pweil - если эта функция не планируется в 1.8 - пожалуйста, обновите веху, указав «next-milestone» или «1.9»

Я бы хотел, чтобы это добралось до бета-версии. Приоритеты (или требования) для этого включают:

1. Аннотации (Pod & PodSecurityPolicy) должны быть перемещены в поля контейнера SecurityContext (см. Https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#alpha-field- в существующей-api-версии)
2. Определитесь с форматом seccomp спецификации OCI и определите профиль Kubernetes по умолчанию (можем ли мы повторно использовать Docker?) Https://github.com/kubernetes/kubernetes/issues/39128
   а. Выясните, как профиль Kubernetes доставляется в среду выполнения контейнера через CRI (/ cc @yujuhong @ Random-Liu)
   б. docker/default все равно должно быть разрешено, если среда выполнения - докер (для обратной совместимости)
3. Профиль по умолчанию Kubernetes должен быть новым профилем по умолчанию. Для обратной совместимости это ДОЛЖНО быть необязательным поведением (т. Е. Управляемым флагом). https://github.com/kubernetes/kubernetes/issues/39845

Кто-нибудь заинтересован в продвижении этой работы к рубежу 1.9 (или 1.10)? @jessfraz @ kubernetes / sig-auth-feature-requests и @ kubernetes / sig-node-feature-requests Я смотрю на вас: подмигнуть:

Также актуально: https://github.com/kubernetes/community/pull/660 (нужно ли нам согласовывать решения в этом PR, прежде чем продолжить?)

/ cc @destijl

Если у кого-то есть время и он хочет этим заняться, мы будем рады, и я
поможет ответить на любые вопросы

22 сентября 2017 г., 20:54, "Тим Олклер (Сент-Клер)" [email protected]
написал:

/ cc @destijl https://github.com/destijl

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/features/issues/135#issuecomment-331593048 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ABYNbDldlrwbOP75Y2AKM-bUFLnwrq0eks5slFbcgaJpZM4KgBy_
.

хорошо, я обновлю предложение и начну с него завтра, если никто не будет;)

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Предотвратить автоматическое закрытие проблем с помощью комментария /lifecycle frozen .

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или @fejta .
/ жизненный цикл устаревший

Привет, @jessfraz, не уверен, что ты что-то понял - у меня нет полосы пропускания для его кодирования, но я рад помочь проверить ...

Неактивные выпуски гниют после 30 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle rotten .
Гнилые проблемы закрываются после дополнительных 30 дней бездействия.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл гнилой
/ remove-жизненный цикл устаревший

Гнилые проблемы закрываются после 30 дней бездействия.
Повторно откройте проблему с помощью /reopen .
Отметьте проблему как новую с помощью /remove-lifecycle rotten .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/близко

/ повторно открыть
/ жизненный цикл заморожен
/ remove-lifecycle гнилой

@ php-coder: вы не можете повторно открыть проблему / PR, если вы не являетесь ее автором или не назначены вам.

/ повторно открыть
/ жизненный цикл заморожен

В понедельник, 26 марта 2018 г., в 7:07, k8s-ci-robot [email protected]
написал:

@ php-coder https://github.com/php-coder : вы не можете повторно открыть проблему / PR
если вы не являетесь его автором или не назначены вам.

В ответ на это
https://github.com/kubernetes/features/issues/135#issuecomment-376129291
:

/ повторно открыть
/ жизненный цикл заморожен
/ remove-lifecycle гнилой

Инструкции по взаимодействию со мной с помощью PR-комментариев доступны здесь.
https://git.k8s.io/community/contributors/devel/pull-requests.md . Если
у вас есть вопросы или предложения, связанные с моим поведением, отправьте
проблема против kubernetes / test-infra
https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:
репозиторий.

-
Вы получаете это, потому что находитесь в упомянутой команде.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/features/issues/135#issuecomment-376129294 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ABG_p9EwKebniej_GySRKSvzrCMITOA1ks5tiMvrgaJpZM4KgBy_
.

@smarterclayton : вы не можете повторно открыть выпуск / PR, если вы не являетесь его автором или не назначены вам.

/ повторно открыть

@idvoretskyi : вы не можете повторно открыть выпуск / PR, если вы не являетесь его автором или не назначены вам.

Игорь 1, бот 0

@ pweil- @ php-кодер @jessfraz
Какие планы на это в 1.11?

Если да, не могли бы вы убедиться, что функция актуальна с соответствующими:

• Описание
• Веха
• Цессионарий (и)
• Ярлыки:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

@ wangzhen127 работает над этим, но не может быть назначен, так как он еще не участник.

https://github.com/kubernetes/kubernetes/pull/62662
https://github.com/kubernetes/kubernetes/pull/62671

Спасибо за обновление, Тим!
/ remove-lifecycle заморожен

@ pweil- @tallclair - Мы проверку электронной таблицы отслеживания функций 1.11 .
Не могли бы вы заполнить какие-либо неполные / пустые поля для позиции этой функции?

@ pweil- @tallclair - эта функция была удалена из этапа 1.11, так как не было обновлений относительно прогресса или документации.

Копия: @jberkus

@ pweil- @tallclair @ kubernetes / sig-auth-feature-requests @ kubernetes / sig-node-feature-requests -

Эта функция была удалена из предыдущего этапа, поэтому мы хотели бы проверить, есть ли какие-либо планы на этот счет в Kubernetes 1.12.

Если да, убедитесь, что эта проблема актуальна и содержит ВСЕ следующую информацию:

• Однострочное описание функции (может использоваться как примечание к выпуску):
• Основное контактное лицо (исполнитель):
• Ответственные SIG:
• Ссылка на проектное предложение (репозиторий сообщества):
• Ссылка на e2e и / или модульные тесты:
• Рецензент (ы) - (для LGTM) рекомендуют иметь 2+ рецензентов (по крайней мере, одного из файла OWNERS кодовой области), согласившихся на рецензирование. Рецензенты из нескольких компаний предпочли:
• Утверждающий (вероятно, из SIG / области, к которой принадлежит объект):
• Функциональная цель (какая цель соответствует какой вехе):
  
  
  
  • Цель альфа-выпуска (xy)
  
  
  • Цель выпуска бета-версии (xy)
  
  
  • Стабильная цель выпуска (xy)
  
  

Обратите внимание, что замораживание функций наступает 31 июля, после чего любые неполные проблемы с функциями потребуют принятия запроса на

Кроме того, обратите внимание на следующие сроки:

• Крайний срок подачи документов (PR с открытыми заполнителями): 21 августа.
• Заморозка тестового набора: 28 августа

Убедитесь, что все PR для функций также содержат соответствующие примечания к выпуску.

Удачной доставки!

/ cc @justaugustus @ kacole2 @robertsandoval @ rajendar38

В версии 1.12 изменений не запланировано.

Спасибо за обновление, @tallclair!

Кто-нибудь заинтересован в продвижении этой работы к рубежу 1.9 (или 1.10)? @jessfraz @ kubernetes / sig-auth-feature-requests и @ kubernetes / sig-node-feature-requests Я смотрю на вас подмигнуть

@tallclair Я могу попробовать забрать это сейчас, если все еще желает

@stlaz :
@ kubernetes / sig-auth-feature-requests, @ kubernetes / sig-node-feature-requests

@stlaz , эта функция по-прежнему желательна. Я потратил некоторое время на добавление профилей seccomp к аддонам в качестве первых шагов # 39845 . Но у меня нет времени, чтобы продвигать эту функцию. Было бы неплохо, если бы вам понравилось поработать над этим. Любая помощь приветствуется! :)

@ wangzhen127 Спасибо, я пытался возникли проблемы, связанные с этой функцией. Казалось бы, комментарий https://github.com/kubernetes/features/issues/135#issuecomment -331592961 по-прежнему актуален и резюмирует именно ту работу, которую необходимо выполнить сейчас.

Я также заметил, что вы пытались добавить для этого FeatureGate, но закрыли PR, почему?

PS: Извините за поздний ответ, я ненадолго отлучился.

Казалось бы, комментарий № 135 (комментарий) по-прежнему актуален и резюмирует именно ту работу, которую необходимо выполнить сейчас.

Это верно. Еще одно, что я хотел бы добавить, это наличие режима «жалоба». Таким образом, пользователи могут выбрать получение предупреждений (в журналах) об использовании запрещенных системных вызовов, а не kill. Ведение журнала действий seccomp доступно в ядре Linux 4.14+ ( seccomp doc ). Возможно, все еще используются более старые версии ядра. Так что нам нужно с этим справиться. Это также нужно будет добавить в спецификацию OCI.

Я также заметил, что вы пытались добавить для этого FeatureGate, но закрыли PR, почему?

Целью этой функции было изменение профиля по умолчанию seccomp с неограниченного на «время выполнения / по умолчанию». У меня было много опасений по поводу обратной совместимости, так что это казалось маловероятным. В настоящее время у нас нет плана по изменению настроек безопасности по умолчанию в целом, потому что они нарушаются. Лучшим подходом, который я сейчас считаю, является перевод seccomp до стабильного состояния, и это по-прежнему должна быть функцией согласия, а не отказа.

Ведение журнала действий seccomp доступно в ядре Linux 4.14+ ( seccomp doc ).

Я предполагаю, что, поскольку мы определим специфичный для Kubernetes формат seccomp по умолчанию как часть второго шага, у нас также может быть такой, который будет регистрироваться вместо этого. Достаточно ли для этого стоимости? Можно ли использовать его для перехода от «неограниченного» к «кубу / по умолчанию», когда последний терпит неудачу? Хотели бы они, чтобы он переключился обратно?
Существуют дистрибутивы LTS, использующие ядра 4.13- Linux (Debian - 8,9; RHEL - 6, 7; Ubuntu LTS - 14.04, 16.04), поэтому о совместимости с ядрами определенно следует помнить.

У меня было много опасений по поводу обратной совместимости, так что это казалось маловероятным.

Средам выполнения контейнеров тоже приходилось претерпевать это изменение в прошлом, когда они впервые включали seccomp. Прямо сейчас, по крайней мере, докер поставляется с поведением по умолчанию, которое менее разрешительно, чем «неограниченное», которое могло кого-то сломать. Я не думаю, что мы делаем что-то неправильно, если просто следим за поведением базовых компонентов (которые также дают возможность отключить это поведение).

Достаточно ли для этого стоимости?

Это можно обсудить. Моя первоначальная мысль заключалась в том, чтобы изменить значение по умолчанию с неограниченного на ведение журнала. Таким образом, у нас нет проблем с обратной совместимостью. И если мы каким-то образом сможем собрать данные и показать, что в X% случаев мы ничего не увидим в журнале, то есть профиль по умолчанию ничего не сломает. Тогда мы можем предложить изменить логирование на kill. Сбор части данных сложен и может потребовать много работы. Даже если мы на самом деле не пойдем по этому пути, я думаю, что наличие профиля регистрации принесет пользу людям, когда они хотят попробовать seccomp out, но еще не уверены.

Средам выполнения контейнеров тоже приходилось претерпевать это изменение в прошлом, когда они впервые включали seccomp. Прямо сейчас, по крайней мере, докер поставляется с поведением по умолчанию, которое менее разрешительно, чем «неограниченное», которое могло кого-то сломать. Я не думаю, что мы делаем что-то неправильно, если просто следим за поведением базовых компонентов (которые также дают возможность отключить это поведение).

Когда докер изменил значение по умолчанию, кубернеты явно сбрасывают такое значение на неограниченное. Раньше я обращался к разработчикам sig-архитектуры в автономном режиме, и они очень обеспокоены проблемой обратной совместимости.

И если мы каким-то образом сможем собрать данные и показать, что в X% случаев мы ничего не увидим в журнале, то есть профиль по умолчанию ничего не сломает.

Мне нравится эта идея. Самая сложная часть, конечно, получить данные, я понятия не имею, как это сделать. Кроме того, нам нужно сначала предложить это изменение в спецификации OCI, а затем, вероятно, реализовать его хотя бы для одной среды выполнения контейнера, верно? Будет ли это нормально в бета-версии жизненного цикла?

Когда докер изменил значение по умолчанию, кубернеты явно сбрасывают такое значение на неограниченное. Раньше я обращался к разработчикам sig-архитектуры в автономном режиме, и они очень обеспокоены проблемой обратной совместимости.

Понятно. Возможно, мы действительно могли бы просто использовать «неограниченный» профиль в качестве профиля по умолчанию (возможно, позже заменив его чем-то вроде kube/logging ). Похоже, что тогда это может скорее контролироваться PSP с помощью правила запрета, где мы начинаем с предположения, что все разрешено по умолчанию, и мы только сокращаем привилегии в дальнейшем. Наличие флагового контроля над этим может быть полезно в тех случаях, когда PSP отключены, так что нужно также войти, но одновременное использование этих двух механизмов, вероятно, было бы немного беспорядочным.

Я предполагаю, что это немного другое направление, чем первоначально предполагалось - оно идет вразрез с работой, проделанной в https://github.com/kubernetes/kubernetes/issues/39845 , но если мы согласны с вышеизложенным, мы должны подумать о профилях seccomp мы в конечном итоге отправим. Пока я вижу runtime/default , kube/default , kube/logging , а также возможность установить для профиля значение unconfined . Остальное, конечно же, - это возможность иметь профили localhost/.* , что уже предусмотрено текущей реализацией.

Будет ли это нормально в бета-версии жизненного цикла?

Звучит неплохо. Хотя я думаю, что это помогает рано начать работу над предложением спецификации OCI.

Выбирайте "без ограничений", поскольку значение по умолчанию для меня пока звучит неплохо. Для kubernetes / kubernetes # 39845 я добавил аннотации к аддонам. И я не думаю, что мы можем пойти дальше.

Пока что я вижу runtime / default, kube / default, kube / logging, а также возможность установить профиль как неограниченный. Остальное, конечно же, - это возможность иметь профили localhost /.*, которые уже предусмотрены текущей реализацией.

Работает для меня. Для kube/default мы можем просто начать с docker/default .

Ведение журнала действий seccomp доступно в ядре Linux 4.14+ (seccomp doc).

Насколько я понимаю, это регистрирует действие с PID - не обязательно информацию, связанную с контейнером. Таким образом, либо auditd, либо какой-либо другой демон на хосте должен будет выполнить поиск / сопоставление, чтобы журнал был действительно полезным ...

И если мы каким-то образом сможем собрать данные и показать, что в X% случаев мы ничего не увидим в журнале, то есть профиль по умолчанию ничего не сломает. Тогда мы можем предложить изменить логирование на kill. Сбор части данных сложен и может потребовать много работы.

Разве @jessfraz еще не сделал это при запуске профиля докера по умолчанию для докера? Если это не достаточно сильный сигнал, будет очень сложно собрать более сильный ...

@tallclair , ты прав, я как бы https://github.com/kubernetes/community/pull/660#issuecomment -303860107. Я полагаю, мы могли бы быть в безопасности, имея "убийственный" дефолт в конце концов.

Привет
Это улучшение отслеживалось и раньше, поэтому мы хотели бы проверить и посмотреть, есть ли какие-либо планы по переходу на этапы в Kubernetes 1.13. Этот выпуск нацелен на то, чтобы быть более «стабильным» и иметь агрессивные сроки. Пожалуйста, включайте это улучшение только в том случае, если есть высокий уровень уверенности, что оно будет соответствовать следующим срокам:

• Документы (PR с открытыми заполнителями): 8/11
• Кодекс Slush: 11/9
• Начало замораживания кода: 15/11
• Документы заполнены и проверены: 27 ноября

Уделите время, чтобы обновить вехи в исходном сообщении для будущего отслеживания, и ping лист отслеживания улучшений 1.13.

Спасибо!

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

Проблемы улучшения, открытые в kubernetes/enhancements никогда не должны помечаться как замороженные.
Владельцы улучшений могут гарантировать, что улучшения останутся актуальными, постоянно обновляя свои состояния на протяжении всех циклов выпуска.

/ remove-lifecycle заморожен

Неактивные выпуски гниют после 30 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle rotten .
Гнилые проблемы закрываются после дополнительных 30 дней бездействия.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл гнилой

/ remove-lifecycle гнилой

Привет @stlaz @ pweil-, я

Как только начнется кодирование, перечислите все соответствующие PR в этом выпуске, чтобы их можно было правильно отслеживать.

в 1.15 изменений не запланировано

Привет, @tallclair @ pweil- @stlaz , я ведущий / Shadow по улучшению 1.16. Будет ли эта функция переходить на стадии альфа / бета / стабильная версия 1.16? Пожалуйста, дайте мне знать, чтобы его можно было добавить в таблицу отслеживания 1.16 . Если нет, я уберу его с вехи и изменю отслеживаемую метку.

Как только кодирование начнется или если оно уже было, перечислите все соответствующие PR в этом выпуске, чтобы их можно было отслеживать должным образом.

Напоминаем, что для каждого улучшения требуется KEP в реализуемом состоянии с критериями градации, объясняющими требования к каждой альфа / бета / стабильной стадии.

Даты вехи - замораживание улучшения 7/30 и замораживание кода 8/29.

Спасибо.

У меня есть первые планы по внедрению этого в GA, но, возможно, будет сложно добраться до него в 1.16. Я постараюсь получить предложение путем замораживания улучшений.

Здравствуйте, @tallclair @ pweil-, 1.17 Enhancement Shadow здесь! 🙂

Я хотел связаться с *, будет ли это улучшение переходить на альфа / бета / стабильная версия в 1.17?
Пожалуйста, дайте мне знать, чтобы это улучшение можно было добавить в лист отслеживания 1.17 .

Спасибо!

🔔Дружелюбное напоминание

• Текущий график выпуска:
  
  
  
  • Понедельник, 23 сентября - начинается цикл выпуска.
  
  
  • Вторник, 15 октября, EOD (тихоокеанское стандартное время) - замораживание улучшений
  
  
  • Четверг, 14 ноября, EOD (тихоокеанское стандартное время) - Code Freeze
  
  
  • Вторник, 19 ноября - документы должны быть заполнены и проверены.
  
  
  • 9 декабря, понедельник - релиз Kubernetes 1.17.0
  
  

• Предложение по улучшению Kubernetes (KEP) должно соответствовать следующим критериям, прежде чем Enhancement Freeze будет принято в выпуске.

  • PR объединен в
  • В состоянии implementable
  • Включите план тестирования и критерии окончания

• Все соответствующие PR к / к должны быть перечислены в этом выпуске.

Да, я планирую перейти на стабильную версию 1.17 - KEP здесь: https://github.com/kubernetes/enhancements/pull/1148

Привет, @tallclair , я добавлю это улучшение в лист отслеживания, чтобы его можно было отслеживать 👍

Пожалуйста, просмотрите сообщение выше для дружеских напоминаний и обратите внимание, что KEP находится в предварительном состоянии. KEP должен быть в состоянии реализации, чтобы быть добавленным в выпуск 1.17.

/ milestone v1.17
/ сценическая конюшня

Привет, @tallclair. Не могли бы вы разместить ссылки на тесты в testgrid и отслеживать все тесты, добавленные для этого улучшения?

Спасибо!

Сделаю. Уже есть куча тестов seccomp, но я не могу найти их ни на одной из вкладок панели инструментов (есть ли способ поискать по всем тестовым сеткам для конкретного теста?)
https://github.com/kubernetes/kubernetes/blob/0956acbed17fb71e76e3fbde89f2da9f8ec8b603/test/e2e/node/security_context.go#L147 -L177

@tallclair нет хорошего способа поиска по всей тестовой сетке = /

Мое лучшее предположение (по крайней мере, для тех 4, на которые вы ссылались) состоит в том, что они фактически не включены. 😬

Похоже, они должны быть частью панели инструментов node-kubelet-features , но в конфигурации задания для ci-kubernetes-node-kubelet-features есть это для test_args :

--test_args=--nodes=8 --focus="\[NodeFeature:.+\]" --skip="\[Flaky\]|\[Serial\]"

Сами тесты гинкго помечены тегом [Feature:Seccomp] и флаг фокуса не совпадет.

Я думаю, что мы должны просто удалить тег функции, как только он перейдет в GA. Я думаю, что seccomp является стандартным для Linux, поэтому тега [LinuxOnly] должно быть достаточно.

Для решения общей проблемы с невыполнением тестов я подал https://github.com/kubernetes/test-infra/issues/14647.

Привет, @tallclair , осталось всего 5 дней до замораживания улучшений (вторник, 15 октября, EOD PST) . Еще одно дружеское напоминание о том, что для того, чтобы завершить это в выпуске 1.17, KEP должен быть объединен и должен быть в состоянии реализации. Похоже, KEP все еще открыт и находится в предварительном состоянии.

Привет, @tallclair , к сожалению, крайний срок для замораживания улучшений 1.17

Обратите внимание, что вы можете отправить исключение улучшения, если вам нужно получить это в версии 1.17.

/ этап очищен

Да, не попал. Надеясь попасть в
/ milestone v1.18

Это звучит неплохо! Я отмечу это как отложенное до версии 1.18 в листе отслеживания улучшений .

Привет 👋, есть ли что-нибудь, что мы можем сделать, чтобы продвинуть это вперед. Я был бы рад внести свой вклад здесь, а также в вопросе AppArmor.

Привет @tallclair

1.18 Прибытие команды разработчиков! Планируете ли вы перейти в стабильную версию 1.18? Похоже, KEP все еще открыт.

График выпуска следующий:

Повышение заморозки: 28 января
Замораживание кода: 5 марта
Документы готовы: 16 марта
Релиз v1.18: 24 марта

Напоминаем, что KEP необходимо объединить со статусом implementable .

Спасибо!

@saschagrunert спасибо за предложение! Мне нужно сделать еще один проход в KEP, чтобы продолжить обзор API, который я провел с @liggitt. Как только KEP будет одобрен, я буду рад вашей помощи в его реализации.

Я думаю, что сейчас самый большой открытый вопрос по KEP - как обрабатывать тип профиля localhost. Поскольку мы хотим отказаться от этой функции (в идеале в пользу чего-то вроде https://github.com/kubernetes/enhancements/pull/1269, / cc @pjbgf ), я бы не хотел помещать для нее поле в API. .

Привет, @tallclair , есть какие-нибудь обновления о том, войдет ли это в версию 1.18 или нет? В настоящее время он отмечен как этап, но вы не подтвердили, следует ли нам отслеживать это или нет.

Спасибо!

v1.18 кажется маловероятным для этого. Я думаю, мы можем наткнуться на
/ веха v1.19

Отлично, спасибо за обновление @tallclair :)

Привет, @tallclair - Улучшения 1.19 Ведите сюда, планируете ли вы stable этом выпуске?

Нет планов по выпуску версии 1.19. У меня есть открытый KEP, но я не буду над ним работать в этом квартале. @pjbgf может забрать его в v1.20

@tallclair - Спасибо за обновления. : Little_smiling_face:

/ milestone v1.20

Планы по этому вопросу немного изменились - как было согласовано на вчерашней встрече sig-node. Теперь это запланировано на:

/ веха v1.19

@pjbgf : Вы должны быть членом команды разработчиков kubernetes / milestone-mainers на GitHub, чтобы установить веху. Если вы считаете, что сможете выполнить команду / milestone, обратитесь к своему и попросите их предложить вас в качестве дополнительного делегата для выполнения этой обязанности.

@palnabarun Не могли бы вы

/ назначить pjbgf

/ веха v1.19

Спасибо @pjbgf @tallclair за обновление. Я обновил лист отслеживания в соответствии с вашими планами.

Не могли бы вы сообщить мне, на какой выпускной этап вы нацеливаетесь, и ссылку на KEP?

Спасибо! Оцените все старания. : Little_smiling_face:

Текущий график выпуска:

• Понедельник, 13 апреля: неделя 1 - начинается цикл выпуска.
• Вторник, 19 мая: 6-я неделя - Заморозка улучшений
• Четверг, 25 июня: 11-я неделя - замораживание кода
• Четверг, 9 июля: неделя 14 - Документы необходимо заполнить и проверить.
• Вторник, 4 августа: 17-я неделя - релиз Kubernetes v1.19.0

Ориентация на Google Analytics

KEP: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md
У KEP все еще есть нерешенные разделы с последующим PR: https://github.com/kubernetes/enhancements/pull/1747

Привет, @tallclair , спасибо за обновление. : +1:

Я соответственно обновил лист отслеживания .

PS: Я обновил описание проблемы со ссылками на KEP и PR последнего обновления KEP.

спасибо @palnabarun за обновление. : +1:

Привет, @tallclair 👋 1.19 docs shadow здесь! Требует ли эта работа по усовершенствованию, запланированная для версии 1.19, новой или измененной документации?

Напоминаем, что если требуются новые / модифицирующие документы, к пятнице, 12 июня, потребуется PR-заполнитель для k / website (ветка dev-1.19 ).

@annajung , это для хедз-ап. Да, в документацию seccomp будут внесены некоторые изменения.

Добавление @hasheddan, который это поднимает (https://github.com/kubernetes/kubernetes/issues/58211).

Отлично, спасибо за обновление! Я внесу соответствующие изменения в лист отслеживания.
Пожалуйста, дайте нам знать, как только будет сделан PR-адрес k / website. Спасибо!

@pjbgf - Не могли бы вы дать ссылку на все PR реализации здесь - k / k или иначе? : Little_smiling_face:

Текущий график выпуска:

• ~ Понедельник, 13 апреля: неделя 1 - начинается цикл выпуска ~
• ~ Вторник, 19 мая: 6-я неделя - Заморозка улучшений ~
• Четверг, 25 июня: 11-я неделя - замораживание кода
• Четверг, 9 июля: неделя 14 - Документы необходимо заполнить и проверить.
• Вторник, 4 августа: 17-я неделя - релиз Kubernetes v1.19.0

@palnabarun вот текущие:
https://github.com/kubernetes/kubernetes/pull/91381
https://github.com/kubernetes/kubernetes/pull/91408
https://github.com/kubernetes/kubernetes/pull/91182
https://github.com/kubernetes/kubernetes/pull/91442

Я также создал общий выпуск, в который вошли все они.

Привет, @pjbgf @hasheddan. Просто дружеское напоминание о том, что к пятнице, 12 июня, должен быть проведен PR-адрес k / website. Пожалуйста, дайте мне знать, как только вы сделаете PR, спасибо!

@annajung, спасибо за напоминание! Скоро откроется: +1:

Привет @pjbgf - Спасибо за создание проблемы с зонтиком. : +1:

Мы отслеживаем то же самое. : Little_smiling_face:

Привет, @pjbgf - просто хотел узнать, как идет работа над улучшением.

График выпуска был недавно пересмотрен, более подробную информацию можно найти здесь .

Пожалуйста, дай мне знать, если возникнут какие-либо вопросы. : Little_smiling_face:

Пересмотренный график выпуска:

• Четверг, 9 июля: 13-я неделя - замораживание кода
• Четверг, 16 июля: неделя 14 - документы должны быть заполнены и проверены.
• Вторник, 25 августа: 20-я неделя - релиз Kubernetes v1.19.0

Спасибо за обновление @palnabarun. Код в основном готов, но теперь мы ждем последующей проверки. В целом мы все еще хорошо выглядим. : +1:

Привет, @pjbgf @hasheddan , дружеское напоминание о приближении следующего дедлайна.
Не забудьте заполнить PR своего документа-заполнителя и подготовить его к рассмотрению до понедельника, 6 июля.

Привет, @pjbgf @hasheddan : wave :, я вижу, что в https://github.com/kubernetes/kubernetes/issues/91286 все еще есть 3 незавершенных элемента действий для изменений, связанных с реализацией, и 1 ожидающий элемент действия для документации. Как вы думаете, они справятся с замораживанием кода в четверг, 9 июля?

Спасибо. : Little_smiling_face:

Замораживание кода начнется в четверг, 9 июля, EOD (тихоокеанское стандартное время).

@palnabarun docs PR в основном готов, просто добавлено специальное руководство для seccomp. У вас уже есть LGTM от @saschagrunert о текущих изменениях. Спасибо, что держите нас в курсе :)

Привет, @hasheddan , спасибо за обновление выше. Просто напоминание о том, чтобы подготовить PR-документ для проверки (удалить WIP / перебазировать / все готово) с помощью EOD. Спасибо!

@annajung подойдет! Спасибо!

@hasheddan - Спасибо за обновление. :улыбка:

@pjbgf - я видел, что в https://github.com/kubernetes/kubernetes/issues/91286 два основных элемента действий еще не объединены и также не находятся в пуле слияния. Как вы думаете, они войдут до замораживания кода?

Спасибо. : Little_smiling_face:

@palnabarun, мы пытаемся сделать это до замораживания кода, в конце концов, это уже был lgtm. У нас возникли проблемы с некоторыми нестабильными тестами в банкомате. 😅

Спасибо за внимание.

Для наглядности мы ждем слияния двух участников:
https://github.com/kubernetes/kubernetes/pull/91408 и https://github.com/kubernetes/kubernetes/pull/92856

Последний (https://github.com/kubernetes/kubernetes/pull/92856), похоже, не проходит проверку. Согласно https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700, это потребует перебазирования / повторного обновления / повторного просмотра, прежде чем оно сможет объединиться.

@kikisdeliveryservice спасибо за разъяснения. Мы ждем, когда нестабильные тесты на https://github.com/kubernetes/kubernetes/pull/91408 перестанут давать сбои, как только они будут объединены, мы сможем перебазировать второй PR, который зависит от него.

Привет, @pjbgf : wave :, Сейчас мы находимся в режиме замораживания кода.

Поскольку https://github.com/kubernetes/kubernetes/pull/91408 находится в пуле слияния, а https://github.com/kubernetes/kubernetes/pull/92856 требует перебазирования поверх https://github.com/ kubernetes / kubernetes / pull / 91408 в соответствии с https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700, мы считаем, что лучшим действием здесь будет подать запрос на

Удаление улучшения из вехи на время.

Спасибо!

Лучший,
Команда по улучшению выпуска Kubernetes v1.19

/ этап очищен

Поскольку kubernetes / kubernetes # 91408 находится в пуле слияния, а kubernetes / kubernetes # 92856 требует перебазирования над kubernetes / kubernetes # 91408 в соответствии с kubernetes / kubernetes # 92856 (комментарий), мы считаем, что лучшим действием здесь было бы подать исключение. запрос на получение дополнительного времени для завершения второго PR после очистки пула слияния.

Перебазирование утвержденного PR в очереди слияния не требует запроса исключения. PR был заполнен и утвержден за день до крайнего срока.

Привет, @liggitt : wave :, спасибо за ваш вклад. : +1:

Мы собираемся снова включить усовершенствование в цикл. Все наши опасения касались перебазирования. Поскольку это отсортировано, это хорошо. : Little_smiling_face:

/ веха v1.19

@pjbgf @saschagrunert @hasheddan - спасибо за ваш вклад. : 100:

Спасибо @palnabarun за подробное отслеживание улучшения. Мы ценим это! 🙏

@saschagrunert последний PR kubernetes / kubernetes # 92856 наконец слились. Поздравляю! Я обновлю лист отслеживания, чтобы отразить это.

@tallclair @pjbgf как вы думаете, мы можем закрыть эту проблему сейчас, поскольку seccomp - это GA?

@saschagrunert Обычно мы ждем выхода релиза, затем implemented и закрываем проблему улучшения.

Не стесняйтесь вносить изменения, отмечая https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md как implemented . : Little_smiling_face:

@saschagrunert Обычно мы ждем выхода релиза, затем implemented и закрываем проблему улучшения.

Не стесняйтесь вносить изменения, отмечая https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md как implemented .

Спасибо за разъяснения, открыл PR в https://github.com/kubernetes/enhancements/pull/1932

KEP был обновлен до реализованного (PR наконец-то слился!)

Не стесняйтесь закрыть этот вопрос @saschagrunert

Спасибо всем за вашу работу !!

/ этап очищен

/близко
Готово.

@saschagrunert Я не могу вспомнить, обсуждали ли мы это раньше, но есть ли какой-либо план, чтобы в конечном итоге очистить аннотации (т.е. удалить поддержку)? Основная мотивация для этого заключается в том, что сторонним инструментам (например, привратнику, krail) не нужно знать, чтобы проверять как аннотацию, так и поле

@saschagrunert Я не могу вспомнить, обсуждали ли мы это раньше, но есть ли какой-либо план, чтобы в конечном итоге очистить аннотации (т.е. удалить поддержку)? Основная мотивация для этого заключается в том, что сторонним инструментам (например, привратнику, krail) не нужно знать, чтобы проверять как аннотацию, так и поле

Да, это планируется в версии 1.23. Это связано с механизмом предупреждения (еще не реализованным), который можно сделать после того, как появятся необходимые служебные функции (см. Https://github.com/kubernetes/kubernetes/issues/94626).

От КЭП:

Чтобы повысить осведомленность об использовании аннотаций (в случае старой автоматизации), будет использоваться механизм предупреждения, чтобы указать, что поддержка будет прекращена в версии 1.23. Рассматриваемые механизмы - это аннотации аудита, аннотации к объекту, событиям или предупреждению, как описано в KEP # 1693.

…

Поскольку мы поддерживаем до двух второстепенных выпусков смещения версий между главным и узлом, аннотации должны продолжать поддерживаться и заполняться по крайней мере для 2 версий, прошедших первоначальную реализацию. Однако мы можем решить расширить опору, чтобы уменьшить поломку. Если эта функция реализована в v1.19, я предлагаю v1.23 в качестве цели для удаления старого поведения.

Вы предпочитаете повторно открывать эту проблему, пока эти биты также не будут реализованы?

Да, давайте оставим это открытым, пока функция не будет полностью завершена. Имеется ли проблема с ак / к для описанной вами работы?

Да, давайте оставим это открытым, пока функция не будет полностью завершена. Имеется ли проблема с ак / к для описанной вами работы?

Теперь у нас есть такой: https://github.com/kubernetes/kubernetes/issues/95171 :)