サポートコンソール開発者トライアルの開始お問い合わせ

検証およびトラブルシューティング

OpenShift Container Platform 4.16

OpenShift Container Platform のインストールの検証とトラブルシューティング

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Container Platform のインストールを検証およびトラブルシューティングする方法を説明します。

第1章 インストールの検証

インストール後に、このドキュメントの手順を実行して OpenShift Container Platform クラスターのステータスを確認できます。

1.1. インストールログの確認

OpenShift Container Platform インストールログでインストールの概要を確認できます。インストールに成功すると、クラスターへのアクセスに必要な情報はログに追加されます。

前提条件

  • インストールホストにアクセスできる。

手順

  • インストールホストのインストールディレクトリーにある .openshift_install.log ログファイルを確認します。 

    $ cat <install_dir>/.openshift_install.log

    出力例

    以下の例で説明されているように、インストールに成功すると、クラスター認証情報はログの末尾に追加されます。 

    ...
time="2020-12-03T09:50:47Z" level=info msg="Install complete!"
time="2020-12-03T09:50:47Z" level=info msg="To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'"
time="2020-12-03T09:50:47Z" level=info msg="Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com"
time="2020-12-03T09:50:47Z" level=info msg="Login to the console with user: \"kubeadmin\", and password: \"password\""
time="2020-12-03T09:50:47Z" level=debug msg="Time elapsed per stage:"
time="2020-12-03T09:50:47Z" level=debug msg="    Infrastructure: 6m45s"
time="2020-12-03T09:50:47Z" level=debug msg="Bootstrap Complete: 11m30s"
time="2020-12-03T09:50:47Z" level=debug msg=" Bootstrap Destroy: 1m5s"
time="2020-12-03T09:50:47Z" level=debug msg=" Cluster Operators: 17m31s"
time="2020-12-03T09:50:47Z" level=info msg="Time elapsed: 37m26s"

1.2. イメージのプルソースの表示

ネットワークに制限のないクラスターの場合は、crictl images など、ノードでコマンドを使用して、プルしたイメージのソースを表示できます。

ただし、非接続インストールでは、プルされたイメージのソースを表示するには、以下の手順のように CRI-O ログを確認して、Trying to access のログエントリーを特定する必要があります。crictl images コマンドなど、イメージプルソースを表示する他の方法では、イメージがミラーリングされた場所からプルされている場合でも、ミラーリングされていないイメージ名を表示します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  • マスターまたはワーカーノードの CRI-O ログを確認します。 

    $  oc adm node-logs <node_name> -u crio

    出力例

    Trying to access ログエントリーは、イメージがプルされる場所を示します。 

    ...
Mar 17 02:52:50 ip-10-0-138-140.ec2.internal crio[1366]: time="2021-08-05 10:33:21.594930907Z" level=info msg="Pulling image: quay.io/openshift-release-dev/ocp-release:4.10.0-ppc64le" id=abcd713b-d0e1-4844-ac1c-474c5b60c07c name=/runtime.v1alpha2.ImageService/PullImage
Mar 17 02:52:50 ip-10-0-138-140.ec2.internal crio[1484]: time="2021-03-17 02:52:50.194341109Z" level=info msg="Trying to access \"li0317gcp1.mirror-registry.qe.gcp.devcluster.openshift.com:5000/ocp/release@sha256:1926eae7cacb9c00f142ec98b00628970e974284b6ddaf9a6a086cb9af7a6c31\""
Mar 17 02:52:50 ip-10-0-138-140.ec2.internal crio[1484]: time="2021-03-17 02:52:50.226788351Z" level=info msg="Trying to access \"li0317gcp1.mirror-registry.qe.gcp.devcluster.openshift.com:5000/ocp/release@sha256:1926eae7cacb9c00f142ec98b00628970e974284b6ddaf9a6a086cb9af7a6c31\""
...

    ログは、前述の例のように、イメージのプルソースを 2 回表示する場合があります。

    ImageContentSourcePolicy オブジェクトに複数のミラーをリスト表示する場合、OpenShift Container Platform はイメージを設定にリスト表示されている順序でプルしようとします。以下に例を示します。 

    Trying to access \"li0317gcp1.mirror-registry.qe.gcp.devcluster.openshift.com:5000/ocp/release@sha256:1926eae7cacb9c00f142ec98b00628970e974284b6ddaf9a6a086cb9af7a6c31\"
Trying to access \"li0317gcp2.mirror-registry.qe.gcp.devcluster.openshift.com:5000/ocp/release@sha256:1926eae7cacb9c00f142ec98b00628970e974284b6ddaf9a6a086cb9af7a6c31\"

