파드 업데이트 및 복구
- 파드 배포
- C\HashiCorp> kubectl apply -f ~/_Book_k8sInfra/ch3/3.2.10/rollout-nginx.yaml
--record
- 배포한 파드 확인
- record 옵션으로 기록된 히스토리를 명령을 통해 확인
- kubectl rollout history deployment rollout-nginx
- 배포한 파드의 정보 확인
- kubectl get pods -o=custom=NAME:.metadata.name,IP:.status.podIP,STATUS:.status.phase,NODE:.spec.nodeName
=> 명령어 입력 시 주의할 점은 띄어쓰기를 사용하면 안된다는 것
(구분자로 인식하기 때문이다.)
- 예제 실습을 위한 파드 생성
- kubectl run nginx-pod --image=nginx
- 파드 접속
- kubectl exec -it nginx-pod -- /bin/bash
- 서버 확인
- curl -l --silent [IP Address] | grep Server
- set image 명령으로 파드 버전 업데이트
- kubectl set image deployment rollout-nginx nginx=nginx:1.16.0 --record
- 이전에 파드 정보 확인했던 명령어로 확인해보면
- kubectl get pods -o=custom=NAME:.metadata.name,IP:.status.podIP,STATUS:
.status.phase,NODE:.spec.nodeName
- 기존의 생성됐던 파드의 해시값과 완전히 다른 해시값을 가지는 파드들이
생성된다.
- 업데이트가 완료되면 Deployment 상태 확인
- kubectl rollout status deployment rollout-nginx
- 히스토리 확인하기
- kubectl rollout history deployment rollout-nginx
- curl 명령으로 업데이트가 제대로 됐는지 확인
- curl -l --silent [IP Address] | grep Server
업데이트 실패 시 파드 복구
- 확인을 위해 업데이트 버전을 의도적으로 변경
- kubectl set image deployment rollout-nginx nginx=nginx:1.17.23 --record
- 파드 정보 확인
- kubectl get pods -o=custom=NAME:.metadata.name,IP:.status.podIP,STATUS:
.status.phase,NODE:.spec.nodeName
=> 업데이트 한 파드의 상태가 Pending 상태로 유지되는 것을 확인할 수 있다.
- 문제 확인을 위해 rollout status를 실행
- kubectl rollout status deployment rollout-nginx
=> 새로운 replicas는 생성했으나 Deployment를 배포하는 단계에서 대기 중(Waiting)으로
더 이상 진행되지 않는 것을 확인할 수 있다.
- Deployment를 생성하려고 여러 번 시도했지만 끝내 생성되지 않았다는
메시지가 출력된다.
- describe 명령으로 문제점 확인
- kubectl describe deployment rollout-nginx
=> 해당 명령은 쿠버네티스의 상태를 살펴볼 때 유용하다.
- 정상적인 상태로 복구하는 방법을 알아보자.
업데이트 할 때 사용했던 명령들을 rollout history로 확인
- kubectl rollout history deployment rollout-nginx
- rollout undo로 명령 실행을 취소해 마지막 단계(revision 3)에서 전 단계(revision 2)로 상태를 되돌리기
- kubectl rollout undo deployment rollout-nginx
- 파드 상태 확인
- kubectl get pods -o=custom=NAME:.metadata.name,IP:.status.podIP,STATUS:
.status.phase,NODE:.spec.nodeName
- rollout history로 실행된 명령을 확인
- revision 4가 추가되고, revision 2가 삭제됐다.
현재 상태를 revision 2로 되돌렸기 때문에 revision 2는 삭제되고, 가장 최근 상태는
revision 4가 된다.
- kubectl rollout history deployment rollout-nginx
- 배포된 컨테이너의 nginx 버전을 curl -l로 확인
- curl -l --silent [IP Address] | grep Server
- rollout status 명령으로 변경이 정상적으로 적용됐는지 확인
- kubectl rollout status deployment rollout-nginx
- describe 명령으로 현재 디플로이먼트 상태도 세부적으로 점검
- kubectl describe deployment rollout-nginx
특정 시점으로 파드 복구
- 처음 상태인 revision 1로 돌아가기
- kubectl rollout undo deployment rollout-nginx --to-revision=1
- 새로 생성된 파드들의 IP를 확인
- kubectl get pods -o=custom=NAME:.metadata.name,IP:.status.podIP,STATUS:
.status.phase,NODE:.spec.nodeName
- curl -l로 nginx 컨테이너의 버전 확인
- curl -l --silent [IP Address] | grep Server
- 다음 단계 진행을 위해 배포한 rollout-nginx 디플로이먼트 삭제
- kubectl delete -f ./_Book_k8sInfra/ch3/3.2.10/rollout-nginx.yaml
- 배포된 파드가 없는지 확인
쿠버네티스 연결을 담당하는 서비스
일반적으로 서비스라고 하면 웹 서비스나 네트워크 서비스처럼 운영체제에 속한 서비스
데몬 또는 개발 중인 서비스 등을 떠올릴 수 있다.
하지만 쿠버네티스의 서비스는 외부에서 쿠버네티스 클러스터에 접속하는 방법을 의미한다.
서비스를 '소비를 위한 도움을 제공한다'는 관점으로 바라본다면 쿠버네티스가 외부에서
쿠버네티스 클러스터에 접속하기 위한 '서비스'를 제공한다고 볼 수 있다.
=> Mini Kube의 경우 LocalHost Address가 Cluster Address가 된다.
가장 간단하게 연결하는 노드포트
외부에서 클러스터 내부에 접속하는 가장 쉬운 방법은 노드포트 서비스를 이용하는 것
노드포트 서비스를 설정하면 모든 워커 노드의 특정 포트(노드포트)를 열고, 여기로 오는
모든 요청을 노드포트 서비스로 전달한다.
외부에서 클러스터 내부 파드에 직접 연결이 아닌, 노드포트를 통해 연결되는 이유는 각각의
파드가 가진 IP 주소는 외부에서 재응답 시 사용할 수 있는 포트가 아니기 때문이다.
또한, 통신의 검증을 위해 노드포트가 방화벽 역할을 하기도 한다.
노드포트 서비스로 외부에서 접속
- 디플로이먼트로 파드를 생성
-kubectl create deployment np-pods --image=sysnet4admin/echo-hname
- 배포된 파드 확인
- kubectl create로 노드포트 서비스를 생성
- kubectl create -f ~/_Book_k8sInfra/ch3/3.3.1/nodeport.yaml
apiVersion: v1
kind: Service
metadata:
name: np-svc
spec:
selector:
app: np-pods
ports:
- name: http
protocol: TCP
port: 80
targetPort: 80
nodePort: 30000
type: NodePort
=> 서비스는 모든 수신 포트를 targetPort에 매핑할 수 있는데, 기본적으로 그리고
편의상 targetPort는 port 필드와 같은 값으로 설정된다.
- 생성된 서비스 확인
- kubectl get service / services
- 쿠버네티스 클러스터의 워커 노드 IP 확인
- kubectl get nodes -o wide
- 웹에서 접근하여 확인
- 노드포트 서비스의 INTERNAL-IP 주소로 접근
부하 분산 테스트
디플로이먼트로 생성된 파드 1개에 접속하고 있는 중 파드가 3개로 증가하면
접속 상태가 어떻게 바뀌는지 확인
즉, 부하가 어떻게 분산 되는지를 확인한다.
- cmd -> powershell 켜기
PS C:\Users\tjoeun> $I=0;while($true)
>> {
>> % { $i++; write-host -NoNewLine "$i $_" }
>> (Invoke-RestMethod "http://localhost:30000")-replace '\n', " "
>> }
=> 명령 실행 시 현재 접속한 호스트 이름을 순서대로 출력함.
- powershell로 코드 실행 후 쿠버네티스 마스터 노드에서 scale을 실행해
파드를 3개로 증가
- kubectl scale deployment np-pods --replicas=3
- 파워 셸에서 1번 명령어를 재입력하여 부하 분산을 확인
노드포트의 오브젝트 스펙인 nodeport.yaml 파일 일부
spec:
selector:
app: np-pods
- np-pods를 yaml 파일로 열기