Kubernetes: CronJobs deve suportar fusos horários

@iterion Não há rótulos de assinatura neste assunto. Adicione um rótulo de assinatura por:
(1) mencionando um sig: @kubernetes/sig-<team-name>-misc
(2) especificando o rótulo manualmente: /sig <label>

_Observação: o método (1) acionará uma notificação para a equipe. Você pode encontrar a lista de equipes aqui e a lista de marcadores aqui _

/ sig apps

Prefira a segunda opção, pois parece mais natural para mim

@soltysh @ kubernetes / sig-apps-feature-requests

Também gosto do segundo formulário, mas parece que o caminho mais fácil para a implementação seria retirar esse tempo e usá-lo separadamente. Além disso, pode-se argumentar que, como estamos usando o modelo cron "padrão", não devemos mexer com isso.

Parece que isso deve ser simples de implementar:
Atualmente, apenas passamos time.Now () no loop syncOne . O cron lib que o k8s está usando parece funcionar apenas usando horários na zona de seu interesse. Portanto, poderíamos extrair o fuso horário do CronJob e passar esse tempo com fuso horário para a função syncOne.

//init the loc, needs error handling
//perhaps default to local if Timezone was invalid
loc, _ := time.LoadLocation(cronjob.Spec.Timezone)

//set timezone,  
now := time.Now().In(loc)

Além disso, estou feliz em tentar implementar isso.

Não sou a pessoa certa para avaliar seu RP, mas tenho algumas perguntas sobre semântica.

• Qual é a semântica quando nenhum fuso horário é especificado?
• A implementação depende do fuso horário configurado corretamente no host do controlador?
• Quando validamos a legalidade do fuso horário? No momento da criação / atualização do objeto, ou mais tarde?
• O que acontecerá se um nome de fuso horário for válido quando o objeto API foi criado, mas não existir mais no futuro? Isso pode acontecer porque um nome foi removido (talvez uma cidade ou nação deixe de existir) ou porque o pacote tzdata subjacente mudou para uma versão mais antiga.

Se nenhum fuso horário for definido, o padrão será o comportamento atual, que seria usar o fuso horário do host. Eu diria que na maioria dos casos isso seria configurado como UTC, mas um usuário poderia escolher qualquer fuso horário. Como tal, não há maior dependência do fuso horário configurado corretamente no host como resultado deste PR.

Atualmente, apenas resgato e uso o fuso horário do host se o usuário especificou algo inválido. Aqui, estou recorrendo ao método time.LoadLocation (str) de golang . Qualquer string aceita por essa função seria considerada válida. Não estou validando isso no momento de criação / atualização, embora pareça que seria uma coisa muito fácil de fazer.

Quanto à última pergunta, essa é um pouco mais indefinida. Atualmente, e provavelmente no futuro, é mais provável que volte a agendar o trabalho com base no fuso horário padrão. Estou aberto a sugestões sobre como lidar com este caso.

O que acontecerá se um nome de fuso horário for válido quando o objeto API foi criado, mas não existir mais no futuro? Isso pode acontecer porque um nome foi removido (talvez uma cidade ou nação deixe de existir) ou porque o pacote tzdata subjacente mudou para uma versão mais antiga.

Minha sugestão para isso seria reprovar a criação de empregos com um evento apropriado. Mas, francamente, duvido que isso aconteça com frequência. Vou me certificar de que isso seja adicionado em sua implementação @iterion.

e o formato cron não suporta o ano arquivado, como executar um trabalho apenas uma vez em um horário especificado?

: +1:

@iterion Obrigado pelo problema e solicitação de pull. Discutimos isso um pouco na semana passada, tanto em SIG Apps quanto em SIG Architecture. Embora os casos de uso possam ser úteis para fazer sentido, também tivemos que discutir as desvantagens. Por exemplo, cada distribuição compatível do Kubernetes precisaria ter um banco de dados de fuso horário e mantê-lo atualizado. Fusos horários, horário de verão e os detalhes de fazer isso funcionar enquanto os detalhes do mundo real podem mudar e mudam é difícil. Isso seria um trabalho adicional para as mais de 20 distribuições que existem hoje.

