Istio Hands-on Study [1기]

[6주차] 데이터 플레인 문제 해결 : Envoy 구성에서 수동으로 잘못된 구성 발견

구구달스 2025. 4. 22. 10:31

🚀 Envoy 설정을 통한 수동 디버깅

Istio의 자동화된 분석 도구(예: istioctl analyze, Kiali)로 설정 문제를 해결하지 못할 때는 Envoy 프록시의 설정을 직접 확인해야 합니다. Envoy 설정을 수동으로 조사하면 문제의 근본 원인을 파악할 수 있습니다.
Envoy administration interface와 istioctl을 사용해 Envoy 설정을 확인합니다.

🛠️ 수동 디버깅의 필요성

Istio의 자동 분석 도구는 대부분의 설정 오류를 탐지하지만, 복잡하거나 드문 문제는 자동화된 도구로 해결되지 않을 수 있습니다. 이런 경우, Envoy 프록시의 전체 설정을 직접 조사해야 합니다. Envoy 설정은 워크로드에 적용된 실제 라우팅 규칙과 클러스터 정의를 포함하므로, 문제의 원인을 정확히 파악할 수 있습니다.
Envoy 설정은 Envoy administration interface 또는 istioctl 명령어를 통해 확인할 수 있습니다.

자동 분석 도구로 문제가 해결되지 않을 때는 Envoy 설정을 수동으로 조사하며,
이를 위해 Envoy administration interface 또는 istioctl을 사용합니다.

🔍 Envoy Administration Interface 활용

Envoy administration interface는 Envoy 프록시의 설정과 상태를 확인하고, 로깅 레벨을 조정하는 등 다양한 기능을 제공합니다. 이 인터페이스는 모든 서비스 프록시에서 포트 15000을 통해 접근 가능합니다. istioctl을 사용해 이 인터페이스를 로컬 환경으로 포트 포워딩할 수 있습니다.
다음 명령어를 실행해 catalog 워크로드의 Envoy 대시보드에 접근합니다:

$ kubectl port-forward deploy/catalog -n istioinaction 15000:15000
Forwarding from 127.0.0.1:15000 -> 15000
Forwarding from [::1]:15000 -> 15000
Handling connection for 15000

대시보드에서 config_dump를 클릭하면 현재 Envoy 프록시에 적용된 전체 설정을 확인할 수 있습니다. 하지만 이 출력은 매우 방대합니다. 출력 크기를 확인하기 위해 다음 명령어를 실행해 봅시다:
- 약 14,000줄에 달하는 데이터는 사람이 직접 읽기 어렵습니다. 이를 해결하기 위해 istioctl은 출력을 필터링해 필요한 정보만 추출할 수 있는 도구를 제공합니다.

$ curl -s localhost:15000/config_dump | wc -l
14237

Envoy administration interface는 포트 15000을 통해 설정을 확인할 수 있으며,
config_dump는 방대한 설정 데이터를 출력하지만 istioctl로 필터링해 읽기 쉽게 만들 수 있습니다.

📌 핵심 요약

수동 디버깅의 중요성: 자동 분석 도구로 해결되지 않는 문제는 Envoy 설정을 수동으로 조사해야 합니다.
Envoy Administration Interface: 포트 15000을 통해 접근 가능하며, istioctl dashboard envoy 명령어로 로컬에서 대시보드를 열 수 있습니다.
config_dump: Envoy의 전체 설정을 출력하지만, 데이터가 방대하므로 istioctl로 필터링해 분석하는 것이 효과적입니다.
참고 자료: Envoy 공식 문서에서 administration interface의 세부 기능을 확인할 수 있습니다.

🚀 istioctl로
Envoy 프록시 설정 확인 및 디버깅

Istio 환경에서 설정 문제를 해결하려면 Envoy 프록시의 설정을 상세히 확인하는 것이 중요합니다. istioctl proxy-config 명령어는 Envoy의 xDS API를 기반으로 프록시 설정을 조회하고 필터링할 수 있는 강력한 도구입니다.
istioctl proxy-config를 사용해 프록시 설정을 단계별로 확인하고, 설정 오류를 탐지 및 수정합니다.

