機械翻訳について

2 Kubernetesクラスタの作成

この章では、Platform CLI (olcnectl)を使用してKubernetesクラスタを作成する方法について説明します。 この章では、Oracle Cloud Native Environmentソフトウェア・パッケージをノードにインストールし、クラスタで使用するように構成し、「スタート・ガイド」で説明するようにKubernetesモジュールをインストールする環境を作成していることを前提としています。

Kubernetesクラスタを作成する高レベルのステップは次のとおりです。

• クラスタに関する情報を指定するKubernetesモジュールを作成します。

• Kubernetesモジュールを検証して、Kubernetesをノードにインストールできることを確認します。

• Kubernetesモジュールをインストールして、Kubernetesパッケージをノードにインストールし、クラスタを作成します。

olcnectlコマンドを使用して、これらのステップを実行します。 olcnectlコマンドの構文の詳細は、「プラットフォーム・コマンドライン・インタフェース」を参照してください。

ヒント:

構成ファイルを使用してモジュールを作成することもできます。 構成ファイルは、デプロイする環境およびモジュールに関する情報を含むYAMLファイルです。 構成ファイルを使用すると、olcnectlコマンドで指定する必要がある情報が削減されます。 構成ファイルの作成および使用の詳細は、「プラットフォーム・コマンドライン・インタフェース」を参照してください。

Kubernetesネットワークの設定

Kubernetesクラスタでは、次のポッド・ネットワーキング・テクノロジを使用できます:

• Flannel。 Kubernetesモジュールを作成する場合のデフォルトのネットワーク・オプション。
• Calico。 Calicoは、Kubernetesモジュールの作成時に設定することも、独自の構成を使用してCalicoモジュールとして設定することもできます。
• Multus。 Multusは、Kubernetesモジュールのインストール後にMultusモジュールとして設定できます。 Multusは、FlannelまたはCalicoの上にモジュールとしてインストールされます。

Flannelネットワーキング

Kubernetesモジュールを作成する場合、Flannelはデフォルトのネットワーク・オプションです。 Flannelを使用するコマンド・オプションを設定する必要はありません。既定でインストールされます。

Calico Networking

Calicoは、オプションのポッド・ネットワーキング・テクノロジです。 Calicoの詳細は、「アップストリームのドキュメント」を参照してください。

前提条件

この項では、Calicoの設定に必要な前提条件について説明します。

firewalldサービスの無効化

Calicoを使用するには、各Kubernetesノードでfirewalldサービスを無効にする必要があります。 firewalldサービスを無効にするには、次のように入力します:

sudo systemctl stop firewalld.service
sudo systemctl disable firewalld.service

プロキシ構成の更新

環境でプロキシ・サーバーを使用している場合は、CRI-Oプロキシ構成ファイルを編集し、KubernetesサービスIP (デフォルトは10.96.0.1)をNO_PROXY変数に追加します(たとえば、各Kubernetesノードで/etc/systemd/system/crio.service.d/proxy.confファイルを編集します):

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:3128"
Environment="HTTPS_PROXY=https://proxy.example.com:3128"
Environment="NO_PROXY=mydomain.example.com,10.96.0.1"

構成ファイルをリロードし、「クリオ」サービスを再起動します:

sudo systemctl daemon-reload
sudo systemctl restart crio.service

ノート:

olcnectl provisionコマンドを使用してクイック・インストールを実行する場合は、このステップを実行する必要はありません。 これは、そのインストール・メソッドを使用してプロキシ情報を指定するときに自動的に設定されます。

Calico構成ファイルの作成

Calicoモジュールをインストールする場合は、Calico構成ファイルを作成して要件に合せてCalicoを構成する必要があります。 このファイルには、operator.tigera.io/v1/Installationのspec部分が含まれている必要があります。 このファイルは、オペレータ・ノードで使用できるはずです。

Calico構成ファイルの詳細は、「アップストリームのドキュメント」を参照してください。

Calico構成ファイルの例:

installation:
  cni:
    type: Calico
  calicoNetwork:
    bgp: Disabled
    ipPools:
    - cidr: 198.51.100.0/24
      encapsulation: VXLAN
  registry: container-registry.oracle.com
  imagePath: olcne

Kubernetesモジュールを使用したCalicoのデプロイ

