Kubernetes 向け Linux OS ガイド

すでに Kubernetes を調べたことがある (または、Kubernetes のデプロイメントを調べることを検討している)。 Kubernetes について学ぶべき理由は数多くあり、Kubernetes がコンテナの管理、クラスターへのワークロードのスケジュール設定、スケーラビリティと冗長性の処理、ロールアウト (更新) とロールバックの自動化を担当していることは、すでによくご存知かもしれません。これは、インフラストラクチャに依存しないシステムであり、宣言文を使用してシステムとアプリケーションがとるべき状態を記述し、管理対象要素をその状態を実現するように駆動します。これにより、強力でスケーラブルなシステムの管理が容易になります。もちろん、ここで言う「管理が容易」には学習曲線がありますが、最新のコンテナベースのソフトウェア開発、つまりスケーラビリティとインフラストラクチャの移植性を提供するインフラストラクチャの利点を享受するには、それだけの価値があります。

[[355372]]

Kubernetes はコンテナの運用上のスケーラビリティと管理を可能にしますが、Kubernetes 自体が依存するインフラストラクチャの管理には直接役立ちません。 Kubernetes 自体はアプリケーション (またはアプリケーションのグループ) であり、これらのアプリケーションはどこかで実行する必要があります。聞いたことがあるかもしれませんが、Kubernetes はオペレーティング システムではなく、ノードにインストールされる Linux または Windows に依存しています。 Kubernetes は、AWS や GCE などのクラウド プロバイダー、または VMware などの仮想化プラットフォーム上で実行できますが、いずれの場合も最初にオペレーティング システムをインストールする必要があります。 (AWS EKS など、コントロールプレーンノードの管理が不要なものもありますが、ワーカーノード用に Linux サーバーをセットアップする必要があります。)

運用上は、当然のことながら、Kubernetes とそれが実行するワークロードに重点が置かれていますが、これにより Kubernetes のデプロイメントでよくある問題が発生します。 Kubernetes は定期的にパッチ適用およびアップグレードされますが、基盤となるオペレーティング システムのメンテナンス、更新、セキュリティ、および運用は、少なくともセキュリティ監査が実行されるまで忘れられたり、無視されたりすることがよくあります。 SRE やシステム管理者からは、Linux と Kubernetes の両方を管理するのは余分な仕事だとよく聞きます。通常の Linux オペレーティング システムと同様に、Kubernetes にもパッチ適用、更新、セキュリティ保護、ユーザー アクセス制御などが必要です。ただし、これらのタスクが Kubernetes レベルで実行されるからといって、オペレーティング システム レベルで無視できるわけではありません。ただし、基盤となるオペレーティング システム ディストリビューションを適切に選択すると、オペレーティング システムの保守にかかる作業負荷が大幅に軽減され、予定外の更新による影響も軽減されます。

では、Kubernetes を実行する前に Linux をインストールする必要があることを考えると、基盤となるオペレーティング システムが関係しますが、どの Linux ディストリビューションを選択して実行すればよいのでしょうか。選択肢は多数ありますが、一般的にはコンテナに最適化されたオペレーティング システムと汎用オペレーティング システムの 2 つのカテゴリに分類されます。

一般的なLinuxオペレーティングシステム

これらは Linux の通常のタイプです。

ほとんどの人は、Ubuntu、Debian、CentOS、RHEL、Fedora などの一般的なタイプの Linux オペレーティング システムの実行に慣れています。これは、Kubernetes クラスターで汎用オペレーティング システムを実行する主な利点の 1 つです。システム管理者は、Linux ディストリビューションをインストール、更新、強化する方法を熟知しています。既存のツール セットを使用して、サーバーを起動し、オペレーティング システムをインストールし、基本レベルのセキュリティを構成できます。既存のパッチ管理およびセキュリティ検出ツールは、Kubernetes を実行している場合でも、これらのシステムで正常に動作するはずです。

しかし……

汎用 Linux システムを使用すると、通常の Linux 管理オーバーヘッドが発生します。つまり、ユーザー アカウント管理、パッチ管理、カーネルの更新、サービス ファイアウォール、SSH セキュリティ、ルート ログインの無効化、未使用のデーモンの無効化、カーネルのチューニングなどをすべて実行し、最新の状態に保つ必要があります。前述したように、これらのタスクのほとんどは、Ansible、Chef、Puppet などの既存のツールを使用して実行できます。ただし、インベントリ ファイルまたは制御ファイルを更新して、サーバー構成ファイルを Kubernetes マスター ノードとワーカー ノードに適したものにするのは簡単な作業ではありません。

