第1章 マルチクラスターエンジン Operator を使用したクラスターライフサイクルについて

マルチクラスターエンジン Operator は、OpenShift Container Platform および Red Hat Advanced Cluster Management ハブクラスターにクラスター管理機能を提供するクラスターライフサイクル Operator です。ハブクラスターから、クラスターを作成および管理し、作成したクラスターを破棄できます。クラスターを休止、再開、およびデタッチすることもできます。クラスターライフサイクル機能の詳細は、以下のドキュメントを参照してください。

情報:

クラスターライフサイクル管理アーキテクチャーのコンポーネントは、クラスターライフサイクルアーキテクチャー に含まれています。

1.1. リリースノート

現在のリリースについて学びます。

注記: Red Hat Advanced Cluster Management の 2.4 以前のバージョンはサービスから 削除 され、サポートされなくなりました。バージョン 2.4 以前のドキュメントは更新されていません。ドキュメントはそのまま利用できますが、エラータやその他の更新はなく、非推奨となります。

現在サポートされているリリースのいずれか、または製品ドキュメントで問題が発生した場合は、Red Hat サポート にアクセスして、トラブルシューティングを行ったり、ナレッジベースの記事を表示したり、サポートチームに連絡したり、ケースを開いたりすることができます。認証情報でログインする必要があります。

Red Hat Customer PortalFAQ で、カスタマーポータルのドキュメントの詳細を確認することもできます。

1.1.1. マルチクラスターエンジン Operator を使用したクラスターライフサイクルの新機能

重要: 一部の機能およびコンポーネントは テクノロジープレビュー として指定され、リリースされます。

詳細は、本リリースの新機能を参照してください。

1.1.1.1. インストール

OpenShift Container Platform または Red Hat Advanced Cluster Management をインストールした場合、マルチクラスターエンジン Operator は自動的に受信されます。マルチクラスターエンジン Operator のインストールにのみ新機能が存在する場合は、このセクションで表示できます。

1.1.1.2. クラスターライフサイクル

マルチクラスターエンジン Operator とクラスターライフサイクルに関連する新機能について説明します。

  • cluster-proxy-addon を使用して、プロキシーを使用してマネージドクラスターの任意のサービスに接続できるようになりました。ハブからマネージドクラスターに直接到達して、一部のサービスと対話します。詳細は、クラスタープロキシーアドオンの使用 を参照してください。
  • Amazon Web Services GovCloud でクラスターを作成できるようになりました。詳細は、Amazon Web Services GovCloud でのクラスターの作成 を参照してください。

API - Clusterset: v1beta2 - ClustersetBinding: v1beta2 の新しいバージョンがあります。詳細は、API を参照してください。

  • hosted と standalone の 2 つのコントロールプレーンタイプを使用できます。スタンドアロン はコンソールウィザード機能であり、ホステッド は CLI からクラスターを作成できるように特定の手順およびガイダンスを提供します。
  • MultiClusterEngine カスタムリソースを更新して、ハブクラスターが自身を管理するかどうかを指定できるようになりました。詳細については、ローカルクラスターの有効化 を参照してください。
  • 非接続環境でインフラストラクチャー環境を作成するときに、ConfigMap および AgentServiceConfig ファイルの設定を変更して、非認証レジストリーを指定できます。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • MachinePool を使用したスケーリングが一般提供されるようになったため、自動スケーリングを簡単に設定してリソースをスケーリングできます。詳細は MachinePool によるスケーリング を参照してください。

1.1.1.3. ホステッドコントロールプレーン

1.1.2. クラスターライフサイクルの既知の問題

マルチクラスターエンジン Operator を使用したクラスターライフサイクルの既知の問題を確認します。以下の一覧には、本リリースの既知の問題、または以前のリリースから持ち越された既知の問題が記載されています。OpenShift Container Platform クラスターについては、OpenShift Container Platform リリースノート を参照してください。

1.1.2.1. クラスター管理

クラスターライフサイクルの既知の問題と制限は、マルチクラスターエンジン Operator のドキュメントを使用したクラスターライフサイクルの一部です。

1.1.2.1.1. アドオンの削除時にマネージドクラスターで必要な VolSync CSV の手動削除

