📗 K8S, Namespace

🏳️‍🌈 [궁금한점]

• namespace 삭제를 정책적으로 방지
• namespace 별로 자원 사용량을 제한

---

🔗[목차]

• 네임 스페이스
  • 네임스페이스 생성 방법
  • 네임스페이스 용도 별 사용 사례
  • 네임스페이스 RBAC 적용
• 리소스 제한: ResourceQuota, LimitRange
  • 네임스페이스 한계
  • 리소스 쿼터 초과 허용 이유
  • 리소스 쿼터 실무 활용
  • 대안 (보다 정밀한 제어)
• 네임스페이스 삭제
  • 네임스페이스 삭제의 주요 위험
  • 실무에서 안전하게 다루는 방법
• RBAC 구성 방법
  • RBAC 구성 요소
  • RBAC 활용
    • 특정 네임스페이스에서 get, list만 허용
    • 네임스페이스 삭제 권한 제거
  • 바인딩 대상 종류

네임 스페이스

네임스페이스(Namespace)는 Kubernetes에서 리소스 격리와 다중 사용자/서비스 환경 관리를 위한 논리적 구획이다. 하나의 클러스터 안에서 여러 개의 독립된 "논리적 공간"을 만들어 팀, 프로젝트, 서비스 단위로 리소스를 구분해 사용할 수 있게 해준다.

• 네임스페이스 사용목적

목적	설명
자원 격리	서로 다른 서비스/팀 간 리소스를 분리하여 충돌 방지
접근 제어	네임스페이스별로 RBAC 설정 가능 (예: A팀은 A 네임스페이스만 접근 가능)
리소스 할당 제한	ResourceQuota를 통해 자원 할당량 제한 가능
관리 단순화	네임스페이스 단위로 리소스 보기, 삭제, 배포 등 간편 관리
테스트와 운영 분리	dev, test, prod 같은 환경별 격리 가능

• 기본 네임스페이스

이름	설명
default	기본 네임스페이스, 명시하지 않으면 여기에 생성됨
kube-system	Kubernetes 시스템 컴포넌트가 동작하는 영역 (kube-dns, coredns 등)
kube-public	모든 사용자가 읽을 수 있는 공개 영역 (거의 사용되지 않음)
kube-node-lease	노드 heartbeat 체크용 lease 객체 저장용 (v1.13+에서 추가됨)

• 네임스페이스 정의 기준

기준	설명	예시
서비스/애플리케이션 기준	서비스 단위로 분리	spark, trino, airflow, hms
팀/조직 기준	팀 또는 부서 단위 분리	data-engineering, ml-team
배포 환경 기준	dev/test/staging/prod 분리	dev-spark, prod-trino
보안 격리 기준	접근 제한이 필요한 경우	secure-data, compliance-zone

네임스페이스 생성 방법

apiVersion: v1
kind: Namespace
metadata:
  name: dev

네임스페이스 용도 별 사용 사례

활용 예	설명
team-a, team-b	팀 단위 분리 (RBAC + 리소스쿼터 적용)
airflow, spark, trino	컴포넌트 단위 격리
dev, stage, prod	배포 환경 분리
ci, cd	파이프라인용 네임스페이스 구분

네임스페이스 RBAC 적용

# RoleBinding 예시
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: trino-readonly
  namespace: trino
subjects:
- kind: User
  name: alice
roleRef:
  kind: Role
  name: view
  apiGroup: rbac.authorization.k8s.io

리소스 제한: ResourceQuota, LimitRange

• CPU, 메모리 요청/제한
• Pod 개수 제한
• PVC 개수 제한
• 특정 객체 개수 제한 (ConfigMap, Secret 등)

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

네임스페이스 한계

제한점	설명
클러스터 수준 자원은 격리 불가	노드, CRD, IngressClass 등은 네임스페이스와 무관
완벽한 보안 경계는 아님	보안적으로는 가상 클러스터(vCluster) 수준의 분리 필요
네임스페이스 이름은 클러스터 내 유일해야 함	중복 불가

Kubernetes에서는 네임스페이스별 ResourceQuota의 총합이 클러스터 전체 실제 자원을 초과해도 설정이 가능하다. "Quota 총합 ≤ 실제 자원"이라는 제한은 강제되지 않는다.
ResourceQuota는 자원 "보장"이 아닌 "제한"을 위한 메커니즘이기 때문이다.

예: 전체 노드 자원이 아래와 같다고 가정

총 노드 자원:

• CPU: 32코어
• Memory: 128Gi

예시로 잘못된 Quota 설정이 가능함

네임스페이스	CPU 쿼터	Memory 쿼터
spark	24	96Gi
trino	16	64Gi
airflow	8	32Gi

→ CPU 총합: 48코어, Memory 총합: 192Gi → 실제 자원보다 초과했지만 설정은 가능함.

리소스 쿼터 초과 허용 이유

