Kubernetes Enterprise plugin
Este plugin permite obtener datos de un entorno de Kubernetes, generando agentes para cada uno de sus elementos y monitorizando estadísticas.
La información es obtenida vía web a través del API de Kubernetes, por lo que no es necesario instalar ningún software adicional para su funcionamiento, aunque para la obtención de los datos de uso de CPU y memoria de los contenedores y los nodos será necesario instalar el addon “metrics-server” en el entorno de Kubernetes.
- Introducción
- Matriz de compatibilidad
- Prerequisitos
- Asignación de permisos para el API
- Instalación de metrics-server
- Configuración
- Configuraciones de los agentes generados
- Configuraciones de transferencia de los ficheros XML
- Configuraciones adicionales
- Ejecución manual
- Módulos generados
Introducción
Este plugin permite obtener datos de un entorno de Kubernetes, generando agentes para cada uno de sus elementos y monitorizando estadísticas.
La información es obtenida vía web a través del API de Kubernetes, por lo que no es necesario instalar ningún software adicional para su funcionamiento, aunque para la obtención de los datos de uso de CPU y memoria de los contenedores y los nodos será necesario instalar el addon “metrics-server” en el entorno de Kubernetes.
Matriz de compatibilidad
Desarrollado contra:
- Kubernetes v1.14.3.
- Metrics-server 1.8+.
Prerequisitos
Se requiere conexión con el servicio Tentacle asociado a su servidor de Pandora FMS.
Se necesitarán las credenciales de acceso o un token de autenticación al API de Kubernetes de un usuario con permisos suficientes para consultar el API.
Opcionalmente, si se quieren obtener los datos de uso de CPU y memoria de contenedores y nodos se debe instalar el addon “metrics-server” en el entorno de Kubernetes.
Asignación de permisos para el API
A continuación se describen los pasos a seguir para crear un usuario con los permisos suficientes para obtener los datos de la monitorización.
- Creación de un “Cluster role” de lectura llamado “api-read-only”: Se creará un rol que conceda los permisos “get”, “list” y “watch” de todos los recursos de Kubernetes.
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
labels:
name: api-read-only
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- get
- list
- watch
- nonResourceURLs:
- '*'
verbs:
- get
- list
- watch
EOF
2. Creación de un “Cluster role binding” llamado “bind-api-read-only”: Se vinculará el rol creado anteriormente a una “service account” ya existente.
kubectl create clusterrolebinding bind-api-read-only \
--clusterrole=api-read-only \
--serviceaccount=namespace:user
Instalación de metrics-server
Para instalar el addon de “metrics-server”, será necesario descargarlo en el entorno de Kubernetes. Se puede obtener de su proyecto de github:
https://github.com/kubernetes-incubator/metrics-server
Una vez descargado solo se tiene que desplegar mediante el comando “kubectl”:
kubectl apply -f metrics-server/deploy/1.8+/
Se puede verificar que el despliegue se haya realizado con éxito si al lanzar el siguiente comando el estado de su API figura como “true”:
$ kubectl get apiservices | grep metrics-server
v1beta1.metrics.k8s.io kube-system/metrics-server True 1m
Si el despliegue tiene éxito, el API de “metrics-server” debería quedar accesible:
$ kubectl get --raw "/apis/metrics.k8s.io/v1beta1/"
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"metrics.k8s.io/v1beta1","resources":[{"name":"nodes","singularName":"","namespaced":false,"kind":"NodeMetrics","verbs":["get","list"]},{"name":"pods","singularName":"","namespaced":true,"kind":"PodMetrics","verbs":["get","list"]}]}
Además, pasados algunos segundos, se deberían poder obtener datos de uso de CPU y memoria de contenedores y nodos:
$ kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
kube 93m 4% 968Mi 56%
$ kubectl top pod
NAME CPU(cores) MEMORY(bytes)
pod1 0m 3Mi
pod2 0m 3Mi
pod3 0m 2Mi
pod4 0m 3Mi
pod5 0m 1Mi
Configuración
El fichero de configuración del plugin “pandora_kubernetes” se divide en bloques (todos los parámetros de configuración se indicarán sin comillas aunque tengan espacios en blanco):
Configuraciones de acceso al API
## API connection parameters
api_ip=192.168.80.145
api_port=8443
ssl=1
## HTTP bearer authentication parameters
auth_method=bearer
auth_token=auth-token
## HTTP basic authentication parameters
#auth_method=basic
#auth_user=user
#auth_pass=pass
api_ip
Dirección IP al servicio del API de Kubernetes.
port
Puerto a la escucha del servicio del API de Kubernetes.
ssl
Indica si la conexión al API es por HTTPS o no (1→ HTTPS, 0 → HTTP).
auth_method
Mecanismo de autenticación a utilizar. Los valores posibles son “bearer” y “basic”.
auth_token
Si “auth_method=bearer”, indica el token de autenticación del usuario con acceso al API. Este token se puede obtener siguiendo estos pasos:
1. Obtención del “secret name” del usuario:
$ kubectl get serviceaccounts user -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: "2019-06-19T10:11:48Z"
name: user
namespace: namespace
resourceVersion: "327"
selfLink: /api/v1/namespaces/namespace/serviceaccounts/user
uid: a60f3652-927a-11e9-b423-ae1361a56794
secrets:
- name: secret_name
2.Obtención del “token” del “secret name”:
$ kubectl describe secret secret_name
Name: secret-name
Namespace: namespace
Labels: <none>
Annotations: kubernetes.io/service-account.name: default
kubernetes.io/service-account.uid: a60f3652-927a-11e9-b423-ae1361a56794
Type: kubernetes.io/service-account-token
Data
====
token: auth-token
ca.crt: 1066 bytes
namespace: 7 bytes
auth_user
Si “auth_method=basic”, indica el usuario con acceso al API.
auth_pass
Si “auth_method=basic”, indica la contraseña del usuario con acceso al API.
Configuraciones de los agentes generados
## Agents parameters
interval=300
group=Servers
#prefix=KUBE-
interval
Intervalo de monitorización en segundos de los agentes generados. Permitirá definir cuándo pasarán los módulos a estado desconocido (por defecto, 2 veces el intervalo definido sin recibir datos).
group
Grupo al que se asignarán los agentes generados. Este grupo se tendrá en cuenta solo si el parámetro “autocreate_group” del servidor de Pandora no se ha definido correctamente.
prefix
Permite incluir una cadena de texto delante de los nombres de los agentes generados con el objetivo de identificar la ejecución de la que surgen (en el caso de tener varias ejecuciones del plugin configuradas).
Agent mode
## Agent mode for deployments and pods
## 1 = learning mode
## 0 = normal mode
## 2 = autodisable mode (default value)
agent_mode=2
normal mode
Para no deshabilitar los elementos "deployments" y "pods"
autodisable mode
Para deshabilitar los elementos "deployments" y "pods" (default)
Configuraciones de transferencia de los ficheros XML
## XML local transfer parameters
tmp=/tmp
transfer_mode=local
local_folder=/var/spool/pandora/data_in
## XML remote transfer parameters
#tmp=/tmp
#transfer_mode=tentacle
#tentacle_ip=127.0.0.1
#tentacle_port=41121
tmp
Directorio temporal en el que se generarán los ficheros XML de los agentes generados antes de su transferencia al servidor de Pandora FMS.
transfer_mode
Método de transferencia de ficheros que se utilizará. Si no se establece como “tentacle” se considerará que el método de transferencia es “local” (copiando los ficheros XML del directorio temporal a uno definido).
local_folder
Directorio al que se copiarán los ficheros XML si el método de transferencia no se establece como “tentacle”.
tentacle_ip
Dirección IP al que se enviarán los ficheros XML si el método de transferencia se establece como “tentacle”.
tentacle_port
Puerto al que conectarse al servidor de Tentacle indicado en el parámetro “tentacle_ip”.
tentacle_opts
Opciones adicionales para la transferencia de ficheros al servidor de Tentacle indicado.
Configuraciones adicionales
## Disable monitoring
get_healthz=1
get_namespaces=1
get_services=1
get_components=1
get_pods=1
get_nodes=1
get_deployments=1
get_metrics=1
## Additional Kubernetes metrics
# Example:
# Apiserver request latencies bucket=apiserver_request_latencies_bucket{component="apiserver",group="scheduling.k8s.io",resource="priorityclasses",scope="cluster",subresource="",verb="WATCH",version="v1",le="125000"}
## Extra parameters
#debug=0
get_healthz
Si se establece a “0” se dejarán de obtener los datos de monitorización del API “/healthz”. Su valor por defecto si no se especifica es “1” (habilitado).
get_namespaces
Si se establece a “0” se dejarán de obtener los datos de monitorización del API “/api/v1/namespaces”. Su valor por defecto si no se especifica es “1” (habilitado).
get_services
Si se establece a “0” se dejarán de obtener los datos de monitorización del API “/api/v1/services”. Su valor por defecto si no se especifica es “1” (habilitado).
get_components
Si se establece a “0” se dejarán de obtener los datos de monitorización del API “/api/v1/componentstatuses”. Su valor por defecto si no se especifica es “1” (habilitado).
get_pods
Si se establece a “0” se dejarán de obtener los datos de monitorización del API “/api/v1/pods” y del API “/apis/metrics.k8s.io/v1beta1/pods” (si se ha instalado el addon “metrics-server”). Su valor por defecto si no se especifica es “1” (habilitado).
get_nodes
Si se establece a “0” se dejarán de obtener los datos de monitorización del API “/api/v1/nodes” y del API “/apis/metrics.k8s.io/v1beta1/nodes” (si se ha instalado el addon “metrics-server”). Su valor por defecto si no se especifica es “1” (habilitado).
get_deployments
Si se establece a “0” se dejarán de obtener los datos de monitorización del API “/apis/extensions/v1beta1/deployments”. Su valor por defecto si no se especifica es “1” (habilitado).
discard_agents
Lista de agentes (separados por comas) que se quieran descartar de la monitorización del plugin. Deben ser los nombres de los agentes sin el prefijo indicado.
get_metrics
Si se establece a “0” se dejarán de obtener los datos de monitorización del API “/metrics”. Su valor por defecto si no se especifica es “1” (habilitado).
Estas métricas se deben especificar en el fichero de configuración con el formato:
nombre del modulo=metrica
Por ejemplo, si se indica en el fichero de configuración:
Apiserver request latencies bucket=apiserver_request_latencies_bucket{component="apiserver",group="scheduling.k8s.io",resource="priorityclasses",scope="cluster",subresource="",verb="WATCH",version="v1",le="125000"}
Se generará un módulo llamado:
Apiserver request latencies bucket
con el valor de la métrica:
apiserver_request_latencies_bucket{component="apiserver",group="scheduling.k8s.io",resource="priorityclasses",scope="cluster",subresource="",verb="WATCH",version="v1",le="125000"}
debug
Si se establece a “1” se mostrará información detallada de las acciones que se realicen durante la ejecución del plugin. Su valor por defecto si no se especifica es “0” (deshabilitado).
Ejecución manual
Para ejecutar el plugin configure el archivo de configuración “pandora_kubernetes.conf” según las instrucciones precedentes.
Ejecución del plugin:
./pandora_kubernetes.64 pandora_kubernetes.conf
Módulos generados
La ejecución de este plugin generará los siguientes agentes y módulos:
- Un agente llamado “Kubernetes”: Tendrá los datos de monitorización que no sean referente a contenedores y nodos. Contendrá los módulos:
- API status: Indica si el API es accesible por el plugin.
- Healthz: Indica si el API es accesible por el plugin.
- Healthz ping: Indica si el API es accesible por el plugin.
- Healthz log: Indica si el API es accesible por el plugin.
- Healthz etcd: Indica si el API es accesible por el plugin.
- Healthz poststarthook crd informer synced: Indica si el API es accesible por el plugin.
- Healthz poststarthook generic apiserver start informers: Indica si el API es accesible por el plugin.
- Healthz poststarthook start apiextensions controllers: Indica si el API es accesible por el plugin.
- Healthz poststarthook start apiextensions informers: Indica si el API es accesible por el plugin.
- Namespaces: Cantidad de “namespaces” en el entorno.
- Services: Cantidad de “services” en el entorno.
- Deployments: Cantidad de “deployments” en el entorno.
- Components: Cantidad de “components” en el entorno.
- Component <component>: Generará un módulo por cada “component” indicado su estado (healthy).
- <metric module name>: Generará un módulo por cada métrica indicada en el fichero de configuración (con los nombres indicados).
- Un agente para cada nodo: Su agente padre será el de “Kubernetes”. Contendrán los módulos:
- Pods: Cantidad de “pods” en el nodo.
- Pods (%): Porcentaje de ocupación de “pods” en el nodo.
- CPU (cores): Uso de CPU del nodo.
- CPU (%): Porcentaje de uso de CPU del nodo.
- Memory (bytes): Uso de memoria del nodo.
- Memory (%): Porcentaje de uso de memoria del nodo.
- <condition>: Generará un módulo por cada “condition” en el nodo indicando su estado.
- Un agente para cada “pod”: Su agente padre será el del nodo en el que se encuentre. Contendrán los módulos:
- Pod status: Indica el estado del “pod”. Estados posibles:
- 0 → Failed
- 1 → Running
- 2 → Succeeded
- 3 → Pending
- 4 → Unknown
- Containers: Cantidad de contenedores en el “pod”.
- Container <container> CPU (cores): Generará un módulo por cada “container” en el “pod” indicando el uso de CPU en el nodo.
- Container <container> CPU (%): Generará un módulo por cada “container” en el “pod” indicando el porcentaje de uso de CPU en el nodo.
- Container <container> memory (bytes): Generará un módulo por cada “container” en el “pod” indicando el uso de memoria en el nodo.
- Container <container> memory (%): Generará un módulo por cada “container” en el “pod” indicando el porcentaje de uso de CPU en el nodo.
- <condition>: Generará un módulo por cada “condition” en el “pod” indicando su estado.
- Un agente para cada despliegue: Su agente padre será el de “Kubernetes”. Contendrán los módulos:
- Replicas: Número total de “pods” objetivo del despliegue no terminados (Sus etiquetas coinciden con el selector).
- Updated replicas: Número total de “pods” objetivo del despliegue no terminados que tienen la plantilla de especificaciones deseada.
- Ready replicas: Número total de “pods” objetivo del despliegue preparados.
- Available replicas: Número total de “pods” objetivo del despliegue disponibles (preparados desde el al menos "minReadySeconds").
- Unavailable replicas: Número total de “pods” objetivo del despliegue no disponibles. Es el número total de “pods” que todavía son necesarios para que el despliegue tenga disponible una capacidad del 100%. Pueden ser “pods” que están iniciados pero aún no están disponibles o “pods” que aún no han sido creados.
- Available: Indica si el despliegue está disponible.
- Progressing: Indica si el despliegue está lanzando un nuevo “replica set”.