アーキテクチャー

コンテナーイメージとそれらのイメージから実行されるコンテナーは、最先端のアプリケーション開発における主要な設定要素ですが、それらを大規模に実行するには、信頼性と柔軟性に優れた分配システムが必要となります。Kubernetes は、コンテナーをオーケストレーションするための事実上の業界標準です。

Kubernetes は、コンテナー化されたアプリケーションのデプロイ、スケーリング、管理を自動化するための、オープンソースのコンテナーオーケストレーションエンジンです。Kubernetes の一般的概念は非常にシンプルです。

Kubernetes は、わずか数年でクラウドとオンプレミスに非常に幅広く採用されるようになりました。このオープンソースの開発モデルにより、多くの人々がネットワーク、ストレージ、認証といったコンポーネント向けの各種の技術を実装し、Kubernetes を拡張できます。

コンテナー化されたアプリケーションには、従来のデプロイメント方法を使用する場合と比べて多くの利点があります。アプリケーションはこれまで、すべての依存関係を含むオペレーティングシステムにインストールする必要がありましたが、コンテナーの場合はアプリケーションがそれぞれの依存関係を持ち込むことができます。コンテナー化されたアプリケーションを作成すると多くの利点が得られます。

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

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

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

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

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

図2.1 OpenShift Container Platform の概要

OpenShift Container Platform 4.17 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

インストールプログラムを使用して、各タイプのクラスターをデプロイメントできます。インストールプログラムは、ブートストラップ、コントロールプレーン、コンピュートマシンの 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 カーネルを特長としています。RHCOS には、Kubernetes ノードエージェントである kubelet や、Kubernetes に対して最適化される CRI-O コンテナーランタイムが含まれます。

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

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

OpenShift Container Platform バージョン 4.17 では、installer-provisioned infrastructure を使用するクラスターの場合、以下のプラットフォームにインストールできます。

これらのクラスターの場合は、インストールプロセスを実行するコンピューターを含むすべてのマシンが、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供できるようインターネットに直接アクセスできる必要があります。

OpenShift Container Platform 4.17 では、user-provisioned infrastructure を使用するクラスターの場合、以下のプラットフォームにインストールできます。

プラットフォームでサポートされているケースに応じて、user-provisioned infrastructure でインストールを実行できます。これにより、完全なインターネットアクセスでのマシンの実行、プロキシーの背後へのクラスターの配置、非接続インストールの実行が可能になります。

非接続インストールでは、クラスターのインストールに必要なイメージをダウンロードして、ミラーレジストリーに配置し、そのデータを使用してクラスターをインストールできます。vSphere またはベアメタルインフラストラクチャー上での非接続インストールでは、プラットフォームコンテナーのイメージをプルするためにインターネットにアクセスする必要がありますが、クラスターマシンはインターネットへの直接のアクセスを必要としません。

OpenShift Container Platform 4.x Tested Integrations のページには、各種プラットフォームの統合テストの詳細が記載されています。

Assisted Installer を除き、OpenShift Container Platform クラスターをインストールする場合は、OpenShift Cluster Manager Hybrid Cloud Console の適切な クラスタータイプ ページから、インストールプログラムをダウンロードする必要があります。このコンソールは以下を管理します。

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

インストールプログラムの場合、プログラムはインストール中に 3 つのファイルセットを使用します。それは、install-config.yaml という名前のインストール設定ファイル、Kubernetes マニフェスト、およびマシンタイプの Ignition 設定ファイルです。

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

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

Assisted Installer を使用したインストールプロセス

Assisted Installer を使用したインストールでは、Web ベースのユーザーインターフェイスまたは RESTful API を使用して対話的にクラスター設定を作成します。Assisted Installer ユーザーインターフェイスは、ユーザーインターフェイスまたは API で変更しない限り、必要な値の入力を求め、残りのパラメーターに適切なデフォルト値を提供します。Assisted Installer は検出イメージを生成します。このイメージをダウンロードして、クラスターマシンの起動に使用します。イメージによって RHCOS とエージェントがインストールされ、エージェントがプロビジョニングを処理します。OpenShift Container Platform を、Assisted Installer を使用して完全な統合により、Nutanix、vSphere、およびベアメタルにインストールできます。統合せずに、Assisted Installer を使用して OpenShift Container Platform を別のプラットフォームにインストールすることもできます。

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