ハブクラスターから VolSync ManagedClusterAddOn を削除すると、マネージドクラスターの VolSync Operator サブスクリプションが削除されますが、クラスターサービスバージョン (CSV) は削除されません。マネージドクラスターから CSV を削除するには、VolSync を削除する各マネージドクラスターで以下のコマンドを実行します。

oc delete csv -n openshift-operators volsync-product.v0.6.0

別のバージョンの VolSync がインストールされている場合は、v0.6.0 をインストール済みバージョンに置き換えます。

1.1.2.1.2. マネージドクラスターセットを削除してもそのラベルが自動的に削除されない

ManagedClusterSet を削除した後に、クラスターセットに関連付ける各マネージドクラスターに追加されるラベルは自動的に削除されません。削除したマネージドクラスターセットに含まれる各マネージドクラスターからラベルを手動で削除します。ラベルは cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name> のようになります。

1.1.2.1.3. ClusterClaim エラー

ClusterPool に対して Hive ClusterClaim を作成し、ClusterClaimspec ライフタイムフィールドを無効な golang 時間値に手動で設定すると、製品は不正な要求だけでなく、すべての ClusterClaims を満たし、調整を停止します。

このエラーが発生すると、clusterclaim-controller Pod ログに以下の内容が表示されます。これは、プール名と、無効な有効期限が含まれた特定の例です。

E0203 07:10:38.266841       1 reflector.go:138] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:224: Failed to watch *v1.ClusterClaim: failed to list *v1.ClusterClaim: v1.ClusterClaimList.Items: []v1.ClusterClaim: v1.ClusterClaim.v1.ClusterClaim.Spec: v1.ClusterClaimSpec.Lifetime: unmarshalerDecoder: time: unknown unit "w" in duration "1w", error found in #10 byte of ...|time":"1w"}},{"apiVe|..., bigger context ...|clusterPoolName":"policy-aas-hubs","lifetime":"1w"}},{"apiVersion":"hive.openshift.io/v1","kind":"Cl|...

無効な要求を削除できます。

不正な要求が削除されると、要求は追加の対話なしに正常に調整を開始します。

1.1.2.1.4. 製品チャネルが、プロビジョニングされたクラスターと同期されない

clusterimagesetfast チャネルに置かれますが、プロビジョニングされたクラスターは stable チャネルにあります。現時点で、製品は channel をプロビジョニングされた OpenShift Container Platform クラスターと同期しません。

OpenShift Container Platform コンソールで適切なチャネルに切り替えます。Administration > Cluster Settings > Details Channel の順にクリックします。

1.1.2.1.5. カスタム CA 証明書を使用した管理対象クラスターの、復元されたハブクラスターへの接続の復元は失敗する可能性がある

カスタム CA 証明書を使用してクラスターを管理したハブクラスターのバックアップを復元した後、管理対象クラスターとハブクラスター間の接続が失敗する場合があります。これは、復元されたハブクラスターで CA 証明書がバックアップされなかったためです。接続を復元するには、管理対象クラスターの namespace にあるカスタム CA 証明書情報を、復元されたハブクラスターの <managed_cluster>-admin-kubeconfig シークレットにコピーします。

ヒント: バックアップコピーを作成する前にこの CA 証明書をハブクラスターにコピーする場合は、バックアップコピーにシークレット情報が含まれます。将来、バックアップコピーを使用して復元する場合、ハブと管理対象クラスター間の接続は自動的に完了します。

1.1.2.1.6. ローカルクラスターが自動的に再作成されない場合がある

disableHubSelfManagementfalse に設定されている場合、local-cluster は MulticlusterHub Operator によって再作成されます。ローカルクラスターをデタッチした後、ローカルクラスターが自動的に再作成されない場合があります。

  • この問題を解決するには、MulticlusterHub によって監視されるリソースを変更します。以下の例を参照してください。

    oc delete deployment multiclusterhub-repo -n <namespace>
  • local-cluster を適切にデタッチするには、MultiClusterHubdisableHubSelfManagement を true に設定します。
1.1.2.1.7. オンプレミスクラスターを作成する場合は、サブネットを選択する必要がある

