機械翻訳について
  1. インストレーションforリリース1.8
  2. Oracle Cloud Native Environmentのインストール

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

この章では、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ノードの証明書の設定

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の設定時と環境の作成時に使用されます。 証明書には別のロケーションを使用できますが、サービスや環境を設定するときに、各証明書とキーのロケーションを指定する必要があります。

ヒント:

olcnectl certificates copyコマンドを使用して、証明書をKubernetesノードにコピーできます。

証明書とキーのデフォルトのロケーション、およびこのマニュアルで使用されるロケーションは、各ノードの/etc/olcne/certificates/ディレクトリです。

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

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

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

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

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

ノード証明書の配布

Platform CLIを使用して、署名付き証明書を生成し、Kubernetesノードに配布します。 CA証明書を使用することも、自動的に作成することもできます。 これらの証明書は、Kubernetesノード間の通信を保護するために、ノード上でPlatform API ServerおよびPlatformエージェントを起動するときに使用されます。

証明書を作成する前に、証明書を作成するオペレータ・ノードのユーザーがolcneグループのメンバーであることを確認します。 次の構文を使用します。

sudo usermod -a -G olcne username

たとえば、olcneグループをoracleユーザーに追加するには、オペレータ・ノードで実行します: 

sudo usermod -a -G olcne oracle

重要:

ユーザーにグループを追加する場合は、端末セッションからログアウトし、再度ログインする必要があります。 これは、変更を適用するために必要です。

オペレータ・ノードで、olcnectl certificates distributeコマンドを使用して、プライベートCAおよび証明書を生成し、Kubernetesノードに配布します。 次の構文を使用します: 
olcnectl certificates distribute
[--byo-ca-cert certificate-path]
[--byo-ca-key key-path]
[--cert-dir certificate-directory]
[--cert-request-common-name common_name]
[--cert-request-country country]
[--cert-request-locality locality]
[--cert-request-organization organization]
[--cert-request-organization-unit organization-unit]
[--cert-request-state state]
[{-h|--help}]
[{-n|--nodes} nodes]
[--one-cert]
[{-R|--remote-command} remote-command]
[{-i|--ssh-identity-file} file_location]
[{-l|--ssh-login-name} username]
[--timeout minutes]

証明書の作成対象のノードは、--nodesオプションで指定します。 Platform API ServerまたはPlatform Agentを実行する各ノードの証明書を作成します。 つまり、オペレータ・ノードおよび各Kubernetesノードの証明書を作成する必要があります。

ノート:

仮想IPアドレスを使用して可用性の高いKubernetesクラスタをデプロイする場合、仮想IPアドレスの証明書を作成する必要はありません。

たとえば:

olcnectl certificates distribute \
--nodes operator.example.com,control1.example.com,worker1.example.com,worker2.example.com

プライベートCAの情報を設定するには、--cert-request-*オプションを使用します。 次の例では、--ssh-*オプションを使用してノードのSSHログイン情報を設定するオプションも含まれています。 

olcnectl certificates distribute \
--nodes operator.example.com,control1.example.com,worker1.example.com,worker2.example.com \
--cert-request-common-name cloud.example.com \
--cert-request-country US \
--cert-request-locality "My Town" \
--cert-request-organization "My Company" \
--cert-request-organization-unit "My Company Unit" \
--cert-request-state "My State" \
--ssh-identity-file ~/.ssh/id_rsa \
--ssh-login-name oracle

証明書を生成するためのCA証明書と非公開キーがある場合は、--byo-ca-certおよび--byo-ca-keyオプションを使用してそれを提供できます。次に例を示します: 

olcnectl certificates distribute \
--nodes operator.example.com,control1.example.com,worker1.example.com,worker2.example.com \
--byo-ca-cert $HOME/certificates/ca/ca.cert \
--byo-ca-key $HOME/certificates/ca/ca.key

各ノードの証明書ファイルが生成され、各ホスト名のディレクトリにある$HOME/certificates/ディレクトリに保存されます。 --cert-dirオプションを使用した場合は、指定したディレクトリに保存されます。

CA証明書および秘密キーが$HOME/certificates/ca/ディレクトリに生成されます。 --cert-dirオプションを使用した場合は、指定したディレクトリに保存されます。 --byo-ca-*オプションを使用してCA証明書およびキーを使用した場合は、作成も保存もされません。

各ノードの証明書は、SSHを使用して、各Kubernetesノードの/etc/olcne/certificates/ディレクトリにコピーされます。 これは、Platform API ServerおよびPlatform Agentの起動時の証明書のロケーションのデフォルト・ディレクトリです。

追加のノード証明書の配布

Platform CLIを使用して、既存のCAを使用して署名付き証明書を生成し、ノードに配布します。