Ao mesmo tempo, houve uma mudança no desenvolvimento do Kubernetes. Não tenho certeza de quão amplamente divulgado foi (a comunicação foi outro ponto discutido na Arquitetura SIG). A mudança é um desejo de que o Kubernetes central se concentre na estabilidade e na lentidão. As pessoas agora são incentivadas a inovar e resolver esses tipos de problemas no ecossistema, em vez de no núcleo.

Em vez de colocar isso no Kubernetes, a pergunta é:

1. Desenvolva isso no ecossistema (por exemplo, um controlador) que outros possam usar. Distribua-o, resolva os problemas ali e veja como é a atualização
2. Se a solução for amplamente adotada e puder ser usada por todos (incluindo pequena escala, vários clusters etc.), ela poderá ser considerada para o Kubernetes principal

Se ajudar, este não é o único recurso que está recebendo a mesma direção (mesmo na mesma reunião de Arquitetura SIG). Estou começando a pensar nisso de forma semelhante a algo como wordpress (eu uso wordpress porque é um exemplo muito comum). Há diferença entre ser um plugin ou parte do próprio wordpress. A direção atual é incentivar a inovação em plug-ins, por assim dizer.

Se você construir algo assim, gostaríamos de ter uma demonstração no SIG Apps para mostrá-lo para o pessoal. Também pode ser demonstrado na reunião da comunidade.

Se você tiver dúvidas sobre isso, sinta-se à vontade para entrar em contato comigo.

Tendo em conta o comentário anterior, sinto que podemos encerrar este problema. Sinta-se à vontade para reabrir se não concordar.

FWIW, "como definir o fuso horário" é perguntado por todos os meus usuários que fazem um CronJob (desenvolvedores e administradores).

@iterion O que você acabou fazendo sobre isso? Estamos considerando várias opções para nosso caso de uso, incluindo

• executando a partir de uma bifurcação de kubernetes com sua correção
• Copiar o código do controlador cron em um controlador externo e usar um apiVersion diferente para distinguir os dois.
• Construindo algo específico para nosso projeto em Ruby que espelha a implementação do controlador de cronjob do kube, mas com base em um arquivo de configuração específico do aplicativo, em vez de recursos CronJob.

Se você já tem algo que está funcionando para você que podemos usar como ponto de partida, ou se podemos colaborar em algo que possa servir para encorajar @mattfarina a reverter sua decisão de não permitir a inclusão disso (o que prejudica drasticamente a adoção deste kube recurso), isso seria incrível.

Na verdade, mudei para um novo emprego, então o problema original não existe mais para mim, pessoalmente. Pelo que eu sei, meus ex-colegas estão apenas lidando com a dor que isso resulta.

Dito isso, se eu tivesse tempo para me dedicar a isso, provavelmente escreveria um pequeno controlador que observaria e modificaria os CronJobs conforme necessário. Provavelmente, eu apenas adicionaria uma anotação aos CronJobs com o horário e fuso horário desejados e faria o controlador converter esse agendamento para UTC e modificar os CronJobs. Você poderia simplesmente executar este loop de sincronização em um intervalo para detectar as bordas do problema, ou seja, quando o horário de verão começa ou termina. Dessa forma, o controlador seria apenas um invólucro muito fino em cima da API CronJob já existente.

incentive @mattfarina a reverter sua decisão de não permitir a inclusão deste

Para deixar claro, essa decisão foi tomada coletivamente durante uma das reuniões da sig-architecture. Matt foi apenas a pessoa que expressou essa decisão nesta edição.

O problema de fusos horários com todos os sinos e apitos foi resolvido há muito tempo no mundo Linux. Por que isso é um pré-requisito para uma implantação do Kubernetes?

É difícil discutir sobre a importância dos casos de uso, eu admito. No entanto (e na minha humilde opinião), poder agendar serviços em sincronia com os usuários dos serviços parece importante o suficiente para eu ser elegível para o núcleo do Kubernetes.

