App Mesh Kubernetes 문제 해결

이 주제에서는 Kubernetes에서 App Mesh를 사용할 때 발생할 수 있는 일반적인 문제를 자세히 설명합니다.

Kubernetes에서 생성된 App Mesh 리소스를 App Mesh에서 찾을 수 없음

증상

Kubernetes 사용자 지정 리소스 정의 (CRD) 를 사용하여 App Mesh 리소스를 생성했지만, 또는 API를 사용할 때 생성한 리소스가 App Mesh에 표시되지 않습니다. AWS Management Console

해결 방법

App Mesh용 Kubernetes 컨트롤러의 오류가 원인일 수 있습니다. 자세한 내용은 문제 해결을 참조하십시오. GitHub 컨트롤러 로그에서 컨트롤러가 리소스를 생성할 수 없음을 나타내는 오류나 경고가 있는지 확인합니다.

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller)

문제가 여전히 해결되지 않으면 문제를 제기하거나 AWS Support에 GitHub 문의하세요.

Envoy 사이드카를 삽입한 후 포드의 준비 상태 및 활성화 상태 확인이 실패함

증상

애플리케이션용 포드는 이전에 성공적으로 실행되었지만 Envoy 사이드카를 포드에 삽입한 후에는 준비 상태 및 활성화 상태 확인이 실패하기 시작합니다.

해결 방법

포드에 삽입된 Envoy 컨테이너가 App Mesh의 Envoy Management Service로 부트스트랩되었는지 확인하세요. Envoy가 오류 텍스트를 나타내며 App Mesh Envoy Management Service에서 연결이 끊김에서 오류 코드를 참조하여 오류를 확인할 수 있습니다. 다음 명령을 사용하여 Envoy 로그에서 관련 포드를 검사할 수 있습니다.

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller) \
    | grep "gRPC config stream closed"

문제가 여전히 해결되지 않으면 문제를 제기하거나 AWS Support에 GitHub 문의하세요.

포드가 AWS Cloud Map 인스턴스로 등록 또는 등록 취소되지 않음

증상

Kubernetes 포드는 수명 주기의 AWS Cloud Map 일부로 등록 또는 등록 취소되지 않습니다. 포드가 성공적으로 시작되어 트래픽을 처리할 준비가 되었지만 수신이 불가능할 수 있습니다. 포드가 종료되더라도 클라이언트는 여전히 IP 주소를 유지하고 트래픽을 보내려고 시도하지만 실패할 수 있습니다.

해결 방법

이는 알려진 문제입니다. 자세한 내용은 문제가 있는 Kubernetes에서 Pod가 자동 등록/등록 취소되지 않음을 참조하십시오. AWS Cloud Map GitHub 포드, App Mesh 가상 노드 및 AWS Cloud Map 리소스 간의 관계로 인해 쿠버네티스용 App Mesh 컨트롤러가 비동기화되어 리소스가 손실될 수 있습니다. 예를 들어, 연결된 포드를 종료하기 전에 가상 노드 리소스를 Kubernetes에서 삭제하면 이러한 문제가 발생할 수 있습니다.

이 문제를 완화하려면:

• Kubernetes용 App Mesh 컨트롤러의 최신 버전을 실행하고 있는지 확인합니다.

• 가상 노드 정의에서 AWS Cloud Map namespaceName 및 가 올바른지 확인하세요serviceName.

• 가상 노드 정의를 삭제하기 전에 연결된 포드를 모두 삭제해야 합니다. 가상 노드와 연결된 포드를 식별하는 데 도움이 필요하면 App Mesh 리소스에 대한 포드가 실행 중인 위치를 확인할 수 없음 섹션을 참조하세요.

• 문제가 지속되면 다음 명령을 실행하여 컨트롤러 로그에서 근본적인 문제를 파악하는 데 도움이 될 수 있는 오류가 있는지 확인하세요.

  kubectl logs -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

• 컨트롤러 포드를 다시 시작하려면 다음 명령을 사용해 보세요. 이렇게 하면 동기화 문제가 해결될 수 있습니다.

  kubectl delete -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

문제가 여전히 해결되지 않으면 문제를 제기하거나 AWS Support에 GitHub 문의하세요.

App Mesh 리소스에 대한 포드가 실행 중인 위치를 확인할 수 없음

증상

