[Kubernetes] 쿠버네티스의 기초: 팟, 레플리카셋, 디플로이먼트

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.
 

Kubernetes

---

이번 포스팅에서는 쿠버네티스의 기초인 팟(Pods), 레플리카셋(Replica set), 디플로이먼트(Deployment) 개념에 대해 배워보도록 하자. 쿠버네티스에 대해 본격적으로 다루어보기 전에 쿠버네티스의 몇 가지 특징에 대해서 살펴보고 넘어가자.

A. 쿠버네티스는 모든 리소스를 '오브젝트(Object)'로 다룬다

먼저, 쿠버네티스에서의 모든 리소스는 '오브젝트'라고 불리는 형태로 관리된다. 예를 들어, 이전에 배웠던 도커 스웜에서 제어 단위였던 '서비스'라는 것은 컨테이너들의 집합을 의미한다고 했다. 이것도 일종의 오브젝트라고 부른다. 그런데 쿠버네티스에서는 도커 스웜보다는 좀 더 다양한 개수의 오브젝트를 관리하며, 예시로는 컨테이너의 집합인 팟, 컨테이너의 집합을 관리하는 컨트롤러인 레플리카셋, 사용자(Service Account), 노드가 있다. 그 이외에 쿠버네티스가 관리하는 여러가지 오브젝트가 있으며 종류도 엄청 다양하다. 기타 추가적인 오브젝트에 뭐가 있는지 알아보려면 공식문서를 확인하거나 쿠버네티스가 설치되어 있는 호스트에서 "kubectl explain [오브젝트 이름]" 명령어를 입력하면 살펴볼 수 있다.

B. 쿠버네티스를 다룰 줄 아는 능력 = YAML 파일 작성할 줄 아는 능력!? 

다음은 쿠버네티스를 다룰 때는 kubectl 명령어보다는 YAML 파일을 더 많이 사용한다는 점이다. 그동안 배웠던 도커 관련 지식 중에서 도커 컴포즈를 배우기 이전까지는 주로 직접적으로 터미널에서 docker 접두어로 시작하는 명령어를 사용하면서 컨테이너를 제어해왔다. 그리고 도커 컴포즈에서 YAML 파일이라는 것을 이용해 여러 개의 컨테이너를 한 번에 관리하는 방법을 배웠었다. 쿠버네티스도 도커 컴포즈 처럼 생성할 컨테이너들을 주로 YAML 파일로 정의하고 생성한다. 도커 컴포즈 때도 그랬지만, 컨테이너에 대한 관련 리소스 뿐만 아니라 네트워크와 같은 기타 모든 리소스 오브젝트들에 대해서 설정을 할 수 있다. 심지어 쿠버네티스를 활용해 실제 서비스를 배포할 때도 YAML 파일을 이용해서 배포하게 된다.

C. 쿠버네티스는 컴포넌트들의 모음으로 실행된다.

마지막으로, 쿠버네티스는 여러 개의 컴포넌트들로 구성되어 있다는 점이다. 도커 스웜 때와 마찬가지로 쿠버네티스에서의 노드 역할은 크게 마스터와 워커 역할로 분리된다. 마스터 역할은 쿠버네티스가 잘 동작할 수 있게 클러스터를 관리하는 것이며 워커는 실질적인 애플리케이션 컨테이너를 생성하는 역할을 한다. 그리고 도커 스웜은 도커 엔진 자체에 내장되어 있기 때문에 설치된 도커 데몬만을 사용했지만, 쿠버네티스는 도커를 포함한 기타 다른 컴포넌트들이 함께 실행된다.

 

예를 들어, 마스터 노드에서는 API 서버(kube-apiserver), 컨트롤러 매니저(kube-controller-manager), 스케쥴러(kube-scheduler), DNS 서버(coreDNS) 등이 실행되고, 모든 노드에서는 오버레이 네트워크 구성을 위해 프록시(kube-proxy)와 네트워크 플러그인(calico, flannel 등)이라는 컴포넌트들이 실행된다. 물론 이러한 컴포넌트들도 기본적으로 '컨테이너'의 형태로 실행된다. 실제로 마스터 노드에서 지금 실행 중인 컨테이너를 출력해보면 아래와 같이 다양한 쿠버네티스 관련 컴포넌트들이 컨테이너 형태로 실행 중임을 알 수 있다.
 

 
저번 포스팅에서 우리는 쿠버네티스를 설치하기 위해서 여러가지 패키지를 다운로드 받았는데, 그 중에 kubelet에 대해서 다운받았다. kubelet은 클러스터의 컨테이너를 직접적으로 제어하는 역할을 함으로써 클러스터 구성을 위해 모든 노드에서 kubelet 이라는 에이전트가 실행이 된다. 컨테이너 생성과 삭제 뿐만 아니라 마스터와 워커 노드 간의 통신 역할까지 함께 담당하며 중요도가 매우 높은 컴포넌트이다. 그렇기 때문에 kubelet이 정상적으로 실행되지 않는 노드는 쿠버네티스와 연결이 제대로 되지 않을 수도 있다.

 

