@enisoc @ dchen1107 @fejta @thockin @ kow3ns @derekwaynecarr , открыл эту проблему отслеживания, чтобы мы могли обсудить.

/назначать

@derekwaynecarr Я провел некоторое исследование изменений kubelet, необходимых для встречи sig-node на следующей неделе, я _ верю_, что изменения необходимы только в пакете kuberuntime , а именно kuberuntime_manager.go in и kuberuntime_container.go .

В kuberuntime_manager.go вы можете изменить computePodActions чтобы реализовать срабатывание выключения (убивать коляски, когда все не боковые машины окончательно покинули его), и сначала запустить коляски.

В kuberuntime_container.go вы можете изменить killContainersWithSyncResult для завершения боковых вагонов последним и отправки перехватчиков preStop (бит перехватов preStop был немного спорным, не было решено, следует ли это делать или нет. @ У Токина было хорошее комментарий ).

Дайте мне знать, если вы хотите, чтобы я продолжил расследование.

@ kow3ns Обсуждение имеет для меня больше смысла, если, возможно, мы сможем определить полное описание последовательности контейнеров в спецификации Pod (sig-app) и как обрабатывать последовательность в kubelet для запуска, перезапуска и каскадного рассмотрения (sig-node). Давайте поговорим о встрече sig-node 5 февраля, чтобы дать больше информации.

cc @ Joseph-Irving

В предложении говорится, что сайдкары запускаются только после запуска контейнеров инициализации. Но что, если вариант использования требует, чтобы sidecar запускался во время / до запуска контейнеров инициализации. Например, если вы хотите направить трафик модуля через прокси-сервер, работающий как sidecar (как в Istio), вы, вероятно, захотите, чтобы этот прокси был на месте, пока запускаются контейнеры инициализации, если сам контейнер инициализации выполняет сетевые вызовы.

@luksa Я думаю, что в какой-то момент есть возможность рассмотреть возможность запуска дополнительных машин на этапе инициализации, но в настоящее время предложение не распространяется на этот вариант использования. В настоящее время нет возможности иметь одновременные контейнеры, работающие на этапе инициализации, поэтому это потенциально может быть гораздо более масштабным / беспорядочным изменением, чем то, что предлагается здесь.

Обновление этого KEP:
Я поговорил об этом с @derekwaynecarr и @ dchen1107 из sig-node, и они не выразили никаких серьезных опасений по поводу этого предложения. Я подниму PR для KEP, добавив некоторые начальные замечания по деталям реализации и прояснив несколько моментов, которые возникли в ходе обсуждения.

Нам все еще нужно согласовать API, похоже, есть консенсус, что простой способ пометить контейнеры как боковые автомобили предпочтительнее более подробных флагов упорядочения. Однако наличие bool в некоторой степени ограничивает, поэтому, возможно, что-то более похожее на containerLifecycle: Sidecar было бы предпочтительнее, чтобы у нас была возможность расширения в будущем.

@ Joseph-Irving На самом деле, ни логическое значение, ни containerLifecycle: Sidecar не подходят для надлежащей расширяемости в будущем. Вместо этого containerLifecycle должен быть объектом, как и deployment.spec.strategy , с type: Sidecar . Это позволит нам затем ввести дополнительные поля. Для решения «коляска на весь срок службы контейнера» это можно выразить следующим образом:

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: CompletePodLifetime

в отличие от

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: AfterInit

Прошу простить меня за плохое название - надеюсь, названия передают идею.

Но есть одна проблема с подходом, в котором мы вводим containerLifecycle в pod.spec.containers . А именно, неправильно иметь sidecars, которые работают параллельно с контейнерами инициализации, указанными в pod.spec.containers . Поэтому, если вы действительно хотите иметь возможность в конечном итоге распространить это на контейнеры инициализации, вам следует найти альтернативное решение - такое, которое позволит вам отмечать контейнеры как боковые на более высоком уровне, то есть не ниже pod.spec.containers или pod.spec.initContainers , но что-то вроде pod.spec.sidecarContainers , которое, я думаю, вы уже обсуждали, но отклонили. Проблема с контейнерами инициализации определенно требует решения в этом направлении.

@luksa Вы также можете решить проблему инициализации, просто позволив контейнеру инициализации быть помеченным как вспомогательный элемент и запустить его вместе с контейнерами инициализации. Насколько я понимаю, проблема в том, что контейнеры инициализации иногда нуждаются в дополнительных компонентах, что отличается от необходимости в контейнере, который работает в течение всего времени существования модуля.

Проблема с pod.spec.sidecarContainers заключается в том, что это гораздо более сложное изменение, необходимо обновить инструменты, а kubelet потребует значительных изменений для поддержки другого набора контейнеров. Текущее предложение намного скромнее, оно основано только на том, что уже есть.

@ Джозеф-Ирвинг. Мы могли бы работать с этим, да. Не идеально, чтобы sidecar отключался после запуска контейнеров инициализации, а затем снова запускался тот же sidecar, но это лучше, чем отсутствие этой опции. Более серьезная проблема заключается в том, что старые Kubelets не могли должным образом обрабатывать контейнеры init-sidecar (как в случае с контейнерами main-sidecar).

Я просто хочу, чтобы вы держали в уме init-sidecars, когда дорабатываете предложение. По сути, вы вводите понятие «sidecar» в k8s (раньше у нас в основном был только набор контейнеров, которые были все равны). Теперь вы представляете настоящие коляски, так что ИМХО, вам действительно следует обдумать это тщательно и не отказываться от очень важного варианта использования коляски.

Буду рад помочь с этим. Без него Istio не может предоставить свои функции для инициализации контейнеров (фактически, в должным образом защищенном кластере Kubernetes, на котором запущен Istio, init-контейнеры полностью теряют способность взаимодействовать с _ любой_ службой).

Что касается обсуждения реализации в https://github.com/kubernetes/enhancements/pull/841 , я открыл WIP PR, содержащий базовый PoC для этого предложения https://github.com/kubernetes/kubernetes/pull / 75099. Это всего лишь первый набросок и явно не идеальный, но базовая функциональность работает и дает вам представление о количестве необходимых изменений.

cc @enisoc

Я собрал короткое видео, показывающее, как сейчас ведет себя PoC https://youtu.be/4hC8t6_8bTs. Лучше увидеть это в действии, чем читать об этом.
Отказ от ответственности: я не профессиональный ютубер.

Я открыл два новых PR:

• https://github.com/kubernetes/enhancements/pull/918 касается критериев окончания, перекоса версии, обновления / понижения
• https://github.com/kubernetes/enhancements/pull/919 - это принять решение о реализации API.

Будем очень признательны за любые мысли или предложения.

@ Joseph-Irving Извините, если я комментирую поздно в процессе проектирования, но у меня есть потенциальный вариант использования контейнеров с коляской, которые могут не поддерживаться в текущем предложении по дизайну. Я просто хотел вынести это на рассмотрение. Суть в том, что у меня есть сценарий, в котором при завершении модуля один дополнительный элемент должен завершаться перед основным контейнером, а другой дополнительный элемент должен завершаться после основного контейнера.

Конкретным примером может быть модуль с контейнером приложения Django, сопроводительный элемент consul для регистрации службы и сопроводительный элемент pgbouncer для управления подключениями к базе данных. Когда модуль завершается, я бы хотел, чтобы сначала был остановлен сопутствующий элемент consul (чтобы больше не перенаправлялся трафик на модуль), затем контейнер приложения (в идеале после короткого периода отсрочки), а затем сопроводительный элемент pgbouncer. Текущее предложение отлично подходит для обработки зависимости контейнера app <-> pgbouncer, но не кажется достаточно выразительным, чтобы уловить случай, когда я хотел бы разрушить коляску перед основным контейнером.

@currankaushik , в описанном вами сценарии вы потенциально можете использовать pre-stop ловушку, чтобы сообщить контейнеру consul подготовиться к завершению работы и прекратить маршрутизацию запросов к вам (при условии, что он может поддерживать что-то подобное). преостановочные крючки будут отправлены в боковые вагоны перед тем, как начнется остановка контейнеров.

Мотивация для этого заключалась в том, чтобы прокси-серверы, такие как istio, могли войти в состояние, в котором они не маршрутизируют трафик к вам, но все еще разрешают трафик, пока ваше приложение завершает работу и закрывается.

