10 промтов для Kubernetes: манифесты, Helm, деплой, которые реально ускоряют работу

Введение

Kubernetes (k8s) — стандарт оркестрации контейнеров, но даже опытные инженеры тратят часы на написание манифестов, отладку Helm-чартов и настройку деплоя. Я собрал 10 проверенных промтов, которые использую ежедневно. Они помогут быстрее создавать Pod’ы, Service’ы, Ingress’ы и автоматизировать рутину. Все примеры основаны на реальных задачах и документации Kubernetes и Helm.

1. Создание базового Pod с переменными окружения и liveness-пробой

Промт: «Сгенерируй YAML-манифест для Pod с образом nginx:1.25, установи переменные окружения ENV=production и REGION=eu-west, добавь livenessProbe через HTTP-запрос на порт 80 с начальной задержкой 10 секунд и периодом 5 секунд».

Пример использования:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-prod
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    env:
    - name: ENV
      value: "production"
    - name: REGION
      value: "eu-west"
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5

Этот промт экономит время на синтаксисе — достаточно скопировать и подставить свои значения.

2. Service типа ClusterIP с селектором по нескольким меткам

Промт: «Напиши манифест Service с типом ClusterIP, который выбирает Pod’ы с метками app=frontend и version=v2, использует порт 8080 и targetPort 80».

Пример:

apiVersion: v1
kind: Service
metadata:
  name: frontend-svc
spec:
  selector:
    app: frontend
    version: v2
  ports:
  - port: 8080
    targetPort: 80
  type: ClusterIP

Полезно, когда нужно изолировать трафик к определённой версии приложения.

3. Ingress с правилами для path-based routing и TLS

Промт: «Создай Ingress для домена example.com, который направляет /api на backend-service:3000, а / на frontend-service:80, и добавь TLS-секрет tls-secret».

Пример:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  tls:
  - hosts:
    - example.com
    secretName: tls-secret
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: backend-service
            port:
              number: 3000
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

Ingress — стандартный способ в Production, и этот шаблон покрывает 80% реальных сценариев.

4. Helm-чарт для микросервиса с ConfigMap и Secret

Промт: «Сгенерируй структуру Helm-чарта my-service с шаблонами для Deployment, Service, ConfigMap и Secret. ConfigMap должен содержать ключ DB_HOST, Secret — DB_PASSWORD, который зашифрован в values.yaml через base64».

Пример структуры:

my-service/
├── Chart.yaml
├── values.yaml
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── configmap.yaml
│   └── secret.yaml

Шаблон configmap.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Values.name }}-config
data:
  DB_HOST: {{ .Values.config.dbHost }}

Secret лучше хранить через sealed-secrets или external-secrets, но для быстрого старта подойдёт и этот вариант.

5. Deployment с rolling update и стратегией рестарта

Промт: «Напиши Deployment для образа myapp:latest с 3 репликами, стратегией RollingUpdate с maxSurge=1 и maxUnavailable=0, добавь readinessProbe и startupProbe».

Пример:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
      - name: app
        image: myapp:latest
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
        startupProbe:
          httpGet:
            path: /started
            port: 8080
          failureThreshold: 30

maxUnavailable=0 — стандарт для zero-downtime деплоя.

6. HorizontalPodAutoscaler на основе CPU и памяти

Промт: «Создай HPA для Deployment myapp, который держит от 2 до 10 подов при средней загрузке CPU выше 70% и памяти выше 80%».

Пример:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

Не забудьте установить requests в манифесте Pod — без них HPA не сработает.

7. Job для разовой задачи с обратной совместимостью (CronJob)

Промт: «Создай Job, который запускает скрипт python migrate.py из образа myapp:latest, и CronJob на его основе, который выполняется каждый день в 3:00 UTC».

Пример Job:

apiVersion: batch/v1
kind: Job
metadata:
  name: migrate-job
spec:
  template:
    spec:
      containers:
      - name: migrate
        image: myapp:latest
        command: ["python", "migrate.py"]
      restartPolicy: Never

CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-migrate
spec:
  schedule: "0 3 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: migrate
            image: myapp:latest
            command: ["python", "migrate.py"]
          restartPolicy: Never

Используется для ETL, очистки данных, рассылок.

8. NetworkPolicy для изоляции трафика между неймспейсами

Промт: «Напиши NetworkPolicy, которая разрешает входящий трафик только от Pod’ов с меткой role=frontend в неймспейсе production на порт 8080, и блокирует весь остальной».

Пример:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          ns: production
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - port: 8080

Без NetworkPolicy любой Pod в кластере может достучаться до любого другого — это небезопасно.

9. StatefulSet с PersistentVolumeClaim для базы данных

Промт: «Создай StatefulSet для postgres:15 с VolumeClaimTemplate на 10 ГБ, сервис headless и имя базы данных mydb».

Пример:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: "postgres-headless"
  replicas: 1
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi
  template:
    spec:
      containers:
      - name: postgres
        image: postgres:15
        env:
        - name: POSTGRES_DB
          value: mydb
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data

StatefulSet гарантирует стабильные hostname и хранение данных.

10. kubectl debug — временный эфемерный контейнер

Промт: «Используя kubectl debug, создай временный контейнер с образом nicolaka/netshoot для отладки сети в Pod’е my-nginx, подключись к нему и выполни nc -zv service-name 80».

Пример команды:

kubectl debug -it pod/my-nginx --image=nicolaka/netshoot --target=my-nginx -- nc -zv frontend-svc 80

Этот приём заменяет SSH внутрь контейнера и не требует установки дополнительных утилит в образе. Подробнее — в официальном руководстве по отладке.

Заключение

Эти 10 промтов покрывают основные задачи, с которыми сталкивается администратор или разработчик Kubernetes. Сохраните их в свой рабочий файл — они сэкономят часы на написание YAML с нуля. А если хотите углубиться — изучите документацию Kubernetes по ссылкам из примеров. Деплоите с удовольствием!