KubernetesでEnvoyサイドカーを構築する実践ガイド

2026年7月2日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 KubernetesでEnvoyサイドカーを構築する実践ガイド
2 Envoyプロキシとサイドカー注入の概要
- 2.1 サービスメッシュにおけるEnvoyの役割
- 2.2 サイドカー注入の仕組みとメリット
3 Kubernetesでのサイドカー構成方法
- 3.1 DeploymentとInitContainerの定義
4 ロギングと監視のためのEnvoyフィルタ
- 4.1 アクセスログの設定例
5 Istioとの関係と併用時の設計ガイド
- 5.1 EnvoyとIstioのアーキテクチャ比較
- 5.2 共存環境での構成制限
6 高可用性確保のためのベストプラクティス
- 6.1 リソース制限とHealth Check設定
7 検証環境構築とトラブルシューティング
- 7.1 ローカルクラスタでのデモ手順
- 7.2 Envoy Admin APIによるステータス確認
8 ベストプラクティスと設計時の注意点
- 8.1 サイドカー注入における設計ルール
- 8.2 ロギング・監視構成の最適化
9 検証・トラブルシューティングガイド
- 9.1 ローカル環境での検証フロー
- 9.2 トラブルシューティング手順
10 結論と今後の方向性
- 10.1 結論の要点

スポンサードリンク

KubernetesでEnvoyサイドカーを構築する実践ガイド

Kubernetes環境でEnvoyプロキシをサイドカーとして導入し、サービスメッシュのデータプレーン構成を検証する方法について解説します。マイクロサービスアーキテクチャでは、通信制御や可観測性向上のためにサイドカー注入が不可欠です。本記事では、Envoy特有の設定手順とベストプラクティスに焦点を当てて進めます。

Envoyプロキシとサイドカー注入の概要

Kubernetesマイクロサービス環境において、Envoyは通信の中継役としてデータプレーンを構築する鍵となる技術です。その特徴的な仕組みとメリットについて解説します。

サービスメッシュにおけるEnvoyの役割

Envoyプロキシは、リバースプロキシ機能に加え、トラフィック制御・ロギング・監視を一括して行うことができます。サービスメッシュで用いられる際には、各マイクロサービスに注入されるサイドカーとして動作します。これにより、通信の可視化やセキュリティポリシーの統一的な適用が可能になります。

サイドカー注入の仕組みとメリット

サイドカー注入は、Podレベルでコンテナを追加する手法です。Envoyはアプリケーションコンテナと並行して動作し、通信を経由して制御します。この方法により、アプリケーション自体を変更せずに機能拡張が可能です。

Kubernetesでのサイドカー構成方法

KubernetesでEnvoyをサイドカーとして注入する際の具体的な手順とYAMLテンプレートを紹介します。デプロイメント定義や自動注入ツールの使い方まで網羅します。

DeploymentとInitContainerの定義

Envoyをサイドカーとして実装するには、Deploymentリソースに追加コンテナを定義します。以下は基本的なYAMLテンプレートです：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: envoy-sidecar-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest
        ports:
        - containerPort: 8080
      - name: envoy
        image: envoyproxy/envoy:v1.25.0
        args:
        - &quot;--configPath=/etc/envoy/config.yaml&quot;
        volumeMounts:
        - name: config-volume
          mountPath: /etc/envoy
      volumes:
      - name: config-volume
        configMap:
          name: envoy-config

apiVersion: apps/v1

kind: Deployment

metadata:

name: envoy-sidecar-demo

spec:

replicas: 2

selector:

matchLabels:

app: myapp

template:

metadata:

labels:

app: myapp

spec:

containers:

- name: myapp

image: myapp:latest

ports:

- containerPort: 8080

- name: envoy

image: envoyproxy/envoy:v1.25.0

args:

- "--configPath=/etc/envoy/config.yaml"

volumeMounts:

- name: config-volume

mountPath: /etc/envoy

volumes:

- name: config-volume

configMap:

name: envoy-config

このように、アプリケーションコンテナとEnvoyコンテナを並列して定義します。volumeMountsで配置されたコンフィグファイル（例：config.yaml）を使用することで、ルーティングやセキュリティ設定を柔軟にカスタマイズできます。

