¿Qué es la aplicación del lado del servidor (SSA) de Kubernetes?

Server-Side Apply (SSA) ha estado disponible en general en Kubernetes desde el lanzamiento de v1.22 en agosto de 2021. Es una estrategia para la administración de recursos declarativa que mejora los cálculos de diferencias y advierte sobre conflictos de combinación al mover la lógica de la kubectl apply comando en el servidor.

Este artículo explicará cómo funciona SSA y por qué se prefiere al enfoque anterior de aplicación del lado del cliente (CSA). También aprenderá a habilitar SSA cuando realice cambios en los objetos de su clúster.

Comprender las actualizaciones declarativas

la kubectl apply El comando realiza actualizaciones declarativas de objetos. En lugar de indicarle a Kubernetes que modifique campos específicos, proporciona una representación completa del objeto como le gustaría que apareciera. El sistema calcula automáticamente las diferencias en comparación con el estado existente de su clúster. Luego llevará a cabo las acciones que transforman el estado en el estado deseado expresado por su archivo de manifiesto.

Aquí hay un manifiesto de Pod simple:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest

Correr kubectl apply con este manifiesto iniciará un nuevo Pod que ejecuta el nginx:latest imagen. La diferencia entre el estado actual del clúster y el deseado es clara: se ha creado un Pod, donde antes no lo había con el nginx nombre.

Luego, puede modificar el manifiesto cambiando una de las propiedades del pod:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.23

Esta vez la diferencia entre el estado existente y el deseado es menos sustancial. la kubectl apply el comando detectará la versión revisada image campo y actualice la configuración de su Pod en consecuencia.

Los problemas con la aplicación del lado del cliente

Diferenciar los cambios y resolver cualquier conflicto es la parte más importante de las actualizaciones declarativas. Este proceso se ejecuta dentro de Kubectl de forma predeterminada. El cliente es responsable de identificar el objeto existente en el servidor y comparar sus cambios.

la kubectl apply comando escribe un last-applied-configuration anotación en objetos para ayudar con este proceso. Permite la identificación de campos que existen en el objeto activo pero que se han eliminado del manifiesto entrante. El cliente entonces sabe que debe borrarlos del objeto para lograr el nuevo estado.

Este enfoque es problemático cuando hay varios agentes que actualizan el mismo objeto. Un solo objeto podría ser modificado tanto por Kubectl como por un controlador dedicado en su clúster, por ejemplo. La aplicación del lado del cliente no puede rastrear qué agente modificó un campo, ni puede comprender cuándo ocurre un conflicto. Simplemente compara su manifiesto local con el del objeto existente last-applied-configuration y se fusiona en cualquier cambio.

La aplicación del lado del cliente también está inherentemente ligada a Kubectl. Las herramientas de terceros que deseen realizar sus propias actualizaciones declarativas deben llamar a Kubectl o volver a crear el apply lógica desde cero. Ninguna de estas dos opciones es particularmente ideal.

Cómo funciona la aplicación del lado del servidor

El problema fundamental con CSA es que los manifiestos locales desactualizados nunca se detectan. Si otro aplicador cambia un objeto antes de ejecutar kubectl apply, sus revisiones locales antiguas pueden sobrescribir las nuevas correctas. Con SSA habilitado, se detectará el conflicto y se bloqueará la actualización. Es un sistema centralizado que exige que su estado local se mantenga actualizado.

SSA funciona agregando un mecanismo de plano de control que almacena información sobre cada campo en sus objetos. Reemplaza el last-applied-configuration anotación con una nueva metadata.managedFields campo. Cada campo en su objeto se rastrea dentro del managedFields.

A los campos se les asigna un "administrador de campos" que identifica al cliente que los posee. Si aplica un manifiesto con Kubectl, Kubectl será el administrador designado. El administrador de un campo también podría ser un controlador o una integración externa que actualice sus objetos.

Los administradores tienen prohibido actualizar los campos de los demás. No podrás cambiar un campo con kubectl apply si actualmente es propiedad de un controlador diferente. Hay tres estrategias disponibles para resolver estos conflictos de combinación:

• Forzar sobrescribir el valor – En algunas situaciones, es posible que desee forzar la actualización. Esto cambiará su valor y transferirá la propiedad al nuevo administrador de campo. Está destinado principalmente a los controladores que necesitan conservar la gestión de los campos que han rellenado. Puede forzar manualmente una actualización configurando el --force-conflicts bandera en Kubectl.
• No sobrescriba el valor – El aplicador puede eliminar el campo de su configuración local y luego repetir la solicitud. El campo conservará su valor existente. La eliminación del campo soluciona el conflicto al ceder la propiedad al administrador existente.
• Comparte la gestión – El aplicador puede actualizar su valor local para que coincida con el valor existente en el servidor. Si repite la solicitud mientras aún reclama la propiedad, la SSA le permitirá compartir la administración con el administrador existente. Esto se debe a que el aplicador acepta el estado actual del campo pero ha indicado que puede querer administrarlo en el futuro.

