アーキテクチャー

クラスター管理者は、OpenShift Container Platform インストールプログラム を使用してクラスターをインストールし、デプロイできます。

コントロールプレーン は、クラスター内のワーカーノードと Pod を管理します。マシン設定プール (MCP) を使用してノードを設定できます。MCP は、コントロールプレーンコンポーネントやユーザーワークロードなど、それらが処理するリソースに基づくマシンのグループです。OpenShift Container Platform は、ホストに異なるロールを割り当てます。これらのロールは、クラスター内のマシンの機能を定義します。クラスターには、標準のコントロールプレーンとワーカーロールタイプの定義が含まれています。

Operator を使用して、コントロールプレーン上のサービスをパッケージ化、デプロイ、および管理できます。Operator は、以下のサービスを提供するため、OpenShift Container Platform の重要なコンポーネントです。

開発者は、さまざまなツール、メソッド、および形式を使用して、固有の要件に基づいて コンテナー化されたアプリケーションを開発 できます。次に例を示します。

Kubernetes マニフェストを作成して、Git リポジトリーに保存することもできます。Kubernetes は、Pod と呼ばれる基本ユニットで動作します。Pod は、クラスターで実行中のプロセスの単一インスタンスです。Pod には 1 つ以上のコンテナーを含めることができます。Pod のセットとそのアクセスポリシーをグループ化することで、サービスを作成できます。サービスは、Pod が作成および破棄されるときに使用する他のアプリケーションの永続的な内部 IP アドレスおよびホスト名を提供します。Kubernetes は、アプリケーションのタイプに基づいてワークロードを定義します。

クラスター管理者は、以下の Red Hat Enterprise Linux Core OS (RHCOS) タスクを実行できます。

OpenShift Container Platform のインストレーションプログラムは、クラスターを作成するのに必要な Ignition 設定ファイルを作成します。Red Hat Enterprise Linux CoreOS (RHCOS) は、初期設定時に Ignition を使用して、パーティション分割、フォーマット、ファイルの書き込み、ユーザーの設定などの一般的なディスクタスクを実行します。初回起動時に、Ignition はインストールメディアまたは指定する場所からその設定を読み取り、設定をマシンに適用します。

Ignition の仕組み、OpenShift Container Platform クラスター内の Red Hat Enterprise Linux Core OS (RHCOS) マシンのプロセス、Ignition 設定ファイルの表示、およびインストール後の Ignition 設定の変更について学習できます。

継続的インテグレーション/継続的デリバリー (CI/CD) の方法論を使用して、アプリケーション開発のすべてのステージを自動化できます。GitOps の方法を使用して、OpenShift Container Platform クラスターおよびアプリケーションを管理し、再作成するための反復可能かつ予測可能なプロセスを作成することもできます。

クラスターリソースに宣言型の GitOps 継続的デリバリーツールである ArgoCD を使用できます。

受付プラグイン を使用して、OpenShift Container Platform の機能を調整できます。リソースリクエストが認証および承認された後、受付プラグインはマスター API へのリソース要求をインターセプトして、リソース要求を検証し、スケーリングポリシーが遵守されていることを確認します。受付プラグインは、セキュリティーポリシー、リソース制限、または設定要件を適用するために使用されます。

OpenShift Container Platform は、コンテナー化されたアプリケーションを開発し、実行するためのプラットフォームです。アプリケーションおよびアプリケーションをサポートするデータセンターで、わずか数台のマシンとアプリケーションから、何百万ものクライアントに対応する何千ものマシンに拡張できるように設計されています。

Kubernetes をその基盤とする OpenShift Container Platform には、大規模な通信、ビデオストリーミング、ゲーミング、バンキングその他のアプリケーションのエンジンと同様に機能する技術が組み込まれています。Red Hat のオープンテクノロジーに実装することで、コンテナー化されたアプリケーションを、単一クラウドを超えてオンプレミスおよびマルチクラウド環境へと拡張することが可能です。

2.1.3. OpenShift Container Platform の概要

OpenShift Container Platform は、以下を含むエンタープライズ対応の拡張機能を Kubernetes に提供します。

• ハイブリッドクラウドのデプロイメント。OpenShift Container Platform クラスターをさまざまなパブリッククラウドのプラットフォームまたはお使いのデータセンターにデプロイできます。
• Red Hat の統合されたテクノロジー。OpenShift Container Platform の主なコンポーネントは、Red Hat Enterprise Linux (RHEL) と関連する Red Hat の技術に由来します。OpenShift Container Platform は、Red Hat の高品質エンタープライズソフトウェアの集中的なテストや認定の取り組みによる数多くの利点を活用しています。
• オープンソースの開発モデル。開発はオープンソースで行われ、ソースコードはソフトウェアのパブリックリポジトリーから入手可能です。このオープンな共同作業が迅速な技術と開発を促進します。

Kubernetes はアプリケーションの管理で威力を発揮しますが、プラットフォームレベルの各種要件やデプロイメントプロセスを指定したり、管理したりすることはありません。そのため、OpenShift Container Platform 4.6 が提供する強力かつ柔軟なプラットフォーム管理ツールとプロセスは重要な利点の 1 つとなります。以下のセクションでは、OpenShift Container Platform のいくつかのユニークな機能と利点について説明します。

2.1.3.1. カスタムオペレーティングシステム

OpenShift Container Platform は、Red Hat Enterprise Linux CoreOS (RHCOS) を使用します。これは、OpenShift Container Platform からコンテナー化されたアプリケーションを実行するために特別に設計されたコンテナー指向のオペレーティングシステムであり、新しいツールと連携して、迅速なインストール、Operator ベースの管理、および簡素化されたアップグレードを提供します。