Calicoのデフォルト構成を使用する場合は、olcnectl module create --module kubernetesコマンドの--pod-network calicoオプションを使用してKubernetesモジュールを作成するときに、このオプションとして設定できます。 これにより、Flannelではなくネットワーク・オプションとしてCalicoが設定されます。

このインストール・メソッドでは、Calicoに最小デフォルト構成が使用されます。 Calicoを構成する場合は、Calicoモジュールをインストールする必要があります。

Calicoモジュールのデプロイ

オプションで、Calicoモジュールをインストールできます。 これにより、Calicoに独自の構成ファイルを使用できます。

このメソッドを使用するには、--pod-network noneオプションを使用してKubernetesモジュールを作成する必要があります。 このオプションは、Kubernetesクラスタ内のポッドのネットワーキングを設定しません。 次に、Calicoモジュールをインストールしてポッド・ネットワーキングを構成します。

Calicoモジュールの作成に使用する構文については、「プラットフォーム・コマンドライン・インタフェース」のolcnectl module createコマンドのcalicoオプションを参照してください。

Calicoモジュールをデプロイするには:

1. olcnectl module create --module kubernetesコマンドの--pod-network noneオプションを使用して、Kubernetesモジュールを作成してインストールします。 このオプションは、Kubernetesクラスタ内のポッドのネットワーキングを設定しません。 この例のKubernetesモジュールの名前は、myclusterです。

   ノート:

   --pod-network noneオプションを指定してKubernetesモジュールをインストールすると、Calicoモジュールをインストールするまで、すべてのkube-systemポッドがpendingとしてマークされます。 Calicoがインストールされると、これらのkube-systemポッドはrunningとしてマークされます。

2. Calicoモジュールを作成し、--calico-kubernetes-moduleオプションを使用してmyclusterという名前のKubernetesモジュールに関連付けます。 この例では、Calicoモジュールの名前はmycalicoです。

   olcnectl module create \
   --environment-name myenvironment \
   --module calico \
   --name mycalico \
   --calico-kubernetes-module mycluster \
   --calico-installation-config calico-config.yaml

   --moduleオプションは、モジュール・タイプを作成(calico)に設定します。 Calicoモジュールの名前は、--nameオプションを使用して定義します。この場合、mycalicoです。

   --calico-kubernetes-moduleオプションは、Kubernetesモジュールの名前を設定します。

   --calico-installation-configオプションは、Calico構成ファイルのロケーションを設定します。 このファイルは、指定されたパスのオペレータ・ノードで使用可能である必要があります。 この構成ファイルの作成については、「Calico構成ファイルの作成」を参照してください。

   モジュールの追加時に必要なすべてのオプションを含めない場合は、指定するよう求められます。

3. olcnectl module validateコマンドを使用して、ノードにCalicoモジュールをデプロイできることを確認します。 たとえば:

   olcnectl module validate \
   --environment-name myenvironment \
   --name mycalico

4. olcnectl module installコマンドを使用して、Calicoモジュールをインストールします。 たとえば:

   olcnectl module install \
   --environment-name myenvironment \
   --name mycalico

   Calicoモジュールは、Kubernetesクラスタにデプロイされます。

Multusネットワーキング

Multusは、FlannelまたはCalicoのネットワーク・ブリッジを作成するオプションのポッド・ネットワーキング・テクノロジです。 Multusの詳細については、「アップストリームのドキュメント」を参照してください。

Multusをモジュールとしてインストールして、FlannelまたはCalicoへのネットワーク・ブリッジを作成できます。 デフォルトの構成を使用してMultusモジュールを作成することも、独自の要件にあわせて構成ファイルを記述することもできます。

前提条件

このセクションでは、Multusを設定するために必要な前提条件について説明します。

プロキシ構成の更新

環境でプロキシ・サーバーを使用している場合は、CRI-Oプロキシ構成ファイルを編集し、KubernetesサービスIP (デフォルトは10.96.0.1)をNO_PROXY変数に追加します(たとえば、各Kubernetesノードで/etc/systemd/system/crio.service.d/proxy.confファイルを編集します):

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:3128"
Environment="HTTPS_PROXY=https://proxy.example.com:3128"
Environment="NO_PROXY=mydomain.example.com,10.96.0.1"

構成ファイルをリロードし、「クリオ」サービスを再起動します:

sudo systemctl daemon-reload
sudo systemctl restart crio.service

