コンテンツにスキップ

Istio を採用しない場合との比較＠Istio

はじめに

本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。


01. 比較表

Istio と Kubernetes のみの比較

Kubernetes と Istio には重複する能力がいくつか (例：サービス検出) ある。istio-proxy をインジェクションした Pod 間の通信では、kube-proxy や Service が通信を中継しない。ただし、Service や EndpointSlice は Istio に宛先情報を提供するために必要である。

実際の運用では、サービスメッシュで管理するマイクロサービスなどの Pod に istio-proxy をインジェクションする。

そのため、istio-proxy をインジェクションしない Pod では、Istio ではなく、従来の CoreDNS などによるサービス検出と、kube-proxy と Service によるルーティングを使用することになる。

能力 Istio + Kubernetes + Envoy Kubernetes + Envoy Kubernetes のみ
サービスメッシュコントロールプレーン Istiod コントロールプレーン (discovery コンテナ) go-control-plane なし
サービス検出でのルーティング先設定 VirtualService + DestinationRule route キー kube-proxy + Service + CoreDNS
サービス検出でのリスナー EnvoyFilter + EndpointSlice listener キー kube-proxy + Service + CoreDNS
トラフィック管理 VirtualService + Service + DestinationRule 記入中... Service
サービス検出での追加サービス設定 ServiceEntry + EndpointSlice cluster キー EndpointSlice
Cluster 外 Node に対するサービス検出 ServiceEntry + WorkloadEntry endpoint キー Egress
サービスレジストリ kube-apiserver etcd kube-apiserver
Node 外からのインバウンド通信のルーティング ・VirtualService + Gateway (内部的には、NodePort Service または LoadBalancer Service が作成され、これらは Node 外からのインバウンド通信を待ち受けられるため、Ingress は不要である)
・Ingress + Istio Ingress Controller + ClusterIP Service		 route キー + listener キー Ingress + Ingress Controller + ClusterIP Service


Istio API から Kubernetes Gateway API への置き換え

Istio の Gateway や VirtualService は、Kubernetes Gateway API の Gateway や HTTPRoute などに置き換えられる。

しかし、Istio の Gateway や VirtualService がもつ機能の多くに必要であり、例えば HTTPRoute は VirtualService のような Pod 間通信に非対応である。

置き換えることなく、Istio の API をそのまま使用すればよい。

Google Cloud Service Mesh では、HTTPRoute などを補うカスタムリソースとして、Mesh がある。

Istio API Kubernetes Gateway API への置き換え
AuthorizationPolicy そのまま使用
DestinationRule そのまま使用
EnvoyFilter そのまま使用
Gateway Kubernetes Gateway
PeerAuthentication そのまま使用
ProxyConfig そのまま使用
RequestAuthentication そのまま使用
ServiceEntry そのまま使用
Sidecar そのまま使用
Telemetry そのまま使用
VirtualService ・GRPCRoute
・HTTPRoute
・TCPRoute
・TLSRoute
・UDPRoute
WasmPlugin そのまま使用
WorkloadEntry そのまま使用
WorkloadGroup そのまま使用


01-02. Istio のメリット/デメリット

メリット


デメリット

項目 説明
Node のハードウェアリソースの消費量増加 Istio の Pod 間通信では、Kubernetes と比べて、通信に必要なコンポーネント (例：Istiod コントロールプレーン、istio-proxy) が増える。そのため、Node のハードウェアリソースの消費量が増え、また宛先 Pod からのレスポンス速度が低くなる。
学習コストの増加 Istio が多機能であり、学習コストが増加する。


02. トラフィック管理

Istio + Kubernetes + Envoy

Kubernetes と Istio 上の Pod は、Service の完全修飾ドメイン名の URL (http://foo-service.default.svc.cluster.local) を指定すると、その Service の配下にある Pod と HTTP で通信できる。

指定する URL は Kubernetes のみの場合と同じであるが、実際は Service を経由しておらず、Pod 間で直接的に通信している。

Pod 間 (フロントエンド領域とマイクロサービス領域間、マイクロサービス間) では、istio-proxy 間の相互 TLS 認証によって通信を暗号化できる。Auto mTLS が有効な場合、通信元 istio-proxy は宛先に応じて相互 TLS 認証を自動的に選択する。


Kubernetes のみ

Kubernetes 上の Pod は、Service の完全修飾ドメイン名の URL (http://foo-service.default.svc.cluster.local) を指定すると、その Service の配下にある Pod と HTTP で通信できる。

Pod 間 (フロントエンド領域とマイクロサービス領域間、マイクロサービス間) を HTTPS で通信したい場合、外部認証局や各コンポーネントで証明書の発行・取得を実装し、取得した証明書をメモリやマウントしたファイルなどに保持する必要がある。