[Kubernetes] Worker Node의 리소스 설정 종류에 대해 알아보자! (Deployment / ReplicaSets / Service)

Intro

이전 포스팅에서도 나와있듯이 pods는 kubernetes가 관리하는 가장 작은 단위이자 실질적으로 해당 pods 안에 Image Bundle의 압축을 해제하여 Container로 돌려 사용하기에 매우 중요하다

또한, 이전의 Master Node/Worker Node의 SSL 인증 등은 사실 설치하는 과정을 따라가기만 한다면 쉽게 설치가 가능하지만 실제 구동되는 곳은 직접 YAML로 만들어서 구성해야하기에 이해가 필요하다!

우리는 이러한 YAML을 작성하기 전 어떤 것이 있는지 먼저 확인해보자!

Main

먼저 우리는 YAML 파일을 작성하기 전 주요 용어들에 대해 알아보자!
우리가 pods를 관리하는 방법은 여러가지가 있는데 여기서는 "kind"라고 명칭을 붙이도록 하자.

이러한 kind는 대표적으로 아래와 같은 종류가 있다.

• pods : 가장 최소한의 리소스로 pods 하나만을 만드는 방식

apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
  - name: pod1-cont
    image: nginx:1.14.0
    ports:
    - containerPort: 80

• RelicaSets : pods의 복제본 등을 관리하는 리소스이다. 해당 부분은 Deployment kind 내에서 "replicas"로 사용해도 되고 ReplicaSets 리소스 YAML을 만든 후 Deployment 리소스 YAML에서 관리해도 상관없다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: rs1-cont
        image: nginx:1.14.0

• Deployment : Deployment는 ReplicaSet을 관리하는 리소스로, 애플리케이션의 롤아웃 및 롤백과 같은 배포 전략 등을 사용할 수 있다!

  Deployment는 업데이트 가능한 ReplicaSet을 생성/관리하여 애플리케이션의 안정적인 배포를 가능하게 하는 것이다!

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dp1
spec:
  replicas: 3
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: dp1-cont
        image: nginx:1.14.0
        ports:
        - containerPort: 80

• DemonSet : 만약의 worker node 각각에 원하는 pods를 하나씩 넣고 싶을 때 사용한다. (만약 worker-node1에 몰빵했을 때 해당 node를 삭제했을 때 위험한 pod에 대해서 보통 만든다.)

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ds1
spec:
  selector:
    matchLabels:
      type: app
  template:
    metadata:
      labels:
        type: app
    spec:
      containers:
      - name: ds1-cont
        image: nginx
        ports:
        - containerPort: 8080

• job : 특정동작을 수행하고 종료하는 리소스

apiVersion: batch/v1
kind: Job
metadata:
  name: job1
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: job1-cont
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]

• Cronjob : 주기적으로 특정 동작을 수행하고 종료하는 작업(배치 작업)을 정의하기 위한 리소스 (즉, Job을 몇초마다 얼마나 등등을 확인하는 작업)

apiVersion: batch/v1
kind: Job
metadata:
  name: job2
spec:
  completions: 6
  parallelism: 2
  activeDeadlineSeconds: 30
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: job2-cont
        image: ubuntu
        command: ["sh", "-c", "echo 'job start';sleep 15; echo 'job end'"]

• Service : 파드 집합에 대한 네티워크 엔드포인트를 설정하는 리소스로, 외부 port와 Service 하위의 Deployments들에 대한 중간에 연결하는 곳이다. (외부 포트연결은 결국 Service단에서 실행)

apiVersion: v1
kind: Service
metadata:
  name: svc1
spec:
  selector:
    app: svc
  ports:
  - port: 9090 // WorkerNode에서는 <Cluster-ip>:9090형태로 확인이 가능하다.
    targetPort: 80
  type: ClusterIP

• ConfigMap : 민감하지 않는 데이터 설정 파일을 올려놓는 곳이다. 만약 여러 곳에 쓰여야하는 설정일 경우 한 곳에서 묶어서 사용하기 위한 방식이다.
• Secrets : 민감데이터를 위한 리소스이다. BASE64로 저장을 해놓는 형태이며 기존 Data를 Base64로 변환하는 방식은 매우 많다. 해당 YAML파일 작성 후 Deployment에서 가져가서 사용할 수 있다!

