네임 스페이스 란 무엇입니까?

네임 스페이스는 Kubernetes 클러스터 내의 가상 클러스터로 생각할 수 있습니다. 단일 Kubernetes 클러스터 내에 여러 네임 스페이스가있을 수 있으며 모두 논리적으로 서로 격리되어 있습니다. 조직, 보안, 성능까지 귀하와 귀하의 팀을 도울 수 있습니다!

"기본"네임 스페이스

대부분의 Kubernetes 배포에서 클러스터는 "default"라는 네임 스페이스와 함께 기본 제공됩니다. 실제로 Kubernetes에는 기본, kube-system (Kubernetes 구성 요소에 사용됨) 및 kube-public (공용 리소스에 사용됨)의 세 가지 네임 스페이스가 실제로 있습니다. kube-public은 현재 많이 사용되지 않으며, 특히 Google Kubernetes Engine  (GKE) 과 같은 관리 형 시스템에서 kube-system을 그대로 두는 것이 좋습니다 . 이렇게하면 서비스 및 앱이 생성되는 위치로 기본 네임 스페이스가 유지됩니다.

이 네임 스페이스를 사용하기 위해 Kubernetes 도구가 기본적으로 설정되어 있으며 삭제할 수 없다는 점을 제외하면이 네임 스페이스에는 특별한 것이 없습니다. 시작 및 소규모 프로덕션 시스템에는 유용하지만 대규모 프로덕션 시스템에서는 사용하지 않는 것이 좋습니다. 팀이 다른 서비스를 인식하지 못한 채 실수로 덮어 쓰거나 중단하는 것이 매우 쉽기 때문입니다. 대신 여러 네임 스페이스를 만들고이를 사용하여 서비스를 관리 가능한 청크로 분할하십시오.

네임 스페이스 생성

네임 스페이스를 만드는 것을 두려워하지 마십시오. 성능 저하를 추가하지 않으며 대부분의 경우 Kubernetes API가 작업 할 더 작은 개체 집합을 가지므로 실제로 성능을 향상시킬 수 있습니다.

네임 스페이스 생성은 단일 명령으로 수행 할 수 있습니다. 'test'라는 네임 스페이스를 생성하려면 다음을 실행합니다.

kubectl create namespace test

또는 YAML 파일을 만들고 다른 Kubernetes 리소스와 마찬가지로 적용 할 수 있습니다.

test.yaml :

kind: Namespace
apiVersion: v1
metadata:
  name: test
  labels:
    name: test
kubectl apply -f test.yaml

네임 스페이스보기

다음 명령으로 모든 네임 스페이스를 볼 수 있습니다.

kubectl get namespace

세 개의 내장 네임 스페이스와 'test'라는 새로운 네임 스페이스를 볼 수 있습니다.

네임 스페이스에 리소스 생성

포드를 생성하는 간단한 YAML을 살펴 보겠습니다.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  labels:
    name: mypod
spec:
  containers:
  - name: mypod
    image: nginx

어디에도 네임 스페이스에 대한 언급이 없음을 알 수 있습니다. 이 파일에서`kubectl apply`를 실행하면 현재 활성 네임 스페이스에 포드가 생성됩니다. 변경하지 않는 한 "기본"네임 스페이스가됩니다.

리소스를 생성하려는 네임 스페이스를 Kubernetes에 명시 적으로 알리는 방법에는 두 가지가 있습니다.

한 가지 방법은 리소스를 만들 때 "namespace"플래그를 설정하는 것입니다.

kubectl apply -f pod.yaml --namespace=test

YAML 선언에 네임 스페이스를 지정할 수도 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: test
  labels:
    name: mypod
spec:
  containers:
  - name: mypod
    image: nginx

YAML 선언에 네임 스페이스를 지정하면 리소스가 항상 해당 네임 스페이스에 생성됩니다. "namespace"플래그를 사용하여 다른 네임 스페이스를 설정하려고하면 명령이 실패합니다.

