Como reduzir o uso de recursos de complementos em clusters menores

Nesta página, explicamos como você pode reduzir os recursos consumidos pelos complementos do cluster. 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 mestre 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. Consulte a documentação da arquitetura de cluster para ver mais detalhes.

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. Você pode usar um pequeno cluster para conhecer o GKE ou testar novos recursos. Os clusters criados usando o modelo chamado Seu primeiro cluster também podem se beneficiar do ajuste fino.

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.

Stackdriver Logging

O Stackdriver Logging coleta, processa e armazena automaticamente seus registros de contêiner e sistema.

Você pode desativar o Stackdriver Logging completamente ou deixá-lo ativado, mas restringir o uso de recursos ajustando o complemento do Fluentd.

Para desativar o Stackdriver Logging:

gcloud container clusters update [CLUSTER_NAME] --logging-service none

Para ativar o Stackdriver Logging:

gcloud container clusters update [CLUSTER_NAME] --logging-service logging.googleapis.com

Como exibir registros quando o Stackdriver Logging está desativado

Quando o Stackdriver Logging está desativado, você ainda pode ver as entradas de registro recentes. Para ver os registros de um pod específico:

kubectl logs -f [POD_NAME]

A opção -f transmite registros.

Para ver os registros de todos os pods que correspondem a um seletor:

kubectl logs -l [SELECTOR]

em que [SELECTOR] é 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, como descrito anteriormente, poderá restringir os recursos utilizados pelos registros ajustando o Fluentd.

O Fluentd coleta registros de seus nós e os envia para o Stackdriver. O agente Fluentd é implantado em seu cluster usando um DaemonSet para que uma instância do agente seja executada em cada nó do cluster. Os requisitos de recursos do Fluentd dependem da sua carga de trabalho específica. Quanto maior for a geração de registros, mais recursos serão necessários.

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 Como gerenciar recursos de cálculo 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, na sigla em inglês), 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.

Stackdriver Monitoring

Recomendamos que você use o StackDriver Monitoring. No entanto, você pode desativar o monitoramento para recuperar alguns recursos.

Consulte a visão geral do monitoramento do GKE para ver mais informações sobre o Stackdriver Monitoring.

Se você usar o complemento de escalonamento automático de pod horizontal juntamente com métricas personalizadas do Stackdriver Monitoring, também é preciso desativar o escalonamento automático de pod horizontal no cluster antes de desativar totalmente o Stackdriver Monitoring.

Para desativar o Stackdriver Monitoring:

gcloud beta container clusters update [CLUSTER_NAME] --monitoring-service none
gcloud container clusters update [CLUSTER_NAME] --update-addons=HorizontalPodAutoscaling=DISABLED
kubectl --namespace=kube-system scale deployment metrics-server-v0.2.1 --replicas=0

Para ativar o Stackdriver Monitoring:

gcloud beta container clusters update [CLUSTER_NAME] --monitoring-service monitoring.googleapis.com
gcloud container clusters update [CLUSTER_NAME] --update-addons=HorizontalPodAutoscaling=ENABLED

Escalonamento automático do pod horizontal

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

Para desativar o HPA:

gcloud container clusters update [CLUSTER_NAME] --update-addons=HorizontalPodAutoscaling=DISABLED

Para ativar o HPA:

gcloud container clusters update [CLUSTER_NAME] --update-addons=HorizontalPodAutoscaling=ENABLED

Painel do Kubernetes

É possível desativar o complemento do painel do Kubernetes para economizar recursos de cluster. Há pouca ou nenhuma desvantagem em desativar o painel porque ele é semelhante aos painéis do GKE disponíveis no console do Google Cloud Platform.

Para desativar o painel:

gcloud container clusters update [CLUSTER_NAME] 
--update-addons=KubernetesDashboard=DISABLED

Para ativar o painel:

gcloud container clusters update [CLUSTER_NAME] 
--update-addons=KubernetesDashboard=ENABLED

DNS do Kube

O DNS do Kube programa uma Implantação de DNS e um serviço no cluster, e os pods no cluster usam o serviço de DNS do Kube para resolver nomes DNS para endereços IP para serviços, pods, nós, bem como endereços IP públicos. O DNS do Kube resolve nomes de domínio público como example.com e nomes de serviço como servicename.namespace.svc.cluster.local. Para mais informações sobre descoberta de serviço baseada em DNS, consulte DNS para serviços e pods.

Por padrão, várias réplicas do DNS do Kube são executadas para manter a alta disponibilidade. Se você não precisar de uma resolução de DNS altamente disponível, poderá economizar recursos de cluster reduzindo a um o número de réplicas de DNS do Kube. Se você não precisar de resolução de nomes DNS, desative totalmente o DNS do Kube.

Como reduzir a replicação de DNS do Kube

Se o cluster não exigir uma resolução de DNS altamente disponível, você poderá economizar recursos de cluster desativando o escalonamento automático horizontal do DNS do Kube e reduzindo a um o número de réplicas.

Para desativar o autoescalador kube-dns e reduzir o kube-dns a uma única réplica:

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

Para ativar o escalonamento automático:

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

Para um controle mais preciso do escalonamento automático, você pode ajustar os parâmetros de escalonamento automático

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 DNS do Kube:

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

Para ativar o DNS do Kube:

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

--replicas=1 é o número desejado de réplicas.

Para ativar o escalonamento automático de DNS do Kube:

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

Você pode 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

Você pode usar variáveis de ambiente de serviço 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.

Próximas etapas

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine