機械翻訳について
  1. スタート・ガイドforリリース1.7
  2. Oracle Cloud Native Environmentのインストール

3 Oracle Cloud Native Environmentのインストール

重要:

このドキュメントで説明されているソフトウェアは、Extended SupportまたはSustaining Supportにあります。 詳細は、「Oracleオープン・ソース・サポート・ポリシー」を参照してください。

このドキュメントに記載されているソフトウェアをできるだけ早くアップグレードすることをお勧めします。

この章では、Oracle Cloud Native Environmentデプロイメントで使用されるノードを準備する方法について説明します。 ノードの準備時には、Oracle Cloud Native Environmentソフトウェア・パッケージとともにインストールする必要があります。 ノードがソフトウェアで設定されている場合、Platform CLIを使用してKubernetesクラスタのデプロイメントを実行し、オプションで他のモジュールをインストールできます。

この章では、ホストを設定し、Oracle Cloud Native Environmentソフトウェアをインストールするステップを実行して、モジュールのデプロイメントを実行する準備をします。 ノードを設定したら、「Kubernetesモジュール」のステップを使用して、Kubernetesモジュールをデプロイし、Kubernetesクラスタをインストールします。

 インストールの概要

この項では、Oracle Cloud Native Environmentの設定の概要について説明します。

Oracle Cloud Native Environmentをインストールするには:

  1. オペレータ・ノードの準備: operatorノードは、環境のデプロイメントを実行および管理するために使用するホストです。 オペレータ・ノードは、Platform API ServerおよびPlatform CLI (olcnectl)で設定する必要があります。

  2. Kubernetesノードの準備: Kubernetesコントロール・プレーン・ノードとワーカー・ノードは、Platform Agentとともに設定する必要があります。

  3. ロード・バランサの設定: 高可用性のKubernetesクラスタをデプロイする場合は、ロード・バランサを設定します。 外部ロード・バランサを設定することも、Platform CLIによってデプロイされたコンテナ・ベースのロード・バランサを使用することもできます。

  4. X.509証明書の設定: X.509証明書は、Kubernetesノード間のセキュアな通信を提供するために使用されます。 証明書は、環境を作成してデプロイメントを実行する前に設定しておく必要があります。

  5. サービスの開始: X.509証明書を使用して、ノードでPlatform API ServerおよびPlatform Agentサービスを起動します。

  6. 環境の作成: Kubernetesモジュールおよびその他のオプション・モジュールをインストールできる環境を作成します。

  7. モジュールのデプロイ: Kubernetesモジュールおよびその他のオプション・モジュールをデプロイします。

 ノードの設定

この項では、Oracle Cloud Native Environmentで使用するノードの設定について説明します。 ノードは、Kubernetesクラスタを形成するために使用されます。

operatorノードは、Platform CLIおよびPlatform API Serverを使用して、Kubernetesクラスタのデプロイメントを実行するために使用されます。 オペレータ・ノードは、Kubernetesクラスタ内のノードまたは別のホストです。 このマニュアルの例では、オペレータ・ノードは個別のホストであり、Kubernetesクラスタの一部ではありません。

それぞれのKubernetesノード(コントロール・プレーン・ノードとワーカー・ノードの両方)に、Platform Agentがインストールされている必要があります。 Kubernetesノードの設定前に、ノードの準備が必要です。 ノードの準備の詳細は、「事前設定」を参照してください。

必須パッケージのインストール時に、olcneユーザーが作成されます。 このユーザーは、Platform API ServerまたはPlatform Agent・サービスの起動に使用され、そのタスクを実行するための最小OS権限を持ちます。 他の目的にolcneユーザーを使用しないでください。

 オペレータ・ノードの設定

この項では、オペレータ・ノードの設定について説明します。 operatorノードは、Kubernetesクラスタのデプロイなど、環境のデプロイメントの実行および管理に使用されるホストです。

オペレータ・ノードを設定するには:

  1. オペレータ・ノードに、Platform CLIとPlatform API Serverおよびユーティリティをインストールします。 

    sudo dnf install olcnectl olcne-api-server olcne-utils

  2. olcne-api-serverサービスを有効化します。ただし、そのサービスは起動しないでください。 olcne-api-serverサービスは、X.509証明書の構成時に起動されます。 

    sudo systemctl enable olcne-api-server.service

    Platform API Serverの構成オプションについては、「Platform API Serverの構成」を参照してください。

 Kubernetesノードの設定

