워크로드 리소스

파드를 직접 띄우는 일은 거의 없고 보통 워크로드 리소스를 사용하여 파드를 생성한다.
워크로드는 쿠버네티스에서 구동되는 애플리케이션이다. 워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의 파드 집합 내에서 실행한다. 쿠버네티스에서 Pod 는 클러스터에서 실행 중인 컨테이너 집합을 나타낸다.
사용자를 대신하여 파드 집합을 관리하는 워크로드 리소스 를 사용할 수 있다. 이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이 실행되고 있는지 확인하는 컨트롤러를 구성한다.

레플리케이션컨트롤러

ReplicaSet을 구성하는 Deployment가 현재 복제를 설정하는 데 권장되는 방법이다. ReplicationController 는 언제든지 지정된 수의 파드 레플리카가 실행 중임을 보장한다. 즉, 레플리케이션 컨트롤러는 파드 또는 동일 종류의 파드의 set이 항상 기동되고 사용 가능한지 확인한다.

# 리소스 확인하기, rc로 줄여서 사용
kubectl api-resources | grep replicationcontroller (rc) 

# 레플리케이션 컨트롤러 예제의 config는 nginx 웹서버의 복사본 세 개를 실행한다.
apiVersion: v1
kind: ReplicationController   
metadata:
  name: nginx
spec:
  replicas: 3
  selector:      
    app: nginx
  template:            #복제 파드를 어떻게 만들지에 대한 정보
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:                   
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        
# rc 내용 확인        
kubectl get rc

# rc로 인해 복제된 파드가 보임, 이름은 모두 고유함
kubectl get pods

# 템플릿의 메타데이터의 레이블이 동일하기에 모두 같음을 확인
kubectl get pods --show-labels

• selector: 템플릿에 보면 레이블이 있는데 파드를 만들게 되면 app:nginx라는 레이블이 붙는다. 내가 관리할 파드들이 app:nginx라는 레이블 있는 것들 만이라는것을 알려줌
  따라서 셀럭터에 있는 이름과 레이블의 이름은 무조건 같아야 한다.

• 외부에서 레이블을 바꾸게 된다면 이 파드는 레블리카 컨트롤러가 더이상 관리하지 않는다. 따라서 복제된 파드의 수를 맞추기 위해서 파드가 하나 더 생성된다.
  만약 다시 레이블을 원래대로 바꿔준다면 관리하는 파드의 수가 넘어가기 때문에 하나가 삭제된다.

• 시작구성, 시작 템플릿과 동일한 의미
  컨트롤러는 파드의 복제본을 지정하면 컨트롤러가 파드를 만듬, 컨트롤러 입장에서는 어떤 이미지를 가지고 파드를 만들지 정보가 필요한데 이것이 밑에서의 정보이이다.

kubectl explain rc.spec.template

# 파드를 어떻게 표현하는지를 나타내는데 이는 위 템플릿과 동일한 내용이다.
kubectl explain rc.spec.template.spec

• 만들어진 파드의 로그를 확인하는 방법

kubectl logs  pod/ngnix-xvbmz | head -2
kubectl logs rc/ngnix |head -2
kubectl logs rc ngnix | head -2

레플리카셋

레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다. 이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다. 레플라카컨트롤러는 레플리카셋으로 대체되고 있다.

• 레블리카컨트롤러는 셀렉터로 일치성 기준만 제공하고 레이블카셋은 일치성과 세트기반을 제공한다.

kubectl api-resources | grep replicasets  (rs)

# 안에 확인했을 때, 레플리카셋은 하위 필드가 추가로 있는 것을 확인
kubectl explain rs.spec.selector
->
FIELDS:
   matchExpressions     <[]Object>
     matchExpressions is a list of label selector requirements. The requirements
     are ANDed.

   matchLabels  <map[string]string>       # 일치성 기준
     matchLabels is a map of {key,value} pairs. A single {key,value} in the
     matchLabels map is equivalent to an element of matchExpressions, whose key
     field is "key", the operator is "In", and the values array contains only
     "value". The requirements are ANDed.

• 레플리카셋 예시, matchLabels의 내용과 템플릿의labels의 내용은 항상 일치해야한다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # 케이스에 따라 레플리카를 수정한다.
  replicas: 3
  selector:
    matchLabels:      # 일치성 기준, 밑에 템플릿의 레이블과 동일해야함!
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

• matchExpressions는 세트기반의 셀레터를 사용할 수 있도록 하기 위해서 레플리카셋이 사용되고 있다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-rs-exp
spec:
  replicas: 3
  selector:
    matchExpressions:      # 세트기반
      - key: app
        operator: In
        values:
          - myapp-rs-exp
      - key: env
        operator: Exists
  template:
    metadata:
      labels:
        app: myapp-rs-exp
        env: dev
    spec:
      containers:
      - name: myapp
        image: ghcr.io/c1t1d0s7/go-myweb:alpine
        ports:
        - containerPort: 8080

