Initial commit: interview prep repo (resume, legend, stack cases, Kubernetes course)
This commit is contained in:
Tot Maxim
169
stack/kubernetes/CASE.md
Normal file
169
stack/kubernetes/CASE.md
Normal file
@@ -0,0 +1,169 @@
|
||||
# Кейс: 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.
|
||||
Reference in New Issue
Block a user