> Насколько знаком с Kubernetes на уровне пользователя (Go)

Короткий ответ

На уровне пользователя Kubernetes я уверенно работаю с kubectl, манифестами, Helm-чартами и отладкой подов. Знаю устройство объектов: Deployment, Service, ConfigMap, Secret, Ingress, PVC. Понимаю, как устроены namespace, labels, selectors, probes, resource requests/limits. Умею работать с логами, exec, port-forward, описывать проблемы и находить их причины через describe, events, kubectl get. Хватает знаний для самостоятельной эксплуатации сервисов в кластере и взаимодействия с DevOps.

Подробное объяснение

На уровне пользователя Kubernetes - это уверенное владение ежедневными операциями без глубокого погружения во внутренности control plane. Я знаю:

• Основные объекты: Pod, Deployment, StatefulSet, DaemonSet, Job, CronJob, Service (ClusterIP, NodePort, LoadBalancer), Ingress, ConfigMap, Secret, PVC/PV, Namespace, ResourceQuota, LimitRange.
• Рабочий процесс: создание и обновление манифестов, rolling update, rollback, масштабирование (replicas, HPA), стратегии деплоя (Recreate, RollingUpdate).
• Сеть: как Service проксирует трафик, headless services, Ingress-контроллеры, NetworkPolicy на базовом уровне.
• Хранилище: динамическое выделение PVC, StorageClass, access modes.
• Конфигурация: ConfigMap и Secret, их монтирование, env, immutable.
• Наблюдаемость: логи (kubectl logs, --previous), события, describe, top, metrics-server, базовые дашборды.
• Безопасность на уровне пользователя: service accounts, RBAC (роли, binding), imagePullSecrets, private registry.
• Helm: создание и использование чартов, values, dependency, upgrade, rollback.
• Kustomize: базовые overlay, patches.

На практике

В повседневной работе я:

• Пишу и ревьюю манифесты, следую best practices: liveness/readiness probes, resource requests/limits, pod anti-affinity, topology spread constraints.
• Использую kubectl с плагинами (kubectl-neat, krew), работаю с несколькими контекстами.
• Отлаживаю проблемы: pod в CrashLoopBackOff, ImagePullBackOff, pending из-за ресурсов или PVC, проблемы с DNS, network policy, ingress routing.
• Работаю с Helm-чартами для деплоя сервисов, управляю values для разных окружений.
• Настраиваю горизонтальное масштабирование через HPA на основе метрик CPU/memory и кастомных метрик.
• Взаимодействую с CI/CD: собираю образ, пуша в registry, обновляю deployment через kubectl set image или helm upgrade.
• Использую port-forward для локальной отладки, exec для диагностики, логи с follow и tail.

Пример кода

YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: production
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.4.2
          ports:
            - containerPort: 8080
          envFrom:
            - configMapRef:
                name: api-config
            - secretRef:
                name: api-secrets
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

BASH
# отладка
kubectl get events --sort-by=.lastTimestamp
kubectl describe pod api-7d8f9c5d6-abc12
kubectl logs deployment/api --tail=100 -f
kubectl exec -it deploy/api -- sh

# обновление
kubectl set image deployment/api api=registry.example.com/api:1.5.0
kubectl rollout status deployment/api
kubectl rollout undo deployment/api

Как отвечать на собеседовании

• Начни с уровня: "уверенный пользователь, не админ кластера".
• Перечисли конкретные объекты и операции, с которыми работал ежедневно.
• Приведи реальный пример: как деплоил сервис, отлаживал проблему, настраивал HPA.
• Упомяни Helm и Kustomize, если использовал - это плюс.
• Покажи понимание trade-off: requests vs limits, readiness vs liveness, replicas vs HPA.
• Если спрашивают про внутренности - честно скажи, что это зона ответственности DevOps/SRE, но базовое понимание control plane есть.
• Не углубляйся в детали etcd, scheduler, kubelet, если не просят - это уровень администратора.

Что проверяет интервьюер

• Реальный опыт, а не заученные определения.
• Умение диагностировать типовые проблемы.
• Понимание жизненного цикла подов и деплойментов.
• Знание best practices по ресурсам, probes, безопасности.
• Способность говорить на одном языке с DevOps.
• Уровень самостоятельности: сможет ли кандидат развернуть и поддерживать сервис в кластере без постоянной помощи.

Типичные ошибки

• Путаница между liveness и readiness - частая ошибка.
• Непонимание разницы между ClusterIP, NodePort и LoadBalancer.
• Утверждение, что PVC можно использовать без StorageClass.
• Незнание, как посмотреть логи предыдущего пода (--previous).
• Уверенность, что kubectl apply всегда безопасен - незнание про conflicts и last-applied-configuration.
• Игнорирование resource requests/limits - "и так работает".
• Непонимание, что HPA не работает без metrics-server.
• Слишком глубокий уход в администрирование кластера, когда спрашивают про пользовательский уровень - это выглядит как заученность.