ノート:

olcnectl provisionコマンドを使用してクイック・インストールを実行する場合は、このステップを実行する必要はありません。 これは、そのインストール・メソッドを使用してプロキシ情報を指定するときに自動的に設定されます。

Multus構成ファイルの作成

Multusモジュールをインストールする場合は、要件にあわせてネットワーキングを設定するための構成ファイルを作成することをお薦めします。 本番環境では、Multusのデフォルト構成はお薦めしません。

構成ファイルには、Kubernetes NetworkAttachmentDefinitionのカスタム・リソース定義が0個以上含まれている必要があります。 これらの定義によって、ネットワーク接続、つまりポッドのセカンダリ・インタフェースが設定されます。 このファイルは、オペレータ・ノードで使用できるはずです。

Multus構成ファイルの作成については、「アップストリームのドキュメント」を参照してください。

Multus構成ファイルの例は次のとおりです:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: bridge-conf
spec:
  config: '{
      "cniVersion": "0.3.1",
      "type": "bridge",
      "bridge": "mybr0",
      "ipam": {
          "type": "host-local",
          "subnet": "192.168.12.0/24",
          "rangeStart": "192.168.12.10",
          "rangeEnd": "192.168.12.200"
      }
    }'

Multusモジュールのデプロイ

このセクションでは、Multusモジュールを取り付ける方法について説明します。 Multusをインストールする前に、Kubernetesモジュールをインストールしておく必要があります。 Kubernetesモジュールは、Kubernetesポッド・ネットワーキング・テクノロジとしてFlannelまたはCalicoのいずれかを使用できます。

Multusモジュールの作成に使用する構文については、「プラットフォーム・コマンドライン・インタフェース」のolcnectl module createコマンドのmultusオプションを参照してください。

Multusモジュールをデプロイするには:

1. FlannelまたはCalicoを使用して、Kubernetesモジュールを作成してインストールします。 この例のKubernetesモジュールの名前は、myclusterです。

2. Multusモジュールを作成し、--multus-kubernetes-moduleオプションを使用してmyclusterという名前のKubernetesモジュールに関連付けます。 この例では、Multusモジュールの名前はmymultusです。

   olcnectl module create \
   --environment-name myenvironment \
   --module multus \
   --name mymultus \
   --multus-kubernetes-module mycluster \
   --multus-config multus-config.conf

   --moduleオプションは、モジュール・タイプを作成(multus)に設定します。 --nameオプション(この場合はmymultus)を使用して、Multusモジュールの名前を定義します。

   --multus-kubernetes-moduleオプションは、Kubernetesモジュールの名前を設定します。

   --multus-configオプションは、Multus構成ファイルのロケーションを設定します。 このファイルは、指定されたパスのオペレータ・ノードで使用可能である必要があります。 この構成ファイルの作成については、「Multus構成ファイルの作成」を参照してください。

   モジュールの追加時に必要なすべてのオプションを含めない場合は、指定するよう求められます。

3. olcnectl module validateコマンドを使用して、ノードにデプロイできるMultusモジュールを検証します。 たとえば:

   olcnectl module validate \
   --environment-name myenvironment \
   --name mymultus

4. olcnectl module installコマンドを使用して、Multusモジュールをインストールします。 たとえば:

   olcnectl module install \
   --environment-name myenvironment \
   --name mymultus

   Multusモジュールは、Kubernetesクラスタにデプロイされます。

Kubernetesモジュールの作成

Kubernetesモジュールは、次のクラスタを作成するように設定できます。

• 外部ロード・バランサを備えた高可用性(HA)クラスタ

• 内部ロード・バランサを備えたHAクラスタ

• 単一のコントロール・プレーン・ノードを備えたクラスタ(非高可用性クラスタ)

HAクラスタを作成するには、少なくとも3つのコントロール・プレーン・ノードと2つのワーカー・ノードが必要です。

外部ロード・バランサの設定、またはPlatform CLIによってインストールされた内部ロード・バランサを使用するためのコントロール・プレーン・ノードの準備の詳細は、スタート・ガイドを参照してください。

HAクラスタ内のコントロール・プレーンのノードでは、多数の追加ポートを開く必要があります。 HAクラスタに必要なポートを開く方法は、スタート・ガイドを参照してください。

