들어가며

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

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

마스터 노드 (Control Plane) 구성

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

• API Server: 모든 Kubernetes 요청의 중앙 처리소

• etcd: 클러스터의 모든 데이터를 저장하는 분산 키-값 저장소

• Controller Manager: 각종 컨트롤러들을 실행하여 클러스터 상태 관리

• Scheduler: 파드를 적절한 워커 노드에 배치하는 역할

워커 노드 구성

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

• kubelet: 노드의 파드 생명주기를 관리하는 에이전트

• kube-proxy: 네트워크 규칙을 관리하는 네트워크 프록시

• Container Runtime: 실제 컨테이너를 실행하는 런타임 (containerd 등)

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

Add-on Pod들

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

• Dashboard: 웹 UI를 통한 클러스터 관리

• Metrics Server: 리소스 사용량 수집 및 제공

• CNI Plugin: 네트워크 구성 (Calico 등)

• 기타 모니터링 도구들

   

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

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

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

오브젝트 (Object)

• 정의: 인프라의 개별 요소를 나타내는 개념

• 특성: 각각이 독립적인 기능을 수행

• 예시: Pod, Service, ConfigMap, Secret, PersistentVolume 등

컨트롤러 (Controller)

• 정의: 오브젝트들을 제어하고 관리하는 상위 개념

• 특성: 다른 오브젝트들의 상태를 모니터링하고 원하는 상태로 유지

• 예시: Deployment, ReplicaSet, DaemonSet, StatefulSet 등

리소스 (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 데이터는 복구 불가능

• 디스크 변경시 안전: 물리적으로 디스크를 교체해야 할 때도 Secret 데이터 유출 위험 없음

실무에서 고려사항

메모리 사용량 문제:

• Secret을 많이 만들수록 노드의 메모리 사용량 증가

• 실제로는 그렇게 많은 Secret을 만들 일은 없지만 알아두어야 할 제약사항

업데이트 딜레이:

• Secret 내용을 수정해도 즉시 반영되지 않음

• kubelet이 주기적으로 체크하여 변경사항을 반영하므로 약간의 딜레이 존재

Secret vs 일반 데이터

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

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

메트릭 수집 체계의 복잡성

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

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

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

• 기본 역할: containerd 등이 실제 컨테이너의 CPU, 메모리 사용량 파악

• 데이터 제공: kubelet이 접근할 수 있는 형태로 리소스 정보 제공

2단계: kubelet의 주기적 수집

• 수집 주기: 10초마다 Container Runtime에서 리소스 사용량 수집

• 로컬 저장: 수집한 데이터를 노드 내에서 임시 저장

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

• 수집 주기: 60초마다 각 노드의 kubelet에서 메트릭 수집

• 중앙 저장: 클러스터 전체의 리소스 사용량 데이터를 중앙에서 관리

• API 제공: Controller Manager가 조회할 수 있는 API 제공

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

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

• 비교 주기: 15초마다 HPA 설정값과 현재 메트릭 비교

• 임계값 체크: CPU/메모리 사용률이 설정된 임계값을 초과하는지 확인

• 스케일링 실행: 필요시 Deployment의 replicas 수 조정

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.)

학습 깊이에 대한 고민

다양한 학습 접근법:

• 실용주의자: Pod 생성 방법과 기본 사용법만 익히고 싶은 사람

• 구조 탐구자: Kubernetes가 Pod를 만들기 위해 어떤 동작을 하는지 알고 싶은 사람

• 저수준 분석가: Kubernetes가 리눅스의 어떤 기술을 이용해서 컨테이너를 실체화시키는지 공부하고 싶은 사람

실용적 학습 권장사항

깊이 있는 학습의 함정:

• 확률적으로 깊은 지식을 써먹을 기회가 많지 않음

• 오버레이 네트워크 같은 복잡한 개념을 깊이 공부해도 실제로는 Kubernetes가 알아서 잘 처리해줌

• 깊이 공부한 내용도 시간이 지나면 까먹게 됨

권장하는 접근법:

• 전체적인 구성 파악: 각 컴포넌트의 역할과 상호작용 이해

