Name: Tremplin Numérique
Price range: $$$

Server-Side Apply (SSA) ist in Kubernetes seit v1.22 im August 2021 allgemein verfügbar. Es handelt sich um eine deklarative Ressourcenverwaltungsstrategie, die Differenzberechnungen verbessert und vor Merge-Konflikten warnt, indem sie die Logik von verschiebt kubectl apply Bestellung auf dem Server.

In diesem Artikel wird erläutert, wie SSA funktioniert und warum es gegenüber dem vorherigen clientseitigen Anwendungsansatz (CSA) bevorzugt wird. Außerdem erfahren Sie, wie Sie SSA aktivieren, wenn Sie Änderungen an Objekten in Ihrem Cluster vornehmen.

Zusammenfassung

Grundlegendes zu deklarativen Updates

La kubectl apply Der Befehl führt deklarative Aktualisierungen an Objekten durch. Anstatt Kubernetes aufzufordern, bestimmte Felder zu ändern, stellen Sie eine vollständige Darstellung des Objekts so bereit, wie es angezeigt werden soll. Das System errechnet automatisch die Differenzen zum bestehenden Stand Ihres Clusters. Es führt dann die Aktionen aus, die den Status in den gewünschten Status umwandeln, der durch Ihre Manifestdatei ausgedrückt wird.

Hier ist ein einfaches Pod-Manifest:

apiVersion: v1
Art: Schote
Metadaten:
  Name: 
spec:
  Behälter:
    - Name: 
      Image: nginx: neueste

Funktionsweise kubectl apply Mit diesem Manifest wird ein neuer Pod gestartet, der die ausführt nginx:latest Bild. Der Unterschied zwischen dem bestehenden Zustand des Clusters und dem gewünschten ist klar: Es wurde ein Pod geschaffen, wo es vorher keinen gab nginx Nom.

Anschließend können Sie das Manifest bearbeiten, indem Sie eine der Pod-Eigenschaften ändern:

apiVersion: v1
Art: Schote
Metadaten:
  Name: 
spec:
  Behälter:
    - Name: 
      Image: nginx:1.23

Diesmal ist der Unterschied zwischen dem Ist-Zustand und dem Soll-Zustand weniger signifikant. Das kubectl apply Der Befehl erkennt die überarbeitete Version image und aktualisieren Sie Ihre Pod-Konfiguration entsprechend.

Probleme mit der clientseitigen Anwendung

Das Zurückstellen von Änderungen und das Auflösen von Konflikten ist der wichtigste Teil deklarativer Aktualisierungen. Dieser Prozess wird standardmäßig in Kubectl ausgeführt. Der Client ist dafür verantwortlich, das vorhandene Objekt auf dem Server zu identifizieren und seine Änderungen zu vergleichen.

La kubectl apply Der Befehl schreibt a last-applied-configuration Anmerkungen zu Objekten, um diesen Prozess zu erleichtern. Es identifiziert Felder, die auf dem aktiven Objekt vorhanden sind, aber aus dem eingehenden Manifest entfernt wurden. Der Client weiß dann, wie er sie aus dem Objekt löschen muss, um den neuen Zustand zu erreichen.

Dieser Ansatz ist problematisch, wenn mehrere Agenten dasselbe Objekt aktualisieren. Ein einzelnes Objekt kann beispielsweise sowohl von Kubectl als auch von einem dedizierten Controller in Ihrem Cluster geändert werden. Die clientseitige Anwendung kann weder wissen, welcher Agent ein Feld geändert hat, noch wissen, wann ein Konflikt auftritt. Es vergleicht lediglich Ihr lokales Manifest mit dem des vorhandenen Objekts last-applied-configuration und fügt alle Änderungen ein.

Die clientseitige Anwendung ist auch untrennbar mit Kubectl verbunden. Tools von Drittanbietern, die ihre eigenen deklarativen Aktualisierungen durchführen möchten, müssen entweder Kubectl aufrufen oder die neu erstellen apply Logik von Grund auf. Keine dieser beiden Optionen ist besonders ideal.

Serverseitiger Anwendungsbetrieb