olcne module createコマンドを使用して、Kubernetesモジュールを作成します。 このコマンドの使用時に必要なすべてのオプションが含まれていない場合は、そのオプションを指定するように求められます。 Kubernetesモジュールで使用可能なオプションの完全なリストは、プラットフォーム・コマンドライン・インタフェースを参照してください。

外部ロード・バランサを使用した高可用性クラスタの作成

この項では、外部ロード・バランサを使用してHAクラスタを作成するために、Kubernetesモジュールを作成する方法について説明します。

次の例では、独自のロード・バランサを使用してHAクラスタを作成します。このロード・バランサは、ホストlb.example.comで使用可能になっていて、ポート6443で実行しているものです。

olcnectl module create \
--environment-name myenvironment \
--module kubernetes \
--name mycluster \
--container-registry container-registry.oracle.com/olcne \
--load-balancer lb.example.com:6443 \
--control-plane-nodes control1.example.com:8090,control2.example.com:8090,control3.example.com:8090 \
--worker-nodes worker1.example.com:8090,worker2.example.com:8090,worker3.example.com:8090,worker4.example.com:8090 \
--selinux enforcing \
--restrict-service-externalip-ca-cert /etc/olcne/certificates/restrict_external_ip/ca.cert \
--restrict-service-externalip-tls-cert /etc/olcne/certificates/restrict_external_ip/node.cert \
--restrict-service-externalip-tls-key /etc/olcne/certificates/restrict_external_ip/node.key

--environment-nameは、Kubernetesモジュールを作成する環境の名前を設定します。 この例では、myenvironmentに設定します。

--moduleオプションは、作成するモジュールのタイプを設定します。 Kubernetesモジュールを作成するには、これをkubernetesに設定する必要があります。

--nameオプションは、Kubernetesモジュールの識別に使用する名前を設定します。 この例では、myclusterに設定します。

--container-registryオプションでは、Kubernetesイメージを取得するコンテナ・レジストリを指定します。 この例では、Oracle Container Registryを使用しますが、Oracle Container Registryミラー、またはOracle Container RegistryからKubernetesイメージをミラー化してあるローカル・レジストリを使用することもできます。 Oracle Container Registryミラーの使用またはローカル・レジストリの作成の詳細は、スタート・ガイドを参照してください。

ただし、Kubernetesモジュールの更新またはアップグレード中に、新しいデフォルトのコンテナ・レジストリ値を設定できます。

--load-balancerオプションは、外部ロード・バランサのホスト名とポートを設定します。 この例では、lb.example.com:6443に設定します。

--control-plane-nodesオプションには、クラスタに含めるコントロール・プレーン・ノードのホスト名またはIPアドレスのカンマ区切りリストと、プラットフォーム・エージェントが使用可能なポート番号が含まれます。 デフォルトのポート番号は8090です。

ノート:

単一のコントロール・プレーン・ノードを備えた外部ロード・バランサを使用するクラスタを作成できます。 ただし、HAおよびフェイルオーバー機能は、クラスタ内の少なくとも3つのコントロール・プレーン・ノードに到達するまで使用できません。 コントロール・プレーン・ノードの数を増やすには、クラスタをスケール・アップします。 クラスタのスケール・アップの詳細は、「Kubernetesクラスタのスケール・アップ」を参照してください。

--worker-nodesオプションには、クラスタに含めるワーカー・ノードのホスト名またはIPアドレスのカンマ区切りリストと、Platform Agentを使用できるポート番号が含まれます。 ワーカー・ノードがNATゲートウェイの背後にある場合は、ノードのパブリックIPアドレスを使用します。 NATゲートウェイの背後にあるワーカー・ノードのインタフェースには、Kubernetesクラスタが到達可能な/32サブネット・マスクを使用するパブリックIPアドレスが必要です。 /32サブネットは、KubernetesクラスタからのすべてのトラフィックがこのパブリックIPアドレスを通過するように、サブネットを1つのIPアドレスに制限します(NATの構成の詳細は、スタート・ガイド参照)。 デフォルトのポート番号は8090です。

コントロール・プレーン・ノードおよびワーカー・ノードでSELinuxがenforcingモード(オペレーティング・システムのデフォルトおよび推奨モード)に設定されている場合、Kubernetesモジュールの作成時にも--selinux enforcingオプションを使用する必要があります。

