

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# App Mesh Kubernetes 문제 해결
<a name="troubleshooting-kubernetes"></a>

**중요**  
지원 종료 공지: 2026년 9월 30일에는에 대한 지원을 중단할 AWS 예정입니다 AWS App Mesh. 2026년 9월 30일 이후에는 AWS App Mesh 콘솔 또는 AWS App Mesh 리소스에 더 이상 액세스할 수 없습니다. 자세한 내용은이 블로그 게시물 [Migrating from to Amazon ECS Service Connect를 참조 AWS App Mesh 하세요](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).

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

## Kubernetes에서 생성된 App Mesh 리소스를 App Mesh에서 찾을 수 없음
<a name="ts-kubernetes-missing-resources"></a>

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

**해결 방법**  
App Mesh용 Kubernetes 컨트롤러의 오류가 원인일 수 있습니다. 자세한 내용은 GitHub의 [문제 해결](https://github.com/aws/aws-app-mesh-controller-for-k8s/blob/master/docs/guide/troubleshooting.md)을 참조하세요. 컨트롤러 로그에서 컨트롤러가 리소스를 생성할 수 없음을 나타내는 오류나 경고가 있는지 확인합니다.

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

문제가 여전히 해결되지 않으면 [GitHub 문제](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)를 열거나 [AWS 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.

## Envoy 사이드카를 삽입한 후 포드의 준비 상태 및 활성화 상태 확인이 실패함
<a name="ts-kubernetes-pods-after-injection"></a>

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

**해결 방법**  
포드에 삽입된 Envoy 컨테이너가 App Mesh의 Envoy Management Service로 부트스트랩되었는지 확인하세요. [Envoy가 오류 텍스트를 나타내며 App Mesh Envoy Management Service에서 연결이 끊김](troubleshooting-setup.md#ts-setup-grpc-error-codes)에서 오류 코드를 참조하여 오류를 확인할 수 있습니다. 다음 명령을 사용하여 Envoy 로그에서 관련 포드를 검사할 수 있습니다.

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

문제가 여전히 해결되지 않으면 [GitHub 문제](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)를 열거나 [AWS 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.

## 포드가 AWS Cloud Map 인스턴스로 등록 또는 등록 취소되지 않음
<a name="ts-kubernetes-pods-cmap"></a>

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

**해결 방법**  
이는 알려진 문제입니다. 자세한 내용은 [포드가 AWS Cloud Map를 포함하는 Kubernetes에서 자동으로 등록/등록 취소되지 않음](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/159) GitHub 문제를 참조하세요. 포드, App Mesh 가상 노드 및 AWS Cloud Map 리소스 간의 관계로 인해 [Kubernetes용 App Mesh 컨트롤러](https://github.com/aws/aws-app-mesh-controller-for-k8s)가 비동기화되어 리소스가 손실될 수 있습니다. 예를 들어, 연결된 포드를 종료하기 전에 가상 노드 리소스를 Kubernetes에서 삭제하면 이러한 문제가 발생할 수 있습니다.

이 문제를 완화하려면:
+ Kubernetes용 App Mesh 컨트롤러의 최신 버전을 실행하고 있는지 확인합니다.
+ 가상 노드 정의에서 및 `serviceName`가 올바른지 확인합니다 AWS Cloud Map `namespaceName`.
+ 가상 노드 정의를 삭제하기 전에 연결된 포드를 모두 삭제해야 합니다. 가상 노드와 연결된 포드를 식별하는 데 도움이 필요하면 [App Mesh 리소스에 대한 포드가 실행 중인 위치를 확인할 수 없음](#ts-kubernetes-where-pod-running) 섹션을 참조하세요.
+ 문제가 지속되면 다음 명령을 실행하여 컨트롤러 로그에서 근본적인 문제를 파악하는 데 도움이 될 수 있는 오류가 있는지 확인하세요.

  ```
  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)
  ```

문제가 여전히 해결되지 않으면 [GitHub 문제](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)를 열거나 [AWS 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.

## App Mesh 리소스에 대한 포드가 실행 중인 위치를 확인할 수 없음
<a name="ts-kubernetes-where-pod-running"></a>

**증상**  
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")'
```

문제가 여전히 해결되지 않으면 [GitHub 문제](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)를 열거나 [AWS 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.

## 포드가 어떤 App Mesh 리소스로 실행되고 있는지 확인할 수 없음
<a name="ts-kubernetes-pod-running-as"></a>

**증상**  
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" }'
```

문제가 여전히 해결되지 않으면 [GitHub 문제](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)를 열거나 [AWS 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.

## 클라이언트 Envoy는 IMDSv1이 비활성화된 상태에서 App Mesh Envoy Management Service와 통신할 수 없습니다.
<a name="ts-kubernetes-imdsv1-disabled"></a>

**증상**  
`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` 복원에 대한 지침은 [인스턴스 메타데이터 옵션 구성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)을 참조하세요.
+ 서비스가 Amazon EKS에서 실행 중인 경우 자격 증명을 가져올 때는 서비스 계정용 IAM 역할(IRSA)을 사용하는 것이 좋습니다. IRSA 활성화 지침은 [서비스 계정의 IAM 역할](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)을 참조하세요.

문제가 여전히 해결되지 않으면 [GitHub 문제](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)를 열거나 [AWS 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.

## App Mesh가 활성화되고 Envoy가 삽입된 경우 IRSA가 애플리케이션 컨테이너에서 작동하지 않음
<a name="ts-kubernetes-irsa-not-working"></a>

**증상**  
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
        }
```

문제가 여전히 해결되지 않으면 [GitHub 문제](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)를 열거나 [AWS 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.