@erictune fyi

@soltysh Em qual SIG posso discutir esse recurso? Quero ter uma discussão mais longa sobre os recursos de terceiros para esse recurso e por que achamos que ele precisa ser integrado ao núcleo.

Vamos usar SIG-Apps por enquanto. Não tem havido muita discussão sobre controladores lá, que eu tenha visto, mas vamos tentar ver como funciona.

Isso está sendo considerado para exclusão do núcleo? Achei que a proposta já havia sido aceita.

@gtaylor nada foi decidido ainda. Atualmente fará parte do grupo alfa em lote, o que acontecerá quando este migrar para mais estável ainda não se sabe.

Meu entendimento foi que isso foi aceito no núcleo, enquanto o fluxo de trabalho de trabalho foi rejeitado no núcleo. Na verdade, tínhamos planejado originalmente tê-lo no 1.3.

@davidopp meu comentário foi baseado na discussão que tivemos anteriormente com @philips @erictune aqui . Embora, pessoalmente, eu prefira que SJ fique no centro: óculos de sol:

@soltysh eu interpretei o comentário como implicando que ele estaria no núcleo (com base na menção de alfa / beta e a declaração "Se alguém produzisse uma versão de terceiros de Scheduler, bem antes de 1.4, e mostrasse que era comparativamente útil , isso seria um argumento convincente para o último caminho "onde o último caminho era a Terceira Parte).

@davidopp esse comentário foi feito quando pensei que SJ seria Beta em 1.4. Agora vai para o Alpha em 1.4. A filosofia era que podemos cancelar um recurso alfa por qualquer motivo, mas devemos ter uma barreira muito alta para cancelar um recurso beta.

Além disso, a todos os que trabalham no SJ: devemos continuar trabalhando a todo vapor, apesar da conversa acima. Grande parte do trabalho se aplicará de qualquer maneira, e precisamos fornecer algum tipo de recurso aos usuários para que possam dar feedback.

Todo o trabalho do SJ está em alta velocidade, o único problema restante (com sorte) é ter https://github.com/kubernetes/kubernetes/pull/29187 instalado . Espero discutir esse problema com

@soltysh : parece que o # 29187 foi fundido, isso significa que o próximo release 1.4 alpha terá o SJ pronto para jogar?

@eghobo esse é o plano.

Isso precisa de documentos em k8s.io, mas parece que o código está disponível. Incrível!

+100

@soltysh os documentos são considerados concluídos ou você está adicionando mais exemplos / tutoriais? Se os documentos estiverem prontos, podemos marcar a caixa de documentos

@janetkuo Eu costumo marcá-los como concluídos assim que

Como ele foi renomeado para CronJobs, atualizarei o título para refletir essa alteração também.

Isso vai estar em beta para 1.5?

@ConorNevin infelizmente não, veja os requisitos beta na descrição do problema, o que precisamos resolver primeiro para promovê-lo a beta. Desculpe: desapontado: a ajuda para consertar isso é altamente encorajada: smiley:

Ainda existe https://github.com/wercker/cronetes , se alguém precisar de funcionalidade semelhante ao cronjob agora sem a capacidade de executar recursos alfa.

O recurso seria executado no máximo uma vez implementado no CronJobs?
Vejo que não foi incluído no alfa - https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/scheduledjob.md#decision

@vinay-g eventualmente, eu acho que sim, mas não tenho ideia de quando isso acontecerá. Ajuda é sempre bem-vinda :)

Esse recurso ainda está anexado ao marco 1.4, e a planilha do marco 1.6 não menciona nada sobre Cron / ScheduledJobs.

Isso ainda está dentro do cronograma para um lançamento beta 1.6? Como cliente do GKE, eu _adoro_ começar a mover todos os nossos crons fora do cluster para o próprio cluster (sem usar cronetes).

De fato. Esse recurso muito necessário vem arrastando-se da versão 1.3, se não estou enganado. Eu estou na mesma posição - não posso esperar até que apareça para começar a puxar os trabalhos locais para o GKE.

Eu modifiquei o marco para o próximo, ainda há muito trabalho a ser feito pelo CronJobs para estabilizá-los, adoraria empurrá-lo de forma mais agressiva, mas infelizmente a falta de tempo é o principal fator que posso ' t atm.

imagePullSecrets é compatível com o modelo ChronJob?

@soltysh obrigado por atualizar.

imagePullSecrets é compatível com o modelo ChronJob?

