Revisão das notas de release das versões do Kubernetes com suporte estendido

O campo .status.kubeProxyVersion para objetos de nó agora está obsoleto, e o projeto do Kubernetes está sugerindo remover esse campo em uma versão futura. O campo obsoleto não é preciso e historicamente foi gerenciado por kubelet que, na verdade, não conhece a versão kube-proxy ou mesmo se kube-proxy está em execução. Se você estiver usando este campo no software cliente, pare. As informações não são confiáveis e o campo agora está obsoleto.

No Kubernetes 1.29, para reduzir a potencial superfície de ataque, o recurso LegacyServiceAccountTokenCleanUp rotulará os tokens legados baseados em segredos gerados automaticamente como inválidos se não forem usados por um longo período (um ano, por padrão), e os removerá automaticamente se não houver uma tentativa de uso por um longo período após serem marcados como inválidos (um ano adicional, por padrão). Para identificar esses tokens, você pode executar:

kubectl get cm kube-apiserver-legacy-service-account-token-tracking -n kube-system

O Kubernetes v1.28 expandiu a distorção suportada entre o nó central e os componentes do ambiente de gerenciamento em uma versão secundária, de n-2 para n-3, para que os componentes de nós (kubelet e kube-proxy) da versão secundária compatível mais antiga possam funcionar com os componentes do ambiente de gerenciamento (kube-apiserver, kube-scheduler, kube-controller-manager, cloud-controller-manager) para a versão secundária compatível mais recente.

As métricas force_delete_pods_total e force_delete_pod_errors_total no Pod GC Controller são aprimoradas para considerar a exclusão forçada de todos os pods. Um motivo é adicionado à métrica para indicar se o pod está sendo excluído por força, porque está sendo encerrado, órfão, encerrando com a taint "out-of-service" ou encerrando e não agendado.

O PersistentVolume (PV) controlador foi modificado para atribuir automaticamente um padrão StorageClass a qualquer não vinculado PersistentVolumeClaim com o storageClassName não definido. Além disso, o mecanismo de validação de PersistentVolumeClaim admissão no servidor da API foi ajustado para permitir a alteração de valores de um estado não definido para um nome StorageClass real.

O kubelet no Kubernetes 1.27 aumentou o padrão kubeAPIQPS para 50 e kubeAPIBurst para 100. Esses aprimoramentos permitem kubelet lidar com um volume maior de consultas de API, melhorando os tempos de resposta e o desempenho. Quando as demandas de escalonamento Pods aumentam, devido aos requisitos de escalabilidade, os padrões revisados garantem que eles kubelet possam gerenciar com eficiência o aumento do workload. Como resultado, os Pod lançamentos são mais rápidos e as operações de cluster são mais eficazes.

Você pode usar uma Pod topologia mais refinada para difundir políticas como minDomain. Esse parâmetro permite especificar o número mínimo de domínios pelos quais você Pods deve estar distribuído. nodeAffinityPolicy e nodeTaintPolicy permita um nível extra de granularidade na Pod governança da distribuição. Isso está de acordo com as afinidades dos nós, as manchas e o matchLabelKeys campo topologySpreadConstraints em sua especificação Pod’s. Isso permite a seleção de cálculos Pods para distribuição após uma atualização contínua.

O Kubernetes 1.27 promoveu a versão beta de um novo mecanismo de política para StatefulSets que controla a vida útil de seus PersistentVolumeClaims (PVCs). A nova política PVC de retenção permite especificar se o PVCs gerado a partir do modelo de StatefulSet especificação será automaticamente excluído ou retido quando StatefulSet for excluído ou se as réplicas StatefulSet forem reduzidas.

A opção goaway-chance no servidor de API do Kubernetes ajuda a evitar que as conexões do cliente HTTP/2 fiquem presas em uma única instância do servidor de API, fechando aleatoriamente uma conexão. Quando a conexão for fechada, o cliente tentará se reconectar e provavelmente acessará um servidor de API diferente como resultado do balanceamento de carga. O Amazon EKS versão 1.27 tem a sinalização goaway-chance habilitada. Se sua workload em execução no cluster do Amazon EKS usa um cliente que não é compatível com HTTP GOAWAY, recomendamos atualizar seu cliente para lidar com GOAWAY reconectando-se no encerramento da conexão.

Antes de fazer o upgrade para o Kubernetes 1.26, atualize seu plug-in CNI da Amazon VPC para Kubernetes para a versão 1.12 ou mais recente. Se você não fizer a atualização para a versão 1.12 ou mais recente do plug-in CNI da Amazon VPC para Kubernetes, ele falhará. Para obter mais informações, consulte Atribuir IPs a pods com a CNI da Amazon VPC.

A opção goaway-chance no servidor de API do Kubernetes ajuda a evitar que as conexões do cliente HTTP/2 fiquem presas em uma única instância do servidor de API, fechando aleatoriamente uma conexão. Quando a conexão for fechada, o cliente tentará se reconectar e provavelmente acessará um servidor de API diferente como resultado do balanceamento de carga. O Amazon EKS versão 1.26 tem a sinalização goaway-chance habilitada. Se sua workload em execução no cluster do Amazon EKS usa um cliente que não é compatível com HTTP GOAWAY, recomendamos atualizar seu cliente para lidar com GOAWAY reconectando-se no encerramento da conexão.