그림으로 배우는 쿠버네티스 CH3 애플리케이션 배포법

배포 형태는 오브젝트이다.

오브젝트는 파드, service, namespace, volumes 가 있는데, 그중 Pod와 파드와 관련된 오브젝트들을 알아본다.

애플리케이션으로 배포되는 오브젝트 형태

1. 파드 (Pod)
2. 디플로이먼트 (Deployment)
3. 레플리카셋 (ReplicaSet)
4. 잡(Job): 파드로 계속 떠있으면 부담이 되는 작업을 처리하기 위한 오브젝트
5. 크론잡 (CronJob) : 잡을 주기적으로 실행할 수 있도록 하는 오브젝트
6. 데몬셋 (DaemonSet) : 노드마다 1개씩만 올라가는 파드 (칼리코)
7. 스테이트풀셋 (StatefulSet) : 순서를 지키면서 배포가 되고 상태를 가지고 있는 파드
   • 기존의 Pod는 stateless이다.

파드(Pod)

pod.yaml

apiVersion: v1 #적합한 API 버전
kind: Pod #종류
metadata: #메타성 데이터
    labels: #별명 
        run: po-nginx 
    name: po-nginx
spec:  #Pod에서 호출할 컨테이너 이미지 지정 
    containers:
    - image: nginx
        name: nginx

• apiVersion : 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전
• kind : 오브젝트 종류
• metadata : 오브젝트를 유일하게 구분지어 줄 데이터, 레이블과 네임으로 구성됨
• spec : 오브젝트에 대해 의도한 상태. 파드에서 호출할 컨테이너 이미지 지정

 

실습

cat _Lect/pod.yaml

k apply -f _Lect/pod.yaml
k get po 
k get po -o wide 
k delete -f pod po-nginx

디플로이먼트(Deployment)

deployment.yaml

apiVersion: apps/v1  # Deployment는 apps/
kind: Deployment 
metadata:
  labels:
    app: deploy-nginx
  name: deploy-nginx 
spec: 
  replicas: 3
  selector: # 템플릿과 연결되어있다. 
    matchLabels:
      app: po-nginx # 동일해야함 
  template: # 붕어빵 틀과 같다.
    metadata:
      labels:
        app: po-nginx #동일해야함
    spec:
      containers:
      - name: nginx
        image: nginx

• selector : 디플로이먼트가 관리할 파드를 찾는 방법 정의. selector가 템플릿을 선택하는 구조로, template의 app과 selector app 이 같아야 함.
• template : 파드를 생성하는 템플릿
• 디플로이먼트가 파드를 포함하고 있는 구조
  • 템플릿하고 pod 구조가 같다. 디플로이먼트는 템플릿을 통해서 파드를 여러개 만든다.

 

레플리카셋(ReplicaSet)

replicaset.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  labels:
    app: rs-nginx
  name: rs-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: po-nginx
  template:
    metadata:
      labels:
        app: po-nginx
    spec:
      containers:
      - image: nginx
        name: nginx

• 디플로이먼트와 kind를 제외하고 코드 차이는 없음.

 

ReplicaSet 대신 Deployment를 사용하는 이유

 

• 컨테이너 버전을 올리는 것임.
• 위의 이미지는 컨테이너 버전을 순차적으로 Update하는 Rolling Update 과정을 나타냄 (롤링 업데이트)
• Deployment가 1개만 있을 경우 Update를 위해서는 추가적인 Deployment가 필요
• 그러한 구조 대신 Deployment가 ReplicaSet을 만들고 ReplicaSet의 복제본으로 업데이트를 진행
• Deployment가 replicaSet를 만들고 두개를 같이 유지하면서 업데이트 할 수 있기 때문에 replicaSet은 하위에서 유지하는 존재로 남아있고, 디플로이먼트는 전체 pod를 관장하는 오브젝트로 남게 된다.

k get replicasets.app # 레플리카 오브젝트 확인
k get deployments.app # 디플리카 오브젝트 확인 
k delete deploy deploy-nginx
k delete replicasets.apps rs-nginx 

커맨드(command)와 인자(args)

컨테이너에 명령이 필요한 이유

계속 동작하게 하고 싶을 때

생성이 됐고, complete이 되었는데, 더 할게 없으니까 crash loop back off라고 해서 죽어버린다.

command : ["/bin/sh", "-c", "sleep 3600"] # 다음과 같은 명령어 사용함