🛠️ istioctl proxy-config 명령어 개요

istioctl proxy-config 명령어는 워크로드의 Envoy 프록시 설정을 조회하고 분석하는 데 사용됩니다. 이 명령어는 Envoy의 xDS API(Cluster Discovery Service, Endpoint Discovery Service 등)를 기반으로 설정을 세분화해 조회할 수 있습니다. 주요 서브커맨드는 다음과 같습니다:
- cluster: 클러스터 설정 조회
- endpoint: 엔드포인트 설정 조회
- listener: 리스너 설정 조회
- route: 라우팅 설정 조회
- secret: 시크릿 설정 조회
이 명령어들은 설정 오류를 찾거나 트래픽 흐름을 추적할 때 유용합니다. Envoy의 xDS API를 이해하면 어떤 설정을 조회해야 할지 쉽게 파악할 수 있습니다.

istioctl proxy-config는 Envoy의 xDS API를 기반으로 프록시 설정을 조회하며,
cluster, endpoint, listener, route, secret 서브커맨드를 제공합니다.

🔍 Envoy API와 요청 라우팅 이해

Envoy는 요청 라우팅을 위해 여러 xDS API를 사용합니다. 아래 그림은 요청이 프록시를 통해 라우팅되는 과정을 보여줍니다.

각 API의 역할은 다음과 같습니다:
- Listener: 트래픽이 프록시로 들어오는 네트워크 설정(예: IP, 포트)을 정의합니다.
- HTTP Filter Chain: router filter를 통해 고급 라우팅 작업을 수행합니다.
- Route: 가상 호스트를 클러스터에 매핑하며, Istio에서는 RDS(Route Discovery Service)를 통해 동적으로 설정됩니다.
- Cluster: 워크로드의 엔드포인트 그룹을 정의하며, DestinationRule로 서브셋을 세분화합니다.
- Endpoint: 워크로드의 실제 IP 주소를 나타냅니다.
이 구조를 이해하면 istioctl proxy-config로 어떤 설정을 확인해야 할지 알 수 있습니다.

Envoy의 xDS API(listener, route, cluster, endpoint)는 요청 라우팅을 구성하며,
Istio는 VirtualService와 DestinationRule로 이를 관리합니다.

🕵️ Envoy Listener 설정 확인

Ingress Gateway가 포트 80으로 들어오는 트래픽을 수신하는지 확인하려면 listener 설정을 조회합니다.
Istio는 Gateway 리소스를 통해 listener를 설정합니다. 다음 명령어로 istio-ingressgateway의 listener 설정을 확인합니다:

$ docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/istio-ingressgateway -n istio-system
ADDRESS PORT  MATCH DESTINATION
0.0.0.0 8080  ALL   Route: http.8080
0.0.0.0 15021 ALL   Inline Route: /healthz/ready*
0.0.0.0 15090 ALL   Inline Route: /stats/prometheus*

출력은 포트 8080에 listener가 설정되어 있으며, 트래픽이 http.8080 라우트로 전달됨을 보여줍니다. 포트 80이 아닌 8080이 사용된 이유는 Kubernetes 서비스 istio-ingressgateway가 포트 80을 8080으로 포워딩하기 때문입니다.

$ kubectl get svc -n istio-system  istio-ingressgateway -o yaml | grep "ports:" -A10
  ports:
  - name: status-port
    nodePort: 30201
    port: 15021
    protocol: TCP
    targetPort: 15021
  - name: http2
    nodePort: 30000
    port: 80
    protocol: TCP
    targetPort: 8080

이로써 포트 80의 트래픽이 8080으로 전달되고, listener가 이를 처리함을 확인했습니다.

istioctl proxy-config listeners로 listener 설정을 확인하며,
포트 80의 트래픽은 Kubernetes 서비스를 통해 8080으로 포워딩됩니다.

🛤️ Envoy Route 설정 확인

