Openshift Deployment & DeploymentConfig
원문 : 호롤리한하루/Openshift Deployment & DeploymentConfig
Overview
Openshift는 pod을 배포할 때, 크게 Deployment와 DeploymentConfig 두가지 방식으로 배포합니다.
이번 포스팅에서는 두 배포 방식의 차이점을 알아보고, DeploymentConfig방식을 직접 테스트해보도록 하겠습니다.
Prerequisites
- Openshift v4이상 클러스터
1. ReplicaSet & ReplicationController
쿠버네티스의 Deployment와 마찬가지로 Openshift의 Deployment와 DeploymentConfig도 Pod의 복제본을 담당하는 컨트롤러를 포함하고 있습니다.
- Deployment : 하나이상의
ReplicaSet을 포함 - DeploymentConfig: 하나이상의
ReplicationController를 포함
쿠버네티스의 복제컨트롤러들과 동일한 역할을 합니다.
간단히 설명을 하고 넘어가도록 하겠습니다.
ReplicationController
# 예시파일
apiVersion: v1
kind: ReplicationController
metadata:
name: frontend-1
spec:
replicas: 1
selector:
name: frontend
template:
metadata:
labels:
name: frontend
spec:
containers:
- image: openshift/hello-openshift
name: helloworld
ports:
- containerPort: 8080
protocol: TCP
restartPolicy: Always- pod의 복제본을 설장한 수대로 유지 (
replicas) - selector로 관리하고자하는 pod을 선택
- equality-based Selector 사용
- 로드나 트래픽 기반 오토스케일링은 지원하지 않음
ReplicaSet
# 예시파일
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend-1
labels:
tier: frontend
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
matchExpressions:
- {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- ReplicationController와 비슷한 기능 제공
- 차이점은 Set-based Selector를 사용한다는 점
(in notin exist 등)
ReplicationController는 label과 일치하는 name의 pod만 관리할 수 있다면
ReplicaSet은 연산자를 사용해 좀더 풍부한 표현식을 사용해 pod을 관리할 수 있다는 게 차이점입니다.
2. Deployment & DeploymentConfig
Deployment
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- 하나 이상의
ReplicaSet포함 - 배포 라이프사이클을 위한 기능을 지원
- Controller Manager가 배포 프로세스를 관리
- 배포할 노드가 죽어도 ControllerManager가 관리하기때문에 다른 마스터에서 배포 관리 가능 (가용성 중시)
- 중간에 롤아웃 일시중지가능
DeploymentConfig
apiVersion: v1
kind: DeploymentConfig
metadata:
name: frontend
spec:
replicas: 5
selector:
name: frontend
template: { ... }
triggers:
- type: ConfigChange
- imageChangeParams:
automatic: true
containerNames:
- helloworld
from:
kind: ImageStreamTag
name: hello-openshift:latest
type: ImageChange
strategy:
type: Rolling - 하나 이상의
ReplicationController포함 - 배포 라이프사이클을 위한 기능을 지원
- build이벤트에 따른 자동 배포 트리거
- 업데이트가 있을 시, strategy 지정 가능
- roll-back
- Deployer pod이 배포프로세스를 관리
- 배포할 노드가 죽으면 노드가 온라인상태가 되거나 수동으로 삭제할 때까지 기다림 (일관성 중시)
- LifeCycle hook
- custom strategies
DeploymentConfig 다뤄보기!
DeploymentConfig 배포
web gui에서 sample app을 deploymentconfig형식으로 배포해줍시다
DeploymentConfig 확인
$ oc get dc
Rollout
deploymentconfig의 버전을 1증가하여 업데이트하는 명령어입니다.
$ oc rollout latest dc/{dc name}
deploymentconfig.apps.openshift.io/php-app-00 rolled out
history
현재까지 진행된 deploymentconfig의 rollout history를 확인하는 명령어입니다.
$ oc rollout history dc/php-app-00
특정 revision의 deploymentconfig 상세정보를 확인하려면 revision 파라미터를 사용하면 됩니다.
$ oc rollout history dc/php-app-00 --revision=1
더 상세한 정보를 얻으려면 describe 명령어를 사용하면 됩니다.
$ oc describe dc php-app-0
deployment 재시도
DeploymentConfig의 배포가 실패했을 때 배포를 재시도하려면 retry 명령어를 사용합니다.
$ oc rollout retry dc/php-app-00
배포에 실패한 dc에만 사용할 수 있는 명령어여서 지금은 complete상태이므로 error가 발생합니다.
추가로 retry는 단순히 실패한 배포를 다시 실행할 뿐, 새로운 revision은 생성하지 않습니다.
deployment rolling back
이전 버전으로 롤백하려면 undo명령어를 사용합니다.
$ $ oc rollout undo dc/php-app-00
deploymentconfig.apps.openshift.io/php-app-00 rolled back
undo한 것도 버전으로 기록되어서 revision이 3이 됩니다.
특정 버전으로 롤백하려면 --to-revision파라미터를 추가하면 됩니다.
deployment log
로그를 확인하려면 logs명령어를 사용합니다.
$ oc logs -f dc/php-app-00
특정 버전의 log를 확이하려면 --version 파라미터를 추가하면 됩니다.
deployment scale
deploymentconfig는 pod의 개수도 관리를 하고 있습니다. replica의 개수를 조정하려면 scale명령어를 사용하면 됩니다.
$ oc scale dc/php-app-00 --replicas=3
deploymentconfig.apps.openshift.io/php-app-00 scaled
replica를 1->3으로 올리니 두 개가 더 생성된 것을 확인 가능합니다.