Referencia cruzada con kubernetes / kubernetes: número 62822

¡Gracias por la actualización!

/ asignar @leblancd
/ tipo de característica
/ sig red
/ hito 1,11

@leblancd ¿ algún documento de diseño disponible?

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

@idvoretskyi : todavía no hay ningún documento de diseño, pero comenzaremos a colaborar en uno en breve.

¿Significa esto que Kubernetes Ingress admitirá Dual-Stack?
¿Significa esto que CNI (Calico) necesitaría ejecutar Dual stack (por ejemplo, demonios BIRD y BIRD6)?

@ sb1975 - Con respecto al soporte de entrada de doble pila, eso es algo que tendremos que analizar, pero aquí están mis pensamientos preliminares:

• La compatibilidad con la entrada de doble pila dependerá principalmente del controlador de entrada que utilice (si es compatible y cómo se implementa). Los controladores de entrada existentes probablemente necesitarán algunos cambios para admitir la doble pila.
• Espero que la configuración de entrada para un controlador de entrada típico no cambie (la configuración podría, por ejemplo, asignar una dirección L7 a un nombre de servicio / puerto de servicio, sin mencionar la familia V4 / V6)
• En el caso de que un servicio tenga pods de punto final que sean de doble pila, los controladores de entrada pueden necesitar cambios para mapear paquetes de entrada según la familia de paquetes, es decir, mapear paquetes de entrada IPv4 a un punto final IPv4 y mapear paquetes de entrada IPv6 a un punto final IPv6. A los efectos de la ponderación del equilibrio de carga, un punto final de doble pila debe contar como un objetivo de punto final único.

- Es posible que deseemos considerar el soporte FUTURO para tener un mapa de controlador de entrada en las familias V4 / V6 (asignar paquetes de entrada IPv4 a un backend IPv6 y viceversa), pero nuestro desarrollo inicial será para una pila dual estricta (es decir, separados, independientes pilas).

Con respecto a Calico y otros complementos de CNI:

