Как можно вынести общие конфиги микросервисов для деплоя в Kubernetes?

# Вынесение общих конфигов микросервисов в Kubernetes

В Kubernetes существует несколько подходов для управления конфигурациями микросервисов. Правильное вынесение конфигов позволяет переиспользовать манифесты и упростить деплой.

1. ConfigMaps для конфигов приложения

ConfigMap хранит конфигурационные данные в виде пар ключ-значение:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  application.properties: |
    server.port=8080
    logging.level=INFO
    database.pool.size=10
  database.url=jdbc:mysql://mysql-service:3306/appdb

Использование в Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  template:
    spec:
      containers:
      - name: api
        image: myregistry/api:latest
        envFrom:
        - configMapRef:
            name: app-config
        volumeMounts:
        - name: config
          mountPath: /etc/config
      volumes:
      - name: config
        configMap:
          name: app-config

2. Secrets для чувствительных данных

Secrets предназначены для хранения конфиденциальных данных (пароли, токены, API ключи):

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  DB_USER: dXNlcm5hbWU=  # base64 encoded
  DB_PASSWORD: cGFzc3dvcmQ=  # base64 encoded

Или с явными значениями (будут автоматически закодированы):

apiVersion: v1
kind: Secret
metadata:
  name: docker-secret
type: kubernetes.io/dockercfg
data:
  .dockercfg: eyJteXJlZ2lzdHJ5LmNvbSI6eyJhdXRoIjoiWFhYWFhYIn19

3. Kustomize для переиспользования манифестов

Kustomize позволяет составлять разные конфигурации из общей базы:

Структура директорий

k8s/
├── base/
│   ├── kustomization.yaml
│   ├── deployment.yaml
│   ├── service.yaml
│   └── configmap.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── config-patch.yaml
    ├── staging/
    │   ├── kustomization.yaml
    │   └── config-patch.yaml
    └── prod/
        ├── kustomization.yaml
        └── config-patch.yaml

base/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - deployment.yaml
  - service.yaml
  - configmap.yaml

commonLabels:
  app: my-service
  version: v1

base/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: api
        image: myregistry/api:latest
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"

overlays/prod/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
  - ../../base

replicas:
  - name: api-service
    count: 5

patches:
  - target:
      kind: Deployment
      name: api-service
    patch: |-
      - op: replace
        path: /spec/template/spec/containers/0/resources/limits/memory
        value: "2Gi"
      - op: replace
        path: /spec/template/spec/containers/0/resources/limits/cpu
        value: "2000m"

configMapGenerator:
  - name: app-config
    behavior: merge
    literals:
      - ENVIRONMENT=production
      - LOG_LEVEL=WARN

4. Helm для управления релизами

Helm — это пакетный менеджер для Kubernetes, позволяющий параметризовать манифесты:

Chart структура

chart/
├── Chart.yaml
├── values.yaml
├── values-prod.yaml
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    ├── configmap.yaml
    └── secret.yaml

values.yaml

replicaCount: 2

image:
  repository: myregistry/api
  tag: "1.0.0"
  pullPolicy: IfNotPresent

config:
  environment: development
  logLevel: INFO
  databaseUrl: jdbc:mysql://mysql:3306/appdb
  poolSize: 10

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

services:
  - name: auth-service
    url: http://auth-service:8080
  - name: payment-service
    url: http://payment-service:8080

templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "chart.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        env:
        - name: ENVIRONMENT
          value: "{{ .Values.config.environment }}"
        - name: LOG_LEVEL
          value: "{{ .Values.config.logLevel }}"
        - name: DATABASE_URL
          value: "{{ .Values.config.databaseUrl }}"
        resources:
          {{- toYaml .Values.resources | nindent 10 }}

Деплой с разными конфигами:

# Development
helm install api ./chart -f chart/values.yaml

# Production
helm install api ./chart -f chart/values-prod.yaml

# С переопределением
helm install api ./chart --set replicaCount=5 --set image.tag=2.0.0

5. Environment-based конфигурация

Для Java приложений можно использовать Spring Boot profiles:

apiVersion: v1
kind: ConfigMap
metadata:
  name: spring-profiles
data:
  SPRING_PROFILES_ACTIVE: "k8s,prod"

И соответствующие application-prod.yml в приложении.

Рекомендации

1. Для конфигов — используй ConfigMaps
2. Для секретов — используй Secrets (рассмотри External Secrets для интеграции с хранилищами)
3. Для переиспользования — выбери Kustomize или Helm в зависимости от сложности
4. Версионирование — коммити все конфиги в Git (кроме production secrets)
5. Разделение — отдельные конфиги для dev/staging/prod
6. Мониторинг — логируй все изменения конфигов через ConfigMap revisions

для простых проектов достаточно ConfigMap + Kustomize, для сложных микросервисных систем Helm дает больше возможностей.