또한 컨테이너 런타임 인터페이스 즉, CRI도 쿠버네티스에서는 또 다른 하나의 컴포넌트이다. 왜냐하면 컨테이너를 제어하기 위해서 CRI를 사용하기 때문이다. 다른 예시로, 도커 스웜 같은 경우는 도커 엔진 자체에 내장되어 있기 때문에 컨테이너를 제어하기 위해서 별 다른 컴포넌트를 실행하는 것은 아니였다. 하지만 쿠버네티스는 CRI 구현체 중 하나를 사용해서 컨테이너를 제어하기 때문에 CRI 구현체의 컴포넌트를 별도로 실행하는 것이다. 실제로, kubelet이 컨테이너를 제어하기 위해서 사용하는 CRI 종류 중 하나로 containerd, cri-o 등 이 중 하나를 사용한다.
 
이제 그러면 쿠버네티스를 직접 다루어 보면서 기초 개념을 쌓아가 보자. 쿠버네티스에서 컨테이너 애플리케이션을 실행시키기 위해서는 반드시 알아야 할 몇 가지 오브젝트가 존재한다. 바로 팟, 레플리카셋, 서비스, 디플로이먼트가 그것들이다. 이제 이것들에 대해서 하나씩 배워보도록 하자.

1. 쿠버네티스에서 컨테이너를 다루는 기본 단위, 팟(Pod)

쿠버네티스에서 팟은 컨테이너 애플리케이션의 기본 단위를 의미한다. 그리고 팟은 1개 이상의 컨테이너로 구성된 컨테이너의 집합이다. 도커 관련 시리즈를 잠시 회상해보면, 도커 엔진에서는 기본 단위가 도커 컨테이너였고, 도커 스웜에서는 '서비스'였다. 이처럼 쿠버네티스에서도 기본 단위가 존재하는데, 이것이 바로 팟이다. 팟의 개념을 좀 더 와닿게 이해하기 위해 하나 예시를 들어보자.
 
만약 Nginx 웹 서비스를 쿠버네티스를 이용해 서비스하려고 한다고 해보자. 어떻게 해야할까? 방법은 단순하다. 바로 Nginx 서버 컨테이너 1개를 포함한 팟 1개를 생성하는 것이다. 만약 이와 동일한 팟 여러 개를 생성하고 싶다면 동일한 구성의 팟을 여러개 생성하면 된다.
 

1개의 팟 안에 1개의 컨테이너

 
그러면 이제 실습으로, Nginx 서버 역할을 하는 컨테이너 1개를 포함한 팟 1개를 생성하는 YAML 파일을 생성해보자. YAML 파일 내용은 다음과 같다. 참고로 실습을 수행하기 위해서 마스터 노드 1개, 워커 노드 3개를 활용해 클러스터를 구축했다.
 

apiVersion: v1
kind: Pod
metadata:
  name: zedd-nginx-pod
spec:
  containers:
  - name: zedd-nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
      protocol: TCP

 
위 YAML 파일을 팟으로 배포해보기 전에 작성된 YAML 파일 내용의 항목에 대해 각각 살펴보는 시간을 갖도록 하자. 
 

• apiVersion : YAML 파일에서 정의한 오브젝트의 API 버전을 의미. 오브젝트의 종류 및 개발 성숙도에 따라 해당 값이 달라질 수 있음
• kind : 리소스의 종류를 의미. 위 예시에서는 팟을 생성하려고 하는 것이기 때문에 값이 Pod이 된다. kind 항목에서 사용할 수 있는 리소스 오브젝트 종류가 여러가지가 있는데, kubectl api-resources 명령어를 치면 출력되는 화면 중 가장 오른쪽에 KIND 라는 항목을 보면 확인할 수 있다.
• metadata : 리소스에 붙히는 라벨,  주석, 이름과 같은 리소스의 부가 정보를 의미
• spec : 리소스를 생성하기 위한 자세한 정보를 의미. 위 예시에서는 팟을 컨테이너로 생성하기 위해 containers 라는 키워드를 작성했고, 하위 항목에 해당 컨테이너를 생성할 때 기반이 되는 이미지, 그리고 컨테이너가 사용할 포트 번호를 입력했다. 대부분의 키워드가 도커 컴포즈를 배웠을 때와 비슷하다.

이제 그러면 정의한 YAML 파일을 이용해서 팟을 쿠버네티스에 생성해보도록 하자. 명령어는 아래와 같다.
 

