Melhores Práticas de Gerenciamento de Cluster

Saiba mais sobre as melhores práticas para gerenciar clusters que você criou pelo Kubernetes Engine (OKE).

Esta seção contém as melhores práticas para gerenciamento de cluster e o Kubernetes Engine.

Melhores Práticas: Usar labels do Kubernetes

Recomendamos que você use labels do Kubernetes para organizar os muitos recursos do Kubernetes (como serviços, pods, contêineres, redes) que compõem um cluster.

Os labels do Kubernetes são pares de chave/valor que ajudam a manter esses recursos e acompanhar como eles interagem uns com os outros em um cluster.

Por exemplo, você pode usar o oci.oraclecloud.com/oke-is-preemptible=true label (que o Kubernetes Engine aplica aos nós de trabalho hospedados em instâncias preemptíveis) com seletores de nó do Kubernetes e afinidade/antiafinidade de nó para controlar quais pods são programados nesses nós de trabalho.

Consulte Rótulos, Anotações e Tintas Bem Conhecidos na documentação do Kubernetes.

Melhores Práticas: Usar a marcação de recursos do OCI

Recomendamos que você use a marcação de recursos do OCI para organizar os muitos recursos (como nós de trabalho, VCNs, balanceadores de carga e volumes em blocos) usados pelos clusters do Kubernetes que você cria com o Kubernetes Engine. Quando há um grande número de recursos espalhados por vários compartimentos em uma tenancy, você pode achar difícil rastrear os recursos usados para fins específicos. Da mesma forma, você pode achar difícil agregar os recursos, reportá-los e tomar ações em massa sobre eles.

A tag permite definir chaves e valores e associá-los aos recursos. Em seguida, você pode usar as tags para organizar e listar recursos com base em suas necessidades de negócios.

Consulte Marcando Recursos Relacionados ao Cluster do Kubernetes.

Melhores Práticas: Defina solicitações e limites de recursos

Recomendamos:

solicitações de recursos, para especificar a quantidade mínima de recursos que um contêiner pode usar
limites de recursos, para especificar a quantidade máxima de recursos que um contêiner pode usar

Ao trabalhar com um cluster do Kubernetes, um desafio comum é a falha ocasional de um aplicativo em implantar em um cluster devido à disponibilidade limitada de recursos nesse cluster. A falha é causada por solicitações de recursos e os limites de recursos não foram definidos.

Se você não definir solicitações e limites de recursos, os pods em um cluster poderão começar a utilizar mais recursos do que o necessário. Se um pod começar a consumir mais CPU ou memória em um nó, o kube-scheduler poderá não conseguir colocar novos pods no nó e o próprio nó poderá até falhar.

Consulte Solicitações e limites na documentação do Kubernetes.

Melhores Práticas: Reserve recursos para daemons do sistema Kubernetes e SO

Recomendamos que você use OS sinalizadores kubelet --kube-reserved e --system-reserved para reservar recursos de CPU e memória para daemons do sistema Kubernetes (como kubelet e container runtime) e daemons do sistema operacional (como sshd e systemd), respectivamente. Por exemplo:

--kube-reserved=cpu=500m,memory=1Gi
--system-reserved=cpu=100m,memory=100Mi

OS pods em execução em um nó de trabalho podem consumir todos OS recursos de CPU e memória disponíveis e, portanto, impedir que outros processos essenciais (como OS daemons do sistema Kubernetes e do sistema operacional) sejam executados no nó. Quando OS daemons do sistema Kubernetes e SO não podem ser executados, o nó de trabalho pode ficar sem resposta, instável e falhar inesperadamente sob carga pesada.

Para evitar que OS pods solicitem recursos exigidos pelos daemons do sistema operacional e do Kubernetes, inclua OS sinalizadores kubelet --kube-reserved e --system-reserved como opções kubelet-extra-args em um script personalizado cloud-init. Para obter mais informações e um exemplo, consulte Exemplo 4: Usando um Script Cloud-init Personalizado para Reservar Recursos para Daemons do Sistema Kubernetes e do Sistema Operacional.

Ao usar o flag kubelet --kube-reserved para reservar uma parte dos recursos de CPU e memória de um nó de trabalho para uso pelos daemons do sistema Kubernetes, considere as seguintes recomendações:

A quantidade de recursos de CPU que recomendamos que você reserve para daemons do sistema Kubernetes depende do número de núcleos de CPU no nó de trabalho, conforme mostrado na seguinte tabela:


