블로그 모아보기 - 인프런

Application 기능으로 k8s 이해 - Probe

Application 기능으로 k8s 이해 - Probe에 대해 학습해 보자! pod안에 probe설정 3가지 : startupProbe/ readinessProbe / livenessProbepod가 만들어 지면 probe 기능 동작startupProbehttpGet: path:"/ready" (공통사항) port: 8080 (공통사항)periodSeconds:10successThreshold: 1failureThreshold: 10 (성공, 실패 수치 )10초에 한 번씩 /ready라는 API를 App에 날린다. 그리고 10번을 실패하기 전에 응답이 있으면 성공!성공 후에 쿠버네티스는 startupProbe기능을 중지 시킨다readinessProbe, livenessProbe 기능 동작 시킨다readinessProbehttpGet: path:"/ready" (공통사항) port: 8080 (공통사항)periodSeconds:10successThreshold: 1failureThreshold: 2 (성공, 실패 수치 )10초에 한 번씩 /ready라는 API를 App에 날린다. App이 살아 있는 동안에는 계속 200 ok결과를 리턴성공 외부 트래픽을 pod가 받을 수 있도록 만들어주면서 서비스 활성화 된다livenessProbehttpGet: path:"/ready" (공통사항) port: 8080 (공통사항)periodSeconds:10successThreshold: 1failureThreshold: 2 (성공, 실패 수치 ) 10초에 한 번씩 /ready라는 API를 App에 날린다. App이 살아 있는 동안에는 계속 200 ok결과를 리턴 readinessProbe, livenessProbe 기능 동작 반복앱이 살아있는지 계속 확인만약 2번 실패한다면? 쿠버네티스는 앱을 재기동 시킨다. (동작 예시)Application에는 동작이 있다. 그 동작이 자동화 되길 요구 한다. [초기화 과정-> User 초기화-> 앱 기동]App 초기화(API 받을 수 없는 상태): 초기화 끝냈는지에 대한 App 상태 체크, 외부 API 접근 금지 User 초기화(API 받을 수 있는 상태): App이 살아있는지에 대한 App 상태 체크, 외부 API 접근 금지 App 기동App이 살아있는지에 대한 App 상태 체크, 외부 API 접근 허용 쿠버네티스 제공 기능 [출처: 인프런 - 쿠버네티스 어나더 클래스 ]livenessProbe 성공하면 startupProbe 중지 -> livenessProbe, readinessProbe 기능 활성화 -> livenessProbe는 설정된 API 호출-> 만약 (실패)--->장애라고 판단하고 pod 재기 readinessProbe여전히 Service를 Pod에 연결하고 있지 않음 -> 연결 성공 -> 쿠버네티스가 Service랑 Pod를 연결 -> 트래픽 들어옴 --> 만약 (실패)---->쿠버네티스는 연결 해제 -> 재연 실습pod를 삭제하고 외부 API 실패app이 초기화 되고 있는 동안에는 실패한다내부 API는 성공!기동 완료 -> 다시 외부 API 날리면 성공!트래픽 중단 - App 내부 isAppReady를 False로 바꿈readinessProbe가 3번 실패하면, Service랑 Pod 연결 해제 & 외부 트래픽 받을 수 없음트래픽 재개 -> App 내부 isAppReady를 True로 바꿈API - 장애발생 (App 내부 isAppLive를 False로 바꿈) & 재기동

데브옵스 · 인프라･쿠버네티스･Probe･데브옵스･공부･열정･실습･아자아자화이팅

1

[인프런 워밍업 클럽 4기 - DevOps] 미션 2. Probe 응용과제