$ kubectl apply -f nginx-pod.yaml

 
그러면 팟이 만들어졌다는 메세지가 출력된다. 그리고 kubectl get pods 명령어를 입력해서 생성된 팟을 아래처럼 확인해보자. 참고로 kubectl get [오브젝트 이름] 명령어를 입력하면 해당 오브젝트의 목록을 확인할 수 있다. '오브젝트 이름'에는 팟이 될 수도 있고 노드, 또는 기타 오브젝트 이름이 들어갈 수 있다.
 

 
그러면 생성된 파드의 컨테이너 즉, Nginx 서버로 테스트 요청을 보내보도록 하자. 위 YAML 파일에서 비록 포트번호를 정의하긴 했지만, 현재 외부에서 접근할 수 있도록 노출된 상태는 아니다. 만약 쿠버네티스 클러스터 외부에서 파드에 접근하려면 서비스라고 하는 오브젝트를 별도로 생성해야 가능하다. 도커 컨테이너로 치면 docker run 명령어를 입력할 때 포트포워딩 옵션인 -p(--publish) 옵션을 지정해주 않은 채 실행한 것인 셈이다. 서비스 오프젝트에 대해서는 추후에 배우도록 하고 지금은 서비스 오브젝트 없이 컨테이너의 IP 만으로 해당 파드의 컨테이너에 접근해보도록 하자. 우선 우리는 생성한 파드의 컨테이너 IP 정보가 필요하다. 아래 명령어를 활용하면 특정 파드에 대한 자세한 정보를 얻을 수 있다.
 

$ kubectl describe pods zedd-nginx-pod

 
위 명령어로 출력된 내용 중 IP 라는 항목을 확인할 수 있다. 여기서 알게 된 IP는 123.456.789.000 이다. 그러면 워커노드 3개 중 아무 노드로 들어가 해당 IP 주소로 curl 명령어를 날려보도록 하자.
 

생성돤 파드에 curl 테스트 날리기

 
터미널 표준 출력에 보면 nginx 서버에서 보여지는 HTML Response가 반환된 것을 볼 수 있다. 그러면 생성한 파드를 삭제해보도록 하자. 마스터 노드에서 아래 명령어를 입력시켜주자.
 

$ kubectl delete -f nginx-pod.yaml

 
여기까지 보면 쿠버네티스의 팟이 도커의 컨테이너와 별 다른 차이가 없는 듯 하다. 그럼에도 불구하고 쿠버네티스의 팟을 더 자주 사용하는 이유는 뭘까? 팟을 사용하는 이유는 바로 여러 리눅스 네임스페이스를 공유하는 여러 컨테이너들을 추상화된 집합으로 사용하기 위함 때문이다. 대체 이게 무슨 이야기인지 모르겠다. 이 뜻을 이해하기 위해서 하나 추가적인 실습을 진행해보자. 방금 삭제한 Nginx 파드를 다시 생성해보고 팟 목록을 출력해보자.
 

 
READY 항목을 보면 1/1 이라고 쓰여져 있다. 이는 해당 파드에 컨테이너가 1개가 정의되어 있고, 그 중 1개의 컨테이너가 정상적으로 실행되고 있음을 의미한다. 그런데 여기서 1/1이 아닌 2/2, 3/3, 2/3은 불가능할까? 가능하다. 물론 대부분의 쿠버네티스 컨테이너 애플리케이션은 위처럼 1개의 컨테이너로 파드를 구성해 사용하긴 하지만 반드시 1개의 컨에티너로 구성되야 하는 것은 아니다. 즉, READY 항목은 파드 내의 컨테이너 개수에 따라 2/2가 될 수도, 3/3이 될 수도 있다. 따라서 우리는 위 Nginx 파드를 생성하기 위해 정의한 YAML 파일을 좀 더 확장해보려 한다. 사용할 YAML 파일 내용은 아래와 같다.
 

apiVersion: v1
kind: Pod
metadata:
  name: zedd-nginx-pod-v2
spec:
  containers:
  - name: zedd-nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
      protocol: TCP

  - name: zedd-ubuntu-container
    image: alicek106/rr-test:curl
    command: ["tail"]
    args: ["-f", "/dev/null"]

 
파일을 보면 저자분이 직접 만든 실습용 이미지를 기반으로 하는 우분투 컨테이너를 하나 더 생성하는 것을 볼 수 있다. 참고로 YAML 파일에 정의된 command는 도커에서 Dockerfile 명령어의 ENTERYPOINT와 동일하고, args는 CMD와 동일하다. 혹시 기억이 안난다면 여기를 참조하자. 그리고 리눅스의 tail 명령어는 일종의 실시간 로그를 모니터링 하는 용도로 사용할 수 있는데, YAML 파일에 정의된 것이 그것이다. 이에 대해서도 이전 리눅스 포스팅에서 배운적이 있으니 그곳을 참고하자. 그러면 이제 팟을 생성해보자.
 

 
위를 보면 zedd-nginx-pod-v2 라는 이름의 팟이 생겼고 READY 항목에 2/2가 있는 것을 볼 수 있다. 그리고 우리가 생성한 컨테이너 중 우분투 컨테이너로 아래 명령어를 통해 들어가보자. 참고로 -c 옵션을 주면 해당 팟 내의 특정 컨테이너로 들어갈 수 있다.
 

