Lanzamientos seguros con Config Management

En este documento, se muestra a los operadores de clústeres y a los administradores de la plataforma cómo lanzar de forma segura los cambios en varios entornos con la Administración de configuración. Config Management puede ayudarte a evitar errores que afecten a todos tus entornos de forma simultánea.

Config Management te permite administrar clústeres individuales, clústeres de multiusuario y parámetros de configuración de Kubernetes de varios clústeres mediante archivos almacenados en un repositorio de Git. Config Management combina tres tecnologías: el Sincronizador de configuración, el Controlador de políticas y Config Connector. El sincronizador de configuración busca actualizaciones para todos los archivos en el repositorio de Git y aplica los cambios a todos los clústeres relevantes de forma automática. El controlador de políticas administra y aplica políticas a los objetos en tus clústeres. Config Connector usa recursos personalizados de Google Kubernetes Engine (GKE) para administrar los recursos en la nube.

Los parámetros de configuración del sincronizador de configuración pueden representar varios elementos, incluidos los siguientes:

Config Management es ideal para implementar configuraciones, políticas y cargas de trabajo necesarias para ejecutar la plataforma que compilas sobre GKE Enterprise, por ejemplo, agentes de seguridad, agentes de supervisión y administradores de certificados.

Si bien puedes implementar aplicaciones orientadas al usuario con Config Management, no recomendamos vincular el ciclo de vida de la versión al ciclo de vida de la versión de las cargas de trabajo administrativas mencionadas antes. En cambio, te recomendamos que uses una herramienta dedicada a la implementación de aplicaciones, como una herramienta de implementación continua, para que los equipos de aplicaciones puedan estar a cargo de sus programas de lanzamientos.

Config Management es un producto potente que puede administrar muchos elementos, por lo que necesitas barreras de seguridad para evitar errores que tengan un impacto importante. En este documento, se describen varios métodos para crear barreras de seguridad. En la primera sección, se abordan los lanzamientos por etapas; la segunda sección se enfoca en pruebas y validaciones; y en la tercera sección, se explica cómo usar el controlador de políticas para crear barreras de seguridad. En la cuarta sección, se muestra cómo supervisar las implementaciones de Config Management.

Puedes usar la mayoría de los métodos que se analizan en este documento, incluso si solo usas el Sincronizador de configuración y no el producto completo de Config Management. Si no usas el producto completo de Config Management, pero aún deseas implementar los métodos que involucran el controlador de políticas, puedes hacerlo de forma correcta mediante Gatekeeper. Las excepciones a esta regla son métodos que se basan en la página Config Management de la consola de Google Cloud, como actualizar la configuración de Config Management en la consola de Google Cloud. También puedes usar varios de los métodos descritos en este documento al mismo tiempo. En la siguiente sección, en una tabla se indica qué métodos son compatibles para su uso simultáneo.

Implementa lanzamientos en etapas con Config Management

En un entorno de varios clústeres, que es una situación común para los usuarios de GKE Enterprise, no recomendamos aplicar un cambio de configuración en todos los clústeres al mismo tiempo. Un lanzamiento por etapas, clúster por clúster, o incluso espacio de nombres por espacio de nombres (si usas espacios de nombres como límite entre aplicaciones), es mucho más seguro porque reduce el radio de efecto de cualquier error.

A continuación, se muestran varias formas de implementar lanzamientos en etapas con Config Management:

  • Usa las confirmaciones o las etiquetas de Git para aplicar los cambios que desees a los clústeres de forma manual.
  • Usa las ramas de Git para aplicar de forma automática los cambios cuando se combinan. Puedes usar diferentes ramas para distintos grupos de clústeres.
  • Usa objetos ClusterSelector y NamespaceSelector para aplicar cambios de forma selectiva a subgrupos de clústeres o espacios de nombres.

Todos los métodos para los lanzamientos por etapas tienen ventajas y desventajas. En la siguiente tabla, se muestra cuáles de estos métodos puedes usar al mismo tiempo.

