サイドカーのインストール

 7分で読めます    ページテスト

インジェクション

Istio のすべての機能を活用するには、メッシュ内の Pod が Istio サイドカープロキシを実行している必要があります。

以下のセクションでは、Istio サイドカーを Pod に注入する 2 つの方法について説明します。Pod の名前空間で自動 Istio サイドカーインジェクションを有効にするか、istioctl コマンドを手動で使用します。

Pod の名前空間で有効にすると、自動インジェクションはアドミッションコントローラーを使用して Pod の作成時にプロキシ構成を注入します。

手動インジェクションでは、デプロイなどの構成を直接変更し、その中にプロキシ構成を追加します。

どちらを使用すればよいかわからない場合は、自動インジェクションをお勧めします。

自動サイドカーインジェクション

Istio が提供する ミューテーション Webhook アドミッションコントローラーを使用することで、該当する Kubernetes Pod にサイドカーを自動的に追加できます。

名前空間に istio-injection=enabled ラベルを設定し、インジェクション Webhook が有効になっている場合、その名前空間に作成された新しい Pod には自動的にサイドカーが追加されます。

手動インジェクションとは異なり、自動インジェクションはポッドレベルで発生します。デプロイメント自体には変更は見られません。代わりに、個々のポッド（kubectl describe経由）をチェックして、インジェクトされたプロキシを確認する必要があります。

アプリのデプロイ

curlアプリをデプロイします。デプロイメントとポッドの両方に単一のコンテナがあることを確認してください。

Zip
$ kubectl apply -f @samples/curl/curl.yaml@
$ kubectl get deployment -o wide
NAME    READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                    SELECTOR
curl    1/1     1            1           12s   curl         curlimages/curl           app=curl

$ kubectl get pod
NAME                    READY   STATUS    RESTARTS   AGE
curl-8f795f47d-hdcgs    1/1     Running   0          42s

default名前空間にistio-injection=enabledのラベルを付けます。

$ kubectl label namespace default istio-injection=enabled --overwrite
$ kubectl get namespace -L istio-injection
NAME                 STATUS   AGE     ISTIO-INJECTION
default              Active   5m9s    enabled
...

インジェクションはポッドの作成時に発生します。実行中のポッドをkillし、新しいポッドがインジェクトされたサイドカーとともに作成されることを確認します。元のポッドには1/1 READYコンテナがあり、インジェクトされたサイドカーを持つポッドには2/2 READYコンテナがあります。

$ kubectl delete pod -l app=curl
$ kubectl get pod -l app=curl
pod "curl-776b7bcdcd-7hpnk" deleted
NAME                     READY     STATUS        RESTARTS   AGE
curl-776b7bcdcd-7hpnk    1/1       Terminating   0          1m
curl-776b7bcdcd-bhn9m    2/2       Running       0          7s

インジェクトされたポッドの詳細な状態を表示します。インジェクトされたistio-proxyコンテナと対応するボリュームが表示されるはずです。

$ kubectl describe pod -l app=curl
...
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  ...
  Normal  Created    11s   kubelet            Created container istio-init
  Normal  Started    11s   kubelet            Started container istio-init
  ...
  Normal  Created    10s   kubelet            Created container curl
  Normal  Started    10s   kubelet            Started container curl
  ...
  Normal  Created    9s    kubelet            Created container istio-proxy
  Normal  Started    8s    kubelet            Started container istio-proxy

default名前空間のインジェクションを無効にし、新しいポッドがサイドカーなしで作成されることを確認します。

$ kubectl label namespace default istio-injection-
$ kubectl delete pod -l app=curl
$ kubectl get pod
namespace/default labeled
pod "curl-776b7bcdcd-bhn9m" deleted
NAME                     READY     STATUS        RESTARTS   AGE
curl-776b7bcdcd-bhn9m    2/2       Terminating   0          2m
curl-776b7bcdcd-gmvnr    1/1       Running       0          2s

インジェクションポリシーの制御

上記の例では、名前空間レベルでインジェクションを有効および無効にしました。インジェクションは、ポッドにsidecar.istio.io/injectラベルを設定することで、ポッドごとに制御することもできます。

リソースラベル有効な値無効な値
名前空間istio-injectionenableddisabled
ポッドsidecar.istio.io/inject"true""false"

コントロールプレーンリビジョンを使用している場合は、代わりに一致するistio.io/revラベルによってリビジョン固有のラベルが使用されます。たとえば、canaryという名前のリビジョンの場合。

リソース有効なラベル無効なラベル
名前空間istio.io/rev=canaryistio-injection=disabled
ポッドistio.io/rev=canarysidecar.istio.io/inject="false"

istio-injectionラベルとistio.io/revラベルが同じ名前空間に両方存在する場合、istio-injectionラベルが優先されます。

インジェクターは次のロジックで構成されています。

  1. いずれかのラベル（istio-injectionまたはsidecar.istio.io/inject）が無効になっている場合、ポッドはインジェクトされません。
  2. いずれかのラベル（istio-injectionまたはsidecar.istio.io/injectまたはistio.io/rev）が有効になっている場合、ポッドはインジェクトされます。
  3. どちらのラベルも設定されていない場合、.values.sidecarInjectorWebhook.enableNamespacesByDefaultが有効になっている場合にポッドはインジェクトされます。これはデフォルトでは有効になっていないため、一般的にこれはポッドがインジェクトされないことを意味します。

