Descripción general de las opciones de configuración

En esta página, se describen las configuraciones, los archivos que Anthos Config Management lee de Git y se aplica a tus clústeres automáticamente. Puedes crear una configuración.

Resumen

Anthos Config Management mantiene tus clústeres inscritos sincronizados mediante el uso de una configuración. Una configuración es un archivo YAML o JSON que se almacena en tu repositorio y contiene los mismos tipos de detalles de configuración que puedes aplicar manualmente a un clúster mediante el comando kubectl apply. En este tema, se cubre cómo funcionan las configuraciones, cómo escribirlas y cómo Anthos Config Management las aplica a tus clústeres inscritos.

Anthos Config Management está diseñado para operadores de clústeres que administren muchos clústeres. Puedes asegurarte de que tus clústeres cumplan con los estándares comerciales y de cumplimiento si permites que Anthos Config Management administre los espacios de nombres, las funciones, los RoleBindings, los ResourceQuotas y otros objetos importantes de Kubernetes en toda tu flota. Puedes crear una configuración para cualquier objeto de Kubernetes que pueda existir en un clúster.

Trabaja con la configuración a lo largo del tiempo

En el siguiente árbol de decisión, se ilustran los resultados de diferentes cambios de configuración en un grupo hipotético de clústeres administrados por Anthos Config Management a lo largo del tiempo. Siguiendo el diagrama, algunas acciones hipotéticas de los operadores de clústeres y los resultados de esas acciones se discuten y se utilizan para ilustrar cómo funciona Anthos Config Management.

Este clúster utiliza el repositorio de ejemplo. El clúster ya está registrado con el operador.

Ejemplo de árbol de decisión que ilustra las acciones y los resultados de Anthos Config Management a lo largo del tiempo

  • Anthos Config Management aplica configuraciones solo cuando se cumple al menos una de las siguientes condiciones:

    • existe una configuración relevante en el repositorio
    • la anotación configmanagement.gke.io/managed: enabled se aplica al objeto de Kubernetes

    El clúster foo-corp tiene un ClusterRole llamado pod-accountant que no tiene la anotación configmanagement.gke.io/managed: enabled, y no existe ninguna configuración para el objeto ClusterRole en el repositorio. Anthos Config Management no configura el ClusterRole pod-accountant.

  • Anthos Config Management aplica un cambio relevante automáticamente cuando se confirma con el repositorio.

    Un administrador de clústeres confirma una configuración en el archivo cluster/quota-viewer-clusterrole.yaml del repositorio. Esta configuración define un ClusterRole llamado quota-viewer. Como la configuración se crea en el directorio cluster/, afecta a todos los clústeres inscritos. Anthos Config Management detecta la configuración recién confirmada y la aplica. El ClusterRole quota-viewer ahora existe en el clúster, tiene la anotación configmanagement.gke.io/managed: enabled y está sincronizado con el contenido de quota-viewer-clusterrole.yaml.

    Algún tiempo después, alguien borra el archivo cluster/quota-viewer-clusterrole.yaml del repositorio. Anthos Config Management detecta este cambio y quita el ClusterRole quota-viewer del clúster.

  • Puedes comenzar con la administración de un objeto existente si agregas la anotación configmanagement.gke.io/managed: enabled.

    El clúster foo-corp tiene un directorio de espacio de nombres llamado shipping-dev. Dentro de este directorio de espacio de nombres, existe una configuración para una función llamada job-creator y tiene la anotación configmanagement.gke.io/managed: enabled. Alguien actualiza el archivo namespaces/dev/shipping-dev/job-creator-role.yaml. El operador detecta y aplica el cambio.

  • Anthos Config Management te permite aplicar cambios de configuración a espacios de nombres de forma jerárquica y agrupada.

    El clúster foo-corp tiene un RoleBinding llamado pod-creator y un archivo /namespaces/pod-creator/pod-creator.yaml correspondiente en el repositorio. En el diagrama, se muestra que shipping-prod, shipping-staging y shipping-dev son espacios de nombres (cada uno tiene un archivo namespace.yaml que define un espacio de nombres) dentro del directorio de espacio de nombres abstracto shipping-dev-backend. Cada uno de estos espacios de nombres hereda el RoleBinding pod-creator.

    Algún tiempo después, alguien modifica el RoleBinding pod-creator en el directorio del espacio de nombres shipping-prod. El operador detecta el cambio y actualiza pod-creator para que coincida con la configuración en el repositorio.

    Finalmente, alguien quita la configuración pod-creator del repositorio. Anthos Config Management detecta el cambio y quita el RoleBinding pod-creator de cada uno de los tres espacios de nombres.

  • Anthos Config Management te permite aplicar cambios manualmente y no administra objetos a menos que tengan la anotación configmanagement.gke.io/managed: enabled.

    Alguien crea manualmente una nueva función llamada secret-admin en el espacio de nombres shipping-prod. No existe ninguna configuración para la función secret-admin en el repositorio. La función secret-admin no tiene la anotación configmanagement.gke.io/managed: enabled. Anthos Config Management no realiza ninguna acción.

    Algún tiempo después, alguien agrega manualmente la anotación configmanagement.gke.io/managed:enabled a la función secret-admin. Todavía no hay una configuración correspondiente en el repositorio, por lo que Anthos Config Management borra la función secret-admin del espacio de nombres.

  • Anthos Config Management crea espacios de nombres faltantes si existen configuraciones para ellos.

    Alguien confirma una nueva configuración para el espacio de nombres audit, que no existe en el clúster. Anthos Config Management crea el espacio de nombres audit en el clúster y le aplica la anotación configmanagement.gke.io/managed: enabled.

  • Anthos Config Management puede administrar configuraciones para un espacio de nombres que no tiene la anotación configmanagement.gke.io/managed: enabled.

    El espacio de nombres shipping-dev existe en el clúster pero no tiene la anotación configmanagement.gke.io/managed: enabled. Sin embargo, el directorio de espacio de nombres shipping-dev en el repositorio tiene un RoleBinding llamado job-creators, que tiene la anotación configmanagement.gke.io/managed: enabled.

    Alguien agrega una configuración para el espacio de nombres shipping-dev en el repositorio, pero no hay configuración para el RoleBinding job-creators. Como no existe ninguna configuración para el RoleBinding, pero este tiene la anotación configmanagement.gke.io/managed: enabled, Anthos Config Management borra el RoleBinding.

    Más tarde, alguien agrega una configuración para el RoleBinding job-creators. El RoleBinding job-creators se vuelve a crear con las propiedades definidas en la configuración.

Qué sigue