← До списку лабораторних по Kubernetes
Повний опис / сценарій лабораторної:
Мета: навчитися організовувати конфігурацію додатка для dev stage і prod через configmap. Крок 1. Створити три namespace dev stage і prod. Команди: kubectl create namespace app-dev; kubectl create namespace app-stage; kubectl create namespace app-prod Пояснення: кожне середовище ізольоване своїм namespace. Крок 2. Створити configmap для кожного середовища. Пояснення: наприклад параметр LOG_LEVEL буде debug для dev info для stage і warn для prod. Крок 3. Перевірити configmap у кожному namespace. Команда: kubectl get configmap -n app-dev; kubectl get configmap -n app-stage; kubectl get configmap -n app-prod Пояснення: переконайся що назви однакові а значення різні. Крок 4. Написати універсальний deployment yaml. Опис: deployment app який читає LOG_LEVEL з configmap що має однакову назву у різних namespace. Пояснення: yaml не містить жорстко зашитих значень специфічних для середовища. Крок 5. Застосувати deployment у трьох namespace. Команди: kubectl apply -f app-deploy.yaml -n app-dev; аналогічно для stage і prod Пояснення: один yaml використовується в різних середовищах. Крок 6. Перевірити змінні середовища у pod. Команди: kubectl exec -it <pod-dev> -n app-dev -- env | grep LOG_LEVEL; аналогічно для інших namespace Пояснення: переконайся що значення відповідають середовищу. Крок 7. Змінити configmap у stage. Пояснення: наприклад переведи log level з info на debug і застосуй зміни. Крок 8. Перезапустити pod тільки у stage. Команда: kubectl rollout restart deployment/app -n app-stage Пояснення: dev і prod не зачіпаються. Крок 9. Переконатися що dev і prod не змінилися. Пояснення: перевір значення env у pod dev і prod ще раз. Крок 10. Міні звіт. Завдання: опиши як такий підхід інтегрується з helm values або kustomize overlays.