本文へジャンプします。

TOP

ニフクラSEハンドブック

クラウド トップ>SEハンドブック>Kubernetes Service Hatoba適用指針

Kubernetes Service Hatoba適用指針

ドキュメント情報

区分

適用指針

リリース日

2023年03月30日

■ニフクラホームページ

https://pfs.nifcloud.com/

はじめに

  • 本ドキュメントではKubernetes Service Hatoba適用指針について記載しています。

  • Kubernetes Service HatobaはKubernetes環境をマネージドサービスとして提供するクラウドサービスです。利用者に共通して提供されている機能やサービスを組み合わせることでシステムを構築します。よって、個別の要望には対応はできません。

  • システム要件によってはKubernetes Service Hatoba適用(移行)不可となる場合があるため、本ドキュメントを最後まで確認のうえ、適用可否を判断してください。

  • 本ドキュメントでは、「ダイレクトポート」、「物理ポート」、「プライベートアクセス」の総称として「プライベート接続サービス」という表記をしています。この「プライベート接続サービス」という表現は、ニフクラ上での正式な呼称ではありませんので、注意してください。

  • ニフクラサービスの変更は最新のドキュメントを参照してください。

Note
Kubernetes Service Hatoba は、2023年9月14日15:00にサービスの提供を終了します。新規クラスターの受け付けは終了しています。
アイコンの説明
  • 本ドキュメント構成図に使用されているアイコンは下記のとおりとなります。

  • リージョン及びゾーンについて特に記載がなければ、単一リージョン、単一ゾーン構成を示します。

  • 構成図内の名称は略称で記載されている場合があります。(下記()内が略称の例)

image image

適用基準

Kubernetes Service Hatobaを適用できないケース

Kubernetes Service Hatobaを適用できない主な条件を示します。
以下の不適合条件に合致する要求がある場合、ユーザーによるKubernetes環境の構築やオンプレミスの検討が必要です。


不適合条件

理由

SLA

SLAとして月間稼働率99.90%を超えるSLA提供が必要

Kubernetes Service Hatobaで設定しているSLAでは、月間稼働率が99.90%となります。 [1] [2]


1. ニフクラで提供しているSLAの詳細については「 https://pfs.nifcloud.com/sla/ 」を参照してください。
2. 業務システムを含めたSLAについては、利用者側で検討が必要です。

冗長性

単一のクラスターにて、マルチゾーン/リージョン構成をとる必要がある

現状では、マルチゾーン/リージョン構成の単一クラスターは作成できません。

機能性

CNIとしてcanal以外を利用する要件がある

現状ではcanal以外を導入することはできません。

設定柔軟性

ノードのkubeletやカーネルパラメーターを設定変更する必要がある

現状では、ノードのkubeletやカーネルパラメーターを設定変更する機能は存在しません。

構成

導入後、Kubernetesのバージョンを固定したい

サービス安定性維持のため、定期的なバージョンアップを実施する必要があります。 [3]

IPv6を直接利用する必要がある

現状、IPv6の利用はできません。

グローバルネットワークへの接続をしたくない

現状、グローバルネットワークへの接続を切断することはできません。

DHCPサーバーがネットワーク上に存在することが許されない

DHCPサーバーが無い状態ではクラスターが構築できません。

Kubernetes Service Hatobaの適用判断

利用者の要件に対応するニフクラサービス仕様(①)を確認し、利用者側で必要となる対処(②)、影響等(③)を検討したうえで、ニフクラ適用可否を判断します。


No.

要件

ニフクラの仕様
(①サービス仕様 ②利用者の対処 ③備考(影響など))

大項目

中項目

小項目

1.1

可用性

継続性

運用スケジュール

  • ①24時間365日無停止。(計画停止/定期保守/即時対応を除く)

  • ②特にありません。

  • ③計画停止/定期保守/即時対応の影響については、No.1.2を参照。

1.2

計画停止

  • ① 非活性メンテナンスの情報は、目安として14日前にコントロールパネル内のお知らせ欄に掲載。緊急メンテナンス時は、掲載や告知がメンテナンスを実施する直前となることがあります。コントロールパネル内の「障害・お知らせ通知」でメールアドレスを登録すれば、メールでも通知されます。
    毎月第3木曜日 午前8時~10時に実施される定期メンテナンス中はコントロールパネルとAPIが利用できません。利用者のサーバーは通常通り利用可能。障害時には、コントロールパネル内のお知らせ欄に情報が掲載されます。こちらも、コントロールパネル内の「障害・お知らせ通知」でメールアドレスを登録すれば、メールでも通知されます。
    コントロールパネルにログインできない、またはサービスアクティビティを利用できない事象が発生している場合は、 ニフクラ 最新イベント/ニュース一覧にて障害の情報を確認可能です。

  • ②通知内容に応じて対応を検討してください。

  • ③特にありません。

1.3

SLA

  • ①月間稼働率:Kubernetes Service HatobaのSLAは、月間稼働率が99.90%となります。

  • ②特にありません。

  • ③稼働率が下回った場合、利用者が請求し、内容が認められることで、当月分の利用料金金額を、翌々月以降ニフクラご利用料金から減額します。
    減額される割合については、「 https://pfs.nifcloud.com/sla/ 」を参照してください。

1.4

自動修復

  • ①約10分以上、ノードの異常が検知された場合に自動修復が行われます。

  • ②検証環境を用意し、事前にバージョンアップテストを実施してください。

  • ③自動修復はノード再起動を実施し、復旧しない場合ノードを削除/追加してください。

1.5

