inflearn logo
강의

강의
N
챌린지

챌린지
멘토링

멘토링
N
클립

클립
로드맵

로드맵
지식공유

[쿠버네티스] Component 동작으로 k8s 이해 #11

_hamtaro_o
2

image

들어가며

Kubernetes를 사용하다 보면 "내부적으로 어떻게 동작하는 걸까?" 하는 궁금증이 생긴다. 각 컴포넌트들이 어떻게 상호작용하며 우리가 만든 애플리케이션이 실행되는지 알아보자. 이런 내용을 모른다고 해서 Kubernetes를 사용하는 데 문제가 생기는 건 아니지만, 이해하고 있으면 문제 해결과 운영에 큰 도움이 된다.

 

1. Kubernetes 클러스터 구성과 컴포넌트

마스터 노드 (Control Plane) 구성

마스터 노드에는 Kubernetes가 돌아가는 데 필요한 핵심 컴포넌트들이 설치된다. 이들을 컨트롤 플레인 컴포넌트라고 부른다.

워커 노드 구성

워커 노드는 실제 애플리케이션이 실행되는 공간이다. 마스터 노드와 동일한 기본 컴포넌트가 설치되지만, 추가로 다음 요소들이 있다:

중요한 점: 운영 환경에서는 마스터 노드에 애플리케이션을 올리면 안 된다. CPU 사용량이 올라가서 마스터 노드가 죽으면 전체 클러스터가 멈추기 때문이다. 애플리케이션은 반드시 워커 노드에 배치해야 한다.

Add-on Pod들

Kubernetes의 기본 기능을 확장시키기 위한 애플리케이션들이다:

앞으로 더 많은 Add-on Pod들을 설치하게 될 텐데, 그만큼 Kubernetes가 복잡해지지만 제대로 사용하기 위해서는 필요한 구성 요소들이다.

 

2. 오브젝트 vs 컨트롤러 vs 리소스

Kubernetes를 이해하려면 이 세 개념의 차이를 명확히 알아야 한다.

오브젝트 (Object)

컨트롤러 (Controller)

리소스 (Resource)

인프라 요소의 Kubernetes 추상화

인프라에는 네트워크, 볼륨, 환경 변수 등의 요소들이 있다. Kubernetes는 이런 요소들을 오브젝트로 정의하고, 이 오브젝트들을 자동화시킬 목적으로 컨트롤러라는 개념을 만들었다.

이 전체 리소스들은 컨트롤 플레인 컴포넌트라는 파드들에 의해서 동작한다. 각자의 역할이 있고 리소스들을 동작시키기 위해서 컨트롤러들과 통신하지만, 실제 컨테이너는 Kubernetes가 직접 만드는 게 아니다. Kubernetes는 컨테이너 생성 요청만 하고, 노드 위에 설치된 특정 기술들(Container Runtime)이 실제 작업을 수행한다.

 

3. 파드 생성 과정 상세 분석

파드가 생성되는 과정을 단계별로 자세히 살펴보자.

1단계: API 요청 및 데이터 저장

kubectl create deployment → API Server → etcd 저장

  1. 요청 접수: kubectl 명령어나 Dashboard를 통해 Deployment 생성 요청

  2. API 처리: API Server가 요청을 받아서 검증 및 처리

  3. 데이터 저장: etcd에 Deployment 데이터 저장

  4. 조회 가능: 이 시점에서 Deployment가 조회되고 Dashboard에 나타남

중요: 아직 실제 컨테이너는 생성되지 않음. 단순히 데이터만 저장된 상태

2단계: Controller Manager의 ReplicaSet 생성

Controller Manager → ReplicaSet 생성 API → etcd 저장

  1. 모니터링: Controller Manager가 지속적으로 etcd 데이터베이스를 모니터링

  2. Deployment 발견: 새로운 Deployment가 생성된 것을 감지

  3. ReplicaSet 생성: Deployment 스펙에 따라 ReplicaSet 생성 요청

  4. 연결 관계: Deployment와 ReplicaSet 간의 관계 설정

3단계: ReplicaSet Controller의 Pod 생성

ReplicaSet Controller → Pod 생성 API → etcd 저장

  1. ReplicaSet 모니터링: ReplicaSet Controller가 새로운 ReplicaSet 발견

  2. Pod 생성 요청: ReplicaSet의 replicas 수만큼 Pod 생성 API 호출

  3. Pod 데이터 저장: etcd에 Pod 데이터 저장

여전히 데이터만 존재: 실제 컨테이너는 아직 생성되지 않음

