Istio

最終更新: 2023-04-28 08:11:31 +0800 +0800
原文は英語で書かれています。あなたはAI翻訳版を読んでいます。

Istio は、Envoy プロキシとコントロールプレーンの設定を通じて、ワークロードにトラフィックポリシー、アイデンティティ、テレメトリ、セキュリティポリシーを適用します。これらの横断的な要件が、追加される運用面を正当化する場合にのみ採用してください。

データプレーンとコントロールプレーン #

データプレーンは、Envoy サイドカー、またはノードごとの ztunnel とオプションの waypoint プロキシで構成されるアンビエントデプロイメントで構成されます。istiod は、xDS を通じてサービスディスカバリ、証明書、トラフィック設定を計算して配布します。ワークロードのパスは、選択したモードに応じてインバウンドおよびアウトバウンドトラフィックを捕捉します。このパスをバイパスするトラフィックはメッシュポリシーで管理できません。アンビエントモードとサイドカーでは L4/L7 の適用位置が異なるため、移行時には各ポリシーがどこで実行されるかを検証する必要があります。

トラフィック管理 #

Gateway と VirtualService リソースは、イングレスリスナーとルーティングルールを定義します。DestinationRule は、宛先に対するサブセット、ロードバランシング、接続、TLS のポリシーを定義します。version などの安定したラベルでルーティングし、サブセットで使用するラベルがワークロードに存在することを確認してください。

重み付きルートを使用すると、測定した割合のトラフィックを安定版サブセットからカナリアへ移行できます。ヘッダーまたはアイデンティティのマッチ条件を使用して、最初にテストトラフィックを振り分けることもできます。各変更は、プロキシ設定の収束とワークロードの健全性を確認してから進めてください。ルートの重みでは、エンドポイントの欠落や誤ったサブセットセレクターを補償できません。

リトライ、タイムアウト、サーキットブレーカー、フォールトインジェクションは、障害時の挙動を変更します。呼び出し元のデッドラインに応じて予算を設定してください。制限のないリトライポリシーは、過負荷を増幅し、べき等でない処理を重複実行する可能性があります。

アイデンティティとセキュリティ #

Istio は Kubernetes のサービスアカウントに基づくワークロードアイデンティティを発行し、プロキシ間の相互 TLS を使用できます。必要なすべてのワークロードがメッシュに参加していることを確認したうえで、AuthorizationPolicy による認可を適用してください。移行時は、管理対象外のトラフィックを特定する目的に限って permissive から開始し、その後、明示的な移行計画に基づいて strict な相互 TLS に移行します。

mTLS の状態には PeerAuthentication を使用し、必要に応じてエンドユーザーの JWT を検証するには RequestAuthentication を使用し、アクセス判断には AuthorizationPolicy を使用します。ワークロードアイデンティティは、テナントやビジネス権限に対するアプリケーション認可の代替にはなりません。

istiod は認証局として動作するか、外部 CA と統合し、短期間有効なワークロード証明書を有効期限前にローテーションします。発行、ルートの移行、トラストドメインの設定、クロックスキューを監視してください。ルートをローテーションする際は、リーフ証明書を置き換える前に重複する信頼関係を配布し、古いワークロードと新しいワークロードが相互に認証できるようにします。

運用 #

メッシュのコントロールプレーンとデータプレーンのバージョンを意図的に管理し、ロールアウト前にアナライザーの出力を確認して、プロキシのリソース使用量、証明書の有効期限、設定の収束を監視してください。意図した YAML に依存するのではなく、istioctl proxy-status と istioctl proxy-config を使用して、プロキシが受信した内容を診断します。

Envoy は、テレメトリ設定に従ってリクエストメトリクス、アクセスログ、トレースを出力します。イングレス、waypoint またはサイドカー、アプリケーション間でリクエスト ID とサンプリングポリシーを保持してください。テレメトリが欠落している場合、トラフィックがプロキシをバイパスした、設定が収束していない、または収集に失敗した可能性があります。

コントロールプレーンの健全性、データプレーンの健全性、アプリケーションの健全性は、別々の障害ドメインです。一時的なコントロールプレーン障害中も、既存のプロキシは最後に受け入れた設定で動作を継続できますが、新しいエンドポイント、証明書、ポリシー変更は停滞する可能性があります。リビジョン単位または範囲を限定したワークロードセット単位でロールアウトし、拒否された xDS 更新とプロキシバージョンを確認して、テスト済みのロールバック手段を保持してください。

参考資料 #

コメント

GitHub で閲覧・コメントする(投稿にはログインが必要です)