RHCOS には以下が含まれます。

• Ignition。OpenShift Container Platform が使用するマシンを最初に起動し、設定するための初回起動時のシステム設定です。
• CRI-O、Kubernetes ネイティブコンテナーランタイム実装。これはオペレーティングシステムに密接に統合し、Kubernetes の効率的で最適化されたエクスペリエンスを提供します。CRI-O は、コンテナーを実行、停止および再起動を実行するための機能を提供します。これは、OpenShift Container Platform 3 で使用されていた Docker Container Engine を完全に置き換えます。
• Kubelet、Kubernetes のプライマリーノードエージェント。 これは、コンテナーを起動し、これを監視します。

OpenShift Container Platform 4.6 ではすべてのコントロールプレーンマシンで RHCOS を使用する必要がありますが、Red Hat Enterprise Linux (RHEL) をコンピュートまたはワーカーマシンのオペレーティングシステムとして使用することができます。RHEL のワーカーを使用する選択をする場合、すべてのクラスターマシンに 対して RHCOS を使用する場合よりも多くのシステムメンテナーンスを実行する必要があります。

2.1.3.2. 単純化されたインストールおよび更新プロセス

OpenShift Container Platform 4.6 では、適切なパーミッションを持つアカウントを使用している場合、単一のコマンドを実行し、いくつかの値を指定することで、サポートされているクラウドに実稼働用のクラスターをデプロイすることができます。また、サポートされているプラットフォームを使用している場合、クラウドのインストールをカスタマイズしたり、クラスターをお使いのデータセンターにインストールすることも可能です。

クラスターのすべてのマシンが RHCOS を使用している場合、OpenShift Container Platform の更新またはアップグレードは、高度に自動化された単純なプロセスで実行できます。OpenShift Container Platform は、各マシンで実行される、オペレーティングシステム自体を含むシステムとサービスを中央のコントロールプレーンから完全に制御するので、アップグレードは自動イベントになるように設計されています。クラスターに RHEL のワーカーマシンが含まれる場合、コントロールプレーンの使用には単純化された更新プロセスの利点があるものの、RHEL マシンのアップグレードには、より多くのタスクの実行が必要になります。

2.1.3.3. その他の主な機能

Operator は、OpenShift Container Platform 4.6 コードベースの基本単位であるだけでなく、アプリケーションとアプリケーションで使用されるソフトウェアコンポーネントをデプロイするための便利な手段です。Operator をプラットフォームの基盤として使用することで、OpenShift Container Platform ではオペレーティングシステムおよびコントロールプレーンアプリケーションの手動によるアップグレードが不要になります。Cluster Version Operator や Machine Config Operator などの OpenShift Container Platform の Operator が、それらの重要なコンポーネントのクラスター全体での管理を単純化します。

Operator Lifecycle Manager (OLM) および OperatorHub は、Operator を保管し、アプリケーションの開発やデプロイを行う人々に Operator を提供する機能を提供します。

Red Hat Quay Container Registry は、ほとんどのコンテナーイメージと Operator を OpenShift Container Platform クラスターに提供する Quay.io コンテナーレジストリーです。Quay.io は、何百万ものイメージやタグを保存する Red Hat Quay の公開レジストリー版です。

OpenShift Container Platform での Kubernetes のその他の拡張には、SDN (Software Defined Networking)、認証、ログ集計、監視、およびルーティングの強化された機能が含まれます。OpenShift Container Platform は、包括的な Web コンソールとカスタム OpenShift CLI (oc) インタフェースも提供します。

2.1.3.4. OpenShift Container Platform のライフサイクル

以下の図は、OpenShift Container Platform の基本的なライフサイクルを示しています。

• OpenShift Container Platform クラスターの作成
• クラスターの管理
• アプリケーションの開発とデプロイ
• アプリケーションのスケールアップ

図2.1 OpenShift Container Platform の概要

OpenShift Container Platform インストールプログラムは柔軟性を提供します。インストールプログラムを使用して、インストールプログラムがプロビジョニングし、クラスターで維持するインフラストラクチャーでクラスターをデプロイしたり、ユーザーが独自に準備し、維持するインフラストラクチャーでクラスターをデプロイしたりすることができます。

OpenShift Container Platform クラスターの基本的な 2 つのタイプとして、インストーラーでプロビジョニングされるインフラストラクチャークラスターとユーザーによってプロビジョニングされるインフラストラクチャークラスターがあります。

これらのクラスターのタイプにはどちらにも以下の特徴があります。

同一のインストールプログラムを使用してこれらクラスターの両方のタイプをデプロイできます。インストールプログラムで生成される主なアセットは ブートストラップ、マスターおよびワーカーマシンの Ignition 設定です。これらの 3 つの設定および適切に設定されたインフラストラクチャーを使用して、OpenShift Container Platform クラスターを起動することができます。

OpenShift Container Platform インストールプログラムは、クラスターのインストールを管理するために一連のターゲットおよび依存関係を使用します。インストールプログラムには、達成する必要のある一連のターゲットが設定され、それぞれのターゲットには一連の依存関係が含まれます。各ターゲットはそれぞれの依存関係の条件が満たされ次第、別個に解決されるため、インストールプログラムは複数のターゲットを並行して達成できるように動作します。最終的なターゲットはクラスターを実行することです。コマンドを実行するのではなく依存関係の条件を満たすことにより、インストールプログラムは、コマンドを実行してコンポーネントを再度作成する代わりに、既存のコンポーネントを認識し、それらを使用することができます。

