Це багатосторінковий друкований вигляд цього розділу. Натисність щоб друкувати.

Повернутися до звичайного перегляду сторінки.

Керування фоновими процесами кластера

Виконуйте загальні завдання для керування DaemonSet, такі як виконання поступового оновлення.

1: Виконання поетапного оновлення DaemonSet
2: Виконання відкату DaemonSet
3: Запуск Podʼів лише на деяких вузлах

1 - Виконання поетапного оновлення DaemonSet

Ця сторінка показує, як виконати поетапне оновлення (rolling update) DaemonSet.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Стратегія оновлення DaemonSet

DaemonSet має два типи стратегій оновлення:

OnDelete: Зі стратегією оновлення OnDelete, після оновлення шаблону DaemonSet нові Podʼи DaemonSet будуть створюватися лише після вручну видалених старих Podʼів DaemonSet. Це та ж поведінка, що й у версії Kubernetes 1.5 або раніше.
RollingUpdate: Це стандартна стратегія оновлення. Зі стратегією оновлення RollingUpdate, після оновлення шаблону DaemonSet старі Podʼи DaemonSet будуть видалені, і нові Podʼи DaemonSet будуть створені автоматично, у контрольованому режимі. Під час усього процесу оновлення на кожному вузлі працюватиме максимум один Pod DaemonSet.

Виконання поетапного оновлення

Щоб увімкнути функцію поетапного оновлення DaemonSet, необхідно встановити .spec.updateStrategy.type на RollingUpdate.

Ви можете також встановити значення .spec.updateStrategy.rollingUpdate.maxUnavailable (типово 1), .spec.minReadySeconds (типово 0) та .spec.updateStrategy.rollingUpdate.maxSurge (типово 0).

Створення DaemonSet зі стратегією оновлення `RollingUpdate`

Цей YAML файл задає DaemonSet зі стратегією оновлення RollingUpdate:

controllers/fluentd-daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # ці tolerations дозволяють запускати DaemonSet на вузлах панелі управління
      # видаліть їх, якщо ваші вузли панелі управління не повинні запускати Podʼи
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

Після перевірки стратегії оновлення в маніфесті DaemonSet, створіть DaemonSet:

kubectl create -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml

Або скористайтесь командою kubectl apply, щоб створити той самий DaemonSet, якщо ви плануєте оновлювати DaemonSet за допомогою kubectl apply.

kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml

Перевірка стратегії оновлення `RollingUpdate` у DaemonSet

Перевірте стратегію оновлення вашого DaemonSet і переконайтесь, що вона встановлена на RollingUpdate:

kubectl get ds/fluentd-elasticsearch -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' -n kube-system

Якщо ви ще не створили DaemonSet у системі, перевірте ваш маніфест DaemonSet за допомогою наступної команди:

kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'

Вивід обох команд повинен бути таким:

RollingUpdate

Якщо вивід не RollingUpdate, поверніться назад і змініть обʼєкт DaemonSet або його маніфест відповідно.

Оновлення шаблону DaemonSet

Будь-які оновлення до .spec.template RollingUpdate DaemonSet викличуть поетапне оновлення. Оновімо DaemonSet, застосувавши новий YAML файл. Це можна зробити за допомогою кількох різних команд kubectl.

controllers/fluentd-daemonset-update.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # ці tolerations дозволяють запускати DaemonSet на вузлах панелі управління
      # видаліть їх, якщо ваші вузли панелі управління не повинні запускати Podʼи
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

Декларативні команди

Якщо ви оновлюєте DaemonSets за допомогою конфігураційних файлів, використовуйте kubectl apply:

kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset-update.yaml

Імперативні команди

Якщо ви оновлюєте DaemonSets за допомогою імперативних команд, використовуйте kubectl edit :

kubectl edit ds/fluentd-elasticsearch -n kube-system

Оновлення лише образу контейнера

Якщо вам потрібно оновити лише образ контейнера у шаблоні DaemonSet, тобто .spec.template.spec.containers[*].image, використовуйте kubectl set image:

kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system

Спостереження за станом поетапного оновлення

Нарешті, спостерігайте за станом останнього поетапного оновлення DaemonSet:

kubectl rollout status ds/fluentd-elasticsearch -n kube-system

Коли оновлення завершиться, вивід буде подібний до цього:

daemonset "fluentd-elasticsearch" successfully rolled out

Усунення несправностей

Поетапне оновлення DaemonSet застрягло

Іноді поетапне оновлення DaemonSet може застрягнути. Ось деякі можливі причини:

