🚀 쿠버네티스 대탐험: Context와 Namespace 완전 정복 가이드 (CKAD 필수!)

안녕하세요! 쿠버네티스라는 거대한 우주를 항해하는 모든 개발자, 엔지니어 여러분! 👨‍🚀👩‍🚀

쿠버네티스 클러스터에 처음 접속하면 마치 광활한 우주에 홀로 떠 있는 기분이 들 수 있습니다. 수많은 별(리소스)들이 어디에 있는지, 내가 지금 어디쯤에서 명령을 내리고 있는지 헷갈리기 쉽죠.

 

이때 우리에게 든든한 나침반과 구획 지도가 되어주는 것이 바로 Context와 Namespace입니다. 특히 CKAD 같은 자격증 시험에서는 이 두 가지를 능숙하게 다루는 것이 합격의 첫걸음이라고 할 수 있습니다.

오늘은 쿠버네티스 작업의 효율과 안정성을 극대화하는 두 핵심 개념, Context와 Namespace에 대해 깊이 파고들어 보겠습니다!

 

---

🗺️ Namespace: 클러스터 안의 작은 나라들

Namespace는 하나의 물리적인 클러스터를 여러 개의 논리적인 단위로 나누어 사용하는 가상 클러스터입니다.

마치 하나의 커다란 대륙(쿠버네티스 클러스터) 안에 여러 나라(Namespace)가 존재하는 모습을 상상해 보세요. 각 나라에는 자신만의 국민(Pod, Service 등), 법률(Policy), 자원(Resource Quota)이 있습니다.

🤔 Namespace는 왜 필요할까요?

1. 리소스 격리 (Isolation) 🛡️
   • development, staging, production 환경을 분리하여 운영할 수 있습니다. development 팀이 실수로 production 환경의 서비스를 건드리는 끔찍한 사고를 막아주죠.
   • 여러 팀이 하나의 클러스터를 공유할 때, 팀별로 Namespace를 할당하여 서로의 리소스에 영향을 주지 않도록 할 수 있습니다. (예: team-a, team-b)
2. 이름 충돌 방지 (Name Scoping) 📛
   • Namespace가 없다면, 모든 리소스는 유일한 이름을 가져야 합니다. 하지만 Namespace를 사용하면, 각기 다른 Namespace 내에서는 같은 이름의 리소스를 생성할 수 있습니다. team-a의 database와 team-b의 database는 완전히 별개의 존재가 되는 것이죠.
3. 접근 제어 및 자원 할당 (Access Control & Resource Quota) 👮‍♂️
   • "A팀은 team-a Namespace에만 접근할 수 있다" 와 같은 세밀한 권한 설정(RBAC)이 가능해집니다.
   • "production Namespace는 CPU 10개, Memory 20Gi까지만 사용할 수 있다" 처럼 Namespace별로 자원 사용량을 제한(ResourceQuota)하여 특정 팀이 클러스터 전체의 리소스를 독점하는 것을 방지합니다.

⚙️ Namespace 핵심 명령어

쿠버네티스는 기본적으로 몇 개의 Namespace를 가지고 시작합니다.

• default: 특별히 지정하지 않으면 모든 리소스가 생성되는 기본 공간입니다.
• kube-system: 쿠버네티스 시스템 자체를 구성하는 핵심 컴포넌트(예: etcd, kube-dns)들이 실행되는 공간입니다. 절대 함부로 건드리면 안 됩니다!
• kube-public: 모든 사용자가 읽기 권한으로 접근할 수 있는 공개적인 공간입니다.

# 모든 Namespace 목록 확인하기
kubectl get namespaces
# 또는 kubectl get ns

# 특정 Namespace의 파드(pod) 목록 확인하기
kubectl get pods -n kube-system

# 새로운 Namespace 생성하기
kubectl create namespace dev-team

# Namespace 삭제하기 (주의! 내부의 모든 리소스가 함께 삭제됩니다)
kubectl delete namespace dev-team

 

