Что такое Deployment в OpenShift?

# Deployment в OpenShift: архитектура и концепции

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

Deployment в OpenShift - это объект Kubernetes (с расширениями OpenShift), который управляет развёртыванием и автоматическим обновлением приложения. Это декларативное описание: "я хочу 3 копии этого контейнера работающих одновременно".

OpenShift контекст

OpenShift - это Kubernetes для enterprise с дополнительными возможностями:

Kubernetes + OpenShift Extensions
├── Kubernetes core (containment, orchestration)
└── OpenShift additions:
    ├── Routes (вместо Ingress)
    ├── Deployment Configs (расширение Deployment)
    ├── Integrated image registry
    ├── Source-to-Image (S2I) builds
    ├── Built-in CI/CD (Jenkins, Tekton)
    ├── Project isolation (RBAC)
    └── Developer console

Что такое Deployment объект?

YAML описание (manifest)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
  namespace: production
  labels:
    app: user-service
    version: v1

spec:
  # Сколько реплик (копий) запустить
  replicas: 3
  
  # Как выбирать Pods для этого Deployment
  selector:
    matchLabels:
      app: user-service
  
  # Стратегия обновления
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Можно добавить 1 лишний pod
      maxUnavailable: 0  # Нельзя выключать pods
  
  # Шаблон для создания pods
  template:
    metadata:
      labels:
        app: user-service
    
    spec:
      # Контейнер
      containers:
      - name: user-service
        image: quay.io/mycompany/user-service:1.2.3
        imagePullPolicy: Always
        
        # Порты
        ports:
        - containerPort: 8080
          name: http
        
        # Переменные окружения
        env:
        - name: DATABASE_HOST
          value: postgres.production.svc.cluster.local
        - name: LOG_LEVEL
          value: INFO
        - name: API_KEY
          valueFrom:
            secretKeyRef:
              name: api-credentials
              key: key
        
        # Проверки здоровья
        livenessProbe:           # Жив ли контейнер?
          httpGet:
            path: /health/live
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        
        readinessProbe:          # Готов ли принимать трафик?
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
        
        # Ресурсы
        resources:
          requests:  # Минимум для старта
            cpu: 100m
            memory: 256Mi
          limits:    # Максимум (kill если превышит)
            cpu: 500m
            memory: 512Mi
        
        # Volumes
        volumeMounts:
        - name: config
          mountPath: /etc/config
      
      # Volume источники
      volumes:
      - name: config
        configMap:
          name: user-service-config

Как Deployment работает

Пошагово при создании

1. kubectl apply -f deployment.yaml
   ↓
2. Kubernetes создаёт объект Deployment
   ↓
3. Deployment Controller видит: нужно 3 реплики
   ↓
4. Создаёт ReplicaSet (управляет набором pods)
   ↓
5. ReplicaSet создаёт 3 Pod objects
   ↓
6. Pod Controller ищет Node с достаточными ресурсами
   ↓
7. Запускает контейнер на выбранном Node
   ↓
8. Container Runtime (Docker/Podman) запускает контейнер
   ↓
9. Kubernetes ждёт readinessProbe успешного ответа
   ↓
10. Pod готов к трафику

Иерархия объектов

Deployment (user-service)
  ↓
  └── ReplicaSet (user-service-7f3b2c)
      ├── Pod (user-service-7f3b2c-abc1)
      │   └── Container (user-service)
      │       └── Process (java -jar...)
      ├── Pod (user-service-7f3b2c-abc2)
      │   └── Container
      │       └── Process
      └── Pod (user-service-7f3b2c-abc3)
          └── Container
              └── Process

Deployment стратегии обновления

1. RollingUpdate (по умолчанию)

Старое:  [v1.0] [v1.0] [v1.0]  (3 pods)

Обновление до v2.0:
Шаг 1:   [v1.0] [v1.0] [v2.0]  (запускаем v2.0)
Шаг 2:   [v1.0] [v2.0] [v2.0]  (убиваем v1.0)
Шаг 3:   [v2.0] [v2.0] [v2.0]  (убиваем v1.0)

Преимущества:
- Zero downtime
- Можно откатить если что-то пошло не так

Недостатки:
- Время обновления дольше