可能であれば、Agent-based Installer をダウンロードして設定する必要がないように、Assisted Installer 機能を使用してください。

エージェントベースのインフラストラクチャーを使用したインストールプロセス

Agent-based installation は Assisted Installer を使用する場合とよく似ていますが、最初に Agent-based Installer をダウンロードしてインストールする必要があります。エージェントベースのインストールは、Assisted Installer の利便性を活用したいにもかかわらず、非接続環境でクラスターをインストールする必要がある場合に役立ちます。

可能であれば、エージェントベースのインストール機能を使用してください。その場合は、ブートストラップ仮想マシンを使用してプロビジョナーマシンを作成し、クラスターインフラストラクチャーをプロビジョニングして維持する必要がなくなります。

installer-provisioned infrastructure でのインストールプロセス

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

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

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

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

user-provisioned infrastructure を使用したインストールプロセス

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

インストールプログラムがプロビジョニングしたインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。次のリストは、一部のセルフマネージドリソースの詳細を示しています。

クラスターで user-provisioned infrastructure を使用する場合は、RHEL コンピュートマシンをクラスターに追加するオプションを使用できます。

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

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

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

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

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

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

インストールのスコープ

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

Overview タブには、クラスターがどのように設定されたかに関する情報が表示されます。

Access control タブを使用すると、クラスターの所有者は ID プロバイダーをセットアップし、昇格されたアクセス許可を付与し、他のユーザーにロールを付与できます。

Insights Advisor タブは、OpenShift Container Platform の Remote Health 機能を使用して、セキュリティー、パフォーマンス、可用性、および安定性に対するリスクを特定して軽減します。OpenShift Container Platform のドキュメントで、Insights を使用してクラスターの問題を特定 を参照してください。

Machine pools タブでは、使用可能なクォータが十分にある場合、クラスター所有者は新しいマシンプールを作成できます。もしくは、既存のマシンプールを編集できます。

> Edit オプションを選択すると、"Edit machine pool" ダイアログが開きます。このダイアログでは、アベイラビリティーゾーンごとのノード数を変更したり、ノードのラベルと taint を編集したり、関連付けられている AWS セキュリティーグループを表示したりできます。

サポート タブでは、クラスター通知を受け取る必要がある個人の通知連絡先を追加できます。指定するユーザー名または電子メールアドレスは、クラスターがデプロイされている Red Hat 組織のユーザーアカウントに関連付けられている必要があります。

また、このタブからサポートケースを開いて、クラスターのテクニカルサポートを依頼することもできます。

Settings タブには、クラスター所有者向けのいくつかのオプションがあります。

OpenShift Container Platform のバージョンは、コントロールプレーンホストとノードホストの間で一致する必要があります。たとえば 4.17 クラスターでは、すべてのコントロールプレーンホストが 4.17、すべてのノードが 4.17 でなければなりません。

クラスターのアップグレード中の一時的な不一致は許容されます。たとえば、以前の OpenShift Container Platform バージョンから 4.17 にアップグレードする場合、一部のノードは他のノードよりも先に 4.17 にアップグレードされます。コントロールプレーンホストとノードホストのスキューが長引くと、古いコンピューティングマシンがバグや不足している機能にさらされる可能性があります。ユーザーは、スキューされたコントロールプレーンホストとノードホストをできるだけ早く解決する必要があります。

kubelet サービスは kube-apiserver よりも新しいものであってはならず、OpenShift Container Platform のバージョンが奇数か偶数かに応じて、最大 2 つのマイナーバージョンになる可能性があります。次の表は、適切なバージョンの互換性を示しています。

Kubernetes のクラスターでは、ワーカーノードは Kubernetes ユーザーによってリクエストされた実際のワークロードを実行し、管理します。ワーカーノードは容量をアドバタイズし、コントロールプレーンサービスであるスケジューラーは Pod とコンテナーを開始するノードを決定します。以下の重要なサービスは、各ワーカーノードで実行されます。