1.3. クラスターのバージョン、ステータス、および更新の詳細の取得

oc get clusterversion コマンドを実行して、クラスターのバージョンおよびステータスを表示できます。インストールが進行中であることがステータスに示されている場合は、Operator のステータスで詳細を確認できます。

現在の更新チャネルをリスト表示し、利用可能なクラスターの更新を確認することもできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. クラスターのバージョンと全体のステータスを取得します。 

    $ oc get clusterversion

    出力例

    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.6.4     True        False         6m25s   Cluster version is 4.6.4

    この出力例は、クラスターが正常にインストールされていることを示しています。

  2. インストールが進行中であることがクラスターのステータスに示されている場合は、Operator のステータスでより詳細な進捗情報を確認できます。 

    $ oc get clusteroperators.config.openshift.io

  3. クラスター仕様、更新の可用性、および更新履歴の詳細な要約を取得します。 

    $ oc describe clusterversion

  4. 現在の更新チャネルをリスト表示します。 

    $ oc get clusterversion -o jsonpath='{.items[0].spec}{"\n"}'

    出力例

    {"channel":"stable-4.6","clusterID":"245539c1-72a3-41aa-9cec-72ed8cf25c5c"}

  5. 利用可能なクラスターの更新を確認します。 

    $ oc adm upgrade

    出力例

    Cluster version is 4.6.4

Updates:

VERSION IMAGE
4.6.6   quay.io/openshift-release-dev/ocp-release@sha256:c7e8f18e8116356701bd23ae3a23fb9892dd5ea66c8300662ef30563d7104f39

関連情報

1.4. クラスターが短期認証情報を使用していることを確認

クラスター内の Cloud Credential Operator (CCO) 設定やその他の値で、クラスターが個々のコンポーネントに対して短期的なセキュリティー認証情報を使用していることを確認できます。

前提条件

  • Cloud Credential Operator ユーティリティー (ccoctl) を使用して OpenShift Container Platform クラスターをデプロイし、短期認証情報を実装した。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  • 次のコマンドを実行して、CCO が手動モードで動作するように設定されていることを確認します。 

    $ oc get cloudcredentials cluster \
  -o=jsonpath={.spec.credentialsMode}

    次の出力は、CCO が手動モードで動作していることを示しています。

    出力例

    Manual

  • 次のコマンドを実行して、クラスターに root 認証情報がないことを確認します。 

    $ oc get secrets \
  -n kube-system <secret_name>

    <secret_name> は、クラウドプロバイダーのルートシークレットの名前です。

    プラットフォームシークレット名

    Amazon Web Services (AWS)

    aws-creds

    Microsoft Azure

    azure-credentials

    Google Cloud Platform (GCP)

    gcp-credentials

    エラーは、ルートシークレットがクラスター上に存在しないことを確認します。

    AWS クラスターの出力例

    Error from server (NotFound): secrets "aws-creds" not found

  • 次のコマンドを実行して、コンポーネントが個々のコンポーネントに対して短期セキュリティー認証情報を使用していることを確認します。 

    $ oc get authentication cluster \
  -o jsonpath \
  --template='{ .spec.serviceAccountIssuer }'

    このコマンドは、クラスター Authentication オブジェクトの .spec.serviceAccountIssuer パラメーターの値を表示します。クラウドプロバイダーに関連付けられた URL の出力は、クラスターがクラスターの外部から作成および管理される短期認証情報を使用して手動モードを使用していることを示します。

  • Azure クラスター: 次のコマンドを実行して、コンポーネントがシークレットマニフェストで指定された Azure クライアント ID を想定していることを確認します。 

    $ oc get secrets \
  -n openshift-image-registry installer-cloud-credentials \
  -o jsonpath='{.data}'

    出力に azure_client_id フィールドと azure_federated_token_file フィールドが含まれている場合は、コンポーネントが Azure クライアント ID を想定しています。

  • Azure クラスター: 次のコマンドを実行して、pod identity webhook を実行していることを確認します。 

    $ oc get pods \
  -n openshift-cloud-credential-operator

    出力例

    NAME                                         READY   STATUS    RESTARTS   AGE
cloud-credential-operator-59cf744f78-r8pbq   2/2     Running   2          71m
pod-identity-webhook-548f977b4c-859lz        1/1     Running   1          70m

1.5. CLI を使用したクラスターノードのステータスのクエリー

