Istio 앰비언트 모드를 통해 제공되는 OpenShift Service Mesh 3.2

Red Hat OpenShift Service Mesh 3.2의 일반 출시(GA)를 발표하게 되어 기쁩니다. 이번 릴리스에서는 Istio의 앰비언트 모드가 일반 공급됩니다. 사이드카 없이 서비스 메시를 배포하는 새로운 방식으로, 서비스 메시 사용에 따른 리소스 비용을 크게 줄일 수 있습니다. 이를 통해 워크로드 ID를 기반으로 하는 경량 Pod-to-Pod mTLS 암호화 및 권한 부여 정책을 통해 제로 트러스트 네트워킹을 위한 오버헤드가 낮은 솔루션을 제공하고 필요에 따라 고급 기능을 추가할 수 있습니다.

Istio, Envoy 및 Kiali 프로젝트를 기반으로 하는 이번 릴리스에서는 Istio 버전을 1.27로, Kiali 버전을 2.17로 업데이트하며 Red Hat OpenShift 4.18 이상에서 지원됩니다. 

OpenShift Service Mesh 3.2로 업그레이드

OpenShift Service Mesh 2.6 이하 릴리스를 실행 중인 경우 OpenShift Service Mesh 3.0, 3.1, 3.2로 업그레이드해야 합니다. OpenShift Service Mesh 2.6은 2026년 6월 30일에 지원 종료(EOL)에 도달하므로(기존 2026년 3월 12일에서 최근 연장됨), OpenShift Service Mesh 3.0으로 신속히 마이그레이션할 것을 권장합니다. 자세한 마이그레이션 가이드는 OpenShift Service Mesh 2.6과 3.0의 차이점 분석을 포함하여 OpenShift Service Mesh 3.0 설명서에 제공되어 있습니다. 이 블로그 게시물에서는 OpenShift Service Mesh 2.6과 3.0 간에 마이그레이션하기 위해 Kiali 콘솔을 사용하는 방법을 설명합니다.

전체적으로 구성된 메트릭과 Kiali 콘솔을 통해 작동하는 OpenShift Service Mesh 3의 예는 솔루션 패턴을 참조하십시오.

사이드카 없는 서비스 메시: Istio의 앰비언트 모드

이번 릴리스에서는 Istio의 앰비언트 모드에 대한 일반적인 가용성 지원이 OpenShift Service Mesh에 제공됩니다. Istio의 앰비언트 모드는 사이드카 프록시 없이도 워크로드에서 서비스 메시 기능을 활성화하는 중요한 새로운 기능입니다.

'사이드카 모드'로 알려진 Istio의 기존 데이터 평면 아키텍처에서는 각 애플리케이션 Pod에 서비스 메시 기능을 활성화하기 위한 사이드카 프록시 컨테이너가 필요합니다. 이로 인해 아키텍처가 단순해지지만 모든 애플리케이션 워크로드 컨테이너에 프록시 컨테이너가 필요하므로 서비스 메시를 실행할 때 추가 오버헤드가 발생합니다. 또한 사이드카 프록시를 애플리케이션 및 서비스 메시의 수명 주기의 일부로 추가하고 업데이트해야 하므로 서비스 메시 도입이 복잡해집니다. 즉, 서비스 메시를 도입하고 업데이트할 때 애플리케이션을 다시 시작해야 합니다.

Istio의 앰비언트 모드 아키텍처에서는 데이터 평면이 서로 다른 역할을 수행하는 ztunnel과 waypoint라는 두 가지 수준의 프록시로 분할됩니다. 

Ztunnel 프록시

Ztunnel은 계층 4에서 트래픽을 가로채는 경량 공유 노드 수준 프록시로, mTLS(상호 전송 계층 보안) 암호화, 인증, 텔레메트리 및 애플리케이션 ID를 기반으로 하는 간단한 L4 권한 부여 정책 형태로 보안('Z'는 '제로 트러스트'를 의미)을 제공합니다. 또한 모든 서비스 메시 메트릭과 마찬가지로 Kiali 콘솔을 사용하여 볼 수 있는 기본 레이어 4(예: TCP) 수준 로그 및 메트릭을 제공합니다.

ztunnel은 이러한 특정 목적을 위해 Rust로 작성되었으므로 최소한의 추가 오버헤드로 고성능 프록시를 달성할 수 있습니다. 

