Espiando a tu Kubernetes con Kubewatch

Share on twitter
Share on linkedin

Desde la Práctica Cloud queremos impulsar la adopción de la nube como forma de trabajo en el mundo de IT. Para ayudar en esta tarea, vamos a publicar multitud de artículos de buenas prácticas y casos de uso, otros hablarán aquellos servicios clave dentro de la nube.

En esta ocasión hablaremos de Kubewatch.

¿Qué es Kubewath?

Kubewatch es una utilidad desarrollada por Bitnami Labs que permite el envío de notificaciones a distintos sistemas de comunicación.

Los webhooks soportados son:

  • Slack
  • Hipchat
  • Mattermost
  • Flock
  • Webhook
  • Smtp

Integración de kubewatch con Slack

Las imágenes disponibles están publicadas en el GitHub de bitnami/kubewatch

Si queréis, podéis descargaros la última versión para probarla en vuestro entorno local:

$ docker pull bitnami/kubewatch 

Una vez dentro del contenedor podéis jugar con las opciones:

$ kubewatch -h

Kubewatch: A watcher for Kubernetes

kubewatch is a Kubernetes watcher that publishes notifications
to Slack/hipchat/mattermost/flock channels. It watches the cluster
for resource changes and notifies them through webhooks.

supported webhooks:
 - slack
 - hipchat
 - mattermost
 - flock
 - webhook
 - smtp

Usage:
  kubewatch [flags]
  kubewatch [command]

Available Commands:
  config      modify kubewatch configuration
  resource    manage resources to be watched
  version     print version

Flags:
  -h, --help   help for kubewatch

Use "kubewatch [command] --help" for more information about a command. 

¿De qué tipos de recursos podemos obtener notificaciones?

¿Cuándo recibiremos una notificación?

En cuanto haya una acción sobre algún objeto de kubernetes, así como creación, destrucción o actualización.

Configuración

En primer lugar, crearemos un canal de slack y le asociaremos un webhook. Para ello, iremos a la sección de Apps de Slack, buscaremos “Incoming WebHooks” y pulsaremos “Add to Slack”:

En el caso de no tener aún un canal creado para este propósito daremos de alta uno nuevo:

En este ejemplo, el canal a crear se llamará “k8s-notifications”. Posteriormente debemos configurar el webhook, yendo para ello al panel de “Incoming WebHooks” y añadiendo una nueva configuración donde tendremos que seleccionar el nombre del canal al que queremos enviar notificaciones. Una vez seleccionado, la configuración nos devolverá una «Webhook URL» que será la que utilicemos para configurar Kubewatch. Opcionalmente, tenemos la posibilidad de seleccionar el icono (opción «Customize Icon») con el que visualizaremos la recepción de eventos y el nombre con el que llegarán (opción “Customize Name”).

En este punto ya estamos listos para configurar los recursos de kubernetes. En el GitHub de Kubewatch tenemos algunos ejemplos de manifiestos y también la opción de instalación por Helm. Sin embargo, aquí construiremos los nuestros propios.

En primer lugar, crearemos un fichero “kubewatch-configmap.yml” con el ConfigMap que servirá para configurar el contenedor de kubewatch:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubewatch
data:
  .kubewatch.yaml: |
    handler:
      webhook:
        url: https://hooks.slack.com/services/<your_webhook>
    resource:
      deployment: true
      replicationcontroller: true
      replicaset: false
      daemonset: true
      services: true
      pod: false
      job: false
      secret: true
      configmap: true
      persistentvolume: true
      namespace: false 

Simplemente tendremos que activar con “true” o desactivar con «false» los tipos de recursos sobre los que queremos recibir notificaciones. Asimismo, establecemos la url del Incomming Webhook que dimos de alta previamente.