以下の図は、インストールのターゲットと依存関係のサブセットを示しています。

図3.1 OpenShift Container Platform インストールのターゲットおよび依存関係

インストール後に、各クラスターマシンは Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングマシンとして使用します。RHCOS は Red Hat Enterprise Linux (RHEL) の不変のコンテナーホストのバージョンであり、デフォルトで SELinux が有効にされた RHEL カーネルを特長としています。これには、Kubernetes ノードエージェントである kubelet や、Kubernetes に対して最適化される CRI-O コンテナーランタイムが含まれます。

OpenShift Container Platform 4.6 クラスターのすべてのコントールプレーンは、Ignition と呼ばれる最初の起動時に使用される重要なプロビジョニングツールが含まれる RHCOS を使用する必要があります。このツールは、クラスターのマシンの設定を可能にします。オペレーティングシステムの更新は、Operator によってクラスター全体に展開されるコンテナーイメージに組み込まれる Atomic OSTree リポジトリーとして提供されます。実際のオペレーティングシステムの変更については、rpm-ostree を使用する atomic 操作として各マシンでインプレースで実行されます。これらのテクノロジーを組み合わせて使用することにより、OpenShift Container Platform では、プラットフォーム全体を最新の状態に保つインプレースアップグレードで、その他のアプリケーションをクラスターで管理するかのようにオペレーティングシステムを管理することができます。これらのインプレースアップグレードにより、オペレーションチームの負担を軽減することができます。

RHCOS をすべてのクラスターマシンのオペレーティングシステムとして使用する場合、クラスターはオペレーティングシステムを含む、そのコンポーネントとマシンのすべての側面を管理します。このため、インストールプログラムと Machine Config Operator のみがマシンを変更することができます。インストールプログラムは Ignition 設定ファイルを使用して各マシンの状態を設定し、Machine Config Operator はインストール後に、新規証明書またはキーの適用などのマシンへの変更を実行します。

3.1.2. インストールプロセス

OpenShift Container Platform クラスターをインストールする場合は、Red Hat OpenShift Cluster Manager サイトの該当する インフラストラクチャープロバイダー ページからインストールプログラムをダウンロードします。このサイトでは以下を管理しています。

• アカウントの REST API
• 必要なコンポーネントを取得するために使用するプルシークレットであるレジストリートークン
• クラスターのアイデンティティーを Red Hat アカウントに関連付けて使用状況のメトリクスの収集を容易にするクラスター登録

OpenShift Container Platform 4.6 では、インストールプログラムは、一連のアセットに対して一連のファイル変換を実行する Go バイナリーファイルです。インストールプログラムと対話する方法は、インストールタイプによって異なります。

• インストーラーでプロビジョニングされるインフラストラクチャーのクラスターの場合、インフラストラクチャーのブートストラップおよびプロビジョニングは、ユーザーが独自に行うのではなくインストールプログラムが代行します。インストールプログラムは、クラスターをサポートするために必要なネットワーク、マシン、およびオペレーティングシステムのすべてを作成します。
• クラスターのインフラストラクチャーを独自にプロビジョニングし、管理する場合には、ブートストラップマシン、ネットワーク、負荷分散、ストレージ、および個々のクラスターマシンを含む、すべてのクラスターインフラストラクチャーおよびリソースを指定する必要があります。

インストール時には、お使いのマシンタイプ用の install-config.yaml という名前のインストール設定ファイル、Kubernetes マニフェスト、および Ingition 設定ファイルの 3 つのファイルセットを使用します。

重要

インストール時に、Kubernetes および基礎となる RHCOS オペレーティングシステムを制御する Ignition 設定ファイルを変更することができます。ただし、これらのオブジェクトに対して加える変更の適合性を確認するための検証の方法はなく、これらのオブジェクトを変更するとクラスターが機能しなくなる可能性があります。これらのオブジェクトを変更する場合、クラスターが機能しなくなる可能性があります。このリスクがあるために、変更方法についての文書化された手順に従っているか、または Red Hat サポートが変更することを指示した場合を除き、Kubernetes および Ignition 設定ファイルの変更はサポートされていません。

インストール設定ファイルは Kubernetes マニフェストに変換され、その後マニフェストは Ignition 設定にラップされます。インストールプログラムはこれらの Ignition 設定ファイルを使用してクラスターを作成します。

インストール設定ファイルはインストールプログラムの実行時にすべてプルーニングされるため、再び使用する必要のあるすべての設定ファイルをバックアップしてください。

重要

インストール時に設定したパラメーターを変更することはできませんが、インストール後に数多くのクラスター属性を変更することができます。

インストーラーでプロビジョニングされるインフラストラクチャーでのインストールプロセス

デフォルトのインストールタイプは、インストーラーでプロビジョニングされるインフラストラクチャーです。デフォルトで、インストールプログラムはインストールウィザードとして機能し、独自に判別できない値の入力を求めるプロンプトを出し、残りのパラメーターに妥当なデフォルト値を提供します。インストールプロセスは、高度なインフラストラクチャーシナリオに対応するようカスタマイズすることもできます。インストールプログラムは、クラスターの基盤となるインフラストラクチャーをプロビジョニングします。

標準クラスターまたはカスタマイズされたクラスターのいずれかをインストールすることができます。標準クラスターの場合、クラスターをインストールするために必要な最小限の詳細情報を指定します。カスタマイズされたクラスターの場合、コントロールプレーンが使用するマシン数、クラスターがデプロイする仮想マシンのタイプ、または Kubernetes サービスネットワークの CIDR 範囲などのプラットフォームについての詳細を指定することができます。

