분산 시스템은 관리하기 어려울 수 있습니다. 큰 이유는 시스템이 작동하기 위해 모두 작동해야하는 움직이는 부품이 많기 때문입니다. 작은 부품이 파손되면 시스템이 이를 감지하고 주변 경로를 정하고 수리해야 합니다. 그리고 이 모든 것이 자동으로 수행 되어야 합니다!
상태 확인은 앱 인스턴스가 작동하는지 여부를 시스템에 알리는 간단한 방법입니다. 앱의 인스턴스가 작동하지 않으면 다른 서비스에서 액세스하거나 요청을 보내서는 안됩니다. 대신 준비된 앱의 다른 인스턴스로 요청을 보내거나 나중에 다시 시도해야 합니다. 또한 시스템은 앱을 정상 상태로 되돌려 야합니다.
기본적으로 Kubernetes는 포드 내부의 모든 컨테이너가 시작될 때 트래픽을 포드로 보내기 시작하고 컨테이너가 충돌하면 다시 시작합니다. 시작할 때 "충분히 충분"할 수 있지만 사용자 지정 상태 확인을 생성하여 배포를 더욱 강력하게 만들 수 있습니다. 다행히 쿠 버네 티스는 이것을 상대적으로 간단하게 만들어서 그렇게하지 않을 이유가 없습니다!
이 "Kubernetes Best Practices"에피소드에서는 준비 상태 및 활성 상태 프로브 의 미묘함 , 어떤 프로브를 언제 사용할지, Kubernetes 클러스터에서 설정하는 방법에 대해 알아 보겠습니다.
상태 확인 유형
Kubernetes는 두 가지 유형의 상태 확인을 제공하며 두 가지 유형의 차이점과 용도를 이해하는 것이 중요합니다.
Readiness
준비 상태 프로브는 앱이 트래픽을 제공 할 준비가되면 Kubernetes에 알리도록 설계되었습니다. Kubernetes는 서비스가 트래픽을 포드로 전송하도록 허용하기 전에 준비 상태 프로브가 통과하는지 확인합니다. 준비 상태 프로브가 실패하기 시작하면 Kubernetes는 통과 할 때까지 트래픽을 포드로 보내는 것을 중지합니다.
Liveness
Liveness 프로브는 Kubernetes에 앱이 살아 있는지 아니면 죽었는지 알려줍니다. 앱이 살아 있으면 Kubernetes는 그대로 둡니다. 앱이 종료 된 경우 Kubernetes는 포드를 제거하고 새 포드를 시작하여 교체합니다.
상태 확인이 도움이되는 방법
준비 상태 및 활성 상태 프로브가 더 강력한 앱을 빌드하는 데 도움이 될 수있는 두 가지 시나리오를 살펴 보겠습니다.
Readiness
앱이 워밍업 및 시작하는 데 1 분 정도 걸린다고 가정 해 보겠습니다. 프로세스가 시작된 경우에도 서비스가 시작되어 실행될 때까지 작동하지 않습니다. 여러 복사본을 갖도록이 배포를 확장하려는 경우에도 문제가 발생합니다. 새 복사본은 완전히 준비 될 때까지 트래픽을 수신해서는 안되지만 기본적으로 Kubernetes는 컨테이너 내부의 프로세스가 시작되는 즉시 트래픽을 보내기 시작합니다. 준비 상태 프로브를 사용하면 Kubernetes는 앱이 완전히 시작될 때까지 기다렸다가 서비스가 새 복사본으로 트래픽을 보낼 수 있도록합니다.
Liveness
앱에 심각한 교착 상태가 발생하여 무한정 중단되고 요청 처리가 중지되는 또 다른 시나리오를 상상해 보겠습니다. 프로세스가 계속 실행되기 때문에 기본적으로 Kubernetes는 모든 것이 정상이라고 생각하고 중단 된 포드에 계속 요청을 보냅니다. 활성 상태 프로브를 사용하여 Kubernetes는 앱이 더 이상 요청을 제공하지 않음을 감지하고 문제가되는 포드를 다시 시작합니다.
프로브 유형
다음 단계는 준비 상태와 활성 상태를 테스트하는 프로브를 정의하는 것입니다. 세 가지 유형의 프로브 (HTTP, 명령 및 TCP)가 있습니다. 활성 상태 및 준비 상태 확인을 위해 이들 중 하나를 사용할 수 있습니다.
HTTP
HTTP 프로브는 아마도 가장 일반적인 유형의 사용자 지정 활성 프로브 일 것입니다. 앱이 HTTP 서버가 아니더라도 앱 내부에 경량 HTTP 서버를 만들어 활성 상태 프로브에 응답 할 수 있습니다. Kubernetes는 경로를 ping하고 200 또는 300 범위에서 HTTP 응답을 받으면 앱을 정상으로 표시합니다. 그렇지 않으면 비정상으로 표시됩니다.
여기에서 HTTP 프로브에 대한 자세한 내용을 읽을 수 있습니다 .
Command
명령 프로브의 경우 Kubernetes는 컨테이너 내에서 명령을 실행합니다. 명령이 종료 코드 0과 함께 반환되면 컨테이너가 정상으로 표시됩니다. 그렇지 않으면 비정상으로 표시됩니다. 이 유형의 프로브는 HTTP 서버를 실행할 수 없거나 실행하고 싶지 않을 때 유용하지만 앱이 정상인지 여부를 확인할 수있는 명령을 실행할 수 있습니다.
여기에서 명령 프로브에 대한 자세한 내용을 읽을 수 있습니다 .
TCP
마지막 프로브 유형은 Kubernetes가 지정된 포트에서 TCP 연결을 설정하려고 시도하는 TCP 프로브입니다. 연결을 설정할 수있는 경우 컨테이너는 정상으로 간주됩니다. 그렇지 않으면 건강에 좋지 않은 것으로 간주됩니다.
HTTP 프로브 또는 명령 프로브가 제대로 작동하지 않는 시나리오가있는 경우 TCP 프로브가 유용합니다. 예를 들어 gRPC 또는 FTP 서비스는 이러한 유형의 프로브에 대한 주요 후보입니다.
여기에서 TCP 프로브에 대한 자세한 내용을 읽을 수 있습니다 .
초기 프로빙 지연 구성
프로브는 다양한 방법으로 구성 할 수 있습니다. 실행 빈도, 성공 및 실패 임계 값, 응답을 기다리는 시간을 지정할 수 있습니다. 프로브 구성에 대한 문서 는 다양한 옵션과 그 기능에 대해 매우 명확합니다.
그러나 활성 프로브를 사용할 때 구성해야하는 매우 중요한 설정이 하나 있습니다. 이것은 initialDelaySeconds 설정입니다.
위에서 언급했듯이 활성 상태 프로브 실패로 인해 포드가 다시 시작됩니다. 앱이 준비 될 때까지 프로브가 시작되지 않는지 확인해야합니다. 그렇지 않으면 앱이 계속 다시 시작되고 준비되지 않습니다!
p99 시작 시간을 initialDelaySeconds로 사용하거나 평균 시작 시간을 취하고 버퍼를 추가하는 것이 좋습니다 . 앱 시작 시간이 빨라지거나 느려지면이 번호를 업데이트해야합니다.
결론
대부분의 사람들은 상태 확인이 모든 분산 시스템의 요구 사항이며 Kubernetes도 예외는 아니라고 말합니다. 상태 확인을 사용하면 Kubernetes 서비스에 견고한 기반, 더 나은 안정성 및 더 높은 가동 시간이 제공됩니다. 고맙게도 Kubernetes를 사용하면 쉽게 할 수 있습니다!