일단 요 디플로이먼트를 하나 만들어두자구.
20220308 과제1_이호재.docx
0.39MB
아직 만들어지는 도중임. 빨리 찍었음 ㅋ


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

--record하면 change-cause 여기에 기록이 됨.


배포 이미지 지정하여 업데이트
kubectl set image deployment DEPLOYMENT_NAME CONTAINER_NAME=IMAGE_REPO:TAG

이렇게 이미지 지정하면 자동으로 rollout됨. (만약 pause 하면 이미지 지정해도 업뎃이 안되는거야)
이렇게 revision의 change-cause에 내용이 기록됨.

 

이번엔 다른거 해보자

annotation 추가하고 readinessProbe 추가하고, 컨테이너 이미지도 v3으로 버전 업해줄거임

 

필수 참고)

이미 manifest 파일을 통해 deploy가 작동을 하구 있자나.

manifest에 의해 이미 생성된 오브젝트에 대해서 수정하고 싶을 때는, kubectl apply -f를 사용해야 한다.
kubectl create -f는 작동 안함.

 

작동하기는 하는데 warning이 뜨네. 처음부터 apply로 만들라고 권고하는데?

개꿀팁)

CHANGE-CAUSE에 명령어만 오는 줄 알았는데, 주석을 남길 수도 있다.

 

여기 보면, replicaset이 넘무 많아. 왜 그런거야? 항상 궁금했어!!!!

deployment는 replicaset을 여러 개 관리하잖아.

근데 rolling update를 하면, 구버전의 replicaset에서 신버전의 replicaset으로 이동한단말야?

그리고 구버전의 replicaset에는 pod이 안남아있게돼.

그래서 replicaset이 여러 개 남아 있는거야.

 

질문)

그럼 남아있는 replicaset을 지우면 rollback이 안되는건가요?

안쓰고 있는 replicaset을 모두 지워버렸어.
그러니까 revision도 사라진다!!! rollback을 못하는거야!!!!!!!!
롤백이 불가능해졌음

결론 : 빈 껍데기만 있는 replicaset이라도 지우지 않는 것이 좋다.

 

<여기까지 버전 업데이트, 롤백 등 배포와 관련된 실습을 해봤다.>

 


DaemonSet (주로 로그 수집 파드들을 노드에 띄워주기 위해서 사용)
 - 기본적으로 Control Plane을 제외한 Worker Nodes에 파드가 노드당 1개씩 실행될 수 있도록 관리하는 Controller
(deployment, rs 등등은 기본적으로 쿠버네티스 스케줄러가 부하 분산을 고려해서 pod들이 node에 분산시킴)

이 컨트롤러는 로그 파일을 위한 pod(컨테이너)를 관리하잖아. 그러면 로그 파일이 메모리나 cpu 많이 잡아먹을 수도 있는데, 그걸 방지하기 위해서 제한을 걸어두는거야.

 

kubectl edit 실행중인 뭔가를 변경할 때!

kubectl edit daemonsets fluentd-elasticsearch -n kube-system

실행중인 이 daemonset Environment의 testenv의 value를 바꿔보자.

 

kubectl edit daemonsets fluentd-elasticsearch -n kube-system

이거 치면

이렇게 vim 에디터가 켜지면서 파일 수정할 수 있게 들어가져.
변경하고 저장하면
변경된 값이 저장된다.
아 이거 OnDelete임. 오타!!!!
아 이것도 오타였음 이렇게 해야됨
오타나니까 ImagePullBackOff 에러 뜸;; kubectl get pods -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 해보니깐

 

Ready가 False야. 이미 실행이 끝났다는거지.


spec.completions : 정상적으로 종료되어야 하는 파드 갯수
spec:parallelism: 병렬성을 지정하는 값으로 동시에 실행되는 파드의 갯수


restartPolicy : 재시작 정책을 의미하며 Never 인 경우 파드가 항상 정상 종료됨을 의미하며, OnFailure는 컨테이너가 비정상 종료되거나 실행이 정상종료되지 않은 경우 컨테이너를 재시작 할 수 있도록 하는 필드

 

 


CronJob
 - 주기적으로 실행해야하는 Job을 제어할 수 있는 Controller

busybox는 머냐하면, 리눅스에서 시스템을 관리하기 위한 최소한의 도구들이 들어있는거임.

그 busybox를 이미지 형태로 구현해놓은거임.

이미 종료됨 ㅋ

 

한번 들어가서 로그를 확인해보고 싶었는데, 이미 끝나서 접근이 안되나봐? 아냐 말이 안돼. job이 됐으면 cronjob도 되어야지. 왜 안됨... ㅡㅡ

 

job의 concurrency를 관리하는 cronjob을 설정해보자.

지금 concurrencyPolicy를 Forbid로 설정해놨잖아.

그러면 job을 동시에 수행하지 않게 되는거야.

즉, 먼저 수행한 job이 정상적으로 끝나야만 다음 job을 수행하는거지.

그런데 concurrencyPolicy를 allow로 설정하면, job을 동시에 수행하게 돼.

첫번째 job이 다 안끝났는데도, 두 번째 job이 또 수행되고 있지!
1분마다 job이 하나씩 계속 수행됨 ㅋㅋ

Replace로 하면, 기존의 container가 사라지면서 새로운 container로 대체됨.

 

 

Statefulset

 

세션

단순한 파일 저장소의 경우에는 state랑 상관이 없쥐

 

statefulset의 경우, 개별적 pod마다 각각 volume을 가짐. 각 애플리케이션의 상태를 저장할 필요가 있을 때 사용.

 

 

 

 

그런데 만약에 로그인 세션의 경우에는?

A 서버에서 session을 맺어도 B서버로 로드밸런싱 되는 순간 session 정보가 안맞아서 새로 login 해야됨. 서버가 바뀔 때마다 login이 풀리게 된다.

-> 강사님이 예시를 잘못 드신듯? 차라리 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
  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 카카오스토리 공유하기