Configurar objetos de Kubernetes

En este tema, se muestra cómo crear archivos de configuración, los archivos que el Sincronizador de configuración lee de Git y que aplica de forma automática a los clústeres.

Antes de comenzar

  • Necesitas una comprensión básica de la sintaxis de YAML o JSON, ya que los archivos de configuración están escritos en uno de estos dos formatos. En todos los ejemplos de esta documentación, se usan YAML, ya que es más fácil de leer.

  • Los distintos tipos de objetos de Kubernetes tienen diferentes opciones configurables. Es útil comprender cómo lograrías la configuración deseada de forma manual antes de escribir un archivo de configuración para ese tipo de objeto.

  • Si eliges un repositorio jerárquico, asegúrate de comprender la estructura del repositorio jerárquico. La ubicación de un archivo de configuración dentro del repositorio afecta a qué clústeres y espacios de nombres se aplica. Esto es de gran importancia para el directorio namespaces/, ya que los subdirectorios del directorio namespaces/ pueden heredar los archivos de configuración de sus directorios de espacio de nombres abstractos.

  • Creamos un repositorio de ejemplo canónico para ilustrar cómo funciona el Sincronizador de configuración. Tiene varios ejemplos, incluidos formato no estructurado y formato jerárquico ,modo de recuperación múltiple y modo de no recuperación múltiple, repositorio raíz y repositorios de espacios de nombres.

    Los ejemplos de este tema provienen de ese repositorio, por lo que puede resultarte útil tener el repositorio abierto en un navegador o clonarlo en tu sistema local.

Crea una configuración

Cuando creas un archivo de configuración, debes decidir la mejor ubicación en el repositorio y los campos que deseas incluir.

Ubicación en el repositorio

  • En el caso de los repositorios no estructurados, puedes organizar los archivos de configuración de manera arbitraria y crear subcarpetas de recursos.

  • Para los repositorios jerárquicos, la ubicación de un archivo de configuración en el repositorio es uno de los factores que determina a qué clústeres se aplica:

    • Los archivos de configuración para objetos con permisos de clúster, excepto los espacios de nombres, se almacenan en el directorio cluster/ del repositorio.
    • Los archivos de configuración para espacios de nombres y objetos con permisos de espacios de nombres se almacenan en el directorio namespaces/ del repositorio.
    • Los archivos de configuración del Sincronizador de configuración se almacenan en el directorio system/ del repositorio.
    • Los archivos de configuración para el Operador de Config Management no se almacenan directamente en el repositorio y no se sincronizan.

Contenido del archivo de configuración

Los archivos de configuración usan un enfoque aditivo, similar a kubectl. Cuando creas objetos nuevos, debes incluir todos los campos obligatorios. Sin embargo, cuando actualizas los objetos existentes, solo debes proporcionar los campos que necesitas actualizar.

El archivo de configuración, cuando se aplica, debe dar como resultado un objeto de Kubernetes válido.

Archivos de configuración de ejemplo

Los siguientes archivos de configuración de ejemplo se toman del repositorio de ejemplo y te ayudarán a comenzar a escribir tus propios archivos de configuración. Esta lista no es exhaustiva; puedes configurar cualquier tipo de objeto de Kubernetes con el Sincronizador de configuración.

Archivo de configuración del espacio de nombres

Este archivo de configuración crea un espacio de nombres llamado gamestore.

apiVersion: v1
kind: Namespace
metadata:
  name: gamestore

Cuando creas un archivo de configuración de espacio de nombres, también puedes agregar etiquetas o anotaciones al espacio de nombres. Las etiquetas son obligatorias cuando se usa un NamespaceSelector.

En el siguiente archivo de configuración de ejemplo, se crea un espacio de nombres llamado gamestore si aún no existe o si no está administrado. El espacio de nombres tiene la etiqueta app: gamestore y la anotación retail: true. Si alguien modifica alguno de los metadatos del objeto de forma manual, el Sincronizador de configuración lo restablece con rapidez al valor del archivo de configuración.

apiVersion: v1
kind: Namespace
metadata:
  name: gamestore
  labels:
    app: gamestore
  annotations:
    retail: "true"

Para obtener más información sobre cómo trabajar con los espacios de nombres, consulta Configura espacios de nombres y objetos con permiso de espacio de nombres.