데몬셋(daemonset)

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

• 데몬셋은 복제본을 제공하지 않는다.

• 서비스를 enable 시키는 것은 운영체제 부팅시에 해당되는 프로세스를 백그라운드로 실행시키기 위함이다. 이를 데몬이라 한다.

• 데몬셋의 일부 대표적인 용도는 다음과 같다.

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

• 컨트롤플레인은 우리가 만든 일반적인 파드들은 배치되지 않도록 스케줄링 되었기 때문에 나머지 모든 노드에 하나씩 배치된다.

• nodeSelector은 pod.spec에도 있고 rs.spec.teplate에도 있다. 즉 파드의 템플릿을 쓰는 곳에서는 노드셀렉터를 사용할 수 있다는 것이다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: myapp-ds
spec:
  selector:
    matchLabels:
      app: myapp-ds
  template:
    metadata:
      labels:
        app: myapp-ds
    spec:
      nodeSelector:            # 노드 셀렉터가 파드에 선언되어있다.
        node: development
      containers:
      - name: myapp
        image: ghcr.io/c1t1d0s7/go-myweb:alpine
        ports:
        - containerPort: 8080

• 데몬셋에 의해서 kube-proxy가 자동으로 생성된다. 이는 다음을 통해 알 수 있다.
  

잡(Job)

잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도한다. 파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다. 지정된 수의 성공 완료에 도달하면, 작업(즉, 잡)이 완료된다. 잡을 삭제하면 잡이 생성한 파드가 정리된다. 작업을 일시 중지하면 작업이 다시 재개될 때까지 활성 파드가 삭제된다.

간단한 사례는 잡 오브젝트를 하나 생성해서 파드 하나를 안정적으로 실행하고 완료하는 것이다. 첫 번째 파드가 실패 또는 삭제된 경우(예로는 노드 하드웨어의 실패 또는 노드 재부팅) 잡 오브젝트는 새로운 파드를 기동시킨다.

• 잡은 셀렉터를 구성할 순 있지만 굳이 사용하지 않는다. 하나의 파드가 여러 컨트롤러에 의해 관리될 수도 있는데 만약 레플리카셋은 계속 실행시키려고하고 잡은 종료시키려고 하는데 이럴때 충동이 발생할 수 있기에 셀렉터를 사용하지 않는다.

파이(π)의 2000 자리까지 계산해서 출력한다. 이를 완료하는 데 약 10초가 소요된다.

# 파일내용
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]     # entrypoint를 대체함
      restartPolicy: Never
  backoffLimit: 4


# 파드 생성
kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml

# 1초에 한번씩 뒤 명령을 실행하여 내용을 실시간으로 확인
watch -n1 kubectl get jod,pods

# 내용확인
kubectl get job,po
NAME           COMPLETIONS   DURATION   AGE
job.batch/pi   1/1           102s       4m24s

NAME           READY   STATUS      RESTARTS   AGE
pod/pi-44xrx   0/1     Completed   0          4m24s


# 파드 중 하나를 표준 출력으로 확인, 이작업은 언제간 종료되는 작업이기 떄문에 잡으로 만드는 것이 좋다
kubectl logs pi-44xrx

• restartPolicy를 끄면 always가 기본값인데 그러면 파드가 만들어지지 않는다. 따라서 OnFailure(실패했을떄만 재시작)나 never(재시작 x)로 설정해주어야 한다.

• completion: 완료라는 의미로 작업이 하나가 끝나면 다음 작업을 실행한다. 완료횟수를 나타낸다고 보면된다.
• parallelism: 작업을 병렬로 동시에 실행시킬 수 있다.

크론잡(cronjobs)

크론잡은 반복 일정에 따라 잡을 만든다. 즉 크론잡이 잡을 만들어 만들어진 잡이 파드를 만드는 구조이다.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:                     # cronjob의 스펙
  schedule: "* * * * *"
  jobTemplate:
    spec:                 # job의 스펙
      template:
        spec:             # pod의 스펙
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure


# ┌───────────── 분 (0 - 59)
# │ ┌───────────── 시 (0 - 23)
# │ │ ┌───────────── 일 (1 - 31)
# │ │ │ ┌───────────── 월 (1 - 12)
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# │ │ │ │ │                                   특정 시스템에서는 7도 일요일)
# │ │ │ │ │                                   또는 sun, mon, tue, wed, thu, fri, sat
# │ │ │ │ │
# * * * * *

cronjob 실습

cd ../05_cronjob

kubectl create -f myapp-cj.yaml

watch -n1 kubectl get cj,job,pod

50초 정도가 지나면 파드가 종료되고 약 1분이 지나면 하나의 잡이 실행되는 것을 확인할 수 있다.

• 만약 startingDeadlineSeconds 가 큰 값으로 설정되거나, 설정되지 않고(디폴트 값), concurrencyPolicy 가 Allow 로 설정될 경우, 잡은 항상 적어도 한 번은 실행될 것이다.