Kubernetes 컨테이너 모범 사례: 상태 확인

TL; DR

• 컨테이너와 마이크로서비스에 대한 높은 가시성을 달성하려면 로그와 기본 지표만으로는 충분하지 않습니다.
• 더 빠른 복구와 향상된 탄력성을 위해 애플리케이션은 HOP(High Observability 원칙)를 적용해야 합니다.
• 애플리케이션 수준에서 NOP에는 적절한 로깅, 긴밀한 모니터링, 온전성 검사 및 성능/전환 추적이 필요합니다.
• NOR의 요소로 검사 사용 준비 프로브 и 활성 프로브 쿠 버네 티스.

상태 확인 템플릿이란 무엇입니까?

미션 크리티컬하고 가용성이 높은 애플리케이션을 설계할 때 내결함성과 같은 측면을 고려하는 것이 매우 중요합니다. 장애로부터 신속하게 복구되는 애플리케이션은 내결함성이 있는 것으로 간주됩니다. 일반적인 클라우드 애플리케이션은 각 구성 요소가 별도의 컨테이너에 배치되는 마이크로서비스 아키텍처를 사용합니다. 그리고 클러스터를 설계할 때 k8s의 애플리케이션 가용성을 높이려면 특정 패턴을 따라야 합니다. 그중에는 상태 확인 템플릿이 있습니다. 이는 애플리케이션이 정상임을 k8s와 통신하는 방법을 정의합니다. 이는 Pod가 실행 중인지 여부뿐 아니라 요청을 수신하고 응답하는 방법에 대한 정보이기도 합니다. Kubernetes가 포드 상태에 대해 더 많이 알수록 트래픽 라우팅 및 로드 밸런싱에 대해 더 현명한 결정을 내릴 수 있습니다. 따라서 높은 관찰 가능성 원칙을 통해 애플리케이션은 적시에 요청에 응답할 수 있습니다.

높은 관찰 가능성 원칙(HOP)

높은 관찰 가능성의 원칙은 다음 중 하나입니다. 컨테이너화된 애플리케이션 설계 원칙. 마이크로서비스 아키텍처에서 서비스는 요청이 어떻게 처리되는지(그리고 올바르게 처리되는지) 신경 쓰지 않지만, 중요한 것은 수신 서비스로부터 응답을 받는 방법입니다. 예를 들어 사용자를 인증하기 위해 한 컨테이너는 특정 형식의 응답을 기대하면서 다른 컨테이너에 HTTP 요청을 보냅니다. 그게 전부입니다. PythonJS도 요청을 처리할 수 있고 Python Flask가 응답할 수 있습니다. 컨테이너는 서로 숨겨진 내용을 담고 있는 블랙박스와 같습니다. 그러나 NOP 원칙에 따르면 각 서비스는 상태와 준비 상태, 내결함성 상태를 나타내는 여러 API 엔드포인트를 노출해야 합니다. Kubernetes는 라우팅 및 로드 밸런싱을 위한 다음 단계를 고려하기 위해 이러한 지표를 요청합니다.

잘 설계된 클라우드 애플리케이션은 표준 I/O 스트림 STDERR 및 STDOUT을 사용하여 주요 이벤트를 기록합니다. 다음은 중앙 모니터링 시스템(예: Prometheus) 및 로그 수집 시스템(ELK 소프트웨어 제품군)에 로그를 전달하는 filebeat, logstash 또는 fluentd와 같은 보조 서비스입니다. 아래 다이어그램은 상태 테스트 패턴 및 높은 관찰 가능성 원칙에 따라 클라우드 애플리케이션이 작동하는 방식을 보여줍니다.

Kubernetes에서 상태 확인 패턴을 어떻게 적용하나요?

기본적으로 k8s는 컨트롤러(배포, 레플리카세트, 데몬세트, StatefulSet 등). 어떤 이유로 포드가 떨어진 것을 발견한 컨트롤러는 포드를 다시 시작하거나 다른 노드로 이동하려고 시도합니다. 그러나 포드는 실행 중이라고 보고할 수 있지만 자체적으로는 작동하지 않습니다. 예를 들어 보겠습니다. 애플리케이션이 Apache를 웹 서버로 사용하고 클러스터의 여러 Pod에 구성 요소를 설치했습니다. 라이브러리가 잘못 구성되었으므로 애플리케이션에 대한 모든 요청은 코드 500(내부 서버 오류)으로 응답합니다. 배송 확인 시 팟 상태를 확인하면 성공적인 결과를 얻을 수 있지만 고객의 생각은 다릅니다. 이 바람직하지 않은 상황을 다음과 같이 설명하겠습니다.