Деякі вузли вичерпали ресурси

Оновлення застрягло, оскільки нові Podʼи DaemonSet не можуть бути заплановані на принаймні один вузол. Це можливо, коли вузол вичерпує ресурси.

Коли це трапляється, знайдіть вузли, на яких не заплановані Podʼи DaemonSet, порівнявши вихід kubectl get nodes з виходом:

kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system

Після того, як ви знайдете ці вузли, видаліть деякі не-DaemonSet Podʼи з вузла, щоб звільнити місце для нових Podʼіів DaemonSet.

Примітка:

Це викличе переривання обслуговування, коли видалені Podʼи не контролюються жодними контролерами або Podʼи не реплікуються. Це також не враховує PodDisruptionBudget.

Неправильне оновлення

Якщо недавнє оновлення шаблону DaemonSet є неправильним, наприклад, контейнер зациклюється або образ контейнера не існує (часто через помилку у назві), поетапне оновлення DaemonSet не просуватиметься.

Щоб виправити це, оновіть шаблон DaemonSet ще раз. Нове оновлення не буде блокуватися попередніми несправними оновленнями.

Невідповідність годинників

Якщо у DaemonSet задано значення .spec.minReadySeconds, невідповідність годинників між мастером та вузлами зробить DaemonSet нездатним визначити правильний прогрес оновлення.

Очищення

Видаліть DaemonSet з простору імен:

kubectl delete ds fluentd-elasticsearch -n kube-system

Що далі

2 - Виконання відкату DaemonSet

Ця сторінка показує, як виконати відкат на DaemonSet.

Перш ніж ви розпочнете

Версія вашого Kubernetes сервера має бути не старішою ніж 1.7. Для перевірки версії введіть kubectl version.

Ви повинні вже знати, як виконати поетапне оновлення на DaemonSet.

Виконання відкату на DaemonSet

Крок 1: Знайдіть ревізію DaemonSet, до якої ви хочете повернутися

Цей крок можна пропустити, якщо ви хочете повернутися до останньої ревізії.

Перегляньте всі ревізії DaemonSet:

kubectl rollout history daemonset <daemonset-name>

Це поверне список ревізій DaemonSet:

daemonsets "<daemonset-name>"
REVISION        CHANGE-CAUSE
1               ...
2               ...
...

Причина зміни копіюється з анотації DaemonSet kubernetes.io/change-cause до його ревізій під час створення. Ви можете вказати --record=true в kubectl, щоб записати команду, виконану в анотації причини зміни.

Щоб переглянути деталі конкретної ревізії:

kubectl rollout history daemonset <daemonset-name> --revision=1

Це поверне деталі цієї ревізії:

daemonsets "<daemonset-name>" with revision #1
Pod Template:
Labels:       foo=bar
Containers:
app:
 Image:        ...
 Port:         ...
 Environment:  ...
 Mounts:       ...
Volumes:      ...

Крок 2: Поверніться до конкретної ревізії DaemonSet

# Вкажіть номер ревізії, отриманий на кроці 1, у --to-revision
kubectl rollout undo daemonset <daemonset-name> --to-revision=<revision>

Якщо команда успішна, вона поверне:

daemonset "<daemonset-name>" rolled back

Примітка:

Якщо прапорець --to-revision не вказано, kubectl обирає найновішу ревізію.

Крок 3: Спостерігайте за процесом відкату DaemonSet

kubectl rollout undo daemonset вказує серверу почати відкочування DaemonSet. Реальний відкат виконується асинхронно всередині панелі управління кластера.

Щоб спостерігати за процесом відкату:

kubectl rollout status ds/<daemonset-name>

Коли відкочування завершиться, вивід буде подібним до цього:

daemonset "<daemonset-name>" successfully rolled out

Розуміння ревізій DaemonSet

У попередньому кроці kubectl rollout history ви отримали список ревізій DaemonSet. Кожна ревізія зберігається в ресурсі під назвою ControllerRevision.

Щоб побачити, що зберігається в кожній ревізії, знайдіть сирцеві ресурси ревізії DaemonSet:

kubectl get controllerrevision -l <daemonset-selector-key>=<daemonset-selector-value>

Це поверне список ControllerRevisions:

NAME                               CONTROLLER                     REVISION   AGE
<daemonset-name>-<revision-hash>   DaemonSet/<daemonset-name>     1          1h
<daemonset-name>-<revision-hash>   DaemonSet/<daemonset-name>     2          1h

Кожен ControllerRevision зберігає анотації та шаблон ревізії DaemonSet.

