|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
運用準備完了クラスターのチェックリスト
このセクションでは、アプリやサービスを実行するための運用準備完了のKubernetesクラスターを作成するためのベストプラクティスを推奨します。
OS/Docker、ハードウェア、ネットワークに関する要件を含むクラスターの要件のリストについては、ノード要件のセクションを参照してください。
これは、すべての運用準備完了クラスターに対して強く推奨するベストプラクティスのショートリストです。
推奨するすべてのベストプラクティスの完全なリストについては、ベストプラクティスセクションを参照してください。
ノード要件
-
ノードがすべてのノード要件を満たしていることを確認し、ポート要件も含めてください。
etcdのバックアップ
-
etcdスナップショットを有効にします。スナップショットが作成されていることを確認し、災害復旧シナリオを実行してスナップショットの有効性を検証します。etcdはクラスターの状態が保存される場所であり、etcdデータを失うことはクラスターを失うことを意味します。クラスターのためにetcdの定期的なスナップショットを構成し、スナップショットが外部（ノード外）に保存されることを確認してください。
クラスターアーキテクチャ
-
ノードは次のいずれかの役割構成を持つべきです：
-
etcd -
controlplane -
etcdおよびcontrolplane -
worker（`worker`の役割は`etcd`または`controlplane`の役割を持つノードに使用したり追加したりしてはいけません）
-
-
1つのノードを失っても生き残るために、役割`etcd`を持つノードを少なくとも3つ持つこと。この数を増やして、より高いノードの耐障害性を実現し、さらに良好な耐障害性を提供するために（可用性）ゾーンに分散させます。
-
マスターコンポーネントの高可用性のために、2つ以上のノードに`controlplane`の役割を割り当てます。
-
ノードに障害が発生した場合にワークロードの再スケジューリングを行うために、2つ以上のノードに`worker`の役割を割り当てます。
各役割が何に使用されるかについての詳細は、Kubernetesにおけるノードの役割に関するセクションを参照してください。
各Kubernetes役割のノード数に関する詳細については、推奨アーキテクチャのセクションを参照してください。
ネットワーキング
-
ネットワークの低レイテンシを最小限に抑えます。Rancherは、etcdノード間の低レイテンシを最小限に抑えることを推奨しています。`heartbeat-interval`のデフォルト設定は`500`であり、`election-timeout`のデフォルト設定は`5000`です。これらの etcdチューニングの設定は、ほとんどのネットワーク（非常に高いレイテンシのネットワークを除く）でetcdが動作することを可能にします。
-
クラスタノードは、単一のリージョン内に配置する必要があります。ほとんどのクラウドプロバイダーは、リージョン内に複数のアベイラビリティゾーンを提供しており、これを使用してクラスタの高可用性を高めることができます。複数のアベイラビリティゾーンを使用することは、どの役割のノードにも問題ありません。Kubernetes Cloud Providerリソースを使用している場合は、制限（例：ゾーンストレージの制限）について文書を参照してください。