728x90
이 글에서는 쿠버네티스 네임스페이스의 개념과 이를 활용한 효율적인 리소스 관리 방법에 대해 알아봅니다. MinIO와 Cilium을 포함한 다양한 워크로드를 논리적으로 분리하고 관리하는 전략부터 네임스페이스 간 통신 제어까지, 구체적인 예시와 함께 살펴보겠습니다.
📌 네임스페이스의 기본 개념과 필요성
✅ 네임스페이스란 무엇인가?
네임스페이스는 쿠버네티스 클러스터 내에서 리소스를 논리적으로 분리하는 가상 경계입니다. 동일한 물리적 클러스터를 여러 가상 클러스터로 나누어 사용할 수 있게 해주는 개념입니다.
▶️ 기본 네임스페이스:
# 클러스터의 기본 네임스페이스 확인
kubectl get namespaces
# 출력 예시:
NAME STATUS AGE
default Active 45d # 기본 네임스페이스
kube-node-lease Active 45d # 노드 상태 정보 저장
kube-public Active 45d # 공개 정보 저장
kube-system Active 45d # 시스템 컴포넌트용
▶️ 네임스페이스의 주요 역할:
- 동일한 이름의 리소스를 다른 네임스페이스에 생성 가능 (이름 충돌 방지)
- 리소스 격리 및 구성 관리
- 접근 제어 및 권한 관리
- 리소스 할당량 설정
✅ 네임스페이스가 필요한 상황
대규모 쿠버네티스 환경에서 네임스페이스는 다음과 같은 상황에서 특히 유용합니다:
▶️ 환경 분리: 개발, 테스트, 스테이징, 프로덕션 환경 구분
▶️ 팀/프로젝트 분리: 여러 팀이나 프로젝트가 동일한 클러스터 사용 시
▶️ 리소스 할당: 팀별/프로젝트별 리소스 사용량 제한
▶️ 액세스 제어: 세분화된 RBAC(역할 기반 접근 제어) 적용
# 개발 환경용 네임스페이스 생성 예시
apiVersion: v1 # Kubernetes API 버전
kind: Namespace # 리소스 종류: Namespace
metadata: # 메타데이터
name: dev-environment # 네임스페이스 이름
labels: # 라벨 설정
environment: development # 환경 라벨
team: storage-team # 팀 라벨
📌 네임스페이스 생성 및 관리
✅ 네임스페이스 생성 방법
네임스페이스를 생성하는 다양한 방법을 살펴보겠습니다:
▶️ YAML 파일을 통한 생성:
# minio-namespace.yaml
apiVersion: v1 # Kubernetes API 버전
kind: Namespace # 리소스 종류
metadata: # 메타데이터 섹션
name: minio-storage # 네임스페이스 이름
labels: # 라벨 정의
app: minio # 애플리케이션 라벨
type: storage # 타입 라벨
environment: production # 환경 라벨
# YAML 파일로 네임스페이스 생성
kubectl apply -f minio-namespace.yaml
▶️ 명령형 방식으로 생성:
# 간단한 네임스페이스 생성
kubectl create namespace minio-dev
# 라벨을 포함한 네임스페이스 생성
kubectl create namespace minio-test --labels=app=minio,environment=test
✅ 네임스페이스 관리 명령어
네임스페이스를 관리하기 위한 기본 kubectl 명령어:
# 모든 네임스페이스 조회
kubectl get namespaces
kubectl get ns # 축약형
# 특정 네임스페이스 세부 정보 확인
kubectl describe namespace minio-storage
# 현재 컨텍스트의 기본 네임스페이스 변경
kubectl config set-context --current --namespace=minio-storage
# 현재 컨텍스트 정보 확인
kubectl config get-contexts
# 네임스페이스 삭제 (주의: 내부 모든 리소스도 삭제됨)
kubectl delete namespace minio-dev
✅ 리소스 네임스페이스 지정
리소스 생성 시 네임스페이스를 지정하는 방법:
▶️ YAML 파일에 네임스페이스 지정:
# minio-deployment-namespaced.yaml
apiVersion: apps/v1 # Kubernetes API 버전
kind: Deployment # 리소스 종류
metadata: # 메타데이터 섹션
name: minio # Deployment 이름
namespace: minio-storage # 네임스페이스 지정
# ... 나머지 내용 생략 ...
▶️ 명령어로 네임스페이스 지정:
# 특정 네임스페이스에 리소스 생성
kubectl apply -f minio-deployment.yaml -n minio-storage
# 특정 네임스페이스의 리소스 조회
kubectl get pods -n minio-storage
kubectl get all -n minio-storage # 해당 네임스페이스의 모든 리소스 조회
▶️ 모든 네임스페이스의 리소스 조회:
# 모든 네임스페이스의 Pod 조회
kubectl get pods --all-namespaces
kubectl get pods -A # 축약형
📌 네임스페이스 구성 전략
✅ 환경별 네임스페이스 구성
다양한 환경을 네임스페이스로 구분하는 방법:
# 환경별 네임스페이스 생성
kubectl create namespace minio-dev --labels=environment=development
kubectl create namespace minio-staging --labels=environment=staging
kubectl create namespace minio-prod --labels=environment=production
▶️ 환경별 구성 이점:
- 개발 과정의 각 단계별 격리
- 각 환경에 맞는 리소스 할당 제어
- 권한 분리 (예: 프로덕션 네임스페이스에 제한된 접근 권한)
✅ 기능별 네임스페이스 구성
서비스나 기능에 따른 네임스페이스 분리:
# 기능별 네임스페이스 생성
kubectl create namespace storage --labels=function=storage
kubectl create namespace database --labels=function=database
kubectl create namespace monitoring --labels=function=monitoring
kubectl create namespace networking --labels=function=networking
▶️ 기능별 MinIO와 Cilium 배포 예시:
# storage 네임스페이스용 MinIO 배포
apiVersion: apps/v1 # Kubernetes API 버전
kind: Deployment # 리소스 종류
metadata: # 메타데이터
name: minio # Deployment 이름
namespace: storage # storage 네임스페이스 지정
# ... 나머지 내용 생략 ...
---
# networking 네임스페이스용 Cilium 구성
apiVersion: cilium.io/v2 # Cilium API 버전
kind: CiliumNetworkPolicy # Cilium 네트워크 정책
metadata: # 메타데이터
name: minio-access # 정책 이름
namespace: networking # networking 네임스페이스 지정
# ... 정책 내용 생략 ...
✅ 팀별 네임스페이스 구성
조직 내 팀 구조에 따른 네임스페이스 구성:
# 팀별 네임스페이스 생성
kubectl create namespace team-storage --labels=team=storage-team
kubectl create namespace team-backend --labels=team=backend-team
kubectl create namespace team-frontend --labels=team=frontend-team
kubectl create namespace team-data --labels=team=data-team
▶️ 팀별 구성 이점:
- 팀 간 리소스 충돌 방지
- 팀 단위 권한 관리 용이
- 팀별 리소스 사용량 모니터링
📌 네임스페이스 간 통신과 접근 제어
✅ 네임스페이스 간 서비스 통신
다른 네임스페이스의 서비스에 접근하는 방법:
▶️ 정규화된 도메인 이름(FQDN) 사용:
<서비스명>.<네임스페이스>.svc.cluster.local
# 다른 네임스페이스의 MinIO에 접근하는 Pod 예시
apiVersion: v1 # Kubernetes API 버전
kind: Pod # 리소스 종류
metadata: # 메타데이터
name: minio-client # Pod 이름
namespace: team-data # team-data 네임스페이스에 배포
spec: # Pod 스펙
containers: # 컨테이너 목록
- name: mc # 컨테이너 이름
image: minio/mc # MinIO 클라이언트 이미지
command: ["sleep", "3600"] # 임시 명령어(테스트용)
env: # 환경 변수 설정
- name: MINIO_SERVER # MinIO 서버 환경 변수
# 다른 네임스페이스의 MinIO 서비스 FQDN
value: "minio-service.storage.svc.cluster.local"
▶️ 서비스 디스커버리 테스트:
# 다른 네임스페이스의 서비스 접근 테스트
kubectl run -n team-data test-dns --image=busybox -it --rm -- nslookup minio-service.storage.svc.cluster.local
# 예상 출력:
# Name: minio-service.storage.svc.cluster.local
# Address: 10.96.x.y
✅ Cilium을 활용한 네임스페이스 간 접근 제어
Cilium 네트워크 정책을 사용해 네임스페이스 간 통신을 세밀하게 제어할 수 있습니다:
# Cilium 네트워크 정책으로 네임스페이스 간 접근 제어
apiVersion: cilium.io/v2 # Cilium API 버전
kind: CiliumNetworkPolicy # 리소스 종류
metadata: # 메타데이터
name: minio-cross-ns-access # 정책 이름
namespace: storage # storage 네임스페이스에 적용
spec: # 정책 스펙
endpointSelector: # 대상 엔드포인트 선택자
matchLabels: # 라벨 매칭
app: minio # MinIO Pod 선택
ingress: # 인그레스 규칙(들어오는 트래픽)
- fromEndpoints: # 출발지 엔드포인트
- matchLabels: # 라벨 매칭
k8s:io.kubernetes.pod.namespace: team-data # team-data 네임스페이스에서
app: data-processor # data-processor 앱에서 오는 트래픽만 허용
toPorts: # 포트 규칙
- ports: # 허용 포트 목록
- port: "9000" # MinIO API 포트
protocol: TCP # TCP 프로토콜
▶️ 네임스페이스 라벨 기반 정책:
# 네임스페이스 라벨 기반 Cilium 정책
apiVersion: cilium.io/v2 # Cilium API 버전
kind: CiliumNetworkPolicy # 리소스 종류
metadata: # 메타데이터
name: allow-from-development # 정책 이름
namespace: storage # storage 네임스페이스에 적용
spec: # 정책 스펙
endpointSelector: # 대상 엔드포인트
matchLabels: # 라벨 매칭
app: minio # MinIO Pod
ingress: # 인그레스 규칙
- fromEndpoints: # 출발지 엔드포인트
- matchLabels: # 라벨 매칭
# 'environment: development' 라벨이 있는 네임스페이스의 모든 Pod
k8s:io.kubernetes.pod.namespace: development
📌 리소스 관리와 할당량
✅ 네임스페이스별 리소스 할당량
ResourceQuota를 사용하여 네임스페이스 내 리소스 사용량을 제한할 수 있습니다:
# minio-namespace-quota.yaml
apiVersion: v1 # Kubernetes API 버전
kind: ResourceQuota # 리소스 종류: ResourceQuota
metadata: # 메타데이터 섹션
name: minio-quota # ResourceQuota 이름
namespace: storage # 적용할 네임스페이스
spec: # 할당량 스펙 정의
hard: # 하드 제한값 설정
# Pod 수 제한
pods: "10" # 최대 10개의 Pod 허용
# CPU 리소스 제한
requests.cpu: "4" # 요청 가능한 최대 CPU 합계: 4 코어
limits.cpu: "8" # 제한 가능한 최대 CPU 합계: 8 코어
# 메모리 리소스 제한
requests.memory: 8Gi # 요청 가능한 최대 메모리 합계: 8GB
limits.memory: 16Gi # 제한 가능한 최대 메모리 합계: 16GB
# 스토리지 리소스 제한
requests.storage: 100Gi # 요청 가능한 최대 스토리지 합계: 100GB
persistentvolumeclaims: "5" # 최대 5개의 PVC 허용
# 리소스 할당량 적용 및 확인
kubectl apply -f minio-namespace-quota.yaml
# 할당량 상태 확인
kubectl describe resourcequota minio-quota -n storage
# 출력 예시:
# Name: minio-quota
# Namespace: storage
# Resource Used Hard
# -------- ---- ----
# limits.cpu 2 8
# limits.memory 2Gi 16Gi
# pods 3 10
# ...
✅ 기본 리소스 제한 설정
LimitRange를 사용하여 네임스페이스 내 기본 리소스 제한을 설정할 수 있습니다:
# minio-limit-range.yaml
apiVersion: v1 # Kubernetes API 버전
kind: LimitRange # 리소스 종류: LimitRange
metadata: # 메타데이터 섹션
name: minio-limits # LimitRange 이름
namespace: storage # 적용할 네임스페이스
spec: # 스펙 정의
limits: # 제한 정의 시작
- type: Container # 컨테이너 타입 제한
default: # 기본 제한(명시적 설정 없을 때)
cpu: "500m" # CPU 제한: 0.5 코어
memory: "512Mi" # 메모리 제한: 512MB
defaultRequest: # 기본 요청(명시적 설정 없을 때)
cpu: "100m" # CPU 요청: 0.1 코어
memory: "256Mi" # 메모리 요청: 256MB
max: # 최대 허용값
cpu: "2" # 최대 CPU: 2 코어
memory: "2Gi" # 최대 메모리: 2GB
min: # 최소 허용값
cpu: "50m" # 최소 CPU: 0.05 코어
memory: "64Mi" # 최소 메모리: 64MB
# LimitRange 적용 및 확인
kubectl apply -f minio-limit-range.yaml
# LimitRange 상태 확인
kubectl describe limitrange minio-limits -n storage
✅ 네임스페이스별 리소스 사용량 모니터링
네임스페이스별 리소스 사용량을 모니터링하는 명령어:
# 네임스페이스별 리소스 사용량 확인
kubectl top pods -n storage # storage 네임스페이스의 Pod CPU/메모리 사용량
# 모든 네임스페이스의 리소스 사용량 확인
kubectl top pods --all-namespaces
# 네임스페이스별 노드 리소스 사용량
kubectl top nodes
📌 MinIO와 Cilium을 위한 네임스페이스 구성 예시
✅ 프로덕션 환경 네임스페이스 설계
실제 환경에서 MinIO와 Cilium을 위한 네임스페이스 구성 예시:
# 핵심 네임스페이스 생성
kubectl create namespace storage-prod # 프로덕션 스토리지
kubectl create namespace storage-backup # 백업 스토리지
kubectl create namespace network-policies # 네트워크 정책 관리
kubectl create namespace monitoring # 모니터링 시스템
▶️ 네임스페이스 분리의 이점:
- 관련 리소스 그룹화 및 관리 용이성
- 서비스별 세분화된 접근 제어
- 장애 격리 (한 네임스페이스의 문제가 다른 네임스페이스에 영향 최소화)
✅ MinIO 멀티 테넌트 설계
여러 사용자나 팀이 공유하는 MinIO 환경을 설계할 때 네임스페이스를 활용하는 방법:
# 팀별 MinIO 인스턴스 구성 예시
---
# 데이터 과학팀용 MinIO
apiVersion: v1 # Kubernetes API 버전
kind: Namespace # 리소스 종류
metadata: # 메타데이터
name: minio-datascience # 네임스페이스 이름
labels: # 라벨 설정
team: datascience # 팀 라벨
tier: storage # 계층 라벨
---
# 미디어 처리팀용 MinIO
apiVersion: v1 # Kubernetes API 버전
kind: Namespace # 리소스 종류
metadata: # 메타데이터
name: minio-media # 네임스페이스 이름
labels: # 라벨 설정
team: media # 팀 라벨
tier: storage # 계층 라벨
---
# 각 네임스페이스에 리소스 할당량 설정
apiVersion: v1 # Kubernetes API 버전
kind: ResourceQuota # 리소스 종류
metadata: # 메타데이터
name: storage-quota # 할당량 이름
namespace: minio-datascience # 데이터 과학팀 네임스페이스
spec: # 스펙 정의
hard: # 하드 제한
requests.storage: 500Gi # 스토리지 요청 제한
persistentvolumeclaims: "10" # PVC 개수 제한
✅ Cilium과 네임스페이스 통합
Cilium 네트워크 정책과 네임스페이스를 통합하여 다계층 보안 구현:
# 네임스페이스 선택적 접근 제어
apiVersion: cilium.io/v2 # Cilium API 버전
kind: CiliumNetworkPolicy # 리소스 종류
metadata: # 메타데이터
name: minio-namespace-access # 정책 이름
namespace: minio-media # 미디어 팀 네임스페이스에 적용
spec: # 정책 스펙
endpointSelector: # 대상 엔드포인트
matchLabels: # 라벨 매칭
app: minio # MinIO 애플리케이션 선택
ingress: # 인그레스 규칙
- fromEndpoints: # 허용할 출발지
- matchLabels: # 라벨 매칭
# 'team: media' 라벨이 있는 네임스페이스의 Pod
k8s:io.kubernetes.pod.namespace: media
# 또는 monitoring 네임스페이스의 모든 Pod
- matchLabels:
k8s:io.kubernetes.pod.namespace: monitoring
📌 네임스페이스 관리 모범 사례
✅ 명명 규칙 및 구조화
일관된 네임스페이스 관리를 위한 모범 사례:
▶️ 명명 규칙:
- 용도를 명확히 표현하는 이름 사용 (예: storage-prod, storage-dev)
- 팀/서비스/환경을 구분할 수 있는 접두사 사용
- 간결하고 명확한 이름 사용 (너무 긴 이름 지양)
▶️ 라벨링 전략:
# 효과적인 네임스페이스 라벨링 예시
apiVersion: v1 # Kubernetes API 버전
kind: Namespace # 리소스 종류
metadata: # 메타데이터
name: minio-prod # 네임스페이스 이름
labels: # 라벨 섹션
environment: production # 환경 구분
app: minio # 애플리케이션 유형
team: storage # 담당 팀
tier: backend # 시스템 계층
cost-center: infrastructure # 비용 센터
✅ 네임스페이스 간 통신 설계
네임스페이스 간 통신을 효과적으로 설계하는 방법:
▶️ 서비스 디스커버리 패턴:
- FQDN 사용 (예: service-name.namespace-name.svc.cluster.local)
- 공통 서비스는 별도의 공유 네임스페이스에 배치
- 서비스 메시나 API 게이트웨이를 통한 중앙화된 통신 관리
▶️ 통신 패턴 예시:
# 다른 네임스페이스의 MinIO에 접근하는 설정 예시
apiVersion: v1 # Kubernetes API 버전
kind: ConfigMap # 리소스 종류
metadata: # 메타데이터
name: app-config # ConfigMap 이름
namespace: application # 애플리케이션 네임스페이스
data: # 데이터 섹션
minio_endpoint: "http://minio-service.storage-prod.svc.cluster.local:9000" # MinIO 서비스 FQDN
# storage-prod 네임스페이스의 MinIO 서비스 참조
✅ 운영 자동화 및 관리
네임스페이스 관리 자동화를 위한 도구 및 전략:
▶️ GitOps 기반 네임스페이스 관리:
- 네임스페이스 정의를 코드로 관리 (Infrastructure as Code)
- CI/CD 파이프라인을 통한 네임스페이스 자동 생성 및 구성
- Argo CD 또는 Flux와 같은 GitOps 도구 활용
# 네임스페이스 자동 생성을 위한 예시 스크립트 (shell)
for env in dev staging prod; do
# 환경별 네임스페이스 생성
kubectl create namespace "minio-${env}" --dry-run=client -o yaml | \
kubectl apply -f -
# 기본 ResourceQuota 적용
kubectl apply -f "quota-${env}.yaml" -n "minio-${env}"
# 네임스페이스별 RBAC 설정
kubectl apply -f "rbac-${env}.yaml" -n "minio-${env}"
done
▶️ 모니터링 및 관리:
- 네임스페이스별 리소스 사용량 모니터링 대시보드 구성
- 네임스페이스 라이프사이클 관리 (생성부터 폐기까지)
- 네임스페이스 정리 정책 수립 (미사용 네임스페이스 식별 및 정리)
📌 Summary
쿠버네티스 네임스페이스에 대해 다음과 같은 주요 내용을 살펴보았습니다:
- 네임스페이스는 쿠버네티스 클러스터 내에서 리소스를 논리적으로 분리하는 가상 경계입니다
- 환경, 팀, 기능별로 네임스페이스를 구성하여 리소스를 효율적으로 관리할 수 있습니다
- ResourceQuota와 LimitRange를 통해 네임스페이스별 리소스 사용량을 제한할 수 있습니다
- Cilium 네트워크 정책을 활용하여 네임스페이스 간 통신을 세밀하게 제어할 수 있습니다
- 명명 규칙, 라벨링, 통신 설계, 운영 자동화 등의 모범 사례를 따르는 것이 중요
- MinIO와 Cilium을 효과적으로 운영하기 위해 네임스페이스를 활용한 멀티테넌트 설계가 가능합니다
- 네임스페이스 기반 관리는 복잡한 쿠버네티스 환경에서 리소스 격리와 조직화의 기본이 됩니다
728x90