1.36 informações sobre a versão e ações de atualização

Confira as informações sobre a versão 1.36 do site IBM Cloud® Kubernetes Service. Para obter mais informações sobre a versão do projeto “ Kubernetes ” 1.36, consulte o registro de alterações em Kubernetes.

Este selo indica a certificação da versão Kubernetes 1.36 para IBM Cloud Kubernetes Service
Kubernetes versão 1.36 selo de certificação

IBM Cloud Kubernetes Service é um produto certificado como “ Kubernetes ” para a versão 1.36 no âmbito do programa de certificação de conformidade de software “ Kubernetes ” da CNCF. Kubernetes® é uma marca registrada The Linux Foundation nos Estados Unidos e/ou em outros países, utilizadas de acordo com uma licença obtida junto à The Linux Foundation.

Linha do tempo de liberações

A tabela a seguir apresenta o cronograma previsto para o lançamento da versão 1.36 do site IBM Cloud® Kubernetes Service. Essas informações podem ser usadas para fins de planejamento, bem como para estimar o período geral após o qual a versão talvez deixe de ser suportada.

As datas marcadas com o símbolo (†) são tentativas e estão sujeitas a mudança.

Cronograma de lançamento da versão “ IBM Cloud Kubernetes Service ” 1.36
Versão Suportado? Data de liberação Dados não suportados
1.36 True 26 de junho de 2026 1º de agosto de 2027 †

Preparando-se para a atualização

Para obter uma lista completa das alterações que podem afetar seus aplicativos implantados ao atualizar seu cluster, consulte o registro de alterações da comunidade em Kubernetes e o registro de alterações de versão em IBM para a versão 1.36. Também é possível revisar os avisos úteis do Kubernetes.

Kubernetes Servidor de API e túnel do Konnectivity disponibilizados na porta 443

O servidor da API do Kubernetes e o túnel do Konnectivity agora são acessados pela porta padrão 443 do HTTPS, em vez de uma porta de nó atribuída dinamicamente (por exemplo, uma porta no intervalo 20000–32767 ). O tráfego é direcionado para o serviço de back-end correto por meio do roteamento baseado em nome de host; é por isso que cada função possui um nome de host dedicado, embora todos os serviços compartilhem a porta 443. Essa alteração facilita a conexão com o seu cluster a partir de ambientes de rede restritivos, pois você não precisa mais permitir o tráfego por uma porta não padrão através dos seus firewalls e controles de saída. Seu cluster expõe dois nomes de host criados especificamente para esse fim por meio de seus pontos de extremidade de serviço privados e públicos:

  • <cluster>.api.<region-domain> — o endpoint do servidor da API Kubernetes
  • <cluster>.tunnel.<region-domain> — o ponto final do túnel Konnectivity utilizado para a comunicação entre o plano de controle e o nó de trabalho

Esse recurso está disponível a partir da versão 1.36 do IKS nas seguintes regiões: Montreal (ca-mon), Chennai (in-che) e Mumbai (in-mum). O suporte a outras regiões estará disponível em breve.

Se você atualizou um cluster que utiliza o endpoint de serviço público, um kubeconfig que ainda faz referência ao endpoint de serviço público URL continuará usando a porta antiga, o que faz com que os comandos kubectl falhem devido a tempos limite de conexão. Para evitar isso, baixe um novo arquivo kubeconfig executando o comando ibmcloud ks cluster config ou atualize manualmente a porta no seu arquivo kubeconfig existente para 443.

  • Novos clusters: Não é necessária nenhuma ação. Novos clusters são criados com endpoints na porta 443, e o arquivo kubeconfig que você baixar já utiliza a porta 443.
  • Clusters atualizados que utilizam exclusivamente o endpoint de serviço privado: Não é necessária nenhuma ação imediata. As conexões existentes direcionadas ao endereço NodePort continuam funcionando após a atualização. O novo kubeconfig que você baixou utiliza o endpoint da porta 443.
  • Regras de rede personalizadas: atualize todas as regras de firewall, grupo de segurança ou lista de permissões de saída que façam referência explícita à antiga porta do plano de controle com número alto, para permitir, em vez disso, o tráfego de saída HTTPS na porta 443. Quaisquer regras que tenham fixado a porta com o número mais alto anterior podem ser removidas.
  • Listas de permissão baseadas em IP: Os registros DNS do endpoint de serviço público agora apontam para endereços IP do front-end do Akamai IP Protect (IPP), em vez dos endereços IP do balanceador de carga (NLB) utilizados anteriormente. Se o seu firewall ou as regras de saída permitirem o tráfego para o seu cluster por endereço IP de destino, atualize-os para utilizar os intervalos de IP atuais do Akamai IPP.
