Перекрестная ссылка с kubernetes / kubernetes: выпуск № 62822

Спасибо за обновления!

/ assign @leblancd
/ kind feature
/ sig сеть
/ веха 1.11

@leblancd есть ли проектный документ?

/ cc @thockin @dcbw @luxas @ kubernetes / sig-network-feature-requests

@idvoretskyi - Дизайн-документа пока нет, но мы скоро начнем

Означает ли это, что Kubernetes Ingress будет поддерживать Dual-Stack?
Означает ли это, что CNI (Calico) потребуется запустить двойной стек (например, демоны BIRD и BIRD6)?

@ sb1975 - Что касается поддержки входящего

• Поддержка входящего трафика двойного стека в основном зависит от того, какой контроллер входящего трафика вы используете (поддерживается ли он и как реализован). Существующие контроллеры входящего трафика, вероятно, потребуют некоторых изменений для поддержки двойного стека.
• Я ожидаю, что конфигурация входа для типичного контроллера входа не изменится (конфигурация может, например, по-прежнему сопоставлять адрес L7 с именем службы / портом службы, без упоминания о семействе V4 / V6)
• В случае, когда служба имеет модули конечных точек, которые являются двойными стеками, входному контроллеру (-ам) могут потребоваться изменения, чтобы сопоставить входящие пакеты на основе семейства пакетов, то есть сопоставить входящие пакеты IPv4 с конечной точкой IPv4 и сопоставить входящие пакеты IPv6. к конечной точке IPv6. В целях взвешивания балансировки нагрузки конечная точка с двумя стеками должна считаться одной конечной точкой.

- Мы могли бы рассмотреть возможность использования БУДУЩЕЙ поддержки карты входящего контроллера для семейств V4 / V6 (сопоставление входящих пакетов IPv4 с серверной частью IPv6 и наоборот), но наша первоначальная разработка будет для строгого двойного стека (т. Е. Отдельного, независимого стеки).

Что касается Calico и других плагинов CNI:

• Плагины CNI НЕ ДОЛЖНЫ работать в режиме двойного стека, если сценарий кластера не требует двойного стека, они все равно должны иметь возможность запускать только IPv4 или только IPv6 (если плагин поддерживает это).
• Поддержка двойного стека, вероятно, потребует изменений в различных подключаемых модулях CNI, но эта работа считается выходящей за рамки этой проблемы Kubernetes (мы сосредоточены на том, чтобы Kubernetes работал с любым произвольным подключаемым модулем с двойным стеком, возможно, используя подключаемый модуль моста как справку), а работа CNI будет выполняться отдельно в каждом конкретном случае.
• В частности, в отношении Calico я не эксперт, но я считаю, что один демон BIRD может быть настроен для обработки маршрутов как IPv4, так и IPv6 (ищите "шаблон bgp" здесь: http://bird.network.cz/?get_doc&v= 20 & f = bird-3.html # ss3.1). Тем не менее, хотя Calico уже поддерживает адреса с двумя стеками в модуле, могут потребоваться изменения, чтобы маршрутизация BGP работала для обоих семейств.

@leblancd : Вот сценарий:

1. Допустим, мы будем использовать контроллер входящего трафика NGINX.
2. Я выставляю свои сервисы через Ingress.
3. Я использую свои поды, настроенные на двойной стек
4. Я пытаюсь связаться с сервисом удаленно, используя dns-записи A и AAAA.
   Надеюсь на все это
5. Подводя итог: я хочу подключиться к интерфейсам модуля, используя адреса IPv4 или IPv6, как было решено моими собственными запросами для записей A и / или AAAA для имени службы модуля.
   Могу ли я принять участие в этой инициативе по тестированию, документации, архитектуре: но мне нужны некоторые рекомендации.
   Как мне узнать об этом, пожалуйста.

@ sb1975 - Хороший вопрос. входной контроллер NGINX с двойным стеком. Я не эксперт по входному контроллеру NGINX (может, кто-нибудь более знакомый сможет вмешаться), но вот как я бы увидел рабочий процесс:

• Когда вы пытаетесь подключиться к сервисам Kube извне, ваш DNS-контроллер должен разрешить сервис с A и AAAA DNS-записями для входного контроллера. Ваш клиент / приложение выберет использование записи A или AAAA для доступа к входному контроллеру. Таким образом, внешний доступ к контроллеру входящего трафика будет двойным.
• Затем на входном контроллере NGINX NGINX будет просматривать URL-адрес L7 (независимо от того, находится ли запрос в пакете IPv4 или IPv6) и балансирует нагрузку на конечные точки восходящего потока. Если балансировщик нагрузки контроллера входящего трафика настроен с ipv6 = on (что по умолчанию, см. Https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#configuring-http-load -balancing-using-dns), а конечная точка (и) службы - с двойным стеком, тогда конфигурация восходящего потока должна иметь записи как IPv4, так и IPv6 для каждой конечной точки с двойным стеком. Как и задумано, подсистема балансировки нагрузки NGINX обрабатывает запись IPv4 и запись IPv6 для конечной точки как отдельные серверы . (См. Строку в вышеупомянутом документе «Если доменное имя разрешается в несколько IP-адресов, адреса сохраняются в конфигурации восходящего потока и балансируются по нагрузке».) Это можно считать хорошими или плохими новостями. Хорошей новостью является то, что балансировка нагрузки будет выполняться между конечными точками IPv4 и IPv6 (что дает вам некоторую избыточность), где, например, входящий запрос IPv4 может быть сопоставлен либо с конечной точкой IPv4, либо с конечной точкой IPv6. Но потенциально плохие новости связаны с гранулярностью балансировки нагрузки: соединение с конечной точкой IPv4 и соединение с соответствующей конечной точкой IPv6 будут обрабатываться (для соображений балансировки нагрузки) как 2 нагрузки на отдельные конечные точки, а не как 2 отдельные нагрузки на одну конечную точку. . Если эта гранулярность балансировки нагрузки вызывает беспокойство, тогда кто-то может отключить балансировку нагрузки для IPv6 (или для IPv4, если для этого есть ручка конфигурации?), Чтобы балансировка нагрузки была для конечных точек, поддерживающих только IPv4. ИЛИ , возможно, балансировщик нагрузки NGINX можно изменить так, чтобы он обрабатывал соединение с IPv4-адресом и соединение с его соответствующим IPv6-адресом как две нагрузки на одну и ту же конечную точку.

Что касается помощи и участия, мы будем очень признательны! Мы собираемся начать всерьез работать над двойным стеком (это немного задержалось из-за работы по настройке CI только для IPv6). Я надеюсь вскоре выпустить схему спецификации (Google Doc или KEPs WIP doc), и мне понадобится помощь в рассмотрении и, возможно, написании некоторых разделов. Нам также ОБЯЗАТЕЛЬНО понадобится помощь с официальной документацией (помимо спецификации дизайна), а также с определением и реализацией тестов E2E с двумя стеками. Некоторые из областей, которые я пока немного отрывочны в плане дизайна, включают:

• Каким образом зонды работоспособности / живучести / готовности влияют или обрабатываются с помощью двойного стека
• Будет ли влияние на сетевую политику?
• Проблемы с балансировщиком нагрузки?
• Проблемы с плагином облачного провайдера?
• Проблемы с проникновением L3 / L4?
  Если вы подумали о чем-либо из них, может быть, вы могли бы помочь с этими разделами?

Мы также рассматриваем промежуточный подход с «двойным стеком на границе» (с IPv6-only внутри кластера), при котором доступ извне кластера к службам K8s будет двухстековым, но это будет отображаться (например, через NGINX входящий контроллер) к конечным точкам только IPv6 внутри кластера (или используйте NAT46 без сохранения состояния). Модули и сервисы в кластере должны быть полностью IPv6, но большим преимуществом будет то, что внешний доступ с двойным стеком будет доступен намного быстрее с точки зрения времени выхода на рынок.

/ этап 1.12

@leblancd / @caseydavenport - я
Следует ли вывести это из рубежа 1.11?

@justaugustus - Да, это нужно переместить в 1.12. Нужно ли мне удалить строку в таблице выпуска или нужно что-то сделать, чтобы это изменить?

@leblancd Я все прикрыл. Спасибо за продолжение! :)

@leblancd @ kubernetes / sig-network-feature-запросы -

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

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

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

Установите следующее:

• Описание
• Цессионарий (и)
• Ярлыки:
  
  
  
  • stage / {альфа, бета, стабильный}
  
  
  • sig / *
  
  
  • вид / особенность
  
  

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

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

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

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

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

/ cc @justaugustus @ kacole2 @robertsandoval @ rajendar38

@leblancd -
Замораживание функций сегодня. Планируете ли вы перейти на бета-версию Kubernetes 1.12?
Если да, можете ли вы убедиться, что все обновлено, чтобы я мог включить это в таблицу отслеживания функций 1.12?

Привет, @justaugustus! Kubernetes 1.13 должен получить статус бета-версии. Мы делаем (хотя и медленно) прогресс в разработке KEP (https://github.com/kubernetes/community/pull/2254), и мы приближаемся к повторному включению тестового PR CI, но Kubernetes 1.12 цель была слишком оптимистичной.

Я обновлю описание / сводку выше, указав информацию, которую вы запрашивали ранее. Спасибо за терпеливость.

/ remove-stage альфа
/ этап бета

Не беспокойся, @leblancd. Спасибо за обновления!

Привет, @justaugustus @leblancd

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

@ navjotsingh83 - Я не думаю, что дата выпуска Kubernetes 1.13 определена. Я не вижу 1.13 в документации по релизам Kubernetes .

Опубликован график выпуска @ navjotsingh83 @leblancd 1.13 . Это короткий цикл выпуска с замораживанием кода 15 ноября. Считаете ли вы, что пора перевести эту функцию на бета-версию? Можете ли вы обновить эту проблему с вашим уровнем уверенности, что ожидает завершения с точки зрения кода, тестирования и документации?

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

/ этап очищен

@ kacole2, чтобы удалить это из таблицы улучшений 1.13.

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

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

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

/ remove-жизненный цикл устаревший

@leblancd Здравствуйте! Я являюсь руководителем усовершенствования версии 1.14, и я проверяю эту проблему, чтобы узнать, какие работы (если таковые имеются) планируются для выпуска 1.14. Заморозка улучшений 29 января, и я хочу напомнить, что все улучшения должны иметь KEP

@leblancd Хотел продолжить ваш предыдущий комментарий относительно создания разграничения на краю кластера для IPv4 / IPv6:

«Мы также рассматриваем промежуточный подход с« двойным стеком на границе »(с IPv6-only внутри кластера), при котором доступ извне кластера к службам K8s будет двойным стеком, но это будет отображаться (например, через Контроллер входящего трафика NGINX) к конечным точкам только IPv6 внутри кластера (или используйте NAT46 без сохранения состояния). Модули и сервисы в кластере должны быть полностью IPv6, но большим преимуществом будет то, что внешний доступ с двойным стеком будет доступен намного быстрее с точки зрения времени выхода на рынок ».

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

@KevinAtDesignworx Если curl -v 93.184.216.34 -H "Host: example.com" ), я искренне думаю, что это лучший подход. Если ваша инфраструктура может использовать ipv6, зачем использовать ipv4, кроме как на границе по соображениям совместимости. Однако, если этот подход означает, что я не могу получить доступ к устаревшим веб-сайтам, используя только ipv4 из моего кластера, я больше в этом не уверен.

ну, есть 464XLAT, поэтому ipv6 только внутри контейнера будет возможен.

@KevinAtDesignworx - если в вашем сценарии будет работать контроллер входящего трафика, можно настроить контроллер входящего трафика NGINX для работы с двумя стеками извне (проксирование на одно семейство внутри кластера): https://github.com/leblancd/ kube-v6 # установка -a-dual-stack-ingress-controller-on-an-ipv6-only-kubernetes-cluster

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

• Ваши узлы имеют двойной стек (в отличие от модулей и служб, которые являются односемейными)
• Ваш / etc / hosts на каждом узле имеет записи IPv6 и только записи IPv6 (без адресов IPv4) для имени хоста этого узла.

Это будет в дополнение к NAT64 / DNS64 для подключений клиентов V6 внутри кластера к внешним серверам, поддерживающим только IPv4.

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

@leblancd - какие работы запланированы здесь для 1.15? Похоже, KEP еще не был принят. Спасибо!

@leblancd Хотел продолжить ваш предыдущий комментарий относительно создания разграничения на краю кластера для IPv4 / IPv6:

«Мы также рассматриваем промежуточный подход с« двойным стеком на границе »(с IPv6-only внутри кластера), при котором доступ извне кластера к службам K8s будет двойным стеком, но это будет отображаться (например, через Контроллер входящего трафика NGINX) к конечным точкам только IPv6 внутри кластера (или используйте NAT46 без сохранения состояния). Модули и сервисы в кластере должны быть полностью IPv6, но большим преимуществом будет то, что внешний доступ с двойным стеком будет доступен намного быстрее с точки зрения времени выхода на рынок ».

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

Изнутри контейнера (который является только ipv6) отправка запроса curl (т.е. curl -v 93.184.216.34 -H "Host: example.com") за пределы кластера. Я думаю, что он выдаст ошибку неизвестного назначения или назначения недоступен, если на хосте, где существует контейнер, не существует маршрута ipv4.

@ GeorgeGuo2018, если бы k8s реализовал DNS64 / NAT64, это сработало бы. это сильно зависит от того, насколько далеко k8s войдет в решения 464xlat / plat и что нужно будет обрабатывать на граничных маршрутизаторах и т. д.

на самом деле я думаю, что это было бы возможно, используя DaemonSet / Deployment, который использует сеть хостов и Tayga внутри пространства имен kube-system, чтобы внутренний DNS64 использовал tayga для выхода за пределы сети.

Похоже на решение для меня.

У нас внутренняя сеть только для IPv6, и NAT64 / DNS64 нам подходит. Для некоторых устаревших вещей, где вообще не было поддержки IPv6, мы в конечном итоге использовали clatd непосредственно там, где это было необходимо. (В нашем случае прямо на виртуальной машине.)

@ kacole2 - Я бы хотел, чтобы это отслеживалось для https://github.com/kubernetes/enhancements/pull/808

В частности, для версии 1.15 мы добавим поддержку следующего:

• Модификации типов API
  
  
  
  • Типы Kubernetes
  
  
  • Типы CRI
  
  
• сеть с двумя модулями стека (модуль с несколькими IP)
• кубенет многосемейная поддержка

cc @caseydavenport для отслеживания этапов ^

@ kacole2 KEP теперь объединен. Сообщите мне, есть ли что-то еще, что нам нужно для отслеживания этого в 1.15

Привет, @leblancd @ lachie83 Просто дружеское напоминание, что мы ищем PR против k / website (ветка dev-1.15) до четверга, 30 мая. Было бы здорово, если бы это начало полной документации, но даже заполнитель PR приемлем. Дайте знать, если у вас появятся вопросы!

@ kacole2 KEP теперь объединен. Сообщите мне, есть ли что-то еще, что нам нужно для отслеживания этого в 1.15

@ lachie83 Привет, Лачи, вы имели в виду, что поддержка двойного стека IPv4 / IPv6 в этом KEP была завершена?

@ kacole2 KEP теперь объединен. Сообщите мне, есть ли что-то еще, что нам нужно для отслеживания этого в 1.15

Собственно, я хочу выяснить, обязательно ли будет добавлена ​​поддержка двойного стека в k8s 1.15.

@leblancd Заполнитель PR для k8s.io dev-1.15 должен быть опубликован в четверг, 30 мая.

@leblancd Заполнитель PR для k8s.io dev-1.15 должен быть опубликован в четверг, 30 мая.

Могу ли я считать, что поддержка двух стеков будет доступна в версии 1.15?

@ GeorgeGuo2018 Он все еще находится в @ kacole2 может предоставить вам более подробную информацию об этом.

Привет, @ lachie83 @leblancd. Code Freeze - четверг, 30 мая 2019 г., EOD PST . Все улучшения, входящие в выпуск, должны быть завершены кодом, включая тесты , и иметь открытую документацию по PR.

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

Я вижу, что kubernetes / kubernetes # 62822 в исходном сообщении все еще открыт. Ожидаем ли мы слияния и других PR?

Если вы знаете, что это произойдет, ответьте и сообщите нам. Спасибо!

@simplytunde -

@ GeorgeGuo2018 - Это будет многопользовательский KEP. Мы планируем перейти на фазу 1 в 1.15. Пожалуйста, ознакомьтесь с планом реализации в KEP для получения дополнительных сведений - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6-dual-stack.md#implementation -план.

@simplytunde - здесь я создал первичный PR для документов-заполнителей с помощью WIP https://github.com/kubernetes/website/pull/14600. Я планирую завершить и подготовить его к рассмотрению в течение следующих нескольких дней.

@ kacole2 Спасибо за пинг. Я обновил таблицу улучшений 1.15, указав K / K PR, который мы отслеживаем (https://github.com/kubernetes/kubernetes/pull/73977), а также PR черновика документации (https://github.com/ kubernetes / website / pull / 14600). В настоящее время мы все еще находимся на пути к объединению этого PR до замораживания кода. LMK, если мне что-то не хватает

@ kacole2 после обсуждения с @claurence и командой разработчиков мы решили убрать это с этапа 1.15. Удалите его и обновите таблицу соответствующим образом. Спасибо за вашу помощь.

/ этап очищен

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

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

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

Спасибо.

https://github.com/kubernetes/dns/issues/315 описывает добавление IPv6 / AAAA в спецификацию обнаружения службы DNS .

@ lachie83 @leblancd есть идеи, будет ли это выпускаться в 1.16, чтобы отследить это?

@ evillgenius75 @ kacole2 Это нужно отслеживать в 1.16. Эта функция будет в альфа-состоянии. Мы будем реализовывать этап 1 и этап 2, как определено в KEP 1.16.

Отслеживание KEP

• https://github.com/kubernetes/enhancements/pull/808

Объединенные к / к ПР (на данный момент в мастере будет в 1.16)

• [MERGED] Этап 1 - https://github.com/kubernetes/kubernetes/pull/73977
• [MERGED] Этап 1 тестирования e2e - https://github.com/kubernetes/kubernetes/pull/78801
• [MERGED] Этап 1 очистки теста e2e - https://github.com/kubernetes/kubernetes/pull/80001
• Службы / конечные точки фазы 2 - https://github.com/kubernetes/kubernetes/pull/79386
• Фаза 2 kube-proxy - https://github.com/kubernetes/kubernetes/pull/79576

Связанные PR

• Поддержка IPv6 https://github.com/kubernetes-incubator/ip-masq-agent/pull/45
• Документы фазы 1 - будут повторно открыты, как только мы доработаем примеры инструментов - https://github.com/kubernetes/website/pull/14600
• [MERGED] очистка - узел dropDisabledFields - https://github.com/kubernetes/kubernetes/pull/79741
• Поддержка нескольких размеров маски для кластерных cidrs - https://github.com/kubernetes/kubernetes/pull/79993
• E2e Prow Job для двойного стека https://github.com/kubernetes/test-infra/pull/12966

Привет, @leblancd Я руководитель выпуска документации

Требуются ли для этого улучшения (или работы, запланированной в версии 1.16) какие-либо новые документы (или модификации)?

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

@simplytunde вот PR документации - https://github.com/kubernetes/website/pull/16010

Заморозка кода напоминания версии 1.16
Службы / конечные точки фазы 2 - kubernetes / kubernetes # 79386
Фаза 2 kube-proxy - kubernetes / kubernetes # 79576

Связанный:
Поддержка нескольких размеров масок для кластерных cidrs - kubernetes / kubernetes # 79993
E2e Prow Job для кубернетов с двойным стеком / test-infra # 12966

Привет @ lachie83 @leblancd похоже, что https://github.com/kubernetes/kubernetes/pull/79576 и https://github.com/kubernetes/kubernetes/pull/79993 не слились до замораживания кода, и это не так в пуле слияния приливов . Эта функция будет улучшена с версии 1.16. Если вы все же хотите, чтобы это было частью выпуска 1.16, отправьте исключение

@ kacole2 Приносим извинения за задержку с ответом. Основной отслеживаемый PR был https://github.com/kubernetes/kubernetes/pull/79386. Что касается kubernetes / kubernetes # 79576, мы приняли решение отложить это до версии 1.17 и вместо этого сосредоточиться на https://github.com/kubernetes/kubernetes/pull/82091 (в соответствии с sig-network), который выполняет те же цели фазы 2, что и были выложены в КЭП. Другой связанный PR, который отслеживался в этом выпуске, был https://github.com/kubernetes/kubernetes/pull/80485, который также объединен. kubernetes / kubernetes # 79993 также был перенесен на версию 1.17.

Привет, @ lachie83 @leblancd - 1.17 Здесь ведутся улучшения. Я хотел проверить и посмотреть, думаете ли вы, что это улучшение будет переведено на альфа / бета / стабильная версия в 1.17?

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

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

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

Спасибо!

/ этап очищен

Привет боб. Спасибо, что обратились к нам. Я все еще планирую фазу 3 этого усовершенствования, которая завершит усовершенствование до завершения. Это улучшение все еще будет в альфа-версии в конце этого выпуска, но будет работа, связанная с фазой 3, которая появится в k / k как часть 1.17.

Вот список результатов высокого уровня для 1.17 для двойного стека. Я буду обновлять этот список на протяжении всего релиза.

• Двухстековый прокси IPtables - https://github.com/kubernetes/kubernetes/pull/79576
• нисходящая поддержка api для Pod.Status.PodIPs - https://github.com/kubernetes/kubernetes/pull/83123
• e2e протестировать один плагин CNI
• Изменения файла хоста (необходимо добавить IPv6-адрес для имени хоста / etc / hosts) - https://github.com/kubernetes/kubernetes/pull/83123
• Добрый двойной стек - https://github.com/kubernetes-sigs/kind/pull/692
• Обновите пакет e2e - https://github.com/kubernetes/kubernetes/pull/80725
• Поддержка среза конечной точки
• Поддержка Dual-Stack для Kubeadm - https://github.com/kubernetes/kubeadm/issues/1612

Большое спасибо, любезно спасибо @ lachie83 ❤️ Я добавлю это в лист отслеживания.

/ milestone v1.17

@mrbobbytables Я также добавил PR, чтобы подробно описать работу, перечисленную выше как часть фазы 3 в KEP, после передачи плана через sig-сеть. Сам KEP все еще находится в состоянии implementable и эти изменения просто документируют запланированную работу в частности, как часть 1.17.

В какой-то момент я хотел бы убедиться, что https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ охватывает IPv6 DNS. https://github.com/kubernetes/website/issues/15434 отслеживает эти изменения; упоминая это здесь, чтобы отметить перекрестную ссылку.

Обновлен KEP для добавления тестов e2e фазы 2 - https://github.com/kubernetes/enhancements/pull/1311

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

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

@ lachie83

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

Привет, @ lachie83 , я знаю, что ты следишь за вкладками, но мне все равно нужно зайти и упомянуть об этом 🙈
Заморозка кода не за горами (14 ноября). Как дела? Будет ли до этого времени объединено все, что идет по плану?

Спасибо!

Привет, @mrbobbytables! Спасибо за пинг. Мы отслеживаем следующие PR, которые появятся в 1.17. С этим изменением могут быть связаны еще один или два PR. Для этих изменений потребуются документы. Подниму плейсхолдер docs PR

• Поддержка Dualstack для режима kube-proxy iptables pr / 82462
• Нисходящий API Dualstack pr / 82462
• добавить поддержку конечных точек ipvs metaproxierlice pr / 84089
• Разрешить использование масок cidr для нескольких узлов в kube-controller-manager pr / 79993

@irvifa - Здесь PR-заполнитель документов. https://github.com/kubernetes/website/pull/17457

Круто спасибо @ lachie83

@ lachie83 завтра - заморозка кода для цикла выпуска 1.17. Похоже, к / к ПР еще не слились. 😬 Мы помечаем это как «Под угрозой» в листе отслеживания улучшений 1.17.
Как вы думаете, они будут объединены EoD 14-го (четверг)? После этого момента в вехе будут разрешены только проблемы с блокировкой выпуска и PR, за исключением.

Спасибо, Боб - я буду обсуждать это с sig-network сегодня и предоставлю обновление.

Привет, @mrbobbytables. Вот список PR, над которыми мы работаем сегодня, чтобы объединить EoD и которые были одобрены sig-network.

• https://github.com/kubernetes/kubernetes/pull/85246
• https://github.com/kubernetes/kubernetes/pull/83123
• https://github.com/kubernetes/kubernetes/pull/79993

Оставшийся PR, скорее всего, будет доведен до 1.18 - https://github.com/kubernetes/kubernetes/pull/82462

@mrbobbytables просто подтверждает, что все указанные выше

Отлично, спасибо @ lachie83!

И это в прямом эфире! https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement/

Мы планируем перевести это улучшение в бета-версию в 1.18. Критерии для завершения повышения квалификации и планы тестирования можно найти в KEP вместе с этим PR - https://github.com/kubernetes/enhancements/pull/1429

/ этап 1.18

@ lachie83 : Указанная веха недействительна для этого репозитория. Вехи в этом репозитории: [ keps-beta , keps-ga , v1.17 , v1.18 , v1.19 , v1.20 , v1.21 ]

Используйте /milestone clear чтобы очистить контрольную точку.

/ milestone v1.18

Мы планируем перевести это улучшение в бета-версию в 1.18. Критерии повышения квалификации и планы тестирования можно найти в KEP вместе с этим PR - # 1429.

Спасибо за обновление @ lachie83 , я пометил это как отслеживаемое в таблице 1.18!

Пожалуйста, отслеживайте следующий PR в рамках работы над выходом 1.18. https://github.com/kubernetes/kubernetes/pull/82462

Добавление других связанных PR для отслеживания:
https://github.com/kubernetes/test-infra/pull/15893
https://github.com/kubernetes-sigs/kind/pull/692

Спасибо @ lachie83!

Привет, @ lachie83 , есть ли у вас какие-либо другие PR, которые мы должны отслеживать, кроме упомянутых выше?

Привет, @ lachie83 @leblancd - я тень Docs в команде выпуска 1.18.

Требуются ли для этой работы по усовершенствованию, запланированной в версии 1.18, какие-либо новые документы или модификации существующих документов?

Если нет, не могли бы вы обновить лист отслеживания улучшений 1.18 (или дайте мне знать, и я сделаю это)

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

Дайте знать, если у вас появятся вопросы!

Если кому-то нужна помощь в документировании IPV6 или двойного стека для v1.18, подтолкните меня. Возможно, я смогу помочь.

Привет @ lachie83 ,

Похоже, что kubernetes-sigs / kind # 692 еще не слились. Это критично для вашего окончания бета-версии?

Привет, @jeremyrickard @sethmccombs, нам придется вытащить это из перехода на бета-версию, учитывая этот PR https://github.com/kubernetes/kubernetes/pull/86895. Пока у нас не будет разумного пути вперед, я не думаю, что будет разумно переводить это в бета-версию для 1.18.

/ этап очищен

@ lachie83 Спасибо за обновление. Я удалил это улучшение из вехи. С нетерпением жду этого 1.19. :)

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

Если на веб-сайте есть страницы, которые показывают Kubernetes с двумя стеками как бета-версию, отправьте их против k / website в качестве приоритетных / важных-скоро ошибок.

Привет, @ lachie83 - Улучшения 1.19

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

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

Если на веб-сайте есть страницы, которые показывают Kubernetes с двумя стеками как бета-версию, отправьте их против k / website в качестве приоритетных / важных-скоро ошибок.

@sftim Я поднял два PR по поводу маркировки релиза в 1.17 и 1.18

@palnabarun Мы работаем над обновлением двойного стека KEP в сроки выпуска 1.19, однако в настоящее время мы не думаем, что внесем изменения в код в выпуске 1.19. У нас есть одна проблема с блокировкой уже выполненной работы (благодаря тому, что она находится в состоянии alpha ). Проблема с блокировкой: https://github.com/kubernetes/kubernetes/pull/86895. Мы планируем решить эту проблему с помощью следующего обновления KEP https://github.com/kubernetes/enhancements/pull/1679, но для достижения консенсуса по предлагаемому изменению потребуется время. На этом этапе улучшение двойного стека будет оставаться в состоянии alpha до тех пор, пока мы не решим эту проблему блокировки с помощью текущей реализации. Я буду сообщать обновления по мере развития событий.

Спасибо, Лачи, за обновления. Ценю все старания! : Little_smiling_face:

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

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

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

/ remove-жизненный цикл устаревший

Мы хотели бы, чтобы это улучшение было отслежено в 1.20. Он будет повторно реализован в альфа-состоянии в соответствии с обновленным kep - https://github.com/kubernetes/enhancements/pull/1679. Пожалуйста, отслеживайте следующий PR для реализации - https://github.com/kubernetes/kubernetes/pull/91824. Мы планируем завершить обзор и объединить PR в начале цикла выпуска 1.20.

Последний переход с двойным стеком до статуса бета-версии, как обсуждалось на собрании сети SIG 17 сентября, для тех, кто играет дома:

• Должен разрешить неоднозначность проверки работоспособности двойного стека кубелета; через https://github.com/kubernetes/enhancements/pull/1975
• Необходимо завершить и объединить существующий PR двухстековых услуг (в стадии активного анализа); через https://github.com/kubernetes/kubernetes/pull/91824
• Необходимо завершить работу с IP-адресами узлов с двойным стеком; через https://github.com/kubernetes/enhancements/pull/1665
• Следует определить, какие (если есть) изменения, необходимые для поля Spec.LoadBalancerIPs службы.

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

@dcbw большое спасибо за обновление (извините, я не смог позвонить). Есть ли смысл вносить это в бета-версию 1.20 или просто оставаться в альфа-версии? Если мы хотим перейти на бета-версию, имеют ли критерии выхода в KEP смысл, учитывая, что это повторная реализация https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md # окончание -критерии

@dcbw большое спасибо за обновление (извините, я не смог позвонить). Есть ли смысл вносить это в бета-версию 1.20 или просто оставаться в альфа-версии? Если мы хотим перейти на бета-версию, имеют ли критерии выхода в KEP смысл, учитывая, что это повторная реализация https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md # окончание -критерии

Однако на самом деле это не повторная реализация. Вся предыдущая работа по-прежнему в силе, и работа в 1.20 строится на ее основе, чтобы завершить последние необходимые изменения, которые были идентифицированы. Моя интерпретация обсуждения sig-network заключается в том, что опубликованный список @dcbw представляет собой набор оставшихся известных проблем, которые необходимо решить для выпуска.

Всем привет,

1.20 Улучшения Ведите сюда, я собираюсь установить это как отслеживаемое, пожалуйста, обновите меня, если что-то изменится :)

