Melhores Práticas para Cluster Grande

Melhores Práticas: Limite o dimensionamento de burst para aproximadamente 10% dos pods e nós em um cluster

Recomendamos que nós e pods sejam adicionados ou removidos de um cluster grande em lotes de aproximadamente 10% do seu número total.

As ações de dimensionamento do cluster (como alterar o número de nós em um pool de nós, configurar o número de réplicas em uma implantação e gerar jobs no cluster) podem gerar uma grande quantidade de tráfego de API para coordenação distribuída e programação de recursos. A recomendação de 10% geralmente é conservadora o suficiente para evitar encontrar limites de taxa no servidor de API do Kubernetes e outros pontos finais de nuvem downstream e, portanto, evitar repetições caras durante um período de alto tráfego que pode causar atrasos devido a backoffs.

A recomendação de 10% é um ponto de partida e depende do tamanho do cluster e dos tipos de carga de trabalho que ele contém. Cargas de trabalho com muitos operadores que se comunicam com o kube-apiserver podem exigir mais suavização de burst, enquanto nós vazios com carga de trabalho mínima podem ser capazes de explodir mais rapidamente.

Consulte Considerações para clusters grandes na documentação do Kubernetes.

Melhores Práticas: Configure FlowSchemas para otimizar decisões de limitação de taxa quando estiver sob carga

Recomendamos a despriorização de solicitações que não sejam críticas para o tempo em clusters grandes.

O recurso API Priority and Fairness (APF) no kube-apiserver expõe alguns controles a solicitações de limite de taxa. É possível configurar o recurso APF usando níveis de prioridade, que definem configurações flexíveis para o tamanho da mão e o tamanho da fila atribuídos a uma prioridade específica. O uso de níveis de prioridade permite que cargas de trabalho avançadas otimizem o processamento de solicitações e garante que as solicitações de alta prioridade sejam atendidas.

Um FlowSchema define o nível de prioridade ao qual uma solicitação pertence. Uma configuração comum, particularmente em clusters com cargas de trabalho de intermitência que exigem a adição ou remoção de um grande número de pods ou nós, é usar um FlowSchema que reduza a prioridade das solicitações LIST /events para o nível de prioridade catch-all. No Kubernetes, as chamadas LIST são geralmente as mais caras para o kube-apiserver servir e, em tempos de alta rotatividade, o número de eventos pode se tornar grande. Ao instalar um FlowSchema que reduz o nível de prioridade dessas chamadas, mais solicitações críticas de tempo podem ser atendidas. As solicitações de prioridade mais baixa recebem erros HTTP 429 Too Many Requests e serão repetidas mais tarde pelos clientes para se tornarem eventualmente consistentes.

Consulte Isolar solicitações não essenciais de outros fluxos famintos na documentação do Kubernetes.

Você pode usar as métricas publicadas pelo kube-apiserver em /metrics para identificar quando a limitação está ocorrendo e quais fluxos podem ser bons candidatos para um esquema personalizado:

• Use a métrica apiserver_flowcontrol_rejected_requests_total para ver quando as solicitações não são atendidas e devem ser repetidas. Se o valor se tornar diferente de zero, ocorreu limitação e talvez você queira agir.
• Use a métrica apiserver_flowcontrol_request_wait_duration_seconds para ver quais níveis de prioridade são um gargalo.

Consulte Boas práticas para usar Prioridade e Justiça da API na documentação do Kubernetes.

Melhores Práticas: Ajuste os complementos do cluster para dimensionar com o tamanho do cluster

Recomendamos configurar os complementos de flanela e CoreDNS em clusters grandes.

Os clusters aprimorados no Kubernetes Engine permitem que você configure os complementos instalados em um cluster (consulte Atualizando um Complemento de Cluster). Os padrões razoáveis para clusters menores não são necessariamente ideais para clusters grandes.

A configuração padrão para CoreDNS aloca 1 réplica por nó. No entanto, em clusters grandes, menos réplicas podem ser mais apropriadas. Por exemplo, uma configuração como {minReplica: 3, nodesPerReplica: 8} pode ser mais apropriada em um cluster grande. Uma configuração com menos réplicas não só consome menos recursos de computação dentro do cluster, mas também aumenta a probabilidade de ocorrências de cache eficientes ao consolidar solicitações de DNS em menos réplicas.

