@enisoc @ dchen1107 @fejta @thockin @ kow3ns @derekwaynecarr , abriu este problema de rastreamento para que possamos discutir.

/atribuir

@derekwaynecarr Fiz algumas alterações de escopo nas mudanças de kubelet necessárias para a reunião de nó de assinatura da próxima semana, eu _acredito_ que as mudanças são necessárias apenas no pacote kuberuntime , especificamente kuberuntime_manager.go em e kuberuntime_container.go .

Em kuberuntime_manager.go você pode modificar computePodActions para implementar o acionamento de desligamento (matar os carros laterais quando todos os não-carros tiverem saído permanentemente) e inicializar os carros laterais primeiro.

Em kuberuntime_container.go você poderia modificar killContainersWithSyncResult para encerrar os sidecars por último e enviar os ganchos preStop (o bit dos ganchos preStop era um pouco discutível, não estava decidido se isso deveria ser feito ou não. @ thockin teve um bom argumento sobre por que você pode não querer encorajar esse comportamento, veja o comentário ).

Avise-me se quiser que eu investigue mais.

@ kow3ns A discussão faz mais sentido para mim se talvez possamos definir uma descrição completa da sequência de contêineres na especificação do Pod (sig-app) e como lidar com a sequência no kubelet para iniciar, reiniciar e consideração em cascata (nó-sig). Vamos pegar a reunião de nó de assinatura de 5 de fevereiro para dar mais informações.

cc @ Joseph-Irving

A proposta diz que os sidecars só rodam depois que os containers init rodam. Mas e se o caso de uso exigir que o arquivo secundário seja executado enquanto / antes da execução dos contêineres init. Por exemplo, se você deseja rotear o tráfego do pod por meio de um proxy executado como um arquivo secundário (como no Istio), provavelmente deseja que esse proxy esteja no lugar enquanto os contêineres init são executados, caso o próprio contêiner init faça chamadas de rede.

@luksa Eu acho que existe a possibilidade de ter sidecars que rodam na fase de inicialização em algum ponto, mas atualmente a proposta não vai cobrir esse caso de uso. Atualmente, não há como ter contêineres simultâneos em execução na fase de inicialização, de modo que seria potencialmente uma alteração muito maior / mais confusa do que o que está sendo sugerido aqui.

Atualização sobre este KEP:
Falei com @derekwaynecarr e @ dchen1107 da sig-node sobre isso e eles não expressaram nenhuma preocupação importante sobre a proposta. Vou levantar um PR para o KEP adicionando algumas notas iniciais sobre os detalhes da implementação e esclarecendo alguns pontos que surgiram durante a discussão.

Ainda precisamos chegar a um acordo sobre a API, parece que há consenso de que uma maneira simples de marcar contêineres como laterais é preferível em vez de sinalizadores de pedido mais detalhados. Ter um bool é um tanto limitante, então talvez algo mais na linha de containerLifecycle: Sidecar seja preferível para que tenhamos a opção de expandir no futuro.

@ Joseph-Irving Na verdade, nem o booleano nem o containerLifecycle: Sidecar são apropriados para extensibilidade futura apropriada. Em vez disso, containerLifecycle deve ser um objeto, assim como deployment.spec.strategy , com type: Sidecar . Isso nos permitiria introduzir campos adicionais. Para a solução "sidecar durante toda a vida útil do pod", seria expresso ao longo destas linhas:

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: CompletePodLifetime

em oposição a

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: AfterInit

Por favor, perdoe minha má nomenclatura - espero que os nomes transmitam a ideia.

Mas há um problema com a abordagem em que introduzimos containerLifecycle a pod.spec.containers . Ou seja, é errado ter sidecars que rodam paralelamente aos containers init especificados em pod.spec.containers . Então, se você realmente deseja estender isso para containers init eventualmente, você deve encontrar uma solução alternativa - uma que permitiria que você marque containers como sidecars em um nível mais alto - ou seja, não abaixo de pod.spec.containers ou pod.spec.initContainers , mas algo como pod.spec.sidecarContainers , que acredito que você já discutiu, mas dispensou. O problema dos containers init definitivamente exige uma solução ao longo dessas linhas.

@luksa Você também pode resolver o problema do init apenas permitindo que um contêiner init seja marcado como um

O problema com pod.spec.sidecarContainers é que é uma alteração muito mais complexa, as ferramentas precisariam ser atualizadas e o kubelet exigiria muitas modificações para suportar outro conjunto de contêineres. A proposta atual é muito mais modesta, está apenas aproveitando o que já existe.

@ Joseph-Irving Podemos trabalhar com isso sim. Não é ideal que o arquivo secundário seja encerrado após a execução dos contêineres init e, em seguida, o mesmo arquivo secundário seja inicializado novamente, mas é melhor do que não ter essa opção. O maior problema é que os Kubelets mais antigos não lidariam com os contêineres init-sidecar apropriadamente (como é o caso com os contêineres do sidecar principal).

Gostaria que você mantivesse o init-sidecars em mente ao finalizar a proposta. Em essência, você está introduzindo o conceito de "sidecar" no k8s (anteriormente, nós basicamente tínhamos apenas um conjunto de contêineres que eram todos iguais). Agora que você está introduzindo sidecars reais, então IMHO, você realmente deve pensar bem nisso e não descartar um caso de uso de sidecar muito importante.

Eu ficaria feliz em ajudar com a implementação disso. Sem ele, o Istio não pode fornecer seus recursos aos contêineres init (na verdade, em um cluster Kubernetes devidamente protegido executando o Istio, os contêineres init perdem completamente a capacidade de se comunicar com _qualquer_ serviço).

Em relação à discussão de implementação em https://github.com/kubernetes/enhancements/pull/841 , abri um WIP PR contendo um PoC básico para esta proposta https://github.com/kubernetes/kubernetes/pull / 75099. É apenas um primeiro rascunho e, obviamente, não é perfeito, mas a funcionalidade básica funciona e dá uma ideia da quantidade de alterações necessária.

cc @enisoc

Montei um pequeno vídeo mostrando apenas como o PoC se comporta atualmente https://youtu.be/4hC8t6_8bTs. Vê-lo em ação pode ser melhor do que ler sobre ele.
Aviso: não sou um youtuber profissional.

Abri dois novos PRs:

• https://github.com/kubernetes/enhancements/pull/918 é sobre critérios de graduação, desvio de versão, upgrade / downgrade
• https://github.com/kubernetes/enhancements/pull/919 é decidir sobre a implementação da API

Quaisquer pensamentos ou sugestões serão muito apreciados.

@ Joseph-Irving Desculpe se estou comentando no final do processo de design, mas tenho um caso de uso potencial para contêineres de sidecar que pode não ser compatível com a proposta de design atual. Eu só queria colocá-lo em consideração. A essência é que tenho um cenário em que, no encerramento do pod, um arquivo secundário deve ser encerrado antes do contêiner principal, enquanto outro arquivo secundário deve ser encerrado após o contêiner principal.

Um exemplo concreto pode ser um pod com um contêiner de aplicativo Django, um cônsul sidecar para registro de serviço e um pgbouncer sidecar para gerenciar conexões com o banco de dados. Quando o pod for encerrado, gostaria que o sidecar cônsul fosse interrompido primeiro (para que nenhum tráfego mais seja direcionado para o pod), depois o contêiner do aplicativo (de preferência após um curto período de carência) e, em seguida, o sidecar pgbouncer. A proposta atual parece ótima para lidar com a dependência do contêiner do app <-> pgbouncer, mas não parece expressiva o suficiente para capturar o caso em que eu gostaria de derrubar um arquivo secundário _antes_ do contêiner principal.

@currankaushik , no cenário que você descreveu, você poderia usar um gancho de pré-parada para dizer ao contêiner do cônsul para se preparar para o desligamento e interromper o roteamento de solicitações para você (presumindo que ele possa oferecer suporte a algo assim). os ganchos de pré-parada serão enviados para os carros laterais antes de iniciar o encerramento dos contêineres.

A motivação para isso era que os proxy sidecars como o istio pudessem entrar em um estado em que não estivessem roteando o tráfego para você, mas continuassem permitindo o tráfego de saída enquanto seu aplicativo é encerrado e encerrado.

Parece bom, obrigado @ Joseph-Irving. Então, apenas para confirmar meu entendimento em um alto nível: ganchos pré-parada serão enviados para os carros laterais primeiro, seguidos por ganchos pré-parada para os carros não laterais, SIGTERM para os carros não laterais e então (depois que todos os carros não laterais tiverem saído ) SIGTERM para sidecars? A proposta de design (https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md) parece implicar isso, mas também diz:

Os ganchos PreStop serão enviados para carros laterais e contêineres ao mesmo tempo.

@currankaushik sim, o que você descreveu é o comportamento pretendido.

Essa linha que você citou precisa de reformulação. Eu tinha alguns conceitos errados sobre como os ganchos prestop foram enviados para os contêineres quando escrevi isso. Obrigado por apontar isso.

@ Joseph-Irving é este recurso visando a inclusão alfa para 1,15?

@ kacole2 sim, esse é o plano, presumindo que possamos fazer com que o KEP seja implementado a tempo para o congelamento das melhorias (30 de abril). Assim que a API for finalizada https://github.com/kubernetes/enhancements/pull/919 e o plano de teste acordado https://github.com/kubernetes/enhancements/pull/951 Acho que devemos estar prontos.

