セットアップ FAQ

簡単なはじめに評価インストールに加えて、Istioをインストールするために使用できるいくつかの異なる方法があります。どれを使用すべきかは、本番環境の要件によって異なります。以下に、利用可能な各方法の長所と短所をいくつか示します。

1. istioctl install

   最もシンプルで、セキュリティの高いインストールおよび管理パスです。これは、ほとんどのユースケースでコミュニティが推奨する方法です。

   長所

   • 徹底的な構成検証とヘルス検証。
   • 広範な構成/カスタマイズオプションを提供するIstioOperator APIを使用します。

   短所

   • 複数のバイナリを管理する必要があり、Istioのマイナーバージョンごとに1つずつ必要です。
   • istioctlコマンドは、実行中の環境に基づいて値を自動的に設定できるため、異なるKubernetes環境で異なるインストールが行われる可能性があります。

2. istioctl manifest generate

   Kubernetesマニフェストを生成し、kubectl apply --pruneで適用します。この方法は、厳密な監査または出力マニフェストの拡張が必要な場合に適しています。

   長所

   • リソースは、istioctl installで使用されているのと同じIstioOperator APIから生成されます。
   • 広範な構成/カスタマイズオプションを提供するIstioOperator APIを使用します。

   短所

   • istioctl installで実行される一部のチェックは実行されません。
   • UXはistioctl installに比べて簡略化されていません。
   • エラー報告は、適用ステップにおいてistioctl installほど堅牢ではありません。

3. Helmを使用したインストール

   Helmチャートを使用すると、Helmベースのワークフローとの簡単な統合と、アップグレード中の自動リソースプルーニングが可能になります。

   長所

   • 業界標準のツールを使用した使い慣れたアプローチ。
   • Helmネイティブなリリースとアップグレード管理。

   短所

   • istioctl installと比較して、チェックと検証が少なくなります。
   • 一部の管理タスクでは、より多くの手順が必要となり、複雑さがより高くなります。

これらのすべての方法のインストール手順は、Istioインストールページで入手できます。

クラスターが自動サイドカーインジェクションの前提条件を満たしていることを確認してください。マイクロサービスがkube-system、kube-public、またはistio-system名前空間にデプロイされている場合、それらは自動サイドカーインジェクションから除外されます。代わりに別の名前空間を使用してください。