[Istio 스터디] 9주차

Ambient Mesh 개요

Istio의 Ambient Mesh는 2022년 알파 버전으로 시작되어 2024년 GA(General Availability) 버전에 도달한 혁신적인 데이터 플레인 아키텍처입니다. Ambient Mesh는 한국어로 '주변 모드'로 번역되며, 기존 사이드카 프록시 없이 동작하는 Istio 데이터 플레인 모드를 의미합니다.

사이드카 모드의 한계점:

애플리케이션 간섭: 사이드카 설치나 업그레이드 시 애플리케이션 파드 재시작 필요
리소스 활용도 저하: 각 파드마다 사이드카 컨테이너의 CPU/메모리 리소스 소비
트래픽 차단: HTTP 구현에 맞지 않는 애플리케이션 중단 가능성
컴퓨팅 비용 증가: 사이드카당 개별 리소스 할당으로 인한 비효율

Ambient Mesh는 기존 사이드카 모델의 한계를 극복하기 위해 설계된 혁신적인 아키텍처로, 애플리케이션과 데이터 플레인의 완전한 분리를 통해 운영 효율성, 보안성, 리소스 활용도를 크게 개선합니다. 특히 L4와 L7 기능의 계층 분리를 통해 필요에 따른 선택적 기능 활용이 가능하여, 다양한 운영 환경에서 최적화된 서비스 메시 솔루션을 제공합니다.

Ambient Mesh 아키텍처

2계층 아키텍처 설계

Ambient Mesh는 기존 사이드카의 단일 구성 요소 방식을 2계층으로 분리합니다:

1. Secure Overlay Layer (L4 처리)

ztunnel: Zero Trust Tunnel의 약자로, 노드당 하나씩 배포
TCP 라우팅, mTLS 터널링, 간단한 인가 정책 처리
L4 수준의 메트릭과 로깅 제공
Rust 언어로 구현되어 고성능 및 메모리 효율성 확보

2. L7 Processing Layer (L7 처리)

Waypoint Proxy: Envoy 기반의 L7 전용 프록시
HTTP 헤더 검사가 필요한 고급 정책 처리
네임스페이스 단위 또는 서비스 계정별 배포 가능
필요에 따라 동적으로 활성화/비활성화 가능

네트워크 통신 흐름

HBONE (HTTP-based Overlay Network Encapsulation) 프로토콜:

HTTP CONNECT 메서드를 사용한 터널링
TCP 15008 포트를 통한 암호화된 통신
IP, TCP, TLS 위에 터널된 클라이언트 스트림 전송
다중 TCP 스트림의 동시 처리 지원

통신 패턴:

L4 통신: 애플리케이션 → ztunnel → 대상 ztunnel → 애플리케이션
L7 통신: 애플리케이션 → ztunnel → waypoint proxy → ztunnel → 애플리케이션

CNI 플러그인 아키텍처 변화

초기 모델의 문제점

초기 Ambient Mesh는 iptables 기반 트래픽 리다이렉션을 사용했으나, 다음과 같은 문제가 발생했습니다:

기존 CNI와의 충돌
Kubernetes 네트워크 정책과의 호환성 문제
NET_ADMIN, NET_RAW 권한 요구사항

개선된 소켓 기반 모델

핵심 기술: 리눅스 소켓 API의 Cross-Namespace Socket Ownership

하나의 네트워크 네임스페이스에서 실행되는 프로세스가 다른 네트워크 네임스페이스의 리스닝 소켓을 생성/소유 가능
iptables 조작 없이 트래픽 리다이렉션 구현
CNI 충돌 문제 완전 해결

동작 원리:

Istio CNI 데몬셋이 애플리케이션 파드 생성 감지
ztunnel이 애플리케이션 파드의 소켓을 Cross-Namespace로 소유
애플리케이션 트래픽이 자동으로 ztunnel로 리다이렉션
암호화/복호화 처리 후 목적지로 전달

성능 및 리소스 최적화

구성 정보 최적화

기존 사이드카 모드:

