このドキュメントで説明されているソフトウェアは、サポートされなくなったか、拡張サポートされています。
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 ノードの設定

この項では、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 7で、次のように入力します。 

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

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

    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の構成オプションの詳細は、4.1「Platform API Serverの構成」を参照してください。

3.2.2 Kubernetesノードの設定

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

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

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

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

    sudo yum install olcne-agent olcne-utils

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

    sudo dnf 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 高可用性クラスタのロード・バランサの設定

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

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

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

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

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

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

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

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

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

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

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

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です。

  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証明書の設定

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/configs/certificates/production/ディレクトリを使用します。 次に例を示します。

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

  • ノードのキー: /etc/olcne/configs/certificates/production/node.key

  • ノードの証明書: /etc/olcne/configs/certificates/production/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-transfer-certs.sh)も作成されます。 gen-certs-helper.shスクリプトを/etc/olcneディレクトリから実行すると、このマニュアルで使用しているデフォルトの証明書ディレクト(/etc/olcne/certificates/)が、olcne-transfer-certs.shスクリプトの作成時に使用されます。 つまり、このマニュアルで示すとおりのデフォルトの証明書ディレクトリの場所を使用して、Platform API ServerとKubernetesノード上のPlatform Agentを起動できるようになるということです。 また、--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

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

    /path/configs/certificates/tmp-olcne/node/

    pathは、gen-certs-helper.shスクリプトを実行したディレクトリか、--cert-dirオプションで設定した場所です。nodeは、生成された証明書の対象ノードの名前です。

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

    /path/configs/certificates/production/

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

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

    このマニュアルの例では、ノード上の証明書の場所として/etc/olcne/configs/certificates/production/ディレクトリを使用します。

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

    重要

    鍵なしSSHを設定する場合、このスクリプト内のUSER変数は、鍵なしSSHで設定するユーザーに変更してください。

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

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

  4. Platform API ServerまたはPlatform Agentを実行する各ノードのolcneユーザーが、証明書のコピー先ディレクトリを読取りできるようにします。 証明書のデフォルト・パス/etc/olcne/certificates/を使用すると、olcneユーザーは読取りアクセスが可能です。

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

    sudo -u olcne ls /path/configs/certificates/production
    
ca.cert  node.cert  node.key

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

3.4.3.2 追加の証明書の作成

この項では、Kubernetesクラスタに追加する追加ノードの証明書の生成について説明します。

プライベート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 /path/configs/certificates/production/ca.cert \
--byo-ca-key /path/configs/certificates/production/ca.key

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

    /path/configs/certificates/production/

    pathは、最初にgen-certs-helper.shスクリプトを実行したディレクトリ(多くの場合は/etc/olcne)、または--cert-dirオプションを使用して設定した場所(そのオプションを使用した場合)です。

  2. 新しい証明書を生成した後、それらをノードにコピーします。 証明書をノードにコピーする際に利用できるスクリプト/path/configs/certificates/olcne-transfer-certs.shが作成されます。 このスクリプトを使用して必要に応じて変更することも、別の方法で証明書をノードにコピーすることもできます。

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

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

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

重要

Oracle Cloud Native Environmentリリース1.2.0を使用している場合は、このセクションのステップを実行する必要はありません。 この項の設定ステップは、リリース1.2.2以上用です。

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

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/configs/certificates/restrict_external_ip/production/ca.cert

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

  • ノード証明書: /etc/olcne/configs/certificates/restrict_external_ip/production/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/configs/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/configs/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証明書および秘密キーを使用できます。 たとえば、次の行をコマンドに追加します: 

--byo-ca-cert /path/configs/certificates/production/ca.cert \
--byo-ca-key /path/configs/certificates/production/ca.key

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

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

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

この項では、クラスタ内でノード上の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 /etc/olcne/configs/certificates/production/ca.cert \
--olcne-node-cert-path /etc/olcne/configs/certificates/production/node.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 vault \
--vault-token s.3QKNuRoTqLbjXaGBOmO6Psjh \
--vault-address https://192.0.2.20:8200 \
--force-download-certs \
--olcne-component agent

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

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

    systemctl status olcne-agent.service

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

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

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

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

    sudo /etc/olcne/bootstrap-olcne.sh \
--secret-manager-type file \
--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 \
--olcne-component api-server

    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-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 \
--olcne-component agent

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

    systemctl status olcne-agent.service

3.7 環境の作成

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

ノート

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

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

この項では、環境の作成に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 --api-server 127.0.0.1:8091 environment create \
--environment-name myenvironment \
--update-config \
--secret-manager-type vault \
--vault-token s.3QKNuRoTqLbjXaGBOmO6Psjh \
--vault-address https://192.0.2.20:8200

--update-configオプションにより、Vaultで生成した証明書をローカル・ホストに保存します。 このオプションを使用すると、環境を管理するときに、証明書の情報を再入力する必要がなくなります。 このオプションでは、Platform API Serverの接続情報も保存されます。 環境への接続時に、この情報を再度指定する必要はありません。 つまり、次回環境に接続するときに、--api-serverオプションを指定する必要はありません。 Platform API Serverの設定の詳細は、プラットフォーム・コマンドライン・インタフェースを参照してください。

--secret-manager-typeオプションは、証明書マネージャをVaultに設定します。 --vault-tokenは、Vaultにアクセスするためのトークンに置き換えてください。 --vault-addressは、Vaultインスタンスの場所に置き換えてください。

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

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

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

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

オペレータ・ノードで、olcnectl environment createコマンドを使用して環境を作成します。 次に例を示します。 

olcnectl --api-server 127.0.0.1:8091 environment create \
--environment-name myenvironment \
--update-config \
--secret-manager-type file \
--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

--update-configオプションは、Platform API Serverの接続情報を保存します。 環境への接続時に、この情報を再度指定する必要はありません。 つまり、次回環境に接続するときに、--api-serverオプションを指定する必要はありません。 Platform API Serverの設定の詳細は、プラットフォーム・コマンドライン・インタフェースを参照してください。

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

証明書ファイルの場所は環境変数を使用することで設定することもできます。環境変数が設定されていると、その設定がolcnectlで使用されます。

環境変数は、olcnectl environment createコマンドの次のオプションにマップされます。

  • $OLCNE_SM_CERT_PATHでは、--olcne-node-cert-pathオプションに使用する値を設定します。

  • $OLCNE_SM_CA_PATHでは、--olcne-ca-pathオプションに使用する値を設定します。

  • $OLCNE_SM_KEY_PATHでは、--olcne-node-key-pathオプションに使用する値を設定します。

次に例を示します。 

export OLCNE_SM_CA_PATH=/etc/olcne/configs/certificates/production/ca.cert
export OLCNE_SM_CERT_PATH=/etc/olcne/configs/certificates/production/node.cert
export OLCNE_SM_KEY_PATH=/etc/olcne/configs/certificates/production/node.key
olcnectl --api-server 127.0.0.1:8091 environment create --environment-name myenvironment \
--update-config \
--secret-manager-type file

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

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

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モジュールのインストールの詳細は、「コンテナ・オーケストレーション」を参照してください。

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