※ 실시간으로 pod monitoring

-  kubectl get pod -o wide --watch
-  watch kubectl get pod -o wide

 Job 

:  배치 처리에 적합한 Controller로서 Pod의 성공적인 완료를 보장

:  Job을 사용하여 Pod를 실행하면?

  • Pod의 작업이 정상적 종료 → 완료
  • Pod의 작업이 비정상적 종료다시 실행시켜 Application의 작업을 하도록 함

전제 : Kubernetes에서 Pod은 항상 Running

실습) Job
- wget http://down.cloudshell.kr/k8s/lab/job/job-exam1.yaml
- watch kubectl get pod -o wide
- kubectl apply -f job-exam1.yaml
60초 동안 sleep 프로세스 진행 중

60초 이내에 pod 종료(비정상적 종료)
- kubectl delete pod pod_name 이렇게 하면 다시 생성한다

새로운 Pod 재시작

60초 후에 Pod 보기(정상적 종료)
- kubectl get job

정상적 종료되었기에 Pod이 Completed가 됨

(application 실행이 종료되어도 Pod은 재시작하지 않음)


Job으로 만든 Pod 삭제 시 
-  kubectl delete job job_name

 

backoffLimit 옵션

-  backoffLimit: 10 이라면 10번까지 Pod/Container재시작한다(기본값6)


restartPolicy 옵션 (비정상적 종료일 때)

  • restartPolicy:Never = Pod를 재시작
  • restartPolicy:OnFailure = Pod를 재시작하지 않고 Container를 재시작 (Pod 재시작 시 IP가 바뀔 수 있기 때문)
실습 1) 명령이 잘못된 Pod를 실행하는 경우 (restartPolicy:OnFailure)
-  wget http://down.cloudshell.kr/k8s/lab/job/job-exam-error1.yaml
잘못된 명령어

-  kubectl apply -f job-exam-error1.yaml

▶ 이렇게 하면 6번까지 Pod이 아닌 Container가 재시작된다. 이렇게 하다가 해결되지 않으면 Pod만을 삭제한다.


실습 2) 명령이 잘못된 Pod를 실행하는 경우 (restartPolicy:Never)

-  wget http://down.cloudshell.kr/k8s/lab/job/job-exam-error2.yaml
-  kubectl apply -f job-exam-error2.yaml

 이렇게 하면 Container가 아닌 Pod이 재생성된다. (여러 개의 Pod이 생성) 이렇게 하다가 해결되지 않으면 Pod만을 삭제해 버린다.

 

 CronJob 

사용자가 원하는 시간에 Job 실행을 예약하는 것

:  Job의 기능을 포함 (즉, CronJob → Job → Pod)

단지, schedulejobTemplate만 추가된 것이다.

:  반복해서 실행하는 Job을 운영할 때 사용 (주기적인 Data Backup, Email 전송, Log 파일 및 불필요한 데이터 삭제)

 

CronJob 표기법: "분 시간 날짜 월 요일"

  • 분: 0~59
  • 시간: 0~23
  • 날짜: 1~31
  • 월: 1~12
  • 요일: 0~6 (일요일~토요일)
  • *는 전체를 의미
예시)
매월 1일 3시 정각에 실행하라: 0 3 1 * *
주말 새벽 3시 정각에 실행하라: 0 3 * * 0,6
5분마다 반복해서 실행하라: */5 * * * *

 

실습) CronJob
-  wget http://down.cloudshell.kr/k8s/lab/cronjob/cronjob-exam1.yaml   

yaml

-  kubectl apply -f cronjob-exam1.yaml

1분이 지나면 Job이 시작되어 pod이 실행되고, 10초 후에 완료된다. 이 과정을 계속 반복한다.

성공한 Job은 3개까지 남아있는 것이 Default 값. 4번째 Job이 성공하면 첫 번째 Job은 삭제된다.
(kubectl get cronjob -o yaml보면 successfulJobsHistoryLimit: 3으로 되어 있다)


계속 Job실행되므로 CronJob중지하여 JobPod삭제한다
-
kubectl delete cronjobs.batch --all

 

 

'Study > Cloud' 카테고리의 다른 글

Kubernetes - 인증과 권한  (0) 2022.07.25
Kubernetes - Pod Scheduling  (0) 2022.07.25
Kubernetes - Controller  (0) 2022.07.22
Kubernetes - Service  (0) 2022.07.22
Kubernetes - Pod  (0) 2022.07.21

Controller

: Pod를 다양한 방식으로 배포, 관리하는 기능을 수행

 

출처 https://azderica.github.io/00-kubernetes/

https://kubernetes.io/ko/docs/concepts/workloads/controllers/

 

워크로드 리소스

운영 수준의 컨테이너 오케스트레이션

kubernetes.io

 

 Replication Controller 

: 항상 Cluster 안에서 지정된 숫자만큼의 Pod가 동작되도록 한다

 

-  kubectl apply -f replicationcontroller.yaml
yaml
-  kubectl get rc,pod -o wide
-  kubectl delete pod nginx-g5wrg → 특정 pod 삭제 시 새로운 pod 생성됨