OpenShift Container Platform では、コンピューティングマシンセットは、worker マシンロールが割り当てられたコンピューティングマシンを制御します。worker のロールを持つマシンは、自動スケーリングを行う特定のマシンプールにより制御されるコンピュートワークロードを実行します。OpenShift Container Platform には複数のマシンタイプをサポートする能力があるため、worker ロールを持つマシンは コンピュート マシンとして分類されます。このリリースでは、コンピュートマシンの唯一のデフォルトタイプはワーカーマシンであるため、このリリースでは ワーカーマシン と コンピュートマシン は相互に置き換え可能な用語として使用されています。OpenShift Container Platform の今後のバージョンでは、インフラストラクチャーマシンなどの異なる種類のコンピュートマシンがデフォルトで使用される場合があります。

Kubernetes のクラスターでは、master ノードは Kubernetes クラスターの制御に必要なサービスを実行します。OpenShift Container Platform では、コントロールプレーンは、master マシンのロールを持つコントロールプレーンマシンで構成されます。これには、OpenShift Container Platform のクラスターを管理する Kubernetes サービス以外も含まれます。

ほとんどの OpenShift Container Platform クラスターでは、コントロールプレーンマシンは一連のスタンドアロンマシン API リソースにより定義されます。サポートされているクラウドプロバイダーと OpenShift Container Platform バージョンの組み合わせの場合、コントロールプレーンはコントロールプレーンマシンセットで管理できます。すべてのコントロールプレーンマシンが削除されてクラスターが切断されないようにするために、追加の制御がコントロールプレーンマシンに適用されます。

コントロールプレーン上の Kubernetes カテゴリーに分類されるサービスには、Kubernetes API サーバー、etcd、Kubernetes コントローラーマネージャー、Kubernetes スケジューラーが含まれます。

また、コントロールプレーンで実行される OpenShift サービス (OpenShift API サーバー、OpenShift コントローラーマネージャー、OpenShift OAuth API サーバー、および OpenShift OAuth サーバー) もあります。

コントロールプレーンマシン上のこれらサービスの一部は systemd サービスとして実行し、それ以外は静的な Pod として実行されます。

systemd サービスは、起動直後の特定のシステムで常に起動している必要のあるサービスに適しています。コントロールプレーンマシンの場合は、リモートログインを可能にする sshd も含まれます。また、以下のようなサービスも含まれます。

CRI-O および Kubelet は、他のコンテナーを実行する前に実行されている必要があるため、systemd サービスとしてホスト上で直接実行される必要があります。

installer-* および revision-pruner-* コントロールプレーン Pod は、root ユーザーが所有する /etc/kubernetes ディレクトリーに書き込むため、root パーミッションで実行する必要があります。これらの Pod は以下の namespace に置かれます。

OpenShift Container Platform では、すべてのクラスター機能が一連のデフォルトの クラスター Operator に分割されます。クラスター Operator は、クラスター全体でのアプリケーションロギング、Kubernetes コントロールプレーンの管理、またはマシンプロビジョニングシステムなどの、クラスター機能の特定の分野を管理します。

クラスター Operator は ClusterOperator オブジェクトで表現されます。これは、クラスター管理者が OpenShift Container Platform Web コンソールの Administration → Cluster Settings ページから表示できます。各クラスター Operator は、クラスター機能を決定するためのシンプルな API を提供します。Operator は、コンポーネントのライフサイクル管理の詳細を非表示にします。Operator は単一コンポーネントも、数十のコンポーネントも管理できますが、最終目標は常に、共通アクションの自動化により操作上の負担の軽減することにあります。

Operator Lifecycle Manager (OLM) と OperatorHub は、OpenShift Container Platform のデフォルトのコンポーネントであり、Kubernetes ネイティブアプリケーションを Operator として管理するのに役立ちます。これらは一緒になって、クラスターで使用可能なオプションのアドオン Operator を検出、インストール、および管理するためのシステムを提供します。