네임 스페이스에서 리소스보기

포드를 찾으려고하면 찾을 수 없다는 것을 알 수 있습니다!

$ kubectl get pods
No resources found.

이는 모든 명령이 현재 활성화 된 네임 스페이스에 대해 실행되기 때문입니다. 포드를 찾으려면 '네임 스페이스'플래그를 사용해야합니다.

$ kubectl get pods --namespace=test
NAME      READY     STATUS    RESTARTS   AGE
mypod     1/1       Running   0          10s

특히 모든 것에 대해 자체 네임 스페이스를 사용하고 모든 명령에 대해 "네임 스페이스"플래그를 사용하고 싶지 않은 팀에서 작업하는 개발자 인 경우 이는 빠르게 성 가실 수 있습니다. 어떻게 고칠 수 있는지 봅시다.

활성 네임 스페이스 관리

기본적으로 활성 네임 스페이스는 "기본"네임 스페이스입니다. YAML에서 네임 스페이스를 지정하지 않는 한 모든 Kubernetes 명령은 활성 네임 스페이스를 사용합니다.

불행히도 kubectl을 사용하여 활성 네임 스페이스를 관리하는 것은 어려울 수 있습니다. 다행스럽게도 kubens (멋진 Ahmet Alp Balkan이 만든) 라는 정말 좋은 도구 가있어 산들 바람을 이룹니다 !

'kubens'명령을 실행하면 활성 네임 스페이스가 강조 표시된 모든 네임 스페이스가 표시되어야합니다.

활성 네임 스페이스를 'test'네임 스페이스로 전환하려면 다음을 실행하십시오.

kubens test

이제 'test'네임 스페이스가 활성화 된 것을 볼 수 있습니다.

이제 kubectl 명령을 실행하면 네임 스페이스가 'default'대신 'test'가됩니다! 즉, 테스트 네임 스페이스에서 포드를보기 위해 네임 스페이스 플래그가 필요하지 않습니다.

$ kubectl get pods
NAME      READY     STATUS    RESTARTS   AGE
mypod     1/1       Running   0          10m

네임 스페이스 간 통신

네임 스페이스는 서로 "숨겨져"있지만 기본적으로 완전히 격리되지는 않습니다. 한 네임 스페이스의 서비스는 다른 네임 스페이스의 서비스와 통신 할 수 있습니다. 예를 들어 네임 스페이스에있는 팀의 서비스가 다른 네임 스페이스에있는 다른 팀의 서비스와 통신하도록하는 경우 이는 종종 매우 유용 할 수 있습니다.

앱에서 Kubernetes sService에 액세스하려는 경우 기본 제공 DNS 서비스 검색을 사용하고 앱에서 서비스 이름을 가리킬 수 있습니다. 그러나 여러 네임 스페이스에서 동일한 이름으로 서비스를 만들 수 있습니다! 고맙게도 확장 된 형태의 DNS 주소를 사용하면 쉽게 해결할 수 있습니다.

Kubernetes의 서비스는 공통 DNS 패턴을 사용하여 엔드 포인트를 노출합니다. 다음과 같이 보입니다.

<Service Name>.<Namespace Name>.svc.cluster.local

일반적으로 서비스 이름 만 있으면 DNS가 자동으로 전체 주소로 확인됩니다. 그러나 다른 네임 스페이스의 서비스에 액세스해야하는 경우 서비스 이름과 네임 스페이스 이름을 사용하면됩니다.

예를 들어 "test"네임 스페이스의 "database"서비스에 연결하려는 경우 다음 주소를 사용할 수 있습니다.

database.test

"프로덕션"네임 스페이스의 "데이터베이스"서비스에 연결하려는 경우 다음 주소를 사용할 수 있습니다.

database.production

네임 스페이스 세분성(granularity)

내가받는 일반적인 질문은 생성 할 네임 스페이스의 수와 용도입니다. 관리 가능한 청크 란 정확히 무엇입니까? 네임 스페이스를 너무 많이 만들면 방해가되지만 너무 적게 만들면 이점을 놓치게됩니다.