꿀팁! 🍯 매번 -n <네임스페이스> 옵션을 붙이는 게 귀찮다면, 현재 작업할 기본 Namespace를 아예 변경할 수도 있습니다. 이 방법은 바로 다음에 설명할 Context와 관련이 깊습니다!

---

🧭 Context: 내가 서 있는 바로 그곳

Context는 어떤 클러스터에, 어떤 사용자 권한으로, 어떤 Namespace를 기본으로 작업할지 묶어놓은 설정 정보입니다.

kubeconfig 파일(~/.kube/config) 안에 저장되는 이 정보는 우리가 kubectl 명령어를 날릴 때 목적지를 정확히 알려주는 항법 장치와 같습니다.

Context는 세 가지 요소로 구성됩니다.

• Cluster 🌐: 어떤 쿠버네티스 클러스터 API 서버에 접속할지에 대한 정보입니다. (서버 주소, 인증서 등)
• User 👤: 해당 클러스터에 어떤 사용자의 권한으로 접근할지에 대한 정보입니다. (인증 토큰, 클라이언트 키 등)
• Namespace 🗺️: 해당 클러스터와 사용자 조합으로 접속했을 때, 기본으로 사용할 Namespace입니다.

즉, "나는 dev-cluster에 developer-A 계정으로 접속해서, 주로 team-a-ns Namespace에서 작업할 거야!" 라는 설정을 하나의 Context로 저장해 둘 수 있는 것입니다.

 

🤔 Context는 왜 중요할까요?

실무 환경에서는 개발용 클러스터, 운영용 클러스터, 테스트용 클러스터 등 여러 개의 클러스터를 동시에 관리하는 경우가 많습니다. 이때 Context를 사용하지 않는다면...

• 매번 kubectl 명령어에 --server, --client-key, --token, --namespace 등 수많은 옵션을 붙여야 합니다. 끔찍하죠. 😱
• 실수로 개발 클러스터에 적용해야 할 명령을 운영 클러스터에 날리는 대형 사고가 발생할 수 있습니다. 💥

Context를 사용하면, 단 한 줄의 명령어로 이 모든 접속 정보를 안전하고 빠르게 전환할 수 있습니다. CKAD 시험에서도 "문제 1번은 context-A에서, 문제 2번은 context-B에서 푸시오" 와 같은 요구사항이 명시적으로 주어지므로, Context 전환은 선택이 아닌 필수입니다.

 

⚙️ Context 핵심 명령어

# 현재 설정 파일에 있는 모든 Context 목록 확인하기
kubectl config get-contexts

# 현재 활성화된(사용 중인) Context 확인하기
kubectl config current-context

# 다른 Context로 전환하기 (CKAD 시험 필수 명령어!)
kubectl config use-context <전환할-context-이름>

# 현재 Context의 기본 Namespace만 변경하기
kubectl config set-context --current --namespace=<변경할-namespace-이름>

# 예시: 현재 Context의 기본 Namespace를 'dev-team'으로 변경
kubectl config set-context --current --namespace=dev-team
# 이제부터 'kubectl get pods'는 'kubectl get pods -n dev-team'과 동일하게 동작합니다!

---

✨ 정리하며: Namespace와 Context, 시너지를 만들다

• Namespace는 클러스터 내부를 나누는 논리적인 칸막이입니다.
• Context는 그 칸막이 중 어디로 들어갈지를 정하는 출입 카드와 같습니다.

이 두 가지를 잘 활용하면 복잡한 쿠버네티스 환경을 질서정연하게 관리하며, 실수 없이 안전하게 작업을 수행할 수 있습니다.

쿠버네티스 여정의 첫걸음, 이제 Context로 올바른 작업 환경을 설정하고, Namespace로 나만의 작업 공간을 만들어보세요. 여러분의 쿠버네티스 항해가 훨씬 더 순조로워질 것입니다!

---

Tags: 쿠버네티스, Kubernetes, CKAD, Namespace, Context, 데브옵스, DevOps, 클러스터 관리, kubectl, 인프라