Este enfoque es mucho más poderoso que el tradicional. kubectl apply. Evita las sobrescrituras accidentales, permite que los controladores reclamen de manera confiable la propiedad de los campos que controlan y es totalmente declarativo. SSA rastrea cómo los diferentes usuarios han cambiado campos individuales, en lugar de solo registrar el último estado completo del objeto. También significa que ahora puede usar aplicar dentro de cualquier herramienta, independientemente del idioma o kubectl disponibilidad binaria. Obtendrá los mismos resultados consistentes independientemente de cómo inicie la operación.

Cómo usar SSA hoy

Puede activar SSA configurando el --server-side marca cada vez que ejecutas Kubectl apply:

$ kubectl apply -f nginx.yaml --server-side
pod/nginx serverside-applied

La salida del comando cambia para resaltar que se ha utilizado SSA.

Inspeccionar el manifiesto YAML del objeto revelará los campos administrados:

$ kubectl get pod nginx -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2022-11-24T16:02:29Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:spec:
        f:containers:
          k:{"name":"nginx"}:
            .: {}
            f:image: {}
            f:name: {}
    manager: kubectl
    operation: Apply
    time: "2022-11-24T16:02:29Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:status:
        f:conditions:
          k:{"type":"ContainersReady"}:
            .: {}
            f:lastProbeTime: {}
            f:lastTransitionTime: {}
            f:status: {}
            f:type: {}
          k:{"type":"Initialized"}:
            .: {}
            f:lastProbeTime: {}
            f:lastTransitionTime: {}
            f:status: {}
            f:type: {}
          k:{"type":"Ready"}:
            .: {}
            f:lastProbeTime: {}
            f:lastTransitionTime: {}
            f:status: {}
            f:type: {}
        f:containerStatuses: {}
        f:hostIP: {}
        f:phase: {}
        f:podIP: {}
        f:podIPs:
          .: {}
          k:{"ip":"10.244.0.186"}:
            .: {}
            f:ip: {}
        f:startTime: {}
    manager: kubelet
    operation: Update
    subresource: status
    time: "2022-11-24T16:02:31Z"
...

Los campos están agrupados por el administrador que los posee. En este ejemplo, spec es administrado por Kubectl porque así fue como se creó el Pod. la status Sin embargo, Kubelet administra el campo porque el nodo que ejecuta el pod cambia el valor de ese campo durante el ciclo de vida del pod.

SSA también está listo para usar en controladores. Permite una semántica más potente y nuevos tipos de controladores, incluidos los que reconstruyen objetos. Este modelo maneja los cambios reconstruyendo primero los campos de un objeto desde cero a satisfacción del controlador y luego aplicando el resultado al servidor. Es un método más natural que establecer manualmente la secuencia de operaciones que producirán un cambio deseado.

Comprobar si un objeto se gestiona con SSA

Puede verificar si un objeto usa CSA o SSA recuperando su manifiesto YAML en Kubectl:

$ kubectl get pod nginx -o yaml

si ves un last-applied-configuration anotación, su objeto es administrado por CSA:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"containers":[{"image":"nginx:latest","name":"nginx"}]}}
  creationTimestamp: "2022-11-24T14:20:07Z"
  name: nginx
  namespace: default
  ...
...

SSA se ha utilizado para el objeto si metadata.managedFields aparece en su lugar:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2022-11-24T16:02:29Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:spec:
        f:containers:
          k:{"name":"nginx"}:
            .: {}
            f:image: {}
            f:name: {}
    manager: kubectl
    operation: Apply
    time: "2022-11-24T16:02:29Z"
    ...
  ...
...

Puede mover un objeto entre CSA y SSA simplemente agregando u omitiendo el --server-side marcar la próxima vez que corras kubectl apply. Kubernetes gestiona la conversión de last-applied-configuration dentro managedFields y viceversa.

Las actualizaciones a SSA pueden presentar conflictos si su manifiesto local difiere del objeto en el servidor. Esto ocurre cuando ha ejecutado un comando imperativo como kubectl scale o kubectl label desde su última operación de aplicación contra el objeto. Debe verificar que su manifiesto local coincida con precisión con el objeto en vivo antes de convertirlo a SSA.

Resumen

La aplicación del lado del servidor es un enfoque para la gestión declarativa de objetos donde el plano de control de Kubernetes realiza un seguimiento de los campos. Esto facilita la detección robusta de conflictos y estrategias de resolución flexibles. SSA aborda las limitaciones de la aplicación del lado del cliente que permite que los campos se sobrescriban involuntariamente sin ninguna advertencia.

Aunque SSA ahora está generalmente disponible, todavía necesita especificarlo manualmente cada vez que ejecuta kubectl apply. Vale la pena tener en cuenta que SSA es más útil en situaciones en las que varios procesos diferentes administran objetos, como operadores humanos con Kubectl y un controlador de bucle. No se beneficiará mucho de la SSA si usa exclusivamente kubectl apply para crear y actualizar objetos.

Se espera que una versión futura de Kubernetes elimine CSA, lo que convierte a SSA en la única opción predeterminada. la --server-side entonces la bandera se volverá redundante.