이번 섹션에서는 Application 개발자가 꼭 알아야 하는 Pod 기능들이라는 주제로 여러 얘기 들을 해볼 건데요.

왜 개발자가 꼭 알아야 되냐면, 이번에 배우는 Pod의 기능들은 개발 로직이 받쳐주지 못하면, 써먹을 수 없는 기능들 이라서 그래요. 그래서 내 App이 쿠버네티스 환경 배포된다고 했을 때, 개발자 입장에서는 그 로직들을 잘 구현해 줘야 하고, 데브옵스 엔지니어 입장에서는 개발자에게 이런 로직들이 꼭 필요하다고 잘 얘기할 수 있어야 됩니다.

그럼 블로그를 시작해 볼께요.

Application 개발자가 꼭 알아야 하는 Pod 기능들

아래 그림을 보면, 워커노드 위에 [Pod가 생성]되는 과정에서 특정 노드(nodeSelector)를 지정 할 수가 있었고요.  이 워커노드에 리소스(resource)는 내 Pod에서 지정된 리소스보다 많이 있어야 겠죠. 그럼 DockerHub에서 이미지(image)를 가져와서 컨테이너와 App이 만들어 집니다. 이제 다음으로 [Pod가 기동하고 운영]되는 과정이 있는데, 여기서부터 컨테이너 안에 Application 개발이랑 관련된 내용들이 시작 됩니다.

이제 여기서 이전에 배웠던 내용을 얘기해 볼게요.

Probe를 설정하면 kubelet이, App에 헬스 체크 API를 날려주기 때문에 App에는 이 API들에 마춰서 Health를 체크를 해주는 로직이 필요 했고요. Comfigmap을 통해서 환경 변수를 줄 수 있었고, Application에서는 파라미터를 받아서 처리를 해주는 설정이 있어야 됐어요.

그리고 또 민감하게 다뤄야 하는 설정 파일의 경우, Secret을 통해 컨테이너로 마운팅 할 수 있었고, App에서 이 파일에 접근하는 로직을 통해서 데이터를 읽을 수가 있어요.

그리고 파일을 저장하고, 영구적으로 보관해야 되는 경우,  PV를 통해서 워커노드에 넣을 수 있는데 이것도 개발 로직과 관련된 부분이라고 볼 수 있겠고요.

여기까지는 Sprint1에서 배웠던 내용 이였고. 워밍업 이였습니다. 😀

이제부터가 이번 섹션에서 배울 내용들을 설명드릴 건데, 잘 들어 주시길 바랄께요.

위 그림을 보시면, 수집 서버 입장에서 모든 Pod의 정보를 조회해 볼 목적으로 API를 날리는 상황이라고 해볼게요. 근데 Service에서는 pod로 트래픽을 랜덤하게 보내주기 때문에, 트래픽을 여러번 시도해야지 모든 Pod를 식별 할 수 있고. 이런 구조는 많은 네트워크 트래픽을 유발 시키기 때문에 좋지 않은 구조입니다.

기존 VM 환경에서는 내가 배포할 App에 대해서 고정 IP가 정해져 있었고, 이 IP들을 모두 수집서버에 Config로 등록해서 딱 필요한 만큼의 조회 트래픽을 날렸었거든요. 근데 Pod는 IP가 자동 생성 되기도 하지만, Pod가 재생성 됐을 때 이 IP가 변경되기 때문에 쿠버네티스 환경에서 수집서버는 내가 정보를 조회 해야할 Pod들 한테 트래픽을 보내기가 힘들어 졌습니다.

그럼 쿠버네티스 환경에서는 이런 상황을 어떤 구조로 바꿔서 해결해야 되냐면, Pod 스스로가 자신의 Pod 정보를 수집 서버에 전송해 주는  구성으로 만들어야 되요. 그리고 이러기 위해서  App에서 내 Pod 정보를 조회하는 로직이 필요한 거고요. 그 로직에는 이렇게 3가지 방식이 있는데, 이 방법들에 대한 차이와 사용법을 강의 수업에서 설명 드려요.

이렇게 마이크로 서비스 아키텍쳐에서 전체 네트워크 트래픽을 줄이기 위해서 수집서버가 주기적으로 Pod 상태를 조회 하는게 아닌 각 Application들이 자신의 상태가 변경이 될 때마다 수집 서버로 API를 전송하는 방법을 쓰고요.

이외에도 Service를 통해서 특정 Pod에 호출이 된 다음에, 이후에는 이 두 Pod 끼리만 서로 양방향 통신을 해야 되는 경우 있습니다. 대표적으로 P2P 통신이고요. 우리가 메세지 관련된 어플리케이션을 만들 때, 그 통신 로직에 내 IP 주소를 넣어야 되요. 시스템 성능적인 면이나, 마찬가지로 전체 네트워크 트래픽을 줄이는 데 유리해요. 

그래서 이렇게 개발 입장에서도 내 Pod의 IP 정보가 필요한 상황은 많다라는 말씀을 드리고 싶습니다.

