728x90
1. Pod
1) Pod란
Pod는 쿠버네티스에서 사용하는 가장 작은 배포 단위이자 컴퓨팅 단위로, 내부에 하나 이상의 컨테이너를 포함할 수 있다. 일반적으로는 하나의 Pod에 하나의 컨테이너를 실행하는 것이 권장되지만, 밀접하게 연관된 프로세스를 함께 실행해야 할 경우 복수의 컨테이너를 하나의 Pod 안에 둘 수도 있다.
2) Pod의 특징
- 고유 IP 할당: 각 Pod는 고유의 IP 주소를 가지며, Pod내부의 컨테이너 간 통신은 localhost를 통해 포트 기반으로 이루어짐
- 단일 노드 배포: 하나의 Pod는 반드시 하나의 노드에만 배포된다. Pod 내 컨테이너는 해당 노드에 같이 올라감
- 컨테이너 배포 단위: 쿠버네티스에서 컨테이너를 직접 다루지 않고, Pod 단위로 컨테이너를 관리하고 배포
3) Pod의 장점
- 밀접하게 연관된 프로세스를 하나의 단위로 실행 가능
- Pod 내부의 컨테이너들은 공통된 네트워크와 자원 공간을 공유하기 때문에, 마치 하나의 어플리케이션처럼 유기적으로 동작
- 동일한 환경 제공 + 부분적 격리 유지
- 격리된 컨테이너 환경을 유지하면서도, 공통의 네임스페이스를 공유해 높은 통신 효율성과 협업이 가능
4) Pod 내부 컨테이너 간 관계
공유 자원 | 설명 |
네트워크 네임스페이스 | Pod 내 컨테이너들은 동일한 IP와 포트 공간을 공유함→ localhost로 통신 가능→ 포트 충돌 위험 존재 |
UTS 네임스페이스 | 동일한 호스트 이름 공유 |
IPC 네임스페이스 | 프로세스 간 통신(IPC)을 통한 데이터 공유 가능 |
멀티 컨테이너 구조의 가장 큰 단점은 하나의 컨테이너가 장애를 일으켰을 때도 Pod 자체가 재시작되어 버리기 때문에 정상 동작 중인 컨테이너에도 문제가 생긴다.
💡 HPA : Horizontal Pod Autoscaler
쿠버네티스에서 Pod의 수를 자동으로 확장 또는 축소해주는 컨트롤러이다.
2. 네트워크 타입 (Network Namespace)
1) Shared Network Namespace
- 동일한 Pod 내의 컨테이너들은 하나의 IP 주소를 공유
- Loopback 인터페이스 공유 → localhost로 컨테이너 간 통신 가능
- 포트 충돌 위험이 있음 → 서로 다른 포트를 명시적으로 지정해야 함
- 주로 다음과 같은 보조 컨테이너 구성에 사용됨:
- 로그 수집기 (sidecar)
- 프록시 컨테이너
- 모니터링 도구 (Prometheus exporter 등)
2) Flat Inter Pod Network
- Kubernetes 클러스터의 모든 Pod는 하나의 Flat Network에 배치됨
- → Pod 간에 클러스터 내부 IP로 자유롭게 통신 가능
- 실제 구현은 CNI (Container Network Interface) 플러그인을 통해 수행
- 예: Calico, Flannel, Cilium, Weave 등
- Pod 단위로 고유 IP 부여됨
- Node 간 통신을 위해 오버레이 네트워크 계층이 구성될 수 있음
3. 생명주기
상태 | 설명 |
Pending | Pod가 생성되었지만 아직 스케줄링되지 않았거나, 이미지가 풀되지 않은 상태 |
Running | Pod가 스케줄된 노드에서 실행 중이며 하나 이상의 컨테이너가 실행 또는 재시작 중 |
Succeeded | Pod 내의 모든 컨테이너가 정상 종료됨 (종료 코드 0) |
Failed | 하나 이상의 컨테이너가 비정상 종료됨 (예: ExitCode 137 = OOM) |
Unknown | Pod 상태를 알 수 없음 (보통 노드와의 통신 불가 상태) |
4. 상태 확인 명령어
kubectl describe pods [POD 이름]
- Status : Pod의 상태 요약
- Containers : Container 정보
- Conditions : Pod의 현재 상태
1) Type
- Initialized : 모든 Container가 초기화 되어 성공적으로 실행
- Ready : Pod는 요청을 처리할 수 있음
- ContainersReady : 모든 Container가 준비 상태
- PodScheduled : Pod가 1개의 node로 Schedule 제출
- UnSchedulable : 스케쥴러 자원 부족 등으로 인해 Pod의 Schedule 제출 불가
2) Status
- True : 상태 활성화
- False : 상태 비활성화
- Unknown : 상태 알 수 없음
4. 네임스페이스
- 클러스터 내 리소스를 논리적으로 격리하기 위한 단위
- 복수 사용자 또는 복수 팀 환경에서의 리소스 충돌 방지를 위해 사용
- 네임스페잇 내에서 리소스 이름은 유일해야 하며, 네임스페이스 간에서 유일할 필요는 없음
- Deployment, Service 등의 오브젝트는 네임스페이스 기반이고, Node, PV, StorageClass는 클러스터 범위
- 동일한 네임스페이스 내에서 리소스를 구별하기 위해 레이블(label)을 사용
💡네임스페이스 vs 레이블
네임스페이스 : 쿠버네티스 클러스터 내에서 자원을 격리
레이블 : 네임스페이스 내에서 자원을 구분
기본적으로 존재하는 네임스페이스
- default : 기본 네임스페이스
- kube-system : 쿠버네티스 시스템에서 생성한 오브젝트를 위한 리소스
- kube-public : 자동으로 생성되며 모든 사용자가 읽기 권한을 접근 가능. 주로 전체 클러스터 중 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약된 네임스페이스
- kube-node-lease : 각 노드와 연관된 리스 오브젝트를 가짐. 노드 리스는 kublet이 하트비트를 보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 함
5. 템플릿 (Manifest)
- 쿠버네티스 리소스를 정의하는 선언형 구성 파일
- 주로 YAML 또는 JSON 형태로 작성
- 쿠버네티스는 실제 상태(desired state)를 유지하려 하므로 이 템플릿을 바탕으로 클러스터를 구성
6. 스케줄링
- kube-scheduler는 컨트롤 플레인 컴포넌트로, 어떤 Pod를 어떤 Node에 배치할지를 결정
- 자원 사용량, Node 상태, 우선순위, taint/toleration 등을 고려
7. Prob
- kubelet에 의해 주기적으로 수행되는 진단 프로그램
- 진단을 위해 kubelet은 컨테이너 내에서 코드를 수행하거나 네트워크 요청에 대한 전송을 주기적으로 실시
- 쿠버네티스는 자가 치유 능력을 극대화하기 위해 사용
- 기본적으로 쿠버네티스 클러스터는 파드의 상태를 모니터링하고 이상이 있으면 파드를 재기동시켜주지만, 파드가 서비스하는 상태를 지속적으로 점검하는 기능은 컨테이너 프로브를 사용해야함
💡 자가 치유 (Self-healing)
실패한 컨테이너를 다시 시작하고, 노드가 죽을 때 컨테이너를 교체 및 일정을 변경하고, 사용자 정의 상태 확인에 응답하지 않는 컨테이너를 종료하고 서비스를 제공할 준비가 될 때까지 클라이언트에게 알리지 않는다.
1) 핸들러 종류
kubelet은 컨테이너 상태 진단을 위해 핸들러를 호출하는데 핸들러는 수행하는 작업 분류에 따라 3가지로 나뉜다.
- exec : 통신을 위한 소켓이 없는 상황에서 특정한 프로그램을 계속 실행하여 리턴 코드를 판단
- tcpSocket : 웹 서버는 아니지만 통신이 가능한 경우 해당 포트로 요청을 하여 정상 통신이 가능한지 판단
- httpGet : 웹 서버가 존재하는 경우 특정 페이지에 요청을 지속적으로 하여 정상 통신이 가능한지 판단
2) 프로브 종류
- 활성 프로브(Liveness probe)
- 애플리케이션 상태를 체크해서 서버가 제대로 응답하는지 혹은 컨테이너가 제대로 동작중인지를 검사
- 파드는 정상적인 Running 상태지만 애플리케이션에 문제가 생겨 접속이 안되는 경우(ex. 메모리 오버플로우 등)을 감지
- 문제를 감지하면 파드를 죽이고 재실행하여 문제를 해결
- 애플리케이션이 데드락 상태에 머무르는 것을 감지하여 재시작시킬 때 유용
- 준비 프로브(Readiness probe)
- 컨테이너가 요청을 처리할 준비가 되었는지 확인하는 프로브.
- 파드가 새로 배포되고 Running 상태여도 처음 로딩 시간이 있어 그 동안은 접속하려 하면 오류가 발생하는데, 준비 프로브는 구동되기 전까지 서비스와 연결되지 않게 해줌
- 준비 프로브가 실패할 때 엔드포인트 컨트롤러가 파드에 연관된 모든 서비스들의 앤드포인트에서 파드의 IP 주소를 제거
- 프로브 핸들러 조건에 의해 실패하면 파드를 서비스로부터 제외시킴
- 프로브 성공한 경우만 파드에 트래픽 전송을 시작하는 경우에 사용
- 시작 프로브(Startup probe)
- 컨테이너 내의 애플리케이션이 시작되었는지를 확인
- 시작 프로브가 주어진 경우 성공할 때까지 다른 나머지 프로브는 활성화되지 않음
- 시작 프로브가 실패하면 kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에따라 처리됨
- 시작 프로브가 성공하고 나서 활성과 준비 프로브가 동작하기 때문에 기동시간이 불규칙적인 애플리케이션이 준비 프로브에 의해 기동되기 전에 재시작되는 것을 방지
✍️ 하루 회고
오늘은 쿠버네티스의 고급 개념에 대해 학습했다.
특히 네임스페이스는 다소 낯선 개념이라 수업 이후에 관련 문서를 찾아보며 추가적으로 리서치했다.
어제 배운 내용이랑 겹치는 내용도 많아서 복습하는 느낌으로 듣다보니 어느정도 체계가 잡혀가는 것 같다.
728x90
'TIL' 카테고리의 다른 글
[에스넷시스템 부트캠프] TIL Day 33 - ReplicationController, ReplicaSet, Deployment, RollingUpdate & RollingBack, Label, Selector, ConfigMap (0) | 2025.07.04 |
---|---|
[에스넷시스템 부트캠프] TIL Day 32 - 쿠버네티스 Pod 2 (0) | 2025.07.03 |
[에스넷시스템 부트캠프] TIL Day 30 - 쿠버네티스 아키텍처 (0) | 2025.07.01 |
[에스넷시스템 부트캠프] TIL Day 29 - Podman Volume, Compose, 쿠버네티스 (0) | 2025.06.30 |
[에스넷시스템 부트캠프] TIL Day 28 - Podman 명령어, 컨테이너 생명주기, 이미지 (0) | 2025.06.29 |