可能な場合は、この機能を使用してクラスターインフラストラクチャーのプロビジョニングと保守の手間を省くようにしてください。他のすべての環境の場合には、インストールプログラムを使用してクラスターインフラストラクチャーをプロビジョニングするために必要なアセットを生成できます。

インストーラーでプロビジョニングされるインフラストラクチャークラスターの場合、OpenShift Container Platform は、オペレーティングシステム自体を含むクラスターのすべての側面を管理します。各マシンは、それが参加するクラスターでホストされるリソースを参照する設定に基づいて起動します。この設定により、クラスターは更新の適用時に自己管理できます。

ユーザーによってプロビジョニングされるインフラストラクチャーを使用したインストールプロセス

OpenShift Container Platform はユーザーが独自にプロビジョニングするインフラストラクチャーにインストールすることもできます。インストールプログラムを使用してクラスターインフラストラクチャーのプロビジョニングに必要なアセットを生成し、クラスターインフラストラクチャーを作成し、その後にクラスターをプロビジョニングしたインフラストラクチャーにデプロイします。

インストールプログラムがプロビジョニングするインフラストラクチャーを使用しない場合、以下を含むクラスターリソースを管理し、維持する必要があります。

• クラスターを設定するコントロールプレーンおよびコンピュートマシンの基礎となるインフラストラクチャー
• ロードバランサー
• DNS レコードおよび必要なサブネットを含むクラスターネットワーク
• クラスターインフラストラクチャーおよびアプリケーションのストレージ

クラスターでユーザーによってプロビジョニングされるインフラストラクチャーを使用する場合には、RHEL コンピュートマシンをクラスターに追加するオプションを使用できます。

インストールプロセスの詳細

クラスターの各マシンにはプロビジョニング時にクラスターについての情報が必要になるため、OpenShift Container Platform は初期設定時に一時的な bootstrap マシンを使用し、必要な情報を永続的なコントロールマシンに提供します。これは、クラスターの作成方法を記述する Ignition 設定ファイルを使用して起動されます。ブートストラップマシンは、コントロールプレーンを設定するマスターマシンを作成します。その後、コントロールプレーンマシンはコンピュートマシン (ワーカーマシンとしても知られる) を作成します。以下の図はこのプロセスを示しています。

図3.2 ブートストラップ、コントロールプレーンおよびコンピュートマシンの作成

クラスターマシンを初期化した後、ブートストラップマシンは破棄されます。すべてのクラスターがこのブートストラッププロセスを使用してクラスターを初期化しますが、ユーザーがクラスターのインフラストラクチャーをプロビジョニングする場合には、多くの手順を手動で実行する必要があります。

重要

インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。

クラスターのブートストラップには、以下のステップが関係します。

1. ブートストラップマシンが起動し、コントロールプレーンマシンの起動に必要なリモートリソースのホスティングを開始します。(ユーザーがインフラストラクチャーをプロビジョニングする場合には手動の介入が必要になります)。
2. ブートストラップマシンは、単一ノードの etcd クラスターと一時的な Kubernetes コントロールプレーンを起動します。
3. コントロールプレーンマシンは、ブートストラップマシンからリモートリソースをフェッチし、起動を終了します。(ユーザーがインフラストラクチャーをプロビジョニングする場合には手動の介入が必要になります)。
4. 一時的なコントロールプレーンは、実稼働コントロールプレーンマシンに対して実稼働コントロールプレーンをスケジュールします。
5. Cluster Version Operator (CVO) はオンラインになり、etcd Operator をインストールします。etcd Operator はすべてのコントロールプレーンノードで etcd をスケールアップします。
6. 一時的なコントロールプレーンはシャットダウンし、コントロールを実稼働コントロールプレーンに渡します。
7. ブートストラップマシンは OpenShift Container Platform コンポーネントを実稼働コントロールプレーンに挿入します。
8. インストールプログラムはブートストラップマシンをシャットダウンします。(ユーザーがインフラストラクチャーをプロビジョニングする場合には手動の介入が必要になります)。
9. コントロールプレーンはコンピュートノードを設定します。
10. コントロールプレーンは一連の Operator の形式で追加のサービスをインストールします。

このブートストラッププロセスの結果として、OpenShift Container Platform クラスターが完全に実行されます。次に、クラスターはサポートされる環境でのコンピュートマシンの作成など、日常の操作に必要な残りのコンポーネントをダウンロードし、設定します。

インストールのスコープ

OpenShift Container Platform インストールプログラムのスコープは意図的に狭められています。単純さを確保し、確実にインストールを実行できるように設計されているためです。インストールが完了した後に数多くの設定タスクを実行することができます。

関連情報

• OpenShift Container Platform 設定リソースについての詳細は、利用可能なクラスターのカスタマイズ について参照してください。

OpenShift Update Service (OSUS) は、Red Hat Enterprise Linux CoreOS (RHCOS) を含む OpenShift Container Platform に OTA (over-the-air) 更新を提供します。コンポーネント Operator のグラフ、または 頂点 とそれらを結ぶ 辺 を含む図表が提示されます。グラフのエッジでは、安全に更新できるバージョンが表示されます。頂点は、マネージドクラスターコンポーネントの意図された状態を指定する更新ペイロードです。

クラスター内の Cluster Version Operator (CVO) は、OpenShift Update Service をチェックして、グラフの現在のコンポーネントバージョンとグラフの情報に基づき、有効な更新および更新パスを確認します。ユーザーが更新をリクエストすると、CVO はその更新のリリースイメージを使ってクラスターを更新します。リリースアーティファクトは、コンテナーイメージとして Quay でホストされます。