¿X es compatible con Y? Confirmaciones o etiquetas de Git Ramas de Git Selectores de clústeres Selectores de espacios de nombres
Confirmaciones o etiquetas de Git No compatible Compatible Compatible
Ramas de Git No compatible Compatible Compatible
Selectores de clústeres Compatible Compatible Compatible
Selectores de espacios de nombres Compatible Compatible Compatible

El siguiente árbol de decisión te ayuda a decidir cuándo usar uno de los métodos de lanzamiento por etapas.

Árbol de decisión para los métodos de lanzamiento.

Usa confirmaciones o etiquetas de Git

En comparación con los otros métodos de lanzamiento por etapas, el uso de confirmaciones o etiquetas de Git proporciona mayor control y es más seguro. Puedes usar la página Config Management de la consola para actualizar varios clústeres al mismo tiempo. Usa este método si deseas aplicar cambios a tus clústeres uno por uno y controlar de forma exacta cuándo sucede.

En este método, “fijas” cada clúster a una versión específica (ya sea una confirmación o una etiqueta) de tu repositorio de Config Management. Este método es similar a usar la confirmación de Git como una etiqueta de imagen de contenedor. Para implementar este método, especifica la confirmación, la etiqueta o el hash en el campo spec.git.revision del recurso personalizado RootSync o RepoSync.

Si administras tus recursos personalizados RootSync o RepoSync con una herramienta como kustomize, puedes reducir la cantidad de trabajo manual necesario para lanzar cambios. Con esta herramienta, solo necesitas cambiar el parámetro revision en un lugar y, luego, aplicar selectivamente el nuevo recurso personalizado RootSync o RepoSync a tus clústeres en el orden y al ritmo que elijas.

Además, si usas Config Management (y no el Sincronizador de configuración), tienes acceso a la página Config Management en la consola de Google Cloud. En esta página, se permite que actualices el parámetro revision para varios clústeres que pertenecen a la misma flota al mismo tiempo. Si tienes un sistema automatizado para actualizar la configuración de Config Management, te recomendamos que no uses la consola para cambiar esta configuración.

Por ejemplo, la siguiente definición de RootSync configura Config Management para usar la etiqueta 1.2.3:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: git@example.com:anthos/config-management.git
    revision: 1.2.3
    auth: ssh

Si aplicas esta configuración a tu clúster, Config Management usará la etiqueta 1.2.3 del repositorio example.com:anthos/config-management.git.

Para actualizar un clúster, cambia el campo spec.git.revision al valor nuevo del clúster. Esto te permite definir qué clústeres se actualizan y cuándo. Si necesitas revertir un cambio, cambia el campo spec.git.revision a su valor anterior.

En el siguiente diagrama, se ilustra el proceso de lanzamiento para este método. Primero, confirma los cambios en el repositorio de Config Management y, luego, actualiza las definiciones de RootSync en todos los clústeres:

Proceso de lanzamiento para confirmaciones y etiquetas de Git.

Recomendamos las siguientes acciones:

  • Usa los ID de confirmación de Git en lugar de las etiquetas. Debido a la forma en que funciona Git, tienes la garantía de que nunca cambiarán. Por ejemplo, git push --force no puede cambiar la confirmación que usa Config Management. Este enfoque es útil con fines de auditoría y para hacer un seguimiento de la confirmación que usas en los registros. Además, a diferencia de las etiquetas, no existe un paso adicional para confirmar los ID.
  • Si prefieres usar etiquetas de Git en lugar de ID de confirmación de Git y usas GitLab, protege las etiquetas para evitar que se muevan o borren. Las otras soluciones principales de Git no tienen esta función.
  • Si deseas actualizar varios clústeres al mismo tiempo, puedes hacerlo en la página de la consola de Config Management. Para que puedas actualizar varios clústeres a la vez, deben ser parte de la misma flota (y estar en el mismo proyecto).

Usa ramas de Git

Si deseas que los cambios se apliquen a los clústeres en cuanto se combinen en tu repositorio de Git, configura Config Management para usar ramas de Git en lugar de confirmaciones o etiquetas. En este método, puedes crear varias ramas de larga duración en tu repositorio de Git y configurar Config Management en diferentes clústeres para leer su configuración desde diferentes ramas.