응용 과제Application 로그를 통한 probe 동작 분석#사전 작업#kubectl patch -n anotherclass-123 hpa api-tester-1231-default -p '{"spec":{"minReplicas":1}}' Grafana 접속 후 Pod 로그 화면 설정Pod 삭제Application Log 확인마스터 노드에서 실행// 1번 API - 외부 API 실패 curl http://192.168.56.30:31231/hello // 2번 API // 외부 API 실패 curl http://192.168.56.30:31231/hello // 내부 API 성공 kubectl exec -n anotherclass-123 -it api-tester-1231-7459cd7df-2hdhk -- curl localhost:8080/hello kubectl exec -n anotherclass-123 -it <my-pod-name> -- curl localhost:8080/hello // 3번 API - 외부 API 성공 curl http://192.168.56.30:31231/hello // 4번 API // 트래픽 중단 - (App 내부 isAppReady를 False로 바꿈) curl http://192.168.56.30:31231/traffic-off // 외부 API 실패 curl http://192.168.56.30:31231/hello // 트래픽 재개 - (App 내부 isAppReady를 True로 바꿈) kubectl exec -n anotherclass-123 -it api-tester-1231-7459cd7df-2hdhk -- curl localhost:8080/traffic-on // 5번 API - 장애발생 (App 내부 isAppLive를 False로 바꿈) curl http://192.168.56.30:31231/server-error 응용 1. startupProbe가 실패 되도록 설정해서 Pod가 무한 재기동 상태가 되도록 설정해 보세요.[결과]응용 2. 일시적 장애 상황(App 내부 부하 증가)가 시작 된 후, 30초 뒤에 트래픽이 중단되고, 3분 뒤에는 App이 재기동 되도록 설정해 보세요.설정 후 API 요청하면 성공하지만 그 이후에는 차단응용 3. Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요.해당 Pod 내부에 파일이 존재하기 때문에 실패 로그는 확인 불가

데브옵스 · 인프라･DevOps･SRE･일프로･Probe･k8s･msa

1

0

[미션2] Application 기능으로 이해하기 - Probe 응용과제

▶응용1 : startupProbe가 실패 되도록 설정해서 Pod가 무한 재기동 상태가 되도록 설정해 보세요 😃Deployment를 수정한다. startupProbe에 failureThreshold 수치 낮추기! App이 기동 안되도록 한다.failureThreshold는 몇 번까지 실패를 허용할지 정하는 수치/startup 에 대한 첫 요청이 실패하면 → 바로 Pod 재시작됨. 앱은 보통 기동될 때 시간이 좀 걸릴 수 있다 (넉넉하게 50초)- DB 연결 Spring 부팅 포트 바인딩이런 것들이 완료 되어야 한다. ▶응용2 : 일시적 장애 상황(App 내부 부하 증가)가 시작 된 후, 30초 뒤에 트래픽이 중단되고, 3분 뒤에는 App이 재기동 되도록 설정해 보세요. 😆부하 증가 API를 보낸다. 이때 App 내부 isAppReady와 isAppLive를 False가 된다.또한 curl http://192.168.56.30:31231/hello 외부 API 실패부하 감소 API를 보낸다. App 내부 isAppReady와 isAppLive를True가 된다.▶응용3 : Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요. 🙃readinessProbe에는 exec라는 속성으로 command를 Pod에 날릴 수 있고, 이는 App기동시 꼭 필요한 파일이 있는지를 체크 event로 실패 로그 확인

데브옵스 · 인프라･인프런･Probe･미션성공･힘들어･그래도･잘했다

0

[워밍업 클럽: 쿠버네티스] #5. App 기능으로 이해하기 - Probe (2주차)