Alguém estaria disposto a escrever um operador com um TimezoneAwareCronjobController? A maior parte do código escrito por @iterion provavelmente pode ser reciclado.
Mover o tratamento de TZ para um aplicativo empacotado resolveria o argumento de distribuição que eliminou o suporte cronjob de primeira classe no Kubernetes.

FWIW, https://gopkg.in/robfig/cron.v2 (que o controlador existente usa um subconjunto mais antigo), oferece suporte à passagem em TZ e um conjunto ligeiramente mais rico de definições de tempo.
Temos um controlador interno que cria cron jobs para algumas de nossas cargas de trabalho internas, e é uma solicitação de recurso pendente ser capaz de especificar o fuso horário para eles. Preciso descobrir como atualizar com segurança uma definição de cronjob existente sem pular acidentalmente ou executar novamente os jobs. Neste ponto, parece que pode realmente ser mais fácil roubar o agendamento de tarefas do controlador de saída e criar definições de tarefas diretamente (em vez de cronjobs).

Desde que comecei a usar o K8s, volto a esse problema duas vezes por ano, quando sou forçado a alterar a programação em todos os CronJobs, esperando que finalmente seja reaberto. Se chronos e crontab têm o recurso, como o K8s ainda não oferece suporte a ele?

problema de longo prazo (nota para mim)

Esperançosamente, esse problema será reaberto e é um pouco estranho olhar para o horário UTC todos os dias.

Tenho um cronjob que precisa ser executado no primeiro dia de cada mês no horário local, mas o horário UTC é 16h do último dia do mês passado. Como posso definir o último dia do mês passado? Cronjob não suporta L.

Parece que não existe uma solução alternativa. Veja minhas perguntas aqui e aqui

Para quem ainda está esperando por isso; Eu criei um controlador derivado do controlador de cronjob nativo do Kubernetes e do PR original que foi fechado.

https://github.com/hiddeco/cronjobber

Edit (12/05/2019): graças a @mterron , o Cronjobber agora oferece suporte a um banco de dados de fuso horário independente de host usando um

@hiddeco seria melhor ter um controlador CJ padrão de controle de controlador em vez de modificar um existente? Com a última abordagem, é necessário acompanhar as mudanças reais do controlador CJ, o que pode nem sempre ser viável. Obrigado por seu trabalho.

@andrewsav isso seria preferível, mas não é viável. A única maneira que vejo de 'controlar' o controlador CJ existente é modificando a programação de CronJob para o deslocamento de um fuso horário. Não há como fazer isso para todas as combinações de horários possíveis.

Não espero muitas mudanças no controlador CJ, além disso, não somos obrigados a ficar em sincronia com ele para mantê-lo funcionando, pois é independente (exceto para dependências no cliente e especificações de Job ) .

@hiddeco

Não há como fazer isso para todas as combinações de horários possíveis.

Você pode explicar isso, por favor?

@AndrewSav exemplo simples: 0 0 1 * * rodando em NZDT (UTC + 13) significaria que você precisaria recalculá-lo todo mês porque você precisará rodar no último dia do mês anterior em 11h em UTC.

Se a complexidade de sua programação aumentar, a quantidade de alterações que você precisa fazer para mantê-la sincronizada também aumentará. Além disso, você precisaria alterá-lo sempre que uma área de fuso horário mudasse de DST para ST.

Isso o torna extremamente complexo e abre muito espaço para executá-lo na hora errada ou talvez até pior; de jeito nenhum.

Uma solução é executar um cron a cada hora "possível" dependendo do seu fuso horário e pular se o horário atual não for o esperado. Eu gostaria de poder fazer isso no nível do kubernetes.

Para o horário de verão, isso significa que ele será executado duas vezes por dia em vez de uma e pulará o primeiro ou o segundo, dependendo do horário de verão.

Por exemplo, cada distribuição compatível do Kubernetes precisaria ter um banco de dados de fuso horário e mantê-lo atualizado. Fusos horários, horário de verão e os detalhes de fazer isso funcionar enquanto os detalhes do mundo real podem mudar e mudam é difícil. Isso seria um trabalho adicional para as mais de 20 distribuições que existem hoje.

