목차
Kubernetes Architecture 쿠버네티스 리소스
- 컨트롤러 오브젝트
- Replicaset
- Deployment
- Daemonset
- 로드밸런서 오브젝트
- 스토리지 오브젝트
(참고) App 업데이트 방법
쿠버네티스 리소스
컨트롤러 오브젝트
- ReplicaSet : (Node 고장 / Pod 삭제 등 발생 시) 파드 복제하여 개수 유지
- Deployment : 구 버전에서 신 버전으로 복제, 레플리카셋 관리(보통 pod를 일일이 관리하기보다는 deployment 를 서비스 단위로 관리)
실습
- Deployment 생성 시 Replica 숫자 지정, 파드를 지워도 ReplicaSet에 의해 다시 재생성
직접 실습을 통해 파드를 지워도 다시 재생성되는지 확인해봅시다.
kubectl create deployment deploy-test --image nginx --replicas=3
deploy-test라는 deployment를 nginx 기반의 이미지로 replicas 설정으로 pod개수 3개로 하여 생성합니다.
kubectl get deployments.apps
kubectl get deployments.apps deploy-test
kubectl get deployments.apps deploy-test -o wide
deployment가 생성되었는지 확인합니다.
kubectl get pod
pod도 확인해보면 3개가 생성되어있는 것을 확인할 수 있습니다.
kubectl get replicaset
현재의 replicaset을 가져옵니다.
kubectl delete pod [pod NAME]
pod을 delete를 해보고 확인해보면
kubectl get pod
새롭게 pod이 생성된 것을 확인할 수 있습니다.
그 이유는 replicaset이 pod 개수를 유지시켜야 하기 때문에 새롭게 생성한 것입니다.
실습을 통해 Replicaset이 pod를 유지하는 것을 직접 확인할 수 있었습니다.
DaemonSet
- 모든 노드에 동일한 파드를 실행시키고 싶은 경우 활용
- 리소스 모니터링, 로그 수집기 등에 유용. 클러스터에 노드가 추가/삭제되면 자동으로 파드도 생성/삭제됨
로드밸런서 오브젝트
- Service : POD는 임시적인(ephemeral) 오브젝트, TCP/UDP 로드밸런싱을 담당하는 추상적 개념
파드는 생성 시마다 IP가 변하기 때문에, 파드 외부와 통신 시 고정 IP를 갖는 'Service'를 통하여 서비스
kubectl create service 명령어도 서비스 생성이 가능하지만, kubectl expose 명령어를 활용하면
생성 ~ 연결까지 한 번에 가능
- 종류 : Cluster IP(기본값), Node Port, LoadBalancer, ExternalName으로 구분
- Ingress : HTTP 로드밸런서. Service로 라우팅 가능
- Service 종류 : Cluster IP(기본값), Node Port, LoadBalancer, ExternalName으로 구분
[ExternalName] 외부 서비스를 쿠버네티스 내부에서 호출 시 활용
스토리지 오브젝트
컨테이너 내의 디스크에 있는 파일은 임시적이지만 퍼시스턴트 볼륨은 지속적으로 존재한다.
PV, PVC
- Persistent Volume(PV) : 관리자가 프로비저닝 하거나 스토리지 클래스를 사용하여 동적으로 프로비저닝 한 클러스터의 스토리지
- Persistent Volume Claim(PVC) : 사용자의 스토리지에 대한 요청. 파드와 비슷.
- 파드 : 노드 리소스를 사용 / POD 명세서 내 특정 수준의 리소스(CPU 및 메모리)를 요청
- PVC : PV 리소스를 사용 / 클레임 명세서 내 특정 크기 및 접근 모드를 요청(예 : ReadWriteOnce, ReadOnlyMany, ReadWriteMany)
(참고) App 업데이트 방법
롤링 업데이트
- 장점 : Down Time 없음. 추가 인프라 투자비 별로 없음.
- 단점 : 신/구 버전 공존에 따른 개발 및 검증 사항 고려 필요. 신/구 버전이 같이 활용하는 인프라에서 문제 발생 가능
블루 그린 업데이트 방식 ( 레드 블랙 업데이트 / AB 배포 )
- 장점 : Down Time 없음. 복구가 빠름
- 단점 : 인프라 투자가 2배로 필요. 로드 밸런서 추가 필요
카나리 업데이트 방식
- 장점 : Downtime 없음. 아주 적은 사용자만 새 버전에 유입시키므로 영향도 최소화, 추가 인프라 투자 별료 없음
- 단점 : 신/구 버전 공존에 따른 개발 및 검증 사항 고려 필요. 업데이트 시간이 롤링 업데이트보다 더 걸림. 로드 밸런서 추가 필요
크리티컬 한 서비스는 카나리 업데이트 방식이 적합하다.
Reference
https://classlion.net/class/detail/21
도커/쿠버네티스 온라인 부트캠프 with 카카오엔터프라이즈
도커/쿠버네티스 온라인 부트캠프 with 카카오엔터프라이즈
www.classlion.net
'DevOps > Kubernetes' 카테고리의 다른 글
[Kubernetes] APIs and Access(2) (0) | 2021.10.26 |
---|---|
[Kubernetes] APIs and Access(1) (0) | 2021.10.25 |
[Kubernetes] Kubernetes Architecture(3)[쿠버네티스 리소스 : 워크로드 오브젝트] (0) | 2021.10.20 |
[Kubernetes] Kubernetes Architecture(2)[쿠버네티스 설치 및 환경 설정] (0) | 2021.10.19 |
[Kubernetes] Kubernetes Architecture(1) (0) | 2021.10.18 |