• Los complementos CNI no TENDRÁN QUE ejecutarse en modo de doble pila si un escenario de clúster no requiere doble pila, aún deberían poder ejecutar solo IPv4 o solo IPv6 (si el complemento lo admite).
• El soporte de doble pila probablemente requerirá cambios en los diversos complementos CNI, pero ese trabajo se considera fuera del alcance de este problema de Kubernetes (nos estamos enfocando en hacer que Kubernetes funcione para cualquier complemento arbitrario de doble pila, probablemente usando el complemento puente como una referencia), y el trabajo de la CNI se realizará por separado, caso por caso.
• Para Calico específicamente, no soy un experto, pero creo que se puede configurar un solo demonio BIRD para manejar rutas IPv4 e IPv6 (busque "template bgp" aquí: http://bird.network.cz/?get_doc&v= 20 & f = pájaro-3.html # ss3.1). Dicho esto, aunque Calico ya admite direcciones de doble pila en el pod, es posible que se requieran cambios para que el enrutamiento BGP funcione para ambas familias.

@leblancd : Así que aquí está el escenario:

1. Digamos que usaremos el controlador de ingreso NGINX
2. Expongo mis servicios a través de Ingress.
3. Estoy ejecutando mis pods configurados en doble pila
4. Estoy intentando comunicarme con el servicio de forma remota mediante los registros dns A y AAAA.
   Espero que todos estos
5. En resumen: quiero conectarme a las interfaces del pod utilizando direcciones IPv4 o IPv6, según lo resuelto por mis propias consultas de registros A y / o AAAA para el nombre del servicio del pod.
   ¿Puedo involucrarme en esta iniciativa para probar, documentación, arquitectura: pero necesito alguna orientación?
   ¿Cómo puedo saber sobre el progreso de esto?

@ sb1975 - Buena pregunta re. el controlador de ingreso NGINX con doble pila. No soy un experto en el controlador de entrada NGINX (tal vez alguien más familiar pueda intervenir), pero así es como vería el flujo de trabajo:

• Cuando intenta comunicarse con los servicios de Kube desde el exterior, su controlador DNS debe resolver el servicio con registros DNS A y AAAA para el controlador de entrada. Sería elección de su cliente / aplicación utilizar el registro A frente al registro AAAA para llegar al controlador de entrada. Por lo tanto, el acceso externo al controlador de entrada sería de doble pila.
• En el controlador de entrada de NGINX, NGINX luego miraría la URL L7 (independientemente de que la solicitud se encuentre en un paquete IPv4 o IPv6) y lo equilibraría a los puntos finales ascendentes. Si el balanceador de carga del controlador de entrada está configurado con ipv6 = on (que es el valor predeterminado, consulte https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#configuring-http-load -balancing-using-dns) y los puntos finales de servicio son de doble pila, la configuración ascendente debe tener entradas tanto IPv4 como IPv6 para cada punto final de doble pila. Tal como se diseñó, el equilibrador de carga NGINX trata la entrada IPv4 y la entrada IPv6 para un punto final como servidores separados . (Vea la línea en el documento mencionado anteriormente "Si un nombre de dominio se resuelve en varias direcciones IP, las direcciones se guardan en la configuración ascendente y la carga se equilibra"). Esto puede considerarse una buena o una mala noticia. La buena noticia es que el equilibrio de carga se realizará en los puntos finales IPv4 e IPv6 (lo que le dará cierta redundancia), donde, por ejemplo, una solicitud IPv4 entrante podría mapearse a un punto final IPv4 o IPv6. Pero la posible mala noticia es la granularidad del equilibrio de carga: una conexión a un punto final IPv4 y una conexión al punto final IPv6 correspondiente se tratarán (por consideraciones de equilibrio de carga) como 2 cargas para puntos finales separados, en lugar de 2 cargas separadas para el mismo punto final. . Si esta granularidad de equilibrio de carga es una preocupación, entonces alguien podría deshabilitar el equilibrio de carga a IPv6 (¿o a IPv4, si hay una perilla de configuración para eso?), De modo que el equilibrio de carga sería para puntos finales solo de IPv4. O , tal vez el equilibrador de carga NGINX se pueda modificar para tratar una conexión a una dirección IPv4 y una conexión a su dirección IPv6 correspondiente como 2 cargas al mismo punto final.

En cuanto a ayudar e involucrarse, ¡esto sería muy apreciado! Estamos a punto de comenzar a trabajar en serio en la pila dual (se ha retrasado un poco por el trabajo para hacer que CI funcione solo para IPv6). Espero poder presentar un esquema para una especificación (Google Doc o KEPs WIP doc) pronto, y estaría buscando ayuda para revisar y tal vez escribir algunas secciones. DEFINITIVAMENTE también necesitaremos ayuda con la documentación oficial (más allá de las especificaciones de diseño) y con la definición e implementación de pruebas E2E de doble pila. Algunas de las áreas en las que todavía estoy un poco incompleto para el diseño incluyen:

• ¿Cómo se ven afectadas o manejadas las sondas de salud / vitalidad / preparación con doble pila?
• ¿Habrá un impacto en las políticas de red?
• ¿Preocupaciones sobre el balanceador de carga?
• ¿Preocupaciones sobre los complementos del proveedor de la nube?
• ¿Problemas de ingreso de L3 / L4?
  Si ha pensado en alguno de estos, ¿quizás podría ayudar con esas secciones?

También estamos considerando un enfoque intermedio de "doble pila en el borde" (con IPv6 solo dentro del clúster), donde el acceso desde fuera del clúster a los servicios de K8 sería de doble pila, pero esto se mapearía (por ejemplo, a través de NGINX controlador de entrada) a los puntos finales solo IPv6 dentro del clúster (o use NAT46 sin estado). Los pods y servicios en el clúster tendrían que ser todos IPv6, pero la gran ventaja sería que el acceso externo de doble pila estaría disponible mucho más rápidamente desde una perspectiva de tiempo de comercialización.

/ hito 1.12

@leblancd / @caseydavenport : estoy notando mucha discusión aquí y un cambio de hito.
¿Debería sacarse esto del hito de 1,11?

@justaugustus - Sí, esto debería moverse a 1.12. ¿Necesito eliminar una fila en la hoja de cálculo de la versión o hay algo que deba hacer para cambiar esto?

@leblancd lo tengo cubierto. ¡Gracias por hacer el seguimiento! :)

@leblancd @ kubernetes / sig-network-feature-orders -

Esta función se eliminó del hito anterior, por lo que nos gustaría verificar y ver si hay algún plan para esto en Kubernetes 1.12.

Si es así, asegúrese de que este problema esté actualizado con TODA la siguiente información:

• Descripción de la función de una línea (se puede utilizar como nota de la versión):
• Contacto principal (cesionario):
• SIG responsables:
• Enlace de propuesta de diseño (repositorio comunitario):
• Enlace a e2e y / o pruebas unitarias:
• Revisores: (para LGTM) recomiendan tener más de 2 revisores (al menos uno del archivo de PROPIETARIOS de área de código) que estén de acuerdo para revisar. Los revisores de varias empresas prefieren:
• Aprobador (probablemente de SIG / área a la que pertenece la característica):
• Objetivo de función (qué objetivo es igual a qué hito):
  
  
  
  • Objetivo de liberación alfa (xy)
  
  
  • Objetivo de lanzamiento beta (xy)
  
  
  • Objetivo de liberación estable (xy)
  
  

Configure lo siguiente:

• Descripción
• Cesionario (s)
• Etiquetas:
  
  
  
  • etapa / {alfa, beta, estable}
  
  
  • sig / *
  
  
  • tipo / característica
  
  

Tenga en cuenta que la congelación de funciones es el 31 de julio, después de lo cual cualquier problema de funciones incompletas requerirá que se acepte una solicitud de excepción en el hito.

Además, tenga en cuenta los siguientes plazos relevantes:

• Fecha límite de documentos (RRPP de marcador de posición abierto): 21 de agosto
• Congelación de casos de prueba: 8/28

Asegúrese de que todos los RP de las funciones también incluyan notas de la versión relevantes.

¡Feliz envío!

/ cc @justaugustus @ kacole2 @robertsandoval @ rajendar38

@leblancd -
Feature Freeze es hoy. ¿Está pensando en graduar esto a Beta en Kubernetes 1.12?
Si es así, ¿puede asegurarse de que todo esté actualizado para que pueda incluirlo en la hoja de cálculo de seguimiento de funciones 1.12?

Hola @justaugustus : el estado Beta deberá pasar a Kubernetes 1.13. Estamos progresando (aunque lentamente) en el diseño KEP (https://github.com/kubernetes/community/pull/2254), y nos estamos acercando a volver a involucrarnos con el PR de prueba de CI, pero el Kubernetes 1.12 el objetivo era demasiado optimista.

Actualizaré la descripción / resumen anterior con la información que solicitó anteriormente. Gracias por su paciencia.

/ remove-stage alpha
/ etapa beta

No te preocupes, @leblancd. ¡Gracias por la actualización!

Hola, @justaugustus @leblancd

Acabo de leer la actualización de que la versión beta se movió a 1.13 para doble pila. ¿Cuál es la fecha de lanzamiento prevista de 1.13? De hecho, estamos buscando soporte de doble pila. Es una decisión inútil que nuestro producto se mueva a contenedores.

@ navjotsingh83 : no creo que la fecha de lanzamiento de Kubernetes 1.13 se haya consolidado. No veo 1.13 en la documentación de versiones de Kubernetes .

Se publica el calendario de lanzamiento de @ navjotsingh83 @leblancd 1.13 . Es un ciclo de lanzamiento corto con congelación de código el 15 de noviembre. ¿Crees que es tiempo suficiente para pasar esta función a Beta? ¿Puede actualizar este problema con su nivel de confianza, qué está pendiente en términos de código, prueba y finalización de documentos?

Según la discusión en la reunión de la Red SIG, aunque se hará un trabajo considerable en esta función en 1.13, no se espera que vaya a Beta en 1.13. eliminando el hito en consecuencia.

/ hito claro

@ kacole2 para eliminar esto de la hoja de cálculo de mejoras 1.13

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

/ remove-lifecycle stale

@leblancd Hola: Soy el líder de la mejora para la versión 1.14 y estoy revisando este problema para ver qué trabajo (si corresponde) se está planificando para la versión 1.14. La congelación de las mejoras es el 29 de enero y quiero recordar que todas las mejoras deben tener un KEP

@leblancd Quería dar seguimiento a su comentario anterior relativo a la creación de una delimitación en el borde del clúster para IPv4 / IPv6:

“También estamos considerando un enfoque intermedio de" doble pila en el borde "(con IPv6 solo dentro del clúster), donde el acceso desde fuera del clúster a los servicios de K8 sería de doble pila, pero esto se mapearía (por ejemplo, a través de Controlador de entrada NGINX) a puntos finales solo IPv6 dentro del clúster (o use NAT46 sin estado). Los pods y los servicios en el clúster tendrían que ser todos IPv6, pero la gran ventaja sería que el acceso externo de doble pila estaría disponible mucho más rápidamente desde una perspectiva de tiempo de comercialización ".

Este caso de uso sería bueno para un proyecto actual, así que quería ver sus pensamientos sobre el marco de tiempo, ver si había algo que yo mismo o alguien de nuestro grupo pudiera contribuir para ayudar con este camino más rápido para llegar al mercado.

@KevinAtDesignworx Si el curl -v 93.184.216.34 -H "Host: example.com" ), realmente creo que es el mejor enfoque. Si su infraestructura puede usar ipv6, ¿por qué molestarse en usar ipv4 excepto en el borde por razones de compatibilidad? Sin embargo, si este enfoque significa que no puedo acceder a sitios web heredados utilizando únicamente ipv4 desde dentro de mi clúster, ya no estoy tan seguro.

bueno, hay 464XLAT, por lo que ipv6 solo dentro del contenedor sería factible.

@KevinAtDesignworx : si el uso de un controlador de entrada funcionaría en su escenario, es posible configurar un controlador de entrada NGINX para la operación de doble pila desde el exterior (proxy a una sola familia dentro del clúster): https://github.com/leblancd/ kube-v6 # instalación -a-dual-stack-ingress-controller-on-an-ipv6-only-kubernetes-cluster

Los controladores de entrada deberían ejecutarse en la red de host en cada nodo, por lo que los controladores deberían configurarse como un daemonset (un controlador de entrada en cada nodo). Esto supone:

• Sus nodos son de doble pila (a diferencia de los pods y los servicios que son unifamiliares)
• Su / etc / hosts en cada nodo tiene entradas IPv6 y solo entradas IPv6 (sin direcciones IPv4) para el nombre de host de ese nodo.

Esto se sumaría a un NAT64 / DNS64 para las conexiones de los clientes V6 dentro del clúster a los servidores externos solo de IPv4.

Stateless NAT46 también es una opción, pero no lo he probado, así que no tengo ninguna guía de configuración para eso.

@leblancd ¿hay algún trabajo planeado aquí para la 1.15? Parece que todavía no se ha aceptado un KEP en este momento. ¡Gracias!

@leblancd Quería dar seguimiento a su comentario anterior relativo a la creación de una delimitación en el borde del clúster para IPv4 / IPv6:

“También estamos considerando un enfoque intermedio de" doble pila en el borde "(con IPv6 solo dentro del clúster), donde el acceso desde fuera del clúster a los servicios de K8 sería de doble pila, pero esto se mapearía (por ejemplo, a través de Controlador de entrada NGINX) a puntos finales solo IPv6 dentro del clúster (o use NAT46 sin estado). Los pods y los servicios en el clúster tendrían que ser todos IPv6, pero la gran ventaja sería que el acceso externo de doble pila estaría disponible mucho más rápidamente desde una perspectiva de tiempo de comercialización ".

Este caso de uso sería bueno para un proyecto actual, así que quería ver sus pensamientos sobre el marco de tiempo, ver si había algo que yo mismo o alguien de nuestro grupo pudiera contribuir para ayudar con este camino más rápido para llegar al mercado.

Desde el interior de un contenedor (que es solo ipv6) enviando una solicitud curl (es decir, curl -v 93.184.216.34 -H "Host: example.com") al exterior del clúster. Creo que dará un error de destino desconocido o destino inalcanzable, a menos que exista una ruta ipv4 en el host donde existe el contenedor.

@ GeorgeGuo2018 si k8s implementara DNS64 / NAT64, funcionaría. depende en gran medida de qué tan lejos llegará k8s a las soluciones 464xlat / plat y qué se necesitaría manejar en los enrutadores de borde, etc.

de hecho, creo que sería posible mediante el uso de un DaemonSet / Deployment que usa redes de host y Tayga dentro del espacio de nombres del sistema kube para que el DNS64 interno use tayga para salir de la red.

Suena como una solución para mí.

Ejecutamos una red solo IPv6 internamente y NAT64 / DNS64 funciona bastante bien para nosotros. Para algunas cosas heredadas donde no había soporte IPv6 en absoluto, terminamos usando clatd directamente donde se necesitaba. (En nuestro caso directamente en una VM).

@ kacole2 - Me gustaría rastrear esto para 1.15. Estoy trabajando para fusionar las siguientes relaciones públicas: https://github.com/kubernetes/enhancements/pull/808

Específicamente para 1.15, estaríamos agregando soporte para lo siguiente:

• Modificaciones de tipo de API
  
  
  
  • Tipos de Kubernetes
  
  
  • Tipos de CRI
  
  
• red de pod de doble pila (pod de varias direcciones IP)
• soporte multifamiliar de kubenet

cc @caseydavenport para seguimiento de hitos ^

@ kacole2 el KEP ahora está fusionado. Avísame si hay algo más que necesitemos para rastrear esto en 1.15

Hola @leblancd @ lachie83 Solo un recordatorio amistoso de que estamos buscando un PR contra k / website (branch dev-1.15) para el jueves 30 de mayo. Sería genial si es el comienzo de la documentación completa, pero incluso un marcador de posición PR es aceptable. ¡Hazme saber si tienes alguna pregunta!

@ kacole2 el KEP ahora está fusionado. Avísame si hay algo más que necesitemos para rastrear esto en 1.15

@ lachie83 Hola, Lachie, ¿quiso decir que se terminó el soporte de doble pila IPv4 / IPv6 para este KEP?

@ kacole2 el KEP ahora está fusionado. Avísame si hay algo más que necesitemos para rastrear esto en 1.15

En realidad, quiero averiguar si el soporte de doble pila seguramente se agregará en k8s 1.15.

@leblancd El marcador de posición PR contra k8s.io dev-1.15 vence el jueves 30 de mayo.

@leblancd El marcador de posición PR contra k8s.io dev-1.15 vence el jueves 30 de mayo.

¿Puedo considerar que el soporte de doble pila estará disponible en la versión 1.15?

@ GeorgeGuo2018 Todavía está en la hoja de mejoras para 1.15, pero solo el líder de mejoras @ kacole2 puede brindarle mejores detalles al respecto.

Hola @ lachie83 @leblancd. Code Freeze es el jueves 30 de mayo de 2019 @ EOD PST . Todas las mejoras que se introduzcan en la versión deben ser de código completo, incluidas las pruebas , y tener documentos PR abiertos.

Por favor, enumere todos los k / k PR actuales para que se puedan rastrear cuando se congelan. Si los RP no se fusionan por congelación, esta función se deslizará durante el ciclo de lanzamiento de 1.15. Solo se permitirán problemas de bloqueo de versiones y RP en el hito.

Veo que kubernetes / kubernetes # 62822 en la publicación original aún está abierto. ¿Hay otros RP que también esperamos fusionar?

Si sabe que esto se deslizará, responda y háganoslo saber. ¡Gracias!

@simplytunde -

@ GeorgeGuo2018 - Este será un KEP de múltiples lanzamientos. Planeamos aterrizar en la fase 1 en 1.15. Consulte el plan de implementación en el KEP para obtener más detalles: https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6-dual-stack.md#implementation -plan.

@simplytunde - He creado el marcador de posición inicial PR aquí con un WIP https://github.com/kubernetes/website/pull/14600. Planeo completarlo y tenerlo listo para su revisión durante los próximos días.

@ kacole2 Gracias por el ping. Actualicé la hoja de especificaciones de mejoras 1.15 con el PR k / k que estamos rastreando (https://github.com/kubernetes/kubernetes/pull/73977) junto con el borrador de documentos PR (https://github.com/ kubernetes / sitio web / pull / 14600). Actualmente, todavía estamos en camino de fusionar este PR antes de la congelación del código. LMK si me falta algo más

@ kacole2 después de discutir con @claurence y el equipo de lanzamiento, hemos decidido eliminar esto del hito 1.15. Continúe, elimínelo y actualice la hoja de cálculo según corresponda. Gracias por toda su ayuda hasta ahora.

/ hito claro

@simplytunde También he comentado sobre los documentos PR. ¿Puede asegurarse de que también se elimine del hito 1,15?

Hola @ lachie83 @leblancd , soy el 1.16 Enhancement Shadow. ¿Esta característica va a graduar las etapas alfa / beta / estable en 1.16? Por favor, avíseme para que se pueda agregar a la hoja de cálculo de seguimiento 1.16 .

Las fechas de hitos son Enhancement Freeze el 30 de julio y Code Freeze el 29 de agosto.

Gracias.

https://github.com/kubernetes/dns/issues/315 cubre la adición de IPv6 / AAAA a la especificación de descubrimiento de servicios DNS .

@ lachie83 @leblancd alguna idea de si esto se va a graduar en 1.16 para seguirlo?

@ evillgenius75 @ kacole2 Esto necesita ser rastreado en 1.16. Esta función estará en estado alfa. Implementaremos la fase 1 y la fase 2 como se define en el KEP es 1.16

Seguimiento de KEP

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

K / k PR fusionados (actualmente en el maestro estará en 1.16)

• [FUSIONADO] Fase 1: https://github.com/kubernetes/kubernetes/pull/73977
• [FUSIONADO] Pruebas e2e de fase 1: https://github.com/kubernetes/kubernetes/pull/78801
• [FUSIONADO] Limpieza de la prueba de fase 1 e2e: https://github.com/kubernetes/kubernetes/pull/80001
• Servicios / puntos finales de la fase 2: https://github.com/kubernetes/kubernetes/pull/79386
• Kube-proxy de fase 2: https://github.com/kubernetes/kubernetes/pull/79576

RP asociados

• Soporte para IPv6 https://github.com/kubernetes-incubator/ip-masq-agent/pull/45
• Documentos de la fase 1: se volverá a abrir una vez que finalicemos los ejemplos de herramientas: https://github.com/kubernetes/website/pull/14600
• [FUSIONADO] limpieza - nodo dropDisabledFields - https://github.com/kubernetes/kubernetes/pull/79741
• Admite varios tamaños de máscara para sidras de clúster: https://github.com/kubernetes/kubernetes/pull/79993
• Trabajo de proa E2e para dualstack https://github.com/kubernetes/test-infra/pull/12966

Hola, @leblancd soy el líder de lanzamiento de documentos v1.16.

¿Esta mejora (o el trabajo planificado para v1.16) requiere algún documento nuevo (o modificaciones)?

Solo un recordatorio amistoso que estamos buscando un PR contra k / sitio web (sucursal dev-1.16) para el viernes 23 de agosto. Sería genial si es el comienzo de la documentación completa, pero incluso un PR de marcador de posición es aceptable. ¡Hazme saber si tienes alguna pregunta!

@simplytunde aquí está la documentación PR - https://github.com/kubernetes/website/pull/16010

La congelación del código recordatorio amigable de
Servicios de fase 2 / puntos finales - kubernetes / kubernetes # 79386
Fase 2 kube-proxy - kubernetes / kubernetes # 79576

Asociado:
Admite varios tamaños de máscara para sidras de clúster - kubernetes / kubernetes # 79993
Trabajo de proa E2e para kubernetes dualstack / test-infra # 12966

Hola @ lachie83 @leblancd , parece que https://github.com/kubernetes/kubernetes/pull/79576 y https://github.com/kubernetes/kubernetes/pull/79993 no se fusionaron antes de la congelación del código y no lo es en el Tide Merge Pool . Esta función se eliminará de la v1.16. Si aún desea que esto sea parte de la versión 1.16, presente una excepción.

@ kacole2 Disculpas por los retrasos en la respuesta. El PR principal donde se estaba rastreando fue https://github.com/kubernetes/kubernetes/pull/79386. En cuanto a kubernetes / kubernetes # 79576, tomamos la decisión de aplazarlo a 1.17 y, en su lugar, centrarnos en https://github.com/kubernetes/kubernetes/pull/82091 (de acuerdo con sig-network), que cumple los mismos objetivos de fase2 que se establecieron en el KEP. El otro PR relacionado que se rastreó en esta versión fue https://github.com/kubernetes/kubernetes/pull/80485 que también se fusionó. kubernetes / kubernetes # 79993 también se ha diferido a 1,17

Hola @ lachie83 @leblancd - 1.17 Las mejoras conducen aquí. Quería registrarme y ver si crees que esta Mejora se graduará en alfa / beta / estable en 1.17.

El calendario de lanzamiento actual es:

• Lunes 23 de septiembre: comienza el ciclo de lanzamiento
• Martes, 15 de octubre, EOD PST - Congelación de mejoras
• Jueves, 14 de noviembre, EOD PST - Code Freeze
• Martes 19 de noviembre: los documentos deben completarse y revisarse
• Lunes 9 de diciembre: lanzamiento de Kubernetes 1.17.0

Si lo hace, enumere todos los RP k / k relevantes en este número para que se puedan rastrear correctamente. 👍

¡Gracias!

/ hito claro

Hola Bob. Gracias por contactarnos. Todavía estoy planeando la fase 3 de esta mejora que completará la mejora hasta su finalización. Esta mejora seguirá estando en alfa al final de esta versión, pero habrá trabajo relacionado con la fase 3 que aterrizará en k / k como parte de 1.17.

Aquí hay una lista de entregables de alto nivel para 1.17 para doble pila. Actualizaré esta lista a lo largo del lanzamiento.

• Proxier de doble pila IPtables: https://github.com/kubernetes/kubernetes/pull/79576
• soporte de API descendente para Pod.Status.PodIPs - https://github.com/kubernetes/kubernetes/pull/83123
• e2e prueba un complemento CNI
• Cambios en el archivo de host (es necesario agregar la dirección IPv6 para el nombre de host / etc / hosts) - https://github.com/kubernetes/kubernetes/pull/83123
• Tipo de doble pila: https://github.com/kubernetes-sigs/kind/pull/692
• Actualización de la suite e2e - https://github.com/kubernetes/kubernetes/pull/80725
• Soporte de segmento de punto final
• Soporte de doble pila para Kubeadm: https://github.com/kubernetes/kubeadm/issues/1612

Muy apreciado, gracias amablemente @ lachie83 ❤️

/ hito v1.17

@mrbobbytables También agregué un PR para detallar el trabajo mencionado anteriormente como parte de la fase 3 en el KEP después de comunicar el plan a través de sig-network. El KEP en sí todavía se encuentra en el estado implementable y estos cambios simplemente documentan el trabajo planificado como parte de 1.17 específicamente.

En algún momento, me gustaría asegurarme de que https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ cubra el DNS IPv6. https://github.com/kubernetes/website/issues/15434 pistas que cambian; mencionándolo aquí para señalar una referencia cruzada.

KEP actualizado para agregar pruebas de fase 2 e2e - https://github.com/kubernetes/enhancements/pull/1311

Hola @ lachie83 , soy una de las sombras de documentos v1.17.
¿Esta mejora para (o el trabajo planeado para v1.17) requiere algún documento nuevo (o modificaciones a los documentos existentes)? Si no es así, ¿puede actualizar la hoja de seguimiento de mejoras 1.17 (o avíseme y lo haré)?

Si es así, solo un recordatorio amistoso de que estamos buscando un PR contra k / website (branch dev-1.17) que vence el viernes 8 de noviembre, puede ser un PR de marcador de posición en este momento. ¡Hazme saber si tienes alguna pregunta!

@ lachie83

Ya que nos acercamos a la fecha límite de relaciones públicas del marcador de posición de Docs el 8 de noviembre. Intente obtener uno en contra de la rama k / website dev-1.17.

Hola @ lachie83 , sé que estás pendiente, pero necesito aparecer y mencionarlo de todos modos 🙈
La congelación de código está a la vuelta de la esquina (14 de noviembre). ¿Cómo van las cosas? ¿Está todo en camino de fusionarse antes de esa fecha?

¡Gracias!

¡Hola @mrbobbytables! Gracias por el ping. Estamos rastreando los siguientes RP para aterrizar en 1.17. Puede haber uno o dos RP más asociados con este cambio que también entran. Estos cambios necesitarán documentos. Levantaré un marcador de posición docs PR

• Soporte de pila dual para el modo iptables kube-proxy pr / 82462
• Api descendente dualstack pr / 82462
• agregar ipvs metaproxier soporte de corte pr / 84089
• Permitir máscaras cidr de múltiples nodos en kube-controller-manager pr / 79993

@irvifa : aquí está el marcador de posición docs PR. https://github.com/kubernetes/website/pull/17457

Genial gracias 🎉 @ lachie83

@ lachie83 mañana es la congelación del código para el ciclo de lanzamiento 1.17. Parece que los k / k PR aún no se han fusionado. 😬 Lo marcamos como En riesgo en la hoja de seguimiento de mejoras 1.17.
¿Crees que se fusionarán con la EoD del 14 (jueves)? Después de ese punto, solo los problemas de bloqueo de versiones y los RP se permitirán en el hito con una excepción.

Gracias Bob. Hablaré de esto con sig-network hoy y proporcionaré una actualización.

Hola @mrbobbytables. Aquí hay una lista de RP en los que estamos trabajando para fusionarlos hoy con EoD y que han sido aprobados por sig-network.

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

Lo más probable es que el PR restante sea pateado a 1,18 - https://github.com/kubernetes/kubernetes/pull/82462

@mrbobbytables acaba de confirmar que todos los RP mencionados anteriormente se han fusionado y que de hecho vamos a despejar kubernetes / kubernetes # 82462 a 1.18. Esta mejora aún se puede rastrear ya que estos RP agregan cambios significativos al comportamiento de la pila dual en 1.17. ¡Ahora solo necesito preparar los documentos de relaciones públicas! Esperamos aterrizar kubernetes / kubernetes # 82462 en 1.18 y progresar este trabajo a beta

¡Genial, gracias @ lachie83!

¡Y está vivo! https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement/

Planeamos trasladar esta mejora a la versión beta en 1.18. Los criterios de graduación de mejora y los planes de prueba se pueden encontrar en el KEP junto con este PR: https://github.com/kubernetes/enhancements/pull/1429

/ hito 1,18

@ lachie83 : el hito proporcionado no es válido para este repositorio. Hitos en este repositorio: [ keps-beta , keps-ga , v1.17 , v1.18 , v1.19 , v1.20 , v1.21 ]

Utilice /milestone clear para borrar el hito.

/ hito v1.18

Planeamos trasladar esta mejora a la versión beta en 1.18. Los criterios de graduación de mejora y los planes de prueba se pueden encontrar en el KEP junto con este PR - # 1429

Gracias por la actualización @ lachie83 , he marcado esto como registrado en la hoja de cálculo 1.18.

Realice un seguimiento del siguiente PR como parte del trabajo para aterrizar en 1.18. https://github.com/kubernetes/kubernetes/pull/82462

Agregar otros RP relacionados para el seguimiento:
https://github.com/kubernetes/test-infra/pull/15893
https://github.com/kubernetes-sigs/kind/pull/692

¡Gracias @ lachie83!

Hola @ lachie83 , ¿tienes algún otro RP que debamos rastrear además de los mencionados anteriormente?

Hola, @ lachie83 @leblancd . Soy una sombra de Docs en el equipo de lanzamiento de la versión 1.18.

¿Este trabajo de mejora planificado para la versión 1.18 requiere algún documento nuevo o modificaciones a los documentos existentes?

Si no es así, ¿puede actualizar la hoja de seguimiento de mejoras 1.18 (o avíseme y lo haré)?

Si se requieren actualizaciones de documentos, recuerde que los PR de marcador de posición del sitio web k / (sucursal dev-1.18) vencen el viernes 28 de febrero.

¡Hazme saber si tienes alguna pregunta!

Si alguien quiere ayuda para documentar IPV6 o cosas de doble pila para v1.18, dame un empujón. Quizás pueda ayudar.

Hola @ lachie83 ,

Parece que kubernetes-sigs / kind # 692 aún no se ha fusionado. ¿Es eso fundamental para tu graduación Beta?

Hola @jeremyrickard @sethmccombs , vamos a tener que sacar esto de graduarnos a beta dado este PR https://github.com/kubernetes/kubernetes/pull/86895. Hasta que tengamos una forma razonable de avanzar, no creo que sea prudente pasar esto a la versión beta para 1.18

/ hito claro

@ lachie83 Gracias por la actualización. Eliminé esta mejora del hito. Esperando esto el 1.19. :)

Me gustaría confirmar que el estado de la mejora dualstack permanece en alpha en 1.18. Actualmente estoy trabajando con la comunidad para evaluar el trabajo que se planea completar en 1.19. Es probable que esta mejora aún permanezca en estado alfa en 1.19, sin embargo, me gustaría confirmarlo. También tomaré una acción para actualizar los documentos para reflejar el estado de mejora en los documentos 1.18.

Si hay páginas en el sitio web que muestran Kubernetes de doble pila como beta, archívelas contra k / website como errores de prioridad / important-soon.

Hola @ lachie83 - 1.19 Mejoras

El calendario de lanzamiento actual es:

• Lunes 13 de abril: Semana 1: comienza el ciclo de lanzamiento
• Martes 19 de mayo: Semana 6 - Congelación de mejoras
• Jueves 25 de junio: Semana 11 - Congelación de código
• Jueves 9 de julio: Semana 14: los documentos deben completarse y revisarse
• Martes 4 de agosto: semana 17: lanzamiento de Kubernetes v1.19.0

Si hay páginas en el sitio web que muestran Kubernetes de doble pila como beta, archívelas contra k / website como errores de prioridad / important-soon.

@sftim He planteado dos RP para abordar el etiquetado de lanzamiento en 1.17 y 1.18

@palnabarun Estamos trabajando para actualizar el dualstack KEP en el plazo de la versión 1.19, sin embargo, actualmente no creemos que vayamos a realizar cambios en el código de la versión 1.19. Tenemos un problema de bloqueo con el trabajo que ya se ha realizado (gracias a tenerlo en el estado alpha ). El problema de bloqueo es https://github.com/kubernetes/kubernetes/pull/86895. Planeamos abordar eso a través de la siguiente actualización de KEP https://github.com/kubernetes/enhancements/pull/1679, pero llevará tiempo lograr un consenso sobre el cambio propuesto. En esta etapa, la mejora dualstack permanecerá en el estado alpha hasta que abordemos este problema de bloqueo con la implementación actual. Proporcionaré actualizaciones a medida que avancen las cosas.

Gracias, Lachie por las actualizaciones. ¡Aprecio todos los esfuerzos! : leve_sonriente_cara:

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

/ remove-lifecycle stale

Nos gustaría que se realizara un seguimiento de esta mejora en 1.20. Se volverá a implementar en estado alfa de acuerdo con el kep actualizado: https://github.com/kubernetes/enhancements/pull/1679. Realice un seguimiento del siguiente PR para la implementación: https://github.com/kubernetes/kubernetes/pull/91824. Estamos planeando completar la revisión y fusionar el PR a principios del ciclo de lanzamiento 1.20.

Última graduación de doble pila al estado Beta como se discutió en la reunión de la Red SIG del 17 de septiembre, para aquellos que juegan en casa:

• Debe resolver la ambigüedad de la comprobación de estado de doble pila de kubelet; a través de https://github.com/kubernetes/enhancements/pull/1975
• Debe finalizar y fusionar el PR de servicios de doble pila existente (en revisión activa); a través de https://github.com/kubernetes/kubernetes/pull/91824
• Debe finalizar el comportamiento de las direcciones IP de nodo de doble pila; a través de https://github.com/kubernetes/enhancements/pull/1665
• Debe determinar qué cambios (si los hay) necesarios para el campo Spec.LoadBalancerIPs del servicio

Todos estos elementos se están trabajando activamente, y 1.20 sigue siendo el objetivo para la graduación de API Beta de doble pila. Sin embargo, a pesar de nuestros mejores esfuerzos, siempre existe la posibilidad de que algo no se resuelva a tiempo y, de ser así, SIG Network decidirá si continuar con la graduación a Beta o no en nuestras reuniones públicas. Todos son bienvenidos a unirse.

@dcbw muchas gracias por la actualización (lo siento, no pude hacer la llamada). ¿Tiene sentido llevar esto a la mejora de la versión beta en 1.20 o simplemente permanecer en alfa? Si queremos pasar a la versión beta, ¿los criterios de graduación en el KEP todavía tienen sentido dado que se trata de una reimplementación? Https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md # graduación -criterios

@dcbw muchas gracias por la actualización (lo siento, no pude hacer la llamada). ¿Tiene sentido llevar esto a la mejora de la versión beta en 1.20 o simplemente permanecer en alfa? Si queremos pasar a la versión beta, ¿los criterios de graduación en el KEP todavía tienen sentido dado que se trata de una reimplementación? Https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md # graduación -criterios

Sin embargo, no es realmente una reimplementación. Todo el trabajo anterior sigue siendo válido y el trabajo en 1.20 se está construyendo sobre él para finalizar los últimos cambios necesarios que se han identificado. Mi interpretación de la discusión de sig-network es que la lista que @dcbw publicó es el conjunto de problemas conocidos restantes que deben resolverse para la graduación.

Hola a todos,

1.20 Líder de mejoras aquí, voy a establecer esto como rastreado, por favor actualíceme si algo cambia :)