OpenShift Update Service が互換性のある更新のみを提供できるようにするために、リリース検証 Pipeline で自動化を支援します。それぞれのリリースアーティファクトについて、他のコンポーネントパッケージだけでなくサポートされているクラウドプラットフォームおよびシステムアーキテクチャーとの互換性の有無が検証されます。Pipeline がリリースの適合性を確認した後に、OpenShift Update Service は更新が利用可能であることを通知します。

連続更新モード中は、2 つのコントローラーが実行されます。1 つのコントローラーはペイロードマニフェストを絶えず更新し、そのマニフェストをクラスターに適用し、Operator が利用可能か、アップグレード中か、または失敗しているかに応じて Operator の制御されたロールアウトのステータスを出力します。2 つ目のコントローラーは OpenShift Update Service をポーリングして、更新が利用可能かどうかを判別します。

更新プロセスで、Machine Config Operator (MCO) は新規設定をクラスターマシンに適用します。MCO は、マシン設定プールの maxUnavailable フィールドによって指定されるノードの数を分離し、それらを利用不可としてマークします。デフォルトで、この値は 1 に設定されます。次に、MCO は新しい設定を適用して、マシンを再起動します。

Red Hat Enterprise Linux (RHEL) マシンをワーカーとして使用する場合、まず OpenShift API をそれらのマシンで更新する必要があるため、MCO は kubelet を更新しません。

新規バージョンの仕様は古い kubelet に適用されるため、RHEL マシンを Ready 状態に戻すことができません。マシンが利用可能になるまで更新を完了することはできません。ただし、利用不可のノードの最大数は、その数のマシンがサービス停止状態のマシンとして分離されても通常のクラスター操作が継続できるようにするために設定されます。

OpenShift Update Service は Operator および 1 つ以上のアプリケーションインスタンスで設定されます。

Operator の 管理状態 は、Operator が設計通りにクラスター内の関連するコンポーネントのリソースをアクティブに管理しているかどうかを定めます。Operator が unmanaged 状態に設定されている場合、これは設定の変更に応答せず、更新を受信しません。

これは非実稼働クラスターやデバッグ時に便利ですが、管理外の状態の Operator はサポートされず、クラスター管理者は個々のコンポーネント設定およびアップグレードを完全に制御していることを前提としています。

Operator は以下の方法を使用して管理外の状態に設定できます。

コンテナープレーンはコントロールプレーンマシン (別称 マスターマシン) から設定されており、OpenShift Container Platform クラスターを管理します。コントロールプレーンマシンは、コンピュートマシン (ワーカーマシンとしても知られる) のワークロードを管理します。クラスター自体は、Cluster Version Operator、Machine Config Operator、および個々の Operator のアクションによって、マシンへのすべてのアップグレードを管理します。

コンテナーを使用したアプリケーションの開発にはさまざまな方法を状況に合わせて使用できます。単一コンテナーの開発から、最終的にそのコンテナーの大企業のミッションクリティカルなアプリケーションとしてのデプロイに対応する一連の方法の概要を示します。それぞれのアプローチと共に、コンテナー化されたアプリケーションの開発に使用できる各種のツール、フォーマットおよび方法を説明します。扱う内容は以下の通りです。

たとえば、アプリケーションをコンテナー化しようと考えているとします。

その場合、まず必要になるのは buildah や docker などのコンテナーをビルドするためのツール、およびコンテナーの内部で実行されることを記述したファイルです。 これは通常、Dockerfile になります。

次に、作成したコンテナーイメージをプッシュする場所が必要になります。ここからコンテナーイメージをプルすると、任意の場所で実行することができます。この場所はコンテナーレジストリーになります。

各コンポーネントのサンプルは、ほとんどの Linux オペレーティングシステムにデフォルトでインストールされています。 ただし Dockerfile はユーザーが各自で用意する必要があります。

以下の図は、イメージをビルドし、プッシュするプロセスを示しています。

図5.1 単純なコンテナー化アプリケーションを作成し、レジストリーにプッシュする

Red Hat Enterprise Linux (RHEL) をオペレーティングシステムとして実行しているコンピューターを使用している場合、コンテナー化されているアプリケーションを作成するプロセスには以下の手順が必要になります。

コンテナーイメージをビルドし、レジストリーにプッシュし、それらを実行するプロセスについての詳細は、Custom image builds with Buildah を参照してください。

5.2.2. ベースイメージのオプション

アプリケーションをビルドするために選択するベースイメージには、Linux システムがアプリケーションのように表示されるソフトウェアのセットが含まれます。ユーザーが独自のイメージをビルドする場合、ソフトウェアはそのファイルシステム内に配置され、ファイルシステムはオペレーティングシステムのように表示されます。このベースイメージの選択により、コンテナーの将来の安全性、効率性およびアップグレードの可能性に大きな影響を与えます。

Red Hat は、Red Hat Universal Base Images (UBI) と呼ばれるベースイメージの新たなセットを提供します。これらのベースイメージは、Red Hat Enterprise Linux をベースとし、Red Hat が過去に提供してきたベースイメージに類似したものですが、次の大きな違いがあります。UBI は、Red Hat のサブスクリプションなしの再ディストリビューションが可能です。 そのため、UBI イメージの共有方法を検討したり、環境ごとに異なるイメージを作成する必要なしに、UBI イメージでアプリケーションをビルドすることができます。

これらの UBI イメージは、標準で最小限の init バージョンです。また、Red Hat Software Collections イメージを、Node.js、Perl、Python などの特定のランタイム環境に依存するアプリケーションの基盤として使用することができます。これらのランタイムベースイメージの特殊なバージョンは Source-to-image (S2I) イメージと呼ばれています。S2I イメージを使用して、コードを、そのコードを実行できるベースイメージ環境に挿入することができます。