Напоминаем, что заморозка улучшений - 6 октября.

В качестве примечания, KEP использует старый формат, который мы обновили до: https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template.

Лучший,
Кирстен

/ milestone v1.20

Привет, @russellb -

Однако на самом деле это не повторная реализация. Вся предыдущая работа по-прежнему в силе, и работа в 1.20 строится на ее основе, чтобы завершить последние необходимые изменения, которые были идентифицированы.

Учитывая изменения API в https://github.com/kubernetes/kubernetes/pull/91824, достаточно различий в том, что маркировка двойного стека как альфа для 1.20 оставит место для любых дальнейших повторных реализаций, которые окажутся необходимыми. Я знаю, что мы все стремимся к бета-версии, но давайте сначала поставим PR с +9,319 −3,261 и дадим пыль осесть. :)

Учитывая изменения API в kubernetes / kubernetes # 91824 , достаточно различий, чтобы пометить двойной стек как альфа для 1.20, +9,319 −3,261 и дадим пыль осесть. :)

@bridgetkromhout Да, нам нужно приземлиться https://github.com/kubernetes/kubernetes/pull/91824, прежде чем мы сможем определить готовность API. Я очень надеюсь, что мы сможем сделать это как можно скорее.

Всем привет,

1.20 Улучшение тени здесь 👋

