갬미의 성장일기
Day 44 - 도커/쿠버네티스 포트포워딩, Replica Set 본문
오늘 배운 내용
- 포트포워딩
- 쿠버네티스 Replica Set
포트포워딩
포트 포워딩은 외부 주소와 내부 주소를 이어주는 역할을 한다.
예를 들어 mysql 서비스가 3306 포트에서 돌고있다고 가정하고 3307:3306 으로 포트포워딩을 한다면
사용자가 3307포트로 접속했을때 3306 포트에서 운영되고 있는 mysql에 접속하도록 하겠다는 말이다
mysql pod를 만들 yml을 만든다
apiVersion: v1
kind: Pod
metadata:
name: mysql
labels:
app: db
spec:
containers:
- name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: frodo
- name: MYSQL_DATABASE
value: frodo
- name: MYSQL_USER
value: frodo
- name: MYSQL_PASSWORD
value: frodo
- name: MYSQL_ROOT_HOST
value: '%'
image: mysql:5.7
ports:
- containerPort: 3306
여기에 적힌 ports는 그저 '설명'의 용도이며 이 포트를 바꾼다고 해도 mysql은 기본 설정 포트인 3306에서 운영된다
cnf에서 listen 포트를 바꿔주어야지 사용하는 포트가 바뀌는것이다 -> 냅다 run/yml에서 바꾼다고 포트가 변경되지 않음
nginx를 예로 들면
nginx - /etc/nginx/conf.d/*.conf 에 listen port 가 running port
이걸 바꾸어주지 않는 이상 80으로 돈다
yaml이나 run 에서 지정하는 port는 discript에 불과함 진짜로 도는것은 conf에서 설정
== 이미지에서 변경하기 전까지는 변경되지 않는다
쿠버네티스 컴포넌트와 Replica Set
쿠버네티스 클러스터의 구성은 다음과 같다
각 컴포넌트의 책임은 다음과 같다.
- api server: 유저나 다른 컴포넌트의 명령을 받아 object를 관리(CRUD)
- Controller Manager: 새로운 Controller를 감지하고 이를 처리
- Deployment Controller → ReplicaSet Controller
- ReplicaSet Controller → new unbound Pods
- Scheduler: unbound Pods를 감지하고 이를 처리
- unbound Pods → bound Pods
- kubelet: bound Pods를 감지하고 실제로 Pod을 띄움
Replica Set의 목적은 Pod desired state를 받아 current state를 지속적으로 모니터링하고, current state와 desired state 사이에 다른 부분이 있을 경우 이를 일치하도록 만드는 것이다.
Replica Set이전에는 Replication controller 가 있었는데 Replica Set이 조금 더 선택지가 넓어졌다는 장점이 있다
Replication Controller = 등호 기반, 레이블을 선택할 때 같은지 다른지만 비교
Replica Set = 집합 기반, in, notin, exists 같은 연산자 지원
Controller Manager와 Replica Set이 어떻게 연결되어 동작하는지 궁금했는데 한 블로그를 보고 감을 잡을 수 있었다
우선, 위에서 Kubernetes는 desired state를 input으로 받는다고 했다. 일반적으로 유저가 정의하는 desired state는 Deployment object이다. 예를 들어, 유저는 kubectl을 통해 Kubernetes master node에 노출된 api server 컴포넌트에 “이미지 A의 컨테이너가 하나 있는 Pod을 4개 띄운 상태로 유지해주세요”라는 Deployment object를 만들라고 명령한다. 그러면 api server는 http 요청을 받고 etcd라는 저장소에 해당 Deployment object의 정보를 저장하기만 한다.
Deployment object를 저장하면, Controller Manager라는 컴포넌트가 이를 감지하고 이에 대응하는 ReplicaSet object를 생성한다. 위 상황에서는 “이미지 A에 대해 4개의 컨테이너 복사본을 유지한다”는 ReplicaSet object를 하나 만들라고 api server에게 명령할 것이다. 그러면 api server는 이를 etcd에 저장(생성)한다.
ReplicaSet object 역시 Controller의 일종이기 때문에, Controller Manager가 ReplicaSet object의 생성을 감지한다. 그러면 Controller Manager는 ReplicaSet object에 적힌 대로 이미지 A를 기반으로 Pod을 4개 생성한다. 여기서 중요한 것은 Controller Manager가 Pod을 실제 Node에 띄우지는 않고 단지 생성만 한다는 것이다
👇 위 글의 출처, Kubenetes 전반적인 설명이 잘 되어 있어서 읽어보면 좋을 것 같다!
Replica Set
레플리카셋으로 만든 파드 수 조정하는 법
1. cli
kubectl scale rs sysinfo-rs --replicas=10
kubectl scale rs sysinfo-rs --replicas=3
2. 레플리카셋 yml에서 수정하고 apply
kubectl apply -f .
3. edit로 조절
kubectl edit rs sysinfo-rs
레플리카셋 정보보기
kubectl edit rs sysinfo-rs
레플리카셋 yml 샘플 파일
https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
replicas = Desire status
replicas가 없을때 template 를 참고해서 pod를 만들어라
Replica Set = Pod 관리가 목적인 리소스
RS로 만든 pod이름은 규칙을 가진다
Service.yml에서 포트는 엄청 중요하다
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
selector:
app: nginx
ports:
- port: 80
targetPort: 80
type: LoadBalancer
이때 type: LoadBalancer 를 주지 않으면 ip를 받을 수 없다 <none> 가 됨
오늘 배운것을 기반으로 서비스 무중단 배포하는 법
nginx_v1, nginx_v2, nginx_v3 이미지를 만들고, 레플리카 세트로 nginx_v1 pod를 생성하고 scv를 배포한다
nginx_v1을 nginx_v2로 바꾸어서 배포하고 싶은데 무중단 배포 하고싶다면 ..
replica set을 새로 만들어서 nginx2를 여러개 배포한다 -> 이때 svc.yml의 selector에 맞게 생성하도록한다 (pod를 만들으면 자동으로 배포 됨)
이후 nginx_v2가 잘 돌아가는걸 확인 후 nginx_v1 pod를 지운다..
오늘의 회고
- 어제 심심해서 자기전에 교재를 읽었는데 이해하는데 도움이 좀 되었다 오늘도 책 보고 복습 해야겠다!
- 포트포워딩이 조금 헷갈렸는데 드디어 개념을 확실히 잡은것 같다
- 무중단 배포에 한걸음 다가감,,, 실제 서비스 배포는 아직 좀 무섭다 (해보지도 않았지만,,)
- 아직 자꾸 명령어도 까먹고 버벅이는 부분이 있지만 익숙해지도록 노력해야겠다 ,, 😂
- 그리고 여담이지만 ,, 티스토리 글쓰기가 날이갈수록 불편해지고 있다 복붙하면 다른 내용이 없어져버리고 ,, 맨 위로 올라가고 ,, ㄱ- 개선해주쇼!
'Cloud > Cloud 공부일기' 카테고리의 다른 글
Day 46 - 쿠버네티스 서비스, 로드밸런서 (0) | 2022.03.16 |
---|---|
Day 45 - 쿠버네티스 서비스 (0) | 2022.03.15 |
Day 43 - 쿠버네티스 기본 명령어 (0) | 2022.03.11 |
Day 42 - GKE, EKS | awscli, ekctl 설치 (0) | 2022.03.10 |
Day 41 - 쿠버네티스 기초 (0) | 2022.03.08 |