Das grundlegende Problem mit CSA besteht darin, dass veraltete lokale Manifeste niemals erkannt werden. Wenn ein anderer Applikator ein Objekt modifiziert, bevor Sie es ausführen kubectl apply, können Ihre alten lokalen Revisionen die korrekten neuen überschreiben. Bei aktiviertem SSA wird der Konflikt erkannt und die Aktualisierung blockiert. Es ist ein zentralisiertes System, das sicherstellt, dass Ihr lokaler Staat auf dem neuesten Stand gehalten wird.

SSA funktioniert durch Hinzufügen eines Steuerungsebenenmechanismus, der Informationen zu jedem Feld Ihrer Objekte speichert. Es ersetzt die last-applied-configuration Anmerkung mit einem neuen metadata.managedFields aufstellen. Jedes Feld Ihres Objekts wird im verfolgt managedFields.

Felder werden einem „Feldmanager“ zugewiesen, der den Kunden identifiziert, dem sie gehören. Wenn Sie ein Manifest mit Kubectl anwenden, ist Kubectl der designierte Handler. Der Handler eines Felds kann auch ein externer Controller oder eine Integration sein, die Ihre Objekte aktualisiert.

Managern ist es untersagt, die Felder anderer Personen zu aktualisieren. Sie können ein Feld nicht mit ändern kubectl apply wenn es derzeit einem anderen Controller gehört. Drei Strategien sind verfügbar, um diese Zusammenführungskonflikte zu lösen:

Überschreiben des Wertes erzwingen – In manchen Situationen möchten Sie vielleicht die Aktualisierung erzwingen. Dies wird seinen Wert ändern und das Eigentum an den neuen Landverwalter übertragen. Es ist hauptsächlich für Controller gedacht, die die Verwaltung der von ihnen ausgefüllten Felder behalten müssen. Sie können eine Aktualisierung manuell erzwingen, indem Sie die --force-conflicts Flagge in Kubectl.
Wert nicht überschreiben – Der Implementierer kann das Feld aus seiner lokalen Konfiguration entfernen und dann die Anfrage wiederholen. Das Feld behält seinen vorhandenen Wert. Durch das Löschen des Felds wird der Konflikt gelöst, indem dem vorhandenen Manager die Eigentümerschaft übertragen wird.
Aktienverwaltung – Der Enforcer kann seinen lokalen Wert aktualisieren, damit er mit dem vorhandenen Wert auf dem Server übereinstimmt. Wenn er die Anfrage wiederholt, während er das Eigentum beansprucht, erlaubt ihm SSA, die Verwaltung mit dem bestehenden Manager zu teilen. Dies liegt daran, dass der Antragsteller den aktuellen Status des Felds akzeptiert, aber angegeben hat, dass er es möglicherweise in Zukunft verwalten möchte.

Dieser Ansatz ist viel leistungsfähiger als der traditionelle kubectl apply. Es verhindert versehentliches Überschreiben, ermöglicht es Controllern, zuverlässig den Besitz der von ihnen kontrollierten Felder zu beanspruchen, und ist vollständig deklarativ. SSA verfolgt, wie verschiedene Benutzer einzelne Felder geändert haben, anstatt nur den letzten vollständigen Zustand des Objekts aufzuzeichnen. Das bedeutet auch, dass Sie sich jetzt in jedem Tool bewerben können, unabhängig von der Sprache oder kubectl binäre Verfügbarkeit. Sie erhalten die gleichen konsistenten Ergebnisse, unabhängig davon, wie Sie die Operation einleiten.

Verwenden Sie SSA noch heute

Sie können SSA aktivieren, indem Sie die --server-side Flag jedes Mal, wenn Sie Kubectl ausführen, gelten:

$ kubectl apply -f nginx.yaml --serverseitiger Pod/nginx serverseitig angewendet

Die Befehlsausgabe ändert sich, um anzuzeigen, dass SSA verwendet wurde.

Beim Überprüfen des YAML-Manifests des Objekts werden die unterstützten Felder angezeigt:

$ 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 Unterressource: Statuszeit: "2022-11-24T16:02:31Z" ...

