[Sprint1] Application 기능- PV/PVC, Deployment, Service, HPA + 실습

남은 Application 기능들을 전부 다뤘다.

 

 

PV/PVC

이전에 가볍게 넘어갔던 부분들을 조금 더 자세히 다뤘다. 

여기서 local과 hostpath에 대해 헷갈려서 표로 정리했다. 

둘다 한 노드를 지정해서 path를 만들기 때문에, 그 node가 삭제되면 데이터도 함께 삭제된다.

약간의 차이가 있다면, local은 결국 PVC가 관리를 해주며, 생성되는 Pod들이 여러 노드에 있기 때문에 더 안정성 있으며, 리소스도 관리가 가능하기 때문에 더 운영환경에 적합하다)

 

 

 

Deployment

이때 maxSurge와 maxUnavailable에 대해 헷갈리는 점들이 있어서 다시 정리했다.

maxSurge

기존 replias 개수를 기준으로, 몇 개까지 더 만들 수 있는지를 의미한다. 

ex1) replicas가 2이고, maxSurge가 100%라면 새로 만들어진 ReplicaSet은  바로 Pod 2개를 새로 만들어준다. 

(기존 Pod기준 2개까지 더 만들 수 있으니까)

ex2)  replicas가 2이고, maxSurge가 50%라면 새로 만들어진 ReplicaSet은 바로 Pod 1개를 새로 만들어준다. 

ex3) replicas가 2이고 maxSurge가 25%라면? 이때 Pod가 0.5개 증가할 순 없으니, 올림을 해서 Pod 1개를 새로 만들어준다.

 

maxUnavailable

기존 replicas개수를 기준으로, 몇 개까지 삭제할 수 있는지를 나타낸다.

ex1)  replicas가 2이고, maxUnavailable이 100%라면 기존의 Pod 2개는 바로 삭제된다. 

ex2) replicas가 2이고, maxUnavailable이 50%라면 기존의 Pod 1개는 바로 삭제된다. 

ex3) replicas가 2이고, maxUnavailable이 25%라면, 올림을 해서 Pod 1개가 바로 삭제된다. 

 

참고로, 이때 100%, 50%의 비율이 아니라, 정수값(Pod 개수)을 넣어도 된다. 

 

이제 두 속성을 전부 적용해보자(replicas: 2)

ex1) maxSurge: 100% / maxUnavailable: 100%

기존 pod 두개 삭제, 새 Pod 두개 생성 -> 서비스 중단 -> 새 Pod 생성됨

ex2) maxSurge: 100% / maxUnavailable: 0%

새 Pod 2개 생성 -> 새 Pod 1개 기동-> 기존 Pod 1개 삭제 -> ...

 

 

 

Service

참고로 내부 DNS이름을 사용하는 이유는 Pod가 죽으면 IP가 바뀌기 때문!

그래서 사실 운영, 테스트 환경이 아니면 외부에서도 IP로 접속을 보통 하지 않는다. 이때 DNS를 사용함. 

 

 

 

 

HPA

강사님 자료 일부-스케일링

 

 

 

 

 

 

 

 

 

---

실습

 

1. PV/PVC

1-1) txt 파일 생성 API 보내기 

http://192.168.56.30:31231/create-file-pod
http://192.168.56.30:31231/create-file-pv

 

 

 

1-2) 파일 확인하기 

# 파일 확인 명령어
kubectl exec -n anotherclass-123 -it <pod-name> -- ls /usr/src/myapp/tmp
kubectl exec -n anotherclass-123 -it <pod-name> -- ls /usr/src/myapp/files/dev
ls /root/k8s-local-volume/1231

 

 

1-3) Pod 삭제 후 파일 확인하기

▲ 임시로 저장된 tmp만 삭제됨 

 

 

1-4) Deployment 편집하고 Hostpath 확인하기 

      volumes:
        - name: files
          hostPath:
            path: /root/k8s-local-volume/1231
        - name: secret-datasource
          secret:
            secretName: api-tester-1231-postgresql

 

 

API로 파일 생성 후

 

Pod 삭제 후

 

