[워밍업 클럽:쿠버네티스] 미션#4 (2주차)
실습 제출 일자: 25.06.10(화)1. PVC / PV▶ 1~4. local 동작 확인// 1번 API - 파일 생성 http://192.168.56.30:31231/create-file-pod http://192.168.56.30:31231/create-file-pv // 2번 - Container 임시 폴더 확인 [root@k8s-master ~]# kubectl exec -n anotherclass-123 -it <pod-name> -- ls /usr/src/myapp/tmp // 2번 - Container 영구저장 폴더 확인 [root@k8s-master ~]# kubectl exec -n anotherclass-123 -it <pod-name> -- ls /usr/src/myapp/files/dev // 2번 - master node 폴더 확인 [root@k8s-master ~]# ls /root/k8s-local-volume/1231 // 3번 - Pod 삭제 [root@k8s-master ~]# kubectl delete -n anotherclass-123 pod <pod-name> // 4번 API - 파일 조회 http://192.168.56.30:31231/list-file-pod http://192.168.56.30:31231/list-file-pvAPI로 파일 생성하기/create-file-pod는 임시폴더 (/usr/src/myapp/tmp) 에 파일을 생성하는 API이다.API를 3번 호출을 해서 txt파일이 임시폴더에 3개 생성이 됐다.master node 폴더에는 API를 2번 호출해 파일이 2개 생성이 됐다. 파일 확인하기파드가 2개인 상태에서 임시폴더 생성 API를 하는 경우 어디에 저장이 될지 궁금했다.파드 2개 중에 한 파드에만 파일이 생성되는 모습이다.반면에 영구저장폴더는 애초에 마스터노더에 저장되는 파일을 연결하는 개념이라 두 파드에 모두 인식이 되는 모습이다.3-4. 파드 삭제 후 생성된 파드에 파일 확인임시폴더와 영구저장폴더를 가진 파드를 삭제를 하였고,새로운 파드가 동작하는 걸 확인한 뒤 다시 파일을 조회해본 결과,임시폴더엔 파일이 없고, 영구저장폴더엔 2개의 파일이 존재하는 걸 확인할 수 있다.터미널 상에도 동일하게 확인가능! ▶ 5. hostPath 동작 확인 - Deployment 수정 후 [1~4] 실행apiVersion: apps/v1 kind: Deployment metadata: namespace: anotherclass-123 name: api-tester-1231 spec: template: spec: nodeSelector: kubernetes.io/hostname: k8s-master containers: - name: api-tester-1231 volumeMounts: - name: files mountPath: /usr/src/myapp/files/dev - name: secret-datasource mountPath: /usr/src/myapp/datasource volumes: - name: files persistentVolumeClaim: // 삭제 claimName: api-tester-1231-files // 삭제 // 아래 hostPath 추가 hostPath: path: /root/k8s-local-volume/1231 - name: secret-datasource secret: secretName: api-tester-1231-postgresql기존의 pvc 코드를 없애고, hostPath로 변경했다.Deployment를 업데이트 하여 새로운 파드들로 교체되었다. (임시폴더 확인)임시폴더에 정상적으로 파일이 생성되는 모습을 볼 수 있다. (영구저장폴더 확인)API 호출을 한번 실행했는데, 기존에 호출했던 2파일까지 없어지지않고 보이는 모습이다.동일하게 파일들이 잘 보인다. 2. Deployment▶ 1. RollingUpdate 하기// 1) HPA minReplica 2로 바꾸기 (이전 강의에서 minReplicas를 1로 바꿔놨었음) kubectl patch -n anotherclass-123 hpa api-tester-1231-default -p '{"spec":{"minReplicas":2}}' // 1) 그외 Deployment scale 명령 kubectl scale -n anotherclass-123 deployment api-tester-1231 --replicas=2 // 1) 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 kubectl set image -n anotherclass-123 deployment/api-tester-1231 // update 실행 포맷 // kubectl set image -n <namespace> deployment/<deployment-name> <container-name>=<image-name>:<tag>이전에 한번 namespace를 삭제하고 다시 설치해서 HPA minReplica는 2여서 따로 바꾸지는 않았다.(대시보드에서 HPA의 값을 확인했을 때 min값이 2로 나온다) 이후 위 명령을 수행한 후, App version을 업데이트 하면,하나씩 파드를 업데이트하고, 정상적으로 파드가 기동하면 기존 파드는 삭제하고, Api version이 2.0으로 출력되는 걸 확인할 수 있다.(최종 version으로 모두 교체 완료된 모습)▶ 2. RollingUpdate (maxUnavailable: 0%, maxSurge: 100%) 하기apiVersion: apps/v1 kind: Deployment metadata: namespace: anotherclass-123 name: api-tester-1231 spec: replicas: 2 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 25% -> 0% # 수정 maxSurge: 25% -> 100% # 수정kubectl set image -n anotherclass-123 deployment/api-tester-1231 api-tester-1231=1pro/api-tester:v1.0.0 ver 1.0으로 바꾼 후 결과 살펴보기증가율이 100%라 2개의 파드가 바로 생성되고, 기존 파드는 삭제되지 않음 비가용율은 0%라 최소 파드 개수인 2개가 유지될 수 있게 새로운 파드 2개가 모두 사용 가능한 후에야 기존 파드가 삭제되고, 그로인해 2.0에서 곧바로 1.0으로 모든 파드가 변경되는 모습이다. ▶ 3. Recreate 하기apiVersion: apps/v1 kind: Deployment metadata: namespace: anotherclass-123 name: api-tester-1231 spec: replicas: 2 strategy: type: RollingUpdate -> Recreate # 수정 rollingUpdate: # 삭제 maxUnavailable: 0% # 삭제 maxSurge: 100% # 삭제kubectl set image -n anotherclass-123 deployment/api-tester-1231 api-tester-1231=1pro/api-tester:v2.0.0 App에 업데이트가 생기는 경우, 기존 파드들을 다 내리게 되어 서비스 불가한 타임 (App version을 받는 log 호출이 되지 않음)이후 새로운 파드로 교체가 되니 정상적으로 호출되는 모습이다. ▶ 4. Rollback// 이전 버전으로 롤백 kubectl rollout undo -n anotherclass-123 deployment/api-tester-1231Recreate 방식으로 롤백을 하여 기존 ver1.0으로 바뀐다.3. Service▶ 1. Pod 내부에서 Service 명으로 API 호출 [서비스 디스커버리]// Version API 호출 curl http://api-tester-1231:80/version가상OS [kubectl로 직접 pod에 위 명령 내리기[root@k8s-master ~]# kubectl exec -n anotherclass-123 -it api-tester-1231-7998bc7d89-lml4g -- curl http://api-tester-1231:80/versionkubectl exec -n [네임스페이스] -it [파드 네임] -- curl http://api-tester-1231:80/version아니면 dashboard에서 실행해도 ㄱㅊ하다. ▶ 2. Deployment에서 Pod의 ports 전체 삭제, Service targetPort를 http -> 8080으로 수정apiVersion: apps/v1 kind: Deployment metadata: namespace: anotherclass-123 name: api-tester-1231 spec: template: spec: nodeSelector: kubernetes.io/hostname: k8s-master containers: - name: api-tester-1231 ports: // 삭제 - name: http // 삭제 containerPort: 8080 // 삭제 --- apiVersion: v1 kind: Service metadata: namespace: anotherclass-123 name: api-tester-1231 spec: ports: - port: 80 targetPort: http -> 8080 // 변경 nodePort: 31231 type: NodePort▶ 2. 그리고 다시 Pod 내부에서 Service 명으로 API 호출curl http://api-tester-1231:80/version동일하게 동작한다(기존에 ports name으로 접근했던 방식이 port number로 바뀐거다). 4. HPA▶ 1. 부하 발생 http://192.168.56.30:31231/cpu-load부하가 증가하는 모습▶ 2. [behavior] 미사용으로 적용kubectl edit -n anotherclass-123 hpa api-tester-1231-defaultapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: namespace: anotherclass-123 name: api-tester-1231-default spec: behavior: # 삭제 scaleUp: # 삭제 stabilizationWindowSeconds: 120 # 삭제평균 utilization이 60%인데, seconds를 0으로 설정하니, 60% 이상을 초과하는 순간 곧바로 파드 개수를 늘려주는 모습이다.
