Reduce el uso de recursos del complemento en clústeres más pequeños

En esta página, se explica cómo puedes reducir los recursos que consumen los complementos del clúster. Usa estas técnicas en clústeres pequeños, como clústeres con tres o menos nodos o que utilicen tipos de máquinas con recursos limitados.

Descripción general

Además de tu carga de trabajo, los nodos del clúster ejecutan varios complementos que integran el nodo en el clúster principal y proporcionan otra funcionalidad. Por lo tanto, existe una diferencia entre los recursos totales de un nodo y los recursos disponibles para tu carga de trabajo. Consulta la documentación de arquitectura de clústeres para obtener más detalles.

Las configuraciones predeterminadas de estos complementos son adecuadas para los clústeres comunes, pero puedes optimizar el uso de recursos de los complementos en función de la configuración de tu clúster particular. También puedes inhabilitar algunos complementos que no son necesarios para tu caso práctico.

La optimización es muy útil para los clústeres con recursos de procesamiento limitados, por ejemplo, los clústeres con un solo nodo o muy pocos, o los que se ejecutan en tipos de máquinas de bajo costo. Puedes usar un clúster pequeño para probar GKE o experimentar con nuevas funciones. Los clústeres que se crean con tu primer clúster y la plantilla de clúster también pueden beneficiarse con la optimización.

Cómo configurar complementos

Puedes configurar cada complemento individual para reducir el impacto en los recursos del nodo.

Los complementos proporcionan visibilidad y depuración a tu clúster. Por ejemplo, si inhabilitas la supervisión en un clúster que ejecuta cargas de trabajo de producción, será más difícil depurar los problemas.

Stackdriver Logging

Stackdriver Logging recopila, procesa y almacena tu contenedor y los registros del sistema de forma automática.

Puedes inhabilitar Stackdriver Logging por completo o dejarlo habilitado, pero debes restringir el uso de recursos con la optimización del complemento Fluentd.

Visualiza los registros cuando Stackdriver Logging está inhabilitado

Cuando Stackdriver Logging está inhabilitado, podrás ver las entradas de registro recientes. Para ver los registros de un pod específico, sigue estos pasos:

kubectl logs -f [POD_NAME]

donde la opción -f transmite los registros.

Para ver los registros de todos los pods que coinciden con un selector, sigue estos pasos:

kubectl logs -l [SELECTOR]

donde SELECTOR es un selector de implementación, por ejemplo, “app=frontend”.

Optimiza Fluentd

Si decides no inhabilitar el registro como se describió con anterioridad, puedes limitar los recursos que usa el registro mediante la optimización Fluentd.

Fluentd recopila los registros de tus nodos y los envía a Stackdriver. El agente Fluentd se implementa en tu clúster con DaemonSet para que una instancia del agente se ejecute en cada nodo del clúster. Para las aplicaciones que escriben una gran cantidad de datos de registro, Fluentd puede requerir recursos adicionales.

Puedes optimizar la asignación de los recursos de Fluentd mediante la creación de una política de escalamiento específica para tus requisitos. Una política de escalamiento define los requisitos y límites de recursos del pod. Consulta Cómo administrar recursos de procesamiento para contenedores a fin de obtener información sobre cómo el programador de Kubernetes maneja los requisitos y límites de recursos. Para obtener más información sobre cómo los requisitos y los límites de los recursos afectan la calidad de servicio (QoS), consulta la sección sobre calidad de servicio de los recursos en Kubernetes.

Amplía la sección siguiente a fin de obtener instrucciones para medir el uso de los recursos de Fluentd y cómo escribir una política de escalamiento personalizada con estos valores.

Stackdriver Monitoring

Te recomendamos que uses Stackdriver Monitoring. Sin embargo, puedes inhabilitar la supervisión para recuperar algunos recursos.

Para obtener más información sobre Stackdriver Monitoring, consulta la descripción general de la supervisión de GKE.

