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

CloudNet@ 가시다님이 진행하는 Istio Hands-on Study [1기]

---

🚀 Istio Gateway를 똑똑하게 활용하는 운영 팁

---

🚀1. Istio Gateway로 트래픽 분리와 유연한 관리 구현하기

• Gateway는 단순한 Envoy 프록시로, ingress뿐 아니라 egress, multi-cluster proxying, 또는 팀별 전용 게이트웨이 같은 다양한 용도로 사용할 수 있습니다.
• 이번 가이드에서는 여러 개의 Gateway를 배포해 트래픽을 분리하고, 팀별로 독립적으로 관리하는 방법을 설명합니다.

---

🌟 Gateway의 다양한 활용과 다중 Ingress의 필요성

• Istio의 Gateway는 사이드카로 배포되지 않은 Envoy 프록시로, ingress, egress, 공유 게이트웨이, 멀티 클러스터 프록시 등 다양한 역할을 수행할 수 있습니다. 특히 ingress의 경우, 단일 Gateway를 모든 트래픽의 진입점으로 사용할 수 있지만, 때로는 여러 개의 Gateway를 배포해 트래픽을 분리하는 것이 더 유리합니다.
• 다중 Gateway를 사용하는 이유는 다음과 같습니다:
  • 성능 최적화: 특정 서비스에 더 높은 성능이 필요한 경우.
  • 고가용성: 중요한 서비스를 위한 전용 Gateway로 안정성을 확보.
  • 규제 준수: 민감한 데이터를 처리하는 서비스를 격리.
  • 팀별 자율성: 각 팀이 독립적으로 Gateway와 설정을 관리.

여러 Gateway를 배포하면 팀별로 트래픽 경로를 분리하고, 서로의 설정에 영향을 주지 않도록 관리할 수 있습니다.

 

단일 Gateway 대신 다중 Gateway를 사용하면 트래픽을 분리하고,
성능, 보안, 팀 자율성을 강화할 수 있습니다.

---

🛠️ 사용자 정의 Gateway 배포하기

• 팀별 또는 서비스별로 전용 Gateway를 배포하려면 IstioOperator 리소스를 사용해 새로운 Gateway를 정의하고 설치합니다.
• 아래는 istioinaction 네임스페이스에 my-user-gateway 라는 사용자 정의 Gateway 를 설정하는 예제입니다:

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ docker exec -it myk8s-control-plane bash
root@myk8s-control-plane:/# cat <<EOF > my-user-gateway-edited.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: my-user-gateway-install
  namespace: istioinaction
spec:
  profile: empty
  values:
    gateways:
      istio-ingressgateway:
        autoscaleEnabled: false
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: false
    - name: my-user-gateway
      namespace: istioinaction
      enabled: true
      label:
        istio: my-user-gateway
      k8s:
        service:
          ports:
            - name: tcp  # my-user-gateway 에서 사용할 포트 설정
              port: 31400
              targetPort: 31400
              nodePort: 30007 # 외부 접속을 위해 NodePort Number 직접 설정
EOF

• 이 설정은 다음과 같은 작업을 수행합니다:
  • 기본 istio-ingressgateway는 비활성화합니다(enabled: false).
  • my-user-gateway라는 새로운 Gateway를 istioinaction 네임스페이스에 활성화합니다.
  • label: istio: my-user-gateway로 Gateway를 식별합니다.
• 이 Gateway를 설치하려면 다음 명령어를 실행합니다:

root@myk8s-control-plane:/# istioctl install -y -n istioinaction -f my-user-gateway-edited.yaml
✔ Ingress gateways installed
✔ Installation complete
Thank you for installing Istio 1.17.  Please take a few minutes to tell us about your install/upgrade experience!  https://forms.gle/hMHGiwZHPU7UQRWe9
root@myk8s-control-plane:/# exit
exit

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl get IstioOperator -A
NAMESPACE       NAME                                      REVISION   STATUS   AGE
istio-system    installed-state                                               3h51m
istioinaction   installed-state-my-user-gateway-install                       48s

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl get deploy my-user-gateway -n istioinaction
NAME              READY   UP-TO-DATE   AVAILABLE   AGE
my-user-gateway   1/1     1            1           56s

 

• Istio에서 외부 TCP 트래픽(포트 31400)을 수신하기 위한 TCP 전용 게이트웨이 (my-user-gateway) 를 생성

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ cat <<EOF | kubectl apply -n istioinaction -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: echo-tcp-gateway
spec:
  selector:
    istio: my-user-gateway  #  New gateway
  servers:
  - port:
      number: 31400
      name: tcp-echo
      protocol: TCP
    hosts:
    - "*"
