Kubernetes 7일차 Deployment(디플로이먼트), StatefulSet(스테이트풀셋)

7.14 강의 8장 디플로이먼트

8장 디플로이먼트

파드를 관리하는 것이 아닌 컨트롤러를 관리한다. 레플리카셋을 관리한다.

레플리카셋이 파드를 관리하는 형태

업데이트를 수행하는 리소스이다.

*디플로이먼트 전략

deployment.spec.strategy

1)RollingUpdate: 롤링방식으로 업데이트(앱2개가 로드밸런서를 통해 접속가능하면 하나 먼저 업데이트하고 다음 앱 업데이트 하는 방식, 순차적업데이트), 무중단 어플리케이션에서 사용함

디플로이먼트 롤링업데이트는 레플리카셋을 새로 하나 더 만들고 그 레플리카셋이 파드를 새로 생성해준다. 이전의 레플리카셋으로 돌아가는 것을 RollBack 이라하고, 이전의 레플리카셋은 scale을 유지하지않고 만약 초기 replicas 가 3이라면 2 1 0 이런식으로 scale 재조정한다.

rollingUpdate.maxUnavaiable: 파드의 수가 얼만큼 줄어들 수 있느냐, 1->파드 삭제 1개씩

rollingUpdate.maxSurge: 파드의 수가 얼만큼 더 늘어날 수 있느냐, 최대 파드의 수 2->

2)Recreate: 재생성, 기존 파드는 모두 삭제하고 새로운 파드 생성, downtime이 발생할 수 밖에 없다.

디플로이 관련 yaml 파일이다. strateht 부분에 롤링업데이트를 지정하였다.

 

확인을 위한 서비스도 생성

**롤아웃 : 디플로이먼트에서 모든 배포 및 롤링업데이트를 롤아웃이라고 한다.

kubectl rollout status deployment myapp-deploy #롤아웃 상태 확인

정상적으로 배포되었다면, successfully rolled out 이 뜬다

kubectl rollout histoty deployment myapp-deploy # 롤아웃 히스토리 확인

버전1 -> 버전2 로의 업데이트

kubectl set image deployment <디플로이먼트이름><컨테이너이름>=<새이미지>

kubectl set image deployment -f <디플로이먼트파일><컨테이너이름>=<새이미지>

kubectl set image deployment myapp-deploy myapp=ghcr.io/c1t1d0s7/go-myweb:v2.0

#버전2로 업데이트하는 것이다. --record 옵션을 사용하지 않았기 때문에 rollout histroy에 cause가 기록되지 않는다. 옵션을 사용하면 앞의 명령어를 change-cause에 등록해준다

똑같이 버전3로 업데이트 했다고 가정,

버전3 -> 버전2 로의 롤백

kubectl rollout undo deployment myapp-deploy --to-revision=2

# 숫자2가 버전2를 의미하는 것이 아니라 히스토리를 통해 확인한 업데이트 항목중에 두번째 항목으로의 롤백을 한다는 것이다. 실습에서는 두번째로 버전2 업데이트 하였기 때문에 2버전으로의 롤백이다.

*파일을 이용한 롤링업데이트 수행

 

kubectl apply -f <파일이름>

모두 진행하고 status, histroy 를 롤아웃 명령어를 통해 진행하고

레플리카셋 목록을 보면 이전의 레플리카셋이 모두 남아있다. 롤백시 다시 이전 레플리카셋을 그대로 사용하기 위함.

recreate, surge, unavailabel 값 조정하며 실습 다시해보기~

 

9장 스테이트풀셋

기존 컨트롤러의 문제점, 파드 템플릿을 통해 파드를 찍어낸다. 모든 파드는 같은 볼륨을 공유해야한다는 단점, 파드마다 고유한 상태를(볼륨을) 저장해낼 수 없어서 나온 것이

스테이트풀셋! 파드 배포, 파드 복제본 소유, 스케일링, 파드의 순서가 존재, 파드의 고유성(이름, 네트워크, 스토리지), 각 파드의 고유한 볼륨

파드마다 고유한 PVC 붙는다.

파드마다 각각 다른 스토리지를 사용해 각각 다른 상태를 유지하기 위해서는 스테이트풀셋 사용

*스테이트풀셋 관리

239~247 다시 해보기… rook-ceph 필요하긴하다

 

*데이터베이스 이중화

1 master , multi slave

마스터 쪽에만 읽기 쓰기 부여, slave에는 읽기만 부여, 마스터와 슬레이브의 스토리지르 복제해놓고 마스터에 장애가 발생하면 slave를 마스터로 승격한다.

만약 rs 나 deploy를 사용하여 MySQL 셋팅을 한다면, 같은 스토리지를 공유하는 두개 이상의 MySQL에 대해서 쓰기를 두개 다 하면

248~261 rook-ceph 설치하고 진행

 

워드프레스 고가용성

인그레스 노드포트서비스 워드프레스(디플로이먼트) 내부 로드밸런서(클러스터 아이피, 헤드리스 버시스) , mysql db(sts or 자신없으면 복제본 하나만)

 

https://17billion.github.io/kubernetes/2019/04/24/kubernetes_control_plane_working.html