Co to jest Kubernetes Server-Side Apply (SSA)?

Server-Side Apply (SSA) jest ogólnie dostępne w Kubernetes od wersji 1.22 w sierpniu 2021 r. Jest to deklaratywna strategia zarządzania zasobami, która poprawia obliczenia różnic i ostrzega przed konfliktami scalania, przesuwając logikę kubectl apply zamówienie na serwerze.

W tym artykule wyjaśniono, jak działa SSA i dlaczego jest preferowany w stosunku do poprzedniego podejścia do aplikacji po stronie klienta (CSA). Dowiesz się również, jak włączyć SSA podczas wprowadzania zmian w obiektach w klastrze.

Zrozumienie aktualizacji deklaratywnych

La kubectl apply Polecenie wykonuje deklaratywne aktualizacje obiektów. Zamiast prosić Kubernetes o modyfikację określonych pól, zapewniasz pełną reprezentację obiektu tak, jak chcesz, aby wyglądał. System automatycznie oblicza różnice w stosunku do istniejącego stanu Twojego klastra. Następnie wykona działania, które przekształcą stan w pożądany stan wyrażony przez twój plik manifestu.

Oto prosty manifest pod:

Wersja api: v1
uprzejmy: Strąk
metadanych:
  Nazwa: nginx
specyfikacja:
  Pojemniki:
    - Nazwa: nginx
      obraz: nginx: najnowsze

operacja kubectl apply z tym manifestem uruchomi nową kapsułę, która uruchomi plik nginx:latest obraz. Różnica między istniejącym stanem klastra a pożądanym jest wyraźna: został utworzony Pod, którego wcześniej nie było z nginx Nie m.

Następnie możesz edytować manifest, modyfikując jedną z właściwości pod:

Wersja api: v1
uprzejmy: Strąk
metadanych:
  Nazwa: nginx
specyfikacja:
  Pojemniki:
    - Nazwa: nginx
      obraz: nginx: 1.23

Tym razem różnica między stanem istniejącym a stanem pożądanym jest mniej znacząca. The kubectl apply polecenie wykryje poprawioną wersję image i odpowiednio zaktualizuj konfigurację poda.

Problemy z aplikacją po stronie klienta

Odraczanie zmian i rozwiązywanie konfliktów to najważniejsza część aktualizacji deklaratywnych. Ten proces jest domyślnie uruchamiany w Kubectl. Klient jest odpowiedzialny za identyfikację istniejącego obiektu na serwerze i porównanie jego zmian.

La kubectl apply polecenie pisze a last-applied-configuration adnotacje na przedmiotach ułatwiające ten proces. Identyfikuje pola, które istnieją w aktywnym obiekcie, ale zostały usunięte z przychodzącego manifestu. Klient wie wtedy, jak usunąć je z obiektu, aby osiągnąć nowy stan.

Takie podejście jest problematyczne, gdy wielu agentów aktualizuje ten sam obiekt. Na przykład pojedynczy obiekt może być modyfikowany zarówno przez Kubectl, jak i dedykowany kontroler w twoim klastrze. Aplikacja po stronie klienta nie może wiedzieć, który agent zmodyfikował pole, ani wiedzieć, kiedy wystąpił konflikt. Po prostu porównuje twój lokalny manifest z manifestem istniejącego obiektu last-applied-configuration i łączy się we wszystkich zmianach.

Aplikacja po stronie klienta jest również nierozerwalnie powiązana z Kubectl. Narzędzia innych firm, które chcą przeprowadzać własne deklaratywne aktualizacje, muszą wywołać Kubectl lub odtworzyć plik apply Logika od podstaw. Żadna z tych dwóch opcji nie jest szczególnie idealna.

Działanie aplikacji po stronie serwera

Podstawowy problem z CSA polega na tym, że przestarzałe manifesty lokalne nigdy nie są wykrywane. Jeśli inny aplikator zmodyfikuje obiekt przed uruchomieniem kubectl apply, stare wersje lokalne mogą zastąpić nowe, poprawne. Po włączeniu SSA konflikt zostanie wykryty, a aktualizacja zostanie zablokowana. Jest to scentralizowany system, który zapewnia aktualność stanu lokalnego.

