Configura objetos de Kubernetes

Este tema muestra cómo crear archivos de configuración, los archivos que Anthos Config Management lee de Git y aplica a tus clústeres automáticamente.

Antes de comenzar

  • Asegúrate de comprender la estructura del repositorio. La ubicación de un archivo de configuración dentro del repositorio tiene incidencia respecto de 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.

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

  • Los diferentes 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.

  • Creamos un repositorio de ejemplo canónico para ilustrar cómo funciona Anthos Config Management. 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 el 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

La ubicación de un archivo de configuración en el repositorio es un factor 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 para los componentes de Anthos Config Management 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.

Configura objetos de Kubernetes existentes

Puede crear una configuración para un objeto de Kubernetes existente, como un espacio de nombres que ya existe en su clúster, antes de instalar Anthos Config Management. Sin embargo, este archivo de configuración se ignora, a menos que el objeto tenga la anotación configmanagement.gke.io/managed: enabled. Para un objeto existente, debes aplicar la anotación de forma manual.

Para los espacios de nombres específicamente, Anthos Config Management aplica configuraciones que crean nuevos objetos dentro de un espacio de nombres no anotado, y aplica la anotación configmanagement.gke.io/managed: enabled a esos objetos. Sin embargo, Anthos Config Management se niega a modificar o eliminar de un clúster cualquier objeto con permiso de clúster no anotado. Esto se ilustra en el diagrama de Trabaja con archivos de configuración a lo largo del tiempo.

Configura CustomResourceDefinitions

Anthos Config Management le permite sincronizar CustomResourceDefinitions (CRDs) de la misma manera que sincronizaría cualquier otro recurso. Cuando sincronizas CRD, debes tener en cuenta la siguiente información.

  • Los CRD, incluso al declarar un recurso personalizado con espacio de nombres, deben colocarse en el directorio cluster/.

  • Las actualizaciones de CRD y sus CustomResources correspondientes no ocurren en ningún orden predecible. Si modificas los CRD y los CustomResources correspondientes en la misma confirmación, no se espera que se lleven a cabo actualizaciones de CRD antes de las actualizaciones de los recursos personalizados. Esto puede provocar que los registros syncer informen un error transitorio durante un período breve, hasta que CustomResource y el CRD estén presentes en el clúster.

  • Anthos Config Management no permite la eliminación de un CRD si cualquier CustomResource en el repositorio depende de él. Para quitar un CRD, también debes quitar su CustomResource. Se recomienda quitar ambos en la misma confirmación al repositorio.

  • Puedes sincronizar un CustomResource sin sincronizar su CRD, siempre y cuando puedas garantizar que la CRD ya existe en el clúster.

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; Puede configurar cualquier tipo de objeto de Kubernetes utilizando Anthos Config Management.

Archivo de configuración del espacio de nombres

Esta configuración crea un espacio de nombres llamado audit.

apiVersion: v1
kind: Namespace
metadata:
  name: audit

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 shipping-prod si aún no existe o si no está administrado. El espacio de nombres tiene la etiqueta env: prod y la anotación audit: true. Si alguien modifica manualmente cualquiera de los metadatos del objeto, Anthos Config Management lo restablece rápidamente al valor del archivo de configuración.

apiVersion: v1
kind: Namespace
metadata:
  name: shipping-prod
  labels:
    env: prod
  annotations:
    audit: "true"

Para obtener más información sobre cómo trabajar con espacios de nombres, consulta Espacios de nombres y objetos con permisos de espacios de nombres.

Archivo de configuración de ClusterRole

Este archivo de configuración crea una ClusterRole llamada namespace-reader, que proporciona la capacidad de leer (obtener, ver y enumerar) todos los objetos de espacio de nombres del 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@foo-corp.com la ClusterRole namespace-reader.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: namespace-readers
subjects:
- kind: User
  name: cheryl@foo-corp.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 colocar 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 llamada psp, que impide la ejecución de contenedores con privilegios y permite que los contenedores se ejecuten como cualquier usuario válido del 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 colocar en directorios de espacios de nombres ni en espacios de nombres abstractos.

Archivo de configuración de NetworkPolicy

En este ejemplo, se crea un NetworkPolicy llamado 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, aísla a 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 la ubicas en un espacio de nombres abstracto con espacios de nombres descendientes, cada uno de esos espacios de nombres hereda la NetworkPolicy. En el repositorio de ejemplo, shipping-app-backend es un espacio de nombres abstracto que contiene archivos de configuración para shipping-dev, shipping-prod y shipping-stage. Si les agregas la NetworkPolicy del ejemplo anterior, cada uno hereda 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 mínimo privilegio a la seguridad. Por ejemplo, si la NetworkPolicy de ejemplo anterior se aplica a shipping-app-backend y la siguiente NetworkPolicy se agrega al espacio de nombres shipping-dev, el tráfico de entrada solo se permite a los pods en ese espacio de nombres con la etiqueta app:nginx. Los espacios de nombres shipping-prod y shipping-staging no se ven afectados por esta NetworkPolicy.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-nginx-ingress
spec:
  podSelector:
    matchLabels:
      app: nginx
  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 se deje de infringir la ResourceQuota.

¿Qué sigue?