Os bancos de dados de fuso horário, DSTs, são muito bem mantidos pelas distribuições do sistema operacional, nas quais as distribuições do kubernetes devem contar. A desculpa "é trabalho duro para as distribuições" não é válida pela IMO.

Eu não discutiria se o conceito se chamasse PeriodicJob ou RepeatingJob . Mas, em vez disso, é chamado de CronJob . Está vinculado ao calendário e ao relógio. Não há como negar que a consciência do fuso horário é um requisito crítico para isso.

Outra solução; talvez o problema possa ser resolvido removendo o CronJob completamente do kubernetes. Não que isso fosse ajudar alguém.

Outra solução; talvez o problema possa ser resolvido removendo o CronJob completamente do kubernetes. Não que isso fosse ajudar alguém.

Concordo, se eles não podem implementar uma solução adequada em k8s, eles não deveriam adicionar a solução de forma alguma. Os Cronjob são projetados para trabalhar com fusos horários, e todos os sistemas operacionais atuais lidam com fusos horários de forma transparente com as funções do sistema operacional associadas.

O raciocínio não parece ser coerente, se vamos seguir essa lógica então deve haver uma série de recursos que existem no K8s que não deveriam existir.

Este é realmente um bug. O próprio nome Cronjob é enganoso, pois não segue as especificações do Cron. A maioria dos usuários do kubernetes presumirá que o suporte ao fuso horário já vem pronto para uso. É decepcionante que os desenvolvedores do núcleo tenham optado por não incluir isso. Este problema deve afetar> 90% dos usuários que não operam no horário UTC.

Eu gostaria de revisitar isso. Um problema que estou tendo é que quero que certos trabalhos sejam executados à 1h da manhã do primeiro dia do mês no Japão - certamente um caso de uso razoável / padrão. Dado que o cron está definido em UTC, não há como especificar isso; 0 0 1 * * será executado às 9h, horário do Japão. (Também seria bom adicionar 0 0 L * * para o último dia do mês, que é usado em algumas implementações do cron)

@johnnyshields você provavelmente deve pedir a @soltysh para reabrir.

Embora eu adorasse que isso fosse reconsiderado, acho que as chances são mínimas. A equipe se reuniu, discutiu e decidiu que isso causaria muito trabalho adicional. Isso não mudou desde então, então a decisão provavelmente também não mudou.

Basta dar uma olhada (e contribuir!) Para CronJobber https://github.com/hiddeco/cronjobber. Ele faz o que todos desejam.

Um PR baseado na versão mais recente do controlador CronJob seria ótimo, mas funciona perfeitamente como está.

Embora eu adorasse que isso fosse reconsiderado, acho que as chances são mínimas. A equipe se reuniu, discutiu e decidiu que isso causaria muito trabalho adicional. Isso não mudou desde então, então a decisão provavelmente também não mudou.

Eles devem, então, ser pelo menos consistentes e remover a implementação atual do cronjob porque é muito enganoso (para dizer o mínimo).

O problema com esse

@AndrewSav e é por isso que eu estava pedindo ajuda com isso. Eu fiz tudo que posso. Não tenho certeza se há algum risco de segurança com isso, o Kubernetes muda o tempo todo, mas isso não significa que a mudança seja significativa em um sentido de segurança.

Dito isso, um rebase seria legal, fique à vontade para contribuir e ajudar com isso.

@mterron você é o autor desse, não é? Portanto, visto que mesmo você não consegue encontrar tempo para fazer isso, é improvável que as pessoas contribuam para algo que não está mais ativo. Seria extremamente bom, porém, eu concordo. Quando esse projeto foi lançado pela primeira vez, considerei brevemente se eu apostaria nele e o colocaria em meus clusters, e então pensei que as chances de ele ser mantido não eram grandes. Agora, um ano depois, vejo que não estava errado. Agradeço o seu trabalho, mas receio que na forma atual não seja sustentável.

Se ele decolar e alguém continuar a reformulá-lo e mantê-lo consistentemente, isso seria maravilhoso.

Não, eu não sou o autor. Sou apenas um usuário que contribui para os projetos que utilizo quando posso.
Eu entendo de onde você vem, mas acho que suas expectativas são um pouco altas em relação a algo que as pessoas fazem em seu tempo livre para o benefício da comunidade.

