Contents
Cilium L2 Announcementの概要と仕組み
Kubernetesクラスタ外からの通信を実現する際、Cilium L2 Announcementはネットワーク構成の重要な技術です。この機能は、クラスタ内のPodが外部ネットワークから直接アクセス可能なアドレスを持つようにすることで、負荷分散や外部サービスとの連携を容易にします。本記事では、その仕組みと実装における設計思想を解説し、Kubernetesエンジニア向けの理解を深めます。
L2 Announcementの基本概念
L2 Announcementは、Ciliumがネットワークアーキテクチャ上での「ローカルホスト」であることを外部ネットワークに通知する仕組みです。これにより、クラスタ外のルーターまたは負荷分散デバイスがPodへの通信経路を正確に認識できるようになります。
具体的には、Cilium Agentがクラスタ内の各ノードで実行され、そのノードのIPアドレスとPodのIPアドレスをARPテーブルやL2ネットワークにアナウンスします。これにより、外部ネットワークから直接Podにアクセスできるようになります。
クラスタ外通信の実現原理
クラスタ外からの通信を実現するには、L2 AnnouncementによるIPアドレスのアナウンスと、LoadBalancer型Serviceの設定が不可欠です。以下のような流れで通信が確立されます：
- 外部ネットワークからアクセスされたトラフィックは、LoadBalancer型ServiceのIPアドレスをターゲットにします（クラウドプロバイダー依存）
- LoadBalancerはCiliumのアナウンス情報をもとに、通信をクラスタ内の適切なPodへルーティングします
- CiliumがL2ネットワーク上でのホストとPodのマッピングを維持することで、パケットの正しく到達を保証します
本記事では、この仕組みに基づく具体的な設定手順を解説します。
LoadBalancer型Serviceの作成手順
Kubernetesクラスタ外からの通信が可能なPodを構築するには、LoadBalancer型Serviceを作成して外部IPアドレスを割り当てることが基本です。このセクションでは、YAMLファイルの記述例とServiceタイプ選択時のポイントを解説します。
YAML定義ファイルの構成例
以下は、外部通信を目的としたLoadBalancer型ServiceのYAMLテンプレートです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: v1 kind: Service metadata: name: example-service spec: type: LoadBalancer selector: app: myapp ports: - protocol: TCP port: 80 targetPort: 9376 |
この設定では、type: LoadBalancerによりクラスタ外からアクセス可能なIPアドレスが自動割り当てられ、selectorでターゲットPodを指定します。
Serviceタイプ選択時の考慮点
Serviceタイプの選択には以下のポイントを意識する必要があります：
- LoadBalancer型：外部ネットワークから直接通信できるようにする場合に必須（クラウドプロバイダー依存）
- NodePort型：クラスタ外からのアクセスが可能だが、L2 Announcementとの併用でIPアドレスの管理を注意深く行う必要あり
- ClusterIP型：クラスタ内専用のサービスであり、外部通信には使えない
外部通信を実現する際は、LoadBalancer型Serviceに特化した設定が効率的です。
ルーター設定時のIPアドレス管理
Cilium L2 Announcementではルーターやネットワーク機器と連携し、IPアドレスの適切な割り当てと管理が不可欠です。ここではCIDRブロックの設計方法とIP枯渇防止策を解説します。
CIDRブロックの設計ガイドライン
クラスタのIPアドレス設計には以下のルールを守ることが重要です：
| 項目 | 推奨値 | 補足 |
|---|---|---|
| CIDRブロック | 192.168.x.0/24 |
クラスタノードとPodのアドレスを分離 |
| ホストIP | 各ノードに静的割当 | アナウンス情報の安定化に寄与 |
| Pod IP | 172.17.x.x/24 など |
クラスタ内ネットワークで一意にする |
上記のように、CIDRブロックを分離することで、ルーターとクラスタ内のアドレス管理が明確になります。
IPアドレス枯渇防止策
IPアドレスの無駄使いを防ぐには、以下の対応策があります：
- DHCPアサイン：動的なIP割り当てで一時的に使用するPodにだけアドレスを払い出す（例: スケジュールドジョブ）
- 静的アサイン：常に通信が必要なサービスには固定IPを使用し、再利用を防ぐ
- IPアドレスプールの監視：
kubectl describe nodeでIP使用状況を確認し、余裕を持たせる
特にDHCPと静的アサインの使い分けは、ロードバランサーとCiliumの連携が安定するポイントです。
ホストポート接続のベストプラクティス
KubernetesのHostPort仕様とCilium L2 Announcementを併用する際には、セキュリティポリシーとポート競合の回避が重要です。以下に実務で活用できる手順を解説します。
セキュリティポリシーの設定例
HostPortを使う場合、以下のCiliumのネットワークポリシーを定義するとセキュリティリスクを抑えることができます：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: hostport-policy spec: ingress: - fromEndpoints: - matchLabels: app: myapp ports: - port: 8080 protocol: TCP |
この設定により、myappラベルを持つPodからのみポート8080へのアクセスを許可します。
ポート競合時の対処法
複数のPodが同じHostPortを使用しようとした場合、以下のような問題が発生します：
- パケットロス：OSレベルでポート競合が発生し、通信が失敗する可能性
- セキュリティリスク：不正なアプリケーションがホストポートを占有してアクセスされるケース
対策としては以下の方法があります：
- Port Rangeの指定：
hostPort: 8080-9000など、幅広い範囲を割り当てて競合回避 - Podの起動順序制御：重要度の高いアプリケーションからホストポートを確保させる
- ポート変換（NAT）：CiliumのL7ルーティングで外部IPとポートのマッピングを実施
ポート競合は、特にオンプレミス環境で顕著になる問題です。事前に設計段階で回避策を検討しましょう。
設定後の通信確認方法
Cilium L2 Announcementの設定が正しいかを確認するには、パケット解析とメトリクス監視が不可欠です。ここでは具体的な手順とツールの使い方を解説します。
tcpdumpでのパケット解析手順
クラスタ内の通信が正常に動作しているかは、tcpdumpでパケットキャプチャを行い確認できます：
|
1 2 |
kubectl exec -it <pod-name> -- tcpdump -i eth0 port 80 -w capture.pcap |
このコマンドにより、Podから外部への通信データがcapture.pcapファイルに保存されます。取得したパケットはWiresharkなどで解析可能です。
メトリクス監視のポイント
Cilium CLIでメトリクスを確認するには以下のように実行します：
|
1 2 |
cilium metrics |
このコマンドでは、以下のメトリクスが表示されます：
- L2 Announcements：アナウンスされたIPアドレス数と成功・失敗回数
- Pod Connectivity：クラスタ内外のPod間通信の成功率（
pod_connectivity_success_rate） - LoadBalancer Stats：トラフィック量やエラーレートなど
メトリクス監視は、異常検知や性能改善に直接役立ちます。定期的な確認を推奨します。
まとめ
本記事では、Cilium L2 Announcementの設定方法と実務におけるポイントを解説しました。重要な内容を以下のように整理します：
- L2 Announcementの仕組みは、クラスタ外からの通信確立に不可欠
- LoadBalancer型Service作成時のYAML記述例とサービスタイプの選択基準
- CIDR設計とIP枯渇防止策は、ルーターとの連携を安定させるための基本
- HostPort接続ではセキュリティポリシーとポート競合対策が必須
- 設定後の確認には
tcpdumpやCilium CLIのメトリクスを使うことで効率的
本記事で解説した手順を参考に、自社環境でのCilium L2 Announcement構成を試してみましょう。