각 사이드카가 모든 엔드포인트 정보 수신 (약 350줄의 XDS 설정)
전체 메시 구성 변경 시 모든 사이드카 업데이트 필요

Ambient Mesh:

ztunnel: L4 정보만 수신 (약 20줄 미만의 설정)
Waypoint Proxy: 목적지 기반 최적화로 25% 수준의 구성 정보만 필요
자동 Export-to 최적화 효과

리소스 사용량 감소

공유 리소스 모델:

노드당 하나의 ztunnel로 모든 L4 처리
필요 시에만 waypoint proxy 동적 배포
기존 대비 50-70% 리소스 사용량 감소 (일부 케이스에서 90% 이상)

보안 강화

보안 경계 분리

기존 사이드카 모드의 취약점:

애플리케이션 파드 침해 시 사이드카 프록시도 동시 침해
동일한 보안 경계 내 위치

Ambient Mesh의 보안 개선:

애플리케이션과 데이터 플레인의 완전한 분리
애플리케이션 침해 시에도 ztunnel/waypoint proxy 독립성 유지
L4만 사용하는 경우 L7 취약점으로부터 완전 격리

최소 권한 원칙

ztunnel 특징:

L4 기능만 처리하여 공격 표면 최소화
L7 취약점의 영향 받지 않음
개별 애플리케이션별 인증서 관리

기술적 구현 세부사항

포트 구성

ztunnel 주요 포트:

15008: HBONE 암호화 트래픽
15006: 플레인텍스트 트래픽 (inbound)
15001: 아웃바운드 트래픽 캡처

모니터링 및 관찰가능성

제공되는 메트릭:

L4 수준의 TCP 연결 정보
mTLS 연결 상태
트래픽 볼륨 및 오류율
Prometheus 메트릭 통합

설정 확인 방법:

# ztunnel 설정 확인
istioctl proxy-config workload <pod-name>

# 프로토콜 확인 (HBONE = Ambient 모드 활성화)
istioctl proxy-config cluster <ztunnel-pod>

Ambient Mesh는 Istio 서비스 메시의 패러다임을 근본적으로 변화시키는 혁신적인 아키텍처로, 기존 사이드카 모드의 한계를 해결하면서도 동일한 보안 및 관찰가능성 기능을 제공합니다. 특히 대규모 환경에서의 리소스 효율성과 운영 복잡성 감소에 큰 장점을 제공합니다.

환경 구성 및 설치 과정

Ambient Mesh를 실습하기 위해 Kubernetes 1.32 버전을 사용하고, 워커노드 두 대를 추가로 설치합니다. 노드당 파드들이 배포되어 노드 간 통신을 확인해야 하므로 여러 워커노드가 필요합니다. 배포 후에는 컨트롤 플레인 노드 1개와 워커노드 2개로 구성된 환경이 준비됩니다. 테스트 PC도 하나 설치하여 외부에서의 접속을 테스트할 수 있습니다.

로드 밸런서 테스트를 위해 MetalLB를 설치합니다. Istio는 현재 1.26.1 버전까지 출시되었으며, Kubernetes 1.33 버전에 대응하는 마지막 패치 업데이트가 적용되어 있습니다. 본 실습에서는 Istio 1.26.0 버전을 사용합니다.

istioctl install --set profile=ambient

Istio 설치 시 istioctl 명령체계가 약간 변경되었습니다. 공식 문서의 메뉴를 보면 사이드카 모드와 Ambient 모드로 나뉘어 있으며, Ambient 모드 설치 방법은 Helm과 istioctl 두 가지만 제공됩니다. 공식적으로는 Helm을 통한 설치를 권장하고 있으며, 이는 ArgoCD와 같은 도구로 관리하기 편리하기 때문입니다.

Gateway API CRD도 설치합니다:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml

주요 컴포넌트 분석

CNI 노드 데몬셋과 ztunnel 데몬셋

설치 후 istio-system 네임스페이스에 두 개의 데몬셋이 생성됩니다:

CNI 노드 데몬셋:
- 컨테이너 이름은 install-cni
- 호스트 경로의 마운트를 통해 노드에 직접 접근
- /opt/cni/bin에 Istio CNI 플러그인을 배치
- 네트워크 네임스페이스와 관련된 정보에 접근
ztunnel 데몬셋:
- 노드마다 하나씩 배포
- 컨테이너 이름은 istio-proxy
- distroless 이미지를 사용하여 보안 강화
- 메모리 요청은 512Mi로 설정
- /var/run/ztunnel 볼륨을 마운트하여 소켓 통신

ztunnel의 구성 설정은 매우 간결합니다. 기존 Envoy 사이드카의 설정과 비교하면 크게 간소화되었으며, 일부 워크로드의 설정값이 30줄도 안 되는 정도로 간결합니다.

Gateway API와 Istio API의 차이

Istio와 Gateway API 모두 Gateway라는 리소스를 사용하지만 서로 다른 API 그룹에 속합니다:

Istio Gateway: networking.istio.io
Gateway API: gateway.networking.k8s.io

두 API는 용도는 유사하지만 서로 다른 방식으로 동작하므로 구분하여 사용해야 합니다.

Ambient Mesh 동작 원리

Ambient CNI 에이전트는 포드 생성을 알리는 UDS 이벤트를 수신하여 상호작용을 시작합니다.
Ambient Watch Server는 필요에 따라 포드 내의 iptables를 수정하여 트래픽을 ztunnel로 리디렉션합니다.
ztunnel은 Kubernetes 클러스터 내에서 연결을 설정하고 네트워크 트래픽 리디렉션을 처리합니다.

샘플 애플리케이션 배포

Bookinfo 샘플 애플리케이션을 배포하고 외부 접근을 위한 Gateway와 HTTPRoute를 설정합니다:

# Bookinfo 애플리케이션 배포
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

# Gateway와 HTTPRoute 설정
kubectl apply -f gateway-httproute.yaml

초기 상태에서는 모든 워크로드가 평문 통신을 하고 있으며, Kiali에서도 보안 표시가 없는 것을 확인할 수 있습니다.

Ambient Mesh 활성화

Ambient Mesh를 활성화하기 위해 네임스페이스나 개별 파드에 라벨을 추가합니다:

# 네임스페이스에 Ambient Mesh 활성화
kubectl label namespace default istio.io/dataplane-mode=ambient

# 특정 파드에만 적용할 경우
kubectl label pod <pod-name> istio.io/dataplane-mode=ambient

# 제외하고 싶은 파드가 있을 경우
kubectl label pod <pod-name> istio.io/dataplane-mode=none

라벨 적용 후 애플리케이션 파드의 재시작 없이 즉시 mTLS 보안 통신이 적용됩니다. 또한 사이드카 컨테이너가 추가되지 않고도 이런 기능이 제공됩니다. Kiali 대시보드에서 자물쇠 아이콘이 표시되며, 워크로드 프로토콜이 TCP에서 HBONE(HTTP-Based Overlay Network Encapsulation)으로 변경된 것을 확인할 수 있습니다.

트래픽 리다이렉션 메커니즘

ztunnel의 설정을 확인하면 워크로드의 프로토콜이 HBONE으로 표시되어 있습니다. 이는 해당 워크로드가 Ambient Mesh에 참여하여 ztunnel을 통한 통신을 수행하고 있음을 의미합니다.

애플리케이션 파드 내부를 확인해보면 iptables 규칙이 사이드카 모드에 비해 극히 간소화되어 있습니다:

# 파드 내 iptables 확인
kubectl exec -it <pod-name> -- iptables -t nat -L

주요 포트 설명:

15001: 아웃바운드 트래픽을 ztunnel로 리다이렉션
15008: HBONE 터널 통신용
15006: 평문 통신용

파드 내부에서 UNIX 도메인 소켓을 확인하면, ztunnel이 파드의 소켓을 소유하고 있는 것을 볼 수 있습니다. 이는 리눅스의 크로스 네트워크 네임스페이스 소켓 소유 기능을 활용한 것으로, 서로 다른 네트워크 네임스페이스에 있는 프로세스가 다른 네임스페이스의 소켓을 생성하고 제어할 수 있게 합니다.