O acesso anônimo ao servidor da API do Kubernetes agora está restrito

O acesso anônimo ao servidor da API do Kubernetes agora está restrito aos endpoints de verificação de integridade (/healthz, /readyz, /livez, /livez/ping). Todos os demais endpoints exigem autenticação (por exemplo, /version). Isso reduz a exposição decorrente de configurações incorretas acidentais do RBAC que concedem permissões a system:anonymous ou system:unauthenticated.

Kubernetes O painel está obsoleto

O painel de controle de código aberto “ Kubernetes ” está obsoleto e arquivado. O painel do Kubernetes não é mais instalado em clusters recém-provisionados e é removido dos clusters em versões anteriores quando você atualiza para o 1.36. O complemento Headlamp está disponível como uma substituição para a interface do usuário d Kubernetes.

NVIDIA Os drivers da GPU não são mais instalados automaticamente

A partir da versão Kubernetes 1.36, o IBM Cloud Kubernetes Service não instala mais automaticamente os drivers de GPU NVIDIA nos nós de trabalho com GPU. Você mesmo deve instalar e gerenciar os drivers da GPU para executar cargas de trabalho na GPU. Para obter mais informações, consulte “Migração para drivers de GPU autogerenciados ”.

O autoscaler de cluster ainda não é compatível com a versão 1.36. Não atualize seu cluster para a versão 1.36 se o autoscaler estiver instalado.

Atualização antes do principal

Analise as seguintes alterações que você deve realizar antes de atualizar o master do Kubernetes.

Alterações a serem feitas antes de atualizar o master para Kubernetes 1.36
Tipo Descrição
Removido: Plug-in de volume “ Portworx ” integrado ao sistema O plug-in de volume “ Portworx ”, integrado ao código-fonte, foi removido na versão Kubernetes 1.36, concluindo a migração para o driver CSI Portworx. O gate de recurso “ CSIMigrationPortworx ” (em fase de aprovação e bloqueado desde 1.33 ) e o gate de recurso “alpha InTreePluginPortworxUnregister ” também foram removidos, e todas as operações de volume Portworx na árvore do código-fonte foram redirecionadas para o CSI. Antes de atualizar, certifique-se de que o driver CSI do Portworx esteja instalado e que seus recursos StorageClass, PersistentVolume e PersistentVolumeClaim façam referência ao driver CSI. Os clusters que ainda dependem do plug-in in-tree perdem o acesso aos volumes d Portworx após a atualização.
Alteração: Validação mais rigorosa de IPs e CIDRs O gate de recursos “ StrictIPCIDRValidation ” está habilitado por padrão no servidor da API. Os campos da API que contêm valores de IP ou CIDR não aceitam mais endereços com zeros à esquerda desnecessários (por exemplo, 010.000.000.005 em vez de 10.0.0.5) ou valores CIDR com bits de host ambíguos (por exemplo, 192.168.0.5/24 em vez de 192.168.0.0/24 ou 192.168.0.5/32). Verifique seus manifestos e ferramentas para recursos como Service, NetworkPolicy e EndpointSlice, e corrija quaisquer valores de IP ou CIDR não canônicos antes de atualizar. Após a atualização do mestre, as solicitações que criam ou atualizam objetos com valores inválidos são rejeitadas.
Alterado: Renomeação das métricas do plano de controle A métrica “ volume_operation_total_errors ” (kube-controller-manager) foi renomeada para “ volume_operation_errors_total ”, e a métrica “ etcd_bookmark_counts ” foi renomeada para “ etcd_bookmark_total ”. Se você utiliza painéis de monitoramento personalizados ou regras de alerta que fazem referência aos nomes antigos das métricas, atualize-os com os novos nomes para que o monitoramento continue funcionando após a atualização do plano de controle.
Removido: plugin de volume “ git-repo ” O plug-in de volume “ git-repo ” está desativado por padrão, sem opção para reativá-lo; a configuração “ GitRepoVolumeDriver ” não tem mais efeito algum. Esse tipo de volume não é mais compatível com o IBM Cloud Kubernetes Service desde a versão 1.33. Se alguma carga de trabalho ainda utilizar um volume do tipo gitRepo, migre-a para um volume do tipo emptyDir, preenchido por um contêiner do tipo init que clona o repositório usando git. Para obter mais informações, consulte a seção “Remoção do driver de volume gitRepo integrado ao sistema ”.

