Minikube 와 함께하는 Kubernetes Study 2

Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

yundream
2023-02-09
2023-01-23
14954

## Kubernetes deployment
[Minikube 와 함께하는 Kubernetes 목차](https://www.joinc.co.kr/w/kubernetes_minikube_index)

쿠버네티스의 최소 배포단위는 POD이다. POD는 실질적인 (컨테이너)프로세스이고, Service 형태로 외부에 노출된다. POD은 프로세스이므로 프로세스의 사양 즉 **프로세스의 이름, 프로세스를 실행할 컨테이너 이미지이름, 사용할 포트**등의 명세서가 필요하다. 또한 Pod의 복제본 수, 업데이트되는 코드의 롤아웃/롤백 정보 등 배포에 필요한 정보들도 있어야 한다.

쿠버네티스는 프로덕션 환경에서 애플리케이션의 배포, 확장, 업데이트와 관련된 작업 과 반복적으로 수행해야 하는 기능을 자동화 하기 위해서 사용한다. 쿠버네티스 Deployment 컨트롤러는 Pod와 노드의 상태를 모니터링 하고 있다가 장애가 발생하면 (Deployment 명세에 따라서) Pod를 새로 실행하거나 교체하는 등의 작업을 자동으로 수행한다.

아래는 NginX를 실행하기 위한 deployment 설정파일이다. 파일 이름은 nginx.yaml로 했다. 
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
```
* spec : 애플리케이션의 스펙정보가 들어간다.
* spec.replicas : 몇 개의 POD를 실행할 것인지 설정한다. 여기에서는 3개를 실행하도록 설정했다.
* spec.selector : Deployment가 관리할 POD를 찾기 위해서 사용한다. 여기에서는 app: nginx 라벨이 붙은 POD를 관리하도록 설정했다.
* template 필드는 POD 컨테이너를 생성하기 위한 상세정보들이 들어간다.
	* image : POD 컨테이너를 실행할 이미지를 설정한다. 
	* ports : POD 컨테이너의 포트를 설정한다.
 
이 deployment 설정파일로 만들어지는 deployment 의 구조는 아래와 같을 것이다.

![deployment](https://docs.google.com/drawings/d/e/2PACX-1vQiGW8V2HnnQSeejskXmIh2DUJqJLd5Qm6ceQQJ00cIpdt5JEHPv_R2nJ5i8TaG9hlN8lEsrfPax37p/pub?w=434&h=279)

## deployments 생성
kubectl apply 명령을 이용해서 deployment 설정파일로 부터 deployment를 실행할 수 있다.
```shell
$ kubectl apply -f ./nginx.yaml 
deployment.apps/nginx-deployment created
```

**get deployments** 명령으로 deploy 상태를 확인해보자.
```shell
$ kubectl get deployments
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           16s
```
nginx.yaml 설정 내용대로 deploy 된 것을 확인 할 수 있다.
* NAME : 현재 네임스페이스(name space)에 실행된 deployment의 이름
* READY : 사용자가 요청한 리플리카의 갯수와 현재 실행된 리플리카의 갯수
* AVAILABLE : 사용할 수 있는 리플리카의 수
* AGE : 실행시간

**rollout** 명령으로 deployment의 상태를 확인할 수 있다.
```shell
$ kubectl rollout status deployment/nginx-deployment
deployment "nginx-deployment" successfully rolled out
```

**get rs** 명령으로 리플리카셋의 정보를 확인 할 수 있다.
```shell
$ kubectl get rs                                    
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-85996f8dbd   3         3         3       38m
```

### Deployment Update
애플리케이션은 버전이 업데이트 되거나 리플리카가 변경되는 등 다양한 변경작업이 있을 수 있다. deployment는 yaml 설정파일을 수정하고 update 하는 것으로 업데이트 할 수 있다. 리플리카를 3에서 4로 증가시키도록 설정파일을 수정했다.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
```
**apply** 명령을 수행하면 자동으로 rollout 된다.
```shell
$ kubectl apply -f ./nginx.yaml 
deployment.apps/nginx-deployment configured
```
get deployments로 확인해보자.
```shell
$ kubectl get deployments      
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   4/4     4            4           73m
```

이제 nginx 버전을 1.16.1로 업그레이드 시켜보자.
```yaml
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1
        ports:
        - containerPort: 80
```
다시 rollout 하고 **describe** 명령으로 상세정보를 확인해보자.
```
$ kubectl describe deployments            
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Sun, 12 Feb 2023 18:50:04 +0900
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 2
Selector:               app=nginx
Replicas:               4 desired | 4 updated | 4 total | 4 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.16.1
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-66f8758855 (4/4 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  77m    deployment-controller  Scaled up replica set nginx-deployment-85996f8dbd to 3
  Normal  ScalingReplicaSet  5m37s  deployment-controller  Scaled up replica set nginx-deployment-85996f8dbd to 4 from 3
  Normal  ScalingReplicaSet  57s    deployment-controller  Scaled up replica set nginx-deployment-66f8758855 to 1
  Normal  ScalingReplicaSet  57s    deployment-controller  Scaled down replica set nginx-deployment-85996f8dbd to 3 from 4
  Normal  ScalingReplicaSet  57s    deployment-controller  Scaled up replica set nginx-deployment-66f8758855 to 2 from 1
  Normal  ScalingReplicaSet  48s    deployment-controller  Scaled down replica set nginx-deployment-85996f8dbd to 2 from 3
  Normal  ScalingReplicaSet  48s    deployment-controller  Scaled up replica set nginx-deployment-66f8758855 to 3 from 2
  Normal  ScalingReplicaSet  47s    deployment-controller  Scaled down replica set nginx-deployment-85996f8dbd to 1 from 2
  Normal  ScalingReplicaSet  47s    deployment-controller  Scaled up replica set nginx-deployment-66f8758855 to 4 from 3
  Normal  ScalingReplicaSet  46s    deployment-controller  Scaled down replica set nginx-deployment-85996f8dbd to 0 from 1

```

### rollout 히스토리
애플리케이션이 업데이트하면서 deployment의 정보 또한 계속 변경된다. **rollout history deploy**명령으로 rollout 히스토리를 확인할 수 있다. 
```shell
$ kubectl rollout history deploy nginx-deployment   
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
```
문서의 내용대로 따라왔다면 지금까지 두번의 rollout을 확인 할 수 있을 것이다. 각 rollout의 상세정보를 확인해보자. 뒤에 **--revision={revision}** 옵션을 설정하면 각 revision의 상세정보를 출력한다. revision 1 과 2의 정보를 출력해보자.
```
$ kubectl rollout history deploy nginx-deployment --revision=1
deployment.apps/nginx-deployment with revision #1
Pod Template:
  Labels:	app=nginx
	pod-template-hash=85996f8dbd
  Containers:
   nginx:
    Image:	nginx:1.14.2
    Port:	80/TCP
    Host Port:	0/TCP
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>

$ kubectl rollout history deploy nginx-deployment --revision=2
deployment.apps/nginx-deployment with revision #2
Pod Template:
  Labels:	app=nginx
	pod-template-hash=66f8758855
  Containers:
   nginx:
    Image:	nginx:1.16.1
    Port:	80/TCP
    Host Port:	0/TCP
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>
```

### 배포 롤백하기
배포한 애플리케이션에 문제가 생겼다면 이를 롤백(되돌려야)한다. **rollout undo deploy** 명령으로 이전 revision 정보로 롤백할 수 있다. 현재 revision은 2이므로 여기에서 롤백하면 nginx 1.14.2 버전으로 롤백할 것이다.
```shell
$ kubectl rollout undo deploy nginx-deployment
```
제대로 롤백됐는지 deployments 정보를 확인해보자.
```shell
$ kubectl describe deployments
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Sun, 12 Feb 2023 18:50:04 +0900
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 3
Selector:               app=nginx
Replicas:               4 desired | 4 updated | 4 total | 4 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.14.2
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-85996f8dbd (4/4 replicas created)
```
롤백은 이전 revision 정보를 이용해서 롤백하는 거지, 이전 revision으로 되돌아가는 건 아니다. 따라서 revision은 항상 증가한다. revision: 3 인것을 확인할 수 있다.

**--to-revision={revision}** 옵션을 이용하면 특정 revsion으로 되돌릴 수 있다.
```
$ kubectl rollout history deploy nginx-deployment --to-revision=2
```
### Kubernetes의 배포 전략
Kubernetes는 다양한 환경에서 작동하는 애플리케이션을 위한 여러 배포 전략을 제공한다. 애플리케이션의 상태를 정의 하면 Deploy controller이 정의에 따라서 배포작업을 수행한다.

여기에서는 배포 전략을 소개만 한다. 실질적인 구성 방법은 다른 문서에서 소개한다.

**Recreate Deployment**

![Recreate Deployment](https://docs.google.com/drawings/d/e/2PACX-1vRiN-5VXi0zIKTJH2oqscSV7GhMQp_9Bwpn0r_T2JmFXyO4Mhb4kcK6b2qYoJeI5k_WnANtvb7aLkkc/pub?w=753&h=342)

현재 실행 중인 pod 인스턴스를 종료하고 새 버전으로 **동시에 새로 실행**한다. 이 때문에 애플리케이션 중단을 막을 수 없으며, 복구(롤백) 프로세스를 돌리는데에도 시간지연이 발생한다.

이 전략은 간단하고 빠르고 저렴하다는 장점이 있다. 하지만 가장 위험한 배포전략으로 모범 사례에 속하지 않는다. 서비스가 비즈니스, 미션, 수익에 중요하지 않는 경우, 근무 시간외에 배포해도 괜찮은 경우, 개발이나 스테이징 환경 등에 주로 사용한다.

**Rolling Update Deployment**

![Rolling Deployment](https://docs.google.com/drawings/d/e/2PACX-1vQTBuWHpAbFtUiE2tNqcEH44iF8kOp9oiKbM8k5lSxrkgYLnXp_h53WNAz5ej1y9NizeFLT9A6FuUsq/pub?w=841&h=357)

롤링 업데이트는 실행 중인 애플리케이션 인스턴스를 **순차적으로 새 릴리즈로 업데이트**하는 배포 전략이다.

롤릴 업데이트는 롤백이 비교적 간단하며 recreate Deployment 보다 더 안전하다는 장점이 있다. 하지만 릴리즈 업데이트가 완료되기 전까지, 서로 다른 버전의 애플리케이션이 실행될 수 있으므로 여기에서 발생할 수 있는 문제점을 해결 할 수 있어야 한다. 업데이트 할 때, 각 애플리케이션이 성공적으로 배포됐는지를 확인하기 때문에 배포에 시간이 걸릴 수 있다.

**Blue/Green Deployment**

![Blue/Green Deployment](https://docs.google.com/drawings/d/e/2PACX-1vT8gGhlxZm-7HyWoCCrnYPaDRqWfJu2keul6S2yycP22m0EORW2YUztpvlObKz6ZXaklkE9EAhqUI2A/pub?w=902&h=324)

블루/그린 배포는 서로 다른 버전의 애플리케이션(혹은 서비스)를 블루(일명 스테이징)와 그린(일명 프로덕션) 두개의 환경을 활용하는 배포 전략이다. 기능 테스트, 품질관리 등의 활동은 블루 환경에서 수행된다. 새로운 변경이 수용되고 테스트가 끝나면, 트래픽을 블루로 라우팅한다.

블루/그린 배포는 간단하고 빠르며 이해하기가 쉽고 구현이 쉽다는 장점이 있다. 롤백도 간단하다. 문제가 발생하며 트래픽을 이전 환경으로 되돌리기만 하면 된다. 다른 배포 전략에 비해서 매우 안전하다.

블루/그린의 단점은 **비용**에 있다. 마이크로 서비스 환경에서 복제된 두 개의 환경을 구축하는데에는 많은 시간과 비용이 들어갈 수 있다. 품질관리, 승인테스트, 회귀테스트를 수행하긴 하지만 모든 사용자 트래픽을 한 번에 전환하면 위험이 발생 할 수 있다. 따라서 블루/그린 환경을 제대로 구성하기 위해서는 잦은 배포 전략을 유지할 필요가 있다.

**canary Deployment**

![Canary Deployment](https://docs.google.com/drawings/d/e/2PACX-1vT1Kl7bgyt6w0b5t9aAv5hqoWs8zLF3NjASw32QIfU82_7iYwMW1aUvHE4_PpotYeITGs47GGvoSF6C/pub?w=808&h=298)

Canary 배포는 서비스를 일부 사용자에게 점진적으로 릴리즈 하는 배포 전략이다. 대상 환경의 인프라는 작은 단계(25%, 50%, 75%, 100%)로 업데이트 한다. Canary 배포는 다른 배포 전략에 비해서 가장 안전하다.

Canary 배포를 통해 조직은 실제 사용자를 대상으로 현재 버전과 업데이트 버전의 작동 경험을 함께 비교 할 수 있다. 블루/그린 배포처럼 복제를 만들 필요가 없기 때문에 비용 역시 저렴하다. 롤백역시 빠르고 안전하다.

Cnary 배포는 프로덕션 환경에서의 테스트에 많은 기술적 노하우가 필요하다는 단점을 가진다. Canary 스크립트는 복잡 하며, 테스트에 많은 시간이 걸릴 수 있다. 테스트 전략, 모니터링 등에 추가 연구가 필요 할 수 있다.

**어떤 배포 전략을 사용해야 할까**
소프트웨어 배포 작업을 해본 사람은 쉽지 않은 과정이라는 것을 알고 있을 것이다. 소프트웨어 배포 작업은 기획자, 품질관리자, 개발자, PM 이 커뮤니케이션 할 수 있는 **업무시간에 실행**하도록 한다. 이를 위해서 필요한 것들은 아래와 같다.

-   서비스별 배포 체크 리스트
-   업데이트 혹은 hotfix된 기능 체크리스트
-   CICD 환경
-   잘 정의된 환경, 문서
-   자동화된 도구 구축
-   Slack 과 같은 커뮤니케이션 채널.
-   사고 대응, 구성정보 등을 담은 플레이북
-   자동화된 롤백

Search For:

BY TAGS

Recent Posts

Archive Posts

Tags

About

Get in Touch

Categories