Como reduzir o uso de recursos de complementos em clusters menores

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Nesta página, explicamos como reduzir os recursos consumidos pelos complementos do cluster do Google Kubernetes Engine (GKE). Use essas técnicas em pequenos clusters, como clusters com três ou menos nós ou clusters que usam tipos de máquina com recursos limitados.

Visão geral

Além de sua carga de trabalho, os nós do cluster executam vários complementos que integram o nó com o plano de controle do cluster e fornecem outras funcionalidades. Desse modo, há uma disparidade entre os recursos totais de um nó e os recursos que estão disponíveis para sua carga de trabalho. Saiba mais sobre a arquitetura de cluster no GKE.

As configurações padrão desses complementos são apropriadas para clusters típicos, mas você pode ajustar o uso de recursos dos complementos, dependendo da sua configuração de cluster específica. Você também pode desativar alguns complementos que não são exigidos pelo seu caso de uso.

O ajuste fino é especialmente útil para clusters com recursos de computação limitados, como clusters com um único nó ou muito poucos nós, ou clusters que são executados em tipos de máquinas de baixo custo. Use um cluster pequeno para conhecer o GKE ou testar novos recursos.

Como configurar complementos

Você pode configurar cada complemento individual para reduzir seu impacto nos recursos do nó.

Complementos fornecem visibilidade e depuração para seu cluster. Por exemplo, se você desativar o monitoramento em um cluster que esteja executando cargas de trabalho de produção, os problemas serão mais difíceis de depurar.

Cloud Logging

O Cloud Logging coleta, processa e armazena automaticamente os registros de contêiner e sistema. Para configurar o Cloud Logging, consulte Como configurar o suporte de monitoramento e geração de registros para um novo cluster.

É possível desativar o Cloud Logging completamente ou deixá-lo ativado, mas restringir o uso de recursos ajustando o complemento do Fluentd.

Como visualizar registros quando o Cloud Logging estiver desativado

Quando o Cloud Logging está desativado, ainda é possível ver as entradas de registro recentes.

Para ver os registros de um pod específico, execute o seguinte comando:

kubectl logs -f POD_NAME

A opção -f transmite registros.

Para ver os registros de todos os pods que correspondem a um seletor, execute o seguinte comando:

kubectl logs -l SELECTOR

Substitua SELECTOR por um seletor de implantação (por exemplo, 'app=frontend').

Como ajustar o Fluentd

Se você optar por não desativar a geração de registros, poderá restringir os recursos utilizados pelos registros ajustando o Fluentd.

O Fluentd coleta registros dos nós e os envia para o pacote de operações do Google Cloud. O agente Fluentd é implantado em seu cluster usando um DaemonSet para que uma instância do agente seja executada em cada nó do cluster. O Fluentd pode exigir mais recursos para aplicativos que gravam uma grande quantidade de dados de registro.

Você pode ajustar a alocação de recursos do Fluentd criando uma política de escalonamento específica para seus requisitos. Uma política de escalonamento define as solicitações e limites de recursos do pod. Consulte a documentação do Kubernetes sobre Como gerenciar recursos para contêineres para saber como o programador do Kubernetes lida com solicitações e limites de recursos. Para mais informações sobre como as solicitações e os limites de recursos afetam a qualidade dos serviços (QoS), consulte Qualidade de serviço de recursos no Kubernetes.

Expanda a seção a seguir para ver instruções sobre como medir o uso de recursos do Fluentd e como escrever uma política de escalonamento personalizada usando esses valores.

Cloud Monitoring

Recomendamos que você use o Cloud Monitoring. No entanto, é possível desativar o monitoramento para recuperar alguns recursos.

Para mais informações sobre o Cloud Monitoring, consulte a visão geral do Cloud Operations para GKE.

Se você usar o complemento de escalonador automático horizontal de pods (HPA, na sigla em inglês) com métricas personalizadas do Cloud Monitoring, desative-o no cluster antes de desabilitar completamente o Cloud Monitoring.

Para configurar o Cloud Monitoring, consulte Como configurar o suporte de monitoramento e geração de registros para um novo cluster.

Escalonamento automático de pod horizontal

O escalonamento automático de pod horizontal escalona as réplicas das implantações com base em métricas como o uso da CPU ou da memória. Se você não precisar do escalonamento automático do pod horizontal e já tiver desativado o Cloud Monitoring, também poderá desativar o escalonamento automático do pod horizontal.

Para desativar o complemento de escalonamento automático horizontal de pods, execute o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --update-addons=HorizontalPodAutoscaling=DISABLED

Para ativar o complemento de escalonamento automático de pod horizontal, execute o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --update-addons=HorizontalPodAutoscaling=ENABLED

DNS do Kubernetes (kube-dns)

O Kubernetes DNS (kube-dns) programa uma implantação e um serviço DNS no cluster, e os pods no cluster usam o serviço kube-dns para resolver nomes DNS para endereços IP para serviços, pods, nós e endereços IP públicos. Ele resolve os nomes de domínio público, como example.com, e os nomes de serviço, como my-svc.my-namespace.svc.cluster-domain.example. Saiba mais em Descoberta de serviços e DNS.

Por padrão, o GKE executa várias réplicas kube-dns para alta disponibilidade. Se você não precisar de DNS altamente disponível, poderá economizar recursos reduzindo o número de réplicas do kube-dns. Se você não precisar de resolução de nomes DNS, desative totalmente o kube-dns. Se você desativar o kube-dns, será possível configurar o DNS externo nos pods.

Para mais informações, consulte Como usar o kube-dns.

Como reduzir a replicação de DNS do Kube

Para desativar o kube-dns autoscaler e reduzir o kube-dns para a réplica 1, execute os seguintes comandos:

kubectl scale --replicas=0 deployment/kube-dns-autoscaler --namespace=kube-system
kubectl scale --replicas=1 deployment/kube-dns --namespace=kube-system

Para ativar o kube-dns autoscaler, execute o seguinte comando:

kubectl scale --replicas=1 deployment/kube-dns-autoscaler --namespace=kube-system

Para um controle mais preciso do escalonamento automático, ajuste os parâmetros de escalonamento automático.

Para saber como configurar uma implantação personalizada do kube-dns, consulte Como configurar uma implantação personalizada do kube-dns.

Como desativar o DNS do Kube

É possível desativar completamente o DNS do Kube. Ele é necessário para cargas de trabalho que resolvam o nome DNS de qualquer serviço dependente. Isso inclui nomes de domínio público e os nomes dos serviços de cluster.

Para desativar o kube-dns, execute os seguintes comandos:

kubectl scale --replicas=0 deployment/kube-dns-autoscaler --namespace=kube-system
kubectl scale --replicas=0 deployment/kube-dns --namespace=kube-system

Para ativar kube-dns, execute o seguinte comando e substitua --replicas=1 pelo número de réplicas que você quer:

kubectl scale --replicas=1 deployment/kube-dns --namespace=kube-system

Para ativar o escalonamento automático kube-dns, execute o seguinte comando:

kubectl scale --replicas=1 deployment/kube-dns-autoscaler --namespace=kube-system
Pesquisas de DNS externo sem DNS do Kube

É possível configurar seus pods para usar a resolução de nome de domínio externo com um serviço DNS de sua escolha. Veja no exemplo a seguir um pod que usa o DNS público do Google para pesquisas de nome externo:

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsPolicy: "None"
  dnsConfig:
    nameservers:
      - 8.8.8.8
      - 8.8.4.4
Descoberta de serviço sem DNS do Kube

As variáveis de ambiente de serviço podem ser usadas como uma alternativa para a descoberta de serviço baseada em DNS. Quando um pod é criado, as variáveis do ambiente de serviço são criadas automaticamente para cada serviço no mesmo namespace que o pod. Isso é mais restritivo que o DNS do Kube, porque as variáveis de ambiente são criadas apenas para serviços gerados antes da criação do pod.

A seguir