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	クラスタ内の他リソースの操作や動的なメタデータ管理を行うリソース