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

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

Stateless застосунки

1: Відкриття зовнішньої IP-адреси для доступу до застосунку в кластері
2: Розгортання релізу за допомогою канаркового розгортання
3: Приклад: Розгортання PHP застосунку гостьової книги з Redis

1 - Відкриття зовнішньої IP-адреси для доступу до застосунку в кластері

Ця сторінка показує, як створити обʼєкт Kubernetes Service, який відкриває зовнішню IP-адресу.

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

Встановіть kubectl.
Використовуйте хмарного провайдера, такого як Google Kubernetes Engine або Amazon Web Services, щоб створити кластер Kubernetes. У цьому підручнику створюється зовнішній балансувальник навантаження, який вимагає хмарного провайдера.
Налаштуйте kubectl для спілкування з вашим API-сервером Kubernetes. Для інструкцій дивіться документацію вашого хмарного провайдера.

Цілі

Запустіть пʼять екземплярів застосунку Hello World.
Створіть обʼєкт Service, який відкриває зовнішню IP-адресу.
Використовуйте обʼєкт Service для доступу до запущеного застосунку.

Створення Service для застосунку, що працює в пʼяти Podʼах

Запустіть застосунок Hello World у вашому кластері:

service/load-balancer-example.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: load-balancer-example
  name: hello-world
spec:
  replicas: 5
  selector:
    matchLabels:
      app.kubernetes.io/name: load-balancer-example
  template:
    metadata:
      labels:
        app.kubernetes.io/name: load-balancer-example
    spec:
      containers:
      - image: gcr.io/google-samples/hello-app:2.0
        name: hello-world
        ports:
        - containerPort: 8080

kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml

Попередня команда створює Deployment і повʼязаний з ним ReplicaSet. ReplicaSet має пʼять Podʼів, кожен з яких запускає застосунок Hello World.

Виведіть інформацію про Deployment:

kubectl get deployments hello-world
kubectl describe deployments hello-world

Виведіть інформацію про обʼєкти ReplicaSet:
```
kubectl get replicasets
kubectl describe replicasets
```

Створіть обʼєкт Service, який експонує Deployment:

kubectl expose deployment hello-world --type=LoadBalancer --name=my-service