-  kubectl run myhttp --image=httpd --labels="app=nginx" --port 80
-  kubectl get rc,pod -o wide --show-labels
새로 만들어진 pod는 알아서 종료된다.
-  kubectl edit rc nginx → pod의 이미지, 갯수 등 다시 설정할 수 있다.


-  kubectl delete rc nginx →  Replication Controller 삭제 시 Pod도 삭제됨!!
-  kubectl delete rc nginx --cascade=orphan → Replication Controller만 삭제되고 Pod는 그대로 유지

 

 ReplicaSet 

: Replication Controller와 동일한 역할

차이점은 Replicaion Controller보다 더 많은 selector를 가진다는 점이다.

 

-  wget http://down.cloudshell.kr/k8s/lab/replicaset/replicaset-nginx.yaml
-  kubectl apply -f replicaset-nginx.yaml

-  kubectl delete -f replicaset-nginx.yaml --cascade=orphan → Pod는 그대로 남고 replicaset만 삭제됨

-  kubectl delete rs --all → 전부 삭제

 

 Deployment 

: Deployment는 ReplicaSet을 사용하여 Pod 개수를 조정함

: Deployment를 생성하면 자동으로 ReplicaSet과 Pod이 생성됨 (Deployment를 삭제하면 자동으로 전부 삭제됨)

: Pod의 Rolling Update 및 Rolling Back 을 위해 주로 사용

 

실습) Rolling Update
-  wget http://down.cloudshell.kr/k8s/lab/deployment/deployment-v1.yaml
-  kubectl apply -f deployment-v1.yaml --record (--record: 업데이트 과정을 history로 기록)
-  kubectl rollout history deployment app-deploy
deployment의 history를 볼 수 있다.

-  kubectl set image deploy app-deploy myweb-con1=nginx:1.15 --record
-  kubectl get pod  → pod가 하나씩 순서대로 Update 된다
-  kubectl describe pod (pod명)
이미지 업데이트 적용

-  kubectl set image deploy app-deploy myweb-con1=nginx:1.16 --record
-  kubectl set image deploy app-deploy myweb-con1=nginx:1.17 --record

-  kubectl rollout history deployment app-deploy
history 확인

-  kubectl rollout undo deploy app-deploy 
undo 결과

-  kubectl rollout undo deploy app-deploy --to-revision=2  → 특정 단계로 돌아간다

 
 Daemon Set 
 
:  Cluster 모든 Node에 Pod를 한 개씩만 배정
:  ReplicaSet과 비교했을 때  --replicas 옵션이 없다

-  wget http://down.cloudshell.kr/k8s/lab/daemonset/daemonset-nginx.yaml
-  kubectl apply -f daemonset-nginx.yaml
-  kubectl apply -f replicaset-nginx.yaml

ReplicaSet과는 다르게 DaemonSet은 한 노드에 하나의 pod만 배정된다.

 

 StatefulSet 

:  관계를 계속해서 유지하는 것

:  즉, 관계의 상태를 유지해야 하는 application을 관리할 때 사용

:  주로 Pod의 이름 순서와 고유성을 보장하는 데 사용

:  상태를 유지하는 항목 ▶ Pod 이름을 순서대로 명명(0~N), Pod의 Volume(PVC 이름), Network (Headless Service)

 

※ 주의 ※ StatefulSet 생성 시 yaml 파일에는 serviceName, replicas, podManagementPolicy, terminationGracePeriodSeconds이 반드시 포함되어야 한다

yaml 일부

-  kubectl apply -f statefulset.yaml

StatefulSet으로 Pod이 생성된 경우에는 Pod이 삭제되면 이전의 삭제된 Pod의 이름과 동일한 Pod이 생성된다.


실습) StatefulSet의 rollingUpdate.partition 수정하기
:  StatefulSet에 변경사항이 있을 때 rollingUpdate.partition에서 지정한 값보다 작은번호의 Pod은 변경되지 않고 크거나 같은 번호만 변경시킨다
:  서버 패치할 때 등의 경우에 사용한다

-  kubectl apply -f statefulset.yaml (## web-0, web-1, web-2가 실행되고 있음)
-  kubectl edit statefulset web
image를 nginx에서 nginx:1.14로 변경
partition 부분을 0에서 2로 변경

-  kubectl get statefulsets.apps

2보다 작은 0과 1은 계속 동작하고 2만 수정된다.

 

 Deployment, DaemonSet, StatefulSet의 공통점과 차이점 

ⓐ 공통점

  • Rolling update 및 Rollback 가능
  • 각각을 삭제하면 Pod도 동시에 삭제됨

ⓑ 차이점

  • Deployment
    - Pod이 어떤 Node에 생성될 지 예측 불가
  • DaemonSet
    - Node별로 동일한 Pod이 하나씩 생성
  • StatefulSet
    - serviceName 필요
    - Pod 이름 및 볼륨 유지
    - partition 값에 따라 업데이트 되지 않을 Pod을 지정할 수 있음

 

 

 

'Study > Cloud' 카테고리의 다른 글

Kubernetes - Pod Scheduling  (0) 2022.07.25
Kubernetes - Controller-2  (0) 2022.07.23
Kubernetes - Service  (0) 2022.07.22
Kubernetes - Pod  (0) 2022.07.21
Kubernetes - Namespace  (0) 2022.07.21

+ Recent posts