@avaranovich deve ser, já que estamos criando um pod a partir do modelo. Se não for, preencha um problema e me marque lá.

Ei @soltysh . Eu adoraria ver neste beta em breve! Quero ajudar, mas não tenho certeza do que é necessário / a próxima etapa aqui. Você pode refinar um pouco a lista de verificação (talvez criar / apontar para questões / documentos relevantes)? 🙂

@ApsOps antes do beta, definitivamente precisamos implementar a remoção do lado do servidor, oferecer suporte ao Google App Engine e ao formato chronos e permitir o uso de fusos horários. Provavelmente seria bom varrer os bugs que estão em mim relacionados ao CronJobs. Duvido que seja viável para 1.6, mas para os próximos lançamentos é viável. Mais importante ainda, marque-me em cada edição / publicação que você criar neste tópico.

@soltysh

Eu acho que algumas pessoas usam CronJobs como estão agora, e eu ouço principalmente "quando será beta", e não tantos problemas com o alfa.

Se acreditarmos que podemos adicionar remoção do lado do servidor, app-engine e cronos, e fusos horários sem quebrar a API atual, então não vejo nenhuma razão para não mover o beta agora e adicionar essas coisas antes do GA.

+1 para CronJobs beta. Assim que eles estiverem beta e a redefinição do cluster não for necessária, seria um recurso mortal para vários de nossos fluxos de trabalho aqui.

Estamos ansiosos para que esse recurso seja beta e não tivemos problemas com o alfa.

Pessoalmente, eu prefiro abordar pelo menos a parte da remoção, pois há alguém que já está trabalhando para adicionar limites configuráveis ​​para quantos trabalhos bem e mal sucedidos foram deixados para trás. E a remoção é um elemento chave, eu acho. Vamos discutir a opção de mover isso para beta para 1.6 ou 1.7 durante a próxima chamada de sig-apps. @michelleN importa em adicionar isso como um tópico?

@NiclasHedam seus problemas foram resolvidos, há questões em aberto que eu não vi, se importaria em abrir / enviar um ping para mim?

Todos eles foram tratados em 1.4.7

Existe algum plano para adicionar suporte GUI a isso? Por exemplo, atualmente posso ver o seguinte:

[obatori<strong i="6">@obatori</strong>:~] >> kubectl get cronjobs
NAME         SCHEDULE      SUSPEND   ACTIVE    LAST-SCHEDULE
cron-hello   */1 * * * *   False     0         Tue, 25 Jul 2017 09:11:00 -0400
hello        0 22 * * *    False     0         <none>

No entanto, na GUI, só consigo ver a execução histórica, não os jobs atuais e a programação associada a eles. Além disso, kubectl get não lista cronjob / cronjobs como tipos de recursos válidos, embora eles realmente funcionem.

Naturalmente, posso estar faltando alguma coisa, mas uma busca exaustiva das várias partes da GUI ainda não me mostrou meus trabalhos!

@oscarbatori Abra um problema no repositório kubernetes / painel e peça esse aprimoramento.

@luxas servirá, obrigado por sua resposta rápida.

@soltysh Você pode adicionar o k8s.io Docs PR para este recurso para versão 1.8 aqui: https://docs.google.com/spreadsheets/d/1AFksRDgAt6BGA3OjRNIiO3IyKmA-GU7CXaxbihy48ns/edit#gid = 0

@soltysh esse recurso está listado na planilha de rastreamento de recursos - https://docs.google.com/spreadsheets/d/1AFksRDgAt6BGA3OjRNIiO3IyKmA-GU7CXaxbihy48ns/edit#gid = 0, mas não tem 1.8 marco atribuído.

Este recurso visa 1.8?

@idvoretskyi parcialmente, a promoção para beta era direcionada para 1.8 e aconteceu nesse período. Não há um marco definido para isso, b / c ainda não há um plano claro para a promoção futura a estável.

@soltysh entendido. Então, vou marcar com 1.8 marco.

Obrigado!

@idvoretskyi, já que há um recurso ( capacidade de iniciar o CronJobs manualmente ) que tentaremos obter a versão 1.9 relacionada ao CronJobs, adicionarei 1.9 milstone aqui, está certo? Não quero criar outro problema apenas para rastrear aquele único item.

Provavelmente tentarei atualizar a descrição inicial para que reflita as alterações introduzidas (também planejadas) para recursos relacionados ao CronJob.

