仮想マシンのデバッグ
このページでは、仮想マシンにデプロイされた Istio の問題のトラブルシューティング方法について説明します。これを読む前に、仮想マシンインストールの手順を実行する必要があります。仮想マシンアーキテクチャも、コンポーネント間の相互作用を理解するのに役立ちます。
Istio仮想マシンインストールのトラブルシューティングは、Kubernetes内で実行されているプロキシの問題のトラブルシューティングと似ていますが、いくつかの重要な違いに注意する必要があります。
多くの情報は両方のプラットフォームで利用できますが、この情報へのアクセス方法は異なります。
ヘルスモニタリング
Istioサイドカーは通常、systemd
ユニットとして実行されます。正しく実行されていることを確認するには、ステータスを確認できます。
$ systemctl status istio
さらに、サイドカーのヘルスは、そのヘルスエンドポイントでプログラム的にチェックできます。
$ curl localhost:15021/healthz/ready -I
ログ
Istioプロキシのログは、いくつかの場所に保存されます。
プロキシの初期化に関する詳細を含むsystemd
ログにアクセスするには、
$ journalctl -f -u istio -n 1000
プロキシはstderr
とstdout
をそれぞれ/var/log/istio/istio.err.log
と/var/log/istio/istio.log
にリダイレクトします。これらをkubectl
と同様の形式で表示するには、
$ tail /var/log/istio/istio.err.log /var/log/istio/istio.log -Fq -n 100
ログレベルは、cluster.env
設定ファイルを変更することで変更できます。既に実行されている場合は、istio
を再起動してください。
$ echo "ISTIO_AGENT_FLAGS=\"--log_output_level=dns:debug --proxyLogLevel=debug\"" >> /var/lib/istio/envoy/cluster.env
$ systemctl restart istio
iptables
iptables
ルールが正常に適用されていることを確認するには、
$ sudo iptables-save
...
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
Istioctl
ほとんどのistioctl
コマンドは仮想マシンで正常に機能します。たとえば、istioctl proxy-status
を使用して、接続されているすべてのプロキシを表示できます。
$ istioctl proxy-status
NAME CDS LDS EDS RDS ISTIOD VERSION
vm-1.default SYNCED SYNCED SYNCED SYNCED istiod-789ffff8-f2fkt 1.24.0
ただし、istioctl proxy-config
はプロキシに接続するためにKubernetesの機能に依存しており、仮想マシンでは機能しません。代わりに、Envoyからの設定ダンプを含むファイルを渡すことができます。例:
$ curl -s localhost:15000/config_dump | istioctl proxy-config clusters --file -
SERVICE FQDN PORT SUBSET DIRECTION TYPE
istiod.istio-system.svc.cluster.local 443 - outbound EDS
istiod.istio-system.svc.cluster.local 15010 - outbound EDS
istiod.istio-system.svc.cluster.local 15012 - outbound EDS
istiod.istio-system.svc.cluster.local 15014 - outbound EDS
自動登録
仮想マシンがIstiodに接続すると、WorkloadEntry
が自動的に作成されます。これにより、仮想マシンはKubernetesのEndpoint
と同様に、Service
の一部になります。
これらが正しく作成されていることを確認するには、
$ kubectl get workloadentries
NAME AGE ADDRESS
vm-10.128.0.50 14m 10.128.0.50
証明書
仮想マシンは、Kubernetesが提供するサービスアカウントトークンを使用してmTLS証明書を認証および更新するKubernetes Podとは異なり、証明書を処理します。代わりに、既存のmTLS資格情報を使用して認証局で認証し、証明書を更新します。
これらの証明書のステータスは、Kubernetesの場合と同様に確認できます。
$ curl -s localhost:15000/config_dump | ./istioctl proxy-config secret --file -
RESOURCE NAME TYPE STATUS VALID CERT SERIAL NUMBER NOT AFTER NOT BEFORE
default Cert Chain ACTIVE true 251932493344649542420616421203546836446 2021-01-29T18:07:21Z 2021-01-28T18:07:21Z
ROOTCA CA ACTIVE true 81663936513052336343895977765039160718 2031-01-26T17:54:44Z 2021-01-28T17:54:44Z
さらに、これらはディスクに永続化されるため、ダウンタイムや再起動によって状態が失われることはありません。
$ ls /etc/certs
cert-chain.pem key.pem root-cert.pem