サービスのアーキテクチャーと依存関係

Red Hat OpenShift のマスター・コンポーネント

Red Hat OpenShift on IBM Cloud クラスターの IBM 管理のマスターに含まれている以下のコンポーネントについて確認してください。

これらのコンポーネントは変更できません。 これらのコンポーネントは IBM が管理し、マスター・パッチの更新時に自動的に更新されます。

OpenShift Container Platform 4 では、管理を簡単にするために、多くのコンポーネントが、対応するオペレーターによって構成されます。 以下の表では、コンポーネントがクラスターに提供する主要な機能に焦点を当てるために、そのようなオペレーターとコンポーネントを一緒にして説明しています。

シングル・テナンシー

マスターおよびすべてのマスター・コンポーネントは、お客様ごとに専用のものがあり、他の IBM のお客様と共有することはありません。

レプリカ

Red Hat OpenShift API サーバーと etcd データ・ストアを含むマスターのコンポーネントは 3 つのレプリカを持ち、複数ゾーンの大都市に配置された場合は複数のゾーンに分散されて、さらに高い可用性を実現します。

cloud-controller-manager

クラウド・コントローラー・マネージャーは、IBM Cloud ロード・バランサーなどのクラウド・プロバイダー固有コンポーネントを管理します。

cluster-health

クラスター正常性コンポーネントは、クラスターの正常性をモニターし、このサービスのための IBM Cloud のモニタリングおよびメトリックと統合されます。

cluster-policy-controller

クラスタ内でポッドを作成するために必要な cluster-policy-controller は、クラスタ内でポッドを作成するために必要なポリシー・リソースを維持します。

cluster-version-operator

クラスター・バージョン・オペレーター (CVO) は、クラスター内で実行される他のオペレーターをインストールおよび更新します。 詳しくは GitHub。

control-plane-operator

コントロール・プレーン・オペレーターは、マスター内のコントロール・プレーン・コンポーネントのインストールと更新を管理します。

etcd, etcd-molecule, etcd-operator

etcd は、クラスターのすべての Kubernetes リソース (サービス、デプロイメント、ポッドなど) の状態を保管する、可用性の高いキー値ストアです。 etcd のデータは、IBM 管理の暗号化されたストレージ・インスタンスに 8 時間おきにバックアップされます。

kube-controller-manager, openshift-controller-manager

Kubernetes コントローラは、ワークロードのレプリカセットなど、クラスタ内のオブジェクトの状態を監視する。 オブジェクトの状態が変化する (例えば、レプリカ・セット内のポッドがダウンする) と、コントローラー・マネージャーは、必要な状態を実現するための修正アクションを開始します。 Red Hat OpenShift コントローラーは、同じ機能を、Red Hat OpenShift API に固有のオブジェクト (プロジェクトなど) に対して実行します。

kube-scheduler

Kubernetes スケジューラは、新しく作成されたポッドを監視し、キャパシティ、パフォーマンスニーズ、ポリシー制約、アンチアフィニティ仕様、およびワークロード要件に基づいて、ポッドの配置場所を決定する。 要件に合致するワーカー・ノードが見つからなければ、ポッドはクラスターにデプロイされません。

manifests-bootstrapper

manifests-boot-strapper ジョブは、クラスタのマスター・ノードとして参加するために必要な証明書でマスターをセットアップします。

oauth-openshift

この標準装備の OAuth サーバーは、IBM Cloud の ID およびアクセス管理 (IAM) と統合するように自動的にセットアップされます。 サポートされている他の ID プロバイダーをクラスターに追加することはできません。 IAM を使用してクラスターで認証を行う方法について詳しくは、Red Hat OpenShift クラスターへのアクセスを参照してください。

openshift-apiserver, openshift-apiserver-operator, kube-apiserver

API サーバーは、ワーカー・ノードからマスターに送られるすべてのクラスター管理要求のメインエントリー・ポイントです。 API サーバーは、Kubernetes オブジェクト (ポッドやサービスなど) と Red Hat OpenShift オブジェクト (プロジェクトやユーザーなど) の状態を変更する要求を検証して処理します。 その後、API サーバーはその状態を etcd データ・ストアに保管します。

konnectivity-server, konnectivity-operator

