1) About
일반적인 네임스페이스 개념과 동일하게 쿠버네티스도 네임스페이스 개념을 제공
별도의 네임스페이스를 지정하지 않으면 사용자가 가용한 쿠버네티스의 객체들은 모두 default 네임스페이스로 지정
일전의 설명에서 쿠버네티스의 기능들 역시 내부적으로 Pod와 서비스를 구성하는 형태로 네트워크 솔루션 및 DNS 서비스 등을 구성하게 되는데, 이와 같은 객체들은 사용자가 조작하면 안 되기 때문에 별도의 kube-system이라는 네임스페이스에 위치시켜 사용자와 분리
쿠버네티스가 만드는 네임스페이스 중에는 사용자가 쿠버네티스로부터 생성된 정보들을 사용할 수 있도록 공개된 kube-public이라는 네임스페이스도 존재
네임스페이스라는 개념은 단순히 쿠버네티스로 간단한 몇 개의 오케스트레이션만 했을 때는 default만으로 충분하겠지만, 기업 및 상업에서의 쿠버네티스 운용 시에는 네임스페이스를 반필수적으로 고려하게 됨
가장 간단하게는 개발 환경 (dev, prod)에 따라 네임스페이스 분리가 가능
예를 들어 default 네임스페이스의 db-service의 접근은 db.connect(”db-service”)와 같은 형태로 가능하고, dev라는 다른 네임스페이스에 접근은 db.connect(”db-service.dev.svc.cluster.local”)과 같은 형태로 가능
이와 같은 것이 가능한 이유는 서비스라는 객체를 생성할 때는 서비스에 해당하는 항목이 특정 포맷으로 DNS에 자동으로 등록되기 때문
** db-service (서비스 이름). dev (네임스페이스). svc (서비스). cluster.local (도메인)
노드 별로 네임스페이스가 분리되는 것이 아니라, 네임스페이스들은 논리적인 분리이므로 노드 자체는 공유를 하게 됨
이에 따라 네임스페이스에 따라 자원 할당량을 별도로 지정하는 것이 필요하고, 이러한 기능을 쿠버네티스가 제공
네임스페이스를 별도로 생성한 뒤, 해당 네임스페이스에 얼만큼의 자원량을 할당할지 ResourceQuota 객체를 생성하여 지정할 수 있음
2) YAML
Object
네임스페이스의 명시는 metadata의 하위 항목 (name 및 labels와 동일한 레벨)에 namespace로 명시할 수 있음
Namespace
apiVersion: v1, kind: Namespace
apiVersion: v1
kind: Namespace
metadata:
name: ns-sample
YAML
복사
ResourceQuota
apiVersion: v1, kind: ResourceQuota
apiVersion: v1
kind: ResourceQuota
metadata:
name: rq-sample
namespace: ns-sample
spec:
hard:
pods: "10"
requests.cpu: "4"
requests.memory: 5Gi
limits.cpu: "10"
limits.memory: 10Gi
YAML
복사
3) Commands
kubectl의 별도 네임스페이스 지정이 없다면 Default를 대상으로 API가 동작
kubectl get pod —namespace ${NAMESPACE}
네임스페이스에 해당하는 Pod들의 정보를 읽음
kubectl get pod —all-namespaces
모든 네임스페이스의 Pod 정보를 읽음
kubectl config set-context $(kubectl config current-context) —namespace=${NAMESPACE}
현재 Context의 네임스페이스를 지정하여 전환
4) Abbreviation
Namespace == ns