Serviços de cluster

Os serviços de cluster são executados dentro de um cluster EKS, mas não são cargas de trabalho do usuário. Se você tem um servidor Linux, geralmente precisa executar serviços como NTP, syslog e um tempo de execução de contêiner para suportar suas cargas de trabalho. Os serviços de cluster são serviços de suporte semelhantes que ajudam você a automatizar e operar seu cluster. No Kubernetes, eles geralmente são executados no namespace kube-system e alguns são executados como. DaemonSets

Espera-se que os serviços de cluster tenham um alto tempo de atividade e geralmente sejam essenciais durante interrupções e para solução de problemas. Se um serviço de cluster principal não estiver disponível, você poderá perder o acesso aos dados que podem ajudar a recuperar ou evitar uma interrupção (por exemplo, alta utilização do disco). Eles devem ser executados em instâncias de computação dedicadas, como um grupo de nós separado ou o AWS Fargate. Isso garantirá que os serviços de cluster não sejam afetados nas instâncias compartilhadas por cargas de trabalho que possam estar aumentando ou usando mais recursos.

CoreDNS de escala

O escalonamento do CoreDNS tem dois mecanismos principais. Reduzindo o número de chamadas para o serviço CoreDNS e aumentando o número de réplicas.

Reduza as consultas externas diminuindo os ndots

A configuração ndots especifica quantos pontos (também conhecidos como “pontos”) em um nome de domínio são considerados suficientes para evitar a consulta ao DNS. Se seu aplicativo tiver uma configuração de ndots de 5 (padrão) e você solicitar recursos de um domínio externo, como api.example.com (2 pontos), o CoreDNS será consultado para cada domínio de pesquisa definido em /etc/resolv.conf para um domínio mais específico. Por padrão, os seguintes domínios serão pesquisados antes de fazer uma solicitação externa.

api.example.<namespace>.svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example.<region>.compute.internal

Os region valores namespace e serão substituídos pelo namespace das cargas de trabalho e pela região de computação. Você pode ter domínios de pesquisa adicionais com base nas configurações do seu cluster.

Você pode reduzir o número de solicitações para o CoreDNS diminuindo a opção ndots da sua carga de trabalho ou qualificando totalmente suas solicitações de domínio incluindo um final. (por exemploapi.example.com.). Se sua carga de trabalho se conectar a serviços externos via DNS, recomendamos definir ndots como 2 para que as cargas de trabalho não façam consultas desnecessárias de DNS de cluster dentro do cluster. Você pode definir um servidor DNS e um domínio de pesquisa diferentes se a carga de trabalho não exigir acesso aos serviços dentro do cluster.

spec:
  dnsPolicy: "None"
  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: edns0

Se você reduzir ndots para um valor muito baixo ou se os domínios aos quais você está se conectando não incluírem especificidade suficiente (inclusive no final), é possível que as pesquisas de DNS falhem. Certifique-se de testar como essa configuração afetará suas cargas de trabalho.

Dimensione o CoreDNS horizontalmente

As instâncias do CoreDNS podem ser escaladas adicionando réplicas adicionais à implantação. É recomendável usar o NodeLocal DNS ou o autoescalador proporcional do cluster para escalar o CoreDNS.

NodeLocal O DNS exigirá a execução de uma instância por nó, como uma, o DaemonSet que exigirá mais recursos computacionais no cluster, mas evitará falhas nas solicitações de DNS e diminuirá o tempo de resposta das consultas de DNS no cluster. O autoescalador proporcional do cluster escalará o CoreDNS com base no número de nós ou núcleos no cluster. Essa não é uma correlação direta com consultas de solicitação, mas pode ser útil dependendo das cargas de trabalho e do tamanho do cluster. A escala proporcional padrão é adicionar uma réplica adicional para cada 256 núcleos ou 16 nós no cluster, o que ocorrer primeiro.

Dimensione o servidor de métricas do Kubernetes verticalmente

O Kubernetes Metrics Server oferece suporte ao escalonamento horizontal e vertical. Ao escalar horizontalmente o Metrics Server, ele estará altamente disponível, mas não será escalado horizontalmente para lidar com mais métricas de cluster. Você precisará escalar verticalmente o Metrics Server com base em suas recomendações à medida que os nós e as métricas coletadas forem adicionados ao cluster.

O Metrics Server mantém os dados que coleta, agrega e veicula na memória. Conforme o cluster cresce, a quantidade de dados que o Metrics Server armazena aumenta. Em grandes clusters, o Metrics Server exigirá mais recursos computacionais do que a reserva de memória e CPU especificada na instalação padrão. Você pode usar o Vertical Pod Autoscaler (VPA) ou o Addon Resizer para escalar o Metrics Server. O Addon Resizer é dimensionado verticalmente em proporção aos nós de trabalho e o VPA é dimensionado com base no uso da CPU e da memória.