kubectl rollout undo бере конкретний ControllerRevision і замінює шаблон DaemonSet на шаблон, збережений у ControllerRevision. kubectl rollout undo еквівалентний оновленню шаблону DaemonSet до попередньої ревізії за допомогою інших команд, таких як kubectl edit або kubectl apply.

Примітка:

Ревізії DaemonSet завжди рухаються вперед. Тобто, після завершення відкату номер ревізії (поле .revision) ControllerRevision, до якого було виконано відкат, збільшиться. Наприклад, якщо у вас є ревізії 1 і 2 в системі, і ви повертаєтеся з ревізії 2 до ревізії 1, ControllerRevision з .revision: 1 стане .revision: 3.

Усунення несправностей

Див. усунення несправностей при поетапному оновленні DaemonSet.

3 - Запуск Podʼів лише на деяких вузлах

Ця сторінка демонструє, як можна запускати Podʼи лише на деяких вузлах як частину DaemonSet

Перш ніж ви розпочнете

Запуск Pod лише на деяких вузлах

Уявімо, що ви хочете запустити DaemonSet, але вам потрібно запускати ці Pod демонів лише на вузлах, які мають локальне SSD-сховище. Наприклад, Pod може надавати кеш-сервіс для вузла, і кеш корисний тільки тоді, коли доступне локальне сховище з низькою затримкою.

Крок 1: Додайте мітки до ваших вузлів

Додайте мітку ssd=true до вузлів, які мають SSD.

kubectl label nodes example-node-1 example-node-2 ssd=true

Крок 2: Створіть маніфест

Створімо DaemonSet, який буде запускати Podʼи демонів тільки на вузлах з міткою SSD.

Використайте nodeSelector, щоб забезпечити, що DaemonSet буде запускати Pod лише на вузлах з міткою ssd, значення якої дорівнює "true".

controllers/daemonset-label-selector.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ssd-driver
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: ssd-driver-pod
  template:
    metadata:
      labels:
        app: ssd-driver-pod
    spec:
      nodeSelector:
        ssd: "true"
      containers:
        - name: example-container
          image: example-image

Крок 3: Створіть DaemonSet

Створіть DaemonSet з маніфесту, використовуючи kubectl create або kubectl apply.

Додамо мітку ще одному вузлу ssd=true.

kubectl label nodes example-node-3 ssd=true

Додавання мітки вузлу автоматично запускає панель управління (конкретно, контролер DaemonSet), щоб запустити новий Pod для демона на цьому вузлі.

kubectl get pods -o wide

Вивід буде схожим на:

NAME                              READY     STATUS    RESTARTS   AGE    IP      NODE
<daemonset-name><some-hash-01>    1/1       Running   0          13s    .....   example-node-1
<daemonset-name><some-hash-02>    1/1       Running   0          13s    .....   example-node-2
<daemonset-name><some-hash-03>    1/1       Running   0          5s     .....   example-node-3

Керування фоновими процесами кластера

1 - Виконання поетапного оновлення DaemonSet

Перш ніж ви розпочнете

Стратегія оновлення DaemonSet

Виконання поетапного оновлення

Створення DaemonSet зі стратегією оновлення RollingUpdate

Перевірка стратегії оновлення RollingUpdate у DaemonSet

Оновлення шаблону DaemonSet

Декларативні команди

Імперативні команди

Оновлення лише образу контейнера

Спостереження за станом поетапного оновлення

Усунення несправностей

Поетапне оновлення DaemonSet застрягло

Деякі вузли вичерпали ресурси

Примітка:

Неправильне оновлення

Невідповідність годинників

Очищення

Що далі

2 - Виконання відкату DaemonSet

Перш ніж ви розпочнете

Виконання відкату на DaemonSet

Крок 1: Знайдіть ревізію DaemonSet, до якої ви хочете повернутися

Крок 2: Поверніться до конкретної ревізії DaemonSet

Примітка:

Крок 3: Спостерігайте за процесом відкату DaemonSet

Розуміння ревізій DaemonSet

Примітка:

Усунення несправностей

3 - Запуск Podʼів лише на деяких вузлах

Перш ніж ви розпочнете

Запуск Pod лише на деяких вузлах

Крок 1: Додайте мітки до ваших вузлів

Крок 2: Створіть маніфест

Крок 3: Створіть DaemonSet

Створення DaemonSet зі стратегією оновлення `RollingUpdate`

Перевірка стратегії оновлення `RollingUpdate` у DaemonSet