@soltysh algum progresso com a atualização da descrição do recurso? :)

Por favor, use o novo modelo - https://github.com/kubernetes/features/blob/master/ISSUE_TEMPLATE.md

@soltysh : wave: Por favor, indique no quadro de rastreamento de recursos 1.9
se esse recurso precisa de documentação. Em caso afirmativo, abra um PR e adicione um link para a planilha de acompanhamento. Desde já, obrigado!

@idvoretskyi, já que há um recurso ( capacidade de iniciar CronJobs manualmente ) que tentaremos obter a versão 1.9 relacionada ao CronJobs, adicionarei 1.9 milstone aqui

Este recurso específico não estará no 1.9. Devemos mover o marco para 1,10?

Para o marco 1.10, existem 3 tópicos:

1. Suporte TimeZone no CronJob (https://github.com/kubernetes/kubernetes/pull/47266) - @iterion veja este comentário para entender o motivo
2. Instanciação manual do CronJob (https://github.com/kubernetes/kubernetes/pull/53988) - @erhudy
3. (?) Reescrever o controlador para usar informadores compartilhados (https://github.com/kubernetes/kubernetes/issues/17130) - @soltysh

@soltysh e ainda beta, certo?

Requisitos estáveis:

1. Informantes compartilhados no controlador (https://github.com/kubernetes/kubernetes/issues/17130)
2. Suporta diferentes formatos de hora ( ISO 8601 , formato de hora GCE ).

A planilha de rastreamento de recursos a planilha ? Obrigado!

@soltysh docs ping - o prazo para mesclar PRs do docs é sexta-feira, 9 de março. Veja o comentário anterior. Obrigado! / cc @idvoretskyi

@ Bradamant3 desculpe pelo atraso, nenhuma atualização de documento é necessária para este recurso. Eu adicionei um comentário na planilha vinculada.

@soltysh
Algum plano para isso em 1.11?

Em caso afirmativo, certifique-se de que o recurso está atualizado com o apropriado:

• Descrição
• Marco
• Cessionário (s)
• Rótulos:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

Algum plano para isso em 1.11?

O controlador reescreve para satisfazer https://github.com/kubernetes/kubernetes/issues/17130, mas ainda estou lutando com o tempo. Portanto, isso é mais um pensamento positivo do que planos reais: pisca:

OK fixe. Eu vou empurrar o marco nisso.

alguma atualização sobre os planos para tornar isso estável? Estou assumindo, com base na falta de marco, que isso não vai acontecer para 1.12?

alguma atualização sobre os planos para tornar isso estável? Estou assumindo, com base na falta de marco, que isso não vai acontecer para 1.12?

@soltysh ^^

@spiffxp - Falei com @soltysh antes. Nada planejado para 1.12.

Oi
Esse aprimoramento já foi rastreado antes, portanto, gostaríamos de verificar e ver se há algum plano de graduar estágios no Kubernetes 1.13. Esta versão é destinada a ser mais 'estável' e terá um cronograma agressivo. Inclua este aprimoramento apenas se houver um alto nível de confiança de que ele atenderá aos seguintes prazos:

• Google Docs (abrir espaço reservado para PRs): 11/8
• Código Slush: 11/9
• Início do congelamento de código: 15/11
• Documentos completos e revisados: 27/11

Por favor, reserve um momento para atualizar os marcos em sua postagem original para rastreamento futuro e ping @ kacole2 se precisar ser incluído na Folha de rastreamento de melhorias 1.13

Obrigado!

@ kacole2 isso não

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

Problemas obsoletos apodrecem após 30 dias de inatividade.
Marque o problema como novo com /remove-lifecycle rotten .
Problemas podres são encerrados após 30 dias adicionais de inatividade.

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

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

Que tal um prefixo para empregos como 20190212T2157Z

/ remove-lifecycle podre

/ ciclo de vida congelado

Os problemas de aprimoramento abertos em kubernetes/enhancements nunca devem ser marcados como congelados.
Os proprietários de aprimoramentos podem garantir que os aprimoramentos permaneçam atualizados, atualizando consistentemente seus estados ao longo dos ciclos de lançamento.

/ remove-ciclo de vida congelado

Olá @soltysh , sou o líder de aprimoramento do 1.15. Este recurso estará graduando os estágios alfa / beta / estável no 1.15? Informe-me para que possa ser rastreado corretamente e adicionado à planilha. Como de costume, um KEP precisará ser mesclado antes que isso possa progredir.

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

Como usuário, uso esse tipo de recurso com sucesso há muito tempo. Não vi nenhum grande problema com a API. É hora de enviá-lo como GA?

Estamos trabalhando em um KEP para a formatura

OK. Obrigado pela atualização.

Olá, @ kow3ns @soltysh , sou o líder de aprimoramento do 1.16. Este recurso estará graduando os 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.

Como um lembrete, todo aprimoramento requer um KEP em um estado implementável com Critérios de Graduação explicando os requisitos de cada estágio alfa / beta / estável.

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

Obrigada.

Olá @soltysh @ kow3ns , 1.17 Melhorias sombra aqui. Gostaria de verificar e ver se você acha que este aprimoramento será alterado para alfa / beta / estável no 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

Se você fizer isso, vou adicioná-lo à planilha de rastreamento 1.17 (https://bit.ly/k8s117-enhancement-tracking). Assim que a codificação começar, liste todos os PRs k / k relevantes nesta edição para que possam ser rastreados corretamente. 👍

Obrigado!

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

Olá @soltysh @ kow3ns ,

1.18 Membro da equipe de melhorias aqui. Gostaria de verificar se você acha que este aprimoramento será alterado para alfa / beta / estável no 1.18. As melhorias serão congeladas em 28 de janeiro.

Se você fizer isso, vou adicioná-lo à planilha de rastreamento 1.18 (https://bit.ly/k8s-1-18-enhancements). Assim que a codificação começar, liste todos os PRs k / k relevantes nesta edição para que possam ser rastreados corretamente. : +1:

Obrigado!

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

• Segunda-feira, 6 de janeiro - Começa o ciclo de lançamento
• Terça-feira, 28 de janeiro EOD PST - Congelamento de melhorias
• Quinta-feira, 5 de março, EOD PST - Código Congelado
• Segunda-feira, 16 de março - os documentos devem ser preenchidos e revisados
• Terça-feira, 24 de março - Kubernetes 1.18.0 lançado

Ei @palnabarun @ barney-s está trabalhando para fechar o KEP a tempo, a implementação irá prosseguir.

Obrigado, @soltysh pelas atualizações. Estou supondo que o aprimoramento deve ser estável para o lançamento. Estou atualizando o mesmo na folha de acompanhamento. Por favor, deixe-me saber se for o contrário.

/ estágio estável

/ milestone v1.18

@barney-s Apenas um lembrete amigável, estamos a apenas 7 dias do Congelamento de Aprimoramento (terça-feira, 28 de janeiro).

Você tem atualizações sobre o KEP?

Por @mattfarina no Slack, isso não se tornará estável no 1.18. Vou removê-lo do marco 1.18 e retirá-lo da folha de controle de lançamento.

KEP PR: https://github.com/kubernetes/enhancements/pull/978

/ marco claro

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

Olá @soltysh @ kow3ns , 1.19 Melhorias sombra aqui. Gostaria de verificar e ver se você acha que este aprimoramento será concluído 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

Se você fizer isso, vou adicioná-lo à planilha de rastreamento 1.19 (http://bit.ly/k8s-1-19-enhancements). Assim que a codificação começar, liste todos os PRs k / k relevantes nesta edição para que possam ser rastreados corretamente. 👍

Obrigado!

Ei @soltysh / @ kow3ns , estou acompanhando minha atualização anterior sobre este aprimoramento que faz parte do lançamento de v1.19 .

Por acaso você tem alguma atualização sobre a possibilidade de isso ser incluído no lançamento v1.19 ?

Obrigado novamente por seu tempo e contribuições. 🖖

Ei @soltysh / @ kow3ns , estou acompanhando minha atualização anterior sobre este aprimoramento que faz parte do lançamento de v1.19 .

Por acaso você tem alguma atualização sobre a possibilidade de isso ser incluído no lançamento v1.19 ?

Obrigado novamente por seu tempo e contribuições. 🖖

Ei @soltysh / @ kow3ns , algum plano para os aprimoramentos serem incluídos em v1.19 ? Informe-me para que eu possa atualizar a planilha de rastreamento para mostrar o estado de inclusão.

_ O congelamento de melhorias ocorre em 19 de maio _

Observe que recentemente o formato KEP mudou. Além disso, o # 1620 foi fundido recentemente, adicionando perguntas de revisão de prontidão de produção ao modelo KEP.
Aproveite esta oportunidade para reformatar seu KEP e também responder às perguntas adicionadas ao modelo nesse PR.

Obrigado,
🖖

Olá @soltysh / @ kow3ns , Infelizmente o prazo para o congelamento do Enhancement 1.19 já passou e o KEP # 978 ainda está em vôo. Por enquanto, isso está sendo removido do marco e da planilha de rastreamento 1.19 . Se houver necessidade de fazer isso, registre uma exceção de aprimoramento .

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

/ ciclo de vida congelado

Os problemas de aprimoramento abertos em kubernetes/enhancements nunca devem ser marcados como congelados.
Os proprietários de aprimoramentos podem garantir que os aprimoramentos permaneçam atualizados, atualizando consistentemente seus estados ao longo dos ciclos de lançamento.

/ remove-ciclo de vida congelado

/ ciclo de vida congelado

Oi @soltysh

Melhorias liderar aqui. Algum plano para isso em 1.20?

Obrigado,
Kirsten

@kikisdeliveryservice sim, estamos planejando mover isso lentamente, consulte https://github.com/kubernetes/enhancements/pull/1996 para obter a proposta, então 1.20 é quando apresentaremos o novo controlador como alfa. Acabei de atualizar a descrição inicial com todos os links adequados e para corresponder ao modelo atual.

/ milestone v1.20

@kikisdeliveryservice sim, estamos planejando mover isso lentamente, consulte # 1996 para a proposta, então 1.20 é quando apresentaremos o novo controlador como alfa. Acabei de atualizar a descrição inicial com todos os links adequados e para corresponder ao modelo atual.

OK, eu li muito isso e estou um pouco confuso 😄
O KEP está em beta. Vai ficar em beta ?? até 1.21 GA?

# The target maturity stage in the current dev cycle for this KEP.
stage: beta

# The most recent milestone for which work toward delivery of this KEP has been
# done. This can be the current (upcoming) milestone, if it is being actively
# worked on.
latest-milestone: "v1.20"

# The milestone at which this feature was, or is targeted to be, at each stage.
milestone:
  alpha: "v1.4"
  beta: "v1.9"
  stable: "v1.21"

Parece que o trabalho será feito durante 1.20 (novo controlador, etc ...) para passar para o GA, mas esse trabalho pode levar um lançamento ou 2 para terminar antes do GA? Eu entendi certo? Então isso não precisaria ser rastreado para o lançamento 1.20?

(Por favor me corrija se eu estiver errado!!)

Parece que o trabalho será feito durante 1.20 (novo controlador, etc ...) para passar para o GA, mas esse trabalho pode levar um lançamento ou 2 para terminar antes do GA? Eu entendi certo? Então isso não precisaria ser rastreado para o lançamento 1.20?

Está correto. Não estamos almejando 1,20 por si só, mas uma parte importante do trabalho (o novo controlador) chegará em 1,20. É por isso que acho que deve ser rastreado por 1.20, não?

/ stage beta

@soltysh Faz sentido, vamos

Para meu registro, estamos apenas esperando que o PR (que atende aos critérios) https://github.com/kubernetes/enhancements/pull/1996 seja mesclado até 6 de outubro

KEP fundido! : partying_face:

Ei @soltysh !

Como seu aprimoramento está programado para 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 os documentos de PR a este problema, para que possamos rastreá-los.

Obrigado!
Kirsten

Olá @soltysh , 1.20 Docs shadow aqui.
Este trabalho de aprimoramento planejado para 1.20 requer novos documentos ou modificações nos documentos existentes?

Em caso afirmativo, siga as etapas aqui para abrir um PR contra dev-1.20 branch 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!

Entendido: +1:

Oi @soltysh
O prazo final do marcador de posição de documentos está quase aqui. Certifique-se de criar um PR de espaço reservado para o ramo dev-1.20 em k/website antes do prazo

Além disso, tenha em mente as 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
• 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.

• Implementação do controlador - https://github.com/kubernetes/kubernetes/pull/93370
• Documentação - https://github.com/kubernetes/website/pull/24885

Olá @soltysh !

Parece que o kubernetes / kubernetes # 93370 ainda está aberto, mas está sendo revisado ativamente. Apenas um lembrete de que o Code Freeze está chegando em 2 dias na quinta - exceção é necessária.

Melhor,
Kirsten

Sim, estou nisso, se não conseguirmos fundir o PR nas próximas horas, preencheremos a exceção.

Ele se fundiu! Incrível!!