Istio アドオンのインストール

コミュニティー Istio の代わりに、マネージド Istio アドオンをインストールできます。

開始前に

• IBM Cloud Kubernetes Service の IAM サービスアクセスロールが Writer または Manager IBM Cloud であることを確認してください。
• それぞれが 4 コアと 16 GB のメモリー (b3c.4x16) 以上を備えた、少なくとも 3 つのワーカー・ノードのある標準 Kubernetes クラスターを作成します。
• クラスターにおいて管理対象 Istio アドオンと同時にコミュニティー Istio を実行することはできません。 既存のクラスターを使用している場合に、IBM Helm チャートまたは別の方法を使用して、そのクラスターに Istio を既にインストールしている場合は、その Istio インストール済み環境をクリーンアップしてください。
• クラシック・マルチゾーン・クラスター: IBM Cloud インフラストラクチャー・アカウントに対して Virtual Routing and Forwarding(VRF) を有効にしていることを確認します。 VRF を有効にするには、VRF の有効化を参照してください。 VRF が既に有効になっているかどうかを確認するには、ibmcloud account show コマンドを使用します。 VRF を有効にできない、または有効にしない場合は、VLAN スパンニングを有効にします。 このアクションを実行するには、 ネットワークVLANスパニングインフラストラクチャの管理権限が必要です。 VLANスパニングがすでに有効になっているかどうかを確認するには、 ibmcloud ks vlan spanning get --region <region> コマンドを 使用します。

Istio アドオンの更新

Istio アドオンを更新します。これは、 IBM Cloud によってテストされ、 IBM Cloud Kubernetes Serviceでの使用が承認されています。

マネージド・アドオンによってインストールされたバージョンの Istio を更新する際は、 istioctl を使用しないでください。 Istio マネージド・アドオンの更新には、Istio バージョンの更新も含まれる、以下の手順のみを使用してください。

サポートされないバージョンの Istio アドオンから更新するには、 Istio コンポーネント を、 IBM Cloud Kubernetes Serviceでサポートされる最新のパッチ・バージョンに更新します。

Istio インストール済み環境のカスタマイズ

managed-istio-custom 構成マップ・リソースを編集することによって、一連の Istio 構成オプションをカスタマイズできます。 これらの設定には、コントロール・プレーンおよびサービス・メッシュのモニタリング、ロギング、およびネットワーキングに対する追加の制御が含まれます。

1. managed-istio-custom ConfigMap リソースを説明し、その内容とインライン・ドキュメントを確認する。

   kubectl describe cm managed-istio-custom -n ibm-operators
   

2. managed-istio-custom 構成マップ・リソースを編集します。

   kubectl edit cm managed-istio-custom -n ibm-operators
   

