クラウドネイティブの不変インフラストラクチャ - CoreOS

コンテナは、アプリケーションを完全にカプセル化し、単純で標準的な操作に抽象化したものです。アプリケーション プロデューサーは、ビルド コマンドを使用して、アプリケーションを標準イメージにパッケージ化します。次に、push コマンドを使用してイメージをイメージ リポジトリにプッシュし、アプリケーションの標準リリースを完了します。アプリケーション ユーザーは pull を使用して標準イメージをダウンロードし、run コマンドを使用して指定された環境を実行して、アプリケーションの迅速な展開を完了します。コンテナはアプリケーションの標準化の問題を完全に解決しますが、複数のコンテナは依然として基礎となる基本オペレーティング システムを共有する必要があり、基本オペレーティング システム自体の多くの問題は解決されません。

1. 不変インフラストラクチャとは何ですか?

現代アーキテクチャに基づくアプリケーションシステムの構築、特にマイクロサービスアーキテクチャの大規模な推進により、システムの規模と複雑さは飛躍的に増大しています。単一の物理マシンから複数のサーバーへの仮想化、そして現在の数十、数百のコンテナインスタンスの規模に至るまで、システムの運用・保守は従来の手作業による手法ではもはや不十分であり、自動化の総合的な推進による運用・保守効率の向上が必要です。

しかし、自動化における最大の障害は、管理オブジェクト、特に基盤となるオペレーティング システムの一貫性です。 Linux オペレーティングシステムには多くのバージョンがあり、一般的に使用される rpm パッケージは 300 ～ 600 個程度あり、柔軟に組み合わせることができます。大規模ノードのバッチ展開、アップグレード、セキュリティ脆弱性管理には大きな課題があります。近年、Kubernetes クラスターの大規模な本番環境障害は、基本的に基盤となるオペレーティング システムによって発生しています。そのため、コンテナの概念に基づいて、基盤となるオペレーティングシステムをさらに標準化し、インフラストラクチャの不変性を実現し、一貫性を向上させることで、コンテナの大規模な運用と保守の現在の課題に対応します。

不変インフラストラクチャとは何ですか? CNCF はクラウド ネイティブを定義するだけでなく、コンテナ、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API など、クラウド ネイティブの代表的なテクノロジも明確に定義しています。その中でも、イミュータブル・インフラストラクチャはクラウドネイティブの代表的な技術であり、概念でもあります。

2. 不変インフラストラクチャの核となる考え方

不変インフラストラクチャの中心的な考え方は、インフラストラクチャのインスタンスは作成されると読み取り専用になるというものです。変更またはアップグレードが必要な場合は、新しいインスタンスに置き換えられます。可変インフラストラクチャではより多くの手動介入が必要となり、オペレーティング システムにさまざまな変更を手動で加える必要があります。不変のインフラストラクチャはより自動化されており、インフラストラクチャとその依存関係は事前に定義されており、新しい変更をトリガーするだけで全体的な変更を完了できます。

コンテナ テクノロジーの場合、イメージを構築すると、そのイメージに基づいてサービスをデプロイできます。問題が発生した場合、既存のコンテナには変更は加えられません。代わりに、コンテナの構築段階から問題が解決され、新しいイメージが再パッケージ化されて構築されます。したがって、コンテナの観点から見ると、イメージは不変のインフラストラクチャです。

不変のインフラストラクチャは徐々にオペレーティング システム レベルにまで浸透し、RancherOS、K3os、CoreOS などの多くのコンテナー化されたオペレーティング システムが形成されています。さまざまなコンテナー オペレーティング システムがありますが、それらすべてに共通するのは、基盤となるインフラストラクチャが不変であることです。上位の業務がどのように変化しても、多数の rpm パッケージがランダムに組み合わせられてリリースされるのではなく、基盤となるオペレーティング システムが全体としてリリースされます。最も単純な例は、Android 携帯電話オペレーティング システムです。 ROMは完全版です。不変とは、変更されないという意味ではなく、オペレーティング システムがパッケージ化されるときに、すべてのカーネルと rpm パッケージが標準化され、全体としてアップグレード、ロールバック、および保守されることを意味します。

3. コンテナOS

コンテナコンセプトに基づいてオペレーティングシステムを再構築します。まず、インフラストラクチャは不変であり、一貫性が向上します。ログ記録、監視、その他多くのツールなど、オペレーティング システムのすべての非コア機能が削除され、オンデマンドでコンテナーの形式で実行されるようにスケジュールされます。つまり、すべてがコンテナー内で実行されます。第二に、コンテナはさまざまなコンポーネントとワークロードを実行し、基盤となるコア機能を最大限に標準化し、構成ファイルを通じて特定のカスタマイズ機能を提供するために使用されます。これら 2 つの最も基本的な特性を満たすことで、基本的にインフラストラクチャの不変性が実現されます。下の図に示すように、よく知られているコンテナ オペレーティング システムがいくつかあります。

4. コアOSとその利点

ほぼすべてのパブリック クラウド ベンダーがすぐにこれに追随し、百花繚乱、百の学派の争いが起こりました。 2015 年、Red Hat は、コンテナ運用環境の問題を解決し、基盤となるオペレーティング システムの管理ワークロードを簡素化することを目指して、Atomic オペレーティング システムを提案しました。 2018 年には、CoreOS の買収と合併によりオープンソース コミュニティ標準が統一され、CoreOS と Atomic が合併して RHCOS が誕生しました。 Atomic の利点は、さまざまなハードウェアベンダーのドライバーとの互換性が優れていることであり、CoreOS の利点は、ignition インストール方式や etcd に基づくマルチクラスター管理など、Kubernetes との統合です。 Atomic と CoreOS の統合により、コンテナ オペレーティング システムの分野で事実上の標準が確立され、一貫性、自己メンテナンス、不変イメージ、ワンクリック アップグレード、ワンクリック リワインドを備えたコンテナ オペレーティング システムが構築され、基盤となるインフラストラクチャの複雑さが簡素化されました。

5. まとめ

オープンソース分野で Red Hat が勝利できる最大の理由は、Linux カーネル、ハードウェア サポート、オープンソース プロジェクトの統合機能、そしてオープンソース エコロジーと収益性のバランスです。

CoreOS コンテナ オペレーティング システムには、エンタープライズ ディストリビューション RH CoreOS とコミュニティ ディストリビューション Fedora CoreOS があります。コミュニティ ディストリビューションのカーネルは比較的迅速に更新され、基本的に Fedora Linux カーネルと一致しています。

RH CoreOS ディストリビューションのカーネルは、RH Linux カーネルと一致しています。基本的には、コミュニティ バージョンが安定したユーザー フィードバックを得て、QA テストが完了した後にのみリリースされます。そのため、エンタープライズ バージョンはコミュニティ バージョンよりも比較的遅く、機能も少なくなりますが、より安定しており、メーカーの技術サポートも受けられます。 CoreOS の機能と検証は、基本的に RH CoreOS の最新バージョンに基づいています。

同時に、CoreOS は、reflink 機能 (ディスク領域の節約、cow メカニズム)、eBPF、XDP (ネットワーク アクセラレーション)、CGROUPV2 (より優れたリソース制限と分離の実現)、nft (より強力なファイアウォール ツール) などの RHEL8 カーネルの新機能を継承しており、その他の新機能を直接使用できます。

この記事はWeChatの公開アカウント「Juzijia」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合はJuzijia公式アカウントまでご連絡ください。