이제 다음으로 Pod가 종료되는 상황에 대해서 얘기를 해볼께요.

이건 정말 이전에 배웠던 probe 만큼이나 꼭 필요하고 중요한 내용이에요.

통상 Applicaiton이 중단되는 경우는 장애가 발생하거나, 업그레이드, 혹은 시스템 점검이 있어서, 공지를 하고 내리기도 해요. 그리고 주로 새벽에 작업을 하기 때문에 이때 App을 종료시키다가 에러가 좀 나도 딱히 문제라고 생각하지 않습니다. 시스템을 내린 이후에 로그를 볼 생각 자체도 잘 안하고요. 

그래서 지금까지 시스템 종료에 대해서 덜 중요하게 생각을 했을 수 있는데, 쿠버네티스 환경에서는 업그레이드나 스케일링들이 운영중도 빈번하게 일어나기 때문에 이런 상황에도 App 종료에 대한 로그를 계속 지켜볼게 아니라면, 이젠 App이 안전하게 종료되도록 만드는 부분이 매우 중요해 졌습니다.

그리고 쿠버네티스 또한 App 종료에 대해서 지원해 주는 기능들이 있는데, 이 기능들에 대해서 간략하게 설명 드릴께요.

Pod 삭제 명령을 받으면 kubelet은 App한테 종료 신호를 보내고요.  App이 스스로 종료될 때까지 기다려요. 근데 어느 정도 시간이 지나도 App이 종료되지 않으면 강제로 Pod를 삭제 시켜 버리고요. 그래서 App에서는종료신호를 받았을 때, 현재 실행중인 App들을 잘 정리하는 로직을 만들어 놔야 합니다. App이 어떤 정리를 해야 되는 지에 대한 부분은 강의에서 자세히 말씀을 드릴 거고요.

그리고 또 App은 종료 신호와는 별개로 내부적으로 메모리 릭이 나거나 해서 장애가 발생하고, 종료 될 수도 있거든요.  이럴 때 쿠버네티스가 알아서 컨테이너를 리스타트 시켜주기 때문에 걱정할 필요는 없지만, 그래도 한번씩 이전 컨테이너가 왜 재시작 됐는지에 대한 사유는 조회를 해봐야 되요.

그래서 kubectl로 이전 컨테이너의 상태를 확인하는 방법들을 알려드릴 거고요. 또 App이 종료될 때 특정 파일에 에러에 대한 사유를 저장해 놓으면, Pod에는 이걸 kubectl로 볼 수 있게 해주는 기능도 있습니다.

그리고 마지막으로 이렇게 Pod의 생성과 운영, 그리고 종료에 따라  Pod와 컨테이너 상태에 대해서 얘기를 해볼께요.

Pod의 상태는 Phase라는 속성에 있고요. 이렇게 각각의 진행에 따라 그 값들이 달라져요.

그리고 Pod 종료시에 Succeded와 failed이 있는 걸 보면, 쿠버네티스는 종료에 대해서 성공적인 종료와, 실패적인 종료를 구분해 놨다는 게 느껴지시죠? 그리고 Pod에 상태가 있지만, 컨테이너에도 별도로 상태가 또 존재합니다.

containerStatuses라는 속성이고요. 이건 좀 단순해 보일 수 있는데, 여기에 이렇게 세부적인 Reason이 또 있어요.

여기 CrashLoopBackOff는 Pod가 재대로 기동이 안될 때 대시보드에서 자주 볼 수 있는데, 실제 Pod는 Pending이고, 컨테이너는 waiting상태에서 이 reason 속성을 화면에 보여줬던 거죠.

그리고 종료에 있어서는 두 가지 Completed와 Error가 있습니다. 일반적으로 컨테이너가 정상 종료되면 Completed고, Pod도 Succeeded로 끝나는데, 한 Pod에는 컨테이너는 두 개 이상 있을 수 있기 때문에, 이때는 컨테이너 하나라도 Error가 있으면 Pod는 Failed 상태가 끝나게 되요.

그래서 다시 Pod 종료에 대한 상태를 정리하면,

SIGTERM을 받은 App이 정상적으로 자원을 정리하고 스스로 종료가 되면 컨테이너의 상태가 Completed고 Pod도 Succeeded로 끝나지만, 스스로 정리를 다 못하고, 강제 삭제가 됐을 때는 컨테이너 상태는 Error고 Pod의 상태는 Failed로 끝나는 거에요.

그럼 이번 블로그는  여기까지고요, 해당 강의에서는 아래 내용들에 대해서 더 다룹니다 😀

[쿠버네티스 어나더 클래스] : https://inf.run/3oKqK

내 Pod 정보를 API로 노출시키기

내 Application을 안정적으로 종료하기

ps. 한번도 좋아요♡를 안 준 사람은 있어도, 한번만 좋아요♡를 준 사람은 없다. 당신은 어떤 사람인가요? :)