@mterron Acho que estou no nível das minhas expectativas. Na verdade, eles estão baixos. Essa é a principal razão pela qual me abstive de usar o trabalho vinculado em minhas clustres.

@AndrewSav você deve fazer uma diferença entre cronjobber e o controlador cronjob upstream. Da última vez que fiz (1,17) não houve diferença. O controlador de cronjob upstream é efetivamente não mantido por sua definição.

O controlador upstream também possui características de desempenho horríveis, que obviamente o cronjobber herda.

@benlangfeld

você deve fazer uma comparação entre o cronjobber e o controlador upstream do cronjob

Não é tanto sobre mim, é sobre ser sustentável para uso geral. É pouco razoável solicitar a cada usuário potencial para fazer uma comparação. Mesmo que seja um fato que não houve mudanças, que gostaria de examinar mais adiante.

O controlador de cronjob upstream é efetivamente não mantido por sua definição.

Esta não é uma interpretação justa do que eu disse.

Sobre diffs: o que você difere com o quê? Existem mais de 50 arquivos nesse repo, e nem todos os nomes correspondem aos das origens do kubernetes. Você pode explicar como podemos nos convencer de que não houve mudanças? De preferência um pouco mais detalhado do que no comentário anterior, pois não é óbvio. Em particular, quais arquivos em quais branches / commits em cada lado você comparou e não detectou mudanças?

Dada a intensa participação neste problema, acho que é justo solicitar uma reavaliação de um recurso principal do Kubernetes.

Acho a seguinte afirmação importante: “Se a solução for amplamente adotada e puder ser usada por todos (incluindo pequena escala, vários clusters, etc.), então ela poderia ser considerada para o Kubernetes principal”. Parece haver soluções, talvez ainda não totalmente prontas. Portanto, uma declaração da equipe principal de que o caso de uso é reconhecido como elegível para o núcleo K8s seria um grande sinal para os desenvolvedores dessas soluções prepará-las para uma solicitação pull.

@AndrewSav como autor do 'fork', tenho que discordar respeitosamente com qualquer coisa que você declarou até agora, e como mantenedor de vários projetos de OSS, estou surpreso com sua atitude.

Primeiro, o cronjobber foi simplesmente derivado do controlador Kubernetes CronJob porque era a correção mais direta, exigindo o mínimo de tempo para uma solução madura (e comprovada). Dadas as razões declaradas abaixo, eu não esperava que o upstream mudasse muito (nem mudou).

Em segundo lugar, gerar o trabalho X no momento Y enquanto leva em conta o fuso horário Z não é ciência de foguetes, a especificação para o conceito de tempo não mudou em anos, e não deveria não requer qualquer manutenção além de garantir que ainda possa gerar jobs nativos do Kubernetes no momento certo (e os bancos de dados de fuso horário estão atualizados, para os quais há um auxiliar disponível graças a @mterron).

Contanto que ele seja capaz de gerar esses jobs, o que é perfeitamente capaz da última vez que verifiquei, meu tempo será melhor gasto em outro lugar. Se isso não atender aos seus padrões, sugiro contratar alguém para escrever e manter uma solução semelhante para você.

@hiddeco

Eu tenho que discordar respeitosamente com qualquer coisa que você declarou até agora

Nada? Essa é uma declaração forte.

Pelas razões indicadas abaixo, eu não esperava que o upstream mudasse muito (nem mudou)

Pode não mudar _muito_, mas também não permanecerá estático. A equipe do kubernetes afirmou que deseja uma solução "amplamente adotada" antes que "possa ser considerada para o Kubernetes principal". Na minha experiência, soluções que não estão sendo mantidas ativamente (sem mudanças por quase um ano) raramente são "amplamente adotadas". Além disso, ninguém demonstrou até agora que o controlador Kubernetes CronJob e suas dependências não mudaram em nada. Eu, pessoalmente, não consigo descobrir uma boa maneira de comparar todos os arquivos que foram afetados e todas as dependências subjacentes.

