CLOUD SECURITY LAB

[Istio] え？私のistio-proxyはどこへ行ったの？🧐 – Kubernetesネイティブサイドカーの完全解析

—

by

cslab
in

こんにちは！今日は、KubernetesとIstio環境を扱っているエンジニアなら一度は経験したかもしれない「消えたサイドカーコンテナの謎」について深く掘り下げていきたいと思います。

Istioを注入（Injection）したのに、YAMLファイルにはプロキシコンテナが見えず、kubectlでは正常に見える場合？それはバグではありません。まさにKubernetesネイティブサイドカー機能が適用されたのです。この変化がなぜ起こり、どのような点が改善されたのかを詳しく見ていきましょう。🚀

image

1. 事件の発端：「コンテナの数が変です」🤔

Istioを使用する環境でPodをデプロイすると、通常は2/2の状態になります。

  1. 自分で作成したアプリケーションコンテナ
  2. Istioが注入したプロキシコンテナ (istio-proxy)

しかし、最近のバージョン（Istio 1.27+、K8s 1.29+）でデプロイされたPodのYAMLを詳しく見ると、非常に奇妙な点を発見します。

$ kubectl get pod details-v1
NAME                            READY   STATUS    RESTARTS   AGE
details-v1-766844796b-zmr86     2/2     Running   0          5m

👉 kubectlコマンドでは、確かにREADY 2/2と表示されます。つまり、2つのコンテナが正常に動作しているという意味です。

しかし、`kubectl get pod details-v1 -o yaml`で仕様を確認すると？

spec:
  containers:
  - name: details  # <--- あれ？コンテナが一つしかない？
    image: docker.io/istio/examples-bookinfo-details-v1:1.20.3
    ...

`spec.containers`セクションに`istio-proxy`がありません！明らかに実行中なのにYAML定義には見えない、この幽霊のような状況、一体何が起こっているのでしょうか？

2. 犯人は『initContainers』に隠れている！🕵️‍♂️

答えは`spec.containers`ではなく、`spec.initContainers`セクションにあります。アップロードされたYAMLファイルを詳しく見ると、その秘密が明らかになります。

  initContainers:
  - name: istio-init
    image: docker.io/istio/proxyv2:1.28.1
    # ... (iptablesを設定する一般的なinitコンテナ) ...

  - name: istio-proxy  # <--- ここに隠れていました！
    image: docker.io/istio/proxyv2:1.28.1
    restartPolicy: Always  # <--- ⭐ 핵심 포인트 ⭐

本来、initContainersはメインアプリケーションが起動する前に「初期化」作業だけを行い、終了（Completed）されるのがルールでした。しかし、ここでは`istio-proxy`が入っており、しかも終了せずに生き続けています。

その秘訣は、まさに`restartPolicy: Always`という設定にあります。

3. Kubernetesネイティブサイドカーとは何か？💡

これはKubernetes v1.28（Alpha）/ v1.29（Beta、デフォルト）から導入されたSidecarContainersという機能です。

過去の方法 (Old Sidecar)

以前は、istio-proxyを通常のcontainersリストに一緒に入れていました。しかし、この方法には致命的な欠点がありました。

  • 開始順序の保証不可：アプリケーションがプロキシより先に起動し、ネットワーク通信を試みると失敗するケースが発生しました。
  • 終了順序の問題 (Job)：バッチジョブ（Job）が終了しても、サイドカーであるistio-proxyが終了せず、Podが永遠にRunning状態のまま残る問題がありました。

現在の方法 (Native Sidecar)

今やKubernetesは、`initContainers`内で`restartPolicy: Always`を持つものを「サイドカーコンテナ」として認識します。

  1. 最初に開始される：メインアプリコンテナより必ず先に開始されます。
  2. 継続して実行される：初期化後も終了せず、メインアプリとライフサイクルを共にします。
  3. 最後に終了される：メインアプリが終了すると、Kubernetesが自動的にサイドカーを終了させます。（Jobの問題解決！）

4. なぜ突然変わったのか？（バージョン履歴）📅

この変化は、IstioとKubernetesのバージョンアップに伴い、自然に適用されたものです。

  • Istio 1.27以前：Native Sidecar機能はありましたが、オプションでした。（ENABLE_NATIVE_SIDECARS=true の設定が必要）
  • Istio 1.27以降：この機能がデフォルト（Default）になりました。
  • Kubernetesの条件：クラスターバージョンがv1.29以上である必要があります。（GKE、EKSなど最新バージョンはほとんどが該当）

現在あなたの環境は、「Istio 1.27以上 + K8s 1.29以上」の組み合わせであるため、別途設定することなく、この最新アーキテクチャが自動的に適用されています。🎉

5. 再び見る2/2の意味🔢

これで、`kubectl get pod`の2/2がどのように計算されるかが明確になります。

  1. メインコンテナ (details): `spec.containers`に定義 ➡️ +1
  2. ネイティブサイドカー (istio-proxy): `spec.initContainers`にあるが`restartPolicy: Always` ➡️ +1
  3. 通常のInit (istio-init): やるべきことを終えて終了（Completed） ➡️ 0

したがって、合計2となるのです。これは非常に正常で健全な状態ですので、ご安心ください！

6. 要約とまとめ📝

この変化は単なる構造変更ではなく、長年Kubernetesエンジニアを悩ませてきた「サイドカーのライフサイクル問題（Lifecycle Issue）」を根本的に解決した、非常に歓迎すべきアップデートです。

  • YAMLのcontainersにプロキシがない？ 👉 `initContainers`を確認してください。
  • `restartPolicy: Always`が見える？ 👉 おめでとうございます！最新のNative Sidecar機能を使用中です。
  • Job（バッチ）ワークロードを実行する際：もう`quitquitquit`のような裏技を使わなくても、プロキシがきれいに終了します。

最新の技術スタックをご利用の皆さん、変化したYAML構造に戸惑わず、この強力な機能を存分に活用してください！今日も楽しいクラウドの航海を！⛵️☁️

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です