KonnectivityサーバーはKonnectivityエージェントと連携し、マスターとワーカーノードを安全に接続します。 この接続は、ポッドやサービスに対する apiserver proxy 呼び出し、kubelet に対する oc exec、attach、logs 呼び出し、変更 Web フックと検証 Web フックをサポートしています。

アドミッション・コントローラー

アドミッション・コントローラーは、Red Hat OpenShift on IBM Cloud クラスターの特定の機能のために実装されています。 　アドミッション・コントローラーにより、クラスター内で特定の操作を許可するかどうかを決定するポリシーを、クラスター内にセットアップできます。 ポリシーには、RBAC を使用してユーザーに割り当てた汎用権限に含まれている操作であっても、ユーザーがその操作を実行できなくなる条件を指定できます。 したがって、アドミッション・コントローラーは Red Hat OpenShift API サーバーで API 要求が処理される前に適用されるセキュリティー層をクラスターに追加できます。 Red Hat OpenShift クラスタを作成すると、以下の Kubernetes アドミッションコントローラが自動的に Red Hat OpenShift マスタに所定の順序でインストールされます：

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultStorageClass
• ResourceQuota
• StorageObjectInUseProtection
• PersistentVolumeClaimResize
• Priority
• BuildByStrategy
• OriginPodNodeEnvironment
• PodNodeSelector
• ExternalIPRanger
• NodeRestriction
• SecurityContextConstraint
• SCCExecRestrictions
• PersistentVolumeLabel
• OwnerReferencesPermissionEnforcement
• PodTolerationRestriction
• openshift.io/JenkinsBootstrapper
• openshift.io/BuildConfigSecretInjector
• openshift.io/ImageLimitRange
• openshift.io/RestrictedEndpointsAdmission
• openshift.io/ImagePolicy
• openshift.io/IngressAdmission
• openshift.io/ClusterResourceQuota
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook

独自のアドミッションコントローラをクラスタにインストールすることも、 Red Hat OpenShift on IBM Cloud が提供するオプションのアドミッションコントローラから選択することもできます。 コンテナイメージのセキュリティ強化：インストール Portieris をインストールして、署名されていないイメージからのコンテナのデプロイをブロックします。

手動でインストールしたアドミッション・コントローラーが不要になった場合は、必ず、完全に削除してください。 アドミッション・コントローラーを完全に削除しておかないと、クラスターで実行する操作がすべてブロックされる可能性があります。.

Red Hat OpenShift ワーカーノードコンポーネント

Red Hat OpenShift on IBM Cloud クラスターのお客様管理のワーカー・ノードに含まれている以下のコンポーネントについて確認してください。

これらは、クラスターにデプロイするワークロードで使用できるコンポーネントであるため、ワーカー・ノードで実行されます。 例えば、アプリで OperatorHub のオペレーターを使用して、内部レジストリーに保管されているイメージからコンテナーを実行することができます。 これらのコンポーネントは、お客様の責任において使用するものですが、IBM は、適用するかどうかを選択できるワーカー・ノードのパッチ更新に含めて、これらのコンポーネントの更新を提供します。

OpenShift Container Platform では、管理を容易にするため、多くのコンポーネントが対応するオペレーターによって設定される。 以下の表では、コンポーネントがクラスターに提供する主要な機能に焦点を当てるために、そのようなオペレーターとコンポーネントを一緒にして説明しています。

シングル・テナンシー

ワーカー・ノードおよびすべてのワーカー・ノード・コンポーネントは、お客様ごとに専用のものがあり、他の IBM のお客様と共有することはありません。 ただし、ワーカーノード仮想マシンを使用する場合、選択したハードウェア分離レベルによっては、基盤となるハードウェアが他の IBM カスタマーと共有される可能性があります。

オペレーティング・システム

クラスター・バージョンごとにサポートされるオペレーティング・システムのリストについては、 バージョン情報 を参照してください。

CRI-O コンテナー・ランタイム

ワーカーノードは CRI-O でインストールされます。 詳しくは、コンテナー・ランタイムを参照してください。

プロジェクト

Red Hat OpenShift は、リソースをプロジェクト (アノテーション付きの Kubernetes 名前空間) に編成し、カタログなどの Red Hat OpenShift 機能を実行するためにコミュニティー Kubernetes クラスターよりも多くのコンポーネントを含みます。 以下の行で、プロジェクトの厳選されたコンポーネントについて説明します。 詳しくは、 プロジェクトでの作業をご覧ください。