/ milestone v1.15
/ stage alpha

@ Joseph-Irving Kubernetes 1.15 O congelamento de aprimoramento é 30/04/2019. Para serem incluídos na etapa 1.15 do Kubernetes, os KEPs precisam estar em um estado "Implementável" com planos de teste e critérios de graduação adequados. Envie todos os PRs necessários para que este KEP cumpra os critérios de inclusão. Se isso diminuir do marco de 1,15, informe-nos para que possamos fazer as alterações de rastreamento apropriadas.

@mrbobbytables, infelizmente, os PRs abertos para colocar isso em um estado de implementação não tiveram muito movimento sobre eles, então acho que precisaremos adiar até 1.16.

Sem problemas. Obrigado por responder tão rapidamente e nos informar!
/ marco claro

Lembre-se de que este KEP é muito importante para o Istio!

É um impedimento para todos os projetos que usam frameworks de serviço com bootstrap / desligamento coordenado (cluster akka, lagom etc.) junto com a malha de serviço istio see .

cc @jroper

@Joseph-Irving sry sobre o comentário tardio, mas não vejo o seguinte no documento de design e gostaria de saber qual é o comportamento pretendido destes:

se houver falha no arquivo secundário, sempre os reiniciamos se o contêiner principal não for concluído (desconsiderando o restartPolicy no pod)? Isso seria útil como arquivo secundário usado para funcionar como proxy, balanceamento de carga, função de manutenção, e não importa se ele falhar algumas vezes, desde que o contêiner principal possa continuar a funcionar

Além disso, ao calcular a fase de pod, se todo o contêiner principal for bem-sucedido e o sidecar falhar (o que é muito comum, pois se o sidecar não capturar SIGTERM, o código de retorno será como 143 ou algo assim), a fase de pod ainda é "bem-sucedida"?

@ zhan849 atualmente, os contêineres Succeeded .

Discutimos isso um pouco antes no processo, mas o sentimento geral era de que deveríamos divergir de um contêiner normal o menos possível, apenas fazendo isso se permitir os casos de uso descritos.

Em relação à fase de pod: eu diria que todos os aplicativos em execução no kubernetes devem lidar com SIGTERMs (especialmente sidecars), mas também às vezes você gostaria de saber se seus sidecars saíram de maneira incorreta e isso deve se refletir na fase de pod, ocultar essa informação pode causar confusão.

Para a política de reinicialização, só parece que isso seria um problema se a política de reinicialização nunca for e seu arquivo secundário estiver sujeito a travar. Não tenho certeza se a complicação de divergir da política de reinicialização de pod vale a pena, especialmente porque algumas pessoas podem querer que seus sidecars obedeçam à política de reinicialização de pod.

Essas duas coisas estão alinhadas com o que um contêiner normal faz e com o que acontece atualmente.
Mudá-los não parecia ser necessário para atingir os objetivos listados no Kep.

Se você tiver alguns casos de uso difundidos para explicar por que é necessário alterá-los para atingir esses objetivos, isso seria útil. Isso torna mais fácil justificar uma mudança mais complicada na base do código.

@Joseph-Irving, temos alguns implementos de side car mais simples que estão funcionando internamente para algumas necessidades imediatas (não contribuímos, pois isso já está em andamento na comunidade), e aqui está o que aprendemos.

Em relação à fase do pod:

1. O status de existência do contêiner já está refletido em pod.status.containerStatuses portanto, não perdemos as informações. Além disso, como um grande caso de uso de sidecar está no Job (ou em qualquer pods run-to-finish, como aqueles em Kubeflow), cargas de trabalho significativas serão aplicadas apenas ao contêiner principal e se a fase do pod for marcada como Falha devido a falha do sidecar , isso resultará em novas tentativas desnecessárias e levará a outras consequências enganosas, como falha no trabalho, etc.

2. Embora seja ideal para sidecars lidar com SIGTERMs, em produção, pode haver muitos sidecars que são simplesmente construídos em software de código aberto e não estão lidando com SIGTERMs bem, incluindo kube-proxy , postfix , rsyslogd , e muitos outros (e mesmo se SIGTERM for manipulado, para SIGKILL não capturável, com certeza não será 0)

Com relação à política de reinicialização (pode ser discutível, mas fazer com que os sidecars obedeçam estritamente à política de reinicialização não é realista na produção):

1. Forçar o arquivo secundário a reiniciar quando os contêineres principais ainda estão em execução definindo "OnFailure" não é uma opção, pois isso reiniciará os contêineres principais com falha e é confuso junto com o limite de repetição do nível de trabalho.

2. Normalmente, ao lidar com carros laterais, os contêineres principais costumam ter muitas lógicas de repetição indisponíveis para o arquivo lateral, e isso é feito antes que a comunidade tenha suporte para carros laterais com ordem explícita de início do contêiner. Esse tratamento de erros históricos não é muito fácil de mudar devido ao seu escopo. Não reiniciar o arquivo secundário fará com que os contêineres principais travem e tentem novamente

3. A propagação de falhas para controladores de nível superior acionará cadeias de reconciliação e muitas chamadas de API, portanto, o escalonamento desnecessário de erros pode tornar o kubernetes menos escalonável.
   Um exemplo mais específico: se os contêineres principais de uma tarefa ainda estiverem em execução e o arquivo secundário falhar, reiniciar o arquivo secundário terá apenas 1 operação de status do pod PATCH e no máximo 1 chamada de API relacionada ao evento. Mas, se falhar totalmente, o pod resultará na reconciliação de Job e em mais controladores de nível de contratação, como CronJob e outros CRDs, e pode haver muito mais chamadas de API.

quero também ver se outras pessoas viram problemas semelhantes (/ cc @ kow3ns )

Essa mudança incorporaria o comportamento desejado em https://github.com/kubernetes/community/pull/2342 , de modo que houvesse uma maneira de configurar todo o pod (ou apenas o contêiner não secundário) para reiniciar se um sidecar falha?

@JacobHenner atualmente não há planos para implementar esse tipo de mecanismo neste KEP, discutimos incorporá-lo, mas ele realmente não depende muito deste KEP e poderia ser desenvolvido independentemente dele. Portanto, parece mais adequado para ter seu próprio KEP.

