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 la instancia principal del clúster 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. Puedes obtener más información sobre la arquitectura del clúster de GKE.

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 características nuevas. Los clústeres que se crean con la plantilla de clúster Tu primer clúster también pueden beneficiarse con la optimización.

Configura 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.

Cloud Logging

Cloud Logging recopila, procesa y almacena automáticamente tu contenedor y los registros del sistema.

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

Visualiza los registros cuando Cloud Logging está inhabilitado

Aunque Cloud Logging esté inhabilitado, puedes 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 registros de tus nodos y los envía al paquete de operaciones. 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 la forma en que 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 siguiente sección 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.

Cloud Monitoring

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

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

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

El paquete de operaciones Kubernetes Monitoring

Para habilitar o inhabilitar 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 HPA y ya has inhabilitado Cloud Monitoring, también puedes inhabilitar HPA.

Para inhabilitar HPA:

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. Hay pocos o ningún inconveniente en inhabilitar el panel, porque es redundante con los paneles de GKE disponibles en Google Cloud Console.

Para inhabilitar el panel:

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. Puedes obtener más información sobre DNS para servicios y pods.

De forma predeterminada, varias réplicas de Kube DNS se ejecutan para mantener una disponibilidad alta. 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:

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

A fin de 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 Kube DNS completamente. Kube DNS es necesario para las cargas de trabajo que resuelven el nombre de 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 tus pods para usar una resolución de nombre de dominio externo con el servicio de DNS que elijas. En el siguiente ejemplo, 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 el descubrimiento de servicios basados en DNS. Cuando se crea un pod, se crean de forma automática las variables de entorno de servicio 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 que se crearon antes que el pod.

Próximos pasos