@enisoc @ dchen1107 @fejta @thockin @ kow3ns @derekwaynecarr , abrió este problema de seguimiento para que podamos discutir.

/asignar

@derekwaynecarr He realizado algunos análisis de los cambios de kubelet necesarios para la reunión de sig-node de la próxima semana, creo_ que los cambios solo son necesarios en el paquete kuberuntime , específicamente kuberuntime_manager.go in y kuberuntime_container.go .

En kuberuntime_manager.go puede modificar computePodActions para implementar la activación del apagado (matar los sidecars cuando todos los que no sean sidecars hayan salido permanentemente) y poner en marcha los sidecars primero.

En kuberuntime_container.go podría modificar killContainersWithSyncResult para terminar los sidecars en último lugar y enviar los ganchos preStop (el bit de ganchos preStop fue un poco discutible, no se resolvió si eso debería hacerse o no. @ Thockin tuvo un buen punto sobre por qué es posible que no desee fomentar ese comportamiento, consulte el comentario ).

Avísame si quieres que investigue más.

@ kow3ns La discusión tiene más sentido para mí si tal vez podamos definir una descripción completa de la secuencia de contenedores en la especificación de Pod (sig-app), y cómo manejar la secuencia en kubelet para comenzar, reiniciar y considerar en cascada (sig-node). Veamos la reunión de sig-nodos del 5 de febrero para dar más aportes.

cc @ Joseph-Irving

La propuesta dice que los sidecars solo se ejecutan después de que se ejecutan los contenedores init. Pero, ¿qué pasa si el caso de uso requiere que el sidecar se ejecute mientras / antes de que se ejecuten los contenedores de inicio? Por ejemplo, si desea enrutar el tráfico del pod a través de un proxy que se ejecuta como sidecar (como en Istio), probablemente desee que ese proxy esté en su lugar mientras se ejecutan los contenedores de inicio en caso de que el contenedor de inicio realice llamadas de red.

@luksa Creo que existe la posibilidad de tener sidecars que se ejecuten en la fase de inicio en algún momento, pero actualmente la propuesta no cubrirá ese caso de uso. Actualmente no hay forma de tener contenedores concurrentes ejecutándose en la fase de inicio, por lo que sería potencialmente un cambio mucho más grande / complicado de lo que se sugiere aquí.

Actualización sobre este KEP:
Hablé con @ dchen1107 de sig-node sobre esto y no expresaron ninguna preocupación importante sobre la propuesta. Le plantearé un RP al KEP agregando algunas notas iniciales sobre los detalles de implementación y aclarando algunos puntos que surgieron durante la discusión.

Todavía tenemos que estar de acuerdo con la API, parece que hay consenso en que se prefiere una forma simple de marcar contenedores como sidecars a las banderas de pedidos más detallados. Sin embargo, tener un bool es algo limitante, por lo que quizás sea preferible algo más en la línea de containerLifecycle: Sidecar para que tengamos la opción de expandirnos en el futuro.

@ Joseph-Irving En realidad, ni el booleano ni el containerLifecycle: Sidecar son apropiados para una futura extensibilidad adecuada. En cambio, containerLifecycle debería ser un objeto, como deployment.spec.strategy , con type: Sidecar . Esto nos permitiría luego introducir campos adicionales. En el caso de la solución "sidecar durante toda la vida útil del módulo", se expresaría de la siguiente manera:

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: CompletePodLifetime

Opuesto a

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: AfterInit

Por favor, perdone mi mala denominación, espero que los nombres transmitan la idea.

Pero hay un problema con el enfoque en el que introducimos containerLifecycle en pod.spec.containers . Es decir, es incorrecto tener sidecars que se ejecuten en paralelo a los contenedores de inicio especificados en pod.spec.containers . Entonces, si realmente desea poder extender esto a los contenedores de inicio eventualmente, debe encontrar una solución alternativa, una que le permita marcar los contenedores como sidecars en un nivel superior, es decir, no por debajo de pod.spec.containers o pod.spec.initContainers , pero algo como pod.spec.sidecarContainers , que creo que ya lo discutiste, pero lo descartaste. El problema de los contenedores init definitivamente requiere una solución en este sentido.

@luksa También puede resolver el problema de init simplemente permitiendo que un contenedor de inicio se marque como un sidecar y que se ejecute junto con los contenedores de inicio. Según tengo entendido, el problema es que los contenedores de inicio a veces necesitan sidecars, que es diferente de necesitar un contenedor que se ejecute durante toda la vida útil del pod.

El problema con pod.spec.sidecarContainers es que es un cambio mucho más complejo, las herramientas deberían actualizarse y el kubelet requeriría muchas modificaciones para admitir otro conjunto de contenedores. La propuesta actual es mucho más modesta, solo se basa en lo que ya existe.

@ Joseph-Irving Podríamos trabajar con ese sí. No es ideal que el sidecar se apague después de que se ejecuten los contenedores de inicio y luego vuelva a iniciar el mismo sidecar, pero es mejor que no tener esa opción. El mayor problema es que los Kubelets más antiguos no manejarían correctamente los contenedores init-sidecar (como es el caso de los contenedores main-sidecar).

Me gustaría que tuvieras en cuenta los init-sidecars al finalizar la propuesta. En esencia, está introduciendo el concepto de "sidecar" en k8s (anteriormente, básicamente solo teníamos un conjunto de contenedores que eran todos iguales). Ahora está presentando sidecars reales, así que en mi humilde opinión, realmente debería pensar esto a fondo y no descartar un caso de uso de sidecar muy importante.

Me complacerá ayudarlo a implementar esto. Sin él, Istio no puede proporcionar sus características para los contenedores de inicio (de hecho, en un clúster de Kubernetes debidamente protegido que ejecuta Istio, los contenedores de inicio pierden por completo la capacidad de comunicarse con _cualquier_ servicio).

En relación con la discusión de implementación en https://github.com/kubernetes/enhancements/pull/841 , abrí un WIP PR que contiene un PoC básico para esta propuesta https://github.com/kubernetes/kubernetes/pull / 75099. Es solo un primer borrador y obviamente no es perfecto, pero la funcionalidad básica funciona y le da una idea de la cantidad de cambio requerido.

cc @enisoc

Reuní un video corto que muestra cómo se comporta actualmente el PoC https://youtu.be/4hC8t6_8bTs. Verlo en acción puede ser mejor que leer sobre él.
Descargo de responsabilidad: no soy un youtuber profesional.

Abrí dos nuevos RP:

• https://github.com/kubernetes/enhancements/pull/918 trata sobre los criterios de graduación, sesgo de versión, actualización / degradación
• https://github.com/kubernetes/enhancements/pull/919 es decidir sobre la implementación de la API

Cualquier pensamiento o sugerencia será muy apreciado.

@ Joseph-Irving Lo siento si estoy comentando al final del proceso de diseño, pero tengo un caso de uso potencial para contenedores sidecar que pueden no ser compatibles con la propuesta de diseño actual. Solo quería plantearlo para su consideración. La esencia es que tengo un escenario en el que en la terminación de la vaina, 1 sidecar debe terminarse antes que el contenedor principal, mientras que otro sidecar debe terminarse después del contenedor principal.

Un ejemplo concreto podría ser un pod con un contenedor de aplicaciones Django, un sidecar de cónsul para el registro del servicio y un sidecar de pgbouncer para administrar las conexiones a la base de datos. Cuando se termina el pod, me gustaría que el sidecar cónsul se detenga primero (para que no se dirija más tráfico al pod), luego el contenedor de la aplicación (idealmente después de un breve período de gracia) y luego el sidecar pgbouncer. La propuesta actual se ve muy bien para manejar la dependencia del contenedor de la aplicación <-> pgbouncer, pero no parece lo suficientemente expresiva como para capturar el caso en el que me gustaría derribar un sidecar _antes_ del contenedor principal.

@currankaushik , en el escenario que describió, podría usar un gancho previo a la parada para decirle al contenedor del cónsul que se prepare para el apagado y deje de enviarle solicitudes (asumiendo que puede admitir algo así). Los ganchos de parada previa se enviarán a los sidecares primero antes de que comience la terminación de los contenedores.

La motivación para esto fue para que los sidecars proxy como istio pudieran ingresar a un estado en el que no enrutan el tráfico hacia usted, pero aún permiten que el tráfico salga mientras la aplicación finaliza y se apaga.

Suena bien, gracias @ Joseph-Irving. Entonces, solo para confirmar mi comprensión a un alto nivel: los ganchos de pre-parada se enviarán primero a los sidecars, seguidos de los ganchos de pre-parada a los no sidecars, SIGTERM a los no sidecars, y luego (después de que todos los no sidecars hayan salido ) ¿SIGTERM a sidecars? La propuesta de diseño (https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md) parece implicar esto pero también dice:

Los PreStop Hooks se enviarán a sidecars y contenedores al mismo tiempo.

@currankaushik sí, lo que describiste es el comportamiento previsto.

Esa línea que citó necesita una nueva redacción. Tenía algunos conceptos erróneos sobre cómo se enviaban los ganchos de parada previa a los contenedores cuando escribí eso. Gracias por mencionarlo.