@ Joseph-Irving apenas para compartilhar nosso implemento que abordou as armadilhas acima mencionadas para sua referência (https://github.com/zhan849/kubernetes/commits/kubelet-sidecar), já que nosso objetivo é aguardar o suporte oficial, tentamos para manter a mudança o mais local possível neste commit.

portanto, para uma política de reinicialização de trabalho == Nunca, com 1 contêiner principal, 1 arquivo secundário ruim que trava constantemente, 1 arquivo secundário bom que continua em execução, o status do pod ficará assim após o contêiner principal encerrar com o impl.

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

Em geral, concordo que um KEP secundário precisa levar em consideração a fase do pod e a política de reinicialização antes de entrar em um estado implementável. Não me importa se é este KEP ou não, mas concordo em geral com os argumentos de @ zhan849 e precisa ser tratado aqui.

obrigado @smarterclayton !
@Joseph-Irving, deixe-nos saber se há mais alguma coisa que você gostaria que compartilhássemos com o carro lateral na prática.

@smarterclayton @ zhan849 , não discordo dos seus pontos de vista, apenas tento apresentar alguns contra-argumentos. Foi uma escolha consciente não alterar as fases do pod / política de reinicialização, pois isso aumentaria ainda mais o escopo desta proposta e ninguém se preocupou muito com isso.

Vou levar esse feedback de volta para sig-apps / sig-node e ver o que eles pensam. sig-node em particular estavam interessados ​​em manter os carros laterais o mais próximo possível dos contêineres normais, se @derekwaynecarr ou @ dchen1107 quiserem

O plano de teste https://github.com/kubernetes/enhancements/pull/951 e o design de API https://github.com/kubernetes/enhancements/pull/919 PRs foram agora mesclados.

Abri https://github.com/kubernetes/enhancements/pull/1109 para marcar o KEP como implementável, uma vez que todos estão felizes com o fato de podermos iniciar o desenvolvimento como alfa em 1.16 🤞

Este Kep foi marcado como implementável, então irei aumentar os PRs para colocá-lo em 1.16 a partir da próxima semana!

Criei https://github.com/kubernetes/kubernetes/pull/79649 para implementar a API, terei um PR separado para as alterações do Kubelet.

Olá, @ Joseph-Irving, sou o líder de aprimoramento do 1.16. Este recurso vai graduar estágios alfa / beta / estável no 1.16? Informe-me para que possa ser adicionado à planilha de rastreamento 1.16 . Se não estiver se formando, vou removê-lo do marco e mudar o rótulo rastreado.

Assim que a codificação começar ou se já tiver começado, liste todos os PRs k / k relevantes nesta edição para que possam ser rastreados corretamente.

As datas dos marcos são Enhancement Freeze 7/30 e Code Freeze 29/8.

Obrigada.

@ Joseph-Irving Se você quiser / precisar de algumas pessoas extras para implementar isso, tenho muito interesse neste pouso, então estou feliz em ajudar.

Olá @ kacole2, este é o alvo do Alpha para 1.16, o KEP foi marcado como implementável.
O único PR para isso atualmente é kubernetes / kubernetes # 79649 para a API

@mhuxtable Eu estarei levantando o PR para as mudanças no kubelet em breve, apenas terminando algumas coisas, eu agradeceria muito a ajuda para dar uma olhada nisso. Vou vinculá-lo aqui quando for levantado.

Abri https://github.com/kubernetes/kubernetes/pull/80744 que implementa as mudanças do kubelet.

Observe que kubernetes / kubernetes # 79649 (api) ainda está aberto, portanto, este PR contém commits dele, fazendo com que pareça grande. Eu o dividi em commits em que cada um implementa um bit diferente de funcionalidade, então deve ser fácil revisá-lo dessa forma.

Ainda não terminei de fazer todos os casos de teste para isso, mas o primeiro rascunho da implementação de trabalho está feito, então gostaria que as pessoas dessem uma olhada.

cc @ kacole2

@ Joseph-Irving

Eu sou uma das sombras do docs v1.16.
Este aprimoramento (ou o trabalho planejado para a v1.16) requer novos documentos (ou modificações nos documentos existentes)? Se não, você pode atualizar a Folha de Rastreador de Aprimoramento 1.16 (ou me avise e eu o farei)

Em caso afirmativo, apenas um lembrete amigável de que estamos procurando um PR contra k / website (branch dev-1.16) com vencimento até sexta-feira, 23 de agosto, pode ser apenas um PR no momento. Deixe-me saber se você tiver alguma dúvida!

Olá @daminisatya , sim, isso vai precisar de atualizações para o Google Docs. Eu criei https://github.com/kubernetes/website/pull/15693 como um RP de espaço reservado.
Gostaria de saber se alguém tem alguma opinião sobre para onde o Docs deve ir, coloquei algo em content/en/docs/concepts/workloads/pods/pod-lifecycle.md por enquanto.

Com menos de uma semana para o Code Freeze, parece muito improvável que ele seja capaz de chegar ao 1.16.
Ainda temos dois PRs abertos relativamente grandes, kubernetes / kubernetes # 80744 e kubernetes / kubernetes # 79649, que têm dificuldade em obter comentários.
Esperançosamente, haverá mais largura de banda do revisor no próximo ciclo de lançamento.

/atribuir

Isso poderia permitir a gravação de um arquivo secundário que possa iniciar o serviço real sob demanda (e destruí-lo)?

Como escalar até zero, mas a única coisa que está funcionando enquanto ocioso é o sidecar. Quando a solicitação chega, ele ativa o serviço real e, após uma última resposta, por exemplo, 30s, ele o fecha. Isso poderia permitir uma maneira simples de dimensionar para quase zero (com apenas os carros laterais em execução).

@Ciantic With Operator Framework você pode fazer isso e muito mais. Dê uma olhada

@janosroden Eu olhei, mas parece muito difícil entender como eu elevaria os serviços em execução a um escalonável zero.

O problema não é que não haja opções disponíveis, por exemplo, Osiris , Keda ou Knative . Tentei o último, mas ele consome 8 Gb de memória, difícil dizer que não tem servidor nesse ponto.

O problema é que a maioria dessas implementações precisam de novos recursos etc. é muito mais fácil pensar isso para que se possa injetar um sidecar que pode controlar todo o ciclo de vida (incluindo iniciar e reiniciar sob demanda) para que possa controlar o serviço além de apenas sentado lá.

Por que isso seria benéfico? É muito útil em situações de baixa utilização e pouca memória, por exemplo, k3s com Raspberry Pi ou Digital Ocean droplet para projetos de hobby. Muitos de nós temos muitos serviços da web que não precisam estar em execução o tempo todo, basta ter um arquivo secundário que possa ativá-los sob demanda.

Não tenho certeza se isso realmente funciona para o seu caso de uso. Eu vejo totalmente o desejo de fazer o que você quiser em tais sistemas com recursos limitados. Mas para ficar realmente estável, você precisa usar solicitações de recursos para ajudar a programar a carga de trabalho. Eles precisam ser especificados antecipadamente, portanto, independentemente se a carga de trabalho está em execução ou não, ele deve reservar o recurso.

Para contornar isso, você precisa basicamente de um pod próprio para fazer o recebimento da conexão inicial e fazer uma nova solicitação de pod para o k8s, esperar que ele gire e enviar o tráfego para ele. Melhorias no contêiner de sidecar não são necessárias neste caso, eu acho. Você precisa de algo mais como um xinetd para k8s, eu acho.

Olá, @ Joseph-Irving - 1.17 As melhorias chegam aqui. Gostaria de verificar e ver se você acha que este aprimoramento será graduado para alfa em 1.17.

A programação de lançamento atual é:

• Segunda-feira, 23 de setembro - Começa o ciclo de lançamento
• Terça-feira, 15 de outubro, EOD PST - Congelamento de melhorias
• Quinta-feira, 14 de novembro, EOD PST - Código Congelado
• Terça-feira, 19 de novembro - os documentos devem ser preenchidos e revisados
• Segunda-feira, 9 de dezembro - Kubernetes 1.17.0 lançado

Em caso afirmativo, assim que a codificação começar, liste todos os PRs k / k relevantes nesta edição para que possam ser rastreados corretamente. 👍

Obrigado!

Olá @mrbobbytables , presumindo que possamos revisar tudo a tempo, o plano é passar para alfa em 1.17.

Os atuais PRs abertos são:
https://github.com/kubernetes/kubernetes/pull/79649 - Alterações de API
https://github.com/kubernetes/kubernetes/pull/80744 - Alterações do Kubelet

Avise-me se precisar de mais alguma coisa.

Excelente! Obrigado @ Joseph-Irving, vou adicionar as informações à folha de acompanhamento 👍

@ Joseph-Irving

Eu sou uma das sombras de docs v1.17.
Este aprimoramento (ou o trabalho planejado para v1.17) requer novos documentos (ou modificações nos documentos existentes)? Se não, você pode atualizar a Folha de Rastreador de Aprimoramento 1.17 (ou me avise e eu o farei)

Em caso afirmativo, apenas um lembrete amigável de que estamos procurando um PR para o site k / (branch dev-1.17) com vencimento até sexta-feira, 8 de novembro, pode ser apenas um PR no momento. Deixe-me saber se você tiver alguma dúvida!

Obrigado!

Olá @ VineethReddy02, sim, isso exigirá documentação, o marcador de posição está aqui https://github.com/kubernetes/website/pull/17190

Eu criei um PR para atualizar o KEP https://github.com/kubernetes/enhancements/pull/1344 com base em algumas discussões que estávamos tendo no PR de implementação https://github.com/kubernetes/kubernetes/pull / 80744.

Eu agradeceria qualquer comentário

Olá @ Joseph-Irving 1.17 Enhancement Shadow aqui! 👋 Estou entrando em contato para verificar como está esse aprimoramento.

A equipe de aprimoramento está rastreando kubernetes / kubernetes # 79649 e kubernetes / kubernetes # 80744 na planilha de rastreamento. Existem outros K / K PRs que também precisam ser rastreados?

Além disso, outro lembrete amigável de que estamos nos aproximando rapidamente do congelamento de código (14 de novembro).

Olá @annajung , sim, esses são os únicos PRs que precisam de rastreamento.

Olá @ Joseph-Irving, Amanhã é o congelamento do código para o ciclo de lançamento 1.17 . Parece que os PRs k / k não foram mesclados. Estamos sinalizando este aprimoramento como At Risk na planilha de rastreamento 1.17.

Você acha que todos os PRs necessários serão mesclados pela EoD do dia 14 (quinta-feira)? Depois disso, apenas problemas de bloqueio de liberação e PRs serão permitidos no marco, com uma exceção.

Olá @annajung , infelizmente parece muito improvável que eles sejam mesclados antes do congelamento do código. Fizemos muito progresso neste ciclo de lançamento, então esperamos poder mesclá-los no início do 1.18.

Ei @ Joseph-Irving Obrigado pela atualização. Vou atualizar o marco de acordo e marcar este aprimoramento como adiado para 1.18. Obrigado!

/ milestone v1.18

Olá, @ Joseph-Irving. 1.18 Melhorias Liderar aqui 👋.

A versão 1.18 começou ontem, então estou entrando em contato para ver se você planeja lançar isso na versão 1.18. Acho que falhou 1.17 por causa do congelamento do código. Como estão as coisas no 1.18? Vejo que os PRs ainda estão abertos.

Obrigado!

Olá @jeremyrickard ,

Sim, o plano é conseguir isso na versão 1.18.

O PR API (https://github.com/kubernetes/kubernetes/pull/79649) recebeu uma avaliação de thockin, outro dia, ele tinha alguns pontos, mas assim que esses forem resolvidos vamos fechar esse PR e incorporar os commits em (https://github.com/kubernetes/kubernetes/pull/80744) para que possamos mesclar a API e a implementação.

Quanto ao Kubelet PR (https://github.com/kubernetes/kubernetes/pull/80744), ele só precisa ser revisado, espero que possamos obter alguma largura de banda do nó de sig para revisá-lo neste ciclo.

Obrigado pela atualização @ Joseph-Irving

Adicionado na folha de acompanhamento!

Desculpe pelo atraso na festa. Esta é uma melhoria significativa para casos comuns. Mas não parece cobrir um caso mais avançado.

Considere um caso de arquivo secundário que exporta registros que também dependem do arquivo secundário do Istio. Se o arquivo secundário do Istio for desligado primeiro, alguns registros confidenciais podem não ser exportados.

Uma abordagem mais genérica seria definir dependências explícitas entre os contêineres. Independentemente de serem carros laterais ou não.

O que você acha dessa definição de API em vez disso:

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

@rubenhak isso fica bagunçado muito rápido. O que precisa ser satisfeito para que a dependência fique clara para prosseguir? Freqüentemente, há uma lacuna entre iniciado e pronto que eu acho que o dependsOn realmente se preocupa com o que a API não aborda.

@ kfox1111 Como o design proposto determina que o sidecar foi iniciado e está pronto para lançar o contêiner principal? A única diferença que proponho é que em vez de marcar contêineres como "arquivo secundário", é usar uma forma mais genérica de definir dependência.

Não acho que dependsOn deva especificar critérios. Ele pode ser especificado no contêiner dependente. ReadinessProbe e / ou livenessProbe não seriam suficientes? Caso contrário, pode haver um startupProbe - cujo sucesso indica que os contêineres dependentes podem ser iniciados.

Olá @ Joseph-Irving, sou uma das sombras da documentação v1.18.
Este aprimoramento para (ou o trabalho planejado para v1.18) requer novos documentos (ou modificações nos documentos existentes)? Se não, você pode atualizar a Folha de Rastreador de Aprimoramento 1.18 (ou me avise e eu o farei)

Em caso afirmativo, apenas um lembrete amigável de que estamos procurando um PR contra k / website (branch dev-1.18) com vencimento até sexta-feira, 28 de fevereiro., Pode ser apenas um PR no momento. Deixe-me saber se você tiver alguma dúvida!

Olá @irvifa , levantei um marcador de posição aqui https://github.com/kubernetes/website/pull/19046

Olá @ Joseph-Irving. Obrigado pela sua resposta rápida!

@rubenhak - Eu concordo com @ kfox1111 que ter um gráfico completo de dependências pode ficar complicado rapidamente. Que tal iniciar os contêineres na ordem das especificações do pod e, em seguida, separá-los na ordem inversa (como uma pilha)? Isso seria muito mais simples de implementar e cobre a maioria dos casos de uso de pedidos comuns que posso imaginar.

@rgulewich , você poderia elaborar um pouco mais, o que exatamente pode ficar confuso? Derivar ordem do gráfico é uma tarefa trivial, especialmente considerando o fato de que nenhum operador lógico executaria mais do que 15 carros laterais (já um trecho).

A ideia do pedido está ok, mas como a maioria dos sidecars são injetados usando controladores de admissão, seria muito difícil garantir a correção do pedido. Existe uma necessidade de indireção.

@rubenhak pode haver um ciclo na ordem de dependência dos contêineres, como o k8s / kubelet decide quebrar o ciclo e decidir em que ordem iniciar / parar os contêineres? Pensando em voz alta, talvez isso possa ser uma validação do lado da API.

Olá, @ Joseph-Irving,

Apenas um lembrete de que o congelamento de código para 1.18 é em 5 de março de 2020 .

Enquanto seguimos em direção ao congelamento do código, liste / conecte-se a todos os PRs em que você está trabalhando para graduar este aprimoramento!

Ei @jeremyrickard ,

É o pr para rastrear https://github.com/kubernetes/kubernetes/pull/80744
Este PR contém mudanças de API, mas terá os commits mesclados no PR acima assim que a revisão for concluída https://github.com/kubernetes/kubernetes/pull/79649

@rubenhak pode haver um ciclo na ordem de dependência dos contêineres, como o k8s / kubelet decide quebrar o ciclo e decidir em que ordem iniciar / parar os contêineres? Pensando em voz alta, talvez isso possa ser uma validação do lado da API.

@bjhaid , o lado da API pode fazer a validação. A detecção de loop é um algoritmo trivial com uma complexidade de tempo linear (assim como a passagem DFS).

Também pode ser necessário executar novamente a validação após a injeção secundária.

Eu estive pensando sobre isso por um tempo ... A maioria dos problemas com dependências realmente se resumem, eu acho, a malhas de serviço. (talvez alguém possa pensar em outro exemplo)

O proxy de malha de serviço é um arquivo secundário que precisa ser iniciado e estar pronto antes de qualquer coisa, e deve ser encerrado após qualquer outra coisa. Eles são de longa execução, portanto, são mais um arquivo secundário do que um contêiner init.

Mas, de maneira ideal, os initContainers devem ser todos capazes de usar a malha de serviço também.

Mas o initContainers pode precisar iniciar outros contêineres secundários.

Embora pudéssemos projetar algum tipo de sistema de dependência intrincado envolvendo contêineres init, contêineres secundários e contêineres regulares, talvez devêssemos ter apenas duas classes de sidecars? sidecars regulares e sidecars de rede?

os sidecars da rede devem estar prontos desde o início. proxies de malha de serviço clique aqui.
Os contêineres init são executados em seguida na ordem.
os sidecars começam e ficam prontos. Isso pode incluir coisas como proxies de autenticação, loggers, etc.
os contêineres regulares começam e ficam prontos.

derrubar é ao contrário.

Isso eliminaria o problema de dependência e, ao mesmo tempo, resolveria todos os problemas que as malhas de serviço parecem ter com os pedidos de contêineres? Estou pensando assim?

@ kfox1111 , o Vault agora faz injeção secreta usando sidecars. Em qual classe ele deve se encaixar? Além disso, dependendo do caso, o vault pode depender da malha de serviço ou o contrário.

Tudo o que estou dizendo é que esse projeto acabaria explodindo em 10 classes de sidecar. Essa abordagem implica uma opinião ainda mais forte sobre como as coisas devem funcionar. As pessoas começariam a hackear com classes, apenas para cumprir a ordem necessária para iniciar o aplicativo.

Se o único propósito dessas classes é definir a ordem, por que não fazer isso explicitamente?

Respondendo à sua pergunta, embora tal design abranja alguns casos de uso, ele não ajuda em outros casos, como sidecars de vault, sidecars de registro, etc. Esta já é uma proposta para redesenhar o recurso original. Como se trata de uma segunda tentativa, vale acertar desta vez.

Não sei como as dependências são complicadas. Você poderia elaborar mais sobre isso? As dependências tornam as definições YAML mais óbvias, não há lógica oculta. A abordagem com classes codificadas exigiria lógica oculta e muito mais documentação explicando por que os sidecars de rede devem ser executados após outros sidecars, etc.

E se introduzirmos um campo no Container?

    // +optional
    Priority int

Este campo é efetivo entre contêineres do mesmo tipo (sidecar, normal).
Para contêineres secundários, o contêiner secundário com prioridade mais alta seria instanciado primeiro / demolido por último.

@tedyu , a dependência tem muito mais metadados e valor em comparação com "prioridade". São necessárias 30 linhas de código c ++ para produzir a ordem de prioridade dada a dependência https://www.geeksforgeeks.org/find-the-ordering-of-tasks-from-given-dependencies/ . O contrário não é possível.

Outro benefício é que determinado gráfico de dependência, certos contêineres podem ser iniciados ao mesmo tempo.
No exemplo a seguir: "A -> B, B -> C, D -> C" os contêineres B e D podem ser iniciados ao mesmo tempo se C for inicializado. Não estou dizendo que a implementação deve suportar isso, mas pelo menos pode ser muito valioso se a API permitir tal definição.

A prioridade do inteiro não funcionará bem - as pessoas usarão todos os tipos de números diferentes e não padronizados, como fazem com a propriedade Z-index do CSS (como -9999 ).

@rubenhak O que você está sugerindo neste ponto é basicamente um recurso totalmente diferente daquele que está sendo descrito neste KEP, não é um pequeno ajuste, é uma reescrita total. Seria necessário fazer com que todos que haviam concordado anteriormente com esse recurso (levou um ano para que isso fosse aprovado por todas as partes) para reavaliar isso.
Se você é apaixonado por esse recurso, sugiro que crie seu próprio KEP e o leve aos vários SIGs para obter feedback sobre ele.

A ideia de um gráfico de dependência foi discutida longamente quando esta proposta começou em 2018, a conclusão foi unânime em que embora possibilitasse mais alguns casos de uso, eles não eram casos de uso fortes o suficiente e que a complexidade adicional não valeu a pena.

Acho que você está subestimando o grau de mudança necessário para implementar o que está descrevendo. Mas se for tão simples quanto você parece pensar, você poderia criar sua própria Prova de Conceito desse trabalho no Kubernetes e apresentá-la aos SIGs para ajudar a fortalecer seu caso.

Este KEP ainda não é um recurso GA. Se o seu KEP for aprovado e implementado, podemos removê-lo. Eles ainda não são mutuamente exclusivos.

Essa mudança pode não ser a solução perfeita para todos os casos de uso, mas melhora drasticamente a experiência para a maioria e acho que seria muito melhor fundir isso do que debater por mais um ano sobre a implementação.

se o seu KEP for aprovado e implementado, podemos remover este. Eles ainda não são mutuamente exclusivos.

Eles nunca seriam mutuamente exclusivos?

Estou me perguntando se esse recurso tem valor _even if_ ordem de inicialização / desligamento de contêiner mais explícita (o que eu acho que seria ótimo) é habilitado por meio de outro aprimoramento no futuro ... e estou pensando que sim.

Qualquer ordem de inicialização / desligamento, que está implícita na classificação de contêineres como init, sidecar ou "regular" separada, essas classificações também expressam _outros_ aspectos úteis e indiscutivelmente não relacionados do comportamento desejado de um contêiner, não é?

Por exemplo, é útil em um pod com restartPolicy != Always (um pod que implementa um trabalho, talvez), que os contêineres designados como laterais não tenham relação com um pod que entra em um estado concluído.

@ kfox1111 , o Vault agora faz injeção secreta usando sidecars. Em qual classe ele deve se encaixar? Além disso, dependendo do caso, o vault pode depender da malha de serviço ou o contrário.

Trabalhamos com drivers csi efêmeros para que coisas como o vault não precisassem de contêineres Sidecars / init. Acredito que haja um driver de cofre em andamento.

Embora o arquivo secundário regular com emptyDir pareça adequado para um arquivo secundário que precisa usar os carros secundários da rede?

@ Joseph-Irving, de forma alguma estava tentando bloquear este KEP de entrar. Eu sei que você começou há quase 2 anos e há muitas pessoas esperando para que isso fosse lançado.

Você tem um link para uma discussão anterior relacionada ao gráfico de dependência?

Olá, @ Joseph-Irving,

Lembrete amigável de que estamos nos aproximando muito rapidamente do congelamento de código em 05 de março de 2020 . Parece que seus PRs ainda não foram mesclados. Você ainda está se sentindo no caminho para congelar o código para este aprimoramento?

Olá @jeremyrickard , A revisão da API (https://github.com/kubernetes/kubernetes/pull/79649) está basicamente concluída. Estaremos fechando esse PR e nos movendo inteiramente para o PR de implementação para que tudo (API e Implementação) seja mesclado em um PR.

O PR de implementação (https://github.com/kubernetes/kubernetes/pull/80744) foi completamente revisado, então estou tentando fazer com que um aprovador de nó de assinatura analise a aprovação final.

Se isso acontecerá a tempo de congelar o código é um tanto difícil para mim dizer, depende muito de eu conseguir chamar a atenção de alguns aprovadores a tempo.

Adoraria ver isso entrar por congelamento de código. Isso tornaria a solução do Istio para https://github.com/istio/istio/issues/7136 mais simples e melhor.

Algum movimento em relação a 1.18? Parece necessário para que os carros laterais istio funcionem conforme o esperado com trabalhos de execução rápida.

Tentei entrar em contato com os aprovadores do nó de assinatura de várias maneiras, mas não recebi nenhuma resposta. Portanto, não estou muito otimista de que isso chegará ao 1.18.

@Joseph-Irving, o canal # pr-reviews slack foi criado para esses casos. Você já tentou isso? É uma forma de aumentar as avaliações de relações públicas. (Eu não vi lá)

Olá, @ Joseph-Irving,

Estamos há apenas alguns dias do congelamento do código agora. Você deseja adiar para 1,19 com base na largura de banda do revisor? Ou tentar fazer um push?

Ei @jeremyrickard ,

Ninguém me respondeu sobre a fusão desses PRs no 1.18, então duvido muito que isso aconteça.

Podemos adiar para 1.19, mas estou começando a me perguntar se vale a pena fazer isso.
Este KEP está em vôo há quase dois anos (o alvo alfa original era 1.15), os PRs em questão estão abertos há quase 1 ano, nunca há nenhuma "largura de banda do revisor" para eles.
Eu educadamente mandei e-mails, relaxei, fui a reuniões de assinatura e até mesmo encontrei pessoas pessoalmente para receber avaliações, mas fizemos muito pouco progresso.
Todas as análises que consegui obter sugeriram apenas pequenas alterações, não é como se grandes reescritas tivessem sido solicitadas, os PRs são basicamente os mesmos de um ano atrás, apenas um pouco mais polidos.
Não sei se devo dar um ping agressivo nas pessoas todos os dias até que elas me respondam, mas isso não é algo que me sinta confortável em fazer.

Acho que o problema é mais que ninguém realmente se preocupa com esse recurso, eu sou o único que está impulsionando esse recurso, ninguém nos SIGs parece interessado em ver isso. Se leva dois anos para chegar ao alfa, quanto tempo vai demorar para chegar ao beta / GA? (como quando a maioria das pessoas pode realmente usar isso)

Frustrante, parece haver interesse da comunidade mais ampla e dos usuários finais em obter esse recurso. A razão de eu ter feito isso em primeiro lugar é que vi que era um problema, perguntando aos SIGs se eles iriam consertá-lo, e eles disse "não temos capacidade, mas ficaríamos felizes se você fizesse isso".
Então fiz tudo o que eles pediram, escrevi o KEP, consegui a aprovação de todas as partes, escrevi todo o código, todos os testes, mantive-o constantemente atualizado a cada lançamento e, mesmo assim, aqui estamos.

Cada vez que atrasamos isso, sinto que estou decepcionando um monte de gente, é tudo culpa minha? o código é tão terrível que ninguém vai comentar? não sou agressivo o suficiente para tentar chamar a atenção?
Só sinto que não consigo fazer isso sozinho e estou ficando um pouco cansado de bater neste cavalo morto.

Sinto muito pelo longo discurso (não dirigido a você pessoalmente, Jeremy ou a qualquer pessoa pessoalmente), mas isso tem corroído minha alma lentamente por um longo tempo.

Frustrante, parece haver interesse da comunidade mais ampla e dos usuários finais em obter esse recurso. A razão de eu ter feito isso em primeiro lugar é que vi que era um problema, perguntando aos SIGs se eles iriam consertá-lo, e eles disse "não temos capacidade, mas ficaríamos felizes se você fizesse isso".

@ Joseph-Irving Sobre isso. Como um usuário ativo, acompanho este tópico porque estou interessado (e dois de meus colegas também). Atividade sobre a questão, solicitação de pull, canais de folga ou sigs podem não ser o melhor indicador de interesse neste recurso.

@dims Talvez você possa lançar alguma luz?

@thockin Eu ouvi você sendo entrevistado no Podcast do Kubernetes há cerca de um ano e você falou sobre como contribuir para o Kubernetes. Talvez tenha sido você ou outra pessoa em outro episódio de podcast que se sentiu muito mal por esse carro lateral KEP não ter chegado a 1.16. Bem, aqui estamos novamente.

Esta questão parece ser um excelente exemplo de como pode ser difícil contribuir se você não for funcionário da, por exemplo. Google, RedHat ou outro grande jogador.

Também pedi ajuda no Slack para revisá- lo, mas acabaram de ser informados de que há uma retenção explícita de

Passei muito tempo no recurso de driver csi efêmero. Conseguir passar foi igualmente frustrante e houve momentos em que eu não tinha certeza se iria dar certo depois de tantos atrasos e reformulações. Então, eu sinto sua dor. Seria ótimo se pudéssemos encontrar uma maneira de torná-lo menos doloroso. Dito isso, também conseguimos, eventualmente, depois de perder alguns lançamentos importantes. Então, por favor, não desista / perca as esperanças! O navio pode ser difícil de virar, mas acaba virando.

Qualquer pessoa executando qualquer tipo de topologia que dependa de um arquivo secundário de rede provavelmente está enfrentando problemas de ordem de inicialização / desligamento de contêiner que este KEP potencialmente resolveria. Ctrl-F para "Istio" neste tíquete, e você verá um monte de aborrecimentos relacionados à ordenação de contêineres.

Há algum mantenedor do Istio aqui? Muitos são Googlers e podem ter mais influência com o pessoal do K8s internamente.

Como uma loja do Istio / K8s, estamos absolutamente torcendo para que você consiga isso, @ Joseph-Irving! ✊❤️

parabéns a @Joseph-Irving por fazer carro lateral tão longe.

Mesmo para o gerenciamento do ciclo de vida secundário, qualquer trabalho em lote exigiria esse recurso ou o Kubernetes simplesmente não funciona para eles, e é por isso que passamos muito tempo ajudando também nas revisões de código e fornecendo feedbacks!

Estamos criando um fork do k8s por um tempo por causa disso e estamos realmente ansiosos para ver esse recurso importante suportado oficialmente.

Como uma loja do Istio + Kubernetes, também esperamos ansiosamente por esse recurso. E ficando cada vez mais frustrado por deslizar de uma versão para outra. Não temos o prazer de ter que recorrer a hacks para matar os sidecars em cargas de trabalho. Para nossas necessidades, esse é o recurso mais importante de que precisamos no Kubernetes, há mais de um ano.

@thockin Foi relatado acima que você colocou um controle explícito sobre isso. Você pode explicar o porquê.

Existem muitos usuários do Linkerd que também estão esperando ansiosamente por isso. Aguente firme @ Joseph-Irving, estamos torcendo por você.

Não tenho certeza se todos os outros aqui viram, mas depois de pesquisar e assistir a um vídeo do kubecon, descobri que Lyft fez algo semelhante a isso. Aqui está o commit mencionado do fork do kubernetes: https://github.com/lyft/kubernetes/commit/ba9e7975957d61a7b68adb75f007c410fc9c80cc

Como uma loja do Istio + Kubernetes, também esperamos ansiosamente por esse recurso. E ficando cada vez mais frustrado por deslizar de uma versão para outra.

Sou um potencial usuário de istio, mas me mantive um pouco à margem devido à espera de um recurso como este. Durante as discussões acima, porém, continuo vendo coisas que me fazem pensar que o recurso sidecar sozinho, conforme discutido aqui, não resolverá todos os problemas que o istio sidecar tem com o fluxo de trabalho. No entanto, pode ajudar. O que eu acho que é parte do motivo pelo qual isso estagnou.

Como funciona a execução do istio em um sidecar ao usar o driver istio cni? Acredito que os containers init que tentam alcançar a rede ainda não funcionarão corretamente, conforme documentado na documentação do istio.

daí minha pergunta acima se os sidecars de rede são uma coisa própria.

Esta questão parece ser um excelente exemplo de como pode ser difícil contribuir se você não for funcionário da, por exemplo. Google, RedHat ou outro grande jogador.

Hah! O que você não sabe é que essas pessoas às vezes também ficam presas!

Sério, sinto muito. Eu tenho desculpas, mas isso é uma merda, então não vou incomodar.

Para esclarecimento:
Não estou sugerindo que não devemos mesclar isso como alfa para obter algum feedback sobre a abordagem. Em geral, acho que é bom. Acho que há alguns buracos nos casos de uso, como malhas de serviço, que não cobrem muito bem. Mas isso não é um motivo para bloquear a obtenção disso o mais rápido possível, para que possamos encontrar todos os outros casos de uso que não abrange, para que possamos fazer a versão beta do recurso funcionar bem para todos. Isso é exatamente o que um alfa é para a IMO.

Estou apenas mencionando o que fiz, especificamente para as pessoas que esperam que isso seja uma solução mágica para o problema de malha de serviço existente. Não acho que o alfa, conforme proposto, consertará totalmente esse problema específico. Portanto, não tenha muitas esperanças ainda. Mas, por favor, não vamos bloquear esse recurso só porque ele ainda não oferece suporte a todos.

Solicitei uma exceção, vamos ver se podemos tentar fazer isso em:
https://groups.google.com/d/msg/kubernetes-sig-release/RHbkIvAmIGM/nNUthrQsCQAJ

Talvez tenha sido você ou outra pessoa em outro episódio [Podcast do Kubernetes] que se sentiu muito mal por este sidecar KEP não ter chegado a 1,16

Veja os episódios 72, com Lachie Evenson , e 83, com Guinevere Saenger . Eu até gritei esta semana que análises de RP são necessárias para resolver esse problema. Nós podemos fazer isso!

Há algum mantenedor do Istio aqui? Muitos são Googlers e podem ter mais influência com o pessoal do K8s internamente.

@duderino e @howardjohn já comentaram neste tópico.

Para ficar claro, precisamos mesclar:
kubernetes / kubernetes # 79649
kubernetes / kubernetes # 80744

Há algum outro PR que devemos rastrear?

Obrigado!

• Equipe de melhorias

Muito obrigado a todos que postaram mensagens de apoio (públicas ou privadas) que foram muito apreciadas ❤️

Houve um grande esforço por parte dos membros da comunidade para tentar colocar isso no 1.18, incluindo a equipe de liberação que aceitou um pedido de extensão, mas, infelizmente, foi tomada a decisão de adiar para o 1.19. Você pode ver a conversa relevante a partir deste comentário: https://github.com/kubernetes/kubernetes/pull/80744#issuecomment -595292034.

Apesar de não ter chegado ao 1.18, ele teve muito mais atenção nos últimos dias do que em muito tempo, então espero que esse ímpeto seja levado para o 1.19.

cc @jeremyrickard , @kikisdeliveryservice

Grande coisa @ Joseph-Irving, parece que algumas de suas frustrações valeram a pena e foram ouvidas. Obrigado por perseverar.

/ milestone v1.19

Olá a todos. Um grupo de nós tem discutido esse tópico na semana passada.

Em primeiro lugar, pedimos desculpas pelo que aconteceu aqui. Não estamos felizes com isso.

Este PR e o KEP associado trouxeram à luz uma série de coisas que o projeto pode fazer melhor. Gostaríamos de separar as questões sociais, processuais e técnicas.

Socialmente, esse recurso foi vítima de nosso desejo de agradar um ao outro. Derek aprovou o KEP, apesar das reservas expressas dentro do SIG, porque Clayton e Tim estavam pressionando por ele. Todos nós confiamos uns nos outros, mas aparentemente nem sempre nos sentimos capazes de dizer “não”. Sabemos disso porque todos nós fizemos exatamente a mesma coisa. Nenhum de nós quer ser o bloqueador da próxima grande ideia.

Confiar uns nos outros deve incluir confiar que podemos dizer “não” e confiar que, quando alguém diz “não”, está fazendo isso por bons motivos. Esta área técnica abrange SIGs, e NÃO devemos pressionar sig-node, que em última análise serão os únicos a lidar com os problemas, a aceitar novos recursos que ainda não são confortáveis ​​para suportar. Não se trata de Tim ou Derek ou Clayton em particular, mas TODOS os aprovadores de alto nível e líderes SIG e contribuidores “seniores”.

Esse recurso também foi vítima de incertezas processuais em torno dos KEPs. Como revisor KEP, sou obrigado a ser revisor de código? Para delegar a um revisor de código? Ou apenas para ler o KEP? À medida que os KEPs abrangem as versões, como podemos garantir que um pastor esteja disponível para o conjunto de alterações orçadas em uma determinada extensão de versões. Se um KEP abrange SIGs, como fazemos o orçamento e alocamos o tempo entre os SIGs? Precisamos esclarecer isso. Vamos trabalhar em algumas propostas de mudança KEP (KEP KEPs) para fortalecer a definição de papéis no processo KEP.

Tecnicamente, esse recurso foi vítima de tempo e atenção. Os revisores não reservaram tempo suficiente para revisá-lo ou simplesmente não era uma prioridade alta o suficiente para eles. As discussões intermináveis ​​levam tempo. As circunstâncias e nossa compreensão do espaço do problema mudam com o tempo.

À medida que mais usuários adotam o Kubernetes, vemos um número crescente de casos extremos estranhos ou flocos sendo relatados ao sig-node. Como o ciclo de vida do pod é fundamental para o Kubernetes, qualquer alteração feita nesse subsistema DEVE ser realizada com cuidado. Nossa capacidade de mesclar novos recursos deve ser equilibrada com nosso desejo de melhorar a confiabilidade. A forma como pensamos sobre o ciclo de vida do pod hoje é um pouco diferente de como pensávamos quando esse recurso foi iniciado. Isso não diminui os casos de uso que levaram a isso de forma alguma, mas sugere que os KEPs de longa duração precisam ser revistos periodicamente ao longo do tempo.

Achamos que precisamos pensar um pouco nos princípios básicos sobre o ciclo de vida do pod. O que realmente queremos? Tentamos não cair em muita complexidade, mas tememos que simplesmente dividimos essa complexidade em várias fases, e o resultado líquido pode ser MAIS complexo do que apenas enfrentá-lo de frente.

O que isso significa para este PR e o KEP associado? Não temos 100% de certeza. Provavelmente significa que NÃO devemos empurrar isso ainda, no entanto.

Derek levantou algumas preocupações sobre o sequenciamento de desligamento. O KEP chamou-os fora do escopo por enquanto, mas há alguma hesitação. Já não respeitamos a terminação normal no desligamento do nó, e isso surpreendeu muitos usuários. Não é culpa do KEP, mas vamos chamá-lo de “circunstâncias atenuantes”. Se alguém usar sidecars para “limpar” seus pods (por exemplo, para drenar logs em cache para um serviço de registro), eles irão esperar (razoavelmente) alguma semântica clara e útil sobre o desligamento, o que este KEP não garante.

Tim teme que o init-sidecars precise se tornar uma coisa, e isso não parece certo. Ele renunciou a essa preocupação no passado, mas ainda o incomoda.

Precisamos do SIG Node para ajudar a definir qual é o objetivo de médio prazo para o estilo de vida do pod e qual é seu apetite para assumir isso. Se pudermos concordar que este é um passo incremental em direção à meta, podemos desbloqueá-lo, mas a menos que conheçamos a meta, provavelmente estamos superando nossos faróis.

Sejamos todos os primeiros a dizer que isso fede. Temos declarações de problemas reais, um contribuidor apaixonado e um conjunto de mantenedores bem-intencionados e acabamos ... aqui. Tim oferecerá seu tempo como voluntário para ajudar no brainstorming e no design. Derek vai empurrar o trabalho de desligamento do nó para o ciclo de vida do pod atual para garantir que tenhamos uma base estável para aumentá-lo ainda mais. Precisaremos especificar com muito cuidado quais garantias podemos e não podemos oferecer diante de falhas não planejadas nas máquinas.

Obrigado,
Clayton, David, Dawn, Derek, John, Tim

Para tentar impulsionar algum movimento para a frente: Derek ou Dawn - há alguém em sig-node que pode arranjar tempo para fazer um brainstorming sobre um pod e ciclo de vida de contêiner mais holístico?

@thockin irá adicionar isso à agenda do nó de

@thockin @derekwaynecarr qual é o tl; dr porque não foi possível entrar?

Descrição de aprimoramento de uma linha: Os contêineres agora podem ser marcados como carros laterais para que sejam inicializados antes dos contêineres normais e desligados após o término de todos os outros contêineres.

Parece algo que tornaria a vida mais fácil nesta nova era de carros laterais de malha de serviço.

Além disso, alguma recomendação para que os sidecars sejam iniciados antes dos contêineres do aplicativo principal e desligados após o encerramento do contêiner do aplicativo principal hoje?

... qual é o tl; dr quanto a por que isso não poderia entrar?

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

O que isso significa para este PR e o KEP associado? Não temos 100% de certeza. Provavelmente significa que NÃO devemos empurrar isso ainda, no entanto.

Derek levantou algumas preocupações sobre o sequenciamento de desligamento. O KEP chamou-os fora do escopo por enquanto, mas há alguma hesitação. Já não respeitamos a terminação normal no desligamento do nó, e isso surpreendeu muitos usuários. Não é culpa do KEP, mas vamos chamá-lo de “circunstâncias atenuantes”. Se alguém usar sidecars para “limpar” seus pods (por exemplo, para drenar logs em cache para um serviço de registro), eles irão esperar (razoavelmente) alguma semântica clara e útil sobre o desligamento, o que este KEP não garante.

[...]

Precisamos do SIG Node para ajudar a definir qual é o objetivo de médio prazo para o estilo de vida do pod e qual é seu apetite para assumir isso. Se pudermos concordar que isso _é_ um passo incremental em direção à meta, podemos desbloqueá-lo, mas a menos que conheçamos a meta, provavelmente estamos ultrapassando nossos faróis.

Respeitosamente, estou curioso para saber se alguma pista planeja priorizar a resolução disso. @Joseph-Irving trabalhou muito nisso e um número impressionante de pessoas que teriam ficado felizes com sua solução estão ansiosas para ouvir alguma solução superior daqueles que a rejeitaram.

No mínimo, embora haja escrúpulos em alguns aspectos, acho que ainda é razoável entrar como um Alfa para descobrir quais problemas aparecerão na prática. Podemos mesclar isso? Os problemas podem impedir que ele se torne Beta, então não acho que seja crítico ficar perfeito antes de um Alpha inicial ser feito.

irá adicionar isso à agenda do nó de sig.

@thockin @derekwaynecarr há alguma atualização sobre o estado atual disso? Eu olhei as notas da reunião do nó de assinatura e não vi nada sobre isso.

Há um grande número de desenvolvedores neste segmento que ficariam mais do que felizes em contribuir com seu tempo para implementá-lo, já que é crítico para muitos casos de uso (o próprio KEP tem 2,5x mais: +1: como qualquer outro KEP). O que podemos fazer para que isso aconteça? Ter uma lista de pré-requisitos para a estabilidade desta área, mesmo que possa abranger muitos lançamentos a serem cumpridos, nos quais poderíamos começar a trabalhar ativamente seria uma grande melhoria de onde estamos hoje.

Olá, @ Joseph-Irving @thockin @khenidak @ kow3ns - 1.19 Líder de melhorias aqui, gostaria de verificar se você acha que esta melhoria seria graduada em 1.19.

Para ter esta parte do lançamento:

1. O KEP PR deve ser mesclado em um estado implementável
2. O KEP deve ter planos de teste
3. O KEP deve ter critérios de graduação.

A programação de lançamento atual é:

• Segunda-feira, 13 de abril: Semana 1 - Início do ciclo de lançamento
• Terça-feira, 19 de maio: Semana 6 - congelamento de melhorias
• Quinta-feira, 25 de junho: Semana 11 - Code Freeze
• Quinta-feira, 9 de julho: Semana 14 - os documentos devem ser concluídos e revisados
• Terça-feira, 4 de agosto: Semana 17 - Kubernetes v1.19.0 lançado

@palnabarun , De acordo com este comentário https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056, este KEP foi colocado em espera indefinida, então não, ele não será graduado em 1.19.

Obrigado @ Joseph-Irving por esclarecer a situação. : +1:

Aprecio seus esforços!

A todos que estão ansiosos para fazer isso, e novamente para @ Joseph-Irving - eu pessoalmente lamento muito por esta situação. Eu quero isso (ou algo parecido) também, mas o fato da questão é que sig-node tem mais trabalho a fazer do que pessoas para fazê-lo agora, e eles não estão prontos para considerar isso.

É uma merda. Entendo. Eu realmente quero.

A melhor maneira que as pessoas podem ajudar é pular para o nó de assinatura e ajudar a aumentar a capacidade, fazendo revisões de código e triagem de problemas, corrigindo bugs e testes e construindo em direção a um lugar onde os especialistas em nó de assinatura tenham mais capacidade e confiança em fazer tal mudança.

sig-node tem mais trabalho a fazer do que pessoas agora

Entendido. Temos promovido, com ênfase, as necessidades de capacidade do sig-node internamente. Estamos trazendo e orientando voluntários OSS sig-node, alguns com experiência, alguns novos, todos com o desejo de trabalhar neste espaço (quatro até agora). Estarei citando seu comentário @thockin , obrigado!

/ marco claro

A melhor maneira que as pessoas podem ajudar é pular para o nó de assinatura e ajudar a aumentar a capacidade, fazendo revisões de código e triagem de problemas, corrigindo bugs e testes e construindo em direção a um lugar onde os especialistas em nó de assinatura tenham mais capacidade e confiança em fazer tal mudança.

@thockin Você poderia fornecer links como repositórios, listas de discussão, guias, etc.? Isso ajudaria as pessoas a ter uma ideia sobre como se envolver com o sig-node efetivamente. Esta solicitação de recurso específico tem mais de 2 anos sem nenhuma resolução à vista.

@ tariq1890 as pessoas que escreveram este KEP fizeram tudo certo. eles não deixaram pedra sobre pedra. O problema aqui é exatamente o que @thockin disse, há uma dívida de tecnologia que precisamos consertar primeiro e mãos são necessárias para isso antes de podermos considerar este. Portanto, a solicitação é para que as pessoas ajudem no que precisa ser feito.

Consulte a atualização mais recente aqui: https://github.com/kubernetes/enhancements/pull/1874

@dims Acho que fui mal interpretado. O que eu quis dizer é que precisamos de uma lista de metas e objetivos viáveis. Se houver dívida de tecnologia a ser tratada, poderíamos manter um marco no GitHub ou fornecer uma lista com marcadores de itens de ação pendentes no comentário de OPs para que as pessoas que visitam esse problema possam saber imediatamente o que precisa ser resolvido.

Estou definitivamente disposto a oferecer minha ajuda para sig / node com o avanço deste KEP, mas simplesmente não sei como

@ tariq1890 a pergunta específica está aqui: "pré-requisito no desligamento normal do nó kubelet (ainda não enviado)" https://github.com/kubernetes/enhancements/pull/1874/files#diff -c6212b56619f2b462935ad5f631d772fR94

Precisamos começar. Alguém tem que assumir o ponto de vista e fazer isso funcionar.

- Escurece

Portanto, o resumo https://github.com/kubernetes/enhancements/pull/1874 para aqueles neste problema: Sig-node (e outros) pensam que não é aconselhável introduzir um novo recurso como este KEP, que adiciona um comportamento mais complexo para encerramento de pod, embora ainda haja o problema mais genérico de encerramento de pod enquanto um nó está sendo desligado.
Portanto, foi decidido que esse recurso não progredirá até que a solução para a terminação do nó tenha sido implementada.
Atualmente, há um documento do Google aqui: https://docs.google.com/document/d/1mPBLcNyrGzsLDA6unBn00mMwYzlP2tSct0n8lWfuRGE
Que contém muita discussão em torno do assunto, mas o KEP para isso ainda não foi enviado.
Ainda há questões em aberto, portanto, comentar sobre elas pode ser útil. Acredito que @bobbypage e @mrunalp estão liderando esse esforço, então talvez eles possam compartilhar outras maneiras pelas quais as pessoas possam ajudar a fazer isso.

@Joseph-Irving agradece muitíssimo por resumir. Espero que toda a energia + ve neste aprimoramento se traduza em mais participação de todos no nó de assinatura regularmente e não apenas em recursos. Há muito trabalho a fazer e poucas mãos.

Oi! Mais um comentário sobre este KEP, no entanto: levantei alguns casos extremos sobre este KEP em reuniões anteriores do nó SIG (23 de junho se você quiser assistir as gravações) e decidimos que a maneira adequada de continuar essa discussão é abrir PRs sobre eles questões para que possamos decidir a melhor maneira de proceder.

No momento, estou trabalhando em um RP para expor essas questões e algumas alternativas nas quais posso pensar.

Além disso, o estado KEP agora é provisório (em vez de implementável) para que possa ser revisado e apenas configurado para implementável novamente quando todas as pessoas concordarem se sentirem confortáveis ​​para seguir em frente com o KEP.

Acho que essa era a única informação que faltava nesta edição. Obrigado!

@rata Você abriu as questões / RP sobre a maneira adequada de lidar com as questões?

@mattfarina Este é o PR https://github.com/kubernetes/enhancements/pull/1913
Ele contém uma série de soluções propostas para os problemas atuais / casos extremos no KEP
Também contém detalhes de uma série de alternativas que foram discutidas e rejeitadas, para que possamos ter um registro melhor do motivo pelo qual certas decisões foram tomadas.

Eu gostaria muito de ver a funcionalidade de sidecar também cobrir o dimensionamento:
Hoje, o dimensionamento HPA é baseado em uma métrica (como cpu). Se o pod contiver mais de um contêiner, a média de todos os contêineres será usada (até onde eu sei). Para pods com sidecar (app + nginx etc), isso torna muito difícil fazer o dimensionamento funcionar corretamente. Eu esperava que a implementação secundária no Kubernetes incluísse a marcação de um contêiner no pod como "autorizado" em termos de métricas usadas para escalonamento HPA.

Eu gostaria muito de ver a funcionalidade de sidecar também cobrir o dimensionamento:

Eu concordo que isso seria útil, mas não é necessariamente específico "secundário" e, uma vez que a implementação está separada disso, pode fazer sentido torná-lo um problema separado - este já é muito complexo. Também não estou convencido de que você deseja simplesmente ignorar o sidecar. Em vez disso, podemos desejar o dimensionamento HPA por contêiner, por exemplo. Não tenho certeza - precisaria ser explorado como seu próprio problema, eu acho.

Alguém tem alguma referência ou poderia ser gentil em compartilhar a solução alternativa atual para esse problema, especificamente para o caso do sidecar do Enviado do Istio?

Lembro-me de uma possível solução alternativa envolvendo:

• uma imagem personalizada do Envoy que ignora SIGTERM.
• invocar / quitquitquit no Envoy de dentro do contêiner do aplicativo no desligamento (semelhante à solução alternativa de conclusão do trabalho)

Alguém tem alguma referência ou poderia ser gentil em compartilhar a solução alternativa atual para esse problema, especificamente para o caso do sidecar do Enviado do Istio?

Usamos uma imagem daemon personalizada como supervisor para embrulhar o programa do usuário. O daemon também ouvirá uma porta específica para transmitir o status de saúde dos programas dos usuários (encerrados ou não).

Aqui está a solução alternativa:

• Usando a imagem do daemon como initContainers para copiar o binário para um volume compartilhado.
• Nosso CD sequestrará o comando dos usuários, deixe o daemon iniciar primeiro. Em seguida, o daemon executa o programa do usuário até que o Envoy esteja pronto.
• Além disso, adicionamos preStop , um script que verifica continuamente o status de saúde do daemon, para o Envoy.

Como resultado, o processo dos usuários será iniciado se o Envoy estiver pronto, e o Envoy irá parar depois que o processo dos usuários for encerrado.

É uma solução alternativa complicada, mas funciona bem em nosso ambiente de produção.

O link na descrição dá um erro 404

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

Eu acho que deveria ser:

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

sim, foi movido em https://github.com/kubernetes/enhancements/pull/1913 , atualizei o link

Alguém tem alguma referência ou poderia ser gentil em compartilhar a solução alternativa atual para esse problema, especificamente para o caso do sidecar do Enviado do Istio?

@shaneqld para problemas de inicialização, a comunidade istio surgiu com uma solução alternativa bastante inteligente que basicamente injeta o envoy como o primeiro contêiner na lista de contêineres e adiciona um gancho postStart que verifica e espera que o envoy esteja pronto. Isso está bloqueando e os outros contêineres não são iniciados, garantindo que o envoy esteja lá e pronto antes de iniciar o contêiner do aplicativo.

Tivemos que portar isso para a versão que estamos executando, mas é bastante simples e estamos felizes com os resultados até agora.

Para o desligamento, também estamos 'resolvendo' com o gancho preStop, mas adicionando uma suspensão arbitrária que esperamos que o aplicativo desligue normalmente antes de continuar com o SIGTERM.

RP relacionado: https://github.com/kubernetes/enhancements/pull/1980

Olá @ Joseph-Irving @thockin e todos os outros: sorria:

Melhorias liderar aqui. Vejo que ainda há muita conversa em andamento, mas, como um lembrete, mantenha-nos atualizados sobre quaisquer planos para incluir isso no 1.20 para que possamos acompanhar o progresso.

Obrigado!
Kirsten

@kikisdeliveryservice o manterá informado, obrigado!

Alguém tem alguma referência ou poderia ser gentil em compartilhar a solução alternativa atual para esse problema, especificamente para o caso do sidecar do Enviado do Istio?

@shaneqld para problemas de inicialização, a comunidade istio surgiu com uma solução alternativa bastante inteligente que basicamente injeta o envoy como o primeiro contêiner na lista de contêineres e adiciona um gancho postStart que verifica e espera que o envoy esteja pronto. Isso está bloqueando e os outros contêineres não são iniciados, garantindo que o envoy esteja lá e pronto antes de iniciar o contêiner do aplicativo.

Tivemos que portar isso para a versão que estamos executando, mas é bastante simples e estamos felizes com os resultados até agora.

Para o desligamento, também estamos 'resolvendo' com o gancho preStop, mas adicionando uma suspensão arbitrária que esperamos que o aplicativo desligue normalmente antes de continuar com o SIGTERM.

Você poderia mostrar alguns insights em detalhes sobre como fazer isso? Como conseguir adicionar 'pré-parada' ao arquivo secundário do Istio-proxy? Parece que precisa de alguma configuração personalizada ou usar um arquivo secundário personalizado. Enfrento o mesmo problema que, quando os pods são reduzidos, o contêiner principal está tentando terminar os trabalhos, mas perde a conexão com o exterior, provavelmente porque o arquivo secundário do Istio fechou imediatamente após o SIGTERM. No momento, uso apenas a injeção secundária padrão. Obrigado!

Ok, este tópico está sendo sequestrado. Vamos continuar no tópico, por favor.

Apenas um lembrete de que o congelamento de aprimoramentos ocorre na próxima semana, terça-feira, 6 de outubro. Nesse momento, o KEP precisaria ser atualizado para ser marcado como implementável.

Além disso, o KEP está usando um formato mais antigo, então atualizar seria ótimo (assim que você terminar de acertar os detalhes): https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

@kikisdeliveryservice, obrigado pelo restante. Servirá se for decidido que será incluído para 1.20. Obrigado! :)

Isso não fará parte de 1.20. Muito obrigado pelo ping! :)

Tenho interesse neste problema e gostaria de agradecer a @ Joseph-Irving e @howardjohn por seus insights sobre isso, o que ajudou a resolver algumas de minhas dúvidas.

Não quero sequestrar essa proposta, mas com base nas conversas acima, me pergunto se essa é talvez uma questão um pouco mais ampla / maior do que foi reconhecido até agora.

Posso imaginar as seguintes soluções para esse problema -

1. Defina uma nova entidade de contêiner "contêiner secundário" que começa após initContainers, antes de "contêineres principais" e termina após o término de "contêineres principais" (de acordo com a proposta original de @ Joseph-Irving)
2. Defina um campo adicional em (1) que define se o "contêiner secundário" inicia antes de initContainer (s) por sugestão de @luksa ).
3. Vá mais longe.

Pessoalmente, a opção (2) resolve meu problema imediato.

Mas estou me perguntando se essas questões não abordam uma questão mais estratégica em K8s em torno de agendamento e como definimos um pod. No meu caso específico (relacionado ao Istio) , sugeri algo como níveis de execução dentro de pods.

A opção (2) também resolve meu problema, mas posso imaginar estruturas de dependência ainda mais complexas que podem exigir a incorporação de um DAG de dependências de contêiner em um pod / statefulSet / daemonSet / qualquer que seja - esta é a opção (3) em que estou pensando.

Você está se perguntando se esse problema realmente deveria ser redirecionado para a definição do pod em si, com o objetivo de criar algo mais genérico? Originalmente, pensei em termos de analogia de níveis de execução, mas talvez uma estrutura DAG semelhante ao Airflow tivesse a aplicabilidade mais ampla.

Que tal adicionar o envoy como container init também? Dessa forma, ele fornecerá rede para outros containers init. Quando o init terminar, ele irá 'sair 0' também, e então o enviado regular (não o init) assumirá

@michalzxc Se não estou errado, os containers init são executados um por um sequencialmente, então você não pode ter um enviado próximo a outro container como init-container .

Oi!

A discussão secundária continuou nestes lugares (eu atualizei sig-node slack, github PR que iniciou este e várias listas de discussão):
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 você pode ver, estamos coletando casos de uso agora, depois de termos mais alguns casos de uso, diferentes pequenos grupos podem criar pré-propostas abordando-os. Sinta-se à vontade para adicionar seu caso de uso (se ainda não estiver lá) ou junte-se mais tarde para a parte de pré-propostas :-)

Por favor, vamos manter este problema de aprimoramento no tópico (e provavelmente encerrado). Você está convidado a participar da conversa nesses lugares :)

Este KEP não irá progredir, Sig-node e outros acham que este não é um passo incremental na direção certa, então eles voltaram à prancheta e surgirão com alguns novos KEPs que podem, esperançosamente, resolver todo o uso casos indicados neste KEP, bem como em outros.

Por favor, veja @rata 's comentário anterior https://github.com/kubernetes/enhancements/issues/753#issuecomment -707014341
Para lugares onde você pode contribuir para a discussão.

É uma pena que todo o trabalho feito neste KEP não esteja sendo usado, mas um grupo mais amplo de pessoas agora está pensando sobre essas questões, então, esperançosamente, a solução que eles apresentarem será a melhor para todos.
Já passei mais de dois anos tentando fazer isso passar, então acho que é um bom momento para eu seguir em frente, @rata e outros irão liderar essas iniciativas daqui para frente.

/fechar

@ Joseph-Irving: Fechando esta edição.