특징

• 우리는 default 네임스페이스 안에서 작업을 하고 있었다.

• 쿠버네티스의 기존 네임스페이스

  • default : "default " 네임스페이스는 자동으로 생성됩니다. 클러스터가 처음 kubernetes를 설정할 때 네트워킹 솔루션에 필요한 포드와 서비스 집합을 내부 목적으로 생성된다.
  • kube-system : 예를들어, DNS 서비스 같은, 그것들은 사용자로부터 이들을 실수로 삭제 못하게 다른 네임 스페이스(kube-system) 안에 생성한다.
  • kube-public : 모든사용자가 사용할 수 있어야하는, 리소스가 생성된다.

• 작은 클러스터로 쿠베를 이용하고 있을때는 네임스페이스 고민 없이, default 로 작업해라. 하지만, 엔터프라이즈 또는 프로덕션을 목적으로 쿠버네티스 클러스터를 확장하고 사용하려고 하면, 고유 네임스페이스 활용을 고려할 수 있다.

  • dev, real 환경에 대한 네임스페이스 분리
  • 예를 들어, dev, real 을 모두 동일한 클러스터를 이용하려고 하는 경우, 네임스페이스 분리가 가능하다.
  • 이를 통해, dev 에서 작업하는 동안 real 에서 리소스 실수를 안할 수 있다.

• 각 네임스페이스에는 누가 , 무엇을 할 수 있는지, 정의하는 고유한 정책 세트가 있을 수 있습니다. 각 네임스페이스가 보장하는 명명되는 공간 각각에 리소스를 할당할 수 있습니다. (resource limits)

  

• 네임스페이스 내의 리소스는 단순히 이름만으로 서로를 참조할 수 있다.
  • 예를 들어, db 에 연결하고 싶은 경우, mysql.connect("db-service") 만 이용하면 됨.
  • 다른 네임스페이스 에 있는 db-service 연동하고 싶은 경우, mysql.connect("db-service.dev.svc.cluster.local") 과 같이 , db 서비스가 될 servicename.namespace.svc.cluster.local 형식을 사용하면된다. (dns 항목과 유사하게 동작)

    • 서비스의 dns 이름을 자세히 살펴보면, 이 형식으로 자동으로 추가된다.

      

      • servicename.namespace.svc.cluster.local
        • svc.cluster.local: 쿠버네티스 클러스터의 기본 도메인 이름
        • svc : “서비스" 에 대한 하위 도메인
        • namespace : 네임 스페이스
        • servicename : 서비스이름 자체

name space 지정 방법

• -n=dev

  k apply -f pod.yaml --namespace=dev
  

• yaml 에 직접 지정 : metadata 에 지정해주면된다. (리소스가 항상 동일 네임스페이스에 생성되게 하는 좋은 방법)

  ...
  metadata:
  	name : myapp-pod
  	namespace: dev
  

namespace 생성방법

• apiVersion 이 v1 인 namespace 정의 파일을 사용해라.

# namespace-dev.yaml
apiVersion: v1
kind : Namespace
metadata:
	name : dev

# k apply -f namespace-dev.yaml

• cli 이용

k create namespace dev