6.2. 배포 이해

ReplicaSet 은 지정된 수의 Pod 복제본이 언제든지 실행되도록 하는 기본 Kubernetes API 오브젝트입니다.

다음은 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

복제본 세트와 유사하게 복제 컨트롤러는 항상 지정된 수의 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

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

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

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

롤오버

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

DeploymentConfig 오브젝트는 최대 하나의 배포자 Pod를 실행할 수 있습니다. 그러지 않으면 최신 복제 컨트롤러여야 하는 항목을 확장하려고 할 때 여러 배포자가 충돌할 수 있습니다. 이로 인해 어느 시점에 두 개의 복제 컨트롤러만 활성화할 수 있습니다. 결과적으로 Deployment 오브젝트에 대한 신속한 롤아웃이 빨라집니다.

비례 스케일링

배포 컨트롤러는 Deployment 오브젝트가 소유한 신규 및 이전 복제본 세트 크기에 대한 유일한 정보 소스이므로 지속적인 롤아웃을 확장할 수 있습니다. 추가 복제본은 각 복제본 세트의 크기에 비례하여 배포됩니다.

컨트롤러에서 새 복제 컨트롤러 크기에 대한 배포자 프로세스에 문제가 있기 때문에 롤아웃이 진행 중인 경우 DeploymentConfig 오브젝트를 스케일링할 수 없습니다.

롤아웃 중 정지

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

자동 롤백

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

Trigger

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

$ oc rollout pause deployments/<name>

라이프사이클 후크

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

사용자 정의 전략

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