이 예에서는 k8s가 기능 점검. 이러한 유형의 확인에서 kubelet은 컨테이너의 프로세스 상태를 지속적으로 확인합니다. 프로세스가 중지되었음을 이해하면 프로세스를 다시 시작합니다. 단순히 애플리케이션을 다시 시작하여 오류를 해결할 수 있고 오류 발생 시 프로그램이 종료되도록 설계된 경우 NOP 및 상태 테스트 패턴을 따르려면 프로세스 상태 확인만 하면 됩니다. 유일한 유감스러운 점은 다시 시작해도 모든 오류가 제거되지는 않는다는 것입니다. 이 경우 k8s는 포드 문제를 식별하는 2가지 더 깊은 방법을 제공합니다. 활성 프로브 и 준비 프로브.

활성 프로브

동안 활성 프로브 kubelet은 3가지 유형의 검사를 수행합니다. 즉, 포드가 실행 중인지 여부뿐 아니라 요청을 수신하고 적절하게 응답할 준비가 되었는지도 확인합니다.

• Pod에 대한 HTTP 요청을 설정합니다. 응답에는 200~399 범위의 HTTP 응답 코드가 포함되어야 합니다. 따라서 코드 5xx 및 4xx는 프로세스가 실행 중임에도 불구하고 포드에 문제가 있음을 나타냅니다.
• HTTP가 아닌 서비스(예: Postfix 메일 서버)를 사용하여 포드를 테스트하려면 TCP 연결을 설정해야 합니다.
• Pod에 대한 임의의 명령을 (내부적으로) 실행합니다. 명령 완료 코드가 0이면 확인이 성공한 것으로 간주됩니다.

이것이 어떻게 작동하는지에 대한 예입니다. 다음 Pod 정의에는 HTTP 요청 시 500 오류를 발생시키는 NodeJS 애플리케이션이 포함되어 있습니다. 이러한 오류를 수신할 때 컨테이너가 다시 시작되는지 확인하기 위해 livenessProbe 매개변수를 사용합니다.

apiVersion: v1
kind: Pod
metadata:
 name: node500
spec:
 containers:
   - image: magalix/node500
     name: node500
     ports:
       - containerPort: 3000
         protocol: TCP
     livenessProbe:
       httpGet:
         path: /
         port: 3000
       initialDelaySeconds: 5

이는 다른 포드 정의와 다르지 않지만 객체를 추가합니다. .spec.containers.livenessProbe. 모수 httpGet HTTP GET 요청이 전송되는 경로를 수락합니다(이 예에서는 /, 그러나 전투 시나리오에서는 다음과 같은 것이 있을 수 있습니다. /api/v1/status). 또 다른 livenessProbe는 매개변수를 허용합니다. initialDelaySeconds, 이는 지정된 시간(초) 동안 기다리도록 확인 작업에 지시합니다. 컨테이너를 시작하는 데 시간이 필요하고 다시 시작하면 한동안 사용할 수 없기 때문에 지연이 필요합니다.

이 설정을 클러스터에 적용하려면 다음을 사용하세요.

kubectl apply -f pod.yaml

몇 초 후에 다음 명령을 사용하여 Pod의 내용을 확인할 수 있습니다.

kubectl describe pods node500

출력이 끝나면 다음을 찾으십시오. 그게 뭐야?.

보시다시피 livenessProbe는 HTTP GET 요청을 시작했고, 컨테이너는 오류 500을 생성했으며(이것이 프로그래밍된 내용임) kubelet이 이를 다시 시작했습니다.

NideJS 애플리케이션이 어떻게 프로그래밍되었는지 궁금하다면 사용된 app.js 및 Dockerfile은 다음과 같습니다.

앱.js

var http = require('http');

var server = http.createServer(function(req, res) {
    res.writeHead(500, { "Content-type": "text/plain" });
    res.end("We have run into an errorn");
});

server.listen(3000, function() {
    console.log('Server is running at 3000')
})

도커 파일

FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]

다음 사항에 유의하는 것이 중요합니다. livenessProbe는 컨테이너가 실패한 경우에만 컨테이너를 다시 시작합니다. 다시 시작해도 컨테이너 실행을 방해하는 오류가 해결되지 않으면 kubelet은 문제를 해결하기 위한 조치를 취할 수 없습니다.

준비 프로브