이외에도 매우 많지만 보통 위의 5개를 가장 많이 사용한다. 1 ~ 3번이 실제 Container가 생성/운영/관리하는 곳이다. 4 ~ 5번의 경우 편의성/보안과 관련이 많으며 실제 AWS를 사용할 때는 보안에 많은 부분들을 고민하며 생각해야한다.

위에서 언급은 하지 않았지만 Kind에는 pods라는 것도 있었다. 하지만 대부분 ReplicaSets를 사용하기에 위에서 빼서 작성하였다.갑자기 이 부분을 언급한 이유는 Replicasets의 장점에 대해서는 구체적으로 알아야 할 필요가 있기 때문이다.

단순한 pods 생성이 아닌 Relicaset을 kind로 썼을 때의 장점은 다음과 같다.

• 가용성 및 신뢰성: 복제본을 사용하면 파드의 가용성과 신뢰성을 향상시킬 수 있습니다. 파드에 장애가 발생하거나 유지 관리 작업이 필요한 경우, 다른 복제본이 해당 파드의 역할을 대신하고 요청을 처리할 수 있습니다.

  백업용으로 있으니까 든든하다는 말이다.

• 로드 밸런싱: 복제본을 사용하면 트래픽을 여러 파드에 분산시킬 수 있습니다. 로드 밸런싱을 통해 각 복제본이 동등하게 트래픽을 처리하므로, 애플리케이션의 성능과 응답 시간을 개선할 수 있습니다.

  Service 리소스에서의 엔드포인트(hostport)는 같으나 container port는 쿠버네티스가 알아서 port를 지정한다.
  만약 이 부분이 헷갈린다면 Docker에서 host port와 container port에 대한 이해를 하면 좋다!

• 스케일링: 복제본을 사용하면 애플리케이션의 수평 스케일링이 용이해집니다. 워크로드의 부하가 증가하면 추가 복제본을 생성하여 처리할 수 있으며, 반대로 부하가 감소하면 불필요한 복제본을 줄일 수 있습니다. 이를 통해 자원 사용의 효율성을 높일 수 있습니다.

  트래픽을 보면서 내가 복제본을 줄일 수 있다는 의미이다. Replica의 장점 중 하나가 "로드 밸런싱"이니까!

• 롤아웃 및 롤백: 복제본을 사용하면 애플리케이션의 업데이트 및 롤백을 용이하게 할 수 있습니다. 새로운 버전의 파드를 배포하기 전에 이전 버전의 복제본을 유지하면서 점진적으로 업데이트할 수 있습니다. 이를 통해 애플리케이션의 안정적인 배포와 문제 발생 시 롤백을 수행할 수 있습니다.

  Rolling Update로 무중단 배포가 된다는 의미이다. Replica가 2개라고 가정했을 때 새로운 v2가 나온다면
  v1 2개 > v1 1개,v2 1개 > v2에 Trouble Shooting이 없는지를 확인 > 정상 작동 시 > v2 2개 방식이다.

위와 같은 장점들 떄문에 Replicaset을 사용한다.

여기서 한가지 궁금증이 있을 수도 있다.
"복제는 그러면 많이 하면 할수록 좋은건가?"
이 대답은 당연히 "No"이다.

Replica가 많다는 것은 결국 해당 컴퓨터의 리소스를 많이 잡아먹는다는 의미가 된다. 그렇기에 컴퓨터의 성능(CPU/Memory)를 확인하여 얼마나 가능한지를 먼저 확인한 후 서비스의 중요도/트래픽량을 고려하여 진행해야한다.
=> 가장 간단하게만 사용하면 Replicas를 2개로 하는게 가장 좋지만 그러면 중간에 무중단 배포가 되더라도 살짝 끊길 수 있다.

Summary

Kubernetes worker node 리소스 종류에 대해 알아봤다.
kubernetes는 YAML파일을 이용하여 리소스를 관리한다.
Kubernetes는 Replicas의 좋은 점에 대해서는 알아야한다.