Управління робочими навантаженнями

Ви розгорнули ваш застосунок та експонували його через Service. Що далі? Kubernetes надає ряд інструментів для допомоги в управлінні розгортанням вашого застосунку, включаючи масштабування та оновлення.

Організація конфігурацій ресурсів

Багато застосунків потребують створення кількох ресурсів, таких як Deployment разом із Service. Управління кількома ресурсами можна спростити, обʼєднавши їх в одному файлі (розділеному --- у YAML). Наприклад:

application/nginx-app.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Кілька ресурсів можна створити так само як і один ресурс:

kubectl apply -f https://k8s.io/examples/application/nginx-app.yaml

service/my-nginx-svc created
deployment.apps/my-nginx created

Ресурси будуть створені в порядку, в якому вони зʼявляються в маніфесті. Тому краще спочатку вказати Service, оскільки це забезпечить, що планувальник зможе розподілити повʼязані з Service podʼи в процесі їх створення контролером(ами), таким як Deployment.

kubectl apply також приймає кілька аргументів -f:

kubectl apply -f https://k8s.io/examples/application/nginx/nginx-svc.yaml \
  -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml

Рекомендовано розміщувати ресурси, повʼязані з одним мікросервісом або рівнем застосунку, в одному файлі та групувати всі файли, повʼязані з вашим застосунком, в одній теці. Якщо рівні вашого застосунку звʼязуються один з одним за допомогою DNS, ви можете розгорнути всі компоненти вашого стека разом.

Також можна вказати URL як джерело конфігурації, що зручно для розгортання безпосередньо з маніфестів у вашій системі контролю версій:

kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml

deployment.apps/my-nginx created

Якщо потрібно визначити більше маніфестів, наприклад, додати ConfigMap, це також можна зробити.

Зовнішні інструменти

У цьому розділі перераховані лише найпоширеніші інструменти, які використовуються для керування навантаженнями в Kubernetes. Щоб переглянути більше інструментів, подивіться Application definition and image build в CNCF Landscape.

Helm

Helm — це інструмент для управління пакетами попередньо налаштованих ресурсів Kubernetes. Ці пакети відомі як Helm чарти.

Kustomize

Kustomize проходить по маніфестах Kubernetes, щоб додати, видалити або оновити конфігураційні опції. Він доступний як окремий бінарний файл і як вбудована функція kubectl.

Пакетні операції в kubectl

Створення ресурсів — не єдина операція, яку kubectl може виконувати в пакетному режимі. Він також може витягувати імена ресурсів з конфігураційних файлів для виконання інших операцій, зокрема для видалення тих же ресурсів, які ви створили:

kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml

deployment.apps "my-nginx" deleted
service "my-nginx-svc" deleted

У випадку з двома ресурсами ви можете вказати обидва ресурси в командному рядку, використовуючи синтаксис resource/name:

kubectl delete deployments/my-nginx services/my-nginx-svc

Для більшої кількості ресурсів буде зручніше вказати селектор (запит на мітку), використовуючи -l або --selector, щоб відфільтрувати ресурси за їхніми мітками:

kubectl delete deployment,services -l app=nginx

deployment.apps "my-nginx" deleted
service "my-nginx-svc" deleted

Ланцюги та фільтрація

Оскільки kubectl виводить імена ресурсів у тому ж синтаксисі, який він приймає, ви можете робити ланцюги операції, використовуючи $() або xargs:

kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service/ )
kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service/ | xargs -i kubectl get '{}'

Вивід може бути подібний до:

NAME           TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)      AGE
my-nginx-svc   LoadBalancer   10.0.0.208   <pending>     80/TCP       0s

Використовуючи вище наведенні команди, спочатку ви створюєте ресурси в examples/application/nginx/ і виводите створені ресурси у форматі виводу -o name (виводите кожен ресурс як resource/name). Потім ви виконуєте grep для вибору Service, а потім виводите його за допомогою kubectl get.

Рекурсивні операції з локальними файлами

Якщо ви організували ваші ресурси в кількох підтеках всередині певної теки, ви можете рекурсивно виконувати операції з ними, вказавши --recursive або -R разом з аргументом --filename/-f.

Наприклад, припустимо, є тека project/k8s/development, яка містить усі маніфести необхідні для середовища розробки, організовані за типом ресурсу:

project/k8s/development
├── configmap
│   └── my-configmap.yaml
├── deployment
│   └── my-deployment.yaml
└── pvc
    └── my-pvc.yaml

