Senior Go Interview Prep - Core Go: https://go.vbloher.org/docs/01-core-go/ - Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/ - Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/ - Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/ - Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/ - Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/ - Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/ - panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/ - Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/ - Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/ - Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/ - Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/ - Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/ - Concurrency: https://go.vbloher.org/docs/02-concurrency/ - sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/ - Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/ - Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/ - Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/ - Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/ - sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/ - context: https://go.vbloher.org/docs/02-concurrency/context/ - Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/ - sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/ - sync.Once: https://go.vbloher.org/docs/02-concurrency/once/ - Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/ - Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/ - Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/ - select: https://go.vbloher.org/docs/02-concurrency/select/ - sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/ - Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/ - Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/ - Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/ - Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/ - Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/ - GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/ - Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/ - Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/ - Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/ - pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/ - Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/ - Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/ - Тестирование: https://go.vbloher.org/docs/04-testing/ - testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/ - Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/ - Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/ - Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/ - Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/ - Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/ - Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/ - Backend: https://go.vbloher.org/docs/05-backend/ - Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/ - Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/ - gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/ - JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/ - Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/ - net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/ - OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/ - OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/ - Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/ - REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/ - Сети и протоколы: https://go.vbloher.org/docs/06-networking/ - Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/ - DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/ - Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/ - TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/ - TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/ - UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/ - WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/ - Базы данных: https://go.vbloher.org/docs/07-databases/ - Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/ - Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/ - Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/ - Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/ - MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/ - Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/ - Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/ - Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/ - Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/ - Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/ - Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/ - Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/ - Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/ - CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/ - Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/ - Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/ - Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/ - Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/ - Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/ - Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/ - Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/ - Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/ - RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/ - Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/ - Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/ - Observability: https://go.vbloher.org/docs/09-observability/ - Grafana: https://go.vbloher.org/docs/09-observability/grafana/ - Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/ - OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/ - Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/ - SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/ - Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/ - Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/ - System Design: https://go.vbloher.org/docs/10-system-design/ - Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/ - Chat System: https://go.vbloher.org/docs/10-system-design/chat/ - Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/ - Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/ - Order Service: https://go.vbloher.org/docs/10-system-design/order-service/ - Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/ - Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/ - URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/ - DevOps: https://go.vbloher.org/docs/11-devops/ - CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/ - Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/ - Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/ - GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/ - Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/ - Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/ - Алгоритмы: https://go.vbloher.org/docs/12-algorithms/ - Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/ - Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/ - Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/ - Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/ - Behavioral: https://go.vbloher.org/docs/13-behavioral/ - Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/ - Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/ - Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/ - Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/ > Модуль: DevOps · Уровень: Middle+/Senior ## TL;DR - **Pod** — минимальная единица деплоя (1+ контейнеров с общими network namespace и volumes). Поды эфемерны и заменяемы. - **Deployment** управляет ReplicaSet'ами, обеспечивает rolling update и self-healing. **Service** даёт стабильный виртуальный IP/DNS и L4-балансировку поверх меняющихся подов. **Ingress** — L7-роутинг (host/path) снаружи. - **ConfigMap** — некритичная конфигурация, **Secret** — чувствительные данные (base64, не шифрование по умолчанию). Монтируются как env или файлы. - **Probes**: liveness (перезапуск зависшего), readiness (убрать из балансировки, не убивая), startup (для медленного старта, отключает остальные пока не пройдёт). - **requests** — гарантированный минимум для планировщика, **limits** — потолок. CPU limit троттлит, memory limit → OOMKill. - Главная Go-проблема: **GOMAXPROCS не видит cgroup-лимит CPU** — по умолчанию берёт число ядер ноды, что вызывает throttling. Решение: `automaxprocs` или Go 1.25+ (cgroup-aware runtime). Аналогично `GOMEMLIMIT` под memory limit. - **Graceful shutdown**: SIGTERM → дренаж readiness → дослужить запросы → exit до истечения `terminationGracePeriodSeconds`. `preStop` хук для синхронизации с балансировщиком. ## Теория ### Базовые объекты **Pod** — один или несколько контейнеров, разделяющих сетевой namespace (один IP, общий localhost) и volumes. В norm-практике 1 контейнер на под + sidecar'ы (логи, прокси). Под не переживает перезапуск ноды — его пересоздаёт контроллер. **ReplicaSet** — поддерживает N идентичных реплик. Напрямую почти не создают. **Deployment** — декларативное управление ReplicaSet'ами: rolling update, rollback, масштабирование, self-healing. ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 3 selector: matchLabels: { app: api } template: metadata: labels: { app: api } spec: terminationGracePeriodSeconds: 30 containers: - name: api image: registry/api:1.4.2 ports: [{ containerPort: 8080 }] env: - name: GOMEMLIMIT valueFrom: resourceFieldRef: { resource: limits.memory } resources: requests: { cpu: "250m", memory: "128Mi" } limits: { cpu: "1", memory: "256Mi" } readinessProbe: httpGet: { path: /readyz, port: 8080 } periodSeconds: 5 livenessProbe: httpGet: { path: /healthz, port: 8080 } periodSeconds: 10 startupProbe: httpGet: { path: /healthz, port: 8080 } failureThreshold: 30 periodSeconds: 2 lifecycle: preStop: exec: { command: ["sleep", "5"] } ``` **Service** — стабильная точка доступа поверх подов (по label selector), L4-балансировка через kube-proxy/iptables/IPVS. Типы: - `ClusterIP` — внутренний виртуальный IP (дефолт). - `NodePort` — порт на каждой ноде. - `LoadBalancer` — внешний LB облака. - `Headless` (`clusterIP: None`) — DNS отдаёт IP всех подов напрямую (для StatefulSet, клиентской балансировки, gRPC). **Ingress** — L7 (HTTP/HTTPS) роутинг по host/path, TLS-терминация. Нужен Ingress Controller (nginx, traefik). Современная замена — Gateway API. ### ConfigMap и Secret ```yaml apiVersion: v1 kind: ConfigMap metadata: { name: app-config } data: LOG_LEVEL: "info" config.yaml: | timeout: 30s --- apiVersion: v1 kind: Secret metadata: { name: app-secret } type: Opaque data: DB_PASSWORD: c2VjcmV0 # base64, НЕ шифрование ``` Подключение: ```yaml envFrom: - configMapRef: { name: app-config } - secretRef: { name: app-secret } volumeMounts: - { name: cfg, mountPath: /etc/app, readOnly: true } ``` - Secret в etcd по умолчанию **только base64**, не шифрование. Включайте encryption-at-rest для etcd и/или внешние хранилища (Vault, External Secrets Operator, cloud KMS). - **env vs volume**: значения через `env` фиксируются на старте пода — обновление ConfigMap не подхватится без рестарта. Смонтированные файлы обновляются автоматически (с задержкой), но приложение должно их перечитывать (watch/SIGHUP). ### Probes | Probe | Что делает при провале | Зачем | |-------|------------------------|-------| | **liveness** | перезапускает контейнер | вытащить из дедлока/зависания | | **readiness** | убирает под из endpoints Service (трафик не идёт), под живёт | временная неготовность: прогрев кэша, потеря БД, дренаж при shutdown | | **startup** | не убивает, пока не превышен `failureThreshold`; до прохождения liveness/readiness не запускаются | защита медленно стартующих приложений от преждевременного liveness-kill | Критично разделять `/healthz` (liveness — процесс жив) и `/readyz` (readiness — готов принимать трафик). **Ошибка: liveness, проверяющий БД** — при кратком сбое БД k8s начнёт каскадно рестартовать все поды (crash loop), хотя приложение в порядке. Зависимости проверяйте в readiness. ### requests / limits и QoS - **requests** — то, что планировщик резервирует для пода; используется для bin-packing на ноды. - **limits** — жёсткий потолок. **CPU limit → throttling** (CFS quota, под не убивают, но тормозят). **Memory limit → OOMKill** при превышении. - **QoS-классы**: `Guaranteed` (requests==limits для всех ресурсов), `Burstable` (есть requests < limits), `BestEffort` (ничего не задано). При нехватке памяти на ноде первыми эвиктятся BestEffort, потом Burstable. Споры по CPU limit: многие убирают CPU limit (оставляя только request), чтобы избежать throttling, но это снижает изоляцию. Memory limit ставить обязательно. ### HPA Horizontal Pod Autoscaler масштабирует реплики по метрикам. ```yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: api } spec: scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: api } minReplicas: 3 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: { type: Utilization, averageUtilization: 70 } ``` - Целевой % считается от **requests**, не от limits. Поэтому корректный CPU request критичен для HPA. - Нужен metrics-server (для resource-метрик) или Prometheus Adapter / KEDA (для custom-метрик: RPS, длина очереди). - **GOMAXPROCS-проблема прямо бьёт по HPA**: если рантайм троттлится из-за неверного GOMAXPROCS, метрики CPU искажаются и автоскейл работает неправильно. ### Rolling update ```yaml strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 # не уменьшать доступную ёмкость maxSurge: 1 # можно поднять +1 под сверх replicas ``` Поды заменяются по одному: поднимается новый, ждём readiness, гасим старый. `maxUnavailable: 0` + `maxSurge` гарантирует отсутствие просадки ёмкости. Откат: `kubectl rollout undo deployment/api`. ### Graceful shutdown (важнейшее для backend на Go) Последовательность при удалении пода: 1. Под помечается `Terminating`, удаляется из endpoints Service (асинхронно). 2. Выполняется `preStop` хук (если есть). 3. Контейнеру шлётся **SIGTERM**. 4. Ждём до `terminationGracePeriodSeconds` (дефолт 30s). 5. Если жив — **SIGKILL**. **Гонка**: удаление из endpoints и SIGTERM происходят параллельно. Балансировщик может ещё слать трафик в под, который уже получил SIGTERM. Решение — `preStop: sleep 5–10s`: даём времени iptables/endpoint-контроллеру обновиться ДО того, как начнём останавливать сервер. Go-реализация: ```go func main() { srv := &http.Server{Addr: ":8080", Handler: mux} go func() { if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed { log.Fatal(err) } }() ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM) defer stop() <-ctx.Done() // получили SIGTERM // снимаем readiness, чтобы новый трафик не шёл atomic.StoreInt32(&ready, 0) // дослуживаем активные запросы shCtx, cancel := context.WithTimeout(context.Background(), 25*time.Second) defer cancel() if err := srv.Shutdown(shCtx); err != nil { log.Printf("graceful shutdown failed: %v", err) } } ``` Важно: `srv.Shutdown` дожидается завершения in-flight запросов, но не прерывает долгие. Таймаут shutdown должен быть < `terminationGracePeriodSeconds`, иначе SIGKILL прервёт на середине. ### GOMAXPROCS, GOMEMLIMIT и cgroups **Проблема**: Go runtime по умолчанию ставит `GOMAXPROCS` = число логических CPU **ноды** (через `/proc`), игнорируя cgroup CPU quota. На ноде с 64 ядрами и лимитом `limits.cpu: 2` Go создаст 64 P, runtime-scheduler будет раскидывать горутины на 64 потока, CFS начнёт жёстко throttle'ить → высокая latency, скачки p99, неэффективный GC. Решения: - `go.uber.org/automaxprocs` — `import _ "go.uber.org/automaxprocs"`, читает cgroup quota и выставляет GOMAXPROCS = floor(quota). - **Go 1.25+** — рантайм стал cgroup-aware и сам учитывает CPU quota (но проверяйте версию; automaxprocs остаётся надёжным фолбэком). - Вручную: `env GOMAXPROCS` из downward API. **GOMEMLIMIT** (Go 1.19+) — soft memory limit для GC. Без него Go может вырасти до memory limit и получить OOMKill раньше, чем GC решит собрать мусор. Выставляйте GOMEMLIMIT в ~80–90% от `limits.memory`: ```yaml env: - name: GOMEMLIMIT value: "230MiB" # при limits.memory: 256Mi ``` GOMEMLIMIT — soft limit: GC станет агрессивнее у границы, но не гарантирует, что процесс не превысит лимит (может крутить GC в死, "GC death spiral", если памяти реально не хватает). Комбинируйте с реалистичным memory limit. ## Подводные камни / gotchas - **Liveness проверяет внешние зависимости** → каскадные рестарты при сбое БД. Зависимости — только в readiness. - **Нет preStop sleep** → 502/connection reset во время деплоя из-за гонки endpoints vs SIGTERM. - **GOMAXPROCS = ядра ноды** → CPU throttling, рост p99. Ставьте automaxprocs. - **Нет GOMEMLIMIT** → OOMKill вместо GC. Симптом: под рестартует с reason `OOMKilled`, exit code 137. - **env из ConfigMap не обновляется** → меняете ConfigMap, под не видит до рестарта. Используйте volume + watch или сделайте rollout. - **CPU limit ставит throttling даже без превышения среднего** — CFS quota применяется в окнах 100ms, burst-нагрузка троттлится. Многие убирают CPU limit. - **HPA не масштабирует** → не выставлен resource request (HPA считает % от request) или нет metrics-server. - **Shutdown timeout > terminationGracePeriodSeconds** → SIGKILL обрывает graceful shutdown. Держите запас. - **Secret в git как plain YAML** → утечка. Используйте SOPS/sealed-secrets/External Secrets. - **`imagePullPolicy: Always` с тегом `latest`** vs кэш — невоспроизводимость. Пинуйте теги/digest. - **Под не реагирует на SIGTERM** — приложение запущено через shell-обёртку (не PID 1) или не ловит сигнал. Exec-форма ENTRYPOINT + signal.NotifyContext. ## Вопросы на собеседовании **В:** Разница между liveness и readiness probe? **О:** Liveness при провале перезапускает контейнер (лечит зависание/дедлок). Readiness при провале убирает под из endpoints Service — трафик не идёт, но под не убивают (временная неготовность, прогрев, дренаж). Внешние зависимости проверяют только в readiness, иначе сбой БД вызовет каскадные рестарты. **В:** Что происходит при `kubectl delete pod` или rolling update, на уровне сигналов? **О:** Под → Terminating, параллельно удаляется из endpoints; выполняется preStop; контейнер получает SIGTERM; ждём terminationGracePeriodSeconds; если жив — SIGKILL. Приложение должно по SIGTERM снять readiness и сделать graceful shutdown активных запросов до истечения grace period. **В:** Почему Go-сервис в k8s тормозит, хотя CPU не утилизирован полностью? **О:** GOMAXPROCS взят по числу ядер ноды, а не по cgroup CPU quota. Runtime раскидывает горутины на много потоков, CFS троттлит до квоты → латентность растёт. Лечится automaxprocs или Go 1.25+ cgroup-aware рантаймом. **В:** В чём разница requests и limits, и что такое QoS? **О:** requests — резерв для планировщика (bin-packing, основа для HPA). limits — потолок: CPU → throttling, memory → OOMKill. QoS: Guaranteed (requests==limits), Burstable (requests