Kubernetes Resource Summary (1)

1) Pod

- 쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 배포 단위

- 한 개 이상의 컨테이너 그룹으로, 공유 스토리지와 네트워크 자원을 포함하여 가지고 있다.

- Recreation : Pod에 문제가 발생할 경우, 쿠버네티스 컨트롤러에 의해 재성성되는 특징(Controller의 Auto Healing)
- Stateless : Pod의 이름, IP 등의 상태가 일정하지 않고 재생성시 변하게 되는 특징

 

2) Replicaset

- 정의된 Pod 개수에 대한 가용성을 보증하는 리소스

- Replicaset에 의해 생성된 Pod의 집합이 항상 안정적으로 실행되도록 유지하는 리소스

 

다음은 Replicaset 예시 yaml 이다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: nginx
    tier: frontend
spec:
  replicas: 4
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx

Yaml 파일에 정의된 내용을 살펴보면 레플리카 개수는 4로 지정되어 있으며, spec.selector.matchLables 에 지정된 tier: frontend 라벨을 가지고 있는 파드의 레플리카 개수를 4개로 보장하게 된다.

따라서 반드시 spec.template.metadata.labels에 tier: frontend 라벨을 동일하게 설정을 해주어야 replicaset 리소스 생성이 가능하다.

 

3) Deployment

- 파드와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공

- Deployment 가 하위 리소스인 Replicaset을 관리하고 Replicaset이 하위 리소스인 Pod를 관리하는 방식

- 관리자는 Replicaset을 직접적으로 관리하면 안되고, Deployment를 통해 Replicaset을 관리해야한다.

- Deployment를 통해 파드에 동작중인 어플리케이션의 버전 업데이트 가능

 

다음은 Deployment 의 예시 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

Yaml 파일에 정의된 내용을 살펴보면 레플리카 개수는 3으로 지정되어 있으며, spec.selector.matchLables 에 지정된 app:nginx 라벨을 가지고 있는 파드의 레플리카 개수를 3개로 보장하게 된다.

따라서 반드시 spec.template.metadata.labels에 app:nginx 라벨을 동일하게 설정을 해주어야 Deployment 리소스 생성이 가능하다.

Deployment를 생성하게 되면 자동으로 Replicaset 이 생성되며, 해당 Replicaset은 Deployment를 통해 관리된다.

 

4) Deployment Version Update 방식

1. Rolling update

- Deployment 에서 기본적으로 제공되는 업데이트 방식

- V1을 V2로 업데이트 할 때, V2를 하나 생성한 뒤 V1을 삭제하는 방식으로 Pod를 하나씩 점진적으로 교체해나가는 방법

- 무중단 업데이트 가능

- V1과 V2의 Pod이 공존하는 순간이 있다

 

ex) V1 파드가 2개 동작중이고, V2로 버전 업데이트 할 경우
1. V2 파드가 1개 생성되고 정상 상태가 확인되면 V1인 1개 파드가 특정 시간(기본값 30초) 동안 트래픽을 처리한 후 제거된다.
2. V2 파드가 1개 더 생성되고 정상 상태가 확인되면 V1인 1개의 파드가 특정 시간동안 트래픽을 처리한 후 제거된다.

 

2. Recreate

- 기존 파드를 모두 제거한 뒤 새로운 버전의 파드를 생성하는 방식

- 서비스 중단 시간 발생

 

ex) V1 파드가 2개 동작중이고, V2로 버전 업데이트 할 경우
1. V1 파드를 모두 제거
2. V2 파드 2개 생성

 

3. Blue/Green

- 기존 버전의 파드를 유지한 채 새로운 버전의 파드를 선언한 개수 만큼 생성한뒤 Service의 트래픽 전달 대상을 새로운 버전의 파드로 교체 후 기존 버전의 파드를 제거하는 방식

- 기존 Rolling update에 존재하는 단점인 V1, V2 버전의 파드가 공존하는 순간이 있다는 문제를 해결

- 배포시 자원을 2배로 소모하게 된다.

 

ex) V1 파드가 2개 동작중이고, V2로 버전 업데이트 할 경우
1. V2 파드를 2개 생성하고 Service 의 트래픽 전달 대상을 V2로 교체
2. 기존 버전의 V1 파드 모두 제거

 

4. Canary

- 테스트용도로 사용

- 구버전과 신버전 파드를 모두 생성한 뒤 트래픽 양을 조절하여 테스트를 진행한 후 교체하는 방식