[Kubernetes] Workload Resources

✔️ Workload란 ?!

워크로드란 쿠버네티스에서 구동되는 어플리케이션이다. 

워크로드가 단일 구성 요소든 함게 작동하는 여러 구성 요소이든 상관없이 쿠버네티스에서는 Pod 세트 내에서 실행한다.

 

쿠버네티스 Pod에는 LifeCycle이 정의되어 있다. 

예를 들어 클러스터에서 Pod가 실행 중에 그 Pod가 실행 중인 노드에 심각한 장애가 발생하면 해당 노드의 모든 Pod에 장애가 발생한다는 것을 의미한다. 

노드가 나중에 정상 상태가 되더라도 복구하려면 새 Pod를 생성해야 한다. 

 

그러나 Pod의 LifeCycle을 관리하기 위해 우리는 각 Pod를 직접 관리할 필요가 없다. 

우리대신 Pod set을 관리하는 Workload Resources를 사용할 수 있다. 

 

✔️ Workload Resources란 ?!

Workload Resources란 Pod의 LifeCycle을 관리하기 위해 사용하는 것이다.

Pod의 상태가 지정한 상태와 일치하는지 (올바른 수의 올바른 파드 유형이 실행되고 있는지) 확인하는 컨트롤러를 구성한다. 

Kubernetes는 다음과 같이 여러가지 빌트인(Built-In) Workload Resources를 제공한다.

 

✔️ Workload Resources의 종류

워크로드 리소스

• Deployments
• ReplicaSet
• StatefulSets
• DaemonSet
• Jobs/CronJob
• Automatic Clean-up for Finished Jobs
• ReplicationController

 

✔️ Deployment 및 ReplicaSet

https://www.ianlewis.org/en/bluegreen-deployments-kubernetes

• Pod, ReplicaSet이 어떻게 구성되어야하는지 정의한다.
  • ReplicaSet: 지정된 수의 Pod Replica가 항상 실행되도록 보장한다.
  • 단독으로도 사용가능하지만(kind: ReplicaSet), 디플로이먼트가 더 폭넓은 기능을 제공하는 상위 개념이기 때문에 디플로이먼트를 사용하는 것이 권장된다.
• 버전 업데이트 등으로 인해 원하는 정의가 변경되었을 때는 현재 상태에서 원하는 상태로 바뀌도록 변경한다.
  • 변경 사항을 저장하는 revision을 남겨서 문제 발생 시에 이전 버전으로 롤백도 가능하다.

 

replicaset-version1에서 replicaset-version2으로 변경

• 업데이트 방식도 정의할 수 있다.
  • 블루/그린: 포드를 한번에 싹 갈아엎는다.
  • 롤링: 하나씩 차례로
  • 카나리: 일부는 신버전 일부는 구버전
• Webserver, WAS처럼 Stateless한 application에 주로 이용된다.

deployment 사용 .yaml 파일 예시

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

• apiVersion apps/v1 → 쿠버네티스의 apps/v1 API를 사용
• kind: ReplicaSet → ReplicaSet의 작업으로 명시
• metadata.name → Replicaset 이름을 설정
• spec.template.metadata → 어떤 파드를 실행할지에 대한 정보를 하위에 설정 
• spec.template.metadata.name → 생성될 파드의 이름을 지정
• spec.template.metadata.labels.app:test-replicaset → 식별하는 레이블이 앱 컨테이너이며 test-replicaset 으로 식별
• spec.spec → 이 하위의 옵션들은 컨테이너에 대한 설정을 합니다. 위 코드에선 컨테이너 명, 이미지, 포트를 지정 했다.
• replicas → 파드의 개수를 몇개 유지할 것 인지 설정, 기본값은 1 
• selector → 어떤 레이블의 파드를 선택하여 관리할지에 대한 설정. 앱 컨테이너의 test-replicaset 레이블을 식별하여 해당되는 파드들을 관리하며, 이 필드가 없을 경우 spec.template.metadata.labels.app 에 적은 내용들을 기본값으로 사용

 

✔️ StatefulSet

이름처럼 위의 Deployment와 달리 Stateful한 pod를 관리하기 위한 controller다.

그래서 pod들의 고유성과 순서를 보장한다.

• Database는 마스터노드가 기동된 후에 워커노드가 순차적으로 기동되어야하는 경우가 많은데, 이런 경우에 사용한다.
• 개별 포드가 Persistent Volumn(PV)을 생성하여 연결하도록 실행한다. Pod가 비정상 종료된 경우에 새 Pod가 기존 Pod에 연결된 PV를 담당하게 된다.

 

✔️ DaemonSet

- 모든 노드에 동일한 파드를 실행시키고 싶은 경우 활용

- 리소스 모니터링, 로그 수집기 등에 유용. 클러스터에 노드가 추가/삭제되면 자동으로 파드도 생성/삭제됨

 

모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 파드도 함께 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 수집된다. 데몬셋을 삭제하면 데몬셋이 생성한 파드들이 함께 정리된다.

용도는 3가지이다.

• 모든 노드에서 클러스터 스토리지 데몬 실행
• 모든 노드에서 로그 수집 데몬 실행
• 모든 노드에서 노드 모니터링 데몬 실행

단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다.

 

✔️ Job 

Job은 하나 이상의 Pod를 지정하고 지정된 수의 파드를 성공적으로 실행하고 종료될 때까지 포드의 실행을 재시도 한다. 노드의 H/W 장애나 재부팅 등으로 인해 파드가 정상 실행이 되지 않았을 경우 Job은 새로운 파드를 시작하도록 할 수 있다. 즉, 백업이나 특정 배치 파일들처럼 한번 실행하고 종료되는 성격의 작업에 사용될 수 있다.

일반적으로 Pod가 시작되면 항상 실행하는 것을 기대하는 것과 달리 Job은 실행되면 몇분 또는 몇 시간, 몇일 뒤에 종료되는 것 (또는 주기적으로 실행되는 작업)을 실행한다. 그리고 실행이 잘 되었다는 결과를 사용자가 확인할 수 있다.  

• Job을 삭제해야 Job이 생성한 포드가 정리된다.
• 작업 유형
  • Non-Parallel Jobs
  • Parallel Jobs with a Fixed complete count
  • Parallel Jobs with a work queue

 

✔️CronJob

CronJob은 지정한 일정에 따라 반복적으로 Job을 생성한다.

 

 

🔗참고

https://moons08.github.io/programming/k8s-basics/

https://artist-developer.tistory.com/34

https://nirsa.tistory.com/136?category=871751

https://valuelog.tistory.com/82?category=893048#%EC%-A%A-%ED%--%A-%EB%A-%AC%EC%A-%--%--%EC%--%A-%EB%B-%-C%EC%A-%-D%ED%-A%B-

https://malwareanalysis.tistory.com/151