Por ejemplo, un patrón simple tiene dos ramas:

  • Una rama staging para clústeres que no son de producción
  • Una rama master para clústeres de producción

Para los clústeres que no son de producción, crea el objeto RootSync o RepoSync con el campo spec.git.branch configurado como staging. Para los clústeres de producción, crea el objeto RootSync o RepoSync con el parámetro spec.git.branch establecido en master.

Por ejemplo, la siguiente definición de RootSync configura Config Management para usar la rama master:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  git:
    repo: git@example.com:anthos/config-management.git
    branch: master
    auth: ssh

En el siguiente diagrama, se ilustra el proceso de lanzamiento de este método:

Proceso de lanzamiento para ramas de Git.

Puedes adaptar este patrón a necesidades específicas mediante el uso de más de dos ramas o ramas asignadas a algo que no sea entornos. Si necesitas revertir un cambio, usa el comando git revert para crear una confirmación nueva en la misma rama que revierte los cambios de la confirmación anterior.

Recomendamos las siguientes acciones:

  • Cuando trabajes con varios clústeres, usa al menos dos ramas de Git para distinguir entre los clústeres de producción y los que no lo sean.
  • La mayoría de las soluciones de Git te permiten usar la función de ramas protegidas para evitar las eliminaciones o los cambios sin revisión de esas ramas. Para obtener más información, consulta la documentación de GitHub, GitLab y Bitbucket.

Usa objetos ClusterSelector y NamespaceSelector

Las ramas de Git son una buena manera de realizar un lanzamiento por etapas de cambios en varios clústeres que al final tendrán las mismas políticas. Sin embargo, si deseas lanzar un cambio solo en un subconjunto de clústeres o espacios de nombres, usa los objetos ClusterSelector y NamespaceSelector. Estos objetos tienen un objetivo similar: te permiten aplicar objetos solo a clústeres o espacios de nombres que tienen etiquetas específicas.

Por ejemplo:

  • Si usas objetos ClusterSelector, puedes aplicar diferentes políticas a los clústeres, según el país en el que se encuentren, para varios regímenes de cumplimiento.
  • Si usas objetos NamespaceSelector, puedes aplicar diferentes políticas a los espacios de nombres que usa un equipo interno y un contratista externo.

Los objetos ClusterSelector y NamespaceSelector también te permiten implementar metodologías avanzadas de prueba y lanzamiento, como las siguientes:

  • Lanzamientos Canary de políticas, en los que implementas una política nueva en un subconjunto pequeño de clústeres y espacios de nombres durante mucho tiempo para estudiar el impacto de la política
  • Pruebas A/B, en las que implementas versiones distintas de la misma política en clústeres diferentes con el fin de estudiar la diferencia del impacto de las versiones de la política y, luego, elegir la mejor para implementar en todas partes

Por ejemplo, imagina una organización con varios clústeres de producción. El equipo de la plataforma ya creó dos categorías de clústeres de producción, llamados canary-prod y prod, con Config Management, objetos Cluster y ClusterSelector (consulta Usa ClusterSelectors).

El equipo de la plataforma desea lanzar una política con el controlador de políticas para aplicar la presencia de una etiqueta de equipo a los espacios de nombres a fin de identificar a qué equipo pertenece cada espacio de nombres. Ya lanzaron una versión de esta política en el modo de ejecución de prueba y ahora quieren aplicarla en una cantidad pequeña de clústeres. Mediante objetos ClusterSelector, crean dos recursos K8sRequiredLabels distintos que se aplican a clústeres diferentes.

  • El recurso K8sRequiredLabels se aplica a los clústeres de tipo prod, con un parámetro enforcementAction configurado como dryrun:

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-team
  annotations:
    configmanagement.gke.io/cluster-selector: prod