externalip-validation-webhook-service Kubernetesサービスの証明書のロケーションも含める必要があります。 これらの証明書はオペレータ・ノードに配置する必要があります。 --restrict-service-externalip-ca-certオプションは、CA証明書のロケーションを設定します。 --restrict-service-externalip-tls-certにより、ノード証明書のロケーションが設定されます。 --restrict-service-externalip-tls-keyオプションは、ノード・キーのロケーションを設定します。 これらの証明書の設定の詳細は、「スタート・ガイド」を参照してください。

オプションで、--restrict-service-externalip-cidrsオプションを使用して、Kubernetesサービスがアクセスできる外部IPアドレスを設定できます。 たとえば:

--restrict-service-externalip-cidrs 192.0.2.0/24,198.51.100.0/24

この例では、許可されるIP範囲は192.0.2.0/24および198.51.100.0/24 CIDRブロック内です。

デフォルトのポッド・ネットワーキングでは、Flannelが使用されます。 オプションで、ポッド・ネットワーキング・テクノロジをCalicoまたはnoneに設定できます。 --pod-networkオプションを使用してポッド・ネットワーキングを設定します。 --pod-network calicoを使用すると、CalicoがFlannelではなくポッドのCNIに設定されます。 --pod-network noneを使用すると、CNIは設定されません。これにより、Calicoモジュールを使用して、ポッド・ネットワーキングの要件を満たす構成ファイルでCalicoをインストールできます。 ポッド・ネットワーキング・オプションの詳細は、「Kubernetesネットワークの設定」を参照してください。

必要に応じて、Kubernetesデータ・プレーン(Kubernetesで実行されているポッドで使用されるインタフェース)に使用するネットワーク・インタフェースを設定できます。 デフォルトでは、プラットフォーム・エージェントで使用されるインタフェース(--control-plane-nodesおよび--worker-nodesオプションで設定)は、Kubernetesコントロール・プレーン・ノードとデータ・プレーンの両方に使用されます。 データ・プレーンに使用する別のネットワーク・インタフェースを指定する場合は、--pod-network-ifaceオプションを指定します。 たとえば、--pod-network-iface ens1です。 これにより、Platform Agentで使用されるネットワーク・インタフェースを使用するコントロール・プレーン・ノードと、別のネットワーク・インタフェース(この例ではens1)を使用するデータ・プレーンが作成されます。

ノート:

regex式を--pod-network-ifaceオプションとともに使用することもできます。 たとえば:

--pod-network-iface "ens[1-5]|eth5"

regexを使用してインタフェース名を設定する場合、カーネルによって返される最初に一致するインタフェースが使用されます。

内部ロード・バランサを使用した高可用性クラスタの作成

この項では、Kubernetesモジュールを作成し、コントロール・プレーン・ノードでPlatform CLIによってインストールされた内部ロード・バランサを使用してHAクラスタを作成する方法を示します。

この例では、Platform CLIによってインストールされた内部ロード・バランサを使用してHAクラスタを作成します。

olcnectl module create \
--environment-name myenvironment \
--module kubernetes \
--name mycluster \
--container-registry container-registry.oracle.com/olcne \
--virtual-ip 192.0.2.100 \
--control-plane-nodes control1.example.com:8090,control2.example.com:8090,control3.example.com:8090 \
--worker-nodes worker1.example.com:8090,worker2.example.com:8090,worker3.example.com:8090,worker4.example.com:8090 \
--selinux enforcing \
--restrict-service-externalip-ca-cert /etc/olcne/certificates/restrict_external_ip/ca.cert \
--restrict-service-externalip-tls-cert /etc/olcne/certificates/restrict_external_ip/node.cert \
--restrict-service-externalip-tls-key /etc/olcne/certificates/restrict_external_ip/node.key

--virtual-ipオプションは、プライマリ・コントロール・プレーン・ノードに使用される仮想IPアドレスを設定します(たとえば、192.0.2.100)。 このIPアドレスは、ネットワーク上で使用可能であり、ネットワーク上のどのホストにも割り当てられていない必要があります。 このIPアドレスは、ロード・バランサによってプライマリ・コントローラとして割り当てられたコントロール・プレーン・ノードに動的に割り当てられます。

コンテナ・レジストリ・ミラーを使用している場合は、--nginx-imageオプションを使用してNGINXイメージの場所も設定する必要があります。 このオプションは、次の形式でレジストリ・ミラーの場所に設定する必要があります。

