Кейс: Kubernetes (домашний pet-кластер)

Если K8s незнаком — сначала пройти учебный курс с нуля LEARNING.md, этот файл — компактный конспект результата для повторения перед собеседованием, без пошаговых объяснений «зачем».

Связь с легендой: ../../legend/LEGEND.md — раздел «Домашняя лаборатория / pet-проект». Важно: K8s не входит в рабочий стек ни АО ТНИИС, ни ОКБ СУХОЙ — это честный pet-проект поверх рабочего опыта с Docker/Ansible/мониторингом, а не часть легенды о работе в конкретной компании. На собеседовании так и позиционируется: «в проде на текущей работе K8s не используем, но поднимал себе дома кластер, чтобы разобраться» (этот же приём в разборе ВТБ сработал в плюс — см. ../../interview/real-interviews.md).

Что нужно реально сделать (домашний стенд)

Локальный кластер через kind (Kubernetes IN Docker) — не требует отдельной виртуалки, поднимается поверх уже установленного Docker. Цель — своими руками пройти путь «манифест → под → сервис → доступ снаружи», задеплоить кусок стека мониторинга через Helm и прогнать диагностические команды, которые реально спрашивали на собеседованиях.

1. Установка и создание кластера

# kind и kubectl (Windows, через choco; либо скачать бинарники с GitHub releases)
choco install kind kubernetes-cli kubernetes-helm

# кластер из 1 control-plane + 2 worker-нод — чтобы было что рисовать при вопросе про архитектуру

# kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker

kind create cluster --name lab --config kind-config.yaml
kubectl cluster-info
kubectl get nodes -o wide

2. Деплой простого приложения: Deployment + Service + ConfigMap

# 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

kubectl apply -f app.yaml
kubectl -n demo get pods -o wide
kubectl -n demo rollout status deployment/demo-app

3. Доступ снаружи: port-forward и Ingress

# быстрый способ проверить сервис
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 — тот же принцип «Prometheus + Grafana», но теперь через Helm-чарт в кластере, а не через голый docker-compose.

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.

5. Диагностика руками (то, что реально спрашивали «показать в терминале»)

kubectl -n demo get pods
kubectl -n demo describe pod <pod-name>
kubectl -n demo logs <pod-name>
kubectl -n demo logs <pod-name> --previous   # логи упавшего предыдущего инстанса контейнера
kubectl -n demo exec -it <pod-name> -- 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).
Практика с Helm — установка чарта, values.yaml, helm upgrade.
Живой опыт диагностики через kubectl describe/logs/events.
Честная граница: это pet-кластер из 3 нод на своей машине, а не эксплуатация продового HA-кластера — расширение до multi-datacenter/etcd-кворума описывается на уровне понимания архитектуры, не личного опыта эксплуатации на этом масштабе.

Как это ложится в легенду

K8s не приписывается к опыту в АО ТНИИС или ОКБ СУХОЙ — там его не было и в резюме он не должен появляться в блоках компаний. В «Ключевые навыки» резюме и в легенду он входит как отдельный, честно обозначенный pet-опыт: практическое знакомство с базовыми объектами и Helm поверх домашнего кластера, дополняющее рабочий опыт с Docker и Ansible.

9.7 KiB Raw Permalink Blame History Unescape Escape