Spec:
  enforcementAction: dryrun
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels:
      - key: "team"

  • El recurso K8sRequiredLabels se aplica a los clústeres de tipo canary-prod, sin el parámetro enforcementAction, lo que significa que la política se aplica de verdad:

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-team
  annotations:
    configmanagement.gke.io/cluster-selector: canary-prod
spec:
  match:
    kinds:
      - apiGroups: [""]
    kinds: ["Namespace"]
  parameters:
    labels:
      - key: "team"

La anotación configmanagement.gke.io/cluster-selector permite que el equipo aplique la política solo en clústeres de tipo canary-prod, lo que evita que se propaguen efectos secundarios no deseados a toda la flota de producción. Para obtener más información sobre la función de ejecución de prueba del controlador de políticas, consulta Crea restricciones.

Recomendamos las siguientes acciones:

  • Usa los objetos ClusterSelector y NamespaceSelector si necesitas aplicar un cambio de configuración a un solo subconjunto de clústeres o espacios de nombres de forma indefinida o durante mucho tiempo.
  • Si lanzas un cambio mediante selectores, ten mucho cuidado. Si usas confirmaciones de Git, cualquier error afecta solo a un clúster a la vez, ya que lanzas clúster por clúster. Sin embargo, si usas ramas de Git, cualquier error puede afectar a todos los clústeres que usen esa rama. Si usas selectores, el error puede afectar a todos los clústeres a la vez.

Implementa revisiones, pruebas y validaciones

Una de las ventajas de Config Management es que administra todo de manera declarativa: los recursos de Kubernetes, los recursos de nube y las políticas. Esto significa que los archivos en un sistema de administración de control de origen representan los recursos (archivos de Git, en el caso de Config Management). Esta función te permite implementar flujos de trabajo de desarrollo que ya usas para el código fuente de una aplicación: revisiones y pruebas automatizadas.

Implementa revisiones

Debido a que Config Management se basa en Git, puedes usar tu solución de Git preferida para alojar el repositorio de Config Management. Es probable que tu solución de Git tenga una función de revisión de código, que puedes usar para revisar los cambios realizados en el repositorio de Config Management.

Las prácticas recomendadas para revisar los cambios en el repositorio de Config Management son las mismas que con una revisión de código normal, como se muestra a continuación:

Debido a la sensibilidad de la base de código de Config Management, también recomendamos que, si es posible con tu solución de Git, establezcas los siguientes parámetros de configuración:

Si usas estas funciones diferentes, puedes aplicar aprobaciones para cada solicitud de cambio en la base de código de Config Management. Por ejemplo, puedes asegurarte de que al menos un miembro del equipo de la plataforma (que opere la flota de clústeres) y un miembro del equipo de seguridad (que esté a cargo de la implementación y definición de políticas de seguridad) aprueben cada cambio.

Te recomendamos la siguiente acción:

  • Aplica las revisiones de pares en el repositorio de Config Management y protege las ramas de Git que usan tus clústeres.

Implementa pruebas automatizadas

Una práctica recomendada común cuando se trabaja en una base de código es implementar la integración continua. Esto significa que configuras pruebas automatizadas para que se ejecuten cuando se crea o se actualiza una solicitud de cambio. Las pruebas automatizadas pueden detectar muchos errores antes de que se realice una revisión manual de la solicitud de cambio. Esto ajusta el ciclo de reacción del desarrollador. Puedes implementar la misma idea con las mismas herramientas para el repositorio de Config Management.

Por ejemplo, un buen punto de partida es ejecutar el comando nomos vet de forma automática en los cambios nuevos. Este comando valida que la sintaxis del repositorio de Config Management sea válida. Puedes implementar esta prueba mediante Cloud Build si sigues el instructivo para validar la configuración. Puedes integrar Cloud Build con las siguientes opciones:

Como puedes ver en el instructivo de validación de configuraciones, la prueba se realiza mediante una imagen de contenedor. Por lo tanto, puedes implementar la prueba en cualquier solución de integración continua que ejecute contenedores, no solo Cloud Build. En particular, puedes implementarla con la CI de GitLab, mediante este ejemplo, que también incluye pruebas para el controlador de políticas.

