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 archivo de configuración y confirmarlo en tu repositorio.

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 un archivo de 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 usa 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 un archivo de 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 ningún archivo de 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 de forma automática cuando se confirma en el repositorio.

    Un administrador de clúster confirma un archivo de configuración en el archivo cluster/quota-viewer-clusterrole.yaml en el repositorio. Este archivo de configuración define un ClusterRole llamado quota-viewer. Debido a que el archivo de 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 a administrar un objeto existente en un clúster cuando 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 un archivo de configuración para una función llamado 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) en el directorio de espacios de nombres abstractos shipping-dev-backend. Cada uno de estos espacios de nombres hereda un RoleBinding pod-creator.

    Poco después, alguien modifica el RoleBinding pod-creator en el directorio de espacio de nombres shipping-prod. El Operador detecta el cambio y actualiza pod-creator para que coincida con el archivo de configuración en el repositorio.

    Tarde o temprano, alguien quita el archivo de 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 de forma manual una nueva función llamada secret-admin en el espacio de nombres shipping-prod. No existe ningún archivo de 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.

    Poco después, alguien agrega de forma manual 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 los espacios de nombres faltantes, si existe una configuración para ellos.

    Alguien confirma un nuevo archivo de 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 archivos de configuración para un espacio de nombres que no tenga 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 un archivo de configuración para el espacio de nombres shipping-dev en el repositorio, pero no hay un archivo de configuración para la función 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 el archivo de configuración.

¿Qué sigue?