Ssoon

2주차 : Istio gateways > 클러스터로 트래픽 유입 : Istio ingress gateways 본문

Istio Hands-on Study [1기]

2주차 : Istio gateways > 클러스터로 트래픽 유입 : Istio ingress gateways

구구달스 2025. 4. 15. 13:31 
CloudNet@ 가시다님이 진행하는 Istio Hands-on Study [1기]

🚀 Istio Ingress Gateway: 클러스터로 들어오는 트래픽의 관문

Istio는 서비스 메시(Service Mesh)를 관리하는 강력한 도구로, 클러스터 외부에서 들어오는 트래픽을 제어하는 ingress gateway라는 핵심 컴포넌트를 제공합니다. 이 글에서는 초보자도 쉽게 이해할 수 있도록 Istio의 ingress gateway가 무엇인지, 어떻게 동작하는지, 그리고 어떤 역할을 하는지 자연스럽게 풀어서 설명하겠습니다. 자, Istio의 세계로 함께 들어가 볼까요?

🌐 Ingress Gateway란 무엇인가요?

Istio의 ingress gateway는 클러스터로 들어오는 트래픽의 첫 번째 관문입니다. 외부에서 들어오는 요청을 받아 이를 클러스터 내부의 서비스로 안전하고 효율적으로 전달하는 역할을 합니다. 비유하자면, ingress gateway는 클러스터라는 도시로 들어오는 고속도로의 톨게이트라고 생각할 수 있어요. 이 톨게이트는 단순히 트래픽을 통과시키는 데 그치지 않고, 트래픽을 관리하고 최적화하는 다양한 기능을 제공합니다.

Ingress gateway는 외부 트래픽을 클러스터로 안전하게 전달하며, load balancing과 virtual-host routing 같은 고급 기능을 수행합니다.

🛠️ Envoy Proxy: Ingress Gateway의 심장

Istio의 ingress gateway는 Envoy proxy라는 강력한 오픈소스 프록시를 기반으로 동작합니다. Envoy는 서비스 간 통신뿐만 아니라 외부 트래픽을 처리하는 데도 탁월한 성능을 발휘합니다. ingress gateway는 단일 Envoy proxy 인스턴스를 사용해 트래픽을 라우팅하고, 부하를 분산하며, 보안 정책을 적용합니다.

Envoy는 단순한 프록시 이상의 역할을 합니다. 예를 들어, HTTP/2, gRPC 같은 최신 프로토콜을 지원하고, 트래픽을 세밀하게 제어할 수 있는 다양한 필터를 제공합니다. Istio는 이런 Envoy의 기능을 활용해 ingress gateway를 강력한 트래픽 관리 도구로 만듭니다.

Ingress gateway는 Envoy proxy를 사용해 트래픽을 라우팅하고, load balancing, routing, 그리고 보안 기능을 제공합니다.

🖥️ Ingress Gateway 확인하기

Istio를 설치하면 istio-system 네임스페이스에 istio-ingressgateway라는 Pod이 생성됩니다. 이 Pod 내부에는 Envoy proxy와 이를 초기화하는 pilot-agent 프로세스가 실행됩니다. 

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~$ kubectl exec -n istio-system deploy/istio-ingressgateway -- ps
    PID TTY          TIME CMD
      1 ?        00:00:00 pilot-agent
     27 ?        00:00:03 envoy
     60 ?        00:00:00 ps

이 결과는 ingress gateway가 Envoy proxy를 핵심으로 사용하고 있음을 보여줍니다. pilot-agent는 Envoy를 초기화하고 설정하며, 필요에 따라 DNS 프록시 역할도 수행합니다.

istio-ingressgateway Pod에서 Envoy proxy와 pilot-agent가 실행되며, 이를 통해 트래픽 처리가 이루어집니다.

🔧 Ingress Gateway 설정: Gateway와 VirtualService

Istio에서 ingress gateway를 설정하려면 두 가지 중요한 리소스를 이해해야 합니다: Gateway와 VirtualService. 이들은 외부 트래픽이 클러스터 내부로 들어오도록 허용하는 데 핵심적인 역할을 합니다.

  • Gateway: ingress gateway의 진입점을 정의합니다. 예를 들어, 어떤 포트와 프로토콜을 사용할지, 어떤 도메인에 반응할지 설정합니다.
  • VirtualService: 트래픽을 특정 서비스로 라우팅하는 규칙을 정의합니다. 예를 들어, 특정 URL 경로를 특정 서비스로 연결하거나, 트래픽을 분할하는 등의 작업을 수행합니다.