Em segundo lugar, gerar o job X no tempo Y e, ao mesmo tempo, levar em consideração o fuso horário Z não é uma ciência espacial, a especificação para o tempo do conceito não mudou em anos e não deve exigir nenhuma manutenção, a não ser garantir que ainda possa gerar jobs nativos do Kubernetes em a hora certa (e os bancos de dados de fuso horário estão atualizados, para o qual existe um ajudante disponível graças a @mterron).

Isso soa excessivamente otimista para mim. Raramente se trata de mudanças nas "especificações". São pequenas coisas que te matam. Bugs são encontrados constantemente, mesmo em projetos "maduros e comprovados" e são corrigidos. Gerar um trabalho pode não ser uma ciência de foguetes, mas descobrir como as mudanças relacionadas na base de código do kubernetes afetam suas mudanças pode ser complicado rapidamente. Por exemplo, durante o ano passado, esforços foram feitos para mover a API do cliente (kubectl) para a preparação. Isso afeta o cron jobber? Eu não sei. A versão da biblioteca cron usada foi atualizada no upstream. Isso afeta o cron jobber? De novo, não sei.

Contanto que ele seja capaz de gerar esses jobs, o que é perfeitamente capaz da última vez que verifiquei, meu tempo será melhor gasto em outro lugar.

E tudo bem. Você já fez mais do que precisava. Você fundiu o PR e publicou seu trabalho para qualquer pessoa usar. Obrigada.

Se isso não atender aos seus padrões, sugiro contratar alguém para escrever e manter uma solução semelhante para você.

Novamente, isso não é sobre mim, como expliquei em um comentário acima. É ser útil para uma classe mais ampla de pessoas. Parece que estou me repetindo agora. Será que tudo a dizer sobre o assunto já foi dito? O que você acha?

Isso soa excessivamente otimista para mim. Raramente se trata de mudanças nas "especificações". São pequenas coisas que te matam. Bugs são encontrados constantemente, mesmo em projetos "maduros e comprovados" e são corrigidos. Gerar um trabalho pode não ser uma ciência de foguetes, mas descobrir como as mudanças relacionadas na base de código do kubernetes afetam suas mudanças pode ser complicado rapidamente. Por exemplo, durante o ano passado, esforços foram feitos para mover a API do cliente (kubectl) para a preparação. Isso afeta o cron jobber? Eu não sei. A versão da biblioteca cron usada foi atualizada no upstream. Isso afeta o cron jobber? De novo, não sei.

Honestamente, isso vem a mim como o que sobre isso resulta em obstrucionismo. Essa lógica pode ser usada para argumentar contra qualquer coisa, então não tenho ideia do que você está tentando alcançar aqui. Não há nada realmente tão complexo em executar cronjobs que reconhecem o fuso horário. Qualquer sistema * nix mainstream (que é onde o k8 é executado) teve suporte de fuso horário sólido por décadas (porque surpresa, os sistemas * nix têm funcionado predominantemente em ambientes de servidor que tem um conjunto semelhante de preocupações por mais de 40 anos).

Novamente, isso não é sobre mim, como expliquei em um comentário acima. É ser útil para uma classe mais ampla de pessoas. Parece que estou me repetindo agora. Será que tudo a dizer sobre o assunto já foi dito? O que você acha?

E como foi declarado ad-nauseam, a implementação atual é quase inútil porque ignora completamente o fuso horário, onde a implementação que está ciente do fuso horário é muito mais útil para um conjunto mais amplo de pessoas, qual é o seu ponto aqui?

Essa lógica pode ser usada para argumentar contra qualquer coisa

Eu não acho que pode. Você está convidado a demonstrá-lo, se quiser, mas por favor, atenha-se ao que foi dito, não ao que poderia estar implícito.

portanto, não tenho ideia do que você está tentando alcançar aqui.

Ah, só estou respondendo o comentário do hiddeco direcionado a mim, você encontra acima.

E como foi afirmado ad-nauseam, a implementação atual é quase inútil porque ignora completamente o fuso horário, já que a implementação que reconhece o fuso horário é muito mais útil para um conjunto mais amplo de pessoas