답은 소규모 팀에서 성숙한 기업에 이르기까지 귀사의 프로젝트 또는 회사가 어느 단계에 있는지에 있다고 생각합니다. 각 단계에는 고유 한 조직 구조가 있습니다. 상황에 따라 관련 네임 스페이스 전략을 채택 할 수 있습니다.

소규모 팀

이 시나리오에서 여러분은 5 ~ 10 개의 마이크로 서비스를 작업하는 소규모 팀의 일원이며 모든 사람을 같은 공간으로 쉽게 데려 갈 수 있습니다. 

이 상황에서는 모든 프로덕션 서비스를 "기본"네임 스페이스로 시작하는 것이 좋습니다. 

멋지고 싶다면 "프로덕션"및 "개발"네임 스페이스를 원할 수 있지만 Minikube 와 같은 것을 사용하여 로컬 머신에서 개발 환경을 테스트하고있을 것 입니다 .

빠르게 성장하는 팀

이 시나리오에서는 10 개 이상의 마이크로 서비스를 작업하는 빠르게 성장하는 팀이 있습니다. 팀을 각각 자체 마이크로 서비스를 소유하는 여러 하위 팀으로 분할하기 시작했습니다. 

모든 사람이 전체 시스템의 작동 방식을 알고 있을 수 있지만 모든 변경 사항을 다른 사람과 조정하기가 점점 더 어려워지고 있습니다. 로컬 머신에서 전체 스택을 가동하려는 시도는 매일 더 복잡해지고 있습니다.

이 시점에서 프로덕션 및 개발을 위해 여러 클러스터 또는 네임 스페이스를 사용해야합니다. 각 팀은보다 쉬운 관리를 위해 자체 네임 스페이스를 선택할 수 있습니다.

대기업

대기업에서는 모든 사람이 다른 사람을 아는 것은 아닙니다. 팀은 다른 팀이 알지 못하는 기능에 대해 작업하고 있습니다. 팀은 서비스 계약을 사용하여 다른 마이크로 서비스 (예 : gRPC )와 통신하고 서비스 메시를 사용하여 통신 (예 : istio ) 을 조정합니다 . 

전체 스택을 로컬에서 실행하는 것은 불가능합니다. Kubernetes-aware Continuous Delivery 시스템 (예 : Spinnaker )을 사용하는 것이 좋습니다.

이 시점에서 각 팀에는 확실히 고유 한 네임 스페이스가 필요합니다. 각 팀은 개발 및 프로덕션 환경을 실행하기 위해 여러 네임 스페이스를 선택할 수도 있습니다. 

RBAC 및 ResourceQuotas를 설정하는 것도 좋은 생각입니다. 여러 클러스터가 이해되기 시작하지만 필요하지 않을 수 있습니다.

Enterprise

이 규모에서는 다른 그룹의 존재에 대해 알지 못하는 그룹이 있습니다. 그룹은 외부 회사 일 수도 있으며 서비스는 잘 문서화 된 API를 통해 사용됩니다. 각 그룹에는 여러 마이크로 서비스가있는 여러 팀이 있습니다. 위에서 언급 한 모든 도구를 사용해야합니다. 

사람들은 손으로 서비스를 배포해서는 안되며 소유하지 않은 네임 스페이스에서 잠가야합니다.

이 시점에서 잘못 구성된 애플리케이션의 폭발 반경을 줄이고 청구 및 리소스 관리를 더 쉽게하기 위해 여러 클러스터를 갖는 것이 합리적 일 것입니다.

결론

네임 스페이스는 Kubernetes 리소스를 구성하는 데 크게 도움이 될 수 있으며 팀의 속도를 높일 수 있습니다. 네임 스페이스에서 리소스를 잠그고 클러스터에 더 많은 보안 및 격리를 도입하는 방법을 보여줄 향후 Kubernetes 모범 사례 에피소드를 계속 지켜봐주십시오!