Para ajustar aún más el ciclo de reacción, puedes pedirles a los usuarios que ejecuten el comando nomos vet como un hook previo a la confirmación de Git. Una advertencia es que es posible que algunos usuarios no tengan acceso a los clústeres de Kubernetes que administra Config Management y que no puedan ejecutar la validación completa desde su estación de trabajo. Ejecuta el comando nomos vet --clusters "" para restringir la validación a verificaciones semánticas y sintácticas.

Puedes implementar cualquier otra prueba que consideres necesaria o útil. Si usas el controlador de políticas, puedes implementar pruebas automatizadas de cambios sugeridos con sus políticas, como se describe en Prueba cambios con las políticas del controlador de políticas.

Te recomendamos la siguiente acción:

  • Implementa pruebas en una canalización de integración continua. Ejecuta al menos el comando nomos vet en todos los cambios sugeridos.

Usa el controlador de políticas

El controlador de políticas es un controlador de admisión dinámico de Kubernetes. Cuando instalas y configuras el controlador de políticas, Kubernetes puede rechazar los cambios que no cumplen con las reglas predefinidas, que se denominan políticas.

A continuación, se incluyen dos casos de uso del controlador de políticas:

  • Aplica la presencia de etiquetas específicas en objetos de Kubernetes.
  • Evita la creación de Pods con privilegios.

Hay una biblioteca de plantillas de políticas disponible para implementar las políticas más usadas, pero puedes escribir la tuya con un lenguaje potente llamado Rego. Mediante el controlador de políticas, puedes, por ejemplo, restringir los nombres de host que los usuarios pueden configurar en una entrada (para obtener más información, consulta este instructivo).

Al igual que el Sincronizador de configuración, el controlador de políticas es parte del producto de Config Management. El controlador de políticas y la sincronización de configuración tienen casos de uso diferentes, pero complementarios, de la siguiente manera:

  • El sincronizador de configuración es una herramienta del estilo de GitOps que te permite crear cualquier objeto de Kubernetes, con la posibilidad de hacerlo en varios clústeres al mismo tiempo. Como se mencionó en la introducción, el sincronizador de configuración es muy útil para administrar políticas.
  • El controlador de políticas te permite definir políticas para los objetos que se pueden crear en Kubernetes. Estas políticas se definen en recursos personalizados, que son objetos de Kubernetes.

Las funciones anteriores crean una relación bidireccional entre las dos aplicaciones. Puedes usar el sincronizador de configuración a fin de crear las políticas que el controlador de políticas aplica; y puedes usar esas políticas para controlar con exactitud qué objetos puede crear el sincronizador de configuración (o cualquier otro proceso) como se muestra en el siguiente diagrama:

Sincronización de configuración y controlador de políticas

El repositorio de Git, el sincronizador de configuración, el controlador de políticas, Kubernetes, un sistema de implementación continua (CD) y los usuarios interactúan todos entre sí de las siguientes maneras:

  • Los usuarios interactúan con el repositorio de Git de Config Management para crear, actualizar o borrar objetos de Kubernetes.
  • El Sincronizador de configuración lee su configuración desde el repositorio de Git de Config Management.
  • El sincronizador de configuración interactúa con el servidor de la API de Kubernetes a fin de crear objetos, que incluyen políticas para el controlador de políticas.
  • El sistema de CD también interactúa con el servidor de la API de Kubernetes para crear objetos. Puede crear restricciones para el controlador de políticas. Sin embargo, te recomendamos que uses Config Management para este caso de uso, ya que te brinda un lugar centralizado para administrar y probar las restricciones.
  • El servidor de la API de Kubernetes acepta o rechaza la creación de objetos mediante el sincronizador de configuración y el sistema de CD, según la respuesta del controlador de políticas.
  • El controlador de políticas proporciona esa respuesta en función de las políticas que lee desde el servidor de la API de Kubernetes.

En el siguiente diagrama, se ilustran estas interacciones:

Interacciones entre el repositorio de Git, la sincronización de configuración, el controlador de políticas, Kubernetes, un sistema de implementación continua y los usuarios.