$ kubectl exec -it zedd-nginx-pod-v2 -c zedd-ubuntu-container bash

 
그러면 이제 우분투 내부로 들어온 것을 볼 수 있다. 이 때 curl localhost 명령어를 입력해보자. 그러면 신기한 일이 발생한다.
 

 
우분투 컨테이너에서 로컬 호스트로 curl 명령어를 날렸는데, Nginx 서버의 HTML Response가 반환되는 것을 볼 수 있다. 아니 이게 어떻게 가능한 걸까? 분명 위 YAML에서 정의한 우분투 컨테이너는 Nginx 서버 역할을 하는 컨테이너가 아니었는데 말이다. 사실 이 HTML Response를 보내준 서버는 이바로 우분투와 같은 팟에 띄워져 있는 컨테이너를 의미한다. 이런 것이 가능한 이유가 바로 파드 내의 컨테이너들이 네트워크 네임스페이스 등과 같은 리눅스 네임스페이스를 공유하기 때문이다.

 

참고로 이와 비슷하게, 도커에서도 이런 기능을 가능하게 할 수 있었다. 바로 브리지 네트워크를 직접 생성해서 --net 과 --net-alias 옵션을 사용해준 경우다. 이에 대한 자료는 이전 포스팅을 참고하자.
 
위 예시에서는 테스트를 위해 어떻게 보면 의미없는 우분투 컨테이너를 하나 추가했다. 그러면 실제로 이렇게 하나의 파드 내에 2개 이상의 컨테이너를 실행시키는 경우가 있을까? 바로 하나의 완전한 애플리케이션이 동작하기 위해서 필요한 컨테이너들이 2개 이상일 때이다. 처음 실습 때 우리는 Nginx 컨테이너 1개만을 하나의 파드로 정의했다. 그러면 이 때는 하나의 파드 내에 2개 이상의 Nginx 컨테이너를 정의하면 안되는가? 물론 되기는 한다. 하지만 바람직하지 않다. 왜냐하면 Nginx 서버는 단지 Nginx 컨테이너 1개만으로 완전한 어플리케이션으로 동작하기 때문이다. 
 
그러다가 만약 Nginx 서버에 부가적인 기능을 추가하기 위해서 별도의 컨테이너를 하나 붙였다고 가정해보자. 그러면 이 때는 Nginx 컨테이너와 별도의 컨테이너 2개가 동시에 실행되어야 완전한 어플리케이션이라고 할 수 있고, 이 때야말로 하나의 파드 내에 2개의 컨테이너를 실행시켜야 하는 적절한 경우가 되겠다. 참고로 이런 별도의 컨테이너를 부가적인 컨테이너라는 의미로, sidecar 컨테이너라고도 부른다. 그리고 같은 파드 내에 실행되고 있는 컨테이너들은 반드시 같은 워커 노드에서 함께 실행되고 있다는 것도 알아두자.

2. 여러 개의 파드를 관리해주는 컨트롤러, 레플리카셋(ReplicaSet)

레플리카셋이란, 동일한 여러 개의 파드 묶음을 의미한다. 잠시 여기서 컨테이너, 파드, 레플리카셋 이 3가지 개념에 대한 관계를 잠깐 정리하고 넘어가자. 아래 그림을 보자.
 

컨테이너, 팟, 레플리카셋 간의 관계

 
레플리카셋은 도커 스웜에서의 '서비스'와 유사한 개념이다. 그러면 쿠버네티스에서 레플리카셋이 필요한 이유는 뭘까? YAML 파일에 단순히 팟만 정의해서 생성하게 되면 팟의 생애주기(Lifecycle)를 사용자가 직접 관리해주어야 하기 때문이다. 만약 실제로 외부 사용자의 요청을 처리해야 하는 마이크로 서비스 구조에서 사용자가 직접 팟의 생애주기를 관리해주어야 한다면 매우 까다롭고 고된 작업일 것이다. 어떠한 이유에서 팟이 존재하는 특정 노드에 장애가 생겨서 다운되거나 할 때마다 사람이 직접 다시 생성해주어야 한다는 것이다. 이러한 문제를 해결하기 위해 등장한 것이 바로 쿠버네티스의 레플리카셋 이라는 오브젝트이다. 레플리카셋의 역할은 크게 2가지로, 정해진 수의 동일한 팟이 항상 실행되도록 관리하는 것, 그리고 노드 장애 상황 처럼 팟을 사용할 수 없는 상황일 때, 다른 노드에서 동일한 팟을 다시 생성하는 역할을 한다. 이것마저도 도커 스웜에서의 '서비스'와 비슷하다고 볼 수 있다.
 
이렇게 쿠버네티스에서는 레플리카셋을 정의함으로써 팟을 사람이 아닌 쿠버네티스가 알아서 관리할 수 있도록 한다. 그래서 실제로 사람이 직접적으로 팟을 관리할 일은 거의 없다. 그러면 이제 직접 레플라카셋 오브젝트를 YAML 파일을 통해서 생성시켜보도록 하자. 정의할 YAML 파일 내용은 아래와 같다.
 

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: zedd-nginx-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: zedd-nginx-pods-label
  template:
    metadata:
      name: zedd-nginx-pod
      labels:
        app: zedd-nginx-pods-label
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

 
YAML 파일의 항목 순서는 크게 다음과 같다. 가장 먼저 생성될 레플리카셋에 대해 1~5번째 줄까지 해서 정의를 해준다. 그리고 레플리카셋 내에서 생성될 파드에 대한 설정을 해주면 되는데, template 키워드를 기준으로 그 위는 파드를 몇 개 생성할 것인지를 명시해준다. 그리고 template 키워드 아래의 내용은 어떠한 파드를 어떻게 생성할 것인지에 대해 명시한다. 이를 파드 스펙 또는 파드 템플릿이라고도 부른다. 이제 그럼 위 YAML 파일 내용을 기반으로 레플리카셋을 생성해보자.
 

