Контейнеры и декларативная конфигурация — Примеры

Пример 1 — Тег, называющий ровно одну сборку

Ваш скрипт выпуска каждый раз пересобирает и отправляет один и тот же тег, поэтому машина разработчика и кластер могут расходиться в том, какие байты лежат в myapp:latest. Переделайте скрипт так, чтобы развёртывание указывало на один неизменяемый тег, а откат был сменой этого значения.

docker build -t myapp:latest .
docker push myapp:latest
kubectl set image deployment/api api=myapp:latest

Решение

docker build -t myapp:1.4.2 .
docker push myapp:1.4.2
kubectl set image deployment/api api=myapp:1.4.2
# откат
kubectl set image deployment/api api=myapp:1.4.1

Теперь каждая сборка публикует тег, который указывает на один набор байтов, поэтому тестируемый образ — это и есть выпускаемый образ, а предыдущий тег — целый путь отката. Обычная ошибка — перезаписать тег ради удобства: на одно имя тогда отвечают две сборки, в кластере может оказаться любая из них, и откат перестаёт быть воспроизводимым.

Пример 2 — Проверка живости, которая перезапускает здоровый процесс

Сервис ниже отвечает на своём порту, но обращается к сервису инвентаря на каждом запросе. Обе проверки работоспособности бьют в один и тот же эндпоинт, который запрашивает эту зависимость. Опишите, что произойдёт, если зависимость всего лишь медленная, и разделите проверки.

livenessProbe:
  httpGet:
    path: /health
    port: 8080
readinessProbe:
  httpGet:
    path: /health
    port: 8080

Решение

livenessProbe:
  httpGet:
    path: /live
    port: 8080
readinessProbe:
  httpGet:
    path: /ready
    port: 8080

Теперь проверка живости зависит только от процесса, а проверка готовности сохраняет зависимость и выводит под из обслуживания, пока она недоступна. Раньше медленная зависимость проваливала живость, и здоровый процесс получал перезапуск, превращая краткое замедление в бесконечный цикл перезапусков.

Подставьте свои имена хостов и детали кластера вместо условных значений в этих набросках.