コンソールを使用してオンプレミスクラスターを作成する場合は、クラスターで利用可能なサブネットを選択する必要があります。必須フィールドとしてマークされていません。

1.1.2.1.8. Infrastructure Operator を使用したクラスターのプロビジョニングに失敗する

Infrastructure Operator を使用して OpenShift Container Platform クラスターを作成する場合、ISO イメージのファイル名は長すぎる可能性があります。長いイメージ名により、イメージのプロビジョニングとクラスターのプロビジョニングが失敗します。この問題が生じるかどうかを確認するには、以下の手順を実行します。

  1. 以下のコマンドを実行して、プロビジョニングするクラスターのベアメタルホスト情報を表示します。

    oc get bmh -n <cluster_provisioning_namespace>
  2. describe コマンドを実行して、エラー情報を表示します。

    oc describe bmh -n <cluster_provisioning_namespace> <bmh_name>
  3. 以下の例と同様のエラーは、ファイル名の長さが問題であることを示します。

    Status:
      Error Count:    1
      Error Message:  Image provisioning failed: ... [Errno 36] File name too long ...

この問題が発生する場合、これは通常 OpenShift Container Platform の以下のバージョンで発生します。インフラストラクチャー Operator がイメージサービスを使用していないためです。

  • 4.8.17 以前
  • 4.9.6 以前

このエラーを回避するには、OpenShift Container Platform をバージョン 4.8.18 以降、または 4.9.7 以降にアップグレードしてください。

1.1.2.1.9. 別の名前で再インポートした後に local-cluster のステータスがオフラインになる

local-cluster という名前のクラスターを、誤って別の名前のクラスターとして再インポートしようとすると、local-cluster と再インポートしたクラスターのステータスが offline と表示されます。

このケースから回復するには、以下の手順を行います。

  1. ハブクラスターで以下のコマンドを実行して、ハブクラスターの自己管理の設定を一時的に編集します。

    oc edit mch -n open-cluster-management multiclusterhub
  2. spec.disableSelfManagement=true の設定を追加します。
  3. ハブクラスターで以下のコマンドを実行し、local-cluster を削除し、再デプロイします。

    oc delete managedcluster local-cluster
  4. 以下のコマンドを実行して local-cluster 管理設定を削除します。

    oc edit mch -n open-cluster-management multiclusterhub
  5. 前の手順で追加した spec.disableSelfManagement=true を削除します。
1.1.2.1.10. Ansible 自動化を使用したクラスタープロビジョニングがプロキシー環境で失敗する

マネージドクラスターを自動的にプロビジョニングするように設定された自動化テンプレートは、次の両方の条件が満たされた場合に失敗する可能性があります。

  • ハブクラスターで、クラスター全体のプロキシーが有効になっている。
  • Ansible Automation Platform には、プロキシー経由でのみアクセスできます。
1.1.2.1.11. klusterlet Operator のバージョンは、ハブクラスターと同じである必要がある

klusterlet Operator をインストールしてマネージドクラスターをインポートする場合には、klusterlet Operator のバージョンは、ハブクラスターのバージョンと同じでなければなりません。そうでないと、klusterlet Operator は動作しません。

1.1.2.1.12. マネージドクラスター namespace を手動で削除できない

マネージドクラスターの namespace を手動で削除できません。マネージドクラスター namespace は、マネージドクラスターの割り当てを解除した後に自動的に削除されます。マネージドクラスターの割り当てを解除する前に手動でマネージドクラスター namespace を削除する場合は、マネージドクラスターの削除後にマネージドクラスターに継続的な終了ステータスが表示されます。この終了マネージドクラスターを削除するには、割り当てを解除したマネージドクラスターからファイナライザーを手動で削除します。

1.1.2.1.13. ハブクラスターとマネージドクラスターのクロックが同期されない

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

1.1.2.1.14. IBM OpenShift Container Platform Kubernetes Service クラスターの特定のバージョンのインポートはサポートされていない

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

1.1.2.1.15. プロビジョニングされたクラスターのシークレットの自動更新はサポートされていない

クラウドプロバイダー側でクラウドプロバイダーのアクセスキーを変更する場合は、マルチクラスターエンジン Operator のコンソールでこのクラウドプロバイダーの対応する認証情報を更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。