Kubernetes 클러스터에서 App Mesh를 실행하는 경우 운영자는 지정된 App Mesh 리소스에 대해 워크로드 또는 포드가 실행 중인 위치를 확인할 수 없습니다.

해결 방법

Kubernetes 포드 리소스에는 해당 리소스가 연결된 메시 및 가상 노드가 주석으로 표시됩니다. 다음 명령을 사용하여 지정된 가상 노드 이름에 대해 실행 중인 포드를 쿼리할 수 있습니다.

kubectl get pods --all-namespaces -o json | \
    jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'

문제가 여전히 해결되지 않으면 문제를 제기하거나 AWS Support에 GitHub 문의하세요.

포드가 어떤 App Mesh 리소스로 실행되고 있는지 확인할 수 없음

증상

Kubernetes 클러스터에서 App Mesh를 실행하는 경우 운영자는 지정된 포드가 어떤 App Mesh 리소스로 실행되고 있는지 확인할 수 없습니다.

해결 방법

Kubernetes 포드 리소스에는 해당 리소스가 연결된 메시 및 가상 노드가 주석으로 표시됩니다. 다음 명령을 통해 포드를 직접 쿼리하여 메시 및 가상 노드 이름을 출력할 수 있습니다.

kubectl get pod pod-name -n namespace -o json | \
    jq '{ "mesh": .metadata.annotations."appmesh.k8s.aws/mesh", "virtualNode": .metadata.annotations."appmesh.k8s.aws/virtualNode" }'

문제가 여전히 해결되지 않으면 문제를 제기하거나 AWS Support에 GitHub 문의하세요.

클라이언트 Envoy는 IMDSv1이 비활성화된 상태에서 App Mesh Envoy Management Service와 통신할 수 없습니다.

증상

IMDSv1이 비활성화되면 클라이언트 Envoy는 App Mesh 제어 영역(Envoy Management Service)과 통신할 수 없습니다. v1.24.0.0-prod 이전의 App Mesh Envoy 버전에서는 IMDSv2 지원이 제공되지 않습니다.

해결 방법

이 문제를 해결하려면 다음 세 가지 중 한 가지 방법을 시도하면 됩니다.

• IMDSv2가 지원되는 App Mesh Envoy 버전 v1.24.0.0-prod 이상으로 업그레이드하세요.

• Envoy가 실행 중인 인스턴스에서 IMDSv1을 다시 활성화합니다. IMDSv1 복원에 대한 지침은 인스턴스 메타데이터 옵션 구성을 참조하세요.

• 서비스가 Amazon EKS에서 실행 중인 경우 자격 증명을 가져올 때는 서비스 계정용 IAM 역할(IRSA)을 사용하는 것이 좋습니다. IRSA 활성화 지침은 서비스 계정의 IAM 역할을 참조하세요.

문제가 여전히 해결되지 않으면 문제를 제기하거나 AWS Support에 GitHub 문의하세요.

App Mesh가 활성화되고 Envoy가 삽입된 경우 IRSA가 애플리케이션 컨테이너에서 작동하지 않음

증상

Amazon EKS용 App Mesh 컨트롤러를 사용하여 Amazon EKS 클러스터에서 App Mesh를 활성화하면 Envoy와 proxyinit 컨테이너가 애플리케이션 포드에 삽입됩니다. 애플리케이션은 IRSA를 가정할 수 없으며 대신 node role을 가정합니다. 포드 세부 정보를 설명하면 AWS_WEB_IDENTITY_TOKEN_FILE 또는 AWS_ROLE_ARN 환경 변수가 애플리케이션 컨테이너에 포함되어 있지 않다는 것을 알 수 있습니다.

해결 방법

AWS_WEB_IDENTITY_TOKEN_FILE 또는 AWS_ROLE_ARN 환경 변수가 정의된 경우 webhook는 포드를 건너뜁니다. 이러한 변수 중 어느 것도 제공하지 마세요. webhook이 자동으로 삽입합니다.

reservedKeys := map[string]string{
        "AWS_ROLE_ARN":                "",
        "AWS_WEB_IDENTITY_TOKEN_FILE": "",
    }
    ...
    for _, env := range container.Env {
        if _, ok := reservedKeys[env.Name]; ok {
            reservedKeysDefined = true
        }

문제가 여전히 해결되지 않으면 문제를 제기하거나 AWS Support에 GitHub 문의하세요.