4단계: Scheduler의 노드 선택

Scheduler → 노드 리소스 분석 → Pod에 노드 정보 업데이트

  1. Pod 감지: Scheduler가 노드가 할당되지 않은 Pod 발견

  2. 노드 분석: 각 워커 노드의 자원 상태 (CPU, 메모리, 디스크) 분석

  3. 스케줄링 결정: Pod의 요구사항과 노드 affinity 등을 고려하여 최적 노드 선택

  4. 노드 할당: Pod에 선택된 노드 정보 업데이트

5단계: kubelet의 실제 컨테이너 생성

kubelet → Container Runtime → 실제 컨테이너 실행

  1. Pod 발견: 각 노드의 kubelet이 자신에게 할당된 Pod 발견

  2. 컨테이너 런타임 호출: containerd 등의 Container Runtime에 컨테이너 생성 요청

  3. 컨테이너 실행: 실제 컨테이너가 생성되고 실행됨

  4. 상태 업데이트: Pod 상태를 API Server를 통해 업데이트

6단계: Health Check 설정

kubelet → Health Check API → 주기적 상태 확인

Probe 설정을 했다면:

  1. Probe 설정 확인: kubelet이 Pod의 Probe 설정 확인

  2. Health Check 실행: 설정에 맞게 컨테이너로 Health Check API 주기적 호출

  3. 상태 반영: Health Check 결과에 따라 Pod 상태 업데이트

 

4. 서비스(Service) 네트워킹 동작 원리

NodePort 서비스 생성 과정

Service 생성 → kubelet 감지 → kube-proxy 호출 → iptables 규칙 추가

  1. Service 생성: NodePort 타입의 Service 리소스 생성

  2. kubelet 감지: Service와 Pod의 연결 관계 파악

  3. kube-proxy 요청: kubelet이 kube-proxy에게 네트워크 설정 요청

  4. iptables 업데이트: kube-proxy가 iptables에 라우팅 규칙 추가

실제 트래픽 흐름

외부 요청(31231 포트) → iptables 규칙 → Service → Pod → Container

  1. 외부 요청: 클라이언트가 NodePort(예: 31231)로 요청

  2. iptables 처리: iptables가 해당 포트를 Service로 라우팅

  3. Service 라우팅: Service가 연결된 Pod 중 하나를 선택

  4. CNI 네트워킹: Calico 등의 CNI가 Pod 간 네트워크 통신 처리

  5. 최종 전달: 대상 컨테이너로 트래픽 전달

iptables의 역할: 리눅스로 들어오는 모든 패킷을 관리하는 도구. kube-proxy가 iptables에 규칙을 추가하여 서비스 이름을 주석으로 포함한 맵핑 규칙을 생성한다.

 

5. Secret의 보안 메커니즘과 동작 방식

Secret의 메모리 기반 저장

Secret은 일반적인 파일 시스템이 아닌 노드의 메모리 영역에 마운트된다.

보안상 장점:

실무에서 고려사항

메모리 사용량 문제:

업데이트 딜레이:

Secret vs 일반 데이터

Secret이 제공하는 보안 기능은 있지만 극도로 제한적이다. 완벽한 보안을 원한다면 별도의 보안 솔루션을 사용해야 한다. Secret은 기본적인 보안 수준을 제공하는 정도로 이해하는 것이 좋다.

 

6. HPA(Horizontal Pod Autoscaler) 상세 동작

메트릭 수집 체계의 복잡성

HPA가 동작하기 위해서는 여러 컴포넌트가 순차적으로 작동해야 한다.

Container Runtime → kubelet(10초) → Metrics Server(60초) → Controller Manager(15초)

1단계: Container Runtime의 리소스 모니터링

2단계: kubelet의 주기적 수집

3단계: Metrics Server의 중앙 집중화

중요: Metrics Server가 설치되지 않으면 HPA가 전혀 동작하지 않는다!

4단계: Controller Manager의 스케일링 결정

HPA 동작 타이밍 분석

최적의 경우: 모든 수집 주기가 완벽하게 맞아떨어지면 즉시 스케일링 동작

최악의 경우: 다음과 같은 시나리오에서 최대 85초 소요

  1. 부하 발생: 애플리케이션에 갑작스런 부하 발생

  2. kubelet 수집 대기: 최대 10초 대기 (다음 수집 주기까지)

  3. Metrics Server 수집 대기: 최대 60초 대기 (다음 수집 주기까지)

  4. Controller Manager 판단 대기: 최대 15초 대기 (다음 체크 주기까지)

