アーキテクチャー

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

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

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

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

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

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

ROSA with HCP を使用すると、パブリックネットワークまたはプライベートネットワーク上にクラスターを作成できます。以下の図は、パブリックネットワークとプライベートネットワークの両方のアーキテクチャーを示しています。

図3.2 パブリックネットワーク上にデプロイされた ROSA with HCP

View larger image

図3.3 プライベートネットワーク上にデプロイされた ROSA with HCP

View larger image

ROSA Classic を使用すると、パブリックネットワークまたはプライベートネットワークでアクセス可能なクラスターを作成できます。

API サーバーエンドポイントと Red Hat SRE 管理のアクセスパターンは、次の方法でカスタマイズできます。

次の図は、パブリックネットワークとプライベートネットワークの両方にデプロイされた ROSA Classic クラスターのアーキテクチャーを示しています。

図3.4 パブリックおよびプライベートネットワークにデプロイされた ROSA Classic

View larger image

ROSA Classic クラスターには、Ingress コントローラー、イメージレジストリー、モニタリングなどの OpenShift コンポーネントがデプロイされるインフラストラクチャーノードが含まれます。インフラストラクチャーノードおよびそれらにデプロイされる OpenShift コンポーネントは ROSA Service SRE によって管理されます。

ROSA Classic では、以下のタイプのクラスターを使用できます。

AWS PrivateLink クラスターを作成する Red Hat マネージドインフラストラクチャーは、プライベートサブネットでホストされています。Red Hat とお客様によって提供されるインフラストラクチャー間の接続は、AWS PrivateLink VPC エンドポイント経由で作成されます。

次の図は、PrivateLink クラスターのネットワーク接続を示しています。

図3.5 プライベートサブネットにデプロイされたマルチ AZ AWS PrivateLink クラスター

View larger image

ROSA は、顧客がレイテンシーの影響を受けやすいアプリケーションのワークロードを VPC 内に配置できる大都市集中型のアベイラビリティーゾーンである AWS Local Zones の使用をサポートします。Local Zones は AWS リージョンを拡張したもので、デフォルトでは有効になっていません。Local Zones が有効になっており、設定されている場合、トラフィックは Local Zones に拡張され、高い柔軟性と低レイテンシーを得ることができます。詳細は、「Local Zones でのマシンプールの設定」を参照してください。

次の図は、トラフィックが Local Zone にルーティングされない ROSA クラスターを示しています。

図3.6 トラフィックが Local Zones にルーティングされない ROSA クラスター

View larger image

次の図は、トラフィックが Local Zone にルーティングされる ROSA クラスターを示しています。

図3.7 トラフィックが Local Zones にルーティングされる ROSA クラスター

View larger image

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

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

Kubernetes のクラスターでは、master ノードは Kubernetes クラスターの制御に必要なサービスを実行します。Red Hat OpenShift Service on AWS では、コントロールプレーンは、master マシンのロールを持つコントロールプレーンマシンで構成されます。これらには、Red Hat OpenShift Service on AWS クラスターを管理するための Kubernetes サービス以上のものが含まれています。

ほとんどの Red Hat OpenShift Service on AWS クラスターでは、コントロールプレーンマシンは一連のスタンドアロンマシン API リソースによって定義されます。コントロールプレーンは、コントロールプレーンマシンセットで管理されます。すべてのコントロールプレーンマシンが削除されてクラスターが切断されないようにするために、追加の制御がコントロールプレーンマシンに適用されます。

コントロールプレーン上の 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 に置かれます。

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

Red Hat OpenShift Service on AWS Web コンソールの OperatorHub を使用すると、dedicated-admin ロールを持つ管理者と許可されたユーザーは、インストールする Operator を Operator のカタログから選択できます。OperatorHub から Operator をインストールすると、ユーザーアプリケーションで実行できるように、グローバルまたは特定の namespace で使用できるようになります。

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

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

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

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

etcd は、常に更新されるクラスターの状態を保持します。この状態は継続的に持続するため、高い頻度で多数の小さな変化が発生します。その結果、Red Hat Site Reliability Engineering (SRE) は、etcd クラスターメンバーを高速で低レイテンシーの I/O でサポートします。

Compute Unified Device Architecture (CUDA) は、GPU での計算全般のために NVIDIA が開発した並列コンピューティングプラットフォームおよびプログラミングモデルです。

ストリームは、GPU 上で発行順に実行される一連の操作です。CUDA コマンドは通常、デフォルトストリームで順次実行され、前のタスクが完了するまでタスクは開始されません。

ストリームをまたいだ操作の非同期処理により、タスクの並列実行が可能になります。あるストリームで発行されたタスクは、別のタスクが別のストリームで発行される前、実行中、または発行された後に実行されます。これにより、GPU は指定された順序に関係なく複数のタスクを同時に実行できるようになり、パフォーマンスの向上につながります。

GPU タイムスライスは、複数の CUDA アプリケーションを実行しているときに、過負荷になった GPU でスケジュールされたワークロードをインターリーブします。