1.1.2.1.17. クラスターを破棄するプロセスが完了しない

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

  1. クラウドに孤立したリソースがなく、マネージドクラスターに関連付けられたプロバイダーリソースがすべて消去されていることを確認します。
  2. 以下のコマンドを入力して、削除するマネージドクラスターの ClusterDeployment 情報を開きます。

    oc edit clusterdeployment/<mycluster> -n <namespace>

    mycluster は、破棄するマネージドクラスターの名前に置き換えます。

    namespace は、マネージドクラスターの namespace に置き換えます。

  3. hive.openshift.io/deprovision ファイナライザーを削除し、クラウドのクラスターリソースを消去しようとするプロセスを強制的に停止します。
  4. 変更を保存して、ClusterDeployment が削除されていることを確認します。
  5. 以下のコマンドを実行してマネージドクラスターの namespace を手動で削除します。

    oc delete ns <namespace>

    namespace は、マネージドクラスターの namespace に置き換えます。

1.1.2.1.18. OpenShift Container Platform Dedicated でコンソールを使用して OpenShift Container Platform マネージドクラスターをアップグレードできない

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

1.1.2.1.20. Red Hat OpenShift Container Platform 以外のマネージドクラスターでは、LoadBalancer が有効にされている必要がある

Red Hat OpenShift Container Platform および OpenShift Container Platform 以外のクラスターの両方は Pod ログ機能をサポートしますが、OpenShift Container Platform 以外のクラスターでは、この機能を使用できるように LoadBalancer が有効にされている必要があります。LoadBalancer を有効にするには、以下の手順を実行します。

  1. クラウドプロバイダーごとに LoadBalancer 設定が異なります。詳細は、クラウドプロバイダーのドキュメントを参照してください。
  2. managedClusterInfo のステータスで loggingEndpoint をチェックして、LoadBalancer が Red Hat Advanced Cluster Management で有効にされているかどうかを確認します。
  3. 以下のコマンドを実行して、loggingEndpoint.IP または loggingEndpoint.Host に有効な IP アドレスまたはホスト名が設定されていることを確認します。

    oc get managedclusterinfo <clusterName> -n <clusterNamespace> -o json | jq -r '.status.loggingEndpoint'

LoadBalancer のタイプについての詳細は、Kubernetes のドキュメントService ページを参照してください。

1.1.2.1.21. OpenShift Container Platform 4.10.z では、プロキシー設定を使用するホステッドコントロールプレーンクラスターはサポートされません

OpenShift Container Platform 4.10.z でクラスター全体のプロキシー設定を使用してホスティングサービスクラスターを作成すると、nodeip-configuration.service サービスがワーカーノードで開始されません。

1.1.2.1.22. Azure で OpenShift Container Platform 4.11 クラスターをプロビジョニングできない

Azure で OpenShift Container Platform 4.11 クラスターをプロビジョニングすると、認証 Operator のタイムアウトエラーが原因で失敗します。この問題を回避するには、install-config.yaml ファイルで別のワーカーノードタイプを使用するか、vmNetworkingType パラメーターを Basic に設定します。次の install-config.yaml の 例を参照してください。

compute:
- hyperthreading: Enabled
  name: 'worker'
  replicas: 3
  platform:
    azure:
      type:  Standard_D2s_v3
      osDisk:
        diskSizeGB: 128
      vmNetworkingType: 'Basic'
1.1.2.1.23. クライアントが iPXE スクリプトにアクセスできない

iPXE は、オープンソースのネットワークブートファームウェアです。詳細は、iPXE を参照してください。

ノードの起動時に、一部の DHCP サーバーの URL の長さ制限により、InfraEnv カスタムリソース定義の ipxeScript URL が切り取られ、コンソールに次のエラーメッセージが表示されます。

