# Кейс: Kubernetes (домашний pet-кластер) Если K8s незнаком — сначала пройти учебный курс с нуля [LEARNING.md](LEARNING.md), этот файл — компактный конспект результата для повторения перед собеседованием, без пошаговых объяснений «зачем». Связь с легендой: [../../legend/LEGEND.md](../../legend/LEGEND.md) — раздел «Домашняя лаборатория / pet-проект». **Важно: K8s не входит в рабочий стек ни АО ТНИИС, ни ОКБ СУХОЙ** — это честный pet-проект поверх рабочего опыта с Docker/Ansible/мониторингом, а не часть легенды о работе в конкретной компании. На собеседовании так и позиционируется: «в проде на текущей работе K8s не используем, но поднимал себе дома кластер, чтобы разобраться» (этот же приём в разборе [ВТБ](../../interview/Bank%20VTB.md) сработал в плюс — см. [../../interview/real-interviews.md](../../interview/real-interviews.md)). ## Что нужно реально сделать (домашний стенд) Локальный кластер через `kind` (Kubernetes IN Docker) — не требует отдельной виртуалки, поднимается поверх уже установленного Docker. Цель — своими руками пройти путь «манифест → под → сервис → доступ снаружи», задеплоить кусок стека мониторинга через Helm и прогнать диагностические команды, которые реально спрашивали на собеседованиях. ### 1. Установка и создание кластера ```bash # kind и kubectl (Windows, через choco; либо скачать бинарники с GitHub releases) choco install kind kubernetes-cli kubernetes-helm # кластер из 1 control-plane + 2 worker-нод — чтобы было что рисовать при вопросе про архитектуру ``` ```yaml # kind-config.yaml kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker - role: worker ``` ```bash kind create cluster --name lab --config kind-config.yaml kubectl cluster-info kubectl get nodes -o wide ``` ### 2. Деплой простого приложения: Deployment + Service + ConfigMap ```yaml # app.yaml apiVersion: v1 kind: Namespace metadata: name: demo --- apiVersion: v1 kind: ConfigMap metadata: name: app-config namespace: demo data: GREETING: "Привет из ConfigMap" --- apiVersion: v1 kind: Secret metadata: name: app-secret namespace: demo type: Opaque stringData: API_KEY: "lab-secret-value" --- apiVersion: apps/v1 kind: Deployment metadata: name: demo-app namespace: demo spec: replicas: 3 selector: matchLabels: app: demo-app template: metadata: labels: app: demo-app spec: containers: - name: demo-app image: nginxdemos/hello:latest ports: - containerPort: 80 envFrom: - configMapRef: name: app-config - secretRef: name: app-secret --- apiVersion: v1 kind: Service metadata: name: demo-app-svc namespace: demo spec: selector: app: demo-app ports: - port: 80 targetPort: 80 type: ClusterIP ``` ```bash kubectl apply -f app.yaml kubectl -n demo get pods -o wide kubectl -n demo rollout status deployment/demo-app ``` ### 3. Доступ снаружи: port-forward и Ingress ```bash # быстрый способ проверить сервис kubectl -n demo port-forward svc/demo-app-svc 8080:80 curl http://localhost:8080 ``` Для полноценного Ingress — установить NGINX Ingress Controller (kind предоставляет готовый манифест под себя) и завести `Ingress`-ресурс с host-based роутингом — так на собеседовании про Реалист спрашивали про «два ЦОД под K8s с балансировщиком»: балансировщик снаружи (в лабе — сам kind/NGINX Ingress) → Service (ClusterIP, виртуальный балансировщик по подам через kube-proxy) → поды на worker-нодах. ### 4. Helm: разворачиваем kube-prometheus-stack Практическая связка с уже готовым кейсом [../monitoring/CASE.md](../monitoring/CASE.md) — тот же принцип «Prometheus + Grafana», но теперь через Helm-чарт в кластере, а не через голый docker-compose. ```bash helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm install monitoring prometheus-community/kube-prometheus-stack \ --namespace monitoring --create-namespace kubectl -n monitoring get pods kubectl -n monitoring port-forward svc/monitoring-grafana 3000:80 ``` Это даёт прямой ответ на вопрос Bi.Zone «как задеплоишь мониторинг на 300 000 серверов»: не поднимать вручную, а Helm-чартом с overrides под масштаб (`values.yaml`: количество реплик, remote_write в Mimir/Thanos, ресурсы). См. цифры и архитектуру масштаба в [../../legend/CAPACITY.md](../../legend/CAPACITY.md). ### 5. Диагностика руками (то, что реально спрашивали «показать в терминале») ```bash kubectl -n demo get pods kubectl -n demo describe pod kubectl -n demo logs kubectl -n demo logs --previous # логи упавшего предыдущего инстанса контейнера kubectl -n demo exec -it -- sh kubectl -n demo get events --sort-by=.lastTimestamp kubectl get daemonset -A # например, kube-proxy — daemonset на каждой ноде ``` Специально сломать под (например, указать несуществующий образ в `image:`) и посмотреть на `ImagePullBackOff`/`CrashLoopBackOff` через `describe` — реальная практика диагностики, а не просто описание. ### 6. Разбор компонентов кластера (для вопроса «из чего состоит K8s») - **control-plane**: `kube-apiserver` (единая точка входа для всех запросов), `etcd` (хранилище состояния кластера, key-value), `kube-scheduler` (назначает поды на ноды), `kube-controller-manager` (следит, что желаемое состояние совпадает с реальным). - **worker-нода**: `kubelet` (агент, который управляет подами на ноде), `kube-proxy` (сетевые правила для Service), container runtime (`containerd`). - **etcd отдельно от control-plane или нет** — в проде для отказоустойчивости etcd часто выносят на отдельные ноды (нечётное количество, 3/5, из-за кворума), в маленьких/pet-инсталляциях (как kind) он живёт на той же control-plane ноде. В `kind` это видно напрямую: `kubectl get pods -n kube-system` покажет `etcd-lab-control-plane`. ## Что это даёт в разговоре с интервьюером - Понимание базовых объектов: Pod, Deployment, Service, Namespace, ConfigMap, Secret, Ingress — и что каждый из них реально содержит (проверено `kubectl get -o yaml`). - Понимание разницы ConfigMap (несекретные конфиги) и Secret (base64-кодированные чувствительные данные — не шифрование, а кодирование; для реальной защиты нужны внешние решения типа Sealed Secrets/Vault, см. [../vault/CASE.md](../vault/CASE.md)). - Практика с Helm — установка чарта, `values.yaml`, `helm upgrade`. - Живой опыт диагностики через `kubectl describe`/`logs`/`events`. - Честная граница: это pet-кластер из 3 нод на своей машине, а не эксплуатация продового HA-кластера — расширение до multi-datacenter/etcd-кворума описывается на уровне понимания архитектуры, не личного опыта эксплуатации на этом масштабе. ## Как это ложится в легенду K8s **не** приписывается к опыту в АО ТНИИС или ОКБ СУХОЙ — там его не было и в резюме он не должен появляться в блоках компаний. В «Ключевые навыки» резюме и в легенду он входит как отдельный, честно обозначенный pet-опыт: практическое знакомство с базовыми объектами и Helm поверх домашнего кластера, дополняющее рабочий опыт с Docker и Ansible.