• 실무 중심 학습: 실제 문제 해결에 도움되는 지식 우선

• 점진적 심화: 정말 필요할 때만 깊이 있게 공부

핵심 원칙:

• 큰 틀의 동작 원리만 알아도 충분함

• ETCD가 데이터를 저장하는 데이터베이스 역할을 한다는 것만 알면 됨 (내부 구조까지 알 필요 없음)

• 확률적으로 공부한 내용을 써먹을 기회의 가성비를 고려해야 함

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

기본 점검 명령어

전체 리소스 확인:

kubectl api-resources

• 모든 Kubernetes 리소스 목록 조회

• 리소스 이름, 약어, 버전 정보 확인

• 네임스페이스 레벨 vs 클러스터 레벨 구분 (NAMESPACED 컬럼)

컴포넌트 로그 확인:

# 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 및 시스템 컴포넌트 확인

• kubelet이 정상 동작하는지 확인

• Container Runtime 상태 점검

• 시스템 리소스 (CPU, 메모리, 디스크) 확인

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

• Pod 상태 및 이벤트 로그 확인

• 애플리케이션 로그 분석

• 리소스 요구사항과 실제 할당량 비교

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

• Service 설정 및 iptables 규칙 점검

• NetworkPolicy 적용 여부 확인

• DNS 설정 문제 여부 점검

트러블슈팅 철학과 접근법

구글링의 중요성:

• "구글에는 모든 답이 있다. 단지 내가 찾는 걸 포기했을 뿐이다"

• 실무에서도 트러블슈팅의 대부분은 구글링으로 해결

• 10분 정도 검색해도 답이 없다면 시스템 재시작 고려

시스템 재설치 고려:

• 한두 번 이상한 현상이 발생하면 차라리 재설치가 효율적

• 시스템은 거짓말을 하지 않음 - 분명히 뭔가 설정을 건드린 것

• 스크립트가 있다면 재설치 부담이 적음

설정 관리의 중요성:

• 추가 작업 내용들을 스크립트에 포함시키거나 문서화 필수

• 정리하지 않은 설정들은 나중에 써먹을 수 없음

• 체계적인 설정 관리가 장기적으로 시간 절약

끈기의 중요성:

• 특별한 재능보다는 포기하지 않고 끝까지 하는 자세가 더 중요

• 대부분의 문제는 해결 방법이 존재함

• 에러 로그를 정확히 복사해서 검색하는 것이 핵심

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

중요 설정 파일 위치

Kubernetes 설정 디렉토리:

• /etc/kubernetes/: 주요 설정 파일들이 위치

• admin.conf: kubectl이 API Server에 접속할 때 사용하는 인증서 정보

• manifests/: 컨트롤 플레인 컴포넌트들의 YAML 파일들

컨테이너 런타임 설정:

• Container Runtime 관련 설정 파일들

• kubelet 설정 파일

로그 파일 위치와 관리

파드 로그 저장 위치:

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

로그 관리 방식:

• 컨테이너별로 개별 로그 파일 생성

• 두 위치에 중복 저장하는 것이 아니라 링크로 연결된 구조

• kubectl logs 명령어로 조회하는 것이 일반적이지만, 특정 시간대나 문자열 검색이 필요할 때는 직접 파일에 접근

실제 사용 시나리오:

• 로키(Loki) 같은 로그 수집 시스템을 설치한 경우

• 로키의 Promtail이 이 파일들을 읽어서 중앙 로그 저장소로 전송

• 따라서 직접 로그 파일에 접근할 일은 많지 않음

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

실습 환경 구축의 가치

현재 시점에서의 역량:

• 지금까지 학습한 내용으로 실습 환경 재구축 시간: 약 1시간

• 실무에서 Kubernetes를 처음 접하는 사람이 동일한 환경 구축 시간: 1달 이상 (앱 개발 포함)

획득한 능력:

• 1시간 만에 스케일링 테스트 환경 구축 가능

• 프로브 테스트 환경 구축 가능

• 다양한 Kubernetes 기능 실험 환경 준비 가능

DevOps/인프라 분야의 장점

표준화의 이점:

• Kubernetes가 컨테이너 오케스트레이션의 사실상 표준

