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) を作成する必要があります。

マウントされていない未フォーマットのロー・ブロック・ストレージを非 SDS ワーカー・ノードに対して手動で追加したことを確認します。
アカウントにログインします。該当する場合は、適切なリソース・グループをターゲットにします。クラスターのコンテキストを設定します。
Block Storage Attacher プラグインをインストールします。

PV の作成を準備します。
- mkpvyaml コンテナーを使用した場合は、以下のコマンドを実行します。
  1. pv-<cluster_name>.yaml ファイルを開きます。
```
nano pv-<cluster_name>.yaml
```
  2. PV の構成を確認します。
- ブロック・ストレージを手動で追加した場合は、次のようにします。**
  1. pv.yaml ファイルを作成します。次のコマンドによって、nano エディターを使用してこのファイルが作成されます。
```
nano pv.yaml
```
  2. ブロック・ストレージ・デバイスの詳細を 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 を接続したり、切り離したりすることができます。

始める前に

アカウントにログインします。該当する場合は、適切なリソース・グループをターゲットにします。クラスターのコンテキストを設定します。

ストレージ・ボリュームをリストし、接続するボリュームの 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 バケットを作成します。
1. サービス詳細ページのナビゲーションで、**「バケット」**をクリックします。
2. 「バケットの作成」 をクリックします。ダイアログ・ボックスが表示されます。
3. バケットに対する固有の名前を入力します。この名前は、IBM Cloud Object Storage 内で、すべてのリージョンおよびすべての IBM Cloud アカウントにわたって固有でなければなりません。
4. **「回復力」**リストから、データに必要な可用性のレベルを選択します。詳しくは、IBM Cloud Object Storage のリージョンとエンドポイントを参照してください。 VPC クラスターの場合は、直接エンドポイントをメモします。例えば、s3.direct.us.cloud-object-storage.appdomain.cloud などです。
5. **「ロケーション」**を変更して、データを保管するリージョンに設定します。法律上の理由により、データをすべてのリージョンで保管できるとは限らないことに注意してください。
6. 「作成」 をクリックします。
バケットの IBM Cloud Object Storage ホスト名を取得します。
1. 前のステップで作成したバケツ名をクリックします。
2. サービス詳細ページのナビゲーションで、「バケット」>**「構成」**をクリックします。
3. バケットのデータにアクセスするためのパブリック 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>"
```
IBM Cloud Object Storage サービス資格情報、バケット名、およびバケットのホスト名を取得します。
こちらの手順に従って、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!!!

データが正常にバックアップまたはリストアされたことを確認します。
- バックアップ:
  1. IBM Cloud Object Storage のリソース・リストで IBM Cloud サービス・インスタンスを見つけます。
  2. ナビゲーションからバケットを選択し、バックアップ構成で使用したバケットをクリックします。バックアップが、バケット内のオブジェクトとして表示されます。
  3. 圧縮ファイルを確認します。 *.gz ファイルをダウンロードし、ファイルを解凍して、バックアップ・データを検証できます。
- リストア:
  1. リストアされたデータが含まれている 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 の名前。
  2. デプロイメントを作成します。
```
kubectl apply -f deployment.yaml
```
  3. ポッドの状況が「Running」であることを確認します。
    
    ibm-storage-restore ポッドの状況が「Completed」や「CrashLoopBackOff」に達しない場合、データのリストアに失敗した可能性があります。 kubectl logs ibm-storage-restore を実行して、失敗の根本原因を見つけてください。
```
kubectl get pods | grep restore
```
    出力例
```
restore-7dfc6f4c78-wkcqp                  1/1     Running             0          3m54s
```
  4. ポッドにログインします。
```
kubectl exec <pod_name> -it bash
```
  5. デプロイメント YAML で指定したマウント・ディレクトリーにナビゲートします。
```
cd <mount_directory>
```
  6. マウント・ディレクトリー内のファイルをリストして、すべてのデータがマウント・ディレクトリーにリストアされたことを確認します。
```
ls
```
  7. クラスターから Helm チャートのインストールを削除します。この手順は、ブロック・ストレージの PVC にデータをリストアした場合に必要です。ブロック・ストレージは、RWO アクセス・モードでマウントされます。このアクセスでは、一度に 1 つのポッドしかブロック・ストレージにマウントできません。 ibm-storage-restore ポッドが既に PVC をマウントしているので、このポッドを削除して PVC を解放して、PVC をクラスター内の別のポッドにマウントできるようにする必要があります。
```
helm uninstall <release_name> -n <namespace>
```
  8. バックアップが正常にリストアされました。これで、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 ダッシュボードを開きます。
クラスター内で実行されているアプリのファイル・システム使用率アラートを作成します。
1. IBM Cloud Monitoring コンソールから、「概要」 > **「ワークロード」**をクリックします。
2. アプリがデプロイされている名前空間を選択します。アプリを見つけて、アプリ上の矢印アイコンをクリックし、**「Kubernetes Pod の概要 (Kubernetes Pod overview)」**を選択します。
3. **「ファイル・システムの使用率 (File System Utilization)」セクションで、「ポッド別のファイル I/O 処理能力 (File I/O Bandwidth by Pod)」**タイルを確認します。
4. 過去 1 日または 1 週間の時間枠のファイル I/O の処理能力を確認して、平均処理能力を判別します。平均帯域幅をしきい値として使用し、ファイルI/O帯域幅が一定時間平均を下回った場合にアラートを設定することができます。たとえば、アプリの平均ファイル I/O 帯域幅が 300B/s である場合、ネットワーク利用率が 300B/s 未満の状態が一定時間続いた場合にアラートを作成できます。
5. **「ポッド別のファイル I/O の処理能力 (File I/O Bandwidth by Pod)タイルで、「オプション」メニューをクリックしてから「アラートの作成 (Create alert)」**をクリックしてアラートを作成します。
6. アラート・メニューの**「通知」**セクションを開き、アラート通知チャネルを作成または選択します。
7. アラートを保存します。
8. クラスターにデプロイされているすべてのアプリについて、これらのステップを繰り返します。
9. 構成したしきい値を編集して手動でアラートをトリガーすることで、作成したアラートをテストします。例えば、使用率が 300 バイト/秒を下回っている状態が 5 分間続くとトリガーされるようにファイル・システム使用率のアラートを設定した場合、しきい値をアプリの現在の 5 分間の使用率の値より大きくし、at least once オプションを選択します。
10. アラートが 5 分経過後にトリガーされることを確認します。アラートを確認したら、値を最初に設定した値に戻します。
クラスター内で実行されているアプリのネットワーク使用率アラートを作成します。
1. IBM Cloud Monitoring コンソールから、「概要」 > **「ワークロード」**をクリックします。
2. アプリがデプロイされている名前空間を選択します。アプリを見つけて、アプリ上の矢印アイコンをクリックし、**「Kubernetes Pod の概要 (Kubernetes Pod overview)」**を選択します。
3. **「ネットワーク使用率 (Network Utilization)」セクションで、「ポッド別のネットワーク要求カウント (Network Request Count by Pod)」**タイルを確認します。
4. 過去 1 日または 1 週間の時間枠のポッドごとの平均ネットワーク要求カウントを確認して、しきい値を判別します。
5. **「ポッド別のネットワーク要求カウント (Network Request Count by Pod)タイルで、「オプション」メニューをクリックしてから「アラートの作成 (Create alert)」**をクリックしてアラートを作成します。アラートのパラメーターを、先ほど確認したしきい値に基づいて設定します。例えば、ネットワーク利用率が一定時間閾値を下回ったままであれば、アラートがトリガーされる。
6. アラート・メニューの**「通知」**セクションを開き、アラート通知チャネルを作成または選択します。
7. アラートを保存します。
8. クラスターにデプロイされているすべてのアプリについて、これらのステップを繰り返します。
9. 構成したしきい値を編集して手動でアラートをトリガーすることで、作成したアラートをテストします。例えば、ポッドごとのネットワーク要求の数が 1 秒あたり 3 つを下回っている状態が 5 分間続くとトリガーされるアラートを設定した場合、アラートのしきい値を編集して 5 分間で確認されたしきい値より少なくなるようにし、at least once オプションを選択します。
10. アラートが 5 分経過後にトリガーされることを確認します。アラートを確認したら、値を最初に設定した値に戻します。
クラスター内で実行されているアプリの使用可能なポッドの数のアラートを作成します。
1. IBM Cloud Monitoring コンソールから、「概要」 > **「ワークロード」**をクリックします。
2. アプリがデプロイされている名前空間を選択します。アプリを見つけて、アプリ上の矢印アイコンをクリックし、**「Kubernetes Pod の概要 (Kubernetes Pod overview)」**を選択します。
3. **「ポッドの正常性 (Pod Health)」セクションで、「使用可能なポッドの数 (Pod Availability)」**タイルを確認します。
4. 過去 1 日または 1 週間の時間枠の使用可能なポッドの数の平均を確認して、しきい値を判別します。
5. アプリの構成ファイルで、要求されたレプリカの数を確認します。この数をしきい値として使用して、使用可能なポッドの数が、アプリに対して要求したレプリカの数より少ないときに、アラートを送信するように設定できます。アプリに対してレプリカを 3 つ要求した場合、使用可能なポッドの数が、要求されたレプリカの数を下回っている状態が一定期間 (例えば 30 分間) 続くとトリガーされる、アラートを設定できます。この例では、使用可能なポッドの数が、要求されたレプリカの数である 3 つよりも少ないままであるときに、アラートがトリガーされます。
6. **「使用可能なポッドの数 (Pod Availability)」タイルで、「オプション」メニューをクリックしてから「アラートの作成 (Create alert)」**をクリックしてアラートを作成します。アラートのパラメーターを、先ほど確認したしきい値と、要求したアプリ・レプリカに基づいて設定します。
7. アラート・メニューの**「通知」**セクションを開き、アラート通知チャネルを作成または選択します。
8. アラートを保存します。
9. クラスターにデプロイされているすべてのアプリについて、これらのステップを繰り返します。
10. 構成したしきい値を編集して手動でアラートをトリガーすることで、作成したアラートをテストします。例えば、使用可能なポッドの数が 3 つを下回っている状態が 5 分間続くとトリガーされるように、使用可能なポッドの数のアラートを設定した場合は、そのしきい値を変更して、4 つを下回っている状態が 5 分間続くとアラートがトリガーされるようにし、at least once オプションを選択します。
11. アラートが 5 分経過後にトリガーされることを確認します。アラートを確認したら、値を最初に設定した値に戻します。

IBM Cloud Monitoring アラートがトリガーされた場合の永続ストレージのトラブルシューティング

アラートがトリガーされたら、IBM Cloud Monitoring でアラートの詳細を確認し、永続ストレージ、アプリ、ワーカー・ノード、およびクラスターのトラブルシューティング・ガイドを確認してアラートの根本原因を見つけます。セットアップしたアラートは、ストレージ・ボリュームの問題に関連しているのではなく、アプリ、ワーカー・ノード、またはクラスター内で発生した問題に関連している可能性もあります。