この項では、Kubernetesクラスタで使用するためにノードを設定する方法について説明します。 Kubernetesのコントロール・プレーン・ノードとワーカー・ノードで、次のステップを実行します。

Kubernetesノードを設定するには:

  1. Kubernetesクラスタに追加する各ノードに、Platform Agentパッケージとユーティリティをインストールします。 

    sudo dnf install olcne-agent olcne-utils

  2. olcne-agentサービスを有効化します。ただし、そのサービスは起動しないでください。 olcne-agentサービスは、X.509証明書の構成時に起動されます。 

    sudo systemctl enable olcne-agent.service

    Platform Agentの構成オプションについては、「Platform Agentの構成」を参照してください。

  3. dockerサービスが実行されている場合は、停止して無効にします。 

    sudo systemctl disable --now docker.service

  4. containerdサービスが実行されている場合は、停止して無効にします。 

    sudo systemctl disable --now containerd.service

プロキシ・サーバーの構成

プロキシ・サーバーを使用する場合は、各KubernetesノードでCRI-Oを使用して構成します。

各Kubernetesノードで、次の手順を実行します:

  1. CRI-O systemd構成ディレクトリを作成します: 

    sudo mkdir /etc/systemd/system/crio.service.d

  2. そのディレクトリに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"

  3. Calico (モジュールとして、またはKubernetesコンテナ・ネットワーク・インタフェースとして)またはMultusモジュールもインストールする場合は、KubernetesサービスIP (デフォルトは10.96.0.1)をNO_PROXY変数に追加します: 

    Environment="NO_PROXY=mydomain.example.com,10.96.0.1"

 高可用性クラスタのロード・バランサの設定

高可用性(HA)クラスタには、コントロール・プレーン・ノードの高可用性を提供するためのロード・バランサが必要です。 ロード・バランサは、コントロール・プレーン・ノードのKubernetes APIサーバーと通信します。

HAクラスタを作成するためにロード・バランサを設定するメソッドは次のとおりです:

  • 外部ロード・バランサ・インスタンスの使用。

  • クラウド・インフラストラクチャによって提供されるロード・バランサ(Oracle Cloud Infrastructureロード・バランサなど)を使用します。

  • Platform CLIによってコントロール・プレーン・ノードにデプロイできる内部ロード・バランサの使用。

外部Load Balancerの設定

外部ロード・バランサ実装を使用するには、HAクラスタ・デプロイメントを実行する前に、外部ロード・バランサ実装を設定して使用する準備ができている必要があります。 ロード・バランサのホスト名とポートは、Kubernetesモジュールの作成時にオプションとして入力します。 ロード・バランサは、次の構成で設定する必要があります:

  • TCPポート6443でリスニングしているリスナー。

  • ラウンド・ロビンに設定された配布。

  • コントロール・プレーン・ノードでTCPポート6443に設定されたターゲット。

  • TCPに設定されたヘルス・チェック。

外部ロード・バランサの設定の詳細は、「Oracle Linux 9: ロード・バランシングの設定」または「Oracle Linux 8: ロード・バランシングの設定」を参照してください。

Oracle Cloud InfrastructureでのLoad Balancerの設定

Oracle Cloud Infrastructureにロード・バランサを設定するには:

  1. Oracle Cloud Infrastructureにサインインします。

  2. ロード・バランサを作成します。

  3. 重み付きラウンド・ロビンを使用して、バックエンド・セットをロード・バランサに追加します。 ヘルス・チェックをTCPポート6443に設定します。

  4. コントロール・プレーン・ノードをバックエンド・セットに追加します。 コントロール・プレーン・ノードのポートをポート6443に設定します。

  5. TCPポート6443を使用して、バックエンド・セットのリスナーを作成します。

Oracle Cloud Infrastructureでのロード・バランサの設定の詳細は、「Oracle Cloud Infrastructureドキュメント」を参照してください。

内部Load Balancerの設定

重要:

本番デプロイメントでは、内部ロード・バランサの使用はお薦めしません。 かわりに、Kubernetesクラスタの外部にある正しく構成されたロード・バランサ(独自の外部ロード・バランサ、「Oracle Cloud Infrastructureロード・バランサ」などのクラウド・インフラストラクチャによって提供されるロード・バランサなど)を使用します。

Platform CLIでデプロイした内部ロード・バランサを使用するには、コントロール・プレーン・ノードを準備するために、次のステップを実行する必要があります。

Platform CLIでデプロイしたロード・バランサ用にコントロール・プレーン・ノードを準備するには:

  1. 「Kubernetesノードの設定」の説明に従って、コントロール・プレーン・ノードを設定します。

  2. Kubernetesモジュールの作成時に--virtual-ipオプションを使用して、プライマリ・コントロール・プレーン・ノードに使用できる仮想IPアドレスを指定します。 このIPアドレスは、どのノードにも使用されていない必要があり、ロード・バランサによってプライマリ・コントローラとして割り当てられたコントロール・プレーン・ノードに動的に割り当てられます。 プライマリ・ノードに障害が発生すると、ロード・バランサによって、その仮想IPアドレスが別のコントロール・プレーン・ノードに再割当てされます。そのノードがプライマリ・ノードになります。

    ヒント:

    Oracle Cloud Infrastructure仮想インスタンスにデプロイする場合は、コントロール・プレーン・ノードのVNICにセカンダリ・プライベートIPアドレスを割り当てて、仮想IPアドレスを作成できます。 Kubernetesモジュールの作成時に、最初にこのコントロール・プレーン・ノードをリストしてください。 セカンダリ・プライベートIPアドレスの詳細は、「Oracle Cloud Infrastructureドキュメント」を参照してください。

  3. 各コントロール・プレーン・ノードで、ポート6444を開きます。 仮想IPを使用すると、Kubernetes APIサーバーのポートがデフォルトの6443から6444に変更されます。 ロード・バランサはポート6443でリスニングして、受信したリクエストをKubernetes APIサーバーに渡します。 

    sudo firewall-cmd --add-port=6444/tcp
sudo firewall-cmd --add-port=6444/tcp --permanent

  4. 各コントロール・プレーン・ノードで、Virtual Router Redundancy Protocol (VRRP)プロトコルを有効にします: 

    sudo firewall-cmd --add-protocol=vrrp
sudo firewall-cmd --add-protocol=vrrp --permanent

KubernetesノードのX.509証明書の設定

Kubernetesノード間の通信は、X.509証明書を使用することで保護されます。

Kubernetesのデプロイ前に、ノード間の通信の管理に使用するX.509証明書を構成する必要があります。 次に、使用可能な方法を示します。

  • Vault: 証明書は、HashiCorp Vaultシークレット・マネージャを使用して管理します。 証明書は、Kubernetesモジュールのデプロイメント「範囲」として作成されます。 Oracle Cloud Native Environmentのトークン認証メソッドを作成する必要があります。

  • CA証明書: 信頼できる認証局(CA)によって署名され、Kubernetesモジュールのデプロイメント前に各Kubernetesノードにコピーされた証明書を使用します。 こうした証明書は、管理対象外であり、手動で更新する必要があります。

  • プライベートCA証明書: Kubernetesモジュールのデプロイメント前には、生成した証明書(自分で設定したプライベートCAによって署名されていて、各Kubernetesノードにコピーしたもの)を使用できます。 こうした証明書は、管理対象外であり、手動で更新する必要があります。 これを設定するために利用できるスクリプトが用意されています。

こうした証明書の管理には、ソフトウェアベースのシークレット・マネージャの使用をお薦めします。 HashiCorp Vaultシークレット・マネージャは、証明書の生成、割当ておよび管理に使用できます。 環境に適したセキュリティを設定して、Vaultのインスタンスを実装することをお薦めします。

Vaultのインストールおよび設定の詳細は、「Hashicorpのドキュメント」を参照してください。

Vaultを使用しない場合は、信頼できるCAによって署名され、各ノードにコピーされた証明書を使用できます。 プライベートCAを生成して各ノードの証明書を生成するためのスクリプトが用意されています。 このスクリプトには、証明書をノードにコピーするためのコマンドもあります。

 Vault認証の設定

