Kubernetes 모범 사례. 준비 상태 및 활동성 테스트를 통해 Kubernetes 활동성 검증

Kubernetes 모범 사례. 작은 컨테이너 만들기
Kubernetes 모범 사례. 네임스페이스가 있는 Kubernetes의 구성

분산 시스템은 시스템이 제대로 작동하려면 이동하고 변화하는 요소가 많기 때문에 관리하기 어려울 수 있습니다. 요소 중 하나에 오류가 발생하면 시스템은 이를 감지하고 우회하여 수정해야 하며 이 모든 작업이 자동으로 수행되어야 합니다. 이 Kubernetes 모범 사례 시리즈에서는 Kubernetes 클러스터의 상태를 테스트하기 위해 준비 및 활성 테스트를 설정하는 방법을 알아봅니다.

상태 확인은 애플리케이션 인스턴스가 실행 중인지 여부를 시스템에 알리는 간단한 방법입니다. 애플리케이션 인스턴스가 다운되면 다른 서비스는 이에 액세스하거나 요청을 보내서는 안 됩니다. 대신 이미 실행 중이거나 나중에 시작될 애플리케이션의 다른 인스턴스로 요청을 보내야 합니다. 또한 시스템은 애플리케이션의 손실된 기능을 복원해야 합니다.

기본적으로 Kubernetes는 포드 내의 모든 컨테이너가 실행 중일 때 포드로 트래픽을 보내기 시작하고 충돌이 발생하면 컨테이너를 재부팅합니다. 이 기본 시스템 동작은 처음에는 충분할 수 있지만 사용자 정의 온전성 검사를 사용하면 제품 배포의 안정성을 향상시킬 수 있습니다.

다행스럽게도 Kubernetes를 사용하면 이 작업을 매우 쉽게 수행할 수 있으므로 이러한 검사를 무시할 이유가 없습니다. Kubernetes는 두 가지 유형의 상태 확인을 제공하며 각 사용 방식의 차이점을 이해하는 것이 중요합니다.

준비 테스트는 애플리케이션이 트래픽을 처리할 준비가 되었음을 Kubernetes에 알리기 위해 설계되었습니다. 서비스가 포드에 트래픽을 전송하도록 허용하기 전에 Kubernetes는 준비 확인이 성공했는지 확인해야 합니다. 준비 테스트가 실패하면 Kubernetes는 테스트가 통과할 때까지 Pod로 트래픽 전송을 중지합니다.

활동성 테스트는 Kubernetes에 애플리케이션이 살아 있는지 죽었는지 알려줍니다. 첫 번째 경우 Kubernetes는 이를 그대로 두고 두 번째 경우에는 죽은 Pod를 삭제하고 새 Pod로 교체합니다.

애플리케이션이 준비되고 실행되는 데 1분이 걸리는 시나리오를 상상해 보겠습니다. 워크플로가 이미 시작되었더라도 애플리케이션이 완전히 로드되어 실행될 때까지 서비스가 작동을 시작하지 않습니다. 이 배포를 여러 복사본으로 확장하려는 경우에도 문제가 발생합니다. 왜냐하면 해당 복사본은 완전히 준비될 때까지 트래픽을 수신해서는 안 되기 때문입니다. 그러나 기본적으로 Kubernetes는 컨테이너 내부 프로세스가 시작되자마자 트래픽 전송을 시작합니다.

준비 테스트를 사용할 때 Kubernetes는 서비스가 새 복사본으로 트래픽을 보낼 수 있도록 허용하기 전에 애플리케이션이 완전히 실행될 때까지 기다립니다.

애플리케이션이 오랫동안 정지되어 요청 처리가 중단되는 또 다른 시나리오를 상상해 보겠습니다. 프로세스가 계속 실행됨에 따라 기본적으로 Kubernetes는 모든 것이 정상이라고 가정하고 작동하지 않는 Pod에 요청을 계속 보냅니다. 그러나 Liveness를 사용하면 Kubernetes는 애플리케이션이 더 이상 요청을 처리하지 않는다는 것을 감지하고 기본적으로 죽은 Pod를 다시 시작합니다.