EOF
gateway.networking.istio.io/echo-tcp-gateway created

• telnet localhost 30007 명령으로 Istio TCP 게이트웨이를 통해 tcp-echo 서비스에 정상적으로 접속된 것을 확인

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ telnet localhost 30007
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Welcome, you are connected to node myk8s-control-plane.
Running on Pod tcp-echo-deployment-584f6d6d6b-dbzgq.
In namespace istioinaction.
With IP address 10.10.0.14.
Service default.
 Split gateway responsibilities
 Split gateway responsibilities
^]
telnet> quit
Connection closed.

IstioOperator를 사용해 사용자 정의 Gateway를 배포하면,
특정 네임스페이스에 전용 진입점을 만들고 팀별로 독립적인 트래픽 관리가 가능합니다.

---

⚠️ 다중 Gateway 배포 시 고려사항

• 새로운 Gateway를 배포할 때는 외부 트래픽이 접근할 수 있도록 네트워크 설정을 고려해야 합니다. 예를 들어:
  • 클라우드 환경: Gateway를 외부로 노출하려면 Kubernetes 서비스의 type: LoadBalancer를 사용해야 합니다. 하지만 각 LoadBalancer는 추가 비용이 발생할 수 있습니다.
  • NodePort: 로컬 환경(예: Docker Desktop)에서는 NodePort로 포트를 노출할 수 있습니다.

다중 Gateway는 유연성을 제공하지만,
외부 노출을 위한 네트워크 설정(LoadBalancer, NodePort 등)과 비용을 신중히 고려해야 합니다.

---

🎯 다중 Gateway로 유연한 트래픽 관리 시작!

이제 Istio Gateway의 유연성을 활용해 트래픽을 분리하고, 팀별로 독립적인 ingress를 관리하는 방법을 배웠습니다. 단일 Gateway를 넘어 다중 Gateway를 배포하면 성능, 보안, 팀 자율성을 크게 향상시킬 수 있죠. IstioOperator를 사용해 사용자 정의 Gateway를 쉽게 설정하고, 각 서비스의 요구사항에 맞는 트래픽 경로를 설계할 수 있습니다.

---

🚀 2. Istio Gateway Injection으로 팀별 Gateway 간편하게 설정하기

이전 가이드에서 IstioOperator를 사용해 사용자 정의 Gateway를 배포하는 방법을 배웠습니다. 하지만 팀이 IstioOperator 같은 강력한 리소스에 직접 접근하지 않고도 자신만의 Gateway를 만들 수 있다면 어떨까요? Gateway Injection은 이를 가능하게 해줍니다! 마치 사이드카 주입처럼, 최소한의 설정으로 Gateway를 배포하고 Istio가 나머지를 자동으로 채워줍니다. 

---

🔧 Gateway Injection으로 간단한 Gateway 배포

• Gateway Injection은 팀이 전체 Istio 설정을 수정할 권한 없이도 자신만의 Gateway를 배포할 수 있도록 설계된 기능입니다. 사용자는 최소한의 Deployment 리소스(스텁)를 정의하고, Istio가 자동으로 Gateway 설정을 완성합니다. 이 과정은 Istio의 sidecar injection과 유사하며, 팀의 자율성을 높이면서 보안을 유지합니다.
• 아래는 Gateway Injection을 위한 스텁 Deployment 예제입니다:

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ cat ch4/my-user-gw-injection.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-user-gateway-injected
  namespace: istioinaction
spec:
  selector:
    matchLabels:
      ingress: my-user-gateway-injected
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
        inject.istio.io/templates: gateway
      labels:
        ingress: my-user-gateway-injected
    spec:
      containers:
      - name: istio-proxy
        image: auto
---

• 이 설정은 다음과 같은 작업을 수행합니다:
  • sidecar.istio.io/inject: "true": Istio가 이 Deployment에 프록시를 주입하도록 지시합니다.
  • inject.istio.io/templates: gateway: 주입할 템플릿을 Gateway로 지정합니다.
  • name: istio-proxy와 image: auto: Istio가 자동으로 적절한 프록시 이미지를 선택합니다.

Gateway Injection은 스텁 Deployment에 주입 지시자(annotations)를 추가해
Istio가 Gateway 설정을 자동으로 완성하도록 합니다.

---

🛠️ 스텁 Gateway 배포하기

