IBM Cloud ストレージ・ユーティリティー
クラシック: IBM Cloud Block Storage Attacher プラグイン (ベータ) のインストール
IBM Cloud Block Storage Attacher プラグインを使用して、未フォーマット、アンマウントのブロックストレージをクラスタのクラシックワーカーノードにアタッチします。
IBM Cloud Block Storage Attacher プラグインは、クラシック・ワーカー・ノードにのみ使用できます。 未フォーマットのブロックストレージをVPCワーカーノードにアタッチしたい場合は、 未フォーマットの Block Storage for VPC ワーカーノードの追加を 参照してください。
例えば、Portworx などのソフトウェア定義ストレージ・ソリューション (SDS) を使用してデータを保管したいが、SDS 使用に最適化され、追加のローカル・ディスクが付属しているクラシック・ベアメタル・ワーカー・ノードは使用したくないとします。 非 SDS のクラシック・ワーカー・ノードにローカル・ディスクを追加するには、IBM Cloud インフラストラクチャー・アカウントでブロック・ストレージ・デバイスを手動で作成し、IBM Cloud Block Volume Attacher を使用してそのストレージを非 SDS ワーカー・ノードに接続する必要があります。
IBM Cloud Block Volume Attacher プラグインは、デーモン・セットの一部としてクラスター内のすべてのワーカー・ノード上にポッドを作成して、後でブロック・ストレージ・デバイスを非 SDS ワーカー・ノードに接続するために使用する Kubernetes ストレージ・クラスをセットアップします。
IBM Cloud Block Volume Attacher プラグインの更新方法と削除方法については、 IBM Cloud Object Storage プラグインの更新と IBM Cloud Object Storage プラグインの削除を参照してください。
-
こちらの手順に従って、Helm クライアント・バージョン 3 をローカル・マシンにインストールします。
-
Helm リポジトリーを更新して、このリポジトリーにあるすべての Helm チャートの最新バージョンを取得します。
helm repo update
-
IBM Cloud Block Volume Attacher プラグインをインストールします。 このプラグインをインストールすると、事前定義されたブロック・ストレージ・クラスがクラスターに追加されます。
helm install block-attacher iks-charts/ibm-block-storage-attacher --namespace kube-system
出力例
NAME: block-volume-attacher LAST DEPLOYED: Thu Sep 13 22:48:18 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1beta1/ClusterRoleBinding NAME AGE ibmcloud-block-storage-attacher 1s ==> v1beta1/DaemonSet NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE ibmcloud-block-storage-attacher 0 0 0 0 0 <none> 1s ==> v1/StorageClass NAME PROVISIONER AGE ibmc-block-attacher ibm.io/ibmc-blockattacher 1s ==> v1/ServiceAccount NAME SECRETS AGE ibmcloud-block-storage-attacher 1 1s ==> v1beta1/ClusterRole NAME AGE ibmcloud-block-storage-attacher 1s NOTES: Thank you for installing: ibmcloud-block-storage-attacher. Your release is named: block-volume-attacher Please refer Chart README.md file for attaching a block storage Please refer Chart RELEASE.md to see the release details/fixes
-
IBM Cloud Block Volume Attacher デーモン・セットが正常にインストールされていることを確認します。
kubectl get pod -n kube-system -o wide | grep attacher
出力例
ibmcloud-block-storage-attacher-z7cv6 1/1 Running 0 19m
正常にインストールされている場合は、1 つ以上の ibmcloud-block-storage-attacher ポッドが表示されます。 ポッドの数は、クラスター内のワーカー・ノードの数と等しくなります。 すべてのポッドが Running 状態である必要があります。
-
IBM Cloud Block Volume Attacher のストレージ・クラスが正常に作成されていることを確認します。
kubectl get sc | grep attacher
出力例
ibmc-block-attacher ibm.io/ibmc-blockattacher 11m
IBM Cloud Block Storage Attacher プラグインの更新
既存の IBM Cloud Block Storage Attacher プラグインを最新バージョンにアップグレードできます。
-
Helm リポジトリーを更新して、このリポジトリーにあるすべての Helm チャートの最新バージョンを取得します。
helm repo update
-
オプション: 最新の Helm チャートをローカル・マシンにダウンロードします。 そして、パッケージを解凍し、
release.md
ファイルを参照して最新リリース情報を確認します。helm pull iks-charts/ibmcloud-block-storage-plugin
-
IBM Cloud Block Storage Attacher プラグインの Helm チャートの名前を確認します。
helm ls -A
出力例
<helm_chart_name> 1 Wed Aug 1 14:55:15 2022 DEPLOYED ibm-block-storage-attacher-1.0.0 default
-
IBM Cloud Block Storage Attacher を最新バージョンにアップグレードします。
helm upgrade --force --recreate-pods <helm_chart_name> ibm-block-storage-attacher
IBM Cloud Block Volume Attacher プラグインの削除
クラスター内で IBM Cloud Block Storage Attacher プラグインをプロビジョンも使用もしない場合は、Helm チャートをアンインストールできます。
-
IBM Cloud Block Storage Attacher プラグインの Helm チャートの名前を確認します。
helm list | grep ibm-block-storage-attacher
出力例
<helm_chart_name> 1 Wed Aug 1 14:55:15 2022 DEPLOYED ibm-block-storage-attacher-1.0.0 default
-
Helm チャートを削除することで、IBM Cloud Block Storage Attacher プラグインを削除します。
helm uninstall <helm_chart_name> -n <namespace>
-
IBM Cloud Block Storage Attacher プラグインのポッドが削除されたことを確認します。
kubectl get pod -n kube-system -o wide | grep attacher
CLI 出力にポッドが表示されていなければ、ポッドは正常に削除されています。
-
IBM Cloud Block Storage Attacher のストレージ・クラスが削除されたことを確認します。
kubectl get sc | grep attacher
ストレージ・クラスが正常に削除された場合は、CLI 出力にストレージ・クラスが表示されません。
クラシック: 特定のワーカー・ノードへのブロック・ストレージの手動追加
この方法を選択するのは、異なるブロック・ストレージ構成を追加する場合、ワーカー・ノードのサブセットのみにブロック・ストレージを追加する場合、またはプロビジョニング・プロセスをより細かく制御する場合です。
このトピックの手順は、クラシック・ワーカー・ノードにのみ使用できます。 未フォーマットのブロックストレージをVPCワーカーノードにアタッチする場合は、 ワーカーノードへの未フォーマット Block Storage for VPC の追加を 参照してください。
-
クラスター内のワーカー・ノードをリスト表示して、ブロック・ストレージ・デバイスを追加する非 SDS ワーカー・ノードのプライベート IP アドレスとゾーンを書き留めます。
ibmcloud ks worker ls --cluster <cluster_name_or_ID>
-
ブロック・ストレージ構成の決定のステップ 3 と 4 を参照して、非 SDS ワーカー・ノードに追加するブロック・ストレージ・デバイスのタイプ、サイズ、および IOPS 数を選択します。
-
非 SDS ワーカー・ノードと同じゾーン内にブロック・ストレージ・デバイスを作成します。
GB あたり 2 IOPS の 20 GB エンデュランス・ブロック・ストレージのプロビジョニング例。
ibmcloud sl block volume-order --storage-type endurance --size 20 --tier 2 --os-type LINUX --datacenter dal10
100 IOPS の 20 GB パフォーマンス・ブロック・ストレージのプロビジョニング例。
ibmcloud sl block volume-order --storage-type performance --size 20 --iops 100 --os-type LINUX --datacenter dal10
-
ブロック・ストレージ・デバイスが作成されたことを確認して、ボリュームの
id
を書き留めます。 注: ブロック・ストレージ・デバイスがすぐに表示されない場合は、数分待ってください。 その後、このコマンドを再実行してください。ibmcloud sl block volume-list
出力例
id username datacenter storage_type capacity_gb bytes_used ip_addr lunId active_transactions 123456789 IBM02SL1234567-8 dal10 performance_block_storage 20 - 161.12.34.123 0 0
-
ボリュームの詳細を確認して、
Target IP
とLUN Id
を書き留めます。ibmcloud sl block volume-detail <volume_ID>
出力例
NAME Value ID 1234567890 User name IBM123A4567890-1 Type performance_block_storage Capacity (GB) 20 LUN Id 0 IOPS 100 Datacenter dal10 Target IP 161.12.34.123 # of Active Transactions 0 Replicant Count 0
-
非 SDS ワーカー・ノードがブロック・ストレージ・デバイスにアクセスすることを許可します。
<volume_ID>
を、先ほど取得したブロック・ストレージ・デバイスのボリューム ID に置き換え、<private_worker_IP>
を、デバイスを接続する非 SDS ワーカー・ノードのプライベート IP アドレスに置き換えます。ibmcloud sl block access-authorize <volume_ID> -p <private_worker_IP>
出力例
The IP address 123456789 was authorized to access <volume_ID>.
-
非 SDS ワーカー・ノードが正常にアクセスを許可されたことを確認して、
host_iqn
、username
、およびpassword
を書き留めます。ibmcloud sl block access-list <volume_ID>
出力例
ID name type private_ip_address source_subnet host_iqn username password allowed_host_id 123456789 <private_worker_IP> IP <private_worker_IP> - iqn.2018-09.com.ibm:ibm02su1543159-i106288771 IBM02SU1543159-I106288771 R6lqLBj9al6e2lbp 1146581
正常にアクセスが許可された場合は、
host_iqn
、username
、およびpassword
が割り当てられています。
クラシック: 非 SDS ワーカー・ノードへのロー・ブロック・ストレージの接続
ブロック・ストレージ・デバイスを非 SDS ワーカー・ノードに接続するには、IBM Cloud Block Volume Attacher のストレージ・クラスとブロック・ストレージ・デバイスの詳細を使用して、永続ボリューム (PV) を作成する必要があります。
このトピックの手順は、クラシック・ワーカー・ノードにのみ使用できます。 未フォーマットのブロックストレージをVPCワーカーノードにアタッチする場合は、 ワーカーノードへの未フォーマット Block Storage for VPC の追加を 参照してください。
- マウントされていない未フォーマットのロー・ブロック・ストレージを非 SDS ワーカー・ノードに対して手動で追加したことを確認します。
- アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
- Block Storage Attacher プラグインをインストールします。
-
PV の作成を準備します。
-
mkpvyaml
コンテナーを使用した場合は、以下のコマンドを実行します。-
pv-<cluster_name>.yaml
ファイルを開きます。nano pv-<cluster_name>.yaml
-
PV の構成を確認します。
-
-
ブロック・ストレージを手動で追加した場合は、次のようにします。**
-
pv.yaml
ファイルを作成します。 次のコマンドによって、nano
エディターを使用してこのファイルが作成されます。nano pv.yaml
-
ブロック・ストレージ・デバイスの詳細を PV に追加します。
apiVersion: v1 kind: PersistentVolume metadata: name: <pv_name> annotations: ibm.io/iqn: "<IQN_hostname>" ibm.io/username: "<username>" ibm.io/password: "<password>" ibm.io/targetip: "<targetIP>" ibm.io/lunid: "<lunID>" ibm.io/nodeip: "<private_worker_IP>" ibm.io/volID: "<volume_ID>" spec: capacity: storage: <size> accessModes: - ReadWriteOnce hostPath: path: / storageClassName: ibmc-block-attacher
metadata.name
- PV の名前を入力します。
ibm.io/iqn
- 前に取得した IQN ホスト名を入力します。
ibm.io/username
- 既に取得した IBM Cloud インフラストラクチャーのユーザー名を入力します。
ibm.io/password
- 既に取得した IBM Cloud インフラストラクチャーのパスワードを入力します。
ibm.io/targetip
- 既に取得したターゲット IP を入力します。
ibm.io/lunid
- 既に取得したブロック・ストレージ・デバイスの LUN ID を入力します。
ibm.io/nodeip
- ブロック・ストレージ・デバイスへのアクセスを既に許可した、ブロック・ストレージ・デバイスを接続するワーカー・ノードのプライベート IP アドレスを入力します。
ibm.io/volID
- 既に取得したブロック・ストレージ・ボリュームの ID を入力します。
storage
- 既に作成したブロック・ストレージ・デバイスのサイズを入力します。 例えば、ブロック・ストレージ・デバイスが 20 ギガバイトの場合は、
20Gi
と入力します。
-
-
-
ブロック・ストレージ・デバイスを非 SDS ワーカー・ノードに接続するための PV を作成します。
-
mkpvyaml
コンテナーを使用した場合は、以下のコマンドを実行します。kubectl apply -f pv-<cluster_name>.yaml
-
ブロック・ストレージを手動で追加した場合は、以下のコマンドを実行します。
kubectl apply -f pv.yaml
-
-
ブロック・ストレージがワーカー・ノードに正常に接続されたことを確認します。
kubectl describe pv <pv_name>
出力例
NAME: kube-wdc07-cr398f790bc285496dbeb8e9137bc6409a-w1-pv1 Labels: <none> Annotations: ibm.io/attachstatus=attached ibm.io/dm=/dev/dm-1 ibm.io/iqn=iqn.2018-09.com.ibm:ibm02su1543159-i106288771 ibm.io/lunid=0 ibm.io/mpath=3600a09803830445455244c4a38754c66 ibm.io/nodeip=10.176.48.67 ibm.io/password=R6lqLBj9al6e2lbp ibm.io/targetip=161.26.98.114 ibm.io/username=IBM02SU1543159-I106288771 kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{"ibm.io/iqn":"iqn.2018-09.com.ibm:ibm02su1543159-i106288771","ibm.io/lunid":"0"... Finalizers: [] StorageClass: ibmc-block-attacher Status: Available Claim: Reclaim Policy: Retain Access Modes: RWO Capacity: 20Gi Node Affinity: <none> Message: Source: Type: HostPath (bare host directory volume) Path: / HostPathType: Events: <none>
ブロック・ストレージ・デバイスが正常に接続された場合は、ibm.io/dm がデバイス ID (
/dev/dm/1
など) に設定され、CLI 出力の Annotations セクションに ibm.io/attachstatus=attached と表示されます。
ボリュームを切り離す場合は、PV を削除します。 切り離されたボリュームは、特定のワーカー・ノードによるアクセスが引き続き許可されて、異なるボリュームを同じワーカー・ノードに接続するために IBM Cloud Block Volume Attacher のストレージ・クラスを使用して新しい PV を作成したときに再接続されます。 元の切り離されたボリュームが再接続されることを回避するには、ibmcloud sl block access-revoke
コマンドを使用して、ワーカー・ノードが切り離されたボリュームにアクセスすることを禁止してください。 ボリュームを切り離しても、そのボリュームは IBM Cloud インフラストラクチャー・アカウントから削除されません。 ボリュームの課金をキャンセルするには、該当ストレージを IBM Cloud インフラストラクチャー・アカウントから手動で削除する必要があります。
VPC: API を使用した VPC ワーカー・ノードへのロー・Block Storage for VPCの追加
Kubernetes Service API を使用して、フォーマットされていない生の Block Storage for Classic を VPC クラスタのワーカーノードにアタッチしたりデタッチしたりできます。
1 つのボリュームは 1 台のワーカー・ノードにのみ接続できます。 接続を成功させるために、ボリュームがワーカー・ノードと同じゾーンにあることを確認してください。
CLI を使用して、ワーカー・ノードのボリューム接続の接続、切り離し、リストを行うこともできます。 詳しくは、ストレージ CLI リファレンスを参照してください。
このトピックの説明は、VPC ワーカー・ノードにのみ当てはまります。 未フォーマットのロー・ブロック・ストレージをクラシック・ワーカー・ノードに接続する場合は、IBM Cloud Block Storage Attacher プラグインをインストールしてください。
始める前に
アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
-
VPC ワーカー・ノードが存在するリージョンとゾーンを確認します。
ibmcloud ks worker ls -c <cluster_name>
-
容量とパフォーマンスの要件に最も適した Block Storage for Classic のプロファイルを決定します。
-
Block Storage for Classic ボリュームをプロビジョンします。 プロビジョンするボリュームは、ワーカー・ノードと同じリソース・グループ、リージョン、およびゾーン内になければなりません。
-
IAM トークンを取得します。
ibmcloud iam oauth-tokens
-
Block Storage for Classic インスタンスに接続するワーカー・ノードの ID を取得します。 Block Storage for Classic ボリュームと同じゾーン内にあるワーカー・ノードを選択してください。
ibmcloud ks worker ls --cluster <cluster_name_or_ID>
-
POST
要求を使用して、Block Storage for Classic ボリュームをワーカー・ノードに接続します。要求の例
curl -X POST "https://containers.cloud.ibm.com/global/v2/storage/createAttachment" -H "accept: application/json" -H "Authorization: <IAM_token>" -H "X-Auth-Resource-Group-ID: <resource_group>" -H "Content-Type: application/json" -d "{ \"cluster\": \"<cluster_name_or_ID>\", \"volumeID\": \"<volume_ID>\", \"worker\": \"<worker_ID>\"}"
IAM_token
- 現行セッションの IAM OAuth トークン。 この値は、
ibmcloud iam oauth-tokens
を実行して取得できます。 cluster_name_or_ID
- クラスターに割り当てられている固有 ID または名前。 この ID は、
ibmcloud ks cluster ls
を実行して取得できます。 worker_ID
- ボリュームを接続するワーカー・ノードに割り当てられている固有 ID。 この値は、
ibmcloud ks worker ls -c <cluster_name>
を実行して取得できます。 volume_ID
- Block Storage for Classic ボリュームに割り当てられている固有 ID。
ibmcloud is volumes
を実行して、Block Storage for Classic ボリュームのリストを取得できます。
応答例。
{ "id": "0111-1aaa11a1-aa1a-111a-111b-1111a1dad1bc", "volume": { "name": "my-vol", "id": "r001-11aa0d59-a1aa-1a11-11ca-ba2bc11e01aa" }, "device": { "id": "" }, "name": "volume-attachment", "status": "attaching", "type": "data" }
-
VPC ワーカー・ノードの既存のボリューム接続を確認して、接続を検証します。
API を使用した VPC クラスター内のワーカー・ノードからの未フォーマットのロー Block Storage for Classic の切り離し
DELETE
要求を使用して、VPC ワーカー・ノードからストレージを切断できます。
VPC クラスターからストレージを切断しても、Block Storage for Classic ボリュームやそのボリュームに保管されているデータは削除されません。 ボリュームを手動で削除するまで、料金がかかります。
-
削除するストレージ・ボリュームを確認し、そのボリューム ID をメモします。
ibmcloud is volumes
-
ボリュームについての詳細を取得します。 このコマンドは、ワーカー・ノード ID および接続 ID を戻します。 ワーカー・ノード ID をメモしてください。 次のコマンドで、この ID は「インスタンス名」として返されます。
ibmcloud is volume <volume_ID>
-
PV のリストを取得します。 このコマンドは、PV のリストを戻します。そのリストを使用して、削除するボリュームを使用している PVC を判別できます。
kubectl get pv
-
ボリュームを使用している PV の詳細を表示します。 削除するボリュームをどの PV が使用しているかわからない場合は、クラスター内の各 PV で
describe pv
コマンドを実行できます。 PV を使用している PVC をメモします。kubectl describe pv <pv_name>
-
ストレージ・ボリュームがポッドで使用されているかどうかを確認します。 次のコマンドは、ボリュームをマウントするポッド、および関連付けられている PVC を表示します。 ポッドが返されない場合、ストレージは使用されていません。
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
-
ボリュームを使用しているポッドがデプロイメントに含まれている場合は、そのデプロイメントを削除します。 ポッドがデプロイメントに含まれていない場合は、ポッドを削除します。
kubectl delete deployment <deployment_name>
kubectl delete pod <pod_name>
-
PVC および PV を削除します。
kubectl delete pvc <pvc_name>
kubectl delete pv <pv_name>
-
IAM トークンを取得します。
ibmcloud iam oauth-tokens
-
POST
要求を使用して、ストレージを切り離します。要求の例
curl -X POST "https://containers.cloud.ibm.com/global/v2/storage/deleteAttachment" -H "accept: application/json" -H "Authorization: <IAM_token>" -H "X-Auth-Resource-Group-ID: <resource_group>" -H "Content-Type: application/json" -d "{ \"cluster\": \"<cluster_name_or_ID\", \"volumeAttachmentID\": \"<volume_attachment_ID>\", \"volumeID\": \"<volume_ID>\", \"worker\": \"<worker_ID>\"}"
IAM_token
- 現行セッションの IAM OAuth トークン。 この値は、
ibmcloud iam oauth-tokens
を実行して取得できます。 cluster_name_or_ID
- クラスターに割り当てられている固有 ID または名前。 この ID は、
ibmcloud ks cluster ls
を実行して取得できます。 worker_ID
- ボリュームを接続するワーカー・ノードに割り当てられている固有 ID。 この値は、
ibmcloud ks worker ls -c <cluster_name>
を実行して取得できます。 volume_ID
- Block Storage for Classic ボリュームに割り当てられている固有 ID。
ibmcloud is volumes
を実行して、Block Storage for Classic ボリュームのリストを取得できます。 volume_attachment_ID
- ボリューム接続に割り当てられている固有 ID。 この ID は、
ibmcloud is volume <volume_ID>
を実行して取得できます。
API を使用した VPC ワーカー・ノードのボリューム接続の詳細の確認
GET
要求を使用して、VPC ワーカー・ノードのボリューム接続の詳細を取得できます。
-
IAM トークンを取得します。
ibmcloud iam oauth-tokens
-
クラスターがデプロイされているリソース・グループの ID を取得します。
ibmcloud ks cluster get <cluster_name_or_ID> | grep "Resource Group ID"
-
ボリューム接続の詳細を表示するワーカー・ノードの ID を取得します。 Block Storage for Classic インスタンスと同じゾーン内にあるワーカー・ノードを選択してください。
ibmcloud ks worker ls --cluster <cluster_name_or_ID>
-
ワーカー・ノードの既存のボリューム接続のリストを確認します。
curl -X GET "https://containers.cloud.ibm.com/v2/storage/getAttachments?cluster=<cluster_ID>&worker=<worker_ID>" --header "X-Auth-Resource-Group-ID: <resource_group_ID>" --header "Authorization: <IAM_token>"
-
特定の接続の詳細を取得します。
curl -X GET "https://containers.cloud.ibm.com/v2/storage/getAttachment?cluster=<cluster_ID>&worker=<worker_ID>&volumeAttachmentID=<volume_attachment_ID>" --header "X-Auth-Resource-Group-ID: <resource_group_ID>" --header "Authorization: <IAM_token>"
IAM_token
- 現行セッションの IAM OAuth トークン。 この値は、
ibmcloud iam oauth-tokens
を実行して取得できます。 cluster_ID
- クラスターに割り当てられている固有 ID。 この ID は、
ibmcloud ks cluster ls
を実行して取得できます。 worker_ID
- ボリュームを接続するワーカー・ノードに割り当てられている固有 ID。 この値は、
ibmcloud ks worker ls -c <cluster_name>
を実行して取得できます。 volume_ID
- Block Storage for Classic ボリュームに割り当てられている固有 ID。
ibmcloud is volumes
を実行して、Block Storage for Classic ボリュームのリストを取得できます。 volume_attachment_ID
- ボリューム接続に割り当てられている固有 ID。 この ID は、
ibmcloud is volume <volume_ID>
を実行して取得できます。
VPC: CLI を使用した VPC ワーカー・ノードへのロー Block Storage for VPC の接続
Kubernetes Service CLI を使用して、VPC クラスター内のワーカー・ノードに対して未フォーマットのロー Block Storage for Classic を接続したり、切り離したりすることができます。
1 つのボリュームは 1 台のワーカー・ノードにのみ接続できます。 接続を成功させるために、ボリュームがワーカー・ノードと同じゾーンにあることを確認してください。
このトピックの説明は、VPC ワーカー・ノードにのみ当てはまります。 未フォーマットのロー・ブロック・ストレージをクラシック・ワーカー・ノードに接続する場合は、IBM Cloud Block Storage Attacher プラグインをインストールしてください。
始める前に
アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
-
ストレージ・ボリュームをリストし、接続するボリュームの ID をメモします。
ibmcloud is vols
-
クラスター内のワーカー・ノードをリストし、ボリュームを接続するワーカー・ノードの ID をメモします。
ibmcloud ks worker ls -c <cluster_name_or_ID>
-
Block Storage for Classic を VPC ワーカー・ノードに接続します。
ibmcloud ks storage attachment create --cluster <cluster_name_or_ID> --volume <volume> --worker <worker_ID>
CLI を使用した VPC ワーカー・ノードからのロー Block Storage for VPC の削除
ibmcloud ks storage attachment rm
コマンドを使用して、ワーカー・ノードからストレージを削除できます。
アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
-
ストレージ・ボリュームをリストし、削除するボリュームの ID をメモします。
ibmcloud is vols
-
ボリュームを接続するボリュームの詳細 (
worker-id
など) を取得します。worker-id
が、コマンド出力の Volume Attachment Instance Reference セクションの Instance name としてリストされます。ibmcloud is vol <volume-ID>
出力例
Volume Attachment Instance Reference Attachment type Instance ID Instance name Auto delete Attachment ID Attachment name data 0727_e18c10d7-7f18-48aa-b5ef-5ed163e54198 kube-bsaucubd07dhl66e4tgg-cluster-default-00000a19 false 0727-3bfe90b0-dc2d-498a-946b-8837a5dad7bc volume-attachment
-
クラスター内のワーカー・ノード上のストレージ接続をリストし、削除する接続 ID をメモします。
ibmcloud ks storage attachment ls -c <cluster> --worker <worker-id>
出力例:
Listing volume attachments... OK ID Name Status Type Volume ID Volume Name Worker ID 0111-1a111aaa-1111-1111-111a-aaa1a1a11a11 volume-attachment attached boot a001-f11ed1e1-1aa1-11dc-b11d-a0dc111b1111 dissuade-anointer-errand-handbrake kube-aa1111aa11aaaaa11aa1-cluster-name-default-00000110
-
ストレージ接続を削除します。
ibmcloud ks storage attachment rm --attachment <attachment-ID> -c <cluster> --worker <worker-ID>
-
ストレージがワーカー・ノードから削除されたことを確認します。
ibmcloud ks storage attachment ls -c <cluster-ID> --worker <worker-id>
ファイル・ストレージおよびブロック・ストレージの PVC データのバックアップとリストア
IBM Cloud Backup Restore Helm チャートを使用して、ファイル・ストレージまたはブロック・ストレージの永続ボリューム請求 (PVC) の保管データの 1 回限りのバックアップまたはスケジュールによるバックアップを作成できます。 データは、お客様が作成して所有している IBM Cloud Object Storage サービス・インスタンスに保管されます。 IBM Cloud Object Storage サービス・インスタンスにある既存のバックアップを使用して、クラスターの PVC にデータをリストアできます。
- Helm チャートをインストールするとどうなりますか?
- この Helm チャートをインストールすると、PVC データの 1 回限りのバックアップまたは定期的なバックアップを実行したり、IBM Cloud Object Storage にあるデータを PVC にリストアしたりする Kubernetes ポッドがクラスター内に作成されます。 バックアップやリストアの設定は、 Helm チャートとともに提供される
values.yaml
ファイルで行うか、helm install
コマンドでオプションを設定する。 - どのような制限に注意する必要がありますか?
- ブロック・ストレージの PVC のデータをバックアップまたはリストアする場合は、PVC をアプリにマウントしないでください。 ブロック・ストレージは、RWO アクセス・モードでマウントされます。 このアクセスでは、一度に 1 つのポッドしかブロック・ストレージにマウントできません。 データをバックアップまたはリストアするには、ストレージを使用するポッドを削除して、PVC をアンマウントする必要があります。 データのバックアップまたはリストアが終了したら、ポッドを再作成して、バックアップまたはリストアされた PVC をマウントできます。
- 始める前に必要なものは?
- IBM Cloud Object Storage を使用してデータをバックアップまたはリストアするには、IBM Cloud Object Storage サービス・インスタンスをセットアップし、そのサービスにアクセスするためのサービス資格情報を作成し、データを保持できるバケットを作成する必要があります。
IBM Cloud Object Storage サービス・インスタンスのセットアップ
バックアップするデータのリポジトリーとなる IBM Cloud Object Storage サービス・インスタンスを作成して構成します。
- HMAC 資格情報を使用する IBM Cloud Object Storage サービス・インスタンスを作成します。
- IBM Cloud Object Storage 資格情報を Kubernetes シークレットに保管します。
- 最初の IBM Cloud Object Storage バケットを作成します。
- サービス詳細ページのナビゲーションで、**「バケット」**をクリックします。
- 「バケットの作成」 をクリックします。 ダイアログ・ボックスが表示されます。
- バケットに対する固有の名前を入力します。 この名前は、IBM Cloud Object Storage 内で、すべてのリージョンおよびすべての IBM Cloud アカウントにわたって固有でなければなりません。
- **「回復力」**リストから、データに必要な可用性のレベルを選択します。 詳しくは、IBM Cloud Object Storage のリージョンとエンドポイントを参照してください。 VPC クラスターの場合は、直接エンドポイントをメモします。 例えば、
s3.direct.us.cloud-object-storage.appdomain.cloud
などです。 - **「ロケーション」**を変更して、データを保管するリージョンに設定します。 法律上の理由により、データをすべてのリージョンで保管できるとは限らないことに注意してください。
- 「作成」 をクリックします。
- バケットの IBM Cloud Object Storage ホスト名を取得します。
- 前のステップで作成したバケツ名をクリックします。
- サービス詳細ページのナビゲーションで、「バケット」>**「構成」**をクリックします。
- バケットのデータにアクセスするためのパブリック URL をメモします。
サービス・インスタンスの構成について詳しくは、IBM Cloud Object Storage 資料を参照してください。
IBM Cloud Object Storage を使用した PVC データのバックアップおよびリストア
IBM Cloud Backup Restore Helm チャートを使用して、ファイル・ストレージまたはブロック・ストレージの PVC のデータを IBM Cloud Object Storage にバックアップしたり、IBM Cloud Object Storage にあるデータをクラスター内の PVC にリストアしたりできます。
始める前に
-
データのバックアップまたはリストアが可能な PVC があることを確認してください。 PVC の作成方法について詳しくは、ファイル・ストレージをアプリに追加するおよびアプリへのブロック・ストレージの追加を参照してください。
-
ブロック・ストレージの PVC をバックアップする場合は、PVC がアプリにマウントされていないことを確認してください。 ブロック・ストレージは、RWO アクセス・モードでマウントされます。 このアクセスでは、一度に 1 つのポッドしかブロック・ストレージにマウントできません。 データをバックアップするには、ストレージをマウントするアプリ・ポッドを削除する必要があります。 PVC がポッドにマウントされているかどうかを調べるには、次のコマンドを実行します。
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
-
こちらの手順に従って、Helm クライアントをローカル・マシンにインストールし、IBM Cloud Helm チャート・リポジトリーをセットアップします。
-
アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
Helm チャートの ibm-storage-backup
ファイルを編集して適用するか、CLI から ibm-storage-restore
コマンドを実行して、
values.yaml
ポッドまたは helm install
ポッドをデプロイできます。
values.yaml
ファイルを編集して PVC をバックアップまたはリストアするには、以下のようにします。
-
最新のバージョンの Helm チャートをローカル・マシンにダウンロードします。
helm fetch --untar iks-charts/ibmcloud-backup-restore
-
nano
コマンドラインエディタでvalues.yaml
ファイルを開く。nano ibmcloud-backup-restore/values.yaml
-
PVC データをバックアップまたはリストアするように、Helm チャートを構成します。 複数の PVC のバックアップを構成できます。
values.yaml
ファイルを構成してバックアップ・ポッドを作成する例:image: repository: icr.io/iks-charts/ibmcloud-backup-restore pullPolicy: Always tag: latest ACCESS_KEY_ID: # Example: 10110abab1111bbb111aa1aaa111b1a1 SECRET_ACCESS_KEY: # Example: a1aba11aaa11b11b11aa1111a1111ba111111111a0b1b11a ENDPOINT: # Example: s3.us-east.cloud-object-storage.appdomain.cloud BUCKET_NAME: # Example: my-bucket BACKUP_NAME: # Example: my_backup PVC_NAMES: - # Example: my_pvc - # Optional example: my_pvc2 CHART_TYPE: # Example: backup or restore BACKUP_TYPE: # Example: incremental SCHEDULE_TYPE: # Example: periodic SCHEDULE_INFO: # Example: weekly
ACCESS_KEY_ID
- 先ほど取得した IBM Cloud Object Storage サービス資格情報のアクセス・キー ID を入力します。
SECRET_ACCESS_KEY
- 先ほど取得した IBM Cloud Object Storage サービス資格情報のシークレットのアクセス・キーを入力します。
ENDPOINT
- 先ほど取得したバケットのパブリック IBM Cloud Object Storage s3 API エンドポイントを入力します。
BUCKET_NAME
- バックアップ: 先ほど作成した IBM Cloud Object Storage バケットの名前を入力します。 このバケットが、バックアップの実行時に PVC データを保管するために使用されます。 リストア: バックアップが保管されている IBM Cloud Object Storage バケットの名前を入力します。
BACKUP_NAME
- バックアップ: IBM Cloud Object Storage に作成するバックアップの名前を入力します。 リストア: IBM Cloud Backup Restore Helm チャートを使用して IBM Cloud Object Storage に作成したバックアップの名前を入力します。 IBM Cloud Object Storage サービス・インスタンスに複数のフルバックアップが存在する場合は、PVC は最後のフルバックアップのデータを使用して復元されます。 増分バックアップが存在する場合は、PVC は、復元を開始した日までのすべての増分バックアップを含む、最後のフルバックアップのデータを使用して復元されます。
PVC_NAMES
- バックアップ: バックアップする PVC の名前を入力します。 複数の PVC をバックアップする場合は、各 PVC を PVC のリストに追加します。 クラスター内に存在するバックアップ可能な PVC をリストするには、
kubectl get pvc
を実行します。 リストア: IBM Cloud Object Storage にあるデータをリストアする PVC の名前を入力します。 一度に 1 つの PVC だけにデータをリストアできます。 クラスター内に存在する、データをリストア可能な PVC をリストするには、kubectl get pvc
を実行します。 CHART_TYPE
- デプロイするチャート・タイプの名前を入力します。 バックアップ・チャートをデプロイするには、
backup
と入力します。 リストア・チャートをデプロイするには、restore
と入力します。 BACKUP_TYPE
- バックアップの場合にのみ必要です。 フルバックアップを作成するには、
full
を入力します。新規ファイルまたは変更されたファイルのみをバックアップするには、incremental
を入力します。incremental
を選択した場合は、SCHEDULING_INFO
およびSCHEDULING_TYPE
オプションを指定する必要があります。BACKUP_TYPE
オプションを指定しない場合、デフォルトでフルバックアップが作成されます。 SCHEDULE_TYPE
- バックアップの場合にのみ必要です。 スケジュールされたバックアップを作成するには、
periodic
を入力します。1 回限りのバックアップを作成するには、このオプションを空のままにします。 定期的なバックアップを作成する場合は、SCHEDULE_INFO
オプションでバックアップ間隔を定義する必要があります。 SCHEDULE_INFO
- バックアップの場合にのみ必要です。 定期的なバックアップを作成する場合は、バックアップ・スケジュールを決定する必要があります。
hourly
、daily
、またはweekly
のいずれかを選択します。 このオプションを設定する場合は、SCHEDULE_TYPE
をperiodic
に設定する必要があります。
-
values.yaml
ファイルを保存して閉じます。 -
values.yaml
ファイルのカスタム設定を使用して、Helm チャートをインストールします。 Helm チャートをインストールしてバックアップまたはリストアを構成すると、ibm-storage-backup
ポッドまたはibm-storage-restore
ポッドがクラスターにデプロイされます。 バックアップ・ポッドは PVC のデータを IBM Cloud Object Storage にバックアップし、リストア・ポッドはデータを PVC にリストアします。<release_name>
を Helm チャートの名前に置き換えます。 バックアップ・ポッドとリストア・ポッドは、バックアップまたはリストアを実行する PVC と同じゾーンにインストールしてください。-
helm install
コマンドを使用して Helm チャートをインストールします。helm install <release_name> ./ibmcloud-backup-restore -n <namespace>
バックアップの出力例:
NAME: <release_name> LAST DEPLOYED: Mon Jan 20 09:17:02 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Thank you for installing: ibmcloud-backup-restore. Your release is named: <release_name> Please refer Chart README.md file for creating a sample PVC Please refer Chart RELEASE.md to see the release details/fixes
-
オプション:
helm install
コマンドでオプションを設定し、 Helm チャートをインストールする。--name
パラメーターを指定してリリースに名前を付けることができます。helm install <release_name> --set ACCESS_KEY_ID=<access_key_ID> --set SECRET_ACCESS_KEY=<secret_access_key> --set ENDPOINT=<public_bucket_endpoint> --set BUCKET_NAME=<bucket_name> --set BACKUP_NAME=<backup_name> --set PVC_NAMES[0]=<pvc_name1> --set PVC_NAMES[1]=<pvc_name2> --set CHART_TYPE=backup --set BACKUP_TYPE=<backup_type> --set SCHEDULE_TYPE=<schedule_type> --set SCHEDULE_INFO=<schedule_info> ./ibmcloud-backup-restore
-
-
データのバックアップまたはリストアが正常に完了したことを確認します。
バックアップ:
-
ibm-storage-backup
ポッドの状況が Running になっていることを確認します。kubectl get pods -A | grep backup
出力例
ibm-storage-backup 1/1 Running 0 64m
-
ibm-storage-backup
ポッドのログを参照して、バックアップが成功したことを確認します。 ログに... backup completed
のメッセージが表示されたら、バックアップは正常に完了したことになります。kubectl logs ibm-storage-backup
日次バックアップの出力例。
[2019-04-18 16:01:51,157] [utilities : 151] [INFO] *****************Start logging to ./Backup.log [2019-04-18 16:01:51,158] [backup : 48] [INFO] Starting backup: [2019-04-18 16:01:51,158] [configureOS : 66] [INFO] Configuring duplicity with IBM CloudObjectStorage i.e s3. [2019-04-18 16:01:51,158] [backup : 62] [INFO] Configuration done!!! [2019-04-18 16:01:51,158] [backup : 78] [INFO] Got all required input from config file!! [2019-04-18 16:01:52,366] [backup : 119] [WARNING] Incremental backup was not created [2019-04-18 16:01:52,366] [backup : 120] [INFO] duplicity --no-encryption incremental /myvol s3://s3.us-south.cloud-object-storage.appdomain.cloud/mybucket/helm-backup command failed due to Fatal Error: Unable to start incremental backup. Old signatures not found and incremental specified [2019-04-18 16:01:52,367] [backup : 121] [INFO] A full backup is required before incremental backups can begin. Creating a one-time full backup and will run incremental backups for scheduled backups. [2019-04-18 16:01:54,357] [backup : 129] [INFO] Full backup completed [2019-04-18 16:01:54,357] [backup : 130] [INFO] Local and Remote metadata are synchronized, no sync needed. Last full backup date: none --------------[ Backup Statistics ]-------------- StartTime 1555603313.31 (Thu Apr 18 16:01:53 2019) EndTime 1555603313.32 (Thu Apr 18 16:01:53 2019) ElapsedTime 0.01 (0.01 seconds) SourceFiles 3 SourceFileSize 20495 (20.0 KB) NewFiles 3 NewFileSize 20495 (20.0 KB) DeletedFiles 0 ChangedFiles 0 ChangedFileSize 0 (0 bytes) ChangedDeltaSize 0 (0 bytes) DeltaEntries 3 RawDeltaSize 15 (15 bytes) TotalDestinationSizeChange 183 (183 bytes) Errors 0 ------------------------------------------------- [2019-04-18 16:01:54,357] [backup : 162] [INFO] Scheduling backup as per configurations, please don't stop this program or run this in background !!! [2019-04-18 16:01:54,358] [backup : 166] [INFO] Schedule info is: ['daily'] [2019-04-18 16:01:54,358] [backup : 172] [INFO] Scheduled for daily!!!
-
-
データが正常にバックアップまたはリストアされたことを確認します。
-
バックアップ:
- IBM Cloud Object Storage のリソース・リストで IBM Cloud サービス・インスタンスを見つけます。
- ナビゲーションからバケットを選択し、バックアップ構成で使用したバケットをクリックします。 バックアップが、バケット内のオブジェクトとして表示されます。
- 圧縮ファイルを確認します。
*.gz
ファイルをダウンロードし、ファイルを解凍して、バックアップ・データを検証できます。
-
リストア:
-
リストアされたデータが含まれている PVC をマウントするポッドの
deployment.yaml
ファイルを作成します。 以下の例では、PVC をnginx
マウント・ディレクトリーにマウントする/test
ポッドをデプロイします。apiVersion: apps/v1 kind: Deployment metadata: name: restore labels: app: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx volumeMounts: - name: my-volume # Example: my_volume mountPath: /test # Example: /test volumes: - name: my-volume # Example: my_volume persistentVolumeClaim: claimName: my-actual-pvc-name # Example: my_pvc
spec.containers.image
- 使用するイメージの名前。 IBM Cloud Container Registry アカウント内の使用可能なイメージをリストするには、
ibmcloud cr image-list
を実行します。 spec.containers.name
- クラスターにデプロイするコンテナーの名前。
spec.containers.volumeMounts.mountPath
- コンテナー内でボリュームがマウントされるディレクトリーの絶対パス。 マウント・パスに書き込まれるデータは、物理ブロック・ストレージ・インスタンスのルート・ディレクトリーに保管されます。 異なるアプリ間でボリュームを共有したい場合は、アプリごとに ボリュームのサブパスを指定できます。
spec.containers.volumeMounts.name
- ポッドにマウントするボリュームの名前。
volumes.name
- ポッドにマウントするボリュームの名前。 通常、この名前は
volumeMounts/name
と同じです。 volumes.persistentVolumeClaim.claimName
- 使用する PV をバインドする PVC の名前。
-
デプロイメントを作成します。
kubectl apply -f deployment.yaml
-
ポッドの状況が「Running」であることを確認します。
ibm-storage-restore
ポッドの状況が「Completed」や「CrashLoopBackOff」に達しない場合、データのリストアに失敗した可能性があります。kubectl logs ibm-storage-restore
を実行して、失敗の根本原因を見つけてください。kubectl get pods | grep restore
出力例
restore-7dfc6f4c78-wkcqp 1/1 Running 0 3m54s
-
ポッドにログインします。
kubectl exec <pod_name> -it bash
-
デプロイメント YAML で指定したマウント・ディレクトリーにナビゲートします。
cd <mount_directory>
-
マウント・ディレクトリー内のファイルをリストして、すべてのデータがマウント・ディレクトリーにリストアされたことを確認します。
ls
-
クラスターから Helm チャートのインストールを削除します。 この手順は、ブロック・ストレージの PVC にデータをリストアした場合に必要です。 ブロック・ストレージは、RWO アクセス・モードでマウントされます。 このアクセスでは、一度に 1 つのポッドしかブロック・ストレージにマウントできません。
ibm-storage-restore
ポッドが既に PVC をマウントしているので、このポッドを削除して PVC を解放して、PVC をクラスター内の別のポッドにマウントできるようにする必要があります。helm uninstall <release_name> -n <namespace>
-
バックアップが正常にリストアされました。 これで、PV をバインドする PVC をクラスター内の他の任意のポッドにマウントして、リストアされたファイルにアクセスすることができます。 バックアップされていたコンテナー・データに非 root ユーザーが含まれていた場合は、新規コンテナーに非 root の権限を追加する必要があります。 詳しくは、非 root ユーザーのボリューム・アクセス権限の追加を参照してください。
-
-
ストレージ・ボリューム用の IBM Cloud Monitoring のセットアップ
ストレージ・ボリュームを使用しているワークロードに関するアラートを IBM Cloud Monitoring にセットアップします。 詳しくは、アラートを参照してください。
ストレージ・ボリュームがダウンすると、ストレージを使用しているアプリ・ポッドのファイル・システム I/O が低下したり、ネットワーク・エラーが発生したり、レプリカの数の減少につながるクラッシュが発生したりします。 IBM Cloud Monitoring でアラートを設定すると、アプリのファイルシステム操作が特定のしきい値を下回った場合、ネットワークエラーが発生した場合、またはアプリのポッドが Ready
の状態に達しなかった場合に通知を受け取ることができます。
-
コンソールから、ストレージボリュームのアラートを設定するクラスタを選択します。
-
**「モニタリング」セクションで、「接続」をクリックして、既存の IBM Cloud Monitoring インスタンスをクラスターに接続します。 インスタンスがない場合は、「インスタンスの作成 (Create an instance)」**をクリックして作成します。 IBM Cloud Monitoring インスタンスのセットアップ方法について詳しくは、インスタンスのプロビジョニングを参照してください。
-
**「起動」**ボタンをクリックし、IBM Cloud Monitoring ダッシュボードを開きます。
-
クラスター内で実行されているアプリのファイル・システム使用率アラートを作成します。
- IBM Cloud Monitoring コンソールから、「概要」 > **「ワークロード」**をクリックします。
- アプリがデプロイされている名前空間を選択します。 アプリを見つけて、アプリ上の矢印アイコンをクリックし、**「Kubernetes Pod の概要 (Kubernetes Pod overview)」**を選択します。
- **「ファイル・システムの使用率 (File System Utilization)」セクションで、「ポッド別のファイル I/O 処理能力 (File I/O Bandwidth by Pod)」**タイルを確認します。
- 過去 1 日または 1 週間の時間枠のファイル I/O の処理能力を確認して、平均処理能力を判別します。 平均帯域幅をしきい値として使用し、ファイルI/O帯域幅が一定時間平均を下回った場合にアラートを設定することができます。 たとえば、アプリの平均ファイル I/O 帯域幅が 300B/s である場合、ネットワーク利用率が 300B/s 未満の状態が一定時間続いた場合にアラートを作成できます。
- **「ポッド別のファイル I/O の処理能力 (File I/O Bandwidth by Pod)タイルで、「オプション」メニューをクリックしてから「アラートの作成 (Create alert)」**をクリックしてアラートを作成します。
- アラート・メニューの**「通知」**セクションを開き、アラート通知チャネルを作成または選択します。
- アラートを保存します。
- クラスターにデプロイされているすべてのアプリについて、これらのステップを繰り返します。
- 構成したしきい値を編集して手動でアラートをトリガーすることで、作成したアラートをテストします。 例えば、使用率が 300 バイト/秒を下回っている状態が 5 分間続くとトリガーされるようにファイル・システム使用率のアラートを設定した場合、しきい値をアプリの現在の 5 分間の使用率の値より大きくし、
at least once
オプションを選択します。 - アラートが 5 分経過後にトリガーされることを確認します。 アラートを確認したら、値を最初に設定した値に戻します。
-
クラスター内で実行されているアプリのネットワーク使用率アラートを作成します。
- IBM Cloud Monitoring コンソールから、「概要」 > **「ワークロード」**をクリックします。
- アプリがデプロイされている名前空間を選択します。 アプリを見つけて、アプリ上の矢印アイコンをクリックし、**「Kubernetes Pod の概要 (Kubernetes Pod overview)」**を選択します。
- **「ネットワーク使用率 (Network Utilization)」セクションで、「ポッド別のネットワーク要求カウント (Network Request Count by Pod)」**タイルを確認します。
- 過去 1 日または 1 週間の時間枠のポッドごとの平均ネットワーク要求カウントを確認して、しきい値を判別します。
- **「ポッド別のネットワーク要求カウント (Network Request Count by Pod)タイルで、「オプション」メニューをクリックしてから「アラートの作成 (Create alert)」**をクリックしてアラートを作成します。 アラートのパラメーターを、先ほど確認したしきい値に基づいて設定します。 例えば、ネットワーク利用率が一定時間閾値を下回ったままであれば、アラートがトリガーされる。
- アラート・メニューの**「通知」**セクションを開き、アラート通知チャネルを作成または選択します。
- アラートを保存します。
- クラスターにデプロイされているすべてのアプリについて、これらのステップを繰り返します。
- 構成したしきい値を編集して手動でアラートをトリガーすることで、作成したアラートをテストします。 例えば、ポッドごとのネットワーク要求の数が 1 秒あたり 3 つを下回っている状態が 5 分間続くとトリガーされるアラートを設定した場合、アラートのしきい値を編集して 5 分間で確認されたしきい値より少なくなるようにし、
at least once
オプションを選択します。 - アラートが 5 分経過後にトリガーされることを確認します。 アラートを確認したら、値を最初に設定した値に戻します。
-
クラスター内で実行されているアプリの使用可能なポッドの数のアラートを作成します。
- IBM Cloud Monitoring コンソールから、「概要」 > **「ワークロード」**をクリックします。
- アプリがデプロイされている名前空間を選択します。 アプリを見つけて、アプリ上の矢印アイコンをクリックし、**「Kubernetes Pod の概要 (Kubernetes Pod overview)」**を選択します。
- **「ポッドの正常性 (Pod Health)」セクションで、「使用可能なポッドの数 (Pod Availability)」**タイルを確認します。
- 過去 1 日または 1 週間の時間枠の使用可能なポッドの数の平均を確認して、しきい値を判別します。
- アプリの構成ファイルで、要求されたレプリカの数を確認します。 この数をしきい値として使用して、使用可能なポッドの数が、アプリに対して要求したレプリカの数より少ないときに、アラートを送信するように設定できます。 アプリに対してレプリカを 3 つ要求した場合、使用可能なポッドの数が、要求されたレプリカの数を下回っている状態が一定期間 (例えば 30 分間) 続くとトリガーされる、アラートを設定できます。 この例では、使用可能なポッドの数が、要求されたレプリカの数である 3 つよりも少ないままであるときに、アラートがトリガーされます。
- **「使用可能なポッドの数 (Pod Availability)」タイルで、「オプション」メニューをクリックしてから「アラートの作成 (Create alert)」**をクリックしてアラートを作成します。 アラートのパラメーターを、先ほど確認したしきい値と、要求したアプリ・レプリカに基づいて設定します。
- アラート・メニューの**「通知」**セクションを開き、アラート通知チャネルを作成または選択します。
- アラートを保存します。
- クラスターにデプロイされているすべてのアプリについて、これらのステップを繰り返します。
- 構成したしきい値を編集して手動でアラートをトリガーすることで、作成したアラートをテストします。 例えば、使用可能なポッドの数が 3 つを下回っている状態が 5 分間続くとトリガーされるように、使用可能なポッドの数のアラートを設定した場合は、そのしきい値を変更して、4 つを下回っている状態が 5 分間続くとアラートがトリガーされるようにし、
at least once
オプションを選択します。 - アラートが 5 分経過後にトリガーされることを確認します。 アラートを確認したら、値を最初に設定した値に戻します。
IBM Cloud Monitoring アラートがトリガーされた場合の永続ストレージのトラブルシューティング
アラートがトリガーされたら、IBM Cloud Monitoring でアラートの詳細を確認し、永続ストレージ、アプリ、ワーカー・ノード、およびクラスターのトラブルシューティング・ガイドを確認してアラートの根本原因を見つけます。 セットアップしたアラートは、ストレージ・ボリュームの問題に関連しているのではなく、アプリ、ワーカー・ノード、またはクラスター内で発生した問題に関連している可能性もあります。