ノードの耐障害性

  • ①IaaSサーバーと同等の耐障害性となります。

  • ②特にありません。

  • ③IaaSでの耐障害性に準じた注意事項を認識してください。

1.6

災害対策(DR)

  • ①リージョン・ゾーンを越えたクラスターは構成できません。

  • ②特にありません。

  • ③リージョン・ゾーンの障害も考慮が必要な場合は、Kubernetes Service Hatoba外にて検討をしてください。

2.1

動作環境

Kubernetes

利用可能なKubernetesのバージョン

  • ①利用可能なバージョンは決まっているため、仕様ページを確認してください。

  • ②運用考慮事項として認識してください。

  • ③特にありません。

2.2

ノードスペック

ノードボリューム容量

  • ①ノードが提供できるボリュームサイズは拡張できません。

  • ②保存可能容量に注意してください。

  • ③30Gを超える容量を保存する場合は、永続ボリュームの利用を検討してください。

2.3

永続ブロックボリュームの提供

  • ①増設ディスク [4]を永続ブロックボリュームとして使用できます。

  • ②クラスター設定変更により、CSIドライバーを導入してください。
    Access TypeはReadWriteOnceのため、ReadOnlyMany/ReadWriteManyが必要な場合はNASを利用してください。

  • ③増設ディスクは、クラスターとは別の料金がかかります。
    増設ディスクが利用可能なリージョンはニフクラ ゾーン別機能対応表を参照してください。
    NASサービスはKubernetesから作成できないため、本ドキュメント記載「他サービスとの組み合わせ例 NAS」のようにユーザーにて設定する必要があります。


4. 高速フラッシュドライブ、標準フラッシュドライブ

2.4

ネットワーク

ネットワーク

  • ①グローバルネットワークへの接続を切断できません。

  • ②適切なファイアウォールグループの設定をする必要があります。

  • ③ファイアウォールグループを適切に設定することで、グローバルからの接続を拒否できます。

2.5

CNIプラグイン

  • ①現状ではcanalのみが利用可能です。

  • ②運用考慮事項として認識してください。

  • ③特にありません。

2.6

ネットワーク

  • ①マルチロードバランサーは外部ロードバランサーとして自動連携できません。

  • ②ロードバランサー(L4)の利用を検討してください。
    プライベート側でロードバランスする必要がある場合は、ルーター経由でグローバルネットワークを経由し、ロードバランサー(L4)へアクセスする構成を検討してください。

  • ③ロードバランサー(L4)のフィルタを利用し、意図しない通信を防いでください。

2.7

HTTPロードバランサー

  • ①クラスターの作成、設定変更で設定されるHTTPロードバランサーは「nginx」となっています。

  • ②コンフィグの作成時に留意してください。

  • ③特にありません。

2.8

スペック

ノードスペック

  • ①利用可能なスペックは 料金一覧を参照してください。

  • ②運用考慮事項として認識してください。

  • ③特にありません。

2.9

ノードスペックの変更

  • ①ノードスペックの変更は、ノードプールの追加、削除が必要です。

  • ②運用考慮事項として認識してください。

  • ③特にありません。

2.10

ノード台数の変更

  • ①ノード台数の変更は活性で実行可能です。

  • ②運用考慮事項として認識してください。

  • ③特にありません。

2.11

性能品質保証

  • ①ノードにはタイプに基づくスペックが割り当てられるが、共用型のため性能はベストエフォートとなります。

  • ②ノードのスケールアップ、スケールアウト、アプリケーションチューニングを実施してください。

  • ③特にありません。

2.12

動作基盤

ファイアウォールグループ

  • ①デフォルトで解放されているOutboundルールが存在します。

  • ②運用考慮事項として認識してください。

  • ③特にありません。

2.13

メモリリソース

  • ①ノードが安定した動作をするために、eviction-hard memory.availableは400Miが設定されています。ノードのメモリ空き容量が400Miの空き容量を確保しようとします。

  • ②Podのメモリ利用量の合計が、ノードリソースから400Mi引いた量となるように注意してください。

  • ③特にありません。

2.14

ノードOS

  • ①ノードイメージはUbuntu 20.04 LTSを利用しています。

  • ②特にありません。

  • ③随時更新されるため、最新情報は 仕様ページ を確認してください。

2.15

コンテナランタイム

  • ①コンテナランタイムはcontainerdを利用しています。

  • ②特にありません。

  • ③随時更新されるため、最新情報は 仕様ページ を確認してください。

2.16

インフラリソースへのタグ機能

  • ①インフラのリソース(クラスター、ノードプール、ファイアウォール、スナップショット)にタグが付与できます。

  • ②特にありません。

  • ③制限値については、制限値ページを確認してください。
    タグ機能は、KubernetesのLabelとは別の機能となります。IaCツールなどでの利用を想定した機能です。

3.1

バージョンアップ

挙動

強制バージョンアップ

  • ①サポート外バージョンになって180日が経過すると、強制的にバージョンアップする対象となります。

  • ②運用考慮事項として、定期的なバージョンアップを取り入れてください。

  • ③強制バージョンアップの結果についてFJCTは関与しません。[5]


5. 詳細は バージョンアップポリシー を確認してください

3.2

バージョンアップの保証

  • ①アップグレードは必ず成功する保証がありません。

  • ②検証環境を用意し、事前にバージョンアップテストを実施してください。
    スナップショット機能などを利用し、クラスターのリストア/再構築に備える必要があります。

  • ③特にありません。

3.3

バージョンアップの方式

  • ①マイナーバージョンアップは1段階ずつ実施する必要があります。(例:1.19→1.21は実施不可)

  • ②こまめなバージョンアップを実施してください。

  • ③特にありません。