Para evitar que um único nó indisponível interrompa o rollout de uma alteração no flannel DaemonSet, você pode configurar a estratégia de rollout para ter um valor maxUnavailable, como 25%. Essa estratégia permite o rollout de uma alteração DaemonSet do flannel para um cluster grande que tem milhares de nós, mesmo que vários desses nós estejam indisponíveis.

Para os complementos de flannel e CoreDNS, em clusters grandes, talvez seja necessário aumentar as solicitações/limites de memória e CPU alocadas para acomodar a carga.

Consulte Configurando Complementos de Cluster.

Melhores Práticas: Configure clientes do Kubernetes para usar o tipo de conteúdo protobuf em vez de JSON

Recomendamos o uso do tipo de conteúdo protobuf com clusters grandes, quando disponível.

Por padrão, os clientes do Kubernetes usam JSON como o tipo de conteúdo para todas as solicitações. O uso de JSON como tipo de conteúdo é uma opção amigável e suficiente para a maioria dos casos de uso. No entanto, com clusters grandes, o uso de protobuf em vez de JSON como tipo de conteúdo pode melhorar o desempenho.

Para especificar o uso do tipo de conteúdo protobuf:

• Para solicitações, use o cabeçalho Content-Type: application/vnd.kubernetes.protobuf.
• Para respostas, use o cabeçalho Accept: application/vnd.kubernetes.protobuf, application/json. Especificando protobuf e json no cabeçalho Accept, o servidor de API do Kubernetes poderá voltar ao JSON se uma representação protobuf não existir para um objeto.

Consulte Representações alternativas de recursos na documentação do Kubernetes.

Melhores Práticas: Ative o Registro em Log de Serviço para visibilidade nos logs do plano de controle do Kubernetes

Recomendamos ativar logs de serviço para clusters grandes.

O servidor de API do Kubernetes reporta muitos problemas aos clientes por meio de avisos nas respostas do servidor, bem como por meio de eventos. No entanto, os logs dos seguintes contêineres de plano de controle do Kubernetes também capturam informações adicionais que podem ajudá-lo a entender o comportamento de clusters grandes:

• kube-programador
• kube-controlador-gerente
• cloud-controller-manager
• kube-apiserver

Para ativar e exibir esses logs do plano de controle do Kubernetes como logs de serviço no Oracle Cloud Infrastructure Logging, siga as instruções em Exibindo Logs de Serviço do Kubernetes Engine (OKE).

Melhores Práticas: Aloque blocos CIDR de rede com endereços IP suficientes para o número esperado de pods

Recomendamos considerar com antecedência como o tamanho do bloco CIDR de rede deve ser especificado para um cluster grande e qual plug-in CNI selecionar.

As alterações de sub-rede em um cluster em execução podem ser disruptivas. No caso de blocos CIDR de pod, você não pode alterar o bloco CIDR de pod especificado inicialmente para um cluster após a criação do cluster. Portanto, antes de criar um cluster grande, para evitar complicações de rede à medida que um cluster é dimensionado, considere cuidadosamente qual é o plug-in CNI mais apropriado a ser selecionado e qual é o tamanho de bloco CIDR mais apropriado a ser especificado.

O plug-in CNI flannel permite que grandes sub-redes privadas sejam alocadas para uso. Recomendamos um bloco CIDR /12 para o bloco CIDR de pod. Devido à natureza das VXLANs, o plug-in CNI flannel pode alocar/desalocar pods rapidamente, com a compensação de que o tráfego de pod agora está dentro do encapsulamento VXLAN. Ao escolher o tamanho de um bloco CIDR de pod, considere que o Kubernetes Engine aloca um bloco CIDR /25 para cada nó. O tamanho do bloco CIDR de pod que você especifica pode limitar o número de nós disponíveis a um cluster (por exemplo, se você especificar um bloco CIDR /24 como o bloco CIDR de pod, o cluster só poderá ter 8 nós). Dependendo da proporção pod-to-node que você espera, um número significativo de endereços IP pode ser alocado para cada nó que não será usado e não estará disponível para outros nós. Se esse for o caso, especifique um bloco CIDR de pod maior (consulte Blocos IPv4 CIDR e o Kubernetes Engine (OKE)).

