쿠버네티스 Part 1 - Pod, Deployment, Service
- 1. 쿠버네티스 Part 1 DEEP DIVE 클라우드 네이티브 엔지니어링
- 2. 목차 • 컨테이너 오케스트레이션 • 로컬 클러스터 구성 • 기본적인 서비스 구성 • 파드/디플로이먼트/서비스/인그레스/컨피그맵/시크릿/스테이트풀셋 • 쿠버네티스의 작동 원리 • 파드 스케줄링 • 애플리케이션의 생명 주기와 배포 전략 (계속됨)
- 3. 목차 (이어서) • CSI와 볼륨 • CNI와 네트워크 • RBAC • AWS EKS • GitOps • 리소스 관리와 수평 확장 • CRDs
- 4. 쿠버네티스: 컨테이너 오케스트레이션 도구 • 오케스트레이션 (plan and organize) 도구 • 컨테이너의 배포, 확장 및 관리를 자동화하기 위한 솔루션 • 수천 수만개의 컨테이너 • 구글의 프로젝트로부터 시작 • 클라우드 사업자에게 종속적이지 않음
- 5. 왜 쿠버네티스가 등장했는가? 모놀리틱 애플리케이션에서 마이크로서비스 아키텍처로 전환 source: https://blog.coderco.io/p/monoliths-vs-microservices-a-guide 더 많은 컨테이너를 필요로 하게 됨
- 6. 컨테이너 오케스트레이션: 배포, 확장, 관리 • 선언적 형태의(명세화된) 컨테이너 배포 및 확장성 • 배포 및 스케일링을 자동화할 수 있음 • 많은 요청에 따른 스케일 아웃 자동화 • 고가용성 • 클러스터 내 인스턴스(노드)에 자동으로 스케줄링 • 자원 최적화 • 컨테이너 애플리케이션의 필요 자원과 한계를 지정할 수 있음 • 네임스페이스 별 관리 • 용이한 재난 복구(Disaster recovery)
- 7. 확장성
- 9. 재난 복구 (DR) source: https://www.starwindsoftware.com/blog/what-is-disaster-recovery/
- 10. 컨테이너 오케스트레이션: 멀티 클라우드 지원 • 여러 클라우드 플랫폼에서 실행 가능 • Amazon Web Services: EKS • Microsoft Azure: AKS • Google Cloud Platform: GKE • 온프레미스 운영 및 하이브리드 구성 가능
- 11. 왜 쿠버네티스가 등장했는가? • 모놀리틱 애플리케이션에서 마이크로서비스 아키텍처로 전환 • 애플리케이션이 작동하기 위한 일관된 환경을 제공해야 할 필요성 • 지속적 배포에 대한 필요성
- 12. 선언적 형태의 배포/운영 • 무엇을 배포할 것인가 • 파드 (Pod) • 어떻게 노출할 것인가 • 서비스 (Service) • 어떻게 배포할 것인가 • 디플로이먼트 (Deployment) Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet
- 13. 파드 • 쿠버네티스에서 배포할 수 있는 가장 작은 단위 • 하나 이상의 컨테이너를 포함하고 있음 • 보통 하나의 파드에 한 개의 애플리케이션 Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet
- 14. • 쿠버네티스에서 파드를 네트워크 상에 노출시키는 방법 • 클러스터에 존재하는 IP주소 Cluster Node 서비스 ClusterIP Service 클러스터 내에서 IP를 이용해 접속 (클러스터 내부) 노드의 포트번호를 통해 접속 (클러스터 외부) NodePort Service Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet
- 15. 디플로이먼트 • 파드 배포에 대한 원하는 상태(desired state)를 선언 Cluster Node Node my-app Pod my-app Pod 예) my-app Pod는 해당 복제본이 두 개 있어야 하여, 파드 업데이트시 순차적으로 교체되어야 한다 my-app Deployment Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet
- 16. 쿠버네티스 아키텍처: 컨테이너는 어떻게 실행되는가? • 쿠버네티스 클러스터는 다음과 같이 구성되어 있음 • 컨트롤 플레인 (Control Plane) • 클러스터 전반의 제어를 담당하는 노드 • 워커 노드 (Worker Nodes) • 하나 이상의 워커 노드가 존재 • 실질적으로 컨테이너가 실행되는 노드 노드 (Node): 베어메탈 혹은 VM
- 18. 쿠버네티스 설치 • 연습 및 개발용 (컨트롤 플레인과 워커 노드가 동일) • minikube • Rancher Desktop • Orbstack • k3s • 가장 좋은 방법은 VM을 3개 이상 만들고, 하나는 컨트롤 플레인, 나머지는 워커 노드로 구성 • 실제 운영시 • 온프레미스 • kubeadm (CKA 시험에서 요구) • 각 클라우드 사업자에서 제공하는 서비스 사용
- 19. 쿠버네티스 설정 • kubectl 명령어 사용 • YAML 파일을 작성하고, kubectl apply 명령 활용 $ kubectl run nginx --image=nginx $ kubectl apply –f <파일이름>.yaml
- 20. 파드 및 서비스 실습 • kubectl run nginx --image=nginx • kubectl port-forward nginx 8080:80 • kubectl expose pod nginx --port=80 --target-port=80
- 21. 쿠버네티스 작동 원리: Pod가 생성될 때 무슨 일이 벌어지는가?
- 22. 쿠버네티스 작동 원리: 컨트롤 플레인 구성 요소 • API Server • k8s의 엔트리포인트 • Controller Manager • 클러스터에서 무슨 일이 벌어지고 있는지 관찰 • Deployment, DaemonSet 등을 관리 • Scheduler • Pod를 어디에 배치할 것인지 결정 • 기본적으로는 노드 자원의 가용성을 고려 • etcd • key-value 저장소 • k8s에서 사용하는 메타데이터를 저장 • Cloud Controller Manager • 클라우드 제공자와 관련한 일
- 23. 쿠버네티스 작동 원리: 워커 노드 구성 요소 • Kubelet • 컨트롤 플레인과 통신하는 에이전트 • kube-proxy • k8s에서 트래픽 규칙을 통해 서비스를 사용할 수 있게 함 • CRI (컨테이너 런타임 인터페이스) • containerd와 같은 컨테이너 실행 도구
- 24. 쿠버네티스 작동 원리: Pod가 생성될 때 무슨 일이 벌어지는가? $ kubectl run nginx --image=nginx 1 2 4 5 etcd api-server scheduler kubelet 6 1. kubectl을 통해 api-server에 Pod 생성 요청 2. api-server는 요청 검증 (YAML이 올바른가, 권한이 있는가 등) 3. Pod 정보를 etcd에 기록 4. Pod 생성 요청을 받은 스케줄러는 어느 노드에 배치하는 것이 적합한지 판단 • etcd에 kubelet을 통해 보고받은 노드 정보가 기록되어 있음 5. 노드가 선택되면, 해당 노드의 kubelet은 Pod 생성 요청을 수행함 6. kubelet은 컨테이너 런타임을 실행 7. 이후 Pod는 IP를 할당받고, Pod 정보는 꾸준히 kubelet 및 api-server를 통해 etcd에 기록 3
- 25. API Server • HTTPS 엔드포인트 제공 (6443번 포트) • kubectl 명령어로 접근 가능
- 28. 디플로이먼트 • Deployment는 ReplicaSet을 활용하여 일정 수의 Pod 집합을 유지 • ReplicaSet의 목적: 고가용성 • Deployment는 이에 더해 롤아웃(롤링 업데이트/롤백) 기능을 제공 • Rollout: 새로운 버전의 애플리케이션을 배포하는 과정 전반 • Rolling Update: 새로운 버전을 점진적으로 배포하는 과정 • Rollback: Rollout 도중 문제가 발생했을 때 이전 버전으로 돌아가는 과정 Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet
- 30. 디플로이먼트 • 파드 배포에 대한 원하는 상태(desired state)를 선언 Cluster Node Node my-app Pod my-app Pod 예) my-app Pod는 해당 복제본이 두 개 있어야 하여, 파드 업데이트시 순차적으로 교체되어야 한다 my-app Deployment Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet
- 31. 디플로이먼트 • 파드 배포에 대한 원하는 상태(desired state)를 선언 Cluster Node Node my-app Pod my-app Pod 예) my-app Pod는 해당 복제본이 두 개 있어야 하여, 파드 업데이트시 순차적으로 교체되어야 한다 my-app Deployment Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet
- 32. 디플로이먼트 파드 스펙 Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet 셀렉터 어떤 파드를 디플로이먼트의 대상으로 지정할 것인가? 라벨 다른 워크로드가 해당 파드를 인식할 수 있도록 지정
- 33. 디플로이먼트 실습 • k apply -f nginx-deployment.yaml • kubectl rollout history deployment nginx-deployment • kubectl rollout undo deployment nginx-deployment • kubectl scale --replicas=2 deployment nginx-deployment Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet
- 34. 디플로이먼트 롤아웃 디플로이먼트 레플리카셋: v1 5c7dff4cf7 레플리카셋: v2 d556bf558 파드 v2 $ kubectl get all NAME READY STATUS RESTARTS AGE pod/nginx-deployment-d556bf558-h6lgh 1/1 Running 0 8m10s pod/nginx-deployment-d556bf558-sd4bd 1/1 Running 0 8m10s pod/nginx-deployment-d556bf558-tvddm 1/1 Running 0 8m10s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/nginx-deployment 3/3 3 3 8m30s NAME DESIRED CURRENT READY AGE replicaset.apps/nginx-deployment-5c7dff4cf7 0 0 0 8m30s replicaset.apps/nginx-deployment-d556bf558 3 3 3 8m20s Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet
- 36. 롤아웃: Recreate • 서비스 성능의 저하 없이 레플리카셋의 모든 파드를 중단할 수 있는 경우에 적합 • 새로운 설정으로 새로운 레플리카셋을 생성하고, 새로운 파드가 온라인으로 전환되기 전에 이전 레플리카셋 삭제 • 다운타임이 존재함
- 37. 롤아웃 방식 차이 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 25m deployment-controller Scaled up replica set cozserver-64fff44954 to 3 Normal ScalingReplicaSet 25m deployment-controller Scaled up replica set cozserver-6bcf6bd57d to 1 Normal ScalingReplicaSet 25m deployment-controller Scaled down replica set cozserver-64fff44954 to 2 Normal ScalingReplicaSet 25m deployment-controller Scaled up replica set cozserver-6bcf6bd57d to 2 Normal ScalingReplicaSet 25m deployment-controller Scaled down replica set cozserver-64fff44954 to 1 Normal ScalingReplicaSet 25m deployment-controller Scaled up replica set cozserver-6bcf6bd57d to 3 Normal ScalingReplicaSet 25m deployment-controller Scaled down replica set cozserver-64fff44954 to 0 Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet
- 38. maxSurge / maxUnavailable Waiting Running v1 v1 v1 v1 v1 v1 v1 v1 v1 v1 v1 v2 v1 v1 v2 v1 v2 v2 v1 v2 v2 v2 v2 v2 v2 v2 v2 v2 v2 v2 가용한 파드 3 3 4 3 4 4 4 3 maxSurge=1 / maxUnavailiable=0 Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet
- 39. maxSurge / maxUnavailable v1 v1 v1 v1 v1 v1 v1 v2 v2 v2 v2 v2 v2 v2 v2 v2 가용한 파드 3 2 4 2 3 maxSurge=1 v2 maxUnavailable=1 Pod Service Deployment Ingress Secret ConfigMap DaemonSet StatefulSet Waiting Running