Звучит хорошо, спасибо @ Joseph-Irving. Итак, просто чтобы подтвердить мое понимание на высоком уровне: сначала крючки перед остановкой будут отправлены в коляски, затем зацепы перед остановкой - в автомобили без коляски, SIGTERM - в автомобили без коляски, а затем (после того, как все автомобили без коляски вышли ) СИГТЕРМ к коляске? Предложение по дизайну (https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md), кажется, подразумевает это, но также говорит:

Крючки PreStop будут отправлены в коляски и контейнеры одновременно.

@currankaushik да, то, что вы описали, является предполагаемым поведением.

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

@ Joseph-Irving, эта функция предназначена для включения альфа-версии в 1.15?

@ kacole2 Да, это план, предполагая, что мы сможем реализовать KEP вовремя для замораживания улучшений (30 апреля). После того, как api будет завершен https://github.com/kubernetes/enhancements/pull/919 и согласован план тестирования https://github.com/kubernetes/enhancements/pull/951, я думаю, все будет готово.

/ milestone v1.15
/ стадия альфа

@ Joseph-Irving Kubernetes 1.15 Enhancement Freeze - 30 апреля 2019 г. Для включения в контрольную точку Kubernetes 1.15 KEP должны находиться в «реализуемом» состоянии с соответствующими планами тестирования и критериями выхода. Пожалуйста, отправьте любые PR, необходимые для того, чтобы KEP соответствовал критериям включения. Если это будет отклоняться от контрольной точки 1,15, сообщите нам об этом, чтобы мы могли внести соответствующие изменения для отслеживания.

@mrbobbytables, к сожалению, доведения этого до реализуемого состояния, не

Не стоит беспокоиться. Спасибо, что так быстро ответили и сообщили нам об этом!
/ milestone clear

Помните, что этот KEP очень важен для Istio!

Это демонстрационная пробка для всех проектов, использующих сервисные фреймворки со скоординированной загрузкой / завершением работы (akka cluster, lagom и т. Д.) Вместе с istio service mesh см .

cc @jroper

@ Joseph-Irving сожалеет о позднем комментарии, но я не вижу следующего в документации по дизайну, и мне было интересно, каково их предполагаемое поведение:

если мы видим сбой сопутствующего элемента, всегда ли мы перезапускаем его, если основной контейнер не завершен (без учета restartPolicy в модуле)? Это было бы полезно в качестве сопроводительного файла, используемого для работы в качестве прокси, балансировки нагрузки, вспомогательной роли, и не имеет значения, если он выйдет из строя пару раз, пока основной контейнер может продолжать работать.

Кроме того, при вычислении фазы пода, если все основные контейнеры завершились успешно, а побочный кадр не удался (что очень часто, как если бы сопутствующий кадр не улавливал SIGTERM, код возврата будет как 143 или что-то в этом роде), будет ли фаза пода по-прежнему «Успешно»?

Контейнеры @ zhan849 в настоящее время подчиняются политике перезапуска модуля и учитываются при вычислении фазы модуля, например Succeeded .

Мы обсуждали это довольно давно в процессе, но общее мнение заключалось в том, что мы должны как можно меньше отклоняться от обычного контейнера, только если это позволяет описанные варианты использования.

Что касается фазы pod: я бы сказал, что все приложения, работающие в kubernetes, должны обрабатывать SIGTERM (особенно с коляской), но также иногда вам может понадобиться узнать, вышли ли ваши коляски плохим образом, и это должно быть отражено в фазе pod, сокрытие этой информации может привести к путанице.

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

Обе эти вещи просто соответствуют тому, что делает обычный контейнер и что происходит в настоящее время.
Менять их, похоже, не требовалось для достижения целей, перечисленных в Kep.

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

@ Джозеф-Ирвинг, у нас есть несколько более простых побочных эффектов, которые используются внутри компании для некоторых насущных нужд (мы не участвовали в этом, так как это уже выполняется в сообществе), и вот что мы узнали.

Что касается фазы стручка:

1. Статус существования контейнера уже отражен в pod.status.containerStatuses поэтому мы не потеряем информацию. Кроме того, поскольку большой вариант использования sidecar находится в Job (или в каких-либо модулях от запуска до завершения, таких как в Kubeflow), значимые рабочие нагрузки будут применяться только к основному контейнеру, и если фаза модуля помечена как Failed из-за сбоя sidecar. , это приведет к ненужным повторным попыткам и приведет к другим вводящим в заблуждение последствиям, таким как сбой задания и т. д.

2. Хотя он идеально подходит для боковых вагонов для обработки SIGTERM, в производстве может быть множество боковых вагонов, которые просто построены на программном обеспечении с открытым исходным кодом, и они плохо обрабатывают SIGTERM, включая kube-proxy , postfix , rsyslogd и многие другие (и даже если SIGTERM обработан, для не улавливаемого SIGKILL это точно не будет 0)

Что касается политики перезапуска (это может быть спорным, но если коляски строго подчиняются политике перезапуска, это нереально в производстве):

1. Принудительный перезапуск сопутствующего элемента, когда основные контейнеры все еще работают, путем установки «OnFailure» не является вариантом, так как это приведет к перезапуску неисправных основных контейнеров и сбивает с толку вместе с ограничением повторных попыток на уровне задания.

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

3. Распространение сбоев на контроллеры верхнего уровня вызовет цепочки согласования и множество вызовов API, поэтому ненужное нарастание ошибок может сделать кубернеты менее масштабируемыми.
   Более конкретный пример: если основные контейнеры задания все еще работают и сопутствующий компонент не работает, перезапуск сопутствующего элемента будет иметь только 1 операцию состояния модуля PATCH и не более 1 вызова API, связанного с событием. Но если полный отказ модуля приведет к согласованию задания и дополнительных контроллеров уровня найма, таких как CronJob и другие CRD, вызовы API могут быть намного больше.

хочу также узнать, видели ли другие люди похожие проблемы (/ cc @ kow3ns )

Будет ли это изменение включать в себя поведение, желаемое в https://github.com/kubernetes/community/pull/2342 , чтобы можно было настроить весь модуль (или только контейнер без дополнительных компонентов) для перезапуска, если коляска не работает?

@JacobHenner в настоящее время нет планов по внедрению такого механизма в этот KEP, мы обсуждали его включение, но на самом деле он не имеет большой зависимости от этого KEP и может быть разработан независимо от него. Так что, похоже, он лучше подходит для собственного KEP.

