← До списку лабораторних по Kubernetes
Повний опис / сценарій лабораторної:
Мета: навчитися підвантажувати нову конфігурацію без повного релізу deployment. Крок 1. Створити configmap з конфігом веб сервісу. Команда: kubectl create configmap web-conf --from-literal=message=Hello -o yaml --dry-run=client > web-conf.yaml Пояснення: конфіг містить просте текстове поле. Крок 2. Написати deployment з двома контейнерами. Опис: app контейнер читає файл конфігу і відповідає цим текстом, sidecar reloader відстежує зміни файлу. Пояснення: обидва монтують configmap як файл. Крок 3. Застосувати configmap та deployment. Команди: kubectl apply -f web-conf.yaml; kubectl apply -f web-reload.yaml Пояснення: pod має запуститися і віддавати поточне значення message. Крок 4. Створити service для доступу до додатка. Команда: kubectl expose deployment web-reload --name=web-reload-svc --port=80 Пояснення: через нього будемо тестувати reload. Крок 5. Перевірити поточну відповідь сервісу. Команда: kubectl run curl-reload --rm -it --image=radial/busyboxplus:curl --restart=Never -- sh -c "curl web-reload-svc" Пояснення: має відповідати текст Hello. Крок 6. Оновити configmap зі значенням message=NewText. Пояснення: відредагуй web-conf.yaml і застосуй його повторно командою kubectl apply. Крок 7. Перевірити логи sidecar reloader. Команда: kubectl logs <web-pod> -c reloader Пояснення: там мають бути повідомлення про виявлення змін і перезавантаження. Крок 8. Знову зробити запит до сервісу. Пояснення: переконайся що тепер відповідь містить NewText без повного redeploy. Крок 9. Обговорити ризики такого підходу. Пояснення: подумай що буде якщо конфіг помилковий і додаток не може його прочитати. Крок 10. Міні звіт. Завдання: опиши коли краще робити повноцінний rolling update замість hot reload.