@ Joseph-Irving, ¿esta función tiene como objetivo la inclusión alfa para 1,15?

@ kacole2 sí, ese es el plan, asumiendo que podemos lograr que el KEP se pueda implementar a tiempo para la congelación de las mejoras (30 de abril). Una vez finalizada la API https://github.com/kubernetes/enhancements/pull/919 y el plan de prueba acordado https://github.com/kubernetes/enhancements/pull/951 , creo que deberíamos estar listos.

/ hito v1.15
/ etapa alfa

@ Joseph-Irving Kubernetes 1.15 Enhancement Freeze es el 30/4/2019. Para ser incluidos en el hito Kubernetes 1.15, los KEP deben estar en un estado "Implementable" con planes de prueba y criterios de graduación adecuados. Envíe los RP necesarios para que este KEP se adhiera a los criterios de inclusión. Si esto se aleja del hito de 1,15, háganoslo saber para que podamos realizar los cambios de seguimiento adecuados.

@mrbobbytables desafortunadamente, los RP abiertos para llevar esto a un estado implementable no han tenido mucho movimiento, así que creo que tendremos que retrasar esto hasta la 1.16.

No hay problema. ¡Gracias por responder tan rápido y hacérnoslo saber!
/ hito claro

¡Tenga en cuenta que este KEP es muy importante para Istio!

Es un obstáculo para todos los proyectos que utilizan marcos de servicio con bootstrap / shutdown coordinados (akka cluster, lagom, etc.) junto con istio service mesh ver .

cc @jroper

@ Joseph-Irving sry sobre el comentario tardío, pero no veo lo siguiente en el documento de diseño, y me preguntaba cuál es el comportamiento previsto de estos:

Si vemos una falla en el sidecar, ¿los reiniciamos siempre si el contenedor principal no está terminado (sin tener en cuenta la política de reinicio en el pod)? Esto sería útil ya que el sidecar se usa para funcionar como proxy, balanceo de carga, función de mantenimiento, y no importa si falla un par de veces, siempre que el contenedor principal pueda continuar funcionando.

Además, al calcular la fase de pod, si todo el contenedor principal tuvo éxito y el sidecar falló (lo cual es muy común, ya que si el sidecar no detecta SIGTERM, el código de retorno será como 143 o algo así), ¿la fase de pod sigue siendo "exitosa"?

@ zhan849 actualmente, los contenedores de sidecar obedecen la política de reinicio de pod y se cuentan al calcular la fase del pod como Succeeded .

Debatimos esto un poco antes en el proceso, pero la sensación general fue que deberíamos divergir de un contenedor normal lo menos posible, solo haciéndolo si habilita los casos de uso descritos.

Con respecto a la fase de pod: Yo diría que todas las aplicaciones que se ejecutan en kubernetes deberían manejar SIGTERM (especialmente sidecars), pero también a veces querrá saber si sus sidecars salieron de mala manera y eso debería reflejarse en la fase de pod. ocultar esa información podría generar confusión.

Para la política de reinicio, solo parece que eso sería un problema si la política de reinicio nunca lo es y su sidecar es propenso a fallar. No estoy seguro de que valga la pena la complicación de apartarlos de la política de reinicio de pod, especialmente porque algunas personas pueden querer que sus sidecares obedezcan la política de reinicio de pod.

Ambas cosas están en línea con lo que hace un contenedor normal y lo que sucede actualmente.
Cambiarlos no parecía ser necesario para lograr los objetivos enumerados en el Kep.

Si tiene algunos casos de uso generalizados de por qué es necesario cambiarlos para lograr esos objetivos, sería útil. Ya que facilita la justificación de un cambio más complicado en la base del código.

@ Joseph-Irving tenemos algunas implicaciones de sidecar más simples que se han estado ejecutando internamente para algunas necesidades inmediatas (no contribuimos porque esto ya está en progreso en la comunidad), y esto es lo que aprendimos.

Respecto a la fase de vaina:

1. El estado del contenedor ya está reflejado en pod.status.containerStatuses por lo que no perdemos la información. Además, dado que un gran caso de uso de sidecar se encuentra en Job (o en los pods de ejecución hasta el final, como los de Kubeflow), las cargas de trabajo significativas se aplicarán solo al contenedor principal y si la fase del pod está marcada como Fallida debido a una falla del sidecar. , dará lugar a reintentos innecesarios y dará lugar a otras consecuencias engañosas, como error en el trabajo, etc.

2. Aunque es ideal para que los sidecares manejen SIGTERM, en producción, podría haber muchos sidecars que simplemente se construyen sobre software de código abierto y no manejan bien los SIGTERM, incluidos kube-proxy , postfix , rsyslogd , y muchos otros (e incluso si se maneja SIGTERM, para SIGKILL no capturable, seguramente no será 0)

Con respecto a la política de reinicio (podría ser discutible, pero los sidecars obedecen estrictamente a restartPolicy no es realista en producción):

1. Forzar el reinicio del sidecar cuando los contenedores principales aún se están ejecutando al configurar "OnFailure" no es una opción, ya que esto reiniciará los contenedores principales fallidos y es confuso junto con el límite de reintentos de nivel de trabajo.

2. Por lo general, cuando se manejan sidecar, los contenedores principales suelen tener muchas lógicas de reintento para sidecar no disponibles, y esto se realiza antes de que la comunidad tenga soporte para sidecar con orden explícita de inicio del contenedor. Este tipo de manejo de errores históricos no es muy fácil de cambiar dado su alcance. No reiniciar el sidecar hará que los contenedores principales se cuelguen y vuelvan a intentar

3. La propagación de fallas a los controladores de nivel superior desencadenará cadenas de reconciliación y muchas llamadas a la API, por lo que la escalada innecesaria de errores puede hacer que Kubernetes sea menos escalable.
   Un ejemplo más específico: si los contenedores principales de un trabajo aún se están ejecutando y el sidecar falla, el reinicio del sidecar tendrá solo 1 operación de estado del pod PATCH y como máximo 1 llamada a la API relacionada con el evento. Pero si fallar el pod por completo resultará en la reconciliación del trabajo y más controladores de nivel de contratación como CronJob y otros CRD, y podría haber muchas más llamadas a la API.

quiero ver también si otras personas han visto problemas similares (/ cc @ kow3ns )

¿Incorporaría este cambio el comportamiento deseado en https://github.com/kubernetes/community/pull/2342 , de modo que habría una forma de configurar todo el pod (o solo el contenedor sin sidecar) para reiniciar si un sidecar falla?

@JacobHenner actualmente no hay planes para implementar ese tipo de mecanismo en este KEP, discutimos su incorporación, pero realmente no tiene mucha dependencia de este KEP y podría desarrollarse independientemente de esto. Por tanto, parece más adecuado para tener su propio KEP.