3.4

バージョンアップ中のノード挙動

  • ①バージョンアップはローリングアップデートで実施され、一時的にノードがユーザー設定値+1となります。古いバージョンのノードが削除され、最後はすべて新しいノードに入れ替わります。

  • ②動作仕様を理解し、運用考慮事項として取り入れてください。

  • ③削除されるノードはdrainにより、安全に停止されます。(v1.20以降)
    バージョンアップ中に一時的に追加されるノードに関しても課金されます。

3.5

制限

バージョンダウン

  • ①バージョンダウンはできません。

  • ②検証環境を用意し、事前にバージョンアップテストを実施してください。

  • ③特にありません。

3.6

バージョンアップ作業に伴う、ユーザー設定情報の取り扱い

  • ①labelやtaint等のノードに追加設定した値は新規ノードには引き継がれません。

  • ②バージョンアップ後に、再設定する。または、ノードにlabelを設定しないでください。

  • ③特にありません。

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字以内

  • 先頭および末尾に-は利用できません

  • masterという名称は利用できません

14

スナップショット名の制限

半角英数小文字および-で40字以内

先頭および末尾に-は利用できません

15

ファイアウォールグループ名の制限

半角英数小文字および-で40字以内

先頭および末尾に-は利用できません

16

ディスク名の制限

半角英数小文字および-で32字以内

先頭および末尾に-は利用できません

17

スナップショットメモ長の制限

全角半角255文字以内

18

リソースあたりの最大タグ作成数

50

19

タグのキーに利用可能な文字長

128文字

UTF-8が利用可能

20

タグの値に利用可能な文字長

256文字

UTF-8が利用可能

構成パターン

代表的なシステムパターンは下記のとおりです。
※本パターン以外も実装できます。要件に応じて検討してください。

プライベートLANを利用しない構成

プライベートLANを利用せず、共通プライベートLANを利用する構成です。
適切なファイアウォールルールの設定が必要です。


image


以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。

作業順番

利用者が実施すべき作業内容

1

コントロールパネルよりファイアウォールグループを作成します。
作成時に、必ずinルールへkubectlを実行する端末のグローバルIPから6443への接続を追加します。
実施しない場合、kubectlによる操作ができません。
また、共通プライベートLANやグローバルからのアクセスを防ぐため、最低1つのinルールを設定してください。
outルールに関しては任意となります。

2

コントロールパネルより、クラスターを作成します。
このとき、プライベートLANにて「指定しない」を指定することで、共通プライベートLANが利用されます。
また、ファイアウォールグループには、1)で作成したものを指定してください。
クラスター作成と同時に最初のノードプールが作成されますので、ステータスが「稼働中」になるとクラスターの利用が開始できます。

3

kubectlを実行できる環境を用意し、作成したノードへ接続するためのクレデンシャルを設定します。
設定するクレデンシャルは、 クラスター一覧 より対象のクラスターを選択し、クレデンシャル表示 をすることで確認できます。

4

3)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。

検討事項

本パターンを構築するための主要検討事項を以下に記載します。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン障害

災害対策(地理的冗長)

単一のクラスターは単一のリージョンに紐付くため、複数のクラスターを別のリージョンへ展開し、クラスター間で切り替えする方法をユーザーにて検討してください。

  • 障害の影響を最小限に抑えるため、マルチリージョン構成を検討してください。
    マルチリージョン構成によって、計画メンテナンス時でも片側のクラスターでシステムを継続できる可能性が高まります。

  • クラスター間の切り替えはユーザーにて設計をする必要があります。

2

リージョン障害

ネットワーク機器故障(両系)

ネットワークノードが両系停止し、通信断が発生する場合があります。

  • リージョン障害に準じます。

3

ローカルディスクアクセス

ストレージ機器故障(両系コントローラ)

ストレージコントローラ両系停止による、IO断が発生する場合があります。

  • リージョン障害に準じます。

4

ノード

物理サーバーメンテナンス時

物理サーバー上の対象ノードをマイグレーションにより別物理サーバーへ移動します。ノードの再起動はありません。

  • 通常のマイグレーション時は、ネットワーク通信断は発生しません。

5

ネットワーク装置

機器故障(片系)/メンテナンス

冗長化しているネットワーク装置が片系停止し、一時的な通信断が発生する場合があります。

  • スイッチのメンテナンス時における無応答時間を3秒以内に定め運用しております。[6]

  • 上記基準を超えるメンテナンスなどを実施する場合は事前にメンテナンス通知にて告知します。[7]

  • 業務アプリケーションの可用性は別途設計してください。

6

ローカルディスクアクセス

ストレージ機器故障(片系コントローラ)

ストレージコントローラ片系停止により、ノードのI/O遅延が発生する場合があります。

  • ファイルシステムがお客様のシステムにてリードオンリーになるまでの時間を120秒と定め運用しております。[8]

  • 上記基準を超えるメンテナンスなど実施する場合は事前にメンテナンス通知にて告知します。[9]

  • 業務アプリケーションの可用性は別途設計してください。

7

ノード

メンテナンス/機器障害

ネットワーク機器やストレージコントローラ切り替えにより、ノードの瞬間的な通信断やI/O遅延または断が発生する場合があります。

  • スイッチのメンテナンス時における無応答時間を3秒以内に定め運用しております。[10]

  • 上記基準を超えるメンテナンスなどを実施する場合は事前にメンテナンス通知にて告知します。[11]

  • 業務アプリケーションの可用性は別途設計してください。

8

ノード

クラウド基盤(物理サーバー)障害対策

