Administra objetos de clúster existentes

Cuando Anthos Config Management gestiona un objeto de clúster, observa el objeto y el conjunto de opciones de configuración en el repositorio que afectan al objeto, y se asegura de que estén sincronizados. En este tema, se describe cómo comenzar a administrar un objeto existente y cómo dejar de administrar un objeto que, actualmente, sea administrado, sin borrarlo.

Descripción general

Anthos Config Management administra un objeto en un clúster si tiene la anotación configmanagement.gke.io/managed: enabled.

Si un objeto no tiene la etiqueta configmanagement.gke.io/managed, o si se configuró como algo diferente de enabled, el objeto no está administrado.

En el siguiente diagrama de flujo, se describen algunas situaciones que hacen que un objeto sea administrado o no administrado:

Cómo administrar o no administrar un objeto Kubernetes con Anthos Config Management

El gráfico contiene tres flujos separados: comenzar a administrar un objeto, detener la administración de un objeto y borrar un objeto administrado.

  1. Quiero administrar un objeto. a. ¿El objeto tiene una configuración en el repositorio?
    • Si la respuesta es No, crea un archivo de configuración para el objeto. Anthos Config Management establece la anotación configmanagement.gke.io/managed: enabled y comienza a administrar el objeto.
    • Si la respuesta es , ¿la configuración establece la anotación configmanagement.gke.io/managed: disabled?
      • Si la respuesta es No, el objeto se administra de forma predeterminada.
      • Si la respuesta es , edita la configuración para quitar la anotación configmanagement.gke.io/managed: disabled. Cuando el cambio se envía al repositorio de origen, Anthos Config Management lo detecta y aplica la anotación configmanagement.gke.io/managed: enabled y la configuración.
  2. Quiero dejar de administrar un objeto, pero no borrarlo.
    • Edita el archivo de configuración del objeto en el repositorio y configura la anotación configmanagement.gke.io/managed: disabled. Cuando se detecta el cambio en la configuración, Anthos Config Management deja de administrar el objeto.
  3. Quiero dejar de administrar y borrar un objeto.
    • Borra la configuración del objeto del repositorio. Cuando borras la configuración de un objeto que antes se administraba, Anthos Config Management borra el objeto de todos los clústeres y los espacios de nombres a los que se aplica la configuración.

Además de la anotación configmanagement.gke.io/managed: enabled, Anthos Config Management aplica la etiqueta app.kubernetes.io/managed-by: configmanagement.gke.io a todos los objetos que administra. Esta etiqueta te permite enumerar con facilidad todos los objetos mediante Anthos Config Management.

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

Anthos Config Management utiliza un modelo declarativo para aplicar cambios de configuración a sus clústeres mediante la lectura de la configuración deseada desde su repositorio. Si intenta aplicar la anotación manualmente (ya sea con el comando kubectl o la API de Kubernetes), Anthos Config Management anula el manual automáticamente con el contenido de su repositorio.

Antes de comenzar

Los siguientes ejemplos se basan en la guía de inicio rápido. Para continuar con los siguientes pasos, sigue la guía de inicio rápido y completa todos los pasos antes de examinar el clúster y el repositorio.

Enumera todos los objetos administrados

Para enumerar todos los objetos administrados por Anthos Config Management en un clúster o un espacio de nombres determinado, usa un selector de etiquetas como el siguiente:

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

Para enumerar todos los objetos no administrados por Anthos Config Management, use un selector de etiquetas como el siguiente:

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

Por ejemplo, mediante este comando, se enumeran los RoleBindings del espacio de nombres shipping-dev que administra Anthos Config Management:

kubectl get rolebindings -n shipping-dev \
    -l "app.kubernetes.io/managed-by=configmanagement.gke.io"
NAME           AGE
job-creators   12m
pod-creators   12m
sre-admin      12m
viewers        12m

Mediante este comando, se enumeran los RoleBindings en el espacio de nombres kube-system que no administra Anthos Config Management:

kubectl get rolebindings -n kube-system \
    -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"
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

Comienza a administrar un objeto existente

En este ejemplo, crea una función manualmente y, luego, comienza a administrarla con Anthos Config Management.

  1. Crea la función myrole en el espacio de nombres audit:

    kubectl create role -n audit myrole --verb=get --resource=pods
  2. Observa los permisos otorgados por la función myrole:

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

    La función solo tiene permiso para get pods.

  3. En este punto, la función existe en el clúster, pero Anthos Config Management no lo sabe.

    1. En una terminal, ve a la clonación local de tu repositorio.
    2. Usa el siguiente comando a fin de crear un manifiesto YAML para myrole y guárdalo en un archivo nuevo llamado namespaces/audit/myrole.yaml.

      kubectl get role myrole -n audit -o yaml > namespaces/audit/myrole.yaml
      
    3. Edita el archivo myrole.yaml.

      1. Quita todos los campos debajo de la clave metadata, excepto name y namespace.
      2. Agrega 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: audit
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - get
        - list
      
    4. Confirma el cambio en el repositorio.

    5. Espere unos minutos para que el Operador de administración de configuración se dé cuenta de la confirmación. Para verificar que la función myrole ahora sea administrada por Anthos Config Management, ejecute kubectl describe nuevamente.

      kubectl describe role myrole -n audit
      