Número de núcleos de CPU no nó de trabalho	1	2	3	4	5	Mais de 5
CPU recomendada para reserva, em milicore (m)	60 minutos	70 minutos	80 minutos	85 minutos	90 minutos	Um adicional de 2,5 m para cada núcleo adicional no nó de trabalho

A quantidade de recursos de memória que recomendamos que você reserve para daemons do sistema Kubernetes depende da quantidade de memória no nó de trabalho, conforme mostrado na seguinte tabela:


Memória no nó de trabalho, em GiB	4 GiB	8 GiB	16 GiB	128 GiB	Mais de 128 GiB
Memória recomendada para reserva, em GiB	1 GiB	1 GiB	2 GiB	9 GiB	Um 20 MiB adicional para cada GiB adicional da memória do nó de trabalho

Ao usar o flag kubelet --system-reserved para reservar uma parte dos recursos de CPU e memória de um nó para uso pelos daemons do sistema operacional, considere as seguintes recomendações:

A quantidade de recurso de CPU que recomendamos que você reserve para daemons do sistema operacional (independentemente da forma do nó) é de 100 m (milicore).
A quantidade de recursos de memória que recomendamos que você reserve para daemons do sistema operacional (independentemente da forma do nó) é de 100 Mi (mebibytes).

Observe que nossas recomendações de CPU e memória para os sinalizadores kubelet --kube-reserved e --system-reserved podem não ser ideais para as cargas de trabalho que você pretende executar; portanto, talvez seja necessário alterar os valores adequadamente. Talvez você também precise ajustar os valores ao longo do tempo.

Para ver a diferença entre o total de recursos em um nó de trabalho e os recursos no nó que as cargas de trabalho podem usar, execute o seguinte comando:

kubectl get node <NODE_NAME> -o=yaml | grep -A 6 -B 7 capacity

Exemplo de saída:

  allocatable:
    cpu: 15743m
    ephemeral-storage: "34262890849"
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 234972476Ki
    pods: "110"
  capacity:
    cpu: "16"
    ephemeral-storage: 37177616Ki
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 257197372Ki
    pods: "110"

A diferença entre a CPU e a memória "capacidade" e "alocáveis" na saída de exemplo inclui a CPU e as reservas de memória para OS daemons do sistema Kubernetes e do sistema operacional.

Observação

A partir de junho de 2024, as recomendações para as reservas de recursos de CPU e memória para daemons do sistema operacional e do Kubernetes descritas nesta seção são usadas como padrões para todas as imagens do OKE, para todas as versões suportadas do Kubernetes. As recomendações também são usadas como padrões para todas as imagens de plataforma do Kubernetes versão 1.30 e posterior. Os padrões se aplicam quando você especifica uma imagem do OKE liberada em junho de 2024 (ou mais recente) e quando faz upgrade da versão do Kubernetes em execução em um cluster para a versão 1.30 (ou mais recente). Se você especificar uma imagem do OKE lançada em junho de 2024 (ou mais recente) ou se fizer upgrade de um cluster para o Kubernetes versão 1.30, recomendamos que você verifique se as reservas padrão são apropriadas para as cargas de trabalho que você pretende executar.

Recomendações adicionais:

Antes de aplicar alterações de reserva aos clusters de produção, sempre faça benchmark e teste o impacto das alterações de reserva em um ambiente que não seja de produção.
Use os sinalizadores kubelet --eviction-hard ou --eviction-soft para definir limites apropriados para memória e pressão do disco. Quando você define esses limites, o sistema Kubernetes pode proteger a estabilidade do sistema removendo pods menos importantes quando necessário. Para obter mais informações, consulte Evição de Pressão do Nó na documentação do Kubernetes.
Lembre-se de que a reserva de muitos recursos pode levar à subutilização de nós. Seu objetivo é encontrar um equilíbrio apropriado entre garantir a disponibilidade de recursos para componentes críticos e maximizar a disponibilidade de recursos para cargas de trabalho. Recomendamos que você comece com reservas de recursos maiores e reduza gradualmente os tamanhos das reservas com base na observação, em vez de começar com reservas de recursos menores que sejam muito baixas e corram o risco de instabilidade do sistema. Use métricas de ferramentas de monitoramento e alerta para observar o uso de recursos pelo Kubernetes e componentes do sistema ao longo do tempo.
Ao reservar recursos, leve em conta as diferenças na forma do nó e no tipo de carga de trabalho. Nós grandes podem exigir reservas absolutas maiores do que nós menores. Cargas de trabalho com necessidades de recursos específicas ou padrões de intermitência conhecidos podem exigir reservas de recursos maiores ou menores.

