[쿠어클#7-1] Application 기능으로 이해하기-Pod (probe)

쿠버네티스를 공부 하다보면 경계를 해야 되는 상황이 있어요. 내가 어떤 개념을 힘들게 공부하고 사용법을 익혔을 때, 그 기능을 내가 하는 프로젝트에 적용 시키고 싶은 마음이 생기죠?

여기까진 좋은데.

그 기능을 적용함으로써 "운영에 불편한 관리 요소가 생기진 않을지?", "오히려 시스템에 복잡도만 증가 시키는 건 아닐지?" 는 충분히 고민하지 않는 경우가 있습니다.

예를 들어, 쿠버네티스에는 NetworkPolicy 라는 object가 있는데, 쉽게 말해 Pod들 간에 방화벽 역할을 하는 는 기능 이예요. 보통 큰 프로젝트 환경을 보면 별도로 보안을 담당하는 사람이 있고, 내부 시스템을 외부에서 연결할 수 있도록 하거나 시스템 간에 통신을 해야 할 때 이 담당자한테 방화벽 오픈 신청을 먼저 하죠. 이렇게 전체적인 시스템에 대해서 방화벽이 관리되고 있는데, 쿠버네티스 클러스터 안에 NetworkPolicy를 적용하고 별도에 내부 방화벽 정책을 또 사용 할지에 대해서는 꼭 그렇게 해야 되는 이유를 충분히 고민 해봐야돼요.

근데 오늘 배울 이 쿠버네티스의 기능은 백퍼센트 사용을 해야되지만 내 Application에 대한 충분한 이해가 없으면 생각지도 못한 장애를 만날 수가 있습니다.

바로 Pod에 probe라는 기능인데요.

실제로 저도 Pod가 내가 의도하지 않은 상황에서 죽었을 때, 원인을 분석하다 보면 이 기능을 잘못 사용해서 그랬던 적이 있을 만큼 정확하게 이해하고 적용 시켜야 되는 기술입니다.

Pod (probe) - 프로브 기본 개념

3가지 종류가 있고 모두 /ready라는 url을 8080포트에 10초 간격으로 날리는데, 각각 성공이랑 실패에 대한 수치는 위 그림처럼 되어 있다고 해볼게요.

컨테이너 안에 있는 App에서는 /ready라는 url이 사전에 만들어져 있어야 되고 Pod가 만들어지자마자 이 probe 기능들은 동작합니다.

App은 처음 기동 중인 상태가 있고, 이때 쿠버네티스가 startupProbe 기능을 동작 시키면서 오브젝트 속성에 있는 대로 10초에 한 번씩 /ready라는 api를 App에 날려요. 기동 중일 때는 응답을 받을 수 없으니까 계속 실패가 될꺼고 10번 실패하기 전에 한번이라도 응답이 오면 성공으로 간주합니다.

startupProbe 가 성공하면, 쿠버네티스는 startupProbe 기능을 중지 시키고 livenessProbe랑 readinessProbe기능을 동작 시킵니다. 그리고 또 설정 한대로 두 probe는 /ready라는 api를 10초 간격으로 반복해서 날리는데 App이 살아있는 동안에는 계속 200 OK 결과를 리턴 해주면서 이 두 probe 동작은 반복됩니다.

각각의 역할은 다른데요.

readinessProbe는 성공했을 때 외부 트래픽을 Pod가 받을 수 있는 상태로 만들어 주면서 서비스가 활성화 되고요. livenessProbe는 app이 살아 있는지를 계속 체크하는 역할 이예요.

livenessProbe는 만약 App에 장애가 발생하게 되면, API는 실패를 하게 되고 설정에 따라 두 번을 실패하게 되면 쿠버네티스는 App을 재기동 시킵니다.

이게 쿠버네티스에 프로브에 대한 기능이고, 일반적으로 자신에 App 기동 시간에 따라 startupProbe에 실패 횟수만 조정해서 쓰는 게 대부분인데 처음엔 이렇게 쓰더라도 어느 순간 이런 생각이 들 때가 있을 거예요.

"왜 probe 마다 귀찮게 api들을 기입하는 항목이 각각 있을까?" 어차피 모두 같은 url을 지정해서 쓰는데, 그리고 또 한가지가 "어차피 장애가 나면 livenessProbe랑 readinessProbe는 같이 실패를 할 텐데, 굳이 readinessProbe도 계속 호출될 필요가 있을까?"

쿠버네티스가 괜히 이렇게 해놓지는 않았을 텐데 "혹시 내가 이 프로브들을 제대로 쓰고 있는 게 아닌가?"

이 프로브들을 간단하게만 써도 나쁘진 않지만 오늘은 이런 의문이 생기는 사람들을 위해서 probe에 대해서 좀 더 깊게 공부를 해보겠습니다.

Pod (probe) - 실습

카페 자료실 링크 (link)

강의 영상에서는 실습이 함께 진행됩니다.

Pod (probe) - 실습 로그 분석

이제부터 실습 후 로그를 함께 분석해 볼게요.

먼저 App이 초기화 되기 시작했고, Spring이랑 Servlet을 초기화 과정이 있어요. 다음으로 Database를 연결하는데 실제 DB가 있는 건 아니고 그냥 제가 코드에 로그만 찍어 놓은거예요. 그리고 이렇게 App이 기동되는 동안 startupProbe는 계속 실패하고요. startupProbe가 찍히는 주기는 설정 해놓은대로 5초 간격이죠. 그리고 기동이 완료되면 startupProbe는 성공을 합니다.

근데 이 로그들은 startupProbe가 찍히는 걸 보여드리기 위해서 제가 임의로 코드를 구성했기 때문에 로그가 보이는 거예요. 무슨 말이냐면, 실제 App 상황에서는 쿠버네티스는 Pod가 생성되자마자 startupProbe를 작동 시키기 때문에 사실 처음부터 API는 실패 되고 있었거든요.

이렇게 App이 기동 되기 전에는 API를 받지 못하기 때문에 실제로는 startupProbe에 로그가 찍힐 수가 없고, 만약에 Was로 tomcat을 썼다면 startupprobe가 찍히는 건 access.log 에서만 볼 수 있게 돼요.

그래서 이 로그는 제가 임의로 코드를 구성한 학습적인 상황이라고 말씀드리는 거고요.

이제 기동이 완료가 됐고, [ConfigMap data is loading]은 사용자가 App이 기동 된 후에 외부에 데이터를 가져와서 추가적으로 시스템을 초기화 시키려는 상황 이예요. 그리고 밑에 livenessProbe랑 readinessProbe도 찍히기 시작했고요. 이때 readinessProbe는 실패했고, livenessProbe만 성공을 했네요. 그리고 추가적인 데이터 작업은 끝났고요.

그림 제일 하단에 livenessProbe랑 readinessProbe는 계속 찍히고 있는데, 이제 둘 다 성공을 했네요. 그리고 호출 주기는 10초고요.

근데 여기 보면 readinessProbe가 한번 실패를 했죠?

이건 사용자 초기화 구간에는 readinessProbe가 실패 하도록 일부러 만든 거예요. 그래서 의도 한대로 현재 기능이 정확하게 동작을 해준 건데, 일단 이런 사실만 기억하고 다음으로 넘어가서 강의 영상에서 Application 동작 중심에 프로브를 다시한 번 설명 드립니다.

밑에 내용들을 강의 영상에서 설명 드릴 내용들 입니다.