이 두 리소스를 함께 사용하면 외부 트래픽을 클러스터 내부의 서비스로 정확히 전달할 수 있습니다. VirtualService는 이후 챕터에서 더 깊이 다루겠지만, 여기서는 ingress gateway 설정의 첫걸음으로 이해하면 됩니다.

Gateway는 트래픽 진입점을 정의하고, VirtualService는 트래픽을 서비스로 라우팅하는 규칙을 설정합니다.

🌍 Egress Gateway와의 비교

Ingress gateway가 클러스터로 들어오는 트래픽을 관리한다면, egress gateway는 클러스터에서 외부로 나가는 트래픽을 처리합니다. 흥미롭게도 egress gateway는 ingress gateway와 동일한 리소스를 사용해 설정됩니다. 이는 Istio의 유연성을 보여주는 부분으로, 동일한 Envoy 기반 프록시를 입출력 트래픽 모두에 활용할 수 있다는 뜻입니다.

Egress gateway는 클러스터에서 외부로 나가는 트래픽을 관리하며, ingress gateway와 동일한 방식으로 설정됩니다.

🎯 요약

Istio의 ingress gateway는 외부 트래픽을 클러스터로 안전하게 전달하는 관문입니다. Envoy proxy를 기반으로 동작하며, load balancing, routing, 그리고 보안 기능을 제공합니다. 설정에는 Gateway와 VirtualService라는 두 가지 리소스가 필요하며, 이를 통해 트래픽을 세밀하게 제어할 수 있습니다. 또한, egress gateway와 함께 입출력 트래픽을 모두 관리할 수 있는 강력한 도구입니다.

🚀 1. Istio Gateway로 트래픽 관리 시작하기

Istio를 활용해 서비스 메시에서 트래픽을 관리하려면 Gateway 리소스를 설정하는 것이 첫걸음입니다. Gateway는 외부 트래픽이 클러스터 내부로 들어오는 관문 역할을 합니다.

🔌 Gateway 리소스로 포트와 호스트 설정하기

Istio의 Gateway 리소스는 클러스터 외부에서 들어오는 트래픽을 처리하기 위해 어떤 포트를 열고, 어떤 virtual host를 허용할지 정의합니다. 아래는 HTTP 포트 80을 열어 webapp.istioinaction.io라는 호스트로 들어오는 트래픽을 처리하는 예제입니다.

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ cat ch4/coolstore-gw.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: coolstore-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "webapp.istioinaction.io"

핵심 포인트

이 설정은 Envoy 프록시가 포트 80에서 HTTP 트래픽을 수신하도록 지시합니다. webapp.istioinaction.io로 들어오는 요청만 처리하며, 다른 호스트로의 요청은 무시됩니다.

이 설정을 통해 Istio의 ingressgateway가 외부 트래픽을 받아들이는 준비를 마칩니다. 이제 이 설정을 실제로 적용해보겠습니다!

🛠️ Gateway 리소스 적용하기

위에서 정의한 Gateway 리소스를 클러스터에 적용하려면 kubectl 명령어를 사용합니다. 예제 파일은 ch4/coolstore-gw.yaml에 저장되어 있다고 가정하겠습니다.

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl -n istioinaction apply -f ch4/coolstore-gw.yaml
gateway.networking.istio.io/coolstore-gateway created

이 명령어를 실행하면 coolstore-gateway라는 이름의 Gateway 리소스가 생성됩니다. 이제 설정이 제대로 적용되었는지 확인해볼 차례입니다.

핵심 포인트

kubectl apply 명령어는 YAML 파일을 읽어 클러스터에 리소스를 생성하거나 업데이트합니다. -n istioinaction은 네임스페이스를 지정해 리소스가 특정 네임스페이스에 적용되도록 합니다.

🔍 Gateway 설정 확인하기

Gateway가 올바르게 설정되었는지 확인하려면 Istio의 istioctl 도구를 사용해 ingressgateway의 리스너 상태를 점검합니다. 

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/istio-ingressgateway.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*

 

이 출력은 포트 80(실제로는 8080으로 매핑)이 HTTP 트래픽을 수신하도록 설정되었음을 보여줍니다. 추가로 헬스 체크(/healthz/ready*)와 메트릭(/stats/prometheus*) 경로도 확인할 수 있습니다.

핵심 포인트

