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

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 ter 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.

SeccompDefault foi promovido para a versão beta no Kubernetes 1.25. Ao definir o sinalizador --seccomp-default quando você configura kubelet, o runtime do contêiner usa o perfil RuntimeDefaultseccomp, em vez do modo ‘’não confinado’’(seccomp disabled). Os perfis padrão fornecem um conjunto robusto de padrões de segurança, preservando a funcionalidade da workload. Embora esse sinalizador esteja disponível, o Amazon EKS não habilita esse sinalizador por padrão, portanto, o comportamento do Amazon EKS permanece efetivamente inalterado. Se quiser, você pode começar a habilitar isso em seus nós. Para obter mais detalhes, consulte o tutorial Restrict a Container's Syscalls with seccomp na documentação do Kubernetes.

A compatibilidade com a Container Runtime Interface (CRI) para Docker (também conhecida como dockershim) foi removida da versão 1.24 e mais recente do Kubernetes. O único runtime de contêineres nas AMIs oficiais do Amazon EKS para clusters 1.24 ou mais recentes do Kubernetes é o containerd. Antes de fazer o upgrade para o Amazon EKS 1.24 ou posterior, remova qualquer referência aos sinalizadores de script de bootstrap que não forem mais compatíveis. Para ter mais informações, consulte Migrar de dockershim para containerd.

O suporte para consultas curinga foi descontinuado no CoreDNS 1.8.7 e removido no CoreDNS 1.9. Isso foi feito como medida de segurança. As consultas curinga não funcionam mais e retornam NXDOMAIN em vez de um endereço IP.

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.25 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.

Você pode usar dicas sensíveis à topologia para indicar sua preferência por manter o tráfego na zona quando os nós de processamento do cluster são implantados em várias zonas de disponibilidade. O roteamento do tráfego dentro de uma zona pode ajudar a reduzir custos e melhorar a performance da rede. Por padrão, as dicas sensíveis à topologia são habilitadas no Amazon EKS1.24. Para obter mais informações, consulte Topology Aware Hints na documentação do Kubernetes.

A PodSecurityPolicy (PSP) está programada para ser removida no Kubernetes 1.25. As PSPs estão sendo substituídas pela Pod Security Admission (PSA). O PSA é um controlador de admissão integrado que usa os controles de segurança descritos nos Pod Security Standards (PSS). Tanto o PSA quanto os PSS são recursos beta e são habilitados no Amazon EKS por padrão. Para resolver a remoção da PSP na versão 1.25, recomendamos que você implemente o PSS no Amazon EKS. Para obter mais informações, consulte Implementing Pod Security Standards in Amazon EKS (Implementando Pod Security Standards no Amazon EKS) no blog da AWS.

A ExecCredential client.authentication.k8s.io/v1alpha1 foi removida no Kubernetes 1.24. A API ExecCredential estava disponível para o público no Kubernetes 1.22. Se você usar um plug-in de credencial client-go que dependa da API v1alpha1, entre em contato com o distribuidor do plug-in para saber como migrar para a API v1.

No Kubernetes 1.24, contribuímos com um recurso para o projeto upstream do Cluster Autoscaler que simplifica a escalabilidade de grupos de nós gerenciados do Amazon EKS de e para zero nó. Anteriormente, para que o Cluster Autoscaler entendesse os recursos, rótulos e taints de um grupo de nós gerenciados que era escalado para zero nós, era necessário marcar o grupo subjacente do Amazon EC2 Auto Scaling com os detalhes dos nós pelos quais ele era responsável. Agora, quando não há nós em execução no grupo de nós gerenciados, o Cluster Autoscaler chama a operação de API DescribeNodegroup do Amazon EKS. Essa operação de API fornece as informações de que o Cluster Autoscaler precisa sobre os recursos, rótulos e taints do grupo de nós gerenciados. Esse recurso requer que você adicione a permissão eks:DescribeNodegroup à política do IAM da conta do serviço Cluster Autoscaler. Quando o valor de uma tag do Cluster Autoscaler no grupo do Auto Scaling que aciona um grupo de nós gerenciados pelo Amazon EKS conflita com o próprio grupo de nós, o Cluster Autoscaler dá preferência ao valor da tag do grupo do Auto Scaling. Isso permite que você substitua os valores conforme necessário. Para obter mais informações, consulte Autoscaler do cluster.