Oracle Cloud Native Environmentで使用するVaultを構成するには、次のプロパティでVaultトークンを設定します:

  • CA証明書または中間体を含むPKIシークレット・エンジン(olcne_pki_intermediary)。

  • そのPKIの下のolcneというロール(共通名が不要で、任意の名前が許容されるように構成されたもの)。

  • olcneロールにアタッチして証明書の要求が可能なトークン認証方式とポリシー。

動的なX.509証明書を生成するようにVault PKIシークレット・エンジンを設定する方法の詳細は、次を参照してください。

https://developer.hashicorp.com/vault/docs/secrets/pki

Vaultのトークンを作成する方法の詳細は、次を参照してください。

https://developer.hashicorp.com/vault/docs/commands/token/create

 CA証明書の設定

この項では、Vaultなどのシークレット・マネージャを使用せずに、信頼できるCAによって署名された証明書を使用する方法を示します。 証明書を使用するには、これらをすべてのKubernetesノードおよびPlatform API Serverノードにコピーします。

各KubernetesノードのPlatform AgentとPlatform API Serverが証明書にアクセスできるようにするには、それらを各ノードの/etc/olcne/certificates/ディレクトリにコピーします。 この証明書のパスは、Platform AgentおよびPlatform API Serverの設定時と環境の作成時に使用されます。

このドキュメントの例では、証明書に/etc/olcne/certificates/ディレクトリを使用します。 たとえば:

  • CA証明書: /etc/olcne/certificates/ca.cert

  • ノード・キー: /etc/olcne/certificates/node.key

  • ノード証明書: /etc/olcne/certificates/node.cert

 プライベートCA証明書の設定

この項では、プライベートCAの作成方法と、それを使用してノード用に署名済証明書を生成する方法を示します。 この項には、ノードへの証明書のコピーに関する情報も含まれています。 この項では、Kubernetesクラスタにスケール・インするノードの証明書の生成についても説明します。

 証明書の作成およびコピー

この項では、プライベートCAの作成方法と、それを使用してノード用に署名済証明書を生成する方法を示します。

プライベートCAを使用して証明書を生成するには:

  1. オペレータ・ノードで、/etc/olcne/gen-certs-helper.shスクリプトを使用して、ノードのプライベートCAおよび証明書を生成します。

    証明書のファイルは、gen-certs-helper.shスクリプトを実行したディレクトリに保存されます。 gen-certs-helper.shスクリプトは、証明書を各Kubernetesノード(olcne-tranfer-certs.sh)にコピーするために使用できるスクリプトも作成します。 /etc/olcneディレクトリからgen-certs-helper.shスクリプトを実行する場合、ディレクトリ/etc/olcne/configs/certificates/を使用して生成されたファイルを保存します。

    ノート:

    オプションで、--cert-dirオプションを使用して、証明書および転送スクリプトを保存するロケーションを指定できます。 --cert-dirオプションを使用する場合は、このセクションのパスを指定したパスに変更してください。

    証明書の作成対象のノードは、--nodesオプションで指定します。 Platform API ServerまたはPlatform Agentを実行する各ノードの証明書を作成します。 つまり、オペレータ・ノード用のものと、それぞれのKubernetesノード用のものがあるということです。 仮想IPアドレス(内部ロード・バランサを使用)を使用して可用性の高いKubernetesクラスタをデプロイする場合、仮想IPアドレスの証明書を作成する必要はありません。

    --cert-request* オプションを使用して非公開CA情報を指定します(これらのオプションの一部は、すべてではない場合があります)。 gen-certs-helper.sh --helpコマンドを使用して、すべてのコマンド・オプションのリストを取得できます。

    たとえば: 

    cd /etc/olcne