Duração do CoreDNS lamduck

Os pods usam o kube-dns Serviço para resolução de nomes. O Kubernetes usa NAT de destino (DNAT) para redirecionar o tráfego dos nós para os pods de back-end kube-dns do CoreDNS. Conforme você escala a implantação do CoreDNSkube-proxy, atualiza as regras e cadeias de iptables nos nós para redirecionar o tráfego de DNS para os pods do CoreDNS. A propagação de novos endpoints ao aumentar a escala e a exclusão de regras ao reduzir o CoreDNS pode levar de 1 a 10 segundos, dependendo do tamanho do cluster.

Esse atraso na propagação pode causar falhas na pesquisa de DNS quando um pod CoreDNS é encerrado, mas as regras de iptables do nó não foram atualizadas. Nesse cenário, o nó pode continuar enviando consultas de DNS para um pod CoreDNS encerrado.

Você pode reduzir as falhas de pesquisa de DNS definindo uma duração lenta em seus pods do CoreDNS. Enquanto estiver no modo idiota, o CoreDNS continuará respondendo às solicitações em voo. Definir uma duração mínima atrasará o processo de desligamento do CoreDNS, dando aos nós o tempo necessário para atualizar suas regras e cadeias de iptables.

Recomendamos definir a duração do CoreDNS lameduck para 30 segundos.

Sonda de prontidão para CoreDNS

Recomendamos usar /ready em vez da sonda /health de prontidão do CoreDNS.

De acordo com a recomendação anterior de definir a duração do lameduck em 30 segundos, fornecendo tempo suficiente para que as regras de iptables do nó sejam atualizadas antes do término do pod, empregar, em vez da sonda de prontidão /ready do CoreDNS, garante que /health o pod CoreDNS esteja totalmente preparado na inicialização para responder prontamente às solicitações de DNS.

readinessProbe:
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP

Para obter mais informações sobre o plug-in CoreDNS Ready, consulte https://coredns. io/plugins/ready/

Agentes de registro e monitoramento

Agentes de registro e monitoramento podem adicionar uma carga significativa ao seu plano de controle de cluster porque os agentes consultam o servidor da API para enriquecer registros e métricas com metadados de carga de trabalho. O agente em um nó só tem acesso aos recursos do nó local para ver coisas como nome do contêiner e do processo. Ao consultar o servidor da API, ele pode adicionar mais detalhes, como nome e rótulos de implantação do Kubernetes. Isso pode ser extremamente útil para solucionar problemas, mas prejudicial ao dimensionamento.

Como há muitas opções diferentes de registro e monitoramento, não podemos mostrar exemplos para cada provedor. Com o fluentbit, recomendamos habilitar o Use_Kubelet para buscar metadados do kubelet local em vez do Kubernetes API Server e definir um número que reduza as chamadas repetidas quando os dados podem Kube_Meta_Cache_TTL ser armazenados em cache (por exemplo, 60).

O monitoramento e o registro em escala têm duas opções gerais:

• Desativar integrações

• Amostragem e filtragem

Desabilitar as integrações geralmente não é uma opção porque você perde os metadados do log. Isso elimina o problema de escalonamento da API, mas introduzirá outros problemas ao não ter os metadados necessários quando necessário.

A amostragem e a filtragem reduzem o número de métricas e registros coletados. Isso reduzirá a quantidade de solicitações para a API Kubernetes e reduzirá a quantidade de armazenamento necessária para as métricas e os registros coletados. Reduzir os custos de armazenamento reduzirá o custo geral do sistema.

A capacidade de configurar a amostragem depende do software do agente e pode ser implementada em diferentes pontos de ingestão. É importante adicionar a amostragem o mais próximo possível do agente, pois provavelmente é aí que as chamadas do servidor da API acontecem. Entre em contato com seu provedor para saber mais sobre o suporte à amostragem.

Se você estiver usando CloudWatch um CloudWatch Logs, poderá adicionar a filtragem de agentes usando os padrões descritos na documentação.

Para evitar a perda de registros e métricas, você deve enviar seus dados para um sistema que possa armazenar dados em buffer no caso de uma interrupção no terminal receptor. Com o fluentbit, você pode usar o Amazon Kinesis Data Firehose para manter temporariamente os dados, o que pode reduzir a chance de sobrecarregar seu local final de armazenamento de dados.