コンテナではないマシンにも同じ ID を
一言でいうと
Kubernetesの外のマシンも、サイドカーを入れればメッシュに入れます。WorkloadGroupはそのようなマシンのテンプレート(ラベル・サービスアカウント・ポート)、WorkloadEntryはマシン1台(アドレス)で、Kubernetesのサービスのセレクターは、WorkloadEntryも選ぶので、VMを既存のサービス名の後ろに置けます。マシンのサイドカーは、Podと同じ方式で、istiodから証明書と設定を受け取ります。
なぜ必要なのか
すべてがコンテナに移ってくるわけではありません。古い決済システム、ライセンスに縛られたデータベースの前段、特殊なハードウェアが付いたサーバーが残ります。それらのマシンがメッシュの外にあると、2つのことが崩れます。メッシュ内のサービスがそのマシンを呼ぶときにmTLS・認可が途切れ、そのマシンがメッシュ内を呼ぶときに身元がなくSTRICTポリシーに阻まれます。結局、例外ルール(PERMISSIVE、広い許可)ができ、例外がセキュリティの穴になります。
VMの組み込みは、そのマシンに同じサイドカーを入れて、同じ身元の仕組みに入れる方法です。
どう動くのか
1. テンプレート: WorkloadGroup。Podのテンプレートのように、「こういうマシンは、このラベル・サービスアカウント・ポートを持つ」を書きます。istioctl x workload entry configureがこれを読んで、マシンに渡すファイルを5つ作ります。
| ファイル | マシンでの置き場所 | 用途 |
|---|---|---|
| cluster.env | /var/lib/istio/envoy/ | ネームスペース・サービスアカウント・ラベル・リダイレクトするポート |
| istio-token | /var/run/secrets/tokens/ | 最初に証明書を受け取るときに差し出すサービスアカウントトークン |
| mesh.yaml | /etc/istio/config/mesh | メッシュの設定(istiodのアドレスなど) |
| root-cert.pem | /etc/certs/ | 信頼するルート |
| hosts | /etc/hostsに追記 | istiodの名前を引くためのアドレス |
2. サイドカー: istio-sidecarパッケージ。公式のdebが、pilot-agent・envoy・istio-start.shを入れます。istio-start.shは、iptablesで出入りするトラフィックをサイドカーに回す規則を仕込み、istio-proxyユーザーでpilot-agentを起動します。pilot-agentはトークンでistiodに証明書を要求し、その後は、Podのサイドカーとまったく同じようにxDSを受け取ります。
3. マシン1台: WorkloadEntry。アドレス・ラベル・サービスアカウントを書きます。ラベルがサービスのセレクターに合えば、istiodがこのアドレスを、そのサービスのエンドポイントとして、すべてのサイドカーに送ります。istiodに自動登録が有効になっていれば、サイドカーがつながるときにWorkloadEntryが自然にできますが、この機能はインストール時に有効にする必要があります。
istiodに届く道筋。複数のネットワークにまたがるインストールでは、マシンがEast-Westゲートウェイを通ってistiodに届きます。マシンがクラスターのServiceアドレスに直接届くネットワークなら、istiodのアドレスを直接渡せます。
このラボの「メッシュ外のマシン」
セッションごとにVMが1台だけで、VM同士は通信できません。そこで、同じVMの中のネットワークネームスペースを、2台目のマシンにしました。ネットワークネームスペースは、アドレス・ルーティングテーブル・iptablesを丸ごと別に持つカーネルの分離単位なので、サイドカーのリダイレクト規則はその中にだけ入ります。実際に測ってみると、規則はネームスペースの中のiptables-legacy側に入り、ホスト(k3sのkube-proxyの規則がある側)にはISTIO規則が1つもできません。両者はぶつかりません。本物のVMとの違いは、ファイルシステムをホストと共有するという点だけです。
現場での姿
VMのサイドカーは起動するのにistiodにつながらない場合です。たいてい名前解決です。hostsの行が抜けているか、DNSがクラスターの名前を知りません。/var/log/istio/istio.logに接続エラーが残ります。
1時間後に新しいVMがつながれない場合です。istio-tokenはデフォルトで1時間のものです。最初に証明書を受け取った後は、証明書で更新しますが、最初につながる前にトークンが期限切れになったら、作り直す必要があります。
VMをサービスの後ろに入れたのに、ときどき接続が切れる場合です。エンドポイントは、WorkloadEntryがある限り残ります。マシンが死んでも外れないので、WorkloadGroupのprobeを使う自動登録や、外れ値検出を併用します。
公式ドキュメント: Virtual Machine Installation・Virtual Machine Architecture・WorkloadEntry・WorkloadGroup
次のラボですること
同じVMの中のネットワークネームスペースで動く「メッシュ外のマシン」を、まず外から呼び、WorkloadGroupとServiceを作って、マシンに渡すファイルを取り出します。ファイルを所定の場所に置いて、ネームスペースの中でサイドカーを起動してistiodにつなげた後、iptablesの規則がホストとぶつからないことを数え、WorkloadEntryでサービスの後ろに入れます。両方向でmTLSが張られることをログで確認し、STRICTと認可ポリシーまでかけます。