Cloud Service Mesh 클라이언트 상태 이해
Cloud Service Mesh를 사용하여 애플리케이션 네트워킹을 처리할 때 다음 두 가지 주요 구성 요소를 고려하세요.
- 인프라 레이어. Envoy 사이드카 프록시 또는 프록시리스 gRPC 라이브러리와 같은 인프라 레이어는 애플리케이션을 대신하여 네트워킹을 처리하도록 구성됩니다.
- 컨트롤 플레인, Cloud Service Mesh 컨트롤 플레인은 인프라 레이어의 구성을 생성하고 이 구성을 인프라 레이어에 배포합니다.
Envoy 프록시 또는 gRPC 라이브러리가 초기화되면 xDS API를 사용하여 Cloud Service Mesh에 연결됩니다. 프록시 또는 라이브러리는 Cloud Service Mesh의 클라이언트 역할을 합니다. 클라이언트와 Cloud Service Mesh 간의 연결이 설정되면 Cloud Service Mesh는 구성 정보를 클라이언트에 다시 전송하고 필요에 따라 구성을 업데이트합니다.
경우에 따라 Cloud Service Mesh에 연결된 클라이언트를 확인하고 Cloud Service Mesh가 클라이언트에 대해 생성하는 구성을 검사하는 것이 좋습니다. 예를 들어 문제를 디버깅하거나, Cloud Service Mesh를 구성할 때 수행하는 작업이 클라이언트가 확인하는 구성에 어떤 영향을 주는지 확인하고 싶을 수 있습니다.
Cloud Service Mesh는 클라이언트 상태 검색 서비스(CSDS) API를 지원합니다. CSDS 클라이언트를 사용하여 이 API를 쿼리하세요. 이를 통해 Cloud Service Mesh에 연결된 클라이언트를 확인하고 Cloud Service Mesh가 클라이언트에 대해 생성하는 구성을 검사할 수 있습니다.
CSDS 클라이언트는 Envoy 저장소에서 가져올 수 있는 오픈소스 도구입니다. 다음 다이어그램은 CSDS 클라이언트가 Cloud Service Mesh의 CSDS API에 대한 정보를 Cloud Service Mesh에 쿼리하는 방법을 보여줍니다.
CSDS 클라이언트는 Cloud Service Mesh에 연결되고 사용자 인증 정보 집합과 함께 프로젝트 번호 및 네트워크 이름을 제공합니다. 그러면 Cloud Service Mesh는 연결된 다양한 Cloud Service Mesh 클라이언트에 대한 정보로 응답할 수 있습니다.
CSDS 클라이언트에 대한 자세한 내용은 README 파일을 참조하세요.
기본 요건
CSDS API에 연결하려면 CSDS 클라이언트가 필요합니다. 클라이언트를 가져오는 방법에는 두 가지가 있습니다.
- Cloud Shell을 사용하여 클라이언트를 빌드할 수 있습니다.
- 로컬 개발 머신에서 클라이언트를 빌드할 수 있습니다.
Cloud Shell을 사용하여 CSDS 클라이언트 빌드
Cloud Shell을 사용하여 CSDS 클라이언트를 빌드하려면 다음을 수행합니다.
- Cloud Shell 사용 중지 또는 재설정의 안내에 따라 Cloud Shell을 재설정합니다. 이렇게 하면 기존 구성이 빌드를 방해하지 않습니다.
- Google Cloud 콘솔에서 새 Cloud Shell 세션을 엽니다.
다음 명령어를 실행하여 CSDS 클라이언트를 빌드하는 데 사용하는 소스 코드를 가져오세요.
git clone https://github.com/envoyproxy/envoy-tools.git
CSDS 클라이언트 디렉터리로 이동하고 다음 명령어를 실행합니다.
cd envoy-tools/csds-client/ make init make build
빌드가 완료되면 다음 명령어로 테스트합니다.
csds-client -help
빌드가 성공하면 클라이언트에 대한 도움말 텍스트가 표시됩니다.
로컬 개발 머신에서 CSDS 클라이언트 빌드
오픈소스 저장소의 README 파일에 있는 안내에 따라 로컬 머신에 CSDS 클라이언트를 다운로드하고 빌드할 수 있습니다. 이를 위해서는 환경에 Go와 make 도구도 설정해야 합니다. 이 작업을 수행하지 않으려면 Go 및 make 도구가 제공되는 위의 Cloud Shell 안내를 따르세요.
추가 기본 요건
각 클라이언트의 노드 ID가 서비스 메시 내에서 고유해야 합니다. 여러 클라이언트가 동일한 노드 ID를 공유하는 경우, 하나의 구성, 즉 가장 최근에 Cloud Service Mesh에 연결된 클라이언트의 구성만 반환됩니다.
Google의 참조 패키지를 사용하는 경우 부트스트랩 파일에서 노드 ID를 수동으로 설정할 필요가 없습니다. 노드 ID는 자동으로 생성됩니다. 참조 패키지를 사용하지 않는 경우 각 부트스트랩 파일에서 노드 ID를 수동으로 설정해야 합니다.
Cloud Service Mesh를 구성하는 데 필요한 Identity and Access Management(IAM) 권한이 있는 사용자 계정에 액세스할 수 있어야 합니다. 다음 안내에서는 Google Cloud CLI를 사용해서 CSDS 클라이언트에 필요한 사용자 인증 정보를 생성하고 자동으로 제공합니다. 또는 CSDS 클라이언트를 사용하여 사용자 인증 정보를 직접 제공할 수 있습니다.
현재 Cloud Service Mesh에 연결된 클라이언트 확인
CSDS 클라이언트를 사용하여 Cloud Service Mesh 구성에 연결된 클라이언트를 확인할 수 있습니다.
이 정보를 확인하려면 다음 세부정보가 필요합니다.
사용자 인증 정보가 생성된 프로젝트의 ID
서비스 라우팅 API를 사용하는 경우 xDS 클라이언트가 가져오는 리소스에 따라 다음 중 하나
이전 API를 사용하는 경우 Cloud Service Mesh를 구성할 때 지정한 VPC 네트워크 이름입니다. 이 네트워크는 라우팅 규칙 맵의 전달 규칙에 의해 지정된 네트워크입니다.
서비스 라우팅 API
올바른 권한이 있는 계정에서 다음 명령어를 실행합니다.
gcloud auth application-default login \ --billing-project=BILLING_PROJECT_ID
다음 콘텐츠로 YAML 형식의 새 파일을 만듭니다.
node_matchers: - node_metadatas: - path: - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER value: string_match: exact: "PROJECT_NUMBER" - path: - key: TRAFFICDIRECTOR_MESH_SCOPE_NAME value: string_match: exact: "MESH_OR_SCOPE"다음 값을 바꿉니다.
PROJECT_NUMBER: 프로젝트 IDMESH_OR_SCOPE: xDS 클라이언트가 메시 리소스를 가져오는 경우mesh:프리픽스 다음에 실제 메시 이름을 사용합니다. xDS 클라이언트가 게이트웨이 리소스를 가져오는 경우scope:프리픽스 다음에 범위 매개변수 이름을 사용합니다.
gcloud CLI에서 생성된 사용자 인증 정보를 사용하는 CSDS 클라이언트를 실행하세요.
PATH_TO_CSDS_REQUEST_YAML_FILE을 이전 단계에서 만든 YAML 파일의 경로로 바꿉니다.csds-client \ -service_uri trafficdirector.googleapis.com:443 \ -platform gcp \ -authn_mode auto \ -api_version v3 \ -request_file PATH_TO_CSDS_REQUEST_YAML_FILE
다음과 비슷한 출력이 표시됩니다.
Client ID xDS stream type Config status 603e3524-d1d6-4a9e-9b26-39bcd633a7cb~10.128.0.5 ADS N/A 603e3524-d1d6-4a9e-9b26-39bcd633a7cb~10.128.0.5 LRS N/A 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 ADS N/A 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 LRS N/A d9577b61-fa3a-41d6-90bd-11c4fdd2f8c0~10.128.0.4 ADS N/A d9577b61-fa3a-41d6-90bd-11c4fdd2f8c0~10.128.0.4 LRS N/A f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6 ADS N/A f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6 LRS N/A
Client ID열에는 Cloud Service Mesh에 연결된 클라이언트의 클라이언트 ID가 표시됩니다. 이 클라이언트 ID는 Envoy 또는 프록시리스 gRPC에서 Cloud Service Mesh에 연결할 때 사용하는 부트스트랩 파일의node_id필드를 사용하여 제공됩니다.
이전 API
올바른 권한이 있는 계정에서 다음 명령어를 실행합니다.
gcloud auth application-default login \ --billing-project=BILLING_PROJECT_ID
다음 콘텐츠로 YAML 형식의 새 파일을 만듭니다.
node_matchers: - node_metadatas: - path: - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER value: string_match: exact: "PROJECT_NUMBER" - path: - key: TRAFFICDIRECTOR_NETWORK_NAME value: string_match: exact: "NETWORK_NAME"다음 값을 바꿉니다.
PROJECT_NUMBER: Google Cloud 프로젝트의 고유 IDNETWORK_NAME: 라우팅 규칙 맵의 전달 규칙으로 지정된 VPC 네트워크.
gcloud CLI에서 생성된 사용자 인증 정보를 사용하는 CSDS 클라이언트를 실행하세요.
PATH_TO_CSDS_REQUEST_YAML_FILE을 이전 단계에서 만든 YAML 파일의 경로로 바꿉니다.csds-client \ -service_uri trafficdirector.googleapis.com:443 \ -platform gcp \ -authn_mode auto \ -api_version v3 \ -request_file PATH_TO_CSDS_REQUEST_YAML_FILE
다음과 비슷한 출력이 표시됩니다.
Client ID xDS stream type Config status 603e3524-d1d6-4a9e-9b26-39bcd633a7cb~10.128.0.5 ADS N/A 603e3524-d1d6-4a9e-9b26-39bcd633a7cb~10.128.0.5 LRS N/A 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 ADS N/A 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 LRS N/A d9577b61-fa3a-41d6-90bd-11c4fdd2f8c0~10.128.0.4 ADS N/A d9577b61-fa3a-41d6-90bd-11c4fdd2f8c0~10.128.0.4 LRS N/A f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6 ADS N/A f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6 LRS N/A
Client ID열에는 Cloud Service Mesh에 연결된 클라이언트의 클라이언트 ID가 표시됩니다. 이 클라이언트 ID는 Envoy 또는 프록시리스 gRPC에서 Cloud Service Mesh에 연결할 때 사용하는 부트스트랩 파일의node_id필드를 사용하여 제공됩니다.
특정 Cloud Service Mesh 클라이언트의 구성 검사
이전 섹션에서 가져온 클라이언트 ID를 사용하여 Cloud Service Mesh가 특정 클라이언트에 전송하는 구성을 검사할 수 있습니다.
리소스 프로토의 세부 구성을 검사하여 특정 클라이언트가 사용 중인 xDS API 버전을 확인할 수 있습니다. 예를 들어 구성에 envoy.api.v2.Cluster가 표시되면 클라이언트가 v2 API를 사용하고 있음을 의미합니다.
구성에 envoy.api.v3.Cluster가 표시되는 경우 클라이언트가 v3 API를 사용하고 있는 것입니다. xDS v3만 지원됩니다. v2에서 v3로 마이그레이션하는 방법에 대한 자세한 내용은 xDS v2에서 xDS v3로 마이그레이션을 참조하세요.
서비스 라우팅 API
현재 Cloud Service Mesh에 연결된 클라이언트 확인에서 만든 YAML 파일을 업데이트합니다. 클라이언트 ID를 값으로 사용하는
node-id필드를 추가합니다.node_matchers: - node_id: exact: "CLIENT_ID" node_metadatas: - path: - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER value: string_match: exact: "PROJECT_NUMBER" - path: - key: TRAFFICDIRECTOR_MESH_SCOPE_NAME value: string_match: exact: "MESH_OR_SCOPE_NAME"다음 값을 바꿉니다.
CLIENT_ID: 구성을 검사할 클라이언트의 ID(예:projects/000000/networks/mesh:mesh1/nodes/00000000-0000-0000-0000-00000000~127.0.0.1)PROJECT_NUMBER: Google Cloud 프로젝트의 고유 IDMESH_OR_SCOPE: xDS 클라이언트가 메시 리소스를 가져오는 경우mesh:프리픽스 다음에 실제 메시 이름을 사용합니다. xDS 클라이언트가 게이트웨이 리소스를 가져오는 경우scope:프리픽스 다음에 범위 매개변수 이름을 사용합니다.
CSDS 클라이언트를 실행합니다. 클라이언트를 실행하면 JSON 파일이 생성됩니다. 이 파일에는 Cloud Service Mesh 클라이언트로 전송되는 구성이 포함되어 있습니다.
csds-client \ -service_uri trafficdirector.googleapis.com:443 \ -platform gcp \ -authn_mode auto \ -api_version v3 \ -request_file PATH_TO_CSDS_REQUEST_YAML_FILE \ -output_file FILENAME.JSON
다음 값을 바꿉니다.
PATH_TO_CSDS_REQUEST_YAML_FILE: YAML 파일의 경로FILENAME.JSON: CSDS 클라이언트의 출력이 포함된 파일의 이름
다음과 비슷한 출력이 표시됩니다.
Client ID xDS stream type Config status 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 ADS LDS SYNCED RDS SYNCED CDS STALE Config has been saved to FILENAME.JSONJSON 파일을 확인하여 자세한 xDS 구성을 검사할 수 있습니다. 이 출력에는 Cloud Service Mesh가 집계된 gRPC 스트림(ADS)을 사용하여 클라이언트에 전송한 개별 xDS 구성의 상태가 포함되어 있습니다.
이전 API
현재 Cloud Service Mesh에 연결된 클라이언트 확인에서 만든 YAML 파일을 업데이트합니다. 클라이언트 ID를 값으로 사용하는
node-id필드를 추가합니다.node_matchers: - node_id: exact: "CLIENT_ID" node_metadatas: - path: - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER value: string_match: exact: "PROJECT_NUMBER" - path: - key: TRAFFICDIRECTOR_NETWORK_NAME value: string_match: exact: "NETWORK_NAME"다음 값을 바꿉니다.
CLIENT_ID: 구성을 검사하는 클라이언트의 ID(예:f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6)PROJECT_NUMBER: Google Cloud 프로젝트의 고유 IDNETWORK_NAME: 라우팅 규칙 맵의 전달 규칙으로 지정된 VPC 네트워크
CSDS 클라이언트를 실행합니다. 클라이언트를 실행하면 JSON 파일이 생성됩니다. 이 파일에는 Cloud Service Mesh 클라이언트로 전송되는 구성이 포함되어 있습니다.
csds-client \ -service_uri trafficdirector.googleapis.com:443 \ -platform gcp \ -authn_mode auto \ -api_version v3 \ -request_file PATH_TO_CSDS_REQUEST_YAML_FILE \ -output_file FILENAME.JSON
다음 값을 바꿉니다.
PATH_TO_CSDS_REQUEST_YAML_FILE: YAML 파일의 경로FILENAME.JSON: CSDS 클라이언트의 출력이 포함된 파일의 이름
다음과 비슷한 출력이 표시됩니다.
Client ID xDS stream type Config status 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 ADS LDS SYNCED RDS SYNCED CDS STALE Config has been saved to FILENAME.JSONJSON 파일을 확인하여 자세한 xDS 구성을 검사할 수 있습니다. 이 출력에는 Cloud Service Mesh가 집계된 gRPC 스트림(ADS)을 사용하여 클라이언트에 전송한 개별 xDS 구성의 상태가 포함되어 있습니다.
상태 값
다음 테이블에는 사용자가 표시될 수도 있는 xDS 구성 상태 값이 나열되어 있습니다.
| 값 | 설명 |
|---|---|
UNKNOWN |
(기본값) 상태 정보를 사용할 수 없거나 알 수 없습니다. |
SYNCED |
Cloud Service Mesh가 클라이언트에 구성을 전송하고 클라이언트로부터 ACK를 수신했습니다. |
ERROR |
Cloud Service Mesh가 클라이언트에 구성을 전송하고 클라이언트로부터 NACK를 수신했습니다. |
STALE |
Cloud Service Mesh가 클라이언트에 구성을 전송했지만 클라이언트로부터 ACK 또는 NACK를 수신하지 못했습니다. |
NOT_SENT |
구성이 전송되지 않았습니다. |
N/A |
CSDS 클라이언트에 노드 ID가 포함되지 않았습니다. 연결된 모든 스트림이 반환되지만 구성 상태는 제공되지 않습니다. |
시각화 및 모니터링
CSDS 클라이언트 오픈소스 도구에는 시각화 및 지속적인 모니터링과 같은 사용하려는 추가 기능이 있습니다. 이러한 기능에 대한 자세한 내용은 오픈소스 저장소에서 README 파일을 참조하세요.
오류 메시지
프로젝트에서만 Cloud Service Mesh API를 사용 설정하면 CSDS 클라이언트에서 다음 오류 메시지가 표시될 수 있습니다.
rpc error: code = NotFound desc = Requested entity was not found.
이는 정상적인 동작입니다. Cloud Service Mesh 구성은 네트워크별로 범위가 지정됩니다. 아직 네트워크를 만들지 않고 CSDS 클라이언트를 실행하면 이 오류 메시지가 표시됩니다.
제한사항
- 엔드포인트 정보는 CSDS v3 API에서 사용할 수 없으므로 CSDS 응답에 포함되지 않습니다.
- 각 클라이언트의 노드 ID는 서비스 메시 내에서 고유해야 합니다. 여러 클라이언트가 동일한 노드 ID를 공유하는 경우, 하나의 구성, 즉 가장 최근에 Cloud Service Mesh에 연결된 클라이언트의 구성만 반환됩니다.
- yaml 파일의 노드 ID 필드에 백슬래시(\)가 표시되는 경우가 있습니다. 이 경우 구성 정보에 대해 CSDS API를 쿼리할 때 추가 백슬래시를 사용하여 백슬래시를 이스케이프 처리하세요. 이는 알려진 문제입니다.
다음 단계
- 일반적인 Cloud Service Mesh 문제 해결 정보는 Envoy를 사용하는 배포 문제 해결을 참조하세요.
- 프록시리스 gRPC 서비스를 배포할 때 구성 문제를 해결하려면 프록시리스 gRPC를 사용하는 배포 문제 해결을 참조하세요.