@ Joseph-Irving solo para compartir nuestra implicación que abordó los escollos mencionados anteriormente para su referencia (https://github.com/zhan849/kubernetes/commits/kubelet-sidecar) ya que nuestro objetivo es esperar el soporte oficial, lo intentamos para mantener el cambio lo más local posible en este compromiso.

así que para una política de reinicio del trabajo == Nunca, con 1 contenedor principal, 1 sidecar malo que se bloquea constantemente, 1 sidecar bueno que sigue funcionando, el estado del pod se verá así después de que el contenedor principal se cierre con la implicación anterior.

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"

En general, estoy de acuerdo en que un KEP de sidecar debe tener en cuenta la fase de pod y la política de reinicio antes de que pueda pasar a un estado implementable. No me importa si es este KEP o no, pero estoy de acuerdo en general con los argumentos de @ zhan849 y debe tratarse aquí.

gracias @smarterclayton !
@ Joseph-Irving háganos saber si hay algo más que le gustaría que compartiéramos con sidecar en la práctica.

@smarterclayton @ zhan849 , no estoy particularmente en desacuerdo con los puntos que haces, solo trato de dar algunos contrapuntos. Fue una elección consciente no cambiar las Fases del módulo / la política de reinicio, ya que eso aumentaría aún más el alcance de esta propuesta y nadie se sintió muy convencido al respecto.

Llevaré estos comentarios a sig-apps / sig-node y veré qué piensan. sig-node en particular estaba interesado en mantener los sidecars lo más cerca posible de los contenedores normales, si @derekwaynecarr o @ dchen1107 quieren

El plan de prueba https://github.com/kubernetes/enhancements/pull/951 y el diseño de API https://github.com/kubernetes/enhancements/pull/919 PR ahora se han fusionado.

Abrí https://github.com/kubernetes/enhancements/pull/1109 para marcar el KEP como implementable, una vez que todos estén contentos con eso, deberíamos poder comenzar el desarrollo para esto como alfa en 1.16 🤞

¡Este Kep se ha marcado como implementable, por lo que aumentaré los PR para que esto sea 1.16 a partir de la próxima semana!

He planteado https://github.com/kubernetes/kubernetes/pull/79649 para implementar la API, tendré un PR separado para los cambios de Kubelet.

Hola @ Joseph-Irving, soy el líder de mejora 1.16. ¿Esta función 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 . Si no se está graduando, lo eliminaré del hito y cambiaré la etiqueta de seguimiento.

Una vez que comience la codificación o si ya lo ha hecho, enumere todos los RP k / k relevantes en este número para que se puedan rastrear correctamente.

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

Gracias.

@ Joseph-Irving Si quiere / necesita gente adicional para implementar esto, tengo mucho interés en este aterrizaje, así que estoy feliz de echar una mano.

Hola @ kacole2, esto apunta a Alpha para 1.16, el KEP se ha marcado como implementable.
El único RP para esto actualmente es kubernetes / kubernetes # 79649 para la API

@mhuxtable Subiré el PR para los cambios de kubelet bastante pronto, acabando de terminar algunas cosas, agradecería mucho ayuda para echar un vistazo a eso. Lo vincularé aquí cuando se plantee.

Abrí https://github.com/kubernetes/kubernetes/pull/80744 que implementa los cambios de kubelet.

Tenga en cuenta que kubernetes / kubernetes # 79649 (api) todavía está abierto, por lo que este PR contiene confirmaciones de él, lo que lo hace parecer grande. Lo he dividido en confirmaciones de que cada uno implementa una funcionalidad diferente, por lo que debería ser fácil revisarlo de esa manera.

No he terminado de hacer todos los casos de prueba para esto, pero el primer borrador de la implementación de trabajo está hecho, así que me gustaría que la gente echara un vistazo.

cc @ kacole2

@ Joseph-Irving

Soy una de las sombras de documentos v1.16.
¿Esta mejora (o el trabajo planificado para la v1.16) requiere algún documento nuevo (o modificaciones a los documentos existentes)? Si no es así, ¿puede actualizar la hoja de seguimiento de mejoras 1.16 (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.16) que vence el viernes 23 de agosto, puede ser un PR de marcador de posición en este momento. ¡Hazme saber si tienes alguna pregunta!

Hola @daminisatya , sí, esto necesitará actualizaciones de Docs, he mencionado https://github.com/kubernetes/website/pull/15693 como un marcador de posición de relaciones públicas.
Me interesaría saber si alguien tiene alguna opinión sobre dónde deberían ir los Documentos, he puesto algo en content/en/docs/concepts/workloads/pods/pod-lifecycle.md por ahora.

Con menos de una semana antes de Code Freeze, parece muy poco probable que esto pueda llegar a 1.16.
Todavía tenemos dos RP abiertos relativamente grandes, kubernetes / kubernetes # 80744 y kubernetes / kubernetes # 79649, que han tenido problemas para obtener revisiones.
Con suerte, habrá más ancho de banda de revisor en el próximo ciclo de lanzamiento para verlos.

/asignar

¿Podría esto permitir escribir un sidecar que pueda iniciar el servicio real a pedido (y destruirlo)?

Como escalar a cero, pero lo único que se ejecuta mientras está inactivo es el sidecar. Cuando llega una solicitud, activa el servicio real y después de una última respuesta, por ejemplo, 30 segundos, lo cerrará. Esto podría permitir una forma sencilla de escalar a casi cero (con solo sidecars en funcionamiento).

@Ciantic Con Operator Framework puedes hacer eso y mucho más. Echar un vistazo

@janosroden Miré, pero parece bastante difícil de entender cómo elevaría los servicios en ejecución a cero escalables.

El problema no es que no haya opciones disponibles, por ejemplo, Osiris , Keda o knative . Probé el último, pero ocupa 8 Gb de memoria, es difícil decir que es 'sin servidor' en ese momento.

El problema es que la mayoría de esas implementaciones necesitan nuevos recursos, etc.es mucho más fácil pensar esto para que uno pueda inyectar un sidecar que pueda controlar todo el ciclo de vida (incluido el inicio y reinicio bajo demanda) para que pueda controlar el servicio más allá de solo sentado allí.

¿Por qué sería beneficioso esto? Es realmente útil en situaciones de poca utilización y poca memoria, por ejemplo, k3s con Raspberry Pi o Digital Ocean droplet para proyectos de hobby. Muchos de nosotros tenemos muchos servicios web que no necesitan estar ejecutándose todo el tiempo, basta con tener un sidecar que pueda activarlos a pedido.

No estoy seguro de que esto realmente funcione para su caso de uso. Veo totalmente el deseo de hacer lo que quiere hacer en estos sistemas con recursos limitados. Pero para ser realmente estable, necesita usar solicitudes de recursos para ayudar a programar la carga de trabajo. Estos deberían especificarse por adelantado, por lo que independientemente de si la carga de trabajo se está ejecutando o no, debería reservar el recurso.

Para solucionar esto, necesita un módulo propio para realizar la recepción de conexión inicial y realizar una nueva solicitud de módulo a k8s, esperar a que se active y luego enviar el tráfico. En este caso, creo que no se necesitan mejoras en el contenedor del sidecar. Creo que necesitas algo más como un xinetd para k8s.

Hola @ Joseph-Irving: 1.17 Las mejoras conducen aquí. Quería registrarme y ver si crees que esta Mejora se graduará en alfa 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, una vez que comience la codificación, enumere todos los RP k / k relevantes en este número para que se puedan rastrear correctamente. 👍

¡Gracias!

Hola @mrbobbytables , suponiendo que podamos revisar todo a tiempo, el plan es pasar a alfa en 1.17.

Los RP abiertos actuales son:
https://github.com/kubernetes/kubernetes/pull/79649 - Cambios en la API
https://github.com/kubernetes/kubernetes/pull/80744 - Cambios de Kubelet

¡Déjame saber si necesitas algo más!

¡Excelente! Gracias @ Joseph-Irving Agregaré la información a la hoja de seguimiento 👍

@ Joseph-Irving

Soy una de las sombras de documentos v1.17.
¿Esta mejora (o el trabajo planificado para la 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!

¡Gracias!

Hola @ VineethReddy02, sí, esto requerirá documentación, el marcador de posición PR está aquí https://github.com/kubernetes/website/pull/17190

He planteado un PR para actualizar el KEP https://github.com/kubernetes/enhancements/pull/1344; se basa en una discusión que tuvimos en el PR de implementación https://github.com/kubernetes/kubernetes/pull / 80744.

Agradecería cualquier comentario

¡Hola, @ Joseph-Irving 1.17 Sombra de mejora aquí! 👋 Me estoy comunicando con usted para ver cómo va esta mejora.

El equipo de Mejoras actualmente está rastreando kubernetes / kubernetes # 79649 y kubernetes / kubernetes # 80744 en la hoja de seguimiento. ¿Hay otras RP de k / k que deban ser rastreadas también?

Además, otro recordatorio amistoso de que nos estamos acercando rápidamente a la congelación de código (14 de noviembre).

Hola @annajung , sí, esos son los únicos RP que necesitan seguimiento.

Hola @ Joseph-Irving, Mañana se congelará el código para el ciclo de lanzamiento de 1.17 . Parece que los k / k PR no se han fusionado. Marcamos esta mejora como At Risk en la hoja de seguimiento 1.17.

¿Crees que todos los RP necesarios serán fusionados por el EoD del 14 (jueves)? Después de eso, solo se permitirán problemas de bloqueo de versiones y RP en el hito con una excepción.

Hola @annajung , desafortunadamente, parece muy poco probable que se fusionen antes de la congelación del código. Hemos progresado mucho en este ciclo de lanzamiento, por lo que es de esperar que podamos fusionarlos antes en la versión 1.18.

Hola @ Joseph-Irving Gracias por la actualización. Actualizaré el hito en consecuencia y marcaré esta mejora como diferida a 1.18. ¡Gracias!

/ hito v1.18

Hola @ Joseph-Irving. 1.18 Mejoras Lidera aquí 👋.

La versión 1.18 comenzó ayer, así que me acerco para ver si planeas conseguir esto en la versión 1.18. Creo que esto pasó por alto 1.17 debido a la congelación del código. ¿Cómo van las cosas para 1,18? Veo que los RP aún están abiertos.

¡Gracias!

Hola @jeremyrickard ,

Sí, el plan es conseguir esto en la versión 1.18.

El API PR (https://github.com/kubernetes/kubernetes/pull/79649) recibió una revisión de thockin, el otro día, tenía algunos puntos, pero una vez que se abordan, cerraremos ese PR e incorporaremos los compromisos en (https://github.com/kubernetes/kubernetes/pull/80744) para que podamos fusionar la API y la implementación.

En cuanto a Kubelet PR (https://github.com/kubernetes/kubernetes/pull/80744), solo necesita revisión, espero que podamos obtener algo de ancho de banda sig-node para revisarlo este ciclo.

Gracias por la actualización @ Joseph-Irving

¡Agregado a la hoja de seguimiento!

Perdón por llegar tarde a la fiesta. Esta es una mejora significativa para casos comunes. Pero no parece abarcar un caso más avanzado.

Considere un caso de sidecar que exporta registros que también depende del sidecar de Istio. Si el sidecar de Istio se apaga primero, es posible que algunos registros confidenciales no se exporten.

Un enfoque más genérico sería definir dependencias explícitas entre contenedores. Independientemente de si son sidecars o no.

¿Qué piensas de dicha definición de api en su lugar:

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

@rubenhak que se

@ kfox1111 ¿Cómo determina el diseño propuesto que el sidecar está iniciado y listo para lanzar el contenedor principal? La única diferencia que propongo es que en lugar de marcar los contenedores como "sidecar" es usar una forma más genérica de definir la dependencia.

No creo que dependOn deba especificar criterios. Podría especificarse en el contenedor dependiente. ¿No serían suficientes readinessProbe y / o livenessProbe ? De lo contrario, puede haber una startupProbe ,

Hola @ Joseph-Irving, soy una de las sombras de documentos v1.18.
¿Esta mejora para (o el trabajo planeado para v1.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 es así, solo un recordatorio amistoso de que estamos buscando un PR contra k / website (branch dev-1.18) que vence el viernes 28 de febrero. Puede ser un PR de marcador de posición en este momento. ¡Hazme saber si tienes alguna pregunta!

Hola @irvifa , he creado un marcador de posición de relaciones públicas aquí https://github.com/kubernetes/website/pull/19046

Hola @ Joseph-Irving ¡Gracias por tu rápida respuesta!

@rubenhak : estoy de acuerdo con @ kfox1111 en que tener un gráfico completo de dependencias puede complicarse bastante rápidamente. ¿Qué hay de comenzar los contenedores en el orden en la especificación de la vaina y luego derribarlos en el orden inverso (como una pila)? Esto sería mucho más sencillo de implementar y cubre la mayoría de los casos de uso de pedidos comunes que se me ocurren.

@rgulewich , ¿podrías explicar un poco más, qué es exactamente lo que puede ensuciarse? Derivar el orden a partir del gráfico es una tarea trivial, especialmente si se considera el hecho de que ningún operador en su sano juicio ejecutaría más de 15 sidecars (ya un tramo).

La idea del orden está bien, pero dado que la mayoría de los sidecars se inyectan mediante controladores de admisión, sería muy difícil garantizar la corrección del orden. Existe la necesidad de una indirecta.

@rubenhak podría haber un ciclo en el orden de dependencia de los contenedores, ¿cómo decide k8s / kubelet romper el ciclo y decidir en qué orden iniciar / detener los contenedores? Pensando en voz alta, tal vez esto podría ser una validación del lado de la API.

Hola @ Joseph-Irving,

Solo un recordatorio amistoso de que el código congelado para 1.18 es el 5 de marzo de 2020 .

A medida que avanzamos hacia la congelación del código, enumere / enlace a cualquier RP en el que esté trabajando para graduar esta mejora.

Hola @jeremyrickard ,

¿Es el PR para rastrear https://github.com/kubernetes/kubernetes/pull/80744
Este PR contiene cambios en la API, pero las confirmaciones se fusionarán con el PR anterior una vez que la revisión haya finalizado https://github.com/kubernetes/kubernetes/pull/79649

@rubenhak podría haber un ciclo en el orden de dependencia de los contenedores, ¿cómo decide k8s / kubelet romper el ciclo y decidir en qué orden iniciar / detener los contenedores? Pensando en voz alta, tal vez esto podría ser una validación del lado de la API.

@bjhaid , el lado de la API puede hacer la validación. La detección de bucles es un algoritmo trivial con una complejidad de tiempo lineal (como el recorrido DFS).

También puede ser necesario volver a ejecutar la validación después de la inyección del sidecar.

He estado pensando en esto por un tiempo ... La mayoría de los problemas con las dependencias realmente se reducen, creo, a las mallas de servicio. (aunque tal vez alguien pueda pensar en otro ejemplo)

El proxy de malla de servicio es un sidecar que debe iniciarse y estar listo antes que nada, y debe salir después de cualquier otra cosa. Son de larga duración, por lo que son más un sidecar que un contenedor de inicio.

Pero initContainers idealmente debería poder usar la malla de servicio también.

Pero initContainers puede necesitar iniciar otros contenedores sidecar.

Si bien podríamos diseñar algún tipo de sistema de dependencia intrincado que involucre contenedores init, contenedores sidecar y contenedores regulares, ¿tal vez deberíamos tener solo dos clases de sidecars? sidecars regulares y sidecars de red?

Los sidecars de red deben estar listos desde el principio. los proxies de malla de servicio van aquí.
Los contenedores init se ejecutan a continuación en orden.
todos los sidecars arrancan y se preparan. Esto puede incluir cosas como proxies de autenticación, registradores, etc.
Los contenedores regulares comienzan y se preparan.

derribar es al revés.

¿Eliminaría esto el problema de la dependencia sin dejar de resolver todos los problemas que parecen tener las mallas de servicio con el pedido de contenedores? Lo estoy pensando

@ kfox1111 , Vault ahora hace una inyección secreta usando sidecars. ¿En qué clase debería encajar? Además, dependiendo del caso, la bóveda podría depender de la malla de servicio o al revés.

Todo lo que digo es que tal diseño eventualmente explotaría en 10 clases de sidecar. Tal enfoque implica una opinión aún más fuerte sobre cómo deberían funcionar las cosas. La gente comenzaría a piratear con clases, solo para lograr el orden requerido para iniciar la aplicación.

Si el único propósito de esas clases es definir el orden, ¿por qué no hacerlo explícitamente?

Respondiendo a su pregunta, si bien dicho diseño cubriría algunos casos de uso, no ayuda con otros casos como sidecars de bóveda, sidecars de registro, etc. Esta ya es una propuesta para el rediseño de la característica original. Dado que este es un segundo intento, vale la pena hacerlo bien esta vez.

No sé cómo las dependencias son intrincadas. ¿Podría dar más detalles sobre esto? Las dependencias hacen que las definiciones de YAML sean más obvias, no hay una lógica oculta. El enfoque con clases codificadas requeriría una lógica oculta y mucha más documentación que explique por qué los sidecars de red deberían ejecutarse después de otros sidecars, etc.

¿Qué pasa si introducimos un campo en Container?

    // +optional
    Priority int

Este campo es efectivo entre contenedores del mismo tipo (sidecar, normal).
Para los contenedores con sidecar, el contenedor con sidecar con mayor prioridad se instanciaría primero / se derribaría al final.

@tedyu , la dependencia tiene muchos más metadatos y valor en comparación con la "prioridad". Se necesitan 30 líneas de código C ++ para producir un orden de prioridad dada la dependencia https://www.geeksforgeeks.org/find-the-ordering-of-tasks-from-given-dependencies/ . No es posible al revés.

Otro beneficio es que, dado el gráfico de dependencia, ciertos contenedores se pueden iniciar al mismo tiempo.
En el siguiente ejemplo: "A -> B, B -> C, D -> C", los contenedores B y D pueden iniciarse al mismo tiempo si C está inicializado. No estoy diciendo que la implementación tenga que soportar eso, pero al menos puede ser muy valioso si la API permite tal definición.

La prioridad entera no funcionará bien: las personas usarán todo tipo de números diferentes y no estandarizados como lo hacen con la propiedad de índice z de CSS (como -9999 ).

@rubenhak Lo que estás sugiriendo en este punto es básicamente una característica completamente diferente a la que se describe en este KEP, no es un pequeño ajuste, es una reescritura total. Sería necesario que todos los que habían aceptado previamente esta función (se necesitaron un año para que todas las partes la aprobaran) la reevaluaran.
Si le apasiona esta función, le sugiero que cree su propio KEP y lo lleve a los diversos SIG para obtener sus comentarios al respecto.

La idea de un gráfico de dependencia se discutió extensamente cuando esta propuesta comenzó en 2018, la conclusión fue unánime en que, aunque permitiría algunos casos de uso más, no eran casos de uso lo suficientemente fuertes y que la complejidad adicional no valía la pena.

Creo que está subestimando un poco el grado de cambio necesario para implementar lo que está describiendo. Pero si es tan simple como parece pensar, puede crear su propia Prueba de concepto de este trabajo en Kubernetes y presentarla a los SIG para ayudar a fortalecer su caso.

Este KEP aún no es una función de GA, si su KEP se aprueba e implementa, podemos eliminarlo. Todavía no son mutuamente excluyentes.

Es posible que este cambio no sea la solución perfecta para todos los casos de uso, pero mejora drásticamente la experiencia para la mayoría y creo que sería mucho mejor fusionarlo y debatir un año más sobre la implementación.

Si su KEP se aprueba e implementa, podemos eliminar este. Todavía no son mutuamente excluyentes.

¿Alguna vez serían mutuamente excluyentes?

Me pregunto si esta función tiene valor _ incluso si_ se habilita un pedido más explícito de inicio / apagado de contenedores (que creo que sería genial) a través de otra mejora en el futuro ... y estoy pensando que sí.

Cualquier orden de inicio / apagado, que esté implícita en la clasificación de contenedores como init, sidecar o "regular" apartados, estas clasificaciones también expresan _otros_ aspectos útiles y posiblemente no relacionados del comportamiento deseado de un contenedor, ¿no es así?

Por ejemplo, es útil en un pod con restartPolicy != Always (un pod que implementa un trabajo, quizás), que los contenedores designados como sidecars no tengan relación con un pod que ingresa a un estado completado.

@ kfox1111 , Vault ahora hace una inyección secreta usando sidecars. ¿En qué clase debería encajar? Además, dependiendo del caso, la bóveda podría depender de la malla de servicio o al revés.

Trabajamos a través de controladores efímeros csi para que cosas como vault no necesitaran contenedores sidecars / init. Creo que hay un controlador de bóveda en proceso.

¿Aunque parece que un sidecar normal con emptyDir encajaría en un sidecar que necesita usar los sidecar de red?

@ Joseph-Irving, de ninguna manera estaba tratando de bloquear este KEP para que no entrara. Me doy cuenta de que lo comenzó hace casi 2 años y hay muchas personas esperando que se publique.

¿Tiene un enlace a una discusión previa relacionada con el gráfico de dependencia?

Hola @ Joseph-Irving,

Recordatorio amistoso de que nos acercaremos bastante rápido a la congelación de código el 5 de marzo de 2020 . No parece que sus RP se hayan fusionado todavía, ¿todavía siente que está en camino de congelar el código para esta mejora?

Hola @jeremyrickard , La revisión de la API (https://github.com/kubernetes/kubernetes/pull/79649) básicamente está lista. Cerraremos ese PR y pasaremos por completo al PR de implementación para que todo (API e Implementación) se pueda fusionar en un PR.

El PR de implementación (https://github.com/kubernetes/kubernetes/pull/80744) se ha revisado a fondo, por lo que estoy tratando de obtener un aprobador de sig-node para buscar la aprobación final.

Si esto sucede a tiempo para la congelación del código es algo difícil de decir para mí, depende mucho de si logro llamar la atención de algunos aprobadores a tiempo.

Me encantaría ver que esto entrara mediante congelación de código. Haría que la solución de Istio para https://github.com/istio/istio/issues/7136 sea más simple y mejor.

¿Algún movimiento sobre esto para llegar a 1,18? Parece necesario para que los sidecars istio funcionen como se espera con trabajos de ejecución rápida.

Intenté comunicarme con los aprobadores de sig-node de varias maneras, pero no obtuve ninguna respuesta. Así que no soy muy optimista de que esto llegue a 1,18.

@ Joseph-Irving se creó el canal # pr-reviews slack para estos casos. ¿Has probado eso? Es una forma de obtener una escalada en las revisiones de relaciones públicas. (No lo vi allí)

Hola @ Joseph-Irving,

Estamos a solo unos días de la congelación del código. ¿Quiere diferir esto a 1,19 según el ancho de banda del revisor? ¿O intentar dar un empujón?

Hola @jeremyrickard ,

Nadie me ha respondido con respecto a la fusión de estos RP en 1.18, por lo que dudo mucho que suceda.

Podemos diferir a 1,19, pero estoy empezando a preguntarme si tiene algún sentido hacerlo.
Este KEP ha estado en vuelo durante casi dos años (el objetivo alfa original era 1,15), los RP en cuestión han estado abiertos durante casi 1 año, nunca hay ningún "ancho de banda de revisor" para ellos.
He enviado correos electrónicos cortésmente, he relajado, he ido a reuniones de firmas e incluso he encontrado personas en persona para recibir reseñas, pero hemos progresado muy poco.
Cualquier revisión que he logrado obtener solo ha sugerido cambios menores, no es como si se hubieran solicitado grandes reescrituras, los PR son básicamente los mismos que hace un año, solo que un poco más pulidos.
No sé si debo hacer ping agresivamente a las personas todos los días hasta que me respondan, pero eso no es algo con lo que me sienta cómodo.

Creo que el problema es más que a nadie le importa esta característica, yo soy el único que está impulsando esta característica, nadie en los SIG parece interesado en ver esto. Si se necesitan dos años para llegar a alfa, ¿cuánto tiempo llevará llegar a beta / GA? (como cuando la mayoría de la gente realmente puede usar esto)

Es frustrante que parezca haber interés de la comunidad en general y de los usuarios finales en incorporar esta función, la razón por la que hice esto en primer lugar es que vi que era un problema, pregunté a los SIG si iban a solucionarlo, y ellos dijo "no tenemos la capacidad, pero estaremos encantados de que lo hagas".
Así que hice todo lo que me pidieron, escribí el KEP, lo aprobé por todas las partes, escribí todo el código, todas las pruebas, lo mantuve actualizado constantemente a medida que pasaba cada versión, y sin embargo, aquí estamos.

Cada vez que retrasamos esto, siento que estoy decepcionando a un montón de gente, ¿es todo culpa mía? ¿Es el código tan terrible que nadie comentará? ¿No soy lo suficientemente agresivo al tratar de llamar la atención?
Siento que no puedo hacer esto por mi cuenta, y me estoy cansando un poco de vencer a este caballo muerto.

Lamento la larga perorata (no dirigida a ti personalmente Jeremy ni a nadie personalmente para el caso), pero esto ha estado carcomiendo lentamente mi alma durante mucho tiempo.

Es frustrante que parezca haber interés de la comunidad en general y de los usuarios finales en incorporar esta función, la razón por la que hice esto en primer lugar es que vi que era un problema, pregunté a los SIG si iban a solucionarlo, y ellos dijo "no tenemos la capacidad, pero estaremos encantados de que lo hagas".

@ Joseph-Irving Sobre esto. Como usuario activo, estoy viendo este hilo porque estoy interesado (y también dos de mis colegas). Es posible que la actividad sobre el problema, la solicitud de extracción, los canales flojos o las firmas no sean el mejor indicador de interés en esta función.

@dims ¿ Quizás puedas arrojar algo de luz?

@thockin Escuché que te entrevistaron en el podcast de Kubernetes hace un ~ año y hablaste de contribuir a Kubernetes. Tal vez fue usted o alguien más en otro episodio de podcast que se sintió realmente mal porque este sidecar KEP no llegó a 1.16. Bien, aquí estamos de nuevo.

Este problema parece ser un excelente ejemplo de lo difícil que puede ser contribuir si no eres un empleado de, por ejemplo. Google, RedHat u otro gran jugador.

También pedí en Slack que me ayudara a revisarlo, pero @thockin me acaba de decir que hay una reserva explícita, así que tampoco estoy seguro del camino a seguir.

Pasé mucho tiempo en la función efímera del controlador csi. Hacerlo fue igualmente frustrante y hubo momentos en los que no estaba seguro de que lo lograría después de tantos retrasos y rediseños. Entonces, siento tu dolor. Sería genial si pudiéramos encontrar una manera de hacerlo menos doloroso. Dicho esto, también lo hicimos eventualmente después de perder algunos lanzamientos importantes. ¡Así que no te rindas / pierdas la esperanza! El barco puede ser difícil de girar, pero eventualmente lo hace.

Cualquiera que ejecute cualquier tipo de topología que dependa de un sidecar de red probablemente tenga problemas de pedidos de inicio / apagado de contenedores que este KEP podría resolver. Ctrl-F para "Istio" en este ticket, y verá un montón de molestias relacionadas con el pedido de contenedores.

¿Hay algunos mantenedores de Istio aquí? Muchos son Googlers, y podrían tener más influencia con la gente de K8 internamente.

Como tienda de Istio / K8s, ¡te apoyamos absolutamente en que consigas esto, @ Joseph-Irving! ✊❤️

Felicitaciones para @ Joseph-Irving por hacer sidecar hasta ahora.

Incluso para la gestión del ciclo de vida del sidecar, cualquier trabajo por lotes requeriría esta función o Kubernetes simplemente no funciona para ellos, y es por eso que pasamos mucho tiempo también ayudando a revisar el código y proporcionando retroalimentación.

Hemos estado bifurcando k8s durante un tiempo debido a esto y estamos ansiosos por ver una característica tan importante compatible oficialmente.

Como tienda de Istio + Kubernetes, también hemos estado esperando ansiosamente esta función. Y cada vez más frustrado porque se desliza de un lanzamiento a otro. No nos complace tener que recurrir a hacks para acabar con los sidecars en las cargas de trabajo. Para nuestras necesidades, esta ha sido la característica más importante que necesitamos en Kubernetes, durante más de un año.

@thockin Se informó anteriormente que ha puesto una reserva explícita sobre esto. ¿Puede explicar por qué?

Hay muchos usuarios de Linkerd que también están esperando ansiosamente esto. Aguanta @ Joseph-Irving, te apoyamos.

No estoy seguro si todos los demás aquí lo vieron, pero después de investigar un poco y ver un video de kubecon, descubrí que Lyft había hecho algo similar a esto. Aquí está la confirmación mencionada de su bifurcación de kubernetes: https://github.com/lyft/kubernetes/commit/ba9e7975957d61a7b68adb75f007c410fc9c80cc

Como tienda de Istio + Kubernetes, también hemos estado esperando ansiosamente esta función. Y cada vez más frustrado porque se desliza de un lanzamiento a otro.

Soy un usuario potencial de istio, pero me he mantenido al margen un poco debido a la espera de una función como esta. Sin embargo, durante las discusiones anteriores, sigo viendo cosas que me hacen pensar que la función de sidecar por sí sola como se discutió aquí no solucionará todos los problemas que el sidecar de istio tiene con el flujo de trabajo. Aunque puede ayudar. Lo cual creo que es parte de la razón por la que esto se ha estancado.

¿Cómo funciona la ejecución de istio en un sidecar cuando se utiliza el controlador istio cni? Creo que los contenedores de inicio que intentan llegar a la red aún no funcionarán correctamente como se documenta en la documentación de istio.

de ahí mi pregunta anterior si los sidecars de red son lo suyo.

Este problema parece ser un excelente ejemplo de lo difícil que puede ser contribuir si no eres un empleado de, por ejemplo. Google, RedHat u otro gran jugador.

¡Ja! ¡Lo que no sabes es que esas personas a veces también se atascan!

En serio, lo siento. Tengo excusas, pero eso apesta, así que no me molestaré.

Para aclarar:
No estoy insinuando que no debamos fusionar esto como alfa para obtener comentarios sobre el enfoque. En general, creo que está bien. Creo que hay algunos agujeros en los casos de uso, como las mallas de servicio, que no cubre del todo. Pero esa no es una razón para bloquear la obtención de esto lo antes posible para que podamos encontrar todos los otros casos de uso que no cubre para que podamos hacer que la versión beta de la función funcione bien para todos. Eso es precisamente lo que es un alfa para la OMI.

Solo estoy mencionando lo que hice, específicamente a las personas que esperan que esto sea una solución milagrosa para el problema de la malla de servicios existente. No creo que la versión alfa propuesta solucione por completo ese problema en particular. Así que no te hagas ilusiones demasiado todavía. Pero, por favor, no bloqueemos esta función solo porque todavía no es compatible con todos.

He solicitado una excepción, veamos si podemos intentar conseguir esto:
https://groups.google.com/d/msg/kubernetes-sig-release/RHbkIvAmIGM/nNUthrQsCQAJ

Tal vez fue usted o alguien más en otro episodio de [Kubernetes Podcast] quien se sintió realmente mal porque este sidecar KEP no llegó a 1.16

Vea los episodios 72, con Lachie Evenson , y 83, con Guinevere Saenger . Incluso dije esta semana que se requieren revisiones de relaciones públicas para superar este problema. ¡Podemos hacerlo!

¿Hay algunos mantenedores de Istio aquí? Muchos son Googlers, y podrían tener más influencia con la gente de K8 internamente.

@duderino y @howardjohn ya han comentado este hilo.

Para ser claros, necesitamos fusionar:
kubernetes / kubernetes # 79649
kubernetes / kubernetes # 80744

¿Hay algún otro RP que debamos rastrear?

¡Gracias!

• Equipo de mejoras

Muchas gracias a todos los que publicaron mensajes de apoyo (pública o privadamente) que fueron muy apreciados ❤️

Hubo un esfuerzo valiente por parte de los miembros de la comunidad para tratar de incluir esto en 1.18, incluido el equipo de lanzamiento que aceptó una solicitud de extensión, pero, lamentablemente, se tomó la decisión de aplazar esto a 1.19. Puede ver la conversación relevante a partir de este comentario: https://github.com/kubernetes/kubernetes/pull/80744#issuecomment -595292034.

A pesar de que no llegó a 1,18, esto ha recibido mucha más atención en los últimos días de lo que ha tenido en bastante tiempo, por lo que espero que este impulso se traslade a 1,19.

cc @jeremyrickard , @kikisdeliveryservice

Buen material @ Joseph-Irving, parece que algunas de sus frustraciones han valido la pena y han sido escuchadas. Gracias por perseverar.

/ hito v1.19

Hola a todos. Un grupo de nosotros hemos estado discutiendo este tema durante la última semana.

Primero, nos disculpamos por lo ocurrido aquí. No estamos contentos con eso.

Este RP y KEP asociado han sacado a la luz una serie de cosas que el proyecto puede hacer mejor. Nos gustaría separar las preocupaciones sociales, de procedimiento y técnicas.

Socialmente, esta característica fue víctima de nuestro deseo de complacernos mutuamente. Derek aprobó el KEP, a pesar de las reservas expresadas dentro del SIG, porque Clayton y Tim lo estaban presionando. Todos confiamos el uno en el otro, pero aparentemente no siempre sentimos que somos capaces de decir "no". Sabemos esto porque todos hemos hecho exactamente lo mismo. Ninguno de nosotros quiere ser el bloqueador de la próxima gran idea.

Confiar el uno en el otro tiene que incluir la confianza en que podemos decir "no" y la confianza en que cuando alguien dice "no", lo está haciendo por buenas razones. Esta área técnica abarca los SIG, y NO debemos presionar a sig-node, que en última instancia serán los que resolverán los problemas, para que acepte nuevas funciones que aún no se sienten cómodos de admitir. No se trata de Tim o Derek o Clayton en particular, pero TODOS los aprobadores de alto nivel y los líderes SIG y los contribuyentes "senior".

Esta característica también fue víctima de la incertidumbre procesal en torno a los KEP. Como revisor de KEP, ¿estoy obligado a ser revisor de código? ¿Para delegar en un revisor de código? ¿O simplemente para leer el KEP? A medida que los KEP abarcan lanzamientos, ¿cómo nos aseguramos de que un pastor esté disponible para el conjunto de cambios presupuestados en un período particular de lanzamientos? Si un KEP abarca los SIG, ¿cómo presupuestamos y asignamos el tiempo entre los SIG? Necesitamos aclarar esto. Vamos a trabajar en algunas propuestas de cambio de KEP (KEP KEP) para fortalecer la definición de roles en el proceso KEP.

Técnicamente, esta característica fue víctima tanto del tiempo como de la atención. Los revisores no se tomaron el tiempo suficiente para revisarlo, o simplemente no fue lo suficientemente prioritario para ellos. Las discusiones de ida y vuelta toman tiempo. Las circunstancias y nuestra comprensión del espacio del problema cambian con el tiempo.

A medida que más usuarios adoptan Kubernetes, vemos un número cada vez mayor de casos extremos extraños o escamas que se informan a sig-node. Dado que el ciclo de vida del pod es fundamental para Kubernetes, cualquier cambio realizado en ese subsistema DEBE realizarse con cuidado. Nuestra capacidad para fusionar nuevas funciones debe equilibrarse con nuestro deseo de mejorar la confiabilidad. La forma en que pensamos sobre el ciclo de vida del pod hoy en día es un poco diferente a cómo lo pensamos cuando se inició esta función. Esto no disminuye los casos de uso que conducen a esto de ninguna manera, pero sugiere que los KEP de larga duración deben volver a revisarse periódicamente a lo largo del tiempo.

Creemos que debemos pensar un poco en los primeros principios en torno al ciclo de vida del Pod. ¿Qué es lo que realmente queremos? Intentamos no descender a demasiada complejidad, pero tememos que simplemente dividimos esa complejidad en múltiples fases, y el resultado neto puede ser MÁS complejo que simplemente abordarlo de frente.

¿Qué significa eso para este RP y el KEP asociado? No estamos 100% seguros. Sin embargo, probablemente signifique que NO deberíamos seguir adelante con esto.

Derek expresó algunas preocupaciones sobre la secuencia de cierre. La KEP los llamó fuera de alcance por ahora, pero hay algunas dudas. Ya no respetamos la terminación ordenada en el cierre del nodo, y eso ha sorprendido a muchos usuarios. Eso no es culpa de este KEP, pero llamémoslo "circunstancias atenuantes". Si alguien usa sidecars para "limpiar" sus pods (por ejemplo, para drenar los registros almacenados en caché en un servicio de registro), esperará (razonablemente) alguna semántica clara y útil sobre el apagado, lo que este KEP no garantiza.

A Tim le preocupa que los init-sidecars tengan que convertirse en algo, y eso no se siente bien. Renunció a esa preocupación en el pasado, pero todavía le molesta.

Necesitamos SIG Node para ayudar a definir cuál es el objetivo a mediano plazo para el ciclo de vida de las vainas y cuál es su apetito por asumirlo. Si podemos estar de acuerdo en que este es un paso incremental hacia el objetivo, podemos desbloquearlo, pero a menos que sepamos el objetivo, probablemente estemos sobrepasando nuestros faros.

Seamos todos los primeros en decir que esto apesta. Tenemos declaraciones de problemas reales, un colaborador apasionado y un conjunto de mantenedores bien intencionados, y terminamos ... aquí. Tim ofrecerá su tiempo como voluntario para ayudar a generar ideas y diseñar. Derek impulsará el trabajo de cierre de nodos durante el ciclo de vida actual del pod para garantizar que tengamos una base estable para seguir creciendo. Tendremos que especificar con mucho cuidado qué garantías podemos y no podemos hacer frente a fallas imprevistas de la máquina.

Gracias,
Clayton, David, Dawn, Derek, John, Tim

Para tratar de estimular algún movimiento hacia adelante: Derek o Dawn: ¿hay alguien en el nodo sig que pueda tomarse el tiempo para hacer una lluvia de ideas sobre un ciclo de vida de contenedores y vainas más holístico?

@thockin agregará esto a la agenda de sig-node.

@thockin @derekwaynecarr ¿

Descripción de la mejora de una línea: los contenedores ahora se pueden marcar como sidecars para que se inicien antes que los contenedores normales y se apaguen después de que todos los demás contenedores hayan terminado.

Suena como algo que facilitaría la vida en esta nueva era de sidecars de malla de servicio.

Además, ¿alguna recomendación para que los sidecars se inicien antes de los contenedores principales de la aplicación y se apaguen después de la finalización del contenedor principal de la aplicación hoy?

... ¿cuál es el tl; dr en cuanto a por qué esto no podría entrar?

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

¿Qué significa eso para este RP y el KEP asociado? No estamos 100% seguros. Sin embargo, probablemente signifique que NO deberíamos seguir adelante con esto.

Derek expresó algunas preocupaciones sobre la secuencia de cierre. La KEP los llamó fuera de alcance por ahora, pero hay algunas dudas. Ya no respetamos la terminación ordenada en el cierre del nodo, y eso ha sorprendido a muchos usuarios. Eso no es culpa de este KEP, pero llamémoslo "circunstancias atenuantes". Si alguien usa sidecars para "limpiar" sus pods (por ejemplo, para drenar los registros almacenados en caché en un servicio de registro), esperará (razonablemente) alguna semántica clara y útil sobre el apagado, lo que este KEP no garantiza.

[...]

Necesitamos SIG Node para ayudar a definir cuál es el objetivo a mediano plazo para el ciclo de vida de las vainas y cuál es su apetito por asumirlo. Si podemos estar de acuerdo en que este _es_ un paso incremental hacia el objetivo, podemos desbloquearlo, pero a menos que sepamos el objetivo, probablemente estemos sobrepasando nuestros faros.

Respetuosamente, tengo curiosidad por saber si algún cliente potencial planea priorizar la solución de esto. @ Joseph-Irving puso una enorme cantidad de trabajo en esto y una asombrosa cantidad de personas que se habrían sentido felices con su solución están ansiosas por escuchar una solución superior de quienes rechazaron esto.

Como mínimo, a pesar de que hay reparos con algunos aspectos, creo que todavía es razonable ingresar como Alfa para encontrar qué problemas se mostrarán en la práctica. ¿Podemos fusionar esto? Los problemas pueden impedir que se convierta en Beta, por lo que no creo que sea crítico perfeccionarse antes de que se haga un Alpha inicial.

agregará esto a la agenda sig-node.

@thockin @derekwaynecarr ¿hay alguna actualización sobre el estado actual de esto? Revisé las notas de la reunión de sig-node y no veo nada sobre esto.

Hay una gran cantidad de desarrolladores en este hilo que estarían más que felices de contribuir con su tiempo para implementar esto, ya que es crítico para muchos casos de uso (el KEP en sí tiene 2.5 veces más: +1: que cualquier otro KEP). ¿Qué podemos hacer para que esto suceda? Tener una lista de requisitos previos para la estabilidad de esta área, incluso si puede abarcar muchos lanzamientos para lograr, en la que podríamos comenzar a trabajar activamente, sería una gran mejora desde donde nos encontramos hoy.

Hola @ Joseph-Irving @thockin @khenidak @ kow3ns - 1.19 Mejoras

Para tener esta parte del lanzamiento:

1. El KEP PR debe fusionarse en un estado implementable
2. El KEP debe tener planes de prueba
3. El KEP debe tener criterios de graduación.

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

@palnabarun , según este comentario https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056, este KEP se ha puesto en espera indefinida, por lo que no se graduará en 1.19.

Gracias @ Joseph-Irving por aclarar la situación. : +1:

¡Aprecia tus esfuerzos!

Para todos los que están ansiosos por incluir esto, y nuevamente para @ Joseph-Irving: personalmente, lamento mucho esta situación. También quiero esto (o algo parecido), pero el hecho es que sig-node tiene más trabajo que hacer que la gente para hacerlo en este momento, y no están listos para considerar esto.

Apesta. Lo entiendo. Realmente realmente lo hago.

La mejor forma en que la gente podría ayudar es saltar a sig-node y ayudar a crear más capacidad asumiendo revisiones de código y triaje de problemas, corrigiendo errores y pruebas, y construyendo hacia un lugar donde los expertos de sig-node tengan más capacidad y confianza en hacer tal cambio.

sig-node tiene más trabajo que hacer que la gente que lo hace en este momento

Comprendido. Hemos estado promoviendo, con énfasis, las necesidades de capacidad de sig-node internamente. Estamos trayendo y asesorando a voluntarios de sig-node OSS, algunos experimentaron algunos nuevos, todos con el deseo de trabajar en este espacio (cuatro hasta ahora). Estaré citando tu comentario @thockin , ¡gracias!

/ hito claro

La mejor forma en que la gente podría ayudar es saltar a sig-node y ayudar a crear más capacidad asumiendo revisiones de código y triaje de problemas, corrigiendo errores y pruebas, y construyendo hacia un lugar donde los expertos de sig-node tengan más capacidad y confianza en hacer tal cambio.

@thockin ¿Podría proporcionar enlaces como repositorios, listas de correo, guías, etc.? Eso ayudaría a las personas a tener una idea sobre cómo interactuar con sig-node de manera efectiva. Esta solicitud de función en particular tiene más de 2 años y no se vislumbra una resolución.

@ tariq1890 las personas que escribieron este KEP han hecho todo bien. no dejaron piedra sin remover. El problema aquí es exactamente lo que dijo @thockin , hay una deuda tecnológica que debemos solucionar primero y se necesitan manos para eso antes de que podamos considerar esta. Así que la solicitud es que la gente ayude con lo que se necesita hacer.

Consulte la última actualización aquí: https://github.com/kubernetes/enhancements/pull/1874

@dims Creo que me han malinterpretado. Lo que quise decir es que necesitamos una lista de objetivos y metas viables. Si hay una deuda tecnológica que abordar, entonces podríamos mantener un Hito de GitHub o proporcionar una lista con viñetas de los elementos de acción pendientes en el comentario de los OP para que las personas que visitan este problema puedan saber de inmediato lo que se debe abordar.

Definitivamente estoy dispuesto a ofrecer mi ayuda a sig / node para avanzar en este KEP, pero no sé cómo

@ tariq1890, la pregunta específica está aquí: "requisito previo para el cierre ordenado del nodo kubelet (aún no enviado)" https://github.com/kubernetes/enhancements/pull/1874/files#diff -c6212b56619f2b462935ad5f631d772fR94

Tenemos que empezar con eso. Alguien tiene que tomar el punto y ponerlo en marcha.

- Atenúa

Entonces, el resumen https://github.com/kubernetes/enhancements/pull/1874 para aquellos en este problema: Sig-node (y otros) piensan que no es prudente introducir una nueva característica como esta KEP, que agrega un comportamiento más complejo a terminación del módulo, mientras que todavía existe el problema más genérico de la terminación del módulo mientras se cierra un nodo.
Por lo tanto, se decidió que esta función no progresará hasta que se haya implementado la solución para la terminación del nodo.
Actualmente hay un documento de Google aquí: https://docs.google.com/document/d/1mPBLcNyrGzsLDA6unBn00mMwYzlP2tSct0n8lWfuRGE
Que contiene gran parte de la discusión sobre el tema, pero el KEP para esto aún no se ha enviado.
Todavía hay preguntas abiertas, por lo que comentarlas podría ser útil. Creo que @bobbypage y @mrunalp están liderando este esfuerzo, por lo que tal vez puedan compartir otras formas en que las personas podrían ayudar a avanzar.

@ Joseph-Irving muchas gracias por resumir. Espero que toda la energía + ve en esta mejora se traduzca en una mayor participación de todos en sig-node de forma regular y no solo en funciones únicas. Hay mucho trabajo por hacer y muy pocas manos.

¡Hola! Sin embargo, un comentario más con respecto a este KEP: planteé algunos casos extremos sobre este KEP en reuniones pasadas del nodo SIG (el 23 de junio si desea ver las grabaciones) y decidimos que la forma correcta de continuar esa discusión es abrir RP sobre esos problemas para que podamos decidir cuál es la mejor manera de proceder.

Actualmente estoy trabajando en un PR para exponer esos problemas y algunas alternativas en las que puedo pensar.

Además, el estado KEP ahora es provisional (en lugar de implementable), por lo que se puede revisar y solo se puede configurar para que se pueda implementar nuevamente cuando todas las personas estén de acuerdo en sentirse cómodas para seguir adelante con el KEP.

Creo que esta fue la única información que faltaba en este número. ¡Gracias!

@rata ¿Abrió problemas / relaciones públicas sobre la forma correcta de manejar los problemas?

@mattfarina Este es el PR https://github.com/kubernetes/enhancements/pull/1913
Contiene una serie de soluciones propuestas a problemas actuales / casos extremos en el KEP
También contiene detalles de una serie de alternativas que se discutieron y se decidieron en contra, para que tengamos un mejor registro de por qué se han tomado ciertas decisiones.

Me gustaría mucho ver que la funcionalidad del sidecar también cubra el escalado:
Hoy en día, el escalado de HPA se basa en una métrica (como cpu). Si la vaina contiene más de un contenedor, se usa el promedio de todos los contenedores (hasta donde yo sé). Para los pods con sidecar (aplicación + nginx, etc.), esto hace que sea muy difícil hacer que el escalado funcione correctamente. Esperaba que la implementación del sidecar en Kubernetes incluyera marcar un contenedor en el pod como "autoritario" en términos de métricas utilizadas para el escalado de HPA.

Me gustaría mucho ver que la funcionalidad del sidecar también cubra el escalado:

Estoy de acuerdo en que esto sería útil, pero no es necesariamente un "sidecar" específico y, dado que la implementación está desacoplada de esto, puede tener sentido convertirlo en un tema separado; este ya es muy complejo. Tampoco estoy convencido de que quieras ignorar el sidecar. En su lugar, es posible que deseemos una escala de HPA por contenedor, por ejemplo. No estoy seguro, creo que necesitaría explorarlo como un problema propio.

¿Alguien tiene alguna referencia a, o podría ser tan amable de compartir, la solución actual para este problema, específicamente para el caso del sidecar Istio Envoy?

Recuerdo una posible solución que involucra:

• una imagen de Envoy personalizada que ignora SIGTERM.
• invocar / quitquitquit en Envoy desde el contenedor de la aplicación al cerrar (similar a la solución alternativa de finalización del trabajo)

¿Alguien tiene alguna referencia a, o podría ser tan amable de compartir, la solución actual para este problema, específicamente para el caso del sidecar Istio Envoy?

Usamos una imagen de demonio personalizada como supervisor para envolver el programa del usuario. El demonio también escuchará un puerto en particular para transmitir el estado de salud de los programas de los usuarios (salidos o no).

Aquí está la solución:

• Usando la imagen del demonio como initContainers para copiar el binario a un volumen compartido.
• Nuestro CD secuestrará el comando de los usuarios, deje que el demonio comience primero. Luego, el demonio ejecuta el programa de los usuarios hasta que Envoy esté listo.
• Además, agregamos preStop , un script que sigue verificando el estado de salud del demonio, para Envoy.

Como resultado, el proceso de los usuarios se iniciará si Envoy está listo y Envoy se detendrá después de salir del proceso de usuarios.

Es una solución complicada, pero funciona bien en nuestro entorno de producción.

El enlace en la descripción da un 404

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

Creo que debería ser:

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

sí, se movió en https://github.com/kubernetes/enhancements/pull/1913 , actualicé el enlace

¿Alguien tiene alguna referencia a, o podría ser tan amable de compartir, la solución actual para este problema, específicamente para el caso del sidecar Istio Envoy?

@shaneqld para problemas de inicio, la comunidad istio ideó una solución bastante inteligente que básicamente inyecta envoy como el primer contenedor en la lista de contenedores y agrega un gancho postStart que verifica y espera a que envoy esté listo. Esto está bloqueando y los otros contenedores no se inician, asegurándose de que envoy esté allí y listo antes de iniciar el contenedor de la aplicación.

Tuvimos que migrar esto a la versión que estamos ejecutando, pero es bastante sencillo y estamos contentos con los resultados hasta ahora.

Para el apagado, también estamos 'resolviendo' con el gancho preStop, pero agregando un sueño arbitrario que esperamos que la aplicación se haya apagado correctamente antes de continuar con SIGTERM.

Relaciones públicas relacionadas: https://github.com/kubernetes/enhancements/pull/1980

Hola @ Joseph-Irving @thockin y todos los demás: sonríen:

Las mejoras conducen aquí. Veo que todavía hay un montón de conversaciones en curso, pero como recordatorio, manténganos actualizados de cualquier plan para incluir esto en la versión 1.20 que se haya decidido para que podamos realizar un seguimiento del progreso.

¡Gracias!
Kirsten

@kikisdeliveryservice te mantendrá informado, ¡gracias!

¿Alguien tiene alguna referencia a, o podría ser tan amable de compartir, la solución actual para este problema, específicamente para el caso del sidecar Istio Envoy?

@shaneqld para problemas de inicio, la comunidad istio ideó una solución bastante inteligente que básicamente inyecta envoy como el primer contenedor en la lista de contenedores y agrega un gancho postStart que verifica y espera a que envoy esté listo. Esto está bloqueando y los otros contenedores no se inician, asegurándose de que envoy esté allí y listo antes de iniciar el contenedor de la aplicación.

Tuvimos que migrar esto a la versión que estamos ejecutando, pero es bastante sencillo y estamos contentos con los resultados hasta ahora.

Para el apagado, también estamos 'resolviendo' con el gancho preStop, pero agregando un sueño arbitrario que esperamos que la aplicación se haya apagado correctamente antes de continuar con SIGTERM.

¿Podría mostrar algunas ideas en detalle sobre cómo hacer esto? ¿Cómo lograr agregar 'pre-stop' al sidecar Istio-proxy? Parece que necesita alguna configuración personalizada o usar un sidecar personalizado. Me enfrento al mismo problema de que cuando las vainas se reducen, el contenedor principal está tratando de terminar los trabajos pero pierde la conexión con el exterior probablemente porque el Istio-sidecar se cerró inmediatamente después de SIGTERM. En este momento solo uso la inyección de sidecar predeterminada. ¡Gracias!

Ok, este hilo está siendo secuestrado. Sigamos con el tema, por favor.

Solo un suave recordatorio de que Enhancements Freeze es la próxima semana, martes 6 de octubre. En ese momento, el KEP deberá actualizarse para que se marque como implementable.

Además, el KEP está utilizando un formato anterior, por lo que la actualización sería excelente (una vez que termine de detallar los detalles): https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

@kikisdeliveryservice gracias por el resto. Servirá si se decide incluirlo para 1.20. ¡Gracias! :)

Esto no será parte de 1.20. ¡Muchas gracias por hacer ping! :)

Tengo interés en este problema y quería agradecer a @ Joseph-Irving y @howardjohn por sus ideas sobre esto, que ayudaron a resolver algunas de mis preguntas.

No quiero secuestrar esta propuesta, pero basándome en las conversaciones anteriores, me pregunto si este es quizás un problema un poco más amplio / grande de lo que se ha reconocido hasta ahora.

Puedo imaginar las siguientes soluciones a este problema:

1. Defina una nueva entidad de contenedor "contenedor sidecar" que comience después de initContainers, antes de "contenedores principales" y termine después de que terminen los "contenedores principales" (según la propuesta original de @ Joseph-Irving)
2. Defina un campo adicional en (1) que establezca si el "contenedor sidecar" comienza antes de initContainer (s) por sugerencia de @luksa ).
3. Vaya más amplio.

Personalmente, la opción (2) resuelve mi problema inmediato.

Pero me pregunto si estas preguntas no se refieren a un tema más estratégico en K8 en torno a la programación y cómo definimos un grupo. En mi caso específico (relacionado con Istio) , sugerí algo como niveles de ejecución dentro de los pods.

La opción (2) también resuelve mi problema, pero puedo imaginar estructuras de dependencia aún más complejas que podrían requerir incrustar un DAG de dependencias de contenedores dentro de un pod / statefulSet / daemonSet / lo que sea: esta es la opción (3) en la que estoy pensando.

¿Me pregunto si este problema realmente debería volver a centrarse en la definición de pod en sí, con miras a crear algo más genérico? Originalmente pensé en términos de una analogía de niveles de ejecución, pero tal vez una estructura DAG similar a Airflow tendría la aplicabilidad más amplia.

¿Qué hay de agregar envoy como contenedor de inicio también? De esta forma, proporcionará una red para otros contenedores de inicio. Cuando init termine, también 'saldrá 0', y luego el enviado regular (no init) se hará cargo

@michalzxc Si no me equivoco, los contenedores de inicio se ejecutan uno por uno secuencialmente, por lo que actualmente no puede tener un enviado junto a otro contenedor como init-container .

¡Hola!

La discusión del sidecar continuó en estos lugares (he actualizado sig-node slack, github PR que inició esto y varias listas de correo):
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

Como puede ver, estamos recopilando casos de uso ahora, después de tener algunos casos de uso más, diferentes grupos pequeños pueden crear propuestas previas para abordarlos. No dude en agregar su caso de uso (si aún no está allí) o unirse más tarde para la parte de propuestas previas :-)

Por favor, mantengamos este tema de mejora en el tema (y probablemente cerrado). Le invitamos a unirse a la conversación en esos lugares :)

Este KEP no progresará, Sig-node y otros sienten que este no es un paso incremental en la dirección correcta, por lo que han vuelto a la mesa de dibujo y presentarán algunos nuevos KEP que, con suerte, pueden resolver todo el uso. casos indicados en esta KEP así como en otros.

Por favor, vea @rata 's comentario anterior https://github.com/kubernetes/enhancements/issues/753#issuecomment -707014341
Para lugares donde puede contribuir a la discusión.

Es lamentable que no se esté acostumbrando todo el trabajo realizado en este KEP, pero un grupo más amplio de personas ahora está pensando en estos problemas, por lo que es de esperar que la solución que encuentren sea la mejor para todos.
Ya he pasado más de dos años tratando de lograrlo , así que creo que este es un buen momento para seguir adelante, liderarán estas iniciativas en el futuro.

/cerrar

@ Joseph-Irving: Cerrando este tema.