ノードには標準でHA機能が装備されているためノードが稼働している物理サーバーが故障などにより停止した場合、その物理サーバー上で稼働していたノードは自動的に別の物理サーバーへ移動して稼働します。
このため、物理障害についてはHAでの自動復旧が見込めますが、この際ノードは強制シャットダウンで停止し、別物理サーバー上で再起動します。
この場合10分以内に正常状態へ復帰することが期待されるため、自動修復基準に合致しない場合、自動修復は機能せず再度クラスターへ再組込みされます。

  • HAでの自動復旧時3~5分程度(目安)のノード停止+kube-nodeサービスの稼働完了までの間クラスターノード数が減少する。

9

Kubernetes

クラウド基盤障害対策

Kubernetes上で稼働するユーザーサービスについて、サービス側での対策はありません。

  • Kubernetes上で稼働するユーザーサービスについてはユーザーにて適切に運用管理が必要です。

  • ユーザーにてカスタムコントローラなどを利用し、適切に設定してください。

10

バックアップ

クラウド基盤障害/バージョンアップ失敗対策

  • クラスターの設定情報管理については、ユーザーにて適切に保存が必要です。

  • スナップショット機能の活用をご検討ください。

  • スナップショットで保存される情報については 仕様 を確認してください。

    • ニフクラNASを永続ストレージとして利用しており、復元時に復旧が必要な場合はnameを「nifcloud-nas-nfs」にしてください。

  • スナップショットを現存のクラスターへ復旧させることはできません、新規クラスターの作成となります。

プライベートLANを利用する構成

プライベートLANを利用する構成です。


image


以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。


作業順番

利用者が実施すべき作業内容

1

コントロールパネルよりプライベートLANを作成します。

2

コントロールパネルよりDHCPコンフィグを作成します。
必ず自動割り当てIPアドレスとして、作成予定ノード数に対して十分に余裕を持ったIPアドレスを配布できるようにしてください。
バージョンアップ時の一時的なノード数増加に対応する必要があります。

3

コントロールパネルよりプライベートLANに接続したルーターを作成します。
作成時には、DHCPオプションを有効にし、先に作成したDHCPコンフィグを指定してください。

4

コントロールパネルよりファイアウォールグループを作成します。
作成時に、必ずinルールへkubectlを実行する端末のグローバルIPから6443への接続を追加します。
実施しない場合、kubectlによる操作ができません。
また、グローバルからのアクセスを防ぐため、最低1つのinルールを設定してください。
outルールに関しては任意となります。

5

コントロールパネルより、クラスターを作成します。
プライベートLANには先に作成したプライベートLANを指定することで、プライベートLANを利用する形でクラスターが作成されます。
また、ファイアウォールグループには、4)で作成したものを指定してください。
クラスター作成と同時に最初のノードプールが作成されますので、ステータスが「稼働中」になるとクラスターの利用が開始できます。
ノードが「異常」状態となる場合は、DHCPの設定を見直してください。

6

kubectlを実行できる環境を用意し、作成したノードへ接続するためのクレデンシャルを設定します。
設定するクレデンシャルは、 クラスター一覧 より対象のクラスターを選択し、クレデンシャル表示 をすることで確認できます。

7

6)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。

検討事項

本パターンを構築するための主要検討事項を以下に記載します。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン障害

災害対策(地理的冗長)

単一のクラスターは単一のリージョンに紐付くため、複数のクラスターを別のリージョンへ展開し、クラスター間の切り替えを検討してください。

  • 障害の影響を最小限に抑えるため、マルチリージョン構成を検討してください。
    マルチリージョン構成によって、計画メンテナンス時でも片側のクラスターでシステムを継続できる可能性が高まります。

2

リージョン障害

ネットワーク機器故障(両系)

ネットワークノードが両系停止し、通信断が発生する場合があります。

  • リージョン障害に準じます

3

ローカルディスクアクセス

ストレージ機器故障(両系コントローラ)

ストレージコントローラ両系停止による、IO断が発生する場合があります。

  • リージョン障害に準じます

4

ノード

物理サーバーメンテナンス時

物理サーバー上の対象ノードをマイグレーションにより別物理サーバーへ移動します。ノードの再起動はありません。

  • 通常のマイグレーション時は、ネットワーク通信断は発生しません。

5

ネットワーク装置

機器故障(片系)/メンテナンス

冗長化しているネットワーク装置が両系停止し、通信断が発生する場合があります。

  • スイッチのメンテナンス時における無応答時間を3秒以内に定め運用しております。[12]

  • 上記基準を超えるメンテナンスなどを実施する場合は事前にメンテナンス通知にて告知します。[13]

  • 業務アプリケーションの可用性は別途設計してください。

6

ローカルディスクアクセス

ストレージ機器故障(片系コントローラ)

ストレージコントローラ両系停止による、IO断が発生する場合があります。

  • ファイルシステムがお客様のシステムにてリードオンリーになるまでの時間を120秒と定め運用しております。[14]

  • 上記基準を超えるメンテナンスなど実施する場合は事前にメンテナンス通知にて告知します。[15]

  • 業務アプリケーションの可用性は別途設計してください。

7

ノード

メンテナンス/機器障害

ネットワーク機器やストレージコントローラ切り替えによって、ノードも瞬間的な通信断やI/O遅延または断が発生する場合があります。

  • スイッチのメンテナンス時における無応答時間を3秒以内に定め運用しております。[16]

  • 上記基準を超えるメンテナンスなどを実施する場合は事前にメンテナンス通知にて告知します。[17]

  • 業務アプリケーションの可用性は別途設計してください。

