Run The Bridge

네임스페이스에 배포할 때, 특정 노드에만 배포하는 방법 본문

Cloud/k8s

네임스페이스에 배포할 때, 특정 노드에만 배포하는 방법

anfrhrl5555 2022. 12. 26. 22:46
728x90
반응형

Kubernetes Cluster를  운영하다 보면 개발, 스테이징, 운영 이렇게 나눠서 운영하는 경우가 매우 많다.

 

예시로 node1, node2, node3이 있다면 node1(개발), node2(스테이징), node3(운영)으로 지정할 텐데

 

node1에는 개발을 위한 Pod만 배포되어야 하고 node2, node3번도 각 역할에 맞게 앱들이 서비스되어야 한다.

 

물론 taint, toleration 설정을 해줘도 되지만, taint, toleration은 DaemonSet으로 배포된 Pod들도 설정해주어야 하는 번거로움이 존재한다.

 

우리는 그것보다 편한 네임스페이스를 구분하여 Pod들을 배포해 본다.


1. Node에 label 부여

먼저 나의 Cluster 구성은 worker01, 02, 03이 존재하고 01(개발), 02(스테이징), 03(운영) 이렇게 지정하였다.

NAME                                         STATUS   ROLES                  AGE    VERSION
p-iskim-cl-ext-acc-host-master               Ready    control-plane,master   54d    v1.23.8
p-iskim-cl-ext-acc-host-worker01             Ready    worker                 54d    v1.23.8
p-iskim-cl-ext-acc-host-worker02             Ready    worker                 54d    v1.23.8
p-iskim-cl-ext-acc-host-worker03.novalocal   Ready    worker                 7d6h   v1.23.8

그러면 먼저 각 Node에 label을 부여한다.

선언형으로 하지 않고, edit을 이용하여 Node에 직접 접근하여 추가했다.

    worker01: dev
    worker02: staging
    worker03: operation
    
p-iskim-cl-ext-acc-host-worker01            kubernetes.io/hostname=p-iskim-cl-ext-acc-host-worker01,node-role.kubernetes.io/worker=,worker01=dev
p-iskim-cl-ext-acc-host-worker02            kubernetes.io/hostname=p-iskim-cl-ext-acc-host-worker02,node-role.kubernetes.io/worker=,worker02=staging
p-iskim-cl-ext-acc-host-worker03.novalocal  kubernetes.io/hostname=p-iskim-cl-ext-acc-host-worker03.novalocal,node-role.kubernetes.io/worker=,worker03=operation

 

2. /etc/kubernetes/manifests/kube-apiserver.yaml 확인

아래 --enable-admission-plugins=PodNodeSelector가 추가되어야 한다.

  containers:
  - command:
    - kube-apiserver
    - --enable-admission-plugins=NodeRestriction,PodNodeSelector

PodNodeSelector 기능은 1.5 alpha부터 추가되었다고 문서에 나와있다.

 

3. namespace에 annotation 설정

dev, staging, operation이라는 네임스페이스를 생성했다.

dev → worker01: dev

staging worker02: staging

operation worker03: operation

kubectl get ns -o jsonpath='{.items[*].metadata.annotations}' | jq

jsonpath을 이용해 네임스페이스에 설정된 값을 확인할 수 있다.

 

4. 배포 테스트

아래 yaml에 namespace와 name만 바꿔서 배포를 테스트한다.

특정한 Node에 배포되는 것을  확인하기 위해 replicas를 10으로 조절한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-dev, nginx-staging, nginx-operation
  namespace: dev, staging, operation
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: base.registry.accordions.co.kr:5000/nginx:1.20.1-alpine
        name: nginx

모두 worker01번에 잘 배포되었다.

staging도 동일하게 worker02번에 배포되었다.

operation에도 worker03번에 집중되어 배포되었다.

※ 정리

PodSelector를 이용하여 taint, toleration 설정 없이 네임스페이스로 목적에 맞게 분기하여 Pod을 배포할 수 있었다.

 

운영하는 Cluster에 맞게 taint, toleration, nodeSelector, PodSelector 중 어떤 것을 사용할지 운영하는 환경에 맞추어 사용하면 된다.


※ 참고

https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podnodeselector

 

Admission Controllers Reference

This page provides an overview of Admission Controllers. What are they? An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authoriz

kubernetes.io

 

728x90
반응형
Comments