Menu Close

6장. 배포

6.1. Deployment 및 DeploymentConfig 오브젝트 이해

OpenShift Container Platform의 DeploymentDeploymentConfig API 오브젝트에서는 일반적인 사용자 애플리케이션을 세밀하게 관리할 수 있도록 유사하지만 서로 다른 두 가지 방법을 제공합니다. 이러한 오브젝트는 다음과 같이 별도의 API 오브젝트로 구성됩니다.

  • DeploymentConfig 또는 Deployment 오브젝트: 특정 애플리케이션 구성 요소에 대해 원하는 상태를 Pod 템플릿으로 설명합니다.
  • DeploymentConfig 오브젝트: 특정 시점의 배포 상태 레코드가 Pod 템플릿으로 포함되는 복제 컨트롤러가 한 개 이상 포함됩니다. 마찬가지로 배포 오브젝트에는 복제 컨트롤러를 대체하는 복제본 세트가 한 개 이상 포함됩니다.
  • 하나 이상의 Pod: 특정 버전의 애플리케이션 인스턴스를 나타냅니다.

6.1.1. 배포 블록 빌드

배포 및 배포 구성은 각각 기본 Kubernetes API 오브젝트인 ReplicaSetReplicationController를 빌딩 블록으로 사용하여 활성화됩니다.

사용자가 DeploymentConfig 오브젝트 또는 배포에서 다루는 복제 컨트롤러, 복제본 세트 또는 Pod를 조작할 필요가 없습니다. 배포 시스템을 통해 변경 사항이 적절하게 전파됩니다.

작은 정보

기존 배포 전략이 사용 사례에 적합하지 않고 배포 라이프사이클 중 수동 단계를 실행해야 하는 경우에는 사용자 정의 배포 전략을 생성해야 합니다.

다음 섹션에서는 이러한 오브젝트에 대해 자세히 설명합니다.

6.1.1.1. 복제 컨트롤러

복제 컨트롤러를 사용하면 항상 지정된 수의 Pod 복제본이 실행됩니다. Pod가 종료되거나 삭제되면 복제 컨트롤러가 작동하여 정의된 수까지 추가로 인스턴스화합니다. 마찬가지로 필요한 것보다 많은 Pod가 실행되고 있는 경우에는 정의된 수에 맞게 필요한 개수의 Pod를 삭제합니다.

복제 컨트롤러 구성은 다음과 같이 구성됩니다.

  • 런타임에 조정할 수 있는 원하는 복제본 수
  • 복제된 Pod를 생성할 때 사용할 Pod 정의
  • 관리형 Pod를 확인하는 선택기

선택기는 복제 컨트롤러에서 관리하는 Pod에 할당한 라벨 세트입니다. 이러한 라벨은 복제 컨트롤러에서 인스턴스화하는 Pod 정의에 포함됩니다. 복제 컨트롤러에서는 필요에 따라 조정할 수 있도록 선택기를 사용하여 이미 실행 중인 Pod의 인스턴스 수를 결정합니다.

복제 컨트롤러에서 로드나 트래픽을 추적하지 않으므로 로드 또는 트래픽을 기반으로 자동 스케일링하지 않습니다. 대신 외부 Autoscaler에서 복제본 수를 조정해야 합니다.

다음은 복제 컨트롤러 정의의 예입니다.

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend-1
spec:
  replicas: 1  1
  selector:    2
    name: frontend
  template:    3
    metadata:
      labels:  4
        name: frontend 5
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always
1
실행할 Pod의 사본 수입니다.
2
실행할 Pod의 라벨 선택기입니다.
3
컨트롤러에서 생성하는 Pod용 템플릿입니다.
4
Pod의 라벨에는 라벨 선택기의 해당 항목이 포함되어야 합니다.
5
매개변수를 확장한 후 최대 이름 길이는 63자입니다.

6.1.1.2. 복제본 세트

복제 컨트롤러와 유사하게 ReplicaSet은 지정된 수의 Pod 복제본을 언제든지 실행할 수 있는 기본 Kubernetes API 오브젝트입니다. 복제본 세트와 복제 컨트롤러의 차이점은 복제본 세트는 세트 기반 선택기 요구 사항을 지원하는 반면 복제 컨트롤러는 일치 기반 선택기 요구 사항만 지원한다는 점입니다.

참고

사용자 정의 업데이트 오케스트레이션이 필요한 경우에만 복제본 세트를 사용하거나 업데이트가 필요하지 않습니다. 그러지 않으면 배포를 사용하십시오. 복제본 세트는 독립적으로 사용할 수 있지만 배포에서 Pod 생성, 삭제, 업데이트를 오케스트레이션하는 데 사용합니다. 배포는 복제본 세트를 자동으로 관리하고 Pod에 선언적 업데이트를 제공하며 생성한 복제본 세트를 수동으로 관리할 필요가 없습니다.

다음은 ReplicaSet 정의의 예입니다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-1
  labels:
    tier: frontend