Стандартно, виконання пакетної операції для project/k8s/development зупиниться на першому рівні теки, не обробляючи жодних вкладених тек. Якщо ви спробували б створити ресурси з цієї теки, використовуючи наступну команду, ви б отримали помилку:

kubectl apply -f project/k8s/development

error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin)

Замість цього, вкажіть аргумент командного рядка --recursive або -R разом з аргументом --filename/-f:

kubectl apply -f project/k8s/development --recursive

configmap/my-config created
deployment.apps/my-deployment created
persistentvolumeclaim/my-pvc created

Аргумент --recursive працює з будь-якою операцією, яка приймає аргумент --filename/-f, такою як: kubectl create, kubectl get, kubectl delete, kubectl describe, або навіть kubectl rollout.

Аргумент --recursive також працює, коли вказані кілька аргументів -f:

kubectl apply -f project/k8s/namespaces -f project/k8s/development --recursive

namespace/development created
namespace/staging created
configmap/my-config created
deployment.apps/my-deployment created
persistentvolumeclaim/my-pvc created

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

Оновлення застосунку без перебоїв у роботі

В якийсь момент вам, ймовірно, доведеться оновити ваш розгорнутий застосунок, зазвичай шляхом зазначення нового образу чи теґу образу. kubectl підтримує кілька операцій оновлення, кожна з яких застосовується до різних сценаріїв.

Ви можете запускати кілька копій вашого застосунку і використовувати rollout для поступового перенаправлення трафіку до нових справних Podʼів. З часом всі запущені Podʼи отримають нове програмне забезпечення.

Цей розділ сторінки проводить вас через процес створення та оновлення застосунків за допомогою Deployments.

Припустимо, ви запускали версію 1.14.2 nginx:

kubectl create deployment my-nginx --image=nginx:1.14.2

deployment.apps/my-nginx created

Переконайтеся, що є 1 репліка:

kubectl scale --replicas 1 deployments/my-nginx --subresource='scale' --type='merge' -p '{"spec":{"replicas": 1}}'

deployment.apps/my-nginx scaled

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

kubectl patch --type='merge' -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge": "100%" }}}}'

deployment.apps/my-nginx patched

Щоб оновитись до версії 1.16.1, змініть .spec.template.spec.containers[0].image з nginx:1.14.2 на nginx:1.16.1, використовуючи kubectl edit:

kubectl edit deployment/my-nginx
# Змініть маніфест на використання новішого образу контейнера, потім збережіть зміни

Ось і все! Deployment оновить розгорнутий застосунок з nginx прогресивно за лаштунками. Він забезпечує, що лише певна кількість старих реплік може бути недоступною під час оновлення, і лише певна кількість нових реплік може бути створена понад бажану кількість podʼів. Щоб дізнатися більше деталей про те, як це відбувається, відвідайте Deployment.

Ви можете використовувати rollouts з DaemonSets, Deployments або StatefulSets.

Управління Rollouts

Ви можете використовувати kubectl rollout для управління прогресивним оновленням поточного застосунку.

Наприклад:

kubectl apply -f my-deployment.yaml

# дочекайтеся завершення rollout
kubectl rollout status deployment/my-deployment --timeout 10m # тайм-аут 10 хвилин

або

kubectl apply -f backing-stateful-component.yaml

# не чекайте завершення rollout, просто перевірте статус
kubectl rollout status statefulsets/backing-stateful-component --watch=false

Ви також можете призупиняти, відновлювати або скасовувати rollout. Відвідайте kubectl rollout для отримання додаткової інформації.

Canary Deployment

Ще один сценарій, коли потрібні кілька міток, це відрізнення розгортання різних версій або конфігурацій одного й того ж компонента. Загальною практикою є розгортання canary нової версії застосунку (зазначеної через теґ образу в шаблоні podʼа) поруч з попередньою версією, щоб нова версія могла отримати реальний трафік перед повним розгортанням.

Наприклад, можна використовувати мітку track для розрізнення різних версій.

Основна, стабільна версія буде мати мітку track зі значенням stable:

name: frontend
replicas: 3
...
labels:
   app: guestbook
   tier: frontend
   track: stable
...
image: gb-frontend:v3

А потім ви можете створити нову версію фронтенду для guestbook, яка має мітку track з іншим значенням (тобто canary), так що два набори podʼів не перетинатимуться:

name: frontend-canary
replicas: 1
...
labels:
   app: guestbook
   tier: frontend
   track: canary
...
image: gb-frontend:v4

Сервіс фронтенду охоплюватиме обидва набори реплік, вибираючи загальну підмножину їх міток (тобто пропускаючи мітку track), так що трафік буде перенаправлено на обидва застосунки:

selector:
   app: guestbook
   tier: frontend

Ви можете налаштувати кількість реплік стабільних і canary версій, щоб визначити відношення кожного розгортання, яке отримає реальний трафік (в цьому випадку, 3:1). Коли ви будете впевнені, що нова версія стабільна, ви можете оновити стабільний трек до нової версії застосунку і видалити canary версію.

Оновлення анотацій

Іноді ви захочете додати анотації до ресурсів. Анотації є довільними метаданими, що не є ідентифікаційними, для отримання API клієнтами, такими як інструменти або бібліотеки. Це можна зробити за допомогою kubectl annotate. Наприклад:

kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
kubectl get pods my-nginx-v4-9gw19 -o yaml

apiVersion: v1
kind: pod
metadata:
  annotations:
    description: my frontend running nginx
...

Для отримання додаткової інформації дивіться анотації та kubectl annotate.

Масштабування вашого застосунку

Коли навантаження на ваш застосунок зростає або зменшується, використовуйте kubectl, щоб масштабувати ваш застосунок. Наприклад, щоб зменшити кількість реплік nginx з 3 до 1, виконайте:

kubectl scale deployment/my-nginx --replicas=1

deployment.apps/my-nginx scaled

Тепер у вас буде тільки один pod, яким управляє deployment.

kubectl get pods -l app=nginx

NAME                        READY     STATUS    RESTARTS   AGE
my-nginx-2035384211-j5fhi   1/1       Running   0          30m

Щоб система автоматично вибирала кількість реплік nginx в межах від 1 до 3, виконайте:

# Це вимагає існуючого джерела метрик контейнера і Pod
kubectl autoscale deployment/my-nginx --min=1 --max=3

horizontalpodautoscaler.autoscaling/my-nginx autoscaled

Тепер ваші репліки nginx будуть масштабуватися вгору і вниз за потреби автоматично.

Для отримання додаткової інформації перегляньте kubectl scale, kubectl autoscale і horizontal pod autoscaler.

Оновлення ресурсів на місці

Іноді необхідно вносити вузькі оновлення до ресурсів які ви створили, не порушуючи роботи.

kubectl apply

Рекомендується підтримувати набір конфігураційних файлів у системі контролю версій (див. конфігурація як код), щоб їх можна було підтримувати та версіонувати разом з кодом для ресурсів, які вони конфігурують. Тоді ви можете використовувати kubectl apply для того, щоб надіслати зміни конфігурації в кластер.

Ця команда порівнює версію конфігурації, яку ви надсилаєте, з попередньою версією та застосовує внесені вами зміни, не перезаписуючи зміни властивостей, що відбулись автоматичні, які ви не вказали.

kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml

deployment.apps/my-nginx configured

Щоб дізнатися більше про механізм, що лежить в основі, прочитайте server-side apply.

kubectl edit

Альтернативно, ви також можете оновлювати ресурси за допомогою kubectl edit:

kubectl edit deployment/my-nginx

Це еквівалентно спочатку отриманню get ресурсу, редагуванню його в текстовому редакторі, а потім apply ресурсу з оновленою версією:

kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml
vi /tmp/nginx.yaml
# зробіть деякі редагування, а потім збережіть файл

kubectl apply -f /tmp/nginx.yaml
deployment.apps/my-nginx configured

rm /tmp/nginx.yaml

Це дозволяє легше вносити більш значні зміни. Зверніть увагу, що ви можете вказати редактор за допомогою змінних середовища EDITOR або KUBE_EDITOR.

Для отримання додаткової інформації дивіться kubectl edit.

kubectl patch

Ви можете використовувати kubectl patch для оновлення API обʼєктів на місці. Ця підкоманда підтримує JSON patch, JSON merge patch і стратегічний merge patch.

Дивіться Оновлення API обʼєктів на місці за допомогою kubectl patch для отримання додаткових деталей.

Оновлення, що порушують стабільність

В деяких випадках може знадобитися оновити поля ресурсу, які не можна оновити після його ініціалізації, або може знадобитися зробити рекурсивну зміну негайно, наприклад, щоб виправити пошкоджені podʼи, створені Deployment. Для зміни таких полів використовуйте replace --force, що видаляє і перезапускає ресурс. У цьому випадку ви можете змінити ваш оригінальний конфігураційний файл:

kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force

deployment.apps/my-nginx deleted
deployment.apps/my-nginx replaced

Що далі

• Дізнайтеся, як використовувати kubectl для інспекції застосунків та налагодження.