機械翻訳について

このドキュメントで説明されているソフトウェアは、サポートされなくなったか、拡張サポートされています。
Oracleでは、現在サポートされているリリースにアップグレードすることをお勧めします。

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

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

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

3.1 インストールの概要

この項では、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モジュールおよびその他のオプション・モジュールをデプロイします。

3.2 ノードの設定

• 3.2.1 オペレータ・ノードの設定
• 3.2.2 Kubernetesノードの設定

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

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

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

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

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

この項では、オペレータ・ノードの設定について説明します。 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の構成オプションの詳細は、4.1「Platform API Serverの構成」を参照してください。

3.2.2 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 

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

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

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

   そのディレクトリにproxy.confというファイルを作成して、プロキシ・サーバーの情報を追加します。 たとえば:

   [Service]
   Environment="HTTP_PROXY=proxy.example.com:3128"
   Environment="HTTPS_PROXY=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

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

• 3.3.1 独自のロード・バランサの設定
• 3.3.2 組込みロード・バランサの設定

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

HAクラスタを作成するためにロード・バランサを設定する方法は2つあります。

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

• Platform CLIでコントロール・プレーン・ノードにデプロイできるロード・バランサを使用する方法

3.3.1 独自のロード・バランサの設定

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

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

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

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

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

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

Oracle Cloud Infrastructureにデプロイする場合は、ロード・バランサを設定します。

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

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

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

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

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

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

3.3.2 組込みロード・バランサの設定

Platform CLIでデプロイ可能な組込みのロード・バランサを使用する場合は、コントロール・プレーン・ノードの準備のために、次のステップを実行する必要があります。 これらのステップは、各コントロール・プレーン・ノードで実行する必要があります。

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

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

2. プライマリ・コントロール・プレーン・ノードに使用できる仮想IPアドレスを指定します。 このIPアドレスはどのノードでも使用しないでください。また、ロード・バランサによってプライマリ・コントローラとして割り当てられたコントロール・プレーン・ノードに動的に割り当てられます。 プライマリ・ノードに障害が発生すると、ロード・バランサによって、その仮想IPアドレスが別のコントロール・プレーン・ノードに再割当てされます。そのノードがプライマリ・ノードになります。 このマニュアルの例で使用する仮想IPアドレスは、192.0.2.100です。

   ヒント

   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. 仮想ルーター冗長プロトコル(VRRP)プロトコルを有効にします。

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

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

• 3.4.1 Vault認証の設定
• 3.4.2 CA証明書の設定
• 3.4.3 プライベートCA証明書の設定

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/operations/ops-deployment-guide

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

3.4.1 Vault認証の設定

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

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

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

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

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

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

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

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

3.4.2 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

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

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

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

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

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

1. (オプション)オペレータ・ノードとKubernetesノードの間に鍵なしSSHを設定できます。そうすることで、ノードへの証明書のコピーが簡単になります。 鍵なしSSHの設定の詳細は、Oracle® Linux: OpenSSHによるリモート・システムへの接続を参照してください。

2. /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アドレスの証明書を作成する必要はありません。

   プライベートCAの情報は、--cert-request*オプションを使用して指定します(該当するオプションの一部についていは、例で示します)。 すべてのコマンド・オプションのリストは、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/

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

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

   /etc/olcne/configs/certificates/production/

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

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

   証明書をノード/etc/olcne/configs/certificates/olcne-tranfer-certs.shにコピーするのに役立つスクリプトが作成されます。 このスクリプトを使用して必要に応じて変更することも、別の方法で証明書をノードにコピーすることもできます。

   重要

   キー・レスSSHを設定する場合は、olcne-tranfer-certs.shスクリプトのUSER変数を、キー・レス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/の標準パスとは異なります。

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

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

3.4.3.2 追加の証明書の作成

この項では、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

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

• 3.5.1 Vault証明書を設定
• 3.5.2 CA証明書の設定
• 3.5.3 プライベートCA証明書の設定

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/ディレクトリを使用します。

3.5.1 Vault証明書を設定

Vaultを使用して、externalIPs Kubernetesサービスの証明書を生成できます。 Vaultインスタンスは、第3.4.1項、「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)をオペレータ・ノードにコピーし、第3.5.2項、「CA証明書の設定」の説明に従ってファイルの所有権を設定します。

3.5.2 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

これらの証明書は、第3.4項、「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/

