Gestionar objetos de clústeres disponibles

Cuando Config Sync gestiona un objeto de clúster, monitoriza el objeto y el conjunto de configuraciones del repositorio que afectan al objeto, y se asegura de que estén sincronizados. En este tema se describe cómo empezar a gestionar un objeto y cómo dejar de gestionar un objeto que se está gestionando sin eliminarlo.

Config Sync gestiona un objeto de un clúster si tiene la anotación configmanagement.gke.io/managed: enabled y la anotación configsync.gke.io/resource-id, que registra la información del grupo, el tipo, el espacio de nombres y el nombre del objeto, es correcta.

El formato de la anotación configsync.gke.io/resource-id es GROUP_KIND_NAMESPACE_NAME para un objeto centrado en un espacio de nombres y GROUP_KIND_NAME para un objeto centrado en un clúster.

En el siguiente diagrama de flujo se describen algunas situaciones que provocan que un objeto se convierta en gestionado o no gestionado:

El diagrama contiene tres flujos independientes: 1) empezar a gestionar un objeto, 2) dejar de gestionar un objeto y 3) eliminar un objeto gestionado.

1. Quiero empezar a gestionar un objeto. ¿Tiene un manifiesto el objeto? En otras palabras, ¿el objeto tiene una configuración en el repositorio?
   • No: crea una configuración para el objeto. Config Sync define la anotación configmanagement.gke.io/managed: enabled, define la anotación configsync.gke.io/resource-id para que coincida con el objeto y empieza a gestionar el objeto.
   • Sí: ¿la configuración define la siguiente anotación? configmanagement.gke.io/managed: disabled
     • No: el objeto se gestiona de forma predeterminada.
     • Sí: edita la configuración para quitar la anotación configmanagement.gke.io/managed: disabled. Cuando el cambio se envía al repositorio de origen, Config Sync detecta el cambio, aplica las anotaciones configmanagement.gke.io/managed: enabled y configsync.gke.io/resource-id, y aplica la configuración.
2. Quiero dejar de gestionar un objeto, pero no eliminarlo.
   • Edita la configuración del objeto en el repositorio y define la anotación configmanagement.gke.io/managed: disabled. Cuando se detecta el cambio de configuración, Config Sync deja de gestionar el objeto.
3. Quiero dejar de gestionar un objeto y eliminarlo.
   • Elimina la configuración del objeto del repositorio. Cuando eliminas una configuración de un objeto que se gestionaba anteriormente, Config Sync elimina el objeto de todos los clústeres o espacios de nombres a los que se aplica la configuración.

Además de las anotaciones configmanagement.gke.io/managed: enabled y configsync.gke.io/resource-id, Config Sync aplica la etiqueta app.kubernetes.io/managed-by: configmanagement.gke.io a todos los objetos que gestiona. Esta etiqueta le permite enumerar fácilmente todos los objetos por Config Sync.

¿Por qué no aplicas la anotación manualmente?

Config Sync usa un modelo declarativo para aplicar los cambios de configuración a tus clústeres leyendo la configuración que quieras de tu repositorio. Si intentas aplicar la anotación manualmente (ya sea con el comando kubectl o con la API de Kubernetes), Config Sync sobrescribe automáticamente la anotación manual con el contenido de tu repositorio.

Antes de empezar

Los siguientes ejemplos se basan en el artículo Primeros pasos con Config Sync. Antes de seguir los pasos que se indican a continuación, consulta la guía de inicio rápido y completa todos los pasos antes de explorar y probar la instalación de Config Sync.

Mostrar todos los objetos gestionados

Para obtener una lista de todos los objetos gestionados por Config Sync en un clúster o espacio de nombres determinado, usa un selector de etiquetas como el siguiente:

kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

Para obtener una lista de todos los objetos que no gestiona Config Sync, usa un selector de etiquetas como este:

kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

Por ejemplo, este comando muestra los RoleBindings del espacio de nombres gamestore que gestiona Config Sync:

kubectl get rolebindings -n gamestore \
    -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

