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

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

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

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

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

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

Welcome ページで Create resource ボタンを選択すると、リソースの作成時に発生するエラーに関するアラートが表示される可能性があります。

この問題を解決するには、以下の手順を実行します。

重要: 入力した情報は、Create resource ページを更新すると失われます。

クラスターのインポート後に、インポートしたクラスターにログインして、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 となります。コマンドを再度実行すると、インポートが正常に実行されるはずです。

オンラインクラスターをアタッチした直後にデタッチすると、Klusterlet は manifestwork が同期する前に、デタッチされたクラスターで稼働し始めます。ハブクラスターからマネージドクラスターを削除しても、Klusterlet はアンインストールされません。問題を解決するには以下の手順を実行します。

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 ページに表示される内容と異なる場合があります。

managedclusteraction で複数のリソースはサポートされません。コンソールのリソース作成機能から、複数のリソースで、 YAML マニフェストを適用することはできません。

パイプラインの検索結果では、正確なリソース数を返しますが、パイプラインカードでは、アプリケーションで使用されていないリソースを表示するので、この数はカードの数と異なる場合があります。

たとえば、kind:channel の検索後に、チャネルが 10 件表示されるにも拘らず、コンソールのパイプラインカードでは使用されているチャネル 5 件だけが表示される可能性があります。

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

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

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

チャネル namespace 内で deployable リソースを手作業で作成する必要があります。

deployable リソースを正しく作成するには、deployable に必要な以下のラベル 2 つをサブスクリプションコントローラーに追加して、このコントローラーで追加する deployable リソースを特定します。

labels:
    apps.open-cluster-management.io/channel: <channel name>
    apps.open-cluster-management.io/channel-type: Namespace

各 deployable の spec.template.metadata.namespace でテンプレートの namespace を指定しないでください。

namespace タイプのチャネルおよびサブスクリプションの場合は、deployable テンプレートがすべてマネージドクラスターのサブスクリプション namespace にデプロイされます。そのため、サブスクリプション namespace 以外で定義される deployable テンプレートは省略されます。

詳細は、「チャネルの作成および管理」を参照してください。

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 に各チャネルを作成することを推奨します。ただし、Git チャネルは、Git、Helm、Kubernetes namespace、オブジェクトストアなどの別のチャネルタイプで namespace を共有できます。

Red Hat Advanced Cluster Management for Kubernetes がインストールされ、OpenShift Container Platform がカスタム Ingress 証明書でカスタマイズされると、500 Internal Error メッセージが表示されます。OpenShift Container Platform 証明書が Red Hat Advanced Cluster Management for Kubernetes の管理 Ingress に含まれていないため、コンソールにアクセスできません。以下の手順を実行して OpenShift Container Platform 証明書を追加します。

上記の手順が完了したら、変更がチャートに伝播されるまで数分待ち、ログインし直します。OpenShift Container Platform 証明書が追加されます。

特定のポリシーの全クラスター違反がポリシーの詳細パネルに一覧表示されます。ユーザーにクラスターへのロールアクセスがない場合には、クラスター名は表示されません。クラスター名は、- の記号で表示されます。

クラスターが実行されていない時にクラスターに適用されたポリシーは NonCompliant とみなされます。違反の詳細を表示すると、status パラメーターが空になっています。

ポリシーを作成または変更した後には、Red Hat Advanced Cluster Management コンソールのポリシー詳細で、配置ルールとポリシーバインディングが空になっている可能性があります。これは通常、ポリシーが無効になっているか、またはポリシーにその他の更新が加えられたことが原因となっています。YAML ビューのポリシーに対して、設定が正しく設定されていることを確認します。

cert-manager および cert-manager-webhook-helmreleases を削除すると、Helm リリースがトリガーされ、チャートを自動的に再デプロイして新しい証明書を生成します。新しい証明書は、他の Red Hat Advanced Cluster Management コンポーネントを作成する他の helm チャートに同期する必要があります。ハブクラスターから証明書コンポーネントを復元するには、以下の手順を実行します。

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

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

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

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

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

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 での操作またはアクセス権をクラスターレベルで制御できるように設定します。