El controlador de políticas puede evitar incumplimientos de políticas que escapan a los revisores manuales y las pruebas automatizadas, por lo que puedes considerarlo la última línea de defensa de tus clústeres de Kubernetes. El controlador de políticas también se vuelve más útil a medida que aumenta la cantidad de revisores manuales de Config Management. Debido al fenómeno de pereza social, cuantos más revisores tengas, menos probabilidades habrá de que apliquen de manera coherente las reglas definidas en tu organización.

Prueba cambios en las políticas del controlador de políticas

Si usas el controlador de políticas, puedes agregar algunos pasos a tu canalización de integración continua (consulta Implementa pruebas automatizadas) para probar de forma automática los cambios sugeridos en las políticas. La automatización de las pruebas proporciona comentarios más rápidos y visibles a la persona que sugiere el cambio. Si no pruebas los cambios con las políticas de la canalización de integración continua, debes confiar en el sistema que se describe en Supervisa los lanzamientos para recibir alertas de errores de sincronización de Config Management. Probar los cambios en las políticas expone cualquier incumplimiento de forma clara y anticipada a la persona que sugiere el cambio.

Puedes implementar esta prueba en Cloud Build si sigues el instructivo Usa el controlador de políticas en una canalización de CI. Como se mencionó antes en Implementa pruebas automatizadas, puedes integrar Cloud Build en GitHub y Bitbucket. También puedes implementar esta prueba con la CI de GitLab. Consulta este repositorio para ver un ejemplo de implementación.

Te recomendamos la siguiente acción:

  • Si usas el controlador de políticas, valida los cambios sugeridos en sus políticas en tu canalización de integración continua.

Supervisa los lanzamientos

Incluso si implementas todas las barreras de seguridad que se cubren en este documento, pueden ocurrir errores. Los siguientes son dos tipos comunes de errores:

  • Errores que no representan ningún problema para el sincronizador de configuración, pero impiden que tus cargas de trabajo funcionen de forma correcta, como una NetworkPolicy demasiado restrictiva que impide que los componentes de tu carga de trabajo se comuniquen
  • Errores que hacen que el sincronizador de configuración no pueda aplicar cambios a un clúster, como un manifiesto de Kubernetes no válido o un objeto rechazado por un controlador de entrada. Los métodos explicados antes deberían detectar la mayoría de estos errores

Es casi imposible detectar los errores descritos en la primera viñeta anterior a nivel de Config Management, ya que esto requiere comprender el estado de cada una de las cargas de trabajo. Por este motivo, tu sistema de supervisión existente es lo mejor para detectar estos errores, ya que te avisa cuando una aplicación tiene un comportamiento deficiente.

La detección de los errores descritos en la segunda viñeta anterior, que deberían ser inusuales si se implementaron todas las barreras de seguridad, requiere una configuración específica. De forma predeterminada, Config Management escribe errores en sus registros (que encontrarás de forma predeterminada en Cloud Logging). También se muestran los errores en la página de la consola de Config Management. Ni los registros ni la consola suelen ser suficiente para detectar errores porque es probable que no los supervises en todo momento. La forma más sencilla de automatizar la detección de errores es ejecutar el comando nomos status, que te indica si hay un error en un clúster.

También puedes configurar una solución más avanzada con alertas automáticas para errores. Config Management expone métricas en el formato Prometheus. Para obtener más información, consulta Supervisa Config Management.

Una vez que tengas las métricas de Config Management en tu sistema de supervisión, crea una alerta para que te notifique cuando la métrica gkeconfig_monitor_errors sea mayor que 0. Si deseas obtener más información, consulta Administra políticas de alertas para Cloud Monitoring o Reglas de alertas para Prometheus.

Resumen de los mecanismos para lanzamientos seguros con Config Management

En la siguiente tabla, se resumen los diversos mecanismos descritos antes en este documento. Ninguno de estos mecanismos es exclusivo. Puedes optar por usar algunos o todos ellos para diferentes propósitos.