もう 1 つの問題は、オペレーティング システムの変更と Kubernetes のメンテナンスの調整です。多くの場合、インストール後もオペレーティング システムが同じままになるように不整合が生じます。時間が経つにつれて、Kubernetes は（うまくいけば）アップグレードされますが、基盤となるオペレーティング システムはそのまま残り、さまざまなパッケージとインストールされたカーネルに既知の CVE（共通脆弱性識別子）の負担が徐々に蓄積されていきます。

理想的には、Ansible や Puppet などの自動化プラットフォームを Kubernetes と連携させて、Kubernetes の操作に影響を与えずにノードのオペレーティング システムをアップグレードできるようにします。つまり、オペレーティング システムは次のことを行う必要があります。

• ノードをスケジュール不可に設定して、新しいワークロードがそのノードにスケジュールされないようにする
• 実行中のすべてのポッドを他のノードに移動するには、ノードを強制退去します。
• ノードを更新してパッチを適用する
• ノードをスケジュール可能に設定する

もちろん、システムでは、クラスターのワークロード容量に悪影響が出ないように、同時に更新されるノードが多すぎないようにする必要があります (また、大規模なクラスターの更新がパッチや更新プログラムのリリース速度よりも遅くならないように、ノードが少なすぎないようにする必要があります)。再起動や停止を減らすために OS アップデートと Kubernetes アップデートを調整したい場合もありますが、それでも短期間でより重要な OS アップデートをサポートする必要があります。

汎用 Linux オペレーティング システムの最大の利点は、スタッフが使い慣れていることです。つまり、導入に精通しているだけでなく、トラブルシューティングのスキルも備えている必要があります。 tcpdump、strace、lsof などの一般的なオペレーティング システム ツールをインストールして使用できます。構成は簡単に変更でき、間違いを修正したり代替案をテストしたりできます (これは良いことでもあり、悪いことでもあります)。欠点は、システム管理を維持するためのオーバーヘッドと、Kubernetes インフラストラクチャおよび運用との更新を調整する必要性です。

コンテナ固有のオペレーティングシステム

アメリカ国立標準技術研究所 (NIST) は、コンテナ固有のオペレーティング システムを定義することの意味をわかりやすくまとめ、その利点をいくつか挙げています。

「コンテナ固有のホスト OS は、コンテナのみを実行するように明示的に設計された最小限のオペレーティング システムであり、他のすべてのサービスと機能は無効になっており、読み取り専用のファイル システムとその他の強化プラクティスが採用されています。コンテナ固有の OS を使用する場合、攻撃対象領域は通常、汎用 OS よりもはるかに小さいため、コンテナ固有のホスト OS を攻撃して侵害する機会は少なくなります。これらの理由から、組織は可能な限りコンテナ固有のホスト OS を使用する必要があります。」 「NIST 特別出版 800-190 アプリケーション コンテナ セキュリティ ガイド」より引用

まとめると、オペレーティング システムで実行されるソフトウェアとパッケージが少ないほど、攻撃対象領域が小さくなり、脆弱性も少なくなることは明らかです。これにより、頻繁にパッチを適用しなくても、コンテナ固有のオペレーティング システムは最初から大幅に安全になります。

コンテナ固有のオペレーティング システムでは、脆弱性の影響を軽減するために、ルート ファイル システム (およびできればすべてのファイル システム) を読み取り専用にするなどの他のセキュリティ対策も採用できます。

コンテナ固有のオペレーティング システムでは通常、パッケージ管理は実行されません (またはサポートされません)。これにより、パッケージのインストールまたは更新によって競合が発生し、ノードまたはサービスが機能しなくなる可能性が軽減されます。 ChefやPuppetなどの管理ツールがないため、不完全な操作がシステム運用の安定性に悪影響を与える可能性が低くなります。代わりに、すべての更新と構成が適用された完全なオペレーティング システム イメージがフォールバック ブート メカニズムにインストールされ、次回の再起動時に起動されるか、以前に正常に動作していたことがわかっているイメージにフォールバックします。つまり、ノードの構成はいつでも完全に把握でき、使用中のバージョン管理システムから任意のバージョンを復元できます。

コンテナ固有のオペレーティング システムの中には、汎用 Linux ディストリビューションに似たものもあります。たとえば、VMware の PhotonOS には、通常の Linux ディストリビューションよりもインストールされるパッケージが少ないですが、パッケージ マネージャー、SSH アクセスが含まれており、ファイル システムを読み取り専用としてマウントしません。人々が時々混乱することの 1 つは、汎用 Linux システムの「クラウドに最適化された」バージョンは、Ubuntu がリリースする「クラウド イメージ」のように、依然として汎用 Linux システムであり、「Ubuntu エンジニアリングによってパブリック クラウドで実行できるようにカスタマイズされている」ということです。ただし、これらは依然としてすべてのパッケージがインストールされた完全な Linux ディストリビューションであり、cloud-init パッケージが追加されているだけで、手動介入なしで起動を簡単に構成できます。

