プラットフォーム固有の前提条件

 約5分    ページテスト

このドキュメントでは、アンビエントモードでIstioをインストールするためのプラットフォームまたは環境固有の前提条件について説明します。

プラットフォーム

特定のKubernetes環境では、サポートするためにさまざまなIstio設定オプションを設定する必要があります。

Google Kubernetes Engine (GKE)

GKEにおいて、system-node-critical `priorityClassName`を持つIstioコンポーネントは、ResourceQuotaが定義されている名前空間のみにインストールできます。GKEのデフォルトでは、`node-critical`クラスのResourceQuotaが定義されているのは`kube-system`のみです。Istio CNIノードエージェントと`ztunnel`はどちらも`node-critical`クラスを必要とするため、GKEでは、どちらのコンポーネントも以下のいずれかの方法でインストールする必要があります。

  • `kube-system`（`istio-system`ではない）にインストールする
  • ResourceQuotaを手動で作成した別の名前空間（例えば`istio-system`）にインストールする
apiVersion: v1
kind: ResourceQuota
metadata:
  name: gcp-critical-pods
  namespace: istio-system
spec:
  hard:
    pods: 1000
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values:
      - system-node-critical

Amazon Elastic Kubernetes Service (EKS)

EKSを使用している場合

  • AmazonのVPC CNIを使用している場合
  • Pod ENIトランキングを有効にしている場合
  • かつ SecurityGroupPolicy を介してEKS podアタッチ型セキュリティグループを使用している場合

`POD_SECURITY_GROUP_ENFORCING_MODE`を明示的に`standard`に設定する必要があります。設定しないと、（デフォルトでVPC CNIによってすべてのポリシー適用から黙って除外されている）Podのヘルスプローブが失敗します。これは、IstioがkubeletヘルスプローブにリンクローカルSNATアドレスを使用しており、AmazonのVPC CNIがそれを認識しておらず、VPC CNIにリンクローカルアドレスをポリシー適用から除外するオプションがないためです。

Pod ENIトランキングが有効になっているかどうかを確認するには、以下のコマンドを実行します。

$ kubectl set env daemonset aws-node -n kube-system --list | grep ENABLE_POD_ENI

クラスタにPodアタッチ型セキュリティグループがあるかどうかを確認するには、以下のコマンドを実行します。

$ kubectl get securitygrouppolicies.vpcresources.k8s.aws

`POD_SECURITY_GROUP_ENFORCING_MODE=standard`を設定するには、以下のコマンドを実行し、影響を受けるPodを再起動します。

$ kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard

k3d

デフォルトのFlannel CNIを使用するk3dを使用する場合、インストールコマンドに正しい`platform`値を追加する必要があります。k3dはCNIの設定とバイナリに非標準の場所を使用するため、Helmのオーバーライドが必要です。

  1. Istioのイングレスゲートウェイと競合しないように、Traefikが無効になっているクラスタを作成します。

    $ k3d cluster create --api-port 6550 -p '9080:80@loadbalancer' -p '9443:443@loadbalancer' --agents 2 --k3s-arg '--disable=traefik@server:*'

  2. Istioチャートをインストールする際に`global.platform=k3d`を設定します。例:

    $ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=k3d --wait

K3s

K3sとそのバンドルされたCNIのいずれかを使用する場合、インストールコマンドに正しい`platform`値を追加する必要があります。K3sはCNIの設定とバイナリに非標準の場所を使用するため、Helmのオーバーライドが必要です。デフォルトのK3sパスについては、Istioは`global.platform`値に基づいた組み込みのオーバーライドを提供しています。

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=k3s --wait

ただし、K3sのドキュメントによると、これらの場所はK3sでオーバーライドされる場合があります。カスタムのバンドルされていないCNIを使用するK3sを使用している場合は、それらのCNIの正しいパス（例：`/etc/cni/net.d`）を手動で指定する必要があります。詳細についてはK3sのドキュメントを参照してください。例:

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --wait --set cniConfDir=/var/lib/rancher/k3s/agent/etc/cni/net.d --set cniBinDir=/var/lib/rancher/k3s/data/current/bin/

MicroK8s

MicroK8sにIstioをインストールする場合は、インストールコマンドに正しい`platform`値を追加する必要があります。MicroK8sはCNIの設定とバイナリに非標準の場所を使用します。例:

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=microk8s --wait

minikube

minikubeとDockerドライバを使用する場合、インストールコマンドに正しい`platform`値を追加する必要があります。Dockerを使用するminikubeは、コンテナの非標準のバインドマウントパスを使用するためです。例:

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=minikube --wait"

Red Hat OpenShift

OpenShiftでは、`ztunnel`と`istio-cni`コンポーネントを`kube-system`名前空間にインストールし、すべてのチャートで`global.platform=openshift`を設定する必要があります。

helmを使用する場合は、ターゲット名前空間と`global.platform`の値を直接設定できます。

istioctlを使用する場合は、同じことを行うために`openshift-ambient`という特別なプロファイルを使用する必要があります。

$ helm install istio-cni istio/cni -n kube-system --set profile=ambient --set global.platform=openshift --wait

CNIプラグイン

特定のCNIプラグインを使用するすべてのプラットフォームに、以下の設定が適用されます。

Cilium

  1. Ciliumは現在、デフォルトで他のCNIプラグインとその設定をプロアクティブに削除するため、チェーニングを適切にサポートするには、`cni.exclusive = false`で設定する必要があります。詳細については、Ciliumのドキュメントを参照してください。

  2. CiliumのBPFマスカレードは現在デフォルトで無効になっており、KubernetesのヘルスチェックでIstioがリンクローカルIPを使用することに問題があります。`bpf.masquerade=true`でBPFマスカレードを有効にすることは現在サポートされておらず、Istio ambientでのPodヘルスチェックが機能しなくなります。Ciliumのデフォルトのiptablesマスカレード実装は引き続き正常に機能するはずです。

  3. CiliumがノードIDを管理し、ノードレベルのヘルスプローブをPodに内部的に許可リストに追加する方法により、Istioをambientモードで動作するCilium CNIインストールの下にデフォルト拒否の`NetworkPolicy`を適用すると、（デフォルトでCiliumによってすべてのポリシー適用から黙って除外されている）`kubelet`ヘルスプローブがブロックされます。これは、IstioがkubeletヘルスプローブにリンクローカルSNATアドレスを使用しており、Ciliumがそれを認識しておらず、Ciliumにリンクローカルアドレスをポリシー適用から除外するオプションがないためです。

    これは、以下の`CiliumClusterWideNetworkPolicy`を適用することで解決できます。

    apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: "allow-ambient-hostprobes"
spec:
  description: "Allows SNAT-ed kubelet health check probes into ambient pods"
  enableDefaultDeny:
    egress: false
    ingress: false
  endpointSelector: {}
  ingress:
  - fromCIDR:
    - "169.254.7.127/32"

    このポリシーのオーバーライドは、クラスタに他のデフォルト拒否の`NetworkPolicies`または`CiliumNetworkPolicies`を既に適用している場合にのみ必要です。

    詳細については、issue #49277とCiliumClusterWideNetworkPolicyを参照してください。

この情報は役に立ちましたか？
改善のための提案はありますか？

ご意見ありがとうございます！