インストール後にクラスターノードのステータスを確認できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. クラスターノードのステータスをリスト表示します。出力に、予想されるすべてのコントロールプレーンおよびコンピュートノードのリストが表示され、各ノードのステータスが Ready であることを確認します。 

    $ oc get nodes

    出力例

    NAME                          STATUS   ROLES    AGE   VERSION
compute-1.example.com         Ready    worker   33m   v1.29.4
control-plane-1.example.com   Ready    master   41m   v1.29.4
control-plane-2.example.com   Ready    master   45m   v1.29.4
compute-2.example.com         Ready    worker   38m   v1.29.4
compute-3.example.com         Ready    worker   33m   v1.29.4
control-plane-3.example.com   Ready    master   41m   v1.29.4

  2. 各クラスターノードの CPU およびメモリーリソースの可用性を確認します。 

    $ oc adm top nodes

    出力例

    NAME                          CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
compute-1.example.com         128m         8%     1132Mi          16%
control-plane-1.example.com   801m         22%    3471Mi          23%
control-plane-2.example.com   1718m        49%    6085Mi          40%
compute-2.example.com         935m         62%    5178Mi          75%
compute-3.example.com         111m         7%     1131Mi          16%
control-plane-3.example.com   942m         26%    4100Mi          27%

関連情報

1.6. OpenShift Container Platform Web コンソールでのクラスターステータスの確認

以下の情報は、OpenShift Container Platform Web コンソールの Overview ページで確認できます。

  • クラスターの一般的なステータス
  • コントロールプレーン、クラスター Operator、およびストレージのステータス
  • CPU、メモリー、ファイルシステム、ネットワーク転送、および Pod の可用性
  • クラスターの API アドレス、クラスター ID、およびプロバイダーの名前
  • クラスターのバージョン情報
  • 現在の更新チャネルの詳細や利用可能な更新を含むクラスター更新のステータス
  • ノード、Pod、ストレージクラスの詳細を示すクラスターインベントリー、および永続ボリューム要求 (PVC) 情報
  • 継続中のクラスターのアクティビティーおよび最近のイベントのリスト

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  • Administrator パースペクティブで、Home → Overview に移動します。

1.7. Red Hat OpenShift Cluster Manager のクラスターステータスの確認

OpenShift Container Platform Web コンソールから、OpenShift Cluster Manager でクラスターのステータスに関する詳細情報を確認できます。

前提条件

  • OpenShift Cluster Manager にログインしている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. OpenShift Cluster Manager の Cluster List リストに移動し、OpenShift Container Platform クラスターを見つけます。
  2. クラスターの Overview タブをクリックします。

  3. クラスターに関する以下の情報を確認します。

    • vCPU およびメモリー可用性およびリソースの使用状況
    • クラスター ID、ステータス、タイプ、リージョン、およびプロバイダー名
    • ノード数 (ノードタイプ別)
    • クラスターバージョンの詳細、クラスターの作成日、およびクラスター所有者の名前
    • クラスターのライフサイクルサポートのステータス

    • サービスレベルアグリーメント (SLA) のステータス、サブスクリプションユニットタイプ、クラスターの実稼働ステータス、サブスクリプションの義務、サービスレベルなどのサブスクリプション情報

      ヒント

      クラスターの履歴を表示するには、Cluster history タブをクリックします。

  4. Monitoring ページに移動し、以下の情報を確認します。

    • 検出されたすべての問題のリスト
    • 実行されるアラートのリスト
    • クラスター Operator のステータスおよびバージョン
    • クラスターリソースの使用状況

  5. オプション: Overview メニューに移動して、Red Hat Insights が収集するクラスターに関する情報を表示できます。このメニューから、次の情報を表示できます。

    • リスクのレベルで分類された、クラスターがさらされる可能性のある問題
    • カテゴリー別のヘルスチェックのステータス

関連情報

1.8. クラスターリソースの可用性および使用状況の確認

OpenShift Container Platform は、クラスターコンポーネントの状態を理解するのに役立つ包括的なモニタリングダッシュボードのセットを提供します。

Administrator パースペクティブでは、以下を含む OpenShift Container Platform のコアコンポーネントのダッシュボードにアクセスできます。

  • etcd
  • Kubernetes コンピュートリソース
  • Kubernetes ネットワークリソース
  • Prometheus
  • クラスターおよびノードのパフォーマンスに関連するダッシュボード

図1.1 コンピュートリソースダッシュボードの例