Поскольку это улучшение планируется в 1.20, имейте в виду следующие важные даты в ближайшее время:
Пятница, 6 ноября: 8-я неделя - крайний срок PR
Четверг, 12 ноября: 9-я неделя - замораживание кода

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

Спасибо!

Привет, @kinarashah @kikisdeliveryservice - я подтвердил на вызове sig-network, что нам нужно реклассифицировать его в альфа для версии 1.20. Это полная повторная реализация, которая требует времени, чтобы выдержать и протестировать на стадии альфа-тестирования.

Привет @ lachie83 , 1.20 Docs shadow здесь.

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

Если да, то следует стадиям здесь , чтобы открыть PR против dev-1.20 филиал в k/website репо. Этот PR может быть просто заполнителем в настоящее время и должен быть создан до 6 ноября .

Также ознакомьтесь с документированием выпуска, чтобы ознакомиться с требованиями к документации для выпуска.

Спасибо!

Спасибо @ reylejano-rxm - мы открыли kubernetes / сайт № 24725

Привет @ lachie83

Спасибо за создание PR документации!

Пожалуйста, помните о предстоящих важных датах:

• Пятница, 6 ноября: 8-я неделя - крайний срок PR для заполнителей документов ВЫПОЛНЕН !
• Четверг, 12 ноября: 9-я неделя - замораживание кода
• Понедельник, 23 ноября: 11-я неделя - Документы PR готовы к рассмотрению

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

