Поиск по сайту:

Что такое Kubernetes Server-Side Application (SSA)?


Server-Side Apply (SSA) общедоступен в Kubernetes с момента выпуска версии 1.22 в августе 2021 года. Это стратегия декларативного управления ресурсами, которая улучшает вычисления различий и предупреждает о конфликтах слияния, перемещая логику применения kubectl. на сервер.

В этой статье объясняется, как работает SSA и почему он предпочтительнее предыдущего подхода с применением на стороне клиента (CSA). Вы также узнаете, как включить SSA при внесении изменений в объекты в кластере.

Понимание декларативных обновлений

Команда kubectl apply выполняет декларативные обновления объектов. Вместо того, чтобы указывать Kubernetes изменять определенные поля, вы предоставляете полное представление объекта, как вы хотите, чтобы он отображался. Система автоматически вычисляет различия по сравнению с существующим состоянием вашего кластера. Затем он выполнит действия, которые преобразуют состояние в желаемое состояние, выраженное в вашем файле манифеста.

Вот простой манифест пода:

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

Запуск kubectl apply с этим манифестом запустит новый модуль, который запускает образ nginx:latest. Разница между существующим состоянием кластера и желаемым очевидна: создан под, которого раньше не было с именем nginx.

Затем вы можете изменить манифест, изменив одно из свойств пода:

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

На этот раз разница между существующим состоянием и желаемым менее существенна. Команда kubectl apply обнаружит исправленное поле image и соответствующим образом обновит конфигурацию вашего модуля.

Проблемы с применением на стороне клиента

Различение изменений и разрешение любых конфликтов — самая важная часть декларативных обновлений. Этот процесс выполняется в Kubectl по умолчанию. Клиент отвечает за идентификацию существующего объекта на сервере и сравнение его изменений.

Команда kubectl apply записывает аннотацию last-applied-configuration на объекты, чтобы облегчить этот процесс. Это позволяет идентифицировать поля, которые существуют в активном объекте, но которые были удалены из входящего манифеста. Затем клиент знает, что нужно очистить их от объекта, чтобы достичь нового состояния.

Этот подход проблематичен, когда несколько агентов обновляют один и тот же объект. Например, один объект может быть изменен как Kubectl, так и выделенным контроллером в вашем кластере. Приложение на стороне клиента не может отследить, какой агент изменил поле, и не может понять, когда возникает конфликт. Он просто сравнивает ваш локальный манифест с last-applied-configuration существующего объекта и объединяет любые изменения.

Применение на стороне клиента также неотъемлемо связано с Kubectl. Сторонние инструменты, которые хотят делать свои собственные декларативные обновления, должны либо обращаться к Kubectl, либо воссоздавать логику apply с нуля. Ни один из этих двух вариантов не является особенно идеальным.

Как работает приложение на стороне сервера

Фундаментальная проблема с CSA заключается в том, что устаревшие локальные манифесты никогда не обнаруживаются. Если другое приложение изменит объект до того, как вы запустите kubectl apply, ваши старые локальные версии могут перезаписать правильные новые. При включенном SSA конфликт будет обнаружен, и обновление будет заблокировано. Это централизованная система, которая обеспечивает актуальность вашего локального состояния.

SSA работает, добавляя механизм уровня управления, который хранит информацию о каждом поле в ваших объектах. Он заменяет аннотацию last-applied-configuration новым полем metadata.managedFields. Каждое поле в вашем объекте отслеживается в managedFields.

Полям назначается «менеджер полей», который идентифицирует клиента, которому они принадлежат. Если вы применяете манифест с Kubectl, то Kubectl будет назначенным менеджером. Менеджер поля также может быть контроллером или внешней интеграцией, которая обновляет ваши объекты.

