Kubernetes運用前に勉強していること基礎編まとめ02

Kubernetes運用前に勉強していること基礎編02

注意
本記事の内容は個人的な勉強・備忘録を目的としており、勤務先や関係者とは一切関係ありません。

---

はじめに

Kubernetesの本番環境での運用を始めるにあたり、個人で勉強している内容を整理した記事です。構築や運用に必要な知識、注意点、実践して学んだことを随時更新していきます。基礎編の想定読者はコンテナの知識があり、Kubernetesでコンテナ運用したいがどうすればいいかを迷っている人です。今回はKubernetesのアーキテクチャ概要を学ぶことを目的としています。

勉強中の主な内容

• 基礎編
  • クラウドネイティブとは
  • Kubernetesのアーキテクチャ概要（今回の話）
  • Kubernetesのリソース

Kubernetesクラスターのアーキテクチャ概要

Kubernetesクラスターは管理層（コントロールプレーン）と実行層（ノード）の二つの主要コンポーネントで構成される。これらはkubernetesアーキテクチャ概要図のように連携してアプリケーションを安定かつ効率的に実行できる環境を提供する。

kubernetesアーキテクチャ概要図

コントロールプレーンコンポーネント

コントロールプレーンは下記のようなクラスタ全体を管理する役割を担う。

kube-apiserver（APIサーバー）

• ノードやクライアントからのリクエスト受付や状態管理
• すべてのAPIリクエストを処理し、クラスターの現在の状態を管理
• ノードやコントローラーからの通信はすべてAPIサーバーを経由
• EKSではAWSによって管理され、高可用性が確保されている

etcd（クラスタ管理用のデータベース）

• クラスター全体の状態やメタデータを保存する分散Key-Valueストア
• クラスター内のすべてのリソース（Pod, Service, ConfigMapなど）の情報を格納
• EKSではAWSによってバックアップや冗長性が管理されている

kube-scheduler（スケジューラー）

• Podをクラスタ内の最適なノードに割り当てる
• ノードのリソース要件、アフィニティ/アンチアフィニティ、データの局所性などを考慮
• EKSでは自動で最適なスケジューリングを行うよう構成されている

kube-controller-manager（コントローラーマネージャー）

• クラスタの状態が常に望ましい状態になるよう管理し、障害時の復旧処理などを担当
• Node Controller：ノードの状態監視
• Replication Controller：Podの期待する数を維持
• Endpoints Controller：サービスとPodの接続情報を管理
• Service Account & Token Controllers：アカウントとアクセストークン作成

cloud-controller-manager

• クラウドプロバイダー固有のAPIとKubernetesを統合
• EKSでは特にAWSのリソース（ELB, EBS, Route 53など）との連携を担当
• ノードライフサイクル、ルーティング、ロードバランシングなどをAWSリソースと連携して管理

デバイスプラグイン（Device Plugin）

• 特殊なハードウェアリソース（GPU、FPGAなど）をKubernetesのPodで利用可能にするための仕組み
• Kubernetesに標準でサポートされていないハードウェアを動的にノードに登録・管理
• Podが特殊なデバイスを要求した際に、適切なノードへスケジュールされるよう支援
• NVIDIA GPUデバイスプラグインなどが代表例

ノードコンポーネント

ノードは実際にアプリケーションを実行する役割を担う。

kubelet

• 各ノードで実行されるエージェント
• Podの仕様に従ってコンテナが確実に動作するよう管理
• コントロールプレーンからの指示を受けて、ノード上のコンテナライフサイクルを管理
• ノードの状態をコントロールプレーンに定期的に報告

kube-proxy (iptables / nftables)

• ネットワークプロキシとしてノード上で動作
• Kubernetes Serviceの実装を担当し、Podへのネットワークトラフィックをルーティング
• EKSではVPCネットワークと統合され、効率的なルーティングを提供

CNIプラグイン

• Kubernetesクラスタ内でのPodのネットワーク管理を担当するプラグイン
• Pod作成時にPodへネットワークインターフェースを割り当て、IPアドレス設定や通信経路を管理
• EKSではAmazon VPC CNIを利用するのが一般的

Amazon VPC CNI Plugin（通常のAWS CNI）

• Podに対してVPC内のプライベートIPアドレスを直接割り当てる
• AWSネイティブなネットワーキングを利用し、PodがVPC内リソース（EC2、RDSなど）と通信できる
• シンプルで運用が容易だが、Pod数とノード数の増加に伴ってIPアドレスの枯渇に注意が必要

Cilium CNI Plugin（eBPF利用）

• eBPF技術を使ってLinuxカーネル内で高速かつ効率的なネットワーキングを実現する
• Pod間通信やネットワークポリシーの制御をカーネルレベルで効率的に処理可能
• ネットワークポリシーを高度かつ柔軟に設定可能で、Pod間の通信を細かく管理できる
• ネットワークトラフィックの可観測性が高く、トラフィック分析や障害解析が容易になる
• 大規模な環境や複雑なネットワーク要件がある場合に有効な選択肢となる

コンテナランタイムインターフェース（CRI）

• Kubernetesとコンテナランタイム間の標準インターフェース
• イメージの取得、コンテナの作成・開始・停止などの機能を提供
• 異なるコンテナランタイムを簡単に切り替え可能にする抽象化レイヤー

containerd

• EKSではデフォルトでcontainerdが採用されている
• Dockerから派生した、より軽量でシンプルなコンテナランタイム
• Kubernetes専用に最適化されており、必要最小限の機能だけを提供
• コンテナ起動のオーバーヘッドが低く、パフォーマンスと安定性が高い
• セキュリティ面でも攻撃対象（Attack Surface）が小さい

Docker

• Kubernetes 1.24以前はDockerが標準のコンテナランタイムとして主に利用されていた
• Dockerはもともと開発者向けに幅広い機能を持つ（イメージ構築やCLI操作など）
• Docker Engineは内部でcontainerdを使用しているが、Docker自体の機能が多いためランタイムとしては重い
• Kubernetesにとっては不要な機能が多く、メモリやCPUの消費が大きい

重要な仕組みと概念

ノードとコントロールプレーン間の通信

• 主にkube-apiserverを介して行われる
• TLS暗号化によりセキュアな通信を確保
• kubeletがAPIサーバーにノードの状態を定期的に報告
• コントロールプレーンからノードへの命令は常にAPIサーバー経由

リース（Lease）

• ノードの健全性を確認するための仕組み
• kubeletが定期的にリースオブジェクトを更新し、ノードの生存状態を通知
• リース期限が切れるとノードに問題があると判断される
• EKSではこの仕組みを利用したノードの自動置換機能も提供

cgroup v2

• Linux上でのリソース制限とアカウンティングを行う仕組み
• CPU、メモリ、ディスクI/Oなどのリソース使用を制御
• Kubernetesのリソース制限（requests/limits）の実装に使用
• EKSの新しいノードではcgroup v2がサポートされている
• Podのリソース分離とQoS（Quality of Service）クラスの実装に不可欠

ガベージコレクション

• 不要になったリソースを自動的に削除する仕組み
• 主に以下の2種類がある：
  • 終了したPodのガベージコレクション
  • 未使用のコンテナイメージのガベージコレクション
• kubeletが設定されたしきい値に基づいて実行
• ディスク使用量を抑え、クラスターのパフォーマンスを維持

EKS特有の考慮事項

IAMとの統合

• EKSクラスターはAWSのIAMと統合されている
• IAM認証を使用してKubernetesクラスターへのアクセスを制御
• IAM RoleとKubernetesのRBACを組み合わせた権限管理が重要

ネットワーキング

• EKSクラスターはAmazon VPC内に作成される
• PodネットワーキングにはAmazon VPC CNI Pluginが使用される
• 各PodはVPC内のプライベートIPアドレスを取得
• ClusterIPやNodePortの代わりにロードバランサータイプのServiceではALB/NLBが自動的にプロビジョニングされる

ストレージ

• EKSでは永続ストレージにAmazon EBS、Amazon EFS、Amazon FSxなどを利用可能
• StorageClassを通じて動的に永続ボリュームをプロビジョニング
• AWS CSI（Container Storage Interface）ドライバーにより柔軟なストレージオプションを提供

運用監視

• Amazon CloudWatchとの統合でメトリクスやログを収集
• AWS X-Rayとの統合でアプリケーショントレーシングが可能
• Container Insightsによるコンテナレベルのモニタリング

EKS マネージド add‑on

• AWSが公式に提供するKubernetesの機能拡張モジュール（add-on）で、インストール、更新、ロールバックといったライフサイクルをAWSが管理している
• Kubernetesクラスター管理ツール（eksctlやAWS Management Console）を通じて簡単に導入や更新が可能
• マネージドadd-onを利用することで運用負荷を軽減し、コンポーネントのバージョン管理も容易になる

KESで提供されている主なadd-onの詳細

EKSマネージドadd-onは、AWSが公式に提供・管理するKubernetesクラスターの追加機能で、クラスターの運用管理をシンプルにする仕組みです。主に以下のメリットがある。

• add-onのインストール、アップデート、ロールバックなどをAWSが自動管理
• AWSサービスとの統合がスムーズ
• Kubernetes周辺ツールのバージョンや互換性問題をAWSが検証し、ユーザー側の管理負荷を軽減
• セキュリティパッチや脆弱性対応をAWSが迅速に提供