Observa la anotación configmanagement.gke.io/managed: enabled, que indica que Anthos Config Management administra el objeto. Observa también las anotaciones que muestran la ruta y el nombre del archivo en el repositorio que causó el cambio de configuración más reciente del objeto, y el hash de Git que representa la confirmación.

Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
Annotations:  configmanagement.gke.io/cluster-name: example-cluster-name
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: namespaces/audit/myrole.yaml
              configmanagement.gke.io/token: 0836805a09f160f12aa934b9042527e7283c7030
PolicyRule:
Resources  Non-Resource URLs  Resource Names  Verbs
---------  -----------------  --------------  -----
pods       []                 []              [get list]

Deja de administrar un objeto administrado

Este ejemplo muestra cómo dejar de administrar un objeto que Anthos Config Management está administrando actualmente, como la función myrole en Comenzar a administrar un objeto existente.

  1. Edita el archivo namespaces/online/shipping-app-backend/shipping-dev/job-creator-rolebinding.yaml en el clon local de tu repositorio y agrega 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:
       name: job-creators
     subjects:
     - kind: User
       name: sam@foo-corp.com
       apiGroup: rbac.authorization.k8s.io
     roleRef:
       kind: Role
       name: job-creator
       apiGroup: rbac.authorization.k8s.io
     annotations:
       configmanagement.gke.io/managed: disabled
    

    Guarda el archivo.

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

  3. Espere unos minutos para que Anthos Config Management se dé cuenta y aplique la nueva confirmación.

  4. Utiliza el siguiente comando para enumerar todas las anotaciones en el RoleBinding job-creators. El resultado se trunca para facilitar la lectura.

    kubectl get rolebinding job-creators -n audit -o yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      annotations:
        configmanagement.gke.io/cluster-name: my-cluster
        configmanagement.gke.io/managed: disabled
        configmanagement.gke.io/source-path: namespaces/viewers-rolebinding.yaml
        configmanagement.gke.io/sync-token: fabdb51587d51a81c7e419eeb983aafcf293dc83
    ...
    

Después de comprobar que el objeto está inhabilitado, puedes quitar el archivo de configuración y verificar que el objeto no administrado no se borre del espacio de nombres. Si deseas volver a administrar el objeto, debes volver a crear su archivo de configuración. Por esta razón, recomendamos que dejes de administrar los objetos y que dejes sus archivos de configuración en el repositorio.

Ahora que el objeto no está administrado, no se crea ni se vuelve a crear en clústeres nuevos o existentes, y no se quita incluso si existe. Para reanudar la administración de un objeto que dejaste de administrar, consulta el siguiente ejemplo, Reanuda la administración de un objeto que dejaste de administrar.

Reanuda la administración de un objeto que dejaste de administrar

En este ejemplo, se muestra cómo reanudar la administración de un objeto que quitaste de la administración, como en Deja de administrar un objeto existente. Se da por sentado que no quitaste el archivo de configuración para el RoleBinding job-creators.

  1. Si borraste el RoleBinding job-creators de tu repositorio en la última confirmación, realiza los siguientes pasos.

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

      git revert HEAD~1
      

      Se te solicitará que confirmes la operación de reversión.

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

      git push
      
  2. Edita el archivo namespaces/online/shipping-app-backend/shipping-dev/job-creator-rolebinding.yaml en la clonación local del repositorio y quita la anotación configmanagement.gke.io/managed: disabled. Guarda el archivo.

  3. Confirma y envía el cambio. Anthos Config Management realiza las siguientes acciones:

    • Advierte el cambio.
    • Aplica la anotación configmanagement.gke.io/managed: enabled; el objeto ahora está administrado.
    • Aplica el archivo de configuración, como sucedería con cualquier objeto administrado.
  4. Para verificar si el objeto está administrado, crea una lista de sus anotaciones:

    kubectl get rolebinding job-creators -n audit -o yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      annotations:
        configmanagement.gke.io/cluster-name: my-cluster
        configmanagement.gke.io/managed: enabled
    ...
    

Deja de administrar un espacio de nombres

Puedes dejar de administrar un espacio de nombres de la misma manera en que dejas de administrar cualquier tipo de objeto. Si deseas dejar de administrar otros recursos dentro del espacio de nombres, sigue estos pasos:

  1. Agrega la anotación configmanagement.gke.io/managed:disabled al archivo de configuración del espacio de nombres y a todos los archivos de configuración en el mismo espacio de nombres.

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

  3. Borra los recursos no administrados del repositorio.

Si hay archivos de configuración administrados dentro de un directorio de espacio de nombres no administrado, el sincronizador registra errores, pero la sincronización de los otros archivos continúa con normalidad.

¿Qué sigue?