El resultado debería ser similar al siguiente:

NAME                              ROLE                                          AGE
configsync.gke.io:ns-reconciler   ClusterRole/configsync.gke.io:ns-reconciler   34h
gamestore-admin                   ClusterRole/admin                             34h
gamestore-webstore-admin          ClusterRole/webstore-admin                    34h

Este comando muestra los RoleBindings del espacio de nombres kube-system que no gestiona Config Sync:

kubectl get rolebindings -n kube-system \
    -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

El resultado debería ser similar al siguiente:

NAME                                             AGE
fluentd-gcp-scaler-binding                       2d21h
gce:cloud-provider                               2d21h
heapster-binding                                 2d21h
metrics-server-auth-reader                       2d21h
system::leader-locking-kube-controller-manager   2d21h
system::leader-locking-kube-scheduler            2d21h
system:controller:bootstrap-signer               2d21h
system:controller:cloud-provider                 2d21h
system:controller:token-cleaner                  2d21h

Empezar a gestionar un objeto

Puedes crear una configuración para un objeto de Kubernetes, como un espacio de nombres, que ya exista en tu clúster antes de instalar Config Sync. Sin embargo, esta configuración se ignora a menos que el objeto tenga la anotación configmanagement.gke.io/managed: enabled y la anotación configsync.gke.io/resource-id correcta. En el caso de los objetos que ya existen, debes aplicar la anotación manualmente.

En el caso de los espacios de nombres, Config Sync sí aplica configuraciones que crean objetos nuevos en un espacio de nombres sin anotaciones y aplica las anotaciones configmanagement.gke.io/managed: enabled y configsync.gke.io/resource-id a esos objetos. Sin embargo, Config Sync no modifica ni elimina ningún objeto sin anotaciones con ámbito de clúster de un clúster. Esto se ilustra en el diagrama de la sección Trabajar con configuraciones a lo largo del tiempo.

En el siguiente ejemplo se muestra cómo gestionar un objeto Role. Primero, crea un rol manualmente y, después, empieza a gestionarlo con Config Sync.

1. Crea el rol myrole en el espacio de nombres gamestore:

   kubectl create role -n gamestore myrole --verb=get --resource=pods

2. Consulta los permisos concedidos por el rol myrole:

   kubectl describe role -n gamestore myrole

   Name:         myrole
   Labels:       <none>
   Annotations:  <none>
   PolicyRule:
     Resources  Non-Resource URLs  Resource Names  Verbs
     ---------  -----------------  --------------  -----
     pods       []                 []              [get]
   

   El rol solo tiene permiso para get pods.

3. En este punto, el rol existe en el clúster, pero Config Sync no lo conoce.

   1. En un terminal, ve a la copia local de tu repositorio.

   2. Usa el siguiente comando para crear un manifiesto YAML para myrole y guardar el manifiesto en un archivo nuevo llamado gamestore-myrole.yaml.

      kubectl get role myrole -n gamestore -o yaml > gamestore-myrole.yaml
      

   3. Edita el archivo gamestore-myrole.yaml.

      1. Elimina todos los campos de la clave metadata, excepto name y namespace.
      2. Añade el verbo list después de get en el campo de lista rules.verbs.

      Guarda los cambios. El archivo resultante tiene el siguiente contenido:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: myrole
        namespace: gamestore
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - get
        - list
      

   4. Confirma el cambio en el repositorio.

   5. Espera unos instantes a que el operador ConfigManagement detecte la confirmación. Para verificar que el rol myrole ahora está gestionado por Config Sync, vuelve a ejecutar kubectl describe.

      kubectl describe role myrole -n gamestore
      

Fíjate en la anotación configmanagement.gke.io/managed: enabled, que indica que Config Sync gestiona el objeto, y en la anotación configsync.gke.io/resource-id, que registra la información del grupo, el tipo, el espacio de nombres y el nombre. También puedes ver las anotaciones que muestran la ruta y el nombre del archivo del repositorio que ha provocado el cambio de configuración más reciente en el objeto, así como el hash de Git que representa la confirmación.

Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
              configsync.gke.io/declared-version=v1