Si usa el complemento del escalador automático de pod horizontal junto con las métricas personalizadas de Stackdriver Monitoring, debes inhabilitar el Escalador automático de pod horizontal (HPA) en el clúster antes de que puedas inhabilitar Stackdriver Monitoring por completo.

Stackdriver Kubernetes Monitoring

Para habilitar o inhabilitar Stackdriver Kubernetes Monitoring en tu clúster, usa la consola de Kubernetes. Haz clic en este vínculo para ir a la consola.

Ajuste de escala automático horizontal de pod

El Ajuste de escala automático horizontal de pod (HPA) escala las réplicas de las implementaciones en función de las métricas, como el uso de CPU o memoria. Si no necesitas un HPA y ya inhabilitaste Stackdriver Monitoring, también puedes inhabilitar HPA.

Para inhabilitar HPA, sigue estos pasos:

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

Para habilitar HPA:

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

Panel de Kubernetes

Puedes inhabilitar el complemento del panel de Kubernetes para conservar los recursos del clúster. Inhabilitar el panel no será un problema, ya que es redundante para los [paneles de GKE] [paneles de GKE] disponibles en Google Cloud Platform Console.

Para inhabilitar el panel, sigue estos pasos:

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

Para habilitar el panel:

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

Kube DNS

Kube DNS programa una implementación de DNS y un servicio en tu clúster, y los pods en tu clúster usan el servicio de Kube DNS a fin de resolver los nombres de DNS para direcciones IP de servicios, pods, nodos y direcciones IP públicas. Kube DNS resuelve los nombres de dominio público como example.com y los nombres de servicios como servicename.namespace.svc.cluster.local. Si deseas obtener más información sobre la detección de servicios basados en DNS, consulta DNS para servicios y pods.

De manera predeterminada, varias réplicas de Kube DNS se ejecutan para mantener una alta disponibilidad. Si no necesitas una resolución de DNS con alta disponibilidad, puedes conservar los recursos del clúster si reduces la cantidad de réplicas de Kube DNS a una. Si no necesitas la resolución de nombres de DNS, puedes inhabilitar Kube DNS por completo.

Cómo reducir la replicación de Kube DNS

Si tu clúster no necesita una resolución de DNS de alta disponibilidad, puedes conservar los recursos del clúster si desactivas el ajuste de escala automático horizontal de Kube DNS y reduces las réplicas a una.

Para desactivar el escalador automático kube-dns y reducir kube-dns a una sola réplica:

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

Para habilitar el ajuste de escala automático, sigue estos pasos:

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

Para obtener un control más preciso del ajuste de escala automático, puedes activar los parámetros de ajuste de escala automático.

Inhabilita Kube DNS

Puedes inhabilitar el DNS de Kube de forma completa. Kube DNS es necesario para las cargas de trabajo que resuelven el nombre DNS de cualquier servicio dependiente. Esto incluye los nombres de dominio público y los nombres de los servicios del clúster.

Para inhabilitar Kube DNS:

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

Para habilitar Kube DNS, sigue estos pasos:

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

donde --replicas=1 es la cantidad de réplicas deseadas.

Para habilitar el ajuste de escala automático de DNS, sigue estos pasos:

kubectl scale --replicas=1 deployment/kube-dns-autoscaler --namespace=kube-system
Consultas de DNS externo sin Kube DNS

Puedes configurar los pods para usar una resolución de nombre de dominio externo con el servicio de DNS que elijas. En el ejemplo siguiente, se muestra un pod que usa un DNS público de Google para las consultas de nombre 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
Detección de servicios sin Kube DNS

Puedes usar las variables de entorno de servicio como alternativa para la detección de servicios basados en DNS. Cuando se crea un pod, las variables de entorno de servicio se crean automáticamente para cada servicio en el mismo espacio de nombres que el pod. Esto es más restringido que Kube DNS porque las variables de entorno solo se crean para los servicios creados antes que el Pod.

Pasos siguientes

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

Documentación de Kubernetes Engine