반응형
안녕하세요?
Istio in Action 책을 공부하면서 내용을 조금씩 정리해보려고 합니다.
4장은 이스티오 게이트웨이 : 클러스터로 트래픽 들이기 입니다.
실습 환경 준비
- MacOS, OrbStack으로 Container 구동
- Kind, k8s 1.33.1
- istioctl 1.27.0
curl -L https://istio.io/downloadIstio | sh -
istioctl install --set profile=demo -y
|\
| \
| \
| \
/|| \
/ || \
/ || \
/ || \
/ || \
/ || \
/______||__________\
____________________
\__ _____/
\_____/
WARNING: Istio is being upgraded from 1.13.0 to 1.27.0.
Running this command will overwrite it; use revisions to upgrade alongside the existing version.
Before upgrading, you may wish to use 'istioctl x precheck' to check for upgrade warnings.
✔ Istio core installed ⛵️
✔ Istiod installed 🧠
✔ Egress gateways installed 🛫
✔ Ingress gateways installed 🛬
✔ Installation completek get pod -n istio-system
NAME READY STATUS RESTARTS AGE
istio-egressgateway-559bd55945-nspdv 1/1 Running 0 10m
istio-ingressgateway-74df47f5f9-nv65v 1/1 Running 0 10m
istiod-85798b5866-8ptm6 1/1 Running 0 11m
4.1 트래픽 인그레스 개념
- Ingress : 네트워크 외부에서 네트워크 내부 엔드포인트를 향하는 트래픽
- Ingress Point : 어떤 트래픽을 로컬 네트워크로 허용할지에 대한 규칙과 정책 집행
4.1.1 가상 IP : 서비스 접근 단순화
- 도메인은 서비스의 단일 인스턴스나 단일 IP 에 대응시켜선 안된다. 다운이 될 수 있다는 점에서 취약하다.
- 그러니 가상 IP주소가 실제 인스턴스로 트래픽을 전달 할 수 있도록 리버스 프록시에 바인딩하는 것이 좋다.
- 물론 리버스 프록시는 로드밸런싱 같은 기능도 있어서 여러 백엔드에 부하를 분산할 수 있다.
4.1.2 가상 호스팅 : 단일 접근 지점의 여러 서비스
- prod.istioinaction.io, api.istioinaction.io가 모두 동일한 가상 IP로 해석되게 하기
- 리버스 프록시를 이용해 HTTP 헤더를 사용해 이를 분산할 수 있다.
- HTTP/1.1에서는 Host헤더, HTTP/2에서는 :authority 헤더를 사용 가능
- TCP 커넥션에서는 TLS의 SNI Server Name Indication 으로 가능
4.2 이스티오 인그레스 게이트웨이
- 이스티오의 인그레스 게이트웨이는 인그레스 포인트 역할을 한다.
- 로드 밸런싱, 가상 호스트 라우팅, 리버스 프록시 기능을 수행한다.
- 이 인그레스 게이트웨이에는 사실 "단일 엔보이 프록시" 를 사용한다.
- 엔보이 프록시는 아래와 같이 이스티오 인그레스 게이트웨이 내에서 동작중이다.
- pilot-agent 프로세스는 처음에 엔보이 프록시를 설정하고 부트스트랩하며 DNS 프록시도 구현한다.
k -n istio-system exec deploy/istio-ingressgateway -- ps PID TTY TIME CMD 1 ? 00:00:00 pilot-agent 22 ? 00:00:02 envoy 36 ? 00:00:00 ps
4.2.1 Gateway 리소스 지정하기
- 아래 게이트웨이 리소스는
- 80포트를 리스닝하고
- HTTP 트래픽을 기대하도록
- "엔보이"를 설정한다.
- 그러니까 특정 포트를 노출하고, 그 포트에서 특정 프로토콜을 예상하고, 그 포트/프로토콜 쌍에서 서빙할 특정 호스트를 정의한다.
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" <-- 이 포트에서 허용할 가상 호스트
그리고 나서 proxy config를 확인하면 listener 상태가 변경된 것을 볼 수 있다.
HTTP 포트를 올바르게 노출하고 있다.
istioctl -n istio-system proxy-config listener deploy/istio-ingressgateway
ADDRESSES 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*기본 isito-ingressgatway는 권한 있는 privileged 접근이 필요하지 않다.
시스템 포트 (HTTP의 경우 80)를 리스닝하지 않기 때문이다.
istio-ingressgateway는 기본적으로 8080 포트에서 리스닝한다. 4.2.2 VirtualService로 게이트웨이 라우팅하기
- VirtualService는 게이트웨이로 들어온 트래픽을 서비스 메시 내 특정 서비스로 가져온다.
- 클라이언트가 특정 서비스와 통신하는 방법을 정의한다.
- FQDN, 서비스 버젼, 라우팅 속성(재시도, 타임아웃)
- 트래픽 규칙들은 정의한 게이트웨이를 통해 들어온 트래픽에만 적용된다.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: webapp-vs-from-gw
spec:
hosts:
- "webapp.istioinaction.io" <-- 비교할 가상 호스트 네임
gateways:
- coolstore-gateway <-- 이 VS를 적용할 게이트웨이
http:
- route:
- destination: <-- 이 트래픽의 목적 서비스
host: webapp
port:
number: 80- 위 manifest를 적용한 뒤의 리스너와 루트를 볼 수 있다.
- 엔보이 루트는 이렇게 생성된다.
- 도메인이 webapp.istioinaction.io와 일치하는 트래픽을
- 서비스 메시 내 webapp 으로 라우팅한다.
istioctl proxy-config route deploy/istio-ingressgateway -o json --name http.8080 -n istio-system
[
{
"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"
},
"maxGrpcTimeout": "0s"
},
"metadata": {
"filterMetadata": {
"istio": {
"config": "/apis/networking.istio.io/v1/namespaces/istioinaction/virtual-service/webapp-vs-from-gw"
}
}
},
"decorator": {
"operation": "webapp.istioinaction.svc.cluster.local:80/*"
}
}
],
"includeRequestAttemptCount": true
}
],
"validateClusters": false,
"maxDirectResponseBodySizeBytes": 1048576,
"ignorePortInHostMatching": true
}
]docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' kind-control-plane
192.168.97.2curl http://192.168.97.2:31733/api/catalog -H "Host: webapp.istioinaction.io"
[{"id":1,"color":"amber","department":"Eyewear","name":"Elinor Glasses","price":"282.00"},{"id":2,"color":"cyan","department":"Clothing","name":"Atlas Shirt","price":"127.00"},{"id":3,"color":"teal","department":"Clothing","name":"Small Metal Shoes","price":"232.00"},{"id":4,"color":"red","department":"Watches","name":"Red Dragon Watch","price":"232.00"}]4.2.3 전체적인 트래픽 흐름 개요
4.2.4 이스티오 인그레스 게이트웨이 vs 쿠버네티스 인그레스
쿠버네티스 인그레스 v1의 문제
- 사양이 HTTP 워크로드에 맞춰져 있다.
- 인그레스 사양은 80 포트와 443 포트만 인그레스 포인트로 간주한다.
- TCP 커넥션을 직접 노출하고 싶어도 허용하지 않는다.
- 쿠버네티스 인그레스 v1 리소스의 사양 부족
- 복잡한 라우팅 규칙, 트래픽 분할, 트래픽 섀도잉
이스티오는 이 단점들을 해결하기 위해
- Gateway에서 L4, L5 문제를 처리
- VirtualService는 L7 문제를 처리
4.3 게이트웨이 트래픽 보안
4.3.1 TLS를 사용한 HTTP 트래픽
- 이스티오 게이트웨이 <- 에 TLS를 설정할 수 있다
인증서와 키로 secret을 생성해서
kubectl create -n istio-system secret tls webapp-credential --key ch4/certs/3_application/private/webapp.istioinaction.io.key.pem --cert ch4/certs/3_application/certs/webapp.istioinaction.io.cert.pem
secret/webapp-credential created
이스티오 게이트웨이 리소스가 인증서와 키를 사용할 수 있도록 설정할 수 있다.
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"
- port:
number: 443 <--- 보안 HTTPS 트래픽 허용
name: https
protocol: HTTPS
tls:
mode: SIMPLE <--- 보안 커넥션
credentialName: webapp-credential <--- 생성한 시크릿 이름
hosts:
- "webapp.istioinaction.io"
tls.mode는
- SIMPLE
- Gateway가 서버 인증서 (Secret의 Cert, Key) 를 이용해 TLS Termination 수행
- 클라이언트 <-> Gateway 구간은 HTTPS/TLS로 암호화되고, Gateway가 트래픽을 복호화한 뒤 내부 서비스에 평문 HTTP로 전달
- MUTUAL
- Gateway가 TLS Termination을 하지만 추가로 클라이언트 인증서도 검증
- PASSTHROUGH
- Gateway가 TLS 핸드셰이크를 직접 처리하지 않고, 단순히 TCP 레벨에서 트래픽을 백엔드로 넘김
- TLS Termination은 내부 서비스에서 수행
- Gateway는 프록시 역할만 수행
- AUTO_PASSTHROUGH / ISTIO_MUTUAL
- 클러스터 내부의 mTLS와 연계
- 멀티 호스트 / 다중 도메인 환경에서 SNI 기반 자동 라우팅
curl -vk --tlsv1.2 --resolve webapp.istioinaction.io:31170:192.168.97.2 https://webapp.istioinaction.io:31170/api/catalog
* Added webapp.istioinaction.io:31170:192.168.97.2 to DNS cache
* Hostname webapp.istioinaction.io was found in DNS cache
* Trying 192.168.97.2:31170...
* Connected to webapp.istioinaction.io (192.168.97.2) port 31170
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
* subject: C=US; ST=Denial; L=Springfield; O=Dis; CN=webapp.istioinaction.io
* start date: Jul 4 12:49:32 2021 GMT
* expire date: Jun 29 12:49:32 2041 GMT
* issuer: C=US; ST=Denial; O=Dis; CN=webapp.istioinaction.io
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://webapp.istioinaction.io:31170/api/catalog
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: webapp.istioinaction.io:31170]
* [HTTP/2] [1] [:path: /api/catalog]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET /api/catalog HTTP/2
> Host: webapp.istioinaction.io:31170
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/2 200
< content-length: 357
< content-type: application/json; charset=utf-8
< date: Tue, 19 Aug 2025 15:31:51 GMT
< x-envoy-upstream-service-time: 186
< server: istio-envoy
<
* Connection #0 to host webapp.istioinaction.io left intact
[{"id":1,"color":"amber","department":"Eyewear","name":"Elinor Glasses","price":"282.00"},{"id":2,"color":"cyan","department":"Clothing","name":"Atlas Shirt","price":"127.00"},{"id":3,"color":"teal","department":"Clothing","name":"Small Metal Shoes","price":"232.00"},{"id":4,"color":"red","department":"Watches","name":"Red Dragon Watch","price":"232.00"}]%4.3.2 HTTPS로 HTTP 리다이렉트
모든 트래픽이 항상 TLS로 강제하는 방법
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"
tls:
httpsRedirect: true <-- HTTP를 HTTPS로 리다이렉트
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: webapp-credential
hosts:
- "webapp.istioinaction.io"4.3.3 상호 TLS를 활용한 HTTP 트래픽
기본 istio-ingressgateway가 상호 TLS 커넥션에 참여하도록 구성
-> 클라이언트의 인증서를 검증하는 데 사용할 수 있도록 CA 인증서 집합 제공
위에 생성한 시크릿으로 istio-ingressgateway에서 이 CA 인증서를 사용할 수 있게 설정
kubectl create -n istio-system secret generic webapp-credential-mtls --from-files=tls.key=ch4/certs/3_application/private/webapp.istioinaction.io.key.pem --from-file=tls.crt=ch4/certs/3_application/certs/webapp.istioinaction.io.cert.pem --from-file=ca.crt=ch4/certs/2_intermediate/certs/ca-chain.cert.pemapiVersion: 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"
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: MUTUAL <--- 상호 TLS 설정
credentialName: webapp-credential-mtls
hosts:
- "webapp.istioinaction.io"tls.mode
- MUTUAL
- Gateway가 TLS Termination을 하지만 추가로 클라이언트 인증서도 검증
4.4 TCP 트래픽
- 이스티오의 게이트웨이은 TCP로 접근하는 모든 트래픽을 처리 가능
- 하지만 단순 TCP로 다룰 때는 이스티오가 어떤 프로토콜을 사용하는지 분간할 수 없기 때문에
- 재시도, 요청 수준 서킷 브레이킹, 복잡한 라우팅 등의 기능을 사용 불가
4.4.1 이스티오 게이트웨이에서 TCP 포트 노출하기
TCP 를 위한 서비스를 만듭니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: tcp-echo-deployment
labels:
app: tcp-echo
system: example
spec:
replicas: 1
selector:
matchLabels:
app: tcp-echo
template:
metadata:
labels:
app: tcp-echo
system: example
spec:
containers:
- name: tcp-echo-container
image: cjimti/go-echo:latest
imagePullPolicy: IfNotPresent
env:
- name: TCP_PORT
value: "2701"
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: SERVICE_ACCOUNT
valueFrom:
fieldRef:
fieldPath: spec.serviceAccountName
ports:
- name: tcp-echo-port
containerPort: 2701
---
apiVersion: v1
kind: Service
metadata:
name: "tcp-echo-service"
labels:
app: tcp-echo
system: example
spec:
selector:
app: "tcp-echo"
ports:
- protocol: "TCP"
port: 2701
targetPort: 2701
TCP 클라이언트로 접속해 명령어를 입력하면 그대로 되돌려주는 서비스입니다.
그리고 HTTP가 아닌 "특정 포트"를 노출하는 이스티오 게이트웨이 리소스를 만듭니다.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: echo-tcp-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 31400 <---- 노출할 포트
name: tcp-echo
protocol: TCP <---- 기대하는 프로토콜
hosts:
- "*" <---- 모든 호스트apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: tcp-echo-vs-from-gw
spec:
hosts:
- "*"
gateways:
- echo-tcp-gateway <---- 적용 대상 게이트웨이
tcp: <---- tcp
- match:
- port: 31400 <---- 일치해야 하는 포트값
route:
- destination:
host: tcp-echo-service <---- 라우팅 대상
port:
number: 2701
테스트를 해봅니다.
TCP 연결이 잘 되는 것을 볼 수 있습니다.
telnet 192.168.97.2 30125
Trying 192.168.97.2...
Connected to 192.168.97.2.
Escape character is '^]'.
Welcome, you are connected to node kind-control-plane.
Running on Pod tcp-echo-deployment-59bfbbc9df-44hsf.
In namespace istioinaction.
With IP address 10.244.0.18.
Service default.
hello world
hello world
hiiiiiiiii
hiiiiiiiii4.4.2 SNI 통과를 사용한 트래픽 라우팅
- 이스티오 인그레스 게이트웨이에서 트래픽을 종료하지 않고 SNI 호스트네임에 따라 TCP 트래픽을 라우팅하기
- 게이트웨이는 SNI 헤더를 살펴보고 트래픽을 그냥 특정 백엔드로 라우팅
- TLS 커넥션 종료는 백엔드에서 처리
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: sni-passthrough-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 31400 <---- 포트
name: tcp-sni
protocol: TLS <---- 프로토콜 TLS
hosts:
- "simple-sni-1.istioinaction.io" <---- 이 호스트를 포트와 연결
tls:
mode: PASSTHROUGH <---- 통과 트래픽으로 처리tls.mode
- PASSTHROUGH
- Gateway가 TLS 핸드셰이크를 직접 처리하지 않고, 단순히 TCP 레벨에서 트래픽을 백엔드로 넘김
- TLS Termination은 내부 서비스에서 수행
- Gateway는 프록시 역할만 수행
VirtualService도 생성
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: simple-sni-1-vs
spec:
hosts:
- "simple-sni-1.istioinaction.io"
gateways:
- sni-passthrough-gateway
tls:
- match:
- port: 31400
sniHosts:
- simple-sni-1.istioinaction.io
route:
- destination:
host: simple-tls-service-1
port:
number: 80
자체적으로 처리하니까 서비스도 인증서를 들고 있어야 합니다.
아래와 같습니다.
---
apiVersion: v1
kind: Service
metadata:
labels:
app: simple-tls-service-1
name: simple-tls-service-1
spec:
ports:
- name: https
port: 80
protocol: TCP
targetPort: 8080
selector:
app: simple-tls-service-1
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: simple-tls-service-1
name: simple-tls-service-1
spec:
replicas: 1
selector:
matchLabels:
app: simple-tls-service-1
template:
metadata:
labels:
app: simple-tls-service-1
spec:
containers:
- env:
- name: "LISTEN_ADDR"
value: "0.0.0.0:8080"
- name: "SERVER_TYPE"
value: "http"
- name: "TLS_CERT_LOCATION"
value: "/etc/certs/tls.crt"
- name: "TLS_KEY_LOCATION"
value: "/etc/certs/tls.key"
- name: "NAME"
value: "simple-tls-service-1"
- name: "MESSAGE"
value: "Hello from simple-tls-service-1!!!"
- name: KUBERNETES_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
image: nicholasjackson/fake-service:v0.14.1
imagePullPolicy: IfNotPresent
name: simple-tls-service
ports:
- containerPort: 8080
name: http
protocol: TCP
securityContext:
privileged: false
volumeMounts:
- mountPath: /etc/certs
name: tls-certs
volumes:
- name: tls-certs
secret:
secretName: simple-sni-1.istioinaction.io
---
apiVersion: v1
data:
tls.crt: ...
tls.key: ...
kind: Secret
metadata:
name: simple-sni-1.istioinaction.io
namespace: istioinaction
type: kubernetes.io/tls
여기로 호출하면 트래픽은 이스티오 인그레스 게이트웨이로 갔다가, 종료 없이 예제 서비스로 도달합니다.
4.5 운영 팁
4.5.1 게이트웨이 책임 나누기
- 이스티오 게이트웨이는 "단순히 사이드카로 배포되지 않는 엔보이 프록시"에 불과함
- 그러니 인그레스, 이그레스, 공유 게이트웨이 기능, 멀티 클러스터 프록시 로 사용 가능
예) 별도의 네임스페이스 전용 새 게이트웨이 만들기
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-gateway4.5.2 게이트웨이 주입
- 사용자에게 IstioOperator 접근 권한을 줄 수 없으니
- 게이트웨이 주입 Gateway Injection 을 이용해 자체 게이트웨이 만들 수 있게 해주기
아래와 같이 이스티오가 주입을 수행하는 방법을 지시하는 애너테이션을 사용합니다.
주입에 사용하는 템플릿은 gateway 템플릿으로 설정합니다.
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 <---- 미완성 이미지
---
apiVersion: v1
kind: Service
metadata:
name: my-user-gateway-injected
namespace: istioinaction
spec:
type: LoadBalancer
selector:
ingress: my-user-gateway-injected
ports:
- port: 80
name: http
- port: 443
name: https
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: my-user-gateway-injected-sds
namespace: istioinaction
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: my-user-gateway-injected-sds
namespace: istioinaction
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: my-user-gateway-injected-sds
subjects:
- kind: ServiceAccount
name: default4.5.3 인그레스 게이트웨이 액세스 로그
관심있는 워크로드에 대해서만 액세스 로그를 켤 수 있습니다.
아래 텔레메트리 정의는 istio-system 네임스페이스 내 셀렉터에 일치하는 파드에 액세스 로그를 활성화합니다.
apiVersion: telemetry.istio.io/vlalpha1
kind: Telemetry
metadata:
name: ingress-gateway
namespace: istio-system
spec:
selector:
matchLabels:
app: istio-ingressgateway <-- 레이블과 일치하는 파드는 텔레메트리 설정을 가져옴
accessLogging:
- providers:
- name: envoy <-- 액세스 로그를 위한 프로바이더 설정
disabled: false <-- disabled를 false로 설정해 활성화4.5.4 게이트웨이 설정 줄이기
프록시에서 필요이상의 설정은 제거하고 게이트웨이 관련 설정만 포함되도록 하기
아래와 같이 PILOT_FILTER_GATEWAY_CLUSTER_CONFIG 이 플래그를 적용하면
게이트웨이 프록시 설정 내에 있는 클러스터를 해당 게이트웨이에 적용한 VirtualService에서 실제로 참조하는 클러스터로만 좁힙니다.
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반응형
'Kubernetes' 카테고리의 다른 글
| Gateway API, AWS Gateway API Controller (0) | 2025.04.26 |
|---|---|
| Vault로 K8S Secret 관리하기 (0) | 2025.04.10 |
| EKS Blue/Green Migration (0) | 2025.04.05 |
| Kubernetes Scheduling과 Scheduling plugins 파보기 (0) | 2025.03.20 |
| Karpenter + Keda로 특정 시간에 Autoscaling 걸기 (0) | 2025.03.16 |