3. data セクションで、以下の 1 つ以上の構成オプションの <key>: "<value>" ペアを追加します。

   istio-components-pilot-requests-cpu

   デフォルト値: "500m"

   istiod コンポーネントポッドに対して、 CPU で CPU リクエストを構成する。 milli この値を変更するときには注意してください。 この値を低く設定しすぎると、コントロールプレーンが正常に動作しなくなる可能性があり、高く設定しすぎると、 istiod ポッドがスケジューリングされなくなる可能性がある。

   istio-global-logging-level

   デフォルト値: "default:info"

   コントロール・プレーン・コンポーネントのログのスコープ、およびログ・メッセージのレベルを定義します。 スコープは、コントロール・プレーン・コンポーネント内の機能領域を表します。各スコープは特定のログ情報レベルをサポートします。 カテゴリー化されていないログ・メッセージ用の default ロギング・スコープは、基本の info レベルのコントロール・プレーンのすべてのコンポーネントに適用されます。

   個々のコンポーネント・スコープのログ・レベルを指定するには、スコープとレベルのコンマ区切りリストを入力します (例: "<scope>:<level>,<scope>:<level>")。 各制御プレーン・コンポーネントのスコープとログ・メッセージの情報レベルのリストについては、 Istio コンポーネント・ロギングのドキュメントを参照してください。 データプレーンのログレベルを変更するには、 istioctl proxy-config log <pod> --level <level> コマンドを使用します。

   istio-global-outboundTrafficPolicy-mode

   デフォルト値: "ALLOW_ANY"

   デフォルトでは、サービス・メッシュからのアウトバウンド・トラフィックはすべて許可されます。 サービス・レジストリー内に定義されていないホスト、またはサービス・メッシュ内に ServiceEntry が含まれないホストへのサービス・メッシュからのアウトバウンド・トラフィックをブロックするには、REGISTRY_ONLY に設定します。

   istio-egressgateway-public-1-enabled

   デフォルト値: "true"

   デフォルトの Istio egress gateway を無効にするには、 "false" に設定する。 例えば、代わりにカスタム Egress ゲートウェイを作成することができます。

   istio-global-proxy-accessLogFile

   デフォルト値: ""

   Envoy プロキシーは、標準出力にアクセス情報を出力します。 これらのログは、Ingress または Egress に関する問題をデバッグする際に役立ちます。 Envoy コンテナーに対して kubectl logs コマンドを実行するときにこのアクセス情報を表示するには、"/dev/stdout" に設定します。

   istio-ingressgateway-public-1|2|3-enabled

   デフォルト値: ゾーン 1 における "true" のみ。

   アプリの可用性を高めるには、"true" に、パブリック istio-ingressgateway ロード・バランサーを作成するゾーンごとに設定します。 デフォルトの Ingress ゲートウェイの代わりにカスタム Ingress ゲートウェイを使用するには、"false" に設定することができます。

   istio-ingressgateway-zone-1|2|3

   デフォルト値: "<zone>"

   ワーカーノードが配置されるゾーンで、アドオンをインストールしたときや、Istioのパッチアップデートを適用したときに自動的に入力されます。 これらのフィールドにより、クラスターのゾーンが istio-ingressgateway-public-1|2|3-enabled フィールドに適用されます。 この設定に表示されているゾーンがクラスタ・ゾーンと同期していない場合は、 kubectl delete pod -n ibm-system -l addon.cleanup=istio および kubectl delete job -n ibm-system -l addon.cleanup=istio を実行することで、自動配置ジョブを再起動できることに注意してください。

   istio-monitoring-telemetry

   デフォルト値: "true"

   テレメトリー・メトリックと Prometheus のサポートは、デフォルトで有効になっています。 テレメトリー・メトリックに関連するすべてのパフォーマンス問題を削除し、すべてのモニタリングを無効にするには、"false" に設定します。

   istio-meshConfig-enableTracing

   デフォルト値: "true"

   デフォルトでは、Istioは100リクエストのうち1リクエストについてトレーススパンを生成する。 トレース・スパンを無効にするには、"false" に設定します。

   istio-pilot-traceSampling

   デフォルト値: "1.0"

   デフォルトでは、Istio は 100 個の要求のうち 1 つの要求に対してトレース・スパンを生成します。これは 1% のサンプリング・レートです。 より多くのトレース・スパンを生成するには、パーセンテージ値を増やします。

   istio-components-pilot-hpa-maxReplicas

   デフォルト値: "5"

   デフォルトでは、Istioは istiod 、デフォルトの水平ポッドオートスケーラー（HPA）の最大ポッドを5に設定する。 istiod 、コンフィギュレーションを更新するためにリソースを増やす必要があるような大規模なサービスメッシュでない限り、この値を増やさないでください。

   例えば、構成マップは以下の例のようになります。

   apiVersion: v1
   data:
     istio-ingressgateway-zone-1: dal10
     <key: value> # such as istio-egressgateway-public-1-enabled: "false"
   kind: ConfigMap
   metadata:
     name: managed-istio-custom
     namespace: ibm-operators
   

   構成マップにこの表のオプションがありませんか? 構成マップにユーザー定義の値が含まれているため、時間経過に伴いリリースされるオプションに照らして構成マップが更新されていません。 ここでは、構成マップのコピーをバックアップし、クラスターからその構成マップを削除できます。 約 5 分経過すると、新しいオプションが含まれるデフォルトの構成マップがクラスターに作成されます。 その後、以前に構成した設定をバックアップからこのデフォルト構成マップにコピーし、新しい設定を構成し、変更を適用できます。

