이 사용 사례에서 여러 GKE 네임스페이스가 포함된 네트워크를 지원하는 네트워크 관리자라고 가정합니다. 지연 시간 문제에 대한 알림을 받았으며 조직의 모바일 애플리케이션이 간헐적으로 느리고 시간이 초과되었다는 메시지를 받았습니다. 여러 사용자가 영향을 받고 있으며 최근에 애플리케이션을 배포하지 않았음을 알고 있습니다. 이 문제는 특정 GKE 클러스터와 관련이 있을 수 있습니다.
다음 사용 사례에서는 네트워크 토폴로지를 사용하여 GKE 배포 문제를 신속하게 해결하고 조사할 수 있는 방법을 보여줍니다.
토폴로지 세부정보
배포는 3개의 Google Cloud 리전(us-central1, europe-west1, asia-east1)에 걸쳐 있습니다. 모든 외부 클라이언트 요청은 여러 네임스페이스가 있는 세 리전 내의 세 클러스터에서 처리합니다. 3개의 비즈니스 리전(미주, EMEA, APAC) 중 하나에서 전달된 클라이언트 요청은 가장 가까운Google Cloud 리전의 애플리케이션 인스턴스에서 처리됩니다.
다음 토폴로지는 배포의 최상위 계층 구조를 보여줍니다.
네트워크 토폴로지 GKE 뷰 예시 토폴로지(확대하려면 클릭)
네트워크 지연 시간
이 시나리오에서는 Online-boutique라는 GKE 클러스터가 있다고 가정합니다. 외부 클라이언트와 GKE 클러스터 간의 지연 시간을 확인하여 이들 간의 지연 시간이 변경되었는지 확인합니다. 변경되었음을 발견하고 클러스터 노드를 추가 조사하기로 결정합니다.
토폴로지를 필터링하여 online-boutique 클러스터의 트래픽만 표시합니다.
필터 섹션에서 필터를 추가하여 노드와 해당 피어를 선택할 수 있습니다. 이 섹션은 통계 뷰가 아닌 측정항목 뷰에만 사용 가능합니다. 필터 추가를 클릭하고 노드 유형과 노드를 선택합니다.
필터를 적용하면 다음 예시와 같이 네트워크 토폴로지에 클러스터와 관련된 연결만 표시됩니다.
미주 지역의 외부 클라이언트부터 시작하여 미주 비즈니스 리전과 GKE 클러스터 사이의 트래픽 측정항목을 클릭합니다.
네트워크 토폴로지의 세부정보 창에 차트가 표시됩니다. 이 정보에는 선택한 항목과 연결된 항목 간의 인그레스 및 이그레스 트래픽이 포함됩니다. 예를 들어 네트워크 토폴로지에서는 초당 쿼리 수(QPS) 및 HTTP 요청 지연 시간에 대한 최신 값을 제공합니다.
요청 지연 시간 차트에는 50번째, 95번째, 99번째 백분위수 값이 표시됩니다. 이 예시에서는 모든 지연 시간 값이 예상보다 높다고 가정합니다.
시계열 차트를 6주로 확장하려면 세부정보 창 상단에서 6주를 선택합니다.
약 2시간 전에 발생한 첫 번째 문제가 보고되었을 때 크게 증가한 것을 확인했습니다. 이 문제는 GKE 포드의 지연 시간 증가와 관련이 있다고 확신합니다.
문제를 개략적으로 파악하고 GKE 노드를 추가 조사합니다. GKE 노드 문제 해결에 대한 자세한 내용은 GKE 연결 문제 해결을 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Use case: Troubleshoot GKE connectivity\n=======================================\n\nIn this use case, you're a network administrator supporting a network that\nincludes several GKE namespaces. You've been alerted of a latency\nproblem and have been told that your organization's mobile application is\nintermittently\nslow and timing out. You know that a number of different users are affected, and\nthat there have been no recent application deployments. The issue is likely\nrelated to a specific GKE cluster.\n\nThe following use case demonstrates how Network Topology can help you\nquickly troubleshoot and investigate issues in your GKE\ndeployment.\n\nTopology details\n----------------\n\nThe deployment spans three Google Cloud regions (`us-central1`,\n`europe-west1`, and `asia-east1`). All external client requests are served by\nthe three clusters within the three regions with multiple namespaces. Client requests\nthat come from one of three business regions (Americas,\nEMEA, and APAC) are served by application instances in the closest\nGoogle Cloud region.\n\nThe following topology shows the top-level hierarchy for the deployment:\n[](/static/network-intelligence-center/docs/network-topology/images/use-cases/gke-auditing-topology.png) Network Topology GKE view example topology (click to enlarge)\n\nNetwork latency\n---------------\n\nIn this scenario, assume that you have a GKE cluster named\nonline-boutique. You check the latency between external clients and the\nGKE cluster to see if the latency between them has changed. You\ndiscover that it has changed and decide to further\ninvestigate the cluster's nodes.\n\n1. You filter the topology to show only the traffic for your cluster\n `online-boutique`.\n\n In the **Filter** section, you can add a filter to select nodes and its\n peers. This section is available only for metric views and not for the\n insights views. Click **Add filter** and select the type of node and the\n node.\n\n After you apply the filter, Network Topology shows only the connections\n related to the cluster, as shown in the following example.\n2. Starting with the external clients in Americas, you click the traffic\n metrics between the Americas business region and the GKE cluster.\n Network Topology shows charts in the details pane. The information includes\n ingress and egress traffic between your selected entity and the connected\n entity. For example, Network Topology provides the latest values for\n queries per second (QPS) and the HTTP request latency.\n In the request latency chart, you see values for the 50th, 95th, and 99th\n percentiles. In this example, assume that all of the latency values are\n higher than you expected.\n\n3. To expand the time series charts to 6 weeks, at the top of the details\n pane, you select **6 weeks**.\n\n You see a significant jump that happened about two hours ago, roughly when\n the first issues were reported. You're confident that the issue is related\n to increased latency with a GKE Pod.\n | **Note:** Traffic details from external entities are only available till the GKE cluster level. Network Topology does not show the traffic to the nodes within a GKE cluster.\n4. Having a high-level view of the issue, you investigate the GKE nodes\n further. For more information about troubleshooting GKE\n nodes, see [Troubleshooting GKE connectivity issues](/kubernetes-engine/docs/troubleshooting#ConnectivityIssues).\n\nWhat's next\n-----------\n\n- [Monitor your networking configuration with Network Topology](/network-intelligence-center/docs/network-topology/how-to/audit-troubleshoot-networking-issues)\n- [Use case: Audit network performance](/network-intelligence-center/docs/network-topology/concepts/auditing-network-performance)\n- [Troubleshoot Network Topology](/network-intelligence-center/docs/network-topology/support/troubleshooting)\n- [Cloud Interconnect quotas and limits](/network-connectivity/docs/interconnect/quotas)\n- [Cloud VPN quotas and limits](/network-connectivity/docs/vpn/quotas)"]]