Привет, @kinarashah @kikisdeliveryservice - я подтвердил на вызове sig-network, что нам нужно реклассифицировать его в альфа для версии 1.20. Это полная повторная реализация, которая требует времени, чтобы выдержать и протестировать на стадии альфа-тестирования.

Привет @ lachie83

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

_Просто напоминаем, что Code Freeze появится через 2 дня в четверг, 12 ноября . Все PR должны быть объединены к этой дате, в противном случае требуется исключение.

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

Привет, @kikisdeliveryservice - да, поддержка двойного стека IPv4 / IPv6 (переопределенная) будет альфа-

Вот прогресс, который у нас есть для этого улучшения:

1) Код объединен с https://github.com/kubernetes/kubernetes/pull/91824 - будет альфа для 1.20
2) Обновления документации, касающиеся этого изменения кода, находятся на https://github.com/kubernetes/website/pull/24725/ - проверены и объединены в ветку dev-1.20.

Есть ли что-нибудь еще, что мы еще не завершили для этого улучшения для версии 1.20?

@bridgetkromhout Спасибо за четкое обновление, у вас все хорошо!

Похоже, что LoadBalancerIP в ServiceSpec еще не является частью реализации двойного стека. Есть ли какие-то планы по его поддержке, или я его пропустил?

Привет, @chenwng - Изменения в коде облачного провайдера для балансировщиков нагрузки в настоящее время выходят за рамки, как определено в KEP здесь - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md # load -balancer-operation.

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

@chenwng В кластерах с двойным стеком работает KEP для LoadBalancerIPs - https://github.com/kubernetes/enhancements/pull/1992

Спасибо за информацию, @aramase , @ lachie83 .