Kubernetes Objects

Pod, Service, Volume, Configmap, Secret, Namespace, ResourceQuota, LimitRange에 대해 다루겠습니다.

1. 파드 (Pod)

• 정의: 쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 배포 단위

1. 파드 (Pod)의 특징

파드는 쿠버네티스에서 가장 기본이 되는 배포 단위이며, 하나 이상의 컨테이너를 포함합니다.

• 네트워킹: 파드 내의 컨테이너들은 동일한 네트워크 공간을 공유합니다. (하나의 호스트로 묶인 것과 유사)
  • 이 때문에 파드 내 컨테이너끼리는 localhost:8080를 통해 서로 접근할 수 있습니다.
• 포트: 컨테이너는 서비스 연결을 위한 포트를 가집니다.
  • 한 컨테이너가 여러 포트를 가질 수는 있지만, 한 파드 내에서 컨테이너 간 포트 번호는 중복될 수 없습니다.
• IP 주소 (휘발성):
  • 파드가 생성될 때마다 고유한 IP가 할당됩니다.
  • 이 IP는 클러스터 내부에서만 접근 가능하며, 외부에서는 직접 접근할 수 없습니다.
  • 파드에 문제가 생겨 삭제되고 다시 생성되면, IP 주소는 변경됩니다. (즉, IP는 고정적이지 않고 휘발성입니다.)

2. 라벨 (Label)

• 적용 대상: 파드뿐만 아니라 모든 오브젝트(노드, 서비스 등)에 붙일 수 있으며, 특히 파드에서 가장 많이 사용됩니다.
• 구조: 'Key'와 'Value'가 한 쌍으로 구성되며, 하나의 파드에 여러 개의 라벨을 붙일 수 있습니다.
• 연결 (Selector): 서비스(Service)와 같은 오브젝트가 특정 파드 그룹에 연결될 때, 셀렉터(Selector)에 라벨의 Key-Value 값을 지정합니다. 서비스는 이 셀렉터와 일치하는 라벨을 가진 파드들을 찾아 연결합니다.

3. 노드 스케줄링 (Node Scheduling)

방법 1: 직접 노드 선택 (수동)

• nodeSelector 사용: 관리자가 특정 노드에 라벨을 붙여두고, 파드를 생성할 때 nodeSelector 항목에 해당 노드의 라벨(Key-Value)과 일치하는 값을 지정하여 파드가 특정 노드에만 배치되도록 강제합니다.

방법 2: 쿠버네티스 스케줄러 (자동)

• 리소스 관리 (requests, limits): 파드 YAML 파일에 requests(최소 요구 자원)와 limits(최대 제한 자원)를 설정합니다.
  • 쿠버네티스 스케줄러는 이 정보를 바탕으로 파드를 실행하기에 가장 적합한(자원 여유가 있는) 노드를 자동으로 찾아 배치합니다.
  • 주요 목적: 특정 앱(파드)이 부하가 걸렸을 때 노드의 모든 자원을 독점하여 다른 파드나 노드 전체가 다운되는 것을 방지합니다.

---

 

2. 서비스 (Service)

 

 

서비스는 파드(Pod)로의 안정적인 접근을 제공하는 핵심 오브젝트입니다.

• 필요성: 파드는 생성, 삭제될 때마다 IP가 바뀌는 휘발성 특징이 있습니다. 이 때문에 파드의 IP로 직접 접근하는 것은 신뢰할 수 없습니다.
• 핵심 역할:
  1. 안정적인 IP 제공: 서비스는 고유하고 고정된 IP(Cluster IP)를 가집니다.
  2. 로드 밸런싱: 서비스에 여러 개의 파드를 연결하면, 서비스가 알아서 트래픽을 파드들에게 분산시켜 줍니다.

서비스는 type에 따라 파드에 접근하는 방식이 다릅니다.

1.  ClusterIP (기본값)

• 특징: 쿠버네티스 클러스터 내부에서만 접근 가능한 IP를 할당받습니다.
• 접근: 클러스터 외부에서는 이 IP로 접근이 불가능합니다.
• 설정: type을 생략하면 자동으로 ClusterIP 타입이 됩니다.
• 주 용도: 클러스터 내부의 다른 오브젝트(파드, 운영자 등)와의 통신

2.  NodePort

• 특징: ClusterIP의 모든 기능을 포함하면서, 추가로 모든 노드에 특정 포트를 개방합니다.
• 접근: [어느 노드의 IP든지]:[지정된 NodePort]로 접속하면, 해당 서비스에 연결된 파드로 트래픽이 전달됩니다.
• 주의점: 파드가 실행 중인 노드뿐만 아니라 '모든' 노드에 동일한 포트가 열립니다.
• 포트 범위: 30000 ~ 32767 사이의 포트만 사용 가능하며, 지정하지 않으면 이 범위 내에서 자동 할당됩니다.
• 주 용도:
  • 클러스터 외부, 하지만 내부망(사내망) 안에서 접근해야 할 때
  • 내부 개발 시스템을 외부에 임시 데모로 노출할 때 (예: 포트포워딩 연동)
• 옵션 (externalTrafficPolicy: Local): 이 값을 Local로 설정하면, 트래픽이 들어온 노드에 실행 중인 파드에게만 트래픽을 전달합니다. (네트워크 홉을 줄여 효율 향상)

