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

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

重要:

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

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

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

この章では、ホストを設定し、Oracle Cloud Native Environmentソフトウェアをインストールするステップを実行して、モジュールのデプロイメントを実行する準備をします。 ノードを設定した後は、コンテナ・オーケストレーションのステップを使用して、KubernetesクラスタをインストールするためにKubernetesモジュールをデプロイします。

 インストールの概要

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

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

  1. オペレータ・ノードの準備: オペレータ・ノードは、環境のデプロイメントを実行および管理するために使用するホストです。 オペレータ・ノードは、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クラスタを形成するために使用されます。

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

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

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

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

この項では、オペレータ・ノードの設定について説明します。 operatorノードは、環境のデプロイメント(Kubernetesクラスタのデプロイを含む)の実行と管理に使用するホストです。

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

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

    Oracle Linux 8で、次のように入力します。 

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

    Oracle Linux 7で、次のように入力します。 

    sudo yum 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の構成オプションについては、「プラットフォームAPIサーバーの構成」を参照してください。

Kubernetesノードの設定

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

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

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

    Oracle Linux 8で、次のように入力します。 

    sudo dnf install olcne-agent olcne-utils

    Oracle Linux 7で、次のように入力します。 

    sudo yum install olcne-agent olcne-utils

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

    sudo systemctl enable olcne-agent.service

    プラットフォーム・エージェントの構成オプションについては、「プラットフォーム・エージェントの構成」を参照してください。

  3. プロキシ・サーバーを使用する場合は、CRI-Oで構成します。 Kubernetesノードごとに、CRI-O systemd構成ディレクトリを作成します。 

    sudo mkdir /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"

  4. dockerサービスが実行中の場合は、そのサービスを停止してから無効化してください。 

    sudo systemctl disable --now docker.service

  5. containerd サービスが実行中の場合は、そのサービスを停止してから無効化してください。 

    sudo systemctl disable --now containerd.service

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

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

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

  • 独自の外部ロード・バランサ・インスタンスを使用する方法

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

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

外部Load Balancerの設定

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

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

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

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

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

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

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ロード・バランサなどのクラウド・インフラストラクチャによって提供されるロード・バランサなど)を使用します。

プラットフォーム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証明書: Kubernetesモジュールのデプロイメント前には、独自の証明書(信頼できる認証局(CA)によって署名されていて、各Kubernetesノードにコピーしたもの)を使用できます。 こうした証明書は、管理対象外であり、手動で更新する必要があります。

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

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

Vaultのインストールと設定の詳細は、次に示すHashiCorpのドキュメントを参照してください。

https://learn.hashicorp.com/vault

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

Vault認証の設定

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

  • CA証明書または仲介(場所: olcne_pki_intermediary)があるPKIシークレット・エンジン。

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

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

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

https://www.vaultproject.io/docs/secrets/pki

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

https://www.vaultproject.io/docs/commands/token/create

CA証明書の設定

この項では、独自の証明書(信頼できるCAによって署名されていて、Vaultなどのシークレット・マネージャを使用しないもの)を使用する方法を示します。 独自の証明書を使用するには、その証明書をすべての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/ディレクトリを使用します。 これはノード上の証明書の推奨ロケーションです。 この証明書のパスは、各ノードでプラットフォーム・エージェントまたはプラットフォームAPIサーバーを設定するとき、および環境を作成するときに使用されます。

    証明書をノード/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スクリプトを使用して証明書ファイルをコピーする場合は、このドキュメントの例で使用されているものとは異なるディレクトリにコピーされます。

    プラットフォームAPIサーバーおよびプラットフォーム・エージェント・サービスを起動するとき、および環境の作成時に、このパス(/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