クラスターへの Portworx のインストール
IBM Cloud カタログから、Portworx サービス・インスタンスをプロビジョンします。 サービス・インスタンスを作成すると、最新の Portworx Enterprise Edition (px-enterprise
) が、Helm を使用してクラスターにインストールされます。 さらに、 Stork は IBM Cloud Kubernetes Service クラスターにもインストールされます。 Stork とは Portworx ストレージのスケジューラーです。 Storkを使えば、ポッドとそのデータをコロケーションし、 Portworx ボリュームのスナップショットを作成、リストアすることができる。
Portworx の更新方法と削除方法については、 Portworxの更新 および Portworxの削除 を参照してください。
Portworx Enterprise および Portworx Backup のデフォルトのインストール方法は、モントリオール地域のプライベート専用クラスタではまだサポートされていません。 モントリオールのプライベート専用クラスタに Portworx Enterprise または Portworx Backup をインストールする必要がある場合は、 Portworx サポートにお問い合わせください。 詳しくは、 Portworx サポートを ご覧ください
始める前に
-
IBM Cloud Kubernetes Service クラスターを作成するための正しい 許可 があることを確認します。
-
クラシック・クラスター内で非 SDS ワーカー・ノードを使用する場合は、ワーカー・ノードにブロック・ストレージ・デバイスを追加します。
-
Portworx の構成とメタデータの保管に、内部 Portworx キー/値データベース (KVDB) を使用するか、それとも Databases for etcd サービス・インスタンスを作成するかを選択します。
-
Portworx ボリュームを暗号化するかどうかを決定します。 ボリュームを暗号化するには、IBM Key Protect インスタンスまたは Hyper Protect Crypto Services インスタンスをセットアップして、サービス情報を Kubernetes シークレットに保管する必要があります。
-
Container Registry からイメージをプルできるように、
default
名前空間にあるイメージ・プル・シークレットをkube-system
名前空間にコピーします。 名前空間の Kubernetes サービス・アカウントにイメージ・プル・シークレットを追加しますkube-system
。 -
クラスターを Portworx 災害復旧構成に含めるかどうかを決定します。 詳しくは、Portworx を使用した災害復旧のセットアップを参照してください。
-
Portworx ジャーナル用に別のデバイスを接続した場合は、ワーカー・ノードにログインしているときに
lsblk
を実行してデバイス・パスを取得するようにしてください。 -
Portworx KVDB 用に別個のデバイスを接続した場合は、ワーカー・ノードにログインしているときに
lsblk
を実行してデバイス・パスを取得するようにしてください。 -
アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
Portworx をインストールするには、次のようにします。
-
IBM Cloud カタログから Portworx サービスを開き、以下のようにフィールドを埋める:
-
IBM Cloud Kubernetes Service クラスターが配置されているリージョンを選択します。
-
Portworx の料金情報を確認します。
-
Portworx サービス・インスタンスの名前を入力します。
-
クラスターが含まれるリソース・グループを選択します。
-
**「タグ (Tag)」**フィールドに、Portworx をインストールするクラスターの名前を入力します。 Portworxサービス・インスタンスを作成した後、Portworxをインストールしたクラスターを見ることはできません。 後でクラスターを見つけやすくするために、クラスターの名前と追加情報をタグとして入力してください。
-
IBM Cloud の API キーを入力して、アクセス可能なクラスターのリストを取得します。 API キーがない場合は、ユーザー API キーの管理を参照してください。 API キーを入力すると、**「Kubernetes または OpenShift クラスター名 (Kubernetes or OpenShift cluster name)」**フィールドが表示されます。
-
固有の Portworx クラスター名を入力します。
-
**「クラウド・ドライブ」**メニューで、以下のようにします。
- Portworx 用に Block Storage for VPC を動的にプロビジョンするには、「クラウド・ドライブの使用」(VPC クラスターのみ) を選択します。 **「クラウド・ドライブの使用」を選択した後、プロビジョンするブロック・ストレージ・ドライブの「ストレージ・クラス名」と「サイズ」**を選択します。
- ワーカー・ノードに既に接続されているブロック・ストレージを使用するには、「既に接続されているドライブの使用」(クラシック、VPC、または Satellite) を選択します。
-
**「Portworx メタデータのキー/値ストア (Portworx metadata key-value store)」ドロップダウンから、Portworx メタデータを保管するために使用するキー/値ストアのタイプを選択します。 Portworx インストール時に自動的にキー/値ストアを作成するには「Portworx KVDB」を選択し、既存の Databases for etcd インスタンスを使用する場合は「Databases for etcd」**を選択します。 **「Databases for etcd」を選択すると、「Etcd API エンドポイント (Etcd API endpoints)」フィールドおよび「Etcd シークレット名 (Etcd secret name)」**フィールドが表示されます。
-
名前空間: Portworx リソースをデプロイする名前空間を入力します。
-
Databases for etcd を使用する場合のみ必須: Databases for etcd サービス・インスタンスの情報を入力します。
- etcd エンドポイント、および Databases for etcd サービス・インスタンス用に作成した Kubernetes シークレットの名前を取得します。
- **「Etcd API エンドポイント (Etcd API endpoints)」**フィールドに、前の手順で取得した Databases for etcd サービス・インスタンスの API エンドポイントを入力します。 エンドポイントは、必ず
etcd:<etcd_endpoint1>;etcd:<etcd_endpoint2>
の形式で入力してください。 複数のエンドポイントがある場合は、すべてのエンドポイントを追加して、それらをセミコロン (;
) で区切ります。 - **「Etcd シークレット名 (Etcd secret name)」**フィールドに、Databases for etcd サービスの資格情報を保管するためにクラスター内に作成した Kubernetes シークレットの名前を入力します。
-
**「Kubernetes または OpenShift クラスター名 (Kubernetes or OpenShift cluster name)」**ドロップダウン・リストで、Portworx をインストールするクラスターを選択します。 クラスターがリストされていない場合は、正しい IBM Cloud リージョンを選択したことを確認してください。 リージョンが正しい場合は、クラスターを表示および使用するための正しい権限があることを確認してください。 Portworx の最小ハードウェア要件を満たすクラスタを選択していることを確認してください。
-
オプション: Portworx シークレット・ストア・タイプ ドロップダウン・リストから、ボリューム暗号鍵の保管に使用するシークレット・ストア・タイプを選択します。
- Kubernetes シークレット (Kubernetes Secret): ボリュームを暗号化するための独自のカスタム鍵を、クラスター内の Kubernetes シークレットに保管する場合は、このオプションを選択します。 このシークレットは、Portworx をインストールする前に存在していてはいけません。 シークレットは、Portworx をインストールした後に作成できます。 詳しくは、 Portworx のドキュメントを参照。
- IBM Key Protect: ボリュームの暗号化に IBM Key Protect 内のルート鍵を使用する場合は、このオプションを選択します。 Portworx をインストールする前に、手順に従って IBM Key Protect サービス・インスタンスを作成し、
portworx
名前空間内の Kubernetes シークレットに、サービス・インスタンスにアクセスするための資格情報を保管してください。
-
オプション: ジャーナル・デバイスまたは KVDB デバイスをセットアップする場合は、詳細オプションフィールドにデバイスの詳細を入力します。 ジャーナル・デバイスの場合は、以下のオプションから選択します。
j;auto
を入力して、Portworx がジャーナルに使用するブロック・ストレージ・デバイスの 1 つに 3 GB 区画を自動的に作成できるようにします。- ジャーナルに特定のデバイスを使用するには、
j;</device/path>
を入力します。 例えば、/dev/vde
にあるディスクを使用するには、j;/dev/vde
と入力します。 ジャーナルに使用するデバイスのパスを見つけるには、ワーカー・ノードにログインし、lsblk
を実行します。 kvdb_dev;<device path>
を入力して、内部 KVDB データを保管するデバイスを指定します。 例えば、kvdb_dev;/dev/vdd
です。 使用するデバイスのパスを見つけるには、ワーカー・ノードにログインしてlsblk
を実行します。 KVDB データ用に特定のデバイスを使用するには、3GB の使用可能なストレージ・デバイスを用意するか、少なくとも 3 つのワーカー・ノード上にある必要があります。 デバイスは、各ワーカー・ノード上の同じパス上にも存在する必要があります。 例:/dev/vdd
。
-
-
**「作成」**をクリックしてクラスターへの Portworx のインストールを開始します。 このプロセスは、完了まで数分かかることがあります。 サービスの詳細ページが開き、Portworx のインストールの検証方法、永続ボリューム請求 (PVC) の作成方法、および PVC のアプリへのマウント方法に関する説明が表示されます。
-
IBM Cloud リソースリストから、作成した Portworx サービスを見つけてください。
-
**「状況」**列で、インストールが成功したか失敗したかを確認します。 状況が更新されるまで数分かかる場合があります。
-
**「状況」**が
Provision failure
に変わった場合は、手順に従って、インストールが失敗した理由のトラブルシューティングを開始します。 -
**「状況」**が
Provisioned
に変わった場合は、Portworx のインストールが正常に完了したこと、およびすべてのローカル・ディスクが認識され、Portworx ストレージ層に追加されたことを確認します。-
kube-system
名前空間内の Portworx ポッドをリスト表示します。 インストールが正常に実行された場合は、portworx
、stork
、およびstork-scheduler
というポッドがそれぞれ 1 つ以上表示されます。 ポッドの数は、Portworx クラスター内のワーカー・ノードの数と等しくなります。 すべてのポッドがRunning
状態である必要があります。kubectl get pods -n kube-system | grep 'portworx\|stork'
出力例
portworx-594rw 1/1 Running 0 20h portworx-rn6wk 1/1 Running 0 20h portworx-rx9vf 1/1 Running 0 20h stork-6b99cf5579-5q6x4 1/1 Running 0 20h stork-6b99cf5579-slqlr 1/1 Running 0 20h stork-6b99cf5579-vz9j4 1/1 Running 0 20h stork-scheduler-7dd8799cc-bl75b 1/1 Running 0 20h stork-scheduler-7dd8799cc-j4rc9 1/1 Running 0 20h stork-scheduler-7dd8799cc-knjwt 1/1 Running 0 20h
-
いずれかの
portworx
ポッドにログインして、Portworx クラスターのステータスをリスト表示します。kubectl exec <portworx_pod> -it -n kube-system -- /opt/pwx/bin/pxctl status
出力例
Status: PX is operational License: Trial (expires in 30 days) Node ID: 10.176.48.67 IP: 10.176.48.67 Local Storage Pool: 1 pool POOL IO_PRIORITY RAID_LEVEL USABLE USED STATUS ZONE REGION 0 LOW raid0 20 GiB 3.0 GiB Online dal10 us-south Local Storage Devices: 1 device Device Path Media Type Size Last-Scan 0:1 /dev/mapper/3600a09803830445455244c4a38754c66 STORAGE_MEDIUM_MAGNETIC 20 GiB 17 Sep 18 20:36 UTC total - 20 GiB Cluster Summary Cluster ID: mycluster Cluster UUID: a0d287ba-be82-4aac-b81c-7e22ac49faf5 Scheduler: kubernetes Nodes: 2 node(s) with storage (2 online), 1 node(s) without storage (1 online) IP ID StorageNode Used Capacity Status StorageStatus Version Kernel OS 10.184.58.11 10.184.58.11 Yes 3.0 GiB 20 GiB Online Up 1.5.0.0-bc1c580 4.4.0-133-generic Ubuntu 20.04.5 LTS 10.176.48.67 10.176.48.67 Yes 3.0 GiB 20 GiB Online Up (This node) 1.5.0.0-bc1c580 4.4.0-133-generic Ubuntu 20.04.5 LTS 10.176.48.83 10.176.48.83 No 0 B 0 B Online No Storage 1.5.0.0-bc1c580 4.4.0-133-generic Ubuntu 20.04.5 LTS Global Storage Pool Total Used : 6.0 GiB Total Capacity : 40 GiB
-
Portworx ストレージ層に含めようとしていたすべてのワーカー・ノードが含まれていることを確認します。そのためには、CLI 出力の Cluster Summary セクションの StorageNode 列を確認します。 ストレージ層にあるワーカー・ノードは、ストレージ・ノード列に
Yes
と表示されます。Portworx はクラスター内で DaemonSet として実行されるため、Portworx をデプロイすると、既存のワーカー・ノードがロー・ブロック・ストレージについて自動的に検査され、Portworx データ層に追加されます。 クラスターにワーカー・ノードを追加し、それらのワーカーにロー・ブロック・ストレージを追加した場合は、新しいワーカー・ノードで Portworx ポッドを再始動して、ストレージ・ボリュームが DaemonSet によって検出されるようにします。
-
リスト表示されている各ストレージ・ノードについて、ロー・ブロック・ストレージの正しい容量が表示されていることを確認します。そのためには、CLI 出力の Cluster Summary セクションの Capacity 列を確認します。
-
Portworx クラスターの一部であるディスクに割り当てられた Portworx 入出力分類を確認します。 Portworx クラスターのセットアップ時に、すべてのディスクが検査されて、そのデバイスのパフォーマンス・プロファイルが決定されます。 このプロファイル分類は、ワーカー・ノードが接続されているネットワークの速度と、使用しているストレージ・デバイスのタイプによって決まります。 SDS ワーカー・ノードのディスクは、
high
として分類されます。 仮想ワーカー・ノードに手動でディスクを接続すると、仮想ワーカー・ノードが原因でネットワーク速度が遅くなるため、そのディスクはlow
として分類されます。kubectl exec -it <portworx_pod> -n kube-system -- /opt/pwx/bin/pxctl cluster provision-status
出力例
NODE NODE STATUS POOL POOL STATUS IO_PRIORITY SIZE AVAILABLE USED PROVISIONED RESERVEFACTOR ZONE REGION RACK 10.184.58.11 Up 0 Online LOW 20 GiB 17 GiB 3.0 GiB 0 B 0 dal12 us-south default 10.176.48.67 Up 0 Online LOW 20 GiB 17 GiB 3.0 GiB 0 B 0 dal10 us-south default 10.176.48.83 Up 0 Online HIGH 3.5 TiB 3.5 TiB 10 GiB 0 B 0 dal10 us-south default
-
Portworx ボリュームの作成
Kubernetes ダイナミック・プロビジョニングを使用して、 Portworx ボリュームの作成を開始する。
-
クラスター内の使用可能なストレージ・クラスをリスト表示して、Portworx のインストール時にセットアップした既存の Portworx ストレージ・クラスを使用できるかどうかを確認します。 事前定義ストレージ・クラスは、データベースの使用とポッド間でのデータ共有のために最適化されています。
kubectl get sc | grep portworx
ストレージ・クラスの詳細を表示するには、
kubectl describe storageclass <storageclass_name>
を実行します。 -
既存のストレージ・クラスを使用しない場合は、カスタマイズしたストレージ・クラスを作成します。 ストレージクラスで指定できるサポートされるオプションの一覧については、 動的プロビジョニングの使用を参照してください。
-
ストレージ・クラスの構成ファイルを作成します。
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: <storageclass_name> provisioner: kubernetes.io/portworx-volume parameters: repl: "<replication_factor>" secure: "<true_or_false>" priority_io: "<io_priority>" shared: "<true_or_false>"
metadata.name
- ストレージ・クラスの名前を入力します。
parameters.repl
- 複数のワーカー・ノードにまたがって保管するデータのレプリカの数を入力します。 許可される番号は、
1
、2
、または3
です。 例えば、3
と入力すると、Portworx クラスター内の 3 つの異なるワーカー・ノードにデータが複製されます。 保管するデータの高可用性を確保するには、複数ゾーン・クラスターを使用して、別々のゾーン内にある 3 つのワーカー・ノードにまたがってデータを複製してください。 複製要件を満たすために十分なワーカー・ノードが必要です。 例えば、2 つのワーカー・ノードしかない場合に、3 つのレプリカを指定した場合は、このストレージ・クラスを使用して PVC を作成できません。 parameters.secure
- IBM Key Protect を使用してボリューム内のデータを暗号化するかどうかを指定します。 次のいずれかのオプションを選択します。
true
:true
を入力すると、Portworx ボリュームの暗号化が有効になります。 ボリュームを暗号化するには、IBM Key Protect サービス・インスタンスと、カスタマー・ルート鍵を保管する Kubernetes シークレットが必要です。 Portworx ボリュームの暗号化をセットアップする方法について詳しくは、Portworx ボリュームの暗号化を参照してください。false
:false
を入力すると、Portworx ボリュームは暗号化されません。 このオプションを指定しない場合、Portworx ボリュームはデフォルトでは暗号化されません。 ストレージ・クラス内で暗号化を無効にした場合でも、PVC 内でボリュームの暗号化を有効にすることができます。 PVC 内の設定は、ストレージ・クラス内の設定よりも優先されます。
parameters.priority_io
-
- データについて要求する Portworx の入出力優先度を入力します。 指定可能な値は、
high
、medium
、およびlow
です。 Portworx クラスターのセットアップ時に、すべてのディスクが検査されて、そのデバイスのパフォーマンス・プロファイルが決定されます。 プロファイルの分類は、ワーカー・ノードのネットワーク帯域幅とストレージ・デバイスのタイプによって異なります。 SDS ワーカー・ノードのディスクは、high
として分類されます。 仮想ワーカー・ノードに手動でディスクを接続すると、仮想ワーカー・ノードが原因でネットワーク速度が遅くなるため、そのディスクはlow
として分類されます。 - ストレージ・クラスを使用して PVC を作成すると、
parameters/repl
で指定したレプリカの数が入出力優先順位をオーバーライドします。 例えば、高速ディスクに保管するレプリカの数として 3 を指定した場合に、高速ディスクを備えたワーカー・ノードがクラスター内に 1 つしかない場合でも、PVC は正常に作成されます。 データは高速ディスクと低速ディスクの両方にまたがって複製されます。
- データについて要求する Portworx の入出力優先度を入力します。 指定可能な値は、
parameters.shared
- 複数のポッドが同じボリュームにアクセスすることを許可するかどうかを定義します。 次のいずれかのオプションを選択します。
- True: このオプションを
true
に設定した場合は、別々のゾーンに存在する複数のワーカー・ノードに分散された複数のポッドから、この同じボリュームにアクセスすることができます。 - False: このオプションを
false
に設定した場合に、複数のポッドからこのボリュームにアクセスするためには、このボリュームの基盤である物理ディスクに接続されたワーカー・ノードに、それらのポッドがデプロイされている必要があります。 ポッドが別のワーカー・ノードにデプロイされている場合、ポッドはボリュームにアクセスできません。
- True: このオプションを
-
ストレージ・クラスを作成します。
kubectl apply -f storageclass.yaml
-
ストレージ・クラスが作成されていることを確認します。
kubectl get sc
-
-
永続ボリューム請求 (PVC) を作成します。
-
PVC の構成ファイルを作成します。
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: mypvc spec: accessModes: - <access_mode> resources: requests: storage: <size> storageClassName: portworx-shared-sc
metadata.name
- PVC の名前 (
mypvc
など) を入力します。 spec.accessModes
- 使用したい Kubernetes アクセスモードを入力します。
resources.requests.storage
- Portworx クラスターから割り当てるストレージの容量 (GB 単位) を入力します。 例えば、Portworx クラスターから 2 GB を割り当てるには、
2Gi
と入力します。 指定できるストレージの容量は、Portworx クラスター内で使用できるストレージの容量によって制限されます。 ストレージ・クラスで 1 より大きい複製係数を指定した場合、PVC で指定したストレージの量が複数のワーカー・ノードで予約されます。 spec.storageClassName
- PV をプロビジョンするために使用する、既に選択または作成したストレージ・クラスの名前を入力します。 サンプルの YAML ファイルでは、
portworx-shared-sc
というストレージ・クラスを使用しています。
-
PVC を作成します。
kubectl apply -f pvc.yaml
-
PVC が作成されて永続ボリューム (PV) にバインドされていることを確認します。 このプロセスには数分かかる場合があります。
kubectl get pvc
-
アプリへのボリュームのマウント
アプリからストレージにアクセスするには、PVC をアプリにマウントする必要があります。
-
PVC をマウントするデプロイメントの構成ファイルを作成します。
Portworx を使用してステートフル・セットをデプロイする方法のヒントについては、ステートフル・セットを参照してください。 Portworx の資料には、 Cassandra、 Kafka、 ElasticSearch with Kibana、および WordPress with MySQLをデプロイする方法の例も含まれています。
apiVersion: apps/v1 kind: Deployment metadata: name: <deployment_name> labels: app: <deployment_label> spec: selector: matchLabels: app: <app_name> template: metadata: labels: app: <app_name> spec: schedulerName: stork containers: - image: <image_name> name: <container_name> securityContext: fsGroup: <group_ID> volumeMounts: - name: <volume_name> mountPath: /<file_path> volumes: - name: <volume_name> persistentVolumeClaim: claimName: <pvc_name>
metadata.labels.app
- デプロイメントのラベル。
spec.selector.matchLabels.app
およびspec.template.metadata.labels.app
- アプリのラベル。
template.metadata.labels.app
- デプロイメントのラベル。
spec.schedulerName
- Portworx クラスタのスケジューラとして Stork を使用する。 Storkを使用すると、ポッドとそのデータをコロケーションでき、ストレージエラーが発生した場合にポッドのシームレスな移行を提供し、 Portworx ボリュームのスナップショットの作成と復元が容易になります。
spec.containers.image
- 使用するイメージの名前。 IBM Cloud Container Registry アカウント内の使用可能なイメージをリストするには、
ibmcloud cr image-list
を実行します。 spec.containers.name
- クラスターにデプロイするコンテナーの名前。
spec.containers.securityContext.fsGroup
- オプションです:root 以外のユーザーでストレージにアクセスするには、デプロイメント YAML の
fsGroup
セクションでポッドの セキュリティコンテキストを指定し、アクセスを許可するユーザーのセットを定義します。 詳細については、 非 root ユーザーで Portworx ボリュームにアクセスするを参照してください。 spec.containers.volumeMounts.mountPath
- コンテナー内でボリュームがマウントされるディレクトリーの絶対パス。 異なるアプリ間でボリュームを共有したい場合は、アプリごとに ボリュームのサブパスを指定できます。
spec.containers.volumeMounts.name
- ポッドにマウントするボリュームの名前。
volumes.name
- ポッドにマウントするボリュームの名前。 通常、この名前は
volumeMounts/name
と同じです。 volumes.persistentVolumeClaim.claimName
- 使用する PV をバインドする PVC の名前。
-
デプロイメントを作成します。
kubectl apply -f deployment.yaml
-
PV がアプリに正常にマウントされていることを確認します。
kubectl describe deployment <deployment_name>
マウント・ポイントは Volume Mounts フィールドにあり、ボリュームは Volumes フィールドにあります。
Volume Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-tqp61 (ro) /volumemount from myvol (rw) ... Volumes: myvol: Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) ClaimName: mypvc ReadOnly: false
-
Portworx クラスターにデータを書き込めることを確認します。
- PV をマウントするポッドにログインします。
kubectl exec <pod_name> -it bash
- アプリ・デプロイメントで定義したボリューム・マウント・パスにナビゲートします。
- テキスト・ファイルを作成します。
echo "This is a test" > test.txt
- 作成したファイルを参照します。
cat test.txt
- PV をマウントするポッドにログインします。