sudo ./gen-certs-helper.sh \
--cert-request-organization-unit "My Company Unit" \
--cert-request-organization "My Company" \
--cert-request-locality "My Town" \
--cert-request-state "My State" \
--cert-request-country US \
--cert-request-common-name cloud.example.com \
--nodes operator.example.com,control1.example.com,worker1.example.com,worker2.example.com,\
worker3.example.com

    ノードごとの証明書とキーは、次のディレクトリに生成されて保存されます。

    /etc/olcne/configs/certificates/tmp-olcne/node/

    「ノード」は、証明書が生成されたノードの名前です。

    プライベートCA証明書とキーのファイルは、次のディレクトリに保存されます。

    /etc/olcne/configs/certificates/production/

  2. ノード用に生成された証明書を/etc/olcne/configs/certificates/tmp-olcne/node/ディレクトリからそのノードにコピーします。

    このドキュメントの例では、ノード上の証明書のロケーションとして/etc/olcne/certificates/ディレクトリを使用します。 これはノード上の証明書の推奨ロケーションです。 この証明書のパスは、各ノードでPlatform AgentまたはPlatform API Serverを設定するとき、および環境を作成するときに使用されます。

    証明書をノード/etc/olcne/configs/certificates/olcne-tranfer-certs.shにコピーするのに役立つスクリプトが作成されます。 このスクリプトを使用して環境に合わせて変更することも、別のメソッドで証明書をノードに転送することもできます。

    重要:

    olcne-tranfer-certs.shスクリプトのUSER変数が、ノードへのSSHキー・ベースの認証を使用して設定されたユーザーに設定されていることを確認します。 「SSHキー・ベース認証の設定」を参照してください。

    スクリプトを実行して、証明書をノードにコピーします。 

    bash -ex /etc/olcne/configs/certificates/olcne-tranfer-certs.sh

    このスクリプトは、各ノードの証明書をノード上の次のディレクトリにコピーします:

    /etc/olcne/configs/certificates/production/

    重要:

    olcne-tranfer-certs.shスクリプトを使用して証明書ファイルをコピーする場合は、このドキュメントの例で使用されているものとは異なるディレクトリにコピーされます。

    Platform API ServerおよびPlatform Agentサービスの起動時および環境の作成時に、このパス(/etc/olcne/configs/certificates/production/)を使用してください。 このパスは、このドキュメントの例で使用されている/etc/olcne/certificates/の標準パスとは異なります。

  3. Platform API ServerまたはPlatform Agentを実行する各ノードのolcneユーザーが、証明書をコピーするディレクトリを読み取れることを確認します。 /etc/olcne/certificates/の証明書のデフォルト・パスを使用した場合、olcneユーザーは読取りアクセス権を持ちます。

    別のパスを使用する場合は、olcneユーザーが証明書のパスを読取りできることを確認してください。 オペレータ・ノードと各Kubernetesノードで、次を実行します。 

    sudo -u olcne ls /etc/olcne/configs/certificates/production/

    ノードの証明書とキーのリストが表示されます。 

    ca.cert  node.cert  node.key
 追加の証明書の作成

この項では、Kubernetesクラスタに追加する追加のノードの証明書の生成について説明します。 この項では、オペレータ・ノードで/etc/olcne/gen-certs-helper.shスクリプトを使用して証明書を生成する方法を示します。

プライベートCAを使用して証明書を生成するには:

  1. オペレータ・ノードで、/etc/olcne/gen-certs-helper.shスクリプトを使用して、ノードの新しい証明書を作成します。 たとえば: 

    cd /etc/olcne
sudo ./gen-certs-helper.sh \
--cert-request-organization-unit "My Company Unit" \
--cert-request-organization "My Company" \
--cert-request-locality "My Town" \
--cert-request-state "My State" \
--cert-request-country US \
--cert-request-common-name cloud.example.com \
--nodes control4.example.com,control5.example.com \
--byo-ca-cert /etc/olcne/configs/certificates/production/ca.cert \
--byo-ca-key /etc/olcne/configs/certificates/production/ca.key

    新しい証明書を生成する秘密キーは--byo-ca-keyオプションで指定され、CA証明書は--byo-ca-certオプションで指定されます。 この例では、プライベートCA証明書およびキー・ファイルがディレクトリにあります:

    /etc/olcne/configs/certificates/production/

    元の証明書の作成時にgen-certs-helper.shスクリプトの--cert-dirオプションを使用した場合、ロケーションは異なる場合があります。

  2. 新しい証明書を生成した後、それらをノードにコピーします。 証明書をノードolcne-tranfer-certs.shにコピーするのに役立つスクリプトが作成されます。 このスクリプトを使用して環境に合わせて変更することも、別のメソッドで証明書をノードに転送することもできます。

    スクリプトを実行して、証明書をノードにコピーします。 

    bash -ex /etc/olcne/configs/certificates/olcne-tranfer-certs.sh