ダッシュボードのコンピュートリソースのモニタリング

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Observe → Dashboards に移動します。
  2. Dashboard リストでダッシュボードを選択します。etcd ダッシュボードなどの一部のダッシュボードは、選択時に追加のサブメニューを生成します。

  3. 必要に応じて、Time Range リストでグラフの時間範囲を選択します。

    • 事前定義済みの期間を選択します。

    • 時間範囲 リストで カスタムの時間範囲 を選択して、カスタムの時間範囲を設定します。

      1. From および To の日付と時間を入力または選択します。
      2. Save をクリックして、カスタムの時間範囲を保存します。
  4. オプション: Refresh Interval を選択します。
  5. ダッシュボードの各グラフにカーソルを合わせて、特定の項目に関する詳細情報を表示します。

関連情報

  • OpenShift Container Platform モニタリングスタックの詳細は、Monitoring Overviewを参照してください。

1.9. 実行されるアラートのリスト表示

アラートは、定義された条件のセットが OpenShift Container Platform クラスターで true の場合に通知を提供します。OpenShift Container Platform Web コンソールでアラート UI を使用して、クラスターで実行されているアラートを確認できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. Administrator パースペクティブで、Observe → Alerting → Alerts ページに移動します。
  2. Severity、State、および Source が含まれる、実行されているアラートを確認します。
  3. Alert Details ページで詳細情報を表示するためにアラートを選択します。

関連情報

  • OpenShift Container Platform のアラートの詳細は、アラートの管理 を参照してください。

1.10. 次のステップ

第2章 インストールの問題のトラブルシューティング

失敗した OpenShift Container Platform インストールのトラブルシューティングを支援するために、ブートストラップおよびコントロールプレーンマシンからログを収集できます。インストールプログラムからデバッグ情報を取得することもできます。ログとデバッグ情報を使用しても問題を解決できない場合は、インストールの問題が発生した場所の特定 を参照して、コンポーネント固有のトラブルシューティングを確認してください。

注記

OpenShift Container Platform のインストールが失敗し、デバッグ出力またはログにネットワークタイムアウトまたはその他の接続エラーが含まれている場合は、ファイアウォールの設定 に関するガイドラインを確認してください。ファイアウォールとロードバランサーからログを収集すると、ネットワーク関連のエラーを診断するのに役立ちます。

2.1. 前提条件

  • OpenShift Container Platform クラスターのインストールを試みたが、インストールに失敗している。

2.2. 失敗したインストールのログの収集

SSH キーをインストールプログラムに指定している場合は、失敗したインストールに関するデータを収集できます。

注記

実行中のクラスターからログを収集する場合とは異なるコマンドを使用して失敗したインストールに関するログを収集します。実行中のクラスターからログを収集する必要がある場合は、oc adm must-gather コマンドを使用します。

前提条件

  • OpenShift Container Platform のインストールがブートストラッププロセスの終了前に失敗している。ブートストラップノードは実行中で、SSH でアクセスできる。
  • ssh-agent プロセスはコンピューター上でアクティブであり、ssh-agent プロセスとインストールプログラムの両方に同じ SSH キーを提供している。
  • 独自にプロビジョニングしたインフラストラクチャーにクラスターのインストールを試行した場合は、ブートストラップおよびコントロールプレーンノードの完全修飾ドメイン名がある。

手順

  1. ブートストラップおよびコントロールプレーンマシンからインストールログを収集するために必要なコマンドを生成します。

    • installer-provisioned infrastructure を使用する場合は、インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。 

      $ ./openshift-install gather bootstrap --dir <installation_directory> 1
      1
      installation_directory は、./openshift-install create cluster を実行した際に指定したディレクトリーです。このディレクトリーには、インストールプログラムが作成する OpenShift Container Platform 定義ファイルが含まれます。

      installer-provisioned infrastructure の場合、インストールプログラムは、ホスト名または IP アドレスを指定しなくてもよいようにクラスターに関する情報を保存します。

    • 各自でプロビジョニングしたインフラストラクチャーを使用した場合は、インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。 

      $ ./openshift-install gather bootstrap --dir <installation_directory> \ 1
    --bootstrap <bootstrap_address> \ 2
    --master <master_1_address> \ 3
    --master <master_2_address> \ 4
    --master <master_3_address> 5
      1
      installation_directory には、./openshift-install create cluster を実行した際に指定したのと同じディレクトリーを指定します。このディレクトリーには、インストールプログラムが作成する OpenShift Container Platform 定義ファイルが含まれます。
      2
      <bootstrap_address> は、クラスターのブートストラップマシンの完全修飾ドメイン名または IP アドレスです。
      3 4 5
      クラスター内のそれぞれのコントロールプレーン (またはマスター) マシンで、<master_*_address> をその完全修飾ドメイン名または IP アドレスに置き換えます。
      注記

      デフォルトクラスターには 3 つのコントロールプレーンマシンが含まれます。クラスターが使用する数にかかわらず、表示されるようにすべてのコントロールプレーンマシンをリスト表示します。

    出力例

    INFO Pulling debug logs from the bootstrap machine