3.5.3 プライベート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

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

• 3.6.1 Vaultを使用したサービスの起動
• 3.6.2 証明書を使用したサービスの起動

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

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

テスト時に使用可能な証明書に署名するためのプライベートCAの作成方法の詳細は、3.4.3「プライベートCA証明書の設定」を参照してください。

3.6.1 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 

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

この項では、各ノードにコピーした独自の証明書を使用して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 

3.7 環境の作成

• 3.7.1 Vaultで管理された証明書を使用した環境の作成
• 3.7.2 証明書を使用した環境の作成

Kubernetesクラスタを作成するための最初のステップは、環境の作成です。 それぞれの環境に潜在的に複数のモジュールが含まれている、複数の環境を作成できます。 各環境およびモジュールに名前を付けると、Oracle Cloud Native Environmentのデプロイ済コンポーネントの管理が容易になります。

ノート

複数の環境で同じノードを使用しないでください。

オペレータ・ノードでolcnectl environment createコマンドを使用して環境を作成します。 olcnectl environment createコマンドの構文の詳細は、プラットフォーム・コマンドライン・インタフェースを参照してください。

ヒント

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

この項では、環境の作成にVaultを使用する方法と、各ノードのファイル・システムにコピーした独自の証明書を使用する方法を示します。 X.509証明書の設定の詳細は、第3.4項、「KubernetesノードのX.509証明書の設定」を参照してください。

3.7.1 Vaultで管理された証明書を使用した環境の作成

この項では、証明書の提供と管理にVaultを使用する環境の作成方法を示します。

オペレータ・ノードで、olcnectl environment createコマンドを使用して環境を作成します。 たとえば、https://192.0.2.20:8200にあるVaultインスタンスから生成された証明書を使用して、myenvironmentという環境を作成するには、次のようにします。:

olcnectl environment create \
--api-server 127.0.0.1:8091 \
--environment-name myenvironment \
--secret-manager-type vault \
--vault-token s.3QKNuRoTqLbjXaGBOmO6Psjh \
--vault-address https://192.0.2.20:8200 \
--update-config 

--api-serverオプションは、Platform API Serverサービスのロケーションを設定します。 この例では、Platform API Serverがオペレータ・ノード(localhost)で実行され、ポート8091でリスニングしています。

--environment-nameオプションは環境の名前を設定します。この例ではmyenvironmentです。

--secret-manager-typeオプションは、証明書マネージャをVaultに設定します。

--vault-tokenは、Vaultにアクセスするためのトークンに置き換えてください。

--vault-addressは、Vaultインスタンスの場所に置き換えてください。

デフォルトでは、Vaultによって生成された証明書は$HOME/.olcne/certificates/environment_name/に保存されます。 証明書の保存先に別の場所を指定する場合は、オプションの--olcne-node-cert-path、--olcne-ca-pathおよび--olcne-node-key-pathを使用します。 たとえば、olcnectl environment createコマンドに、次のオプションを追加します。

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

--update-configオプションは、環境に関する情報を$HOME/.olcne/olcne.confにあるローカル構成ファイルに書き込み、この構成はプラットフォームAPIサーバーへの将来の呼び出しに使用されます。 このオプションを使用する場合は、将来のolcnectlコマンドでPlatform API Server (--api-serverオプションを使用)を指定する必要はありません。 Platform API Serverの設定の詳細は、プラットフォーム・コマンドライン・インタフェースを参照してください。

3.7.2 証明書を使用した環境の作成

この項では、独自の証明書(各ノードにコピーしたもの)を使用して環境を作成する方法を示します。 この例では、証明書が/etc/olcne/certificates/ディレクトリ内のすべてのノードで使用できることを前提としています。

オペレータ・ノードで、olcnectl environment createコマンドを使用して環境を作成します。 たとえば:

olcnectl environment create \
--api-server 127.0.0.1:8091 \
--environment-name myenvironment \
--secret-manager-type file \
--olcne-node-cert-path /etc/olcne/certificates/node.cert \
--olcne-ca-path /etc/olcne/certificates/ca.cert \
--olcne-node-key-path /etc/olcne/certificates/node.key \
--update-config

--api-serverオプションは、Platform API Serverサービスのロケーションを設定します。 この例では、Platform API Serverがオペレータ・ノード(localhost)で実行され、ポート8091でリスニングしています。

--environment-nameオプションは環境の名前を設定します。この例ではmyenvironmentです。

