Как настраивается конфигурация Kubernetes

Ответ

Конфигурация Kubernetes — это декларативное описание желаемого состояния кластера в виде YAML- или JSON-манифестов. Я настраиваю её, следуя принципам GitOps и инфраструктуры как кода (IaC).

Основные инструменты и подходы:

  1. Базовые манифесты (kubectl apply): Для простых сервисов или одноразовых задач.

    # deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: api-backend
      namespace: production
      labels:
        app: api
        tier: backend
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: api
          tier: backend
      template:
        metadata:
          labels:
            app: api
            tier: backend
        spec:
          containers:
          - name: api
            image: registry.example.com/api:v1.2.3
            ports:
            - containerPort: 8080
            envFrom:
            - configMapRef:
                name: api-config
            resources:
              requests:
                memory: "256Mi"
                cpu: "250m"
              limits:
                memory: "512Mi"
                cpu: "500m"
          # Добавляем sidecar для сбора логов
          - name: log-shipper
            image: fluentbit:latest

    Применение: kubectl apply -f deployment.yaml -n production

  2. Kustomize для управления окружениями: Позволяет создавать базовые конфигурации и оверлеи для dev/staging/prod.

    base/
    ├── deployment.yaml
    ├── service.yaml
    └── kustomization.yaml
    overlays/
    ├── staging/
    │   ├── replica-patch.yaml # Увеличиваем реплики
    │   ├── configmap-patch.yaml # Конфиг для staging
    │   └── kustomization.yaml
    └── production/
        ├── hpa.yaml # Добавляем HorizontalPodAutoscaler
        ├── ingress.yaml # Публичный ingress
        └── kustomization.yaml

    Применение: kubectl apply -k overlays/production

  3. Helm для пакетирования приложений: Использую для сложных приложений с множеством зависимостей (например, Elasticsearch с StatefulSet, Service, ConfigMap).

    # Установка чарта из репозитория
    helm repo add bitnami https://charts.bitnami.com/bitnami
    helm install my-postgres bitnami/postgresql -f values/prod.yaml
    
    # Создание своего чарта
    helm create my-microservice
    # Затем редактирую templates/ и values.yaml
  4. GitOps с ArgoCD: Это основной подход в production. Манифесты хранятся в Git, а ArgoCD автоматически синхронизирует состояние кластера с репозиторием.

    # Application manifest для ArgoCD
    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: api-backend
      namespace: argocd
    spec:
      project: default
      source:
        repoURL: 'git@github.com:my-org/k8s-manifests.git'
        targetRevision: HEAD
        path: apps/api/overlays/production
      destination:
        server: 'https://kubernetes.default.svc'
        namespace: production
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

    Такой подход обеспечивает аудируемость, откат изменений через git revert и единый источник истины для всей инфраструктуры.

Ответ 18+ 🔞

Ну слушай, история с этими куберами — это ёперный театр, если честно. Конфигурация там — это просто бумажка, где ты пишешь, как всё должно быть в идеальном мире. Типа, «хочу три копии приложения, чтоб память им вот столько, и чтоб они там красиво висели». Всё это на YAML, который читать — хуй с горы, глаза сломаешь.

Чем я обычно пользуюсь, чтобы не сойти с ума:

  1. Простые манифесты (kubectl apply): Для какой-нибудь мелочёвки, когда надо быстро что-то запилить и забыть. Но это, блядь, как спички в детстве — кажется просто, а потом весь дом ебушки-воробушки. Открываешь файл, а там эта простыня, ядрёна вошь.

    # deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: api-backend
      namespace: production
      labels:
        app: api
        tier: backend
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: api
          tier: backend
      template:
        metadata:
          labels:
            app: api
            tier: backend
        spec:
          containers:
          - name: api
            image: registry.example.com/api:v1.2.3
            ports:
            - containerPort: 8080
            envFrom:
            - configMapRef:
                name: api-config
            resources:
              requests:
                memory: "256Mi"
                cpu: "250m"
              limits:
                memory: "512Mi"
                cpu: "500m"
          # Добавляем sidecar для сбора логов
          - name: log-shipper
            image: fluentbit:latest

    И потом тыкаешь команду kubectl apply -f deployment.yaml -n production и молишься, чтобы не вылезла какая-нибудь хитрая жопа с ошибкой в отступах.

  2. Kustomize для разных окружений: Вот это уже ближе к делу. Потому что держать одни и те же настройки для прода и для тестов — это, ёпта, мудя полная. Ты делаешь одну основу, а потом как будто накладываешь плёнки: для staging — одни патчи, для production — другие, овердохуища сложные.

    base/
    ├── deployment.yaml
    ├── service.yaml
    └── kustomization.yaml
    overlays/
    ├── staging/
    │   ├── replica-patch.yaml # Увеличиваем реплики
    │   ├── configmap-patch.yaml # Конфиг для staging
    │   └── kustomization.yaml
    └── production/
        ├── hpa.yaml # Добавляем HorizontalPodAutoscaler
        ├── ingress.yaml # Публичный ingress
        └── kustomization.yaml

    Запускаешь kubectl apply -k overlays/production и чувствуешь себя немножко волшебником. Немножко.

  3. Helm для сложных штук: А вот это когда приложение — не просто контейнер, а целый зоопарк из StatefulSet'ов, ConfigMap'ов и прочей хуйни. Типа Elasticsearch. Без Helm'а там можно мозг вынести на развод. Он всё упаковывает в один красивый (иногда) пакет.

    # Установка чарта из репозитория
    helm repo add bitnami https://charts.bitnami.com/bitnami
    helm install my-postgres bitnami/postgresql -f values/prod.yaml
    
    # Создание своего чарта
    helm create my-microservice
    # Затем редактирую templates/ и values.yaml

    Главное — не запутаться в этих {{ .Values.some.deeply.nested.variable }}, а то будет вам хиросима и нигерсраки.

  4. GitOps с ArgoCD: Это, блядь, священный грааль для продакшена. Всё, что у тебя в кластере, должно быть описано в гите. ArgoCD смотрит в гит и орёт: «Ага, тут написано три реплики, а у тебя две! Щас я тебя, сука, порешаю!» — и сам всё приводит в порядок. Доверия к этому ебать ноль сначала, но потом привыкаешь.

    # Application manifest для ArgoCD
    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: api-backend
      namespace: argocd
    spec:
      project: default
      source:
        repoURL: 'git@github.com:my-org/k8s-manifests.git'
        targetRevision: HEAD
        path: apps/api/overlays/production
      destination:
        server: 'https://kubernetes.default.svc'
        namespace: production
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

    Получается, что если хочешь что-то поменять, ты не лезешь в кластер, как полупидор, а делаешь коммит. А если всё накрылось медным тазом — откатил коммит, и ArgoCD всё откатит. Красота, в общем. Но чувство, что какая-то мартышлюшка сидит и постоянно сравнивает твой гит с реальностью, сначала не покидает.