Se reformularmos isso, para dizer que você e eu temos uma preferência de que o cronjob do kubernetes é compatível com fusos horários, isso seria correto. Acho "closs to inutil" um pouco forte, mas concordo plenamente que uma implementação com suporte para fuso horário seria muito mais útil.

qual é o seu ponto aqui?

A questão é que não há evidências de que o "fork" que estamos discutindo é "amplamente adotado" e, portanto, é improvável que a equipe do kubernetes o aceite, o que é uma pena, porque é isso que eu adoraria veja incorporado ao kubernetes.

Bugs são encontrados constantemente, mesmo em projetos "maduros e comprovados" e são corrigidos.

Primeiro, palavras "maduras" e "comprovadas pelo tempo" não têm lugar em uma frase sobre kubernetes ou seu ecossistema.

Em segundo lugar, desde quando os bugs são um problema no kubernetes? @ fejta-bot irá apenas "consertá-los" (fechá-los) automaticamente. Não há necessidade de pensar em bugs. Tudo está bem.

Eu me pergunto quando / se algum mantenedor se importará / comentará?

Acho que isso deve ser documentado em https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron -job-limitações

Concordo que "cronjobs" na Kubernetes deve ter o apoio de fuso horário porque aglomerados Kubernetes rodar em Linux que fornece isso. Estamos rejeitando essa ideia porque alguma parte tem planos de executar o Kubernetes (ou variante) no Windows em um futuro distante? Razão muito fraca para rejeitar este problema, se for o caso. Podemos pelo menos adicionar a tag "triagem / não resolvido" para distinguir isso dos problemas que foram resolvidos?

Se a decisão for que os k8s principais não devem se estender a essa funcionalidade, concordo com o comentário acima de que o suporte ao cronjob deve ser removido para que as pessoas sejam encorajadas a adotar uma solução de ecossistema conforme desejarem. Isso realmente se destaca como algo no K8s principal que não é explícito sobre o resultado pretendido e que confunde as pessoas.

Como o Go 1.15 agora tem um pacote time/tzdata em sua biblioteca principal, possivelmente ...?

Como devo provisionar em excesso meu cluster das 7 da manhã às 7 da noite?
Onde meus usuários estão, há horário de verão e horário de inverno.
Portanto, não posso confiar nisso de forma alguma.

NÃO gerenciar o fuso horário com cronjobs foi uma decisão muito estranha que você tomou.

Encontramos uma boa solução alternativa para esse problema: pare de usar K8s CronJobs e use o Apache Airflow.

A vida ficou muito melhor desde então. Junte-se a nós!

Esse problema é resolvido externamente lá: https://github.com/hiddeco/cronjobber

@mattfarina

1. Se a solução for amplamente adotada e puder ser usada por todos (incluindo pequena escala, vários clusters etc.), ela poderá ser considerada para o Kubernetes principal

Como e quando a adoção da solução da comunidade é medida?

https://github.com/kubernetes/enhancements/pull/1996

@mattfarina @soltysh agora com KEP-19: Graduate CronJob to stable , que menciona o fuso horário como uma das melhorias para consideração, foi aprovado e mesclado e o trabalho no controlador de cronjob v2 está em andamento. Este problema pode ser reaberto e reconsiderado?

Ele menciona isso como uma consideração / possível melhoria. Não garante se nem quando isso será abordado. Posso dizer com 100% de garantia que não vai acontecer antes do CronJob GA, que vai levar esse e mais 2 lançamentos.

@soltysh Ainda pode ser discutido apropriadamente. Já foi amplamente demonstrado que esse é um recurso necessário. A insistência em chutar a bola na estrada mostra uma enorme desconexão entre os mantenedores e os usuários.

@benlangfeld Estou muito aberto a isso, mas o tempo é o principal fator limitante aqui: decepcionado:

@benlangfeld Estou muito aberto a isso, mas o tempo é o principal fator limitante aqui 😞

Já existe uma correção proposta. De que informações você precisa para que isso seja aceito?

O controlador está sendo reescrito, esse é o foco principal agora. A mudança só será possível com o novo controlador. É inútil mudar o antigo que deve ser substituído.