O plug-in CNI de Rede Nativa de Pod se integra diretamente à rede da VCN usando anexos de VNIC secundária para endereços IP de pod. Essa abordagem elimina a necessidade de uma camada de rede de sobreposição de VXLAN adicional no cluster. O planejamento ainda é necessário porque as sub-redes da VCN são limitadas a um bloco CIDR /16 e o número de VNICs que podem ser anexadas a um nó é limitado pela forma do nó (consulte Tamanho e Faixas de Endereços da VCN Permitidos). Quando vários perfis de VNIC secundária são anexados para rede de pods, a capacidade do IP do pod é dimensionada usando ipCount por perfil, com um orçamento total combinado de ipCount de até 256 IPs de pod em todos os perfis de VNIC secundária configurados em um nó. Use Recursos do Aplicativo somente quando as cargas de trabalho tiverem que ser fixadas em um único perfil selecionável (cada pod solicitar apenas um Recurso do Aplicativo no modelo de programação no nível do pod). Para pods com várias interfaces, anexe interfaces adicionais usando Multus e NADs e não combine anotações de rede Multus com solicitações de Recurso de Aplicativo no nível do pod na mesma especificação do pod. Se você precisar de mais de 32 IPs por VNIC, configure sub-redes de pod com dois blocos CIDR como recomendação de planejamento de capacidade. Consulte Anexando Várias VNICs Secundárias para Rede de Pods.

A sub-rede do ponto final da API do Kubernetes geralmente exige apenas um pequeno bloco CIDR, porque apenas um único endereço IP do ponto final é necessário para cada cluster que compartilha a sub-rede. Por exemplo, a especificação de um bloco CIDR /29 para a sub-rede de ponto final da API do Kubernetes permite que 6 clusters compartilhem a sub-rede, enquanto um bloco CIDR /28 permite que 14 clusters compartilhem a sub-rede.

Melhores Práticas: Solicite antecipadamente aumentos no limite de serviço

Recomendamos revisar os limites de serviço configurados para sua tenancy e enviar solicitações com antecedência para aumentar os limites de serviço que você espera que grandes clusters atinjam. Consulte Limites por Serviço.

Clusters grandes geralmente atingem os seguintes limites:

• O número e o tamanho dos repositórios de imagem do contêiner.
• O número de nós permitidos para um único cluster.
• O número de gigabytes de volumes em blocos que podem ser alocados.

Para evitar possíveis interrupções, recomendamos enviar solicitações para aumentar os limites do serviço com antecedência, especialmente para limites de volumes em blocos usados como volumes de inicialização para nós.

Consulte Criando uma Solicitação de Aumento de Limite

Melhores Práticas: Aproveite o dimensionamento automático para gerenciar recursos de computação proporcionalmente com cargas de trabalho

Recomendamos o uso de dimensionadores automáticos (como o Kubernetes Cluster Autoscaler (CA), o Horizontal Pod Autoscaler (HPA) e o Vertical Pod Autoscaler (VPA)) com clusters grandes, para otimizar o uso de recursos.

O uso de um dimensionador automático permite configurar regras que definem quando provisionar mais nós, criar mais réplicas ou reduzir um cluster durante um período de silêncio.

O dimensionamento automático baseado em regras é uma maneira eficiente de gerenciar clusters grandes com milhares de nós e pods.

Consulte Melhores Práticas do Autoscaler.

Melhores Práticas: Usar regras sem monitoramento de estado para listas de segurança e grupos de segurança de rede para minimizar a sobrecarga de rastreamento de conexão

Recomendamos o uso de regras sem monitoramento de estado ao configurar listas de segurança e grupos de segurança de rede para clusters grandes.

Tutoriais e documentação muitas vezes especificam que você deve criar listas de segurança e grupos de segurança de rede com regras "estatísticas". As regras com monitoramento de estado utilizam o rastreamento de conexão para garantir que o caminho de retorno de uma solicitação seja permitido automaticamente, independentemente da presença de uma regra de saída (consulte Rastreamento de Conexão). Embora a permissão automática de caminhos de retorno se destine a simplificar a configuração de regras, esses caminhos de retorno permitidos automaticamente são uma possível sobrecarga que pode se tornar um problema para clusters grandes. O número de conexões que podem ser rastreadas é proporcional à forma da instância usada, mas simplesmente selecionar uma forma maior não necessariamente resolve o problema.

Para eliminar a sobrecarga do rastreamento de conexão e evitar possíveis limites de dimensionamento, recomendamos que, para cada caminho de rede:

1. você define uma regra de entrada e uma regra de saída correspondente como um par.
2. você especifica as regras de entrada e saída como "sem monitoramento de estado".

Consulte Regras com e sem Monitoramento de Estado