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 Webコンソールにおける視点 からデプロイできます。

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 から内部レジストリーにイメージをインポートしたりすることもできます。 内部レジストリには、 レジストリイメージを保存 するための「 File Storage for Classic 」ボリュームが、 IBM Cloud インフラストラクチャアカウントに付属しています。 このファイル・ストレージ・ボリュームは、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

このマーケットプレイスには、 OperatorHubRed Hat OpenShift クラスタにデフォルトで付属するものが含まれています。 OperatorHub には、Red Hat やサード・パーティー・プロバイダーのオペレーターが入っています。 これらのオペレーターはコミュニティーから提供されるものであり、クラスターと統合しなくてもかまいません。また、IBM がサポートするものではないことを忘れないでください。 Red Hat OpenShift のWebコンソールにある「 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 つのレプリカがあり、 複数のゾーンに分散されるので、さらに高い可用性が実現されます。 Mastersには、クラスタ向けの「Classic」クラスタアーキテクチャで説明されているのと同じ構成要素が含まれています。 マスターとすべてのマスター・コンポーネントはお客様ごとに専用のものがあり、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、またはクラシック・インフラストラクチャー内のリソースと通信するようにクラスターをセットアップできます。

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

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

ストレージ

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