[CKA] Kubernetes Namespace

Kubernetes Namespace

마크라는 이름의 두 소년이 있다. 그들을 구별하기 위해 우리는 그들을 성으로 부른다. 스미스와 윌리엄은 서로 다른 집에서 왔다. 물론 스미스와 윌리엄 집에는 다른 가족들이 있다. 집안에 있는 가족들은 단순히 그들의 이름으로 서로를 부른다. 예를 들어, 아버지는 마크 스미스를 단순히 마크라고 부른다. 그러나 아버지가 다른 집에 있는 마크를 부를때는 마크 윌리엄이라고 부를것이다. 이 집들 각각은 그들만의 규칙이 있다. 이 집들은 kubernetes의 네임스페이스에 해당한다. 지금까지 클러스터에 Pod Deployment Service와 같은 개체를 만들었다. 우리가 해왔던 것은 모두 네임스페이스 안에서 해왔다. 이 네임스페이스가 기본(default) 네임스페이스로 알려져 있고 자동으로 kubernetes가 생성될 때 클러스터가 처음 설정되면 네트워킹 솔루션에 필요한 것과 같은 내부 목적에 맞게 pod 및 service 집합을 생성한다.

DNS 서비스 등은 사용자로부터 격리하고 사용자가 실수로 삭제하거나 수정하는 것을 방지하기 위해 쿠버네티스가 클러스터 시작 시 생성된 다른 네임스페이스인 Kube system에 해당 클러스터를 생성한다. 세번째 자동으로 생성되는 네임스페이스는 Kube public이다. 여기서 모든 사용자가 사용할 수 있어야 하는 리소스가 생성된다. 환경이 작거나 소규모 클러스터를 학습하고 사용하는 경우 default 네임스페이스에서 계속 작업할 수 있고 네임스페이스에 대해 걱정할 필요가 없다. 그러나 기업 또는 프로덕션 목적으로 kubernetes 클러스터를 확장하고 사용할 때는 자신만의 네임스페이스를 만들 수 있으므로 네임스페이스를 사용하는 것을 고려할 수 있다. 예를 들어 ,개발 환경과 운영 환경 모두에 동일한 클러스터를 사용하면서도 리소스를 분리하려는 경우 각 클러스터에 대해 서로 다른 네임스페이스를 생성할 수 있다. 이렇게 하면 개발 환경에서 작업하는 동안 프로덕션에서 리소스를 실수로 수정하지 않는다.

이러한 네임스페이스 각각은 누가 무엇을 할 수 있는지 정의하는 고유한 정책 집합을 가질 수 있다. 또한 각 네임스페이스에 일정량이 보장되고 허용된 것보다 더 많이 사용하지 않는 각 명명된 공간에 리소스 할당량을 할당할 수 있다.
네임스페이스 내의 리소스는 단순히 이름으로 서로를 참조할 수 있다.

예를들어 웹 앱 Pod은 필요한 경우 호스트 이름 db 서비스를 사용하여 단순히 db 서비스에 도달할 수 있다.
웹 앱 Pod는 다른 네임스페이스의 서비스에 연결할 수도 있다. 이렇게 하려면 네임스페이스 이름을 서비스 이름에 추가해야 한다.
예를 들어 기본 네임스페이스의 웹 Pod가 개발 환경 또는 네임스페이스나 데이터베이스에 연결할 수 있다. servicename.namespace.svc.cluster.local 형식을 사용한다.

db-service.dev.svc.cluster.local은 서비스가 생성될 때 서비스의 DNS 이름을 자세히 보고 이 형식으로 DNS 항목이 자동으로 추가되므로 이 작업을 수행할 수 있다. 마지막 부분 cluster.local은 kubernetes 클러스터의 기본 도메인 이름이다. svc는 서비스의 하위 도메인이다. 서비스 다음에 네임스페이스가 오고 그 다음 서비스 자체의 이름이 온다.