복습한 내용과 미션2를 함께 포함해서 작성하였다. 강의 수강 일자 : 25.06.02 (월)블로그 복습 일자 : 25.06.04 (수) 전 시간에 Object에 대해 배우면서, 쿠버네티스의 Object들이 어떻게 연결되고 생성되는지 봤다면, 이번 시간에는 Object 중 Pod를 생성하고 관리해주는 Probe에 대해 자세히 복습해보겠다. 우선 Deployment 를 선언할 때 template: 코드 아래는 Pod에 대한 내용이라는 건 배웠었다.Pod 관련 코드들을 살펴보면 다음과 같은 코드를 확인할 수 있다. startupProbePod에서 기동되는 App은 http 8080 port로 값을 받는다.App이 기동이 되면 5초 간격으로(periodSeconds) "/startup" api 호출을 하고, 36번까지 api 호출이 실패하게 되면 (failureThreshold) App이 재기동 된다.App 초기화가 끝났는지 확인하는 동작 과정이며, 초기화가 완료되면 곧바로 liveness와 readiness를 호출해User 초기화와 외부 API 접근 여부를 확인한다. livenessProbeApp 기동이 완료되면 readiness와 livenessProbe는 동시에 각자의 api호출을 하게 된다. App 초기화가 되었다고 해서곧바로 App을 사용할 수는 없고, User 초기화를 해야할 요소들이 있어 해당 과정이 완료되면 App이 살아있게 된다.livenessProbe는 10초 간격으로 "/liveness" api 호출을 하며, 3번 호출이 실패되면 App이 어떤 오류로 죽었다는 의미이다. 하지만 대부분 startupProbe 호출을 받게 되면 App 초기화가 끝나면서 곧바로 livenessProbe도 호출을 받는다.어떤 오류로 App 장애가 생겨 livenessProbe가 끊기게 되면 App 재기동을 한다. readinessProbereadinessProbe는 App에서 외부 Api를 받을 수 있는 상태인지 확인하는 api호출로, App이 정상적으로 기동을 하고, API를 받게되면 readinessProbe도 호출이 완료되며, App 동작이 모두 정상적으로 실행된다는 의미가 된다. 응용 과제 [미션 2]원래 HPA에서 minReplica 값을 2로 하여 파드가 최소 2개씩 유지되었지만, 미션에서는 1로 변경하였다.// HPA minReplica 1로 바꾸기 - Master Node kubectl patch -n anotherclass-123 hpa api-tester-1231-default -p '{"spec":{"minReplicas":1}}' 쿠버네티스 대시보드와 Loki를 활용해 프로브 값이 바뀜에 따라 어떻게 보여지는지 확인했다. ▶ 응용1 : startupProbe가 실패 되도록 설정해서 Pod가 무한 재기동 상태가 되도록 설정해 보세요.(여러분들이 가장 많이 겪게될 Pod 에러입니다)기존 startupProbe 상태는 다음과 같았다.5초 간격으로 App 초기화 여부를 확인하는 상태로, 36번까지 확인해도 초기화가 되지 않는다면 다시 재기동하는 코드지만,실패 횟수를 줄여 App이 초기화 되기도 전에 재기동 시키면 될 것 같다. 처음에는 36번에서 ->10번으로 줄여봤다.정상적으로 App이 기동되는 모습을 보였고, 횟수를 5로 줄여봤다. App이 계속해서 무한으로 재기동되는 모습을 볼 수 있다. ▶ 응용2 : 일시적 장애 상황(App 내부 부하 증가)가 시작 된 후, 30초 뒤에 트래픽이 중단되고, 3분 뒤에는 App이 재기동 되도록 설정해 보세요.(아래 API를 날리면 readinessProbe와 livenessProbe가 동시에 실패하게 됩니다) // 부하 증가 - (App 내부 isAppReady와 isAppLive를 False로 바꿈) curl http://192.168.56.30:31231/server-load-on // 외부 API 실패 curl http://192.168.56.30:31231/hello // 부하 감소 API - (App 내부 isAppReady와 isAppLive를 True로 바꿈) curl http://192.168.56.30:31231/server-load-off부하 증가로 livenessProve와 readinessProve가 동시에 꺼지게 되는 상황이고,30초 후에 readinessProve failure 카운트 수를 초과시켜 외부 API 트래픽을 받을 수 없게,3분 후에는 livenessProve failure 카운트 수를 초과시켜 App을 재기동하게 만들어야 한다. readinessProbe는 10초 간격으로 3번, livenessProbe는 30초 간격 6번으로 설정했다. 부하를 증가 시킨 후, 시간이 지난 후에 api 호출을 한 결과 호출을 실패하는 모습이다. 지속적으로 livenessProbe가 실패를 출력하다, App을 재기동시킨 모습이다. ▶ 응용3 : Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요.(꼭 API를 날리는 것만이 readinessProbe 활용의 전부는 아닙니다) Exec로 확인을 했을 때 yaml 파일이 존재command 명령에 실패(해당 파일이 없을 때)하면 아래와 같이 event로 실패 로그를 볼 수 있어요라고 하지만 파일이 존재해서 실패 로그는 확인할 수 없었다.

데브옵스 · 인프라･k8s･Probe･Object･Mission

0