k exec simple-command -it -- /bin/bash #들어가 봄 
nslookup kubernetes # 쿠버네티스 이름으로 리턴 ip 가 있음을 확인 
exit 
k delete pod simple-command 

사용자가 원하는 명령을 내리고 싶을 때

command : ["/bin/sh" , "-c", "echo run multiple-command-v1 && sleep 3600"]

명령에 인자(args)를 추가하는 방법

 

잡(Job)

1-1-job-curl-succ

apiVersion: batch/v1
kind: Job
metadata:
  name: job-curl-succ
spec:
  template:
    spec:
      containers:
      - name: net-tools
        image: sysnet4admin/net-tools
        command: ["curlchk", "nginx"]
      restartPolicy: Never

• apiVersion: 일괄적으로 일어난다는 의미의 batch
• 한 번에 여러 개의 잡을 순차적 또는 동시에 실행할 수 있음 ( 따라서 템플릿으로 감싸져 있음)
• restartPolicy: 지정하지 않을 경우 기본이 Always
  • 잡에서 이것을 지정하지 않으면 잡의 본연에 목적에 맞지 않으므로 에러 발생. 다시 시작되는 거 하게 하면 안됨. 로그 보존이 안되기 때문에.
  • 리소스를 더이상 쓰지 않고, 추후에 확인을 하고자 complete 상태를 유지하는 것. 따라서 never로 지정함.
• 실행하고 결과를 log로 확인할 목적으로 사용

k get po
k get svc
k logs ...

잡의 병렬 실행

 

• completions: 순차적 실행
• parallelism: 병렬 실행

잡의 자동 종료

 

• activeDeadlineSeconds: 실행 후 완료 여부에 상관 없이 일정 시간 경과 시 종료
• ttlSecondsAfterFinished: TTL(Time To Live), 잡이 완료된 시점 이후 일정 시간 경과 시 종료

크론잡(CronJob)

주기성을 가지고 실행되어야 할 내용이 있을 경우 사용하는 오브젝트

cronjob-1m-hist10-curl.yaml

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cj-1m-hist3-curl
spec:
  schedule: "*/1 * * * *"
  successfulJobsHistoryLimit: 10
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: net-tools
            image: sysnet4admin/net-tools
            command: ["curlchk", "nginx"]
          restartPolicy: Never

• successfulJobsHistoryLimit: 기본값은 3, 이 수치를 넘는 동작 완료된 크론잡은 삭제됨

크론(cron) 규칙

 

데몬셋(DaemonSet)

노드마다 1개씩 배포되는 파드

• kind는 대소문자 구분 잘해야한다.

daemonset.yaml

 

• deployment 와 데몬 셋의 차이? 디플로이먼트는 배포 갯수를 지정해줘야 하지만 데몬셋은 워커 노드마다 1개씩만 배포되기 때문에 replicas 항목이 없음
• 워커노드가 총 3개면 3개가 배포가 된다. 이거 이외에도 데몬셋이 있다.
• 워커노드 하나 추가를 위해, 프로비저닝을 진행한다.
  • vagrant up을 명시해주면 provisioning이 가능하다. 슈퍼푸티로 돌아가서 데몬셋 동작을 본다. 그러면 워커 노드가 하나 늘어나서 데몬셋 하나 더 추가된다.
• 데몬셋 노드 단위로 배포하기 적합하다.

k get nodes
k get po -o wide
k get daemonsets.apps -A 
k deletenode w4-k8s
k get node
k delte -f _Lecture/*...
k get po
vagrant destroy -f w4-k8s-1.22

스테이트풀셋(StatefulSet)

상태를 유지하고 있는 파드

statefulset.yaml

 

• serviceName : 쿠버네티스에서 제공하는 서비스 오브젝트의 이름. 필수 값 (꼭 넣어야 함!!!!)
• 스테이트풀셋으로 배포할 경우 해시값이 아닌 고정된 이름을 가짐
• 상태값을 유지해야한다. 정확한 순서를 알아야 한다.
• 순서를 가지고 배포해야할 때, ELK 스택 이용할 때(? 이건 아직 잘 모르겠다. 나중에 찾아봐야 할듯) 쓴다.
• 스케일 아웃해서 replicaSet 많이 만들면 어떻게 될까? → 차례로 더 늘어나게 된다. 반대로 줄이면, 카운트 다운으로 세개로 줄어든다.