Melhores Práticas de Upgrade

Melhores Práticas: Use a versão mais recente do Kubernetes

As novas versões do Kubernetes geralmente incluem muitas atualizações, recursos adicionais e, o mais importante, patches para resolver problemas de segurança em versões anteriores. O Kubernetes Engine fornece suporte para três versões secundárias do Kubernetes, com a versão de patch mais recente para cada uma dessas versões.

Por conseguinte, recomendamos que:

• Os clusters de produção sempre executam a versão estável mais recente do Kubernetes.
• Você especifica a versão secundária mais recente suportada do Kubernetes ao criar clusters usando o Kubernetes Engine.
• Você faz upgrade dos clusters existentes quando a Oracle anuncia o suporte do Kubernetes Engine para uma versão principal, versão secundária ou versão de patch do Kubernetes. O upgrade regular de clusters permite evitar situações em que os clusters estão executando versões mais antigas do Kubernetes que não incluem os recursos e correções mais recentes.

Consulte Versões do Kubernetes e Kubernetes Engine (OKE), Fazendo Upgrade de Clusters para Versões Mais Recentes do Kubernetes.

Melhores Práticas: Configurar ambientes de Teste e Produção

Recomendamos que você use vários ambientes do Kubernetes Engine como parte de um workflow para implantar e liberar aplicativos. O uso de vários ambientes ajuda a minimizar o risco e o tempo de inatividade indesejado, permitindo testar atualizações de software e infraestrutura em um ambiente separado do ambiente de produção. No mínimo, recomendamos que você tenha um ambiente de produção e um ambiente de pré-produção ou teste.

Também recomendamos que antes de fazer upgrade de um cluster para uma nova versão do Kubernetes, você teste todos os aplicativos implantados no cluster para confirmar se os aplicativos são compatíveis com a nova versão do Kubernetes. Depois de fazer upgrade dos nós do plano de controle para uma versão mais recente do Kubernetes, você não poderá fazer o downgrade deles para uma versão anterior do Kubernetes. Daí a importância de testar aplicativos antes de fazer upgrade do cluster para uma nova versão do Kubernetes. Por exemplo, antes de fazer upgrade de um cluster, você pode criar um cluster separado executando a nova versão do Kubernetes e testar aplicativos nesse cluster.

Consulte Upgrade de Clusters para Versões Mais Recentes do Kubernetes.

Melhores Práticas: Use uma estratégia de implantação azul-verde

Recomendamos que você use uma estratégia de implantação azul-verde para reduzir o risco e minimizar o tempo de inatividade ao fazer upgrade de clusters do Kubernetes. As implantações azul-verde usam dois ambientes de produção, conhecidos como "azul" e "verde", para fornecer testes confiáveis, atualizações contínuas sem interrupção e rollbacks instantâneos. O uso de uma estratégia de implantação azul/verde garante que os usuários tenham acesso a um ambiente de produção enquanto o outro ambiente de produção está sendo atualizado.

Melhores Práticas: Programar janelas de manutenção

Recomendamos que você programe atividades de manutenção fora do horário de pico para limitar o impacto nos aplicativos que não lidam normalmente com a interrupção do pod causada por atualizações e manutenção de cluster/nó.

Por exemplo, durante as atualizações, pode haver interrupções temporárias quando as cargas de trabalho são movidas para recriar nós. Para garantir que tais interrupções causem impacto mínimo, sempre que possível:

• programar upgrades para horas fora do pico
• projetar implantações de aplicativos para lidar com interrupções parciais sem problemas

Melhores Práticas: Tratar os nós de trabalho como imutáveis

Recomendamos que você trate os nós de trabalho existentes como entidades imutáveis.

As alterações feitas nas propriedades do nó de trabalho de um pool de nós só se aplicam aos novos nós de trabalho criados posteriormente. Você não pode alterar as propriedades dos nós de trabalho existentes.

Por exemplo, em vez de atualizar a imagem do sistema operacional em execução nos nós de trabalho existentes, considere criar um novo pool de nós com nós de trabalho que tenham a imagem atualizada do sistema operacional. Depois de especificar opções de cordão e drenagem para o pool de nós original para impedir o início de novos pods e excluir os pods existentes, você pode mudar o trabalho do pool de nós original para o novo pool de nós. Em seguida, você pode excluir o pool de nós original.

Consulte Criando Nós de Trabalho com Propriedades Atualizadas.

Melhores Práticas: Cordon e drenar nós de trabalho em preparação para manutenção

Recomendamos que você conecte e drene um nó de trabalho antes da manutenção programada nesse nó.

O cordoning marca um nó de trabalho como não programável e impede que o kube-scheduler coloque novos pods nesse nó. A drenagem remove com segurança pods de um nó de trabalho, o que garante que os contêineres sejam encerrados normalmente e executem qualquer limpeza necessária.

Consulte Cordonando e Drenando Nós Gerenciados Antes de Encerrar ou Encerrar. Consulte também Administração Manual de Nós e Drenar um Nó com Segurança na documentação do Kubernetes.