calico-system, tigera-operator

Calico は、クラスターのネットワーク・ポリシーを管理し、コンテナー・ネットワーク接続、IP アドレス割り当て、およびネットワーク・トラフィック制御を管理するいくつかのコンポーネントを含みます。 Tigera オペレーターは、Calico コンポーネントのインストールとライフサイクル管理を行います。

default

このプロジェクトは、プロジェクトを指定しない場合、または Kubernetes リソース用のプロジェクトを作成しない場合に使用されます。

ibm-system

このプロジェクトには、ibm-cloud-provider-ip デプロイメントが含まれています。このデプロイメントは、keepalived と連携して、アプリ・ポッドへの要求のヘルス・チェックおよびレイヤー 4 ロード・バランシングを提供します。

kube-system

このプロジェクトには、ワーカー・ノードで Kubernetes を実行するために使用される多くのコンポーネントが含まれています。

• ibm-master-proxy: ibm-master-proxy は、ワーカー・ノードからの要求を、可用性の高い複数のマスター・レプリカの各 IP アドレスに転送するデーモン・セットです。 単一ゾーン・クラスターのマスターの場合は、別々のホスト上に 3 つのレプリカが存在します。 複数ゾーン対応ゾーンにあるクラスターの場合、マスターの 3 つのレプリカがゾーン間に分散されます。 高可用性ロード・バランサーは、マスター・ドメイン・ネームへの要求をマスター・レプリカに転送します。
• kubelet: kubelet はワーカー・ノードごとに実行されるワーカー・ノード・エージェントであり、ワーカー・ノードで実行される各ポッドの正常性のモニタリングと、API サーバーから送信されるイベントの監視を行います。 イベントに基づいて、kubelet は、ポッドを作成または削除し、Liveness Probe と Readiness Probe を確保し、API サーバーに応答としてポッドの状況を報告します。
• vpn:KonnectivityエージェントはKonnectivityサーバーと連携し、マスターとワーカーノードを安全に接続します。 この接続は、ポッドやサービスに対する apiserver proxy 呼び出しと、kubelet に対する oc exec、attach、logs 呼び出しをサポートしています。
• その他のコンポーネント: kube-system プロジェクトには、IBM 提供のリソース (ファイル・ストレージおよびブロック・ストレージ用のストレージ・プラグイン、Ingress アプリケーション・ロード・バランサー (ALB)、keepalived など) を管理するコンポーネントも含まれています。

openshift-cloud-credential-operator

クラウド資格情報オペレーターは、クラウド・プロバイダーの資格情報を要求する Red Hat OpenShift コンポーネントのコントローラーを管理します。 コントローラーが、操作に必要な資格情報のみを使用し、admin などの高い権限を使用しないようにします。 詳しくは GitHub。

openshift-cluster-node-tuning-operator

IBM はノードチューニングオペレータを管理し、クラスタ内の各ワーカーノード上でデーモンセットを実行してワーカーノードをチューニングします。

openshift-cluster-samples-operator

samples オペレータは、デフォルトで Red Hat OpenShift クラスタに付属している、選択した画像ストリームとテンプ レートを管理する。 これらのテンプレートは 、 Red Hat OpenShift ウェブコンソールの Developer パースペクティブから デプロイできます。

openshift-cluster-storage-operator

クラスター・ストレージ・オペレーターは、デフォルトのストレージ・クラスが設定されていることを確認します。

openshift-console, openshift-console-operator

Red Hat OpenShift Web コンソールは、クラスタで実行する Red Hat OpenShift および Kubernetes リソースを管理するために使用できる Web ベースのインターフェイスです。 このコンソールを使用して、CLI でクラスターの認証を受けるための oc login トークンを表示することもできます。 詳しくは、Red Hat OpenShift コンソールをナビゲートするを参照してください。

openshift-dns, openshift-dns-operator

DNS プロジェクトには、ワーカー・ノードでセットアップされた iptables ルールに照らして着信ネットワーク・トラフィックを検証し、クラスターへの出入りを許可された要求をプロキシー処理するためのコンポーネントが含まれています。

openshift-image-registry