Менеджерам запрещено обновлять поля друг друга. Вам будет запрещено изменять поле с помощью kubectl apply, если оно в настоящее время принадлежит другому контроллеру. Для разрешения этих конфликтов слияния доступны три стратегии:

  • Принудительно перезаписать значение. В некоторых ситуациях может потребоваться принудительное обновление. Это изменит его значение и передаст право собственности новому полевому менеджеру. Он в основном предназначен для контроллеров, которым необходимо сохранить управление заполненными полями. Вы можете принудительно выполнить обновление вручную, установив флаг --force-conflicts в Kubectl.
  • Не перезаписывать значение. Пользователь может удалить поле из своей локальной конфигурации, а затем повторить запрос. Поле сохранит свое существующее значение. Удаление поля устраняет конфликт, передавая право собственности существующему менеджеру.
  • Общий доступ к управлению. Приложение может обновить свое локальное значение, чтобы оно соответствовало существующему значению на сервере. Если он повторяет запрос, все еще заявляя о праве собственности, SSA позволит ему разделить управление с существующим менеджером. Это связано с тем, что применяющий принимает текущее состояние поля, но указал, что может захотеть управлять им в будущем.

Этот подход намного мощнее, чем традиционный kubectl apply. Он предотвращает случайную перезапись, позволяет контроллерам надежно заявлять права собственности на поля, которыми они управляют, и является полностью декларативным. SSA отслеживает, как разные пользователи изменяли отдельные поля, а не только записывает все последнее состояние объекта. Это также означает, что теперь вы можете использовать apply внутри любого инструмента, независимо от языка или наличия бинарного файла kubectl. Вы получите одинаковые стабильные результаты, как бы вы ни начали операцию.

Использование SSA сегодня

Вы можете активировать SSA, устанавливая флаг --server-side каждый раз, когда запускаете Kubectl apply:

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

Выходные данные команды изменятся, чтобы подчеркнуть, что SSA использовался.

Проверка YAML-манифеста объекта покажет управляемые поля:

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

Поля группируются по управляющему, которому они принадлежат. В этом примере spec управляется Kubectl, потому что именно так был создан Pod. Однако поле status управляется Kubelet, поскольку узел, на котором запущен модуль, меняет значение этого поля в течение жизненного цикла модуля.

SSA также готов к использованию в контроллерах. Он обеспечивает более мощную семантику и новые типы контроллеров, в том числе те, которые реконструируют объекты. Эта модель обрабатывает изменения, сначала перестраивая поля объекта с нуля в соответствии с требованиями контроллера, а затем применяя результат обратно на сервер. Это более естественный метод, чем установление вручную последовательности операций, которая приведет к желаемому изменению.

Проверка того, управляется ли объект с помощью SSA

Вы можете проверить, использует ли объект CSA или SSA, получив его манифест YAML в Kubectl:

$ kubectl get pod nginx -o yaml

Если вы видите аннотацию last-applied-configuration, ваш объект управляется 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 использовался для объекта, если вместо него отображается metadata.managedFields:

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

Вы можете перемещать объект между CSA и SSA, просто добавляя или опуская флаг --server-side при следующем запуске kubectl apply. Kubernetes обрабатывает преобразование last-applied-configuration в managedFields и наоборот.

Обновление до SSA может вызвать конфликты, если ваш локальный манифест отличается от объекта на сервере. Это происходит, когда вы запускаете императивную команду, такую как kubectl scale или kubectl label, с момента последней операции применения к объекту. Вы должны убедиться, что ваш локальный манифест точно соответствует живому объекту перед преобразованием в SSA.

Краткое содержание

Применение на стороне сервера — это подход к декларативному управлению объектами, при котором поля отслеживаются плоскостью управления Kubernetes. Это способствует надежному обнаружению конфликтов и гибким стратегиям разрешения. SSA устраняет ограничения применения на стороне клиента, которые позволяют непреднамеренно перезаписывать поля без предупреждения.

Хотя SSA теперь общедоступен, вам по-прежнему необходимо указывать его вручную каждый раз при запуске kubectl apply. Стоит иметь в виду, что SSA наиболее полезен в ситуациях, когда объекты управляются несколькими разными процессами, такими как операторы-люди с Kubectl и цикл контроллера. Вы не получите много пользы от SSA, если будете использовать kubectl apply исключительно для создания и обновления объектов.

Ожидается, что в будущем выпуске Kubernetes CSA будет удален, что сделает SSA единственным вариантом по умолчанию. После этого флаг --server-side станет излишним.




Все права защищены. © Linux-Console.net • 2019-2024