SSA działa poprzez dodanie mechanizmu płaszczyzny kontrolnej, który przechowuje informacje o każdym polu twoich obiektów. Zastępuje last-applied-configuration adnotacja z nowym metadata.managedFields pole. Każde pole twojego obiektu jest śledzone w managedFields.

Pola są przypisane do „kierownika pola”, który identyfikuje klienta, który jest ich właścicielem. Jeśli zastosujesz manifest za pomocą Kubectl, to Kubectl będzie wyznaczonym modułem obsługi. Program obsługi pola może być również zewnętrznym kontrolerem lub integracją aktualizującą obiekty.

Menedżerom nie wolno aktualizować pól innych osób. Nie będziesz mógł edytować pola za pomocą kubectl apply jeśli jest obecnie własnością innego kontrolera. Dostępne są trzy strategie rozwiązywania tych konfliktów scalania:

• Wymuś nadpisanie wartości – W niektórych sytuacjach możesz chcieć wymusić aktualizację. Spowoduje to zmianę jego wartości i przeniesienie własności na nowego zarządcę gruntu. Jest przeznaczony głównie dla administratorów, którzy muszą zachować zarządzanie polami, które wypełnili. Możesz ręcznie wymusić aktualizację, ustawiając plik --force-conflicts flaga w Kubectlu.
• Nie nadpisuj wartości – Implementator może usunąć pole z jego lokalnej konfiguracji, a następnie powtórzyć żądanie. Pole zachowa swoją dotychczasową wartość. Usunięcie pola rozwiązuje konflikt przez przekazanie własności istniejącemu menedżerowi.
• Zarządzanie udziałami – Moduł egzekwujący może zaktualizować swoją wartość lokalną, aby odpowiadała istniejącej wartości na serwerze. Jeśli powtórzy żądanie podczas zgłaszania własności, SSA pozwoli mu dzielić zarządzanie z obecnym menedżerem. Dzieje się tak dlatego, że aplikator akceptuje obecny stan pola, ale zasygnalizował, że może chcieć nim zarządzać w przyszłości.

To podejście jest znacznie potężniejsze niż tradycyjne kubectl apply. Zapobiega przypadkowym nadpisaniom, umożliwia kontrolerom niezawodne zgłaszanie praw własności do kontrolowanych przez nich pól i jest w pełni deklaratywny. SSA śledzi, jak różni użytkownicy zmieniali poszczególne pola, zamiast rejestrować tylko ostatni pełny stan obiektu. Oznacza to również, że możesz teraz używać aplikacji w dowolnym narzędziu, niezależnie od języka lub kubectl dostępność binarna. Otrzymasz te same spójne wyniki bez względu na to, jak zainicjujesz operację.

Skorzystaj z SSA już dziś

Możesz włączyć SSA, ustawiając --server-side flaga za każdym razem, gdy uruchamiasz Kubectl Apply:

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

Dane wyjściowe polecenia zmieniają się, aby pokazać, że użyto SSA.

Sprawdzenie manifestu YAML obiektu ujawnia obsługiwane pola:

$ kubectl get pod nginx -o yaml apiVersion: v1 rodzaj: Pod metadane: createTimestamp: "2022-11-24T16:02:29Z" ManagedFields: - apiVersion: v1 FieldsType: FieldsV1 FieldsV1: f:spec: f:containers: k: {"name":"nginx"}: .: {} f:image: {} f:name: {} manager: kubectl operacja: czas zastosowania: "2022-11-24T16:02:29Z" - apiVersion: v1 typ pól : PolaV1 polaV1: f:status: f:warunki: k:{"type":"ContainersReady"}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} k:{"type":"Initialized"}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} k:{"type":" Gotowe"}: .: {} 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 operacja: aktualizacja zasób podrzędny: czas stanu: „2022-11-24T16:02:31Z” ...