Kubernetes で GPU のタイムスライスを有効にするには、GPU のレプリカセットを定義し、それを個別に Pod に配分してワークロードを実行できるようにしっます。マルチインスタンス GPU (MIG) とは異なり、メモリーや障害はレプリカ間で分離されませんが、一部のワークロードでは一切共有しないより、こちらの方が適切です。内部的には、GPU タイムスライスを使用して、基礎である同じ GPU のレプリカからのワークロードを多重化します。

クラスター全体のデフォルト設定をタイムスライスに適用できます。ノード固有の設定を適用することもできます。たとえば、タイムスライス設定を Tesla T4 GPU を備えたノードにのみ適用し、他の GPU モデルを備えたノードは変更しないようにできます。

クラスター全体のデフォルト設定を適用し、ノードにラベルを付けて、それらのノードにノード固有の設定が適用されるようにすることで、2 つのアプローチを組み合わせることができます。

CUDA マルチプロセスサービス (MPS) を使用すると、単一の GPU で複数の CUDA プロセスを使用できます。プロセスは GPU 上で並行して実行されるため、GPU コンピュートリソースの飽和が発生しなくなります。MPS を使用すると、カーネル操作や、別のプロセスからのメモリーコピーの同時実行または重複も可能になり、使用率が向上します。

マルチインスタンス GPU (MIG) を使用すると、GPU コンピュートユニットとメモリーを複数の MIG インスタンスに分割できます。これらの各インスタンスは、システムの観点からはスタンドアロン GPU デバイスであり、ノード上で実行されている任意のアプリケーション、コンテナー、または仮想マシンに接続できます。GPU を使用するソフトウェアは、これらの各 MIG インスタンスを個別の GPU として扱います。

MIG は、GPU 全体のフルパワーを必要としないアプリケーションがある場合に役立ちます。新しい NVIDIA Ampere アーキテクチャーの MIG 機能を使用すると、ハードウェアリソースを複数の GPU インスタンスに分割できます。各インスタンスは、オペレーティングシステムで独立した CUDA 対応 GPU として利用できます。

NVIDIA GPU Operator バージョン 1.7.0 以降では、A100 および A30 Ampere カードの MIG サポートを提供しています。これらの GPU インスタンスは、最大 7 つの独立した CUDA アプリケーションをサポートするように設計されており、専用のハードウェアリソースをしようしてそれぞれ完全に分離された状態で稼働します。

仮想マシンは、NVIDIA vGPU を使用して単一の物理 GPU に直接アクセスできます。企業全体の仮想マシンで共有され、他のデバイスからアクセスできる仮想 GPU を作成できます。

この機能は、GPU パフォーマンスのパワーと、vGPU がもたらす管理およびセキュリティーの利点を組み合わせたものです。vGPU には他にも、仮想環境のプロアクティブな管理と監視、混合 VDI とコンピュートワークロードのワークロードバランシング、複数の仮想マシン間でのリソース共有などの利点があります。

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

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

アプリケーションをビルドするために選択するベースイメージには、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 イメージは、Red Hat OpenShift Service on AWS Web UI から直接使用できます。Developer パースペクティブで、+Add ビューに移動し、Developer Catalog タイルで Developer Catalog で利用可能なすべてのサービスを表示します。

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

View larger image

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

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 が所有し、管理しています。Red Hat OpenShift Service on AWS で使用されるコンポーネントの多くは Quay.io に保管されます。これには Red Hat OpenShift Service on AWS 自体をデプロイするために使用されるコンテナーイメージおよび Operator が含まれます。Quay.io は、Helm チャートなどの他のタイプのコンテンツを保管する手段ともなります。

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

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

コンテナーイメージは 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 より永続性があります。サービスが使用できる状態の場合、サービスは名前で要求され、Red Hat OpenShift Service on AWS クラスターはその名前を IP アドレスとポートに解決し、そこからサービスを設定する Pod に到達することができます。

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

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

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

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

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

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

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

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

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

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

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

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration 
metadata:
  name: <webhook_name> 
webhooks:
- name: <webhook_name> 
  clientConfig: 
    service:
      namespace: default 
      name: kubernetes 
      path: <webhook_url> 
    caBundle: <ca_signing_certificate> 
  rules: 
  - operations: 
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 
  sideEffects: None

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration 

metadata:
  name: <webhook_name> 

webhooks:
- name: <webhook_name> 

  clientConfig: 

    service:
      namespace: default 

      name: kubernetes 

      path: <webhook_url> 

    caBundle: <ca_signing_certificate> 

  rules: 

  - operations: 

    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 

  sideEffects: None

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

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration 
metadata:
  name: <webhook_name> 
webhooks:
- name: <webhook_name> 
  clientConfig: 
    service:
      namespace: default  
      name: kubernetes 
      path: <webhook_url> 
    caBundle: <ca_signing_certificate> 
  rules: 
  - operations: 
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 
  sideEffects: Unknown

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration 

metadata:
  name: <webhook_name> 

webhooks:
- name: <webhook_name> 

  clientConfig: 

    service:
      namespace: default  

      name: kubernetes 

      path: <webhook_url> 

    caBundle: <ca_signing_certificate> 

  rules: 

  - operations: 

    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 

  sideEffects: Unknown