반응형
[참고]
본 글은 인프런의
<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>
강의 내용과 실습을 바탕으로 정리한 기록입니다.
주요 컴포넌트 구성
1. Resource 계층 (논리적 리소스 및 스토리지)
- Cluster level & Namespace level: 클러스터 전체에 적용되는 Namespace, PV와 그 하위에서 격리되어 관리되는 리소스들로 구분됩니다.
- Controller: HPA ➔ Deployment ➔ ReplicaSet으로 이어지며 타 컨트롤러나 오브젝트를 상태 정의에 맞게 제어합니다.
- Object: Service, ConfigMap, Secret 등이 Pod와 연결되어 단독 인프라 기능을 수행하며, 데이터 보존을 위해 Pod ➔ PVC ➔ PV ➔ 외부 볼륨 솔루션(NFS, Ceph, AWS EBS 등)으로 이어집니다.
2. Kubernetes Cluster 계층 (클러스터 내부 컴포넌트)
- Control Plane Component:
- kube-apiserver: 중앙에서 모든 API 요청을 수신하고 통신을 중계합니다.
- etcd: 클러스터의 모든 상태 정보(Database)를 안전하게 저장합니다.
- kube-controller-manager & kube-scheduler: 파드의 스케줄링 및 컨트롤러 상태를 관리합니다.
- Worker Component & Addon Pod:
- 노드 네트워킹을 위한 kube-proxy와 실제 사용자의 User App Pod가 동작합니다.
- 클러스터 기능을 확장하는 metrics-server, coredns, calico, kube-dashboard 등이 Addon 파드로 설치됩니다.
3. VM 계층 (물리/가상 노드 및 실행 도구)
- Master Node:
- kubectl: 인증서(/root/.kube/config)를 사용해 kube-apiserver로 명령을 전달합니다.
- kubeadm: 정적 파드 Manifests(/etc/kubernetes/manifests)를 통해 컨트롤 플레인을 구축합니다.
- kubelet: kube-apiserver의 요청을 받아 컨테이너 런타임(containerd)에 실제 컨테이너 생성을 명령합니다.
- Worker Node: kubeadm join을 통해 클러스터에 참여하며 kubelet과 containerd가 실행되어 파드를 띄웁니다.
💻 Resource 확인
$ kubectl api-resources
✅ 확인 결과
💻 Cluster 주요 컴포넌트 로그 확인
// 주요 컴포넌트 로그 보기 (kube-system)
$ kubectl get pods -n kube-system
$ kubectl logs -n kube-system etcd-k8s-master
$ kubectl logs -n kube-system kube-scheduler-k8s-master
$ kubectl logs -n kube-system kube-apiserver-k8s-master
✅ 확인 결과
💻 Master Node 파일 위치
// 쿠버네티스 인증서 위치
$ cd /etc/kubernetes
$ ls /root/.kube/config
// Control Plane Component Pod 생성 yaml 파일 위치
$ ls /etc/kubernetes/manifests
// 전체 Pod 로그
/var/log/pods/<namespace_<pod-name>_<uid>/<number>.log
/var/log/containers/<pod-name>_<namespace>_<container-name>_<container-id>.log
✅ 확인 결과
💻 트러블 슈팅
// kubelet 상태 확인
1) systemctl status kubelet // systemctl (restart or start) kubelet
2) journalctl -u kubelet | tail -10
// 상태 확인 -> 상세 로그 확인 -> 10분 구글링 -> VM 재기동 -> Cluster 재설치 -> 답을 찾을 때 까지 구글링
// containerd 상태 확인
1) systemctl status containerd
2) journalctl -u containerd | tail -10
// 노드 상태 확인
1) kubectl get nodes -o wide
2) kubectl describe node k8s-master
// Pod 상태 확인
1) kubectl get pods -A -o wide
// Event 확인 (기본값: 1h)
2-1) kubectl get events -A
2-2) kubectl events -n anotherclass-123 --types=Warning (or Normal)
// Log 확인
3-1) kubectl logs -n anotherclass-123 <pod-name> --tail 10 // 10줄 만 조회하기
3-2) kubectl logs -n anotherclass-123 <pod-name> -f // 실시간으로 조회 걸어 놓기
3-3) kubectl logs -n anotherclass-123 <pod-name> --since=1m // 1분 이내에 생성된 로그만 보기
Pod 생성 및 probe 동작
쿠버네티스에서 사용자가 배포 명령을 내렸을 때, 컨트롤 플레인 내부에서 Pod가 생성되는 메커니즘과 노드 단에서 Probe 검사가 수행되는 전체 흐름을 보여주는 다이어그램입니다.
1. Resource 계층 (배포 관련 오브젝트 및 속성)
- Deployment & ReplicaSet: Deployment 정의에 따라 ReplicaSet이 생성되고, 이는 지정된 개수만큼의 Pod를 관리합니다.
- Pod 핵심 설정 속성:
- nodeSelector: 특정 노드(예: Master Node 등)를 지정하여 Pod가 배포될 위치를 결정합니다.
- resources: CPU, Memory의 requests 및 limits 자원 사용량을 설정합니다.
- probe: 컨테이너의 상태 체크(Startup, Readiness, Liveness) 메커니즘을 정의합니다.
2. Control Plane 계층 (Pod 생성 워크플로우)
- 요청 수신: kubectl 명령을 통해 kube-apiserver로 Deployment 생성 API가 호출됩니다.
- 상태 저장: kube-apiserver는 매 요청 및 클러스터 변경 사항을 etcd Database에 기록하고 업데이트합니다.
- 컨트롤러 동작: kube-controller-manager가 etcd 상태 변화를 모니터링하다가 ReplicaSet 및 Pod 생성 API를 수행합니다.
- 스케줄링: kube-scheduler가 노드의 자원 상태를 모니터링하여, 생성될 Pod를 어느 노드에 할당할지 결정(노드 스케줄링)합니다.
3. Node 계층 (컨테이너 생성 및 헬스 체크)
- 노드 모니터링: 해당 노드의 kubelet은 kube-apiserver를 감시하다가 자신에게 할당된 Pod 정보가 넘어오면 이를 감지합니다.
- 컨테이너 실행: kubelet이 로컬의 컨테이너 런타임(containerd)에 컨테이너 생성 요청을 전달하여 실제 프로세스를 띄웁니다.
- Probe 체크 (상태 검사):
- 컨테이너가 띄워진 후, kubelet이 설정된 probe 기준에 따라 컨테이너 상태를 직접 주기적으로 검사합니다.
- Startup Probe: 앱 기동 완료 여부 확인 (실패 시 재기동)
- Readiness Probe: 트래픽 수신 준비 완료 여부 확인 (실패 시 서비스 엔드포인트 제외)
- Liveness Probe: 프로세스 생존 상태 확인 (실패 시 컨테이너 재시작)
Service 동작
쿠버네티스에서 외부 사용자가 호출한 API 트래픽이 Service(NodePort)를 거쳐 최종 목적지인 Pod의 컨테이너까지 전달되는 전체 네트워크 포워딩 메커니즘을 보여주는 다이어그램입니다.
1. Resource 계층 (서비스 및 네트워크 설정)
- Service (nodePort): NodePort 타입의 Service 오브젝트가 생성되어 외부 트래픽을 받기 위한 포트(예: 31231)를 노드 전체에 개방합니다.
- Pod 연결: Service의 selector 조건과 Pod의 labels가 매칭되어, 진입한 트래픽이 올바른 타겟 파드로 라우팅될 수 있도록 연결 고리를 형성합니다.
2. Control Plane & Worker 계층 (네트워크 정책 구성)
- Network 생성 요청: kube-apiserver에 Service 생성 요청이 등록되면, 각 노드의 kube-proxy가 이를 감지합니다.
- CNI 연동 (calico): 클러스터 내부 및 Pod 간의 네트워크 통신 환경은 Addon Pod로 설치된 CNI 플러그인(calico)을 통해 제어됩니다.
- iptables 규칙 업데이트: kube-proxy는 Service 및 Endpoints 정보를 기반으로 노드의 OS iptables 라우팅 규칙을 자동으로 업데이트합니다.
3. Node 계층 (실제 트래픽 흐름)
- 외부 API 호출: 외부 클라이언트가 http://Node_IP:31231/version 형태로 노드의 개방된 포트(31231)로 API 요청을 보냅니다.
- iptables 포워딩: 노드의 OS 단 iptables가 들어온 요청(port 31231)을 낚아채어, 해당 서비스(api-tester-1231)와 매핑된 Pod IP 및 포트(targetPort)로 트래픽을 변환(NAT)합니다.
- 컨테이너 전달: 변환된 트래픽이 최종적으로 container로 전달되어 애플리케이션의 응답을 처리하게 됩니다.
Secret 동작
Secret 데이터를 볼륨(Volume) 마운트 방식으로 Pod에 주입했을 때의 데이터 동기화 메커니즘과 메모리 기반 마운트의 특징을 보여주는 다이어그램입니다.
1. Resource 계층 (Secret과 Volume 바인딩)
- Secret ➔ Pod (volume): Secret 오브젝트에 정의된 data가 Pod 내부의 volume 영역으로 연결되어 있습니다.
- 내용 수정 시 동기화: Secret의 data 내용이 수정될 때, 볼륨으로 연결된 파드는 이를 동적으로 감지하여 반영할 준비를 합니다.
2. Control Plane & Worker 계층 (변경 사항 동기화)
- 주기적 변경 확인: 해당 노드의 kubelet이 kube-apiserver를 통해 Secret 오브젝트의 변경 사항을 주기적으로 감시(Poll/Watch)합니다.
- 볼륨 내용 업데이트: Secret 값이 변경되면 kubelet이 파드를 재시작하지 않고도, 컨테이너 내부로 마운트되어 있는 해당 파일 영역을 실시간으로 업데이트합니다.
3. Node 계층 (Memory 기반 마운트의 데이터 보안 특징)
- Memory(tmpfs) 마운트: 노드의 물리 디스크가 아닌 노드의 메모리(Memory) 영역에 Secret 파일(postgresql-info.yaml)을 생성한 후 컨테이너 내부 지정 경로(/usr/src/myapp/datasource/postgresql-info.yaml)로 마운트합니다.
- 휘발성 특징 (전원 오프 시 데이터 삭제): 메모리 영역을 활용하기 때문에 서버 전원이 꺼지면 메모리에 올려두었던 데이터가 함께 삭제되어, 물리 디스크에 보안 데이터 흔적이 남지 않는 보안적 특성을 가집니다.
HPA 동작
클러스터 내 부하(CPU, Memory 등)를 감지하여 Pod 수량을 자동으로 조절하는 HorizontalPodAutoscaler(HPA)의 전체 매트릭 수집 및 스케일링 흐름을 보여주는 다이어그램입니다.
1. Resource 계층 (오토스케일링 대상 및 조건)
- HPA (metrics): HPA 컨트롤러가 Target으로 지정된 Deployment의 리소스 사용 상태를 감시하며 스케일아웃/인 조건(임계값)을 제어합니다.
- Deployment 제어: HPA 조건에 따라 Deployment의 replicas 수량을 변경하여 Pod 개수를 늘리거나 줄입니다.
2. Control Plane & Worker 계층 (메트릭 연동 및 스케일링)
- 메트릭 수집 (metrics-server): Addon Pod로 설치된 metrics-server가 각 노드의 kubelet으로부터 수집된 파드별 CPU/메모리 사용 데이터를 집계합니다.
- 임계값 비교 (kube-controller-manager):
- HPA 컨트롤러가 포함된 kube-controller-manager가 kube-apiserver를 통해 metrics-server에 요청을 보내 15초 주기로 현재 사용량 매트릭을 조회합니다.
- 조회한 매트릭과 HPA에 설정된 임계값(metrics)을 비교합니다.
- 스케일링 명령 수행: 임계치를 초과하거나 미달할 경우, HPA 컨트롤러가 Deployment의 replicas 수치를 조절하여 파드 확장을 명령합니다. (전체 반응 시간: 1~85초)
3. Node 계층 (실제 자원 메트릭 조회)
- 컨테이너 자원 조회: 각 노드의 kubelet이 containerd 런타임 및 cgroup을 통해 파드 내 컨테이너의 CPU/Memory 사용량을 10초 주기로 조회합니다.
- 자원 정보 집계: kubelet은 조회된 자원 사용량 메트릭을 60초 주기로 metrics-server로 전송 및 수집시킵니다.
반응형