출력에서 Route: http.80이 보인다면, Gateway가 포트 80을 통해 HTTP 트래픽을 수신할 준비가 된 것입니다!

참고
Docker Desktop이 아닌 환경에서는 리스너 이름(예: http.8080)이 다를 수 있습니다. 이 경우, 아래 명령어에서 이름을 적절히 수정해야 합니다.

🛤️ 라우팅 상태 점검하기

이제 Gateway가 트래픽을 수신할 준비가 되었으니, 실제로 어떤 경로로 트래픽이 라우팅되는지 확인해봅시다.

istio-ingressgateway의 라우팅 설정을 확인합니다:

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ docker exec -it myk8s-control-plane istioctl proxy-config routes deploy/istio-ingressgateway.istio-system -o json --name http.8080
[
    {
        "name": "http.8080",
        "virtualHosts": [
            {
                "name": "blackhole:80",
                "domains": [
                    "*"
                ]
            }
        ],
        "validateClusters": false,
        "ignorePortInHostMatching": true
    }
]

이 출력은 현재 Gateway가 모든 트래픽(*)을 blackhole이라는 기본 경로로 보내고 있음을 보여줍니다. 즉, 아직 특정 서비스로 연결된 VirtualService가 없기 때문에 들어오는 요청은 HTTP 404 응답을 받게 됩니다.

📌 "name": "http.8080"

  • 이건 Istio 내부에서 HTTP 요청을 8080 포트로 받는 가상의 라우팅 이름이에요.

🚫 "name": "blackhole:80"

  • **"blackhole"**은 무슨 뜻이냐면,
    현재 이 Gateway에 유효한 라우팅 규칙이 없어서, 요청을 그냥 버린다는 뜻이에요.
    즉: "받을 준비는 되어 있는데, 어디로 보낼지 모름 → 요청을 무시함"

🌐 "domains": ["*"]

  • 어떤 도메인으로 들어오든 다 적용할 수 있게 "*" (와일드카드)로 되어 있지만,
    아직 실제 동작하는 VirtualService가 없어서 "blackhole"로 처리돼요.

🎯 다음 단계는?

지금까지 Gateway 리소스를 설정하고 확인하는 과정을 살펴봤습니다. 하지만 현재는 트래픽이 blackhole로 라우팅되어 실제 서비스로 연결되지 않습니다. 다음 단계에서는 VirtualService를 추가해 포트 80으로 들어오는 트래픽을 클러스터 내 특정 서비스로 라우팅하는 방법을 배워볼게요. 이를 통해 Istio의 강력한 트래픽 관리 기능을 최대한 활용할 수 있습니다!

🚀 2. Istio VirtualService로 Gateway 트래픽을 서비스로 연결하기

이전 가이드에서 Istio의 Gateway 리소스를 설정해 외부 트래픽을 받아들일 포트와 호스트를 정의했습니다. 하지만 트래픽이 Gateway에 들어왔다고 해서 자동으로 서비스에 도달하지 않습니다. 이제 VirtualService 리소스를 사용해 Gateway로 들어온 트래픽을 서비스 메시 내부의 특정 서비스로 라우팅하는 방법을 알아봅니다. 

🔗 VirtualService로 트래픽 라우팅 정의하기

VirtualService는 Istio에서 트래픽의 경로를 정의하는 핵심 리소스입니다. 이를 통해 특정 호스트로 들어오는 트래픽을 어떤 서비스로 보낼지, 어떤 포트를 사용할지, 심지어 재시도나 타임아웃 같은 라우팅 속성까지 설정할 수 있습니다. 이번 예제에서는 webapp.istioinaction.io로 들어오는 트래픽을 webapp 서비스로 라우팅하는 VirtualService를 설정합니다.

다음은 예제 VirtualService 리소스입니다:

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ cat ch4/coolstore-vs.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: webapp-vs-from-gw
spec:
  hosts:
  - "webapp.istioinaction.io"
  gateways:
  - coolstore-gateway
  http:
  - route:
    - destination:
        host: webapp
        port:
          number: 80

핵심 포인트

🌐 외부에서 http://webapp.istioinaction.io로 요청이 오면,
🚪 coolstore-gateway가 받아서
🚚 내부의 webapp 서비스(80번 포트)로 전달해주는 길을 연결하는 설정이에요!

이 설정을 통해 Gateway로 들어온 트래픽이 webapp 서비스로 정확히 연결됩니다. 이제 이 리소스를 적용해볼까요?

