As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Serviços de cluster
Os serviços de cluster são executados dentro de um EKS cluster, 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.
Núcleo de escala DNS
O Scaling Core DNS tem dois mecanismos principais. Reduzindo o número de chamadas para o DNS serviço principal 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 consultas. DNS Se seu aplicativo tiver uma configuração ndots de 5 (padrão) e você solicitar recursos de um domínio externo, como api.example.com (2 pontos), o Core DNS será consultado para cada domínio de pesquisa definido como .conf para um domínio mais específico. in /etc/resolv 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 Core DNS diminuindo a opção ndotsapi.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 DNS consultas de cluster desnecessárias dentro do cluster. Você pode definir um DNS servidor 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 (incluindo o final), é possível que as pesquisas falhem. DNS Certifique-se de testar como essa configuração afetará suas cargas de trabalho.
Dimensione o núcleo DNS horizontalmente
DNSAs instâncias principais podem ser escaladas adicionando réplicas adicionais à implantação. É recomendável usar NodeLocal DNS
NodeLocal DNSexigirá a execução de uma instância por nó, como uma, DaemonSet o que exigirá mais recursos computacionais no cluster, mas evitará DNS solicitações com falha e diminuirá o tempo de resposta das consultas no cluster. DNS O autoescalador proporcional do cluster escalará o Core DNS 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 suporta escalabilidade 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
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 memória e a CPU reserva especificadas na instalação padrão. Você pode usar o Vertical Pod Autoscaler
Duração do DNS pato principal
Os pods usam o kube-dns
Serviço para resolução de nomes. O Kubernetes usa destination NAT (DNAT) para redirecionar o kube-dns
tráfego dos nós para os pods de back-end principais. DNS Conforme você escala a DNS implantação principal, kube-proxy
atualiza as regras e cadeias de iptables nos nós para redirecionar o DNS tráfego para os pods principaisDNS. A propagação de novos endpoints ao aumentar a escala e a exclusão de regras ao reduzir o Core DNS pode levar de 1 a 10 segundos, dependendo do tamanho do cluster.
Esse atraso na propagação pode causar falhas de DNS pesquisa quando um DNS pod Core é encerrado, mas as regras de iptables do nó não foram atualizadas. Nesse cenário, o nó pode continuar enviando DNS consultas para um Core DNS Pod encerrado.
Você pode reduzir as falhas de DNS pesquisa definindo uma duração mínima
Recomendamos definir a duração do Core DNS lameduck para 30 segundos.
Sonda de DNS prontidão do núcleo
Recomendamos usar /ready
em vez da sonda /health
de prontidão DNS do Core.
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, /ready
em vez da sonda de DNS prontidão Core, garante que o DNS pod Core esteja totalmente preparado na inicialização /health
para responder prontamente às solicitações. DNS
readinessProbe: httpGet: path: /ready port: 8181 scheme: HTTP
Para obter mais informações sobre o plug-in Core DNS 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 API servidor 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 API servidor, 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 fluentbitKube_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 API de escalabilidade, 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 o Kubernetes API 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 API servidor 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