• 이제 위의 스텁 Deployment를 적용해 Gateway를 배포합니다. 다음 명령어를 실행합니다:

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl apply -f ch4/my-user-gw-injection.yaml
deployment.apps/my-user-gateway-injected created
service/my-user-gateway-injected created
role.rbac.authorization.k8s.io/my-user-gateway-injected-sds created
rolebinding.rbac.authorization.k8s.io/my-user-gateway-injected-sds created

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl get deploy,svc,ep my-user-gateway-injected -n istioinaction
NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/my-user-gateway-injected   1/1     1            1           4s

NAME                               TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
service/my-user-gateway-injected   LoadBalancer   10.200.1.185   <pending>     80:31664/TCP,443:30424/TCP   4s

NAME                                 ENDPOINTS                      AGE
endpoints/my-user-gateway-injected   10.10.0.18:443,10.10.0.18:80   4s

• 이 명령어는 다음 리소스를 생성합니다:
  • deployment.apps/my-user-gateway-injected: Gateway Deployment
  • service/my-user-gateway-injected: Gateway를 노출하는 서비스
  • role.rbac.authorization.k8s.io/my-user-gateway-injected-sds: SDS(Secret Discovery Service) 접근 권한
  • rolebinding.rbac.authorization.k8s.io/my-user-gateway-injected-sds: 권한 바인딩
• 배포 후, istioinaction 네임스페이스의 Pod를 확인하면 Istio가 주입한 완전한 Gateway가 실행 중인 것을 볼 수 있습니다.

kubectl apply로 스텁 Deployment를 배포하면,
Istio가 자동으로 Gateway 설정을 완성해 즉시 사용 가능한 Gateway를 제공합니다.

---

🔍 Gateway Injection의 장점

• Gateway Injection은 팀이 IstioOperator 같은 고급 권한 없이도 Gateway를 배포할 수 있도록 해줍니다. 주요 장점은 다음과 같습니다:
  • 보안 강화: 팀은 제한된 권한으로 자신만의 Gateway를 관리할 수 있습니다.
  • 간편한 설정: 최소한의 YAML로 Gateway를 배포할 수 있어 복잡성이 줄어듭니다.
  • 유연성: 팀별, 서비스별로 독립적인 Gateway를 운영할 수 있습니다.

Gateway Injection은 팀 자율성을 유지하면서 안전하고 간단하게 Gateway를 배포할 수 있는 강력한 방법입니다.

---

🎯 Gateway Injection으로 팀 자율성 극대화!

이제 Gateway Injection을 활용해 최소한의 설정으로 사용자 정의 Gateway를 배포하는 방법을 배웠습니다. 스텁 Deployment에 주입 지시자를 추가하면 Istio가 나머지 설정을 자동으로 처리해줍니다. 이를 통해 팀은 전체 Istio 설정에 접근하지 않고도 자신만의 Gateway를 자유롭게 관리할 수 있습니다.

---

📜 3. Istio Ingress Gateway 액세스 로그로 트래픽 추적하기

Istio의 Gateway를 통해 들어오는 트래픽을 관리하다 보면, 어떤 요청이 처리되고 있는지 확인하고 싶을 때가 있습니다. 이때 **액세스 로그(access logs)**가 큰 도움이 되죠! Istio의 프록시(Envoy)는 모든 요청을 기록하는 액세스 로그를 생성할 수 있으며, 이를 통해 문제를 진단하거나 트래픽 흐름을 분석할 수 있습니다. 

---

📋 Ingress Gateway 액세스 로그 확인하기

• Istio의 demo 설치 프로파일에서는 Ingress Gateway와 서비스 프록시가 기본적으로 액세스 로그를 표준 출력(stdout)으로 기록하도록 설정되어 있습니다. 이를 확인하려면 istio-ingressgateway의 컨테이너 로그를 출력하면 됩니다:

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl logs -f deploy/istio-ingressgateway -n istio-system
...

• 이 명령어는 Ingress Gateway의 액세스 로그를 출력하며, 이전 예제에서 생성된 트래픽 기록을 확인할 수 있습니다. 로그에는 요청의 세부 정보(예: 요청 시간, 경로, 응답 코드 등)가 포함되어 있어 디버깅에 유용합니다.

demo 프로파일에서는 Ingress Gateway의 액세스 로그가 기본적으로 활성화되어 있으며,
kubectl logs로 쉽게 확인할 수 있습니다.

---

⚙️ 프로덕션 환경에서 액세스 로그 활성화하기

