Розгортання в Azure Kubernetes Service

Мова: Українська

Цю статтю перекладено з англійської за допомогою ШІ, тому вона може містити помилки. Ваші відгуки допоможуть нам її покращити.

У цьому посібнику описано, як розгорнути автономний сервер ActivityInfo в Azure Kubernetes Service (AKS) на керованому диску Premium SSD v2. Він призначений для ІТ-фахівців, знайомих з Kubernetes та Microsoft Azure.

Використовуйте цей варіант розгортання, коли затримка в мережі спільної файлової системи обмежує продуктивність бази даних. Щоб дізнатися про простіший варіант, який використовує Azure Files, див. Розгортання у вигляді веб-застосунку Azure.

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

Автономний сервер ActivityInfo зберігає свої дані в базі даних SQLite. Це визначає весь процес розгортання:

Запускайте одну репліку. Сервер призначений для вертикального, а не горизонтального масштабування: щоб підтримувати більше одночасних користувачів, надайте поду більше ядер ЦП та пам'яті, а не додавайте репліки.
Використовуйте надійне блочне сховище. Керований диск Premium SSD v2 забезпечує затримку, близьку до локального диска, з можливістю налаштування IOPS та пропускної здатності. Оскільки це керований диск, підключений до мережі, його дані реплікуються в бекенді сховища і зберігаються в разі втрати вузла: диск від'єднується і знову приєднується до вузла, на якому переплановується под.

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

Попередні вимоги

Встановіть Azure CLI та kubectl, а потім увійдіть:

az login

Встановлення змінних

RESOURCE_GROUP=activityinfo-rg
LOCATION=westeurope
CLUSTER=activityinfo-aks

Створення кластера

Створіть групу ресурсів та кластер AKS. Драйвер Azure Disk CSI, який надає керовані диски, встановлюється за замовчуванням. Диски Premium SSD v2 є зональними, тому пул вузлів повинен працювати в зоні доступності; --zones 1 розміщує його в зоні 1. Одного вузла достатньо, оскільки ActivityInfo працює як один под. Додайте другий вузол у тій самій зоні, якщо ви хочете, щоб под переплановувався швидше під час збою або оновлення вузла.

az group create --name $RESOURCE_GROUP --location $LOCATION

az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER \
  --node-vm-size Standard_D4s_v5 \
  --node-count 1 \
  --zones 1 \
  --generate-ssh-keys

Підключіть kubectl до нового кластера:

az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER

Створення класу сховища

Вбудовані класи сховищ використовують старіші типи дисків. Визначте клас сховища для Premium SSD v2. Збережіть наступне у storageclass.yaml:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: activityinfo-premium-v2
provisioner: disk.csi.azure.com
parameters:
  skuName: PremiumV2_LRS
  cachingMode: None
  DiskIOPSReadWrite: "3000"
  DiskMBpsReadWrite: "125"
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

WaitForFirstConsumer створює диск у тій самій зоні, що й под, який його використовує. reclaimPolicy: Retain зберігає диск, якщо заявку буде видалено, щоб база даних не була втрачена випадково. Збільште DiskIOPSReadWrite та DiskMBpsReadWrite вище безкоштовного базового рівня 3000 IOPS та 125 МБ/с, якщо ваше робоче навантаження потребує більшого. Застосуйте його:

kubectl apply -f storageclass.yaml

Розгортання ActivityInfo

Збережіть наступне у activityinfo.yaml. Він визначає StatefulSet з однією реплікою, який запитує диск Premium SSD v2 з класу сховища та монтує його в /data. fsGroup у контексті безпеки робить змонтований диск доступним для запису контейнером, який працює від імені користувача без прав root. Service відкриває доступ до контейнера на порту 80 всередині кластера.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: activityinfo
spec:
  serviceName: activityinfo
  replicas: 1
  selector:
    matchLabels:
      app: activityinfo
  template:
    metadata:
      labels:
        app: activityinfo
    spec:
      securityContext:
        fsGroup: 1000
      containers:
        - name: activityinfo
          image: activityinfo/activityinfo:5.0.0
          ports:
            - containerPort: 8081
          env:
            - name: ACTIVITYINFO_DATA_DATA_DIRECTORY
              value: /data
          volumeMounts:
            - name: data
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: activityinfo-premium-v2
        resources:
          requests:
            storage: 100Gi
---
apiVersion: v1
kind: Service
metadata:
  name: activityinfo
spec:
  selector:
    app: activityinfo
  ports:
    - port: 80
      targetPort: 8081

Застосуйте маніфест:

kubectl apply -f activityinfo.yaml

Доступ до сервера

Дочекайтеся, поки под буде готовий, а потім переадресуйте локальний порт на Service:

kubectl rollout status statefulset/activityinfo
kubectl port-forward service/activityinfo 8081:80

Поки команда виконується, відкрийте http://localhost:8081, де вам буде запропоновано створити перший обліковий запис адміністратора. Натисніть Ctrl+C, щоб зупинити переадресацію.

Відкриття доступу до сервера в Інтернеті

Переадресація портів дозволяє отримати доступ до сервера лише з вашого комп'ютера. Щоб зробити ActivityInfo доступним для користувачів, відкрийте доступ до Service та надайте його через HTTPS. ActivityInfo може отримувати та поновлювати власний сертифікат через Let's Encrypt, або ви можете завершити TLS на контролері вхідного трафіку. Наступні ресурси описують можливі варіанти:

Автоматичне налаштування SSL — вбудована підтримка Let's Encrypt в ActivityInfo.
Режим HTTPS-проксі — коли TLS завершується на контролері вхідного трафіку або зворотному проксі.
Використання загальнодоступного балансувальника навантаження в AKS — відкриття доступу до служби за допомогою загальнодоступної IP-адреси.
Керований NGINX ingress в AKS — додаток для маршрутизації застосунків.

Резервне копіювання бази даних

Керований диск витримує втрату вузла, але не захищає від катастроф, таких як пожежа в центрі обробки даних. Регулярно робіть знімки тому диска або копіюйте вміст /data до надійного сховища, наприклад Azure Blob Storage, за розкладом. Зберігайте резервні копії за межами кластера, щоб мати змогу відновити дані після повної втрати кластера.

Наступні кроки

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

Наступний елемент

Інші платформи