트래픽 최적화 기법

Ambient Mesh는 여러 최적화 기법을 적용하여 성능을 향상시킵니다:

패킷 캐싱 효과:
- 첫 번째 패킷은 전체 분석 과정을 거침
- 이후 패킷들은 이미 확립된 경로를 재사용
- 특정 태그(0x111)로 표시하여 중복 처리 방지
루프 방지 메커니즘:
- 특정 태그(0x039)로 패킷 표시
- iptables의 MARK를 사용하여 이미 처리된 패킷 식별
- 루프를 감지하여 무한 리다이렉션 방지
소스 IP 보존:
- IP 투명성(IP transparent) 옵션 활성화
- 원본 클라이언트 IP를 목적지 서버까지 보존

Waypoint Proxy 소개

L7 레벨의 고급 기능이 필요할 경우 Waypoint Proxy를 활용합니다. 이는 Envoy 기반으로 동작하며, 애플리케이션과 독립적인 생명주기를 가집니다.

트래픽 흐름:

소스 파드에서 트래픽 발생
ztunnel로 리다이렉션
L7 기능이 필요한 경우 Waypoint Proxy로 라우팅
Waypoint Proxy에서 L7 정책 적용
다시 ztunnel을 통해 목적지 파드로 전달

Waypoint Proxy는 필요에 따라 동적으로 배포되며, 네임스페이스 단위 또는 서비스 계정별로 구성할 수 있습니다.

모니터링 및 관측성

Ambient Mesh는 L4 레벨의 텔레메트리를 기본으로 제공합니다. ztunnel 파드에서 Prometheus 메트릭을 확인할 수 있으며, 그라파나 대시보드의 "ztunnel Dashboard"에서 다양한 지표를 모니터링할 수 있습니다.

주요 메트릭:

TCP 연결 상태
전송/수신 바이트
연결 보안 정책 (mtls 등)

Ambient Mesh와 사이드카 모드 비교

Ambient Mesh의 장단점을 정리하면:

장점:

리소스 사용량 절감
애플리케이션 영향 없이 보안 정책 적용
운영 간소화
파드 재시작 없이 정책 변경 가능

제약사항:

세분화된 L7 필터 적용이 다소 어려움
일부 고급 기능의 성숙도 부족
Wasm 플러그인 직접 적용 제한

권장 사용 시나리오:

이미 다양한 고급 기능을 사용 중이라면 사이드카 모드 유지
자원 절약과 운영 간소화가 우선이거나 주로 L4 처리만 필요하다면 Ambient 모드 사용
혼합 모드는 경계와 정책의 이원화로 복잡성이 증가하므로 권장하지 않음

Istio CLI 도구를 통한 상세 정보 확인

Istio의 관리와 모니터링을 위해서는 istioctl 명령어를 사용하여 다양한 상세 정보를 확인할 수 있습니다. 특히 Ambient mesh 모드에서 동작하는 Ztunnel에 대한 정보를 확인하는 것이 중요합니다.

Istioctl Proxy-Status 명령어

먼저 istioctl proxy-status 명령어를 통해 프록시의 전반적인 상태를 확인할 수 있습니다. 이때 Ztunnel은 무시되는 것을 확인할 수 있는데, bookinfo gateway의 Istio는 Envoy가 포함된 구성요소입니다. Envoy는 Istio 서비스 메시에서 데이터 플레인의 핵심 구성요소로, CDS(Cluster Discovery Service), LDS(Listener Discovery Service), EDS(Endpoint Discovery Service), RDS(Route Discovery Service) 등의 xDS API를 통해 동적으로 설정을 받아 트래픽을 처리합니다.

Bookinfo Gateway의 Envoy 정보 확인