• 어떤 프로젝트를 가더라도 비슷한 일을 하게 될 확률이 높음

• 한 번 익힌 지식을 지속적으로 활용 가능

지속적인 성장 가능성:

• 체계적으로 학습하고 정리한 지식은 오래 활용 가능

• 다른 사람보다 앞선 시작점에서 새 프로젝트 시작 가능

• 실력과 연봉을 꾸준히 높일 수 있는 분야

효과적인 학습 전략

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

• 시간이 오래 지나도 빠르게 적응할 수 있는 기반 마련

• 설정 스크립트화 및 문서화 필수

• 반복 학습보다는 체계적인 정리가 중요

점진적 학습 접근법:

• 한 번에 모든 것을 완벽하게 이해하려 하지 말 것

• 필요에 따라 단계적으로 심화 학습

• 실무에서 당장 필요한 것부터 우선순위를 두고 학습

실습 중심의 학습:

• 이론보다는 직접 해보면서 체득

• 문제 상황을 만들어서 해결해보는 경험 축적

• 반복적인 실습을 통해 자연스럽게 명령어와 개념 습득

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

2. 결과 분석:

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

3. 문제 해결:

# 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>

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

• Service Selector가 Pod Label과 일치하지 않음

• Pod가 Ready 상태가 아님

• NetworkPolicy에 의한 트래픽 차단

• DNS 해석 문제

  ---

   

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

출력 정보 해석:

• NAME: 리소스의 풀네임

• SHORTNAMES: kubectl에서 사용할 수 있는 약어

• APIVERSION: API 버전 정보

• NAMESPACED: 네임스페이스 레벨 여부 (false면 클러스터 레벨)

• KIND: YAML 파일에서 사용하는 Kind 값

실무 활용팁:

• 자주 사용하는 리소스의 약어를 외워두면 타이핑 시간 절약

• 새로운 리소스를 접할 때 NAMESPACED 여부 확인 필수

• API 버전 정보는 YAML 파일 작성 시 참고

리소스 간 관계 이해

계층적 관계:

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가 생성하는 규칙들:

• KUBE-SERVICES: Service 목록과 기본 라우팅

• KUBE-NODEPORTS: NodePort 서비스 처리

• KUBE-SEP-xxx: Service Endpoint 개별 처리

• KUBE-SVC-xxx: Service 로드밸런싱

실제 규칙 예시:

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의 역할:

• Pod 간 네트워크 통신 제공

• 클러스터 내부 IP 주소 관리

• 네트워크 정책(NetworkPolicy) 구현

• 크로스 노드 통신 터널링

네트워크 플로우:

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

주의사항:

• Secret/ConfigMap 데이터가 클수록 메모리 사용량 증가

• 많은 수의 Secret을 생성할 때 노드 메모리 고려 필요

• 메모리 부족 시 Pod 스케줄링 실패 가능

로그 관리와 디스크 사용량

로그 파일 크기 관리:

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

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

로그 로테이션 설정:

• kubelet의 로그 로테이션 설정 확인

• 오래된 로그 파일 자동 정리 설정

• 디스크 사용량 모니터링 필수

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

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

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

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

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

4. 임시 복구 조치:

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

스케일링 전략:

• 수직 스케일링: Pod의 CPU/메모리 제한 증가

• 수평 스케일링: Pod 개수 증가 (HPA)

• 클러스터 스케일링: 노드 개수 증가

보안 및 네트워크 정책

기본 보안 체크리스트:

# 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. 운영 노하우: 효율적인 클러스터 관리와 모니터링 방법

지속적인 성장을 위한 제언

실무 적용 시 고려사항:

• 완벽한 이해보다는 문제 해결 능력에 집중

• 체계적인 문서화를 통한 지식 축적

• 실습 환경 유지를 통한 지속적인 실험과 학습

앞으로의 학습 방향:

• CI/CD 파이프라인: Kubernetes와 연계된 배포 자동화

• 모니터링 스택: Prometheus, Grafana 등의 관측 도구

• 보안 강화: Pod Security Standards, Network Policies

• 고가용성: Multi-zone, Multi-region 클러스터 구성

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

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

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