$ kubectl apply -f nginx-replicaset.yaml

 
그리고 아래의 첫 번째 명령어로 생성된 팟들을 살펴보고, 두 번째 명령어로 생성한 레플리카 셋 목록을 출력해보자.

(참고로 po는 팟을 rs는 레플리카 셋의 줄임 단어를 의미한다. 이런 오브젝트의 줄임말을 보고 싶다면 kubectl api-resources의 SHORTNAMES 항목을 보면 된다)
 

$ kubectl get po
$ kubectl get rs

 
이번에는 방금 생성한 레플리카셋에서 정의한 팟 개수를 4개로 늘려보자. 팟 개수를 늘리는 것과 같이 레플리카셋(오브젝트)의 리소스 속성을 변경하기 위해 기존에 생성한 레플리카셋을 굳이 삭제할 필요가 없다. 쿠버네티스에서는 이러한 변경 기능을 제공해주기 때문이다. kubectl edit 또는 kubectl patch 명령어를 사용하면 된다. 하지만 여기서는 위에서 정의한 YAML 파일에서 텍스트 에디터로 직접 replicas 항목을 3에서 4로 수정 후 아래 명령어를 다시 실행시켜주자.
 

$ kubectl apply -f nginx-replicaset.yaml

 

 
위 화면이 보여주는 것처럼 kubectl delete 명령어로 기존에 존재한 레플리카셋을 삭제해주지 않아도 리소스 변경 후 재생성이 가능하다. 단, 그럴 경우 위 화면에서 처럼 해당 레플리카셋이 변경되었다는 것을 의미하는 'configured' 키워드가 등장한 것을 볼 수 있다. 레플리카셋을 삭제할 경우 팟 때와 마찬가지로 kubectl delete 명령어를 사용하면 된다. 당연하게도 레플리카셋을 삭제하면 그 레플리카셋 내에 있는 파드도 같이 삭제된다.
 

$ kubectl delete -f nginx-replicaset.yaml
$ kubectl delete rs zedd-nginx-replicaset

 
다음은 레플리카셋의 동작 원리를 간단하게 알아보자. 원리를 알아보기 전에 우리는 레플리카셋의 존재 이유에 대해 알고 넘어가면 좋다. 레플리카셋의 존재 이유는 뭘까? 물론 동일한 팟 여러 개를 한 번에 생성하는 것도 있겠지만 그보다 더 중요한 것은 일정 개수의 팟를 유지하려고 하는 것이다.
 
위에서 우리는 레플리카셋을 생성하면서 그 안에 정의되어 있는 팟도 같이 생성되는 것을 볼 수 있었다. 이것을 보고 레플리카셋은 파드와 연결되어 있다라고 생각할 수 있다. 하지만 아니다. 물론 느슨한 연결(Loosely coupled)을 유지하고 있긴 하지만, 이는 YAML 파일에서 정의한 라벨 셀렉터(Label Selector)로 인해 연결된 것이다. 다시 말해, 레플리카셋과 팟 간의 연결은 YAML 파일을 작성한 사람이 만들어준 것! 이를 이해하기 위해 정의한 YAML 파일 중 아래 노란색 표시의 텍스트를 유심히 살펴보자.
 

노란색 부분을 살펴보자

 
라벨 셀렉터는 바로 위 내용 중 matchLabels 라는 항목을 의미한다. 해당 항목에는 key : value 쌍의 형태로 정의되어 있다. 이 라벨은 주로 쿠버네티스의 리소스를 분류할 때 자주 사용되며 리소스의 부가적인 정보를 표현하는 데 자주 사용된다. 그런데 이것 말고도 또 추가적인 기능을 하는데 바로 서로 다른 오브젝트(팟, 레플리카셋 등..)가 서로를 찾아야 할 때 사용된다는 것이다. 
 
따라서 레플리카셋은 위 YAML 파일의 matchLabels 항목을 참조해서 해당 라벨을 가지는 팟의 개수와 replicas 항목에 적혀있는 숫자와 일치하도록 맞춰주려고 노력한다. 즉, 만약 해당 라벨을 갖는 팟의 개수가 replicas 항목의 숫자보다 적다면 동일한 팟을 추가로 생성한다는 것이다. 이 때 생성하는 팟의 스펙은 teamplate 항목에 적혀있는 대로 생성한다. 물론 반대로 해당 라벨을 갖는 팟의 개수가 더 크다면 팟을 삭제시켜주기도 한다. 
 