Kiali에서 확인할 수 있는 bookinfo gateway는 HTTP 트래픽을 처리하는 Envoy 프록시로 구성되어 있습니다. istioctl proxy-config 명령어를 사용하여 이 Envoy 프록시의 listener, route, cluster, endpoint 등의 상세 정보를 확인할 수 있습니다.

Listener: 트래픽을 수신하는 포트와 프로토콜 정보
Route: 요청을 어떤 클러스터로 라우팅할지 결정하는 규칙
Cluster: 백엔드 서비스들의 그룹
Endpoint: 실제 서비스 인스턴스들의 주소와 포트

Secret 및 인증서 정보

Envoy 프록시에는 mTLS 통신을 위한 인증서 정보도 포함되어 있습니다. 이는 포털 스트랩(Portal Strap) 방식으로 istio-proxy에 주입되며, istioctl proxy-config secret 명령어를 통해 확인할 수 있습니다.

Ztunnel Configuration 명령어

기본 사용법

istioctl ztunnel-config 명령어는 Ztunnel의 설정 정보를 항목별로 확인할 수 있는 강력한 도구입니다. 이 명령어는 다음과 같은 그룹 커맨드들을 제공합니다:

workload: 워크로드 정보
service: 서비스 정보
policy: 정책 정보
log: 로그 설정
connection: 연결 정보
certificate: 인증서 정보
all: 전체 정보

서비스 정보 확인

서비스 정보를 확인할 때는 istioctl ztunnel-config service 명령어를 사용합니다. 네임스페이스 필터를 적용하여 특정 네임스페이스의 서비스만 확인할 수 있습니다:

istioctl ztunnel-config service --namespace default

각 서비스에는 다음과 같은 정보가 포함됩니다:

VIP (Virtual IP): 서비스의 가상 IP 주소
Waypoint: 현재 설정된 waypoint 정보 (없는 경우 표시되지 않음)
Endpoints: 서비스에 연결된 파드들의 정보

Reviews 서비스의 경우 3개의 파드가 있어 각각 version-v1, version-v2, version-v3 파드의 정보가 표시됩니다. JSON 형식으로 더 상세한 정보를 확인하려면 -o json 옵션을 사용할 수 있습니다.

워크로드 정보 확인

워크로드 정보는 istioctl ztunnel-config workload 명령어로 확인할 수 있으며, 네임스페이스 필터와 노드 필터를 모두 적용할 수 있습니다:

istioctl ztunnel-config workload --namespace default --node worker-node-1

인증서 정보 확인

istioctl ztunnel-config certificate 명령어를 통해 인증서 정보를 확인할 수 있습니다. 중요한 점은 이 인증서들이 애플리케이션 파드에 있는 것이 아니라 Ztunnel 파드가 보유하고 있다는 것입니다. 각 노드마다 하나씩 존재하는 Ztunnel 파드가 해당 노드에서 Ambient mesh로 동작하는 워크로드들의 인증서를 관리합니다.

OpenSSL을 사용하여 인증서의 상세 정보를 확인할 수도 있습니다:

openssl x509 -in certificate.pem -text -noout

연결 정보 확인

현재 Ztunnel에 연결된 커넥션 정보는 istioctl ztunnel-config connection 명령어로 확인할 수 있습니다. 노드별로 필터링이 가능하며, -aw 옵션을 사용하면 IP 주소와 포트 정보로 출력됩니다.

Ambient Mesh에서의 iptables 설정

iptables 규칙 구조

Ambient mesh 모드에서는 Istio CNI DaemonSet이 각 노드에 iptables 규칙을 주입합니다. 이 규칙들은 트래픽을 Ztunnel로 리다이렉션하기 위해 필요합니다.

주요 iptables 체인들:

raw: DNS 관련 UDP 53번 포트 트래픽의 연결 추적을 위한 마킹
mangle: 특정 마크가 붙은 트래픽을 식별하여 후속 NAT 처리를 건너뛰도록 하는 규칙
nat: 실제 트래픽 리다이렉션을 수행하는 규칙들

주요 리다이렉션 규칙

