istioctl は、クラスター上で Istio を動かす最も手早い方法です。そのため、長期的に管理する本番のインストールには（次のガイドで説明する）Helm のほうが適していますが、メッシュを学ぶ出発点としてはふさわしいツールです。このガイドでは、Istio をインストールし、正常であることを確認し、実際のワークロードにサイドカーを注入します。

インストール前に：クラスターのリソース

Istio のコントロールプレーンと ingress/egress ゲートウェイには、実際の CPU とメモリが必要で、一般的なローカルクラスターがデフォルトで割り当てる量よりも多くを必要とします。特に minikube では、余裕を持ってクラスターを起動してください。

minikube start --cpus=4 --memory=8192

リソース不足は、最初のインストールで Istio の Pod が Pending や CrashLoopBackOff で止まる一般的な原因であり、他のトラブルシューティングを始める前に除外しておく価値があります。

istioctl をインストールする

Istio のリリースページからお使いのプラットフォーム向けのものをダウンロードするか、インストールスクリプトを使います。

curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH
istioctl version --remote=false

export PATH の行は現在のシェルセッションにのみ適用されます。この手順を繰り返さずに、新しいターミナルすべてで istioctl を使いたい場合は、シェルのプロファイル（~/.bashrc、~/.zshrc）に追加してください。

Istio をクラスターにインストールする

istioctl install --set profile=demo -y

-y は確認プロンプトをスキップします。demo プロファイルは、コントロールプレーンと、ingress および egress の両方のゲートウェイを、ローカルクラスターにも十分軽いリソース設定でインストールします。本番のインストールは通常、より簡素な default プロファイルから始めますが、これは Helm のガイドで説明します。選ぶ前に各プロファイルに何が含まれるかを確認したい場合は、利用可能なプロファイルを一覧表示します。

istioctl profile list

インストールを確認します。

kubectl get pods -n istio-system

istiod と、demo プロファイルでは istio-ingressgateway と istio-egressgateway が、すべて Running になっているはずです。

Istio のインストールがまだ何も変更していないことを確認する

最初は意外に感じられるため、明示的に確認しておく価値があります。Istio をインストールしても、既存のワークロードには何の影響もありません。サイドカーは現れず、注入を明示的に有効にするまで、アプリケーションの動作は何も変わりません。Istio がクラスターに存在しても使われていなければ、そのコストは、自分のコントロールプレーンとゲートウェイが消費するリソースだけです。

namespace のサイドカー注入を有効にする

kubectl label namespace default istio-injection=enabled
kubectl get namespace default --show-labels

これは、ラベルを適用した後に作成された Pod にのみ影響します。その namespace にすでに存在していた Pod は、再作成してください。

kubectl delete pods --all -n default
kubectl rollout restart deployment -n default

（あるいは、元々それらを作成したマニフェストを再適用します。変更していない同じファイルに対して kubectl delete の後に kubectl apply を行っても同じように機能します。注入が適用されるために、マニフェスト自体を変更する必要はまったくありません。）

サイドカーが実際に追加されたことを確認する

kubectl get pods -n default

サイドカーのある Pod は、READY の下で 1/1 ではなく 2/2 と表示されます。2 番目のコンテナが実際に何かを確認します。

kubectl describe pod <pod-name> -n default

出力の Containers の下に、アプリケーション自身のコンテナと並んで、istio-init init コンテナ（トラフィックの傍受を設定する）と istio-proxy コンテナが表示されるはずです。

namespace にラベルを付けずに、単一のワークロードを手動で注入する

namespace 全体をメッシュに含めたいわけではなく、特定の 1 つのワークロードだけを含めたい場合があります。istioctl kube-inject は、namespace 全体の自動注入に頼らず、適用前にマニフェストにサイドカーを追加します。

istioctl kube-inject -f my-deployment.yaml | kubectl apply -f -

これは、namespace のラベルが自動的にトリガーするものの手動版です。istioctl が生成したサイドカーの spec が、マニフェストにマージされ、1 ステップで適用されます。メッシュに含めるワークロードと含めないワークロードが混在する namespace で、namespace 全体にラベルを付けると意図した以上のものがメッシュに含まれてしまう場合に便利です。

アンインストール

istioctl uninstall --purge -y
kubectl delete namespace istio-system

--purge は、現在アクティブなもの以外のプロファイルのリソースも含め、インストールが追加したすべてを削除します。テスト中にプロファイルを切り替えた場合に、以前のインストールの残りではなく、きれいな削除をしたいときに重要です。