INFO Bootstrap gather logs captured here "<installation_directory>/log-bundle-<timestamp>.tar.gz"

    インストールの失敗に関する Red Hat サポートケースを作成する場合は、圧縮したログをケースに含めるようにしてください。

2.3. ホストへの SSH アクセスによるログの手動収集

must-gather または自動化された収集方法が機能しない場合にログを手動で収集します。

重要

デフォルトでは、OpenShift Container Platform ノードへの SSH アクセスは、Red Hat OpenStack Platform (RHOSP) ベースのインストールでは無効になっています。

前提条件

  • ホストへの SSH アクセスがある。

手順

  1. 以下を実行し、journalctl コマンドを使用してブートストラップホストから bootkube.service サービスログを収集します。 

    $ journalctl -b -f -u bootkube.service

  2. podman ログを使用して、ブートストラップホストのコンテナーログを収集します。これは、ホストからすべてのコンテナーログを取得するためにループで表示されます。 

    $ for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done

  3. または、以下を実行し、tail コマンドを使用してホストのコンテナーログを収集します。 

    # tail -f /var/lib/containers/storage/overlay-containers/*/userdata/ctr.log

  4. 以下を実行し、journalctl コマンドを使用して kubelet.service および crio.service サービスログをマスターホストおよびワーカーホストから収集します。 

    $ journalctl -b -f -u kubelet.service -u crio.service

  5. 以下を実行し、tail コマンドを使用してマスターホストおよびワーカーホストのコンテナーログを収集します。 

    $ sudo tail -f /var/log/containers/*

2.4. ホストへの SSH アクセスを使用しないログの手動収集

must-gather または自動化された収集方法が機能しない場合にログを手動で収集します。

ノードへの SSH アクセスがない場合は、システムジャーナルにアクセスし、ホストで生じていることを調査できます。

前提条件

  • OpenShift Container Platform のインストールが完了している。
  • API サービスが機能している。
  • システム管理者権限がある。

手順

  1. 以下を実行し、/var/log の下にある journald ユニットログにアクセスします。 

    $ oc adm node-logs --role=master -u kubelet

  2. 以下を実行し、/var/log の下にあるホストファイルのパスにアクセスします。 

    $ oc adm node-logs --role=master --path=openshift-apiserver

2.5. インストールプログラムからのデバッグ情報の取得

以下のアクションのいずれかを使用して、インストールプログラムからデバッグ情報を取得できます。

  • 非表示の .openshift_install.log ファイルで過去のインストールからのデバッグ情報を確認します。たとえば、以下を入力します。 

    $ cat ~/<installation_directory>/.openshift_install.log 1
    1
    installation_directory には、./openshift-install create cluster を実行した際に指定したのと同じディレクトリーを指定します。

  • インストールプログラムが含まれるディレクトリーに切り替え、--log-level=debug でこれを再実行します。 

    $ ./openshift-install create cluster --dir <installation_directory> --log-level debug 1
    1
    installation_directory には、./openshift-install create cluster を実行した際に指定したのと同じディレクトリーを指定します。

2.6. OpenShift Container Platform クラスターの再インストール

OpenShift Container Platform のインストールに失敗して問題をデバッグおよび解決できない場合は、新しい OpenShift Container Platform クラスターのインストールを検討してください。完全に消去してから、インストールプロセスを開始しなおしてください。user-provisioned infrastructure (UPI) をインストールする場合は、クラスターを手動で破棄し、関連するすべてのリソースを削除する必要があります。次の手順は、installer-provisioned infrastructure (IPI) のインストール用です。

手順

  1. クラスターを破棄し、インストールディレクトリー内の非表示のインストーラー状態ファイルなども含めて、クラスターに関連付けられているすべてのリソースを削除します。 

    $ ./openshift-install destroy cluster --dir <installation_directory> 1
    1
    installation_directory は、./openshift-install create cluster を実行した際に指定したディレクトリーです。このディレクトリーには、インストールプログラムが作成する OpenShift Container Platform 定義ファイルが含まれます。

  2. クラスターを再インストールする前に、インストールディレクトリーを削除してください。 

    $ rm -rf <installation_directory>
  3. OpenShift Container Platform クラスターの新規インストール手順に従います。

関連情報

Legal Notice

Copyright © 2024 Red Hat, Inc.

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.