S2I イメージは、以下の図に示すように、OpenShift Container Platform Web UI のCatalog → Developer Catalog を選択することにより直接使用することができます。

図5.2 特定のランタイムを必要とするアプリケーションの S2I ベースイメージを選択する

コンテナーイメージは、コンテナー化されたアプリケーション用の基本的なビルディングブロックですが、OpenShift Container Platform などの Kubernetes 環境でそのアプリケーションを管理し、デプロイするには、より多くの情報が必要になります。イメージ作成後に実行される通常の手順は以下のとおりです。

アプリケーションを他者が実行できるようにする場合、アプリケーションを Operator としてパッケージ化し、デプロイすることが適切である場合があります。前述のように、Operator は、ライフサイクルコンポーネントをアプリケーションに追加し、インストール後すぐにアプリケーションを実行するジョブが完了していないことを認識します。

アプリケーションを Operator として作成する場合、アプリケーションを実行し、維持する方法についての独自のノウハウを盛り込むことができます。アプリケーションのアップグレード、バックアップ、スケーリング、状態のトラッキングなどを行う機能を組み込むことができます。アプリケーションを正しく設定すれば、Operator の更新などのメンテナーンスタスクは、Operator のユーザーに非表示の状態で自動的に実行されます。

役に立つ Operator の一例として、データを特定のタイミングで自動的にバックアップするように設定された Operator を挙げることができます。Operator は設定されたタイミングでのアプリケーションのバックアップを管理するため、システム管理者はバックアップのタイミングを覚えておく必要がありません。

データのバックアップや証明書のローテーションなど、これまで手作業で行われていたアプリケーションのメンテナーンスは、Operator によって自動化されます。

Red Hat Enterprise Linux CoreOS (RHCOS) は、自動化されたリモートアップグレード機能を備えた Red Hat Enterprise Linux (RHEL) の品質基準を提供することにより、次世代の単一目的コンテナーオペレーティングシステムテクノロジーを表しています。

RHCOS は、すべての OpenShift Container Platform マシンの 1 つの OpenShift Container Platform 4.6 コンポーネントとしてのみサポートされます。RHCOS は、OpenShift Container Platform のコントロールプレーンまたはマスターマシン向けに唯一サポートされるオペレーティングシステムです。RHCOS はすべてのクラスターマシンのデフォルトオペレーティングシステムですが、 RHEL をオペレーティングシステムとして使用するコンピュートマシン (ワーカーマシンとしても知られる) を作成することもできます。RHCOS を OpenShift Container Platform 4.6 にデプロイするには、以下の 2 つの一般的な方法があります。

ブートストラップマシンをデプロイするのに使用される Ignition 設定ファイルを表示するには、以下のコマンドを実行します。

$ openshift-install create ignition-configs --dir $HOME/testconfig

いくつかの質問に回答すると、bootstrap.ign、master.ign、worker.ign ファイルが入力したディレクトリーに表示されます。

bootstrap.ign ファイルの内容を確認するには、そのファイルを jq フィルターでそのファイルをパイプします。以下は、そのファイルの抜粋です。

