워크로드

 

 

 

https://kubernetes.io/ko/docs/concepts/workloads/

워크로드

 

워크로드

 

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

사용자를 대신하여 파드의 실패시 재생성 등 파드 집합을 자동으로 관리해주는 리소스이다.

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

 

• Deployment 및 ReplicaSet (레거시 리소스 레플리케이션컨트롤러(ReplicationController)를 대체). Deployment 는 Deployment 의 모든 Pod 가 필요 시 교체 또는 상호 교체 가능한 경우, 클러스터의 스테이트리스 애플리케이션 워크로드를 관리하기에 적합하다.
• StatefulSet는 어떻게든 스테이트(state)를 추적하는 하나 이상의 파드를 동작하게 해준다. 예를 들면, 워크로드가 데이터를 지속적으로 기록하는 경우, 사용자는 Pod 와 PersistentVolume을 연계하는 StatefulSet 을 실행할 수 있다. 전체적인 회복력 향상을 위해서, StatefulSet 의 Pods 에서 동작 중인 코드는 동일한 StatefulSet 의 다른 Pods 로 데이터를 복제할 수 있다.
• DaemonSet은 노드-로컬 기능(node-local facilities)을 제공하는 Pods 를 정의한다. 이러한 기능들은 클러스터를 운용하는 데 기본적인 것일 것이다. 예를 들면, 네트워킹 지원 도구 또는 add-on 등이 있다. DaemonSet 의 명세에 맞는 노드를 클러스터에 추가할 때마다, 컨트롤 플레인은 해당 신규 노드에 DaemonSet 을 위한 Pod 를 스케줄한다.
• Job 및 CronJob은 실행 완료 후 중단되는 작업을 정의한다. CronJobs 이 스케줄에 따라 반복되는 반면, 잡은 단 한 번의 작업을 나타낸다.

 

 

 

Deployment 및 ReplicaSet

 

레플리카셋은 디플로이먼트에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용

디플로이먼트는 여러개의 RS 를 관리

RS 는 하나 이상의 POD 를 관리

디플로이먼트 생성 순서

디플로이먼트 생성 → RS 생성 → POD 생성

 

예시로 레플리카 3개를 만드는 디플로이먼트를 생성해보자.

# 디플로이먼트
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dep-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80

# 레플리카셋
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80

 

다음과 같이 3개의 해시 이름이 붙은 레플리카가 생성된다. (pod 의 이름은 ‘RS + POD’ 로 생성된다.)

이렇게 파드가 생성되면 레플리카셋(RS)을 삭제해도 다시 생성된다.

디플로이먼트가 관리자기이기 때문에 디플로이먼트를 삭제하지 않는 이상 다 관리할 수 있다.

디플로이먼트 확인

k get deployment

 

레플리카셋 확인

k get rs

 

디플로이먼트의 특징은, 파드를 지워도 만들때 쓴 템플릿을 다시 참조하여 그대로 지워진 컨테이너 수 만큼 새로 생성한다는 점이다.

자동으로 복구된 파드는 해시 이름이 달라져서 재생성된다.

# k delete pods nginx-zddcg

# k get pods --show-labels

yaml파일의 replicas: 3 부분을 6으로 바꾸면 금방 6개의 파드를 생성해낼 수 있다.

이렇게 디플로이먼트는

scale out과 scale in이 빠르고 (동일 스펙의 장비 개수 조절)

scale up과 scale down이 빠르다 (장비의 스펙을 올리거나 내리는 것)

 

스케일 아웃

k scale deploy dep-nginx --replicas=5

 

스케일 인 ( cpu 100m, RAM 32Mi )

k set resources deploy dep-nginx --limits=cpu=100m,memory=32Mi

 

 

 

 

 

statefulset

 

클라이언트와 서버 관계에서, 서버가 클라이언트의 상태를 보존하는 형태의 서비스

파드 이름, 네트워크 신원, 스토리지 관계의 상태를 유지하여 Application의 안정적인 상태를 가지게 하는 워크로드 API 오브젝트

Statefulset을 생성하면 Pods에 PVC(영구 볼륨 클레임) 설정

 

구분 레플리카셋 스테이트풀셋

