포드 시작 시간

이 섹션에서는 포드 시작 시간과 관련된 일반적인 Cloud Service Mesh 문제와 해결 방법을 설명합니다. 추가 지원이 필요하면 지원 받기를 참조하세요.

포드 시작 및 Envoy 구성 동기화

일부 Cloud Service Mesh 및 Istio 환경에서 포드 시작 중에 발생하는 일반적인 문제는 애플리케이션 준비와 Envoy 프록시 구성 간의 동기화와 관련됩니다. 이 문제는 애플리케이션 컨테이너와 Envoy 사이드카가 동시에 시작되어 발생합니다. 애플리케이션은 Envoy 프록시가 초기화를 완료하고 컨트롤 플레인에서 구성을 수신하기 전에 준비를 알릴 수 있습니다. 이렇게 하면 수신 요청이 트래픽을 수신할 준비가 되지 않은 구성되지 않은 Envoy 프록시로 전달되는 경합 상태가 발생합니다. 이로 인해 트래픽을 전달할 사이드카가 없어지므로 애플리케이션 시작 초기 단계에서 요청이 삭제되거나 잘못 라우팅되거나 잘못 처리될 수 있습니다.

완화 전략

다음 섹션에서는 이 문제를 완화할 수 있는 방법을 설명합니다.

전역 메시 구성: holdApplicationUntilProxyStarts

첫 번째 옵션은 Istio 메시 구성에서 holdApplicationUntilProxyStarts: true를 설정하는 것입니다. 이 옵션은 기본적으로 사용 중지되어 있습니다. 이 플래그는 포드의 프록시가 트래픽을 수락할 준비가 될 때까지 애플리케이션 시작을 지연하는 후크를 추가합니다.

구성을 추가하면 이 경합은 제거되지만 이전에 사용 설정되지 않은 경우 새 포드의 애플리케이션 준비 시간이 지연될 수 있습니다.

준비 상태 프로브

또 다른 해결 방법은 애플리케이션 및 Envoy 상태 점검을 모두 통합하는 준비 프로브를 구현하는 것입니다. 준비 프로브는 포드가 트래픽을 수락할 준비가 되었음을 Kubernetes에 알립니다. 중요한 점은 준비 프로브 로직이 애플리케이션 준비뿐만 아니라 Envoy 프록시 상태도 확인해야 한다는 것입니다. Envoy의 관리자 포트에서 상태를 쿼리하여 확인할 수 있습니다. 두 점검을 결합하면 Kubernetes는 애플리케이션과 Envoy가 모두 완전히 초기화되고 구성될 때까지 트래픽이 포드로 전달되지 않도록 않습니다.

이 방식은 더 유연하고 더 복잡한 시작 및 준비 논리를 허용하지만 그만큼 더 복잡해집니다.

다음 코드에서 healthcheck.sh 파일을 만듭니다.

#!/bin/sh
APP_HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
  http://localhost:8080/health)
ENVOY_HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
  http://localhost:9901/ready)

if [[ "$APP_HEALTH" -eq 200 && "$ENVOY_HEALTH" -eq 200 ]]; then
  exit 0
else
  exit 1
fi

IP/포트를 애플리케이션 컨테이너 및 Envoy의 IP/포트로 바꿉니다.

다음 YAML 파일은 이전에 만든 스크립트를 사용하는 준비 프로브를 정의합니다.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-envoy
spec:
  containers:
  - name: application
    <…>
    readinessProbe:
      initialDelaySeconds: 15
      periodSeconds: 10
      failureThreshold: 3
      exec:
        command:
        - /healthcheck.sh # using the script
  - name: envoy
    <…>

다음 단계