リリースノート

可観測性の詳細は、「環境の監視の紹介」を参照してください。

Openshift Container Platform クラスターがアップグレードの段階に入ると、クラスター Pod は再起動され、クラスターのステータスが 1-5 分ほど、upgrade failed のままになることがあります。この動作は想定されており、数分後に解決されます。

Red Hat Advanced Cluster Management for Kubernetes をインストールする時に、クラスター上に証明書マネージャーを配置させることはできません。

証明書マネージャーがクラスターに存在すると、Red Hat Advanced Cluster Management for Kubernetes のインストールに失敗します。

この問題を解決するには、以下のコマンドを実行して、証明書マネージャーがクラスターに存在するかどうかを確認します。

kubectl get crd | grep certificates.certmanager

kubectl get crd | grep certificates.certmanager

Cluster ページに表示されているノード数と Search の結果々で差異が生じる場合があります。

LDAP ユーザー名は、大文字と小文字が区別されます。LDAP ディレクトリーで設定したものと全く同じ名前を使用する必要があります。

この製品は、Linux、macOS、および Windows で利用可能な Mozilla Firefox 74.0 または最新バージョンをサポートします。コンソールの互換性を最適化するため、最新版にアップグレードしてください。

コンソールおよび Visual Web ターミナルから、値に空白が含まれている場合には検索できません。

kubeadmin でログインしており、ドロップダウンメニューから Log out オプションをクリックすると、コンソールはログイン画面に戻りますが、/logout URL のブラウザータブが開きます。このページは空白であるため、コンソールに影響を与えずにタブを閉じることができます。

セキュリティー上の理由で、検索時にマネージドクラスターにあるシークレットの内容は表示されません。コンソールからシークレットを検索すると、以下のエラーメッセージが表示される場合があります。

Unable to load resource data - Check to make sure the cluster hosting this resource is online

Unable to load resource data - Check to make sure the cluster hosting this resource is online

searchcustomization CR でストレージサイズを更新する場合、PVC 設定は変更されません。ストレージサイズを更新する必要がある場合は、以下のコマンドで PVC (<storageclassname>-search-redisgraph-0) を更新します。

oc edit pvc <storageclassname>-search-redisgraph-0

oc edit pvc <storageclassname>-search-redisgraph-0

Safari v14.0.3 Web ブラウザーを使用する場合は、Search ページから YAML ファイルは表示されません。サポート対象の他のブラウザーについては Supported browsers を参照してください。または、Safari バージョンをアップグレードしてください。

2.2.z から 2.2.5 にアップグレードすると、redisgraph StatefulSet および Pod はリフレッシュされません。変更が反映されるように、redisgraph StatefulSet を手動で削除する必要があります。問題を解決するには以下の手順を実行します。

redisgraph StatefulSet および Pod が再起動しました。

可観測性エンドポイントオペレーターは、MultiClusterObservability CustomResource (CR) へのデプロイにプルシークレットを作成したにも拘らず、open-cluster-management-observability namespace にプルシークレットがない場合に問題が発生します。新しいクラスターをインポートする場合、または Red Hat Advanced Cluster Management で作成された Hive クラスターをインポートする場合は、マネージドクラスターにプルイメージシークレットを手動で作成する必要があります。

詳細は、「可観測性の有効化」を参照してください。

マネージドクラスターを強制的にデタッチすると、クラスター namespace にある ObservabilityAddon リソース (observability-addon) が Terminating の状態のままになり、削除できません。また、クラスター namespace も削除できません。

この問題を修正するには、クラスター namespace の ObervabilityAddon リソースを更新してください。メタデータの finalizers パラメーターを削除してリソースを更新します。以下のコマンドを実行します。

kubectl edit observabilityaddon observability-addon -n <CLUSTER_NAMESPACE>

kubectl edit observabilityaddon observability-addon -n <CLUSTER_NAMESPACE>

CLUSTER_NAMESPACE は、デタッチされたクラスターの namespace です。

finalizers パラメーターを削除してから ObervabilityAddon リソースを削除します。

Red Hat Advanced Cluster Management の可観測性は、組み込みダッシュボードで、ROKS クラスターのデータが表示されないパネルがあります。これは、ROKS が、管理対象サーバーからの API サーバーメトリクスを公開しないためです。以下の Grafana ダッシュボードには、Kubernetes/API server、Kubernetes/Compute Resources/Workload、Kubernetes/Compute Resources/Namespace(Workload) の ROKS クラスターをサポートしないパネルが含まれます。

