6 Kubernetesクラスタのスケーリング
Kubernetesクラスタのスケーリングには、クラスタにノードを追加するか、クラスタからノードを削除してクラスタを更新する必要があります。 Kubernetesクラスタにノードを追加する場合は、クラスタをスケール・アップし、クラスタからノードを削除する場合は、クラスタをスケール・ダウンします。
クラスタをスケール・アップする理由には、より大きなワークロードの処理、ネットワーク・トラフィックの増加、またはクラスタ内でより多くのアプリケーションを実行する必要性が含まれる場合があります。 クラスタをスケール・ダウンする理由には、メンテナンスまたはトラブルシューティングのためにノードを一時的に削除することが含まれる場合があります。
新しいノードを追加する前に、そのノードがKubernetesクラスタの一部になるために必要なすべての要件を満たすようにノードを設定する必要があります。 Kubernetesノードの設定の詳細は、「インストール」を参照してください。 クラスタに追加するノードのタイプおよびシステム設定によっては、クラスタ用に構成されたロード・バランサに新しいノードを追加する必要がある場合もあります。
単一のコントロール・プレーン・ノード(たとえば、テスト目的で作成)を持つ環境は、多数のコントロール・プレーン・ノードを持つ高可用性(HA)クラスタにスケール・アップできます(--load-balancer
または--virtual-ip
オプションで作成されている場合)。
Kubernetesクラスタをスケーリングする場合:
-
クラスタをバックアップします。 スケール・アップまたはスケール・ダウンの実行中に問題が発生した場合は、前の状態に戻するようにクラスタをリストアできます。 Kubernetesクラスタのバックアップおよびリストアの詳細は、「Kubernetesクラスタのバックアップおよびリストア」を参照してください。
-
クラスタに追加するノードを検証します。 ノードの検証に問題がある場合(ファイアウォールの問題など)、クラスタの更新が続行できなくなり、そのノードはクラスタに追加できなくなります。 クラスタにノードを追加できるようにするために、検証の問題を解決する操作を求められます。
-
コントロール・プレーン・ノードおよびワーカー・ノードは、クラスタに対して追加または削除されます。
-
クラスタをチェックして、すべてのノードが正常に動作していることを確認します。 クラスタの検証が完了したら、クラスタをスケーリングして、そのクラスタにアクセスします。
Kubernetesクラスタをスケーリングするためのベスト・プラクティス
次のリストでは、本番環境でKubernetesクラスタをスケーリングする際に従うベスト・プラクティスについて説明します:
- 個別のステップでスケール・アップおよびスケール・ダウン
-
1ステップでクラスタをスケール・アップおよびスケール・ダウンしないことをお薦めします: 2つの別々のコマンドでスケール・アップしてからスケール・ダウンします。
- コントロール・プレーン・ノードのスケーリング
-
インのシナリオを回避するには、クラスタ内のコントロール・プレーン・ノードの数は、常に3、5、7などの3以上の奇数である必要があります。 したがって、クラスタ定足数を維持するには、制御ノードを一度に2つのノードにスケールアップおよびスケール・ダウンする必要があります。
メンテナンス操作中に2つのノードを削除する必要がある場合は、クラスタに少なくとも5つのコントロール・プレーン・ノードをプロビジョニングすることをお薦めします。
- ワーカー・ノードのスケーリング
-
クラスタ内のワーカー・ノードを一度に1つのノードに置き換えて、ノードで実行されているアプリケーションを他のノードに移行できるようにします。
クラスタには常に3つ以上のワーカー・ノードが必要です。 したがって、メンテナンス操作中にノードが削除された場合、クラスタには少なくとも4つのワーカー・ノードをプロビジョニングすることをお薦めします。
ヒント:
この章の例では、--control-plane-nodes
および--worker-nodes
オプションを使用してクラスタに含めるすべてのノードを指定することによって、コントロール・プレーン・ノードとワーカー・ノードを同時に変更してスケール・アップおよびスケール・ダウンする方法を示しています。 コントロール・プレーン・ノードのみをスケーリングする場合は、--control-plane-nodes
オプションを使用して、クラスタに含めるコントロール・プレーン・ノードのリストのみを指定する必要があります(ワーカー・ノード・リストを指定する必要はありません)。 同様に、ワーカー・ノードのみをスケーリングする場合は、--worker-nodes
オプションのみを使用してワーカー・ノードのリストを指定します。
Kubernetesクラスタのスケール・アップ
Kubernetesクラスタをスケール・アップする前に、新しいノードをクラスタに追加できるように設定する必要があります。 また、クラスタに追加するノードのタイプおよびシステム設定によっては、クラスタ用に構成されたロード・バランサに新しいノードを追加する必要がある場合もあります。
新しいKubernetesノードの設定
ノードを準備するには:
Load Balancerへの新規ノードの追加
Kubernetesクラスタに外部ロード・バランサ(Kubernetesモジュールの作成時に--load-balancer
オプションで設定)を使用している場合は、新しいコントロール・プレーン・ノードを追加します。 「Oracle Cloud Infrastructureロード・バランサ」を使用している場合は、新しいコントロール・プレーン・ノードを適切なバックエンド・セットに追加し、コントロール・プレーン・ノードのポートを6443
に設定します。 Platform CLIによってデプロイされたロード・バランサ(Kubernetesモジュールの作成時に--virtual-ip option
で設定)を使用している場合は、コントロール・プレーン・ノードを追加する必要はありません。 これは、ノードをクラスタにスケーリングするときに自動的に行われます。
Istioモジュールがインストールされており、Istioイングレス・ゲートウェイのロード・バランサを使用して設定されており、新しいワーカー・ノードを追加する場合は、新しいワーカー・ノードをIstioエグレス・ロード・バランサに追加します。 「Oracle Cloud Infrastructureロード・バランサ」を使用している場合は、新しいワーカー・ノードを適切なバックエンド・セットに追加します。
Kubernetesクラスタへの新規ノードの追加
前の項の準備ステップを完了した後、この手順の手順を使用して、Kubernetesクラスタにノードを追加します。
Kubernetesクラスタをスケール・アップするには:
-
Kubernetesクラスタのコントロール・プレーン・ノードから、
kubectl get nodes
コマンドを使用して、クラスタのコントロール・プレーン・ノードおよびワーカー・ノードを表示します。kubectl get nodes
出力は次のようになります:
NAME STATUS ROLE AGE VERSION control1.example.com Ready control-plane 26h version control2.example.com Ready control-plane 26h version control3.example.com Ready control-plane 26h version worker1.example.com Ready <none> 26h version worker2.example.com Ready <none> 26h version worker3.example.com Ready <none> 26h version
この例では、3つのコントロール・プレーン・ノードがKubernetesクラスタにあります:
-
control1.example.com
-
control2.example.com
-
control3.example.com
また、3つのワーカー・ノードもクラスタ内にあります:
-
worker1.example.com
-
worker2.example.com
-
worker3.example.com
-
-
olcnectl module update
コマンドを使用して、Kubernetesクラスタをスケール・アップします。この例では、推奨される最低5つのコントロール・プレーン・ノードと4つのワーカー・ノードを持つように、Kubernetesクラスタがスケール・アップされます。 この例では、2つの新しいコントロール・プレーン・ノード(
control4.example.com
およびcontrol5.example.com
)と1つの新しいワーカー・ノード(worker4.example.com
)をmycluster
という名前のKubernetesモジュールに追加します。 オペレータ・ノードで次のコマンドを実行します。olcnectl module update \ --environment-name myenvironment \ --name mycluster \ --control-plane-nodes control1.example.com:8090,control2.example.com:8090,control3.example.com:8090,\ control4.example.com:8090,control5.example.com:8090 \ --worker-nodes worker1.example.com:8090,worker2.example.com:8090,worker3.example.com:8090,\ worker4.example.com:8090
必要に応じて、
--generate-scripts
オプションを指定できます。 このオプションでは、スケーリング中に検証が失敗した場合に、ノードごとに実行できるスクリプトが生成されます。 モジュール内の各ノードに対してスクリプトが作成され、ローカル・ディレクトリに保存され、hostname:8090.sh
という名前が付けられます。必要に応じて、
--force
オプションを指定し、クラスタのスケーリングの続行を確認するプロンプトを非表示にすることもできます。オプションで、
--log-level
オプションを使用して、コマンド出力に表示されるロギングのレベルを設定できます。 デフォルトでは、エラー・メッセージが表示されます。 たとえば、次を含めると、すべてのメッセージが表示されるようにロギング・レベルを設定できます:--log-level debug
ログ・メッセージは、操作ログとしても保存されます。 操作ログは、コマンドの実行中または完了時に表示できます。 操作ログの使用方法の詳細は、「プラットフォーム・コマンドライン・インタフェース」を参照してください。
-
Kubernetesクラスタのコントロール・プレーン・ノードで、
kubectl get nodes
コマンドを使用して、クラスタがスケール・アップされ、新しいコントロール・プレーン・ノードおよびワーカー・ノードが含まれることを確認します。kubectl get nodes
出力は次のようになります:
NAME STATUS ROLE AGE VERSION control1.example.com Ready control-plane 26h version control2.example.com Ready control-plane 26h version control3.example.com Ready control-plane 26h version control4.example.com Ready control-plane 2m38s version control5.example.com Ready control-plane 2m38s version worker1.example.com Ready <none> 26h version worker2.example.com Ready <none> 26h version worker3.example.com Ready <none> 26h version worker4.example.com Ready <none> 2m38s version
Kubernetesクラスタのスケール・ダウン
この手順では、Kubernetesクラスタからノードを削除する方法を示します。
注意:
クラスタのコントロール・プレーン・ノードをスケール・ダウンする場合は注意してください。 2つのコントロール・プレーン・ノードがあり、スケール・ダウンしてコントロール・プレーン・ノードを1つのみにすると、シングル・ポイント障害になります。
Kubernetesクラスタをスケール・ダウンするには:
-
Kubernetesクラスタのコントロール・プレーン・ノードから、
kubectl get nodes
コマンドを使用して、クラスタのコントロール・プレーン・ノードおよびワーカー・ノードを表示します。kubectl get nodes
出力は次のようになります:
NAME STATUS ROLE AGE VERSION control1.example.com Ready control-plane 26h version control2.example.com Ready control-plane 26h version control3.example.com Ready control-plane 26h version control4.example.com Ready control-plane 2m38s version control5.example.com Ready control-plane 2m38s version worker1.example.com Ready <none> 26h version worker2.example.com Ready <none> 26h version worker3.example.com Ready <none> 26h version worker4.example.com Ready <none> 2m38s version
この例では、Kubernetesクラスタに5つのコントロール・プレーン・ノードがあります:
-
control1.example.com
-
control2.example.com
-
control3.example.com
-
control4.example.com
-
control5.example.com
クラスタには、4つのワーカー・ノードもあります:
-
worker1.example.com
-
worker2.example.com
-
worker3.example.com
-
worker4.example.com
-
-
olcnectl module update
コマンドを使用して、Kubernetesクラスタをスケール・ダウンします。この例では、Kubernetesクラスタは、コントロール・プレーン・ノードが3つ、ワーカー・ノードが3つになるようにスケール・ダウンされます。 この例では、
mycluster
という名前のKubernetesモジュールから、2つのコントロール・プレーン・ノード(control4.example.com
およびcontrol5.example.com
)と1つのワーカー・ノード(worker4.example.com
)を削除します。 オペレータ・ノードで次のコマンドを実行します。olcnectl module update \ --environment-name myenvironment \ --name mycluster \ --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
-
Kubernetesクラスタのコントロール・プレーン・ノードで、
kubectl get nodes
コマンドを使用して、クラスタがスケール・ダウンされていることを確認し、コントロール・プレーン・ノードおよびワーカー・ノードを削除します。kubectl get nodes
出力は次のようになります:
NAME STATUS ROLE AGE VERSION control1.example.com Ready control-plane 26h version control2.example.com Ready control-plane 26h version control3.example.com Ready control-plane 26h version worker1.example.com Ready <none> 26h version worker2.example.com Ready <none> 26h version worker3.example.com Ready <none> 26h version
-
削除されたノードは、必要なメンテナンスの完了後にスケールアップ操作でクラスタに戻すことができます。 ただし、ノードを新しいノードに置き換える場合は、ロード・バランサから古いノードを削除する必要がある場合があります。 ロード・バランサの詳細は、「Load Balancerへの新規ノードの追加」を参照してください。