170 lines
9.7 KiB
Markdown
170 lines
9.7 KiB
Markdown
# Кейс: 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 <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](../vault/CASE.md)).
|
||
- Практика с Helm — установка чарта, `values.yaml`, `helm upgrade`.
|
||
- Живой опыт диагностики через `kubectl describe`/`logs`/`events`.
|
||
- Честная граница: это pet-кластер из 3 нод на своей машине, а не эксплуатация продового HA-кластера — расширение до multi-datacenter/etcd-кворума описывается на уровне понимания архитектуры, не личного опыта эксплуатации на этом масштабе.
|
||
|
||
## Как это ложится в легенду
|
||
|
||
K8s **не** приписывается к опыту в АО ТНИИС или ОКБ СУХОЙ — там его не было и в резюме он не должен появляться в блоках компаний. В «Ключевые навыки» резюме и в легенду он входит как отдельный, честно обозначенный pet-опыт: практическое знакомство с базовыми объектами и Helm поверх домашнего кластера, дополняющее рабочий опыт с Docker и Ansible.
|