4. 構成ファイルを保存して閉じます。

5. istio-global-logging-level または istio-global-proxy-accessLogFile の設定を変更した場合、データ・プレーン・ポッドを再始動して、変更を適用する必要があります。

   1. istio-system 名前空間に含まれていないすべてのデータ・プレーン・ポッドのリストを取得します。

      istioctl version --short=false | grep "data plane version" | grep -v istio-system
      

      出力例

      data plane version: version.ProxyInfo{ID:"test-6f86fc4677-vsbsf.default", IstioVersion:"1.23.5"}
      data plane version: version.ProxyInfo{ID:"rerun-xfs-f8958bb94-j6n89.default", IstioVersion:"1.23.5"}
      data plane version: version.ProxyInfo{ID:"test2-5cbc75859c-jh6bx.default", IstioVersion:"1.23.5"}
      data plane version: version.ProxyInfo{ID:"minio-test-78b5d4597d-hkpvt.default", IstioVersion:"1.23.5"}
      data plane version: version.ProxyInfo{ID:"sb-887f89d7d-7s8ts.default", IstioVersion:"1.23.5"}
      data plane version: version.ProxyInfo{ID:"gid-deployment-5dc86db4c4-kdshs.default", IstioVersion:"1.23.5"}
      

   2. 各ポッドを削除して、再始動します。 前のステップの出力では、ポッド名と名前空間が各項目に data plane version: version.ProxyInfo{ID:"<pod_name>.<namespace>", IstioVersion:"1.23.5"} としてリストされています。

      kubectl delete pod <pod_name> -n <namespace>
      

ConfigMap

configmap に追加した設定を変更したい場合は、パッチ・スクリプトを使用します。 例えば、istio-global-proxy-accessLogFile: "/dev/stdout" 設定を追加した後で、"" に戻す場合は、kubectl patch cm managed-istio-custom -n ibm-operators --type='json' -p='[{"op": "add", "path": "/data/istio-global-proxy-accessLogFile", "value":""}]' を実行します。

カスタマイズ・セットアップのデバッグが必要ですか？

addon-istio-operator （Istio バージョン 1.10 以降）または managed-istio-operator （Istio バージョン 1.9 以前）ポッドのログを、 kubectl logs -n ibm-operators -l name=managed-istio-operator を実行して確認する。 行われたすべてのカスタム Istio の変更は、Istio オペレーターにより検証および調整されます。

Istio アドオンを無効化する場合、アンインストール中に managed-istio-custom 構成マップが削除されることはありません。 Istio アドオンを再有効化すると、カスタマイズした構成マップがインストール中に適用されます。 Istio を後からインストールするときにカスタム設定を再使用しない場合は、kubectl delete cm -n ibm-operators managed-istio-custom を実行して Istio アドオンを無効にした後で configmap を削除する必要があります。 Istio アドオンを再有効化するときに、インストール中にデフォルトの構成マップが適用されます。

Istio アドオンをアンインストールしています

Istioでの作業が終了したら、クラスタ内のIstioリソースをクリーンアップし、Istioアドオンをアンインストールすることができます。

kubectl delete deployment -n ibm-operators addon-istio-operator --ignore-not-found=true
kubectl delete serviceaccount -n ibm-operators addon-istio-operator --ignore-not-found=true
kubectl delete clusterrolebinding addon-istio-operator --ignore-not-found=true
kubectl delete clusterrole addon-istio-operator --ignore-not-found=true

クラスター内にインストールされている他の Istio のアンインストール

IBM Helm チャートまたは別の方法を使用して既にクラスターに Istio をインストールした場合は、その Istio インストール済み環境をクリーンアップしてから、クラスター内のマネージド Istio アドオンを有効にしてください。 クラスター内に Istio が既に存在しているかどうかを確認するには、kubectl get namespaces を実行し、出力で istio-system 名前空間を探します。