준비 상태와 실행 가능성이 어떻게 테스트되는지 살펴보겠습니다. 테스트 방법에는 HTTP, Command, TCP의 세 가지가 있습니다. 그 중 하나를 사용하여 확인할 수 있습니다. 사용자를 테스트하는 가장 일반적인 방법은 HTTP 프로브입니다.

애플리케이션이 HTTP 서버가 아니더라도 애플리케이션 내부에 경량 HTTP 서버를 생성하여 활동성 테스트와 상호 작용할 수 있습니다. 그 후 Kubernetes는 포드에 대한 핑을 시작하고 HTTP 응답이 200 또는 300ms 범위에 있으면 포드가 정상임을 나타냅니다. 그렇지 않으면 모듈이 "비정상"으로 표시됩니다.

명령 테스트의 경우 Kubernetes는 컨테이너 내부에서 명령을 실행합니다. 명령이 종료 코드 1으로 반환되면 컨테이너는 정상으로 표시됩니다. 그렇지 않으면 255~XNUMX의 종료 상태 번호를 수신하면 컨테이너가 "sick"으로 표시됩니다. 이 테스트 방법은 HTTP 서버를 실행할 수 없거나 실행하고 싶지 않지만 애플리케이션의 상태를 확인하는 명령을 실행할 수 있는 경우에 유용합니다.

최종 검증 메커니즘은 TCP 테스트입니다. Kubernetes는 지정된 포트에서 TCP 연결 설정을 시도합니다. 이것이 가능하다면 컨테이너는 정상으로 간주되고, 그렇지 않으면 실행 불가능한 것으로 간주됩니다. 이 방법은 HTTP 요청 또는 명령 실행을 사용한 테스트가 제대로 작동하지 않는 시나리오를 사용하는 경우 유용할 수 있습니다. 예를 들어 TCP를 사용하는 확인을 위한 주요 서비스는 gRPC 또는 FTP입니다.

다양한 매개변수를 사용하여 여러 가지 방법으로 테스트를 구성할 수 있습니다. 실행 빈도, 성공 및 실패 임계값, 응답 대기 시간을 지정할 수 있습니다. 자세한 내용은 준비 및 활성 테스트 설명서를 참조하세요. 그러나 Liveness 테스트를 설정할 때 매우 중요한 점이 하나 있습니다. 바로 테스트 지연initialDelaySeconds의 초기 설정입니다. 앞서 언급했듯이 이 테스트가 실패하면 모듈이 다시 시작됩니다. 따라서 애플리케이션이 준비될 때까지 테스트가 시작되지 않도록 해야 합니다. 그렇지 않으면 애플리케이션이 다시 시작되는 순환을 시작합니다. P99 시작 시간 또는 버퍼의 평균 애플리케이션 시작 시간을 사용하는 것이 좋습니다. 애플리케이션의 시작 시간이 빨라지거나 느려지면 이 값을 조정해야 합니다.

대부분의 전문가는 상태 점검이 모든 분산 시스템에 대한 필수 점검이며 Kubernetes도 예외는 아니라는 점을 확인합니다. 서비스 상태 확인을 사용하면 Kubernetes가 안정적이고 문제 없이 작동할 수 있으며 사용자가 쉽게 사용할 수 있습니다.

조만간 계속...

일부 광고 🙂

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $4.99부터 시작하는 개발자용 클라우드 VPS, 귀하를 위해 우리가 발명한 고유한 보급형 서버 아날로그: VPS(KVM) E5-2697 v3(6코어) 10GB DDR4 480GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

Dell R730xd는 암스테르담의 Equinix Tier IV 데이터 센터에서 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com