Referência cruzada com kubernetes / kubernetes: problema nº 62822

Obrigado pela atualização!

/ assign @leblancd
/ tipo recurso
rede / sig
/ marco 1.11

@leblancd algum documento de design disponível?

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

@idvoretskyi - Nenhum documento de design ainda, mas começaremos a colaborar em um em breve.

Isso significa que o Kubernetes Ingress será compatível com Dual-Stack?
Isso significa que CNI (Calico) precisaria executar Dual stack (daemons BIRD e BIRD6, por exemplo)?

@ sb1975 - Com relação ao suporte de entrada de pilha dupla, isso é algo que precisamos resolver, mas aqui estão meus pensamentos preliminares:

• O suporte de entrada de pilha dupla dependerá principalmente de qual controlador de entrada você usa (se é compatível e como é implementado). Os controladores de entrada existentes provavelmente precisarão de algumas alterações para oferecer suporte a pilha dupla.
• Espero que a configuração de ingresso para um controlador de ingresso típico não mude (a configuração pode, por exemplo, ainda mapear um endereço L7 para um nome de serviço / porta de serviço, sem menção à família V4 / V6)
• No caso em que um serviço tem pods de endpoint com pilha dupla, o (s) controlador (es) de entrada podem precisar de mudanças para mapear os pacotes de entrada com base na família de pacotes, ou seja, mapear pacotes de entrada IPv4 para um endpoint IPv4 e mapear pacotes de entrada IPv6 para um endpoint IPv6. Para fins de ponderação de equilíbrio de carga, um ponto de extremidade de pilha dupla deve contar como um único destino de ponto de extremidade.

- Podemos querer considerar o suporte FUTURO para ter um mapa de controlador de ingresso entre famílias V4 / V6 (mapear pacotes IPv4 de ingresso para um back-end IPv6 e vice-versa), mas nosso desenvolvimento inicial será para pilha dupla estrita (ou seja, separados, independentes pilhas).

Em relação ao Calico e outros plug-ins CNI:

• Os plug-ins CNI NÃO PRECISAM ser executados no modo de pilha dupla se um cenário de cluster não exigir pilha dupla, eles ainda devem ser capazes de rodar somente IPv4 ou IPv6 (se o plug-in for compatível).
• O suporte de pilha dupla provavelmente exigirá mudanças nos vários plug-ins CNI, mas esse trabalho é considerado fora do escopo deste problema do Kubernetes (estamos nos concentrando em fazer o Kubernetes funcionar para qualquer plug-in de pilha dupla arbitrário, provavelmente usando o plug-in de ponte como uma referência), e o trabalho da CNI será feito separadamente, caso a caso.
• Para Calico especificamente, não sou um especialista, mas acredito que um único daemon BIRD pode ser configurado para lidar com as rotas IPv4 e IPv6 (pesquise "template bgp" aqui: http://bird.network.cz/?get_doc&v= 20 & f = bird-3.html # ss3.1). Dito isso, embora o Calico já ofereça suporte a endereços de pilha dupla no pod, pode haver alterações necessárias para que o roteamento BGP funcione para ambas as famílias.

@leblancd : Então, aqui está o cenário:

1. Digamos que usaremos o controlador de entrada NGINX
2. Estou expondo meus serviços por meio do Ingress.
3. Estou executando meus pods configurados em pilha dupla
4. Estou tentando acessar o serviço remotamente usando registros dns A e AAAA.
   Espero que todos estes
5. Em resumo: desejo me conectar a interfaces de pod usando endereços IPv4 ou IPv6, conforme resolvido por minhas próprias consultas para registros A e / ou AAAA para o nome do serviço de pod.
   Posso me envolver nessa iniciativa de teste, documentação, arquitetura: mas preciso de algumas orientações.
   Como faço para saber sobre o andamento disso, por favor.

@ sb1975 - Boa pergunta. o controlador de entrada NGINX com pilha dupla. Não sou um especialista em controlador de entrada NGINX (talvez alguém mais familiarizado possa falar), mas é assim que eu veria o fluxo de trabalho:

• Quando você tenta acessar os serviços Kube de fora, seu controlador DNS deve resolver o serviço com registros DNS A e AAAA para o controlador de ingresso. Seria escolha do seu cliente / aplicativo usar o registro A vs. AAAA para alcançar o controlador de ingresso. Portanto, o acesso externo ao controlador de ingresso seria de pilha dupla.
• No controlador de entrada NGINX, o NGINX examinaria a URL L7 (independentemente da solicitação estar em um pacote IPv4 ou IPv6) e balancearia a carga para os pontos de extremidade upstream. Se o balanceador de carga do controlador de entrada estiver configurado com ipv6 = on (que é o padrão, consulte https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#configuring-http-load -balancing-using-dns), e os terminais de serviço são de pilha dupla, então a configuração upstream deve ter entradas IPv4 e IPv6 para cada ponto de extremidade de pilha dupla. Conforme projetado, o balanceador de carga NGINX trata a entrada IPv4 e a entrada IPv6 para um ponto de extremidade como servidores separados . (Consulte a linha no documento mencionado anteriormente "Se um nome de domínio resolver para vários endereços IP, os endereços são salvos na configuração upstream e com balanceamento de carga.") Isso pode ser considerado uma boa ou má notícia. A boa notícia é que o balanceamento de carga será feito entre os endpoints IPv4 e IPv6 (dando a você alguma redundância), onde, por exemplo, uma solicitação IPv4 de entrada pode ser mapeada para um endpoint IPv4 ou IPv6. Mas a má notícia em potencial é a granularidade do balanceamento de carga: uma conexão com um endpoint IPv4 e uma conexão com o endpoint IPv6 correspondente serão tratadas (para considerações de balanceamento de carga) como 2 cargas para endpoints separados, em vez de 2 cargas separadas para o mesmo endpoint . Se essa granularidade de balanceamento de carga for uma preocupação, alguém pode desabilitar o balanceamento de carga para IPv6 (ou para IPv4, se houver um botão de configuração para isso?), De modo que o balanceamento de carga seja para endpoints somente IPv4. OU , talvez o balanceador de carga NGINX possa ser modificado para tratar uma conexão com um endereço IPv4 e uma conexão com seu endereço IPv6 correspondente como 2 carregamentos para o mesmo ponto de extremidade.

Quanto a ajudar e se envolver, isso seria muito apreciado! Estamos prestes a começar a trabalhar seriamente no dual-stack (foi um pouco atrasado pelo trabalho de fazer o CI funcionar apenas para IPv6). Espero lançar um esboço para uma especificação (Google Doc ou KEPs WIP doc) em breve e procuraria ajuda na revisão e talvez na redação de algumas seções. DEFINITIVAMENTE, também precisaremos de ajuda com a documentação oficial (além das especificações de design) e com a definição e implementação de testes E2E de pilha dupla. Algumas das áreas nas quais ainda estou um pouco incompleto para o design incluem:

• Como as sondas de saúde / vivacidade / prontidão são afetadas ou tratadas com pilha dupla
• Haverá um impacto nas políticas de rede?
• Preocupações com o balanceador de carga?
• Preocupações com o plugin do provedor de nuvem?
• Preocupações com o ingresso L3 / L4?
  Se você já pensou em algum desses itens, talvez possa ajudar nessas seções?

Também estamos considerando uma abordagem intermediária de "pilha dupla na extremidade" (com IPv6 apenas dentro do cluster), em que o acesso de fora do cluster aos serviços K8s seria de pilha dupla, mas seria mapeado (por exemplo, via NGINX controlador de ingresso) para endpoints somente IPv6 dentro do cluster (ou use NAT46 sem estado). Os pods e serviços no cluster precisariam ser todos IPv6, mas a grande vantagem seria que o acesso externo de pilha dupla estaria disponível muito mais rapidamente do ponto de vista do tempo de chegada ao mercado.

/ marco 1.12

@leblancd / @caseydavenport - Estou observando muita discussão aqui e uma mudança de marco.
Isso deve ser retirado do marco 1.11?

@justaugustus - Sim, deve ser movido para 1.12. Preciso excluir uma linha da planilha de lançamento ou preciso fazer algo para alterar isso?

@leblancd Eu

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

Esse recurso foi removido do marco anterior, portanto, gostaríamos de verificar e ver se há planos para isso no Kubernetes 1.12.

Em caso afirmativo, certifique-se de que este problema está atualizado com TODAS as seguintes informações:

• Descrição do recurso de uma linha (pode ser usada como uma nota de versão):
• Contato principal (cessionário):
• SIGs responsáveis:
• Link de proposta de design (repositório da comunidade):
• Link para e2e e / ou testes de unidade:
• Revisor (es) - (para LGTM) recomendam que mais de 2 revisores (pelo menos um do arquivo OWNERS da área de código) concordem em revisar. Revisores de várias empresas preferidos:
• Aprovador (provavelmente do SIG / área à qual o recurso pertence):
• Meta de recurso (qual meta é igual a qual marco):
  
  
  
  • Alvo de liberação alfa (xy)
  
  
  • Meta de lançamento beta (xy)
  
  
  • Alvo de liberação estável (xy)
  
  

Defina o seguinte:

• Descrição
• Cessionário (s)
• Rótulos:
  
  
  
  • estágio / {alfa, beta, estável}
  
  
  • sig / *
  
  
  • tipo / recurso
  
  

Observe que o congelamento de recursos ocorre em 31 de julho, após o qual qualquer problema de recurso incompleto exigirá que uma solicitação de exceção seja aceita no marco.

Além disso, esteja ciente dos seguintes prazos relevantes:

• Prazo do Docs (abrir espaço reservado para PRs): 21/08
• Congelamento do caso de teste: 28/08

Certifique-se de que todos os PRs para recursos tenham notas de versão relevantes incluídas também.

Frete feliz!

/ cc @justaugustus @ kacole2 @robertsandoval @ rajendar38

@leblancd -
O congelamento de recursos é hoje. Você está planejando mudar para Beta no Kubernetes 1.12?
Em caso afirmativo, você pode ter certeza de que tudo está atualizado, para que eu possa incluí-lo na planilha de rastreamento de recursos 1.12?

Olá, @justaugustus - o status Beta precisará deslizar para o Kubernetes 1.13. Estamos fazendo um progresso (embora lento) no KEP de design (https://github.com/kubernetes/community/pull/2254), e estamos perto de nos envolver novamente com o PR de teste de CI, mas o Kubernetes 1.12 alvo era um pouco otimista demais.

Vou atualizar a descrição / resumo acima com as informações que você solicitou anteriormente. Obrigado pela sua paciência.

/ remove-stage alpha
/ stage beta

Não se preocupe, @leblancd. Obrigado pela atualização!

Olá, @justaugustus @leblancd

Acabei de ler a atualização de que o beta foi movido para 1.13 para pilha dupla. Qual é a data de lançamento prevista para 1,13? Na verdade, estamos procurando suporte para pilha dupla. É uma decisão inútil para o nosso produto mover para contêineres.

@ navjotsingh83 - Não acho que a data de lançamento do Kubernetes 1.13 foi solidificada. Não vejo 1.13 listado na documentação de versões do

@ navjotsingh83 @leblancd 1.13 cronograma de lançamento publicado . É um ciclo de lançamento curto com congelamento de código em 15 de novembro. Você acha que é hora de mudar esse recurso para Beta. Por favor, você pode atualizar este problema com seu nível de confiança, o que está pendente em termos de código, teste e conclusão de documentos?

De acordo com a discussão na reunião da Rede SIG, embora haja um trabalho considerável feito sobre esse recurso em 1.13, não se espera que vá para Beta em 1.13. removendo o marco em conformidade.

/ marco claro

@ kacole2 para remover isto da planilha de melhorias 1.13

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

/ remove-lifecycle stale

@leblancd Olá - sou o líder do aprimoramento para 1.14 e estou verificando este problema para ver que trabalho (se houver) está sendo planejado para o lançamento 1.14. O congelamento de melhorias é 29 de janeiro e quero lembrar que todas as melhorias devem ter um KEP

@leblancd Gostaria de dar seguimento a seu comentário anterior sobre a criação de uma delimitação na extremidade do cluster para IPv4 / IPv6:

“Também estamos considerando uma abordagem intermediária de" pilha dupla na borda "(com IPv6 apenas dentro do cluster), em que o acesso de fora do cluster aos serviços K8s seria de pilha dupla, mas isso seria mapeado (por exemplo, via Controlador de entrada NGINX) para pontos de extremidade somente IPv6 dentro do cluster (ou use NAT46 sem estado). Os pods e serviços no cluster precisariam ser todos IPv6, mas a grande vantagem seria que o acesso externo de pilha dupla estaria disponível muito mais rapidamente do ponto de vista do tempo até o mercado. ”

Esse caso de uso seria bom para um projeto atual, portanto, gostaria de ver seus pensamentos sobre o prazo, ver se há algo que eu mesmo ou alguém em nosso grupo poderia contribuir para ajudar neste tempo mais rápido para o caminho do mercado.

@KevinAtDesignworx Se a curl -v 93.184.216.34 -H "Host: example.com" ), eu realmente acho que é a melhor abordagem. Se sua infraestrutura pode usar ipv6, por que se preocupar em usar ipv4, exceto no limite por razões de compatibilidade. No entanto, se essa abordagem significa que não posso acessar sites legados usando apenas ipv4 de dentro do meu cluster, não tenho mais tanta certeza.

bem, há 464XLAT, então ipv6 apenas dentro do contêiner seria viável.

@KevinAtDesignworx - Se usar um controlador de ingresso funcionasse em seu cenário, é possível configurar um controlador de ingresso NGINX para operação de pilha dupla de fora (proxy para família única dentro do cluster): https://github.com/leblancd/ kube-v6 # installation -a-dual-stack-ingress-controller-on-an-ipv6-only-kubernetes-cluster

Os controladores de ingresso precisariam ser executados na rede do host em cada nó, portanto, os controladores precisariam ser configurados como um daemonset (um controlador de ingresso em cada nó). Isso pressupõe:

• Seus nós são de pilha dupla (ao contrário de pods e serviços de família única)
• Seu / etc / hosts em cada nó tem entradas IPv6 e apenas entradas IPv6 (sem endereços IPv4) para o nome de host desse nó.

Isso seria uma adição a um NAT64 / DNS64 para conexões de clientes V6 dentro do cluster para servidores externos somente IPv4.

O NAT46 sem estado também é uma opção, mas não tentei isso, então não tenho nenhum guia de configuração para isso.

@leblancd algum trabalho planejado aqui para 1.15? Parece que um KEP ainda não foi aceito neste momento. Obrigado!

@leblancd Gostaria de dar seguimento a seu comentário anterior sobre a criação de uma delimitação na extremidade do cluster para IPv4 / IPv6:

“Também estamos considerando uma abordagem intermediária de" pilha dupla na borda "(com IPv6 apenas dentro do cluster), em que o acesso de fora do cluster aos serviços K8s seria de pilha dupla, mas isso seria mapeado (por exemplo, via Controlador de entrada NGINX) para pontos de extremidade somente IPv6 dentro do cluster (ou use NAT46 sem estado). Os pods e serviços no cluster precisariam ser todos IPv6, mas a grande vantagem seria que o acesso externo de pilha dupla estaria disponível muito mais rapidamente do ponto de vista do tempo até o mercado. ”

Esse caso de uso seria bom para um projeto atual, portanto, gostaria de ver seus pensamentos sobre o prazo, ver se há algo que eu mesmo ou alguém em nosso grupo poderia contribuir para ajudar neste tempo mais rápido para o caminho do mercado.

De dentro de um contêiner (que é apenas ipv6) enviando uma solicitação curl (ou seja, curl -v 93.184.216.34 -H "Host: example.com") para o exterior do cluster. Acho que vai dar um erro de destino desconhecido ou destino inacessível, a menos que exista uma rota ipv4 no host onde existe o container.

@ GeorgeGuo2018 se k8s implementasse DNS64 / NAT64, funcionaria. depende muito de quão longe k8s irão em soluções 464xlat / plat e o que precisaria ser tratado em roteadores de ponta, etc ...

na verdade, acho que seria possível usar um DaemonSet / Deployment que usa rede de host e Tayga dentro do namespace do sistema kube para que o DNS64 interno usasse tayga para sair da rede.

Parece uma solução para mim.

Operamos internamente uma rede somente IPv6 e o ​​NAT64 / DNS64 funciona muito bem para nós. Para algumas coisas legadas em que não havia suporte IPv6, acabamos usando o clatd diretamente onde era necessário. (No nosso caso, diretamente em uma VM.)

@ kacole2 - Eu gostaria que isso fosse rastreado por 1.15. Estou trabalhando para obter o seguinte PR mesclado - https://github.com/kubernetes/enhancements/pull/808

Especificamente para 1.15, estaríamos adicionando suporte para o seguinte:

• Modificações de tipo de API
  
  
  
  • Tipos de Kubernetes
  
  
  • Tipos CRI
  
  
• rede de pod de pilha dupla (pod multi-IP)
• suporte multi-família kubenet

cc @caseydavenport para acompanhamento de marcos ^

@ kacole2 o KEP está agora integrado. Avise-me se precisarmos de mais alguma coisa para rastrear em 1.15

Olá @leblancd @ lachie83 Só um lembrete amigável de que estamos procurando um PR contra k / website (branch dev-1.15) para quinta-feira, 30 de maio. Seria ótimo se fosse o início da documentação completa, mas até mesmo um espaço reservado PR é aceitável. Deixe-me saber se você tiver alguma dúvida!

@ kacole2 o KEP está agora integrado. Avise-me se precisarmos de mais alguma coisa para rastrear em 1.15

@ lachie83 Olá, Lachie, você quis dizer que o suporte de pilha dupla IPv4 / IPv6 deste KEP foi concluído?

@ kacole2 o KEP está agora integrado. Avise-me se precisarmos de mais alguma coisa para rastrear em 1.15

Na verdade, eu quero descobrir se o suporte de pilha dupla certamente será adicionado em k8s 1.15.

@leblancd O marcador de posição PR contra k8s.io dev-1.15 vence quinta-feira, 30 de maio.

@leblancd O marcador de posição PR contra k8s.io dev-1.15 vence quinta-feira, 30 de maio.

Posso considerar que o suporte de pilha dupla estará disponível na versão 1.15?

@ GeorgeGuo2018 Ainda está na folha de melhorias para 1.15, mas apenas o lead de melhoria @ kacole2 pode fornecer-lhe melhores detalhes sobre isso.

Olá @ lachie83 @leblancd. Code Freeze é quinta-feira, 30 de maio de 2019 @ EOD PST . Todos os aprimoramentos que vão para o lançamento devem ser de código completo, incluindo testes , e ter documentos PRs abertos.

Liste todos os PRs k / k atuais para que possam ser rastreados durante o congelamento. Se os PRs não forem mesclados por congelamento, esse recurso será suspenso para o ciclo de lançamento 1.15. Somente problemas de bloqueio de liberação e PRs serão permitidos no marco.

Vejo que kubernetes / kubernetes # 62822 na postagem original ainda está aberto. Existem outros PRs que esperamos fundir também?

Se você sabe que isso vai escorregar, responda e nos informe. Obrigado!

@simplytunde - Agradecemos o

@ GeorgeGuo2018 - Este será um KEP multi-lançamento. Planejamos aterrissar a fase 1 em 1.15. Dê uma olhada no plano de implementação no KEP para mais detalhes - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6-dual-stack.md#implementation -plano.

@simplytunde - Eu criei o PR de documentos de espaço reservado inicial aqui com um WIP https://github.com/kubernetes/website/pull/14600. Pretendo concluí-lo e deixá-lo pronto para revisão nos próximos dias.

@ kacole2 Obrigado pelo ping. Atualizei a planilha de aprimoramentos 1.15 com o PR k / k que estamos rastreando (https://github.com/kubernetes/kubernetes/pull/73977) junto com o PR dos documentos preliminares (https://github.com/ kubernetes / website / pull / 14600). No momento, ainda estamos no caminho certo para mesclar esse PR antes do congelamento do código. LMK se estou faltando mais alguma coisa

@ kacole2 após discussão com @claurence e a equipe de lançamento, decidimos remover isso do marco 1.15. Vá em frente, remova-o e atualize a planilha conforme apropriado. Obrigado por toda sua ajuda até agora.

/ marco claro

@simplytunde Eu também comentei sobre o PR da docs. Você pode, por favor, certificar-se de que isso também seja removido do marco 1,15?

Olá @ lachie83 @leblancd , sou a Sombra de Aprimoramento 1.16. Esse recurso graduará os estágios alfa / beta / estável no 1.16? Informe-me para que possa ser adicionado à planilha de rastreamento 1.16 .

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

Obrigada.

https://github.com/kubernetes/dns/issues/315 abrange a adição de IPv6 / AAAA à especificação de descoberta de serviço DNS .

@ lachie83 @leblancd alguma ideia se isso vai se formar no 1.16 para rastreá-lo?

@ evillgenius75 @ kacole2 Isso precisa ser rastreado no 1.16. Este recurso estará em estado alfa. Estaremos implementando a fase 1 e a fase 2 conforme definido no KEP é 1.16

Rastreando KEP

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

PRs k / k mesclados (atualmente no master estará em 1.16)

• [MERGED] Fase 1 - https://github.com/kubernetes/kubernetes/pull/73977
• [MERGED] Testes e2e da ​​Fase 1 - https://github.com/kubernetes/kubernetes/pull/78801
• [MERGED] Fase 1 e2e test cleanup - https://github.com/kubernetes/kubernetes/pull/80001
• Serviços / pontos de extremidade da fase 2 - https://github.com/kubernetes/kubernetes/pull/79386
• Fase 2 kube-proxy - https://github.com/kubernetes/kubernetes/pull/79576

PRs associados

• Suporte para IPv6 https://github.com/kubernetes-incubator/ip-masq-agent/pull/45
• Documentos da fase 1 - serão reabertos assim que finalizarmos os exemplos de ferramentas - https://github.com/kubernetes/website/pull/14600
• [MERGED] limpeza - node dropDisabledFields - https://github.com/kubernetes/kubernetes/pull/79741
• Suporte a vários tamanhos de máscara para cidrs de cluster - https://github.com/kubernetes/kubernetes/pull/79993
• E2e Prow Job para dualstack https://github.com/kubernetes/test-infra/pull/12966

Ei, @leblancd , sou o líder de lançamento de documentos

Este aprimoramento (ou o trabalho planejado para v1.16) requer novos documentos (ou modificações)?

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. Seria ótimo se fosse o início da documentação completa, mas até mesmo um PR de espaço reservado é aceitável. Deixe-me saber se você tiver alguma dúvida!

@simplytunde aqui está a documentação de RP - https://github.com/kubernetes/website/pull/16010

@ lachie83 O congelamento do código de lembrete amigável para 1.16 ocorre na quinta-feira, 29/8. (como se você não soubesse disso). Parece que estes PRs ainda estão pendentes:
Serviços / pontos de extremidade da fase 2 - kubernetes / kubernetes # 79386
Fase 2 kube-proxy - kubernetes / kubernetes # 79576

Associado:
Compatível com vários tamanhos de máscara para cidrs de cluster - kubernetes / kubernetes # 79993
E2e Prow Job para dualstack kubernetes / test-infra # 12966

Olá @ lachie83 @leblancd , parece que https://github.com/kubernetes/kubernetes/pull/79576 e https://github.com/kubernetes/kubernetes/pull/79993 não se fundiram antes do congelamento do código e não é na piscina de fusão da registre uma exceção

@ kacole2 Desculpas pela demora na resposta. O PR principal de rastreamento foi https://github.com/kubernetes/kubernetes/pull/79386. Quanto ao kubernetes / kubernetes # 79576, tomamos a decisão de adiar para 1.17 e, em vez disso, focar em https://github.com/kubernetes/kubernetes/pull/82091 (de acordo com a sig-network), que cumpre os mesmos objetivos da fase 2 que foram dispostos no KEP. O outro PR relacionado foi rastreado neste lançamento foi https://github.com/kubernetes/kubernetes/pull/80485 que também foi mesclado. kubernetes / kubernetes # 79993 também foi adiado para 1.17

Olá @ lachie83 @leblancd - 1.17 As melhorias

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, liste todos os PRs k / k relevantes nesta edição para que possam ser rastreados corretamente. 👍

Obrigado!

/ marco claro

Oi Bob. Agradecemos seu contato. Ainda estou planejando a fase 3 desse aprimoramento, que o completará até a conclusão. Este aprimoramento ainda estará em alfa no final desta versão, mas haverá trabalho relacionado à fase 3 que chegará a k / k como parte do 1.17.

Aqui está uma lista de resultados de alto nível para 1,17 para pilha dupla. Vou atualizar esta lista ao longo do lançamento.

• Proxy de pilha dupla IPtables - https://github.com/kubernetes/kubernetes/pull/79576
• suporte de API descendente para Pod.Status.PodIPs - https://github.com/kubernetes/kubernetes/pull/83123
• e2e testar um plugin CNI
• Alterações no arquivo de host (o endereço IPv6 para o nome do host precisa ser adicionado / etc / hosts) - https://github.com/kubernetes/kubernetes/pull/83123
• Tipo de pilha dupla - https://github.com/kubernetes-sigs/kind/pull/692
• Atualizar o pacote e2e - https://github.com/kubernetes/kubernetes/pull/80725
• Suporte para endpoint slice
• Suporte Dual-Stack para Kubeadm - https://github.com/kubernetes/kubeadm/issues/1612

Muito apreciado, gentilmente obrigado @ lachie83 ❤️ Vou adicionar à folha de acompanhamento.

/ milestone v1.17

@mrbobbytables Eu também adicionei um PR para detalhar o trabalho listado acima como parte da fase 3 do KEP após comunicar o plano via sig-network. O próprio KEP ainda está no estado implementable e essas mudanças estão apenas documentando o trabalho planejado como parte do 1.17 especificamente.

Em algum momento, gostaria de garantir que https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ cobre o DNS IPv6. https://github.com/kubernetes/website/issues/15434 rastreia essa mudança; mencioná-lo aqui para observar uma referência cruzada.

KEP atualizado para adicionar testes e2e de fase 2 - https://github.com/kubernetes/enhancements/pull/1311

Olá @ lachie83 , sou uma das sombras do Docs v1.17.
Este aprimoramento para (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 farei isso)

Em caso afirmativo, apenas um lembrete amigável de que estamos procurando um PR contra k / website (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!

@ lachie83

Já que estamos chegando ao fim do prazo de RP de espaço reservado do Docs em 8 de novembro. Por favor, tente obter um contra o branch k / website dev-1.17.

Olá @ lachie83 , sei que você está mantendo o controle, mas preciso entrar e mencionar isso de qualquer maneira 🙈
O congelamento do código está chegando (14 de novembro). Como estão as coisas? Está tudo em ordem para ser mesclado antes disso?

Obrigado!

Ei @mrbobbytables! Obrigado pelo ping. Estamos rastreando os seguintes PRs para pousar em 1.17. Pode haver um ou dois mais PRs associados a essa mudança que também entram. Essas mudanças precisarão de documentos. Vou levantar um espaço reservado para documentos de relações públicas

• Suporte Dualstack para modo kube-proxy iptables pr / 82462
• Dualstack downward api pr / 82462
• adicionar ipvs metaproxier endpointslice support pr / 84089
• Permitir várias máscaras cidr de nó em kube-controller-manager pr / 79993

@irvifa - Aqui está o espaço reservado para documentos de relações públicas. https://github.com/kubernetes/website/pull/17457

Muito obrigado 🎉 @ lachie83

@ lachie83 amanhã é o congelamento do código para o ciclo de lançamento 1.17. Parece que os PRs k / k ainda não foram mesclados. 😬 Estamos sinalizando isso como Em risco na planilha de rastreamento de aprimoramento 1.17.
Você acha que eles serão mesclados pela EoD do dia 14 (quinta-feira)? Depois desse ponto, apenas problemas de bloqueio de liberação e PRs serão permitidos no marco, com uma exceção.

Obrigado Bob - Discutirei isso com a sig-network hoje e fornecerei uma atualização.

Ei @mrbobbytables. Aqui está uma lista de PRs nos quais estamos trabalhando para serem integrados ao EoD hoje e que foram aprovados pela sig-network.

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

O PR restante provavelmente será punido para 1,18 - https://github.com/kubernetes/kubernetes/pull/82462

@mrbobbytables apenas confirmando que todos os PRs declarados acima foram mesclados e que, de fato, iremos transferir o kubernetes / kubernetes # 82462 para 1.18. Esse aprimoramento ainda pode ser rastreado, pois esses PRs adicionam mudanças de significado ao comportamento de pilha dupla no 1.17. Agora só preciso preparar os documentos de relações públicas! Esperamos lançar o kubernetes / kubernetes # 82462 na versão 1.18 e progredir este trabalho para a versão beta

Ótimo, obrigado @ lachie83!

E é ao vivo! https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement/

Planejamos mover esse aprimoramento para beta no 1.18. Critérios de graduação de aprimoramento e planos de teste podem ser encontrados no KEP junto com este PR - https://github.com/kubernetes/enhancements/pull/1429

/ marco 1.18

@ lachie83 : O marco fornecido não é válido para este repositório. Marcos neste repositório: [ keps-beta , keps-ga , v1.17 , v1.18 , v1.19 , v1.20 , v1.21 ]

Use /milestone clear para limpar o marco.

/ milestone v1.18

Planejamos mover esse aprimoramento para beta no 1.18. Critérios de graduação de aprimoramento e planos de teste podem ser encontrados no KEP junto com este PR - # 1429

Obrigado pela atualização @ lachie83 , marquei isso como rastreado na planilha 1.18!

Acompanhe o seguinte PR como parte do trabalho para pousar em 1.18. https://github.com/kubernetes/kubernetes/pull/82462

Adicionando outros PRs relacionados para rastreamento:
https://github.com/kubernetes/test-infra/pull/15893
https://github.com/kubernetes-sigs/kind/pull/692

Obrigado @ lachie83!

Olá @ lachie83 , você tem algum outro PR que devemos rastrear além dos mencionados acima?

Olá, @ lachie83 @leblancd - sou uma sombra do Docs na equipe de lançamento do 1.18.

Este trabalho de aprimoramento planejado para 1.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)

Se atualizações de documentos forem necessárias, lembre-se de que os PRs de espaço reservado para k / website (branch dev-1.18) são devidos até sexta-feira, 28 de fevereiro.

Deixe-me saber se você tiver alguma dúvida!

Se alguém quiser ajuda para documentar IPV6 ou coisas de pilha dupla para v1.18, me dê um cutucão. Posso ajudar.

Ei @ lachie83 ,

Parece que o kubernetes-sigs / kind # 692 ainda não foi mesclado. Isso é crítico para a sua graduação Beta?

Ei, @jeremyrickard @sethmccombs , vamos ter que puxar isso da graduação para beta com este PR https://github.com/kubernetes/kubernetes/pull/86895. Até que tenhamos uma maneira razoável de avançar, não acho que seja sábio mover isso para a versão beta do 1.18

/ marco claro

@ lachie83 Obrigado pela atualização. Removi esse aprimoramento do marco. Ansioso por isso em 1.19. :)

Gostaria de confirmar que o estado do aprimoramento de pilha dupla permanece em alpha em 1.18. Atualmente, estou trabalhando com a comunidade para avaliar o trabalho planejado para ser concluído em 1.19. É provável que este aprimoramento ainda permaneça no estado alfa em 1.19, no entanto, gostaria de confirmar. Também tomarei medidas para atualizar os documentos para refletir o estado de aprimoramento nos documentos 1.18.

Se houver páginas no site que mostram Kubernetes de pilha dupla como beta, registre-as em k / site como bugs prioritários / importantes em breve.

Olá @ lachie83 - 1.19, líder de melhorias aqui, gostaria de verificar se você acha que esta melhoria seria graduada em 1.19.

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

Se houver páginas no site que mostram Kubernetes de pilha dupla como beta, registre-as em k / site como bugs prioritários / importantes em breve.

@sftim levantei dois PRs para abordar a rotulagem de lançamento em 1.17 e 1.18

@palnabarun Estamos trabalhando para atualizar o dualstack KEP no prazo de lançamento 1.19, entretanto, não achamos que faremos alterações no código no lançamento 1.19. Temos um problema de bloqueio com o trabalho que já foi feito (graças a ele estar no estado alpha ). O problema de bloqueio é https://github.com/kubernetes/kubernetes/pull/86895. Planejamos resolver isso por meio da atualização do KEP a seguir https://github.com/kubernetes/enhancements/pull/1679, mas levará algum tempo para chegar a um consenso sobre a mudança proposta. Neste estágio, o aprimoramento de pilha dupla permanecerá no estado alpha até que resolvamos esse problema de bloqueio com a implementação atual. Vou fornecer atualizações à medida que as coisas progridem.

Obrigado, Lachie pelas atualizações. Agradeço todos os esforços! : ligeiramente_smiling_face:

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

/ remove-lifecycle stale

Gostaríamos que esse aprimoramento fosse rastreado em 1.20. Ele será reimplementado em estado alfa de acordo com o kep atualizado - https://github.com/kubernetes/enhancements/pull/1679. Acompanhe o seguinte PR para a implementação - https://github.com/kubernetes/kubernetes/pull/91824. Estamos planejando concluir a revisão e mesclar o PR no início do ciclo de lançamento 1.20.

A última graduação dual-stack para o status Beta, conforme discutido na reunião da Rede SIG de 17 de setembro, para aqueles que jogam juntos em casa:

• Deve resolver a ambiguidade da verificação de integridade de pilha dupla do kubelet; via https://github.com/kubernetes/enhancements/pull/1975
• Deve terminar e mesclar o PR de serviços dual-stack existente (sob revisão ativa); via https://github.com/kubernetes/kubernetes/pull/91824
• Deve finalizar o comportamento de IPs de nó de pilha dupla; via https://github.com/kubernetes/enhancements/pull/1665
• Deve determinar quais alterações (se houver) são necessárias para o campo Spec.LoadBalancerIPs do serviço

Todos esses itens estão sendo ativamente trabalhados, e 1.20 ainda é o alvo para a graduação da API Beta de pilha dupla. No entanto, apesar de nossos melhores esforços, sempre há uma chance de que algo não seja resolvido a tempo e, se for o caso, a Rede SIG decidirá se continuará a graduação para Beta ou não em nossas reuniões públicas. Todos são bem-vindos.

@dcbw muito obrigado pela atualização (desculpe, não pude fazer a ligação). Faz sentido levar isso para beta em 1.20 ou simplesmente permanecer em alfa? Se quisermos ir para a versão beta, os critérios de graduação no KEP ainda fazem sentido, visto que se trata de uma reimplementação https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md # graduation -criteria

@dcbw muito obrigado pela atualização (desculpe, não pude fazer a ligação). Faz sentido levar isso para beta em 1.20 ou simplesmente permanecer em alfa? Se quisermos ir para a versão beta, os critérios de graduação no KEP ainda fazem sentido, visto que se trata de uma reimplementação https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md # graduation -criteria

Não é realmente uma reimplementação, no entanto. Todo o trabalho anterior ainda é válido e o trabalho em 1.20 é construído em cima dele para finalizar as últimas mudanças necessárias que foram identificadas. Minha interpretação da discussão da sig-network é que a lista @dcbw postada é o conjunto de problemas conhecidos restantes que precisam ser resolvidos para a graduação.

Olá a todos,

1.20 Líder de melhorias aqui, vou definir isso como rastreado, atualize-me se houver alguma alteração :)

Como um lembrete, o Congelamento de Aprimoramentos ocorre em 6 de outubro.

Observe que o KEP está usando um formato antigo que atualizamos para: https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

Melhor,
Kirsten

/ milestone v1.20

Olá, @russellb -

Não é realmente uma reimplementação, no entanto. Todo o trabalho anterior ainda é válido e o trabalho em 1.20 é construído em cima dele para finalizar as últimas mudanças necessárias que foram identificadas.

Dadas as mudanças da API em https://github.com/kubernetes/kubernetes/pull/91824, é bastante diferente que marcar pilha dupla como alfa para 1.20 permitirá espaço para qualquer reimplementação adicional que se mostre necessária. Eu sei que estamos todos ansiosos pelo beta, mas primeiro vamos conseguir o PR com +9,319 −3,261 e deixar a poeira baixar. :)

Dadas as mudanças da API em kubernetes / kubernetes # 91824 , é bastante diferente que marcar pilha dupla como alfa para 1.20 permitirá espaço para qualquer +9,319 −3,261 e deixar a poeira baixar. :)

@bridgetkromhout sim, precisamos pousar https://github.com/kubernetes/kubernetes/pull/91824 antes de tomarmos qualquer decisão sobre a prontidão da API. Eu realmente espero que possamos fazer isso o mais rápido possível.

Olá a todos,

1.20 Sombra de aprimoramento aqui 👋

Como este aprimoramento está programado para o dia 1.20, lembre-se das próximas datas importantes:
Sexta-feira, 6 de novembro: Semana 8 - Prazo de PR do Docs Placeholder
Quinta-feira, 12 de novembro: Semana 9 - Código Congelado

Como um lembrete, vincule todos os seus PR k / k, bem como documentos PR, a este problema para que possamos rastreá-los.

Obrigado!

Olá, @kinarashah @kikisdeliveryservice - Confirmei na chamada sig-network que precisamos reclassificar para alfa para 1.20. É uma reimplementação completa que precisa de tempo para ser absorvida e testada no estágio alfa.

Olá @ lachie83 , 1.20 Docs shadow aqui.

Este trabalho de aprimoramento planejado para 1.20 requer novos documentos ou modificações nos documentos existentes?

Se assim for, por favor segue os passos aqui para abrir um PR contra o dev-1.20 filial no k/website repo. Este PR pode ser apenas um espaço reservado no momento e deve ser criado antes de 6 de novembro .

Além disso, dê uma olhada em Documentando para um lançamento para se familiarizar com os requisitos de documentos para o lançamento.

Obrigado!

Obrigado @ reylejano-rxm - abrimos o kubernetes / site # 24725

Olá @ lachie83

Obrigado por criar o PR do docs!

Lembre-se das próximas datas importantes:

• Sexta-feira, 6 de novembro: Semana 8 - Prazo de PR do Docs Placeholder CONCLUÍDO!
• Quinta-feira, 12 de novembro: Semana 9 - Código Congelado
• Segunda-feira, 23 de novembro: Semana 11 - PR do Documentos pronto para revisão

Como um lembrete, vincule todos os seus PR k / k, bem como os documentos de PR, a este problema para que a equipe de lançamento rastreie.

Olá, @kinarashah @kikisdeliveryservice - Confirmei na chamada sig-network que precisamos reclassificar para alfa para 1.20. É uma reimplementação completa que precisa de tempo para ser absorvida e testada no estágio alfa.

Ei @ lachie83

Diante do exposto, presumo que isso ainda se destina ao alfa no estado em que se encontra. Não vejo nenhum PR pendente que precisa ser mesclado / trabalho que já foi mesclado.

_Só um lembrete de que o Code Freeze está chegando em 2 dias na quinta - exceção é necessária._

Obrigado!
Kirsten

Olá, @kikisdeliveryservice - sim, o suporte de pilha dupla IPv4 / IPv6 (reimplementado) será alfa para 1.20.

Aqui está o progresso que temos para este aprimoramento:

1) O código foi mesclado de https://github.com/kubernetes/kubernetes/pull/91824 - será alfa para 1.20
2) As atualizações de documentação que cobrem essa mudança de código estão em https://github.com/kubernetes/website/pull/24725/ - revisadas e mescladas no branch dev-1.20

Há mais alguma coisa necessária para 1.20 que não tenhamos concluído neste aprimoramento?

@bridgetkromhout Obrigado pela atualização clara, você está bem!

Parece que LoadBalancerIP em ServiceSpec ainda não faz parte da implementação de pilha dupla. Existe algum plano para apoiá-lo ou eu o perdi?

Olá @chenwng - As alterações no código do provedor de nuvem para https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md # load -balancer -operation.

Você pode ajudar fornecendo seu caso de uso e mudanças sugeridas para entender e decidir se precisamos fazer alguma modificação no KEP.

@chenwng Há um KEP sendo trabalhado por LoadBalancerIPs em clusters de pilha dupla - https://github.com/kubernetes/enhancements/pull/1992

Obrigado pela informação, @aramase , @ lachie83 .