• default 프로파일을 사용하는 프로덕션 Istio 설치에서는 액세스 로그가 기본적으로 비활성화되어 있습니다. 이는 대규모 클러스터에서 수백, 수천 개의 워크로드가 생성하는 로그가 로깅 시스템에 부담을 줄 수 있기 때문입니다. 각 요청이 여러 서비스를 거치며 다중 홉(hop)을 발생시키므로 로그 양이 급격히 증가할 수 있죠.
• 액세스 로그를 활성화하려면 accessLogFile 속성을 설정해 표준 출력으로 로그를 출력하도록 구성할 수 있습니다:

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ docker exec -it myk8s-control-plane bash

root@myk8s-control-plane:/# istioctl install --set meshConfig.accessLogFile=/dev/stdout
This will install the Istio 1.17.8 default profile with ["Istio core" "Istiod" "Ingress gateways"] components into the cluster. Proceed? (y/N) y
✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete                                                                                 Making this installation the default for injection and validation.

Thank you for installing Istio 1.17.  Please take a few minutes to tell us about your install/upgrade experience!  https://forms.gle/hMHGiwZHPU7UQRWe9
root@myk8s-control-plane:/# exit
exit

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$

 

• configmap 에 mesh 바로 아래에 accessLogFile 부분 추가됨

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ kubectl get cm -n istio-system istio -o yaml
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
...

프로덕션 환경에서는 액세스 로그가 기본적으로 꺼져 있지만,
accessLogFile=/dev/stdout 설정으로 전체 워크로드의 로그를 활성화할 수 있습니다.

---

🎯 Telemetry API로 특정 워크로드 로그 활성화

• 모든 워크로드의 로그를 활성화하면 로그 양이 너무 많아질 수 있습니다. Istio 1.12부터 도입된 Telemetry API 를 사용하면 특정 워크로드(예: Ingress Gateway)에만 액세스 로그를 선택적으로 활성화할 수 있습니다.
• 아래는 Ingress Gateway에만 로그를 활성화하는 Telemetry 리소스 예제입니다:

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: ingress-gateway
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  accessLogging:
  - providers:
    - name: envoy
      disabled: false

• 이 설정은 다음과 같은 작업을 수행합니다:
  • selector로 app: istio-ingressgateway 레이블이 있는 Pod에만 로그를 활성화합니다.
  • providers에서 envoy를 지정해 Envoy 프록시의 로그를 생성합니다.
  • disabled: false로 로그를 활성화합니다.
• 로그를 비활성화하려면 disabled: true로 설정하면 됩니다. 이를 테스트해 Ingress Gateway의 로그 출력이 중지되는지 확인할 수 있습니다.

Telemetry API를 사용하면 필요한 워크로드에만 액세스 로그를 활성화해 로그 양을 효율적으로 관리할 수 있습니다.

---

🔍 Istio 설정의 스코프와 우선순위

• Istio의 설정(예: Telemetry, sidecar, peer authentication 등)은 적용 범위에 따라 세 가지 스코프로 나뉘며, 우선순위가 다릅니다:
  • Mesh-wide: 전체 서비스 메시에 적용됩니다. Istio 설치 네임스페이스에 설정하며, 워크로드 셀렉터가 없습니다.
  • Namespace-wide: 특정 네임스페이스의 모든 워크로드에 적용됩니다. 워크로드 셀렉터 없이 네임스페이스에 설정하며, Mesh-wide 설정을 덮어씁니다.
  • Workload-specific: 특정 워크로드(셀렉터로 지정)에만 적용됩니다. 네임스페이스 내에서 설정하며, Mesh-wide와 Namespace-wide 설정을 모두 덮어씁니다.
• 예를 들어, 위 Telemetry 설정은 istio-ingressgateway 워크로드에만 적용되므로 Workload-specific 스코프입니다.

Istio 설정은 Mesh-wide, Namespace-wide, Workload-specific 순으로 우선순위가 높아지며,
세밀한 로그 관리를 가능하게 합니다.

---

🎯 액세스 로그로 트래픽 디버깅 시작!

이제 Istio Ingress Gateway의 액세스 로그를 활성화하고 관리하는 방법을 배웠습니다. 기본 로그 확인부터 프로덕션 환경에서의 선택적 로깅, 그리고 Telemetry API를 활용한 워크로드별 로그 설정까지, 트래픽 문제를 효과적으로 추적할 수 있는 도구를 손에 쥐었죠. 설정 스코프를 이해하면 로그뿐 아니라 다른 Istio 설정도 유연하게 관리할 수 있습니다.

---

🚀 4. Istio Gateway 설정 최적화로 효율적인 트래픽 관리

