アプリケーションは複数の環境にまたがる場合が多く、データベースはその良い例です。レガシーまたはストレージの理由で、データベースをKubernetesの外で稼働しているかもしれません。もしくはマネージドデータベースサービスを使用していることもあります。
しかし心配は要りません！ Istioサービスメッシュに外部データベースを追加できます。方法を見てみましょう。
ここでは、Istioが有効になっているKubernetesクラスター内で実行されている plants サービスがあります。plants は、Firestore用のGolangクライアントライブラリを使用して、Google Cloudで実行されているFirestore NoSQLデータベースにインベントリを書き込みます。ログは次のようになります。:
writing a new plant to Firestore...
✅success
Firestoreへの送信トラフィックを監視するとします。これを行うには、Firestore APIのホスト名に対応するIstio ServiceEntryを追加します。
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: firestore
spec:
hosts:
- "firestore.googleapis.com"
ports:
- name: https
number: 443
protocol: HTTPS
location: MESH_EXTERNAL
resolution: DNS
ここから、IstioのサービスグラフにFirestoreが表示されます。
plants のサイドカープロキシがFirestore TLSトラフィックを プレーンなTCPとして受信しているため、トラフィックはTCPとして表示されることに注意してください。グラフの先頭は、Firestoreへのリクエストスループットの値をビット/秒で示しています。
ここで、データベースに接続できない場合の plants の動作をテストするとします。アプリケーションコードを変更せずに、Istioで行えます。
Istioは現在TCPフォールトインジェクションをサポートしていませんが、Firestore APIトラフィックを別の「ブラックホール」サービスに送信するTCPトラフィックルールを作成して、Firestoreへのクライアント接続を効果的に切断することができます。
これを行うには、クラスター内に小さな echo サービスをデプロイして、Firestoreへの全トラフィックを echo サービスに転送します。:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: fs
spec:
hosts:
- firestore.googleapis.com
tcp:
- route:
- destination:
host: echo
port:
number: 80
このIstio VirtualServiceをクラスターに適用すると、plants ログにエラーが報告されます。:
writing a new plant to Firestore...
🚫 Failed adding plant: rpc error: code = Unavailable desc = all SubConns are in TransientFailure
そして、サービスグラフでは、firestore ノードに紫色の VirtualService アイコンがあることがわかります。これは、そのサービスに対してIstioトラフィックルールを適用したことを意味します。データベースへの全ての外部接続をリダイレクトしたため、やがて直近1分間のFirestoreのスループットは 0 になります。
Istioで、Redis、SQL、MongoDBなど、クラスター内のデータベースのトラフィックを管理することもできます。詳細については、Istio docsをご覧ください。