Container Service for Kubernetes:Notas de versão do ACK para Kubernetes 1.30

A versão 1.30.7-aliyun.1 corrige a vulnerabilidade CVE-2024-10220.

No Kubernetes 1.29

• O hook PreStop agora inclui uma ação de suspensão, permitindo que o contêiner pause por um período especificado antes do encerramento. Isso concede tempo para concluir processamentos em andamento ou requisições de rede. Para mais informações, consulte KEP-3960: Introdução da ação de suspensão para hook PreStop.

• O recurso SidecarContainers está em Beta e ativado por padrão. Ele permite definir o restartPolicy de um contêiner init como Always. Isso transforma o contêiner init em um contêiner sidecar, que pode ser iniciado, parado ou reiniciado independentemente, sem afetar o contêiner principal da aplicação ou outros contêineres Init. Para mais informações, consulte Contêineres Sidecar.

  Ao usar este recurso, certifique-se de que a versão do kubelet nos nós corresponda à versão do plano de controle.

• O novo tipo de recurso ServiceCIDR permite configurar dinamicamente o intervalo de endereços IP do cluster para Services. Esse recurso está em Alpha e desativado por padrão. Para mais detalhes sobre a expansão dinâmica do número de endereços IP disponíveis para Services, consulte KEP-1880: Múltiplos CIDRs de Service.

• PVCs (Persistent Volume Claims) e contêineres utilizavam a mesma struct ResourceRequirements para definir requests e limits de recursos. Consequentemente, a API de PVC também era alterada quando a struct resources dos contêineres mudava, como na adição do campo claims. Agora, os PVCs usam uma struct VolumeResourceRequirements separada, contendo apenas requests e limits, sem incluir claims. Para mais informações, consulte Requisitos de recursos de volume.

• O recurso PodReadyToStartContainers agora está em Beta e ativado por padrão. Ele indica que o ambiente sandbox de um Pod foi criado com sucesso (o ambiente de execução do contêiner está pronto) e a configuração de rede foi concluída, auxiliando o kubelet a compreender o status do Pod. Para mais informações, consulte Condições do Pod.

• PodAffinity e PodAntiAffinity agora suportam matchLabelKeys e mismatchLabelKeys. Esse recurso resolve um problema em que o agendador não distinguia Pods novos de antigos durante uma atualização contínua (rolling update) de Deployment, resultando em agendamentos fora das expectativas de afinidade e anti-afinidade. Ao configurar matchLabelKeys para PodAffinity, o Deployment adiciona o rótulo pod-template-hash ao ReplicaSet, atribuindo a cada Pod uma string de hash correspondente. Essa string instrui o agendador a avaliar apenas Pods com o mesmo valor de pod-template-hash, facilitando a distinção de Pods atualizados no mesmo lote. Para mais informações, consulte KEP-3633.

• Além dos recursos principais da API do Kubernetes, a verificação de tipos do ValidatingAdmissionPolicy agora suporta CRDs e tipos de Extensão de API, garantindo maior confiabilidade das políticas e configuração correta do cluster. Para mais informações, consulte verificação de tipos.

• O novo feature gate UserNamespacesPodSecurityStandards integra namespaces de usuário aos Padrões de Segurança de Pod. Quando ativado, permite executar contêineres com um usuário não root ou uma identidade específica no contexto de segurança do pod. Esse feature gate está em Alpha, definido como false por padrão, e pode permanecer assim no futuro. Para mais informações, consulte KEP-127: Atualizar PSS com base em feature gate.

• Para objetos de nó, introduziu-se o feature gate DisableNodeKubeProxyVersion. Ele descontinua o campo status.nodeInfo.kubeProxyVersion, impedindo a definição do campo kubeProxyVersion para nós no Kubernetes. Como o kubelet nem sempre identifica com precisão a versão do kube-proxy, esse campo pode ser impreciso. O feature gate está na fase Alpha e desativado (false) por padrão.

• O feature gate JobBackoffLimitPerIndex foi promovido para Beta e definido como true por padrão. Ele permite especificar o número máximo de tentativas para cada índice em um job indexado. Para mais informações sobre jobs indexados, consulte Usar um job indexado para processamento paralelo com atribuição estática de trabalho.

No Kubernetes 1.30

• O feature gate ImageMaximumGCAge permite que o kubelet configure a idade máxima de uma imagem não utilizada antes da coleta de lixo. Se a imagem permanecer sem uso após atingir essa idade, o mecanismo de coleta de lixo poderá removê-la. O valor padrão é "0s", indicando ausência de limite de tempo. Introduzido como Alpha na v1.29, esse feature gate foi promovido para Beta na v1.30.

• O Kubelet adicionou a métrica de monitoramento image_pull_duration_seconds para rastrear a duração do download de imagens. Para mais informações, consulte Lista de métricas alpha do Kubernetes.

