[Kubernetes] 쿠버네티스 namespace

<쿠버네티스 네임스페이스>

 

안녕하세요.
개발자김모씨입니다.

오늘도 쿠버네티스 이야기로 돌아왔습니다.

오늘 살펴볼 이야기는 쿠버네티스의 namespace 입니다!

---

namespace란?

우리는 저번 포스팅에서 쿠버네티스 클러스터 위에 pod을 올리는 것에 대해 보았습니다.
쿠버네티스 구조를 중심으로 다시 리마인드 해보자면,

출처 : https://blog.newrelic.com/engineering/what-is-kubernetes/

이처럼, 쿠버네티스의 워커 노드 위에 각 pod들이 배포되는 거죠.

여기서 문제!
용도와 목적이 다른 수많은 오브젝트들이 배포되면 어떻게 될까요?

쿠버네티스 오브젝트에서는 pod만 있는 것이 아니죠.
label, deployment, statefulset, secret 등 다양한 리소스가 있는데요.
그렇기 때문에 비슷한 이름의 오브젝트들이 수없이 많이 생길 것이고,
쿠버네티스 환경 운영자와 사용자는 관리와 사용 측면에서 어려움을 겪게 될 겁니다.

그래서 쿠버네티스에서는 namespce 라는 것을 제공하고 있습니다.
namespace란, 쿠버네티스 클러스터 내의 논리적인 분리 단위 입니다.
클러스터 내의 오브젝트들을 네임스페이스를 통해 논리적인 분리를 시키는 거죠.

그림으로 설명해보죠.

출처 : https://tommypagy.tistory.com/230

이처럼, 쿠버네티스 클러스터를 dev/stg/prd 세 개의 네임스페이스로 구분한 겁니다.
dev 목적의 사용자는 dev namespace에 접근하여 오브젝트를 배치 또는 운영하고,
stage 목적의 사용자는 stg namespace에 접근하여 운영하는 거죠.

여기서 주의해야할 것은 무엇이냐! 하면!

namespace는 클러스터를 논리적으로 분리하는 것이지, 물리적으로 분리하는 것은 아니다!

라는 겁니다.
다시 말해, isolation은 되지 않는다는 점이죠!
namespace는 쿠버네티스 오브젝트를 묶는 하나의 가상공간 또는 그룹입니다.
다른 namespace의 pod이더라도, 서로 통신이 가능할 뿐만 아니라
클러스터의 장애가 발생할 경우, 모든 namespace가 타격을 입게 되니
'namespace를 통한 fault-tolerance 확보'등은 이루어질 수 없습니다.
isolation을 원할 경우, 쿠버네티스 클러스터를 다중화/이중화 함으로써 해결해야 합니다.

---

namespace의 목적

그렇다면 namespace는 어떤 목적으로 사용될까요?

- 네임스페이스별 리소스 할당량 지정

출처 : https://bcho.tistory.com/category/%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C%20%EC%BB%B4%ED%93%A8%ED%8C%85%20%26%20NoSQL/%EB%8F%84%EC%BB%A4%20%26%20%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4?page=4

네임 스페이스를 통해 CPU/GPU 할당량을 조절할 수 있습니다.
전체 리소스가 CPU 500G, GPU 100G인 아주 빈약한 환경을 가정해보죠.
서비스의 운영 환경은 지연이 발생하지 않도록 매우 강력한 power와 리소스를 가져야 하지만,
개발과 신규 기능 및 수정 사항을 테스트 하기 위한 환경은 그 정도로 powerful할 필요가 없습니다.
그래서 dev/test/stage 로 namespace를 구분하고,
dev와 test namespace에는 각각 CPU 100, GPU 20씩,
stage namespace에는 CPU 300G, GPU 80G를 할당할 수 있습니다.
빈약한 환경 속에서도 최적의 개발 및 운영 환경을 구축하는 거죠!

 

- 사용자별 네임스페이스 접근 권한

Authorization이라고 하는 분야의 이야기죠. 권한관리는 Well-made 서비스를 위해 반드시 필요합니다.
쿠버네티스 클러스터의 api나 namespace에 접근하기 위해서,
유효한 사용자 인증(authentication)을 거치게 할 수 있습니다.
사용자 인증 후, 해당 사용자가 api 또는 namespace에 권한이 있는지 체크하고,
검증된 사용자만 api를 사용하게 하는 거죠.
일반적인 Authorization은 ABAC(Attribute-based access control)과 RBAC(Role-based access control)로 구분됩니다.
ABAC은 속성 기반의 권한 관리로, 사용자/그룹/요청 경로/네임스페이스 등으로 권한을 설정하는 거죠.
여기서 언급된 접근 권한은 ABAC을 의미합니다.
번외로, RBAC의 경우에는 역할 기반 권한 관리로, 사용자와 역할을 별개로 선언하고 둘을 binding 하여
사용자에게 권한을 부여하는 방식으로 구현됩니다.
일반적으로 RBAC이 더 많이 사용되긴 합니다만, ABAC도 가능하다는 점. 알아두자구요!

---

namespace의 사용

그럼 사용법을 알아봐야겠죠.

- namespace 생성

//test-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: test  
spec:
  limits:
  - default:
      cpu: 1
    defaultRequest:
      cpu: 0.5
    type: Container

test라는 namespace를 만드는 test-namespace.yaml 입니다.
kind를 Namespace로 두고 metadata에 네임스페이스 이름을 적어주면 됩니다.

이 namespace는 지금 cpu 자원의 limit을 지정했죠.
이처럼 spec부의 limits에서 리소스의 기본값과 상한값 등을 지정할 수 있습니다.

kubectl apply -f test-namespace.yaml

저번 포스팅에서 나왔던,
kubectl apply 명령어를 통해 네임스페이스를 만들 수 있죠.

또는,

kubectl create namespace test

kubectl create namespace 명령어를 통해 간단히 만들 수도 있습니다.

 

- namespace에 쿠버네티스 오브젝트 생성

우리가 기존에 배포하던 것은 default namespace 인데요.
test namespace를 만들었으니, 이 쪽에도 오브젝트를 생성해봐야겠죠.
저번 포스팅에서 나왔던 yaml을 다시 보죠.

//Pod 생성 예제 : sample-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  namespcae: test // --- namespace 지정
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

 

이처럼, metadata부에 namespace를 간단히 지정할 수 있죠.

그런 다음,

kubectl get pod -namespace test

이렇게, 뒤에 namespace를 지정해주면
해당 namespace의 쿠버네티스 오브젝트를 조회할 수 있습니다.

 

- namespace 삭제

삭제도 간단합니다.

kubectl delete namespace <이름>

이렇게 해주면, 해당 namespace와 쿠버네티스 오브젝트들이 삭제되고,
할당되있던 리소스들이 자동으로 해제됩니다.

 

---

오늘은 이렇게
쿠버네티스 네임스페이스에 관해 알아보았습니다.

namespace를 통해서
깔끔하고 안정적인 쿠버네티스 환경을 구현해봅시다~~~~~~~

 

오늘은, 여기까지!

구독과 댓글은 개발자김모씨에게 큰 힘이 됩니다.

 

감사합니당당당