Annotations:  config.k8s.io/owning-inventory: config-management-system_root-sync
              configmanagement.gke.io/cluster-name: my-cluster
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: config-sync-quickstart/multirepo/root/gamestore-myrole.yaml
              configmanagement.gke.io/token: 747b843a7ddbd945c0616034a935cf648b58e7b5
              configsync.gke.io/declared-fields: {"f:rules":{}}
              configsync.gke.io/git-context: {"repo":"https://github.com/GoogleCloudPlatform/anthos-config-management-samples","branch":"main","rev":"HEAD"}
              configsync.gke.io/manager: :root
              configsync.gke.io/resource-id: rbac.authorization.k8s.io_role_gamestore_myrole
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list]

Dejar de gestionar un objeto gestionado

En este ejemplo se muestra cómo dejar de gestionar un objeto que Config Sync está gestionando, como el rol myrole en Empezar a gestionar un objeto.

Nota: Antes de quitar un espacio de nombres de la gestión, asegúrate de que sabes qué ocurre con los objetos de ese espacio de nombres que aún están gestionados.

1. Edita el archivo config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml en la copia local de tu repositorio y añade una sección annotations: que coincida con el texto en negrita que aparece a continuación:

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      annotations:
        configmanagement.gke.io/managed: disabled
      name: gamestore-webstore-admin
      namespace: gamestore
    subjects:
    - kind: ServiceAccount
      name: ns-reconciler-gamestore
      namespace: config-management-system
    roleRef:
      kind: ClusterRole
      name: webstore-admin
      apiGroup: rbac.authorization.k8s.io
   

   Guarda el archivo.

2. Crea una confirmación de Git con los cambios y envíala a tu repositorio.

3. Espera unos instantes a que Config Sync detecte y aplique la nueva confirmación.

4. Usa el siguiente comando para verificar que las anotaciones y las etiquetas del recurso gamestore-webstore-admin RoleBinding están vacías. Config Sync no asigna el valor disabled a la anotación configmanagement.gke.io/managed del objeto.

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml
   

   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     annotations:
     name: gamestore-webstore-admin
     namespace: gamestore
   subjects:
   - kind: ServiceAccount
     name: ns-reconciler-gamestore
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: webstore-admin
     apiGroup: rbac.authorization.k8s.io
   

Después de verificar que el objeto está inhabilitado, puedes quitar la configuración del repositorio y comprobar que el objeto no gestionado no se ha eliminado del espacio de nombres. Si quieres volver a gestionar el objeto, debes volver a añadir su configuración al repositorio. Por este motivo, puede que quieras dejar de gestionar objetos y dejar sus configuraciones en el repositorio.

Ahora que el objeto no está gestionado, no se crea ni se vuelve a crear en clústeres nuevos o ya creados, y no se elimina aunque exista. Para volver a gestionar un objeto que has dejado de gestionar, consulta el siguiente ejemplo: Volver a gestionar un objeto que no se gestionaba.

Reanudar la gestión de un objeto que no se gestionaba anteriormente

En este ejemplo se muestra cómo volver a gestionar un objeto que has quitado de la gestión, como se explica en Dejar de gestionar un objeto. Se da por hecho que no has quitado la configuración de gamestore-webstore-admin RoleBinding.

1. Si has eliminado el recurso gamestore-webstore-admin RoleBinding de tu repositorio en la última confirmación, sigue estos pasos.

   1. Usa git revert para revertir la última confirmación:

      git revert HEAD~1
      

      Se te pedirá que confirmes la operación de restauración.

   2. Envía la confirmación de reversión a tu repositorio.

      git push
      

2. Edita el archivo config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml en la clonación local de tu repositorio y elimina la anotación configmanagement.gke.io/managed: disabled. Guarda el archivo.