Atualização após o principal

Analise as seguintes alterações que você deve realizar após atualizar o master do Kubernetes.

Alterações a serem feitas após a atualização do master para Kubernetes 1.36
Tipo Descrição
Obsoleto: Serviço .spec.externalIPs O campo “ .spec.externalIPs ” nos recursos Service está obsoleto, e o servidor da API agora retorna um aviso de obsolescência quando esse campo é definido. Planeje deixar de usar o externalIPs e, em vez disso, redirecione o tráfego externo por meio de um serviço LoadBalancer ou de um Ingress. Para obter mais informações, consulte “IPs externos ”.
Alterado: Perfil padrão do kubectl debug O perfil padrão do site kubectl debug mudou de legacy para general. Se você tiver scripts ou runbooks que dependam do comportamento do perfil “ legacy ”, passe explicitamente o parâmetro “ --profile=legacy ”. Está prevista a remoção do perfil “ legacy ” na versão Kubernetes 1.39. Para obter mais informações, consulte “Depuração de Pods em execução ”.
Alterado: ordem dos eventos do informador do client-go (AtomicFIFO) O recurso “ AtomicFIFO ” do client-go está habilitado por padrão. Os armazenamentos do Informer agora são totalmente atualizados para uma versão consistente do recurso antes que os manipuladores por item OnAdd, OnUpdate e OnDelete sejam chamados, e o processamento de ressincronização do Informer sofreu pequenas alterações, o que pode resultar em diferenças perceptíveis no tempo de invocação dos manipuladores. Teste controladores e operadores personalizados que incorporam o client-go. Caso observe regressões, você pode definir temporariamente o recurso “ AtomicFIFO ” do client-go como “ false ” no seu próprio binário do controlador enquanto realiza as adaptações.
Alteração: Validação numérica mais rigorosa em CustomResourceDefinition CustomResourceDefinition A validação (CRD) agora aplica rigorosamente os intervalos dos formatos numéricos int32, int64, float e double quando estes são definidos em um esquema. Os objetos existentes que já contêm valores fora do intervalo são preservados por meio do mecanismo de validação progressiva, mas os valores novos ou atualizados devem estar dentro do intervalo. Analise os recursos personalizados que utilizam esses formatos numéricos.
Obsoleto: campo “lista de permissões” do plug-in de credenciais Na lista de permissões do plug-in de credenciais do cliente, o campo “ AllowlistEntry.Name ” foi renomeado para “ AllowlistEntry.Command ”. Se você configurar uma lista de permissões para plug-ins de credenciais (por exemplo, por meio de kuberc), atualize sua configuração para usar o novo nome do campo.
Obsoleto: Acesso direto a metav1.FieldsV1.Raw O acesso direto ao campo Raw do metav1.FieldsV1 está obsoleto. O código que cria ou lê FieldsV1 (por exemplo, controladores ou ferramentas que inspecionam campos gerenciados) deve migrar para os novos métodos de acesso NewFieldsV1(string), GetRawBytes(), GetRawString()`` e SetRawBytes() .
Ação necessária: Agendador personalizado e plug-ins d PreBind A estrutura do agendador agora oferece suporte à execução paralela de plug-ins do tipo “ PreBind ”. Se você mantém plug-ins personalizados para o agendador, atualize-os para que retornem um PreBindPreFlightResult no método PreBindPreFlight ; retornar nil mantém o comportamento sequencial existente, e os plug-ins optam pela execução paralela ao retornar AllowParallel: true``. Essa ação se aplica apenas a clusters que executam plug-ins personalizados do agendador.
Ação necessária: RBAC granular para drivers DRA Quando o recurso “ DRAResourceClaimGranularStatusAuthorization ” está ativado (em versão beta em 1.36 ), os drivers e controladores de Alocação Dinâmica de Recursos (DRA) exigem permissões RBAC granulares para atualizar os status de “ ResourceClaim ”. Os agendadores e controladores precisam de update ou patch em resourceclaims/binding, e os drivers DRA precisam de associated-node:update ou arbitrary-node:update em resourceclaims/driver, sujeitos às restrições de seu resourceNames específico. Se você estiver executando drivers DRA, atualize o RBAC deles. Essa ação se aplica apenas aos clusters que utilizam o DRA.