Ahora, para que nuestro contenedor tenga acceso a los recursos de kubernetes a través de su api vamos a dar de alta el fichero “kubewatch-service-account.yml” con un Service Account, un Cluster Role y un Cluster Role Binding:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubewatch
rules:
- apiGroups: ["*"]
  resources: ["pods", "pods/exec", "replicationcontrollers", "namespaces", "deployments", "deployments/scale", "services", "daemonsets", "secrets", "replicasets", "persistentvolumes"]
  verbs: ["get", "watch", "list"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kubewatch
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: kubewatch
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kubewatch
subjects:
  - kind: ServiceAccount
    name: kubewatch
    namespace: default 

Por último, crearemos un fichero “kubewatch.yml” para desplegar la aplicación:

apiVersion: v1
kind: Pod
metadata:
  name: kubewatch
  namespace: default
spec:
  serviceAccountName: kubewatch
  containers:
  - image: bitnami/kubewatch:0.0.4
    imagePullPolicy: Always
    name: kubewatch
    envFrom:
      - configMapRef:
          name: kubewatch
    volumeMounts:
    - name: config-volume
      mountPath: /opt/bitnami/kubewatch/.kubewatch.yaml
      subPath: .kubewatch.yaml
  - image: bitnami/kubectl:1.16.3
    args:
      - proxy
      - "-p"
      - "8080"
    name: proxy
    imagePullPolicy: Always
  restartPolicy: Always
  volumes:
  - name: config-volume
    configMap:
      name: kubewatch
      defaultMode: 0755 

Vemos que el valor de la clave “mountPath” será la ruta del fichero donde se escribirá la configuración de nuestro ConfigMap dentro del contenedor (/opt/bitnami/kubewatch/.kubewatch.yaml). Podemos ampliar aquí la información sobre cómo montar configuraciones en kubernetes. En este ejemplo, vemos que nuestro despliegue del aplicativo será a través de un único pod. Evidentemente, en un sistema productivo tendríamos que definir un Deployment con el número de réplicas que consideremos convenientes para tenerlo así siempre activo, aun en caso de pérdida del pod.

Una vez listos los manifiestos vamos a aplicarlos a nuestro clúster:

$ kubectl apply  -f kubewatch-configmap.yml -f kubewatch-service-account.yml -f kubewatch.yml 

En unos pocos segundos tendremos listo el servicio:

$ kubectl get pods |grep -w kubewatch

kubewatch                                  2/2     Running     0          1m 

El pod de kubewatch tiene asociado dos contenedores: kubewatch y kube-proxy, este último para atacar a la API.

$   kubectl get pod kubewatch  -o jsonpath='{.spec.containers[*].name}'

kubewatch proxy 

Verificamos a través de los logs que ambos contenedores han levantado correctamente y sin mensajes de error:

$ kubectl logs kubewatch kubewatch

==> Config file exists...
level=info msg="Starting kubewatch controller" pkg=kubewatch-daemonset
level=info msg="Starting kubewatch controller" pkg=kubewatch-service
level=info msg="Starting kubewatch controller" pkg="kubewatch-replication controller"
level=info msg="Starting kubewatch controller" pkg="kubewatch-persistent volume"
level=info msg="Starting kubewatch controller" pkg=kubewatch-secret
level=info msg="Starting kubewatch controller" pkg=kubewatch-deployment
level=info msg="Starting kubewatch controller" pkg=kubewatch-namespace
... 
$ kubectl logs kubewatch proxy

Starting to serve on 127.0.0.1:8080 

Podríamos igualmente acceder al contenedor de kubewatch para probar la cli, ver la configuración, etcétera:

$  kubectl exec -it kubewatch -c kubewatch /bin/bash 

¡Ya tenemos listo nuestro notificador de eventos!

Ahora toca probar. Utilizaremos, por ejemplo, la creación de un deployment para testear el correcto funcionamiento:

$ kubectl create deployment nginx-testing --image=nginx
$ kubectl logs -f  kubewatch kubewatch

level=info msg="Processing update to deployment: default/nginx-testing" pkg=kubewatch-deployment 

Los logs ya nos avisan que se ha detectado el nuevo evento, así que vamos a nuestro canal de slack para verificarlo:

¡El evento ha sido notificado correctamente!

Ya podemos eliminar el deployment de prueba:

$ kubectl delete deploy nginx-testing 

Conclusiones

Evidentemente, Kubewatch no suple a los sistemas básicos de alerta y monitorización que todo orquestador productivo debe mantener, pero nos proporciona una manera fácil y eficaz de ampliar nuestro control sobre la creación y modificación de los recursos en kubernetes. En este caso de ejemplo, hemos realizado una configuración de kubewatch transversal a todo el clúster, “espiando” todo tipo de eventos, algunos quizá inservibles si mantenemos una plataforma como servicio, pues nos enteraríamos de cada uno de los pods creados, eliminados o actualizados por cada equipo de desarrollo en su propio namespace, lo cual es usual, legítimo y no aporta valor. Quizá sea más conveniente filtrar por los namespaces sobre cual queremos recibir notificaciones, como por ejemplo de kube-system, que es donde albergaremos generalmente nuestros servicios administrativos y donde solo los administradores deben tener acceso. En ese caso, simplemente tendremos que especificar el namespace en nuestro ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubewatch
data:
  .kubewatch.yaml: |
    namespace: "kube-system"
    handler:
      webhook:
        url: https://hooks.slack.com/services/<your_webhook>
    resource:
      deployment: true
      replicationcontroller: true
      replicaset: false 

Otra utilidad interesante puede ser “escuchar” a nuestro clúster tras un ajuste signicativo de la configuración como, por ejemplo, de nuestra estrategia de autoescalado, herramientas de integración, etcétera, pues siempre nos notificará los scale up y scale down, pudiendo ser interesante sobre todo en un momento inicial. En definitiva, Kubewatch amplía el control sobre los clústeres, siendo nosotros quienes decidamos el alcance que le damos. En sucesivos artículos veremos cómo gestionar los logs y las métricas de forma productiva.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
Share on twitter
Share on linkedin