readinessProbe는 문제 해결 작업을 제외하고 livenessProbes(GET 요청, TCP 통신 및 명령 실행)와 유사하게 작동합니다. 오류가 감지된 컨테이너는 다시 시작되지 않지만 들어오는 트래픽에서 격리됩니다. 컨테이너 중 하나가 많은 계산을 수행하거나 부하가 높아 응답 시간이 길어진다고 상상해 보세요. livenessProbe의 경우 응답 가용성 확인이 트리거되고(timeoutSeconds 확인 매개변수를 통해) 그 후 kubelet이 컨테이너를 다시 시작합니다. 시작되면 컨테이너는 리소스 집약적인 작업을 수행하기 시작하고 다시 시작됩니다. 이는 응답 속도가 필요한 애플리케이션에 매우 중요할 수 있습니다. 예를 들어, 도로에 있는 자동차가 서버의 응답을 기다리고 있는데 응답이 지연되어 자동차가 사고를 당하게 됩니다.

GET 요청 응답 시간을 5초 이하로 설정하는 redinessProbe 정의를 작성해 보겠습니다. 그러면 애플리케이션은 XNUMX초 후에 GET 요청에 응답합니다. pod.yaml 파일은 다음과 같아야 합니다.

apiVersion: v1
kind: Pod
metadata:
 name: nodedelayed
spec:
 containers:
   - image: afakharany/node_delayed
     name: nodedelayed
     ports:
       - containerPort: 3000
         protocol: TCP
     readinessProbe:
       httpGet:
         path: /
         port: 3000
       timeoutSeconds: 2

kubectl을 사용하여 포드를 배포해 보겠습니다.

kubectl apply -f pod.yaml

몇 초 정도 기다렸다가 readinessProbe가 어떻게 작동하는지 살펴보겠습니다.

kubectl describe pods nodedelayed

출력이 끝나면 일부 이벤트가 비슷한 것을 볼 수 있습니다. 이 하나.

보시다시피 kubectl은 확인 시간이 2초를 초과하면 Pod를 다시 시작하지 않았습니다. 대신 그는 요청을 취소했습니다. 수신 통신은 작동 중인 다른 포드로 리디렉션됩니다.

이제 포드가 오프로드되었으므로 kubectl은 요청을 다시 포드로 라우팅합니다. GET 요청에 대한 응답은 더 이상 지연되지 않습니다.

비교를 위해 수정된 app.js 파일은 다음과 같습니다.

var http = require('http');

var server = http.createServer(function(req, res) {
   const sleep = (milliseconds) => {
       return new Promise(resolve => setTimeout(resolve, milliseconds))
   }
   sleep(5000).then(() => {
       res.writeHead(200, { "Content-type": "text/plain" });
       res.end("Hellon");
   })
});

server.listen(3000, function() {
   console.log('Server is running at 3000')
})

TL; DR
클라우드 애플리케이션이 등장하기 전에는 로그가 애플리케이션 상태를 모니터링하고 확인하는 주요 수단이었습니다. 그러나 시정 조치를 취할 방법이 없었습니다. 로그는 오늘날에도 여전히 유용하며 긴급 상황을 분석하고 의사결정을 내리기 위해 로그를 수집하고 로그 수집 시스템으로 전송해야 합니다. [예를 들어 monit을 사용하는 클라우드 애플리케이션 없이 이 모든 작업을 수행할 수 있지만 k8s를 사용하면 훨씬 쉬워졌습니다. :) – 편집자 주. ]

오늘날에는 거의 실시간으로 수정이 이루어져야 하므로 애플리케이션은 더 이상 블랙박스일 필요가 없습니다. 아니요, 모니터링 시스템이 프로세스 상태에 대한 중요한 데이터를 쿼리하고 수집하여 필요한 경우 즉시 대응할 수 있도록 하는 엔드포인트를 표시해야 합니다. 이를 HOP(High Observability 원칙)를 따르는 성능 테스트 디자인 패턴이라고 합니다.

Kubernetes는 기본적으로 readinessProbe와 livenessProbe라는 두 가지 유형의 상태 확인을 제공합니다. 둘 다 동일한 유형의 검사(HTTP GET 요청, TCP 통신 및 명령 실행)를 사용합니다. 포드의 문제에 대응하여 내리는 결정이 다릅니다. livenessProbe는 오류가 다시 발생하지 않기를 바라며 컨테이너를 다시 시작하고, readinessProbe는 문제의 원인이 해결될 때까지 수신 트래픽에서 포드를 격리합니다.

적절한 애플리케이션 설계에는 두 가지 유형의 검사가 모두 포함되어야 하며, 특히 예외가 발생하는 경우 충분한 데이터를 수집하는지 확인해야 합니다. 또한 모니터링 시스템(Prometheus)에 중요한 상태 지표를 제공하는 데 필요한 API 엔드포인트도 표시되어야 합니다.

출처 : habr.com