NameSpace 관리

요약

• 네임스페이스는 쿠버네티스에서 리소스를 논리적으로 구분하기 위해 사용하는 오브젝트이다. 파드, 레플리카셋, 디플로이먼트, 서비스와 같은 쿠버네티스 리소스들이 묶여있는 하나의 가상 공간이다.
• 리소스를 논리적으로 묶어서 가상 클러스터처럼 사용할 수 있다. 대부분 모니터링, 로드 밸런싱 인그레스 등을 위한 용도로 사용한다.
• 한편 네임스페이스에 속하지 않는 오브젝트도 있는데, 보통 클러스터 전반에 걸쳐 사용되어 특정 네임스페이스에서 관리되지 않아야 하는 노드 등이 있다.
• 특정 네임스페이스에 속하는 리소스는 다른 네임스페이스에서 직접 접근할 수 없으며, 네임스페이스의 이름을 통해서만 접근 가능하다.

 

네임스페이스의 사용 목적

 

네임스페이스는 쿠버네티스의 리소스를 논리적으로 구분하기 위해 사용한다. 다음과 같이 활용할 수 있다.

• 모니터링, 테스트, 로드 밸런싱 인그레스 등의 특정 목적을 위해 사용되는 리소스를 논리적인 그룹으로 묶어서 관리
• 개발 환경, 테스트 환경, 운영 환경 등에 대한 별도의 네임스페이스를 할당하여 환경 간 충돌을 방지하고 각각의 환경을 격리
• 여러 조직이 클러스터를 동시에 사용하는 경우, 조직마다 네임스페이스 생성하여 격리된 환경 제공

 

쿠버네티스에서는 다음과 같은 네임스페이스를 기본으로 제공한다.

• kube-system : 쿠버네티스 클러스터 구성에 필수적인 컴포넌트등과 설정값이 존재하는 네임스페이스이다. 마스터 노드에 있는 컨트롤 플레인 컴포넌트들이 이 네임스페이스에서 동작한다.
• kube-public : 모든 사용자가 접근할 수 있는 리소스들이 저장되는 네임스페이스이다.
• kube-node-lease : 노드 간의 lease 정보를 저장하는 네임스페이스이다. lease는 리소스에 대한 고유한 보유권을 나타내는 작은 오브젝트이다. 노드와 파드에 lease를 부여하여 중복 작업과 충돌을 막는다.
• default : 쿠버네티스 클러스터 내에서 생성된 모든 오브젝트들이 지정되지 않은 경우에 할당되는 기본 네임스페이스이다. 대부분의 쿠버네티스 오브젝트들이 이 네임스페이스에서 생성된다.

 

🌱 Note : 라벨 vs 네임스페이스

네임스페이스와 라벨은 리소스를 논리적으로 구별하기 위해 사용한다. 이 둘의 차이점은 네임스페이스는 리소스들을 논리적인 그룹으로 묶는 오브젝트인 반면, 라벨은 리소스에 대한 추가 정보를 제공하여 관리를 용이하게 해주는 역할을 하는 것이다. 그래서 네임스페이스는 라벨보다 더욱 넓은 용도로 사용할 수 있다. 네임스페이스를 통해서 격리된 리소스 그룹에 대해 다른 오브젝트나 기능을 적용할 수 있다. 특정 네임스페이스에 생성되는 파드의 자원 사용량을 제한하거나, 특정 네임스페이스에서 생성되는 파드에는 항상 사이드카 컨테이너를 붙이도록 설정한다.

 

네임스페이스 사용과 리소스 확인

 

🌱 yaml 파일로 네임스페이스 생성

apiVersion: v1
kind: Namespace
metadata:
  name: production

• yaml 파일로 생성 : kubectl apply -f production-namespace.yaml
• 이름으로 생성 : kubectl create namespace production
• 네임스페이스 확인 : kubectl get ns | grep production
• 네임스페이스 삭제 : kubectl delete namepace production

 

🌱 특정 네임스페이스에 리소스 생성

# 오랜만에 봤더니 기억이 잘 안나서 복습
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname-deployment-ns
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      name: my-nginx-pod
      labels:
        app: my-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

---

apiVersion: v1
kind: Service
metadata:
  name: hostname-svc-clusterip-ns
  namespace: production
spec:
  ports:
    - name: web-port
      port: 8080
      targetPort: 80
  selector:
    app: my-nginx
  type: ClusterIP

