Kubernetes Service Hatoba適用指針
ドキュメント情報
- 区分
-
適用指針
- リリース日
-
2023年03月30日
- ■ニフクラホームページ
はじめに
-
本ドキュメントではKubernetes Service Hatoba適用指針について記載しています。
-
Kubernetes Service HatobaはKubernetes環境をマネージドサービスとして提供するクラウドサービスです。利用者に共通して提供されている機能やサービスを組み合わせることでシステムを構築します。よって、個別の要望には対応はできません。
-
システム要件によってはKubernetes Service Hatoba適用(移行)不可となる場合があるため、本ドキュメントを最後まで確認のうえ、適用可否を判断してください。
-
本ドキュメントでは、「ダイレクトポート」、「物理ポート」、「プライベートアクセス」の総称として「プライベート接続サービス」という表記をしています。この「プライベート接続サービス」という表現は、ニフクラ上での正式な呼称ではありませんので、注意してください。
-
ニフクラサービスの変更は最新のドキュメントを参照してください。
Note
|
Kubernetes Service Hatoba は、2023年9月14日15:00にサービスの提供を終了します。新規クラスターの受け付けは終了しています。 |
アイコンの説明
-
本ドキュメント構成図に使用されているアイコンは下記のとおりとなります。
-
リージョン及びゾーンについて特に記載がなければ、単一リージョン、単一ゾーン構成を示します。
-
構成図内の名称は略称で記載されている場合があります。(下記()内が略称の例)
適用基準
Kubernetes Service Hatobaを適用できないケース
Kubernetes Service Hatobaを適用できない主な条件を示します。
以下の不適合条件に合致する要求がある場合、ユーザーによるKubernetes環境の構築やオンプレミスの検討が必要です。
不適合条件 |
理由 |
|
---|---|---|
SLA |
SLAとして月間稼働率99.90%を超えるSLA提供が必要 |
1. ニフクラで提供しているSLAの詳細については「 https://pfs.nifcloud.com/sla/ 」を参照してください。
2. 業務システムを含めたSLAについては、利用者側で検討が必要です。
|
冗長性 |
単一のクラスターにて、マルチゾーン/リージョン構成をとる必要がある |
現状では、マルチゾーン/リージョン構成の単一クラスターは作成できません。 |
機能性 |
CNIとしてcanal以外を利用する要件がある |
現状ではcanal以外を導入することはできません。 |
設定柔軟性 |
ノードのkubeletやカーネルパラメーターを設定変更する必要がある |
現状では、ノードのkubeletやカーネルパラメーターを設定変更する機能は存在しません。 |
構成 |
導入後、Kubernetesのバージョンを固定したい |
サービス安定性維持のため、定期的なバージョンアップを実施する必要があります。 [3]
3. 詳細はバージョンアップポリシーを参照
|
IPv6を直接利用する必要がある |
現状、IPv6の利用はできません。 |
|
グローバルネットワークへの接続をしたくない |
現状、グローバルネットワークへの接続を切断することはできません。 |
|
DHCPサーバーがネットワーク上に存在することが許されない |
DHCPサーバーが無い状態ではクラスターが構築できません。 |
Kubernetes Service Hatobaの適用判断
利用者の要件に対応するニフクラサービス仕様(①)を確認し、利用者側で必要となる対処(②)、影響等(③)を検討したうえで、ニフクラ適用可否を判断します。
No. |
要件 |
ニフクラの仕様 |
||
---|---|---|---|---|
大項目 |
中項目 |
小項目 |
||
1.1 |
可用性 |
継続性 |
運用スケジュール |
|
1.2 |
計画停止 |
|
||
1.3 |
SLA |
|
||
1.4 |
自動修復 |
|
||
1.5 |
ノードの耐障害性 |
|
||
1.6 |
災害対策(DR) |
|
||
2.1 |
動作環境 |
Kubernetes |
利用可能なKubernetesのバージョン |
|
2.2 |
ノードスペック |
ノードボリューム容量 |
|
|
2.3 |
永続ブロックボリュームの提供 |
4. 高速フラッシュドライブ、標準フラッシュドライブ
|
||
2.4 |
ネットワーク |
ネットワーク |
|
|
2.5 |
CNIプラグイン |
|
||
2.6 |
ネットワーク |
|
||
2.7 |
HTTPロードバランサー |
|
||
2.8 |
スペック |
ノードスペック |
|
|
2.9 |
ノードスペックの変更 |
|
||
2.10 |
ノード台数の変更 |
|
||
2.11 |
性能品質保証 |
|
||
2.12 |
動作基盤 |
ファイアウォールグループ |
|
|
2.13 |
メモリリソース |
|
||
2.14 |
ノードOS |
|
||
2.15 |
コンテナランタイム |
|
||
2.16 |
インフラリソースへのタグ機能 |
|
||
3.1 |
バージョンアップ |
挙動 |
強制バージョンアップ |
5. 詳細は バージョンアップポリシー を確認してください
|
3.2 |
バージョンアップの保証 |
|
||
3.3 |
バージョンアップの方式 |
|
||
3.4 |
バージョンアップ中のノード挙動 |
|
||
3.5 |
制限 |
バージョンダウン |
|
|
3.6 |
バージョンアップ作業に伴う、ユーザー設定情報の取り扱い |
|
||
4.1 |
保守性 |
サポート体制 |
|
Kubernetes Service Hatobaの制限値一覧
各種制限値の一覧
代表的な制限値は仕様ページをご確認ください
No. |
項目 |
ニフクラの制限値 |
注釈 |
---|---|---|---|
1 |
リージョンあたりの最大クラスター作成数 |
5 |
|
2 |
クラスターあたりの最大ノードプール数 |
10 |
|
3 |
クラスターあたりの最大ノード数 |
10 |
|
4 |
ノードプールあたりの最大ノード数 |
10 |
|
5 |
ノードあたりのローカルストレージ |
30G |
|
6 |
ノードあたりの最大Pod数 |
100 |
|
7 |
ノードあたりの最大ディスク接続可能数 |
14 |
|
8 |
リージョンあたりの最大ファイアウォールグループ作成数 |
25 |
|
9 |
ファイアウォールグループあたりのルール最大数 |
100 |
|
10 |
ディスクあたりの最大ストレージサイズ |
2,000GB(100GBごと) |
|
11 |
リージョンあたりの最大スナップショット作成数 |
50 |
|
12 |
クラスター名の制限 |
半角英数小文字および-で40字以内 |
先頭および末尾に-は利用できません |
13 |
ノードプール名の制限 |
半角英数小文字および-で40字以内 |
|
14 |
スナップショット名の制限 |
半角英数小文字および-で40字以内 |
先頭および末尾に-は利用できません |
15 |
ファイアウォールグループ名の制限 |
半角英数小文字および-で40字以内 |
先頭および末尾に-は利用できません |
16 |
ディスク名の制限 |
半角英数小文字および-で32字以内 |
先頭および末尾に-は利用できません |
17 |
スナップショットメモ長の制限 |
全角半角255文字以内 |
|
18 |
リソースあたりの最大タグ作成数 |
50 |
|
19 |
タグのキーに利用可能な文字長 |
128文字 |
UTF-8が利用可能 |
20 |
タグの値に利用可能な文字長 |
256文字 |
UTF-8が利用可能 |
構成パターン
代表的なシステムパターンは下記のとおりです。
※本パターン以外も実装できます。要件に応じて検討してください。
プライベートLANを利用しない構成
プライベートLANを利用せず、共通プライベートLANを利用する構成です。
適切なファイアウォールルールの設定が必要です。
以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
作業順番 |
利用者が実施すべき作業内容 |
---|---|
1 |
コントロールパネルよりファイアウォールグループを作成します。 |
2 |
コントロールパネルより、クラスターを作成します。 |
3 |
|
4 |
3)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。 |
検討事項
本パターンを構築するための主要検討事項を以下に記載します。
No. |
検討事項 |
対策観点 |
検討内容 |
検討時の重点ポイント |
---|---|---|---|---|
1 |
リージョン障害 |
災害対策(地理的冗長) |
単一のクラスターは単一のリージョンに紐付くため、複数のクラスターを別のリージョンへ展開し、クラスター間で切り替えする方法をユーザーにて検討してください。 |
|
2 |
リージョン障害 |
ネットワーク機器故障(両系) |
ネットワークノードが両系停止し、通信断が発生する場合があります。 |
|
3 |
ローカルディスクアクセス |
ストレージ機器故障(両系コントローラ) |
ストレージコントローラ両系停止による、IO断が発生する場合があります。 |
|
4 |
ノード |
物理サーバーメンテナンス時 |
物理サーバー上の対象ノードをマイグレーションにより別物理サーバーへ移動します。ノードの再起動はありません。 |
|
5 |
ネットワーク装置 |
機器故障(片系)/メンテナンス |
冗長化しているネットワーク装置が片系停止し、一時的な通信断が発生する場合があります。 |
|
6 |
ローカルディスクアクセス |
ストレージ機器故障(片系コントローラ) |
ストレージコントローラ片系停止により、ノードのI/O遅延が発生する場合があります。 |
|
7 |
ノード |
メンテナンス/機器障害 |
ネットワーク機器やストレージコントローラ切り替えにより、ノードの瞬間的な通信断やI/O遅延または断が発生する場合があります。 |
|
8 |
ノード |
クラウド基盤(物理サーバー)障害対策 |
ノードには標準でHA機能が装備されているためノードが稼働している物理サーバーが故障などにより停止した場合、その物理サーバー上で稼働していたノードは自動的に別の物理サーバーへ移動して稼働します。 |
|
9 |
Kubernetes |
クラウド基盤障害対策 |
Kubernetes上で稼働するユーザーサービスについて、サービス側での対策はありません。 |
|
10 |
バックアップ |
クラウド基盤障害/バージョンアップ失敗対策 |
|
|
プライベートLANを利用する構成
プライベートLANを利用する構成です。
以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
作業順番 |
利用者が実施すべき作業内容 |
---|---|
1 |
コントロールパネルよりプライベートLANを作成します。 |
2 |
コントロールパネルよりDHCPコンフィグを作成します。 |
3 |
コントロールパネルよりプライベートLANに接続したルーターを作成します。 |
4 |
コントロールパネルよりファイアウォールグループを作成します。 |
5 |
コントロールパネルより、クラスターを作成します。 |
6 |
|
7 |
6)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。 |
検討事項
本パターンを構築するための主要検討事項を以下に記載します。
No. |
検討事項 |
対策観点 |
検討内容 |
検討時の重点ポイント |
---|---|---|---|---|
1 |
リージョン障害 |
災害対策(地理的冗長) |
単一のクラスターは単一のリージョンに紐付くため、複数のクラスターを別のリージョンへ展開し、クラスター間の切り替えを検討してください。 |
|
2 |
リージョン障害 |
ネットワーク機器故障(両系) |
ネットワークノードが両系停止し、通信断が発生する場合があります。 |
|
3 |
ローカルディスクアクセス |
ストレージ機器故障(両系コントローラ) |
ストレージコントローラ両系停止による、IO断が発生する場合があります。 |
|
4 |
ノード |
物理サーバーメンテナンス時 |
物理サーバー上の対象ノードをマイグレーションにより別物理サーバーへ移動します。ノードの再起動はありません。 |
|
5 |
ネットワーク装置 |
機器故障(片系)/メンテナンス |
冗長化しているネットワーク装置が両系停止し、通信断が発生する場合があります。 |
|
6 |
ローカルディスクアクセス |
ストレージ機器故障(片系コントローラ) |
ストレージコントローラ両系停止による、IO断が発生する場合があります。 |
|
7 |
ノード |
メンテナンス/機器障害 |
ネットワーク機器やストレージコントローラ切り替えによって、ノードも瞬間的な通信断やI/O遅延または断が発生する場合があります。 |
|
8 |
ノード |
クラウド基盤(物理サーバー)障害対策 |
ノードには標準でHA機能が装備されているためノードが稼働している物理サーバーが故障などにより停止した場合、その物理サーバー上で稼働していたノードは自動的に別の物理サーバーへ移動して稼働します。 |
|
9 |
Kubernetes |
クラウド基盤障害対策 |
Kubernetes上で稼働するユーザーサービスについて、サービス側での対策はありません。 |
|
10 |
バックアップ |
クラウド基盤障害/バージョンアップ失敗対策 |
|
|
他サービスとの組み合わせ例
Hatobaはニフクラ上の他サービス/ユーザーシステムと連携できます。
以下に、ニフクラ上の他サービスとの組み合わせ例を示します。
NAS
NASサービスを永続ストレージとして利用する構成となります。
以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
作業順番 |
利用者が実施すべき作業内容 |
---|---|
1 |
コントロールパネルよりプライベートLANを作成します。 |
2 |
コントロールパネルよりDHCPコンフィグを作成します。 |
3 |
コントロールパネルよりプライベートLANに接続したルーターを作成します。 |
4 |
コントロールパネルよりNASファイアウォールグループを作成します。 |
5 |
コントロールパネルよりプライベートLANに接続したNASを作成します。 |
6 |
コントロールパネルよりHatobaのファイアウォールグループを作成します |
7 |
コントロールパネルより、クラスターを作成します。 |
8 |
|
9 |
8)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。 |
10 |
クラスターにデプロイします。方法として二つあります。
|
11 |
テストPVCを作成し、問題なく作成されるか確認します。
|
検討事項
本パターンを構築するための主要検討事項はプライベートLANを利用する構成の検討事項に準じます。
RDB
ニフクラRDBを、データベースとして利用する構成となります。
本手順ではプライベートLANを利用する構成を前提としていますが、必ずしもプライベートLANは必要ではありません。
以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
作業順番 |
利用者が実施すべき作業内容 |
---|---|
1 |
コントロールパネルよりプライベートLANを作成します。 |
2 |
コントロールパネルよりDHCPコンフィグを作成します。 |
3 |
コントロールパネルよりプライベートLANに接続したルーターを作成します。 |
4 |
コントロールパネルよりDBファイアウォールグループを作成します。 |
5 |
コントロールパネルよりプライベートLANに接続したRDBを作成します。 |
6 |
コントロールパネルよりHatobaのファイアウォールグループを作成します |
7 |
コントロールパネルより、クラスターを作成します。 |
8 |
|
9 |
8)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。 |
10 |
RDBをサービス登録します。
|
11 |
|
検討事項
本パターンを構築するための主要検討事項はプライベートLANを利用する構成の検討事項に準じます。
ロードバランサー(L4)
ロードバランサー(L4)を利用し、サービスを外部公開する構成となります。
Serviceのtype:LoadBalancerを利用します。
以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
本手順ではプライベートLANを利用する構成を前提としていますが、必ずしもプライベートLANは必要ではありません。
作業順番 |
利用者が実施すべき作業内容 |
---|---|
1 |
コントロールパネルよりプライベートLANを作成します。 |
2 |
コントロールパネルよりHatobaのファイアウォールグループを作成します |
3 |
コントロールパネルより、クラスターを作成します。 |
4 |
|
5 |
4)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。 |
6 |
ロードバランサー(L4)による振り分け設定を投入します。
|
7 |
テストとして、振り分け先Podを作成します。
|
検討事項
本パターンを構築するための主要検討事項を以下に記載します。
基本的に、プライベートLANを利用する構成の検討事項に準じます。
ここでは、差分のみ記載します。
No. |
検討事項 |
対策観点 |
検討内容 |
検討時の重点ポイント |
---|---|---|---|---|
1 |
稼働監視 |
ロードバランサー(L4)の状態確認 |
ロードバランサー(L4)のAPIでは、Hatobaノードの組込み状態が取得できない。 |
|
2 |
リストア時の挙動 |
ロードバランサー(L4)が振り分け先として選択するノード |
最後に設定を実施したクラスターへのみ振り分けを実施します。複数のクラスターをまたいだ振り分けは実施しません。 |
運用上考慮点とする。 |
ロードバランサー(L4)とKubernetes Service HatobaのHTTPロードバランサーの組み合わせ
ロードバランサー(L4)とIngressロードバランサーを利用し、IngressロードバランサーにてHTTPSを終端し、サービスを外部公開する構成となります。
IngressコントローラーのServiceをtype:LoadBalancerにすることで、ロードバランサー(L4)と連携させます。
以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
本手順ではプライベートLANを利用する構成を前提としていますが、必ずしもプライベートLANは必要ではありません。
作業順番 |
利用者が実施すべき作業内容 |
---|---|
1 |
コントロールパネルよりプライベートLANを作成します。 |
2 |
コントロールパネルよりHatobaのファイアウォールグループを作成します |
3 |
コントロールパネルより、クラスターを作成します。 |
4 |
|
5 |
4)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。 |
6 |
証明書ファイルをクラスターに登録します。(証明書は別途用意してください。)
|
7 |
|
8 |
Ingressコントローラと、ロードバランサー(L4)を組み合わせます。
|
9 |
テストとして、振り分け先Podを作成します。
|
検討事項
本パターンを構築するための主要検討事項を以下に記載します。
基本的に、プライベートLANを利用する構成の検討事項に準じます。
ここでは、差分のみ記載します。
No. |
検討事項 |
対策観点 |
検討内容 |
検討時の重点ポイント |
---|---|---|---|---|
1 |
稼働監視 |
ロードバランサー(L4)の状態確認 |
ロードバランサー(L4)のAPIでは、Hatobaノードの組込み状態が取得できない。 |
|
2 |
リストア時の挙動 |
ロードバランサー(L4)が振り分け先として選択するノード |
最後に設定を実施したクラスターへのみ振り分けを実施します。複数のクラスターをまたいだ振り分けは実施しません。 |
運用上考慮点とする。 |