Deployment
- ReplicaSet에서 발전된 형태의 Controller
Deployment 배포 전략
- RollingUpdate (기본적으로 사용하는 전략)
- 서비스 중단 없이 신규 버전의 애플리케이션으로 업데이트할 수 있는 배포 전략
- 업데이트 중에는 구버전의 애플리케이션과 신버전의 애플리케이션이 공존함
- ReCreate
- 기존의 애플리케이션을 모두 지운 후 새로운 애플리케이션을 배포하는 배포 전략
- 애플리케이션 업데이트 과정에서 서비스 중단 시간(다운 타임)이 수반되는 배포 전략
-> 그럼 이거 안좋은거 아냐? 왜 써?
어떤 사용자는 구버전으로 접속하고 어떤 사용자는 신버전으로 접속하는 상황을 방지할 수 있다.
maxUnavailable : RollingUpdate 과정에서 사용할 수 없는 최대 파드 갯수(기본값 : 25%)
maxSurge: RollingUpdate 과정에서 생성할 수 있는 최대 파드 갯수(기본값 : 25%)
minReadySeconds : 새로운 파드의 컨테이너가 준비되기까지 대기할 시간(기본값 : 0초)
--
spec:
strategy:
type: RollingUpdate | Recreate
rollingupdate:
maxUnavailable: 정수 | 비율 (정수나 percent 모두 가능)
maxSurge:
--
-----
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
minReadySeconds: 20 (strategy와 동등한 들여쓰기)
-----
kubectl create -f deploy-myapp-v1.yaml --record
Deployment 배포 및 롤링 업데이트(rollout) 상태 확인
kubectl rollout status deployment DEPLOYMENT_NAME (실시간으로 rollout되는 status가 보임)
Deployment 배포 이력 확인
kubectl rollout history deployment DEPLOYMENT_NAME
배포 이미지 지정하여 업데이트
kubectl set image deployment DEPLOYMENT_NAME CONTAINER_NAME=IMAGE_REPO:TAG
이번엔 다른거 해보자
annotation 추가하고 readinessProbe 추가하고, 컨테이너 이미지도 v3으로 버전 업해줄거임
필수 참고)
이미 manifest 파일을 통해 deploy가 작동을 하구 있자나.
manifest에 의해 이미 생성된 오브젝트에 대해서 수정하고 싶을 때는, kubectl apply -f를 사용해야 한다.
kubectl create -f는 작동 안함.
개꿀팁)
CHANGE-CAUSE에 명령어만 오는 줄 알았는데, 주석을 남길 수도 있다.
여기 보면, replicaset이 넘무 많아. 왜 그런거야? 항상 궁금했어!!!!
deployment는 replicaset을 여러 개 관리하잖아.
근데 rolling update를 하면, 구버전의 replicaset에서 신버전의 replicaset으로 이동한단말야?
그리고 구버전의 replicaset에는 pod이 안남아있게돼.
그래서 replicaset이 여러 개 남아 있는거야.
질문)
그럼 남아있는 replicaset을 지우면 rollback이 안되는건가요?
결론 : 빈 껍데기만 있는 replicaset이라도 지우지 않는 것이 좋다.
<여기까지 버전 업데이트, 롤백 등 배포와 관련된 실습을 해봤다.>
DaemonSet (주로 로그 수집 파드들을 노드에 띄워주기 위해서 사용)
- 기본적으로 Control Plane을 제외한 Worker Nodes에 파드가 노드당 1개씩 실행될 수 있도록 관리하는 Controller
(deployment, rs 등등은 기본적으로 쿠버네티스 스케줄러가 부하 분산을 고려해서 pod들이 node에 분산시킴)
kubectl edit 실행중인 뭔가를 변경할 때!
kubectl edit daemonsets fluentd-elasticsearch -n kube-system
kubectl edit daemonsets fluentd-elasticsearch -n kube-system
이거 치면
수정한다음에 kubectl apply -f daemonset.yaml 해줘야됨
아냐 에러떴어. 왜?????????????
kubectl edit을 하든 kubectl apply -f를 하든 둘 중 하나만 해야 되는데, 둘 다 해서 그래.
kubectl edit에서는 제대로 고쳐놨는데 yaml파일은 안고쳐놨단말야.
근데 계속 마지막에 apply를 하니까 제대로 로드가 안되지.
(테스트 할거면, pod 지웠을 때 하나 다시 올라오는지 확인하면 대)
daemonset을 manifest 파일로 지우려면
kubectl delete -f daemonset.yaml
질문)
실습한건 일반 노드들에만 적용되는데 control plane에도 적용하려면 어떻게 해야하나요?
-> 일반적으로 ControlPlane에는 애플리케이션이 포함된 pod는 띄우지 않는다.
관리하는 역할만 하는거야. (안되는 이유는 taint가 걸려있어서 그럼. tolerance 걸면 띄울 수는 있는데, 권장하지 않음.)
Job
- 한번 실행 후 종료해야하는 성격의 작업을 실행할때 사용하는 Controller
- 일정 갯수의 파드를 정상 실행하고 정상 종료하는 것을 보장함
해당 pod을 describe 해보니깐
spec.completions : 정상적으로 종료되어야 하는 파드 갯수
spec:parallelism: 병렬성을 지정하는 값으로 동시에 실행되는 파드의 갯수
restartPolicy : 재시작 정책을 의미하며 Never 인 경우 파드가 항상 정상 종료됨을 의미하며, OnFailure는 컨테이너가 비정상 종료되거나 실행이 정상종료되지 않은 경우 컨테이너를 재시작 할 수 있도록 하는 필드
CronJob
- 주기적으로 실행해야하는 Job을 제어할 수 있는 Controller
busybox는 머냐하면, 리눅스에서 시스템을 관리하기 위한 최소한의 도구들이 들어있는거임.
그 busybox를 이미지 형태로 구현해놓은거임.
이미 종료됨 ㅋ
job의 concurrency를 관리하는 cronjob을 설정해보자.
지금 concurrencyPolicy를 Forbid로 설정해놨잖아.
그러면 job을 동시에 수행하지 않게 되는거야.
즉, 먼저 수행한 job이 정상적으로 끝나야만 다음 job을 수행하는거지.
그런데 concurrencyPolicy를 allow로 설정하면, job을 동시에 수행하게 돼.
Replace로 하면, 기존의 container가 사라지면서 새로운 container로 대체됨.
Statefulset
세션
그런데 만약에 로그인 세션의 경우에는?
-> 강사님이 예시를 잘못 드신듯? 차라리 statefulset을 안쓰고 volume을 하나로 쓰면 session 공유가 될 것 같은데?
'System Engineering > Kubernetes' 카테고리의 다른 글
| kubernetes 7/17 (0) | 2022.04.01 |
|---|---|
| 쿠버네티스 잘 정리된 블로그 (subicura) (0) | 2022.03.31 |
| github에 branch 만들고 push하기 (0) | 2022.03.29 |
| 깃헙 하위 branch 생성 (0) | 2022.03.29 |
| kubernetes 5/17 (0) | 2022.03.26 |
최근댓글