Como recordatorio, Enhancements Freeze es el 6 de octubre.

Como nota, el KEP está utilizando un formato antiguo que hemos actualizado a: https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

Mejor,
Kirsten

/ hito v1.20

Hola, @russellb -

Sin embargo, no es realmente una reimplementación. Todo el trabajo anterior sigue siendo válido y el trabajo en 1.20 se está construyendo sobre él para finalizar los últimos cambios necesarios que se han identificado.

Dados los cambios de API en https://github.com/kubernetes/kubernetes/pull/91824, es lo suficientemente diferente como para marcar la pila dual como alfa para 1.20 que dejará espacio para cualquier reimplementación adicional que resulte necesaria. Sé que todos estamos ansiosos por la versión beta, pero primero conectemos el PR con +9,319 −3,261 y dejemos que el polvo se asiente. :)

Dados los cambios de API en kubernetes / kubernetes # 91824 , es lo suficientemente diferente que marcar la pila dual como alfa para 1.20 permitirá espacio para cualquier reimplementación adicional que resulte necesaria. Sé que todos estamos ansiosos por la versión beta, pero primero conectemos el PR con +9,319 −3,261 y dejemos que el polvo se asiente. :)

@bridgetkromhout sí, necesitamos aterrizar https://github.com/kubernetes/kubernetes/pull/91824 antes de que podamos tomar alguna determinación sobre la preparación de la API. Realmente espero que podamos hacerlo lo antes posible.

