GitHub – anthem-ai / kubernetes-state-checker


Kubernetes State Checker, como sugiere su nombre, le ayuda a comprobar el estado de su clúster de Kubernetes.

Puede preguntar, con Kubernetes, no declara el estado que desea y Kubernetes hace que eso suceda, ¿por qué tengo que verificar el estado? Estaría en lo correcto, pero generalmente hay interacciones de un recurso de Kubernetes con otro o puede depender de un recurso externo o de terceros. Es posible que cualquiera de estos elementos no pueda alcanzar el estado deseado, lo que puede tener efectos posteriores o efectos en el medio ambiente. Incluso si Kubernetes puso el estado del clúster / aplicación en el estado que declaró, a veces lo que declaró podría ser incorrecto porque alguien cambió la configuración buscando hacer una solución que no se comunicó a las dependencias posteriores y que podría romper el entorno.

Con una arquitectura de microservicio, varios equipos pueden contribuir a un entorno de aplicación. Asegurar que todo se integre y funcione correctamente es a menudo un desafío. A menudo hay expertos en aplicaciones que saben cómo se integran todas estas aplicaciones entre sí y se supone que funcionan para su entorno y se confía en esta persona para depurar los problemas de integración. Esta es una tarea tediosa y depender de ciertas personas para depurar este tipo de problemas los convierte en un cuello de botella.

¿Cómo ayuda Kubernetes State Checker?

Aquí hay un ejemplo real que ha sido desinfectado y convertido en genérico. Tenemos un entorno con muchos microservicios. En este escenario, hablaremos de 2 de ellos. El microservicio 1 se configuró para escuchar en el puerto 5000 y el microservicio 2 se configuró para conectarse al microservicio 1 en el puerto 30001. Según la configuración, cada estado de las implementaciones llegó al estado deseado, pero cuando el microservicio 2 intentó conectarse al microservicio 1, eso la conexión falló.

Le dijimos el problema exacto, pero cuando esto ocurrió, no era evidente que los puertos estuvieran configurados incorrectamente. Lo primero que nos alertó de que este entorno ahora estaba roto fue una prueba e2e que falló. Sin embargo, el e2e prueba solo pruebas desde ciertos puntos de entrada al sistema y no puede decirnos por qué el sistema está roto. Esto llevó a los desarrolladores a mirar los registros de aplicaciones en los diversos servicios, ya que saben cómo fluye la llamada a través del sistema. A partir de los registros, los desarrolladores pudieron localizar el problema en algunos microservicios, pero no pudieron decir exactamente por qué se interrumpió la llamada. El siguiente paso fue incluir a la gente de infraestructura para que echara un vistazo. La gente de infraestructura tuvo que ponerse al día con lo que estaba sucediendo y con esa información comenzó a verificar varias cosas de Kubernetes. Después de una tediosa tarea de rastrear cómo la aplicación estaba configurada para lo que estaba tratando de comunicarse, se encontró que la configuración del puerto estaba desactivada y un lado de los números de puerto tendría que cambiar.

Con Kubernetes State Checker, podremos declarar estos estados sobre cómo se deben configurar los números de puerto y luego ejecutar una verificación para asegurarnos de que se encuentran en ese estado. Si no es así, como en este caso, le diría que este puerto en particular no está en el estado en el que dijo que lo quería.
Esto fue esencialmente un problema de integración entre Microservice 1 y Microservice 2. El microservicio 1 estaba escuchando en un puerto, pero el Microservice 2 pensó que debería conectarse al Microservice 1 en otro puerto. ¿Quién tiene razón? Este es un entendimiento entre los dos microservicios sobre cómo se conectarán entre sí, pero nada lo impone ni lo verifica. Kubernetes State Checker puede ser ese “control” o “aplicación”.

Desde el punto de vista de los desarrolladores, esto les brinda una herramienta para verificar las capas debajo de la aplicación para asegurarse de que todo en esas capas esté configurado según lo esperado.

Desde el punto de vista de una persona de DevOps / Infraestructura, esto les permite configurar un estado esperado y permitir que otros grupos lo verifiquen. También le da a este grupo una herramienta en la que pueden ejecutar para verificar el estado, lo que puede ayudarlos a eliminar lo que podría estar mal y ver otras áreas que esta herramienta no cubrió.

Casos de uso

¿Se ha configurado correctamente un entorno?

Si tuvo una serie de comprobaciones que representa un entorno de configuración correcta, entonces puede usar esas comprobaciones y ejecutarlas en otro entorno para asegurarse de que todo esté en su lugar. Si algo no está configurado correctamente, entonces kubernetes-state-checker generará lo que no es correcto.

Bucle de retroalimentación desde el desarrollo hasta la producción

A medida que el desarrollador está desarrollando la aplicación, esta persona generalmente sabe lo que necesita la aplicación para que funcione correctamente y probablemente haya encontrado algunos problemas al depurar esta aplicación. El desarrollador puede crear verificaciones muy similares a cómo pueden crear pruebas unitarias en áreas que se sabe que tienen fallas. Luego, otros equipos que administran otros entornos pueden utilizar estas comprobaciones para asegurarse de que sus entornos estén configurados correctamente.

