Kubernetes Object 알아보기 1 - Pod, Namespace, Service, Deployment, ConfigMap, Secret, Ingress

서론

쿠버네티스에는 pod, namespace, service, deployment, configMap, secret, ingress 등 엄청나게 많은 Object들이 존재합니다. Kubernetes를 사용하려면 꼭 알아야 할 Object들에 대해서 상세히 알아볼 겸 본 포스팅을 작성합니다.

---

본론

1. Pod

Pod란?

• 쿠버네티스에서 가장 작은 배포 단위(Unit)입니다.
• 하나 이상의 컨테이너가 모여서 동작하는 논리적인 집합체입니다.
• 일반적으로 하나의 Pod에는 하나의 주 컨테이너가 들어가지만, 사이드카 컨테이너(예: 로그 수집, 프록시 등)를 함께 두는 경우도 많습니다.

언제/어떻게 사용하나?

• 실제 애플리케이션을 컨테이너 단위로 배포하고 실행할 때 사용합니다.
• 로그 수집 에이전트나 모니터링 에이전트를 같이 배포해야 하는 경우, 사이드카 컨테이너를 추가해 하나의 Pod로 묶어 관리합니다.
• Pod 자체로는 잘 사용하지 않고, 보통은 Deployment나 ReplicaSet 등의 상위 오브젝트로 관리합니다.

예시

1. nginx 웹 서버를 실행하는 컨테이너 1개와 로그 수집 에이전트(Fluentd 등)를 넣은 사이드카 컨테이너를 하나의 Pod로 구성하여 배포.
2. DB 마이그레이션 작업이 필요한 컨테이너를 임시로 Pod로 띄워 사용하는 경우.

---

2. Namespace

Namespace란?

• 하나의 쿠버네티스 클러스터에서 리소스(오브젝트)들을 논리적으로 구분해주는 가상 공간입니다.
• 팀 간, 개발·테스트·프로덕션 환경 간 자원을 분리하여 관리하기 위해 사용합니다.

언제/어떻게 사용하나?

• 여러 환경을 한 클러스터에서 분리해 운용할 때, 예: dev, test, stage, prod 네임스페이스를 분리하여 관리.
• 서로 다른 프로젝트 팀이 하나의 쿠버네티스 클러스터를 공유할 때, 각 팀의 자원을 안전하게 분리하여 충돌을 방지하고 리소스 제한을 적용할 때.

예시

1. 개발용 Namespace에서 자유롭게 테스트를 진행하고, 프로덕션용 Namespace에서만 실제 서비스를 운영.
2. 다수의 프로젝트가 동시에 진행되는 대규모 조직에서, 프로젝트별 네임스페이스를 만들어 접근 권한과 리소스 쿼터를 설정함.

---

3. Service

Service란?

• 쿠버네티스 클러스터 내부 또는 외부에서 Pod(들)에 접근하기 위한 네트워킹 오브젝트입니다.
• Pod가 동적으로 생성·종료되어도 변하지 않는 고정된 엔드포인트(IP, DNS 등)를 제공합니다.
• 대표적으로 ClusterIP, NodePort, LoadBalancer 타입을 많이 사용합니다.

언제/어떻게 사용하나?

• 서비스 내부 컴포넌트들 간 통신 시, Pod의 IP가 바뀌어도 접근 경로가 유지되어야 할 때.
• 외부에서 HTTP/HTTPS 요청을 받아 특정 Pod로 분산시키고 싶을 때(주로 LoadBalancer 타입 사용).
• NodePort로 각 노드의 특정 포트를 열어 간단히 외부와 통신할 때.

예시

1. ClusterIP 타입을 이용해 내부에서만 접근 가능한 DB 서비스나 내부 API 서비스 구성.
2. ALB, NLB와 같은 클라우드 로드밸런서와 연동을 위해 LoadBalancer 타입의 서비스를 생성해 웹 트래픽 처리를 담당.
3. 사설 환경에서 외부 로드밸런서 없이 NodePort를 활용해 임시 서비스 오픈.

---

4. Deployment

Deployment란?

• Pod와 ReplicaSet을 더욱 편리하게 관리하기 위한 쿠버네티스 오브젝트입니다.
• 선언형(Declarative)으로 원하는 스펙(컨테이너 이미지, Pod 개수 등)을 정의하고, Deployment가 ReplicaSet을 통해 Pod를 일관성 있게 유지합니다.
• 롤링 업데이트와 롤백 등, 애플리케이션 배포/업데이트 과정 전반을 책임집니다.

언제/어떻게 사용하나?

• 스케일링(확장/축소)을 간편하게 하고 싶을 때.
• 애플리케이션을 새 버전으로 무중단 업데이트(롤링 업데이트)하거나, 문제 발생 시 이전 버전으로 쉽게 되돌릴(롤백) 때.
• 지속적으로 업데이트가 필요한 웹/백엔드 애플리케이션을 구성할 때 일반적으로 사용합니다.

예시

1. Java Spring Boot 웹 애플리케이션의 Pod 3개를 운영하려고 할 때, replicas: 3으로 설정하여 Deployment 생성.
2. 최신 버전이 잘못 올라갔다면, 배포 이력을 이용해 간단히 이전 버전으로 롤백.
3. 트래픽 증가로 인한 확장 시, replicas 수를 늘려 빠르게 스케일 아웃.

---

5. ConfigMap

ConfigMap이란?

• 애플리케이션에 필요한 환경 설정값(환경 변수, 설정 파일 등)을 분리하여 관리하는 오브젝트입니다.
• Pod 스펙과 분리해서 환경 설정을 관리함으로써, 이미지 재빌드 없이 설정만 교체할 수 있도록 해줍니다.

