Nesta página, explicamos como as descontinuações de recursos e APIs causadas pelo Kubernetes e outras dependências funcionam com o Google Kubernetes Engine (GKE). Nesta página, você também encontra tabelas com informações sobre suspensões de uso específicas do Kubernetes. Para saber como conferir sua exposição às próximas descontinuações, consulte Como consultar insights e recomendações de descontinuação.
O que são as suspensões de uso do Kubernetes?
Os clusters do GKE são fornecidos pelo sistema de gerenciamento de clusters de código aberto Kubernetes. O conjunto de recursos do Kubernetes evolui com o tempo e, assim como novos recursos são lançados, às vezes um recurso pode precisar ser removido. Ou um recurso pode ser graduado da fase Beta para a fase do GA. A política de suspensão de uso do Kubernetes garante que os usuários tenham um processo previsível para que possam migrar de um recurso ou API obsoleto antes de ser removido.
Após o período de suspensão de uso, quando um recurso ou API for removido, não será mais possível usá-lo a partir da versão secundária do GKE correspondente. Se um cluster depende de um recurso ou API que teve o uso suspenso, a funcionalidade pode ser comprometida.
Descontinuações causadas por outras dependências upstream
Além dos recursos e APIs do Kubernetes, o GKE também oferece recursos com suporte de outros provedores, como imagens de nós do Windows com suporte da Microsoft e imagens de nó do Ubuntu com suporte da Canonical. Quando esses provedores upstream estiverem descontinuados ou encerrarem o suporte a um recurso, o GKE talvez precise remover o recurso correspondente. As tabelas nesta página também fornecem informações sobre descontinuações e remoções futuras causadas por dependências upstream no Kubernetes.
Como as suspensões de uso do Kubernetes funcionam com o GKE
Executar aplicativos no GKE envolve a responsabilidade compartilhada entre você e o GKE.
Como usuário, é preciso avaliar e mitigar qualquer exposição a recursos e APIs obsoletos que serão removidos nas próximas versões secundárias do Kubernetes. Nas próximas seções, saiba mais sobre como o GKE facilita esse processo detectando o uso de APIs e recursos obsoletos do Kubernetes, compartilhando insights sobre esse uso e fornecendo recomendações sobre como migrar para recursos e as APIs compatíveis com as próximas versões secundárias
Se o GKE detectar que um cluster está usando um recurso removido em uma versão secundária futura do Kubernetes, os upgrades automáticos de cluster para a próxima versão secundária serão pausados, e o GKE compartilhará uma recomendação e um insight de suspensão de uso.
O que acontece quando o GKE pausa os upgrades automáticos?
Se o GKE detectar o uso de um recurso ou API descontinuados, ele pausará os upgrades automáticos para evitar que o cluster seja atualizado para um estado corrompido. Os upgrades para a próxima versão secundária do Kubernetes estão pausados, mas o GKE continua a fornecer upgrades de patch para o cluster na versão secundária atual. Por exemplo, se um cluster estiver na versão 1.21.11-gke.1100 e tem chamadas para APIs descontinuadas removidas da versão 1.22, o GKE pausará o upgrade automático para a versão 1.22. No entanto, o GKE não pausa o upgrade automático para uma nova versão de patch, 1.21.11-gke.1900.
Como o GKE não pode garantir que todo o uso seja detectado, ele não garante que os upgrades sejam sempre pausados quando uma API ou um recurso descontinuado for usado. Para garantir que não seja feito o upgrade de um cluster, use as exclusões de manutenção.
Quando o GKE retoma os upgrades automáticos?
Quando o GKE não detectar o uso do recurso descontinuado ou das chamadas para APIs descontinuadas por 30 dias, o cluster será atualizado automaticamente se a próxima versão secundária for a versão padrão no canal de lançamento do cluster. Para saber quando a versão secundária se torna padrão no canal de lançamento do cluster, consulte a Programação de lançamento.
Se o GKE continuar detectando o uso do recurso obsoleto no cluster, ele vai manter o cluster na versão secundária atual até o fim da vida útil da versão. Quando essa data, disponível na programação de lançamentos, for atingida, o cluster será atualizado automaticamente para a próxima versão secundária, e o ambiente do cluster poderá ser afetado à medida que o recurso removido ainda estiver em uso. Para saber mais, leia as Perguntas frequentes sobre compatibilidade de versões.
O que são insights e recomendações de descontinuação?
Se o GKE detectar que um cluster está usando um recurso removido em uma versão secundária futura do Kubernetes, ele compartilhará um insight e uma recomendação de suspensão de uso, notificando o uso de um recurso obsoleto no cluster; Esse insight fornece informações sobre o último uso detectado e mais detalhes, dependendo do tipo de descontinuação. Para saber mais sobre como visualizar essas informações, consulte Como visualizar insights e recomendações de descontinuação.
Avaliar e mitigar a exposição a futuras suspensões de uso do Kubernetes
O GKE fornece guias de migração que orientam você na migração de recursos e APIs obsoletos para aqueles compatíveis com a próxima versão secundária. Para ver uma lista de suspensões de uso futuras e guias de migração, consulte Informações sobre as suspensões de uso do Kubernetes.
Embora o GKE compartilhe insights sobre os clusters detectados que estão expostos a uma descontinuação, a detecção de todas as exposições a futuras suspensões de uso não é garantida. Por exemplo, se um recurso descontinuado não tiver sido usado nos últimos 30 dias, o GKE não detectará nenhum uso, e um insight e uma recomendação não serão gerados.
Avalie a exposição do ambiente do cluster de maneira independente para quaisquer suspensões de uso futuras antes de fazer upgrade dele para a próxima versão secundária. Para controlar o processo de upgrade, escolha um canal de lançamento, use janelas e exclusões de manutenção ou faça upgrade manual dos seus clusters se você determinou que eles não serão expostos a suspensões de uso na próxima versão secundária.
Como resolver a exposição a suspensões de uso do Kubernetes
Para fazer isso, consulte as próximas suspensões de uso. Confira recomendações e insights sobre suspensão de uso, para avaliar se o cluster foi exposto, e use guias de migração para reduzir a exposição antes que a última versão secundária disponível que oferece suporte ao recurso chegue ao fim da vida útil.
Depois que você faz alterações para interromper o uso de APIs ou recursos descontinuados no cluster, o GKE aguarda até que ele não observe mais o uso de APIs ou recursos descontinuados por 30 dias e, em seguida, desbloqueia upgrades automáticos. Os upgrades automáticos prosseguem de acordo com a programação de lançamentos.
Também é possível fazer upgrade do cluster manualmente se você confirmar que o upgrade não causa interrupção no ambiente do cluster. Para isso, primeiro crie um cluster de teste e verifique se o upgrade causa alguma interrupção. Se isso não acontecer, será possível fazer upgrade do cluster manualmente.
Ao dispensar uma recomendação, ela só será ocultada para todos os usuários. Os upgrades automáticos permanecem pausados até que você migre para fora dos recursos descontinuados e o GKE não detecte o uso dos recursos descontinuados por 30 dias consecutivos.
Informações de descontinuação do Kubernetes
As seções a seguir fornecem informações sobre descontinuações em andamento, incluindo guias que explicam como migrar para recursos ou APIs compatíveis com versões secundárias disponíveis do Kubernetes. Verifique essas tabelas para ver se o GKE detecta e informa o uso com insights e recomendações.
Essas tabelas fornecem apenas informações sobre descontinuações em andamento e omitem as informações incluídas anteriormente para recursos ou APIs que foram descontinuados com versões muito após a data de fim da vida útil.
Descontinuações de recursos do Kubernetes
Veja na tabela a seguir as suspensões de uso de recursos atuais do GKE, bem como a versão em que esses recursos não são mais compatíveis:
| Nome | Suspenso | Removida | Mais informações | O GKE detecta e informa o uso? |
|---|---|---|---|---|
| Certificados TLS assinados com o algoritmo SHA-1 | Versão 1.24 do GKE | Versão GKE 1.29 | Certificados TLS SHA-1 são compatíveis com a remoção | Sim |
| Plug-in de autenticação integrado para clientes do Kubernetes | GKE versão 1.22 | Versão 1.25 do GKE | Plug-in de autenticação descontinuado para clientes do Kubernetes | No |
| PodSecurityPolicy | Versão 1.21 do GKE | Versão 1.25 do GKE | Suspensão de uso da PodSecurityPolicy | Sim |
| Imagens de nó com base no Docker | Versão 1.20 do GKE | Versão 1.24 do GKE | Descontinuação da imagem do nó do Docker | Sim |
| Campo "Nome comum" X.509 em certificados do webhook | Versão 1.19 do GKE | Versão 1.23 do GKE | Suspensão de uso do campo "CN" dos certificados do webhook | Sim |
Suspensões da API Kubernetes
A tabela a seguir fornece uma visão geral das APIs do Kubernetes que foram suspensas e não são mais exibidas, classificadas por versão do Kubernetes:
| Versão do Kubernetes | Mais informações | O GKE detecta e informa o uso? |
|---|---|---|
| 1,29 | APIs descontinuadas do Kubernetes 1.29 | Sim |
| 1,27 | APIs descontinuadas do Kubernetes 1.27 | Sim |
| 1.26 | APIs obsoletas do Kubernetes 1.26 | Sim |
| 1,25 | APIs descontinuadas do Kubernetes 1.25 | Sim |
| 1.22 | APIs obsoletas do Kubernetes 1.22 e APIs Beta do Ingress do Kubernetes removidas do GKE 1.23 |
Sim |
Outras descontinuações de recursos
A tabela a seguir fornece informações sobre descontinuações e remoções causadas por outros provedores de upstream que não fazem parte do projeto de código aberto do Kubernetes.
| Nome | Suspenso | Removida | Mais informações | O GKE detecta e informa o uso? |
|---|---|---|---|---|
| Imagens de nó do Canal Semestral do Windows Server (SAC) | N/A | 9 de agosto de 2022 | Fim do serviço SAC do Windows Server | No |