8

ノード

クラウド基盤(物理サーバー)障害対策

ノードには標準でHA機能が装備されているためノードが稼働している物理サーバーが故障などにより停止した場合、その物理サーバー上で稼働していたノードは自動的に別の物理サーバーへ移動して稼働します。
このため、物理障害についてはHAでの自動復旧が見込めますが、この際ノードは強制シャットダウンで停止し、別物理サーバー上で再起動します。
この場合10分以内に正常状態へ復帰することが期待されるため、自動修復基準に合致しない場合、自動修復は機能せず再度クラスターへ再組込みされます。

  • HAでの自動復旧時3~5分程度(目安)のノード停止+kube-nodeサービスの稼働完了までの間クラスターノード数が減少します。

9

Kubernetes

クラウド基盤障害対策

Kubernetes上で稼働するユーザーサービスについて、サービス側での対策はありません。

  • Kubernetes上で稼働するユーザーサービスについてはユーザーにて適切に運用管理が必要です。

  • ユーザーにてカスタムコントローラなどを利用し、適切に設定してください。

10

バックアップ

クラウド基盤障害/バージョンアップ失敗対策

  • クラスターの設定情報管理については、ユーザーにて適切に保存が必要です。

  • スナップショット機能の活用をご検討ください。

  • スナップショットで保存される情報については 仕様 を確認してください。

    • ニフクラNASを永続ストレージとして利用しており、復元時に復旧が必要な場合はnameを「nifcloud-nas-nfs」にしてください。

  • スナップショットを現存のクラスターへ復旧させることはできません、新規クラスターの作成となります。

他サービスとの組み合わせ例

Hatobaはニフクラ上の他サービス/ユーザーシステムと連携できます。

image

以下に、ニフクラ上の他サービスとの組み合わせ例を示します。

NAS

NASサービスを永続ストレージとして利用する構成となります。

image


以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。


作業順番

利用者が実施すべき作業内容

1

コントロールパネルよりプライベートLANを作成します。

2

コントロールパネルよりDHCPコンフィグを作成します。
必ず自動割り当てIPアドレスとして、作成予定ノード数に対して十分に余裕を持ったIPアドレスを配布できるようにしてください。
バージョンアップ時の一時的なノード数増加に対応する必要があります。

3

コントロールパネルよりプライベートLANに接続したルーターを作成します。
作成時には、DHCPオプションを有効にし、先に作成したDHCPコンフィグを指定してください。

4

コントロールパネルよりNASファイアウォールグループを作成します。
作成後、ルール変更にて2)でノードへ配布するレンジとしたIP帯を追加し、NFSマウントできるようにしてください。

5

コントロールパネルよりプライベートLANに接続したNASを作成します。
プロトコルはNFS、NASファイアウォールグループには4)で作成したファイアウォールグループを指定してください。
また、付与するIPアドレスは2)で指定した自動払い出しのIP帯を避けたものとしてください。

6

コントロールパネルよりHatobaのファイアウォールグループを作成します
作成時に、必ずinルールへkubectlを実行する端末のグローバルIPから6443への接続を追加します。
実施しない場合、kubectlによる操作ができません。
また、グローバルからのアクセスを防ぐため、最低1つのinルールを設定してください。
outルールに関しては任意となりますが、outルールを指定する場合はNFSマウント時に必要となるポートの解放を忘れずに実施してください。

7

コントロールパネルより、クラスターを作成します。
プライベートLANには先に作成したプライベートLANを指定することで、プライベートLANを利用する形でクラスターが作成されます。
また、ファイアウォールグループには、6)で作成したものを指定してください。
クラスター作成と同時に最初のノードプールが作成されますので、ステータスが「稼働中」になるとクラスターの利用が開始できます。
ノードが「異常」状態となる場合は、DHCPの設定を見直してください。

8

kubectlを実行できる環境を用意し、作成したノードへ接続するためのクレデンシャルを設定します。
設定するクレデンシャルは、 クラスター一覧 より対象のクラスターを選択し、クレデンシャル表示 をすることで確認できます。
合わせてhelmも実行できるようにしておくと後の作業が簡単になります。

9

8)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。

10

クラスターにデプロイします。方法として二つあります。
本方式にて、NFS上にディレクトリが作成され、PVとして扱われるようになります。

  1. helmが使え、オプションで指定できるカスタマイズで十分な場合

    1. helmレポジトリを追加する

      $ helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
    2. helmを使ってデプロイする

      $ helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner --set nfs.server=[NFSサーバーのIP] --set nfs.path=/ --set storageClass.name=nifcloud-nas-nfs
  2. helmが使えない、helmは使えるがオプションではカスタマイズが足りない場合

    1. nfs-subdir-external-provisionerのドキュメントを参考に、必要に応じてコンフィグファイルを修正し、デプロイします。
      NFS_SERVER(NFSサーバーのIP)と、NFS_PATH(/)の変更は必須となります。

11

テストPVCを作成し、問題なく作成されるか確認します。

  1. PVCを作成するためのコンフィグを作成します。

    pvc.yml
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: test-claim
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 1Mi
      storageClassName: nifcloud-nas-nfs
  2. コンフィグを適用し、PVCを作成します。

    $ kubectl create -f pvc.yml
  3. 作成を確認します。pvが作成されれば問題ありません。

    $ kubectl get pv
    NAME                CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM              STORAGECLASS     REASON AGE
    pvc-[RANDOM STRING] 1Mi      RWX          Delete         Bound  default/test-claim nifcloud-nas-nfs 8s
検討事項

