워크로드 리소스

워크로드 (Workload) API 카테고리

 

 

이 리소스는 클러스터 위에서 컨테이너를 가동하기 위해 사용한다. 

 

 

 

목차

파드 ( Pod )

레플리케이션 컨트롤러 ( Replication Controller )

레플리카셋 ( ReplicaSet )

디플로이먼트 ( Deployment )

데몬셋 ( DaemonSet )

스테이트풀셋 ( StatefulSet )

잡 ( Job )

크론잡 ( CronJob )

 

 

 

 

 

 

레플리케이션 컨트롤러 RC

 

지정된 숫자만큼 파드의 갯수를 관리해주는 역할을 한다.  기능이 추가되며 이름이 레플리카셋으로 변경되었다. 고로 레플리카셋을 사용하도록 하자.  

 

 

 

 

 

 

레플리카셋 RS

 

RC의 새로운 버전으로 크게 차이는 없다. 

 

둘다 파드의 실행을 항상 안정적으로 유지시키기 위해 사용한다. 

 

하지만 레플리카셋만 사용하는것은 권장하지않는다고 나와있다. 그것의 상위개념인 디플로이먼트를 사용하도록 한다.

 

레플리카셋은 label의 일치여부를 확인하여 pod를 관리한다. 

 

아래를 보면  label을 일치시켰는데, 

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

 

 

위를 약간 변조해서 아래처럼 두가지 레플리카셋을 실행해보자. 

 

 

여기 두가지 레플리카셋이 있다. 하나는 label이 동일 ( s1 ) 하고 하나는 label이 다르다 ( s2 ) 

두개다 실행해보면 s1은 실행되지만, s2는 오류가 뜬다. 라벨을 일치시키지 않으면 오류가 뜬다. 

 

레플리카셋은 이렇게 파드를 관리한다. 

 

그러면 같은 label을 가진 pod를 밖에서 관리하면 어떻게 될까?

 

apiVersion: v1
kind: Pod
metadata:
  name: s3
  labels:
    app: sample-app
spec:
  containers:
    - name: nginx-container
      image: nginx:1.13
      ports:
      - containerPort: 80

 

 

아래 결과를 확인해보면

레플리카셋이 label을 확인하고 새로운 파드를 지워버렸다. 이처럼 label을 잘 관리해줘야지 안그러면 레플리카셋이 지워버린다. 

 

 

 

 

 

 

 

디플로이먼트 Deployment

 

 

 

여러개의 rs를 가져간다. 

 

위를 보면, 디플로이먼트가 레플리카셋을 관리하고 레플리카셋이 파드를 관리하는 관계가 된다. 

레플리카셋을 소유하거나 여러 업데이트를 지원하는 오브젝트이다. 

파드와 레플리카셋 ( RS ) 에 선언적 업데이트를 하는데, 명령만 내리면 바로바로 변경해준다. 

 

 

 

 

 

 

생성되는 pod의 갯수를 조정하는 방법

 

여기에서

 

k edit rc nginx

 

변경하고

 

6개로 늘어남

 

 

 

스케일을 명령어로 조정하는 방법

2개로 줄었다.

 

이번엔 버전변경하기

k edit rc nginx

 

 

 

확인해보면 버전이 바뀌어있다.

 

 

 

 

 

 

 

kubectl set

 

기능들을 설정하는 명령어

 

현재 아래와 같은 레플리카 컨트롤러에 

아래명령어처럼 치면 변경가능하다. 

변경된 것을 볼 수있다. 

 

 

 

레플리케이션 컨트롤러만 삭제하는 명령어

 

 

--cascade=orphan

 

 

 

 

 

 

 

 

 

 

 

 

RS 실행

 

아래처럼 된 yaml파일을 실행하면 

 

 

 

 

실행이 된다. 

 

 

 

 

deployment 실행

 

아래와같은 yaml파일을 만들어서

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

아래처럼 만들어진다. 

순서대로 확인해보면 아래처럼 종속된것을 확인할 수 있다.

 

 

 

 

kubectl rollout status deployment/dep-nginx

 

※ 버전업데이트 / 파드 갯수 변경 / 리소스제한

 

 

1. 버전업데이트 

아래처럼 하면 

확인해봤을때, 

2. 파드 갯수 변경

 

5개로 늘리고, 2개로 줄임

 

 

 

 

3. 리소스 제한

 

 

 

 

 

 

 

데몬셋

 

 

각 노드마다 하나씩만 파드를 배치하는 특수한 형태의 레플리카셋이다. 

 