spec:
  replicas: 3
  selector: 1
    matchLabels: 2
      tier: frontend
    matchExpressions: 3
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always
1
리소스 집합에 대한 레이블 쿼리입니다. matchLabelsmatchExpressions의 결과는 논리적으로 결합됩니다.
2
선택기와 일치하는 라벨을 사용하여 리소스를 지정하는 일치 기반 선택기입니다.
3
키를 필터링하는 세트 기반 선택기입니다. 키가 tier이고 값이 frontend인 모든 리소스를 선택합니다.

6.1.2. DeploymentConfig 오브젝트

OpenShift Container Platform은 복제 컨트롤러를 기반으로 소프트웨어 개발 및 배포 라이프사이클에 대한 지원을 DeploymentConfig 오브젝트의 개념으로 확장합니다. 가장 간단한 경우 DeploymentConfig 오브젝트는 새 복제 컨트롤러를 생성하고 이 컨트롤러에서 Pod를 시작할 수 있도록 설정합니다.

그러나 DeploymentConfig 오브젝트의 OpenShift Container Platform 배포에서는 이미지의 기존 배포에서 새 버전으로 전환하는 기능도 제공하고 복제 컨트롤러를 생성하기 전이나 후에 실행할 후크도 정의합니다.

DeploymentConfig 배포 시스템에서는 다음 기능을 제공합니다.

  • 실행 중인 애플리케이션에 대한 템플릿인 DeploymentConfig 오브젝트
  • 이벤트에 대한 응답으로 자동 배포를 실행하는 트리거
  • 이전 버전에서 새 버전으로의 전환을 위한 사용자 정의 가능 배포 전략. 전략은 일반적으로 배포 프로세스라는 Pod 내에서 실행됩니다.
  • 배포 라이프사이클 중 다른 시점에서 사용자 정의 동작을 실행하는 일련의 후크(라이프사이클 후크)
  • 배포가 실패하는 경우 롤백을 수동 또는 자동으로 지원하기 위한 애플리케이션 버전 관리
  • 복제본 수동 스케일링 및 자동 스케일링

DeploymentConfig 오브젝트를 생성하면 DeploymentConfig 오브젝트의 Pod 템플릿을 나타내는 복제 컨트롤러가 생성됩니다. 배포가 변경되면 최신 Pod 템플릿을 사용하여 새 복제 컨트롤러가 생성되고 배포 프로세스가 실행되어 이전 복제 컨트롤러가 축소되고 새 복제 컨트롤러가 확장됩니다.

애플리케이션 인스턴스는 생성 시 서비스 로드 밸런서와 라우터 모두에서 자동으로 추가 및 제거됩니다. 애플리케이션에서 TERM 신호를 수신할 때 정상 종료를 지원하는 경우 실행 중인 사용자 연결을 정상적으로 완료할 수 있는 기회를 제공할 수 있습니다.

OpenShift Container Platform DeploymentConfig 오브젝트는 다음과 같은 세부 정보를 정의합니다.

  1. ReplicationController 정의의 요소
  2. 새 배포를 자동으로 생성하는 트리거
  3. 배포 간 전환을 위한 전략
  4. 라이프사이클 후크

배포가 수동 또는 자동으로 트리거될 때마다 배포자 Pod에서 배포를 관리합니다(이전 복제 컨트롤러 축소, 새 복제 컨트롤러 확장, 후크 실행 포함). 배포 Pod는 배포 로그를 유지하기 위해 배포 완료 후 무기한으로 유지됩니다. 배포가 다른 배포로 대체되면 필요한 경우 쉽게 롤백할 수 있도록 이전 복제 컨트롤러가 유지됩니다.

DeploymentConfig 정의의 예

apiVersion: v1
kind: DeploymentConfig
metadata:
  name: frontend
spec:
  replicas: 5
  selector:
    name: frontend
  template: { ... }
  triggers:
  - type: ConfigChange 1
  - imageChangeParams:
      automatic: true
      containerNames:
      - helloworld
      from:
        kind: ImageStreamTag
        name: hello-openshift:latest
    type: ImageChange  2
  strategy:
    type: Rolling      3

1
복제 컨트롤러 템플릿이 변경될 때마다 구성 변경 트리거를 통해 새 배포가 생성됩니다.
2
이름이 지정된 이미지 스트림에 새 버전의 백업 이미지가 제공될 때마다 이미지 변경 트리거를 통해 새 배포가 생성됩니다.
3
기본 Rolling 전략을 사용하면 배포 사이에 다운타임 없이 전환할 수 있습니다.

6.1.3. 배포

Kubernetes는 OpenShift Container Platform에서 Deployment라는 최상위 기본 API 오브젝트 유형을 제공합니다. Deployment 오브젝트는 OpenShift Container Platform 관련 DeploymentConfig 오브젝트의 하위 항목 역할을 합니다.

Deployment 오브젝트는 DeploymentConfig 오브젝트와 같이 특정 애플리케이션 구성 요소의 원하는 상태를 Pod 템플릿으로 설명합니다. 배포에서는 Pod 라이프사이클을 오케스트레이션하는 복제본 세트를 생성합니다.

