Qu’est-ce que Kubernetes Server-Side Apply (SSA) ?

Server-Side Apply (SSA) est généralement disponible dans Kubernetes depuis la version v1.22 en août 2021. Il s’agit d’une stratégie de gestion déclarative des ressources qui améliore les calculs de différences et avertit des conflits de fusion en déplaçant la logique du kubectl apply commande sur le serveur.

Cet article explique comment SSA fonctionne et pourquoi il est préféré à l’approche d’application côté client (CSA) précédente. Vous apprendrez également à activer SSA lorsque vous apportez des modifications aux objets de votre cluster.

Comprendre les mises à jour déclaratives

La kubectl apply La commande effectue des mises à jour déclaratives d’objets. Au lieu de demander à Kubernetes de modifier des champs spécifiques, vous fournissez une représentation complète de l’objet tel que vous souhaitez qu’il apparaisse. Le système calcule automatiquement les différences par rapport à l’état existant de votre cluster. Il effectuera ensuite les actions qui transforment l’état en l’état souhaité exprimé par votre fichier manifeste.

Voici un simple manifeste de pod :

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

Fonctionnement kubectl apply avec ce manifeste démarrera un nouveau pod qui exécute le nginx:latest image. La différence entre l’état existant du cluster et celui souhaité est claire : un Pod a été créé, là où il n’y en avait pas auparavant avec le nginx Nom.

Vous pouvez ensuite modifier le manifeste en modifiant l’une des propriétés du pod :

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

Cette fois, la différence entre l’état existant et celui souhaité est moins importante. La kubectl apply la commande détectera la version révisée image et mettez à jour la configuration de votre pod en conséquence.

Les problèmes avec l’application côté client

Différer les modifications et résoudre les conflits est la partie la plus importante des mises à jour déclaratives. Ce processus s’exécute par défaut dans Kubectl. Le client est chargé d’identifier l’objet existant sur le serveur et de comparer ses modifications.

La kubectl apply la commande écrit un last-applied-configuration annotation sur les objets pour faciliter ce processus. Il permet d’identifier les champs qui existent sur l’objet actif mais qui ont été supprimés du manifeste entrant. Le client sait alors les effacer de l’objet pour atteindre le nouvel état.

Cette approche est problématique lorsque plusieurs agents mettent à jour le même objet. Un seul objet peut être modifié à la fois par Kubectl et un contrôleur dédié dans votre cluster, par exemple. L’application côté client ne peut pas savoir quel agent a modifié un champ, ni savoir quand un conflit se produit. Il compare simplement votre manifeste local à celui de l’objet existant last-applied-configuration et fusionne dans tous les changements.

L’application côté client est également intrinsèquement liée à Kubectl. Les outils tiers qui souhaitent effectuer leurs propres mises à jour déclaratives doivent soit appeler Kubectl, soit recréer le apply logique à partir de zéro. Aucune de ces deux options n’est particulièrement idéale.

Fonctionnement de l’application côté serveur

Le problème fondamental avec CSA est que les manifestes locaux obsolètes ne sont jamais détectés. Si un autre applicateur modifie un objet avant que vous n’exécutiez kubectl apply, vos anciennes révisions locales peuvent écraser les nouvelles correctes. Avec SSA activé, le conflit sera détecté et la mise à jour sera bloquée. C’est un système centralisé qui veille à ce que votre état local soit tenu à jour.

SSA fonctionne en ajoutant un mécanisme de plan de contrôle qui stocke des informations sur chaque champ de vos objets. Il remplace le last-applied-configuration annotation avec un nouveau metadata.managedFields champ. Chaque champ de votre objet est suivi dans le managedFields.

Les champs sont attribués à un « gestionnaire de champs » qui identifie le client qui les possède. Si vous appliquez un manifeste avec Kubectl, alors Kubectl sera le gestionnaire désigné. Le gestionnaire d’un champ peut également être un contrôleur ou une intégration externe qui met à jour vos objets.

Il est interdit aux gestionnaires de mettre à jour les champs des autres. Vous ne pourrez pas modifier un champ avec kubectl apply s’il appartient actuellement à un autre contrôleur. Trois stratégies sont disponibles pour résoudre ces conflits de fusion :