그래서 위 YAML 파일을 실행시키면 레플리카셋이 최초로 생성되었을 때는 app: zedd-nginx-pods-label 이라는 라벨을 갖는 팟이 생성되어 있지 않은 상태일 것이다. 그렇기 때문에 즉시 replicas 항목에 있는 4개를 맞춰주기 위해서 template 항목에 있는 스펙대로 팟을 4개 생성하게 된다. 그런 다음 해당 라벨을 갖는 팟을 새롭게 생성하려고 해도 레플리카셋은 더이상 해당 라벨을 갖는 팟을 생성하지 않는다. 왜냐하면 이미 개수가 4개로 채워졌기 때문이다. 이를 실제로 살펴보기 위해 간단한 실습을 해보도록 하자.
 
이미 위 YAML 파일을 기준으로 레플리카셋을 하나 생성했다고 가정해보자. 그리고 우리는 아래와 같이 동일한 라벨을 갖는 팟을 수동으로 추가로 하나 생성해보자.
 

apiVersion: v1
kind: Pod
metadata:
  name: zed-nginx-pod
  labels:
    app: zedd-nginx-pods-label
spec:
  containers:
  - name: zedd-nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

 
그런 다음 kubectl get pods 명령어를 실행시키면 어떤일이 발생할까? 아래 화면을 보자.
 

 
노란색 네모칸을 보면 수동으로 추가한 팟이 생성되자마자 바로 종료되고 난 뒤 팟 목록에서 사라진 것을 볼 수 있다. 그럼 반대로 레플리카 셋을 생성하기 이전에 수동으로 동일한 팟을 생성해놓고, 레플리카셋을 생성하면 어떻게 될까? 아래 화면을 보자.
 

 
보면 미리 수동으로 생성해놓은 zed-nginx-pod이 남아 있고 레플리카셋 생성으로 인해 생성된 팟들(zedd-nginx-replicaset로 시작하는 팟들)이 4개가 아닌 3개만 생성된 것을 볼 수 있다. 즉, 라벨 셀렉터, 여기 예시에서는 'app: zedd-nginx-pods-label' 라는 라벨을 통해서 팟과 레플리카셋이 연결되는 것이다.
 
그러면 만약 특정 팟에서 해당 라벨을 삭제하게 되면 어떻게 될까? 리소스 속성을 변경하도록 하기 위해서는 kubectl edit 명령어를 사용할 수 있다. 아래 명령어를 사용해서 위 팟 중 zedd-nginx-replicaset-xj94j 라는 이름의 팟의 레이블을 수정해보자.
 

$ kubectl edit pods zedd-nginx-replicaset-xj94j

 
위 명령어를 수행하면 Vim 에디터 편집기로 이동하게 된다. 그리고 라벨에 있는 항목을 주석처리하거나 삭제한 뒤 편집기를 저장 후 종료해보자. 그리고 팟 목록을 출력해보자.
 

 
출력을 보면 끝에 b7rlg 라는 텍스트가 들어가는 팟이 새롭게 생성되었음을 알 수 있다. 그리고 방금 라벨을 삭제한 xj94j 라는 텍스트가 이름에 있는 팟은 여전히 실행중이다. 즉, 라벨이 삭제됨으로써 더이상 레플리카셋이 해당 팟을 관리하지 않는 것이다.

 

이렇게 해서 레플리카셋의 동작 원리를 간단히 알아보았다. 참고로 레플리카셋으로부터 생성된 팟에서 어떤 레플리카로부터 생성되었는지 확인하고 싶다면 팟의 ownerReferences 항목을 확인해보면 된다. 그리고 쿠버네티스는 이 ownerReferences를 통해서 리소스 간의 소유-종속 관계를 표현한다. 예를 들어, 팟은 ownerReference에 의해 레플리카셋에 종속되어 있기 때문에 레플리카셋은 팟의 owner라고 할 수 있다.

 

마지막으로 레플리카셋과 레플리케이션 컨트롤러간의 차이점에 대해 알아보자. 지금까지 배운 레플리카셋은 쿠네버티스 1.23.6 이전 버전에는 존재하지 않았고 그의 역할을 레플리케이션 컨트롤러가 대신 수행했었다. 하지만 버전이 업그레이드됨에 따라 레플리케이션 컨트롤러는 deprecated 되었고, 그 대신 레플리카셋이 사용되고 있다. 그럼 이 2개 간의 차이점은 뭘까? 차이점은 바로 라벨 셀렉터를 표현식 기반으로 사용할 수 있는지 여부이다. 레플리카셋은 가능하고, 레플리케이션 컨트롤러는 불가능하다. 표현식 기반의 라벨 셀렉터는 어떤 것일까? 예시 YAML 파일로 한 번 알아보자.

 

표현식 기반의 라벨 셀렉터 예시

 