Mecanismos Usos ideales Usos no convenientes Ejemplo de caso de uso
ID y etiquetas de confirmación de Git Usa etiquetas o ID de confirmación de Git específicos para controlar con precisión en qué clúster se aplican cambios. No uses ID de confirmación ni etiquetas de Git para las diferencias de larga duración entre clústeres. Usa selectores de clúster. Todos tus clústeres están configurados para aplicar la confirmación 12345 de Git. Realiza un cambio con una confirmación nueva, abcdef, que deseas probar. Cambia la configuración de un solo clúster para usar esta confirmación nueva a fin de validar el cambio.
Ramas de Git Usa varias ramas de Git cuando quieras lanzar el mismo cambio en varios entornos, uno después del otro. No uses varias ramas de Git para las diferencias de larga duración entre clústeres. Las ramas se dividirán de forma significativa y será difícil volver a combinarlas. Primero, combina el cambio en la rama de etapa de pruebas, en la que los clústeres de etapa de pruebas lo tomarán.
Luego, combina el cambio en la rama principal, en la que los clústeres de producción lo tomarán.
Selectores de clústeres y de espacios de nombres Usa selectores para las diferencias de larga duración entre los clústeres y los espacios de nombres. No uses selectores para un lanzamiento por etapas en varios entornos. Si primero quieres probar una modificación en la etapa de pruebas y, luego, implementarla en producción, usa ramas de Git diferentes. Si los equipos de la aplicación necesitan acceso completo a los clústeres de desarrollo, pero solo lectura a los clústeres de producción, usa el objeto ClusterSelector para aplicar las políticas de RBAC adecuadas solo en los clústeres relevantes.
Evaluaciones entre compañeros Usa las evaluaciones entre compañeros para asegurarte de que los equipos relevantes aprueben los cambios. Los revisores manuales no detectan todos los errores, en particular, los elementos como los errores de sintaxis. Tu organización exige que el equipo de seguridad revise los cambios de configuración que afectan a varios sistemas. Haz que un miembro del equipo de seguridad revise los cambios.
Pruebas automatizadas en la canalización de integración continua Usa las pruebas automatizadas para detectar errores en los cambios sugeridos. Las pruebas automatizadas no pueden reemplazar por completo a un revisor humano. Usa ambas opciones. Ejecutar un comando nomos vet en todos los cambios sugeridos confirma que el repositorio es una configuración válida de Config Management.
Policy Controller Aplica políticas para toda la organización e implementa barreras de seguridad directamente a nivel de servidor de la API de Kubernetes. El controlador de políticas no se puede usar para crear, actualizar ni borrar políticas (esa es la función de Config Management). El controlador de políticas solo puede aplicar políticas. El equipo de seguridad usa Config Management para crear una restricción del controlador de políticas a fin de evitar que los usuarios creen contenedores con privilegios, incluso en espacios de nombres que administran directamente los equipos de la aplicación.
Prueba los cambios en las restricciones del controlador de políticas. Asegúrate de que el controlador de políticas no rechace los cambios cuando Config Management los aplique. Probar cambios en las restricciones del controlador de políticas en una canalización de integración continua no es un reemplazo para habilitar el controlador de políticas en los clústeres. Cada espacio de nombres debe tener una etiqueta de “equipo” para identificar al propietario. Un usuario desea crear un espacio de nombres nuevo y olvida agregar esta etiqueta en el cambio sugerido. La canalización de integración continua detecta el error antes de que se revise el cambio de forma manual.
Supervisa errores de sincronización Asegúrate de que Config Management realmente aplique los cambios a tus clústeres. Los errores de sincronización se producen solo si Config Management intenta aplicar un repositorio no válido o si el servidor de la API de Kubernetes rechaza algunos de los objetos. Si no codificaste aún todas tus restricciones en las políticas del controlador de políticas, no se detectarán los recursos que las infrinjan. Un usuario omite todas tus pruebas y revisiones, y confirma un cambio no válido en el repositorio de Config Management. Este cambio no se puede aplicar a tus clústeres. Si supervisas los errores de sincronización, recibirás una alerta si se produce un error.