主なマネージドadd-onの例

add-on名	機能概要
Amazon VPC CNI	Podに直接VPC内IPを割り当てる
Amazon EBS CSI Driver	EBSを永続ストレージとして動的に割り当て
Amazon EFS CSI Driver	EFSの共有ファイルシステムをPodにマウント
AWS Load Balancer Controller	ALB/NLBをIngressやServiceから自動で作成
karpenter	ノードをPod需要に応じて自動的に追加・削除
Cilium	eBPFを利用した高速で柔軟なネットワーク管理

Amazon VPC CNI（Container Network Interface）

• Kubernetes Podのネットワーク管理に使用される
• PodがAmazon VPC内のプライベートIPアドレスを直接取得し、VPC内リソースとの連携を容易にする
• ノード単位ではなく、Pod単位で細かくネットワークを管理・設定可能

Amazon EBS CSI Driver

• Amazon EBSボリュームを動的にプロビジョニング（作成・割り当て）可能にするドライバー
• KubernetesのStorageClassとPersistentVolumeClaim (PVC)を利用し、必要に応じてEBSボリュームを迅速に自動作成できる
• StatefulSetやデータベースなど、永続的なストレージが必要なアプリケーションで重要

Snapshot-controller

• EBS CSI Driverと連携して、Kubernetesネイティブなスナップショット機能を提供する
• KubernetesのVolumeSnapshot APIを使い、EBSボリュームのスナップショットを作成・管理できる
• 定期的なバックアップや障害復旧（DR）のためのスナップショット運用が簡単に実現できる

Amazon EFS CSI Driver

• Amazon EFS（Elastic File System）をPodからマウントして共有ストレージとして利用できるドライバー
• 複数Pod間でのファイルシステム共有が容易に実現可能
• 動的プロビジョニングに対応し、Podの増減時もファイルシステムの拡張性が維持される

AWS Load Balancer Controller

• KubernetesのIngressリソースやServiceリソースの定義から、自動的にALB（Application Load Balancer）やNLB（Network Load Balancer）をAWS上に作成・管理する
• クラスター外部へのトラフィックルーティングをシンプルかつ効率的に行える
• SSL証明書（ACM）との統合やパスベース／ホストベースルーティングもサポートしている

karpenter

• ノードの自動プロビジョニング（作成と削除）を行うオートスケーリングツール
• Podの要求リソース量に応じて、最適なサイズやスペックのノードを自動で追加・削除し、効率的にリソースを利用する
• クラスターのコスト効率とリソース利用効率を同時に改善できる

Cilium

• ネットワークポリシーの実装やネットワーク管理を行う高性能なネットワークプラグイン
• LinuxカーネルのeBPF技術を使用して高速なネットワークデータプレーンを実現し、オーバーヘッドを抑えてネットワーク性能を向上させる
• ネットワークトラフィックの詳細な可視化（可観測性）やセキュリティポリシーの適用を容易に行える

まとめ

EKSを効果的に使用するためには、Kubernetesの基本的なアーキテクチャコンポーネントとその相互関係を理解することが重要です。コントロールプレーンとノード間の通信、リソース管理の仕組み、ネットワーキングなどの基本概念を把握することで、EKSクラスターの設計、デプロイ、運用がスムーズに行えるようになる。

AWSは多くのコントロールプレーンの管理を代行してくれるが、ノードの管理、アプリケーションのデプロイ戦略、リソースの最適化などはユーザー側の責任となる。これらの基本的な概念を理解した上で、AWSの提供する豊富なマネージドサービスと組み合わせることで、堅牢で可用性の高いKubernetesベースのアプリケーション基盤を構築できる。

個人の所感

Kubernetes（K8s）を学んで感じたことは、そのアーキテクチャが非常に複雑であるということだ。基本的なコンセプトを理解しておけば、実際にEKS内でパフォーマンスの問題やトラブルが発生した際にも迅速かつ適切な対応が可能になるだろう。
また、K8s特有の課題として、K8s自体のバージョン管理はもちろん、kubeletや各種アプリケーションごとのバージョンの相性も考慮して環境を構築する必要がある。これは運用上、無視できないポイントだ。
その点、AWSが提供するEKSは、このような複雑なバージョン管理や互換性問題についてのサポートが整っており、大きな利便性を感じる。Amazon EBS CSI DriverやAWS Load Balancer ControllerといったAddon機能をEKSのコマンドラインから容易に導入できるのは非常に便利で、効率的な運用を実現するうえで大きなメリットだと感じた。

参考文献

• Kubernetesのコンセプト