Red Hat Advanced Cluster Management を 2.2.3 から 2.2.4 にアップグレードした後、open-cluster-management-addon-observability の metrics-collector がマネージドクラスターからデータの収集が停止してしまう可能性があります。これは、マルチクラスター可観測性 Operator のアップグレード後にイメージマニフェストの ConfigMap がアップグレードされたためです。

以下の Quay.io イメージが endpoint-observabililty-operator YAML ファイルで使用されることを確認できます (quay.io/open-cluster-management/endpoint-monitoring-operator:2.2.0-6a5ea47fc39d51fb4fade6157843f2977442996e および quay.io/open-cluster-management/metrics-collector:2.2.0-ff79e6ec8783756b942a77f08b3ab763dfd2dc15。

この問題を修正するには、ハブクラスターの open-cluster-management namespace にある multicluster-observability-operator Pod を削除します。新規 Pod が作成されると、適切なイメージで新しい endpoint-observability-operator デプロイメントがマネージドクラスターに作成されます。

Red Hat Advanced Cluster Management を 2.1 から 2.2.x にアップグレードした後に、MultiClusterObservability カスタムリソース (CR) は引き続き OpenShift Container Platform コンソールからの Installing を表示します。Grafana コンソールからメトリクスデータが表示されることを確認して、MultiClusterObservability が正常にデプロイされていることを確認できます。

一部のメトリクスデータは、Red Hat OpenShift Container Platform と 4.8 クラスターの Grafana ダッシュボードには表示されません。バージョン 2.3 にアップグレードする必要があります。詳細は、「Operator を使用したアップグレード」を参照してください。

Google Cloud Platform(GCP)でのクラスターのプロビジョニングを試みると、以下のエラーを出して失敗する可能性があります。

Cluster initialization failed because one or more operators are not functioning properly.
The cluster should be accessible for troubleshooting as detailed in the documentation linked below,
https://docs.openshift.com/container-platform/latest/support/troubleshooting/troubleshooting-installations.html
The 'wait-for install-complete' subcommand can then be used to continue the installation

Cluster initialization failed because one or more operators are not functioning properly.
The cluster should be accessible for troubleshooting as detailed in the documentation linked below,
https://docs.openshift.com/container-platform/latest/support/troubleshooting/troubleshooting-installations.html
The 'wait-for install-complete' subcommand can then be used to continue the installation

GCP プロジェクトで ネットワークセキュリティー API を有効にして、このエラーを回避することができます。これにより、クラスターのインストールを継続できます。

Cluster details ページでマネージドクラスターまたはローカルクラスターをアップグレードする場合に、アップグレードプロセスが完了してから、更新されたバージョン番号が Cluster details ページに表示されるまで最長 10 分かかることがあります。

ハブクラスターが OpenShift Container Platform バージョン 4.7 でホストされる場合は、Red Hat Advanced Cluster Management ハブクラスターを使用してベアメタルマネージドクラスターを作成することはできません。

マネージドクラスターをデタッチすると、Create resources ページが一時的に破損し、以下のエラーが表示される可能性があります。

Error occurred while retrieving clusters info. Not found.

Error occurred while retrieving clusters info. Not found.

namespace が自動的に削除されるまで待ちます。待機時間は、クラスターのデタッチ後、5-10 分ほどです。または、namespace が終了状態のままの場合、namespace を手動で削除する必要があります。ページに戻り、エラーが解決されたかどうかを確認します。

ハブクラスターおよびマネージドクラスターの時間が同期されず、コンソールで unknown と表示され、最数的に、数分以内に available と表示されます。Red Hat OpenShift Container Platform ハブクラスターの時間が正しく設定されていることを確認します。「ノードのカスタマイズ」を参照してください。

クラスターのインポート後に、インポートしたクラスターにログインして、Klusterlet でデプロイした Pod すべてが実行中であることを確認します。全 Pod が実行されていない場合に、コンソールで矛盾するデータが表示される可能性があります。

ポリシーコントローラーを実行していない場合など、Governance and risk ページと Cluster status で同じ違反結果が表示されない可能性があります。

たとえば、Overview ステータスで違反が 0 件と表示されているにも拘らず、Governance and risk ページで違反が 12 件報告される場合などです。

このような場合には、ページ間で不整合があると、マネージドクラスターの policy-controller-addon とハブクラスターのポリシーコントローラーが連携されていないことが分かります。また、マネージドクラスターには、すべての Klusterlet コンポーネントを実行するためのリソースが十分にない可能性があります。

その結果、ポリシーはマネージドクラスターに伝播されないことや、違反がマネージドクラスターから報告されないことがありました。

Red Hat Advanced Cluster Management ハブクラスターで以前に管理されていて、デタッチされたクラスターをインポートすると、1 回目のインポートプロセスが失敗する可能性があります。クラスターのステータスは pending import となります。コマンドを再度実行すると、インポートが正常に実行されるはずです。

IBM Red Hat OpenShift Kubernetes Service バージョン 3.11 のクラスターをインポートすることはできません。IBM OpenShift Kubernetes Service の 3.11 よりも後のバージョンはサポート対象です。

クラウドプロバイダーのアクセスキーを変更しても、プロビジョニングされたクラスターのアクセスキーは、namespace で更新されません。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。このような場合は、以下のコマンドを実行して、クラウドプロバイダーでアクセスキーを更新します。

management-ingress サービスを実行するには、root でログインする必要があります。

検索で、ハブクラスターのリソース用の RBAC がマッピングされます。Red Hat Advanced Cluster Management のユーザー RBAC 設定によっては、マネージドクラスターからのノードデータが表示されない場合があります。また検索の結果は、クラスターの Nodes ページに表示される内容と異なる場合があります。

マネージドクラスターを破棄してから 1 時間経過してもステータスが Destroying のままで、クラスターが破棄されません。この問題を解決するには、以下の手順を実行します。

Red Hat Advanced Cluster Management コンソールを使用して、Red Hat OpenShift Dedicated 環境にある OpenShift Container Platform マネージドクラスターをアップグレードすることはできません。

ベアメタルアセットは、関連付けられたクラスターを破棄した後、孤立したアセットとして残る可能性があります。これは、クラスターを破棄するために必要なパーミッションはあるけれども、ベアメタルアセットを破棄するパーミッションがない場合に発生します。この問題を回避するには、クラスターデプロイメントを参照する Red Hat Advanced Cluster Management でベアメタルアセットを作成する際に、ファイナライザーを ClusterDeployment リソースに追加します。

kubectl patch clusterdeployments <name> -n <namespace> -p '{"metadata":{"finalizers":["baremetalasset.inventory.open-cluster-management.io"]}}'

kubectl patch clusterdeployments <name> -n <namespace> -p '{"metadata":{"finalizers":["baremetalasset.inventory.open-cluster-management.io"]}}'

name は、お使いのクラスターデプロイメント名に置き換えます。

namespace は、お使いのクラスターリソースの namespace に置き換えます。

クラスターデプロイメントを削除する場合、以下のコマンドを入力してファイナライザーを手動で削除する必要があります。

kubectl patch clusterdeployments <name> -n <namespace> -p '{"metadata":{"finalizers":[]}}'

kubectl patch clusterdeployments <name> -n <namespace> -p '{"metadata":{"finalizers":[]}}'

name は、お使いのクラスターデプロイメント名に置き換えます。

namespace は、お使いのクラスターリソースの namespace に置き換えます。

Active within specified interval に設定されたデプロイメントウィンドウでアプリケーションを作成する場合は、デプロイメントウィンドウが正しく計算されず、アプリケーションが未定義の時間でデプロイされることがあります。

アプリケーション名は 37 文字を超えることができません。この数を超えると、アプリケーションのデプロイメント時に以下のエラーが表示されます。

status:
  phase: PropagationFailed

status:
  phase: PropagationFailed

特定のマネージドクラスターにある特定のリソースの検索詳細ページで問題が発生する可能性があります。マネージドクラスターの work-manager アドオンが Available ステータスであることを確認してから検索する必要があります。

仕様なしで Deployable リソースを適用すると、Pod の multicluster-operators-application コンテナー multicluster-operators-deployable をクラッシュします。deployable には仕様が含まれている必要があります。

仕様なしでリソースを誤って作成する場合は、不要な deployable を削除して、multicluster-operators-application Pod を再起動します。

空で Pod をクラッシュさせる以下の Deployable の例を参照してください。

apiVersion: apps.open-cluster-management.io/v1
kind: Deployable
metadata:
  labels:
    app: simple-app-tester
  name: simple-app-tester-deployable
  namespace: grp-proof-of-concept-acm

apiVersion: apps.open-cluster-management.io/v1
kind: Deployable
metadata:
  labels:
    app: simple-app-tester
  name: simple-app-tester-deployable
  namespace: grp-proof-of-concept-acm

ReplicationController または ReplicaSet リソースを直接作成するアプリケーションをデプロイする場合には、Pod リソースは アプリケーショントポロジー に表示されません。Pod リソースを作成する代わりに、Deployment または DeploymentConfig リソースを使用できます。

Ansible テストは、通常のタスクとしてではなく、サブスクリプションのフックとして実行されます。Ansible タスクは prehook および posthook フォルダーに保存する必要があります。Ansible タスクは、フックとしてではなく、通常のタスクとしてデプロイできますが、このような場合に、アプリケーショントポロジーの Ansible のジョブステータスが正しく報告されません。

Ansible フックのスタンドアロンモードはサポートされていません。サブスクリプションを使用してハブクラスターに Ansible フックをデプロイするには、次のサブスクリプション YAML を使用できます。

apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: sub-rhacm-gitops-demo
  namespace: hello-openshift
annotations:
  apps.open-cluster-management.io/github-path: myapp
  apps.open-cluster-management.io/github-branch: master
spec:
  hooksecretref:
      name: toweraccess
  channel: rhacm-gitops-demo/ch-rhacm-gitops-demo
  placement:
     local: true

apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: sub-rhacm-gitops-demo
  namespace: hello-openshift
annotations:
  apps.open-cluster-management.io/github-path: myapp
  apps.open-cluster-management.io/github-branch: master
spec:
  hooksecretref:
      name: toweraccess
  channel: rhacm-gitops-demo/ch-rhacm-gitops-demo
  placement:
     local: true

ただし、この設定では spec.placement.local:true ではサブスクリプションが standalone モードで実行されているので、Ansible インストールが作成されない可能性があります。ハブモードでサブスクリプションを作成する必要があります。

両方を適用すると、Ansible インスタンスがハブクラスターに作成されているのが表示されるはずです。

アプリケーションの作成または編集時に Deploy on local cluster を選択すると、アプリケーショントポロジーが正しく表示されません。Deploy on local cluster は、ハブクラスターにリソースをデプロイして local cluster として管理できるようにするオプションですが、今回のリリースではベストプラクティスではありません。

この問題を解決するには、以下の手順を参照してください。

namespace チャネルにサブスクライブして、チャネル、シークレット、ConfigMap、または配置ルールなどの他の関連リソースを修正した後にサブスクリプションの状態が FAILED のままになると、namespace サブスクリプションの調整が継続的に行われなくなります。

サブスクリプションの調整を強制的に行い、FAILED の状態から抜けるには、以下の手順を完了してください。

oc label subscriptions.apps.open-cluster-management.io the_subscription_name reconcile=true

oc label subscriptions.apps.open-cluster-management.io the_subscription_name reconcile=true

Editor ロールで実行するユーザーは、アプリケーションで read または update の権限のみが割り当てられているはずにも拘らず、誤ってアプリケーションの create および delete の操作ができてしまいます。Red Hat OpenShift Operator Lifecycle Manager のデフォルト設定により、当製品の設定が変更されてしまいます。この問題を回避するには、以下の手順を参照してください。

Editor ロールで実行するユーザーは、配置ルールで read または update の権限のみが割り当てられているはずにも拘らず、誤って create および delete の操作もできてしまいます。Red Hat OpenShift Operator Lifecycle Manager のデフォルト設定により、当製品の設定が変更されてしまいます。この問題を回避するには、以下の手順を参照してください。

配置ルールの更新後にアプリケーションがデプロイされない場合には、klusterlet-addon-appmgr Pod が実行されていることを確認します。サブスクリプションコンテナーである klusterlet-addon-appmgr は、エンドポイントクラスターで実行する必要があります。

oc get pods -n open-cluster-management-agent-addon を実行して確認します。

また、コンソールで kind:pod cluster:yourcluster を検索し、klusterlet-addon-appmgr が実行中であることを確認できます。

検証できない場合は、もう一度、クラスターのインポートを試行して検証を行います。

Red Hat OpenShift Container Platform SCC に関する説明は、「Security Context Constraints (SCC) の管理」を参照してください。これは、マネージドクラスターで必要な追加の設定です。

デプロイメントごとにセキュリティーコンテキストとサービスアカウントが異なります。サブスクリプション Operator は SCC を自動的に作成できず、管理者が Pod のパーミッションを制御します。Security Context Constraints (SCC) CR は、関連のあるサービスアカウントに適切なパーミッションを有効化して、デフォルトではない namespace で Pod を作成する必要があります。

お使いの namespace で SCC CR を手動で作成するには、以下を実行します。

同じ namespace に複数のチャネルを作成すると、ハブクラスターでエラーが発生する可能性があります。

たとえば、namespace charts-v1 は、Helm タイプのチャネルとしてインストーラーで使用するので、charts-v1 に追加のチャネルを作成します。一意の namespace でチャネルを作成するようにしてください。すべてのチャネルには個別の namespace が必要ですが、GitHub チャネルは例外で、別 GitHub のチャネルと namespace を共有できます。

コンソールのさまざまな アプリケーション の表に対する以下の制限を確認してください。

設定ポリシーで complianceType のパラメーターに mustnothave、remediationAction のパラメーターに enforce が設定されている場合に、ポリシーは Kubernetes API に削除要求が送信されてから、準拠と表示されます。そのため、ポリシーが準拠と表示されているにも関わらず、Kubernetes オブジェクトは、Terminating の状態のままになってしまう可能性があります。

Red Hat Advanced Cluster Management は、Kubernetes の API 非推奨ガイドラインに従います。このポリシーの詳細については、 「Kubernetes の非推奨ポリシー」を参照してください。

Red Hat Advanced Cluster Management API が非推奨または削除となるのは、以下のタイムライン以外のみです。

GDPR は、各自の個人データを処理するにあたり、強力なデータ保護規制フレームワークを確立します。GDPR は以下を提供します。

Red Hat Advanced Cluster Management for Kubernetes はプラットフォームとして、複数の技術データを扱いますが、その内、管理者ユーザー ID とパスワード、サービスユーザー ID とパスワード、Kubernetes ノード名など、個人データとみなされる可能性があるものも含まれます。また、Red Hat Advanced Cluster Management for Kubernetes プラットフォームは、プラットフォームの管理ユーザーに関する情報も扱います。プラットフォームで実行されるアプリケーションにより、プラットフォームではまだ知られていない、他のカテゴリーの個人データが取り込まれる可能性があります。

このような技術データの収集/作成、保存、アクセス、セキュリティー設定、ロギング、削除の方法に関する情報は、本書で後述します。

お客様は、以下のような情報をさまざまな方法でオンラインからコメント/フィードバック/依頼を送信できます。

通常は、連絡先フォームの件名への個人返信を有効にすると、お客様名とメールアドレスのみが使用され、個人データの使用は、Red Hat オンラインプライバシーステートメント に準拠します。

The Red Hat Advanced Cluster Management for Kubernetes プラットフォームの認証マネージャーは、コンソールからのユーザーの認証情報を受け入れ、バックエンドの OIDC プロバイダーに認証情報を転送し、OIDC プロバイダーはエンタープライズディレクトリーに対してユーザーの認証情報を検証します。次に OIDC プロバイダーは認証クッキー (auth-cookie) を、JSON Web Token (JWT) のコンテンツと合わせて、認証マネージャーに返します。JWT トークンは、認証要求時にグループのメンバーシップに加え、ユーザー ID やメールアドレスなどの情報を永続化します。この認証クッキーはその後コンソールに返されます。クッキーはセッション時に更新されます。クッキーは、コンソールをサインアウトしてから、または Web ブラウザーを閉じてから 12 時間有効です。

コンソールから次回認証要求を送信すると、フロントエンドの NGIX サーバーが、要求で利用可能な認証クッキーをデコードし、認証マネージャーを呼び出して要求を検証します。

Red Hat Advanced Cluster Management for Kubernetes プラットフォーム CLI では、ユーザーはログインに認証情報が必要です。

kubectl と oc CLI でも、クラスターへのアクセスに認証情報が必要です。このような認証情報は、管理コンソールから取得でき、12 時間後に有効期限が切れます。サービスアカウント経由のアクセスは、サポートされています。

Red Hat Advanced Cluster Management for Kubernetes プラットフォームは、ロールベースのアクセス制御 (RBAC) をサポートします。ロールマッピングのステージでは、認証ステージで提示されたユーザー名がユーザーまたはグループロールにマッピングされます。認可時にロールを使用して、認証ユーザーがどのような管理者アクティビティーを実行できるか判断します。

Red Hat Advanced Cluster Management for Kubernetes プラットフォームのロールを使用して、クラスター設定アクション、カタログや Helm リソース、Kubernetes リソースへのアクセスを制御します。クラスター管理者、管理者ー、オペレーター、エディター、ビューワーなど、IAM (Identity and Access Management) ロールが複数含まれています。ロールは、チームへの追加時に、ユーザーまたはユーザーグループに割り当てられます。リソースへのチームアクセスは、namespace で制御できます。

Pod のセキュリティーポリシーを使用して、Pod での操作またはアクセス権をクラスターレベルで制御できるように設定します。