Hola a todos,

1.20 Sombra de mejora aquí 👋

Dado que esta Mejora está programada para la versión 1.20, tenga en cuenta estas próximas fechas importantes:
Viernes 6 de noviembre: Semana 8 - Fecha límite de relaciones públicas del marcador de posición de Docs
Jueves, 12 de noviembre: Semana 9 - Congelación de código

Como recordatorio, vincule todas sus relaciones públicas de k / k, así como las relaciones públicas de los documentos, a este problema para que podamos rastrearlas.

¡Gracias!

Hola @kinarashah @kikisdeliveryservice : he confirmado en la llamada sig-network que necesitamos esto reclasificado a alfa para 1.20. Es una reimplementación completa que necesita tiempo para empaparse y probarse en la etapa alfa.

Hola @ lachie83 , 1.20 Docs shadow here.

¿Este trabajo de mejora planificado para la versión 1.20 requiere algún documento nuevo o modificación de los documentos existentes?

Si es así, siga los pasos aquí para abrir un PR contra la sucursal dev-1.20 en el repositorio k/website . Este PR puede ser solo un marcador de posición en este momento y debe crearse antes del 6 de noviembre .

También eche un vistazo a Documenting para una versión para familiarizarse con los requisitos de documentación para la versión.

¡Gracias!

