Como reduzir o uso de recursos de complementos em clusters menores

Padrão

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.

Como criar uma política de escalonamento personalizada

Acesse o menu Cargas de trabalho do Kubernetes no Console do Google Cloud.
Use a barra de filtros para encontrar o Fluentd DaemonSet: remova o filtro "Is System: false" e adicione um filtro para Name: "fluentd-gcp-v".

Observação: o número da versão no nome da carga de trabalho depende da versão implementada do Fluentd no momento. Deixe a barra de filtros completar o nome automaticamente.
Clique na carga de trabalho "fluentd" na lista.
Veja as estatísticas de uso de recursos de cada pod do Fluentd clicando nos nomes dos pods na seção "Pod gerenciado". Haverá um nó de pod por cluster. O cluster neste exemplo tem três nós.
Analise cada pod no seu cluster e observe quanta CPU e memória estão sendo usadas pelo contêiner fluentd-gcp. Observe os valores máximos de cada recurso. Usaremos esses valores em nossa política de escalonamento personalizada. Você pode alterar a escala de tempo dos gráficos para visualizar tendências de longo prazo.

Neste exemplo, o pico de uso da CPU do pod está próximo da CPU 2.0e-2:

Neste exemplo, o pico de uso de memória do pod é de 135 MB.
Use os dados de uso de recursos observados para calcular os valores a serem usados na política de escalonamento:
- Multiplique o uso máximo da CPU por 1.000 para conseguir um valor de mCPU para o GKE.
- A memória máxima será a nova solicitação de memória. Para deixar espaço para crescimento, podemos fazer com que o limite de memória seja 1,1x da solicitação.

Use os valores calculados para gravar uma política de escalonamento para o Fluentd. Use o seguinte manifesto como modelo:

apiVersion: scalingpolicy.kope.io/v1alpha1
kind: ScalingPolicy
metadata:
  name: fluentd-gcp-scaling-policy
  namespace: kube-system
spec:
  containers:
  - name: fluentd-gcp
    resources:
      requests:
      - resource: cpu
        base: [CPU request value from above]
      - resource: memory
        base: [Memory request value from above]
      limits:
      - resource: memory
        base: [Memory limit value from above]

Esse manifesto não especifica um limite de CPU. Isso permite que o Fluentd consuma mais CPU conforme necessário, sem que haja despejo. É possível especificar uma CPU se o fluentd não pode consumir mais do que uma quantidade específica de CPU.

Aplique a política de escalonamento com o kubectl apply. Por exemplo, se o nome do arquivo de política de escalonamento for fluentd_scaling_policy.yaml:
```
kubectl apply -f fluentd_scaling_policy.yaml
```

Confirme se os novos valores foram aplicados. Pode levar alguns minutos para que os novos valores sejam aplicados ao cluster.

kubectl get ds --namespace=kube-system -l k8s-app=fluentd-gcp -o custom-columns=NAME:.metadata.name,CPU_REQUEST:.spec.template.spec.containers[].resources.requests.cpu,MEMORY_REQUEST:.spec.template.spec.containers[].resources.requests.memory,MEMORY_LIMIT:.spec.template.spec.containers[].resources.limits.memory

A resposta ao comando será semelhante à mostrada a seguir. Os valores de solicitação e limite correspondem aos valores na política:

NAME                 CPU_REQUEST   MEMORY_REQUEST   MEMORY_LIMIT
fluentd-gcp-v3.0.0   20m           135M             200M

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.