이번 스터디 주제는 디플로이먼트와 서비스입니다
(책은 15단계로 배우는 도커와 쿠버네티스, 깔끔하고 눈으로만 봐도 될정도로 과정을 다 기록해줌)
요약
1. pod는 일시적인 존재라 없어질 수 있기 때문에 관리해줄 친구들이 필요해요
2. 그 방법이 오늘 정리할 deployment service, job 입니다.
- deployment는 파드의 개수를 관리해줘요
- service는 IP를 관리해줘요
- job 은 실행하고 종료하는 역할을 해요
1. Deployment
요청한 개수만큼 파드를 기동하여, 장애 등의 이유로 파드의 개수가 줄어들면 새롭게 파드를 만들어 기동한다.
- replicaset 과 함께 동작한다.
주요 명령어
replicas : 파드 템플릿을 기동할 파드의 개수를 지정
selector : 레플리카셋과 파드를 대응 (matchlabels>app: aaaa)
template : (metatada>app: aaaa)
- pod의 메타데이터와 spec 부분이 일치해야함
1. 스케일
레플리카의 값을 변경해서 개수를 늘림
클러스터의 cpu/메모리가 부족해지면 프드 생성이 보류됨
방법은 2가지가 있음
* deplyment.yml
spec:
replicas: 3 -> 5* kubectl scale
kubectl scale --replicas=3 rs/foo # Scale a replicaset named 'foo' to 3
kubectl scale --replicas=3 -f foo.yaml # Scale a resource specified in "foo.yaml" to 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # If the deployment named mysql's current size is 2, scale mysql to 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multiple replication controllers2. 롤아웃
컨테이너 업데이트 (yml 수정해서 한 번더 apply 하는 것)
- 작업을 진행할 수 있도록, 일정 개수만큼만 업데이트 진행할 수 있음
RollingUpdateStrategy: 25% max unavailable, 25% max surge
- 최대 25%파드를 정지할 수 있고 ,최대 25%만 초과할 수 있다.
예시) replcias: 5 일 경우, nginx의 이미지만 1.16에서 1.17로 변경
-> 최소 4개의 파드를 유지하고, 최대 7개의 파드가 되도록 점진적 롤아웃 진행
- 최소 파드 : 5 * 0.75 = 3.75 -> 4 (최소 running)
- 초과 파드 : 5 * 1.25 = 6.25 -> 7 (최대 runnging + creating + terminating)
롤 아웃에 의해 종료될 때는 SIGTERM이 전송되고 30초 후에 강제 종료됨
3. 롤백
SQL의 롤백처럼, 롤아웃 전에 사용하던 예전 컨테이너로 돌아가는법
$ kubectl rollout undo deployment web-deploy
4. 자동복구
노드 수준에서 장애가 발행했을 대 파드를 복구하는 기능
node1,2에서 pod가 실행되고 있는데, node2를 죽이면
deployment가 있는 경우 ip그대로 node1에 복구가되지만
deployment 없이 생성된 pod는 그대로 사라진다.
+ kubectl get events | grep web-deploy
+ kubectl logs [파드명]
+ kubectl describe po [파드명]
+ kubectl exec -it [파드명]
2. 서비스
서비스는 IP를 관리하는 타입으로 4가지 종류가 있어요
- ClusterIP : 내부의 파드 -> 서비스의 이름으로 접근
- NodePort : 외부 -> 노드의 IP 주소와 포트번호로 접근
- LoadBalancer : 외부 -> 대표IP주소로 접근
- ExternalName : 외부 IP 주소에 서비스 이름으로 접근
## 서비스
apiVersion: v1
kind: Service
metadata:
name: web-service # 내부 DNS에 저장되며, IP연계에 사용
spec: # type을 생략하여 ClusterIP가 적용된다.
selector: # service - 백엔드 pod와 연결
app: web
ports:
- protocol: TCP
port: 80
Default : ClusterIP
> clusterIp 주소: 파드 집합을 대표하는 IP 주소
파드 내부에서 통신할 때 kubectl get pode -o wide 의 IP로 통신 가능함
clusterIP: None
- 헤드리스 설정으로 서비스가 동작 -> 대표 IP 주소 획득 X, 부하 분산도 X
서비스 타입 : NodePort
> clusterIP + NodePort
외부에서 접근할 때 필요함
노드 IP에고 공개 Port 할당됨 (30000 ~ 32767)
사용 중인 포트를 설정하면 manifest 배포 과정에서 실패
노드가 셧다운되면 서비스 이용 못할 수 있음
* m1 에서 nodeport 가 작동안되서, tunneling으로 동작을 확인했어요
m1에서 안됨 (arm은 virtualbox 지원안해서 그런듯)
➜ step09 git:(master) ✗ minikube start --memory=4096 --driver=virtualbox
😄 Darwin 11.3.1 (arm64) 의 minikube v1.23.0
✨ 유저 환경 설정 정보에 기반하여 virtualbox 드라이버를 사용하는 중
❌ Exiting due to DRV_UNSUPPORTED_OS: The driver 'virtualbox' is not supported on darwin/arm64
---------------------------------------------------------------------------------------------------------
차선책으로 tunneling 해야함
➜ ~ minikube service web-service-np --url
🏃 web-service-np 서비스의 터널을 시작하는 중
|-----------|----------------|-------------|------------------------|
| NAMESPACE | NAME | TARGET PORT | URL |
|-----------|----------------|-------------|------------------------|
| default | web-service-np | | http://127.0.0.1:53525 |
|-----------|----------------|-------------|------------------------|
http://127.0.0.1:53525
❗ Because you are using a Docker driver on darwin, the terminal needs to be open to run it.
c^C✋ Stopping tunnel for service web-service-np.
(다른 터미널에서)
➜ step09 git:(master) ✗ curl localhost:53525
<!DOCTYPE html>
<html>
<head>
서비스 타입 : LoadBalancer
> clusterIP + NodePort
nodeport를 사용하기 때문에 자연스럽게 clusterIp도 사용
- 로드밸랜서와 연동이 됨 퍼블릭 클라우드
서비스 타입 : ExternalName
> 파드에서 외부의 엔드포인트에 접속하기 위한 방법
외부 DNS 이름의 매핑을 내부 DNS에 설정
* m1에서는 외부 DNS는 되지만, 내부 DNS는 설정이 안되는 것 같아요
잡과 크론잡
> pod의 status가 completed 나와도 문제가 있을 수 있다. -> k describe job, k logs [pod] 로 확인 필요
잡
> 지정한 실행횟수와 병행 개수에 따라 한 개 이상의 파드를 실행
- 활용 예
1) 동시 실행과 순차 실행 -> parallelism
2) 파드를 실행할 노드 선택 -> GPU, CPU 등 특정 목적
3) 온라인 배치 처리 요청 -> 메시지 브로커를 예시로 듦
4) 정기 실행 배치 처리 -> 가장 일반적인 것
크론잡
> 크론으로 반복하는 잡
- 종료된 파드는 가비지 수집 컨트롤러가 삭제
잡부분이 생각보다 복잡했는데, 실제 사용을 해봐야 와닿을 것 같아요.
다음 스터디는 아마 Storage와 Statefulset 에 대해 공부할 것 같아요
'기타 > K8S' 카테고리의 다른 글
| youtube) k8s+spark+minio 실습 따라하기_2 :: mightytedkim (0) | 2021.09.21 |
|---|---|
| youtube) k8s+spark+minio 실습 따라하기_1 :: mightytedkim (0) | 2021.09.21 |
| Slipp) K8S 스터디3주차_minikube 실습 :: mightytedkim (0) | 2021.09.11 |
| Slipp) K8S 스터디2주차_컨테이너의 개념 :: mightytedkim (0) | 2021.08.26 |
| Slipp) K8S 스터디1주차_개념 잡기 :: mightytedkim (0) | 2021.08.15 |