Kubernetes - Namespace, ResourceQuota, LimitRange (1)

Namespace, ResourceQuota, LimitRange - Kubernetes

이 글은 김태민님의 대세는 쿠버네티스 강의를 참고하여 정리하였습니다!

출처 : https://www.inflearn.com/course/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EA%B8%B0%EC%B4%88/dashboard

---

🔍 테스트해 볼 내용

1. Namespace 구성

2. ResourceQuota 구성

3. LimitRange 구성

   도커 이미지는 김태민님께서 만들어두신 이미지를 사용합니다.

   ---

   🤔 Why Use?

먼저 이와 같은 기술들은 공통된 한 공간에서 독립적인 공간으로 분리하기 위해서 만듭니다. 예를 들어, 한 Node에는 여러 공간의 Namespace가 존재할 수 있으며 Namespace안의 Pod들은 다른 Namespace의 존재 자체를 모르게 되죠.. 물론, Namespace로만 분리되지 않는 것이 있습니다.

또한, 여러 Namespace에는 여러 개의 Pod를 만들 수 있습니다. 각 Pod는 Cpu와 Memory같은 공유 자원을 사용하게 되는데, 한 Pod 혹은 한 Namespace에서 공유자원을 독차지하면 안되겠죠!

그래서 이번에 해볼것은 어떤 방식으로 자원을 할당할 수 있을지 실험해보려고 합니다!

🚀 Namespace

Namespace에서 같은 타입의 Object들은 이름이 중복될 수 없습니다. Pod마다 이름이 달라야하는 것과 같은 이유입니다.

즉, Object마다 별도의 uuid가 존재한다고 하여도, 같은 Object끼리는 이름 또한 uuid의 역할을 한다고 볼 수 있습니다.

또한, Namespace의 대표적인 특징은 타 Namespace와 분리가 된다는 것입니다.

지금부터, Namespace를 구성하고 Pod를 만들어봅시다!

ns1.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: ns-1

kubectl create -f ./ns1.yaml

kubectl apply -f ./ns1.yaml

Namespace가 만들어진 것을 확인하였습니다!

pod1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
  namespace: ns-1
  labels:
    app: pod
spec:
  containers:
  - name: container
    image: tmkube/app
    ports:
    - containerPort: 8080

kubectl create -f ./pod1.yaml

kubectl apply -f ./pod1.yaml

만들어둔 Namespace에 Pod가 만들어진 것을 확인하였습니다!

지금부터는
1. Service를 만들어봅시다.
2. Namespace를 하나 더 만들어 봅시다.
3. 어떤 것들이 분리되는지 대략 알아봅시다.
4. 분리되지 않는 것들을 알아봅시다.

이 순대로 실험을 진행해 보겠습니다.

service1.yaml

apiVersion: v1
kind: Service
metadata:
  name: svc-1
  namespace: ns-1
spec:
  selector:
    app: pod
  ports:
  - port: 9000
    targetPort: 8080

kubectl create -f ./service1.yaml

kubectl apply -f ./service1.yaml

Service또한 만들었습니다.

Namespace를 하나 더 만듭시다. 위의 과정에서 이름만 다르게 하면됩니다!

전 ns-2라는 이름의 namespace를 만들었습니다.

그렇다면, 분리되는 자원으로는 무엇이 있을지 확인해 봅시다!

ns-1에 같은 이름의 Pod를 하나 더 만들어 봅시다! 아까 만들어두었던 pod1.yaml을 사용하면 됩니다.

처음 부분에서 말했던것과 시피 이름이 중복되면 안된다는 것을 확인할 수 있습니다!

이제 ns-2에 service를 하나 더 만들어봅시다! service1.yaml에 namespace만 ns-2로 바꾸면 됩니다.

위의 그림에서 확인할 수 있는 것은 분명 똑같은 이름의 service인데 ns-2에서는 만들어진 것을 확인할 수 있습니다. 즉 Namespace는 Object를 분리시킬 수 있다는 것을 알 수 있습니다!

그에 대한 확인으로 대시보드를 확인해보도록 합시다!

ns-1에서의 service는 Pod가 연결되었고, ns-2에서는 Pod가 연결되지 않은 것을 볼 수 있습니다

지금 부터는 분리되지 않는 자원에 대해서 확인 해 봅시다!

ns-1과 ns-2에서의 각각의 service 와 pod의 IP를 알아봅시다.

이제 ns-2의 pod에 접속해 보도록 하겠습니다!

kubectl exec pod-1 -it /bin/bash

curl 명령어를 통해 ns-1의 pod와 ns-2의 pod에 모두 접근해보도록 하겠습니다!

curl 172.17.0.6:8080/hostname

curl 172.17.0.5:8080/hostname

보시는바와 같이 ns-2에서의 pod에서도 ns-1에서의 pod에 접근 가능한 것을 볼 수 있습니다. 이 말은 즉, IP 접속은 분리 되지 않는 다는 것을 볼 수 있습니다!

이제 각각의 namespace에 HostPath Volume Mount를 하는 pod들을 만들어 보도록 합시다!

ns-1 pod3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-2
  namespace: ns-1
spec:
  nodeSelector:
    kubernetes.io/hostname: minikube
  containers:
  - name: container
    image: tmkube/init
    volumeMounts:
    - name: host-path
      mountPath: /mount1
  volumes:
  - name: host-path
    hostPath:
      path: /node-v
      type: DirectoryOrCreate

ns-2 pod4.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-2
  namespace: ns-2
spec:
  nodeSelector:
    kubernetes.io/hostname: minikube
  containers:
  - name: container
    image: tmkube/init
    volumeMounts:
    - name: host-path
      mountPath: /mount1
  volumes:
  - name: host-path
    hostPath:
      path: /node-v
      type: DirectoryOrCreate

이제 ns-1의 pod에서 volume에 파일을 하나 만들고 ns-2의 pod에서 그 파일이 존재하나 확인해 봅시다.

빨간 박스는 namespace변경 부분을 의미합니다.

이것 또한, 보시는 바와 같이 Hostpath형태로 mount된 volume은 공유된다는 것을 볼 수 있습니다!

정리하자면,

• 분리되는 것
  1. Object
• 분리되지 않는 것
  1. IP주소 접근
  2. HostPath 형태의 Volume

이상으로 마치겠습니다. 🙋🏻‍♂️