externalIPs Kubernetes ServiceのX.509証明書の設定

Kubernetesをデプロイすると、KubernetesサービスのexternalIPsへのアクセスを制御するクラスタにサービスがデプロイされます。 このサービスはexternalip-validation-webhook-serviceという名前で、externalip-validation-systemネームスペースで実行されます。 このKubernetesサービスでは、Kubernetesをデプロイする前にX.509証明書を設定する必要があります。 Vaultを使用して証明書を生成したり、この目的で既存の証明書を使用できます。 gen-certs-helper.shスクリプトを使用して証明書を生成することもできます。 証明書はオペレータ・ノードで使用可能である必要があります。

このドキュメントの例では、これらの証明書に/etc/olcne/certificates/restrict_external_ip/ディレクトリを使用します。

Vault証明書を設定

Vaultを使用して、externalIPs Kubernetesサービスの証明書を生成できます。 Vaultインスタンスは、「Vault認証の設定」で説明されているのと同じ方法で構成する必要があります。

次の名前の2つのノードの証明書を生成する必要があります:

externalip-validation-webhook-service.externalip-validation-system.svc

externalip-validation-webhook-service.externalip-validation-system.svc.cluster.local

証明書情報は、PEM形式で生成する必要があります。

たとえば: 

vault write olcne_pki_intermediary/issue/olcne \
    alt_names=externalip-validation-webhook-service.externalip-validation-system.svc,\
externalip-validation-webhook-service.externalip-validation-system.svc.cluster.local \
    format=pem_bundle

出力が表示されます。 certificateで始まるセクションを探します。 このセクションには、(alt_namesオプションで設定された)ノード名の証明書が含まれます。 このセクションの出力をnode.certという名前のファイルに保存します。 ファイルは次のようになります: 

-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEAymg8uHy+mpwlelCyC4WrnfLwUmJ5vZmSos85QnIlZvyycUPK
...
X3c8LNaJDfQx1wKfTc/c0czBhHYxgwfau0G6wjqScZesPi2xY0xyslE=
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIID2TCCAsGgAwIBAgIUZ/M/D7bAjhyGx7DivsjBb9oeLhAwDQYJKoZIhvcNAQEL
...
9bRwnen+JrxUn4GV59GtsTiqzY6R2OKPm+zLl8E=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDnDCCAoSgAwIBAgIUMapl4aWnBXE/02qTW0zOZ9aQVGgwDQYJKoZIhvcNAQEL
...
kV8w2xVXXAehp7cg0BakVA==
-----END CERTIFICATE-----

issuing_caで始まるセクションを探します。 このセクションには、CA証明書が含まれます。 このセクションの出力をca.certという名前のファイルに保存します。 ファイルは次のようになります: 

-----BEGIN CERTIFICATE-----
MIIDnDCCAoSgAwIBAgIUMapl4aWnBXE/02qTW0zOZ9aQVGgwDQYJKoZIhvcNAQEL
...
kV8w2xVXXAehp7cg0BakVA==
-----END CERTIFICATE-----

private_keyで始まるセクションを探します。 このセクションには、ノード証明書の秘密キーが含まれます。 このセクションの出力をnode.keyという名前のファイルに保存します。 ファイルは次のようになります: 

-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEAymg8uHy+mpwlelCyC4WrnfLwUmJ5vZmSos85QnIlZvyycUPK
...
X3c8LNaJDfQx1wKfTc/c0czBhHYxgwfau0G6wjqScZesPi2xY0xyslE=
-----END RSA PRIVATE KEY-----

3つのファイル(node.cert、ca.certおよびnode.key)をオペレータ・ノードにコピーし、「CA証明書の設定」の説明に従ってファイルの所有権を設定します。

 CA証明書の設定

既存の証明書を使用している場合は、オペレータ・ノードの/etc/olcne/certificates/の下のディレクトリにコピーします。 たとえば:

  • CA証明書: /etc/olcne/certificates/restrict_external_ip/ca.cert

  • ノード・キー: /etc/olcne/certificates/restrict_external_ip/node.key

  • ノード証明書: /etc/olcne/certificates/restrict_external_ip/node.cert