Gracias @ reylejano-rxm - hemos abierto kubernetes / sitio web # 24725

Hola @ lachie83

¡Gracias por crear los documentos PR!

Tenga en cuenta las próximas fechas importantes:

• Viernes, 6 de noviembre: Semana 8 - Fecha límite de relaciones públicas de Docs Placeholder ¡HECHO!
• Jueves, 12 de noviembre: Semana 9 - Congelación de código
• Lunes 23 de noviembre: Semana 11 - Docs PR listo para revisión

Como recordatorio, vincule todas sus relaciones públicas de k / k, así como las relaciones públicas de los documentos, a este problema para que el equipo de lanzamiento realice un seguimiento.

Hola @kinarashah @kikisdeliveryservice : he confirmado en la llamada sig-network que necesitamos esto reclasificado a alfa para 1.20. Es una reimplementación completa que necesita tiempo para empaparse y probarse en la etapa alfa.

Hola @ lachie83

Dado lo anterior, supongo que esto todavía está destinado a alfa tal como está. No veo ningún RP pendiente que necesite fusionarse / el trabajo ya se fusionó.

_Sólo un recordatorio de que Code Freeze llegará en 2 días el jueves 12 de noviembre . Todos los RP deben fusionarse antes de esa fecha; de lo contrario, se requiere una excepción.