Para obter mais informações sobre como reservar recursos, consulte Reserve Compute Resources for System Daemons na documentação do Kubernetes.

Melhores Práticas: Forneça nós dedicados usando padrões e tolerâncias

Recomendamos que você use restrições e tolerâncias do Kubernetes para limitar aplicativos com uso intenso de recursos a nós de trabalho específicos.

O uso de restrições e tolerâncias permite manter os recursos do nó disponíveis para cargas de trabalho que os exigem e impede a programação de outras cargas de trabalho nos nós.

Por exemplo, ao criar um cluster usando o Kubernetes Engine, você pode definir nós de trabalho para ter uma forma de GPU ou uma forma com um grande número de CPUs avançadas. Esses nós de trabalho bem especificados são ideais para grandes cargas de trabalho de processamento de dados. No entanto, esse hardware especializado é normalmente caro de implementar. Consequentemente, você normalmente desejará limitar as cargas de trabalho que podem ser programadas nesses nós. Para limitar as cargas de trabalho que podem ser programadas nos nós de trabalho bem especificados, adicione uma mancha aos nós. Por exemplo, ao executar um destes comandos:

kubectl taint nodes <node-name> special=true:NoSchedule
kubectl taint nodes <node-name> special=true:PreferNoSchedule

Depois de adicionar uma mancha aos nós de trabalho bem especificados, adicione uma tolerância correspondente aos pods que você deseja permitir para usar os nós.

Da mesma forma, você pode usar o oci.oraclecloud.com/oke-is-preemptible=true label (que o Kubernetes Engine aplica aos nós de trabalho hospedados em instâncias preemptíveis) com tolerações do Kubernetes para controlar quais pods são programados nesses nós de trabalho.

Consulte Taints and Tolerations na documentação do Kubernetes.

Melhores Práticas: Controle a programação do pod usando seletores de nó e afinidade

Há várias maneiras de restringir um pod a ser executado em nó(s) específico(s) ou especificar uma preferência para que um pod seja executado em nó(s) específico(s). Todas as abordagens recomendadas usam seletores de rótulo para facilitar a seleção. Muitas vezes, o kube-scheduler fará automaticamente uma colocação razoável sem tais restrições ou preferências. No entanto, há algumas circunstâncias em que você pode querer controlar o nó no qual um pod é executado.

Nessas situações, recomendamos que você controle a programação de pods em nós usando seletores de nó do Kubernetes, afinidade de nó e afinidade entre pods.

O uso de seletores de nó, afinidade de nó e afinidade entre pods permite que o kube-scheduler isole logicamente cargas de trabalho, como pelo hardware do nó.

Por exemplo, você pode fornecer aos nós um rótulo para indicar que eles têm armazenamento SSD conectado localmente. Para especificar que um pod deve ser executado apenas em nós com armazenamento SSD conectado localmente, inclua esse label como seletor de nó na especificação do pod. O Kubernetes só programa os pods em nós com labels correspondentes.

Consulte Designando Pods a Nós na documentação do Kubernetes.

Melhores Práticas: Usar o serviço OCI Full Stack Disaster Recovery para backup e recuperação de desastres

Recomendamos que você use o serviço OCI Full Stack Disaster Recovery com o Kubernetes Engine para backup e recuperação de desastres. O Full Stack Disaster Recovery é um serviço de orquestração e gerenciamento de recuperação de desastre nativo da nuvem que fornece recursos abrangentes de recuperação de desastre para todas as camadas de uma pilha de aplicativos, incluindo infraestrutura, middleware, banco de dados e aplicativos.

Ao usar o Full Stack Disaster Recovery, você pode adicionar clusters do Kubernetes que criou com o Kubernetes Engine a grupos de proteção de recuperação de desastres, permitindo automatizar a orquestração de recuperação de ponta a ponta do seu sistema Kubernetes entre regiões do OCI.

Para obter mais informações, consulte a documentação do Full Stack Disaster Recovery e as seguintes seções em particular:

Observe que antes do lançamento do Full Stack Disaster Recovery, recomendamos anteriormente o uso de ferramentas de terceiros (como Kasten, Rancher, Trilio ou Velero) com o Kubernetes Engine para backup e recuperação de desastres. Se uma ferramenta de recuperação de desastres de terceiros já estiver em vigor, você poderá continuar a usá-la. No entanto, recomendamos que você considere os benefícios do OCI Full Stack Disaster Recovery como uma alternativa às ferramentas de terceiros.

Documentação do Oracle Cloud Infrastructure