<이해하기 쉽게 그림으로 표현해본 쿠버네티스 구조>

시작하기 앞서 계속해서 나오는 용어 간단 설명

• 메타데이터(meta data) : 속성정보를 의미하고 그냥 정보라는 단어로 치환해도 어느 정도 해석이 가능하다. 정보를 효율적으로 찾기위한 정보라고 생각하면 될 듯 하다.
• 매니페스트(manifest) : 메타데이터를 포함한 파일(아래에서는 yaml파일을 의미한다고 보면될 듯)

1.클러스터(Cluster)

컨테이너 형태의 어플리케이션을 호스팅하는 물리/가상 환경의 노드들로 이루어진 집합(영역)을 의미한다.

2.워크로드(Workload)

클러스터 상의 컨테이너를 구동 및 관리하는 데 사용되는 객체들을 의미한다.

< 워크로드 종류 >

• 파드(Pod)
• 레플리카셋(ReplicaSet) / 레플리케이션 컨트롤러(ReplicationController)
• 디플로이먼트(Deployment)
• 데몬셋(DaemonSet)
• 스테이트풀셋(StatefulSet)
• 잡(Job)

2.1) 파드(Pod)

워크로드 리소스의 최소 단위 리소스다. 하나 이상의 컨테이너로 구성되어 있는 영역을 의미한다.

< 특징 >

1. 하나의 파드 내부에 존재하는 컨테이너들은 네트워크적으로 격리되어 있지 않고 같은 IP 주소를 가진다. 파드끼리는 서로 다른 IP 주소를 가지므로 서로 다른 파드 내부에 존재하는 컨테이너들은 서로 다른 IP 주소를 가진다.
2. 여러 파드 디자인 패턴이 존재한다. 사이드카 패턴(메인 컨테이너 이외에 보조 기능을 추가한 서브 컨테이너를 포함하는 파드 패턴), 엠버서더 패턴(메인 컨테이너의 외부 시스템 접속을 대리로 중계하는 서브 컨테이너를 포함하는 파드 패턴), 어댑터 패턴(메인 컨테이너의 데이터 형식을 변환해주는 서브 컨테이너를 포함하는 파드 패턴)

2.2) 레플리카셋(ReplicaSet) / 레플리케이션 컨트롤러(ReplicationController)

본래 이름은 레플리케이션 컨트롤러였지만 현재 몇 가지 기능이 추가되면서 레플리카셋이라는 이름으로 변경되었다. 레플리카셋은 파드나 노드에 문제가 생겼을 때를 대비해서 파드를 정해진 수만큼 복제하고 관리하는 리소스다.

레플리카셋의 동작 방식을 예시를 통해 알아본다. 만약 레플리카셋으로 3개의 파드를 실행하고 싶다고 하면 3개의 파드를 생성하고 이를 각각 다른 노드에서 실행시킨다. 이때 쿠버네티스는 이 파드들을 감시한다. 만약 한 파드가 갑자기 에러로 멈추게 된다면 쿠바네티스는 이를 감지하고 다른 노드에 파드 하나를 새롭게 실행시켜 3개의 파드가 유지되도록 한다.

레플리카셋이 감시할 파드를 정하는 방법은 레플리카셋 yaml파일에서 spec.selector를 이용하는 것이다. 일반적으로 레이블(label)을 spec.selector의 요소로 사용하는데 예시를 통해 알아본다.

# 레플리카셋 yaml 파일 예시(sample.yaml)
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: sample-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
    template:
      metadata:
        labels:
          app: sample-app
      spec:
        containers:
        - name: nginx-container
          image: nginx: 1.16

• spec.selector 부분 내용

    matchLabels:
      app: sample-app

즉, lable이 app: sample-app와 일치하는지 체크하여 해당 파드가 감시할 파드인지를 구분하겠다는 뜻이다. 이때 밑에서 spec.template.metadata.labels에서 레플리카셋으로 생성할 파드의 레이블을 설정함을 볼 수 있는데 해당 내용은 다음과 같다.