¡Gracias!
Kirsten

Hola, @kikisdeliveryservice : sí, el soporte de doble pila IPv4 / IPv6 (reimplementado) será alfa para 1.20.

Aquí está el progreso que tenemos para esta mejora:

1) El código se fusionó desde https://github.com/kubernetes/kubernetes/pull/91824 - será alfa para 1.20
2) Las actualizaciones de la documentación que cubren ese cambio de código se encuentran en https://github.com/kubernetes/website/pull/24725/ - revisadas y fusionadas en la rama dev-1.20

¿Se necesita algo más para 1.20 que no hayamos completado en esta mejora?

@bridgetkromhout Gracias por la clara actualización, ¡estás bien!

Parece que LoadBalancerIP en ServiceSpec no forma parte de la implementación de doble pila. ¿Hay algún plan para apoyarlo o me lo perdí?

Hola @chenwng : los cambios en el código del proveedor de nube para Loadbalancers están fuera del alcance actualmente, como se define en el KEP aquí: https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md # load -balancer-operation.

Puede ayudar proporcionando su caso de uso y cambios sugeridos para comprender y decidir si necesitamos realizar modificaciones en el KEP.

@chenwng Se está trabajando en un KEP por LoadBalancerIPs en clústeres de doble pila: https://github.com/kubernetes/enhancements/pull/1992

Gracias por la información, @aramase , @ lachie83 .