feat: added lab 5.2

2026-06-15 23:04:14 +03:00
1 parent 401ae1dd51
commit b0e5a6b653
@@ -0,0 +1,174 @@
+---
+course_code: VKCLOUD-80
+artifact_type: PR
+module: 5
+task_code: 2
+task_title: Работа с Kubernetes (MK8s)
+student_fio: Ремизов Кирилл Львович
+date: 2026-06-15
+source_docs:
+  - 3-Конспект лекций - VK 1.md
+  - 4-Практические работы - VK -1.md
+commands_used:
+  - kubectl get nodes
+  - kubectl get pods --all-namespaces
+  - kubectl apply -f deployment.yaml
+  - kubectl get pods
+  - kubectl get services
+  - kubectl get service nginx-service -w
+attached_files:
+  - VKC_PR_M05_02_k8s_my-k8s_РемизовКЛ_20260615.png
+  - VKC_PR_M05_02_k8s_stage2log_РемизовКЛ_20260615.log
+  - VKC_PR_M05_02_k8s_stage3log_РемизовКЛ_20260615.log
+  - VKC_PR_M05_02_k8s_stage3pruf_РемизовКЛ_20260615.png
+  - VKC_PR_M05_02_k8s_deployment_РемизовКЛ_20260615.yaml
+status: final
+---
+# Отчёт по практической демонстрации
+
+## 1. Цель
+
+Освоить базовые навыки работы с **управляемым сервисом Kubernetes (MK8s)** в VK Cloud. Научиться создавать кластер через веб‑консоль, подключаться к нему с помощью `kubectl`, разворачивать контейнеризированное приложение (nginx) с несколькими репликами и обеспечивать его доступность из интернета через сервис типа `LoadBalancer`.
+
+## 2. Что было прочитано перед выполнением
+
+- **Документ:** 3-Конспект лекций - VK 1.md  
+- **Раздел/тема:** Модуль 5 «Контейнеризация и автоматизация», тема 5.2 «Контейнеры и оркестрация (Kubernetes)»  
+- **Ключевые понятия:**  
+  - Контейнеры (Docker) vs виртуальные машины  
+  - Kubernetes: кластер, ноды (master/worker), control plane  
+  - Объекты: Pod, Deployment, Service (типы ClusterIP, LoadBalancer)  
+  - Managed Kubernetes в VK Cloud (MK8s)  
+  - `kubectl` – клиент для управления кластером  
+  - Манифесты в формате YAML (Deployment + Service)  
+
+- **Дополнительно:** Документ 4-Практические работы - VK -1.md, демонстрация 5.2 «Работа с Kubernetes (MK8s)» (этапы создания кластера, подключения, развёртывания приложения).
+
+## 3. Ход выполнения
+
+### Демонстрация 5.2: Работа с Kubernetes (MK8s)
+
+#### Этап 1. Создание кластера (веб-консоль)
+
+**Действие:**  
+В разделе **«Контейнеры» → «Kubernetes»** создал новый кластер со следующими параметрами:
+
+| Параметр               | Значение                              |
+|------------------------|---------------------------------------|
+| Имя кластера           | `my-k8s`                              |
+| Версия Kubernetes      | v1.34.2                               |
+| Тип кластера           | Стандартный (1 master, 2 worker)      |
+| Сеть                   | `my-k8s` (создана ранее)              |
+| Подсеть worker‑узлов   | `subnet_8887`                         |
+| Тип виртуальной машины | `STD3-2-8` для master, `Standard-2-4` для worker |
+| Количество worker‑нод  | 2                                     |
+| Зона доступности       | Москва (PA2)                          |
+
+**Результат:**  
+Через 5–7 минут кластер перешёл в статус **Running**.  
+*Скриншот страницы с параметрами кластера приложен:*  
+[[VKC_PR_M05_02_k8s_my-k8s_РемизовКЛ_20260615.png]]
+
+#### Этап 2. Подключение к кластеру (kubectl)
+
+**Действие:**  
+1. Скачал `kubeconfig` из консоли VK Cloud (файл `my-k8s-kubeconfig`).  
+2. Установил переменную окружения:
+   ```bash
+   export KUBECONFIG=~/Downloads/my-k8s-kubeconfig
+   ```
+3. Проверил доступность узлов и системных подов:
+   ```bash
+   kubectl get nodes
+   kubectl get pods --all-namespaces
+   ```
+
+**Результат:**  
+- Оба worker‑узла находятся в состоянии **Ready** (версия v1.34.2).  
+- В пространстве `kube-system` работают основные компоненты: сетевой плагин Calico, драйвер CSI для дисков, другие системные поды.  
+
+*Полный вывод команд сохранён в логе:*  
+[[VKC_PR_M05_02_k8s_stage2log_РемизовКЛ_20260615.log]]
+
+#### Этап 3. Развёртывание приложения (Deployment + LoadBalancer)
+
+**Действие:**  
+1. Создал файл манифеста `deployment.yaml` (см. приложение). В нём описаны:
+   - **Deployment** `nginx-deployment` с 3 репликами, использующий образ `nginx:latest`, с ограничениями по CPU и памяти.
+   - **Service** типа `LoadBalancer`, который слушает порт 80 и направляет трафик на поды с меткой `app: nginx`.
+2. Применил манифест:
+   ```bash
+   kubectl apply -f deployment.yaml
+   ```
+3. Отследил создание подов и назначение внешнего IP:
+   ```bash
+   kubectl get pods
+   kubectl get services
+   kubectl get service nginx-service -w
+   ```
+4. Дождался, когда в поле `EXTERNAL-IP` появится реальный IP‑адрес (процесс занял около 3 минут).  
+5. Открыл в браузере полученный IP и убедился, что отображается стандартная приветственная страница nginx.
+
+**Результат:**  
+- Три пода `nginx-deployment-*` перешли в статус `Running`.  
+- Сервис `nginx-service` получил внешний IP (в логе после ожидания IP не отобразился, но скриншот браузера подтверждает доступность).  
+- При обращении по этому IP видна страница **Welcome to nginx!**
+
+*Лог применения манифеста и ожидания:*  
+[[VKC_PR_M05_02_k8s_stage3log_РемизовКЛ_20260615.log]]  
+*Скриншот работающего приложения:*  
+[[VKC_PR_M05_02_k8s_stage3pruf_РемизовКЛ_20260615.png]]  
+*Файл манифеста:*  
+[[VKC_PR_M05_02_k8s_deployment_РемизовКЛ_20260615.yaml]]
+
+## 4. Ошибки и исправления
+
+| Проблема | Решение |
+| :--- | :--- |
+| После применения манифеста сервис долго (более 2 минут) имел статус `EXTERNAL-IP = <pending>`. | Это нормальное поведение для облачного провайдера: требуется время на автоматическое создание облачного балансировщика нагрузки (Octavia) и выделение ему плавающего IP. Достаточно подождать 3–5 минут – IP назначается автоматически. |
+| В логе `stage3log` внешний IP так и не отобразился (вывод прерван `^C`). | Студент прервал команду `kubectl get service -w` раньше, чем IP появился. Однако позже IP был получен (доказательство – скриншот браузера). В следующий раз стоит дождаться появления адреса или использовать `kubectl describe service nginx-service`. |
+
+## 5. Критерии успеха
+
+- [x] Кластер Kubernetes успешно создан (статус Running, 2 worker‑ноды).
+- [x] `kubectl get nodes` показывает `Ready` для обеих нод.
+- [x] Deployment с 3 репликами nginx запущен и все поды находятся в статусе `Running`.
+- [x] Сервис типа `LoadBalancer` получил внешний IP.
+- [x] При обращении по внешнему IP открывается стандартная страница nginx.
+
+## 6. Приложенные доказательства
+
+| Файл                                                              | Тип           | Что подтверждает                                      |
+| ----------------------------------------------------------------- | ------------- | ----------------------------------------------------- |
+| VKC_PR_M05_02_k8s_my-k8s_РемизовКЛ_20260615.png                   | Скриншот      | Параметры созданного кластера (версия, ноды, сеть)     |
+| VKC_PR_M05_02_k8s_stage2log_РемизовКЛ_20260615.log                | Текстовый лог | Вывод `kubectl get nodes` и `get pods --all-namespaces` (готовность кластера) |
+| VKC_PR_M05_02_k8s_stage3log_РемизовКЛ_20260615.log                | Текстовый лог | Применение манифеста, создание подов, ожидание External‑IP |
+| VKC_PR_M05_02_k8s_stage3pruf_РемизовКЛ_20260615.png               | Скриншот      | Страница nginx, доступная по внешнему IP балансировщика |
+| VKC_PR_M05_02_k8s_deployment_РемизовКЛ_20260615.yaml              | YAML‑манифест | Код развёртывания Deployment и Service LoadBalancer    |
+
+## 7. Самопроверка
+
+- **Что получилось:**  
+  Успешно создал managed‑кластер Kubernetes в VK Cloud, подключился к нему, развернул масштабируемое приложение (3 реплики nginx) и открыл доступ к нему из интернета через LoadBalancer. На практике убедился в простоте использования управляемого сервиса: не требуется настраивать control plane, достаточно скачать kubeconfig.
+
+- **Что осталось непонятным:**  
+  - Каким образом VK Cloud автоматически создаёт балансировщик для сервиса типа LoadBalancer (используется ли Octavia, как долго это происходит в зависимости от региона).  
+  - Как настроить Ingress‑контроллер для маршрутизации на основе доменных имён, вместо использования одного LoadBalancer на сервис.  
+  - Почему в выводе `kubectl get service -w` внешний IP долго не появлялся, хотя балансировщик в консоли VK Cloud создался быстрее – возможно, задержка связана с обновлением состояния в `kubectl`.
+
+- **Что можно улучшить:**  
+  - Добавить в манифест `livenessProbe` и `readinessProbe` для надёжного мониторинга состояния подов.  
+  - Использовать `ConfigMap` для вынесения конфигурации nginx (например, кастомной index.html).  
+  - Включить **Horizontal Pod Autoscaler** для автоматического масштабирования реплик по CPU.  
+  - Применить GitOps‑подход: выложить манифесты в Git и настроить ArgoCD для синхронизации.
+
+## 8. Краткий вывод
+
+Практическая работа показала, что **управляемый Kubernetes (MK8s)** в VK Cloud позволяет быстро развернуть готовый кластер, не тратя время на установку и настройку control plane. С помощью стандартного инструмента `kubectl` и декларативных YAML‑манифестов можно за минуты запустить приложение в контейнерах, обеспечить его масштабирование и сделать доступным из интернета через облачный балансировщик нагрузки.
+
+Особую ценность имеют:
+- **Простота начала работы** – кластер создаётся «по кнопке», kubeconfig скачивается готовым.
+- **Стандартизация** – Kubernetes предоставляет единые API‑объекты (Deployment, Service), которые работают одинаково в любом облаке.
+- **Автоматизация** – сервис типа LoadBalancer автоматически интегрируется с облачной сетью, избавляя от ручного назначения плавающих IP.
+
+Полученные навыки являются базой для дальнейшего изучения более сложных тем: Helm, Ingress, Service Mesh, GitOps и построения production‑ready микросервисных архитектур в облаке.