ztunnel은 Kubernetes DaemonSet인 노드 수준 프록시로 실행되지만 각 Pod의 네트워크 네임스페이스 내에서 트래픽 리디렉션을 구현합니다. 즉, 네트워크 격리 관점에서 트래픽 리디렉션 및 암호화는 실제로 Pod 내에서 발생하므로 Pod 간 트래픽 격리 및 암호화가 유지 관리됩니다. 이 내용은 Istio CNI 에이전트가 이 트래픽 리디렉션을 구성하는 방법과 함께 ZTunnel 트래픽 리디렉션에 대한 Istio 자료에서 자세히 설명합니다.

Istio의 앰비언트 모드를 사용하면 ztunnel에서 제공하는 기능만 필요한 경우 ztunnel만 실행하면 되므로 매우 리소스 효율적인 서비스 메시를 구축할 수 있습니다.

Waypoint 프록시

사용자가 HTTP 또는 gRPC 관련 텔레메트리, 트래픽 관리 및 권한 부여 정책과 같은 애플리케이션 수준(레이어 7) 서비스 메시 기능을 원하는 경우 '웨이포인트'라는 추가 프록시를 도입할 수 있습니다. 일반적으로 밀접하게 관련된 애플리케이션 워크로드 그룹과 함께 네임스페이스별로 배포됩니다. 

ztunnel에서 이미 제공한 기능 외에도 waypoint 프록시는 다음과 같은 기능을 추가합니다.

• HTTP 라우팅 및 로드 밸런싱, 재시도, 시간 초과, 회로 차단, 속도 제한 및 오류 주입
• 요청 유형 또는 HTTP 헤더와 같은 L7 기본 요소를 기반으로 하는 다양한 권한 부여 정책
• HTTP 메트릭, 액세스 로깅 및 추적

Waypoint 프록시는 독립 실행형 Envoy 프록시로 인그레스 게이트웨이와 유사하게 관리되며, 서비스 메시 제어 평면 또는 노드별 ztunnel이 아닌 애플리케이션 워크로드와 함께 수명 주기가 관리될 가능성이 높습니다.

Istio의 앰비언트 모드가 적합한가요? 장점과 단점은 무엇인가요? 

Istio의 앰비언트 모드는 Istio 커뮤니티에서 계속 발전하고 있으며, 현재 사이드카 모드와 마이그레이션하거나 결합할 때 몇 가지 제한 사항이 있으므로 새로운 서비스 메시 설치에 이상적입니다(자세한 내용은 아래 참조).  

지원되는 Kubernetes Gateway API CRD(사용자 정의 리소스 정의)에는 OpenShift 4.19 이상을 사용해야 합니다. 이는 인그레스 게이트웨이를 구성하는 데 권장되며 앰비언트 waypoint 프록시를 구성하는 데 필요합니다. OpenShift Service Mesh 4.18 및 이전 릴리스는 이러한 CRD를 포함하거나 지원하지 않습니다.

앰비언트 모드 채택의 이점과 절충안은 다음과 같습니다.

리소스 비용 대폭 절감

사이드카가 더 이상 필요하지 않으므로 Istio의 앰비언트 모드는 mTLS 암호화와 같은 서비스 메시 기능을 채택하는 데 필요한 메모리 및 CPU 모두에서 리소스 사용 공간을 크게 줄입니다. 사이드카 모드에 비해 메모리 사용량이 90% 이상, CPU 사용량이 50% 이상 감소했습니다. ztunnel만 사용하는 경우 리소스 사용량이 훨씬 더 크게 줄어듭니다. 

경량 제로 트러스트 네트워킹

Istio 앰비언트 모드의 가장 큰 동기는 경량 Pod 간 mTLS 암호화라고 생각합니다. 제로 트러스트 네트워킹이 점점 더 중요해짐에 따라 많은 고객이 여러 애플리케이션에서 mTLS 암호화를 적용하기 위해 서비스 메시를 의무화하고 있습니다. ztunnel만 사용하는 Istio의 앰비언트 모드는 ID 및 인증서 관리를 포함하여 이를 제공하는 동시에 리소스 오버헤드와 실행 중인 워크로드에 미치는 영향을 최소화합니다. 요구 사항이 확장되면 waypoint를 추가하여 HTTP 요청 유형(예: /GET) 또는 헤더를 기반으로 하는 애플리케이션 수준 정책 및 텔레메트리를 도입할 수 있습니다. 

향상된 확장성 

Istio의 앰비언트 모드는 관리할 프록시 수가 적고 사용 공간이 훨씬 작기 때문에 기존 사이드카 모드보다 확장성이 훨씬 뛰어납니다. 고객이 Istio의 범위 지정 및 확장 기능을 사용하여 수천 개의 워크로드를 지원하도록 메시를 확장하는 것을 확인했지만 앰비언트 모드의 아키텍처는 필요한 최적화 횟수를 줄여 수십만 개 또는 수십만 개의 워크로드로 확장할 수 있는 잠재력을 제공합니다. 

잠재적 성능 특성

Istio 커뮤니티에서 유망한 초기 성능 측정이 있었지만 Red Hat은 여전히 고객과 유사한 엔터프라이즈급 설정에서 Istio 앰비언트 모드의 성능을 평가하고 있습니다. 현재까지는 사이드카 모드와 비슷한 성능을 보였으며 향후 릴리스에서 개선될 가능성이 있습니다. 성능 특성은 ztunnel만 사용하는 경우와 ztunnel 및 waypoint를 함께 사용하는 경우에 따라 다르며, waypoint를 사용하면 설정에 따라 오버헤드가 더 커집니다. 또한 ztunnel의 수직 확장성을 제한하는 알려진 병목 현상이 발생했으며, 이 문제를 해결하는 데 시간이 걸릴 것입니다. Istio의 앰비언트 아키텍처는 향후 릴리스에서 성능이 향상될 가능성이 있다고 생각합니다.

더 쉬운 채택

또한 Istio의 앰비언트 모드를 사용하면 사이드카 컨테이너를 추가하기 위해 워크로드를 더 이상 수정할 필요가 없으므로 서비스 메시를 더 쉽게 채택할 수 있습니다. 실제로 메시를 추가하거나 메시를 업그레이드할 때 다시 시작할 필요조차 없습니다. 또한 2단계 아키텍처를 사용하면 필요하지 않을 때 레이어 7 프록시의 리소스 비용을 발생시키지 않고도 Istio 기능을 점진적으로 채택할 수 있습니다. 

기능 지원 수준

앰비언트 모드를 사용하는 Istio 기능에 대한 지원 수준은 기존 사이드카 모드와 다를 수 있습니다. 지원되는 기능 목록은 Service Mesh 기능 지원 표를 참조하십시오. 멀티 클러스터 및 멀티 메시와 같은 고급 기능은 아직 개발 중이며, 특히 사이드카가 있는 waypoint 프록시를 사용하는 경우 사이드카 및 앰비언트 모드를 사용하는 워크로드를 혼합하는 데는 제한이 있습니다. 앰비언트와 사이드카에 대한 Istio 커뮤니티의 관점은 이 페이지를 참조하십시오. 

업그레이드 고려 사항

Istio의 앰비언트 모드는 사이드카 프록시를 사용할 때 필요한 워크로드 포드를 다시 시작하지 않고도 Istio 데이터 평면을 업데이트할 수 있다는 이점을 제공합니다. 절충안은 ztunnel이 여러 애플리케이션의 데이터 경로에 포함된 공유 노드 수준 에이전트라는 것입니다. 따라서 ztunnel을 주의해서 업그레이드해야 합니다. 유지 관리 기간 또는 트래픽이 적은 기간에 업그레이드하는 것이 좋습니다. 그러면 해당 노드에서 수명이 긴 TCP 연결이 재설정됩니다. 이번 릴리스에서는 수정 기반(카나리아) 업그레이드도 아직 지원되지 않습니다. 이것은 향후 릴리스에서 개발될 영역입니다.

Istio의 앰비언트 모드 시작하기

Istio의 앰비언트 모드를 시작하기 위해 OpenShift Service Mesh는 ztunnel을 데몬 세트로 설치하고 관리할 수 있는 'Ztunnel' 리소스를 제공합니다. 이 리소스는 'Istio' 및 'IstioCNI' 리소스와 함께 설치되며 일부 워크로드에 사이드카가 있는 경우에도 '앰비언트' 프로필로 구성해야 합니다. 

기존 사이드카 모드와 마찬가지로 Istio 제어 평면이 메시의 일부가 될 네임스페이스와 더 이상 메시의 일부가 아닌 네임스페이스를 모니터링할 수 있도록 Istio '검색 선택기'를 구성하는 것도 중요합니다. 앰비언트 모드의 경우 'istio.io/dataplane-mode=ambient' 레이블은 네임스페이스 또는 워크로드가 메시에 포함되어야 함을 나타내는 데 사용됩니다. 워크로드 추가에 대한 자세한 내용은 Istio 커뮤니티 설명서를 참조하십시오.

