Google Cloud Platform: uso de Config Sync para administrar Kubernetes

En este artículo, veremos cómo podemos administrar Kubernetes usando Config Sync. Para hacerlo, creemos un enunciado del problema y resolvamos el mismo.

Planteamiento del problema:

Ravi tiene un nuevo rol, Administrador de plataforma, y ​​tiene la tarea de garantizar que toda la infraestructura creada por todos los equipos de su empresa cumpla con los requisitos de gobierno. Veamos cómo Config Sync le facilita la vida. El equipo de Ravi está usando Kubernetes para el desarrollo. 

Solución:

Uno de los muchos beneficios de Kubernetes es su flujo de trabajo declarativo. Puede especificar cuántas instancias de una aplicación desea ejecutar y estar seguro de que Kubernetes garantizará ese estado por usted. Kubernetes

Pero a veces, el estado de los clústeres en ejecución puede perder la sincronización con lo que está en el papel cuando se aplican cambios no examinados a un clúster en vivo. Puede ser difícil saber qué está pasando realmente en su clúster. Cuando esto sucede, hacer que su clúster vuelva al último estado bueno conocido cuando algo sale mal se vuelve problemático. Es por eso que Ravi propone usar Config Sync para el flujo de trabajo de git ops. Config Sync permite a los operadores de clústeres administrar clústeres de Kubernetes mediante archivos llamados configs, almacenados en repositorios de git. 

Config Sync observa las actualizaciones de esos archivos y aplica los cambios a todos los clústeres relevantes automáticamente. Al bloquear el acceso directo a la API de Kubernetes, puede exigir que todos los cambios de configuración del clúster se propaguen mediante Config Sync. El siguiente comando se usa para lo mismo:

$ kubectl delete pod my_pod --ns namespace_1

 De esta manera, todos los cambios se revisan antes de enviarlos. Las herramientas declarativas como Config Sync significan que git se convertirá en la fuente de la verdad y reflejará con precisión lo que sucede en su clúster en vivo. Para un administrador de plataforma como Ravi, esto es una victoria. Y a medida que todo el sistema se vuelve más fácil de administrar, depurar y monitorear.

Veamos un ejemplo de cómo se puede usar Config Sync para mantener un repositorio sincronizado. En este ejemplo, creamos un clúster, nos convertimos en administradores del clúster e instalamos el comando normal y el operador Config Sync en el clúster en el que operamos. 

El primer paso es configurar el repositorio git que almacena las configuraciones desde las que se sincronizará nuestro clúster. Crearemos un archivo de configuración llamado config-management-yaml que se aplicará a todos nuestros clústeres. Este archivo le dice a Kubernetes en qué clústeres operar. Y proporciona información sobre el repositorio de git, incluida la rama y la carpeta desde la que sincronizar. Podemos configurar credenciales para acceder al repositorio privado según sea necesario. Se vería algo como a continuación:

$ cat config-management.yaml
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
    name: config-management
spec:
    clusterName: my_cluster
git:
syncRepo: https://github.com/GoogleCloud Platform/csp-config-management/ syncBranch: 1.0.0
secretType: none
policyDir: "geeksforgeeks.org'

Una vez que se aplica, puede ver que el operador Config Sync realmente crea pods en el espacio de nombres de Config Management. Estos son servicios que se ejecutan para asegurarse de que el estado deseado del clúster coincida con su estado real. 

Con Config Sync, puede emparejar el enfoque de git ops con git para almacenamiento y control de versiones. Y sus cambios se sincronizarán automáticamente con el clúster para garantizar un proceso de revisión coherente. Con este enfoque, todos los cambios de configuración siguen un proceso de revisión constante que se valida y aprueba antes de aplicarse, tal como lo haría el código. Esto hace que sea mucho más fácil para Ravi asegurarse de que todos los equipos sigan este proceso de manera consistente para que pueda escalar en toda la empresa.