これらの証明書を、「KubernetesノードのX.509証明書の設定」で設定されているKubernetesノードで使用される証明書およびキーとは異なるロケーションにオペレータ・ノードにコピーします。 これにより、これらの証明書およびキーは上書きされません。 次の名前の2つのノードの証明書を生成する必要があります:

externalip-validation-webhook-service.externalip-validation-system.svc

externalip-validation-webhook-service.externalip-validation-system.svc.cluster.local

これらの2つのノードの証明書を、node.certという名前の単一ファイルとして保存します。

証明書が保存されるディレクトリの権限が、olcnectlコマンドを実行してKubernetesをインストールするために使用するオペレータ・ノードでユーザーが読み取ることができることを確認します。 この例では、opcユーザーがオペレータ・ノードで使用されるため、ディレクトリの所有権はopcユーザーに設定されます: 

sudo chown -R opc:opc /etc/olcne/certificates/restrict_external_ip/

 プライベートCA証明書の設定

gen-certs-helper.shスクリプトを使用して証明書を生成できます。 オペレータ・ノードでスクリプトを実行し、環境に必要なオプションを入力します。

--cert-dirオプションは、証明書を保存するロケーションを設定します。

--nodesオプションは、次に示すように、Kubernetesサービスの名前に設定する必要があります:

--nodes externalip-validation-webhook-service.externalip-validation-system.svc,externalip-validation-webhook-service.externalip-validation-system.svc.cluster.local

--one-certオプションを使用して、2つのサービス名の証明書を単一のファイルに保存します。 

cd /etc/olcne
sudo ./gen-certs-helper.sh \
--cert-dir /etc/olcne/certificates/restrict_external_ip/ \
--cert-request-organization-unit "My Company Unit" \
--cert-request-organization "My Company" \
--cert-request-locality "My Town" \
--cert-request-state "My State" \
--cert-request-country US \
--cert-request-common-name cloud.example.com \
--nodes externalip-validation-webhook-service.externalip-validation-system.svc,\
externalip-validation-webhook-service.externalip-validation-system.svc.cluster.local \
--one-cert

--byo-ca-certおよび--byo-ca-keyオプションを使用して、Kubernetesノード証明書の生成に使用したものと同じCA証明書および秘密キーを使用できます。 たとえば、gen-certs-helper.shスクリプトを使用してノード証明書を生成した場合は、コマンドに次の行を追加します: 

--byo-ca-cert /etc/olcne/configs/certificates/production/ca.cert \
--byo-ca-key /etc/olcne/configs/certificates/production/ca.key

この例では、証明書が作成され、ディレクトリに保存されます:

/etc/olcne/certificates/restrict_external_ip/production

証明書が保存される出力ディレクトリの権限を、olcnectlコマンドを実行してKubernetesをインストールするために使用するオペレータ・ノードでユーザーが読み取ることができることを確認します。 この例では、opcユーザーがオペレータ・ノードで使用されるため、ディレクトリの所有権はopcユーザーに設定されます。 たとえば: 

sudo chown -R opc:opc /path/

この項に示すようにgen-certs-helper.shスクリプトを使用した場合は、次を実行します: 

sudo chown -R opc:opc /etc/olcne/certificates/restrict_external_ip/production

 Platform API ServerとPlatform Agentサービスの起動

この項では、クラスタ内でノード上のPlatform API ServerとPlatform Agentの間に安全な通信を設定するために証明書を使用する方法について説明します。 Vaultによって管理される証明書を使用するか、各ノードにコピーされた証明書を使用して、セキュアな通信を設定できます。 Platform API ServerとPlatform Agentは、サービスの起動時に証明書を使用するように構成する必要があります。

Vaultで証明書を設定する方法については、「KubernetesノードのX.509証明書の設定」を参照してください。

テスト中に使用できる証明書に署名するためのプライベートCAの作成については、「プライベートCA証明書の設定」を参照してください。

 Vaultを使用したサービスの起動

この項では、Vaultで管理された証明書を使用するようにPlatform API ServerとPlatform Agentサービスを設定する方法について説明します。

Vaultを使用してサービスを設定および起動するには:

  1. オペレータ・ノードで、/etc/olcne/bootstrap-olcne.shスクリプトを使用して、Vault証明書を取得して使用するようにPlatform API Serverを構成します。 このスクリプトのオプションのリストを表示するには、bootstrap-olcne.sh --helpコマンドを使用します。 たとえば: 

    sudo /etc/olcne/bootstrap-olcne.sh \