새 워크로드가 메시지에 추가되면 Istio CNI 에이전트는 노드 로컬 ztunnel 프록시와 함께 작동하여 트래픽 리디렉션을 구성하므로 모든 트래픽이 가로채어 Istio의 HBONE 터널링 프로토콜을 사용하여 mTLS를 사용하도록 업그레이드됩니다. Ztunnel은 또한 동일한 노드의 모든 Pod에 대한 인증서 가져오기 및 관리를 처리합니다.

waypoint 프록시가 필요한 경우 OpenShift 4.19+에 포함된 Kubernetes Gateway API의 Kubernetes 'Gateway' 리소스를 사용하여 인그레스(ingress) 또는 이그레스(egress) 게이트웨이를 추가하는 것과 유사한 방식으로 추가할 수 있습니다. waypoint 설치에 대한 자세한 내용은 여기에서 확인할 수 있으며, L7 기능에 waypoint를 사용하는 방법은 여기에서 확인할 수 있습니다.

Istio의 앰비언트 모드를 시작하는 방법에 대한 자세한 절차는 OpenShift Service Mesh 설명서를 참조하십시오.

이미 서비스 메시를 사용 중인 경우 앰비언트 모드로 마이그레이션할 수 있나요?

앰비언트 모드는 새로운 서비스 메시 사용자에게 이상적이지만 기존 서비스 메시 배포에 도입하고 특정 주의 사항이 있는 사이드카 모드 워크로드와 결합할 수 있습니다. 또한 포드 당 전용 Envoy 프록시의 전체 기능 세트가 필요한 경우 사이드카 모드가 계속 선호되는 사용 사례가 될 것으로 예상합니다. 

기존 메시지에 앰비언트 모드를 도입하려면 메시(Istio 및 Istio CNI)를 '앰비언트' 프로필로 업데이트하고 사이드카가 있는 모든 워크로드를 다시 시작하여 HBONE 터널링 프로토콜을 사용하여 ztunnel과 통신할 수 있도록 해야 합니다. 

이러한 공존의 현재 제한 사항은 사이드카 프록시와 앰비언트 워크로드 간의 트래픽이 일반적으로 waypoint 프록시를 우회하므로 앰비언트 워크로드에 레이어 7 정책이 적용되지 않는다는 것입니다.

이러한 제한 사항을 고려할 때 네임스페이스 및 애플리케이션 그룹은 긴밀하게 결합된 애플리케이션 워크로드 내에서 모드를 혼합하지 않고 앰비언트 모드 또는 사이드카 모드를 사용하는 것이 좋습니다. 사이드카 및 앰비언트 모드 포드 레이블을 혼합하지 않는 것도 중요합니다.

Istio의 앰비언트가 적용된 Kiali

OpenShift Service Mesh에 포함된 Istio용 콘솔인 Kiali는 Istio의 앰비언트 모드를 구성, 시각화 및 검증하기 위한 다양한 기능을 제공합니다. 워크로드가 ztunnel이 있는 메시, waypoint가 있는 메시, 사이드카 모드 또는 메시의 일부가 아닌 상태 등 여러 가지 가능한 상태에 있을 수 있으므로 Kiali는 분산 애플리케이션이 예상대로 작동하지 않을 때 메시의 상태를 이해하고 문제를 해결하는 데 훨씬 더 중요합니다.

Kiali는 모든 수준에서 앰비언트 모드가 성공적으로 구성되었음을 명확하게 확인합니다. 이것은 앰비언트 프로필이 활성화된 상태로 실행되는 Istio 제어 평면으로 시작하고 네임스페이스와 워크로드가 레이블이 지정되어 워크로드 트래픽이 예상대로 ztunnel 및/또는 waypoint에 의해 캡처되도록 합니다. 마지막으로, 포드 수준에서 암호화되지 않은 TCP 대신 Istio의 HBONE 프로토콜을 사용하여 트래픽이 보호되는지 확인할 수 있습니다.

또한 Kiali는 ztunnel과 waypoint 간의 연관된 로그를 제공하여 워크로드에서 각 프록시를 거쳐 트래픽이 이동하는 방식을 이해하고 문제를 해결할 수 있도록 지원합니다.

웨이포인트 프록시는 다른 프록시와 유사하지만, Kiali는 등록된 서비스와 워크로드를 표시하는 특정 탭을 제공합니다. 

마지막으로 앰비언트 모드의 토폴로지 그래프는 사이드카 모드와 비교했을 때 다르게 보입니다. 이제 프록시가 2개 계층으로 나뉘므로 워크로드당 2개의 독립적인 텔레메트리 세트가 보고될 수 있습니다. L4(TCP) 메트릭은 ztunnel에서 파란색 엣지로 표시되고, L7(HTTP) 메트릭은 waypoint가 구성된 경우 녹색 엣지로 표시됩니다. Kiali는 표시되는 트래픽 유형을 선택할 수 있는 기능을 제공합니다.