노란색으로 칠한 부분을 보면 키워드가 matchExpressions로 바뀐 것을 볼 수 있다. 그리고 key, values 항목을 넣을 수 있는데, key에는 일반적인 라벨 셀렉터에서 정의했을 때의 키값이었던 app을 명시해준다. 그리고 values 항목에는 여러 값들을 나열할 수 있고, 연산(operator)을 정의할 수 있다. 위 예시에서는 In 연산을 정의했다. 이를 해석해보면, app이라는 key 값에 할당된 values가 zedd-nginx-pods-label 또는 test-nginx-pods-label 중에 하나라도 있다면 레플리카셋의 팟으로 인지하도록 하는 것이다. 사용할 수 있는 operator의 종류로는 In, NotIn, Exists, DoesNotExist, Gt, Lt 등이 있다. 

3. 여러 개의 레플리카셋을 관리하자, 디플로이먼트(Deployment)

이번 목차에서는 여러 개의 레플리카셋을 관리하는 디플로이먼트에 대해 알아보자. 디플로이먼트는 레플리카셋 보다 상위 개념의 오브젝트이며, 하는 역할은 크게 2가지이다. 레플리카셋의 리비전 관리 및 롤백 기능과 롤링 업데이트 관련 기능이다. 여기에서는 전자인 레플리카셋의 리비전 관리 및 롤백 기능에 대해 알아보도록 하자.

 

실제 쿠버네티스를 운영하는 환경에서는 YAML 파일에 팟 또는 레플리카셋만 정의해서 사용하지 않는다. 대부분의 경우, 레플리카셋과 팟의 정보를 함께 정의하는 디플로이먼트라는 오브젝트를 YAML 파일에 정의해서 사용한다. 당연하게도, 디플로이먼트를 생성하면 그와 관련된 레플리카셋, 팟도 함께 생성된다. 이를 알아보기 위해 디플로이먼트를 정의한 YAML 파일 예시를 살펴보자. 

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: zedd-nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: zedd-nginx
  template:
    metadata:
      name: zedd-nginx-pod
      labels:
        app: zedd-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.10
        ports:
        - containerPort: 80

 

위 YAML 파일을 배포해보고, 생성한 디플로이먼트를 출력하는 명령어를 입력해보자.

 

$ kubectl apply -f nginx-deployment.yaml
$ kubectl get deploy

 

 

위와 같이 디플로이먼트가 생성되었다. READY 항목은 생성된 팟의 개수이고, 현재 3개 모두 이용가능한 상태(AVAILABLE)이다. 함께 생성된 팟과 레플리카셋도 같이 한번 살펴보자.

 

 

YAML에서 정의한 대로 1개의 레플리카셋과 3개의 팟이 잘 생성된 것을 볼 수 있다. 위 화면에서 잠깐 주목할 키워드가 있다 바로 레플리카셋과 팟의 이름 항목에 있는 "9d878d95c" 라는 키워드이다. 이는 팟을 생성하는 템플릿으로부터 생성된 즉, YAML 파일 내의 template 키워드 부분으로 인해 생긴 값이다. 주목하는 이유는 잠시 후 등장하므로 머릿속에 기억해두자.

 

지금까지 디플로이먼트를 생성해보면서 레플리카셋을 생성할 때와는 다른 차별점이나 편한 점이 느껴졌는가? 솔직히 아니다. 단지 그냥 YAML 파일에 작성된 내용만 달랐을 뿐, 아직까지는 굳이 디플로이먼트를 사용하는 이유에 대해서는 잘 모르겠다. 이제 디플로이먼트만의 특징에 대해 알아보자.

 

디플로이먼트를 굳이 사용하는 이유는 애플리케이션의 업데이트와 배포를 더욱 편하게 만들기 위함이다. 즉, 컨테이너 애플리케이션을 배포하고 관리하는 역할을 하는데, 여기서 '관리하다' 라는 것은 애플리케이션의 기능을 업데이트 할 때 레플리카셋의 변경 사항을 저장하는 리비전(Revision)을 남겨서 롤백을 가능하게 해준다는 것이다. 또한 무중단 서비스를 위하 팟의 롤링 업데이트 전략을 지정할 수 있는 기능을 제공해준다.

 

이러한 기능을 실습을 통해 살펴보자. 살펴보기 위해서 잠시 위에서 생성한 디플로이먼트를 삭제하되 동일한 YAML 파일을 내용으로 디플로이먼트를 다시 생성해보자. 단, 생성 시 --record 옵션을 넣어주는 것만 다르다.

 

$ kubectl delete -f nginx-deployment.yaml
$ kubectl apply -f nginx-deployment.yaml --record

 

디플로이먼트가 다시 생성되었다면 생성 시 설정한 팟의 이미지 버전을 변경해보자. 위에서 몇 번 언급했지만 리소스를 변경하기 위한 방법으로는 여러가지가 있다. kubectl set image 명령어를 쓰거나 직접 YAML 파일을 변경 후, kubect apply -f 명령어를 쓰는 법, 아니면 kubectl edit 명령어를 사용해도 된다. 여기에서는 처음 사용해보는 kubectl set image 명령어를 사용해보자.

 

$ kubectl set image deployment zedd-nginx-deployment nginx=nginx:1.11 --record

 

