일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- Podman
- 유산소
- 소모임
- 하체
- 달리기
- docker
- Shell
- Grafana
- 중식
- Kubernetes
- GitHub
- 성수대교
- 2021
- Linux
- 힐링
- 한강
- 대구
- Python
- 오답노트
- zabbix
- 러닝
- Run The Bridge
- DSEC
- 자전거
- 건대입구역
- 10km
- 대전
- 뚝섬유원지
- 정보처리기사
- 맛집
- Today
- Total
Run The Bridge
네임스페이스에 배포할 때, 특정 노드에만 배포하는 방법 본문
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
'Cloud > k8s' 카테고리의 다른 글
kubernetes 환경변수 N개 이상 Pod에 적용하는 방법 (0) | 2023.06.28 |
---|---|
kubectl config로 default namespace 변경 하는 방법 (1) | 2023.03.22 |
Calico CNI를 이용하여 Pod 고정 IP 할당하는 방법 (0) | 2022.08.02 |
kubectl apply, create, patch, replace 비교 (2) | 2022.03.20 |
사이드카 컨테이너 restart 테스트 (0) | 2022.03.13 |