웨이포인트 프록시는 긴밀하게 결합된 워크로드 그룹(일반적으로 분산된 애플리케이션 구성)을 나타낼 가능성이 높으므로, 웨이포인트 보기는 매우 큰 메시일 수 있는 메시에 대한 더 높은 수준의 개요를 제공합니다.

앰비언트 모드에 대한 Kiali의 모든 기능에 대한 자세한 내용은 Kiali 커뮤니티 설명서를 참조하십시오.

Istio 1.27 업데이트

이번 릴리스에는 Istio 1.27 변경 사항에 명시된 모든 업데이트가 포함되어 있습니다. 다음은 주요 내용입니다.

Gateway API Inference Extensions (GIE)

이번 릴리스에는 Gateway API Inference Extensions에 대한 지원이 포함됩니다. Red Hat OpenShift AI 3에서 고객 지원을 강화하기 위해 Red Hat은 일반적으로 사용 가능한 API 구현(버전 1.0)을 이번 릴리스에 백포트했습니다. 이 기능은 Red Hat OpenShift AI 3에서만 지원되며 OpenShift Service Mesh 3.2의 기술 프리뷰 기능으로 간주됩니다. 

앰비언트 모드를 사용하는 멀티 클러스터

이번 릴리스에서는 멀티 프라이머리, 멀티 클러스터 토폴로지에서 Istio 앰비언트 모드에 대한 초기 지원이 도입되었습니다. 이 기능은 업스트림에서 계속 개발 중이므로 OpenShift Service Mesh 3.2에서는 '개발자 프리뷰'로 지정되었습니다. 

사이드카 모드의 네이티브 nftables 지원

Red Hat Enterprise Linux(RHEL) 10을 준비하기 위해 Red Hat은 Istio 프로젝트에 nftables 지원을 제공했으며, Istio 1.27에서 사이드카 모드에 대한 지원이 도입되었습니다. nftable 프레임워크는 Istio가 네트워크 리디렉션 규칙을 구성하는 데 사용하는 Linux 기능인 iptables의 최신 버전입니다. Envoy 사이드카로 또는 사이드카에서 트래픽을 리디렉션하기 위한 향상된 성능, 유지 관리성 및 보다 유연한 규칙 관리를 제공하는 것을 목표로 합니다. RHEL 10부터 nftables는 네트워킹 규칙을 관리하기 위한 기본 도구가 됩니다. RHEL 10 지원은 향후 OpenShift 릴리스에서 제공될 예정입니다.

Cert-manager Istio-CSR 일반 공급

cert-manager Operator는 OpenShift Service Mesh와 함께 사용하도록 지원되지만, cert-manager가 워크로드에 대한 인증서를 서명, 제공 및 갱신하려면 istio-csr 에이전트가 필요합니다. cert-manager Operator 버전 1.18 릴리스를 통해 이제 이 에이전트를 일반적으로 사용할 수 있으며 지원되는 모든 OpenShift Service Mesh 버전에서 사용할 수 있습니다. cert-manager와 OpenShift Service Mesh가 어떻게 협력하여 제로 트러스트를 지원하는지에 대한 자세한 내용은 이 블로그 게시물을 참조하십시오. OpenShift Service Mesh에서 cert-manager를 사용하는 방법에 대한 자세한 절차는 설명서를 참조하십시오.

OpenShift Service Mesh 시작하기

Red Hat OpenShift Service Mesh에 대한 자세한 내용은 이 블로그 게시물과 멀티 클러스터 서비스 메시에 대한 후속 조치를 참조하십시오. 

서비스 메시를 시작하려면 먼저 Red Hat OpenShift Service Mesh 3 Operator를 설치해야 합니다. 서비스 메시를 처음 사용하는 경우 Istio의 앰비언트 모드를 고려해 보십시오. 기존 사이드카 모드보다 훨씬 더 리소스 효율적인 서비스 메시 아키텍처를 제공합니다. Istio의 앰비언트 모드를 시작하려면 여기에서 설명서를 참조하십시오. 

OpenShift 사용자 워크로드 모니터링, 분산 추적 및 Kiali와 함께 OpenShift Service Mesh를 사용하는 방법에 대한 엔드 투 엔드 예제는 이 솔루션 패턴을 참조하십시오.