起動可能なデバイスがありません

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

  1. 自動インストールを使用して bootArtifacts を公開する場合は、InfraEnv カスタムリソース定義を適用します。これは次のファイルのようになります。

    status:
      agentLabelSelector:
        matchLabels:
          infraenvs.agent-install.openshift.io: qe2
      bootArtifacts:
        initrd: https://assisted-image-service-multicluster-engine.redhat.com/images/0000/pxe-initrd?api_key=0000000&arch=x86_64&version=4.11
        ipxeScript: https://assisted-service-multicluster-engine.redhat.com/api/assisted-install/v2/infra-envs/00000/downloads/files?api_key=000000000&file_name=ipxe-script
        kernel: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.11/latest/rhcos-live-kernel-x86_64
        rootfs: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.11/latest/rhcos-live-rootfs.x86_64.img
  2. 短い URL で bootArtifacts を公開するプロキシーサーバーを作成します。
  3. 次のコマンドを実行して、bootArtifacts をコピーし、プロキシーに追加します。

    for artifact in oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts}" | jq ". | keys[]" | sed "s/\"//g"
    do curl -k oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts.${artifact}}"` -o $artifact
  4. ipxeScript アーティファクトプロキシー URL を libvirt.xmlbootp パラメーターに追加します。
1.1.2.1.24. Red Hat Advanced Cluster Management のアップグレード後に ClusterDeployment を削除できない

Red Hat Advanced Cluster Management 2.6 で削除された BareMetalAssets API を使用している場合、BareMetalAssets API が ClusterDeployment にバインドされているため、Red Hat Advanced Cluster Management 2.7 にアップグレードした後に ClusterDeployment を削除することはできません。

この問題を回避するには、以下のコマンドを実行して、Red Hat Advanced Cluster Management 2.7 にアップグレードする前に finalizers を削除します。

oc patch clusterdeployment <clusterdeployment-name> -p '{"metadata":{"finalizers":null}}' --type=merge
1.1.2.1.25. CIM サービスを使用して非接続環境にデプロイしたクラスターがインストールされない場合がある

Central Infrastructure Management サービスを使用して非接続環境でクラスターをデプロイすると、クラスターノードのインストールが開始されない場合があります。

この問題は、OpenShift Container Platform バージョン 4.12.0 から 4.12.2 に同梱されている Red Hat Enterprise Linux CoreOS ライブ ISO イメージから作成された検出 ISO イメージをクラスターが使用するために発生します。イメージには、registry.redhat.io および registry.access.redhat.com から取得したイメージの署名を必要とする制限付きの /etc/containers/policy.json ファイルが含まれています。非接続環境では、ミラーリングされたイメージにミラーリングされた署名がない場合があり、その結果、クラスターノードの検出時にイメージのプルが失敗します。エージェントイメージがクラスターノードとの接続に失敗するため、アシストサービスとの通信が失敗します。

この問題を回避するには、/etc/containers/policy.json ファイルを制限なしに設定する ignition オーバーライドをクラスターに適用します。ignition オーバーライドは、InfraEnv カスタムリソース定義で設定できます。次の例は、オーバーライドを使用した InfraEnv カスタムリソース定義を示しています。

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: cluster
  namespace: cluster
spec:
  ignitionConfigOverride: '{"ignition":{"version":"3.2.0"},"storage":{"files":[{"path":"/etc/containers/policy.json","mode":420,"overwrite":true,"contents":{"source":"data:text/plain;charset=utf-8;base64,ewogICAgImRlZmF1bHQiOiBbCiAgICAgICAgewogICAgICAgICAgICAidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIgogICAgICAgIH0KICAgIF0sCiAgICAidHJhbnNwb3J0cyI6CiAgICAgICAgewogICAgICAgICAgICAiZG9ja2VyLWRhZW1vbiI6CiAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIiI6IFt7InR5cGUiOiJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dCiAgICAgICAgICAgICAgICB9CiAgICAgICAgfQp9"}}]}}'

次の例は、作成される制限なしのファイルを示しています。

{
    "default": [
        {
            "type": "insecureAcceptAnything"
        }
    ],
    "transports": {
        "docker-daemon": {
        "": [
        {
            "type": "insecureAcceptAnything"
        }
        ]
    }
    }
}

この設定を変更すると、クラスターがインストールされます。

1.1.2.2. ホステッドコントロールプレーン

1.1.2.2.1. コンソールにホステッドクラスターが Pending import として表示される

