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

A porta do recurso VolumeAttributesClass beta e o recurso de API estão habilitados na versão 1.31 do Amazon EKS. Esse recurso permite que operadores de cluster modifiquem propriedades mutáveis de volumes persistentes (PVs) gerenciados por drivers da CSI compatíveis, incluindo o driver da CSI do Amazon EBS. Para aproveitar esse recurso, certifique-se de que o driver CSI seja compatível com o recurso VolumeAttributesClass (no caso do driver CSI do Amazon EBS, atualize para a versão 1.35.0 ou posterior para ativar automaticamente o recurso). Você poderá criar objetos VolumeAttributesClass para definir os atributos de volume desejados, como tipo de volume e throughput, e associá-los às suas declarações de volume persistentes (PVCs). Consulte a documentação oficial do Kubernetes e a documentação do driver da CSI para obter mais informações.

O suporte do Kubernetes a AppArmor avançou para estável e agora está disponível para o público em geral. Esse recurso permite que você proteja seus contêineres com o AppArmor definindo o campo appArmorProfile.type no securityContext do contêiner. Antes da versão 1.30 do Kubernetes, o AppArmor era controlado por anotações. Começando na versão 1.30, ele é controlado usando campos. Para aproveitar esse recurso, recomendamos que você se afaste das anotações e use o campo appArmorProfile.type para garantir que suas cargas de trabalho sejam compatíveis.

O recurso de tempo de transição da última fase de PersistentVolume avançou para estável e agora está disponível para uso pelo público em geral na versão 1.31 do Kubernetes. Esse recurso introduz um novo campo, .status.lastTransitionTime, em PersistentVolumeStatus que fornece um registro de data e hora de quando um PersistentVolume avançou pela última vez para uma fase diferente. Esse aprimoramento permite um melhor rastreamento e gerenciamento de PersistentVolumes, especialmente em cenários em que a compreensão do ciclo de vida dos volumes é importante.

A partir da versão 1.30 do Amazon EKS ou em versões mais recentes, qualquer grupo de nós gerenciados recém-criados será automaticamente padronizado para usar o Amazon Linux 2023 (AL2023) como o sistema operacional do nó. Para obter mais informações sobre como especificar o sistema operacional para um grupo de nós gerenciados, consulte Criar um grupo de nós gerenciados para seu cluster.

Com o Amazon EKS 1.30, o rótulo topology.k8s.aws/zone-id é adicionado a nós de processamento. É possível visualizar os IDs de Zonas de disponibilidade (IDs de AZs) para determinar o local de recursos em uma conta em relação aos recursos em outra conta. Para obter mais informações, consulte IDs de zona de disponibilidade para os recursos do AWS no Guia do Usuário do AWS RAM.

A partir da versão 1.30, o Amazon EKS não incluirá mais a anotação default no recurso gp2 StorageClass aplicado a clusters recém-criados. Isso não terá impacto se você estiver referenciando essa classe de armazenamento pelo nome. Você deverá tomar medidas se estiver confiando em ter um StorageClass padrão no cluster. É necessário referenciar StorageClass pelo nome gp2. Como alternativa, você pode implantar a classe de armazenamento padrão recomendada pelo Amazon EBS definindo o parâmetro defaultStorageClass.enabled como verdadeiro ao instalar a versão 1.31.0 ou posterior do aws-ebs-csi-driver add-on.

A política do IAM mínima exigida para o perfil do IAM do cluster do Amazon EKS foi alterada. A ação ec2:DescribeAvailabilityZones é obrigatória. Para obter mais informações, consulte Função do IAM do cluster do Amazon EKS.

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