Kubernetes と Talos Linux を使ったベアメタル環境でのプライベートクラウド構築

2024年4月、Kubernetes Blog に掲載された記事で、Ænix の Andrei Kvapil 氏は、オープンソース技術のみを用いてプライベートクラウドインフラを構築する方法を紹介しました。このガイドでは、OpenStack などの従来の仮想化レイヤーから脱却し、マネージド Kubernetes クラスターをホストするためにベアメタルサーバーを準備することに焦点を当てています。

何が起きたか

Kvapil 氏は、テナント用 Kubernetes クラスターを物理ハードウェア上で直接実行するように設計されたプラットフォーム「Cozystack」の作成プロセスについて説明しました。このアプローチは、Kubernetes をインストールする前に OpenStack でベアメタルサーバーを管理するという一般的な慣行に挑戦しています。代わりに、Kubernetes 自体を活用してインフラ管理の複雑さを処理し、エコシステム内の複雑なシステムの数を削減することを目指しています。

この記事は、このアーキテクチャの詳細を扱うシリーズの第1部です。データセンターの初期準備に必要な基礎作業、具体的には仮想マシンの実行、ネットワークの分離、耐障害性のあるストレージの設定などが含まれています。目標は、外部クラウドプロバイダーに依存せずに、動的ボリュームプロビジョニング、ロードバランサー、オートスケーリングをサポートするフル機能の Kubernetes クラスターを提供することです。

仕組み

中核となる違いは、クラウド上とベアメタル上での Kubernetes の動作にあります。パブリッククラウドでは、永続ボリューム、ロードバランサー、ノードのプロビジョニングなどのサービスは、プロバイダーによって外部で処理されます。これにより、ノードを一時的なユーティリティとして扱い、容易に削除・再作成できます。一方、ベアメタルでは、これらのサービスをクラスター内で実行する必要があり、物理サーバーを仮想マシンのように単純に削除・交換できないため、更新やメンテナンスが大幅に複雑になります。

この課題に対応するため、ガイドでは Kubernetes 用に特別に設計されたオペレーティングシステムである Talos Linux の使用を推奨しています。Talos では、システム全体の構成を単一のファイルで定義できます。この宣言的なアプローチにより、完全なノードの再作成やサービスの移行を行わずに、カーネルモジュールや Kubernetes コンポーネントを更新できます。Ænix チームはこの手法を用い、ZFS や DRBD などの必要なカーネルモジュールをカスタムシステムイメージにバンドルしています。

デプロイメントでは、PXE ブートを使用します。一時的な DHCP サーバーと PXE サーバーをコンテナ内で実行し、カスタムの Talos Linux イメージを物理ノードに配信します。その後、ブートストラップスクリプトがノードを初期化し、最初の Kubernetes コントロールプレーンを確立します。ベースクラスターが稼働したら、FluxCD などの GitOps ツールを使用してシステムコンポーネントをインストール・管理し、宣言的な Helm チャートを通じてクラスターが望ましい状態を維持するようにします。

主要な詳細

• ガイドでは、エコシステムの複雑さを軽減するために、OpenStack を Kubernetes ネイティブのアプローチに置き換えることを提唱しています。
• 不変かつ宣言的な構成モデルを持つため、Talos Linux が基本 OS として使用されています。
• ZFS、DRBD、OpenvSwitch などの特定のカーネルモジュールを含めるために、Docker を使用してカスタムシステムイメージをビルドします。
• 初期プロビジョニング中にベアメタルサーバーへ OS イメージを配信するために、PXE ブートが採用されています。
• システムコンポーネントの管理および GitOps によるクラスターの均一性の維持には、ArgoCD よりも FluxCD が推奨されています。
• 初期ブートストラッププロセスにより、約5分でベアメタル上に機能的な Kubernetes クラスターをデプロイできます。

なぜ重要なのか

自社ハードウェアを管理しているエンジニアリングチームにとって、このアプローチは、個別の仮想化プラットフォームを維持するオーバーヘッドなしに、クラウドのような俊敏性への道を提供します。インフラをコードとして扱い、不変のオペレーティングシステムを使用することで、チームは設定ドリフトのリスクを低減し、更新プロセスを簡素化できます。これは、データとハードウェアに対する厳格な制御が必要でありながら、Kubernetes の運用上の利点も求める組織にとって特に重要です。

ただし、この方法はインフラチームに大きな責任を課します。マネージドクラウドサービスとは異なり、エンジニアはネットワーク、ストレージ、セキュリティパッチ適用を自ら処理する必要があります。複雑さは、複数の異なるシステムの管理から、Kubernetes、基盤 OS、物理ハードウェア間の相互作用を深く理解することへと移ります。これにはより高度な専門知識が必要ですが、大規模なデプロイメントにおいて、より効率的でコスト効率の良いインフラを実現できる可能性があります。

実施可能なこと

• ノード管理を簡素化するために、ベアメタル Kubernetes クラスターの基本 OS として Talos Linux を評価してください。
• FluxCD を使用して GitOps プラクティスを実装し、宣言的にシステムコンポーネントを管理してください。
• Docker を使用して、ZFS、DRBD、OpenvSwitch などの特定のカーネルモジュールを含むカスタムシステムイメージをビルドしてください。
• 初期プロビジョニング中にベアメタルサーバーへ OS イメージを配信するために、PXE ブートを導入してください。
• システムコンポーネントの管理および GitOps によるクラスターの均一性の維持には、ArgoCD よりも FluxCD を検討してください。
• 初期ブートストラッププロセスにより、約5分でベアメタル上に機能的な Kubernetes クラスターをデプロイできることを確認してください。