[k8s] 기본 오브젝트의 yaml 파일

1. 파드(Pods)
2. 디플로이먼트(Deployment)
3. 레플리카셋(ReplicaSet)
4. 잡(Job)
5. 크론잡(CronJob)
6. 데몬셋(DaemonSet)
7. 스테이트풀셋(StatefulSet)

---

 

 

0. yaml파일 생성 후, kubectl 에서 명령어로 실행 

kubectl apply -f ____.yaml

 

+ 예시 yaml 은 쿠버네티스 공식문서 - 워크로드 리소스 부분 참고 

1. 파드(Pods)

pod .yaml

apiVersion: v1 
kind: Pod
metadata:
  name: nginx #kubectl get pod 하면 나오는 이름
  labels: #pod의 레이블, 레이블은 필수값 아님 
    runs: nginx
spec: # 배포할 컨테이너에 대한 값, Pod에서 호출할 컨테이너 이미지 지정
  containers:
  - name: nginx
    image: nginx

 

2. 디플로이먼트(Deployment)

deployment.yaml

apiVersion: apps/v1 #Pod는 v1인데, Deploy는 apps/v1 인것 확인 
kind: Deployment
metadata:
  name: nginx-deployment  #kubectl get deploy로 조회되는 이름
  labels:
    app: nginx #deploy의 레이블
spec:
  replicas: 3 #pod를 몇 개 생성 할 지 
  selector: #selector는 template와 연결됨 
    matchLabels: 
      app: nginx
  template: #일반적으로 Pod 구조와 같다. pod를 똑같이 여러개 만들기 > 템플릿 
    metadata:
      labels:
        app: nginx #selector.matchLables.app = template.metadata.labels.app 
    spec:
      containers:
      - name: nginx
        image: nginx

 

3. 레플리카셋(ReplicaSet)

replicaset.yaml

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

yaml 파일을 살펴보니 kind가 ReplicaSet으로 명시된 것 이외에는 Deployment와 거의 동일한 정보를 가지고 있다. 

deployment는 replicaset보다 상위 개념이다. 

1) ReplicaSet 선언, Deployment 선언 한 뒤 

 - kubectl get deployment.apps > Deployment만 조회됨 

 - kubectl get replicasets.apps  >  ReplicaSet, Deployment  모두 조회됨 

2) Deployment delete한 뒤에 ReplicaSet 도 삭제해야한다. 

 

ReplicaSet의 존재 이유 : 컨테이너 버전을 업데이트 할 때, Deploy는 그대로 있는 상태에서 ReplicaSet  이 replica를 조절하면서 pod를 업데이트 하기 때문

 

 

4. 잡(Job)

job.yaml

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)"]
      restartPolicy: Never #반복실행 진행하지 않는다. 기본값은 "문제가 있으면 언제나 다시 시작한다" 임 
  backoffLimit: 4

job에는 필수적으로 넣는 요소  restartPolicy: Never 

기본값은 always인데 job의 특성상 한 번 실행하고 발생한 로그를 보존해야 job이기 때문

(다시 실행하면 로그는 날아갈 것)

실패하는 경우 다시 구동하고자 할 때는 "OnFailure" 

 

job spec 설정 

1)병렬 실행

1-1) completions : 3 

     job실행 > job 실행 > job 실행

1-2) parallelism : 3 

     동시에 3개의 pod 실행 

2) 자동 종료 

2-1) activeDeadLineSeconds: 30 

     job이 실행되고 30초 뒤에 종료 

2-2) ttlSecondsAfterFinished: 30

     job 이 모든 job이 일을 한 뒤에 30초 뒤에 종료 

 

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  ttlSecondsAfterFinished: 30  # 언급한 4개의 옵션은 이 위치에서 설정
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never 
  backoffLimit: 4

 

5. 크론잡(CronJob)

apiVersion: batch/v1
kind: CronJob
metadata:
  name: pi
spec:
  schedule: "* * * * *"
  successfulJobsHistoryLimit: 10 #10회까지 job 보존하고 싶을 때 이렇게 설정
  jobTemplate:
    spec:
      template:
         spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

크론 규칙을 통해 스케쥴을 설정해서, 시간마다 반복적으로 job을 실행할 수 있도록 설정

successfulJobsHistoryLimit의 default값은 3회,  3회 초과시 기존 실행된 잡을 삭제해서 3회를 유지함

 

6. 데몬셋(DaemonSet)

daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec: #Demonset에서는 Deployment와 다르게 replicas를 선언하지 않음. 
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # 이 톨러레이션(toleration)은 데몬셋이 컨트롤 플레인 노드에서 실행될 수 있도록 만든다.
      # 컨트롤 플레인 노드가 이 파드를 실행해서는 안 되는 경우, 이 톨러레이션을 제거한다.
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

Demonset에서는 Deployment와 다르게 replicas를 선언하지 않는다.

worker node당 1개씩으로 이미 설정되어있기 때문

node마다 하나씩 배포되는 형태

 

7. 스테이트풀셋(StatefulSet)

statefulset.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # .spec.template.metadata.labels 와 일치해야 한다
  serviceName: "nginx" #statefulSet의 필수 값 
  replicas: 3 # 기본값은 1
  minReadySeconds: 10 # 기본값은 0
  template:
    metadata:
      labels:
        app: nginx # .spec.selector.matchLabels 와 일치해야 한다
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

serviceName을 꼭 입력해야함 

상태를 가지고 독립적인 생태계를 꾸리는 스테이트풀셋(쿠버네티스 내에서 유일)

상태값을 유지하면서, 어떤 순서로 배포가 이루어진다고 미리 정해져있어서, 정확히 그 순서로 배포가 일어남.

순서를 가지고 배포하거나 고정된 이름이 필요한 애플리케이션에 적합하다. 

레플리카 수를 늘리면 순차적으로 배포되었다가, 레플리카 수를 줄이면 역순으로 하나 씩 삭제된다.