Istio는 기본적으로 서비스 메시 내 모든 서비스 정보를 프록시에 설정합니다. 하지만 서비스가 많아질수록 이 설정은 방대해져 성능 저하와 확장성 문제를 일으킬 수 있죠. 특히 Ingress Gateway 같은 Gateway는 모든 서비스 정보를 포함하므로 부담이 큽니다. 이번 가이드에서는 Gateway 설정 최적화를 통해 불필요한 구성을 줄이고 성능을 향상시키는 방법을  설명합니다.

---

⚠️ 대규모 서비스 메시에서의 설정 과부하

• Istio는 기본적으로 모든 프록시(데이터 플레인)에 서비스 메시 내 모든 서비스 정보를 설정합니다. 이는 소규모 환경에서는 문제가 없지만, 수백, 수천 개의 서비스가 있는 대규모 메시에서는 다음과 같은 문제를 초래할 수 있습니다:
  • 리소스 낭비: 프록시 설정이 커져 메모리와 CPU 사용량이 증가.
  • 성능 저하: 대량의 설정 처리로 인해 요청 처리 속도가 느려짐.
  • 확장성 문제: 새로운 서비스 추가 시 프록시 설정이 계속 늘어남.
• Sidecar 리소스를 사용하면 일반 워크로드의 설정을 줄일 수 있지만 Gateway에는 적용되지 않습니다. Ingress Gateway는 기본적으로 모든 서비스 정보를 포함하므로 최적화가 필요합니다.

대규모 서비스 메시에서는 프록시 설정이 과도하게 커질 수 있으며,
특히 Gateway는 모든 서비스 정보를 포함해 성능에 부담을 줍니다.

---

🔧 Gateway 설정 최적화 활성화하기

• Gateway의 설정을 최적화하려면 불필요한 서비스 정보를 제외하고, Gateway와 관련된 VirtualService에서 참조하는 클러스터만 포함하도록 설정을 조정해야 합니다.
• Istio는 이를 위해 PILOT_FILTER_GATEWAY_CLUSTER_CONFIG 기능을 제공합니다. 최신 버전에서는 이 기능이 기본적으로 활성화될 수 있지만, 명시적으로 설정하는 것이 안전합니다.
• 아래는 Gateway 설정 최적화를 활성화하는 IstioOperator 리소스 예제입니다:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: control-plane
spec:
  profile: minimal
  components:
    pilot:
      k8s:
        env:
        - name: PILOT_FILTER_GATEWAY_CLUSTER_CONFIG
          value: "true"
  meshConfig:
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"
      enablePrometheusMerge: true

• 이 설정은 다음과 같은 작업을 수행합니다:
  • PILOT_FILTER_GATEWAY_CLUSTER_CONFIG: "true": Gateway 프록시 설정에서 VirtualService가 참조하는 클러스터만 포함하도록 필터링합니다.
  • 불필요한 서비스 정보를 제거해 설정 크기를 줄입니다.

 

PILOT_FILTER_GATEWAY_CLUSTER_CONFIG를 활성화하면
Gateway 설정이 VirtualService와 관련된 클러스터로 제한되어 성능과 리소스 효율성이 향상됩니다.

---

🌟 최적화로 얻는 이점

• Gateway 설정 최적화를 적용하면 다음과 같은 이점을 얻을 수 있습니다:
  • 리소스 절약: 프록시 설정이 간소화되어 메모리와 CPU 사용량이 감소.
  • 성능 향상: 더 적은 설정을 처리하므로 트래픽 처리 속도가 빨라짐.
  • 확장성 강화: 대규모 서비스 메시에서도 Gateway가 안정적으로 동작.
• 이 기능은 특히 서비스 수가 많거나 트래픽이 많은 환경에서 큰 차이를 만듭니다.

Gateway 설정 최적화는 리소스 사용을 줄이고 성능을 높여 대규모 서비스 메시를 효율적으로 관리할 수 있게 합니다.

---

🎯 Gateway 최적화로 서비스 메시 성능 극대화!

이제 PILOT_FILTER_GATEWAY_CLUSTER_CONFIG를 사용해 Istio Gateway의 설정을 최적화하는 방법을 배웠습니다. 불필요한 서비스 정보를 제거함으로써 Gateway의 성능을 높이고, 리소스 사용을 줄이며, 대규모 서비스 메시에서도 안정적인 운영을 가능하게 했죠. 이는 특히 Ingress Gateway처럼 트래픽이 집중되는 지점에서 큰 효과를 발휘합니다.