파드 생성 시 이름 설정	Random 이름으로 설정 cf) Pod-ska25, Pod-dk15d ...	Ordinal index 이름으로 생성 cf) Pod-0, Pod-1, Pod-2 ...
파드 생성 시 순서	동시 생성	순차 생성 ( 0->1->2... )
파드 Recreate 시	파드 이름 변경 cf) Pod-sdf34 -> Pod-vjng3	파드 이름 유지 cf) Pod-2 -> Pod-2
파드 삭제 시 순서	동시 삭제	인덱스 높은 순부터 순차 삭제 ( 2->1->0 )
볼륨 생성 하는 방법	PVC를 직접 생성	volumeClaimTemplates 을 통한 동적 생성
파드의 수를 늘리면 PVC는?	1개의 PVC에 모두 연결	각각의 PV 를 생성한 뒤 연결
PVC 연결된 특정 파드를 죽으면?	NodeSelector 가 설정 되어 있다면 해당 노드에 동일한 서비스로 랜덤한 파드이름 생성(같은 노드에 PVC,파드가 생성되지 않으면 연결되지 않음)	특정 파드와 동일한 파드를 생성 후 기존 PVC와 연결
PVC가 연결된 파드 수를 0으로 하면?	PVC도 삭제함	PVC는 삭제하지 않음

 

node3 에서 진행

systemctl status nfs-server

저번에 설정한 nfs-server가 활성화 되어 있음

exportfs

 

node2, 3에서

cat > st-nginx.yaml

apiVersion: v1
kind: PersistentVolume # PV 설정
metadata:
  name: nfs-pv # pv명
spec:
  capacity:
    storage: 10Gi # pv 용량
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  storageClassName: manual
  persistentVolumeReclaimPolicy: Recycle
  nfs:
   server: 192.168.108.6 # pv 서버 지정
   path: /html
---
apiVersion: v1
kind: PersistentVolumeClaim # PVC 설정
metadata:
  name: nfs-pvc # pvc명
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 2Gi
  storageClassName: manual # 접점자
---
apiVersion: apps/v1
kind: StatefulSet # statefull set 설정
metadata:
  name: st-nginx # statefull명
spec:
  replicas: 3
  serviceName: st-nginx
  podManagementPolicy: OrderedReady # 순차적으로 파드 생성(병렬처리 하려면 'Parallel' 입력
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80
        volumeMounts: # 볼륨 마운트 설정
        - mountPath: /usr/share/nginx/html # 마운트 볼륨 위치
          name: pvc-volume # pvc 연결
      volumes:
      - name: pvc-volume
        persistentVolumeClaim:
          claimName: nfs-pvc

k create -f st-nginx.yaml

k delete pods st-nginx-2

이름, 노드, 볼륨이 모두 동일한 파드가 자동 재생성된다.

node3에서 진행

cd /html

echo "Hello SeSAC" > index.html

 

master node에서 진행

curl http://10.40.0.2

마운트된 볼륨에서 수정한 내용이 잘 출력 됨

k scale statefulset st-nginx --replicas=5

curl http://10.36.0.3

스케일아웃으로 생성 된 파드들도 모두 동일한 내용을 출력함

 

k delete statefulset --all

 

 

 

Job

1개 이상의 파드를 지정한 후 지정한 파드를 성공적으로 실행하도록 하는 설정

 

apiVersion: batch/v1
kind: Job
metadata:
  name: job-example # job의 이름
spec:
  completions: 5 # Pod를 5개 순차적으로 실행.
  parallelism: 2 # running중인 Pod를 2개까지 유지, completions 5 까지
  activeDeadlineSeconds: 5 # 작업이 5초내에 마치지 않으면 강제로끝냄
  template:
    spec:
      containers:
      - name: centos-container
        image: centos:7
        command: ["bash"]
        args:
        -  "-c"
        - "echo 'Hello world' ; sleep 50 ; echo 'Bye' "
      restartPolicy: Never # 파드의 재시작 정책 (Job 실패 시 Pod를 재실행 X)
    # restartPolicy: Always # Job 실패하면 Pod 재실행
    # restartPolicy: OnFailure # Job 실패하면 Pod 재실행
    # backoffLimit: 6 # 기본값 OnFailure 때 Pod 재실행 횟수 제한

 

job으로 파드 실행

k create -f job.yaml

watch get pods -o wide