--secret-manager-typeオプションは、ファイルベースの証明書を使用するように証明書マネージャを設定します。

--olcne-node-cert-path、--olcne-ca-path、および--olcne-ca-pathオプションは、証明書ファイルのロケーションを設定します。 証明書ファイルの場所は環境変数を使用することで設定することもできます。環境変数が設定されていると、その設定がolcnectlで使用されます。 次の環境変数は、olcnectl environment createコマンド・オプションにマップされます:

表3.1 証明書オプション

コマンド・オプション	環境変数	用途
--olcne-node-cert-path	$OLCNE_SM_CERT_PATH	ノード証明書のパス。
--olcne-ca-path	$OLCNE_SM_CA_PATH	認証局証明書へのパス。
--olcne-node-key-path	$OLCNE_SM_KEY_PATH	ノード証明書のキーへのパス。

たとえば、同じ環境の環境変数を使用して証明書情報を設定するには、次を使用できます:

export OLCNE_SM_CA_PATH=/etc/olcne/certificates/ca.cert
export OLCNE_SM_CERT_PATH=/etc/olcne/certificates/node.cert
export OLCNE_SM_KEY_PATH=/etc/olcne/certificates/node.key

olcnectl environment create \
--api-server 127.0.0.1:8091 \
--environment-name myenvironment \
--secret-manager-type file \
--update-config 

--update-configオプションは、環境に関する情報を$HOME/.olcne/olcne.confにあるローカル構成ファイルに書き込み、この構成はプラットフォームAPIサーバーへの将来の呼び出しに使用されます。 このオプションを使用する場合は、将来のolcnectlコマンドでPlatform API Server (--api-serverオプションを使用)を指定する必要はありません。 Platform API Serverの設定の詳細は、プラットフォーム・コマンドライン・インタフェースを参照してください。

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

• 3.8.1 Kubernetesモジュールの作成
• 3.8.2 Istioモジュールの作成
• 3.8.3 Operator Lifecycle Managerモジュールの作成
• 3.8.4 Oracle Cloud Infrastructure Container Storage Interfaceモジュールの作成
• 3.8.5 Glusterコンテナ・ストレージ・インタフェース・モジュールの作成

環境を作成した後は、必要なモジュールを環境に追加できます。

3.8.1 Kubernetesモジュールの作成

基本インストールには、Kubernetesクラスタの作成に使用されるKubernetesモジュールが必要です。 Kubernetesモジュールの作成およびインストールの詳細は、コンテナ・オーケストレーションを参照してください。

3.8.2 Istioモジュールの作成

Kubernetesモジュールを作成してインストールした後は、Istioモジュールを使用して必要に応じてサービス・メッシュをインストールできます。 Istioモジュールをインストールしてサービス・メッシュを作成する方法は、サービス・メッシュを参照してください。

3.8.3 Operator Lifecycle Managerモジュールの作成

Kubernetesモジュールを作成してインストールすると、オプションでOperator Lifecycle Managerモジュールをインストールして、Kubernetesクラスタ内のオペレータのインストールおよびライフサイクル管理を管理できます。 Operator Lifecycle Managerモジュールのインストールの詳細は、「コンテナ・オーケストレーション」を参照してください。

3.8.4 Oracle Cloud Infrastructure Container Storage Interfaceモジュールの作成

Kubernetesモジュールを作成してインストールした場合、オプションでOracle Cloud Infrastructure Container Storage Interfaceモジュールをインストールして、Oracle Cloud Infrastructureストレージへのアクセスを設定できます。 これにより、Oracle Cloud Infrastructureブロック・ボリュームを使用して、Kubernetesアプリケーションに永続ストレージを提供できます。 Oracle Cloud Infrastructure Container Storage Interfaceモジュールのインストールの詳細は、「ストレージ」を参照してください。

3.8.5 Glusterコンテナ・ストレージ・インタフェース・モジュールの作成

Kubernetesモジュールを作成してインストールした場合、オプションでGlusterコンテナ・ストレージ・インタフェース・モジュールをインストールして、Glusterストレージへのアクセスを設定できます。 これにより、Glusterクラスタを使用して、Kubernetesアプリケーションに永続ストレージを提供できます。 Gluster Container Storage Interfaceモジュールのインストールの詳細は、「ストレージ」を参照してください。

Copyright © 2019, 2023, Oracle and/or its affiliates.