ロギングと監視のためのEnvoyフィルタ

Envoyはアクセスログの出力先指定や、Prometheusとの連携によるメトリクス収集を通じて、監視・分析を強化します。以下に具体的な設定例を紹介します。

アクセスログの設定例

Envoyのコンフィグファイルでaccess_logディレクティブを使用し、アクセスログの出力先を指定できます。例えば：

access_log:
  - name: accesslog
    sink: &quot;/var/log/envoy/access.log&quot;
    format: |
      [REQUEST] &quot;%REQ(:METHOD)% %REQ(FULL_PATH)% %REQ(PROTOCOL)%&quot; %RESPONSE_CODE% &quot;%DOWNSTREAM_REMOTE_ADDRESS%&quot; &quot;%UPSTREAM_LOCAL_ADDRESS%&quot;

access_log:

- name: accesslog

sink: "/var/log/envoy/access.log"

format: |

[REQUEST] "%REQ(:METHOD)% %REQ(FULL_PATH)% %REQ(PROTOCOL)%" %RESPONSE_CODE% "%DOWNSTREAM_REMOTE_ADDRESS%" "%UPSTREAM_LOCAL_ADDRESS%"

この設定により、/var/log/envoy/access.logにアクセスログが記録されます。Kubernetesのロギング仕組み（例：EFKスタック）と連携させることで、リアルタイム監視が可能です。

Istioとの関係と併用時の設計ガイド

EnvoyはIstioのデータプレーンに使われますが、単体でもサービスメッシュを構築できます。 ここではIstioとの比較や併用時の設計上の注意点を整理します。

EnvoyとIstioのアーキテクチャ比較

項目	Envoy単体利用	Istio利用時	補足
データプレーン	✅ 利用可能	✅ 利用可能	Envoyをカスタムで制御可能
コントロールプレーン	❌ 必須	✅ Istioが提供	Pilot（Istio 1.5以降ではControllerへ移行）が必要
自動注入機能	❌ 利用不可	✅ Istio Sidecar Injector利用	マニフェストでの手動注入可能

注意：Istio 1.6以降ではPilotは非推奨となり、Controllerが代替として使用されます。併用時は最新バージョンのドキュメントを参照してください。

共存環境での構成制限

Istioと併用する際には、Envoyのインジェクター（Sidecar Injector）が衝突しないように注意が必要です。 Istioはデフォルトでサイドカーを自動注入しますが、手動注入を行うと両者が競合してしまう可能性があります。

高可用性確保のためのベストプラクティス

Kubernetes環境では、Envoyサイドカーに高い信頼性と安定性が求められます。リソース制限やセキュリティポリシーを適切に設定することで、高可用な構成を実現できます。

リソース制限とHealth Check設定

Podのresources.limitsでCPU・メモリ使用量を制限し、Envoyが過負荷になることを防ぎます。

resources:
  limits:
    memory: &quot;512Mi&quot;
    cpu: &quot;500m&quot;

resources:

limits:

memory: "512Mi"

cpu: "500m"

また、Health CheckはlivenessProbeとreadinessProbeで設定します。例えば：

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 8080

livenessProbe:

httpGet:

path: /healthz

port: 8080

initialDelaySeconds: 10

readinessProbe:

httpGet:

path: /ready

port: 8080

検証環境構築とトラブルシューティング

Minikubeなどでのローカルクラスタで検証し、Envoy Admin APIを使ってステータスを確認する方法を紹介します。

ローカルクラスタでのデモ手順

Minikubeを起動（minikube start）
上記のYAMLファイルをkubectl apply -f envoy-deployment.yamlで適用
kubectl get podsでPodが正常に動作しているか確認

Envoy Admin APIによるステータス確認

Envoyは/statsエンドポイントを提供し、リアルタイムでのメトリクスを取得できます。たとえば：

curl http://&lt;envoy-pod-ip&gt;:15000/stats

1 2	curl http://<envoy-pod-ip>:15000/stats

このAPIを通じて、リクエスト数やエラーレスポンスの状況が確認可能です。