アノテーションと ManagedCluster 名が一致しない場合、コンソールはクラスターを Pending import と表示します。クラスターはマルチクラスターエンジン Operator では使用できません。アノテーションがなく、ManagedCluster 名が HostedCluster リソースの Infra-ID 値と一致しない場合は、同じ問題が発生します。

1.1.2.2.2. コンソールは、ホステッドクラスターにノードプールを追加する際に、同じバージョンを複数回、一覧表示する場合があります。

コンソールを使用して既存のホステッドクラスターに新規ノードプールを追加すると、同じバージョンの OpenShift Container Platform がオプションの一覧に複数回、表示される可能性があります。必要なバージョンの一覧で任意のインスタンスを選択できます。

1.1.3. エラータの更新

マルチクラスターエンジン Operator の場合、エラータの更新はリリース時に自動的に適用されます。

重要: 参照できるように、エラータ リンクと GitHub 番号がコンテンツに追加され、内部で使用される可能性があります。ユーザーは、アクセス権が必要なリンクを利用できない可能性があります。

FIPS の通知: spec.ingress.sslCiphers で独自の暗号を指定しない場合、multiclusterhub-operator は暗号のデフォルトリストを提供します。2.4 の場合には、この一覧には、FIPS 承認されていない暗号が 2 つ含まれます。バージョン 2.4.x 以前からアップグレードし、FIPS コンプライアンスが必要な場合は、multiclusterhub リソースから、以下の 2 つの暗号 (ECDHE-ECDSA-CHACHA20-POLY1305 および ECDHE-RSA-CHACHA20-POLY1305) を削除します。

1.1.3.1. エラータ 2.2.4

  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。

1.1.3.2. エラータ 2.2.3

  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。

1.1.3.3. エラータ 2.2.2

  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。

1.1.3.4. エラータ 2.2.1

  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。

1.1.4. 非推奨と削除

製品の一部が非推奨またはマルチクラスターエンジン Operator から削除されるタイミングを確認します。推奨アクション および詳細にある、代わりのアクションを検討してください。これについては、現在のリリースおよび、1 つ前のリリースと 2 つ前のリリースの表に記載されています。

1.1.4.1. API の非推奨と削除

マルチクラスターエンジン Operator は、Kubernetes の API 非推奨ガイドラインに従います。そのポリシーに関する詳細は、Kubernetes の非推奨ポリシー を参照してください。マルチクラスターエンジン Operator API は、以下のタイムライン外でのみ非推奨または削除されます。

  • V1 API はすべて、12 ヶ月間または リリース 3 回分 (いずれか長い方) の期間は一般公開され、サポート対象となります。V1 API は削除されませんが、この期間を過ぎると非推奨になる可能性があります。
  • Beta 版 API はすべて、9ヶ月間またはリリース 3 回分 (いずれか長い方) の期間は一般公開されます。Beta 版 API は、この期間を過ぎても削除されません。
  • Alpha 版 API はサポートの必要はありませんが、ユーザーにとってメリットがある場合には、非推奨または削除予定として記載される場合があります。
1.1.4.1.1. API の非推奨化

製品またはカテゴリー

影響を受けるアイテム

バージョン

推奨されるアクション

詳細およびリンク

1.1.4.1.2. API の削除

製品またはカテゴリー

影響を受けるアイテム

バージョン

推奨されるアクション

詳細およびリンク

1.1.4.2. マルチクラスターエンジン Operator の非推奨化

非推奨 のコンポーネント、機能またはサービスはサポートされますが、使用は推奨されておらず、今後のリリースで廃止される可能性があります。以下の表に記載されている 推奨アクション と詳細の代替アクションについて検討してください。

製品またはカテゴリー

影響を受けるアイテム

バージョン

推奨されるアクション

詳細およびリンク

1.1.4.3. 削除

通常、削除 された項目は、以前のリリースで非推奨となった機能で、製品では利用できなくなっています。削除された機能には、代わりの方法を使用する必要があります。以下の表に記載されている 推奨アクション と詳細の代替アクションについて検討してください。

製品またはカテゴリー

影響を受けるアイテム

バージョン

推奨されるアクション

詳細およびリンク