本パターンを構築するための主要検討事項はプライベートLANを利用する構成の検討事項に準じます。

RDB

ニフクラRDBを、データベースとして利用する構成となります。
本手順ではプライベートLANを利用する構成を前提としていますが、必ずしもプライベートLANは必要ではありません。


image


以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。

作業順番

利用者が実施すべき作業内容

1

コントロールパネルよりプライベートLANを作成します。

2

コントロールパネルよりDHCPコンフィグを作成します。
必ず自動割り当てIPアドレスとして、作成予定ノード数に対して十分に余裕を持ったIPアドレスを配布できるようにしてください。
バージョンアップ時の一時的なノード数増加に対応する必要があります。

3

コントロールパネルよりプライベートLANに接続したルーターを作成します。
作成時には、DHCPオプションを有効にし、先に作成したDHCPコンフィグを指定してください。

4

コントロールパネルよりDBファイアウォールグループを作成します。
作成後、ルール変更にて2)でノードへ配布するレンジとしたIP帯を追加し、DBへアクセスできるようにしてください。

5

コントロールパネルよりプライベートLANに接続したRDBを作成します。
DBファイアウォールグループには4)で作成したファイアウォールグループを指定してください。
また、付与するIPアドレスは2)で指定した自動払い出しのIP帯を避けたものとしてください。

6

コントロールパネルよりHatobaのファイアウォールグループを作成します
作成時に、必ずinルールへkubectlを実行する端末のグローバルIPから6443への接続を追加します。
実施しない場合、kubectlによる操作ができません。
また、グローバルからのアクセスを防ぐため、何か一つinルールを設定してください。
outルールに関しては任意となりますが、outルールを指定する場合はRDBの通信解放を忘れずに実施してください。

7

コントロールパネルより、クラスターを作成します。
プライベートLANには先に作成したプライベートLANを指定することで、プライベートLANを利用する形でクラスターが作成されます。
また、ファイアウォールグループには、6)で作成したものを指定してください。
クラスター作成と同時に最初のノードプールが作成されますので、ステータスが「稼働中」になるとクラスターの利用が開始できます。
ノードが「異常」状態となる場合は、DHCPの設定を見直してください。

8

kubectlを実行できる環境を用意し、作成したノードへ接続するためのクレデンシャルを設定します。
設定するクレデンシャルは、 クラスター一覧 より対象のクラスターを選択し、クレデンシャル表示 をすることで確認できます。
合わせてhelmも実行できるようにしておくと後の作業が簡単になります。

9

8)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。

10

RDBをサービス登録します。

  1. RDBをサービスとして登録するコンフィグを作成します。

    rdb-service.yml
    apiVersion: v1
    kind: Service
    metadata:
      name: database
    spec:
      ports:
      - protocol: TCP
        port: 3306
        targetPort: 3306
    
    ---
    apiVersion: v1
    kind: Endpoints
    metadata:
      name: database
    subsets:
      - addresses:
          - ip: XX.XX.XX.XX
        ports:
          - port: 3306
  2. クラスターに適用します。

    $ kubectl apply -f rdb-sv.yml
    service/database created
    endpoints/database created
    $ kubectl get service
    NAME       TYPE      CLUSTER-IP  EXTERNAL-IP PORT(S)  AGE
    database   ClusterIP XX.XX.XX.XX <none>      3306/TCP XXXX
    kubernetes ClusterIP XX.XX.XX.XX <none>      443/TCP  XXXX
    $ kubectl  get endpoints
    NAME       ENDPOINTS      AGE
    database   [RDBのIP]:3306 XXXX
    kubernetes XX.XX.XX.XX    XXXX

11

  1. クラスター上のpodからmysqlに接続できるか確認します。

    $ kubectl apply -f mysql-client.yml ← mysqlクライアントが使えるイメージをpodとして記述したコンフィグファイル
    pod/mysql-client created
    $ kubectl -ti exec pod/mysql-client -- /bin/bash
    # mysql -u test -p -h database
    Enter password:
    MySQL>show databases;
    +--------------------+
    | Database           |
    +--------------------+
    | information_schema |
    | innodb             |
    | mysql              |
    | performance_schema |
    | sys                |
    | test               |
    +--------------------+
    6 rows in set (0.001 sec)
検討事項

本パターンを構築するための主要検討事項はプライベートLANを利用する構成の検討事項に準じます。

ロードバランサー(L4)

ロードバランサー(L4)を利用し、サービスを外部公開する構成となります。
Serviceのtype:LoadBalancerを利用します。

image


以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
本手順ではプライベートLANを利用する構成を前提としていますが、必ずしもプライベートLANは必要ではありません。


作業順番

利用者が実施すべき作業内容

1

コントロールパネルよりプライベートLANを作成します。

2

コントロールパネルよりHatobaのファイアウォールグループを作成します
作成時に、必ずinルールへkubectlを実行する端末のグローバルIPから6443への接続を追加します。
実施しない場合、kubectlによる操作ができません。
また、グローバルからのアクセスを防ぐため、何か一つinルールを設定してください。
outルールに関しては任意となります。

3

コントロールパネルより、クラスターを作成します。
プライベートLANには先に作成したプライベートLANを指定することで、プライベートLANを利用する形でクラスターが作成されます。
また、ファイアウォールグループには、2)で作成したものを指定してください。
クラスター作成と同時に最初のノードプールが作成されますので、ステータスが「稼働中」になるとクラスターの利用が開始できます。
ノードが「異常」状態となる場合は、DHCPの設定を見直してください。

4