OpenShift Container Platform Web コンソールで OperatorHub を使用すると、クラスター管理者および許可されたユーザーは、Operator のカタログからインストールするオペレーターを選択できます。OperatorHub から Operator をインストールすると、ユーザーアプリケーションで実行できるように、グローバルまたは特定の namespace で使用できるようになります。

Red Hat Operator、認定 Operator、コミュニティー Operator を含むデフォルトのカタログソースが利用可能です。クラスター管理者は、独自のカスタムカタログソースを追加することもできます。このカタログソースには、カスタムの Operator セットを含めることができます。

開発者は Operator SDK を使用して、OLM 機能を利用するカスタム Operator の作成を支援することもできます。次に、それらの Operator をバンドルしてカスタムカタログソースに追加し、クラスターに追加してユーザーが利用できるようにできます。

etcd を使用すると、いくつかの利点があります。

クラスターの設定と管理に対する信頼性の高いアプローチを確保するために、etcd は etcd Operator を使用します。Operator は、OpenShift Container Platform のような Kubernetes コンテナープラットフォームでの etcd の使用を簡素化します。etcd Operator を使用すると、etcd メンバーの作成または削除、クラスターのサイズ変更、バックアップの実行、および etcd のアップグレードを行うことができます。

etcd オペレーターは、以下を観察、分析、および実行します。

etcd は、常に更新されるクラスターの状態を保持します。この状態は継続的に持続するため、高い頻度で多数の小さな変化が発生します。そのため、etcd クラスターメンバーを高速で低レイテンシーの I/O でサポートすることが重要です。etcd のベストプラクティスの詳細は、「推奨される etcd プラクティス」を参照してください。

Buildah、Podman、Skopeo を使用してコンテナービルドし、管理すると、それらのコンテナーを最終的に OpenShift Container Platform またはその他の Kubernetes 環境にデプロイする目的で調整された各種機能が含まれる業界標準のコンテナーイメージが生成されます。これらのツールはデーモンレスであり、root 権限なしで実行できるため、実行に必要なオーバーヘッドが少なくて済みます。

コンテナーを最終的に OpenShift Container Platform で実行するときは、CRI-O コンテナーエンジンを使用します。CRI-O は、OpenShift Container Platform クラスターのすべてのワーカーマシンおよびコントロールプレーンマシン上で実行されますが、CRI-O は、OpenShift Container Platform の外部のスタンドアロンランタイムとしてはまだサポートされていません。

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

Red Hat は、Red Hat Universal Base Images (UBI) と呼ばれるベースイメージの新たなセットを提供します。これらのイメージは Red Hat Enterprise Linux をベースにしており、Red Hat が過去に提供していたベースイメージに類似していますが、1 つの大きな違いは、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 から直接使用できます。Developer パースペクティブで、+Add ビューに移動し、Developer Catalog タイルで Developer Catalog で利用可能なすべてのサービスを表示します。

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

コンテナーレジストリーはコンテナーイメージを保管する場所です。ここから、コンテナーイメージを他の人と共有したり、最終的に実行するプラットフォームで使用できるようにしたりできます。無料アカウントを提供する大規模なパブリックコンテナーレジストリーや、容量の大きいストレージや特殊な機能を備えたプレミアムバージョンを選択できます。また、自身の組織にのみ限定される独自のレジストリーをインストールしたり、共有する相手を選択して独自のレジストリーをインストールすることもできます。

Red Hat のイメージおよび認定パートナーのイメージを取得するには、Red Hat レジストリーから取り出すことができます。Red Hat レジストリーは、認証されていない非推奨の registry.access.redhat.com、および認証が必要な registry.redhat.io の 2 つの場所によって表わされます。Container images section of the Red Hat Ecosystem Catalog で、Red Hat レジストリーの Red Hat イメージおよびパートナーのイメージを確認できます。これは、Red Hat コンテナーイメージのをリスト表示するだけでなく、適用されたセキュリティー更新に基づくヘルススコアなどの、これらのイメージのコンテンツと品質に関する広範な情報も表示します。

