-Deployment : ReplicaSet의 업그레이드 된 버전으로 롤링업데이트가 잘됨.
-
⇒롤링 업데이트( 기존버전을 새로운 버전으로 중단없이 업데이트 하는것 )
-
RS와 Deployment , 두가지 비교시 거의 똑같고 차이점은 kind 다름
deployment 설정
- vim deploy-nginx.yaml
- deployment를 이용하여 pod 생성 내용 작성
- kubectl create -f deploy-nginx.yaml
- 기존 기능은 RC, RS와 유사
deployment 롤링 업데이트
- kubectl edit deployments.apps deploy-nginx
- image를 1.14에서 1.15로 바꾸면 컨테이너가 순서대로 롤링 업데이트 된다
#deployment-exam1 실행
-파일의 버전을 1.15 로 수정을 하면? 새로 생성이 되고 기존것 하나 삭제가 되는지 ⇒ 업데이트됨
- ⇒ 순차적으로 하나씩 진행되는것 확인됨.
-업데이트 확인
- [root@master ~]# kubectl describe pod app-deploy-6f8cb5d6bf-mtln9
deployment를 이용해서 이미지 업데이트
- vim deployment-exam1.yaml
- deployment를 이용해서 pods를 생성하는 내용 저장
- kubectl set image deploy app-deploy web=nginx:1.15 --record
( 이미지를 업데이트 ( deployment ), 순차적으로 )- kubectl describe pods app-deploy-6f8cb5d6bf-c2tr9 | grep -i image
( 이미지 확인 )- kubectl rollout history deployment app-deploy
( 이전에 수행된 롤아웃에 대한 정보를 확인 , 10개까지 기록 )
( 롤 아웃은 소프트웨어나 애플리케이션의 새로운 버전을 시스템에 배포하는 과정 )
- [root@master ~]# kubectl rollout status deploy app-deploy ⇒ 업데이트 되는 과정
- [root@master ~]# kubectl set image deploy app-deploy web=nginx:1.18 --record
- #kubectl rollout pause deploy app-deploy [ resume / status ] 를 번갈아 해보면
업데이트가 일시정지 / 다시시작 되는 과정 확인
- #kubectl rollout pause deploy app-deploy [ resume / status ] 를 번갈아 해보면
rollout 명령어
- kubectl rollout status deployment app-deploy ( 업데이트 과정 상태 확인 )
- kubectl rollout pause deployment app-deploy ( 잠깐 멈춤 )
- kubectl rollout resume deployment app-deploy ( 다시 시작 )
[root@master ~]# kubectl rollout history deployment app-deploy ⇒ 기본 10개만 보여줌
-업데이트는 기본적으로 진행되는데 시간을 설정해서 정해진 시간안에 업데이트가 이루어 지지 않으면
중지 시켜버리는 기능도 있음 ( 시간기록은 초 단위로 : 600 )
-롤백은 undo
- [root@master ~]# kubectl rollout --help
⇒일반적은 롤백은 이전버전으로 해주는것.
⇒현재 버전은 nginx:1.19
- [root@master ~]# kubectl rollout undo deployment app-deploy ⇒ 이전버전으로 롤백이됨
deployment.apps/app-deploy rolled back
⇒ 버전 확인 해보면 1.18
⇒원하는 버전(1.16)으로 한번에 롤백 하기 ⇒ history에서 번호확인 하면 3번으로 확인됨.
- [root@master ~]# kubectl rollout undo deployment app-deploy --to-revision=3
버전확인 ⇒ 1.16으로 롤백된것 확인됨.
⇒ history를 보면 1.16 버전이 가장 최신 번호로 기록됨.
- [root@master ~]# kubectl rollout history deployment app-deploy
여기서 다시 일반적인 롤백을 하면 몇 버전으로 롤백이 될까? 현재 1.16 ⇒ 1.15 or 1.19
⇒모두 삭제
[root@master ~]# kubectl delete deployments.apps app-deploy
롤 백
- kubectl rollout undo ( 이전 버전으로 롤 백 )
- kubectl rollout undo deployment app-deploy
( 버전 확인, 이전 버전으로 롤 백 )
- kubectl rollout undo deployment app-deploy --to-revision=3
( "app-deploy" 디플로이먼트를 리비전 3으로 롤백하는 것 )- 롤 백은 히스토리 리비전을 기준으로 롤백 ( kubectl rollout history deployment app-deploy )
- kubectl delete deployments.apps app-deploy로 삭제
#deployment-exam2.yaml
-[root@master ~]# kubectl create -f deployment-exam2.yaml
- 업데이트시 전체개수의 25%씩 진행 ( ex :100개라면 25개씩 업데이트가 진행됨 )
mazUnavailable 이분은 위에서 설정한 5%의 업데이트가 끝나면 바로 진행하는것.
만약 아래 30% 으로 설정하면 일부가 겹치는 부분이 발생됨 - [root@master ~]# kubectl set image deploy deploy-nginx web=nginx:1.16 --record
- [root@master ~]# kubectl set image deploy deploy-nginx web=nginx:1.17 --record
- [root@master ~]# kubectl delete deployments.apps deploy-nginx
deployment rolling update
- vim deployment-exam2.yaml
- Deployment의 구성을 정의
( maxSurge와 maxUnavailable은 롤링 업데이트 중에 새로운 파드를
얼마나 많이 생성하거나 기존 파드를 얼마나 많이 제거할 수 있는지를 나타냄 )
( maxSurge는 롤링 업데이트 중에 허용되는 파드의 초과 생성 수 )
( maxUnavailable은 롤링 업데이트 중에 사용할 수 없는 파드의 최대 수 )
( revisionHistoryLimit은 유지할 이전 ReplicaSet의 개수 )
( progressDeadlineSeconds는 롤아웃의 진행이 얼마나 오랫동안 중지될 수 있는지를 나타냄 )
롤링 업데이트
- kubectl set image deploy deploy-nginx web=nginx:1.17 --record
- kubectl rollout history deployment deploy-nginx로 확인
-DaemonSet :
지금까지 했던 레플리카 처럼 개수를 지정하는게 아닌 노드마다 1대씩 보장해주는것.
- 전체 노드에서 한개가 실행되도록 해주는것.
-모니터링, 로그 수집, 에이전트 프로그램이 실행시 적용
daemonset 설정
- vim daemonset-exam.yaml
- daemonset을 정의하는 yaml 파일 작성 ( 각 노드에 정확히 하나의 파드가 실행 )
( selector.matchLabels는 DaemonSet이 파드를 배치할 노드를 선택하는 기준 )
- kubectl create -f daemonset-exam.yaml
- kubectl get daemonsets.apps daemonset-nginx ( 확인 )
- RC, RS, deployment와 마찬가지로 갯수 보장
- deployment와 마찬가지로 롤링 업데이트, 롤 백 가능
*StatefulSet : 현재 상태를 유지(보존해주는것)
⇒ 현재 상태란 파드의 이름을 뜻함
- ⇒rc-nginx.yaml 파일 확인 및 실행
- [root@master ~]# cat rc-nginx.yaml
replicas: 3 - ⇒하나를 삭제하면 새로 생성됨 ( 이름이 다르게 생성됨 )
- [root@master ~]# cat rc-nginx.yaml
- [root@master ~]# kubectl create -f statefulset-exam.yaml
- ⇒3개 새성됨
- ⇒하나를 삭제 해보면 같은 이름으로 생성됨.
[root@master ~]# kubectl delete pod sf-nginx-1
statefullset 설정
- vim statefullset-exam.yaml
- statefullset 정의하는 yaml 파일 작성
( 각각의 파드에 고유한 식별자가 부여되고, 파드가 순차적으로 생성되거나
삭제될 때에도 일관된 식별자를 유지할 수 있는 리소스 관리 방법 )
( OrderedReady는 순차적( 이전 파드 생성 후에 파드 생성 )으로 파드를 관리하고,
Parallel은 병렬적( 이전 파드가 준비가 되지 않아도 파드 생성 )으로 파드를 관리 )
- kubectl create -f statefulset-exam.yaml
- sf-nginx-0를 삭제하면 같은 이름의 sf-nginx-0를 생성
( RC나 RS 등 은 다른 이름의 pods 생성 )
⇒ scale 로 개수를 줄이거나 늘리면?
- [root@master ~]# kubectl scale statefulset sf-nginx --replicas=2
- 0 1 2 중에서 2번이 삭제됨
- [root@master ~]# kubectl scale statefulset sf-nginx --replicas=4
- 0 1 2 3 으로 늘어남
scale로 개수를 줄이거나 늘리기
- kubectl scale statefulset sf-nginx --replicas 2 ( scale 개수 조정 )
- 순차적으로 삭제
- kubectl scale statefulset sf-nginx --replicas 4
- 순차적으로 생성
⇒ 1.15로 롤링 업데이트(edit / scale) / 롤백(undo) 을 하면? 잘됨.
- [root@master ~]# kubectl edit statefulset.apps sf-nginx
- [root@master ~]# kubectl describe pod sf-nginx-0
- [root@master ~]# kubectl rollout undo statefulset.apps sf-nginx
- [root@master ~]# kubectl describe pod sf-nginx-0
롤링 업데이트 및 롤 백
- kubectl set image statefulset sf-nginx nginx-container=nginx:1.16 --record
- kubectl rollout undo statefulset sf-nginx
- kubectl rollout history statefulset sf-nginx 로 확인
*job 컨트롤러 : 파드가 계속 실행되도록 보장
파일 구조
job 설정
- vim job.yaml
- job을 작성하는 yaml 파일 작성 ( Job은 일회성 작업을 실행하는데 사용 )
( spec.activeDeadlineSeconds는 Job이 활성화된 시간(초)을 나타냄,
이 시간을 초과하면 Job이 중단 )
( spec.template.spec.containers는 Job에서 실행될 컨테이너를 정의 )
( spec.template.spec.restartPolicy는 파드의 재시작 정책을 정의 )
- kubectl create -f job.yaml
- 활성화 시간이 지난 후 파드 삭제
job-yaml.txt ⇒ 예제 파일
#test.yaml ⇒ 정상 실행
job을 이용한 컨트롤러 예제 ( helloworld )
- vim job-exam.yaml
- job을 이용하여 yaml 파일 작성
( busybox 이미지를 사용하여 "echo helloworld" 명령을 실행하는 단순한 작업을 정의 )
( kubectl logs pods hello-world-lnwk5로 확인 : hello world)
[root@master ~]# err-test.yaml
- ⇒ 에러 발생시키는 파일 실행시키면 err 발생으로 6번정도 재시도후 종료
- [root@master ~]# kubectl get job ⇒ job 실행 성공/실패 확인
[root@master ~]# kubectl get pod ⇒ job 실행 성공/실패 확인
[root@master ~]# kubectl logs hello-world-sd4zc ⇒ job 실행 성공 확인
helloworld
- [root@master ~]# kubectl get job ⇒ job 실행 성공/실패 확인
job을 이용한 컨트롤러 예제 ( error )
- job을 이용하여 yaml 파일 작성
( "ls unvalid path" 명령은 잘못된 경로를 사용하고 있어서 오류를 발생 )- kubectl get job로 확인
- [root@master ~]# kubectl delete job hello-world
#backoff-test.yaml ⇒ 에러발생시 0으로 설정해서 실행시 처음한번 에러발생하면 더이상 재시작 안함.
- apiVersion: batch/v1
kind: Job
—----------------
backoffLimit: 0
job을 이용한 컨트롤러 예제 ( backoffLimit )
- job을 이용하여 yaml 파일 작성
( 위의 에러 테스트를 backoffLimit으로 제한 )
( backoffLimit을 0으로 설정하고 있습니다.
backoffLimit은 재시도 횟수를 제한하는데 사용되며,
이 경우 0으로 설정되어 있어 재시도를 하지 않음을 의미 )
#restart-test.yaml
- command: ["exit 1"] ⇒ 1비정상으로 설정해서 계속 재시작 하도록 / 0은 정상종료
restartPolicy: OnFailure
job을 이용한 컨트롤러 예제 ( restart )
- job을 이용하여 yaml 파일 작성
( busybox 이미지를 사용하여 "exit 1" 명령( 비정상 종료 )을 실행하는 작업을 정의 )
( restartPolicy가 "OnFailure"로 설정되어 있어 실패한 경우에만 재시작을 수행 )
#loop-test.yaml ⇒ 무한루프 발생 후 20초 후에 종료 되도록 설정
- spec:
activeDeadlineSeconds: 20
job을 이용한 컨트롤러 예제 ( loop )
- job을 이용하여 yaml 파일 작성
( 3초마다 "hello"를 출력하는 무한 루프를 실행하는 작업을 정의 )
( activeDeadlineSeconds가 20으로 설정되어 있어서, 해당 작업은 20초 후에는 중지 )
- kubectl logs pods infinity-print-activedeadlineseconds-gxvn4 로 확인
*Cronjob : 지정한 시간에 job이 실행되도록.
#cronjob.yaml 파일 생성/실행
version 수정 batch/v1 으로 수정 후 실행 하고 1분마다 새로 실행되는거 확인
- [root@master ~]# kubectl get cronjobs.batch -o yaml
⇒모두 삭제 후 schedule 예약 부분을 현재 시간 기준 10분 후로 수정하고 실행 되는지 확인
- [root@master ~]# kubectl delete cronjobs.batch cronjob-exam
cron job 설정
- vim cronjob.yaml
- cronjob을 작성하는 yaml 파일 작성( 주기적으로 스케줄된 작업을 실행하는데 사용 )
( CronJob은 "* * * * *"으로 설정된 스케줄을 가지고 있어서
매 분마다 작업을 실행하도록 예약 )
( 또한, startingDeadlineSeconds는 500으로 설정되어 있어서
작업이 시작되기까지의 최대 시간을 정의 )
( concurrencyPolicy는 "Forbid"로 설정되어 있으며,
이는 작업이 동시에 실행되는 것을 금지하는 정책 )
- kubectl logs pods/cronjob-exam-28588694-xqt8f로 확인
- kubectl get cronjobs.batch cronjob-exam 로 확인
- crontab은 timedatectl로 확인하여 universal time 으로 설정
*컨트롤러 정리
- Replication controller : 파드의 개수를 책임지고 보장
- ReplicaSet : 다양한 Lable을 지원 [ 버전등 ..]
- Deployment : 롤백 / 롤링업데이트 지원
- DaemonSet : 노드마다 하나씩 파드 지원
- StatefulSet : 파드의 이름을 보장
- job/CronTab : 스케줄링을 통한 파드 실행.