2. Recreate (быстро, но downtime)

Старое:  [v1.0] [v1.0] [v1.0]

Обновление до v2.0:
Шаг 1:   [ - ] [ - ] [ - ]  (убиваем все)
Шаг 2:   [v2.0] [v2.0] [v2.0]  (запускаем новые)

Преимущества:
- Быстро
- Не дублируются версии

Недостатки:
- Downtime во время обновления

OpenShift vs Kubernetes Deployment

ОpenShift имеет DeploymentConfig (legacy) и Deployment (modern):

# Kubernetes Deployment
apiVersion: apps/v1
kind: Deployment

# OpenShift DeploymentConfig (старо)
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
spec:
  triggers:  # Автоматическое обновление при изменении image
  - type: ConfigChange
  - type: ImageChange
    imageChangeParams:
      automatic: true
      containerNames:
      - user-service
      from:
        kind: ImageStreamTag
        name: user-service:latest

OpenShift S2I (Source-to-Image)

ОpenShift может автоматически:

1. Взять исходный код из Git
2. Собрать образ контейнера
3. Запустить контейнер через Deployment

# Одна команда для всего
oc new-app java~https://github.com/user/project.git \
  --name=user-service

# OpenShift:
# 1. Клонирует repo
# 2. Находит Java (pom.xml)
# 3. Собирает JAR
# 4. Создаёт образ
# 5. Пушит в registry
# 6. Создаёт Deployment
# 7. Запускает

Практический пример: развёртывание Java приложения

Шаг 1: Создать ImageStream (для отслеживания версий)

apiVersion: image.openshift.io/v1
kind: ImageStream
metadata:
  name: user-service
spec:
  lookupPolicy:
    local: false

Шаг 2: Создать Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 3
  
  selector:
    matchLabels:
      app: user-service
  
  template:
    metadata:
      labels:
        app: user-service
    
    spec:
      containers:
      - name: user-service
        image: quay.io/mycompany/user-service:1.0.0
        imagePullPolicy: Always
        
        ports:
        - containerPort: 8080
        
        env:
        - name: JAVA_OPTS
          value: \"-Xmx256m -Xms128m\"
        - name: SPRING_PROFILES_ACTIVE
          value: \"production\"
        
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 45
          periodSeconds: 10
        
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          initialDelaySeconds: 20
          periodSeconds: 5
        
        resources:
          requests:
            memory: \"256Mi\"
            cpu: \"100m\"
          limits:
            memory: \"512Mi\"
            cpu: \"500m\"

Шаг 3: Создать Service (для сетевого доступа)

apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  type: ClusterIP  # Внутри кластера
  selector:
    app: user-service
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Шаг 4: Создать Route (для наружного доступа)

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: user-service
spec:
  host: user-service.example.com
  to:
    kind: Service
    name: user-service
  tls:
    termination: edge  # HTTPS с самоподписанным

Шаг 5: Деплоить

oc apply -f deployment.yaml
oc apply -f service.yaml
oc apply -f route.yaml

# Проверить статус
oc get pods
oc logs pod/user-service-xyz

# Обновить image (запустит новые pods)
oc set image deployment/user-service \
  user-service=quay.io/mycompany/user-service:1.1.0

Мониторинг Deployment

# Список deployments
oc get deployments

# Детали
oc describe deployment user-service

# Логи всех pods
oc logs deployment/user-service --tail=100 -f

# События
oc get events

# Откатить последнее обновление
oc rollout undo deployment/user-service

# История
oc rollout history deployment/user-service

Ответ на собеседовании

Правильный ответ: "Deployment в OpenShift (или Kubernetes) - это объект, который декларативно описывает, как должно работать приложение. Например: \"я хочу 3 копии моего Java приложения работающих одновременно\". Deployment управляет автоматическим обновлением контейнеров используя RollingUpdate стратегию - убивает старые pods и запускает новые без downtime. Он также обеспечивает self-healing: если pod упадёт, Deployment автоматически запустит новый. OpenShift расширяет Kubernetes добавляя Routes для внешнего доступа, ImageStreams для отслеживания версий, и S2I для автоматической сборки из исходного кода. Я использую Deployment для управления жизненным циклом приложения в production: обновления, масштабирование, откаты."