kubectlを実行できる環境を用意し、作成したノードへ接続するためのクレデンシャルを設定します。
設定するクレデンシャルは、 クラスター一覧 より対象のクラスターを選択し、クレデンシャル表示 をすることで確認できます。
合わせてhelmも実行できるようにしておくと後の作業が簡単になります。

5

4)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。

6

ロードバランサー(L4)による振り分け設定を投入します。

  1. ロードバランサー(L4)をサービスとして作成するコンフィグを作成します。
    ここで使用しているアノテーションについては、ドキュメントを参照ください。

    l4-lb.yml
    apiVersion: v1
    kind: Service
    metadata:
      name: hellolb
      labels:
        run: hello
      annotations:
        # https://pfs.nifcloud.com/api/rest/CreateLoadBalancer.htm
        #最大流量.Mbsp
        service.beta.kubernetes.io/hatoba-load-balancer-network-volume: "10"
        #月額:1/従量:2
        service.beta.kubernetes.io/hatoba-load-balancer-accounting-type: "2"
        # ロードバランサーの種類.standard/ats
        service.beta.kubernetes.io/hatoba-load-balancer-policy-type: standard
        # 1:ound-Robin 2:Least-Connection
        service.beta.kubernetes.io/hatoba-load-balancer-balancing-type: "1"
        # https://pfs.nifcloud.com/api/rest/ConfigureHealthCheck.htm
        #count to fail.1-10
        service.beta.kubernetes.io/hatoba-load-balancer-healthcheck-unhealthy-threshold: "3"
        service.beta.kubernetes.io/hatoba-load-balancer-healthcheck-interval: "30" #helth check interval.5-300
        # https://pfs.nifcloud.com/api/rest/SetFilterForLoadBalancer.htm
        #フィルタの挙動 許可:1/拒否:2
        service.beta.kubernetes.io/hatoba-load-balancer-filter-type: "1"
    spec:
      type: LoadBalancer
      ports:
        - port: 80 #ロードバランサーの待ち受けポート
          protocol: TCP #TCPのみ受け付けます
          targetPort: 8080 #Podが待ち受けているポート
          name: http
      loadBalancerSourceRanges:
        - 192.168.10.0/24 #アクセス元のグローバルIP(帯)
        - 192.168.10.254/32 #アクセス元のグローバルIP(単体)
      selector:
        run: hello
  2. クラスターに適用します。

    $ kubectl apply -f l4-lb.yml
    service/hellolb configured
    $ kubectl get service
    NAME         TYPE           CLUSTER-IP  EXTERNAL-IP PORT(S)      AGE
    hellolb      LoadBalancer   XX.XX.XX.XX XX.XX.XX.XX 80:32246/TCP XXs
    kubernetes   ClusterIP      XX.XX.XX.XX <none>      443/TCP      XdXXs

7

テストとして、振り分け先Podを作成します。

  1. テストとして、httpアクセスされると「Hello Kubernetes!」とだけ返すコンテナを起動します。

    helo.yml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: hello
    spec:
      selector:
        matchLabels:
          run: hello
      replicas: 3
      template:
        metadata:
          labels:
            run: hello
        spec:
          containers:
          - name: hello
            image: gcr.io/google-samples/node-hello:1.0
            ports:
            - containerPort: 8080
  2. Podをデプロイします。

    $ kubectl apply -f hello.yml
    deployment.apps/hello created
  3. ブラウザから、ロードバランサーのIPへアクセスし、「Hello Kubernetes!」と表示されることを確認します。

検討事項

本パターンを構築するための主要検討事項を以下に記載します。
基本的に、プライベートLANを利用する構成の検討事項に準じます。
ここでは、差分のみ記載します。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

稼働監視

ロードバランサー(L4)の状態確認

ロードバランサー(L4)のAPIでは、Hatobaノードの組込み状態が取得できない。

2

リストア時の挙動

ロードバランサー(L4)が振り分け先として選択するノード

最後に設定を実施したクラスターへのみ振り分けを実施します。複数のクラスターをまたいだ振り分けは実施しません。

運用上考慮点とする。

ロードバランサー(L4)とKubernetes Service HatobaのHTTPロードバランサーの組み合わせ

ロードバランサー(L4)とIngressロードバランサーを利用し、IngressロードバランサーにてHTTPSを終端し、サービスを外部公開する構成となります。
IngressコントローラーのServiceをtype:LoadBalancerにすることで、ロードバランサー(L4)と連携させます。

image


以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
本手順ではプライベートLANを利用する構成を前提としていますが、必ずしもプライベートLANは必要ではありません。


作業順番

利用者が実施すべき作業内容

1

コントロールパネルよりプライベートLANを作成します。

2

コントロールパネルよりHatobaのファイアウォールグループを作成します
作成時に、必ずinルールへkubectlを実行する端末のグローバルIPから6443への接続を追加します。
実施しない場合、kubectlによる操作ができません。
また、グローバルからのアクセスを防ぐため、何か一つinルールを設定してください。
outルールに関しては任意となります。

3

コントロールパネルより、クラスターを作成します。
プライベートLANには先に作成したプライベートLANを指定することで、プライベートLANを利用する形でクラスターが作成されます。
また、ファイアウォールグループには、2)で作成したものを指定し、「HTTPロードバランサー」の項目を「利用する」に設定してください。
クラスター作成と同時に最初のノードプールが作成されますので、ステータスが「稼働中」になるとクラスターの利用が開始できます。
ノードが「異常」状態となる場合は、DHCPの設定を見直してください。

4