これは、Kubernetesクラスタに追加する追加のノードの証明書を生成および配布する場合に便利です。

オペレータ・ノードで、olcnectl certificates distributeコマンドを使用して、プライベートCAおよび証明書を生成し、Kubernetesノードに配布します。 次の構文を使用します: 

olcnectl certificates distribute
[--byo-ca-cert certificate-path]
[--byo-ca-key key-path]
[--cert-dir certificate-directory]
[--cert-request-common-name common_name]
[--cert-request-country country]
[--cert-request-locality locality]
[--cert-request-organization organization]
[--cert-request-organization-unit organization-unit]
[--cert-request-state state]
[{-h|--help}]
[{-n|--nodes} nodes]
[--one-cert]
[{-R|--remote-command} remote-command]
[{-i|--ssh-identity-file} file_location]
[{-l|--ssh-login-name} username]
[--timeout minutes]

証明書の作成対象のノードは、--nodesオプションで指定します。

--byo-ca-certオプションを使用して、既存のCA証明書のロケーションを指定します。

--byo-ca-certおよび--byo-ca-keyオプションを使用して、Kubernetesノード証明書の生成に使用したものと同じCA証明書および秘密キーを使用できます。

たとえば:

olcnectl certificates distribute \
--nodes worker3.example.com,worker4.example.com \
--byo-ca-cert $HOME/certificates/ca/ca.cert \
--byo-ca-key $HOME/certificates/ca/ca.key

元の証明書の作成時にolcnectl certificates distributeコマンドの--cert-dirオプションを使用した場合、CA証明書と秘密キーのロケーションは異なる場合があります。

各ノードの証明書ファイルが生成され、各ホスト名のディレクトリにある$HOME/certificates/ディレクトリに保存されます。

各ノードの証明書は、SSHを使用して、各Kubernetesノードの/etc/olcne/certificates/ディレクトリにコピーされます。 これは、Platform API ServerおよびPlatform Agentの起動時の証明書のロケーションのデフォルト・ディレクトリです。

Platform API ServerへのPlatform CLIの証明書の設定

Platform CLIとPlatform API Server間の通信は、X.509証明書を使用して保護されます。

Platform CLIとPlatform API Server間の通信の管理に使用するX.509証明書を構成することをお薦めします。 次に、使用可能な方法を示します。

  • Vault: 証明書は、HashiCorp Vaultシークレット・マネージャを使用して管理します。

  • CA証明書: 信頼できる認証局によって署名されたCA証明書を使用します。

  • プライベートCA証明書: 設定したプライベートCAによって署名された、生成された証明書を使用します。 こうした証明書は、管理対象外であり、手動で更新する必要があります。

証明書は、Platform CLIを含むノード上にある必要があります(これはおそらくオペレータ・ノードです)。 ディレクトリの名前は、Platform API Serverを含むホストの名前を反映します(これはおそらくオペレータ・ノードです)。 証明書のディレクトリの形式は次のとおりです:

$HOME/.olcne/certificates/api_server_hostname:port

api_server_hostnameはPlatform API Serverがインストールされているノードのホスト名で、portはPlatform API Serverにアクセスするためのポートです(デフォルトは8091です)。 これは、Platform API Serverキーのデフォルト・ディレクトリで、Platform CLIは追加の構成なしでPlatform API Serverへのアクセスをチェックします。 たとえば:

$HOME/.olcne/certificates/operator.example.com:8091

Platform API ServerへのPlatform CLIの証明書の生成

Platform CLIを使用して、Platform CLIの署名付き証明書を生成し、Platform API Serverにアクセスします。

オペレータ・ノードで、olcnectl certificates generateコマンドを使用してPlatform CLIの証明書を生成し、Platform API Serverにアクセスします。 次の構文を使用します: 

olcnectl certificates generate
[--byo-ca-cert certificate-path]
[--byo-ca-key key-path]
[--cert-dir certificate-directory]
[--cert-request-common-name common_name]
[--cert-request-country country]
[--cert-request-locality locality]
[--cert-request-organization organization]
[--cert-request-organization-unit organization-unit]
[--cert-request-state state]
[{-h|--help}]
{-n|--nodes} nodes
[--one-cert]

--cert-dirオプションは、証明書を保存するロケーションを設定します。 ディレクトリには、次の形式を使用することをお薦めします:

$HOME/.olcne/certificates/api_server_hostname:port

api_server_hostnameはPlatform API Serverがインストールされているノードのホスト名で、portはPlatform API Serverにアクセスするためのポートです(デフォルトは8091です)。 これは、Platform API Serverキーのデフォルト・ディレクトリであり、Platform CLIでは追加の構成なしでPlatform API Serverへのアクセスがチェックされます。

重要:

これは、olcnectl environment createコマンドを使用して環境を作成するときに、Platform CLIがPlatform API Serverにアクセスするための証明書のロケーションを指定するパスです。

次に示すように、--nodesオプションをPlatform API Serverのホスト名およびIPアドレスに設定する必要があります:

--nodes api_server_hostname,api_server_ip_address

ホスト名とIPアドレスの証明書を1つのファイルに保存するには、--one-certオプションを使用します。

--byo-ca-certおよび--byo-ca-keyオプションを使用して、Kubernetesノード証明書の生成に使用したものと同じCA証明書および秘密キーを使用できます。

たとえば:

olcnectl certificates generate \
--nodes operator.example.com,127.0.0.1 \
--cert-dir $HOME/.olcne/certificates/operator.example.com:8091/  \
--byo-ca-cert $HOME/certificates/ca/ca.cert \
--byo-ca-key $HOME/certificates/ca/ca.key \
--one-cert

この例では、証明書ファイル( node.cert、node.csr、node.key)が作成され、ディレクトリに保存されます:

$HOME/.olcne/certificates/operator.example.com:8091/

キーの生成に使用したCA証明書をこのディレクトリにコピーします。 たとえば: 

cp $HOME/certificates/ca/ca.cert $HOME/.olcne/certificates/operator.example.com:8091/

Platform CLIは、Platform API Serverに安全に接続するように設定されています。

externalIPs Kubernetesサービスの証明書の設定

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

このドキュメントの例では、これらの証明書に/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ノードの証明書の設定」で設定されている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をインストールするために使用するオペレータ・ノードでユーザーが読み取ることができることを確認します。 

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

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

Platform CLIを使用して証明書を生成できます。

ExternalIPsサービスの証明書の生成

Platform CLIを使用して、Kubernetes ExternalIPsサービスの署名付き証明書を生成します。

オペレータ・ノードで、olcnectl certificates generateコマンドを使用して、Kubernetes ExternalIPsサービスの証明書を生成します。 次の構文を使用します: 

olcnectl certificates generate
[--byo-ca-cert certificate-path]
[--byo-ca-key key-path]
[--cert-dir certificate-directory]
[--cert-request-common-name common_name]
[--cert-request-country country]
[--cert-request-locality locality]
[--cert-request-organization organization]
[--cert-request-organization-unit organization-unit]
[--cert-request-state state]
[{-h|--help}]
{-n|--nodes} nodes
[--one-cert]

--cert-dirオプションは、証明書を保存するロケーションを設定します。 次のディレクトリを使用することをお薦めします:

$HOME/certificates/restrict_external_ip/

使用するディレクトリには、olcnectlコマンドを実行してKubernetesをインストールするために使用するユーザーによる読取りおよび書込み権限が必要です。

重要:

これは、olcnectl module createコマンドを使用してKubernetesモジュールを作成するときに、ExternalIPs Kubernetesサービス証明書のロケーションを指定するパスです。

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

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

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

--byo-ca-certおよび--byo-ca-keyオプションを使用して、Kubernetesノード証明書の生成に使用したものと同じCA証明書および秘密キーを使用できます。

たとえば:

olcnectl certificates generate \
--nodes externalip-validation-webhook-service.externalip-validation-system.svc,\
externalip-validation-webhook-service.externalip-validation-system.svc.cluster.local \
--cert-dir $HOME/certificates/restrict_external_ip/ \
--byo-ca-cert $HOME/certificates/ca/ca.cert \
--byo-ca-key $HOME/certificates/ca/ca.key \
--one-cert

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

$HOME/certificates/restrict_external_ip/

証明書の生成に使用したCA証明書をこのディレクトリにコピーします。 すべてのデフォルト・パスと推奨パスを使用した場合、次のコマンドでファイルがコピーされます: 

cp $HOME/certificates/ca/ca.cert $HOME/certificates/restrict_external_ip/

証明書は、Kubernetes ExternalIPsサービスに対して設定されます。

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

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

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

テスト中に使用できる証明書に署名するためのプライベート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

    Kubernetesノードの証明書が/etc/olcne/certificates/ (デフォルト)以外のディレクトリにある場合は、証明書のロケーションを含めます。 --olcne-node-cert-path、--olcne-ca-path、および--olcne-node-key-pathオプションは、証明書ファイルのロケーションを設定します。 たとえば: 

    --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

    Kubernetesノードの証明書が/etc/olcne/certificates/ (デフォルト)以外のディレクトリにある場合は、証明書のロケーションを含めます。 --olcne-node-cert-path、--olcne-ca-path、および--olcne-node-key-pathオプションは、証明書ファイルのロケーションを設定します。 たとえば: 

    --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