--secret-manager-type vault \
--vault-token s.3QKNuRoTqLbjXaGBOmO6Psjh \
--vault-address https://192.0.2.20:8200 \
--force-download-certs \
--olcne-component api-server

    Vaultで生成された証明書がダウンロードされます。

    デフォルトでは、証明書は/etc/olcne/certificates/ディレクトリに保存されます。 オプションで、証明書のパスを指定できます。たとえば、bootstrap-olcne.shコマンドに次のオプションを含めます: 

    --olcne-ca-path /path/ca.cert \
--olcne-node-cert-path /path/node.cert \
--olcne-node-key-path /path/node.key \

    Platform API Serverは、証明書を使用するように構成されてから起動されます。 次のコマンドを使用して、サービスが実行中であることを確認できます。 

    systemctl status olcne-api-server.service

  2. 各Kubernetesノードで、/etc/olcne/bootstrap-olcne.shスクリプトを使用して、証明書を取得して使用するようにPlatform Agentを構成します。 たとえば: 

    sudo /etc/olcne/bootstrap-olcne.sh \
--secret-manager-type vault \
--vault-token s.3QKNuRoTqLbjXaGBOmO6Psjh \
--vault-address https://192.0.2.20:8200 \
--force-download-certs \
--olcne-component agent

    Vaultで生成された証明書がダウンロードされます。

    デフォルトでは、証明書は/etc/olcne/certificates/ディレクトリに保存されます。 オプションで、証明書のパスを指定できます。たとえば、bootstrap-olcne.shコマンドに次のオプションを含めます: 

    --olcne-ca-path /path/ca.cert \
--olcne-node-cert-path /path/node.cert \
--olcne-node-key-path /path/node.key \

    Platform Agentは、証明書を使用するように構成されてから起動されます。 次のコマンドを使用して、サービスが実行中であることを確認できます。 

    systemctl status olcne-agent.service

 証明書を使用したサービスの起動

この項では、各ノードにコピーされた証明書を使用するようにPlatform API ServerおよびPlatform Agentサービスを設定する方法について説明します。 この例では、証明書が/etc/olcne/certificates/ディレクトリ内のすべてのノードで使用できることを前提としています。

証明書を使用してサービスをセットアップおよび起動するには:

  1. オペレータ・ノードで、/etc/olcne/bootstrap-olcne.shスクリプトを使用して、証明書を使用するようにPlatform API Serverを構成します。 このスクリプトのオプションのリストを表示するには、bootstrap-olcne.sh --helpコマンドを使用します。 たとえば: 

    sudo /etc/olcne/bootstrap-olcne.sh \
--secret-manager-type file \
--olcne-component api-server

    証明書が/etc/olcne/certificates/以外のディレクトリにある場合は、次のようなオプションを使用して証明書のロケーションを追加します: 

    --olcne-node-cert-path /etc/olcne/configs/certificates/production/node.cert \
--olcne-ca-path /etc/olcne/configs/certificates/production/ca.cert \
--olcne-node-key-path /etc/olcne/configs/certificates/production/node.key \

    Platform API Serverは、証明書を使用するように構成されてから起動されます。 次のコマンドを使用して、サービスが実行中であることを確認できます。 

    systemctl status olcne-api-server.service

  2. 各Kubernetesノードで、/etc/olcne/bootstrap-olcne.shスクリプトを使用して、証明書を使用するようにPlatform Agentを構成します。 たとえば: 

    sudo /etc/olcne/bootstrap-olcne.sh \
--secret-manager-type file \
--olcne-component agent

    証明書が/etc/olcne/certificates/以外のディレクトリにある場合は、次のようなオプションを使用して証明書のロケーションを追加します: 

    --olcne-node-cert-path /etc/olcne/configs/certificates/production/node.cert \
--olcne-ca-path /etc/olcne/configs/certificates/production/ca.cert \
--olcne-node-key-path /etc/olcne/configs/certificates/production/node.key \

    Platform Agentは、証明書を使用するように構成されてから起動されます。 次のコマンドを使用して、サービスが実行中であることを確認できます。 

    systemctl status olcne-agent.service