[Kubernetes] Kubernetes Architecture(4)[쿠버네티스 리소스 : 컨트롤러 오브젝트, 로드밸런서 오브젝트, 스토리지 오브젝트]

목차

Kubernetes Architecture 쿠버네티스 리소스

- 컨트롤러 오브젝트

  - Replicaset

  - Deployment

  - Daemonset

- 로드밸런서 오브젝트

- 스토리지 오브젝트

 

(참고) App 업데이트 방법

 

---

쿠버네티스 리소스

컨트롤러 오브젝트

- ReplicaSet : (Node 고장 / Pod 삭제 등 발생 시) 파드 복제하여 개수 유지

- Deployment : 구 버전에서 신 버전으로 복제, 레플리카셋 관리(보통 pod를 일일이 관리하기보다는 deployment 를 서비스 단위로 관리)

 

그림 출처 : https://www.ianlewis.org/en/bluegreen-deployments-kubernetes

실습

- 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

- 모든 노드에 동일한 파드를 실행시키고 싶은 경우 활용

- 리소스 모니터링, 로그 수집기 등에 유용. 클러스터에 노드가 추가/삭제되면 자동으로 파드도 생성/삭제됨

 

그림 출처 : Kubernetes in Action

 

---

로드밸런서 오브젝트

- Service : POD는 임시적인(ephemeral) 오브젝트, TCP/UDP 로드밸런싱을 담당하는 추상적 개념

              파드는 생성 시마다 IP가 변하기 때문에, 파드 외부와 통신 시 고정 IP를 갖는 'Service'를 통하여 서비스

              kubectl create service 명령어도 서비스 생성이 가능하지만, kubectl expose 명령어를 활용하면

              생성 ~ 연결까지 한 번에 가능

              - 종류 : Cluster IP(기본값), Node Port, LoadBalancer, ExternalName으로 구분

- Ingress : HTTP 로드밸런서. Service로 라우팅 가능

 

그림 출처 : Medium, Sandeep Dinesh

 

- Service 종류 : Cluster IP(기본값), Node Port, LoadBalancer, ExternalName으로 구분

 

그림 출처 : Medium, Sandeep Dinesh

[ExternalName] 외부 서비스를 쿠버네티스 내부에서 호출 시 활용

 

---

스토리지 오브젝트

컨테이너 내의 디스크에 있는 파일은 임시적이지만 퍼시스턴트 볼륨은 지속적으로 존재한다.

 

 

 

PV, PVC

- Persistent Volume(PV) : 관리자가 프로비저닝 하거나 스토리지 클래스를 사용하여 동적으로 프로비저닝 한 클러스터의 스토리지

- Persistent Volume Claim(PVC) : 사용자의 스토리지에 대한 요청. 파드와 비슷.

  - 파드 : 노드 리소스를 사용 / POD 명세서 내 특정 수준의 리소스(CPU 및 메모리)를 요청

  - PVC : PV 리소스를 사용 / 클레임 명세서 내 특정 크기 및 접근 모드를 요청(예 : ReadWriteOnce, ReadOnlyMany, ReadWriteMany)

 

그림 출처 : https://www.alibabacloud.com/blog/kubernetes-persistent-storage-process_596505

 

 

 

---

(참고) App 업데이트 방법

롤링 업데이트

- 장점 : Down Time 없음. 추가 인프라 투자비 별로 없음.

- 단점 : 신/구 버전 공존에 따른 개발 및 검증 사항 고려 필요. 신/구 버전이 같이 활용하는 인프라에서 문제 발생 가능

 

그림 출처 : dev.to의 Jason Skowronski

 

 

 

블루 그린 업데이트 방식 ( 레드 블랙 업데이트 / AB 배포 )

- 장점 : Down Time 없음. 복구가 빠름

- 단점 : 인프라 투자가 2배로 필요. 로드 밸런서 추가 필요

 

그림 출처 : dev.to의 Jason Skowronski

 

카나리 업데이트 방식

- 장점 : Downtime 없음. 아주 적은 사용자만 새 버전에 유입시키므로 영향도 최소화, 추가 인프라 투자 별료 없음

- 단점 : 신/구 버전 공존에 따른 개발 및 검증 사항 고려 필요. 업데이트 시간이 롤링 업데이트보다 더 걸림. 로드 밸런서 추가 필요

 

그림 출처 : dev.to의 Jason Skowronski

 

크리티컬 한 서비스는 카나리 업데이트 방식이 적합하다.

 

---

Reference

https://classlion.net/class/detail/21

도커/쿠버네티스 온라인 부트캠프 with 카카오엔터프라이즈

 

---