Archivo de configuración de ClusterRole

Con esta configuración, se crea una ClusterRole llamado namespace-reader, que proporciona la capacidad de leer (obtener, visualizar y enumerar) todos los objetos namespace en el clúster. Un archivo de configuración de ClusterRole suele usarse junto con un archivo de configuración de ClusterRoleBinding.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: namespace-reader
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]

Archivo de configuración de ClusterRoleBinding

Este archivo de configuración crea una ClusterRoleBinding llamada namespace-readers, que otorga al usuario cheryl@example.com la ClusterRole namespace-reader.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: namespace-readers
subjects:
- kind: User
  name: cheryl@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: namespace-reader
  apiGroup: rbac.authorization.k8s.io

Las ClusterRoleBindings tienen permisos de clúster y no se pueden ubicar en directorios de espacios de nombres ni en espacios de nombres abstractos.

Archivo de configuración de PodSecurityPolicy

En este ejemplo, se crea una PodSecurityPolicy llamado psp, que impide la ejecución de contenedores con privilegios y permite que los contenedores se ejecuten como cualquier usuario válido en el nodo.

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

Las PodSecurityPolicies tienen permisos de clúster y no se pueden ubicar en directorios de espacios de nombres ni en espacios de nombres abstractos.

Archivo de configuración de NetworkPolicy

En este ejemplo, se crea una NetworkPolicy llamada default-deny-all-traffic.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny-all-traffic
spec:
  podSelector: {}

Las NetworkPolicies tienen permisos de espacio de nombres y solo se pueden ubicar en directorios de espacio de nombres o en espacios de nombres abstractos.

Cuando aplicas la NetworkPolicy anterior a un solo espacio de nombres, se aíslan los Pods de ese espacio de nombres del tráfico de entrada y salida.

Cuando aplicas la misma NetworkPolicy a varios espacios de nombres y los ubicas en un espacio de nombres abstracto con espacios de nombres descendientes, cada uno hereda la NetworkPolicy. En el repositorio de ejemplo de espacio de nombres, el directorio namespaces contiene dos espacios de nombres abstractos, eng y rnd, y cada espacio de nombres abstracto contiene dos espacios de nombres reales, analytics y gamestore, incubator-1 y incubator-2, respectivamente. Si agregas la NetworkPolicy default-deny-all-traffic anterior a los espacios de nombres abstractos, los cuatro espacios de nombres reales heredan la NetworkPolicy, por lo que cada uno de sus pods está protegido contra el tráfico de entrada y salida.

Puedes usar la herencia del espacio de nombres para aplicar un enfoque de privilegio mínimo a la seguridad. Por ejemplo, si la NetworkPolicy de ejemplo anterior se aplica a ambos espacios de nombres abstractos y la siguiente NetworkPolicy se agrega al espacio de nombres abstracto eng, el tráfico de entrada solo se permite a los pods en los espacios de nombres descendientes con la etiqueta app:gamestore Los espacios de nombres analytics, incubator-1 y incubator-2 no se ven afectados por esta NetworkPolicy.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-gamestore-ingress
spec:
  podSelector:
    matchLabels:
      app: gamestore
  ingress:
  - {}

Archivo de configuración de ResourceQuota

En este ejemplo, se crea una ResourceQuota llamada quota, que establece un límite estricto de 1 pod, 100 miliCPU y 100 mebibytes (Mi) de memoria.

kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
spec:
  hard:
    pods: "1"
    cpu: "100m"
    memory: "100Mi"

Si la creación de un objeto nuevo de un tipo determinado infringe una ResourceQuota existente, Kubernetes no podrá crear ese objeto hasta que deje de infringir la ResourceQuota.

Archivo de configuración de RepoSync

En este ejemplo, se crea un objeto RepoSync en el repositorio raíz, que se sincroniza desde un repositorio de espacio de nombres. Para obtener más información sobre cómo configurar el objeto RepoSync, consulta Configura la sincronización desde repositorios de espacios de nombres.

apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: repo-sync
  namespace: gamestore
spec:
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: main
    dir: quickstart/multirepo/namespaces/gamestore
    auth: none

El Sincronizador de configuración crea un conciliador de espacio de nombres para sincronizarse desde el repositorio del espacio de nombres.

¿Qué sigue?