TL; DR
들어가며
안녕하세요?
이 글에서는 Istio sidecar mode에 대해서 알아보겠습니다.
이 글은 CloudNeta 팀 가시다님의 KANS(Kubernetes Advanced Network Study) 7주차 과제로 작성되었습니다.
Istio의 routing이 어떻게 이루어지는지 예시로 Kubeflow를 사용하겠습니다.
Istio가 뭔가요?
Istio 는 왜 등장했나요?
Istio는 Service Mesh입니다.
Service Mesh란건 마이크로서비스 아키텍쳐에서 각 서비스간의 네트워크 트래픽을 관리합니다.
주로 Cloud native application과 Kubernetes 환경에서 사용됩니다.
마이크로서비스 아키텍처가 점점 널리 도입되면서, 각 서비스가 독립적으로 배포되고 관리되기 때문에 여러 가지 복잡한 문제가 발생했습니다.
특히 네트워크 상에서 서비스 간 통신이 복잡해지고, 다음과 같은 문제를 해결할 필요가 있었다고 합니다.
- 트래픽 관리의 복잡성: 각 서비스가 많아질수록 서비스 간 트래픽을 어떻게 효율적으로 제어할지 고민이 됩니다. 특히 A/B 테스트, 블루-그린 배포, 트래픽 분할과 같은 시나리오에서는 네트워크 통신을 제어할 필요가 있었다고 합니다.
- 보안 강화: 서비스 간 통신에서 보안을 보장하기 위해 트래픽 암호화, 인증, 권한 관리가 필요하나 수동으로 하기는 어렵습니다.
- 서비스 모니터링: 서비스 간의 성능을 모니터링하고 장애를 추적하고 서비스 간에 어떤 문제가 발생했는지 빠르게 파악해야 서비스의 가용성을 유지할 수 있습니다.
이러한 문제들을 해결하기 위해 Istio와 같은 Service Mesh가 등장했다고 합니다.
Istio Architecture
Istio는 Sidecar mode와 Ambient mode가 있습니다.
아래는 Istio Sidecar mode 에 대한 도식과 설명입니다.
Istio Service Mesh는 논리적으로 데이터 플레인과 컨트롤 플레인으로 나뉩니다.
- 데이터 플레인 > Istio-proxy > Envoy
- Istio가 적용되는 서비스에는 sidecar로 배포된 Istio proxy가 들어가게 됩니다.
- Istio Proxy는 Goalng으로 작성되어있고, Envoy를 래핑합니다.
- Envoy는 원래 별도의 제품입니다.
- Istio 가 적용된 모든 마이크로서비스간 통신은 Istio proxy를 통과하여, 메트릭을 수집하거나 트래픽 컨트롤을 할 수 있습니다.
- 각 애플리케이션은 파드 내의 Envoy proxy에 접속하기 위해 localhost 에 TCP 접속을 합니다.
- 물론 pod 내의 모든 컨테이너는 동일한 loopback network interface를 공유하기 때문에 그것이 가능합니다.
- Istiod와 통신해서 트래픽 컨트롤을 위한 전송 룰을 가져옵니다.
- 그리고 Envoy proxy에 전송 룰로서 설정됩니다.
- 컨트롤 플레인 > Istiod
- 트래픽 라우팅을 위해 프록시를 관리하고 구성합니다.
- 상세하게는 Pilot, Galley, Citadel 이라는 3가지의 프로레스가 들어있습니다.
- Pilot: 데이터 플레인과 통신하면서 라우팅 규칙을 동기화합니다.
- 모든 Envoy 사이드카에서 프록시 라우팅 규칙을 관리하며, 서비스 디스커버리와 로드 밸런싱 설정을 제공합니다.
- Galley: 쿠버네티스와 Istio를 연동합니다.
- Istio와 쿠버네티스(TLS 연결 및 파일럿에 필요한 설정)를 연결해 주는 역할을 합니다. 서비스 메시 구성 데이터를 검증하고 변환합니다.
- Citadel: 보안 기능을 담당하며, TLS 인증서 발급 및 관리를 통해 서비스 간 통신의 암호화를 수행합니다.
출처 : Istio / Architecture
출처 : Istio / Security
Envoy의 동작 방식
실제 Istio proxy에서 동작하고 있는건 Envoy이기 때문에 이에 대해 이해할 필요가 있습니다.
Envoy의 routing은 아래와 같은 방법으로 이루어집니다.
High level에서 Envoy의 routing은 Listner와 Cluster로 나뉩니다.
- Listener
- Downstream 요청 처리
- 다운스트림 요청 수명 주기를 관리하고 클라이언트에 대한 응답 경로를 담당합니다. 다운스트림 HTTP/2 코덱이 여기에 있습니다.
- Cluster
- 엔드포인트에 대한 Upstream 연결 선택 및 구성을 담당합니다.
- 클러스터 및 엔드포인트 상태, 로드 밸런싱, 연결 풀링에 대한 지식이 존재하는 곳입니다.
- 두 시스템은 HTTP 라우터 필터로 연결되며, 이 필터는 downstream에서 upsteam으로 HTTP 요청을 전달합니다.
출처 : Life of a Request — envoy 1.33.0-dev-2d06cd documentation
어쨌건간에 흘러가는 자 님의 좀 더 상세하게 표현된 좋은 그림도 있습니다.
출처 : Istio Internals: xDS
Envoy와 Istio 간에 sync가 되는 xDS(그러니까 여러개의 DS) API는 아래와 같은 레이어에서 동작합니다.
- LDS - Listener Discovery Service
- RDS - Route Discovery Service
- CDS - Cluseter Discovery Service
- EDS - Endpoint Discovery Service
출처 : KANS(Kubernetes Advanced .. : 네이버블로그
Istio 환경 구성
istio operator를 통한 설치
Istio operator는 deprecated 됩니다만 일단 이 형태로 설치합니다.
Istio / Istio Operator Install
export ISTIOV=1.23.2
echo "export ISTIOV=1.23.2" >> /etc/profile
curl -s -L https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIOV TARGET_ARCH=x86_64 sh -
tree istio-$ISTIOV -L 2 # sample yaml 포함
cp istio-$ISTIOV/bin/istioctl /usr/local/bin/istioctl
istioctl version --remote=false
istioctl profile dump demo > demo-profile.yaml
istioctl install -f demo-profile.yaml -y
✔ Istio core installed ⛵️
✔ Istiod installed 🧠
✔ Ingress gateways installed 🛬
✔ Installation complete
만약 잘 설치되면
istio-system namespace에서 아래와 같은 구성요소들을 볼 수 있습니다.
istiod, istio-ingressgateway 등의 구성요소들이 보입니다.
istiod로 접근해서 Listening 상태에 있는 모든 TCP 소켓과 해당 소켓이 사용하는 포트 번호와 관련된 프로세스 정보를 보겠습니다.
ss -tnlp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 127.0.0.1:9876 0.0.0.0:* users:(("pilot-discovery",pid=1,fd=8))
LISTEN 0 4096 *:15010 *:* users:(("pilot-discovery",pid=1,fd=11))
LISTEN 0 4096 *:15012 *:* users:(("pilot-discovery",pid=1,fd=10))
LISTEN 0 4096 *:15014 *:* users:(("pilot-discovery",pid=1,fd=9))
LISTEN 0 4096 *:15017 *:* users:(("pilot-discovery",pid=1,fd=12))
LISTEN 0 4096 *:8080 *:* users:(("pilot-discovery",pid=1,fd=3))
pilot-discovery라는 user가 있습니다.
istio-ingressgateway에서도 소켓정보를 보겠습니다.
ss -tnlp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 0.0.0.0:15021 0.0.0.0:* users:(("envoy",pid=15,fd=23))
LISTEN 0 4096 0.0.0.0:15021 0.0.0.0:* users:(("envoy",pid=15,fd=22))
LISTEN 0 4096 0.0.0.0:8080 0.0.0.0:* users:(("envoy",pid=15,fd=35))
LISTEN 0 4096 0.0.0.0:8080 0.0.0.0:* users:(("envoy",pid=15,fd=34))
LISTEN 0 4096 0.0.0.0:15090 0.0.0.0:* users:(("envoy",pid=15,fd=21))
LISTEN 0 4096 0.0.0.0:15090 0.0.0.0:* users:(("envoy",pid=15,fd=20))
LISTEN 0 4096 127.0.0.1:15000 0.0.0.0:* users:(("envoy",pid=15,fd=18))
LISTEN 0 4096 127.0.0.1:15004 0.0.0.0:* users:(("pilot-agent",pid=1,fd=15))
LISTEN 0 4096 *:15020 *:* users:(("pilot-agent",pid=1,fd=3))
여기에는 envoy와 pilot-agent라는 유저가 있습니다.
istio proxy 설정을 네임스페이스에 적용하기
istio를 설치했으니 우리의 애플리케이션 파드에 아무 설정도 할 필요없이 istio-proxy를 통해 Istio Service Mesh에 애플리케이션이 편입되어야 합니다.
어떻게 이게 가능할까요?
바로 Auto Injection with namespace label 을 통해서 해당 네임스페이스에 생성되는 모든 파드들은 istio 사이드카가 자동으로 injection 됩니다.
일단 네임스페이스에 istio-injection=enabled 라는 레이블을 부여합니다.
kubectl label namespace default istio-injection=enabled
그러면 아래와 같은 형태로 각 pod가 생성시 istio-proxy sidecar가 삽입됩니다.
istio injection 확인 테스트
이제 istio injection의 적용 전 후를 비교해보겠습니다.
현재 default namespace에는 label이 없는 상태입니다.
여기에 테스트용 pod를 배포해보겠습니다.
컨테이너는 python 밖에 없습니다.
apiVersion: v1
kind: Pod
metadata:
name: python-test-pod
labels:
app: python-test
spec:
containers:
- name: python-container
image: python:3.11-slim
command: ["python", "-c"]
args:
- |
import time;
while True:
print("Python pod is running...");
time.sleep(99999)
resources:
limits:
memory: "128Mi"
cpu: "500m"
ports:
- containerPort: 8080
배포를 해보면,
네 pod에는 아무것도 없습니다.
이제 네임스페이스에 레이블을 부여해보겠습니다.
kubectl label namespace default istio-injection=enabled
파드를 생성하면 아까와 달리
istio-init, istio-proxy가 생성되는 모습을 볼 수 있습니다.
istio-init의 동작
istio-init은 생성되었다가 작업을 완료하고 사라집니다.
이 친구는 뭘 하고 갔을까요? 로그를 확인해보겠습니다.
2024-10-20T06:56:39.206472Z info Istio iptables environment:
...
2024-10-20T06:56:39.206954Z info Writing following contents to rules file: /tmp/iptables-rules-1729407399206562346.txt2135675131
* nat
-N ISTIO_INBOUND
-N ISTIO_REDIRECT
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-A ISTIO_INBOUND -p tcp --dport 15008 -j RETURN
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A ISTIO_INBOUND -p tcp --dport 15090 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 15021 -j RETURN
-A ISTIO_INBOUND -p tcp --dport 15020 -j RETURN
-A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_OUTPUT -o lo -s 127.0.0.6/32 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d 127.0.0.1/32 -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -o lo -m owner ! --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -o lo ! -d 127.0.0.1/32 -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -o lo -m owner ! --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
COMMIT
2024-10-20T06:56:39.207030Z info Running command: iptables-restore --noflush /tmp/iptables-rules-1729407399206562346.txt2135675131
2024-10-20T06:56:39.225434Z info Writing following contents to rules file: /tmp/ip6tables-rules-1729407399225364986.txt51985113
2024-10-20T06:56:39.225480Z info Running command: ip6tables-restore --noflush /tmp/ip6tables-rules-1729407399225364986.txt51985113
2024-10-20T06:56:39.228161Z info Running command: iptables-save
2024-10-20T06:56:39.231680Z info Command output:
# Generated by iptables-save v1.8.7 on Sun Oct 20 06:56:39 2024
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:ISTIO_INBOUND - [0:0]
:ISTIO_IN_REDIRECT - [0:0]
:ISTIO_OUTPUT - [0:0]
:ISTIO_REDIRECT - [0:0]
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_INBOUND -p tcp -m tcp --dport 15008 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15090 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15021 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15020 -j RETURN
-A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A ISTIO_OUTPUT -s 127.0.0.6/32 -o lo -j RETURN
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -o lo -m owner ! --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -o lo -m owner ! --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001
COMMIT
# Completed on Sun Oct 20 06:56:39 2024
2024-10-20T06:56:39.231984165Z
pod내에 어떤 목적을 위한 iptable을 세팅한 다음에 종료됩니다.
아래는 istio-proxy가 사용하는 포트정보입니다.
출처 : https://istio.io/latest/docs/ops/deployment/application-requirements/
각 포트가 어떤 목적을 가지고 어떤 동작을 하는지
아래 어쨌건간에 흘러가는 자 님의 도식을 보면 상세하게 이해할 수 있습니다.
출처 : https://www.anyflow.net/sw-engineer/istio-internals-by-port
Istio의 Routing
이제 실제 애플리케이션을 통해 Istio의 routing이 어떻게 이루어지는지 예시를 들어서 한번 살펴보겠습니다.
Kubeflow는 기본적으로 istio를 진입점으로 사용하니 이를 도식으로 그려보았습니다.
유저가 Kubeflow 내에 생성한 vscode server로 어떻게 진입하는지를 표현하는 도식입니다.
Istio Gateway와 VirtualService
Istio 의 Gateway는 지정한 인그레스 게이트웨이로부터의 트래픽 인입, 프로토콜 및 포트, HOSTS, Proxy 등을 설정 가능 합니다.
Istio 의 VirtualService 는 인입 처리할 hosts 설정, L7 PATH 별 라우팅, 목적지에 대한 정책 설정이 가능합니다. (envoy route config)
Kubeflow의 Gateway와 VirtualService의 경우, 아래와 같은 도식으로 표현할 수 있습니다.
출처 : https://istio.io/latest/docs/setup/additional-setup/gateway/
예시로 든 Kubeflow VSCode Server 애플리케이션의 경우
VirtualService를 보면,
k get virtualservice
NAME GATEWAYS HOSTS
sample-virtualservice ["kubeflow/kubeflow-gateway"] ["*"]
이와 같이 kubeflow/kubeflow-gateway를 사용하고 있습니다.
좀 더 자세하게 보기 위해 describe를 해보면
Match.Uri로 /notebook/default/sample-service/ 로 접근시 도달하도록
Route.Destination에 pod의 service를 의미하는 host와 port를 명시하고 있는 모습을 볼 수 있습니다.
k describe virtualservice sample-virtualservice
Name: sample-virtualservice
Namespace: default
Labels: <none>
Annotations: <none>
API Version: networking.istio.io/v1beta1
Kind: VirtualService
Metadata:
Creation Timestamp: ...
Owner References:
API Version: kubeflow.org/v1beta1
Block Owner Deletion: true
Controller: true
Kind: Notebook
...
Spec:
Gateways:
kubeflow/kubeflow-gateway
Hosts:
*
Http:
Headers:
Request:
Set:
Match:
Uri:
Prefix: /notebook/default/sample-service/
Rewrite:
Uri: /
Route:
Destination:
Host: sample-service.default.svc.cluster.local
Port:
Number: 80
이제 위에 명시된 Gateway를 살펴보겠습니다.
k -n kubeflow describe gateway kubeflow-gateway
Name: kubeflow-gateway
Namespace: kubeflow
..
API Version: networking.istio.io/v1beta1
Kind: Gateway
Metadata:
..
Spec:
Selector:
Istio: ingressgateway
Servers:
Hosts:
*
Port:
Name: http
Number: 80
Protocol: HTTP
Events: <none>
Selector로 istio ingressgateway를 선택하고 있고,
80번 포트로 오는 HTTP 포로토콜 트래픽을 명시하고 있는 모습을 볼 수 있습니다.
해당 istio-proxy가 떠 있는 pod로 통신하는 istio-proxy의 설정은 잘 반영되고 있을까요?
istioctl proxy-status
NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION
...
sample-service.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-... 1...
CDS, LDS, EDS, RDS 가 잘 sync 되어있다고 나옵니다.
Istio-proxy 좀 더 깊이 들여다보기
istio-proxy network namespace
이제 타겟이 되는 앱의 istio-proxy에 어떤 설정이 되어있는지 좀 더 깊이 파보겠습니다.
먼저 istio-proxy의 network namespace입니다.
lsns -t net
NS TYPE NPROCS PID USER NETNSID NSFS COMMAND
4026535635 net 4 1 istio-proxy unassigned /usr/local/bin/pilot-agent proxy sidecar --domain sample-service.svc.cluster.local
istio-proxy user로 실행되는 pilot-agent라는 프로세스가 특정 네트워크 네임스페이스에서 sidecar 프록시를 설정하고 있는 것을 보여줍니다.
대상 Kubeflow app에서의 network namespace 입니다
서로 sidecar container로 떠 있어서 같은 네트워크 네임스페이스 4026535635를 사용하고 있다는 사실을 알 수 있습니다.
lsns -t net
NS TYPE NPROCS PID USER NETNSID NSFS COMMAND
4026535635 net 23 1 root unassigned /bin/bash /sample.sh
istio-proxy에서 현재 시스템에서 Listening 상태인 모든 TCP 소켓과 이를 사용하는 프로세스를 확인해보겠습니다.
ss -tnlp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 0.0.0.0:15021 0.0.0.0:* users:(("envoy",pid=26,fd=24))
LISTEN 0 4096 0.0.0.0:15021 0.0.0.0:* users:(("envoy",pid=26,fd=23))
LISTEN 0 4096 0.0.0.0:15090 0.0.0.0:* users:(("envoy",pid=26,fd=22))
LISTEN 0 4096 0.0.0.0:15090 0.0.0.0:* users:(("envoy",pid=26,fd=21))
LISTEN 0 511 0.0.0.0:8888 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:15000 0.0.0.0:* users:(("envoy",pid=26,fd=18))
LISTEN 0 4096 0.0.0.0:15001 0.0.0.0:* users:(("envoy",pid=26,fd=35))
LISTEN 0 4096 0.0.0.0:15001 0.0.0.0:* users:(("envoy",pid=26,fd=34))
LISTEN 0 4096 127.0.0.1:15004 0.0.0.0:* users:(("pilot-agent",pid=1,fd=15))
LISTEN 0 4096 0.0.0.0:15006 0.0.0.0:* users:(("envoy",pid=26,fd=37))
LISTEN 0 4096 0.0.0.0:15006 0.0.0.0:* users:(("envoy",pid=26,fd=36))
LISTEN 0 511 127.0.0.1:42593 0.0.0.0:*
LISTEN 0 4096 *:15020 *:* users:(("pilot-agent",pid=1,fd=3))
0.0.0.0:15021 : 15021에서 모든 인터페이스(0.0.0.0)에서 연결을 수신 대기하고 있습니다. 이 포트는 Envoy가 Istio health check를 위해 사용하는 포트입니다.
0.0.0.0:15090 : 15090은 Istio에서 Envoy의 모니터링과 진단 정보를 노출하는 포트입니다. Prometheus 같은 모니터링 도구가 이 포트에서 Envoy의 메트릭 정보를 수집합니다.
127.0.0.1:15000 : 15000은 Envoy의 관리 인터페이스로, 로컬 호스트에서만 접근 가능합니다. 이를 통해 Envoy의 내부 상태를 조회하거나 관리 명령을 실행할 수 있습니다.
0.0.0.0:15001 : 포트 15001은 트래픽 리디렉션을 위한 포트입니다. Istio의 iptables 규칙에 의해, 외부 트래픽이 Envoy로 리디렉션되어 이 포트에서 처리됩니다.
127.0.0.1:15004: pilot-agent가 내부 통신에 사용하는 포트로, Istio 제어 영역(Pilot)과의 상호작용을 위한 설정에 사용됩니다.
0.0.0.0:15006: 내부 클러스터 간의 트래픽을 처리하는 포트입니다. 이 포트에서 들어오는 트래픽은 iptables에 의해 리디렉션된 트래픽으로, Envoy가 이를 처리하여 적절한 서비스로 전달합니다.
*:15020 : Istio의 pilot-agent가 제어 영역(Pilot)과 통신하는 데 사용되는 포트입니다. 이 포트를 통해 Istio가 프록시 구성을 조정하고 유지 관리합니다.
Envoy는 15001, 15006, 15021, 15090를 통해 외부 및 내부 트래픽을 처리하고, 트래픽의 모니터링과 로깅을 담당합니다.
pilot-agent는 envoy와 상호작용하여 프록시의 동작을 제어하고 설정을 전달합니다. 15004, 15020 포트를 통해 Istio 컨트롤 플레인과 통신하며, 프록시의 상태를 유지 관리합니다.
Envoy config
envoy에는 실제로 어떤 설정이 반영되어 있는지 보기 위해서는 istioctl proxy-config 명령을 사용할 수 있습니다.
envoy가 들어있는 샘플 서비스를 대상으로 proxy-config를 확인해보겠습니다.
먼저 route 입니다.
istioctl proxy-config route sample-service
NAME VHOST NAME DOMAINS MATCH VIRTUAL SERVICE
80 istio-ingressgateway.istio-system.svc.cluster.local:80 istio-ingressgateway.istio-system, 10.0.214.253 /*
80 sample-service.svc.cluster.local:80 sample-service, sample-service.default /*
...- NAME은 포트번호 입니다.
- 80은 HTTP 서비스의 포트 번호를 나타냅니다.
- VHOST NAME
- istio-ingressgateway.istio-system.svc.cluster.local:80 는 Istio 인그레스 게이트웨이에서 오는 트래픽을 처리합니다.
- sample-service.svc.cluster.local:80은 sample-service라는 서비스에서 오는 트래픽을 처리합니다.
- DOMAINS 은 이 두 가상 호스트가 처리하는 도메인을 나타냅니다.
- MATCH 는 /* 는 도메인과 일치하는 모든 요청 경로를 처리함을 의미합니다.
Reference
'Kubernetes' 카테고리의 다른 글
| Operator로 배포하는 Gateway API 형태의 Kong API Gateway (4) | 2024.10.09 |
|---|---|
| Iptables와 Kubernetes ClusterIP의 Iptables (0) | 2024.10.08 |
| Kubernetes Kube-proxy의 IPVS 모드 (4) | 2024.10.03 |
| Kubernetes Kube-proxy의 iptables proxy mode, ClusterIP 심화 탐구 (2) | 2024.09.28 |
| Calico CNI의 구조를 파악하고 통신 테스트하기 (0) | 2024.09.17 |