🛠️ VirtualService 리소스 적용하기

  • VirtualService를 클러스터에 적용하려면 kubectl 명령어를 사용합니다. 
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl apply -n istioinaction -f ch4/coolstore-vs.yaml
virtualservice.networking.istio.io/webapp-vs-from-gw created
  • 이 명령어를 실행하면 webapp-vs-from-gw라는 VirtualService가 생성됩니다.

VirtualService 적용 후, Gateway는 이제 webapp.istioinaction.io로 들어오는 트래픽을 webapp 서비스로 라우팅할 준비가 됩니다.

🔍 라우팅 설정 확인하기

  • VirtualService가 제대로 적용되었는지 확인하려면 istioctl로 istio-ingressgateway의 라우팅 설정을 점검합니다. 

 

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ docker exec -it myk8s-control-plane istioctl proxy-config routes deploy/istio-ingressgateway.istio-system -o json --name http.8080
[
    {
        "name": "http.8080",
        "virtualHosts": [
            {
                "name": "webapp.istioinaction.io:80",
                "domains": [
                    "webapp.istioinaction.io"
                ],
                "routes": [
                    {
                        "match": {
                            "prefix": "/"
                        },
                        "route": {
                            "cluster": "outbound|80||webapp.istioinaction.svc.cluster.local",
                            "timeout": "0s",
                            "retryPolicy": {
                                "retryOn": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
                                "numRetries": 2,
                                "retryHostPredicate": [
                                    {
                                        "name": "envoy.retry_host_predicates.previous_hosts",
                                        "typedConfig": {
                                            "@type": "type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate"
                                        }
                                    }
                                ],
                                "hostSelectionRetryMaxAttempts": "5",
                                "retriableStatusCodes": [
                                    503
                                ]
                            },
                            "maxGrpcTimeout": "0s"
                        },
                        "metadata": {
                            "filterMetadata": {
                                "istio": {
                                    "config": "/apis/networking.istio.io/v1alpha3/namespaces/istioinaction/virtual-service/webapp-vs-from-gw"
                                }
                            }
                        },
                        "decorator": {
                            "operation": "webapp.istioinaction.svc.cluster.local:80/*"
                        }
                    }
                ],
                "includeRequestAttemptCount": true
            }
        ],
        "validateClusters": false,
        "ignorePortInHostMatching": true
    }
]
  • 외부에서 http://webapp.istioinaction.io로 들어오는 요청은
    내부의 webapp 서비스(80번 포트)로 정상적으로 라우팅되고 있음
  • 이제 Gateway는 더 이상 blackhole로 트래픽을 보내지 않고, 올바른 서비스로 연결합니다!

VirtualService 덕분에 Envoy 프록시는 webapp.istioinaction.io 도메인과 매칭되는 트래픽을 webapp 서비스로 라우팅하도록 설정되었습니다.

🛠️ 서비스 배포하기

  • 라우팅 설정이 완료되었으니, 실제로 트래픽이 도달할 서비스를 배포해야 합니다. 
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl apply -f services/catalog/kubernetes/catalog.yaml -n istioinaction
serviceaccount/catalog created
service/catalog created
deployment.apps/catalog created

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl apply -f services/webapp/kubernetes/webapp.yaml -n istioinaction
serviceaccount/webapp created
service/webapp created
deployment.apps/webapp created
  • 배포 후, 모든 Pod가 준비되었는지 확인합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl get pod -n istioinaction -owide
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE                  NOMINATED NODE   READINESS GATES
catalog-6cf4b97d-9h7db   2/2     Running   0          24s   10.10.0.12   myk8s-control-plane   <none>           <none>
webapp-7685bcb84-4kmr7   2/2     Running   0          16s   10.10.0.13   myk8s-control-plane   <none>           <none>

 

  • 다음으로, Gateway와 VirtualService가 올바르게 설치되었는지 확인합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl get gateway -n istioinaction
NAME                AGE
coolstore-gateway   33m
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl get virtualservice -n istioinaction
NAME                GATEWAYS                HOSTS                         AGE
webapp-vs-from-gw   ["coolstore-gateway"]   ["webapp.istioinaction.io"]   6m48s

서비스와 리소스가 모두 준비되었습니다.
이제 Gateway를 통해 트래픽을 테스트할 차례입니다!