• spec.template.metadata.labels 부분 내용

      app: sample-app

이를 통해 위 레플리카셋 yaml 파일로 생겨난 파드들은 app: sample-app라는 레이블 속성값을 가지고 있고 레플리카셋은 레이블로 app: sample-app값을 가지고 있는 파드들을 감시한다고 했으므로 위 레플리카셋 yaml으로 생겨난 3개의 파드들을 감시하게 된다. 만약 이때 해당 레플리카셋 yaml파일로 파드들을 만들기 전에 미리 만들어 놓은 파드가 존재하고 해당 파드의 레이블값이 app: sample-app를 만족한다면 해당 파드도 감시 대상에 포함된다. 그리고 이 경우는 미리 만들어져있던 파드 1개 + 레플리카셋으로 만들어진 파드 3개 = 총 4개의 파드가 생성되므로 레플리카셋의 spec.relicas값이 3인 관계로 이 4개의 파드 중 랜덤으로 하나가 정지되게 된다.

레플리카셋을 수정하는 방법으로는 해당 매니페스트(yaml파일) 자체를 수정하고 다시 실행하는 방식과, kubectl scale 명령어를 통해 스케일 처리하는 방식이 있다. 전자는 말 그대로 yaml파일을 원하는대로 수정하면 되는 것이라 설명은 생략한다. 후자도 비슷한데 명령어 예시를 통해 알아본다.

$ kubectl scale replicaset sample-rs --replicas 5

위 명령어는 레플리카셋을 5개로 유지하도록 설정은 스케일링(수정)한 것이다.

2.3) 디플로이먼트(Deployment)

디플로이먼트는 여러 레플리카셋을 관리하는 리소스다. 즉, 디플로이먼트는 레플리카셋을 관리하고, 레플리카셋은 파드를 관리하게 되는 구조다.

디플로이먼트의 매니페스트 파일을 확인해보면 레플리카셋의 매니페스트와 동일하다는 것을 알 수 있다. 그렇다면 왜 굳이 디플로이먼트를 사용할까? 디플로이먼트의 이점은 원래 있던 파드를 삭제하고 새로운 파드를 생성할 때 드러난다. 레플리카셋은 그저 파드의 수만을 유지하는 역할을 했다. 그래서 해당 레플리카셋이 관리하는 파드들의 설정을 바꾸고 싶어도 할 수가 없었다. 만약 레플리카셋의 매니페스트 파일에서 파드에 대한 설정을 바꾼다면 이는 해당 레플리카셋이 관리할 파드를 바꾸는 것이지 해당 레플리카셋으로 먼저 만들어져 관리받던 파드들이 변경되는 것은 아니기 때문이다.

그래서 디플로이먼트를 활용해 이미 만들어진 파드들을 삭제하고 새롭게 만들고 싶다면 디플로이먼트 매니페스트 내용을 바꾸고 적용하면 된다. 이때 이미 만들어진 파드를 삭제한다면 디플로이먼트로 만들어졌던 레플리카셋의 설정을 통해 파드를 하나 더 생성해 개수를 보충하려 해 파드 삭제가 이루어지지 않을텐데 어떻게 파드를 삭제할까? 여기서 사용되는 여러 방식이 존재한다.

< 업데이트 방식 종류 >