지금은 node가 master-node 1개 뿐이라 별다른 차이가 없다. 

 

 

 

2. deployment

2-1) RollingUpdate

// HPA minReplica 2로 바꾸기
kubectl patch -n anotherclass-123 hpa api-tester-1231-default -p '{"spec":{"minReplicas":2}}'

// Deployment replicas 2 로 바꾸기
kubectl scale -n anotherclass-123 deployment api-tester-1231 --replicas=2
// edit로 모드로 직접 수정도 가능
// kubectl edit -n anotherclass-123 deployment api-tester-1231

// 2) 지속적으로 Version호출 하기 (업데이트 동안 리턴값 관찰)
while true; do curl http://192.168.56.30:31231/version; sleep 2; echo ''; done; 

// 3) 별도의 원격 콘솔창을 열어서 업데이트 실행 
kubectl set image -n anotherclass-123 deployment/api-tester-1231 api-tester-1231=1pro/api-tester:v2.0.0

// update 실행 포맷 
// kubectl set image -n <namespace> deployment/<deployment-name> <container-name>=<image-name>:<tag>

 

점진적으로 업데이트 됨 

 

 

2-2)  RollingUpdate (maxUnavailable: 0%, maxSurge: 100%) 하기

대시보드에서 수정함

예상: maxSurge 100%, maxUnavailable: 0% 이므로 Pod는 2개 더 늘어나고, 2개 다 기동 되면 남은 2개가 삭제될 것

 

kubectl set image -n anotherclass-123 deployment/api-tester-1231 api-tester-1231=1pro/api-tester:v1.0.0

▲ 업데이트 시작하자마자 늘어난 Pod들

▲ 시간이 지나자, Pod의 버전이 v1.0.0으로 업데이트 됨과 동시에 pod들이 2개로 감소했다. 

 

 

 

2-3) Recreate 

예상: 전부 삭제하고 새로 만들어지므로, 중간에 runnung 중인 Pod가 없는 상황이 생길 수 있음. 

kubectl set image -n anotherclass-123 deployment/api-tester-1231 api-tester-1231=1pro/api-tester:v2.0.0

▲ 예상대로 서비스 중단 

▲ 시간이 지난 후 

 

 

 

2-4) Rollback

kubectl rollout undo -n anotherclass-123 deployment/api-tester-1231

 

 

 

 

3. Service

3-1) Pod 내부에서 Service 명으로 API 호출 [서비스 디스커버리]

curl http://api-tester-1231:80/version

참고로, 이 curl 명령어는 master-node의 리눅스 쉘에서는 동작하지 않는다! 

왜냐하면 리눅스 쉘은 kubernetes cluster외부에 있는 것이기 때문. 

▲ Container의 Port 부분 지움 

 

▲ targetPort 8080으로 변경 

 

▲ App을 업데이트 하면서 잠시 연결이 끊겼다가 통신이 됨 (현재 Recreate)

 

 

 

 

 

4. HPA

4-1) 부하 발생

http://192.168.56.30:31231/cpu-load?min=3

 

4-2) 부하 확인

// 실시간 업데이트는 명령어로 확인하는 게 빨라요
kubectl top -n anotherclass-123 pods
kubectl get hpa -n anotherclass-123

// Grafana는 Prometheus를 거쳐 오기 때문에 좀 늦습니다
Grafana > Home > Dashboards > [Default] Kubernetes / Compute Resources / Pod

▲ CPU 사용량에 따라 Pod 수가 증가함 

 

▲ HPA가 작동해서 Pod가 3개로 늘어남 

 

 

4-3) [behavior] 미사용으로 부하 발생

// hpa 코드 수정 (behavior 부분 삭제)
kubectl edit -n anotherclass-123 hpa api-tester-1231-default

// 부하 삽입
http://192.168.56.30:31231/cpu-load

 

 

4-4) [behavior] 미사용으로 부하 확인

- 부하 받기 전

 

- 부하 받고 난 후

 

 

 

 

 

 

 

 

정말 긴 여정이었네요 읽어주셨다면 감사합니다