Kubernetes運用前に勉強していること基礎編03-06
注意
本記事の内容は個人的な勉強・備忘録を目的としており、勤務先や関係者とは一切関係ありません。
はじめに
Kubernetesの本番環境での運用を始めるにあたり、個人で勉強している内容を整理した記事です。構築や運用に必要な知識、注意点、実践して学んだことを随時更新していきます。基礎編の想定読者はコンテナの知識があり、Kubernetesでコンテナ運用したいがどうすればいいかを迷っている人です。今回は前回の引き続きで、Kubernetesのリソースカテゴリを学ぶことを目的としています。
勉強中の主な内容
- 基礎編
- クラウドネイティブとは
- Kubernetesのアーキテクチャ概要
- Kubernetesのリソース（今回の話）
Ingress（イングレス）
Ingressは、クラスタ外からHTTP/HTTPSなどのリクエストをクラスタ内のサービスにルーティングするためのリソースである。簡単に言えば、IngressはL7（アプリケーション層）のリバースプロキシ/ロードバランサ設定を表現するオブジェクトである。Ingressリソースではホスト名やパスに基づく転送ルールを定義できる。
たとえば「example.com/apiへのリクエストはapi-serviceへ、example.com/webはweb-serviceへ転送」といったことができる。 Ingress自体はあくまでルーティングルールの集合であり、それ単体では外部からのトラフィックを終端させる機能である。このため、Ingress自体はPod やノード上でパケットを処理する機能はない。
Ingressルールを有効にするには、クラスター上に図のようなIngress Controller（イングレスコントローラ）と呼ばれる専用のポッドをデプロイする必要がある。
Ingress Controller
Ingress Controller は通常 Deployment として動く Pod 群であり、
- API‑Server を watch して Ingress リソースの追加・更新・削除イベントを受け取る。
- 受け取ったルールをもとに データプレーン（ALB, Envoy, NGINX など）を動的再設定
- 健全性チェックや証明書更新などを行う
Kubernetesのマニフェストで定義した理想状態に実態を合わせるネットワーク経路実装する。Ingress がルート表で、Controller がルータを自動配線するエンジニアに相当するイメージである。
Ingressの種類
| 分類 | 代表例 | データプレーン | 外部 LBの有無 | 主なユースケース |
|---|---|---|---|---|
| クラウド LB 制御型 | AWS Load Balancer Controller | ALB/NLB（マネージド） | あり | パブリック公開 |
| 組込プロキシ型 | NGINX Ingress Controller | Pod 上のNGINX | なし | クラスタ内マルチテナント、 L7 カスタマイズ |
AWS Load Balancer Controller
アーキテクチャ概要
- Controller は Ingress を監視し、ingressClassName: albを検知すると AWS ALBを自動生成
- 生成された ALB は Target Group に Pod IP を直接登録（target-type: ip）し、Pod スケール/再配置は Controllerが同期
- ALB は L7 で TLS 終端ポリシ適用・Header Rewrite などを実行し、その後 VPC 内 ENI 経由で Pod へフォワードする
特徴と利点
- 運用負荷:
- ALB 側で証明書、Autoscaling、AZ Fault tolerance が完結。
- Controller Pod は control‑plane のみでスケール不要
- 性能:
- Hyper‑scale 帯域（数十 Gbps）、HTTP/2, gRPC, TLS 1.3 をフルサポート
- コスト/経路:
- インターネット公開の場合でも ALB → VPC ENI → Pod の 2 ホップで済み NAT不要
注意点
ルール数・リスナ数が多い場合は別 Ingress へ分割する。
NGINX Ingress Controller
アーキテクチャ概要
- Controller Pod 内で NGINX が動作し、Ingress 変更を検知すると nginx.conf を再生成
- デフォルトでは Controller Pod に対し Service type:ClusterIP が作成され、トラフィックは クラスタ内で完結
- 外部に公開する場合は ClusterIP をフロントに NodePort や Service type:LoadBalancerを追加で置く二段構え
特徴と利点
- 柔軟な L7 機能:
- rewrite、WebAuthn,Lua など NGINX 拡張を自由に組込める
- サイドカー的配置:
- Private Subnet 内だけでAPIやgRPCサービスを相互接続する
- マルチプロトコル:
- TCP/UDP 振り分けや PROXY Protocol も ConfigMap で設定でき、LBに依存しない
注意点
- パケットは全て Controller Pod を経由 するため、スループットは Pod 数・ノード帯域に依存し、100k rps 超級では Scale‑Out 設計必須
「クラスタ外 LB 型」 と 「内部プロキシ型」の違い
| 観点 | ALB Ingress | NGINX Ingress |
|---|---|---|
| データプレーン | AWS マネージド（ALB/NLB） | Pod 内 NGINX |
| スケール | ELB の Auto‑Scaling | Pod Replicas |
| L7 機能 | WAFv2, HeaderRewrite, HTTP/2, gRPC | rewrite, Lua, TCP/UDP |
| ネットワーク経路 | インターネット→ALB→Pod | (追加 LB)→NodePort→NGINX→Pod |
Ingressのまとめ
- Ingress リソース は ルールの宣言、Ingress Controller は ルールを実働システムに反映 する制御プレーン
- Controller 実装は クラウド LB 制御型 と 組込プロキシ型 に2分され、データプレーンの場所・保守性・スケーラビリティが決定的に異なる
所感
公開されているHelmを使って、アプリケーションを運用するうえでIngressの設定がややこしく、よく失敗している。最初はLoadBalancerとIngressの違いなどが分からないため、NGINX Ingress Controller（組込プロキシ型）とAWS Load Balancer Controller（クラウド LB制御型）が混在して理解して、想定していない状態になっていた。このあたりのネットワーク関連のトラブルや設計を勉強することで、実運用のトラブルが起きても対応していけるようにしたい。
補足
過去の記事で記載していた内容を補足として追記しています。
Kubernetesのリソースカテゴリ
Kubernetesのリソースカテゴリは、『Kubernetes完全ガイド第二版』をベースとしている。
| カテゴリ | 概要 |
|---|---|
|
Workload APIs |
アプリケーション（コンテナ）の実行を管理するためのリソース |
|
Service APIs |
Pod内のコンテナをネットワーク経由で公開し、アクセスを提供するリソース |
|
Config APIs |
コンテナで利用する設定や機密情報を管理するためのリソース |
|
Storage APIs |
コンテナで利用する永続化データを管理するためのリソース |
|
Cluster APIs |
クラスタ内のリソースの運用や管理、セキュリティを制御するリソース |
|
Metadata APIs |
クラスタ内の他リソースの操作や動的なメタデータ管理を行うリソース |