• O feature gate LegacyServiceAccountTokenCleanUp foi promovido para GA e está ativado por padrão. Se um Secret gerado automaticamente associado a uma ServiceAccount não for utilizado por um período específico (um ano por padrão) e não estiver montado em nenhum Pod, o kube-controller-manager adiciona o rótulo kubernetes.io/legacy-token-invalid-since ao Secret. O valor desse rótulo é a data atual, marcando o Secret como inválido. Caso o Secret permaneça sem uso por outro período específico (um ano por padrão) após ser marcado como inválido, o kube-controller-manager o limpará automaticamente. Para tornar válido novamente um Secret rotulado como inválido mas não removido automaticamente, remova o rótulo kubernetes.io/legacy-token-invalid-since. Para mais informações, consulte Limpeza automática de tokens legados de ServiceAccount e Limpador de tokens legados de ServiceAccount.

• Na v1.30, se a flag --nodeport-addresses do kube-proxy não estiver definida (padrão), atualizações em um Service NodePort modificarão apenas o IP principal do nó (Primary Node IP), e não todos os IPs do nó. Para mais informações, consulte #122724.

• Para evitar conflitos de configuração e problemas de segurança, não configure a URL do Emissor OIDC com o mesmo valor da URL do Emissor de ServiceAccount do API server. Para mais informações, consulte #123561.

• O feature gate LoadBalancerIPMode adiciona o campo .status.loadBalancer.ingress.ipMode a Services do tipo LoadBalancer para especificar o comportamento de encaminhamento do IP do balanceador de carga. Especifique esse campo somente se o campo .status.loadBalancer.ingress.ip também for especificado. O feature gate LoadBalancerIPMode agora está em Beta. Para mais informações, consulte Especificando IPMode do status do balanceador de carga e Modo de IP do Balanceador de Carga para Services.

• O Horizontal Pod Autoscaler (HPA) baseado em métricas de recursos de contêiner atingiu o estágio Estável na v1.30. Isso permite que o HPA dimensione pods com base no uso de recursos de contêineres individuais, e não apenas no uso geral do pod, sendo útil para configurar limiares de dimensionamento para os contêineres mais críticos. Para mais informações, consulte Métricas de recursos de contêiner.

• O feature gate AdmissionWebhookMatchConditions foi promovido para GA. Ativado por padrão e não desativável, ele permite definir condições de correspondência para webhooks de admissão, oferecendo controle mais granular sobre o acionamento de webhooks. Para mais informações, consulte Controle de Admissão Dinâmico.

• O novo feature gate JobSuccessPolicy, atualmente em Alpha, permite declarar um Job como concluído com base em um conjunto de pods bem-sucedidos. A política de sucesso pode especificar uma quantidade de pods bem-sucedidos ou uma lista de índices específicos (por exemplo, pods com índice x, y e z) para determinar a conclusão do Job. Para mais informações, consulte Política de sucesso/conclusão de Job.

• Adicionou-se o feature gate RelaxedEnvironmentVariableValidation, permitindo o uso da maioria dos caracteres ASCII imprimíveis (intervalo de 32 a 126, exceto =) em variáveis de ambiente. Esse feature gate está na fase Alpha e desativado por padrão. Para mais informações, consulte #123385.

• Adicionou-se o feature gate CustomResourceFieldSelectors, que permite configurar o campo selectableFields para CRDs. Assim, é possível usar Seletores de Campo para filtrar requisições List, Watch e DeleteCollection, facilitando localizar ou gerenciar recursos CRD que atendem a critérios específicos. Esse feature gate está na fase Alpha e desativado por padrão. Para mais informações, consulte Seletores de Campo de Recurso Personalizado.

• O feature gate CRDValidationRatcheting foi atualizado. Ao adicionar uma nova validação a um CRD, o API server deixa de bloquear atualizações em recursos existentes que falhariam na nova validação, desde que as partes inválidas permaneçam inalteradas. Isso facilita implementar novas regras de validação com segurança ao migrar CRDs para esquemas OpenAPI v3, sem impactar recursos existentes. Promovido para Beta, esse feature gate está ativado por padrão. Para mais informações, consulte Retenção de validação de CRD.

• A Downward API suporta pilha dupla (IPv4 e IPv6) por meio do campo status.hostIPs. O primeiro endereço IP na lista status.hostIPs é sempre igual a status.hostIP. Para mais informações, consulte Downward API.

• O feature gate NodeLogQuery permite usar o endpoint /logs para consultar logs de serviços de nó. Promovido para Beta, esse feature gate está desativado por padrão. Para mais informações, consulte Consulta de Log.

No Kubernetes 1.29

• O CronJob não suporta mais CRON_TZ ou TZ no campo .spec.schedule. Use o campo .spec.timeZone, disponível desde a v1.25. Para mais informações, consulte Limitações do CronJob.

• Removeu-se a API ClusterCIDR networking/v1alpha1. Essa API estava em Alpha e era considerada controversa.

No Kubernetes 1.30

• O comando kubectl apply removeu a flag --prune-whitelist. Use --prune-allowlist em seu lugar. Para mais informações, consulte --prune.

• A v1.30 remove o plugin de admissão SecurityContextDeny, descontinuado na v1.27. Recomendamos usar o plugin de admissão PodSecurity, que atingiu o estágio Estável na v1.25 e está ativado por padrão. Para mais informações, consulte PodSecurity.