Какой использовал оркестратор контейнеров в DevOps?

Container Orchestration: Kubernetes vs Docker Swarm — Мой Опыт

Основной Оркестратор: Kubernetes

В моей карьере я использовал Kubernetes как основной контейнер-оркестратор в 3+ крупных проектах. Это фактически industry standard в 2025 году.

Почему Kubernetes?

Ключевые преимущества:

• Auto-scaling: горизонтальное масштабирование по CPU/custom metrics
• Self-healing: автоматический перезапуск упавших pods
• Rolling updates: zero-downtime deployments
• Network policies: built-in микросегментация
• Resource management: resource requests/limits

Архитектура K8s в Моих Проектах

# Пример Kubernetes deployment для Java микросервиса
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
  namespace: production
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: payment-service
  template:
    metadata:
      labels:
        app: payment-service
        version: v2.1.0
    spec:
      containers:
      - name: payment-service
        image: myregistry.azurecr.io/payment-service:v2.1.0
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 8080
        - name: metrics
          containerPort: 9090
        
        # Health checks
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          initialDelaySeconds: 20
          periodSeconds: 5
        
        # Resource requests/limits
        resources:
          requests:
            cpu: 500m
            memory: 512Mi
          limits:
            cpu: 1000m
            memory: 1Gi
        
        # Environment variables
        env:
        - name: JAVA_OPTS
          value: "-XX:+UseG1GC -XX:MaxGCPauseMillis=200"
        - name: SPRING_PROFILES_ACTIVE
          value: "production"
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: url
        
        # Security context
        securityContext:
          runAsNonRoot: true
          runAsUser: 1000
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
        
        # Volume mounts
        volumeMounts:
        - name: tmp
          mountPath: /tmp
        - name: config
          mountPath: /app/config
          readOnly: true
      
      # Pod disruption budget (для graceful shutdowns)
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - payment-service
              topologyKey: kubernetes.io/hostname
      
      volumes:
      - name: tmp
        emptyDir: {}
      - name: config
        configMap:
          name: payment-service-config

---
# Horizontal Pod Autoscaler
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: payment-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payment-service
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 15
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15
      - type: Pods
        value: 4
        periodSeconds: 15
      selectPolicy: Max

---
# Service для exposing приложения
apiVersion: v1
kind: Service
metadata:
  name: payment-service
spec:
  type: ClusterIP
  selector:
    app: payment-service
  ports:
  - name: http
    port: 8080
    targetPort: 8080
    protocol: TCP
  - name: metrics
    port: 9090
    targetPort: 9090

CI/CD Pipeline с Kubernetes

# Мой типичный deployment workflow
#!/bin/bash

# 1. Build Docker image
docker build -t myregistry.azurecr.io/payment-service:${VERSION} .
docker push myregistry.azurecr.io/payment-service:${VERSION}

# 2. Update deployment в git (GitOps подход)
sed -i "s|image: myregistry.*|image: myregistry.azurecr.io/payment-service:${VERSION}|" k8s/deployment.yaml
git commit -m "Deploy payment-service:${VERSION}"
git push origin main

# 3. ArgoCD автоматически синхронизирует кластер с git
# (или используем kubectl apply если без GitOps)

# 4. Мониторим rollout
kubectl rollout status deployment/payment-service -n production

# 5. Откатываем если нужно
kubectl rollout undo deployment/payment-service -n production

Мониторинг и Logging в K8s

# Prometheus scrape config для Java приложения
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
data:
  prometheus.yml: |
    scrape_configs:
    - job_name: 'kubernetes-pods'
      kubernetes_sd_configs:
      - role: pod
      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__

Сравнение с Docker Swarm

Так как я использовал также Docker Swarm в одном проекте:

Мой выбор: Kubernetes для всех production систем, Docker Swarm только для внутреннего/legacy.

Инструменты и Stack

Каждый проект с K8s включал:

Kubernetes (K8s/EKS/AKS) ← оркестрация контейнеров
    ├─ kubectl ← управление
    ├─ Helm ← package manager
    └─ ArgoCD ← GitOps deployment

Monitoring & Logging:
    ├─ Prometheus + Grafana ← metrics
    ├─ ELK Stack / Loki ← logs
    └─ Jaeger ← distributed tracing

Security:
    ├─ Network Policies ← микросегментация
    ├─ RBAC (Role-Based Access Control) ← авторизация
    └─ Pod Security Policies ← container security

Service Mesh (для микросервисов):
    ├─ Istio ← traffic management
    └─ Kiali ← visualization

Реальные Проблемы и Решения

Проблема 1: Memory Leaks в JVM

# Решение: правильные limits в Kubernetes
resources:
  requests:
    memory: 512Mi
  limits:
    memory: 1Gi

# + JVM flags для G1GC
JAVA_OPTS: "-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:G1NewCollectionHookedIntoHotspotLoggingOutput=true"

Проблема 2: Slow Startup Time

# Решение: отсрочить readiness check
readinessProbe:
  initialDelaySeconds: 60  # для Java app startup
  periodSeconds: 10
  timeoutSeconds: 5
  successThreshold: 1
  failureThreshold: 3

Проблема 3: Network Partitions

# Решение: PodDisruptionBudget + Anti-affinity
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-service-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: payment-service

Заключение

Кубернетес — это новый стандарт для deployment Java приложений в 2025. Хотя он сложен, это инвестиция, которая окупается через:

• Reliability: автоматическое восстановление
• Scalability: горизонтальное масштабирование
• DevOps efficiency: меньше manual операций
• Cost optimization: лучшее использование ресурсов

Для карьеры Java developer: знание Kubernetes это практически обязательно для senior позиций.