Container Service for Kubernetes:ACK release notes for Kubernetes 1.33

Versões dos componentes

A tabela a seguir lista as versões dos principais componentes do ACK.

Notas de atualização

Ao atualizar um cluster para a versão 1.33, os pods criados na versão 1.20 ou anterior são reiniciados uma vez caso nunca tenham sido atualizados ou não tenham tido um container reiniciado previamente.

Principais alterações

• A partir da versão 1.33, o ACK utiliza o containerd 2.1 por padrão. Em clusters existentes, o ACK atualiza o runtime de container para o containerd 2.1 durante as atualizações de nó. Para mais informações, consulte Introdução ao containerd 2.1.

• Desde a versão 1.33, novos clusters gerenciados pelo ACK já vêm com o componente ack-ram-authenticator mais recente instalado por padrão. Para mais detalhes, veja [[Anúncio de Produto] ack-ram-authenticator instalado por padrão em clusters gerenciados pelo ACK v1.33 e posteriores](t2938443.xdita#).

Alterações em recursos

• O recurso de redimensionamento de pod in-place foi promovido para Beta e está ativado por padrão. Essa funcionalidade permite alterar dinamicamente a configuração de recursos de CPU e memória de um container sem reiniciar o pod.

• Agora é possível usar a opção --subresources no kubectl para ajustar sub-recursos específicos. Por exemplo, ajuste dinamicamente o tamanho dos recursos de um pod executando kubectl edit pod <pod-name> --subresource resize. Na versão 1.33, os sub-recursos suportados incluem status, scale e resize.

• O recurso TopologyAwareHints para EndpointSlices agora está Generally Available (GA). A anotação beta service.kubernetes.io/topology-mode foi descontinuada. Recomendamos o uso do campo spec.trafficDistribution para definir a política de topologia. Ao definir trafficDistribution como PreferClose, por exemplo, o tráfego é roteado preferencialmente para endpoints na mesma zona do cliente. Para mais informações, consulte Distribuição de tráfego.

• O campo .status.resize para pods foi descontinuado e não pode mais ser definido. Dois novos campos de condição foram adicionados: PodResizeInProgress e PodResizePending.

• O feature gate DisableNodeKubeProxyVersion está ativado por padrão e não pode ser desativado. O kubelet deixou de definir o campo status.kubeProxyVersion nos nós.

• O campo .spec.serviceName para StatefulSets tornou-se opcional, mas sua validação ficou mais rigorosa, exigindo conformidade com o padrão DNS-1123. Caso o .spec.serviceName de um StatefulSet existente falhe na validação, novos pods não poderão ser criados até que o campo seja removido manualmente. Essa atualização transfere a validação de DNS da fase de criação do pod para a fase de configuração do recurso StatefulSet, reduzindo tentativas falhas pelo controlador do StatefulSet.

• O plug-in de volume Git-Repo está desativado por padrão. Para utilizá-lo, ative o feature gate GitRepoVolumeDriver.

• A versão 1.33.3-aliyun.1 corrige as vulnerabilidades CVE-2024-4563.

Recursos

• Os containers sidecar agora são GA e estão ativados por padrão. Um container sidecar é um tipo especial de init container que executa durante todo o ciclo de vida do pod e suporta probes quando você define restartPolicy: Always.

• O recurso OrderedNamespaceDeletion foi promovido para Beta. Ele otimiza o processo de exclusão de recursos de namespace: ao excluir um namespace, os pods de carga de trabalho são removidos primeiro, seguidos por recursos dependentes, como NetworkPolicy e recursos de armazenamento. Isso evita que pods fiquem órfãos após a remoção de recursos críticos de segurança.

• O recurso SupplementalGroupsPolicy foi promovido para Beta e está ativado por padrão. Utilize o campo .spec.securityContext.supplementalGroupsPolicy para configurar um controle refinado de grupos suplementares para um pod, oferecendo maior precisão nas permissões de acesso a volumes. Para mais informações, consulte Configurar controle refinado de SupplementalGroups para um Pod.

• O recurso MultiCIDRServiceAllocator agora é GA e está ativado por padrão. Ele introduz os recursos ServiceCIDR e IPAddress para registrar alocações de ClusterIP para serviços. Use o ServiceCIDR para expandir dinamicamente o intervalo de ClusterIPs alocáveis.

• O recurso JobBackoffLimitPerIndex tornou-se GA, permitindo especificar o número máximo de tentativas de pod para cada índice de um job indexado.

• O recurso JobSuccessPolicy agora é GA. Ele possibilita definir uma política de sucesso personalizada para um Job. Por exemplo, determine se um job foi concluído especificando quais índices devem ter êxito e a quantidade necessária de índices bem-sucedidos. Para mais detalhes, veja SuccessPolicy do Job torna-se GA.

• O recurso ImageVolume foi promovido para Beta e vem desativado por padrão. Ative manualmente os feature gates no API server e no kubelet para permitir que os pods usem uma origem de volume image, que monta uma imagem de container como um volume somente leitura.

• O recurso UserNamespacesSupport foi promovido para Beta e está ativado por padrão, permitindo que os pods usem namespaces de usuário do Linux para maior segurança do container. Esse recurso não afeta os pods existentes. Para usá-lo, especifique manualmente pod.spec.hostUsers. Para mais informações, consulte User Namespaces ativados por padrão.

• O recurso RelaxedDNSSearchValidation foi promovido para Beta e está ativado por padrão. Ele permite caracteres especiais como . e _ no campo .spec.dnsConfig.searches de um pod, proporcionando mais flexibilidade na configuração de DNS.

• O kube-apiserver agora desativa o mecanismo WatchList por padrão, substituindo-o por um mecanismo de codificação em streaming que inclui StreamingCollectionEncodingToJSON e StreamingCollectionEncodingToProtobuf. Essa mudança melhora o desempenho das operações List ao transmitir grandes solicitações de lista de recursos em streaming. Para solicitações List que envolvem muitos recursos, essa alteração pode reduzir significativamente o uso de memória e aumentar a estabilidade do sistema. Para mais informações, consulte Respostas de List em streaming.

  O kube-controller-manager não ativa mais proativamente o recurso WatchListClient.

• O recurso CPUManagerPolicyOptions agora é GA e está ativado por padrão. Ele permite ajustar finamente a política de alocação de recursos do CPU Manager:

  • Quando um pod exige CPUs exclusivas, o sistema impõe o alinhamento SMT para garantir que as CPUs alocadas ocupem exclusivamente núcleos físicos completos. Para mais informações, consulte Extensão do cpu manager para rejeitar cargas de trabalho não alinhadas com SMT.

  • Ao alocar recursos de CPU entre nós NUMA, o sistema garante que os recursos sejam distribuídos uniformemente. Para mais informações, consulte Adicionar opção de política do CPUManager para distribuir CPUs entre nós NUMA em vez de compactá-las.

• O recurso MatchLabelKeysInPodAffinity agora é GA e está ativado por padrão. Ele adiciona os campos matchLabelKeys e mismatchLabelKeys às regras de afinidade de pod, proporcionando um controle mais preciso sobre a colocalização de pods.

• O recurso NodeInclusionPolicyInPodTopologySpread agora é GA e está ativado por padrão. Ele permite usar nodeAffinityPolicy e nodeTaintsPolicy nas restrições de distribuição de topologia de pod para filtrar dinamicamente os nós agendáveis.

  • nodeAffinityPolicy: O padrão é Honor. Apenas os nós que correspondem ao nodeSelector ou à nodeAffinity do pod são considerados no cálculo de distribuição de topologia.

  • nodeTaintsPolicy: O padrão é Ignore. As regras de nodeAffinity e nodeSelector são ignoradas, e todos os nós são considerados no cálculo de distribuição de topologia.

• O recurso HonorPVReclaimPolicy agora é GA e está ativado por padrão. Ele garante que, quando a reclaimPolicy de um PV estiver definida como Delete, o recurso de armazenamento subjacente seja estritamente excluído conforme a política, independentemente da ordem em que o PV ou PVC for excluído. Isso ajuda a evitar vazamentos de recursos de armazenamento.

• O recurso ProcMountType foi promovido para Beta. Use o campo securityContext.procMount do pod para personalizar o tipo de montagem do sistema de arquivos /proc em um container. Isso permite um controle refinado sobre o acesso ao /proc, melhorando a segurança e o isolamento do pod. Esse recurso é útil para executar containers não privilegiados em namespaces de usuário, onde relaxar as restrições do /proc pode melhorar a compatibilidade e a flexibilidade.

• O recurso PodLifecycleSleepActionAllowZero foi promovido para Beta. Ele permite definir o tempo de espera da operação sleep no hook de ciclo de vida preStop como 0.

• Agora é possível usar ResourceQuota para limitar o número de PVCs associados a uma VolumeAttributesClass específica.

• Otimizações de desempenho do agendador:

  • O recurso SchedulerPopFromBackoffQ foi adicionado e está ativado por padrão. Ele otimiza a lógica da fila de agendamento permitindo que os pods sejam retirados diretamente da backoffQ quando a activeQ estiver vazia, o que reduz significativamente a latência de agendamento de pods.

  • O recurso SchedulerAsyncPreemption foi promovido para Beta e está ativado por padrão. Ele permite que o agendador realize agendamento preemptivo de forma assíncrona. Como a preempção pode ser custosa, executá-la assincronicamente reduz a latência de agendamento.

  • O desempenho de agendamento para pods que usam restrições de distribuição de topologia de pod foi otimizado.

APIs descontinuadas

• O Kubernetes 1.33 usa o containerd 2.1 por padrão, que não suporta mais a API CRI v1alpha2. Se suas cargas de trabalho dependem dessa versão da API, migre para a API CRI v1 para garantir a compatibilidade.

• A API Endpoints v1 foi oficialmente descontinuada. Recomendamos o uso da API EndpointSlice em seu lugar. A API EndpointSlice é estável desde o Kubernetes 1.21 e introduz recursos como suporte a rede dual-stack. A API Endpoints v1 não será removida neste momento. Para mais informações, consulte Continuando a transição de Endpoints para EndpointSlices.

• O grupo de API apidiscovery.k8s.io/v2beta1 foi desativado. Os clientes usam essa API para consultar todos os recursos de API registrados em um cluster. Recomendamos migrar para a versão estável v2. Clientes mais antigos podem usar um mecanismo de fallback para utilizar automaticamente a API v1 não agregada para descoberta de serviços, evitando erros imediatos. No entanto, se um cliente não suportar a versão v2, ele precisará fazer várias chamadas de API para recuperar os dados completos e não agregados, o que pode aumentar o número de solicitações e a latência.

Referências

Para acessar o changelog completo do Kubernetes 1.33, consulte CHANGELOG-1.33 e Kubernetes v1.33: Octarine.