ベストプラクティスと設計時の注意点

以下は、EnvoyをKubernetesで導入・運用する際の重要なポイントです。各項目について詳しく解説します。

サイドカー注入における設計ルール

YAMLテンプレート：volumeMountsとvolumesを正しく定義し、Envoyコンフィグが読み込めることを確認
セキュリティ設定：TLS証明書の自動更新やRate Limitingのためのフィルタを事前に組み込む
Istio併用時の競合回避：自動注入と手動注入の両方が動作しないように、sidecar.istio.io/inject: "false"をPodに追加

ロギング・監視構成の最適化

項目	設定例	用途
アクセスログフォーマット	`%REQ(FULL_PATH)% %RESPONSE_CODE%`	URLとステータスコードを明確に記録
メトリクスエンドポイント	`http://<envoy-pod-ip>:15000/stats`	Prometheusとの連携時

警告：Envoy v1.24以降でaccess_log.formatのフォーマットが変更されているため、旧バージョンでの設定を再利用しないように注意してください。

検証・トラブルシューティングガイド

導入後の動作確認と問題発生時の対応手順を明確にします。以下のステップに従って検証を行い、異常時の対処を行います。

ローカル環境での検証フロー

minikube startでローカルクラスタを起動
kubectl apply -f envoy-deployment.yamlでデプロイメントを適用
kubectl get podsでPodの状態を確認し、すべてReadyになっているかチェック

トラブルシューティング手順

ログ取得：kubectl logs <pod-name> --previousでEnvoy起動時のエラーメッセージを確認
コンフィグファイル検証：ConfigMapのenvoy-configが正しくマウントされているか、kubectl describe pod <pod-name>で確認
Admin API経由でのステータス確認：curl http://<envoy-pod-ip>:15000/statsでメトリクスを取得し、異常リクエストの有無をチェック

結論と今後の方向性

EnvoyはKubernetesマイクロサービス環境において、トラフィック制御・ロギングを担うデータプレーンとして適しています。本記事で紹介した手順や設計ルールに従って導入することで、高可用なサービスメッシュ構築が可能になります。

結論の要点

Envoy単体利用ではコントロールプレーンを自作する必要があるため、Istio併用が推奨されるケースが多い
サイドカー注入はYAMLテンプレートの正確な記述とConfigMapのマウントに注力が必要
バージョン互換性には常に注意し、EnvoyやIstioの最新リリース情報を確認すること

KubernetesでEnvoyサイドカー構成を試して、サービスメッシュの実装の一歩を踏み出しましょう。

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-Envoy

comment コメントをキャンセル

: Envoy

Envoy トラブルシューティング完全チェックリストとデバッグ手順

Envoy の稼働確認からログ取得、設定バリデーション、各プラットフォーム別のトラブルシューティング手順をまとめた実践ガイド。

: Envoy

Envoyアプリでオフィススケジュール管理を始める前に | 導入ガイド

Envoyアプリはリアルタイム情報共有と在庫確認機能でチーム連携を強化。導入前のおすすめポイントや初期設定、スケジュール管理の使い方を解説。

: Envoy

Envoy Visitor Management App: Global & Japanese Enterprise Solutions

Envoy visitor management app streamlines check-ins with QR codes/facial recognition, Slack integration, and security compliance. Features include global enterprise adoption, Japan-specific privacy standards, and case studies from Dropbox/Rakuten/Mazda.

: Envoy

Envoy訪問者管理システム導入ガイド | 手順と設定方法

Envoyの訪問者管理システム導入前の準備からSlack通知との連携設定まで、日本企業向けカスタマイズ手順をステップバイステップで解説します。

: Envoy

Envoy Proxy導入: IstioとKubernetesでのサイドカー設定手順

Kubernetes環境において、Envoy Proxyをサイドカーとして導入する際には、Istio Control Plane（istiod）との連携が不可欠です。xDS API経由で動的コンフィギュレーション管理を行う方法や、Helmチャート・DaemonSetによるインストール手順を解説します。

KeycloakとSpring BootのOAuth2連携ガイド

ゼロトラストでリモートワークのセキュリティを強化