3.  LoadBalancer

• 특징: NodePort의 모든 기능을 포함하며, 외부 IP 주소를 가진 로드밸런서를 생성합니다.
• 접근: 이 외부 IP를 통해 외부에서 서비스에 직접 접근할 수 있습니다. 이 로드밸런서가 각 노드의 NodePort로 트래픽을 분산시킵니다.
• 필수 조건:
  • GCP, AWS, Azure 등 클라우드 플랫폼의 쿠버네티스(GKE, EKS 등)를 사용하면 자동으로 외부 IP가 할당됩니다.
  • 직접 설치한 클러스터에서는 외부 IP를 할당해주는 별도 플러그인이 설치되어 있어야 합니다.
• 주 용도:
  • 외부(인터넷)에 서비스를 정식으로 노출할 때 사용합니다.
  • 내부 IP를 노출하지 않고 안정적으로 서비스를 운영할 수 있습니다.

---

3. 볼륨 (Volume)

 

 

 

1. emptyDir

이름 그대로 '빈 디렉토리'입니다. Pod가 생성될 때 함께 만들어지며, 이 볼륨은 항상 비어있는 상태로 시작합니다.

• 핵심 용도: Pod 내에 있는 여러 컨테이너 간의 데이터 공유
• 특징:
  • Pod 안에 있는 컨테이너들은 emptyDir 볼륨을 각자 원하는 경로(mountPath)로 마운트할 수 있습니다. 경로 이름이 달라도, YAML 파일에서 동일한 볼륨 이름을 참조하고 있다면 결국 같은 디렉토리를 바라보게 됩니다.
  • emptyDir 볼륨의 생명주기는 Pod의 생명주기와 일치합니다. 즉, Pod에 문제가 생겨서 재시작되거나 삭제되면, emptyDir 안의 데이터도 전부 사라집니다.

2. hostPath

hostPath는 이름처럼 Pod가 현재 스케줄링된 호스트(Node)의 실제 파일 시스템 경로를 볼륨으로 사용하는 방식입니다.

• emptyDir와의 차이점: 데이터가 Pod가 아닌 '노드'에 저장되기 때문에, Pod가 재시작되어도 데이터가 보존됩니다.
• 문제점 (스케줄링):
  1. 만약 'Node-1'에서 실행되던 Pod A가 hostPath로 'Node-1'의 /data/logs를 사용 중이었다고 가정해봅시다.
  2. 이 Pod A가 어떤 이유로 죽어서 재생성될 때, 쿠버네티스 스케줄러가 'Node-1'의 자원이 부족하다고 판단하면 'Node-2'에 Pod A를 띄울 수 있습니다.
  3. 이때 새로 생성된 Pod A는 'Node-2'의 /data/logs를 마운트하려고 시도합니다.
  4. 결과적으로 Pod A는 'Node-1'에 저장해둔 기존 로그 데이터에 접근할 수 없게 됩니다.
• 수동 해결책 (But 비추천): 굳이 이 문제를 해결하려면, 운영자가 직접 모든 노드(Node-1, Node-2, ...)에 동일한 경로(e.g., /data/logs)를 만들고, NFS 같은 별도의 마운트 기술을 사용해서 이 경로들을 수동으로 동기화해야 합니다. 하지만 이건 쿠버네티스가 관리해주는 역할이 아닙니다.
• 주의사항: hostPath로 지정한 경로는 Pod가 생성되기 전에 반드시 해당 노드에 미리 만들어져 있어야 에러가 발생하지 않습니다.

3. PV와 PVC

실제 운영 환경에서 영속적인 볼륨을 사용하는 표준 방식입니다.

Pod가 PV에 바로 연결하지 않고, 굳이 중간에 PVC를 두는 이유

-> '관리자' 영역과 '사용자' 영역을 분리하기 위함.

 

1. 관리자의 역할: PV생성

• 인프라 관리자는 실제 스토리지(NFS, EBS 등)를 설정하고, 이를 쿠버네티스에 PV 리소스로 등록해둡니다.
• "자, 여기 10GB짜리 빠른 SSD 스토리지(PV)가 준비됐어" 하고 **'공급'**해두는 것입니다.
• 이때 PV에는 용량(capacity), 접근 모드(accessModes - e.g., ReadWriteOnce) 등이 명시됩니다.

2. 사용자의 역할: PVC생성

• Pod를 배포하는 개발자는 실제 스토리지의 복잡한 설정을 몰라도 됩니다.
• "나 5GB 정도 용량에, 한 번에 한 Pod만 연결해서 쓸 볼륨이 필요해" 라는 '요청서'인 PVC만 생성합니다.

3. 쿠버네티스의 역할: 바인딩 

• 쿠버네티스가 사용자가 올린 PVC의 요청 사항을 확인합니다.
• 그리고 관리자가 미리 등록해둔 PV 목록 중에서 가장 적절한 PV를 찾아 PVC와 자동으로 연결시켜 줍니다.

4. Pod에서 사용

• 사용자는 Pod를 만들 때, 볼륨 설정에 PV 이름을 쓰는 게 아니라,PVC의 이름을 적어주기만 하면 됩니다.

 

 

Reference : https://inf.run/yW34