Caso pretenda usar os tipos de instância Inferentia ou Trainium com o Amazon EKS 1.24, você deverá atualizar para a versão 1.9.3.0 ou mais recente do plug-in do dispositivo AWS Neuron. Para obter mais informações, consulte Neuron K8 release [1.9.3.0] na documentação do AWS Neuron.

Por padrão, o Containerd tem o IPv6 habilitado para pods. Ele aplica as configurações do kernel do nó aos namespaces de rede de pods. Por isso, os contêineres em um pod se vinculam aos endereços de loopback IPv4 (127.0.0.1) e IPv6 (::1). O IPv6 é o protocolo padrão para comunicação. Antes de atualizar o cluster para a versão 1.24, recomendamos que você teste os pods de vários contêineres. Modifique os aplicativos para que eles possam se vincular a todos os endereços IP nas interfaces de loopback. A maioria das bibliotecas permite a vinculação do IPv6, que é compatível com o IPv4. Quando não é possível modificar o código da aplicação, você tem duas opções:

Se você precisar bloquear o IPv6 para todos os pods em todos os nós, talvez seja necessário desabilitar o IPv6 nas instâncias.

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.24 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.

O Kubernetes deixou de ser compatível com dockershim na versão dockershim e removeu o 1.20 na versão 1.24. Para obter mais informações, consulte Kubernetes is Moving on From Dockershim: Commitments and Next Steps (O Kubernetes está superando o Dockershim: compromissos e próximas etapas) no blog do Kubernetes. O Amazon EKS deixará de ser compatível com o dockershim a partir do Amazon EKS versão 1.24. A partir do Amazon EKS versão 1.24, as AMIs oficiais do Amazon EKS terão o containerd como o único runtime.

Embora a versão 1.23 do Amazon EKS continue sendo compatível com odockershim, recomendamos que você comece a testar as aplicações agora mesmo para identificar e remover quaisquer dependências do Docker. Dessa forma, você estará preparado para atualizar seu cluster para a versão 1.24. Para obter mais informações sobre a remoção do dockershim, consulte Migrar de dockershim para containerd.

O Kubernetes mudou para disponibilidade geral a rede de pilha dupla IPv4/IPv6 para pods, serviços e nós. Porém, o Amazon EKS e o plug-in CNI da Amazon VPC para Kubernetes atualmente não são compatíveis com a rede de pilha dupla. Os clusters podem atribuir endereços IPv4 ou IPv6 a serviços e pods, mas não podem atribuir os dois tipos de endereço.

O Kubernetes mudou o recurso Pod Security Admission (PSA) para a versão beta. O recurso é habilitado por padrão. Para obter mais informações, consulte Pod Security Admission na documentação do Kubernetes. A PSA substitui o controlador de admissão da Pod Security Policy (PSP). O controlador de admissão PSP não é compatível e sua remoção está agendada para a versão 1.25 do Kubernetes.

O controlador de admissão PSP impõe padrões de segurança de pods em um namespace com base em rótulos específicos do namespace que definem o nível de imposição. Para obter mais informações, consulte Pod Security Standards (PSS) and Pod Security Admission (PSA) (Padrões de segurança de pod [PSS] e admissão de segurança de pod [PSA]) no guia de práticas recomendadas do Amazon EKS.

Agora, a imagem do kube-proxy implantada com clusters é a imagem básica mínima mantida pelo Amazon EKS Distro (EKS-D). A imagem contém pacotes mínimos e não tem shells ou gerenciadores de pacotes.

O Kubernetes mudou contêineres temporários para a versão beta. Contêineres efêmeros são contêineres temporários executados no mesmo namespace de um pod existente. Você pode usá-los para observar o estado de pods e contêineres a fim de solucionar problemas e realizar depuração. Isso é especialmente útil para solucionar problemas interativos quando kubectl exec é insuficiente porque um contêiner travou ou uma imagem de contêiner não inclui utilitários de depuração. As imagens sem distribuição são um exemplo de contêiner que inclui um utilitário de depuração. Para obter mais informações, consulte Debugging with an ephemeral debug container na documentação do Kubernetes.

O Kubernetes mudou a API autoscaling/v2 estável do HorizontalPodAutoscaler para disponibilidade geral. A API HorizontalPodAutoscaler autoscaling/v2beta2 está obsoleta. Ele não está disponível na versão 1.26.

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.23 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.