[CKAD] Namespace

Namespace란?

• 쿠버네티스 클러스터 안에서 리소스를 논리적으로 구분하는 영역
• 같은 이름(예: Mark)이라도 '스미스 집', '윌리엄스 집'처럼 구분이 가능하듯, 네임스페이스는 리소스를 격리해 관리

---

목적

• 환경 분리: dev, staging, prod 등 운영 환경을 분리
• 팀/사용자별 리소스 격리: 특정 팀이 다른 팀의 리소스에 영향을 주지 않도록 분리
• 권한 관리: RBAC(Role-Based Access Control)과 연계
• 자원 제한: ResourceQuota를 통해 CPU/메모리 제한

---

기본 제공 Namespace

• default: 별도 지정이 없으면 여기에 리소스가 생성됨
• kube-system: 쿠버네티스 내부 컴포넌트(DNS, 네트워크 등)가 동작하는 영역
• kube-public: 모든 사용자 접근 가능, 공개 리소스 저장

개인/학습 환경에서는 default만 사용해도 무방
기업/프로덕션 환경에서는 dev, staging, prod 등으로 분리 운영 필수

---

Namespace와 DNS

• 같은 네임스페이스 내 서비스 접근 → 서비스 이름만으로 접근 가능
  • 예: db-service
• 다른 네임스페이스 서비스 접근 → 풀 도메인(FQDN) 필요
  • 예: db-service.dev.svc.cluster.local

구조:

<service>.<namespace>.svc.<cluster-domain>

---

Namespace 관련 명령어

목적	명령어	설명
네임스페이스 생성	kubectl create namespace dev	dev 네임스페이스 생성
YAML 기반 생성	kubectl create -f namespace-dev.yml	정의 파일 기반 생성
특정 네임스페이스에 리소스 생성	kubectl create -f pod.yml --namespace=dev	dev에 Pod 생성
네임스페이스 전환	kubectl config set-context --current --namespace=dev	기본 context 네임스페이스를 dev로 변경
특정 네임스페이스 리소스 확인	kubectl get pods --namespace=kube-system	kube-system의 Pod 확인
전체 네임스페이스 확인	kubectl get pods --all-namespaces	모든 네임스페이스의 Pod 확인
리소스 쿼터 생성	kubectl apply -f quota.yaml	자원 제한 설정

Namespace 장점

  1. 사용자별로 Namespace 접근 권한을 다르게 설정
2. Namespace별로 리소스 할당량을 지정(using ResourceQuota 사용)
3. Namepsace 별로 리소스(pod, Service...)를 나눠서 관리

Namespace 단점

  1. 물리적인 Cluster 분리가 아니므로 Cluster에 장애가 발생하면 모든 Namespace가 타격을 받음
2. 리소스를 생성할 때 반드시 Namespace 지정이 필요
- 반드시는 아니지만, 지정하지 않으면 default Namespace에서 리소스가 생성

출처: https://dobby-isfree.tistory.com/158 [지니 is 뭔들:티스토리]

---

kubectl Context란?

• 쿠버네티스 클러스터에 접속할 때 필요한 클러스터 + 사용자 + 네임스페이스 조합
• Context는 “내가 어느 클러스터를 어떤 사용자로, 어떤 네임스페이스에서 사용할지”를 나타내는 환경 설정 세트

구성 요소:

• Cluster: API 서버 주소 등 클러스터 정보
• User: 인증 계정 (인증서, 토큰 등)
• Namespace: 기본 적용 네임스페이스

---

ResourceQuota (리소스 할당량)

네임스페이스 단위로 자원 사용량을 제한하는 오브젝트

동작 방식

• ResourceQuota는 네임스페이스에 적용
• 해당 네임스페이스 내 모든 리소스의 CPU/메모리 총합 제한

예시 YAML

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "10"
    limits.memory: 20Gi

→ dev 네임스페이스에 Pod은 10개까지만, CPU는 최대 10코어, 메모리는 20GiB까지만 사용 가능

---

Imperative vs Declarative 방식

Declarative

• YAML 파일 작성 후 kubectl apply -f로 생성
• 운영 환경에서 주로 사용 (버전 관리, 일관성 유지)

Imperative

• CLI 명령으로 직접 리소스 생성
• 빠른 작업/시험 환경에서 유용

핵심 옵션

• --dry-run=client: 리소스를 실제 생성하지 않고 검증만
• -o yaml: YAML 정의 출력
• > file.yaml: 출력 결과를 파일로 저장

예시

kubectl run nginx --image=nginx --dry-run=client -o yaml > nginx-pod.yaml

→ 실제 생성은 하지 않고, Pod YAML 정의 파일만 생성

---

명령어 정리

리소스	기본 생성 명령어	YAML 출력 (템플릿 생성)	특징
Pod	kubectl run nginx --image=nginx	kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml	가장 기본 리소스
Deployment	kubectl create deployment nginx --image=nginx	kubectl create deployment nginx --image=nginx --dry-run=client -o yaml > deploy.yaml	ReplicaSet 자동 생성
Deployment 스케일링	kubectl scale deployment nginx --replicas=4	(YAML 수정 후 apply)	수평 확장/축소
Service (ClusterIP)	kubectl expose pod redis --port=6379 --name=redis-service	kubectl expose pod redis --port=6379 --name=redis-service --dry-run=client -o yaml > svc.yaml	기본 Service 유형
Service (NodePort)	kubectl create service nodeport nginx --tcp=80:80 --node-port=30080	kubectl create service nodeport nginx --tcp=80:80 --node-port=30080 --dry-run=client -o yaml > svc-nodeport.yaml	NodePort 지정 가능

---