k8s-06_워크로드 API(Pod, Replicaset, Deployment)

시작하면서 두 번째 세션에서 쿠버네티스의 API는 아래와 같이 구성되어있다고 공유했다.

이제 그 시작인 워크로드 API에 대해서 알아볼 것이며, 해당 영역은 실무와 굉장히 밀접하고 필수적이다.

시작하기전 아래 사항을 다시 한번 rewind 하고 minikube start를 통해 테스트 환경을 준비하자.

2021.12.25 - [Devops 2회차/K8S Study] - K8S-02_쿠버네티스 기초와 kubectl

참조

쿠버네티스 완벽 가이드 (마사야 아오야마)

실무를 통한 경험

Workload API

Workload API는 클러스터에 컨테이너를 기동시키기 위해 사용되는 리소스이다. 
내부에서 사용되는 리소스도 있지만 사용자가 직접 사용하는 리소스는 아래와 같다.

• Pod
• Replication Controller
• Replicaset
• Deployment
• Demonset
• Statefullset
• Job
• CronJob

하지만 위 리소스들이 모두 수평적인 관계는 아니다.
위 모든 리소스들을 생성하면 파드는 기본적으로 따라오며, 디플로이먼트는 Replicaset을 만들고, Replicaset은 파드를 생성 및 관리하는 역할을 한다. 좀 보기 좋게 그려보면 아래와 같다.

Workload API

이제 workload api 하나하나씩을 만들어보면서 그 구조를 이해하면 쿠버네티스에서 '무언가' 할 수 있는 상태가 된다.

 

Pod

위의 그림처럼 Pod는 리소스의 최소 단위이다. (실제 서비스에서는 Pod 내부에 컨테이너가 뜨기에, 컨테이너가 더 작을 수 있겠다.)

파드는 한 개 이상의 컨테이너로 구성되어 있으며,
하나의 파드 내부에서 생성된 컨테이너는 네트워크 적으로 IP 주소를 공유한다.
즉, 파드 내부의 컨테이너는 서로 localhost로 통신할 수 있다.
보통 우리가 서비스로 띄울 Image가 한 개라면 단순히 하나의 컨테이너가 필요할 것 같지만,
쿠버네티스에서 다양한 모니터링이나 기능들을 접목시키면 Image가 하나라도 여러개의 컨테이너가 뜰 수 있다. 컨테이너가 다른 목적으로 사용되기 위해 추가적으로 붙는 것을 디자인 패턴 이라고 한다.
디자인패턴에는 사이드카, 앰버서더, 어댑터 패턴 이렇게 세 가지가 있으나 현재 이론을 다루는 여기서는 구체적으로 설명하지는 않겠다.

Pod는 지난 글에서 생성을 다뤄보았기 때문에 manifests 예시만 남겨두고 넘어간다.

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.16
  - name: redis-container
    image: redis:3.2

Replicaset/ Replica Controller

 

Replica를 쉽게 정의하면, 파드를 관리하기 위해 생성되는 리소스 이며,
파드 수를 유지해주는 리소스 라고 여기면 된다.
Replica Controller는 초기의 파드 레플리카를 생성하는 리소스명이였으나
현재는 Replicaset으로 이름이 변경되며 기능이 추가적으로 붙었다고 한다.
즉, 현재는 Replicaset가 더 널리 사용되고 우리도 Replicaset을 사용한다고 보면 된다.

 

아래는 Replicaset의 예제이다. 위 내용을 복사해서 sample-rs.yaml 파일을 만들고 적용시켜보자
적용은 지난 페이지에서 다뤘다. 혹시 기억 안난다면 kubectl apply -f sample-rs.yaml 로 띄워보자

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # 케이스에 따라 레플리카를 수정한다.
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

일단 성공적으로 repliacset(rs)가 떴고, 위와 같이 확인이 가능하다.
내부 manifests를 보면 selector, template, spec 막 이런 구분들이 있는데 여기서는 replicaset의 역할과 띄워보는 것만 다룬다.
궁금하다면 직접 찾아보시되, 너무 조급해 하지 말 것.

 

가장 중요한 것은 우리는 replicas 개수를 3으로 조정하였고, 실제로 파드가 3개 떴는지를 확인해보자.

아주 잘 떴음을 확인할 수 있다.

Replicaset의 가장 중요한 기능은 여기서부터인데,
Replicaset은 계속해서 사용자가 지정한 Replicas 수를 맞춰준다. 
사용자가, 혹은 장애에 의하여 파드 하나가 다운된 경우 Replicaset에 의해 자동으로 Pod가 다시 뜨게 되는 것이다.
이 내용이 Replicaset의 목적이며 쓰임이기 때문에 가장 중요하다.

Deployment

여태까지 pod를 만들고 pod를 관리하는 replicaset을 만들었다면
이번에는 여러 replicaset을 관리하여 롤링 업데이트나 롤백이 가능하게 만드는 디플로이먼트에 대해 알아보자.
이제 Deployment까지 알게 되면 기본적인 서비스의 Rolling 배포까지 가능해진다.

혹여나 헷갈리까봐 다시 한번 언급하자면,
Pod는 최소 단위이고, Replicaset을 생성하면 Pod는 자동으로 생성된다.
Deployment를 생성하면 Replicaset과 Pod를 자동 생성하는 리소스 이다.
그러니 각각 별개로 생성할 필요 없음을 인지하자.

아래는 Deployment.yaml 예제이다. (쿠버네티스 공식 매뉴얼)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  # replica 수도 조정할 수 있고
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    # 컨테이너 설정도도 직접 명시할 수 있다    
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

위 예제를 통하여 sample-deploy.yaml 을 생성하여 적용하였다.

그리고 replicaset과 pod가 모두 잘 맞춰 생성 된 것을 확인할 수 있었다.

결국 deployment는 실무를 하게 되면 가장 중요시 다루고 가장 많은 설정을 할 수 있는 리소스이다.
이 deployment 라는 리소스와 친해져야 한다.

Deployoment에서는 대표적으로 아래와 같은 기능들을 잘 활용하여 서비스 운영에 최적화 될 수 있도록 한다.

• 배포 방식(recreate, rolling)
• 헬스체크(liveness, readiness)
• 최소 대기 시간 : 파드가 Ready 상태가 된 다음부터 디플로이먼트 리소스에서 파드 기동이 완료되었다고 판단하기까지의 시간
• 수정 버전 기록 제한 : 롤백이 가능한 이력 수