• Forcer l’écrasement de la valeur – Dans certaines situations, vous voudrez peut-être forcer la mise à jour. Cela changera sa valeur et transférera la propriété au nouveau gestionnaire de terrain. Il est principalement destiné aux contrôleurs qui doivent conserver la gestion des champs qu’ils ont remplis. Vous pouvez forcer manuellement une mise à jour en définissant le --force-conflicts drapeau dans Kubectl.
• Ne pas écraser la valeur – L’applicateur peut supprimer le champ de sa configuration locale puis réitérer la demande. Le champ conservera sa valeur existante. La suppression du champ résout le conflit en cédant la propriété au gestionnaire existant.
• Partagez la gestion – L’applicateur peut mettre à jour sa valeur locale pour qu’elle corresponde à la valeur existante sur le serveur. S’il répète la demande tout en revendiquant la propriété, SSA lui permet de partager la gestion avec le gestionnaire existant. En effet, l’applicateur accepte l’état actuel du champ, mais a indiqué qu’il souhaiterait peut-être le gérer à l’avenir.

Cette approche est beaucoup plus puissante que la traditionnelle kubectl apply. Il empêche les écrasements accidentels, permet aux contrôleurs de revendiquer de manière fiable la propriété des champs qu’ils contrôlent et est entièrement déclaratif. SSA suit la façon dont différents utilisateurs ont modifié des champs individuels, au lieu d’enregistrer uniquement le dernier état complet de l’objet. Cela signifie également que vous pouvez désormais utiliser apply dans n’importe quel outil, quelle que soit la langue ou kubectl disponibilité binaire. Vous obtiendrez les mêmes résultats cohérents quelle que soit la façon dont vous lancez l’opération.

Utiliser SSA aujourd’hui

Vous pouvez activer SSA en définissant le --server-side flag chaque fois que vous exécutez Kubectl apply :

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

La sortie de la commande change pour mettre en évidence que SSA a été utilisé.

L’inspection du manifeste YAML de l’objet révèle les champs gérés :

$ 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"
...

Les champs sont regroupés par le gestionnaire qui les possède. Dans cet exemple, spec est géré par Kubectl car c’est ainsi que le Pod a été créé. La status Le champ est géré par Kubelet, cependant, car le nœud exécutant le pod modifie la valeur de ce champ pendant le cycle de vie du pod.

SSA est également prêt à être utilisé dans les contrôleurs. Il permet une sémantique plus puissante et de nouveaux types de contrôleurs, y compris ceux qui reconstruisent des objets. Ce modèle gère les modifications en reconstruisant d’abord les champs d’un objet à partir de zéro à la satisfaction du contrôleur, puis en appliquant le résultat au serveur. C’est une méthode plus naturelle que d’établir manuellement la séquence d’opérations qui produira le changement souhaité.

Vérifier si un objet est géré avec SSA

Vous pouvez vérifier si un objet utilise CSA ou SSA en récupérant son manifeste YAML dans Kubectl :

$ kubectl get pod nginx -o yaml

Si vous voyez un last-applied-configuration annotation, votre objet est géré par 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 a été utilisé pour l’objet si metadata.managedFields apparaît à la place :

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"
    ...
  ...
...

Vous pouvez déplacer un objet entre CSA et SSA en ajoutant ou en omettant simplement le --server-side signaler la prochaine fois que vous courez kubectl apply. Kubernetes gère la conversion de last-applied-configuration dans managedFields et vice versa.

Les mises à niveau vers SSA peuvent présenter des conflits si votre manifeste local diffère de l’objet sur le serveur. Cela se produit lorsque vous avez exécuté une commande impérative telle que kubectl scale ou kubectl label depuis votre dernière opération d’application sur l’objet. Vous devez vérifier que votre manifeste local correspond exactement à l’objet actif avant de convertir en SSA.

Sommaire

L’application côté serveur est une approche de la gestion déclarative des objets dans laquelle les champs sont suivis par le plan de contrôle Kubernetes. Cela facilite une détection robuste des conflits et des stratégies de résolution flexibles. SSA résout les limitations de l’application côté client qui permettent aux champs d’être écrasés par inadvertance sans aucun avertissement.

Bien que SSA soit désormais généralement disponible, vous devez toujours le spécifier manuellement à chaque fois que vous exécutez kubectl apply. Il convient de garder à l’esprit que SSA est particulièrement utile dans les situations où les objets sont gérés par plusieurs processus différents, tels que des opérateurs humains avec Kubectl et une boucle de contrôleur. Vous ne bénéficierez pas beaucoup de SSA si vous utilisez exclusivement kubectl apply pour créer et mettre à jour des objets.

Une future version de Kubernetes devrait supprimer CSA, faisant de SSA la seule option par défaut. La --server-side flag deviendra alors redondant.