CoreOS は、広く採用された最初のコンテナ固有のオペレーティング システムであり、セキュリティと分離を強化するためにすべてのプロセスをコンテナ内で実行するという考え方を普及させました。 CoreOS はパッケージ マネージャーを廃止し、2 つの読み取り専用 /usr パーティションのいずれかを再起動して、更新がアトミックであり、ロールバックできることを保証します。しかし、CoreOS が RedHat に買収されたため、プロジェクトは終了しました。

現在のコンテナ固有のオペレーティング システムはすべて最小限の姿勢を採用しています (OS にインストールされるパッケージは少数です)。 （ある程度）ロックダウンされている。コンテナ内でプロセスを実行し (セキュリティ、安定性、サービスの分離を向上)、アトミック アップデートを提供します (1 つの起動可能なパーティションを起動し、別のパーティションを更新します)。例としては次のようなものがあります。

• Google の Container-Optimized OS は読み取り専用のルート ファイル システムをサポートしていますが、SSH を許可し、GCP でのみ実行されます。
• RancherOSはSSHを実行し、ルートパーティションを保護するために読み取り専用ファイルシステムを使用しません。
• K3OS も Rancher によって開発されていますが、完全な Kubernetes ディストリビューションは実行されません。管理は kubectl 経由で行われますが、SSH がサポートされています。
• AWS Bottlerocket は、不変のルートファイルシステムと SSH サポートを備えた別の OS であり、少なくとも当初は AWS ワークロードに重点を置いています。

唯一の例外は、コンテナ固有のオペレーティング システムの中で最も物議を醸している Talos です。他の OS と同様に、Talos OS は最小限で、パッケージ マネージャーがなく、読み取り専用ファイルシステムのみを使用します (/var と /etc/kubernetes、および /etc/resolv.conf のような一時的な (再起動時にリセットされる) 1 つまたは 2 つの特殊ファイルを除く)。また、アップグレード コントローラーを介して K8s 統合でアップグレードされます。

ただし、Talos OS は、すべての SSH およびコンソール アクセスを廃止し、すべての OS アクセスと管理を API 駆動にすることで、不変インフラストラクチャの概念を他のシステムよりも一歩進めています。 Kubernetes を実行しているノードで実行したいすべての操作、すべてのコンテナの表示、ネットワーク設定の確認などのための API 呼び出しがあります。ただし、ファイル システムのアンマウントなど、ノードで実行すべきでない操作は実行できません。 Talos は、Kubernetes を起動するという 1 つの機能だけを実行する Linux Init システムを完全に書き直すことも選択しました。

ユーザー定義のサービスは管理できません (これらはすべて Kubernetes を通じて管理する必要があります)。これにより、セキュリティがさらに向上し (SSH もコンソールも不要)、メンテナンスが軽減され (ユーザーもパッチも不要)、CVE の影響が軽減されます (ファイル システムは不変で一時的であるため)。 SSH アクセスを放棄し、SRE アクションを制限し、ノードを完全に不変に強制することが望ましいということには同意できないかもしれませんが、これは少し前に不変コンテナに反対する議論でもあり、検討する価値があります。 API 管理のオペレーティング システムを使用すると、大規模な運用と管理にも最適です。ノード、ノードのクラス、またはすべてのノード上のコンテナのログを確認する必要がある場合は、異なるパラメータを持つ同じ API 呼び出しを実行するだけです。

要約する

コンテナ管理は「家畜であってペットではない」という考え方を採用し、更新や修正を展開するときにコンテナを破棄して新しいバージョンを開始する場合は、コンテナをサポートするインフラストラクチャにも同じアプローチを採用することが理にかなっています。コンテナに似た管理モデルを採用し、パッチ適用ではなく更新のためにノードを破棄して再構成するには、ある程度のトレーニングが必要になる場合がありますが、コンテナ固有のオペレーティング システムを採用すると、このモデルを採用し、管理オーバーヘッドを削減し、セキュリティを向上させることができます。コンテナ固有のオペレーティング システムは、システム管理者や開発者が動作させるために構成を変更する必要がないため、人為的エラーや構成ミスによって次のアップグレードが失敗する可能性がなくなり、運用の安定性も向上します。

多くの企業がまだ Kubernetes 導入ライフサイクルの初期段階にあることを考えると、今こそこの次世代オペレーティング システムに慣れる良い機会です。オペレーティング システムと Kubernetes を緊密に結合させることで、Kubernetes クラスター全体を 1 台のコンピューターとして扱うことができ、オーバーヘッドが削減され、セキュリティが強化されます。これにより、コンピューティング インフラストラクチャによって提供されるワークロードと価値に重点が置かれ、API 駆動型データ センターに向けた新たな一歩となります。