Red Hat OpenShift 内部 コンテナ・イメージ・レジストリを提供し、コンソールを使ってローカルにイメージを管理・閲覧できる。 代わりに、プライベートの IBM Cloud Container Registry をセットアップしたり、 IBM Cloud Container Registry から内部レジストリーにイメージをインポートしたりすることもできます。 内部レジストリには、 レジストリのイメージを保存 するための IBM Cloud アカウント File Storage for Classic ボリュームが付属しています。 このファイル・ストレージ・ボリュームは、image-registry-storage 永続ボリューム請求 (PVC) を使用してプロビジョンされます。

openshift-ingress, openshift-ingress-operator

Red Hat OpenShift は、外部クライアントがサービスに到達できるように、ホスト名でアプリのサービスを直接公開する ルートを使用します。 経路を作成するために、クラスターは Ingress オペレーターを使用します。 Ingress を使用して、アプリを外部に公開したり、ルーティングをカスタマイズしたりすることもできます。 Ingress を構成する 3 つのコンポーネントは、Ingress オペレーター、Ingress コントローラー、および Route リソースです。 Ingress コントローラーは、サービスをホスト名にマップします。 デフォルトでは、Ingress コントローラーには 2 つのレプリカが含まれています。 Ingress コントローラーを別々のコンピュート・ホストで実行して可用性を高められるように、クラスターには 2 つ以上のワーカー・ノードを用意してください。

openshift-marketplace

マーケットプレイスには OperatorHub が含まれており、デフォルトで Red Hat OpenShift クラスタに付属しています。 OperatorHub には、Red Hat やサード・パーティー・プロバイダーのオペレーターが入っています。 これらのオペレーターはコミュニティーから提供されるものであり、クラスターと統合しなくてもかまいません。また、IBM がサポートするものではないことを忘れないでください。 Red Hat OpenShift ウェブコンソールの OperatorHub から オペレーターを有効に できます。

openshift-monitoring

OpenShift Container Platform には、クラスタ用の ビルトイン・モニタリング・スタックが含まれており、メトリクスとアラート管理機能を備えています。 組み込みのモニタリング・スタックと IBM Cloud Monitoring などの他のオプションの比較については、ロギングとモニタリングについてを参照してください。

openshift-multus

OpenShift Container Platform は、Multus コンテナ・ネットワーク・インターフェース（CNI）プラグインを使用して、 複数のポッドネットワークを許可します。 ただし、複数のポッド・ネットワークを使用するようにクラスターを構成することはできません。Red Hat OpenShift on IBM Cloud クラスターは、デフォルトでクラスターにセットアップされている Calico のみをサポートします。 有効にすると、 サービスメッシュは Multusプラグインを使用します。

openshift-network-operator

クラスタネットワークオペレータ（CNO ）は、CNIポッドネットワークプロバイダプラグインやDNSオペレータなど、デフォルトで設定されているクラスタネットワークコンポーネントを管理します。

openshift-operator-lifecycle-manager

オペレータ・ライフサイクル・マネージャ(OLM )は、デフォルト・コンポーネントのオペレータと追加したカスタム・オペレータを含め、クラスタで実行されるすべてのオペレータとカタログのライフサイクルを管理します。

openshift-service-ca, openshift-service-ca-operator

認証局 ( CA) オペレーターは、証明書の署名を実行し、クラスター内の API サーバー・リソースと構成マップに証明書を組み入れます。 詳しくは GitHub。

パブリック・クラウド・サービス・エンドポイントとプライベート・クラウド・サービス・エンドポイントがあるクラスター

次の図は、パブリックとプライベートの両方のクラウド・サービス・エンドポイントが有効なクラスターの各コンポーネントおよびコンポーネント間の対話方法を示しています。 両方のサービス・エンドポイントが有効であるため、VPC には、サービスごとに、インバウンド・トラフィックのためのパブリック・ロード・バランサーが作成されます。

プライベート・クラウド・サービス・エンドポイントのみ有効なクラスター

次の図は、プライベート・クラウド・サービス・エンドポイントしか有効でないクラスターの各コンポーネント、およびコンポーネント間の対話方法を示しています。 プライベート・クラウド・サービス・エンドポイントしか有効でないため、VPC には、サービスごとに、インバウンド・トラフィックのためのプライベート・ロード・バランサーが作成されます。

VPCマスターノードとワーカーノードのコンポーネント