언제/어떻게 사용하나?

• 개발·테스트·프로덕션 환경별로 다른 설정을 사용해야 할 때, 이미지는 동일하게 두고 ConfigMap만 교체.
• 애플리케이션 설정 파일(예: application.properties)을 쿠버네티스 설정으로 관리하면서, 지속적인 설정 변경이 필요한 경우.
• 외부 서비스 Endpoint, 포트 번호, 기타 플래그 등 자주 바뀌는 설정 요소를 코드에서 분리하고 싶을 때.

예시

1. Spring Boot 앱에서 DB 연결 정보를 application.properties 파일 대신 ConfigMap으로 관리.
2. Nginx의 설정 파일(nginx.conf)을 ConfigMap에 저장 후, 여러 Pod에서 공통 설정을 공유.
3. 다양한 API 엔드포인트 주소를 환경별로 분리하여 ConfigMap에 담고, Deployment에서는 해당 값을 참조.

---

6. Secret

Secret이란?

• ConfigMap과 유사한 형태지만, 민감한 정보를 안전하게 보관하기 위한 오브젝트입니다.
• 쿠버네티스 내부적으로 Base64 인코딩을 통해 저장되며, RBAC 설정 등을 통해 접근 제어가 이뤄집니다.

언제/어떻게 사용하나?

• 데이터베이스 비밀번호, API 키, 인증서, TLS 키 등 노출되면 안 되는 민감 정보를 관리할 때 사용합니다.
• Pod가 실행되면서 해당 Secret을 참조해 환경 변수나 볼륨 등으로 마운트해 사용.
• ConfigMap을 사용하기에는 민감도가 높은 경우 반드시 Secret 사용을 권장합니다.

예시

1. 외부 서비스 연동을 위한 API 토큰을 Secret으로 관리하고, 필요한 Pod에서 환경 변수로 주입.
2. TLS 인증서와 키를 Secret으로 관리하여 Ingress Controller 등에서 HTTPS 설정에 사용.
3. DB 접속 정보를 Secret에 담아 Pod 실행 시 참조해 보안성을 강화.

---

7. Ingress

Ingress란?

• 쿠버네티스 클러스터 외부의 HTTP/HTTPS 트래픽을 내부 서비스(Pod)로 라우팅하기 위한 오브젝트입니다.
• L7(애플리케이션 레벨)에서 트래픽을 분산하고, 도메인 기반 라우팅, SSL/TLS 종료 등의 기능을 제공합니다.
• Ingress Controller(Nginx, HAProxy, Istio Gateway 등)가 실제 트래픽 처리를 맡으며, Ingress는 그 라우팅 규칙을 정의합니다.

언제/어떻게 사용하나?

• 여러 서비스가 각각 다른 경로나 서브도메인을 통해서 하나의 로드밸런서 IP/도메인을 공유하여 외부에 노출될 때.
• HTTPS 종단(TLS Termination)을 수행하고, 내부 트래픽은 HTTP로 라우팅하고 싶을 때.
• 경로(/api, /images 등)에 따라 서로 다른 서비스로 트래픽을 분산하여 API Gateways 역할을 간단히 대체할 때.

예시

1. example.com 도메인을 통해 여러 백엔드 서비스를 연결: /api -> API 서비스, /auth -> 인증 서비스, /static -> 정적 파일 서비스 등.
2. 클라우드 환경에서 Nginx Ingress Controller 설치 후, SSL 인증서를 Secret으로 관리하여 HTTPS(443) 트래픽 처리.
3. Istio, Linkerd 등 Service Mesh 환경에서 Gateway(혹은 Ingress Controller)와 함께 내부 마이크로서비스로 트래픽 라우팅.

---

결론

쿠버네티스에는 정말 다양한 오브젝트들이 있고, 이 포스팅에서 다룬 Pod, Namespace, Service, Deployment, ConfigMap, Secret, Ingress는 가장 기초적이면서도 중요하게 다뤄지는 오브젝트들입니다.

• Pod: 하나 이상의 컨테이너가 동작하는 가장 작은 배포 단위로, 실제 실행 환경을 구성하는 기본 요소입니다.
• Namespace: 프로젝트나 환경을 논리적으로 구분할 수 있게 해주어 대규모 클러스터 운영 시 유용합니다.
• Service: 동적으로 생성·제거되는 Pod를 안정적으로 접근할 수 있는 네트워크 엔드포인트를 제공해 줍니다.
• Deployment: Pod와 ReplicaSet을 선언형으로 관리하여 롤링 업데이트, 롤백, 스케일링 등 중요한 배포 관련 기능을 간편하게 제공합니다.
• ConfigMap: 환경 설정 파일과 같은 비민감한 정보를 이미지와 분리하여 관리할 수 있습니다.
• Secret: 암호나 토큰, 인증서처럼 민감한 정보를 안전하게 관리하여 보안성을 높입니다.
• Ingress: 외부 트래픽을 내부 서비스로 라우팅하기 위한 L7 레벨의 설정을 정의합니다. 

 

이상으로 쿠버네티스의 주요 오브젝트에 대해 알아보았습니다. 각 오브젝트가 어떤 역할을 맡고, 언제 어떻게 사용하는지 이해하면, 더욱 체계적이고 유연한 클라우드 네이티브 인프라 운영이 가능해집니다. 향후에는 여기서 소개한 기본 오브젝트들을 기반으로 StatefulSet, DaemonSet, Job, CronJob 등 더 다양한 리소스도 살펴보고, Helm, ArgoCD 등의 배포 자동화 툴과 연계해 확장하는 포스팅도 진행해보도록 하겠습니다.