Route 설정은 트래픽을 어떤 클러스터로 라우팅할지 정의합니다.
Istio는 VirtualService를 통해 route를 설정합니다. http.8080 라우트의 설정을 확인하려면 다음 명령어를 실행합니다:

$ docker exec -it myk8s-control-plane istioctl proxy-config routes deploy/istio-ingressgateway -n istio-system --name http.8080
NAME          DOMAINS                      MATCH     VIRTUAL SERVICE
http.8080     catalog.istioinaction.io     /*        catalog-v1-v2.istioinaction

이 출력은 catalog.istioinaction.io 호스트의 트래픽이 catalog VirtualService로 라우팅됨을 보여줍니다. 클러스터 세부 정보를 확인하려면 JSON 형식으로 출력합니다:

$ docker exec -it myk8s-control-plane istioctl proxy-config routes deploy/istio-ingressgateway -n istio-system --name http.8080 -o json
...
                "routes": [
                    {
                        "match": {
                            "prefix": "/"
                        },
                        "route": {
                            "weightedClusters": {
                                "clusters": [
                                    {
                                        "name": "outbound|80|version-v1|catalog.istioinaction.svc.cluster.local",
                                        "weight": 20
                                    },
                                    {
                                        "name": "outbound|80|version-v2|catalog.istioinaction.svc.cluster.local",
                                        "weight": 80
                                    }
                                ],
                                "totalWeight": 100
...

이 JSON은 트래픽이 version-v1(20%)과 version-v2(80%) 클러스터로 분배됨을 보여줍니다.

istioctl proxy-config routes로 라우팅 규칙을 확인하며,
JSON 출력은 VirtualService의 클러스터 분배 비율을 보여줍니다.

🗄️ Envoy Cluster 설정 확인

Cluster는 트래픽이 라우팅되는 백엔드 서비스를 정의합니다. 클러스터는 엔드포인트(IP 주소)로 구성되며, DestinationRule로 서브셋을 정의합니다. version-v1 클러스터를 조회하려면 다음 명령어를 실행합니다:

$ docker exec -it myk8s-control-plane istioctl proxy-config clusters deploy/istio-ingressgateway -n istio-system \
--fqdn catalog.istioinaction.svc.cluster.local --port 80 --subset version-v1
SERVICE FQDN                                PORT     SUBSET         DIRECTION     TYPE     DESTINATION RULE
catalog.istioinaction.svc.cluster.local     80       version-v1     outbound      EDS      catalog.istioinaction

version-v1과 version-v2 클러스터가 존재하지 않음을 알 수 있습니다. 이는 DestinationRule이 누락되었기 때문입니다. 이를 해결하기 위해 catalog-destinationrule-v1-v2.yaml 파일을 적용합니다.

$ docker exec -it myk8s-control-plane cat /istiobook/ch10/catalog-destinationrule-v1-v2.yaml
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: catalog
  namespace: istioinaction
spec:
  host: catalog.istioinaction.svc.cluster.local
  subsets:
  - name: version-v1
    labels:
      version: v1
  - name: version-v2
    labels:
      version: v2

유효성 확인 후, 파일을 적용합니다:

$ docker exec -it myk8s-control-plane istioctl analyze /istiobook/ch10/catalog-destinationrule-v1-v2.yaml -n istioinaction

✔ No validation issues found when analyzing /istiobook/ch10/catalog-destinationrule-v1-v2.yaml.

$ kubectl apply -f ch10/catalog-destinationrule-v1-v2.yaml

다시 클러스터를 조회합니다:

$ docker exec -it myk8s-control-plane istioctl proxy-config clusters deploy/istio-ingressgateway -n istio-system \
--fqdn catalog.istioinaction.svc.cluster.local --port 80
SERVICE FQDN                                PORT     SUBSET         DIRECTION     TYPE     DESTINATION RULE
catalog.istioinaction.svc.cluster.local     80       -              outbound      EDS      catalog.istioinaction
catalog.istioinaction.svc.cluster.local     80       version-v1     outbound      EDS      catalog.istioinaction
catalog.istioinaction.svc.cluster.local     80       version-v2     outbound      EDS      catalog.istioinaction

이제 version-v1과 version-v2 서브셋이 정의된 것을 확인할 수 있습니다.

istioctl proxy-config clusters로 클러스터 설정을 확인하며,
DestinationRule 적용으로 누락된 서브셋을 정의해 문제를 해결합니다.

🌐 Envoy Endpoint 설정 확인

클러스터는 엔드포인트(워크로드의 IP 주소)로 구성됩니다. 엔드포인트는 EDS(Endpoint Discovery Service)를 통해 동적으로 발견됩니다.
version-v1 클러스터의 엔드포인트를 확인하려면 다음 명령어를 실행합니다:

$ docker exec -it myk8s-control-plane istioctl proxy-config endpoints deploy/istio-ingressgateway -n istio-system \
--cluster "outbound|80|version-v1|catalog.istioinaction.svc.cluster.local"
ENDPOINT            STATUS      OUTLIER CHECK     CLUSTER
10.10.0.12:3000     HEALTHY     OK                outbound|80|version-v1|catalog.istioinaction.svc.cluster.local

이 IP 주소가 실제 워크로드와 연결되었는지 확인합니다:

$ kubectl get pod -n istioinaction --field-selector status.podIP=10.10.0.12 -owide --show-labels
NAME                     READY   STATUS    RESTARTS   AGE    IP           NODE                  NOMINATED NODE   READINESS GATES   LABELS
catalog-6cf4b97d-56jm5   2/2     Running   0          152m   10.10.0.12   myk8s-control-plane   <none>           <none>            app=catalog,pod-template-hash=6cf4b97d,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=catalog,service.istio.io/canonical-revision=v1,version=v1

이로써 version-v1 클러스터의 엔드포인트가 실제 워크로드와 연결됨을 확인했습니다.

istioctl proxy-config endpoints로 클러스터의 엔드포인트를 확인하며,
kubectl로 IP 주소가 실제 워크로드와 연결됨을 검증합니다.

📌 핵심 요약

istioctl proxy-config: Envoy의 xDS API(cluster, endpoint, listener, route)를 기반으로 프록시 설정을 조회합니다.
Envoy API: Listener, Route, Cluster, Endpoint가 요청 라우팅을 구성하며, Istio는 Gateway, VirtualService, DestinationRule로 이를 관리합니다.
Listener 확인: 포트 80의 트래픽이 8080으로 포워딩되며, http.8080 라우트로 처리됨을 확인합니다.
Route 확인: VirtualService가 트래픽을 version-v1(20%), version-v2(80%)로 분배함을 JSON 출력으로 확인합니다.
Cluster 및 Endpoint: DestinationRule로 서브셋을 정의하고, EDS로 엔드포인트를 동적으로 발견해 워크로드와 연결함을 검증합니다.
문제 해결: 누락된 DestinationRule을 적용해 클러스터를 정의하고, istioctl analyze로 유효성을 검증합니다.

🚀 마이크로서비스 애플리케이션 문제 해결 가이드

마이크로서비스 기반 애플리케이션에서 발생하는 문제를 해결하는 데 있어 Envoy 프록시의 로그와 메트릭은 매우 유용합니다. 이를 통해 성능 병목 현상을 일으키는 서비스를 발견하거나, 자주 실패하는 엔드포인트를 식별하고, 성능 저하를 감지할 수 있습니다.

🛠️ 문제 시나리오 설정: 느린 워크로드와 타임아웃

설정 전 정상 통신 환경 상태 확인
kiali : catalog - 100% 성공

kiali : catalog 에 v1 : HTTP Request Response Time(ms)에 p99 확인

kiali : catalog 에 v2 : HTTP Request Response Time(ms)에 p99 확인

Grafana - Istio Mesh 대시보드

느린 워크로드 설정

catalog 서비스의 특정 워크로드를 간헐적으로 느리게 만들기 위해 아래 명령어를 실행합니다.
이 명령은 catalog 파드에 latency 문제를 활성화합니다.

$ CATALOG_POD=$(kubectl get pods -l version=v2 -n istioinaction -o jsonpath={.items..metadata.name} | cut -d ' ' -f1)

$ echo $CATALOG_POD
catalog-v2-56c97f6db-244cd

$ kubectl -n istioinaction exec -c catalog $CATALOG_POD \
-- curl -s -X POST -H "Content-Type: application/json" \
-d '{"active": true, "type": "latency", "volatile": true}' \
localhost:3000/blowup ;
blowups=[object Object]

blowups=[object Object]가 출력되며, 워크로드가 간헐적으로 느린 응답을 반환하도록 설정됩니다.

타임아웃 설정

다음으로, catalog-v1-v2 VirtualService에 0.5초 이상 걸리는 요청이 타임아웃되도록 설정합니다.

$ kubectl patch vs catalog-v1-v2 -n istioinaction --type json \
-p '[{"op": "add", "path": "/spec/http/0/timeout", "value": "0.5s"}]'
virtualservice.networking.istio.io/catalog-v1-v2 patched

이제 요청이 0.5초를 초과하면 타임아웃이 발생합니다.

트래픽 생성

문제를 진단하기 위해 catalog 워크로드에 지속적인 트래픽을 생성합니다. 별도의 터미널에서 다음 명령어를 실행하세요.

$ for in in {1..9999}; do curl http://catalog.istioinaction.io:30000/items -w "\nStatus Code %{http_code}\n"; sleep 1; done
upstream request timeout
Status Code 504

일부 요청이 느린 워크로드로 라우팅되며, 타임아웃으로 인해 Status Code 504 (Gateway Timeout)이 반환됩니다.

느린 워크로드와 타임아웃을 설정해 문제를 시뮬레이션하고,
트래픽을 생성해 로그와 메트릭을 수집했습니다.

📜 Envoy Access Log 이해하기

Envoy Access Log는 Envoy 프록시가 처리한 모든 요청을 기록하며, 디버깅과 문제 해결에 필수적입니다. 기본적으로 Istio는 로그를 TEXT 형식으로 출력하지만, 이는 읽기 어렵습니다. 이를 개선하기 위해 JSON 형식으로 변경하는 방법을 배워봅니다.

기본 TEXT 형식 로그

다음 명령어로 Istio ingress gateway의 로그를 확인하면, 504 에러가 포함된 로그를 볼 수 있습니다.

$ kubectl logs -n istio-system -l app=istio-ingressgateway -f | grep 504
[2025-05-12T04:29:33.075Z] "GET /items HTTP/1.1" 504 UT response_timeout - "-" 0 24 499 - "172.18.0.1" "curl/8.5.0" "27d4a8da-ec71-9737-ad33-b253a86a4eb3" "catalog.istioinaction.io:30000" "10.10.0.13:3000" outbound|80|version-v2|catalog.istioinaction.svc.cluster.local 10.10.0.7:46964 10.10.0.7:8080 172.18.0.1:35936 - -

kiali : catalog v2

Grafana - Istio Mesh 대시보드 : 500 응답 증가, v2 에 Success Rate % 확인

TEXT 형식의 Envoy Access Log는 정보는 풍부하지만 초보자에게 읽기 어렵습니다.

JSON 형식으로 로그 변경

JSON 형식은 키-값 쌍으로 로그를 제공해 가독성을 높입니다.
MeshConfig 설정 수정

$ KUBE_EDITOR="vi" kubect
l edit -n istio-system cm istio
configmap/istio edited

apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
    accessLogEncoding: JSON
    ...

설정 후, 다시 로그를 확인하고 jq를 사용해 가독성을 높입니다.

$ kubectl logs -n istio-system -l app=istio-ingressgateway -f | jq
{
  "requested_server_name": null,
  "downstream_local_address": "10.10.0.7:8080",
  "upstream_host": "10.10.0.13:3000",
  "response_code": 200,
  "bytes_received": 0,
  "downstream_remote_address": "172.18.0.1:35510",
  "request_id": "4b9f0b63-14fe-915f-9fa9-aa3e594cb68a",
  "upstream_service_time": "465",
  "connection_termination_details": null,
  "upstream_local_address": "10.10.0.7:45006",
  "response_code_details": "via_upstream",
  "upstream_transport_failure_reason": null,
  "protocol": "HTTP/1.1",
  "start_time": "2025-05-12T04:34:39.345Z",
  "bytes_sent": 502,
  "user_agent": "curl/8.5.0",
  "x_forwarded_for": "172.18.0.1",
  "response_flags": "-",
  "path": "/items",
  "upstream_cluster": "outbound|80|version-v2|catalog.istioinaction.svc.cluster.local",
  "route_name": null,
  "duration": 466,
  "authority": "catalog.istioinaction.io:30000",
  "method": "GET"
}
...

JSON 형식 로그는 키-값 쌍으로
가독성이 높아 문제 진단에 유용합니다.

Envoy Response Flags

Envoy는 연결 실패 원인을 상세히 설명하는 response flags를 제공합니다. 자주 사용되는 플래그는 다음과 같습니다:
- UT: Upstream request timeout (업스트림이 타임아웃 설정을 초과).
- UH: No healthy upstream (클러스터에 정상 워크로드 없음).
- NR: No route configured (라우팅 설정 없음).
- UC: Upstream connection termination (업스트림 연결 종료).
자세한 플래그 목록은 Envoy 공식 문서에서 확인하세요.

Response flags는 문제 원인을 파악하는 데 중요한 단서를 제공합니다.

느린 파드 식별

JSON 로그에서 upstream_host의 IP 주소를 추출해 느린 파드를 식별합니다.

SLOW_POD_IP=$(kubectl -n istio-system logs deploy/istio-ingressgateway \
  | grep 504 | tail -n 1 | jq -r .upstream_host | cut -d ":" -f1)

SLOW_POD=$(kubectl get pods -n istioinaction \
  --field-selector status.podIP=$SLOW_POD_IP \
  -o jsonpath={.items..metadata.name})

이제 SLOW_POD 변수에 문제가 있는 파드 이름이 저장됩니다.

로그에서 IP 주소를 추출해 느린 파드를 정확히 식별할 수 있습니다.

🔍 Envoy 로그 레벨 높이기

Access Log만으로 충분한 정보를 얻지 못할 경우, Envoy 프록시의 로깅 레벨을 높여 더 자세한 로그를 확인할 수 있습니다.

현재 로깅 레벨 확인

다음 명령어로 ingress gateway의 현재 로깅 레벨을 확인합니다.

$ docker exec -it myk8s-control-plane istioctl proxy-config log deploy/istio-ingressgateway -n istio-system
istio-ingressgateway-6bb8fb6549-kmx69.istio-system:
active loggers:
...
  connection: warning
  conn_handler: warning
  decompression: warning
  dns: warning
  dubbo: warning
...

connection: warning: connection 스코프의 로그는 warning 레벨 이상만 출력.
로깅 레벨: none, error, warning, info, debug (상세도 순).

로깅 스코프와 레벨을 조정해 필요한 정보만 추출할 수 있습니다.

로깅 레벨 높이기

문제 진단에 유용한 스코프(connection, http, router, pool)의 로깅 레벨을 debug로 설정합니다.

$ docker exec -it myk8s-control-plane \
istioctl proxy-config log deploy/istio-ingressgateway \
-n istio-system \
--level http:debug,router:debug,connection:debug,pool:debug
istio-ingressgateway-6bb8fb6549-kmx69.istio-system:
active loggers:
...
  connection: debug
...
  http: debug
...
  pool: debug
...
  router: debug
...

디버그 로그 확인

로그를 파일로 저장해 분석합니다.

$ kubectl logs -n istio-system deploy/istio-ingressgateway > /tmp/ingress-logs.txt

Debug 레벨 로그는
프록시 동작을 상세히 분석해 문제 원인을 명확히 파악할 수 있습니다.

📌 핵심 요약

문제 시나리오 설정: 느린 워크로드와 0.5초 타임아웃을 설정해 문제를 시뮬레이션하고, 트래픽을 생성해 로그를 수집했습니다.
Envoy Access Log: TEXT 형식은 읽기 어렵지만, JSON 형식으로 변경하면 가독성이 높아져 문제 진단이 쉬워집니다. response_flags와 upstream_host로 타임아웃 원인을 파악할 수 있습니다.
로깅 레벨 조정: istioctl로 Envoy의 로깅 레벨을 debug로 높여 상세 로그를 확인하고, 연결 ID를 추적해 문제 파드를 정확히 식별했습니다.
핵심 도구: kubectl, istioctl, jq를 활용해 로그를 분석하고, Envoy의 response flags로 문제 원인을 구체화했습니다.

🌐 네트워크 트래픽 분석: Wireshark 활용법

🛠️ Wireshark 설치하기

Wireshark를 설치해 네트워크 분석 환경을 구축합니다.

설치 단계

Wireshark 설치:
$ sudo apt install wireshark Reading package lists... Done Building dependency tree... Done Reading state information... Done The following package was automatically installed and is no longer required: libllvm17t64 Use 'sudo apt autoremove' to remove it. The following additional packages will be installed: ...

🔍 Pod의 네트워크 트래픽 분석하기

이제 문제 있는 Pod의 네트워크 트래픽을 캡처하고 분석해보겠습니다.
tcpdump를 사용해 Pod의 네트워크 트래픽을 캡처하고, 이를 Wireshark로 시각화합니다.

트래픽 캡처 명령어

slow 파드 정보 확인

$ CATALOG_POD=$(kubectl get pods -l version=v2 -n istioinaction -o jsonpath={.items..metadata.name} | cut -d ' ' -f1)

istio-proxy 에 tcp port 3000 에서 패킷 덤프에 출력 결과를 파일로 저장

$ kubectl exec -it -n istioinaction $CATALOG_POD -c istio-proxy -- sudo tcpdump -i any tcp port 3000 -w /var/lib/istio/data/dump.pcap
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
...

$ kubectl exec -it -n istioinaction $CATALOG_POD -c istio-proxy -- ls -l /var/lib/istio/data/
total 116
-rw-r--r-- 1 tcpdump tcpdump 117388 May 12 05:04 dump.pcap

출력 결과 파일을 로컬로 다운로드

$ kubectl cp -n istioinaction -c istio-proxy $CATALOG_POD:var/lib/istio/data/dump.pcap ./dump.pcap

로컬로 다운 받은 파일을 wireshark 로 불러오기

$ wireshark dump.pcap

📊 Wireshark로 트래픽 필터링하기

캡처된 트래픽은 매우 많을 수 있으므로, 우리가 관심 있는 데이터만 볼 수 있도록 필터링합니다.
여기서는 HTTP GET /items 요청만 확인해보겠습니다.

필터링 방법

Wireshark의 디스플레이 필터 창에 아래 쿼리를 입력하세요:

http contains "GET /items"

이 필터는 HTTP 프로토콜 중 GET 메서드와 /items 경로를 포함한 패킷만 보여줍니다.

필터링된 결과는 분석에 필요한 데이터만 깔끔하게 보여줍니다. 초보자라도 이 과정을 통해 원하는 네트워크 요청을 쉽게 추적할 수 있습니다.

Wireshark의 디스플레이 필터를 사용해
HTTP GET /items 요청만 추려내세요.

🔗 TCP 스트림 분석하기

TCP 연결의 시작부터 종료까지 상세히 살펴보려면 TCP 스트림 기능을 사용합니다. 이를 통해 연결의 전체 흐름을 쉽게 이해할 수 있습니다.

TCP 스트림 확인 방법

Wireshark에서 필터링된 패킷 중 첫 번째 행을 마우스 오른쪽 버튼으로 클릭합니다.
Follow 메뉴를 선택한 뒤 TCP Stream을 클릭합니다.
TCP 스트림 창이 열리며, 연결의 상세 흐름이 표시됩니다.

TCP 스트림 창은 TCP 연결의 시작, 데이터 전송, 종료 과정을 직관적으로 보여줍니다.

TCP 스트림 분석 결과

분석된 TCP 스트림은 아래와 같은 흐름을 보여줍니다:
- TCP 3-way 핸드셰이크: 클라이언트와 서버가 [SYN], [SYN, ACK], [ACK] 플래그를 통해 연결을 설정합니다.
- 연결 재사용: 설정된 연결은 여러 요청에 재사용되며, 모든 요청이 성공적으로 처리됩니다.
- 응답 지연: 클라이언트의 요청이 서버에서 0.5초 이상 지연되며, 이는 패킷 간 시간 차이로 확인됩니다.
- 연결 종료: 클라이언트가 [FIN] 플래그를 보내 연결을 종료하고, 서버가 이를 수락합니다.

TCP 스트림을 통해 연결의 전체 흐름을 분석하고,
지연과 종료 원인을 파악하세요.

⚙️ TCP 제어 플래그 이해하기

TCP 연결을 분석하려면 TCP 제어 플래그를 이해하는 것이 중요합니다. 이 플래그는 연결의 상태를 나타냅니다.

주요 TCP 플래그

SYN (Synchronization): 새로운 연결을 시작할 때 사용됩니다.
ACK (Acknowledgment): 패킷이 성공적으로 수신되었음을 확인합니다.
FIN (Finish): 연결 종료를 요청합니다.
이 플래그들을 이해하면 네트워크 트래픽 분석이 훨씬 쉬워집니다. 예를 들어, [SYN]과 [ACK] 플래그를 통해 연결이 시작되었는지, [FIN] 플래그를 통해 연결이 종료되었는지 확인할 수 있습니다.

TCP 플래그(SYN, ACK, FIN)를 통해 연결의 상태를 파악하세요..

📌 핵심 요약

트래픽 캡처: ocalhost 트래픽을 캡처하고, 트래픽 생성 스크립트로 데이터를 수집
필터링: Wireshark에서 http contains "GET /items" 필터를 사용해 필요한 HTTP 요청만 확인
TCP 스트림 분석: TCP 스트림을 통해 연결의 시작, 데이터 전송, 종료 과정을 파악
TCP 플래그: SYN, ACK, FIN 플래그를 통해 연결 상태를 이해

저작자표시 (새창열림)

[6주차] 데이터 플레인 문제 해결 : Envoy 구성에서 수동으로 잘못된 구성 발견

🚀 Envoy 설정을 통한 수동 디버깅

🛠️ 수동 디버깅의 필요성

🔍 Envoy Administration Interface 활용

📌 핵심 요약

🚀 istioctl로 Envoy 프록시 설정 확인 및 디버깅

🛠️ istioctl proxy-config 명령어 개요

🔍 Envoy API와 요청 라우팅 이해

🕵️ Envoy Listener 설정 확인

🛤️ Envoy Route 설정 확인

🗄️ Envoy Cluster 설정 확인

🌐 Envoy Endpoint 설정 확인

📌 핵심 요약

🚀 마이크로서비스 애플리케이션 문제 해결 가이드

🛠️ 문제 시나리오 설정: 느린 워크로드와 타임아웃

느린 워크로드 설정

타임아웃 설정

트래픽 생성

📜 Envoy Access Log 이해하기

기본 TEXT 형식 로그

JSON 형식으로 로그 변경

Envoy Response Flags

느린 파드 식별

🔍 Envoy 로그 레벨 높이기

현재 로깅 레벨 확인

로깅 레벨 높이기

디버그 로그 확인

📌 핵심 요약

🌐 네트워크 트래픽 분석: Wireshark 활용법

🛠️ Wireshark 설치하기

설치 단계

🔍 Pod의 네트워크 트래픽 분석하기

트래픽 캡처 명령어

📊 Wireshark로 트래픽 필터링하기

필터링 방법

🔗 TCP 스트림 분석하기

TCP 스트림 확인 방법

TCP 스트림 분석 결과

⚙️ TCP 제어 플래그 이해하기

주요 TCP 플래그

📌 핵심 요약

🚀 istioctl로
Envoy 프록시 설정 확인 및 디버깅