총 최대 대기시간: 10 + 60 + 15 = 85초

이런 타이밍 특성을 이해하고 있어야 HPA의 한계를 알고 적절한 임계값을 설정할 수 있다.

 

7. Kubernetes 아키텍처의 기술 스택

다층 구조의 이해

Kubernetes는 여러 기술 스택이 조합된 복잡한 시스템이다:

Application Layer (Pod, Service, etc.)
       ↓
Kubernetes Layer (API Server, Controller, etc.) 
       ↓
Container Runtime Layer (containerd, etc.)
       ↓
Linux Kernel Layer (cgroup, namespace, etc.)
       ↓
Hardware Layer (CPU, Memory, Network, etc.)

 

학습 깊이에 대한 고민

다양한 학습 접근법:

 

실용적 학습 권장사항

깊이 있는 학습의 함정:

권장하는 접근법:

핵심 원칙:

 

8. 실전 트러블슈팅 가이드

기본 점검 명령어

전체 리소스 확인:

kubectl api-resources

컴포넌트 로그 확인:

# kube-system 네임스페이스의 모든 파드 조회
kubectl get pods -n kube-system

# 특정 컴포넌트 로그 확인
kubectl logs -n kube-system <pod-name>

 

시스템 레벨 진단

kubelet 상태 확인:

# kubelet 상태 확인
systemctl status kubelet

# kubelet 재시작 (문제 발생시)
systemctl restart kubelet
systemctl start kubelet

# 상세 로그 확인
journalctl -u kubelet --no-pager

Container Runtime 확인:

# containerd 상태 확인
systemctl status containerd

# 노드 상태 전반적 확인
kubectl get nodes
kubectl describe node <node-name>

 

애플리케이션 레벨 진단

Pod 상태 확인:

# 전체 Pod 상태 확인
kubectl get pods --all-namespaces

# 특정 네임스페이스의 Pod 확인  
kubectl get pods -n <namespace>

# Pod 상세 정보 확인
kubectl describe pod <pod-name>

이벤트 로그 분석:

# 전체 이벤트 조회 (너무 많이 나올 수 있음)
kubectl get events

# 특정 네임스페이스의 Warning 이벤트만 조회
kubectl get events -n <namespace> --field-selector type=Warning

# 특정 시간 이후 이벤트만 조회
kubectl get events --sort-by='.lastTimestamp'

애플리케이션 로그 확인:

# 기본 로그 확인
kubectl logs <pod-name>

# 마지막 10줄만 확인
kubectl logs <pod-name> --tail=10

# 실시간 로그 스트리밍
kubectl logs <pod-name> --follow

# 최근 1분간의 로그만 확인
kubectl logs <pod-name> --since=1m

# 컨테이너가 여러 개인 경우 특정 컨테이너 지정
kubectl logs <pod-name> -c <container-name>

 

네트워크 관련 진단

서비스와 iptables 확인:

# iptables 규칙 확인 (NodePort 맵핑 확인)
iptables -t nat -L | grep <port-number>

# 서비스 정보 확인
kubectl get services
kubectl describe service <service-name>

# 엔드포인트 확인 (Service와 Pod 연결 상태)
kubectl get endpoints

 

문제 해결 프로세스

1단계: 기본 상태 점검

# 전체적인 클러스터 상태 파악
kubectl cluster-info
kubectl get nodes
kubectl get pods --all-namespaces | grep -v Running

2단계: kubelet 및 시스템 컴포넌트 확인

3단계: 애플리케이션 레벨 분석

4단계: 네트워크 및 보안 설정 확인

 

트러블슈팅 철학과 접근법

구글링의 중요성:

시스템 재설치 고려:

설정 관리의 중요성:

끈기의 중요성:

 

9. Kubernetes 설정 파일과 로그 위치

중요 설정 파일 위치

Kubernetes 설정 디렉토리:

컨테이너 런타임 설정:

 

로그 파일 위치와 관리

파드 로그 저장 위치:

/var/log/pods/: 마스터 노드 위에 올라가는 모든 파드들의 로그 저장

로그 관리 방식:

실제 사용 시나리오:

 

10. 학습 효율성과 실무 적용

실습 환경 구축의 가치

현재 시점에서의 역량:

획득한 능력:

 

DevOps/인프라 분야의 장점

표준화의 이점:

지속적인 성장 가능성:

 

효과적인 학습 전략

공부한 자료의 체계적 정리:

점진적 학습 접근법:

실습 중심의 학습:

 

11. 실제 문제 해결 시나리오