@ Joseph-Irving, просто чтобы поделиться нашим мнением по устранению вышеупомянутых ловушек для вашей справки (https://github.com/zhan849/kubernetes/commit/kubelet-sidecar), поскольку наша цель - дождаться официальной поддержки, мы стараемся чтобы изменения в этом коммите были как можно более локальными.

поэтому для политики перезапуска задания == Никогда, с 1 основным контейнером, 1 плохим сайтом, который постоянно дает сбой, 1 хорошим сайтом, который продолжает работать, статус модуля будет выглядеть следующим образом после выхода основного контейнера с указанным выше impl.

containerStatuses:
  - containerID: xxxxx
    image: xxxxx
    imageID: xxxxx
    lastState: {}
    name: main
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 0
        finishedAt: "2019-05-24T17:59:53Z"
        reason: Completed
        startedAt: "2019-05-24T17:59:43Z"
  - containerID: xxxxx
    image: xxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-bad
    ready: false
    restartCount: 1
    state:
      terminated:
        containerID: xxxxx
        exitCode: 1
        finishedAt: "2019-05-24T17:59:46Z"
        reason: Error
        startedAt: "2019-05-24T17:59:45Z"
  - containerID: xxxxx
    image: xxxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-healthy
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 137
        finishedAt: "2019-05-24T18:00:24Z"
        reason: Error
        startedAt: "2019-05-24T17:59:44Z"
  hostIP: 10.3.23.230
  phase: Succeeded
  podIP: 192.168.1.85
  qosClass: BestEffort
  startTime: "2019-05-24T17:59:41Z"

Я в целом согласен с тем, что вспомогательный KEP должен учитывать фазу пода и политику перезапуска, прежде чем он сможет перейти в реализуемое состояние. Меня не волнует, является ли это KEP или нет, но я в целом согласен с аргументами разобраться с этим.

спасибо @smarterclayton !
@ Джозеф-Ирвинг, дайте нам знать, если есть еще что-нибудь, чем вы хотели бы поделиться с нами на практике.

@smarterclayton @ zhan849 , я не особо не согласен с вашими

Я верну этот отзыв в sig-apps / sig-node и посмотрю, что они думают. В частности, sig-node были заинтересованы в том, чтобы коляски были как можно ближе к обычным контейнерам, если @derekwaynecarr или @ dchen1107 захотят

План тестирования https://github.com/kubernetes/enhancements/pull/951 и дизайн API https://github.com/kubernetes/enhancements/pull/919 теперь объединены.

Я открыл https://github.com/kubernetes/enhancements/pull/1109, чтобы пометить KEP как реализуемый, как только все будут довольны тем, что мы сможем начать разработку для этого как альфа в 1.16 🤞

Этот Kep отмечен как реализуемый, поэтому я буду повышать PR, чтобы добавить его в 1.16, начиная со следующей недели!

Я поднял https://github.com/kubernetes/kubernetes/pull/79649 для реализации API, у меня будет отдельный PR для изменений Kubelet.

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

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

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

Спасибо.

@ Joseph-Irving. Если вы хотите / вам нужны дополнительные люди для реализации этого, я очень заинтересован в этой площадке, поэтому я рад протянуть руку помощи.

Привет, @ kacole2, это
Единственный PR для этого в настоящее время - kubernetes / kubernetes # 79649 для API.

@mhuxtable Я довольно скоро подниму PR для изменений kubelet, просто закончу некоторые вещи, я был бы очень признателен за помощь, если бы взглянул на это. Свяжу здесь, когда поднимется.

Я открыл https://github.com/kubernetes/kubernetes/pull/80744, который реализует изменения кублета.

Обратите внимание, что kubernetes / kubernetes # 79649 (api) все еще открыт, поэтому этот PR содержит коммиты от него, что делает его большим. Я разбил его на коммиты, каждый из которых реализует свою функциональность, поэтому его будет легко просмотреть таким образом.

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

cc @ kacole2

@ Джозеф-Ирвинг

Я один из тени документации v1.16.
Требуются ли для этого улучшения (или работы, запланированной на v1.16) какие-либо новые документы (или модификации существующих документов)? Если нет, не могли бы вы обновить лист отслеживания улучшений 1.16 (или дайте мне знать, и я сделаю это)

Если это так, просто дружеское напоминание, что мы ищем PR против k / website (ветка dev-1.16) к пятнице, 23 августа, в настоящее время это может быть просто PR-агент. Дайте знать, если у вас появятся вопросы!

Привет, @daminisatya , да, для этого потребуются обновления Документов, я поднял https://github.com/kubernetes/website/pull/15693 в качестве заместителя PR.
Мне было бы интересно узнать, есть ли у кого-нибудь какие-либо мнения о том, куда должны идти Документы. Я добавил кое-что в content/en/docs/concepts/workloads/pods/pod-lifecycle.md на данный момент.

До Code Freeze осталось меньше недели, поэтому маловероятно, что это удастся превратить в 1.16.
У нас все еще есть два относительно крупных открытых PR: kubernetes / kubernetes # 80744 и kubernetes / kubernetes # 79649, которые изо всех сил пытались получить какие-либо отзывы.
Надеюсь, что в следующем цикле выпуска у рецензентов будет больше пропускной способности, чтобы взглянуть на них.

/назначать

Может ли это позволить написать сопроводительную книгу, которая может запускать фактическую службу по запросу (и уничтожать ее)?

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

@Ciantic С Operator Framework вы можете сделать это и многое другое. Взглянем

@janosroden Я посмотрел, но мне кажется, довольно сложно понять, как мне поднять работающие службы до нулевой масштабируемости.

Проблема не в том, что нет доступных вариантов, например Осирис , Кеда или Кнатив . Я пробовал последний, но он потребляет 8 ГБ памяти, на тот момент сложно сказать, что он «бессерверный».

Проблема в том, что большинству этих реализаций требуются новые ресурсы и т. Д., Гораздо проще подумать об этом, чтобы можно было внедрить вспомогательный элемент, который может управлять всем жизненным циклом (включая запуск и перезапуск по запросу), чтобы он мог контролировать службу, не только сидит там.

Почему это было бы полезно? Это действительно полезно в ситуациях с низким уровнем использования и нехваткой памяти, например, k3s с Raspberry Pi или дроплет Digital Ocean для хобби-проектов. У многих из нас есть множество веб-сервисов, которые не обязательно должны работать все время, достаточно было бы просто наличия сопроводительного файла, который может их разбудить по запросу.

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

Чтобы обойти это, вам в значительной степени понадобится собственный модуль, который будет выполнять начальное получение соединения и делать новый запрос модуля k8s, ждать, пока он его раскрутит, а затем отправлять ему трафик. Я думаю, что в этом случае усовершенствования контейнера Sidecar не нужны. Думаю, вам нужно что-то большее вроде xinetd для k8s.

Привет, @ Joseph-Irving - 1.17. Здесь ведутся улучшения. Я хотел проверить и узнать, будет ли это улучшение в версии 1.17 перейти на альфа-версию?

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

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

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

Спасибо!

Привет, @mrbobbytables , предполагая, что мы сможем все рассмотреть вовремя, план состоит в том, чтобы перейти на альфа-версию в 1.17.

Текущие открытые PR:
https://github.com/kubernetes/kubernetes/pull/79649 - Изменения API
https://github.com/kubernetes/kubernetes/pull/80744 - Изменения Kubelet

Дай мне знать если тебе нужно что-нибудь еще!

Большой! Спасибо, @ Joseph-Irving, я добавлю информацию в лист отслеживания 👍

@ Джозеф-Ирвинг

Я один из тени документации v1.17.
Требуются ли для этого улучшения (или работы, запланированной на v1.17) какие-либо новые документы (или модификации существующих документов)? Если нет, не могли бы вы обновить лист отслеживания улучшений 1.17 (или дайте мне знать, и я сделаю это)

Если это так, просто дружеское напоминание, что мы ищем PR против k / website (ветка dev-1.17) к пятнице, 8 ноября, в настоящее время это может быть просто PR-агент. Дайте знать, если у вас появятся вопросы!

Спасибо!

Привет @ VineethReddy02, да, для этого потребуется документация, PR-заполнитель находится здесь https://github.com/kubernetes/website/pull/17190

Я поднял PR для обновления KEP https://github.com/kubernetes/enhancements/pull/1344, это основано на некоторых обсуждениях, которые мы вели в PR реализации https://github.com/kubernetes/kubernetes/pull / 80744.

Буду признателен за любые комментарии

Привет, @ Joseph-Irving 1.17 Enhancement Shadow здесь! 👋 Я обращаюсь к вам, чтобы узнать, как продвигается это улучшение.

Команда усовершенствования в настоящее время отслеживает kubernetes / kubernetes # 79649 и kubernetes / kubernetes # 80744 в листе отслеживания. Есть ли еще какие-либо PR к / к, которые также необходимо отслеживать?

Кроме того, еще одно дружеское напоминание о том, что мы быстро приближаемся к замораживанию кода (14 ноября).

Привет @annajung , да, это единственные PR, которые нужно отслеживать.

Привет, @ Joseph-Irving! Завтра - заморозка кода для цикла выпуска 1.17 . Похоже, к / к ПР не объединены. Мы отмечаем это улучшение как At Risk в листе отслеживания 1.17.

Как вы думаете, все необходимые PR будут объединены EoD 14 числа (четверг)? После этого в вехе будут разрешены только проблемы с блокировкой выпуска и PR, за исключением.

Привет, @annajung , к сожалению, маловероятно, что они будут объединены до замораживания кода. Мы добились большого прогресса в этом цикле выпуска, поэтому, надеюсь, мы сможем объединить их на раннем этапе в 1.18.

Привет, @ Джозеф-Ирвинг. Спасибо за сообщение. Я соответствующим образом обновлю веху и отмечу это улучшение как отложенное до версии 1.18. Спасибо!

/ milestone v1.18

Привет, Джозеф-Ирвинг. 1.18 Улучшения ведут сюда 👋.

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

Спасибо!

Привет @jeremyrickard!

Да, планируется добавить это в выпуск 1.18.

PR API (https://github.com/kubernetes/kubernetes/pull/79649) получил обзор от thockin, на днях у него было несколько пунктов, но как только они будут решены, мы закроем этот PR и включим коммиты в (https://github.com/kubernetes/kubernetes/pull/80744), чтобы мы могли объединить API и реализацию вместе.

Что касается Kubelet PR (https://github.com/kubernetes/kubernetes/pull/80744), он просто нуждается в пересмотре, я надеюсь, что мы сможем получить некоторую пропускную способность сиг-узла, чтобы просмотреть его в этом цикле.

Спасибо за обновление @ Joseph-Irving

Добавил в лист отслеживания!

Извините за опоздание на вечеринку. Это значительное улучшение для общих случаев. Но, похоже, не охватывает более сложный случай.

Рассмотрим случай сопроводительного файла, который экспортирует журналы, которые также зависят от сопроводительного файла Istio. Если сначала завершится работа Istio sidecar, некоторые важные журналы могут не быть экспортированы.

Более общий подход заключался бы в определении явных зависимостей между контейнерами. Независимо от того, коляски они или нет.

Что вы думаете о таком определении api вместо этого:

kind: Pod
spec:
  containers:
  - name: myapp
    dependsOn: ["exporter", "istio"]
  - name: exporter
    dependsOn: ["istio"]
  - name: istio

@rubenhak, который очень быстро становится грязным. Что необходимо удовлетворить, чтобы зависимость продолжилась? Часто существует разрыв между начато и готово, и я думаю, что в зависимости от того, что api не решает, действительно позаботится об этом.

@ kfox1111 Как предлагаемый дизайн определяет, что sidecar запущен и готов к запуску основного контейнера? Единственное отличие, которое я предлагаю, заключается в том, что вместо того, чтобы отмечать контейнеры как «сопутствующие товары», следует использовать более общий способ определения зависимости.

Я не думаю, что в зависимости от типа следует указывать критерии. Это может быть указано в зависимом контейнере. Будет не readinessProbe и / или livenessProbe быть достаточно? В противном случае может быть startupProbe - успешное выполнение которого указывает на то, что зависимые контейнеры могут быть запущены.

Привет, @ Joseph-Irving, я один из теней в документации v1.18.
Требуются ли для этого улучшения (или работы, запланированной для v1.18) какие-либо новые документы (или модификации существующих документов)? Если нет, не могли бы вы обновить лист отслеживания улучшений 1.18 (или дайте мне знать, и я сделаю это)

Если это так, просто дружеское напоминание, что мы ищем PR против k / website (ветка dev-1.18) к пятнице, 28 февраля, в настоящее время это может быть просто PR-агент. Дайте знать, если у вас появятся вопросы!

Привет @irvifa, я поднял PR здесь https://github.com/kubernetes/website/pull/19046

Привет @ Joseph-Irving Спасибо за быстрый ответ!

@rubenhak - я согласен с @ kfox1111, что наличие полного графика зависимостей может довольно быстро стать довольно запутанным. Как насчет того, чтобы запускать контейнеры в порядке, указанном в спецификации модуля, а затем разбирать их в обратном порядке (как стек)? Это было бы намного проще реализовать, и оно охватывает большинство распространенных вариантов использования для упорядочивания, которые я могу придумать.

@rgulewich , не могли бы вы уточнить, что именно может запутаться? Получение порядка из графа - тривиальная задача, особенно с учетом того факта, что ни один здравомыслящий оператор не будет запускать более 15 боковых вагонов (уже натяжка).

Идея порядка - это нормально, но поскольку большинство боковых вагонов вводятся с использованием контроллеров допуска, было бы действительно сложно гарантировать правильность порядка. Есть потребность в косвенном обращении.

@rubenhak может быть цикл в порядке зависимости контейнеров, как k8s / kubelet решает прервать цикл и решить, в каком порядке запускать / останавливать контейнеры? Размышляя вслух, возможно, это может быть проверка на стороне API.

Привет, Джозеф-Ирвинг,

Напоминаем, что замораживание кода для версии 1.18 - 5 марта 2020 г.

По мере того, как мы приближаемся к замораживанию кода, перечислите / дайте ссылку на любые PR, над которыми вы работаете, чтобы закончить это усовершенствование!

Привет @jeremyrickard ,

Это пр для отслеживания https://github.com/kubernetes/kubernetes/pull/80744
Этот PR содержит изменения API, но коммиты будут объединены в PR выше после завершения проверки https://github.com/kubernetes/kubernetes/pull/79649

@rubenhak может быть цикл в порядке зависимости контейнеров, как k8s / kubelet решает прервать цикл и решить, в каком порядке запускать / останавливать контейнеры? Размышляя вслух, возможно, это может быть проверка на стороне API.

@bjhaid , проверка может выполняться на стороне API. Обнаружение петель - это тривиальный алгоритм с линейной временной сложностью (как и обход DFS).

Также может возникнуть необходимость в повторном запуске проверки после внедрения sidecar.

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

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

Но в идеале все initContainers должны иметь возможность использовать также и сервисную сетку.

Но initContainers может потребоваться запустить другие контейнеры sidecar.

Хотя мы могли бы разработать какую-то сложную систему зависимостей, включающую контейнеры инициализации, боковые контейнеры и обычные контейнеры, может быть, нам следует иметь просто два класса боковых автомобилей? обычные коляски и сетевые коляски?

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

снести наоборот.

Устранит ли это проблему зависимости, но при этом решит все проблемы, которые, по-видимому, возникают у сервисных сеток с упорядочиванием контейнеров? Я так думаю?

@ kfox1111 , Vault теперь выполняет секретную инъекцию с помощью

Все, что я говорю, это то, что такой дизайн в конечном итоге распался на 10 классов с коляской. Такой подход предполагает еще более сильное мнение о том, как все должно работать. Люди начали бы взламывать классы, просто чтобы добиться порядка, необходимого для запуска приложения.

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

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

Я не понимаю, насколько сложны зависимости. Не могли бы вы подробнее рассказать об этом? Зависимости делают определения YAML более очевидными, здесь нет скрытой логики. Подход с жестко запрограммированными классами потребует скрытой логики и гораздо большего количества документации, объясняющей, почему сетевые вспомогательные машины должны запускаться после других вспомогательных машин и т. Д.

Что, если мы введем поле в Контейнер?

    // +optional
    Priority int

Это поле действует среди контейнеров одного типа (sidecar, normal).
Для контейнеров с коляской контейнер с коляской с более высоким приоритетом будет создан первым / снесен в последнюю очередь.

@tedyu , у зависимости гораздо больше метаданных и значения по сравнению с "приоритетом". Для создания порядка приоритета с учетом зависимости https://www.geeksforgeeks.org/find-the-ordering-of-tasks-from-given-dependencies/ требуется 30 строк кода C ++. Обратное невозможно.

Еще одно преимущество состоит в том, что с учетом графа зависимостей некоторые контейнеры могут запускаться одновременно.
В следующем примере: «A -> B, B -> C, D -> C» контейнеры B и D могут быть запущены одновременно, если C инициализирован. Я не говорю, что реализация должна поддерживать это, но, по крайней мере, это может быть очень полезно, если API позволяет такое определение.

Целочисленный приоритет не будет работать нормально - люди будут использовать всевозможные нестандартные числа, как они это делают со свойством z-index CSS (например, -9999 ).

@rubenhak То, что вы предлагаете на этом этапе, по сути, является совершенно другой функцией, чем та, что описывается в этом KEP, это не небольшая настройка, это полная переработка. Потребовалось бы, чтобы все, кто ранее соглашался с этой функцией (на то, чтобы все стороны одобрили ее, потребовался год), чтобы переоценить ее.
Если вы увлечены такой функцией, я бы посоветовал вам создать свой собственный KEP и передать его различным SIG, чтобы получить их отзывы о нем.

Идея графа зависимостей подробно обсуждалась, когда это предложение было выдвинуто еще в 2018 году, и был единодушен в том, что, хотя это позволит сделать еще несколько вариантов использования, они не были достаточно надежными вариантами использования и что дополнительная сложность того не стоила.

Я думаю, вы несколько недооцениваете степень изменений, необходимых для реализации того, что вы описываете. Но если это так просто, как вы думаете, вы можете создать свое собственное Доказательство концепции этой работы в Kubernetes и представить его SIG, чтобы укрепить свою позицию.

Этот KEP еще не является функцией GA. Если ваш KEP будет одобрен и внедрен, мы сможем удалить его. Они еще не исключают друг друга.

Это изменение не может быть идеальным решением для каждого отдельного случая использования, но оно значительно улучшает опыт для большинства, и я думаю, что нам было бы намного лучше объединить это, чем еще год обсуждать реализацию.

если ваш KEP будет одобрен и внедрен, мы сможем удалить его. Они еще не исключают друг друга.

Будут ли они никогда не быть взаимоисключающими?

Я спрашиваю себя, имеет ли эта функция значение, даже если_ более явное упорядочение запуска / завершения работы контейнера (что, я думаю, было бы замечательно), будет включено с помощью другого улучшения в будущем ... и я думаю, что да.

Любой порядок запуска / выключения, подразумеваемый классификацией контейнеров как init, sidecar или «обычный», за исключением, эти классификации также выражают _другие_ полезные и, возможно, не связанные аспекты желаемого поведения контейнера, не так ли?

Например, это полезно в модуле с restartPolicy != Always (модуль, который, возможно, реализует задание), когда контейнеры, обозначенные как боковые, не имеют отношения к модулю, входящему в завершенное состояние.

@ kfox1111 , Vault теперь выполняет секретную инъекцию с помощью

Мы работали с временными драйверами csi, чтобы такие вещи, как vault, не нуждались в контейнерах sidecars / init. Я считаю, что в разработке находится драйвер хранилища.

Хотя обычная коляска с emptyDir кажется подходящей для коляски, которая должна использовать сетевые коляски?

@ Джозеф-Ирвинг, я ни в коем случае не пытался заблокировать этот KEP от входа. Я понимаю, что вы начали его почти 2 года назад, и довольно много людей ждут, когда это будет выпущено.

У вас есть ссылка на предыдущее обсуждение графа зависимостей?

Привет, Джозеф-Ирвинг,

Дружеское напоминание о том, что мы довольно быстро приближаемся к замораживанию кода 5 марта 2020 года . Похоже, ваши PR еще не объединились, вы все еще чувствуете, что идете по пути замораживания кода для этого улучшения?

Привет, @jeremyrickard! Обзор API (https://github.com/kubernetes/kubernetes/pull/79649) в основном завершен. Мы закроем этот PR и полностью перейдем к PR реализации, чтобы все это (API и реализация) можно было объединить в один PR.

PR реализации (https://github.com/kubernetes/kubernetes/pull/80744) был тщательно рассмотрен, поэтому я пытаюсь получить утверждающего sig-узла, чтобы получить окончательное одобрение.

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

Хотелось бы увидеть это путем замораживания кода. Это сделало бы решение Istio для https://github.com/istio/istio/issues/7136 проще и лучше.

Есть ли какие-либо подвижки при переходе на 1.18? Кажется необходимым, чтобы коляски istio работали должным образом с быстро выполняющимися заданиями.

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

@ Joseph-Irving был создан слабый канал # pr-reviews. Вы пробовали это? Это способ повысить популярность PR-обзоров. (Я этого не видел)

Привет, Джозеф-Ирвинг,

До замораживания кода осталось всего несколько дней. Вы хотите отложить это до версии 1.19 в зависимости от пропускной способности рецензента? Или попытаться подтолкнуть?

Привет @jeremyrickard ,

Никто не ответил мне по поводу объединения этих PR в 1.18, поэтому я очень сомневаюсь, что это произойдет.

Мы можем отложить до версии 1.19, но я начинаю задаваться вопросом, есть ли в этом смысл.
Этот KEP находится в стадии разработки почти два года (исходная альфа-цель была 1,15), соответствующие PR открыты почти год, для них никогда не существует «пропускной способности для рецензентов».
Я вежливо писал по электронной почте, расслаблялся, ходил на sig-встречи и даже находил людей лично, чтобы получить отзывы, но мы добились очень небольшого прогресса.
Во всех обзорах, которые мне удалось получить, предлагались только незначительные изменения, не похоже, чтобы требовалось большое переписывание, все PR в основном такие же, как и год назад, только немного более отполированные.
Я не знаю, должен ли я агрессивно пинговать людей каждый день, пока они не ответят мне, но на самом деле это не то, что мне удобно.

Я думаю, проблема больше в том, что на самом деле никого не волнует эта функция, я единственный, кто продвигает эту функцию, никто из SIG, похоже, не заинтересован в том, чтобы довести это до конца. Если для перехода к альфа-версии требуется два года, сколько времени потребуется, чтобы перейти к бета-версии / GA? (например, когда большинство людей действительно могут это использовать)

К сожалению, более широкое сообщество и конечные пользователи проявляют интерес к этой функции, потому что я сделал это в первую очередь потому, что я увидел, что это проблема, и спросил у SIG, собираются ли они ее исправить, и они сказал: «У нас нет возможностей, но мы будем рады, если вы это сделаете».
Итак, я сделал все, что они просили, я написал KEP, я получил его одобрение всех сторон, я написал весь код, все тесты, постоянно обновлял его по мере прохождения каждого выпуска, и все же мы здесь.

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

Прошу прощения за длинную тираду (не адресованную лично тебе, Джереми, или кому-либо лично в этом отношении), но это медленно разъедает мою душу в течение долгого времени.

К сожалению, более широкое сообщество и конечные пользователи проявляют интерес к этой функции, потому что я сделал это в первую очередь потому, что я увидел, что это проблема, и спросил у SIG, собираются ли они ее исправить, и они сказал: «У нас нет возможностей, но мы будем рады, если вы это сделаете».

@ Джозеф-Ирвинг Об этом. Как активный пользователь, я смотрю эту ветку, потому что мне это интересно (как и двое моих коллег). Активность по проблеме, запрос на вытягивание, резервные каналы или подписи могут быть не лучшим индикатором интереса к этой функции.

@dims Может пролить свет?

@thockin Я

Эта проблема, кажется, является ярким примером того, насколько сложно может быть содействие, если вы не являетесь сотрудником, например. Google, RedHat или другой крупный игрок.

Я также просил в Slack помочь с его рассмотрением, но мне только что сказали, что @thockin явно придерживается делать дальше.

Я потратил много времени на функцию эфемерного драйвера csi. Проходить это было так же сложно, и были времена, когда я не был уверен, что это получится после стольких задержек и переделок. Итак, я чувствую твою боль. Было бы здорово, если бы мы нашли способ сделать это менее болезненным. При этом, в конце концов, мы все же получили его после того, как пропустили несколько основных выпусков. Так что, пожалуйста, не сдавайтесь / теряйте надежду! Корабль может быть трудно повернуть, но в конце концов это произойдет.

Любой, кто использует любую топологию, зависящую от дополнительной сетевой карты, скорее всего, столкнется с проблемами порядка запуска / завершения работы контейнера, которые этот KEP потенциально может решить. Ctrl-F для "Istio" в этом билете, и вы увидите кучу неприятностей, связанных с заказом контейнеров.

Есть ли здесь какие-нибудь специалисты по сопровождению Istio? Многие из них являются гуглерами и могут иметь большее влияние на людей K8 внутри компании.

Как магазин Istio / K8s, мы абсолютно поддерживаем вас, @ Joseph-Irving! ✊❤️

Престижность для @ Joseph-Irving за то, что он сделал коляску так далеко.

Даже для управления жизненным циклом коляски любая пакетная работа потребует эту функцию, или Kubernetes просто не работает для них, и поэтому мы потратили много времени, помогая проверять код и оставляя отзывы!

Из-за этого мы какое-то время разводили k8s и очень ждем официальной поддержки такой важной функции.

Как магазин Istio + Kubernetes, мы тоже с нетерпением ждали появления этой функции. И все больше разочаровывается в том, что он ускользает от релиза к релизу. Нам не нравится прибегать к хакерским атакам, чтобы убивать мотоциклы с коляской при рабочих нагрузках. Для наших нужд это была самая важная функция, которая нам нужна в Kubernetes уже более года.

@thockin Выше сообщалось, что вы явно удерживаете это. Объясните, пожалуйста, почему.

Многие пользователи Linkerd тоже этого с нетерпением ждут. Держись @ Джозеф-Ирвинг, мы болеем за тебя.

Не уверен, что все присутствующие видели, но, покопавшись и просмотрев видео о kubecon, я обнаружил, что Lyft сделал что-то подобное. Вот упомянутый коммит из их вилки кубернетов: https://github.com/lyft/kubernetes/commit/ba9e7975957d61a7b68adb75f007c410fc9c80cc

Как магазин Istio + Kubernetes, мы тоже с нетерпением ждали появления этой функции. И все больше разочаровывается в том, что он ускользает от релиза к релизу.

Я потенциальный пользователь istio, но я немного держался в стороне из-за ожидания такой функции. Тем не менее, во время обсуждений выше я продолжаю видеть вещи, которые заставляют меня думать, что обсуждаемая здесь функция sidecar не решит всех проблем, связанных с рабочим процессом istio sidecar. Хотя это может помочь. Я думаю, это одна из причин, по которой это застопорилось.

Как работает istio в sidecar при использовании драйвера istio cni? Я считаю, что контейнеры инициализации, пытающиеся подключиться к сети, по-прежнему не будут работать должным образом, как описано в документации istio.

следовательно, мой вопрос выше, если сетевые коляски - это отдельная вещь.

Эта проблема, кажется, является ярким примером того, насколько сложно может быть содействие, если вы не являетесь сотрудником, например. Google, RedHat или другой крупный игрок.

Ха! Вы не знаете, что эти люди тоже иногда застревают!

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

В целях разъяснения:
Я не имею в виду, что мы не должны объединять это в качестве альфа-версии, чтобы получить отзывы о подходе. В целом считаю, что это нормально. Я думаю, что в сценариях использования, таких как служебные сетки, есть несколько дыр, которые он не полностью покрывает. Но это не причина блокировать получение этой функции как можно скорее, чтобы мы могли найти все другие варианты использования, которые она не охватывает, чтобы мы могли сделать бета-версию функции удобной для всех. Именно это и есть альфа для ИМО.

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

Я запросил исключение, давайте посмотрим, сможем ли мы попытаться ввести это:
https://groups.google.com/d/msg/kubernetes-sig-release/RHbkIvAmIGM/nNUthrQsCQAJ

Может быть, это вы или кто-то другой из другого эпизода [Подкаста Kubernetes] очень расстроился из-за того, что этот sidecar KEP не добрался до версии 1.16.

Пожалуйста, смотрите серию 72 с Лачи Эвенсон и 83 серию с Гвиневер Сэнгер . Я даже сказал на этой неделе, что обзоры по связям с общественностью необходимы, чтобы

Есть ли здесь какие-нибудь специалисты по сопровождению Istio? Многие из них являются гуглерами и могут иметь большее влияние на людей K8 внутри компании.

@duderino и @howardjohn оба уже прокомментировали эту

Для ясности нам нужно объединить:
кубернетес / кубернетес # 79649
кубернетес / кубернетес # 80744

Есть ли еще какие-то PR, за которыми мы должны следить?

Спасибо!

• Команда усовершенствований

Большое спасибо всем, кто разместил сообщения поддержки (публично или в частном порядке), которые были очень оценены ❤️

Члены сообщества приложили огромные усилия, чтобы попытаться внедрить это в 1.18, включая команду выпуска, которая приняла запрос на расширение, но, увы, было принято решение отложить это до версии 1.19. Вы можете увидеть соответствующий разговор, начиная с этого комментария: https://github.com/kubernetes/kubernetes/pull/80744#issuecomment -595292034.

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

cc @jeremyrickard , @kikisdeliveryservice

Отличный материал @ Джозеф-Ирвинг, похоже, что некоторые из ваших разочарований стоили того, и к ним прислушивались. Спасибо за настойчивость.

/ веха v1.19

Всем привет. Группа из нас обсуждала эту тему на прошлой неделе.

Во-первых, мы приносим свои извинения за то, что здесь произошло. Нам это не нравится.

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

В социальном плане эта функция стала жертвой нашего желания нравиться друг другу. Дерек одобрил KEP, несмотря на оговорки, высказанные в SIG, потому что Клейтон и Тим настаивали на этом. Мы все доверяем друг другу, но, видимо, не всегда чувствуем, что можем сказать «нет». Мы знаем это, потому что все сделали одно и то же. Никто из нас не хочет препятствовать следующей великой идее.

Доверие друг к другу должно включать в себя уверенность в том, что мы можем сказать «нет», и верить в то, что, когда кто-то говорит «нет», они делают это по уважительным причинам. Эта техническая область охватывает SIG, и мы НЕ должны давить на sig-узлы, которые в конечном итоге будут теми, кто решит проблемы на местах, чтобы они приняли новые функции, которые им еще неудобно поддерживать .. Это не касается Тима, Дерека или Клейтона в частности, но ВСЕ утверждающие на высоком уровне, руководители SIG и «старшие» участники.

Эта функция также стала жертвой процедурной неопределенности в отношении KEP. Обязан ли я как рецензент KEP быть рецензентом кода? Поручить обозревателю кода? Или просто прочитать KEP? Поскольку KEP охватывает выпуски, как мы можем гарантировать, что пастырь доступен для набора изменений, предусмотренных в бюджете для определенного диапазона выпусков. Если KEP охватывает SIG, как мы планируем и распределяем время между SIG? Нам нужно это прояснить. Мы собираемся работать над некоторыми предложениями по изменению KEP (KEP KEP), чтобы усилить определение ролей в процессе KEP.

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

По мере того, как все больше пользователей принимают Kubernetes, мы видим, что на sig-узел поступает все больше странных крайних случаев или ошибок. Поскольку жизненный цикл Pod является ядром Kubernetes, любые изменения, вносимые в эту подсистему, ДОЛЖНЫ выполняться с осторожностью. Наша способность объединять новые функции должна быть сбалансирована с нашим желанием повысить надежность. То, как мы думаем о жизненном цикле Pod сегодня, немного отличается от того, как мы думали о нем, когда эта функция была запущена. Это никоим образом не уменьшает количество вариантов использования, ведущих к этому, но предполагает, что длительные KEP необходимо периодически пересматривать с течением времени.

Мы думаем, что нам нужно подумать о первых принципах жизненного цикла Pod. Чего мы на самом деле хотим? Мы старались не погружаться в слишком большую сложность, но боимся, что просто разбили эту сложность на несколько этапов, и конечный результат может быть БОЛЕЕ сложным, чем просто взяться за дело.

Что это означает для данного PR и связанного с ним KEP? Мы не уверены на 100%. Это, вероятно, означает, что мы НЕ должны пока проталкивать это.

Дерек выразил некоторые опасения по поводу последовательности выключения. KEP назвал их на данный момент вне сферы действия, но есть некоторые колебания. Мы уже не уважаем постепенное завершение работы при завершении работы узла, и это удивило многих пользователей. Это не вина КЭП, но это, назовем это «смягчающими обстоятельствами». Если кто-то использует вспомогательные машины для «очистки» своих модулей (например, для слива кешированных журналов в службу ведения журналов), он будет ожидать (разумно) некоторой ясной и полезной семантики в отношении завершения работы, которую этот KEP не гарантирует.

Тим обеспокоен тем, что init-sidecars должны стать чем-то вроде, и это не кажется правильным. Раньше он отказывался от этой озабоченности, но она все еще его беспокоит.

Нам нужен SIG Node, чтобы помочь определить среднесрочную цель жизненного цикла подов и их аппетиты к этому. Если мы можем согласиться , что это инкрементальный шаг на пути к цели, мы можем разблокировать его, но если мы не знаем целей, мы , вероятно , более вождения наших фар.

Давайте все первыми скажем, что это воняет. У нас есть настоящие постановки проблем, энтузиазм и ряд доброжелательных специалистов по сопровождению, и в итоге мы оказались ... здесь. Тим будет добровольно посвящать свое время мозговому штурму и дизайну. Дерек продолжит работу по отключению узлов в текущем жизненном цикле пода, чтобы у нас была стабильная база для его дальнейшего развития. Нам нужно будет очень тщательно определить, какие гарантии мы можем и не можем дать перед лицом незапланированных отказов оборудования.

Спасибо,
Клейтон, Дэвид, Рассвет, Дерек, Джон, Тим

Чтобы попытаться стимулировать какое-то движение вперед: Дерек или Дон - есть ли у кого-нибудь сиг-нода, у которого есть время, чтобы провести мозговой штурм по поводу более целостного жизненного цикла модуля и контейнера?

@thockin добавит это в повестку дня sig-узла.

@thockin @derekwaynecarr Что за tl; dr, почему это не могло войти?

Однострочное описание улучшения: теперь контейнеры можно пометить как вспомогательные, чтобы они запускались раньше обычных контейнеров и закрывались после завершения работы всех остальных контейнеров.

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

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

... что за tl; dr относительно того, почему это не могло войти?

@naseemkullah Из https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056 ... 👇

Что это означает для данного PR и связанного с ним KEP? Мы не уверены на 100%. Это, вероятно, означает, что мы НЕ должны пока проталкивать это.

Дерек выразил некоторые опасения по поводу последовательности выключения. KEP назвал их на данный момент вне сферы действия, но есть некоторые колебания. Мы уже не уважаем постепенное завершение работы при завершении работы узла, и это удивило многих пользователей. Это не вина КЭП, но это, назовем это «смягчающими обстоятельствами». Если кто-то использует вспомогательные машины для «очистки» своих модулей (например, для слива кешированных журналов в службу ведения журналов), он будет ожидать (разумно) некоторой ясной и полезной семантики в отношении завершения работы, которую этот KEP не гарантирует.

[...]

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

С уважением, мне любопытно, планируют ли какие-либо потенциальные клиенты уделять первоочередное внимание решению этой проблемы. @ Джозеф-Ирвинг вложил в это огромную работу, и ошеломляющее количество людей, которые были бы довольны его решением, с нетерпением ждут лучшего решения от тех, кто его отклонил.

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

добавит это в повестку дня sig-узла.

@thockin @derekwaynecarr есть ли какие-нибудь обновления о текущем состоянии этого? Я просмотрел заметки о собрании сигнатурных узлов и ничего не увидел в этом.

В этом потоке есть большое количество разработчиков, которые были бы более чем счастливы потратить время на реализацию этого, поскольку это критично для многих случаев использования (сам KEP имеет в 2,5 раза больше: +1: чем любой другой KEP). Что мы можем сделать, чтобы это произошло? Наличие списка предпосылок к стабильности в этой области, даже если он может охватывать множество выпусков, над которыми мы могли бы начать активную работу, было бы огромным улучшением по сравнению с тем, где мы находимся сегодня.

Привет, @ Joseph-Irving @thockin @khenidak @ kow3ns - Улучшения 1.19 Ведите сюда, я хотел проверить, думаете ли вы, что это улучшение появится в версии 1.19?

Чтобы получить эту часть релиза:

1. KEP PR необходимо объединить в реализуемом состоянии.
2. У KEP должны быть планы тестирования
3. У KEP должны быть критерии окончания.

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

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

@palnabarun , согласно этому комментарию https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056, этот KEP был приостановлен на неопределенный срок, поэтому нет, он не будет выходить из версии 1.19.

Спасибо @ Joseph-Irving за разъяснение ситуации. : +1:

Цените ваши старания!

Всем, кто жаждет получить это, и еще раз @ Joseph-Irving - я лично очень сожалею об этой ситуации. Я тоже хочу этого (или чего-то подобного), но дело в том, что у sig-node больше работы, чем у людей, которые это делают прямо сейчас, и они не готовы это рассматривать.

Это отстой. Я понял. Я действительно люблю.

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

у sig-node больше работы, чем у людей, которые делают это прямо сейчас

Понял. Мы продвигали, с упором, потребности в мощности для сиг-узлов внутри компании. Мы привлекаем и наставляем добровольцев OSS с сигнатурными узлами, некоторые из них испытали новые возможности, все с желанием работать в этой сфере (пока четверо). Я процитирую ваш комментарий @thockin , спасибо!

/ milestone clear

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

@thockin Не могли бы вы предоставить ссылки на репозитории, списки рассылки, руководства и т. д.? Это поможет людям понять, как эффективно взаимодействовать с sig-узлами. Этому конкретному запросу функции более 2 лет, и решения пока не видно.

@ tariq1890 люди, пишущие этот KEP, сделали все правильно. они не оставили камня на камне. Проблема здесь в том, что сказал @thockin : есть технический долг, который нам нужно исправить в первую очередь, и для этого нужны руки, прежде чем мы сможем рассмотреть этот. Итак, просим людей помочь с тем, что нужно сделать.

Просмотрите последнее обновление здесь: https://github.com/kubernetes/enhancements/pull/1874

@dims Я думаю, что меня неправильно поняли. Я хотел сказать, что нам нужен список достижимых целей и задач. Если есть технический долг, который необходимо решить, мы могли бы поддерживать GitHub Milestone или предоставить маркированный список ожидающих действий в комментарии OP, чтобы люди, посещающие эту проблему, могли сразу знать, что необходимо решить.

Я определенно готов предложить свою помощь sig / node в продвижении этого KEP, но просто не знаю, как

@ tariq1890 конкретный запрос находится здесь: «предварительное условие для корректного завершения работы (еще не отправленного KEP) узла kubelet» https://github.com/kubernetes/enhancements/pull/1874/files#diff -c6212b56619f2b462935ad5f631d772fR94

Нам нужно это начать. Кто-то должен понять суть дела и начать действовать.

- затемнения

Итак, резюмируйте https://github.com/kubernetes/enhancements/pull/1874 для тех, кто в этом выпуске: Sig-узел (и другие) считают неразумным вводить новую функцию, подобную этому KEP, которая добавляет более сложное поведение к завершение модуля, в то время как все еще существует более общая проблема завершения модуля во время завершения работы узла.
Поэтому было решено, что эта функция не будет развиваться, пока не будет реализовано решение по завершению работы узла.
В настоящее время здесь есть документ Google: https://docs.google.com/document/d/1mPBLcNyrGzsLDA6unBn00mMwYzlP2tSct0n8lWfuRGE
Который содержит много дискуссий по этому вопросу, но KEP для этого еще не представлен.
По-прежнему есть открытые вопросы, поэтому комментарии по ним могут быть полезны, я считаю, что @bobbypage и @mrunalp возглавляют эти усилия, поэтому, возможно, они могут поделиться любыми другими способами, которыми люди могут помочь в продвижении вперед.

@ Джозеф-Ирвинг благодарит за подведение итогов. Я надеюсь, что вся положительная энергия этого улучшения приведет к большему участию всех в sig-узле на регулярной основе, а не только для отдельных функций. Работы много, а рук мало.

Привет! Еще один комментарий относительно этого KEP: я поднимал некоторые крайние случаи по поводу этого KEP на прошлых собраниях SIG-узла (23 июня, если вы хотите посмотреть записи), и мы решили, что правильный способ продолжить это обсуждение - это начать PR по этим вопросы, чтобы мы могли решить, как лучше всего действовать.

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

Кроме того, состояние KEP теперь является предварительным (а не реализуемым), поэтому его можно просмотреть и снова установить в качестве реализуемого только тогда, когда все люди согласятся, что им будет комфортно продвигаться вперед с KEP.

Думаю, это единственное, чего не хватало в этом выпуске. Спасибо!

@rata Вы открывали вопросы / PR о том, как правильно решать проблемы?

@mattfarina Это пиар https://github.com/kubernetes/enhancements/pull/1913
Он содержит ряд предлагаемых решений текущих проблем / крайних случаев в KEP.
Также содержит подробную информацию о ряде альтернатив, которые были обсуждены и отклонены, чтобы у нас был лучший журнал того, почему были приняты определенные решения.

Я бы очень хотел, чтобы функциональность коляски также охватывала масштабирование:
Сегодня масштабирование HPA основано на метрике (например, cpu). Если модуль содержит более одного контейнера, используется среднее значение по всем контейнерам (насколько мне известно). Для модулей с дополнительным элементом (приложение + nginx и т. Д.) Это очень затрудняет правильную функцию масштабирования. Я надеялся, что реализация sidecar в Kubernetes будет включать в себя пометку одного контейнера в модуле как «авторитетного» с точки зрения метрик, используемых для масштабирования HPA.

Я бы очень хотел, чтобы функциональность коляски также охватывала масштабирование:

Я согласен, что это было бы полезно, но это не обязательно связано с «сопутствующей книгой», и, поскольку реализация не связана с этим, может иметь смысл выделить его в отдельную проблему - это уже очень сложно. Я также не уверен, что вы хотите просто игнорировать коляску. Например, нам может потребоваться масштабирование HPA для каждого контейнера. Не уверен - я думаю, это требует отдельного изучения.

Кто-нибудь может сослаться на текущее решение этой проблемы, особенно в случае с коляской Istio Envoy, или может быть так любезен поделиться?

Я вспоминаю возможное обходное решение, включающее:

• пользовательское изображение Envoy, которое игнорирует SIGTERM.
• вызов / quitquitquit на Envoy из контейнера приложения при завершении работы (аналогично обходному пути завершения задания)

Кто-нибудь может сослаться на текущее решение этой проблемы, особенно в случае с коляской Istio Envoy, или может быть так любезен поделиться?

Мы используем собственный образ демона, например supervisor чтобы обернуть программу пользователя. Демон также будет прослушивать определенный порт, чтобы передать состояние работоспособности программ пользователей (завершено или нет).

Вот обходной путь:

• Использование образа демона как initContainers для копирования двоичного файла на общий том.
• Наш CD перехватит команду пользователя, пусть демон запустится первым. Затем демон запускает программу пользователя, пока Envoy не будет готов.
• Кроме того, мы добавляем preStop , скрипт, который постоянно проверяет состояние работоспособности демона для Envoy.

В результате процесс пользователей запустится, если Envoy будет готов, и Envoy остановится после выхода из процесса пользователей.

Это сложный обходной путь, но он отлично работает в нашей производственной среде.

Ссылка в описании дает 404

https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0753-sidecarcontainers.md

Думаю, должно быть:

https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0753-sidecarcontainers.md

да, он был перемещен в https://github.com/kubernetes/enhancements/pull/1913 , я обновил ссылку

Кто-нибудь может сослаться на текущее решение этой проблемы, особенно в случае с коляской Istio Envoy, или может быть так любезен поделиться?

@shaneqld для проблем с запуском, сообщество istio придумало довольно умный обходной путь, который в основном вводит envoy в качестве первого контейнера в списке контейнеров и добавляет обработчик postStart, который проверяет и ожидает готовности envoy. Это блокировка, и другие контейнеры не запускаются, чтобы убедиться, что посланник присутствует и готов, перед запуском контейнера приложения.

Нам пришлось перенести это в текущую версию, но это довольно просто, и пока мы довольны результатами.

Для выключения мы также «решаем» с помощью preStop hook, но добавляем произвольный сон, который, как мы надеемся, приложение корректно завершит, прежде чем продолжить работу с SIGTERM.

Связанный PR: https://github.com/kubernetes/enhancements/pull/1980

Привет @ Джозеф-Ирвинг @thockin и все остальные: smile:

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

Спасибо!
Кирстен

@kikisdeliveryservice будет держать вас в курсе, спасибо!

Кто-нибудь может сослаться на текущее решение этой проблемы, особенно в случае с коляской Istio Envoy, или может быть так любезен поделиться?

@shaneqld для проблем с запуском, сообщество istio придумало довольно умный обходной путь, который в основном вводит envoy в качестве первого контейнера в списке контейнеров и добавляет обработчик postStart, который проверяет и ожидает готовности envoy. Это блокировка, и другие контейнеры не запускаются, чтобы убедиться, что посланник присутствует и готов, перед запуском контейнера приложения.

Нам пришлось перенести это в текущую версию, но это довольно просто, и пока мы довольны результатами.

Для выключения мы также «решаем» с помощью preStop hook, но добавляем произвольный сон, который, как мы надеемся, приложение корректно завершит, прежде чем продолжить работу с SIGTERM.

Не могли бы вы подробно рассказать о том, как это сделать? Как добиться добавления «pre-stop» к сайдкару Istio-proxy? Кажется, ему нужна нестандартная конфигурация или использование кастомной коляски. Я сталкиваюсь с той же проблемой, что при уменьшении масштаба подов основной контейнер пытается завершить работу, но теряет соединение с внешним миром, вероятно, потому, что сайдкар Istio закрывается сразу после SIGTERM. Прямо сейчас я просто использую инъекцию коляски по умолчанию. Спасибо!

Хорошо, эта ветка перехватывается. Не останавливайтесь на теме, пожалуйста.

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

Кроме того, KEP использует более старый формат, поэтому обновление будет отличным (после того, как вы завершите детализацию): https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

@kikisdeliveryservice благодарит за остаток. Сделаю если решено включить по 1.20. Спасибо! :)

Это не будет частью 1.20. Большое спасибо за пинг! :)

У меня есть интерес к этой проблеме, и я хотел бы поблагодарить @ Joseph-Irving и @howardjohn за их идеи по этому

Я не хочу перехватывать это предложение, но, основываясь на разговорах выше, мне интересно, может быть, это немного более широкая / большая проблема, чем было признано до сих пор.

Я могу представить следующие решения этой проблемы -

1. Определите новый объект-контейнер «sidecar container», который начинается после initContainers, перед «основными контейнерами» и завершается после завершения «основных контейнеров» (согласно исходному предложению @ Joseph-Irving)
2. Определите дополнительное поле в (1), которое устанавливает, запускается ли «контейнер sidecar» до initContainer (ов) согласно предложению @luksa ).
3. Идите шире.

Лично вариант (2) решает мою непосредственную проблему .

Но мне интересно, не связаны ли эти вопросы с более стратегической проблемой K8s, связанной с планированием и тем, как мы определяем под. В моем конкретном (связанном с Istio) случае я предложил что-то вроде уровней запуска внутри подов.

Вариант (2) также решает мою проблему, но я могу представить себе еще более сложные структуры зависимостей, которые могут потребовать встраивания DAG зависимостей контейнеров в pod / statefulSet / daemonSet / что угодно - это вариант (3), о котором я думаю.

Просто интересно, действительно ли следует переориентировать эту проблему на само определение модуля с целью создания чего-то более общего? Первоначально я думал об аналогии с уровнями выполнения, но, возможно, структура DAG, подобная Airflow, будет иметь самое широкое применение.

А как насчет добавления посланника в качестве контейнера инициализации? Таким образом, он обеспечит сеть для других контейнеров инициализации. Когда init завершится, он также выйдет из 0, и тогда обычный envoy (не init) возьмет на себя

@michalzxc Если я не ошибаюсь, контейнеры инициализации выполняются один за другим последовательно, поэтому в настоящее время у вас не может быть посланника рядом с другим контейнером в виде init-container .

Привет!

Обсуждение сопроводительных файлов продолжилось на этом месте (я обновил sig-node slack, github PR, с которого это началось, и несколько списков рассылки):
https://groups.google.com/g/kubernetes-sig-node/c/w019G3R5VsQ/m/bbRDZTv5CAAJ
https://groups.google.com/g/kubernetes-sig-node/c/7kUaX-jBN3M/m/dhI3E8LOAAAJ

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

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

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

Пожалуйста , смотрите @rata «s предыдущий комментарий https://github.com/kubernetes/enhancements/issues/753#issuecomment -707014341
Для мест, где вы можете внести свой вклад в обсуждение.

К сожалению, вся работа, проделанная над этим KEP, не будет использоваться, но более широкая группа людей теперь думает над этими проблемами, поэтому мы надеемся, что решение, которое они придумают, будет лучшим для всех.
Я уже потратил более двух лет, пытаясь пройти через это, поэтому я думаю, что сейчас хорошее время для меня, чтобы двигаться дальше, @rata и другие будут руководить этими инициативами в будущем.

/близко

@ Джозеф-Ирвинг: Закрытие этого выпуска.