[kubernetes] #8 네임스페이스를 통해 컴포넌트 구성하기

서론

네임스페이스가 무엇인지, 어떻게 사용하는지 알아보자.

---

네임스페이스란? #1

 

네임스페이스는 쿠버네티스 클러스터 내부의 가상 클러스터라고 생각할 수 있다.

클러스터를 만들때, 쿠버네티스는 기본적인 4개의 네임스페이스를 제공한다.

kubectl get namespace

 

kubernetes-dashboard : minikube에만 기본적으로 생성되어있는 네임스페이스이다. 대시보드의 생성에 필요한 컴포넌트를 가지고 있다.

 

• default : 다른 네임스페이스가 없는 오브젝트(컴포넌트)를 위한 기본 네임스페이스이다. 
  
  
• kube-system : 쿠버네티스 시스템에서 생성한 오브젝트(시스템 프로세스)를 위한 네임스페이스이다. 사용자가 임의로 사용할 수 없다.
  
  
• kube-public : 공개적으로 접근할 수 있는 데이터가 포함된 네임스페이스이다. 클러스터 정보를 가지고 있는 configmap같은 컴포넌트를 가지고 있다.
  
  
• kube-node-lease : 노드의 hearbeat를 감지한다. 네임스페이스에는 각 노드와 연관된 lease 객체가 있다. 노드의 가용성을 판단한다.

 

네임스페이스 생성

kubectl create namespace my-namespace

 

---

네임스페이스 사용 이유

만약 당신이 default 네임스페이스만 가지고 있고, 당신이 생성한 모든 컴포넌트들이 default 네임스페이스에 포함된다고 가정해보자. 예를 들어 여러개의 Deloyment, Replicasets, Pods, Resources, ConfigMaps, Services, etc... 를 가지고 있는 복잡한 애플리케이션이 모두 default 네임스페이스에 포함된 것이다.

이런 상황이면 컴포넌트들을 관찰하기 매우 힘들 것이다. 다양한 유저들이 서버 내부에 자신만의 컴포넌트들을 생성하기 때문이다.

 

첫 번째 상황은 자원의 사용에 따라 네임스페이스를 구분해 줄 수 있다.

data와 관련된 컴포넌트들(ex. mongoDB)은 database 네임스페이스로 그룹화 해주고, 모니터링에 관련된 컴포넌트들(ex. 프로메테우스)은 Monitoring 네임스페이스로 그룹화 해주고, Elastic Stack에 포함되는 컴포넌트(ex. kibana, elastic search)들은 Elastic 네임스페이스에 그룹화 해준다.

 

쿠버네티스 공식문서에 따르면, 작은 프로젝트에는 네임스페이스를 사용하면 안된다.

10명 이상의 User(개발자를 의미한다)가 있는 프로젝트에서만 그룹화를 추천한다.

만약 그 정도의 user가 없다면 모두 default 네임스페이스에 넣는 것을 추천한다.

 

 

두 번째 상황은 많은 팀이 존재하고, 이름이 중복된 애플리케이션이 있는 경우이다.

A팀이 my-app 이라는 Deployment를 배포중이었다. 그런데 B팀도 my-app이라는 Deployment를 같은 네임스페이스에 배포해버리면, B팀의 my-app Deployment는 A팀의 my-app을 덮어씌어버리게 된다. 특히 jenkins 같은 빌드, 배포 자동화 도구를 사용한다면, B팀의 my-app이 A팀의 my-app을 덮어쓰기 하는지도 모른 채로 배포가 될 것이다.

따라서 각 팀은 각자의 이름에 맞는 네임스페이스에서만 작업을 하도록 권장된다.

 

 

세 번째 상황은 다른 클러스터에서 중복으로 사용되는 컴포넌트를 하나의 네임스페이스로 그룹화하는 경우이다.

이것과 관련된 문제 중 Blue/Green Deployment가 있다.

서로 다른 버전의 애플리케이션이 같은 설정파일(자원)을 사용할 때, 이들을 각각 네임스페이스로 구분할 수 있고, 자원의 재사용을 도모하는 방법이다.

 

 

네 번째 상황으로 자원의 접근과 사용에 제한을 두기 위해 네임스페이스를 설정할 수 있다.

A와 B팀이 각자의 네임스페이스를 가지고 있고, 각자의 네임스페이스 내부에서 컴포넌트의 create, delete 등의 활동을 하는 중이다. 하지만 A와 B 팀은 서로의 네임스페이스가 가진 자원을 사용할 수 없다. 절대적으로 자원의 사용을 제한하면서 독립적인 공간을 만들기 위함이다. 하지만 A팀이 자원을 너무 많이 사용해 버린다면 시스템의 자원은 한정되어있기 때문에 B팀은 자신들이 사용할 자원이 부족해지게 된다. 이와 같은 불공평한 상황을 해결하기 위해서 각각의 네임스페이스에 RAM, CPU 같은 자원을 임의로 할당해 줄 수 있다.

 

정리

1. 컴포넌트 구조의 통일성을 위해 사용한다.
2. 팀 간의 충돌을 방지하기 위해 사용한다.
3. 다른 환경에서 공통적으로 사용하는 자원을 그룹화 하기 위해 사용한다.
4. 네임스페이스 단계에서 자원의 사용을 제한하기 위해 사용한다.

---

네임스페이스의 특징

1. 다른 네임스페이스의 자원에 접근할 수 없다.

프로젝트 A는 ConfigMap을 가지고 있다. ConfigMap은 DB 네임스페이스의 database-service의 특정 정보를 참조하고 있다.

만약 프로젝트 B가 프로젝트 A의 ConfigMap에 접근해서 필요한 정보를 가져오려 한다면 접근이 금지된다. 만약 프로젝트 B도 ConfigMap을 생성해서 database-service의 정보를 참조하도록 한다면 정보를 사용할 수 있다.

 

2. 다른 네임스페이스의 서비스에 접근할 수 있다.

프로젝트 B 네임스페이스의 ConfigMap은 DB 네임스페이스의 database-service에 접근할 수 있다.

database의 이름이 mysql이라면 프로젝트 B의 ConfigMap.yaml 파일에는 위과 같이 mysql-service에 접근할 수 있다.

service의 이름이 url로 사용할 수 있기 때문에, 다른 네임스페이스에서 자유롭게 서비스를 참조할 수 있는 것이다.

 

3. 몇몇 컴포넌트는 네임스페이스를 가질 수 없다.

Volume 과 node에는 네임스페이스를 설정할 수 없다. 이들은 클러스터 전체에 상주하며, 독립적으로 사용할 수 없다. 

 

---

네임스페이스 설정방법

 

kubectl get configmap
# kubectl get configmap -n default

위 명령어는 클러스터의 default 네임스페이스에 있는 configmap을 가져온다는 뜻이다.

-n 옵션이 생략되면 기본적으로 default 네임스페이스의 컴포넌트를 가져온다.

 

# my-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-configmap
  namespace: my-namespace
data:
  db_url: mysql-service.database

네임스페이스 지정이 필요하면 yaml 파일의 metadata 부분에 namespace를 설정해 주는것이 좋다.

문서화에 도움이 되고, 더 편리하기 때문이다.

아래 코드처럼 kubectl 명령어의 옵션으로 네임스페이스를 따로 지정해 줄 수는 있지만 추천하는 방법이 아니다.

kubectl apply -f my-configmap.yaml --namespace=my-namespace

 

---

출처 : https://www.youtube.com/watch?v=X48VuDVv0do

번역 : 나

Chapter : Orginizing your components with K8s Namespaces