사용용도는 보통 각 파드가 출력하는 로그 수집이나, 사용현황을 모니터링하는 데이터독 등 모든 노드에서 반드시 동작해야하는 파드를 뒷받침하는 프로그램용이다. 

 

두개씩 할수도 없으며, 제외할 노드는 설정할 수 있다. 

 

 

아래는 데몬셋의 예제이다. 

 

 

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: s7
spec:
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
        - name: nginx-container
          image: nginx:1.12
          ports:
            - containerPort: 80

 

레플리카셋처럼 레플리카 수를 지정할 수는 없다. 

 

확인해보면 각 노드마다 하나씩만 배치되어있는것을 확인 할 수 있다. 

 

 

 

 

 

 

스테이트풀셋

 

 

 

데몬셋처럼 레플리카셋의 특수한 형태이다.

두가지 특징이 있는데,

 

새로 생성될때마다 파드 명이 바뀌지 않아 데이터베이스같은 stateful(상태저장)을 위한 요소에 사용하기 위한 리소스이다. 

데이터를 영구적으로 저장하기 위한 구조로 되어있다. 

 

아래 스테이트풀셋을 실행해보자. 

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: s1
spec:
  serviceName: s1
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
        - name: nginx-container
          image: nginx:1.12
          ports:
            - containerPort: 80
          volumeMounts:
          - name: www
            mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 1G

 

 

 

 

 

잡

 

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

 

목적만 달성하면 파드가 정지되는것이다. 

 

 

간단한 예로 살펴보자. 아래 yaml을 실행하자.

apiVersion: batch/v1
kind: Job
metadata:
  name: j1
spec:
  completions: 1
  parallelism: 1
  backoffLimit: 10
  template:
    spec:
      containers:
      - name: sleep-container
        image: centos:6
        command: ["sleep"]
        args: ["60"]
      restartPolicy: Never

 

 

위에서 살펴보면

completions는 성공횟수

parallelism은 병렬성

backoffLimit는 실패를 허용하는 횟수이다. 

그러므로 위의 경우는 1개의 병렬로(parallelism) 1번 성공횟수를 목표로(completions) 하며 10회의 실패를 허용(backoffLimit)한다. 

 

 

 

실행해서 지켜보면 

 

아래처럼 확인할 수 있다 

 

 

잡에서는 restartPolicy가 있는데, Onfailur와 Never 중 하나를 지정할 수 있는데, 

 

Never : 파드에 장애가 발생하면 신규 파드가 생성된다

Onfailur : 파드에 장애가 발생하면 다시 동일한 파드가 생성된다. 

 

 

 

 

 

크론잡

 

하는일을 스케줄링된 시간에 잡을 생성한다 

 

디플로이먼트와 레플리카셋의 관계라고 볼 수 있다.

 

 

아래 예제로 크론잡을 실행해보자. 

 

1분마다 50%확률로 성공하는 한번만실행되는 잡을 포함하고 있다. 

apiVersion: batch/v1
kind: CronJob
metadata:
  name: c1
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
  startingDeadlineSeconds: 30
  successfulJobsHistoryLimit: 5
  failedJobsHistoryLimit: 3
  suspend: false
  jobTemplate:
    spec:
      completions: 1
      parallelism: 1
      backoffLimit: 1
      template:
        spec:
          containers:
          - name: sleep-container
            image: centos:6
            command:
            - "sh"
            - "-c"
            args:
            # 약 50% 확률로 성공하는 명령어
            - "sleep 40; date +'%N' | cut -c 9 | egrep '[1|3|5|7|9]'"
          restartPolicy: Never

 

여기 컨테이너인 amsy810/random-exit는 50%확률로 성공하는 명령어가 실행된다. 

 

 

 

 

 

크론잡은 지정한 시간에 계속 잡을 생성한다.

점검이나 여러 사항으로 잡을 생성하기 원치않을경우, 

suspend를 false에서 true로 변경한 후 apply하면 된다.

 

 

 

잡의 동시실행 제어도 할 수 있다. spec.concurrencyPolicy 에서 변경하면 된다

Allow, Forbid, Replace 세가지 값이 있는데 이는 아래와 같은 특성이 있다. 

 

잡의 실행 시작 기한 제어도 할 수 있는데,  spec.startingDeadlineSeconds 에서

 

매시 00분에 실행하는 잡을 00~05분까지 허용하려면

 

300초로 설정해야한다. 

 

또한 이력을 남길수도 있다. 

spec.successfulJobsHistoryLimit와 

spec.failedJobsHistoryLimit

이 두가지는 성공한 잡, 실패한 잡을 저장하는 갯수를 지정할 수 있다.