# 참고 - pod 생성 yaml 파일. Deployment 하위 template 항목에 동일한 정보를 작성한다.
apiVersion: v1 # 오브젝트 api 버전
kind: Pod # 리소스 종류
metadata: # 리소스의 부가정보
  name: my-nginx-pod
spec: # 리소스 생성을 위한 정보
  containers: # 컨테이너 정보
  - name: my-nginx-container # 컨테이너 이름
    image: nginx:latest # 이미지
    ports: # 컨테이너가 사용할 포트
    - containerPort: 80
      protocol: TCP

 

🌱 Deployment 생성 설정

• metadata.namespace : 이 서비스가 속하는 네임스페이스 선택
• spec.replicas : 동일한 파드를 몇개 유지시킬 것인지 설정한다.
• spec.template 아래의 내용 : 파드를 생성할 때 사용할 템플릿을 정의한다.
• spec.template.metadata : 디플로이먼트에서 생성하는 파드의 메타 정보를 작성한다.
• spec.template.spec.containers : 디플로이먼트에서 생성하는 파드를 설정한다. 컨테이너 이름, 이미지, 컨테이너가 사용할 포트와 같은 정보를 포함한다.

 

🌱 Service 생성 설정

• metadata.namespace : 이 서비스가 속하는 네임스페이스 선택
• spec.selector : 이 서비스를 통해 접근 가능한 파드를 선택
• spec.ports.port : 서비스가 받는 내부 IP로 개방할 포트
• spec.ports.targetPort : 연결된 파드가 내부적으로 사용하는 포트

 

🌱 네임스페이스 생성하고 확인

• 리소스 생성 : kubectl apply -f hostname-deploy-svc-ns.yaml
• 네임스페이스의 리소스 확인 : kubectl get pods,services -n production

NAME                                          READY   STATUS    RESTARTS   AGE
pod/hostname-deployment-ns-6964bcb8c4-7crxx   1/1     Running   0          57s
pod/hostname-deployment-ns-6964bcb8c4-kr9wn   1/1     Running   0          56s
pod/hostname-deployment-ns-6964bcb8c4-ldcbt   1/1     Running   0          56s

NAME                                TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
service/hostname-svc-clusterip-ns   ClusterIP   10.8.11.60   <none>        8080/TCP   56s

 

네임스페이스의 서비스 접근

 

6장에서 서비스를 공부할 때 클러스터 내부에서 서비스 이름을 통해 파드에 접근할 수 있다고 배웠다. 이것은 정확하게 말하자면 같은 네임스페이스 내의 서비스를 사용할 때 서비스 이름만으로 접근 가능하다는 말이다.

 

어떤 네임스페이스에 속하는 서비스는 다른 네임스페이스에서 서비스 이름으로 직접 접근할 수 없다. 왜냐하면 네임스페이스 안의 서비스는 고유한 이름을 가지는데, 다른 네임스페이스를 함께 고려하면 중복된 이름을 가지는 서비스가 존재할 수 있기 때문이다. 쉽게 생각해보면 절차지향 언어의 구조체나 객체지향 언어의 클래스도 동일한 원리를 사용한다. 구조체나 클래스는 변수나 메소드 같은 메모리를 하나의 논리적인 그룹으로 만들어 관리한다. 특정 클래스에 속하는 메소드를 사용하려면 어떤 클래스에 소속되는 메소드를 호출하는 것인지 참조 연산자를 사용해야 한다.

 

그렇다면 다른 네임스페이스에서 특정 네임스페이스의 서비스에 접근하려면 어떻게 해야할까? 구조체나 클래스와 마찬가지로 해당 서비스의 소속인 네임스페이스 이름을 함께 참조하면 된다. <서비스이름>.<네임스페이스이름>.svc으로 사용한다.

 

🌱 default 네임스페이스에서 production 네임스페이스에 있는 hostname-svc-clusterip-ns 서비스로 요청 보내기

curl hostname-svc-clusterip-ns.production.svc:8080 --silent | grep Hello

 

네임스페이스에 속하는 오브젝트 확인

🌱 네임스페이스에 속하는 오브젝트

파드, 서비스, 레플리카셋, 디플로이먼트는 네임스페이스에 속하는 오브젝트이다. 각 네임스페이스에 속하는 오브젝트는 다른 네임스페이스에서는 보이지 않는다.

 

속하는 오브젝트 확인 : kubectl api-resources --namespace=true