kubectlを実行できる環境を用意し、作成したノードへ接続するためのクレデンシャルを設定します。
設定するクレデンシャルは、 クラスター一覧 より対象のクラスターを選択し、クレデンシャル表示 をすることで確認できます。
合わせてhelmも実行できるようにしておくと後の作業が簡単になります。

5

4)の環境からkubectl get nodesなどのコマンドを実施し、情報が取得できること、表示されたノードがコントロールパネルで表示される一覧と同じ事を確認します。

6

証明書ファイルをクラスターに登録します。(証明書は別途用意してください。)

$ kubectl create secret tls sample-tls --key sample-tls.key --cert sample-tls.crt
$ kubectl get secret tls
NAME        TYPE                 DATA   AGE
sample-tls  kubernetes.io/tls    1      xxs

7

  1. Ingressロードバランサーを作成します。今回はhttpsでアクセスするため、先に登録した証明書を使いtls通信を終端します

    https-lb.yml
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: doc-sample-ingress
    spec:
      ingressClassName: nginx
      tls:
        - hosts:
            - example.com
          secretName: sample-tls
      rules:
      - host: example.com
        http:
          paths:
            - path: /
              pathType: Prefix
              backend:
                service:
                  name: hello-service
                  port:
                    number: 443
  2. クラスターに適用します。tlsの終端状況を確認します。

    $ kubectl apply -f https-lb.yml
    ingress.networking.k8s.io/doc-sample-ingress configured
    $  kubectl doctest describe ing doc-sample-ingress
    Name:             doc-sample-ingress
    Labels:           <none>
    Namespace:        default
    Address:          XXX.XXX.XXX.XXX
    Ingress Class:    nginx
    Default backend:  <default>
    TLS:
      sample-tls terminates example.com
    Rules:
      Host                Path  Backends
      ----                ----  --------
      example.com
                          /   hello-service:443 (<error: endpoints "hello-service" not found>)
    Annotations:          <none>
    Events:
      Type    Reason  Age      From                      Message
      ----    ------  ----     ----                      -------
      Normal  Sync    xx      nginx-ingress-controller  Scheduled for sync

8

Ingressコントローラと、ロードバランサー(L4)を組み合わせます。

  1. 現状のIngressコントローラの設定を抜き出します

    $ kubectl get service -n ingress-nginx ingress-nginx-controller -o yaml > ingress-nginx-controller.yml
  2. 以下のポイントを修正します

    • デフォルトでは名前が長すぎるため、ロードバランサー名のアノテーションを指定

      ingress-nginx-controller.yml
      annotations:
        service.beta.kubernetes.io/hatoba-load-balancer-name: inglb  # ←追記
    • L4ロードバランサーと組み合わせるため、「spec:type:」を「NodePort」から、「LoadBalancer」に変更

      ingress-nginx-controller.yml
      spec:
        type: LoadBalancer #←変更
  3. 適用します

    $ kubectl apply -f ingress-nginx-controller.yml
    % kubectl get service --namespace ingress-nginx ingress-nginx-controller
    NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
    ingress-nginx-controller   LoadBalancer   XX.XX.XX.XX     <pending>     80:3xxxx/TCP,443:3xxxx/TCP   XXX
  4. ロードバランサーが作成されると、EXTERNAL-IPが表示されます

    % kubectl get service --namespace ingress-nginx ingress-nginx-controller
    NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
    ingress-nginx-controller   LoadBalancer   XX.XX.XX.XX     YY.YY.YY.YY   80:3xxxx/TCP,443:3xxxx/TCP   XXX

9

テストとして、振り分け先Podを作成します。

  1. テストとして、httpアクセスされると「echo1」と「echo2」と返すコンテナを起動します。

    hello.yml
    kind: Deployment
    metadata:
      name: hello-deploy-1
    spec:
      selector:
        matchLabels:
          run: hello-pod
      replicas: 1
      template:
        metadata:
          labels:
            run: hello-pod
        spec:
          containers:
          - name: hello
            image: hashicorp/http-echo
            args:
              - -text=echo1
              - -listen=:80
            ports:
              - containerPort: 80
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: hello-deploy-2
    spec:
      selector:
        matchLabels:
          run: hello-pod
      replicas: 1
      template:
        metadata:
          labels:
            run: hello-pod
        spec:
          containers:
          - name: hello
            image: hashicorp/http-echo
            args:
              - -text=echo2
              - -listen=:80
            ports:
              - containerPort: 80
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: hello-service
    spec:
      selector:
        run: hello-pod
      ports:
        - protocol: TCP
          port: 443
          targetPort: 80
  2. デプロイします。

    $ kubectl apply -f hello.yml
    deployment.apps/hello-deploy-1 created
    deployment.apps/hello-deploy-2 created
    service/hello-service created
  3. ブラウザからロードバランサーのIPへアクセスし、「echo1」または、「echo2」と表示されることを確認します。
    また、複数回更新し、両方表示されることを確認します。

検討事項

本パターンを構築するための主要検討事項を以下に記載します。
基本的に、プライベートLANを利用する構成の検討事項に準じます。
ここでは、差分のみ記載します。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

稼働監視

ロードバランサー(L4)の状態確認

ロードバランサー(L4)のAPIでは、Hatobaノードの組込み状態が取得できない。

2

リストア時の挙動

ロードバランサー(L4)が振り分け先として選択するノード

最後に設定を実施したクラスターへのみ振り分けを実施します。複数のクラスターをまたいだ振り分けは実施しません。

運用上考慮点とする。

導入のご相談はお電話でも受け付けております。

0120-22-1200

0120-22-1200

受付時間:9:00~17:45(土日祝・当社指定の休業日を除く)
※携帯電話・PHSからもご利用可能