메타데이터 서비스 예외: 169.254.169.254 주소는 AWS EC2 메타데이터 서비스 주소로, 이는 Istio OUTPUT 체인에서 예외 처리됩니다.
DNS 리다이렉션: DNS 요청(UDP/TCP 53번 포트)은 15053번 포트로 리다이렉션됩니다.
일반 트래픽 리다이렉션: 마크가 붙지 않은 나머지 트래픽들은 15001번 포트로 리다이렉션됩니다.
인바운드 트래픽: 외부에서 들어오는 TCP 트래픽은 15006번 포트로 리다이렉션됩니다.

소켓 정보 확인

애플리케이션 파드 내부에서는 다음과 같은 포트들이 리스닝 중인 것을 확인할 수 있습니다:

15008: 애플리케이션 트래픽 처리 포트
15006: 인바운드 트래픽 처리 포트

mTLS 통신 확인 방법

프로토콜 수준에서의 확인

mTLS(Mutual TLS) 통신이 활성화되어 있는지 확인하는 방법은 여러 가지가 있습니다:

프로토콜 확인: 연결이 HTTP/2(h2) 프로토콜을 사용하고 있다면 mTLS 통신 중임을 의미합니다.
일반 TCP: 단순 TCP 연결은 일반적으로 암호화되지 않은 통신입니다.

Prometheus 메트릭을 통한 확인

Prometheus에서 제공하는 메트릭을 통해 연결의 보안 상태를 확인할 수 있습니다:

connection_security_policy: "unknown"은 일반 통신, "mutual_tls"는 mTLS 통신을 의미합니다.

로그를 통한 확인

애플리케이션 로그에서 다음 필드들을 확인할 수 있습니다:

source_principal: 요청을 보낸 주체의 신원
destination_principal: 요청을 받는 주체의 신원
SPIFFE ID: mTLS 통신에서 사용되는 신원 식별자

SPIFFE(Secure Production Identity Framework For Everyone)는 워크로드의 신원을 안전하게 식별하기 위한 표준으로, Istio에서 mTLS 인증서 생성의 기반이 됩니다.

Kiali에서의 확인

Kiali 대시보드에서는 다음과 같은 방법으로 mTLS 상태를 확인할 수 있습니다:

자물쇠 아이콘: 연결에 자물쇠 표시가 있으면 mTLS가 활성화됨
mTLS enabled: 서비스 세부 정보에서 mTLS 활성화 상태 확인
Principal: SPIFFE 기반의 principal 정보 표시

패킷 캡처를 통한 확인

tcpdump나 tshark를 사용하여 실제 네트워크 트래픽을 캡처해보면 평문이 아닌 암호화된 데이터만 확인할 수 있습니다:

tcpdump -i any port 15008

이때 HTTP 요청의 평문 내용은 보이지 않고 암호화된 데이터만 확인됩니다.

L4 보안 정책 적용

Layer 4 보안 정책의 특징

Istio의 Ambient mesh 모드에서는 Ztunnel을 통해 Layer 4 수준의 보안 정책을 적용할 수 있습니다. 이는 공식 문서의 "Use Layer 4 security policies" 섹션에서 자세히 다루어집니다.

L4 정책의 주요 특징:

네트워크 레벨 제어: IP 주소, 포트, 프로토콜 기반의 접근 제어
서비스 계정 기반 인증: Kubernetes 서비스 계정을 통한 신원 기반 정책
L7 조건 불가: HTTP 헤더, 경로 등 애플리케이션 레벨 조건은 사용 불가

정책 예제 구현

다음은 프로덕션 페이지에 대한 접근을 특정 서비스 계정으로만 제한하는 정책 예제입니다:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: productpage-policy
  namespace: default
spec:
  selector:
    matchLabels:
      app: productpage
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/sleep"]

이 정책의 동작 방식:

대상 선택: productpage 애플리케이션을 대상으로 함
액션: ALLOW (허용)
규칙: sleep 서비스 계정에서만 접근 허용

정책 적용 확인

정책 적용 후 다음과 같은 변화를 확인할 수 있습니다:

외부 접근 차단: Istio Gateway를 통한 외부 접근이 차단됩니다 (bookinfo-gateway의 서비스 계정이 다르기 때문).
내부 접근 허용: sleep 파드에서의 접근은 계속 허용됩니다.
RBAC 업데이트: Ztunnel 로그에서 RBAC 정책 업데이트 메시지를 확인할 수 있습니다.

정책 수정 및 복구

정책에 추가 principal을 포함시켜 외부 접근을 복구할 수 있습니다:

rules:
- from:
  - source:
      principals: 
        - "cluster.local/ns/default/sa/sleep"
        - "cluster.local/ns/istio-system/sa/bookinfo-gateway"

Waypoint Proxy 설정

Waypoint Proxy의 목적

Waypoint Proxy는 Layer 7 수준의 트래픽 처리가 필요할 때 사용되는 Envoy 기반의 프록시입니다. 다음과 같은 기능들을 위해 필요합니다:

Traffic Management: 고급 라우팅, 로드 밸런싱, 서킷 브레이킹
Advanced Security: HTTP 헤더 기반 보안 정책, JWT 검증
L7 Observability: HTTP 메트릭, 분산 추적

Waypoint 설정 과정

공식 문서의 "Configure waypoint proxies" 가이드를 따라 설정할 수 있습니다:

서비스 계정 확인: 대상 서비스의 서비스 계정 이름을 확인합니다.
Waypoint 구성 생성: istioctl waypoint generate 명령어를 사용하여 YAML 템플릿을 생성합니다:

istioctl waypoint generate --for service --namespace default

구성 적용: 생성된 YAML을 적용합니다:

istioctl waypoint generate --for service --namespace default | kubectl apply -f -

Waypoint 리소스 확인

적용 후 다음 리소스들이 생성됩니다:

Gateway 리소스: 15008번 포트 리스너가 포함된 Gateway
Waypoint Pod: Envoy와 pilot-agent가 포함된 별도 파드
서비스: Waypoint 트래픽을 처리하기 위한 서비스

Waypoint 상태 확인

istioctl waypoint 명령어들을 통해 상태를 확인할 수 있습니다:

istioctl waypoint list
istioctl waypoint status
istioctl proxy-status  # waypoint가 SYNCED 상태로 표시됨

Waypoint 파드는 기본적으로 sidecar와 동일한 구조를 가지며, Envoy 프록시의 모든 기능을 사용할 수 있습니다.

Kmesh 소개

Kmesh의 특징

Kmesh는 중국에서 개발된 프로젝트로, Istio의 Ztunnel과 유사한 기능을 eBPF(Extended Berkeley Packet Filter)를 통해 구현합니다. 주요 특징은 다음과 같습니다:

eBPF 기반: 커널 수준에서 트래픽 처리를 수행하여 성능 최적화
리소스 효율성: 유저 스페이스 처리에 비해 CPU와 메모리 사용량 감소
투명한 레이어: Ambient mesh와 유사한 투명한 서비스 메시 구현

eBPF vs 유저스페이스 처리

전통적인 Ztunnel은 유저 스페이스에서 동작하는 반면, Kmesh는 다음과 같은 장점을 제공합니다:

커널 레벨 처리: 패킷이 커널과 유저 스페이스 간을 오가는 오버헤드 감소
XDP 지원: eXpress Data Path를 통한 하드웨어 수준의 트래픽 처리
성능 향상: 특히 고성능 네트워킹 환경에서 더 나은 성능

'Work > 개발 노트' 카테고리의 다른 글

[Istio 스터디] 8주차 - VM Support & Istio Traffic Flow (0)	2025.05.31
[istio 스터디] 6주차 - 운영 및 트러블슈팅 (0)	2025.05.17
[istio 스터디] 5주차 - 마이크로서비스 통신 보안 (0)	2025.05.11
[istio study] 4주차 - Observability (0)	2025.05.03
[Istio 스터디] 2주차 - Envoy, Istio Gateway (0)	2025.04.19

[Istio 스터디] 9주차 - Ambient Mesh