DevOpsツール入門 #09：マシンのデプロイ

これまでのDevOpsツールに関する解説では、コンテナ仮想化と、それによってアプリケーションのパッケージ化やデプロイ方法がどのように変革されたかを見てきました。コンテナの大きな利点のひとつは、従来の仮想マシンと比較してリソースのオーバーヘッドが非常に小さいにもかかわらず、起動が非常に高速である点です。コンテナはホストOSのカーネルを共有するため、数秒で起動でき、同一のインフラ上で多くの分離されたワークロードを効率よく実行できます。

しかし、コンテナによってアプリケーションのパッケージ化や実行は簡素化された一方で、複数のサーバーにまたがる大量のコンテナを管理することは急速に複雑になります。現代のアプリケーションは、数十、場合によっては数百のコンテナで構成され、それらをスケジューリングし、監視し、障害時には再起動し、需要に応じて動的にスケールさせる必要があります。これらの作業を手動で行うことは、本番環境では現実的ではありません。

この課題を解決するために登場したのが、コンテナオーケストレーションプラットフォームです。これらは、複数のマシンからなるクラスター上で、コンテナのデプロイ、スケーリング、ネットワーク管理、ライフサイクル管理を自動化することを目的としています。その中でも、Kubernetesはコンテナ化されたワークロードのオーケストレーションにおいて、最も広く採用されているソリューションとなっています。

KubernetesはもともとGoogleによって開発され、その後Cloud Native Computing Foundationに寄贈されました。分散されたコンテナアプリケーションを信頼性高く大規模に管理できる、強力かつ拡張性の高いアーキテクチャを提供しています。 Pods, Services, Deployments,controllersといった概念を導入することで、管理者やDevOpsエンジニアはインフラの「望ましい状態（Desired State）」を定義でき、プラットフォーム側がその状態を維持するよう継続的に制御します。

本章では、Kubernetesのアーキテクチャ、クラスターの主要コンポーネント、そしてkubectlなどのツールを使ってクラスターの状態を確認し、リソースを管理する方法について解説します。

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

Kubernetesクラスターは、2つの主要な要素から構成される分散システムです。

コントロールプレーンはクラスターを管理しスケジューリングを行い、ワーカーノードはアプリケーションのワークロードを実行します。

このアーキテクチャにより、Kubernetesはアプリケーションの望ましい状態を維持できます。管理者はサーバー上で手動でプロセスを起動する代わりに、意図する構成を宣言するだけで、Kubernetesがその状態に一致するようクラスターを自動的に調整します。

コントロールプレーンの主要コンポーネント

コントロールプレーンには、クラスター管理とオーケストレーションを担う重要なコンポーネントが含まれます。

API Server

Kubernetes API Server（kube-apiserver）は、クラスターの中心となる通信ハブです。管理者がkubectlや内部コンポーネント、各種自動化ツールを通じて行うすべての操作は、このAPIを経由します。

主な役割は以下の通りです。

• Kubernetes REST APIの公開
• リクエストの認証および認可
• リソース定義の検証
• クラスター状態のetcdへの保存

クラスターへの入口となるため、ステートレスなサービスとして設計されており、水平スケーリングが可能です。

etcd

etcdは、Kubernetesの永続ストレージとして使用される分散型キーバリューデータベースです。設定情報、ノード情報、リソース定義など、クラスターに関するすべての情報を保存します。

Pod、Deployment、Serviceなど、すべてのKubernetesオブジェクトはetcdに記録されます。そのため、etcdはクラスターの「唯一の信頼できる情報源（Single Source of Truth）」となります。

etcdが利用できなくなると、すでに動作中のワークロードは継続する可能性がありますが、新規作成や更新などの変更は行えなくなります。

Controller Manager

Controller Manager（kube-controller-manager）は、複数のコントローラーを実行し、クラスターの状態を継続的に監視して、望ましい構成を維持します。

コントローラーは「リコンシリエーションループ」を実装しており、実際の状態と望ましい状態を繰り返し比較し、差異があれば修正を行います。

主なコントローラーの例：

• Node Controller
• ReplicaSet Controller
• Deployment Controller
• Service Controller

これにより、ワークロードの可用性と一貫性が保たれます。

Scheduler

Kubernetes Scheduler（kube-scheduler）は、新しく作成されたPodをクラスター内のどのノードで実行するかを決定します。リソースの空き状況や制約、ポリシーを考慮して最適なノードを選択します。

主な判断基準：

• CPUやメモリの空き状況
• ノードアフィニティルール
• テイントとトレラント
• ワークロードのバランス

ワーカーノードの構成要素

ワーカーノードはアプリケーションのワークロードを実行し、通常は以下のコンポーネントを含みます。

• kubelet：コントロールプレーンと通信するノードエージェント
• コンテナランタイム：containerdやDockerなど
• kube-proxy：ネットワークおよびサービスルーティングを担当

これらにより、Podの実行と状態報告が可能になります。

kubectlの設定

kubectlは、Kubernetesクラスターと通信するためのコマンドラインツールです。APIサーバーと連携し、リソースの管理やクラスター状態の取得を行います。

設定は通常、~/.kube/config ファイルに保存され、以下の情報を含みます。

• クラスターのエンドポイント
• 認証情報
• コンテキスト
• ネームスペース

設定の管理には kubectl config コマンドを使用します。

kubectl get

リソース情報の取得は、Kubernetes操作の中でも最も基本的な作業です。

例：

これらのコマンドにより、リソースとその状態を簡潔に確認できます。

リソースの作成と管理

kubectl create

コマンドラインまたはマニフェストファイルからリソースを作成します。

例：

kubectl apply

YAMLマニフェストで宣言されたリソースを作成または更新します。

例：

宣言的インフラ管理をサポートするため、DevOpsパイプラインで広く利用されています。

kubectl run

指定したコンテナイメージでPodを作成します。

例：

リソースの変更とスケーリング

kubectl scale

レプリカ数を変更します。

例：

kubectl set

コンテナイメージなどの設定を更新します。

例：

ワークロードの確認とトラブルシューティング

kubectl logs

コンテナのログを表示します。

例：

kubectl exec

実行中のコンテナ内でコマンドを実行します。

例：

アプリケーションのトラブルシューティングに非常に有効です。

LPI DevOps Tools Engineer認定を目指すDevOpsエンジニアにとって、これらのコンポーネントの理解とkubectlコマンドの習得は不可欠です。クラスターの状態確認、リソースの作成・変更、稼働中ワークロードのトラブルシューティングは、現代のクラウドネイティブ環境におけるKubernetes運用の基礎となります。

Kubernetesのアーキテクチャと利用方法を詳しく解説した完全なレッスンは、Linux Professional Instituteが提供する公式ラーニングマテリアルで無料公開されています。これらの教材には、Kubernetesの各コンポーネントの詳細説明、kubectlによる操作方法、そしてDevOps Tools Engineer試験の目的に沿った実践例が含まれています。

<< 本シリーズの前の記事を読む ｜ 次の記事を読む >>