위 명령어에서 nginx=nginx:1.11 에서 앞 부분의 'nginx' 라는 단어는 우리가 위에서 정의한 YAML 파일에서 spec.template.spec.containers.name에 있는 항목을 의미한다. 명령어를 입력하면 디플로이먼트 이미지가 변경(updated)되었다는 출력이 뜰 것이다. 그리고 다시 레플리카셋과 팟의 목록을 출력해보자.

 

 

위 화면의 아랫부분인 팟의 목록부터 살펴보자. 아까 주목하라고 했던 해쉬값 키워드였던 "9d878d95c" 에서 "5fdb947f4b"로 바뀐 것을 볼 수가 있다. 그리고 레플리카셋 목록을 살펴보면 "5fdb947f4b" 키워드가 이름에 들어가 있는 디플로이먼트가 새롭게 생겨났다. 여기서 주목할 부분은 그 이전의 버전이라고 할 수 있는 "9d878d95c" 키워드가 들어가있는 레플리카셋이 삭제되지 않고 여전히 존재하는 것을 볼 수 있다. 단, 존재하긴 하지만 그 레플리카셋에서 실행 중인 파드는 존재하지 않고 있음을 알 수 있다.

 

다시 말해, 디플로이먼트는 팟의 정보를 업데이트 함으로써 신규 버전의 레플리카셋을 생성하되 이전 버전의 레플리카셋은 삭제하지 않고 그대로 남겨두고 있다. 즉, 이전 정보를 리비전으로서 보존하고 있다는 것이다. 리비전 정보 세부사항에 대해서 보고 싶다면 아래 명령어를 수행해주면 된다.

 

$ kubectl rollout hisotry deployment zedd-nginx-deployment

 

 

그러면 위 화면처럼 REVISION 번호와 해당 리비전을 만들 때 사용한 kubectl 명령어가 무엇인지를 의미하는 CHANGE-CAUSE 항목도 알 수 있다. 단, CHANGE-CAUSE 항목은 위에서 최초 버전의 디플로이먼트를 생성할 때와 새로운 버전의 디플로이먼트를 생성할 때 --record 옵션을 주지 않으면 <NONE> 값이 들어간다는 점도 잊지말자.

 

현재 디플로이먼트의 버전은 REVISION 값이 2인 상태이다. 그러면 버전 1로 돌아가는 롤백 기능을 수행해보자. kubectl rollout undo 명령어와 --to-revision 옵션에 돌아갈 리비전 버전을 명시해준다. 당연히 여기서 리비전 버전은 위 화면에서 확인할 수 있는 REVISION에 대응되는 숫자이다.

 

$ kubectl rollout undo deployment zedd-nginx-deployment --to-revision=1
$ kubectl get rs,pod

 

버전 1로 롤백 후, 현재 상태의 레플리카셋과 팟의 목록을 다시 한번 출력해보았다.

 

 

현재 레플리카셋, 팟 이름에 최초 버전이었던 레플리카셋 이름에 붙어있던 키워드인 "9d878d95c"가 다시 붙어있는 것을 볼 수 있다. 만약 현재 설정된 레플리카셋, 팟의 버전의 정보가 구체적으로 궁금하다면, 그 디플로이먼트의 정보를 출력해보면 알 수 있다. 당연히 디플로이먼트도 kubectl describe 명령어가 적용이 된다. 디플로이먼트의 정보 중에 Annotations 항목과 NewreplicaSet 항목을 보면 알 수 있다.

 

$ kubect describe deployment zedd-nginx-deployment

 

이렇게 해서 우리는 디플로이먼트가 무엇인지, 그리고 디플로이먼트의 기능에 대해서 실습과 함께 알아보았다. 이제야 좀 실무에서 디플로이먼트를 왜 자주 사용하는지에 대해 알게 되는 것 같다. 

---

이렇게 해서 쿠버네티스를 다루는 데 있어서 필수적으로 익혀야 할 개념들인 팟, 레플리카셋, 그리고 디플로이먼트에 대해 알아보았다. 다음 포스팅에서는 쿠버네티스 클러스터에서 배포한 팟에 외부에서도 접근할 수 있도록 하는 서비스 개념에 대해서 알아보도록 하자. 아래는 본 포스팅을 작성하면서 정리한 kubectl 명령어 표이다. 앞으로 쿠버네티스를 학습하거나 이용하면서 cheat sheet 처럼 하나씩 추가될 수 있다.

---

명령어	의미	특징
kubectl get [OBJECT]	특정 오브젝트의 목록을 출력
kubectl describe [OBJECT] [OBJECT NAME]	특정 오브젝트의 특정 이름을 갖고 있는 리소스의 자세한 정보를 얻을 수 있음
kubectl exec -it [POD NAME] -c [CONTAINER NAME] [COMMAND]	특정 파드의 특정 컨테이너로 명령어를 실행할 수 있음	docker exec 과 유사
kubectl logs [POD NAME]	특정 파드의 로그를 확인
kubectl delete -f [YAML FILENAME]	특정 오브젝트를 삭제	YAML 파일을 지정해서 그 YAML 파일이 생성한 오브젝트를 삭제
kubectl delete pod [POD NAME]	특정 팟을 삭제