Los clústeres de Anthos en equipos físicos incluyen varias opciones para el registro y la supervisión de clústeres, incluidos los servicios administrados basados en la nube, las herramientas de código abierto y la compatibilidad validada con soluciones comerciales de terceros. En esta página, se explican estas opciones y se proporciona orientación básica sobre cómo seleccionar la solución adecuada para el entorno.
Opciones para clústeres de Anthos en equipos físicos
Tienes varias opciones de registro y supervisión para tus clústeres de Anthos en equipos físicos:
- Cloud Logging y Cloud Monitoring, habilitados de forma predeterminada en los componentes del sistema de equipos físicos
- Prometheus y Grafana están disponibles en Cloud Marketplace.
- Opciones de configuración validadas con soluciones de terceros
Cloud Logging y Cloud Monitoring
Google Cloud's operations suite es la solución de observabilidad integrada para Google Cloud. Ofrece una solución de registro completamente administrada, recopilación de métricas, supervisión, paneles y alertas. Cloud Monitoring supervisa clústeres de Anthos alojados en clústeres de equipos físicos de manera similar a los clústeres de GKE basados en la nube.
Los agentes se pueden configurar para cambiar el permiso de los registros y la supervisión, así como el nivel de las métricas recopiladas:
- El permiso de registro y supervisión se puede establecer solo en los componentes del sistema (predeterminado) o en componentes y aplicaciones del sistema.
- El nivel de métricas recopiladas se puede configurar para un conjunto optimizado de métricas (predeterminado) o métricas completas.
Consulta Configura agentes de Stackdriver para clústeres de Anthos alojados en Bare Metal en este documento a fin de obtener más información.
Logging y Monitoring proporcionan una solución de observabilidad única, potente, fácil de configurar y basada en la nube. Recomendamos Logging y Monitoring cuando se ejecutan cargas de trabajo solo en clústeres de Anthos en equipos físicos, o cargas de trabajo de GKE y Anthos en equipos físicos. Para las aplicaciones con componentes que se ejecutan en clústeres de Anthos alojados en equipos físicos y en la infraestructura local tradicional, podrías considerar otras soluciones fin de obtener una vista de extremo a extremo de esas aplicaciones.
Para obtener detalles sobre la arquitectura, la configuración y los datos que se replican en el proyecto de Google Cloud de forma predeterminada, consulta Cómo funcionan los clústeres de Logging y Monitoring para Anthos en equipos físicos.
Para obtener más información sobre Logging, consulta la documentación de Cloud Logging.
Para obtener más información sobre Monitoring, consulta la documentación de Cloud Monitoring.
Para obtener información sobre cómo ver y usar las métricas de uso de los recursos de Cloud Monitoring desde los clústeres de Anthos alojados en Bare Metal a nivel de la flota, consulta Usa la descripción general de Anthos.
Prometheus y Grafana
Prometheus y Grafana son dos productos populares de supervisión de código abierto disponibles en Cloud Marketplace:
Prometheus recopila métricas de aplicaciones y sistemas.
Alertmanager maneja el envío de alertas con varios mecanismos de alerta diferentes.
Grafana es una herramienta de paneles.
Prometheus y Grafana se pueden habilitar en cada clúster de administrador y de usuario. Prometheus y Grafana se recomiendan para equipos de aplicaciones con experiencia previa en esos productos. Estos productos también se recomiendan para los equipos operativos que prefieren conservar las métricas de la aplicación dentro del clúster y a fin de solucionar los problemas cuando se pierde la conectividad de red.
Soluciones de terceros
Google trabajó con varios proveedores de soluciones de registro y supervisión de terceros para que sus productos funcionen bien con clústeres de Anthos alojados en equipos físicos. Entre estos, se incluyen Datadog, Elastic y Splunk. En el futuro, se agregarán más proveedores validados.
Las siguientes guías de solución están disponibles para usar soluciones de terceros con clústeres de Anthos en equipos físicos:
- Supervisa clústeres de Anthos alojados en equipos físicos con Elastic Stack
- Recopila registros sobre clústeres de Anthos alojados en equipos físicos con Splunk Connect
Cómo funcionan Logging y Monitoring en los clústeres de Anthos alojados en equipos físicos
Cloud Logging y Cloud Monitoring se instalan y se activan en cada clúster cuando creas un nuevo clúster de administrador o de usuario.
Los agentes de Stackdriver incluyen varios componentes en cada clúster:
Operador de Stackdriver (
stackdriver-operator-*
): Administra el ciclo de vida de todos los demás agentes de Stackdriver implementados en el clúster.Recurso personalizado de Stackdriver. Es un recurso que se crea automáticamente como parte de los clústeres de Anthos en el proceso de instalación de equipos físicos.
Agente de métricas de GKE (
gke-metrics-agent-*
). Un DaemonSet basado en el recopilador de OpenTelemetry que realiza scraping de métricas de cada nodo en Cloud Monitoring. También se incluyen un DaemonSetnode-exporter
y un Deploymentkube-state-metrics
para proporcionar más métricas sobre el clúster.Servidor de reenvío de registros de Stackdriver (
stackdriver-log-forwarder-*
). Un DaemonSet de Fluent Bit que reenvía los registros de cada máquina a Cloud Logging. El servidor de reenvío almacena en búfer las entradas de registro en el nodo de forma local y vuelve a enviarlas durante un máximo de 4 horas. Si el búfer se llena o si el servidor de reenvío no puede llegar a la API de Cloud Logging durante más de 4 horas, se descartan los registros.Agente de metadatos de Anthos (
stackdriver-metadata-agent-
). Una implementación que envía metadatos de los recursos de Kubernetes, como Pods, implementaciones o nodos, a la API de Config Monitoring para API de operaciones. Estos datos se usan para enriquecer las consultas de métricas, ya que te permite realizar consultas por nombre de implementación, de nodo o incluso de servicio de Kubernetes.
Puedes ver los agentes que instaló Stackdriver mediante la ejecución del siguiente comando:
kubectl -n kube-system get pods -l "managed-by=stackdriver"
El resultado de este comando es similar al siguiente:
kube-system gke-metrics-agent-4th8r 1/1 Running 1 (40h ago) 40h kube-system gke-metrics-agent-8lt4s 1/1 Running 1 (40h ago) 40h kube-system gke-metrics-agent-dhxld 1/1 Running 1 (40h ago) 40h kube-system gke-metrics-agent-lbkl2 1/1 Running 1 (40h ago) 40h kube-system gke-metrics-agent-pblfk 1/1 Running 1 (40h ago) 40h kube-system gke-metrics-agent-qfwft 1/1 Running 1 (40h ago) 40h kube-system kube-state-metrics-9948b86dd-6chhh 1/1 Running 1 (40h ago) 40h kube-system node-exporter-5s4pg 1/1 Running 1 (40h ago) 40h kube-system node-exporter-d9gwv 1/1 Running 2 (40h ago) 40h kube-system node-exporter-fhbql 1/1 Running 1 (40h ago) 40h kube-system node-exporter-gzf8t 1/1 Running 1 (40h ago) 40h kube-system node-exporter-tsrpp 1/1 Running 1 (40h ago) 40h kube-system node-exporter-xzww7 1/1 Running 1 (40h ago) 40h kube-system stackdriver-log-forwarder-8lwxh 1/1 Running 1 (40h ago) 40h kube-system stackdriver-log-forwarder-f7cgf 1/1 Running 2 (40h ago) 40h kube-system stackdriver-log-forwarder-fl5gf 1/1 Running 1 (40h ago) 40h kube-system stackdriver-log-forwarder-q5lq8 1/1 Running 2 (40h ago) 40h kube-system stackdriver-log-forwarder-www4b 1/1 Running 1 (40h ago) 40h kube-system stackdriver-log-forwarder-xqgjc 1/1 Running 1 (40h ago) 40h kube-system stackdriver-metadata-agent-cluster-level-5bb5b6d6bc-z9rx7 1/1 Running 1 (40h ago) 40h
Métricas de Cloud Monitoring
Para obtener una lista de métricas recopiladas por Cloud Monitoring, consulta Visualiza clústeres de Anthos en métricas de equipos físicos.
Configura agentes de Stackdriver para clústeres de Anthos alojados en equipos físicos
Los agentes de Stackdriver instalados en los clústeres de Anthos en equipos físicos recopilan datos sobre los componentes del sistema para mantener y solucionar problemas con los clústeres. En las siguientes secciones, se describen la configuración de Stackdriver y los modos operativos.
Solo componentes del sistema (modo predeterminado)
Después de la instalación, los agentes de Stackdriver se configuran de forma predeterminada para recopilar registros y métricas, incluidos los detalles de rendimiento (por ejemplo, el uso de CPU y memoria) y los metadatos similares, para los componentes del sistema que proporciona Google. Estas incluyen todas las cargas de trabajo del clúster de administrador y, para los clústeres de usuario, las cargas de trabajo de los espacios de nombres kube-system, gke-system, gke-connect, istio-system y config-management-system.
Componentes y aplicaciones del sistema
Para habilitar el registro y la supervisión de la aplicación sobre el modo predeterminado, sigue los pasos que se indican en Habilita el registro y la supervisión de la aplicación.
Métricas optimizadas (métricas predeterminadas)
De forma predeterminada, las implementaciones kube-state-metrics
que se ejecutan en el clúster recopilan y, luego, informan un conjunto optimizado de métricas de kube para Google Cloud's operations suite (antes conocido como Stackdriver).
Se necesitan menos recursos para recopilar este conjunto optimizado de métricas, lo que mejora el rendimiento general y la escalabilidad.
Para inhabilitar las métricas optimizadas (no recomendado), anula la configuración predeterminada en tu recurso personalizado de Stackdriver.
Configura los recursos del componente de Stackdriver
Cuando creas un clúster, los clústeres de Anthos alojados en Bare Metal crean de forma automática un recurso personalizado de Stackdriver. Puedes editar la especificación en el recurso personalizado a fin de anular los valores predeterminados para las solicitudes de CPU y memoria y los límites de un componente de Stackdriver, y puedes anular por separado la configuración de métricas optimizada predeterminada.
Anula las solicitudes y los límites predeterminados de CPU y memoria para un componente de Stackdriver
Los clústeres con una alta densidad de Pods generan una sobrecarga de registro y supervisión más alta. En casos extremos, los componentes de Stackdriver pueden informarse cerca del límite de uso de CPU y memoria o, incluso, pueden estar sujetos a reinicios constantes debido a los límites de recursos. En este caso, a fin de anular los valores predeterminados para los requisitos de CPU y memoria de un componente de Stackdriver, sigue estos pasos:
Ejecuta el siguiente comando para abrir tu recurso personalizado de Stackdriver en un editor de línea de comandos:
kubectl -n kube-system edit stackdriver stackdriver
En el recurso personalizado de Stackdriver, agrega la sección
resourceAttrOverride
en el campospec
:resourceAttrOverride: DAEMONSET_OR_DEPLOYMENT_NAME/CONTAINER_NAME: LIMITS_OR_REQUESTS: RESOURCE: RESOURCE_QUANTITY
Ten en cuenta que la sección
resourceAttrOverride
anula todos los límites y solicitudes predeterminados existentes para el componente que especificas. Los siguientes componentes son compatibles conresourceAttrOverride
:gke-metrics-agent/gke-metrics-agent
stackdriver-log-forwarder/stackdriver-log-forwarder
stackdriver-metadata-agent-cluster-level/metadata-agent
node-exporter/node-exporter
kube-state-metrics/kube-state-metrics
Un archivo de ejemplo se ve de la siguiente manera:
apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: anthosDistribution: baremetal projectID: my-project clusterName: my-cluster clusterLocation: us-west-1a resourceAttrOverride: gke-metrics-agent/gke-metrics-agent: requests: cpu: 110m memory: 240Mi limits: cpu: 200m memory: 4.5Gi
Para guardar los cambios en el recurso personalizado de Stackdriver, guarda y sal del editor de línea de comandos.
Verifica el estado de tu Pod:
kubectl -n kube-system get pods -l "managed-by=stackdriver"
Una respuesta para un Pod en buen estado se ve de la siguiente manera:
gke-metrics-agent-4th8r 1/1 Running 1 40h
Verifica las especificaciones del pod del componente para asegurarte de que los recursos estén configurados correctamente.
kubectl -n kube-system describe pod POD_NAME
Reemplaza
POD_NAME
con el nombre del Pod que acabas de cambiar. Por ejemplo,gke-metrics-agent-4th8r
La respuesta es similar a la siguiente:
Name: gke-metrics-agent-4th8r Namespace: kube-system ... Containers: gke-metrics-agent: Limits: cpu: 200m memory: 4.5Gi Requests: cpu: 110m memory: 240Mi ...
Inhabilita las métricas optimizadas
De forma predeterminada, las implementaciones kube-state-metrics
que se ejecutan en el clúster recopilan y, luego, informan un conjunto optimizado de métricas de kube a Stackdriver. Si necesitas métricas adicionales, te recomendamos encontrar un reemplazo de la lista de métricas de clústeres de Anthos alojados en Bare Metal físicos.
Estos son algunos ejemplos de reemplazos que puedes usar:
Métrica inhabilitada | Reemplazos |
---|---|
kube_pod_start_time |
container/uptime |
kube_pod_container_resource_requests |
container/cpu/request_cores container/memory/request_bytes |
kube_pod_container_resource_limits |
container/cpu/limit_cores container/memory/limit_bytes |
Para inhabilitar la configuración predeterminada de las métricas optimizadas (no recomendado), haz lo siguiente:
Abre tu recurso personalizado de Stackdriver en un editor de línea de comandos:
kubectl -n kube-system edit stackdriver stackdriver
Configura el campo
optimizedMetrics
comofalse
:apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: anthosDistribution: baremetal projectID: my-project clusterName: my-cluster clusterLocation: us-west-1a optimizedMetrics: false
Guarda los cambios y cierra el editor de la línea de comandos.
Servidor de métricas
El Servidor de métricas es la fuente de las métricas de recursos del contenedor para varias canalizaciones con ajuste de escala automático. El servidor de métricas recupera las métricas de kubelets y las expone a través de la API de Metrics de Kubernetes. El HPA y el VPA usan estas métricas para determinar cuándo activar el ajuste de escala automático. El servidor de métricas se escala mediante el cambio de tamaño del complemento.
En casos extremos en los que la alta densidad del Pod crea demasiada sobrecarga de registro y supervisión, el servidor de métricas podría detenerse y reiniciarse debido a las limitaciones de recursos. En este caso, puedes asignar más recursos al servidor de métricas si editas el mapa de configuración metrics-server-config
en el espacio de nombres gke-managed-metrics-server y cambias el valor de cpuPerNode
y memoryPerNode
.
kubectl edit cm metrics-server-config -n gke-managed-metrics-server
El contenido de ejemplo del ConfigMap es el siguiente:
apiVersion: v1
data:
NannyConfiguration: |-
apiVersion: nannyconfig/v1alpha1
kind: NannyConfiguration
cpuPerNode: 3m
memoryPerNode: 20Mi
kind: ConfigMap
Después de actualizar el ConfigMap, vuelve a crear los Pods del servidor de métricas con el siguiente comando:
kubectl delete pod -l k8s-app=metrics-server -n gke-managed-metrics-server
Requisitos de configuración para Logging y Monitoring
Hay varios requisitos de configuración para habilitar Cloud Logging y Cloud Monitoring con clústeres de Anthos en equipos físicos. Estos pasos se incluyen en Configura una cuenta de servicio para usar con Logging y Monitoring en la página Habilita servicios de Google y en la siguiente lista:
- Se debe crear un lugar de trabajo de Cloud Monitoring dentro del proyecto de Google Cloud. Para ello, haz clic en Monitoring en la consola de Google Cloud y sigue el flujo de trabajo.
Debes habilitar las siguientes API de Stackdriver:
Debes asignar las siguientes funciones de IAM a la cuenta de servicio que usan los agentes de Stackdriver:
logging.logWriter
monitoring.metricWriter
stackdriver.resourceMetadata.writer
monitoring.dashboardEditor
opsconfigmonitoring.resourceMetadata.writer
Precios
No se aplican cargos por los registros y las métricas del sistema de Anthos.
En un clúster de Anthos alojado en un clúster de equipo físico, los registros y las métricas del sistema Anthos incluyen lo siguiente:
- Registros y métricas de todos los componentes en un clúster de administrador
- Registros y métricas de los componentes de estos espacios de nombres en un clúster de usuario:
kube-system
,gke-system
,gke-connect
,knative-serving
,istio-system
,monitoring-system
,config-management-system
,gatekeeper-system
,cnrm-system
Para obtener más información, consulta Precios de Google Cloud's operations suite.
Si quieres obtener información sobre los créditos de las métricas de Cloud Logging, comunícate con Ventas para obtener información sobre los precios.