• IBM Cloud Istio Helm チャートを使用して Istio をインストールした場合は、以下のようにします。

  1. Istio Helm デプロイメントをアンインストールします。

     helm del istio --purge
     

  2. Helm 2.9 以前を使用した場合は、さらにジョブ・リソースを削除します。

     kubectl -n istio-system delete job --all
     

  3. アンインストール処理には、最大 10 分かかります。 Istio マネージド・アドオンをクラスターにインストールする前に、kubectl get namespaces を実行して、istio-system 名前空間が削除されたことを確認します。

• Istioを手動でインストールした場合、またはIstioコミュニティ Helm チャートを使用した場合は、 Istioアンインストールドキュメントを参照してください。

• 以前にクラスター内に BookInfo をインストールした場合は、それらのリソースをクリーンアップします。

  1. ディレクトリーを Istio ファイルの場所に切り替えます。

     cd <filepath>/istio-1.23.5
     

  2. クラスター内の BookInfo サービス、ポッド、デプロイメントをすべて削除します。

     samples/bookinfo/platform/kube/cleanup.sh
     

  3. アンインストール処理には、最大 10 分かかります。 Istio マネージド・アドオンをクラスターにインストールする前に、kubectl get namespaces を実行して、istio-system 名前空間が削除されたことを確認します。

Istio アドオンのトラブルシューティング

マネージド Istio アドオンの使用時によく起きる問題の解決方法については、マネージド・アドオンのトラブルシューティングを参照してください。

ステップ2：Istioオペレータのスケールダウン

Istioオペレータのデプロイメントをスケールダウンする。

以下のコマンドを実行します。

kubectl scale deployment -n ibm-operators addon-istio-operator --replicas=0

ステップ 3: リソースの保存

istio-system ネームスペースで作成または変更したリソースと、カスタム・リソース定義 （CRD）によって自動的に生成されたすべての Kubernetes リソースを保存します。

1. managed-istio-custom ConfigMap を保存して、問題のトラブルシューティングを行ったり、後でアドオンを再インストールしたりします。

   kubectl get cm -n ibm-operators managed-istio-custom -o yaml > Customizations.yaml
   

2. すべての IstioOperator CR (IOP) を保存します。

   • IOP リソースをリストします。

     kubectl get iop -A
     

   • リストアップされた各IOPリソースについて、ファイナライザを削除する。 managed-istio IOP の使用例:

     kubectl patch -n ibm-operators istiooperator/managed-istio --type json --patch='[ { "op": "remove", "path": "/metadata/finalizers" } ]'
     

   • リストされた IOP リソースごとに、それぞれをファイルに保管します。

     kubectl get iop -n <IOP_namespace> <IOP_name> -o yaml > <IOP_name>.yaml
     

3. 10 分間待ってから、次のステップに進みます。

ステップ 4: IOPS のインストーラーの変更

カスタム Ingress ゲートウェイなど、すべての Istio オペレーター (IOP) リソースを削除します。

1. istioctl cliツールが必要なパッチバージョンであることを確認してください。

   istioctl version
   

2. 前のステップで保存した IOP ファイルごとに、 upgrade コマンドを実行します。

   istioctl upgrade -f <filename>.yaml
   

ステップ5：IstioオペレータとIOPの削除

Istioオペレータのデプロイメント、サービス・アカウント、クラスタ・ロール・バインディング、クラスタ・ロール、およびすべてのIOPを削除します。

1. 以下のコマンドを実行して、istio operator deploymentを削除します：

   kubectl delete deployment -n ibm-operators addon-istio-operator --ignore-not-found=true
   kubectl delete serviceaccount -n ibm-operators addon-istio-operator --ignore-not-found=true
   kubectl delete clusterrolebinding addon-istio-operator --ignore-not-found=true
   kubectl delete clusterrole addon-istio-operator --ignore-not-found=true
   

2. IOPを削除する。

   • IOP リソースをリストします。

     kubectl get iop -A
     

   • リストされた各IOPリソースについて、それを削除する：

     kubectl delete IstioOperator <resource_name> -n <namespace>
     

ステップ6：ConfigMapの削除

ConfigMap は以前に保存されているため、削除できます。

managed-istio-custom ConfigMapを削除します。

kubectl delete cm -n ibm-operators managed-istio-custom

アドオンの削除が完了しました。必要に応じて、引き続きコミュニティー Istio を使用してアップグレードすることができます。