Pola są pogrupowane według menedżera, który jest ich właścicielem. w tym przykładzie spec jest zarządzany przez Kubectl, ponieważ tak powstał Pod. The status Pole jest jednak zarządzane przez Kubelet, ponieważ węzeł, na którym działa kapsuła, zmienia wartość tego pola w trakcie cyklu życia kapsuły.

SSA jest również gotowy do użycia w kontrolerach. Pozwala na potężniejszą semantykę i nowe typy kontrolerów, w tym te, które rekonstruują obiekty. Ten model obsługuje zmiany, najpierw rekonstruując pola obiektu od podstaw do zadowolenia kontrolera, a następnie stosując wynik na serwerze. Jest to metoda bardziej naturalna niż ręczne ustalanie sekwencji operacji, które doprowadzą do pożądanej zmiany.

Sprawdź, czy obiekt jest zarządzany za pomocą SSA

Możesz sprawdzić, czy obiekt używa CSA lub SSA, pobierając jego manifest YAML w Kubectl:

$ kubectl pobierz pod nginx -o yaml

Jeśli zobaczysz last-applied-configuration adnotacja, twoim obiektem zarządza CSA:

Wersja api: v1
uprzejmy: Strąk
metadanych:
  adnotacje:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadane":{"annotations":{},"name":"nginx","namespace":"default"},"spec": {"containers":[{"image":"nginx:najnowsze","name":"nginx"}]}}
  znacznik czasu tworzenia: "2022-11-24T14:20:07Z"
  Nazwa: nginx
  przestrzeń nazw: domyślnym
  ...
...

SSA został użyty dla obiektu if metadata.managedFields zamiast tego pojawia się:

Wersja api: v1
uprzejmy: Strąk
metadanych:
  znacznik czasu tworzenia: "2022-11-24T16:02:29Z"
  zarządzane pola:
  - wersja API: v1
    typ pól: PolaV1
    polaV1:
      f: spec:
        f:kontenery:
          k:{"nazwa":"nginx"}:
            .: {}
            f: obraz: {}
            f: imię: {}
    kierownik: kubectl
    działanie: Aplikuj
    czas: "2022-11-24T16:02:29Z"
    ...
  ...
...

Możesz przenieść obiekt między CSA i SSA, po prostu dodając lub pomijając --server-side zgłoś się następnym razem, gdy będziesz biegać kubectl apply. Kubernetes zarządza konwersją last-applied-configuration do managedFields i wzajemnie.

Uaktualnienia do SSA mogą powodować konflikty, jeśli manifest lokalny różni się od obiektu na serwerze. Dzieje się tak, gdy uruchomisz imperatywne polecenie, takie jak kubectl scale ou kubectl label od ostatniej operacji zastosowania na obiekcie. Przed konwersją na SSA należy sprawdzić, czy lokalny manifest dokładnie pasuje do aktywnego obiektu.

streszczenie

Aplikacja po stronie serwera to deklaratywne podejście do zarządzania obiektami, w którym pola są śledzone przez platformę kontrolną Kubernetes. Ułatwia to solidne wykrywanie konfliktów i elastyczne strategie rozwiązywania. SSA rozwiązuje ograniczenia aplikacji po stronie klienta, które umożliwiają przypadkowe nadpisanie pól bez żadnego ostrzeżenia.

Chociaż SSA jest teraz ogólnie dostępny, nadal musisz go ręcznie określać przy każdym uruchomieniu kubectl apply. Należy pamiętać, że SSA jest szczególnie przydatne w sytuacjach, w których obiektami zarządza kilka różnych procesów, takich jak operatorzy z Kubectl i pętla kontrolera. Nie skorzystasz wiele z SSA, jeśli będziesz używać wyłącznie kubectl apply tworzyć i aktualizować obiekty.

Przyszła wersja Kubernetes powinna usunąć CSA, czyniąc SSA jedyną domyślną opcją. The --server-side wtedy flaga stanie się zbędna.