$ kubectl get pods

이제 네임스페이스의 몇 가지 운영 측면을 살펴보자. kube control 명령어를 알아보자. 예를 들어 이 명령은 모든 pod를 나열하는 데 사용되지만 default 네임스페이스의 pod 만 나열된다.

$ kubectl get pods --namespace=kubesystem

다른 네임스페이스(ex. Kube-system)의 pod를 나열하려면 네임스페이스 옵션을 네임스페이스 이름과 함께 사용한다.

# pod-definition.yaml
apiVersion: v1
kind:Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: front-end
spec:
  containers:
  - name: nginx-container
    image: nginx

파일을 사용하여 pod를 생성할 때 pod 정의 파일이 있다.

$ kubectl create -f pod-definition.yaml

파일을 사용하여 pod를 생성할 때 pod 정의 파일을 옵션으로 주고 생성한다. default 네임스페이스에 pod가 생성된다.

$ kubectl create -f pod-definition.yaml --namespace=dev

이 pod가 항상 개발 환경에서 생성되도록 하려면 네임스페이스 옵션을 사용하면 된다.

# pod-definition.yaml
apiVersion: v1
kind:Pod
metadata:
  name: myapp-pod
  namespace: dev
  labels:
    app: myapp
    type: front-end
spec:
  containers:
  - name: nginx-container
    image: nginx

명령줄에서 네임스페이스를 지정하지 않더라도 네임스페이스 정의를 다음과 같이 메타데이터 섹션 아래 Pod 정의 파일로 이동할 수 있다. 이것은 리소스가 항상 동일한 네임스페이스에 생성되도록 하는 좋은 방법이다.

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

그러면 다른 개체처럼 새로운 네임스페이스를 어떻게 만들까? API 버전은 v1이고 kind는 Namespace인 네임스페이스 정의 파일을 사용한다. 메타데이터에서 이름을 지정한다.

$ kubectl create -f namespace-dev.yml

Kube control create 명령을 실행하여 네임스페이스를 만든다.

$ kubectl create namespace dev

네임스페이스를 만드는 또 다른 방법은 단순히 Kube control 명령을 실행하는 것이다.

kubectl get pods 명령을 사용하면 default 네임스페이스 내부의 리소스를 확인하고 ,dev 네임스페이스의 리소스를 보려면 namespace 옵션을 사용해야한다. 하지만 더 이상 namespace 옵션을 지정할 필요가 없도록 dev namespace로 영구적으로 전환하려면 어떻게 해야 할까?

$  kubectl config set-context $(kubectl config current-context) --namespace=dev

이 경우 Kube control config 명령을 사용하여 현재 컨텍스트에서 네임스페이스를 설정한다. 그런 다음 네임스페이스 옵션 없이 Kube control get pods 명령으로 간단히 dev 환경에서 pod를 나열할 수 있다. 대신 default 또는 prod와 같은 다른 환경에 대한 옵션을 지정해야 한다. 마찬가지로 prod 네임스페이스로 전환할 수 있다. context는 동일한 관리 시스템에서 여러 환경의 여러 클러스터를 관리하는 데 사용된다.

$ kubectl get pods --all-namespaces

마지막으로 모든 네임스페이스의 pod를 보려면 명령의 all 네임스페이스 옵션을 사용한다. 모든 네임스페이스의 모든 pod가 나열된다.

# Compute-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: dev
spec:
  hard:
    pods: “10"
    requests.cpu: “4"
    requests.memory: 5Gi
    limits.cpu: “10"
    limits.memory: 10Gi

네임스페이스의 자원을 제한하기 위해 리소스 할당량을 정하여 생성할 수도 있다. 리소스 할당량에 대한 정의 파일로 시작하여 할당량을 생성할 네임스페이스를 지정한 다음 규격에서 10 pod 10 CPU 단위 10GB 메모리와 같은 제한을 제공한다.








출처:
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14295510#overview