🌐 Gateway로 트래픽 테스트하기

  • 이제 Gateway를 통해 트래픽이 서비스로 잘 전달되는지 테스트
  • 응답을 반환하지 않습니다. 왜일까요? 
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ curl http://localhost:30000/api/catalog -v
* Host localhost:30000 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:30000...
* connect to ::1 port 30000 from ::1 port 54054 failed: Connection refused
*   Trying 127.0.0.1:30000...
* Connected to localhost (127.0.0.1) port 30000
> GET /api/catalog HTTP/1.1
> Host: localhost:30000
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< date: Sat, 19 Apr 2025 06:02:01 GMT
< server: istio-envoy
< content-length: 0
<
* Connection #0 to host localhost left intact

 

    1. localhost:30000 포트로 접속 시도 → 연결 성공! 🎉
    2. /api/catalog 요청을 보냄
    3. Istio의 Envoy(Gateway)가 요청을 받음
    4. 하지만... 해당 경로를 처리할 서비스 or 라우팅 규칙이 없음
    5. 결과: 404 Not Found

✅ 올바른 Host 헤더로 요청 보내기

  • 이 문제를 해결하려면 Host 헤더를 webapp.istioinaction.io로 명시적으로 설정해야 합니다
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ curl -s http://localhost:30000/api/catalog -H "Host: webapp.istioinaction.io" | jq
[
  {
    "id": 1,
    "color": "amber",
    "department": "Eyewear",
    "name": "Elinor Glasses",
    "price": "282.00"
  },
  ...
  • 이제 정상적인 응답을 받을 수 있습니다!
  • Gateway가 트래픽을 받아 VirtualService의 설정에 따라 webapp 서비스로 정확히 라우팅했음을 확인할 수 있습니다.

Gateway와 VirtualService는 Host 헤더를 기반으로 트래픽을 라우팅합니다.
요청 시 올바른 호스트를 지정하는 것이 중요합니다!

🎯 다음 단계는?

이제 Gateway와 VirtualService를 사용해 외부 트래픽을 서비스 메시 내부의 서비스로 라우팅하는 방법을 배웠습니다. 하지만 Istio의 트래픽 관리 기능은 여기서 끝이 아니에요! 다음 단계에서는 VirtualService의 고급 기능, 예를 들어 버전 기반 라우팅, 재시도 정책, 타임아웃 설정 등을 탐구하며 더 정교한 트래픽 관리 방법을 배워볼게요. Istio의 강력한 기능을 활용해 서비스를 더욱 안정적이고 유연하게 운영해보세요!

🌐 3. Istio로 트래픽 흐름 한눈에 이해하기

Istio의 Gateway와 VirtualService 리소스를 활용해 트래픽을 관리하는 방법을 앞선 가이드에서 배웠습니다. 이제 이 모든 과정을 하나로 연결해, 외부 클라이언트에서 클러스터 내부 서비스까지 트래픽이 어떻게 흐르는지 큰 그림을 그려볼게요! 

🚪 Gateway: 클러스터의 입구 설정하기

Gateway 리소스는 서비스 메시의 가장자리에서 외부 트래픽을 받아들이는 문지기 역할을 합니다. 이 리소스를 통해 어떤 포트를 열지, 어떤 프로토콜을 사용할지, 그리고 어떤 virtual host를 허용할지를 정의합니다.

예를 들어, 포트 80에서 HTTP 프로토콜을 사용해 webapp.istioinaction.io 호스트로 들어오는 트래픽을 수신하도록 Gateway를 설정할 수 있습니다. 이 설정은 Istio의 ingressgateway가 외부 요청을 받아들일 준비를 하도록 지시합니다.

Gateway는 클러스터 외부에서 들어오는 트래픽의 첫 번째 관문입니다.
포트, 프로토콜, 호스트를 정의해 어떤 트래픽을 허용할지 결정합니다.

🛤️ VirtualService: 트래픽의 목적지 안내하기

Gateway가 트래픽을 받아들였다면, 이제 이 트래픽을 서비스 메시 내부의 특정 서비스로 연결해야 합니다. 여기서 VirtualService 리소스가 등장합니다. VirtualService는 들어온 트래픽을 어떤 서비스로 라우팅할지, 어떤 포트를 사용할지 정의합니다.

예를 들어, webapp.istioinaction.io로 들어오는 트래픽을 webapp 서비스의 포트 8080으로 보내도록 VirtualService를 설정할 수 있습니다. 이 설정을 통해 Gateway에서 수신한 트래픽이 정확한 목적지로 안내됩니다.

VirtualService는 Gateway로 들어온 트래픽을 서비스 메시 내부의 서비스로 연결하는 가이드 역할을 합니다.
호스트와 라우팅 규칙을 정의해 트래픽의 경로를 설정합니다.

🌍 트래픽 흐름의 전체 그림

이제 Gateway와 VirtualService가 어떻게 협력하는지 전체 흐름을 정리해보겠습니다. 다음은 외부 클라이언트에서 서비스 메시 내부의 서비스까지 트래픽이 이동하는 과정입니다:

  1. 클라이언트 요청: 외부 클라이언트가 http://webapp.istioinaction.io/api/catalog 같은 URL로 요청을 보냅니다.
  2. Gateway 수신: Istio의 ingressgateway가 포트 80에서 이 요청을 수신합니다. Gateway는 요청의 호스트(webapp.istioinaction.io)와 프로토콜(HTTP)이 설정과 일치하는지 확인합니다.
  3. VirtualService 라우팅: 요청이 Gateway를 통과하면, VirtualService가 이 트래픽을 webapp 서비스의 포트 8080으로 라우팅합니다.
  4. 서비스 응답: webapp 서비스가 요청을 처리하고, 응답이 다시 VirtualService와 Gateway를 거쳐 클라이언트로 반환됩니다.

 

그림 4.7: 트래픽 흐름

외부 클라이언트 → Gateway (포트 80, webapp.istioinaction.io) → VirtualService → webapp 서비스 (포트 8080) → 응답 반환

Gateway와 VirtualService는 외부 트래픽을 클러스터 내부로 안내하는 두 단계의 협력 시스템입니다.
Gateway가 문을 열고, VirtualService가 길을 안내합니다.

🎯 트래픽 관리의 시작점

이제 Istio에서 트래픽이 어떻게 흐르는지 전체적인 그림을 이해했습니다. Gateway는 외부 트래픽의 진입점을 설정하고, VirtualService는 그 트래픽을 서비스로 연결하는 역할을 하죠. 이 두 리소스를 잘 활용하면 복잡한 트래픽 관리도 간단하고 유연하게 처리할 수 있습니다. 다음 단계에서는 더 고급 라우팅 기법이나 트래픽 분배 방법을 배워 Istio의 강력한 기능을 한층 더 깊이 탐구해보세요!

🚀 4. Istio Gateway와 Kubernetes Ingress, 뭐가 다를까?

왜 Istio는 Kubernetes의 Ingress 리소스를 사용하지 않고 별도의 Gateway를 사용할까? Istio는 Kubernetes Ingress v1을 지원하지만, 몇 가지 한계 때문에 자체적인 Gateway와 VirtualService 리소스를 선호합니다. 

🛠️ Kubernetes Ingress v1: 간단하지만 제약이 많은 친구

Kubernetes Ingress v1은 HTTP 기반 워크로드를 처리하기 위한 간단한 명세입니다. Nginx, Traefik 같은 인기 있는 Ingress 컨트롤러들이 이를 구현하지만, 주로 HTTP 트래픽에 초점이 맞춰져 있어요. 예를 들어, Ingress는 기본적으로 포트 80(HTTP)과 443(HTTPS)만 지원합니다.

만약 Kafka나 NATS.io 같은 메시징 시스템에 TCP 연결을 열고 싶다면? Kubernetes Ingress로는 불가능하죠. 😅 이런 제약 때문에 다양한 트래픽을 처리해야 하는 서비스 메쉬 환경에서는 한계가 명확합니다.

Kubernetes Ingress v1은 HTTP 워크로드에 최적화되어 있어 TCP 같은 비HTTP 트래픽을 지원하지 않습니다.

📜 Kubernetes Ingress의 애매한 명세

Kubernetes Ingress v1은 트래픽 관리에 필요한 세부 명세가 부족합니다. 예를 들어, 복잡한 트래픽 라우팅, 트래픽 분할, 트래픽 섀도잉 같은 고급 기능은 명세에 포함되지 않아요. 이 때문에 각 벤더(HAProxy, Nginx 등)는 자신만의 방식으로 기능을 추가해야 했습니다.

결과적으로, 벤더마다 다른 설정 방식이 생겨서 **포터빌리티(portability)**가 떨어지는 문제가 발생했죠. Istio가 이런 방식에 의존했다면, Envoy의 강력한 기능을 활용하기 위해 수많은 비표준 어노테이션(annotation)이 필요했을 거예요. 😓

Kubernetes Ingress v1은 명세가 부족해 복잡한 트래픽 관리 기능이 제한적이고, 벤더마다 설정 방식이 달라 혼란을 초래합니다.

🔧 Istio Gateway: 더 강력하고 유연한 대안

Istio는 Kubernetes Ingress의 한계를 극복하기 위해 Gateway와 VirtualService라는 새로운 리소스를 도입했습니다. 이들은 트래픽 관리를 계층별로 분리해 더 유연하고 강력한 설정을 가능하게 해요:

  • Gateway: L4(전송 계층)와 L5(세션 계층)를 담당하며, 포트, 프로토콜, 도메인을 설정해 트래픽의 입구를 정의합니다.
  • VirtualService: L7(애플리케이션 계층)을 처리하며, 트래픽 라우팅, 분할, 재시도 같은 고급 기능을 제공합니다.

이렇게 계층을 분리함으로써 Istio는 HTTP뿐만 아니라 TCP, gRPC 등 다양한 프로토콜을 지원하고, 복잡한 트래픽 관리 시나리오도 쉽게 처리할 수 있습니다. 😎

Istio Gateway와 VirtualService는 L4/L5와 L7을 분리해 다양한 프로토콜과 고급 트래픽 관리를 지원합니다.

🌐 Kubernetes Gateway API: 새로운 표준의 시작

Kubernetes 커뮤니티도 Ingress v1의 한계를 인식하고, 이를 대체할 Gateway API를 개발 중입니다 (자세한 내용은 gateway-api.sigs.k8s.io에서 확인 가능). 이 새로운 API는 Istio의 Gateway와 VirtualService에서 영감을 받아 더 유연하고 표준화된 트래픽 관리 방식을 목표로 하고 있어요.

다만, Istio의 Gateway와 VirtualService는 이미 성숙한 구현체로, Kubernetes Gateway API가 등장하기 전부터 서비스 메쉬에서 강력한 기능을 제공해왔습니다. 두 API는 목적은 비슷하지만, Istio는 서비스 메쉬에 특화된 강점을 가지고 있습니다.

Kubernetes Gateway API는 Ingress v1을 대체하려는 새로운 표준이지만,
Istio Gateway는 이미 서비스 메쉬에 최적화된 강력한 솔루션입니다.

🎉 마무리

Istio Gateway와 Kubernetes Ingress v1은 트래픽을 클러스터로 가져오는 공통된 목표를 가지고 있지만, Istio는 더 유연하고 강력한 기능을 제공합니다. HTTP에 국한되지 않는 다양한 프로토콜 지원, 명확한 계층 분리, 고급 트래픽 관리 기능은 Istio를 서비스 메쉬 환경에서 빛나게 하죠. 🌈 Kubernetes Gateway API가 미래를 준비하고 있지만, 지금 Istio Gateway는 이미 강력한 선택지입니다!🚀

🌐 Istio Ingress Gateway와 API Gateway, 어떻게 다를까?

서비스 메쉬와 API 관리의 세계에서 Istio Ingress Gateway 와 API Gateway 는 비슷해 보이지만, 각기 다른 역할을 맡고 있습니다.

🛠️ API Gateway란 무엇일까?

API Gateway는 클라이언트와 백엔드 서비스 사이에서 **중재자** 역할을 하는 강력한 도구입니다. 클라이언트가 서비스의 내부 구현 세부사항(네트워크 구조나 아키텍처)을 알 필요 없이, 잘 정의된 API를 통해 쉽게 접근할 수 있도록 돕죠. 예를 들어, API Gateway는 다음과 같은 기능을 제공합니다:

  • 문서화된 API: 클라이언트가 이해하기 쉬운 API 명세를 제공.
  • 호환성 유지: API가 과거/미래 버전과 호환되도록 관리.
  • 셀프서비스: 개발자가 직접 API를 등록하고 사용할 수 있는 포털 제공.

이 외에도 보안, 메시지 변환, 트래픽 관리 등 다양한 기능을 지원해요. 쉽게 말해, API Gateway는 클라이언트와 서비스 사이의 **편리한 다리** 같은 존재입니다!

API Gateway는 클라이언트와 서비스 사이에서 API 접근을 간편하고 안전하게 만드는 중재자입니다.

🔒 API Gateway의 강력한 기능들

API Gateway는 단순한 트래픽 전달을 넘어 고급 기능을 제공합니다:

  • 보안: OpenID Connect(OIDC), OAuth 2.0, LDAP 같은 다양한 인증/인가 방식을 지원해 클라이언트를 식별합니다.
  • 메시지 변환: SOAP를 REST로, gRPC를 REST로 변환하거나, 요청 본문/헤더를 변형합니다.
  • 비즈니스 수준의 제어: 세밀한 rate limiting(속도 제한)으로 트래픽을 관리합니다.
  • 개발자 포털: 개발자가 직접 API를 탐색하고 등록할 수 있는 셀프서비스 환경을 제공합니다.

이런 기능들은 클라이언트 경험을 향상시키고, 서비스 운영을 더 유연하게 만들어줍니다. 😎

API Gateway는 보안, 메시지 변환, rate limiting, 개발자 포털 등 고급 기능을 제공해 클라이언트 경험을 최적화합니다.

🚪 Istio Ingress Gateway의 역할과 한계

Istio의 **Ingress Gateway**는 서비스 메쉬의 **엣지**에서 외부 트래픽을 받아들이는 문지기입니다. Gateway와 VirtualService를 통해 포트, 프로토콜, 도메인을 설정하고, 트래픽을 내부 서비스로 라우팅하죠. 하지만 Istio Ingress Gateway는 API Gateway처럼 클라이언트 중심의 고급 기능을 기본적으로 제공하지 않습니다.

예를 들어, Istio는 인증(OIDC, OAuth), 메시지 변환(SOAP ↔ REST), 셀프서비스 포털 같은 기능이 기본적으로 포함되지 않아요. 이런 기능이 필요하다면, Istio를 기반으로 추가적인 설정을 하거나, **Solo.io Gloo Edge** 같은 전용 API Gateway 솔루션을 고려해야 합니다(docs.solo.io/gloo-edge).

Istio Ingress Gateway는 서비스 메쉬의 트래픽 입구를 관리하지만, API Gateway의 고급 기능(인증, 변환, 포털)은 기본적으로 지원하지 않습니다.

🆚 언제 무엇을 선택해야 할까?

Istio Ingress Gateway와 API Gateway는 서로 다른 목적을 위해 설계되었습니다:

  • Istio Ingress Gateway: 서비스 메쉬 환경에서 트래픽을 클러스터 내부로 가져오고, VirtualService로 라우팅하는 데 최적화되어 있어요. HTTP, TCP, gRPC 등 다양한 프로토콜을 지원하며, 서비스 메쉬 내부의 트래픽 관리에 강점을 발휘합니다.
  • API Gateway: 클라이언트와 서비스 사이의 API 관리에 초점을 맞춥니다. 보안, 메시지 변환, rate limiting, 개발자 포털 같은 기능을 통해 클라이언트 경험을 최적화하죠.

만약 서비스 메쉬 내에서 트래픽 라우팅과 관리가 주된 목표라면 Istio Ingress Gateway가 적합합니다. 반면, 클라이언트 중심의 API 관리와 고급 기능이 필요하다면 API Gateway를 선택하거나, Istio 위에 Gloo Edge 같은 솔루션을 추가하는 게 좋아요! 🚀

Istio Ingress Gateway는 서비스 메쉬 트래픽 관리에, API Gateway는 클라이언트 중심 API 관리에 적합합니다.

🎉 마무리

Istio Ingress Gateway와 API Gateway는 트래픽을 처리한다는 공통점이 있지만, 각각의 초점은 다릅니다. Istio는 서비스 메쉬 내부의 트래픽 라우팅에 강력한 도구이고, API Gateway는 클라이언트와 API 간의 상호작용을 최적화하는 데 특화되어 있습니다.

저작자표시

'Istio Hands-on Study [1기]' 카테고리의 다른 글

2주차 : Istio gateways > 클러스터로 트래픽 유입 : 운영 팁  (0) 2025.04.15
2주차 : Istio gateways > 클러스터로 트래픽 유입 : gateways 트래픽 보안  (0) 2025.04.15
2주차 : Istio gateways > 클러스터로 트래픽 유입 : 트래픽 유입 개념  (0) 2025.04.15
2주차 : Istio 데이터 플레인 > The Envoy proxy : Envoy와 Istio의 사용 방법  (0) 2025.04.15
2주차 : Istio 데이터 플레인 > The Envoy proxy : Envoy in action  (0) 2025.04.15
'Istio Hands-on Study [1기]' Related Articles more
Comments