Виведіть інформацію про Service:
```
kubectl get services my-service
```
Вивід буде подібний до:
```
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)    AGE
my-service   LoadBalancer   10.3.245.137   104.198.205.71   8080/TCP   54s
```
Примітка
Сервіс типу `type=LoadBalancer` підтримується зовнішніми хмарними провайдерами, що не розглядається в цьому прикладі, будь ласка, зверніться до [встановлення `type: LoadBalancer` для вашого Service](/docs/concepts/services-networking/service/#loadbalancer) для деталей.
Примітка
Якщо зовнішня IP-адреса показується як \, зачекайте хвилину та введіть ту саму команду знову.

Виведіть детальну інформацію про Service:

kubectl describe services my-service

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

Name:           my-service
Namespace:      default
Labels:         app.kubernetes.io/name=load-balancer-example
Annotations:    <none>
Selector:       app.kubernetes.io/name=load-balancer-example
Type:           LoadBalancer
IP:             10.3.245.137
LoadBalancer Ingress:   104.198.205.71
Port:           <unset> 8080/TCP
NodePort:       <unset> 32377/TCP
Endpoints:      10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more...
Session Affinity:   None
Events:         <none>

Занотуйте зовнішню IP-адресу (LoadBalancer Ingress), відкриту вашим сервісом. У цьому прикладі, зовнішня IP-адреса — 104.198.205.71. Також занотуйте значення Port і NodePort. У цьому прикладі, Port — 8080, а NodePort — 32377.

У попередньому виводі ви можете побачити, що сервіс має кілька точок доступу: 10.0.0.6:8080, 10.0.1.6:8080, 10.0.1.7:8080 + ще 2. Це внутрішні адреси Podʼів, які запускають застосунок Hello World. Щоб переконатися, що це адреси Podʼів, введіть цю команду:

kubectl get pods --output=wide

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

NAME                         ...  IP         NODE
hello-world-2895499144-1jaz9 ...  10.0.1.6   gke-cluster-1-default-pool-e0b8d269-1afc
hello-world-2895499144-2e5uh ...  10.0.1.8   gke-cluster-1-default-pool-e0b8d269-1afc
hello-world-2895499144-9m4h1 ...  10.0.0.6   gke-cluster-1-default-pool-e0b8d269-5v7a
hello-world-2895499144-o4z13 ...  10.0.1.7   gke-cluster-1-default-pool-e0b8d269-1afc
hello-world-2895499144-segjf ...  10.0.2.5   gke-cluster-1-default-pool-e0b8d269-cpuc

Використовуйте зовнішню IP-адресу (LoadBalancer Ingress) для доступу до застосунку Hello World:
```
curl http://<external-ip>:<port>
```
де <external-ip> — це зовнішня IP-адреса (LoadBalancer Ingress) вашого сервісу, а <port> — значення Port в описі вашого сервісу. Якщо ви використовуєте minikube, ввівши minikube service my-service автоматично відкриє застосунок Hello World в оглядачі.
Відповідь на успішний запит — привітальне повідомлення:
```
Hello, world!
Version: 2.0.0
Hostname: 0bd46b45f32f
```

Очищення

Щоб видалити Service, введіть цю команду:

kubectl delete services my-service

Щоб видалити Deployment, ReplicaSet і Podʼи, які запускають застосунок Hello World, введіть цю команду:

kubectl delete deployment hello-world

Що далі

Дізнайтеся більше про Підключення застосунків за допомогою Service. Спробуйте Розгортання канаркового релізу, щоб дізнатися, як безпечно тестувати нові версії застосунків у виробничому середовищі.

2 - Розгортання релізу за допомогою канаркового розгортання

Цей навчальний посібник проведе вас через розгортання канаркового релізу в Kubernetes. Канаркове розгортання дозволяє безпечно протестувати нову версію застосунку з невеликою часткою промислового трафіку, перш ніж повністю впровадити її. Такий підхід допомагає мінімізувати ризики та забезпечує швидкий зворотний звʼязок від реальних користувачів.

Огляд канаркових розгортань дивіться у розділі Канаркові розгортання концептуальної сторінки "Керування робочими навантаженнями".

Цілі

Розгорнути стабільну версію застосунку
Розгорнути канаркову версію поряд зі стабільною
Направляти трафік до обох версій за допомогою Service
Відстежувати канаркове розгортання
Завершити впровадження, масштабувавши канаркове розгортання та видаливши попередню стабільну версію

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

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

Розуміння канаркових розгортань

Канаркове розгортання — це стратегія, за якої ви розгортаєте нову версію вашого застосунку поряд з наявною версією. Нова версія (канарка) отримує невеликий відсоток трафіку, що дозволяє вам:

Тестувати нову версію з реальним промисловим трафіком
Відстежувати помилки, проблеми з продуктивністю чи неочікувану поведінку
Швидко відкотитися назад, якщо виявлено проблеми
Поступово збільшувати трафік до нової версії, якщо вона добре працює

У цьому навчальному посібнику ви використаєте мітку track для розрізнення стабільного та канаркового релізів. Стабільний реліз використовує track: stable, а канарковий — track: canary. Обидва розгортання мають спільні мітки (app.kubernetes.io/name: rollout-demo), які дозволяють Service направляти трафік до обох наборів Podʼів.

Ви розгорнете стабільну версію з 3 репліками та канаркову версію з 1 реплікою. Оскільки обидві версії використовують спільний селектор Service (app.kubernetes.io/name: rollout-demo), Kubernetes буде балансувати навантаження між усіма 4 Podʼами. За такого співвідношення приблизно 25% трафіку йде до канарки та 75% — до стабільної версії.

Розгортання стабільної версії

Спочатку розгорніть стабільну версію вашого застосунку:

application/canary/app-v1-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rollout-demo-stable
  labels:
    app.kubernetes.io/name: rollout-demo
    track: stable
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: rollout-demo
      track: stable
  template:
    metadata:
      labels:
        app.kubernetes.io/name: rollout-demo
        track: stable
    spec:
      containers:
      - name: rollout-demo
        image: gcr.io/google-samples/hello-app:1.0
        ports:
        - containerPort: 8080
        env:
        - name: VERSION
          value: "v1"

Застосуйте стабільний Deployment:

kubectl apply -f https://k8s.io/examples/application/canary/app-v1-deployment.yaml

Перевірте, що Deployment створено та Podʼи працюють:

kubectl get deployments -l app.kubernetes.io/name=rollout-demo

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

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
rollout-demo-stable    3/3     3            3           10s

Перевірте Podʼи:

kubectl get pods -l app.kubernetes.io/name=rollout-demo

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

NAME                                  READY   STATUS    RESTARTS   AGE
rollout-demo-stable-7d4b9b8c5d-abc12   1/1     Running   0          15s
rollout-demo-stable-7d4b9b8c5d-def34   1/1     Running   0          15s
rollout-demo-stable-7d4b9b8c5d-ghi56   1/1     Running   0          15s

Створення service

Створіть Service, щоб відкрити доступ до вашого застосунку. Селектор Service використовує спільну мітку (app.kubernetes.io/name: rollout-demo) та оминає мітку track, що дозволяє йому направляти трафік і до стабільних, і до канаркових Podʼів:

application/canary/app-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: rollout-demo-service
  labels:
    app.kubernetes.io/name: rollout-demo
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: rollout-demo
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Застосуйте Service:

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

Перевірте, що Service створено:

kubectl get service rollout-demo-service

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

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
rollout-demo-service   ClusterIP   10.96.123.45    <none>        80/TCP    5s

Протестуйте Service, створивши тимчасовий Pod та виконавши запит:

kubectl run curl-test --image=curlimages/curl:latest --rm -it --restart=Never -- curl http://rollout-demo-service

Ви повинні побачити відповіді від стабільних Podʼів. Виконайте цю команду кілька разів, щоб побачити різні імена хостів Podʼів, але всі відповіді мають показувати версію v1.

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

Розгортання канаркової версії

Щоб створити канарковий Deployment, ви можете скопіювати маніфест стабільного Deployment та внести кілька змін:

Змінити metadata.name (наприклад, на rollout-demo-canary)
Змінити мітку track з stable на canary в обох metadata.labels та spec.selector.matchLabels/spec.template.metadata.labels
Встановити меншу кількість реплік (наприклад, 1)
Оновити образ контейнера до нової версії

Оновлений маніфест має виглядати так:

application/canary/app-v2-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rollout-demo-canary
  labels:
    app.kubernetes.io/name: rollout-demo
    track: canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: rollout-demo
      track: canary
  template:
    metadata:
      labels:
        app.kubernetes.io/name: rollout-demo
        track: canary
    spec:
      containers:
      - name: rollout-demo
        image: gcr.io/google-samples/hello-app:2.0
        ports:
        - containerPort: 8080
        env:
        - name: VERSION
          value: "v2"

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

kubectl apply -f https://k8s.io/examples/application/canary/app-v2-deployment.yaml

Перевірте, що обидва Deployment працюють:

kubectl get deployments -l app.kubernetes.io/name=rollout-demo

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

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
rollout-demo-stable    3/3     3            3           2m
rollout-demo-canary    1/1     1            1           10s

Перевірте всі Podʼи:

kubectl get pods -l app.kubernetes.io/name=rollout-demo -o wide

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

NAME                                  READY   STATUS    RESTARTS   AGE   IP           NODE
rollout-demo-stable-7d4b9b8c5d-abc12   1/1     Running   0          2m    10.244.1.5   node1
rollout-demo-stable-7d4b9b8c5d-def34   1/1     Running   0          2m    10.244.1.6   node1
rollout-demo-stable-7d4b9b8c5d-ghi56   1/1     Running   0          2m    10.244.2.7   node2
rollout-demo-canary-8e5c0d9f6a-xyz78   1/1     Running   0          15s   10.244.2.8   node2

Зверніть увагу, що тепер у вас 4 Podʼи загалом: 3 стабільні Podʼи та 1 канарковий Pod.

Тестування розподілу трафіку

Оскільки обидва Deployment використовують однаковий селектор Service (app.kubernetes.io/name: rollout-demo), Service направляє трафік до всіх Podʼів. З 3 стабільними Podʼами та 1 канарковим Podʼом приблизно 25% запитів йде до канарки.

Протестуйте Service кілька разів, щоб побачити розподіл трафіку:

kubectl run curl-test --image=docker.io/library/curlimages/curl:latest --rm -it --restart=Never -- \
  sh -c 'for i in $(seq 1 10); do curl -s http://rollout-demo-service; echo; done'

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

Перевірте EndpointSlices Service, щоб переконатися, що обидві версії отримують трафік:

kubectl get endpointslices -l kubernetes.io/service-name=rollout-demo-service

Вивід буде схожий на цей (один EndpointSlice на сімейство адрес; стовпець ENDPOINTS за замовчуванням обрізається):

NAME                          ADDRESSTYPE   PORTS   ENDPOINTS                              AGE
rollout-demo-service-abc12    IPv4          8080    10.244.1.5,10.244.1.6,10.244.2.7 + 1 more...   3m

Щоб побачити всі адреси точок доступу, використовуйте -o yaml.

Моніторинг канаркового розгортання

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

Перевірте логи Podʼа канарки:

kubectl logs -l app.kubernetes.io/name=rollout-demo,track=canary --tail=50

Відстежуйте стан Podʼів:

kubectl get pods -l app.kubernetes.io/name=rollout-demo -w

Натисніть Ctrl+C, щоб зупинити спостереження.

Перевірте використання ресурсів:

kubectl top pods -l app.kubernetes.io/name=rollout-demo

Примітка:

Команда kubectl top вимагає, щоб у вашому кластері був встановлений metrics-server. Якщо він недоступний, ви можете відстежувати за допомогою інших методів, як-от Prometheus або засобів моніторингу хмарного провайдера.

Регулювання розподілу трафіку

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

Масштабуйте канарку до 2 реплік (тепер 40% трафіку):

kubectl scale deployment/rollout-demo-canary --replicas=2

Перевірте, що новий Pod працює:

kubectl get pods -l app.kubernetes.io/name=rollout-demo

Продовжуйте відстеження. Якщо все виглядає добре, ви можете масштабувати канарку далі та зменшити стабільну версію.

Завершення впровадження

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

Щоб завершити впровадження за допомогою одного Deployment, спочатку збільшіть стабільний Deployment, щоб не втратити пропускну здатність, якщо новому образу не вдасться завантажитися. Потім оновіть образ та змінну середовища VERSION відповідно до нової версії, зачекайте завершення впровадження та видаліть канарковий Deployment:

kubectl scale deployment/rollout-demo-stable --replicas=3

# Поза цим навчальним посібником ви б не встановлювали
# змінну середовища $VERSION.
# Однак ваш новий код застосунку може потребувати
# інших змін конфігурації після оновлення.
kubectl set image deployment/rollout-demo-stable rollout-demo=gcr.io/google-samples/hello-app:2.0
kubectl set env deployment/rollout-demo-stable VERSION=v2

# Зачекайте завершення впровадження
kubectl rollout status deployment/rollout-demo-stable

kubectl delete deployment rollout-demo-canary

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

Або ви можете прочитати решту сторінки, перш ніж почати очищення — попереду ще кілька тем.

Відкат канаркового розгортання

Якщо ви виявили проблеми з канарковою версією, ви можете швидко відкотитися назад:

Масштабуйте канарковий Deployment вниз:

kubectl scale deployment/rollout-demo-canary --replicas=0

Масштабування до нуля зберігає канарковий Deployment, щоб ви могли переглянути його конфігурацію, поки проводите розслідування. Після завершення видаліть його командою kubectl delete deployment rollout-demo-canary.

За потреби збільште стабільну версію назад:

kubectl scale deployment/rollout-demo-stable --replicas=3

Розслідуйте проблеми з канаркою, перш ніж робити чергову спробу канаркового розгортання.

Розподіл трафіку за допомогою HTTPRoute (опціонально)

Якщо ви використовуєте Gateway API, ви можете застосувати HTTPRoute для точнішого контролю над розподілом трафіку між стабільною та канарковою версіями. Такий підхід дозволяє вказувати точні відсотки розподілу трафіку, а не покладатися на кількість реплік.

Спочатку створіть окремі Services для стабільної та канаркової версій. Цей підхід також корисний для налагодження, навіть якщо ви не використовуєте Gateway API. Маючи окремі Services, ви можете напряму тестувати або відстежувати кожну версію незалежно.

apiVersion: v1
kind: Service
metadata:
  name: rollout-demo-stable-service
spec:
  selector:
    app.kubernetes.io/name: rollout-demo
    track: stable
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: rollout-demo-canary-service
spec:
  selector:
    app.kubernetes.io/name: rollout-demo
    track: canary
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Потім створіть HTTPRoute, який розподіляє трафік між двома Services:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: rollout-demo-route
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "rollout-demo.example.com"
  rules:
  - backendRefs:
    - name: rollout-demo-stable-service
      port: 80
      weight: 90
    - name: rollout-demo-canary-service
      port: 80
      weight: 10

Ця конфігурація направляє 90% трафіку до стабільного Service та 10% до канаркового Service, незалежно від кількості реплік.

Ви також можете використовувати маршрутизацію на основі заголовків, щоб надсилати конкретний трафік до канарки:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: rollout-demo-route
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "rollout-demo.example.com"
  rules:
  # Правило 1: Направляти трафік із заголовком canary до канаркового service
  - matches:
    - headers:
      - type: Exact
        name: env
        value: canary
    backendRefs:
    - name: rollout-demo-canary-service
      port: 80
  # Правило 2: Розподіляти решту трафіку у співвідношенні 90/10
  - backendRefs:
    - name: rollout-demo-stable-service
      port: 80
      weight: 90
    - name: rollout-demo-canary-service
      port: 80
      weight: 10

Ця конфігурація надсилає весь трафік із заголовком env: canary до канаркового Service, а решта трафіку розподіляється у співвідношенні 90/10 між стабільною та канарковою версіями.

Примітка:

Gateway API вимагає встановлення контролера Gateway у вашому кластері. Інструкції зі встановлення та підтримувані реалізації дивіться у документації Gateway API.

Автоматизація канаркових впроваджень

У промислових середовищах канарковими впровадженнями зазвичай керують контролери або CI/CD-системи, які автоматизують перемикання трафіку, моніторинг та просування чи відкат. Такі інструменти, як Flux, Argo Rollouts, GitLab та багато інших, можуть взяти на себе прогресивне постачання, аналіз та відкат за вас. Це зменшує кількість ручних кроків і допомагає забезпечити безпечні, повторювані розгортання. Додаткову інформацію дивіться у документації вибраного вами інструмента розгортання або контролера.

Очищення

Видаліть ресурси, створені в цьому навчальному посібнику:

kubectl delete deployment rollout-demo-stable rollout-demo-canary
kubectl delete service rollout-demo-service

Якщо ви створили окремі Services для HTTPRoute, видаліть і їх:

kubectl delete service rollout-demo-stable-service rollout-demo-canary-service
kubectl delete httproute rollout-demo-route

Що далі

Дізнайтеся більше про канаркові розгортання на концептуальній сторінці "Керування робочими навантаженнями".
Прочитайте про Deployments та про те, як вони керують життєвим циклом вашого застосунку.
Прочитайте про Services та про те, як вони забезпечують виявлення сервісів і балансування навантаження.
Вивчіть Gateway API для розширених можливостей керування трафіком.
Розгляньте використання Горизонтального автомасштабування Podʼів для автоматичного регулювання кількості реплік на основі метрик.

3 - Приклад: Розгортання PHP застосунку гостьової книги з Redis

Цей посібник показує, як створити та розгорнути простий (але не готовий до промислового використання) багатошаровий вебзастосунок, використовуючи Kubernetes та Docker. Цей приклад складається з наступних компонентів:

Одно-екземплярний Redis для зберігання записів у гостьовій книзі
Кілька веб-фронтендів

Цілі

Запустити Redis-лідер.
Запустити двох Redis-фолловерів.
Запустити фронтенд гостьової книги.
Опублікувати та переглянути Frontend Service.
Виконати очищення.

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

Версія вашого Kubernetes сервера має бути не старішою ніж v1.14.

Для перевірки версії введіть kubectl version.

Запуск бази даних Redis

Застосунок гостьової книги використовує Redis для зберігання своїх даних.

Створення Deployment Redis

Файл маніфесту, наведений нижче, визначає контролер Deployment, який запускає одну репліку Redis Pod.

application/guestbook/redis-leader-deployment.yaml
# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-leader
  labels:
    app: redis
    role: leader
    tier: backend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
        role: leader
        tier: backend
    spec:
      containers:
      - name: leader
        image: "registry.k8s.io/redis@sha256:cb111d1bd870a6a471385a4a69ad17469d326e9dd91e0e455350cacf36e1b3ee"
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 6379

Відкрийте вікно термінала в теці, куди ви завантажили файли маніфестів.

Застосуйте Deployment Redis з файлу redis-leader-deployment.yaml:

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-deployment.yaml

Перевірте список Podʼів, щоб переконатися, що Pod Redis запущений:
```
kubectl get pods
```
Відповідь повинна бути схожою на цю:
```
NAME                           READY   STATUS    RESTARTS   AGE
redis-leader-fb76b4755-xjr2n   1/1     Running   0          13s
```
Виконайте наступну команду, щоб переглянути лог з Podʼа Redis лідера:
```
kubectl logs -f deployment/redis-leader
```

Створення Service Redis-лідера

Застосунок гостьової книги потребує звʼязку з Redis для запису своїх даних. Вам потрібно застосувати Service, щоб спрямовувати трафік до Pod Redis. Service визначає політику доступу до Podʼів.

application/guestbook/redis-leader-service.yaml
# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: v1
kind: Service
metadata:
  name: redis-leader
  labels:
    app: redis
    role: leader
    tier: backend
spec:
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    app: redis
    role: leader
    tier: backend

Застосуйте Service Redis з файлу redis-leader-service.yaml:

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-service.yaml

Перевірте список Serviceʼів, щоб переконатися, що Service Redis запущений:

kubectl get service

Відповідь повинна бути схожою на цю:

NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
kubernetes     ClusterIP   10.0.0.1     <none>        443/TCP    1m
redis-leader   ClusterIP   10.103.78.24 <none>        6379/TCP   16s

Примітка

Цей файл маніфесту створює Service з іменем `redis-leader` з набором міток, які відповідають раніше визначеним міткам, тому Service спрямовує мережевий трафік до Pod Redis.

Налаштування Redis-фолловерів

Хоча Redis-лідер є одним Pod, ви можете зробити його високо доступним і задовольняти потреби в трафіку, додавши кілька фолловерів Redis або реплік.

application/guestbook/redis-follower-deployment.yaml
# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-follower
  labels:
    app: redis
    role: follower
    tier: backend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
        role: follower
        tier: backend
    spec:
      containers:
      - name: follower
        image: us-docker.pkg.dev/google-samples/containers/gke/gb-redis-follower:v2
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 6379

Застосуйте Deployment Redis з файлу redis-follower-deployment.yaml:

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-deployment.yaml

Перевірте, що дві репліки Redis-фолловерів запущені, виконавши запит списку Podʼів:

kubectl get pods

Відповідь повинна бути схожою на цю:

NAME                             READY   STATUS    RESTARTS   AGE
redis-follower-dddfbdcc9-82sfr   1/1     Running   0          37s
redis-follower-dddfbdcc9-qrt5k   1/1     Running   0          38s
redis-leader-fb76b4755-xjr2n     1/1     Running   0          11m

Створення Service Redis-фолловера

Застосунок гостьової книги потребує зʼязку з фолловерами Redis для читання даних. Щоб зробити фолловерів Redis доступними, потрібно налаштувати інший Service.

application/guestbook/redis-follower-service.yaml
# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: v1
kind: Service
metadata:
  name: redis-follower
  labels:
    app: redis
    role: follower
    tier: backend
spec:
  ports:
    # порт на якому повинен працювати цей Service
  - port: 6379
  selector:
    app: redis
    role: follower
    tier: backend

Застосуйте сервіс Redis з файлу redis-follower-service.yaml:

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-service.yaml

Перевірте список Serviceʼів, щоб переконатися, що Service Redis запущений:

kubectl get service

Відповідь повинна бути схожою на цю:

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
kubernetes       ClusterIP   10.96.0.1       <none>        443/TCP    3d19h
redis-follower   ClusterIP   10.110.162.42   <none>        6379/TCP   9s
redis-leader     ClusterIP   10.103.78.24    <none>        6379/TCP   6m10s

Примітка

Цей файл маніфесту створює Service з іменем `redis-follower` з набором міток, які відповідають раніше визначеним міткам, тому сервіс спрямовує мережевий трафік до Pod Redis.

Налаштування та експонування фронтенда гостьової книги

Тепер, коли ви запустили сховище Redis для своєї гостьової книги, запустіть вебсервери фронтенду. Як і фолловери Redis, фронтенд розгортається за допомогою контролера Deployment Kubernetes.

Застосунок гостьової книги використовує PHP фронтенд. Він налаштований для звʼязку з Serviceʼами фолловера або лідера Redis, залежно від того, чи є запит читанням або записом. Фронтенд відкриває інтерфейс JSON та забезпечує UX на основі jQuery-Ajax.

Створення Deployment фронтенду гостьової книги

application/guestbook/frontend-deployment.yaml
# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
        app: guestbook
        tier: frontend
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5
        env:
        - name: GET_HOSTS_FROM
          value: "dns"
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 80

Застосуйте розгортання фронтенду з файлу frontend-deployment.yaml:
```
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
```

Перевірте список Podʼів, щоб переконатися, що три репліки фронтенду запущені:

kubectl get pods -l app=guestbook -l tier=frontend

Відповідь повинна бути схожою на цю:

NAME                        READY   STATUS    RESTARTS   AGE
frontend-85595f5bf9-5tqhb   1/1     Running   0          47s
frontend-85595f5bf9-qbzwm   1/1     Running   0          47s
frontend-85595f5bf9-zchwc   1/1     Running   0          47s

Створення Service для Фронтенду

Serviceʼи Redis, які ви створили, доступні тільки всередині кластера Kubernetes, оскільки типовий тип для Service — ClusterIP. ClusterIP надає одну IP-адресу для набору Podʼів, на які вказує Service. Ця IP-адреса доступна тільки всередині кластера.

Якщо ви хочете, щоб гості могли отримати доступ до вашої гостьової книги, ви повинні налаштувати Service фронтенду таким чином, щоб він був видимий зовні, щоб клієнт міг запитувати Service ззовні кластера Kubernetes. Проте користувачі Kubernetes можуть скористатися командою kubectl port-forward, щоб отримати доступ до Service, навіть якщо він використовує ClusterIP.

Примітка

Деякі хмарні провайдери, такі як Google Compute Engine або Google Kubernetes Engine, підтримують зовнішні балансувальники навантаження. Якщо ваш хмарний провайдер підтримує балансувальники навантаження і ви хочете його використовувати, розкоментуйте `type: LoadBalancer`.

application/guestbook/frontend-service.yaml
# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: v1
kind: Service
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # якщо ваш кластер підтримує це, розкоментуйте наступне, щоб автоматично створити
  # зовнішню IP-адресу з балансуванням навантаження для служби frontend.
  # type: LoadBalancer
  #type: LoadBalancer
  ports:
    # порт на якому має працювати цей Service
  - port: 80
  selector:
    app: guestbook
    tier: frontend

Застосуйте Service фронтенду з файлу frontend-service.yaml:

kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml

Виконайте запит для отримання списку Service, щоб переконатися, що Service фронтенду запущений:

kubectl get services

Відповідь повинна бути схожою на цю:

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
frontend         ClusterIP   10.97.28.230    <none>        80/TCP     19s
kubernetes       ClusterIP   10.96.0.1       <none>        443/TCP    3d19h
redis-follower   ClusterIP   10.110.162.42   <none>        6379/TCP   5m48s
redis-leader     ClusterIP   10.103.78.24    <none>        6379/TCP   11m

Перегляд Service Фронтенду через `kubectl port-forward`

Виконайте наступну команду, щоб перенаправити порт 8080 на вашій локальній машині на порт 80 на сервісі.
```
kubectl port-forward svc/frontend 8080:80
```
Відповідь повинна бути схожою на цю:
```
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
```
Завантажте сторінку http://localhost:8080 у вашому оглядачі, щоб переглянути вашу гостьову книгу.

Перегляд Service Фронтенду через `LoadBalancer`

Якщо ви розгорнули маніфест frontend-service.yaml з типом LoadBalancer, вам потрібно знайти IP-адресу, щоб переглянути вашу гостьову книгу.

Виконайте наступну команду, щоб отримати IP-адресу для Service фронтенду.
```
kubectl get service frontend
```
Відповідь повинна бути схожою на цю:
```
NAME       TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)        AGE
frontend   LoadBalancer   10.51.242.136   109.197.92.229     80:32372/TCP   1m
```
Скопіюйте зовнішню IP-адресу та завантажте сторінку у вашому оглядачі, щоб переглянути вашу гостьову книгу.

Примітка

Спробуйте додати кілька записів у гостьову книгу, ввівши повідомлення та натиснувши "Submit". Повідомлення, яке ви ввели, зʼявиться на фронтенді. Це повідомлення свідчить про те, що дані успішно додані до Redis через Serviceʼи, які ви створили раніше.

Масштабування Веб-Фронтенду

Ви можете збільшувати або зменшувати кількість реплік за потребою, оскільки ваші сервери визначені як Service, що використовує контролер Deployment.

Виконайте наступну команду, щоб збільшити кількість Podʼів фронтенду:
```
kubectl scale deployment frontend --replicas=5
```

Виконайте запит для отримання списку Podʼів, щоб перевірити кількість запущених Podʼів фронтенду:

kubectl get pods

Відповідь повинна виглядати приблизно так:

NAME                             READY   STATUS    RESTARTS   AGE
frontend-85595f5bf9-5df5m        1/1     Running   0          83s
frontend-85595f5bf9-7zmg5        1/1     Running   0          83s
frontend-85595f5bf9-cpskg        1/1     Running   0          15m
frontend-85595f5bf9-l2l54        1/1     Running   0          14m
frontend-85595f5bf9-l9c8z        1/1     Running   0          14m
redis-follower-dddfbdcc9-82sfr   1/1     Running   0          97m
redis-follower-dddfbdcc9-qrt5k   1/1     Running   0          97m
redis-leader-fb76b4755-xjr2n     1/1     Running   0          108m

Виконайте наступну команду, щоб зменшити кількість Pods фронтенду:
```
kubectl scale deployment frontend --replicas=2
```

Виконайте запит для отримання списку Podʼів, щоб перевірити кількість запущених Podʼів фронтенду:

kubectl get pods

Відповідь повинна виглядати приблизно так:

NAME                             READY   STATUS    RESTARTS   AGE
frontend-85595f5bf9-cpskg        1/1     Running   0          16m
frontend-85595f5bf9-l9c8z        1/1     Running   0          15m
redis-follower-dddfbdcc9-82sfr   1/1     Running   0          98m
redis-follower-dddfbdcc9-qrt5k   1/1     Running   0          98m
redis-leader-fb76b4755-xjr2n     1/1     Running   0          109m

Очищення

Видалення Deployment та Serviceʼів також видаляє всі запущені Podʼи. Використовуйте мітки для видалення кількох ресурсів однією командою.

Виконайте наступні команди, щоб видалити всі Pods, Deployment і Serviceʼи.

kubectl delete deployment -l app=redis
kubectl delete service -l app=redis
kubectl delete deployment frontend
kubectl delete service frontend

Відповідь повинна виглядати приблизно так:

deployment.apps "redis-follower" deleted
deployment.apps "redis-leader" deleted
deployment.apps "frontend" deleted
service "frontend" deleted

Виконайте запит списку Podʼів, щоб переконатися, що жоден Pod не працює:
```
kubectl get pods
```
Відповідь повинна виглядати приблизно так:
```
No resources found in default namespace.
```

Що далі

Пройдіть інтерактивні навчальні посібники Основи Kubernetes
Використовуйте Kubernetes для створення блогу з використанням постійних томів для MySQL і WordPress
Дізнайтеся більше про Підключення застосунків за допомогою Service
Дізнайтеся більше про ефективне використання міток
Спробуйте Розгортання канаркового релізу, щоб дізнатися, як безпечно тестувати нові версії застосунків у виробничому середовищі.

Stateless застосунки

1 - Відкриття зовнішньої IP-адреси для доступу до застосунку в кластері

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

Цілі

Створення Service для застосунку, що працює в пʼяти Podʼах

Очищення

Що далі

2 - Розгортання релізу за допомогою канаркового розгортання

Цілі

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

Розуміння канаркових розгортань

Розгортання стабільної версії

Створення service

Розгортання канаркової версії

Тестування розподілу трафіку

Моніторинг канаркового розгортання

Примітка:

Регулювання розподілу трафіку

Завершення впровадження

Відкат канаркового розгортання

Розподіл трафіку за допомогою HTTPRoute (опціонально)

Примітка:

Автоматизація канаркових впроваджень

Очищення

Що далі

3 - Приклад: Розгортання PHP застосунку гостьової книги з Redis

Цілі

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

Запуск бази даних Redis

Створення Deployment Redis

Створення Service Redis-лідера

Налаштування Redis-фолловерів

Створення Service Redis-фолловера

Налаштування та експонування фронтенда гостьової книги

Створення Deployment фронтенду гостьової книги

Створення Service для Фронтенду

Перегляд Service Фронтенду через kubectl port-forward

Перегляд Service Фронтенду через LoadBalancer

Масштабування Веб-Фронтенду

Очищення

Що далі

Перегляд Service Фронтенду через `kubectl port-forward`

Перегляд Service Фронтенду через `LoadBalancer`