• 롤링 업데이트(주로 많이 쓰임)
  : 간단하게 설명하자면 기존 버전을 새로운 버전으로 교체할 때, 기존 버전을 하나 없에고 새로운 버전을 하나 추가하는 과정을 기존 버전이 다 사라질 때까지 반복하는 방식을 의미한다. 이런 방식은 기존 버전과 새로운 버전이 공존하는 시간이 존재하게 되는 단점이 있지만, 이는 오히려 서버를 중단하지 않고 무중단으로 업데이트를 할 수 있다는 장점으로도 생각할 수 있다.
  디플로이먼트가 롤링 업데이트를 진행하는 방식은 다음과 같다. 기존 레플리카셋의 레플리카 수가 3이었다면 레플리카 수가 1인 새로운 레플리카셋을 생성한다. 그러면 레플리카 수 1에 맞춰 새로운 파드가 1개 생성될 것이고 이때 기존 레플리카셋의 레플리카 수를 3에서 2로 낮춰 기존 파드 3개에서 1개가 삭제되어 2개가 될 것이다. 그럼 새로운 레플리카셋의 레플리카 수를 1에서 2로 늘린다. 그러면 레플리카 수 2에 맞춰 새로운 파드가 1개 추가 생성되어 새로운 파드는 총 2개 있을 것이고 이때 기존 레플리카셋의 레플리카 수를 2에서 1로 낮춰 기존 파드 2개에서 1개가 삭제되어 1개가 될 것이다. 한번 더 이 과정을 거치면 기존 레플리카셋의 레플리카 수가 0이 되어 기존 파드들은 모두 삭제되고 새로운 레플리카셋의 레플리카 수는 3이 되어 새로운 파드들은 3개가 될 것이다.

• Recreate
  : 위 방식과 다르게 한 번에 삭제를 하고 한 번에 생성을 하는 방식으로 잠깐 중단이 일어난다는 단점이 있다. 하지만 추가 리소를 사용하지 않고 전환 속도도 꽤 빠르다는 것이 장점이다.
  즉, 기존 레플리카셋의 레플리카 수를 0으로 줄여 기존 파드들을 모두 삭제하고나서 레플리카 수를 원하는 수로 지정한 레플리카셋을 생성해 새로운 파드들을 생성하는 방식이다.

디플로이먼트 수정 방식으로는 위에서 레플리카셋을 수정하는 방식과 동일하다. 디플로이먼트 매니페스트 파일을 수정한 뒤 kubectl apply -f 명령어를 사용하던가, kubectl scale 명령어에서 --replicas같은 옵션을 통해 기존 디플로이먼트 매니페스트 파일을 수정한다.

2.4) 데몬셋(DaemonSet)

데몬셋은 레플리카셋의 특수한 형태 리소스다. 레플리카셋은 파드를 생성할 때 노드의 리소스 상황에 맞게 노드를 선정해 파드를 생성한다. 그래서 어떤 노드에 몇 개의 파드가 생성될지는 랜덤이다. 데몬셋은 이런 랜덤성을 해결한 레플리카셋으로 기본적으로 모든 노드에 1개 씩 파드가 생성되도록 하는 레플리카셋이다. 업데이트 방식에는 롤링 업데이트, OnDelete방식이 있다.

< 데몬셋 업데이트 방식 >

• 롤링 업데이트
  : ?
• OnDelete
  : 처음에 데몬셋 매니페스트 파일 안에 spec.updateStrategy값에 type: OnDelete라는 설정을 해놓으면 파드가 정지되지 않는한 데몬셋의 업데이트가 이루어지지 않게 하는 방식이다. 이는 운영상의 이유로 정지되면 안되는 경우 유용하게 쓰일 수 있지만 파드가 정지되지 않는한 구 버전의 데몬셋이 계속해서 유지될 수 있다는 문제점도 있다.

2.5) 스테이트풀셋(StatefulSet)

스테이트풀셋도 데몬셋과 비슷하게 레플리카셋의 특수한 형태 리소스다. 데이터베이스와 같은 스테이트풀한 워크로드에 사용하기 위한 리소스다. 간단하게 말하면 외부에 저장공간을 만들고 이를 파드에 마운트해서 사용할 수 있게 하는 것이다. 파드는 삭제되면 안에 있던 정보도 모두 날아간다는 특성때문에 데이터를 저장하는 용도로 사용할 수 없기 때문에 이런 방식을 이용한다.

< 스테이트풀세 업데이트 방식 >

• 롤링 업데이트
  : ?
• OnDelete
  : ?

2.6) 잡(Job)

잡은 컨테이너를 활용해 한 번만 실행되는 리소스다.