マスター ノードとワーカーノードには、クラスタのクラシック・クラスタ・アーキテクチャで説明したものと同じコンポーネントが含まれます。 アーキテクチャ OpenShift Container Platform の詳細については、 ドキュメント Red Hat OpenShift を参照してください。

マスター

API サーバーや etcd などのマスター・コンポーネントには 3 つのレプリカがあり、 複数のゾーンに分散されるので、さらに高い可用性が実現されます。 マスターには、クラスタのクラシック・クラスタ・アーキテクチャで説明したものと同じコンポーネントが含まれます。 マスターとすべてのマスター・コンポーネントはお客様ごとに専用のものがあり、IBM の他のお客様と共有されません。

ワーカー・ノード

Red Hat OpenShift on IBM Cloud では、クラスターが管理する仮想マシンは、ワーカー・ノードと呼ばれるインスタンスです。 これらのワーカー・ノードの仮想マシンとすべてのワーカー・ノード・コンポーネントはお客様ごとに専用のものがあり、IBM の他のお客様と共有されません。 ただし、基礎となるハードウェアは IBM の他のお客様と共有されます。 ワーカー・ノードの管理には、API、CLI、コンソールなど、Red Hat OpenShift on IBM Cloud 提供の自動化ツールを使用します。 クラシック・クラスターとは異なり、VPC コンピュートのワーカー・ノードは、インフラストラクチャー・ポータルにも個別のインフラストラクチャー請求書にも表示されません。代わりに、Red Hat OpenShift on IBM Cloudを使用して、ワーカー・ノードの保守と請求に関するあらゆるアクティビティーを管理します。

ワーカーノードには、クラシック・クラスタ・アーキテクチャで説明したものと同じ コンポーネントが 含まれます。

oc get nodes を実行すると、ワーカー・ノードの「ROLES」に、「master,worker」のように両方のマークが表示されることがあります。 これらのノードは IBM Cloud のワーカー・ノードであり、 IBM 管理のマスター・コンポーネントは含まれません。 master のマークが表示されるのは、これらのノードが、クラスター内のデフォルト・リソース (OperatorHub や内部レジストリーなど) のセットアップや管理に必要な OpenShift Container Platform コンポーネントを実行するからです。

クラスター・ネットワーキング

ワーカー・ノードは、お客様が指定したゾーンの VPC サブネット内に作成されます。 マスターとワーカー・ノードの間の通信は、プライベート・ネットワーク経由で行われます。 パブリックとプライベートのクラウド・サービス・エンドポイントを有効にしてクラスターを作成した場合、認証された外部ユーザーは、パブリック・ネットワークを使用してマスターと通信し、oc コマンドなどを実行することができます。 プライベート・クラウド・サービス・エンドポイントのみを有効にしてクラスターを作成した場合、認証された外部ユーザーは、プライベート・ネットワークでしかマスターと通信できません。 プライベート・ネットワーク上に VPC VPN、IBM Cloud Direct Link、または IBM Cloud Transit Gateway をセットアップすると、オンプレミスのネットワーク、他の VPC、またはクラシック・インフラストラクチャー内のリソースと通信するようにクラスターをセットアップできます。

アプリ・ネットワーキング

Virtual Private Cloudのロードバランサーは、クラスタ内に作成したネットワーキング・サービスのために、クラスタ外のVPC内に自動的に作成されます。 例えば、VPC ロード・バランサーは、クラスター内のルーター・サービスをデフォルトで公開します。 アプリ用の Kubernetes LoadBalancer サービスを作成することもできます。その場合、VPC ロード・バランサーが自動的に生成されます。 VPC ロード・バランサーはマルチゾーンであり、ワーカー・ノードで自動的に開かれるプライベート NodePort を介して、アプリに要求を転送します。 パブリックとプライベートのクラウド・サービス・エンドポイントを有効にした場合は、ルーターと VPC ロード・バランサーが、デフォルトでパブリックとして作成されます。 プライベート・クラウド・サービス・エンドポイントのみを有効にした場合は、ルーターと VPC ロード・バランサーが、デフォルトでプライベートとして作成されます。 詳しくは、VPC クラスターのパブリック・アプリ・ネットワーキングまたは プライベート・アプリ・ネットワーキングを参照してください。 Calico は、クラスター・ネットワーキング・ポリシー・ファブリックとして使用されます。

ストレージ

IBM Cloud Object Storageと Cloud Databases のみをセットアップできます。