이유	설명
리소스 할당은 "예약"이 아니라 "제한" 목적	실제 사용하지 않으면 문제 없음
리소스는 동적 사용됨 (Spark executor 등)	피크치로 계산할 경우 초과 가능
Quota는 네임스페이스 내부 제한용	다른 네임스페이스와 협의된 보장은 아님
리소스 스케줄링은 kube-scheduler가 담당	실제 노드에 자원이 없으면 Pending 상태 유지

리소스 쿼터 실무 활용

전략	설명
클러스터 총량보다 약간 여유롭게 할당	예: 총 자원의 80~90%만 네임스페이스 쿼터로 배분
Quota 합산 대시보드 구성	Prometheus + Grafana 또는 Kubecost에서 추적 가능
리소스 oversubscription 정책 문서화	예: Spark maxExecutor 수 제한 등
필요 시 LimitRange로 개별 Pod 제한	Quota는 네임스페이스 단위, 실제 사용은 Pod 단위

대안 (보다 정밀한 제어)

도구	기능
Kubecost	네임스페이스별 실사용 리소스 추적, Quota 초과 감지
OPA Gatekeeper	정책 기반으로 총합 초과 방지 가능 (예: Template 정책 작성)
Karmada / Hierarchical Namespace Controller	조직/하위 구조 기반 Quota 배분 가능

네임스페이스 삭제

Kubernetes에서 네임스페이스(Namespace) 를 삭제하면, 그 안에 존재하는 모든 리소스(Pod, Service, Deployment, PVC, ConfigMap 등) 가 함께 영구적으로 삭제된다. 이로 인해 다음과 같은 위험 요소가 존재한다.

네임스페이스 삭제의 주요 위험

위험 요소	설명
모든 리소스 삭제	네임스페이스 하위의 모든 리소스가 종속적으로 제거됨
복구 어려움	리소스를 복구하려면 백업이나 GitOps 등의 별도 이력이 필요
공유 리소스 삭제 위험	네임스페이스 안에 다른 팀 혹은 서비스가 함께 쓰던 리소스가 있으면 함께 삭제됨
종속 외부 리소스 손상	예: PVC 삭제 → 영속 스토리지까지 삭제될 수 있음 (스토리지Class 설정에 따라 다름)

실무에서 안전하게 다루는 방법

방법	설명
kubectl delete로 개별 리소스 삭제	네임스페이스 삭제 대신 리소스 타입별로 선택적 삭제 권장
네임스페이스 삭제 전 백업	kubectl get all --namespace=<ns> -o yaml > backup.yaml
GitOps 관리 사용	Argo CD, Flux 등을 사용해 선언적 상태에서 복원 가능하게 운영
Finalizer 확인	네임스페이스 삭제가 오래 걸릴 때는 finalizer 가 걸려 있는지 확인 필요
--wait=false 옵션 사용 자제	강제 삭제 시 일부 리소스가 유령처럼 남는 경우 있음

리소스 보호용 네임스페이스는 deletion 권한 제한

→ 예: admin만 삭제 가능하게 RBAC 구성

--dry-run=client로 사전 검토

→ 삭제 명령이 실제로 어떤 리소스를 제거하는지 시뮬레이션 가능

필요하시다면 네임스페이스 삭제 전에 리소스를 안전하게 정리하거나 백업하는 스크립트도 만들어드릴 수

RBAC 구성 방법

Kubernetes에서 RBAC(Role-Based Access Control) 은 사용자 또는 서비스 계정이 무엇을, 어디에서, 어떻게 할 수 있는지를 제어하는 핵심 보안 메커니즘이다.

RBAC 구성 요소

객체	설명
Role	특정 네임스페이스 내에서의 권한을 정의
ClusterRole	클러스터 전체 또는 여러 네임스페이스에 걸친 권한 정의
RoleBinding	Role을 사용자/그룹/서비스계정에 바인딩 (네임스페이스 한정)
ClusterRoleBinding	ClusterRole을 클러스터 전체에 바인딩

RBAC 활용

특정 네임스페이스에서 get, list만 허용

• role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: readonly-role
  namespace: my-namespace
rules:
  - apiGroups: [""]
    resources: ["pods", "services"]
    verbs: ["get", "list"]

• rolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: readonly-binding
  namespace: my-namespace
subjects:
  - kind: User
    name: alice@example.com   # 또는 kind: ServiceAccount
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: readonly-role
  apiGroup: rbac.authorization.k8s.io

네임스페이스 삭제 권한 제거

delete 권한을 뺀다. 또는 완전한 admin ClusterRole 대신 제한된 Role을 직접 정의해서 사용한다.

• 예: 네임스페이스 삭제 권한 제외한 Role

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: limited-admin
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps", "secrets"]
    verbs: ["get", "list", "create", "update", "patch", "delete"]
  - apiGroups: ["apps"]
    resources: ["deployments", "statefulsets"]
    verbs: ["*"]

그리고 이를 클러스터 수준 또는 특정 네임스페이스에 바인딩한다.

바인딩 대상 종류

kind	설명
User	kubectl 등으로 로그인한 사용자
Group	IDP 연동 시 사용자 그룹 (ex. OIDC)
ServiceAccount	Pod 내부에서 사용하는 인증 주체