registry:port/olcne/nginx:version

たとえば:

--nginx-image myregistry.example.com:5000/olcne/nginx:1.17.7

この例で使用されているその他のオプションについては、「外部Load Balancerを使用したHAクラスタの作成」を参照してください。

単一のコントロール・プレーン・ノードを使用したクラスタの作成

この項では、単一のコントロール・プレーン・ノードを備えたクラスタを作成するためのKubernetesモジュールを作成する方法を示します。 このタイプのクラスタではロード・バランサは使用されず、必要ありません。

この例では、単一のコントロール・プレーン・ノード備えたクラスタを作成します。

olcnectl module create \
--environment-name myenvironment \
--module kubernetes --name mycluster \
--container-registry container-registry.oracle.com/olcne \
--control-plane-nodes control1.example.com:8090 \
--worker-nodes worker1.example.com:8090,worker2.example.com:8090 \
--selinux enforcing \
--restrict-service-externalip-ca-cert /etc/olcne/certificates/restrict_external_ip/ca.cert \
--restrict-service-externalip-tls-cert /etc/olcne/certificates/restrict_external_ip/node.cert \
--restrict-service-externalip-tls-key /etc/olcne/certificates/restrict_external_ip/node.key

--control-plane-nodesオプションには1つのノードのみを含めるようにしてください。

この例で使用されているその他のオプションについては、「外部Load Balancerを使用したHAクラスタの作成」を参照してください。

Kubernetesモジュールの検証

環境にKubernetesモジュールを作成した後は、モジュールをインストールするためにノードが正しく構成されていることを検証する必要があります。

olcnectl module validateコマンドを使用して、ノードが正しく構成されていることを検証します。 たとえば、myenvironment環境内のmyclusterというKubernetesモジュールを検証するには、次のようにします。

olcnectl module validate \
--environment-name myenvironment \
--name mycluster

検証エラーが発生した場合は、出力にノードを修正するために必要なコマンドが示されます。 そのコマンドをスクリプトとして保存する場合は、--generate-scriptsオプションを使用します。 たとえば:

olcnectl module validate \
--environment-name myenvironment \
--name mycluster \
--generate-scripts

モジュール内の各ノードに対してスクリプトが作成され、ローカル・ディレクトリに保存され、hostname:8090.shという名前が付けられます。 このスクリプトを該当するノードにコピーして実行することで、検証エラーを修正できます。

Kubernetesモジュールのインストール

Kubernetesモジュールを作成して検証した後は、これを使用してKubernetesをノードにインストールし、クラスタを作成します。

olcnectl module installコマンドを使用して、ノードにKubernetesをインストールし、クラスタを作成します。

Kubernetesモジュールのインストールの一環として次のことが実行されます。

• Kubernetesパッケージがノードにインストールされます。 kubeadmパッケージにより、CRI-OとKata Containersの実行に必要なパッケージがインストールされます。 CRI-Oは、コンテナをランタイム・エンジン(runcまたはkata-runtimeのどちらか)に委託するために必要です。 コンテナ・ランタイムの詳細は、コンテナ・ランタイムを参照してください。

• crioサービスとkubeletサービスが有効化および起動されます。

• 内部ロード・バランサをインストールしている場合は、コントロール・プレーン・ノードでolcne-nginxおよびkeepalivedサービスが有効化され、起動されます。

たとえば、myenvironment環境でmyclusterというKubernetesモジュールを使用してクラスタを作成するには、次のコマンドを使用します。

olcnectl module install \
--environment-name myenvironment \
--name mycluster

Kubernetesモジュールを使用してKubernetesがノードにインストールされ、クラスタが起動して健全性が検証されます。

重要:

Kubernetesのインストールは、完了までに数分かかることがあります。

Kubernetesモジュールに関する情報のレポート

Kubernetesモジュールをインストールしたら、Kubernetesモジュールとそのプロパティに関する情報を確認できます。

olcnectl module reportコマンドを使用して、モジュールに関する情報を確認します。

たとえば、次のコマンドを使用して、myenvironmentのmyclusterという名前のKubernetesモジュールを確認します:

olcnectl module report \
--environment-name myenvironment \
--name mycluster \
--children

olcnectl module reportコマンドの構文の詳細は、「プラットフォーム・コマンドライン・インタフェース」を参照してください。