$ cat $HOME/testconfig/bootstrap.ign | jq
\\{
  "ignition": \\{
        "config": \\{},
  "storage": \\{
        "files": [
          \\{
            "filesystem": "root",
            "path": "/etc/motd",
            "user": \\{
              "name": "root"
            },
            "append": true,
            "contents": \\{
              "source": "data:text/plain;charset=utf-8;base64,VGhpcyBpcyB0aGUgYm9vdHN0cmFwIG5vZGU7IGl0IHdpbGwgYmUgZGVzdHJveWVkIHdoZW4gdGhlIG1hc3RlciBpcyBmdWxseSB1cC4KClRoZSBwcmltYXJ5IHNlcnZpY2UgaXMgImJvb3RrdWJlLnNlcnZpY2UiLiBUbyB3YXRjaCBpdHMgc3RhdHVzLCBydW4gZS5nLgoKICBqb3VybmFsY3RsIC1iIC1mIC11IGJvb3RrdWJlLnNlcnZpY2UK",

bootstrap.ign ファイルに一覧表示されたファイルの内容をデコードするには、そのファイルの内容を表す base64 でエンコードされたデータ文字列を base64 -d コマンドに渡します。以下に示すのは、上記の出力からブートストラップマシンに追加された /etc/motd ファイルの内容の使用例です。

$ echo VGhpcyBpcyB0aGUgYm9vdHN0cmFwIG5vZGU7IGl0IHdpbGwgYmUgZGVzdHJveWVkIHdoZW4gdGhlIG1hc3RlciBpcyBmdWxseSB1cC4KClRoZSBwcmltYXJ5IHNlcnZpY2UgaXMgImJvb3RrdWJlLnNlcnZpY2UiLiBUbyB3YXRjaCBpdHMgc3RhdHVzLCBydW4gZS5nLgoKICBqb3VybmFsY3RsIC1iIC1mIC11IGJvb3RrdWJlLnNlcnZpY2UK | base64 --decode

This is the bootstrap machine; it will be destroyed when the master is fully up.

The primary service is "bootkube.service". To watch its status, run, e.g.:

journalctl -b -f -u bootkube.service

これらのコマンドを master.ign と worker.ign ファイル上で繰り返し実行し、マシンタイプごとの Ignition 設定ファイルのソースを参照します。 ブートストラップマシンから Ignition 設定を取得する方法を特定する、worker.ign についての以下のような行が表示されるはずです。

"source": "https://api.myign.develcluster.example.com:22623/config/worker",

bootstrap.ign ファイルについて、以下のいくつかの点に留意してください

Machine 設定プールはノードのクラスターおよびそれらの対応するマシン設定を管理します。マシン設定にはクラスターの設定情報が含まれます。既知のすべてのマシン設定プールを一覧表示するには、以下を実行します。

$ oc get machineconfigpools

NAME   CONFIG                                  UPDATED UPDATING DEGRADED
master master-1638c1aea398413bb918e76632f20799 False   False    False
worker worker-2feef4f8288936489a5a832ca8efe953 False   False    False

すべてのマシン設定を一覧表示するには、以下を実行します。

$ oc get machineconfig

NAME                                      GENERATEDBYCONTROLLER   IGNITIONVERSION   CREATED   OSIMAGEURL

00-master                                 4.0.0-0.150.0.0-dirty   3.1.0             16m
00-master-ssh                             4.0.0-0.150.0.0-dirty                     16m
00-worker                                 4.0.0-0.150.0.0-dirty   3.1.0             16m
00-worker-ssh                             4.0.0-0.150.0.0-dirty                     16m
01-master-kubelet                         4.0.0-0.150.0.0-dirty   3.1.0             16m
01-worker-kubelet                         4.0.0-0.150.0.0-dirty   3.1.0             16m
master-1638c1aea398413bb918e76632f20799   4.0.0-0.150.0.0-dirty   3.1.0             16m
worker-2feef4f8288936489a5a832ca8efe953   4.0.0-0.150.0.0-dirty   3.1.0             16m

Machine Config Operator が Machineconfig を適用するときの動作は Ignition とは若干異なります。マシン設定は (00* から 99* までの) 順序で読み取られます。マシン設定内のラベルは、それぞれのノードのタイプ (マスターまたはワーカー) を特定します。同じファイルが複数のマシン設定ファイルに表示される場合、最後のファイルが有効になります。たとえば、99* ファイルに出現するファイルは、00* ファイルに出現する同一のファイルを置き換えます。入力された MachineConfig オブジェクトはレンダリングされた MachineConfig オブジェクトに結合されます。 これは Operator のターゲットとして使用され、マシン設定プールで確認できる値です。

マシン設定から管理されているファイルを表示するには、特定の MachineConfig オブジェクト内で “Path:" を検索します。以下は例になります。

$ oc describe machineconfigs 01-worker-container-runtime | grep Path:

            Path:            /etc/containers/registries.conf
            Path:            /etc/containers/storage.conf
            Path:            /etc/crio/crio.conf

マシン設定ファイルには (10-worker-container-runtime などの) より新しい名前を付けてください。各ファイルの内容については、URL 形式のデータであることに留意してください。次に、新規マシン設定をクラスターに適用します。

継続的インテグレーション は、開発者向けの自動化プロセスです。アプリケーションのコード変更は定期的にビルドされ、テストされ、共有リポジトリーにマージされます。

継続的デリバリー および 継続的デリバリー は、相互に密接に関連する交換可能な概念であり、パイプラインの自動化に言及する概念です。継続的デリバリーでは、自動化により、開発者によるアプリケーションの変更をテストし、リポジトリーに送信し、オペレーションチームがそれらを実稼働環境にデプロイできるようにします。継続的デプロイメントは、リポジトリーから実稼働環境までに発生する変更のリリースを有効にします。継続的デプロイメントはアプリケーションの配信を迅速化し、オペレーションチームのオーバーロードを防ぎます。

GitOps は、Git プル要求を使用してインフラストラクチャーおよびアプリケーションの設定を管理する一連の手法です。GitOps の Git リポジトリーは、システムおよびアプリケーション設定の信頼できる唯一のソースです。リポジトリーにはシステムの全体の状態が含まれ、システム状態の変更の追跡情報は表示され、監査可能になります。GitOps を使用して DevOps の方法論を実装できます。

GitOps ツールを使用し、OpenShift Container Platform クラスターおよびアプリケーションの管理および再作成のための反復可能かつ予測可能なプロセスを作成できます。GitOps を使用することで、インフラストラクチャーおよびアプリケーション設定のスプロールの問題に対処できます。これは、インフラストラクチャーとアプリケーションの定義をコードとして定義することで、インフラストラクチャーおよびアプリケーション設定の変更の伝播を単純化します。 クラスター設定ファイルに GitOps を実装すると、自動インストールが容易になり、クラスターの自動化されたカスタマイズの設定が可能になります。Git リポジトリーでのソフトウェアの開発およびメンテナーンスのコアとなる原則を、クラスターおよびアプリケーション設定ファイルの作成および管理に適用できます。

OpenShift Container Platform を使用してクラスター設定およびコンテナー開発プロセスの両方を自動化することにより、GitOps 手法を導入する場面およびそのタイミングを選択することができます。GitOps ストラテジーと実行計画と共に CI パイプラインを使用することが理想的です。OpenShift Container Platform は、この方法論をビジネスプラクティスや各種パイプラインに統合するタイミングとその方法を選択する面での柔軟性を提供します。

GitOps 統合により、OpenShift Container Platform クラスター設定を宣言的に設定し、保存することができます。

GitOps はクラスターを宣言的に設定し、クラスター設定の状態を Git に保存することができるため、OpenShift Container Platform と効果的に機能します。詳細は、利用可能なクラスターのカスタマイズ を参照してください。

ArgoCD は、GitOps を使用してクラスターリソースを維持する宣言型の継続的デリバリーツールです。ArgoCD は、Git リポジトリーで定義されるアプリケーション定義および設定を継続的に監視し、それらの設定の指定された状態をクラスターのライブ状態と比較するコントローラーとして実装されます。Git リポジトリーで指定された状態から逸脱した設定は OutOfSync として分類されます。ArgoCD はこれらの違いを報告し、管理者が定義した状態に合わせて設定を自動または手動で再同期できるようにします。

ArgoCD を使用すると、OpenShift Container Platform クラスターを設定するために使用されるリソースなどのグローバルカスタムリソースを配信できます。

Red Hat では、このツールのサポートを提供していません。ArgoCD のサポートを取得するには、ArgoCD ドキュメントの Support を参照してください。

ArgoCD の使用についての詳細は、ArgoCD ドキュメント を参照してください。

受付プラグインは、OpenShift Container Platform 4.6 の機能の調整に役立ちます。受付プラグインは、マスター API への要求をインターセプトしてリソース要求の検証を行い、要求の認証および認可後にポリシーが順守されるようにします。たとえば、これらは一般的にセキュリティーポリシー、リソースの制限、設定要件の適用に使用されます。

受付プラグインは受付チェーン (admission chain) として順番に実行されます。シーケンス内の受付プラグインが要求を拒否すると、チェーン全体が中止され、エラーが返されます。

OpenShift Container Platform には、各リソースタイプについて有効にされている受付プラグインのデフォルトセットがあります。それらはマスターが適切に機能するために必要です。受付プラグインは、それらが対応していないリソースを無視します。

デフォルト以外にも、受付チェーンは、カスタム Webhook サーバーを呼び出す Webhook 受付プラグインを介して動的に拡張できます。Webhook 受付プラグインには、変更用の受付プラグインと検証用の受付プラグインの 2 種類の Webhook 受付プラグインがあります。変更用の受付プラグインが最初に実行され、リソースの変更および要求の検証の両方が可能です。検証用の受付プラグインは要求を検証し、変更用の受付プラグインによってトリガーされた変更も検証できるように変更用の受付プラグインの後に実行されます。

変更用の受付プラグインを使用して Webhook サーバーを呼び出すと、ターゲットオブジェクトに関連するリソースに影響を与える可能性があります。このような場合に、最終結果が想定通りであることを検証するためにいくつかの手順を実行する必要があります。

OpenShift Container Platform 4.6 では、デフォルトの検証および受付プラグインが有効になっています。これらのデフォルトプラグインは、Ingress ポリシー、クラスターリソース制限の上書き、クォータポリシーなどの基本的なコントロールプレーンの機能に貢献するものです。次のリストには、デフォルトの受付プラグインが含まれています。

OpenShift Container Platform のデフォルト受付プラグインのほかに、受付チェーンの機能を拡張するために Webhook サーバーを呼び出す Webhook 受付プラグインを使用して動的な受付を実装できます。Webhook サーバーは、定義されたエンドポイントにて HTTP で呼び出されます。

OpenShift Container Platform には、2 種類の Webhook 受付プラグインがあります。

API 要求が送信されると、変更用または検証用の受付コントローラーは設定内の外部 Webhook の一覧を使用し、それらを並行して呼び出します。

Webhook の受付プラグインと Webhook サーバー間の通信は TLS を使用する必要があります。CA 証明書を生成し、その証明書を使用して Webhook 受付サーバーで使用されるサーバー証明書に署名します。PEM 形式の CA 証明書は、サービス提供証明書のシークレットなどのメカニズムを使用して Webhook 受付プラグインに提供されます。

以下の図は、複数の Webhook サーバーが呼び出される連続した受付チェーンのプロセスを示しています。

図9.1 変更用および検証用の受付プラグインを含む API 受付チェーン

Webhook 受付プラグインのユースケースの例として使用できるケースでは、すべての Pod に共通のラベルのセットがなければなりません。この例では、変更用の受付プラグインはラベルを挿入でき、検証用の受付プラグインではラベルが予想通りであることを確認できます。OpenShift Container Platform は引き続いて必要なラベルが含まれる Pod をスケジュールし、それらのラベルが含まれない Pod を拒否します。

一般的な Webhook 受付プラグインのユースケースとして、以下が含まれます。

クラスター管理者は、API サーバーの受付チェーンで変更用の受付プラグインまたは検証用の受付プラグインを使用して Webhook サーバーを呼び出すことができます。

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration 1
metadata:
  name: <webhook_name> 2
webhooks:
- name: <webhook_name> 3
  clientConfig: 4
    service:
      namespace: default 5
      name: kubernetes 6
      path: <webhook_url> 7
    caBundle: <ca_signing_certificate> 8
  rules: 9
  - operations: 10
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 11
  sideEffects: None

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration 1
metadata:
  name: <webhook_name> 2
webhooks:
- name: <webhook_name> 3
  clientConfig: 4
    service:
      namespace: default  5
      name: kubernetes 6
      path: <webhook_url> 7
    caBundle: <ca_signing_certificate> 8
  rules: 9
  - operations: 10
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 11
  sideEffects: Unknown

この手順では、動的受付を設定するための手順の概要を説明します。受付チェーンの機能は、Webhook サーバーを呼び出すように Webhook 受付プラグインを設定することで拡張されます。

Webhook サーバーは集約された API サーバーとしても設定されます。これにより、他の OpenShift Container Platform コンポーネントは内部認証情報を使用して Webhook と通信でき、oc コマンドを使用したテストを容易にします。さらに、これによりロールベースのアクセス制御 (RBAC) が Webhook に対して可能となり、他の API サーバーからのトークン情報が Webhook に開示されないようになります。