2 Kubernetesクラスタの作成
この章では、プラットフォームCLI (olcnectl
)を使用してKubernetesクラスタを作成する方法を示します。 この章では、Oracle Cloud Native Environmentソフトウェア・パッケージをノードにインストールし、クラスタで使用するように構成し、「インストール」で説明するようにKubernetesモジュールをインストールする環境を作成していることを前提としています。
Kubernetesクラスタを作成する高レベルのステップは次のとおりです。
-
クラスタに関する情報を指定するKubernetesモジュールを作成します。
-
Kubernetesモジュールを検証して、Kubernetesをノードにインストールできることを確認します。
-
Kubernetesモジュールをインストールして、Kubernetesパッケージをノードにインストールし、クラスタを作成します。
これらのステップを実行するには、olcnectl
コマンドを使用します。 olcnectl
コマンドの構文の詳細は、「プラットフォーム・コマンドライン・インタフェース」を参照してください。
ヒント:
構成ファイルを使用してモジュールを作成することもできます。 構成ファイルは、デプロイする環境およびモジュールに関する情報を含むYAMLファイルです。 構成ファイルを使用すると、olcnectl
コマンドの指定に必要な情報が削減されます。 構成ファイルの作成および使用の詳細は、「プラットフォーム・コマンドライン・インタフェース」を参照してください。
Kubernetes CNIの設定
次のKubernetesコンテナ・ネットワーク・インタフェース(CNI)プラグインを使用して、ポッド・ネットワーク・トラフィックを管理できます:
-
Flannel: Kubernetesモジュールを作成する場合、FlannelはデフォルトのCNIです。 Flannelがデフォルトでインストールされているため、Flannelを使用するためにコマンド・オプションを設定する必要はありません。
-
Calico: Calicoは、Flannelの代わりに使用できるオプションのCNIです。
olcnectl module create --module kubernetes
コマンドの--pod-network calico
オプションを使用して、Kubernetesモジュールを作成するときに、CalicoをCNIとして設定できます。 これにより、CalicoがFlannelではなくKubernetes CNIとして設定されます。 このインストール・メソッドでは、Calicoに最小デフォルト構成が使用されます。 オプションで、Calicoをモジュールとしてインストールできます。 Calicoをモジュールとしてインストールするには、Kubernetesモジュールの作成時に--pod-network none
を設定して、Kubernetesのデプロイ時にCNIが設定されないようにします。 Calicoの詳細、およびモジュールとしてインストールする方法については、「Calicoモジュール」を参照してください。重要:
CalicoをKubernetes CNIとして設定するには、まず「Calicoモジュール」で前提条件を実行する必要があります
-
Multus: Multusは、FlannelまたはCalicoへのネットワーキング・ブリッジを作成するオプションのCNIです。 Multusは、Kubernetesモジュールのインストール後にMultusモジュールを使用して設定できます。 Multusの詳細およびモジュールのインストール方法については、「Multusモジュール」を参照してください。
Kubernetesモジュールの作成
Kubernetesモジュールは、次のクラスタを作成するように設定できます。
-
外部ロード・バランサを備えた高可用性(HA)クラスタ
-
内部ロード・バランサを備えたHAクラスタ
-
単一のコントロール・プレーン・ノードを持つクラスタ(HAなし)。
HAクラスタを作成するには、少なくとも3つのコントロール・プレーン・ノードと2つのワーカー・ノードが必要です。
外部ロード・バランサの設定、またはPlatform CLIによってインストールされた内部ロード・バランサを使用するためのコントロール・プレーン・ノードの準備の詳細は、「インストール」を参照してください。
HAクラスタ内のコントロール・プレーン・ノードでは、追加のポートを開く必要があります。 HAクラスタに必要なポートを開く方法については、「インストール」を参照してください。
olcne module create
コマンドを使用して、Kubernetesモジュールを作成します。 このコマンドの使用時に必要なオプションをすべて含めない場合は、オプションを指定するよう求められます。 Kubernetesモジュールで使用可能なオプションの完全なリストは、プラットフォーム・コマンドライン・インタフェースを参照してください。
外部ロード・バランサを使用した高可用性クラスタの作成
この項では、外部ロード・バランサを使用してHAクラスタを作成するために、Kubernetesモジュールを作成する方法について説明します。
次の例では、ホストlb.example.com
で使用可能なロード・バランサを使用し、ポート6443
でリスニングするHAクラスタを作成します。
olcnectl module create \
--environment-name myenvironment \
--module kubernetes \
--name mycluster \
--container-registry container-registry.oracle.com/olcne \
--load-balancer lb.example.com:6443 \
--control-plane-nodes control1.example.com:8090,control2.example.com:8090,control3.example.com:8090 \
--worker-nodes worker1.example.com:8090,worker2.example.com:8090,worker3.example.com:8090,worker4.example.com:8090 \
--selinux enforcing \
--restrict-service-externalip-ca-cert /etc/olcne/certificates/restrict_external_ip/ca.cert \
--restrict-service-externalip-tls-cert /etc/olcne/certificates/restrict_external_ip/node.cert \
--restrict-service-externalip-tls-key /etc/olcne/certificates/restrict_external_ip/node.key
--environment-name
は、Kubernetesモジュールを作成する環境の名前を設定します。 この例では、myenvironment
に設定します。
--module
オプションは、作成するモジュールのタイプを設定します。 Kubernetesモジュールを作成するには、これをkubernetes
に設定する必要があります。
--name
オプションは、Kubernetesモジュールの識別に使用する名前を設定します。 この例では、mycluster
に設定します。
--container-registry
オプションでは、Kubernetesイメージを取得するコンテナ・レジストリを指定します。 この例では、Oracle Container Registryを使用しますが、Oracle Container Registryミラー、またはOracle Container Registryからミラー化されたKubernetesイメージを持つローカル・レジストリも使用できます。 Oracle Container Registryミラーの使用、またはローカル・レジストリの作成の詳細は、「インストール」を参照してください。
ただし、Kubernetesモジュールの更新またはアップグレード中に、新しいデフォルトのコンテナ・レジストリ値を設定できます。
--load-balancer
オプションは、外部ロード・バランサのホスト名とポートを設定します。 この例では、lb.example.com:6443
に設定します。
--control-plane-nodes
オプションには、クラスタに含めるコントロール・プレーン・ノードのホスト名またはIPアドレスのカンマ区切りリストと、プラットフォーム・エージェントが使用可能なポート番号が含まれます。 デフォルトのポート番号は8090
です。
ノート:
単一のコントロール・プレーン・ノードを備えた外部ロード・バランサを使用するクラスタを作成できます。 HAおよびフェイルオーバー機能は、クラスタ内の少なくとも3つのコントロール・プレーン・ノードに到達するまで使用できません。 コントロール・プレーン・ノードの数を増やすには、クラスタをスケール・アップします。 クラスタのスケール・アップの詳細は、「Kubernetesクラスタのスケール・アップ」を参照してください。
--worker-nodes
オプションには、クラスタに含めるワーカー・ノードのホスト名またはIPアドレスのカンマ区切りリストと、Platform Agentを使用できるポート番号が含まれます。 ワーカー・ノードがNATゲートウェイの背後にある場合は、ノードのパブリックIPアドレスを使用します。 NATゲートウェイの背後にあるワーカー・ノードのインタフェースには、Kubernetesクラスタからアクセス可能な /32サブネット・マスクを使用するパブリックIPアドレスが必要です。 /32サブネットは、サブネットを1つのIPアドレスに制限し、KubernetesクラスタからのすべてのトラフィックがこのパブリックIPアドレスを流れるようにします(NATの構成の詳細は、「インストール」を参照してください)。 デフォルトのポート番号は8090
です。
コントロール・プレーン・ノードおよびワーカー・ノードでSELinuxがenforcing
モード(OSのデフォルトおよび推奨モード)に設定されている場合、Kubernetesモジュールの作成時に--selinux enforcing
オプションも含める必要があります。
externalip-validation-webhook-service
Kubernetesサービスの証明書のロケーションも含める必要があります。 これらの証明書はオペレータ・ノード上にある必要があります。 --restrict-service-externalip-ca-cert
オプションは、CA証明書のロケーションを設定します。 --restrict-service-externalip-tls-cert
により、ノード証明書のロケーションが設定されます。 --restrict-service-externalip-tls-key
オプションは、ノード・キーのロケーションを設定します。 これらの証明書の設定の詳細は、「インストール」を参照してください。
オプションで、--restrict-service-externalip-cidrs
オプションを使用して、Kubernetesサービスがアクセスできる外部IPアドレスを設定できます。 たとえば:
--restrict-service-externalip-cidrs 192.0.2.0/24,198.51.100.0/24
この例では、許可されるIP範囲は192.0.2.0/24
および198.51.100.0/24
CIDRブロック内です。
ポッドのデフォルトのKubernetes CNIはFlannelです。 オプションで、CNIをCalicoまたはnoneに設定できます。 --pod-network
オプションを使用してポッド・ネットワーキングを設定します。 --pod-network calico
を使用すると、CalicoがFlannelではなくCNIに設定されます。 --pod-network none
を使用すると、CalicoモジュールをインストールできるCNIは設定されません。 Calicoの詳細は、「Calicoモジュール」を参照してください。
必要に応じて、Kubernetesデータ・プレーン(Kubernetesで実行されているポッドで使用されるインタフェース)に使用するネットワーク・インタフェースを設定できます。 デフォルトでは、プラットフォーム・エージェントで使用されるインタフェース(--control-plane-nodes
および--worker-nodes
オプションで設定)は、Kubernetesコントロール・プレーン・ノードとデータ・プレーンの両方に使用されます。 データ・プレーンに使用する別のネットワーク・インタフェースを指定するには、--pod-network-iface
オプションを含めます。 たとえば、--pod-network-iface ens1
です。 これにより、Platform Agentで使用されるネットワーク・インタフェースを使用するコントロール・プレーン・ノードと、別のネットワーク・インタフェース(この例ではens1
)を使用するデータ・プレーンが作成されます。
ノート:
regex式を--pod-network-iface
オプションとともに使用することもできます。 たとえば:
--pod-network-iface "ens[1-5]|eth5"
regexを使用してインタフェース名を設定する場合、カーネルによって返される最初に一致するインタフェースが使用されます。
内部ロード・バランサを使用した高可用性クラスタの作成
この項では、Kubernetesモジュールを作成し、コントロール・プレーン・ノードでPlatform CLIによってインストールされた内部ロード・バランサを使用してHAクラスタを作成する方法を示します。
この例では、Platform CLIによってインストールされた内部ロード・バランサを使用してHAクラスタを作成します。
olcnectl module create \
--environment-name myenvironment \
--module kubernetes \
--name mycluster \
--container-registry container-registry.oracle.com/olcne \
--virtual-ip 192.0.2.100 \
--control-plane-nodes control1.example.com:8090,control2.example.com:8090,control3.example.com:8090 \
--worker-nodes worker1.example.com:8090,worker2.example.com:8090,worker3.example.com:8090,worker4.example.com:8090 \
--selinux enforcing \
--restrict-service-externalip-ca-cert /etc/olcne/certificates/restrict_external_ip/ca.cert \
--restrict-service-externalip-tls-cert /etc/olcne/certificates/restrict_external_ip/node.cert \
--restrict-service-externalip-tls-key /etc/olcne/certificates/restrict_external_ip/node.key
--virtual-ip
オプションは、プライマリ・コントロール・プレーン・ノードに使用される仮想IPアドレスを設定します(たとえば、192.0.2.100
)。 このIPアドレスは、ネットワークで使用可能であり、ネットワーク上のどのホストにも割り当てられていない必要があります。 このIPアドレスは、ロード・バランサによってプライマリ・コントローラとして割り当てられたコントロール・プレーン・ノードに動的に割り当てられます。
コンテナ・レジストリ・ミラーを使用している場合は、--nginx-image
オプションを使用してNGINXイメージのロケーションも設定する必要があります。 このオプションは、次の形式でレジストリ・ミラーのロケーションに設定する必要があります:
registry:port/olcne/nginx:version
たとえば:
--nginx-image myregistry.example.com:5000/olcne/nginx:1.17.7
この例で使用されているその他のオプションについては、「外部Load Balancerを使用したHAクラスタの作成」を参照してください。
単一のコントロール・プレーン・ノードを使用したクラスタの作成
この項では、単一のコントロール・プレーン・ノードを備えたクラスタを作成するためのKubernetesモジュールを作成する方法を示します。 このタイプのクラスタではロード・バランサは使用されず、必要ありません。
この例では、単一のコントロール・プレーン・ノード備えたクラスタを作成します。
olcnectl module create \
--environment-name myenvironment \
--module kubernetes --name mycluster \
--container-registry container-registry.oracle.com/olcne \
--control-plane-nodes control1.example.com:8090 \
--worker-nodes worker1.example.com:8090,worker2.example.com:8090 \
--selinux enforcing \
--restrict-service-externalip-ca-cert /etc/olcne/certificates/restrict_external_ip/ca.cert \
--restrict-service-externalip-tls-cert /etc/olcne/certificates/restrict_external_ip/node.cert \
--restrict-service-externalip-tls-key /etc/olcne/certificates/restrict_external_ip/node.key
--control-plane-nodes
オプションにはノードを1つだけ含める必要があります。
この例で使用されているその他のオプションについては、「外部Load Balancerを使用したHAクラスタの作成」を参照してください。
Kubernetesモジュールの検証
環境にKubernetesモジュールを作成したら、モジュールをインストールするようにノードが正しく構成されていることを検証します。
olcnectl module validate
コマンドを使用して、ノードが正しく構成されていることを検証します。 たとえば、myenvironment
環境でmycluster
という名前のKubernetesモジュールを検証するには:
olcnectl module validate \
--environment-name myenvironment \
--name mycluster
オプションで、--log-level
オプションを使用して、コマンド出力に表示されるロギングのレベルを設定できます。 デフォルトでは、エラー・メッセージが表示されます。 たとえば、次を含めると、すべてのメッセージが表示されるようにロギング・レベルを設定できます:
--log-level debug
ログ・メッセージは、操作ログとしても保存されます。 操作ログは、コマンドの実行中または完了時に表示できます。 操作ログの使用方法の詳細は、「プラットフォーム・コマンドライン・インタフェース」を参照してください。
検証エラーが返された場合、ノードの修正に必要なコマンドが出力に表示されます。 コマンドをスクリプトとして保存するには、--generate-scripts
オプションを使用します。 たとえば:
olcnectl module validate \
--environment-name myenvironment \
--name mycluster \
--generate-scripts
モジュール内の各ノードに対してスクリプトが作成され、ローカル・ディレクトリに保存され、hostname:8090.sh
という名前が付けられます。 このスクリプトを該当するノードにコピーして実行することで、検証エラーを修正できます。
Kubernetesモジュールのインストール
Kubernetesモジュールを作成して検証した後は、これを使用してKubernetesをノードにインストールし、クラスタを作成します。
olcnectl module install
コマンドを使用して、クラスタを作成するためのノードにKubernetesをインストールします。
Kubernetesモジュールのインストールの一環として次のことが実行されます。
-
Kubernetesパッケージがノードにインストールされます。
kubeadm
パッケージにより、CRI-OとKata Containersの実行に必要なパッケージがインストールされます。 CRI-Oは、コンテナをランタイム・エンジン(runc
またはkata-runtime
のどちらか)に委託するために必要です。 コンテナ・ランタイムの詳細は、コンテナ・ランタイムを参照してください。 -
crio
サービスとkubelet
サービスが有効化および起動されます。 -
内部ロード・バランサをインストールする場合、コントロール・プレーン・ノードで
olcne-nginx
およびkeepalived
サービスが有効化され、起動されます。
たとえば、myenvironment
環境でmycluster
というKubernetesモジュールを使用してクラスタを作成するには、次のコマンドを使用します。
olcnectl module install \
--environment-name myenvironment \
--name mycluster
オプションで、--log-level
オプションを使用して、コマンド出力に表示されるロギングのレベルを設定できます。 デフォルトでは、エラー・メッセージが表示されます。 たとえば、次を含めると、すべてのメッセージが表示されるようにロギング・レベルを設定できます:
--log-level debug
ログ・メッセージは、操作ログとしても保存されます。 操作ログは、コマンドの実行中または完了時に表示できます。 操作ログの使用方法の詳細は、「プラットフォーム・コマンドライン・インタフェース」を参照してください。
Kubernetesモジュールを使用してKubernetesがノードにインストールされ、クラスタが起動して健全性が検証されます。
重要:
Kubernetesのインストールが完了するまでに数分かかる場合があります。
Kubernetesモジュールに関する情報のレポート
Kubernetesモジュールをインストールしたら、Kubernetesモジュールとそのプロパティに関する情報を確認できます。
olcnectl module report
コマンドを使用して、モジュールに関する情報を確認します。
たとえば、次のコマンドを使用して、myenvironment
のmycluster
という名前のKubernetesモジュールを確認します:
olcnectl module report \
--environment-name myenvironment \
--name mycluster \
--children
olcnectl module report
コマンドの構文の詳細は、「プラットフォーム・コマンドライン・インタフェース」を参照してください。