大規模なパブリックレジストリーには、Docker Hub および Quay.io が含まれます。Quay.io レジストリーは Red Hat が所有し、管理しています。OpenShift Container Platform で使用されるコンポーネントの多くは Quay.io に保管されます。これには OpenShift Container Platform 自体をデプロイするために使用されるコンテナーイメージおよび Operator が含まれます。Quay.io は、Helm チャートなどの他のタイプのコンテンツを保管する手段ともなります。

専用のプライベートコンテナーレジストリーが必要な場合は、OpenShift Container Platform 自体にプライベートコンテナーレジストリーが含まれています。これは、OpenShift Container Platform と共にインストールされ、そのクラスター上で実行されます。また、Red Hat は <blink>Red Hat Quay</blink> と呼ばれるプライベートバージョンの Quay.io レジストリーも提供しています。Red Hat Quay には、geo レプリケーション、Git ビルドトリガー、Clair イメージスキャンなどの多くの機能が含まれています。

ここで言及したすべてのレジストリーでは、これらのレジストリーからイメージをダウンロードする際に認証情報が必要です。これらの認証情報の一部は OpenShift Container Platform のクラスター全体に提供されますが、他の認証情報は個別に割り当てられます。

コンテナーイメージは Docker を使用する基本単位であり、Kubernetes が使用する基本単位は Pod と呼ばれます。Pod はアプリケーションのビルドの次の手順で使用されます。Pod には、1 つ以上のコンテナーを含めることができます。Pod はデプロイやスケーリングおよび管理を実行する単一の単位であることに留意してください。

Pod での実行内容を決定する際に考慮する必要のある主要な点として、スケーラビリティーと namespace を考慮できます。デプロイメントを容易にするには、コンテナーを Pod にデプロイして、Pod 内に独自のロギングとモニタリングコンテナーを含めることができるかもしれません。後に、Pod を実行し、追加のインスタンスをスケールアップすることが必要になると、それらの他のコンテナーもスケールアップできます。namespace の場合、Pod 内のコンテナーは同じネットワークインターフェイス、共有ストレージボリューム、メモリーや CPU などのリソース制限を共有します。これにより、Pod のコンテンツを単一の単位として管理することが容易になります。また Pod 内のコンテナーは、System V セマフォや POSIX 共有メモリーなどの標準的なプロセス間通信を使用することにより、相互に通信できます。

個々の Pod が Kubernetes 内のスケーラブルな単位を表すのに対し、サービス は、負荷分散などの完全なタスクを実行する完全で安定したアプリケーションを作成するために複数の Pod をグループ化する手段を提供します。 また、サービスは削除されるまで同じ IP アドレスで利用可能な状態になるため、Pod より永続性があります。サービスが使用できる状態では、サービスが名前で要求され、OpenShift Container Platform クラスターはその名前を IP アドレスとポートに解決し、そこからサービスを設定する Pod に到達できます。

性質上、コンテナー化されたアプリケーションは、そのアプリケーションが実行するオペレーティングシステムから分離され、したがってユーザーからも分離されます。Kubernetes マニフェストの一部には、コンテナー化されたアプリケーションとの通信の詳細な制御を可能にする ネットワークポリシー を定義して、アプリケーションを内外のネットワークに公開する方法が記述されています。HTTP、HTTPS の受信要求やクラスター外からの他のサービスをクラスター内のサービスに接続するには、Ingress リソースを使用できます。

コンテナーが、サービスを通じて提供されるデータベースストレージではなくディスク上のストレージを必要とする場合は、ボリューム をマニフェストに追加して、そのディスクを Pod で使用できるようにすることができます。永続ボリューム (PV) を作成するか、Pod 定義に追加されるボリュームを動的に作成するようにマニフェストを設定できます。

アプリケーションを設定する Pod のグループを定義した後に、それらの Pod を Deployment および DeploymentConfig オブジェクトで定義できます。

次に、アプリケーションのタイプが、その実行方法にどのように影響するかを検討します。

Kubernetes は、各種のアプリケーションに適した異なるタイプのワークロードのタイプを定義します。アプリケーションに適したワークロードを決定するために、アプリケーションが以下のどのタイプに該当するかを確認してください。

作成するアプリケーションには、データベースやロギングコンポーネントなどのサポートコンポーネントが必要な場合があります。このニーズに対応するために、OpenShift Container Platform の Web コンソールで利用可能な以下のカタログから必要なコンポーネントを取得できる場合があります。