예를 들어 다음 배포 정의에서는 하나의 hello-openshift Pod를 가져오는 복제본 세트를 생성합니다.

배포 정의

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-openshift
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-openshift
  template:
    metadata:
      labels:
        app: hello-openshift
    spec:
      containers:
      - name: hello-openshift
        image: openshift/hello-openshift:latest
        ports:
        - containerPort: 80

6.1.4. Deployment 및 DeploymentConfig 오브젝트 비교

OpenShift Container Platform에서는 Kubernetes Deployment 오브젝트와 OpenShift Container Platform 제공 DeploymentConfig 오브젝트가 모두 지원되지만 DeploymentConfig 오브젝트에서 제공하는 특정 기능 또는 동작이 필요하지 않는 한 Deployment 오브젝트를 사용하는 것이 좋습니다.

다음 섹션은 두 오브젝트 유형의 차이점에 대해 더 자세히 설명하여 사용할 유형을 결정하는 데 도움이 됩니다.

6.1.4.1. 설계

DeploymentDeploymentConfig 오브젝트의 중요한 차이점은 각 설계에서 롤아웃 프로세스에 대해 선택한 CAP theorem의 속성입니다. DeploymentConfig 오브젝트는 일관성을 선호하는 반면 Deployments 오브젝트는 일관성보다 가용성을 우선합니다.

DeploymentConfig 오브젝트의 경우 배포자 Pod를 실행하는 노드가 종료되면 대체되지 않습니다. 이 프로세스는 노드가 다시 온라인 상태가 될 때까지 기다리거나 수동으로 삭제됩니다. 노드를 수동으로 삭제하면 해당 Pod도 삭제됩니다. 즉 kubelet에서 연결된 Pod를 삭제해야 하므로 롤아웃을 해제하기 위해 Pod를 삭제할 수 없습니다.

그러나 배포 롤아웃은 컨트롤러 관리자에서 구동됩니다. 컨트롤러 관리자는 마스터에서 고가용성 모드로 실행되고 리더 선택 알고리즘을 사용하여 일관성보다 가용성을 중시합니다. 오류가 발생하는 동안 기타 마스터가 동일한 배포에서 동시에 작업할 수 있지만 이러한 문제는 오류 발생 직후 조정됩니다.

6.1.4.2. DeploymentConfig 오브젝트별 기능

자동 롤백

현재 배포에서는 배포에 실패하는 경우 성공적으로 배포된 마지막 복제본 세트로 자동 롤백되지 않습니다.

Trigger

배포의 Pod 템플릿이 변경될 때마다 새 롤아웃이 자동으로 트리거된다는 점에서 배포에는 암시적 구성 변경 트리거가 포함되어 있습니다. Pod 템플릿 변경 시 새 롤아웃을 수행하지 않으려면 배포를 정지하십시오.

$ oc rollout pause deployments/<name>
라이프사이클 후크

배포에서는 아직 라이프사이클 후크를 지원하지 않습니다.

사용자 정의 전략

배포에서는 사용자가 지정하는 사용자 정의 배포 전략을 아직 지원하지 않습니다.

6.1.4.3. 배포별 기능

롤오버

Deployment 오브젝트에 대한 배포 프로세스는 모든 새 롤아웃에 대해 배포자 Pod를 사용하는 DeploymentConfig 오브젝트와 달리 컨트롤러 반복문에 의해 실행됩니다. 즉 Deployment 오브젝트에는 활성 상태의 복제본 세트가 가능한 한 많이 있을 수 있습니다. 결국 배포 컨트롤러에서 이전 복제본 세트를 축소하고 최신 복제본 세트를 확장합니다.

DeploymentConfig 오브젝트에서는 최대 1개의 배포자 Pod를 실행할 수 있습니다. 그러지 않으면 여러 배포자가 최신이라고 생각하는 복제 컨트롤러를 확장하면서 충돌하게 됩니다. 이로 인해 어느 시점에 두 개의 복제 컨트롤러만 활성화할 수 있습니다. 결국 Deployment 오브젝트에 대한 신속한 롤아웃이 더 빨라집니다.

비례 스케일링

배포 컨트롤러는 배포에서 다루는 새 복제본 세트 및 이전 복제본 세트 크기에 대한 유일한 정보 소스이므로 지속적 롤아웃을 스케일링할 수 있습니다. 추가 복제본은 각 복제본 세트의 크기에 비례하여 배포됩니다.

롤아웃이 진행 중일 때는 컨트롤러의 배포자 프로세스에 새 복제 컨트롤러 크기에 대한 문제가 발생하기 때문에 배포를 스케일링할 수 없습니다.

롤아웃 중 정지

배포는 언제든지 정지할 수 있습니다. 따라서 지속적인 롤아웃도 정지할 수 있습니다. 반면 현재 배포자 Pod는 정지할 수 없으므로 롤아웃 중 배포를 정지하려고 해도 배포자 프로세스는 영향을 받지 않고 완료될 때까지 계속 수행됩니다.