手動サイドカーインジェクション

デプロイメントを手動でインジェクトするには、istioctl kube-injectを使用します。

Zip
$ istioctl kube-inject -f @samples/curl/curl.yaml@ | kubectl apply -f -
serviceaccount/curl created
service/curl created
deployment.apps/curl created

デフォルトでは、これはクラスタ内の構成を使用します。あるいは、構成のローカルコピーを使用してインジェクションを実行することもできます。

$ kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.config}' > inject-config.yaml
$ kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.values}' > inject-values.yaml
$ kubectl -n istio-system get configmap istio -o=jsonpath='{.data.mesh}' > mesh-config.yaml

入力ファイルに対してkube-injectを実行し、デプロイします。

Zip
$ istioctl kube-inject \
    --injectConfigFile inject-config.yaml \
    --meshConfigFile mesh-config.yaml \
    --valuesFile inject-values.yaml \
    --filename @samples/curl/curl.yaml@ \
    | kubectl apply -f -
serviceaccount/curl created
service/curl created
deployment.apps/curl created

READY列の下に2/2で、サイドカーがcurlポッドにインジェクトされていることを確認します。

$ kubectl get pod  -l app=curl
NAME                     READY   STATUS    RESTARTS   AGE
curl-64c6f57bc8-f5n4x    2/2     Running   0          24s

インジェクションのカスタマイズ

一般的に、ポッドはistio-sidecar-injector ConfigMapで構成されているサイドカーインジェクションテンプレートに基づいてインジェクトされます。ポッドごとの構成は、個々のポッドでこれらのオプションをオーバーライドするために使用できます。これは、ポッドにistio-proxyコンテナを追加することで行われます。サイドカーインジェクションは、ここで定義された構成をデフォルトのインジェクションテンプレートのオーバーライドとして扱います。

これらの設定をカスタマイズする際には注意が必要です。これにより、結果のPodを完全にカスタマイズでき、サイドカーコンテナが正常に機能しなくなるような変更も加えられる可能性があります。

たとえば、次の構成は、CPUリクエストの削減、ボリュームマウントの追加、preStopフックの追加など、さまざまな設定をカスタマイズします。

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "100m"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["curl", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

一般的に、ポッド内の任意のフィールドを設定できます。ただし、特定のフィールドについては注意が必要です。

  • Kubernetesでは、インジェクションが実行される前にimageフィールドを設定する必要があります。特定のイメージを設定してデフォルトのイメージをオーバーライドできますが、imageをautoに設定して、サイドカーインジェクターが使用するイメージを自動的に選択するようにすることをお勧めします。
  • Podの一部のフィールドは、関連する設定に依存しています。たとえば、CPUリクエストはCPU制限よりも小さくなければなりません。両方のフィールドが一緒に構成されていない場合、ポッドが起動に失敗する可能性があります。
  • securityContext.RunAsUserおよびsecurityContext.RunAsGroupフィールドは、場合によっては尊重されない場合があります。たとえば、TPROXYモードを使用する場合、サイドカーはユーザー0として実行する必要があるためです。これらのフィールドを誤ってオーバーライドすると、トラフィックが失われる可能性があり、細心の注意を払って行う必要があります。

さらに、特定のフィールドはポッドのアノテーションによって構成可能ですが、設定をカスタマイズするには上記の方法を使用することをお勧めします。特定のアノテーションについては、さらに注意が必要です。

  • sidecar.istio.io/proxyCPUが設定されている場合は、必ずsidecar.istio.io/proxyCPULimitを明示的に設定してください。そうしないと、サイドカーのcpu制限が無制限に設定されます。
  • sidecar.istio.io/proxyMemoryが設定されている場合は、必ずsidecar.istio.io/proxyMemoryLimitを明示的に設定してください。そうしないと、サイドカーのmemory制限が無制限に設定されます。

たとえば、以下に示す不完全なリソースアノテーション構成と、対応するインジェクトされたリソース設定をご覧ください。

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyMemoryLimit: "5Gi"

spec:
  containers:
  - name: istio-proxy
    resources:
      limits:
        memory: 5Gi
      requests:
        cpu: 200m
        memory: 5Gi
      securityContext:
        allowPrivilegeEscalation: false

カスタムテンプレート（実験的）

完全にカスタムのテンプレートをインストール時に定義することもできます。たとえば、GREETING環境変数をistio-proxyコンテナにインジェクトするカスタムテンプレートを定義するには、次のようにします。

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio
spec:
  values:
    sidecarInjectorWebhook:
      templates:
        custom: |
          spec:
            containers:
            - name: istio-proxy
              env:
              - name: GREETING
                value: hello-world

ポッドはデフォルトで、自動的に作成されるsidecarインジェクションテンプレートを使用します。これは、inject.istio.io/templatesアノテーションでオーバーライドできます。たとえば、デフォルトのテンプレートとカスタマイズを適用するには、inject.istio.io/templates=sidecar,customを設定できます。

sidecarに加えて、ゲートウェイデプロイメントへのプロキシインジェクションをサポートするために、gatewayテンプレートがデフォルトで提供されます。

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

フィードバックありがとうございます！