Los cheques también pueden fluir desde el otro lado. Por lo general, en una organización más grande, es posible que los desarrolladores no sean los que se ocupen de los sistemas de producción. Puede que haya otro equipo para eso. A medida que ejecuta la (s) aplicación (es) en producción, normalmente verá otros problemas operativos que no son un problema en dev. Este equipo también puede emitir cheques para estos artículos para que estos problemas se detecten antes de que se conviertan en un problema. Con estas comprobaciones, los otros equipos, incluidos los desarrolladores, pueden ejecutarlo para asegurarse de que todo esté bien y de que se cumplan las suposiciones desde el desarrollo hasta la producción.

Uso de ejemplo

Verifique el puerto de servicio de Kubernetes

kubernetes-state-checker:
- type: doesServicePortExist
  name: Does microservice 1 have a kubernetes service with port 5000 exposed
  description: This checks if microservice 1 has a Kubernetes service with port 5000 exposed
  namespace: app
  # Input values for this specific check
  values:
    serviceName: microservice-1
    port: 5000

Verificar el medio ambiente en una vaina

kubernetes-state-checker:
- type: doesEnvarExistInDeployment
  name: Check that the microservice 2 deployments has the correct envar for microservice 1
  description: The microservice 2 uses the "MICROSERVICE_1_HOST_PORT" envar to find microservice 1.  This checks to make sure that this envar is there and set to the correct value.
  Namespace: app
  # Input values for this specific check
  values:
    deploymentName: microservice-2
    envarKey: MICROSERVICE_1_HOST_PORT
    envarValue: microservice-1:5000

Compruebe si un puerto está abierto

Tal vez incluso kube exec telnet / nc para probar la conexión

Discusiones abiertas

Una forma más dinámica de leer configuraciones

Durante una revisión por pares de este documento, se presentó una idea para ver si podemos leer las configuraciones de una manera más dinámica para que estas configuraciones no tengan que estar en más de un lugar. Tomando nuestro ejemplo de microservicio 1 y microservicio 2 de arriba. Los puertos y envars reales se definen en los archivos de valores de Helm de cada servicio. Luego, con esta prueba, una vez más tenemos que definir qué puertos se asignan a qué. Esto significa que la misma información está ahora en dos lugares. Cuando alguien quiere actualizar el puerto para el microservicio 1, tendría que actualizarlo en los valores de Helm del microservicio 1 y luego ir al yaml de configuración de verificación de kubernetes-state-checker y cambiar el valor allí también. Esto hace que la cantidad de trabajo sea repetitiva y tediosa.

Nos gustaría una forma en la que podamos decirle a este yaml de configuración de verificación de kubernetes-state-checker que aquí está el puerto en el que está escuchando microservice-1 y aquí está el archivo y aquí está el envar que microservice-2 está usando para llegar a ese puerto . Estos valores deberían ser los mismos.

Soluciones propuestas:

Ser capaz de leer desde cualquier archivo yaml con un kubernetes-state-checker sección Podemos apuntarlo a cualquier archivo yaml y encontrará y solo el kubernetes-state-checker sección.

fullnameOverride: &name "hos-core-authentication"

image:
  repository: 1234.dkr.ecr.us-west-2.amazonaws.com/hos/hos-core-authentication
  pullPolicy: Always
  tag: &tag dev

service:
  port: 20004
  targetPort: 20004

some-other-yaml:
  foo: bar

kubernetes-state-checker:
- type: doesServicePortExist
  name: Does hos-core-authentication have a kubernetes service with port 20004 exposed
  description: This checks if hos-core-authentication has a Kubernetes service with port 20004 exposed
  namespace: app
  # Input values for this specific check
  values:
    serviceName: hos-core-authentication
    port: 20004

Ignorará todas las secciones y solo usará la información en el kubernetes-state-checker sección.

Esto tiene los archivos de configuración que le ayudan a mostrar el entorno que necesita para desarrollarlo localmente a través de un contenedor Docker.

Esto se basa en este ejemplo: https://github.com/microsoft/vscode-remote-try-go

Tendrás que instalar el Visual Studio Code Remote - Containers extension: https://code.visualstudio.com/docs/remote/containers#_getting-started

Una vez que instale esto y reinicie VScode en este repositorio, le preguntará si desea abrirlo en un contenedor. La primera vez que haga esto, tomará algún tiempo ya que está construyendo el contenedor basado en el Dockerfile en el .devcontainer directorio. Después de que construya el contenedor, abrirá este proyecto dentro de este contenedor y podrá codificar como de costumbre.

Instale las dependencias de go:

go get gopkg.in/yaml.v2
go get k8s.io/apimachinery/pkg/api/errors
go get k8s.io/apimachinery/pkg/apis/meta/v1
go get k8s.io/client-go/kubernetes
go get k8s.io/client-go/tools/clientcmd
go get k8s.io/client-go/util/homedir
go get github.com/evanphx/json-patch
go get k8s.io/kube-openapi/pkg/util/proto
go get github.com/olekukonko/tablewriter

Establecer ruta de acceso

export GOPATH=$GOPATH:$PWD

Ejecuta todas las pruebas unitarias

go test ./...

Kubeconfig

los .devcontainer/devcontainer.json archivo especifica un montaje local de su $HOME/.kube/config en el $HOME/.kube/config dentro del contenedor.



Source link

Loading spinner

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

A %d blogueros les gusta esto: