Kubernetes

워크로드 리소스 (= 컨트롤러)

컨트롤러중 디플로이먼트와 스테이트풀셋은 추후 다룰 예정이고, 두개를 제외한 나머지 컨트롤러는 이번 장에서 다룰것이다.

replication controller

• ReplicaSet을 구성하는 Deployment가 현재 권장하는 레플리케이션 설정 방법이다.
  • ReplicaSet과 같은 기능을 가지고 있으며, rc는 조만간 사라질 기술이다.
• 레플리케이션컨트롤러는 언제든지 지정된 수의 파드 레플리카가 실행 중임을 보장한다. 다시 말하면, 레플리케이션 컨트롤러는 파드 또는 동일 종류의 파드의 셋이 항상 기동되고 사용 가능한지 확인한다 = 선언형의 특징, 선언한 개수를 항상 유지한다

kubectl get rc # 생성한 레플리케이션 컨트롤러(=rc) 보기 

kubectl explain rc # rc에 들어가는 항목 확인 

kubectl get pods --show-labels # rc로 생성한 파드들의 레이블 확인  

kubeclg get rc -o wide # rc가 셀렉터로 선택한 레이블 확인 가능 

📒 rc개념 참조

1 . 레플리케이션 컨트롤러 에제

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx # 리소스와 리소스의 연결(label의 두번째 목적)
  template: 
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

-> template아래에는 파드를 작성하는 것과 같이 metadata, spec을 작성해 원하는 컨테이너의 스펙을 설정을 해준다.
-> 파드가 매우 많다면 해당 파드를 생성한 rc는 자신이 생성한 파드만을 관리하는 것이 어렵다. 그리하여 자신이 생성한 파드만을 관리하기 위해 파드에 레이블을 붙이고, 셀렉터로 해당 레이블을 선택한다. 이것이 바로 레이블을 이용해 리소스간 느슨한 연결을 한것이다.
( =레이블의 목적 2번째 )
📗 만약 파드안에 컨테이너 하나의 레이블을 바꾸면 rc는 자신의 관리하는 레이블안의 컨테이너가 두개가 되기때문에 그 즉시 세개를 유지하기 위해 컨테이너 하나를 더 생성한다.

2 . 레플리케이션 컨트롤러 에제

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp-rc
spec:
  replicas: 3
  selector:
    app: myapp-rc
  template:
    metadata:
      labels:
        app: myapp-rc
    spec:
      containers:
      - name: myapp
        image: ghcr.io/c1t1d0s7/go-myweb:alpine
        ports:
        - containerPort: 8080

kubectl logs pod/replicatest-98bjn
# pod/pod이름으로 log확인할 수 있다.

replica set

• 레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다. 이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다.
  = 선언형의 특징 , 선언한 파드의 개수 유지

• 위의 replication controller와 기능이 같다.

• rc보다 rs를 사용하는것을 권장

• rc와 다른것은 집합성 기준과 일치성 기준이 존재한다.

• 레플리카셋은 지정된 수의 파드 레플리카가 항상 실행되도록 보장한다. 그러나 디플로이먼트는 레플리카셋을 관리하고 다른 유용한 기능과 함께 파드에 대한 선언적 업데이트를 제공하는 상위 개념이다. 따라서 우리는 사용자 지정 오케스트레이션이 필요하거나 업데이트가 전혀 필요하지 않은 경우라면 레플리카셋을 직접적으로 사용하기 보다는 디플로이먼트를 사용하는 것을 권장한다.

• 이는 레플리카셋 오브젝트를 직접 조작할 필요가 없다는 것을 의미한다. 대신 디플로이먼트를 이용하고 사양 부분에서 애플리케이션을 정의하면 된다.

kubectl get rs # 레플리카셋 확인 

📗 레플리카셋 개념 참조

1 . 일치성 기준을 포함한 레플리카셋 예시

apiVersion: apps/v1 # 버전이 다르다
kind: ReplicaSet
metadata:
  name: replicatest
spec:
  replicas: 5
  selector:
    matchLabels: # 일치성 기준 (rc와 다른점)
      suhwan: good
  template:
    metadata:
      labels:
        suhwan: good
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          protocol: TCP
        livenessProbe:
          exec:
            command: 
            - cat
            - /etc/passwd

-> rc와 다른것은 matchLabels 하나이고 그외 나머지는 모두 일치하고, 기능 또한 똑같다

2 . 집합성 기준을 포함한 레플리카셋 예시

apiVersion: apps/v1 # 버전 확인 
kind: ReplicaSet
metadata:
  name: myapp-rs-exp
spec:
  replicas: 3
  selector:
    matchExpressions: # 집합성 기준 추가 (rc와 다른점)
      - 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

-> rc와 다른것은 matchExpressions 하나이고 그외 나머지는 모두 일치하고, 기능 또한 똑같다

daemonset

kubectl api-resources # 리소스들 확인 

• 버전 : apps/v1
• shortname: ds

데몬 (프로세스,서비스)

• 백그라운드 프로세스, 운영체제 서비스
• apache, nginx같은 패키지를 백그라운드로 실행시킨다
• systemctl같은 것이 데몬이다. (systemd, sshd ,httpd 등..)

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