ConfigMap 삭제로 인한 Pod 장애 시뮬레이션

실제 문제 상황을 만들어서 트러블슈팅 과정을 살펴보자.

문제 상황 생성:

# ConfigMap 삭제
kubectl delete configmap <configmap-name>

# Pod 재시작 (문제 상황 유발)
kubectl delete pod <pod-name>

증상 확인:

# Pod 상태 확인 - CrashLoopBackOff 또는 ContainerCreating 상태
kubectl get pods

# 3개의 Pod가 모두 에러 상태로 나타남

원인 분석 과정:

  1. 이벤트 로그 우선 확인:

# 전체 이벤트 조회 (너무 많이 나올 수 있음)
kubectl get events

# 특정 네임스페이스와 타입으로 필터링
kubectl get events -n <namespace> --field-selector type=Warning

  1. 결과 분석:

Warning  FailedMount  5s    kubelet  MountVolume.SetUp failed for volume "config-volume" : configmap "app-config" not found

  1. 문제 해결:

# ConfigMap 재생성
kubectl create configmap app-config --from-file=config.properties

# Pod 자동 복구 확인
kubectl get pods

 

Pod 로그 분석 시나리오

애플리케이션 내부 에러 진단:

이벤트 로그에 특별한 문제가 없다면 애플리케이션 자체 문제일 가능성이 높다.

# 기본 로그 확인
kubectl logs <pod-name>

# 실시간 로그 모니터링
kubectl logs <pod-name> --follow

# 최근 1분간 로그만 확인
kubectl logs <pod-name> --since=1m

# 마지막 10줄만 간단히 확인
kubectl logs <pod-name> --tail=10

다중 컨테이너 Pod의 경우:

# 특정 컨테이너 로그 확인
kubectl logs <pod-name> -c <container-name>

# 모든 컨테이너 로그 확인
kubectl logs <pod-name> --all-containers=true

 

네트워크 연결 문제 진단

Service 연결 문제 해결:

# Service 상태 확인
kubectl get services
kubectl describe service <service-name>

# Endpoints 확인 (Service와 Pod 연결 상태)
kubectl get endpoints <service-name>

# iptables 규칙 확인
sudo iptables -t nat -L | grep <service-port>

일반적인 네트워크 문제들:

12. Kubernetes 리소스 관리 심화

전체 리소스 확인과 관리

kubectl api-resources 명령어 활용:

# 전체 리소스 목록 확인
kubectl api-resources

# 특정 API 버전의 리소스만 확인
kubectl api-resources --api-group=apps

# 네임스페이스 레벨 리소스만 확인
kubectl api-resources --namespaced=true

# 클러스터 레벨 리소스만 확인  
kubectl api-resources --namespaced=false

출력 정보 해석:

실무 활용팁:

 

리소스 간 관계 이해

계층적 관계:

Deployment (Controller)
    ↓ 관리
ReplicaSet (Controller)  
    ↓ 관리
Pod (Object)
    ↓ 사용
ConfigMap, Secret (Object)

소유권 관계 확인:

# ownerReferences 확인
kubectl get replicaset <rs-name> -o yaml | grep -A 10 ownerReferences

# 특정 Deployment의 하위 리소스들 확인
kubectl get all -l app=<app-name>

 

13. iptables와 네트워킹 심화

iptables 규칙 상세 분석

NodePort 매핑 규칙 확인:

# NAT 테이블의 모든 규칙 확인
sudo iptables -t nat -L -n --line-numbers

# 특정 포트 관련 규칙만 확인
sudo iptables -t nat -L | grep <port-number>

# 자세한 규칙 정보 확인
sudo iptables -t nat -L KUBE-SERVICES -n

kube-proxy가 생성하는 규칙들:

실제 규칙 예시:

Chain KUBE-NODEPORTS (1 references)
target     prot opt source               destination
KUBE-SVC-xxx  tcp  --  0.0.0.0/0            0.0.0.0/0            /* default/my-service:http */ tcp dpt:31231

 

CNI 네트워킹 이해

Calico의 역할:

네트워크 플로우:

Client → NodePort → iptables → kube-proxy → CNI → Pod

 

14. 메모리와 스토리지 관리

Secret과 ConfigMap의 메모리 사용

메모리 마운트 확인:

# Pod 내부에서 마운트 포인트 확인
kubectl exec <pod-name> -- df -h

# Secret이 마운트된 경로 확인 (보통 tmpfs)
kubectl exec <pod-name> -- mount | grep tmpfs

메모리 사용량 모니터링:

# 노드의 메모리 사용량 확인
kubectl top nodes

# 특정 Pod의 메모리 사용량 확인
kubectl top pods

주의사항:

 

로그 관리와 디스크 사용량

로그 파일 크기 관리:

# 로그 디렉토리 크기 확인
sudo du -sh /var/log/pods/

# 특정 Pod의 로그 크기 확인
sudo du -sh /var/log/pods/<namespace>_<pod-name>_*/

로그 로테이션 설정:

 

15. 고급 모니터링과 메트릭스

Metrics Server 의존성 이해

HPA 동작을 위한 필수 조건:

  1. Metrics Server 설치: kubectl apply -f metrics-server.yaml

  2. 리소스 요청 설정: Pod에 resources.requests 설정 필수

  3. 충분한 실행 시간: 메트릭 수집을 위한 최소 시간 필요

메트릭 수집 체인 검증:

# Metrics Server 상태 확인
kubectl get pods -n kube-system | grep metrics-server

# 노드 메트릭 확인
kubectl top nodes

# Pod 메트릭 확인  
kubectl top pods

# HPA 상태 확인
kubectl get hpa
kubectl describe hpa <hpa-name>

 

리소스 사용량 분석

CPU/메모리 사용 패턴 파악:

# 실시간 리소스 사용량 모니터링
watch kubectl top pods

# 특정 네임스페이스의 리소스 사용량
kubectl top pods -n <namespace>

# 정렬된 리소스 사용량 확인
kubectl top pods --sort-by=cpu
kubectl top pods --sort-by=memory

HPA 타이밍 최적화:

 

16. 실무 운영 시나리오

장애 대응 프로세스

단계별 장애 대응:

  1. 1차 진단 (1분 내):

kubectl get pods --all-namespaces | grep -v Running
kubectl get nodes
kubectl cluster-info

  1. 2차 분석 (5분 내):

kubectl describe pod <problem-pod>
kubectl get events --sort-by='.lastTimestamp' | tail -20
kubectl logs <problem-pod> --tail=50

  1. 3차 심화 분석 (10분 내):

systemctl status kubelet
systemctl status containerd
sudo dmesg | tail -20

  1. 임시 복구 조치:

kubectl delete pod <problem-pod>  # ReplicaSet이 새 Pod 생성
kubectl rollout restart deployment <deployment-name>

 

용량 계획과 리소스 관리

클러스터 용량 모니터링:

# 전체 클러스터 리소스 사용량
kubectl top nodes

# 네임스페이스별 리소스 사용량
kubectl top pods -A --sort-by=memory

# 리소스 요청량 vs 실제 사용량 비교
kubectl describe nodes

스케일링 전략:

 

보안 및 네트워크 정책

기본 보안 체크리스트:

# RBAC 설정 확인
kubectl get clusterrolebindings
kubectl get rolebindings -A

# 네트워크 정책 확인
kubectl get networkpolicies -A

# 보안 컨텍스트 확인
kubectl get pods -o yaml | grep -A 10 securityContext

 

마치며

학습 성과 정리

이 글을 통해 다음과 같은 내용들을 체계적으로 정리했다:

  1. 아키텍처 이해: Kubernetes의 전체적인 구성과 각 컴포넌트의 역할

  2. 동작 원리 파악: 파드 생성부터 서비스 네트워킹까지의 상세 과정

  3. 실무 트러블슈팅: 실제 문제 상황에서의 체계적인 해결 방법

  4. 운영 노하우: 효율적인 클러스터 관리와 모니터링 방법

 

지속적인 성장을 위한 제언

실무 적용 시 고려사항:

앞으로의 학습 방향:

마지막 당부: Kubernetes는 빠르게 발전하는 기술이다. 완벽하게 모든 것을 알려고 하기보다는, 핵심 개념을 이해하고 필요할 때 찾아서 활용할 수 있는 능력을 기르는 것이 더 중요하다.

구글에는 정말로 모든 답이 있다. 포기하지 말고 끝까지 찾아보자. 그리고 해결한 내용들은 반드시 정리해두자. 그것이 미래의 나와 동료들에게 큰 도움이 될 것이다.

"시스템은 거짓말을 하지 않는다. 분명히 뭔가를 건드렸을 것이다."
"구글에는 모든 답이 있다. 단지 내가 찾는 걸 포기했을 뿐이다."

데브옵스 · 인프라 쿠버네티스 일프로

답변 1

0

일프로

이젠 AI도 있으니 도저히 포기할 이유를 찾기도 힘들어 졌네요.