· Ïm IBM® Cloud Private 2.1.0.3 IBM® Cloud Private ß +'CZ6 l{Ê ZZl)k>l8 l{Ê Ðlß DÙ B 6 >](lkG\CUl Cöß Y)/l (E 7\l'Wc) ß E 7\l'Wcéß Y)/lß 5 E 7\l'Wc¼úß Y)/lß

$Page 1: · Ïm IBM® Cloud Private 2.1.0.3 IBM® Cloud Private ß +'CZ6 l{Ê ZZl)k>l8 l{Ê Ðlß DÙ B 6 >](lkG\CUl Cöß Y)/l (E 7\l'Wc) ß E 7\l'Wcéß Y)/lß 5 E 7\l'Wc¼úß Y)/lß$
IBM Cloud Private 2.1.0.3

IBM

⽬次

IBM® Cloud Private 2.1.0.3

IBM® Cloud Private のアクセシビリティー機能

リリース・ノート新機能

既知の問題と制約

テクノロジー・プレビュー複数のクラスター (フェデレーション) の処理フェデレーションへのクラスターの追加

フェデレーションからのクラスターの削除

IPVS を使⽤した kube-proxy の管理Istio の処理カスタム・メトリックを使⽤したポッドの⽔平⾃動スケーリング

containerd を使⽤した IBM® Cloud Private のインストール

概要IBM® Cloud Private の概要IBM® Cloud Private のバンドルアーキテクチャー

コンポーネント

GDPR 対応に向けた IBM® Cloud Private プラットフォームの考慮事項サポートされる⾔語

インストールシステム要件

ハードウェア要件および推奨

サポートされるオペレーティング・システムとプラットフォーム

サポートされるブラウザー

サポートされる Docker バージョンサポートされるファイル・システムとストレージ

デフォルト・ポート

インストールに向けたクラスターの準備

クラスターの構成

IBM® Cloud Privateバインド・マウントを使⽤したデフォルト Docker ストレージ・ディレクトリーの指定バインド・マウントを使⽤した他のデフォルト・ストレージ・ディレクトリーの指定

IBM® Cloud Private のインストールIBM® Cloud Private クラウド・ネイティブ環境のインストールIBM® Cloud Private エンタープライズ環境のインストールIBM® Cloud Private-CE のインストール

1

1

3

3

6

13

14

16

18

19

20

26

30

31

32

33

36

39

48

57

58

58

58

63

65

65

67

67

69

69

72

74

75

76

76

80

84

バンドル製品のインストール

インストール中のオプションの構成

クラスター・ノードでの SSH 鍵の共有クラスター・ノードのパスワード認証の構成

hosts ファイルでのノード役割の設定インストールのカスタマイズ

config.yaml ファイルを使⽤したクラスターのカスタマイズDocker の⾃動インストールのためのクラスター・ノードの構成HA クラスターでのノード割り当ておよび通信モニタリング・サービスの構成

GlusterFS ストレージの構成vSphere クラウド・プロバイダーの構成動的ストレージ・プロビジョニング

IPsec を使⽤したクラスター・データのネットワーク・トラフィックの暗号化IBM® Cloud Private サービス⽤の独⾃の認証局 (CA) の指定dm-crypt を使⽤したボリュームの暗号化VMware NSX-T 2.0 と IBM® Cloud Private の統合脆弱性アドバイザーの使⽤可能化

外部ロード・バランサーのセットアップ

Kubernetes 監査ログの⽣成

アンインストールIBM® Cloud Private のアンインストールIBM® Cloud Private-CE のアンインストール

アップグレードと復帰IBM® Cloud Private バージョン 2.1.0.2 から 2.1.0.3IBM® Cloud Private-CE バージョン 2.1.0.2 から 2.1.0.3バンドル製品のアップグレード

IBM Cloud Private Docker パッケージのアップグレードアップグレードでのモニター・データの保持

IBM® Cloud Private の旧バージョンへの復帰IBM® Cloud Private-CE の旧バージョンへの復帰IBM Cloud Private Docker パッケージの復帰

クラスターへのアクセスmanagement console からクラスターへのアクセスkubectl CLI からクラスターへのアクセス

IBM® Cloud Private CLI によるクラスターの管理IBM® Cloud Private CLI のインストールIBM Cloud Private CLI のサービス API 鍵のコマンドIBM® Cloud Private CLI コマンド解説書

bx pr apibx pr cluster-configbx pr cluster-getbx pr clusters

87

89

89

90

92

94

96

106

107

109

110

117

119

120

122

123

126

129

129

132

132

133

133

134

134

138

141

142

143

145

145

146

147

147

147

148

149

149

154

155

155

155

155

bx pr delete-helm-chartbx pr initbx pr load-helm-chartbx pr load-ppa-archivebx pr loginbx pr logoutbx pr master-getbx pr mastersbx pr tokensbx pr worker-getbx pr workers

クラスターの再始動

チャートおよびアプリケーションの管理Catalog での Helm チャートのデプロイ⾮デフォルト名前空間での⾼い特権を必要とする Helm チャートのデプロチャートの操作

Helm CLI のセットアップHelm CLI への内部 Helm リポジトリーの追加カスタム・アプリケーションの追加

Helm チャートのパッケージ化外部リポジトリーへのチャートの追加

内部リポジトリーへのチャートの追加

インターネット接続のないクラスターへの主なアプリケーションの追加

イメージの管理イメージ・マネージャー

Docker CLI の認証の構成イメージのプッシュおよびプル

イメージ・スコープの変更

特定の名前空間の imagePullSecrets の作成console からのイメージの削除IBM® Cloud Private 計量サービスのためのイメージのラベル付け

ワークロードの管理DaemonSets の作成デプロイメントの管理

デプロイメントの作成


添付 GPU リソースを使⽤したデプロイメントの作成デプロイメントの変更

デプロイメントの削除

デプロイメントのスケーリング

Helm リリースの管理ジョブの管理

ジョブの作成

156

156

156

157

157

158

158

158

158

159

159

160

160

161

162

163

164

164

166

167

168

168

169

171

171

172

173

174

175

176

178

178

179

180

180

180

181

183

184

184

184

186

186

CronJobs の作成StatefulSets の作成ReplicaSets の管理

サービスの管理サービスの作成

サービスの変更

サービスの削除

サービスの有効化と無効化

IBM Cloud Private CLI を使⽤したサービス ID の作成IBM® Cloud Private でのサービス・カタログ・リソースの使⽤

ServiceBrokers の使⽤ClusterServiceBroker の登録ClusterServiceClasses および ClusterServicePlans の表⽰ServiceInstance の作成ServiceInstance ⽤の ServiceBinding の作成ServiceInstance のアンバインディングServiceInstance の削除ClusterServiceBroker の削除

構成とスケーリングの管理ConfigMaps の作成ポリシーの管理

デプロイメント・ポリシーの作成

デプロイメント・ポリシーの更新

デプロイメント・ポリシーの削除

秘密の管理

プラットフォームの管理計量、モニタリング、およびロギング

IBM® Cloud Private 計量サービス計量レポートの表⽰

計量サービスを使⽤したチャージバックの管理

IBM® Cloud Private のモニタリングシステムおよびリソースのモニタリング

ポッド情報の表⽰

IBM® Cloud Private のロギングIBM® Cloud Private ロギングおよびメトリックのキャパシティー・プランニングロギング・サービスのための IBM® Cloud Private Filebeat ノードのカスタマイズネットワーク

ノードの準備

Calico CLI のセットアップNetworkPolicy の作成

IBM® Cloud Private クラスター・ノードの追加と削除クラウド・プロバイダーを使⽤したクラスター・ノードの追加または削除

IBM® Cloud Private クラスター・ノードの追加IBM® Cloud Private-CE クラスター・ノードの追加

187

188

189

190

191

192

192

192

193

195

197

197

198

198

198

199

199

199

200

200

200

201

202

202

202

203

204

204

204

204

206

207

209

209

222

226

228

228

229

230

232

232

235

238

IBM® Cloud Private クラスター・ノードの削除IBM® Cloud Private-CE クラスター・ノードの削除ストレージ

Container Storage Interface (CSI) の使⽤GlusterFS

IBM® Cloud Private クラスター内の GlusterFS ストレージの構成GlusterFS クラスターのストレージ容量の増加GlusterFS ボリュームからのデータのリカバリーIBM® Cloud Private の再インストールのための GlusterFS ワーカー・ノードの準備Heketi の秘密の変更

vSphere クラウド・プロバイダーIBM® Cloud Private クラスターでの vSphere クラウド・プロバイダーの構成

IBM Spectrum Scale™IBM Spectrum Scale™ を IBM® Cloud Private クラスター内のストレージに使⽤するストレージ・クラス

ストレージ・クラスの作成

vSphere ボリューム⽤ストレージ・クラスの作成GlusterFS ⽤ストレージ・クラスの作成ストレージ・クラスの削除

PersistentVolumePersistentVolume の作成

NFS PersistentVolume の作成GlusterFS PersistentVolume の作成hostPath PersistentVolume の作成

PersistentVolume の削除PersistentVolumeClaim

PersistentVolumeClaim の作成PersistentVolumeClaim のアプリケーションへの添付PersistentVolumeClaim の削除

リソース

Nvidia GPU のサポートGPU ワーカー・ノードの構成脆弱性アドバイザー

IBM Cloud Private クラスターの脆弱性アドバイザー・ポストインストールの有効化

プラットフォームへのアクセスの管理認証

役割ベースのアクセス制御

LDAP 接続の構成Helm リポジトリーの管理名前空間

名前空間の作成

名前空間の削除

ポッド・セキュリティー

ポッド・セキュリティー・ポリシーの作成

リソース割り当て量の設定

IBM® Cloud Private CLI による Kubernetes Secret パスワードの管理チーム

240

240

241

241

243

243

244

248

249

249

250

250

254

254

256

256

260

261

262

262

263

264

265

268

269

270

270

271

271

272

272

273

274

277

281

281

282

287

293

294

294

295

295

295

296

297

299

チームの作成

チームへのユーザーの追加

チームへのグループの追加

チームへのリソースの追加

チームからのユーザーの削除

チームからのグループの削除

チームからのリソースの削除

チームの削除

クラスターの管理者権限資格情報の変更

クラスターのアクセス URL のカスタマイズ認証および許可の監査ログ

フィーチャー・サービスバンドルされたアプリケーション

Cloud Automation ManagerWebSphere Application Server LibertyWebSphere Application Server Network Deploymentコア・サービス

IBM® Cloud Private のロギング・サービスKibanaIBM® Cloud Private のモニタリング・サービス

IBM Cloud Product Insights Transformation AdvisorIBM DataPower GatewayIBM Data Science Experience Developer EditionIBM Data Server ManagerIBM Db2IBM Db2 WarehouseIBM InfoSphere Information ServerIBM Integration BusIBM MQIBM Netcool Operations Insight プローブIBM Operational Decision ManagerNode.js サンプル・アプリ⽤ IBM SDKIBM Spectrum LSF Community EditionIBM Spectrum SymphonyIBM Voice GatewayIBM Watson Compare and Comply: Element ClassificationIBM Watson ExplorerMicroclimateMongoDBPostgreSQLSkydive

IBM® Cloud Private Cloud Foundry プラットフォームの概要IBM® Cloud Private Cloud Foundry バージョン 2.1.0.3 の新機能IBM® Cloud Private Cloud Foundry のインストール準備

IBM® Cloud Private Cloud FoundryVMware インスタンスに関する必須情報

299

300

300

301

301

302

302

302

303

305

308

309

309

309

310

310

311

311

312

312

317

318

318

318

318

319

319

319

320

320

321

321

321

322

322

323

323

324

324

324

324

325

326

327

327

328

VMware のアクセス権の構成IBM® Cloud Private Cloud Foundry の開発者向けインストールのための VMware サイズ要件IBM® Cloud Private Cloud Foundry のエンタープライズ向けインストールのための VMware サイズ要件

IBM® Cloud Private Cloud Foundry の OpenStack 要件OpenStack インスタンスに関する必要な情報IBM® Cloud Private Cloud Foundry 開発者版のインストールの OpenStack サイズ要件IBM® Cloud Private Cloud Foundry エンタープライズ版のインストールの OpenStack サイズ要件

IBM® Cloud Private Cloud Foundry の証明書の提供IBM® Cloud Private Cloud Foundry のインストール共通のパラメーター

vSphere パラメーターOpenStack パラメーター

IBM® Cloud Private Cloud Foundry のアップグレードIBM® Cloud Private Cloud Foundry のアンインストールIBM® Cloud Private Cloud Foundry の認証の構成組織およびスペースに対するユーザー許可の管理

IBM® Cloud Private Cloud Foundry ⽤の環境のカスタマイズIBM® Cloud Private Cloud Foundry の LDAP 認証の構成IBM® Cloud Private Cloud Foundry の UAA 認証の構成IBM® Cloud Private Cloud Foundry のバックアップの構成

IBM® Cloud Private Cloud Foundry での拡張機能の使⽤拡張機能の作成

拡張機能の実⾏

IBM Cloud Private Cloud Foundry コンソールの構成IBM® Cloud Private Cloud Foundry ops console のインストールIBM® Cloud Private Cloud Foundry ops console の使⽤IBM® Cloud Private Cloud Foundry の DNS の構成別のデータベースを使⽤するための Director の構成コンテナー・ネットワーキングの構成

IBM® Cloud Private Cloud Foundry のバックアップの構成アベイラビリティー・ゾーンの構成

Diego セルの数の増加IBM® Cloud Private Cloud Foundry ops console のコマンド・ライン・インターフェースIBM® Cloud Private Cloud Foundry との統合の構成

IBM® Cloud Private Cloud Foundry での Cloud Foundry App Autoscaler の使⽤IBM® Cloud Private Cloud Foundry syslog と Splunk の統合Splunk Firehose Nozzle Release の Cloud Foundry アプリケーションとしての構成IBM® Cloud Private Cloud Foundry syslog と ELK スタックとの統合Prometheus への IBM® Cloud Private Cloud Foundry の接続

IBM® Cloud Private Cloud Foundry ⽤アプリケーションのための信頼証明書の構成IBM® Cloud Private Cloud Foundry でのビルドパックの使⽤

IBM® Cloud Private Cloud Foundry でのビルドパックの管理IBM® Cloud Private Cloud Foundry でのユーザー提供サービスの処理ユーザー提供サービスと Liberty スターター・アプリの処理ユーザー提供サービスと Node.js スターター・アプリの処理

IBM® Cloud Private Cloud Foundry での Liberty および Node.js アプリケーションの管理クイック構成マネージャー (CM) リファレンス・ガイドIBM® Cloud Private Cloud Foundry のトラブルシューティング

329

329

331

333

333

336

338

339

342

343

346

347

349

352

352

352

353

354

357

357

357

358

361

363

365

366

367

368

368

369

372

373

374

375

376

381

383

385

386

388

389

391

392

394

397

400

404

406

無効⽂字が原因で launch_deployment.sh が失敗するvCenter または ESXs FDQNs を解決できないため、デプロイメントが失敗するCloud Foundry cf push および log コマンドがエラーを返すCloud Foundry 管理ユーザーがロックアウトされているBOSH デプロイメント中に consul ジョブが失敗する⽅向付けコンテナーが開始しない

Cloud Foundry デプロイメントがタイムアウトになるCloud Foundry の検証に失敗する特定の仮想マシン・ジョブで Cloud Foundry のデプロイメントが失敗するIP アドレスの競合が原因で Cloud Foundry のデプロイメントが失敗するPortGroup が管理者権限を付与されていないMicrobosh Director が bosh/0 の初期化に失敗するEHOSTUNREACH エラーが原因で Cloud Foundry アプリケーションのデプロイメントが失敗するno route to host エラーが原因で Cloud Foundry での Docker アプリケーションのデプロイメントが失敗するOpenStack で BOSH ssh が失敗するBosh 仮想マシンが無応答と表⽰される

トラブルシューティングとサポートサポート

IBM® Cloud Private のサポート・タイプIBM® Cloud Private でのオープン・ソース・サポートインストール

インストールの停⽌または失敗

etcd コンポーネントが開始できないssh 経由の接続に失敗するコンテナーの作成に失敗する

Kubelet コンテナーが開始できないDNS サーバーの検証に失敗するngnix ingress コントローラーが開始しないポッドが初期化に失敗する

firewalld が有効なときにインストールが失敗するHeapster がエラー状態のままになるログイン

CLI を使⽤してログインできないクラスターの管理者が management console にログインできない管理コンソール

(マスター・ノードの再始動後に) management console にアクセスできない脆弱性アドバイザー・レポートを表⽰できない

ネットワーク

Calico ネットワークのトラブルシューティングストレージ

システム再始動後に GlusterFS デバイスが⾒つからないGlusterFS ノードが異常終了するIBM® Cloud Private の再インストールで GlusterFS の問題が解決されないGlusterFS PersistentVolumeClaim を作成できない複数のワーカー・ノードを同時に再始動すると GlusterFS が失敗するパーシスタント・ボリュームまたはパーシスタント・ボリューム・クレームを作成または削除できない

GlusterFS ノードの状況に「Peer Rejected」と表⽰される

406

407

408

409

409

410

410

411

411

413

414

414

414

415

416

417

418

419

419

419

420

421

421

423

423

423

427

428

428

428

429

430

430

431

432

432

433

434

434

435

435

436

436

437

438

439

441

GlusterFS パーシスタント・ボリューム・クレームを削除するとパーシスタント・ボリューム状況に「Failed」と表⽰される場合があるイベントおよびログ

イベントおよびログ (CLI)イベントおよびログ (クラスター management console)Elasticsearch のログ・データがクリーンアップされていない

Windows で CLI を使⽤して kubectl を認証できない

APIAPI コマンド実⾏の準備コンポーネント API

Kubernetes APIHeapster APIElasticsearch APIDocker Registry V2 APIPrometheus APIユーザー管理および認証 APIアカウント管理

すべてのアカウントに関する情報の取得

アカウントに関する情報の取得

ディレクトリー管理

LDAP ディレクトリーへの接続LDAP 接続のリストLDAP ディレクトリーの削除LDAP ディレクトリー内でのユーザー・グループの検索LDAP ディレクトリー内でのユーザーの検索LDAP ディレクトリーからのユーザー・グループのインポートLDAP ディレクトリーからのユーザーのインポートユーザー・グループ管理

すべてのユーザー・グループの取得

ユーザー・グループの削除

ユーザー管理

すべてのユーザーに関する情報の取得

全チームでユーザーに割り当てられている最⾼の役割の取得

ユーザーに割り当てられているチーム・リソースの取得

ユーザーの削除

ユーザーのアカウント情報の取得

チーム管理

チームの作成

ユーザーおよびユーザー・グループをチームに割り当てる

チームへのリソースの割り当て

チームに関する情報の取得

すべてのチームに関する情報の取得

チームに割り当てられたリソースの取得

チームの更新

チームの削除

サービス管理 APIサービス ID 管理 API

442

445

445

446

447

447

448

448

450

450

451

452

453

454

455

455

455

456

457

457

458

458

459

460

460

461

462

462

462

463

463

464

464

465

466

467

467

467

468

469

469

470

471

472

472

473

すべてのサービス ID に関する情報の取得CRN にバインドされたすべてのサービス ID に関する情報の取得サービス ID の作成特定のサービス ID に関する情報の取得特定のサービス ID および関連 API 鍵の削除サービス ID の更新

API 鍵管理 APIAPI 鍵の作成CRN にバインドされた API 鍵の取得API 鍵に関する情報の取得API 鍵の更新API 鍵の削除OpenID Connect (OIDC) トークンの⽣成サービス・ポリシー管理 APIすべてのシステム定義の役割に関する情報の取得

すべての登録済みサービスに関する情報の取得

サービス ID およびスコープに割り当てられたポリシーに関する情報の取得サービス ID のアクセス・ポリシーの作成特定のサービスに割り当てられたアクセス・ポリシーに関する情報の取得

特定のサービスに割り当てられたアクセス・ポリシーの更新

特定のサービスに割り当てられたアクセス・ポリシーの削除

イメージ管理 APIリポジトリーの削除

JWT トークンの取得エンドポイントのリスト

リポジトリーのリスト

指定リポジトリーのリスト

リポジトリー・メタデータの更新

脆弱性アドバイザー API

ライセンス交付

473

474

474

475

476

476

477

477

478

479

479

480

481

482

482

482

484

484

485

486

487

487

489

490

491

492

493

494

496

498

IBM® Cloud Private v2.1.0.3 の資料

IBM Cloud Private の資料へようこそ。ここでは、IBM Cloud Private のインストール、保守、および使⽤⽅法に関する情報を⼊⼿できます。

始めに

概要

システム要件

リリース・ノート

IBM Cloud Private のアクセシビリティー機能

共通タスク

IBM Cloud Private のインストール

ワークロードの管理

チャートおよびアプリケーションの管理

イメージの管理

プラットフォームの管理

トラブルシューティングとサポート

トラブルシューティング

IBM Cloud Technology Slack チャネル

技術コミュニティー

ibm-cloud-private タグを指定したスタック・オーバーフロー問題の表⽰

Copyright IBM Corporation 2018.

IBM® Cloud Private のアクセシビリティー機能

アクセシビリティー機能は、運動障がいまたは視覚障がいなどの⾝体障がいを持つユーザーが情報技術コンテンツを

快適に使⽤できるようにサポートします。

概要

IBM Cloud Private には、以下の主なアクセシビリティー機能が含まれています。

キーボードのみでの操作

スクリーン・リーダーでの操作

IBM Cloud Private クラスターを管理するためのコマンド・ライン・インターフェース (CLI)

IBM Cloud Private では、最新の W3C 標準である WAI-ARIA 1.0 を使⽤して、Section 508 Standards for Electronicand Information Technology および Web Content Accessibility Guidelines (WCAG) 2.0 に対する準拠を確保して

IBM Cloud Private 2.1.0.3 1

http://ibm.biz/BdsHmN

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W1559b1be149d_43b0_881e_9783f38faaff

https://stackoverflow.com/questions/tagged/ibm-cloud-private

http://www.w3.org/TR/wai-aria/

http://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards

http://www.w3.org/TR/WCAG20/

います。アクセシビリティー機能を利⽤するには、スクリーン・リーダーの最新リリースおよび IBM Cloud Privateでサポートされる最新の Web ブラウザーを使⽤してください。

IBM Knowledge Center の IBM Cloud Private のオンライン製品資料は、アクセシビリティー対応です。 IBMKnowledge Center のアクセシビリティー機能については、 IBM Knowledge Center リリース・ノートのアクセシビリティー・セクションに説明があります。⼀般的なアクセシビリティーの情報については、IBM におけるアクセシビリティーを参照してください。

ハイパーリンク

すべての外部リンク (IBM Knowledge Center の外部でホストされているコンテンツへのリンク) は、新規ウィンドウで開きます。このような外部リンクには、外部リンク・アイコン ( ) によるフラグも⽴てられています。

キーボード・ナビゲーション

IBM Cloud Private では、標準ナビゲーション・キーを使⽤します。

IBM Cloud Private では、以下のキーボード・ショートカットを使⽤します。

表 1. IBM Cloud Private でのキーボード・ショートカットアクション Internet Explorer のショートカット Firefox のショートカット

コンテンツ・ビュー・フレームに移動 Alt+C の後に、Enter および Shift+F6 を押す Shift+Alt+C および Shift+F6

インターフェース情報

IBM Cloud Private では、スクリーン・リーダーの最新バージョンを使⽤してください。

IBM Cloud Private ユーザー・インターフェースには、1 秒間に 2 から 55 回点滅するコンテンツは含まれていません。

IBM Cloud Private Web ユーザー・インターフェースでは、コンテンツを適切にレンダリングするため、および使いやすい使⽤感を提供するために、カスケーディング・スタイル・シートを利⽤しています。このアプリケーションでは、ハイコントラスト・モードなど、低視⼒のユーザーがシステム表⽰設定を使⽤するための同等の⼿段が⽤意され

ています。デバイスまたは Web ブラウザーの設定を使⽤して、フォント・サイズを制御できます。

IBM Cloud Private には、以下のサポートされるブラウザーでアクセスできます。

表 2. サポートされるブラウザープラットフォームサポートされるブラウザー

Windows™ Edge - 最新バージョンMozilla Firefox - Windows ⽤の最新バージョンGoogle Chrome - Windows ⽤の最新バージョン

Linux™ Mozilla Firefox - Linux ⽤の最新バージョンGoogle Chrome - Linux ⽤の最新バージョン

macOS Mozilla Firefox - Mac ⽤の最新バージョンGoogle Chrome - Mac ⽤の最新バージョンSafari - 最新バージョン

management console にアクセスするには、Web ブラウザーを開き、以下の URL にナビゲートします。

https://master_ip:8443

2 IBM Cloud Private 2.1.0.3

http://www.ibm.com/support/knowledgecenter/about/releasenotes.html

https://www.ibm.com/accessibility/jp/ja/

ここで、master_ip は、IBM Cloud Private マスター・ノードが稼働しているホストの IP アドレスです。デフォルト管理者ユーザー名は admin であり、デフォルト・パスワードは admin です。

⾼可⽤性 (HA) インストール済み環境の場合、master_ip は、IBM Cloud Private クラスターの仮想 IP アドレス(cluster_vip) です。

management console では、コンテンツを適切にレンダリングするため、および使いやすい使⽤感を提供するために、カスケーディング・スタイル・シートを利⽤することはしていません。ただし、IBM Knowledge Center で使⽤可能な製品資料では、カスケーディング・スタイル・シートを利⽤しています。 IBM Cloud Private では、ハイコントラスト・モードなど、低視⼒のユーザーがシステム表⽰設定を使⽤するための同等の⼿段が⽤意されています。デバイスまたはブラウザーの設定を使⽤して、フォント・サイズを制御できます。標準スクリーン・リーダーは、製品資料に含まれているファイル・パス、環境変数、コマンド、およびその他のコンテンツの発⾳を間違える可能性があ

ることに留意してください。説明が最も正確になるようにするために、すべての句読点を読むようにスクリーン・リーダーを構成してください。

ベンダー・ソフトウェア

IBM Cloud Private には、IBM のご使⽤条件でカバーされない特定のベンダー・ソフトウェアが含まれています。IBM は、そうした製品のアクセシビリティー機能についていかなる表明も⾏いません。各製品に関するアクセシビリティー情報については、該当するベンダーにお問い合わせください。

関連アクセシビリティー情報

標準 IBM ヘルプ・デスクおよびサポート Web サイトに加え、IBM では TTY 電話サービスを⽤意しています。このサービスは、聴覚障がいを持つお客様が販売やサポートのサービスにアクセスするためにご利⽤いただけます。

TTY サービス800-IBM-3383 (800-426-3383)(北アメリカ内)

IBM のアクセシビリティーに対する取り組みについて詳しくは、IBM Accessibility を参照してください。

リリース・ノート

新機能既知の問題および制限

バージョン 2.1.0.3 の新機能

このリリースで追加、変更、改善、または⾮推奨化された内容の概要を簡単に⽰します。

IBM® Cloud Private バージョン 2.1.0.3 では、以下の新機能または機能拡張が導⼊されています。

新機能

Kubernetes

IBM Cloud Private バージョン 2.1.0.3 は、Kubernetes バージョン 1.10.0 を使⽤するようにアップグレードされました。 Kubernetes 1.10.0 で導⼊された機能について詳しくは、https://github.com/kubernetes/sig-release/blob/master/releases/release-1.10/release-notes-draft.md を参照してください。

ストレージ


http://www.ibm.com/able

https://github.com/kubernetes/sig-release/blob/master/releases/release-1.10/release-notes-draft.md

IBM Cloud Private のバックエンド・データベースは、IBM Cloudant から MongoDB に置き換えられました。IBM Cloud Private コンポーネントを参照してください。IBM Cloud Private のインストール後に vSphere クラウド・プロバイダーを構成できるようになりました。『IBM Cloud Private クラスターでの vSphere クラウド・プロバイダーの構成』を参照してください。Container Storage Interface (CSI) のベータ版が使⽤可能になりました。 Container Storage Interface (CSI) の使⽤を参照してください。

Helm

Helm リソースをチームに追加できるようになりました。 Helm リソースには、内部 Helm リポジトリーと、Helm リポジトリー内にある Helm チャートが含まれます。 Helm リポジトリーがチームのリソースに追加されると、チームはリポジトリー内のすべてのチャートにアクセスできるようになります。

Helm リポジトリー内のチャートがチームに追加されると、Helm リポジトリー・ページで、ユーザーに Helm リポジトリーが表⽰されます。 Catalog には、チームが使⽤可能な、選択されたチャートのみが表⽰されます。

チームを作成する際に、Helm リポジトリー/チャートがチームに追加されなかった場合、チームの Catalog のページは空です。

チームへのリソースの追加について詳しくは、チームへのリソースの追加を参照してください。

local-charts という名前の内部 Helm リポジトリーを外部リポジトリーとして Helm CLI に追加できるようになりました。 local-charts は、Helm CLI からクラスターにチャートをインストールするためのソースとして使⽤できます。詳しくは、『Helm CLI への内部 Helm リポジトリーの追加』を参照してください。

Catalog

Catalog に記載されているほとんどの Helm チャートのリリース・ノート情報を表⽰できるようになりました。このリリース・ノートには、各 Helm チャートに関する情報 (バージョン、新機能、フィックス、追加された機能拡張など) が含まれます。

⼀部の IBM Helm チャートにはリリース・ノートがない場合があります。 Catalog に追加されるサード・パーティーの Helm チャートの場合、リリース・ノートは提供されません。

また、Catalog のフィルター操作が拡張され、より多くのオプションがカバーされるようになりました。チャートおよびアプリケーションの管理を参照してください。

計量

IBM Cloud Private 環境の外部で実⾏されている IBM 製品からデータを収集したり、そのような製品によるリソース使⽤量を報告したりできるようになりました。この環境には、ベア・メタル、VM、または別のクラウド・プラットフォームがあります。 IBM Cloud Private クラスターの外部で実⾏されている IBM 製品の使⽤量のトラッキングを参照してください。

作成する Docker イメージには、オファリングの製品 ID、名前、およびバージョンを識別するラベルを含めることができます。計量デーモンがこれらのラベルを発⾒し、計量対象のランタイム・メトリックを実⾏中のオファリング・インスタンスに関連付けるために使⽤できます。詳しくは、『IBM® Cloud Private 計量サービスのためのイメージのラベル付け』を参照してください。

IBM Cloud Private CLI

IBM Cloud Private CLI を使⽤して、クラスターでプロキシー・ノードを追加または削除できます。詳しくは、『クラウド・プロバイダーを使⽤したクラスター・ノードの追加または削除』の『クラウド・プロバイダーを使⽤したプロ

キシー・ノードの追加または削除』セクションを参照してください。

セキュリティー


IBM Cloud Private CLI で秘密のパスワードを管理できます。 IBM Cloud Private CLI を使⽤して、パスワード要件の適⽤、パスワードの変更、必要なポッドおよびコンテナーの再始動を⾏うことができます。詳しくは、『IBM Cloud Private CLI による Kubernetes Secret パスワードの管理』を参照してください。

アプリケーションで必要な特定のサービスにアクセスするためのサービス ID、API 鍵、およびポリシーを管理できます。詳しくは、『IBM Cloud Private CLI のサービス API 鍵のコマンド』および『IBM Cloud Private CLIを使⽤したサービス ID の作成』を参照してください。

認証および許可の監査ログが、IBM Cloud Private で使⽤可能になりました。『認証および許可の監査ログ』を参照してください。

IBM Cloud Private Elasticsearch、Logstash、および Kibana (ELK) スタックに対してエンドツーエンドの TLS暗号化を有効にすることができます。有効にした場合、スタック内のすべての製品間のすべての通信が保護されるだけでなく、PKI ベースの相互認証を使⽤した保護も⾏われます。

注: 現在、Elasticsearch ⽤の TLS 暗号化は、amd64 ベースのプラットフォームでのみサポートされます。Filebeat は、引き続き、セキュア・ログ・ストリーミングのために任意のプラットフォームにデプロイ可能です。

ネットワーキング

IBM Cloud Private クラスター内に etcd ノードを構成して、etcd パフォーマンスを改善できるようになりました。アーキテクチャーを参照してください。

脆弱性アドバイザー

IBM Cloud Private クラスターをインストールした後に、脆弱性アドバイザー機能を有効にすることができるようになりました。『IBM Cloud Private クラスターの脆弱性アドバイザー・ポストインストールの有効化』を参照してください。

API を使⽤して脆弱性アドバイザーを管理できるようになりました。『脆弱性アドバイザー API』を参照してください。

⼀般データ保護規則 (GDPR)

⼀般データ保護規則 (GDPR) は、欧州連合 (EU) によって採択され、2018 年 5 ⽉ 25 ⽇から適⽤されています。組織で GDPR に対応できるようにするために考慮する必要がある、構成可能な IBM Cloud Private プラットフォームの機能および製品の使⽤のいくつかの側⾯については、『GDPR 対応に向けた IBM Cloud Private プラットフォームの考慮事項』を参照してください。

テクノロジー・プレビュー

以下の機能がテクノロジー・プレビューとして使⽤可能です。

クラスター・フェデレーション - 複数クラスター環境で、フェデレーションを使⽤して、複数の Kubernetesクラスターにおける共通のサービスをデプロイおよび管理できます。『複数クラスターの処理 (フェデレーション)』を参照してください。IP Virtual Server (IPVS) モードでの kube-proxy の実⾏。『IPVS を使⽤した kube-proxy の管理』を参照してください。

Istio を使⽤したマイクロサービスの管理および保護。 Istio の処理を参照してください。カスタマー・メトリックを使⽤したポッドの⾃動スケーリング。カスタム・メトリックを使⽤したポッドの⽔平⾃動スケーリングを参照してください。

クラスター・ノードのランタイムとしての containerd の使⽤。『containerd を使⽤した IBM Cloud Private のインストール』を参照してください。


フィックスおよび改善

IBM Cloud Private バージョン 2.1.0.3 の導⼊に伴い、以下の改善および機能拡張が⾏われました。

「ワークロード (Workloads)」>「デプロイメント (Deployments)」ページで「起動 (Launch)」リンクが使⽤可能になりました。このリンクを使⽤して、関連するデプロイメントのアプリケーションにアクセスできます。

IBM® Z システムでプロキシー・ノードを実⾏できるようになりました。『プラットフォームごとのサポートされるノード・タイプ』を参照してください。

イメージ名がすべてのプラットフォーム・アーキテクチャーで⼀貫性のあるものになりました。 Linux® 64-bitおよび Linux® on Power® (ppc64le) のインストーラー・イメージを実⾏するために別個のコマンドを使⽤する必要はなくなりました。

IBM Cloud Private Cloud Foundry の変更点

IBM Cloud Private Cloud Foundry に対する変更点について詳しくは、『IBM Cloud Private Cloud Foundry バージョン2.1.0.3 の新機能』を参照してください。

変更された内容

IBM Cloud Private バージョン 2.1.0.3 の導⼊に伴い、以下のパッケージのバージョンが変更されました。

Calico がバージョン 2.6.6 からバージョン 3.0.4 にアップグレードされました。Calicoctl がバージョン 1.6.3 からバージョン 2.0.2 にアップグレードされました。Calico/cni がバージョン 1.11.2 からバージョン 2.0.3 にアップグレードされました。Calico/kube-policy-controller がバージョン 1.0.3 からバージョン 2.0.2 にアップグレードされました。Kubernetes がバージョン 1.9.1 からバージョン 1.10.0 にアップグレードされました。NGINX Ingress コントローラーがバージョン 0.9.0 からバージョン 0.12.0 にアップグレードされました。

既知の問題および制限

以下に、バージョン 2.1.0.3 の既知の問題について記載します。

Tiller 2.7.2 では、Kubernetes 1.9 - 1.10 リソースのアップグレードおよびインストールはサポートされないプライベート・イメージ・レジストリー内のイメージのリスト表⽰は 256 件に制限されるアラート、ロギング、またはモニターのページで「500 Internal Server Error」が表⽰されるIPv6 はサポートされないCloud Automation Manager バージョン 2.1.0.2 はまだ使⽤可能でないHelm CLI インストールのエラーサービスが応答しない、または「Gateway Timeout」エラーが表⽰されるストレージに GlusterFS を使⽤している⼀部のポッドは⼿動で削除する必要がある先導マスターの再始動後に LDAP ユーザーで管理コンソールにログインできないLinux® on Power® (ppc64le) ノードにおける Calico の接頭部の制限Slack のアラートに無効なリンクが含まれるワーカー・ノードのシャットダウン後に StatefulSets が Terminating 状態のままになるLDAP 接続に制限があるリポジトリーの同期で Helm チャートの内容が更新されないことがある新しい management console から⼀部の機能を使⽤できないコンテナーの開始に失敗する

管理コンソールに「502 Bad Gateway Error」と表⽰されるIngress コントローラーが新しいアノテーション接頭部を使⽤できるようにするIngress コントローラーの動的構成はデフォルトでは無効になっている


vSphere クラウド・プロバイダーでパーシスタント・ボリューム・クレーム (PVC) の作成が失敗するCalico ネットワーク使⽤時にノード名に⼤⽂字を使⽤できないアップグレード時に動的にプロビジョンされたボリュームを使⽤した場合、モニター・データは保持されない

vSphere ストレージを使⽤している場合にノードを再始動できない⼀部の⾔語で切り捨てられたラベルがダッシュボードに表⽰される

Helm リポジトリー名に DBCS GB18030 ⽂字を含めることはできないSELinux を使⽤している場合には計量サービスでデータが収集されないIBM Cloud Private のインストール後に vSphere クラウド・プロバイダーを構成した場合に GlusterFS クラスターが使⽤不可になる

IBM Cloud Private のアップグレードまたはロールバックが失敗すると、異なる状況の 2 つのリリースが作成される

Tiller 2.7.2 では、Kubernetes 1.9 - 1.10 リソースのアップグレードおよびインストールはサポートされない

IBM Cloud Private バージョン 2.1.0.3 では、Tiller バージョン 2.7.2 がインストールされます。 Tiller 2.7.2 では、Kubernetes API バージョン 1.8 が使⽤されます。 Tiller 2.7.2 を使⽤して、Kubernetes バージョン 1.9 からバージョン 1.10 リソースのみを使⽤する Helm チャートをインストールおよびアップグレードすることはできません。 Helmチャートをインストールまたはアップグレードするには、チャートで Kubernetes バージョン 1.8 リソースがサポートされている必要があります。

Helm リリースのアップグレード中に「Error: UPGRADE FAILED: failed to create patch: unable to find api field in struct Unstructured for the json field "spec"」というエラーが発⽣することがあります。このエラー・メッセージが表⽰された場合、リリースを削除してから、チャートの新規バージョンをインストールする必要があります。

プライベート・イメージ・レジストリー内のイメージのリスト表⽰は 256 件に制限される

IBM Cloud Private では、management consoleで、またはイメージ管理 API の list repositories 関数を使⽤してリストできる有効なイメージは 256 件までです。

イメージのリストが 256 件を超えていないのにもかかわらず、イメージの全リストにアクセスできない場合は、プライベート・イメージ・レジストリー内に孤⽴ファイルが存在している可能性があります。

1. イメージ・マネージャー・ログでエラーまたは警告メッセージがないかを確認します。

kubectl logs -f image-manager-0 -c image-manager -n kube-system

孤⽴イメージが⾒つかった場合、出⼒は以下のコードのようになります。

time="2018-05-08T08:38:42Z" level=warning msg="registry.(*Registry).FilterDeletedRepositories (repositories.go:99) Found 1 orphan images, it may cause UI or API can't fully list 256 images as MAX supported images, please refer to ICP Knowledge Center 'Known issues and limitations' section to correct it. "

2. レジストリーから孤⽴イメージをすべて削除します。『プライベート・レジストリー・ストレージからイメージ・ファイルを削除』を参照してください。

アラート、ロギング、またはモニターのページで「500 Internal Server Error」が表⽰される

この問題を解決するには、マスター・ノードから以下のステップを実⾏します。


1. ⾮セキュア kubectl api ログイン⽤の別名を作成します。

alias kc='kubectl -n kube-system'

2. Kibana の構成マップを編集します。

kc edit cm kibana-nginx-config

以下の更新を⾏います。

upstream kibana { server localhost:5602; } localhost を 127.0.0.1 に変更します。

3. Kibana ポッドを⾒つけ、再始動します。

kc get pod | grep -i kibana

kc delete pod <kibana-POD_ID>

4. Grafana の構成マップを編集します。

kc edit cm grafana-router-nginx-config

以下の更新を⾏います。

upstream grafana { server localhost:3000; } localhost を 127.0.0.1 に変更します。

5. grafana ポッドを⾒つけ、再始動します。

kc get pod | grep -i monitoring-grafana

kc delete pod <monitoring-grafana-POD_ID>

6. Alertmanager の構成マップを編集します。

kc edit cm alertmanager-router-nginx-config

以下のセクションを編集します。 upstream alertmanager { server localhost:9093; } localhost を 127.0.0.1 に変更します。

7. Alertmanager ポッドを⾒つけ、再始動します。

kc get pod | grep -i monitoring-prometheus-alertmanager

kc delete pod <monitoring-prometheus-alertmanager-POD_ID>

IPv6 はサポートされない

IBM Cloud Private は IPv6 ネットワークを使⽤できません。 IPv6 設定が各クラスター・ノードの /etc/hosts ファイルからコメント化されていることを確認します。クラスターの構成を参照してください。

Helm CLI インストールのエラー

Helm CLI のインストール中に、以下の出⼒のようなエラー・メッセージが表⽰されることがあります。


error copying from remote stream to local connection: readfrom tcp4 x.x.x.x>x.x.x.x write tcp4 x.x.x.x>x.x.x.x write: broken pipe LAST DEPLOYED: Fri Feb 16 16:56:32 2018 NAMESPACE: default STATUS: DEPLOYED

状況が DEPLOYED の場合、このエラー・メッセージは無視できます。状況が DEPLOYED の場合、Helm CLI のインストールは、このエラー・メッセージの影響を受けません。

サービスが応答しない、または「Gateway Timeout」エラーが表⽰される

クラスター・ノードがオンラインであるが、そのノードで実⾏されるサービスにアクセスしようとすると、応答しな

いか、「504 Gateway Timeout」エラーが返されることがあります。このエラーの原因は、containerd デーモンの再始動後にも古い containerd の参照が使⽤される Docker の既知の問題である可能性があります。この⽋陥のため、Docker デーモンが内部エラー・ループに陥り、⼤量の CPU リソースが使⽤され、多数のエラーがログに記録されます。このエラーについて詳しくは、Moby プロジェクトに対する Pull Request の『Refresh containerdremotes on containerd restarted』を参照してください。

この⽋陥が原因でエラーが発⽣しているのかどうかを判別するには、影響を受けているノードに SSH で接続し、journalctl -u kubelet -f コマンドを実⾏します。コマンド出⼒で、以下のテキストが含まれているエラー・メッセージを確認します。「transport: dial unix /var/run/docker/containerd/<container_id>: connect: connection refused」

このテキストが表⽰されている場合、top コマンドを実⾏し、dockerd が、使⽤可能な CPU の⾼いパーセンテージを使⽤していることを確認します。

この問題を回避するには、ホスト・オペレーティング・システム・コマンドを使⽤して、当該ノード上の docker サービスを再始動します。しばらくすると、サービスが再開されます。

ストレージに GlusterFS を使⽤している⼀部のポッドは⼿動で削除する必要がある

ストレージに GlusterFS PersistentVolume を使⽤しているポッドを削除しようとしたときに、そのポッドが Terminating 状態でスタックした場合、そのポッドを⼿動で削除する必要があります。次のコマンドを実⾏します。

kubectl -n <namespace> delete pods --grace-period=0 --force <pod_name>

先導マスターの再始動後に LDAP ユーザーで管理コンソールにログインできない

⾼可⽤性クラスター内の先導マスター・ノードを再始動した後に management console にログインできない場合、以下のアクションを実⾏します。

1. クラスター管理者の資格情報を使⽤して、管理コンソールにログインします。ユーザー名は admin であり、パスワードは admin です。

2. 「メニュー (Menu)」 > 「管理 (Manage)」 > 「認証 (LDAP) (Authentication (LDAP))」をクリックします。3. 「編集」をクリックしてから、「保存 (Save)」をクリックします。 LDAP ユーザーは、management consoleにログインできます。

Linux® on Power® (ppc64le) ノードにおける Calico の接頭部の制限

IBM Cloud Private を PowerVM Linux LPAR にインストールし、仮想 Ethernet デバイスが接頭部 ibmveth を使⽤している場合、Calico ネットワーキングを使⽤するようにネットワーク・アダプターを設定する必要があります。必ず、インストール時に、config.yaml ファイルに calico_ip_autodetection_method パラメーター値を設定してください。設定は、以下のテキストのようになります。

calico_ip_autodetection_method: interface=<device_name>


https://github.com/moby/moby/pull/36173

ここで、<device_name> は、ネットワーク・アダプターの名前です。ワーカー・ノードも含め、クラスターの各ノードで ibmveth0 インターフェースを指定する必要があります。注: PowerVC を使⽤してクラスター・ノードをデプロイした場合、この問題による影響は受けません。

Slack のアラートに無効なリンクが含まれる

Slack プロバイダーと Alertmanager を統合した場合、Slack メッセージに含まれているリンクは無効です。アラートを表⽰するには、https://<master_ip>:8443/alertmanager の Alertmanager ダッシュボードを開く必要があります。

ワーカー・ノードのシャットダウン後に StatefulSets が Terminating 状態のままになる

StatefulSet ポッドが実⾏されているノードがシャットダウンした場合、StatefulSet のポッドは Terminating 状態になります。 Terminating 状態でスタックしたポッドを⼿動で削除して、別のノードでのそのポッドの再作成を強制する必要があります。次のコマンドを実⾏します。

kubectl -n <namespace> delete pods --grace-period=0 --force <pod_name>

Kubernetes ポッドの安全管理について詳しくは、Kubernetes コミュニティーの Feature Spec の Pod Safety,Consistency Guarantees, and Storage Implications を参照してください。

LDAP 接続に制限がある

IBM Cloud Private で定義できる LDAP 接続は 1 つのみです。 LDAP 接続を追加した後に、その接続を編集することはできますが、削除することはできません。

リポジトリーの同期で Helm チャートの内容が更新されないことがある

リポジトリーの同期は、完了するまで数分かかります。同期の進⾏中、README ファイルを表⽰しようとすると、エラーが表⽰されることがあります。同期の完了後は、README ファイルを表⽰し、チャートをデプロイできます。

新しい management console から⼀部の機能を使⽤できない

IBM Cloud Private 2.1.0.3 では、新しい management console のみがサポートされます。ただし、以前のコンソールの⼀部のオプションがまだ使⽤可能になっていません。これを回避するには、該当する機能については、kubectlCLI を使⽤する必要があります。

コンテナーの開始に失敗する

コンテナーの開始に失敗し、「no space left on device」エラー・メッセージが表⽰されます。この問題は、cgroups のリークによって引き起こされる既知の Docker エンジンの問題です。この問題について詳しくは、https://github.com/moby/moby/issues/29638 および https://github.com/kubernetes/kubernetes/issues/61937 を参照してください。

この問題を回避するには、ホストを再始動する必要があります。

管理コンソールに「502 Bad Gateway Error」と表⽰される

インストール後またはマスター・ノードのリブート後に管理コンソールに「502 Bad Gateway Error」と表⽰されることがあります。 IBM Cloud Private を最近インストールした場合、数分待ってからページを再ロードしてください。


https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/pod-safety.md

https://github.com/moby/moby/issues/29638

https://github.com/kubernetes/kubernetes/issues/61937

マスター・ノードをリブートした場合、以下のステップを実⾏します。

1. icp-ds ポッドの IP アドレスを取得します。マスター・ノードから、以下のコマンドを実⾏します。

kubectl get pods -o wide -n kube-system | grep "icp-ds"

出⼒は、以下のテキストのようになります。

icp-ds-0 1/1 Running 0 1d 10.1.231.171 10.10.25.134

この例では、10.1.231.171 がポッドの IP アドレスです。

⾼可⽤性 (HA) 環境では、マスター・ノードごとに icp-ds ポッドが存在します。

2. マスター・ノードから、icp-ds ポッドに ping します。 IP アドレスごとに以下のコマンドを実⾏して、各 icp-ds ポッドの IP アドレスを確認します。

ping 10.1.231.171

出⼒が以下のテキストのようになっている場合、ポッドを削除する必要があります。

connect: Invalid argument

3. マスター・ノードから、到達できない各ポッドを削除します。

kubectl delete pods icp-ds-0 -n kube-system

この例では、icp-ds-0 が、応答しないポッドの名前です。

HA インストール済み環境では、マスター・ノードごとにポッドを削除する必要が⽣じる場合があります。

4. マスター・ノードから、代替ポッドの IP アドレスを取得します。次のコマンドを実⾏します。

kubectl get pods -o wide -n kube-system | grep "icp-ds"


icp-ds-0 1/1 Running 0 1d 10.1.231.172 10.10.2

5. ポッドに再度 ping します。 IP アドレスごとに以下のコマンドを実⾏して、各 icp-ds ポッドの IP アドレスを確認します。

ping 10.1.231.172

すべての icp-ds ポッドに到達できた場合、当該ポッドが使⽤可能状態になると、IBM Cloud Privatemanagement console にアクセスできます。

Ingress コントローラーが新しいアノテーション接頭部を使⽤できるようにする

NGINX Ingress アノテーションには、バージョン 0.9.0 で新しい接頭部が含まれるようになり、IBM Cloud Private2.1.0.3 nginx.ingress.kubernetes.io ではそれが使⽤されます。この変更は、実⾏中のデプロイメントへの中断を回避するためにフラグを使⽤します。

実⾏中の NGINX Ingress コントローラーが中断されないようにするには、フラグ --annotations-prefix=ingress.kubernetes.io を NGINX Ingress コントローラーのデプロイメントに追加します。製品は、IBM Cloud Private Ingress コントローラー内でフラグ --annotations-prefix=ingress.kubernetes.io をデフォルトで受け⼊れます。

新しい Ingress アノテーションを使⽤する場合は、以下のコマンドを使⽤して --annotations-prefix=ingress.kubernetes.io フラグを削除することで、Ingress コントローラーを更新します。


注: このコマンドはマスター・ノードから実⾏してください。

Linux® 64-bit の場合:

kubectl edit ds nginx-ingress-lb-amd64 -n kube-system

Linux® on Power® (ppc64le) の場合:

kubectl edit ds nginx-ingress-lb-ppc64le -n kube-system

次に、--annotations-prefix=ingress.kubernetes.io を削除します。変更を実装するには、保存して終了します。 Ingress コントローラーが再始動して、新しい構成が取得されます。

Ingress コントローラーの動的構成はデフォルトでは無効になっている

IBM Cloud Private 2.1.0.3 で使⽤される 0.13.0 Ingress コントローラーの動的構成は、デフォルトでは無効になっています。動的構成を有効にする場合は、--enable-dynamic-configuration=true を Ingress コントローラーの開始コマンドに追加して、コマンド kubectl edit ds -n kube-system nginx-ingress-controller を実⾏します。この問題について詳しくは、https://github.com/kubernetes/ingress-nginx/issues/2403 を参照してください。

vSphere クラウド・プロバイダーでパーシスタント・ボリューム・クレーム (PVC) の作成が失敗する

vSphere クラウド・プロバイダーを使⽤している場合、IBM Cloud Private ノードの VM ハードウェア・バージョンが13 以降であると、PVC がパーシスタント・ボリュームにバインドされない可能性があります。この問題の原因は、vSphere クラウド・プロバイダーがノードを UUID で⾒つけることができないためです。この問題について詳しくは、https://github.com/kubernetes/kubernetes/issues/58927 を参照してください。

この問題を回避するには、ノードの VM ハードウェア・バージョンを 13 より前のバージョンにする必要があります。

Calico ネットワーク使⽤時にノード名に⼤⽂字を使⽤できない

IBM Cloud Private クラスターで Calico ネットワークを使⽤している場合、ノードのホスト名または完全修飾ドメイン名 (FQDN) を必ず⼩⽂字で設定してください。これらの名前に⼤⽂字が使⽤されていると、IBM Cloud Private のインストールが失敗する可能性があります。

アップグレード時に動的にプロビジョンされたボリュームを使⽤した場合、モニター・

データは保持されない

動的にプロビジョンされた永続ボリューム (GlusterFS など) を使⽤してモニター・データを保管した場合、モニター・サービスを 2.1.0.2 から 2.1.0.3 にアップグレードした後にデータが失われます。

vSphere ストレージを使⽤している場合にノードを再始動できない

vSphere クラウド・プロバイダーを使⽤している IBM Cloud Private 環境では、クラスター・ノードをシャットダウンした場合、ノード上のポッドはクラスター内の別のノードに移動されます。ただし、ポッドが元のノードで使⽤していた vSphere ボリュームは、ノードから切り離されません。ノードを再始動しようとすると、エラーが表⽰されることがあります。

この問題を解決するには、まずボリュームをノードから切り離します。次に、ノードを再始動します。


https://github.com/kubernetes/ingress-nginx/issues/2403


⼀部の⾔語で切り捨てられたラベルがダッシュボードに表⽰される

Windows™ オペレーティング・システムを使⽤しているシステム上の Mozilla Firefox ブラウザーで、英語以外の⾔語の IBM Cloud Private ダッシュボードにアクセスした場合、⼀部のラベルが切り捨てられることがあります。

Helm リポジトリー名に DBCS GB18030 ⽂字を含めることはできない

Helm リポジトリーの追加時にリポジトリー名に DBCS GB18030 ⽂字を使⽤しないでください。

SELinux を使⽤している場合には計量サービスでデータが収集されない

SELinux (Security-Enhanced Linux) を使⽤している場合、計量サービスでは、Docker ソケットと通信できないため、IBM Cloud Private 上で実⾏されているワークロードに関するデータは収集されません。

IBM Cloud Private のインストール後に vSphere クラウド・プロバイダーを構成した場合に GlusterFS クラスターが使⽤不可になる

デフォルトでは、kubelet ではノード名としてノードの IP アドレスが使⽤されます。 vSphere クラウド・プロバイダーを構成した場合、kubelet ではノード名としてノードのホスト名が使⽤されます。 GlusterFS クラスターを IBMCloud Private のインストール時にセットアップした場合、Heketi では、ノードの IP アドレスを使⽤してトポロジーが作成されます。 IBM Cloud Private のインストール後に vSphere クラウド・プロバイダーを構成した場合、GlusterFS クラスターは使⽤不可になります。これは、kubelet ではノードがホスト名で識別されるのに対し、Heketiではノードの識別に IP アドレスが引き続き使⽤されるためです。

そのため、IBM Cloud Private クラスターで GlusterFS と vSphere クラウド・プロバイダーをともに使⽤する予定の場合は、インストール時に config.yaml ファイルに kubelet_nodename: hostnameを必ず設定してください。

IBM Cloud Private のアップグレードまたはロールバックが失敗すると、異なる状況の 2つのリリースが作成される

アップグレードまたはロールバックが失敗すると、同じ名前の 2 つのリリースがリストされます。1 つはアップグレードまたはロールバックされていない正常なリリースであり、もう 1 つはアップグレーまたはロールバックが失敗したリリースです。

このような同じ名前の 2 つのリリースは、同じリリースの 2 つの改訂であるため、⽚⽅を削除すると、もう⽚⽅も削除されます。リリースの複数の改訂が表⽰されるというこの問題は、既知のコミュニティーの Helm 2.7.2 の問題です。詳しくは、https://github.com/kubernetes/helm/issues/2941 を参照してください。

テクノロジー・プレビュー

このバージョンの IBM® Cloud Private では、⼀部の機能はテクノロジー・プレビュー・コード (TPC) としてのみ使⽤可能です。

テクノロジー・プレビュー・コード

IBM Cloud Private ソフトウェアには TPC が含まれており、これは以下の TPC に関するライセンス情報の条件の対象となります。

テクノロジー・プレビュー・コード: テクノロジー・プレビュー・コード (TPC) は、本プログラムまたは更新版に含まれるか、それらと共に配布されます。 TPC は、Notices File (または更新版に付随する Notices File の更新版) で特


https://github.com/kubernetes/helm/issues/2941

定されます。 TPC の⼀部または全部は、IBMによって、製品として、または製品に組み込まれて⼀般出荷可能になっていない場合があります。お客様は、実稼働環境での使⽤ではなく、内部評価を⾏う⽬的にのみ、TPC を使⽤することができます。 Notices File では、当該評価⽬的での使⽤を評価期間内に限定する場合があります。その場合、お客様は、かかる評価期間終了時に TPC の使⽤を停⽌し、アンインストールするものとします。 TPC に対するサポートは提供されません。また、TPC は現存するままの状態で提供され、商品性の黙⽰保証、特定⽬的適合性の黙⽰保証を含むがそれらに限定されない、⼀切の明⽰もしくは黙⽰の保証責任または保証条件を伴いません。お客様は、TPCを第三者に移転することはできません。 TPC には、評価期間終了後の使⽤を防ぐ無効化デバイスが含まれています。この無効化デバイスまたは TPC を改ざんすることはできません。 TPC を使⽤できなくなった場合に起こりうるデータの損失を回避するため、予防措置を講じなければなりません。

複数のクラスター (フェデレーション) の処理 IPVS を使⽤した kube-proxy の管理 Istio の処理カスタム・メトリックを使⽤したポッドの⽔平⾃動スケーリング containerd を使⽤した IBM® Cloud Private のインストール

複数のクラスターの処理 (フェデレーション)

フェデレーションをインストールおよび管理する⽅法を説明します。

複数のクラスターがある環境では、フェデレーションを使⽤することによって、複数の Kubernetes クラスターすべてに共通するサービスをデプロイおよび管理することができます。

フェデレーション・コントロール・プレーンのセットアップ

フェデレーションのインストールの検証

フェデレーションでの外部ポリシー・エンジンの処理

外部ポリシー・エンジンの検証

フェデレーションへのクラスターの追加


フェデレーション・コントロール・プレーンのセットアップ

IBM® Cloud Private のインストール中に、クラスターの 1 つにフェデレーション・プレーンをデプロイすることを選択できます。この指定された IBM Cloud Private ホスト・クラスターは、フェデレーション・コントロール・プレーンのコンポーネントを含みます。フェデレーション・コントロール・プレーンは、フェデレーション API サーバーおよびコントローラー・マネージャーからなります。

フェデレーション・コントロール・プレーンを使⽤可能にするには、config.yaml ファイル内で federation_enabled を true に設定する必要があります。

フェデレーションが使⽤可能にされているクラスターの構成ファイルは、次のようになります。

## Federation cluster settings federation_enabled: true federation_cluster: federation-cluster federation_domain: cluster.federation # federation_apiserver_extra_args: [] # federation_controllermanager_extra_args: []

フェデレーションの設定について詳しくは、表 8: フェデレーション設定を参照してください。

フェデレーションのインストールの検証

インストールが完了した後、初期フェデレーション・クラスターが作成されたことを確認します。ホスト・クラスターのブート・ノードで以下のコマンドを実⾏します。ホスト・クラスターはデフォルトでフェデレーションに追加さ


れます。以下のコマンドを実⾏する前に、kubectl CLI のセットアップを⾏ったことを確認してください。

フェデレーション内のすべてのクラスターのリストを表⽰するには、次のコマンドを実⾏します。

kubectl --kubeconfig=<installation_directory>/cluster/conf/kubeconfig \ --context=federation-cluster get clusters

出⼒は、以下のコードのようになります。

NAME AGE mycluster 4h

フェデレーション内のすべての名前空間のリストを表⽰するには、次のコマンドを実⾏します。

kubectl --kubeconfig=<installation_directory>/cluster/conf/kubeconfig \ --context=federation-cluster get namespaces


NAME STATUS AGE default Active 4h

フェデレーションでの外部ポリシー・エンジンの処理

フェデレーション外部ポリシーを有効化して IBM Cloud Private クラスターをインストールした後、クラスターに外部ポリシー・エンジン (OPA) がデプロイされます。デフォルト・ポリシーを表⽰するには、次のコマンドを実⾏します。

kubectl --context=federation-cluster --namespace=kube-federation-scheduling-policy get configmap scheduling-policy

スケジューリング・ポリシーを更新するには、以下のようにします。

1. デフォルトのスケジューリング・ポリシー ConfigMap を編集します。

kubectl --context=federation-cluster --namespace=kube-federation-scheduling-policy edit configmap scheduling-policy

2. 必要な場合、デフォルトのスケジューリング・ポリシーを更新し、変更を保存できます。スケジューリング・ポリシーは動的にロードされます。

外部ポリシー・エンジンの検証

サンプル・スケジューリング・ポリシーが予期したとおりに機能することを確認します。

1. クラスターの 1 つにアノテーションを追加します。

kubectl --context=federation-cluster annotate clusters mycluster pci-certified=true

2. ReplicationSet リソースを作成します。 ReplicationSet のアノテーション・セクションに requires-pci: "true" を設定する必要があります。

apiVersion: apps/v1 kind: ReplicaSet metadata: labels: app: nginx-pci name: nginx-pci annotations: requires-pci: "true" spec: replicas: 3


selector: matchLabels: app: nginx-pci template: metadata: labels: app: nginx-pci spec: containers: - image: nginx name: nginx-pci

3. この ReplicationSet リソースをデプロイします。

kubectl --context=federation-cluster apply -f nginx-pci.yaml

この RepicationSet は、nginx-pci の 3 個のレプリカを⼦クラスター mycluster 内に作成します。

4. nginx-pci ReplicationSet の仕様を表⽰するため、次のコマンドを実⾏します。

kubectl --context=federation-cluster get rs nginx-pci -o yaml

出⼒では、レプリカ・スケジューリングに関して以下のアノテーションが追加されたことが⽰されます。

annotations: federation.kubernetes.io/replica-set-preferences: '{"clusters":{"cluster22":{"weight":1}},"rebalance":true}'

スケジューリング・アノテーションについて詳しくは、https://v1-10.docs.kubernetes.io/docs/tasks/administer-federation/replicaset/ を参照してください。

フェデレーションへのクラスターの追加

IBM® Cloud Private フェデレーションにクラスターを追加します。

⽤語

クライアント・ノードとは、フェデレーションへのアクセスおよびフェデレーションの管理に使⽤するノード

のことです。このノードは、IBM Cloud Private クラスターのメンバーでなければなりません。⼦クラスターとは、フェデレーションに追加される IBM Cloud Private クラスターまたは Kubernetes クラスターのことです。

ホスト・クラスターとは、フェデレーション・コントロール・プレーンがデプロイされている IBM CloudPrivate クラスターまたは Kubernetes クラスターのことです。

フェデレーションの⽅式

Federation architecture

⼿順

1. root としてクライアント・ノードにログオンします。

2. ⼦クラスターおよびホスト・クラスターのパラメーター⽤の環境変数を作成します。

⼦クラスターのパラメーター⽤に以下のコマンドを実⾏します。

export child_cluster_name="<child_cluster>" export child_cluster_url="<child_cluster_url>"


https://v1-10.docs.kubernetes.io/docs/tasks/administer-federation/replicaset/

child_cluster_name は、⼦クラスターのクラスター名です。 IBM Cloud Private クラスターの場合、クラスター名は、インストール中に config.yaml ファイル内に設定されます。表 1: ⼀般設定を参照してください。

child_cluster_url は、⼦クラスターの API サーバー URL です。例えば、https:// :8001 です。

ホスト・クラスターのパラメーター⽤に以下のコマンドを実⾏します。

export host_cluster_name="<host_cluster_name>" export host_cluster_url="<host_cluster_url>"

host_cluster_name は、ホスト・クラスターのクラスター名です。 IBM Cloud Private クラスターの場合、クラスター名は、インストール中に config.yaml ファイル内に設定されます。表1: ⼀般設定を参照してください。host_cluster_url は、ホスト・クラスターの API サーバー URL です。例えば、https://:8001 です。

3. ホスト・クラスターのブート・ノードからクライアント・ノードへ kubeconfig ファイルをコピーします。

mkdir /root/.kube scp root@<boot_node_host>:<installation_directory>/cluster/conf/kubeconfig /root/.kube/

次に、kubeconfig ファイルを config に名前変更します。

mv /root/.kube/kubeconfig /root/.kube/config

4. kubectl および kubefed を抽出します。

Standard Edition:

sudo docker run -e LICENSE=accept --rm -v /usr/local/bin/:/data/ ibmcom/icp-inception:2.1.0.3-ee cp /usr/local/bin/kubectl /usr/local/bin/kubefed /data

Community Edition:

sudo docker run -e LICENSE=accept --rm -v /usr/local/bin/:/data/ ibmcom/icp-inception:2.1.0.3 cp /usr/local/bin/kubectl /usr/local/bin/kubefed /data

5. ⼦クラスターの kubeconfig を構成します。

mkdir -p /root/federation/$child_cluster_name kubectl config set-cluster $child_cluster_name --server=$child_cluster_url \ --insecure-skip-tls-verify=true kubectl config set-context $child_cluster_name --cluster=$child_cluster_name kubectl config set-credentials $child_cluster_name \ --client-certificate=/root/federation/$child_cluster_name/kubecfg.crt \ --client-key=/root/federation/$child_cluster_name/kubecfg.key kubectl config set-context $child_cluster_name --user=$child_cluster_name

6. ⼦クラスターのマスター・ノードからクライアント・ノードへ Kubernetes 証明書ファイルをコピーします。

⼦クラスターが IBM Cloud Private クラスターである場合、⼦クラスターのマスター・ノードからクライアントの /root/federation/$child_cluster_name ディレクトリーへ Kubernetes 証明書をコピーします。

scp root@<master_node_child>:/var/lib/kubelet/kubecfg.* /root/federation/$child_cluster_name


⼦クラスターが (IBM Cloud Private によってデプロイされたのではない) Kubernetes クラスターである場合、クラスター管理者に連絡して必要な証明書を⼊⼿します。その後、証明書をクライアント・ノード上のターゲット・ディレクトリーにコピーします。

7. ⼦クラスター⽤に kubeconfig が正しく構成されていることを検証します。

kubectl --context=$child_cluster_name get nodes

8. ホスト・クラスターの kubeconfig を構成します。

mkdir -p /root/federation/$host_cluster_name kubectl config set-cluster $host_cluster_name --server=$host_cluster_url --insecure-skip-tls-verify=true kubectl config set-context $host_cluster_name --cluster=$host_cluster_name kubectl config set-credentials $host_cluster_name \ --client-certificate=/root/federation/$host_cluster_name/kubecfg.crt \ --client-key=/root/federation/$host_cluster_name/kubecfg.key kubectl config set-context $host_cluster_name --user=$host_cluster_name

9. ホスト・クラスターのマスター・ノードからクライアント・ノードへ Kubernetes 証明書ファイルをコピーします。

ホスト・クラスターが IBM Cloud Private クラスターである場合、ホスト・クラスターのマスター・ノードからクライアントの /root/federation/$host_cluster_name ディレクトリーへ Kubernetes証明書をコピーします。

scp root@<master_node>:/var/lib/kubelet/kubecfg.* /root/federation/$host_cluster_name

ホスト・クラスターが (IBM Cloud Private によってデプロイされたのではない) Kubernetes クラスターである場合、クラスター管理者に連絡して必要な証明書を⼊⼿します。その後、証明書をクライアント・ノード上のターゲット・ディレクトリーにコピーします。

10. ホスト・クラスター⽤に kubeconfig が正しく構成されていることを検証します。

kubectl --context=$host_cluster_name get nodes

11. コンテキストを、フェデレーション・クラスターのコンテキストに設定します。

kubectl config use-context federation-cluster

12. クラスターに参加するための kubefed コマンドを実⾏します。

kubefed join $child_cluster_name --host-cluster-context=$host_cluster_name --cluster-context=$child_cluster_name

13. フェデレーション内のクラスターを表⽰します。

kubectl get clusters

⼦クラスターの準備ができたら、フェデレーション・リソースを作成できます。詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/cluster-administration/federation/ を参照してください。


IBM® Cloud Private フェデレーションから⼦クラスターを削除します。


https://v1-10.docs.kubernetes.io/docs/concepts/cluster-administration/federation/

フェデレーションから⼦クラスターを削除するには、クライアント・ノードで以下のコマンドを実⾏します。

kubefed unjoin $child_cluster_name --host-cluster-context=$host_cluster_name --cluster-context=$child_cluster_name

変数 $child_cluster_name および $host_cluster_name の設定⽅法について詳しくは、フェデレーションへのクラスターの追加を参照してください。

IPVS を使⽤した kube-proxy の管理

IPVS (IP Virtual Server) は、Kubernetes 1.9.1 のベータ機能です。 kube-proxy ipvs モードは、iptables およびuserspace モードを使⽤する従来型の⽅法に⽐べてパフォーマンスが向上するといった利点を kube-proxy にもたらします。

ホスト上で実⾏されている IPVS は、複数の実サーバーからなるクラスターの前⾯でロード・バランサーとして動作します。 IPVS は、TCP/UDP ベースのサービスへの要求を実サーバーに誘導します。また、IPVS は、実サーバー上で実⾏されているサービスを、単⼀ IP アドレスにある 1 つの仮想サービスに⾒えるようにすることもできます。

kube-proxy ipvs モードを有効にするには、クラスター構成ファイル内に kube_proxy_extra_args パラメーターを設定する必要があります。

kube-proxy ipvs を有効にしたクラスターの構成ファイルは、以下の出⼒に似たものになります。

## Kubernetes Settings # kube_apiserver_extra_args: [] # kube_controller_manager_extra_args: [] kube_proxy_extra_args: ["--feature-gates=SupportIPVSProxyMode=true","--proxy-mode=ipvs"]

インストールが完了した後、以下のステップを実⾏して、IPVS ルールが作成されたことを確認します。

1. kube-proxy コンテナー・ログを検討します。

[root@testnode ~]# docker ps |grep proxy 6e8b9b058bfc ibmcom/kubernetes@sha256:0a186c019bd7d3a078799a387663da93c162b290b0665d16b229dba7d8f060b7 "/hyperkube proxy ..." 11 minutes ago Up 11 minutes k8s_proxy_k8s-proxy-9.21.53.16_kube-system_97991d33fbaf5606a3a6113337710e27_0 docker logs 6e8b9b058bfc -f ... I0131 13:24:32.282248 1 feature_gate.go:184] feature gates: map[SupportIPVSProxyMode:true] I0131 13:24:32.283828 1 server_others.go:180] Using ipvs Proxier. I0131 13:24:32.284643 1 server_others.go:205] Tearing down inactive rules. I0201 05:31:25.008541 1 server.go:426] Version: v1.10.0+icp-ee ...

2. 各クラスター・ノードで IPVS モードが検出されることを確認します。

ipvsadm -Ln


IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.17.0.1:31443 rr -> 10.1.20.84:9443 Masq 1 0 0 TCP 172.17.0.1:32292 rr -> 10.1.20.94:3000 Masq 1 0 0


TCP 9.21.53.16:30090 rr -> 10.1.20.80:9090 Masq 1 0 0 TCP 9.21.53.16:30296 rr -> 10.1.20.93:3001 Masq 1 0 0 TCP 9.21.53.16:31443 rr -> 10.1.20.84:9443 Masq 1 0 0 TCP 9.21.53.16:32292 rr ...

Istio の処理

Istio は、マイクロサービスの接続、管理、および保護に使⽤できるオープン・プラットフォームです。サービス・コードを変更することなく、ロード・バランシング、サービス間認証、モニターなどのデプロイ済みサービスのネッ

トワークを簡単に作成できます。 Istio サポートをサービスに追加するには、Istio で提供されるコントロール・プレーン機能を使⽤して、構成済みで管理下にあるマイクロサービス間のすべてのネットワーク通信を傍受する特別なサ

イドカー・プロキシーを環境全体にデプロイする必要があります。

IBM Cloud Private 2.1.0.3 では、Istio を有効にする⽅法が 2 つサポートされています。クラスター・インストール中に Istio を有効にするか、またはクラスター・インストール後に「カタログ」から Istio チャートをインストールすることができます。

クラスター・インストール中の Istio の有効化

クラスター・インストール中に Istio を有効にするには、cluster/config.yaml 内の disabled_management_services から istio を削除する必要があります。

以下の出⼒に⽰すように、istio が disabled_management_services パラメーターにリストされていないことを確認します。

## Disabled Management Services Settings ## You can disable the following management services: ["service-catalog", "metering", "monitoring", "istio", "vulnerability-advisor", "custom-metrics-adapter"] disabled_management_services: ["vulnerability-advisor", "custom-metrics-adapter"]

Istio はサイドカーの⾃動注⼊をサポートします。デフォルトでは、IBM Cloud Private でサイドカーの⾃動注⼊は無効になっています。

サイドカーの⾃動注⼊を有効にするには、cluster/config.yaml ファイルに以下の内容を追加します。

# Istio chart configuration istio: sidecar-injector: enabled: true

ご使⽤の IBM Cloud Private クラスターがインターネットにアクセスできない場合は、sidecar autoinjection を使⽤しないでください。 sidecar autoinjection には imagePullSecrets が含まれていないため、プライベート・レジストリーからイメージをプルできない可能性があります。 IBM Cloud Private は Istio 0.7.1 を使⽤します。サイドカーの⾃動注⼊は Istio 0.7.1 ではサポートされていません。この問題は Istio 0.8 では解決されており、IBMCloud Private の将来のリリースでは使⽤できます。

IBM Cloud Private のインストールを開始する準備ができました。 Istio は IBM Cloud Private インストーラーによってインストールされます。

既存クラスターに対する Istio のインストール

既に IBM Cloud Private 2.1.0.3 クラスターがインストールされている場合は、「カタログ」から ibm-istio チャートをインストールすることで Istio をデプロイすることも可能です。


https://istio.io/

1. ibm-istio チャートがデプロイされる名前空間 istio-system を作成します。

# kubectl create ns istio-system

2. IBM Cloud Private 管理コンソールにログインし、メニューから「カタログ」をクリックします。

3. フィルター・ツールを使⽤して Istio を検索します。検索が完了すると、ibm-istio チャートが表⽰されます。

4. ibm-istio チャートをクリックします。チャートのインストール、アンインストール、および構成に関する情報が含まれている README ファイルが⽤意されています。

5. 「構成」をクリックして構成ページに進みます。6. リリースの名前を指定して istio-system 名前空間を選択します。名前は、⼩⽂字の英字、数字、またはダッシュ⽂字 (-) で構成される必要があり、先頭と末尾は英数字でなければなりません。

7. (オプション) 好みに合わせてフィールドをカスタマイズします。サイドカーの⾃動注⼊を有効にする場合は、「サイドカー・インジェクターを有効にする (sidecar-injector enabled)」をクリックします。

8. ご使⽤条件を読んで同意したことを確認します。9. 「インストール」をクリックし、Istio チャートをデプロイし、Istio リリースを作成します。

インストールの確認

インストールが完了したら、以下のようにして Istio control plane が作成されていることを確認します。

1. 必須 Kubernetes サービス istio-security、istio-pilot、istio-mixer、istio-ingress がデプロイされていることを確認します。注: istio-grafana、istio-prometheus、istio-servicegraph、およびistio-zipkin はオプションです。デフォルトでは、IBM Cloud Private で有効になっています。

kubectl -n istio-system get svc

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-grafana ClusterIP 10.0.0.30 <none> 3000/TCP 32m istio-ingress LoadBalancer 10.0.0.19 <pending> 80:31205/TCP,443:31295/TCP 32m istio-mixer ClusterIP 10.0.0.189 <none> 9091/TCP,15004/TCP,9093/TCP,9094/TCP,9102/TCP,9125/UDP,42422/TCP 32m istio-pilot ClusterIP 10.0.0.12 <none> 15005/TCP,15007/TCP,15003/TCP,15010/TCP,8080/TCP,9093/TCP,443/TCP 32m istio-prometheus ClusterIP 10.0.0.106 <none> 9090/TCP 32m istio-security ClusterIP 10.0.0.157 <none> 8060/TCP 32m istio-servicegraph ClusterIP 10.0.0.196 <none> 8088/TCP 32m istio-zipkin ClusterIP 10.0.0.156 <none> 9411/TCP 32m

1. 対応する次の Kubernetes ポッドがデプロイされ、すべてのコンテナーが実⾏中で使⽤可能であることを確認します。istio-ca- *、istio-ingress- *、istio-mixer- *、istio-pilot- *。注: istio-sidecar-injector- *、istio-grafana- *、istio-prometheus- *、istio-servicegraph- *、および istio-zipkin- * はオプションです。

# kubectl -n istio-system get pods

NAME READY STATUS RESTARTS AGE istio-ca-86d77498ff-8hmwc 1/1 Running 0 32m istio-grafana-684ff696b-lhqk6 1/1 Running 0 32m istio-ingress-5cb7767559-hjqft 1/1 Running 0 32m istio-ingress-5cb7767559-ndscw 1/1 Running 0 32m istio-mixer-7644994b7d-d74hj 3/3 Running 0 32m istio-pilot-7fc9b6c554-m5c8d 2/2 Running 0 32m


istio-prometheus-8675bb8bb6-549tl 1/1 Running 0 32m istio-servicegraph-667d8569cb-6xfwp 1/1 Running 0 32m istio-zipkin-557985787-p5hk7 1/1 Running 0 32m

アプリケーションのデプロイ

Istio control plane が正常にデプロイされた後、アプリケーションのデプロイを開始できます。

プライベート・レジストリーを使⽤するための秘密の作成

プライベート・レジストリーを使⽤する場合は、許可トークンを保持するクラスター内に docker-registry タイプの regcred という名前の secret を作成します。それをアプリケーションに関連付けられた ServiceAccountに適⽤します。以下の例では、ServiceAccount として default を使⽤しています。

kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email> kubectl get serviceaccount default -o yaml | grep -w regcred || kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "regcred"}]}'

サイドカーの⾃動注⼊

サイドカーの⾃動注⼊を有効にした場合、istio-sidecar-injector によって、Envoy コンテナーが istio-injection=enabled というラベルの名前空間で実⾏されるアプリケーション・ポッドに⾃動的に注⼊されます。

kubectl label namespace <namespace> istio-injection=enabled kubectl create -n <namespace> -f <your-app-spec>.yaml

サイドカーの⼿動注⼊

サイドカーの⾃動注⼊を有効にしなかった場合は、注⼊ツール istioctl を使⽤して、Envoy コンテナーをアプリケーションに⼿動で注⼊します。

以下の⼿順を実⾏して、Istio istioctl CLI をダウンロードします。

1. istioctl を含む最新の Istio リリース・パッケージをダウンロードして解凍します。

mkdir istio-0.7.1 && \ docker run --rm -v `pwd`:/home/ ibmcom/istioctl:0.7.1 tar -x --strip-components=1 \ -f /root/istio-0.7.1.tar.gz -C /home/istio-0.7.1/

2. Istio パッケージを解凍したディレクトリーに移動し、istioctl クライアントを PATH に追加します。

cd istio-0.7.1 export PATH=$PWD/bin:$PATH

さらに、ConfigMap を作成して、以下のようなサイドカー・インジェクター構成を組み込む必要があります。

cat <<EOF | kubectl create -f - apiVersion: v1 kind: ConfigMap metadata: name: istio-sidecar-injector-configuration namespace: istio-system labels: app: sidecar-injector istio: sidecar-injector data: config: |- policy: enabled template: |- initContainers: - name: istio-init


image: ibmcom/istio-proxy_init:0.7.1 imagePullPolicy: IfNotPresent args: - "-p" - {{ .MeshConfig.ProxyListenPort }} - "-u" - 1337 securityContext: capabilities: add: - NET_ADMIN privileged: true restartPolicy: Always containers: - name: istio-proxy image: ibmcom/istio-proxy:0.7.1 imagePullPolicy: IfNotPresent args: - proxy - sidecar - --configPath - {{ .ProxyConfig.ConfigPath }} - --binaryPath - {{ .ProxyConfig.BinaryPath }} - --serviceCluster {{ if ne "" (index .ObjectMeta.Labels "app") -}} - {{ index .ObjectMeta.Labels "app" }} {{ else -}} - "istio-proxy" {{ end -}} - --drainDuration - {{ formatDuration .ProxyConfig.DrainDuration }} - --parentShutdownDuration - {{ formatDuration .ProxyConfig.ParentShutdownDuration }} - --discoveryAddress - {{ .ProxyConfig.DiscoveryAddress }} - --discoveryRefreshDelay - {{ formatDuration .ProxyConfig.DiscoveryRefreshDelay }} - --zipkinAddress - {{ .ProxyConfig.ZipkinAddress }} - --connectTimeout - {{ formatDuration .ProxyConfig.ConnectTimeout }} - --statsdUdpAddress - {{ .ProxyConfig.StatsdUdpAddress }} - --proxyAdminPort - {{ .ProxyConfig.ProxyAdminPort }} - --controlPlaneAuthPolicy - {{ .ProxyConfig.ControlPlaneAuthPolicy }} env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: INSTANCE_IP valueFrom: fieldRef: fieldPath: status.podIP securityContext: privileged: true readOnlyRootFilesystem: false runAsUser: 1337 restartPolicy: Always volumeMounts:


- mountPath: /etc/istio/proxy name: istio-envoy - mountPath: /etc/certs/ name: istio-certs readOnly: true volumes: - emptyDir: medium: Memory name: istio-envoy - name: istio-certs secret: optional: true {{ if eq .Spec.ServiceAccountName "" -}} secretName: istio.default {{ else -}} secretName: {{ printf "istio.%s" .Spec.ServiceAccountName }} {{ end -}} EOF

これで、前のセクションで作成した ConfigMap に injectConfigMapName パラメーターを指定することで、アプリケーションをデプロイできます。

kubectl create -f <(istioctl kube-inject --injectConfigMapName istio-sidecar-injector-configuration -f <your-app-spec>.yaml)

注: サイドカーの⾃動注⼊でデバッグ・モードを有効にするには、ConfigMap 内の注⼊テンプレートに別の init コンテナーを追加してから ConfigMap を作成してください。完全なインジェクター構成は、以下のようになります。

apiVersion: v1 kind: ConfigMap metadata: name: istio-sidecar-injector-configuration namespace: istio-system labels: app: sidecar-injector istio: sidecar-injector data: config: |- policy: enabled template: |- initContainers: - name: istio-init image: ibmcom/istio-proxy_init:0.7.1 imagePullPolicy: IfNotPresent args: - "-p" - {{ .MeshConfig.ProxyListenPort }} - "-u" - 1337 securityContext: capabilities: add: - NET_ADMIN privileged: true restartPolicy: Always - name: enable-core-dump image: alpine imagePullPolicy: IfNotPresent command: - /bin/sh args: - -c #/etc/istio/proxy value here matches ConfigPathDir const in context.go - sysctl -w kernel.core_pattern=/etc/istio/proxy/core.%e.%p.%t && ulimit -c unlimited resources: {}


securityContext: privileged: true containers: - name: istio-proxy image: ibmcom/istio-proxy:0.7.1 imagePullPolicy: IfNotPresent args: - proxy - sidecar - --configPath - {{ .ProxyConfig.ConfigPath }} - --binaryPath - {{ .ProxyConfig.BinaryPath }} - --serviceCluster {{ if ne "" (index .ObjectMeta.Labels "app") -}} - {{ index .ObjectMeta.Labels "app" }} {{ else -}} - "istio-proxy" {{ end -}} - --drainDuration - {{ formatDuration .ProxyConfig.DrainDuration }} - --parentShutdownDuration - {{ formatDuration .ProxyConfig.ParentShutdownDuration }} - --discoveryAddress - {{ .ProxyConfig.DiscoveryAddress }} - --discoveryRefreshDelay - {{ formatDuration .ProxyConfig.DiscoveryRefreshDelay }} - --zipkinAddress - {{ .ProxyConfig.ZipkinAddress }} - --connectTimeout - {{ formatDuration .ProxyConfig.ConnectTimeout }} - --statsdUdpAddress - {{ .ProxyConfig.StatsdUdpAddress }} - --proxyAdminPort - {{ .ProxyConfig.ProxyAdminPort }} - --controlPlaneAuthPolicy - {{ .ProxyConfig.ControlPlaneAuthPolicy }} env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: INSTANCE_IP valueFrom: fieldRef: fieldPath: status.podIP securityContext: privileged: true readOnlyRootFilesystem: false runAsUser: 1337 restartPolicy: Always volumeMounts: - mountPath: /etc/istio/proxy name: istio-envoy - mountPath: /etc/certs/ name: istio-certs readOnly: true volumes: - emptyDir: medium: Memory name: istio-envoy - name: istio-certs secret:


optional: true {{ if eq .Spec.ServiceAccountName "" -}} secretName: istio.default {{ else -}} secretName: {{ printf "istio.%s" .Spec.ServiceAccountName }} {{ end -}}

Istio について詳しくは、https://istio.io/docs/ を参照してください。

制限

Power 上の Istio (ppc64le)

Istio を使⽤して独⾃のフィルターを作成できます。HTTP フィルターはその⼀タイプです。 Power 上で Istio を実⾏する場合、HTTP Lua フィルターはサポートされません。このフィルターは luajit コンパイラーを使⽤しますが、これには Power ⽤の 64 ビット・リトル・エンディアン・サポートがありません。現時点で、Power ⽤の HTTP Lua フィルター・サポートを追加する計画はありません。

Lua またはその他の拡張を使⽤した独⾃のフィルターの作成について詳しくは、ご使⽤の特定のリリース⽤の Envoy資料を参照してください。

デフォルト以外の名前空間でのアプリケーション・デプロイメント

Istio 注⼊を使⽤してアプリケーションをデフォルト以外の名前空間にデプロイする場合は、インストール⽤のポッド・セキュリティー・ポリシーを作成することをお勧めします。詳しくは、『デフォルト以外の名前空間への IBMCloud Private 上の Istio 対応アプリケーションのデプロイ (Deploy Istio enabled application on IBM Cloud Private ina non-default namespace) 』を参照してください。

カスタム・メトリックを使⽤したポッドの⽔平⾃動スケーリング

IBM Cloud Private の⽔平ポッド⾃動スケーラー (HPA) を使⽤すると、リソース使⽤量に基づいてワークロードを⾃動的に増減できます。この⾃動スケーリングは、ワークロードのサービス・レベル・アグリーメント (SLA) を保証するのに役⽴ちます。

デフォルトでは、実際の CPU 使⽤率に基づいて、HPA ポリシーがHPA ポリシーがポッド数を⾃動的に増減します。ただし、多くの場合、着信要求数やメモリー消費量など、他のモニター対象メトリックに基づいてアプリケーション

をスケーリングすることがあります。 IBM Cloud Private バージョン 2.1.0.3 以降、Prometheus および Prometheusアダプターを活⽤してスケーリングを⾃動化することができます。

Prometheus

Prometheus は、Kubernetes クラスターのすべてのコンポーネントをモニターするために広く使⽤されています。これらのコンポーネントには、クラスター上で実⾏されているコントロール・プレーン、ワーカー・ノード、および

アプリケーションなどがあります。

Prometheus アダプター

Prometheus アダプターは、追加の Kubernetes スタイルの API をインストールし、カスタム API サーバーをKubernetes クラスターに登録する Kubernetes 統合機能層です。このアダプターは、Prometheus から使⽤可能なメトリックの名前を定期的に収集し、⾃動スケーリングのためにメトリックを HPA に公開します。

インストールの準備


https://istio.io/docs/

https://www.envoyproxy.io/docs

https://medium.com/ibm-cloud/deploy-istio-enabled-application-on-ibm-cloud-private-in-a-non-default-namespace-e44f897ce228

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

https://github.com/prometheus/prometheus

https://github.com/DirectXMan12/k8s-prometheus-adapter

https://kubernetes.io/docs/concepts/api-extension/apiserver-aggregation/

デフォルトでは、IBM Cloud Private で CPU 使⽤率に基づいて⾃動スケーリングするために HPA が有効になっています。カスタム・メトリックに基づいて⾃動スケーリングを⾏えるようにするには、/<installation_directory>/cluster/config.yaml ファイルで disabled_management_services パラメーターから custom-metrics-adapter オプションを削除する必要があります。

構成ファイルは、以下のようなコードになります。

## Disabled Management Services Settings ## You can disable the following management services: ["service-catalog", "metering", "monitoring", "istio", "vulnerability-advisor", "custom-metrics-adapter"] disabled_management_services: ["istio", "vulnerability-advisor"]


インストールが完了したら、custom-metrics-adapter が有効になっていることを確認します。

1. autoscaling/v2beta1 API グループが表⽰されることを確認します。

kubectl api-versions |grep "autoscaling/v2beta1"


autoscaling/v2beta1

2. 対応する custom-metrics-adapter ポッドがデプロイされ、running 状態であることを確認します。

kubectl get po -n kube-system |grep custom-metrics-adapter


custom-metrics-adapter-76d7bb8dcd-2pj4k 1/1 Running 0 18m

3. ポッド上の Prometheus アダプターによって提供されるデフォルトのカスタム・メトリックをリストします。

kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq . |grep "pods/"


"name": "pods/kube_pod_container_status_waiting_reason", "name": "pods/fs_read", "name": "pods/memory_failures", "name": "pods/kube_pod_status_phase", "name": "pods/kube_pod_container_resource_limits_memory_bytes", "name": "pods/cpu_user", "name": "pods/fs_usage_bytes", "name": "pods/tasks_state", "name": "pods/kube_pod_container_info", "name": "pods/cpu_cfs_throttled", "name": "pods/fs_sector_writes", "name": "pods/kube_pod_created", "name": "pods/network_tcp_usage", "name": "pods/spec_memory_limit_bytes", "name": "pods/network_udp_usage", "name": "pods/memory_max_usage_bytes", "name": "pods/spec_cpu_quota", "name": "pods/kube_pod_container_status_terminated_reason", "name": "pods/cpu_system", "name": "pods/kube_pod_container_status_running", "name": "pods/kube_pod_status_ready", "name": "pods/fs_io_time_weighted", "name": "pods/fs_reads_bytes", "name": "pods/kube_pod_info", "name": "pods/fs_reads_merged",


"name": "pods/kube_pod_container_resource_requests_cpu_cores", "name": "pods/fs_io_time", "name": "pods/kube_pod_container_resource_limits_cpu_cores", "name": "pods/fs_inodes", "name": "pods/start_time_seconds", "name": "pods/kube_pod_container_status_terminated", "name": "pods/kube_pod_container_status_waiting", "name": "pods/cpu_usage", "name": "pods/spec_cpu_shares", "name": "pods/spec_memory_reservation_limit_bytes", "name": "pods/kube_pod_container_status_ready", "name": "pods/fs_writes_merged", "name": "pods/fs_inodes_free", "name": "pods/cpu_cfs_throttled_periods", "name": "pods/kube_pod_labels", "name": "pods/cpu_load_average_10s", "name": "pods/fs_io_current", "name": "pods/memory_working_set_bytes", "name": "pods/spec_memory_swap_limit_bytes", "name": "pods/fs_reads", "name": "pods/kube_pod_container_resource_requests_memory_bytes", "name": "pods/memory_rss", "name": "pods/cpu_cfs_periods", "name": "pods/fs_writes_bytes", "name": "pods/fs_writes", "name": "pods/last_seen", "name": "pods/spec_cpu_period", "name": "pods/kube_pod_start_time", "name": "pods/fs_write", "name": "pods/memory_failcnt", "name": "pods/kube_pod_container_status_restarts", "name": "pods/fs_sector_reads", "name": "pods/kube_pod_status_scheduled", "name": "pods/memory_cache", "name": "pods/memory_usage_bytes", "name": "pods/memory_swap", "name": "pods/fs_limit_bytes", "name": "pods/kube_pod_owner",

例: HPA ポリシーを使⽤したアプリケーションのデプロイ

この例では、HPA ポリシーを使⽤して、メモリー使⽤量に基づいて nginx Web アプリケーションを⾃動スケーリングする⽅法を⽰します。 nginx ポッドの memory_usage_bytes が 10M より⼤きい場合、ポリシーは nginx Web アプリケーションを拡⼤します。アプリケーションを拡⼤すると、デプロイメントに使⽤できるポッドの数が増加します。 nginx ポッドの memory_usage_bytes が 10M より⼩さい場合、アプリケーションは縮⼩されますが、デプロイメント⽤に指定されたレプリカの最⼩数を下回ることはありません。

1. podinfo サービスを作成します。

cat podinfo-svc.yaml &&kubectl create -f podinfo-svc.yaml


--- apiVersion: v1 kind: Service metadata: name: podinfo labels: app: podinfo annotations: prometheus.io/scrape: "true" spec: type: NodePort ports:


- port: 80 targetPort: 80 nodePort: 31198 protocol: TCP selector: app: podinfo service "podinfo" created

2. podinfo デプロイメントを作成します。

cat podinfo-dep.yaml &&kubectl create -f podinfo-dep.yaml


--- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: podinfo spec: replicas: 2 template: metadata: labels: app: podinfo annotations: prometheus.io/scrape: 'true' spec: containers: - name: podinfod image: nginx:1.8.1 imagePullPolicy: Always ports: - containerPort: 80 protocol: TCP resources: requests: memory: "32Mi" cpu: "1m" limits: memory: "256Mi" cpu: "100m"

3. ポッドのメモリー使⽤量 (memory_usage_bytes, 10485760 =10M) に基づいて podinfo HPA ポリシーを作成します。

cat podinfo-hpa-custom.yaml &&kubeclt create -f podinfo-hpa-custom.yaml


--- apiVersion: autoscaling/v2beta1 kind: HorizontalPodAutoscaler metadata: name: podinfo spec: scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: podinfo minReplicas: 2 maxReplicas: 10 metrics: - type: Pods pods: metricName: memory_usage_bytes


targetAverageValue: 10485760 horizontalpodautoscaler.autoscaling "podinfo" created

4. apache ab アプリケーションを使⽤して、負荷をシミュレートします。このアプリケーションは、⾃動スケーリング・ワークロードをトリガーします。

for a in `seq 1 50`; do ab -rSqd -c 200 -n 20000 <node_ip>:31198/;done

ここで <node_ip> は、IBM Cloud Private クラスター内のノードの IP アドレスです。

containerd を使⽤した IBM® Cloud Private のインストール

cri は、Kubernetes コンテナー・ランタイム・インターフェース (CRI) によって使⽤される containerd プラグインの実装です。 cri では、コンテナー・ランタイムとして containerd を使⽤して Kubernetes を実⾏できます。

すべてのクラスター・ノードへの cri-containerd のインストールクラスター・ノードのセットアップ

始める前に

containerd を使⽤した IBM Cloud Private のインストールは、Linux® 64-bit 上で実⾏されている Ubuntu 16.04LTS オペレーティング・システムでのみサポートされます。この⼿順を実⾏する前に、IBM Cloud Private のご使⽤のエディションのインストール資料のブート・ノードのみでの Docker のインストール、インストール環境のセットアップ、および(オプション) クラスターのカスタマイズの各セクションを完了する必要があります。

IBM Cloud Private クラウド・ネイティブ環境のインストールIBM Cloud Private エンタープライズ環境のインストールIBM® Cloud Private-CE のインストール

すべてのクラスター・ノードへの cri-containerd のインストール

1. icp-containerd-binaries-1.0.0_x86_64.bin パッケージをダウンロードします。このパッケージはIBM® パスポート・アドバンテージ Web サイトから⼊⼿できます。

2. すべてのクラスター・ノードで、cri-containerd をインストールします。

sudo ./icp-containerd-binaries-1.0.0_x86_64.bin --install

3. インストールを検証します。

systemctl status containerd

クラスター・ノードのセットアップ

1. ブート・ノードで、以下のイメージをプルします。

docker pull ibmcom/hyperkube:v1.10.0-ee docker pull ibmcom/etcd:v3.2.14 docker pull ibmcom/pause:3.0 docker pull ibmcom/mariadb:10.2.14

2. ブート・ノードで、イメージをローカル・ファイル・システムに保存します。

docker save ibmcom/hyperkube:v1.10.0-ee -o hyperkube.tar docker save ibmcom/etcd:v3.2.14 -o etcd.tar


https://www-01.ibm.com/software/passportadvantage/

docker save ibmcom/pause:3.0 -o pause.tar docker save ibmcom/mariadb:10.2.14 -o mariadb.tar

3. イメージ・パッケージをすべてのクラスター・ノードにコピーします。

4. すべてのクラスター・ノードで、ctr cri loadコマンドを実⾏してイメージをロードします。

ctr cri load hyper.tar


Loaded image: ibmcom/hyperkube:v1.10.0-ee

ctr cri load etcd.tar


Loaded image: ibmcom/etcd:v3.2.14

ctr cri load pause.tar


Loaded image: ibmcom/pause:3.0

ctr cri load mariadb.tar


Loaded image: ibmcom/mariadb:10.2.14

5. イメージが正常にロードされたことを確認します。

crictl images

IMAGE TAG IMAGE ID SIZE ibmcom/etcd v3.2.14 94bc3af972c98 37.5MB ibmcom/hyperkube v1.10.0-ee 97ec947ff617d 642MB ibmcom/mariadb 10.2.14 3b5159f610ed6 401MB ibmcom/pause 3.0 99e59f495ffaa 753kB

6. <installation_directory>/cluster/config.yaml ファイルを更新します。 container_runtime パラメーターを containerd に変更します。

container_runtime=containerd

7. IBM Cloud Private のご使⽤のエディションのインストール資料の Deploy the environment セクションを続けます。

IBM Cloud Private Cloud ネイティブ環境のインストールIBM Cloud Private エンタープライズ環境のインストールIBM® Cloud Private-CE のインストール

概要

IBM® Cloud Private は、オンプレミスのコンテナー化されたアプリケーションを開発および管理するためのアプリケーション・プラットフォームです。


IBM Cloud Private は、共有マルチテナント環境でのアプリケーションの開発を容易にし、x86 上の Linux® 64-bit とLinux® on Power® (ppc64le) の両⽅のアーキテクチャーをサポートします。

IBM Cloud Private 概要 IBM Cloud Private バンドルアーキテクチャーコンポーネントサポートされる⾔語

IBM® Cloud Private の概要

IBM Cloud Private は、オンプレミスのコンテナー化されたアプリケーションを開発および管理するためのアプリケーション・プラットフォームです。これは、コンテナー・オーケストレーターの Kubernetes、プライベート・イメージ・レジストリー、management console、およびモニターのフレームワークが含まれたコンテナーを管理するための統合環境です。

IBM Cloud Private は、エンタープライズ向けのお客様が管理するコンテナー・ソリューションを提供します。また、コミュニティー・エディション IBM® Cloud Private-CE としてもご利⽤いただけます。その場合、テスト環境に最適な、無料で使⽤可能な制限されたオファリングが提供されます。

IBM Cloud Private の使⽤で得られるエクスペリエンスを最良のものにするためには、Kubernetes、Docker、およびHelm の仕組みを理解する必要があります。これらのオープン・ソースのコンポーネントは、IBM Cloud Private プラットフォームの基礎となっています。 Kubernetes デプロイメントを使⽤して、Docker イメージを参照する Helm チャートにビルドされたアプリケーションのインスタンスを配置します。 Helm チャートには、アプリケーションに関する詳細が含まれます。Docker イメージには、アプリケーションの実⾏に必要なすべてのソフトウェア・パッケージが含まれます。これらのコンポーネントの詳細については、各コンポーネントの以下の資料を参照してください。

Helm 資料 Docker 資料の Get Started, Part 1: Orientation and setup Kubernetes 資料の Kubernetes Basics

IBM Cloud Private バージョン 2.1.0.3には、以下のフィーチャーおよび機能が含まれています。

統合インストーラー

Ansible ベースのインストーラーを使⽤して、マスター、ワーカー、プロキシーの各ノード、およびオプションの管理ノードと脆弱性アドバイザー・ノードが含まれた Kubernetes ベースのクラスターを迅速にセットアップします。この Ansible ベースのインストーラーは、⾼速かつ使いやすくなっています。単⼀のブート・ノードからいくつかのシンプルなコマンドを実⾏すると、数分でクラスターが稼働状態になります。

IBM Cloud Private management console

⼀元化された単⼀のセキュアな management console から、アプリケーションおよびクラスターを管理、モニター、およびトラブルシューティングします。

プライベート Docker イメージ・レジストリー

プライベート Docker レジストリーが Docker レジストリー V2 API と統合されており、クラウド・ベースのレジストリー・サービスである Docker Hub と同じように機能するローカル・レジストリー・サービスが提供されます。このローカル・レジストリーは、Docker Hub と同じ機能をすべて備えていますが、このレジストリーのイメージを表⽰またはプルできるユーザーを制限することもできます。

コンテナー化されたソフトウェアおよびサービスの Catalog32 IBM Cloud Private 2.1.0.3

https://docs.helm.sh/

https://docs.docker.com/get-started/

https://kubernetes.io/docs/tutorials/kubernetes-basics/

Catalog は、クラスター内のパッケージを参照およびインストールできる、⼀元化された場所を提供します。

追加の IBM 製品のパッケージが、デフォルトの IBM Cloud Private リポジトリー・リストに含まれている、キュレーションされたリポジトリーから使⽤可能です。ご使⽤の環境は、該当するパッケージのチャートにアクセスできるように、インターネットに接続されている必要があります。すべての IBM Cloud Private チャートのリストを表⽰するには、https://github.com/IBM/charts/tree/master/stable を参照してください。

Kubernetes ネイティブ・パッケージ管理システムである Helm が、IBM Cloud Private クラスター内のアプリケーション管理に使⽤されます。 Helm GitHub コミュニティーによって、テスト済みの事前構成された Kubernetes アプリケーションのセットがキュレーションされ、継続的に拡張されています。 management console から、安定したアプリケーションで構成されるこのカタログにある項⽬をクラスターに追加できます。この Helm コミュニティー・カタログをインストールすると、クラスターにデプロイする準備ができた 80 以上の追加の Kubernetes アプリケーションが提供されます。 Helm リポジトリーで使⽤可能なすべての安定したアプリケーションのリストを表⽰するには、https://github.com/kubernetes/charts/tree/master/stable を参照してください。

分離されたテナント・ネットワーク

Calico により、クラスター内でパフォーマンスおよびネットワークの分離性を改善させることができます。 Calico では、クラスター内のプロジェクトごとに分離したサブネットを作成できます。このネットワークの分離により、データ伝送時に追加のセキュリティーが得られ、アプリケーションおよびそのデータの漏えいの可能性が低減します。同じ物理マシンまたは仮想マシンで実⾏されているアプリケーションが複数存在している環境では、ネットワークの分

離が特に重要になります。

また、Calico により、単⼀の名前空間内におけるオブジェクトの共有を微細に制御できるようにする新規ネットワーク・ポリシーの作成が容易になります。

ELK スタックを使⽤した堅固なモニターおよびロギング

IBM Cloud Private は、ログおよびメトリックの収集、保管、および照会に Elasticsearch、Logstash、Filebeat、および Heapster を使⽤します。このモニターおよびロギング・プロセスでは、すべてのログおよびメトリックに対して⼀元化されたストアが提供され、パフォーマンスが向上し、ログおよびメトリックへのアクセスおよび照会時の安定

度が増します。

Elasticsearch データベース内のデータを照会するために、Kibana または Grafana をインストールすることもできます。そうした照会の結果を使⽤して、洞察に富んだグラフおよびレポートを作成できます。

IBM® Cloud Private バンドル

IBM Cloud Private は、IBM ミドルウェアやその他のソフトウェア製品など、他の IBM 製品とともに購⼊可能です。

すべての IBM Cloud Private バンドルには、コア IBM Cloud Private プラットフォーム、およびCatalogを介してアクセスできる無料で使⽤可能なフィーチャー・アプリケーションが含まれています。各バンドルには、さまざまなライセンスのソフトウェアが含まれています。これらのソフトウェアは別途インストールしたり、 IBM Cloud Private プラットフォームのインストール後にCatalogに追加したりすることができます。

IBM Cloud Private Cloud Native

表 1. IBM Cloud Private Cloud Native コンポーネント

ソフトウェ

ア説明

インス

トール

⽅法


https://github.com/IBM/charts/tree/master/stable

https://github.com/kubernetes/charts/tree/master/stable

ソフトウェ

ア説明

インス

トール

⽅法

CloudAutomationManager

IBM Cloud Automation Manager は、複数のクラウドでクラウド・インフラストラクチャーをデプロイするための、 IBM Cloud Private のクラウド管理ソリューションであり、ユーザー・エクスペリエンスが最適化されています。

個別イ

ンスト

ーラー

IBMWebSphereApplicationServerLiberty

IBM WebSphere Application Server Liberty を、IBM Cloud Private のコンテンツ・Catalog内で使⽤可能な豊富な種類のミドルウェア・テクノロジーと組み合わせることで、データベース、

キャッシュ・ソリューション、メッセージング・ソリューションなど、ミドルウェアを統合する

ために必要な統合の量が減ります。

Catalogを介して使

⽤可能

Microservice Builder

Microservice Builder は、最新のアプリケーションを開発およびデプロイするためのエンドツーエンドのユーザー・エクスペリエンスを提供し、IBM Cloud Private でデフォルトで利⽤可能です。 Microservice Builder は、コンテナー化されたアプリケーションのデプロイメントおよび管理の第⼀級のエクスペリエンスを提供します。

Catalogを介して使

⽤可能

IBM Cloud Private Enterprise

表 2. IBM Cloud Private Enterprise コンポーネント

ソフトウェア説明インストー

ル⽅法

CloudAutomationManager

IBM Cloud Automation Manager は、複数のクラウドでクラウド・インフラストラクチャーをデプロイするための、 IBM Cloud Private のクラウド管理ソリューションであり、ユーザー・エクスペリエンスが最適化されています。

個別インス

トーラー

IBM APIConnectProfessional

IBM API Connect Professional は、作成から管理に⾄る API ライフサイクル全体を管理するための包括的なソリューションを提供します。

個別インス

トーラー

IBM MQAdvanced

IBM MQ Advanced は、オンプレミス環境とクラウド・デプロイメントの両⽅を含め、プラットフォーム内および複数のプラットフォーム間でアプリケーション、システム、お

よびサービスを接続して統合するためのシンプル、セキュア、スケーラブルで信頼性の

⾼いメッセージングを提供する堅固なメッセージング・ミドルウェア・ソリューション

です。

個別

イン

スト

ーラ

ー

Catalogに追加

した

Helmチャ

ート

を介

して

IBMWebSphereApplicationServerLiberty

IBM WebSphere Application Server Liberty を、IBM Cloud Private のコンテンツ・Catalog内で使⽤可能な豊富な種類のミドルウェア・テクノロジーと組み合わせることで、データベース、キャッシュ・ソリューション、メッセージング・ソリューションな

ど、ミドルウェアを統合するために必要な統合の量が減ります。

Catalogを介して使⽤可

能


https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0.0/mapfiles/getting_started.html

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.helphome.v90.doc/WelcomePagev9r0.htm

ソフトウェア説明インストー

ル⽅法

IBMWebSphereApplicationServerNetworkDeployment

IBM WebSphere Application Server Network Deployment は、⼤規模アプリケーション・デプロイメント⽤の⾼度で柔軟なランタイム環境を提供します。基幹業務アプリケーション⽤の⾼度なパフォーマンスおよび管理の機能によって、ほぼ中断のない可⽤性を提

供します。

個別インス

トーラー

MicroserviceBuilder

Microservice Builder は、最新のアプリケーションを開発およびデプロイするためのエンドツーエンドのユーザー・エクスペリエンスを提供し、IBM Cloud Private でデフォルトで利⽤可能です。 Microservice Builder は、コンテナー化されたアプリケーションのデプロイメントおよび管理の第⼀級のエクスペリエンスを提供します。

Catalogを介して使⽤可

能

オプション・コンポーネント

以下のコンポーネントをバンドルに追加することもできます。 IBM 営業担当員にお問い合わせください。

表 3. オプション・コンポーネントソフト

ウェア説明

インストー

ル⽅法

IBM®CloudPrivateCloudFoundry

IBM® Cloud Private Cloud Foundry プラットフォームは、IBM Cloud および IBM CloudDedicated で利⽤できるのと同じレベルの Cloud Foundry アプリケーション機能をデータ・センターにもたらします。これは、VMware vSphere で実⾏できます。

個別インス

トーラー

DataScienceExperienceLocal

IBM Data Science Experience (DSX) Local は、データ・サイエンティストおよびデータ・エンジニア向けのオンプレミスのエンタープライズ・ソリューションです。専有の IBM テクノロジーと統合されたデータ・サイエンス・ツールのスイートを提供します。

Catalogに追加した

Helm チャートを介し

て


https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/welcome_nd.html

https://datascience.ibm.com/docs/content/local/welcome.html

ソフト

ウェア説明

インストー

ル⽅法

IBMDB2DirectAdvanced

IBM DB2 Direct Advanced は、デジタル、クラウド、およびコグニティブの時代におけるトランザクション・ワークロードおよび分析ワークロード⽤の変換データ・プラットフォームで

す。データの継続的可⽤性を提供し、トランザクション操作および分析操作の最⼤の効率性を保つことで、データへのアクセスが、計画されたダウン時間や計画外のダウン時間によって影

響されないようにします。

個別

イン

スト

ーラ

ー

Catalogに追

加し

た

Helm チャー

トを

介し

て

CloudAutomationManagerを使

⽤し

て

IBMUrbanCodeDeploy

IBM UrbanCode Deploy は、堅固な可視性、追跡可能性、監査の機能を組み合わせたアプリケーション・リリース⾃動化ソリューションです。コンテナーでの IBM UrbanCode Deploy の使⽤について詳しくは、Getting Started with IBM UrbanCode Deploy and Containers を参照してください。

個別インス

トーラー

アーキテクチャー

IBM® Cloud Private クラスターには、4 つの主要なノード・クラス (ブート、マスター、ワーカー、およびプロキシー) があります。

オプションで、クラスター内に管理ノード、脆弱性アドバイザー (VA) ノード、および etcd ノードを指定できます。

IBM Cloud Private クラスターのアーキテクチャーを決定してからインストールします。インストール後には、クラスターでワーカー、プロキシー、管理、および VA の各ノードの追加と削除ができるだけです。標準クラスターを⾼可⽤性クラスターに変換したり、⾼可⽤性クラスターにマスター・ノードを追加したりすることはできません。

重要: クラスター内のブート、マスター、プロキシー、VA、etcd、および管理の各ノードは、同じプラットフォーム・アーキテクチャーを使⽤しなければなりません。異なるプラットフォーム・アーキテクチャーを使⽤できるのは、ワーカー・ノードのみです。例えば、Linux® on Power® (ppc64le) ノードをマスター・ノードとして使⽤する予定の場合、Linux® on Power® (ppc64le) ブート・ノードを使⽤します。

ブート・ノード

マスター・ノード

ワーカー・ノード


https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.licensing.doc/doc/c0070181.html

https://www.ibm.com/support/knowledgecenter/en/SS4GSP_6.2.6/com.ibm.udeploy.doc/ucd_version_welcome.html

https://developer.ibm.com/urbancode/docs/getting-started-ibm-urbancode-deploy-containers/

プロキシー・ノード

管理ノード

VA ノードetcd ノード

ブート・ノード

ブート (ブートストラップ) ノードは、インストール、構成、ノード・スケーリング、およびクラスター更新の実⾏に使⽤されます。どのクラスターでも、必要になるブート・ノードの数は 1 つのみです。単⼀のノードをマスターとブートの両⽅として使⽤できます。

単⼀のブート・ノードを複数のクラスターで使⽤できます。その場合、ブートとマスターを単⼀のノードに割り当てることはできません。クラスターごとに独⾃のマスター・ノードが必要です。ブート・ノードでは、クラスターごとに別個のインストール・ディレクトリーが必要です。認証⽤に独⾃の認証局 (CA) を指定する場合、クラスターごとに別個の CA ドメインが必要です。

マスター・ノード

マスター・ノードは、管理サービスを提供し、クラスター内のワーカー・ノードを制御します。マスター・ノードは、リソース割り振り、状態維持、スケジューリング、およびモニターを処理するプロセスをホストします。⾼可⽤性 (HA) 環境には複数のマスター・ノードが含まれているため、先導マスター・ノードで障害が発⽣した場合、フェイルオーバー・ロジックによって、別のノードがマスター役割に⾃動的にプロモートされます。マスターの役割を果たすことができるホストは、マスター候補と呼ばれます。

ワーカー・ノード

ワーカー・ノードは、タスクを実⾏するためのコンテナー化された環境を提供するノードです。要求の増加に伴い、ワーカー・ノードをクラスターに簡単に追加して、パフォーマンスおよび効率性を向上させることができます。 1 つのクラスターには任意の数のワーカー・ノードを含めることができますが、少なくとも 1 つのワーカー・ノードが必要です。

プロキシー・ノード

プロキシー・ノードは、クラスター内で作成されたサービスに外部要求を送信するノードです。⾼可⽤性 (HA) 環境には複数のプロキシー・ノードが含まれているため、先導プロキシー・ノードで障害が発⽣した場合、フェイルオー

バー・ロジックによって、別のノードがプロキシー役割に⾃動的にプロモートされます。単⼀のノードをマスターとプロキシーの両⽅として使⽤できますが、専⽤のプロキシー・ノードを使⽤してマスター・ノードの負荷を軽減する

のが最良です。クラスター内でロード・バランシングが必要な場合、1 つのクラスターには、少なくとも 1 つのプロキシー・ノードが含まれている必要があります。

クラスターでこのノード・タイプを使⽤する場合、アーキテクチャーは、以下の図のようになります。


管理ノード

管理ノードは、モニター、計量、ロギングなどの管理サービスのみをホストするオプション・ノードです。専⽤の管理ノードを構成することで、マスター・ノードが過負荷状態にならないようにすることができます。管理ノードを有効にできるのは、IBM Cloud Private のインストール時のみです。

クラスターで管理ノードを使⽤する場合、アーキテクチャーは、以下の図のようになります。


VA ノード

VA (脆弱性アドバイザー) ノードは、脆弱性アドバイザー・サービスの実⾏に使⽤するオプション・ノードです。脆弱性アドバイザー・サービスは、リソースを⼤量に使⽤します。脆弱性アドバイザー・サービスを使⽤する場合は、専⽤の VA ノードを指定してください。脆弱性アドバイザーについて詳しくは、『脆弱性アドバイザー』を参照してください。

クラスターで VA ノードを使⽤する場合、アーキテクチャーは、以下の図のようになります。

etcd ノード

etcd ノードは、etcd 分散キー値ストアの実⾏に使⽤するオプション・ノードです。 100 個以上などの多数のノードがある IBM Cloud Private クラスター内に etcd ノードを構成すると、etcd のパフォーマンス改善に役⽴ちます。etcd ノードの構成について詳しくは、hosts ファイルでのノード役割の設定を参照してください。

IBM® Cloud Private コンポーネント

IBM Cloud Private には、2 つのメイン・コンポーネントがあり、それはコンテナー・マネージャー (Docker) とコンテナー・オーケストレーター (Kubernetes) です。

IBM Cloud Private クラスターの他のコンポーネントは、これらのメイン・コンポーネントとともに動作し、認証、ストレージ、ネットワーキング、ロギング、モニターなどのサービスを提供します。クラスター managementconsole も⽤意されており、これはこれらのサービスの⼀元化された管理の場所の役割を果たします。

アーキテクチャー・モデルおよびノード・タイプについて詳しくは、『アーキテクチャー』を参照してください。


注: モニター、計量、ロギングなどの管理コンポーネントは、管理ノードで実⾏されます。クラスター内に管理ノードが存在しない場合、管理コンポーネントはマスター・ノードで実⾏されます。


表 1. IBM Cloud Private ノード・コンポーネントコンポーネ

ント

バージ

ョン

ロケーショ

ン役割

アラート・

マネージャ

ー

0.13.0 単⼀の管理

ノード

Prometheus サーバーによって送信されたアラートを処理します。重複排除、グループ化、正しい受信側統合 (slack、E メール、PagerDuty など) へのルーティングを⾏います。

Ansible ベースのイン

ストーラー

および opsマネージャ

ー

2.5.0 ブート・ノ

ード

マスター・ノードおよびワーカー・ノードに IBM Cloud Private をデプロイします。ブート・ノードは、オンデマンドでクラスターのサイズをスケーリングするため、およびローリング更新を実⾏するためにも使⽤されます。

認証マネー

ジャー

2.1.0.3 各マスタ

ー・ノード

ユーザーを管理するための HTTP API を提供します。プロトコルは、RESTful ⽅式で実装されます。 OpenID Connect が認証に使⽤されます。

calico/node 3.0.4 ブート・ノ

ードを除く

すべてのノ

ード。

各ノードで Calico ネットワーク構成を設定します。 Calico コンポーネントについて詳しくは、https://docs.projectcalico.org/v2.6/releases/ を参照してください。

calicoctl 2.0.2 各マスタ

ー・ノード

全体的な Calico 構成をセットアップするために Kubernetes ジョブとして実⾏されるクライアント・ツール。

calico/cni 2.0.3 ブート・ノ

ードを除く

すべてのノ

ード。

各ノードでネットワーク CNI プラグインを設定します。

calico/kube-policy-controller

2.0.2 各マスタ

ー・ノード

IBM Cloud Private クラスターでネットワーク・ポリシーを設定するコントローラー・センター。

DockerRegistry

2 各マスタ

ー・ノード

イメージ・リポジトリーにコンテナー・イメージ・ファイルを保管するために使

⽤されるプライベート・イメージ・レジストリー。 Docker ディストリビューションおよびレジストリーのバージョンは API V2 です。

デフォル

ト・バック

エンド

1.2 単⼀マスタ

ー・ノード

クラスター内のサービスへのインバウンド接続のルーティングを⽀援する

Ingress コントローラーのマイナー・コンポーネント。

Elasticsearch

5.5.1 単⼀の管理

ノード

システムおよびアプリケーションのログとメトリックを保管します。

Elasticsearch は、それらのログおよびメトリックを照会するために使⽤できる⾼度な API も提供します。

etcd 3.2.14 各マスタ

ー・ノード

構成データを保持する、分散したキーと値のストア。

Filebeat 5.5.1 ブート・ノ

ードを除く

すべてのノ

ード。

すべてのシステム・コンポーネント、および各ノードで実⾏されているユーザ

ー・アプリケーション・コンテナーのログを収集します。


https://docs.projectcalico.org/v2.6/releases/

コンポーネ

ント

バージ

ョン

ロケーショ

ン役割

フェデレー

ション・コ

ンポーネン

ト

coredns(1.0.3)Kubefed(1.8.3)opa(0.5.13)opa_kube_mgmt(0.4)

単⼀の管理

ノード

複数クラスター環境でクラスターのディスカバリーおよび管理を容易にします。

GlusterFS 3.12.1 選択された

ワーカー・

ノード

ストレージ・ファイル・システム。


コンポーネ

ント

バージ

ョン

ロケーショ

ン役割

Grafana 4.6.3 単⼀の管理

ノード

データ可視化およびモニター機能。データ・ソースとして Prometheus がサポートされます。

Heapster 1.4.0 単⼀マスタ

ー・ノード

各ワーカー・ノードで実⾏されている kubelet に接続し、ノードおよびコンテナーのメトリックを収集します。該当するメトリックには、CPU、メモリー、およびネットワークの使⽤量があります。

Heketi 5.0.0 任意のワー

カー・ノー

ド上でポッ

ドとして実

⾏されま

す。

GlusterFS を管理するための CLI。

Helm(Tiller)

2.7.2 単⼀マスタ

ー・ノード

Kubernetes チャート (パッケージ) を管理します。

IBM CloudPrivatemanagement console

2.1.0.3 各マスタ

ー・ノード

Open DC/OS GUI に基づいた Web ポータル。この management console は、VIP マネージャーによって提供されている仮想 IP (VIP) を使⽤して、先導マスター・ノードに接続します。

イメージ・

マネージャ

ー

2.1.0.3 各マスタ

ー・ノード

Docker レジストリーに拡張機能を提供して、イメージを管理します。この機能には、プッシュ、プル、および削除の各操作のための許可があります。イメージ・マネージャーは、イメージ・ライブラリーのカタログのための許可も提供し

ます。

Indices-cleaner

0.2 単⼀の管理

ノード

Elasticsearch データをクリーンアップします。

Kibana 5.5.1 単⼀の管理

ノード

Elasticsearch に保管されているデータに簡単にアクセスできるようにし、またそのデータの視覚化およびダッシュボードを作成する機能を備えた UI。

Kubelet 1.10.0 ブート・ノ

ードを除く

すべてのノ

ード。

クラスターのシステム・コンポーネントを監視します。

Kube-dnskubedns_dnsmasqkubedns_sidecar

1.14.4 すべてのマ

スター・ノ

ード

Kubernetes アプリケーションのサービス・ディスカバリーを提供します。

KubernetesAPI サーバー

1.10.0 各マスタ

ー・ノード

Kubernetes オブジェクトのデータを検証および構成するための REST API を提供します。該当する Kubernetes オブジェクトには、ポッド、サービス、複製コントローラーがあります。

Kubernetesコントロー

ル・マネー

ジャー

1.10.0 各マスタ

ー・ノード

現在の状態をモニターおよび調整することで、Kubernetes クラスターの共有状態を維持し、必要なサービス標準が有効になっている状態を保ちます。この維持は、km apiserver を介して実⾏されます。


コンポーネ

ント

バージ

ョン

ロケーショ

ン役割

Kubernetespause

3.0 ブート・ノ

ードを除く

すべてのノ

ード。

ポッドの IP アドレスを保管し、ポッドに参加する他のコンテナーのネットワーク名前空間をセットアップします。

Kubernetesプロキシー

1.10.0 ブート・ノ

ードを除く

すべてのノ

ード。

Kubernetes サービス宛てのトラフィックを受け取り、適切なポッドに転送します。 Kubernetes プロキシーは、km minion によって開始されます。

Kubernetesスケジュー

ラー

1.10.0 各マスタ

ー・ノード

スケジューリング・ポリシーに基づいて、ポッドをワーカー・ノードに割り当て

ます。

kube_state_metrics

1.2.0 単⼀の管理

ノード

Kubernetes API サーバーと通信して、Kubernetes オブジェクトの状態に関するメトリックを⽣成します。

Logstash 5.5.1 単⼀の管理

ノード

Filebeat によって収集されたログを変換して Elasticsearch に転送します。

mariaDB 10.1.16 各マスター・ノード

OIDC によって使⽤されるデータベース。

計量コンポ

ーネント

計量

サー

バー

計量

リー

ダー

2.1.0.3 計量

サー

バー

(単⼀の管

理ノ

ード)計量

リー

ダー

(ブート・

ノー

ドを

除く

すべ

ての

ノー

ド)

アプリケーションおよびクラスターの使⽤量メトリックを収集します。

MongoDB 3.6 各マスタ

ー・ノード

計量サービス (IBM® Cloud Product Insights)、Helm リポジトリー・サーバー、および Helm API サーバーによって使⽤されるデータベース。

OpenIDConnect(OIDC)

1.0 各マスタ

ー・ノード

OAuth 2.0 を介した ID プロトコル。 Websphere Liberty プロファイルが OIDC プロバイダーとして使⽤されます。 Liberty プロファイルは、既存のエンタープライズ LDAP サーバーと統合するように構成できます。

Prometheus コンポーネント

Prometheu

単⼀の管理

ノード

指定間隔で構成されているターゲットからメトリックを収集し、ルール式を評価

し、結果を表⽰します。条件が真であると判定された場合、アラートをトリガー

できます。


コンポーネ

ント

バージ

ョン

ロケーショ

ン役割

s(2.0.0)collectd_exporter(0.3.1)node_exporter(0.15.2)configmap_relo


コンポーネ

ント

バージ

ョン

ロケーショ

ン役割

ad(0.1)elasticsearch-exporter(1.0.2)kube-state-metrics-exporter(1.2.0)


コンポーネ

ント

バージ

ョン

ロケーショ

ン役割

rescheduler 0.5.2 各マスタ

ー・ノード

クラスター内のポッド管理に使⽤されます。 rescheduler は、クラスター内のポッドのレイアウトを最適化するために、実⾏中のポッドをプロアクティブに再配

置するエージェントです。Kubernetes rescheduler について詳しくは、https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduler.md を参照してください。

ルーター 2.1.0.3 各マスタ

ー・ノード

management console をホストし、すべてのシステム・コンポーネント API のリバース・プロキシーの役割を果たします。

サービス・

カタログ

0.1.2 各マスタ

ー・ノード

Open Service Broker API を実装して、IBM Cloud Private のサービス・ブローカー統合を提供します。

UCarp 1.5.2 各マスタ

ー・ノード

およびプロ

キシー・ノ

ード

マスター・ノードで仮想 IP (VIP) を管理するために使⽤されます。このコンポーネントは、クラスターにおける⾼可⽤性 (HA) の維持に役⽴ちます。 UCarp を使⽤するには、HA マスター環境を開始する必要があります。

統合ルータ

ー

2.1.0.3 単⼀マスタ

ー・ノード

IBM Cloud Private management console のバックエンド機能をサポートするために使⽤されます。

vip_manager

1.0 マスター・

ノードおよ

びプロキシ

ー・ノード

NGINXIngress コントローラ

ー

0.13.0 各プロキシ

ー・ノード

NodePort Kubernetes サービスのロード・バランシングに使⽤されます。

脆弱性アドバイザー (VA) コンポーネント (オプション・フィーチャー)

表 2. 脆弱性アドバイザー・ノード・コンポーネント


バ

ー

ジ

ョ

ン

ロ

ケ

ー

シ

ョ

ン

役割

Kafka 0.10.0.1

VAノ

ー

ド

データの取り込みおよびキュレーションに使⽤されるデータ・パイプライン・コンポーネ

ント。

SecurityAnalyticsService (SAS)コンポーネント

SAS APIサーバー

SASManagement サーバー

1.2.1

VAノ

ー

ド

脆弱性アドバイザー・フロントエンド・サービス・コンポーネント。 SAS コンポーネントは、脆弱性アドバイザー・クローラーおよび脆弱性アドバイザー・ダッシュボードの

RESTful API を提供します。

クローラーは、SAS API を使⽤して、スキャンされたコンテナーおよびイメージの情報 (フレームと呼ばれる) を脆弱性アドバイザー・データ・パイプラインに出⼒します。

脆弱性アドバイザー・ダッシュボードも SAS API を使⽤して、脆弱性アドバイザーの知⾒を報告します。


https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduler.md


バ

ー

ジ

ョ

ン

ロ

ケ

ー

シ

ョ

ン

役割

Statsd 0.7.2

VAノ

ー

ド

脆弱性アドバイザー・サービスが内部システム・モニターに使⽤します。

VAElasticsearch

5.5.1

VAノ

ー

ド

脆弱性アドバイザー・データおよび分析アノテーションの索引付けおよび照会に使⽤され

るデータ・パイプライン・コンポーネント。

VAElasticsearchcurator

5.4.1

VAノ

ー

ド

脆弱性アドバイザーの索引サイズの管理および古い索引の除去に使⽤される Elasticsearchcurator。 VA Elasticsearch curator は、CronJob としてデプロイされます。

VA アノテーター

VACompliance アノテーター

VAConfig パーサー

VAPassword アノテーター

VARootkitアノテー

ター

VAVulnerability アノテーター

1.2.1

VAノ

ー

ド

脆弱性分析、コンプライアンス・チェック、パスワード分析、構成分析、ルートキット検

出などの各種分析を使⽤して、スキャンされたコンテナーおよびイメージのデータのセキ

ュリティーを向上させる脆弱性アドバイザー・データ・パイプライン・コンポーネント。

これらのアノテーターは、内部および外部のセキュリティーとコンプライアンスの情報を

使⽤して、コンテナーおよびイメージのセキュリティーを向上させます。

VA インデクサー

VAConfig インデクサ

ー

VAGenericインデク

サー

1.2.1

VAノ

ー

ド

脆弱性アドバイザー・バックエンドへの脆弱性アドバイザーの知⾒の索引付けに使⽤され

るデータ・パイプライン・コンポーネント。



バ

ー

ジ

ョ

ン

ロ

ケ

ー

シ

ョ

ン

役割

VA Liveスキャ

ン・プロ

キシー

VANotification ディスパッチ

ャー

1.2.1

VAノ

ー

ド

API およびトリガーに使⽤されるデータ・パイプライン・コンポーネント。

VA Usncrawler 1.2.1

VAノ

ー

ド

脆弱性アドバイザー分析コンポーネントの外部セキュリティー通知を取り込んで集約する

ために使⽤されるデータ・パイプライン・コンポーネント。

VA クローラー 1.2.1

VAノ

ー

ド

実⾏中のコンテナーおよびオフラインのイメージを検査する脆弱性アドバイザー・デー

タ・コレクター (クローラーとも呼ばれる)。

これらのクローラーは、すべての脆弱性アドバイザー分析コンポーネントが使⽤するシス

テムおよびアプリケーションの情報を抽出します。

ライブ・クローラーおよびメトリック・クローラーは、ワーカー・ノードで実⾏され、

DaemonSets としてデプロイされます。

レジストリー・クローラーは、別個のデプロイメントとして実⾏され、IBM Cloud Privateイメージ・レジストリーにデプロイされたイメージをスキャンします。

Zookeeper 3.4.9

VAノ

ー

ド

脆弱性アドバイザーの kafka コンポーネントによって使⽤されます。

GDPR 対応に向けた IBM® Cloud Private プラットフォームの考慮事項

特記事項

この資料は、GDPR 対応に向けた準備に役⽴てるためのものです。組織で GDPR に対応できるようにするために考慮する必要がある、構成可能な IBM Cloud Private プラットフォームの機能および製品使⽤のいくつかの側⾯に関する情報を⽰します。お客様が機能を選択および構成できる⽅法が多岐にわたっており、また製品を単体で、あるいはサード・パーティーのアプリケーションおよびシステムとともにさまざまな⽅法で使⽤できるため、この情報はすべて

を網羅したリストではありません。

EU ⼀般データ保護規則 (GDPR) などの各種法規の遵守を保証するのはお客様の責任とさせていただきます。お客様のビジネスに影響を与える可能性がある関連法規の確認と解釈、並びにかかる法規を遵守するためにお客様がとる必

要のある措置に関して、弁護⼠の適切な助⾔を得ることはお客様のみにかかわる責任とさせていただきます。


ここに記載されている製品、サービス、およびその他の機能は、すべてのお客様の環境に適合するとは限らず、使⽤

可能性が制限されることがあります。 IBM は法律上、会計上、または監査上の助⾔を提供することはいたしません。また、IBM のサービスまたは製品が、お客様がいかなる法規も遵守されていることの裏付けとなると表明するものでも、保証するものでもありません。

⽬次

GDPRGDPR の製品構成データ・ライフサイクル

データ収集

データ・ストレージ

データ・アクセス

データ処理

データ削除

データ・モニター

個⼈データの使⽤を制限するための機能

付録

GDPR

⼀般データ保護規則 (GDPR) は、欧州連合 (EU) によって採択され、2018 年 5 ⽉ 25 ⽇から適⽤されています。

GDPR が重要である理由

GDPR では、個⼈データを処理するための、より強⼒なデータ保護規制フレームワークを規定しています。 GDPR により、以下が⽣じます。

個⼈の新しい権限および強化された権限

個⼈データの定義の拡張

処理者の新しい義務

⾮遵守に対する相当な⾦銭的罰則の可能性

データ・ブリーチ通知の義務

GDPR の詳細に関する資料

EU GDPR 情報ポータル ibm.com/GDPR Web サイト

製品の構成 – GDPR 対応に向けた考慮事項

以下のセクションでは、IBM Cloud Private プラットフォーム内におけるデータ管理のいくつかの側⾯について説明し、GDPR 要件に対応するためにお客様に役⽴つ機能に関する情報を⽰します。

データ・ライフサイクル

IBM Cloud Private は、オンプレミスのコンテナー化されたアプリケーションを開発および管理するためのアプリケーション・プラットフォームです。コンテナー・オーケストレーター Kubernetes、プライベート・イメージ・レジストリー、管理コンソール、およびモニタリング・フレームワークを含むコンテナーを管理する統合環境を提供しま

す。

そのため、IBM Cloud Private プラットフォームでは、プラットフォームの構成および管理に関連した技術データを主に扱いますが、その⼀部は GDPR の対象になる可能性があります。 IBM Cloud Private プラットフォームでは、プ


https://www.eugdpr.org/

https://www.ibm.com/data-responsibility/gdpr/

ラットフォームを管理するユーザーに関する情報も扱います。お客様の責任で GDPR 要件を満たすことが認識されるように、このデータについては、本資料の⾄る所で記載されます。

このデータは、プラットフォームのローカルまたはリモートのファイル・システム上の構成ファイルまたはデータベ

ースで永続化されます。 IBM Cloud Private プラットフォームで実⾏されるように開発されたアプリケーションで、GDPR の対象となる他の形式の個⼈データを扱う可能性があります。プラットフォーム・データの保護および管理に使⽤されるメカニズムは、プラットフォームで実⾏されるアプリケーションにも使⽤可能です。 IBM Cloud Privateプラットフォームで実⾏されるアプリケーションによって収集された個⼈データを管理および保護するために、追加

のメカニズムが必要になることがあります。

IBM Cloud Private プラットフォームおよびそのデータ・フローを理解する最善の⽅法として、Kubernetes、Docker、および Helm の仕組みを把握する必要があります。これらのオープン・ソースのコンポーネントは、IBMCloud Private プラットフォームの基礎となっています。 Kubernetes デプロイメントを使⽤して、Docker イメージを参照する Helm チャートにビルドされたアプリケーションのインスタンスを配置します。 Helm チャートには、アプリケーションに関する詳細が含まれます。Docker イメージには、アプリケーションの実⾏に必要なすべてのソフトウェア・パッケージが含まれます。

IBM Cloud Private には、デフォルトの IBM Cloud Private リポジトリー・リストにある IBM のコンテナー化されたソフトウェアおよびサービスのカタログが含まれます。すべての IBM Cloud Private チャートのリストを表⽰するには、https://github.com/IBM/charts/tree/master/stable を参照してください。カタログ内の製品での GDPR に関する考慮事項については、該当する製品の資料を参照してください。コア IBM Cloud Private プラットフォームおよび使⽤可能なライセンス・ソフトウェアが含まれる、使⽤可能な IBM Cloud Private バンドルに関する情報は、『IBMCloud Private バンドル』にあります。カタログで使⽤可能なアプリケーションの⼀部は、オープン・ソース・ソフトウェアです。オープン・ソース・ソフトウェアに対して適切な GDPR 管理を判別して実装するのは、お客様の責任です。該当するパッケージに関する情報は、カタログ項⽬に含まれています。

IBM Cloud Private プラットフォームに関する資料は、IBM Knowledge Center の IBM Cloud Private コレクションにあります。

IBM Cloud Private プラットフォームをフローするデータのタイプ

プラットフォームとして、IBM Cloud Private は、デフォルト管理者のユーザー ID およびパスワード、サービス・ユーザーの ID およびパスワード、IP アドレス、Kubernetes ノード名など、個⼈データと⾒なされる可能性がある複数のカテゴリーの技術データを扱います。 IBM Cloud Private プラットフォームでは、プラットフォームを管理するユーザーに関する情報も扱います。プラットフォームで実⾏されるアプリケーションにより、プラットフォームでは不明な他のカテゴリーの個⼈データが導⼊されることがあります。

この⽂書の以降のセクションでは、この技術データを収集/作成、保管、アクセス、保護、記録、削除する⽅法に関する情報を⽰します。

IBM とのオンラインでの連絡に使⽤される個⼈データ

IBM Cloud Private のお客様は、IBM Cloud Private の問題について IBM に連絡するために、オンラインによるさまざまな⽅法でコメント/フィードバック/要求を送信することができ、主に以下のようなものがあります。

IBM Cloud Private-CE (Community Edition) Slack のパブリック・コミュニティーIBM Knowledge Center 内の IBM Cloud Private 製品資料のページ上のパブリック・コメント・エリアdWAnswers の IBM Cloud Private スペース内のパブリック・コメント

通常、報告された問題について直接返信できるようにお客様の名前と E メール・アドレスのみが使⽤され、個⼈データの使⽤は、IBM プライバシー・ステートメントに準拠しています。

データ収集


https://github.com/IBM/charts/tree/master/stable

https://www.ibm.com/support/knowledgecenter/ja/SSBS6K_2.1.0.3/getting_started/bundles.html

https://www.ibm.com/privacy/jp/ja/

IBM Cloud Private プラットフォームでは、機密個⼈データを収集しません。デフォルト管理者のユーザー ID およびパスワード、サービス・ユーザーの ID およびパスワード、IP アドレス、Kubernetes ノード名などの技術データを作成および管理し、そうしたデータは個⼈データと⾒なされる可能性があります。 IBM Cloud Private プラットフォームでは、プラットフォームを管理するユーザーに関する情報も扱います。このようなすべての情報にアクセスできるのは、役割ベースのアクセス制御によって管理コンソールを使⽤するシステム管理者、および IBM Cloud Private プラットフォーム・ノードにログインしたシステム管理者のみです。

IBM Cloud Private プラットフォームで実⾏されるアプリケーションは、個⼈データを収集する可能性があります。

コンテナー化されたアプリケーションを実⾏している IBM Cloud Private プラットフォームの使⽤および GDPR の要件を満たす必要性を評価する際には、アプリケーションによって収集される個⼈データのタイプ、および以下のよう

なそのデータの管理⽅法のいくつかの側⾯を考慮する必要があります。

アプリケーションとの間をフローするデータがどのように保護されるか。転送中のデータは暗号化されるか。データがアプリケーションによってどのように保管されるか。保存データは暗号化されるか。アプリケーションへのアクセスに使⽤される資格情報がどのように収集および保管されるか。

アプリケーションがデータ・ソースにアクセスするために使⽤する資格情報がどのように収集および保管され

るか。

必要に応じて、アプリケーションによって収集されたデータがどのように削除されるか。

これは、IBM Cloud Private プラットフォームによって収集されるデータのタイプの完全なリストではありません。考慮するための例として⽰しています。データのタイプについての質問は、IBM にお問い合わせください。


IBM Cloud Private プラットフォームでは、ローカルまたはリモート・ファイル・システム上のステートフル・ストア内に構成ファイルとして、あるいはデータベース内に、プラットフォームの構成および管理に関連した技術データ

を永続化します。すべての保存データの保護について考慮する必要があります。 IBM Cloud Private プラットフォームでは、dm-crypt を使⽤した、ステートフル・ストアでの保存データの暗号化がサポートされます。詳しくは、『dm-crypt を使⽤したボリュームの暗号化』を参照してください。

以下の項⽬では、GDPR のために考慮する必要があるデータの保管領域を取り上げます。

プラットフォーム構成データ: IBM Cloud Private プラットフォーム構成は、⼀般設定、Kubernetes、ログ、ネットワーク、Docker、およびその他の設定⽤のプロパティーが含まれた構成 YAML ファイルを更新することでカスタマイズできます。このデータは、1 つ以上のノードをデプロイするために、IBM Cloud Private プラットフォーム・インストーラーへの⼊⼒として使⽤されます。プロパティーには、ブートストラップに使⽤されるデフォルト管理者のユーザー ID およびパスワードも含まれています。詳しくは、『クラスターのカスタマイズ』を参照してください。

Kubernetes 構成データ: Kubernetes クラスター状態データは、分散キー/値ストアである etcd に保管されます。詳しくは、『コンポーネント』を参照してください。ユーザー認証データ (ユーザー ID およびパスワードを含む): ユーザー ID およびパスワードの管理は、お客様のエンタープライズ LDAP ディレクトリーによって処理されます。 LDAP で定義されているユーザーおよびグループを IBM Cloud Private プラットフォーム・チームに追加し、アクセス役割を割り当てることができます。 IBM Cloud Private プラットフォームは、LDAP からの E メール・アドレスおよびユーザーID を保管しますが、パスワードは保管しません。 IBM Cloud Private プラットフォームはグループ名を保管し、ログイン時に、ユーザーが属している使⽤可能なグループをキャッシュに⼊れます。グループ・メンバーシップが⻑期的に永続化されることはありません。エンタープライズ LDAP で保存されるユーザーおよびグループのデータを保護することを検討する必要があります。また、IBM Cloud Private プラットフォームには、認証サービスOpen ID Connect (OIDC) も含まれており、これはエンタープライズ・ディレクトリーと対話し、アクセス・トークンを保持します。このサービスは、バッキング・ストアとして MariaDB および MongoDB を使⽤します。詳しくは、『LDAP 接続の構成』および『認証』を参照してください。サービス認証データ (ユーザー ID およびパスワードを含む): IBM Cloud Private プラットフォームのコンポーネントでコンポーネント間のアクセスに使⽤される資格情報は、Kubernetes 秘密として定義されます。すべ


ての Kubernetes リソース定義は、etcd キー/値ストアに永続化されます。初期資格情報値は、プラットフォーム構成データに Kubernetes 秘密構成 YAML ファイルとして定義されています。詳しくは、『秘密の管理』を参照してください。

Helm チャート・データ: IBM Cloud Private プラットフォームには、参照して Helm チャートからクラスターにインストールできるコンテナー化されたソフトウェアおよびサービスのカタログが含まれます。 Helm サービスは、MongoDB バッキング・ストアに構成データを永続化します。詳しくは、『チャートおよびアプリケーションの管理』および『コンポーネント』を参照してください。GlusterFS ストレージ・ファイル・システム: クラスターで GlusterFS ストレージを使⽤できます。 GlusterFSストレージがデプロイされたボリュームを暗号化することを検討する必要があります。詳しくは、『GlusterFS』および『dm-crypt を使⽤したボリュームの暗号化』を参照してください。モニター・データ: IBM Cloud Private プラットフォームのモニターを使⽤して、クラスターおよびアプリケーションの状況をモニターできます。このサービスは、Grafana および Prometheus を使⽤して、クラスター・ノードおよびコンテナーに関する詳細情報を提⽰します。アプリケーションのモニターのために、追加のモニター・スタックをデプロイできます。モニター・データは、Kubernetes PersistentVolumes を使⽤して永続化できます。詳しくは、『IBM Cloud Private モニター・サービス』および『IBM Cloud Private クラスター・モニタリング』を参照してください。

計量データ: IBM Cloud Private 計量サービスを使⽤して、アプリケーションおよびクラスターの詳細な使⽤量メトリックを表⽰およびダウンロードできます。計量サービスは、バッキング・データ・ストアとしてMongoDB を使⽤してメトリック・データを永続化します。詳しくは、『IBM Cloud Private 計量サービス』を参照してください。

ロギング・データ: IBM Cloud Private プラットフォームは、システム・ログに ELK スタックを使⽤します。ELK は、Elastic によって構築された Elasticsearch、Logstash、および Kibana という 3 つの製品の略語であり、これらを合わせて、ログのストリーミング、保管、検索、およびモニターに使⽤できる多数のツールが構

成されます。 IBM Cloud Private プラットフォームに付属する ELK スタックは、Elastic が公開している公式のELK スタック・イメージを使⽤しています。 IBM Cloud Private プラットフォーム・サービスのロギングがデフォルトで構成されています。アプリケーションのロギングのために、追加の ELK スタックをデプロイできます。詳しくは、『IBM Cloud Private ロギング』を参照してください。

データ・アクセス

IBM Cloud Private プラットフォームのデータには、以下の定義されている⼀連の製品インターフェースからアクセスできます。

Web ユーザー・インターフェース (管理コンソール)Kubernetes kubectl CLIIBM Cloud Private CLIHelm CLI

これらのインターフェースは、IBM Cloud Private クラスターに対する管理の変更を⾏えるように設計されています。IBM Cloud Private への管理アクセスを保護することができ、このアクセスには、要求を⾏う際に 3 つの順序付けられた論理ステージ (認証、役割マッピング、および許可) があります。

認証

IBM Cloud Private プラットフォーム認証マネージャーは、管理コンソールからユーザー資格情報を受け⼊れ、その資格情報をバックエンドの OIDC プロバイダーに転送します。このプロバイダーは、エンタープライズ・ディレクトリーに対してユーザー資格情報を検証します。次に、OIDC プロバイダーが、JSON Web Token (JWT) の内容が含まれた認証 Cookie (auth-cookie) を認証マネージャーに返します。 JWT トークンは、認証要求時のグループ・メンバーシップに加え、ユーザー ID および E メール・アドレスなどの情報を永続化します。この認証 Cookie はその後、管理コンソールに戻されます。 Cookie はセッション中に更新されます。これは、管理コンソールからサインアウト後、または Web ブラウザーを閉じてから 12 時間有効です。

管理コンソールからのその後のすべての認証要求について、フロントエンド NGINX サーバーは、要求内の使⽤可能な認証 Cookie をデコードして、認証マネージャーを呼び出すことで要求を検証します。


IBM Cloud Private プラットフォーム CLI では、ユーザーはログインするために資格情報を指定する必要があります。

kubectl CLI でも、クラスターにアクセスするために資格情報が必要です。これらの資格情報は、管理コンソールから取得でき、12 時間後に有効期限が切れます。サービス・アカウントを介したアクセスがサポートされます。

Helm CLI のアクセスでは、クラスターにアクセスするために証明書を使⽤します。クライアント証明書には、ユーザー ID や E メール・アドレスなどの個⼈情報が含まれています。これらは、クラスターで MongoDB に保管されます。

役割マッピング

IBM Cloud Private プラットフォームでは、役割ベースのアクセス制御 (RBAC) がサポートされます。役割マッピング・ステージでは、認証ステージで指定されたユーザー名がユーザーまたはグループの役割にマップされます。役割は、認証済みユーザーがどの管理アクティビティーを実⾏できるのかを許可する際に使⽤されます。

許可

IBM Cloud Private プラットフォーム役割は、クラスター構成アクション、カタログおよび Helm リソース、Kubernetes リソースへのアクセスを制御します。クラスター管理者、管理者、オペレーター、エディター、ビューアーなどの複数の IAM (Identity and Access Management) 役割が⽤意されています。役割は、ユーザーまたはユーザー・グループを追加するときに割り当てます。チームによるリソースへのアクセスは、名前空間によって制御できます。

ポッドのセキュリティー

ポッド・セキュリティー・ポリシーを使⽤して、ポッドが実⾏可能な内容や、ポッドがアクセス可能な対象につい

て、クラスター・レベルでの制御をセットアップします。詳しくは、以下を参照してください。

プラットフォームへのアクセスの管理

クラスターへのアクセス

IBM Cloud Private CLI によるクラスターの管理チャートの操作.

データ処理

IBM Cloud Private のユーザーは、構成および管理に関連した技術データをどのように処理および保護するのかをシステム構成によって制御できます。

役割ベースのアクセス制御 (RBAC) により、ユーザーがアクセスできるデータおよび機能を制御します。


て、クラスター・レベルでの制御をセットアップします。

転送中データは、TLS および IPSEC を使⽤して保護されます。 HTTPS (TLS ベース) が、ユーザー・クライアントとバックエンド・サービスとの間のセキュアなデータ転送のために使⽤されます。ユーザーは、インストール時に使⽤するルート証明書を指定できます。すべてのノード間のデータ・トラフィックは、初期状態で、アプリケーションを変更することなく、IPSEC を使⽤して暗号化できます。

保存データの保護は、dm-crypt を使⽤してデータを暗号化することでサポートされます。

ロギング (ELK) およびモニター (Prometheus) のデータ保存期間が構成可能であり、提供されている API を使⽤したデータの削除がサポートされます。

IBM Cloud Private プラットフォームの技術データを管理および保護するために使⽤されるのと同じプラットフォーム・メカニズムを使⽤して、ユーザーが開発したアプリケーションやユーザー提供のアプリケーションの個⼈データ

を管理および保護できます。お客様は、さらなる制御を実装するために独⾃の機能を開発することもできます。


詳しくは、以下を参照してください。


dm-crypt を使⽤したボリュームの暗号化IPsec を使⽤したクラスター・データ・ネットワーク・トラフィックの暗号化IBM Cloud Private サービス⽤の独⾃の認証局 (CA) の指定

データ削除

IBM Cloud Private プラットフォームでは、製品によって作成または収集されたデータを削除するためのコマンド、アプリケーション・プログラミング・インターフェース (API)、およびユーザー・インターフェース・アクションが⽤意されています。これらの機能により、ユーザーは、サービス・ユーザーの ID およびパスワード、IP アドレス、Kubernetes ノード名、その他のすべてのプラットフォーム構成データなどの技術データに加え、プラットフォームを管理しているユーザーに関する情報を削除できます。

データ削除のサポートのために考慮する必要がある IBM Cloud Private プラットフォームの領域:

ロギング・データ (ELK) のデータ保存期間は構成可能です。モニター・データ (Prometheus) のデータ保存期間は構成可能です。ロギング・データは、Elasticsearch API を使⽤して ELK スタックから削除できます。モニター・データは、Prometheus API を使⽤して Prometheus から削除できます。プラットフォーム構成に関連したすべての技術データは、管理コンソールまたは Kubernetes kubectl API を介して削除できます。

アカウント・データ削除のサポートのために考慮する必要がある IBM Cloud Private プラットフォームの領域:

プラットフォーム構成に関連したすべての技術データは、管理コンソールまたは Kubernetes kubectl API を介して削除できます。

エンタープライズ LDAP ディレクトリーを介して管理されるユーザー ID およびパスワードのデータを削除する機能は、IBM Cloud Private プラットフォームとともに使⽤する LDAP 製品で提供されます。

プラットフォームのロギングおよびモニターによって永続化される個⼈データは、クラスター・コンポーネントの

IP アドレス、ユーザー名、およびユーザー ID で構成されます。ユーザーが開発したアプリケーションおよびユーザー提供のアプリケーションには、ロギングおよびモニターの使⽤において、その他の個⼈データが含まれる可能性が

あります。アプリケーションのロギングおよびモニターのデータにも、システムのロギングまたはモニターのデータの削除に使⽤されるのと同じメカニズムを使⽤できます。これらのサービスの外部でアプリケーションによって収集された個⼈データについては、データを削除するためにアプリケーション提供のメカニズムが必要になります。詳しくは、以下を参照してください。

IBM Cloud Private ロギングElasticsearch APIIBM Cloud Private のモニタリング・サービスPrometheus の資料Prometheus のログおよびメトリックの管理

データ・モニター

IBM Cloud Private プラットフォームには、クラスターおよびアプリケーションの状況をモニターするためのモニター・サービスが⽤意されています。このサービスは、Grafana および Prometheus を使⽤して、クラスター・ノードおよびコンテナーに関する詳細情報を提⽰します。モニターは、アラートを⽣成するように構成したり、外部アラート・プロバイダーと統合したりできます。プラットフォームのモニターは、デフォルトで有効になっています。アプリケーションのモニターのために、追加のモニター・スタックをデプロイできます。詳しくは、『IBM Cloud Private モニター・サービス』および『IBM Cloud Private クラスター・モニタリング』を参照してください。


https://prometheus.io/docs/introduction/overview/

IBM Cloud Private には、アプリケーションおよびクラスターの詳細な使⽤量メトリックを表⽰およびダウンロードするための計量サービスが⽤意されています。デプロイされたすべてのコンテナー・アプリケーションに対して、デフォルトで計量は有効になります。詳しくは、『IBM Cloud Private 計量サービス』を参照してください。

IBM Cloud Private プラットフォームには、ログをストリーミング、保管、検索、およびモニターするための、ELK スタック・ベースのロギング・サービスが⽤意されています。 IBM Cloud Private プラットフォームに付属する ELK スタックは、Elastic が公開している公式の ELK スタック・イメージを使⽤しています。ロギングは、デフォルトで、IBM Cloud Private プラットフォーム・サービスのシステム・ログを収集するように構成されます。アプリケーションのロギングのために、追加の ELK スタックをデプロイできます。詳しくは、『IBM Cloud Private ロギング』を参照してください。

個⼈データの使⽤を制限するための機能

IBM Cloud Private プラットフォームでは、エンド・ユーザーは、この資料で要約されている機能を使⽤して、個⼈データと⾒なされる、プラットフォーム内の技術データの使⽤を制限できます。

GDPR の下で、ユーザーは、アクセス、変更、および処理制限の権利を備えています。以下を制御するために、この資料の他のセクションを参照してください。

アクセスする権利

IBM Cloud Private プラットフォーム管理者は、IBM Cloud Private プラットフォーム機能を使⽤して、個⼈が⾃分のデータにアクセスできるようにすることが可能です。

IBM Cloud Private プラットフォーム管理者は、IBM Cloud Private プラットフォーム機能を使⽤して、個⼈についてどのようなデータを IBM Cloud Private プラットフォームが保持するのかに関する情報を個⼈に提供できます。

変更する権利

IBM Cloud Private プラットフォーム管理者は、IBM Cloud Private プラットフォーム機能を使⽤して、個⼈が⾃分のデータを変更または修正できるようにすることが可能です。

IBM Cloud Private プラットフォーム管理者は、IBM Cloud Private プラットフォーム機能を使⽤して、個⼈に代わって個⼈のデータを修正できます。

処理を制限する権利

IBM Cloud Private プラットフォーム管理者は、IBM Cloud Private プラットフォーム機能を使⽤して、個⼈のデータの処理を停⽌できます。

付録 - IBM Cloud Private プラットフォームによってログに記録されるデータ

プラットフォームとして、IBM Cloud Private は、デフォルト管理者のユーザー ID およびパスワード、サービス・ユーザーの ID およびパスワード、IP アドレス、Kubernetes ノード名など、個⼈データと⾒なされる可能性がある複数のカテゴリーの技術データを扱います。 IBM Cloud Private プラットフォームでは、プラットフォームを管理するユーザーに関する情報も扱います。プラットフォームで実⾏されるアプリケーションにより、プラットフォームでは不明な他のカテゴリーの個⼈データが導⼊されることがあります。

この付録では、プラットフォーム・サービスによってログに記録されるデータに関する詳細を記載します。

IBM Cloud Private セキュリティー

ログに記録されるデータ

ログイン・ユーザーのユーザー ID、ユーザー名、IP アドレスデータがログに記録されるタイミング

ログイン要求時

データがログに記録される場所

/var/lib/icp/audit の監査ログ内/var/log/audit の監査ログ内


データの削除⽅法

監査ログでユーザー固有のデータを検索してそのレコードを削除する


⾼可⽤性 IBM Cloud Private クラスターKubernetes 監査ログの⽣成認証および許可の監査ログ

IBM Cloud Private プラットフォーム API


コンテナー・ログ内のクライアントのユーザー ID、ユーザー名、および IP アドレスetcd サーバー内の Kubernetes クラスター状態データetcd サーバー内の Openstack および VMWare 資格情報

データがログに記録されるタイミング

API 要求時credentials-set コマンドからの資格情報の保管時


コンテナー・ログ、Elasticsearch、および etcd サーバー内データの削除⽅法

コンテナー・ログ (platform-api, platform-deploy) をコンテナーから削除するか、ユーザー固有のログ項⽬を Elasticsearch から削除するetcdctl rm コマンドを使⽤して、選択した etcd のキーと値のペアをクリアするcredentials-unset コマンドを呼び出して、資格情報を削除する


Kubernetes のロギング Elasticsearch APIetcdctl クラウド・プロバイダーを使⽤したワーカー・ノードの追加または削除

IBM Cloud Private モニター


ポッド、リリース、イメージの IP アドレス、名前お客様が開発したアプリケーションから取得されたデータに個⼈データが含まれている可能性がありま

す


Prometheus が、構成されているターゲットからメトリックを取得したときデータがログに記録される場所

Prometheus サーバーまたは構成されている永続ボリューム内データの削除⽅法

Prometheus API を使⽤して、データを検索して削除する

詳しくは、Prometheus の資料および『Prometheus のログおよびメトリックの管理』を参照してください。

IBM Cloud Private Kubernetes


クラスター・デプロイ・トポロジー (マスター、ワーカー、プロキシー、va のノード情報)サービス構成 (k8s configmap) および秘密 (k8s secrets)api-server ログのユーザー ID



https://kubernetes.io/docs/concepts/cluster-administration/logging/

https://github.com/coreos/etcd/blob/master/etcdctl/READMEv2.md


クラスターのデプロイ時

Helm カタログからのアプリケーションのデプロイ時データがログに記録される場所

etcd 内のクラスター・デプロイ・トポロジーetcd 内のデプロイ済みアプリケーションの構成および秘密


IBM Cloud Private 管理コンソールを使⽤するk8s CLI (kubectl) または etcd REST API を使⽤して、データを検索して削除するElasticsearch API を使⽤して、api-server ログ・データを検索して削除する

Kubernetes クラスター構成の変更またはクラスター・データの削除を⾏う際には慎重に⾏ってください。

詳しくは、Kubernetes kubectl および Elasticsearch API を参照してください。

IBM Cloud Private Helm API


ユーザー名および役割


チームに追加されたチャートまたはリポジトリーをユーザーが取得したとき


helm-api デプロイメント・ログ、Elasticsearchデータの削除⽅法

Elasticsearch API を使⽤して、helm-api ログ・データを検索して削除する

詳しくは、『Elasticsearch API』を参照してください。

IBM Cloud Private サービス・ブローカー


ユーザー ID (デバッグ・ログ・レベル 10 の場合のみ、デフォルトのログ・レベルでは記録されない)データがログに記録されるタイミング

サービス・ブローカーに API 要求が⾏われたときサービス・ブローカーがサービス・カタログにアクセスしたとき


サービス・ブローカー・コンテナー・ログ、Elasticsearch


Elasticsearch API を使⽤して、api-server ログを検索して削除するapi-server コンテナーでログを検索して削除する

kubectl logs $(kubectl get pods -n kube-system | grep service-catalogapiserver | awk '{print $1}') -n kube-system | grep admin


Elasticsearch APIKubernetes kubectl

サポートされる⾔語

IBM® Cloud Private 2.1.0.3 では、多数の⾔語がサポートされます。製品資料も多数の⾔語でリリースされています。


https://kubernetes.io/docs/reference/kubectl/overview/

https://kubernetes.io/docs/reference/kubectl/overview/

表 1. IBM Cloud Private でサポートされる⾔語

IBM Cloud Private でサポートされる⾔語⾔語コードブラジル・ポルトガル語 pt-br

英語 en

フランス語 fr

ドイツ語 de

イタリア語 it

⽇本語 ja

韓国語 ko

中国語 (簡体字) zh-cn

スペイン語 es

中国語 (繁体字) zh-tw

インストール

インストール・オプションを検討し、IBM® Cloud Private クラスターを構成します。

標準構成または⾼可⽤性構成で IBM Cloud Private をインストールできます。ただし、IBM® Cloud Private-CE(Community Edition) を⾼可⽤性構成でインストールすることはできません。

システム要件インストールのためのクラスターの準備 IBM Cloud Private のインストールインストール中のオプションの構成

システム要件

IBM® Cloud Private クラスターのセットアップに必要となるソフトウェア、ハードウェア、およびシステム構成の設定です。

ハードウェア要件および推奨サポートされるオペレーティング・システムとプラットフォームサポートされるブラウザーサポートされる Docker バージョンサポートされるファイル・システムとストレージデフォルト・ポート

ハードウェア要件および推奨

IBM® Cloud Private クラスターをセットアップし、実⾏するための CPU、メモリー、RAM、およびディスク・スペースの最⼩要件をご確認ください。

以下の表は、評価環境と実稼働環境の両⽅で IBM Cloud Private を実⾏するための、ノードごとの最⼩システム要件をまとめたものです。

システム要件は、マルチノード・クラスターをセットアップする必要があるかどうか、また、単⼀ホストを使⽤して

テスト環境をセットアップする必要があるかどうかによって異なります。単⼀のホスト環境にはブート、マスター、ワーカー、およびプロキシーの各ノードがあり、そのすべてが単⼀ホスト上で実⾏されます。


ハードウェア要件 (単⼀ノード・クラスター)ハードウェア要件 (マルチノード・クラスター)ディスク・スペース所要量

ファイル・システム要件

サポートされる IaaS およびハイパーバイザー

ハードウェア要件 (単⼀ノード・クラスター)

表 1. 単⼀ノード・クラスターの場合のハードウェアの最⼩要件

要件

すべ

ての

管理

サー

ビス

が使

⽤可

能

計量お

よびモ

ニタリ

ング・

サービ

スは使

⽤不可

注記

ホス

トの

数

1 1

コア 8 以上

4 以上複数のコアを搭載した最近のプロセッサーを選択してください。多くの場合、サーバーには 2つのソケット (2 つのプロセッサー) が搭載されています。このため、システム内のコアの総数は、ソケットの数に各プロセッサーのコアの数を掛けた数になります。最近のプロセッサーは通常 1 つにつき 8 個以上のコアを搭載しています。ハイエンドのプロセッサーではコア数が20 個以上になる場合もあります。プロセッサーを選択する際は、コア数、周波数、キャッシュ・サイズが最⾼でも最低でもないものを選ぶとよいでしょう。

CPU 2.4GHz以上

2.4GHz 以上

Linux® 64-bit クラスターの場合は、SSE 4.2 をサポートする CPU を選択してください。Linux® on Power® (ppc64le) クラスターの場合は、バージョン Power8 以上の CPU を使⽤してください。

RAM 32GB以上

8 GB 以上

相当量のメモリーを使⽤する可能性のあるアプリケーションをこのテスト・クラスターで実⾏

する予定がある場合、この最⼩メモリーより多くのメモリーが必要となる可能性があります。

イン

スト

ール

⽤の

ディ

ス

ク・

スペ

ース

200GB以上

150 GB以上

ハードウェア要件 (マルチノード・クラスター)

注: マルチノード・クラスターで、管理ノードを使⽤しない場合は、マスター・ノードがマスター・ノードの要件に加え、管理ノードの要件も満たすようにしてください。

表 2. マルチノード・クラスターの場合のハードウェアの最⼩要件


要件

ブ

ー

ト

・

ノ

ー

ド

マ

ス

タ

ー

・

ノ

ー

ド

プ

ロ

キ

シ

ー

・

ノ

ー

ド

ワ

ー

カ

ー

・

ノ

ー

ド

管

理

ノ

ー

ド

VA ノード

etcdノ

ー

ド

注記要件

ブ

ー

ト

・

ノ

ー

ド

マ

ス

タ

ー

・

ノ

ー

ド

プ

ロ

キ

シ

ー

・

ノ

ー

ド

ワ

ー

カ

ー

・

ノ

ー

ド

管

理

ノ

ー

ド

VA ノード

etcdノ

ー

ド

注記

ホス

トの

数

1 1、

3、

5の

い

ず

れ

か

1以

上

1以

上

1以

上

1、3、5のいずれ

か

1つ

以

上

の

奇

数

ノ

ー

ド

数

コア 1以

上

2以

上

2以

上

1以

上

4以

上

2以

上

6以

上

(実

稼

働

環

境

)

1以

上

複数のコアを搭載した最近のプロセッサーを選択してください。多くの場合、サーバーには 2 つのソケット (2 つのプロセッサー) が搭載されています。このため、システム内のコアの総数は、ソケットの数に各プロセッサーのコアの数を掛

けた数になります。最近のプロセッサーは通常 1 つにつき 8 個以上のコアを搭載しています。ハイエンドのプロセッサーではコア数が 20 個以上になる場合もあります。プロセッサーを選択する際は、コア数、周波数、キャッシュ・サイズが最⾼でも最低でもないものを選ぶとよいでしょう。

CPU 2.4GHz以

上

2.4GHz以

上

2.4GHz以

上

2.4GHz以

上

2.4GHz以

上

2.4 GHz以上

2.4GHz以

上

Linux® 64-bit クラスターの場合は、SSE 4.2 をサポートする CPU を選択してください。

Linux® on Power® (ppc64le) クラスターの場合は、バージョン Power8 以上の CPU を使⽤してください。IBM® Z クラスター上の Linux の場合は、バージョン EC12 以上の CPU を使⽤してください。


要件

ブ

ー

ト

・

ノ

ー

ド

マ

ス

タ

ー

・

ノ

ー

ド

プ

ロ

キ

シ

ー

・

ノ

ー

ド

ワ

ー

カ

ー

・

ノ

ー

ド

管

理

ノ

ー

ド

VA ノード

etcdノ

ー

ド

注記

RAM 4GB以

上

8GB以

上

4GB以

上

4GB以

上

8GB以

上

8GB以

上

16GB以

上

(実

稼

働

環

境

)

4GB以

上

イン

スト

ール

⽤の

ディ

ス

ク・

スペ

ース

100GB以

上

150GB以

上

150GB以

上

150GB以

上

150GB以

上

100GB以

上

400GB以

上

(実

稼

働

環

境

)

100GB以

上

ディスク・スペース所要量


ロケーション最⼩ディスク・

スペースノードロケーション

最⼩ディスク・

スペースノード

/var

240 GB

/var/lib/docker

100 GB 以上すべてのノード

/var/lib/etcd

10 GB 以上マスター

/var/lib/icp

100 GB 以上マスター、管理、および VA ノード

/var/lib/mysql

10 GB 以上マスター

/var/lib/kubelet

10 GB 以上すべてのノードで 10 GB を超えるディスク・スペースが必要脆弱性アドバイザーを使⽤可能にする場合、VA ノードは 100 GB 以上のディスク・スペースを必要とします。

/tmp

50GB すべてのノードのインストール・ファイル⽤ステージング・ディレクトリー。

重要: /var ディレクトリーは、IBM Cloud Private クラスターで使⽤されるほとんどの Docker イメージおよびコンテナーのデフォルト・ストレージ・ロケーションです。

ディスク・スペースの問題を防ぐには、ディスク容量のより⼤きい別のパスにデフォルト・ストレージ・ディレクト

リーをマウントしてください。 Docker ストレージ・ディレクトリー (/var/lib/docker) のマウントについて詳しくは、バインド・マウントを使⽤したデフォルト Docker ストレージ・ディレクトリーの指定を参照してください。このバインド⽅法は、他の IBM Cloud Private のデフォルト・ストレージ・ディレクトリーをマウントする際にも使⽤できます。クラスター内でのディスク・スペースの問題を防ぐには、以下のディレクトリーをマウントするのにバインド・マウントを使⽤するとよいでしょう。

Etcd - /var/lib/etcdVA および統合 - /var/lib/icpKubelet サービス - /var/lib/kubelet

デフォルト・ストレージ・ディレクトリーのマウントについて詳しくは、バインド・マウントを使⽤した他のデフォ

ルト・ストレージ・ディレクトリーの指定を参照してください。

ファイル・システム要件

IBM Cloud Private では、以下のファイル・システム・タイプが必要ですが、IBM Cloud Private ではサポートされていません。

表 4. 必須ファイル・システム

ファイル・

システム・

タイプ

バ

ー

ジ

ョ

ン

注記

POSIX 準拠の共有ファ

イル・シス

テム

適

⽤

外

⾼可⽤性 (HA) クラスターでは、共有ストレージ⽤に POSIX 準拠のファイル・システムをセットアップする必要があります。このファイル・システムは、IBM Cloud Private クラスターの外部に配置する必要があります。⾼可⽤性 IBM® Cloud Private クラスターを参照してください。

IBM Cloud Private でサポートされるファイル・システムのリストについては、『サポートされるファイル・システムとストレージ』を参照してください。


サポートされる IaaS およびハイパーバイザー

IBM Cloud Private は、いくつかの Infrastructure as a Service (IaaS) プロバイダーおよびハイパーバイザーの認証を受けています。

表 5. サポートされる IaaS バージョンIaaS バージョン注記

VMwarevCenter

5.5

6.0OpenStack Mitaka 以上Hyper-V 10.0.15063.0 以降Nutanix AHV 20170331.54 および

20170331.74Linux® on Power® (ppc64le) プラットフォームのみでサポートされる

IBM Cloud Private は、KVM、ESX、および Nutanix Acropolis ハイパーバイザーについての認証を受けています。

IBM Cloud Private は、Amazon Web Services (AWS) クラウド・プラットフォームでも実⾏できます。

Kubernetes および Cloud Foundry は、コミュニティー内の複数の IaaS プロバイダー間でのポータビリティーを実証しています。 IBM Cloud Private は VMWare、OpenStack、およびベア・メタルでのオンプレミス・インストールについて認証されていますが、他の IaaS システムにもインストール可能です。追加情報については、営業担当員にお問い合わせください。

サポートされるオペレーティング・システムとプラットフォーム

IBM® Cloud Private は、Linux ™ および Linux® on Power® (ppc64le) の 64 ビット・オペレーティング・システムをサポートします。

表 1. サポートされるオペレーティング・システムプラットフォームオペレーティング・システム

Linux® 64-bit Red Hat Enterprise Linux (RHEL) 7.3、7.4 および 7.5Ubuntu 16.04 LTSSUSE Linux Enterprise Server (SLES) 12 SP3

Linux® on Power® (ppc64le) Red Hat Enterprise Linux (RHEL) 7.3、7.4 および 7.5Ubuntu 16.04 LTSSUSE Linux Enterprise Server (SLES) 12 SP3

IBM® Z Red Hat Enterprise Linux (RHEL) 7.3、7.4 および 7.5Ubuntu 16.04 LTSSUSE Linux Enterprise Server (SLES) 12 SP3

IBM Cloud Private コンポーネントは、その独⾃のオペレーティング・システムの依存関係を取り込む Docker イメージのセットとして配布されます。上の表にリストされた認定済みオペレーティング・システムのいずれかを使⽤することをお勧めします。ただし、IBM Cloud Private は、Docker 1.12 以上をサポートする任意の Linux オペレーティング・システムで実⾏できます。

プラットフォームごとのサポートされるノード・タイプ

表 2. プラットフォームごとのサポートされるノード・タイプノード・タイプ Linux 64 ビット (x86_64) Linux® on Power® (ppc64le) IBM® Z (s390x)


ノード・タイプ Linux 64 ビット (x86_64) Linux® on Power® (ppc64le) IBM® Z (s390x)ブート Y Y N

マスター Y Y N

管理 Y Y N

プロキシー Y Y Y

ワーカー Y Y YVA Y Y N

重要: クラスター内のブート、マスター、プロキシー、VA、および管理の各ノードは、同じプラットフォーム・アーキテクチャーを使⽤しなければなりません。ワーカー・ノードのみが、異なるプラットフォーム・アーキテクチャーを使⽤できます。例えば、Linux® on Power® (ppc64le) ノードをマスター・ノードとして使⽤する予定である場合は、Linux® on Power® (ppc64le) ブート・ノードを使⽤します。

プラットフォームごとのサポートされる機能

表 3. プラットフォームごとのサポートされる機能

機能

Linux 64ビット

(x86_64)

Linux® onPower®

(ppc64le)

IBM®Z

(s390x)

注意

CloudFoundry

Y N N この機能は Community Edition では使⽤できません。

CloudAutomation Manager

Y Y N この機能は Community Edition では使⽤できません。

インストー

ル

Y Y N インストールはマスター・ノードまたは専⽤のブート・ノードでのみサポ

ートされます。

管理コンソ

ール

Y Y N 管理コンソールはマスター・ノードでのみ実⾏されます。

ELK Y Y Y* *ELK はマスター・ノードまたは管理ノードでのみ実⾏されますが、ワーカー・ノードからのデータは Filebeat を使⽤して収集されます。

モニタリン

グ

PrometheusGrafana

Y Y Y* *Prometheus および Grafana はマスター・ノードまたは管理ノードでのみ実⾏されますが、ワーカー・ノードからのデータはノード・エクスポー

ターを使⽤して収集されます。

セキュリテ

ィーおよび

RBAC

Y Y N

脆弱性アド

バイザー

Y Y N この機能は Community Edition では使⽤できません。

IPsec Y Y Nネットワー

キング:Calico

Y Y Y


機能

Linux 64ビット

(x86_64)

Linux® onPower®

(ppc64le)

IBM®Z

(s390x)

注意

ネットワー

キング:NSX-T

Y N N

ストレー

ジ:GlusterFS

Y Y N

ストレー

ジ: VMwareY N N

計量 Y Y NHelm repoまたは API

Y Y N

Nvidia GPUサポート

Y Y N

フェデレー

ション

Y Y N フェデレーション・プレーンのデプロイはマスター・ノードのみでサポー

トされています。

注: IBM® Cloud Private がサポート対象のオペレーティング・システム、Kubernetes、Docker、およびその他の従属インフラストラクチャーの新しいバージョンをサポートするようになるのは、新規リリース発表後にそれらが IBM®Cloud Private チームによって完全にテストされた場合です。

サポートされるブラウザー

IBM® Cloud Private management console には、Mozilla Firefox、Google Chrome、Internet Explorer、および Safariからアクセス可能です。

表 1. サポートされるブラウザープラットフォームサポートされるブラウザー

Windows™ Edge - 最新バージョンMozilla Firefox - Windows ⽤の最新バージョンGoogle Chrome - Windows ⽤の最新バージョン

Linux™ Mozilla Firefox - Linux ⽤の最新バージョンGoogle Chrome - Linux ⽤の最新バージョン

macOS Mozilla Firefox - Mac ⽤の最新バージョンGoogle Chrome - Mac ⽤の最新バージョンSafari - 最新バージョン

注: IBM Cloud Private は、Windows™ オペレーティング・システムまたは Mac オペレーティング・システムを使⽤するシステムにはインストールできません。ただし、ブラウザーを使⽤して Windows™ または Mac のホストから IBMCloud Private management console にアクセスすることはできます。

サポートされる Docker バージョン

IBM® Cloud Private は、選定されたオペレーティング・システム上で Docker 統合をサポートします。


Docker バージョン

表 1. IBM Cloud Private でサポートされる Docker のバージョンプラットフォームオペレーティング・システム Docker CE Docker EE

Linux® 64-bit Red Hat Enterprise Linux (RHEL) 7.3、7.4 および 7.5

注記を参照 17.03 から17.12.1

Ubuntu 16.04 LTS 1.12 から17.12.1

17.03 から17.12.1

SUSE Linux Enterprise Server (SLES) 12SP3

1.12 から17.06

17.03 から17.06

Linux on POWER 64 ビット・リトル・エンディアン (LE)

Red Hat Enterprise Linux (RHEL) 7.3、7.4 および 7.5

注記を参照 17.03 から17.12.1

Ubuntu 16.04 LTS 1.12 から17.12.1

17.03 から17.12.1


1.12 から17.06

17.03 から17.06

IBM® Z Red Hat Enterprise Linux (RHEL) 7.3、7.4 および 7.5

注記を参照 17.03 から17.12.1

Ubuntu 16.04 LTS 1.12 から17.12.1

17.03 から17.12.1


1.12 から17.06

17.03 から17.06

注記

RHEL システムの場合、提供されている IBM Cloud Private Docker パッケージを使⽤できます。提供されるIBM Cloud Private Docker パッケージを参照してください。IBM Cloud Private バージョン 2.1.0.3 は、表 1 に概略化されている Docker のバージョンでのみテスト済みです。それより後のバージョンの Docker でも、作動する可能性はあります。 Docker の互換性ポリシーについて詳しくは、Breaking changes and incompatibilities を参照してください。

提供される IBM Cloud Private Docker パッケージ

IBM Cloud Private によって提供される Docker パッケージを、ブート・ノードおよびクラスター・ノードへのインストールに使⽤できます。

このパッケージは、Red Hat Enterprise Linux (RHEL) システムおよび Ubuntu システムでのみ使⽤可能です。 SUSELinux Enterprise Server (SLES) ワーカー・ノードの場合、SLES 資料内の [Docker インストールの説明に従って、Dockerを⼿動でインストールする必要があります。

⼿動インストール⽤の Docker パッケージは、IBM Cloud Private-CE では使⽤できません。 IBM Cloud Private-CE の場合、IBM Cloud Private でサポートされるバージョンの Docker を Docker Web サイトから⼿動でインストールする必要があります。 Docker Web サイトからの Docker の⼿動インストールを参照してください。

ブート・ノードおよびクラスター・ノードへの⼿動インストールの場合 - Docker パッケージは [IBM パスポート・アドバンテージ Web サイトから⼊⼿できます。これらのパッケージのダウンロードについて詳しくは、IBM 営業担当員にお問い合わせください。⼿動インストールを実⾏するには、提供されているIBM CloudPrivate Docker パッケージを使⽤した Docker の⼿動インストールを参照してください。クラスター・ノードにインストールする場合 - Docker パッケージは /<installation_directory>/cluster/docker-engine ディレクトリー内にあり、インストール中にクラスター・ノードに⾃動的にインストール可能です。クラスター・ノードへのインストールの説明は、IBM


https://docs.docker.com/engine/breaking_changes/

Cloud Private のインストールに関するトピックに記載されています。IBM Cloud Private のインストールを参照してください。

表 2. IBM パスポート・アドバンテージ Web サイトで⼊⼿可能な IBM Cloud Private Docker パッケージ

プラットフォームオペレーティング・システ

ムパッケージ名バイナリー名

Linux® 64-bit Red Hat Enterprise Linux(RHEL)、Ubuntu

IBM Cloud Private 2.1.0.3 Docker for Linux icp-docker-17.12.1_x86_64.bin

Linux® on Power®(ppc64le)

Red Hat Enterprise Linux(RHEL)、Ubuntu

IBM Cloud Private 2.1.0.3 Docker for Linux®on Power® (ppc64le)

icp-docker-17.12.1_ppc64le.bin

IBM® Z Red Hat Enterprise Linux(RHEL)、Ubuntu

IBM Cloud Private 2.1.0.3 Docker for IBM Z icp-docker-17.12.1_s390x.bin

サポートされるファイル・システムとストレージ

IBM® Cloud Private は複数のファイル・システムとストレージのタイプをサポートしています。

サポートされるファイル・システムとストレージの表では、IBM Cloud Private management console からサポートされるストレージのタイプをまとめています。ただし、IBM Cloud Private はコマンド・ラインからすべてのKubernetes ストレージのタイプをサポートしています。サポートされるストレージ・タイプの完全なリストについては、https://v1-10.docs.kubernetes.io/docs/user-guide/persistent-volumes/ を参照してください。

表 1. サポートされるファイル・システムとストレージファイル・システムまたはストレージ

のタイプ

バージョ

ン注意

NFS 4 サーバーとクライアントの両⽅が認定バージョン 4 である必要があります。

GlusterFS 3.10.1 サーバーとクライアントの両⽅が認定バージョン 3.10.1 である必要があります。

vSphere Virtual Volume 適⽤外 vSphere Cloud Provider が構成済みである必要があります。hostPath 適⽤外単⼀ノード・クラスターでのみ使⽤してください。

デフォルト・ポート

IBM® Cloud Private クラスターのインストールと構成のために使⽤可能にする必要があるデフォルト・ポートのリストです。

IBM Cloud Private のインストールを始める前にポートを開きます。インストーラーはポートが開いていることを確認します。

ポートのアクセス・タイプ

内部 - クラスター内部での接続を可能にするには、ポートが開いていなくてはなりません。外部 - クラスター外側での接続を可能にするには、ポートが開いていなくてはなりません。

重要: IBM Cloud Private はオプションの管理ノードをサポートしています。クラスターに管理ノードが含まれていない場合、管理ノードにロードされるコンポーネントは代わりにマスター・ノードにロードされます。マスター・ノードの Management ポートを開く必要があります。


https://v1-10.docs.kubernetes.io/docs/user-guide/persistent-volumes/

表 1. デフォルト・ポート

コンポーネントデフォルト・ポートノード

インスト

ール・モ

ード

アクセ

ス・タ

イプ

認証マネージャー 8101 マスター HA および⾮ HA

内部

Calico 179 - TCP9099 - TCP

マスター

ワーカー

プロキシー

管理 (使⽤する場合)

HA および⾮ HA

内部

Docker レジストリー 8500 - TCP マスター HA および⾮ HA

内部お

よび外

部

etcd 23804001

マスター HA および⾮ HA

内部

GlusterFS 24007 - TCP24008 - TCP2222 - TCP49152:49251(TCP)

マスター

GlusterFS に使⽤されるワーカー・ノードHA および⾮ HA

内部

Heapster 80828084


内部

Helm 31031 - TCP31030 - TCP


内部

イメージ・マネージャ

ー

8600 マスター HA および⾮ HA

内部

Ingress サービス 80 - TCP443 - TCP8181 - TCP18080 - TCP

マスター

プロキシー

HA および⾮ HA

内部お

よび外

部

Kubernetes 10248 -10252 (TCP)kube_apiserver_port (8001)(TCP)kube_apiserver_insecure_port (8888)(TCP)

マスター

ワーカー

プロキシー

注: kube_apiserver_port およびkube_apiserver_insecure_port はマスター・ノードのみで使⽤可能にする必要があります。

HA および⾮ HA

内部

Kubernetes 30000 - 32767 (UDPおよび TCP)

マスター

ワーカー

プロキシー

HA および⾮ HA

外部

management console 8080 - TCP8443 - TCP


内部お

よび外

部


コンポーネントデフォルト・ポートノード

インスト

ール・モ

ード

アクセ

ス・タ

イプ

mariaDB 3306 - TCP マスター HA および⾮ HA

内部

mariaDBGalera

456745684444

マスター HA 内部

計量サーバー 31443 - TCP マスター HA および⾮ HA

外部

platform-api 6969 管理またはマスター HA および⾮ HA

内部

platform-auth-service 3100 TCP マスター HA および⾮ HA

内部

platform-deploy 4242 マスター HA および⾮ HA

内部

Rescheduler 9235 マスター HA および⾮ HA

内部

service-catalog-apiserver

30443 TCP マスター HA/⾮HA

内部

strongSwan IPsec 500 - UDP および TCP4500 - UDP

マスター

ワーカー

プロキシー

管理 (使⽤する場合)

HA および⾮ HA

内部

WebSphere®Application ServerLiberty プロファイル

9443 - TCP マスター HA および⾮ HA

外部

インストールのためのクラスターの準備

インストール・オプションを検討した後、IBM® Cloud Private クラスターをセットアップし、構成します。

クラスターの構成 IBM® Cloud Private の Docker のセットアップバインド・マウントを使⽤したデフォルト Docker ストレージ・ディレクトリーの指定バインド・マウントを使⽤した他のデフォルト・ストレージ・ディレクトリーの指定

クラスターの構成

IBM® Cloud Private をインストールする前に、サーバー・ノードのクラスターを構成する必要があります。

インストールのためのクラスターの準備

IBM Cloud Private をインストールするためのノードの準備を⾏う前に、クラスターに関していくつかの決定を⾏う必要があります。

1. システム要件を検討します。ソフトウェア要件およびハードウェア要件について詳しくは、システム要件を参照してください。


2. クラスター・アーキテクチャーを判別し、クラスター内のすべてのノードの IP アドレスを取得します。ノード・タイプについて詳しくは、アーキテクチャーを参照してください。インストール中に、各ノード・タイプの IP アドレスを指定します。 IBM Cloud Private をインストールした後で、ワーカー・ノード、プロキシー・ノード、または管理ノードをクラスターに追加したり、クラスターから削除したりできることに留意してくだ

さい。

インストールのための各ノードの準備

1. すべてのデフォルト・ポートがオープンしているが、使⽤されていないことを確認します。これらのポートをブロックするファイアウォール・ルールがあってはなりません。インストール中に、インストーラーもこれらのポートが開かれていることを確認します。 IBM Cloud Private デフォルト・ポートについて詳しくは、『デフォルト・ポート』を参照してください。

ポートが開かれていて使⽤可能かどうかを確認するために、以下の 2 つのコマンドのいずれかを実⾏できます。ここで、port_numbersは、確認する 1 つ以上の TCP/UDP ポートを表します。

以下の ss コマンドを実⾏します。

ss -tnlp | awk '{print $4}'| egrep -w "<port_numbers>"

ポートが使⽤中でない場合は、出⼒は空です。ポートが使⽤中の場合は、以下の例のように出⼒が表⽰されます。

# ss -tnlp | awk '{print $4}' | egrep -w "8001|8500|3306" :::8001 :::3306 :::8500

または、ネットワーク・ユーティリティーがインストールされている場合は、以下の netstat コマンドを実⾏します。

netstat -tnlp | awk '{print $4}' | egrep -w "<port_numbers>"

ポートが使⽤中の場合は、以下の例のように出⼒が表⽰されます。

# netstat -tnlp | awk '{print $4}' | egrep -w "8001|8500|3306" :::8001 :::3306 :::8500

ポート番号は、| ⽂字で区切る必要があります。以下の例を参照してください。

netstat -tnlp | awk '{print $4}'| egrep -w 8101|8500|3306|

2. クラスター内の各ノードで /etc/hosts ファイルを構成します。

1. 各ノードの /etc/hosts ファイルに、すべてのノードの IP アドレスおよびホスト名を追加します。重要: 必ずローカル・ホストの IP アドレスの次にホスト名をリストしてください。ホスト名をループバック・アドレス 127.0.0.1 の次にリストすることはできません。/etc/hosts ファイル内のホスト名に⼤⽂字を使⽤することはできません。クラスターに含まれるノードが 1 つの場合、そのノードの IP アドレスおよびホスト名をリストする必要があります。

2. ファイル内の 127.0.1.1 および ::1 localhost で始まる⾏をコメントにして取り除きます。

1 つのマスター・ノード、1 つのプロキシー・ノード、および 2 つのワーカー・ノードを含んでいるクラスターの /etc/hosts ファイルは、次のコードのようになります。

127.0.0.1 localhost # 127.0.1.1 <host_name> # The following lines are desirable for IPv6 capable hosts


#::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters <master_node_IP_address> <master_node_host_name> <worker_node_1_IP_address> <worker_node_1_host_name> <worker_node_2_IP_address> <worker_node_2_IP_host_name> <proxy_node_IP_address> <proxy_node_host_name>

3. (オプション) /etc/hosts が OpenStack 環境で cloud-init サービスによって管理されている場合、cloud-initサービスが /etc/hosts ファイルを変更するのを防⽌する必要があります。 /etc/cloud/cloud.cfg ファイル内で、manage_etc_hosts パラメーターが false に設定されていることを確認してください。

manage_etc_hosts: false

4. クラスター内のすべてのノード間のネットワーク接続を確認します。各ノードがクラスター内の他のすべてのノードに接続されていることを確認してください。

5. クラスター内の各ノードで、サポートされるバージョンの Python がインストールされていることを確認します。 Python バージョン 2.6 から 2.9.x がサポートされています。

python --version

6. クラスター内の各ノードでクロックを同期化します。 Network Time Protocol (NTP) を使⽤してクロックを同期化できます。 NTP のセットアップについて詳しくは、ご使⽤のオペレーティング・システムのユーザー資料を参照してください。

7. 各ノードに SSH クライアントがインストールされていることを確認します。

8. マスター・ノードで、vm.max_map_count 設定が 262144 以上であるようにします。

1. vm.max_map_count パラメーターの値を判別します。

sudo sysctl vm.max_map_count

2. vm.max_map_count 値が 262144 以上ではない場合、次のコマンドを実⾏します。

sudo sysctl -w vm.max_map_count=262144

3. セッションおよびシステムの再始動をまたがってこの値が維持されることを確実にするには、/etc/sysctl.conf ファイルにこの設定を追加します。 root ユーザーとして、次のコマンドを実⾏します。

echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf

9. マスター・ノードで、⼀時ポート範囲の下限が 10240 より⼤きくなるようにします。

1. net.ipv4.ip_local_port_range パラメーターの値を判別します。

sudo sysctl net.ipv4.ip_local_port_range

2. net.ipv4.ip_local_port_range 出⼒の下限が 10240 より⼩さい場合、次のコマンドを実⾏します。

sudo sysctl -w net.ipv4.ip_local_port_range="10240 <upper limit>"

ここで、<upper_limit> は、使⽤する最⼤⼀時ポート値です。

3. セッションおよびシステムの再始動をまたがってこの値が維持されることを確実にするには、/etc/sysctl.conf ファイルにこの設定を追加します。 root ユーザーとして、次のコマンドを実⾏します。

echo 'net.ipv4.ip_local_port_range="10240 60999"' | sudo tee -a /etc/sysctl.conf


次の作業

クラスターをインストールします。IBM Cloud Private のインストールを参照してください。

IBM® Cloud Private の Docker のセットアップ

IBM Cloud Private には Docker が必要です。ブート・ノードには Docker を⼿動でインストールする必要があります。残りのクラスター・ノードには Docker を⼿動でインストールするか、または、正しく構成されたマスター・ノード、ワーカー・ノード、プロキシー・ノード、およびオプションの管理ノードおよび脆弱性アドバイザー (VA) ノードにインストーラーが⾃動的に Docker をインストールできます。

IBM Cloud Private でサポートされるバージョンの Docker をブート・ノードに⼿動でインストールする必要があります。

また、すべてのクラスター・ノードに⼿動で Docker をインストールすることも、IBM Cloud Private インストーラーでクラスター・ノード上に Docker をセットアップすることもできます。インストーラーでクラスター・ノードにDocker をセットアップする場合は、クラスターのインストール時にこの構成を設定できます。 Docker の⾃動インストールのためのクラスター・ノードの構成を参照してください。

IBM Cloud Private でサポートされる Docker バージョンのリストについては、サポートされる Docker バージョンを参照してください。

Docker の⼿動インストールDocker Web サイトからの Docker の⼿動インストール提供されている IBM Cloud Private Docker パッケージを使⽤した Docker の⼿動インストール

インストールの検証

Docker エンジンの構成

Docker の⼿動インストール

提供されている IBM Cloud Private Docker パッケージをインストールすることも、Docker Web サイトから取得したIBM Cloud Private がサポートするバージョンの Docker をインストールすることもできます。

Docker Web サイトからの Docker の⼿動インストール

Docker を⼿動でインストールする各ノードで、以下のステップを実⾏します。

1. Docker をインストールします。Ubuntu については、https://docs.docker.com/engine/installation/ を参照してください。SUSE Linux Enterprise Server (SLES) ノードの場合、SLES 資料の Docker インストール⼿順を使⽤して、⼿動で Docker をインストールする必要があります。

2. インストールを検証します。インストールの検証を参照してください。

提供されているIBM Cloud Private Docker パッケージを使⽤した Docker の⼿動インストール

Docker を⼿動でインストールする各ノードで、以下のステップを実⾏します。

1. ご使⽤のノードで、パッケージの更新を許可するようにパッケージ・マネージャーが構成されていることを確認します。パッケージ・マネージャーには、RHEL ⽤の RPM および Ubuntu ⽤の Apt があります。

2. ノード⽤の Docker パッケージをダウンロードします。 IBM Cloud Private Docker パッケージを参照してください。

3. Docker をインストールします。


https://docs.docker.com/engine/installation/

https://www.suse.com/documentation/sles-12/singlehtml/book_sles_docker/book_sles_docker.html#cha.docker.installation

Linux® 64-bit の場合、次のコマンドを実⾏します。

chmod +x icp-docker-17.12.1_x86_64.bin sudo ./icp-docker-17.12.1_x86_64.bin --install

Linux® on Power® (ppc64le) の場合、次のコマンドを実⾏します。

chmod +x icp-docker-17.12.1_ppc64le.bin sudo ./icp-docker-17.12.1_ppc64le.bin --install

IBM® Z の場合、次のコマンドを実⾏します。

chmod +x icp-docker-17.12.1_s390x.bin sudo ./icp-docker-17.12.1_s390x.bin --install

注: この Docker パッケージをアンインストールするには、コマンドの --install オプションを --uninstall オプションに置き換えてください。

4. インストールを検証します。インストールの検証を参照してください。

インストールの検証

1. Docker エンジンが開始していることを確認します。次のコマンドを実⾏します。

sudo systemctl start docker

2. Docker エンジンを構成します。Docker エンジンの構成を参照してください。

Docker エンジンの構成

1. デフォルトの Docker ストレージ・ディレクトリーの場所を変更したい場合、IBM Cloud Private をインストールする前に、新ディレクトリーへのバインド・マウントを構成する必要があります。⼿動でインストールされる Docker ⽤のデフォルト Docker ストレージ・ディレクトリーの指定を参照してください。

2. Docker コンテナーおよびサービスのログを IBM Cloud Private management console で表⽰するには、デフォルトのロギング・ドライバーを json-file に設定する必要があります。

1. Docker デーモンのデフォルトのロギング・ドライバーを検出します。

docker info|grep "Logging Driver"


Logging Driver: journald

2. Docker ロギング・ドライバーを構成して json-file にします。https://docs.docker.com/engine/admin/logging/overview/#configure-the-default-logging-driver を参照してください。

3. デフォルトのロギング・ドライバーが json-file に更新されたことを検証します。

systemctl daemon-reload systemctl start docker docker info|grep "Logging Driver"


Logging Driver: json-file

3. カスタム docker.service ファイルを使⽤している場合、MountFlags パラメーターが share に設定されていることを確認するか、または、docker.service ファイルから MountFlags パラメーターを削除します。


https://docs.docker.com/engine/admin/logging/overview/#configure-the-default-logging-driver

systemd ユニット・ファイル docker.service の⼿動での作成について詳しくは、https://docs.docker.com/engine/admin/systemd/#manually-creating-the-systemd-unit-files を参照してください。

4. Red Hat Enterprise Linux (RHEL) システムの場合、ストレージ・ドライバーを devicemapper に設定する必要があります。ストレージ・ドライバーを設定するには、devicemapper ストレージ・ドライバーを使⽤したDocker の構成を参照してください。実稼働環境で devicemapper ストレージを使⽤するには、direct-lvm モードを有効にする必要があります。 direct-lvm モードを⼿動で構成するには、Configure direct-lvm mode manually を参照してください。

5. SELinux が Docker に対して使⽤可能になっていないことを確認します。

1. SELinux が使⽤可能かどうかを確認します。

docker info --format '{{json .SecurityOptions}}'

SELinux が使⽤可能な場合、出⼒は次のコードのようになります。

["name=seccomp,profile=default","name=selinux"]

2. SELinux が使⽤可能になっている場合は、Docker サービス・ファイルから --selinux-enable 設定を削除し、そのファイルを保存します。

vim /lib/systemd/system/docker.service

Docker デーモン構成ファイルの変更について詳しくは、デーモン構成ファイルを参照してください。

3. 変更を適⽤します。

systemctl daemon-reload

4. Docker デーモンを再始動します。

systemctl restart docker.service

5. SELinux が使⽤不可であることを確認します。

docker info --format '{{json .SecurityOptions}}'

SELinux が使⽤不可の場合、出⼒は次のコードのようになります。

["name=apparmor","name=seccomp,profile=default"]

バインド・マウントを使⽤したデフォルト Docker ストレージ・ディレクトリーの指定

異なるデフォルト Docker ストレージ・ディレクトリーを使⽤したい場合、IBM® Cloud Private をインストールする前に、バインド・マウントを使⽤して変更する必要があります。

IBM Cloud Private には Docker が必要です。各ノードに Docker をインストールするか、または、IBM Cloud Privateインストール・プロセスが Docker インストールを含むようにノードを構成することができます。 IBM Cloud Privateでの Docker のインストールを参照してください。

⼿動でインストールされる Docker ⽤のデフォルト Docker ストレージ・ディレクトリーの指定⾃動的にインストールされる Docker ⽤のデフォルト Docker ストレージ・ディレクトリーの指定


https://docs.docker.com/engine/admin/systemd/#manually-creating-the-systemd-unit-files

https://docs.docker.com/storage/storagedriver/device-mapper-driver/#configure-docker-with-the-devicemapper-storage-driver

https://docs.docker.com/storage/storagedriver/device-mapper-driver/#configure-direct-lvm-mode-manually

https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file

⼿動でインストールされる Docker ⽤のデフォルト Docker ストレージ・ディレクトリーの指定

Docker をノードにインストール済みの場合、以下の⼿順を実⾏してください。

1. すべての Docker コンテナーおよびイメージを削除します。

docker rm -f $(docker ps -aq); docker rmi -f $(docker images -q)

2. Docker サービスを停⽌します。

systemctl stop docker

3. Docker ストレージ・ディレクトリーを削除します。

rm -rf /var/lib/docker

4. 新しい /var/lib/docker ストレージ・ディレクトリーを作成します。

mkdir /var/lib/docker

5. 新しいロケーションをバインド・マウントを使⽤して設定します。例えば、新しいロケーションを /mnt/docker と設定するには、次のコマンドを実⾏します。

mkdir /mnt/docker mount --rbind /mnt/docker /var/lib/docker

6. Docker サービスを開始します。

systemctl start docker

⾃動的にインストールされる Docker ⽤のデフォルト Docker ストレージ・ディレクトリーの指定

IBM Cloud Private インストール・プロセスに Docker インストールが含まれる場合、以下の⼿順を実⾏してください。

1. 新しい /var/lib/docker ストレージ・ディレクトリーを作成します。

mkdir /var/lib/docker

2. 新しいロケーションをバインド・マウントを使⽤して設定します。例えば、新しいロケーションを /mnt/docker と設定するには、次のコマンドを実⾏します。

mkdir /mnt/docker mount --rbind /mnt/docker /var/lib/docker

バインド・マウントを使⽤したその他のデフォルト・ストレージ・デ

ィレクトリーの指定

コア IBM® Cloud Private サービスに対して異なるデフォルト・ストレージ・ディレクトリーを使⽤したい場合、IBMCloud Private をインストールする前に、バインド・マウントを使⽤して変更を⾏う必要があります。

ディスク・スペースの問題を防ぐには、ディスク容量のより⼤きい別のパスにデフォルト・ストレージ・ディレクト

リーをマウントしてください。

以下のディレクトリーをバインド・マウントを使⽤してマウントできます。


Etcd - /var/lib/etcdプライベート・イメージ・レジストリー - /var/lib/registry管理サービス - /opt/ibm/cfcVA および統合 - /var/lib/icpKubelet サービス - /var/lib/kubelet

新しいデフォルト・ロケーションを設定するには、以下のコマンドを実⾏します。

1. 新規ストレージ・ディレクトリーを作成します。

mkdir <new storage directory name>

2. 新しいロケーションをバインド・マウントを使⽤して設定します。

mount --rbind <new storage directory> <old storage directory>

3. システムのリブートをまたがってこの変更が保持されるようにします。

echo "<new storage directory> <old storage directory> none defaults,bind 0 0" >> /etc/fstab

例えば、/var/lib/etcd ディレクトリーに対して新しいロケーションを /mnt/etcd と設定するには、以下のコマンドを実⾏します。

mkdir /mnt/etcd mount --rbind /mnt/etcd /var/lib/etcd echo "/mnt/etcd /var/lib/etcd none defaults,bind 0 0" >> /etc/fstab

IBM® Cloud Private のインストール

IBM Cloud Private のマスター・ノード、プロキシー・ノード、ワーカー・ノード、および、オプションの管理ノードおよび脆弱性アドバイザー・ノードを、標準構成または⾼可⽤性構成でクラスターにインストールします。

IBM® Cloud Private-CE のインストールでは、テスト⽬的でのみ単⼀ノード・クラスターまたはマルチノード・クラスターをセットアップします。このエディションは無料オプションです。このエディションは⾼可⽤性をサポートしていません。また、Cloud Foundry、Cloud Automation Manager、および脆弱性アドバイザーなどのフィーチャー・サービスは使⽤できません。 Community Edition からライセンス・エディションの IBM Cloud Private にアップグレードすることはできません。

IBM Cloud Private クラウド・ネイティブ環境のインストールでは、単⼀ノード・クラスターまたはマルチノード・クラスターの実稼働環境をセットアップします。このバージョンでは、バンドルされたコンポーネントの⼀部を使⽤でき、さらに、コンポーネントの追加が可能です。 IBM Cloud Private クラウド・ネイティブを参照してください。

IBM Cloud Private エンタープライズ環境のインストールでは、単⼀ノード・クラスターまたはマルチノード・クラスターの実稼働環境をセットアップします。このバージョンでは、IBM Cloud Private クラウド・ネイティブ・バージョンに含まれているすべてのバンドルされたコンポーネントと、いくつかの追加機能を使⽤できます。また、追加のコンポーネントを使⽤してカスタマイズすることも可能です。 IBM Cloud Private エンタープライズ環境を参照してください。

IBM Cloud Private クラウド・ネイティブ環境のインストール IBM Cloud Private エンタープライズ環境のインストール IBM® Cloud Private-CE のインストールバンドルされた製品のインストール

IBM® Cloud Private クラウド・ネイティブ環境のインストール


IBM Cloud Private クラウド・ネイティブ・バンドルの標準クラスターや⾼可⽤性 (HA) クラスターをインストールできます。

IBM Cloud Private をインストールする前に、クラスターを準備します。クラスターの構成を参照してください。

マスター・ノードまたはプロキシー・ノードが SUSE Linux Enterprise Server (SLES) オペレーティング・システムを使⽤している場合、インストール中は、クラスター内のすべてのファイアウォールを無効にする必要が

あります。

次の 5 つの主なステップで IBM Cloud Private のインストールを実⾏できます。

1. ブート・ノードのみでの Docker のインストール2. インストール環境のセットアップ3. (オプション) クラスターのカスタマイズ4. クラスター・ノード⽤の Docker のセットアップ5. 環境のデプロイ

インストールが完了したら、クラスターにアクセスし、インストール後のタスクを実⾏してください。

ステップ 1: ブート・ノードのみでの Docker のインストール

ブート・ノードは、クラスターのインストールに使⽤されるノードです。通常、ブート・ノードはマスター・ノードです。ブート・ノードについて詳しくは、ブート・ノードを参照してください。

IBM Cloud Private でサポートされるバージョンの Docker がブート・ノードにインストールされる必要があります。サポートされる Docker バージョンを参照してください。

Docker をインストールするには、Docker の⼿動インストールを参照してください。

ステップ 2: インストール環境のセットアップ

1. root 権限を持つユーザーとしてブート・ノードにログインします。2. IBM Cloud Private のインストール・ファイルをダウンロードします。クラスター内のノードのタイプに合った正しいファイルをダウンロードする必要があります。これらのファイルは、IBM® パスポート・アドバンテージ Web サイトから⼊⼿できます。

Linux® 64-bit クラスターの場合、ibm-cloud-private-x86_64-2.1.0.3.tar.gz ファイルをダウンロードします。

Linux® on Power® (ppc64le) クラスターの場合、ibm-cloud-private-ppc64le-2.1.0.3.tar.gzファイルをダウンロードします。

IBM® Z ワーカー・ノードおよびプロキシー・ノードを使⽤するクラスターの場合、ibm-cloud-private-s390x-2.1.0.3.tar.gz ファイルをダウンロードします。

3. イメージを解凍して Docker にロードします。イメージの解凍には数分かかる場合があります。


tar xf ibm-cloud-private-x86_64-2.1.0.3.tar.gz -O | sudo docker load


tar xf ibm-cloud-private-ppc64le-2.1.0.3.tar.gz -O | sudo docker load

4. IBM Cloud Private 構成ファイルを保管するためのインストール・ディレクトリーを作成し、そのディレクトリーに移動します。例えば /opt/ibm-cloud-private-2.1.0.3 に構成ファイルを保管するには、次のコマンドを実⾏します。



mkdir /opt/ibm-cloud-private-2.1.0.3; \ cd /opt/ibm-cloud-private-2.1.0.3

5. インストーラー・イメージから構成ファイルを解凍します。

sudo docker run -v $(pwd):/data -e LICENSE=accept \ ibmcom/icp-inception:2.1.0.3-ee \ cp -r cluster /data

インストール・ディレクトリー内に cluster ディレクトリーが作成されます。例えば、インストール・ディレクトリーが /opt/ibm-cloud-private-2.1.0.3 の場合、/opt/ibm-cloud-private-2.1.0.3/cluster フォルダーが作成されます。 cluster ディレクトリー構造の概要については、cluster ディレクトリー構造を参照してください。

6. (オプション) 以下のコマンドを実⾏して、IBM Cloud Private のライセンス・ファイルを表⽰できます。

docker run -e LICENSE=view -e LANG=$LANG ibmcom/icp-inception:2.1.0.3-ee

ここで、$LANG はサポートされる⾔語形式です。例えば、中国語 (簡体字) でライセンスを表⽰するには、以下のコマンドを実⾏します。

docker run -e LICENSE=view -e LANG=zh_CN ibmcom/icp-inception:2.1.0.3-ee

サポートされる⾔語形式のリストについては、『サポートされる⾔語』を参照してください。

7. ブート・ノードからクラスター内の他のすべてのノードへのセキュア接続を確⽴します。以下のいずれかのプロセスを実⾏します。

クラスター内で SSH をセットアップします。クラスター・ノードでの SSH 鍵の共有を参照してください。

クラスター内でパスワード認証をセットアップします。クラスター・ノードのパスワード認証の構成を参照してください。

8. クラスター内の各ノードの IP アドレスを /<installation_directory>/cluster/hosts ファイルに追加します。 hosts ファイルでのノード役割の設定を参照してください。カスタマイズしたホスト・グループを定義することもできます。カスタム・ホスト・グループの定義を参照してください。

注: ワーカー・ノードは、混合アーキテクチャーをサポートできます。 Linux® 64-bit、Linux® on Power®(ppc64le)、および IBM® Z の各プラットフォームで実⾏されている単⼀クラスターにワーカー・ノードを追加することができます。

9. クラスターを保護するために SSH 鍵を使⽤する場合、/<installation_directory>/cluster フォルダー内の ssh_key ファイルを、他のクラスター・ノードとの通信に使⽤される秘密鍵ファイルに置き換えます。クラスター・ノードでの SSH 鍵の共有を参照してください。次のコマンドを実⾏します。

sudo cp ~/.ssh/id_rsa ./cluster/ssh_key

この例で、~/.ssh/id_rsa は、秘密鍵ファイルのロケーションと名前です。

10. クラスター⽤のイメージ・ファイルを /<installation_directory>/cluster/images フォルダーに移動します。


mkdir -p cluster/images; \ sudo mv /<path_to_installation_file>/ibm-cloud-private-x86_64-2.1.0.3.tar.gz cluster/images/


mkdir -p cluster/images; \ sudo mv /<path_to_installation_file>/ibm-cloud-private-ppc64le-2.1.0.3.tar.gz


cluster/images/

このコマンド内の path_to_installation_file は、イメージ・ファイルのパスです。

11. (オプション) IBM® Z ワーカー・ノードおよびプロキシー・ノードをクラスターに追加することを計画している場合、次のコマンドを実⾏します。

sudo mv /<path_to_installation_file>/ibm-cloud-private-s390x-2.1.0.3.tar.gz cluster/images/

ステップ 3: クラスターのカスタマイズ

1. オプションで、/<installation_directory>/cluster/config.yaml ファイル内でクラスターのさまざまなカスタマイズを設定することもできます。汎⽤設定を参照してください。

2. OpenStack や AWS など、ネットワーク・インターフェース (NIC) が複数ある環境では、以下のコードを config.yaml ファイルに追加する必要があります。

cluster_lb_address: <external address> proxy_lb_address: <external address>

<external address> の値は、外部サービスへの通信を管理する、IP アドレス、完全修飾ドメイン・ネーム、または OpenStack 浮動 IP アドレスです。 proxy_lb_address パラメーターの設定が必要なのは、プロキシー HA 環境の場合のみです。

3. HA 環境の場合、HA 設定を参照してください。

ステップ 4: クラスター・ノード⽤の Docker のセットアップ

クラスター・ノードとは、マスター・ノード、ワーカー・ノード、プロキシー・ノード、および管理ノードのことで

す。アーキテクチャーを参照してください。

IBM Cloud Private でサポートされるバージョンの Docker がクラスター・ノードにインストールされる必要があります。サポートされる Docker バージョンを参照してください。

サポートされるバージョンの Docker がクラスター・ノードにインストールされていない場合、IBM Cloud Privateは、インストール中にクラスター・ノードに Docker を⾃動的にインストールできます。

Docker の⾃動インストールのためにクラスター・ノードを準備するには、Docker の⾃動インストールのためのクラスター・ノードの構成を参照してください。

ステップ 5: 環境のデプロイ

1. インストール・ディレクトリー内の cluster フォルダーに移動します。

cd ./cluster

2. 環境をデプロイします。選択するオプションによっては、デプロイメント・コマンドにさらにパラメーターを追加する必要がある場合があります。

config.yaml ファイル内で offline_pkg_copy_path パラメーターを指定した場合。デプロイメント・コマンドに -e ANSIBLE_REMOTE_TEMP=<offline_pkg_copy_path> オプションを追加します。ここで、<offline_pkg_copy_path> は、config.yaml ファイル内で設定する offline_pkg_copy_path パラメーターの値です。デフォルトで、環境をデプロイするコマンドは、⼀度に 15 個のノードをデプロイするように設定されます。 15 より多いノードがあるクラスターの場合、デプロイメントの完了までの時間が⻑くなることがあります。デプロイメントが速く⾏われるようにしたい場合、もっと多くの数のノードが⼀度にデプ


ロイされるように指定できます。コマンドで -f <number of nodes to deploy> 引数を使⽤します。

環境をデプロイするには、次のコマンドを実⾏します。

sudo docker run --net=host -t -e LICENSE=accept \ -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3-ee install

3. インストールの状況を確認します。

インストールが成功した場合、次のようなクラスターのアクセス情報が表⽰されます。

UI URL is https://<ip_address>:8443 , default username/password is admin/admin

config.yaml ファイル内に cluster_lb_address 値を指定した場合、<ip_address> は、その cluster_lb_address アドレスです。この値を指定しなかった場合、HA クラスターでは、このメッセージ内の <ip_address> はユーザーが指定した cluster_vip アドレスであり、標準クラスターでは、この値はマスター・ノードの IP アドレスです。

注: プライベート・ネットワーク内部にクラスターを作成した場合、マスター・ノードのパブリック IPアドレスを使⽤して、クラスターにアクセスしてください。

インストール中にエラーが発⽣する場合は、トラブルシューティングを参照してください。


1. クラスターにアクセスします。 Web ブラウザーからクラスターの URL をブラウズします。サポートされるブラウザーのリストについては、サポートされるブラウザーを参照してください。

Web ブラウザーから IBM Cloud Private management console を使⽤してクラスターにアクセスする⽅法について詳しくは、management console を使⽤した IBM Cloud Private クラスターへのアクセスを参照してください。

Kubernetes コマンド・ライン (kubectl) を使⽤してクラスターにアクセスする⽅法について詳しくは、kubectl CLI を使⽤した IBM Cloud Private クラスターへのアクセスを参照してください。

注: インストールのすぐ後に management console でページを開くと、「502 Bad Gateway」というメッセージが出されることがあります。その場合、NGINX サービスはすべてのコンポーネントの開始をまだ完了していません。すべてのコンポーネントが開始された後、ページはロードされます。

インストール後のタスク

1. ファイアウォールを無効にしていた場合は、ファイアウォールを再始動します。2. すべての IBM Cloud Private デフォルト・ポートが開いていることを確認します。デフォルト IBM Cloud

Private ポートについて詳しくは、デフォルト・ポートを参照してください。3. ブート・ノードのバックアップを取ります。セキュアな場所に /<installation_directory>/cluster ディレクトリーをコピーします。クラスターを保護するために SSH 鍵を使⽤している場合、バックアップ・ディレクトリー内の SSH 鍵が同期を保っていることを確認してください。

4. その他のソフトウェアをバンドルからインストールします。バンドルされた製品のインストールを参照してください。

IBM® Cloud Private エンタープライズ環境のインストール

IBM Cloud Private エンタープライズ・バンドルの標準クラスターや⾼可⽤性 (HA) クラスターをインストールできます。


IBM Cloud Private-CE をインストールする前に、クラスターを準備してください。クラスターの構成を参照してください。


あります。









1. root 権限を持つユーザーとしてブート・ノードにログインします。2. IBM Cloud Private のインストール・ファイルをダウンロードします。クラスター内のノードのタイプに合った正しいファイルをダウンロードする必要があります。これらのファイルは、IBM® パスポート・アドバンテージ Web サイトから⼊⼿できます。

Linux® 64-bit クラスターの場合、ibm-cp-app-mod-x86_64-2.1.0.3.tar.gz ファイルをダウンロードします。

Linux® on Power® (ppc64le) クラスターの場合、ibm-cp-app-mod-ppc64le-2.1.0.3.tar.gz ファイルをダウンロードします。

IBM® Z ワーカー・ノードおよびプロキシー・ノードを使⽤するクラスターの場合、ibm-cloud-private-s390x-2.1.0.3.tar.gz ファイルをダウンロードします。



tar xf ibm-cp-app-mod-x86_64-2.1.0.3.tar.gz -O | sudo docker load


tar xf ibm-cp-app-mod-ppc64le-2.1.0.3.tar.gz -O | sudo docker load

4. IBM Cloud Private 構成ファイルを保管するためのインストール・ディレクトリーを作成し、そのディレクトリーに移動します。例えば /opt/ibm-cp-app-mod-2.1.0.3 に構成ファイルを保管するには、次のコマンドを実⾏します。

mkdir /opt/ibm-cp-app-mod-2.1.0.3; \ cd /opt/ibm-cp-app-mod-2.1.0.3

5. インストーラー・イメージから構成ファイルを解凍します。



sudo docker run -v $(pwd):/data -e LICENSE=accept \ ibmcom/icp-inception:2.1.0.3-ee \ cp -r cluster /data

インストール・ディレクトリー内に cluster ディレクトリーが作成されます。例えば、インストール・ディレクトリーが /opt/ibm-cp-app-mod-2.1.0.3 の場合、/opt/ibm-cp-app-mod-2.1.0.3/cluster フォルダーが作成されます。 cluster ディレクトリー構造の概要については、cluster ディレクトリー構造を参照してください。














10. クラスター⽤のイメージ・ファイルを /<installation_directory>/cluster/images フォルダーに移動します。


mkdir -p cluster/images; \ sudo mv /<path_to_installation_file>/ibm-cp-app-mod-x86_64-2.1.0.3.tar.gz cluster/images/


mkdir -p cluster/images; \ sudo mv /<path_to_installation_file>/ibm-cp-app-mod-ppc64le-2.1.0.3.tar.gz cluster/images/

このコマンド内の path_to_installation_file は、イメージ・ファイルのパスです。


11. (オプション) IBM® Z ワーカー・ノードおよびプロキシー・ノードをクラスターに追加することを計画している場合、次のコマンドを実⾏します。

sudo mv /<path_to_installation_file>/ibm-cloud-private-s390x-2.1.0.3.tar.gz cluster/images/




cluster_lb_address: <external address> proxy_lb_address: <external address>

<external address> の値は、外部サービスへの通信を管理する、IP アドレス、完全修飾ドメイン・ネーム、または OpenStack 浮動 IP アドレスです。 proxy_lb_address パラメーターの設定が必要なのは、プロキシー HA 環境の場合のみです。

3. HA 環境の場合、HA 設定を参照してください。









cd ./cluster


config.yaml ファイル内で offline_pkg_copy_path パラメーターを指定した場合。デプロイメント・コマンドに -e ANSIBLE_REMOTE_TEMP=<offline_pkg_copy_path> オプションを追加します。ここで、<offline_pkg_copy_path> は、config.yaml ファイル内で設定する offline_pkg_copy_path パラメーターの値です。デフォルトで、環境をデプロイするコマンドは、⼀度に 15 個のノードをデプロイするように設定されます。 15 より多いノードがあるクラスターの場合、デプロイメントの完了までの時間が⻑くなることがあります。デプロイメントが速く⾏われるようにしたい場合、もっと多くの数のノードが⼀度にデプロイされるように指定できます。コマンドで -f <number of nodes to deploy> 引数を使⽤します。



sudo docker run --net=host -t -e LICENSE=accept \ -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3-ee install



UI URL is https://<ip_address>:8443 , default username/password is admin/admin

config.yaml ファイル内に cluster_lb_address 値を指定した場合、<ip_address> は、その cluster_lb_address アドレスです。この値を指定しなかった場合、HA クラスターでは、このメッセージ内の <ip_address> はユーザーが指定した cluster_vip アドレスであり、標準クラスターでは、この値はマスター・ノードの IP アドレスです。







注: インストールのすぐ後に management console でページを開くと、「502 Bad Gateway」というメッセージが出されることがあります。その場合、NGINX サービスはすべてのコンポーネントの開始をまだ完了していません。すべてのコンポーネントが開始された後、ページはロードされます。


1. ファイアウォールを無効にしていた場合は、ファイアウォールを再始動します。2. すべての IBM Cloud Private デフォルト・ポートが開いていることを確認します。デフォルト IBM Cloud

Private ポートについて詳しくは、デフォルト・ポートを参照してください。3. ブート・ノードのバックアップを取ります。セキュアな場所に /<installation_directory>/cluster ディレクトリーをコピーします。クラスターを保護するために SSH 鍵を使⽤している場合、バックアップ・ディレクトリー内の SSH 鍵が同期を保っていることを確認してください。

4. その他のソフトウェアをバンドルからインストールします。バンドルされた製品のインストールを参照してください。

IBM® Cloud Private-CE のインストール

クラスター内で IBM® Cloud Private-CE (Community Edition) のマスター・ノード、ワーカー・ノード、プロキシー・ノード、およびオプションの管理ノードをセットアップします。

IBM Cloud Private-CE をインストールする前に、クラスターを準備してください。クラスターの構成を参照してください。



あります。









1. root 権限を持つユーザーとしてブート・ノードにログインします。

2. Docker Hub から IBM Cloud Private-CE インストーラー・イメージをプルし、以下のコマンドを実⾏します。

sudo docker pull ibmcom/icp-inception:2.1.0.3

3. IBM Cloud Private 構成ファイルを保管するためのインストール・ディレクトリーを作成し、そのディレクトリーに移動します。例えば、構成ファイルを /opt/ibm-cloud-private-ce-2.1.0.3 に保管する場合、次のコマンドを実⾏します。

mkdir /opt/ibm-cloud-private-ce-2.1.0.3; \ cd /opt/ibm-cloud-private-ce-2.1.0.3

4. 構成ファイルを解凍します。

sudo docker run -e LICENSE=accept \ -v "$(pwd)":/data ibmcom/icp-inception:2.1.0.3 cp -r cluster /data

インストール・ディレクトリー内に cluster ディレクトリーが作成されます。例えば、インストール・ディレクトリーが /opt の場合、/opt/cluster フォルダーが作成されます。 cluster ディレクトリー構造の概要については、cluster ディレクトリー構造を参照してください。


















cluster_lb_address: <external IP address>

ここで、<external address> は、外部サービスへの通信を管理する、IP アドレス、完全修飾ドメイン・ネーム、または OpenStack 浮動 IP アドレスです。









cd ./cluster



デフォルトで、環境をデプロイするコマンドは、⼀度に 15 個のノードをデプロイするように設定されます。 15 より多いノードがあるクラスターの場合、デプロイメントの完了までの時間が⻑くなることがあります。デプロイメントが速く⾏われるようにしたい場合、もっと多くの数のノードが⼀度にデプロイされるように指定できます。コマンドで -f <number of nodes to deploy> 引数を使⽤します。


sudo docker run --net=host -t -e LICENSE=accept \ -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3 install



UI URL is https://master_ip:8443 , default username/password is admin/admin

このメッセージ中の master_ip は、IBM Cloud Private-CE クラスターのマスター・ノードの IP アドレスです。





Web ブラウザーから IBM Cloud Private-CE management console を使⽤してクラスターにアクセスする⽅法について詳しくは、management console を使⽤した IBM Cloud Private クラスターへのアクセスを参照してください。


注: インストールのすぐ後に管理コンソールでページを開くと、「502 Bad Gateway」というメッセージが出されることがあります。その場合、NGINX サービスはすべてのコンポーネントの開始をまだ完了していません。すべてのコンポーネントが開始された後、ページはロードされます。


1. ファイアウォールを無効にしていた場合は、ファイアウォールを再始動します。2. すべての IBM Cloud Private-CE デフォルト・ポートがオープンしていることを確認してください。デフォルト IBM Cloud Private-CE ポートについて詳しくは、デフォルト・ポートを参照してください。

3. ブート・ノードのバックアップを取ります。よりセキュアな場所に /<installation_directory>/cluster ディレクトリーをコピーします。クラスターを保護するためにSSH 鍵を使⽤している場合、バックアップ・ディレクトリー内の SSH 鍵が同期を保っていることを確認してください。

バンドルされた製品のインストール

IBM® Cloud Private パッケージに組み込まれている他の製品の Helm チャートを⼿動でインストールする必要があります。


これらの製品の圧縮ファイルは、IBM パスポート・アドバンテージ新しいタブで開く](../images/icons/launch-glyph.svg "新しいタブで開く") から⼊⼿できます。

必要なユーザー・タイプまたはアクセス・レベル: クラスター管理者またはチーム管理者

チャートをロードする前に、前提条件である以下の作業を実⾏してください。

IBM Cloud Private をインストールします。標準 IBM Cloud Private 環境のインストールを参照してください。IBM Cloud Private CLI をインストールし、クラスターにログインします。 IBM Cloud Private CLI のインストールを参照してください。

ご使⽤のコンピューターから Docker プライベート・イメージ・レジストリー・ホストへの認証を構成し、プライベート・レジストリーにログインします。 Docker CLI の認証の構成を参照してください。root ユーザーではない場合、ご使⽤のアカウントが docker グループの⼀部であることを確認します。Docker 資料のLinux のインストール後のステップを参照してください。

ご使⽤のコンピューターとクラスターとの間に安定したネットワーク接続があることを確認します。

パッケージされている製品をインストールするには、以下のようにします。

1. 圧縮ファイルをパスポート・アドバンテージから取得します。

2. 圧縮ファイル内のイメージをコンピューターにロードするための⼗分なディスク・スペースがあることを確認します。

1. Docker ディスク使⽤量を確認します。次のコマンドを実⾏します。

docker system df

コマンド・オプションについて詳しくは、Docker 資料のdocker system df を参照してください。

2. 追加のディスク・スペースが必要な場合は、以下のいずれかのアクションを実⾏してください。古い Docker イメージを削除します。Docker デーモンが使⽤するストレージ量を増やします。 Docker デーモンが使⽤するストレージ量を増やすには、dockerd Docker 資料の dm.basesize に関する項⽬を参照してください。

3. まだログインしていない場合は IBM Cloud Private CLI からクラスターにログインし、Docker プライベート・イメージ・レジストリーにログインします。

bx pr login -a https://<cluster_CA_domain>:8443 --skip-ssl-validation docker login <cluster_CA_domain>:8500

ここで、cluster_CA_domain は、認証局 (CA) ドメインです。 CA ドメインを指定しなかった場合、デフォルト値は mycluster.icp です。 IBM Cloud Private サービス⽤の独⾃の認証局 (CA) の指定を参照してください。

4. パスポート・アドバンテージからのファイルをインストールします。

bx pr load-ppa-archive --archive <compressed_file_name> [--clustername <cluster_CA_domain>] [--namespace <namespace>]

ここで、compressed_file_name はパスポート・アドバンテージからダウンロードしたファイルの名前、cluster_CA_domain は (CA) ドメイン、namespace は Docker イメージをホスティングする Docker 名前空間です。注: imagePullSecret を指定する場合を除いて、このイメージには、イメージがホスティングされている名前空間からのみアクセスできます。

5. IBM Cloud Private Catalog 内のチャートを表⽰します。

1. IBM Cloud Private management console ナビゲーション・メニューから、「管理」 > 「リポジトリー」をクリックします。

2. 「リポジトリーの同期」をクリックします。


https://docs.docker.com/engine/installation/linux/linux-postinstall/#manage-docker-as-a-non-root-user

https://docs.docker.com/engine/reference/commandline/system_df/

https://docs.docker.com/engine/reference/commandline/dockerd

リポジトリーの同期化、追加、または削除を⾏うために必要なユーザー・タイプまたはアクセス・レベ

ル: クラスター管理者

3. ナビゲーション・メニューから「カタログ」を選択します。

新規 Helm チャートが Catalog にロードされ、クラスターにそれらをインストールできます。

注: Helm チャートは Catalog を使⽤することでのみロードできます。 Helm CLI を使⽤してチャートをロードすることはできません。

インストール中のオプションの構成

IBM® Cloud Private クラスター。

クラスター・ノードでの SSH 鍵の共有クラスター・ノードのパスワード認証の構成 hosts ファイルでのノード役割の設定インストールのカスタマイズ config.yaml ファイルを使⽤したクラスターのカスタマイズ Docker の⾃動インストールのためのクラスター・ノードの構成 HA クラスターでのノード割り当ておよび通信モニタリング・サービスの構成 GlusterFS ストレージの構成 vSphere クラウド・プロバイダーの構成ストレージの動的プロビジョニング IPsec を使⽤したクラスター・データ・ネットワーク・トラフィックの暗号化 IBM Cloud Private サービス⽤の独⾃の認証局 (CA) の指定 dm-crypt を使⽤したボリュームの暗号化 VMware NSX-T 2.0 と IBM Cloud Private の統合脆弱性アドバイザーの使⽤可能化外部ロード・バランサーのセットアップ Kubernetes 監査ログの⽣成

クラスター・ノードでの SSH 鍵の共有

SSH (Secure Shell) 鍵は、IBM® Cloud Private クラスター内のホスト間のセキュア接続を可能にするために使⽤されます。

IBM Cloud Private クラスターをインストールする前に、構成ノード間の認証を構成します。ブート・ノード上でSSH 鍵ペアを⽣成し、その鍵を他のクラスター・ノードと共有することができます。鍵をクラスター・ノードと共有するには、クラスター内の各ノードに対する root 権限を持つアカウントにアクセスできる必要があります。

SSH 鍵を共有せずに認証を構成するには、クラスター・ノードのパスワード認証を構成します。クラスター・ノードのパスワード認証の構成を参照してください。

1. root 権限を持つアカウントを使⽤してブート・ノードにログインします。

2. SSH 鍵を⽣成します。

ssh-keygen -b 4096 -f ~/.ssh/id_rsa -N ""

3. この鍵を、認可された鍵のリストに追加します。

cat ~/.ssh/id_rsa.pub | sudo tee -a ~/.ssh/authorized_keys


4. この鍵を、クラスター内のマスター・ノード、ワーカー・ノード、プロキシー・ノード、管理ノード、または脆弱性アドバイザー (VA) ノードに追加します。

1. ブート・ノードから、SSH 公開鍵をノードに追加します。

ssh-copy-id -i ~/.ssh/id_rsa.pub <user>@<node_ip_address>

ここで、<user> はノードのユーザー名、<node_ip_address> はノードの IP アドレスです。

2. マスター・ノード、ワーカー・ノード、プロキシー・ノード、管理ノード、または VA ノードにログインします。

3. SSH サービスを再始動します。

sudo systemctl restart sshd

5. クラスター内の残りの各ノードについて前のステップを繰り返します。

クラスター・ノードのパスワード認証の構成

SSH 鍵の代わりにパスワードを使⽤して、IBM® Cloud Private クラスター内のホスト間のセキュア接続を可能にします。

IBM Cloud Private クラスターをインストールする前に、ノード間の認証を構成する必要があります。

注: /<installation_directory>/cluster/config.yaml ファイルまたは /<installation_directory>/cluster/hosts ファイルのいずれかを使⽤することによって、各ノードでユーザーのパスワード認証を構成できます。両⽅のファイルを使⽤してパスワード認証を構成しないでください。

root ユーザー、または root 権限を持つユーザー名のパスワードを指定する必要があります。

各ノードでパスワードを指定せずに認証を構成するには、ブート・ノードで SSH 鍵ペアを⽣成し、その鍵を他のクラスター・ノードと共有します。クラスター・ノードでの SSH 鍵の共有を参照してください。

config.yaml ファイルを使⽤したパスワード認証の構成

同じパスワードを持つノードに対してのみ、config.yaml ファイルを使⽤してパスワード認証を設定できます。各ノードのパスワードが異なっている場合は、hosts ファイルを使⽤してパスワード認証を設定してください。

ユース・ケースに応じた構成パラメーターを /<installation_directory>/cluster/config.yaml ファイルに追加します。

ユーザー・タイプ構成パラメーター

root ansible_user: root ansible_ssh_pass: SHARED_PASSWORD ansible_ssh_common_args: "-oPubkeyAuthentication=no"

ここで、

SHARED_PASSWORD

は、各 root ユーザーのパスワードです。 ansible_user: non_root


⾮ root ansible_ssh_pass: SHARED_PASSWORD ansible_become: true ansible_become_pass: "{{ ansible_ssh_pass }}" ansible_ssh_common_args: "-oPubkeyAuthentication=no"

ここで、

SHARED_PASSWORD

は、各ユーザーのパスワードです。

hosts ファイルを使⽤したパスワード認証の構成

パスワードが同じノードまたは異なっているノードに対して、hosts ファイルを使⽤してパスワード認証を設定できます。

ユース・ケースに応じた構成パラメーターを /<installation_directory>/cluster/hosts ファイルに追加します。

root ユーザーの場合、以下のコードで⽰されているように、各 IP アドレスを、そのノード上の root ユーザーに関する ansible_user パラメーター、ansible_ssh_pass パラメーター、ansible_ssh_common_argsパラメーター、およびオプションの ansible_port パラメーターと共に付加します。

[master] <master_node_IP_address> ansible_user="root" ansible_ssh_pass="<NODE_PASSWORD>" ansible_ssh_common_args="-oPubkeyAuthentication=no" ansible_port="<PORT_VALUE>" [worker] <worker_node_IP_address> ansible_user="root" ansible_ssh_pass="<NODE_PASSWORD>" ansible_ssh_common_args="-oPubkeyAuthentication=no" ansible_port="<PORT_VALUE>" [proxy] <proxy_node_IP_address> ansible_user="root" ansible_ssh_pass="<NODE_PASSWORD>" ansible_ssh_common_args="-oPubkeyAuthentication=no" ansible_port="<PORT_VALUE>" [management] <management_node_IP_address> ansible_user="root" ansible_ssh_pass="<NODE_PASSWORD>" ansible_ssh_common_args="-oPubkeyAuthentication=no" ansible_port="<PORT_VALUE>" [va] <va_node_IP_address> ansible_user="root" ansible_ssh_pass="<NODE_PASSWORD>" ansible_ssh_common_args="-oPubkeyAuthentication=no" ansible_port="<PORT_VALUE>"

ここで、<NODE_PASSWORD> は、そのノード上の root ユーザーのパスワードです。また、<PORT_VALUE>は、カスタマイズされた SSH ポートです。

⾮ root ユーザーの場合、以下のコードで⽰されているように、各 IP アドレスを、ansible_user パラメーター、ansible_ssh_pass パラメーター、ansible_ssh_common_args パラメーター、ansible_become パラメーター、ansible_become_pass パラメーター、およびオプションの ansible_port パラメーターと共に付加します。

[master] <master_node_IP_address> ansible_user="<USER>" ansible_ssh_pass="<NODE_PASSWORD>" ansible_become=true ansible_become_pass="<NODE_PASSWORD>" ansible_port="<PORT_VALUE>" ansible_ssh_common_args="-oPubkeyAuthentication=no" [worker] <worker_node_IP_address> ansible_user="<USER>" ansible_ssh_pass="<NODE_PASSWORD>" ansible_become=true ansible_become_pass="<NODE_PASSWORD>" ansible_port="<PORT_VALUE>" ansible_ssh_common_args="-oPubkeyAuthentication=no" [proxy]


<proxy_node_IP_address> ansible_user="<USER>" ansible_ssh_pass="<NODE_PASSWORD>" ansible_become=true ansible_become_pass="<NODE_PASSWORD>" ansible_port="<PORT_VALUE>" ansible_ssh_common_args="-oPubkeyAuthentication=no" [management] <management_node_IP_address> ansible_user="<USER>" ansible_ssh_pass="<NODE_PASSWORD>" ansible_become=true ansible_become_pass="<NODE_PASSWORD>" ansible_port="<PORT_VALUE>" ansible_ssh_common_args="-oPubkeyAuthentication=no" [va] <va_node_IP_address> ansible_user="<USER>" ansible_ssh_pass="<NODE_PASSWORD>" ansible_become=true ansible_become_pass="<NODE_PASSWORD>" ansible_ssh_common_args="-oPubkeyAuthentication=no"

ここで、<USER> は、そのノード上で root 権限を持つ⾮ root ユーザーであり、<NODE_PASSWORD> は、この⾮ root ユーザーのパスワードです。また、<PORT_VALUE> は、カスタマイズされた SSH ポートです。

hosts ファイルでのノード役割の設定

hosts ファイルには、クラスター内のマスター・ノード、ワーカー・ノード、プロキシー・ノード、およびオプションの管理ノードおよび脆弱性アドバイザー・ノードの IP アドレスが含まれます。

IBM® Cloud Private ノード・タイプについて詳しくは、アーキテクチャーを参照してください。

この hosts ファイルは /<installation_directory>/cluster フォルダー内にあります。

IBM Cloud Private のインストール中に、マスター・ノード、ワーカー・ノード、およびプロキシー・ノードの IP アドレスをこのファイルに追加します。オプションで、管理ノードも指定できます。 IBM Cloud Private をインストールした後、クラスター内のマスター・ノード、プロキシー・ノード、および管理ノードを変更することはできませ

ん。

重要: このファイルにホスト名を追加しないでください。

1. /<installation_directory>/cluster/hosts ファイルを開きます。

2. 各ノード・タイプの IP アドレスを、このファイルの別々のセクションに追加します。

標準環境または Community Edition 環境の場合、master セクションに 1 つのノードのみを指定できます。

⾼可⽤性 (HA) 環境の場合、master セクションと proxy セクションに複数のホストを指定します。任意の数のプロキシー・ノードを指定できますが、3 個から 5 個のマスター・ノードを指定する必要があります。マスター・ノードのみ、プロキシー・ノードのみ、あるいは、両⽅のタイプのノードに対して、⾼可⽤性を構成できます。

オプションの管理ノードを使⽤可能にできます。

単⼀のコンピューターをクラスター内の複数のノードとして使⽤する場合、適⽤する各ノードのセクシ

ョンにそのコンピューターの IP アドレスを指定する必要があります。例えば、同じノードをマスターおよびプロキシーとして使⽤する場合、そのノードの IP アドレスを master セクションと proxy セクションの両⽅に⼊⼒します。

オプションの etcd ノードを使⽤可能にできます。 etcd ノードを追加すると、etcd がこのノードにインストールされます。それ以外の場合は、etcd がマスター・ノードにインストールされます。

標準環境または Community Edition 環境の hosts ファイルは次のテキストのようになります。

[master] <master_node_IP_address> [worker] <worker_node_1_IP_address> ....


<worker_node_n_IP_address> [proxy] <proxy_node_IP_address> [management] <management_node_1_IP_address> .... <management_node_n_IP_address> [va] <va_node_IP_address> [etcd] <etcd_node_IP_address>

注: 管理ノードを使⽤可能にしたい場合、[management] ヘッダーから # を削除する必要があります。

⾼可⽤性環境の hosts ファイルは次のテキストのようになります。

[master] <master_node_1_IP_address> <master_node_2_IP_address> <master_node_3_IP_address> [worker] <worker_node_1_IP_address> .... <worker_node_n_IP_address> [proxy] <proxy_node_1_IP_address> <proxy_node_2_IP_address> <proxy_node_3_IP_address> [management] <management_node_1_IP_address> .... <management_node_n_IP_address> [va] <va_node_IP_address> [etcd] <etcd_node_IP_address>

注: 脆弱性アドバイザー・ノードおよび管理ノードを使⽤可能にしたい場合、[va] ヘッダーおよび [management]ヘッダーから # を削除する必要があります。

1. HA 環境では、hosts ファイル内のノード固有パラメーターに値を設定することもできます。例えば、以下のコードのように vip_iface パラメーター値を設定できます。

[master] <master_node_1_IP_address> vip_iface=eth0 <master_node_2_IP_address> vip_iface=ens192 <master_node_3_IP_address> vip_iface=ens160

インストール中の優先順位が⾼いのは config.yaml ファイル内のパラメーター値です。 hosts ファイルでパラメーター値を設定するには、config.yaml ファイルからそのパラメーターを削除してください。 IBMCloud Private クラウド・ネイティブ環境のインストールを参照してください。

カスタム・ホスト・グループの定義


特定のアプリケーションまたはプロセス⽤に予約しておけるホスト・グループを作成することもできます。ホスト・グループはインストール中またはインストール後に定義できます。

カスタム・ホスト・グループを定義するには、次のようにします。

1. ホスト・グループの名前を作成します。ホスト・グループ名は hostgroup-customname の形式でなければなりません。

2. カスタム・ホスト・グループに属するホストの IP を追加します。例えば、Db2 プロセスでのみ使⽤できるカスタム・ホスト・グループを作成するには、hosts ファイルに以下を追加します。

...... [hostgroup-db2] <hostgroup_node_1_IP_address> <hostgroup_node_2_IP_address> <hostgroup_node_3_IP_address>

3. ホスト・グループをデプロイします。

インストール中にカスタム・ホスト・グループを作成する場合は、インストール⼿順を続⾏します。

インストール後にカスタム・ホスト・グループを作成する場合は、クラスター・ノードの追加を参照し

てください。

デプロイメント後、ホスト・グループのノードには customname=true ラベルおよび dedicated=customname:NoSchedule テイントが割り当てられます。例えば、hostgroup-db2 ノードには db2=true ラベルおよび dedicated=db2:NoSchedule テイントが割り当てられます。

インストールのカスタマイズ

クラスターのカスタマイズのほとんどを /<installation_directory>/cluster/config.yaml ファイルで⾏うことができます。これらのカスタマイズは、クラスターのインストール中に実⾏される必要があります。

カスタマイズを⾏うために使⽤可能なパラメーターの完全なリストを検討するには、config.yaml ファイルを使⽤したクラスターのカスタマイズを参照してください。

/<installation_directory>/cluster/hosts ファイルでもノード固有のパラメーター値を設定できます。ただし、インストール中の優先順位は config.yaml ファイル内に設定されたパラメーター値が最⾼です。 hosts ファイルでパラメーター値を設定するには、config.yaml ファイルからそのパラメーターを削除してください。 hosts ファイルでのノード固有パラメーター値の設定について詳しくは、hosts ファイルでのノード役割の設定を参照してください。

汎⽤インストール・オプション

HA インストール・オプションcluster ディレクトリー構造

汎⽤インストール・オプション

クラスターをカスタマイズするためにインストール中に構成可能ないくつかのオプション機能を以下に⽰します。

1. モニタリング・サービスを構成します。モニタリング・サービスの構成を参照してください。重要: ⾼可⽤性構成を使⽤する場合、モニタリング・サービス構成⼿順に従って、モニタリング・サービスがネットワーク共

有ストレージ・プロバイダーを使⽤することを許可してください。

2. クラスター⽤の認証局 (CA) を指定します。 IBM Cloud Private サービス⽤の独⾃の認証局 (CA) の指定を参照してください。


3. 統合をセットアップします。表 8: 統合設定を参照してください。このフィーチャーは、テクノロジー・プレビューとしてのみ使⽤可能です。 IBM Cloud Private-CE (Community Edition) ではこのフィーチャーは使⽤できません。

4. 脆弱性アドバイザーを使⽤可能にします。脆弱性アドバイザーの使⽤可能化を参照してください。 IBM CloudPrivate-CE (Community Edition) ではこのフィーチャーは使⽤できません。

5. ワーカー・ノードで GlusterFS ストレージをプロビジョンします。 GlusterFS ストレージを参照してください。

6. vSphere クラウド・プロバイダーを構成します。 vSphere クラウド・プロバイダーの構成を参照してください。

7. AWS クラウド・プロバイダーを構成します。 AWS クラウド・プロバイダー設定を参照してください。8. 環境内のストレージ・プロビジョナー⽤の 1 つ以上のストレージ・クラスを作成します。ストレージの動的プロビジョニングを参照してください。

9. IPsec を使⽤してクラスター・データ・ネットワーク・トラフィックを暗号化します。 IPsec を使⽤したクラスター・データ・ネットワーク・トラフィックの暗号化を参照してください。

10. etcd key-value ストアを暗号化します。 eCryptfs を使⽤したボリュームの暗号化を参照してください。注:Red Hat Enterprise Linux (RHEL) では eCryptfs はサポートされていません。

11. VMware NSX-T 2.0 と IBM Cloud Private クラスター・ノードを統合します。 VMware NSX-T 2.0 と IBM CloudPrivate の統合を参照してください。

12. デフォルト Docker ストレージ・ディレクトリーを指定します。バインド・マウントを使⽤したデフォルトDocker ストレージ・ディレクトリーの指定を参照してください。

13. その他のデフォルト・ストレージ・ディレクトリーを指定します。バインド・マウントを使⽤したその他のデフォルト・ストレージ・ディレクトリーの指定を参照してください。

14. 外部ロード・バランサーをセットアップします。外部ロード・バランサーのセットアップを参照してください。

HA インストール・オプション

⾼可⽤性 IBM® Cloud Private クラスターのトピックを必ず検討してください。 HA は、IBM Cloud Private のクラウド・ネイティブ・エディションおよびエンタープライズ・エディションでのみサポートされています。

HA クラスターの場合、以下のように HA パラメーターを構成します。

1. マスター・ノードに対して HA を構成するには、config.yaml ファイル内の HA settings セクションを更新します。 vip_iface パラメーター値として、環境のインターフェース名を指定します。 cluster_vip パラメーター値として、使⽤可能な IP アドレスを指定します。クラスター・ノードが使⽤する同じ IP 範囲から 1 つを指定することが推奨されます。構成は次のコードのようになります。

# HA settings vip_iface: eth0 cluster_vip: 5.5.5.1

2. プロキシー・ノードに対して HA を構成するには、config.yaml ファイル内の Proxy settings セクションを更新します。 proxy_vip_iface パラメーター値として、環境のインターフェース名を指定します。proxy_vip パラメーター値として、使⽤可能な IP アドレスを指定します。クラスター・ノードが使⽤する同じIP 範囲から 1 つを指定することが推奨されます。構成は次のコードのようになります。

# Proxy settings proxy_vip_iface: eth0 proxy_vip: 5.5.5.2

注: cluster_vip パラメーターと proxy_vip パラメーターの値には、異なる IP アドレスを使⽤する必要があります。

注: これらのノード固有パラメーターは hosts ファイル内に設定することもできます。例えば、以下のコードのように vip_iface パラメーター値を設定できます。


[master] <master_node_1_IP_address> vip_iface=eth0 <master_node_2_IP_address> vip_iface=ens192 <master_node_3_IP_address> vip_iface=ens160

インストール中の優先順位が最も⾼いのは config.yaml ファイル内のパラメーター値です。 hosts ファイルでパラメーター値を設定するには、config.yaml ファイルからそのパラメーターを削除してください。

cluster ディレクトリー構造

cluster ディレクトリーには以下のファイルが含まれます。

config.yaml: クラスターに IBM Cloud Private をインストールするために使⽤される構成設定。

hosts: クラスター内のノードの定義。

misc/storage_class: クラスターの動的ストレージ・クラス定義が含まれているフォルダー。

ssh_key: クラスター内の他のノードと通信するために使⽤される SSH 秘密鍵のプレースホルダー・ファイル。

docker-engine: クラスター・ノードに Docker をインストールするために使⽤できる IBM Cloud PrivateDocker パッケージが含まれています。

config.yaml ファイルを使⽤したクラスターのカスタマイズ

config.yaml ファイルには、クラスターをデプロイするために必要なすべての構成設定が含まれます。

config.yaml ファイルでさまざまなパラメーターを使⽤することによって、インストールをカスタマイズできます。

config.yaml には、IBM® Cloud Private-CE (Community Edition) インストール・プロセス中にインストーラーによって Docker Hub からプルされる Docker イメージのリストも含まれます。 IBM Cloud Private-CE (CommunityEdition) インストールの場合、Docker Hub から直接プルする代わりに、これらのインストール・イメージをプライベート・イメージ・レジストリーに保管することもできます。イメージがプライベート・イメージ・レジストリーに保管される場合、config.yaml ファイルを更新して、プライベート・イメージ・レジストリー内のインストール・イメージをポイントするようにします。 IBM Cloud Private インストールの場合、これらのインストーラー Docker イメージは、ダウンロードされるインストーラー・パッケージ内にあるため、コメント化されます。

注: config.yaml ファイルのセクションを更新する前に、そのセクション内のインライン・コメントを検討してください。

config.yaml ファイルを変更することによって、以下のパラメーターを設定したり更新したりできます。

1. /<installation_directory>/config.yaml ファイルを開きます。2. パラメーターおよび値を追加または変更します。 <parameter_name>:<value> の形式でパラメーターおよび値を定義します。

汎⽤設定

表 1. 汎⽤設定パラメ

ーター説明

デフォルト

値


パラメ

ーター説明

デフォルト

値

cluster_name

クラスターの名前。

複数のクラスターがある環境では、クラスターごとに別個の名前を指定します。

cluster_name には⼩⽂字の英数字のみを使⽤する必要があります。

mycluster

cluster_CA_domain

クラスター内で使⽤する認証局 (CA) ドメインを指定します。 {{cluster_name }}.icp

cluster_domain

Kubernetes 内部 DNS ドメイン・ネーム。 cluster.local

offline_pkg_copy_path

オフラインでのインストール中に⼀時インストール・ファイルを保持するためのディレクトリ

ー。このロケーションには、30 GB 以上の使⽤可能なディスク・スペースがなければなりません。

/tmp ディレクトリーのスペースが 30 GB 未満の場合は、このパラメーターに使⽤可能なディスク・スペース所要量があるロケーションを設定する必要があります。

/tmp

tiller_http_proxy tiller_https_proxy

このパラメーターにより、ファイアウォールの内側で実⾏される環境やインターネットにアク

セスできない環境で、IBM Cloud Private カタログへのアクセスが可能になります。 IBM 公開 Helm リポジトリーにアクセスできるようにするには、クラスターのインストール前にこのパラメーターを設定します。受け⼊れられる値:

標準 HTTP プロキシー URL。例: http://123.4.5.6:3128標準 HTTPS プロキシー URL。例: https://123.4.5.6:3129

なし

firewall_enabled

ファイアウォールが有効になっている環境での IBM Cloud Private クラスターのインストールを許可するには、このパラメーターを true に設定します。

false

docker_api_timeout

docker-py がコンテナーを開始するのを待機する最⼤時間を設定します。 100 秒

wait_for_timeout

このパラメーターは、オペレーションのデフォルトのタイムアウト値を指定します。ほとんどの環境で、3600 に設定するのが理想的です。

なし

disabled_management_services

このパラメーターは、管理サービスを無効にする場合に使⽤します。

例えば、サービス・カタログ、計量、モニター・サービス、およびカスタム・メトリック・スケ

ーリング・ポリシーを無効にするには、このパラメーターを ["service-catalog", "metering", "monitoring", "istio", "vulnerability-advisor", "custom-metrics-adapter"] に設定します。

デフォルトでは、脆弱性アドバイザー、Istio、およびカスタム・メトリック・スケーリング・ポリシーは無効になっています。

以下のすべての管理サービスを無効にした状態で、IBM Cloud Private バージョン 2.1.0.3 クラスターを正常にインストールできます。 ["istio","service-catalog","nginx-ingress","platform-api","platform-ui","catalog-ui","security-onboarding","heapster","rescheduler","unified-router","metering","monitoring","helm-repo","helm-api", "vulnerability-advisor", "custom-metrics-adapter"]

["istio","vulnerability-advisor","custom-metrics-adapter"]


Kubernetes 設定

表 2. Kubernetes 設定

パラメーター説明

デフ

ォル

ト値

kube_apiserver_extra_args

Kubernetes の追加 API サーバー構成を設定します。 --key=value 形式で指定される API サーバー引数のリストを受け⼊れます。

なし

kube_apiserver_secure_port

Kubernetes API サーバーのセキュア・ポートを設定します。 8001

kube_controller_manager_extra_args

Kubernetes の追加コントローラー構成を設定します。 --key=value 形式で指定されるコントローラー引数のリストを受け⼊れます。

なし

kube_proxy_extra_args

Kubernetes の追加プロキシー構成を設定します。 --key=value 形式で指定されるプロキシー引数のリストを受け⼊れます。

なし

kube_scheduler_extra_args

Kubernetes の追加スケジューラー構成を設定します。 --key=value 形式で指定されるスケジューラー引数のリストを受け⼊れます。

なし

kubelet_extra_args

kubelet の追加構成を設定します。 --key=value 形式で指定される kubelet 引数のリストを受け⼊れます。例えば、1 つの kubelet で実⾏できるポッドの最⼤数を設定するには、kubelet_extra_args: ["--max-pods=110"] という構成を設定します。

なし

auditlog_enabled

システムを変更した個々のユーザー、管理者、またはその他のシステム・コンポーネントによ

るアクティビティーを発⽣順に記録する Kubernetes 監査ログを有効にします。監査ログを有効にするには、このパラメーターを true に設定します。

false

ログ設定

表 3. ログ設定

パラメ

ーター説明値

デフ

ォル

ト値

metrics_max_age

システムおよびアプリケーションのメトリックを保管する最⼤⽇数を設定します。指定されたこの⽇数よりも古いメトリックは削除されます。メトリックの削除は指定⽇の 23:59に実⾏されます。

⽇数 1

kibana_install

true に設定されていると、インストーラーは Kibana をデプロイし、それを IBM CloudPrivate management console と統合します。

true または false

false

ネットワーク設定

表 4. ネットワーク設定パラ

メー

ター

説明値デフォ

ルト値

calico_ipip_enabled

Calico が IP over IP モードで実⾏されることを許可します。この設定は、複数のワーカー・ノードが異なるサブネットワークにあり、それらのワーカー・ノード間のルーターで

BGP が使⽤可能にされていない場合に必要です。また、この設定は、仮想マシンがルーターとして機能することが許可されていない、⼀部のクラウド環境 (OpenStack など) でも必要です。

true または false

true


パラ

メー

ター

説明値デフォ

ルト値

calico_tunnel_mtu

Calico の IPIP のデフォルト MTU は 1430 です。ご使⽤のホストのメイン・インターフェースの MTU が 1450 未満の場合、Calico IPIP のパフォーマンスが低下します。ホストのメイン・インターフェースの MTU から Calico IPIP トンネルのデフォルト MTU を引き算した結果が 20 以上になるように、MTU を設定してください。

正整数 1430

network_cidr

ネットワーク全体に対して使⽤する IPv4 ネットワーク。この値は CIDR 形式でなければなりません。 network_cidr を作成する際、既存のホスト・ネットワークともservice_cluster_ip_range とも競合しない IP 範囲を選択するように注意してください。ほとんどの環境では、デフォルト値を使⽤できます。

CIDR 形式の IP アドレス

10.1.0.0/16

cluster_lb_address

ネットワーク・インターフェース (NIC) が複数ある環境では、cluster_lb_address を使⽤して、クラスター内の管理サービス⽤のパブリック IP アドレスまたは外部 IP アドレスを設定します。 IP アドレスの代わりに、完全修飾ドメイン・ネームを指定できます。このパブリック・アドレスはマスター・ノードに割り当てられ、コンソールにアクセスす

るために使⽤され、kubectl を構成するためにも使⽤されます。 HA 環境では、cluster_lb_address は、先導マスター IP として cluster_vip をマスクします。

IPア

ド

レ

ス

完

全

修

飾

ド

メ

イ

ン

・

ネ

ー

ム

OpenStack浮

動

IPア

ド

レ

ス

なし


パラ

メー

ター

説明値デフォ

ルト値

proxy_lb_address

ネットワーク・インターフェース (NIC) が複数ある環境では、proxy_lb_address を使⽤して、サービスへの外部アクセスを許可するために NodePort リソースによって使⽤されるパブリック IP アドレスまたは外部 IP アドレスを設定します。 IP アドレスの代わりに、完全修飾ドメイン・ネームを指定できます。

IPア

ド

レ

ス

完

全

修

飾

ド

メ

イ

ン

・

ネ

ー

ム

OpenStack浮

動

IPア

ド

レ

ス

なし


パラ

メー

ター

説明値デフォ

ルト値

calico_ip_autodetection_method

ノード間のルーティングに使⽤される IP アドレスを⾃動検出するように Calico ノードを構成できます。以下のいずれかのメソッドを使⽤できます。

calico_ip_autodetection_method: first-found: このメソッドは、最初に検出された有効なインターフェース上の最初の有効な IP アドレスを使⽤します。calico_ip_autodetection_method: interface: このパラメーターは、正規表現の名前のコンマ区切りリストを値として受け⼊れます。指定されたインターフェース上で検出された最初の IP アドレスが使⽤されます。

例:

calico_ip_autodetection_method: interface=eth0calico_ip_autodetection_method: interface=eth.*calico_ip_autodetection_method: interface=eth.*,ens.*

calico_ip_autodetection_method: can-reach=<remote IP address or host name>: can-reach メソッドは、ローカル・ルーティングを使⽤して、指定された宛先に到達するために使⽤される IP アドレスを判別します。このパラメーターは、リモート IP アドレスまたはドメイン・ネームを値として受け⼊れます。注:ネットワーク・インターフェース (NIC) が複数ある環境では、can-reach メソッドを

使⽤して、ワークロード⽤に使⽤されるネットワークを指定します。 IBM Cloud Private では、calico_ip_autodetection_method: can-reach=<Master node IP address> と設定できます。ネットワーク・インターフェース名は⽂字列

"docker.*"、"cbr.*"、"dummy.*"、"virbr.*"、"lxcbr.*"、"veth.*"、"lo"、"cali.*"、"tunl.*"、および "flannel.*" を含んでいてはなりません。

IP によっては Calico で認識されないものがあります。インターフェースに以下の範囲の IP がないことを確認してください。

10.0.2.15/24 - この IP 範囲は、デフォルト Vagrant/VirtualBox NAT インターフェース・アドレス範囲です。

92.168.122.* - この IP 範囲は、デフォルト libvirt VM インターフェース・アドレス範囲です。

first-found

interface=INTERFACE-REGEX

can-reach=<remote IP address or domain name>

can-reach={{ groups['master'][0] }}


パラ

メー

ター

説明値デフォ

ルト値

service_cluster_ip_range

Kubernetes サービス・クラスター IP 範囲。この構成によって、サービス⽤の⼀連の IP が割り振られます。トラフィックがノードから発信される前に kube-proxy がサービス IP をポッド IP に変換するため、これらのサービス IP はルーティング可能である必要はありません。 service_cluster_ip_range を作成する際、既存のホスト・ネットワークともnetwork_cidr とも競合しない IP 範囲を選択するように注意してください。service_cluster_ip_range は、仮想ネットワークです。ほとんどの環境では、デフォルト値をそのまま使⽤できます。

CIDR 形式の IP アドレス

10.0.0.1/24

Docker 設定

注: これらの構成は、提供される IBM Cloud Private Docker パッケージに対してのみ設定できます。 IBM CloudPrivate Docker パッケージを参照してください。

表 5. Docker 設定

パラ

メー

ター

説明フォーマット

デ

フ

ォ

ル

ト

値

docker_version

インストールする Docker のバージョンを指定します。

必要なバージョンのパッケージが /<installation_directory>/cluster/docker-engine ディレクトリーにある必要があります。

ストリング 17.12.1

install_docker

クラスター・ノードにインストーラーが⾃動的に Docker をインストールすることを許可します。

true または false true

docker_env

Docker の環境を設定します。例えば、Docker がファイアウォールの背後で実⾏される場合、https_proxy ロケーションを構成します。環境ロケーションは /etc/systemd/system/docker.service.d/docker.conf ファイルに保管されます。

["HTTP_PROXY=http://httphost:port/","NO_PROXY=localhost,127.0.0.1"]

な

し

docker_extra_args

Docker 構成パラメーターを設定します。 Docker 構成パラメーターについて詳しくは、dockerd を参照してください。

["--storage-driver=devicemapper"] なし

docker_log_max_size

それを超えると古い項⽬が削除される、ログ・ファイルの最⼤サイ

ズ。このパラメーターは、⾮ブート・ノードに IBM Cloud Privateが Docker をインストールすることを許可する場合のみ使⽤します。

正整数と、ファイル・サイズの計測

単位を表す修飾⼦。修飾⼦には、「k」(kB)、「m」(mB)、または「g」(gB) を使⽤できます。

50m

docker_log_max_file

ログ・ファイルの最⼤数。このパラメーターは、⾮ブート・ノードに IBM Cloud Private が Docker をインストールすることを許可する場合のみ使⽤します。

正整数。 10

プロキシー HA 設定

表 6. プロキシー HA 設定


https://docs.docker.com/engine/reference/commandline/dockerd/

パラ

メー

ター

説明値

デ

フ

ォ

ル

ト

パラ

メー

ター

説明値

デ

フ

ォ

ル

ト

vip_manager

マスター・ノードまたはプロキシー・ノードで、あるいは、マスター・ノードおよび

プロキシー・ノードで仮想 IP (VIP) を管理するサービス。マスター・ノードまたはプロキシー・ノードに HA を構成する場合、この値を設定できます。この値は⼀度だけ設定します。

ucarpetcdkeepalived

etcd

proxy_vip_iface

プロキシー・ノード HA 環境の仮想 IP インターフェースを設定します。 eth0 な

し

proxy_vip

プロキシー・ノード HA 環境の仮想 IP アドレスを設定します。 172.16.12.123 IP アドレスの中にサブネットを指

定しないでくださ

い。

な

し

マスター HA 設定

表 7. HA 設定パ

ラ

メ

ー

タ

ー

説明値

デ

フ

ォ

ル

ト

vip_manager

マスター・ノードまたはプロキシー・ノードで、あるいは、マスター・ノードおよびプ

ロキシー・ノードで仮想 IP (VIP) を管理するサービス。マスター・ノードまたはプロキシー・ノードに HA を構成する場合、この値を設定できます。この値は⼀度だけ設定します。

ucarpetcdkeepalived

etcd

cluster_vip

IBM Cloud Private HA 環境の仮想 IP アドレスを設定します。 172.16.12.123 IP アドレスの中にサブネットを指

定しないでくださ

い。

な

し

vip_iface

IBM Cloud Private HA 環境の仮想 IP インターフェースを設定します。 eth0 な

し

統合設定

表 8. 統合設定

パラメーター説明デフォ

ルト値


パラメーター説明デフォ

ルト値

federation_enable このクラスターに統合コントロール・プレーンをデプロイします。このクラスターがホスト統合クラスターになります。単⼀の統合ホスト・クラスターが複数のクラスターを管理できます。

統合クラスターについて詳しくは、https://v1-10.docs.kubernetes.io/docs/tasks/federation/set-up-cluster-federation-kubefed/

を参照してください。

インストール中にクラスターに統合プレーンをデプロイするには、このパラメータ

ーの値を true に設定します。

false

federation_cluster

統合クラスターの名前。 federation-cluster

federation_domain 統合の DNS 接尾部。統合サービス DNS 名はこの接尾部を付けて公開されます。 cluster.federation

federation_external_policy_engine_enabled

統合内の外部ポリシー・エンジンを有効または無効にします。 false

federation_apiserver_extra_args

追加の統合 API サーバー引数を設定します。

–key=value 形式で指定される引数のリストを受け⼊れます。

例: [“--arg1-value1”,”--arg2=value2”]federation_controllermanager_extra_args

追加の統合コントローラー・マネージャー引数を設定します。

–key=value 形式で指定される引数のリストを受け⼊れます。

例: [“--arg1-value1”,”--arg2=value2”]cluster_zone クラスターが配置されるゾーン。例えば、クラスターが⽶国南部にある場合、ゾー

ンを south に設定します。

myzone

cluster_region クラスターが配置される地域。複数のゾーンが集まって 1 つの地域になります。例えば、クラスターが⽶国南部にある場合、地域を us に設定します。

myregion

ユーザー設定

表 9. ユーザー設定パラメー

ター説明

ansible_useransible_ssh_passansible_becomeansible_portansible_become_pass

IBM Cloud Private は、インストール中にクラスター・ノードにアクセスするために、ansible_user パラメーターおよび ansible_ssh_pass パラメーターの値を使⽤します。マスター・ノードまたはワーカー・ノードに接続するための sudo 特権のある⾮管理者アカウントを使⽤している場合、ansible_user をユーザー名に、ansible_become を true に設定します。パスワードを使⽤して sudo を実⾏する場合、ansible_become_pass パラメーターを⾮ root (sudo ユーザー) のパスワードの値に設定する必要があります。 /etc/sudoers ファイルに NOPASSWD を設定する場合、この変数はオプションです。カスタマイズされた SSH ポートがある場合は、<installation_directory/cluster/hosts ファイルで ansible_port パラメーターを設定することもできます。これらのパラメーター値の構成⽅法については、クラスター・ノードのパスワード認証の構成を参照して

ください。


https://v1-10.docs.kubernetes.io/docs/tasks/federation/set-up-cluster-federation-kubefed/

パラメー

ター説明

default_admin_user

カスタマイズされたクラスター管理者ユーザー名を設定します。デフォルトは admin です。 LDAP が有効にされていて、ユーザー名 admin の LDAP ユーザーがある場合、クラスター管理者名と LDAP ユーザー名との競合を回避するため、default_admin_user パラメーター値を他の値に変更してください。

default_admin_password

カスタマイズされたクラスター管理者パスワードを設定します。デフォルトは admin です。 LDAP が有効にされている場合、このパラメーターは LDAP 管理者パスワードを設定します。

GlusterFS 設定

表 10. GlusterFS 設定パラメー

ター説明

glusterfs

ワーカー・ノードでストレージをプロビジョンします。

GlusterFS をセットアップするには、いくつかのパラメーターを設定する必要があります。 GlusterFS ストレージの追加を参照してください。

vSphere クラウド・プロバイダー設定

表 11. vSphere クラウド・プロバイダー設定パラメー

ター説明

cloud_provider

vSphere クラウド・プロバイダーをセットアップします。

vSphere クラウド・プロバイダーをセットアップするには、いくつかのパラメーターを設定する必要があります。 vSphere クラウド・プロバイダーの構成を参照してください。

AWS クラウド・プロバイダー設定

表 12. AWS クラウド・プロバイダー設定パラメ

ーター説明

cloud_provider

AWS クラウド・プロバイダーをセットアップします。

AWS クラウド・プロバイダーを設定するには、次の 2 つのパラメーターを設定する必要があります。cloud_provider を aws に設定し、kubelet_nodename を nodename に設定します。

Amazon Web Services (AWS) クラウド・プラットフォームでの IBM Cloud Private-CE (Community Edition)のセットアップについて詳しくは、Run IBM Cloud Private on Amazon Web Services (AWS) cloud platform

を参照してください。

IPsec を使⽤したクラスター・データ・ネットワーク・トラフィックの暗号化

表 13. IPsec を使⽤したクラスター・データ・ネットワーク・トラフィックの暗号化パラメ

ーター説明

ipsec_mesh


https://medium.com/ibm-cloud/run-ibm-cloud-private-on-amazon-web-services-aws-cloud-platform-c2cec1020ba8

パラメ

ーター説明

enable: true

IPsec を使⽤可能にします。

IPsec をセットアップするには、いくつかのパラメーターを設定する必要があります。 IPsec を使⽤したクラスター・データ・ネットワーク・トラフィックの暗号化を参照してください。

脆弱性アドバイザー設定

表 14. 脆弱性アドバイザー設定パラメータ

ー説明デフォルト値

disabled_management_services

デフォルトでは、脆弱性アドバイザーは使⽤不可にされます。

脆弱性アドバイザーを有効にするには、無効リストから vulnerability-advisor を削除します。パラメーターを以下のように設定できます。disabled_management_services: ["istio", "custom-metrics-adapter"]

["istio","vulnerability-advisor", "custom-metrics-adapter"]

va_api_server_nodePort

脆弱性アドバイザー API サービスのノード・ポート。既存サービスと競合する場合は、デフォルト値を変更してください。

30610

va_crawler_enabled

クラスター内で脆弱性アドバイザー⽤にクローラーを使⽤可能にするかどうかを

指定します。

脆弱性レポートが必要ない場合は、このパラメーターを実⾏時に使⽤不可にする

ことができます。

True

VMware NSX-T 2.0 と IBM Cloud Private の統合

表 15. VMware NSX-T 2.0 と IBM Cloud Private の統合パラメータ

ー説明

network_type

nsx-t

ingress_controller_in_hostnetwork

デフォルト⼊⼝コントローラーの動作を設定します。値は、true (デフォルト) または false です。デフォルト値 true の場合、デフォルト⼊⼝コントローラーはノード IP アドレスを使⽤するように設定されます。デフォルト⼊⼝コントローラーが NAT (ネットワーク・アドレス変換) プールを使⽤することが必要な場合、この値を false に設定する必要があります。

nsx_t VMware NSX-T 2.0 と IBM Cloud Private を統合するには、いくつかのパラメーターを設定する必要があります。 VMware NSX-T 2.0 と IBM Cloud Private の統合を参照してください。

Docker ⾃動インストールのためのクラスター・ノードの構成

インストール時にクラスター・ノードに Docker を⾃動的にインストールするように IBM Cloud Private をセットアップします。クラスター・ノードとは、マスター・ノード、プロキシー・ノード、ワーカー・ノード、脆弱性アドバイザー・ノード、および管理ノードのことです。

インストール中に、Docker は RHEL または Ubuntu のクラスター・ノードに⾃動的にインストールされます。クラスター・ノードへのインストールに使⽤される Docker パッケージは、ブート・ノードの /<installation_directory>/cluster/docker-engine フォルダーに置かれています。このプロセスは、どの


バージョンの Docker もインストールされていないノードに Docker をインストールします。 IBM Cloud Private でサポートされるバージョンの Docker がノードにインストール済みの場合、この⼿順をスキップできます。

SUSE Linux Enterprise Server (SLES) ノードの場合、SLES の資料にある Docker インストールの説明に従って、Docker を⼿動でインストールする必要があります。

クラスター・ノードへの Docker の⾃動インストールを許可するには、以下のようにします。

1. マスター・ノード、プロキシー・ノード、ワーカー・ノード、管理ノード、および VA ノードで、パッケージ・マネージャーがパッケージ更新を許可するように構成されていることを確認します。パッケージ・マネージャーには、RHEL ⽤の RPM および Ubuntu ⽤の Apt があります。

2. デフォルトの Docker ストレージ・ディレクトリーの場所を変更したい場合、IBM Cloud Private をインストールする前に、新ディレクトリーへのバインド・マウントを構成する必要があります。⾃動的にインストールされる Docker ⽤のデフォルト Docker ストレージ・ディレクトリーの指定を参照してください。

3. (オプション) マスター・ノード、プロキシー・ノード、ワーカー・ノード、管理ノード、および VA ノードで必要な Docker オプションを判別します。これらのオプションは config.yaml ファイルで指定します。

4. Red Hat Enterprise Linux (RHEL) システムの場合、提供される IBM Cloud Private Docker パッケージのストレージ・ドライバーは、デフォルトで devicemapper に設定されます。実稼働環境で devicemapper ストレージを使⽤するには、direct-lvm モードを有効にする必要があります。 direct-lvm モードは、Docker のインストール時に⾃動的に構成することも、Docker のインストール後に⼿動で構成することもできます。

提供される IBM Cloud Private Docker パッケージのインストール時に direct-lvm モードを構成するには、次のようにします。 IBM Cloud Private Docker をインストールする前に、構成オプションを /etc/docker/daemon.json ファイル内に設定する必要があります。構成オプションについて詳しくは、direct-lvm モード構成の表を参照してください。

構成は、以下のコードのようになります。

{ "storage-opts": [ "dm.directlvm_device=/dev/vdb", "dm.thinp_percent=95", "dm.thinp_metapercent=1", "dm.thinp_autoextend_threshold=80", "dm.thinp_autoextend_percent=20", "dm.directlvm_device_force=false" ] }

注: この構成は、Docker フレッシュ・インストールにのみ使⽤されます。また、このセットアップでは、単⼀ブロック・デバイスのみがサポートされます。

direct-lvm モードを⼿動で構成するには、Configure direct-lvm mode manually を参照してください。

⾼可⽤性 IBM® Cloud Private クラスター

IBM Cloud Private マスター・ノードおよびプロキシー・ノードに対して⾼可⽤性を構成できます。

マスター・ノードのみ、プロキシー・ノードのみ、あるいは、両⽅のタイプのノードに対して、⾼可⽤性を構成でき

ます。クラスターのインフラストラクチャー要件を減らすために、マスターとプロキシーの両⽅の役割を⾼可⽤性ノードに割り当てることができます。

注: パフォーマンスのリスクを軽減するには、複数のプロキシー・ノードと、3 個から 5 個のマスター・ノードを構成します。


https://www.suse.com/documentation/sles-12/singlehtml/book_sles_docker/book_sles_docker.html#cha.docker.installation

https://docs.docker.com/storage/storagedriver/device-mapper-driver/#allow-docker-to-configure-direct-lvm-mode

https://docs.docker.com/storage/storagedriver/device-mapper-driver/#configure-direct-lvm-mode-manually

すべてのマスター・ノードにわたる共有ストレージをセットアップする必要があります。このストレージは、IBMCloud Private クラスターの外部にある POSIX 準拠の共有ファイル・システムでなければなりません。ファイル・システムは、マスター・ノードからアクセス可能でなければなりません。この共有ストレージに以下のディレクトリーをマウントしてください。

/var/lib/registry - このディレクトリーは、プライベート・イメージ・レジストリーにイメージを保管するために使⽤されます。この共有イメージ・ディレクトリーは、これらのイメージがすべてのマスター・ノードで同期化された状態を保つために必要です。

/var/lib/icp/audit - このディレクトリーは、Kubernetes 監査ログを保管するのに使⽤します。監査ログは、IBM Cloud Private 使⽤に関連したデータを追跡および保管するために使⽤されます。/var/log/audit - このディレクトリーは、認証および許可の監査ログを保管するのに使⽤します。これらのログは、IBM Cloud Private クラスター内でトリガーされたイベントをトラッキングする際に使⽤します。

クラスター要件

これらの要件は、クラスターの⾼可⽤性のみを対象としています。プロキシーの⾼可⽤性は、クラスター・サイズの影響を受けません。

クラスターまたはマスターの⾼可⽤性には、3 個、5 個、または 7 個のマスター・ノードが必要です。クラスターでフォールト・トレランスを確保するには、この数のマスター・ノードが必要です。

クラスター内のマスターの数が N 個の場合、クラスターは最⼤ (N-1)/2 回の永続的な障害に耐えることができます。例えば、クラスター内に 3 個のマスターがあり、1 個のマスターがダウンした場合、フォールト・トレランスは (3-1)/2=1 と計算されます。フォールト・トレランスは 1 以上にする必要があります。

クラスター内のマスターの数は奇数でなければなりません。マスター・サイズが奇数の場合、マジョリティーに必要な数は変わりません。マジョリティーとは、クラスターが作動可能であるために必要なマスター・ノードの数です。ただし、マスター・ノードを追加すると、フォールト・トレランスは⾼くなります。表 1: HA クラスターのフォールト・トレランスに、偶数および奇数のクラスター・サイズがどのようにクラスターのフォールト・トレランスに

影響するかを⽰しています。

表 1. HA クラスターのフォールト・トレランスクラスター・サイズマジョリティーフォールト・トレランス

1 1 02 2 03 2 14 3 15 3 26 4 27 4 3

HA クラスターでのノード割り当ておよび通信

⾼可⽤性 (HA) IBM® Cloud Private クラスターでは、仮想 IP マネージャーがマスター・ノードおよびプロキシー・ノードの割り当てを管理します。

仮想 IP マネージャーは、どのノードがマスターおよびプロキシーの役割を担うのかを、仮想 IP アドレスをそれらのノードに割り当てることによって管理します。 IBM Cloud Private 内の仮想 IP マネージャーは、ネットワーク・インターフェース・コントローラー (NIC) を介してノード間の通信を容易にします。仮想 IP マネージャーは、cluster_vip IP アドレスを、使⽤可能なマスター・ノードに割り当て、proxy_vip IP アドレスを、使⽤可能なプロキシー・ノードに割り当てます。これらのノードは、先導マスター・ノードおよび先導プロキシー・ノードとして動作します。 cluster_vip IP アドレスは、vip_iface パラメーターで指定する NIC 上にある必要があります。同様に、proxy_vip IP アドレスは、proxy_vip_iface パラメーターで指定する NIC 上にある必要があります。


仮想 IP マネージャーは、クラスターのマスター・ノードおよびプロキシー・ノードの正常性をモニターします。先導マスター・ノードまたは先導プロキシー・ノードが使⽤可能でなくなった場合、仮想 IP マネージャーは、使⽤可能なノードを 1 つ選択し、そのノードに正しい仮想 IP アドレスを割り当てます。

IBM Cloud Private は仮想 IP マネージャーを通して⾼可⽤性を管理しますが、外部ロード・バランサーを使⽤することによって、マスター・ノードとプロキシー・ノードの負荷を分散し、外部通信を容易にすることもできます。ロード・バランサーを使⽤するには、インストール中に、ロード・バランサーの IP アドレスを config.yaml ファイル内の cluster_lb_address パラメーターおよび proxy_lb_address パラメーターの値として指定します。

ロード・バランサーを使⽤して、外部通信 (management console および API にアクセスすること、マスター・ノードおよびプロキシー・ノードに他の要求を⾏うことも含む) を容易にすることもできます。外部通信のためにロード・バランサーを使⽤する場合でも、内部通信を容易にするため、cluster_vip_iface、cluster_vip、proxy_vip、および proxy_vip の各パラメーターの値を設定する必要があります。 IBM Cloud Private の仮想 IP マネージャーは、これらのパラメーター値を使⽤して管理サービス間の内部通信 (例えば kubelet が kube-api サービスにアクセスするのを許可するための通信) を管理します。

インストール時の HA のセットアップについて詳しくは、HA インストール・オプションを参照してください。

モニタリング・サービスの構成

IBM® Cloud Private のインストール中にモニタリング・サービスをカスタマイズできます。

1. /<installation_directory>/cluster フォルダー内の config.yaml ファイルを開きます。

2. config.yaml ファイルに以下のコード⾏を追加します。

monitoring: prometheus: scrapeInterval: 1m evaluationInterval: 1m retention: 24h persistentVolume: enabled: false storageClass: "-" alertmanager: persistentVolume: enabled: false storageClass: "-" grafana: user: "admin" password: "admin" persistentVolume: enabled: false storageClass: "-"

3. 以下のパラメーターの値をカスタマイズします。

monitoring.prometheus セクションには、以下のパラメーターがあります。

prometheus.scrapeInterval は、Prometheus でターゲットを収集する頻度です。prometheus.evaluationInterval は、Prometheus でルールを評価する頻度です。prometheus.retention は、モニター・データを保持する期間です。prometheus.persistentVolume.enabled は、Prometheus の永続ボリュームを使⽤するように設定するフラグです。フラグ false は、永続ボリュームを使⽤しないことを意味します。prometheus.persistentVolume.storageClass は、Prometheus が使⽤するストレージ・クラスです。ストレージ・クラス・パラメーターを参照してください。

monitoring.alertmanager セクションには、以下のパラメーターがあります。


alertmanager.persistentVolume.enabled は、Alertmanager の永続ボリュームを使⽤するように設定するフラグです。フラグ false は、永続ボリュームを使⽤しないことを意味します。alertmanager.persistentVolume.storageClass は、Alertmanager が使⽤するストレージ・クラスです。ストレージ・クラス・パラメーターを参照してください。

monitoring.grafana セクションには、以下のパラメーターがあります。

grafana.user は、Grafana にアクセスするために使⽤するユーザー名です。grafana.password は、grafana.user パラメーターで指定されたユーザーのパスワードです。grafana.persistentVolume.enabled は、Grafana の永続ボリュームを使⽤するように設定するフラグです。フラグ false は、永続ボリュームを使⽤しないことを意味します。grafana.persistentVolume.storageClass は、Grafana が使⽤するストレージ・クラスです。ストレージ・クラス・パラメーターを参照してください。

4. config.yaml ファイルを保存して終了します。

ストレージ・クラス・パラメーター

storageClass パラメーター値は、モニター・サービスが使⽤するストレージ・クラスの名前です。

ストレージ・クラスを使⽤しない場合は - を⼊⼒します。データはコンテナー・ファイル・システム内で保管され、コンテナーが破損するとすべてのデータが失われます。

共有ストレージを使⽤する場合は、glusterfs などの、ストレージ・クラスの名前を⼊⼒します。共有ストレージを使⽤すると、コンテナーが破損してもデータは保持されます。このオプションを使⽤するには、ネットワーク・ストレージ・プロバイダーを構成する必要があります。ストレージを参照してください。

任意の有効な Kubernetes ストレージ・クラスを指定できます。 Kubernetes 資料のストレージ・クラスを参照してください。重要: IBM Cloud Private の⾼可⽤性インストールの場合は、共有ストレージを構成します。⾼可⽤性IBM® Cloud Private クラスターを参照してください。共有ストレージを構成しないと、先導マスターで障害が起こった場合にモニタリング・サービスがアクセス不能になる可能性があります。

GlusterFS ストレージの構成

IBM® Cloud Private クラスター内のワーカー・ノードで GlusterFS ストレージを構成します。そうすると、アプリケーション内のポッドは、この GlusterFS ストレージ・クラスターをデータ永続性のために使⽤できるようになります。

注: IBM Cloud Private 環境の外部で構成された GlusterFS サーバーを使⽤している場合は、IBM Cloud Private クラスターで GlusterFS を構成する必要はありません。 IBM Cloud Privateをインストールした後、GlusterFS 永続ボリュームを作成して使⽤することができます。 GlusterFS 永続ボリュームの作成について詳しくは、GlusterFS 永続ボリュームの作成を参照してください。

IBM® Cloud Private クラスター内に GlusterFS クラスターを構成する場合は、IBM® Cloud Private のインストール時または IBM Cloud Private のインストール後にそれを⾏うことができます。

IBM Cloud Private をインストールした後に GlusterFS ストレージを構成する⽅法について詳しくは、IBM CloudPrivate クラスター内の GlusterFS ストレージの構成を参照してください。

IBM Cloud Private のインストール時に GlusterFS ストレージを構成するには、以降のセクションで説明されている⼿順を実⾏してください。

前提条件

GlusterFS ストレージの構成およびボリュームの要求


https://kubernetes.io/docs/concepts/storage/storage-classes/

注: 前の IBM Cloud Private インストールで GlusterFS ストレージを構成した場合、IBM Cloud Private をアンインストールしてもディスクからデータは消去されません。再インストール⽤にワーカー・ノードを準備する⼿順については、IBM® Cloud Private の再インストールのための GlusterFS ワーカー・ノードの準備を参照してください。

マルチパス・ボリューム

GlusterFS のマルチパス・ボリュームを使⽤できます。

マルチパスのセットアップについて詳しくは、以下の資料を参照してください。

Ubuntu の場合、https://help.ubuntu.com/lts/serverguide/dm-multipath-chapter.html を参照してください。

RHEL の場合、https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/dm_multipath/index を参照してください。

暗号化ボリューム

GlusterFS の暗号化ボリュームを使⽤できます。暗号化ボリュームについて詳しくは、『dm-crypt を使⽤したボリュームの暗号化』を参照してください。

暗号化ボリュームは、/dev/mapper/<encrypted-volume-name> にあります。

前提条件

以下の前提条件が満たされていることを確認してください。前提条件が満たされていない場合、GlusterFS インストールが失敗したり、ワーカー・ノードの GlusterFS クラスターが不安定になったりする可能性があります。

少なくとも 3 つのワーカー・ノード上で、GlusterFS を使⽤したストレージ・プロビジョニングが構成される必要があります。

GlusterFS に使⽤されるストレージ・デバイスの容量は 25 GB 以上である必要があります。GlusterFS に使⽤されるストレージ・デバイスは未加⼯ディスクである必要があります。それらは、フォーマット済みであったり、パーティション化されていたり、ファイル・システム・ストレージ必要量を満たすため

に使⽤されたりしてはなりません。

シンボリック・リンク (symlink) を使⽤してストレージ・デバイスを識別する必要があります。システムが再始動するとデバイス名が変わる可能性があるため、/dev/sdb のようなデバイス名を使⽤しないでください。symlink を取得するには、以下の⼿順を実⾏します。

1. 使⽤するストレージ・デバイスを特定します。次のコマンドを⼊⼒することによって、使⽤可能なストレージ・デバイスをリストできます。

fdisk -l

出⼒は、以下の例のようになります。

root@icps-worker-4:~# fdisk -l Disk /dev/sdb: 48 GiB, 51539607552 bytes, 100663296 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/sda: 40 GiB, 42949672960 bytes, 83886080 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xe96e93a3


https://help.ubuntu.com/lts/serverguide/dm-multipath-chapter.html

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/dm_multipath/index

Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 7813119 7811072 3.7G 82 Linux swap / Solaris /dev/sda2 7815166 83884031 76068866 36.3G 5 Extended /dev/sda5 7815168 83884031 76068864 36.3G 83 Linux

注: マルチパス・デバイスまたは暗号化デバイスを使⽤している場合、該当するデバイスは、/dev/mapper/ にあります。

2. 25 GB 以上のストレージ容量を持つデバイスを識別します。この例では、デバイス /dev/sdb がこれに当たります。

3. wipefs コマンドを使⽤して、すべてのファイル・システム、raid、およびパーティション・テーブルのこん跡を消去します。例えば、デバイス /dev/sdb 上のこん跡を消去するには、次のコマンドを実⾏します。

sudo wipefs --all --force /dev/sdb

4. 次のコマンドを⼊⼒して、デバイスの symlink を取得します。

ls -altr /dev/disk/*

出⼒は、以下の例のようになります。

root@icps-worker-4:~# ls -altr /dev/disk/* /dev/disk/by-path: total 0 drwxr-xr-x 2 root root 160 Oct 23 02:34 . lrwxrwxrwx 1 root root 9 Oct 23 02:34 pci-0000:00:10.0-scsi-0:0:1:0 -> ../../sdb lrwxrwxrwx 1 root root 9 Oct 23 02:34 pci-0000:00:10.0-scsi-0:0:0:0 -> ../../sda lrwxrwxrwx 1 root root 9 Oct 23 02:34 pci-0000:02:01.0-ata-1 -> ../../sr0 drwxr-xr-x 6 root root 120 Oct 23 02:34 .. lrwxrwxrwx 1 root root 10 Oct 23 02:34 pci-0000:00:10.0-scsi-0:0:0:0-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Oct 23 02:34 pci-0000:00:10.0-scsi-0:0:0:0-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Oct 23 02:34 pci-0000:00:10.0-scsi-0:0:0:0-part5 -> ../../sda5 /dev/disk/by-id: total 0 drwxr-xr-x 2 root root 260 Oct 23 02:34 . lrwxrwxrwx 1 root root 9 Oct 23 02:34 wwn-0x6000c29ddc232994ce32cad1533c25e1 -> ../../sda lrwxrwxrwx 1 root root 9 Oct 23 02:34 wwn-0x6000c296507a2c4be3b79a74f921d283 -> ../../sdb lrwxrwxrwx 1 root root 9 Oct 23 02:34 scsi-36000c29ddc232994ce32cad1533c25e1 -> ../../sda lrwxrwxrwx 1 root root 9 Oct 23 02:34 scsi-36000c296507a2c4be3b79a74f921d283 -> ../../sdb lrwxrwxrwx 1 root root 9 Oct 23 02:34 ata-VMware_Virtual_SATA_CDRW_Drive_00000000000000000001 -> ../../sr0 drwxr-xr-x 6 root root 120 Oct 23 02:34 .. lrwxrwxrwx 1 root root 10 Oct 23 02:34 wwn-0x6000c29ddc232994ce32cad1533c25e1-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Oct 23 02:34 wwn-0x6000c29ddc232994ce32cad1533c25e1-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Oct 23 02:34 scsi-36000c29ddc232994ce32cad1533c25e1-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Oct 23 02:34 scsi-36000c29ddc232994ce32cad1533c25e1-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Oct 23 02:34 wwn-0x6000c29ddc232994ce32cad1533c25e1-part5 -> ../../sda5 lrwxrwxrwx 1 root root 10 Oct 23 02:34 scsi-36000c29ddc232994ce32cad1533c25e1-


part5 -> ../../sda5 /dev/disk/by-uuid: total 0 lrwxrwxrwx 1 root root 9 Oct 23 02:34 2017-02-15-20-36-22-00 -> ../../sr0 drwxr-xr-x 6 root root 120 Oct 23 02:34 .. drwxr-xr-x 2 root root 100 Oct 23 02:34 . lrwxrwxrwx 1 root root 10 Oct 23 02:34 6d48a0d5-846b-48d3-bb0f-a626bb49c916 -> ../../sda1 lrwxrwxrwx 1 root root 10 Oct 23 02:34 60f23142-a575-455d-8a99-6edca077d990 -> ../../sda5 /dev/disk/by-label: total 0 lrwxrwxrwx 1 root root 9 Oct 23 02:34 Ubuntu-Server\x2016.04.2\x20LTS\x20amd64 -> ../../sr0 drwxr-xr-x 6 root root 120 Oct 23 02:34 .. drwxr-xr-x 2 root root 60 Oct 23 02:34 . root@icps-worker-4:~#

デバイスの symlink のリンク・パスは、/dev/disk/by-path、/dev/disk/by-id、/dev/disk/by-uuid、または /dev/disk/by-label のいずれかになります。

5. symlink とリンク・パスをメモします。例えば、デバイス sdb の場合、リンク・パスは /dev/disk/by-path であり、symlink は pci-0000:00:10.0-scsi-0:0:1:0 です。 GlusterFS 構成に使⽤しようとしているデバイスごとに、config.yaml ファイル内で <link path>/<symlink> を追加する必要があります。例のデバイス sdb の場合、config.yaml ファイル内で /dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:1:0 を追加します。

GlusterFS ストレージの構成およびボリュームの要求

GlusterFS ストレージを IBM Cloud Private で使⽤するには、以下の⼀連のタスクを実⾏します。

ノードの準備

GlusterFS ストレージの構成GlusterFS ボリュームの要求

サンプル構成については、GlusterFS 構成例を参照してください。

ノードの準備

クラスター内のワーカー・ノードごとに、このステップを実⾏します。また、GlusterFS ボリュームを使⽤する可能性のあるクラスター内の他のノードでも、このステップを実⾏する必要があります。

1. GlusterFS 分散ファイル・システムに参加するように各ホストを構成します。

1. 各ノード上で、GlusterFS クライアントをインストールし、dm_thin_pool カーネル・モジュールを構成します。以下のコマンドを⼊⼒します。

Ubuntu では、以下のコマンドを実⾏します。

sudo apt-get update

sudo apt-get install glusterfs-client

sudo modprobe dm_thin_pool

Red Hat Enterprise Linux (RHEL) では、以下のコマンドを実⾏します。

sudo yum install glusterfs-client



RHEL Linux® on Power® (ppc64le) では、まずリポジトリーを作成し、次に GlusterFS クライアントをインストールします。

1. リポジトリーを作成します。

[centos-gluster312] name=CentOS-$releasever - Gluster 3.12 baseurl=https://buildlogs.centos.org/centos/7/storage/$basearch/gluster-3.12/ gpgcheck=0 enabled=1

2. GlusterFS クライアントをインストールします。


3. dm_thin_pool カーネル・モジュールを構成します。


2. カーネル・モジュールのロードがリブートをまたがって持続することを確実にするため、dm_thin_pool モジュール名を modules ファイルに追加します。

Ubuntu では、次のコマンドを実⾏します。

echo dm_thin_pool | sudo tee -a /etc/modules

RHEL では、次のコマンドを実⾏します。

echo dm_thin_pool | sudo tee -a /etc/modules-load.d/dm_thin_pool.conf

変更が正しく保存された場合、コマンドは以下の出⼒を返します。

dm_thin_pool

2. 以下のポートがオープンしているが、どのサービスでも使⽤されていないことを確認します。

表 1. GlusterFS ポートポート使⽤法

24007 GlusterFS デーモン24008 GlusterFS 管理2222 sshd (GlusterFS がポッドで実⾏されている場合に使⽤される)49152:49251ボリューム内の各ブリックの TCP ポート

コマンド netstat -an | grep <port number> | grep -i listen を使⽤して、ポートがオープンしているかどうかを確認できます。このコマンドで出⼒が返される場合、ポートがオープンしているが、使⽤中であることを意味します。ポートを使⽤しているサービスを停⽌してください。


GlusterFS ボリュームを構成するには、/<installation_directory>/cluster フォルダー内の config.yaml ファイルを更新する必要があります。この更新には、ワーカー・ノードおよびそれらのデバイスに関する情報が含まれ、また、オプションでストレージ・クラス構成に関する情報が含まれます。

config.yaml ファイルを編集します。

1. glusterfs: true を⼊⼒します。2. ワーカー・ノードおよびデバイスのリストを含んでいる Storage Configuration セクションを追加します。 1 つのワーカー・ノードで複数のデバイスを追加できます。


以下のコード例は、config.yaml ファイルへの変更を⽰します。

glusterfs: true # Storage Configuration storage: - kind: glusterfs nodes: - ip: <worker_node_m_IP_address> device: <link path>/<symlink of device aaa>,<link path>/<symlink of device bbb> - ip: <worker_node_n_IP_address> device: <link path>/<symlink of device ccc> - ip: <worker_node_o_IP_address> device: <link path>/<symlink of device ddd> storage_class: default: false volumetype: replicate:3 name:

各部の意味は次のとおりです。

ip は、GlusterFS をデプロイするワーカー・ノードの IP アドレスです。少なくとも 3 つのワーカー・ノードを追加する必要があります。

device は、ストレージ・デバイスの symlink への絶対パスです。

注: デバイス名を追加しないでください。 symlink を追加してください。

storage_class は、GlusterFS ⽤のストレージ・クラスを作成します。

default は、デフォルト・ストレージ・クラスとして GlusterFS を構成するオプションです。デフォルト値は false です。このストレージ・クラスをデフォルトにしたい場合は、true と指定します。volumetype は、ボリュームの構成パラメーターです。この値を replicate:3 に設定すると、カウント 3 のレプリカ・ボリュームが作成されます。有効なパラメーター値は none、replicate:<replicate_count>、disperse:<data>:<redundancy_count> です。ボリューム・タイプが指定されていない場合、プロビジョナーによってボリューム・タイプが replicate:3 に設定されます。

name は、ストレージ・クラス名です。デフォルト値は none です。ストレージ・クラス名はKubernetes 命名規則 (最⼤ 253 ⽂字で、⼩⽂字の英数字、-、および . のみを使⽤) に準拠していなければなりません。名前を指定すると、IBM Cloud Private インストーラーは、指定された名前のデフォルト・ストレージ・クラスを作成します。この時点でストレージ・クラスを作成したくない場合は、名前を指定しないでください。

注: 後でいつでも、GlusterFS ストレージを使⽤するためのストレージ・クラスをさらに作成することができます。 GlusterFS ⽤のストレージ・クラスの作成を参照してください。

GlusterFS ボリュームの要求

IBM Cloud Private をインストールした後、PersistentVolumeClaim (PVC) を使⽤して、IBM Cloud Private クラスター内のワーカー・ノードに構成された GlusterFS ボリュームを要求できます。 PVC の作成について詳しくは、「リソースの作成」ウィンドウを使⽤した PersistentVolumeClaim の作成を参照してください。

GlusterFS ボリュームの PVC は最⼤ 100 個まで作成できます。

GlusterFS 構成例



以下の構成例では、3 つのワーカー・ノードがあり、それらのノードには、リンク・パスが /dev/disk/by-path のデバイスがあります。この例では、scdefaultgluster という名前のデフォルト・ストレージ・クラスも構成されています。

glusterfs: true ## GlusterFS Storage Settings storage: - kind: glusterfs nodes: - ip: 192.168.0.126 device: /dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:1:0 - ip: 192.168.0.129 device: /dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:1:0 - ip: 192.168.0.89 device: /dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:1:0 storage_class: name: scdefaultgluster volumetype: replicate:3 default: true

IBM Cloud Private をインストールした後、コマンド kubectl describe sc <storage class name> を使⽤して、ストレージ・クラスが作成されたかどうかを検証できます。例えば、上の構成例で作成されるストレージ・クラスの場合、コマンド kubectl describe sc scdefaultgluster をマスター・ノードから実⾏すると、出⼒は以下のようになります。

Name: scdefaultgluster IsDefaultClass: Yes Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{"storageclass.beta.kubernetes.io/is-default-class":"true"},"name":"scdefaultgluster","namespace":""},"parameters":{"resturl":"http://10.0.0.209:8080","restuser":"admin","secretName":"heketi-secret","secretNamespace":"kube-system","volumetype":"none"},"provisioner":"kubernetes.io/glusterfs"} ,storageclass.beta.kubernetes.io/is-default-class=true Provisioner: kubernetes.io/glusterfs Parameters: resturl=http://10.0.0.209:8080,restuser=admin,secretName=heketi-secret,secretNamespace=kube-system,volumetype=none ReclaimPolicy: Delete VolumeBindingMode: Immediate Events: <none>

ここで、10.0.0.209 は、Heketi サービス・クラスター IP アドレスであり、8080 は Heketi サービス・ポートです。

GlusterFS PersistentVolume (PV) が作成されたかどうかを検証するには、コマンド kubectl describe pv を使⽤します。このコマンドは、クラスター内のすべての PV をリストします。

GlusterFS ボリュームの要求

以下に、GlusterFS ボリュームを要求するための PVC の YAML 構成の例を⽰します。

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: glusterpvc spec: accessModes: - ReadWriteOnce resources: requests:


storage: 1Gi storageClassName: scdefaultgluster

vSphere クラウド・プロバイダーの構成

vSphere クラウド・プロバイダーを使⽤して、ポッドがスケジュールされているノードにマウントされた vSphere 永続ボリュームにデータを保管できます。ポッドが削除された場合、ボリュームはアンマウントされ、データは持続します。ポッドのスケジュールが変更された場合、vSphere クラウド・プロバイダーは、ボリュームをノードからデタッチし、ポッドがスケジュール変更されたノードにアタッチします。

注: vSphere クラウド・プロバイダーは、永続ボリュームに対して ReadWriteOnce アクセス・モードのみをサポートします。

前提条件

クラスター内のノードが以下の要件を満たしていることを確認してください。

VM ハードウェア・バージョンは、バージョン 13 より前のバージョンでなければなりません。すべての IBM® Cloud Private クラスター・ノードが 1 つの vSphere VM フォルダーの下にある必要があります。

すべての IBM Cloud Private マスター・ノードが vCenter にアクセスできる必要があります。ノード・ホスト名は VM 名と同じである必要があります。ノード・ホスト名は、正規表現 (regex) のガイドラインに準拠していなければならず、以下の追加の制約事項を満たしている必要もあります。

以下の regex に準拠している必要があります。 [a-z](([-0-9a-z]+)?[0-9a-z])?(\.[a-z0-9](([-0-9a-z]+)?[0-9a-z])?)*先頭が数字であってはなりません。

⼤⽂字を使⽤してはなりません。

「.」および「-」以外の特殊⽂字を使⽤してはなりません。3 ⽂字以上、63 ⽂字以下でなければなりません。

ノード VM 上でディスク UUID が使⽤可能になっている必要があります。つまり、「disk.EnableUUID」値が「True」に設定されている必要があります。vSphere クラウド構成に指定されているユーザーは vCenter と対話できる特権を持っている必要があります。

表 1. vSphere クラウド・プロバイダーのユーザー

役割特権エンティティー⼦への

伝搬


役割特権エンティティー⼦への

伝搬

manage-k8s-node-vms Resource.AssignVMToPoolSystem.AnonymousSystem.ReadSystem.ViewVirtualMachine.Config.AddExistingDiskVirtualMachine.Config.AddNewDiskVirtualMachine.Config.AddRemoveDeviceVirtualMachine.Config.RemoveDiskVirtualMachine.Inventory.CreateVirtualMachine.Inventory.Delete

クラスター

ホスト

VM フォルダー

はい

manage-k8s-volumes Datastore.AllocateSpaceDatastore.FileManagementSystem.AnonymousSystem.ReadSystem.View

データ・ストアいいえ

k8s-system-read-and-spbm-profile-view

StorageProfile.ViewSystem.AnonymousSystem.ReadSystem.View

vCenter いいえ

ReadOnly System.AnonymousSystem.ReadSystem.View

データ・センター

データ・ストア・クラスター

データ・ストア・ストレー

ジ・フォルダー

いいえ

ソース: https://v1-10.docs.kubernetes.io/docs/getting-started-guides/vsphere/

vSphere クラウド・プロバイダーの構成

vSphere クラウド・プロバイダーを構成するには、以下の⼿順を実⾏します。

1. 「/ /cluster」フォルダー内の「config.yaml」ファイルを開きます。2. 「config.yaml」ファイルに以下のコード⾏を追加します。

kubelet_nodename: hostname cloud_provider: vsphere vsphere_conf: user: "<vCenter username for vSphere Cloud Provider>" password: "<password for vCenter user>" server: <vCenter server IP or FQDN> port: [vCenter Server Port; default: 443] insecure_flag: [set to 1 if vCenter uses a self-signed certificate] datacenter: <datacenter name on which Node VMs are deployed> datastore: <default datastore to be used for provisioning volumes> working_dir: <vCenter VM folder path in which node VMs are located>



https://v1-10.docs.kubernetes.io/docs/getting-started-guides/vsphere/

kubelet_nodename: 「hostname」に設定する必要があります。cloud_provider: 「vsphere」に設定する必要があります。user: vCenter のユーザ名。すべての vCenter 操作は、このユーザーの資格情報を使⽤して実⾏されます。password: 「user」パラメーターで指定されたユーザーのパスワード。server: vCenter サーバーの IP アドレスまたは完全修飾ドメイン・ネーム (FQDN)。port: vCenter をセットアップするために使⽤されるポート番号。デフォルト値は「443」です。insecure_flag: vCenter が⾃⼰署名証明書を使⽤する場合は「1」に設定します。datacenter: ノード VM がデプロイされているデータ・センターの名前。datastore: ストレージ・クラスを使⽤して作成される永続ボリュームを配置するのに使⽤されるデータ・ストアの名前。データ・ストアがフォルダー内に置かれていたり、データ・ストア・クラスターのメンバーであったりする場合でも、単に名前を指定します。データ・ストア名は⼤⽂字⼩⽂字が区別されます。working_dir: vCenter 内のノード VM が置かれているフォルダー名またはパス。フォルダー名またはパスは⼤⽂字⼩⽂字が区別されます。

ノード VM がルート・フォルダー内にある場合、「working_dir: ""」と設定します。ノード VM がルート・フォルダーの下のフォルダー内にある場合、「working_dir: Folder1_name」の形式でパスを設定します。

ノード VM がルート・フォルダーの下のネストされたフォルダー内にある場合、「working_dir:Folder1_name/Folder2_name」の形式でパスを設定します。

次の作業

IBM Cloud Private のインストールを続⾏します。

IBM Cloud Private をインストールした後、vSphere ストレージを使⽤するためのストレージ・クラスを作成します。⼿順については、『vSphere ボリューム⽤のストレージ・クラスの作成』を参照してください。

ストレージの動的プロビジョニング

動的プロビジョニングは、ストレージ・ボリュームがオンデマンドで作成されることを可能にします。ストレージ・クラスを使⽤してボリュームをプロビジョンします。

IBM® Cloud Private でのストレージ・クラスについて詳しくは、ストレージ・クラスの作成を参照してください。


IBM Cloud Private のインストール中にストレージ・クラスを作成できます。インストール完了後、ストレージ・クラスは作成されていて、ストレージの動的プロビジョニングに使⽤できます。

注: Kubernetes ストレージ・クラスのみがサポートされています。

以下の⼿順を実⾏して、ストレージ・クラス定義ファイルを作成します。

1. ストレージ・クラス定義を含む YAML ファイルを作成します。ストレージ・クラス定義について詳しくは、Kubernetes 資料を参照してください。

2. YAML ファイルを /<installation_directory>/cluster/misc/storage_class フォルダーに保存します。

注: 他のファイルを /misc/storage_class ロケーションに置かないでください。 IBM Cloud Private インストーラーは、このディレクトリーからストレージ・クラス YAML ファイルのみを取り出し、他のファイルはすべて無視します。


IPsec を使⽤したクラスター・データ・ネットワーク・トラフィックの暗号化

IBM® Cloud Private クラスターにおいて、ノード間のすべてのデータ・プレーン・ネットワーク・トラフィックを暗号化します。

前提条件

クラスター内の各ノードに 2 つ以上のネットワーク・インターフェースがある必要があります。 1 つは管理インターフェースであり、もう 1 つのインターフェースはポッド⽤のセキュアなネットワーキングを提供します。ネットワーク・インターフェース名は⽂字列 "docker.*"、"cbr.*"、"dummy.*"、"virbr.*"、"lxcbr.*"、"veth.*"、"lo"、"cali.*"、"tunl.*"、および "flannel.*" を含んでいてはなりません。Calico ネットワークが IP over IP モードで有効にされている必要があります。strongSwan パッケージの場所をポイントするリポジトリーがクラスター内のすべてのノードでセットアップされていることを確認してください。このパッケージは、IPsec を使⽤したデータ・ネットワーク・トラフィックの暗号化を有効にするために必須です。

クラスター・データ・ネットワーク・トラフィックの暗号化を有効にする

デフォルトでは、IBM Cloud Private クラスター内では暗号化は無効にされます。

暗号化を有効にするには、以下のタスクを実⾏します。

1. config.yaml ファイル内に以下のパラメーターがあることを確認します。これらのパラメーターについて詳しくは、ネットワーク設定を参照してください。

network_type: calicocalico_ipip_enabled: truecalico_ip_autodetection_method: interface=<data network interface>

calico_tunnel_mtu: 1390

注: calico_tunnel_mtu には、Calico IP-in-IP (20 バイト) + IPsec ヘッダー (40 バイト) = 60 バイトに対応できるような値を設定してください。 Calico トンネル MTU 値は、データ・プレーン・インターフェース MTU サイズに⽐べて 60 バイト以上少ない値でなければなりません。

2. config.yaml ファイルに以下の構成データを追加します。

# IPsec mesh configuration # If user wants to configure IPsec mesh, the following parameters # should be configured through config.yaml ipsec_mesh: # To enable IPsec feature enable: true # The interface for which the IPsec should be enabled. interface: <interface name on which IPsec will be enabled> # List of subnets for which the IPsec should be enabled subnets: [] # List of IPs to be excluded from IPsec subnet exclude_ips: "<list of IP addresses separated by a comma>"


enable は、データ・プレーン・トラフィックの暗号化を有効または無効にするために使⽤されます。暗号化を有効にするには、true に設定します。デフォルト値は false です。


interface は、IPsec インターフェースです。このインターフェースは、calico_ip_autodetection_method パラメーターに設定されているのと同じインターフェースでなければなりません。

subnets は、ワークロード⽤に使⽤されるインターフェースのネットワーク・アドレスです。サブネット・アドレスは CIDR 形式 [a.b.c.d/n] で指定する必要があります。必要な場合、複数のサブネットをコンマで区切ってリストします ([a.b.c.d/n, l.m.n.o/p])。exclude_ips は、IPsec サブネットから除外される IP アドレスです。これらの IP アドレスへのトラフィックは暗号化されません。これはオプション・パラメーターです。

IPsec 証明書および鍵

IBM Cloud Private における IPsec 実装では、クラスター内の 2 つのノード間の相互認証のために Internet KeyExchange (IKE) が使⽤されます。

認証のために、各ノードは、信頼できる機関によって署名されたデジタル証明書と、そのデジタル証明書⽤の秘密鍵

を保有します。

これらの証明書および鍵は、IBM Cloud Private のインストール中に⽣成されます。

ユーザー独⾃の証明書および鍵の使⽤

デフォルトの証明書および鍵を独⾃のものに置き換えることができます。以下のファイルの準備ができていることを確認してください。

認証局 (CA) ファイル。ファイル名の例: example-ca.crt証明書ファイル。ファイル名の例: example-cert.crt秘密鍵ファイル。ファイル名の例: example-private.key

クラスター内のすべてのノードで以下のステップを実⾏します。


1. CA ファイルを /etc/ipsec.d/cacerts/ フォルダーに⼊れます。2. 証明書ファイルを /etc/ipsec.d/certs/ フォルダーに⼊れます。3. 秘密鍵ファイルを /etc/ipsec.d/private/ フォルダーに⼊れます。4. /etc/ipsec.conf ファイル内の証明書ファイル名 leftcert="example-cert.crt" を置き換えます。

5. /etc/ipsec.secrets ファイル内の秘密鍵ファイル名を置き換えます。鍵ファイル名 example-private.key を更新します。

6. strongSwan サービスを再始動します。

service strongswan restart

Red Hat Enterprise Linux では、以下のコマンドを実⾏します。

1. CA ファイルを /etc/strongswan/ipsec.d/cacerts/ フォルダーに⼊れます。2. 証明書ファイルを /etc/strongswan/ipsec.d/certs/ フォルダーに⼊れます。3. 秘密鍵ファイルを /etc/strongswan/ipsec.d/private/ フォルダーに⼊れます。4. /etc/strongswan/ipsec.conf ファイル内の証明書ファイル名 leftcert="example-cert.crt"を置き換えます。

5. /etc/strongswan/ipsec.secrets ファイル内の秘密鍵ファイル名を置き換えます。鍵ファイル名 example-private.key を更新します。

6. strongSwan サービスを再始動します。

service strongswan restart


IBM® Cloud Private サービス⽤の独⾃の認証局 (CA) の指定

プライベート・イメージ・レジストリーおよび IBM Cloud Private ルーターの認証に使⽤される独⾃の認証局 (CA) を提供します。

新しい認証局 (CA) を作成することも、既存の認証局 (CA) を使⽤することもできます。

新しい認証局 (CA) の作成

1. 証明書を作成します。

例えば、ドメイン・ネームが mydomain.icp の⾃⼰署名証明書を作成するには、次のコマンドを実⾏します。

openssl req -x509 -nodes -sha256 -subj "/CN=mydomain.icp" -days 36500 \ -newkey rsa:2048 -keyout icp-auth.key -out icp-auth.crt

このコマンドによって、現⾏作業ディレクトリー内に icp-auth.key と icp-auth.crt という 2 つの証明書が作成されます。

2. これらの証明書を IBM Cloud Private インストール・ディレクトリーにコピーします。

mkdir <installation_dir>/cluster/cfc-certs cp icp-auth.crt icp-auth.key <installation_dir>/cluster/cfc-certs/

3. <installation_dir>/cluster/config.yaml ファイル内に CA ドメイン・パラメーターを設定します。

cluster_CA_domain: mydomain.icp

4. クラスターをインストールします。

既存の認証局 (CA) の使⽤ - (BYOK)

BYOK (Bring Your Own Key) を IBM Cloud Private クラスター内部で使⽤できます。

1. cluster ディレクトリー内に cfc-certs ディレクトリーおよび cfc-keys ディレクトリーを作成します。

mkdir <installation_dir>/cluster/cfc-certs

2. 既存の BYOK を icp-auth.key に名前変更し、この鍵ファイルをインストール・ディレクトリーにコピーします。

mv <BYOK_location>/<BYOK> icp-auth.key cp icp-auth.key <installation_dir>/cluster/cfc-certs/

3. BYOK ⽤の既存の証明書を icp-auth.crt に名前変更し、この証明書ファイルをインストール・ディレクトリーにコピーします。

mv <BYOK_location>/<BYOK_cert> icp-auth.crt cp icp-auth.crt <installation_dir>/cluster/cfc-certs/

4. <installation_dir>/cluster/config.yaml ファイル内の CA ドメイン・パラメーターを BYOK の CN 名に設定します。

cluster_CA_domain: <cn_name_BYOK>

5. クラスターをインストールします。


dm-crypt を使⽤したボリュームの暗号化

ボリュームを暗号化します。

dm-crypt は、ブロック・デバイスの透過暗号化を提供します。デバイスをマウントした直後にデータにアクセスできます。 dm-crypt について詳しくは、https://wiki.archlinux.org/index.php/dm-crypt を参照してください。

dm-crypt を使⽤してボリュームを暗号化し、パスフレーズまたは鍵ファイルを使⽤してボリュームを暗号化解除することができます。鍵ファイルは、システムの再始動時に指定できます。

IBM® Cloud Private のストレージ・ディレクトリー

IBM Cloud Private では、dm-crypt を使⽤して、以下の場所に保管される保存データを暗号化できます。

Kubernetes キー/値ストア: /var/lib/etcdKubernetes 監査: /var/lib/icp/auditMongoDB: /var/lib/icp/mongodbHelm リポジトリー: /var/lib/icp/helmrepo脆弱性アドバイザー (VA): /var/lib/icp/vaイメージ・マネージャーの永続ボリューム: /var/lib/registry証明書および鍵: /etc/cfcMariaDB: /var/lib/mysqlライセンス: /opt/ibm/cfc/licenseソフトウェア ID タグ: /opt/ibm/cfc/swidtagロギング⽤の永続ボリューム: /var/lib/icp/logging/elasticsearchPrometheus ⽤の永続ボリューム: <installation_directory>/dirforPrometheusServerAlertManager ⽤の永続ボリューム: <installation_directory>/dirforAlertManagerGrafana ⽤の永続ボリューム: <installation_directory>/dirforGrafanaIBM Cloud Private 構成: <installation_directory>/cluster

上記のリストにあるストレージ・ロケーションを保護するために、以下のディレクトリーを暗号化できます。

/var/lib/etcd/var/lib/icp/var/lib/registry/var/lib/mysql/etc/cfc/opt/ibm<installation_directory>注: /opt/ibm をインストール・ディレクトリーとして使⽤できます。

これらのディレクトリーのディスク・スペース所要量について詳しくは、『ディスク・スペース所要量』を参照して

ください。

ディレクトリーの暗号化

以下の⼿順に従ってディレクトリーを暗号化する必要があります。 /var/lib/etcd データ・ストアを暗号化するステップを、例として⽰しています。下記のステップに従って、任意のディレクトリーを暗号化できます。

前提条件

以下のパッケージが IBM Cloud Private クラスターのすべてのノードにインストールされていることを確認します。

Red Hat Enterprise Linux (RHEL) では、以下のパッケージがインストールされている必要があります。


https://wiki.archlinux.org/index.php/dm-crypt

cryptsetupdevice-mapper

util-linux

これらのパッケージがインストールされていない場合は、root ユーザーとして以下のコマンドを実⾏してインストールします。

yum install cryptsetup-luks

Ubuntu では、以下のパッケージがインストールされている必要があります。

cryptsetuplibdevmapper1

util-linux

これらのパッケージがインストールされていない場合は、root ユーザーとして以下のコマンドを実⾏してインストールします。

apt-get install cryptsetup

ボリュームの暗号化

root ユーザーとして以下のコマンドを実⾏してください。

1. 暗号化されたデータを保管するよう論理ボリューム管理 (LVM) を構成します。

1. 物理ボリュームを作成します。

pvcreate <full path and name of the physical volume>

以下はコマンドと出⼒の例です。

pvcreate /dev/sda1 Physical volume "/dev/sda1" successfully created.

2. ボリューム・グループを作成します。

vgcreate <name of the volume group> <full path to the physical volume>


vgcreate etcdvg /dev/sda1 Volume group "etcdvg" successfully created.

3. 論理ボリュームを作成します。

lvcreate -L <amount of space required> <name of the volume group> -n <name of the logical volume>


lvcreate -L4G etcdvg -n etcd Logical volume "etcd" created.

2. ボリューム内に dm-crypt LUKS コンテナーを作成します。cryptsetup -y luksFormat <full path to the logical volume>

暗号化解除にパスフレーズを使⽤する場合は、ここで指定できます。

コマンドおよび出⼒の例は次のとおりです。


cryptsetup -y luksFormat /dev/etcdvg/etcd WARNING! ======== This will overwrite data on /dev/etcdvg/etcd irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase:

3. LUKS コンテナーを開き、論理ボリュームをパスにマップします。

cryptsetup luksOpen <full path to the logical volume> <name of the logical volume>


cryptsetup luksOpen /dev/etcdvg/etcd etcd Enter passphrase for /dev/etcdvg/etcd:

4. 論理ボリューム上にファイル・システムを作成します。任意のファイル・システムを使⽤できます。以下のコマンドは、XFS ファイル・システムを使⽤するためのものです。

mkfs.xfs /dev/mapper/<name of the logical volume>


mkfs.xfs /dev/mapper/etcd meta-data=/dev/mapper/etcd isize=512 agcount=4, agsize=262016 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0, sparse=0 data = bsize=4096 blocks=1048064, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0

5. ファイル・システムをマウントするマウント・ロケーションを作成します。

mkdir <mount location>


mkdir /var/lib/etcd

6. ファイル・システムをマウントします。

mount /dev/mapper/<name of the logical volume> <mount location>

コマンドの例を以下に⽰します。

mount /dev/mapper/etcd /var/lib/etcd

システムの再始動と再始動の間に⾃動的にマウントするには、/etc/crypttab ファイルおよび /etc/fstabファイルに以下の⾏を追加します。

/etc/crypttab ファイルに次の⾏を追加します。

<name of the volume group> <full path to the logical volume> {none|<absolute_path_to_keyfile>} luks

ここで、暗号化解除にパスフレーズを使⽤した場合は none を追加し、暗号化解除に鍵ファイルを使⽤した場合は鍵ファイルへの絶対パスを追加します。


以下にサンプル・コードを⽰します。

etcd /dev/etcdvg/etcd none luks

/etc/fstab ファイルに次の⾏を追加します。

/dev/mapper/<name of the logical volume> <full path to the volume group> xfs defaults 0 2

以下にサンプル・コードを⽰します。

/dev/mapper/etcd /var/lib/etcd xfs defaults 0 2

次に、IBM Cloud Private のインストールを続⾏します。

VMware NSX-T 2.0 と IBM® Cloud Private の統合

VMware NSX-T 2.0 (以降は NSX-T と記述) は、IBM Cloud Private クラスターにネットワーキング機能を提供します。

注: IBM Cloud Private クラスターに NSX-T を構成した場合、クラスターからワーカー・ノードを削除しても、OpenvSwitch (OVS) ブリッジからポートおよびフローは削除されません。ワーカー・ノードをクラスターに再び追加する前に、ブリッジからポートおよびフローをクリアする必要があります。ポートおよびフローをクリアするには、br-int ブリッジを削除し、NSX-T と IBM Cloud Private クラスター・ノードの統合を⾏うときにこのブリッジを再度追加します。

IBM Cloud Private をアンインストールする場合は、NSX-T マネージャーからクラスター関連項⽬ (ファイアウォール・ルール、スイッチ、ティア-1 ルーターなど) を削除する必要があります。

サポートされるオペレーティング・システム

NSX-T と Kubernetes の統合は以下のオペレーティング・システムでサポートされます。

Ubuntu 16.04Red Hat Enterprise Linux™ (RHEL) 7.3 のみ

サポートされる Kubernetes バージョン

IBM Cloud Private 2.1.0.3 は Kubernetes 1.10.0 を使⽤します。 VMware NSX-T 2.0 は Kubernetes バージョン 1.6.xをサポートします。それでも NSX-T と IBM Cloud Private を統合することができます。ただし、ネットワーク・ポリシーは、Kubernetes バージョン 1.6.x でサポートされる範囲で適⽤可能です。詳しくは、『Network Policies 』を参照してください。

NSX-T と IBM Cloud Private クラスター・ノードの統合

1. VMware vSphere 環境に NSX-T をインストールします。 NSX-T について詳しくは、資料「NSX-T InstallationGuide 」を参照してください。

2. IBM Cloud Private クラスター⽤の NSX-T リソースを構成します。詳しくは、VMware の資料を参照してください。

注: タグ {'ncp/cluster': '<cluster_name>'} を設定するときには、IBM Cloud Private クラスター名を使⽤してください。 <installation_directory>/cluster/config.yaml ファイル内で設定する cluster_name を使⽤します。デフォルト値は mycluster です。

注: IP Blocks for Kubernetes Pods セクションを構成するときには、<installation_directory>/cluster/config.yaml ファイル内で network_cidr として設定する IP ブ


https://v1-6.docs.kubernetes.io/docs/concepts/services-networking/network-policies/

https://docs.vmware.com/en/VMware-NSX-T/2.0/com.vmware.nsxt.install.doc/GUID-3E0C4CEC-D593-4395-84C4-150CD6285963.html

https://docs.vmware.com/en/VMware-NSX-T/2.0/com.vmware.nsxt.ncp_kubernetes.doc/GUID-49D7630F-AEB1-4443-BDE0-8788E4415647.html

ロックを使⽤してください。

3. クラスター内の各ノードで NSX-T CNI (コンテナー・ネットワーク・インターフェース) プラグイン・パッケージをインストールします。詳しくは、VMware の資料を参照してください。

4. クラスター内の各ノードで Open vSwitch (OVS) をインストールし、構成します。詳しくは、VMware の資料を参照してください。

注: 割り当てられた ofport が 1 ではない場合、IBM Cloud Private 構成ファイルを準備するときに、config.yaml ファイルに ovs_uplink_port を必ず追加してください。

5. クラスター内の各ノードで NSX-T ネットワーキングを構成します。ノードでの NSX-T の構成について詳しくは、VMware の資料を参照してください。論理スイッチ・ポートをタグ付けする場合、必ず以下のパラメーター値を使⽤してください。

{'ncp/node_name': '<node_name>'}: <installation_directory>/cluster/config.yamlファイル内に kubelet_nodename: hostname を構成した場合、ノードのホスト名を <node_name>パラメーター値として追加します。ノードのホスト名は次のコマンドを使⽤して取得できます。

hostname -s

<installation_directory>/cluster/config.yaml ファイル内に kubelet_nodename: hostname を構成しなかった場合、ノードの IP アドレスを <node_name> パラメーター値として追加します。 IBM Cloud Private クラスター・ノードの IP アドレスは <installation_directory>/cluster/hosts ファイルから取得できます。

{'ncp/cluster': '<cluster_name>'}: <installation_directory>/cluster/config.yamlファイル内で設定する cluster_name を使⽤します。デフォルト値は mycluster です。

IBM Cloud Private 構成ファイルの準備

構成ファイルを準備するには、以下のステップを実⾏します。

1. images ディレクトリーがまだない場合は、<installation_directory>/cluster/ フォルダーの下に作成します。

2. NSX-T Docker コンテナー .tar ファイルをダウンロードして <installation_directory>/cluster/images フォルダーにコピーします。

3. <installation_directory>/cluster/config.yaml ファイルに以下のコードを追加します。

注: 1 つの IBM Cloud Private クラスターに対して使⽤可能にできるネットワーク・タイプは、常に 1 つのみです。以下のコードで⽰されているように network_type: nsx-t を使⽤可能にする場合、config.yaml ファイルからデフォルト network_type: calico 設定を必ず削除してください。

network_type: nsx-t # NSX-T configuration nsx_t: managers: <hostname>[:port], <hostname>[:port] manager_user: <user name for NSX-T manager> manager_password: <password for NSX-T manager user> manager_ca_cert: | -----BEGIN CERTIFICATE----- MIIDYzCCAkugAwIBAgIEcK9gWjANBgsedkiG9w0BAQsFADBiMQswCQYDVQQGEwJV .......................................... .......................................... .......................................... hzYlaog68RTAQpkV0bwedxq8lizEBADCgderTw99OUgt+xVybTFtHume8JOd+1qt G3/WlLwiH9upSujL76cEG/ERkPR5SpGZhg37aK/ovLGTtCuAnQndtM5jVMKoNDl1 /UOKWe1wrT==


https://docs.vmware.com/en/VMware-NSX-T/2.0/com.vmware.nsxt.ncp_kubernetes.doc/GUID-6AFA724E-BB62-4693-B95C-321E8DDEA7E1.html

https://docs.vmware.com/en/VMware-NSX-T/2.0/com.vmware.nsxt.ncp_kubernetes.doc/GUID-155DD8C6-175A-4C45-8258-C9D4F76EC70E.html

https://docs.vmware.com/en/VMware-NSX-T/2.0/com.vmware.nsxt.ncp_kubernetes.doc/GUID-FF047592-ADBF-405C-A6F3-20A3FDD86C12.html

-----END CERTIFICATE----- client_cert_file: | Certificate: Data: Version: 3 (0x2) Serial Number: 8 (0x8) Signature Algorithm: sha256WithRSAEncryption .......................................... .......................................... .......................................... 43:8e:69:8c:5f:d2:ab:eb:5b:e3:29:e3:a9:6e:85:25:cf:fa: 06:46:8e:c0:16:5a:ac:09:2d:02:ef:2b:50:1f:6f:03:5a:e9: b3:ba:d7:e3 -----BEGIN CERTIFICATE----- MIIDUDCCAjigAwIBAgIBCDANBgkqhkiG9w0BAQsFADA6TR0wGwYDVQQDDBQxMjcu .......................................... .......................................... .......................................... X9Kr61vjKeOpboUlz/oGRo7AFlqsCSderTtQH28DWumzutfj -----END CERTIFICATE----- client_private_key_file: | -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAUYTRASCBKgwggSkAgEAAoIBAQC/Jz4WnaTmbfB7 .......................................... .......................................... .......................................... n8jakjGLolYe5yv0KyM4RTD5 -----END PRIVATE KEY----- subnet_prefix: 26 external_subnet_prefix: 26 ncp_package: <name of the NSX-T Docker container file that is placed in `<installation_directory>/cluster/images` folder> ncp_image: <name of the NSX-T Docker container image> ncp_image_tag: <tag for the NSX-T Docker container image> nsx_apparmor_profile: <AppArmor profile name> nsx_apparmor_enabled: <true or false> ovs_uplink_port: ethX ingress_mode: hostnetwork or nat


network_type は nsx-t に設定する必要があります。managers は、NSX-T マネージャーの IP アドレスまたはホスト名です。 NSX-T マネージャーのポート番号はオプションです。複数の NSX-T マネージャーを指定することができます。 IP アドレスまたはホスト名をコンマで区切って追加してください。

manager_user は、NSX-T マネージャーへのアクセス権限を持つユーザーのユーザー名です。manager_password は、manager_user パラメーターで指定されたユーザーのパスワードです。manager_ca_cert NSX-T マネージャー・サーバー証明書の検証に使⽤する NSX-T マネージャー CA 証明書ファイルの内容を挿⼊します。

client_cert_file NSX-T マネージャーでの認証に使⽤する、NSX-T マネージャーのクライアント証明書ファイルの内容を挿⼊します。

client_private_key_file NSX-T マネージャーでの認証に使⽤する、NSX-T マネージャー・クライアント秘密鍵ファイルの内容を挿⼊します。

subnet_prefix は、ポッド⽤の IP アドレス・ブロックのサブネット接頭部の⻑さです。external_subnet_prefix は、外部 (NAT) IP アドレス・ブロックのサブネット接頭部の⻑さです。指定されない場合、subnet_prefix に指定された値が使⽤されます。ncp_package は、<installation_directory>/cluster/images フォルダーに置かれた NSX-T Dockerコンテナー .tar ファイルです。ncp_image は、NSX-T Docker コンテナー・イメージの名前です。ncp_image_tag は、latest などの、NSX-T Docker コンテナー・イメージのタグです。


nsx_apparmor_profile は、使⽤される AppArmor プロファイルの名前です。指定できるデフォルトAppArmor プロファイル名は node-agent-apparmor です。別のプロファイルを使⽤する場合は、パラメーター値としてカスタム・プロファイル名を指定します。

nsx_apparmor_enabled は、AppArmor サービスがシステムで使⽤可能にされるかどうかを指定するために使⽤されるパラメーターです。デフォルト値は true です。このパラメーターは Ubuntu でのみ適⽤できます。

ovs_uplink_port は、アップリンク・ポートとして構成されるインターフェースの名前です。割り当てられた ofport が 1 でない場合のみ、このパラメーターを追加してください。ingress_mode は、⼊⼝コントローラーを公開するためのオプションです。 nat と指定すると、NSX-T NATプールが使⽤されます。 hostnetwork と指定すると、ノード IP アドレスが使⽤されます。デフォルトのIBM Cloud Private 管理⼊⼝コントローラーはルーティングにノード IP アドレスを使⽤します。カスタム⼊⼝コントローラーについては、ルーティングに NSX-T NAT プールを使⽤するよう設定できます。

次に、IBM Cloud Private インストールを続⾏します。

脆弱性アドバイザーの使⽤可能化

クラスター内で脆弱性アドバイザーを使⽤可能にします。

脆弱性アドバイザーについて詳しくは、IBM Cloud 資料 {: newwindow} の脆弱性アドバイザーについて_セクションを参照してください。

脆弱性アドバイザー機能は、IBM Cloud Private の Cloud Native エディションおよび Enterprise エディションでのみサポートされています。

脆弱性アドバイザーを使⽤可能にする場合、システムの CPU、メモリー、およびディスク・スペースが追加で必要になる可能性があります。ハードウェア要件および推奨事項を参照してください。

1. 専⽤ VA ノードをセットアップします。 1 個、3 個、または 5 個の VA ノードを保有できます。専⽤ノードをセットアップするには、インストール中に、hosts ファイルの [va] セクションにノード IP を指定します。 hosts ファイル内の [va] ヘッダーから # を削除する必要があります。

2. 脆弱性アドバイザーを有効にするには、無効リストから vulnerability-advisor を削除します。パラメーターを以下のように設定できます。

## 管理サービス ["service-catalog", "metering", "monitoring", "istio", "vulnerability-advisor", "custom-metrics-adapter"] を無効にできます disabled_management_services: ["istio", "custom-metrics-adapter"]

脆弱性アドバイザーについて詳しくは、脆弱性アドバイザーを参照してください。

外部ロード・バランサーのセットアップ

⾼可⽤性環境でマスター・ノードまたはプロキシー・ノードの外部ロード・バランサーを構成する⽅法について説明

します。

IBM® Cloud Private ⾼可⽤性環境のマスター・ノードとプロキシー・ノードは、ucarp と etcd の両⽅をロード・バランサーとして使⽤します。このセットアップでは、仮想 IP アドレス (VIP) が 1 つのマスター・ノードまたは 1 つのプロキシー・ノードにバインドされます。

別の⽅法として、または VIP の代わりとして、外部ロード・バランサーを使⽤する場合もあります。

IBM Cloud Private ⾼可⽤性環境で外部ロード・バランサー・モードを使⽤可能にするには、ロード・バランサー・ノードを準備し、HAProxy をインストールする必要があります。次に、config.yaml ファイルで


https://console.bluemix.net/docs/services/va/va_index.html#about

cluster_lb_address パラメーターと proxy_lb_address パラメーターを設定して、ロード・バランサーを構成します。

クラスター外部ロード・バランサーは、IBM Cloud Private 管理サービスのロード・バランシングに使⽤されます。プロキシー外部ロード・バランサーは、IBM Cloud Private ワークロード・サービスのロード・バランシングに使⽤されます。

1. クラスター外部ロード・バランサーをセットアップするには、ロード・バランサー・ノードに 8001、8443、8500、9443 の各ポートが追加され、開いていることを確認します。

2. プロキシー外部ロード・バランサーをセットアップするには、ロード・バランサー・ノードに 80 および 443の各ポートが追加され、開いていることを確認します。

3. ロード・バランサー・ノードをセットアップします。このロード・バランサー・ノードは、マスター・ノード、ワーカー・ノード、プロキシー・ノードなどの他のクラスター・ノードと共有してはなりません。ポートの競合を防ぐために、専⽤ノードが必要です。

1. ロード・バランサー・ノードに HAproxy をインストールします。

Ubuntu の場合:

apt-get install haproxy

Red Hat Enterprise Linux (RHEL):

yum install haproxy

2. HAproxy を構成します。ロード・バランサー・ノード上の /etc/haproxy/haproxy.cfg ファイルでHAproxy を構成します。

# Example configuration for a possible web application. See the # full configuration options online. # # http://haproxy.1wt.eu/download/1.4/doc/configuration.txt # # Global settings global # To view messages in the /var/log/haproxy.log you need to: # # 1) Configure syslog to accept network log events. This is done # by adding the '-r' option to the SYSLOGD_OPTIONS in # /etc/sysconfig/syslog. # # 2) Configure local2 events to go to the /var/log/haproxy.log # file. A line similar to the following can be added to # /etc/sysconfig/syslog. # # local2.* /var/log/haproxy.log # log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 4000 user haproxy group haproxy daemon # 3) Turn on stats unix socket stats socket /var/lib/haproxy/stats # Common defaults that all the 'listen' and 'backend' sections # use, if not designated in their block. defaults mode http


log global option httplog option dontlognull option http-server-close option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 frontend k8s-api *:8001 mode tcp option tcplog use_backend k8s-api backend k8s-api mode tcp balance roundrobin server server1 <master_node_1_IP_address>:8001 server server2 <master_node_2_IP_address>:8001 server server3 <master_node_3_IP_address>:8001 frontend dashboard *:8443 mode tcp option tcplog use_backend dashboard backend dashboard mode tcp balance roundrobin server server1 <master_node_1_IP_address>:8443 server server2 <master_node_2_IP_address>:8443 server server3 <master_node_3_IP_address>:8443 frontend auth *:9443 mode tcp option tcplog use_backend auth backend auth mode tcp balance roundrobin server server1 <master_node_1_IP_address>:9443 server server2 <master_node_2_IP_address>:9443 server server3 <master_node_3_IP_address>:9443 frontend registry *:8500 mode tcp option tcplog use_backend registry backend registry mode tcp balance roundrobin server server1 <master_node_1_IP_address>:8500 server server2 <master_node_2_IP_address>:8500 server server3 <master_node_3_IP_address>:8500 frontend proxy-http *:80 mode tcp option tcplog use_backend proxy-http


backend proxy-http mode tcp balance roundrobin server server1 <proxy_node_1_IP_address>:80 server server2 <proxy_node_2_IP_address>:80 server server3 <proxy_node_3_IP_address>:80 frontend proxy-https *:443 mode tcp option tcplog use_backend proxy-https backend proxy-https mode tcp balance roundrobin server server1 <proxy_node_1_IP_address>:443 server server2 <proxy_node_2_IP_address>:443 server server3 <proxy_node_3_IP_address>:443

3. クラスター・ロード・バランサーをセットアップするには、<master_node_1_IP_address>、<master_node_2_IP_address>、および <master_node_3_IP_address> を HA マスター・ノードの IP アドレスに置き換えます。

4. プロキシー・ロード・バランサーをセットアップするには、<proxy_node_1_IP_address>、<proxy_node_2_IP_address>、および <proxy_node_3_IP_address> を HA プロキシー・ノードの IP アドレスに置き換えます。

4. config.yaml ファイルを更新します。 cluster_lb_address パラメーターまたは proxy_lb_address パラメーターを、外部ロード・バランサー・ノードの IP アドレスに置き換えます。

## External loadbalancer IP or domain ## Or floating IP in OpenStack environment cluster_lb_address: none

## External loadbalancer IP or domain ## Or floating IP in OpenStack environment proxy_lb_address: none

Kubernetes 監査ログの⽣成

IBM® Cloud Private での Kubernetes 監査ログについて説明します。

Kubernetes 監査ログは、IBM Cloud Private の使⽤に関連したデータを追跡および保管するために使⽤されます。監査ログに保存するデータのタイプに関するルールを定義するために、監査ポリシーが使⽤されます。 IBM CloudPrivate はデフォルトの Kubernetes 監査ポリシーを使⽤します。デフォルトの Kubernetes 監査ポリシーについて詳しくは、https://kubernetes.io/docs/tasks/debug-application-cluster/audit/ を参照してください。

デフォルトでは、Kubernetes 監査ログは IBM Cloud Private で使⽤不可です。該当するログを⽣成するには、/<installation_directory>/config.yaml ファイルで auditlog_enabled パラメーターを true に設定します。『Kubernetes 設定』を参照してください。

ログ・ファイルは、/var/lib/icp/audit フォルダーに保存されます。

アンインストール

IBM® Cloud Private をクラスターからアンインストールできます。


https://kubernetes.io/docs/tasks/debug-application-cluster/audit/

IBM Cloud Private のアンインストール IBM Cloud Private-CE のアンインストール

IBM® Cloud Private のアンインストール

IBM Cloud Private をアンインストールします。

1. root 権限を持つユーザーとしてブート・ノードにログインします。通常、ブート・ノードはマスター・ノードです。ノード・タイプについて詳しくは、アーキテクチャーを参照してください。インストール中に、各ノード・タイプの IP アドレスを指定します。

2. IBM Cloud Private インストール・ディレクトリー内の cluster ディレクトリーに移動します。

cd /<installation_directory>/cluster

3. IBM Cloud Private をアンインストールします。

docker run -e LICENSE=accept --net=host \ -t -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3-ee uninstall

注: アンインストール・プロセスがハングする場合、ノードをリブートし、その後でアンインストール・コマンドを実⾏してください。

4. クラスター内の各ノードで Docker を再始動します。各ノードで次のコマンドを実⾏します。

service docker restart

5. クラスター内のすべてのノードを再始動します。

注: GlusterFS クラスターがあった場合、IBM Cloud Private をアンインストールすると Heketi および GlusterFS のポッドが削除されます。ただし、論理ボリュームは削除されません。これらの論理ボリュームからデータを復旧できます。データ復旧について詳しくは、GlusterFS ボリュームからのデータ復旧を参照してください。

IBM® Cloud Private-CE のアンインストール

IBM Cloud Private-CE (Community Edition) をアンインストールします。


2. IBM Cloud Private-CE インストール・ディレクトリー内の cluster ディレクトリーに移動します。


3. IBM Cloud Private-CE をアンインストールします。

docker run -e LICENSE=accept --net=host \ -t -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3 uninstall

注: アンインストール・プロセスがハングする場合、ノードをリブートし、その後でアンインストール・コマンドを実⾏してください。

4. クラスター内の各ノードで Docker を再始動します。各ノードで次のコマンドを実⾏します。



5. クラスター内のすべてのノードを再始動します。

注: GlusterFS クラスターがあった場合、IBM Cloud Private-CE をアンインストールすると Heketi および GlusterFSのポッドが削除されます。ただし、論理ボリュームは削除されません。これらの論理ボリュームからデータを復旧できます。データ復旧について詳しくは、GlusterFS ボリュームからのデータ復旧を参照してください。

アップグレードと復帰

IBM® Cloud Private クラスターをアップグレードおよび復帰します。

IBM Cloud Private バージョン 2.1.0.2 から 2.1.0.3 へのアップグレード IBM Cloud Private-CE バージョン 2.1.0.2 から 2.1.0.3 へのアップグレードバンドルされた製品のアップグレード IBM Cloud Private Docker パッケージのアップグレードアップグレードでのモニター・データの保持前のバージョンの IBM Cloud Private への復帰前のバージョンの IBM Cloud Private-CE への復帰 IBM Cloud Private Docker パッケージの復帰

IBM® Cloud Private バージョン 2.1.0.2 から 2.1.0.3 へのアップグレード

IBM Cloud Private をバージョン 2.1.0.2 から 2.1.0.3 へアップグレードできます。

バージョン 2.1.0.2 からのみアップグレードできます。それより前のバージョンの IBM Cloud Private を使⽤している場合、最初に 2.1.0.2 にアップグレードする必要があります。 IBM Cloud Private バージョン 2.1.0.2 資料でアップグレードおよび復帰に関するセクションを参照してください。

アップグレード・プロセス中は IBM Cloud Private management console にアクセスできません。また、アップグレード・プロセスの⼀部の実⾏中に、アプリケーションにアクセスできないことがあります。アプリケーションのレプリカが複数のワーカー・ノード上にある場合は、アップグレード中でもアプリケーションにアクセスできます。

アップグレード・プロセス中は、クラウド・プロバイダー・オプションの設定 (vSphere クラウド・プロバイダーの設定など) を⾏うことはできず、NSX-T の使⽤を選択することもできません。


2. IBM Cloud Private のインストール・ファイルをダウンロードします。これらのファイルは、IBM® パスポート・アドバンテージ Web サイトからダウンロードできます。

Linux® 64-bit クラスターの場合、ibm-cloud-private-x86_64-2.1.0.3.tar.gz ファイルをダウンロードします。

Linux® on Power® (ppc64le) クラスターの場合、ibm-cloud-private-ppc64le-2.1.0.3.tar.gzファイルをダウンロードします。



tar xf ibm-cloud-private-x86_64-2.1.0.3.tar.gz -O | sudo docker load



https://www.ibm.com/support/knowledgecenter/SSBS6K_2.1.0.2/installing/upgrading.html


tar xf ibm-cloud-private-ppc64le-2.1.0.3.tar.gz -O | sudo docker load

4. インストール・ディレクトリーを作成し、IBM Cloud Private 構成ファイルを抽出してそこに置きます。前のバージョン⽤に使⽤したものとは異なるインストール・ディレクトリーを使⽤してください。例えば /opt/ibm-cloud-private-2.1.0.3 に構成ファイルを保管するには、次のコマンドを実⾏します。

mkdir /opt/ibm-cloud-private-2.1.0.3 cd /opt/ibm-cloud-private-2.1.0.3 sudo docker run -e LICENSE=accept \ -v "$(pwd)":/data ibmcom/icp-inception:2.1.0.3-ee cp -r cluster /data

インストール・ディレクトリー内に cluster ディレクトリーが作成されます。例えば、インストール・ディレクトリーが /opt/ibm-cloud-private-2.1.0.3 の場合、/opt/ibm-cloud-private-2.1.0.3/cluster フォルダーが作成されます。

5. ディレクトリー cfc-certs、cfc-keys、および cfc-components と、ファイル hosts および ssh_keyを、前のインストール・ディレクトリーから新しい IBM Cloud Private cluster フォルダーにコピーします。

cp -r /<installation_directory>/cluster/cfc-certs /<new_installation_directory>/cluster cp -r /<installation_directory>/cluster/cfc-keys /<new_installation_directory>/cluster cp -r /<installation_directory>/cluster/cfc-components /<new_installation_directory>/cluster cp /<installation_directory>/cluster/hosts /<new_installation_directory>/cluster cp /<installation_directory>/cluster/ssh_key /<new_installation_directory>/cluster

注: /<installation_directory> はバージョン 2.1.0.2 インストール・ディレクトリーの絶対パスであり、/<new_installation_directory> はバージョン 2.1.0.3 インストール・ディレクトリーの絶対パスです。

6. IBM Cloud Private 2.1.0.2 をインストールした後で管理サービスの構成を追加または変更した場合、それらの構成を /<new_installation_directory>/cluster/cfc-components/ 内のサービス YAML ファイルに適⽤します。これらの管理サービスには、ELK、Heapster、image-manager、Calico、rescheduler、Tiller、Helm、および unified-router があります。

7. /<installation_directory>/cluster/config.yaml ファイルに加えた変更内容を検討し、それらの変更を /<new_installation_directory>/cluster/config.yaml ファイル内で再現します。 config.yaml ファイルのカスタマイズには、以下の注記を確認してください。

glusterfs パラメーターが false に設定されていることを確認します。

glusterfs: false

IBM Cloud Private バージョン 2.1.0.3 の場合、disabled_management_services パラメーターのデフォルト値が更新されます。『汎⽤設定』を参照してください。無効にする追加のサービスをこの新しいデフォルト・リストに追加できます。

注: 脆弱性アドバイザー・オプションは、バージョン 2.1.0.3 で vulnerability-advisor と呼ばれるようになりました。アップグレード時に、古い va オプションは、新しい vulnerability-advisorオプションとともに使⽤する必要があります。例えば、アップグレード時に脆弱性アドバイザーを無効にするには、/<new_installation_directory>/cluster/config.yaml ファイルを以下のように更新します。

disabled_management_services: ["va", "vulnerability-advisor"]

⾼可⽤性クラスターの場合、バージョン 2.1.0.3 の vip_manager 設定は、バージョン 2.1.0.2 の設定に⼀致している必要があります。バージョン 2.1.0.2 では、デフォルトの vip_manager は ucarp でしたが、2.1.0.3 のデフォルト設定は etcd です。バージョン 2.1.0.2 クラスターでデフォルトの ucarp


設定を使⽤していた場合、/<new_installation_directory>/cluster/config.yaml ファイルの vip_manager パラメーターを ucarp に設定する必要があります。

ingress_controller パラメーターについては、バージョン 2.1.0.2 設定が⽰されているサンプル構成に似ている場合は、バージョン 2.1.0.3 ファイルを更新します。

バージョン 2.1.0.2 構成設定

ingress_controller: disable-access-log: 'false'


nginx-ingress: ingress: config: disable-access-log: 'false'

8. デフォルト・クラスター IP が使⽤中でないことを確認します。

kubectl get services --all-namespaces --no-headers | awk '{if($4 ~ /\.(8|9)$/){printf "%s %s %s\n", $1, $2, $4}}'

出⼒がブランクの場合、次のステップに進むことができます。

返された出⼒に末尾が .8 の IP が含まれている場合、/<new_installation_directory>/cluster/config.yaml ファイル内の image_manager_service_ip を使⽤可能な IP に置き換える必要があります。例: image_manager_service_ip: x.x.x.3

返された出⼒に末尾が .9 の IP が含まれている場合、/<new_installation_directory>/cluster/config.yaml 内の tiller_service_ip を使⽤可能な IP に置き換える必要があります。例: tiller_service_ip: x.x.x.4

値 x.x.x.3 および x.x.x.4 は例であり、任意の使⽤可能な IP を使⽤できます。

1. 既に使⽤されている IP のリストを確認するには、以下のコマンドを実⾏します。

kubectl get services --all-namespaces --no-headers | awk '{if($4 !~ /None/){print $4}}' | sort -n

2. リストを確認した後、返された出⼒にリストされていない任意の IP を tiller_service_ip および image_manager_service_ip に使⽤できます。

9. クラスター⽤のイメージ・ファイルを /<new_installation_directory>/cluster/images フォルダーに移動します。


mkdir -p cluster/images; \ mv /<path_to_images_file>/ibm-cloud-private-x86_64-2.1.0.3.tar.gz cluster/images/


mkdir -p cluster/images; \ sudo mv /<path_to_images_file>/ibm-cloud-private-ppc64le-2.1.0.3.tar.gz cluster/images/

クラスター内に IBM® Z ワーカー・ノードがある場合、次のコマンドを実⾏します。

sudo mv /<path_to_images_file>/ibm-cloud-private-s390x-2.1.0.3.tar.gz cluster/images/


このコマンド内の path_to_images_file は、イメージ・ファイルのパスです。


cd ./cluster

11. モニタリングをインストールした場合、「プラットフォーム」 > 「モニタリング」コンソールに進み、そのダッシュボードの新しいバージョンをインポートします。現在の Prometheus Stats ダッシュボード・ファイルは、Prometheus サーバーでは正常に機能しません。 prometheus2.0-stats.json を developerWorkscommunity files からダウンロードします。

12. 以下のステップを実⾏して、環境をデプロイします。

1. アップグレードのためにクラスターを準備します。

sudo docker run -e LICENSE=accept --net=host --rm -t -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3-ee upgrade-prepare

クラスターの準備が失敗した場合は、エラー・メッセージを確認して問題を解決してください。次に、cluster/.install.lock ファイルを削除し、upgrade-prepare コマンドを再実⾏します。

2. Kubernetes をアップグレードします。

sudo docker run -e LICENSE=accept --net=host --rm -t -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3-ee upgrade-k8s

Kubernetes のアップグレードが失敗した場合は、エラー・メッセージを確認して問題を解決してください。その後、Kubernetes をロールバックし、Kubernetes のアップグレード・コマンドを再実⾏します。 Kubernetes をロールバックする⽅法については、前のバージョンの IBM Cloud Private への復帰を参照してください。

3. 管理サービスをアップグレードします。

sudo docker run -e LICENSE=accept --net=host --rm -t -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3-ee upgrade-mgtsvc

管理サービスのアップグレードが失敗した場合は、エラー・メッセージを確認して問題を解決してくだ

さい。その後、管理サービスをロールバックし、管理サービスのアップグレード・コマンドを再実⾏します。管理サービスをロールバックする⽅法については、前のバージョンの IBM Cloud Private への復帰を参照してください。

13. アップグレードの状況を確認します。

アップグレードが正常終了した場合、以下のようにクラスターのアクセス情報が表⽰されます。


このメッセージ中の master_ip は、IBM Cloud Private クラスターのマスター・ノードの IP アドレスです。


エラーが発⽣する場合は、トラブルシューティングを参照してください。

14. IBM Cloud Private バージョン 2.1.0.2で GlusterFS を構成した場合は、/<installation_directory>/cluster/config.yaml ファイルで、glusterfs パラメーターを確実に true に戻してください。


https://www.ibm.com/developerworks/community/files/app#/file/8b486e3f-747d-4cdb-a7f4-0eef1a539e73

glusterfs: true

IBM Cloud Private 2.1.0.3 では、GlusterFS バージョンをアップグレードする必要はありません。

15. ブラウザー・キャッシュを初期化します。




17. すべての IBM Cloud Private デフォルト・ポートが開いていることを確認します。デフォルト IBM CloudPrivate ポートについて詳しくは、デフォルト・ポートを参照してください。

18. ブート・ノードのバックアップを取ります。セキュアな場所に /<new_installation_directory>/cluster ディレクトリーをコピーします。

19. IBM Cloud Private クラスター内で Cloud Automation Manager を使⽤している場合、それもアップグレードする必要があります。 Upgrading Cloud Automation Manager を参照してください。

IBM® Cloud Private-CE バージョン 2.1.0.2 から 2.1.0.3 へのアップグレード

IBM Cloud Private-CE をバージョン 2.1.0.2 から 2.1.0.3 へアップグレードできます。

バージョン 2.1.0.2 からのみアップグレードできます。それより前のバージョンの IBM Cloud Private-CE を使⽤している場合、最初に 2.1.0.2 にアップグレードする必要があります。 IBM Cloud Private バージョン 2.1.0.2 資料でアップグレードおよび復帰に関するセクションを参照してください。

あるバージョンの IBM Cloud Private-CE から別のバージョンの IBM Cloud Private-CE へのみアップグレードできます。 IBM Cloud Private-CE を IBM Cloud Private Cloud Native エディションまたは Enterprise エディションにアップグレードすることはできません。

アップグレード・プロセス中は IBM Cloud Private management console にアクセスできません。また、アップグレード・プロセスの⼀部の実⾏中に、アプリケーションにアクセスできないことがあります。アプリケーションのレプリカが複数のワーカー・ノード上にある場合は、アップグレード中でもアプリケーションにアクセスできます。

アップグレード・プロセス中は、クラウド・プロバイダー・オプションの設定 (vSphere クラウド・プロバイダーの設定など) を⾏うことはできず、NSX-T の使⽤を選択することもできません。


2. Docker Hub から IBM Cloud Private-CE インストーラー・イメージをプルします。

sudo docker pull ibmcom/icp-inception:2.1.0.3

3. インストール・ディレクトリーを作成し、IBM Cloud Private 構成ファイルを抽出してそこに置きます。前のバージョン⽤に使⽤したものとは異なるインストール・ディレクトリーを使⽤してください。例えば、構成フ

ァイルを /opt/ibm-cloud-private-2.1.0.3 に保管する場合、次のコマンドを実⾏します。

mkdir /opt/ibm-cloud-private-2.1.0.3 cd /opt/ibm-cloud-private-2.1.0.3 sudo docker run -e LICENSE=accept \ -v "$(pwd)":/data ibmcom/icp-inception:2.1.0.3 cp -r cluster /data


https://www.ibm.com/support/knowledgecenter/SS2L37/cam_upgrade_cam.html

https://www.ibm.com/support/knowledgecenter/SSBS6K_2.1.0.2/installing/upgrading.html

インストール・ディレクトリー内に cluster ディレクトリーが作成されます。例えば、インストール・ディレクトリーが /opt/ibm-cloud-private-2.1.0.3 の場合、/opt/ibm-cloud-private-2.1.0.3/cluster フォルダーが作成されます。

4. ディレクトリー cfc-certs、cfc-keys、および cfc-components と、ファイル hosts および ssh_keyを、前のインストール・ディレクトリーから新しい IBM Cloud Private cluster フォルダーにコピーします。

cp -r /<installation_directory>/cluster/cfc-certs /<new_installation_directory>/cluster cp -r /<installation_directory>/cluster/cfc-keys /<new_installation_directory>/cluster cp -r /<installation_directory>/cluster/cfc-components /<new_installation_directory>/cluster cp /<installation_directory>/cluster/hosts /<new_installation_directory>/cluster cp /<installation_directory>/cluster/ssh_key /<new_installation_directory>/cluster

注: /<installation_directory> はバージョン 2.1.0.2 インストール・ディレクトリーの絶対パスであり、/<new_installation_directory> はバージョン 2.1.0.3 インストール・ディレクトリーの絶対パスです。

5. IBM Cloud Private-CE 2.1.0.2 をインストールした後で管理サービスの構成を追加または変更した場合、それらの構成を /<installation_directory>/cfc-components/ 内のサービス YAML ファイルに適⽤します。これらの管理サービスには、ELK、Heapster、image-manager、Calico、rescheduler、Tiller、Helm、および unified-router があります。

6. /<installation_directory>/cluster/config.yaml ファイルに加えた変更内容を検討し、それらの変更を /<new_installation_directory>/cluster/config.yaml ファイル内で再現します。 config.yaml ファイルのカスタマイズには、以下の注記を確認してください。

glusterfs パラメーターが false に設定されていることを確認します。

glusterfs: false

IBM Cloud Private バージョン 2.1.0.3 の場合、disabled_management_services パラメーターのデフォルト値が更新されます。『汎⽤設定』を参照してください。無効にする追加のサービスをこの新しいデフォルト・リストに追加できます。

ingress_controller パラメーターについては、バージョン 2.1.0.2 設定が⽰されているサンプル構成に似ている場合は、バージョン 2.1.0.3 ファイルを更新します。


ingress_controller: disable-access-log: 'false'


nginx-ingress: ingress: config: disable-access-log: 'false'


cd ./cluster

8. モニタリングをインストールした場合、「プラットフォーム」 > 「モニタリング」コンソールに進み、現⾏のPrometheus Stats ダッシュボード・ファイルを削除します。それを新しいダッシュボード・ファイル prometheus2.0-stats.json で置き換えます。このファイルは developerWorks community files から⼊⼿できます。


https://www.ibm.com/developerworks/community/files/app#/file/8b486e3f-747d-4cdb-a7f4-0eef1a539e73

9. 以下のステップを実⾏して、環境をデプロイします。

1. アップグレードのためにクラスターを準備します。

sudo docker run -e LICENSE=accept --net=host --rm -t -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3 upgrade-prepare

クラスターの準備が失敗した場合は、エラー・メッセージを確認して問題を解決してください。次に、cluster/.install.lock ファイルを削除し、upgrade-prepare コマンドを再実⾏します。

2. Kubernetes をアップグレードします。

sudo docker run -e LICENSE=accept --net=host --rm -t -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3 upgrade-k8s

Kubernetes のアップグレードが失敗した場合は、エラー・メッセージを確認して問題を解決してください。その後、Kubernetes をロールバックし、Kubernetes のアップグレード・コマンドを再実⾏します。 Kubernetes をロールバックする⽅法については、前のバージョンの IBM® Cloud Private-CE への復帰を参照してください。

3. 管理サービスをアップグレードします。

sudo docker run -e LICENSE=accept --net=host --rm -t -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3 upgrade-mgtsvc

管理サービスのアップグレードが失敗した場合は、エラー・メッセージを確認して問題を解決してくだ

さい。その後、管理サービスをロールバックし、管理サービスのアップグレード・コマンドを再実⾏します。管理サービスをロールバックする⽅法については、前のバージョンの IBM® Cloud Private-CEへの復帰を参照してください。

10. アップグレードの状況を確認します。

アップグレードが正常終了した場合、以下のようにクラスターのアクセス情報が表⽰されます。


このメッセージ中の master_ip は、IBM Cloud Private クラスターのマスター・ノードの IP アドレスです。


エラーが発⽣する場合は、トラブルシューティングを参照してください。

11. IBM Cloud Private バージョン 2.1.0.2で GlusterFS を構成した場合は、/<installation_directory>/cluster/config.yaml ファイルで、glusterfs パラメーターを確実に true に戻してください。

glusterfs: true

IBM Cloud Private 2.1.0.3 では、GlusterFS バージョンをアップグレードする必要はありません。

12. ブラウザー・キャッシュを初期化します。


Web ブラウザーから IBM Cloud Private management console を使⽤してクラスターにアクセスする⽅法について詳しくは、management console を使⽤した IBM Cloud Private クラスターへのアクセスを


参照してください。


14. すべての IBM Cloud Private デフォルト・ポートが開いていることを確認します。デフォルト IBM CloudPrivate ポートについて詳しくは、デフォルト・ポートを参照してください。

15. ブート・ノードのバックアップを取ります。セキュアな場所に /<new_installation_directory>/cluster ディレクトリーをコピーします。

バンドルされた製品のアップグレード

IBM® Cloud Private パッケージに組み込まれている他の製品の Helm チャートをアップグレードできます。

これらの製品の圧縮ファイルは、IBM® パスポート・アドバンテージ新しいタブで開く](../images/icons/launch-glyph.svg "新しいタブで開く") から⼊⼿できます。それらの新しいフ

ァイルをインストールした後、既存の Helm リリースをアップグレードする必要があります。


チャートをアップグレードする前に、前提条件である以下の作業を実⾏してください。

バンドルされた製品のインストールに関する前提条件を満たしていることを確認してください。バンドルされた製品のインストールを参照してください。

Helm コマンド・ライン・インターフェース (CLI) をインストールします。 Helm CLI のセットアップを参照してください。

パッケージされた製品をアップグレードするには、以下のようにします。

1. 圧縮ファイルをパスポート・アドバンテージから取得します。

2. 圧縮ファイル内のイメージをコンピューターにロードするための⼗分なディスク・スペースがあることを確認します。

1. Docker ディスク使⽤量を確認します。次のコマンドを実⾏します。

docker system df

コマンド・オプションについて詳しくは、Docker 資料のdocker system df を参照してください。

2. 追加のディスク・スペースが必要な場合は、以下のいずれかのアクションを実⾏してください。古い Docker イメージを削除します。Docker デーモンが使⽤するストレージ量を増やします。 Docker デーモンが使⽤するストレージ量を増やすには、dockerd Docker 資料の dm.basesize に関する項⽬を参照してください。

3. まだログインしていない場合は IBM Cloud Private CLI からクラスターにログインし、Docker プライベート・イメージ・レジストリーにログインします。

bx pr login -a https://<cluster_CA_domain>:8443 --skip-ssl-validation docker login <cluster_CA_domain>:8500

ここで、cluster_CA_domain は、認証局 (CA) ドメインです。 CA ドメインを指定しなかった場合、デフォルト値は mycluster.icp です。 IBM Cloud Private サービス⽤の独⾃の認証局 (CA) の指定を参照してください。

4. パスポート・アドバンテージから⼊⼿した新バージョンのチャートをインストールします。

bx pr load-ppa-archive --archive <compressed_file_name> [--clustername <cluster_CA_domain>] [--namespace <namespace>]


https://docs.docker.com/engine/reference/commandline/system_df/

https://docs.docker.com/engine/reference/commandline/dockerd

ここで、compressed_file_name はパスポート・アドバンテージからダウンロードしたファイルの名前、cluster_CA_domain は (CA) ドメイン、namespace は Docker イメージをホスティングする Docker 名前空間です。

5. IBM Cloud Private Catalog でチャートを表⽰します。

1. IBM Cloud Private management console から、「管理」 > 「Helm リポジトリー」と選択します。


リポジトリーの同期化、追加、または削除を⾏うために必要なユーザー・タイプまたはアクセス・レベ

ル: クラスター管理者

3. メニュー・バーから「カタログ」を選択します。

新バージョンのチャートをインストールすると、Catalog には両⽅のチャートが表⽰されます。クラスターにはどちらかのバージョンをインストールできます。

6. チャートを使⽤する既存の Helm リリースをアップグレードします。

helm upgrade <releaseName> http://<cluster_CA_domain>:8443/helm-repo/requiredAssets/<chartName>-<chartVersion>.tgz

このコマンドの各部は、以下のとおりです。

<releaseName> は、アップグレードする既存 Helm リリースの名前です。リリース名は managementconsole で⾒つけることができます。<cluster_CA_domain> は認証局 (CA) ドメインです。CA ドメインを指定しなかった場合、デフォルト値は mycluster.icp です。 IBM Cloud Private サービス⽤の独⾃の認証局 (CA) の指定を参照してください。

<chartName> は、この Helm リリースが使⽤するチャートの名前です。チャート名は Catalog ページから取得できます。

<chartVersion> は、使⽤するチャートの新バージョンです。チャート・バージョンは、Catalog 内で新規チャートをクリックすることで取得できます。

IBM Cloud Private Docker パッケージのアップグレード

IBM Cloud Private Docker パッケージを使⽤してインストールされた Docker エンジンをアップグレードします。

IBM Cloud Private Docker パッケージのアップグレード (ブート・ノード)IBM Cloud Private Docker パッケージのアップグレード (クラスター・ノード)

IBM Cloud Private Docker パッケージのアップグレード (ブート・ノード)

IBM Cloud Private Docker パッケージを使⽤してインストールされたブート・ノードをアップグレードします。

1. プラットフォームに合った Docker パッケージをダウンロードします。 IBM Cloud Private Docker パッケージを参照してください。

2. ブート・ノード上で Docker をアップグレードします。


chmod +x icp-docker-17.12.1_x86_64.bin sudo ./icp-docker-17.12.1_x86_64.bin --upgrade



chmod +x icp-docker-17.12.1_ppc64le.bin sudo ./icp-docker-17.12.1_ppc64le.bin --upgrade



IBM Cloud Private Docker パッケージのアップグレード (クラスター・ノード)

IBM Cloud Private Docker パッケージを使⽤してインストールされたクラスター・ノードをアップグレードします。

1. /<installation_directory>/cluster/ ディレクトリーに切り替えます。

cd /<installation_directory>/cluster/

1. Docker をアップグレードします。

sudo docker run --net=host -t -e LICENSE=accept -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3-ee upgrade-docker

-l オプションを使⽤して、特定のクラスター・ノードをアップグレードすることもできます。

ワーカー・ノードの場合、-l worker を使⽤します。HA 環境では、-l <host_ip> を使⽤して、マスター・ノードとプロキシー・ノードを⼀度に 1 つずつアップグレードします。

2. すべてのノードで、Docker エンジンが開始していることを確認します。次のコマンドを実⾏します。


アップグレードでのモニター・データの保持

アップグレード時にモニター・データを保持します。

IBM® Cloud Private バージョン 2.1.0.2 では、モニター・サービスのストレージを動的にプロビジョンした場合、データがアップグレード時に失われます。モニター・データにローカル・ストレージを使⽤していた場合、以下のセクションのステップを実⾏して、アップグレード時にデータを保持できます。

既存の永続ボリュームの更新

永続ボリュームの作成

config.yaml ファイルの更新

既存の永続ボリュームの更新

1. kubectl CLI をセットアップします。 kubectl CLI を使⽤した IBM® Cloud Private クラスターへのアクセスを参照してください。

2. クラスター内のすべての永続ボリューム (PV) のリストを取得します。モニター・サービスの各コンポーネントが使⽤している PV をメモします。

kubectl get pv


NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE helm-repo-pv 5Gi RWO Delete Bound kube-system/helm-repo-pvc helm-repo-storage 1d image-manager-10.10.24.83 20Gi RWO Retain Bound


kube-system/image-manager-image-manager-0 image-manager-storage 1d logging-datanode-10.10.24.83 20Gi RWO Retain Bound kube-system/data-logging-elk-data-0 logging-storage-datanode 1d mongodb-10.10.24.83 20Gi RWO Retain Bound kube-system/mongodbdir-icp-mongodb-0 mongodb-storage 1d alertmanager-pv 1Gi RWO Delete Bound default/my-release-prometheus-alertmanager 17h

3. モニター・サービスが使⽤している PV ごとに、以下のコマンドを実⾏します。このコマンドは、PV の再利⽤ポリシーを Delete から Retain に変更します。

kubectl patch pv <PV name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'


kubectl patch pv alertmanager-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' persistentvolume "alertmanager-pv" patched

4. PV が更新されたことを確認します。

kubectl get pv


NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE helm-repo-pv 5Gi RWO Delete Bound kube-system/helm-repo-pvc helm-repo-storage 1d image-manager-10.10.24.83 20Gi RWO Retain Bound kube-system/image-manager-image-manager-0 image-manager-storage 1d logging-datanode-10.10.24.83 20Gi RWO Retain Bound kube-system/data-logging-elk-data-0 logging-storage-datanode 1d mongodb-10.10.24.83 20Gi RWO Retain Bound kube-system/mongodbdir-icp-mongodb-0 mongodb-storage 1d alertmanager-pv 1Gi RWO Retain Bound default/my-release-prometheus-alertmanager 17h

永続ボリュームの作成

モニター・サービス・コンポーネントが使⽤している PV ごとに、新規 PV を作成します。古い PV が割り当てられていたのと同じノードに新規 PV を割り当てる必要があります。

PersistentVolumes のデフォルト・ストレージ要件は以下のとおりです。

Prometheus: 10GiGrafana: 1Giアラート・マネージャー: 1Gi

Helm チャートで定義したストレージ要件に基づいて、PersistentVolume の定義を更新する必要があります。アップグレード時に既存のデータが保持されるようにするために、既存の PV で使⽤していたのと同じストレージ・クラスを使⽤する必要があります。

以下に、アラート・マネージャーの新規 PV の定義の例を⽰します。

kind: PersistentVolume apiVersion: v1 metadata: name: alertmanager-data labels: component: alertmanager annotations:


"volume.alpha.kubernetes.io/node-affinity": '{ "requiredDuringSchedulingIgnoredDuringExecution": { "nodeSelectorTerms": [ { "matchExpressions": [ { "key": "kubernetes.io/hostname", "operator": "In", "values": [ "10.10.24.83" ] } ]} ]} }' spec: storageClassName: monitoring-storage capacity: storage: 1Gi accessModes: - ReadWriteMany hostPath: path: "/opt/ibm/cfc/monitoring/alertmanager" persistentVolumeReclaimPolicy: Retain

config.yaml ファイルの更新

/<installation_directory>/cluster フォルダー内の config.yaml ファイルを更新します。『モニタリング・サービスの構成』を参照してください。

次に、クラスターのアップグレードに進みます。

前のバージョンの IBM® Cloud Private への復帰

IBM Cloud Private 2.1.0.3 にアップグレードした後、最後にインストールされていたバージョンに戻すことができます。

クラスター・バージョンを戻す場合、アップグレード後の構成変更および作成した新しいワークロードはすべ

て削除されます。

バージョン 2.1.0.3 で新しいワークロードを作成する場合、クラスター・バージョンを戻すことはできません。

インストールされているバージョンを戻す場合、以下のステップを実⾏します。

1. 管理サービスをロールバックします。

sudo docker run -e LICENSE=accept --net=host --rm -t -v \ "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3-ee rollback-mgtsvc

2. Kubernetes をロールバックします。

sudo docker run -e LICENSE=accept --net=host --rm -t -v \ "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3-ee rollback-k8s

前のバージョンの IBM® Cloud Private-CE への復帰

IBM Cloud Private-CE 2.1.0.3 にアップグレードした後、最後にインストールされていたバージョンに戻すことができます。

クラスター・バージョンを戻す場合、アップグレード後の構成変更および作成した新しいワークロードはすべ

て削除されます。


バージョン 2.1.0.3 で新しいワークロードを作成する場合、クラスター・バージョンを戻すことはできません。

インストールされているバージョンを戻す場合、以下のステップを実⾏します。

1. 管理サービスをロールバックします。

sudo docker run -e LICENSE=accept --net=host --rm -t -v \ "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3 rollback-mgtsvc

1. Kubernetes をロールバックします。

sudo docker run -e LICENSE=accept --net=host --rm -t -v \ "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3 rollback-k8s

IBM Cloud Private Docker パッケージの復帰

IBM Cloud Private Docker パッケージの復帰 (ブート・ノード)IBM Cloud Private Docker パッケージの復帰 (クラスター・ノード)

クラスター内で使⽤されている IBM Cloud Private Docker パッケージのバージョンを前のバージョンに戻します。

IBM Cloud Private Docker パッケージの復帰 (ブート・ノード)

ブート・ノードで使⽤されている IBM Cloud Private Docker パッケージのバージョンを戻します。

1. プラットフォームに合った Docker パッケージをダウンロードします。 IBM Cloud Private Docker パッケージを参照してください。

2. ブート・ノード上の Docker バージョンを戻します。


chmod +x icp-docker-17.12.1_x86_64.bin sudo ./icp-docker-17.12.1_x86_64.bin --rollback


chmod +x icp-docker-17.12.1_ppc64le.bin sudo ./icp-docker-17.12.1_ppc64le.bin --rollback



IBM Cloud Private Docker パッケージの復帰 (クラスター・ノード)

IBM Cloud Private Docker パッケージを使⽤してインストールされたクラスター・ノードの Docker バージョンを戻します。

1. /<installation_directory>/cluster/ ディレクトリーに切り替えます。

cd /<installation_directory>/cluster/

2. Docker バージョンを戻します。

sudo docker run --net=host -t -e LICENSE=accept -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3-ee rollback-docker

-l オプションを使⽤して、特定のクラスター・ノードをアップグレードすることもできます。


ワーカー・ノードの場合、-l worker を使⽤します。HA 環境では、-l <host_ip> を使⽤して、マスター・ノードとプロキシー・ノードを⼀度に 1 つずつアップグレードします。

3. すべてのノードで、Docker エンジンが開始していることを確認します。次のコマンドを実⾏します。



クラスターへのアクセス⽅法を説明します。

management console を使⽤した IBM® Cloud Private クラスターへのアクセス kubectl CLI を使⽤した IBM Cloud Private クラスターへのアクセス

management console を使⽤した IBM® Cloud Private クラスターへのアクセス

サポートされる Web ブラウザーから、IBM Cloud Private クラスター management console にアクセスできます。

1. クラスター management console URL およびデフォルト資格情報を取得します。

URL は https://master_ip:8443 です。ここで、master_ip は、IBM Cloud Private クラスターのマスター・ノードの IP アドレスです。デフォルトのユーザー名は admin、デフォルトのパスワードは admin です。この情報は、以下のコードのように、インストール・ログに表⽰されます。

UI URL is https://master_ip:8443, default username/password is admin/admin


3. クラスターにログインします。

kubectl CLI を使⽤した IBM® Cloud Private クラスターへのアクセス

コマンド・ライン・インターフェース (CLI) を使⽤してクラスターにアクセスするには、Kubernetes コマンド・ライン・ツールである kubectl をインストールして構成する必要があります。

1. クライアント・コンピューターと IBM Cloud Privateクラスター内のノードとの間でクロックを同期化します。Network Time Protocol (NTP) を使⽤してクロックを同期化できます。 NTP のセットアップについて詳しくは、ご使⽤のオペレーティング・システムのユーザー資料を参照してください。

2. Kubernetes コマンド・ライン・インターフェース kubectl バージョン 1.10.0 をインストールします。 kubectl バイナリー・ファイルを IBM Cloud Private インストーラーから取得するか、新規インストール・ファイルをダウンロードできます。

IBM Cloud Private インストーラーからのバイナリー・ファイルを使⽤するには、次のコマンドを実⾏します。

Standard Edition:


docker run -e LICENSE=accept --net=host -v /usr/local/bin:/data ibmcom/icp-inception:2.1.0.3-ee cp /usr/local/bin/kubectl /data

Community Edition:

docker run -e LICENSE=accept --net=host -v /usr/local/bin:/data ibmcom/icp-inception:2.1.0.3 cp /usr/local/bin/kubectl /data

新規バイナリー・ファイルをダウンロードしてインストールするには、Install and Set Up kubectl を参照してください。

3. クラスター構成詳細を取得します。クラスター構成詳細は、IBM Cloud Private CLI または managementconsole を使⽤して取得できます。

management console から構成詳細を取得するには、次のようにします。

1. クラスター management console にログインします。 management console を使⽤した IBMCloud Private クラスターへのアクセスを参照してください。

2. 「ユーザー名」 > 「クライアントの構成」を選択します。以下のコードのようなクラスター構成詳細が表⽰されます。

kubectl config set-cluster {cluster_name} --server=https://master_ip:8001 --insecure-skip-tls-verify=true kubectl config set-context {cluster_name}-context --cluster={cluster_name} kubectl config set-credentials {cluster_name}-user --token={token} kubectl config set-context {cluster_name}-context --user={cluster_name}-user --namespace=default kubectl config use-context {cluster_name}-context

この詳細の中で master_ip は、IBM Cloud Private クラスターのマスター・ノードの IP アドレスです。

3. 構成情報をコピーしてコマンド・ラインに貼り付け、Enter を押します。

IBM Cloud Private CLI から構成詳細を取得するには、次のようにします。

1. IBM Cloud Private コマンド・ライン・インターフェース (CLI) をインストールし、クラスターにログインします。 IBM Cloud Private CLI のインストールを参照してください。

2. クラスター名を取得します。

bx pr clusters

3. クラスター⽤に kubectl を構成します。

bx pr cluster-config <cluster-name>

ここで、<cluster-name> はクラスターの名前です。

注: この構成は 12 時間で有効期限が切れます。引き続き CLI を使⽤するには、12 時間ごとにログインして kubectl を再構成する必要があります。この制限を回避するために、サービス・アカウントを使⽤して CLI を構成することができます。https://www.ibm.com/developerworks/community/blogs/fe25b4ef-ea6a-4d86-a629-6f87ccf4649e/entry/Configuring_the_Kubernetes_CLI_by_using_service_account_tokens1 を参照してください。

IBM® Cloud Private CLI を使⽤したクラスターの管理


https://v1-10.docs.kubernetes.io/docs/user-guide/prereqs/

https://www.ibm.com/developerworks/community/blogs/fe25b4ef-ea6a-4d86-a629-6f87ccf4649e/entry/Configuring_the_Kubernetes_CLI_by_using_service_account_tokens1

IBM Cloud Private コマンド・ライン・インターフェース (CLI) を使⽤して、クラスターに関する情報の表⽰、新規クラスターの作成、Helm チャートおよびその他のワークロードのインストールを⾏うことができます。

IBM Cloud Private CLI のインストール IBM Cloud Private CLI コマンド解説書

IBM® Cloud Private CLI のインストール

IBM Cloud Private コマンド・ライン・インターフェース (CLI) をインストールすると、新規クラスターを作成および管理することができます。

IBM Cloud Private をインストールした後、Windows、Linux、または macOS で CLI をインストールできます。

1. クライアント・コンピューターと IBM Cloud Privateクラスター内のノードとの間でクロックを同期化します。Network Time Protocol (NTP) を使⽤してクロックを同期化できます。 NTP のセットアップについて詳しくは、ご使⽤のオペレーティング・システムのユーザー資料を参照してください。

2. IBM Cloud CLI をインストールします。詳しくは、IBM Cloud CLI の概説を参照してください。

3. IBM Cloud CLI がインストールされたことを確認します。

bx --help

IBM Cloud CLI 使⽤法が表⽰されます。

4. IBM Cloud Private management console から、「メニュー」 > 「コマンド・ライン・ツール」 > 「CloudPrivate CLI」をクリックします。

5. CLI インストーラー・ファイルをダウンロードするため、ご使⽤のオペレーティング・システムのダウンロード・リンクをクリックします。

6. CLI をインストールします。次のコマンドを実⾏します。

bx plugin install /<path_to_installer>/<cli_file_name>

例えば、Downloads フォルダー内にある macOS ⽤の icp-darwin-amd64 ファイルを使⽤するには、次のコマンドを実⾏します。

bx plugin install ~/Downloads/icp-darwin-amd64

7. IBM Cloud Private CLI がインストールされたことを確認します。

bx pr --help

IBM Cloud Private CLI 使⽤法が表⽰されます。


bx pr login -a https://<master_ip_address>:8443 --skip-ssl-validation

ここで、master_ip_address は、マスター・ノードまたは先導マスター・ノードの外部 IP アドレスです。

これで、IBM Cloud Private CLI を使⽤して、最初のクラスターについての情報を表⽰したり、クラスターのコンテンツをさらにインストールしたり、追加のクラスターを構成したりできます。 IBM Cloud Private CLI を使⽤して新規クラスターを構成する場合、そのクラスターへのワーカー・ノードの追加または削除を CLI を使⽤して⾏うことができます。

IBM Cloud Private CLI のサービス API 鍵のコマンド


https://console.bluemix.net/docs/cli/reference/bluemix_cli/get_started.html#getting-started

アプリケーションで必要な特定サービスにアクセスするためのサービス ID、API 鍵、ポリシーを管理するには、以下のコマンドを参照してください。

ヒント: IBM Cloud Private プラグインのバージョンを表⽰するには、以下のコマンドを実⾏します。

bx plugin list

IAM コマンドおよびデータをリストするために実⾏するコマンド:

bx pr iambx pr iam rolesbx pr iam services

ID を管理するために実⾏するコマンド:

bx pr iam service-idbx pr iam service-id-createbx pr iam service-id-deletebx pr iam service-id-updatebx pr iam service-ids

鍵を管理するために実⾏するコマンド:

bx pr iam service-api-keybx pr iam service-api-key-createbx pr iam service-api-key-deletebx pr iam service-api-key-updatebx pr iam service-api-keys

ポリシーを管理するために実⾏するコマンド:

bx pr iam service-policiesbx pr iam service-policybx pr iam service-policy-createbx pr iam service-policy-deletebx pr iam service-policy-update

bx pr iam

bx pr iam - ID およびリソースへのアクセス権限を管理するための⼀連のコマンドを表⽰します。

例

bx pr iam

bx pr iam roles

roles - 役割のリストシステム定義の役割を admin ユーザーとして表⽰します。

例

bx pr iam roles

bx pr iam services

services - サービスのリストシステム定義のサービスを admin ユーザーとして表⽰します。

例


bx pr iam services

ID を管理するためのコマンド

bx pr iam service-id NAME [--uuid]

サービス ID の詳細の表⽰

オプション

--uuid サービス ID の UUID の表示

例

bx pr iam service-id <metering-service> [--uuid]

bx pr iam service-id-create NAME [-d, --description DESCRIPTION]

注: サービス ID を作成する前に、'bx pr target [-n NAMESPACE]' を実⾏してターゲット名前空間を設定してください。

service-id-create - サービス ID の作成

オプション

-d value, --description value サービス ID の説明

例

bx pr iam service-id-create <metering-service> -d <my-description>

bx pr iam service-id-delete NAME [-f, --force]

service-id-delete - サービス ID の削除

オプション

-f, --force 確認せずに削除

例

bx pr iam service-id-delete <metering-service> [-f, --force]

bx pr iam service-id-update NAME [-n, --name NEW_NAME][-d, --descriptionDESCRIPTION] [-f, --force]

service-id-update - サービス ID の更新

オプション

-n value, --name value サービス ID の新規名 -d value, --description value サービス ID の新規の説明 -f, --force 確認せずに更新


例

bx pr iam service-id-update <metering-service> -n <updated-metering-service-id> -d <my-description> [-f, --force]

bx pr iam service-ids --uuid

service-ids - すべてのサービス ID をリストします。

例

bx pr iam service-ids --uuid

鍵を管理するためのコマンド

bx pr iam service-api-key NAME SERVICE_ID_NAME [--uuid]

service-api-key - サービス API 鍵の詳細のリスト

オプション

SERVICE_ID (必須) サービス ID の名前または UUID --uuid サービス API 鍵の UUID の表示 -f, --force 確認せずにサービス API 鍵を表示

例

bx pr iam service-api-key <my-apikey> <metering-service> [--uuid]

bx pr iam service-api-key-create NAME SERVICE_ID_NAME [-d, --descriptionDESCRIPTION][-f, --file FILE]

service-api-key-create - サービス API 鍵の作成

オプション

-d value, --description value API 鍵の説明 -f value, --file value 指定されたファイルに API 鍵情報を保存します。設定されないと、JSON コンテンツが表示されます。

例

bx pr iam service-api-key-create <my-apikey> <metering-service> -d <my-description> [-f, --file FILE]

bx pr iam service-api-key-delete NAME SERVICE_ID_NAME [-f, --force]

service-api-key-delete - サービス API 鍵の削除

オプション



例

bx pr iam service-api-key-delete <my-apikey> <metering-service> [-f, --force]

bx pr iam service-api-key-update NAME SERVICE_ID_NAME [-n, --nameNEW_NAME][-d, --description DESCRIPTION] [-f, --force]

service-api-key-update - サービス API 鍵の更新

オプション


例

bx pr iam service-api-key-update <metering-service> <updated-service-key> <my-description> [-f, --force]

bx pr iam service-api-keys serviceid

service-api-keys - サービスのすべての API 鍵をリスト

例

bx pr iam service-api-keys <metering-service>

ポリシーを管理するためのコマンド

bx pr iam service-policies SERVICE_ID_NAME [--json][-f, --force]

service-policies 指定されたサービスのすべてのサービス・ポリシーをリスト

オプション

--json JSON 形式でポリシーを表示 -f, --force 確認せずにサービス・ポリシーを表示

例

bx pr iam service-policies <metering-service> [--json] [-f, --force]

bx pr iam service-policy SERVICE_ID_NAME POLICY_ID [--json][-f, --force]

service-policy - サービス・ポリシーの詳細を表⽰

オプション

--json JSON 形式でポリシーを表示 -f, --force 確認せずにサービス・ポリシーを表示

例

bx pr iam service-policy <metering-service> POLICY_ID [--json] [-f, --force]


bx pr iam service-policy-create NAME SERVICE_ID_NAME [-d, --descriptionDESCRIPTION][-f, --file FILE]

service-policy-create - サービス・ポリシーの作成

オプション

-r value, --roles value ポリシー定義の役割名。サポートされる役割については、bx pr iam roles を実行してください。 --service-name value ポリシー定義のサービス名。 -f, --force 確認せずにサービス・ポリシーを作成

例

bx pr iam service-policy-create <metering-service> -r <Viewer> --service-name <metering-service> [-f, --force]

bx pr iam service-policy-delete SERVICE_ID_NAME POLICY_ID [-f, --force]

service-policy-delete - サービス・ポリシーの削除

オプション


例

bx pr iam service-policy-delete <metering-service> POLICY_ID [-f, --force]

bx pr iam service-policy-update SERVICE_ID_NAME POLICY_ID {[-r, --rolesROLE_NAME1,ROLE_NAME2...][--service-name SERVICE_NAME]} [-f, --force]

service-policy-update - サービス・ポリシーの更新

オプション

-r value, --roles value ポリシー定義の役割名。サポートされる役割については、bx pr iam roles を実行してください。 --service-name value ポリシー定義のサービス名。 -f, --force 確認せずにサービス・ポリシーを更新

例

bx pr iam service-policy-update <metering-service> POLICY_ID -r <ClusterAdministrator> --service-name <monitoring-service> [-f, --force]

IBM® Cloud Private CLI コマンド解説書

クラスターの作成と管理を⾏うときに以下のコマンドを参照してください。

ヒント: IBM Cloud Private プラグインのバージョンを表⽰するには、以下のコマンドを実⾏します。

bx plugin list


bx pr apibx pr cluster-config clusterbx pr cluster-getbx pr clustersbx pr delete-helm-chartbx pr initbx pr load-helm-chartbx pr load-ppa-archivebx pr loginbx pr logoutbx pr master-getbx pr mastersbx pr tokensbx pr worker-getbx pr workersbx pr worker-addbx pr worker-rm

bx pr api

サービスの API エンドポイントおよび API バージョンを表⽰します。

例

bx pr api

bx pr cluster-config [cluster name or id]

Kubernetes 構成をダウンロードし、指定されたクラスター⽤に kubectl を構成します。

オプション

[cluster name or id]クラスターに付けた名前。デフォルト値は mycluster.icp です。

例

bx pr cluster-config mycluster.icp

bx pr cluster-get [cluster name or id]

クラスターの詳細を表⽰します。

オプション


--json出⼒を JSON 形式で表⽰します。

例

bx pr cluster-get mycluster.icp

bx pr clusters


ご使⽤のアカウントのすべてのクラスターをリストします。

オプション


例

bx pr clusters

bx pr delete-helm-chart --name HELM_CHART_NAME [--versionHELM_CHART_VERSION][--clustername CLUSTERNAME]

IBM Cloud Private 内部レジストリーから Helm チャートを削除します。

オプション

--name value 削除する Helm チャートの名前。

--version value削除する Helm チャートのバージョン。

--clustername value認証局 (CA) ドメイン名。デフォルト値は mycluster.icp です。 IBM Cloud Private サービス⽤の独⾃の認証局(CA) の指定を参照してください。

例

bx pr delete-helm-chart --name helmchart --version 2.1.1 --clustername mycluster.icp

bx pr init

API エンドポイントで IBM Cloud Private プラグインを初期化します。

オプション

--host valueサービスの API エンドポイント

--skip-ssl-validationセキュアでない SSL 証明書を許可します

--insecureセキュアでない HTTP 接続を許可します

例

bx pr init --host https://myendpoint --skip-ssl-validation

注: --skip-ssl-validation オプションを含める必要があります。

bx pr load-helm-chart --archive HELM_CHART_ARCHIVE [--clusternameCLUSTERNAME]

IBM Cloud Private クラスターに Helm チャート・アーカイブをロードします。 Helm チャートをロードする前に、Docker をセットアップし、プライベート・レジストリーにイメージをプッシュしてください。イメージのプッシュとプルを参照してください。


https://www.ibm.com/support/knowledgecenter/SSBS6K_2.1.0/manage_images/using_docker_cli.html

オプション

--archive valueHelm チャート・アーカイブ tgz へのパス。


例

bx pr load-helm-chart --archive helmchart.tgz --clustername mycluster.icp

bx pr load-ppa-archive --archive PPA_TAR_ARCHIVE [--clustername CLUSTERNAME][--namespace NAMESPACE]

このコマンドを使⽤して、IBM Cloud Private バンドルのいくつかのコンポーネントをロードします。バンドルについて詳しくは、IBM® Cloud Private バンドルを参照してください。バンドル・アーカイブをロードする前に、Dockerをセットアップする必要があります。

https://www.ibm.com/support/knowledgecenter/SSBS6K_2.1.0/manage_images/using_docker_cli.html を参照してください。

オプション

--archive valuePPA アーカイブ tgz へのパス。


--namespace valueDocker イメージがプッシュされる先の名前空間。デフォルトは default です。

例

bx pr load-ppa-archive --archive archive.tgz --clustername mycluster.icp --namespace dev

bx pr login [-a CLUSTER_URL][-u USERNAME] [-p PASSWORD]

ユーザーをログインします。

警告: コマンド・ライン・オプションとしてパスワードを指定することは推奨されません。パスワードが他者に対して可視になったり、シェル履歴に記録されたりする可能性があります。

オプション

-a value管理コンソールにアクセスするために使⽤する URL (例: https:// :8443)。

-u valueユーザー名

-p valueパスワード

--skip-ssl-validationHTTP 要求の SSL 検証をバイパスします。このオプションは推奨されません。

例


https://www.ibm.com/support/knowledgecenter/ja/SSBS6K_2.1.0.3/getting_started/bundles.html

https://www.ibm.com/support/knowledgecenter/SSBS6K_2.1.0/manage_images/using_docker_cli.html

ユーザー名とパスワードを対話式に指定するには、ユーザー名とパスワードのオプションを省略します。

bx pr login

ユーザー名とパスワードを引数として指定することもできます。

bx pr login -u [email protected] -p pa55woRD

スペースが含まれているパスワードは引⽤符 (") で囲みます。

bx pr login -u [email protected] -p "my password"

パスワードに引⽤符 (“) が含まれている場合は、円記号 (¥) を使⽤してエスケープします。

bx pr login -u [email protected] -p "\"password"\"

bx pr logout

ユーザーをログアウトします。

例

bx pr logout

bx pr master-get [id of master]

マスター・ノードに関する詳細を表⽰します。

オプション

id of masterマスター・ノードのホスト名。


例

bx pr master-get master_host_name

bx pr masters [cluster name or id]

既存のクラスター内のすべてのマスター・ノードをリストします。

オプション



例

bx pr masters mycluster.icp

bx pr tokens

現⾏セッションの OAuth トークンを表⽰します。トークンを⽣成するには、bx pr login を実⾏します。


このコマンドは、API 認証⽤のアクセス・トークンと ID トークンの両⽅を返します。

例

bx pr tokens

bx pr worker-get [id of worker]

ワーカー・ノードに関する詳細を表⽰します。

オプション

[id of worker]ワーカー・ノードのホスト名。


例

bx pr worker-get worker_host_name

bx pr workers [cluster name or id]

既存のクラスター内のすべてのワーカー・ノードをリストします。

オプション



例

bx pr workers my_cluster.icp

bx pr worker-add

ワーカー・ノードをクラスターに追加します。

オプション

[cluster name or id]クラスターに付けた名前。デフォルト値は mycluster です。

[workers]クラスター・ワーカー・ノードの数。デフォルト値は 1 です。

[machine-type]ワーカー・ノードのマシン・タイプ。使⽤可能なマシン・タイプを表⽰するには、bx pr machine-types を実⾏します。

[file]クラスター作成のための値を含んでいる YAML ファイル。クラスター作成コマンドにパラメーターを含めることによって、これらの値をオーバーライドできます。

例


bx pr worker-add --cluster mycluster --machine-type icp-platform-api-ubuntu-med --workers 1

bx pr worker-rm

既存のクラスターからワーカー・ノードを削除します。

オプション

[f]ユーザー・プロンプトを出さずに強制的にワーカー・ノードを削除します。

[s]⽇付メッセージおよび更新リマインダーを表⽰しません。

例

bx pr worker-rm mycluster <worker1 id> [worker2 id..]

クラスターの再始動

IBM® Cloud Private クラスターを再始動します。

IBM Cloud Private クラスターを再始動するには、すべてのノードで Docker エンジンを再始動する必要があります。

1. 各ノードで、以下のコマンドを実⾏します。

systemctl restart kubelet docker

チャートおよびアプリケーションの管理

Catalog を使⽤して、IBM® Cloud Private クラスターで Helm チャートのパッケージを参照およびインストールできます。

Catalog では、Kubernetes サービスとして実⾏可能なアプリケーション・パッケージが含まれている Helm チャートが表⽰されます。パッケージは、リポジトリーに保管されます。 IBM Cloud Private の Catalog には、デフォルトで1 つのリポジトリー接続が含まれていますが、他のリポジトリーに接続することもできます。リポジトリーに接続した後に、Catalog からリポジトリーのチャートにアクセスできます。アプリケーション開発者は、アプリケーションを開発して Catalog で公開し、他のユーザーがそのアプリケーションに簡単にアクセスしてインストールできるようにすることもできます。

Catalogで使⽤可能なアクションは、役割ベースのアクセス制御によって決定されます。詳しくは、『役割ベースのアクセス制御 (Role-based access control)』を参照してください。

Catalog を⾒つける

1. IBM Cloud Private management console にログインします。2. ナビゲーション・メニューから「Catalog」をクリックします。

Catalog の検索

Catalog ページから、Helm チャートをフィルタリングして、ナビゲーションを容易にすることができます。

以下の分類に基づいて、Helm チャートをフィルタリングできます。


リリース・タイプ

ベータ - 公式に発表された初期リリースのチャート。技術プレビュー (Tech Preview) - まだ発表されていないが、初期のレビューのために使⽤できるチャート。

限定使⽤ - 開発⽤のトライアルや評価版として使⽤できるチャート (無料チャート)商⽤ (Commercial use) - 実動に使⽤できるチャート (有料チャート)


Linux® 64-bitLinux® on Power® (ppc64le)IBM® Z

リポジトリー名

プロキシー・サーバーを使⽤した Catalog へのアクセス

プロキシー・サーバーを使⽤して Catalog にアクセスするには、IBM Cloud Private クラスターのインストール時にプロキシー・アクセスを有効にするか、クラスターのインストール後に Helm デプロイメントを編集します。

インストール時にプロキシー・アクセスを有効にするには、config.yaml ファイルで tiller_http_proxyおよび tiller_https_proxy パラメーターを設定します。 config.yaml ファイルを使⽤したクラスターのカスタマイズを参照してください。

クラスターのインストール後にアクセスを有効にするには、以下のステップを実⾏します。

1. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」をクリックします。2. helm-api デプロイメントの場合、「アクション」>「編集」を選択します。そのデプロイメントの

JSON ファイルが表⽰されます。3. ご使⽤のプロキシー URL の値で、HTTP_PROXY および HTTPS_PROXY 変数を更新します。プロトコルとポートを含めてください。

4. 「送信」をクリックします。デプロイメントが再始動し、プロキシー・サーバーを使⽤したカタログへのアクセスがセットアップされます。

Helm チャート・コレクションの確認

Catalog で使⽤可能なデフォルト・アプリケーションについて詳しくは、フィーチャー・サービスを参照してください。

Catalog 内の Helm チャートのデプロイ⾮デフォルト名前空間での⾼い特権を必要とする Helm チャートのデプロイチャートの操作

Catalog 内の Helm チャートのデプロイ

Catalog では、デプロイするために使⽤できる Helm チャートが表⽰されます。


1. ナビゲーション・メニューで、「Catalog」>「Helm チャート (Helm Charts)」をクリックします。

2. デプロイする Helm チャートを選択します。

Helm チャートごとに、インストール、アンインストール、および構成に関する情報が含まれている READMEファイルが⽤意されています。

3. 「構成 (Configure)」をクリックします。


4. 「構成 (Configuration)」ページで、リリースに名前を付けます。名前は、⼩⽂字の英字、数字、ダッシュ⽂字(-) のみで構成でき、先頭と末尾は英数字でなければなりません。

5. (オプション) 好みに合わせてフィールドをカスタマイズします。6. ご使⽤条件を読んで同意したことを確認します。7. 「インストール (Install)」をクリックして、Helm チャートをデプロイしてリリースを作成します。リリースは、Kubernetes クラスターで実⾏されるチャートのインスタンスです。

⾮デフォルト名前空間での⾼い特権を必要とする Helm チャートのデプロイ

定義されたポッド・セキュリティー・ポリシーが含まれている割り当て済み名前空間に、⾼い特権を必要とする

Helm チャートを IBM® Cloud Private Catalog からデプロイします。

必要なユーザー・タイプまたはアクセス・レベル: クラスター管理者

1. kubectl CLI をセットアップします。『kubectl CLI を使⽤した IBM Cloud Private クラスターへのアクセス』を参照してください。

2. ポッド・セキュリティー・ポリシーを作成します。例えば、ibm-icplogging ロギング・チャートの場合、IPC_LOCK 機能が含まれた privileged ポッドを作成できます。

a. ポリシー定義が含まれた YAML ファイルを作成します。

vim icplogging-psp.yaml

apiVersion: extensions/v1beta1 kind: PodSecurityPolicy metadata: name: icplogging spec: privileged: true allowedCapabilities: - IPC_LOCK fsGroup: rule: RunAsAny runAsUser: rule: RunAsAny seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes: - "*"

b. ポリシーを作成します。

kubectl create -f icplogging-psp.yaml


podsecuritypolicy "icplogging" created

3. ポッド・セキュリティー・ポリシー・リソースのクラスター役割を作成します。この役割の resourceNamesは、前のステップで作成したポッド・セキュリティー・ポリシーの名前でなければなりません。

a. クラスター役割の YAML ファイルを作成します。

vim icplogging-clusterrole.yaml


apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: icplogging-role rules: - apiGroups: - extensions resourceNames: - icplogging resources: - podsecuritypolicies verbs: - use

b. 役割を作成します。

kubectl create -f icplogging-clusterrole.yaml


clusterrole "icplogging-role" created

4. 名前空間を作成し、その名前空間内のサービス・アカウントのクラスター役割バインディングをセットアップします。この役割バインディングを使⽤して、作成したポッド・セキュリティー・ポリシーを使⽤するように名前空間内のサービス・アカウントを設定できます。

例えば、役割バインディング・サービスとともに名前空間 elk を作成するには、以下のようにします。

a. 名前空間を作成します。

kubectl create namespace elk

b. 役割バインディング・サービスを作成します。

vim logging-clusterrolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: logging-psp-users roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: icplogging-role subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: "system:serviceaccounts:elk"

kubectl create -f logging-clusterrolebinding.yaml

注: roleRef は、YAML ファイル内で clusterrole リソースより前に指定する必要があります。 subjectsは、名前空間のサービス・アカウントでなければなりません。


clusterrolebinding "logging-psp-users" created

5. Helm チャートをデプロイします。『Catalog 内の Helm チャートのデプロイ』を参照してください。チャートの名前空間として、パート 4 で作成した名前空間を必ず指定してください。

チャートの操作


クラスター内の Kubernetes チャート (パッケージ) を管理するには、Helm コマンド・ライン・インターフェース(CLI) を使⽤する必要があります。

Helm CLI をセットアップした後に、クラスターでパッケージを作成または更新できます。

Helm CLI のセットアップ Helm CLI への内部 Helm リポジトリーの追加カスタム・アプリケーションの追加インターネット接続がないクラスターへのフィーチャー・アプリケーションの追加

Helm CLI のセットアップ

Helm コマンド・ライン・インターフェース (CLI) を使⽤して、クラスター内のパッケージを管理します。

Helm について詳しくは、https://github.com/kubernetes/helm/tree/master/docs を参照してください。

IBM Cloud Private では役割ベースのアクセス制御を提供しているため、Helm CLI クライアントの特定のバージョンをインストールし、特定のアカウントの IBM Cloud Private アクセス・トークンが含まれている証明書を提供する必要があります。

重要: 接続の構成後に、Tiller を介してサーバーにアクセスする Helm コマンドに --tls オプションを追加する必要があります。

Helm CLI をセットアップする前に、以下のステップを実⾏する必要があります。

socat をインストールします。 socat は、2 つの場所間の双⽅向データ・フローに使⽤されるネットワーク・ユーティリティー・ツールです。 Helm では、socat は、Helm クライアントと Tiller の両⽅のポート転送を設定するために使⽤されます。 socat のセットアップと使⽤について詳しくは、http://www.dest-unreach.org/socat/doc/README を参照してください。Kubernetes コマンド・ライン・ツール kubectl をインストールし、クラスターへのアクセスを構成します。『kubectl CLI を使⽤した IBM Cloud Private クラスターへのアクセス (Accessing your IBM Cloud Privatecluster by using the kubectl CLI)』を参照してください。IBM Cloud Private CLI をインストールし、クラスターにログインします。『IBM Cloud Private CLI のインストール』を参照してください。

ブート・ノードおよびクラスター管理者アカウントへのアクセス権限を取得するか、そのアクセス権限を持つ

他のユーザーに証明書を作成するように要請します。クラスター管理者アカウントにアクセスできない場合、チームのオペレーターまたは管理者役割が割り当てられていて、kube-system 名前空間にアクセスできるIBM Cloud Private アカウントが必要です。

Helm CLI のインストール

1. Helm 実⾏可能バイナリー・ファイルをダウンロードします。 helm バイナリー・ファイルを IBM CloudPrivate パッケージから取得するか、バイナリーを Helm GitHub サイトからダウンロードできます。

Helm バイナリーを IBM Cloud Private パッケージからダウンロードするには、ご使⽤のクライアント・ノード・アーキテクチャーに合致するコマンドを実⾏します。

Linux® 64-bit の場合、以下のコマンドを実⾏します。

docker run -e LICENSE=accept --net=host -v /usr/local/bin:/data ibmcom/icp-helm-api:1.0.0 cp /usr/src/app/public/cli/linux-amd64/helm /data

Linux® on Power® (ppc64le) の場合、以下のコマンドを実⾏します。


https://github.com/kubernetes/helm/tree/master/docs

http://www.dest-unreach.org/socat/doc/README

docker run -e LICENSE=accept --net=host -v /usr/local/bin:/data ibmcom/icp-helm-api:1.0.0 cp /usr/src/app/public/cli/linux-ppc64le/helm /data

MacOS の場合、以下のコマンドを実⾏します。

docker run -e LICENSE=accept --net=host -v /usr/local/bin:/data ibmcom/icp-helm-api:1.0.0 cp /usr/src/app/public/cli/darwin-amd64/helm /data

Windows の場合、以下のコマンドを実⾏します。

docker run -e LICENSE=accept --net=host -v /usr/local/bin:/data ibmcom/icp-helm-api:1.0.0 cp /usr/src/app/public/cli/windows-amd64/helm /data

Helm v2.7.2 バイナリーを Helm GitHub サイトからダウンロードするには、Helm 2.7.2 を参照してください。

2. Helm 実⾏可能バイナリー・ファイルを PATH に追加します。

Linux および MacOS の場合、HELM_HOME を設定し、ファイルを /usr/local/bin フォルダーに移動します。

export HELM_HOME=/root/.helm mv helm /usr/local/bin

Windows の場合は、helm バイナリーがあるフォルダー・パスをシステム変数パスに追加します。

3. 証明書を提供します。クラスター管理者の証明書を提供するか、またはチームのオペレーターまたは管理者役割が割り当てられていて、kube-system 名前空間にアクセスできる特定のユーザーの証明書を提供できます。オペレーター、管理者、またはクラスター管理者の役割を備えている任意のユーザーが、以下のステップを実⾏して証明書を⽣成できます。

証明書を提供するには、以下のアクションを実⾏します。

1. IBM Cloud Private CLI をインストールします。『IBM Cloud Private CLI のインストール』を参照してください。


bx pr login -a https://<master_ip_address>:8443 --skip-ssl-validation

ここで、master_ip_address は、マスター・ノードまたは先導マスター・ノードの外部 IP アドレスです。

3. クラスターの名前を検索します。

bx pr clusters

4. クラスターを構成します。

bx pr cluster-config <clustername>

クラスターを構成すると、cert.pem 証明書および key.pem 証明書が ~/.helm ディレクトリーに追加されます。


1. Helm CLI を初期設定します。

インターネット・アクセスがある環境の場合、以下のコマンドを実⾏します。

helm init --client-only


https://github.com/kubernetes/helm/releases/tag/v2.7.2/

インターネット・アクセスがない環境の場合、以下のコマンドを実⾏します。

helm init --client-only --skip-refresh

2. Helm CLI が初期設定されていることを確認します。次のコマンドを実⾏します。

helm version --tls


Client: &version.Version{SemVer:"v2.7.2", GitCommit:"5bc7c619f85d74702e810a8325e0a24f729aa11a", GitTreeState:"dirty"} Server: &version.Version{SemVer:"v2.7.2", GitCommit:"5bc7c619f85d74702e810a8325e0a24f729aa11a", GitTreeState:"clean"}

3. 使⽤可能なパッケージまたはインストールされているパッケージのリストを確認します。

1. Helm リポジトリーを追加します。 Kubernetes Incubator リポジトリーを追加するには、以下のコマンドを実⾏します。

helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/

2. 以下のように、使⽤可能なパッケージを表⽰します。

helm search -l

3. パッケージをインストールします。次のコマンドを実⾏します。

helm install --name=package_name stable/package_in_repo --tls

このコマンドで、package_name はパッケージの名前であり、package_in_repo はインストールする使⽤可能なパッケージの名前です。例えば、WordPress パッケージをインストールするには、以下のコマンドを実⾏します。

helm install --name=my-wordpress stable/wordpress --tls

4. 以下のように、インストールされているパッケージをリストします。

helm list --tls


NAME REVISION UPDATED STATUS CHART NAMESPACE my-wordpress 1 Wed Jun 28 22:15:13 2017 DEPLOYED wordpress-0.6.5 default

5. パッケージを削除するには、以下のコマンドを実⾏します。

helm delete package_name --purge --tls

このコマンドで、package_name は、削除するパッケージの名前です。例えば、WordPress パッケージを削除するには、以下のコマンドを実⾏します。

helm delete my-wordpress --purge --tls

カスタム・アプリケーションの追加

カスタム・アプリケーションを IBM® Cloud Private Catalog に追加するには、Helm チャートを作成します。


Helm によって管理される Kubernetes パッケージは、チャートとも呼ばれます。このユーザー・ガイドでは、⽤語「パッケージ」と「チャート」は同じ意味で使⽤しています。

作成したチャートまたはインターネットからダウンロードしたチャートを外部 Helm リポジトリーまたは内部 IBMCloud Private リポジトリーに追加できます。

Helm チャートのパッケージ外部リポジトリーへのチャートの追加


Helm チャートのパッケージ

1. Helm コマンド・ライン・インターフェース (CLI) をセットアップします。『Helm CLI のセットアップ』を参照してください。

2. Helm チャートを作成します。例えば、demoapp Helm チャートを作成するには、以下のコマンドを実⾏します。

helm create demoapp

3. Helm チャートの内容を表⽰します。 demoapp Helm チャートの内容を表⽰するには、以下のコマンドを実⾏します。

tree demoapp

以下のように、チャートの内容が表⽰されます。

demoapp |-- charts |-- Chart.yaml |-- templates | |-- deployment.yaml | |-- _helpers.tpl | |-- NOTES.txt | `-- service.yaml `-- values.yaml

4. Helm チャートを構成します。 Getting Started with a Chart Template を参照してください。保守ユーザー情報、ソフトウェア・バージョン、コード・ソースを Chart.yaml ファイルに追加できます。また、deployment.yaml および service.yaml ファイルを変更したり、テンプレート・ディレクトリーをさらに追加したりすることもできます。

5. チャートのフォーマットが正しいことを確認します。次のコマンドを実⾏します。

helm lint --strict demoapp


==> Linting demoapp Lint OK 1 chart(s) linted, no failures

6. チャートをパッケージし、そのパッケージが追加されたことを確認します。

helm package demoapp ; ls -l

パッケージが追加された場合、そのチャート・パッケージはローカル・リポジトリー内にあります。以下の出⼒では、demoapp-0.1.0.tgz パッケージが表⽰されています。

total 62748 drwxr-xr-x 4 root root 4096 Jan 8 10:23 demoapp


https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/getting_started.md

-rw-r--r-- 1 root root 1768 Jan 8 10:37 demoapp-0.1.0.tgz

7. チャートの Docker イメージを、指定されているソース・レジストリーにアップロードします。 IBM CloudPrivate で提供されているプライベート・イメージ・レジストリーを使⽤している場合は、『イメージのプッシュおよびプル (Pushing and pulling images)』を参照してください。

8. チャートを外部リポジトリーまたは IBM Cloud Private 内部リポジトリーに追加します。外部リポジトリーへのチャートの追加


外部リポジトリーへのチャートの追加

Helm チャートをパッケージした後に、そのパッケージを外部リポジトリーに追加することで、IBM Cloud Private から使⽤できるようにすることができます。

1. リモート・チャート・リポジトリーのインデックスを更新します。

1. リモート・チャート・リポジトリーの index.yaml ファイルを取得します。

wget http://<remote_host>/charts/index.yaml

2. ご使⽤のチャートに基づいて、index.yaml ファイルを更新します。

./helm repo index --merge index.yaml --url http://<remote_host>/charts/ ./

--url オプションでは、チャート・リポジトリーの場所を指定します。このパスは、Helm CLI で新規チャート・パッケージを取得できる場所です。

2. チャートをリモート・リポジトリーにアップロードします。

更新した index.yaml と新規チャート・パッケージ・ファイルの両⽅をローカル・ホストから、リモート・ホスト上の対応するディレクトリーにコピーします。

3. IBM Cloud Private クラスター management console を使⽤して、パッケージ・リポジトリーを更新します。

リポジトリーを同期、追加、または削除するために必要なユーザー・タイプまたはアクセス・レベル: クラスター管理者

1. IBM Cloud Private management console から、「メニュー (Menu)」>「管理 (Manage)」>「Helm リポジトリー (Helm Repositories)」をクリックします。

2. リストでリポジトリーが表⽰されていない場合、追加します。『Helm リポジトリーの追加』を参照してください。

3. 「リポジトリーの同期」をクリックします。4. 「メニュー (Menu)」>「コンソール (Console)」をクリックします。新規 Helm チャートが Catalog にロードされ、クラスターにそれらをインストールできます。


Helm チャートをパッケージした後に、IBM Cloud Private で提供されている内部リポジトリーにそのパッケージを追加できます。


チャートをロードする前に、以下の前提条件を実⾏します。

IBM Cloud Private CLI をインストールし、クラスターにログインします。『IBM Cloud Private CLI のインストール』を参照してください。


『Docker CLI のための認証の構成 (Configuring authentication for the Docker CLI)』のステップ 1 に⽰されているように、hosts ファイルにクラスター IP アドレスおよびクラスター CA ドメイン・ネームを追加します。

1. Helm チャートをパッケージします。

2. IBM Cloud Private CLI からクラスターにログインし、Docker プライベート・イメージ・レジストリーにログインします (まだ⾏っていない場合)。

bx pr login -a https://<cluster_CA_domain>:8443 --skip-ssl-validation

ここで、cluster_CA_domain は、認証局 (CA) ドメインです。 CA ドメインを指定しなかった場合、デフォルト値は mycluster.icp です。『IBM Cloud Private サービス⽤の独⾃の認証局 (CA) の指定』を参照してください。

3. 以下のように、Helm チャートをインストールします。

bx pr load-helm-chart --archive <helm_chart_archive> [--clustername <cluster_CA_domain>]

ここで、helm_chart_archive は圧縮 Helm チャート・ファイルの名前であり、<cluster_CA_domain> は認証局 (CA) ドメインです。

新規 Helm チャートが Catalog にロードされ、クラスターにそれらをインストールできます。

インターネット接続がないクラスターへのフィーチャー・アプリケー

ションの追加

インターネット接続がないクラスター内の IBM® Cloud Private Catalog にフィーチャー・アプリケーションを追加できます。

IBM Cloud Private バンドルの⼀部であるアプリケーションを追加するには、『バンドル製品のインストール(Installing bundled products)』を参照してください。

フィーチャー・アプリケーションを追加するには、アプリケーション定義が含まれている Helm チャートと、指定されているすべての Docker イメージの両⽅をダウンロードする必要があります。


アプリケーションを追加する前に、コンピューターで以下の前提条件を実⾏する必要があります。

Git をインストールします。 Installing Git を参照してください。Docker をインストールします。 https://docs.docker.com/engine/installation/ を参照してください。Helm コマンド・ライン・インターフェース (CLI) をインストールします。『Helm CLI のセットアップ』を参照してください。

IBM Cloud Private CLI をインストールし、クラスターにログインします。『IBM Cloud Private CLI のインストール』を参照してください。

1. Helm チャートを取得します。以下のように、/IBM/charts リポジトリーを複製します。

git clone https://github.com/IBM/charts.git

2. チャートの values.yaml ファイルを開き、使⽤されている 1 つ以上の Docker イメージを⾒つけます。例えば、ibm-db2oltp-dev チャートをロードする場合、/stable/ibm-db2oltp-dev/values.yaml ファイルを開きます。以下のテキストに⽰すように、多くの場合、イメージの場所は image セクションに表⽰されます。


https://git-scm.com/book/en/v2/Getting-Started-Installing-Git


image: repository: na.cumulusrepo.com/hcicp_dev/db2server_dec tag: 11.1.2.2 pullPolicy: IfNotPresent

この例では、イメージは na.cumulusrepo.com/hcicp_dev/db2server_dec リポジトリー内にあり、11.1.2.2 タグを使⽤しています。

3. イメージをローカルにプルします。 values.yaml ファイルからのリポジトリーおよびタグの情報を使⽤します。次のコマンドを実⾏します。

docker pull <repository>:<tag>

この例では、コマンドは以下のテキストのようになります。

docker pull na.cumulusrepo.com/hcicp_dev/db2server_dec:11.1.2.2

4. チャートで使⽤されているイメージをプライベート・イメージ・レジストリーにアップロードします。『イメージのプッシュおよびプル (Pushing and pulling images)』を参照してください。イメージをプライベート・イメージ・レジストリーにアップロードすると、レジストリーで、その名前が割り当てられているイメージの

みが含まれるリポジトリーが保管されます。

5. values.yaml ファイルを再度開き、使⽤されている 1 つ以上の Docker イメージを⾒つけます。例えば、ibm-db2oltp-dev チャートをロードする場合、/stable/ibm-db2oltp-dev/values.yaml ファイルを開きます。以下のテキストに⽰すように、多くの場合、イメージの場所は image セクションに表⽰されます。

image: repository: <cluster_CA_domain>:8500/namespace/imagename tag: 11.1.2.2 pullPolicy: IfNotPresent

ここで、<cluster_CA_domain> は、インストール時に config.yaml ファイルに設定された認証局 (CA) ドメインであり、imagename はイメージの名前です。この例では、imagename は na.cumulusrepo.com/hcicp_dev/db2server_dec です。

6. 以下のように、Helm チャートを再パッケージします。

helm package <path_to_helm_directory>

ここで、<path_to_helm_directory> は、Helm チャートが含まれているフォルダーのパスです。

ibm-db2oltp-dev チャートをパッケージするには、以下のコマンドを実⾏します。

helm package charts/stable/ibm-db2oltp-dev

Helm チャートが含まれている .tgz ファイルがそのフォルダーに追加されます (ibm-db2oltp-dev-0.1.0.tgz など)。

7. 以下のように、チャートを IBM Cloud Private クラスターにアップロードします。

bx pr load-helm-chart --archive <tgz_package>

ここで、<tgz_package> は、作成したチャート・パッケージの名前です。

ibm-db2oltp-dev チャートをアップロードするには、以下のコマンドを実⾏します。

bx pr load-helm-chart --archive ibm-db2oltp-dev-0.1.0.tgz

8. IBM Cloud Private クラスター management console を使⽤して、パッケージ・リポジトリーを更新します。

1. IBM Cloud Private management console から、「メニュー (Menu)」>「管理 (Manage)」>「Helm リポジトリー (Helm Repositories)」をクリックします。


2. リストでリポジトリーが表⽰されていない場合、追加します。『Helm リポジトリーの追加』を参照してください。


4. 「メニュー (Menu)」>「コンソール (Console)」をクリックします。新規 Helm チャートが Catalog にロードされ、クラスターにそれらをインストールできます。

注: Catalog を使⽤することでのみ、Helm チャートをロードできます。 Helm CLI を使⽤してチャートをロードすることはできません。

イメージの管理

イメージ・マネージャーは、クラスター内部のイメージを集中的に管理するための場所です。イメージ・マネージャーは、Docker ハブと同じ機能を提供します。

イメージ・マネージャー Docker CLI の認証の構成イメージのプッシュおよびプルイメージ・スコープの変更特定の名前空間の imagePullSecrets の作成 consoleからのイメージの削除 IBM® Cloud Private 計量サービスのためのイメージのラベル付け

イメージ・マネージャー

イメージ・マネージャーは、Docker レジストリー V2 API を介して実⾏されるレイヤーです。イメージ・マネージャーは、Docker レジストリーが保管するイメージ・リポジトリーの管理機能と許可を提供します。

イメージ・マネージャーは、Docker レジストリーと統合して、クラウド・ベースのレジストリー・サービス Dockerハブと同じように機能するローカル・レジストリー・サービスを提供します。ローカル・レジストリーは、外部サービス Docker ハブとは異なり、イメージを表⽰またはプルできるユーザーについて制限があります。 Docker ハブが強制しているプッシュ制限は、このローカル・レジストリーで維持されます。


Docker コマンド・ライン操作を使⽤して、Docker イメージを IBM Cloud Private クラスター・イメージ・レジストリーに追加できます。 Docker について詳しくは、https://docs.docker.com/engine/getstarted/step_six/ を参照してください。

Docker クライアントを使⽤して、クラスター内でイメージをプッシュしたりプルしたりできます。その後、イメージ・マネージャーがクラスターの認証サービスを使⽤して、ログインしているユーザーの資格情報にアクセスし、イ

メージへのアクセスを提供します。認証サービスについて詳しくは、認証を参照してください。

イメージ・レジストリーに追加されたイメージは、名前空間によって所有されています。名前空間内部のすべてのユーザーは、イメージの所有者です。所有者は、クラスターのmanagement consoleからイメージを削除したり更新したりできます。スーパー管理者は、クラスター内のすべてのイメージへの全アクセス権限を持っています。所有者は、イメージのスコープを更新することもできます。スコープを設定すると、イメージを特定の名前空間に制限したり、すべての名前空間からイメージにアクセス可能にしたりすることができます。

クラスターのmanagement consoleから使⽤可能なイメージ・ページでは、ログインしているユーザーが、⾃分の使⽤可能なすべてのイメージを表⽰できます。イメージ名をクリックすると、イメージに関する追加情報が表⽰されます。

プライベート・イメージ・レジストリー内部にあるイメージを削除または更新するには、イメージ管理 API を使⽤する必要があります。『イメージ管理 API』を参照してください。

Docker CLI の認証の構成

IBM® Cloud Private クラスターの外部からプライベート・イメージ・レジストリーにアクセスするには、ご使⽤のコンピューターからクラスターへの認証をセットアップします。


始める前に

1. Docker をコンピューターにインストールする必要があります。『Install Docker 』を参照してください。

2. ノード上で Docker プロキシーが有効になっている場合は、以下のステップを実⾏します。

1. <cluster_CA_domain>:8500 を NO_PROXY リストに追加します。ここで、<cluster_CA_domain>は、インストール中に config.yaml ファイルに設定された認証局 (CA) ドメインです。

# cat /etc/systemd/system/docker.service.d/https-proxy.conf

更新は、以下のコードのようになります。

[Service] Environment="HTTP_PROXY=<proxy_url>" "NO_PROXY=localhost,127.0.0.1,<cluster_CA_domain>:8500"

2. Docker サービスを再開します。

systemctl daemon-reload systemctl restart docker

Linux の場合

1. クライアント・コンピューターと、IBM Cloud Private クラスター内のノードの間で、クロックを同期します。Network Time Protocol (NTP) を使⽤してクロックを同期化できます。 NTP のセットアップについて詳しくは、ご使⽤のオペレーティング・システムのユーザー資料を参照してください。


https://docs.docker.com/engine/getstarted/step_six/


2. Docker イメージをホストするシステム上で、/etc/hosts ファイルに以下の⾏を追加します。

<master_ip> <cluster_CA_domain>

ここで <master_ip> は、クラスター内のマスター・ホストの IP アドレスであり、<cluster_CA_domain>は、インストール時に config.yaml ファイルで設定された認証局 (CA) ドメインです。 CA ドメイン名を指定しなかった場合、デフォルト値は mycluster.icp です。『IBM Cloud Private サービス⽤の独⾃の認証局(CA) の指定』を参照してください。

3. コンピューター上で、Docker レジストリー証明書を保管するディレクトリーを作成します。

mkdir /etc/docker/certs.d/<cluster_CA_domain>:8500/

4. IBM Cloud Private クラスターのマスター・ノードから、レジストリー証明書をコンピューターにセキュア・コピーします。

scp /etc/docker/certs.d/<cluster_CA_domain>\:8500/ca.crt \ root@<client_node>:/etc/docker/certs.d/<cluster_CA_domain>\:8500/

5. クライアント・コンピューターで、Docker サービスを再始動します。


6. プライベート・イメージ・レジストリーにログインします。

docker login <cluster_CA_domain>:8500

macOS の場合

1. コンピューターと、IBM Cloud Private クラスター内のノードの間で、クロックを同期します。 Network TimeProtocol (NTP) を使⽤してクロックを同期化できます。 NTP のセットアップについて詳しくは、ご使⽤のオペレーティング・システムのユーザー資料を参照してください。

2. IBM Cloud Private クラスターのマスター・ノードから、レジストリー証明書をコンピューターにセキュア・コピーします。

scp /Users/<user_name>/.docker\:8500/ca.crt \ root@<client_node>:/Users/<user_name>/.docker\:8500/

3. クライアント・コンピューターから、キーチェーンに証明書を追加します。

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ca.crt

4. クライアント・コンピューターで、/etc/hosts ファイルに以下の⾏を追加します。

<master_ip> <cluster_CA_domain>

ここで <master_ip> は、クラスター内のマスター・ホストの IP アドレスであり、<cluster_CA_domain>は、インストール時に config.yaml ファイルで設定された認証局 (CA) ドメインです。 CA ドメイン名を指定しなかった場合、デフォルト値は mycluster.icp です。『IBM Cloud Private サービス⽤の独⾃の認証局(CA) の指定』を参照してください。

5. クライアント・コンピューターで、Docker サービスを再始動します。6. プライベート・イメージ・レジストリーにログインします。


イメージのプッシュおよびプル


ローカル・ファイル・システムからプライベート・イメージ・レジストリーへ、イメージをプッシュしたりプルした

りできます。


前提条件:

コンピューターに Docker をインストールします。『Install Docker』を参照してください。Docker CLI を構成します。『Docker CLI の認証の構成』を参照してください。クラスターが⾼可⽤性アーキテクチャーを使⽤している場合は、必ず /var/lib/registry の下に共有ディレクトリーをマウントしてください。

1. プライベート・イメージ・レジストリーにログインします。


2. 必要なイメージをプッシュまたはプルします。既存の名前空間にイメージをプッシュするか、既存の名前空間からイメージをプルする必要があります。イメージをプッシュまたはプルできるのは、⾃分が正しい役割を持っているチームに名前空間リソースが割り当てられている場合のみです。管理者およびオペレーターは、イメージをプッシュおよびプルすることができ、エディターとビューアーはイメージをプルできます。

imagePullSecret を指定していない場合、このイメージにアクセスできるのは、このイメージをホストする名前空間からのみです。名前空間について詳しくは、『名前空間』を参照してください。

ローカル・ファイル・システムからプライベート・イメージ・レジストリーへイメージをプッシュする

には、次のコマンドを実⾏します。プッシュするイメージの名前は、253 ⽂字よりも短くなければなりません。

1. イメージにタグを付けます。

docker tag image_name:tagname <cluster_CA_domain>:8500/namespacename/imagename:tagname

ここで namespacename はイメージを割り当てる名前空間の名前です。

2. イメージをプライベート・イメージ・レジストリーにプッシュします。

docker push <cluster_CA_domain>:8500/namespacename/imagename:tagname

デフォルトでは、イメージは namespace 名前空間に追加されます。すべての名前空間がそのイメージを使⽤できるようにしたい場合は、スコープを global に変更してください。『イメージ・スコープの変更』を参照してください。イメージは、その名前が割り当てられているイメージのみを含むリポジトリーに保管されます。

プライベート・イメージ・レジストリーからローカル・ファイル・システムへイメージをプルするに

は、Docker pullコマンドを実⾏します。

docker pull <cluster_CA_domain>:8500/namespacename/imagename:tagname

3. (オプション) 新規に追加されたイメージを使⽤して、アプリケーションまたはジョブをデプロイします。アプリケーションおよびジョブのデプロイについて詳しくは、『アプリケーションおよびジョブのデプロイ』を参

照してください。

イメージ・スコープの変更

イメージのスコープを変更して、クラスター内でのイメージの可⽤性を制限したり拡張したりすることができます。

デフォルトでは、プライベート・イメージ・レジストリー内のイメージは namespace スコープに割り当てられます。 global スコープを設定することによって、すべての名前空間がイメージを使⽤できるようにすることも、イメ



ージを特定の名前空間に制限することもできます。

management consoleからのイメージ・スコープの変更コマンド・ラインからのイメージ・スコープの変更

必要なユーザー・タイプまたはアクセス・レベル: クラスター管理者、チーム管理者、エディター、またはオペレーター

現在そのイメージが含まれている名前空間へのアクセス権限が必要です。 global または namespace のスコープにイメージを割り当てることができます。スコープが namespace であるイメージは、単⼀の名前空間内からのみアクセス可能ですが、global スコープのイメージはすべての名前空間からアクセスできます。

management consoleからのイメージ・スコープの変更

1. ナビゲーション・メニューから「カタログ (Catalog)」>「イメージ (Images)」をクリックします。2. 更新するイメージを対象として「アクション」>「スコープの変更 (Change Scope)」を選択します。3. スコープを選択します。4. 「イメージの更新 (Update Image)」をクリックします。

コマンド・ラインからのイメージ・スコープの変更

1. kubectl CLI を構成します。『kubectl CLI を使⽤した IBM Cloud Private クラスターへのアクセス』を参照してください。

2. イメージを編集します。

スコープを namespace から global に変更するには、次のコマンドを実⾏します。

kubectl get image <image name> -n=namespace -o yaml \ | sed 's/scope: namespace/scope: global/g' | kubectl replace -f -

ここで <image name> は移動するイメージの名前です。

スコープを global から namespace に変更するには、次のコマンドを実⾏します。

kubectl get image <image name> -n=namespace -o yaml \ | sed 's/scope: global/scope: namespace/g' | kubectl replace -f -

ここで <image name> は移動するイメージの名前です。

例えば、dev/keepalived という名前のイメージのイメージ・スコープをglobal から namespace に変更するには、次のコマンドを実⾏します。

kubectl get image keepalived -n=dev -o yaml \ | sed 's/scope: global/scope: namespace/g' | kubectl replace -f -

特定の名前空間の imagePullSecrets の作成

imagePullSecrets は、秘密としても知られる許可トークンであり、レジストリーにアクセスするために使⽤されるDocker 資格情報を保管します。

management console からアプリケーションを作成するために、2 つの形式が使⽤可能です。「デプロイメントの作成 (Create Deployments)」ウィンドウでパラメーター値を⼊⼒するか、YAML ファイルを「リソースの作成 (Createresource)」ウィンドウに貼り付けることによって、アプリケーションを作成できます。

プライベート・イメージ・レジストリー内の異なる名前空間からのイメージを使⽤したい場合は、YAML ファイルでその名前空間の imagePullSecrets 値を提供する必要があります。


imagePullSecrets を作成するには、以下のようにします。

1. kubectl コマンド・ライン・インターフェースをインストールし、IBM® Cloud Private クラスターへの接続を構成します。『kubectl CLI からのクラスターへのアクセス』を参照してください。

2. デプロイメントを作成したい名前空間に切り替えます。

kubectl config set-context <cluster_CA_domain>-context --user=<user_name> --namespace=<namespace_name>

ここで、<cluster_CA_domain> は、インストール中に config.yaml ファイルに設定された認証局 (CA) ドメインです。

3. 秘密を作成します。次のコマンドを実⾏します。

kubectl create secret docker-registry myregistrykey --docker-server=<cluster_CA_domain>:8500 --docker-username=<user_name> --docker-password=<user_password> --docker-email=<user_email>

4. 秘密を表⽰します。次のコマンドを実⾏します。

kubectl get secret


NAME TYPE DATA AGE myregistrykey kubernetes.io/dockercfg 1 5d default-token-5gjfc kubernetes.io/service-account-token 3 5d

この例では、myregistrykey 秘密が、default 名前空間で使⽤可能です。

デプロイメントでの imagePullSecret の使⽤

imagePullSecrets パラメーターを、デプロイメントの YAML ファイルに追加します。以下の例に⽰すように、imagePullSecrets パラメーターを、templates セクション内の spec セクションに配置してください。

apiVersion: apps/v1beta2 kind: Deployment metadata: name: nginx-demo spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: hostNetwork: false containers: - name: nginx image: mycluster.icp:8500/developer/nginx ports: [] resources: limits: {} imagePullSecrets: - name: myregistrykey

consoleからのイメージの削除


IBM® Cloud Private management consoleから、イメージを削除できます。


1. ナビゲーション・メニューから「カタログ (Catalog)」>「イメージ (Images)」をクリックします。2. 削除するイメージを対象として「アクション」>「削除」を選択します。3. 「イメージの削除 (Remove Image)」をクリックします。イメージがmanagement consoleから削除されます。

4. プライベート・レジストリー・ストレージからイメージ・ファイルを削除します。

プライベート・レジストリー・ストレージからイメージ・ファイルを削除

IBM Cloud Private management console からイメージを削除すると、ソフト削除が⾏われます。ソフト削除では、IBM Cloud Private クラスターからイメージが削除されますが、イメージのファイルはプライベート・レジストリー・ストレージに残ります。イメージ・レジストリー・ストレージからファイルを削除するには、レジストリーのガーベッジ・コレクション (GC) ツールを使⽤する必要があります。

プライベート・レジストリー・ストレージからイメージを削除するには、以下の⼿順を実⾏します。

1. イメージ・マネージャーを無効にします。 GC プロセスの実⾏中にイメージがレジストリーにプッシュされると、新しいイメージのレイヤーが削除される危険があります。これにより、イメージが破損する可能性があります。イメージ・マネージャーを無効にするには、以下のコマンドを実⾏します。

kubectl patch svc image-manager -n kube-system -p '{"spec": {"selector": {"app": "image-manager-dummy"}}}'


service "image-manager" patched

2. ガーベッジ・コレクション・プロセスによってクリーンアップされる予定のファイルを表⽰します。

kubectl exec -it image-manager-0 -c icp-registry -n kube-system -- registry garbage-collect --dry-run /etc/docker/registry/config.yml

注: --dry-run オプションを指定すると、データは削除せず、クリーンアップの計画を表⽰します。

3. ガーベッジ・コレクション・ツールを実⾏します。

kubectl exec -it image-manager-0 -c icp-registry -n kube-system -- registry garbage-collect /etc/docker/registry/config.yml

4. オーファン・イメージ・リポジトリー・フォルダーを削除します。

kubectl exec -it image-manager-0 -c icp-registry -n kube-system -- /bin/sh -c "find /var/lib/registry/docker/registry/v2/repositories/ -maxdepth 2 -mindepth 2 | tee /tmp/image_all"

kubectl exec -i image-manager-0 -c icp-registry -n kube-system -- /bin/sh -c "registry garbage-collect --dry-run /etc/docker/registry/config.yml 2>&1 |grep 'marking manifest'| cut -d ":" -f 0 |xargs -n1 echo '/var/lib/registry/docker/registry/v2/repositories/' |sed 's/ //g'|tee /tmp/image_valid"

kubectl exec -i image-manager-0 -c icp-registry -n kube-system -- /bin/sh -c "grep -F -v -f /tmp/image_valid /tmp/image_all |tr -d '\r'| xargs -n1 rm -rf 2>&1"

5. イメージ・マネージャーを有効にします。

kubectl patch svc image-manager -n kube-system -p '{"spec": {"selector": {"app": "image-manager"}}}'



service "image-manager" patched

IBM® Cloud Private 計量サービスのための Docker イメージのラベル付け

作成した Docker イメージには、オファリングの製品 ID、名前、およびバージョンを識別するラベルを含めることができます。これらのラベルは、コンテナー・イメージの作成時に Dockerfile で指定されます。計量デーモンがこれらのラベルを発⾒し、計量対象のランタイム・メトリックを実⾏中のオファリング・インスタンスに関連付けるため

に使⽤できます。

以下のラベルを指定することができます。

com.ibm.cloud.metering.productidこのラベルを使⽤して、オファリングを⼀意的に識別する製品 ID を指定します。

com.ibm.cloud.metering.productnameこのラベルを使⽤して、⼈間が理解できるオファリング名を⽰す製品名を指定します。

com.ibm.cloud.metering.productversionこのラベルを使⽤して、オファリングのバージョン、リリース、モディフィケーション、およびフィッ

クス・レベル (v.r.m.f) を⽰す製品バージョン ID を指定します。

注:

ラベルは、⼩⽂字でなければなりません。

イメージが他のイメージのコンテナーに依存する (Docker の⽤語では、「継承する」) 場合は、継承する側のイメージに含まれるイメージを作成するときに、依存イメージのラベルが、継承する側のイメージによって上

書きされる必要があります。例えば、イメージ A がイメージ B のコンテナーに依存する (継承する) 場合、継承する側のイメージ (この例ではイメージ A) に含まれるイメージを作成するときに、依存イメージ (この例ではイメージ B) のラベルが、継承する側のイメージによって上書きされなければなりません。計量⽬的で収集されたメトリックを、デプロイされたオファリングと関連付けるために、ラベルが使⽤されま

す。これらのオファリングのライセンスは、計量サービスによるものではなく、オファリング購⼊時のエンタイトルメントのご使⽤条件に従います。計量サービスは、実⾏中オファリングのメトリックを計測して、この使⽤状況を管理者にレポートするだけです。

以下の例は、これらのラベルを使⽤した Dockerfile を⽰しています。

FROM ibmcom/ibmjava:jre RUN apt-get -y update RUN apt-get -y install curl COPY ./wlp /wlp COPY ./startup.sh / EXPOSE 9080 EXPOSE 9443 LABEL "com.ibm.cloud.metering.productid"="fbf6a96d49214c0abc6a3bc5da6e48cd" \ "com.ibm.cloud.metering.productname"="My product" \ "com.ibm.cloud.metering.productversion"="1.0.0.0" CMD /startup.sh

ワークロードの管理

アプリケーション、構成、サービス、およびポリシーを更新およびモニターする⽅法を説明します。

このガイドでは、ユーザーが Kubernetes の概念および⽤語に精通していると想定しています。 Kubernetes の主要な⽤語およびコンポーネントの定義は記述されていません。 Kubernetes の概念について詳しくは、https://v1-


https://v1-10.docs.kubernetes.io/docs/home/

10.docs.kubernetes.io/docs/home/ を参照してください。

DaemonSet の作成デプロイメントの管理 Helm リリースの管理ジョブの管理 StatefulSet の作成 ReplicaSet の管理

DaemonSet の作成

DaemonSet を作成して、ポッドのコピーをクラスター内の各ノードが実⾏することを許可できます。

DaemonSet について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/daemonset/ を参照してください。

management console から DaemonSet を作成するために、2 つの形式が使⽤可能です。

「DaemonSet の作成」ウィンドウでパラメーター値を⼊⼒することによって、または、YAML ファイルを「リソースの作成」ウィンドウに貼り付けることによって、DaemonSet を作成できます。


「DaemonSet の作成」ウィンドウを使⽤した DaemonSet の作成

1. ナビゲーション・メニューから、「ワークロード」 > 「DaemonSet」をクリックします。2. 「DaemonSet の作成」をクリックします。

3. DaemonSet の詳細を指定します。「DaemonSet の作成」ウィンドウで個々の値を指定します。いくつかのパラメーターについては、値の指定が必要です。

「⼀般」タブで、以下の値を指定します。

名前 - DaemonSet の名前。

「コンテナー設定」タブで、以下の値を指定します。

名前 - コンテナーの名前。

イメージ - コンテナーに使⽤するイメージ。プライベート・イメージ・レジストリーにあるイメージを使⽤する場合、以下の形式でイメージ名を指定する必要があります。

<cluster_CA_domain> は、インストール時に config.yaml ファイルに設定された認証局(CA) ドメインです。

<cluster_CA_domain>:8500/namespace/imagename

プロトコルおよびコンテナー・ポート - コンテナーの通信プロトコルおよびポート番号。

注: 他のパラメーターの値はオプションです。 CPU、メモリー、および GPU についてのリソース限度を指定しない場合、コンテナーは無制限にクラスター・リソースを使⽤できます。

4. 「作成」をクリックします。

「リソースの作成」ウィンドウを使⽤した DaemonSet の作成

1. ダッシュボードから、「リソースの作成」をクリックします。



https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/daemonset/

2. YAML ファイルをコピーして「リソースの作成」ダイアログ・ボックスに貼り付けます。 YAML ファイルの使⽤による DaemonSet の作成について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/daemonset/#writing-a-daemonset-spec を参

照してください。


デプロイメントの管理

デプロイメントを更新およびモニターする⽅法を説明します。

このガイドでは、ユーザーが Kubernetes の概念および⽤語に精通していると想定しています。 Kubernetes の主要な⽤語およびコンポーネントの定義は記述されていません。 Kubernetes の概念について詳しくは、https://v1-10.docs.kubernetes.io/docs/home/ を参照してください。

デプロイメントの作成デプロイメントの変更デプロイメントの削除デプロイメントのスケーリング


クラスター内でデプロイメントを作成および構成する⽅法を⽰します。

このガイドでは、ユーザーが Kubernetes の概念および⽤語に精通していると想定しています。 Kubernetes の主要な⽤語およびコンポーネントの定義は記述されていません。 Kubernetes の概念について詳しくは、https://v1-10.docs.kubernetes.io/docs/home/ を参照してください。

デプロイメントの作成 GPU リソースがアタッチされたデプロイメントの作成


名前空間に新規デプロイメントを作成します。

新規デプロイメントは、その作成者であるユーザーの名前空間に割り当てられます。管理者がデプロイメントを作成した場合は、デフォルト名前空間に割り当てられます。

management console からデプロイメントを作成するために、2 つの形式が使⽤可能です。

「デプロイメントの作成」ウィンドウでパラメーター値を⼊⼒することによって、または、YAML ファイルを「リソースの作成」ウィンドウに貼り付けることによって、デプロイメントを作成できます。


「デプロイメントの作成」ウィンドウを使⽤したデプロイメントの作成

1. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」をクリックします。2. 「デプロイメントの作成」をクリックします。

3. デプロイメント詳細を指定します。「デプロイメントの作成」ウィンドウで個々の値を指定します。

いくつかのパラメーターについては、値の指定が必要です。


https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/daemonset/#writing-a-daemonset-spec




名前 - デプロイメントの名前。レプリカ - ポッド (レプリカ) の数。デフォルト値は 1 です。







注: 他のパラメーターの値はオプションです。 CPU、メモリー、および GPU についてのリソース限度を指定しない場合、コンテナーは無制限にクラスター・リソースを使⽤できます。

4. (オプション) コンテナーに PersistentVolume をアタッチします。デプロイメントへの PersistentVolumeClaimのアタッチを参照してください。


「リソースの作成」ウィンドウを使⽤したデプロイメントの作成

1. ダッシュボードから、「リソースの作成」をクリックします。2. YAML ファイルまたは JSON ファイルをコピーして「リソースの作成」ダイアログ・ボックスに貼り付けます。 YAML ファイルの使⽤による Kubernetes デプロイメントの作成について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment を参照してください。

注: プライベート・イメージ・レジストリーから、異なる名前空間にあるイメージを使⽤したい場合は、その名前空間へのアクセス権限を持っている必要があり、YAML ファイル内にその名前空間の imagePullSecrets値を指定する必要があります。特定の名前空間の imagePullSecrets の作成を参照してください。


デプロイメントが完了したら、新規デプロイメントが「デプロイメント」ページに表⽰されます。希望列、現⾏列、準備完了列、および使⽤可能列のすべてに同じ値が表⽰されます。この値は、デプロイメント中に指定した、ポッド

(レプリカ) の数です。

デプロイメントの詳細情報を表⽰するには、デプロイメント名をクリックします。デプロイメントのプロパティーを検討し、それらが正確であることを確認してください。

インターネットからデプロイメントにアクセスするには、デプロイメントをサービスとして公開する必要がありま

す。サービスの作成を参照してください。

GPU リソースがアタッチされたデプロイメントの作成

GPU リソースがアタッチされたコンテナーを作成する⽅法を説明します。

IBM® Cloud Private における Nvidia GPU サポートの概要については、Nvidia GPU サポートを参照してください。


https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment

GPU ドライバーがワーカー・ノードにインストールされていることを確認してください。 kubectl describe nodes コマンドを使⽤して、alpha.kubernetes.io/nvidia-gpu が検出されることを検証できます。 Kubernetes は、alpha.kubernetes.io/nvidia-gpu を使⽤して GPU リソースを⽰します。

IBM Cloud Private は、nvidia-docker プロジェクトにあるイメージに対して組み込み GPU サポートを提供します。GPU リソースを指定するには、デプロイメントに nvidia-docker プロジェクトからのイメージが指定される必要があります。

Linux® on Power® (ppc64le) ノードの場合、nvidia/cuda-ppc64le Docker Hub リポジトリー内のイメージか、コンテンツから派⽣させたイメージを使⽤します。

Linux® 64-bit ノードの場合、nvidia/cuda Docker Hub リポジトリー内のイメージか、コンテンツから派⽣させたイメージを使⽤します。

management console からデプロイメントを作成するために、2 つの形式が使⽤可能です。

「デプロイメントの作成」ウィンドウでパラメーター値を⼊⼒することによって、または、YAML ファイルを「リソースの作成」ウィンドウに貼り付けることによって、デプロイメントを作成できます。


始める前に、デプロイメントのためのノードの準備ができていることを確認してください。 GPU ワーカー・ノードの構成を参照してください。

「デプロイメントの作成」ウィンドウを使⽤した、GPU リソースがアタッチされたデプロイメントの作成

1. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」 > 「デプロイメントの作成」をクリックします。

2. 「コンテナー設定」タブで、デプロイメントのために要求される GPU の数を指定します。この値は正整数でなければなりません。

3. デプロイメントに必要な他のすべてのパラメーター・オプションを⼊⼒します。4. 「作成」をクリックします。

「リソースの作成」ウィンドウを使⽤したデプロイメントの作成

1. gpu-demo.yaml ファイルを作成します。このサンプル gpu-demo.yaml ファイルでは、単⼀の GPU リソースがアタッチされたコンテナー・デプロイメントが作成されます。

このサンプル・デプロイメントでは、Linux® 64-bit システム向けの nvidia-docker イメージである nvidia/cuda:7.5-runtime イメージが使⽤されています。このイメージは、nvidia/cuda Docker Hub リポジトリーから取得できます。 Power Systems の場合、nvidia/cuda-ppc64le Docker Hub リポジトリーにある nvidia/cuda-ppc64le イメージの 1 つを使⽤します。

apiVersion: apps/v1beta2 kind: Deployment metadata: name: gpu-demo spec: replicas: 1 template: metadata: labels: run: gpu-demo spec: containers: - name: gpu-demo image: nvidia/cuda:7.5-runtime command:


https://github.com/NVIDIA/nvidia-docker

https://hub.docker.com/r/nvidia/cuda-ppc64le

https://hub.docker.com/r/nvidia/cuda/

https://hub.docker.com/r/nvidia/cuda/

https://hub.docker.com/r/nvidia/cuda-ppc64le

- "/bin/sh" - "-c" args: - nvidia-smi && tail -f /dev/null resources: limits: alpha.kubernetes.io/nvidia-gpu: 1

1. ダッシュボードから、「リソースの作成」をクリックします。2. gpu-demo.yaml ファイルをコピーして「リソースの作成」ダイアログ・ボックスに貼り付けます。3. 「作成」をクリックします。

コンテナー内部で GPU リソースが検出されるかどうかの確認

1. kubectl コマンド・ライン・インターフェースをインストールします。 kubectl CLI からのクラスターへのアクセスを参照してください。

2. 実⾏中コンテナーのリストを表⽰するため、次のコマンドを実⾏します。

kubectl get pods

返される出⼒から gpu-demo デプロイメントを⾒つけることができます。

3. gpu-demo デプロイメントのログにアクセスします。以下に例を⽰します。

kubectl logs gpu-demo-3638364752-zkqel


Tue Feb 7 08:38:11 2017 +------------------------------------------------------+ | NVIDIA-SMI 352.63 Driver Version: 352.63 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 GeForce GT 730 Off | 0000:01:00.0 N/A | N/A | | 36% 41C P8 N/A / N/A | 4MiB / 1023MiB | N/A Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | 0 Not Supported | +-----------------------------------------------------------------------------+

デプロイメントが完了したら、新規デプロイメントが「デプロイメント」ページに表⽰されます。希望列、現⾏列、準備完了列、および使⽤可能列のすべてに同じ値が表⽰されます。この値は、デプロイメント中に指定した、ポッド

(レプリカ) の数です。

デプロイメントの詳細情報を表⽰するには、デプロイメント名をクリックします。デプロイメントのプロパティーを検討し、それらが正確であることを確認してください。

インターネットからデプロイメントにアクセスするには、デプロイメントをサービスとして公開する必要がありま

す。サービスの作成を参照してください。

デプロイメントの変更

デプロイメントのプロパティーを編集します。


デプロイメントの JSON ファイルを編集することによって、デプロイメントのプロパティーを変更できます。


1. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」をクリックします。2. 変更したいデプロイメントに対して、「アクション」 > 「編集」を選択します。そのデプロイメントの JSONファイルが表⽰されます。

3. プロパティーを更新します。4. 「送信」をクリックします。デプロイメントが更新されます。ポッド・テンプレートを変更した場合、ロールアウトが開始されます。

変更を確認するため、デプロイメント詳細を検討してください。

デプロイメントの削除

不要になったデプロイメントを削除します。

デプロイメントを削除すると、その基礎となっているオブジェクト (ReplicaSet、ポッド、およびサービス) がすべて削除されます。


1. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」をクリックします。2. 削除したいデプロイメントに対して、「アクション」 > 「削除」を選択します。「デプロイメントの削除」ウィンドウが表⽰されます。

3. 「削除」をクリックします。

選択したデプロイメントがデプロイメント・リストから削除され、その基礎となっているオブジェクトもすべて削除

されます。

デプロイメントのスケーリング

デプロイメント・インスタンスの数を⼿動で調整します。

デプロイメント・インスタンスの数を⼿動で調整できます。

注: デプロイメント・レプリカの数を⾃動的に調整するポリシーを定義するには、ポリシーの管理を参照してください。


1. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」をクリックします。2. スケーリングしたいデプロイメントに対して、「アクション」 > 「スケーリング」を選択します。「デプロイメントのスケーリング」ウィンドウが表⽰されます。

3. 必要なポッドの数を⼊⼒します。4. 「デプロイメントのスケーリング」をクリックします。デプロイされたポッドの数が、必要な新しいポッド数に⼀致するように増減されます。

デプロイメントの「希望」、「現⾏」、「準備完了」、および「使⽤可能」の値が更新されます。

Helm リリースの管理


管理できる Helm リリースのリストを表⽰します。 Helm Glossary に、リリースについての詳しい説明が記載されています。

Helm リリースの表⽰Helm リリース・バージョンのアップグレードHelm リリース・バージョンのロールバックHelm リリースの削除

Helm リリースの表⽰

Helm リリースを表⽰するには、以下のステップを実⾏します。

1. ナビゲーション・メニューから、「ワークロード」 > 「Helm リリース」をクリックします。2. 各リリースをクリックして、使⽤可能なすべてのリソースの詳細を表⽰します。

Helm リリース・バージョンのアップグレード

現⾏の Helm リリースを、使⽤可能な任意のバージョン変更 (パッチ、マイナー、またはメジャー) にアップグレードすることができます。アップグレード中に、チャート構成パラメーターを変更できます。

表 1. Helm リリースのアップグレード・パス

アップグレード・パス現⾏バージョン新バージョン

パッチ 1.0.0 1.0.1

マイナー 1.0.0 1.1.0

メジャー 1.0.0 2.0.0

Helm リリース・バージョンをアップグレードするには、以下のステップを実⾏します。

1. ナビゲーション・メニューから、「ワークロード」 > 「Helm リリース」をクリックします。2. 「AVAILABLE VERSION」列を検討して、Helm リリースに対して使⽤可能なバージョン更新があるかどうかを確認します。

3. アップグレードしたい Helm リリースに対して、「アクション」 > 「アップグレード」を選択します。

4. 「バージョン」オプションから、必要なパッチ、メジャーまたはマイナーの更新バージョンを選択します。

注: メニューには、現⾏バージョンよりも前のバージョンの Helm リリースが含まれています。

5. その他の構成設定を必要に応じて変更します。注: Helm リリースのアップグレード時にはパラメーターが検証されないため、必ず構成パラメーターを確認してください。

6. 「アップグレード」をクリックします。

Helm リリース・バージョンのロールバック

現⾏ Helm リリースを、以前に構成されたリリースの任意の旧バージョンにロールバックすることができます。

Helm リリース・バージョンをロールバックするには、以下のステップを実⾏します。

1. ナビゲーション・メニューから、「ワークロード」 > 「Helm リリース」をクリックします。2. ロールバックしたい Helm リリースに対して、「アクション」 > 「ロールバック」を選択します。3. ロールバック先にしたいバージョンを選択します。4. 「ロールバック」をクリックします。

Helm リリースの削除


https://github.com/kubernetes/helm/blob/master/docs/glossary.md

Helm リリースを削除するには、以下のステップを実⾏します。

1. ナビゲーション・メニューから、「ワークロード」 > 「Helm リリース」をクリックします。2. ロールバックしたい Helm リリースに対して、「アクション」 > 「削除」を選択します。3. 「削除」をクリックします。

ジョブの管理

さまざまな種類のジョブを作成する⽅法を説明します。

このガイドでは、ユーザーが Kubernetes の概念および⽤語に精通していると想定しています。 Kubernetes の主要な⽤語およびコンポーネントの定義は記述されていません。 Kubernetes の概念について詳しくは、http://kubernetes.io/docs/reference/ を参照してください。

ジョブの作成 CronJob の作成

ジョブの作成

ポッドが確実にデプロイされるように、または複数のポッドが並⾏して実⾏されるようにジョブを作成します。

バッチ・ジョブについて詳しくは、https://v1-10.docs.kubernetes.io/docs/user-guide/jobs を参照してください。

management console からアプリケーションを作成するために、2 つの形式が使⽤可能です。

「ジョブの作成」ウィンドウでパラメーター値を⼊⼒することによって、または、YAML ファイルを「リソースの作成」ウィンドウに貼り付けることによって、ジョブを作成できます。


「ジョブの作成」ウィンドウを使⽤したジョブの作成

1. ナビゲーション・メニューから、「ワークロード」 > 「ジョブ」をクリックします。2. 「ジョブの作成」をクリックします。

3. ジョブ詳細を指定します。「ジョブの作成」ウィンドウで個々の値を指定します。



名前


名前 - コンテナー名。




プロトコルおよびポート - コンテナーの通信プロトコルおよびポート番号。


http://kubernetes.io/docs/reference/

https://v1-10.docs.kubernetes.io/docs/user-guide/jobs

注: 他のパラメーターの値はオプションです。

4. (オプション) コンテナーに PersistentVolume ストレージをアタッチします。『アプリケーションへのボリュームの接続』を参照してください。


「リソースの作成」ウィンドウを使⽤したジョブの作成

1. ダッシュボードから、「リソースの作成」をクリックします。2. YAML ファイルまたは JSON ファイルをコピーして「リソースの作成」ダイアログ・ボックスに貼り付けます。 YAML ファイルの使⽤による Kubernetes バッチ・ジョブの作成について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#running-an-example-job を参照してください。



CronJob の作成

CronJob は、時間ベースのバッチ・ジョブを管理するために使⽤されます。それらのジョブは、指定の時点に 1 回実⾏されるか、指定の時点に繰り返し実⾏されます。

CronJobs について詳しくは、https://v1-10.docs.kubernetes.io/docs/user-guide/cron-jobs を参照してください。

management console からアプリケーションを作成するために、2 つの形式が使⽤可能です。

「CronJob の作成」ウィンドウでパラメーター値を⼊⼒することによって、または、YAML ファイルを「リソースの作成」ウィンドウに貼り付けることによって、CronJob を作成できます。


「CronJob の作成」ウィンドウを使⽤した CronJob の作成

1. CronJob を作成するには、以下のようにします。2. ナビゲーション・メニューから、「ワークロード」 > 「ジョブ」をクリックし、次に「CronJob」をクリックします。

3. 「CronJob の作成」をクリックします。

4. ジョブ詳細を指定します。「CronJob の作成」ウィンドウで個々の値を指定します。


名前

スケジュール - Cron フォーマットでのデプロイメント・スケジュール。





https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#running-an-example-job

https://v1-10.docs.kubernetes.io/docs/user-guide/cron-jobs



プロトコルおよびポート - コンテナーの通信プロトコルおよびポート番号。

注: 他のパラメーターの値はオプションです。

5. コンテナーに PersistentVolume ストレージをアタッチします。『アプリケーションへのボリュームの接続』を参照してください。


「リソースの作成」ウィンドウを使⽤した CronJob の作成

1. ダッシュボードから、「リソースの作成」をクリックします。2. YAML ファイルまたは JSON ファイルをコピーして「リソースの作成」ダイアログ・ボックスに貼り付けます。 YAML ファイルの使⽤による Kubernetes CronJob の作成について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#creating-a-cron-job を参照してください。



StatefulSet の作成

ネットワークおよびストレージの ID が保証されたポッドを作成します。

通常のポッド・デプロイメントは、ID の概念が弱い設計であり、ステートレスなユニットとして扱われます。ポッドが正常でないか、新しいバージョンで置き換えられる場合、システムは古いポッドまたは正常でないポッドを削除

します。 StatefulSet とも呼ばれるステートフル・アプリケーションの導⼊によって、ID の概念が強いアプリケーションを作成できるようになります。ステートフル・アプリケーションは、クラウドにおいてストレージをオンデマンドでプロビジョンすることもできます。

ステートフル・アプリケーション、すなわち StatefulSets について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/statefulset/ を参照してください。

management console から StatefulSet を作成するために、2 つの形式が使⽤可能です。

「StatefulSet の作成」ウィンドウでパラメーター値を⼊⼒することによって、または、YAML ファイルを「リソースの作成」ウィンドウに貼り付けることによって、ステートフル・アプリケーションを作成できます。


「StatefulSet の作成」ウィンドウを使⽤した StatefulSet の作成

1. ナビゲーション・メニューから、「ワークロード」 > 「StatefulSet」をクリックします。2. 「StatefulSet の作成」をクリックします。

3. アプリケーション詳細を指定します。



https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#creating-a-cron-job

https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/statefulset/


名前 - StatefulSet の名前。サービス名 - ポッドへのアクセス権限を定義するサービス。レプリカ - ポッド (レプリカ) の数。デフォルト値は 1 です。







**注:** 他のパラメーターの値はオプションです。 CPU、メモリー、および GPU についてのリソース限度を指定しない場合、コンテナーは無制限にクラスター・リソースを使用できます。

1. (オプション) コンテナーに PersistentVolume ストレージをアタッチします。『アプリケーションへのボリュームの接続』を参照してください。


「リソースの作成」ウィンドウを使⽤した StatefulSet の作成

1. ダッシュボードから、「リソースの作成」をクリックします。2. YAML ファイルまたは JSON ファイルをコピーして「リソースの作成」ダイアログ・ボックスに貼り付けます。 YAML ファイルの使⽤による StatefulSet の作成について詳しくは、https://v1-10.docs.kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#creating-a-statefulset を参照してください。



ReplicaSet の管理

ReplicaSet を使⽤して、デプロイメント内のポッド数の作成および管理を⾏います。

ReplicaSet は、常に正しい数のポッドが実⾏中になることを保証します。 ReplicaSet によって管理されるポッドは、障害が発⽣すると⾃動的にスケジュール変更されます。障害には、ノード問題やネットワーク問題があります。

ReplicaSet は、ポッド・マネージャーとして Replication Controller に置き換わるものです。 ReplicaSets について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/replicaset/ を参照してください。

クラスター内のすべての ReplicaSet のリストを表⽰するには、ナビゲーション・メニューから「ワークロード」 >「ReplicaSet」をクリックします。このビューでは、ReplicaSet を名前空間でフィルタリングすることもできます。


ReplicaSet の作成ReplicaSet のスケーリング


https://v1-10.docs.kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#creating-a-statefulset

https://v1-10.docs.kubernetes.io/docs/concepts/workloads/controllers/replicaset/

ReplicaSet の更新

ReplicaSet の作成

1. ナビゲーション・メニューから、「ワークロード」 > 「ReplicaSet」をクリックします。2. 名前空間ドロップダウン・メニューから名前空間を選択します。名前空間が選択されない場合、ReplicaSet はdefault 名前空間に作成されます。

3. 「ReplicaSet の作成」をクリックします。

4. ReplicaSet の詳細を指定します。いくつかのパラメーターについては、値の指定が必要です。

5. 「⼀般」タブで、以下の値を指定します。

名前 - ReplicaSet の名前。レプリカ - ポッド (レプリカ) の数。デフォルト値は 3 です。

6. 「コンテナー設定」タブで、以下の値を指定します。


イメージ - コンテナーに使⽤するイメージ。プライベート・イメージ・レジストリーにあるイメージを使⽤する場合、以下の形式でイメージ名を指定する必要があります。<cluster_CA_domain> は、インストール時に config.yaml ファイルに設定された認証局 (CA) ドメインです。


プロトコルおよびコンテナー・ポート - コンテナーの通信プロトコルおよびポート番号。注: 他のパラメーターの値はオプションです。


ReplicaSet のスケーリング

1. ナビゲーション・メニューから、「ワークロード」 > 「ReplicaSet」をクリックします。2. スケーリングしたい ReplicaSet に対して、「アクション」 > 「スケーリング」を選択します。3. ポッドまたはインスタンスの数を必要に応じて指定します。4. 「ReplicaSet のスケーリング」をクリックします。

ReplicaSet の更新

1. ナビゲーション・メニューから、「ワークロード」 > 「ReplicaSet」をクリックします。2. 変更したい ReplicaSet に対して、「アクション」 > 「編集」を選択します。その ReplicaSet の JSON ファイルが表⽰されます。

3. プロパティーを更新します。4. 「送信」をクリックします。 ReplicaSet が更新されます。

サービス

アプリケーションをサービスとして公開することによって、アプリケーションへの外部アクセスを提供します。

サービスの作成サービスの変更サービスの削除サービスの有効化と無効化


IBM® Cloud Private でのサービス・カタログ・リソースの使⽤

サービスの作成

ネットワークの外部からデプロイメントにアクセスすることを許可するには、デプロイメントをサービスとして公開

します。

management console からサービスを作成するために、2 つの形式が使⽤可能です。

「サービスの作成」ウィンドウでパラメーター値を⼊⼒することによって、または、YAML ファイルを「リソースの作成」ウィンドウに貼り付けることによって、サービスを作成できます。


「サービスの作成」ウィンドウを使⽤したサービスの作成

1. ナビゲーション・メニューから、「ネットワーク・アクセス」 > 「サービス」をクリックします。2. 「サービスの作成」をクリックします。

3. サービス詳細を指定します。「サービスの作成」ウィンドウで個々の値を指定します。



名前 - サービスの名前。公開⽅式 (Expose method) - デプロイメントを公開する⽅式を選択します。

ClusterIPNodePort

クラスター IP - クラスター IP アドレスが指定されない場合は⾃動的に⽣成されます。セッション・アフィニティー

「ポート」タブで、以下の値を指定します。

接続詳細を定義します。

「プロトコル」リストから、プロトコルの接続を選択します。

接続の名前を⼊⼒します。

「ポート」フィールドに、サービス・アクセス・ポイントを指定します (例: 80)。「targetPort」フィールドに、コンテナー内部で実⾏中のサービスが使⽤するポート番号を指定します (例: 8080)。NodePort ⽅式を使⽤する場合は、「NodePort」フィールドにノード・ポートを指定します (例: 31888)。デフォルトのノード・ポート範囲は 31000 から 32000 です。

「セレクター」タブで、以下の値を指定します。キーと値のペアとして、サービスを作成する対象のデプロイメントを指定します。

セレクター - app値 - デプロイメントの名前を指定します


「リソースの作成」ウィンドウを使⽤したサービスの作成

1. ダッシュボードから、「リソースの作成」をクリックします。2. YAML ファイルまたは JSON ファイルをコピーして「リソースの作成」ダイアログ・ボックスに貼り付けます。 YAML ファイルの使⽤による Kubernetes サービスの作成について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/services-networking/service/#defining-a-service を参照してください。



https://v1-10.docs.kubernetes.io/docs/concepts/services-networking/service/#defining-a-service

サービスの変更

サービスを更新します。

1. ナビゲーション・メニューから、「ネットワーク・アクセス」 > 「サービス」をクリックします。2. 「アクション」 > 「編集」を選択します。サービスの JSON ファイルが表⽰されます。3. サービスのプロパティーを更新します。4. 「送信」をクリックします。


デプロイメントからの外部アクセスを認可するサービスを削除します。


1. ナビゲーション・メニューから、「ネットワーク・アクセス」 > 「サービス」をクリックします。2. 削除したいサービスに対して、「アクション」 > 「削除」を選択します。「デプロイメントの削除」ウィンドウが表⽰されます。

3. 「削除」をクリックします。

選択したサービスがサービス・リストから削除されます。

サービスの有効化と無効化

service-catalog、metering、および monitoring のサービスは、IBM® Cloud Private のインストール後に不要であれば無効にすることができます。 istio、vulnerability-advisor、および custom-metrics-adapter のサービスはデフォルトで無効になっています。

必要なユーザー・タイプまたはアクセス・レベル: クラスター管理者またはチーム管理者。サービスを無効にする場合は、Admin ユーザーとして helm コマンド・ライン・インターフェース (CLI) を構成する必要があります。

1. サービスを有効または無効にするには、config.yaml で disabled_management_services パラメーターのサービスを追加または削除します。

2. vulnerability-advisor サービスを有効にする場合は、次のように hosts ファイルを更新して、新しい脆弱性アドバイザー・ノードをデプロイすることも必要です。

[master] xxx ..... zzz [va] new-va-node1 new-va-node2 new-va-node3

次のコマンドを実⾏して、脆弱性アドバイザー・ノードをデプロイします。

docker run --rm -t -e LICENSE=accept --net=host -v $(pwd):/installer/cluster ibmcom/icp-inception:2.1.0.3-ee va

3. サービスを有効にする場合は、次のようにアドオン・コマンドを実⾏します。

docker run --rm -t -e LICENSE=accept --net=host -v $(pwd):/installer/cluster ibmcom/icp-inception:2.1.0.3-ee addon


4. サービスを無効にする場合は、次のコマンドを実⾏します。

helm delete --purge --tls service-identifier

IBM Cloud Private CLI を使⽤したサービス ID の作成

前提条件

Kubernetes コマンド・ライン・ツール kubectl をインストールし、セットアップします。 Install and Set Upkubectl を参照してください。注: バージョン 1.9.1 をインストールする必要があります。

IBM Cloud CLI をインストールし、セットアップします。まず、CLI およびツールの概要を参照してください。

IBM Cloud Private CLI プラグインをインストールします。まず、IBM Cloud Private CLI のインストールを参照してください。

サービス ID の作成

1. トークンを⽣成するために IBM Cloud Private にログインします。パスワードを求めるプロンプトがコマンドから出されます。

bx pr login -a https://<cluster-domain-name>:8443 -u <username> --skip-ssl-validation

2. 次のコマンドを実⾏して、IAM コマンドおよびデータをリストします。

bx pr iam

Output ------ NAME: bx pr iam - Group of commands to manage identities and access to resources. USAGE: bx pr iam command [arguments...][command options] COMMANDS: roles List roles service-api-key List details of a service API key service-api-key-create Create a service API key service-api-key-delete Delete a service API key service-api-key-update Update a service API key service-api-keys List all API keys of a service service-id Display details of a service ID service-id-create Create a service ID service-id-delete Delete a service ID service-id-update Update a service ID service-ids List all service IDs. service-policies List all service policies of specified service service-policy Display details of a service policy service-policy-create Create a service policy service-policy-delete Delete a service policy service-policy-update Update a service policy services List services help

bx pr iam roles

Output ------ Getting system defined roles as admin... OK


https://kubernetes.io/docs/tasks/tools/install-kubectl/

https://console.bluemix.net/docs/cli/index.html#overview

Name ID Description Viewer crn:v1:icp:private:iam::::role:Viewer Viewers can take actions that do not change state (i.e. read only). ClusterAdministrator crn:v1:icp:private:iam::::role:ClusterAdministrator ClusterAdministrators can take all actions including the ability to manage access control. Administrator crn:v1:icp:private:iam::::role:Administrator Administrators can take all actions including the ability to manage access control. Editor crn:v1:icp:private:iam::::role:Editor Editors can take actions that can modify the state and create/delete sub-resources. Operator crn:v1:icp:private:iam::::role:Operator Operators can take actions required to configure and operate resources.

bx pr iam services

Output ------ Getting system defined services as admin... OK ID Name Display Name Supported Roles 5adf7987e6ace7000a023556 idmgmt service-identity-manager ClusterAdministrator, Operator, Editor, Viewer, Administrator 5adf7987e6ace7000a023557 idprovider service-identity-provider ClusterAdministrator, Operator, Editor, Viewer, Administrator 5adf7987e6ace7000a023558 idauth service-auth-service ClusterAdministrator, Operator, Editor, Viewer, Administrator 5adf7987e6ace7000a023559 identity service-identity ClusterAdministrator, Operator, Editor, Viewer, Administrator 5adf79e1fc55aa00c8e05bf1 helm-api-service helmapi-repos ClusterAdministrator, Administrator, Operator, Editor, Viewer 5adf79e7fc55aa00c8e05bf2 elasticsearch-service elasticsearch ClusterAdministrator, Administrator, Operator 5adf79e8fc55aa00c8e05bf3 service-monitoring-service service-monitoring ClusterAdministrator, Administrator, Operator

3. 次のコマンドを使⽤して、ターゲット名前空間を設定します。

bx pr target -n kube-system

Output ------ API endpoint: https://8.37.204.878:8443 User: admin Account: id-my-account Namespace: kube-system

4. 次のコマンドを実⾏して、サービスのサービス ID を作成します。ここで、NAME は <meteringserviceId>で、[-d, --description DESCRIPTION] は <service id for metering> です。

bx pr iam service-id-create <meteringserviceId> -d <service id for metering>

Output ------ Creating service ID meteringserviceId bound to current account as admin... OK Service ID meteringserviceId is created successfully Name meteringserviceId Description service id for metering CRN crn:v1:icp:private:k8::n/kube-system::serviceid:ServiceId-58451b31-


607b-42b4-99c8-1ceeea96bb48 Bound To crn:v1:icp:private:k8::n/kube-system:::

アプリケーションで必要な特定のサービスにアクセスするために、サービス ID の管理、API 鍵の作成と管理、ポリシーの作成と管理を⾏います。サービス、API 鍵、ポリシーのコマンドと例については、IBM CloudPrivate CLI のサービス API 鍵のコマンドを参照してください。

IBM® Cloud Private でのサービス・カタログ・リソースの使⽤

サービス・カタログを使⽤すると、サービスがどのように作成または管理されるのかについて詳しく知らなくても、

ブローカーからのサービスを使⽤することができ、それらのサービスを使⽤するようにアプリケーションを簡単に構

成することもできます。

サービス・カタログは、Open Service Broker API と互換の 1 つ以上のサービス・ブローカーへの Kubernetes ネイティブなインターフェースを提供します。

IBM Cloud Private バージョン 2.1.0.3 には、ベータ版 v0.1.11 のサービス・カタログが組み込まれています。詳しくは、https://github.com/kubernetes-incubator/service-catalog/tree/v0.1.11/docs を参照してください。

v0.1.11 で追加された変更の要約については、https://github.com/kubernetes-incubator/service-catalog/releases/tag/v0.1.11 を参照してください。

サービス・カタログ・リソースの管理

サービス・カタログ・コンポーネントによって、使⽤できる新しい Kubernetes リソースが 4 つ追加されました。

コマンド・ライン・インターフェースを使⽤したサービス・カタログ・リソースの管理

kubectl コマンド・ライン・インターフェースを使⽤することによって、コマンド・ラインでこれらのリソースを処理できます。以下の例を参照してください。

表 1. サービス・カタログの Kubernetes リソースリソース有効範囲使⽤例

ClusterServiceBrokerクラスター kubectl get clusterservicebrokers

ClusterServiceClass クラスター kubectl get clusterserviceclasses

ClusterServicePlan クラスター kubectl get clusterserviceplans

ServiceInstance 名前空間 kubectl get serviceinstances

ServiceBinding 名前空間 kubectl get servicebindings

これらの 4 つのリソースを使⽤すると、IBM Cloud Private クラスターにデプロイされたサービスまたは IBM CloudPrivate 外部のサービスとの統合によって、IBM Cloud Private クラスターの機能を拡張できます。

サービス・カタログ・リソースの詳細

ClusterServiceBroker

ClusterServiceBroker (またはサービス・ブローカー) は、 1 つ以上のサービスからなる集合を管理するエンティティーです。

ClusterServiceClass

ClusterServiceClass は、サービス・カタログ内の構成体です。 ClusterServiceClass は、ブローカーが提供するサービスと、各サービスに対して提供されている関連付けられたプランを記述します。


https://github.com/kubernetes-incubator/service-catalog/tree/v0.1.11/docs

https://github.com/kubernetes-incubator/service-catalog/releases/tag/v0.1.11

ClusterServicePlan

ClusterServicePlan は、サービス・カタログ内の構成体です。 ClusterServicePlan は、サービスに対して提供されているプランを記述します。

ServiceInstance

ServiceInstance は、プロビジョンされた ClusterServiceClass のインスタンスです。管理対象サービスの新しい具象インスタンスを 1 つ以上のクラスター内アプリケーションで使⽤できるようにするためには、ServiceInstance を作成します。

ServiceBinding

ServiceBinding は、アプリケーションが ServiceInstance を参照および使⽤するためのものです。アプリケーションが ServiceInstance を使⽤する必要がある場合は、ServiceBinding を作成してください。 ServiceBinding を作成すると、ServiceInstance によって表されるサービスの接続詳細および資格情報を含んでいる Kubernetes 秘密も作成されます。

IBM Cloud Private management console を使⽤したサービス・カタログ・リソースの管理

ブローカーを Helm チャートとして IBM Cloud Private Catalog management console からロードおよびデプロイできます。それらのチャートには、登録および認証秘密作成テンプレートも組み込まれている必要があります。 Helm チャートは、クラスターの内部にデプロイされる必要のあるブローカーの場合、ブローカーのデプロイメント⽤のテン

プレートを含むことができます。

ブローカーのデプロイまたは登録の後にデプロイメントに使⽤可能なブローカー・サービスが、「Catalog」ビューに Helm チャートと共に表⽰されます。

サービス・ブローカーがプラットフォームに登録されると、サービスと、各サービスの内部的なプランが、Catalogで選択可能なオファリングとして利⽤可能になります。

IBM Cloud Private では、サービスおよびプランの詳細が含まれるサービス詳細ページ、サービスのデプロイメントとサービス・インスタンスの作成、および、サービス・バインディング (サービスがバインド可能である場合) がサポートされます。現⾏の製品バージョンでは、以下の新機能が使⽤可能です。

ブローカー対象サービスで指定された、サービス・インスタンス作成⽤の構成パラメーターのサポート。

すべての clusterserviceclass とプランを取得するためにブローカー・チャートと登録をデプロイおよび登録する権限を clusteradmin のみに許可 (RBAC)。チームおよびユーザー・アクセス権限に基づくカタログ・ビューでの clusterserviceclass およびclusterserviceplan のチームおよびキュレーション clusterserviceclass および clusterserviceplan への割り当て (RBAC)。

「ブローカー対象サービス」ビュー

特定のブローカー・サービスおよびプランに対してインスタンスが作成されると、それらのブローカー対象サービ

ス・インスタンスを「ブローカー対象サービス」ビューに表⽰できます。「ワークロード」 > 「ブローカー対象サービス」をクリックして、このビューを表⽰します。特定のブローカー・サービス・インスタンスを選択して、そのサービス・インスタンスにバインディング・オブジェクトが作成されているかどうかを確認できます。

ブローカー・サービス・インスタンスを削除するには、バインディング・リソースが最初に削除されていることを確

認します。

ダッシュボード URL


ブローカー・サービス・インスタンスがダッシュボード URL を定義している場合、その URL は、概要表で「起動」というラベルのクリック可能なリンクとして表⽰されます。特定のブローカー・サービス・インスタンスを選択すると、「起動」というラベルのボタンとしてリンクが使⽤可能になります。

「サービス・ブローカー」ビュー

サービス・ブローカーがプラットフォームに登録されると、「サービス・ブローカー」ビューにサービス・ブローカーが表⽰されます。特定のサービス・ブローカーを選択して、選択したサービス・ブローカーが提供するサービスおよびプランのリストを表⽰できます。

「ClusterServiceBroker の追加」または「リソースの作成」を使⽤して、ダイアログ・ウィンドウで必要なフィールドを指定することにより、サービス・ブローカーをプラットフォームに直接登録できます。

ServiceBroker の使⽤

ServiceBroker の使⽤

サービス・ブローカーをデプロイして、使⽤可能なサービスおよびプランの表⽰、使⽤可能なサービスおよびプラン

からのインスタンスの作成、および、サービス・インスタンスへ接続するためのバインディングの作成を⾏うことが

できます。

以下のステップは、コミュニティー・サービス・ブローカー・サンプルをデプロイする⽅法を⽰します。 OpenService Broker API 仕様に準拠する独⾃のサービス・ブローカーを開発する場合も、それをデプロイするためにこのサンプル⼿順を使⽤できます。

コミュニティー・サービス・ブローカー・サンプルは、クラスター内部で実⾏するブローカー・サーバーを実装しま

す。クラスター内部またはクラスター外部のブローカー・サーバーにアクセスできます。以下の Helm コマンドを実⾏することによって、このブローカー・サーバーをクラスターにデプロイします。

helm install charts/ups-broker --name ups-broker --namespace ups-broker

ClusterServiceBroker の登録ClusterServiceClass および ClusterServicePlan の表⽰ServiceInstance の作成ServiceInstance の ServiceBinding の作成ServiceInstance のアンバインドServiceInstance の削除ClusterServiceBroker の削除

ClusterServiceBroker の登録

1. ブローカーまたは ClusterServiceBroker を登録します。インスタンスを作成するサービスおよびプランを表⽰するには、その前に、ClusterServiceBroker リソースを使⽤してブローカーをサービス・カタログに登録する必要があります。

1. broker.yaml ファイルを作成します。このファイルには、ブローカー詳細が含まれます。ブローカーの名前 (name) および URL (url) の値を指定する必要があります。 broker.yaml ファイルは、以下のコードのようになります。

yaml apiVersion: servicecatalog.k8s.io/v1beta1 kind: ClusterServiceBroker metadata: name: ups-broker


spec: url: http://ups-broker-ups-broker.ups-broker.svc.cluster.local

2. 次のコマンドを実⾏します。

kubectl create -f broker.yaml

ClusterServiceClass および ClusterServicePlan の表⽰

各サービスは、対応する 1 つの ServiceClass リソースと、関連付けられた 1 つ以上のプランを持つことができます。次のコマンドを実⾏します。

登録されたサービスを表⽰します。

kubectl get clusterserviceclasses

登録されたプランを表⽰します。

kubectl get clusterserviceplans

ServiceInstance の作成

1. サービス・クラスの特定のプロビジョンされたインスタンスである、ServiceInstance を作成します。サービス・クラスをアプリケーションが使⽤するには、その前にサービス・クラスのインスタンスを作成する必要が

あります。

1. サービス・インスタンスの instance.yaml ファイルを作成します。 instance.yaml ファイルには、以下のコード例のように、インスタンスの名前 (name) と、使⽤するスペック (spec) が含まれます。

yaml apiVersion: servicecatalog.k8s.io/v1beta1 kind: ServiceInstance metadata: name: ups-instance namespace: test-ns spec: clusterServiceClassExternalName: user-provided-service clusterServicePlanExternalName: default parameters: credentials: name: root password: letmein

2. インスタンスを作成します。次のコマンドを実⾏します。

bash kubectl create -f instance.yaml

ServiceInstance の ServiceBinding の作成

1. ServiceInstance をアプリケーションにバインドするため、サービス・インスタンスのアクセス資格情報である ServiceBinding を作成します。

1. サービス・インスタンスをアプリケーションにバインドする binding.yaml ファイルを作成します。以下のコードに⽰すように、バインディングの名前 (name) および秘密名 (secretName) を指定する必要があります。

yaml apiVersion: servicecatalog.k8s.io/v1beta1 kind: ServiceBinding metadata:


name: <binding_name> namespace: test-ns spec: secretName: <secret_name> instanceRef: name: ups-instance

ポッド・セレクター・ラベルについての詳細は Kubernetes 資料にあります。 https://v1-10.docs.kubernetes.io/docs/concepts/overview/working-with-objects/labels/ を参照してください。

2. バインディングを作成します。次のコマンドを実⾏します。

kubectl create -f binding.yaml

サービス・カタログ・コントローラーは、サービス・インスタンスの接続詳細および資格情報を含んで

いる Kubernetes 秘密を作成します。

3. バインディング詳細を表⽰します。バインディング詳細を表⽰します。次のコマンドを実⾏します。

kubectl get servicebindings service_binding -o yaml

4. アプリケーションに接続するのに必要な秘密詳細を表⽰します。次のコマンドを実⾏します。

kubectl get secrets <secret_name> -o yaml

ここで、<secret_name> は、バインディングで使⽤される秘密名です。 <secret_name> は、次のテキストのようになります。

apiVersion: v1 data: . . Secret data to connect to the database instance . . kind: Secret metadata: . . metadata parameters and values . . type: Opaque

ServiceInstance のアンバインド

インスタンスをアプリケーションからアンバインドするには、作成した ServiceBinding を削除します。バインディングを削除すると、そのバインディングが使⽤する秘密も削除されます。

1. インスタンスをアンバインドするには、以下のコマンドを実⾏します。

kubectl delete -n test-ns servicebindings ups-binding

ここで、ups-binding は、削除するバインディングの名前です。

ServiceInstance の削除

1. サービス・インスタンスを削除します。次のコマンドを実⾏します。

kubectl delete -n test-ns serviceinstances ups-instance

ここで、ups-instance は、削除するインスタンスの名前です。

ClusterServiceBroker の削除

1. ブローカーを登録抹消します。

kubectl delete clusterservicebrokers ups-broker


https://v1-10.docs.kubernetes.io/docs/concepts/overview/working-with-objects/labels/

ここで、ups-instance は、削除するブローカーの名前です。

サービス・ブローカー・サーバーのクリーンアップ

1. Helm デプロイメントを削除します。

helm delete --purge ups-broker

ここで、ups-broker は、削除する Helm デプロイメントの名前です。

構成およびスケーリングの管理

構成ファイルおよびデプロイメント・ポリシーを管理します。

ConfigMap の作成ポリシーの管理秘密の管理

ConfigMap の作成

ポッドまたはシステム・コンポーネント (コントローラーなど) に適⽤するために、構成データをキーと値のペアとして保管することができます。

構成ファイル、つまり ConfigMap は、イメージ・コンテンツから分離されている構成情報を含みます。構成データを分離することによって、コンテナー化したアプリケーションの移植可能性が⾼まります。

ConfigMap ファイルについて詳しくは、https://v1-10.docs.kubernetes.io/docs/tasks/configure-pod-container/configmap/ を参照してください。

management console から構成ファイルを作成するために、2 つの形式が使⽤可能です。

「ConfigMap の作成」ウィンドウでパラメーター値を⼊⼒することによって、または、YAML ファイルを「リソースの作成」ウィンドウに貼り付けることによって、構成ファイルを作成できます。


「ConfigMap の作成」ウィンドウを使⽤した構成ファイルの作成

1. ナビゲーション・メニューから、「構成」 > 「ConfigMap」をクリックします。2. 「ConfigMap の作成」をクリックします。3. ConfigMap の名前を指定し、構成詳細をキーと値のペアとして⼊⼒します。4. 「作成」をクリックします。

「リソースの作成」ウィンドウを使⽤した構成ファイルの作成

1. ダッシュボードから、「リソースの作成」をクリックします。2. YAML ファイルまたは JSON ファイルを「リソースの作成」ダイアログ・ボックスに貼り付けます。3. 「作成」をクリックします。

ポリシーの管理


https://v1-10.docs.kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/

デプロイメント・ポリシーを作成および保守します。デプロイメント・ポリシーは、デプロイメント・レプリカの数を⾃動的にスケーリングします。

デプロイメントの CPU 使⽤量に応じて、クラスター内のレプリカのスケーリングが⾏われます。

⾃動スケールアップ

サーバーで多数の要求を処理する場合など、CPU 要求が増えたときに、スケールアップがトリガーされます。次の条件により、⾃動的にスケールアップ操作がトリガーされます。

CURRENT_CPU_UT >1.1*TARGET_CPU_UT

デプロイメントがスケールアップすると、その DESIRED パラメーター、CURRENT パラメーター、および READY パラメーターの値が⼤きくなります。デプロイメントのホーム・ページからこれらの値を確認できます。

⾃動スケールダウン

サーバーがアイドル状態になるか、CPU 要求が減少すると、スケールダウンがトリガーされます。次の条件により、⾃動的にスケールダウン操作がトリガーされます。

CURRENT_CPU_UT < 0.9*TARGET_CPU_UT

デプロイメントがスケールダウンすると、DESIRED パラメーター、 CURRENT パラメーター、および READY パラメーターの値が⼩さくなります。デプロイメントのホーム・ページからこれらの値を確認できます。

デプロイメント・ポリシーの作成デプロイメント・ポリシーの更新デプロイメント・ポリシーの削除

デプロイメント・ポリシーの作成

ポリシーを使⽤して、ポッドのスケーリングおよびリソース割り振りを指定します。

すべてのユーザーが、⾃分の名前空間内で新規ポリシーを定義できます。管理者の場合、ポリシーはデフォルトで管理者名前空間内に作成されます。

1. ナビゲーション・メニューから「構成 (Configuration)」>「スケーリング・ポリシー (Scaling Policy)」をクリックします。

2. 「ポリシーの作成 (Create Policy)」をクリックします。3. ポリシー詳細を指定します。「ポリシーの作成 (Create Policy)」ウィンドウで個別の値を指定します。

1. ポリシーの「名前 (Name)」を⼊⼒します。2. 「スケーリングのターゲット (Scale target)」フィールドに、ポリシーを適⽤するアプリケーションの名前を⼊⼒します。

3. 「複製の最⼩数 (Minimum replications)」の値を⼊⼒します。デフォルト値は 1 です。4. 「複製の最⼤数 (Maximum replications)」の値を⼊⼒します。この値は、スケールアップ中に許可される複製の最⼤数です。

5. 「ターゲット CPU (Target CPU)」の値を⼊⼒します。この値は、アプリケーションが割り振ることのできる使⽤可能な CPU のパーセンテージです。コンテナーのリソース制限を指定しない場合、値はunlimited に設定されます。


新規ポリシーが「スケーリング・ポリシー (Scaling Policies)」ホーム・ページに表⽰されます。

詳細なポリシー情報を表⽰するには、ポリシー名をクリックします。


デプロイメント・ポリシーの更新

デプロイメント・ポリシーを更新します。


2. 「アクション」 > 「編集」を選択します。ポリシーの JSON ファイルが表⽰されます。3. ポリシー・プロパティーを更新します。4. 「送信」をクリックします。

デプロイメント・ポリシーの削除

デプロイメント・ポリシーを削除します。


2. 削除するポリシーを対象として「アクション」>「削除」を選択します。確認のダイアログ・ボックスが表⽰されます。

3. 「ポリシーの削除 (Remove Policy)」をクリックします。

ポリシーが、デプロイメント・ポリシー・リストから削除されます。

秘密の管理

秘密は、パスワードや API 鍵といった機密の構成設定を保管するために使⽤されます。

複数のコンテナーまたはデプロイメントで使⽤できる機密情報を、秘密を使⽤して保管できます。秘密を参照できるのは、同じ名前空間で実⾏されているコンテナーまたはデプロイメントのみです。

秘密について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/configuration/secret/ を参照してください。

クラスター内のすべての秘密を表⽰するには、ナビゲーション・メニューから「構成」 > 「秘密」をクリックします。このビューでは、秘密を名前空間でフィルタリングすることもできます。


秘密の作成

コマンド・ラインからの秘密の作成

management console からの秘密の作成management console からの秘密の更新

秘密の作成

コマンド・ラインからの秘密の作成

1. kubectl CLI をセットアップします。 kubectl CLI を使⽤した IBM® Cloud Private クラスターへのアクセスを参照してください。

2. 秘密を作成したい名前空間に切り替えます。

kubectl config set-context <cluster_CA_domain>-context --user=<user_name> --namespace=<namespace_name>


https://v1-10.docs.kubernetes.io/docs/concepts/configuration/secret/

ここで、<cluster_CA_domain> は、インストール中に config.yaml ファイルに設定された認証局 (CA) ドメインです。

3. 作成する秘密のタイプに応じて kubectl コマンドを実⾏します。

Docker レジストリーと共に使⽤するための秘密 (Dockercfg 秘密) を作成するには、コマンド・ラインから kubectl create secret docker-registry コマンドを使⽤します。特定の名前空間のimagePullSecrets の作成およびkubectl create secret docker-registry command を参照してください。

ローカル・ファイルまたはディレクトリーから秘密を作成するには、コマンド・ラインから kubectl create secret generic コマンドを使⽤します。 kubectl create secret generic コマンドを参照してください。

公開/秘密鍵ペアから秘密を作成するには、コマンド・ラインから kubectl create secret tls コマンドを使⽤します。 kubectl create secret tls コマンドを参照してください。

management console からの秘密の作成

IBM® Cloud Private management console を使⽤して、リテラル値から秘密を作成できます。これらの値は、Base64でエンコードされる必要があります。

1. コマンド・ラインから、データ値を base64 でエンコードします。末尾の改⾏⽂字 (\n) がストリングに付加されないようにするため、-n オプションを使⽤する必要があります。

echo -n "admin" | base64


YWRtaW4=

2. ナビゲーション・メニューから、「構成」 > 「秘密」をクリックします。

3. 名前空間ドロップダウン・メニューから名前空間を選択します。名前空間が選択されない場合、秘密は default 名前空間に作成されます。

4. 「秘密の作成」をクリックします。5. 秘密の詳細を指定します。

「⼀般」タブで、秘密の名前とタイプを指定します。タイプが指定されない場合、デフォルトのタイプである Opaque が割り当てられます。「データ」タブで、秘密の構成詳細をキーと値のペアとして⼊⼒します。値は base64 でエンコードされる必要があります。


management console からの秘密の更新

コマンド・ラインまたは management console のいずれかから作成された秘密を更新できます。

1. ナビゲーション・メニューから、「構成」 > 「秘密」をクリックします。2. 変更したい秘密に対して、「アクション」 > 「編集」を選択します。その秘密の JSON ファイルが表⽰されます。

3. プロパティーを更新します。4. 「送信」をクリックします。秘密が更新されます。

プラットフォームの管理

プラットフォームを維持する⽅法を説明します。


https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-secret-docker-registry-em-

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-secret-generic-em-

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-secret-tls-em-

計量、モニタリング、およびロギングネットワーククラスター・ノードの追加または削除ストレージリソース脆弱性アドバイザー

計量、モニタリング、およびロギング

リソース、メトリック、およびシステム・ログを確認します。

IBM® Cloud Private 計量サービス IBM Cloud Private モニタリングシステムおよびリソースのモニタリングポッド情報の表⽰ IBM Cloud Private ロギング IBM Cloud Private ロギングおよびメトリックのキャパシティー・プランニングロギング・サービス⽤の IBM Cloud Private Filebeat ノードのカスタマイズ

IBM® Cloud Private 計量サービス

計量サービスを使⽤して、アプリケーションおよびクラスターの詳細な使⽤量メトリックを表⽰およびダウンロード

できます。

計量サービスは、IBM Cloud Private 環境の⼀部として⾃動的にインストールされます。

計量レポートの表⽰


IBM クラスターの外部で実⾏されている IBM Cloud Private 製品の使⽤量のトラッキングIBM Cloudant からの計量データのパージ

計量レポートの表⽰

1. IBM Cloud Private management consoleからナビゲーション・メニューを開き、「プラットフォーム(Platform)」>「計量 (Metering)」をクリックします。

2. 計量データを表⽰およびダウンロードします。アプリケーションの計量データを表⽰するには、「コンテナー (Containers)」をクリックし、アプリケーションに移動します。

「使⽤可能なコア (Available Cores)」、「上限付きコア (Capped Cores)」、および「メモリー(Memory)」のメトリックを表⽰できます。関⼼のある期間を表⽰するように、表⽰される時刻範囲を更新できます。

特定のアプリケーションについて表⽰されたデータを .csv ファイルとしてダウンロードできます。

アプリケーション・メトリック・データの⽉次レポートを含む .csv ファイルをダウンロードするには、「レポートのダウンロード (Download Report)」をクリックします。レポートには、製品と各コンテナー・インスタンスの両⽅の使⽤量データの要約が含まれています。

Virtual Processing Core (VPC) の使⽤量は、レポートにリストされた Ccores の数です。クラスター内のノードの計量データを表⽰するには、「プラットフォーム (Platform)」をクリックします。



チーム、部⾨、個⼈、または特定のクライアントなどの、クラスターのユーザーのサブセットごとの IBM CloudPrivate 使⽤量の追跡に興味がある場合は、戦略的な名前空間割り当てを使⽤してデータを追跡してください。コア、メモリー、およびプロセッサーの使⽤量に関して計量サービスが収集したデータを使⽤して、クラスター・ユー

ザーの請求を管理できます (⼀般に「チャージバック」として知られる慣例)。

名前空間を使⽤してチャージバックを管理するには、追跡したいユーザーのサブセットを決定します。次に、ユーザーのグループごとの名前空間を作成し、ユーザーのグループ⽤の名前空間のみへのアクセス権限を各ユーザーに割り

当てます。グループのチャージバックを管理する必要がある場合は、名前空間ごとの使⽤量を確認してください。名前空間ごとの使⽤量情報を使⽤して、グループの請求を割り当てることができます。

IBM クラスターの外部で実⾏されている IBM Cloud Private 製品の使⽤量のトラッキング

計量サービスは、管理者役割を持つ IBM Cloud Private ユーザーが取得できる API 鍵を提供するようになりました。

1. IBM Cloud Private management consoleからナビゲーション・メニューを開き、「プラットフォーム(Platform)」>「計量 (Metering)」をクリックします。

2. 計量ダッシュボードから、「API 鍵の管理 (Manage API Keys)」を選択します。このフォームから、ご使⽤のプラットフォーム⽤の API 鍵を取得できます。

IBM 製品で計量が使⽤可能になっている場合、製品と IBM Cloud Private の間の通信をセットアップできます。 API鍵を使⽤した通信の構成⽅法については、外部製品の資料を参照してください。

IBM Cloud Private 計量サービスにデータを送信する外部製品は、製品固有のメトリックを提供する場合があります。これらのメトリックは、計量ダッシュボードおよびダウンロード可能なレポートから⼊⼿できます。場合によっては、レポート内の値に上限が付いていることがあります。このような場合、値の決定⽅法を説明する追加の詳細がレポートに⽰されます。各メトリックの測定⽅法について詳しくは、外部製品の資料を参照してください。

IBM Cloudant からの計量データのパージ

累積計量データにより、ノード上のディスク・スペースがすぐに満杯になってしまう可能性があります。

計量データの使⽤量を検証するには、マスター・ノードで以下のコマンドを実⾏します。

cd /opt/ibm/cfc/cloudant/cloudant/view_index/.shards/; du -hs `find . -name conc_usage*`

ディスク・スペース使⽤量が多い場合は、以下の⼿順を実⾏してファイルを圧縮します。

1. kubectl CLI をセットアップします。 kubectl CLI を使⽤した IBM Cloud Private クラスターへのアクセスを参照してください。

2. 以下のコマンドを実⾏してファイルを圧縮します。データベース圧縮コマンドは⾮同期で実⾏されます。コマンドの起動が成功すると、応答メッセージ OK が返されます。コマンドの完了には数分かかる場合があります。

kubectl -n kube-system exec -it icp-ds-0 -- /bin/bash -c 'curl -k -H "Content-Type: application/json" -X POST https://admin:$ADMIN_PASSWORD@cloudantdb:6984/conc_usage/_compact'

kubectl -n kube-system exec -it icp-ds-0 -- /bin/bash -c 'curl -k -H "Content-Type: application/json" -X POST https://admin:$ADMIN_PASSWORD@cloudantdb:6984/conc_usage/_compact/designDoc'

kubectl -n kube-system exec -it icp-ds-0 -- /bin/bash -c 'curl -k -H "Content-Type: application/json" -X POST https://admin:$ADMIN_PASSWORD@cloudantdb:6984/conc_usage/_compact/designDoc2'


3. すべての圧縮ジョブが完了していることを確認します。

kubectl -n kube-system exec -it icp-ds-0 -- /bin/bash -c 'curl -k -H "Content-Type: application/json" -X GET https://admin:$ADMIN_PASSWORD@cloudantdb:6984/_active_tasks'


[]

4. 計量データがこれ以上増⼤しないようにするには、metering-dm デプロイメントに環境変数を追加する必要があります。

1. IBM Cloud Private management console にログインします。2. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」をクリックします。3. metering-dm デプロイメントを⾒つけます。「アクション」 > 「編集」を選択します。 metering-dmデプロイメントの JSON ファイルが表⽰されます。

4. spec.template.spec.containers セクションの下の、env セクションを⾒つけます。

5. 新規の環境変数を追加します。

{ "name": "HC_DM_CONCERENABLED", "value": "false" },

6. 「送信」をクリックします。変更を送信した後、ポッドもサーバーも⼿動で再始動する必要はありません。

新しい環境変数を使⽤して metering-dm ポッドが⾃動的に再作成され、conc_usage データベース・ファイルの増⼤が停⽌します。この更新によって、環境内のデータが悪影響を受けたりデータが失われたりすることはありません。

IBM® Cloud Private クラスター・モニタリング

IBM Cloud Private クラスター・モニタリング・ダッシュボードを使⽤して、クラスターおよびアプリケーションの状況をモニターできます。

モニタリング・ダッシュボードは、Grafana および Prometheus を使⽤して、クラスター・ノードおよびコンテナーに関する詳細なデータを提⽰します。 Grafana について詳しくは、Grafana 資料を参照してください。

Prometheus について詳しくは、Prometheus 資料を参照してください。

モニタリング・ダッシュボードへのアクセス

1. IBM Cloud Private management console にログインします。

注: management consoleにログインすると、Grafana への管理アクセス権限を持つことになります。 Grafanaダッシュボード内でさらにユーザーを作成したり、既存のユーザーまたは組織を変更したりしないでくださ

い。

2. 「メニュー (Menu)」>「プラットフォーム (Platform)」>「モニタリング (Monitoring)」をクリックします。あるいは、https://<master_ip>:8443/grafana を開くことができます。ここで master_ip は、マスター・ノードの IP アドレスです。

3. Grafana ダッシュボードから、以下の 3 つのデフォルト・ダッシュボードのいずれかを開きます。Docker Host & Container OverviewKubernetes cluster monitoring (via Prometheus)Prometheus Stats


http://docs.grafana.org/


他のデータを表⽰したい場合は、新規ダッシュボードを作成するか、Grafana ⽤の JSON 定義ファイルからダッシュボードをインポートすることができます。

アラートの構成

Prometheus アラートを構成するか、IBM Cloud Private ⽤に Slack または PagerDuty などの外部アラート・サービス・プロバイダーを統合することができます。

1. IBM Cloud Private management consoleから「メニュー (Menu)」>「構成 (Configuration)」>「ConfigMap(ConfigMaps)」をクリックします。

2. Prometheus アラートを構成するには、以下のステップを実⾏します。

alert_rules ConfigMap と同じ⾏で「アクション」>「編集」を選択します。data セクションでアラートを指定します。アラート構成について詳しくは、Prometheus の資料内の『Alerting Rules 』を参照してください。

例えば、alertmanager ダッシュボードをテストするために 2 つのサンプル・アラートを構成するには、data セクションを以下のテキストに置き換えます。

"data": { "sample.rules": "groups:\n- name: a.rules\n rules:\n - alert: NodeMemoryUsage\n expr: (((node_memory_MemTotal - node_memory_MemFree - node_memory_Cached) / (node_memory_MemTotal)\n * 100)) > 25\n for: 1m\n labels:\n severity: page\n annotations:\n DESCRIPTION: '{{$labels.instance}}: Memory usage is above 75% (current value\n is: {{ $value }})'\n SUMMARY: '{{$labels.instance}}: High memory usage detected'\n - alert: HighCPUUsage\n expr: ((sum(node_cpu{mode=~\"user|nice|system|irq|softirq|steal|idle|iowait\"})\n BY (instance, job)) - (sum(node_cpu{mode=~\"idle|iowait\"}) BY (instance, job)))\n / (sum(node_cpu{mode=~\"user|nice|system|irq|softirq|steal|idle|iowait\"}) BY\n (instance, job)) * 100 > 2\n for: 1m\n labels:\n service: backend\n annotations:\n description: This machine has really high CPU usage for over 10m\n summary: High CPU Usage" }

data セクションを置換した後、「送信」をクリックします。

3. 外部アラート・サービスを統合するには、以下のようにします。

monitoring-prometheus-alertmanager ConfigMap と同じ⾏で「アクション」>「編集」を選択します。

アラートの構成について詳しくは、Prometheus の資料内『Configuration 』および『NotificationTemplate Examples 』を参照してください。

4. 更新が有効になるまで数分間かかります。その後、https://<master_ip>:8443/alertmanager でアラート・マネージャー・ダッシュボードを開きます。

サンプル・アラートを構成した場合は、それらが表⽰されます。

他に構成した有効なアラートがあれば、すべて表⽰されます。

外部アラート・サービスを構成した場合は、アラート・マネージャー・ダッシュボードが有効なデータ

を表⽰した後に、そのサービス⽤のダッシュボードでそれらのアラートを表⽰できます。

いつでもこのダッシュボードに戻ってアラートを表⽰できます。

システムおよびリソースのモニタリング


https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/

https://prometheus.io/docs/alerting/configuration/#%3Creceiver%3E

https://prometheus.io/docs/alerting/notification_examples/

IBM® Cloud Private ダッシュボードから、現在のシステムおよびリソースのメトリックを確認できます。

システム概要 (System overview)

クラスター内のノード、ストレージ、およびアプリケーションに関する⼀般情報を表⽰します。

ノード (Nodes)

クラスター内のアクティブ・ノードと⾮アクティブ・ノードの数を表⽰します。

共有ストレージ (Shared Storage)

クラスターで定義されているストレージ・ボリュームの状況を表⽰します。

使⽤可能 (Available) - ボリュームが使⽤していないストレージの量使⽤済み (Used) - ボリュームが使⽤しているストレージの量解放済み (Released) - 削除されたボリュームからレクラメーション処理されていないストレージの量失敗 (Failed) - ⾃動レクラメーションに失敗したストレージの量

アプリケーション

クラスター内の正常なアプリケーションと正常でないアプリケーションの数を表⽰します。正常なアプリケーションは実⾏中であり使⽤可能ですが、正常でないアプリケーションは停⽌しています。

リソース概要 (Resource overview)

リソースの使⽤に関する情報を表⽰します。各リソースに関する以下の情報を表⽰できます。

クラスター内のすべてのノードが使⽤可能なリソースの合計量。

使⽤中のリソースの量。

割り振られたリソースの量。割り振られた値は、クラスター内の各アプリケーションの、そのリソースの最⼤使⽤量制限の合計です。

以下のクラスター・リソースに関する情報が表⽰されます。

CPU

クラスター内の合計 CPU 使⽤量を取得するため、 IBM Cloud Private management consoleは、まず Kubernetes APIを呼び出して、クラスター内の CPU コアの合計を取得します。次に、以下の式を使⽤して CPU 使⽤率が計算されます。

(使用 CPU コア/合計 CPU コア) * 100

メモリー

クラスター内の合計メモリー使⽤量を取得するため、 IBM Cloud Private management consoleは、まず KubernetesAPI を呼び出して、クラスター内の使⽤可能なメモリーの合計を取得します。次に management consoleは Heapsterを呼び出して、コンテナーが使⽤中のメモリーの合計を取得します。次に、以下の式を使⽤してメモリー使⽤率が計算されます。

(使用メモリー/使用可能な合計メモリー) * 100

GPU


クラスター内で使⽤可能な合計 GPU を取得するために、IBM Cloud Private コンソールは Kubernetes API を呼び出します。

注: 現在、Heapster は GPU 使⽤量を報告できません。そのため、ダッシュボードに表⽰される合計 GPU 使⽤量は、単にクラスター内の合計 GPU を反映したものです。

ポッド情報の表⽰

クラスター内のポッドに関する情報を表⽰できます。

ポッドの詳細の表⽰

1. IBM® Cloud Private management console にログインします。2. 「メニュー (Menu)」 > 「ワークロード (Workloads)」 > 「デプロイメント (Deployments)」をクリックします。クラスター内のデプロイメントのリストが表⽰されます。

3. デプロイメント名をクリックします。デプロイメントの詳細が表⽰されます。ポッドは、そのページの「ポッド (Pods)」セクションに表⽰されます。

4. ポッド名をクリックします。ポッドの詳細ページにポッド情報が表⽰されます。

ポッド使⽤メトリックを表⽰するには、IBM Cloud Private クラスター・モニタリング・ダッシュボードを使⽤します。詳しくは、『IBM Cloud Privateクラスター・モニタリング』を参照してください。.

IBM® Cloud Private ロギング

IBM Cloud Private は、管理ロギング・サービスといわれる ELK スタックをデプロイして、すべての Docker キャプチャー・ログを収集して保管します。 IBM Cloud Private をインストールする前に、エンドツーエンドの TLS 暗号化など、スタックをカスタマイズする多くのオプションがあります。カタログから追加の ELK スタックをデプロイしてカスタマイズすることも、他のサード・パーティー・ソリューションをデプロイすることもできます。これにより、

ログを管理するために、ほぼ無限の可能性が提供されます。

ELK は Elastic によって構築された Elasticsearch、Logstash、および Kibana という 3 つの製品の略語です。これらは共に、ログなどのデータのストリーミング、保管、検索、およびモニターに使⽤できる多数のツールで構成されて

います。 IBM Cloud Private ELK スタックは、amd64 ベースのハードウェアにデプロイされた場合、Elastic が公開している公式イメージを使⽤します。この⽅法により、ソフトウェア・スタックが適切にアセンブルされること、およびアップグレードとフィックスが提供者によってサポートされることが⼀層強⼒に保証されます。他のプラットフォームのイメージは、公式の amd64 イメージに可能な限り近く構築されます。

プリインストール⼿順


デフォルトでは、Elasticsearch からのログ・データは、ELK スタックが実⾏される各管理ノードの /var/lib/icp/logging/elk-data ディレクトリーに保管されます。次のパラメーターを config.yaml ファイルに追加することによって、インストール時にデフォルトのディレクトリーを変更できます。elasticsearch_storage_dir: <your_path>

リソース計画

ELK スタックに⼗分なリソースが割り振られているかどうかが、機能的なロギング・サービスと、機能しないロギング・サービスの分かれ⽬になります。 IBM® Cloud Private ロギングおよびメトリックのキャパシティー・プランニン


https://www.elastic.co/

グのトピックに詳細なガイドがあります。まとめると、ELK スタックのハードウェア容量を計画する際には、以下を含むいくつかの要因を考慮してください。

1. ログがストリーミングされるコンテナーの数2. 各コンテナーが最悪の場合に⽣成するログ・ボリューム3. アクティブ参照と⻑期保管の両⽅の、必須のログ保存期間4. サポート要件など、特定のアプリケーションについて推奨されるログ保存要件 (ある場合)5. 転送中のデータにエンドツーエンドの TLS 暗号化が必要かどうか

プランニング・フェーズの最初のステップとして、スタック⽤の Elastic のハードウェア要件を確認します。まず、https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html を参照してください。このガイドは、スタックの各パートとそれが実⾏されるハードウェアとの複雑な関係の理解にも役⽴ちます。

Elastic のガイドで述べているように、メモリーは、2 つの最も消費量の多いリソースのうちの 1 つです。また、これが、機能する Kubernetes クラスターになるか、失敗の Kubernetes クラスターになるかの分かれ⽬になる可能性があります。例えば、特定のポッドのメモリー割り振りが不⼗分な場合は、そのポッドが安定状態を回復しようと奮闘します。しかし、ノードのメモリー割り振りが不⼗分な場合、Kubernetes は、クラスター内のすべてのポッドのハードウェアを探そうと奮闘します。これは、他のアプリケーションやサービスに影響を与える可能性がありま

す。

ディスク・ストレージは、キャパシティー・プランニングにおいておそらく最も重要な要因です。ディスクがいっぱいになると、着信ログを処理するためのコンピューティング能⼒がどれだけあっても関係ありません。ワーカー・ノードが 2 個または 3 個のみで、デプロイメントの少ない⼩規模な環境であっても、1 時間当たり数 GB のログを予期するのが妥当です。

調査により、⽣成されるログのボリュームと、Elasticsearch が保管のために必要とするディスクの間には、⾼い相関関係があることが⽰されているようです。追加のスペースをバッファーとして割り振ることが賢明であり、また、可能な場合には要件よりも⼤幅に⼤きなディスク・スペースを割り振ることが賢明です。異常な状況のために、予期されたログ保存期間の延⻑が必要となる場合があり、追加のスペースを提供することで問題を回避できます。

最後に、TLS 暗号化は、CPU とメモリーの両⽅に影響します。保護された ELK スタック製品を実⾏する、そうしたノードには、より⾼速のコアと何 GB かの追加メモリーを割り振ることを検討してください。


IBM Cloud Private インストーラーがデフォルト ELK スタックをデプロイするために使⽤するコードは、カタログ内の Helm チャートからのものです。インストーラーは、リリース時に利⽤可能なバージョンの Helm チャートをパッケージしますが、これは、利⽤可能な最新バージョンと少し異なる場合があります。 Helm チャートを使⽤してデフォルト・スタックをデプロイすると、デフォルト・スタックをより新しいバージョンに置き換えることも別の設定に

置き換えることもあります。

Helm チャートは、以下のコンポーネントを含む標準のアーキテクチャーをデプロイします。

クラスターの状態をトラッキングする専⽤ Elasticsearch マスター・ポッド。Logstash、Kibana、その他からの着信要求を処理する専⽤ Elasticsearch クライアント・ポッド。

カスタマイズ可能な頻度で古いデータをクリーンアップする、各 Elasticsearch クライアント・ポッド内のキュレーター。

データの処理と保管を⾏う専⽤ Elasticsearch データ・ポッド。パーシスタント・ボリュームが必要です。管理サービスは、ストレージ・クラス logging-storage-datanode を指定してデプロイされます。

ログを収集して Logstash にストリーミングするためにすべてのノードにデプロイされる Filebeat。Filebeat と Elasticsearch 間のバッファーを提供する Logstash ポッド。オプションで、データの表⽰および管理のインターフェースとしての Kibana ポッド。

管理サービスとしてデプロイされた Kibana ポッドは、ユーザーが管理者役割でログインしていることも検査します。


https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html

さらに、Helm チャートは、ニーズに合わせてスタックを構成するための幅広いオプションを提供します。そうしたオプションの⼀部を以下に⽰します。

ポッド当たりのメモリー割り振り。このステップは、機能的ロギング・インフラストラクチャーのために重要です。詳しくは、IBM® Cloud Private ロギングおよびメトリックのキャパシティー・プランニングを参照してください。

最⼩ディスク・サイズ。メモリー割り振りと同様に、この検討も機能的ログ・サービスのために重要です。TLS 暗号化の切り替え。有効化の⽅法を含め、詳しくは、後続の『TLS 暗号化』のセクションを参照してください。

Filebeat 名前空間のスコープ設定。 Helm チャートによって複数の個別 ELK スタックをデプロイする場合、それぞれを 1 つ以上の名前空間に制限することができます。データ・キュレーション頻度。ログをトリムする頻度を構成できます。標準および管理対象モード。管理対象モードでは、以下のようなものが追加されます。

管理者ログイン検査。

管理ノードへのバインディング。

⼊⼝を使⽤した Elasticsearch および Kibana (オプション) へのアクセス。

TLS 暗号化

エンドツーエンドの TLS 暗号化は、IBM Cloud Private ELK スタックの重要なフィーチャーです。有効にすると、スタック内のすべての製品間の通信をすべて保護するほか、PKI ベースの相互認証でもそれを⾏います。この認証⽅式は、Filebeat から Logstash、Kibana から Elasticsearch など、すべての接続が、証明書を使⽤して接続の⽚側ではなく両側で検証されることを意味します。相互認証ポリシーは、ELK システム内でも、ブラウザーへのセキュア接続でも、送信されるすべてのデータが盗聴および不正な改ざんから保護される明確な保証を提供します。

注: Elasticsearch 製品の TLS 暗号化は現在、amd64 ベースのプラットフォームでのみサポートされます。 Filebeatは、引き続き、セキュア・ログ・ストリーミングのために任意のプラットフォームにデプロイ可能です。

TLS の有効化

TLS を有効にするには、以下の 2 つの⽅法があります。

IBM Cloud Private をデプロイする前に、以下の節を cluster/config.yaml に追加します。

logging: security: enabled: true

Helm チャートのデプロイ時に、security.enabled フィールドを true に設定します。

その他のオプションも使⽤可能で、後続のセクションでそれらについて説明します。

ユーザー許可

TLS 暗号化フィーチャーは、ユーザー許可を有効にしません。 (Kibana 経由であっても、許可された証明書を使⽤した REST 経由であっても) ログのコンテンツへのアクセスが許可されたユーザーは、すべてのデータへの全アクセス権限を持ち、付与されたアクセス権限で許可されたすべてのアクションを実⾏可能です。

PKI について

PKI 認証とは、公開鍵と秘密鍵を使⽤するトラステッド接続に関与する⼀連の技法をまとめて記述するものです。IBM Cloud Private と ELK スタックのために、PKI 認証をさらに特化して記述することができます。基本的に、プロセスは、認証局、つまり CA として知られる特殊な証明書で始まります。この CA を使⽤して、CA にトレースバック可能な署名証明書を⽣成できます。署名証明書は、それぞれ公開鍵と秘密鍵から構成され、トラステッド・ネットワーク内のクライアントとサーバーに配布できます。


接続が確⽴されると、各側の個別の署名証明書の公開鍵のみが交換されます。接続の各側は、固有の秘密鍵に照らしてもう⼀⽅の公開鍵を検証し、それが CA からのものであるかどうかを⽴証します。さらなる⾝元証明のために、公開鍵にオプションで名前が保管される場合もあります。公開鍵が両側で検証されると、接続がトラステッドと⾒なされます。

Elasticsearch における PKI

バージョン 5.0 以降、Elastic 社は、古い TLS 有効化プラグインを⾮推奨とし、X-Pack と呼ばれる新しいプラグインにそれを置き換えました。 X-Pack は、TLS 暗号化を越える追加のエンタープライズ・レベルのフィーチャーを提供しますが、ライセンスが購⼊されない場合は、30 ⽇限定使⽤のポリシーが適⽤されます。試⽤期間の満了前にライセンスを購⼊しないと、すべての X-Pack 機能が無効になります。

Search Guard は、ELK スタックのプラグインを提供するもう 1 つの製品で、エンタープライズ・ユーザーにも販売されています。しかし、エンタープライズ・グレード・フィーチャーのライセンス要件のほかに、いくつかのフィーチャーは「Community Edition」のカテゴリーで提供されています。 README ファイルには、「Search Guard offers all basic security features for free. The Community Edition of Search Guard can be used for all projects, including commercial projects, at absolutely no cost.」と記載されています。 PKI による TLS 暗号化は、これらの Community Edition フィーチャーの 1 つです。

デフォルトで、IBM Cloud Private ELK スタックは、PKI を提供するために Search Guard を使⽤します。しかし、X-Pack のライセンスを既にお持ちの場合、または購⼊予定の場合は、以下のように指定できます。

security: provider: xpack

これにより、Helm チャートは、X-Pack の PKI 実装を使⽤するように ELK スタックを構成します。

CA の構成

IBM Cloud Private ELK スタックは、PKI とセキュリティーに関する⼀連のオプションを許可しています。まず、既存の認証局を指定することができます。あるいは、デフォルトで Helm チャートが認証局を⽣成します。既存の認証局を使⽤するには、以下のルールに従う必要があります。

1. Kubernetes 秘密に保管されなければなりません。2. 秘密は、ELK スタックのデプロイ先の名前空間に存在しなければなりません。3. 証明書の内容とその秘密鍵は、Kubernetes 秘密内の異なる名前のフィールド (つまり、キー) に保管される必要があります

例えば、以下の例のようなサンプルの秘密があるとします。

apiVersion: v1 kind: Secret metadata: name: my-ca-secret type: Opaque data: my_ca.crt: ... my_ca.key: ...

以下の値サブセットで Helm チャートを構成する必要があります。

security: ca: origin: external external: secretName: my-ca-secret certSecretKey: my_ca.crt keySecretKey: my_ca.key


https://github.com/floragunncom/search-guard

証明書と役割

『PKI について』の説明のように、適切に署名された証明書を受け渡すように、すべてのクライアント/サーバー接続が構成されなければなりません。 IBM Cloud Private ELK スタック・アーキテクチャーでは、多くの証明書を⽣成する必要があります。すべてが、それぞれ異なるフィールド名 (つまり、キー名) で同じ Kubernetes 秘密に保管されます。

ELK 役割説明秘密キー名鍵ストア鍵形式

初期化 Search Guard 設定を初期化します sgadmin JKS PKCS12Superuser Elasticsearch 管理者 superuser PEM PKCS1Filebeat Logstash に対するクライアント filebeat PEM PKCS1Logstash Filebeat のサーバー logstash PEM PKCS8Logstash Elasticsearch ログ・ストリームのクライアント logstash-monitoring JKS PKCS12Logstash Elasticsearch モニターのクライアント logstash-elasticsearch JKS PKCS12Elasticsearch REST API サーバー elasticsearch JKS PKCS12Elasticsearch イントラ・ノード・トランスポート elasticsearch-transport JKS PKCS12

キュレーター Elasticsearch REST API に対するクライアント curator PEM PKCS1Kibana Elasticsearch REST API に対するクライアント kibana PEM PKCS8

Kibana プロキシー着信接続のサーバー kibanarouter PEM PKCS1

各クライアント証明書も役割 ID を定義します。その役割 ID が、役割マッピングのセットに照らしてマッチングされます。Elasticsearch に対して発⾏される要求は、その役割に付与された許可に従わなければなりません。

パフォーマンス

当然、TLS 暗号化は、CPU の使⽤量に影響を与えます。暗号化と復号の処理で CPU の効率は向上していますが、オーバーヘッドは依然としてゼロではありません。 TLS を有効にした ELK スタック製品を実⾏するノードに割り振るコアの数は、ストリーミングが必要なログのボリュームによって異なります。 TLS 暗号化を提供するプラグイン (X-Pack または Search Guard) のニーズに応じて、メモリー使⽤量も影響を受ける可能性があります。

ハードウェア要件の⾒積もりに役⽴てるために、テストを実⾏することを強くお勧めします。

デプロイ済みログ・サービスの再構成

IBM Cloud Private をインストールした後、管理ロギング・サービスの設定、または個別のログ・サービスの設定までも、調整が必要な場合があります。前のセクションで⾔及したように、インストーラーは、Helm チャートによってロギング・サービスをデプロイします。このアプローチによって、アップグレードや完全な置き換えが⼤幅に容易になります。このセクションでは、さまざまな設定とその適⽤⽅法について説明します。

管理ログ・サービスの基本設定

後続のいくつかのセクションには、インストーラーによって kube-system にデプロイされる管理ログ・サービスを扱っているものもあります。サービスのデプロイに使⽤される設定を繰り返すのではなく、以下のブロックでは、デフォルト構成全体を説明します。後続のセクションでは、関連サブセットを扱います。これらの設定はどれも、インストールの前に cluster/config.yaml を使⽤してオーバーライドできます。インストールの前にオーバーライド値を指定した場合、それらの設定は、サービスの Helm ベースの再デプロイメントでもオーバーライドされなければなりません。

logstash: heapSize: "512m" memoryLimit: "1024Mi" port: 5044 elasticsearch:


name: elasticsearch internalPort: 9300 client: restPort: 9200 heapSize: "512m" memoryLimit: "1024Mi" data: # Replace the value below with the number of management nodes in your cluster replicas: "<< number_of_management_nodes >>" heapSize: "1024m" memoryLimit: "2048M" storage: size: "20Gi" storageClass: "logging-storage-datanode" master: # Replace the value below with the number of management nodes in your cluster replicas: "<< number_of_management_nodes >>" heapSize: "512m" memoryLimit: "1024Mi" kibana: install: "false" internal: 5601 external: 31601 curator: app: # The default for this value is 1. count: "<< logs_maxage >>" monitoring: # The default for this value is 1. count: "<< metrics_max_age >>" security: enabled: false mode: managed # The value below is the default. If you changed this during install, it needs to be changed here. clusterDomain: "cluster.local" nameOverride: elk

TLS

構成全体に⼤きく関与するため、TLS はデプロイメントの前に有効にする必要があります。 TLS を有効にして再デプロイするには、以下のようにします。

1. kube-system 名前空間で Helm リリースの logging を削除することで、管理ログ・サービスを削除します。2. パーシスタント・ボリュームとパーシスタント・ボリューム・クレームはそのままにします。3. カタログから ibm-icplogging チャートを選択し、以下の設定を変更します。

security: enabled: true

4. 管理サービスを再デプロイする場合は、kube-system 名前空間が選択されていること、および、前に説明した管理構成設定が適切に⾏われていることを確認します。

5. デプロイします。

メモリー

ロギング・サービスには、2 つのタイプのメモリー設定があります。 1 つめは、Java ベース・プロセスの場合のヒープ・サイズです。ヒープ・サイズは、プロセスが実⾏される JVM のみに影響します。ファイル・システム・キャッシングなど、他の⽅法でメモリーを使⽤するプロセス (Lucene など) には影響しません。 2 つめのメモリー設定は、Kubernetes のメモリー限度です。この限度では、コンテナーが全体として使⽤できるメモリーを制約します。

メモリー設定は、Helm チャートを再デプロイせずに調整可能ですが、その操作では、影響されるポッドをKubernetes が削除して再作成することになります。


1. kubectl コマンド・ライン・インターフェースをインストールします。詳しくは、kubectl CLI からのクラスターへのアクセスを参照してください。

2. 追加メモリーが必要な Deployment または StatefulSet の Kubernetes リソースを特定します。3. kubectl edit を実⾏して、エディターでそのリソースのコンテンツを開きます。4. Java プロセスのヒープ・サイズを変更する場合 (Elasticsearch および Logstash の場合のみ):

1. ES_JAVA_OPTS または LS_JAVA_OPTS の環境変数の定義を⾒つけます。2. -Xmx と -Xms の両⽅のパラメーターを同じ値に設定します。

5. コンテナーの Kubernetes メモリー限度を変更する場合:1. memory: キーを探します。これは container.resources.limits 節の中にあります。2. キーの値として、新しいメモリー限度を設定します。値の正しい構造については、Kubernetes の資料を参照してください。

6. エディターを保存して終了します。7. Kubernetes が代替ポッドを起動するまで待ちます。

Filebeat のスコープ

特定の名前空間、または⼀連の名前空間からログを収集するように Filebeat を構成することができます。このスコープは、デプロイメント時、またはデプロイメント後に構成可能です。ロギング・サービス⽤の IBM® Cloud PrivateFilebeat ノードのカスタマイズを参照してください。

キュレーター

これらの設定の変更⽅法に関する詳細⼿順については、後続の『キュレーターのカスタマイズ』のセクションを参照

してください。キュレーター設定の変更は、Kubernetes に Elasticsearch クライアント・ポッドをリサイクルさせるだけにしてください。

Elasticsearch API

Elasticsearch には、⾼度な柔軟性があり、詳細にドキュメント化された API があります。提供される API の中には、規制コンプライアンスなどの特定シチュエーションに関連するものもあります。以下のリストは、役⽴つ可能性があるエンドポイントのサンプルです。

注: これらの API は、Elasticsearch データ・ストアで現在トラッキングされているデータについて照会または操作するためにのみ動作します。バックアップには作⽤しません。

照会による削除。特定の照会に⼀致する⽂書全体 (例えば、ログ項⽬など) を削除できます。照会による更新。 delete-by-query API と類似していますが、フィールドの内容を変更する、または⽂書全体から特定フィールドを削除することができます。更新 API でフィールドの削除例を参照してください。バルク操作。ログ・データが累積すると、⼀部の操作で完了に時間がかかる可能性があります。バルク APIは、複数の操作を同じ要求のコンテキスト内で実⾏できるようにしてパフォーマンスを向上させるよう設計さ

れています。

デフォルトのシステム・ロギング動作

IBM Cloud Private インストーラーは、Logstash および Elasticsearch のサービスと、IBM Cloud Private クラスター内のすべてのノードからのログをストリーミングする Filebeat daemonset をデプロイします。 Kibana では、インストール前の追加変更がインストール・プロセス中にデプロイされる必要があります。あるいは、インストール後に別

にデプロイされる場合があります。

Filebeat daemonset は kube-system 名前空間にデプロイされますが、デプロイされた名前空間に関係なく、他のコンテナーおよびポッドからのすべての Docker キャプチャー・ログを収集します。この動作をカスタマイズして、他のサービスを有効にしたり、特定 ELK スタックのログ収集のスコープを絞ったりして、他のアプリケーションまたは名前空間の要件に対応することができます。


https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/#memory-units

https://www.elastic.co/guide/en/elasticsearch/reference/5.5/docs-delete-by-query.html

https://www.elastic.co/guide/en/elasticsearch/reference/5.5/docs-update-by-query.html

https://www.elastic.co/guide/en/elasticsearch/reference/5.5/docs-update.html

https://www.elastic.co/guide/en/elasticsearch/reference/5.5/docs-bulk.html

IBM Cloud Private インストーラーは、カタログ内にある Helm チャートの内部的に保管されたバージョンをデプロイします。カタログ内で利⽤可能なバージョンは、特定の IBM Cloud Private フル・リリースでパッケージされたバージョンの後に、新しくなっている可能性があります。このアプローチの 1 つの利点として、プロセスを理解している管理者であれば、デフォルトのログ管理サービスをアンインストールして、カタログを使⽤して新しいカスタマイズ

されたバージョンをデプロイすることができます。また、カタログとインストーラーでデプロイされたすべての ELKスタックについて、ログ管理ライフサイクル全体で⼀貫したエクスペリエンスが確保されます。

ELK スタックの構成設定はすべて、ConfigMap 内、秘密内、またはポッドのデプロイメント⾃体の中 (JVM ヒープ・サイズ割り振りやポッド・リソース限度の場合と同様) に保管されます。すべての設定は、該当ユーザーに⼗分な許可があればデプロイメント後にユーザー構成可能ですが、ユーザーは、設定を変更する前に⼗分に注意する必要があ

ります。設定の中には、意図しない副作⽤があったり、それを誘発したりする可能性があるものもあります。ユーザーは、ELK の資料だけでなく Kubernetes の資料も⼗分に確認して、個々の変更の影響をすべて把握しておく必要があります。

重要なこととして、管理対象 ELK スタック・コンテナーに割り振ったハードウェア (メモリーや CPU など) によって、IBM Cloud Private クラスターのログ・トラフィックが処理されるため、このハードウェアによってスタックの可⽤性、スケーラビリティー、および耐久性が決まります。

ユーザーがデプロイした ELK スタック

カタログから、さらに ELK スタックを任意の名前空間へデプロイすることができます。これらの ELK スタックは、広い範囲または狭い範囲の基準でログを収集するように構成できます。また、複数の ELK スタックで同じログを収集することも可能です。カタログで利⽤可能な Helm チャートは、デプロイメント前に設定する幅広いオプションを提供していますが、管理者が適切と思う変更を⾏えるように、設定はすべて Kubernetes リソースに保管されます。ただし、ELK スタックの構成は、複雑な作業であることもあります。害がないと思われる変更で、ELK スタックやノード⾃体に悪影響が出る場合があります。 ELK と Kubernetes の両資料をすべて確認し、意図する変更の影響を⼗分に把握してください。

IBM Cloud Private では、プラットフォームにデプロイ可能な ELK スタックまたはその他のログ管理ツールの数に制限はありません。しかし、ハードウェア・リソースを適切に計画して、対象のログの処理、保管、照会に⼗分な余地を確保することが⼤切です。

アプリケーションのロギングの構成

コンテナーが収集したログ

多くの Docker 対応アプリケーションは、ログを stdout および stderr に出⼒します。コンテナー内で正しく開始された場合、この 2 つのストリームが⾃動的に Docker によって収集され、そのコンテナー⽤の個別のログ・ファイル (多くの場合 /var/lib/docker/containers/<container_id> 内) に保管されます。

Kubernetes は、hostPath でマウントされるボリュームを通じて、Docker コンテナーにこれらのログ・ファイルの可視性を提供します。すなわち、hostPath ボリュームは、コンテナーがホスト VM のディスクの⼀部分にアクセスできるようにする⼿段です。 IBM Cloud Private は、ポッドをデーモンセットとしてすべてのワーカー・ノードにデプロイし、Docker コンテナー・ログを保管するパスをマウントし、次にログ・ファイルを Logstash にストリーミングします。インストール時にデプロイされた ELK スタックと、カタログからデプロイしたスタックの両⽅が、デーモンセット内で Filebeat を使⽤して、該当するノードからコンテナー・ログをストリーミングします。

この機能を活⽤するには、RUN コマンドまたは ENTRYPOINT コマンドのいずれかを使⽤して、Dockerfile から直接アプリケーションを開始する⽅法を理解してください。

コンテナー・ログ

他のほとんどのアプリケーションは、ログをローカルに個別のファイル内に保存します。 Linux システムでは、通常、/var/log/ ディレクトリー内のどこかに保管されます。いずれにしても、これらのファイルは他のコンテナー


https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/

https://kubernetes.io/docs/concepts/configuration/secret/

https://v1-8.docs.kubernetes.io/docs/concepts/storage/volumes/#hostpath

https://v1-8.docs.kubernetes.io/docs/concepts/workloads/controllers/daemonset/

https://docs.docker.com/engine/reference/builder/#run

https://docs.docker.com/engine/reference/builder/#entrypoint

https://docs.docker.com/get-started/part2/#define-a-container-with-a-dockerfile

から直接アクセスできず、ユーザーはコンテナー外部でログをストリーミングする別の⽅式を構成する必要がありま

す。最も効果的な解決⽅法は、それらのログを⾒ることができ、Filebeat などのストリーミング・ツールを実⾏するポッド (多くの場合、サイドカーと呼ばれる) に別のコンテナーを追加することです。メイン・アプリケーション・コンテナーが、アプリケーションには決して影響することなく、ログが保管されているフォルダーを共有するため、

サイドカーのアプローチは効果的です。

サイドカーの作成

既存のデプロイメントにサイドカーを追加するには、サイドカー⾃体で実⾏されるアプリケーションの構成を含め、

いくつかのステップが必要です。

注: 以下のガイドでは、ターゲット Elasticsearch クラスターで TLS 暗号化が有効になっていないことを想定しています。セキュリティーが有効になっている場合は、必要な証明書が⼊った秘密を解決してマウントし、Filebeat を適切に構成してください。

1. Filebeat ConfigMap を作成し、それに filebeat.yml という名前を付けます。 ConfigMap を使⽤すると、それを参照するすべてのアプリケーションの ConfigMap を動的に更新するのが容易になります。サンプルConfigMap 内の変数のほとんどは、値として環境変数を割り当てられています。これらの環境変数には、デフォルト値が含まれています。デフォルト値は、値の中のコロンの後に表⽰されます。これらのデフォルト値を定義することによって、デプロイメントごとにパラメーター値を構成できます。そのデプロイメント⽤の環境変数に各デプロイメントの値を設定します。環境変数を使⽤することで、多数のデプロイメントに同⼀のConfigMap を使⽤できます。詳細と設定については、Filebeat の資料を参照してください。

apiVersion: v1 kind: ConfigMap metadata: labels: app: filebeat-daemonset component: filebeat release: myapp name: filebeat-sidecar-config data: filebeat.yml: |- filebeat.prospectors: - input_type: log encoding: '${ENCODING:utf-8}' paths: '${LOG_DIRS}' exclude_lines: '${EXCLUDE_LINES:[]}' include_lines: '${INCLUDE_LINES:[]}' ignore_older: '${IGNORE_OLDER:0}' scan_frequency: '${SCAN_FREQUENCY:10s}' symlinks: '${SYMLINKS:true}' max_bytes: '${MAX_BYTES:10485760}' harvester_buffer_size: '${HARVESTER_BUFFER_SIZE:16384}' multiline.pattern: '${MULTILINE_PATTERN:^\s}' multiline.match: '${MULTILINE_MATCH:after}' multiline.negate: '${MULTILINE_NEGATE:false}' fields_under_root: '${FIELDS_UNDER_ROOT:true}' fields: type: '${FIELDS_TYPE:kube-logs}' node_hostname: '${NODE_HOSTNAME}' pod_ip: '${POD_IP}' tags: '${TAGS:sidecar}' filebeat.config.modules: # Set to true to enable config reloading reload.enabled: true


https://www.elastic.co/guide/en/beats/filebeat/5.5/filebeat-configuration-details.html

output.logstash: # Sends logs to IBM Cloud Private managed Logstash by default hosts: '${LOGSTASH:logstash.kube-system:5044}' timeout: 15 logging.level: '${LOG_LEVEL:info}'

2. 既存の Kubernetes デプロイメントの .yaml ファイルを開きます。

3. containers セクションの宣⾔を⾒つけ、同位の volumes セクションを追加します。詳しくは、Kubernetesの資料内の volumes を参照してください。

4. アプリケーション・コンテナーのボリューム節を追加します。ほとんどの場合、ログ・フォルダーごとに emptyDir ボリューム・マウント・ポイントを追加します。より複雑なストレージ要件のあるアプリケーションの場合、永続的ボリュームを別個に宣⾔することもできます。フォルダーごとに別個の名前と emptyDir宣⾔を追加してください。ボリューム宣⾔は、以下のコードのようになります。

volumes: - name: <logs_volume> emptyDir: {}

5. アプリケーションのコンテナー宣⾔にボリューム・マウント・ポイントを追加します。 name 属性の値が、volumes 宣⾔で指定された値と同⼀でなければならないことに注意してください。

containers: - name: my-app ... volumeMounts: - name: <logs_volume> mountPath: /var/log

6. サイドカー・コンテナーをポッドに追加します。以下の宣⾔を containers セクションに追加します。

containers: - name: myapp-sidecar-filebeat image: docker.elastic.co/beats/filebeat:5.5.1

7. サイドカー・コンテナー・セクション内で、共有ボリュームのそれぞれのボリューム・マウント・ポイントを定義します。

volumeMounts: - name: logs_volume mountPath: /var/log/applogs

8. ログを⾒つけるようにサイドカーを構成します。 Filebeat ConfigMap は、環境変数 LOG_DIRS を定義します。ConfigMap を使⽤するたびに、この変数の値でログのストレージ・ロケーションを指定します。単⼀のディレクトリー・パスを指定することも、ディレクトリーのコンマ区切りリストを指定することもできます。

env: - name: LOG_DIRS value: /var/log/applogs/app.log

9. ボリュームとして参照することによって、作成した Filebeat ConfigMap を接続します。

containers: - name: myapp-sidecar-filebeat ... volumeMounts: ... - name: filebeat-config mountPath: /usr/share/filebeat/filebeat.yml subPath: filebeat.yml ... volumes:


https://v1-8.docs.kubernetes.io/docs/concepts/storage/volumes/

... - name: filebeat-config configMap: name: filebeat-sidecar-config items: - key: filebeat.yml path: filebeat.yml

10. ログの読み取り時のアクセス権の問題を回避するため、root ユーザーとして Filebeat を実⾏します。

spec: securityContext: runAsUser: 0 containers:

完成したアプリケーション・デプロイメント・ファイルは、以下の例のようになります。

apiVersion: v1 kind: Pod metadata: name: myapp labels: app: myapp spec: template: metadata: labels: app: myapp spec: securityContext: runAsUser: 0 containers: - name: sidecar-filebeat image: docker.elastic.co/beats/filebeat:5.5.1 env: - name: LOG_DIRS value: /var/log/applogs/app.log - name: NODE_HOSTNAME valueFrom: fieldRef: fieldPath: spec.nodeName - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP volumeMounts: - name: logs_volume mountPath: /var/log/applogs - name: filebeat-config mountPath: /usr/share/filebeat/filebeat.yml subPath: filebeat.yml - name: myapp-container [ your container definition ] volumeMounts: - name: logs_volume mountPath: /var/log volumes: - name: logs_volume emptyDir: {} - name: filebeat-config configMap: name: filebeat-sidecar-config items: - key: filebeat.yml path: filebeat.yml


構成の仕上げ

アプリケーションをデプロイする前に、Filebeat 構成が正しく Logstash をターゲットとしていることを確認してください。直前の例では、output.logstash.hosts フィールドのデフォルト値は logstash.kube-system:5044です。ご使⽤の Kubernetes 環境で実⾏中の既存の Logstash サービスを指すように、この値をカスタマイズします。Logstash サービス名およびポート番号を取得するには、IBM Cloud Private ユーザー・インターフェースを確認するか、kubectl get services コマンド (CLI 資料を参照してください) の出⼒を確認します。

サイドカーのテスト

CLI を使⽤して、ConfigMap を作成し、アプリケーションをデプロイします。例えば次のようにします。

1. kubectl create -f filebeat.yml2. kubectl create -f myapp.yml

ポッドをデプロイしたら、ターゲット Elasticsearch インスタンスに関連付けられた Kibana インスタンスを⾒つけます。ご使⽤の環境に複数の Kibana インスタンスが含まれ、どのインスタンスを使⽤すべきか分からない場合は、kubectl get services を実⾏して、必要なインスタンスを⾒つけます。

Kibana ダッシュボードで、「Discover」タブを開き、ログを検索します。コンテナー名は、kubernetes.container_name:myapp-container という形式になります。ここで myapp-container は、ご使⽤のコンテナー名です。アプリケーションのログ項⽬が表⽰されます。

しばらくしてもログが表⽰されない場合は、問題が発⽣したために Filebeat がログを Logstash にストリーミングできない可能性があります。 kubectl describe pod コマンドおよび kubectl logs コマンドの出⼒を確認して、ログがストリーミングされない理由を調べてください。例えば、前のサイドカーの⼿順に従った場合は、kubectl logs myapp sidecar-filebeat コマンドを実⾏して、Filebeat の stdout ストリームおよび stderr ストリームを取得できます。 Logstash への接続のトラブルシューティングに役⽴つエラー・メッセージが含まれている可能性があります。

Elasticsearch キュレーター

キャパシティー・プランニングを⾏っている場合、ストレージは最も重要な考慮事項の 1 つです。ディスク・スペースが使い尽くされると、スタックで他のボトルネックが除去されても関係なくなります。ログのストレージ所要量を特定の制約の範囲内にとどめておくために役⽴つ⽅法の 1 つが、キュレーターを使⽤する⽅法です。 IBM CloudPrivate 内にデフォルトでインストールされている ELK スタックには、キュレーターが含まれており、⾃由にそれを変更することも、削除して別個に独⾃のキュレーターをデプロイすることもできます。

キュレーターについて

キュレーターは、指定された存続期間よりも古いデータを削除します。 Elasticsearch は、保管されたデータをチャンクに分割します。それらのチャンクはインデックスと呼ばれます。キュレーターは、指定された存続期間よりも古いインデックスを削除します。 IBM Cloud Private にデフォルトでデプロイされるデフォルトの Elasticsearch キュレーターについて詳しくは、Elastic の資料内の Curator Reference を参照してください。

IBM Cloud Private でのキュレーターの使⽤

IBM Cloud Private インストーラーは、Elastic のサイトに記載されているものと同じキュレーターをデプロイします。これは個別のポッドとしてデプロイされ、デフォルトで、1 ⽇よりも古いインデックスを削除するために毎晩24:00 に実⾏されます。

デフォルトのキュレーターは以下のようになります。

ローカル・クーロン・ジョブとして実⾏されます。ポッドが実⾏されていない場合、キュレーターは古いインデックスを削除できません。


https://www.elastic.co/guide/en/elasticsearch/client/curator/5.1/about.html

Logstash ConfigMap logstash-pipeline の output セクションで指定したインデックスを使⽤します。

キュレーターのカスタマイズ

キュレーターを構成するには、3 つのファイルを変更する必要があります。

1. cron ファイルには、いつキュレーター・プロセスを実⾏するかに関する構成情報が含まれています。2. action ファイルには、どのインデックスをクリーンアップするか、およびインデックスが存続できる期間などの、インデックス・データが含まれています。

3. config ファイルには、Elasticsearch エンドポイントおよびその他の⼀般設定などの、キュレーター⾃体の基本的な構成が含まれています。

これらのファイルは、kube-system 名前空間内の Kubernetes ConfigMap es-curator に保管されています。キュレーターがデプロイされると、その ConfigMap で指定されたファイルが、キュレーター・コンテナーのファイル・システム上のファイルにマップされます。 ConfigMap を変更できますが、変更内容は、ファイルの元の構造を維持する必要があります。

ConfigMap を取得して更新するには、以下のようにします。

1. kubectl クライアントを構成します。詳しくは、kubectl CLI を使⽤した IBM Cloud Private クラスターへのアクセスを参照してください。

2. kubectl get configmap es-curator -o yaml --namespace kube-system を実⾏します。このコマンドにより ConfigMap の内容が出⼒されます。その内容は 3 つの主要なセクションで構成され、それぞれが別個のファイルを表しています。

3. 出⼒の内容をテキスト・ファイルにコピーします。4. その他の変更を⾏います。5. kubectl update -f <path_to_updated_file> を実行します。

Kibana

Kibana は、Elasticsearch に保管されているデータにユーザーが容易にアクセスできるようにするユーザー・インターフェースです。これについては、Elastic の Web サイトに詳細な資料があります。

IBM Cloud Private 内の Kibana

IBM Cloud Private のインストール中に、Kibana を管理対象サービスとしてデプロイできます。このサービスをデプロイすると、デプロイされた Kibana インスタンスは、Elastic が公開した公式の Docker イメージを使⽤します。このイメージでは、XPack および関連フィーチャーが無効になっていますが、他のすべての機能にアクセスできます。 IBM Cloud Private コンソール・アドレスを変更することによって、Kibana にアクセスできます。その URLで、/console を /kibana に置き換えてください。

IBM Cloud Private をインストールした後に Kibana をデプロイする場合は、そのデプロイメントの資料を参照して、ターゲット URL を判別してください。そのデプロイメントで有効になっているフィーチャーは、プロバイダーによって、および構成した使⽤可能なオプションによって異なります。

初期構成

注: Kibana の初回の始動時に、プラグインの最適化に数分かかります。このプロセス中は、Kibana にアクセスできません。詳しくは、Elastic の資料内の Updating & Removing Plugins を参照してください。

Kibana の起動後に、それをブラウザーで開き、Elasticsearch 照会で使⽤するインデックスを構成します。詳しくは、Elastic の資料内の Creating an Index Pattern to Connect to Elasticsearch を参照してください。

標準のフィールド


https://www.elastic.co/products/kibana

https://www.elastic.co/guide/en/x-pack/5.5/xpack-introduction.html

https://www.elastic.co/guide/en/kibana/5.5/_updating_amp_removing_plugins.html

https://www.elastic.co/guide/en/kibana/5.5/index-patterns.html#settings-create-pattern

Kibana を初めて構成した後に、ユーザーが「Discover」タブを使⽤してログ・データを検索および分析できます。インデックスの⼀部であるかインデックス・パターンであることを Elasticsearch が検出したフィールドが表⽰されます。ログが ELK スタックを通じて処理されるため、それらのフィールドの⼀部は Filebeat および Logstash が⽣成します。以下のフィールドが⽣成されます。

kubernetes.container_id: コンテナーごとに Docker が⽣成する固有 ID。kubernetes.container_name: Kubernetes が使⽤するコンテナーの、理解しやすい名前。kubernetes.pod: コンテナーがデプロイされているポッドの名前。このフィールドの値は、通常、kubectl get pods コマンドを実⾏した場合にリストされるポッドに対応しています。kubernetes.namespace: 関連付けられたポッドがデプロイされる名前空間。

これらのフィールドを使⽤することで、Kibana を使⽤して、⼩規模なスコープと⼤規模なスコープの両⽅でログをモニターしたり分析したりできます。コンテナー⾃体という狭いスコープでも、名前空間内のすべてのポッドという広いスコープでも構いません。

IBM® Cloud Private ロギングおよびメトリックのキャパシティー・プランニング

柔軟性

責任あるプランニングにより、企業は、ワークロード⽤のハードウェア・リソースを最⼤限に増やし、⼀⽅でトラブ

ルシューティングおよび履歴分析に必要なリソースを最⼩限にすることができるようになります。特に負荷のかかる条件下で、ロギングおよびメトリックの取り込み、保管、および管理のために⼗分なリソースを割り振ることが⾮常

に重要です。このデータは多くの場合、過去のイベントの分析と将来の要件の予測の両⽅にとっての鍵となります。

ログおよびメトリックの取り込み、保管、および管理について普遍的にコスト効率の良い推奨事項を提⽰することは

できませんが、以下のガイドでは、IBM Cloud Private でのワークロードの動作の観察に基づく知⾒を提供します。アイドル条件とストレス条件の両⽅でワークロードをテストし、その情報を使⽤して、短期的管理と⻑期的管理の両

⽅に必要なハードウェア・リソースを予測することをお勧めします。

管理対象サービス

IBM Cloud Private は、管理ノードにデプロイできる管理対象サービスのセットを提供します。それらのノードに割り振られるリソースは、該当する管理対象サービスが IBM Cloud Private クラスター全体のすべてのロギングとモニタリングのトラフィックを処理しなければならないかどうかを反映する必要があります。ただし、常に集中管理が必須であるわけではありません。

いくつかの管理対象サービスでは、類似した構成可能な Helm チャートがカタログに組み込まれています。ノード・ラベルと Helm チャート・オプションの組み合わせによって、ユーザーは、特定のワークロードおよび名前空間に焦点を合わせたサービスをデプロイできます。このアプローチでは、クラウドの使⽤⽅法についてより詳細な検討が必要ですが、中央サービスの作業全体を削減するメリットが得られる可能性があります。

Kubernetes でのロギングとモニタリング

ワークロードは、2 つのレベルでログに記録され、モニターされます。デフォルトの、最も⼀般的なレベルでは、ワークロードをブラック・ボックスとして扱います。ロギング・サービスおよびモニタリング・サービスは、Dockerコンテナー⾃体の外部から⾒えるデータのみを読み取り、測定するため、ワークロードをブラック・ボックスとして

扱います。ロギング・サービスおよびモニタリング・サービスが機能するために、ワークロード⾃体の知識は必要ありません。 2 つ⽬のレベルは、より深いワークロード統合です。

ブラック・ボックスとしてのワークロード


ポッド、コンテナー、名前空間、およびその他のワークロードの⼀部のメタデータは、Elasticsearch や Prometheusでは使⽤できません。 Kubernetes ユーザーが⾒ることのできるほとんどのメタデータは、管理対象ロギング・サービスおよびモニタリング・サービスからは⾒えません。例えばロギングの場合、Elasticsearch 照会は、kubernetes.pod、kubernetes.container_name、および kubernetes.namespace などのフィールドを返します。それらのフィールド値は、API を通じて取得されるのではなく、代わりにログ・ファイル名⾃体から抽出されます。 Kubernetes は、下層にある Docker ログへの symlink を作成します。各 symlink の名前は、ポッド名、コンテナー名、コンテナー ID、および名前空間で構成されます。その情報をファイル名に格納しなければ、ロギング・サービスはそれらの値を取り込むことができません。

管理対象モニタリング・サービスには、さらに制約があります。メトリック・コレクターは、実⾏中のノードから、どのプロセス (Docker コンテナーを含む) がどのリソースをどの程度使⽤しているかに関する情報を抽出します。ほとんどの場合、コレクターは、その収集したデータのオリジンに関するメタデータを検出するために Kubernetes およびワークロードを深く洞察することはありません。これにより、フィルタリングおよび相関を実⾏できる程度が制

限されます。結果として、管理対象モニタリング・スタックによる収集⽤に構成できる最⼩のスコープは、IBMCloud Private ノードです。

深いワークロード統合

多くのアプリケーションでブラック・ボックスの制限があるものの、⼀部のワークロードでは、コレクション API とログ共有機能を統合します。例えば、コンテナーのログ・ファイルを送信するために Filebeat サイドカーを使⽤する場合があります。あるいは、ミドルウェアが詳細なメトリックを収集するための API を実装する場合があります。これらの技法をブラック・ボックス・コンテナーと組み合わせて、より豊富なメタデータ収集を表現する⽅法を⾒つ

けることもできます。

ハードウェアのインパクトの要約

ELK スタック

IBM Cloud Private は、ELK スタックを以下のようにデプロイします。

1. すべてのノードで実⾏される Filebeat デーモンセット2. 単⼀の Logstash ポッド (スケールアウト可能)3. Elasticsearch クラスターの管理を調整する Elasticsearch マスター・ポッド4. Logstash からのすべての着信ログおよび Kibana からの照会⽤の REST インターフェースを実装する

Elasticsearch クライアント・ポッド5. すべてのログ・データを処理および保管するための 2 つの Elasticsearch データ・ポッド6. オプションの Kibana ポッド

⼀般に、スタックのうちで最も多くのリソースを必要とする部分は、Logstash および Elasticsearch データ・ノードです。マスター Elasticsearch ノードおよびクライアント Elasticsearch ノードは、最⼩限のリソースを使⽤して⼤量のトラフィックを処理できます。 Filebeat も⾮常に効率的で、ごくわずかなリソースを使⽤します。

デフォルトでは、単⼀インスタンスの Logstash 構成が、1 秒当たり何百ものログ項⽬を処理できます。CPU 使⽤量は、1 秒当たり 150 から 200 のレコードごとにおよそ 1 つのコアの割合で増加します。ただし、ある時点 (ネットワーク容量によって異なり、おそらく 1 秒当たりおよそ 700 レコードの時点) で、ログ・トラフィックのボリュームによりネットワークのパフォーマンスが低下し始めます。このボリューム増加は、影響を受けるノードで実⾏されるアプリケーションに、相関する影響を与えます。⼀般に、⾼レートのログ・トラフィックが予期される場合は、それをできるだけ多くのノードに分散するか、ワークロードを複数の IBM Cloud Private クラスターに分割します。Filebeat および Logstash は、接続エラーの追跡とそこからの復旧において優れており、通常のトラフィック・レートに戻ったときのデータの損失を最⼩限にします。

Elasticsearch データ・ノードは、通常 Logstash よりも CPU 使⽤量が少ないですが、ディスクおよび RAM については注意が必要です。 Elastic 社によれば、Elasticsearch で保管されたログは、通常、未加⼯のログ・ファイル⾃体と類似したストレージを必要とします。メモリーの使⽤量は、保管されたログの 15% から 20% まで増加する場合が


あります。 Elasticsearch 構成を調整すると、その数値に影響する可能性がありますが、JVM ヒープはデータ・ノードが使⽤する合計メモリーの 1 つの側⾯のみを表すことに留意することが重要です。

特にログおよび照会のトラフィックが増加するにつれて、暗号化による CPU への負荷は必然的に重くなります。新しい CPU モデルでは、暗号化をより効率的に処理することが可能で、追加ハードウェアのニーズを埋め合わせる可能性はありますが、さらに多くのハードウェアが必要になります。また、TLS 暗号化を提供するプラグインによってオーバーヘッドがかかる可能性があるため、メモリーの追加も推奨されます。

Prometheus

さまざまな理由から、Prometheus は収集したすべてのメトリックを 2 時間にわたってメモリー内に保持します。Prometheus が必要とする RAM の量は、以下のようないくつかの要因に応じて異なります。

1. IBM Cloud Private クラスター内のノードの数2. ピーク作動状態時のワークロードの数3. メトリックが収集される頻度

3 番⽬の要因は、慎重に検討する必要のある要因です。メトリック収集の間の時間を 2 倍にする (例えば 15 秒ごとから 30 秒ごとに延ばす) と、Prometheus のメモリー使⽤量は半分に削減されますが、それらのメトリックの細分度も低下します。プランニング・プロセスの重要な要素の 1 つとして、トラブルシューティングと予測分析の両⽅を対象としたメトリック収集の要件の評価が挙げられます。

詳細な影響

計画⽴案者は、ロギング・データとモニタリング・データを管理するためのリソースを⾒積もる際に、以下の要因を

考慮する必要があります。

1. Data in Motion (流れているデータ) の暗号化が必要かどうか2. 管理対象ロギング・サービスおよびモニタリング・サービスに、ログおよびメトリックを集中的に収集するかどうか

3. ログを Logstash クラスターにストリーミングする Filebeat インスタンス (ノードのデーモンセットまたはサイドカー) の数

4. ワークロードによって⽣成されたログのボリューム5. 予測された負荷のバースト。結果としてログ・ボリュームが⼤きくなります6. 収集するメトリックの細分度7. ロギングおよび計量の保存要件8. Elasticsearch 照会のパフォーマンス

暗号化

Prometheus が使⽤する多くのコレクターで TLS はサポートされていませんが、モニターおよびログ⽤のすべての他の Data in Motion トラフィックは暗号化可能です。ただし、⼀般に CPU には影響があり、最近の CPU は効率性が向上していますが、それでも処理は厳しくなります。特に ELK スタックでは、暗号化を有効にするプラグインのために、メモリーのオーバーヘッドが発⽣する可能性があります。 RAM の制約が厳しいノードでは、安定性とパフォーマンスの問題が発⽣することがあります。

⼀般的に、暗号化を有効にする予定の場合は、ログ・ボリューム全体に⽐例した数量で、割り振る CPU の数を増やすことを検討してください。

集中的な収集

管理対象ロギング・サービスは、⽐較的⼩さい負荷の処理に最適な構成となっていますが、⼤幅に規模の⼤きいワー

クロードも処理できます。ただし、負荷が⾼くなると、CPU、ディスク、および RAM の使⽤量も増加します。


リソースのモニタリングには、多くの場合、CPU よりも多くの RAM が必要です。 Prometheus は、時間的制約のある照会への応答性や、より効率的な⼀括ディスク操作などの理由のため、2 時間という構成不可の期間にわたって、すべてのメトリックをメモリー内に保持します。その結果、ワークロードが増えると計量の必要なリソースが増え、その 2 時間で⽣成されるメトリックが増えます。管理ノードでメモリーの可⽤性が懸案事項であり、IBM CloudPrivate が多数のワークロードを実⾏している場合、管理対象モニタリング・スタックがメトリックを収集するノードを制限することができます。

Filebeat インスタンスの数

この要因は、主として Logstash に影響します。デフォルトで、IBM Cloud Private は Filebeat デーモンセットをすべてのノードにデプロイし、各デーモンセットは管理対象ロギング・サービスにストリーミングします。ユーザーも、Filebeat サイドカーを使⽤してコンテナー内部に保管されているログをストリーミング出⼒するポッドごとに、Filebeat インスタンスを作成します。 Filebeat インスタンスの数が増え、ログ・トラフィックが増加したら、Grafana で Logstash CPU 使⽤量を確認することを検討してください。 Logstash インスタンスが CPU コアをフルに使⽤し始めたら、Logstash クラスターにもう 1 つのレプリカを追加することを検討すべきです。

ログ・ボリューム

ログ・ボリュームが多いと、多くの場合、他の要因よりも RAM およびネットワークのパフォーマンスに影響します。環境によっては、1 秒当たり数⼗のログ項⽬が存在することがあります。他の環境では、1 秒当たりの項⽬数が数千にもなる可能性があります。いくつかの測定結果で、ログ・ボリュームが 1 秒当たり 1,000 項⽬に達するとネットワークのパフォーマンスが低下し始める場合があることを⽰していますが、個々の結果は異なります。

ログ・ボリュームは、⼀般に、ワークロード数の増加によって、またはワークロードからの出⼒のレートが⾼くなる

ことによって⼤きくなります。他の箇所で述べているように、ワークロードを含めてリソースの数が増えるにつれ、Prometheus では⼀時的なメトリック保管のためにより多くの RAM を必要とします。

トラフィックのバースト

データ収集をモニターするために必要なリソースは、トラフィックのバーストを通じても⽐較的安定していますが、

ログ出⼒のボリュームは⼤幅に増加することがあります。トラフィックでの予期しないバーストを処理するためのCPU コア、メモリー、およびディスクの割り振りを、慎重に検討する必要があります。

メトリックの細分度

『Prometheus』セクションを参照してください。

データ保存

管理対象ロギング・スタックおよびモニタリング・スタックのデフォルト構成では、データを 1 ⽇間のみ保持します。毎晩 24:00 頃に古いデータが削除されます。これらの設定は変更できます。『IBM Cloud Private ロギング』を参照してください。しかし、これらの設定を変更した場合、データを⻑期間保持することを選択したときの重要な影響について考慮する必要があります。

Elasticsearch は、データをチャンクに分解します。このチャンクはインデックスとしても知られています。各インデックスは、3 つの部分からなります。1 つ⽬はディスク上のデータ、2 つ⽬は Elasticsearch メモリー内キャッシュ、3 つ⽬は Lucene (検索エンジン) キャッシュです。管理対象 ELK スタックは、各インデックスを 1 ⽇として定義します。保持される各⽇のログについて、ディスクおよびキャッシュの所要量は累積します。各キャッシュのサイズは、そのキャッシュ⽤に⽣成されるログのボリューム (15% にもなることがある) と相関しています。⾔い換えると、保管されている 100 GB のログごとに、Grafana は、RAM を 15 GB も使⽤している Elasticsearch データ・ノードを報告する可能性があります。この使⽤量の⽐率は普遍的なルールではありませんが、IBM Cloud Private で実⾏するワークロードによってもたらされるリソース負荷を判別するためのテストの必要性を⽰します。

照会のパフォーマンス


⼀部のプランニング・シナリオでは、Elasticsearch の照会 (Kibana を通じて実⾏されるか、直接 Elasticsearch RESTAPI を通じて実⾏されるかに関わらず) が完了しなければならない時間フレームに制約を課すことがあります。複雑な照会も、時間的制約のある照会もあるため、結果は特定のしきい値の範囲内で提供される必要があります。このような場合、メモリーの増設だけでなく、ディスクの⾼速化も計画することがさらに重要になります。ソリッド・ステート・ディスク (SSD) は、⼀般にコストが⾼くなりますが、システムが厳格な照会しきい値に従うことを可能にする⼊出⼒のパフォーマンスを提供します。

RAM の増設、メモリー内キャッシュの拡⼤の促進、およびディスクの⾼速化を組み合わせると役⽴ちますが、それがすべてというわけではありません。他のセクションで説明したように、極端に⾼いログ・トラフィックは、ネットワーク品質に影響する可能性があり、それが照会の応答性に影響する可能性があります。管理対象 ELK スタックに関係しない (または IBM Cloud Private にも関係しない) その他の要因が照会の応答性に影響することもあります。早期にテストすると、発⽣する可能性のあるボトルネックの特定に役⽴ちます。

失敗に備えた計画

多くの場合、ロギング・データとモニタリング・データは監査のためにアーカイブされますが、アクティブなレビュ

ーのためにアーカイブされることはまれです。そのデータを管理するために割り振るコストのかかるリソースを少なくして、代わりにそのようなハードウェアをワークロードに集中させたくなります。しかし、Kubernetes の背景となる基本的な考えは、アプリケーション開発者およびシステム管理者が、障害時にも正常終了して障害から素早く復

旧するように、ソフトウェアを設計する必要があるということです。ポッドを再始動するコマンドがないのは、そのように考えているためです。ポッドを削除して Kubernetes がポッドを再作成するのを待機することのみ可能です。

したがって、適切なプランニングでは、IBM Cloud Private で実⾏されるワークロードの標準的な⽇常の動作だけでなく、1 つ以上のシステムまたはワークロードで壊滅的な障害が発⽣したときに何が必要かについても考慮します。ロギング・データおよびメトリック・データへのアクセスが最も重要になるのは、そのような場合です。

ロギング・サービス⽤の IBM® Cloud Private Filebeat ノードのカスタマイズ

ノードのサブセットのシステム・ログまたはアプリケーション・ログを収集するように、Filebeat をカスタマイズできます。

IBM Cloud Private ロギング・サービスは、Filebeat をデフォルトのログ収集エージェントとして使⽤します。

Filebeat は、同じノードでコンテナーなどのワークロードが⽣成したログをモニターします。ログを抽出し、そのログをさらに処理して保管するためにサーバーに転送します。 Filebeat インスタンスがノードで実⾏されない場合、このノード上のワークロードからのログを IBM Cloud Private ロギング・サービスが使⽤することはできず、それらのログは IBM Cloud Private management consoleに表⽰されません。

デフォルトでは、各 IBM Cloud Private ノード上の Filebeat インスタンスは、ノードのシステム・ログとアプリケーション・ログの両⽅を収集します。カタログから Filebeat インスタンスをインストールして、アプリケーション・ログを収集できます。この場合、ノード上で実⾏される Filebeat インスタンスが複数存在することがあります。システム・ログを収集するデフォルトの Filebeat インスタンスは、kube-system 名前空間内で実⾏されます。

ノードのラベルおよびセレクターを使⽤して、どのノードが Filebeat を実⾏するかをカスタマイズできます。

1. kubectl コマンド・ライン・インターフェースをインストールします。『kubectl CLI からのクラスターへのアクセス』を参照してください。

2. 次のコマンドを実⾏して IBM Cloud Private ノードのリストを取得します。

kubectl get nodes --show-labels

コマンド出⼒は、以下のテキストのようになります。


https://v1-8.docs.kubernetes.io/docs/concepts/overview/working-with-objects/labels

NAME STATUS AGE VERSION LABELS 9.42.24.5 Ready 5h v1.7.3-11+f747daa02c9ffb beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,gpu/nvidia=NA,kubernetes.io/hostname=9.42.24.5,role=master 9.42.30.64 Ready 4h v1.7.3-11+f747daa02c9ffb beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,gpu/nvidia=NA,kubernetes.io/hostname=9.42.30.64 9.42.41.109 Ready 4h v1.7.3-11+f747daa02c9ffb beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,gpu/nvidia=NA,kubernetes.io/hostname=9.42.41.109,management=true

3. Filebeat を実⾏するノードにラベルを付けます。次のコマンドを実⾏して、Filebeat を実⾏する必要のある各ノードにラベルを付けます。

kubectl label node <node_name> ibm.com/system-filebeat=true

ここで <node_name> は、Filebeat を実⾏するノードの名前であり、ibm.com/system-filebeat=trueは、Filebeat をこのノードで実⾏する必要があることを⽰すラベルです。ラベルに別の名前を使⽤する場合は、後で nodeSelector パラメーターをカスタマイズするときに必ずその名前を使⽤してください。

4. アーキテクチャーごとに現在の Filebeat インスタンスのリストを取得します。次のコマンドを実⾏して、Filebeat インスタンスをホストする名前空間でデーモンセットを検索します。

kubectl get ds --namespace=<namespace>

ここで <namespace> は、検索する名前空間です。

例えば、システム・ログを収集する Filebeat インスタンスを取得するには、次のコマンドを実⾏します。

kubectl get ds --namespace=kube-system


NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE-SELECTOR AGE filebeat-ds-amd64 3 3 3 3 3 beta.kubernetes.io/arch=amd64 6h filebeat-ds-ppc64le 0 0 0 0 0 beta.kubernetes.io/arch=ppc64le 6h filebeat-ds-s390x 0 0 0 0 0 beta.kubernetes.io/arch=s390x 6h

NAME の値は、各アーキテクチャーのデーモンセットの名前です。

5. nodeSelector の値を Filebeat インスタンスに追加します。 nodeSelector パラメーターを変更することによって、どのクラスター・ノードが Filebeat を実⾏するかを指定します。

1. Filebeat デーモンセット定義をエディターで開きます。

kubectl edit ds <filebeat_daemonset> --namespace=<namespace>

ここで <filebeat_daemonset> は、アクティブな Filebeat デーモンセットの名前であり、<namespace> は、デーモンセットをホストする名前空間です。

例えば、システム・ログを収集するインスタンスの Filebeat デーモンセット定義を開くには、次のコマンドを実⾏します。

kubectl edit ds <filebeat_daemonset> --namespace=kube-system

2. ibm.com/system-filebeat=true ラベルを nodeSelector パラメーターに追加します。このラベルを nodeSelector パラメーターに追加することにより、そのラベルを含むノードのみで Filebeat が実⾏されます。 nodeSelector パラメーターは、以下のコードのようになります。


nodeSelector: beta.kubernetes.io/arch: amd64 ibm.com/system-filebeat: "true"

3. ファイルを保存します。

4. Filebeat デーモンセットが実⾏中であることを確認します。

kubectl get ds <filebeat_daemonset> --namespace=<namespace>

ここで <filebeat_daemonset> は、変更した Filebeat デーモンセットの名前であり、<namespace>は、デーモンセットをホストする名前空間です。

例えば、システム・ログ⽤の Filebeat デーモンセットが実⾏中であることを確認するには、次のコマンドを実⾏します。

kubectl get ds <filebeat_daemonset> --namespace=kube-system


NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE-SELECTOR AGE filebeat-ds-amd64 1 1 1 1 1 beta.kubernetes.io/arch=amd64,ibm.com/system-filebeat=true 1h

更新された Filebeat デーモンセットが正しく実⾏されている場合、⽰されているように、必要なインスタンス数と使⽤可能なインスタンス数は⼀致します。

6. 残りの Filebeat デーモンセットのそれぞれについて、直前のステップを繰り返します。

ネットワーク

Calico ネットワークを使⽤すると、ネットワーク管理が容易になります。

Calico は、開放型システム間相互接続 (OSI) モデルの 3 番⽬の層 (レイヤー 3 またはネットワーク層としても知られる) の上に構築されています。 Calico は、Border Gateway Protocol (BGP) を使⽤して、エージェント・ノード間の通信を容易にするルーティング・テーブルを構築します。このプロトコルを使⽤することで、Calico ネットワークはパフォーマンスとネットワーク分離を向上させます。

Calico を使⽤すると、進⼊トラフィックをより適切に制御できます。 Calico を使⽤して、ワークロードへの進⼊トラフィックのアクセスを規制したり、ポッドへの進⼊トラフィックを制限するルールを設定したりすることができま

す。

IBM® Cloud Private クラスターのmanagement consoleから、特定のワークロードへの進⼊トラフィックを拒否または許可できるようになりました。ポッド間のアクセスを制限するネットワーク・ポリシー・ルールを設定することもできます。

ノードの準備 Calico CLI のセットアップネットワーク・ポリシーの作成

ノードの準備

ノードが Calico のシステム要件を満たすようにしてください。

Calico のネットワークの問題を最⼩限に抑えるには、ご使⽤の IBM® Cloud Private クラスター内のノードが以下の要件を満たすようにしてください。


IPv4 ネットワークの場合、3.10 以上の Linux カーネル・バージョンをインストールしてください。ネットワーク設定を確認してください。詳細については、『ネットワーク設定』を参照してください。クラスター内のすべてのノードがネットワーク接続されていることを確認してください。マスター・ノードからワーカー・ノード、ワーカー・ノードからマスター・ノード、およびすべてのワーカー・ノード間の接続

を確認してください。

ポートが開いており、それらのポートをブロックしているファイアウォール・ルールがないことを確認してく

ださい。 IBM Cloud Private デフォルト・ポートについて詳しくは、『デフォルト・ポート』を参照してください。

IP 転送が有効になっていることを確認してください。 IP 転送の構成を確認するには、以下のコマンドを実⾏します。

sysctl net.ipv4.ip_forward

IP 転送が有効になっている場合、net.ipv4.ip_forward= 1 が表⽰されます。

セッションとシステムの再始動の間の IP 転送を有効にするには、net.ipv4.ip_forward = 1 を /etc/sysctl.conf ファイルに追加します。

/etc/sysctl.conf ファイルへの変更を有効にするには、以下のコマンドを実⾏します。

sysctl -p /etc/sysctl.conf

Calico CLI のセットアップ

Calico コマンド・ライン・ツール calicoctl は、Calico ネットワークおよびセキュリティー・ポリシーを管理するために使⽤されます。

以下のステップは、IBM® Cloud Private クラスター内部のマスター・ノード、ワーカー・ノード、またはプロキシー・ノード上で実⾏する必要があります。

IBM Cloud Private 環境の外部にあるリモート・ワークステーションから calicoctl をセットアップする場合は、以下のステップに従うこともできます。

Calico コマンド・ラインをセットアップするには、以下のステップを実⾏します。

1. calicoctl 実⾏可能バイナリーを抽出します。

Linux® 64-bit の場合、以下のコマンドを実⾏します。

docker run -v /root:/data --entrypoint=cp ibmcom/calico-ctl:v2.0.2 /calicoctl /data

Linux® on Power® (ppc64le) の場合、以下のコマンドを実⾏します。

docker run -v /root:/data --entrypoint=cp ibmcom/calico-ctl-ppc64le:v2.0.2 /calicoctl /data

2. calicoctl 実⾏可能バイナリー・ファイルを $PATH に追加します。実⾏可能バイナリー・ファイルを $PATH に追加するには、実⾏可能バイナリー・ファイルを /usr/local/bin/ ディレクトリーにコピーします。

3. リモート・ワークステーションから calicoctl をセットアップする場合は、マスター・ノードからワークステーションに以下のファイルをコピーします。

/etc/cfc/conf/etcd/ca.pem/etc/cfc/conf/etcd/client-key.pem/etc/cfc/conf/etcd/client.pem


4. etcdv2 データ・ストアを使⽤するように calicoctl を構成します。ブート・ノード上の config.yaml ファイル内にあるものと同じ cluster_name を使⽤してください。

証明書ファイルをエクスポートします。

export ETCD_CERT_FILE=/etc/cfc/conf/etcd/client.pem

CA 証明書ファイルをエクスポートします。

export ETCD_CA_CERT_FILE=/etc/cfc/conf/etcd/ca.pem

鍵ファイルをエクスポートします。

export ETCD_KEY_FILE=/etc/cfc/conf/etcd/client-key.pem

CA ドメインをエクスポートします。

export ETCD_ENDPOINTS=https://<cluster_CA_domain>:4001

ここで <cluster_CA_domain> は、インストール時に config.yaml ファイルに設定された認証局(CA) ドメインです。

注: セッション間で環境変数の値を保持するには、.bashrc などのスクリプトに環境変数の値を追加します。次の例を参照してください。 Calico CLI コマンドを実⾏するすべてのノードにスクリプトをコピーする必要があります。

#!/bin/sh export ETCD_CERT_FILE=/etc/cfc/conf/etcd/client.pem export ETCD_CA_CERT_FILE=/etc/cfc/conf/etcd/ca.pem export ETCD_KEY_FILE=/etc/cfc/conf/etcd/client-key.pem export ETCD_ENDPOINTS=https://<cluster_CA_domain>:4001

etcdv2 データ・ストアを使⽤する calicoctl の構成について詳しくは、https://docs.projectcalico.org/v3.0/usage/calicoctl/configure/etcd を参照してください。

5. Calico コマンド・ラインを使⽤します。 Calico コマンド・ラインの使⽤を開始するには、https://docs.projectcalico.org/v3.0/reference/calicoctl/commands/ を参照してください。

ネットワーク・ポリシーの作成

ポッド間のネットワーク・アクセスを管理するネットワーク・ポリシーを設定します。

ネットワーク・ポリシーをセットアップするには、クラスターのインストール時に Calico ネットワークを有効にする必要があります。

ネットワーク・ポリシーの構成について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/services-networking/network-policies/ を参照してください。

1. ナビゲーション・メニューから「プラットフォーム (Platform)」>「ネットワーク (Network)」をクリックします。

2. 「ネットワーク・ポリシーの作成 (Create NetworkPolicy)」を選択します。

3. ポリシー詳細を指定します。ネットワーク・ポリシーを作成するには、以下のパラメーターが必要です。

ポリシーの名前。

「適用先 (Apply to)」 - ポリシーを適⽤する必要のあるポッドのリスト。ポッドのリストを指定しない場合、ポリシーはすべてのポッドに適⽤されます。 management consoleまたは Kubernetes CLI からポッドのリストを取得できます。下記の「アクセス元 (From)」セクションを参照してください。開くポート番号およびプロトコル。ポート番号を指定しない場合、すべてのポートが開きます。


https://docs.projectcalico.org/v3.0/usage/calicoctl/configure/etcd

https://docs.projectcalico.org/v3.0/reference/calicoctl/commands/

https://v1-10.docs.kubernetes.io/docs/concepts/services-networking/network-policies/

「アクセス元 (From)」 - アクセスを許可されたポッドのリスト。ポッドのリストを指定しない場合、すべてのポッドに、指定されたポッドへのアクセス権限が付与されます。名前空間およびポッドのラベル⼀致セレクターを使⽤して、許可されるポッドを指定できます。

ポッドのラベル⼀致セレクターを選択した場合、指定されたラベルを持つすべてのポッドが選択されま

す。ポッドは、関連付けられたユーザーと同じ名前空間内に存在していなければなりません。management consoleまたは Kubernetes CLI からポッド・ラベルのリストを表⽰できます。以下に例を⽰します。

ポッドのラベル⼀致セレクター

1. ポッドのリストを取得します。

kubectl get pods


NAME READY STATUS RESTARTS AGE dev-nginx-254164163-02gbb 1/1 Running 0 2h dev-tomcat-3353689452-k5bpz 1/1 Running 0 2h

2. ポッドから詳細を取得します。次のコマンドを実⾏します。

kubectl describe pods dev-nginx-254164163-02gbb


Name: dev-nginx-254164163-02gbb Namespace: dev Node: 9.21.62.194/9.21.62.194 Start Time: Fri, 10 Mar 2017 03:50:16 -0500 Labels: app=dev-nginx image=nginx_1_11_7 pod-template-hash=254164163 Status: Running IP: 10.1.53.6 Controllers: ReplicaSet/dev-nginx-254164163 Containers: ...

名前空間のラベル⼀致セレクター

名前空間のラベル⼀致セレクターを選択した場合、指定された名前空間ラベルを持つ名前空間に関連付

けられたすべてのポッドが選択されます。 Kubernetes CLI から名前空間ラベルを表⽰できます。

1. 名前空間のリストを取得します。

kubectl get namespaces


NAME STATUS AGE default Active 1h dev Active 31m kube-system Active 1h qa Active 29m

2. 名前空間を記述する YAML ファイルを開きます。次のコマンドを実⾏します。

kubectl get namespaces dev -o yaml

この例では、dev は名前空間の名前です。

YAML ファイルが開きます。以下のテキストのようになっています。


apiVersion: v1 kind: Namespace metadata: creationTimestamp: 2017-03-10T13:17:52Z labels: team: dev name: dev apiVersion: v1 kind: Namespace metadata: creationTimestamp: 2017-03-10T13:17:52Z labels: team: dev name: dev ...


クラスター・ノードの追加または削除

クラスター・ノードを追加または削除できます。マスター・ノードを追加または削除することはできません。

クラウド・プロバイダーを使⽤したクラスター・ノードの追加または削除 IBM® Cloud Private クラスター・ノードの追加 IBM® Cloud Private-CE クラスター・ノードの追加 IBM Cloud Private クラスター・ノードの削除 IBM® Cloud Private-CE クラスター・ノードの削除

クラウド・プロバイダーを使⽤したクラスター・ノードの追加または

削除

クラウド・プロバイダーを使⽤することによって、IBM® Cloud Private クラスターにノードを追加したり、クラスターからノードを削除したりします。

前提条件

クラウド・プロバイダーのセットアップ

レジストリーのセットアップ

プロキシー・ノードの追加または削除

ワーカー・ノードの追加または削除

前提条件


IBM Cloud Private ワーカー要件に準拠するイメージを持つ仮想マシンへのアクセスのため、OpenStack または VMware にアクセスできる必要があります。

使⽤しているイメージに Python 2.7 および Docker をインストールします。

クラウドでプロビジョンされた仮想マシンに sudo ユーザーとしてログインするため、ユーザー名とパスワード、または SSH 鍵が必要です。

IBM Cloud Private レジストリーのセットアップ


1. root 権限を持つユーザーとしてマスター・ノードにログインします。通常、マスター・ノードはブート・ノードからアクセス可能です。

2. Kubernetes コマンド・ライン・ツール kubectl をインストールし、セットアップします。『Install and SetUp kubectl 』を参照してください。注: バージョン 1.9.1 をインストールする必要があります。

3. IBM Cloud CLI をインストールし、セットアップします。まず、CLI およびツールの概要を参照してください。

4. IBM Cloud Private CLI プラグインをインストールします。まず、IBM Cloud Private CLI のインストールを参照してください。

5. トークンを⽣成するために IBM Cloud Private にログインします。パスワードを求めるプロンプトがコマンドから出されます。


6. IBM Cloud Private Docker レジストリー⽤の Kubernetes 秘密を作成します。次のコマンドを実⾏してレジストリーにログインします。パスワードを求めるプロンプトがコマンドから出されます。

bx pr registry-init -u <username> --server mycluster.icp:8500

7. イメージをローカル・レジストリーにロードします。

bx pr load-images --registry <cluster-domain-name>:8500 --repo-pattern 'ibmcom.*'

クラウド・プロバイダーのセットアップ

VMware のセットアップ

1. VMware クラウド・プロバイダーの資格情報を設定します。パスワードを求めるプロンプトがコマンドから出されます。

bx pr credentials-set-vmware -u <username> --server-url <server-url> [--skip-ssl-validation]

2. VMware マシン・タイプを作成します。マシン・タイプとは、仮想マシンをインスタンス化するために使⽤される構成です。

bx pr machine-type-add-vmware --name <name> \ --domain <domain> \ --datacenter <datacenter> \ --datastore <datastore> \ --cluster <cluster> \ --cpus <num-cpus> \ --memory <memory> \ --network <network> \ --template <template> \ --vm-user <vm-user> \ [--vm-password <vm-password> | --vm-key <vm-key>] \ [--dns-servers <dns-servers>]

OpenStack のセットアップ

1. OpenStack クラウド・プロバイダーの資格情報を設定します。パスワードを求めるプロンプトがコマンドから出されます。

bx pr credentials-set-openstack -u <username> \ --auth-url <url> \ --domain-name <domain> \


https://kubernetes.io/docs/tasks/tools/install-kubectl/


--tenant-name <tenant> \ --ca-cert <path-to-pem-file>

注: 前のステップのために OpenStack CA 証明書をダウンロードする必要がある場合、次のコマンドを実⾏してください。

openssl s_client \ -connect <server-url> \ -showcerts </dev/null \ 2>/dev/null \ | openssl x509 -outform PEM > ca.pem

2. OpenStack マシン・タイプを作成します。マシン・タイプとは、仮想マシンをインスタンス化するために使⽤される構成です。

bx pr machine-type-add-openstack --name <name> \ --region <region> \ --flavor-name <flavor> \ --image-name <image> \ --security-groups <default_group,group_1,group_2> \ --availability-zone <zone> \ --network <network> \ --vm-user <user> \ --vm-key <path-to-pem-file> \ --key-pair <key-pair-name> \

クラウド・プロバイダーを使⽤したプロキシー・ノードの追加または削除

クラウド・プロバイダーを使⽤することによって、IBM Cloud Private クラスターにプロキシー・ノードを追加したり、クラスターからプロキシー・ノードを削除したりします。

1. プロキシーを追加するには、特定のオプションを指定して以下のコマンドを実⾏します。

bx pr proxy-add --cluster <cluster-name> --machine-type <machine-type-name> --network <network> [--ip <ip>] [--gateway <gateway>]

オプション: --cluster 値クラスターの名前または ID。 --machine-type 値ノードのマシン・タイプ。使用可能なマシン・タイプを表示するには、bx pr machine-types <location> を実行します。 --network 値ネットワークまたは IP プールの名前。 --ip 値プロキシー・ノードにアクセスできる IP。 --gateway 値アクセス IP のゲートウェイ。 VMware のみ。 --file 値コマンドの値が含まれている YAML ファイルへのパス。コマンドにパラメーターを直接組み込むことにより、これらの値をオーバーライドできます。

2. プロキシーをリストするには、クラスター ID を指定して以下のコマンドを実⾏します。

bx pr proxies <cluster-name>

3. プロキシーの詳細を表⽰するには、以下のコマンドを実⾏します。

bx pr proxy-get <proxy-id>

4. プロキシーを削除するには、以下のコマンドを実⾏します。

bx pr proxy-rm <proxy-id>

クラウド・プロバイダーを使⽤したワーカー・ノードの追加または削除


クラウド・プロバイダーを使⽤することによって、IBM Cloud Private クラスターにワーカー・ノードを追加したり、クラスターからワーカー・ノードを削除したりします。

1. ワーカーを追加するには、次のコマンドを実⾏します。

注: 3 つより多いワーカーを⼀度に追加しないでください。

bx pr worker-add --cluster <cluster-name> --machine-type <machine-type-name> --workers <num>

2. ワーカーをリストするには、次のコマンドを実⾏します。

bx pr workers <cluster-name>

3. ワーカーの詳細を表⽰するには、以下のコマンドを実⾏します。

bx pr worker-get <worker-id>

4. ワーカーを削除するには、以下のコマンドを実⾏します。

bx pr worker-rm <cluster-name> <worker-id>

IBM® Cloud Private クラスターへのノードの追加

ワーカー・ノード、プロキシー・ノード、管理ノード、およびカスタム・ホスト・グループ・ノードを IBM CloudPrivate クラスターに追加します。

インストールのためのノードの準備

ノードの追加

ワーカー・ノードの追加

管理ノードの追加

プロキシー・ノードの追加

ホスト・グループの追加


1. すべてのデフォルト・ポートがオープンしているが、使⽤されていないことを確認します。これらのポートをブロックするファイアウォール・ルールがあってはなりません。 IBM® Cloud Private デフォルト・ポートについて詳しくは、デフォルト・ポートを参照してください。ポートがオープンしているかどうかを確認するには、次のコマンドを実⾏します。

ssh -p <port_number> localhost

ここで、port_number は確認対象のポート番号です。このコマンドで出⼒が返される場合、ポートは使⽤中です。ポートが使⽤中である場合、 ss -nlp | grep <port_number> コマンドを実⾏して、どのサービスで使⽤されているのかを確認できます。






127.0.0.1 localhost # 127.0.1.1 <host_name> # The following lines are desirable for IPv6 capable hosts #::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters <master_node_IP_address> <master_node_host_name> <worker_node_1_IP_address> <worker_node_1_host_name> <worker_node_2_IP_address> <worker_node_2_IP_host_name> <proxy_node_IP_address> <proxy_node_host_name>


4. 新規ノードのクロックを残りのクラスター・ノードと同期化します。 Network Time Protocol (NTP) を使⽤してクロックを同期化できます。 NTP のセットアップについて詳しくは、ご使⽤のオペレーティング・システムのユーザー資料を参照してください。

5. 新規ノードで、サポートされるバージョンの Python がインストールされていることを確認します。 Python バージョン 2.6 から 2.9.x がサポートされています。

python --version

6. 新規ノードに SSH クライアントがインストールされていることを確認します。

7. クラスター・ノード間のセキュア接続を作成するために SSH を使⽤する場合、新規ノードに SSH 鍵を追加します。




2. ノードにログインします。3. SSH サービスを再始動します。


8. ⾮ブート・ノードに⼿動で Docker をインストールする場合、新規ノードに Docker をインストールします。IBM Cloud Private での Docker のインストールを参照してください。



10. ノードが稼働しているプラットフォームのインストーラーが /<installation_directory>/cluster/images ディレクトリーで使⽤可能であることを確認してください。

Linux® 64-bit ノードの場合、ibm-cloud-private-x86_64-2.1.0.3.tar.gz ファイルまたは ibm-cp-app-mod-x86_64-2.1.0.3.tar.gz ファイルが必要です。Linux® on Power® (ppc64le) ノードの場合、ibm-cloud-private-ppc64le-2.1.0.3.tar.gz ファイルまたは ibm-cp-app-mod-ppc64le-2.1.0.3.tar.gz ファイルが必要です。IBM® Z ワーカー・ノードの場合、ibm-cloud-private-s390x-2.1.0.3.tar.gz ファイルが必要です。

ノードの追加



注: クラスターに IBM® Z ノードを追加するには、 Z ワーカー・ノードの IP アドレスを /<installation_directory>/hosts ファイルに追加します。

ワーカー・ノードを追加するには、次のコマンドを実⾏します。

docker run -e LICENSE=accept --net=host \ -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3-ee worker -l \ ip_address_workernode1,ip_address_workernode2

このコマンド内の ip_address_workernode1 および ip_address_workernode2 は、新規ワーカー・ノードの IPアドレスです。このコマンドを実⾏すると、指定した IP アドレスが hosts ファイルに追加されます。

管理ノードの追加

管理ノードを追加するには、次のコマンドを実⾏します。

docker run -e LICENSE=accept --net=host \ -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3-ee management -l \ ip_address_managementnode1,ip_address_managementnode2

このコマンド内の ip_address_managementnode1 および ip_address_managementnode2 は、新規管理ノードの IP アドレスです。このコマンドを実⾏すると、指定した IP アドレスが hosts ファイルに追加されます。

プロキシー・ノードの追加

この⼿順はプロキシー HA 環境でのみサポートされます。

プロキシー・ノードを追加するには、次のコマンドを実⾏します。

docker run -e LICENSE=accept --net=host \ -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3-ee proxy -l \ ip_address_proxynode1,ip_address_proxynode2

このコマンド内の ip_address_proxynode1 および ip_address_proxynode2 は、新規プロキシー・ノードの IPアドレスです。このコマンドを実⾏すると、指定した IP アドレスが hosts ファイルに追加されます。


ホスト・グループ・ノードは、ワーカー・ノードです。

1. ホスト・グループがホスト・ファイル内で定義されていることを確認してください。 hosts ファイルでのノード役割の設定を参照してください。

2. ホスト・グループを追加します。

ホスト・グループをセットアップするには、以下のコマンドを実⾏します。

docker run -e LICENSE=accept --net=host \ -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3-ee hostgroup -l [hostgroup-name]

注: 単⼀のコマンドで複数のホスト・グループをインストールしたい場合は、-l オプションを省略します。


特定のホストをホスト・グループに追加するには、次のコマンドを実⾏します。

docker run -e LICENSE=accept --net=host \ -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3-ee hostgroup -l \ ip_address_hostgroupnode1,ip_address_hostgroupnode2

このコマンド内の ip_address_hostgroupnode1 および ip_address_hostgroupnode2 は、新規ホスト・グループ・ノードの IP アドレスです。

IBM® Cloud Private-CE クラスターへのノードの追加

ワーカー・ノードとカスタム・ホスト・グループ・ノードを IBM® Cloud Private-CE (Community Edition) クラスターに追加します。


ノードの追加




1. すべてのデフォルト・ポートがオープンしているが、使⽤されていないことを確認します。これらのポートをブロックするファイアウォール・ルールがあってはなりません。 IBM® Cloud Private デフォルト・ポートについて詳しくは、デフォルト・ポートを参照してください。ポートがオープンしているかどうかを確認するには、次のコマンドを実⾏します。

ssh -p <port_number> localhost

ここで、port_number は確認対象のポート番号です。このコマンドで出⼒が返される場合、ポートは使⽤中です。ポートが使⽤中である場合、 ss -nlp | grep <port_number> コマンドを実⾏して、どのサービスで使⽤されているのかを確認できます。





127.0.0.1 localhost # 127.0.1.1 <host_name> # The following lines are desirable for IPv6 capable hosts #::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters <master_node_IP_address> <master_node_host_name> <worker_node_1_IP_address> <worker_node_1_host_name> <worker_node_2_IP_address> <worker_node_2_IP_host_name> <proxy_node_IP_address> <proxy_node_host_name>



4. 新規ノードのクロックを残りのクラスター・ノードと同期化します。 Network Time Protocol (NTP) を使⽤してクロックを同期化できます。 NTP のセットアップについて詳しくは、ご使⽤のオペレーティング・システムのユーザー資料を参照してください。

5. 新規ノードで、サポートされるバージョンの Python がインストールされていることを確認します。 Python バージョン 2.6 から 2.9.x がサポートされています。

python --version

6. 新規ノードに SSH クライアントがインストールされていることを確認します。

7. クラスター・ノード間のセキュア接続を作成するために SSH を使⽤する場合、新規ノードに SSH 鍵を追加します。




2. ノードにログインします。3. SSH サービスを再始動します。


8. ⾮ブート・ノードに⼿動で Docker をインストールする場合、新規ノードに Docker をインストールします。IBM Cloud Private での Docker のインストールを参照してください。



ノードの追加


注: クラスターに IBM® Z ノードを追加するには、 Z ワーカー・ノードの IP アドレスを /<installation_directory>/hosts ファイルに追加します。

ワーカー・ノードを追加するには、次のコマンドを実⾏します。

docker run -e LICENSE=accept --net=host \ -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3 worker -l \ ip_address_workernode1,ip_address_workernode2

このコマンド内の ip_address_workernode1 および ip_address_workernode2 は、新規ワーカー・ノードの IPアドレスです。このコマンドを実⾏すると、指定した IP アドレスが hosts ファイルに追加されます。


ホスト・グループ・ノードとは、特定のアプリケーションまたはプロセスを実⾏するために予約済みのワーカー・ノ

ードの集合です。

1. ホスト・グループの名前を作成したことを確認し、グループに各ノードの IP を追加します。カスタム・ホスト・グループの定義を参照してください。


2. ホスト・グループを追加します。

ホスト・グループをセットアップするには、以下のコマンドを実⾏します。

docker run -e LICENSE=accept --net=host \ -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3 hostgroup -l [hostgroup-name]

注: 単⼀のコマンドで複数のホスト・グループをインストールしたい場合は、-l オプションを省略します。

特定のホストをホスト・グループに追加するには、次のコマンドを実⾏します。

docker run -e LICENSE=accept --net=host \ -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3 hostgroup -l \ ip_address_hostgroupnode1,ip_address_hostgroupnode2

このコマンド内の ip_address_hostgroupnode1 および ip_address_hostgroupnode2 は、新規ホスト・グループ・ノードの IP アドレスです。

IBM® Cloud Private クラスター・ノードの削除

IBM Cloud Private クラスターからクラスター・ノードを削除します。



2. クラスターから IBM® Z ワーカー・ノードを削除するには、/<installation_directory>/cluster/images フォルダーに ibm-cloud-private-s390x-2.1.0.3.tar.gz ファイルが含まれている必要があります。

3. ノードを削除するには、以下のコマンドを実⾏します。

docker run -e LICENSE=accept --net=host \ -v "$(pwd)":/installer/cluster \ ibmcom/icp-inception:2.1.0.3-ee uninstall -l \ ip_address_clusternode1,ip_address_clusternode2

このコマンド内の ip_address_clusternode1 および ip_address_clusternode2 は、hosts ファイル内にリストされているノードの IP アドレスです。これらのノードは、ワーカー・ノード、プロキシー・ノード、または管理ノードの組み合わせであることが可能です。

IBM® Cloud Private-CE クラスター・ノードの削除

IBM Cloud Private-CE (Community Edition) クラスターからノードを削除します。

IBM® Cloud Private-CE クラスターの場合、ワーカー・ノードのみを削除できます。



2. ノードをクラスターから削除します。

docker run -e LICENSE=accept --net=host \ -v "$(pwd)":/installer/cluster \


ibmcom/icp-inception:2.1.0.3 uninstall -l \ ip_address_clusternode1,ip_address_clusternode2

このコマンド内の ip_address_clusternode1 および ip_address_clusternode2 は、hosts ファイル内にリストされているノードの IP アドレスです。これらのノードはワーカー・ノードでなければなりません。

ノードがクラスターから削除され、それらのノードの IP アドレスが hosts ファイルから削除されます。

ストレージ

Kubernetes クラスター内のデータ・ストレージはボリュームを使⽤して処理されます。 Kubernetes では、PersistentVolume (PV) は、管理者によってプロビジョンされた、クラスター内のネットワーク化されたストレージです。 PersistentVolumeClaim (PVC) は、ユーザーによるストレージの要求です。

PersistentVolumes について詳しくは、https://v1-10.docs.kubernetes.io/docs/user-guide/persistent-volumes/ を参照してください。

管理者は、IBM® Cloud Private クラスター内に、そのクラスター内のすべてのプロジェクトで使⽤可能なPersistentVolume を作成できます。その後、ユーザーは、このリソースを⾃分のアプリケーション⽤に要求するために PersistentVolumeClaim を作成できます。 Kubernetes でサポートされているすべての PersistentVolume タイプが IBM Cloud Private でもサポートされています。

管理者は、動的プロビジョン⽤にストレージ・クラスを作成することもできます。 IBM Cloud Private でのストレージ・クラスの作成について詳しくは、ストレージ・クラスの作成を参照してください。

Kubernetes ストレージ・クラスについて詳しくは、StorageClasses を参照してください。

Container Storage Interface (CSI) の使⽤GlusterFSvSphere クラウド・プロバイダー IBM Spectrum Scale™ ストレージ・クラス永続ボリューム

Container Storage Interface (CSI) の使⽤

現在、コンテナー・ストレージ・インターフェース (CSI) は、Kubernetes v1.10 でベータ版として使⽤できます。ベータ版へのプロモーションにより、デフォルトで CSI が使⽤可能になりました。 Kubernetes での CSI ベータ版の実装について詳しくは、『Container Storage Interface (CSI) for Kubernetes Goes Beta 』を参照してください。

CSI の構成

ほとんどの CSI プラグインでは、API サーバー・バイナリーおよび kubelet バイナリーで --allow-privileged=true フラグが設定されている必要があります。このフラグは、IBM Cloud Private ではデフォルトで使⽤可能になっています。 IBM Cloud Private 環境の場合は、追加の構成を設定することなく、CSI ボリュームをKubernetes ポッドで使⽤できます。

例: IBM Cloud Private での CSI NFS ドライバーのデプロイ

このサンプル・デプロイメントで使⽤されるサンプル・ファイルは、Kubernetes GitHub リポジトリーから⼊⼿できます。 kubernetes-csi/drivers を参照してください。


https://v1-10.docs.kubernetes.io/docs/user-guide/persistent-volumes/

https://v1-10.docs.kubernetes.io/docs/concepts/storage/persistent-volumes/#storageclasses

https://kubernetes.io/blog/2018/04/10/container-storage-interface-beta/

https://github.com/kubernetes-csi/drivers

1. NFS をインストールします。 NFS のセットアップについて詳しくは、『NFS PersistentVolume の作成』トピックの『前提条件』セクションを参照してください。

2. kubernetes-csi/drivers リポジトリーを複製します。

3. nfs ディレクトリーに切り替えます。

cd drivers/pkg/nfs

4. デプロイメントを作成します。

kubectl create -f ./deploy/kubernetes/


service "csi-attacher-nfsplugin" created statefulset.apps "csi-attacher-nfsplugin" created serviceaccount "csi-attacher" created clusterrole.rbac.authorization.k8s.io "external-attacher-runner" created clusterrolebinding.rbac.authorization.k8s.io "csi-attacher-role" created daemonset.apps "csi-nodeplugin-nfsplugin" created serviceaccount "csi-nodeplugin" created clusterrole.rbac.authorization.k8s.io "csi-nodeplugin" created clusterrolebinding.rbac.authorization.k8s.io "csi-nodeplugin" created

5. 作成した CSI ボリュームを使⽤してポッドをデプロイします。

1. NFS サーバーを⾒つけます。

showmount -e


Export list for nfsserver: /nfs *

2. examples/kubernetes/nginx.yaml ファイルを編集します。システム設定と⼀致するように、server パラメーターと share パラメーターを更新します。

cat examples/kubernetes/nginx.yaml | grep csi -A 5


csi: driver: csi-nfsplugin volumeHandle: data-id volumeAttributes: server: 10.10.25.7 share: /nfs ---

3. NFS ドライバーを使⽤してポッドを作成します。

kubectl create -f examples/kubernetes/nginx.yaml


persistentvolume "data-nfsplugin" created persistentvolumeclaim "data-nfsplugin" created pod "nginx" created

6. マウント・ポイントを確認します。

1. nginx コンテナーにアクセスします。


https://github.com/kubernetes-csi/drivers

kubectl exec -it nginx sh

2. /var/www ディレクトリーに移動します。

cd /var/www

3. ファイルを作成します。

touch test

4. マウント・ポイント上のファイルをリストします。

ls


test

7. NFS サーバーを確認します。

1. サーバーを⾒つけます。

hostname


nfsserver

2. サーバー上のファイルをリストします。

ls /nfs


test

GlusterFS

GlusterFS ストレージを構成および管理します。

IBM Cloud Private クラスターでの GlusterFS ストレージの構成GlusterFS クラスターのストレージ容量の増加 GlusterFS ボリュームからのデータ復旧 IBM® Cloud Private の再インストールのための GlusterFS ワーカー・ノードの準備Heketi の秘密の変更

IBM® Cloud Private クラスターでの GlusterFS ストレージの構成

GlusterFS ストレージを IBM Cloud Private クラスターに追加します。

IBM Cloud Private のインストール中か、IBM Cloud Private をインストールした後で、クラスター内で GlusterFS ストレージをプロビジョンできます。

IBM Cloud Private のインストール中に GlusterFS ストレージをプロビジョニングすることについて詳しくは、GlusterFS ストレージの構成を参照してください。

IBM Cloud Private のインストール後に GlusterFS ストレージを追加する場合は、以下のステップを実⾏してください。


1. GlusterFS ストレージの構成のページにある前提条件が満たされるようにします。2. ノードの準備に記述されているように、GlusterFS 構成⽤にワーカー・ノードを準備します。3. GlusterFS ストレージの構成に記述されているように、config.yaml ファイルを更新します。

4. <installation_directory>/cluster フォルダーから以下のコマンドを実⾏して、GlusterFS 構成を完成させます。

Standard IBM Cloud Private Cloud Native 環境、IBM Cloud Private Enterprise 環境、およびIBM Cloud Private Enterprise HA 環境

sudo docker run --net=host -t -e LICENSE=accept \ -v $(pwd):/installer/cluster ibmcom/icp-inception:2.1.0.3-ee install-glusterfs -vv | tee gluster_install.txt

IBM® Cloud Private-CE (Community Edition) 環境

sudo docker run --net=host -t -e LICENSE=accept \ -v $(pwd):/installer/cluster ibmcom/icp-inception:2.1.0.3 install-glusterfs -vv | tee gluster_install.txt

5. ステップ 3 で、または GlusterFS ⽤のストレージ・クラスの作成で説明されているように、ストレージ・クラスを作成しなかった場合、ストレージ・クラスを作成します。作成する GlusterFS ボリュームを要求するためにはストレージ・クラスが必要です。

これで、IBM Cloud Private クラスター内のワーカー・ノードに構成された GlusterFS ボリュームをPersistentVolumeClaim (PVC) を使⽤して要求することができるようになりました。 PVC の作成について詳しくは、「リソースの作成」ウィンドウを使⽤した PersistentVolumeClaim の作成を参照してください。

GlusterFS ボリュームの PVC は最⼤ 100 個まで作成できます。

GlusterFS クラスターのストレージ容量の増加

GlusterFS クラスターのストレージ容量を増やします。

既存のワーカー・ノード上でデバイスを追加することによって、または GlusterFS クラスターにワーカー・ノードを追加することによって、GlusterFS クラスターのストレージ容量を増やすことができます。

GlusterFS ワーカー・ノード上でのデバイスの追加GlusterFS クラスターへのワーカー・ノードの追加

始める前に、kubectl CLI をセットアップします。 kubectl CLI を使⽤した IBM® Cloud Private クラスターへのアクセスを参照してください。

注: kubectl コマンドで -- heketi-cli を使⽤する場合は必ず、Heketi ポッド認証⽤の --user admin パラメーターおよび --secret <default_admin_password> パラメーターを指定する必要があります。

GlusterFS ワーカー・ノード上でのデバイスの追加

GlusterFS クラスターに存在するワーカー・ノード上でデバイスを追加できます。そのデバイスは GlusterFS デバイスの要件を満たしている必要があります。 GlusterFS ストレージの構成の前提条件を参照してください。

デバイスを追加した後、それを Heketi トポロジーの⼀部にするには、まず必要な情報の取得を⾏ってから、トポロジーの更新⽤のコマンドを実⾏します。

必要な情報の取得


デバイスを追加する先のノードの ID が必要です。ノード ID を取得するには、以下のコマンドを実⾏します。

1. Heketi ポッド名を取得します。

kubectl get pods --all-namespaces | grep heketi

以下は出⼒の例です。

NAME READY STATUS RESTARTS AGE heketi-7b69bb4d48-g4kx9 1/1 Running 0 1h

2. クラスター ID を取得します。

kubectl -n kube-system exec <Heketi pod name> -- heketi-cli --user admin --secret <default_admin_password> cluster list


kubectl -n kube-system exec heketi-7b69bb4d48-g4kx9 -- heketi-cli --user admin --secret admin cluster list Clusters: Id:2a47436e012604919dae5fbb4fc3899c [file][block] #

3. ノード ID を取得します。

kubectl -n kube-system exec <Heketi pod name> -- heketi-cli --user admin --secret <default_admin_password> cluster info <cluster ID>

このコマンドは、ノードのリストを返します。


kubectl -n kube-system exec heketi-7b69bb4d48-g4kx9 -- heketi-cli --user admin --secret admin cluster info 2a47436e012604919dae5fbb4fc3899c Cluster id: 2a47436e012604919dae5fbb4fc3899c Nodes: 6c4c66317f5650e7b61057fede8dbe25 8164c019b2e7c67b224709a97d05d0e9 de3d0a9a21868a09f92fb50e166cceda Volumes: 896044a59b18316790ff5554455a7a9e b971b2bb34703143e094f9b5241e4ddf f3f93e7eddd48e95779361ff35bd2222 Block: true File: true

4. 新規デバイスを持つノードを特定します。そのためには、ノード IP アドレスを使⽤します。ノード IP アドレスを取得するには、すべてのノードに対して以下のコマンドを実⾏します。新規デバイスを持つワーカー・ノードのノード ID をメモします。

kubectl -n kube-system exec <Heketi pod name> -- heketi-cli --user admin --secret <default_admin_password> node info <node ID>

注: 新規デバイスの symlink を取得します。 symlink の取得⽅法について詳しくは、GlusterFS ストレージの構成の前提条件を参照してください。


kubectl -n kube-system exec heketi-7b69bb4d48-g4kx9 -- heketi-cli --user admin --secret admin node info de3d0a9a21868a09f92fb50e166cceda


Node Id: de3d0a9a21868a09f92fb50e166cceda State: online Cluster Id: 2a47436e012604919dae5fbb4fc3899c Zone: 1 Management Hostname: 192.168.0.96 Storage Hostname: 192.168.0.96 Devices: Id:4c6ba3295f71a78515d6bd5d5aad58ae Name:/dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:1:0State:online Size (GiB):24 Used (GiB):2 Free (GiB):22 #

トポロジーの更新

新規デバイスに関する情報を使⽤して Heketi トポロジーを更新します。次のコマンドを実⾏します。

kubectl -n kube-system exec <Heketi pod name> -- heketi-cli --user admin --secret <default_admin_password> device add --name=<device symlink> --node=<Node ID>


kubectl -n kube-system exec heketi-7b69bb4d48-g4kx9 -- heketi-cli --user admin --secret admin device add --name=/dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:1:0 --node=de3d0a9a21868a09f92fb50e166cceda Device added successfully #

GlusterFS クラスターへのワーカー・ノードの追加

GlusterFS クラスターにワーカー・ノードを追加できます。新しいワーカー・ノード上のデバイスは、GlusterFS デバイスの要件を満たしている必要があります。 GlusterFS ストレージの構成の前提条件を参照してください。

先に進む前に、/<installation_directory>/cluster フォルダー内の config.yaml ファイルにこの新規ノードを追加します。 GlusterFS ストレージの構成を参照してください。

kubectl CLI を使⽤して以下のステップを実⾏します。

1. 新規ノードにストレージ・ノードとしてラベル付けします。

kubectl label node <IP address or host name of the node> storagenode=glusterfs --overwrite


kubectl label node 192.168.0.139 storagenode=glusterfs --overwrite node "192.168.0.139" labeled #

2. GlusterFS ポッド名を取得します。

kubectl -n kube-system get pod -owide | grep glusterfs


kubectl -n kube-system get pod -owide | grep glusterfs NAME READY STATUS RESTARTS AGE IP NODE glusterfs-4srll 1/1 Running 1 3h 192.168.0.96 192.168.0.96 glusterfs-5zp55 0/1 ContainerCreating 0 7s 192.168.0.139 192.168.0.139 glusterfs-j2t6d 1/1 Running 0 3h 192.168.0.56 192.168.0.56 glusterfs-q8mcm 1/1 Running 0 3h 192.168.0.184


192.168.0.184 #

3. 既存の GlusterFS ポッドからピア・プローブ・コマンドを実⾏します。

kubectl -n kube-system exec <GlusterFS pod name> -- gluster peer probe <IP address or host name of the new node>


kubectl -n kube-system exec glusterfs-4srll -- gluster peer probe 192.168.0.139 peer probe: success. #





5. クラスター ID を取得します。

kubectl -n kube-system exec <Heketi pod name> -- heketi-cli --user admin --secret <default_admin_password> cluster list


kubectl -n kube-system exec heketi-7b69bb4d48-g4kx9 -- heketi-cli --user admin --secret admin cluster list Clusters: Id:2a47436e012604919dae5fbb4fc3899c [file][block] #

6. 新規ノードを GlusterFS クラスターに追加します。

kubectl -n kube-system exec <Heketi pod name> -- heketi-cli --user admin --secret <default_admin_password> node add --zone=1 --cluster=<cluster ID> --management-host-name=<IP address or host name of the new node> --storage-host-name=<IP address of the new node>


kubectl -n kube-system exec heketi-7b69bb4d48-g4kx9 -- heketi-cli --user admin --secret admin node add --zone=1 --cluster=2a47436e012604919dae5fbb4fc3899c --management-host-name=192.168.0.139 --storage-host-name=192.168.0.139 Node information: Id: 5df753379b9629eda0c5eb71687ee2ea State: online Cluster Id: 2a47436e012604919dae5fbb4fc3899c Zone: 1 Management Hostname 192.168.0.139 Storage Hostname 192.168.0.139 #

7. 新規ノードのデバイス情報を使⽤してトポロジーを更新します。

kubectl -n kube-system exec <Heketi pod name> -- heketi-cli --user admin --secret <default_admin_password> device add --name=<device symlink> --node=<Node ID>

注: デバイスの symlink を名前として追加してください。 symlink の取得⽅法について詳しくは、GlusterFS ストレージの構成を参照してください。



kubectl -n kube-system exec heketi-7b69bb4d48-g4kx9 -- heketi-cli --user admin --secret admin device add --name=/dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:1:0 --node=5df753379b9629eda0c5eb71687ee2ea Device added successfully #

GlusterFS ボリュームからのデータ復旧

GlusterFS ボリュームからデータを復旧します。

GlusterFS は、LVM (論理ボリューム・マネージャー) を使⽤して、ストレージの作成と管理を⾏います。 GlusterFSは、GlusterFS クラスター内の全ノードにわたってデータをボリュームに複製します。データを復旧する必要がある場合、データが複製された論理ボリュームにアクセスできます。


論理ボリュームからデータを復旧するには、GlusterFS クラスター内のすべてのノードで以下のステップを実⾏します。

1. 論理ボリューム・パスを持つ論理ボリュームを識別するため、以下のコマンドを実⾏します。

lvdisplay | grep "LV Path"


WARNING: Not using lvmetad because config setting use_lvmetad=0. WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache). LV Path /dev/vg_88f4bd7e79e88798c21b45dd9ca854ba/brick_d3f350725ab55fe9504a64d5213cb393

通常のディスクをマウントするときのように、論理ボリューム・パスをマウントします。

2. 論理ボリュームをマウントするために /mnt フォルダー内にディレクトリーを作成します。

mkdir -p /mnt/<mount directory name>

次の例では、ディレクトリー名としてブリック名が使⽤されています。

mkdir -p /mnt/brick_d3f350725ab55fe9504a64d5213cb393

3. 論理ボリュームをマウントします。

mount <LV path> /mnt/<mount directory name>

コマンドは、次のテキストのようになります。

mount /dev/vg_88f4bd7e79e88798c21b45dd9ca854ba/brick_d3f350725ab55fe9504a64d5213cb393 /mnt/brick_d3f350725ab55fe9504a64d5213cb393

4. 論理ボリュームが /mnt ディレクトリーにマウントされたことを確認します。次のコマンドを実⾏します。

ls /mnt

出⼒は、次のテキストのようになります。

brick_d3f350725ab55fe9504a64d5213cb393

5. /mnt/<mount directory name>/brick/ ディレクトリーに移動します。


cd /mnt/<mount directory name>/brick/

6. 復旧されたデータを表⽰します。次のコマンドを実⾏します。

ls

出⼒は、次のテキストのようになります。

heketi.db

この例では、heketi.db が論理ボリュームから復旧されました。

IBM® Cloud Private の再インストールのための GlusterFS ワーカー・ノードの準備

前の IBM Cloud Private インストールで GlusterFS ストレージを構成した場合、IBM Cloud Private をアンインストールしてもディスクからデータは消去されません。以下の⼿順に従って、再インストールのためにワーカー・ノードを準備する必要があります。

前のインストールで使⽤されたディスク上のデータをバックアップします。以降のステップが原因で、古いディスク上のデータが失われる可能性があります。

GlusterFS 構成のために使⽤するワーカー・ノード上に未使⽤のディスクを追加します。ディスク要件について詳しくは、前提条件を参照してください。

これらのワーカー・ノードをリブートしてシステムがディスクを識別できるようにします。

再インストールに使⽤される各ワーカー・ノードから、Heketi および Gluster デーモン構成ディレクトリーを削除します。以下のコマンドを実⾏します。

rm -rf /var/lib/heketi

rm -rf /var/lib/glusterd

次に、前提条件に従い、GlusterFS ストレージの構成およびボリュームの要求内のタスクを実⾏します。

Heketi の秘密の変更

Heketi サービスが認証に使⽤する秘密を変更します。

Heketi サービス・ポッドは、--user admin と --secret <default_admin_password> のパラメーターを認証に使⽤します。デフォルトでは、秘密は、/<installation_directory>/config.yaml ファイル内の default_admin_password に設定されます。

Heketi サービスが使⽤する秘密を変更するには、以下の⼿順を実⾏します。

1. IBM® Cloud Private CLI をセットアップします。詳しくは、IBM® Cloud Private CLI を使⽤したクラスターの管理を参照してください。

2. kubectl CLI がセットアップされていることを確認します。 kubectl CLI を使⽤した IBM® Cloud Private クラスターへのアクセスを参照してください。






4. 既存のパスワードで Heketi ポッドにアクセスできることを確認します。次のサンプルのコマンドを実⾏します。

kubectl -n kube-system exec -it <Heketi pod name> -- heketi-cli --user admin --secret <existing_password> cluster list


Clusters: Id:53e34819cc8ba1b28c61718cf0248e5d

5. Heketi の秘密を更新します。

bx pr update-secret mycluster kube-system heketi-secret -d admin_password=<new_password>


Secret changes are valid. 1 deployments will be updated: - heketi Continue? (Y/N)> Y OK 1 deployments updated: - heketi

6. 新しいパスワードで Heketi ポッドにアクセスできることを確認します。次のサンプルのコマンドを実⾏します。

kubectl -n kube-system exec -it <Heketi pod name> -- heketi-cli --user admin --secret <new_password> cluster list


Clusters: Id:53e34819cc8ba1b28c61718cf0248e5d

vSphere クラウド・プロバイダー

IBM Cloud Private クラスター内の vSphere クラウド・プロバイダーを構成します。

IBM® Cloud Private クラスターでの vSphere クラウド・プロバイダーの構成

IBM® Cloud Private クラスターでの vSphere クラウド・プロバイダーの構成

IBM Cloud Private クラスターで vSphere クラウド・プロバイダーを構成します。

IBM Cloud Private のインストール時か、IBM Cloud Private をインストールした後で、クラスター内で vSphere クラウド・プロバイダーを構成できます。

IBM Cloud Private のインストール時に vSphere クラウド・プロバイダーを構成する⽅法について詳しくは、vSphereクラウド・プロバイダーの構成を参照してください。


IBM Cloud Private をインストールした後に vSphere クラウド・プロバイダーを構成する場合は、以下のセクションの⼿順を実⾏してください。

始める前に、vSphere クラウド・プロバイダーの構成ページに記載されている前提条件に従ってください。

その後、以下の⼿順を実⾏します。

1. マスター・ノードを除くすべてのクラスター・ノードを更新します。2. すべてのマスター・ノードを更新します。3. 古いノードを削除します。4. vSphere クラウド・プロバイダーの構成に記述されているように、config.yaml ファイルを更新します。

マスター・ノードを除くすべてのクラスター・ノードの更新

マスター・ノードを除くすべてのノードで以下の⼿順を実⾏します。

1. /etc/systemd/system/kubelet.service ファイルの [Service] セクションの下に、次のコード部分を追加します。

--cloud-provider=vsphere

コードを追加すると、ファイルの内容は以下のテキストのようになります。

``` [Unit] Description=Kubelet Service Documentation= https://github.com/kubernetes/kubernetes

[Service] EnvironmentFile=-/etc/environment ExecStart=/opt/kubernetes/hyperkube kubelet \ --feature-gates Accelerators=true,ExperimentalCriticalPodAnnotation=true \ . . . --cloud-provider=vsphere \ --fail-swap-on=false

Restart=always RestartSec=10 [Install] WantedBy=multi-user.target ```

1. kubelet systemd ユニット・ファイルを再ロードします。


2. kubelet サービスを再始動します。

systemctl restart kubelet.service

3. kubelet サービスを再始動すると、⼿動でノードに追加したラベルやテイントが失われることがあります。その場合には、この時点でそれを再び追加できます。

すべてのマスター・ノードの更新

IBM Cloud Private クラスター内のすべてのマスター・ノードで以下の⼿順を実⾏します。

1. 以下のパラメーターを使⽤して vSphere クラウド・プロバイダー構成ファイルを作成し、それを <name>.conf ファイルとして保存します。ファイルを場所 /etc/cfc/conf/ にコピーします。この場所は、kubelet コンテナー、コントローラー・マネージャー・ポッド、および API サーバー・ポッドからアクセス可能な共有ディレクトリーです。

[Global] user=<vCenter username for vSphere Cloud Provider> password=<password for vCenter user> server=<vCenter server IP address or FQDN>


https://github.com/kubernetes/kubernetes

port=[vCenter server port; default: 443] insecure-flag=[set to 1 if vCenter uses a self-signed certificate] datacenter=<datacenter name on which node VMs are deployed> datastore=<default datastore to be used for provisioning volumes> working-dir=<vCenter VM folder path in which node VMs are located> [Disk] scsicontrollertype=pvscsi


user: vCenter のユーザ名。すべての vCenter 操作は、このユーザーの資格情報を使⽤して実⾏されます。

password: user パラメーターで指定されたユーザーのパスワード。server: vCenter サーバーの IP アドレスまたは完全修飾ドメイン・ネーム (FQDN)。port: vCenter をセットアップするために使⽤されるポート番号。デフォルト値は 443 です。insecure_flag: vCenter が⾃⼰署名証明書を使⽤する場合は 1 に設定します。datacenter: ノード VM がデプロイされているデータ・センターの名前。datastore: ストレージ・クラスを使⽤して作成される永続ボリュームを配置するのに使⽤されるデータ・ストアの名前。データ・ストアがフォルダー内に置かれていたり、データ・ストア・クラスターのメンバーであったりする場合でも、単に名前を指定します。データ・ストア名は⼤⽂字⼩⽂字が区別されます。

working_dir: vCenter 内のノード VM が置かれているフォルダー名またはパス。フォルダー名またはパスは⼤⽂字⼩⽂字が区別されます。

ノード VM がルート・フォルダー内にある場合、working_dir: "" と設定します。ノード VM がルート・フォルダーの下のフォルダー内にある場合、working_dir: Folder1_name の形式でパスを設定します。ノード VM がルート・フォルダーの下のネストされたフォルダー内にある場合、working_dir: Folder1_name/Folder2_name の形式でパスを設定します。

scsicontrollertype は、仮想ディスクへのアクセスに使⽤される Small Computer System Interface(SCSI) コントローラー・タイプです。

2. 以下のコード部分を kubelet、およびコントローラー・マネージャーと API サーバーのマニフェスト・ファイルに追加します。

--cloud-provider=vsphere --cloud-config=<full-path-to-the-vsphere.conf-file>

/etc/systemd/system/kubelet.service ファイルの [Service] セクションの下に、コードを追加します。


[Unit] Description=Kubelet Service Documentation=https://github.com/kubernetes/kubernetes [Service] EnvironmentFile=-/etc/environment ExecStart=/opt/kubernetes/hyperkube kubelet \ --feature-gates Accelerators=true,ExperimentalCriticalPodAnnotation=true \ --allow-privileged=true \ --cadvisor-port=0 \ . . . --cloud-provider=vsphere \ --cloud-config=/etc/cfc/conf/vsphere.conf \ --fail-swap-on=false Restart=always RestartSec=10


[Install] WantedBy=multi-user.target

/etc/cfc/pods/master.json ファイルの "spec">"containers">"name": "controller-manager">"command" セクションと "spec">"containers">"name": "apiserver">"command"セクションの下に、コードを追加します。


"spec":{ "hostNetwork": true, "containers":[ { "name": "controller-manager", "image": "registry.ng.bluemix.net/mdelder/hyperkube:v1.10.0", "imagePullPolicy": "IfNotPresent", "command": [ "/hyperkube", "controller-manager", "--master=https://127.0.0.1:8001", "--service-account-private-key-file=/etc/cfc/conf/server.key", "--cloud-provider=vsphere", "--cloud-config=/etc/cfc/conf/vsphere.conf", . . . "name": "apiserver", "image": "registry.ng.bluemix.net/mdelder/hyperkube:v1.10.0", "imagePullPolicy": "IfNotPresent", "command": [ "/hyperkube", "apiserver", "--secure-port=8001", "--bind-address=0.0.0.0", "--advertise-address=10.10.25.206", "--cloud-provider=vsphere", "--cloud-config=/etc/cfc/conf/vsphere.conf", . . .

3. kubelet systemd ユニット・ファイルを再ロードします。


4. kubelet サービスを再始動します。

systemctl restart kubelet.service

5. kubelet サービスを再始動すると、⼿動でノードに追加したラベルやテイントが失われることがあります。その場合には、この時点でそれを再び追加できます。

次に、古いノードの削除の⼿順を実⾏します。

古いノードの削除

config.yaml ファイル内に kubelet_nodename: hostname がインストールで設定されなかった場合にのみ、このセクションの⼿順を実⾏します。

IP アドレスを持つ古いノードを削除します。これらのコマンドは、クラスター内の任意のノード、またはリモート・ワークステーションから実⾏します。



2. 古いノードを削除します。

a. ノードに関する情報を取得します。

kubectl get nodes


NAME STATUS ROLES AGE VERSION 10.10.25.6 NotReady <none> 7d v1.10.0 10.10.25.3 NotReady <none> 7d v1.10.0 master Ready <none> 55s v1.10.0 worker1 Ready <none> 45s v1.10.0

b. 「Name」フィールドの下の、IP アドレスを持つノードを削除します。

kubectl delete node <IP-address>


kubectl delete node 10.10.25.3 node "10.10.25.3" deleted

c. ノードが削除されていることを確認します。

kubectl get nodes


NAME STATUS ROLES AGE VERSION 10.10.25.6 NotReady <none> 7d v1.10.0 master Ready <none> 7m v1.10.0 worker1 Ready <none> 7m v1.10.0

次に、vSphere クラウド・プロバイダーの構成に記述されているように、config.yaml ファイルを更新します。

IBM Spectrum Scale™

IBM Spectrum Scale™ を IBM® Cloud Private クラスター内のストレージに使⽤する⽅法について説明します。

IBM Spectrum Scale™ を IBM® Cloud Private クラスター内のストレージに使⽤する

IBM® Cloud Private クラスター内のストレージに対する IBMSpectrum Scale の使⽤

ボリュームを作成し、パーシスタント・ストレージ⽤に使⽤します。

注: IBM Cloud Private は、IBM Spectrum Scale™ を使⽤したストレージの動的プロビジョニングはサポートしていません。

IBM Spectrum Scale は、単⼀ファイル・システムまたはファイル・システム集合への複数ノードからの並⾏アクセスを提供する、クラスター・ファイル・システムです。 IBM Spectrum Scale について詳しくは、IBM SpectrumScale の概要を参照してください。


https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1ins_intro.htm

IBM Cloud Private クラスター内のポッド⽤に IBM Spectrum Scale ボリュームを使⽤する⽅法は複数あります。以降のセクションでは、hostPath を使⽤してボリュームの作成と請求を⾏う⽅法を説明します。

IBM Cloud Private ⽤の IBM Spectrum Scale の構成

始める前に、IBM Spectrum Scale クラスターをセットアップします。詳しくは、IBM Spectrum Scale クラスター構成および IBM Spectrum Scale クラスターの確⽴および開始の⼿順を参照してください。

IBM Cloud Private 環境の外部または内部に IBM Spectrum Scale クラスターをセットアップできます。どちらの場合も、すべての IBM Cloud Private ワーカー・ノードが IBM Spectrum Scale クライアント・ノードである必要があります。詳しくは、IBM Spectrum Scale クラスターの作成を参照してください。

IBM Spectrum Scale クラスターが IBM Cloud Private 環境の外部にある場合、確実に IBM Cloud Private ワーカー・ノードを IBM Spectrum Scale クライアント・ノードとして追加してください。

ファイル・システムの作成

IBM Spectrum Scale クラスター内にファイル・システムを作成する必要があります。ファイル・システムの作成について詳しくは、ファイル・システムの作成に関する考慮事項を参照してください。ファイル・システムを作成するためのコマンドについて詳しくは、 mmcrfs コマンドを参照してください。

次に、ファイル・システムをマウントします。

ファイル・システムのマウント

IBM Spectrum Scale クラスター内のすべてのノードでファイル・システムをマウントします。詳しくは、ファイル・システムのマウントを参照してください。

ファイル・セットの作成

ファイル・システムのデバイス上にファイル・セットを作成します。ファイル・セットは、ファイル・システム全体よりもきめ細かい管理操作ができるようにファイル・システムを区画化する⼿段を提供します。

ファイル・セットについて詳しくは、ファイル・セットを参照してください。

ファイル・セットを作成するためのコマンドについて詳しくは、mmcrfileset コマンドを参照してください。

ファイル・セットのマウント

ファイル・システムをマウントして、ファイル・セットをリンクします。詳しくは、ファイル・セットのリンクを参照してください。

hostPath を使⽤したパーシスタント・ボリュームの作成

IBM Cloud Private クラスター内で hostPath を使⽤して、パーシスタント・ボリュームを作成します。詳しくは、hostPath PersistentVolume の作成を参照してください。

以下に YAML ファイルの例を⽰します。

--- apiVersion: v1 kind: PersistentVolume metadata: name: gpfsstorage namespace: default


https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1ins_lscfg.htm

https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1ins_estart.htm

https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1ins_clnodes.htm#clnodes

https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1ins_plcrfs.htm

https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1adm_mmcrfs.htm

https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1adm_mount.htm

https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1adv_filesets.htm#filesets

https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1adm_mmcrfileset.htm

https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.0/com.ibm.spectrum.scale.v5r00.doc/bl1adv_fslink.htm

labels: storage: gpfs spec: capacity: storage: 1Gi hostPath: path: "/ibm/fs1/filesetpath" <======= Path where you have mounted the filseset accessModes: - ReadWriteMany

パーシスタント・ボリュームの状況を確認します。パーシスタント・ボリュームを使⽤できるのは、状況が Available になってからです。

パーシスタント・ボリューム・クレームの作成

パーシスタント・ボリューム・クレームを作成して、アプリケーションまたはポッドで消費できるようにします。

パーシスタント・ボリューム・クレームの作成⽅法について詳しくは、PersistentVolumeClaim の作成を参照してください。

以下に YAML ファイルの例を⽰します。

--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: gpfsclaim namespace: default spec: accessModes: - ReadWriteMany selector: matchLabels: storage: gpfs <======== Label of the persistent volume resources: requests: storage: 512Mi volumeName: gpfsstorage

パーシスタント・ボリューム・クレームの状況を確認します。パーシスタント・ボリューム・クレームを使⽤できるのは、状況が Bound になってからです。

これで、パーシスタント・ボリューム・クレームが、ポッドまたはアプリケーションで使⽤できるようになりまし

た。

アプリケーションまたはポッドを作成するときに、Volumes: セクションにパーシスタント・ボリューム・クレームの名前を指定して、ポッドまたはアプリケーションでそれを使⽤できるようにします。

ストレージ・クラス

動的ストレージ・プロビジョニング⽤のストレージ・クラスを使⽤します。

ストレージ・クラスの作成ストレージ・クラスの削除



ストレージ・クラスは、動的プロビジョニングのために使⽤されます。


ストレージ・クラスを作成するときには、以下のストレージ・クラスおよびそれらに関連付けられたサービスの品質

(QoS) を検討してください。

表 1. ストレージ・クラスストレージ・クラス名 QoS ((⼊出⼒操作/秒 (IOPS)/サイズ)ibmc-file-bronze 2 IOPSibmc-file-silver 4 IOPSibmc-file-gold 10 IOPSibmc-file-custom 可変のサイズおよび IOPibmc-block-bronze 2 IOPSibmc-block-silver 4 IOPSibmc-block-gold 10 IOPSibmc-block-custom 可変のサイズおよび IOP

ストレージ・クラスの例

IBM® Cloud Private での GlusterFS および vSphere のストレージ・クラスの作成⼿順については、GlusterFS ⽤のストレージ・クラスの作成およびvSphere ボリューム⽤のストレージ・クラスの作成を参照してください。

いくつかのストレージ・クラス定義のリストについては、StorageClasses を参照してください。

基本的なストレージ・クラス

kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: provisioner: kubernetes.io/<plug-in-type> parameters: parameter 1: value ... parameter N: value


kind: StorageClass は、API です。apiVersion: storage.k8s.io/v1 は、API バージョンです。metadata: name: は、ストレージ・クラスの名前です。provisioner: kubernetes.io/<plug-in-type> は、ストレージ・プロビジョナーの名前です。parameters は、ストレージ・クラスに属しているボリュームを記述します。パラメーターはオプションであり、プロビジョナーによって変わります。

GlusterFS

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: slow provisioner: kubernetes.io/glusterfs parameters: resturl: "http://127.0.0.1:8081" clusterid: "630372ccdc720a92c681fb928f27b53f" restauthenabled: "true"


https://v1-10.docs.kubernetes.io/docs/concepts/storage/persistent-volumes/#storageclasses

restuser: "admin" secretNamespace: "default" secretName: "heketi-secret" gidMin: "40000" gidMax: "50000" volumetype: "replicate:3"


resturl は、必須であり、Gluster ボリュームをオンデマンドでプロビジョンする Gluster REST サービス URLまたは Heketi サービス URL です。⼀般的な形式は IP address:Port です。 Heketi サービスが Kubernetes構成内でルーティング可能なサービスとして公開されている場合、resturl は http://heketi-storage-project.cloudapps.mystorage.com のような形式であることも可能です。ここで、FQDN は、解決可能なHeketi サービス URL です。restauthenabled は、REST サーバーへの認証を有効にする Gluster REST サービス認証ブール値です。この値が true の場合、restuser と restuserkey を指定するか、または、secretNamespace と secretNameを指定する必要があります。このオプションは⾮推奨です。以下のパラメーターのいずれかが指定された場合は認証は有効にされます。

restuserrestuserkeysecretNamesecretNamespace

restuser は、Gluster トラステッド・プール内にボリュームを作成できる、Gluster REST サービス・ユーザーまたは Heketi ユーザーです。restuserkey は、REST サーバーへの認証に使⽤される、Gluster REST サービス・ユーザーまたは Heketi ユーザーのパスワードです。このオプションは⾮推奨であり、secretNamespace と secretName を使⽤することが推奨されます。

secretNamespace および secretName はオプションです。これらは、Gluster REST サービスと通信するために使⽤するパスワードが含まれている秘密インスタンスを識別します。 secretNamespace および secretName が指定されていない場合、空のパスワードが使⽤されます。提供される秘密のタイプは“kubernetes.io/glusterfs”でなければなりません。clusterid: 630372ccdc720a92c681fb928f27b53f はオプションです。この ID は、ボリュームをプロビジョンするために Heketi が使⽤するクラスターの ID です。複数のクラスター ID をコンマで区切ったリストを指定することもできます。

gidMin および gidMax はオプションです。これらは、ストレージ・クラスの GID 範囲の最⼩値と最⼤値です。この範囲 (gidMin から gidMax) 内にある固有値 (GID) が、動的にプロビジョンされるボリュームに使⽤されます。 gidMin および gidMax が指定されていない場合、gidMin および gidMax のデフォルトである2000 から 2147483647 の範囲内の値を使⽤してボリュームがプロビジョンされます。volumetype は、ボリューム・タイプとそのパラメーターです。ボリューム・タイプはオプションです。指定されない場合、プロビジョナーがボリューム・タイプを決定します。例: ‘Replica volume’: volumetype: replicate:3 (3 はレプリカ数です); ‘Disperse/EC volume’: volumetype: disperse:4:2 (4 はデータ、2 は冗⻑数です); ‘Distribute volume’: volumetype: none

vSphere

ユーザー指定のディスク・フォーマットで PersistentVolume を作成します。

kind: StorageClassapiVersion: storage.k8s.io/v1metadata: name: fastprovisioner: kubernetes.io/vsphere-volumeparameters: diskformat: zeroedthick

ここで、diskformat 値は、thin、zeroedthick、または eagerzeroedthick です。デフォルト値は thin です。


ユーザー指定のデータ・ストアに、ユーザー指定のディスク・フォーマットで PersistentVolume を作成します。

kind: StorageClassapiVersion: storage.k8s.io/v1beta1metadata: name: fastprovisioner: kubernetes.io/vsphere-volumeparameters: diskformat: zeroedthick datastore: VSANDatastore

diskformat: thin、zeroedthick、または eagerzeroedthick。デフォルトは thin です。datastore: StorageClass にデータ・ストアを指定することもできます。ボリュームは、ストレージ・クラスに指定されたデータ・ストア (この例では VSANDatastore) に作成されます。このフィールドはオプションです。指定されていない場合、前の YAML の説明にあるように、ボリュームは、vSphere クラウド・プロバイダーを初期化するために使⽤される vSphere 構成ファイル内に指定されたデータ・ストアに作成されます。

ユーザー指定の VSAN ストレージ機能を持つ PersistentVolume を作成します。

kind: StorageClassapiVersion: storage.k8s.io/v1beta1metadata: name: vsan-policy-fastprovisioner: kubernetes.io/vsphere-volumeparameters: diskformat: thin hostFailuresToTolerate: "1" diskStripes: "2" cacheReservation: "20" datastore: VSANDatastore

Kubernetes 内部でのボリュームの動的プロビジョニングに対して VSAN ストレージ機能を指定できます。

PersistentVolume に関するストレージ要件 (パフォーマンスや可⽤性など) をストレージ・ポリシーが収集します。これらのポリシーは、要求されるサービス品質を確保するために、コンテナー・ボリューム・ストレージ・オブジェクトがどのようにプロビジョンされ、データ・ストア内でどのように割り振られるのかを決定し

ます。ストレージ・ポリシーはストレージ機能から構成され、ストレージ機能は通常はキーと値のペアで表されます。キーは、データ・ストアが提供できる特定のプロパティーです。値は、例えば、仮想ディスクによって⽀えられるコンテナー・ボリュームなど、プロビジョンされるオブジェクトに対してデータ・ストアが保

証するメトリックまたは範囲です。

VSAN は、複数のストレージ機能を公開しています。次の表は、vSphere クラウド・プロバイダーがサポートする VSAN ストレージ機能のリストです。

表 1. VSAN ストレージ機能ストレージ機能の名前説明

cacheReservation フラッシュ読み取りキャッシュ予約

diskStripes オブジェクト当たりのディスク・ストライプの数

forceProvisioning プロビジョニングを強制

hostFailuresToTolerate 容認できる障害数

iopsLimit オブジェクトの IOPS 限度objectSpaceReservationオブジェクト・スペース予約

vSphere インフラストラクチャー管理者は、Kubernetes 内部でストレージ・クラスを作成する間に、ストレージ機能に関してアプリケーションのストレージ要件を指定できます。管理者は、StorageClass を作成するときに、表 1で使⽤されているストレージ機能名を指定する必要があります。それらの名前は VSAN が使⽤するものと異なる場合


があるためです。例えば、オブジェクト当たりのディスク・ストライプの数は、VSAN 資料では stripeWidth という名前です。しかし、vSphere クラウド・プロバイダーが使⽤する名前は diskStripes です。

GlusterFS ⽤のストレージ・クラスの作成 vSphere ボリューム⽤のストレージ・クラスの作成

vSphere ボリューム⽤のストレージ・クラスの作成

ストレージ・クラスを作成して、vSphere データ・ストア上に PersistentVolume を提供します。


前提条件

IBM® Cloud Private が vSphere クラウド・プロバイダーと共に構成されている必要があります。 vSphere クラウド・プロバイダーの構成を参照してください。


vSphere ボリューム⽤のストレージ・クラスを作成するには、ストレージ・クラス定義に以下のフィールド値を指定します。

metadata:name: ストレージ・クラス・オブジェクトの名前。

parameters:diskformat: thin、zeroedthick、または eagerzeroedthick。datastore: データ・ストアの名前。ボリュームは、ストレージ・クラスに指定されたデータ・ストア上に作成されます。

ストレージ・クラスの作成⽅法の例を以下に⽰します。

1. ストレージ・クラス定義を含む YAML ファイルを作成します。

vim vsphere-volume-storage-class-1.yaml

kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: storage-class-1 provisioner: kubernetes.io/vsphere-volume parameters: diskformat: thin datastore: datastore-1

2. ストレージ・クラスを作成します。

kubectl create -f vsphere-volume-storage-class-1.yaml


storageclass "storage-class-1" created

3. ストレージ・クラスが作成されたことを確認します。

kubectl describe sc storage-class-1



Name: storage-class-1 IsDefaultClass: No Annotations: <none> Provisioner: kubernetes.io/vsphere-volume Parameters: datastore=datastore-1,diskformat=thin Events: <none>

GlusterFS ⽤のストレージ・クラスの作成

GlusterFS ストレージをプロビジョンするためのストレージ・クラスを作成します。


前提条件

IBM® Cloud Private 環境で GlusterFS クラスター⽤のストレージ・クラスを作成する場合、GlusterFS クラスターの準備ができていることを確認してください。 GlusterFS クラスターの追加は、IBM Cloud Private のインストール中または後に⾏うことができます。

IBM Cloud Private 環境の外部で構成された GlusterFS サーバーを使⽤する場合、GlusterFS サーバーに Heketiがインストールされていることを確認してください。 IBM Cloud Private マスター・ノードから Heketi サーバーがアクセス可能であるかどうかを確認するには、マスター・ノードで以下のコマンドを実⾏します。

curl http://<Heketi_server_IP>:<Heketi_server_port>/hello

コマンド出⼒に Hello from Heketi が含まれている場合、Heketi サーバーはアクセス可能です。


GlusterFS ⽤のストレージ・クラスを作成するには、ストレージ・クラス定義に以下のフィールド値を指定します。

metadata:name は、ストレージ・クラスの名前です。

parameters:

resturl は、ボリュームをプロビジョンする Heketi REST URL です。

IBM® Cloud Private クラスターの外部にある GlusterFS サーバーの場合、構⽂は次のとおりです。

http://<Heketi_server_IP>:<Heketi_server_port>

IBM® Cloud Private クラスター内の GlusterFS クラスターの場合、構⽂は次のとおりです。

http://<Heketi_service_cluster_IP>:<Heketi_service_port>

Heketi サービスのクラスター IP を取得するには、次のコマンドを実⾏します。

kubectl -n kube-system get service heketi -o=jsonpath='{.spec.clusterIP}'

Heketi サービスのポート番号を取得するには、次のコマンドを実⾏します。

kubectl -n kube-system get service heketi -o=jsonpath='{.spec.ports[0].port}'

volumetype (オプション) は、ボリュームのタイプです。有効なパラメーター値は、none、replicate:<replicate_count>、および disperse:<data>:<redundancy_count> です。ボリ


ューム・タイプが指定されない場合、プロビジョナーがボリューム・タイプを replicate:3 に設定します。

GlusterFS ⽤のストレージ・クラスを作成するには、以下の例で⽰されている⼿順を実⾏する必要があります。

1. 以下のストレージ・クラス定義を含んでいる、glusterfs-glusterfs-distributed.yaml という名前のYAML ファイルを作成します。

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: glusterfs-distributed provisioner: kubernetes.io/glusterfs parameters: resturl: "http://10.0.0.185:8080" restuser:"admin" secretName:"heketi-secret" secretNamespace:"kube-system" volumetype: replicate:3

注: GlusterFS クラスターが IBM® Cloud Private 環境にある場合、以下のパラメーター値を使⽤する必要があります。

restuser は "admin" でなければなりません。secretName は "heketi-secret" でなければなりません。secretNamespace は "kube-system" でなければなりません。

2. ストレージ・クラスを作成します。

kubectl create -f glusterfs-glusterfs-distributed.yaml


storageclass "glusterfs-distributed" created

3. ストレージ・クラスが作成されたことを確認します。

kubectl describe sc glusterfs-distributed

ストレージ・クラスの削除

不要になったストレージ・クラスを削除します。


ストレージ・クラスを削除するには、以下の Kubernetes コマンド・ライン (kubectl) コマンドを使⽤します。 kubectl のインストールと構成について詳しくは、kubectl CLI を使⽤した IBM® Cloud Private クラスターへのアクセスを参照してください。

kubectl delete storageclass <storage class name>


$ kubectl delete storageclass glusterfs-distributed storageclass "glusterfs-distributed" deleted

PersistentVolume

PersistentVolumes の管理⽅法について説明します。


PersistentVolume の作成 PersistentVolume の削除

PersistentVolume の作成

クラスター内のすべてのコンテナーで使⽤可能なストレージをセットアップします。

PersistentVolume のリストを表⽰するには、ナビゲーション・メニューから「プラットフォーム」 > 「ストレージ」をクリックします。

management console から PersistentVolume を作成するために、2 つの形式が使⽤可能です。

「PersistentVolume の作成」ダイアログ・ボックスでパラメーター値を⼊⼒することによって、または、YAML ファイルを「リソースの作成」ウィンドウに貼り付けることによって、PersistentVolume を作成できます。


「PersistentVolume の作成」ダイアログ・ボックスを使⽤した PersistentVolume の作成

1. ナビゲーション・メニューから、「プラットフォーム」 > 「ストレージ」をクリックします。2. 「PersistentVolume の作成」をクリックします。

3. ストレージ詳細を⼊⼒します。

以下のパラメーターは、ストレージを作成するために必須です。

名前

容量

アクセス・モード

再利⽤ポリシー

ストレージ・タイプ - 「PersistentVolume の作成」ダイアログ・ボックスを使⽤して新規ストレージを作成している場合、選択できるのは、NFS、GlusterFS、hostPath、または vSphere のみです。他のタイプのストレージを使⽤するには、「リソースの作成」ウィンドウを使⽤します。

ストレージのパラメーター - このパラメーターは、選択されたストレージ・タイプに基づきます。例えば、NFS ストレージを選択した場合、ストレージのサーバーおよびパスを指定する必要があります。


「リソースの作成」ウィンドウを使⽤した PersistentVolume の作成

1. ダッシュボードから、「リソースの作成」をクリックします。2. YAML ファイルをコピーして「リソースの作成」ダイアログ・ボックスに貼り付けます。永続ボリュームの作成について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes を参照してください。


デプロイメントが完了したら、新規 PersistentVolume がリスト中に表⽰されます。その PersistentVolume の状況を確認してください。ボリュームは Available 状態でなければなりません。

NFS PersistentVolume の作成 Glusterfs PersistentVolume の作成 hostPath PersistentVolume の作成


https://v1-10.docs.kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes

NFS PersistentVolume の作成

ネットワーク・ファイル・システム (NFS) PersistentVolume を作成します。

前提条件

NFS サーバーがセットアップされていて、使⽤可能である必要があります。 IBM® Cloud Private においてサポートされる NFS バージョンについて詳しくは、サポートされるファイル・システムおよびストレージを参照してください。

NFS クライアント・パッケージが IBM Cloud Private クラスター内のすべてのノードにインストールされている必要があります。


sudo apt-get update

sudo apt-get install nfs-common

Red Hat Enterprise Linux (RHEL) では、次のコマンドを実⾏します。

yum install nfs-utils

「PersistentVolume の作成」ダイアログ・ボックスを使⽤した NFS PersistentVolumeの作成

NFS PersistentVolume をクラスター内に作成できます。その後、アプリケーション内のコンテナーはそれをデータ永続性のために使⽤できます。



「PersistentVolume の作成」ウィンドウを使⽤した NFS PersistentVolume の作成

NFS PersistentVolume をセットアップするには、以下のようにします。


3. PersistentVolume 詳細を⼊⼒します。

以下のパラメーターは、NFS PersistentVolume を作成するために必須です。

「⼀般」タブ

名前 - PersistentVolume の名前を指定します。容量



ストレージのタイプ - NFS を選択します

「パラメーター」タブ


ストレージのパラメーター。パラメーターは、キーと値のペアとして指定されます。 NFS の場合、以下を指定する必要があります。

サーバー

キー: - server値: - NFS サーバーのホスト名または IP。

パス

キー: - path値: - 共有ディレクトリーとしてマウントされる、NFS サーバー上のディレクトリーのロケーション。


「リソースの作成」ウィンドウを使⽤した NFS PersistentVolume の作成


2. YAML ファイルまたは JSON ファイルをコピーして「リソースの作成」ダイアログ・ボックスに貼り付けます。 YAML ファイルの使⽤による割り当て量の作成について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes を参照してください。

単純な YAML ファイルは、以下のテキストのようになります。

apiVersion: v1kind: PersistentVolumemetadata: name: nfsvol01spec:capacity: storage: 40GiaccessModes: - ReadWriteOncepersistentVolumeReclaimPolicy: Recyclenfs: path: <insert/path/to/share> server: <insert_nfs_server_ip_or_name>


デプロイメントが完了したら、新規 NFS PersistentVolume が PersistentVolume リスト中に表⽰されます。そのPersistentVolume の状況を確認してください。 PersistentVolume の状況は「Available」でなければなりません。

GlusterFS PersistentVolume の作成

GlusterFS PersistentVolume を作成します。

注: ストレージ・クラスを作成することによって IBM® Cloud Private ワーカー・ノードで GlusterFS ストレージをプロビジョンしたい場合、GlusterFS ⽤のストレージ・クラスの作成を参照してください。

GlusterFS PersistentVolume をクラスター内に作成できます。その後、アプリケーション内のコンテナーはそれをデータ永続性のために使⽤できます。





エンドポイントおよびサービスの作成

エンドポイントおよびサービスの作成は、IBM Cloud Private 環境の外部で構成された GlusterFS サーバーを使⽤している場合のみ⾏ってください。

このタスクを実⾏する前に、以下が必要です。

複数の GlusterFS サーバーがある GlusterFS サーバー・クラスターが IBM Cloud Private クラスターからアクセス可能である必要があります。 GlusterFS サーバーのセットアップについて詳しくは、https://www.howtoforge.com/high-availability-storage-with-glusterfs-3.2.x-on-debian-wheezy-automatic-file-replication-mirror-across-two-storage-servers を参照してください。GlusterFS ストレージが作成されている必要があります。

GlusterFS クライアントがすべての IBM Cloud Private ノードにインストールされている必要があります。


sudo apt-get update

sudo apt-get install glusterfs-client

Red Hat Enterprise Linux (RHEL) では、次のコマンドを実⾏します。


RHEL Linux® on Power® (ppc64le) では、まずリポジトリーを作成し、次に GlusterFS クライアントをインストールします。

リポジトリーを作成します。

[centos-gluster312] name=CentOS-$releasever - Gluster 3.12 baseurl=https://buildlogs.centos.org/centos/7/storage/$basearch/gluster-3.12/ gpgcheck=0 enabled=1

GlusterFS クライアントをインストールします。


GlusterFS サーバー・クラスターのエンドポイントを作成します。

YAML 例

--- kind: Endpoints apiVersion: v1 metadata: name: glusterfs-cluster subsets: - addresses: - ip: 9.111.249.161 ports: - port: 1729 - addresses: - ip: 9.111.249.162 ports: - port: 1729

指定する IP アドレスは、GlusterFS サーバー・クラスター内のノードのアドレスである必要があります。


https://www.howtoforge.com/high-availability-storage-with-glusterfs-3.2.x-on-debian-wheezy-automatic-file-replication-mirror-across-two-storage-servers

Kubernetes でエンドポイントを作成します。

kubectl create -f glusterfs-endpoints.yaml

エンドポイントが正常に作成されたことを確認します。

kubectl get endpoints

結果例:

NAME ENDPOINTS glusterfs- glusterfs-cluster 9.111.249.161:1729,9.111.249.162:1729 1h

エンドポイント⽤のサービスを作成します。エンドポイント⽤のサービスを作成することによって、エンドポイントが永続することが許可されます。セレクターなしでサービスを追加すると、エンドポイントが⼿動で追加されたことが Kubernetes に通知されます。

YAML 例

--- kind: Service apiVersion: v1 metadata: name: glusterfs-cluster spec: ports: - port: 1729

Kubernetes でサービスを作成します。

kubectl create -f glusterfs-service.yaml

「PersistentVolume の作成」ダイアログ・ボックスを使⽤した GlusterFSPersistentVolume の作成

1. IBM Cloud Private management console にログインします。2. ナビゲーション・メニューから、「プラットフォーム」 > 「ストレージ」をクリックします。3. 「PersistentVolume の作成」をクリックします。

4. PersistentVolume 詳細を⼊⼒します。 JSON 形式で詳細を指定するか、または、「PersistentVolume の作成」ダイアログ・ボックスのフィールドに⼊⼒して詳細を指定することができます。

以下のパラメーターは、PersistentVolume を作成するために必須です。

「⼀般」タブ

名前 - PersistentVolume の名前を指定します。容量



ストレージのタイプ - Glusterfs を選択します


ストレージのパラメーター。パラメーターは、キーと値のペアとして指定されます。以下を指定する必要があります。

エンドポイント

キー: - endpoints


値: - ステップ 1 で作成したエンドポイントの名前。パス

キー: - path値: - GlusterFS ストレージ名。


新規 GlusterFS PersistentVolume が PersistentVolume リスト中に表⽰されます。その PersistentVolume の状況を確認してください。 PersistentVolume の状況は Available でなければなりません。

「リソースの作成」ウィンドウを使⽤した GlusterFS PersistentVolume の作成

1. IBM Cloud Private management console にログインします。2. ダッシュボードから、「リソースの作成」をクリックします。3. YAML ファイルまたは JSON ファイルをコピーして「リソースの作成」ウィンドウに貼り付けます。 YAML ファイルの使⽤による PersistentVolume の作成について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes を参照してください。


デプロイメントが完了したら、新規 PersistentVolume がリスト中に表⽰されます。その PersistentVolume の状況を確認してください。ボリュームは Available 状態でなければなりません。

hostPath PersistentVolume の作成

hostPath PersistentVolume を作成します。

hostPath ボリュームは、ホスト・ノードのファイル・システムからポッドへ、ファイルまたはディレクトリーをマウントします。 hostPath ボリュームについて詳しくは、Types of Volumes を参照してください。

hostPath PersistentVolume は、単⼀ノードのクラスターでのみ使⽤する必要があります。 Kubernetes は、現在、マルチノード・クラスターでの hostPath をサポートしていません。

management console を使⽤して hostPath PersistentVolume を作成できます。

IBM® Cloud Private クラスター内のパーシスタント・ボリュームのリストを表⽰するには、ナビゲーション・メニューから「プラットフォーム」 > 「ストレージ」をクリックします。


「PersistentVolume の作成」ダイアログ・ボックスを使⽤した hostPathPersistentVolume の作成

hostPath PersistentVolume を作成するには、以下のようにします。


3. PersistentVolume 詳細を⼊⼒します。

hostPath PersistentVolume を作成するには、以下のパラメーターを指定してください。

「⼀般」タブ



https://v1-10.docs.kubernetes.io/docs/concepts/storage/volumes/#hostpath

名前 - (必須) PersistentVolume の名前を指定します。容量 - (必須) ストレージ容量を指定します。アクセス・モード - (オプション) ReadWriteOnce を選択します。再利⽤ポリシー - (オプション) 保持またはリサイクルを選択します。

ストレージ・タイプ - (必須) ホスト・パスを選択します。

「ラベル」タブ

PersistentVolume にラベルを付加します。ラベルは、キーと値のペアです。例えば、type=local です。このパラメーターはオプションです。


ストレージのパラメーター。パラメーターは、キーと値のペアとして指定されます。 hostPath の場合、以下を指定する必要があります。

パス

キー: - path値: - クラスターのノード上のファイルまたはディレクトリーのロケーション (例: /tmp/data)。


「リソースの作成」ウィンドウを使⽤した hostPath PersistentVolume の作成


2. YAML ファイルまたは JSON ファイルをコピーして「リソースの作成」ウィンドウに貼り付けます。 YAML ファイルの使⽤による PersistentVolume の作成について詳しくは、Create a PersistentVolume を参照してください。

単純な YAML の例を以下に⽰します。

kind: PersistentVolume apiVersion: v1 metadata: name: hostpath2 labels: type: local spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce reclaimPolicy: - Recycle hostPath: path: "/tmp/data1"


デプロイメントが完了したら、新規 hostPath PersistentVolume が PersistentVolume リスト中に表⽰されます。そのPersistentVolume の状況を確認してください。 PersistentVolume の状況は Available でなければなりません。

PersistentVolume の削除

不要になった PersistentVolume を削除します。


https://v1-10.docs.kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume

削除する PersistentVolume を使⽤しているアプリケーションがないことを確認してください。


PersistentVolume を削除するには、以下のようにします。

1. ナビゲーション・メニューから、「プラットフォーム」 > 「ストレージ」をクリックします。PersistentVolume のリストが表⽰されます。

2. リストから、削除する PersistentVolume に対して「アクション」 > 「削除」を選択します。

選択した PersistentVolume がリストから削除されます。

PersistentVolumeClaims

アプリケーション⽤のストレージを要求するために PersistentVolumeClaim を使⽤できます。

PersistentVolumeClaim は、PersistentVolumeClaim を使⽤するアプリケーションと同じ名前空間に存在している必要があります。

PersistentVolumeClaim は、関連付けられたストレージにアクセスするために使⽤されます。アプリケーションを作成し、PersistentVolumeClaim をアタッチすると、この要求に関連付けられた PersistentVolume がホストにマウントされ、要求を⾏ったポッドのコンテナーで使⽤可能になります。

PersistentVolumeClaim の作成アプリケーションへの PersistentVolumeClaim のアタッチ PersistentVolumeClaim の削除

PersistentVolumeClaim の作成

ストレージをアプリケーションに割り振るために、PersistentVolumeClaim を作成できます。

このタスクを使⽤して、アプリケーション⽤の PersistentVolumeClaim を作成します。 PersistentVolumeClaim を作成する前に、使⽤可能な PersistentVolume がクラスター内になければなりません。ストレージの管理について詳しくは、ストレージを参照してください。

使⽤可能な PersistentVolume が PersistentVolumeClaim にバインドされ、アプリケーションで使⽤できます。各PersistentVolume は 1 つのみの PersistentVolumeClaim にバインドできます。

「PersistentVolumeClaim の作成」ダイアログ・ボックスでパラメーター値を⼊⼒することによって、または、YAMLファイルを「リソースの作成」ウィンドウに貼り付けることによって、PersistentVolumeClaim を作成できます。

PersistentVolumeClaim のリストを表⽰するには、ナビゲーション・メニューから「プラットフォーム」 > 「ストレージ」 > 「PersistentVolumeClaim」をクリックします。


「PersistentVolumeClaim の作成」ダイアログ・ボックスを使⽤したPersistentVolumeClaim の作成

1. ナビゲーション・メニューから、「プラットフォーム」 > 「ストレージ」をクリックします。2. 「PersistentVolumeClaim」を選択します。3. 「PersistentVolumeClaim の作成」をクリックします。

4. 「PersistentVolumeClaim の作成」ダイアログ・ボックスで PersistentVolumeClaim 詳細を⼊⼒します。


以下のパラメーターは、PersistentVolumeClaim を作成するために必須です。

名前 - PersistentVolumeClaim の名前を指定します。ストレージ要求 - 必要なストレージの量。アクセス・モード - 複数のアクセス・モードをサポートするボリュームの場合、必要なモードを指定する必要があります。


「リソースの作成」ウィンドウを使⽤した PersistentVolumeClaim の作成

1. ダッシュボードから、「リソースの作成」をクリックします。2. YAML ファイルまたは JSON ファイルをコピーして「リソースの作成」ウィンドウに貼り付けます。 YAML ファイルの使⽤による PersistentVolumeClaim の作成について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims を参照してください。


PersistentVolumeClaim が正常に作成された場合、新規 PersistentVolumeClaim が PersistentVolumeClaim リスト中に表⽰されます。状況を確認してください。 PersistentVolumeClaim の状況は Bound でなければなりません。

デプロイメントへの PersistentVolumeClaim のアタッチ

デプロイメントにストレージを提供します。

このタスクを使⽤して、PersistentVolumeClaim にバインドされた PersistentVolume と共に新規デプロイメントを作成します。

PersistentVolumeClaim をデプロイメントにアタッチできるのは、デプロイメントの最初の作成中のみです。

PersistentVolumeClaim のリストを表⽰するには、ナビゲーション・メニューから「プラットフォーム」 > 「ストレージ」 > 「PersistentVolumeClaim」をクリックします。


デプロイメントに PersistentVolumeClaim をアタッチするには、次のようにします。

1. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」をクリックします。2. 「デプロイメントの作成」をクリックします。3. 「デプロイメントの作成」ダイアログ・ボックスから「ボリューム」タブを選択します。4. ボリュームについての以下の情報を指定します。

名前 - ボリュームの名前を指定します。ボリューム - 使⽤したい PersistentVolumeClaim の名前を指定します。この PersistentVolumeClaim は存在していなければならず、バインド済みの状態である必要があります。 PersistentVolumeClaim の作成について詳しくは、PersistentVolumeClaim の作成を参照してください。マウント・パス - このマウント・パスは、コンテナー内部で使⽤したいロケーションです。

5. 必要なデプロイメント詳細を⼊⼒します。新規デプロイメントのデプロイについて詳しくは、デプロイメントの作成を参照してください。

6. 「作成」をクリックします。ポッド詳細を確認して、PersistentVolume がマウントされていることを検証できます。

PersistentVolumeClaim の削除

不要になった PersistentVolumeClaim を削除します。


https://v1-10.docs.kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims

このタスクを使⽤して、PersistentVolumeClaims をクラスターから削除します。


PersistentVolumeClaim を削除するには、以下のようにします。

1. ナビゲーション・メニューから、「プラットフォーム」 > 「ストレージ」をクリックします。2. 「PersistentVolumeClaim」を選択します。3. 削除する PersistentVolumeClaim に対して、「アクション」 > 「削除」を選択します。

選択した PersistentVolumeClaim がリストから削除されます。

リソース

アプリケーションを作成するときに、各コンテナーがどれだけの中央演算処理装置 (CPU)、メモリー (RAM)、およびグラフィカル・プロセッシング・ユニット (GPU) の各リソースを使⽤できるかを、オプションで指定できます。

CPU、メモリー、および GPU は、計算リソース、または単にリソースと総称されます。計算リソースは、要求、割り振り、および使⽤が可能な、測定可能な量のクラスター・リソースです。

コンテナーのリソース制限を指定した場合、ワーカー・ノード間でのアプリケーション・コンテナーの分散を最適化

できます。

計算リソースの管理について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ を参照してください。

ノード上でのアプリケーションの実際のメモリー、CPU、または GPU の使⽤量は、時間の経過と共に変わります。ノード上でのメモリー、CPU、または GPU の合計使⽤量も、時間の経過と共に変わります。 management consoleのダッシュボード・ページで、クラスターのメモリーおよび CPU の使⽤量をモニターできます。ノードのページから各ノードのリソース使⽤量をモニターすることもできます。報告された実際のリソース使⽤量には、ノード上のすべてのコンテナーの統計も含まれます。これらの使⽤量の数値には、IBM® Cloud Private が使⽤するリソースと、docker run などのその他のプロセスが使⽤するリソースが含まれています。

Nvidia GPU サポート GPU ワーカー・ノードの構成

Nvidia GPU サポート

IBM® Cloud Private クラスター内部のグラフィカル・プロセッシング・ユニット (GPU) リソースを、アプリケーションおよびジョブに割り当てることができます。

GPU は、機械学習や⾼性能コンピューティング・システムなどのフィールドで道を開いている新しいワークロードを⽀えている処理能⼒です。 Kubernetes 1.6.1 以降、CPU やメモリーなどの他のリソースと同様の⽅法で GPU を管理できるようになりました。

IBM Cloud Private クラスター内の GPU の使⽤には、以下の制約事項が適⽤されます。

GPU リソースを、GPU 物理コアの数を⽰す正整数で表す必要があります。部分的な GPU コア割り振りはサポートされていません。

GPU ドライバー・バージョン 352 以降を使⽤する必要があります。それよりも古いバージョンは、IBMCloud Private との互換性がない可能性があります。GPU リソースは、コンテナーのみに割り当てることができ、ポッドに割り当てることはできません。GPU リソース制限のみを宣⾔でき、要求は宣⾔できません。


https://v1-10.docs.kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

接続された GPU リソースと共にアプリケーションをデプロイする⽅法について詳しくは、『接続された GPU リソースを含むデプロイメントの作成』を参照してください。

GPU ワーカー・ノードの構成

GPU ワーカー・ノードのデプロイメントの準備ができていることを確認してください。

GPU ドライバー・バージョンの更新

IBM® Cloud Private のインストールの前または後に、GPU ドライバーを更新できます。

1. GPU ドライバー・バージョンを更新するには、 http://www.nvidia.com/Download/index.aspx を参照してください。

2. GPU ドライバー・バージョンを更新したら、Kubernetes が GPU ドライバーへの変更を適⽤できるように、Kubelet を再始動します。

systemctl restart kubelet

ノードのデプロイメントの準備ができていることの確認

Nvidia GPU ドライバーがインストールされているワーカー・ノードから、以下の確認⼿順を実⾏する必要があります。

1. Nvidia が稼働中であることを確認します。

nvidia-smi


Thu Nov 9 16:44:28 2017 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 375.66 Driver Version: 375.66 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 Tesla K80 Off | 0000:08:00.0 Off | 0 | | N/A 47C P8 26W / 149W | 0MiB / 11439MiB | 0% Default | +-------------------------------+----------------------+----------------------+ | 1 Tesla K80 Off | 0000:09:00.0 Off | 0 | | N/A 36C P8 31W / 149W | 0MiB / 11439MiB | 0% Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+

エラー・メッセージが返された場合は、ノードに GPU ドライバーを再インストールしてください。http://www.nvidia.com/Download/index.aspx を参照してください。

2. nvidia-uvm デバイス・ファイルが使⽤可能であることを確認します。

ls /dev/nvidia-uvm


http://www.nvidia.com/Download/index.aspx


「No such file or directory」というエラー・メッセージが返された場合、nvidia-uvm デバイス・ファイルを作成する必要があります。

nvidia-uvm デバイス・ファイルを作成するには、以下のステップを実⾏します。

Linux® 64-bit の場合

1. IBM developerWorks コミュニティーからワーカー・ノードへ cudaInit_x86 ファイルをダウンロードします。 cudaInit_x86 を参照してください。

2. ワーカー・ノードで以下のコマンドを実⾏します。

./cudaInit_x86


1. IBM developerWorks コミュニティーからワーカー・ノードへ cudaInit_ppc64le ファイルをダウンロードします。 cudaInit_ppc64le を参照してください。

2. ワーカー・ノードで以下のコマンドを実⾏します。

./cudaInit_ppc64le

3. GPU ドライバーのログ・ファイルを⾒つけます。

ls /var/lib/docker/volumes/nvidia_driver_<xxx.xx>

ここで <xxx.xx> は Nvidia ドライバーのバージョンです。 nvidia-smi コマンドを実⾏することで、バージョン情報を取得できます。

「No such file or directory」というエラー・メッセージが返された場合、GPU ドライバーのログ・ディレクトリーを作成する必要があります。

GPU ログ・ディレクトリーを作成するには、以下のステップを実⾏します。

1. /var/lib/docker/volumes フォルダーを削除し、kubelet を再始動します。

rm -rf /var/lib/docker/volumes systemctl restart kubelet

2. GPU ドライバーのログ・ファイルが作成されたことを確認します。

ls /var/lib/docker/volumes/nvidia_driver_<xxx.xx>

ログ・ファイルがまだ作成されていない場合は、ノードに GPU ドライバーを再インストールしてください。 http://www.nvidia.com/Download/index.aspx を参照してください。

これで、ワーカー・ノードで GPU リソースを使⽤するアプリケーションをデプロイする準備ができました。『接続された GPU リソースを含むデプロイメントの作成』を参照してください。

脆弱性アドバイザー

アドバイザーを使⽤して、 IBM® Cloud Private プライベート・レジストリー内のコンテナー・イメージのセキュリティー状況を取得します。脆弱性アドバイザーは、環境内の稼働しているコンテナーに対するセキュリティー検査も実⾏します。

脆弱性アドバイザーについて詳しくは、IBM Cloud 資料 {: newwindow} の脆弱性アドバイザーについて_セクションを参照してください。


https://www.ibm.com/developerworks/community/files/app#/file/c81243bf-3327-4c3c-b5fb-e81e319ba935

https://www.ibm.com/developerworks/community/files/app#/file/7dff6a33-b2b8-4623-8b29-3efddc6e95b7


https://console.bluemix.net/docs/services/va/va_index.html#about

脆弱性アドバイザー機能は、IBM Cloud Private の Cloud Native エディションおよび Enterprise エディションでのみサポートされています。

脆弱性アドバイザーは、IBM Cloud Private クラスターのインストール中、またはインストール後に有効にすることができます。

脆弱性アドバイザーを有効にするには、『脆弱性アドバイザーの有効化』を参照してください。

クラスターの脆弱性アドバイザーのポストインストールを⾏うには、IBM Cloud Private クラスターの脆弱性アドバイザー・ポストインストールの有効化を参照してください。

脆弱性アドバイザーのコンポーネントのリストについては、『コンポーネント』を参照してください。

脆弱性アドバイザーの構成

脆弱性アドバイザーのコンテナー・クローラーの構成

脆弱性アドバイザーのイメージ・クローラーの構成

イメージを再スキャンするための脆弱性アドバイザーのイメージ・クローラーの構成

ログおよびレポート管理

Elasticsearch クラスターのデータ・キュレーション間隔の構成Kafka クラスターのログ・クリーンアップ間隔の構成

セキュリティー・レポートの表⽰


管理者パスワード変更後の脆弱性アドバイザー設定の更新

脆弱性アドバイザーの構成

脆弱性アドバイザーのコンテナー・クローラーの構成

1. ナビゲーション・メニューから、「構成」 > 「ConfigMap」をクリックします。2. 検索ボックスに「live-crawler」と⼊⼒します。3. vulnerability-advisor-live-crawler ConfigMap を対象として「アクション」>「編集」を選択します。 vulnerability-advisor-live-crawler JSON ファイルが表⽰されます。

4. enabled パラメーターの値を変更します。クローラーを無効にするには、enabled パラメーターを false に設定します。クローラーを有効にするには、enabled パラメーターを true に設定します。

5. (オプション) ホスト上のコンテナーをスキャンする時間間隔を構成することもできます。時間間隔を構成するには、crawl-interval パラメーターの値を変更します。デフォルト値は 86400 (1 ⽇当たりの秒数) です。このパラメーターを更新した場合、クローラー・コンテナーを再始動する必要があります。コンテナー・クローラーが、live-crawler-amd64 または live-crawler-ppc64le のいずれかの名前のデーモンセットとしてデプロイされます。「ワークロード (Workloads)」>「デーモンセット (DaemonSet)」ページからデーモンセットを再始動できます。

6. 「送信」をクリックします。

脆弱性アドバイザーのイメージ・クローラーの構成

1. ナビゲーション・メニューから、「構成」 > 「ConfigMap」をクリックします。2. 検索ボックスに「registry-crawler」と⼊⼒します。3. vulnerability-advisor-registry-crawler ConfigMap を対象として「アクション」>「編集」を選択します。 vulnerability-advisor-registry-crawler JSON ファイルが表⽰されます。

4. enabled パラメーターの値を変更します。クローラーを無効にするには、enabled パラメーターを false に設定します。クローラーを有効にするには、enabled パラメーターを true に設定します。



イメージを再スキャンするための脆弱性アドバイザーのイメージ・クローラーの構成

1. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」をクリックします。2. 検索ボックスに「registry-crawler」と⼊⼒します。3. vulnerability-advisor-registry-crawler デプロイメントを対象として「アクション」>「編集」を選択します。 vulnerability-advisor-registry-crawler JSON ファイルが表⽰されます。

4. 次のパラメーターの値を変更します。

正常にスキャンされたイメージを再スキャンするには、RESET_WHITELIST オプションを true に設定します。

スキャンに失敗したイメージを再スキャンするには、RESET_BLACKLIST オプションを true に設定します。


ログおよびレポート管理

脆弱性アドバイザーのコンポーネント (Kafka ログおよび Elasticsearch インデックス) は、VA ノード上で多くのディスク・スペースを消費します。デフォルトでは、Kafka は 600 分 (10 時間) のログを保持し、Elasticsearch は 7 ⽇分のデータを保持します。このデータには、コンテナーおよびイメージ・レポートが含まれます。

Elasticsearch クラスターのデータ・キュレーション間隔の構成

1. ナビゲーション・メニューから、「構成」 > 「ConfigMap」をクリックします。2. 検索ボックスに「elasticsearch-curator」と⼊⼒します。3. vulnerability-advisor-elasticsearch-curator ConfigMap を対象として「アクション」>「編集」を選択します。 vulnerability-advisor-elasticsearch-curator JSON ファイルが表⽰されます。

4. unit_count パラメーターの値を変更します。単位は⽇です。デフォルト値は 7 ⽇間です。5. 「送信」をクリックします。

Kafka クラスターのログ・クリーンアップ間隔の構成

1. kubectl CLI をセットアップします。『kubectl CLI を使⽤した IBM Cloud Private クラスターへのアクセス』を参照してください。

2. Kafka を再構成するように vulnerability-advisor-kafka StatefulSet オブジェクトを編集します。

kubectl --namespace=kube-system edit StatefulSet vulnerability-advisor-kafka

3. KAFKA_LOG_RETENTION_MINUTES 環境変数の値を変更します。デフォルト値は 600 分 (10 時間) です。

4. 変更を保存します。

セキュリティー・レポートの表⽰

management consoleから、コンテナーおよびイメージのセキュリティー・レポートを、名前空間ごとに編成して表⽰できます。これらのセキュリティー・レポートは、デフォルト・ポリシーを使⽤して⽣成されます。

1. ナビゲーション・メニューから「プラットフォーム (Platform)」>「脆弱性アドバイザー」をクリックします。

2. 表⽰したい名前空間を選択します。脆弱性アドバイザーのダッシュボードが表⽰されます。このダッシュボードから、選択された名前空間内のコンテナーおよびイメージのレポートをレビューできます。レポートには、各コンテナーまたはイメージに関する以下の情報が詳細に記載されています。


名前 (Name) - コンテナーまたはイメージの名前。所有者 (Owner) - イメージまたはコンテナーが属する名前空間。クロール時刻 (Crawled Time) - イメージまたはコンテナーがスキャンされたタイム・スタンプ。タイプ (Type) - オブジェクトがコンテナーまたはイメージのいずれであるかを指定します。組織のポリシー (Organizational Policies) - 使⽤されているセキュリティー・ポリシー。これは、「ポリシーの管理 (Managing Policies)」ページで設定されます。脆弱パッケージ (Vulnerable Packages) - コンテナーまたはイメージで特定された現在の脆弱性。コンテナー設定 (Container Settings) - 潜在的なセキュリティーおよびコンプライアンス上の問題の要約。セキュリティーの推奨事項もここに表⽰されます。


1. ナビゲーション・メニューから「プラットフォーム (Platform)」>「脆弱性アドバイザー」をクリックします。

2. レポートを表⽰する対象の名前空間を選択します。脆弱性アドバイザーのダッシュボードが表⽰されます。3. 脆弱性アドバイザーのダッシュボードの⽔平ナビゲーション・メニューから、「ポリシーの管理 (Manage

Policies)」を選択します。.4. 「ポリシーの管理 (Manage Policies)」ページで「ON/OFF」ラジオ・ボタンを切り替えて、⾏いたいポリシーの変更を選択します。

5. 「ポリシーの送信」をクリックします。

IBM Cloud Private クラスターの脆弱性アドバイザー・ポストインストールの有効化

IBM Cloud Private クラスターのインストール後に脆弱性アドバイザー・フィーチャーを有効にします。

1. Helm CLI をセットアップします。 Helm CLI のセットアップを参照してください。2. kubectl をセットアップします。 kubectl CLI を使⽤した IBM® Cloud Private クラスターへのアクセスを参照してください。

3. 脆弱性アドバイザーの専⽤ノードを作成します。 Elasticsearch や Kafka などの脆弱性アドバイザー・コンポーネントは、多くのシステム・リソースを使⽤します。脆弱性アドバイザーには、専⽤のノードを割り振る必要があります。

Zookeeper および Kafka のコンポーネントには、奇数個の va ノードが必要です。 1 個または 3 個の vaノードを使⽤しなければなりません。実稼働環境の場合は、3 個の va ノードを使⽤してください。

脆弱性アドバイザーは、va=true と許容テイント dedicated=va:NoSchedule のラベルを持つノードにデプロイされます。次のコマンドで、専⽤ va ノードにラベルとテイントを追加できます。

kubectl label node <va_node_ip> va=true kubectl taint node <va_node_ip> dedicated=va:NoSchedule

<va_node_ip> は、専⽤の脆弱性アドバイザー・ノードの IP アドレスです。

4. 実稼働環境の場合は、データ永続性を有効にする必要があります。 Zookeeper、Kakfa、および Elasticsearchには、ローカル・ファイル・システムに脆弱性アドバイザー・データを保管するためにパーシスタント・ボリ

ュームが必要です。

1. 脆弱性アドバイザー・ノードで、Zookeeper、Kakfa、および Elasticsearch のコンポーネントのデータ・ディレクトリーを作成します。

mkdir -p /var/lib/icp/va/zookeeper


mkdir -p /var/lib/icp/va/kafka

mkdir -p /var/lib/icp/va/elasticsearch

2. Zookeeper のパーシスタント・ボリュームを作成します。指定例の <va_node_ip> プレースホルダーは、必ず、実際の脆弱性アドバイザー・ノードの IP アドレスに置き換えてください。パーシスタント・ボリュームの指定は、以下のようなコードになります。

--- apiVersion: v1 kind: PersistentVolume metadata: name: zookeeper-<va_node_ip> spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: zookeeper-storage local: path: /var/lib/icp/va/zookeeper nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <va_node_ip> --- kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: zookeeper-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer

3. Kakfa のパーシスタント・ボリュームを作成します。指定例の <va_node_ip> プレースホルダーは、必ず、実際の脆弱性アドバイザー・ノードの IP アドレスに置き換えてください。パーシスタント・ボリュームの指定は、以下のようなコードになります。

--- apiVersion: v1 kind: PersistentVolume metadata: name: kafka-<va_node_ip> spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: kafka-storage local: path: /var/lib/icp/va/kafka nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <va_node_ip>


--- kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: kafka-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer

4. Elasticsearch のパーシスタント・ボリュームを作成します。指定例の <va_node_ip> プレースホルダーは、必ず、実際の脆弱性アドバイザー・ノードの IP アドレスに置き換えてください。パーシスタント・ボリュームの指定は、以下のようなコードになります。

--- apiVersion: v1 kind: PersistentVolume metadata: name: va-elasticsearch-<va_node_ip> spec: capacity: storage: 100Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: va-elasticsearch-storage local: path: /var/lib/icp/va/elasticsearch nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <va_node_ip> --- kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: va-elasticsearch-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer

5. 脆弱性アドバイザーの Helm チャート・パッケージをダウンロードします。

docker run -t -e LICENSE=accept --rm -v "$(pwd)":/data/ ibmcom/icp-inception:2.1.0.3-ee cp /addon/vulnerability-advisor/vulnerability-advisor-1.2.1.tgz /data/

6. Helm チャートを解凍します。

tar -xvzf vulnerability-advisor-1.2.1.tgz

7. Helm チャートの内容を表⽰します。 vulnerability-advisor Helm チャートの内容を表⽰するには、以下のコマンドを実⾏します。

ls -l vulnerability-advisor/


total 80 -rw-r--r-- 1 root root 698 Apr 25 14:34 Chart.yaml -rw-r--r--@ 1 root root 18938 May 4 08:59 README.md drwxr-xr-x 5 root root 160 Apr 16 13:44 charts -rw-r--r-- 1 root root 406 Apr 25 14:34 requirements.lock -rw-r--r-- 1 root root 166 Apr 16 13:44 requirements.yaml


drwxr-xr-x 32 root root 1024 Apr 25 14:34 templates -rw-r--r-- 1 root root 4366 May 3 14:05 values.yaml

8. 脆弱性アドバイザーの Helm チャートを構成します。構成の設定とパラメーターの全リストについては、脆弱性アドバイザーの README ファイルを確認してください。構成プロセスの中では、以下の更新も必要です。

values.yaml に、Kafka、Zookeeper、および Elasticsearch の正しい StorageClass 名を指定します。前のステップで作成されたパーシスタント・ボリュームから、各コンポーネントの StorageClass 名を⼊⼿できます。values.yaml で、クラスター内の va ノードの数に⼀致するように、Kafka、Zookeeper、およびElasticsearch のレプリカを更新します。レプリカの値は、1 または 3 のいずれかにしてください。

9. 脆弱性アドバイザーの Helm チャートをインストールします。

helm install --name=vulnerability-advisor --namespace=kube-system --values=myvalues.yaml --tls ./vulnerability-advisor-1.2.1.tgz

注: 脆弱性アドバイザーは、kube-system 名前空間のみでインストールがサポートされています。 IBM CloudPrivate management console との統合を可能にするには、チャートの名前を vulnerability-advisor にする必要があります。

10. 脆弱性アドバイザー・ノードで、インストールを検証します。

1. すべての脆弱性アドバイザー・ポッドが Running 状態であることを確認します。

# kubectl -n kube-system get pods |grep vulnerability-advisor- vulnerability-advisor-compliance-annotator-c45c5747b-bm4hh 1/1 Running 0 31m vulnerability-advisor-compliance-indexer-bcf46c487-vj8fp 1/1 Running 0 31m vulnerability-advisor-config-indexer-75f796dc8f-v9wdr 1/1 Running 0 31m vulnerability-advisor-config-parser-74459fbf9d-c4jf8 1/1 Running 0 31m vulnerability-advisor-elasticsearch-client-6b967d6f49-84p99 1/1 Running 0 31m vulnerability-advisor-elasticsearch-data-0 1/1 Running 0 31m vulnerability-advisor-elasticsearch-master-7bf66f9fb9-dnllc 1/1 Running 0 31m vulnerability-advisor-kafka-0 1/1 Running 0 31m vulnerability-advisor-live-crawler-cqfnb 1/1 Running 0 31m vulnerability-advisor-live-crawler-ddj9l 1/1 Running 0 31m vulnerability-advisor-live-crawler-fgjn5 1/1 Running 0 31m vulnerability-advisor-notification-dispatcher-655f5f8848-sw7s2 1/1 Running 5 31m vulnerability-advisor-password-annotator-8655cfdbf-mjn66 1/1 Running 0 31m vulnerability-advisor-registry-crawler-7df8dd8ddb-67xxp 1/1 Running 0 31m vulnerability-advisor-rootkit-annotator-6bcb999655-wvnnz 1/1 Running 0 31m vulnerability-advisor-rootkit-indexer-7ffb4d8668-gvhlq 1/1 Running 0 31m vulnerability-advisor-sas-apiserver-59d55c8945-485nk 1/1 Running 0 31m vulnerability-advisor-sas-mgmt-54f979dbdf-m9fln 1/1 Running 0 31m vulnerability-advisor-secconfig-annotator-7ccb7dfd47-95nqr 1/1 Running 0 31m


vulnerability-advisor-secconfig-indexer-8fd58cd47-x4wh7 1/1 Running 0 31m vulnerability-advisor-statsd-85c4894ffc-lr8gl 1/1 Running 0 31m vulnerability-advisor-usncrawler-t542v 0/1 Completed 3 31m vulnerability-advisor-vulnerability-annotator-67f5c486d-gmfqb 1/1 Running 0 31m vulnerability-advisor-vulnerability-indexer-5d786f7554-p25hq 1/1 Running 0 31m vulnerability-advisor-zookeeper-0 1/1 Running 0 31m

2. management console からセキュリティー・レポートを表⽰します。セキュリティー・レポートの表⽰を参照してください。

これで、脆弱性アドバイザーを使⽤する準備ができました。脆弱性アドバイザーの処理について詳しくは、脆弱性アドバイザーを参照してください。


プラットフォームへのアクセスの管理⽅法を学習します。

認証役割ベースのアクセス制御 LDAP 接続の構成 Helm リポジトリーの管理名前空間ポッド・セキュリティーリソース・クォータの設定チームスーパー管理者権限資格情報の変更クラスター・アクセス URL のカスタマイズ認証および許可の監査ログ

認証

クラスター management console と OpenID Connect (OIDC) プロバイダー間のユーザー資格情報の転送は、認証マネージャーによって進められます。


認証マネージャーは、management console からユーザー資格情報を受け⼊れて、バックエンド OIDC プロバイダーに資格情報を転送します。 OIDC プロバイダーは、エンタープライズ・ディレクトリーに対してユーザー資格情報を検証します。次に JSON Web トークン (JWT) のコンテンツを持つ認証 Cookie (auth-cookie) を認証マネージャーに返します。この認証 Cookie はその後 management console に戻されます。 Cookie はセッション中に更新されます。これは、management console からサインアウト後、またはブラウザーをクローズしてから 12 時間有効です。

management console から作成された連続するすべての認証要求について、フロントエンド NGINX サーバーは、要求内の使⽤可能な認証 Cookie をデコードして、認証マネージャーを呼び出すことで要求を検証します。

役割ベースのアクセス制御

IBM® Cloud Private は複数の役割をサポートします。役割は、実⾏できるアクションを決定します。

クラスター管理者役割とアクション

IBM Cloud Private は、クラスター管理者役割をサポートします。

表 1. クラスター管理者役割とアクション役割説明アクション


役割説明アクション

クラスタ

ー管理者

IBM Cloud Private プラットフォームへの完全なアクセス権限があります。

次のアクションはクラスター管理者のみが完了できます:

LDAP ディレクトリーへの接続ユーザーの追加とユーザーへの IAM 役割の割り当てすべての名前空間でのワークロード、インフラスト

ラクチャー、アプリケーションの管理


クォータの割り当て

ポッド・セキュリティー・ポリシーの追加

内部 Helm リポジトリーの追加内部 Helm リポジトリーの削除内部 Helm リポジトリーへの Helm チャートの追加内部 Helm リポジトリーからの Helm チャートの削除

内部および外部 Helm リポジトリーの同期

ポッドのセキュリティー・ポリシーの追加について詳しくは、ポッドのセキュリティー・ポリシーの作成を参照して

ください。

IAM 役割とアクション

ユーザーまたはユーザー・グループを追加するときに、IAM 役割をこれらに割り当てます。各ユーザーまたはユーザー・グループは、チーム内で 1 つの役割のみ持つことができます。ただし、ユーザーを個別に追加し、かつチームのグループのメンバーとして追加する場合は、ユーザーはチーム内で複数の役割を持つ場合があります。その場合は、ユーザーは、割り当てられた最⾼の役割に基づいて⾏動することができます。例えば、ユーザーを管理者として追加して、そのユーザーのグループにビューアーの役割を割り当てると、ユーザーはチームの管理者の役割を果たすことができます。

ユーザーまたはユーザー・グループは、複数のチームのメンバーになることができ、各チームで異なる役割を持つこ

とができます。

IAM 役割は、ユーザーがチーム・リソースで実⾏できるアクションを定義します。

IBM Cloud Private は、次の IAM 役割をサポートします。

注: チーム、ユーザー、および役割を管理できるのは、クラスター管理者と管理者のみです。管理者は、いかなるユーザーにもグループにもクラスター管理者役割を割り当てることはできません。

表 2. IAM 役割とアクション役割説明アクション

ビュ

ーア

ー

読み取り専⽤権限があります。ユーザーがチームに追加されるときに、ビューアー

役割はデフォルトでユーザーに割り当て

られます。

ビューアーは、チーム・リソースに関する情報を表⽰できます。ビューアーは、以下の management console ページを表⽰できません。

ダッシュボード

秘密

ノード

認証


チーム


役割説明アクション

エデ

ィタ

ー

読み取り権限と編集権限があります。エディターはチーム・リソースを表⽰、編集できます。エディターは、以下の management console ページを表⽰できません。


ノード

認証


チーム

オペ

レー

ター

読み取り、編集、作成権限があります。オペレーターはリソースを表⽰、編集、作成できます。オペレーターは、以下の management console ページを表⽰できません。


ノード

認証


チーム

管理

者

追加、更新、表⽰、削除権限があります。管理者は次のアクションを実⾏できます。

チームの作成

他のチームへのリソースの割り当て

注: 管理者は、クラスター管理者によってチームに割り当てられたリソースにアクセスできます。管理者は、そのようなリソースを⾃⾝が管理者となっているその他のチームに割

り当てることができます。

チーム⽤のリソースの作成

注: 管理者は、チーム⽤のリソースを作成できます。彼らは、そのようなリソースを⾃⾝が管理者となっているその他

のチームに割り当てることができます。

⾃⾝のチームのユーザー、グループ、および役割の管理

注: 管理者は、いかなるユーザーにもグループにもクラスター管理者役割を割り当てることはできません。

チームのリソースの読み取り、更新、および削除

管理者は、以下の management console ページを表⽰できません。


ノード


クラ

スタ

ー管

理者

IBM Cloud Private プラットフォームへの完全なアクセス権限があります。

クラスター管理者役割とアクションを参照してください。

注: ビューアーおよびエディターは、いずれの IBM Cloud Private management console ページでもログを表⽰できません。

カタログおよび Helm リソースの RBAC


表 3. IAM 役割に基づいた許可された Helm リポジトリーのアクションアクション管理者オペレーターエディタービューアー

内部 Helm リポジトリーの追加内部および外部 Helm リポジトリーの同期内部 Helm リポジトリーの削除内部 Helm リポジトリーへの Helm チャートの追加 X

内部 Helm リポジトリーからの Helm チャートの削除 X

Helm チャートの構成 X X X

Helm リリースの削除 X X X

Kubernetes リソースの RBAC

ユーザーに割り当てる IAM 役割は、チームに割り当てられる Kubernetes リソースでユーザーが実⾏できるアクションの定義もします。例えば、ユーザー 1 がチーム 1 のオペレーターで、チーム 1 に名前空間 1 のリソースがある場合、ユーザー 1 は名前空間 1 の情報を表⽰および更新することができます。ユーザー 1 は名前空間 1 にポッドのようなリソースを作成することもできます。チーム 1 からユーザー 1 を削除すると、チーム 1 のリソースにバインドされているユーザー 1 の役割が削除されます。ユーザー 1 が同じ名前空間を持つ別のチーム (例えばチーム 2) の⼀部である場合、チーム 2 の名前空間にバインドされているユーザー 1 の役割は、ユーザー 1 をチーム 1 から削除しても影響を受けません。

表 4. IAM 役割に基づいた許可されたアクションアクション管理者オペレーターエディタービューアー

get X X X Xlist X X X Xwatch X X X Xupdate X X Xpatch X X Xcreate X Xdelete Xdeletecollection X

表⽰編集操作管理

バインディングバインディングバインディングバインディング

clusterrolebindings.rbac.authorization.k8s.io

clusterservicebrokers.servicecatalog.k8s.io (表⽰権限のみ)




clusterserviceclasses.servicecatalog.k8s.io (表⽰権限のみ)




clusterserviceplans.servicecatalog.k8s.io (表⽰権限のみ)




configmaps configmaps configmaps configmapscronjobs.batch cronjobs.batch cronjobs.batch cronjobs.batchdaemonsets.apps daemonsets.apps daemonsets.apps daemonsets.extensionsdaemonsets.extensions daemonsets.extensions daemonsets.extensions deployments.appsdeployments.apps deployments.apps deployments.apps deployments.extensionsdeployments.extensions deployments.extensions deployments.extensions deployments.apps/rollback



deployments.apps/scale deployments.apps/rollback deployments.apps/rollback deployments.extensions/rollback

deployments.extensions/scale

deployments.extensions/rollback

deployments.extensions/rollback

deployments.apps/scale

endpoints deployments.apps/scale deployments.apps/scale deployments.extensions/scale

events deployments.extensions/scale

deployments.extensions/scale

endpoints

horizontalpodautoscalers.autoscaling

endpoints endpoints events

images.icp.ibm.com events events horizontalpodautoscalers.autoscaling

ingresses.extensions horizontalpodautoscalers.autoscaling

horizontalpodautoscalers.autoscaling

images.icp.ibm.com

jobs.batch images.icp.ibm.com images.icp.ibm.com ingresses.extensionslimitranges ingresses.extensions ingresses.extensions jobs.batchnamespaces jobs.batch jobs.batch limitrangesnamespaces/status limitranges limitranges localsubjectaccessreviews.a

uthorization.k8s.ionetworkpolicies.extensions namespaces namespaces namespacesnetworkpolicies.networking.k8s.io

namespaces/status namespaces/status namespaces/status

persistentvolumeclaims networkpolicies.extensions networkpolicies.extensions networkpolicies.extensionspods networkpolicies.networking

.k8s.ionetworkpolicies.networking.k8s.io

networkpolicies.networking.k8s.io

pods/log persistentvolumeclaims persistentvolumeclaims persistentvolumeclaimspods/status pods pods poddisruptionbudgets.policyreplicasets.apps pods/attach pods/attach podsreplicasets.extensions pods/exec pods/exec pods/attachreplicasets.apps/scale pods/log pods/log pods/execreplicasets.extensions/scale

pods/portforward pods/portforward pods/log

replicationcontrollers pods/proxy pods/proxy pods/portforwardreplicationcontrollers/scale pods/status pods/status pods/proxyreplicationcontrollers.extensions/scale

replicasets.apps replicasets.apps pods/status

replicationcontrollers/status

replicasets.extensions replicasets.extensions replicasets.extensions

resourcequotas replicasets.apps/scale replicasets.apps/scale replicasets.extensions/scaleresourcequotas/status replicasets.extensions/scal

ereplicasets.extensions/scale

replicationcontrollers

serviceaccounts replicationcontrollers replicationcontrollers replicationcontrollers/scaleservicebindings.servicecatalog.k8s.io

replicationcontrollers/scale replicationcontrollers/scale replicationcontrollers.extensions/scale

servicebindings.servicecatalog.k8s.io/status

replicationcontrollers.extensions/scale

replicationcontrollers.extensions/scale


serviceinstances.servicecatalog.k8s.io



resourcequotas



serviceinstances.servicecatalog.k8s.io/status

resourcequotas resourcequotas resourcequotas/status

services resourcequotas/status resourcequotas/status rolebindings.rbac.authorization.k8s.io

statefulsets.apps secrets secrets roles.rbac.authorization.k8s.io

serviceaccounts serviceaccounts scheduledjobs.batchservicebindings.servicecatalog.k8s.io

servicebindings.servicecatalog.k8s.io

secrets



serviceaccounts



servicebindings.servicecatalog.k8s.io




services services serviceinstances.servicecatalog.k8s.io

services/proxy services/proxy serviceinstances.servicecatalog.k8s.io/status

statefulsets.apps statefulsets.apps servicesservices/proxystatefulsets.apps

LDAP 接続の構成

IBM® Cloud Private クラスターの LDAP (Lightweight Directory Access Protocol) 接続を構成します。

LDAP ディレクトリーがある場合、これを IBM Cloud Private クラスターに接続することができます。 LDAP ディレクトリーからユーザーをインポートして、クラスターに追加することができます。

以下の LDAP タイプがサポートされています。

IBM Tivoli Directory ServerIBM Lotus DominoIBM SecureWay Directory ServerNovell eDirectorySun Java™ System Directory ServerNetscape Directory ServerMicrosoft Active Directoryカスタム


LDAP over SSL の構成

SSL (Secure Sockets Layer) を使⽤することで LDAP 接続を保護することができます。 LDAP over SSL (LDAPS) ディレクトリーと接続するために、IBM Cloud Private クラスターを準備する必要があります。

始める前に、LDAPS ディレクトリーのセットアップに使⽤したパブリックまたはプライベート SSL 証明書をインポートする必要があります。


SSL 証明書の取得

LDAP サーバーの SSL 証明書がある場合は、SSL 証明書のエンコードに進んでください。

LDAP サーバーの SSL 証明書がない場合は、以下のステップを実⾏して SSL 証明書を取得してください。

注 : これらのコマンドを実⾏するには、ldapsearch プログラムが必要です。これをインストールするには、Ubuntu では apt install ldap-utils を実⾏し、Red Hat Enterprise Linux (RHEL) では yum install openldap-clients を実⾏します。

1. SSL 証明書が /etc/openldap/cacerts ディレクトリーにないことを確認します。

2. 以下の ldapsearch コマンドを実⾏して、証明書名を取得します。

ldapsearch -H <LDAP server URL> -d 1 -b <searchbase> -D "" -s base "(<filter>)"


LDAP サーバー URL は、ご使⽤の LDAP ディレクトリーのドメイン・ネームまたは IP アドレス、およびポートです。フォーマットは、ldaps://<LDAP server domain name or IP address>:<port> です。-d はデバッグ・レベルです。-b は検索ベースです。-D はバインド DN です。このパラメーターはオプションです。-s は検索の範囲です。filter は LDAP フィルターです。デフォルト・フィルターは (objectClass=*) です。


$ ldapsearch -H ldaps://corp.example.com:636 -d 1 -b o=example.com -D "" -s base "(objectclass=*)" ldap_url_parse_ext(ldaps://corp.example.com:636) ldap_create ldap_url_parse_ext(ldaps://corp.example.com:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP corp.example.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 9.17.186.253:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS: certdb config: configDir='/etc/openldap' tokenDescription='ldap(0)' certPrefix='cacerts' keyPrefix='cacerts' flags=readOnly TLS: cannot open certdb '/etc/openldap', error -8018:Unknown PKCS #11 error. TLS: could not get info about the CA certificate directory /etc/openldap/cacerts - error -5950:File not found. TLS: certificate [CN=DigiCert Global Root G2,OU=www.digicert.com,O=DigiCert Inc,C=US] is not valid - error -8172:Peer's certificate issuer has been marked as not trusted by the user.. TLS: error: connect - force handshake failure: errno 2 - moznss error -8172 TLS: can't connect: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

証明書情報は、この出⼒の TLS: certificate [CN=DigiCert Global Root G2,OU=www.digicert.com,O=DigiCert Inc,C=US] is not valid - error -8172:Peer's certificate issuer has been marked as not trusted by the user.. のセクションにあります。


3. Web ブラウザーで証明書を⾒つけ、PEM 形式のファイルにエクスポートし、拡張⼦ .crt を付けて保存します。

4. .crt ファイルを IBM Cloud Private クラスターのマスター・ノードにコピーします。

次に、SSL 証明書のエンコードに進みます。

SSL 証明書のエンコード

以下の⼿順を実⾏して base64 で証明書をエンコードします。

1. IBM Cloud Private クラスターのマスター・ノードにログオンします。

2. base64 で証明書をエンコードします。

cat <LDAPS SSL certificate name>.crt | base64 -w 0


LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUdDRENDQS9DZ 0F3SUJBZ0lRS3k1dTZ0bDFObXdVaW03Ym8zeU1CekFOQmdrcWhraUc5 ... lDOHg0OU9oZ1E9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0KDQo=

LDAPS 接続できるようにクラスターを準備します。

管理コンソールまたはコマンド・ライン・インターフェース (CLI) を使⽤して、クラスターを準備できます。

管理コンソールを使⽤している場合は、以下の⼿順に従ってください。

1. クラスター管理者として management console にログオンします。2. ナビゲーション・メニューから、「構成」 > 「秘密」をクリックします。3. platform-auth-ldaps-ca-cert を⾒つけて、「アクション」 > 「編集」の順にクリックします。「秘密の編集 (Edit Secret)」ウィンドウが表⽰されます。

4. 以下のセクションで、Base64 証明書を貼り付けます。

"data": { "certificate": "" },

更新されたセクションは、以下のテキストのようになります。

"data": { "certificate": "LS0tLS1<very_long_base64_string>ASDFASDo=" },

5. 「送信」をクリックします。6. ナビゲーション・メニューから、「ワークロード」 > 「DaemonSet」をクリックします。7. auth-idp を⾒つけて、「アクション」 > 「編集」の順にクリックします。「DaemonSet の編集 (Edit

DaemonSet)」ウィンドウが表⽰されます。8. 変更を加えずに「送信 (Submit)」をクリックします。この⼿順では、auth-idp ポッドを再ロードします。

CLI を使⽤している場合は、以下の⼿順に従ってください。

1. マスター・ノードのコマンド・ライン・インターフェース (CLI) にアクセスします。以下の⼿順を実⾏するには、Kubernetes コマンド・ライン・ツールである kubectl が必要です。 kubectl のインストールと構成について詳しくは、kubectl CLI を使⽤して IBM® Cloud Private クラスターにアクセスするを参照してください。


2. LDAPS CA 証明書秘密をファイルにコピーします。

kubectl get secret platform-auth-ldaps-ca-cert -o yaml -n kube-system > platform-auth-ldaps-ca-cert-secret.yaml

3. base64 証明書をコピーして platform-auth-ldaps-ca-cert-secret.yaml ファイルに貼り付けます。

4. 変更を適⽤します。

kubectl apply -f platform-auth-ldaps-ca-cert-secret.yaml

kubectl apply -f <installation directory>/cluster/cfc-components/platform-auth/platform-auth-idp-ds.yaml

次に、「LDAP ディレクトリーへの接続」セクションの⼿順を実⾏します。

LDAP ディレクトリーへの接続

以下のステップに従って LDAP 接続をセットアップします。

1. 管理者としてログオンします。2. ナビゲーション・メニューで「管理」 > 「認証」の順にクリックします。3. 「接続のセットアップ (Set up the connection)」をクリックします。「LDAP の接続 (LDAP connection)」ページが表⽰されます。

4. 以下の詳細を⼊⼒し、LDAP 接続をセットアップします。

LDAP 接続

接続情報を⼊⼒します。

名前: LDAP 接続の固有の名前。形式: 1 から 50 個の英数字; 許可される特殊⽂字: - _タイプ: 接続している LDAP ディレクトリーのタイプ。リストから選択します。形式: 1 から 255 個の英数字; 空⽩⽂字が許可されます。許可される特殊⽂字はありません。

URL: LDAP ディレクトリーのドメイン・ネームまたは IP アドレス、および LDAP ポート番号。ドメイン・ネームは、ldap:// で開始する必要があります。サンプル URL: ldap://corpldap.abc.com:389 または ldap://10.10.10.1:389。

LDAPS の場合、ドメイン・ネームは ldaps:// で始まる必要があります。サンプル URL: ldaps://corpldap.abc.com:636 または ldaps://10.10.10.1:636。

注: ホスト名を使⽤して LDAPS ディレクトリーに接続できない場合は、LDAPS ディレクトリーのホスト名と IP アドレスを platform-auth-service コンテナーの /etc/hosts ファイルに追加します。以下のステップに従って、ファイルを更新します。

1. 認証サービス・ポッドの ID を取得します。

kubectl -n kube-system get pods | grep auth-idp

2. platform-auth-service コンテナーの /etc/hosts ファイルを更新します。

kubectl -n kube-system exec -it <auth-service-pod-ID> -c platform-auth-service -- /bin/bash -c 'echo "<LDAPS server IP address> <LDAPS server host name>" >> /etc/hosts'

LDAP 認証

認証情報を⼊⼒します。


ベース DN: 検索ベースの識別名。例: dc=abc,dc=com。形式: 1 から 255 個の英数字; 許可される特殊⽂字: = . , -バインド DN: ベース DN の検索を許可されたユーザー。例: cn=admin,dc=abc,dc=com。このパラメーターはオプションです。バインド DN パラメーターにユーザーが指定されていない場合、LDAP 接続は認証なしで確⽴されます。形式: 0 から 255 個の英数字; 空⽩⽂字が許可されます。許可される特殊⽂字: = . , -

管理者パスワード: バインド DN に記載されているユーザーのパスワード。このパラメーターは、バインド DN にユーザーを指定しない場合は必須ではありません。最⼤で 255 ⽂字可能です。

「テスト接続 (Test connection)」をクリックして LDAP 接続の詳細が有効かどうかを確認することができます。

LDAP フィルター

検索フィルターに関する情報を⼊⼒します。 LDAP タイプごとのデフォルトの LDAP フィルターについては、LDAP タイプごとのデフォルト LDAP フィルターを参照してください。

グループ・フィルター: グループを検索するためのフィルター節。形式: 1 から 255 個の英数字; 許可される特殊⽂字: 空⽩⽂字、= ; . , & % () {} <> |グループ ID マップ: グループ名を LDAP エントリーにマップするフィルター。形式: 1 から 255 個の英数字; 許可される特殊⽂字: 空⽩⽂字、* : = ; . , & % () {}グループ・メンバー ID マップ: ユーザーをグループにマップするフィルター。形式: 1 から 255 個の英数字; 許可される特殊⽂字: 空⽩⽂字、* : = ; . , & % () {}ユーザー・フィルター: ユーザーを検索するためのフィルター節。形式: 1 から 255 個の英数字; 許可される特殊⽂字: 空⽩⽂字、= ; . , & % () {} <> |ユーザー ID マップ: ユーザー名を LDAP エントリーにマップするフィルター。形式: 1 から 255 個の英数字; 許可される特殊⽂字: 空⽩⽂字、* : = ; . , & % () {}

5. 「接続」をクリックします。

これで IBM Cloud Private クラスターは LDAP ディレクトリーと接続されます。

次に、LDAP ユーザーとユーザー・グループを IBM Cloud Private クラスターに追加することができます。ユーザーの追加について詳しくは、ユーザーをチームに追加するおよびグループをチームに追加するを参照してください。

LDAP タイプごとのデフォルト LDAP フィルター

表 1. デフォルトの IBM Tivoli Directory Server LDAP フィルターのリスト

属性名データ・タイプデフォルト値

groupFilter string (&(cn=%v)(objectclass=groupOfUniqueNames))groupIdMap string *:cngroupMemberIdMap string groupOfUniqueNames:uniquememberuserFilter string (&(emailAddress=%v)(objectclass=person))userIdMap string *:uid

表 2. デフォルトのカスタム・サーバー LDAP フィルターのリスト属性名データ・タイプデフォルト値

groupFilter string (&(cn=%v)(objectclass=groupOfUniqueNames))groupIdMap string *:cngroupMemberIdMap string groupOfUniqueNames:uniquememberuserFilter string (&(uid=%v)(objectclass=ePerson))



userIdMap string *:uid

表 3. デフォルトの Microsoft Active Directory LDAP フィルターのリスト


groupFilter string (&(cn=%v)(objectclass=group))groupIdMap string *:cngroupMemberIdMap string memberOf:memberuserFilter string (&(sAMAccountName=%v)(objectclass=user))userIdMap string user:sAMAccountName

表 4. デフォルトの IBM Lotus Domino LDAP フィルターのリスト属性名データ・タイプデフォルト値

groupFilter string (&(cn=%v)(objectclass=dominoGroup))groupIdMap string *:cngroupMemberIdMap string dominoGroup:memberuserFilter string (&(uid=%v)(objectclass=Person))userIdMap string person:uid

表 5. デフォルトの IBM SecureWay Directory Server LDAP フィルターのリスト

属性名データ・タイ

プデフォルト値

groupFilter string (&(cn=%v)((objectclass=groupOfNames)(objectclass=groupOfUniqueNames)))groupIdMap string *:cngroupMemberIdMap string groupOfNames:member;groupOfUniqueNames:uniqueMemberuserFilter string (&(uid=%v)(objectclass=ePerson))userIdMap string *:uid

表 6. デフォルトの Sun Java System Directory Server LDAP フィルターのリスト


groupFilter string (&(cn=%v)(objectclass=ldapsubentry))groupIdMap string *:cngroupMemberIdMap string nsRole:nsRoleuserFilter string (&(uid=%v)(objectclass=inetOrgPerson))userIdMap string inetOrgPerson:uid

表 7. デフォルトの Netscape Directory Server LDAP フィルターのリスト

属性名データ・タイ

プデフォルト値

groupFilter string (&(cn=%v)((objectclass=groupOfNames)(objectclass=groupOfUniqueNames)))groupIdMap string *:cngroupMemberIdMap string groupOfNames:member;groupOfUniqueNames:uniqueMemberuserFilter string (&(uid=%v)(objectclass=inetOrgPerson))userIdMap string inetOrgPerson:uid

表 8. デフォルトの Novell eDirectory LDAP フィルターのリスト属性名データ・タイプデフォルト値

groupFilter string (&(cn=%v)(objectclass=groupOfNames))groupIdMap string *:cngroupMemberIdMap string groupOfNames:member



userFilter string (&(cn=%v)(objectclass=Person))userIdMap string person:cn

Helm リポジトリーの管理

内部 Helm リポジトリーは、Helm パッケージ (チャート) の保管に使⽤されます。

Helm リポジトリーの追加Helm リポジトリーの同期Helm リポジトリーの削除

Helm リポジトリーの追加

リポジトリーを追加します。


1. ナビゲーション・メニューで、「管理 (Manage)」>「Helm リポジトリー (Helm Repositories)」をクリックします。デフォルト・リポジトリーが使⽤可能です。

2. 「リポジトリーの追加 (Add Repository)」をクリックします。

3. リポジトリーの詳細を⼊⼒します。

名前 (Name): 固有のリポジトリー名を⼊⼒します。URL: index.yaml ファイルの GitHub リポジトリー URL を⼊⼒します。 http と https の両⽅のリポジトリーに接続できます。 Helm Kubernetes チャート・リポジトリーに接続するには、https://kubernetes-charts.storage.googleapis.com/ と⼊⼒します。ソース URL (Source URL): チャートの GitHub URL。このフィールドは必須ではありません。

4. 「追加」をクリックします。 Catalog でチャートを⾒つけることができます。

Helm リポジトリーの同期

内部 Helm リポジトリーを、外部でホストされている同⼀の Helm リポジトリーと同期します。


1. ナビゲーション・メニューで、「管理 (Manage)」>「Helm リポジトリー (Helm Repositories)」をクリックします。デフォルト・リポジトリーが使⽤可能です。

2. 「リポジトリーの同期 (Synch repositories)」をクリックします。新規チャートが外部リポジトリーからダウンロードされた場合、Catalog でその新規チャートが表⽰されるようになります。

Helm リポジトリーの削除

リポジトリー接続を削除します。

デフォルト・リポジトリーである ibm-charts および local-charts という名前は予約されています。これらのデフォルト・リポジトリーを削除した場合、これらの予約名を使⽤してそれらを再び追加することはできません。デフォルト・リポジトリーを復元するには、同じ URL を使⽤する必要がありますが、予約済みのものとは異なる名前を指定する必要があります。



1. ナビゲーション・メニューで、「管理 (Manage)」>「Helm リポジトリー (Helm Repositories)」をクリックします。

2. 削除するリポジトリーと同じ⾏で、「アクション (Action)」>「削除 (Delete)」を選択します。3. 「削除 (Delete)」をクリックします。

名前空間

ユーザーは、名前空間とよばれる組織単位に割り当てられます。

名前空間は、テナントまたはアカウントとも呼ばれます。 IBM® Cloud Private では、ユーザーはチームに割り当てられます。複数の名前空間をチームに割り当てることができます。チームのユーザーは、チームの名前空間のメンバーです。

IBM Cloud Private 名前空間は、Kubernetes の単⼀の名前空間に対応します。単⼀の名前空間に作成されるすべてのデプロイメント、ポッド、およびボリュームは、同⼀の Kubernetes 名前空間に属します。

デフォルトの名前空間は、IBM Cloud Private をインストールすると使⽤可能になります。デフォルトの名前空間は、クラスター内のすべてのスーパー管理者に割り当てられます。デフォルトの名前空間は削除してはなりません。



アプリケーションは、IBM® Cloud Private クラスターの名前空間の下に作成またはデプロイされる必要があります。名前空間は、ユーザーとアプリケーションを編成するために必要です。


1. クラスター管理者としてログオンします。2. ナビゲーション・メニューで「管理」 > 「名前空間」の順にクリックします。3. 「名前空間の作成」をクリックします。4. 名前空間に名前を⼊⼒します。名前空間の名前は、以下の名前空間の Kubernetes 要件に⼀致する必要があります。

固有である。重複する名前空間名を使⽤することはできません。⻑さが 63 ⽂字を超えない。⼩⽂字、数字、ダッシュ記号 (-) のみを含む。


デプロイメントが完了したら、新規の名前空間が名前空間ページに表⽰されます。

ラベルの追加

ラベルを使⽤して、名前空間セレクターに基づいたネットワーク・ポリシーを作成することができます。 IBM CloudPrivate management console から名前空間のラベルを追加することはできません。名前空間ラベルを追加するには、Kubernetes CLI を使⽤してください。

1. kubectl コマンド・ライン・インターフェースをインストールします。『kubectl CLI からのクラスターへのアクセス』を参照してください。

2. すべての名前空間のリストを表⽰します。

kubectl get namespaces



NAME STATUS AGE default Active 6h dev Active 2h kube-system Active 6h qa Active 2h

3. ラベルを追加します。

kubectl label namespaces dev team=dev

名前空間の削除

使⽤されていない名前空間を削除します。


1. クラスター管理者としてログオンします。2. ナビゲーション・メニューで「管理」 > 「名前空間」の順にクリックします。3. 削除する名前空間ごとに、「アクション」 > 「削除」を選択します。確認のダイアログ・ボックスが表⽰されます。

4. 「名前空間の削除」をクリックします。


クラスター内で実⾏されているポッドおよびコンテナーを保護する⽅法を説明します。



ポッドおよびコンテナーのセキュリティー・ポリシーを作成します。


て、クラスター・レベルでの制御をセットアップします。

IBM® Cloud Private で使⽤可能なポッド・セキュリティー・ポリシーには、privileged と default の 2 つがあります。

privileged ポリシーは、super レベル権限を持つスーパー管理者に割り当てられます。default ポリシーは、クラスター内部の限定された権限を持つ通常の (システム管理者ではない) ユーザーに割り当てられます。

通常、⾮クラスター管理者は、特権ポッドの作成、ホスト・ネットワークやホスト・ポートの使⽤、およびコンテナ

ー内部での追加の Linux 機能の使⽤を⾏うことはできません。ただし、スーパー管理者は、新規 PodSecurityPolicyを作成することによって、特定の名前空間またはテナントに対して追加の権限を提供できます。

ポッド・セキュリティー・ポリシーのリストを表⽰するには、ナビゲーション・メニューから「管理」 > 「ポッド・セキュリティー」をクリックします。「ポッド・セキュリティー」ページに、事前定義済みの privileged ポリシーおよび default ポリシーが表⽰されます。スーパー管理者は、これら 2 つのポリシーを必要に応じて更新することができますが、削除することはできず、再割り当てすることもできません。



「ポッド・セキュリティー・ポリシーの作成」ウィンドウを使⽤した PodSecurityPolicyの作成

1. ナビゲーション・メニューから、「管理」 > 「ポッド・セキュリティー」をクリックします。

2. 「ポッド・セキュリティー・ポリシーの作成」をクリックします。

3. ポリシー詳細を指定します。以下のパラメーターについては、値の指定が必要です。

「⼀般」タブで、ポリシーの名前を指定します。

必要に応じて、他のすべてのポリシー設定を指定します。ポリシーについて詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/policy/pod-security-policy/ を参照してください。


「リソースの作成」ウィンドウを使⽤した PodSecurityPolicy の作成

1. ダッシュボードから、「リソースの作成」をクリックします。2. YAML ファイルをコピーして「リソースの作成」ダイアログ・ボックスに貼り付けます。 PodSecurityPolicy の作成について詳しくは、https://v1-10.docs.kubernetes.io/docs/concepts/policy/pod-security-policy/#creating-a-pod-security-policy を参照してください。


デプロイメントが完了したら、新規 PodSecurityPolicy が「ポッド・セキュリティー」ページに表⽰されます。

リソース割り当て量の設定

リソース割り当て量を設定して、アプリケーションが要求できる計算リソースおよびストレージ・リソースの合計を

制限します。また、リソース割り当て量を使⽤して、単⼀の名前空間で使⽤可能な、指定されたタイプのオブジェクトの数を限定することもできます。

リソース割り当て量の設定について詳しくは、https://v1-10.docs.kubernetes.io/docs/admin/resourcequota を参照してください。

割り当て量のリストを表⽰するには、ナビゲーション・メニューから「管理」 > 「割り当て量」をクリックします。


「ResourceQuota の作成」ウィンドウを使⽤した割り当て量の作成

1. ナビゲーション・メニューから、「管理」 > 「割り当て量」をクリックします。2. 「ResourceQuota の作成」をクリックします。3. リソース割り当て量の詳細を⼊⼒します。4. 「作成」をクリックします。

「リソースの作成」ウィンドウを使⽤した割り当て量の作成


2. YAML ファイルまたは JSON ファイルをコピーして「リソースの作成」ダイアログ・ボックスに貼り付けます。 YAML ファイルの使⽤による割り当て量の作成について詳しくは、https://v1-


https://v1-10.docs.kubernetes.io/docs/concepts/policy/pod-security-policy/

https://v1-10.docs.kubernetes.io/docs/concepts/policy/pod-security-policy/#creating-a-pod-security-policy

https://v1-10.docs.kubernetes.io/docs/admin/resourcequota

https://v1-10.docs.kubernetes.io/docs/concepts/policy/resource-quotas/#viewing-and-setting-quotas

10.docs.kubernetes.io/docs/concepts/policy/resource-quotas/#viewing-and-setting-quotas を参照してください。

「リソースの作成」ウィンドウから割り当て量を作成するときには、metadata セクションに名前空間を必ず指定してください。

GPU リソース割り当て量の場合、limits.alpha.kubernetes.io/nvidia-gpu パラメーターを使⽤することによって、特定の名前空間のリソース限度を設定できます。

以下のサンプル・コードは、myspace 名前空間に対して、GPU 割り当て量限度として 2 GPU を設定しています。

apiVersion: v1 kind: ResourceQuota metadata: name: compute-resources namespace: myspace spec: hard: requests.cpu: "1" requests.memory: 1Gi limits.cpu: "2" limits.memory: 2Gi limits.alpha.kubernetes.io/nvidia-gpu: "2"


デプロイメントが完了したら、新規割り当て量が「割り当て量」ページに表⽰されます。

IBM® Cloud Private CLI による Kubernetes Secret パスワードの管理

Secret のセットに対して IBM Cloud Private CLI を使⽤することで、パスワード要求の強制、パスワードの変更、および必要なポッドやコンテナーの再始動を実⾏できます。

前提条件


Kubernetes コマンド・ライン・ツール kubectl をインストールし、セットアップします。 kubectl CLI を使⽤した IBM® Cloud Private クラスターへのアクセスを参照してください。

IBM Cloud CLI をインストールし、セットアップします。まず、CLI およびツールの概要を参照してください。

次のコマンドを実⾏して IBM Cloud Private CLI をダウンロードします。

wget https://<cluster-domain-name>:8443/api/cli/icp-linux-amd64 --no-check-certificate

IBM Cloud Private CLI プラグインをインストールします。まず、IBM Cloud Private CLI のインストールを参照してください。

トークンを⽣成するために IBM Cloud Private にログインします。パスワードを求めるプロンプトがコマンドから出されます。



https://v1-10.docs.kubernetes.io/docs/concepts/policy/resource-quotas/#viewing-and-setting-quotas


パスワードの管理

Kubernetes Secret 内に保管されている複数の IBM Cloud Private パスワードを変更できます。 IBM Cloud Private CLIには、パスワードを変更し、そのパスワードを使⽤するサービスを再始動するためのコマンドがあります。

1. 以下の Secret のリストから、パスワードを変更するものを選択します。

platform-auth-idp-credentials: クラスター管理者権限資格情報icp-mongodb-admin: Mongo を使⽤するサービスの内部パスワードplatform-mariadb-credentials: MariaDB を使⽤するサービスの内部パスワードplatform-oidc-credentials: 認証サービスの内部パスワード

2. 変更する Secret に応じたコマンドを実⾏します。パスワード値を求めるプロンプトと、変更を確認するプロンプトが出されます。

platform-auth-idp-credentials

bx pr update-secret mycluster kube-system platform-auth-idp-credentials -d admin_password

icp-mongodb-admin

bx pr update-secret mycluster kube-system icp-mongodb-admin -d password

platform-mariadb-credentials

bx pr update-secret mycluster kube-system platform-mariadb-credentials -d OAUTH2DB_PASSWORD

platform-oidc-credentials

bx pr update-secret mycluster kube-system platform-oidc-credentials -d WLP_CLIENT_SECRET

オプション: パスワード規則の管理

パスワード規則は、オプションの正規表現 (regex) であり、名前空間内の管理対象パスワード値を設定および検証するために使⽤されます。 update-secret コマンドは、Secret 内の値を変更する前にパスワード規則をチェックします。このコマンドは、Secret が含まれる名前空間に対して規則が存在するかどうかを検証するとともに、任意の⼤/⼩⽂字の組み合わせの pass または pwd が Secret データ・エレメント名変更に含まれているかどうかを検証します。

注: コマンド・ラインから以下の regex 式を使⽤できます。式は単⼀引⽤符で囲んでください。

表 1. Regex 式の規則のリスト規則 Regex

最⼩⻑ 10 ^.{10,}

最⼤⻑ 10 ^.{0,10}$

⻑さ範囲 ^.{10,20}$

⼩⽂字が必要 .*[a-z].*

⼤⽂字が必要 .*[A-Z].*

数字が必要 .*[0-9].*

特殊⽂字が必要 .*[!@#\$%\^&\*].*

1. 以下のコマンドを使⽤して、パスワード規則を設定します。

bx pr password-rule-set <cluster> <namespace> <rule_name> <rule_regex> <rule_desc>


以下の Regex 式の例を参照してください。

bx pr password-rule-set mycluster default min_10 '^.{10,}' "minimum length of 10" OK

2. パスワード規則をリストします。

bx pr password-rules <cluster> <namespace>

以下の例を参照してください。

bx pr password-rules mycluster default Name Description Regex min10 minimum length 10 ^.{10,} OK

3. パスワード規則を削除します。

bx pr password-rule-rm <cluster> <namespace> <rule_name>

以下の例を参照してください。

bx pr password-rule-rm mycluster default min_10 OK

チーム

チームは、ユーザーに役割を割り当てて、リソースへのアクセスを管理するために必要です。

チームの作成チームへのユーザーの追加チームへのグループの追加チームへのリソースの追加チームからのユーザーの削除チームからのグループの削除チームからのリソースの削除チームの削除

チームの作成

チームを作成します。

チームを作成して、ユーザー、ユーザー・グループ、およびリソースをチームに追加することができます。チーム内のすべてのユーザーには、チームのリソースへのアクセス権限があります。ユーザー、ユーザー・グループ、またはリソースは、複数のチームに割り当てることができます。


チームを作成するには、以下の⼿順を実⾏します。

1. クラスター管理者としてログオンします。2. ナビゲーション・メニューで「管理」 > 「チーム」をクリックします。3. 「チームの作成」をクリックします。「チームの作成」ダイアログ・ボックスが表⽰されます。4. 「チーム名 (Team name)」フィールドにチームの名前を⼊⼒します。形式: 1 から 50 個の英数字; 空⽩⽂字が許可されます。許可される特殊⽂字: - _

5. (オプション) ユーザーまたはユーザー・グループをチームに追加することができます。


1. 個々のユーザーまたはユーザー・グループを名前で検索します。2. 追加するユーザーまたはユーザー・グループを選択します。3. ユーザーまたはユーザー・グループの役割を選択します。グループ内のすべてのメンバーは、選択した同じ役割に割り当てられます。 IBM® Cloud Private での役割について詳しくは、役割ベースのアクセス制御を参照してください。


次に、ユーザー、ユーザー・グループ、およびリソースをチームに割り当てます。

ユーザーのチームへの割り当てについては、ユーザーをチームに追加するを参照してください。

ユーザー・グループのチームへの割り当てについては、グループをチームに追加するを参照してください。

リソースのチームへの割り当てについては、チームへのリソースの割り当てを参照してください。

チームへのユーザーの追加

ユーザーをチームに追加します。

LDAP 接続は、ユーザーをチームに追加する前にセットアップする必要があります。 LDAP 接続のセットアップについて詳しくは、LDAP 認証の構成を参照してください。

ユーザーをチームに追加できるようにするには、その前にチームを作成する必要があります。チームの作成について詳しくは、チームの作成を参照してください。


ユーザーをチームに追加するには、以下の⼿順を実⾏します。

1. 管理者としてログオンします。2. ナビゲーション・メニューで「管理」 > 「チーム」をクリックします。3. チームのリストからチーム名を選択します。4. 「ユーザー」タブを選択します。5. 「ユーザーの追加」を選択します。「ユーザーの追加」ダイアログ・ボックスが表⽰されます。

1. 名前でユーザーを検索します。検索テキストに⼊⼒または変更すると、50 個の結果が表⽰されます。追加するユーザーが表⽰されるまでテキストを⼊⼒します。

2. 追加するユーザーを選択します。3. 各ユーザーの役割を選択します。 IBM Cloud Private の役割について詳しくは、役割ベースのアクセス制御を参照してください。

4. 「追加」をクリックします。

ユーザーがチームに追加されます。

チームへのグループの追加

グループをチームに追加します。

LDAP 接続は、グループをチームに追加する前にセットアップする必要があります。 LDAP 接続のセットアップについて詳しくは、LDAP 認証の構成を参照してください。

グループをチームに追加できるようにするには、その前にチームを作成する必要があります。チームの作成について詳しくは、チームの作成を参照してください。



ユーザー・グループをチームに追加するには、以下の⼿順を実⾏します。

1. 管理者としてログオンします。2. ナビゲーション・メニューで「管理」 > 「チーム」を選択します。3. チームのリストからチーム名を選択します。4. 「グループ」タブを選択します。5. 「グループの追加 (Add group)」を選択します。「グループの追加 (Add group)」ダイアログ・ボックスが表⽰されます。

6. 名前でグループを検索します。7. チームに割り当てるグループを選択します。

8. 各グループの役割を選択します。 IBM® Cloud Private での役割について詳しくは、役割ベースのアクセス制御を参照してください。

注: 役割をグループに割り当てると、グループのすべてのユーザーが同じ役割に割り当てられます。

9. 「保存」を選択します。

グループがチームに追加されます。

チームへのリソースの追加

リソースをチームに追加します。

IBM® Cloud Private クラスターからリソースを追加することができます。チーム・メンバーは、チームに追加されるリソースに対してのみ、アクセス権限があります。

リソースをチームに追加できるようにするには、その前にチームを作成する必要があります。チームの作成について詳しくは、チームの作成を参照してください。


ユーザーをチームに追加するには、以下の⼿順を実⾏します。

1. 管理者としてログオンします。2. ナビゲーション・メニューで「管理」 > 「チーム」をクリックします。3. チームのリストからチーム名を選択します。4. 「リソース」をクリックします。5. 「リソースの追加 (Add resource)」をクリックします。使⽤可能なリソースのリストが表⽰されます。6. 追加するリソースを選択します。7. 「リソースの追加 (Add resource)」をクリックします。

リソースがチームに追加されます。

チームからのユーザーの削除

チームからユーザーを削除します。


チームからユーザーを削除するには、以下の⼿順を実⾏します。

1. 管理者としてログオンします。2. ナビゲーション・メニューで「管理」 > 「チーム」をクリックします。3. チームのリストからチーム名を選択します。


4. 「ユーザー」タブを選択します。5. 削除するユーザーごとに、「アクション」 > 「削除」を選択します。確認のダイアログ・ボックスが表⽰されます。

6. 「ユーザーの削除」をクリックします。

チームからユーザーが削除されます。

チームからのグループの削除

チームからグループを削除します。


チームからグループを削除するには、以下の⼿順を実⾏します。

1. 管理者としてログオンします。2. ナビゲーション・メニューで「管理」 > 「チーム」をクリックします。3. チームのリストからチーム名を選択します。4. 「グループ」タブを選択します。5. 削除するグループごとに、「アクション」 > 「削除」の順にクリックします。確認のダイアログ・ボックスが表⽰されます。

6. 「グループの削除」をクリックします。

チームからグループが削除されます。

チームからのリソースの削除

チームからリソースを削除します。


チームからリソースを削除するには、以下の⼿順を実⾏します。

1. 管理者としてログオンします。2. ナビゲーション・メニューで「管理」 > 「チーム」をクリックします。3. チームのリストからチーム名を選択します。4. 「リソース」タブを選択します。5. 削除するリソースごとに、「アクション」 > 「削除」を選択します。確認のダイアログ・ボックスが表⽰されます。

6. 「リソースの削除 (Remove resource)」をクリックします。

チームからリソースが削除されます。

チームの削除

クラスターからチームを削除します。


クラスターからチームを削除するには、以下の⼿順を実⾏します。

1. 管理者としてログオンします。2. ナビゲーション・メニューで「管理」 > 「チーム」をクリックします。チームのリストが表⽰されます。


3. 削除するチームごとに、「アクション」 > 「削除」を選択します。確認のダイアログ・ボックスが表⽰されます。

4. 「チームの削除」をクリックします。

クラスターからチームが削除されます。

クラスター管理者権限資格情報の変更

デフォルトのクラスター管理者である admin のユーザー名またはパスワードを更新します。


1. IBM® Cloud Private クラスターのマスター・ノードにログオンします。

2. 新規ユーザー名またはパスワードを base64 でエンコードします。末尾の改⾏⽂字 (\n) がストリングに付加されないようにするため、-n オプションを使⽤する必要があります。

echo -n "MyNewUsernameOrPassword" | base64

パスワードを更新すると、出⼒は以下のようなコードになります。

TXlOZXdQYXNzMHdyZA==

ユーザー名を更新すると、出⼒は以下のようなコードになります。

YWRtaW4xMjM0

3. kubectl CLI をセットアップします。 kubectl CLI を使⽤して IBM Cloud Private クラスターにアクセスするを参照してください。

4. kube-system 名前空間に関連付けられる platform-auth-idp-credentials 秘密ファイルを開きます。

kubectl -n kube-system edit secrets platform-auth-idp-credentials


# Please edit the object below. Lines beginning with a '#' will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file will be # reopened with the relevant failures. # apiVersion: v1 data: admin_password: YWRtaW4= admin_role: Q2x1c3RlckFkbWluaXN0cmF0b3I= admin_username: YWRtaW4= kind: Secret metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","data":{"admin_password":"YWRtaW4=","admin_role":"Q2x1c3RlckFkbWluaXN0cmF0b3I=","admin_username":"YWRtaW4="},"kind":"Secret","metadata":{"annotations":{},"name":"platform-auth-idp-credentials","namespace":"kube-system"},"type":"Opaque"} creationTimestamp: 2018-01-31T12:38:28Z name: platform-auth-idp-credentials namespace: kube-system resourceVersion: "1065" selfLink: /api/v1/namespaces/kube-system/secrets/platform-auth-idp-credentials uid: a32e7567-0683-11e8-9c67-005056a85e40 type: Opaque


5. base64 でエンコードされた新規のパスワードまたはユーザー名で、admin_password または admin_username セクションを更新します。

..................... apiVersion: v1 data: admin_password: TXlOZXdQYXNzMHdyZA== admin_username: YWRtaW4xMjM0== kind: Secret .....................

6. 変更を保存します。

7. 認証サービスを再始動します。認証サービスを再始動するために、すべての認証ポッドを強制的に削除することができます。強制削除により、ポッドが再始動します。既存のユーザー・セッションは、ポッドのスケジュールを変更するとリセットされる可能性があります。認証ポッドを削除するには、以下のコマンドを実⾏します。

kubectl -n kube-system delete pods -l k8s-app=auth-idp


pod "auth-idp-mkfxq" deleted

8. クラスター管理者ユーザー名を更新している場合、次のタスクも実⾏する必要があります。

1. 次のコマンドを実⾏して、認証ポッドを削除します。

kubectl -n kube-system delete pods -l k8s-app=auth-pdp


pod "auth-pdp-kvpdp" deleted

2. クラスター役割バインディング・ファイルを更新します。

1. クラスター役割バインディング・ファイルを開いて編集します。

kubectl edit clusterrolebinding oidc-admin-binding


# Please edit the object below. Lines beginning with a '#' will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file will be # reopened with the relevant failures. # apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"oidc-admin-binding","namespace":""},"roleRef":{"apiGroup":"rbac.authorization.k8s.io","kind":"ClusterRole","name":"cluster-admin"},"subjects":[{"apiGroup":"rbac.authorization.k8s.io","kind":"User","name":"https://mycluster.icp:9443/oidc/endpoint/OP#admin"}]} creationTimestamp: 2018-02-13T10:43:08Z name: oidc-admin-binding resourceVersion: "1612" selfLink:


/apis/rbac.authorization.k8s.io/v1/clusterrolebindings/oidc-admin-binding uid: ae410b5a-10aa-11e8-a474-005056a85e40 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: https://mycluster.icp:9443/oidc/endpoint/OP#admin

2. https://mycluster.icp:9443/oidc/endpoint/OP#admin で管理者名を新規の名前に置き換えます。 OP#admin を OP# に変更します。<new admin user name>.

3. ファイルを保存します。

9. 認証サービスが正常に再始動したことを確認します。

auth-idp ポッドの状況を確認します。

kubectl -n kube-system get pods -l k8s-app=auth-idp


NAME READY STATUS RESTARTS AGE auth-idp-4qb42 3/3 Running 0 58s

auth-pdp ポッドの状況を確認します。

kubectl -n kube-system get pods -l k8s-app=auth-pdp


NAME READY STATUS RESTARTS AGE auth-pdp-r2dj5 1/1 Running 0 1m

クラスター・アクセス URL のカスタマイズ

IBM® Cloud Private クラスター management console にログインするために使⽤する Uniform Resource Locator(URL) をカスタマイズします。

サポートされるカスタマイズ形式

以下のカスタマイズ形式がサポートされています。

https://<Public IP>:8443/consolehttps://<Public IP>:8443/console/https://<Private IP>:8443/console/https://<Private IP>:custom-port/console/https://<host name>:8443/consolehttps://<host name>:custom-port/consolehttps://localhost:8443/consolehttps://localhost:<custom port>/consolehttps://<Regex host name>:8443/consolehttps://<Regex IP>:8443/consolehttps://<Regex host name>:<custom port>/consolehttps://<Regex IP>:<custom port>/consolehttps://<Regex host name>:<Regex port>/consolehttps://<Regex IP>:<Regex Port>/console



クラスター・アクセス URL のカスタマイズ

IBM Cloud Private クラスターのブート・ノードで次のタスクを実⾏します。

1. root 権限を持つユーザーとしてブート・ノードにログインします。

2. <installation directory/cluster/cfc-components/oidc-registration/platform-oidc-registration.json ファイルを編集します。ファイル内容は、以下のようなコードになります。

{ "token_endpoint_auth_method":"client_secret_basic", "client_id": "e76eb3d7928e10867a2f4602139f1c52", "client_secret": "d024b44b0768ed9f59762460be655548", "scope":"openid profile email", "grant_types":[ "authorization_code", "client_credentials", "password", "implicit", "refresh_token", "urn:ietf:params:oauth:grant-type:jwt-bearer" ], "response_types":[ "code", "token", "id_token token" ], "application_type":"web", "subject_type":"public", "post_logout_redirect_uris":[ "https://192.168.0.84:8443/console/logout","https://9.37.204.198:8443/console/logout","https://mycluster.icp:8443/console/logout" ], "preauthorized_scope":"openid profile email general", "introspect_tokens":true, "trusted_uri_prefixes":[ "https://192.168.0.84:8443","https://9.37.204.198:8443","https://mycluster.icp:8443" ], "redirect_uris":[ "https://192.168.0.84:8443/auth/liberty/callback","https://9.37.204.198:8443/auth/liberty/callback","https://mycluster.icp:8443/auth/liberty/callback" ] }

1. 次のコード部分を追加します。

"allow_regexp_redirects":"true",

更新されたコードは、以下のテキストのようになります。

{ "token_endpoint_auth_method":"client_secret_basic", "client_id": "e76eb3d7928e10867a2f4602139f1c52", "client_secret": "d024b44b0768ed9f59762460be655548", "scope":"openid profile email", "allow_regexp_redirects":"true", <========== "grant_types":[ "authorization_code", "client_credentials", "password", "implicit", "refresh_token",


"urn:ietf:params:oauth:grant-type:jwt-bearer" ...

2. カスタム URI を "redirect_uris" セクションに追加します。追加できる URI のタイプについては、サポートされるカスタマイズ形式を参照してください。

"<regexp>:https://<custom IP address or host name>:<custom port>/auth/liberty/callback",

ここで、カスタム URI に regex を使⽤している場合のみ、<regexp>: を追加します。

クラスターにアクセスするために使⽤する次のサンプル URI を検討します。

マスター・ノードの IP アドレスと 84 で始まるポートを使⽤します。その場合、"regexp:https://<master node IP address>:84!d!d/auth/liberty/callback"を追加します。

ホスト名 example.abc.com とポート 4002 を使⽤します。その場合、"https://example.abc.com:4002/auth/liberty/callback" を追加します。変数のホスト名と動的ポート割り当てを使⽤します。その場合、"regexp:https://example.[a-z]*.com:[0-9]*/auth/liberty/callback" を追加します。

サンプルのカスタム URI を追加した場合は、更新されたコードは次のようなテキストになります。

... "application_type":"web", "subject_type":"public", "post_logout_redirect_uris":[ "https://192.168.0.84:8443/console/logout","https://9.37.204.198:8443/console/logout","https://mycluster.icp:8443/console/logout" ], "preauthorized_scope":"openid profile email general", "introspect_tokens":true, "trusted_uri_prefixes":[ "https://192.168.0.84:8443","https://9.37.204.198:8443","https://mycluster.icp:8443" ], "redirect_uris":[ "regexp:https://192.168.0.84:84!d!d/auth/liberty/callback", <========== "https://example.abc.com:4002/auth/liberty/callback", <========== "regexp:https://example.[a-z]*.com:[0-9]*/auth/liberty/callback", <========== "https://9.37.204.198:8443/auth/liberty/callback","https://mycluster.icp:8443/auth/liberty/callback" ] }

3. ファイルを保存して終了します。

4. クライアント ID、クライアント秘密鍵、およびアクセス IP を次の変数に保存します。

1. クライアント秘密鍵を保存します。

OAUTH2_CLIENT_REGISTRATION_SECRET=$(kubectl -n kube-system get secret platform-oidc-credentials -o yaml | grep OAUTH2_CLIENT_REGISTRATION_SECRET | awk '{ print $2}' | base64 --decode)

2. クライアント ID を保存します。

WLP_CLIENT_ID=$(kubectl -n kube-system get secret platform-oidc-credentials -o yaml | grep WLP_CLIENT_ID | awk '{ print $2}' | base64 --decode)

3. アクセス IP を保存します。


FIP=<master node IP address>

5. platform-oidc-registration.json ファイルに対して⾏った変更を適⽤します。

curl -kvv -X PUT -u oauthadmin:$OAUTH2_CLIENT_REGISTRATION_SECRET -H "Content-Type: application/json" -d @<installation directory>/cluster/cfc-components/oidc-registration/platform-oidc-registration.json https://$FIP:9443/oidc/endpoint/OP/registration/$WLP_CLIENT_ID

これで、新規の URL で management console にアクセスすることができます。

認証および許可の監査ログ

IBM® Cloud Private での認証および許可の監査ログ。

IBM Cloud Private は、認証および許可の監査ログを⽣成します。

これらのログは、デフォルトで有効になります。ログには、以下のようなデータが保存されます。

表 1. 認証および許可の監査ログ・データフィールド名保存データ説明例

initiator.id アクションのソ

ース

アクションを開始したソースの ID LDAP ID、API 鍵のID

initiator.typeURI

ソースの URI アクションのソースの URI サービス、ユーザー

initiator.credential.type

ID のタイプアクションのソースの ID タイプトークン、API 鍵

target.name アクションのタ

ーゲット

アクションが開始されるエンドポイン

ト

サービス、リソース

target.id ターゲットの

IDサービスまたはリソースの CloudResource Name (CRN) 値

crn:v1:icp:private:platform-service:::core:service:metering-service

target.typeURI ターゲットのURI

アクションが開始されるターゲットの

URIリソース、API 鍵、Secret

action 要求されたアク

ション

イベントをトリガーするアクション create、update、delete、deploy、authenticate

outcome アクションの結

果

success、pending、failure

reason.reasonCode

HTTP 応答コード

結果の応答コード成功の場合は 200

severity 重⼤度レベルイベントの重⼤度レベル critical、normaleventTime タイム・スタン

プ

イベントの時刻、⽇付、およびタイ

ム・ゾーン

2018-04-20 20:15:00.32 +0000 UTC

ディレクトリー、ユーザー、ユーザー・グループ、およびチームに関連したすべての作成、読み取り、更新、および

削除 (CRUD) 操作がログに記録されます。

ログは、マスター・ノード上の以下の場所で⼊⼿できます。

認証ログは、/var/log/audit/platform-identity-mgmt-audit.log ファイルに保存されます。許可ログは、/var/log/audit/platform-identity-provider-audit.log ファイルに保存されます。

ログ・ファイルは、コンテナー内でもアクセス可能です。

認証ログは、/opt/ibm/identity-mgmt/logs/audit.log ファイルに保存されます。


許可ログは、/opt/ibm/identity-provider/logs/audit.log ファイルに保存されます。

任意のセキュリティー情報イベント管理 (SIEM) ツールを使⽤して、これらのログを表⽰できます。

フィーチャー・サービス

IBM® Cloud Private には、いくつかのフィーチャー・サービスが含まれています。

バンドルされたアプリケーションコア・サービス IBM Cloud Product Insights Transformation Advisor IBM DataPower Gateway IBM Data Science Experience Developer Edition IBM Data Server Manager IBM Db2 IBM Db2 Warehouse IBM InfoSphere Information Server IBM Integration Bus IBM MQ IBM Netcool Operations Insight プローブ IBM Operational Decision Manager IBM SDK for Node.js サンプル・アプリケーション IBM Spectrum LSF Community Edition IBM Spectrum Symphony IBM Voice Gateway IBM Watson Compare and Comply: Element Classification IBM Watson Explorer Microclimate MongoDB PostgreSQL Skydive

バンドルされたアプリケーション

⼀部の IBM® Cloud Private バンドルには、Helm チャートをインストールすることによってのみアクセスできるアプリケーションが含まれています。

該当するアプリケーションにアクセスするには、その前に、そのアプリケーションを IBM Cloud Private Catalog に対して使⽤可能にしておく必要があります。バンドルされた製品のインストールを参照してください。

IBM Cloud Private バンドルについて詳しくは、『IBM Cloud Private バンドル』を参照してください。

Cloud Automation Manager WebSphere Application Server Liberty WAS ND

Cloud Automation Manager

IBM Cloud Automation Manager は、複数のクラウドでクラウド・インフラストラクチャーをデプロイするための、IBM® Cloud Private のクラウド管理ソリューションであり、ユーザー・エクスペリエンスが最適化されています。

Cloud Automation Manager は、オープン・ソースの Terraform を使⽤して、クラウド・インフラストラクチャーをコードとして管理および提供します。コードとして提供されたクラウド・インフラストラクチャーは再使⽤可能であ


り、バージョン管理下で配置可能であり、分散チームで共有でき、環境を簡単に複製するために使⽤できます。

すぐに開始できるように、Cloud Automation Manager コンテンツ・ライブラリーには、サンプル・テンプレートが事前に取り込まれています。サンプル・テンプレートをそのまま使⽤するか、必要に応じてカスタマイズしてください。また、Cloud Automation Manager を使⽤して、より⾼度なアプリケーションの構成およびデプロイメントのために Chef ランタイム環境をデプロイすることもできます。

IBM Cloud Private での Cloud Automation Manager のインストールについて詳しくは、『インストール』を参照してください。

WebSphere Application Server Liberty

IBM WebSphere Application Server Liberty と、IBM® Cloud Private Catalog で使⽤可能な豊富な種類のミドルウェア・テクノロジーを組み合わせることで、データベース、キャッシュ・ソリューション、メッセージング・ソリュー

ションなど、ミドルウェアを統合するために必要な統合の量を低減できます。

IBM® Cloud Private で Liberty アプリケーションを実⾏するには、まず、アプリケーションを Docker コンテナーにインストールしてから、Helm チャートを構成する必要があります。

Liberty アプリケーションの継続的統合環境をセットアップする準備ができたら (コードのチェックインからデプロイメントまで)、Microservice Builder Helm チャートを探索して、Microservice Builder ファブリックのインストールおよび Microservice Builder パイプラインのセットアップを⾏います。 Microservice Builder を使⽤した IBM CloudPrivate での Liberty アプリケーションのデプロイについて詳しくは、『Liberty Helm chart』を参照してください。

WebSphere Application Server Network Deployment

WebSphere Application Server Network Deployment は、⼤規模な基幹業務アプリケーション・デプロイメント⽤の柔軟でセキュアなサーバー・ランタイム環境を提供します。オンプレミス、パブリック・クラウド、プライベート・クラウド、およびハイブリッド・クラウドでご利⽤いただけます。⽬的がコストの削減なのか、WebSphere への投資からの新しい価値の創出なのか、市場に出すまでの時間の短縮なのかを問わず、この製品は、あらゆるビジネス・

ニーズに適合します。

WebSphere Application Server の機能および利点

アプリケーション・インフラストラクチャーを最適化して、任意のクラウドおよび任意のコンテナー・サービ

スでアプリケーションをデプロイおよび管理できる柔軟性を提供するハイブリッド機能によって、コストを削

減します。

既存の Java™ アプリケーションをクラウドに接続し、API ライフサイクル管理およびクラウド・サービス(IBM Watson や IBM Cloud Product Insights など) によって、新しい価値を創出します。

Java および Node.js アプリケーションと API ⽤の単⼀の管理コンソールを備えた軽量の構成可能な実動ランタイムを使⽤して、迅速にクラウド・ネイティブおよび Web ベースのアプリケーションおよびマイクロサービスを作成してデプロイします。

クラウド内で起動し、Java Platform, Standard Edition 8 および Java Platform, Enterprise Edition 7 の各フレームワークのサポートが得られます。

Kubernetes への WebSphere アプリケーションのデプロイ

WebSphere アプリケーションを Kubernetes にデプロイするには、モノリシック・アプリケーションをマイクロサービス・ベースのアーキテクチャーに徐々にリファクタリングする必要があります。コードをリファクタリングする際


https://www.ibm.com/support/knowledgecenter/SS2L37/cam_planning.html

https://hub.docker.com/_/websphere-liberty/

https://www.ibm.com/support/knowledgecenter/SSAW57_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/twlp_icp_helm.html

https://www.ibm.com/support/knowledgecenter/en/SS5PWC/installing_fabric_task.html

https://www.ibm.com/support/knowledgecenter/en/SS5PWC/pipeline.html

https://www.ibm.com/support/knowledgecenter/SSAW57_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/rwlp_icp_helm.html

に、変換、共存、除去から成るストラングラー・アプリケーション・パターンを使⽤して、IBM® Cloud Private 上の仮想マシン (VM) にアプリケーションをリフト・アンド・シフトできます。

Application Modernization バンドルには、従来型のオンプレミスのデプロイメントから Kubernetes ベースのプライベート・クラウド環境への移⾏を容易にする複数の製品が含まれます。 WebSphere Connect を API Connect とともに使⽤して、アプリケーションおよびデータの各部を API として公開します。モノリシック・アプリケーションの各部をマイクロサービスに置き換える際、Cloud Automation Manager を使⽤して、ネットワーキング・インフラストラクチャーを Kubernetes の新規アプリケーションと共有する VM に旧アプリケーションをプロビジョンします。このデプロイメント・モデルを使⽤することで、2 つのアプリケーションは、クリーンかつセキュアに相互運⽤されます。

マイクロサービス・ベースのアプリケーションが旧アプリケーションを引き継ぐ準備が完全にできるまで、2 つのアプリケーションは共存することになります。この時点では、新規アプリケーションが Kubernetes にデプロイされている⼀⽅で、WebSphere の従来型デプロイメントの管理コードは、Cloud Automation Manager から VM で変更することなく実⾏し続けることができます。

以下のプロセスの概要をガイドとして使⽤して、Kubernetes で実⾏されるように WebSphere アプリケーションを最新化します。

1. Cloud Automation Manager を使⽤して、現在の WebSphere Application Server Network Deployment クラスターを IBM® Cloud Private 内の VM にデプロイします。 Cloud Automation Manager を使⽤してデプロイすることで、既存の管理コードおよびスクリプトをそのまま維持できます。

2. WebSphere Connect を使⽤して、現⾏形式のアプリケーション・コードの各部にアクセスできる API を作成します。 Application Modernization バンドルには WebSphere および API Connect が含まれているため、既存のアプリケーションからセキュアな新規 API を作成できます。詳しくは、WebSphere ConnectdeveloperWorks のチュートリアルを参照してください。

3. コードの各部を⼀度に 1 つずつ削除して、既存のコードをマイクロサービスとしてリエンジニアリングします。 WebSphere Connect API を使⽤して、古いコードと新しいコード間の呼び出しを⾏います。既存のコードに基づいた API 層の作成が終わったら、Microservice Builder ファブリックおよびパイプラインを使⽤して、IBM® Cloud Private の Kubernetes にデプロイされる、より⼩さいクラウド・ネイティブ・マイクロサービスによって、それらの API を実装します。このアプローチでは、VM を介して WebSphere のモノリシック・アプリケーションを実⾏することから開始し、コードの各部を、Kubernetes の新規アプリケーション内のマイクロサービスに徐々に移⾏します。

4. 新しいマイクロサービス・ベースのアプリケーションによって実動要件を適切に満たすことができるようになったら、既存のアプリケーションを廃⽌できます。

コア・サービス

インストール後に、コア IBM® Cloud Private サービスの⼀部のインスタンスをインストールできます。

Kibana やロギングおよびモニター・サービスの追加インスタンスをインストールする場合、クラスターに該当するチャートのインスタンスをデプロイできます。

IBM Cloud Private ロギング・サービス Kibana IBM Cloud Private モニター・サービス

IBM® Cloud Private ロギング・サービス


デフォルトでは、IBM Cloud Private はシステム・ログに ELK スタックを使⽤します。 Catalogからさらに ELK スタックをデプロイして、アプリケーション・ログを収集することもできます。

動的ストレージ・プロビジョニングを構成していない場合は、ロギング・サービスの新規インスタンスをデプロイす

る前に、サービス⽤の PersistentVolume を作成する必要があります。『アプリケーションへのボリュームの接続』を参照してください。

ロギング・サービスの新規インスタンスをデプロイするには、Catalog から ibm-icplogging チャートをデプロイします。『Catalog 内の Helm チャートのデプロイ』を参照してください。

IBM Cloud Private を使⽤する ELK スタックについて詳しくは、『IBM Cloud Private のロギング』を参照してください。

Kibana

IBM® Cloud Private のインストール時に Kibana をデプロイしなかった場合、後からデプロイできます。

Kibana の新規インスタンスをデプロイするには、Catalog から ibm-icplogging-kibana チャートをデプロイします。『Catalog 内の Helm チャートのデプロイ』を参照してください。

IBM Cloud Private management console のナビゲーション・メニューから Kibana にアクセスすることはできません。

IBM® Cloud Private モニター・サービス

IBM Cloud Private で提供されているモニター・サービスの追加インスタンスをデプロイして、アプリケーションの状況をモニターできます。

始める前に

実稼働環境で、IBM Cloud Private クラスター内に 3 つの PersistentVolume を作成します。モニター・サービス⽤のPersistentVolume を作成しなかった場合、収集されたメトリック・データは、コンテナーの異常終了時に失われます。テスト環境や開発環境の場合、PersistentVolume を作成したくない場合もあるでしょう。

以下の PersistentVolume を作成します。

Prometheus サーバー⽤の 10 GB のものAlertmanager ⽤の 1 GB のものGrafana ⽤の 1 GB のもの

注: IBM Cloud Private バージョン 2.1.0.3 では、バージョン 1.0.0 より後のバージョンの ibm-icpmonitoring Helmチャートを使⽤する必要があります。

Catalog からのモニター・サービスのデプロイ

IBM Cloud Private management console で Catalog から、カスタマイズされた構成を使⽤して、追加のモニター・スタックをデプロイできます。

1. Catalog のページから、ibm-icpmonitoring Helm チャートをクリックして構成およびデプロイします。2. 必須パラメーターの値を指定します。

1. Prometheus、Alertmanager、および Grafana ⽤の PersistentVolume を作成した場合、各セクションのpersistentVolume.enabled フィールドに true と⼊⼒します。


2. Prometheus、Alertmanager、および Grafana ⽤の PersistentVolume を作成した場合、各セクションのpersistentVolume.size フィールドに、永続ボリュームのサイズを⼊⼒します。 Prometheus のセクションでは、10Gi と⼊⼒します。Alertmanager および Grafana のセクションでは、1Gi と⼊⼒します。

CLI からのモニター・サービスのデプロイ

1. Kubernetes コマンド・ライン (kubectl) をインストールします。『kubectl CLI を使⽤した IBM Cloud Privateクラスターへのアクセス』を参照してください。

2. Helm コマンド・ライン・インターフェース (CLI) をインストールします。『Helm CLI のセットアップ』を参照してください。

3. ibm-icpmonitoring Helm チャートをインストールします。

チャート⽤の PersistentVolume を作成した場合、以下のコマンドを実⾏します。

helm install -n <release> --namespace <namespace> --set prometheus.persistentVolume.enabled=true --set alertmanager.persistentVolume.enabled=true --set grafana.persistentVolume.enabled=true ibm-charts/ibm-icpmonitoring

ここで、<release> はデプロイメントに割り当てる名前であり、<namespace> はデプロイ先の名前空間です。

チャート⽤の PersistentVolume を作成しなかった場合は、以下のコマンドを実⾏します。

helm install -n <release> --namespace <namespace> ibm-charts/ibm-icpmonitoring

ここで、<release> はデプロイメントに割り当てる名前であり、<namespace> はデプロイ先の名前空間です。

モニター・ダッシュボードへのアクセス

モニター・サービス・コンポーネントは、NodePort を使⽤してデプロイされるため、任意のノードの IP アドレスを使⽤してアクセスできます。 URL のフォーマットは、https://<node_ip>:<service_port> です。

IBM Cloud Private management console から URL を取得するには、以下のようにします。

1. IBM Cloud Private management console から、「ネットワーク・アクセス (Network Access)」>「サービス(Services)」をクリックします。

2. サービス名をクリックして、モニター・サービスのコンポーネントの概要ページを開きます。モニター・サービス名は、<release>-prometheus、<release>-alertmanager、<release>-grafana のようになっています。

3. コンポーネント・ダッシュボードにアクセスするには、エンドポイント・ラベルの側にある「アクセス HTTP(access http)」リンクをクリックします。

kubectl CLI を使⽤してアクセス URL を取得するには、以下のようにします。

1. 以下のように、サービスの有効なポート番号を取得します。

Prometheus マネージャーのポートを取得するコマンド:

kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services ${RELEASE}-prometheus -n ${NAMESPACE}

アラート・マネージャーのポートを取得するコマンド:

kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services ${RELEASE}-prometheus-alertmanager -n ${NAMESPACE}


grafana のポートを取得するためのコマンド:

kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services ${RELEASE}-grafana -n ${NAMESPACE}

Grafana ダッシュボードにアクセスするためのデフォルトのユーザー名とパスワードは、admin と admin です。

モニター・サービスを使⽤するためのアプリケーションの構成

モニター・サービスのインスタンスをデプロイした後に、それを使⽤するようにアプリケーションを構成する必要が

あります。アプリケーションの Helm チャート内でこの構成を実⾏します。

1. アプリケーションを変更してメトリックを公開します。

メトリック・エンドポイントがあるアプリケーションの場合、アノテーション prometheus.io/scrape: 'true' を使⽤して、Kubernetes サービスとしてメトリック・エンドポイントを定義する必要があります。サービス定義は、以下のコードのようになります。

apiVersion: v1 kind: Service metadata: annotations: prometheus.io/scrape: 'true' labels: app: liberty name: liberty spec: ports: - name: metrics targetPort: 5556 port: 5556 protocol: TCP selector: app: liberty type: ClusterIP

注: Prometheus のためのメトリック・エンドポイントの構成について詳しくは、Prometheus 資料のCLIENT LIBRARIES を参照してください。

collectd を使⽤し、メトリックの公開のために collectd-exporter に依存しているアプリケーションについて、アプリケーション・コンテナー内の collectd 構成ファイルを更新します。この構成ファイルでは、ネットワーク・プラグインを追加し、collectd エクスポーターを指す必要があります。以下のテキストを構成ファイルに追加します。

LoadPlugin network <Plugin network> Server "${RELEASE}-exporter" "25826" </Plugin>

Grafana での Prometheus データ・ソースの⼿動構成

デフォルトでインストールされる Grafana インスタンスは、デフォルト・ダッシュボードを備えており、そのデータ・ソースとしてデフォルトの Prometheus インスタンスを使⽤するように構成されています。このデータ・ソースは、IBM Cloud Private のインストール時に⾃動的に構成されます。

場合によっては、偶発的なエラーのため、データ・ソース構成が失敗することがあります。この場合、データ・ソースを⼿動でセットアップできます。

データ・ソースを構成する前に、以下のアクションを実⾏します。


https://prometheus.io/docs/instrumenting/

Helm コマンド・ライン・インターフェース (CLI) をインストールします。『Helm CLI のセットアップ』を参照してください。

kubectl CLI をセットアップします。『kubectl CLI を使⽤した IBM Cloud Private クラスターへのアクセス』を参照してください。

データ・ソースを構成するには、以下のようにします。

1. job.yaml という名前のジョブ YAML ファイルを作成します。

Linux® 64-bit クラスターの場合、以下の YAML を使⽤します。

apiVersion: batch/v1 kind: Job metadata: labels: app: monitoring-grafana component: setds name: monitoring-grafana-ds namespace: kube-system spec: activeDeadlineSeconds: 300 template: metadata: labels: app: monitoring-grafana component: setds spec: tolerations: - key: "dedicated" operator: "Exists" effect: "NoSchedule" affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: beta.kubernetes.io/arch operator: In values: - amd64 - ppc64le - key: management operator: In values: - "true" containers: - name: grafana-ds image: "ibmcom/curl:3.6" command: ["/opt/entry/entrypoint.sh"] volumeMounts: - mountPath: "/opt/ibm/monitoring/certs" name: monitoring-client-certs - mountPath: "/opt/ibm/monitoring/ca-certs" name: monitoring-ca-cert - mountPath: "/opt/entry" name: grafana-ds-entry volumes: - name: monitoring-client-certs secret: secretName: monitoring-monitoring-client-certs - name: monitoring-ca-cert secret: secretName: monitoring-monitoring-ca-cert - name: grafana-ds-entry configMap: name: monitoring-grafana-ds-entry-config


defaultMode: 0744 restartPolicy: OnFailure

2. 失敗したジョブを削除し、新しいジョブを作成します。次のコマンドを実⾏します。

kubectl delete jobs/monitoring-grafana-ds -n kube-system kubectl apply -f job.yaml

外部 Grafana インスタンスでの Prometheus データ・ソースの構成

データ・ソースとしてデフォルトの Prometheus インスタンスを使⽤するように、IBM Cloud Private クラスターの外部で実⾏される Grafana インスタンスを構成できます。

1. NodePort タイプを使⽤する Prometheus ⽤の service.yaml ファイルを作成します。ファイルには、以下のテキストが含まれます。

apiVersion: v1 kind: Service metadata: labels: app: monitoring-prometheus component: prometheus name: monitoring-prometheus-externalservice namespace: kube-system spec: ports: - name: https port: 8443 protocol: TCP targetPort: 8443 selector: app: monitoring-prometheus component: prometheus type: "NodePort"

2. Prometheus リソースを更新するために、以下のコマンドを実⾏します。

kubectl apply -f service.yaml

3. 以下のように、ランダムに割り当てられた NodePort ポートを取得します。

kubectl get --namespace kube-system -o jsonpath="{.spec.ports[0].nodePort}" services monitoring-prometheus-1

4. モニター・サービスのクライアント証明書およびキーを取得します。

1. 以下のように、クライアント証明書のエンコードされた値を表⽰します。

kubectl get secrets/monitoring-monitoring-client-certs -n kube-system -o yaml

2. base64 デコード・ツールを使⽤して、証明書をデコードします。 [https://www.base64decode.org/ ]など、任意の Base64 でコード・ツールを使⽤できます。必ず ASCII モードに切り替えてください。

5. 以下のように、モニター・サービスの ca cert ファイルを取得します。

1. 以下のように、 ca cert ファイルのエンコードされた値を表⽰します。

kubectl get secrets/monitoring-monitoring-ca-cert -n kube-system -o yaml

2. base64 デコード・ツールを使⽤して、ca cert ファイルをデコードします。[https://www.base64decode.org/ ] など、任意の Base64 でコード・ツールを使⽤できます。必ずASCII モードに切り替えてください。


https://www.base64decode.org/

https://www.base64decode.org/

6. Grafana インスタンスをホストしているシステムの hosts ファイルで、以下の項⽬を追加します。

<IP_address> monitoring-prometheus

ここで、<IP_address> は、Grafana がアクセスできる IBM Cloud Private クラスター内のノードの IP アドレスです。

7. Grafana ダッシュボードで、データ・ソースを追加します。以下の値を使⽤します。

「Type」で「Prometheus」を選択します。以下の HTTP 設定を使⽤します。

Url: https://monitoring-prometheus:<Port>。ここで、<Port> は、作成したサービスのNodePort ポート値です。Access: proxy

「Http Auth」で「TLS Client Auth」および「With CA Cert」を選択します。「TLS Auth Details」フィールドに、クライアント証明書および ca cert のデコードされた値を⼊⼒します。

パラメーター値を⼊⼒した後に、「Save & Test」をクリックします。データ・ソースが作成されます。「Success Data source is working」というメッセージが表⽰された場合、データ・ソースは正常に構成されました。

Prometheus のログおよびメトリックの管理

config.yaml ファイル内にある storage.tsdb.retention パラメーターを更新して、メトリックの保存期間を変更できます。デフォルトでは、この値は、24h に設定されており、メトリックは 24 時間保持されてからパージされます。『モニタリング・サービスの構成』を参照してください。

ただし、このデータをシステムから⼿動で削除する必要がある場合、Prometheus コンポーネントで提供されているREST API を使⽤できます。

メトリック・データを削除するには、Delete Series を参照してください。削除されたデータをディスクから削除し、ディスク・スペースをクリーンアップするには、CleanTombstones を参照してください。

注: ターゲット URL のフォーマットは https://<ip_address>:8443/prometheus でなければなりません。ここで、<ip_address> は、management console へのアクセスに使⽤する IP アドレスです。

メトリック・データを削除する場合、コマンドは以下のコードのようになります。

https://<ip_address>:8443/prometheus/api/v1/admin/tsdb/delete_series?*******

削除されたデータを削除してディスクをクリーンアップする場合、コマンドは以下のコードのようになりま

す。

https://<ip_address>:8443/prometheus/api/v1/admin/tsdb/clean_tombstones

IBM Cloud Product Insights Transformation Advisor

IBM® Cloud Product Insights Transformation Advisor は、クラウドにデプロイするためにオンプレミスの Java™ EEアプリケーションを迅速に評価できるようにする、無料で使⽤可能な開発者ツールです。

Transformation Advisor アプリケーションは、IBM® Cloud Private で使⽤可能です。パブリック・クラウド環境またはプライベート・クラウド環境上の WebSphere Application Server および Liberty に迅速にデプロイするために、オンプレミスのアプリケーションを速やかに評価できます。


https://prometheus.io/docs/prometheus/latest/querying/api/#delete-series

https://prometheus.io/docs/prometheus/latest/querying/api/#clean-tombstones

IBM Cloud Private での Transformation Advisor のインストールについて詳しくは、Deploying TransformationAdvisor into IBM Cloud Private を参照してください。

Transformation Advisor の使⽤について詳しくは、Using the Transformation Advisor on IBM Cloud Private を参照してください。

IBM DataPower Gateway

IBM® DataPower® Gateway は、複数のビジネス・チャネルを介したワークロードに対するセキュリティー、制御、統合、および最適化されたアクセスを提供できるようにする単⼀のゲートウェイ・プラットフォームです。該当するチャネルには、モバイル、Web、アプリケーション・プログラミング・インターフェース (API)、サービス指向アーキテクチャー (SOA)、B2B、クラウドが含まれます。

DataPower Gateway は、チャネル全体で⼀貫したセキュリティー・ポリシーを使⽤してワークロードを保護するための集中型ポリシー適⽤ポイントを提供します。これにより、運⽤コストが削減され、セキュリティーが向上しま

す。 DataPower Gateway を使⽤することで、価値の⾼い IT 資産のスコープを新規チャネルに迅速に拡張し、顧客、従業員、その他のステークホルダーがクリティカル・リソースにアクセスできるようにすることが可能です。詳しくは、IBM Knowledge Center の IBM DataPower Gateway を参照してください。

IBM® Cloud Private での DataPower のインストールについて詳しくは、Deploying DataPower into IBM Cloud Private を参照してください。

IBM Data Science Experience Developer Edition

IBM® Data Science Experience (DSX) Developer Edition は、データ・サイエンティストおよびデータ・エンジニア向けの無料で使⽤可能なデスクトップ・クライアントです。

専有の IBM テクノロジーと統合されたデータ・サイエンス・ツールのスイートを提供します。また、RStudio、Spark、および Jupyter ノートブック・テクノロジーとシームレスに統合されます。追加情報については、DSXDesktop の資料を参照してください。

IBM® Cloud Private での DSX Developer Edition のインストールについて詳しくは、Deploy DSX Developer Editioninto IBM Cloud Private を参照してください。

IBM® Data Server Manager

IBM® Data Server Manager (DSM) は、Db2 for Linux®, UNIX®, and Windows データベースおよび BigInsights Big SQL環境のパフォーマンスの統括、モニター、管理、および最適化に役⽴ちます。 Db2 for z/OS データベースに対しても同様の機能を提供します。また、このソリューションは、Db2 on Cloud、Db2 Warehouse on Cloud、および Db2Warehouse Private のエンタープライズ管理機能も提供します。

IBM DSM により、データベース管理者 (DBA) や他の IT スタッフは、パフォーマンスをプロアクティブに管理し、問題がビジネスに影響を及ぼす前に問題を防⽌できます。このソリューションはクラウド対応であり、迅速かつ容易にデプロイできます。

無料の DSM Edition を使⽤して、Db2 を管理、モニターできます。詳しくは、Data Server Manager を参照してください。

IBM Cloud Private での DSM のインストールについて詳しくは、Deploy DSM into IBM Cloud Private を参照してください。

IBM Db2318 IBM Cloud Private 2.1.0.3

https://developer.ibm.com/recipes/tutorials/deploying-transformation-advisor-into-ibm-cloud-private/

https://developer.ibm.com/recipes/tutorials/using-the-transformation-advisor-on-ibm-cloud-private/

https://www.ibm.com/support/knowledgecenter/SS9H2Y

https://developer.ibm.com/apiconnect/2017/10/16/deploying-datapower-ibm-cloud-private/

https://datascience.ibm.com/docs/content/desktop/welcome.html

https://datascience.ibm.com/docs/content/desktop/icp.html

https://www.ibm.com/jp-ja/marketplace/data-server-manager

https://developer.ibm.com/recipes/tutorials/deploy-dsm-into-ibm-cloud-private/

IBM® Db2® は、管理、ストレージ、開発、サーバーのコストを低減しながら、複数のワークロードに対して業界をリードするパフォーマンスを提供できるように最適化されたデータベース・ソリューションです。

IBM Db2 は、ビジネス⽤のアプリケーションを迅速に開発、テスト、およびビルドできるように設計されたマルチ・ワークロード・データベースです。このソリューションは、運⽤ワークロードおよび分析ワークロード⽤に設計されており、⾼いパフォーマンスとスケーラビリティーを実現できるように、メモリー内のコンピューティングおよびそ

の他の機能を提供します。ストレージの最適化および圧縮により、アプリケーションのコスト効率性を⾼めることができ、また継続的なデータ取り込みにより、ビジネスのスピードでアプリケーションが確実に実⾏されます。

Db2 には、さまざまなエディションがあります。無料の Db2 Developer-C Edition を使⽤して、アプリケーションを設計、ビルド、プロトタイプ化できます。詳しくは、DB2 for Linux® UNIX® and Windows 参照してください。

IBM® Cloud Private での Db2 Developer-C Edition のインストールについて詳しくは、Deploy Db2 into IBM CloudPrivate を参照してください。

IBM Db2 Warehouse

IBM Db2 Warehouse は、プライベート・クラウドおよび仮想プライベート・クラウド⽤のソフトウェア定義のデータウェアハウスです。任意のハードウェアに迅速にデプロイし、その後、デプロイメントを簡単に管理できます。IBM Db2 Warehouse の真価は、メモリー内の処理とデータベース内の分析を組み合わせた、ハイパフォーマンスの分析エンジンです。また、Db2 Warehouse は、Oracle および Netezza との互換性も備えています。

IBM Cloud Private を使⽤して Db2 Warehouse をデプロイおよび構成する⽅法については、Helm チャートのREADME ファイルを参照するか、IBM Db2 Warehouse 資料で、IBM Db2 Warehouse のセットアップのセクションにある IBM Cloud Private のトピックを参照してください。

IBM® InfoSphere® Information Server for Evaluation v11.7

InfoSphere® Information Server は、データを介してビジネス価値を創出するための分析の洞察に関する包括的な情報管理およびガバナンスのソリューションを提供します。 IBM® InfoSphere® Information Server for Evaluation v11.7は、評価のために IBM® Cloud Private ⾮実稼働環境にデプロイするためのものです。

これは、統合環境における ETL ジョブの実⾏、資産の管理、およびデータのクリーンアップのための InfoSphere®DataStage、Information Governance Catalog、Information Analyzer を含む製品スイートを提供します。詳しくは、InfoSphere® Information Server の資料を参照してください。

IBM Cloud Private での IBM® InfoSphere® Information Server Evaluation バージョンのインストールについて詳しくは、Deploy InfoSphere Information Server for Evaluation into IBM Cloud Private を参照してください。

IBM Integration Bus

IBM Integration Bus は、市場をリードする、アプリケーション統合のソフトウェア・ソリューションです。これは、アジャイルでセキュアなハイパフォーマンス・プラットフォームで統合機能の包括的なセットを提供し、エンタ

ープライズ・システム、アプリケーション、およびデータの間の汎⽤接続を実現します。

IBM Integration Bus を使⽤することで、サポートされるメッセージ・フォーマットやプロトコルに関係なく、複数のアプリケーションを接続できます。この接続により、柔軟で動的かつ拡張可能なインフラストラクチャーで、多様なアプリケーションの間で対話を⾏い、データを交換できます。

IBM Integration Bus は、メッセージをある場所から別の場所にルーティング、変換、拡張します。ルーティング、変換、フィルター、拡張、モニター、配布、収集、相関分析、検出などの多くの操作がサポートされます。例えば、


https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.welcome.doc/doc/welcome.html

https://developer.ibm.com/recipes/tutorials/db2-integration-into-ibm-cloud-private/

https://www.ibm.com/support/knowledgecenter/en/SS6NHC/com.ibm.swg.im.dashdb.kc.doc/welcome.html

https://www.ibm.com/support/knowledgecenter/en/SS6NHC/com.ibm.swg.im.dashdb.doc/admin/local_setup.html

https://www.ibm.com/analytics/us/en/technology/information-server/

https://www.ibm.com/support/knowledgecenter/SSZJPZ_11.7.0/com.ibm.swg.im.iis.productization.iisinfsv.home.doc/topics/kc_homepage_IS.html

https://developer.ibm.com/recipes/tutorials/deploy-infosphere-information-server-for-evaluation-into-ibm-cloud-private/

メッセージの内容に基づいて、メッセージを送信側から受信側にルーティングしたり、メッセージをあるフォーマッ

トから別のフォーマットに変換したり、メッセージを変更または結合してから配信したりすることができます。

IBM Integration Bus では、WebSphere® MQ、JMS 1.1 と 2.0、HTTP と HTTPS、Web サービス (SOAP と REST)、ファイル、エンタープライズ情報システム (SAP や Siebel を含む)、TCP/IP など、さまざまなプロトコルがサポートされます。また、バイナリー・フォーマット (C と COBOL)、XML、業界標準 (SWIFT、EDI、HIPAA を含む) など、さまざまなデータ・フォーマットもサポートされます。さらに、独⾃のデータ・フォーマットを定義することもできます。

開発およびテストのために無料で使⽤できる IBM Integration Bus for Developers (Developer Edition) または実稼働環境に適している IBM Integration Bus Advanced Edition のいずれかを選択できます。 Developer Edition では、すべての機能が有効ですが、メッセージ・フロー・レベルで 1 秒当たり 1 件のメッセージ (トランザクション) に制限されます。 Advanced Edition では、SalesforceRequest ノードを除き、すべての機能が有効です。

IBM Integration Bus のエディションおよびライセンス要件について詳しくは、IBM Integration Bus のライセンス要件を参照してください。

IBM® Cloud Private への IBM Integration Bus のインストールについては、以下のトピックを参照してください。

Deploying IBM Integration Bus to IBM Cloud PrivateDeploying IBM Integration Bus for Developers to IBM Cloud Private

IBM MQ

IBM® MQ は、複数のプラットフォームにおける多様なアプリケーションおよびビジネス・データの統合を簡素化および加速するメッセージング・ミドルウェアです。

IBM MQ は、任意のタイプのデータをメッセージとしてトランスポートできます。そのため、企業では、サービス指向アーキテクチャー (SOA) 環境などの柔軟で再使⽤可能なアーキテクチャーを構築できます。これは、さまざまなコンピューティング・プラットフォーム、アプリケーション、Web サービス、および通信プロトコルとともに動作し、セキュリティーの充実したメッセージ配信を実現します。 IBM MQ は、組織内外のメッセージおよびデータのフローの可視性および制御のための通信層を提供します。詳しくは、IBM MQ (以前の IBM WebSphere MQ) を参照してください。

MQ では、テストおよび実動のために、無料の開発オプションおよび有料のデプロイメント・オプションが⽤意されています。

IBM® Cloud Private のために IBM MQ を構成する場合は、『IBM MQ の IBM Cloud Private へのインストール』を参照してください。

Netcool Operations Insight プローブ

IBM® Netcool® Operations Insight は、各種ビジネス・アプリケーション、仮想化サーバー、ネットワーク・デバイスとプロトコル、インターネット・プロトコル、およびセキュリティー・デバイスとストレージ・デバイスのインフ

ラストラクチャーと運⽤管理を、単⼀の⼀貫したソリューションへと統合します。

Netcool Operations Insight を使⽤すると、さまざまなソースからのイベントなどの運⽤データを受信し、相関付けることができ、それによってオペレーターが障害の原因を検出できるようになります。原因を迅速に把握できるほど、システムを復元し、ビジネスを復帰するのも早くなります。 IBM® Cloud Private と IBM Netcool OperationsInsight の間の統合シナリオの説明については、Learn how IBM Netcool Operations Insight provides operationalefficiency and automation for IBM Cloud Private を参照してください。

IBM Netcool Operations Insight がデータを取得するための標準メカニズムの 1 つに、プローブの概念があります。プローブは、専⽤のソースからイベントを取得し、OMNIbus で予期される形式に合わせてデータを微調整し、カス


https://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/bh25920_.htm

https://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/bz91410_.htm

https://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/bz91400_.htm

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ/com.ibm.mq.helphome.doc/product_welcome_wmq.htm

https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.ins.doc/q131160_.htm

https://www.ibm.com/developerworks/community/blogs/fe25b4ef-ea6a-4d86-a629-6f87ccf4649e/entry/Learn_how_IBM_Netcool_Operations_Insight_provides_operational_efficiency_and_automation_for_IBM_Cloud_Private?lang=en

タム・フィールドを設定してから、イベントを OMNIbus に転送します。 IBM Netcool Operations Insight メッセージ・バス・プローブを介して Logstash および Prometheus からイベントを受信するサンプル構成を使⽤できます。これらの 2 つのソースは、アプリケーションの正常性に関するすべての重要な情報を収集します。

Netcool Operations Insight のプローブには、IBM® Cloud Private で使⽤するための無料の開発オプションが⽤意されています。このイメージ IBM Tivoli Netcool/OMNIbus Probe for Message Bus x86_64 Docker Image は Docker ハブからプルでき、デフォルトの IBM® Cloud Private カタログ内でその Helm チャートを⾒つけることができます。

Logstash および Prometheus ⽤の Netcool Operations Insight プローブのセットアップについて詳しくは、Collectand detect problems using Netcool Operations Insight を参照してください。 IBM Runbook Automations をセットアップして、問題を修正する⽅法について詳しくは、Solve Problems in IBM Cloud Private using IBM RunbookAutomation を参照してください。

IBM Operational Decision Manager

IBM® Operational Decision Manager (ODM) は、反復可能なビジネスの決定を収集、⾃動化、および管理するためのプラットフォームです。洞察を形成してビジネス・ルールを適⽤する状態を特定できます。

ODM は、ビジネスにおいて、⾃動化されたインテリジェントな意思決定によって、リアルタイム・データに対応できるようにする、認知技術を提供します。 IT ユーザーとビジネス・ユーザーはいずれも、組織内の運⽤システムで使⽤されるビジネス意思決定ロジックを管理できます。

ODM for Developers は、無料の開発オプションを使⽤する開発者のためのインストール・プロセスを簡素化し、迅速化するフィーチャー・サービスです。 ODM は、IBM® Cloud Private での実動⽤の有料デプロイメント・オプションとしても使⽤可能です。

ODM for Developers は、無料で使⽤可能で、テスト環境に最適な限定オファリングを提供します。

ODM のエディションおよびライセンス要件について詳しくは、ライセンスを参照してください。

IBM® Cloud Private ⽤に ODM を構成するには、インストールを参照してください。

Node.js サンプル・アプリケーション

IBM® Cloud Private で Node.js アプリケーションを作成、デプロイ、およびモニターする⽅法を⽰すために、サンプル・アプリケーションが⽤意されています。

サンプル・アプリケーションは、IBM Cloud Developer Tools を使⽤して作成されています。アプリケーションに含まれている以下の npm モジュールによってモニターが提供されます。

モニター・データを収集する appmetrics と、そのデータのビューを提供する appmetrics-dash 。Prometheus で表⽰するためのモニター・データを提供する appmetrics-prometheus 。 Prometheusをクラスターにデプロイしてから使⽤して、Kubernetes 内の多数存在する可能性があるポッドで実⾏されている Node.js アプリケーションをモニターできます。

Catalogから Node.js サンプル・アプリケーションをインストールできます。nodejs-sample を検索してください。デプロイメント後に、アプリケーションを開始して、アプリケーションに関する詳細情報を⽰す Web ページを表⽰します。

サンプル・アプリケーションは、IBM SDK for Node.js ランタイムで実⾏されます。 SDK について詳しくは、IBMSDK for Node.js を参照してください。

IBM Spectrum LSF Community Edition


https://hub.docker.com/r/ibmcom/netcool-probe-messagebus/

https://developer.ibm.com/recipes/tutorials/collect-detect-problems-in-ibm-cloud-private-using-netcool-operations-insight/

https://developer.ibm.com/recipes/tutorials/solve-problems-in-ibm-cloud-private-using-ibm-runbook-automation/

https://www.ibm.com/support/knowledgecenter/en/SSQP76_8.9.2/com.ibm.odm.distrib.install/topics/con_inst_licenses.html

https://www.ibm.com/support/knowledgecenter/SSQP76_8.9.2/com.ibm.odm.icp/topics/tsk_install_odm_icp.html

https://www.npmjs.com/package/appmetrics

https://www.npmjs.com/package/appmetrics-dash

https://prometheus.io/

https://www.npmjs.com/package/appmetrics-prometheus

https://developer.ibm.com/node/sdk/

IBM Spectrum LSF Community Edition は、IBM Spectrum LSF ワークロード管理プラットフォームの無料のコミュニティー・エディションです。

IBM Spectrum LSF は、分散コンピューティング環境⽤の強⼒なワークロード管理システムです。 IBM Spectrum LSFは、インテリジェントなポリシー駆動のスケジューリング機能の包括的なセットを提供します。これにより、すべて

の計算インフラストラクチャー・リソースを使⽤して、最適なアプリケーション・パフォーマンスが得られるように

することができます。

IBM Spectrum LSF は、Web ベースのインターフェースの最新のデザインを使⽤してアクセスできる堅固なワークロード・アプリケーション管理機能を備えています。そのため、強⼒、かつ使いやすいソリューションとなっていま

す。 MPI を必要とするアプリケーションでは、Platform MPI ライブラリーにより、HPC アプリケーションが加速およびスケーリングされ、解決までの時間が短縮します。

IBM developerWorks 上の LSF フォーラムを介して、コミュニティーの⽀援が受けられます。

注: IBM Spectrum LSF Community Edition アプリケーションをインストールして実⾏するには、デュアル・ソケット・コアまたはシングル・コアのホストが必要です。シングル・コアを使⽤する場合、最⼤で 10 個までサポートされます。

IBM Spectrum Symphony

IBM Spectrum Symphony は、スケーラブルな共有グリッドにおける計算およびデータの処理負荷が⾼いアプリケーション⽤のエンタープライズ・クラスのワークロード・マネージャーです。より早い結果が得られ、使⽤可能なすべてのリソースを有効活⽤するために何⼗もの分散並列アプリケーションを加速する効率的な分析コンピューティング

環境を提供します。

IBM Spectrum Symphony は、無料のお客様が管理する Community Edition として、IBM® Cloud Private とともにデフォルトで使⽤可能です。 Community Edition は、最⼤で 64 コアまでのクラスターに対して、IBM SpectrumSymphony の全機能を提供します。

IBM Cloud Private で Helm チャートとして IBM Spectrum Symphony をデプロイして、Kubernetes クラスター内のDocker コンテナー・アプリケーションとして IBM Spectrum Symphony を迅速に構成および実⾏できます。その後、IBM Cloud Private で UI または CLI から IBM Spectrum Symphony アプリケーションを管理できます。 IBMCloud Private での IBM Spectrum Symphony のインストールについて詳しくは、『Installing IBM SpectrumSymphony in IBM Cloud Private』を参照してください。

ヒント: IBM Spectrum Symphony の Community Edition は、64 コアに制限されており、IBM developerWorks コミュニティー・フォーラムで⽀援を受けることができます。クラスターをスケーリングして 64 コアを超えるようにし、ライセンス交付を受けたソフトウェアに関連付けられた IBM サポートを受けるには、ライセンスを IBMSpectrum Symphony Advanced Edition にアップグレードすることを検討してください。詳しくは、分析ワークロード管理: IBM Spectrum Symphony を参照してください。

IBM Voice Gateway

IBM® Voice Gateway は、 Session Initiation Protocol (SIP) を使⽤して、⼀連のオーケストレーションされた Watsonサービスと、パブリックおよびプライベート電話網を統合する⼿段を提供します。

Voice Gateway により、バックボーンで Watson™ ⼈⼯知能を使⽤したコグニティブ・セルフサービス・エージェントをセットアップできます。これにより、エージェントは、顧客と直接通信して、従来型の対話式⾳声応答 (IVR) システムでは困難であった複雑な対話を処理できます。また、Voice Gateway をエージェント・アシスタントとして構成することもできます。この場合、顧客である発信者と顧客サービス・エージェント間の電話通話を書き起こし、リ

アルタイムのエージェント・フィードバックが得られるように分析を使⽤して会話を処理できます。詳しくは、IBMVoice Gateway の資料を参照してください。


https://www.ibm.com/developerworks/community/forums/html/forum?id=8286831d-ca54-41c3-9929-9d326ece835c

https://www.ibm.com/support/knowledgecenter/SSZUMP_7.2.0/install_grid_sym/symphony_icp.html

https://www.ibm.com/developerworks/community/groups/service/html/communityoverview?communityUuid=46ecec34-bd69-43f7-a627-7c469c1eddf8#fullpageWidgetId=We269f41b55c9_44c8_be84_82043b18865f

https://www.ibm.com/jp-ja/marketplace/analytics-workload-management

https://www.ibm.com/support/knowledgecenter/SS4U29/

IBM Cloud Private で Voice Gateway をデプロイすることで、プライベート・クラウドでセルフサービス・エージェントまたはエージェント・アシスタントを迅速にセットアップできます。デプロイされた Voice Gateway は、他の外部サービスやネットワーク・コンポーネント (Watson サービス、SIP プロバイダー、コンタクト・センター・インフラストラクチャーなど) に接続されます。 Voice Gateway には、開発および制限された実動⽤のライセンスが付属しています。このライセンスは、完全な実稼働環境⽤のライセンスにアップグレード可能です。

IBM Cloud Private での Voice Gateway の構成およびデプロイについては、『IBM Cloud Private での Voice Gatewayのデプロイ』を参照してください。

IBM Watson Compare and Comply: Element Classification

IBM Watson™ Compare and Comply: Element Classification は、契約などの法的⽂書における⾼密度の法的⾔語をプログラムで解析および分析するためのソリューションです。

Compare and Comply: Element Classification を使⽤すると、規定を記述した⽂書を迅速に解析して重要なエレメントを変換、識別、分類することができます。最先端の⾃然⾔語処理を使⽤して、このサービスは以下のような⽂書エレメントを抽出します。

party (エレメントが参照するパーティー)nature (エレメントのタイプ)category (特定のクラス)

Compare and Comply: Element Classification のサービスは、以下の機能を提供します。

契約の⾃然⾔語による理解

プログラマチック PDF を注釈付き JSON に変換する機能対象となる問題に関する専⾨知識に沿った法⼈およびカテゴリーの識別

Compare and Comply: Element Classification は、機能的に豊富な、統合化され⾃動化された Watson API のセットを提供し、プログラマチックな PDF を⼊⼒して以下を識別します。

セクション

リスト (番号付き、黒丸付き)脚注

テーブル

このサービスは、これらの項⽬を構造化された HTML 形式に変換します。さらに、この構造化形式を分類し、注釈を付け、ラベル付きのエレメント、タイプ、およびカテゴリーを持つ JSON として出⼒します。

Compare and Comply: Element Classification について詳しくは、製品の資料を参照してください。

IBM Watson Explorer

IBM Watson Explorer は、コグニティブ・コンテンツ分析ソリューションであり、⾮構造化情報を含むあらゆるデータをドリルスルーして、求めている深い洞察を⾒つけられるようにします。 Watson Explorer は、次の 3 つの概要レベルで、あらゆるデータを拡張するのに役⽴ちます。

探索: Watson Explorer は、⾮構造化データを視覚的に編成およびナビゲートする複数の⽅法を備えており、ユーザーが、より迅速かつ徹底的に情報を探索できるようにします。

分析: Watson Explorer Content Miner により、ユーザーは、⾮構造化データの焦点を迅速に絞り込むことができます。余分な結果を取り除き、統計的異常を容易にモニターすることで、具体的で関連性の⾼い情報を提供

できます。

アドバイス: Watson Explorer は、機械学習の⼒を利⽤して、あらゆるデータの中からパターン、ディスカバリー、および洞察を明らかにします。 Watson Explorer は、最も関連性の⾼い情報に導くお客様独⾃のコグニテ


https://www.ibm.com/support/knowledgecenter/SS4U29/deployicp.html

https://console.bluemix.net/docs/services/compare-and-comply/getting-started.html#getting_started

ィブ・アシスタントとして機能します。

IBM Watson Explorer について詳しくは、製品の資料を参照してください。

Microclimate

Microclimate は、Docker 化された、エンドツーエンドの開発環境です。 Java、Node、および Swift でマイクロサービスを⽣成し、それらを編集し、変更を即時に確認できます。コードが完成したら、コードをチェックインします。そうすると、パイプラインによって⾃動的にビルドが⾏われ、Kubernetes にデプロイされます。

Microclimate は、単に使いやすい新種の IDE ではありません。 Microclimate には、⼿始めに必要なアプリケーション・モニター・ツールと HTTP ロード・ドライバーが組み込まれています。これらの各ツールは、プリインストールされ、サービス⽤に事前構成されているため、タブを切り替え、すぐに実⾏できます。問題が発⽣したときに、他のツールを⾒つけたり、ツールをセットアップしたりする必要はありません。

Microclimate を使⽤すると、すぐに Docker でマイクロサービスと⾃動ビルドを作成できます。あるマシンで発⽣した問題を再現したり、実稼働環境のコンテナーに切り替える際の違いを再現したりするために時間を費やす必要がな

くなります。環境も Docker を使⽤して構築されているため、ローカルで実⾏することも、クラウド・プラットフォーム上でホストし、Web 上で使⽤することもできます。ローカル設定や、複数のツールのインストーラーが必要になるといった問題もなくなります。

Microclimate について詳しくは、Microclimate Web サイトを参照してください。そこでは、Microclimate のダウンロード、サポート情報の参照、説明ビデオの視聴、Slack チャネルへのアクセスなどが可能です。

Catalog から Microclimate をインストールする⽅法について詳しくは、Installing Microclimate in IBM Cloud Privateを参照してください。

MongoDB

MongoDB は、クロスプラットフォームの⽂書指向のデータベースです。 MongoDB は NoSQL データベースに分類され、従来型の表ベースのリレーショナル・データベース構造を避け、動的スキーマを使⽤した JSON のような⽂書を使⽤します。この構造により、特定のタイプのアプリケーションにおけるデータの統合が容易化および加速します。

MongoDB Community Edition を使⽤して、アプリケーションを設計、ビルド、プロトタイプ化できます。詳しくは、MongoDB を参照してください。

IBM® Cloud Private での MongoDB Community Edition のインストールについて詳しくは、Deploy MongoDB into IBMCloud Private を参照してください。

PostgreSQL

PostgreSQL はオープン・ソースのオブジェクト・リレーショナル・データベースです。

IBM® Cloud Private での PostgreSQL のインストールについて詳しくは、Deploy PostgreSQL into IBM Cloud Private を参照してください。

Skydive

Skydive は、オープン・ソースのリアルタイム・ネットワーク・トポロジーおよびプロトコル・アナライザーです。ネットワーク・インフラストラクチャーで何が起きているのかを理解する包括的な⼿段を提供します。 Skydive エージェントがトポロジー情報およびフローを収集し、詳細な分析のために中央のアナライザーに転送します。


https://www.ibm.com/support/knowledgecenter/SS8NLW_12.0.0/com.ibm.watson.wex.ee.doc/t_onewex_install_icp.html

https://microclimate-dev2ops.github.io/

https://microclimate-dev2ops.github.io/installicp

https://www.mongodb.com/

https://developer.ibm.com/recipes/tutorials/deploy-mongodb-into-ibm-cloud-private/

https://developer.ibm.com/recipes/tutorials/deploy-postgresql-into-ibm-cloud-private/

Skydive を使⽤して、IBM® Cloud Private ネットワークをデバッグ、トラブルシューティング、および探索できます。詳しくは、Skydive Docs を参照してください。

IBM Cloud Private での Skydive のインストールについて詳しくは、Deploy Skydive into IBM Cloud Private を参照してください。

IBM® Cloud Private Cloud Foundry プラットフォーム

IBM Cloud Private Cloud Foundry プラットフォームは、IBM Cloud および IBM Cloud Dedicated で利⽤できるのと同じレベルのアプリケーション機能をデータ・センターにもたらします。これは、VMware vSphere で実⾏できます。

IBM 認定リリースを受け取り続けながら、IBM またはコミュニティーのリリースを使⽤して、Cloud Foundry を拡張できます。この機能により、Cloud Foundry デプロイメントにいつも存在しているとは限らない新機能や特殊機能を使⽤できるようになります。

IBM Cloud Private バージョン 2.1.0.3 で使⽤可能な IBM Cloud Private Cloud Foundry は、Cloud Foundry バージョン270 を提供します。

オファリング

IBM Cloud Private Cloud Foundry は、2 つのモード (開発者モードとエンタープライズ・モード) でデプロイできます。開発者モードで使⽤されるフットプリントは⼩さく、製品を把握するのに適しています。この場合でも、エンタープライズ・インフラストラクチャーにデプロイされますが、フットプリントは最⼩限に抑えられています。エンタープライズ・モードでは、すべてのコンポーネントを 2 つまたは 3 つのノード・クラスターにデプロイします。このデプロイメント・モデルでは、Infrastructure as a Service (IaaS) の⾼可⽤性 (HA) によって提供される保護に加え、2 つ⽬の保護レイヤーを提供し、確実にワークロードが実⾏され続けるようにします。 HA プラットフォームの初期設定後、特定の要件に合わせて、そのノードを拡張または削減できます。

これらのデプロイメント・オプションはいずれも、IBM パスポート・アドバンテージから単⼀バイナリー・ファイルとして⼊⼿可能であり、AirGap シナリオをサポートします。インストーラーは⼗分に⼩さいため、Docker を使⽤して⼩規模仮想マシン (VM) で実⾏可能です。 VM は、個別のコンピューターで実⾏しても、エンタープライズ・インフラストラクチャーで実⾏しても構いません。

機能

IBM Cloud Private Cloud Foundry

Cloud Foundry Diego アーキテクチャーに基づいて構築Docker 化されたインストールおよび更新ツールを使⽤IBM の IBM® Cloud Private Cloud Foundry ops console が含まれており、それによって Cloud Foundry デプロイメントのモニター、問題の検出、その問題の修復、環境のデバッグが可能

組み込みの UAA や企業 LDAP など、複数の認証オプションを提供IBM の NodeJS、Liberty、Swift に加え、Cloud Foundry コミュニティー・ビルドパックを利⽤可能以下のユーザー・カスタマイズが可能

Director または Cloud Foundry デプロイメント構成の変更 (設定の変更、リリースの追加または削除)ビルドパックの追加または削除

証明書、秘密、パスワードの変更

カスタマイズされた Stemcell の使⽤既存のロギング・サービスおよびモニター・サービスへの接続、あるいはCatalogにある IBM CloudPrivate サービスの使⽤

What's new in IBM Cloud Private Cloud Foundry バージョン 2.1.0.3IBM Cloud Private Cloud Foundry のインストールの準備


http://skydive-project.github.io/skydive/

https://developer.ibm.com/recipes/tutorials/deploy-skydive-into-ibm-cloud-private/


IBM Cloud Private Cloud Foundry のインストールIBM Cloud Private Cloud Foundry のアップグレードIBM Cloud Private Cloud Foundry のアンインストールIBM Cloud Private Cloud Foundry のための認証の構成IBM® Cloud Private Cloud Foundry での拡張機能の使⽤{{site.data.keyword.icpcf-notm}} コンソールの構成IBM® Cloud Private Cloud Foundry ops console のインストールIBM® Cloud Private Cloud Foundry ops console の使⽤IBM Cloud Private Cloud Foundry のためのドメイン・ネーム・サービス解決の構成別のデータベースを使⽤するための Director の構成Diego セルの数を増やすIBM® Cloud Private Cloud Foundry ops console ⽤のコマンド・ライン・インターフェースIBM® Cloud Private Cloud Foundry との統合の構成IBM Cloud Private Cloud Foundry ⽤アプリケーションのための信頼証明書の構成IBM Cloud Private Cloud Foundry でのビルドパックの使⽤IBM Cloud Private Cloud Foundry のトラブルシューティング

IBM® Cloud Private Cloud Foundry バージョン 2.1.0.3 の新機能

このリリースで追加、変更、改善、または⾮推奨化された内容の概要を簡単に⽰します。

主要な機能拡張

IBM Cloud Private Cloud Foundry バージョン 2.1.0.3 では、IBM Cloud Private Cloud Foundry コンソールのテクニカル・プレビューが導⼊されています。 IBM Cloud Private Cloud Foundry コンソールは、Cloud Foundryアプリケーションおよびバインド済みサービスを作成および管理するために使⽤します。

コンテナー間ネットワーキングは、Gorouter を経由せずにアプリケーション・コンテナー間の通信を可能にする新機能です。コンテナー・ネットワーキングは、アプリケーション・ポリシーを使⽤して、コンテナーが相互に通信する⽅法を制御します。ポリシーは動的に定義できます。詳しくは、Understanding Container-to-Container Networking を参照してください。Blobstore が、NFS から、よりセキュアで管理しやすいサーバーである WebDAV に移⾏されました。 WebDAVでは実際のデータ・マイグレーションが関係しないため、Cloud Foundry には NFS よりも WebDAV プロトコルが適しています。 Cloud コントローラーは、nfs-mounter を使⽤する代わりに、WebDAV プロトコルを使⽤して Blobstore にアクセスするようになりました。Cloud Foundry の DNS 名を公開するために、bosh-dns を使⽤して Director が構成されます。ローカル DNSサーバーがすべての Cloud Foundry 仮想マシン上で稼働し、dns-aware-bosh agent を使⽤してそのデータを Director から複製します。これにより、単⼀障害点としての、Director PowerDNS への仮想マシンの依存関係が取り除かれます。詳しくは、 Native DNS Support にアクセスしてください。BOSH バックアップおよびリストアが使⽤可能です。詳しくは、BOSH Backup and Restore を参照してください。

UAADB、CCDB、Director、およびデプロイメントのバックアップが使⽤可能です。詳しくは、『IBM® CloudPrivate Cloud Foundry のバックアップの構成』を参照してください。アベイラビリティー・ゾーンで複数の vSphere クラスターおよびポート・グループを管理して、⾼可⽤性分散デプロイメントを作成できます。アベイラビリティー・ゾーンにより、IBM Cloud Private Cloud Foundry デプロイメントのフォールト・トレランスおよび⾼可⽤性を実現できます。詳しくは、『IBM Cloud Private CloudFoundry のアベイラビリティー・ゾーンの構成』を参照してください。

その他の機能拡張

Cloud Foundry が、270.29 270 にアップグレードされました。


https://docs.cloudfoundry.org/concepts/understand-cf-networking.html

https://bosh.io/docs/dns/

https://docs.cloudfoundry.org/bbr/

ビルドパック検出パフォーマンスを改善するために、ビルドパックの推奨順序があります。順序を変更した場合、新規順序が維持されます。

すべての Cloud Foundry および Diego リリースが、Stemcell バージョン 3468.20 でプリコンパイルされています。これにより、デプロイメントおよびアップグレードの時間が 20 から 30% 短縮されます。統合された Bosh os-conf-release パッケージが存在します。これを使⽤して、VMware 時刻同期を有効にすることができます。 VMware 時刻同期は、os-conf-release パッケージを使⽤することで、BOSH がデプロイされたすべての VM でデフォルトで有効になります。ホストと外部 NTP サーバーとの時刻同期が有効になっていることを確認する必要があります。

変更された内容

IBM Cloud Private Cloud Foundry バージョン 2.1.0.3 の導⼊に伴い、以下のパッケージのバージョンが変更されました。

CloudFoundry cf-release は 270.29 にアップグレードされました。Director は 264.7 にアップグレードされました。Stemcell は 3468.20 にアップグレードされました。bosh-vsphere-cpi は 47 にアップグレードされました。bosh-openstack-cpi は 37 にアップグレードされました。cf-networking リリース 1.12.0bosh-dns リリース 1.3.0OpenStack テクノロジー・プレビュー・コード

以前のバージョン 2.1.0.2 の IBM Cloud Private Cloud Foundry からバージョン 2.1.0.3 に移⾏する場合のアップグレード⼿順が変更されています。『IBM® Cloud Private Cloud Foundry のアップグレード』を必ずお読みください。

IBM ビルドパック

SDK for NodeJS がバージョン 3.1.4 からバージョン v3.19-20180314-1533 にアップグレードされています。Liberty for Java がバージョン 3.13 からバージョン v3.19-20180313-1017 にアップグレードされています。

IBM® Cloud Private Cloud Foundry のインストールの準備

IBM Cloud Private Cloud Foundry をインストールする前にクラウドを準備する必要があります。

IBM Cloud Private Cloud Foundry は、プライベート VMware vSphere クラウドまたは OpenStack でインストールできます。

1. IBM Cloud Private Cloud Foundry のインストール⽤にクラウドを準備します。1. VMware vSphere については、『IBM Cloud Private Cloud Foundry の VMware 要件』を参照してください。

2. OpenStack については、『IBM Cloud Private Cloud Foundry の OpenStack 要件』を参照してください。

2. ご使⽤の環境⽤の証明書を指定します。『IBM Cloud Private Cloud Foundry の証明書の指定』を参照してください。

IBM Cloud Private Cloud Foundry の VMware 要件 IBM Cloud Private Cloud Foundry の OpenStack 要件 IBM Cloud Private Cloud Foundry の証明書の指定

IBM® Cloud Private Cloud Foundry の VMware 要件


インターネットに接続されているかどうかに関係なく、IBM Cloud Private Cloud Foundry は、VMware vSphere 5.5または 6.X インスタンスにインストールできます。

VMware インスタンスに関する必要な情報 VMware 許可の構成 IBM Cloud Private Cloud Foundry 開発者版のインストールの VMware サイズ要件 IBM Cloud Private Cloud Foundry エンタープライズ版のインストールの VMware サイズ要件

VMware インスタンスに関する必要な情報

IBM® Cloud Private Cloud Foundry を VMware にインストールするには、vSphere 5.5 または 6.x インスタンスが特定の要件を満たしている必要があり、また VMware インスタンスに関する情報が必要になります。

必要な VMware vSphere 情報

vSphere バージョン 5.5、6.0、または 6.5 がサポートされます。vCenter IP アドレスvCenter ユーザー名vCenter パスワードデプロイメントの親である、vSphere Client に表⽰されるデータ・センター名データ・センターの⼦である、vSphere Client で表⽰されるクラスター名(オプション) クラスターの⼦である、vSphere Client で表⽰されるリソース・プール名Stemcell およびすべての仮想マシンをホストする 1 つ以上のデータ・ストア永続ディスクのフォルダー名

BOSH Director および Cloud Foundry 仮想マシンが接続するポート・グループ名BOSH Director および Cloud Foundry 仮想マシンの親である仮想マシン・フォルダー名 (「Virtual Machines &Templates」vSphere Client ビュー)

必要なネットワーク情報

使⽤するサブネット (172.12.34.0/24 など)。指定サブネットからのゲートウェイ。

1 つ以上の DNS サーバー。1 つ以上の NTP サーバー。選択したサブネットの IP アドレス。開発者版のインストールの場合、25 個の IP アドレスが必要です。エンタープライズ版のインストールの場合、40 個の IP アドレスが必要です。

必要なネットワーク経路

インストーラーは、IP アドレスまたは完全修飾ドメイン・ネーム (FQDN) を使⽤して vCenter インスタンスに到達できるとともに、選択したクラスター内のすべての ESXi に到達できる必要があります。インストーラーは、vCenter に⽰される IP アドレスまたは FQDN を使⽤して、ESXi に到達しようとします。 ESXi が到達可能でない場合、デプロイメントは失敗します。

インストーラーは、BOSH Director をデプロイします。 Director はインストーラーと同じ vCenter と ESXi の経路を使⽤します。

ほとんどのデプロイメントでは、LDAP、プロキシー、サービスなどの追加の経路が必要です。

必要な証明書

⾃⼰署名ワイルドカード証明書がインストール時に⽣成されます。独⾃の証明書を提供することもできます。


VMware 許可の構成

root/管理者アカウントを使⽤しない場合、IBM® Cloud Private Cloud Foundry を VMware にインストールする前に、以下の許可を構成する必要があります。

1. 2 つの役割を作成します。最初の役割に以下の許可を付与します。

データ・ストア: 低レベル・ファイル操作データ・ストア: 仮想マシン・ファイルの更新vApp: インポート

2 番⽬の役割に以下の許可を付与します。グローバル: カスタム属性の管理

仮想分散スイッチ・ネットワークを使⽤している場合、役割に以下の許可を付与します。dvPort グループ: 変更

2. vCenter ユーザーを作成します。3. vSphere コンポーネント・リストに関する以下の役割をユーザーに割り当てます。

表 1. VMware ユーザー許可vSphere Client ビュー vSphere コンポーネント役割その他

Hosts and Clusters VCenter 2 番⽬のユーザー定義の役割伝搬なしHosts and Clusters データ・センター最初のユーザー定義の役割伝搬なし

Hosts and Clusters クラスター管理者伝搬あり

VMs and Templates 仮想マシン・フォルダー管理者伝搬あり

Datastores and Datastore Clusters各データ・ストア管理者伝搬あり

1. vSwitch ネットワークを使⽤している場合、以下のようにします。適切なポート・グループに administrator 役割を割り当てます。「Propagate to Child Objects」が選択されていない状態にします。

2. 仮想分散スイッチ (vDS) ネットワークを使⽤している場合、以下のようにします。vDS スイッチをフォルダーに配置します。vDS 親フォルダーに新規ユーザーの Read-only 役割を割り当て、「Propagate to Child Objects」を選択します。

適切なポート・グループに administrator 役割を割り当てます。「Propagate to Child Objects」が選択されていない状態にします。

IBM® Cloud Private Cloud Foundry 開発者版のインストールのVMware サイズ要件

IBM Cloud Private Cloud Foundry の開発者版を VMware にインストールするには、vSphere インスタンスが以下のサイズ要件を満たしている必要があります。

データ・ストア要件では、uiconfig_vmware_template.yml のパラメーター vmware_disk_type の値を preallocated に設定しているものと想定しています。 thin のデフォルトの vmware_disk_type 値を使⽤している場合、初期デプロイメントで必要になるデータ・ストアの量は少なくなります。ただし、必要なデータ・ストア・スペース量は時間とともに増⼤し、指定サイズに到達する可能性があります。

開発者版のセル構成:

vCPU: 2 メモリー: 32768 MB


ストレージ: 360.8 GB = 369,424 MB = (32768 MB vSphere スワップ・ファイル + 300,000 MB 一時ディスク + 3072 MB システム・ディスク)x1.10 = (メモリー+ストレージ) x

開発者モードでのサイジング

総計

最⼩合計ストレージは 1128.531 GB最⼩合計メモリーは 114.000 GB最⼩合計 vCPU は 48

デプロイメント当たりの総計

デプロイメントインスタン

ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク

(MB)オーバーヘッド・ディスク

(MB)Director 1 4 8192 51200 102400 27750Cloud Foundry 8 20 23552 92160 59392 68094Diego 8 16 70656 386016 2048 143560CFP UI 1 2 8192 24576 65536 21401Compilationworker

3 6 6144 24288 0 19323

総計 21 48 116736 646112 229376 280128

詳細なサイジング

Director のサイジング

VM ジョブインスタンス vCPUメモリー VM ディスク (MB)永続ディスク (MB)オーバーヘッド・ディスク (MB)bosh 1 4 8192 51200 102400 27750合計 1 4 8192 51200 102400 27750

Cloud Foundry のサイジング

VM ジョブインスタン

ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク


(MB)consul 1 4 8192 24576 4096 15257debian_nfs_server

1 2 1024 6144 24576 7577

nats 1 4 8192 24576 10240 15872ccdb_ng 1 2 1024 6144 10240 6144uaadb 1 2 1024 6144 10240 6144router 1 2 1024 6144 0 5120cc_core 1 2 2048 12288 0 6860ha_proxy 1 2 1024 6144 0 5120合計 8 20 23552 92160 59392 68094

Diego のサイジング


VM ジョブインスタンス vCPUメモリー VM ディスク (MB)永続ディスク (MB)オーバーヘッド・ディスク (MB)VM ジョブインスタンス vCPUメモリー VM ディスク (MB)永続ディスク (MB)オーバーヘッド・ディスク (MB)database 1 2 1024 12288 0 5734brain 1 2 1024 6144 0 5120policy_server 2 2 16384 24576 1024 23961cell 1 2 32768 300000 0 69424cc_bridge 1 2 1024 6144 0 5120route_emitter 1 2 1024 6144 0 5120access 1 2 1024 6144 0 5120合計 8 16 70656 386016 2048 143560

CFP UI のサイジング

VM ジョブインスタンス vCPUメモリー VM ディスク (MB)永続ディスク (MB)オーバーヘッド・ディスク (MB)docker 1 2 8192 24576 65536 21401合計 1 2 8192 24576 65536 21401

Compilation worker のサイジング


ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク


(MB)Compilationworker

3 2 2048 8096 0 6441

合計 3 6 6144 24288 0 19323

IBM® Cloud Private Cloud Foundry エンタープライズ版のインストールの VMware サイズ要件

IBM Cloud Private Cloud Foundry のエンタープライズ版インストール済み環境を VMware にインストールするには、vSphere インスタンスが以下のサイズ要件を満たしている必要があります。

通常のアプリケーション負荷では、このインフラストラクチャー・テンプレートは、最⼤ 1 TB までのセル・メモリーをサポートします。

⾼可⽤性インフラストラクチャー⽤の要件に加え、アプリケーションをホストするためのセル・リソースを⽤意する

必要があります。アプリケーション要件およびハードウェア・プロファイルに合わせて、これらのサイズ要件を変更できます。

データ・ストア要件では、uiconfig_vmware_template.yml のパラメーター vmware_disk_type の値を preallocated に設定しているものと想定しています。 thin のデフォルトの vmware_disk_type 値を使⽤している場合、初期デプロイメントで必要になるデータ・ストアの量は少なくなります。ただし、必要なデータ・ストア・スペース量は時間とともに増⼤し、指定サイズに到達する可能性があります。

標準セル構成:

vCPU: 4 メモリー: 32768 MB ストレージ: 360.8 GB = 369,424 MB = (32768 MB vSphere スワップ・ファイル + 300,000 MB 一時ディスク + 3072 MB システム・ディスク)x1.10 = (メモリー+ストレージ) x オーバーヘッド

エンタープライズでのサイジング


総計




ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク



5 10 10240 40480 0 32205

総計 35 108 329728 1440736 903168 682540






ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク


(MB)nfs_WAL_server 1 4 8192 24576 307200 45568consul 3 4 8192 24576 20480 16896debian_nfs_server

1 4 8192 24576 262144 41062



VM ジョブインスタンス vCPUメモリー VM ディスク (MB)永続ディスク (MB)オーバーヘッド・ディスク (MB)database 2 4 16384 32768 0 24678brain 2 2 8192 24576 0 14848policy_server 2 2 16384 24576 1024 23961cell 1 4 32768 300000 0 69424


VM ジョブインスタンス vCPUメモリー VM ディスク (MB)永続ディスク (MB)オーバーヘッド・ディスク (MB)cc_bridge 2 2 16384 32768 0 24678route_emitter 2 2 8192 24576 0 14848access 2 2 8192 24576 0 14848合計 13 32 180224 627680 2048 305146





ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク



5 2 2048 8096 0 6441

合計 5 10 10240 40480 0 32205

IBM® Cloud Private Cloud Foundry の OpenStack 要件

インターネットに接続されているかどうかに関係なく、IBM Cloud Private Cloud Foundry は、OpenStack インスタンスにインストールできます。

OpenStack インスタンスに関する必要な情報IBM Cloud Private Cloud Foundry 開発者版のインストールの OpenStack サイズ要件IBM Cloud Private Cloud Foundry エンタープライズ版のインストールの OpenStack サイズ要件

OpenStack インスタンスに関する必要な情報

IBM® Cloud Private Cloud Foundry を OpenStack にインストールするには、OpenStack インスタンスが特定の要件を満たしている必要があり、また OpenStack インスタンスに関する情報が必要になります。

必要な OpenStack パラメーターの理解

OpenStack UI から、「プロジェクト」>「コンピュート」>「アクセスとセキュリティ」>「API アクセス」>「OpenStack RC v3 ファイルのダウンロード (Download OpenStack RC File v3)」を選択して、以下のパラメーターに関する詳細情報をダウンロードします。

API バージョン 3 が必要OpenStack 認証 URLOpenStack ユーザー名OpenStack パスワードAPI バージョンユーザー・ドメイン名

プロジェクト名

プロジェクト ID地域名


インターフェース

ネットワーク IDアベイラビリティー・ゾーン

OpenStack CA 証明書OpenStack 鍵ペア名OpenStack 鍵ペア秘密鍵OpenStack セキュリティー・グループ

必要なフレーバーの設定

IBM® Cloud Private Cloud Foundry デプロイメントでは、各種タイプの仮想マシンに関する特定の CPU、メモリー、およびディスクのサイジングが必要です。 OpenStack では、これらをフレーバーとして定義します。デフォルトでは、IBM® Cloud Private Cloud Foundry はインストール時にフレーバーを作成します。新規フレーバーを作成できない場合は、以下のステップを実⾏して、フレーバーのマッピングを指定します。

1. ファイル /<installation_directory>/uiconfig_openstack_template.yml にナビゲートします。flavors キーを⾒つけます。

# flavors: # icpcf_default: <your_flavor> # icpcf_director: <your_flavor> # icpcf_coreNode: <your_flavor> # icpcf_cc_core: <your_flavor> # icpcf_nats: <your_flavor> # icpcf_consul: <your_flavor> # icpcf_router: <your_flavor> # icpcf_logger: <your_flavor> # icpcf_brain: <your_flavor>

2. ポンド記号 (#) を削除することで、# flavors: ⾏およびすべての⼦キーのコメントを外します。

3. フレーバー・キーごとに、そのインスタンス・タイプに必要な CPU、メモリー、およびディスクの要件に対する合致度が最も⾼い既存の OpenStack フレーバーへのマッピングを指定します。

OpenStack サイズ要件について詳しくは、『IBM Cloud Private Cloud Foundry 開発者版のインストールのOpenStack サイズ要件』および『IBM Cloud Private Cloud Foundry エンタープライズ版のインストールのOpenStack サイズ要件』を参照してください。

必要なキー・ペアの設定

OpenStack UI で、以下のように、適切な「ドメイン」および「プロジェクト」を選択します。

1. 左側のナビゲーション・パネルから「プロジェクト」を選択します。2. 左側のナビゲーション・パネルから「コンピュート」を選択します。3. 「アクセスとセキュリティー」を選択します。4. 「キーペア」タブを選択します。5. 「キーペアの作成」をクリックします。6. 鍵ペアに bosh と名前を付け、「キーペアの作成」をクリックします。7. bosh.pem ファイルを保存します。

必要なセキュリティー・グループの作成

OpenStack UI で、適切な「ドメイン」および「プロジェクト」が選択された状態で、以下の⼿順を実⾏します。

1. 左側のナビゲーション・パネルから「プロジェクト」を選択します。2. 左側のナビゲーション・パネルから「コンピュート」を選択します。3. 「アクセスとセキュリティー」を選択します。


4. 「セキュリティーグループ」を選択します。5. 「セキュリティーグループの作成」をクリックします。6. セキュリティー・グループに bosh と名前を付け、BOSH Security Group という説明を追加します。7. 「セキュリティーグループの作成」をクリックします。8. 「BOSH セキュリティーグループ」を選択し、「ルールの編集 (Edit Rules)」をクリックします。9. 「ルールの追加」をクリックします。

10. 以下のルールを「BOSH セキュリティーグループ」に追加します。

⽅向イーサネット・タイプ IP プロトコルポート範囲リモート⽬的

受信 IPv4 TCP 22 0.0.0.0/0 (CIDR) CLI からの SSH アクセス受信 IPv4 TCP 80 0.0.0.0/0 (CIDR) haproxy へのアクセス受信 IPv4 TCP 443 0.0.0.0/0 (CIDR) haproxy へのアクセス受信 IPv4 TCP 2222 0.0.0.0/0 (CIDR) Cloud Foundry SSHIngress IPv4 TCP 4222 0.0.0.0/0 (CIDR) NATS受信 IPv4 TCP 4443 0.0.0.0/0 (CIDR) Cloud Foundry コンソール受信 IPv4 TCP 6868 0.0.0.0/0 (CIDR)ブートストラッピング⽤ BOSH AgentIngress IPv4 TCP 8443 0.0.0.0/0 (CIDR) UAA API受信 IPv4 TCP 25250 0.0.0.0/0 (CIDR) Blobstore

受信 IPv4 TCP 25555 0.0.0.0/0 (CIDR) BOSH Director API

受信 IPv4 TCP 25777 0.0.0.0/0 (CIDR)レジストリー受信 IPv4 TCP 1-65535 bosh 管理アクセスとデータ・アクセス

送信 IPv4 任意 - 0.0.0.0/0 (CIDR)

送信 IPv6 任意 - ::/0 (CIDR)

Director、HA Proxy、および Console UI の必要な浮動 IP アドレスの割り振り

BOSH Director、HA Proxy、および Console UI のそれぞれに、浮動 IP アドレスが必要です。 OpenStack UI で、適切な「ドメイン」および「プロジェクト」が選択された状態で、以下の⼿順を実⾏します。

1. 左側のナビゲーション・パネルから「プロジェクト」を選択します。2. 左側のナビゲーション・パネルから「コンピュート」を選択します。3. 「アクセスとセキュリティー」を選択します。4. 「Floating IP」タブを選択します。5. 「Floating IP の確保」を選択します。6. 「プール」ドロップダウン・メニューから「External」を選択します。7. 「IP の確保」をクリックします。8. IP が割り振られたら、ポップアップ・ウィンドウに表⽰された IP アドレスを書き留めておいてください。9. このプロセスを繰り返して、必要な浮動 IP アドレスの番号を割り振ります。

必要なネットワーク情報

以下のネットワーク情報を指定する必要があります。

使⽤するサブネット (10.10.25.0/24 など)。少なくとも 64 個の IP アドレスが含まれた範囲を指定する必要があります。

指定サブネットからのゲートウェイ

1 つ以上の DNS サーバー1 つ以上の NTP サーバー選択したサブネットの IP アドレス。開発者版のインストールでは 25 個の IP アドレス、エンタープライズ版のインストールでは 40 個の IP アドレスが必要です。


必要なネットワーク経路の理解

インストーラーでは、IP アドレスまたは完全修飾ドメイン・ネーム (FQDN) を使⽤して OpenStack インスタンスに到達する必要があります。

インストーラーは、BOSH Director をデプロイします。 Director はインストーラーと同じ OpenStack の経路を使⽤します。

ほとんどのデプロイメントでは、LDAP、プロキシー、サービスなどの追加の経路が必要です。

必要な証明書

⾃⼰署名ワイルドカード証明書がインストール時に⽣成されます。独⾃のものを提供することもできます。

IBM® Cloud Private Cloud Foundry 開発者版のインストールのOpenStack サイズ要件

IBM Cloud Private Cloud Foundry のエンタープライズ版インストール済み環境を OpenStack にインストールするには、OpenStack インスタンスが以下のサイズ要件を満たしている必要があります。




標準セル構成:

vCPU: 4 メモリー: 32768 MB ストレージ: 376.2 GB = 385,228 MB = (317,440 MB 永続ディスク + 67,788 MB オーバーヘッド)

開発者モードでのサイジング

総計




ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク



5 10 10240 92160 0 20480



ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク


(MB)

総計 21 48 88064 823296 227328 193730






ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク


(MB)consul 1 4 8192 34816 4096 12902debian_nfs_server

1 2 1024 16384 24576 5222



VM ジョブインスタンス vCPUメモリー VM ディスク (MB)永続ディスク (MB)オーバーヘッド・ディスク (MB)database 1 2 1024 22528 0 3379brain 1 2 1024 16384 0 2764cell 1 2 32768 317440 0 67788cc_bridge 1 2 1024 16384 0 2764route_emitter 1 2 1024 16384 0 2764access 1 2 1024 16384 0 2764合計 6 12 37888 405504 0 82223





ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク


(MB)



ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク



5 2 2048 18432 0 4096

合計 5 10 10240 92160 0 20480

IBM® Cloud Private Cloud Foundry エンタープライズ版のインストールの OpenStack サイズ要件

IBM Cloud Private Cloud Foundry のエンタープライズ版インストール済み環境を OpenStack にインストールするには、OpenStack インスタンスが以下のサイズ要件を満たしている必要があります。




標準セル構成:

vCPU: 4 メモリー: 32768 MB ストレージ: 376.2 GB = 385,228 MB = (317,440 MB 永続ディスク + 67,788 MB オーバーヘッド)

OpenStack のエンタープライズでのサイジング

総計




ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク



5 10 10240 92160 0 20480

総計 33 104 296960 1812480 901120 554989




VM ジョブインスタンス vCPUメモリー VM ディスク (MB)永続ディスク (MB)オーバーヘッド・ディスク (MB)VM ジョブインスタンス vCPUメモリー VM ディスク (MB)永続ディスク (MB)オーバーヘッド・ディスク (MB)bosh 1 4 8192 34816 102400 22732合計 1 4 8192 34816 102400 22732



ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク


(MB)nfs_WAL_server 1 4 8192 34816 307200 43212consul 3 4 8192 34816 20480 14540debian_nfs_server

1 4 8192 34816 262144 38707



VM ジョブインスタンス vCPUメモリー VM ディスク (MB)永続ディスク (MB)オーバーヘッド・ディスク (MB)database 2 4 16384 43008 0 22323brain 2 2 8192 34816 0 12492cell 1 4 32768 317440 0 67788cc_bridge 2 2 16384 43008 0 22323route_emitter 2 2 8192 34816 0 12492access 2 2 8192 34816 0 12492合計 11 28 147456 698368 0 232032





ス

vCPU

メモリ

ー

VM ディスク(MB)

永続ディスク



5 2 2048 18432 0 4096

合計 5 10 10240 92160 0 20480

IBM® Cloud Private Cloud Foundry の証明書の指定

IBM Cloud Private Cloud Foundry をインストールする前に、独⾃の証明書を指定できます。


独⾃の認証局を使⽤して必要な証明書を作成するか、外部認証局を使⽤して証明書を⽣成するか、⼿動で証明書を作

成できます。ドメインの証明書は、2 つの部分 (ルート証明書とキー) で構成されます。

独⾃の証明書を使⽤しなかった場合、uiconfig.yml ファイルで指定したアプリケーション・ドメイン bluemix_app_domain および環境ドメイン bluemix_env_domain の値を使⽤して、インストール中に証明書が作成されます。

必要な証明書を⼿動で⽣成するには、以下のようにします。

注: アプリケーション・ドメインと環境ドメインの両⽅でキーが必要であるため、このプロセスは 2 回実⾏する必要があります。

環境ドメイン bluemix_env_domain の場合、証明書 *.management.mycompany.com を作成します。アプリケーション・ドメイン bluemix_app_domain の場合、証明書 *.apps.mycompany.com を作成します。

1. 以下のように、ルート証明書を⽣成します。

openssl genrsa -des3 -out rootCA.key 2048

証明書のパスワードを指定します。

証明書は、rootCA.key ファイルに保管されます。

2. 以下のように、証明書に⾃⼰署名します。

openssl req -x509 -new -nodes -key rootCA.key -days 1024 -out rootCA.pem

プロンプトが出されたら、証明書のパスワードおよび組織の情報を指定します。

この証明書は、1024 ⽇で有効期限が切れます。

署名済み証明書は、rootCA.pem ファイルに保管されます。

3. セキュアな場所に rootCA.key 証明書ファイルおよびそのパスワードを保管します。

4. ⾃⼰署名証明書のドメイン・キーを⽣成します。

openssl req -new -newkey rsa:2048 -nodes -out star_<your_domain>.csr -keyout star_<your_domain>.key -subj "/C=<country_code>/ST=<state>/L=<locality>/O=<organization_name>/CN=*.<your_domain>"

このコマンドで、<your_domain> は Cloud Foundry インスタンスのドメイン (inter.mycompany.com など)であり、subj パラメーターには以下のデータが含まれます。

<country_code> は、2 ⽂字の国名です。<state> は、都道府県名です。<locality> は、市や町など、地域の名前です。<organization_name> は、組織 (会社) の名前です。 

star_<your_domain>.csr および star_<your_domain>.key ファイルが作成されます。

6. 以下のように、ドメイン証明書を⽣成します。

1. 以下のように、ドメイン証明書拡張ファイル ext_v3 を作成します。


[ v3_req ] subjectAltName=DNS:*.<your_domain>,DNS:<your_domain>

このコマンドにより、ext_v3 ファイルが作成されます。

2. 以下のように、ドメイン証明書を⽣成します。

openssl x509 -req -in star_<your_domain>.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out star_<your_domain>.crt -days 500 -extensions v3_req -extfile ext_v3

ここで、ext_v3 は作成したドメイン証明書拡張ファイルの名前であり、<your_domain> は CloudFoundry インスタンスのドメインです。

この証明書は、500 ⽇で有効期限が切れます。

このコマンドにより、star_<your_domain>.crt ファイルが作成されます。

7. インストール・スクリプトを実⾏した後に、証明書の値を Cloud Foundry に指定する必要があります。インストール・コマンドで参照される uiconfig-templates.yml ファイルの uiconfig セクションに、アプリケーション・ドメインと環境ドメインの両⽅について、star_<your_domain>.crt、star_<your_domain>.key、および rootCA.pem ファイルの内容を配置する必要があります。『IBM®Cloud Private Cloud Foundry のインストール』を参照してください。

値を uiconfig-templates.yml ファイルに⼿動で追加します。 launch_deployment.sh -c UICONFIG_TEMLATE_FIL コマンドで参照される uiconfig-templates.yml ファイルに、アプリケーション・ドメインと環境ドメインの両⽅について、star_<your_domain>.crt、star_<your_domain>.key、および rootCA.pem ファイルの内容を配置します。

uiconfig: bluemix_apps_domain_cert: |+ -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- bluemix_apps_domain_cert_rsa_key: |+ -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- bluemix_env_domain_cert: |+ -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- bluemix_env_domain_cert_ca: |+ -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- bluemix_env_domain_cert_rsa_key: |+ -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY-----

注: ⽰される順序は、維持する必要があります。 1 つ以上の値セットを含めて、複数のドメインを有効にすることができます。

1. bluemix_apps_domain_cert および bluemix_env_domain_cert は、star_<env_domain/app_domain>.crt ファイルの内容です。

2. bluemix_apps_domain_cert_ca および bluemix_env_domain_cert_ca は、rootCA.pem ファイルの内容です。

3. bluemix_apps_domain_cert_rsa_key および bluemix_env_domain_cert_rsa_key は、star_<env_domain/app_domain>.key ファイルの内容です。

以下のように、コマンド・ラインから値を指定します。

1. 以下のように、管理 (環境) 証明書を追加します。

./cm bmxconfig -m [--key star_<your_domain>.key] [--cert star_<your_domain>.crt] [--rootCA rootCA.pem]

1. 以下のように、アプリケーション証明書を追加します。


./cm bmxconfig -a [--key star_<your_domain>.key] [--cert star_<your_domain>.crt] [--rootCA rootCA.pem]

IBM Cloud Private Cloud Foundry のインストール

IBM® Cloud Private Cloud Foundry をダウンロードしてインストールするには、以下のステップを実⾏します。

インストール・ファイルをダウンロードする時間を含めず、インストールには約 2 から 3 時間かかります。

1. フルインストール・ファイルをパスポート・アドバンテージからダウンロードします (8 から 10 GB)。2. インターネット接続がないデータ・センターに IBM® Cloud Private Cloud Foundry をインストールするには、実動 Docker Community Edition (CE) および VMware 環境にアクセスできるサーバーにインストール・ファイルをコピーします。

3. Docker CE がまだインストールされていない場合は、Docker CE をインストールします。『Install Docker 』を参照してください。

4. インストール・ディレクトリーを作成します。5. フルインストール・ファイルをインストール・ディレクトリーに解凍します。6. インストール・ディレクトリーに移動します。7. インストール・ディレクトリーから Docker イメージをインポートします。

import_images.sh

8. インストール構成を保管するためのディレクトリーを作成します。このディレクトリーに少なくとも 35 GBのスペースを割り振る必要がありますが、最⼤で 100 GB のスペースが必要になる場合もあります。次のコマンドを実⾏します。

mkdir -p /home/user/data

9. 以下のように、インストール・スクリプトを実⾏します。

./launch.sh -n IBMCloudPrivate -b ./BOM.yml -c /home/user/data -e LICENSE=accept

上の例では、/home/user/data がインストール構成ディレクトリーです。

10. ご使⽤の IaaS インフラストラクチャーに応じて /<installation_directory>/uiconfig_vmware_template.yml ファイルまたは /<installation_directory>/uiconfig_openstack_template.yml ファイルを作成または変更し、vSphere または OpenStack のインフラストラクチャーに応じた値を指定します。

vSphere と OpenStack の両⽅に共通のパラメーターについては、『共通のパラメーター』を参照してください。

vSphere に固有のパラメーターについては、『vSphere のパラメーター』を参照してください。OpenStack に固有のパラメーターについては、『OpenStack のパラメーター』を参照してください。

11. DNS を構成します。『IBM® Cloud Private Cloud Foundry のためのドメイン・ネーム・サービス解決の構成』を参照してください。

12. 以下のように、デプロイメントを開始します。

./launch_deployment.sh -c your-uiconfig.yml

このコマンドによってデプロイメントが開始され、ログが表⽰されます。

13. ビルドパックをデプロイする場合は、DNS がセットアップされていて、api.BLUEMIX_ENV_DOMAIN および api.BLUEMIX_APPS_DOMAIN が解決可能であることを確認してください。

./create_buildpacks.sh




共通のパラメーター

インストール時に、/<installation_directory>/uiconfig_vmware_template.yml または /<installation_directory>/uiconfig_openstack_template.yml ファイルに以下のパラメーターを指定します。

これらのパラメーターは、vSphere と OpenStack の両⽅に共通です。

以下の例で、これらのパラメーターを⽰します。

uiconfig: #Infrastructure agnostic parameters. developer_mode: "false" main_user_name: "admin" main_user_password: "mypassword" diego_cell_instances: 1 bluemix_env_domain: "local.bluemix.net" bluemix_env_domain_cert: |+ -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- bluemix_env_domain_cert_ca: |+ -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- bluemix_env_domain_cert_rsa_key: |+ -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- bluemix_apps_domain: "local.mybluemix.net" bluemix_apps_domain_cert: |+ -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- bluemix_apps_domain_cert_rsa_key: |+ -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- ntp_servers: "ntp1,myntp2.com" subnet: "100.155.194.129/27" address_range: "100.15.194.130-100.15.194.155" external_dns: "100.12.13.14,100.12.13.15,100.12.13.16" gateway: "100.15.194.1" director_ip: "100.15.194.2" haproxy_ip: "100.15.194.3" console_ip: "100.15.194.4" #cloud configuration customization. #Uncomment the attribute 'cloud_config_custom' and add your customization in place of the example, if needed. #cloud_config_custom: | # --- # my_custom_yaml: my_custom_yaml #Cloud Foundry customization #Uncomment the attribute `cf_custom` and add your customization in place of the example, if needed. #cf_custom: | # --- # my_custom_yaml: my_custom_yaml #Diego customization #Uncomment the attribute `diego_custom` and add your customization in place of the example, if needed. #diego_custom: | # --- # my_custom_yaml: my_custom_yaml #Bosh director customization #Uncomment the attribute `director_custom` and add your customization in place of


the example, if needed. #director_custom: | # --- # my_custom_yaml: my_custom_yaml #Backups #Note: Most of the parameters are optional. bbr_backup: #Set the `customer_nfs_host`, `customer_nfs_path` and `customer_short_name` if you want the director and #deployment backups pushed to your own NFS server. #The NFS mount is built as <customer_nfs_host>:/<customer_nfs_path>/<customer_short_name> customer_nfs_host: "NFS IP or hostname" customer_nfs_path: "/bluemix_nfs" customer_short_name: "bluemix1" # director_backup: # Optional. Add this parameter if you want to change the default time for the director backup. # The default value is 2 AM in the nfs_WAL_server timezone. # scheduled: "* 2 * * *" # enable: "false" # The default value is true, which means that backups are executed. # nb_backups: "10" #Number of backup to keep on the nfs_WAL_server. The default value is 10. # max_log_size: "1048576" #Maximum log size before it rolls over (in bytes). The default value is 1048576 (1 MB). # nb_logs: "10" #Maximum number of logs to keep on the nfs_WAL_server. The default value is 10. # deployments_backup: # deployments: #Optional. Add this parameter if you want to change the default time for the Bluemix deployment backup. # The default value is 2:30 AM in the nfs_WAL_server timezone. # - name: Bluemix # enabled: "false" # The default value is true, which means that the backup runs. # nb_backups: "10" #Number of backups to keep on the nfs_WAL_server. The default value is 10. # max_log_size: "1048576" #Maximum log size before it rolls over (in bytes). The default value is 1048576 (1 MB) # nb_logs: "10" #Maximum number of logs to keep on the nfs_WAL_server. The default value is 10. # schedule: "* 6 * * *" db_nfs_copy: #Set the customer_nfs_host, customer_nfs_path and customer_short_name if you want the UAADB and #CCDB backups pushed to your own NFS server. #The NFS mount is built as <customer_nfs_host>:/<customer_nfs_path>/<customer_short_name> customer_nfs_host: "NFS server IP address or hostname" customer_nfs_path: "/bluemix_nfs" customer_short_name: "bluemix1"

developer_mode: 単⼀インスタンス・コンポーネントをデプロイするのか、エンタープライズ・クラスター化コンポーネントをデプロイするのかを指定します。有効な値は「true」または「false」です。main_user_name: Cloud Foundry CLI および API へのログインに使⽤するユーザー名。このユーザーは、管理者になります。

main_user_password: 管理者ユーザーのパスワード。diego_cell_instances: デプロイする Diego セルの数を指定します。各 Diego セルは、4 vCPU、32 GB のRAM、および 300 GB のディスク・スペースを使⽤します。⾼可⽤性エンタープライズ・デプロイメントの場合、2 つの Diego セルを使⽤する必要があります。


bluemix_apps_domain: アプリケーションのデプロイ先のデフォルト共有ドメイン。 bluemix_env_domainの値とは異なる値を指定する必要があります。

bluemix_apps_domain_cert: オプション。ワイルドカード・ドメイン証明書 (例えば、*.domain.com)。bluemix_apps_domain_cert_ca: オプション。ワイルドカード・アプリケーション・ドメイン・ルート証明書。

bluemix_apps_domain_cert_rsa_key: オプション。ワイルドカード・アプリケーション・ドメイン・キー。bluemix_env_domain: Cloud Foundry デプロイメントで使⽤される API および管理ドメイン。bluemix_apps_domain の値とは異なる値を指定する必要があります。bluemix_env_domain_cert: ワイルドカード・システム・ドメイン証明書。この値を指定することも、⾃動⽣成されたデータを使⽤することもできます。詳しくは、『IBM® Cloud Private Cloud Foundry の証明書の指定』を参照してください。

bluemix_env_domain_cert_ca: ワイルドカード・システム・ドメイン・ルート証明書。この値を指定することも、⾃動⽣成されたデータを使⽤することもできます。詳しくは、『IBM® Cloud Private Cloud Foundry の証明書の指定』を参照してください。

bluemix_env_domain_cert_rsa_key: ワイルドカード・システム・ドメイン・キー。この値を指定することも、⾃動⽣成されたデータを使⽤することもできます。詳しくは、『IBM® Cloud Private Cloud Foundry の証明書の指定』を参照してください。

ntp_servers: 仮想マシン (VM) の開始時に VM の時刻の同期に使⽤する NTP サーバー。スペースが含まれないコンマ区切りリストとしてサーバー名を指定します。

subnet: 192.168.52.0/24 など、Cloud Foundry をホストするサブネット。

注: 開発者版のインストールでは、25 個の IP アドレスが必要です。エンタープライズ版のインストールでは、少なくとも 40 個の IP アドレスが必要です。

gateway: Cloud Foundry が、指定したサブネットから他のサブネットまたはネットワークにトラフィックをルーティングするために使⽤する IP アドレス。

address_range: オプション。使⽤可能な IP アドレスの範囲を指定します。ゲートウェイは、⾃動的に使⽤不可と⾒なされます。値を指定しなかった場合、全サブネット範囲が使⽤可能になります。

例えば、ゲートウェイが 192.168.52.1 で、開発者版のインストールに .50 から .75 の IP アドレスを使⽤する場合、192.168.52.50-192.168.52.75 と指定します。各範囲をコンマで区切って、同じサブネット内の複数の範囲を指定できます。例: 192.168.52.50-192.168.52.65,192.168.52.70-192.168.52.80

external_dns: 会社、インターネット、および Cloud Foundry ワイルドカードの URL を解決する DNS サーバーのリスト。スペースが含まれないコンマ区切りリストとしてサーバー名を指定します。director_ip: Director に割り当てる、使⽤可能な範囲内の IP アドレス。haproxy_ip: haproxy に割り当てる、使⽤可能な範囲内の IP アドレス。この IP アドレスは、ワイルドカード・ドメインが差す⼊⼝点です。

console_ip: コンソール・ユーザー・インターフェースに割り当てる、使⽤可能な範囲内の IP アドレス。この IP アドレスは、ワイルドカード・ドメインが差す⼊⼝点です。cloud_config_custom: YAML クラウド構成のカスタマイズの詳細。director_custom: BOSH Director に適⽤される YAML 構成。この構成情報は、デフォルト構成テンプレートに対して spruce merge されます。カスタム構成が含まれた YAML ファイルを作成します。cf_custom: Cloud Foundry デプロイメントに適⽤される YAML 構成。この構成情報は、デフォルト構成テンプレートに対して spruce merge されます。カスタム構成が含まれた YAML ファイルを作成します。diego_custom: YAML Diego のカスタマイズの詳細。bbr_backup: Director およびデプロイメントのバックアップに関するプロパティー (スケジュール、バックアップの数、外部 NFS サーバー) を定義します。詳しくは、uiconfig-<vmware|openstack>-template.yml ファイルを参照してください。デフォルトでは、次のようになります。

Director のバックアップは毎⽇午前 2 時に⾏われ、10 個のバックアップが nfs_WAL_server 上に保持されます。

Bluemix デプロイメントのバックアップ (マニフェストのみ) は毎⽇午前 2:30 に⾏われ、10 個のバックアップが nfs_WAL_server 上に保持されます。


外部 NFS サーバーへの転送は⾏われません。bbr_backup.customer_nfs_host: 外部 NFS サーバーの IP アドレスまたはホスト名。bbr_backup.customer_nfs_path: NFS サーバーのディレクトリー・パス。bbr_backup.customer_short_name: 環境の短縮名。環境のすべてのバックアップを再グループ化するための任意の名前を指定します。

bbr_backup.director_backup.schedule: crontab 形式での、Director バックアップのスケジュール。デフォルト値は 2 (毎⽇午前 2:00) です。bbr_backup.director_backup.enabled: Director バックアップを有効にします。デフォルト値は true です。データベースが外部化されていて別個にバックアップされる場合は、このバックアップを無効にすることがで

きます。

bbr_backup.director_backup.nb_backups: 外部 NFS サーバーが指定されていない場合、このパラメーターにより、nfs_WAL_server で保持するバックアップの数を指定します。デフォルト値は 10 です。bbr_backup.director_backup.max_log_size: ログの最⼤サイズ。このサイズに達すると、ログはロールオーバーされます。デフォルト値は 1Mb です。bbr_backup.director_backup.nb_logs: 保持するログの数。bbr_backup.deployments_backup*.deployments: バックアップするデプロイメントのリスト。デフォルトでは、Cloud Foundry コミュニティー・スクリプトを使⽤して、Bluemix デプロイメントのみがバックアップされます。デフォルトでは、このバックアップは、午前 2:30 に実⾏するようスケジュールされます。現在、マニフェストのみがバックアップされます。

bbr_backup.deployments_backup.deployments.name: バックアップするデプロイメントの名前。bbr_backup.deployments_backup.deployments.enabled: このパラメーターが true に設定されている場合、デプロイメントのバックアップが有効になります。このパラメーターは、デフォルトのバックアップ(Bluemix) を無効にする場合に役⽴ちます。bbr_backup.deployments_backup.deployments.schedule:crontab 構⽂ * * * * * を使⽤して、いつバックアップを外部ロケーションに移動するのかを指定します。 crontab フィールドは、MIN(0-59) HOURS(0-23) DAY(1-31) MONTH(1-12) WEEKDAY(0-6) です。bbr_backup.deployments_backup.nb_backups: 外部 NFS サーバーが指定されていない場合、このパラメーターにより、nfs_WAL_server で保持するバックアップの数を指定します。デフォルト値は 10 です。bbr_backup.deployments_backup.max_log_size: ログの最⼤サイズを指定します。このサイズに達すると、ログはロールオーバーされます。デフォルト値は 1Mb です。bbr_backup.deployments_backup.nb_logs: 保持するログの数を指定します。db_nfs_copy: UAA および CC データベースに関するプロパティー (スケジュール、バックアップの数、外部NFS サーバー) を定義します。デフォルトでは、バックアップは外部 NFS サーバーに転送されません。db_nfs_copy.customer_nfs_host: 外部 NFS サーバーの IP アドレスまたはホスト名。db_nfs_copy.customer_nfs_path: NFS サーバーのディレクトリー・パス。db_nfs_copy.customer_short_name: 環境の短縮名。環境のすべてのバックアップを再グループ化するための任意の名前を指定します。

vSphere のパラメーター

インストール時に、/<installation_directory>/uiconfig_vmware_template.yml ファイルに以下のパラメーターを指定します。

これらのパラメーターは、vSphere にのみ適⽤されます。


uiconfig: ... #vSphere specific parameters vmware_address: "100.204.4.40" vmware_username: "vmware_user" vmware_password: "vmware_password" vmware_disk_type: "thin or preallocated"


datacenter_name: "MyDataCenter" cluster_name: "MyPersistentDataStorePattern" resource_pool: "MyResourcePool" template_folder: "MyTemplateFolder" vm_folder: "MyVMFolder" disk_path: "/Disk" datastore_pattern: "MyDataStorePattern*" persistent_datastore_pattern: "MyPersistentDataStorePattern" portgroup: "myPortGroup"

vmware_address: vCenter インスタンスのホスト名または IP アドレス。vmware_username: Cloud Foundry ⽤の vCenter にアクセスする権限がある VMware ユーザー名。vmware_password: VMware ユーザーのパスワード。

vmware_disk_type: 仮想マシン (VM) ⽤にプロビジョンするディスクのタイプ。有効な値は thin または preallocated であり、デフォルト値は thin です。パラメーター値が thin である場合、VMware は必要になるまでディスク・スペースを割り振らず、またディスクが過剰使⽤される可能性があります。 thin プロビジョンされたディスクを使⽤すると、VMware による新規ファイルの書き込みが遅くなり、またストレージの過剰使⽤が原因でスペース不⾜になる可能性があります。

preallocated を指定すると、VMware は VM の作成時にすべてのディスク・スペースを割り振ります。この値を使⽤すると、デプロイメント時に必要なディスク・スペースが増加しますが、スペースが常に使⽤可能で

あることが保証されます。

datacenter_name: Cloud Foundry VMware リソースをホストする vSphere データ・センター。cluster_name: Cloud Foundry ESXi ホストをホストする vSphere クラスター。resource_pool: オプション。仮想マシンをホストするリソース・プール。使⽤可能なものがない場合、値を Resources に設定します。template_folder: すべての stemcell 仮想マシンが含まれる、vSphere のフォルダー (仮想マシンおよびテンプレート)。vm_folder: すべての仮想マシンが含まれる、vSphere のフォルダー (仮想マシンおよびテンプレート・ビュー)。disk_path: 仮想マシン永続ディスク (VMDK) をホストする、データ・ストア内のディレクトリー。ディレクトリーは、存在しない場合、作成されます。

datastore_pattern: Cloud Foundry 仮想マシンをホストするデータ・ストアを判別するパターン。persistent_datastore_pattern: 仮想マシン永続ディスクをホストするデータ・ストアを判別するパターン。datastore_pattern と同じ値を使⽤できます。portgroup: すべての仮想マシンのプロビジョンに使⽤する vSphere ポート・グループ。

OpenStack のパラメーター

インストール時に、/<installation_directory>/uiconfig_openstack_template.yml ファイルに以下のパラメーターを指定します。

これらのパラメーターは、OpenStack にのみ適⽤されます。

これらのパラメーターの多くは、OpenStack ユーザー・インターフェースを使⽤して、「プロジェクト」>「コンピュート)」>「アクセスとセキュリティ」 >「API アクセス」>「OpenStack RC v3 ファイルのダウンロード (Download OpenStack RC File v3)」を選択してファイルをダウンロードすることで、⾒つけることができます。


uiconfig: ... openstack_key_pair_name: "my_icp_cf_key_name" openstack_key_pair_private: |+


-----BEGIN RSA PRIVATE KEY----- -----END RSA PRIVATE KEY----- openstack_availability_zone: "nova" openstack_security_groups: "CF-Sec1,CF-Sec2" openstack_cacert: |+ -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- openstack: auth: auth_url: "https://hostname:5000/v3" project_name: "myopenstack_project_name" project_id: "e16asdfasdf7ab80ac9b4234a74d" user_domain_name: "myopenstack_domain_name" username: "myopenstack_user" password: "myopenstack_password" identity_api_version: 3 interface: "public" region_name: "RegionOne" #Uncomment this section and overwrite with your flavor if needed. # flavors: # icpcf_default: <your_flavor> # icpcf_director: <your_flavor> # icpcf_coreNode: <your_flavor> # icpcf_cc_core: <your_flavor> # icpcf_nats: <your_flavor> # icpcf_consul: <your_flavor> # icpcf_router: <your_flavor> # icpcf_logger: <your_flavor> # icpcf_brain: <your_flavor> # icpcf_cc_bridge: <your_flavor> # icpcf_access: <your_flavor> # icpcf_route_emitter: <your_flavor> # icpcf_database: <your_flavor> # icpcf_cell: <your_flavor> # icpcf_cell_16: <your_flavor> # icpcf_compilation: <your_flavor>

openstack_key_pair_name: OpenStack 仮想マシンにアクセスするための鍵ペア名。openstack_key_pair_private: OpenStack 仮想マシンにアクセスするための鍵ペアの秘密鍵。openstack_availability_zone: アベイラビリティー・ゾーン。openstack_security_groups: 仮想マシンに接続するための OpenStack セキュリティー・グループ (.csv ファイル内)。スペースが含まれないコンマ区切りリストとしてセキュリティー・グループ名を指定します。例: default,boshopenstack_cacert: 仮想マシンへの接続に使⽤する証明書。証明書は、/data/openstack-cacert.pem に保管されます。

openstack: この属性の内容は、/data/home/.config/openstack/clouds.yaml に保管されます。これにより、inception コンテナーから openstack --os-cloud cf <sub-command> を実⾏できるようになります。

openstack.auth.auth_url: OpenStack 認証 URL。例えば、https://<hostname>:5000/v3。この値は、OpenStack RC 環境変数 OS_AUTH_URL から取得できます。openstack.auth.project_name: IBM® Cloud Private Cloud Foundry をインストールする必要があるプロジェクトの名前。この値は、OpenStack RC 環境変数 OS_PROJECT_NAME から取得できます。openstack.auth.project_id: IBM® Cloud Private Cloud Foundry をインストールする必要があるプロジェクトの ID。この値は、OpenStack RC 環境変数 OS_PROJECT_ID から取得できます。openstack.auth.user_domain_name: IBM® Cloud Private Cloud Foundry をインストールする必要があるドメイン・ネーム。この値は、OpenStack RC 環境変数 OS_USER_DOMAIN_NAME から取得できます。openstack.auth.username: IBM® Cloud Private Cloud Foundry デプロイメントに使⽤する OpenStack ユーザー。この値は、OpenStack RC 環境変数 OS_USERNAME から取得できます。


openstack.auth.password: IBM® Cloud Private Cloud Foundry デプロイメントに使⽤する OpenStack ユーザーのパスワード。この値は、OpenStack RC 環境変数 OS_PASSWORD から取得できます。openstack.identity_api_version: 3 に設定する必要があります。この値は、OpenStack RC 環境変数 OS_IDENTITY_API_VERSION から取得できます。openstack.interface: 有効な値は public または private です。この値は、OpenStack RC 環境変数 OS_INTERFACE から取得できます。openstack.region_name: IBM® Cloud Private Cloud Foundry デプロイメントに使⽤する地域。この値は、OpenStack RC 環境変数 OS_REGION_NAME から取得できます。flavors: 各 IBM® Cloud Private Cloud Foundry ジョブで使⽤するフレーバー。指定されたユーザーがフレーバーを作成する権限を備えている場合は、フレーバーが⾃動的に作成されます。そうでない場合は、このパラメーターを使⽤して、各ジョブの独⾃のフレーバーを設定できます。詳しくは、『IBM® Cloud Private CloudFoundry 開発者版のインストールの OpenStack サイズ要件』を参照してください。

IBM® Cloud Private Cloud Foundry のアップグレード

IBM Cloud Private Cloud Foundry をダウンロードしてアップグレードするには、以下のステップを実⾏します。

インストール・ファイルをダウンロードする時間を含めず、アップグレード・プロセスには約 2 時間から 4 時間かかります。

アップグレード・プロセスは、3 つのパートで構成されます。パート 1 と 2 は、並⾏して実⾏できます。パート 3は、パート 1 と 2 が完了した後に実⾏します。

1. パート 1: 新規インストール・メディアの準備2. パート 2: アップグレードのための既存インストール済み環境の準備3. パート 3: 新規バージョンへのアップグレード

開始する前に: 既存のインストール済み環境のインストール構成ディレクトリーをメモしてください。パート 3 でこのディレクトリーが必要になります。

パート 1: 新規インストール・メディアの準備

1. フルインストール・ファイルをパスポート・アドバンテージからダウンロードします (8.1 GB)。2. IBM Cloud Private Cloud Foundry をアップグレードするには、実動 Docker CE および VMware 環境にアクセスできるサーバーにインストール・ファイルをコピーします。

3. Docker Community Edition (CE) がまだインストールされていない場合は、Docker CE をインストールします。詳しくは、Docker のインストールに関する資料を参照してください。

4. アップグレードで使⽤するディレクトリーを作成します。5. フルインストール・ファイルをそのディレクトリーに解凍します。6. そのディレクトリーに移動します。7. そのディレクトリーから Docker イメージをインポートします。

import_images.sh

パート 2: アップグレードのための既存インストール済み環境の準備

注: 後続のステップの例では、/<installation_directory>/uiconfig_template.yml を参照しています。これらの例で参照されている uiconfig_template.yml ファイルは、構成ファイルのカスタマイズ版を指しています。ご使⽤のファイルのファイル名をテンプレートから変更しなかった場合、ファイル名は uiconfig_template.yml です。ファイル名を変更した場合は、例のファイル名を置き換えてください。

1. 前のバージョンのインストール・ディレクトリーに移動します。




2. /<installation_directory>/uiconfig_template.yml ファイルでキー diego_cell_instances を調べて、デプロイメントで使⽤しているセルの数を判別します。

3. 前のバージョンの 2.1.0.2 /<installation_directory>/uiconfig_template.yml ファイルを更新します。 /<installation_directory>/uiconfig_template.yml ファイル内に以下の項⽬が存在していることを確認します。

uiconfig: developer_mode: true ... diego_custom: | --- jobs: - name: cell instances: <**diego_cell_instances**> ...

前のバージョンで新規バージョンのアベイラビリティー・ゾーンを利⽤できるようにするために、エンタープ

ライズ・モードから開発者モードへのこの⼀時的なマイグレーションを⾏う必要があります。

developer_mode を true に設定する必要があります。 diego_custom jobs cell instances は、diego_cell_instances 値に⼀致している必要があります。

4. 以下のように、アップグレードのために前のバージョンを準備します。

./cm engine reset

./launch_deployment.sh -c uiconfig_template.yml

パート 3: 新規バージョンへのアップグレード

1. 新規バージョンのディレクトリーに移動します。

注: 後続のステップでは、元のインストール済み環境の inception コンテナーが必要です。

2. 以下のコマンドを実⾏して、元のインストール済み環境の inception コンテナーがまだ実⾏中かどうかを確認します。

docker ps -f "name=inception-IBMCloudPrivate"

inception コンテナーがまだ実⾏中でない場合は、以下のように launch.sh スクリプトを実⾏して inceptionコンテナーを開始します。

./launch.sh -n IBMCloudPrivate -b ./BOM.yml -c /home/user/data -e LICENSE=accept

ここで、/home/user/data は、元のインストール構成ディレクトリーです。

3. /<installation_directory>/uiconfig_vmware_template.yml ファイル内に以下の項⽬が存在していることを確認します。

uiconfig: developer_mode: true ... diego_custom: | --- instance_groups: - name: cell instances: <**diego_cell_instances**> migrated_from: - name: cell az: '-' - name: database


migrated_from: - name: database az: '-' - name: access migrated_from: - name: access az: '-' - name: cc_bridge migrated_from: - name: cc_bridge az: '-' - name: route_emitter migrated_from: - name: route_emitter az: '-' - name: brain migrated_from: - name: brain az: '-' ... console_ip: 1.1.1.1

developer_mode: アップグレードのこのパートでは、「true」に設定する必要があります。diego_custom jobs cell instances は、diego_cell_instances 値に⼀致している必要があります。diego_cell_instances: 前のバージョンと同じ値に設定する必要があります。 console_ip: Cloud FoundryConsole をホストするために使⽤する追加の静的 IP。注: diego_custom セクションでは、前のバージョンのjobs は、新規バージョンでは instance_groups になっています。

4. 以下のように、新規バージョンにアップグレードします。

./cm engine reset


5. 新規バージョンへのアップグレードが完了したので、必要に応じて、開発者モードをエンタープライズ・モードに変更できます。

6. /<installation_directory>/uiconfig-template.yml ファイル内に以下の項⽬が存在していることを確認します。

uiconfig: developer_mode: false ... console_ip: 1.1.1.1

diego_custom instance_groups セクションは不要になっています。 console_ip: Cloud Foundry Console をホストするために使⽤する追加の静的 IP。

7. 以下のように、開発者モードからエンタープライズ・モードに変更します。

./cm engine reset


8. 拡張機能をメイン・デプロイメントに挿⼊した場合は、./cm states コマンドを実⾏してメイン・デプロイメントのステップの順序を確認し、必要に応じて、./cm states delete および ./cm states insert コマンドを使⽤してデプロイメント・ステップを並べ替えます。 launch.sh スクリプトを実⾏して inceptionコンテナーを更新すると、拡張機能は、デプロイメント順序の末尾に配置されます。拡張機能の並べ替えについて詳しくは、『拡張機能の作成』を参照してください。

9. 以下のように、アップグレードを開始します。

./cm engine reset



このコマンドにより、すべてのデプロイメント・ステップがアクティブ化され、IBM Cloud Private CloudFoundry のアップグレードが開始されます。問題が発⽣した場合は、『IBM Cloud Private Cloud Foundry のトラブルシューティング』を参照してください。

10. 以下のように、ビルドパックを更新します。


このコマンドは、IBM 提供のビルドパックを更新します。

IBM® Cloud Private Cloud Foundry のアンインストール

IBM Cloud Private Cloud Foundry をアンインストールするには、まず BOSH デプロイメントを削除してから、インストール・コンテナーを削除します。

1. vSphere コンソールに接続します。2. デプロイメントを⾒つけます。構成に応じて、仮想マシンはリソース・プールまたはクラスター内に存在している可能性があります。

3. リソース・プールまたはクラスター内のすべての仮想マシン (VM) を選択して右クリックし、「power」>「off」をクリックします。

4. VM を再度選択して右クリックし、「delete from disk」をクリックします。5. IBM Cloud Private Cloud Foundry が使⽤していたクラスター、リソース・プール、および仮想マシン・フォルダーが不要になっている場合は、それらを削除します。

6. IBM Cloud Private Cloud Foundry の再インストールの予定がない場合は、inception コンテナーをインストール・ホストから削除します。

1. 以下のように、inception コンテナー名を取得します。

docker ps

inception コンテナーの名前は、inception- で開始します。

2. 以下のように、inception コンテナーを削除します。

docker rm <inception-name>

7. (オプション) Docker をアンインストールします。

8. インストール構成ファイルを保管していたディレクトリーを削除します。このディレクトリーは、launch.sh インストール・コマンドの実⾏時に -c オプションの引数として指定しています。

IBM® Cloud Private Cloud Foundry のための認証の構成

インストールの前または後に、IBM Cloud Private Cloud Foundry の認証を構成できます。

IBM Cloud Private Cloud Foundry のための LDAP 認証の構成IBM Cloud Private Cloud Foundry のための UAA 認証の構成組織およびスペースに対するユーザー許可の管理

組織およびスペースに対するユーザー許可の管理

ユーザーの作成後、組織およびスペースにアクセスするための許可をユーザーに付与できます。


組織またはスペースに対する許可をユーザーに付与する前に、以下のアクションを実⾏します。

ユーザーを作成します。『IBM® Cloud Private Cloud Foundry のための認証の構成』を参照してください。アクセス権限を付与する予定のオブジェクトが存在していることを確認します。 cf orgs または cf spacesを実⾏して、組織またはスペースが存在していることを確認します。 (cf target -o ORG が必要)ユーザーが IBM Cloud Private Cloud Foundry にログインしていることを確認します。ログインしていない場合、そのユーザーに組織またはスペースに対するアクセス権限を付与できません。

組織へのアクセス権限の付与

組織へのアクセス権限をユーザーに付与するには、以下のコマンドを実⾏します。

cf set-org-role <username> <org> <role>

ここで、<username> はユーザー名であり、<org> は Cloud Foundry 組織であり、<role> は以下の役割のいずれかです。

OrgManager: このユーザーは、ユーザーの招待と管理、プランの選択と変更、⽀払上限の設定を⾏うことができます。

BillingManager: このユーザーは、請求アカウントと⽀払い情報の作成および管理を⾏うことができます。OrgAuditor: このユーザーは、組織の情報とレポートに対する読み取り専⽤権限を備えます。

スペースへのアクセス権限の付与

注: Cloud Foundry CLI バージョン 6.13 以前を使⽤して、以下のコマンドを実⾏する必要があります。

スペースへのアクセス権限をユーザーに付与するには、以下のコマンドを実⾏します。

cf set-space-role USERNAME <username> <org> <space> <role>

ここで、<username> はユーザー名であり、<org> は Cloud Foundry 組織であり、<role> は以下の役割のいずれかです。

SpaceManager: このユーザーは、ユーザーの招待と管理、スペースのフィーチャーの有効化を⾏うことができます。

SpaceDeveloper: このユーザーは、アプリケーションとサービスの作成および管理、ログとレポートの表⽰を⾏うことができます。

SpaceAuditor: このユーザーは、スペースのログ、レポート、および設定を表⽰できます。

組織およびスペースに対するユーザー許可の削除

組織に対するユーザーの許可を削除するには、以下のコマンドを実⾏します。

cf unset-org-role <username> <org> <role>

スペースに対するユーザーの許可を削除するには、以下のコマンドを実⾏します。

cf unset-space-role <username> <org> <space> <role>

IBM® Cloud Private Cloud Foundry のための認証の構成

インストールの前または後に、IBM Cloud Private Cloud Foundry ⽤の環境をカスタマイズできます。

IBM Cloud Private Cloud Foundry のための LDAP 認証の構成

IBM Cloud Private Cloud Foundry のための UAA 認証の構成


IBM® Cloud Private Cloud Foundry のための LDAP 認証の構成

IBM Cloud Private Cloud Foundry でユーザー認証に LDAP 認証を使⽤することもできます。

LDAP 認証を構成できるのは、IBM Cloud Private Cloud Foundry のインストール後のみです。『IBM Cloud PrivateCloud Foundry のインストール』を参照してください。拡張機能を作成し、そのデプロイメントをメイン CloudFoundry デプロイメントに追加します。『IBM® Cloud Private Cloud Foundry での拡張機能の使⽤』を参照してください。

IBM Cloud Private Cloud Foundry では、IBM Cloud Foundry ログイン・サービスを使⽤して LDAP 認証を管理します。

LDAP 認証を構成する前に、LDAP または Active Directory ドメインにユーザーを作成する必要があります。グループを使⽤して、IBM Cloud Private Cloud Foundry 環境へのアクセスをフィルターに掛けることができます。

ユーザーのアクティブ化の準備

LDAP 認証を構成する前に、ユーザーのアクティブ化プロセスを計画する必要があります。以下の 3 つの⽅法でユーザーをアクティブ化できます。

各ユーザーを Cloud Foundry に⼿動で追加する。認証が LDAP で成功すると、追加したユーザーのみがアクティブ化されます。

すべてのユーザーを⾃動的にアクティブ化する。 LDAP 認証が成功すると、ユーザーは Cloud Foundry に追加されます。初期状態では、Cloud Foundry 組織およびスペースに追加されません。特定のグループにユーザーを⾃動的にアクティブ化する。 LDAP 認証が成功すると、ユーザーは CloudFoundry 組織またはスペースに追加されます。

すべてのユーザーを⾃動的にアクティブ化するには、- UAA ブランチでパラメーター autoProvisionUsers: .*を使⽤します。このパラメーターを使⽤することで、各 IBM Cloud Private Cloud Foundry アカウントが⾃動的にプロビジョンされますが、アカウントは組織およびスペースには割り当てられません。

特定のグループにユーザーを⾃動的にアクティブ化するには、各 LDAP ブランチで、ユーザーをプロビジョンする場所を指定できます。ユーザーの LDAP グループ・メンバーシップに基づいて、特定の組織およびスペースを構成できます。特定の LDAP グループ内のユーザーのみが認証できます。 LDAP memberOf オーバーレイを使⽤して、⾃動的に IBM Cloud Private Cloud Foundry ユーザーを作成し、そのユーザーを組織およびスペースに割り当てる必要があります。各ブランチで、以下のテキストのようなコードを指定します。

# ユーザーが特定の LDAP グループに存在しているかどうかの検査に使用 expressions: searchLoginUser: (&(%userNameAttr=%loginUser)((memberOf=cn=MY_GROUP,ou=GROUPS_PARENT,dc=MY_DOMAIN,dc=net)) # この設定を適用すると、LDAP フィルターが使用され、すべてのユーザー ID が memberOf オーバーレイ・プロパティーに照らして検証される。これにより、認証が許可されることが確認される。この設定は、LDAP サーバーでログインをブロックする

SignUp: type: UAASyncByGroup groups: - name: cn=MY_GROUP,dc=MY_DOMAIN,dc=net orgName: MY_COMPANY orgRole: managers spaceName: MY_SPACE spaceRole: developers

LDAP のユーザーのインポート


1. LDAP 構成詳細が含まれた YAML フォーマットのファイルを作成します。以下の例に⽰すように、uiconfig:セクションに構成詳細を配置します。このファイルは、構成マネージャーのコマンド・ラインを使⽤してinception コンテナーに指定します。

以下の properties 情報を使⽤します。

uiconfig: properties: loginserver: NG: - type: LDAP id: CUSTOMER_LDAP # 任意のラベル default: true # エントリーをデフォルト認証ドメインにするために使用 cliSearchOrder: 20 # 複数の LDAP サーバーの優先順位の指定に使用。 0-100, 100 = highest priority (UAA cliSearchOrder: 10) group: # 任意のラベル LDAP: url: ldaps://1.1.1.1 # LDAP サーバーのホスト名または IP。 (非セキュアの場合は ldap://、セキュアの場合は ldaps://) userId: cn=admin,dc=icp,dc=net # LDAP ドメインの検索許可を備えたユーザーの名前 password: ***** # LDAP ドメインを検索するユーザーのパスワード objCls: inetOrgPerson # LDAP ドメイン内のユーザーのオブジェクト・クラス userNameAttr: userId # ユーザーの ID を突き合わせるために検索される、LDAP ドメイン内の属性名 mailAttr: cn # ユーザーの E メールが含まれている、LDAP 内の属性名。使用可能な E メール属性がない場合は、別の属性を使用 firstNameAttr: givenName # ユーザーの名が含まれている、LDAP 内の属性名 lastNameAttr: cn # ユーザーの姓が含まれている、LDAP 内の属性名 searchCtx: ou-users,dc=icp,dc=net # LDAP ドメイン内のユーザー・レコードの検索パス groupsAttr: memberOf # メンバーが属しているグループのリストを示す、LDAP 内の属性名 expressions: searchLoginUser: LDAP_EXPR # この属性は、ユーザーのルックアップ時に適用されるフィルター。これにより、IBM Cloud Private Cloud Foundry # ユーザーを 1 つ以上のグループに制限。 memberOf オーバーレイの使用例: # (&(%userNameAttr=%loginUser)(memberOf=cn=MY_GROUP,ou=GROUPS_PARENT,dc=MY_DOMAIN,dc=net)) これにより、 # MY_GROUP のメンバーである場合、検証ユーザーのみが返される。

以下の Signup 情報を使⽤します。

SignUp: # [オプション・ブランチ] このブランチは、1 つ以上の LDAP グループの特定の IBM Cloud Private Cloud Foundry 組織およびスペースへのマップをサポート。 type: UAASyncByGroup groups: - name: cn=user-grp,dc=icp,dc=net # ユーザーをサインアップする前にメンバーシップを検査するグループの検索パス orgName: MY_COMPANY # ユーザーを追加する組織 orgRole: managers # リストされた組織のユーザーに適用する役割 spaceName: dev # ユーザーを追加するスペースの名前 spaceRole: developers # リストされたスペースのユーザーに提供する役割

以下の UAA 情報を使⽤します。


- UAA: userPattern: USER_PATTERN # LDAP に照らして検査されず、直接 UAA に移行する UAA ユーザーのパターン。 usersList: USER1,USER2 # LDAP に照らして検査されず、直接 UAA に移行する UAA ユーザーのコンマ区切りのリスト。 IBM Cloud Private Cloud Foundry 管理者名は、リストに自動的に追加される。 cliSearchOrder: 10 id: UAA type: UAA default: false autoProvisionUsers: .* # [オプション] LDAP を介して認証されたすべてのユーザーが IBM Cloud Private Cloud Foundry で作成される clientsThatAcceptNonProvisionedUsers: null # このパラメーター値は「null」のままにすること certificates: # [オプション] ldaps:// の使用時、LDAP サーバーでは SSL 証明書が必要。 - ldap_cert: | # 通常、自己署名または企業署名証明書に適用。デプロイメントにより、ワイルドカード証明書がここに自動的に追加される。 -----BEGIN CERTIFICATE----- # 証明書の追加時、ワイルドカード証明書も必ず追加すること (この設定により、デフォルトのワイルドカード証明書設定がオーバーライドされるため)。 ... -----END CERTIFICATE-----

2. 構成のカスタマイズを適⽤します。

1. 以下のように、構成ファイルを inception コンテナーにプッシュします。

./cm extension -e cfp-ext-ldap save -c <your_ldap_config_file>

ここで、<your_ldap_config_file> は、作成した LDAP 構成ファイルの名前です。

2. メイン Cloud Foundry デプロイメントに拡張機能を挿⼊します。以下のコマンドにより、CloudFoundry コンポーネントのデプロイメント前に LDAP 拡張機能のデプロイメントを追加します。

./cm states insert -i cfp-ext-ldap -n deploy-cf -b

3. 以下のように、エンジンをリセットします。

./cm engine reset

4. 以下のように、Cloud Foundry デプロイメント・プロセスを再始動します。

launch_deployment.sh -c uiconfig-template.json

3. デプロイメントが完了したら、LDAP サーバーの状況を確認します。次のコマンドを実⾏します。

curl https://login.<mydomain>/UAALoginServerWAR/check

ここで、<mydomain> は IBM Cloud Private Cloud Foundry ドメインです。

4. 組織およびスペースに対する許可をユーザーに付与します。『組織およびスペースに対するユーザー許可の管理』を参照してください。

ユーザーのアクティブ化

ユーザーを⼿動でアクティブ化した場合、ユーザーごとに以下のコマンドを実⾏します。

cf create-user USER_NAME USER_PASSWORD

ここで、USER_NAME は、LDAP 構成の userNameAttr パラメーターで定義されている LDAP ユーザー ID です。 USER_PASSWORD パラメーターのパスワード値を⼊⼒する必要がありますが、その値は使⽤されません。


ユーザーを⾃動的にアクティブ化した場合、追加アクションは不要です。

ユーザー・アクセスの取り消し

ユーザー・アクセスを取り消すには、IBM Cloud Private Cloud Foundry 環境へのアクセスをフィルターに掛けるために使⽤している LDAP グループからユーザーを削除します。

IBM® Cloud Private Cloud Foundry のための UAA 認証の構成

UAA 認証は、IBM Cloud Private Cloud Foundry のデフォルト認証⽅式です。

UAA は、Cloud Foundry の内部ユーザー・アカウント & 認証サービスです。

IBM Cloud Private Cloud Foundry のインストール時に、main_user_name および main_user_password パラメーターで管理ユーザー名とパスワードを定義します。

cf CLI を使⽤したユーザーの作成

1. cf CLI をインストールします。『IBM® Cloud Private Cloud Foundry ops console ⽤のコマンド・ライン・インターフェース』を参照してください。

2. Cloud Foundry にログインします。次のコマンドを実⾏します。

cf api https://api.<my_domain> cf login

ここで、<my_domain> は API ドメインです。

プロンプトが出されたら、管理者資格情報を⼊⼒します。

3. 以下のように、ユーザーを作成します。

cf create-user <username> <password>

ここで、<username> はユーザー名であり、<password> は関連パスワードです。

4. 組織およびスペースに対する許可をユーザーに付与します。『組織およびスペースに対するユーザー許可の管理』を参照してください。


内部 UAA に追加したユーザーを削除するには、以下のコマンドを実⾏します。

cf delete-user <username> [-f]

ここで、<username> はユーザー名であり、-f オプションにより、CLI での確認なしでユーザーが削除されます。

IBM® Cloud Private Cloud Foundry での拡張機能の使⽤

IBM Cloud Private Cloud Foundry では、拡張機能とは、デプロイメント・プロセスおよびそれに必要なスクリプトとファイルが含まれたパッケージです。拡張機能フレームワークを使⽤して、ご使⽤のデプロイメントと CloudFoundry デプロイメントを統合したり、独⽴して実⾏したりすることができます。

拡張機能は、デプロイメント・パッケージおよびそれに必要なスクリプトとファイルで構成されます。


デプロイメント・プロセスは、複数のステップにフェーズ化できます。構成マネージャーが、マニフェスト・ファイルに設定した順序に従って、ステップ (状態) を順次実⾏します。マニフェスト・ファイルでは、ステップの名前、各ステップで実⾏するスクリプトの名前、および必要なパラメーターとその値を指定します。デプロイメントを実⾏すると、スクリプトの実⾏が失敗するか、すべてのステップが完了するまで、各ステップが順次実⾏されます。ステップに関連付けられているスクリプトの実⾏が失敗すると、そのステップには FAILED のマークが付けられます。成功したすべてのステップには、SUCCEEDED のマークが付けられます。

拡張機能の作成


拡張機能の作成

拡張機能を作成するには、各デプロイメント・ステップ⽤のスクリプトを作成し、ステップの実⾏順序およびパラメ

ーターの概要を⽰したマニフェスト・ファイルを作成し、マニフェスト・ファイルおよびステップ・ファイルを圧縮

します。

1. デプロイメント・ステップを実⾏するためのスクリプトを作成します。 Ubuntu を使⽤しているコンピューターでこれらのスクリプトを実⾏できなければなりません。

2. マニフェスト・ファイルを作成します。マニフェスト・ファイルは YAML フォーマットでなければならず、また states セクションが含まれている必要があります。このセクションでは、ステップの順序、および各ステップ⽤のスクリプトの名前を指定します。他のパラメーターを指定する必要がある場合、そのパラメーターを含めるための追加のセクションを作成できます。

注: 関連付けられたスクリプトを実⾏する順序で、状態をリストする必要があります。

states セクションの形式は、以下のとおりです。

states: - name: task1 log_path: /tmp/task.log status: READY start_time: end_time: reason: script: scripts/success.sh task1 script_timeout: 10 ...

表 1. 状態のパラメーターパ

ラ

メ

ー

タ

ー

説明値デフォルト値必

須

name

状態の名前。英数字ス

トリング

N/A は

い

script

その状態中に実⾏するスクリプト。拡張機能の .zip ファイルのルートを基準とした相対パスを指定できます。絶対パスを指定した場合、inception コンテナー内のパスになります。

ファイ

ル・パス

N/A は

い


パ

ラ

メ

ー

タ

ー


須

phase

スクリプトをいつ実⾏するか。このパラメーター値を AtEachRun に設定した場合、状態の状況が SUCEEDED であっても、スクリプトが実⾏されます。このパラメーターを省略した場合、スクリプトは 1 回だけ実⾏されます。

AtEachRunブ

ラ

ン

ク

ブランクい

い

え

log_path

当該状態のログのパス。状態⽤のスクリプトが実⾏されると、前の実⾏ログがバックアップされます。

ファイ

ル・パス

/data/logs/extensions/custom/extension_name.log

い

い

え

time_out

スクリプトを実⾏できる最⼤時間。スクリプトは、割り振られている時間に完了しなかった場合、停⽌し、状態の状況が FAILED に変更されます。

時間 (分) 60 い

い

え


パ

ラ

メ

ー

タ

ー


須

status

状態の状況。状態の状況は、そのスクリプトの実⾏後に変更されます。 READYSKIPRUNNINGSUCCEEDEDFAILED

N/A は

い

start_time

スクリプトの開始タイム・スタンプ (協定世界時)。この値は、構成マネージャーによって変更されます。

N/A N/A い

い

え

end_time

スクリプトの終了タイム・スタンプ (協定世界時)。この値は、構成マネージャーによって変更されます。

N/A N/A い

い

え

reason

状態が失敗した理由。この値は、デプロイメント中に構成マネージャーによって変更されます。

N/A N/A は

い

オプションとして、call_state セクションを追加できます。このセクションでは、拡張機能の呼び出し元にする必要がある親状態ファイル内にステップを挿⼊します。 call_state を追加した場合、親状態ファイルに呼び出しステップを追加するために使⽤する state.yml を作成することはできません。

call_states セクションの形式は、以下のとおりです。

call_state: phase: AtEachRun

call_states セクションでは、states セクションと同じデフォルト値を使⽤します。


1. 拡張機能⽤のフォルダーを作成し、スクリプトおよびマニフェスト・ファイルをそこにコピーします。マニフェスト・ファイルは、このディレクトリーのルートに配置する必要があります。スクリプト・ファイルは、任意のサブフォルダーに配置できますが、スクリプト・パラメーター値に正しい相対ファイル・パスが含まれる

ようにしてください。フォルダー構造は、以下の例のようになります。

extension-manifest.yml scripts/ scripts/success.sh scripts/README.md

2. 拡張機能のフォルダーを .zip ファイルに圧縮します。アーカイブ・ファイルは、ZIP64 フォーマット互換でなければなりません。『.ZIP File Format Specification 』を参照してください。 Ubuntu および iOS の zip コマンドは、ZIP64 互換です。


拡張機能を実⾏すると、以下のルールが適⽤されます。

状況が READY または FAILED の最初のスクリプトが実⾏されます。スクリプトの実⾏が失敗した場合、拡張機能の実⾏は停⽌します。

状況が SKIP または SUCCEEDED のスクリプトは、実⾏されません。phase パラメーターの値を AtEachRun に設定した場合、そのステップのスクリプトは、エンジンを開始するたびに、状況が SUCCEEDED であっても実⾏されます。スクリプトの実⾏中、その状況は RUNNING に設定されます。

1. inception コンテナーで拡張機能を登録します。拡張機能を登録すると、拡張機能のアーカイブ・ファイルの内容が、inception コンテナー上の /data/extensions/custom/<extension_name> フォルダーにアップロードされます。注: IBM が提供している拡張機能を登録する必要はありません。既に登録されています。次のコマンドを実⾏します。

./cm extension -e <extension_name> register -p <archive_path>

ここで、<extension_name> は拡張機能の名前であり、<archive_path> は圧縮アーカイブ・フォルダーのパスと名前です。

2. 拡張機能が登録されたことを確認します。以下のコマンドを実⾏し、拡張機能の名前が出⼒でリストされていることを確認します。

./cm extensions

3. スクリプトに変数が含まれている場合、変数を定義した構成ファイルを作成し、そのファイルを拡張機能に指定できます。

1. 構成ファイルを作成します。このファイルは YAML フォーマットでなければならず、また uiconfig セクションから開始する必要があります。例えば、servicebroker_port パラメーターの値を設定するには、構成ファイルの内容は、以下のテキストのようになります。

uiconfig: servicebroker_port: 8080

2. 構成ファイルを inception コンテナーに指定するには、以下のコマンドを実⾏します。

./cm extension -e <extension_name> save -c <config_file>

ここで、<extension_name> は登録した拡張機能の名前であり、<config_file> は構成ファイルの名前です。構成ファイルは、uiconfig.yml ファイルとして inception コンテナー上の /data/extensions/custom/<extension_name> フォルダーに保管されます。スクリプトは、このファイルを使⽤して、実⾏時に必要な各パラメーターを取得できます。


https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

4. 拡張機能をデプロイします。拡張機能とメインの Cloud Foundry デプロイメントを統合したり、拡張機能を別の拡張機能のデプロイメントに追加したり、拡張機能を単独でデプロイしたりすることができます。

重要: Cloud Foundry をデプロイすると、構成マネージャー・ツール ./cm が⾃動的にインストールされるため、インストール・ディレクトリーから cm コマンドを実⾏する必要があります。

拡張機能を Cloud Foundry デプロイメントに挿⼊するには、以下のステップを実⾏します。

1. Cloud Foundry の状態を表⽰します。

./cm states

2. 拡張機能のマニフェストに call_step セクションが含まれていない場合、Cloud Foundry デプロイメント⽤の state_cf.yml ファイルを作成します。このファイルは、実⾏する新規ステップとして Cloud Foundry デプロイメントに挿⼊されるテンプレート・ファイルです。 script パラメーターは、拡張機能を呼び出すように⾃動的に設定されます。デフォルトでは、各パラメーターが、前の表で説明したように設定されます。ファイルには、以下のテキストが含まれます。

name: <extension_name>

次に、以下のように、拡張機能を Cloud Foundry 状態ファイルに追加します。

./cm states insert -s state_cf.yml -n <state_name>

ここで、<state_name> は、この状態の後に拡張機能を実⾏する状態です。状態の前に拡張機能を実⾏する必要がある場合は、-n オプションを -b オプションに置き換えてください。

3. 拡張機能のマニフェストに call_step セクションが含まれている場合、拡張機能を CloudFoundry 状態ファイルに追加するために、以下のコマンドを実⾏します。

./cm states insert -i <extension_name> -n <state_name>

ここで、<extension_name> は実⾏する拡張機能の名前であり、<state_name> はこの状態の後に拡張機能を実⾏する状態です。状態の前に拡張機能を実⾏する必要がある場合は、-n オプションを -b オプションに置き換えてください。

4. 更新された状態の順序を確認するには、./cm states -e extension_name コマンドを再度実⾏します。

5. launch_deployment.sh コマンドを実⾏して、Cloud Foundry および拡張機能をデプロイします。

新規拡張機能を既存の拡張機能に挿⼊するには、以下のステップを実⾏します。

1. 既存の拡張機能の状態を表⽰します。

./cm states -e extension_name

ここで、<extension_name> は既存の拡張機能です。

2. 拡張機能⽤の state_<extension_name>.yml ファイルを作成します (<extension_name> は既存の拡張機能)。このファイルは、実⾏する新規ステップとして拡張機能デプロイメントに挿⼊されるテンプレート・ファイルです。 script パラメーターは、拡張機能を呼び出すように⾃動的に設定されます。デフォルトでは、各パラメーターが、前の表で説明したように設定されます。ファイルには、以下のテキストが含まれます。

name: <extension_name>

ここで、<extension_name> は、拡張機能の名前です。

3. 以下のように、新規拡張機能を既存の拡張機能の状態ファイルに追加します。


./cm states -e <extension_name> insert -s state_<extension_name>.yml -n <state_name>

ここで、<extension_name> は既存の拡張機能であり、<state_name> は、この状態の後に拡張機能を実⾏する状態です。状態の前に拡張機能を実⾏する必要がある場合は、-n オプションを -b オプションに置き換えてください。

4. 更新された状態の順序を確認するには、./cm states -e extension_name コマンドを再度実⾏します。

5. 以下のように、既存の拡張機能をデプロイします。

./cm extension -e <extension_name> deploy

ここで、<extension_name> は、既存の拡張機能の名前です。

拡張機能を単独でデプロイするには、以下のコマンドを実⾏します。

./cm extension -e <extension_name> deploy

ここで、<extension_name> は、拡張機能の名前です。このコマンドはバックグラウンドで実⾏されますが、 -w フラグをコマンドに追加して、デプロイメントが終了するまで待機することもできます。

デプロイメント中、pie-<extension-name>.yml ファイルが拡張機能のディレクトリーに作成されます。このファイルは、構成マネージャー・エンジンによって更新されます。デプロイメント中、デフォルト値に加え、必要に応じて状況、開始タイム・スタンプ、停⽌タイム・スタンプを使⽤して、各

項⽬が更新されます。

スクリプトのタイム・スタンプ (協定世界時) がスクリプトの実⾏の開始および終了時に設定されます。

状況が、スクリプトの exitCode に基づいて、⾃動的に設定されます。スクリプトの実⾏が終了しなかった (終了コードがゼロでない) 場合、スクリプトの状況には FAILED のマークが付けられます。

スクリプトから出⼒された StdOut および StdErr が、ログ・ファイルに記録されます。タイムアウト値を超過した場合、プロセスは停⽌し、FAILED のマークが付けられます。

5. 拡張機能をモニターします。./cm extension -e extension_name logs コマンドを実⾏して、拡張機能のログ・ファイルを確認できます。 -f フラグを追加して、ログを順次表⽰できます。デプロイメントの各種ログ・ファイルが、連続して表⽰されます。

6. オプション: 拡張機能を登録抹消します。拡張機能を登録抹消すると、inception エンジンから拡張機能データが削除されますが、デプロイメントがクラスターから削除されることはありません。拡張機能は、デプロイ後、インストール済みの拡張機能をアンデプロイするステップが含まれた拡張機能を作成しない限り、削除で

きません。拡張機能を登録抹消するには、以下のコマンドを実⾏します。

./cm extension -e extension_name unregister

ここで、<extension_name> は、拡張機能の名前です。

7. オプション: 拡張機能を別の拡張機能に追加したが、既存の拡張機能の次回デプロイ時に新規拡張機能をデプロイしない場合は、その拡張機能を削除します。次のコマンドを実⾏します。

./cm states -e extension_name delete -n state_name

ここで、<extension_name> は既存の拡張機能であり、<state_name> は、この状態の後に拡張機能を実⾏する状態です。

IBM Cloud Private Cloud Foundry コンソールの構成


IBM Cloud Private Cloud Foundry コンソールは、Cloud Foundry アプリケーションおよびバインド済みサービスを作成および管理するために使⽤します。

始める前に

1. uiconfig ファイルの console_ip プロパティーに IBM Cloud Private Cloud Foundry コンソールの IP アドレスを指定する必要があります。 IP アドレスを指定しなかった場合、検証が失敗し、インストールは開始しません。 console_ip プロパティーについては、『共通のパラメーター』を参照してください。

2. IBM Cloud Private Cloud Foundry をデプロイするために、『IBM Cloud Private Cloud Foundry のインストール』のステップを実⾏します。

3. IBM Cloud Private Cloud Foundry のデプロイメントの完了後に、必要な値を構成ファイルから取得する必要があります。ヒント: 該当する値は、以下のステップ 5 で UAA のコンソール資格情報を構成する際に必要になります。

1. IBM Cloud Private Cloud Foundry のデプロイメントで使⽤した構成ディレクトリーにナビゲートします。

2. ./uiconfig.yml を検索して、以下のプロパティーの値を取得します。

bluemix_env_domain main_user_name main_user_password

3. ./CloudFoundry/credentials.yml で、uaa_cf_ui_secret の password の値を取得します。

uaa_cf_ui_secret: password: "" complexity: 12 description: "Secret for cf_ui client-id, that is used by the Console to access Cloud Foundry"

IBM Cloud Private Cloud Foundry コンソールへの接続

4. https://<console_ip>:4443 にナビゲートします。5. ⾃⼰署名証明書を受け⼊れます。6. 「Cloud Foundry セットアップ (Cloud Foundry Console Setup)」ウィザードがロードされます。7. 「1 概要 (1 Introduction)」ウィンドウが表⽰されます。「次へ」をクリックします。8. 「2 UAA エンドポイント (2 UAA Endpoint)」ウィンドウが表⽰されます。以下の環境情報の値を指定します。

UAA エンドポイントAPI URL: UAA を指す URL を指定します。 https://uaa.BLUEMIX_ENV_DOMAIN。例:https://uaa.cf.ibm.comエンドポイントの SSL 検証をスキップする (Skip SSL validation for the endpoint): IBM CloudPrivate Cloud Foundry で⾃⼰署名証明書を使⽤する場合にのみ選択します。

UAA のコンソール資格情報 (Console credentials for UAA)クライアント ID: cf_ui が、IBM Cloud Private Cloud Foundry のデプロイメント時に⾃動的に作成されます。

クライアント秘密鍵 (Client Secret): uaa_cf_ui_secret の password の値を指定します。管理者ユーザー名 (Admin Username): main_user_name の値を指定します。管理者パスワード (Admin Password): main_user_password の値を指定します。

すべての必須フィールドを指定した後に、「次へ」をクリックします。9. 「3 コンソール管理スコープ (3 Console Admin Scope)」ウィンドウが表⽰されます。「スコープ (Scope)」ドロップダウン・リストで stratos.admin を選択し、「完了 (Complete)」をクリックします。 IBM Cloud Private Cloud Foundry コンソール・ログイン・ウィンドウが表⽰されます。


https://uaa.bluemix_env_domain./

https://uaa.cf.ibm.com/

IBM Cloud Private Cloud Foundry コンソールへのログイン

ログイン・ウィンドウで、上記のステップ 5 で指定した「管理者ユーザー名 (Admin username)」と「管理者パスワード (Admin Password)」を使⽤します。ランディング・ページで、「エンドポイントの登録 (Register an endpoint)」をクリックします。ポップアップ・リストが表⽰されます。以下の値を指定して、IBM Cloud Private Cloud Foundry エンドポイント (デプロイメント) を登録します。

エンドポイント・アドレス (Endpoint Address): IBM Cloud Private Cloud Foundry API を指す URL を指定します。 https://api.BLUEMIX_ENV_DOMAIN。例: https://api.cf.ibm.com名前 (Name): 登録する IBM Cloud Private Cloud Foundry エンドポイントを表す任意のラベルを指定します。

エンドポイントの SSL 検証をスキップする (Skip SSL validation for the endpoint): IBM Cloud PrivateCloud Foundry で⾃⼰署名証明書を使⽤する場合にのみ選択します。

すべての必須フィールドを指定した後に、「登録 (Register)」をクリックします。「Cloud Foundry エンドポイント登録 (Cloud Foundry Endpoint registration)」ウィンドウが表⽰されます。⾏の右側にある 3 つの⽔平ドットをクリックし、「接続 (Connect)」をクリックします。「資格情報の指定 (Provide Credentials)」ダイアログで、「管理者ユーザー名 (Admin username)」および「管理者パスワード (Admin Password)」を指定します。資格情報を指定した後に、「接続 (Connecting)」をクリックします。これで、IBM Cloud Private Cloud Foundry コンソールを使⽤する準備ができました。

IBM® Cloud Private Cloud Foundry ops console のインストール

仮想マシンおよびコア IBM® Cloud Private Cloud Foundry ジョブに関する BOSH データを表⽰するには、IBM® CloudPrivate Cloud Foundry ops console をインストールします。

1. コンピューターに Docker CE をインストールします。『Get Docker CE for Ubuntu 』を参照してください。2. BOSH Director をインストールした場合、doctor-config.yml ファイルを取得します。

このコンピューターを使⽤して BOSH Director をデプロイした場合、doctor-config.yml ファイルは/data/CloudFoundry フォルダーにあります。インストール・プロセスでは、そのファイルが⾃動的に使⽤されます。

別のコンピューターを使⽤して BOSH ディレクターをインストールした場合、doctor-config.ymlファイルをこのコンピューターにコピーします。ファイルの場所をメモします。doctor-config.yml がない場合、インストール中に作成します。

3. Cloud Foundry ops console のインストール・ディレクトリーを作成します。このディレクトリーは、CloudFoundry ops console で⽣成された構成ファイルをホストするためのパーシスタンス・レイヤーとして使⽤されます。このインストール・ディレクトリーに対する書き込み権限が必要です。 IBM Cloud Private CloudFoundry のインストールで作成したインストール・ディレクトリーを使⽤してはなりません。

4. インストール・ファイル icp-cf-op-console-x86_64-2.1.0.tar.gz をパスポート・アドバンテージから取得します。

5. インストール・ディレクトリーに移動し、icp-cf-op-console-x86_64-2.1.0.tar.gz をそこに解凍します。

6. 以下のように、Cloud Foundry ops console の Docker イメージをインポートします。

./import_images.sh

7. Cloud Foundry ops console を開始します。

このコンピューターを使⽤して BOSH Director をデプロイした場合、以下のコマンドを実⾏します。

./launchOps.sh -b <BOM.yml> -c <installation_directory> -e LICENSE=accept


https://api.bluemix_env_domain.xn--fsq/

https://api.cf.ibm.com/

https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/


別のコンピューターを使⽤して BOSH Director をインストールした場合、以下のコマンドを実⾏します。

./launchOps.sh -b <BOM.yml> -c <installation_directory> --doctor-config /<path_to_config>/doctor-config.yml -e LICENSE=accept

doctor-config.yml ファイルがない場合、インストール中に作成できます。次のコマンドを実⾏します。

./launchOps.sh -b <BOM.yml> -c <installation_directory> -e LICENSE=accept

Cloud Foundry ops console の Docker イメージをロードしていない場合、プライベート・レジストリーまたはデフォルト・レジストリーのいずれかからイメージをダウンロードできます。デフォルト・レジストリーを使⽤する場合、<registry_name> パラメーターに値を指定しないでください。次のコマンドを実⾏します。

./launchOps.sh -b <BOM.yml> -c <installation_directory> -r <registry_name> -e LICENSE=accept

これらのコマンドで、installation_directory はインストール・ディレクトリーの絶対パスであり、docker_token は Docker トークンであり、path_to_config は doctor-config.yml ファイルの絶対パスです。

8. Docker 管理者ユーザーを追加します。次のコマンドを実⾏します。

./add_user.sh -ip <docker_container_ip> -u <user_name> -p <user_password>

このコマンドでは、docker_container_ip は、Doctor をホストしている IP アドレスです。指定する user_name および user_password パラメーターの値は、IBM® Cloud Private Cloud Foundry ops console UIへのログインに使⽤する固有の資格情報です。 OS ユーザーや IBM Cloud Private Cloud Foundry ユーザーとの関連はありません。

9. インストールが完了したことを確認します。ブラウザーで、https://localhost:9666 を開きます。

IBM® Cloud Private Cloud Foundry ops console の使⽤

IBM® Cloud Private Cloud Foundry ops consoleを使⽤すると、コマンド・ラインからは受信できない情報を表⽰できます。

Cloud Foundry ops console にアクセスするには、コンソールをインストールしておく必要があります。詳細およびインストール・ステップについては、『IBM® Cloud Private Cloud Foundry ops console のインストール』を参照してください。

Cloud Foundry ops console には、コマンド・ラインから取得できない、リソースの使⽤に関する詳細が含まれています。 Cloud Foundry ops console では、Cloud Foundry インストール済み環境全体のディスクおよびメモリーの使⽤を表⽰できます。

また、クラスター内のコンポーネントおよびアプリケーションに関する以下の詳細も取得できます。

「インスタンス」をクリックして、BOSH Director を使⽤してデプロイされた Cloud Foundry コンポーネント(ジョブ) の正常性を確認します。このページは、仮想マシンのリソース・データとインスタンスの IP アドレスの両⽅を⽰します。

「ジョブ」をクリックして、各ジョブのすべてのインスタンスとすべてのインスタンスがデプロイされている

環境のリストを表⽰します。各ジョブが使⽤するテンプレートを表⽰するには、monit コマンドを実⾏します。

「IaaS」をクリックして、Cloud Foundry インスタンス内の仮想マシン (VM) の VMware 名 (接頭部 vm- で開始する) および IP アドレスを取得します。構成ファイルから vcap 資格情報を取得した場合、「SSH コンソー


ル (SSH Console)」アイコンをクリックして、コンソールからリモートでファイルに接続できます。「ユーザーおよびアプリケーションの検索 (User & App Search)」をクリックして、特定のユーザーまたはアプリケーションに関する、メモリーの割り振り、使⽤可能なアプリケーション、使⽤される経路、割り当てら

れているサービス、およびユーザー役割を表⽰します。

IBM® Cloud Private Cloud Foundry のためのドメイン・ネーム・サービス解決の構成

IBM Cloud Private Cloud Foundry をインストールした後に、ドメイン・ネーム解決をセットアップする必要があります。

IBM Cloud Private Cloud Foundry インストール済み環境で使⽤する 2 つのドメイン (ファイル uiconfig.yml 内の bluemix_env_domain および bluemix_apps_domain) を会社の DNS サーバーに追加する必要があります。このプロセスでは、ワイルドカード・ドメインを IP アドレスに関連付けます。 IBM Cloud Private Cloud Foundry の前にロード・バランサーを使⽤している場合は、ワイルドカード・ドメインをロード・バランサーの IP アドレスに割り当てます。⼀時的なスタンドアロン DNS サーバーもセットアップできます。 IBM Cloud Private Cloud Foundry で ha_proxy 設定を使⽤する開発者インストール済み環境の場合、ha_proxy IP アドレスでワイルドカード・ドメイン・レコードを関連付けます。

注: 管理ドメインの場合にのみ、ha_proxy を介して HTTPS を使⽤できます。

ワイルドカード・ドメイン

1. ほとんどの DNS サーバー・システムでは、ドメイン・オブジェクトが作成されます。2. その場合、* とロード・バランサーまたは ha_proxy の IP アドレスを使⽤して、ドメインに A レコードが作成されます。

スタンドアロン DNS サーバーでワイルドカード・ドメインをホストする場合

⼀時 DNS サーバーを使⽤して IBM Cloud Private Cloud Foundry 管理ドメインおよびアプリケーション・ドメインをホストする場合、uiconfig-template.yml ファイル内の DNS サーバー・リストに DNS_SERVER_IP パラメーターを追加しないでください。代わりに、uiconfig-template.yml ファイルの uiconfig セクションに以下の cf_custom プロパティーを含めます。これらの stub-zones 値を指定することで、管理ドメインおよびアプリケーション・ドメインのルックアップは、⼀時 DNS サーバーに転送されます。ヒント: 必ず、サンプル・セクションで使⽤されているインデントを維持してください。

cf_custom: |+ properties: unbound: stub-zones: - (( grab bmxconfig.unbound_stub_zones.0 )) - name: (( grab bmxconfig.bluemix_env_domain )) stub-addr: DNS_SERVER_IP - name: (( grab bmxconfig.bluemix_apps_domain )) stub-addr: DNS_SERVER_IP

注: ⼀時 DNS サーバーを使⽤してホストできるのは、IBM Cloud Private Cloud Foundry 管理ドメインおよびアプリケーション・ドメインのみです。⼀時 DNS サーバーで他のドメイン名を解決することはできません。

ha_proxy IP の使⽤

IBM Cloud Private Cloud Foundry をインストールした後に、ha_proxy IP アドレスを取得できます。

1. 以下のように、BOSH CLI を使⽤して、仮想マシンの IP を表⽰します。


bosh2 -e IBMCloudPrivate -d Bluemix vms | grep ha_proxy

2. 取得した ha_proxy の IP アドレスを使⽤して、bluemix_env_domain と bluemix_apps_domain の両⽅について、DNS サーバーの A レコードを更新します。

3. launch_deployment.sh インストール・スクリプトを再度実⾏します。

別のデータベースを使⽤するための Director の構成

デフォルトでは、Director サービスには Postgres データベースが含まれています。このデータベースは、⾮クラスター化データ・ソースの単⼀インスタンスです。別の Postgres または MySQL データベースを使⽤するようにDirector サービスを構成できます。

別のデータベースを使⽤するには、custom-director.yml ファイルを変更します。 custom-director.yml ファイルは、以下のようなコードです。

jobs: - name: bosh templates: - (( delete postgress )) - (( delete registry )) properties: director: db: &db listen_address: ~ host: <host> port: <port> user: <user> password: <password> database: bosh adapter: [postgres|mysql]

custom-director.yml ファイルで、以下のパラメーターの値を指定します。

host: Postgres または MySQL サーバーの IP または FQDN。

port: データベースのポート番号。

user: データベースに接続するためのユーザー名。

password: 指定したデータベース・ユーザーのパスワード。

adapter: データベース・タイプ。 postgres または mysql を⼊⼒します。

Director データベースの構成について詳しくは、『Connecting the Director to an External Postgres Database 』を参照してください。

コンテナー・ネットワーキングの構成

IBM Cloud Private 2.1.0.3 で導⼊されたコンテナー間ネットワーキングでは、オーバーレイ・ネットワークを再使⽤してアプリケーション・インスタンス間の通信を管理し、Gorouter を経由する必要がありません。コンテナー・ネットワーキング機能の説明と詳細については、Understanding Container-to-Container Networking を参照してください。

始める前に


https://bosh.io/docs/director-configure-db.html

https://docs.cloudfoundry.org/concepts/understand-cf-networking.html

IBM® Cloud Private Cloud Foundry がインストールされていることを確認します。

注: コンテナー・ネットワーキングは、デフォルトで有効になります。

構成

また、コンテナー間ネットワーキング機能は、各アプリケーション・コンテナーに対して固有の IP アドレスを提供するほか、アプリケーション・インスタンス間で直接 IP 到達可能にします。

ご使⽤のデプロイメントでコンテナー間ネットワーキングを使⽤するには、cf コマンド・ラインを使⽤してアプリケーション・インスタンス間の通信⽤のポリシーを作成する必要があります。デフォルトでは、アプリケーション・コンテナーは相互に可視ではありません。作成するポリシーには、アプリケーション・インスタンスが Gorouter、ロード・バランサー、またはファイアウォールを経由せずに直接通信できるように、ソース・アプリケーション、宛

先アプリケーション、プロトコル、およびポートを指定します。コンテナー間ネットワーキングは UDP および TCPをサポートするので、複数のポートに対応する複数のポリシーを構成できます。これらのポリシーは、アプリケーションを再始動しなくとも即時に適⽤されます。

オプションの構成

デプロイメント要件に合わせて、以下のオプション・パラメーターを調整できます。デプロイメント内のコンテナー間ネットワーキングをカスタマイズするには、your-uiconfig.yml を編集して、以下の値を調整します。

1. cf_neworking.disable: true に設定すると、コンテナー・ネットワーキングが完全に無効になります。デフォルト値は false です。

2. cf_networking.network_cidr: オーバーレイ・ネットワークの IP 範囲を⼊⼒します。 CIDR では、RFC1918 の範囲を指定する必要があります。カスタム範囲を設定しないと、デプロイメントでは 10.255.0.0/16 が使⽤されます。

3. iptables_logging: カーネル IP テーブルのロギングをオンにするには、フラグを true に設定します。デフォルト値は false です。

4. Diego デプロイメントの状態を変更します。以下のコマンドを実⾏して、状況を READY に変更します。

./cm state -s prepare-diego set --status READY

./cm state -s deploy-diego set --status READY

5. 以下のコマンドを実⾏して、Diego のデプロイメントを再起動します。


IBM® Cloud Private Cloud Foundry のバックアップの構成

構成に応じて、バックアップは、お客様でホストしている NFS (ネットワーク・ファイル・システム) サーバーに送信されるか、nfs_WAL_server 上に保持されます。使⽤可能なスペースの観点から、NFS でホストされているバックアップを管理できます。また、バックアップの暗号化がセキュリティー・ルールの⼀部である場合、バックアップを暗号化することもできます。

バックアップについて

UAADB、CCDB、Director、およびデプロイメントのバックアップがスケジュールされます。バックアップは、nfs_WAL_server 上にローカルに取得およびポストされます。お客様でホストしている NFS サーバーにバックアップを移動する必要があるかどうかを構成で指定できます。


詳しくは、『Component: User Account and Authentication (UAA) Server 』および『Component: Cloud Controller 』を参照してください。『BOSH Backup and Restore 』で説明されているスクリプトを実装した場合、独⾃のデプロイメントをバックアップすることもできます。

UAADB/CCDB のバックアップ

バックアップは 1 時間ごとに取得され、nfs_WAL_server 上に 6 時間保持されます。お客様でホストしている NFSサーバーにバックアップをコピーする場合は、uiconfig ファイルの db_nfs_copy 属性を設定します。詳しくは、『IBM Cloud Private Cloud Foundry のインストール』を参照してください。コピー・プロセスは 1 時間ごとに実⾏され、7 ⽇分のバックアップがお客様でホストしている NFS 上で保持されます。

Director のバックアップ

uiconfig ファイルの bbr_backup 属性を設定して、バックアップのスケジュールを構成します。詳しくは、『IBMCloud Private Cloud Foundry のインストール』を参照してください。bbr_backup 属性には、デフォルト値があります。 bbr_backup 属性に指定した場合、お客様でホストしている NFS サーバーに移動できます。お客様でホストしている NFS サーバーに転送されると、nfs_WAL_server からは削除されます。

お客様でホストしている NFS サーバーを指定しなかった場合、あるいはお客様でホストしている NFS サーバーが使⽤不可である場合、bbr_backup 属性で定義されている数のバックアップが nfs_WAL_server 上に保持されます。

/var/vcap/store/bbr_backup/director ディレクトリーまたは NFS サーバー (Director のバックアップにセットアップした場合) を確認することで、バックアップが機能しているかどうかを確認できます。

リストアするには、以下の⼿順を実⾏します。

1. バックアップ .tgz ファイルがあることを確認します。バックアップが nfs_WAL_server 上にある場合、inception コンテナーに転送します。

2. director 仮想マシンを削除します。3. /data/gen-vmware_micro_boshinit-state.json ファイルを名前変更します。4. director を再インストールします。次のコマンドを実⾏します。

./cm engine reset

./cm states set-status-by-range -f deploy-director --status SKIP #これにより、deploy-director 後のすべての状態を SKIP に設定 launch_deployment.sh...

5. inception または nfs_wal_server からリストアを起動します。バックアップが nfs_WAL_server 上にもう存在しない場合、inception からの起動が有⽤です。

nfs_wal_server からリストアを起動するには、以下の⼿順を実⾏します。

1. コマンド ssh vcap@<nfs_WAL_ip> または bosh -e IBMCloudPrivate -d Bluemix ssh <nfs_WAL_server_name> を使⽤して、リモートから nfs_wal_server にログインします。 bosh -e IBMCloudPrivate vms を実⾏して、<nfs_WAL_ip> および <nfs_WAL_server_name> を⾒つけます。

2. tar xvf <file> を実⾏して、nfs の /local_backup/director ディレクトリーまたはローカル・ディスクの /var/vcap/store/cfp-backup/director のいずれかにあるバックアップを圧縮解除します。

3. リストアするには、以下のコマンドを実⾏します。 /var/vcap/packages/bbr-1.2.0/bbr director --host 192.168.247.2 --username director_backup --private-key-path /var/vcap/sys/run/cfp-backup/director_backup.key restore --artifact-path <uncompressed file>.

inception からリストアを起動するには、以下の⼿順を実⾏します。


https://docs.cloudfoundry.org/concepts/architecture/uaa.html

https://docs.cloudfoundry.org/concepts/architecture/cloud-controller.html

https://docs.cloudfoundry.org/bbr/index.html

1. 例えば、docker cp <backup_file> cfp-inception-<environment_name>:/tmp を使⽤して、バックアップを inception にコピーします。

2. コマンド ./connect.sh -n <your environment name> を使⽤して inception に接続します。

3. 以下のコマンドを実⾏して、bbr 1.2.0 をインストールします。

wget https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/download/v1.2.0/bbr-1.2.0.tar tar xvf bbr-1.2.0.tar chmod +x releases/bbr

4. 以下のコマンドを実⾏して、秘密鍵を取得します。

cat /data/CloudFoundry/certificates.yml

5. director_backup グループ属性を検索します。

6. ファイルに、キー->データの内容をコピーします。各⾏が 1 列⽬から開始していることを確認してください。

7. tar xvf <file> を実⾏して、バックアップをコピーしたディレクトリーからのバックアップを圧縮解除します。

8. リストアするには、以下のコマンドを実⾏します。

<BBR_INSTALLATION_PATH>/bbr director --host 192.168.247.2 --username director_backup --private-key-path <BACKUP_KEY_PATH>/director_backup.key restore --artifact-path <uncompressed file>.

デプロイメントのバックアップ

Bluemix デプロイメント

director バックアップとして、Bluemix のバックアップを bbr_backup 属性で構成できます (スケジュール、お客様でホストしている NFS サーバー、および保持するバックアップの数)。 Bluemix マニフェストのみがバックアップされます。

ディレクトリー /var/vcap/store/bbr_backup/deployments/Bluemix または NFS サーバー (director のバックアップに NFS サーバーをセットアップした場合) を確認することで、バックアップが機能しているかどうかを確認できます。

カスタマイズしたデプロイメント

デプロイメントで BOSH Backup and Restore を実装した場合、デプロイメントを⾃動的かつ定期的にバックアップするために cf_custom 属性を設定できます。

cf_custom: |+ properties: bbr_backup: deployment_backup: deployments: - (( grab bmxconfig.bbr_backup.deployments_backup.deployments.0 )) #これにより、Bluemix のバックアップに進む - name: YourDeployment schedule: "* 3 * * *" nb_backups: 15 nb_logs: 15 max_log_size: 10000


https://docs.cloudfoundry.org/bbr/index.html

ディレクトリー /var/vcap/store/bbr_backup/deployments/<YourDeploymentName> または NFS サーバー(director のバックアップにセットアップした場合) を確認して、バックアップが機能しているかどうかを確認できます。

IBM Cloud Private Cloud Foundry のアベイラビリティー・ゾーンの構成

IBM Cloud Private 2.1.0.3 で導⼊されたアベイラビリティー・ゾーンは、オペレーターによって割り当てられる、ネットワーク・インフラストラクチャーの機能的に独⽴したセグメントです。アベイラビリティー・ゾーンにより、IBM Cloud Private Cloud Foundry デプロイメントのフォールト・トレランスおよび⾼可⽤性を実現できます。

アベイラビリティー・ゾーンおよびその実装について詳しくは、『High Availability in Cloud Foundry 』および『Availability Zones 』を参照してください。

始める前に

注: デフォルトでは、3 つのアベイラビリティー・ゾーンが有効になっていて、デプロイされています。 3 つすべてのアベイラビリティー・ゾーンが、同じデータ・センターにデプロイされるように構成されています。デフォルトでは、デプロイメントでは、ラウンドロビン⽅式によって、すべてのアベイラビリティー・ゾーンで各インスタンス・

グループに指定されるインスタンスの数を均等に分配しようとします。

カスタマイズしたアベイラビリティー・ゾーンをデプロイする場合は、カスタム構成に関するセクションを参照して

ください。

構成のカスタマイズ

1. uiconfig.yml の azs_definition フィールドで、以下のスタンザを追加します。必要に応じて、スタンザを複製することで、複数のアベイラビリティー・ゾーンを記述できます。以下のクラウド・プロバイダー・オプションを参照してください。

VMware

azs: - name: AVAILABILITY_ZONE_NAME_1 cloud_properties: datacenters: - name: DATACENTER_NAME_1 - clusters: [{CLUSTER_NAME_1: {resource_pool: RESOURCE_POOL_NAME_1}}] - name: AVAILABILITY_ZONE_NAME_2 cloud_properties: datacenters: - name: DATACENTER_NAME_2 - clusters: [{CLUSTER_NAME_2: {resource_pool: RESOURCE_POOL_NAME_2}}]

Openstack

azs: - name: AVAILABILITY_ZONE_NAME_1 cloud_properties: availability_zone: OPENSTACK_AVAILABILITY_ZONE_1 - name: AVAILABILITY_ZONE_NAME_2 cloud_properties: availability_zone: OPENSTACK_AVAILABILITY_ZONE_2

2. オプション: インスタンスの分配およびそのアベイラビリティー・ゾーンの配置を変更する場合は、『アベイラビリティー・ゾーンおよびインスタンスの例』セクションを参照してください。


https://docs.cloudfoundry.org/concepts/high-availability.html

https://bosh.io/docs/azs/

3. デプロイメント・エンジンをリセットします。以下のコマンドを実⾏して、状況を READY に変更します。

./cm engine reset

4. 以下のコマンドを実⾏して、デプロイメントを再起動します。

./launch.sh -c <data_folder_absolute_path> -n <director_name> -b ./BOM.yml

次に、以下を実⾏します。


アベイラビリティー・ゾーンおよびインスタンスの例

インスタンスの分配およびそのアベイラビリティー・ゾーンの配置を変更する場合は、デプロイメントの cf-deploy.yml を変更します。

注: インスタンスの数は標準的な実動デプロイメント⽤にバランスが取られているため、cf-deploy.yml の変更は必須ではありません。

各インスタンス・グループは、cf-deploy.yml ファイルでインスタンスが配置されているゾーンを定義するアベイラビリティー・ゾーンのリスト (azs:) を受け⼊れます。以下の⼿順および例を参照してください。

1. インスタンスを 1 つのアベイラビリティー・ゾーン (以下の例では z2) に隔離できます。

... instance_groups: - name: consul instances: 3 azs: [z2] migrated_from: - { name: consul } ...

2. 以下のように、Bosh で 1 つのインスタンスをすべてのアベイラビリティー・ゾーン (例えば、z1、z2、および z3) にデプロイできます。

... - name: consul instances: 3 azs: [z1, z2, z3] migrated_from: - { name: consul } ...

3. 以下によって、Bosh で 1 つのインスタンスを除外し、z1 と z2 にインスタンスが 1 つずつ含まれるようにすることができます。インスタンス数に注⽬してください。インスタンスは、z3 アベイラビリティー・ゾーンにデプロイされません。

... - name: consul instances: 2 azs: [z1, z2, z3] migrated_from: - { name: consul } ...

Diego セルの数を増やす

アプリケーションのデプロイ後、環境内の Diego セルの数を増やす必要が⽣じることがあります。


注: 開発者モードで使⽤できる Diego セルは 1 つのみです。

始める前に

IBM® Cloud Private Cloud Foundry がデプロイされていることを確認します。

ステップ

1. your-uiconfig.yml ファイルを編集します。 diego_cell_instances パラメーターの値を⼤きくし、変更を保存します。

2. Diego デプロイメントの状態を変更します。以下のコマンドを実⾏して、状況を READY に変更します。

./cm state -s prepare-diego set --status READY

./cm state -s deploy-diego set --status READY

3. 以下のコマンドを使⽤して、Diego のデプロイメントを再起動します。


注: 追加のセルのデプロイには、数分かかることがあります。

IBM® Cloud Private Cloud Foundry ops console ⽤のコマンド・ライン・インターフェース

IBM® Cloud Private Cloud Foundry を使⽤するには、いくつかのコマンド・ライン・インターフェース (CLI) をインストールする必要が⽣じる場合があります。

BOSH: デプロイされているすべての仮想マシンを管理する BOSH Director を管理するには、この CLI を使⽤します。

Cloud Foundry (Cloud Foundry CLI): コア Cloud Foundry コマンドを実⾏するには、この CLI を使⽤します。

BOSH

BOSH CLI をインストールするには、『BOSH Command Line Interface 』を参照してください。

BOSH CLI コミュニティーの資料

役に⽴つ BOSH コマンド

BOSH Director をターゲット指定する。接続されているネットワークを介して director_ip IP アドレスに到達できる必要があります。

bosh2 alias-env IBMCloudPrivate -e https://<director_ip>:25555

BOSH2 CLI を BOSH Director に対して認証する。以下のコマンドでは、ユーザー名は admin であり、パスワードはインストール構成ディレクトリーの ./CloudFoundry フォルダーにある credentials.yml ファイル内の credentials.boshdirector.bosh.password パラメーターの値です。

export BOSH_ENVIRONMENT=IBMCloudPrivate bosh2 login

bosh2 logout

接続されている Director によって現在管理されている BOSH デプロイメントをリストする。


https://bosh.io/docs/bosh-cli.html

https://bosh.io/docs

bosh2 deployments

デプロイメントに関連付けられている仮想マシンをリストする。

bosh2 -d DEPLOYMENT_NAME vms [--details | --vitals]

単⼀のコマンドで、BOSH デプロイメントをターゲット指定する。

bosh2 -d DEPLOYMENT BOSH_COMMAND

BOSH デプロイメント・マニフェスト・ファイルを永続的にターゲット指定する。

export BOSH_DEPLOYMENT=DEPLOYMENT_NAME

デプロイメントのマニフェストをエクスポートする。

bosh2 -d DEPLOYMENT_NAME download manifest MANIFEST_FILE.yml

最近の BOSH タスクをリストする。

bosh2 tasks recent

BOSH task ID 番号のリストが表⽰されます。

BOSH タスクの詳細を表⽰する。

bosh2 task ID_NUMBER

最近の BOSH タスクを表⽰することで、タスク番号のリストを取得できます。

Cloud Foundry

Installing the cf CLI

Cloud Foundry コマンド・ライン・インターフェース (cf CLI)

役に⽴つ Cloud Foundry コマンド

Cloud Foundry プラットフォームをターゲット指定する。

cf api https://api.<YOUR_DOMAIN>

Cloud Foundry CLI を Cloud Foundry プラットフォームに対して認証する。

cf login

cf logout

さらなるコマンドを表⽰する。

cf -h

特別な考慮事項最新バージョンの Cloud Foundry CLI では、set-org-role および set-space-role は正しく機能しません。これらのコマンドを実⾏する場合は、バージョン 6.13 の Cloud Foundry CLI を使⽤してください。

IBM® Cloud Private Cloud Foundry との統合の構成

インストールの前または後に、IBM Cloud Private Cloud Foundry の認証を構成できます。

IBM® Cloud Private Cloud Foundry での Cloud Foundry App Autoscaler の使⽤


https://docs.cloudfoundry.org/cf-cli/install-go-cli.html

https://docs.cloudfoundry.org/cf-cli/

IBM® Cloud Private Cloud Foundry syslog と Splunk の統合 Cloud Foundry アプリケーションとしての Splunk Firehose Nozzle リリースの構成 IBM® Cloud Private Cloud Foundry syslog と ELK スタックの統合 Prometheus への IBM® Cloud Private Cloud Foundry の接続

IBM® Cloud Private Cloud Foundry での Cloud Foundry AppAutoscaler の使⽤

IBM® Cloud Private Cloud Foundry アプリケーションと App Autoscaler を統合できます。

App Autoscaler は、アプリケーションのパフォーマンスを維持しながら、アプリケーション実⾏のコストを制御するために使⽤できるマーケットプレイス・サービスです。

アプリケーションのパフォーマンスとコストのバランスを取るために、スペース開発者は App Autoscaler を使⽤して以下のタスクを実⾏できます。

CPU 使⽤量などのメトリックのしきい値に基づいてインスタンス数を調整するルールを構成する。アプリケーションのインスタンスの最⼤数および最⼩数を⼿動で、またはスケジュールに従って変更する。

App Autoscaler は合計で 5 つのリリースを使⽤します。 cfp-cf-release および unbound リリースは、IBM CloudPrivate Cloud Foundry で提供されています。さらに 2 つのリリース postgres および cf-routing-release は、ダウンロードして inception コンテナー上のディレクトリーに移動します。最後のリリースは、App Autoscaler リリースであり、app-autoscaler-release/src ディレクトリーに含まれています。

注: この説明では、データベースが⾃動スケーリング⽤にまだセットアップされていないものと想定しています。既にデータベースがセットアップされている場合は、必ず、アドレスおよび表を正しいデータベースにマップするよう

に manifests/db-stub-override.yml ファイルを構成し、manifests/property-overrides.yml ファイル内の default_db 値が正しいデータベースにリンクされた状態にしてください。

App Autoscaler をインストールするための前提条件

1. Bosh および IBM Cloud Private Cloud Foundry コマンド・ラインをインストールします。『IBM® CloudPrivate Cloud Foundry ops console ⽤のコマンド・ライン・インターフェース』を参照してください。

2. 拡張機能を作成する際に、postgres および cf-routing-release リリースをダウンロードできるように、インターネット・アクセスを⽤意します。

postgres を postgres v17 新しいタブで開くからダウンロードします。cf-routing-release を cf-routing-release v162 新しいタブで開くからダウンロードします。

3. データベースの静的 IP アドレスを構成します (複数のデータベースをサポートするには、カスタマイズが必要です)。

1. 使⽤する静的 IP アドレスを決定します。2. cloud-config.yml を開き、静的 IP アドレスを追加します。3. networks.subnets.reserved 配列を調整し、新規静的 IP アドレス、および必要な他の⾃動スケーリング・ジョブ⽤の 7 つの追加アドレスを含めます。合計 8 つの IP アドレスが必要です。

4. cloud-config.yml ファイルを再デプロイし、更新された IP アドレスを含めます。次のコマンドを実⾏します。

bosh2 -e ENVIRONMENT_NAME update-cloud-config /data/CloudFoundry/cloud-config.yml

App Autoscaler のインストール

App Autoscaler は、Platform Configuration Manager を介して拡張機能としてデプロイします。拡張機能について詳しくは、『IBM® Cloud Private Cloud Foundry での拡張機能の使⽤』を参照してください。


https://bosh.io/d/github.com/cloudfoundry/postgres-release?v=17

https://bosh.io/d/github.com/cloudfoundry-incubator/cf-routing-release?v=0.162.0

1. App Autoscaler ソース・コードが含まれる Git リポジトリーを inception コンテナー・ホスト内に複製します。以下のコマンドを実⾏して、Git リポジトリーを複製します。

git clone https://github.com/jnpacker/app-autoscaler-release.git

2. 以下のように、端末で、複製したファイルの app-autoscaler-release フォルダーに移動します。

cd app-autoscaler-release

3. manifest/property-override.yml ファイルを確認し、必要なすべてのプロパティー値をカスタマイズします。ポート、ユーザー名、およびパスワードが正しいことを確認します。以下のプロパティーを確認して更新します。

cf_properties.apidefault_db.addressservice_broker_properties.uriservice_broker_properties.portservice_broker_properties.usernameservice_broker_properties.passworddefault_db.password

4. 拡張機能を作成します。端末で以下のコマンドを実⾏します。

make extension

5. IBM Cloud Private Cloud Foundry のインストール・コンテナーを実⾏しているサーバーに app-autoscaler-extension.zip ファイルをコピーします。

6. サーバーで対話式の bash シェルを開きます。

7. bash シェルで、拡張機能を登録します。 install.sh と同じディレクトリーで作業する必要があります。次のコマンドを実⾏します。

./cm extension -e app-autoscaler register -p ./app-autoscaler-extension.zip

8. bash シェルで、拡張機能をデプロイします。次のコマンドを実⾏します。

./cm extension -e app-autoscaler deploy

9. すべてのステップが SUCCEEDED 状況であることを確認します。以下のコマンドを実⾏し、出⼒を確認します。

./cm states -e app-autoscaler

App Autoscaler の登録

1. App Autoscaler サービスを登録します。 admin ユーザーとして {{site.data.keyword.cf_notm}} にログインし、以下のコマンドを実⾏します。

cf create-service-broker autoscaler <brokerUserName> <brokerPassword> <brokerURL>


<brokerUserName> は、サービス・ブローカーに認証するユーザー名です。<brokerPassword> は、サービス・ブローカーに認証するためのパスワードです。<brokerURL> は、サービス・ブローカーの URL です。

デフォルトの <brokerUserName> 値は username であり、デフォルトの <brokerPassword> 値は password であり、デフォルトの <brokerURL> 値は http://autoscalerservicebroker.YOUR_DOMAINです。


デフォルト値を使⽤した場合、以下のコマンドを実⾏します。

cf create-service-broker autoscaler username password http://autoscalerservicebroker.YOUR_DOMAIN

2. このサービスを使⽤してアプリケーションを⾃動スケーリングするには、{{site.data.keyword.cf_notm}} にadmin ユーザーとしてログインし、組織に対してサービスへのアクセスを有効にします。以下のコマンドを実⾏して、すべての組織または特定の組織に対してサービスへのアクセスを有効にします。

cf enable-service-access autoscaler -o <org>

ここで、<org> は、メンバーがサービスを使⽤できる 1 つ以上の組織です。

3. スペース開発者役割を備えているユーザーとして、サービス・インスタンスを作成します。

cf create-service autoscaler autoscaler-free-plan <service_instance_name>

ここで、<service_instance_name> は、サービス・インスタンスに割り当てる名前です。

⾃動スケーリング・ポリシーの作成

1. ⾃動スケーリング・ポリシー・ファイルを作成します。⾃動スケーリング・ポリシー・ファイルは、⾃動スケーリング・ルールを定義したパラメーターが含まれている JSON フォーマットのファイルです。この JSON ファイルは、以下のようなコードです。

{ "instance_min_count": 1, "instance_max_count": 5, "scaling_rules": [{ "metric_type": "memoryutil", "stat_window_secs": 300, "breach_duration_secs": 600, "threshold": 30, "operator": "<", "cool_down_secs": 300, "adjustment": "-1" }, { "metric_type": "memoryutil", "stat_window_secs": 300, "breach_duration_secs": 600, "threshold": 55, "operator": ">=", "cool_down_secs": 300, "adjustment": "+1" }], "schedules": { "timezone": "America/Los_Angeles", "recurring_schedule": [{ "start_time": "01:00", "end_time": "23:00", "days_of_week": [ 1, 2, 3, 4, 5, 6, 7 ], "instance_min_count": 1, "instance_max_count": 5, "initial_min_instance_count": 5 }], "specific_date": [{


"start_date_time": "2016-06-02T10:00", "end_date_time": "2018-06-15T13:59", "instance_min_count": 1, "instance_max_count": 4, "initial_min_instance_count": 1 }] } }

このファイルには、複数のセクションがあります。その中で、instance_min_count 値 (インスタンスの最⼩数) および instance_max_count (インスタンスの最⼤数) を定義します。 scaling_rules セクションでは、複数のスケーリング基準を定義できます。schedules セクションでは、曜⽇に基づいて繰り返しのスケジュールを定義したり、特定の⽇または時刻範囲の単⼀スケジュールを定義したりすることができます。複数のスケーリング・ルールまたはスケジュールを指定できますが、それらの定義のそれぞれに、すべての指定パ

ラメーターが含まれている必要があります。以下の表に、該当するパラメーターに関する詳細を⽰します。

表 1. ⾃動スケーリング・ポリシーのパラメーターパラメータ

ー説明値

instance_min_count

アプリケーション・インスタンスの最⼩数。正整数

instance_max_count

アプリケーション・インスタンスの最⼤数。正整数

scaling_rules

どのようなときに新規アプリケーションが作成また

は削除されるのかを定義した⼀連のルール。

配列

metric_type

memoryusedmemoryutilresponsetimethroughput

stat_window_secs

__ (秒)。正整数

breach_duration_secs


threshold アプリケーション・インスタンスの数をいつ変更するのかの制限。

正整数

operator <>

cool_down_secs


adjustment

インスタンス数の変更量。特定の数のインスタンスずつ、またはインスタンス総数の特定のパーセン

トのインスタンスずつ、増減できます。

-99 から -1 および 1 から 99 の整数正または負のパーセンテージ

schedules 新規アプリケーションをそれぞれの⽇時で作成または削除する⽅法を定義した⼀連のルール。

配列

timezone サーバーのタイム・ゾーン。 ???recurring_schedulestart_time

ルールの適⽤を開始する時刻。 24 時間制の時刻 (01:00 など)

end_time ルールの適⽤を終了する時刻。 24 時間制の時刻 (023:00 など)days_of_week

スケジュールが適⽤される曜⽇。ここでは、⽇曜⽇を 1 と表し、他の曜⽇も順次数値で表す

1 から 7


パラメータ

ー説明値

initial_min_instance_count

期間の開始時におけるインスタンスの最⼩数。正整数

specific_date

特定の時刻範囲に適⽤する⾃動スケーリング・ポリ

シー

配列

start_date_time

このポリシーの適⽤を開始する時刻。以下の形式の⽇時: <four_digit_year>-<two_digit_month>-<two_digit_day>T<hour>:<minute> (例えば、2018-06-15T13:59)

end_date_time

このポリシーの適⽤を終了する時刻。以下の形式の⽇時: <four_digit_year>-<two_digit_month>-<two_digit_day>T<hour>:<minute> (例えば、2018-06-15T13:59)

1. スペース開発者役割を備えているユーザーとして、既存のアプリケーションをサービス・インスタンスにバインドします。

cf bind-service <app_name> <service_instance_name> -c <policy>


<app_name> は、⾃動スケーリングするアプリケーションの名前です。<service_instance_name> は、App Autoscaler のサービス・インスタンスの名前です。<policy> は、適⽤するポリシー・ファイルのパス (/data/extension/custom/app-autoscaler/example/example-policy.json など) です。

これで、サービスがアプリケーションにバインドされ、policy.json ファイルに定義されている条件に従って⾃動的にスケーリングされるようになりました。


以下のサービスを削除する必要がある場合、以下のアクションを実⾏します。

1. {{site.data.keyword.cf_notm}} に admin ユーザーとしてログインします。2. 次のコマンドを実⾏します。

cf purge-service-offering autoscaler ; \ cf delete-service-broker autoscaler

App Autoscaler のトラブルシューティング

リリースの作成に失敗する

症状

App Autoscaler をデプロイすると、以下のエラー・メッセージが表⽰されます。

Building a release from directory '/data/extensions/custom/app-autoscaler': Compressing staging directory: Shelling out to tar: Running command: 'tar czf /data/home/.bosh/tmp/bosh-platform-disk-TarballCompressor-CompressSpecificFilesInDir114079115 -C /data/home/.bosh/tmp/bosh-resource-archive204470236 .', stdout: '', stderr: ' gzip: stdout: No space left on device ':


signal: broken pipe Exit code 1 state:Create Release

原因

/data/home/.bosh/tmp ディレクトリーがいっぱいです。

問題の解決

以下のコマンドを実⾏して、BOSH ⼀時ディレクトリーをクリアします。

rm -rf /data/home/.bosh/tmp

リリースの作成中に URL にアクセスできない

症状

App Autoscaler をデプロイすると、以下のエラー・メッセージが表⽰されます。org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute INFO: Retrying request to {s}->https://repo.spring.io:443

原因

inception コンテナーがセキュア・リポジトリーに到達しようとしているときに問題が発⽣しています。

問題の解決

1. /data/extensions/custom/app-autoscaler/src/app-autoscaler/scheduler/ フォルダー内の pom.xml ファイルを開きます。

2. すべての https の記述を http に変更します。3. 以下のように、デプロイメント・コマンドを再度実⾏します。

/opt/ibm/cloud/bin/cm extension -e app-autoscaler deploy

IBM® Cloud Private Cloud Foundry syslog と Splunk の統合

Splunk Enterprise を使⽤している場合、IBM Cloud Private Cloud Foundry アプリケーション・ログと Splunk を統合できます。

Cloud Foundry は RFC5425 syslog プロトコルを使⽤しているため、このプロトコルをサポートする Splunk アドオンをインストールする必要もあります。

Docker を使⽤した Splunk Enterprise のインストール

1. Docker をインストールします。『Install Docker』を参照してください。

2. 以下のように、Docker Hub から Splunk イメージをプルします。

docker pull splunk/splunk

3. 以下のように、Splunk を開始します。



docker run -d -e "SPLUNK_START_ARGS=--accept-license" -e "SPLUNK_USER=root" -p "8000:8000" -p "12345:12345" splunk/splunk

このコマンドにおいて、8000 は Splunk UI が実⾏されるデフォルト・ポートであり、12345 は CloudFoundry からシステム・ログを受け取る TCP ポートです。 TCP ポートには任意の使⽤可能なポートを使⽤できます。

4. Splunk が実⾏中であることを確認するために、ブラウザーで http://localhost:8000 を開きます。デフォルトのログイン資格情報は admin:changeme です。

Cloud Foundry から syslog を受け取るための Splunk の構成

1. Splunk の RFC5424 syslog アドオンをダウンロードします。アドオンをダウンロードするには、Splunk アカウントが必要です。『RFC5424 Syslog』を参照してください。

2. rfc5424-syslog_11.tar ファイルを解凍します。

tar -xvzf rfc5424-syslog_11.tgz

3. ./rfc5424/default/transforms.conf ファイルを開き、その内容を以下のテキストに置き換えます。

[rfc5424_host] DEST_KEY = MetaData:Host REGEX = <\d+>\d{1}\s{1}\S+\s{1}(\S+) FORMAT = host::$1 [rfc5424_header] REGEX = <(\d+)>\d{1}\s{1}\S+\s{1}\S+\s{1}(\S+)\s{1}(\S+)\s{1}(\S+) FORMAT = prival::$1 appname::$2 procid::$3 msgid::$4 MV_ADD = true

4. Splunk コンテナー⽤の Docker containerId を取得します。

docker ps -aqf "ancestor=splunk/splunk"

5. rfc5424 フォルダーを Splunk ⽤の Docker コンテナーにコピーします。

docker cp rfc5424 <containerId>:/opt/splunk/etc/apps

6. Docker コンテナーを再始動します。

docker restart <containerId>

7. ブラウザーで http://localhost:8000 を開き、Splunk にログインします。

8. 「Add Data」>「Monitor」>「TCP / UDP」をクリックします。9. Splunk の開始時に指定した TCP ポート (12345 など) を「TCP Port」で選択し、「Next」をクリックします。

10. 「Source Type」で「rfc545_syslog」を選択し、「Review and Submit」をクリックします。11. IBM Cloud Private Cloud Foundry からデータを Splunk に送信するために、「Start Searching」をクリックします。

Splunk への IBM Cloud Private Cloud Foundry からの syslog の送信

1. CLI で Cloud Foundry にログインします。

2. 以下のように、Splunk ⽤のユーザー提供のサービスを作成します。

cf create-user-provided-service <SERVICE-NAME> -l syslog://<splunkipaddress>:<port>

ここで、<SERVICE-NAME> は Splunk サービスの名前であり、<splunkipaddress> は Splunk で使⽤している IP アドレスであり、<port> は Cloud Foundry が Splunk への syslog の送信に使⽤する TCP ポートです。


https://splunkbase.splunk.com/app/978/

3. 以下のように、このサービスを既存の Cloud Foundry アプリケーションにバインドします。

cf bind-service <CF-APP-NAME> <SERVICE-NAME>

ここで、<SERVICE-NAME> は Splunk サービスの名前であり、<CF-APP-NAME> は Cloud Foundry アプリケーションの名前です。

4. 以下のように、Cloud Foundry アプリケーションを再ステージします。

cf restage <CF-APP-NAME>

5. sourcetype=rfc5424_syslog を検索して、Splunk で Cloud Foundry ログにアクセスできることを確認します。

Cloud Foundry アプリケーションとしての Splunk Firehose Nozzleリリースの構成

IBM® Cloud Private Cloud Foundry コンポーネント・メトリック、アプリケーション・ログ、およびアプリケーション・メトリックを Splunk に送信するように splunk-firehose-nozzle コミュニティー・アプリケーションを構成できます。

Splunk Firehose Nozzle アプリケーションをインストールする前に、コンテナーに Splunk をインストールする必要があります。 Splunk がインストールされていない場合、Docker を使⽤してインストールできます。 Splunk を既に使⽤している場合、Splunk Marketplace を介して Cloud Foundry ⽤の Splunk アドオンを構成できます。

Splunk のインストール

1. Docker をインストールします。『Install Docker 』を参照してください。

2. Docker Hub から Splunk イメージをプルします。

docker pull splunk/splunk

3. 以下のように Splunk を開始します。

docker run -d -e "SPLUNK_START_ARGS=--accept-license" -e "SPLUNK_USER=root" -p "8000:8000" -p "8088:8088" splunk/splunk

この例では、8000 は Splunk UI が実⾏されているデフォルト・ポートを表しており、8088 は nozzle からログを受け取る HTTP Event Collector ポートです。

4. Splunk が実⾏中であることを確認するために、ブラウザーで http://localhost:8000 を開き、ログインします。デフォルトのユーザー名は admin、デフォルトのパスワードは chageme です。

Cloud Foundry ⽤の Splunk アドオンのインストール

1. 以下のように、Cloud Foundry ⽤の最新の Splunk アドオンを複製します。

git clone [email protected]:splunk/splunk-addon-for-cloud-foundry.git

2. 以下のように、Splunk の Docker containerId を取得します。

docker ps -aqf "ancestor=splunk/splunk"

3. 複製した Splunk\_SA\_CloudFoundry フォルダーを Docker コンテナーにコピーします。



docker cp splunk-addon-for-cloud-foundry/Splunk_SA_CloudFoundry <containerId>:/opt/splunk/etc/apps

取得した Splunk の <containerId> 値を使⽤します。

4. Docker コンテナーを再始動します。

docker restart <containerId>

5. http://localhost:8000 で Splunk ダッシュボードを開きます。アドオンがインストールされている場合、「Splunk add-on for Cloud Foundry」というタイトルの新規アイコンが表⽰されます。

Splunk HTTP Event Collector の構成

Splunk HTTP Event Collector を使⽤して HTTP からのデータを Splunk に送信します。この場合、Cloud Foundry システム・ログを送信できます。

1. Splunk ダッシュボードで、「Settings」>「Data inputs」をクリックします。2. 「HTTP Event Collector」セクションで、「Add new」をクリックします。3. データ⼊⼒の名前を⼊⼒し、「Next」をクリックします。4. 「Source type」リストで「Automatic」を選択します。5. 「Index」で、「Default」などの既存のインデックスを選択するか、新規インデックスを作成します。6. 「Review」をクリックしてから、「Submit」をクリックします。7. 「Generated Token Value」を保存します。8. 以下のように、HTTP Event Collector を有効にします。

1. 「Settings」>「Data inputs」をクリックします。2. 「HTTP Event Collector」をクリックします。3. 「Global Settings」をクリックします。4. 「All Tokens」セクションで「Enabled」をクリックしてから、「Save」をクリックします。

9. これで、Splunk がポート 8088 を使⽤して HTTP を介してログを受け取る準備ができました。注: 別のポートを使⽤する場合は、「Global Settings」でその値を指定できます。

Splunk Firehose Nozzle リリース・アプリケーションの構成およびデプロイ

1. splunk-firehose-nozzle アプリケーションを GitHub から複製します。

git clone https://github.com/cloudfoundry-community/splunk-firehose-nozzle.git cd splunk-firehose-nozzle

2. 以下のように、Cloud Foundry にログインします。

cf login -a https://api.<your cf system domain> -u <your Cloud Foundry id>

Cloud Foundry コマンド・ライン・インターフェースがインストールされていない場合は、『IBM® CloudPrivate Cloud Foundry ops console ⽤のコマンド・ライン・インターフェース』を参照してください。

3. 「nozzle_manifest」ファイルを変更します。

vi ci/nozzle_manifest.yml

API_ENDPOINT: Cloud Foundry API エンドポイント・アドレス。API_USER: Cloud Foundry ユーザー名。API_PASSWORD: Cloud Foundry ユーザー・パスワード。SPLUNK_TOKEN: Set up and use HTTP Event Collector SPLUNK_HOST: Splunk HTTP Event Collector ホスト (https://example.cloud.splunk.com:8088 など)。SPLUNK_INDEX: イベントの送信先の Splunk インデックス。FIREHOSE_SUBSCRIPTION_ID: Firehose サブスクリプション ID で nozzle イベントをタグ付けします。『Loggregator Guide for Cloud Foundry Operators 』を参照してください。 Nozzle には、スコー


http://docs.splunk.com/Documentation/SplunkCloud/6.6.3/Data/UsetheHTTPEventCollector

https://example.cloud.splunk.com:8088/

https://docs.pivotal.io/pivotalcf/1-11/loggregator/log-ops-guide.html

プが「doppler.firehose」および「cloud_controller.admin_read_only」(「ADD_APP_INFO」値が「true」の場合) であるユーザーが必要です。「cloud_controller.admin_read_only」がシステムで使⽤可能でない場合は、「cloud_controller.admin」値の使⽤に切り替えます。

4. nozzle をプッシュします。

make deploy-nozzle

IBM® Cloud Private Cloud Foundry syslog と ELK スタックの統合

ELK (Elasticsearch、Logstash、Kibana) スタックを使⽤している場合、IBM Cloud Private Cloud Foundry アプリケーション・ログを統合できます。

Docker を使⽤した ELK スタックのインストール

1. Docker をインストールします。『Install Docker 』を参照してください。

2. Docker ELK スタックをインストールします。 Docker ELK スタックを参照してください。

3. 以下のように、Docker ELK スタックを複製します。

git clone https://github.com/deviantony/docker-elk

4. 以下のように、複製したリポジトリーに移動し、Docker ELK スタックを開始します。

cd docker-elk ; docker-compose up -d

デフォルトでは、このスタックによって以下のポートが公開されます。

5000: Logstash TCP ⼊⼒9200: Elasticsearch HTTP9300: Elasticsearch TCP トランスポート5601: Kibana

5. Kibana が実⾏中であることを確認するために、ブラウザーで http://localhost:5601 を開きます。

Cloud Foundry から syslog を受け取るための ELK の構成

Cloud Foundry は RFC5425 syslog プロトコルを使⽤します。 RFC5425 標準の Elasticsearch でのマッピングを作成するために、ELK デプロイメントの Logstash 構成ファイルの末尾に構成フィルターを追加します。

1. 次のコマンドを実⾏します。ここで、<docker-elk-clone-dir> は、docker-elk リポジトリーの複製先ディレクトリーです。

cat /<docker-elk-clone-dir>/elk/logstash/pipeline/logstash.conf

1. 以下のフィルター・テキストをファイルの末尾に追加します。

filter { if [type] == "syslog" { grok { match => { "message" => "%{SYSLOG5424PRI}%{NONNEGINT:syslog5424_ver} +(?:%{TIMESTAMP_ISO8601:syslog5424_ts}|-) +(?:%{HOSTNAME:syslog5424_host}|-) +(?:%{NOTSPACE:syslog5424_app}|-) +(?:%{NOTSPACE:syslog5424_proc}|-) +(?:%{WORD:syslog5424_msgid}|-) +(?:%{SYSLOG5424SD:syslog5424_sd}|-|) +%{GREEDYDATA:syslog5424_msg}" } } syslog_pri { } date { match => [ "syslog_timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss" ] }



https://github.com/deviantony/docker-elk

if !("_grokparsefailure" in [tags]) { mutate { replace => [ "@source_host", "%{syslog_hostname}" ] replace =>[ "@message", "%{syslog_message}" ] } } mutate { remove_field => [ "syslog_hostname", "syslog_message", "syslog_timestamp" ] } } }

2. ファイルを保存して終了します。

ELK スタックへの IBM Cloud Private Cloud Foundry からの syslog の送信

1. uiconfig.yml ファイルで、cf_custom:{name: cf_custom, value:""} を以下のテキストに置き換えます。 <ip> は ELK デプロイメントの IP アドレスであり、port 値はログの受け取りに使⽤する Logstash TCP⼊⼒ポートであり、transport 値はログの送信に使⽤するトランスポート・プロトコルです。

cf_custom: | --- properties: syslog_daemon_config: address: <ip> port: 5000 transport: tcp

1. cfp-build デプロイメントを再デプロイします。詳しくは、『IBM Cloud Private Cloud Foundry のアップグレード』を参照してください。

Prometheus への IBM Cloud Private Cloud Foundry の接続

IBM® Cloud Private Cloud Foundry Prometheus エクスポーターを使⽤して、IBM Cloud Private Cloud Foundry モニター・データを集約します。エクスポーターは BOSH、IBM Cloud Private Cloud Foundry、および Firehose モニター・プールからデータを抽出し、IBM Cloud Private Cloud Foundry デプロイメントの正常性に関する情報を提供します。 IBM Cloud Private Cloud Foundry 環境にこれらのエクスポーターをインストールするには、ibm-cf-exporters-prod Helm チャートをインストールします。

前提条件

ベータ API が有効になっている Kubernetes 1.4 以降。以下のステップを実⾏します。

Kubernetes にログインします。右上隅にあるユーザー・アイコンをクリックし、「クライアントの構成 (Configure client)」を選択します。

kubectl コマンド・ライン・インターフェース (CLI) がまだインストールされていない場合はインストールします。

CLI を構成するためのコマンドをコピー・アンド・ペーストします。

注: IBM Cloud Private Cloud Foundry エクスポーターをホストするために使⽤する名前空間で、--namespace の値を更新します。

bx CLI をインストールします。詳しくは、IBM Cloud Developer Tools 概要を参照してください。


https://console.bluemix.net/docs/cli/index.html#cli

IBM® Cloud Private bx プラグインをダウンロードします。 IBM Cloud Private コンソールで、「コマンド・ライン・ツール」>「Cloud Private CLI」をクリックします。bx IBM Cloud Private プラグインをインストールします。詳しくは、『IBM® Cloud Private CLI のインストール』を参照してください。

Helm CLI をインストールします。詳しくは、『Helm CLI のセットアップ』を参照してください。IBM Cloud Private Cloud Foundry をデプロイします。

チャートのインストール

始める前に

有効な values.yaml ファイルがなければなりません。注: values.yaml ファイルは、Helm チャートの他のファイルとともに、インストール構成ディレクトリーにあります。 IBM Cloud Private Cloud Foundry のインストール時に launch.sh を実⾏したときに、-c 引数でこのディレクトリーを指定しました。インストール構成ディレクトリーに移動してから、IBMCloudPrivate/ibm-cf-exporters-prod ディレクトリーに移動します。

values.yaml および ibm-cf-exporters-prod Helm チャートは、ここにあります。

構成

以下の表では、ibm-cf-exporters-prod チャートの構成可能パラメーターおよびそのデフォルト値をリストします。

これらのパラメーターは、Helm チャートをインストールする前に構成する必要があります。これらのパラメーターは、values.template_yaml で定義されている環境変数にマップされます。インストール後、すべての yaml ファイルは、インストール構成ディレクトリー内にあります。

パラメーター説明デフォルト

cf_api_url Cloud Foundry API URL https://api.DOMAIN DOMAIN の場合、bmxconfig.yml: bmxconfig.bluemix_env_domain を参照

cf_client_secret

Cloud Foundry cf_exporter クライアントID の秘密

credentials.yml: credentials.cloudfoundry.uaa_cf_exporter_secret を参照

uaa_url Cloud Foundry UAA URLhttps://uaa.DOMAIN

DOMAIN の場合、bmxconfig.yml: bmxconfig.bluemix_env_domain を参照

firehose_client_secret

クライアント firehose_client の秘密 credentials.yml: credentials.cloudfoundry.uaa_firehose_exporter_secret.secret を参照

firehose_doppler_url

Cloud Foundry Doppler URLwss://doppler.DOMAIN:443 URL

DOMAIN の場合、bmxconfig.yml: bmxconfig.bluemix_env_domain を参照

bosh_url Bosh director URLhttps://IP_ADDRESS:25555 URL

IP_ADDRESS の場合、bmxconfig.yml: bmxconfig.director_ip を参照

bosh_pwd Bosh admin ユーザー・パスワード credentials.yml: credentials.boshdirector.bosh.password を参照

director_cert

Bosh director CA 証明書 certificates.yml: certificates.rootca.certificates.data を参照

environment Prometheus および Grafana で表⽰する環境名

IBM Cloud Private Cloud Foundry デプロイメントごとに固有でなければなりません

CloudFoundry


https://github.com/IBM/charts/blob/master/stable/ibm-cf-exporters-helm/values.template_yaml

https://api/

https://uaa/

https://ip_address:25555/

1. IBMCloudPrivate/ibm-cf-exporters-provide ディレクトリーに移動します。これは、インストール構成ディレクトリー内にあります。

2. values.yaml を検査するか、values.template_yaml から values.yaml を作成します。その際、前の表に従ってパラメーターを編集します。


helm install --name=cf-exporters . --tls

結果

このコマンドにより、IBM Cloud Private Cloud Foundry と通信する IBM Cloud Private Cloud Foundry エクスポーターが Kubernetes クラスターにデプロイされます。

トラブルシューティング以下のようにして、3 つのエクスポーターのログを確認します。

kubectl logs cf-exporter kubectl logs firehose-exporter kubectl logs bosh-exporter

ログでは、正しくない構成パラメーターが指定されていたかどうかが⽰されます。

Grafana ダッシュボード

必要な場合、ダッシュボードをデプロイメントに追加できます。追加のダッシュボードは、以下の場所で⼊⼿できます。

IBM Cloud Private Cloud Foundry ダッシュボード

Bosh ダッシュボード

IBM Cloud Private コンソールを使⽤して、/grafana にナビゲートします。

ページの右側の「ホーム (Home)」>「ダッシュボードのインポート (Import Dashboard)」をクリックします。

前述の GitHub から、インストールするダッシュボードの .json ファイルを選択します。内容をコピーして、IBM Cloud Private の「ダッシュボードのインポート (Import Dashboard)」に貼り付けます。次に、「ロード (Load)」をクリックします。プロンプトが出されたら、必要に応じて「名前 (Name)」を変更してから、prometheus フィールドで prometheus を選択します。「インポート (Import)」をクリックします。ダッシュボードが表⽰されます。これで、このダッシュボードが「ホーム (Home)」メニューからアクセスできるようになりました。

チャートのアンインストール

以下のコマンドを実⾏して、my-release デプロイメントをアンインストールまたは削除します。

helm delete cf-exporters --tls

このコマンドにより、チャートに関連付けられているすべての Kubernetes コンポーネントが削除され、リリースが削除されます。

IBM® Cloud Private Cloud Foundry ⽤アプリケーションのための信頼証明書の構成


https://github.com/bosh-prometheus/prometheus-boshrelease/tree/master/jobs/cloudfoundry_dashboards/templates

https://github.com/bosh-prometheus/prometheus-boshrelease/tree/master/jobs/bosh_dashboards/templates

アプリケーション・インスタンスのための信頼証明書を構成します。

オプションとして、PEM エンコードの信頼システム証明書セットをデプロイし、アプリケーション・インスタンスで使⽤できるようにすることが可能です。これらの証明書は、以下の場所にインストールされます。

cflinuxfs2 スタックを使⽤するビルドパック・ベースのアプリケーションの場合、/etc/ssl/certs/ トラストストア。これらの証明書は、openssl など、トラストストアに従うプログラムで⾃動的に使⽤可能になります。

.crt ファイル拡張⼦を使⽤する、Docker イメージおよび Windows イメージ・ベースのアプリケーションの場合、/etc/cf-system-certificates ファイル。証明書の場所は、インスタンス・コンテナーの環境変数 CF_SYSTEM_CERT_PATH で指定されます。

launch.sh -c <directory> コマンドの実⾏時に指定したパスにある ./CloudFoundry/certificates.yml ディレクトリー内の certificates.yml ファイルに証明書を配置する必要があります。以下のスタンザで 3 つの証明書ファイルの内容を配置します。

``` trusted_certs: certificate: data: | -----BEGIN CERTIFICATE----- (contents of certificate #1) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (contents of certificate #2) -----END CERTIFICATE----- description: "Trusted certificates to be injected into Diego containers" ```

IBM® Cloud Private Cloud Foundry でのビルドパックの使⽤

デフォルトでは、IBM Cloud Private Cloud Foundry には、クラウドにアプリケーションをデプロイするために使⽤できる、IBM でサポートされるビルドパックが含まれています。

ビルドパックについて

Cloud Foundry ビルドパックは、Cloud Foundry 環境でのアプリケーションのランタイム・サポートを提供します。アプリケーションをクラウドにデプロイすると、そのアプリケーション・タイプをサポートするビルドパックが開始

されます。 IBM Cloud Private Cloud Foundry は、Java™ EE、Node.js、ASP.Net、Swift、および他のアプリケーション・タイプのビルドパック・サポートを提供します。

IBM Cloud Private Cloud Foundry に含まれているビルドパックを使⽤して、アプリケーションをデプロイし、ユーザー提供のサービスにバインドすることができます。以下の Cloud Foundry ビルドパックは、IBM Cloud と IBM CloudPrivate の両⽅で使⽤可能です。 Cloud Foundry の構成によっては、IBM Cloud Private のビルドパックは、IBMCloud の場合と異なる動作になります。

使⽤可能なビルドパック

以下の⼿順により、Liberty for Java、SDK for Node.js、Runtime for Swift、または ASP.NET Core の各ビルドパックを使⽤して、アプリケーションをクラウドにデプロイできます。あるいは、以下のビルドパックのスターター・アプリケーションを使⽤して、ユーザー提供のサービスの処理を開始することもできます。

Liberty for JavaSDK for Node.js


ビルドパックのインストールおよび更新

ビルドパックは、IBM Cloud Private Cloud Foundry に含まれています。ビルドパックのインストールおよび更新について詳しくは、『IBM Cloud Private Cloud Foundry でのビルドパックの管理』を参照してください。

ビルドパックを使⽤したアプリケーションのデプロイの⼀般的な⼿順

ビルドパックを使⽤した IBM Cloud Private Cloud Foundry インスタンスへのアプリケーションのデプロイ

1. IBM Cloud Private Cloud Foundry の API エンドポイントまたはターゲット URL を使⽤して、Cloud FoundryCLI にご使⽤の環境を指定します。

cf api <IBM Cloud Private Cloud Foundry の API エンドポイント>

注: API エンドポイントまたはターゲット URL の識別について詳しくは、『bluemix_env_domain を使⽤した API エンドポイントおよびログイン・エンドポイントの確認』を参照してください。

1. cf コマンド・ラインを使⽤して Cloud Foundry にログインします。

cf login

2. アプリケーション・ディレクトリー内から、アプリケーションをプッシュします。

cf push

3. アプリケーションのデプロイには、数分かかることがあります。デプロイメントが完了すると、アプリケーションが実⾏中であることを⽰すメッセージが表⽰されます。 push コマンドの出⼒でリストされている URL でアプリケーションを表⽰するか、以下のコマンドを実⾏して、アプリケーションのデプロイメント状況と URLの両⽅を表⽰します。

cf app <アプリケーション名>

ヒント: cf logs <Your-App-Name> --recent コマンドを使⽤して、デプロイメント・プロセスにおけるエラーをトラブルシューティングできます。

IBM Cloud Private Cloud Foundry でのビルドパックの環境変数

IBM Cloud と⽐較して IBM Cloud Private Cloud Foundry を異なる構成にすることができるため、⼀部の環境変数では、動作が異なり、⼿動構成が必要になることがあります。

bluemix_env_domain を使⽤した API エンドポイントおよびログイン・エンドポイントの確認

Cloud Foundry をインストールする際、管理者が bluemix_env_domain 変数を定義します。この変数は、API エンドポイントまたはターゲット URL の定義に使⽤され、IBM Cloud Private Cloud Foundry のインスタンスのログイン・エンドポイントを定義するように変更できます。

例えば、bluemix_env_domain が local.bluemix.net と定義されている場合、ターゲット URL または API エンドポイントは、https://api.local.bluemix.net のようになります。環境ドメインのログイン・エンドポイントは、https://login.local.bluemix.net/UAALoginServerWAR のようになります。ログイン・エンドポイントURL では常に、bluemix_env_domain の前に login. が含まれ、末尾が /UAALoginServerWAR になります。 API エンドポイントまたはターゲット URL では、bluemix_env_domain の前に api. が含まれます。

Cloud Foundry をインストールして IBM Cloud Private を構成する⽅法について詳しくは、『IBM Cloud Private CloudFoundry のインストールのプラットフォームの概要』を参照してください。


PORT

IBM Cloud Private Cloud Foundry にデプロイする前におけるローカルでの Node.js アプリケーションの実⾏

アプリケーションをデプロイする前、またはデバッグする場合に、アプリケーションをローカルで実⾏できます。ビルドパックを使⽤すると、Cloud Foundry 環境がポートを割り当て、PORT 環境変数でその情報をアプリケーションに渡します。 Cloud Foundry でアプリケーションを実⾏するには、PORT 環境変数にバインドするようにアプリケーションをコーディングする必要があります。ただし、アプリケーションをローカルで実⾏した場合、この環境変数が設定されていないことがあります。 PORT 環境変数が⾒つからない場合にデフォルト・ポートにバインドするようにアプリケーションをコーディングする必要があります。

Node.js スターター・アプリケーションで作業する際に、PORT 環境変数を 3000 に設定します。ローカルでのNode.js アプリケーションの実⾏について詳しくは、チュートリアル『ユーザー提供のサービスおよび Node.js スターター・アプリケーションの処理』および Node.js アプリケーションのローカルでの実⾏⽅法に関する IBM Cloud資料を参照してください。

関連リンク

ユーザー提供のサービス、ビルドパックの管理、および IBM Cloud Private Cloud Foundry のスターター・アプリケーションについて詳しくは、以下のトピックを参照してください。

IBM Cloud Private Cloud Foundry でのビルドパックの管理IBM Cloud Private Cloud Foundry でのユーザー提供のサービスの処理IBM Cloud Private Cloud Foundry での Liberty および Node.js アプリケーションの管理

IBM Cloud でのビルドパックについて詳しくは、以下を参照してください。

Liberty for Java SDK for Node.js IBM Cloud Runtime for Swift ASP.NET Core

IBM® Cloud Private Cloud Foundry でのビルドパックの管理

IBM Cloud Private の構成によっては、IBM Cloud Private Cloud Foundry に含まれているビルドパックで、更新の管理、⾮推奨のビルドパックの削除、およびその他の保守が必要になることがあります。

ビルドパックの保守およびライフサイクル

所有者は、ビルドパックの順序と配置を選択できます。各ビルドパック・バージョンにはメモリーが必要であり、ビルドパックを更新したときに、環境から使⽤していないビルドパックや⾮推奨のビルドパックを削除する必要があり

ます。

IBM Cloud Private Cloud Foundry でのビルドパックの作成、更新、削除など、ビルドパックのライフサイクルについて詳しくは、Cloud Foundry ビルドパックのリソースを参照してください。

ヒント: すべてのビルドパックで⼀貫性のある命名システムを使⽤した場合、インストールしたバージョンの追跡に役⽴ちます。ビルドパックのサポートが必要な場合、ビルドパックの⾔語およびバージョンが含まれた命名システムを使⽤することで、問題の診断および修正に役⽴てることができます。ビルドパック名⾃体、またはビルドパックのファイル名に⾔語およびバージョンを含めるように選択できます。


https://console.bluemix.net/docs/runtimes/nodejs/runningLocally.html#hints

https://console.bluemix.net/docs/runtimes/liberty/index.html

https://console.bluemix.net/docs/runtimes/nodejs/index.html

https://console.bluemix.net/docs/runtimes/swift/index.html

https://console.bluemix.net/docs/runtimes/dotnet/index.html

https://docs.cloudfoundry.org/buildpacks/

ビルドパックおよびビルドパック更新のインストール

IBM Cloud Private Cloud Foundry の各リリースには、IBM ビルドパックが含まれています。 IBM Cloud Private CloudFoundry を定期的に更新している場合、Cloud Foundry コンポーネントの更新にはビルドパックの更新も含まれます。 IBM Cloud Private Cloud Foundry をインストールした後に、または Cloud Foundry を更新するごとに、ビルドパックを作成する必要があります。

launch.sh および launch_deployment.sh スクリプトが含まれているディレクトリーから以下のコマンドを実⾏して、ビルドパックを作成します。


Cloud Foundry のインストールについて詳しくは、『IBM Cloud Private Cloud Foundry のインストール』を参照してください。

ビルドパックの削除

ビルドパックは⾃動的に削除されないため、⾃分でビルドパックを削除するタイミングを決定します。 CloudFoundry のメモリー・スペースが不⾜しないように、ビルドパックを定期的に削除する必要があります。

以下のステップでビルドパックを削除します。

1. Cloud Foundry CLI で、ビルドパックをリストします。

cf buildpacks

2. 削除するビルドパックを選択し、以下のコマンドを使⽤してビルドパックを削除します。

cf delete-buildpack <buildpack_name>

オフライン・モードのビルドパック

Liberty for Java™ と Node.js のいずれのビルドパックも、動作しているクラウド環境の外部にあるサイトにアクセスし、外部のソースから成果物をダウンロードする可能性があります。サイトのホワイトリスティングについて詳しくは、IBM Cloud Dedicated、Bluemix Local、および IBM Cloud Private の各環境の『Liberty のオフライン・モードの使⽤』を参照してください。また、Node.js アプリケーションのローカルでの実⾏について詳しくは、『Node.jsのオフライン・モードの処理』を参照してください。

IBM® Cloud Private Cloud Foundry でのユーザー提供のサービスの処理

IBM Cloud Private Cloud Foundry は、ユーザー提供のサービス (クラウド環境で提供されていないか、使⽤可能でないことがあるサービス) に接続して使⽤するためのメカニズムを備えています。

概要

アプリケーションでユーザー提供のサービスを使⽤するには、以下が必要です。

ご使⽤の環境の外部にある使⽤可能なサービス

そのサービスへのアクセスまたはサービスの使⽤のための資格情報

そのサービスにバインドできるアプリケーション

Cloud Foundry でユーザー提供のサービスを使⽤することで、Liberty for Java™、SDK for Node.js、Runtime forSwift、または ASP.NET Core の各ビルドパックを使⽤して、IBM Cloud Private 環境のマーケットプレイスの外部のサ


https://console.bluemix.net/docs/runtimes/liberty/offlineMode.html#offline_mode

https://console.bluemix.net/docs/runtimes/nodejs/offlineMode.html#offline_mode

https://docs.cloudfoundry.org/devguide/services/user-provided.html

ービスにアプリケーションをバインドできます。

ガイドの使⽤⽅法

以下の⼿順では、Cloud Foundry ビルドパックを使⽤して、外部サービスの作成、アプリケーションのデプロイ、外部サービスへのアプリケーションのバインドを⾏う⼀般的なプロセスを⽰します。サービス資格情報がある場合、独⾃のアプリケーション、およびパブリック・クラウドまたは IBM Cloud Private でホストされている任意のサービスに合わせてこの⼿順を変更して、ユーザー提供のサービスを作成できます。 Cloud Foundry は、サービスの作成およびその資格情報の提供に関する多数のオプションを備えています。ご使⽤のクラウド環境に合わせてユーザー提供のサービスをカスタマイズする⽅法について詳しくは、ユーザー提供のサービス・インスタンスに関する CloudFoundry の資料を参照してください。

Liberty または Node.js のスターター・アプリケーションを使⽤することもできます。スターター・アプリケーションは、クラウド環境でユーザー提供のサービスをセットアップする具体例を⽰します。⼿順では、スターター・アプリケーションおよび IBM Cloud の Cloudant® NoSQL DB サービスを使⽤して、ユーザー提供のサービスを作成する⽅法を⽰します。

始める前に

問題の回避: 外部インターネット・アクセスがない状態で作業している場合は、ビルドパックの処理を開始する前に、⼿順全体を最後まで読んでください。すべての必要な資料およびリソースにアクセスできるようにしてください。

ステップ 1: 外部サービスの作成

必要な資格情報がある場合、ご使⽤の環境外にある任意のサービスにバインドできます。例えば、IBM Cloud でサービス・インスタンスを作成し、IBM Cloud Private Cloud Foundry でその IBM Cloud サービスにバインドしたアプリケーションをデプロイできます。

ステップ 2: サービス資格情報の保存

サービス・インスタンスの作成後に、アプリケーションをバインドするために必要な資格情報を保存します。 JSONファイルに該当する資格情報を保存できます。各種サービスにはそれぞれ固有の資格情報の要件およびフォーマットが存在している可能性がありますが、以下のテンプレート例では、Cloudant NoSQL DB で必要な資格情報を⽰します。

{ "username": "<username>", "password": "<password>", "host": "<host.dns.name>", "port": <port>, "url": "https://<username>:<password>@<host.dns.name>" }

ステップ 3: ユーザー提供のサービスの作成

Cloud Foundry cf cups コマンドを使⽤して、ユーザー提供のサービスを作成できます。

cf create-user-provided service <service name> -p <path to JSON file>

注: Cloud Foundry は、cf create-user-provided-service コマンドを使⽤してコマンド・ラインからアクセスできる、ユーザー提供のサービスを作成する他の⽅法に関する情報を提供しています。

ステップ 4: ユーザー提供のサービスへのアプリケーションのバインド



コマンド・ラインを使⽤して、ユーザー提供のサービスをアプリケーションにバインドします。

cf bind-service <app-name> <service-name>

次に、アプリケーションを再ステージします。

cf restage <app-name>

再ステージ後、アプリケーションの URL を参照することで、アプリケーションが期待どおりに機能しているかを確認できます。あるいは、cf service コマンドを使⽤して、サービスおよびバインドされたアプリケーションを表⽰することもできます。

IBM Cloud Private Cloud Foundry でのユーザー提供のサービスの例と情報

ビルドパック・スターター・アプリケーションでは、ユーザー提供のサービスの作成、IBM Cloud での Cloudant データベースの作成、およびサービスへのアプリケーションのバインドが⽰されます。

以下に従って、ユーザー提供のサービスの作成およびアプリケーションのバインドをお試しください。

ユーザー提供のサービスおよび Liberty スターター・アプリケーションの処理ユーザー提供のサービスおよび Node.js スターター・アプリケーションの処理

ユーザー提供のサービスおよび Liberty スターター・アプリケーションの処理

IBM® Cloud Private Cloud Foundry のアプリケーションを、IBM Cloud Private Cloud Foundry 環境の外部に存在しているサービスにバインドできます。 Cloud Foundry は、クラウド・インスタンスで提供されていない、あるいは使⽤可能でないサービスとアプリケーションを接続するメカニズムを提供します。 Cloud Foundry の機能について詳しくは、『User-Provided Service Instances』を参照してください。

この例では、Cloudant® NoSQL DB インスタンスを使⽤し、Liberty for Java™ 開始アプリケーションを使⽤した、アプリケーションの準備とデプロイ、ユーザー提供のサービスの作成、および Cloudant データベースへの接続のプロセスを⽰します。

始める前に

以下のアカウントおよびツールが必要です。

IBM Cloud Private Cloud Foundry 環境へのアクセスIBM Cloud アカウント Cloud Foundry CLI Git Maven

ステップ 1: サンプル・アプリケーションの複製

まず、サンプル・アプリケーション GitHub repo を複製します。

git clone https://github.com/IBM-Bluemix/get-started-java

ステップ 2: コマンド・ラインを使⽤したアプリケーションのローカルでの実⾏

Maven を使⽤して、ソース・コードをビルドし、アプリケーションを実⾏します。



https://console.ng.bluemix.net/registration/

https://github.com/cloudfoundry/cli#downloads

https://git-scm.com/downloads

https://maven.apache.org/download.cgi

1. コマンド・ラインで、サンプル・アプリケーションがある場所にディレクトリーを変更します。

cd get-started-java

2. Maven を使⽤して、依存関係をインストールし、.war ファイルをビルドします。

mvn clean install

3. Liberty でローカルにアプリケーションを実⾏します。

mvn install liberty:run-server

「The server defaultServer is ready to run a smarter planet」というメッセージが表⽰されます。http://localhost:9080/GetStartedJava でアプリケーションを表⽰できます。

アプリケーションを停⽌するには、アプリケーションを開始したコマンド・ライン・ウィンドウで Ctrl-C を押します。

ステップ 3: アプリケーションのデプロイメントの準備

IBM Cloud Private にデプロイする場合、manifest.yml ファイルをセットアップすると役⽴ちます。 manifest.yml には、名前、各インスタンスで割り振るメモリー容量、経路など、アプリケーションに関する基本情報が含まれます。 get-started-java ディレクトリー内にサンプル manifest.yml ファイルがあります。

manifest.yml ファイルを開き、name を GetStartedJava からご使⽤のアプリケーション名 app_name に変更します。

applications: - name: GetStartedJava random-route: true path: target/GetStartedJava.war memory: 512M instances: 1

ヒント: この manifest.yml ファイルで random-route: true を指定することで、アプリケーションに対してランダムな経路が⽣成され、経路が他のものと競合しなくなります。必要に応じて、random-route: true を host:myChosenHostName に置き換え、任意のホスト名を指定できます。詳細...

ステップ 4: IBM Cloud Private Cloud Foundry へのデプロイ

1. IBM Cloud Private Cloud Foundry URL を使⽤して、アプリケーションを IBM Cloud Private Cloud Foundry にデプロイします。

cf api <API endpoint of IBM Cloud Private Cloud Foundry>

2. IBM Cloud Private Cloud Foundry アカウントにログインします。

cf login

3. get-started-java ディレクトリー内から、アプリケーションを IBM Cloud Private にプッシュします。

cf push


cf apps


http://localhost:9080/GetStartedJava

https://console.bluemix.net/docs/manageapps/depapps.html#appmanifest


ステップ 5: Cloudant NoSQL DB サービス・インスタンスの作成

次に、IBM Cloud の Cloudant NoSQL DB データベースをこのアプリケーションに追加して、ローカルおよび IBMCloud Private で実⾏されるようにアプリケーションをセットアップします。 IBM Cloud で Cloudant データベースを作成する必要があります。次に、IBM Cloud Private Cloud Foundry 内から IBM Cloud サービスにスターター・アプリケーションをバインドします。

1. ブラウザーで、IBM Cloud にログインし、Catalogに移動します。2. 「データ」&「分析」セクションで、「Cloudant NoSQL DB」を選択し、サービスを作成します。3. 「サービス資格情報」に移動し、サービスの資格情報を表⽰します。

4. JSON ファイルに Cloudant NoSQL DB 資格情報を保存します。


5. 開始アプリケーションを処理するには、作成したユーザー提供のサービスのサービス名に cloudant を含める必要があります。開始アプリケーションは VCAP サービス変数を解析し、my-cloudantNoSQLDB-ups など、名前に cloudant が含まれているユーザー提供のサービスを検索します。

create-user-provided-service コマンドを使⽤して、ユーザー提供のサービスを作成します。サービス名、および作成した cloudant-credentials.json ファイルのパスを指定します。

cf create-user-provided-service <Your-Service-Name> -p <path to json file>

ステップ 6: Cloudant NoSQL DB の使⽤

1. ユーザー提供のサービスを開始アプリケーションにバインドします。

cf bs <Your-App-Name> <Your-Service-Name>

2. アプリケーションを再ステージします。

cf restage <Your-App-Name>

ヒント: 環境変数を使⽤して、デプロイメント設定をソース・コードから分離できます。例えば、データベース・パスワードをハードコーディングする代わりに、データベース・パスワードを環境変数に保管し、その環境変数をソー

ス・コードで参照できます。詳細...

ステップ 7: Cloudant NoSQL DB のローカルでの使⽤

次に、ローカル・コードを更新して、このデータベースを指定します。プロパティー・ファイルにサービスの資格情報を保管できます。このファイルは、アプリケーションがローカルで実⾏されている場合にのみ使⽤されます。アプリケーションを IBM Cloud Private Cloud Foundry で実⾏した場合、資格情報は、VCAP_SERVICES 環境変数から読み取られます。

1. src/main/resources/cloudant.properties ファイルを開きます。

cloudant_url=


https://console.bluemix.net/docs/manageapps/depapps.html#app_env

2. ステップ 5 でファイルに保存したサービス資格情報の url の値をコピーし、cloudant.properties ファイルの url フィールドに貼り付けます。変更を保存します。

cloudant_url=https://123456789 ... bluemix.cloudant.com

3. ローカルの Liberty サーバーを停⽌し、get-started-java ディレクトリー内から以下のコマンドでサーバーを再始動します。

mvn install liberty:run-server

ステップ 8: 確認

http://localhost:9080/GetStartedJava/ でブラウザー・ビューを最新表⽰します。アプリケーションに⼊⼒した名前がデータベースに追加されます。

ローカル・アプリケーションと IBM Cloud Private Cloud Foundry アプリケーションは、Cloudant NoSQL DB データベースを共有しています。いずれかのアプリケーションで追加された名前は、ブラウザーを最新表⽰すると、いずれのアプリケーションでも表⽰されます。

ユーザー提供のサービスおよび Node.js スターター・アプリケーションの処理

IBM® Cloud Private Cloud Foundry のアプリケーションを、IBM Cloud Private Cloud Foundry 環境の外部に存在しているサービスにバインドできます。 Cloud Foundry は、クラウド・インスタンスで提供されていない、あるいは使⽤可能でないサービスとアプリケーションを接続するメカニズムを提供します。 Cloud Foundry の機能について詳しくは、『User-Provided Service Instances』を参照してください。

この例では、Cloudant® NoSQL DB インスタンスを使⽤し、Node.js 開始アプリケーションを使⽤した、アプリケーションの準備とデプロイ、ユーザー提供のサービスの作成、および Cloudant データベースへの接続のプロセスを⽰します。

始める前に

以下のアカウントおよびツールが必要です。

IBM Cloud Private Cloud Foundry 環境へのアクセスIBM Cloud アカウント Cloud Foundry CLI Git Node.js

アプリケーションの準備およびデプロイ

ステップ 1: サンプル・アプリケーションの複製

まず、サンプル・アプリケーション GitHub repo を複製します。

git clone https://github.com/IBM-Bluemix/get-started-node

ステップ 2: コマンド・ラインを使⽤したアプリケーションのローカルでの実⾏

1. コマンド・ラインで、サンプル・アプリケーションがある場所にディレクトリーを変更します。


http://localhost:9080/GetStartedJava/


https://console.ng.bluemix.net/registration/

https://github.com/cloudfoundry/cli#downloads

https://git-scm.com/downloads

https://nodejs.org/en/

cd get-started-node

2. アプリケーションをローカルで実⾏するために、package.json ファイルにリストされている依存関係をインストールします。

npm install

3. アプリケーションを実⾏します。

npm start

http://localhost:3000 でアプリケーションを表⽰できます。

ヒント: ファイルが変更されたときにアプリケーションを⾃動的に再始動するには、nodemon を使⽤してください。

ステップ 3: アプリケーションのデプロイメントの準備

アプリケーションを IBM Cloud Private にデプロイする場合、manifest.yml ファイルをセットアップすると役⽴ちます。 manifest.yml には、名前、各インスタンスで割り振るメモリー容量、経路など、アプリケーションに関する基本情報が含まれます。 get-started-node ディレクトリー内にサンプル manifest.yml ファイルがあります。

manifest.yml ファイルを開き、name を GetStartedNode からご使⽤のアプリケーション名 <var class="keyword varname" data-hd-keyref="app_name">app_name</var> に変更します。

applications: - name: GetStartedNode random-route: true memory: 128M

ヒント: この manifest.yml ファイルで random-route: true を指定することで、アプリケーションに対してランダムな経路が⽣成され、経路が他のものと競合しなくなります。必要に応じて、random-route: true を host:myChosenHostName に置き換え、任意のホスト名を指定できます。詳細...

ステップ 4: IBM Cloud Private Cloud Foundry へのデプロイ

1. IBM Cloud Private Cloud Foundry URL を使⽤して、アプリケーションを IBM Cloud Private Cloud Foundry にデプロイします。

cf api <url of IBM Cloud Private Cloud Foundry>

2. IBM Cloud Private Cloud Foundry アカウントにログインします。

cf login

3. get-started-node ディレクトリー内から、アプリケーションを IBM Cloud Private にプッシュします。

cf push


cf apps


ステップ 5: データベースの追加


https://docs.npmjs.com/files/package.json

http://localhost:3000/

https://nodemon.io/

https://console.bluemix.net/docs/manageapps/depapps.html#appmanifest

次に、IBM Cloud の Cloudant NoSQL DB データベースをアプリケーションに追加して、ローカルおよび IBM CloudPrivate で実⾏されるようにアプリケーションをセットアップします。 IBM Cloud で Cloudant データベースを作成する必要があります。次に、IBM Cloud Private Cloud Foundry 内から IBM Cloud サービスにスターター・アプリケーションをバインドします。

1. ブラウザーで、IBM Cloud にログインし、カタログに移動します。2. 「データ」&「分析」セクションで、「Cloudant NoSQL DB」を選択し、サービスを作成します。3. 「サービス資格情報」に移動し、サービスの資格情報を表⽰します。4. Cloudant インスタンスの作成後に、資格情報を保存してアプリケーションをバインドする必要があります。 cloudant_credentials.json などのファイル名の JSON ファイルに Cloudant NoSQL DB 資格情報を保存します。


オプション: アプリケーションのローカルでの実⾏

アプリケーションをローカルで実⾏するには、ローカル・コードを更新して、このデータベースを指定する必要があ

ります。アプリケーションで使⽤するサービスの資格情報を保管する JSON ファイルを作成します。このファイルは、アプリケーションがローカルで実⾏されている場合にのみ使⽤されます。クラウドで実⾏されている場合、資格情報は、VCAP_SERVICES 環境変数から読み取られます。

問題の回避: この vcap-local.json JSON ファイルは、cloudant-credentials.json ファイルと同じではありません。 vcap-local.json ファイルは、アプリケーションをローカルで実⾏する場合にのみ使⽤されます。

1. get-started-node ディレクトリーで、以下の内容が含まれた vcap-local.json という名前のファイルを作成します。

{ "services": { "cloudantNoSQLDB": [ { "credentials": { "url":"CLOUDANT_DATABASE_URL" }, "label": "cloudantNoSQLDB" } ] } }

ヒント: 環境変数を使⽤して、デプロイメント設定をソース・コードから分離できます。例えば、データベース・パスワードをハードコーディングする代わりに、データベース・パスワードを環境変数に保管し、その環

境変数をソース・コードで参照できます。詳細...

2. ステップ 5 で保存した cloudant-credentials.json ファイル、またはステップ 5 のサービス資格情報から、資格情報の url のみをコピーし、vcap-local.json ファイルの url フィールドに貼り付け、CLOUDANT_DATABASE_URL を置き換えます。

3. ローカル・アプリケーションを停⽌してから、再始動します。

npm start

http://localhost:3000 でローカル・アプリケーションを表⽰します。アプリケーションに⼊⼒した名前がデータベースに追加されます。


https://console.bluemix.net/docs/manageapps/depapps.html#app_env

http://localhost:3000/

問題の回避: アプリケーションがクラウドで実⾏される場合、IBM Cloud によって PORT 環境変数が定義されます。アプリケーションをローカルで実⾏した場合、PORT 環境変数は定義されていないため、3000 がポート番号として使⽤されます。アプリケーションのローカルでの実⾏について詳しくは、『アプリケーションのローカルでの実⾏』を参照してください。

ステップ 6: ユーザー提供のサービスの作成

開始アプリケーションを処理するには、作成したユーザー提供のサービスのサービス名に cloudant を含める必要があります。開始アプリケーションは VCAP サービス変数を解析し、my-cloudantNoSQLDB-ups など、名前にcloudant が含まれているユーザー提供のサービスを検索します。

create-user-provided-service コマンドを使⽤して、ユーザー提供のサービスを作成します。サービス名、およびステップ 5 で作成した cloudant-credentials.json ファイルのパスを指定します。

cf create-user-provided-service <service name> -p <path to json file>

ステップ 7: ユーザー提供のサービスのバインドおよびアプリケーションの再ステージ

ユーザー提供のサービスを開始アプリケーションにバインドし、再ステージします。

cf bs <Your-App-Name> <Your-Service-Name> cf restage <Your-App-Name>

ステップ 8: 確認

アプリケーションを参照し、スターター・アプリケーションの name フィールドに複数の名前を追加できることを確認します。

ローカル・アプリケーションと IBM Cloud Private Cloud Foundry アプリケーションは、Cloudant データベースを共有しています。いずれかのアプリケーションで追加された名前は、ブラウザーを最新表⽰すると、いずれのアプリケーションでも表⽰されます。

IBM® Cloud Private Cloud Foundry での Liberty および Node.js アプリケーションの管理

App Management は、IBM® Cloud での Liberty および Node.js アプリケーション⽤に使⽤可能な開発およびデバッグのユーティリティーのセットです。

App Management ユーティリティー

ビルドパックは、Liberty および Node.js ⽤に動作する以下のアプリケーション管理ユーティリティーを提供します。

Liberty と Node.js の両⽅のためのユーティリティー

proxynoproxyhc

Liberty ユーティリティー

debugjmx


localjmx

Node.js ユーティリティー

inspector

制限

App Management を使⽤してアプリケーションに⾏った変更は⼀時的なものであり、このモードを終了すると失われます。このモードは、⼀時的な開発で使⽤するためのものであり、パフォーマンス上の理由から、実稼働環境として使⽤するものではありません。

manifest.yml ファイル (コマンド) または CF CLI (-c) で start コマンドを設定した場合、ほとんどの AppManagement ユーティリティーは機能しません。これらのメソッドはビルドパックのオーバーライドであり、Node.js アプリケーションを開始するためのベスト・プラクティスではありません。最良の結果が得られるように、package.json ファイルまたは Procfile で start コマンドを設定してください。

App Management の構成⽅法

App Management ユーティリティーを有効にするには、BLUEMIX_APP_MGMT_ENABLE 環境変数を設定し、アプリケーションを再ステージします。 + で区切ることで、複数のユーティリティーを有効にすることができます。

例えば、hc および debug ユーティリティーを有効にするには、以下のコマンドを実⾏します。

cf set-env myApp BLUEMIX_APP_MGMT_ENABLE hc+debug

環境変数を設定した後には、以下のようにアプリケーションを再ステージします。

cf restage myApp

App Management ユーティリティーがアプリケーションとともにインストールされないようにする場合は、BLUEMIX_APP_MGMT_INSTALL 環境変数を「false」に設定し、アプリケーションを再ステージします。

例えば、以下のコマンドを実⾏して、App Management ユーティリティーなしでアプリケーションをステージします。

cf set-env myApp BLUEMIX_APP_MGMT_INSTALL false cf restage myApp

Liberty および Node.js ユーティリティー

proxy

proxy ユーティリティーは、アプリケーションとクラウド環境間の最⼩限のアプリケーション管理を提供します。

有効になっている場合、ビルドパックは、アプリケーションのランタイムとコンテナー間にあるプロキシー・エージ

ェントを開始します。 proxy ユーティリティーは、アプリケーションが受け取るすべての要求を処理します。要求のタイプに基づいて、App Management アクションを実⾏するか、要求をアプリケーションに転送します。 proxy を使⽤して、他のほとんどの App Management ユーティリティーを有効にすることができます。 proxy を有効にすると、アプリケーションが異常終了した場合でも、アプリケーション・コンテナーが稼働し続けます。プロキシー・エージェントを使⽤することで、増分ファイル更新の構成を使⽤できます。これにより、Node.js アプリケーションのライブ編集モードが有効になります。

noproxy


Node.js ⽤の inspector ユーティリティーなどの⼀部のユーティリティーは、proxy ユーティリティーを⾃動的に開始します。 proxy が⾃動的に開始される場合、noproxy ユーティリティーを使⽤して proxy を無効にすることができます。 Diego セルでは、プロキシーは不要です。Diego は、アプリケーションに ssh で直接接続し、ポート転送をセットアップする機能を備えているためです。

noproxy ユーティリティーは、Diego セルで実⾏されるアプリケーションにのみ適⽤されます。

hc

ヘルス・センター (hc) エージェントにより、ヘルス・センター・クライアントでアプリケーションをモニターできます。 hc エージェントは、 IBM SDK for Node.js のランタイム・バージョンでのみ使⽤可能です。現在の⼀連のランタイムについては、『SDK for Node.js ビルドパックに対する最新の更新』を参照してください。

ヘルス・センターでは、IBM Monitoring and Diagnostic Tools を使⽤した Liberty および Node.js アプリケーションのパフォーマンスの分析がサポートされます。詳しくは、『How to analyze the performance of Liberty Java™ orNode.js apps in IBM Cloud 』を参照してください。

重要: hc ユーティリティーは、proxy を開始します。

hc ユーティリティーは、noproxy とともに使⽤できます。 noproxy とともにヘルス・センターを使⽤するには、まず、cf ssh コマンドを使⽤してポート転送を設定します。例えば次のようにします。

cf ssh -N -T -L 1883:127.0.0.1:1883 <appName>

次に、ヘルス・センター・クライアントに接続するために、MQTT 接続を使⽤し、ホストとして 127.0.0.1 およびポートとして 1883 を指定します。

Eclipse Tools の開発モード

開発モードは、クラウドで実⾏中のアプリケーションを操作する機能を開発者に提供する、Eclipse Tools for IBMCloud の機能です。 Eclipse Tools の開発モードは、セキュアな⼀時ワークスペースで IBM Cloud Private のアプリケーションに対して作業する⼿段を提供します。

開発モードは、Liberty と Node.js のいずれのアプリケーションでもサポートされます。 Liberty または Node.js アプリケーションの開発モードを有効にした場合、アプリケーションをプッシュすることなく、アプリケーション・ファ

イルを増分的に更新できます。また、アプリケーションとのデバッグ・セッションを確⽴することもできます。Liberty アプリケーションの開発モードは、debug および jmx App Management ユーティリティーを有効にした場合と同等です。 Node.js アプリケーションの場合、inspector ユーティリティーを有効にした場合と同等です。

Liberty ユーティリティー

debug

debug ユーティリティーを使⽤するには、Eclipse Tools for IBM Cloud をインストールする必要があります。

debug ユーティリティーは、Liberty アプリケーションをデバッグ・モードにし、IBM Eclipse Tools for IBM Cloud などのクライアントがアプリケーションとのリモート・デバッグ・セッションを確⽴できるようにします。

重要: debug ユーティリティーは、proxy を開始します。

debug ユーティリティーは、noproxy とともに使⽤できます。 noproxy とともにデバッガーを使⽤するには、まず、cf ssh コマンドを使⽤してポート転送を設定します。以下のコード・スニペットでは、cf ssh コマンド・フォーマットの例を⽰します。



https://console.bluemix.net/docs/runtimes/nodejs/updates.html#latest_updates

https://developer.ibm.com/bluemix/2015/07/03/how-to-analyze-performance-in-bluemix/

http://www.ibm.com/support/knowledgecenter/SS3KLZ/com.ibm.java.diagnostics.healthcenter.doc/topics/connectingtojvm.html

https://console.bluemix.net/docs/manageapps/eclipsetools/eclipsetools.html

https://console.bluemix.net/docs/manageapps/eclipsetools/eclipsetools.html

https://console.bluemix.net/docs/manageapps/eclipsetools/eclipsetools.html#remotedebug

次に、Eclipse で接続するために、リモート Java 構成を使⽤し、ホストとして 127.0.0.1 およびポートとして 7777 を指定します。

jmx

jmx ユーティリティーにより、JMX REST Connector は、リモート JMX クライアントで IBM Cloud ユーザー資格情報を使⽤してアプリケーションを管理できるようにすることが可能になります。

JMX コネクターの構成⽅法について詳しくは、『Liberty プロファイルへのセキュア JMX 接続の構成』を参照してください。

重要: jmx ユーティリティーは proxy を開始しません。

localjmx

localjmx ユーティリティーにより、localConnector-1.0 Liberty フィーチャーが有効になります。このユーティリティーをローカル・ポート転送と組み合わせることで、リモート JMX クライアントでアプリケーションを管理できるようにする代替⼿段が使⽤可能になります。

始める前に: localjmx を使⽤するには、JConsole をインストールする必要があります。

localjmx ユーティリティーは、Diego セルで実⾏されるアプリケーションにのみ適⽤できます。 localjmx を使⽤するには、まず、cf ssh コマンドを使⽤してポート転送を設定します。例えば次のようにします。


次に、JConsole に接続するために、リモート・プロセスを選択して 127.0.0.1:5000 を指定し、⾮セキュア接続を使⽤します。

Node.js ユーティリティー

inspector

inspector ユーティリティーを使⽤して、IBM Cloud Private でのアプリケーションの実⾏中に、CPU 使⽤率プロファイルの作成、ブレークポイントの追加、コードのデバッグを⾏うことができます。バージョン 6.3.0 より前のNode.js の場合、inspector により、Node inspector デバッガー・インターフェースが有効になります。 Nodeinspector について詳しくは、GitHub 上の node-inspector の README ファイルを参照してください。バージョン6.3.0 以上の Node.js の場合、inspector ユーティリティーは V8 Inspector Integration for Node.js を使⽤します。

バージョン 6.3.0 以降 Node.js の場合

デバッグ・モードを開始すると、proxy が含まれていない Node.js のバージョンを使⽤している場合でも、proxy が⾃動的に有効になります。バージョン 6.3.0 以降 Node.js には、proxy は含まれていません。バージョン 6.3.0 以降Node.js で inspector ユーティリティーを使⽤している場合は、noproxy を使⽤して、proxy を再びオフにすることができます。

proxy を使⽤して inspector インターフェースにアクセスする代わりに、Google Chrome Web ブラウザーのDeveloper Tools 機能を使⽤します。

以下のコマンドを使⽤して、ローカル・ポート転送を使⽤した URL へのアクセスを有効にします。


以下のコマンドを使⽤して、アプリケーションの開始ログを取得します。

cf logs <appName> --recent


https://www.ibm.com/support/knowledgecenter/SSAW57_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/twlp_admin_restconnector.html

http://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/rwlp_feature_localConnector-1.0.html

https://github.com/node-inspector/node-inspector

https://nodejs.org/dist/latest-v6.x/docs/api/debugger.html#debugger_v8_inspector_integration_for_node_js

inspector ユーティリティーがアクティブの場合、ログには、以下のようなメッセージが表⽰されます。

2017-10-16T14:37:44.75-0400 [APP/PROC/WEB/0] ERR

最新バージョンの Chrome Web ブラウザーを使⽤し、chrome://inspect を参照します。この URL から、file://home/vcap/app/app.js など、アプリケーション・ファイルへのリンクとともにアプリケーションがリストされます。 inspect を選択して、inspect インターフェースにアクセスします。

バージョン 6.3.0 より前の Node.js の場合

proxy を使⽤している場合、https://myApp.mybluemix.net/bluemix-debug/inspector で inspector インターフェースにアクセスできます。

proxy ユーティリティーを使⽤していない場合、以下のコマンドを使⽤して、ローカル・ポート転送を使⽤したアプリケーション URL へのアクセスを有効にします。


次に、URL http://127.0.0.1:8790 から inspector にアクセスします。

構成マネージャー (CM) クイック・リファレンス・ガイド

概要

構成マネージャーは、Cloud Foundry デプロイメントを管理するツールです。これはサーバーとクライアントで構成されます。サーバーは、inception コンテナー上で実⾏されます。クライアントは、インストール・ディレクトリーにインストールされ、サーバーと対話します。以下の情報は、クイック・リファレンス・ガイドとして提供しています。

コマンド・ラインの⼀般的な形式

./cm [-f <format>] [-u <s_url>] [-t <timeout_sec>] [--cacert <certificate_path>] [--insecure] [--token <token>] <cmd> [<options>...] [<sub-command>] [<options>...]

詳細については、以下のコマンドを⼊⼒してください。

./cm -h

./cm ... <cmd> -h

./cm ... <cmd>... <sub-commad> -h

オプション -f、-u、-t、および --cacert のデフォルト値は、インストール時に設定されます。詳細を取得するには、./cm api を実⾏してください。

API

使⽤法: サーバー上で実⾏されている API へのアクセスをクライアントから管理表⽰: ./cm api設定: ./cm [-f yaml|text|json] [-u <api_url>] [-t <timeout_sec>] [--insecure] [--token <token>] [--cacert <certificate_path>] [-k] [-token <token>] api save削除: ./cm api remove

CFP

使⽤法: コンポーネント・バージョンの管理表⽰: ./cm cfp


構成

使⽤法: デプロイメント構成の管理表⽰: ./cm bmxconfig設定: ./cm bmxconfig save -c <configuraiton_file_path>管理ドメインの証明書を構成ファイル内に追加: ./cm bmxconfig add-certificates -c <configuraiton_file_path> --mgt --key <key_file_path> --cert <cert_file_path> --rootca <rootcA_file_path>アプリケーションのドメインの証明書を構成ファイル内に追加: ./cm bmxconfig add-certificates -c <configuraiton_file_path> --apps --key <key_file_path> --cert <cert_file_path> --rootca <rootcA_file_path>検証: ./cm bmxconfig validate

engine

使⽤法: デプロイメント・エンジンの管理エンジンの状況の表⽰: ./cm engineリセット: ./cm engine reset

extension

使⽤法: IBM またはお客様の拡張機能の管理表⽰: ./cm extension -e <extension_name>登録: ./cm extension -e <extenstion_name> -p <extension_zip_path> [--force]構成のポスト: ./cm extension -e <extension_name> save -c <config_file>デプロイ: ./cm extension -e <extension_name> deploy [--from-state <state_name>] [to-state <state_name>] --wait登録抹消: ./cm extension -e <extenstion_name> unregisterリセット: ./cm extension -e <extenstion_name> resetログ: ./cm extension -e <extenstion_name> [--state <state_name>] [--follow]

extensions

使⽤法: 使⽤可能な拡張機能の表⽰表⽰: ./cm extenstions

logs

使⽤法: デプロイメントのログまたは拡張機能のログの表⽰表⽰: ./cm logs [-e <extension_name>] [--state <state_name>] [--follow]

state

使⽤法: デプロイメント状態の管理表⽰: ./cm state [-e <extension_name>] -s <state_name>状態の新しい状況を設定: ./cm state [-e <extension_name>] -s <state_name> set --status <STATUS>状態の新しいタイムアウトを設定: ./cm state [-e <extension_name>] -s <state_name> set --timeout <timeout_min>

states

使⽤法: デプロイメントの状態の管理


表⽰: ./cm states [-e <extension_name>]特定の状況を持つ状態の検索: ./cm states [-e <extension_name>] --status <STATUS>デプロイメントに状態を挿⼊: ./cm states [-e <extension_name>] insert --state-path <state_file_path> --insert-extension-name <extension_name> [--state-name <state_name_reference> | --position <position_to_insert>] [--before]デプロイメントから状態を削除: ./cm states [-e <extension_name>] delete [--state-name <state_name> | --position <position_to_delete]状況を範囲で設定: ./cm states [-e <extension_name>] set-status-by-range --status <new_status> --from-state <from_state_name> [--from-included] --to-state <to_state_name> [--to-included]

status

使⽤法: サーバー状況の表⽰表⽰: ./cm status

token

使⽤法: API 通信⽤にサーバー上に新規トークンを作成作成: ./cm token create -c <token_path>

IBM® Cloud Private Cloud Foundry のトラブルシューティング

IBM Cloud Private Cloud Foundry での問題を切り分けて解決する⽅法について説明します。

無効⽂字のため、launch_deployment.sh が失敗する vCenter または ESX の FDQN を解決できないため、デプロイメントが失敗する Cloud Foundry cf push コマンドおよび log コマンドでエラーが返される The Cloud Foundry 管理ユーザーがロックアウトされる BOSH デプロイメント中に consul ジョブが失敗する inception コンテナーが開始しない Cloud Foundry デプロイメントがタイムアウトになる Cloud Foundry の検証が失敗する特定の仮想マシン・ジョブで Cloud Foundry デプロイメントが失敗する IP アドレスの競合のため、Cloud Foundry デプロイメントが失敗するポート・グループに管理者許可がない Microbosh Director で bosh/0 の初期化に失敗する EHOSTUNREACH エラーのため、Cloud Foundry アプリケーション・デプロイメントが失敗する「no route to host」というエラーのため、Cloud Foundry での Docker アプリケーション・デプロイメントが失敗する OpenStack で BOSH ssh が失敗する Bosh 仮想マシンが応答しなくなる

無効⽂字のため、Cloud Foundry launch_deployment.sh が失敗する

無効⽂字のため、Cloud Foundry launch_deployment.sh が失敗します。

症状

launch_deployment.sh を実⾏すると、以下のメッセージのようなエラーが表⽰されます。


invalid character 'N' looking for beginning of value strconv.Atoi: parsing "invalid character 'N' looking for beginning of value": invalid syntax

問題の解決

1. uiconfig-template.yml ファイルを確認して、YAML 構⽂エラーまたは無効なキーが含まれていないかを調べます。ファイルは、以下の特性を満たしている必要があります。

ファイルで適切な YAML のインデントを使⽤している。各特殊⽂字が⼆重引⽤符で囲まれている。多くの場合、パスワードに特殊⽂字が含まれています。先頭ゼロまたは後続ゼロが含まれている数値が、⼆重引⽤符で囲まれている。

すべてのキーが有効である。

2. launch_deployment.sh スクリプトを再度実⾏してください。

vCenter または ESX の FDQN を解決できないため、デプロイメントが失敗する

vCenter または ESX の完全修飾ドメイン・ネームを解決できないため、IBM® Cloud Private Cloud Foundry デプロイメントが失敗します。

症状

インストールの検証フェーズで、以下のメッセージのようなエラーが表⽰されます。

=> Name : vmware_address Value : vcenter.mycompany.com Message type: error Message : Can not reach VMware, please check connectivity. dial tcp: lookup vcenter.mycompany.com on 8.8.8.8:53: no such host

原因

inception コンテナーの /etc/resolv.conf ファイルに間違った DNS サーバー値が設定されているため、このコンテナーで正しい DNS サーバー値を適⽤できません。

Docker が DNS 情報をコンテナーに提供する⽅法が、考えられる原因の 1 つです。 Docker は、ホスト・コンピューター上の /etc/resolv.conf ファイル内の値を inception コンテナーに適⽤します。このファイルに nameserverパラメーター値が含まれていない場合、それは inception コンテナーに適⽤されません。 nameserver IP アドレスがホスト・コンピューター上の /etc/hosts ファイルにもある場合、その値はコンテナーに提供されません。 Dockerにより、そのアドレスがフィルターで除外されます。適⽤するのに適切な nameserver 値がコンテナーにない場合、または Docker によってアドレスがフィルターで除外された場合、コンテナーは Google DNS アドレスを使⽤します。 Docker 資料の『Configure container DNS 』を参照してください。

別の考えられる原因として、dnsmasq パラメーター値を設定して DNS サポート・ワイルドカードをエミュレートしていることが挙げられます。この場合、ホストの /etc/resolv.conf ファイル内の値が、/etc/hosts ファイル内にある 127.0.0.1 IP アドレスで上書きされます。 Docker ファイルによって値がフィルターで除外される仕組みのため、コンテナー上の /etc/resolv.conf ファイル内の nameserver 値が、Google DNS アドレスに設定されます。

問題の解決


https://docs.docker.com/v17.09/engine/userguide/networking/default_network/configure-dns/

1. ホストから vCenter の完全修飾ドメイン・ネーム (FQDN) を解決できるかどうかを確認します。2. コンテナーから vCenter の FQDN を解決できるかどうかを確認します。3. inception コンテナー上の /etc/resolv.conf ファイルを開き、DNS IP アドレスが含まれていないことを確認します。

4. /etc/resolv.conf ファイルに DNS IP アドレスが含まれていない場合、ホスト上の /etc/hosts ファイルにそれが含まれているかどうかを確認します。 /etc/hosts ファイルに DNS IP アドレスが含まれている場合は、そのアドレスを削除します。

5. inception コンテナーで、/etc/docker/daemon.json を開き、DNS の指定を上書きしていないことを確認します。上書きしている場合は、その指定を削除して、コンテナー上の /etc/resolv.conf ファイルがホスト上の当該ファイルのバージョンを反映するようにします。

6. launch.sh コマンドを再度実⾏してください。7. launch_deployment.sh コマンドを再度実⾏してください。

Cloud Foundry cf push コマンドおよび log コマンドでエラーが返される

Cloud Foundry cf push および cf log コマンドが失敗します。

症状

Cloud Foundry cf push APPLICATION_NAME および cf log APPLICATION_NAME --recent で、Cloud FoundryLoggregator に到達しようとしたときにエラーが返されます。

cf push APPLICATION_NAME を実⾏すると、以下のエラー・メッセージが表⽰されます。

Warning: error tailing logs

cf logs APPLICATION_NAME --recent を実⾏すると、以下のエラー・メッセージが表⽰されます。

unknown issue when making HTTP request to Loggregator

問題の解決

1. BOSH にログインします。『IBM® Cloud Private Cloud Foundry ops console ⽤のコマンド・ライン・インターフェース』を参照してください。

2. 失敗している Loggregator インスタンスを判別します。インストール済み環境の nats インスタンスごとに、以下のコマンドを実⾏します。開発者版のインストール済み環境の場合、nats/0 を確認します。エンタープライズ版のインストール済み環境の場合、nats/0、nats/1、および nats/2 を確認します。

bosh2 -e IBMCloudPrivate -d Bluemix ssh <nats> -c "tail /var/vcap/sys/log/loggregator_trafficcontroller/loggregator_trafficcontroller.stderr.log"

ここで、<nats> は、確認するインスタンスです。

問題を引き起こした nats インスタンスのコマンド出⼒には、以下のエラー・メッセージのいずれかが含まれています。

2017/12/05 18:37:12 Could not get app information: [Get http://api.local.bluemixx .net/internal/log_access/f3c629e8-0bf0-4ecb-98a6-5dd42b707acb: dial tcp: lookup api.local.bluemix.net on 127.0.0.1:53: no such host]

または


2017/12/05 18:45:04 Error while reading from stream (192.168.248.11:8082): rpc ee rror: code = 1 desc = context canceled 2017/12/05 18:45:04 Unable to connect to doppler (192.168.248.11:8082): rpc erroo r: code = 1 desc = context canceled 2017/12/05 18:45:04 Disconnecting from stream (192.168.248.10:8082) (doppler.diss connect=false) (ctx.disconnect=1) 2017/12/05 18:45:04 Disconnecting from stream (192.168.248.9:8082) (doppler.discc onnect=false) (ctx.disconnect=1) 2017/12/05 18:45:04 Disconnecting from stream (192.168.248.11:8082) (doppler.diss connect=false) (ctx.disconnect=1)

3. Loggregator を再始動します。次のコマンドを実⾏します。

bosh2 -e IBMCloudPrivate -d Bluemix ssh <nats> sudo su - monit restart unbound monit summary monit restart loggregator_trafficcontroller exit

ここで、<nats> は、エラーを⽣成した nats インスタンスです。

4. エラー・メッセージが表⽰された nats インスタンスごとに、前のステップを繰り返します。

Cloud Foundry 管理ユーザーがロックアウトされる

Cloud Foundry 管理ユーザーがロックアウトされます。

症状

Cloud Foundry 管理ユーザーが IBM® Cloud Private Cloud Foundry からロックアウトされます。

問題の解決

1. /data/CloudFoundry/credentials.yml ファイルの uaa_admin_client_secret 値を取得します。

2. uaa_admin_client_secret 値を使⽤して、UAAC で Cloud Foundry UAA に接続します。次のコマンドを実⾏します。

uaac target <uaa> uaac token client get admin -s <uaa_admin_client_secret> uaac password set <user_name> -p <new_password>

3. /data/CloudFoundry/bmxconfig.yml ファイルで、管理ユーザー資格情報を更新します。

BOSH デプロイメント中に consul ジョブが失敗する

BOSH デプロイメント中に consul ジョブが失敗します。

症状

BOSH デプロイメントを実⾏した後、以下のコマンドを使⽤して仮想マシンにログインします。ここで、またはは、ssh 接続の特定の仮想マシンを識別するものです。

bosh2 -e IBMCloudPrivate -d Bluemix ssh <job name>/<uuid> または


bosh2 -e IBMCloudPrivate -d Bluemix ssh <job name>/<index>

以下のように、プロセスの状況を表⽰します。

sudo su - monit summary

次に、/var/vcap/sys/log/consul_agent フォルダー内のログを確認します。 stderr または stdout ログに、1つ以上の consul エージェントに到達できないと⽰されています。

問題の解決

1. 以下のように、custom-cf.yml ファイルを変更します。

fqdn_groups: consul_agent_ips: - (( delete "<instance_name>" ))

ここで、<instance_name> は、失敗した BOSH ジョブの名前です。

2. デプロイメントを再度開始します。3. デプロイメントが成功した場合、custom-cf.yml ファイルに追加したコード⾏を削除します。4. デプロイメントを再度開始し、成功したことを確認します。

inception コンテナーが開始しない

inception コンテナーが開始しません。

症状

インストール時に、以下のメッセージが表⽰されます。

Error response from daemon: driver failed programming external connectivity on the endpoint...

問題の解決

インストール時に launch.sh コマンドで指定したポートを有効にします。次のコマンドを実⾏します。

ufw enable <port_number>

ここで、<port_number> は、指定した値です。デフォルト・ポート番号は 8483 です。

iptables を使⽤して、インバウンド通信にホストで指定したポートを開くこともできます。

Cloud Foundry デプロイメントがタイムアウトになる

Cloud Foundry デプロイメントがタイムアウトになって完了しません。

症状

デプロイメントの各ステップには、デフォルトのタイムアウトがあります。ステップのデプロイメントにかかっている時間がデフォルトのタイムアウト値を超えると、以下のメッセージのようなエラーが表⽰されます。


State name: director Label : Director Phase : Script : /repo_local/cfp-bosh-templates/2.3.2c-ff920bc/scripts/deploy-director.sh Timeout : 60 LogPath : /data/logs/CloudFoundry/deploy-director.log Status : FAILED Start time: Wed Jan 10 18:06:52 UTC 2018 End time : Wed Jan 10 19:06:52 UTC 2018 Reason : Cmd failed:State director killed as timeout reached

原因

通常、このエラーが発⽣するのは、inception コンテナーと vSphere 環境間のネットワーク接続が遅い場合です。

問題の解決

当該ステップにより⼤きいタイムアウト値を設定することで、このタイムアウト値を⼤きくすることができます。

1. インストール・ディレクトリーで、以下のコマンドを実⾏します。

./cm state -s <state_name> set --timeout <new_timeout>

ここで、<state_name> は失敗した状態の名前であり、<new_timeout> はステップの実⾏が完了する必要がある時間 (分) です。

2. launch_deployment.sh コマンドを再度実⾏してください。

Cloud Foundry の検証が失敗する

Cloud Foundry の検証が失敗します。

症状

検証で警告ではなくエラーが表⽰されます。ただし、確認後、サポート・チームおよびお客様は、環境は適切に構成

されていると推測しています。

問題の解決

1. エラーを確認し、インフラストラクチャーが正しく構成されていることを確かめます。2. uiconfig ファイルに正しい情報が含まれているかどうかを確認します。3. 構成が正しい場合、検証なしでデプロイメントを実⾏します。次のコマンドを実⾏します。

launch_deployment.sh --no-validation

特定の仮想マシン・ジョブで Cloud Foundry デプロイメントが失敗する

特定の仮想マシン・ジョブで Cloud Foundry デプロイメントが失敗します。

症状

Cloud Foundry アプリケーションをデプロイすると、以下のメッセージのようなエラーが表⽰されます。


Started updating job debian_nfs_server > debian_nfs_server/0 (c9a7c3c2-1d3b-41d2-a14c-f3c4f1ec742d) (canary)..... Done (00:01:13) Started updating job consul > consul/0 (7ade5ffb-a450-46e3-b94a-c1f8be310ef7) (canary)..... Done (00:01:08) Started updating job nats > nats/0 (76fe6c8e-1d21-4422-a407-8f79a78e03b7) (canary)...... Done (00:01:15) Started updating job ccdb_ng > ccdb_ng/0 (d4b559cb-b1e8-4b20-87de-37182e2b30ec) (canary)..... Done (00:01:10) Started updating job uaadb > uaadb/0 (e68e8783-049b-4f10-95c4-e922d2eccff6) (canary)..... Done (00:01:11) Started updating job router > router/0 (20d6e777-2ffe-42f7-8fbd-8b1675c5fa3c) (canary).... Done (00:00:47) Started updating job dea_next > dea_next/0 (75dae58e-de27-4f61-b396-1618fcc1ac04) (canary)..... Done (00:01:05) Started updating job cc_core > cc_core/0 (87de372a-ac40-471c-b621-b4a6ac3ca602) (canary)........................................ Failed: 'cc_core/0 (87de372a-ac40-471c-b621-b4a6ac3ca602)' is not running after update. Review logs for failed jobs: cloud_controller_ng, cloud_controller_worker_local_1, cloud_controller_worker_local_2, nginx_cc, cloud_controller_migration, cloud_controller_worker_1, cloud_controller_clock (00:08:48) Error 400007: 'cc_core/0 (87de372a-ac40-471c-b621-b4a6ac3ca602)' is not running after update. Review logs for failed jobs: cloud_controller_ng, cloud_controller_worker_local_1, cloud_controller_worker_local_2, nginx_cc, cloud_controller_migration, cloud_controller_worker_1, cloud_controller_clock Task 9 error

このメッセージでは、失敗したジョブの名前は cloud_controller_ng です。

問題の解決

1. 管理資格情報を使⽤して BOSH Director にログインします。2. BOSH デプロイメントが設定されていることを確認します。設定されていない場合は、BOSH CLI をインストールします。

3. cc_core の ID を判別します。次のコマンドを実⾏します。

bosh2 -e IBMCloudPrivate -d Bluemix vms

4. 失敗したサービスを判別するために、以下のコマンドを実⾏します。

bosh2 -e IBMCloudPrivate -d Bluemix ssh cc_core/<uuid> sudo su monit summary


The Monit daemon 5.2.5 uptime: 27m Process 'unbound' running Process 'consul_agent' running Process 'cloud_controller_ng' Execution failed Process 'cloud_controller_worker_local_1' initializing Process 'cloud_controller_worker_local_2' initializing Process 'nginx_cc' initializing Process 'cloud_controller_migration' Does not exist Process 'cloud_controller_worker_1' Does not exist File 'nfs_mounter' accessible Process 'cloud_controller_clock' Does not exist Process 'statsd-injector' running Process 'route_registrar' running Process 'loginserver' running Process 'uaa' running Process 'mod_vms' running Process 'metron_agent' running System 'system_localhost' running


この例では、cloud_controller_ng プロセスが失敗しています。

5. 以下のように、失敗したプロセスのディレクトリーの場所を探索します。

cd /var/vcap/sys/log/<failed_process> ; ls

ここで、<failed_process> は、失敗したプロセスの名前です。出⼒は、以下のコードのようになります。

-rw-r--r-- 1 root root 20250 Aug 22 17:30 cloud_controller_ng_ctl.err.log -rw-r--r-- 1 root root 24159 Aug 22 17:30 cloud_controller_ng_ctl.log -rw-r--r-- 1 root root 33988 Aug 22 17:30 cloud_controller_worker_ctl.err.log -rw-r--r-- 1 root root 21678 Aug 22 17:30 cloud_controller_worker_ctl.log -rw-r----- 1 root root 506 Aug 22 17:00 pre-start.stderr.log -rw-r----- 1 root root 0 Aug 22 17:00 pre-start.stdout.log

6. エラーが⾒つかるまで、このディレクトリー内の各ログを確認します。

7. エラーを訂正してください。

IP アドレスの競合のため、Cloud Foundry デプロイメントが失敗する

IP アドレスの競合のため、Cloud Foundry デプロイメントが失敗します。

症状

Cloud Foundry デプロイメントの仮想マシン (VM) 作成ステージで、以下のメッセージのようなエラーが表⽰されます。

11:52:30 | Compiling packages: tps/ef9adb86728a43959bd8c3549106f7582513a294 (00:00:06) L Error: Unknown CPI error 'Unknown' with message 'Detected IP conflicts with other VMs on the same networks: tools-vm01 on network VM Network with ip 172.16.215.160' in 'create_vm' CPI method..................

問題の解決

1. vCenter インスタンスを開き、エラー・メッセージで表⽰された IP アドレスを VM が既に使⽤しているかどうかを検索して確認します。 IBM Cloud Private Cloud Foundry デプロイメントの⼀部ではない VM が当該 IP アドレスを使⽤している可能性があります。

2. IP アドレスが使⽤中の場合、IBM Cloud Private Cloud Foundry デプロイメントの⼀部である VM によって使⽤されているのかどうかを判別します。 VM 名が vm- 接頭部で開始している場合、その VM は IBM Cloud PrivateCloud Foundry デプロイメントの⼀部です。

3. 問題を修正します。VM が IBM Cloud Private Cloud Foundry デプロイメントの⼀部でない場合、IBM Cloud Private CloudFoundry のインストール時に指定した subnet または address_range に VM が含まれています。 IBMCloud Private Cloud Foundry ⽤に予約する subnet および address_range の値を決定し、IBM CloudPrivate Cloud Foundry インストール済み環境を更新します。『IBM® Cloud Private Cloud Foundry のインストール』を参照してください。

VM が IBM Cloud Private Cloud Foundry デプロイメントの⼀部であり、エラーがコンパイル・フェーズで発⽣した場合、VMware リソース・プールをクリーンアップする必要が⽣じることがあります。データ・ディレクトリーを削除してデプロイメントを再始動した場合、インストール中に作成された VM が削除されないことがあります。リソース・プールをクリアし、デプロイメントを再度実⾏します。VM が IBM Cloud Private Cloud Foundry デプロイメントの⼀部であり、エラーがコンパイル・フェーズで発⽣した場合は、IBM サポートにお問い合わせください。


ポート・グループに管理者許可がない

/<installation_directory>/uiconfig-template.yml ファイルに定義されているユーザーの VMware 特権が、ポート・グループで⼗分でありません。 deploy-director.sh スクリプトを実⾏すると、失敗します。

症状

以下のコマンドの出⼒に、ポート・グループ情報が含まれていません。

docker exec -it inception-<name> "cat /tmp/bosh-init-run.log"

ここで、<name> は、インストール時に launch.sh -n <name> スクリプトを実⾏したときに指定した該当値です。

問題の解決

伝搬ありで vSphere 分散スイッチを使⽤している場合、/<installation_directory>/uiconfig-template.yml ファイルに管理者として定義したユーザーを、ポート・グループが含まれているフォルダーに追加します。標準仮想スイッチを使⽤している場合、ユーザーをポート・グループに追加します。

Microbosh Director で bosh/0 の初期化に失敗する

⼀部のサービスがオンラインにならないため、BOSH Director がデプロイされません。

症状

BOSH Director をホストする仮想マシンで monit summary を実⾏すると、出⼒に mod_vms: failed が含まれています。

問題の解決

1. launch_deployment.sh スクリプトを使⽤してデプロイメントを起動するために使⽤した uiconfig-template.yml で、以下のテキストを director_custom YML キーに追加します。

director_custom: | --- jobs: - name: bosh templates: - (( delete "mod_vms" ))

2. 変更を適⽤するために、launch_deployment.sh スクリプトを再度実⾏します。

EHOSTUNREACH エラーのため、Cloud Foundry アプリケーション・デプロイメントが失敗する

EHOSTUNREACH エラーのため、Cloud Foundry アプリケーション・デプロイメントが失敗します。

症状

Cloud Foundry アプリケーションをデプロイすると、以下のメッセージのようなエラーが表⽰されます。


-----> Building dependencies Installing node modules (package.json) npm ERR! Linux 4.4.0-75-generic npm ERR! argv "/tmp/app/vendor/node/bin/node" "/tmp/app/vendor/node/bin/npm" "install" "--unsafe-perm" "--userconfig" "/tmp/app/.npmrc" npm ERR! node v6.12.2 npm ERR! npm v3.10.10 npm ERR! code EHOSTUNREACH npm ERR! errno EHOSTUNREACH npm ERR! syscall connect npm ERR! connect EHOSTUNREACH 151.101.40.162:443 npm ERR! npm ERR! If you need help, you may report this error at: npm ERR! <https://github.com/npm/npm/issues> npm ERR! Please include the following file with any support request: npm ERR! /tmp/app/npm-debug.log -----> Build failed Some possible problems: - Node version not specified in package.json http://docs.cloudfoundry.org/buildpacks/node/node-tips.html Failed to compile droplet Exit status 223 Staging failed: Exited with status 223 Destroying container Successfully destroyed container FAILED Error restarting application: BuildpackCompileFailed

このメッセージでは、失敗したアプリケーション、またはそのアプリケーションによって使⽤されるビルドパック

が、コンテンツをダウンロードするためにインターネットにアクセスしようとしています。インターネットに到達するために HTTP プロキシーを使⽤する必要がある場合、プロキシーを使⽤するようにアプリケーションを構成する必要があります。

問題の解決


cf login

2. アプリケーションがデプロイされている組織およびスペースに変更します。

cf target -o <org> -s <space>

3. アプリケーションの HTTP プロキシー変数を設定します。例えば、プロキシーが http://myproxy.com:3128 である場合、以下のコマンドを実⾏します。

cf set-env myApp https_proxy "http://myproxy.com:3128" cf set-env myApp http_proxy "http://myproxy.com:3128"

4. アプリケーションを再始動します。次のコマンドを実⾏します。

cf restart myApp

「no route to host」というエラーのため、Cloud Foundry でのDocker アプリケーション・デプロイメントが失敗する


「no route to host」というエラーのため、Cloud Foundry での Docker アプリケーション・デプロイメントが失敗します。

症状

Cloud Foundry で Docker アプリケーションをデプロイすると、以下のメッセージのようなエラーが表⽰されます。

Creating container Successfully created container Staging... Staging process started ... Failed to talk to docker registry: Get https://registry-1.docker.io/v2/: dial tcp 54.152.209.167:443: getsockopt: no route to host Failed to talk to docker registry: Get http://registry-1.docker.io/v2/: dial tcp 54.152.209.167:80: getsockopt: no route to host Staging process failed: Exit trace for group: builder exited with error: failed to fetch metadata from [cloudfoundry/lattice-app] with tag [latest] and insecure registries [] due to Get http://registry-1.docker.io/v2/: dial tcp 54.152.209.167:80: getsockopt: no route to host Exit status 2 Staging Failed: Exited with status 2 Destroying container Successfully destroyed container FAILED Error restarting application: StagingError

このメッセージでは、失敗したアプリケーションが、コンテンツをダウンロードするためにインターネットにアクセ

スしようとしています。インターネットに到達するために HTTP プロキシーを使⽤する必要がある場合、プロキシーを使⽤するようにアプリケーションを構成する必要があります。

問題の解決


cf login

2. アプリケーションがデプロイされている組織およびスペースに変更します。

cf target -o <org> -s <space>

3. 以下のように、Docker アプリケーションを開始せずにプッシュします。

cf push myApp --docker-image --no-start <docker container image>

4. アプリケーションの HTTP プロキシー変数を設定します。例えば、プロキシーが http://myproxy.com:3128 である場合、以下のコマンドを実⾏します。

cf set-env myApp https_proxy "http://myproxy.com:3128" cf set-env myApp http_proxy "http://myproxy.com:3128"

5. アプリケーションを開始します。次のコマンドを実⾏します。

cf restart myApp

OpenStack で BOSH ssh が失敗する

OpenStack で BOSH ssh が失敗します。

症状


OpenStack 上で実⾏しているときに、bosh 仮想マシンに対して bosh2 ssh コマンドを試⾏すると、以下の通知で失敗します。

Host key verification failed.

問題の解決

1. 管理資格情報を使⽤して BOSH Director にログインします。2. BOSH デプロイメントが設定されていることを確認します。設定されていない場合は、BOSH CLI をインストールします。

3. 以下のコマンドを実⾏して、BOSH ディレクターの IP アドレスを⾒つけます。

bosh2 -e IBMCloudPrivate envs

4. ログインする仮想マシンのインスタンス ID を判別します。次のコマンドを実⾏します。

bosh2 -e IBMCloudPrivate -d Bluemix vms

5. 仮想マシンにアクセスするための秘密鍵が使⽤可能であることを確認します。これは、uiconfig.yml 内で openstack_key_pair_private として指定されているのと同じ鍵です。また、uiconfig.yml 内でキー openstack_key_pair_name によって参照され、Key Pair として OpenStack にインポートされるものと同じ鍵でもあります。

Inception コンテナーに秘密鍵ファイルを作成する必要がある場合、以下のコマンドを実⾏できます。

export KEYNAME=`bosh2 int /data/uiconfig.yml --path /uiconfig/openstack_key_pair_name` bosh2 int /data/uiconfig.yml --path /uiconfig/openstack_key_pair_private > /data/${KEYNAME}.pem chmod 600 /data/${KEYNAME}.pem

6. いくつかの追加パラメーターを指定した BOSH SSH コマンドを使⽤します。次のコマンドを実⾏します。

bosh2 -e IBMCloudPrivate -d Bluemix ssh <Instance ID> --gw-private-key=<private key> --gw-host=<director IP> --gw-user=vcap

Bosh 仮想マシンが応答しなくなる

症状 (検出)

1. Prometheus アラートに、failure メッセージがある仮想マシンが表⽰されます。2. Ops コンソールに、failure (⾚いドット) メッセージがある仮想マシン (ジョブ) が表⽰されます。3. bosh2 -e IBMCloudPrivate vms に、failure メッセージがある仮想マシン (ジョブ) が表⽰されます。

ディスク使⽤量 100% の識別

1. Bosh2 クライアントにログインします。2. 以下のコマンドを実⾏して、ディスク使⽤量を確認します。

bosh2 -e IBMCloudPrivate vms --vitals

3. Bosh2 を使⽤して、問題の仮想マシンに接続します。ここで、0 は、問題の仮想マシンのインスタンスです。

bosh2 -e IBMCloudPrivate -d Bluemix ssh JOB_NAME/0

役に⽴つコマンド

仮想マシンに接続されたら、以下のコマンドを実⾏できます。


df -k # 仮想マシンのすべてのディスク使用量をリストします。 du --max-depth=1 # 現在の場所にあるすべてのファイルおよびディレクトリーのサイズをリストします。

ccdb_ng および uaadb [ /var/vcap/store ] の永続ディスク使⽤量が 100% の場合の修正法

4. 以下のコマンドを実⾏して、vcap ユーザーになります。

sudo su vcap

5. トランザクション・ログをクリーンアップします。

/var/vcap/packages/postgres-9.4.9/bin/pg_resetxlog -f /var/vcap/store/postgres/postgres-9.4.9/

注: このコマンドにはしばらく時間がかかる場合がありますが、/var/vcap/store のサイズが削減されます。

6. ディスク使⽤量が 100% でなくなったことを確認します。

[ /var/vcap/data ] の⼀時ディスク使⽤量が 100% の場合の修正法

1. root ユーザーとしてログインします。

sudo su -

2. 仮想マシンで、cd /var/vcap/data にナビゲートします。3. ファイル・サイズが最⼤のファイルやディレクトリーをたどって、削除できる⼤きなファイルまたはディレクトリーがないかどうかを判別します。

du --max-depth=1

4. /var/vcap/data/sys/log 内のファイルはほとんど削除できます。ログが必要な場合は、それらを外部ロケーションにコピーしてから、ローカル・コピーを削除してください。

5. ディスク使⽤量が 100% でなくなったことを確認します。

[ /var/vcap/data ] の⼀時ディスク使⽤量が 100% の場合の代替の修正法

注: この⽅法は、⼀時ディスクのみを修正します。現時点で、永続ディスク使⽤量が 100% の場合は、実⾏しないでください。

1. ⼀時ディスクには永続データが含まれていないため、仮想マシンを再作成できます。2. Bosh2 を使⽤して仮想マシンを再作成します。

bosh2 -e IBMCloudPrivate -d Bluemix recreate JOB_NAME/INDEX # Example: JOB_NAME/INDEX = ccdb_ng/0 Continue? [yN]: y

3. 仮想マシンが再作成されたら、ディスク使⽤量が 100% でなくなったことを確認します。

トラブルシューティングとサポート

IBM® Cloud Private を使⽤して問題を切り分けて解決する⽅法を学習します。

問題が、ディスク、メモリー、CPU 容量などのオペレーティング・システム要件に関連していないことを確認してください。システム要件について詳しくは、システム要件を参照してください。


サポートインストールログイン管理コンソールネットワークストレージイベントとログ Windows で CLI を使⽤して kubectl を認証できない

サポート

IBM® Cloud Private を使⽤する際にヘルプが必要な場合は、サポート・ページにアクセスしてください。

IBM® Cloud Private サポート・タイプ IBM® Cloud Private でのオープン・ソースのサポート

IBM® Cloud Private サポート・タイプ

IBM は、異なるレベルのサポートを異なるオファリングの IBM Cloud Private に提供し、さらにサポートが必要な場合は、サポート・プランを購⼊することができます。

IBM は、さまざまなエンタープライズ製品バンドルの⾼品質なサポート・プランを提供します。 IBM の広範なサポート・チームへのアクセスは、IBM Cloud Private (パスポート・アドバンテージ S&S) の購⼊に含まれています。IBM サポート・チームには、[サポート・ページからアクセスできます。

エンタープライズ製品バンドルを購⼊した場合は、IBM Cloud Private のプレミアム・サポートを購⼊することもできます。このプランでは、お客様のさらなる成功を⼿助けする、より早い応答性、サポートケースのより⾼い優先度、および指定された Client Success Manager (お客様の成功を導く担当者) が提供されます。 IBM Cloud Private プレミアム・サポートについて詳しくは、IBM Cloud Private Sales にお問い合わせください。

さらなる⽀援が必要なお客様には、IBM から追加のオープン・ソース・サポート・オプションを提供することもできます。これらのサービスについて詳しくは、IBM 営業またはオープン・ソース・ベンダーにお問い合わせください。

IBM Cloud Private-CE (Community Edition) は、以下を含むデジタル・サポート・プランを提供します。

公共の IBM Cloud Private-CE (Community Edition) Slack コミュニティー。登録するか、ログオンします。

スタック・オーバーフロー。 ibm-cloud-private タグが付いているスタック・オーバーフローについての質問を表⽰します。

IBM Cloud Private サポート・ページの Watson Chatbot。ログインせずにチャットボットを試⾏します。

IBM® Cloud Privateでのオープン・ソースのサポート

IBM® Cloud Private にはオープン・ソース・ソフトウェアが含まれるため、IBM では使⽤されるオープン・ソース・ソフトウェアのサポートを提供しています。

IBM は次の 3 つの⽅法でオープン・ソース・ソフトウェアを使⽤しています。

お得意様がベンダーの囲い込みを避けるのを⼿助けする

ソフトウェアのブロードキャスト・エコシステムとの互換性を確保する

商品の開発を加速させる


https://ibm.biz/icpsupport

https://slack-invite-ibm-cloud-tech.mybluemix.net/

https://ibm-cloud-tech.slack.com/messages/C2HQFDAET

https://stackoverflow.com/search?q=ibm-cloud-private

https://ibm.biz/icpsupport

IBM Cloud Private で使⽤される、成⻑した、エンタープライズ・レベルのオープン・ソース・コンポーネントは、注意深く選択され、統合され、製品⽂書と使⽤許諾に記載される通りに動作することをテストされます。コンポーネントには、Kubernetes、Docker Engine、Helm、ELK stack、Cloud Foundry のような必要不可⽋なオープン・ソース・コンポーネントが含まれます。

IBM® のソフトウェア・サポート・ハンドブックは、IBM のオープン・ソースのサポート・ステートメントに関する最も信頼のおけるリファレンスです。 IBM のオープン・ソースのサポート・ステートメントを確認するには、IBMソフトウェア・サポート・ハンドブックの『第三者ソフトウェアとオープン・ソース・ソフトウェア (Third partysoftware and Open Source software) 』を参照してください。 IBM Cloud Private のサポート・チームは、ユーザーとの対話を詳しく調べるためにこのステートメントの情報を使⽤します。

IBM Cloud Private のサポート・チームの主⽬的は、お客様ができるだけ早くサポート対象の製品を再び機能させることができるように⽀援することです。すべての IBM Cloud Private ユーザーに対してコミュニティー・サポート・オプションが使⽤可能ですが、IBM Cloud Private の各種バンドル・エンタープライズ・エディションのユーザーにとって、IBM サポートにお問い合わせいただくことが最善のサポート・オプションです。コミュニティー・サポート・チャネルは、IBM Cloud Private-CE (Community Edition) ユーザーにとって唯⼀のサポート・オプションです。詳しくは、製品サポート・タイプを参照してください。

IBM サポートにお問い合わせいただく場合は、オープン・ソースのサポートに 2 つのフェーズがあります。

1. 1 つ⽬は問題判別フェーズです。このフェーズで、サポート・エンジニアは、問題の根本原因がオープン・ソース・コードであるか IBM コードであるかを判別します。

2. もう 1 つはオープン・ソースのサポート・フェーズです。根本原因がオープン・ソース・コードだった場合は、サポート・エンジニアは問題が含まれているオープン・ソース・プロジェクトを特定し、次の⼿順を判別

するためにユーザーと共同で作業します。

IBM Cloud Private 内のオープン・ソース・ソフトウェアに重⼤な障害が検出された場合、IBM エンジニアはオープン・ソース・コミュニティー・リソースを使⽤して、問題に対する修正を送信します。結果の修正は統合およびテストされ、緊急アップデートとして、および次の製品リリースでお客様にリリースされます。重⼤な障害に有効な修正がコミュニティーにない場合は、IBM は合理的な業務努⼒によりお客様へのテスト修正を提供した後に、特定のオープン・ソース・コミュニティーと連携して公式の修正を作成する場合があります。サポート対象の修正を提供できるかどうかは、最終的にオープン・ソース・コミュニティーによって決定されます。

エンタープライズ・レベルのオープン・ソース・プロジェクトに重⼤な障害があると多くのクライアントが影響を受

け、問題解決のためにできるだけ早くコミュニティーが処理することにご注意ください。お客様 1 社だけでオープン・ソースの重⼤な障害が発⽣することはあまりありません。

IBM は、IBM Cloud Private に同梱されていないオープン・ソース・ソフトウェアをサポートすることはできません。また、お客様が IBM Cloud Private オープン・ソース・コードに製品の更新以外の追加、削除、アップグレードを⾏った場合、そのコードはサポートされません。 Cloud Foundry については、IBM は、適切なオープン・ソース・コミュニティーへのコミュニティー・ビルドパックおよびランタイムにおける障害の報告を⽀援する場合がありま

す。 IBM は、これらの Cloud Foundry コミュニティー・ビルドパックとランタイムの修正を提供できません。

注: IBM® Cloud Private がサポート対象のオペレーティング・システム、Kubernetes、Docker、およびその他の従属インフラストラクチャーの新しいバージョンをサポートするようになるのは、新規リリース発表後にそれらが IBM®Cloud Private チームによって完全にテストされた場合です。

さらなるサポートが必要な場合は、IBM が⽀援します。 IBM Cloud Private プレミアム・サポートについて詳しくは、製品資料の製品サポート・タイプを参照してください。

インストール

よくあるインストールのエラーについて検討します。

インストールが停⽌または失敗する


https://www-304.ibm.com/support/customercare/sas/f/handbook/policies.html#thirdparty

認証コンポーネントを開始できない etcd コンポーネントを開始できない SSH 経由の接続に失敗するコンテナーの作成に失敗する Kubelet コンテナーを開始できない DNS サーバーの検証の失敗 Ngnix Ingress コントローラーが開始しないポッドの初期化に失敗する Heapster がエラー状態のままとどまるポッドが CrashLoopBackOff で失敗する

インストールが停⽌または失敗する

インストールが停⽌または失敗します。

症状

明確な説明、警告、エラー・メッセージなしにインストールが停⽌または失敗します。

原因

インストールの停⽌または失敗は、さまざまな原因に起因することがあります。根本原因を特定するには、インストール中に詳細レポートを取得します。

問題の診断

詳細 (-vvv) オプションを指定して、デプロイメント・コマンドを再実⾏します。

Standard Edition:

docker run -e LICENSE=accept --net=host -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3-ee install -vvv

Community Edition:

docker run -e LICENSE=accept --net=host -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3 install -vvv

タイマーを設定してデプロイメントを再実⾏することもできます。このタイマーは、各タスクにかかる時間をトラッキングし、この情報は問題の原因となるステップを特定するのに役⽴ちます。

Standard Edition:

docker run -e LICENSE=accept -e ANSIBLE_CALLBACK_WHITELIST=profile_tasks,timer --net=host -t -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3-ee install

Community Edition:

docker run -e LICENSE=accept -e ANSIBLE_CALLBACK_WHITELIST=profile_tasks,timer --net=host -t -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3 install

etcd コンポーネントが開始できない

インストール中に、etcd コンポーネントが開始できません。


症状

etcd コンポーネントの開始を 10 分間待った後、インストールが終了します。

注: デフォルトで、インストールは終了する前に 10 分間待機します。 /<installation_directory>/cluster/config.yaml ファイル内の wait_for_timeout パラメーターを更新することで、この待機時間を変更することができます。パラメーター値は秒単位で指定してください。

原因

kubelet コンテナーが開始できない。etcd イメージがプルできない。etcd コンテナーが開始できない。etcd ポートにアクセスできない。デフォルトの etcd ポートは 4001 です。

問題の解決

kubelet が実⾏中かどうか確認します。

1. マスター・ノードにログインします。

2. 以下のコマンドを実⾏して kubelet の状況を確認します。

systemctl status kubelet

kubelet が実⾏されていない場合は、次のコマンドを実⾏してログを取得してください。

journalctl -u kubelet &>kubelet.log

IBM® Cloud Private-CE 環境において、インターネット・アクセスが可能で etcd イメージをプルできることを確認します。

IBM® Cloud Private エンタープライズ環境およびクラウド・ネイティブ環境で、etcd イメージがブート・ノードにコピーされていることを確認します。次のコマンドを使⽤して、etcd イメージがロードされたかどうか確認してください。

docker images | grep etcd

etcd コンテナーが開始されたかどうか確認します。

1. root 権限を持つユーザーとしてマスター・ノードにログインします。

2. 次のコマンドを実⾏して etcd コンテナーの状況を確認します。

docker ps | grep etcd

etcd コンテナーが開始していない場合は、次のコマンドを実⾏してログを取得してください。

1. etcd コンテナーの ID を取得します。

docker ps -a | grep etcd

2. 次のコマンドを実⾏してログを取得します。

docker logs <etcd container ID> &>etcd.log

etcd に接続できるかどうか確認します。次のコマンドを実⾏します。

telnet <master node IP or cluster virtual IP address> 4001


ファイアウォールがポート 4001 をブロックしていないことを確認してください。

SSH 経由の接続に失敗する

SSH 接続の問題によりインストールが失敗します。

症状

次のエラー・メッセージが表⽰され、インストールが失敗します。

fatal: [x.x.x.x] => Failed to connect to the host via ssh'

原因

ブート・ノードからクラスター内の他のノードへのパスワードなしの SSH がセットアップされていません。

問題の解決

パスワードなしの SSH のセットアップについて詳しくは、クラスター・ノード間での SSH 鍵の共有 (SharingSSH keys among cluster nodes) を参照してください。パスワードなしの SSH が、ブート・ノードからクラスター内の他のすべてのノードに構成されるようにしてください。単⼀ノードがブートとマスターの両⽅に使⽤される場合でも、そのノードでパスワードなしのSSH を構成する必要があります。次のコマンドを実⾏して、パスワードなしの SSH がクラスター内で構成されていることを確認します。

ssh -vvv -i cluster/ssh_key [email protected]

コンテナーの作成に失敗する

コンテナーの作成中にインストールが失敗します。

症状

以下のエラー・メッセージが表⽰され、インストールが失敗します。

Error creating container: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=XXX)

問題の解決

docker_api_timeout パラメーターの値を⾼くします。 docker_api_timeout パラメーターについて詳しくは、config.yaml ファイルを使⽤したクラスターのカスタマイズを参照してください。

Kubelet コンテナーが開始できない

kubelet コンテナーが開始できない。

シナリオ 1: inotify リソースの問題が原因で kubelet コンテナーを開始できないシナリオ 2: cgroup ドライバーの構成が誤っているために kubelet コンテナーを開始できないシナリオ 3: RHEL で Kubelet コンテナーを開始できないシナリオ 4: マスター・ノードで Kubelet コンテナーを開始できない


シナリオ 1: inotify リソースの問題が原因で kubelet コンテナーを開始できない

症状

Kubelet コンテナーを開始できず、以下の出⼒のようなメッセージが表⽰されます。

hyperkube[19678]: E1121 03:18:16.730638 19678 raw.go:140] Failed to watch directory "/sys/fs/cgroup/blkio/system.slice": inotify_add_watch /sys/fs/cgroup/blkio/system.slice/var-lib-kubelet-pods-d111600d\x2dcdf2\x2d11e7\x2d8e6b\x2dfa163ebb68b9-volumes-kubernetes.io\x7esecret-etcd\x2dcerts.mount: no space left on device hyperkube[19678]: F1121 03:18:16.730652 19678 kubelet.go:1302] Failed to start cAdvisor inotify_add_watch /sys/fs/cgroup/blkio/system.slice/var-lib-kubelet-pods-d111600d\x2dcdf2\x2d11e7\x2d8e6b\x2dfa163ebb68b9-volumes-kubernetes.io\x7esecret-etcd\x2dcerts.mount: no space left on device systemd[1]: kubelet.service: Main process exited, code=exited, status=255/n/a systemd[1]: kubelet.service: Unit entered failed state. systemd[1]: kubelet.service: Failed with result 'exit-code'.

原因

この問題の根本原因は、Kubernetes 公開問題リポジトリーで概説されています。 inotify resources exhausted :possible leak in cAdvisor を参照してください。

問題の解決

この問題を回避するには、システムの fs.inotify.max_user_watches オプションの設定を変更するか、ホスト・マシンをリブートします。

オプション 1

影響を受けるノードで、fs.inotify.max_user_watches オプションを現在の設定よりも⼤きい値に設定します。

1. 現在の設定を⾒つけます。

cat /proc/sys/fs/inotify/max_user_watches


8192

2. より⼤きい値を割り当てます。

sudo echo 1048576 > /proc/sys/fs/inotify/max_user_watches

オプション 2

影響を受けるノードをリブートします。

シナリオ 2: cgroup ドライバーの構成が誤っているために kubelet コンテナーを開始できない

症状

Kubelet コンテナーを開始できず、以下の出⼒のようなメッセージが表⽰されます。



hyperkube[327]: F0424 08:15:51.227460 327 server.go:233] failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd" systemd[1]: kubelet.service: Main process exited, code=exited, status=255/n/a systemd[1]: kubelet.service: Unit entered failed state. systemd[1]: kubelet.service: Failed with result 'exit-code'.

原因

kubelet cgroup ドライバーは、Docker cgroup ドライバーとは異なります。

問題の解決

この問題を回避するには、systemd を使⽤するように kubelet デーモンを更新するか、cgroupfs を使⽤するようにDocker デーモンを更新します。

オプション 1

systemd を使⽤するように kubelet デーモンを更新します。

1. 影響を受けるノードで、/ etc/systemd/system/kubelet.service ファイル内の -cgroup-driver パラメーターを systemd に更新します。出⼒は、以下のコードのようになります。

EnvironmentFile=-/etc/environment ExecStart=/opt/kubernetes/hyperkube kubelet \ ........ --cluster-domain=cluster.local \ --cgroup-driver=systemd \ --fail-swap-on=false ...........

2. kubelet サービスを再ロードして再開します。

systemctl stop kubelet.service systemctl start kubelet.service

オプション 2

cgroupfs を使⽤するように Docker デーモンを更新します。

1. 影響を受けるノードで、/lib/systemd/system/docker.service ファイルを cgroupfs に更新します。

[Service] Type=notify # the default is not to use systemd for cgroups because the delegate issues still # exists and systemd currently does not support the cgroup feature set required # for containers run by docker ExecStart=/usr/bin/dockerd --log-opt max-size=10m --exec-opt native.cgroupdriver=cgroupfs -H fd:// ...............

2. Docker サービスを再ロードして再開します。

systemctl daemon-reload systemctl restart docker

シナリオ 3: RHEL で Kubelet コンテナーを開始できない

症状


次のテキストを含むメッセージが表⽰されてインストールが失敗します。

misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"

次のコマンドを実⾏します。

docker info | grep "Cgroup Driver"

出⼒に Cgroup Driver: systemd が表⽰される場合、IBM® Cloud Private が使⽤する --cgroup-driver パラメーター値を更新する必要があります。

原因

Docker の複数のバージョンで、Cgroup Driver 値に cgroupfs の代わりに systemd を使⽤しています。

問題の解決

この問題を修正するには、以下を実⾏します。

1. config.yaml ファイルに次の⾏を追加します。

kubelet_extra_args: ["--cgroup-driver=systemd"]

2. IBM Cloud Private インストール・プロセスを繰り返します。

シナリオ 4: マスター・ノードで Kubelet コンテナーを開始できない

症状

以下のメッセージが表⽰されてインストールが失敗します。

TASK [k8s-master : Start Kubelet container on Master nodes] ******************** fatal: [172.16.188.123] => Error starting container 6f57324d6f8deb084a52f300acab480ec7c90704fd2f0923fbb323b805ee9a1e: 500 Server Error: Internal Server Error ("{"message":"linux mounts: Path /var/lib/kubelet is mounted on / but it is not a shared mount."}")

原因

サポートされていない Docker バージョンです。不正な MountFlags 値です。

問題の解決

この問題を修正するには、以下を実⾏します。

インストールされている Docker バージョンが 1.12.0 よりも新しいことを確認してください。

MountFlags パラメーターが shared に設定されていることを確認してください。 MountFlags 値を確認するには、以下のコマンドを影響を受けるノードで実⾏します。

systemctl cat docker.service

例えば、「症状」セクションのサンプルのエラー・メッセージを使⽤して、ホスト 172.16.188.123 で systemctl cat docker.service コマンドを実⾏できます。


systemd ユニット・ファイル docker.service の⼿動による作成について詳しくは、https://docs.docker.com/engine/admin/systemd/#manually-creating-the-systemd-unit-files を参照してください。

DNS サーバーの検証の失敗

DNS サーバーの検証ステージでインストールが失敗します。

症状

以下のメッセージが表⽰されてインストールが失敗します。

fatal: [x.x.x.x] => A loopback IP is used in your DNS server configuration. For more details, see https://ibm.biz/dns-fails.

原因

エラー・メッセージに⽰されているクラスター・ノードが、DNS サーバーとしてループバック IP (127.0.0.1 または127.0.1.1) を使⽤しています。または、エラー・メッセージに⽰されているクラスター・ノードに、/etc/resolv.confファイルがありません。

ループバック IP を DNS サーバーとして使⽤する場合、サービスがコンテナーの内部から外部ドメインを解決しようと試みると、問題が発⽣する可能性があります。

問題の解決

1. cluster/config.yaml 構成ファイルに以下の設定を追加します。

loopback_dns: true

2. インストールを再試⾏します。

3. クラスターが正常にインストールされたら、kubedns daemonset を更新します。

kubectl edit daemonset kube-dns --namespace=kube-system

対話式インターフェースから、以下のようにファイルを更新します。

- name: dnsmasq image: ibmcom/xxx livenessProbe: httpGet: path: /healthz-dnsmasq port: 8080 scheme: HTTP initialDelaySeconds: 60 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 5 args: - --cache-size=1000 - --no-resolv - --server=127.0.0.1#10053 + - --server=8.8.8.8 + - --all-servers - --log-facility=-

この問題について詳しくは、https://github.com/kubernetes/kubernetes/issues/23474 を参照してください。


https://docs.docker.com/engine/admin/systemd/#manually-creating-the-systemd-unit-files


Ngnix Ingress コントローラーが開始しない

Ngnix Ingress コントローラーの開始に失敗しました。

症状

Docker ログに次のエラー・メッセージが表⽰されます。

epoll_create() failed (24: Too many open files)

原因

オープンしたファイルの数がシステムしきい値を超えました。デフォルトでは、1024 を超えるファイルを開くことはできません。 ulimit -n コマンドを実⾏して、オープンするファイルの制限を確認することができます。

問題の解決

1. docker.service ファイルをオープンし、次のコードを追加します。

LimitNOFILE=infinity LimitNPROC=infinity LimitCORE=infinity

2. Docker を再始動します。

docker restart

ポッドが初期化に失敗する

ポッドが dm_task_set_cookie Cookie を設定できないため、初期化に失敗します。

症状

⼀部のポッドのステータスが rpc error: code = 2 desc = Error response from daemon: {"message":"devmapper: Error activating devmapper device for '68781a983adeef6156b303e9ffb18251a5fdd7267d0591226e11066dc9e9fe7d-init': devicemapper: Can't set cookie dm_task_set_cookie failed"} となっています。

原因

バージョン 17.06.2 より前の Docker バージョンでは、dm_task_set_cookie Cookie を正しく設定できません。

問題の解決

次のコマンドを実⾏して、Docker サービスを再始動します。

dmsetup udevcomplete_all

firewalld が使⽤可能なときにインストールが失敗する

Red Hat Enterprise Linux™ (RHEL) 7 に IBM® Cloud Private をインストールすると、firewalld が使⽤可能な場合にインストールが失敗する場合があります。


症状

次のようなエラー・メッセージが表⽰されてインストールが失敗します。

TASK [iptables : Creating firewalld rules for Etcd] **************************************************************************************************************************************************************************************** failed: [9.111.250.102] (item=4001) => {"failed": true, "item": 4001, "msg": "ERROR: Exception caught: org.fedoraproject.FirewallD1.Exception: COMMAND_FAILED"} failed: [9.111.250.102] (item=2380) => {"failed": true, "item": 2380, "msg": "ERROR: Exception caught: org.fedoraproject.FirewallD1.Exception: COMMAND_FAILED"} PLAY RECAP ********************************************************************************************************************************************************************************************************************************* 9.111.250.102 : ok=81 changed=16 unreachable=0 failed=1 localhost : ok=29 changed=0 unreachable=0 failed=0

問題の解決

1. 次のコマンドを実⾏して、ファイアウォール・デーモン・サービスを再始動します。

service firewalld restart

(または)

systemctl restart firewalld.service

2. インストールを再試⾏します。

Heapster がエラー状態のままになる

インストール後、Heapster が正常でない状態になり、復旧できない場合があります。

症状

以下のいずれかまたは両⽅の症状が発⽣する可能性があります。

1. コマンド kubectl logs <heapster_pod_name> eventer を実⾏すると、Failed to config ElasticSearch や no Elasticsearch node available などのメッセージを含む項⽬が表⽰される。

2. IBM® Cloud Private management console 内のポッドの「ログ」タブがロードされない。⻑時間経過してもログ項⽬が表⽰されません。

原因

Calico が Elasticsearch クラスターのネットワーク分離を正しく構成できなかった可能性があります。ポート 9200でクラスターと連絡するよう構成されたポッドが拒否される可能性があります。

問題の解決

Elasticsearch および Kibana のネットワーク・ポリシーを削除して再作成します。

1. 既存のポリシーを削除します。


kubectl delete netpol elasticsearch-client-policy elasticsearch-internal-policy kibana-policy -n kube-system

2. マスター・ノードにリモート接続します。

3. クラスターのインストール・ディレクトリーから、次のコマンドを実⾏します。

kubectl install -f cluster/cfc-components/elasticsearch/es-netpolicy.yaml

このコマンドは、Elasticsearch ノード上の Calico 設定をリセットします。 Kubernetes が次に Heapster ポッドの開始を試⾏する際は、Elasticsearch ポッドにアクセスできます。

4. (オプション) Heapster ポッドを削除し、Kubernetes を強制的に即時再始動します。

kubectl delete pod <heapster_pod_name>

ログイン

よくあるログインの問題について検討します。

CLI を使⽤してログインできないクラスター管理者が management console にログインできない

CLI を使⽤してログインできない

コマンド・ライン・インターフェース (CLI) を使⽤して IBM® Cloud Private クラスターにログインできません。

IBM Cloud Private のインストール後、bx pr login コマンドを実⾏すると、403 エラー・メッセージが表⽰される場合があります。

原因

セキュリティー・サービスが実⾏されていません。

問題の解決

kubectl CLI を使⽤してセキュリティー・サービスを開始してください。

1. クラスター management console にログインします。 management console を使⽤した IBM Cloud Private クラスターへのアクセスを参照してください。

2. <ユーザ名 (User name)> > 「クライアントの構成 (Configure client)」を選択します。以下のコードのように、クラスター構成の詳細が表⽰されます。

kubectl config set-cluster {cluster_name} --server=https://master_ip:8001 --insecure-skip-tls-verify=true kubectl config set-context {cluster_name}-context --cluster={cluster_name} kubectl config set-credentials {cluster_name}-user --token={token} kubectl config set-context {cluster_name}-context --user={cluster_name}-user --namespace=default kubectl config use-context {cluster_name}-context

この詳細の中で、master_ip は IBM Cloud Private クラスターのマスター・ノードの IP アドレスです。

3. 構成情報をコマンド・ラインにペーストして Enter を押します。



1. セキュリティー・サービス DaemonSet を削除します。

kubectl delete ds auth-pdp -n kube-system

2. ディレクトリーを platform-iam のロケーションに変更します。

cd /opt/<installation_directory>/cluster/cfc-components/platform-iam

3. デフォルトの構成でセキュリティー・サービスを開始します。次のコマンドを実⾏します。

kubectl apply -f platform-auth-pdp-ds.yaml

4. サービスが開始済みであることを確認します。次のコマンドを実⾏します。

docker ps | grep policy-decision

コマンド出⼒は以下のようになります。

ae7441f4321b ibmcom/iam-policy-decision "bash -c ./startia..." 33 hours ago Up 33 hours \ k8s_iam-policy-decision_auth-pdp-5m7t2_kube-system_59567fa9-bf50-11e7-8fbf-06d103a0bd94_0

5. bx pr login コマンドを使⽤してログインしてみてください。

クラスター管理者が management console にログインできない

LDAP 接続のセットアップ後に、クラスター管理者資格情報 username/password: admin/admin を使⽤してIBM® Cloud Private クラスター management console にログインできません。

原因

LDAP 接続の構成中に指定した LDAP パラメーターが正しくない可能性があります。

問題の解決

現⾏ LDAP 構成を削除します。

LDAP 構成は、platform-auth コンテナー内の /config/configDropins/defaults/ldap-<LDAP_connection_name>.xml ファイルに保管されています。誤った LDAP 構成を削除するには、このファイルを削除するか、別の場所に移動する必要があります。その後、console にログインし、正しいパラメーターを使⽤して LDAP 接続を再度セットアップできます。

現⾏ LDAP 構成を削除するには、マスター・ノードで root 権限を使⽤して以下のコマンドを実⾏します。

1. platform-auth コンテナー ID を取得します。

docker ps | grep platform-auth


root@master:/opt/icp/cluster# docker ps | grep platform-auth d588a5b951b4 ibmcom/icp-platform-auth "/usr/bin/superv is..." 5 days ago Up 5 days k8s_platfor m-auth-service_auth-idp-ln0s6_kube-system_d5f4fe3c-c60e-11e7-8ea2-005056a85e40_0

2. コンテナー内部のシェルにアクセスします。

docker exec -it <container ID> /bin/bash



root@master:/opt/icp/cluster# docker exec -it d588a5b951b4 /bin/bash bash-4.3#

3. /config/configDropins/defaults/ ディレクトリーに配置されている LDAP 設定ファイル名を書き留めます。例えば、LDAP 接続名が openLDAP の場合、ファイル名は ldap-openLDAP.xml です。

4. LDAP 設定ファイルを /config/configDropins/defaults/ ディレクトリーの外に移動します。例えば、以下のコマンドで、ファイルを /config/configDropins/ ディレクトリーに移動できます。

mv /config/configDropins/defaults/ldap-<LDAP_connection_name>.xml /config/configDropins/

注:ファイルを移動する代わりに、/config/configDropins/defaults/ ディレクトリーから LDAP 設定ファイルを削除することもできます。ただし、ファイルを移動した場合は、構成ファイルのバックアップを保持しておくことになるため、トラブルシューティングで使⽤できます。また、ファイル内の設定を修正し、LDAP 接続をセットアップするためにそれを再使⽤することができます。ファイルを再使⽤する場合は、修正したファイルを /config/configDropins/defaults/ ディレクトリーに戻す必要があります。

5. しばらく待機してから、クラスター管理者としてログインします。

6. 正しい構成パラメーターを指定して LDAP 接続をセットアップします。 LDAP 接続のセットアップについて詳しくは、『LDAP 接続の構成』を参照してください。

管理コンソール

頻繁に発⽣する management console の問題についてご確認ください。

(マスター・ノードの再始動後に) management console にアクセスできない Helm チャートの README ファイルがカタログに表⽰されない計量ダッシュボードにアクセスできない脆弱性アドバイザー・レポートを表⽰できない

management console にアクセスできない (マスター・ノードの再始動後)

マスター・ノードの再始動後に、management console にアクセスできません。

症状

マスター・ノードの再始動後に management console を表⽰できません。

原因

必須ポートにアクセスできなくなった可能性があります。

問題の解決

すべてのデフォルト・ポートが開いていて、使⽤可能であることを確認してください。デフォルト・ポートのリストについては、デフォルト・ポート (Default ports)を参照してください。


脆弱性アドバイザー・レポートを表⽰できない

脆弱性アドバイザー (VA) レポートがコンソールから表⽰されません。

問題の解決

1. kubectl CLI をセットアップします。 management consoleを使⽤して IBM® Cloud Private クラスターにアクセスするを参照してください。

2. sas-api を停⽌して、replica 値を 0 に更新します。

kubectl edit deployment sas-api-server --namespace=kube-system

更新後にポッドが正常に再始動することを確認してください。

kubectl --namespace=kube-system get pods |grep sas-api

3. VA Elasticsearch IP アドレスを検索します。次のコマンドを実⾏します。

kubectl get pods -o wide --namespace=kube-system |grep va-elastic


va-elasticsearch-0 1/1 Running 3 5h 10.1.27.151 9.21.53.20

この例では、VA Elasticsearch IP アドレスは 10.1.27.151 です。

4. sas_info インデックスを削除します。

curl -k -s -XDELETE http://<VA elasticsearch IP>:9200/sas_info

5. sas-api を再デプロイして、replica を 1 に更新します。

kubectl edit deployment sas-api-server --namespace=kube-system

更新後にポッドが正常に再始動することを確認してください。

kubectl --namespace=kube-system get pods |grep sas-api

6. レジストリー・クローラーからフレームを送信します。

例:

docker push mycluster.icp:8500/default/nginx:1.13.1 docker push mycluster.icp:8500/default/tomcat:9.0

7. ブラウザーのデータを消去します。

8. IBM Cloud Private management console にログインします。 management console を使⽤した IBM CloudPrivate クラスターへのアクセスを参照してください。 VA は認証 Cookie へのアクセス権限が必要です。

9. ブラウザーで新しいタブを開きます。10. 新しいタブから、https://<master_ip>:8443/va/ui/list を開きます。11. ナビゲーション・バーから「選択」をクリックし、va-auth.json ファイルを指定します。12. ポリシー名を選択します。13. ナビゲーション・バーから「ポリシーの管理」をクリックします。「デフォルト・ポリシー (Default

Policy)」表で verdict:package_vulnerability_found オプションを選択します。14. 「ポリシーの送信」をクリックします。

これで、指定した名前空間内のコンテナーおよびイメージに関する脆弱性レポートを表⽰できるようになります。


ネットワーク

よくあるネットワークの問題について検討します。

Calico ネットワークのトラブルシューティング

Calico ネットワークのトラブルシューティング

Calico ネットワークに関する問題を特定し、調査します。

Calico ネットワークに関する問題は通常、ポッド間の接続性の問題として現れます。ポッド間の接続性の問題が発⽣した場合、以下のいずれかのシナリオに注意してください。

Heapster サービスまたは kube-dns サービスが Kubernetes サービス・エンドポイントと通信できない。ポッドが DNS を使⽤してホスト名を正常に解決できない。Helm デプロイメントは正しく実⾏されているが、management console 内の Catalog ページが正しく表⽰されない。

calicoctl を使⽤して Calico ネットワークの構成をチェックすることができます。 calicoctl は、https://github.com/projectcalico/calicoctl/releases からダウンロードできます。{: new_window} また、IBM®Cloud Private のインストール・メディアからコピーすることも可能です。

クラスター内のネットワーキングに関する問題を診断する際は、以下の⼿順を⾏って確認することもできます。

1. Kubernetes CLI および Calico CLI を確実にセットアップします。IBM Cloud Private のインストール・メディアから⼊⼿可能な calicoctl バイナリー・ファイルをセットアップするには、Calico CLI のセットアップを参照してください。Kubernetes CLI (kubectl) をセットアップするには、kubectl CLI を使⽤した IBM Cloud Private クラスターへのアクセスを参照してください。

2. etcdv2 データ・ストアを使⽤するよう calicoctl を構成します。ブート・ノードの config.yaml ファイル内にある同じ cluster_name を使⽤してください。

証明書ファイルをエクスポートします。

export ETCD_CERT_FILE=/etc/cfc/conf/etcd/client.pem

CA 証明書ファイルをエクスポートします。

export ETCD_CA_CERT_FILE=/etc/cfc/conf/etcd/ca.pem

鍵ファイルをエクスポートします。

export ETCD_KEY_FILE=/etc/cfc/conf/etcd/client-key.pem

CA ドメインをエクスポートします。

export ETCD_ENDPOINTS=https://<cluster_CA_domain>:4001

ここで <cluster_CA_domain> は、インストール時に config.yaml ファイルに設定された認証局(CA) ドメインです。

3. ポリシー・コントローラーが実⾏中であるか確認します。ポリシー・コントローラーが実⾏中でない場合、ポッドは相互に通信することができません。ポリシー・コントローラーが実⾏中かどうか確認するには、以下のコマンドを実⾏します。

kubectl get pod --namespace=kube-system | grep policy-controller


https://github.com/projectcalico/calicoctl/releases

ポリシー・コントローラーが実⾏中でない場合、Kubernetes がまだポリシー・コントローラー・イメージをプルしようとしている可能性があります。

4. それぞれの名前空間のプロファイルがポリシー・コントローラーによって作成されたか確認してください。次のコマンドを実⾏します。

export ETCD_ENDPOINTS=http://<cluster_CA_domain>:4001 calicoctl get profile

get profile コマンドは 2 つ以上のプロファイルを返します。

k8s_ns.default k8s_ns.kube-system

これらのプロファイルが表⽰されない場合、Calico ポリシー・コントローラーが正常に実⾏されていないということです。問題を特定するために、Calico ポリシー・コントローラーのログを確認してください。

5. すべてのマスター・ホストおよびワーカー・ホストが同じサブネット上にあるか、または、ホストが同じサブネット上にあるけれど OpenStack などのクラウド環境にあるかを確認します。

ホストが同じサブネット上にないか、またはクラウド環境にある場合、以下の⼿順を実⾏します。

a. config.yaml ファイルで calico_ipip_enabled が true に設定されていることを確認します。 b. クラスターを再インストールします。

ストレージ

よくあるストレージの問題について検討します。

システム再始動後に GlusterFS デバイスが⾒つからない GlusterFS ノードの異常終了 IBM® Cloud Private の再インストールでは GlusterFS 問題が解決しない PersistentVolumeClaim を作成できないワーカー・ノードの同時再始動により GlusterFS に障害が発⽣するパーシスタント・ボリュームまたはパーシスタント・ボリューム・クレームを作成または削除できない GlusterFS ノードの状況に「Peer Rejected」と表⽰される GlusterFS パーシスタント・ボリューム・クレームを削除するとパーシスタント・ボリューム状況に「Failed」と表⽰される場合がある

システム再始動後に GlusterFS デバイスが⾒つからない

GlusterFS ボリュームを作成するために取り付けたデバイスが検出できません。

症状

GlusterFS は、正しいデバイスが取り付けられていることを検出できないと不安定になります。

原因

システム再始動時に、デバイス名が変更された可能性があります。

問題の解決

デバイスのシンボリック・リンク (symlink) をデバイス ID として使⽤します。


GlusterFS クラスターを再作成します。 GlusterFS ストレージの構成の説明に従ってください。

IBM® Cloud Private を再インストールします。

GlusterFS ノードの異常終了

GlusterFS クラスターの⼀部であるワーカー・ノードが異常終了した可能性があります。

GlusterFS クラスターに新規のノードを追加することができます。詳細については、GlusterFS クラスターのストレージ容量の増加 (Increasing the storage capacity of a GlusterFS cluster) を参照してください。

IBM® Cloud Private の再インストールでは GlusterFS 問題が解決しない

IBM Cloud Private の再インストールでは GlusterFS デバイスの問題は解決しません。

問題の特定

ご使⽤の環境に関する情報を集め、問題の原因を特定します。

1. ログを収集できるように、詳細オプションを指定してインストール・コマンドを実⾏します。

Standard Edition:

docker run -e LICENSE=accept --net=host -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3-ee install -vvv

Community Edition:

docker run -e LICENSE=accept --net=host -v "$(pwd)":/installer/cluster ibmcom/icp-inception:2.1.0.3 install -vvv

2. <installation directory> から以下のコマンドを実⾏して、kubectl を構成します。

#!/bin/bash docker run -e LICENSE=accept --net=host \ -v /usr/local/bin:/data ibmcom/kubernetes:v1.7.3 cp /kubectl /data set -e mkdir -p ~/.kube sudo cp cluster/cfc-certs/kubecfg.* ~/.kube/ sudo chown -R $USER:$USER ~/.kube/ kubectl config set-cluster cfc-cluster --server=https://mycluster.icp:8001 --insecure-skip-tls-verify=true kubectl config set-context kubectl --cluster=cfc-cluster kubectl config set-credentials user --client-certificate=$HOME/.kube/kubecfg.crt --client-key=$HOME/.kube/kubecfg.key kubectl config set-context kubectl --user=user kubectl config use-context kubectl

3. GlusterFS および Heketi に関連するポッドを検索します。

kubectl -n kube-system get po | grep -E 'gluster|heketi'


4. GlusterFS および Heketi に関連する各ポッドのログを取得します。実⾏中の GlusterFS ポッドと Heketi ポッドを識別します。

kubectl -n kube-system logs glusterfs-<pod name/ID> kubectl -n kube-system logs heketi-<pod name/ID> > heketi.txt kubectl -n kube-system exec glusterfs-<pod name/ID> -- cat /var/log/glusterfs/glusterd.log

5. 実⾏中の GlusterFS ポッドのボリュームの状態を検索します。

kubectl -n kube-system exec glusterfs-<pod name/ID> -- gluster volume status

6. 実⾏中の Heketi ポッドのトポロジーの状態を検索します。

kubectl -n kube-system exec heketi-<pod name/ID> -- heketi-cli topology info

7. 次の問題を解決します。

GlusterFS ログがデバイスへのアクセスに関する問題を⽰している場合は、ホストでのパスが正しく、正しいアクセス権が有効になっていることを確認します。 ls -l コマンドを使⽤して、デバイス・ファイルが存在し、アクセス可能であることを確認します。

デバイスが破損している場合、または GlusterFS がブリックをロードできない場合は、GlusterFS でデバイス・マッピングを置き換えます。

Heketi トポロジーの状況が、GlusterFS ボリュームが正しく初期化されていないことを⽰している場合は、デバイスを置き換えます。 Heketi を初期化するには、デバイスをフォーマット設定してはなりません。 GlusterFS ストレージの構成の説明に従って、config.yaml ファイルを更新します。

8. IBM Cloud Private をアンインストールします。アンインストール (Uninstalling) を参照してださい。9. IBM Cloud Private をインストールします。インストール (Installing) を参照してください。

GlusterFS PersistentVolumeClaim を作成できない

GlusterFS PersistentVolumeClaim (PVC) を作成できません。

原因

PVC の名前が⻑すぎます。 PVC の名前の⻑さが 63 ⽂字を超えると、PVC サービス・エンドポイントをバインドすることができません。 GlusterFS は、サービス・エンドポイント名を作成する際に glusterfs-dynamic を PVC の名前に付加します。これらの追加の⽂字によって PVC の名前が限界の⻑さを超える場合があります。

例えば、volumeClaimTemplates を使⽤して StatefulSet 内に PVC を作成する場合、⾃動的に作成される PVC の名前は次のようになります。<pvc name>-<statefulset name>-<ordinal> 例えば、PVC と StatefulSet の両⽅が default-mq-stocktrader-m という名前である場合、PVC の新しい名前は default-mq-stocktrader-m-default-mq-stocktrader-m-0 となる可能性があります。 GlusterFS を使⽤してこの PVC を作成する場合、サービス・エンドポイントを作成するために glusterfs-dynamic- という接頭部が PVC の名前に付加されます。サービス・エンドポイント名 glusterfs-dynamic-default-mq-stocktrader-m-default-mq-stocktrader-m-0は 63 ⽂字を超えているため、PVC のバインドは失敗します。

PVC を作成する際、Status: Pending が表⽰される場合があります。また、コマンド出⼒の Events: セクションに以下のようなメッセージが表⽰される可能性もあります。

Service "glusterfs-dynamic-default-mq-stocktrader-m-default-mq-stocktrader-m-0" is invalid: \ metadata.name: Invalid value: \ "glusterfs-dynamic-default-mq-stocktrader-m-default-mq-stocktrader-m-0": \ must be no more than 63 characters

問題の解決


GlusterFS を使⽤する場合は、PVC の名前を 45 ⽂字までに制限してください。 StatefulSets で volumeClaimTemplates を使⽤する場合、StatefulSet の名前と PVC の名前の両⽅に短い名前を使⽤します。

PVC のバインディングが失敗する場合は、StatefulSet の名前または PVC の名前を短くして、GlusterFS サービス・エンドポイント glusterfs-dynamic-<pvc name>-<statefulset name>-<ordinal> の全体の⻑さが 63 ⽂字を超えないようにしてください。

この問題について詳しくは、Kubernetes コミュニティー内の『glusterfs create pvc failed 』の問題を参照してください。

ワーカー・ノードの同時再始動により GlusterFS に障害が発⽣する

すべてのワーカー・ノードを同時に再始動すると、GlusterFS が始動しません。

原因

ワーカー・ノードの同時再始動により、Heketi ポッドが始動しません。 heketidbstorage ボリュームをマウントできないため、Heketi コンテナーは始動に失敗します。 heketidbstorage の状況は、正常でないシャットダウンにより、対応するブリックがオンラインではないため、オフラインを⽰しています。

問題の解決

次のコマンドを実⾏して、GlusterFS ポッド情報を取得します。

kubectl -n kube-system get pod | grep gluster

以下はコマンド出⼒の例です。

glusterfs-36nd0 1/1 Running 4 7d glusterfs-3m5ql 1/1 Running 3 7d glusterfs-tc279 1/1 Running 16 7d

すべての GlusterFS ポッドに対して以下の⼿順を実⾏します。

1. GlusterFS ポッドにログインします。

kubectl -n kube-system exec -it <POD ID> bash

以下は、コマンドと出⼒の例です。

root@BPILICPMSTR001:~/cluster# kubectl -n kube-system exec -it glusterfs-36nd0 bash [root@bpilicpwrk001 /]#

2. ポッド上の GlusterFS ボリュームの状況を確認します。

gluster volume status

以下は、コマンドと出⼒の例です。

[root@bpilicpwrk001 /]# gluster volume status Status of volume: heketidbstorage Gluster process TCP Port RDMA Port Online Pid Brick 10.10.25.49:/var/lib/heketi/mounts/vg _22bbf0fbb483f9c170774d83081c3420/brick_2fb 3a10c7eafb8bed375829e8aaf782a/brick 49153 0 Y 5858 Brick 10.10.25.51:/var/lib/heketi/mounts/vg _118f22bc13626321606280ea1d79fdc3/brick_649



4a3b077c38667f07a59197efabea7/brick 49153 0 Y 5318 Brick 10.10.25.50:/var/lib/heketi/mounts/vg _d4d4f2e86c08f571befe7fc272dc4aae/brick_dc9 416bf4d88e45ff4d0061c08ef5b19/brick 49153 0 Y 5441 Self-heal Daemon on localhost N/A N/A Y 5878 Self-heal Daemon on 10.10.25.50 N/A N/A Y 5461 Self-heal Daemon on 10.10.25.51 N/A N/A Y 5338 Task Status of Volume heketidbstorage There are no active volume tasks [root@bpilicpwrk001 /]#

heketidbstorage に対応するブリックがダウンしている場合は、以下のコマンドを実⾏してブリックを再始動します。

gluster volume stop heketidbstorage

gluster volume start heketidbstorage force

3. Heketi ポッドの状況を確認します。

kubectl -n kube-system get pod | grep heketi

状況には、以下のようなメッセージが表⽰されます。

heketi-402978595-pjnd7 1/1 Running 0 2h

パーシスタント・ボリュームまたはパーシスタント・ボリューム・ク

レームを作成または削除できない

PersistentVolume (PV) または PersistentVolumeClaim (PVC) を作成または削除できません。

GlusterFS ストレージを使⽤している場合、PV または PVC を作成または削除しようとすると、「データベースは読み取り専用モードです (database is in read-only mode)」というメッセージが表⽰されることがあります。

原因

Heketi ポッドを再始動した場合は、ポッドが Heketi データベース・ファイルへの write 権限を付与されませんでした。

GlusterFS クラスター・ノードがダウンしています。

問題の解決

問題を解決するには、以下のステップを実⾏します。

1. すべての GlusterFS クラスター・ノードが稼働中であることを確認します。2. kubectl CLI がセットアップされていることを確認します。 kubectl CLI を使⽤した IBM® Cloud Private クラスターへのアクセスを参照してください。

3. Heketi サービス・デプロイメント・ポッド名を取得します。





4. Heketi デプロイメントを 0 に縮⼩します。

a. Heketi デプロイメントの構成ファイルを開きます。

kubectl -n kube-system edit deployments <name of the Heketi service deployment pod>.


# Please edit the object below. Lines beginning with a '#' will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file will be # reopened with the relevant failures. # apiVersion: extensions/v1beta1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: "1" description: Defines how to deploy Heketi kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"extensions/v1beta1","kind":"Deployment","metadata":{"annotations":{"description":"Defines how to deploy Heketi"},"labels":{"glusterfs":"heketi-deployment"},"name":"heketi","namespace":"kube-system"},"spec":{"replicas":1,"template": {"metadata":{"labels":{"glusterfs":"heketi-pod"},"name":"heketi"},"spec":{"containers":[{"env": [{"name":"HEKETI_EXECUTOR","value":"kubernetes"},{"name":"HEKETI_FSTAB","value":"/var/lib/heketi/fstab"},{"name":"HEKETI_SNAPSHOT_LIMIT","value":"14"},{"name":"HEKETI_KUBE_GLUSTER_DAEMONSET","value":"y"},{"name":"HEKETI_ADMIN_KEY","valueFrom":{"secretKeyRef":{"key":"admin_password","name":"heketi-secret"}}}],"image":"ibmcom/heketi:5","imagePullPolicy":"IfNotPresent","livenessProbe":{"httpGet":{"path":"/hello","port":8080},"initialDelaySeconds":30,"timeoutSeconds":3},"name":"heketi","ports":[{"containerPort":8080}],"readinessProbe": {"httpGet":{"path":"/hello","port":8080},"initialDelaySeconds":3,"timeoutSeconds":3},"volumeMounts":[{"mountPath":"/var/lib/heketi","name":"db"}]}],"nodeSelector":{"beta.kubernetes.io/arch":"amd64"},"serviceAccountName":"default","volumes":[{"glusterfs":{"endpoints":"heketi-storage-endpoints","path":"heketidbstorage"},"name":"db"}]}}}} creationTimestamp: 2018-02-13T16:15:14Z generation: 3 labels: glusterfs: heketi-deployment name: heketi namespace: kube-system resourceVersion: "91880" selfLink: /apis/extensions/v1beta1/namespaces/kube-system/deployments/heketi uid: 129bb2b3-10d9-11e8-a889-00163e01ce72 spec: replicas: 1 selector: matchLabels: glusterfs: heketi-pod strategy: rollingUpdate:

b. replicas: 1 を replicas: 0 に変更することで、インスタンスの数をゼロに縮⼩します。構成を保存します。

c. 変更を適⽤します。

kubectl -n kube-system rollout status deployments <name of the Heketi service deployment pod>


デプロイメントが正常にロールアウトされると、出⼒は以下のようなコードになります。

deployment "heketi" successfully rolled out

d. ポッドが終了するまで待ちます。次のコマンドを実⾏して、ポッドの状況を表⽰します。

kubectl -n kube-system get pods | grep heketi

ポッドが正常に終了した場合、コマンドは出⼒を返しません。

5. Heketi デプロイメントを拡⼤します。

a. Heketi デプロイメントの構成ファイルを開きます。

kubectl -n kube-system edit deployments <name of the Heketi service deployment pod>.

b. replicas: 0 を replicas: 1 に変更することで、インスタンスの数を増⼤します。構成を保存します。

c. 変更を適⽤します。

kubectl -n kube-system rollout status deployments <name of the Heketi service deployment pod>

デプロイメントが正常にロールアウトされると、出⼒は以下のようなコードになります。

deployment "heketi" successfully rolled out

d. ポッドが開始するまで待ちます。次のコマンドを実⾏して、ポッドの状況を表⽰します。

kubectl -n kube-system get pods | grep heketi

ポッドが開始されると、出⼒は以下のようなコードになります。

heketi-68549fdf65-sm8tl 1/1 Running 0 23s

GlusterFS ノードの状況に「Peer Rejected」と表⽰される

GlusterFS ノードの状況に「Peer Rejected」と表⽰される場合があります。

注: 複数のノードが「Peer Rejected」状態である場合、GlusterFS ノードを復旧できないことがあります。再度、GlusterFS クラスターのセットアップが必要になる場合があります。

問題の解決


2. GlusterFS ポッドの状況を確認します。

kubectl -n kube-system get pods -o wide | grep gluster


glusterfs-l95bp 1/1 Running 3 6d 192.168.0.184 worker-2 glusterfs-n85vr 1/1 Running 0 4d 192.168.0.56 worker-1 glusterfs-p66jq 1/1 Running 3 6d 192.168.0.96 worker-3


3. 任意の GlusterFS ポッドからピアの状況を確認します。

kubectl -n kube-system exec <pod name> -- gluster peer status


kubectl -n kube-system exec glusterfs-l95bp -- gluster peer status Number of Peers: 2 Hostname: 192.168.0.96 Uuid: 3e518a43-b59f-45e7-a62c-5b213e0fece8 State: Peer in Cluster (Connected) Other names: 192.168.0.96 Hostname: worker-1 Uuid: c2a81937-e94f-4a22-86e7-bc9c8929c2d3 State: Peer Rejected (Connected)

「Peer Rejected」状況が表⽰された場合、そのピアのボリューム構成が、クラスター内の残りのピアと同期されていないことを意味します。

GlusterFS クラスターと同期化するには、「Peer Rejected」状態の GlusterFS ノードで以下のステップを実⾏します。

1. GlusterFS ポッド内でシェルにアクセスします。

kubectl -n kube-system exec -it <pod name> bash

2. /var/lib/glusterd ディレクトリーに変更します。

cd /var/lib/glusterd

フォルダーには以下のファイルとフォルダーが含まれる可能性があります。

. .. bitd geo-replication glusterd.info glusterfind glustershd groups hooks nfs options peers quotad scrub snaps ss_brick vols

3. glusterd.info (これは汎⽤固有 ID (UUID) ファイルです) を除いて、すべてを削除します。

4. Gluster デーモンを再始動します。

service glusterd restart

5. 「Peer Rejected」状態でないピアを調べます。

gluster peer probe <node name>

6. ピアの状況を確認します。

gluster peer status

注: 「Peer Rejected」状況が表⽰されなくなるまで、上記のステップを繰り返す必要がある場合があります。

GlusterFS パーシスタント・ボリューム・クレームを削除するとパーシスタント・ボリューム状況に「Failed」と表⽰される場合がある

GlusterFS PersistentVolume (PV) にバインドされた PersistentVolumeClaim (PVC) を削除すると、GlusterFS PV の状況に「Failed」と表⽰されます。

以下のコマンドと出⼒の例を参照してください。


続⾏する前に、kubectl CLI をセットアップします。 kubectl CLI を使⽤した IBM® Cloud Private クラスターへのアクセスを参照してください。

1. すべての PVC のリストを取得します。

kubectl get pvc


NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE gfs-endpoint-test Bound pvc-812dd5df-575f-11e8-9b8b-005056a8640c 1Gi RWO gluster 22h noreplica-pvc-gluster Bound pvc-08f87fa7-542f-11e8-89ac-005056a8640c 1Gi RWO gluster-no-replica 5d test-pvc-gluster-r2-1 Bound pvc-7ab00b20-5394-11e8-89ac-005056a8640c 1Gi RWO gluster-replica2 5d

2. PVC を削除します。

kubectl delete pvc <PVC name>


kubectl delete pvc noreplica-pvc-gluster persistentvolumeclaim "my-release-grafana" deleted

3. PVC の状況を確認します。

kubectl get pvc

出⼒は、以下のコードのようになります。 PVC は、正常に削除されました。

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE gfs-endpoint-test Bound pvc-812dd5df-575f-11e8-9b8b-005056a8640c 1Gi RWO gluster 22h test-pvc-gluster-r2-1 Bound pvc-7ab00b20-5394-11e8-89ac-005056a8640c 1Gi RWO gluster-replica2 5d

4. PV の状況を確認します。削除された PVC がバインドされていた先の PV の状況に「Failed」が表⽰される可能性があります。

kubectl get pv


NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-08f87fa7-542f-11e8-89ac-005056a8640c 1Gi RWO Delete Failed default/noreplica-pvc-gluster gluster-no-replica 5d pvc-7ab00b20-5394-11e8-89ac-005056a8640c 1Gi RWO Delete Bound default/test-pvc-gluster-r2-1 gluster-replica2 5d pvc-812dd5df-575f-11e8-9b8b-005056a8640c 1Gi RWO Delete Bound default/gfs-endpoint-test gluster 22h

原因

GlusterFS ノードがダウンしているか、⼀部の GlusterFS ポッドが実⾏状態でありません。


問題の解決

1. すべての GlusterFS ノードが実⾏中で、IBM Cloud Private クラスターに登録されているかどうかを確認します。

kubectl get nodes


NAME STATUS ROLES AGE VERSION master Ready <none> 5d v1.10.0+icp-ee worker-1 Ready <none> 5d v1.10.0+icp-ee worker-2 Ready <none> 5d v1.10.0+icp-ee worker-3 Ready <none> 5d v1.10.0+icp-ee

2. すべての GlusterFS ポッドの状況に「Running」が表⽰されることを確認します。また、ポッドの数が、構成した GlusterFS ノードの数と同じかどうかを確認します。

kubectl -n kube-system get pods | grep gluster


glusterfs-l95bp 1/1 Running 1 5d glusterfs-n85vr 1/1 Running 0 3d glusterfs-p66jq 1/1 Running 3 5d

ノードとポッドの数が⼀致しない場合、ノードのラベルを確認してください。すべての GlusterFS ノードに storagenode=glusterfs ラベルが必要です。

kubectl get nodes --show-labels


NAME STATUS ROLES AGE VERSION LABELS master Ready <none> 6d v1.10.0+icp-ee beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,etcd=true,gpu/nvidia=NA,kubernetes.io/hostname=master,management=true,master=true,proxy=true,role=master worker-1 Ready <none> 6d v1.10.0+icp-ee beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,gpu/nvidia=NA,kubernetes.io/hostname=worker-1,storagenode=glusterfs worker-2 Ready <none> 6d v1.10.0+icp-ee beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,gpu/nvidia=NA,kubernetes.io/hostname=worker-2,storagenode=glusterfs worker-3 Ready <none> 6d v1.10.0+icp-ee beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,gpu/nvidia=NA,kubernetes.io/hostname=worker-3,storagenode=glusterfs

3. storagenode=glusterfs ラベルを持たないすべての GlusterFS ノードに対し、ラベルを追加します。

kubectl label nodes <node name> storagenode=glusterfs

4. GlusterFS および Heketi のポッドの状況を確認します。

kubectl -n kube-system get pods | egrep "gluster|heketi"


glusterfs-l95bp 1/1 Running 1 5d glusterfs-n85vr 1/1 Running 0 3d glusterfs-p66jq 1/1 Running 3 5d heketi-9f984d759-zcmvb 1/1 Running 0 4d


5. すべてのポッドの状況が「Running」と表⽰されるようになったら、「Failed」と表⽰されていた PV の状況を確認します。注: 再利⽤ポリシーが「Delete」だった場合、PV は削除されます。そうでなければ、PV の状況は「Released」と表⽰されます。

kubectl get pv


NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-7ab00b20-5394-11e8-89ac-005056a8640c 1Gi RWO Delete Bound default/test-pvc-gluster-r2-1 gluster-replica2 5d pvc-812dd5df-575f-11e8-9b8b-005056a8640c 1Gi RWO Delete Bound default/gfs-endpoint-test gluster 22h

イベントおよびログ

頻繁に発⽣するイベントおよびログに関する問題についてご確認ください。

イベントおよびログ (CLI) イベントおよびログ (クラスター management console) Elasticsearch のログ・データがクリーンアップされていない

イベントとログ (CLI)

クラスターのトラブルシューティングを助けるためには、コンポーネント・ログを検討します。

Docker ログ

コンテナーの状況を確認するには、マスター・ノードかワーカー・ノードで以下を実⾏します。

docker ps -a

これにより、ノードで実⾏されているすべてのコンテナーに関する情報が返されます。

実⾏中のコンテナーの終了状況を確認するには、次のコマンドを実⾏します。

docker logs container-id

ワーカー・ログ

Kubernetes ワーカー・ログを表⽰するには、ワーカー・ノードで次のコマンドを実⾏します。

systemctl status kubelet

Kubernetes ワーカー・ログでの詳細を表⽰するには、ワーカー・ノードで次のコマンドを実⾏します。

journalctl -u kubelet.service

Calico ログを表⽰するには、ワーカー・ノードで次のコマンドを実⾏します。

docker logs -f calico


イベントおよびログ (クラスター management console)

クラスター management console を使⽤して、デプロイメントのイベントとログにアクセスします。

クラスター management console からアクセス可能な以下のイベントおよびログを、デプロイメントや操作に関する問題をトラブルシューティングするためのツールとして使⽤できます。

デプロイメント・イベント

デプロイメント・イベントにはデプロイメントやデプロイメント⽤のその他のイベントの詳細が含まれています。

特定のデプロイメント⽤のデプロイメント・イベントを確認するには、以下の⼿順を実⾏します。

1. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」をクリックします。2. 表⽰したいデプロイメントを選択します。3. 「イベント」タブをクリックします。検索機能を使⽤すると、キーワード・ベースで素早く照会を⾏うことができます。

デプロイメント・ログ

デプロイメント・ログをチェックする前に、デプロイメント内のすべてのポッドが実⾏中の状態になっていることを

確認してください。そうでない場合、なぜポッドが稼働中でないのか調べるために、ログを確認する必要があるかもしれません。

特定のデプロイメントのデプロイメント・ログを確認するには、以下の⼿順を実⾏します。

1. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」をクリックします。2. 表⽰したいデプロイメントを選択します。3. 「ログ」タブをクリックします。ここから、確認したいポッドとコンテナーを選択できます。検索機能を使⽤すると、キーワード・ベースで素早く照会を⾏うことができます。

ReplicaSet イベント

ReplicaSets は、クラスター内で実⾏中のレプリカまたはポッドを維持するために使⽤します。

特定のデプロイメント⽤の ReplicaSet イベントを確認するには、以下の⼿順を実⾏します。

1. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」をクリックします。2. 表⽰したいデプロイメントを選択します。3. replicaSet の詳細を確認します。

ポッド・イベント

ポッドは、クラスター内で作成される、デプロイ可能な基本ユニットです。単⼀のポッドに 1 つ以上のコンテナーが含まれている可能性があります。

特定のデプロイメント⽤のポッド・イベントを確認するには、以下の⼿順を実⾏します。

1. ナビゲーション・メニューから、「ワークロード」 > 「デプロイメント」をクリックします。2. 表⽰したいデプロイメントを選択します。3. 表⽰したいポッドを選択します。4. 「イベント」タブをクリックします。キーワード・ベースで素早く照会を⾏える検索ボックスも使⽤できます。


Elasticsearch のログ・データがクリーンアップされていない

クラスター・ログ (Logstash) およびメトリック (Heapster) の Elasticsearch インデックス・データが管理ノードから削除されていません。

症状

/opt/ibm/cfc/logging/elasticsearch フォルダー内に保管されているクラスター・ログおよびメトリックのデータは過度のディスク・スペースを消費します。

原因

デフォルトで、ログとメトリックは 1 ⽇ごとに保管されます。ログをクリーンアップするために、クーロン・ジョブが毎⽇ 23:59 に実⾏されます。その時にコンピューターが中断状態にあると、ログが累積される可能性があります。

管理ノードが Red Hat Enterprise Linux を使⽤している場合、誤った構成の Docker ストレージ・ドライバーによりクーロン・ジョブの⾃動実⾏が邪魔される場合があります。この構成が、ログが累積される原因となる可能性があります。

また、ご使⽤のコンテナーが⼤量のログまたはメトリック・データを⽣成する場合、管理ノードのストレージ容量が

⼩さすぎるケースや、デフォルトのログおよびメトリックの保管の間隔が⻑すぎるケースが考えられます。

問題の解決

管理ノードが Red Hat Enterprise Linux を使⽤している場合、Docker ストレージ・ドライバーが正しく構成されていることを確認します。ストレージ・ドライバーは、IBM® Cloud Private をインストールする前に構成する必要があります。

Docker の⼿動インストールについては、Docker エンジンの構成を参照してください。Docker の⾃動インストールについては、Docker 設定を参照してください。

ご使⽤のコンテナーが⼤量のログまたはメトリック・データを⽣成する場合、管理ノードのストレージ容量を増やす

か、IBM Cloud Private のロギングページのキュレーターのカスタマイズセクションの説明に従って、デフォルトのログおよびメトリックのキュレーター基準を変更してください。

Windows で CLI を使⽤して kubectl を認証できない

IBM Cloud Private コマンド・ラインを使⽤して IBM® Cloud Private クラスターを kubectl コマンド・ラインに接続すると Windows で障害が発⽣します。

症状

bx pr cluster-config mycluster コマンドを実⾏して kubectl をクラスターに接続すると、次のエラーが表⽰されます。

Unable to rename file to bat extension: C:\Users\<your_account>`\.bluemix\plugins\icp\clusters\mycluster/kube-config

ここで <your_account> はご使⽤の Windows アカウントの名前です。

原因


コマンドが .bat ファイルにダウンロードする kube-config ファイルを、Windows が正しく変換できません。

問題の解決

1. ファイル名を C:\Users\<your_account>\.bluemix\plugins\icp\clusters\mycluster/kube-config から C:\Users\<your_account>\.bluemix\plugins\icp\clusters\mycluster/kube-config.bat に変更します。

2. C:\Users\<your_account>\.bluemix\plugins\icp\clusters\mycluster/kube-config.bat ファイルを実⾏します。クラスターに対して kubectl コマンドを実⾏することができます。

API

API を使⽤して、IBM® Cloud Private クラスターにアクセスしたり、クラスターを変更したりします。

コンポーネント API コマンドまたは管理 API コマンドを実⾏するための準備コンポーネント API ユーザー管理および認証 API イメージ管理 API 脆弱性アドバイザー API

コンポーネント API コマンドまたは管理 API コマンドを実⾏するための準備

コンポーネント API コマンドを実⾏する前に、認証トークンを取得し、クラスターの CA 証明書をダウンロードします。

1. Kubernetes コマンド・ライン (kubectl) をインストールします。 kubectl CLI を使⽤した IBM® Cloud Privateクラスターへのアクセスを参照してください。

2. (オプション) IBM Cloud Private コマンド・ライン・インターフェース (CLI) をインストールし、クラスターにログインします。『IBM Cloud Private CLI のインストール』を参照してください。

3. 認証トークンを取得します。 IBM Cloud Private CLI を使⽤するか、curl コマンドを実⾏できます。

IBM Cloud Private CLI を使⽤するため、以下のコマンドを実⾏します。

bx pr tokens

以下のようにアクセス・トークンおよび ID トークンが表⽰されます。

Access token: Bearer jHVcaGjSuWEXGUPeH8WVnoqUyex5kJDlCl4DnZMQN2WseErIoVWDW5cY1Ikvoqdhxkou4bvHYJM77U2FZf2aKbo3h2FeH1OJpaEwj8rpGiDLusaXc54rJbnefbjAv4OECvk2tg9gIeJAx6DZlmlknDXB6zM0bkGtqayP94L8gSXtzPoW6miuoR8dFD5Du63OjVBVZljw5ajOWBtvYzR1ttamH4SRMflEVWC3AxcBhtkadMCAsdWFi1KRGUoVM5k0TkuPFP7AAX8vryEpakeVqBQfbR2m0OlRBTRbkNJoacPp7AesyGLBjPVElQs01FCz3xhMNHkQJAFT0T0xhbhDj3DgenAjJd5eSNWxdTLSfhOaQClfx6BLq5Z0e8S0Uhp2NSWqNVkU49fHuTHW2UwxG84nvwpz4ZxYJaP3m6DZv5lTwKcbQkB3w9cLr8pgUaC94IZ9gJhYvprMR1NKz4etFgNPmhA4T1NS8NVVgMHBYOptv1qAdKSNzZ2l6V23h2BquFpVQ2MqE6Lcx0N0j1ZoRVuYo1qTrIkOpEBNbn94b3PHNJMVO2v1NqV85G6uNgPdvv85eneHItsIfUc5yXMeYLXZ017trlhxj43lLVsEyUaM7S5dfykayqVgsaJ9faHYz6F14oRKJCbwhg7y4ybxxxR5KtCKihXgf5QJJXYmsrimudD8KXMVsQKEyHFETzVR7eNMRZvcohFKBPwZdIntkcpLygMmZK4Gaz6pD3t4PTkVXKAWQsPTepJ57FfP9kNkPU6BDxf9X7skBrsRFD3ldCdFUMi0lxOmkBakmXHLODRmmZl73bKuIKFT7lZAXY0Rn3d5NzXcyzVODRNXnMyRW9c2NLvhYQe0ltdR8dIDtRbsh1AQEC5P1eI9XGhBLcAqhU0oBe7k5rMzQXL44TtYMo9NccsgMjNsfToyCqezocgfmLYjqZOUnRbBG7ymn5FJECzOd8X1KagaXqzlSmDtD7cRzZms3iA8FE85cWaK ID token: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiN2p2MmFjeGtucHVpcXo1MXRna2giLCJyZWFsbU5hbWUiOiJjdXN0b21SZWFsbSIsInVuaXF1ZVNlY3VyaXR5TmFtZSI6ImFkbWluIiw


iaXNzIjoiaHR0cHM6Ly9teWNsdXN0ZXIuaWNwOjk0NDMvb2lkYy9lbmRwb2ludC9PUCIsImF1ZCI6ImY4YjVjZGE1YTgzZjg4NjZhOTIxMTQ2MGU5YTk4YzQ4IiwiZXhwIjoxNTA4MjYwODc4LCJpYXQiOjE1MDgyNjA4NzgsInN1YiI6ImFkbWluIn0.IrLm1R9a4GBiTG0wYR1JhGqT4HSArN3gPHhPPTC4ZuS46LulRQCBksxh9I59uT4pYcqhd0qJ_xp9Ys1H8xLsq1zKSI0W2KAzuFkIbXQiK9Q6_Z3oQOHE8XMG7Xfb0R8B4TgbTjQ3XWkEkXsyeliXk0l7mqlVIgTFbXx8nqcoFbXhmH7ZQukj73lMQ0AyKKPpJktWtPCLpugtiTA0nkKUodncvHdSw43bmVQuGsQ_kRhhr8Ka8y_olYcBtYUSAKqdwiGPu6O0Qk-57FCiUmX4W9pjLRAR9EmILY9RqJAsH5kE11kYHPTO2fu-B6omzw2eKxhjZYHMIPmxUciiBRB9Pw

これらのトークンは、CLI にログインしている間、/<user_folder>/.bluemix/plugins/icp/config.json ファイルに保管されています。ここで、<user_folder> は、ユーザー・ディレクトリーのパスです (macOS の /Users/my_username など)。

curl を使⽤する場合、以下のコマンドを実⾏します。

curl -k -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -d "grant_type=password&username=admin&password=admin&scope=openid" https://<cluster_lb_address>:8443/idprovider/v1/auth/identitytoken --insecure

ここで、<cluster_lb_address> は、IBM Cloud Private management console へのアクセスに使⽤する IP アドレスです。

以下の例に⽰すように、このコマンドによって access_token、refresh_token、および id_tokenが返されます。

{"access_token":"We15Nz7hwPy4gc9rVh7oQK0JmrM4A97DRj1pvZrMGBhdYhJDhklcZTYsTZB4rjpsTrTMTGNI6OhQK4lmjHi6BoJK5r4xTT1xkOiJeqrKPk5AVxuBfgPpUU4q766GlPEYDNJCKcrue4EOpPoqzH5nywEfXyUDmEFy4gAXg9ehjKFqfmL9m0N4H815QY9ItoCW4uBiPIU8tjg4BlhVFdlGbvkttBJ0R1yP7PMHp273wWOziGEkuAWEtjtdh24Nvo1qaDl2ZU0XNO8mS5zKtgA4iH5ftndk0YZWiJcyoiKh61qEbMkx7QehhzVHDt01fD3zYxfdHJuzIqajLweEEan4zWPnZlTViqTfAxkUFdLPZoh7ocUENQVMwiuFGjkKJhTaugYLCM8zOUNZJ8MFgeM1stixCKrVrIk1rUaLIx0QRDDmIjNY0WK0hBvTuoLodbcq6XqJPu6KjcWnpQJQYAPeAhPp7hDGqOnfZt5p4weTBq094OCpG9VyU6FvTUQVrW6603If5iJmlzCUfu2fW1RtePD4MYhepFDmUSdibsSe7z3WItOzw0FZ3JcXDpUt8nOZWBrQUfTZGrsYS7CT8dDZCgb9dxfUxolxPLH0AFSEXIIopb6RhS6Dsup0d8xXEdpEFXNecPZDzFteKEwSyQTGyQzafXIHqcw7JUiLZgpmLun99K4UM0pfSoQkLG2xSwR4Azq7FwMN0KBKXwCWBp0oe6CtCzev6hFvXWMJqimiveXa2cclrqlkRvgRmSpKhfIbQ2uaRaxOlBfLFzmvnr5jGldboI0Ppr094wv7QvpsME25HwQkod4neVeU5TAxjU3Kni5B2TJkbpGA8Zlm9GVpq4vG3BkGEvjP5u9Fh6pWXksOmLhlhLj7cSiegOzy3I1WsgbYFBEyDJdKAHGnVlHLKMegaYEKIEhoG3Oc1bP7R15tvwEP3aSPrwqEnJCkHNWFlzqkNRHjWEChGG6XaqbnShqHVA0bAeEBknCXvVXI","token_type":"Bearer","expires_in":43199,"scope":"openid",\ "refresh_token":"kxr337rAXlA0dm8Gx3e7DjJYOXOfrunKM4znvSGhQGjWNvvh05",\ "id_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiZm9ldTgxZzJrOTVyaXNiajJrcHoiLCJyZWFsbU5hbWUiOiJjdXN0b21SZWFsbSIsInVuaXF1ZVNlY3VyaXR5TmFtZSI6ImFkbWluIiwiaXNzIjoiaHR0cHM6Ly9teWNsdXN0ZXIuaWNwOjk0NDMvb2lkYy9lbmRwb2ludC9PUCIsImF1ZCI6ImE2OWVlNjM5MjZlMDA0MmYzZWVlNGYyOTE4MDViNjMyIiwiZXhwIjoxNTA3OTgzODIxLCJpYXQiOjE1MDc5ODM4MjEsInN1YiI6ImFkbWluIn0.ZvE0eApr6SiAYbx7zSicEjdtWsUL8dq4UdttZsQpoB7eWFFioIC1R52ub2jlrwQqjITfHDtc7eUyK0QXOHIalXheX61DoAseTVxi2fELZqG_weKPe4LOeo4LENsoRx8P_Jfv8iQh5zmsrKxBeZCn5gWre5LPOE34CF8F-b0RJO2axEY2m0KOiXOQGD4ltYGNzMdzp5LeaGENTOUM2ayrvpHFBhLxAtF0RpK5NuyNvlKO3t33DPGSWOUy_q19fasM9ZN6Z2R73fRHtuC9lMDooQKJdAtqwcJ4Y2T7RyzJEp9pvarcGUDr5X3YJ0dI-XJlT-fJJ6rHxddHQRvtCAGUvw"}root@master:~#

4. 認証トークンを変数に保管します。 Kubernetes や Heapster も含め、IBM Cloud Private API にアクセスする際には、要求ヘッダーに認証トークンを指定します。次のコマンドを実⾏します。

export ID_TOKEN=<ID token>

ここで、<ID token> は、表⽰された ID トークンです。

5. アクセス・トークンを変数に保管します。 IBM Cloud Private ユーザー管理 API にアクセスする際には、要求ヘッダーにアクセス・トークンを指定します。次のコマンドを実⾏します。

export ACCESS_TOKEN=<Access token>

ここで、<Access token> は、表⽰されたアクセス・トークンです。


6. クラスターの CA 証明書のコピーを取得します。

ブート・ノードにアクセスできる場合、CA 証明書ファイルは、/<installation_directory>/cluster/etc/docker/certs.d/mycluster.icp:8500/ca.crt です。

IBM Cloud Private CLIを使⽤する場合、以下のようにします。

1. クラスター名を取得します。次のコマンドを実⾏します。

bx pr clusters


Name ID State Created Masters Workers Datacenter mycluster 00000000000000000000000000000001 deployed 2017-10-17T13:59:02+0000 1 4 default

この出⼒では、クラスター名は mycluster です。

2. ご使⽤のクラスター⽤に kubectl を構成します。 kubectl を構成すると、認証証明書がコンピューターに保管されます。次のコマンドを実⾏します。

bx pr cluster-config <cluster>

ここで、<cluster> は、前のコマンドで取得したクラスター名です。

3. 認証証明書が使⽤可能であることを確認します。以下のコマンドを実⾏します。

ls /<user_folder>/.bluemix/plugins/icp/clusters/<cluster>

ここで、<user_folder> はユーザー・ディレクトリーのパス (macOS の /Users/my_username など) であり、<cluster> はクラスター名です。このファイル・パスは、後のステップで使⽤する <certificate_path> 変数です。

以下の出⼒に⽰されているように、ca.crt ファイルがあります。

ca.crt kube-config

コンポーネント API

IBM® Cloud Private で使⽤されるいくつかのコンポーネントのための API にアクセスできます。

Kubernetes API Heapster API Elasticsearch API Docker Registry V2 API Prometheus API

Kubernetes API

IBM® Cloud Private バージョン 2.1.0.3 では、Kubernetes バージョン 1.10.0 を使⽤して⻑期実⾏サービスを管理します。

Kubernetes API の資料には、以下の場所からアクセスできます。

https://github.com/kubernetes/kubernetes/tree/v1.10.0/docs/api-reference


https://github.com/kubernetes/kubernetes/tree/v1.10.0/docs/api-reference

https://github.com/kubernetes/kubernetes/tree/v1.10.0/docs

Kubernetes API コマンドの実⾏

Kubernetes API コマンドを実⾏する際には、認証ヘッダーを取得して指定する必要があります。『コンポーネントAPI コマンドまたは管理 API コマンドを実⾏するための準備』を参照してください。

この情報を取得した後に、Kubernetes API コマンドを実⾏できます。例えば、default 名前空間内のポッドをリストするには、以下のコマンドを実⾏します。

curl -k -H "Authorization:Bearer $ID_TOKEN" https://<cluster_CA_domain>:8001/api/v1/namespaces/default/pods


$ID_TOKEN は、クラスターの認証トークンを保管している変数です。<cluster_identification> は、マスター IP アドレス、cluster_lb_address アドレス値、またはインストール時に config.yaml ファイルに設定された認証局 (CA) ドメインです。認証局 (CA) ドメイン・ネームを指定した場合、ローカル /etc/hosts ファイルでその IP アドレスをそのドメイン・ネームにマップする必要があります。


{ "kind": "PodList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/namespaces /default/pods", "resourceVersion": "414" }, "items": [{...}, {...}] }

Heapster API

Kubernetes API サービス・プロキシーを介して Heapster サービスにアクセスできます。 IBM® Cloud Private バージョン 2.1.0.3 では、Heapster バージョン 1.4.0 を使⽤して、ポッドのメトリックを収集します。

Heapster サービスに直接アクセスすることはできません。 Kubernetes API サービス・プロキシーを介してのみアクセス可能です。

スーパー管理者とチーム管理者のどちらも、Kubernetes API にアクセスできます。ただし、チーム管理者は、その名前空間に属しているリソースのみにアクセスできます。スーパー管理者は、クラスター内のすべてのリソースにアクセスできます。

Heapster API モデルを表⽰するには、https://github.com/kubernetes/heapster/blob/release-1.4/docs/model.md を参照してください。

Heapster でエクスポートされるメトリックのリストを表⽰するには、https://github.com/kubernetes/heapster/blob/release-1.4/docs/storage-schema.md を参照してください。

Heapster メトリックへのアクセス

Heapster メトリックにアクセスするには、Kubernetes API コマンドの実⾏に使⽤するのと同じ認証ヘッダーを取得して指定する必要があります。『コンポーネント API コマンドまたは管理 API コマンドを実⾏するための準備』を参照してください。

例えば、ポッド nginx-1720728682-dklzv の CPU 使⽤率メトリックを取得するには、以下のコマンドを実⾏します。

# curl -k -s -H "Authorization:Bearer $ID_TOKEN" \ https://<cluster_CA_domain>:8443/kubernetes/api/v1/proxy/\ namespaces/kube-system/services/heapster/api\


https://github.com/kubernetes/kubernetes/tree/v1.10.0/docs

https://github.com/kubernetes/heapster/blob/release-1.4/docs/model.md

https://github.com/kubernetes/heapster/blob/release-1.4/docs/storage-schema.md

/v1/model/namespaces/<namespace>/pods/ \ <pod>/metrics/cpu/usage_rate


$ID_TOKEN は、クラスターの認証トークンを保管している変数です。<cluster_CA_domain> は、インストール時に config.yaml ファイルに設定された認証局 (CA) ドメインです。

<namespace> は、名前空間スコープです。<pod> は、ポッドの名前です。出⼒は、以下のコードのようになります。

{ "metrics": [ { "timestamp": "2016-10-11T02:26:00Z", "value": 0 }, { "timestamp": "2016-10-11T02:27:00Z", "value": 0 } ], "latestTimestamp": "2016-10-11T02:27:00Z" }

Elasticsearch API

Elasticsearch API コマンドを実⾏できます。 IBM® Cloud Private バージョン 2.1.0.3 では、Elasticsearch バージョン5.5.1 を使⽤して、ログの検索およびポッドからのメトリックの取得を⾏います。

スーパー管理者とチーム管理者のどちらも、すべてのリソースについて Elasticsearch API にアクセスできます。Elasticsearch API サービス・プロキシーを介して Elasticsearch にアクセスする必要があります。

Elasticsearch API の資料を表⽰するには、https://www.elastic.co/guide/en/elasticsearch/reference/5.5/docs.html を参照してください。

Elasticsearch API コマンドの実⾏

Elasticsearch API にアクセスする際に、認証ヘッダーを指定する必要があります。『コンポーネント API コマンドまたは管理 API コマンドを実⾏するための準備』を参照してください。

例えば、ポッド helm-1857591562-s41zh で実⾏されている Tiller コンテナーに関する最新の 10 件のログを取得するには、以下のコマンドを実⾏します。

curl -k -s -X POST -H "Authorization:Bearer $ID_TOKEN" \ https://<cluster_CA_domain>:8443/elasticsearch*/_search?pretty -d \ '{"from" : 0, "size" : 10, "_source" : ["log", "time"], "query" : \ {"bool" : { "must" : [{ "match" :{ "kubernetes.namespace" : "kube-system" }}, \ { "match" : { "kubernetes.pod" : "helm-1857591562-s41zh" }},{ "match" : \ { "kubernetes.container_name" : "Tiller" }}]}}, "sort" : [ {"time" : { "order" : "desc" }}]}'




{ "took" : 2, "timed_out" : false, "_shards" : { "total" : 2, "successful" : 2, "failed" : 0 }, "hits" : { "total" : 70,


https://www.elastic.co/guide/en/elasticsearch/reference/5.5/docs.html

"max_score" : null, "hits" : [ { "_index" : "logstash-2017.03.21", "_type" : "%{transport}", "_id" : "AVrvPCCkB2X5riajRReg", "_score" : null, "_timestamp" : 1490072379557, "_source" : { "log" : "2017/03/21 04:59:35 transport: http2Server.HandleStreams failed to read frame: read tcp [::1]:44134->[::1]:43588: read: connection reset by peer", "time" : "2017-03-21T04:59:35.36956464Z" }, "sort" : [ 1490072375369 ] }, { "_index" : "logstash-2017.03.21", "_type" : "%{transport}", "_id" : "AVrvOBVvB2X5riajRPqd", "_score" : null, "_timestamp" : 1490072114543, "_source" : { "log" : "2017/03/21 04:55:05 transport: http2Server.HandleStreams failed to read frame: read tcp [::1]:44134->[::1]:43398: read: connection reset by peer", "time" : "2017-03-21T04:55:05.390721513Z" }, "sort" : [ 1490072105390 ] }, ….. ] } }

Docker Registry V2 API

Docker API コマンドを実⾏できます。 IBM® Cloud Private バージョン 2.1.0.3 では、Docker Registry V2 API 仕様を実装している Docker ディストリビューションを使⽤して、Docker イメージのストレージを管理します。

スーパー管理者とチーム管理者のどちらも、Docker Registry API にアクセスできます。ただし、チーム管理者は、その名前空間に属しているリソースのみにアクセスできます。スーパー管理者は、クラスター内のすべてのリソースにアクセスできます。

Docker Registry V2 API について詳しくは、以下の公式資料を参照してください。

Docker Registry HTTP API V2 Docker Registry v2 authentication via central service

Docker API コマンドの実⾏

Docker API コマンドを実⾏する際には、クラスター・ノードから認証証明書を取得し、認証トークンを指定する必要があります。

クラスター・ノードにある /etc/docker/certs.d/<cluster_CA_domain>:8500/ca.crt ファイル (認証証明書) を、API コマンドを実⾏するノードにコピーする必要があります。

以下のコマンドを実⾏して、認証トークンを ID_TOKEN 変数に保管できます。

export CMD=`curl --cacert /<certificate_path>/ca.crt -s -u admin:admin "https://<cluster_CA_domain>:8443/image-manager/api/v1/auth/token?service=token-service&scope=registry:catalog:*"`

export ID_TOKEN=$(echo $CMD | python -c 'import sys,json; print json.load(sys.stdin)["token"]')


https://docs.docker.com/registry/spec/api

https://github.com/docker/distribution/blob/master/docs/spec/auth/token.md

echo $ID_TOKEN

その後、REST コマンドで認証トークンを使⽤できます。例えば、Docker Registry からイメージのリストを取得するには、以下のコマンドを実⾏します。

# curl --cacert /<certificate_path>/ca.crt -s -H "Authorization: Bearer $ID_TOKEN" "https://<cluster_CA_domain>:8500/v2/_catalog"

このコマンドで、$ID_TOKEN は、クラスターの認証 Cookie を保管している変数です。


{"repositories":[]}

Prometheus API

IBM® Cloud Private バージョン 2.1.0.3 は、Prometheus バージョン 2.0 を使⽤して、収集ターゲットからのメトリックを管理します。

クラスター管理者とチーム管理者の両⽅が、Prometheus API にアクセスできます。

Prometheus には、Prometheus API サービス・プロキシーからアクセスする必要があります。

Prometheus API の資料を表⽰するには、https://prometheus.io/docs/prometheus/latest/querying/api/ を参照してください。

Prometheus API コマンドの実⾏

Prometheus API コマンドを実⾏する際には、認証ヘッダーを取得して指定する必要があります。『コンポーネントAPI コマンドまたは管理 API コマンドを実⾏するための準備』を参照してください。

この情報を取得した後に、Prometheus API コマンドを実⾏できます。例えば、すべてのノードのブート時刻を取得するには、次のコマンドを実⾏します。

curl -k -s -X GET -H "Authorization:Bearer $ID_TOKEN" https://<cluster_CA_domain>:8443/prometheus/api/v1/query?query=node_boot_time




{"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"node_boot_time","app":"monitoring-prometheus", \ "chart":"ibm-icpmonitoring-1.1.0","component":"nodeexporter","heritage":"Tiller","instance":"9.42.135.189:9100", \ "job":"kubernetes-service-endpoints","kubernetes_name":"monitoring-prometheus-nodeexporter","kubernetes_namespace":"kube-system", \ "release":"monitoring"},"value":[1523394278.231,"1521476293"]}, \ {"metric":{"__name__":"node_boot_time","app":"monitoring-prometheus","chart":"ibm-icpmonitoring-1.1.0", \ "component":"nodeexporter","heritage":"Tiller","instance":"9.42.135.84:9100","job":"kubernetes-service-endpoints", \ "kubernetes_name":"monitoring-prometheus-nodeexporter","kubernetes_namespace":"kube-system","release":"monitoring"}, \ "value":[1523394278.231,"1521476285"]},{"metric":{"__name__":"node_boot_time","app":"monitoring-prometheus", \ "chart":"ibm-icpmonitoring-


https://prometheus.io/docs/prometheus/latest/querying/api/

1.1.0","component":"nodeexporter","heritage":"Tiller","instance":"9.42.78.191:9100", \ "job":"kubernetes-service-endpoints","kubernetes_name":"monitoring-prometheus-nodeexporter","kubernetes_namespace": \ "kube-system","release":"monitoring"},"value":[1523394278.231,"1521476254"]}]}}

ユーザー管理および認証 API

ユーザー管理 API コマンドでは、ユーザーおよびチームを管理します。

これらの API を使⽤するには、許可ヘッダーを要求に追加する必要があります。許可ヘッダーに追加するアクセス・トークンが必要です。アクセス・トークンを取得するには、『コンポーネント API コマンドまたは管理 API コマンドを実⾏するための準備』を参照してください。

ユーザー管理および認証 API のデータ

API バージョン1.0.0

API URI コンポーネント

スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

基本パス

idmgmt/identity/api/v1

コマンド出⼒フォーマット

application/json

アカウント管理ディレクトリー管理ユーザー・グループ管理ユーザー管理チーム管理

アカウント管理 API

アカウントを管理するための API。

基本パス: https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/account

すべてのアカウントに関する情報の取得




スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/account

コマンド

GET


application/json

サンプル curl コマンドは、以下のコードのようになります。

curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/account'

応答は、以下のコードのようになります。

[{"id":"id-mycluster-account","name":"mycluster Account","description":"Description for mycluster Account"}]

アカウントに関する情報の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/account/{id}

コマンド

GET


application/json



curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/account/id-mycluster-account'


{"id":"id-mycluster-account","name":"mycluster Account","description":"Description for mycluster Account","url":"/identity/api/v1/account/id-mycluster-account"}

ディレクトリー管理 API

LDAP ディレクトリーを管理するための API。

基本パス: https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/directory/ldap

LDAP ディレクトリーへの接続



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/directory/ldap/onboardDirectory

コマンド

POST


application/json


curl -k -X POST --header "Authorization: bearer $ACCESS_TOKEN" --header 'Content-Type: application/json' -d '{"LDAP_ID": "Corp", "LDAP_URL": "ldap://corp.abc.com:389", "LDAP_BASEDN": "o=ibm.com", "LDAP_BINDDN": "", "LDAP_BINDPASSWORD": "", "LDAP_TYPE": "IBM Tivoli Directory Server", "LDAP_USERFILTER": "(&(emailAddress=%v)(objectclass=ePerson))", "LDAP_GROUPFILTER": "(&(cn=%v)(objectclass=groupOfUniqueNames))", "LDAP_USERIDMAP": "*:emailAddress","LDAP_GROUPIDMAP":"*:cn", "LDAP_GROUPMEMBERIDMAP": "groupOfUniqueNames:uniqueMember"}' 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/directory/ldap/onboardDirectory'

LDAP パラメーターについて詳しくは、『LDAP 認証の構成』を参照してください。



"8b019a10-daa0-11e7-8dba-bf3c83e12db5"

LDAP 接続のリスト表⽰



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/directory/ldap/list

コマンド

GET


application/json


curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/directory/ldap/list'


[{"id":"8b019a10-daa0-11e7-8dba-bf3c83e12db5","LDAP_ID":"Corp","LDAP_REALM":"REALM","LDAP_HOST":"corp.abc.com","LDAP_PORT":"389","LDAP_BASEDN":"o=ibm.com","LDAP_BINDDN":"","LDAP_BINDPASSWORD":"","LDAP_TYPE":"IBM Tivoli Directory Server","LDAP_USERFILTER":"(&(emailAddress=%v)(objectclass=ePerson))","LDAP_GROUPFILTER":"(&(cn=%v)(objectclass=groupOfUniqueNames))","LDAP_USERIDMAP":"*:emailAddress","LDAP_GROUPIDMAP":"*:cn","LDAP_GROUPMEMBERIDMAP":"groupOfUniqueNames:uniqueMember","LDAP_URL":"ldap://corp.abc.com:389","LDAP_PROTOCOL":"ldap"}]

LDAP ディレクトリーの削除



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号


8443

パス

idmgmt/identity/api/v1/directory/ldap/offboardDirectory

コマンド

POST


application/json


curl -k -X POST --header "Authorization: Bearer $ACCESS_TOKEN" 'https://<cluster_lb_address>:8443/identity/api/v1/directory/ldap/offboardDirectory'


"Count: 1"

LDAP ディレクトリーでのユーザー・グループの検索



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/directory/ldap/{id}/fetchUserGroups

コマンド

GET


application/json


curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/directory/ldap/{LDAP ID}/fetchUserGroups?searchString=*sec*"


[{"cn":"security","dn":"cn=security,cn=platform,ou=cloud,ou=isl,ou=groups,dc=ibm,dc=com"},{"cn":"cloudSecurity","dn":"cn=cloudSecurity,ou=cloud,ou=isl,ou=groups,dc=ibm,dc=com"}]


LDAP ディレクトリーでのユーザーの検索



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/directory/ldap/{id}/fetchUsers

コマンド

GET


application/json


curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/directory/ldap/{LDAP ID}/fetchUsers?searchString=*test*"


[{"cn":"TestUser","dn":"uid=testuser,ou=people,dc=ibm,dc=com"},{"cn":"test1","dn":"uid=test1,ou=people,dc=ibm,dc=com"}]

LDAP ディレクトリーからのユーザー・グループのインポート



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/directory/ldap/{id}/importUserGroups


コマンド

POST


application/json


curl -k -X POST --header "Authorization: Bearer $ACCESS_TOKEN" --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{ "baseDN": "cn=security,cn=platform,ou=cloud,ou=isl,ou=groups,dc=ibm,dc=com" }' "https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/directory/ldap/fb01b1d0-1fa4-11e8-80d6-15882dd657a0/importUserGroups"


{"name":"security","directoryId":"fb01b1d0-1fa4-11e8-80d6-15882dd657a0","userGroupDN":"cn=security,cn=platform,ou=cloud,ou=isl,ou=groups,dc=ibm,dc=com"}

LDAP ディレクトリーからのユーザーのインポート



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/directory/ldap/{id}/importUser

コマンド

POST


application/json


curl -k -X POST --header "Authorization: Bearer $ACCESS_TOKEN" --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{ "baseDN": "uid=testuser,ou=people,dc=ibm,dc=com" }' "https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/directory/ldap/fb01b1d0-1fa4-11e8-80d6-15882dd657a0/importUser"'


{"userId":"testuser","directoryId":"fb01b1d0-1fa4-11e8-80d6-15882dd657a0","firstName":"TestUser","lastName":"","email":"[email protected]","lastLogin"


:"","userBaseDN":"uid=testuser,ou=people,dc=ibm,dc=com","type":"LDAP","_id":"testuser","loopback__model__name":"Users"}

ユーザー・グループ管理 API

ユーザー・グループを管理するための API。

基本パス: https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/usergroup

すべてのユーザー・グループの取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/usergroup

コマンド

GET


application/json


curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/usergroup'


[{"name":"security","directoryId":"fb01b1d0-1fa4-11e8-80d6-15882dd657a0","userGroupDN":"cn=security,cn=platform,ou=cloud,ou=isl,ou=groups,dc=ibm,dc=com"}]

ユーザー・グループの削除



スキーム

HTTPS


ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/usergroup/{id}

コマンド

DELETE


application/json


curl -k -X DELETE --header "Authorization: Bearer $ACCESS_TOKEN" 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/usergroup/<usergroup name>'


{"count":1}

ユーザー管理 API

ユーザーを管理するための API。

基本パス: https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/users

すべてのユーザーに関する情報の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/idmgmt/identity/api/v1/users

コマンド

GET



application/json


curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/users'


[{"userId":"aaa","directoryId":"fb01b1d0-1fa4-11e8-80d6-15882dd657a0","firstName":"AAA","lastName":"","email":"[email protected]","lastLogin":"","userBaseDN":"uid=aaa,ou=people,dc=ibm,dc=com","type":"LDAP"},{"userId":"testuser","directoryId":"fb01b1d0-1fa4-11e8-80d6-15882dd657a0","firstName":"TestUser","lastName":"","email":"[email protected]","lastLogin":"","userBaseDN":"uid=testuser,ou=people,dc=ibm,dc=com","type":"LDAP"},{"userId":"bbb","directoryId":"fb01b1d0-1fa4-11e8-80d6-15882dd657a0","firstName":"BBB","lastName":"","email":"[email protected]","lastLogin":"","userBaseDN":"uid=bbb,ou=people,dc=ibm,dc=com","type":"LDAP"}]

全チームでユーザーに割り当てられている最⾼の役割の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/idmgmt/identity/api/v1/users/{ID}/getHighestRole

コマンド

GET


application/json

注: ユーザーに割り当てられている最⾼の役割を表⽰できるのは、ログインしているユーザーのみです。


curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/users/admin/getHighestRole


"ClusterAdministrator"

ユーザーに割り当てられているチーム・リソースの取得

API バージョン


1.0.0API URI コンポーネント

スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/idmgmt/identity/api/v1/users/{user}/getTeamResources

コマンド

GET


application/json

注: ユーザーに割り当てられているリソースを表⽰できるのは、ログインしているユーザーのみです。


curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/users/admin/getTeamResources


[{"crn":"crn:v1:icp:private:k8:mycluster:n/default:::","serviceName":"k8","region":"mycluster","namespaceId":"default"},{"crn":"crn:v1:icp:private:k8:mycluster:n/kube-public:::","serviceName":"k8","region":"mycluster","namespaceId":"kube-public"},{"crn":"crn:v1:icp:private:k8:mycluster:n/kube-system:::","serviceName":"k8","region":"mycluster","namespaceId":"kube-system"},{"crn":"crn:v1:icp:private:k8:mycluster:n/platform:::","serviceName":"k8","region":"mycluster","namespaceId":"platform"},{"crn":"crn:v1:icp:private:k8:mycluster:n/services:::","serviceName":"k8","region":"mycluster","namespaceId":"services"}]




スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443


パス

/idmgmt/identity/api/v1/users/{id}

コマンド

DELETE


application/json


curl -k -X DELETE --header "Authorization: Bearer $ACCESS_TOKEN" 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/users/aaa'


"Count: 1"

ユーザーのアカウント情報の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/idmgmt/identity/api/v1/users/{user}/getAccounts

コマンド

GET


application/json


curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/users/testuser/getAccounts'


{"userId":"testuser","directoryId":"fb01b1d0-1fa4-11e8-80d6-15882dd657a0","firstName":"TestUser","lastName":"","email":"[email protected]","lastLogin":"","userBaseDN":"uid=testuser,ou=people,dc=ibm,dc=com","type":"LDAP","url":"/identity/api/v1/users/testuser"}


チーム管理 API

チームを管理するための API。

基本パス: https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/teams

チームの作成



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/teams

コマンド

POST


application/json


curl -k -X POST --header 'Content-Type: application/json' --header "Authorization: bearer $ACCESS_TOKEN" -d '{"teamId":"team3","name":"Team3"}' https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/teams


{"teamId":"team3","name":"Team3","users":[],"usergroups":[]}

チームへのユーザーおよびユーザー・グループの割り当て



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号


8443

パス


コマンド

POST


application/json


curl -k -X POST --header "Authorization: Bearer $ACCESS_TOKEN" --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{"teamId":"test-team","name":"Test Team","users":[{"userId":"testuser","userBaseDN":"uid=testuser,ou=people,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:Operator"}]}],"groups":[{"name":"security","userGroupDN":"cn=security,cn=platform,ou=cloud,ou=isl,ou=groups,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:Operator"}]}]}' "https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/teams"


{"teamId":"test-team","name":"Test Team","users":[{"userId":"testuser","userBaseDN":"uid=testuser,ou=people,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:Operator"}]}],"usergroups":[],"groups":[{"name":"security","userGroupDN":"cn=security,cn=platform,ou=cloud,ou=isl,ou=groups,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:Operator"}]}]}

チームへのリソースの割り当て



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス


コマンド

POST


application/json



curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Authorization: bearer <ACCESS_TOKEN>' -d '{"crn": "crn:v1:icp:private:k8:mycluster.icp:n/default:::"}' 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/teams/<team-ID>/resources' --insecure

ここで、"crn:v1:icp:private:k8:mycluster.icp:n/default:::" は、チームに割り当てるリソースの形式です。サンプル・コマンドでは、default 名前空間がチームに割り当てられています。


{"crn":"crn:v1:icp:private:k8:mycluster.icp:n/default:::","serviceName":"k8","region":"mycluster.icp","namespaceId":"default","scope":"namespace"}

チームに関する情報の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/teams/{id}

コマンド

GET


application/json


curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/teams/test-team'


{"teamId":"test-team","name":"Test Team","users":[{"userId":"testuser","userBaseDN":"uid=testuser,ou=people,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:Operator"}]}],"usergroups":[],"groups":[{"name":"security","userGroupDN":"cn=security,cn=platform,ou=cloud,ou=isl,ou=groups,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:Operator"}]}]}

すべてのチームに関する情報の取得




スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス


コマンド

GET


application/json


curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" 'http://<cluster_lb_address>:8443/idmgmt/identity/api/v1/teams'


[{"teamId":"test-team","name":"Test Team","users":[{"userId":"testuser","userBaseDN":"uid=testuser,ou=people,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:Operator"}]},{"userId":"aaa","firstName":"AAA Nemivant","lastName":"","email":"[email protected]","userBaseDN":"uid=aaa,ou=people,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:Administrator"}]}],"usergroups":[{"name":"security","directoryId":"fb01b1d0-1fa4-11e8-80d6-15882dd657a0","userGroupDN":"cn=security,cn=platform,ou=cloud,ou=isl,ou=groups,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:Viewer"}]},{"name":"cloudSecurity","directoryId":"fb01b1d0-1fa4-11e8-80d6-15882dd657a0","userGroupDN":"cn=cloudSecurity,ou=cloud,ou=isl,ou=groups,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:Operator"}]}]},{"teamId":"f-122","name":"F122","users":[{"userId":"aaa","roles":[{"id":"crn:v1:icp:private:iam::::role:Administrator"}]},{"userId":"bbb","roles":[{"id":"crn:v1:icp:private:iam::::role:Editor"}]},{"userId":"ccc","roles":[{"id":"crn:v1:icp:private:iam::::role:Editor"}]},{"userId":"ddd","roles":[{"id":"crn:v1:icp:private:iam::::role:Viewer"}]}],"usergroups":[]},{"teamId":"team-1","name":"Team1","users":[{"userId":"aaa","firstName":"AAA Nemivant","lastName":"","email":"[email protected]","userBaseDN":"uid=aaa,ou=people,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:ClusterAdministrator"}]}],"usergroups":[{"name":"security","directoryId":"fb01b1d0-1fa4-11e8-80d6-15882dd657a0","userGroupDN":"cn=security,cn=platform,ou=cloud,ou=isl,ou=groups,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:Editor"}]}]},{"teamId":"team3","name":"Team3","users":[],"usergroups":[]},{"teamId":"team2","name":"Team2","users":[{"userId":"ppp","userBaseDN":"uid=ppp,ou=people,dc=ibm,dc=com","roles":[{"id":"crn:v1:icp:private:iam::::role:Viewer"}]}],"usergroups":[]}]

チームに割り当てられたリソースの取得




スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/teams/{id}/resources

コマンド

GET


application/json


curl -k -X GET --header "Authorization: Bearer $ACCESS_TOKEN" 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/teams/{id}/resources'


[{"crn":"crn:v1:icp:private:k8:mycluster:n/default:::","serviceName":"k8","region":"mycluster","namespaceId":"default","scope":"namespace"}]

チームの更新



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス


コマンド

PUT


application/json



curl -k -X PUT --header 'Content-Type: application/json' --header "Authorization: bearer $ACCESS_TOKEN" -d '{"teamId":"f-122","name":"F122","users":[{"userId":"aaa","roles":[{"id":"crn:v1:icp:private:iam::::role:Administrator"}]},{"userId":"bbb","roles":[{"id":"crn:v1:icp:private:iam::::role:Editor"}]},{"userId":"ccc","roles":[{"id":"crn:v1:icp:private:iam::::role:Editor"}]},{"userId":"ddd","roles":[{"id":"crn:v1:icp:private:iam::::role:Viewer"}]}]}' 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/teams/f-122'


{"teamId":"f-122","name":"F122","users":[{"userId":"aaa","roles":[{"id":"crn:v1:icp:private:iam::::role:Administrator"}]},{"userId":"bbb","roles":[{"id":"crn:v1:icp:private:iam::::role:Editor"}]},{"userId":"ccc","roles":[{"id":"crn:v1:icp:private:iam::::role:Editor"}]},{"userId":"ddd","roles":[{"id":"crn:v1:icp:private:iam::::role:Viewer"}]}],"usergroups":[],"_rev":"2-9238053d5bc6a27237a444e0a2e2cc5b","_id":"f-122","loopback__model__name":"Team"}

チームの削除



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

idmgmt/identity/api/v1/teams/{id}

コマンド

DELETE


application/json


curl -k -X DELETE --header "Authorization: Bearer $ACCESS_TOKEN" 'https://<cluster_lb_address>:8443/idmgmt/identity/api/v1/teams/a-1'


{"count":1}

サービス管理 API

サービス管理 API は、サービス ID、API 鍵、およびサービス・ポリシーを管理します。


これらの API を使⽤するには、許可ヘッダーを要求に追加する必要があります。許可ヘッダーに追加するアクセス・トークンが必要です。アクセス・トークンを取得するには、『コンポーネント API コマンドまたは管理 API コマンドを実⾏するための準備』を参照してください。

サービス ID 管理 API 鍵管理サービス・ポリシー管理

サービス ID 管理 API

サービス ID を管理するための API。

基本パス: https://<cluster_lb_address>:8443/iam-token/serviceids/

すべてのサービス ID に関する情報の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/iam-token/serviceids/

コマンド

GET


application/json


curl -k -X GET -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/iam-token/serviceids/"


{"currentPage":1,"pageSize":20,"items":[{"metadata":{"iam_id":"iam-ServiceId-9acf5d7a -d193-4453-be47-3619b7c25de8","uuid":"ServiceId-9acf5d7a-d193-4453-be47-3619b7c25de8" ,"crn":"crn:v1:icp:private:k8::n/kube-system::serviceid:ServiceId-9acf5d7a-d193-4453- be47-3619b7c25de8","createdAt":"2018-05-03T14:28+0000","modifiedAt":"2018-05-03T14:28 +0000"},"entity":{"boundTo":"crn:v1:icp:private:k8::n/kube-system:::","name":"pavan-s erviceid"}},{"metadata":{"iam_id":"iam-ServiceId-d3948112-bded-4189-8537-bc8450a8725d ","uuid":"ServiceId-d3948112-bded-4189-8537-bc8450a8725d","crn":"crn:v1:icp:private:k 8::n/kube-system::serviceid:ServiceId-d3948112-bded-4189-8537-bc8450a8725d","createdA t":"2018-05-03T14:28+0000","modifiedAt":"2018-05-03T14:28+0000"},"entity":{"boundTo": "crn:v1:icp:private:k8::n/kube-system:::","name":"iam-pap-test","description":"iam-pa


p-test serviceid"}},{"metadata":{"iam_id":"iam-ServiceId-ee41749e-7be4-44ae-aa21-1b5e 342f9685","uuid":"ServiceId-ee41749e-7be4-44ae-aa21-1b5e342f9685","crn":"crn:v1:icp:p rivate:k8::n/default::serviceid:ServiceId-ee41749e-7be4-44ae-aa21-1b5e342f9685","crea tedAt":"2018-05-07T09:18+0000","modifiedAt":"2018-05-07T09:18+0000"},"entity":{"bound To":"crn:v1:icp:private:k8::n/default:::","name":"pavan-default-serviceid"}}]}

CRN にバインドされたすべてのサービス ID に関する情報の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/iam-token/serviceids/?boundTo={CRN}

コマンド

GET


application/json


curl -k -X GET -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/iam-token/serviceids/?boundTo=crn:v1:icp:private:k8::n/kube-system:::"


{"currentPage":1,"pageSize":20,"items":[{"metadata":{"iam_id":"iam-ServiceId-9acf5d7a -d193-4453-be47-3619b7c25de8","uuid":"ServiceId-9acf5d7a-d193-4453-be47-3619b7c25de8" ,"crn":"crn:v1:icp:private:k8::n/kube-system::serviceid:ServiceId-9acf5d7a-d193-4453- be47-3619b7c25de8","createdAt":"2018-05-03T14:28+0000","modifiedAt":"2018-05-03T14:28 +0000"},"entity":{"boundTo":"crn:v1:icp:private:k8::n/kube-system:::","name":"pavan-s erviceid"}},{"metadata":{"iam_id":"iam-ServiceId-d3948112-bded-4189-8537-bc8450a8725d ","uuid":"ServiceId-d3948112-bded-4189-8537-bc8450a8725d","crn":"crn:v1:icp:private:k 8::n/kube-system::serviceid:ServiceId-d3948112-bded-4189-8537-bc8450a8725d","createdA t":"2018-05-03T14:28+0000","modifiedAt":"2018-05-03T14:28+0000"},"entity":{"boundTo": "crn:v1:icp:private:k8::n/kube-system:::","name":"iam-pap-test","description":"iam-pa p-test serviceid"}}]}

サービス ID の作成



スキーム


HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/iam-token/serviceids/

コマンド

POST


application/json


curl -k -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" -d '{"boundTo": "crn:v1:icp:private:k8::n/kube-system:::","name": "test_serviceid","description": "Description for test_serviceid"}' "https://<cluster_lb_address>:8443/iam-token/serviceids/"


{"metadata":{"iam_id":"iam-ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f","uuid":"Se rviceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f","crn":"crn:v1:icp:private:k8::n/kube-sy stem::serviceid:ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f","createdAt":"2018-05- 08T07:47+0000","modifiedAt":"2018-05-08T07:47+0000"},"entity":{"boundTo":"crn:v1:icp: private:k8::n/kube-system:::","name":"test_serviceid","description":"Description for test_serviceid"}}

特定のサービス ID に関する情報の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/iam-token/serviceids/{サービス ID}

コマンド

GET



application/json


curl -k -X GET -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/iam-token/serviceids/ServiceId-9acf5d7a-d193-4453-be47-3619b7c25de8"


{"metadata":{"iam_id":"iam-ServiceId-9acf5d7a-d193-4453-be47-3619b7c25de8","uuid":"Se rviceId-9acf5d7a-d193-4453-be47-3619b7c25de8","crn":"crn:v1:icp:private:k8::n/kube-sy stem::serviceid:ServiceId-9acf5d7a-d193-4453-be47-3619b7c25de8","createdAt":"2018-05- 03T14:28+0000","modifiedAt":"2018-05-03T14:28+0000"},"entity":{"boundTo":"crn:v1:icp: private:k8::n/kube-system:::","name":"pavan-serviceid"}}

特定のサービス ID および関連 API 鍵の削除



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス


コマンド

DELETE


application/json


curl -k -X DELETE -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/iam-token/serviceids/ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f"


no content Response Code: 204

サービス ID の更新




スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス


コマンド

PUT


application/json


curl -k -X PUT -H "Content-Type: application/json" -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" -d '{"name": "test_serviceid","description": "Updated Description for test_serviceid"}' "https://<cluster_lb_address>:8443/iam-token/serviceids/ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f"


{"metadata":{"iam_id":"iam-ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f","uuid":"Se rviceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f","crn":"crn:v1:icp:private:k8::n/kube-sy stem::serviceid:ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f","createdAt":"2018-05- 08T07:47+0000","modifiedAt":"2018-05-08T07:48+0000"},"entity":{"boundTo":"crn:v1:icp: private:k8::n/kube-system:::","name":"test_serviceid","description":"Updated Descript ion for test_serviceid"}}

API 鍵管理 API

鍵を管理するための API。

基本パス: https://<cluster_lb_address>:8443/iam-token/apikeys/

API 鍵の作成



スキーム

HTTPS

ホスト IP

cluster_lb_address


ポート番号

8443

パス

/iam-token/apikeys/

コマンド

POST


application/json


curl -k -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" -d '{"name": "test_serviceid_apikey","description": "Description for test_serviceid_apikey ","boundTo": "crn:v1:icp:private:k8::n/kube-system::serviceid:ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f"}' "https://<cluster_lb_address>:8443/iam-token/apikeys/"


{"metadata":{"uuid":"ApiKey-1c40ff8e-5b33-441e-b06f-d5cb89cd1a88","createdAt":"2018-05-08T08:13+0000","modifiedAt":"2018-05-08T08:13+0000"},"entity":{"boundTo":"crn:v1:icp:private:k8::n/kube-system::serviceid:ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f","name":"test_serviceid_apikey","description":"Description for test_serviceid_apikey","format":"APIKEY","apiKey":"YZouCtoSz6zTdg9c7tfNNBl5kvo8Fgz1C__8IrsWtieA"}}

CRN にバインドされた API 鍵の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/iam-token/apikeys/?boundTo={CRN}::{サービス ID}

コマンド

GET


application/json



curl -k -X GET -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>MASTER_NODE_IP:8443/iam-token/apikeys/?boundTo=crn:v1:icp:private:k8::n/kube-system::serviceid:ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f"


{"currentPage":1,"pageSize":20,"items":[{"metadata":{"uuid":"ApiKey-b730fe51-66b5-4c60-83a4-e3e0416d4d86","createdAt":"2018-05-08T08:11+0000","modifiedAt":"2018-05-08T08:11+0000"},"entity":{"boundTo":"crn:v1:icp:private:k8::n/kube-system::serviceid:ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f","name":"test_serviceid_apikey","description":"Description for test_serviceid_apikey ","format":"APIKEY","apiKey":"OKfUUmsbiK5QF8Yq1_2oiKkDzqAVGaOp504Bnvjn0nxs"}}]}

API 鍵に関する情報の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/iam-token/apikeys/{API 鍵}

コマンド

GET


application/json


curl -k -X GET -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/iam-token/apikeys/ApiKey-1c40ff8e-5b33-441e-b06f-d5cb89cd1a88"


{"metadata":{"uuid":"ApiKey-1c40ff8e-5b33-441e-b06f-d5cb89cd1a88","createdAt":"2018-0 5-08T08:13+0000","modifiedAt":"2018-05-08T08:13+0000"},"entity":{"boundTo":"crn:v1:ic p:private:k8::n/kube-system::serviceid:ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f ","name":"test_serviceid_apikey","description":"Description for test_serviceid_apikey ","format":"APIKEY","apiKey":"YZouCtoSz6zTdg9c7tfNNBl5kvo8Fgz1C__8IrsWtieA"}}

API 鍵の更新




スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス


コマンド

PUT


application/json


curl -k -X PUT -H "Content-Type: application/json" -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" -d '{"name": "test_serviceid_apikey","description": "Updated Description for test_serviceid_apikey"}' "https://<cluster_lb_address>:8443/iam-token/apikeys/ApiKey-1c40ff8e-5b33-441e-b06f-d5cb89cd1a88"


{"metadata":{"uuid":"ApiKey-1c40ff8e-5b33-441e-b06f-d5cb89cd1a88","createdAt":"2018-0 5-08T08:13+0000","modifiedAt":"2018-05-08T08:24+0000"},"entity":{"boundTo":"crn:v1:ic p:private:k8::n/kube-system::serviceid:ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f ","name":"test_serviceid_apikey","description":"Updated Description for test_servicei d_apikey","format":"APIKEY","apiKey":"YZouCtoSz6zTdg9c7tfNNBl5kvo8Fgz1C__8IrsWtieA"}}

API 鍵の削除



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス


コマンド


DELETE


application/json


curl -k -X DELETE -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/iam-token/apikeys/ApiKey-1c40ff8e-5b33-441e-b06f-d5cb89cd1a88"



OpenID Connect (OIDC) トークンの⽣成



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス


コマンド

POST


application/json


curl -k -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Accept: application/json" -d 'grant_type=urn:ibm:params:oauth:grant-type:apikey&apikey=EiAUSgnt32h800nur9BCPnHlIsOK6G95pH6fNR2T7peZ&response_type=cloud_iam' "https://<cluster_lb_address>:8443/iam-token/oidc/token"


{"access_token":"eyJraWQiOiIyMDE3MDUxNS0wMDowMDowMCIsImFsZyI6IlJTMjU2In0.eyJpYW1faWQi OiJpYW0tU2VydmljZUlkLTYzZjZiMjZmLTE1NjgtNGUzZS1iODhjLTc3ODA5Y2VhOGM4ZiIsImlkIjoiaWFtL VNlcnZpY2VJZC02M2Y2YjI2Zi0xNTY4LTRlM2UtYjg4Yy03NzgwOWNlYThjOGYiLCJyZWFsbWlkIjoiaWFtIi wic3ViX3R5cGUiOiJTZXJ2aWNlSWQiLCJpYXQiOjE1MjU3NzMyNzQsImV4cCI6MTUyNTg1OTY3NCwiaXNzIjo iaHR0cHM6Ly9sb2NhbGhvc3Q6MTA0NDMvb2lkYy90b2tlbiIsImdyYW50X3R5cGUiOiJ1cm46aWJtOnBhcmFt czpvYXV0aDpncmFudC10eXBlOmFwaWtleSIsInNjb3BlIjoib3BlbmlkIiwiY2xpZW50X2lkIjoiZGVmYXVsd CJ9.Lq68chxg3R7pNbq9Tqd7AUfGYK3Xl8Ec-g6E5oFxgDRKGy3Q-coFNf2X5IDFBqkoX3RqIPdB1gx8oNt2P cf8vrxnfZCymo949kRtz1fgwUqs7JAtC6etvT54i-Cd_i-M8_2zXI8j0jXeRc58i30bSg34gEHZFikgGuGa3m J_hxLYUUhtHzN4E_OS578WpQ7GfDkNCSv5aaYSA1fQIwMfF76cTcB8Cb_9d9oUAFyVe5CRGicLuGtULnckVy2


aWLdjM_txu8p7NF_Y5EbD-0plHfrsqpE877jhgTkbtP_p3aBR028q8j8X-a_S5NnIOKsAbAAX_8jIMCBYNRJQ nXU5Uw","token_type":"Bearer","expires_in":86400,"expiration":1525859674}

サービス・ポリシー管理 API

サービス・ポリシーを管理するための API。

基本パス: https://<cluster_lb_address>:8443/iam-pap/acms/v1/

すべてのシステム定義の役割に関する情報の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/iam-pap/acms/v1/roles

コマンド

GET


application/json


curl -k -X GET -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/iam-pap/acms/v1/roles"


{"systemDefinedRoles":[{"crn":"crn:v1:icp:private:iam::::role:Viewer","displayName":" Viewer","description":"Viewers can take actions that do not change state (i.e. read o nly)."},{"crn":"crn:v1:icp:private:iam::::role:ClusterAdministrator","displayName":"C lusterAdministrator","description":"ClusterAdministrators can take all actions includ ing the ability to manage access control."},{"crn":"crn:v1:icp:private:iam::::role:Ad ministrator","displayName":"Administrator","description":"Administrators can take all actions including the ability to manage access control."},{"crn":"crn:v1:icp:private :iam::::role:Editor","displayName":"Editor","description":"Editors can take actions t hat can modify the state and create/delete sub-resources."},{"crn":"crn:v1:icp:privat e:iam::::role:Operator","displayName":"Operator","description":"Operators can take ac tions required to configure and operate resources."}]}

すべての登録済みサービスに関する情報の取得

API バージョン


1.0.0API URI コンポーネント

スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/iam-pap/acms/v1/services?fields={フィールド名}

コマンド

GET


application/json


curl -k -X GET -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/iam-pap/acms/v1/services?fields=name"


{"services":[{"_id":"5aeac66bdc2c4100c82016ba","name":"helm-api-service","enabled":tr ue,"platformExtenstions":{"supportedAttributes":[{"key":"accountId"},{"key":"serviceN ame"}],"supportedRoles":[{"id":"crn:v1:icp:private:iam::::role:Administrator"},{"id": "crn:v1:icp:private:iam::::role:ClusterAdministrator"},{"id":"crn:v1:icp:private:iam: :::role:Operator"},{"id":"crn:v1:icp:private:iam::::role:Viewer"},{"id":"crn:v1:icp:p rivate:iam::::role:Editor"}]},"actions":[],"supportedRoles":[]},{"_id":"5aeac677dc2c4 100c82016bb","name":"elasticsearch-service","enabled":true,"platformExtenstions":{"su pportedAttributes":[{"key":"accountId"},{"key":"serviceName"}],"supportedRoles":[{"id ":"crn:v1:icp:private:iam::::role:Administrator"},{"id":"crn:v1:icp:private:iam::::ro le:ClusterAdministrator"},{"id":"crn:v1:icp:private:iam::::role:Operator"},{"id":"crn :v1:icp:private:iam::::role:Viewer"},{"id":"crn:v1:icp:private:iam::::role:Editor"}]} ,"actions":[],"supportedRoles":[]},{"_id":"5aeac678dc2c4100c82016bc","name":"servicemonitoring- service","enabled":true,"platformExtenstions":{"supportedAttributes":[{"ke y":"accountId"},{"key":"serviceName"}],"supportedRoles":[{"id":"crn:v1:icp:private:ia m::::role:Administrator"},{"id":"crn:v1:icp:private:iam::::role:ClusterAdministrator" },{"id":"crn:v1:icp:private:iam::::role:Operator"},{"id":"crn:v1:icp:private:iam::::r ole:Viewer"},{"id":"crn:v1:icp:private:iam::::role:Editor"}]},"actions":[],"supported Roles":[]},{"_id":"5af03e6b078693000abde634","name":"idmgmt","enabled":true,"platform Extenstions":{"supportedAttributes":[{"key":"accountId"},{"key":"serviceName"}],"supp ortedRoles":[{"id":"crn:v1:icp:private:iam::::role:Administrator"},{"id":"crn:v1:icp: private:iam::::role:ClusterAdministrator"},{"id":"crn:v1:icp:private:iam::::role:Oper ator"},{"id":"crn:v1:icp:private:iam::::role:Viewer"},{"id":"crn:v1:icp:private:iam:: ::role:Editor"}]},"actions":[],"supportedRoles":[]},{"_id":"5af03e6b078693000abde635" ,"name":"idprovider","enabled":true,"platformExtenstions":{"supportedAttributes":[{"k ey":"accountId"},{"key":"serviceName"}],"supportedRoles":[{"id":"crn:v1:icp:private:i am::::role:Administrator"},{"id":"crn:v1:icp:private:iam::::role:ClusterAdministrator "},{"id":"crn:v1:icp:private:iam::::role:Operator"},{"id":"crn:v1:icp:private:iam:::: role:Viewer"},{"id":"crn:v1:icp:private:iam::::role:Editor"}]},"actions":[],"supporte dRoles":[]},{"_id":"5af03e6b078693000abde636","name":"idauth","enabled":true,"platfor mExtenstions":{"supportedAttributes":[{"key":"accountId"},{"key":"serviceName"}],"sup portedRoles":[{"id":"crn:v1:icp:private:iam::::role:Administrator"},{"id":"crn:v1:icp


:private:iam::::role:ClusterAdministrator"},{"id":"crn:v1:icp:private:iam::::role:Ope rator"},{"id":"crn:v1:icp:private:iam::::role:Viewer"},{"id":"crn:v1:icp:private:iam: :::role:Editor"}]},"actions":[],"supportedRoles":[]},{"_id":"5af03e6b078693000abde637 ","name":"identity","enabled":true,"platformExtenstions":{"supportedAttributes":[{"ke y":"accountId"},{"key":"serviceName"}],"supportedRoles":[{"id":"crn:v1:icp:private:ia m::::role:Administrator"},{"id":"crn:v1:icp:private:iam::::role:ClusterAdministrator" },{"id":"crn:v1:icp:private:iam::::role:Operator"},{"id":"crn:v1:icp:private:iam::::r ole:Viewer"},{"id":"crn:v1:icp:private:iam::::role:Editor"}]},"actions":[],"supported Roles":[]}]}

サービス ID およびスコープに割り当てられたポリシーに関する情報の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/iam-pap/acms/v1/scopes/{スコープ}/service_ids/{サービス ID}/policies

コマンド

GET


application/json


curl -k -X GET -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/iam-pap/acms/v1/scopes/n%252Fkube-system/service_ids/iam-ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f/policies"


{"policies":[{"id":"14cbbc3f-077d-439d-9a24-6fe39263e0ab","roles":[{"id":"crn:v1:icp: private:iam::::role:Administrator","displayName":"Administrator","description":"Admin istrators can take all actions including the ability to manage access control."},{"id ":"crn:v1:icp:private:iam::::role:Operator","displayName":"Operator","description":"O perators can take actions required to configure and operate resources."}],"resources" :[{"namespaceId":"kube-system","serviceName":"idmgmt"}],"links":{"href":"https://9.37 .239.107:8443/acms/v1/scopes/n%252Fkube-system/service_ids/iam-ServiceId-63f6b26f-156 8-4e3e-b88c-77809cea8c8f/policies/14cbbc3f-077d-439d-9a24-6fe39263e0ab","link":"self" }}]}

サービス ID のアクセス・ポリシーの作成




スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス

/iam-pap/acms/v1/scopes/{スコープ}/service_ids/{サービス ID}/policies

コマンド

POST


application/json


curl -k -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" -d '{"resources": [{"namespaceId": "kube-system","serviceName": "idmgmt"}],"roles": [{"id": "crn:v1:icp:private:iam::::role:Administrator"},{"id": "crn:v1:icp:private:iam::::role:Editor" }]}' "https://<cluster_lb_address>:8443/iam-pap/acms/v1/scopes/n%252Fkube-system/service_ids/iam-ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f/policies"


{"id":"14cbbc3f-077d-439d-9a24-6fe39263e0ab","roles":[{"id":"crn:v1:icp:private:iam:: ::role:Administrator","displayName":"Administrator","description":"Administrators can take all actions including the ability to manage access control."},{"id":"crn:v1:icp :private:iam::::role:Editor","displayName":"Editor","description":"Editors can take a ctions that can modify the state and create/delete sub-resources."}],"resources":[{"n amespaceId":"kube-system","serviceName":"idmgmt"}],"links":{"href":"https://9.37.239. 107:8443/acms/v1/scopes/n%252Fkube-system/service_ids/iam-ServiceId-63f6b26f-1568-4e3 e-b88c-77809cea8c8f/policies/14cbbc3f-077d-439d-9a24-6fe39263e0ab","link":"self"}}

特定のサービスに割り当てられたアクセス・ポリシーに関する情報の取得



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス


/iam-pap/acms/v1/scopes/{スコープ}/service_ids/{サービス ID}/policies/{ポリシー ID}

コマンド

GET


application/json


curl -k -X GET -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/iam-pap/acms/v1/scopes/n%252Fkube-system/service_ids/iam-ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f/policies/14cbbc3f-077d-439d-9a24-6fe39263e0ab"


{"id":"14cbbc3f-077d-439d-9a24-6fe39263e0ab","roles":[{"id":"crn:v1:icp:private:iam:: ::role:Administrator","displayName":"Administrator","description":"Administrators can take all actions including the ability to manage access control."},{"id":"crn:v1:icp :private:iam::::role:Operator","displayName":"Operator","description":"Operators can take actions required to configure and operate resources."}],"resources":[{"namespace Id":"kube-system","serviceName":"idmgmt"}],"links":{"href":"https://9.37.239.107:8443 /acms/v1/scopes/n%252Fkube-system/service_ids/iam-ServiceId-63f6b26f-1568-4e3e-b88c-7 7809cea8c8f/policies/14cbbc3f-077d-439d-9a24-6fe39263e0ab","link":"self"}}

特定のサービスに割り当てられたアクセス・ポリシーの更新



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス


コマンド

PUT


application/json


curl -k -X PUT -H "Content-Type: application/json" -H "Accept: application/json" -H " Authorization: Bearer $ACCESS_TOKEN" -d '{"resources": [{"namespaceId": "kube-system","serviceName": "idmgmt"}],"roles": [{"id": "crn:v1:icp:private:iam::::role:Administrator"


},{"id": "crn:v1:icp:private:iam::::role:Operator"}]}' "https://<cluster_lb_address>:8443/iam-pap/acms/v1/scopes/n%252Fkube-system/service_ids/iam-ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f/policies/14cbbc3f-077d-439d-9a24-6fe39263e0ab"


{"id":"14cbbc3f-077d-439d-9a24-6fe39263e0ab","roles":[{"id":"crn:v1:icp:private:iam:: ::role:Administrator","displayName":"Administrator","description":"Administrators can take all actions including the ability to manage access control."},{"id":"crn:v1:icp :private:iam::::role:Operator","displayName":"Operator","description":"Operators can take actions required to configure and operate resources."}],"resources":[{"namespace Id":"kube-system","serviceName":"idmgmt"}],"links":{"href":"https://9.37.239.107:8443 /acms/v1/scopes/n%252Fkube-system/service_ids/iam-ServiceId-63f6b26f-1568-4e3e-b88c-7 7809cea8c8f/policies/14cbbc3f-077d-439d-9a24-6fe39263e0ab/14cbbc3f-077d-439d-9a24-6fe 39263e0ab","link":"self"}}

特定のサービスに割り当てられたアクセス・ポリシーの削除



スキーム

HTTPS

ホスト IP

cluster_lb_address

ポート番号

8443

パス


コマンド

DELETE


application/json


curl -k -X DELETE -H "Accept: application/json" -H "Authorization: Bearer $ACCESS_TOKEN" "https://<cluster_lb_address>:8443/iam-pap/acms/v1/scopes/n%252Fkube-system/service_ids/iam-ServiceId-63f6b26f-1568-4e3e-b88c-77809cea8c8f/policies/14cbbc3f-077d-439d-9a24-6fe39263e0ab"



イメージ管理 API

イメージ管理 API コマンドは、イメージ・レジストリー内のイメージをリスト、更新、および削除します。


クラスター管理者と管理者のどちらも、すべてのリソースについてすべてのイメージ管理 API コマンドにアクセスできます。

これらの API を使⽤するには、許可ヘッダーを要求に追加する必要があります。『コンポーネント API コマンドまたは管理 API コマンドを実⾏するための準備』を参照してください。

例:

# curl --cacert /<certificate_path>/ca.crt -s -H "Authorization: Bearer $ID_TOKEN" https://<cluster_CA_domain>:8443/image-manager/api/v1


<certificate_path> は、コンピューター上の ca.crt の場所です。

$ID_TOKEN は、クラスターの識別トークンを保管している変数です。

<cluster_CA_domain> は、インストール時に config.yaml ファイルに設定された認証局 (CA) ドメインです。

CA ドメインを設定していない場合、⾮セキュア接続を使⽤して要求を続⾏できます。

例:

# curl -k -H "Authorization: Bearer $ID_TOKEN" https://<cluster_lb_address>:8443/image-manager/api/v1

ここで、<cluster_lb_address> は、クラスター内の管理サービスのパブリックまたは外部の IP アドレスです。

イメージ管理 API のデータ

API バージョン2.1.0.3


スキーム

HTTPS

ホスト名

cluster_name または cluster_lb_address

ポート番号

8443

基本パス

/image-manager/api/v1


application/json

リポジトリーの削除 JWT トークンの取得エンドポイントのリスト表⽰リポジトリーのリスト表⽰指定したリポジトリーのリスト表⽰


リポジトリーのメタデータの更新

リポジトリーの削除

プライベート・イメージ・レジストリーから特定のリポジトリーを削除します。

基本パス: https://<cluster_lb_address>:8443/image-manager/api/v1/repositories/<repo>

ここで、repo は、名前空間を含むリポジトリー・イメージの完全な名前です。例えば、default/alpine です。プライベート・イメージ・レジストリーでは、同じ名前が割り当てられているイメージ⽤の個別のリポジトリーが作

成されます。イメージ・リポジトリーを削除すると、そのリポジトリー内のすべてのイメージが削除されます。リポジトリー内の特定のイメージを削除することはできません。

例えば、mycluster.icp:8500/default/nginx:1.9.1 は、mycluster.icp:8500/default/nginx リポジトリー内のイメージです。

リポジトリーを削除した後に、レジストリー・ストレージから関連ファイルを削除できます。『プライベート・レジストリー・ストレージからイメージ・ファイルを削除』を参照してください。



スキーム

HTTPS

ホスト名


ポート番号

8443

基本パス

/image-manager/api/v1/repositories/{namespace}/{repo}

コマンド

DELETE


application/json


curl -X DELETE -H "Authorization:Bearer $ID_TOKEN" https://<cluster_lb_address>:8443/image-manager/api/v1/repositories/<repo> --insecure

コマンドでは、メッセージは返されません。

root@master:~# curl -X DELETE -H "Authorization: Bearer $ID_TOKEN" https://9.37.142.86:8443/image-manager/api/v1/repositories/default/alpine --insecure

パラメーター

表 1. リポジトリーの削除に使⽤するパラメーター


タイプ名前説明スキーマデフォルト必須タイプ名前説明スキーマデフォルト必須

パス namespaceリポジトリーがある名前空間ストリングはい

パス repo:.* リポジトリーの名前ストリングはい

応答

表 2. リポジトリーの削除時に返される応答

HTTP コード説明スキーマ

200 OK コンテンツなし

JWT トークンの取得

Docker クライアントで使⽤する JWT トークンを取得します。

基本パス: https://<cluster_lb_address>:8443/image-manager/api/v1/auth/token



スキーム

HTTPS

ホスト名


ポート番号

8443

基本パス

/image-manager/api/v1/auth/token

コマンド

GET


application/json


curl -k -H GET --header "Authorization: Bearer $ID_TOKEN" https://<cluster_lb_address>:8443/image-manager/api/v1/auth/token


root@master:~# curl -k -H GET --header "Authorization: Bearer $ID_TOKEN" https://9.37.204.198:8443/image-manager/api/v1/auth/token {"expires_in":1800,"issued_at":"2017-11-30T05:24:21Z","token":\ "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjZMUDY6SFFJUjozVkg0OlZIUUk6TTRNMjpMSEFWOldGS0M6Mk9aQTpSTjRMOlQ3UUs6RzVLUTpKNkg1In0.eyJpc3MiOiJyZWdpc3RyeS10b2tlbi1pc3N1ZXIiLCJzdWIiOiIiLCJhdWQiOiIiLCJleHAiOjE1MTIwMjEyNjEsIm5iZiI6MTUxMjAxOTQ2MSwiaWF0IjoxNTEyMDE5NDYxLCJqdG


kiOiJsYzVkRzVPVTI0anhjemVLIiwiYWNjZXNzIjpudWxsfQ.F2D6VjwhQRlRvU-da2zHDzDbck8avh1lxc8B4hAVrIhEY8orcqwYhocjxnFk3kXdNm3yihMwi17lYySEnet3_p7jWOJ0XGTF6_m7DeUsNd-YqtGGv7FTycTG_10Xnm7zuknBhpsbMx_Eq4gKRBM1ndwdkhhOLG135r97BbTcT_GlHcnmyKfFLXfmhVgiAhBeTn1_phmSO-Olys0bhbKl2M_jIiCGLwleKQpa3dFsJ3JsYGSQcB7dEVZuSAmzc3OmlYXmvl8oCnjyM-RIkQk8-uGkI_7cjhXOY8rORGMgp0r6f8LXky5K_XH1mIG7BARKr1E-9SKyyIGwRWMUIs3fwA"}

応答

表 1. JWT トークンの取得時に返される応答



エンドポイントのリスト表⽰

使⽤可能なエンドポイントをリストします。

基本パス: https://<cluster_lb_address>:8443/image-manager/api/v1



スキーム

HTTPS

ホスト名


ポート番号

8443

基本パス

/image-manager/api/v1

コマンド

GET


application/json


curl -k -H GET --header "Authorization: Bearer $ID_TOKEN" https://<cluster_lb_address>:8443/image-manager/api/v1


root@master:~# curl -k -X GET --header "Authorization: Bearer $ID_TOKEN" https://9.37.204.198:8443/image-manager/api/v1 IBM Cloud Private Image Management API. The listener is working. Now try a valid endpoint Available APIs:


GET / GET /image-manager/api/v1 GET /image-manager/api/v1/auth/token GET /image-manager/api/v1/repositories GET /image-manager/api/v1/repositories/{repo:.*} PUT /image-manager/api/v1/repositories/{repo:.*} DELETE /image-manager/api/v1/repositories/{repo:.*}

応答

表 1. エンドポイントをリストしたときに返される応答



リポジトリーのリスト表⽰

プライベート・イメージ・レジストリー内のすべてのリポジトリーをリストします。

プライベート・イメージ・レジストリーでは、同じ名前が割り当てられているイメージ⽤の個別のリポジトリーが作

成されます。

基本パス: https://<cluster_lb_address>:8443/image-manager/api/v1/repositories



スキーム

HTTPS

ホスト名


ポート番号

8443

基本パス

/image-manager/api/v1/repositories

コマンド

GET


application/json


curl -k -H GET --header "Authorization: Bearer $ID_TOKEN" https://<cluster_lb_address>:8443/image-manager/api/v1/repositories --insecure

サンプル応答は、以下のコードのようになります。


root@master:~# curl -k -H GET --header "Authorization: Bearer $ID_TOKEN" https://9.37.142.86:8443/image-manager/api/v1/repositories {"repositories":[{"name":"default/alpine","owner":"default","scope":"global","tags":\ [{"name":"3.6","manifest":{"schemaVersion":2,"mediaType":"application/ vnd.docker.distribution.manifest.v2+json",\ "config":{"mediaType":"application/vnd.docker.container.image.v1\ +json","size":1512,"digest":\ "sha256:053cde6e8953ebd834df8f6382e68be83adb39bfc063e40b0fc61b4b333938f1"},"layers":[{"mediaType":"application/\ vnd.docker.image.rootfs.diff.tar.gzip","size":1991435,"digest":\ "sha256:b56ae66c29370df48e7377c8f9baa744a3958058a766793f821dadcb144a4647"}]}}]},{"name":"default/alpine-ppc64le","owner":"default","scope":"namespace","tags":[{"name":"3.6","manifest":\ {"schemaVersion":2,"mediaType":"application/vnd.docker.distribution.manifest.v2+json",\ "config":{"mediaType":"application/vnd.docker.container.image.v1 +json","size":1760,"digest":\ "sha256:daa414b19dcffa0ba7b80abb50a6b31156f1efd7bb1b8cdaeeb848da367afa38"},"layers":[{"mediaType":"application/\ vnd.docker.image.rootfs.diff.tar.gzip","size":2008578,\ "digest":"sha256:1e52418956f7d2a8ea35e8e6e3318fd08e005b27457d77868c225e7433bbfa02"},{"mediaType":"application/\ vnd.docker.image.rootfs.diff.tar.gzip","size":176,\ "digest":"sha256:acf472f4e5bb7956ac20bb343b304e1d3de1f79160c0d158cccbe25980022d50"}]}}]},{"name":"default/alpine-s390x","owner":"default","scope":"namespace","tags":[{"name":"3.6","manifest":{"schemaVersion":2,"mediaType":"application/vnd.docker.distribution.manifest.v2+json","config":{"mediaType":\ "application/vnd.docker.container.image.v1 +json","size":1758,"digest":\ "sha256:f7d8089567d12668e7f0d27e18b87abb38013f1b221b37ff7158fce2cbc3d792"},"layers":[{"mediaType":"application/\ vnd.docker.image.rootfs.diff.tar.gzip","size":2109387,\ "digest":"sha256:22a16c518b849c1025d3475ee9310b25eaf5ec70f10d657ac7a322323f14873a"},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","size":176,\ "digest":"sha256:0e5978b6b34b3e943e0fd25dfb50991c0bad82a986cfdaa91c4de756431ba679"}]}}]}]}root@master:~#

応答

表 1. すべてのリポジトリーをリストしたときに返される

応答



指定したリポジトリーのリスト表⽰

特定のリポジトリーに関する詳細を取得します。


ここで、repo は、タグを含むイメージの名前です。例えば、イメージ mycluster.icp:8500/default/tomcatをイメージ・レジストリーにプッシュした場合、default/tomcat がリポジトリーの名前です。



スキーム


HTTPS

ホスト名


ポート番号

8443

基本パス


コマンド

GET


application/json


curl -k -H GET --header "Authorization: Bearer $ID_TOKEN" https://<cluster_lb_address>:8443/image-manager/api/v1/repositories/<repo> --insecure


root@master:~# curl -k -H GET --header "Authorization: Bearer $ID_TOKEN" https://9.37.142.86:8443/image-manager/api/v1/repositories/default/alpine --insecure {"name":"default/alpine","owner":"default","scope":"global","tags":\ [{"name":"3.6","manifest":{"schemaVersion":2,"mediaType":"application/\ vnd.docker.distribution.manifest.v2+json","config":{"mediaType":"application/\ vnd.docker.container.image.v1+json","size":1512,"digest":\ "sha256:053cde6e8953ebd834df8f6382e68be83adb39bfc063e40b0fc61b4b333938f1"},"layers":[{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","size":1991435,\ "digest":"sha256:b56ae66c29370df48e7377c8f9baa744a3958058a766793f821dadcb144a4647"}]}}]}root@master:~#

パラメーター

表 1. 特定のリポジトリーをリストするために使⽤するパラメーター

タイプ名前説明スキーマデフォルト必須

パス namespaceリポジトリーがある名前空間ストリングはい

本⽂ repo:.* リポジトリーの名前ストリングはい

応答

表 2. 特定のリポジトリーをリストしたときに返される応答


200 作成成功コンテンツなし

リポジトリーのメタデータの更新


リポジトリーのメタデータを更新します。


ここで、repo は、タグを含むイメージの名前です。例えば、イメージ mycluster.icp:8500/default/tomcatをイメージ・レジストリーにプッシュした場合、default/tomcat がリポジトリーの名前です。



スキーム

HTTPS

ホスト名


ポート番号

8443

基本パス


コマンド

PUT


application/json


curl -X PUT -d '{"scope": "global"}' -H "Authorization: Bearer $ID_TOKEN" https://<cluster_lb_address>:8443/image-manager/api/v1/repositories/<repo> --insecure


curl -X PUT -d '{"scope": "global"}' -H "Authorization:Bearer $ID_TOKEN" https://9.21.58.24:8443/image-manager/api/v1/repositories/default/cam-broker --insecure OK

パラメーター

表 1. リポジトリーの更新に使⽤するパラメータータ

イ

プ

名前説明スキー

マ

デフォ

ルト

必

須

本

⽂

"scope":

グローバル・レベルまたは名前空間レベルでリポジトリーのイメージを更新しま

す。値:「global」または「namespace」ストリ

ング

は

い

本

⽂

namespace

リポジトリーがある名前空間ストリ

ング

は

い

本

⽂

repo:.* リポジトリーの名前ストリ

ング

は

い


応答

表 2. リポジトリーのメタデータの更新時に返される応答



脆弱性アドバイザー API

脆弱性アドバイザー API コマンドを使⽤して、セキュリティー・レポートを管理できます。

クラスター管理者と管理者のどちらも、すべてのリソースについてすべての脆弱性アドバイザー API コマンドにアクセスできます。

また、IBM Cloud Private management console (https://<master_ip>:8443/va/ui/api-docs/index.html)で、脆弱性アドバイザー・コンポーネントの swagger API 資料にアクセスすることもできます。ここで、<master_ip> は、クラスター内のマスター・ホストの IP アドレスです。

コマンド・ラインからこれらの API にアクセスするには、許可ヘッダーを要求に追加する必要があります。『コンポーネント API コマンドまたは管理 API コマンドを実⾏するための準備』を参照してください。

例:

# curl -k -s -XGET -H "Authorization: Bearer $ID_TOKEN" https://<master_ip>:8443/va/api

ここで、$ID_TOKEN はクラスターの識別トークンを保管している変数であり、<master_ip> はクラスター内のマスター・ホストの IP アドレスです。

脆弱性アドバイザー API データ



スキーム

HTTPS

ホスト名

master_ip_address

ポート番号

8443

基本パス

/va/api


application/json

名前空間の取得



curl -k -s -XGET -H "Authorization: Bearer $ID_TOKEN" https://<master_ip>:8443/va/api/get-namespaces?access_group=kube-system&max=3' | jq .


{ "result": [ { "namespace": "kube-system/va-annotator-74c4c9bb96-8pbg9/va-annotator/e84dbbbca7af7c6ca3555620ca4ffc80d23c668221321098968cc759741ebaea", "source_type": "container", "timestamp": "2018-04-27T10:59:59+0000" }, { "namespace": "kube-system/filebeat-ds-amd64-9s4zv/POD/6bcc7bb988f449586eaa5c45289e1f1f67af2b2ad68f4c2bc60e1944aca93e47", "source_type": "container", "timestamp": "2018-04-27T06:53:09+0000" } }

get-snapshot-timestamps


curl -k -s -XGET -H "Authorization: Bearer $ID_TOKEN" https://<master_ip>:8443/va/api/get-snapshot-timestamps?access_group=kube-system&namespace=kube-system/elasticsearch-client-6c9fc8b5b6-dvztg/POD/d228119a35ab6ff158b3903cf24b3c014ad3809748485b1c6008d00baf1d6487' | jq ..


{ "result": [ "2018-04-27T06:52:23+0000", "2018-04-26T06:52:32+0000", "2018-04-25T06:54:12+0000", "2018-04-24T06:53:22+0000", ], "request_id": "66c4e381-0cc9-4f63-8ca5-aac81400ac8d" }

get-report


curl -k -s -XGET -H "Authorization: Bearer $ID_TOKEN" https://9.59.150.3:8443/va/api/get-report?access_group=kube-system&namespace=kube-system/elasticsearch-client-6c9fc8b5b6-dvztg/POD/d228119a35ab6ff158b3903cf24b3c014ad3809748485b1c6008d00baf1d6487&timestamp=2018-04-10T06%3A53%3A27%2B0000&report_type=compliance' | jq .


{ "result": { "compliance": { "statusCode": 200, "body": { "total": 27, "compliant": 23, "non_compliant": 4, "custom": 0, "crawled_time": "2018-04-10T06:53:27+0000",


"details": [ { "compliance_id": "Linux.1-1-a", "compliant": "false", "compliance_check_time": "2018-04-10T06:53:30.639238Z", "reason": "File /etc/passwd not found", "description": "Each UID must be used only once.", "rule_type": "default" }, { .............

ライセンス交付

IBM® Cloud Private では、現在の使⽤法がライセンス資格レベル内にあるかどうかを判別するため、および、潜在的なライセンス違反を防⽌するために、ライセンス監査がデフォルトで有効になります。

ライセンス交付⽬的のため、IBM Cloud Private は Virtual Processing Core (VPC) 当たりで価格設定されています。

ライセンス要件に準拠しているかどうかの査定を⽀援するため、IBM® License Metric Tool (ILMT) が使⽤されます。ILMT は、仮想化環境の管理およびライセンス使⽤の計測のための有⽤な機能を備えています。 ILMT は、ユーザーのインフラストラクチャーにインストールされたソフトウェアを検出し、使⽤量データの分析を⽀援し、監査レポート

の⽣成を可能にします。各レポートは、コンピューター・グループ、ソフトウェア・インストール、ソフトウェア・カタログの内容など、インフラストラクチャーに関するさまざまな情報を提供します。

ILMT を使⽤して VPC 使⽤量を判別できます。 Determining the usage of Virtual Processor Cores (VPC) を参照してください。

デフォルトでは、すべての ILMT 監査レポートで直近 90 ⽇間のデータが⽰されます。レポートに表⽰される情報のタイプと量をフィルターを使⽤してカスタマイズでき、将来の使⽤のために個⼈⽤設定を保存することができます。

レポートを .csv または .pdf 形式にエクスポートすることもでき、また、重要なイベントが発⽣したときに指定宛先に通知されるようにレポートの E メール送信をスケジュールすることもできます。詳しくは、IBM KnowledgeCenter の IBM License Metric Tool を参照してください。

IBM Cloud Private 計量サービスを使⽤して、ライセンス使⽤法を検討することもできます。 IBM Cloud Private 計量サービスを参照してください。


https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20License%20Metric%20Tool/page/Determining%20the%20usage%20of%20Virtual%20Processor%20Cores%20%28VPC%29

https://www.ibm.com/support/knowledgecenter/en/SS8JFY_9.2.0/com.ibm.lmt.doc/Inventory/ic-homepage_lmt.html

Documents

· Ïm IBM® Cloud Private 2.1.0.3 IBM® Cloud Private ß +'CZ6 l{Ê ZZl)k>l8 l{Ê Ðlß DÙ B 6 >](lkG\CUl Cöß Y)/l (E 7\l'Wc) ß E 7\l'Wcéß Y)/lß 5 E 7\l'Wc¼úß Y)/lß