무조건 노드마다 하나씩 파드를 배치된다.

<데몬셋 용도>

• 모든 노드에서 클러스터 스토리지 데몬 실행
• 모든 노드에서 노드 모니터링 데몬 실행
• 모든 노드에서 로그 수집 데몬 실행
  -> ex) 각 파드의 로그는 해당 노드의 /var/log/pod에 수집된다. 하지만 만약 노드가 수백개라면 일일이 수백개의 노드의 해당 디렉터리에서 로그를 수집하는 것은 비효율적이다. 데몬셋을 이용해 각 노드에 파드를 배치해 백그라운드에서 로그를 수집하면 효율적이다.

kubectl get ds # 생성한 데몬셋 확인
kubectl get pods -o wide # 파드들이 각 노드에 하나씩 배치되었는지 확인 

📕 데몬셋 개념 참조

1 . 모든 노드에 대한 데몬셋 예시

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: myapp-ds
spec:
  selector:
    matchLabels:
      app: myapp-ds
  template:
    metadata:
      labels:
        app: myapp-ds
    spec:
      containers:
      - name: myapp
        image: nginx
        ports:
        - containerPort: 80

-> 모든 노드에 설정한 스펙을 가진 파드가 각각 생성된 것을 확인
-> 레이블을 통해 느슨한 연결을 하여 특정 파드만 관리

2 . 특정 노드에 대한 데몬셋 예시

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

-> 데몬셋을 이용해 모든 node에 백그라운드 파드를 배치할 수 있지만, nodeSelector를 이용해 특정 노드에만 파드를 배치할 수 있다. 이때 특정 노드를 가리키기 위해 노드가 가진 레이블을 사용한다.

📗 node도 레이블을 가지고 있다

job

kubectl api-resources

• 버전 : batch/v1

• 잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도한다
  = 종료를 보장한다
  -> job, cronjob을 제외한 다른 컨트롤러들은 종료가 아닌 애플리케이션의 지속적인 실행을 목표로 한다. 하지만 job은 애플리케이션/서비스의 종료를 목표로한다. 종료하게되면 재시작하지않고 끝난다.

kubectl get job, pods # 생성한 job과 pod보기

📗 job 개념 참조

1 . job 예시

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(1000)"]
      restartPolicy: Never
  backoffLimit: 4

-> 예시는 파이(π)의 1000 자리까지 계산해서 출력한다.
-> 쿠버네티스에서 재시작 정책이 Always이지만 job에서는 항상 Never로 설정해야 한다.
-> backoffLimit은 정상적으로 종료되지 않았을 때 재시작되는 횟수를 나타낸다.

kubectl logs pod/jobtest-mnjds 

-> 실제로 노드에 배치되서 작업한 파드의 로그를 확인하면 파이(π) 1000자리까지 작업한걸 볼 수 있다.

2 . 성공횟수를 지정한 job 예시

apiVersion: batch/v1
kind: Job
metadata:
  name: myapp-job-comp
spec:
  completions: 3 # 성공횟수 , 기본적으로 직렬실행 
  template:
    metadata:
      labels:
        app: myapp-job-comp
    spec:
      restartPolicy: OnFailure
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(1000)"]
    

-> completion을 3으로 지정했기 때문에 직렬 로 컨테이너 하나씩 생성 후 작업을 마무리하고 총 3번 완료하면 종료된다

3 . 성공횟수 지정과 병렬실행 예시

apiVersion: batch/v1
kind: Job
metadata:
  name: myapp-job-para
spec:
  completions: 3 # 성공횟수
  parallelism: 3 # 병렬실행 
  template:
    metadata:
      labels:
        app: myapp-job-para
    spec:
      restartPolicy: OnFailure
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(1000)"]
    

-> completion을 3으로 지정했기 때문에 병렬 로 컨테이너를 3개 생성하고 작업을 병렬로 3개 완료 후 종료된다

cronjob

버전 : batch/v1
shortname : cj

• 크론잡은 반복 일정에 따라 잡을 만든다.
• 크론잡이 잡을 만들고 잡이 파드를 만드는 구조이다
• 크론잡은 잡을 크론 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다
• 쉽게말해, 잡은 일회성으로 실행하는 작업이고, 그러한 잡을 주기적으로 반복하기 위해서 사용하는 것이 크론잡이다.

kubectl get cj,job,pods # 생성한 크론잡, 잡, 파드보기

📗 cronjob 개념 참조

1 . cronjob 예시

apiVersion: batch/v1
kind: CronJob
metadata:
  name: myapp-cj
spec: # cronjob의 스펙
  schedule: "* * * * *"
  jobTemplate:
    spec: # jpb의 스펙
      template:
        metadata:
           labels:
             app: myapp-cj
        spec: # 파드의 스펙 
          restartPolicy: OnFailure
          containers:
          - name: sleep
            image: busybox
            command: ["sleep", "50"]

1-1 . suspend

kubectl edit cj 크론잡이름 

-> edit을 통해 실시간으로 수정이 가능하고 suspend를 false에서 True로 변경하면 일시중지 시킬 수 있다.