Felder werden nach dem Manager gruppiert, dem sie gehören. In diesem Beispiel spec wird von Kubectl verwaltet, da der Pod so erstellt wurde. Das status Das Feld wird jedoch von Kubelet verwaltet, da der Knoten, auf dem der Pod ausgeführt wird, den Wert dieses Felds während des Lebenszyklus des Pods ändert.

SSA ist auch bereit für den Einsatz in Steuerungen. Es ermöglicht eine leistungsfähigere Semantik und neue Arten von Controllern, einschließlich solcher, die Objekte rekonstruieren. Dieses Modell handhabt Änderungen, indem es zuerst die Felder eines Objekts von Grund auf zur Zufriedenheit des Controllers rekonstruiert und dann das Ergebnis auf den Server anwendet. Dies ist eine natürlichere Methode als das manuelle Festlegen der Abfolge von Vorgängen, die die gewünschte Änderung bewirken.

Überprüfen Sie, ob ein Objekt mit SSA verwaltet wird

Sie können überprüfen, ob ein Objekt CSA oder SSA verwendet, indem Sie sein YAML-Manifest in Kubectl abrufen:

$ kubectl get pod nginx -o yaml

Wenn du ein siehst last-applied-configuration Anmerkung, Ihr Objekt wird von CSA verwaltet:

apiVersion: v1
Art: Schote
Metadaten:
  Anmerkungen:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec": {"Container":[{"image":"nginx:latest","name":"nginx"}]}}
  Erstellungszeitstempel: "2022-11-24T14:20:07Z"
  Name: 
  Namensraum: Standard
  ...
...

SSA wurde für das Objekt if verwendet metadata.managedFields erscheint stattdessen:

apiVersion: v1
Art: Schote
Metadaten:
  Erstellungszeitstempel: "2022-11-24T16:02:29Z"
  ManagedFields:
  - apiVersion: v1
    FelderTyp: FelderV1
    FelderV1:
      f:spez:
        f:Container:
          k:{"name":"nginx"}:
            .: {}
            f: Bild: {}
            f:Name: {}
    Manager: kubectl
    Betrieb: Jetzt bewerben
    Zeit: "2022-11-24T16:02:29Z"
    ...
  ...
...

Sie können ein Objekt zwischen CSA und SSA verschieben, indem Sie einfach hinzufügen oder weglassen --server-side melde dich beim nächsten Lauf kubectl apply. Kubernetes verwaltet die Konvertierung von last-applied-configuration in managedFields und umgekehrt.

Bei Upgrades auf SSA können Konflikte auftreten, wenn sich Ihr lokales Manifest von dem Objekt auf dem Server unterscheidet. Dies geschieht, wenn Sie einen zwingenden Befehl wie ausgeführt haben kubectl scale ou kubectl label seit Ihrer letzten Anwendung auf das Objekt. Sie sollten überprüfen, ob Ihr lokales Manifest genau mit dem aktiven Objekt übereinstimmt, bevor Sie in SSA konvertieren.

Zusammenfassung

Die serverseitige Anwendung ist ein deklarativer Objektverwaltungsansatz, bei dem Felder von der Kubernetes-Steuerungsebene nachverfolgt werden. Dies ermöglicht eine robuste Konflikterkennung und flexible Lösungsstrategien. SSA adressiert clientseitige Anwendungsbeschränkungen, die ein unbeabsichtigtes Überschreiben von Feldern ohne Vorwarnung ermöglichen.

Obwohl SSA jetzt allgemein verfügbar ist, müssen Sie es immer noch bei jeder Ausführung manuell angeben kubectl apply. Denken Sie daran, dass SSA besonders in Situationen nützlich ist, in denen Objekte von mehreren verschiedenen Prozessen verwaltet werden, z. B. menschliche Operatoren mit Kubectl und einer Controller-Schleife. Sie werden nicht viel von SSA profitieren, wenn Sie ausschließlich verwenden kubectl apply um Objekte zu erstellen und zu aktualisieren.

Eine zukünftige Version von Kubernetes sollte CSA entfernen, sodass SSA die einzige Standardoption ist. Das --server-side Flag wird dann überflüssig.