3. Confirma y envía el cambio. Config Sync hace lo siguiente:

   • Detecta el cambio
   • Aplica la anotación configmanagement.gke.io/managed: enabled y la anotación configsync.gke.io/resource-id. El objeto ahora está gestionado.
   • Aplica la configuración, como ocurriría con cualquier objeto gestionado.

4. Para verificar que el objeto ahora está gestionado, enumera sus anotaciones:

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     annotations:
       configmanagement.gke.io/cluster-name: my-cluster
       configmanagement.gke.io/managed: enabled
       configsync.gke.io/resource-id: rbac.authorization.k8s.io_rolebinding_gamestore_gamestore-webstore-admin
   ...
   

Dejar de gestionar un espacio de nombres

Puedes dejar de gestionar un espacio de nombres de la misma forma que dejas de gestionar cualquier tipo de objeto. Si quieres dejar de gestionar otros recursos en el espacio de nombres, sigue estos pasos:

1. Añade la anotación configmanagement.gke.io/managed:disabled a la configuración del espacio de nombres y a todas las configuraciones del mismo espacio de nombres. Todos los objetos del espacio de nombres deben tener esta anotación.

   Precaución: En una fuente de información jerárquica, si el espacio de nombres se hereda de un espacio de nombres abstracto, no se puede desgestionar.

2. Confirma y envía los cambios al repositorio. Espera a que el operador se sincronice con el repositorio.

3. Elimina los recursos no gestionados del repositorio.

   Advertencia: Se sabe que, si no usas las APIs RootSync y RepoSync, al eliminar el espacio de nombres no gestionado del repositorio, se eliminará del clúster activo. En el caso de los recursos no gestionados que se hayan eliminado por error, debes volver a añadirlos manualmente al clúster, por ejemplo, con kubectl apply. Para usar las APIs RootSync y RepoSync, debes migrar tu objeto ConfigManagement.

Si hay configuraciones de configuraciones gestionadas en un directorio de espacio de nombres no gestionado, el reconciliador registra errores, pero otras configuraciones siguen sincronizándose con normalidad.

Eliminar recursos gestionados

Cuando eliminas un recurso de una fuente de información veraz, ese objeto se elimina del clúster la próxima vez que Config Sync se sincronice con la fuente de información veraz. También puedes habilitar la propagación de la eliminación, que te permite eliminar objetos en bloque.

Eliminar objetos concretos

Con el comportamiento predeterminado de Config Sync, cuando eliminas un objeto de una fuente de información veraz, ese objeto se elimina del clúster cuando Config Sync se sincroniza con la fuente de información veraz.

Hay varias formas de comprobar el estado de Config Sync o el estado de objetos específicos:

• Usa nomos status.
• Usa kubectl para examinar los recursos.
• Utiliza el panel de control de Config Sync.

Eliminar objetos en bloque

Vista previa

Este producto o función está sujeto a los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Los productos y las funciones previos a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases de lanzamiento.

De forma predeterminada, si se elimina un objeto RootSync o RepoSync, Config Sync abandona los objetos que se habían aplicado anteriormente desde la fuente de información veraz. También puedes habilitar la propagación de la eliminación para eliminar todos los objetos aplicados anteriormente.

Si habilitas la propagación de la eliminación en un objeto RootSync o RepoSync y, a continuación, eliminas ese objeto, Config Sync eliminará automáticamente todos los objetos que gestionaba ese RootSync o RepoSync.

La propagación de la eliminación puede facilitar la limpieza de recursos, por ejemplo, si vas a migrar a un nuevo espacio de nombres o clúster, si quieres limpiar después de una demostración o un experimento, o si vas a desinstalar una aplicación.

Opciones de propagación de la eliminación

La propagación de la eliminación está inhabilitada de forma predeterminada. Para habilitar la propagación de la eliminación, añade la anotación configsync.gke.io/deletion-propagation-policy: Foreground al objeto RootSync o RepoSync, como en el siguiente ejemplo:

# example-rootsync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: example-rootsync
  namespace: config-management-system
  annotations:
    configsync.gke.io/deletion-propagation-policy: Foreground
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: main
    dir: config-sync-quickstart/multirepo/root
    auth: none
    period: 30s