サポートする Operator およびテンプレートは、開発チームの特定のニーズに合わせて設定し、開発者が作業に使用する namespace で利用できるようにすることができます。 多くの場合、共有テンプレートは他のすべての namespace からアクセス可能になるために openshift namespace に追加されます。

Kubernetes マニフェストを使用して、Kubernetes アプリケーションを設定するコンポーネントのより詳細な情報を得ることができます。これらのマニフェストは YAML ファイルとして作成し、oc apply などのコマンドを実行して、それらをクラスターに適用してデプロイできます。

この時点で、コンテナー開発のプロセスを自動化する方法を検討します。この際、イメージをビルドしてレジストリーにプッシュするいくつかの CI パイプラインがあることが望ましいと言えます。とくに GitOps パイプラインは、アプリケーションのビルドに必要なソフトウェアを保管する Git リボジトリーにコンテナー開発を統合します。

ここまでのワークフローは以下のようになります。

以下は、RHCOS オペレーティングシステムの主要な機能を説明しています。

RHCOS システムの場合、rpm-ostree ファイルシステムのレイアウトには、以下の特徴があります。

RHCOS は、最低限のユーザー設定で OpenShift Container Platform クラスターにデプロイするように設計されています。これは最も基本的な形式であり、以下で構成されます。

OpenShift Container Platform の RHCOS システムは OpenShift Container Platform クラスターから完全に管理されるように設計されているため、RHCOS マシンに直接ログインすることは推奨されていません。RHCOS マシンクラスターへの直接のアクセスはデバッグ目的で制限的に実行できますが、RHCOS システムを直接設定することはできません。その代わりに、OpenShift Container Platform ノードに機能を追加または変更する必要がある場合は、以下の方法で変更を行うことを検討してください。

以下は、Day-1 で実行できるカスタマイズの例です。

これらのタスクを実行する上で、openshift-install プロセスを拡張して MachineConfig などの追加のオブジェクトを含めることができます。machine config を作成するこれらの手順は、クラスターの起動後に Machine Config Operator に渡すことができます。

OpenShift Container Platform の RHCOS インストールの相違点は、インストーラーまたはユーザーによってプロビジョニングされるインフラストラクチャーにデプロイするかどうかによって異なります。

Ignition 機能は、RHCOS システムの初回セットアップ時にのみ実行されます。その後は、Ignition 設定はマシン設定を使用して指定できます。

Ignition は、初回設定時にディスクを操作するために RHCOS によって使用されるユーティリティーです。これにより、ディスクのパーティション設定やパーティションのフォーマット、ファイル作成、ユーザー設定などの一般的なディスク関連のタスクが実行されます。初回起動時に、Ignition はインストールメディアや指定した場所からその設定を読み込み、その設定をマシンに適用します。

クラスターをインストールする場合かマシンをクラスターに追加する場合かを問わず、Ignition は常に OpenShift Container Platform クラスターマシンの初期設定を実行します。実際のシステム設定のほとんどは、各マシン自体で行われます。各マシンで、Ignition は、RHCOS イメージを取得し、RHCOS カーネルを起動します。カーネルコマンドラインのオプションで、デプロイメントのタイプや Ignition で有効にされた初期 RAM ディスク (initramfs) の場所を特定します。

変更用の受付プラグインは、受付プロセスの変更フェーズで起動します。これにより、リソースコンテンツが永続化する前にそれらを変更できます。変更用の受付プラグインで呼び出し可能な Webhook の一例として、Pod ノードセレクター機能があります。 この機能は namespace でアノテーションを使用してラベルセレクターを検索し、これを Pod 仕様に追加します。

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

検証用の受付 Webhook は受付プロセスの検証フェーズで起動します。このフェーズでは、特定 API リソースの変更がない項目の実施を可能にし、リソースが再び変更されないようにすることができます。Pod ノードセレクターは、すべての nodeSelector フィールドが namespace のノードセレクターの制限の制約を受けるようにするために、検証用の受付プラグインによって呼び出される Webhook の一例です。

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