Ejemplo de estrategia de lanzamiento

En esta sección, se usan los conceptos presentados en el resto de este artículo para ayudarte a crear una estrategia de implementación de extremo a extremo en todos los clústeres de tu organización. En esta estrategia, se da por sentado que tienes flotas separadas para el desarrollo, la etapa de pruebas y la producción (como se muestra en el ejemplo de flota 1, enfoque 1).

.

En esta situación, debes configurar cada clúster para que se sincronice con el repositorio de Git de Config Management mediante una confirmación de Git específica. Implementar un cambio en una flota determinada es un proceso de 4 pasos:

  1. Debes actualizar un solo clúster (el "canary") en la flota para usar la confirmación nueva primero.
  2. Verifica que todo funcione según lo esperado mediante la ejecución de pruebas y la supervisión del lanzamiento.
  3. Debes actualizar el resto de los clústeres en la flota.
  4. Vuelve a comprobar que todo funcione según lo esperado.

A fin de implementar un cambio en todos tus clústeres, repite este proceso para cada flota. Técnicamente, puedes aplicar este método con cualquier confirmación de Git, desde cualquier rama. Sin embargo, te sugerimos que adoptes el siguiente proceso para identificar los problemas durante las primeras etapas del proceso de revisión:

  1. Cuando alguien abra una solicitud de cambio en el repositorio de Git de Config Management, implementa ese cambio en uno de los clústeres de desarrollo.
  2. Si se acepta y combina la solicitud de cambio en tu rama principal, ejecuta la implementación completa en todas las flotas, como se describió antes.

Si bien algunos cambios pueden apuntar a una flota específica, te recomendamos que implementes todos los cambios en todas las flotas cuando sea posible. Con esta estrategia, se elimina el problema de realizar un seguimiento de qué flota se debe sincronizar con qué confirmación. Presta especial atención a los cambios que se orientan solo a la flota de producción porque no se pudieron realizar las pruebas adecuadas en flotas anteriores. Por ejemplo, esto significa que pasará más tiempo para que se muestren los problemas mientras realizas una implementación en los clústeres Canary y, luego, en el resto de los clústeres.

En resumen, una implementación de extremo a extremo completa de esta es similar a la siguiente:

  1. Alguien abre una solicitud de cambio.
  2. Se ejecutan pruebas y validaciones automatizadas, y se realiza una revisión manual.
  3. Se activa un trabajo de forma manual para implementar el cambio en el clúster de Canary de la flota de desarrollo. Las pruebas automatizadas de extremo a extremo se ejecutan en este clúster.
  4. Si todo está bien, fusionas la solicitud de cambio en la rama principal.
  5. La combinación activa un trabajo automatizado para implementar el nuevo compromiso sugerido de la rama principal en el clúster canary de la flota de desarrollo. Las pruebas automatizadas de extremo a extremo se ejecutan en este clúster (para detectar incompatibilidades potenciales entre dos solicitudes de cambio que se crearon y fusionaron aproximadamente al mismo tiempo).
  6. Los siguientes trabajos se ejecutan uno después del otro (los activas de forma manual o después de un tiempo predefinido para permitir los informes de regresiones de usuarios):
    1. Implementar en todos los clústeres de la flota de desarrollo.
    2. Ejecutar pruebas y validaciones en los clústeres de la flota de desarrollo.
    3. Implementar en el clúster canary de la flota de etapa de pruebas.
    4. Ejecutar las pruebas y validaciones en el clúster canary de la flota de etapa de pruebas.
    5. Implementar en todos los clústeres de la flota de etapa de pruebas
    6. Ejecutar pruebas y validaciones en los clústeres de la flota de etapa de pruebas.
    7. Implementar en el clúster canary de la flota de producción.
    8. Ejecutar las pruebas y validaciones en el clúster Canary de la flota de producción.
    9. Implementar en todos los clústeres de la flota de producción.
    10. Ejecutar pruebas y validaciones en los clústeres de la flota de producción.

Proceso completo de implementación:

¿Qué sigue?