También puedes actualizar un RootSync o RepoSync para que use la propagación de la eliminación ejecutando el siguiente comando:

RootSync

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

Sustituye ROOTSYNC_NAME por el nombre del RootSync que quieras actualizar.

RepoSync

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

Sustituye REPOSYNC_NAME por el nombre del RepoSync que quieras actualizar.

Para inhabilitar la propagación de la eliminación, quita la anotación o cambia el valor a configsync.gke.io/deletion-propagation-policy: Orphan:

Nota: A partir de la versión 1.21.0, Config Sync deja de gestionar todos los objetos cuando se usa la política de propagación de eliminación Orphan. Antes de la versión 1.21.0, Config Sync anotaba los objetos como gestionados por el objeto RootSync o RepoSync eliminado. El nuevo comportamiento asegura que otros clientes puedan actualizar los objetos huérfanos o que un nuevo objeto RootSync o RepoSync pueda adoptarlos.

RootSync

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

Sustituye ROOTSYNC_NAME por el nombre del RootSync que quieras actualizar.

RepoSync

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

Propagar la eliminación de objetos

En este ejemplo se muestra cómo aplicar la propagación de la eliminación a un objeto RootSync o RepoSync y, a continuación, eliminar el objeto RootSync o RepoSync para eliminar todos los objetos que gestionaba.

Precaución: En el caso de los objetos RepoSync, no elimines el espacio de nombres en el que se encuentra el objeto RepoSync antes de que este termine de eliminarse. Si lo haces, es posible que se elimine RoleBinding antes de que se complete la propagación de la eliminación, lo que provocará un bloqueo que puede impedir la eliminación tanto de RepoSync como de Namespace.

RootSync

1. Aplica la anotación a un objeto RootSync para habilitar la propagación de la eliminación:

   kubectl patch RootSync example-rootsync \
     --namespace config-management-system \
     --type merge \
     --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
   

2. Elimina el objeto RootSync y espera a que Config Sync lo elimine:

   kubectl delete RootSync example-rootsync --namespace config-management-system --wait
   

   El proceso de eliminación de RootSync puede tardar unos minutos.

RepoSync

1. Aplica la anotación a un objeto RepoSync para habilitar la propagación de la eliminación:

   kubectl patch RepoSync example-reposync \
     --namespace example-namespace \
     --type merge \
     --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
   

2. Elimina el objeto RepoSync y espera a que Config Sync lo elimine:

   kubectl delete RepoSync example-reposync --namespace example-namespace --wait
   

   El proceso de eliminación de RepoSync puede tardar unos minutos en completarse.

Impedir la eliminación de objetos de Kubernetes

Después de eliminar un objeto de Kubernetes de un repositorio de Git gestionado por Config Sync, este objeto también se elimina del clúster cuando la nueva confirmación se sincroniza con el clúster.

Si quieres evitar que Config Sync elimine el objeto cuando se quite su configuración del repositorio de Git, puedes seguir estos pasos:

1. Añade la anotación client.lifecycle.config.k8s.io/deletion: detach a la configuración del objeto en el repositorio de Git.

2. Confirma e inserta el cambio en el repositorio de Git.

3. Espera a que el cambio se sincronice con el clúster.

Una vez que hayas completado estos pasos, Config Sync no eliminará este objeto del clúster cuando se quite su configuración del repositorio de Git, pero otros clientes sí podrán eliminarlo.

Ignorar un objeto en la fuente de información veraz

Puede que quieras que Config Sync ignore un objeto de tu fuente de información veraz. Por ejemplo, una configuración de función kpt nunca se debe aplicar al clúster.

En los objetos que quieras que ignore Config Sync, añade la anotación config.kubernetes.io/local-config: "true" al objeto. Después de añadir esta anotación, Config Sync ignora este objeto como si se hubiera quitado de la fuente de información veraz. Los recursos con la anotación local-config definida en cualquier valor que no sea "false" se tratan como si estuviera definida en "true" y se ignoran.