Kubernetes Service Hatobaで設定しているSLAについては品質保証制度(SLA)についてを確認してください。 [1]
はじめに
-
本ドキュメントは、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としてニフクラが定める月間稼働率を超えるSLA提供が必要 |
1. 業務システムを含めたSLAについては、利用者側で検討が必要です。
|
冗長性 |
単一のクラスターにて、マルチゾーン/リージョン構成をとる必要がある |
現状では、マルチゾーン/リージョン構成の単一クラスターは作成できません。 |
機能性 |
CNIとしてcanal以外を利用する要件がある |
現状ではcanal以外を導入することはできません。 |
設定柔軟性 |
ノードのkubeletやカーネルパラメーターを設定変更する必要がある |
現状では、ノードのkubeletやカーネルパラメーターを設定変更する機能は存在しません。 |
構成 |
導入後、Kubernetesのバージョンを固定したい |
サービス安定性維持のため、定期的なバージョンアップを実施する必要があります。 [2]
2. 詳細はバージョンアップポリシーを参照
|
IPv6を直接利用する必要がある |
現状、IPv6の利用はできません。 |
|
グローバルネットワークへの接続をしたくない |
現状、グローバルネットワークへの接続を切断することはできません。 |
|
DHCPサーバーがネットワーク上に存在することが許されない |
DHCPサーバーが無い状態ではクラスターが構築できません。 |
|
Kubernetes Service Hatobaの適用判断
利用者の要件に対応するニフクラサービス仕様(①)を確認し、利用者側で必要となる対処(②)、影響等(③)を検討したうえで、ニフクラ適用可否を判断します。
No. |
要件 |
ニフクラの仕様 |
||
|---|---|---|---|---|
大項目 |
中項目 |
小項目 |
||
1.1 |
可用性 |
継続性 |
運用スケジュール |
Kubernetes Service Hatobaは「計画停止及び緊急メンテナンス、障害発生時/アップグレード対応」を除いて24時間365日無停止で稼働します。
|
1.2 |
SLA |
月間稼働率:ニフクラにおけるサービス品質の水準としてKubernetes Service HatobaのSLAを定めています。 |
||
1.3 |
自動修復 |
Kubernetes Service Hatobaで作成されたクラスターはノードの異常が検知された場合に、自動的にノードの修復操作が行われます。詳細は仕様ページを確認してください。 |
||
1.4 |
ノードの耐障害性 |
IaaSサーバーと同等の耐障害性となります。詳細はニフクラの可用性向上への取り組みを参照してください。 |
||
1.5 |
災害対策(DR) |
リージョン・ゾーンを越えたクラスターは構成できません。 リージョン・ゾーンの障害も考慮が必要な場合は、Kubernetes Service Hatoba以外を検討をしてください。 |
||
2.1 |
動作環境 |
Kubernetes |
利用可能なKubernetesのバージョン |
利用可能なバージョンは決まっているため、仕様ページを確認してください。 |
2.2 |
ノードスペック |
ノードスペック |
|
|
2.3 |
性能品質保証 |
|
||
2.4 |
ノードボリューム容量 |
|
||
2.5 |
永続ブロックボリュームの提供 |
|
||
2.6 |
ネットワーク |
ネットワーク |
||
2.7 |
動作基盤 |
ノード |
|
|
2.8 |
ファイアウォールグループ |
|
||
2.9 |
インフラリソースへのタグ機能 |
|
||
3.1 |
バージョンアップ |
バージョンアップについて |
|
|
4.1 |
保守性 |
サポート体制 |
|
|
Kubernetes Service Hatobaの制限値一覧
以下の代表的な制限値は仕様ページをご確認ください
-
リージョンあたりの最大クラスター作成数
-
クラスターあたりの最大ノードプール数
-
クラスターあたりの最大ノード数
-
ノードプールあたりの最大ノード数
-
ノードあたりのローカルストレージ
-
ノードあたりの最大Pod数
-
ノードあたりの最大ディスク接続可能数
-
リージョンあたりの最大ファイアウォールグループ作成数
-
ファイアウォールグループあたりのルール最大数
-
ディスクあたりの最大ストレージサイズ
-
リージョンあたりの最大スナップショット作成数
-
クラスター名の制限
-
ノードプール名の制限
-
スナップショット名の制限
-
ファイアウォールグループ名の制限
-
ディスク名の制限
-
スナップショットメモ長の制限
-
リソースあたりの最大タグ作成数
-
タグのキーに利用可能な文字長
-
タグの値に利用可能な文字長
構成パターン
代表的なシステムパターンは下記のとおりです。
※本パターン以外も実装できます。要件に応じて検討してください。
プライベートLANを利用しない構成
プライベートLANを利用せず、共通プライベートLANを利用する構成です。
適切なファイアウォールルールの設定が必要です。
以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
作業順番 |
利用者が実施すべき作業内容 |
|---|---|
1 |
コントロールパネルよりファイアウォールグループを作成します。 |
2 |
コントロールパネルより、クラスターを作成します。 |
3 |
kubectlを実行できる環境を用意し、作成したノードへ接続するためのクレデンシャルを設定します。 |
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 |
kubectlを実行できる環境を用意し、作成したノードへ接続するためのクレデンシャルを設定します。 |
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 |
kubectlを実行できる環境を用意し、作成したノードへ接続するためのクレデンシャルを設定します。 |
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 |
kubectlを実行できる環境を用意し、作成したノードへ接続するためのクレデンシャルを設定します。 |
9 |
8)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。 |
10 |
RDBをサービス登録します。
|
11 |
|
検討事項
本パターンを構築するための主要検討事項はプライベートLANを利用する構成の検討事項に準じます。
ロードバランサー(L4)
ロードバランサー(L4)を利用し、サービスを外部公開する構成となります。
Serviceのtype:LoadBalancerを利用します。
以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
本手順ではプライベートLANを利用する構成を前提としていますが、必ずしもプライベートLANは必要ではありません。
作業順番 |
利用者が実施すべき作業内容 |
|---|---|
1 |
コントロールパネルよりプライベートLANを作成します。 |
2 |
コントロールパネルよりHatobaのファイアウォールグループを作成します |
3 |
コントロールパネルより、クラスターを作成します。 |
4 |
kubectlを実行できる環境を用意し、作成したノードへ接続するためのクレデンシャルを設定します。 |
5 |
4)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。 |
6 |
ロードバランサー(L4)による振り分け設定を投入します。
|
7 |
テストとして、振り分け先Podを作成します。
|
検討事項
本パターンを構築するための主要検討事項を以下に記載します。
基本的に、プライベートLANを利用する構成の検討事項に準じます。
ここでは、差分のみ記載します。
No. |
検討事項 |
対策観点 |
検討内容 |
検討時の重点ポイント |
|---|---|---|---|---|
1 |
稼働監視 |
ロードバランサー(L4)の状態確認 |
ロードバランサー(L4)のAPIでは、Hatobaノードの組込み状態が取得できない。 |
Hatobaで用意されているAPIを利用してください。 |
2 |
リストア時の挙動 |
ロードバランサー(L4)が振り分け先として選択するノード |
最後に設定を実施したクラスターへのみ振り分けを実施します。複数のクラスターをまたいだ振り分けは実施しません。 |
運用上考慮点とする。 |
ロードバランサー(L4)とKubernetes Service HatobaのHTTPロードバランサーの組み合わせ
ロードバランサー(L4)とIngressロードバランサーを利用し、IngressロードバランサーにてHTTPSを終端し、サービスを外部公開する構成となります。
IngressコントローラーのServiceをtype:LoadBalancerにすることで、ロードバランサー(L4)と連携させます。
以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
本手順ではプライベートLANを利用する構成を前提としていますが、必ずしもプライベートLANは必要ではありません。
作業順番 |
利用者が実施すべき作業内容 |
|---|---|
1 |
コントロールパネルよりプライベートLANを作成します。 |
2 |
コントロールパネルよりHatobaのファイアウォールグループを作成します |
3 |
コントロールパネルより、クラスターを作成します。 |
4 |
kubectlを実行できる環境を用意し、作成したノードへ接続するためのクレデンシャルを設定します。 |
5 |
4)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。 |
6 |
証明書ファイルをクラスターに登録します。(証明書は別途用意してください。)
|
7 |
|
8 |
Ingressコントローラと、ロードバランサー(L4)を組み合わせます。
|
9 |
テストとして、振り分け先Podを作成します。
|
検討事項
本パターンを構築するための主要検討事項を以下に記載します。
基本的に、プライベートLANを利用する構成の検討事項に準じます。
ここでは、差分のみ記載します。
No. |
検討事項 |
対策観点 |
検討内容 |
検討時の重点ポイント |
|---|---|---|---|---|
1 |
稼働監視 |
ロードバランサー(L4)の状態確認 |
ロードバランサー(L4)のAPIでは、Hatobaノードの組込み状態が取得できない。 |
Hatobaで用意されているAPIを利用してください。 |
2 |
リストア時の挙動 |
ロードバランサー(L4)が振り分け先として選択するノード |
最後に設定を実施したクラスターへのみ振り分けを実施します。複数のクラスターをまたいだ振り分けは実施しません。 |
運用上考慮点とする。 |


