openshift container platform 3.11 クラスター管理...3.5.2. etcd v3...

OpenShift Container Platform 3.11

クラスター管理

OpenShift Container Platform 3.11 クラスター管理

Last Updated: 2020-11-12

法律上の通知法律上の通知

Copyright © 2020 Red Hat, Inc.

The text of and illustrations in this document are licensed by Red Hat under a Creative CommonsAttribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA isavailable athttp://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you mustprovide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift,Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United Statesand other countries.

Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.

Java ® is a registered trademark of Oracle and/or its affiliates.

XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United Statesand/or other countries.

MySQL ® is a registered trademark of MySQL AB in the United States, the European Union andother countries.

Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by theofficial Joyent Node.js open source or commercial project.

The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marksor trademarks/service marks of the OpenStack Foundation, in the United States and othercountries and are used with the OpenStack Foundation's permission. We are not affiliated with,endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

概要概要

『OpenShift クラスター管理』では、OpenShift クラスターを管理するための通常のタスクや他の詳細設定についてのトピックを扱います。

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

目次目次

第第1章章概要概要

第第2章章ノードの管理ノードの管理2.1. 概要2.2. ノードの一覧表示2.3. ノードの表示2.4. ホストの追加手順

2.5. ノードの削除2.6. ノードのラベルの更新2.7. ノード上の POD の一覧表示2.8. ノードをスケジュール対象外 (UNSCHEDULABLE) またはスケジュール対象 (SCHEDULABLE) としてマークする2.9. POD のノードからの退避2.10. ノードの再起動

2.10.1. インフラストラクチャーノード2.10.2. Pod の非アフィニティーの使用2.10.3. ルーターを実行するノードの処理

2.11. ノードの変更2.11.1. ノードリソースの設定2.11.2. ノードあたりの最大 Pod 数の設定

2.12. DOCKER ストレージの再設定

第第3章章 OPENSHIFT CONTAINER PLATFORM コンポーネントの復元コンポーネントの復元3.1. 概要3.2. クラスターの復元手順

3.3. マスターホストのバックアップの復元手順

3.4. ノードホストバックアップの復元手順

3.5. ETCD の復元3.5.1. etcd データの復元手順3.5.1.1. peerURLS パラメーターの修正

3.5.1.1.1. 手順3.5.2. etcd v3 スナップショットの復元手順

3.5.3. 静的 Pod での etcd の復元3.6. ETCD ノードの追加

3.6.1. Ansible を使用した新規 etcd ホストの追加手順

3.6.2. 新規 etcd ホストの手動による追加手順現在の etcd クラスターの変更新規 etcd ホストの変更各 OpenShift Container Platform マスターの変更

3.7. OPENSHIFT CONTAINER PLATFORM サービスの再オンライン化手順

3.8. プロジェクトの復元手順

3.9. アプリケーションデータの復元

14

151515181919212222

22232424252626282930

32323232323233343535353737373738393939404041

44454646474747

目次目次

1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

手順3.10. PERSISTENT VOLUME CLAIM (永続ボリューム要求、PVC) の復元

3.10.1. ファイルの既存 PVC への復元手順

3.10.2. データの新規 PVC への復元手順

第第4章章マスターホストの置き換えマスターホストの置き換え4.1. マスターホストの使用の終了手順

4.2. ホストの追加手順

4.3. ETCD のスケーリング前提条件4.3.1. Ansible を使用した新規 etcd ホストの追加手順


第第5章章ユーザーの管理ユーザーの管理5.1. 概要5.2. ユーザーの作成5.3. ユーザーおよび ID リストの表示5.4. グループの作成5.5. ユーザーおよびグループラベルの管理5.6. ユーザーの削除

第第6章章プロジェクトの管理プロジェクトの管理6.1. 概要6.2. プロジェクトのセルフプロビジョニング

6.2.1. 新規プロジェクトのテンプレートの変更6.2.2. セルフプロビジョニングの無効化

6.3. ノードセレクターの使用6.3.1. クラスター全体でのデフォルトノードセレクターの設定6.3.2. プロジェクト全体でのノードセレクターの設定6.3.3. 開発者が指定するノードセレクター

6.4. ユーザーあたりのセルフプロビジョニングされたプロジェクト数の制限6.5. サービスアカウント別のセルフプロビジョニングされたプロジェクトの有効化および制限

第第7章章 POD の管理の管理7.1. 概要7.2. POD の表示7.3. 1 回実行 (RUN-ONCE) POD 期間の制限

7.3.1. RunOnceDuration プラグインの設定7.3.2. プロジェクト別のカスタム期間の指定

7.3.2.1. Egress ルーター Pod のデプロイ7.3.2.2. Egress ルーターサービスのデプロイ

7.3.3. Egress ファイアウォールでの Pod アクセスの制限7.3.3.1. Pod アクセス制限の設定

7.4. POD で利用可能な帯域幅の制限7.5. POD の DISRUPTION BUDGET (停止状態の予算) の設定

484848484949

515151

53535556575758585861

63

65656565666767

6969696970717172737374

7676767676777779798081

82

OpenShift Container Platform 3.11 クラスター管理クラスター管理

2

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.6. CRITICAL POD の設定

第第8章章ネットワークの管理ネットワークの管理8.1. 概要8.2. POD ネットワークの管理

8.2.1. プロジェクトネットワークへの参加8.3. プロジェクトネットワークの分離

8.3.1. プロジェクトネットワークのグローバル化8.4. ルートおよび INGRESS オブジェクトにおけるホスト名の競合防止の無効化8.5. EGRESS トラフィックの制御8.6. 外部リソースへのアクセスを制限するための EGRESS ファイアウォールの使用

8.6.1. 外部リソースから Pod トラフィックを認識可能にするための Egress ルーターの使用8.6.1.1. リダイレクトモードでの Egress ルーター Pod のデプロイ8.6.1.2. 複数の宛先へのリダイレクト8.6.1.3. ConfigMap の使用による EGRESS_DESTINATION の指定8.6.1.4. Egress ルーター HTTP プロキシー Pod のデプロイ8.6.1.5. Egress ルーター HTTP プロキシー Pod のデプロイ8.6.1.6. Egress ルーター Pod のフェイルオーバーの有効化

8.6.2. 外部リソースへのアクセスを制限するための iptables ルールの使用8.7. 外部プロジェクトトラフィックの静的 IP の有効化8.8. 自動 EGRESS IP の有効化8.9. マルチキャストの有効化8.10. NETWORKPOLICY の有効化

8.10.1. NetworkPolicy の効率的な使用8.10.2. NetworkPolicy およびルーター8.10.3. 新規プロジェクトのデフォルト NetworkPolicy の設定

8.11. HTTP STRICT TRANSPORT SECURITY の有効化8.12. スループットの問題のトラブルシューティング

第第9章章サービスアカウントの設定サービスアカウントの設定9.1. 概要9.2. ユーザー名およびグループ9.3. サービスアカウントの管理9.4. サービスアカウント認証の有効化9.5. 管理サービスアカウント9.6. インフラストラクチャーサービスアカウント9.7. サービスアカウントおよびシークレット

第第10章章ロールベースアクセス制御ロールベースアクセス制御 (RBAC) の管理の管理10.1. 概要10.2. ロールとバインディングの表示

10.2.1. クラスターロールの表示10.2.2. クラスターのロールバインディングの表示10.2.3. ローカルのロールバインディングの表示

10.3. ロールバインディングの管理10.4. ローカルロールの作成10.5. クラスターロールの作成10.6. クラスターおよびローカルのロールバインディング10.7. ポリシー定義の更新

第第11章章イメージポリシーイメージポリシー11.1. 概要11.2. インポート用に許可されるレジストリーの設定11.3. IMAGEPOLICY 受付プラグインの設定

83

84848484848485868789909293949699

100100102103104106106107108109

111111111

112113113114114

115115115115119123124127127127128

130130130131

目次目次

3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11.4. 受付コントローラーを使用した ALWAYS PULL イメージの使用11.5. IMAGEPOLICY 受付プラグインのテスト

第第12章章イメージの署名イメージの署名12.1. 概要12.2. ATOMIC CLI を使用したイメージの署名12.3. OPENSHIFT CLI を使用したイメージ署名の検証12.4. レジストリー API の使用によるイメージ署名へのアクセス

12.4.1. API 経由でのイメージ署名の書き込み12.4.2. API 経由でのイメージ署名の読み取り12.4.3. 署名ストアからのイメージ署名の自動インポート

第第13章章スコープ付きトークンスコープ付きトークン13.1. 概要13.2. 評価13.3. ユーザースコープ13.4. ロールスコープ

第第14章章イメージのモニタリングイメージのモニタリング14.1. 概要14.2. イメージ統計の表示14.3. IMAGESTREAMS 統計の表示14.4. イメージのプルーニング

第第15章章 SCC (SECURITY CONTEXT CONSTRAINTS) の管理の管理15.1. 概要15.2. SCC (SECURITY CONTEXT CONSTRAINTS) の一覧表示15.3. SCC (SECURITY CONTEXT CONSTRAINTS) オブジェクトの検査15.4. 新規 SCC (SECURITY CONTEXT CONSTRAINTS) の作成15.5. SCC (SECURITY CONTEXT CONSTRAINTS) の削除15.6. SCC (SECURITY CONTEXT CONSTRAINTS) の更新

15.6.1. SCC (Security Context Constraints) 設定のサンプル15.7. デフォルト SCC (SECURITY CONTEXT CONSTRAINTS) の更新15.8. 使用方法

15.8.1. 特権付き SCC のアクセス付与15.8.2. 特権付き SCC のサービスアカウントアクセスの付与15.8.3. Dokerfile の USER によるイメージ実行の有効化15.8.4. ルートを要求するコンテナーイメージの有効化15.8.5. レジストリーでの --mount-host の使用15.8.6. 追加機能の提供15.8.7. クラスターのデフォルト動作の変更15.8.8. hostPath ボリュームプラグインの使用15.8.9. 受付を使用した特定 SCC の初回使用15.8.10. SCC のユーザー、グループまたはプロジェクトへの追加

第第16章章スケジューリングスケジューリング16.1. 概要

16.1.1. 概要16.1.2. デフォルトスケジューリング16.1.3. 詳細スケジューリング16.1.4. カスタムスケジューリング

16.2. デフォルトスケジューリング16.2.1. 概要16.2.2. 汎用スケジューラー

133134

136136136137138138139140

141141141141141

142142142142143

144144144144145146147147148148148149149150150150151151152152

153153153153153153153153153


4

16.2.3. ノードのフィルター16.2.3.1. フィルターされたノード一覧の優先順位付け16.2.3.2. 最適ノードの選択

16.2.4. スケジューラーポリシー16.2.4.1. スケジューラーポリシーの変更

16.2.5. 利用可能な述語16.2.5.1. 静的な述語

16.2.5.1.1. デフォルトの述語16.2.5.1.2. 他の静的な述語

16.2.5.2. 汎用的な述語汎用的な非クリティカル述語汎用的なクリティカル述語

16.2.5.3. 設定可能な述語16.2.6. 利用可能な優先度

16.2.6.1. 静的優先度16.2.6.1.1. デフォルトの優先度16.2.6.1.2. 他の静的優先度

16.2.6.2. 設定可能な優先度16.2.7. 使用例

16.2.7.1. インフラストラクチャーのトポロジーレベル16.2.7.2. アフィニティー16.2.7.3. 非アフィニティー

16.2.8. ポリシー設定のサンプル16.3. 再スケジュール (DESCHEDULING)

16.3.1. 概要16.3.2. クラスターロールの作成16.3.3. Descheduler ポリシーの作成

16.3.3.1. 重複 Pod の削除16.3.3.2. ノードの低使用率ポリシー (Low Node Utilization Policy) の作成16.3.3.3. Pod 間の非アフィニティー (Inter-Pod Anti-Affinity) に違反する Pod の削除

16.3.4. 設定マップでの Descheduler ポリシーの設定16.3.5. ジョブ仕様の作成16.3.6. Descheduler の実行

16.4. カスタムスケジューリング16.4.1. 概要16.4.2. スケジューラーをパッケージ化します。16.4.3. カスタムスケジューラーを使用した Pod のデプロイ

16.5. POD 配置の制御16.5.1. 概要16.5.2. ノード名の使用による Pod 配置の制約16.5.3. ノードセレクターの使用による Pod 配置の制約16.5.4. プロジェクト対する Pod 配置の制御

16.6. POD の優先順位とプリエンプション16.6.1. Pod の優先順位およびプリエンプションの適用16.6.2. Pod の優先順位について

16.6.2.1. Pod の優先順位クラス16.6.2.2. Pod の優先順位名

16.6.3. Pod プリエンプションについて16.6.3.1. Pod プリエンプションおよび他のスケジューラーの設定16.6.3.2. プリエンプションが実行された Pod の正常な終了

16.6.4. Pod の優先順位のシナリオ例16.6.5. 優先順位およびプリエンプションの設定16.6.6. 優先順位およびプリエンプションの無効化

154154154154156157157157158159159159159161161161

162163164165165165165168168169170171171172173173174174174174175177177177178179182182182182182183183184184184186

目次目次

5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16.7. 詳細スケジューリング16.7.1. 概要16.7.2. 詳細スケジューリングの使用

16.8. 詳細スケジューリングおよびノードのアフィニティー16.8.1. 概要16.8.2. ノードのアフィニティーの設定

16.8.2.1. ノードアフィニティーの required (必須) ルールの設定16.8.2.2. ノードアフィニティーの preferred (優先) ルールの設定

16.8.3. 例16.8.3.1. 一致するラベルを持つノードのアフィニティー16.8.3.2. 一致するラベルのないノードのアフィニティー

16.9. 詳細スケジューリングおよび POD のアフィニティーと非アフィニティー16.9.1. 概要16.9.2. Pod のアフィニティーおよび非アフィニティーの設定

16.9.2.1. アフィニティールールの設定16.9.2.2. 非アフィニティールールの設定

16.9.3. 例16.9.3.1. Pod のアフィニティー16.9.3.2. Pod の非アフィニティー16.9.3.3. 一致するラベルのない Pod のアフィニティー

16.10. 詳細スケジューリングおよびノードセレクター16.10.1. 概要16.10.2. ノードセレクターの設定

16.11. 詳細スケジューリングおよび容認16.11.1. 概要16.11.2. テイントおよび容認 (Toleration)

16.11.2.1. 複数テイントの使用16.11.3. テイントの既存ノードへの追加16.11.4. 容認の Pod への追加

16.11.4.1. Pod のエビクションを遅延させる容認期間 (秒数) の使用16.11.4.1.1. 容認の秒数のデフォルト値の設定

16.11.5. ノードの問題の発生時における Pod エビクション16.11.6. Daemonset および容認16.11.7. 例

16.11.7.1. ノードをユーザー専用にする16.11.7.2. ユーザーのノードへのバインド16.11.7.3. 特殊ハードウェアを持つノード

第第17章章クォータの設定クォータの設定17.1. 概要17.2. クォータで管理されるリソース

17.2.1. 拡張リソースのリソースクォータの設定17.3. クォータのスコープ17.4. クォータの実施17.5. 要求 VS 制限17.6. リソースクォータ定義のサンプル17.7. クォータの作成

17.7.1. オブジェクトカウントクォータの作成17.8. クォータの表示17.9. クォータの同期期間の設定17.10. デプロイメント設定におけるクォータアカウンティング17.11. リソース消費における明示的なクォータの要求17.12. 既知の問題

186186186187187188190191191191

192193193194195196197197198199

200200200201201201

203203204204205206207207207207208

209209209

211213214214214218218219219

220220221


6

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

第第18章章複数プロジェクトのクォータ設定複数プロジェクトのクォータ設定18.1. 概要18.2. プロジェクトの選択18.3. 適用可能な CLUSTERRESOURCEQUOTAS の表示18.4. 選択における粒度

第第19章章制限範囲の設定制限範囲の設定19.1. 概要

19.1.1. コンテナーの制限19.1.2. Pod の制限19.1.3. イメージの制限19.1.4. イメージストリームの制限

19.1.4.1. イメージ参照の数19.1.5. PersistentVolumeClaim の制限

19.2. 制限範囲の作成19.3. 制限の表示19.4. 制限の削除

第第20章章オブジェクトのプルーニングオブジェクトのプルーニング20.1. 概要20.2. プルーニングの基本操作20.3. グループのプルーニング20.4. デプロイメントのプルーニング20.5. ビルドのプルーニング20.6. イメージのプルーニング

20.6.1. イメージのプルーニングの各種条件20.6.2. セキュアまたは非セキュアな接続の使用20.6.3. イメージのプルーニングに関する問題イメージがプルーニングされない非セキュアなレジストリーに対するセキュアな接続の使用20.6.3.1. セキュリティーが保護されたレジストリーに対する非セキュアな接続の使用正しくない認証局の使用

20.7. レジストリーのハードプルーニング20.8. CRON ジョブのプルーニング

第第21章章カスタムリソースによるカスタムリソースによる KUBERNETES API の拡張の拡張21.1. KUBERNETES カスタムリソース定義21.2. カスタムリソース定義の作成手順

21.3. カスタムリソース定義のクラスターロールの作成前提条件手順

21.4. CRD からのカスタムオブジェクトの作成前提条件手順

21.5. カスタムオブジェクトの管理前提条件手順

第第22章章ガベージコレクションガベージコレクション22.1. 概要22.2. コンテナーのガベージコレクション

22.2.1. 削除するコンテナーの検出22.3. イメージのガベージコレクション

222222222223224

225225227228229229230230231231

232

233233233233234234235237239239239240240241241

244

245245245245247247247248248248249249249

251251251

252252

目次目次

7

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22.3.1. 削除するイメージの検出

第第23章章ノードリソースの割り当てノードリソースの割り当て23.1. 概要23.2. 割り当てられるリソースについてのノードの設定23.3. 割り当てられるリソースの計算23.4. ノードの割り当て可能なリソースおよび容量の表示23.5. ノードによって報告されるシステムリソース23.6. ノードの実施23.7. エビクションしきい値23.8. スケジューラー

第第24章章 NODE PROBLEM DETECTOR24.1. 概要24.2. NODE PROBLEM DETECTOR の出力サンプル24.3. NODE PROBLEM DETECTOR のインストール24.4. 検出された条件のカスタマイズ24.5. NODE PROBLEM DETECTOR が実行中であることの確認24.6. NODE PROBLEM DETECTOR のアンインストール

第第25章章オーバーコミットオーバーコミット25.1. 概要25.2. 要求および制限

25.2.1. Buffer Chunk Limit の調整25.3. コンピュートリソース

25.3.1. CPU25.3.2. メモリー25.3.3. 一時ストレージ

25.4. QOS (QUALITY OF SERVICE) クラス25.5. マスターでのオーバーコミットの設定25.6. ノードでのオーバーコミットの設定

25.6.1. Quality of Service (QoS) 層でのメモリー予約25.6.2. CPU 制限の実施25.6.3. システムリソースのリソース予約25.6.4. カーネルの調整可能なフラグ25.6.5. swap メモリーの無効化

第第26章章 INGRESS トラフィックの固有の外部トラフィックの固有の外部 IP の割り当ての割り当て26.1. 概要26.2. 制限26.3. 固有の外部 IP を使用するようクラスターを設定する

26.3.1. サービスの Ingress IP の設定26.4. 開発またはテスト目的での INGRESS CIDR のルーティング

26.4.1. サービス externalIP

第第27章章 OUT OF RESOURCE (リソース不足リソース不足) エラーの処理エラーの処理27.1. 概要27.2. エビクションポリシーの設定

27.2.1. ノード設定を使用したポリシーの作成27.2.2. エビクションシグナルについて27.2.3. エビクションのしきい値について

27.2.3.1. ハードエビクションのしきい値について27.2.3.1.1. デフォルトのハードエビクションしきい値

27.2.3.2. ソフトエビクションのしきい値について

253

254254254255255256257258259

260260261261262265265

267267267267268268268269269270271271

272272273274

275275275276276277277

279279279280281283284284285


8

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27.3. スケジューリング用のリソース量の設定27.4. ノードの状態変動の制御27.5. ノードレベルのリソースの回収

Imagefs が設定されている場合Imagefs が設定されていない場合

27.6. POD エビクションについて27.6.1. QoS および Out of Memory Killer について

27.7. POD スケジューラーおよび OOR 状態について27.8. シナリオ例27.9. 推奨される対策

27.9.1. DaemonSet および Out of Resource (リソース不足) の処理

第第28章章ルーターのモニタリングおよびデバッグルーターのモニタリングおよびデバッグ28.1. 概要28.2. 統計の表示28.3. 統計ビューの無効化28.4. ログの表示28.5. ルーター内部の表示

第第29章章高可用性高可用性29.1. 概要29.2. IP フェイルオーバーの設定

29.2.1. 仮想 IP アドレス29.2.2. チェックおよび通知スクリプト29.2.3. VRRP プリエンプション29.2.4. Keepalived マルチキャスト29.2.5. コマンドラインオプションおよび環境変数29.2.6. VRRP ID オフセット29.2.7. 254 を超えるアドレスについての IP フェイルオーバーの設定29.2.8. 高可用サービスの設定

29.2.8.1. IP フェイルオーバー Pod のデプロイ29.2.9. 高可用サービスの仮想 IP の動的更新

29.3. サービスの EXTERNALIP および NODEPORT の設定29.4. INGRESSIP の高可用性

第第30章章 IPTABLES30.1. 概要30.2. IPTABLES30.3. IPTABLES.SERVICE

第第31章章ストラテジーによるビルドのセキュリティー保護ストラテジーによるビルドのセキュリティー保護31.1. 概要31.2. ビルドストラテジーのグローバルな無効化31.3. ユーザーへのビルドストラテジーのグルーバルな制限31.4. プロジェクト内でのユーザーへのビルドストラテジーの制限

第第32章章 SECCOMP を使用したアプリケーション機能の制限を使用したアプリケーション機能の制限32.1. 概要32.2. SECCOMP の有効化32.3. OPENSHIFT CONTAINER PLATFORM での SECCOMP の設定32.4. OPENSHIFT CONTAINER PLATFORM でのカスタム SECCOMP プロファイルの設定

第第33章章 SYSCTL33.1. 概要33.2. SYSCTL について

285286287287287287288289289290290

291291291291291292

294294295296296298299300301301302304304305305

307307307307

309309309

311311

312312312312313

314314314

目次目次

9

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33.3. NAMESPACE を使用した SYSCTL VS ノードレベルの SYSCTL33.4. 安全 VS 安全でない SYSCTL33.5. 安全でない SYSCTL の有効化33.6. POD の SYSCTL 設定

第第34章章データストア層でのデータの暗号化データストア層でのデータの暗号化34.1. 概要34.2. 設定および暗号がすでに有効にされているかどうかの判別34.3. 暗号化設定について

34.3.1. 利用可能なプロバイダー34.4. データの暗号化34.5. データが暗号化されていることの確認34.6. すべてのシークレットが暗号化されていることの確認34.7. 復号化キーのローテーション34.8. データの復号化

第第35章章 IPSEC を使用したノード間のトラフィックの暗号化を使用したノード間のトラフィックの暗号化35.1. 概要35.2. ホストの暗号化前提条件35.2.1. 証明書での IPsec の設定35.2.2. libreswan IPsec ポリシーの作成

35.2.2.1. 便宜的なグループ (opportunistic group) の設定35.2.2.2. 明示的な接続の設定

35.3. IPSEC ファイアウォールの設定35.4. IPSEC の開始および終了35.5. IPSEC の最適化35.6. トラブルシューティング

第第36章章依存関係ツリーのビルド依存関係ツリーのビルド36.1. 概要36.2. 使用法

第第37章章失敗した失敗した ETCD メンバーの置き換えメンバーの置き換え37.1. 失敗した ETCD メンバーの削除手順

37.2. ETCD メンバーの追加37.2.1. Ansible を使用した新規 etcd ホストの追加手順


第第38章章 ETCD のクォーラムのクォーラム(定足数定足数) の復元の復元38.1. 複数サービスの ETCD クォーラム(定足数) の復元

38.1.1. etcd のバックアップ38.1.1.1. etcd 設定ファイルのバックアップ手順

38.1.1.2. etcd データのバックアップ前提条件手順

38.1.2. etcd ホストの削除

314315315317

319319319319

320321

322322323323

325325325325326327327328329329329330

331331331

332332332332332332333334334337339

340341341341341341341

342342


10

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

手順手順

38.1.3. 単一ノード etcd クラスターの作成手順

38.1.4. 復元後の etcd ノードの追加手順

38.2. 静的 POD の ETCD クォーラム(定足数) の復元手順

第第39章章 OPENSHIFT SDN のトラブルシューティングのトラブルシューティング39.1. 概要39.2. 用語39.3. HTTP サービスへの外部アクセスのデバッグ39.4. ルーターのデバッグ39.5. サービスのデバッグ39.6. ノード間通信のデバッグ39.7. ローカルネットワークのデバッグ

39.7.1. ノードのインターフェース39.7.2. ノード内の SDN フロー39.7.3. デバッグ手順

39.7.3.1. IP 転送は有効にされているか?39.7.3.2. ルートは正しく設定されているか?

39.7.4. Open vSwitch (OVS) は正しく設定されているか?39.7.4.1. iptables 設定に誤りがないか?39.7.4.2. 外部ネットワークは正しく設定されているか?

39.8. 仮想ネットワークのデバッグ39.8.1. 仮想ネットワークのビルドに障害が発生している

39.9. POD の EGRESS のデバッグ39.10. ログの読み取り39.11. KUBERNETES のデバッグ39.12. 診断ツールを使用したネットワークの問題の検出39.13. その他の注意点

39.13.1. ingress についての追加情報39.13.2. TLS ハンドシェイクのタイムアウト39.13.3. デバッグについての他の注意点

第第40章章診断ツール診断ツール40.1. 概要40.2. 診断ツールの使用40.3. サーバー環境における診断の実行40.4. クライアント環境での診断の実行40.5. ANSIBLE ベースのヘルスチェック

40.5.1. ansible-playbook によるヘルスチェックの実行40.5.2. Docker CLI でのヘルスチェックの実行

第第41章章アプリケーションのアイドリングアプリケーションのアイドリング41.1. 概要41.2. アプリケーションのアイドリング

41.2.1. 単一サービスのアイドリング41.2.2. 複数サービスのアイドリング

41.3. アプリケーションのアイドリング解除

第第42章章クラスター容量の分析クラスター容量の分析42.1. 概要

343343345345345346347347

348348348349350351352353354354354354354355356356356356357357358358358358358359

360360360363363363367367

369369369369369370

371371

目次目次

11

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42.2. コマンドラインでのクラスター容量分析の実行42.3. POD 内のジョブとしてのクラスター容量分析の実行

第第43章章 AWS でのクラスターの自動スケーラーの設定でのクラスターの自動スケーラーの設定43.1. OPENSHIFT CONTAINER PLATFORM 自動スケーラーについて43.2. PRIMED イメージの作成43.3. 起動設定および自動スケーリンググループの作成43.4. クラスターへの自動スケーラーコンポーネントのデプロイ43.5. 自動スケーラーのテスト

第第44章章機能ゲートの使用による各種機能の無効化機能ゲートの使用による各種機能の無効化44.1. クラスターの各種機能の無効化44.2. ノードの各種機能の無効化

44.2.1. 機能ゲートの一覧

第第45章章 KURYR SDN の管理の管理45.1. 概要

45.1.1. 孤立した OpenStack リソース

371372

375375375378380385

388388389390

394394394


12

目次目次

13

第1章概要『OpenShift クラスター管理』では、OpenShift Container Platform クラスターを管理するための日常的なタスクや他の詳細な設定についてのトピックを扱います。


14

第2章ノードの管理

2.1. 概要

インスタンスのノードは、CLI を使用して管理することができます。

ノードの管理操作を実行する際、CLI は実際のノードホストの表現であるノードオブジェクトと対話します。マスターはノードオブジェクトの情報を使用し、ヘルスチェックでノードの検証を実行します。

2.2. ノードの一覧表示

マスターに認識されるすべてのノードを一覧表示するには、以下を実行します。

出力例出力例

ノードの情報を含むプロジェクトの Pod デプロイメントについての情報と共にすべてのノードを一覧表示するには、以下を実行します。

出力例出力例

単一ノードについての情報のみを一覧表示するには、<node> を完全なノード名に置き換えます。

これらのコマンドの出力にある STATUS 列には、ノードの以下の状態が表示されます。

表2.1 ノードの状態

条件条件説明説明

Ready ノードは StatusOK を返し、マスターから実行されるヘルスチェックをパスしています。

$ oc get nodes

NAME STATUS ROLES AGE VERSIONmaster.example.com Ready master 7h v1.9.1+a0ce1bc657node1.example.com Ready compute 7h v1.9.1+a0ce1bc657node2.example.com Ready compute 7h v1.9.1+a0ce1bc657

$ oc get nodes -o wide

NAME STATUS ROLES AGE VERSION EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIMEip-172-18-0-39.ec2.internal Ready infra 1d v1.10.0+b81c8f8 54.172.185.130 Red Hat Enterprise Linux Server 7.5 (Maipo) 3.10.0-862.el7.x86_64 docker://1.13.1ip-172-18-10-95.ec2.internal Ready master 1d v1.10.0+b81c8f8 54.88.22.81 Red Hat Enterprise Linux Server 7.5 (Maipo) 3.10.0-862.el7.x86_64 docker://1.13.1ip-172-18-8-35.ec2.internal Ready compute 1d v1.10.0+b81c8f8 34.230.50.57 Red Hat Enterprise Linux Server 7.5 (Maipo) 3.10.0-862.el7.x86_64 docker://1.13.1

$ oc get node <node>

第第2章章ノードの管理ノードの管理

15

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#node

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cli_reference/#cli-reference-index

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#node-object-definition

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#master


NotReady ノードはマスターから実行されるヘルスチェックをパスしていません。

SchedulingDisabled ノードへの Pod の配置をスケジュールできません。

条件条件説明説明

注記注記

STATUS 列には、CLI でノードの状態を検索できない場合にノードについて Unknownが表示されます。

現在の状態の理由を含む特定ノードについての詳細情報を取得するには、以下を実行します。

例:

出力例出力例

$ oc describe node <node>

$ oc describe node node1.example.com

Name: node1.example.com 1Roles: compute 2Labels: beta.kubernetes.io/arch=amd64 3 beta.kubernetes.io/os=linux kubernetes.io/hostname=m01.example.com node-role.kubernetes.io/compute=true node-role.kubernetes.io/infra=true node-role.kubernetes.io/master=true zone=defaultAnnotations: volumes.kubernetes.io/controller-managed-attach-detach=true 4CreationTimestamp: Thu, 24 May 2018 11:46:56 -0400Taints: <none> 5Unschedulable: falseConditions: 6 Type Status LastHeartbeatTime LastTransitionTime Reason Message ---- ------ ----------------- ------------------ ------ ------- OutOfDisk False Tue, 17 Jul 2018 11:47:30 -0400 Tue, 10 Jul 2018 15:45:16 -0400 KubeletHasSufficientDisk kubelet has sufficient disk space available MemoryPressure False Tue, 17 Jul 2018 11:47:30 -0400 Tue, 10 Jul 2018 15:45:16 -0400 KubeletHasSufficientMemory kubelet has sufficient memory available DiskPressure False Tue, 17 Jul 2018 11:47:30 -0400 Tue, 10 Jul 2018 16:03:54 -0400 KubeletHasNoDiskPressure kubelet has no disk pressure Ready True Tue, 17 Jul 2018 11:47:30 -0400 Mon, 16 Jul 2018 15:10:25 -0400 KubeletReady kubelet is posting ready status PIDPressure False Tue, 17 Jul 2018 11:47:30 -0400 Thu, 05 Jul 2018 10:06:51 -0400 KubeletHasSufficientPID kubelet has sufficient PID availableAddresses: 7 InternalIP: 192.168.122.248


16

Hostname: node1.example.comCapacity: 8 cpu: 2 hugepages-2Mi: 0 memory: 8010336Ki pods: 40Allocatable: cpu: 2 hugepages-2Mi: 0 memory: 7907936Ki pods: 40System Info: 9 Machine ID: b3adb9acbc49fc1f9a7d6 System UUID: B3ADB9A-B0CB-C49FC1F9A7D6 Boot ID: 9359d15aec9-81a20aef5876 Kernel Version: 3.10.0-693.21.1.el7.x86_64 OS Image: OpenShift Enterprise Operating System: linux Architecture: amd64 Container Runtime Version: docker://1.13.1 Kubelet Version: v1.10.0+b81c8f8 Kube-Proxy Version: v1.10.0+b81c8f8ExternalID: node1.example.comNon-terminated Pods: (14 in total) 10 Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits --------- ---- ------------ ---------- --------------- ------------- default docker-registry-2-w252l 100m (5%) 0 (0%) 256Mi (3%) 0 (0%) default registry-console-2-dpnc9 0 (0%) 0 (0%) 0 (0%) 0 (0%) default router-2-5snb2 100m (5%) 0 (0%) 256Mi (3%) 0 (0%) kube-service-catalog apiserver-jh6gt 0 (0%) 0 (0%) 0 (0%) 0 (0%) kube-service-catalog controller-manager-z4t5j 0 (0%) 0 (0%) 0 (0%) 0 (0%) kube-system master-api-m01.example.com 0 (0%) 0 (0%) 0 (0%) 0 (0%) kube-system master-controllers-m01.example.com 0 (0%) 0 (0%) 0 (0%) 0 (0%) kube-system master-etcd-m01.example.com 0 (0%) 0 (0%) 0 (0%) 0 (0%) openshift-ansible-service-broker asb-1-hnn5t 0 (0%) 0 (0%) 0 (0%) 0 (0%) openshift-node sync-dvhvs 0 (0%) 0 (0%) 0 (0%) 0 (0%) openshift-sdn ovs-zjs5k 100m (5%) 200m (10%) 300Mi (3%) 400Mi (5%) openshift-sdn sdn-zr4cb 100m (5%) 0 (0%) 200Mi (2%) 0 (0%) openshift-template-service-broker apiserver-s9n7t 0 (0%) 0 (0%) 0 (0%) 0 (0%) openshift-web-console webconsole-785689b664-q7s9j 100m (5%) 0 (0%) 100Mi (1%) 0 (0%)Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) CPU Requests CPU Limits Memory Requests Memory Limits


17

1

2

3

4

5

6

7

8

9

10

11

ノードの名前。

ノードのロール。master、compute、または infra のいずれか。

ノードに適用されるラベル。

ノードに適用されるアノテーション。

ノードに適用されるテイント。

ノードの状態。

ノードの IP アドレスおよびホスト名。

Pod リソースおよび割り当て可能なリソース。

ノードホストについての情報。

ノードの Pod。

ノードで報告されるイベント。

2.3. ノードの表示

コンテナーのランタイム環境を提供する、ノードについての使用状況の統計を表示できます。これらの使用状況の統計には CPU、メモリー、およびストレージの消費量が含まれます。

使用状況の統計を表示するには、以下を実行します。

出力例出力例

------------ ---------- --------------- ------------- 500m (25%) 200m (10%) 1112Mi (14%) 400Mi (5%)Events: 11 Type Reason Age From Message ---- ------ ---- ---- ------- Normal NodeHasSufficientPID 6d (x5 over 6d) kubelet, m01.example.com Node m01.example.com status is now: NodeHasSufficientPID Normal NodeAllocatableEnforced 6d kubelet, m01.example.com Updated Node Allocatable limit across pods Normal NodeHasSufficientMemory 6d (x6 over 6d) kubelet, m01.example.com Node m01.example.com status is now: NodeHasSufficientMemory Normal NodeHasNoDiskPressure 6d (x6 over 6d) kubelet, m01.example.com Node m01.example.com status is now: NodeHasNoDiskPressure Normal NodeHasSufficientDisk 6d (x6 over 6d) kubelet, m01.example.com Node m01.example.com status is now: NodeHasSufficientDisk Normal NodeHasSufficientPID 6d kubelet, m01.example.com Node m01.example.com status is now: NodeHasSufficientPID Normal Starting 6d kubelet, m01.example.com Starting kubelet. ...

$ oc adm top nodes

NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%


18

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/installing_clusters/#configuring-node-host-labels

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-events

ラベルの付いたノードの使用状況の統計を表示するには、以下を実行します。

フィルターするのに使用するセレクター (ラベルクエリー) を選択する必要があります。=、==、および != をサポートします。

注記注記

使用状況の統計を閲覧するには、cluster-reader パーミッションがなければなりません。

注記注記

使用状況の統計を閲覧するには、metrics-server がインストールされている必要があります。「Horizontal Pod Autoscaler の要件」を参照してください。

2.4. ホストの追加

scaleup.yml Playbook を実行して新規ホストをクラスターに追加できます。この Playbook はマスターをクエリーし、新規ホストの新規証明書を生成し、配布してから、設定 Playbook を新規ホストにのみ実行します。scaleup.yml Playbook を実行する前に、前提条件となる「ホストの準備」手順をすべて完了してください。

重要重要

scaleup.yml の Playbook は新規ホストの設定のみを設定します。マスターサービスのNO_PROXY の更新やマスターサービスの再起動は行いません。

scaleup.yml Playbook を実行するには、現在のクラスター設定を表す既存のインベントリーファイル(/etc/ansible/hosts など) が必要です。以前に atomic-openshift-installer コマンドを使用してインストールを実行した場合は、~/.config/openshift/hosts を調べて、インストーラーによって生成された最新のインベントリーファイルを見つけ、そのファイルをインベントリーファイルとして使用することができます。このファイルは必要に応じて変更することができます。後で ansible-playbook を実行する際に -i オプションを使用してそのファイルの場所を指定する必要があります。

重要重要

ノードの推奨される最大数については、「cluster maximums」のセクションを参照してください。

手順手順

1. openshift-ansible パッケージを更新して最新の Playbook を取得します。

# yum update openshift-ansible

node-1 297m 29% 4263Mi 55%node-0 55m 5% 1201Mi 15%infra-1 85m 8% 1319Mi 17%infra-0 182m 18% 2524Mi 32%master-0 178m 8% 2584Mi 16%

$ oc adm top node --selector=''


19

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/developer_guide/#req-for-using-hpas

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/installing_clusters/#preparing-for-advanced-installations-origin

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/scaling_and_performance_guide/#scaling-performance-cluster-maximums

2. /etc/ansible/hosts ファイルを編集し、new_<host_type> を [OSEv3:children] セクションに追加します。たとえば、新規ノードホストを追加するには、new_nodes を追加します。

[OSEv3:children]mastersnodesnew_nodes

新規マスターホストを追加するには、new_masters を追加します。

3. [new_<host_type>] セクションを作成して、新規ホストのホスト情報を指定します。以下の新規ノードの追加例で示されているように、既存のセクションと同じ様になフォーマットにこのセクションをフォーマットします。

[nodes]master[1:3].example.comnode1.example.com openshift_node_group_name='node-config-compute'node2.example.com openshift_node_group_name='node-config-compute'infra-node1.example.com openshift_node_group_name='node-config-infra'infra-node2.example.com openshift_node_group_name='node-config-infra'

[new_nodes]node3.example.com openshift_node_group_name='node-config-infra'

その他のオプションについては、「ホスト変数の設定」を参照してください。

新規マスターを追加する場合は、[new_masters] セクションと [new_nodes] セクションの両方に新規ホストを追加して、新規マスターホストが OpenShift SDN の一部となるようにします。

[masters]master[1:2].example.com

[new_masters]master3.example.com


[new_nodes]master3.example.com

重要重要

マスターホストに node-role.kubernetes.io/infra=true ラベルを付け、それ以外に専用インフラストラクチャーノードがない場合は、エントリーに openshift_schedulable=true を追加してホストにスケジュール可能であることを示すマークを明示的に付ける必要もあります。そうしないと、レジストリーPod とルーター Pod をどこにも配置できなくなります。


20

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/installing_clusters/#advanced-host-variables

4. Playbook ディレクトリーに切り替え、openshift_node_group.yml Playbook を実行します。インベントリーファイルがデフォルトの /etc/ansible/hosts 以外の場所にある場合は、-i オプションで場所を指定します。

$ cd /usr/share/ansible/openshift-ansible$ ansible-playbook [-i /path/to/file] \ playbooks/openshift-master/openshift_node_group.yml

これにより、新規ノードグループの ConfigMap が作成され、最終的にはホスト上のノードの設定ファイルが作成されます。

注記注記

openshift_node_group.yaml Playbook を実行しても、新規ノードのみが更新されます。これは、クラスター内の既存ノードを更新するために更新することはできません。

5. scaleup.yml Playbook を実行します。インベントリーファイルがデフォルトの/etc/ansible/hosts 以外の場所にある場合は、-i オプションで場所を指定します。

ノードを追加する場合は、以下を指定します。

$ ansible-playbook [-i /path/to/file] \ playbooks/openshift-node/scaleup.yml

マスターを追加する場合は、以下を実行します。

$ ansible-playbook [-i /path/to/file] \ playbooks/openshift-master/scaleup.yml

6. EFK スタックをクラスターにデプロイしている場合は、ノードラベルを logging-infra-fluentd=true に設定します。

# oc label node/new-node.example.com logging-infra-fluentd=true

7. Playbook の実行後に、「インストールの検証」を行います。

8. [new_<host_type>] セクションで定義したホストを適切なセクションに移動します。このようにホストを移動することで、このインベントリーファイルを使用するその後の Playbook の実行で、正しくノードが処理されるようになります。[new_<host_type>] セクションは空のままにできます。たとえば、新規ノードを追加する場合は以下のように指定します。

[nodes]master[1:3].example.comnode1.example.com openshift_node_group_name='node-config-compute'node2.example.com openshift_node_group_name='node-config-compute'node3.example.com openshift_node_group_name='node-config-compute'infra-node1.example.com openshift_node_group_name='node-config-infra'infra-node2.example.com openshift_node_group_name='node-config-infra'

[new_nodes]

2.5. ノードの削除


21

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/installing_clusters/#advanced-verifying-the-installation

CLI を使用してノードを削除する場合、ノードオブジェクトは Kubernetes で削除されますが、ノード自体にある Pod は削除されません。レプリケーションコントローラーでサポートされないベア Pod はOpenShift Container Platform からアクセスできなくなり、レプリケーションコントローラーでサポートされる Pod は他の利用可能なノードにスケジュール変更されます。ローカルのマニフェスト Pod は手動で削除する必要があります。

OpenShift Container Platform クラスターからノードを削除するには、以下を実行します。

1. 削除しようとしているノードからPod を退避します。

2. ノードオブジェクトを削除します。

3. ノードがノード一覧から削除されていることを確認します。

Pod は、Ready 状態にある残りのノードに対してのみスケジュールされます。

4. すべての Pod およびコンテナーを含む OpenShift Container Platform のすべてのコンテンツをノードホストからアンインストールする必要がある場合は、ノードのアンインストールを継続し、uninstall.yml Playbook を使用する手順に従います。この手順では、Ansible を使用したクラスターインストールプロセスについての全般的な理解があることが前提となります。

2.6. ノードのラベルの更新

ノードでラベルを追加し、更新するには、以下を実行します。

詳細な使用法を表示するには、以下を実行します。

2.7. ノード上の POD の一覧表示

1 つ以上のノードにすべてまたは選択した Pod を一覧表示するには、以下を実行します。

選択したノードのすべてまたは選択した Pod を一覧表示するには、以下を実行します。

2.8. ノードをスケジュール対象外 (UNSCHEDULABLE) またはスケジュール対象 (SCHEDULABLE) としてマークする

デフォルトで、Ready ステータスの正常なノードはスケジュール対象としてマークされます。つまり、

$ oc delete node <node>

$ oc get nodes

$ oc label node <node> <key_1>=<value_1> ... <key_n>=<value_n>

$ oc label -h

$ oc adm manage-node <node1> <node2> \ --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

$ oc adm manage-node --selector=<node_selector> \ --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]


22

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#node-configuration-files

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/installing_clusters/#uninstalling-nodes

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/installing_clusters/#install-config-

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#labels

新規 Pod をこのノードに配置することができます。手動でノードをスケジュール対象外としてマークすると、新規 Pod のノードでのスケジュールがブロックされます。ノード上の既存 Pod には影響がありません。

1 つまたは複数のノードをスケジュール対象外としてマークするには、以下を実行します。

例:

出力例出力例

現時点でスケジュール対象外のノードをスケジュール対象としてマークするには、以下を実行します。

または、特定のノード名 (例: <node1> <node2>) を指定する代わりに、--selector=<node_selector>オプションを使用して選択したノードをスケジュール対象またはスケジュール対象外としてマークすることができます。

2.9. POD のノードからの退避

Pod を退避することで、すべての Pod または選択した Pod を 1 つの指定されたノードから移行できます。Pod の退避を実行するには、まずノードをスケジュール対象外としてマークする必要があります。

レプリケーションコントローラーでサポートされる Pod のみを退避できます。レプリケーションコントローラーは他のノードで新規 Pod を作成し、既存の Pod を指定したノードから削除します。デフォルトで、ベア Pod (レプリケーションコントローラーでサポートされていない Pod) はこの影響を受けません。Pod セレクターを指定して Pod のサブセットを退避できます。Pod セレクターはラベルをベースにしており、指定されたラベルのあるすべての Pod の退避が行われます。

ノードですべての Pod または選択した Pod を退避するには、以下を実行します。

--force オプションを使用すると、ベア Pod の削除を強制的に実行できます。 true に設定されると、Pod がレプリケーションコントローラー、ReplicaSet、ジョブ、daemonset、または StatefulSet で管理されていない場合でも削除が続行されます。

--grace-period を使用して、各 Pod を正常に終了するための期間 (秒単位) を設定できます。負の値の場合には、Pod に指定されるデフォルト値が使用されます。

--ignore-daemonsets を使用し、これを true に設定すると、Deamonset で管理された Pod を無視で

$ oc adm manage-node <node1> <node2> --schedulable=false

$ oc adm manage-node node1.example.com --schedulable=false

NAME LABELS STATUSnode1.example.com kubernetes.io/hostname=node1.example.com Ready,SchedulingDisabled

$ oc adm manage-node <node1> <node2> --schedulable

$ oc adm drain <node> [--pod-selector=<pod_selector>]

$ oc adm drain <node> --force=true

$ oc adm drain <node> --grace-period=-1


23

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#replication-controllers

--ignore-daemonsets を使用し、これを true に設定すると、Deamonset で管理された Pod を無視できます。

--timeout を使用すると、中止する前の待機期間を設定できます。値 0 は無限の時間を設定します。

--delete-local-data を使用し、これを true に設定すると、Pod が emptyDir (ノードがドレイン (解放))される場合に削除されるローカルデータ) を使用する場合でも削除が続行されます。

退避を実行せずに移行するオブジェクトを一覧表示するには、--dry-run オプションを使用し、これを true に設定します。

特定のノード名を指定する代わりに、--selector=<node_selector> オプションを使用し、セレクターに一致するノードの Pod を退避することができます。

2.10. ノードの再起動

プラットフォームで実行されるアプリケーションを停止せずにノードを再起動するには、まず Pod の退避を実行する必要があります。ルーティング階層によって可用性が高くされている Pod については、何も実行する必要はありません。ストレージ (通常はデータベース) を必要とするその他の Pod については、それらが 1 つの Pod が一時的にオフラインになっても作動したままになることを確認する必要があります。ステートフルな Pod の回復性はアプリケーションごとに異なりますが、いずれの場合でも、ノードの非アフィニティー (node anti-affinity) を使用して Pod が使用可能なノード間に適切に分散するようにスケジューラーを設定することが重要になります。

別の課題として、ルーターやレジストリーのような重要なインフラストラクチャーを実行しているノードを処理する方法を検討する必要があります。同じノードの退避プロセスが適用されますが、一部のエッジケースについて理解しておくことが重要です。

2.10.1. インフラストラクチャーノード

インフラストラクチャーノードは、OpenShift Container Platform 環境の一部を実行するためにラベルが付けられたノードです。現在、ノードの再起動を管理する最も簡単な方法として、インフラストラクチャーを実行するために利用できる 3 つ以上のノードを確保することができます。以下のシナリオでは、2 つのノードのみが利用可能な場合に OpenShift Container Platform で実行されるアプリケーションのサービスを中断しかねないよくある問題を示しています。

ノード A がスケジュール対象外としてマークされており、すべての Pod の退避が行われている。

このノードで実行されているレジストリー Pod がノード B に再デプロイされる。これは、ノード B が両方のレジストリー Pod を実行していることを意味します。

ノード B はスケジュール対象外としてマークされ、退避が行われる。

ノード B の 2 つの Pod エンドポイントを公開するサービスは、それらがノード A に再デプロイされるまでの短い期間すべてのエンドポイントを失う。

$ oc adm drain <node> --ignore-daemonsets=true

$ oc adm drain <node> --timeout=5s

$ oc adm drain <node> --delete-local-data=true

$ oc adm drain <node> --dry-run=true


24

1

2

3

4

5

3 つのインフラストラクチャーノードを使用する同じプロセスではサービスの中断が生じません。しかし、Pod のスケジューリングにより、退避してローテーションに戻された最後のノードはゼロ (0) レジストリーを実行していることになり、他の 2 つのノードは 2 つのレジストリーと 1 つのレジストリーをそれぞれ実行します。最善の解決法として、Pod の非アフィニティーを使用できます。これは現在テスト目的で利用できる Kubernetes のアルファ機能ですが、実稼働ワークロードに対する使用はサポートされていません。

2.10.2. Pod の非アフィニティーの使用

Pod の非アフィニティーは、ノードの非アフィニティーとは若干異なります。ノードの非アフィニティーの場合、Pod のデプロイ先となる適切な場所がほかにない場合には違反が生じます。Pod の非アフィニティーの場合は required (必須) または preferred (優先) のいずれかに設定できます。

Pod の非アフィニティーを設定するためのスタンザです。

preferred (優先) ルールを定義します。

preferred (優先) ルールの重みを指定します。最も高い重みを持つノードが優先されます。

非アフィニティールールが適用される時を決定する Pod ラベルの説明です。ラベルのキーおよび値を指定します。

演算子は、既存 Pod のラベルと新規 Pod の仕様の matchExpression パラメーターの値のセットの間の関係を表します。これには In、NotIn、Exists、または DoesNotExist のいずれかを使用できます。

この例では、コンテナーイメージレジストリー Pod に docker-registry=default のラベルがあることを想定しています。Pod の非アフィニティーでは任意の Kubernetes の一致式を使用できます。

最後に必要となる手順として、/etc/origin/master/scheduler.json で MatchInterPodAffinity スケジューラーの述語を有効にします。これが有効にされると、2 つのインフラストラクチャーノードのみが利用可能で、1 つのノードが再起動される場合に、コンテナーイメージレジストリー Pod が他のノードで実行されることが禁じられます。oc get pods は、適切なノードが利用可能になるまでこの Pod をunready (準備ができていない) として報告します。ノードが利用可能になると、すべての Pod は Ready(準備ができている) 状態に戻り、次のノードを再起動することができます。

apiVersion: v1kind: Podmetadata: name: with-pod-antiaffinityspec: affinity: podAntiAffinity: 1 preferredDuringSchedulingIgnoredDuringExecution: 2 - weight: 100 3 podAffinityTerm: labelSelector: matchExpressions: - key: docker-registry 4 operator: In 5 values: - default topologyKey: kubernetes.io/hostname


25

2.10.3. ルーターを実行するノードの処理

ほとんどの場合、OpenShift Container Platform ルーターを実行する Pod はホストのポートを公開します。PodFitsPorts スケジューラーの述語により、同じポートを使用するルーター Pod が同じノードで実行されないようにし、Pod の非アフィニティーが適用されます。ルーターの高可用性を維持するために IP フェイルオーバーを利用している場合には、他に実行することはありません。高可用性を確保するために AWS Elastic Load Balancing などの外部サービスを使用するルーター Pod の場合は、そのような外部サービスがルーター Pod の再起動に対して対応します。

ルーター Pod でホストのポートが設定されていないということも稀にあります。この場合は、インフラストラクチャーノードについての推奨される再起動プロセスに従う必要があります。

2.11. ノードの変更

インストール時に、OpenShift Container Platform はそれぞれのノードグループに対して openshift-node プロジェクトに configmap を作成します。

node-config-master

node-config-infra

node-config-compute

node-config-all-in-one

node-config-master-infra

既存のノードに設定の変更を加えるには、該当する設定マップを編集します。各ノードの sync pod は設定マップで変更の有無を監視します。インストール時に、同期 Pod は sync Daemonsets および/etc/origin/node/node-config.yaml ファイルを使用して作成されます。ここにノード設定パラメーターが存在し、これらは各ノードに追加されます。同期 Pod が設定マップの変更を検出すると、ノードグループのすべてのノードで node-config.yaml を更新し、該当するノードで atomic-openshift-node.service を再起動します。

出力例出力例

node-config-computeグループの設定マップのサンプルグループの設定マップのサンプル

$ oc get cm -n openshift-node

NAME DATA AGEnode-config-all-in-one 1 1dnode-config-compute 1 1dnode-config-infra 1 1dnode-config-master 1 1dnode-config-master-infra 1 1d

apiVersion: v1authConfig: 1 authenticationCacheSize: 1000 authenticationCacheTTL: 5m authorizationCacheSize: 1000 authorizationCacheTTL: 5mdnsBindAddress: 127.0.0.1:53


26

1

2

認証および認可設定オプションを保持します。

Pod の /etc/resolv.conf に追加 IP アドレスです。

dnsDomain: cluster.localdnsIP: 0.0.0.0 2dnsNameservers: nulldnsRecursiveResolvConf: /etc/origin/node/resolv.confdockerConfig: dockerShimRootDirectory: /var/lib/dockershim dockerShimSocket: /var/run/dockershim.sock execHandlerName: nativeenableUnidling: trueimageConfig: format: registry.reg-aws.openshift.com/openshift3/ose-${component}:${version} latest: falseiptablesSyncPeriod: 30skind: NodeConfigkubeletArguments: 3 bootstrap-kubeconfig: - /etc/origin/node/bootstrap.kubeconfig cert-dir: - /etc/origin/node/certificates cloud-config: - /etc/origin/cloudprovider/aws.conf cloud-provider: - aws enable-controller-attach-detach: - 'true' feature-gates: - RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true node-labels: - node-role.kubernetes.io/compute=true pod-manifest-path: - /etc/origin/node/pods 4 rotate-certificates: - 'true'masterClientConnectionOverrides: acceptContentTypes: application/vnd.kubernetes.protobuf,application/json burst: 40 contentType: application/vnd.kubernetes.protobuf qps: 20masterKubeConfig: node.kubeconfignetworkConfig: 5 mtu: 8951 networkPluginName: redhat/openshift-ovs-subnet 6servingInfo: 7 bindAddress: 0.0.0.0:10250 bindNetwork: tcp4 clientCA: client-ca.crtvolumeConfig: localQuota: perFSGroup: null 8volumeDirectory: /var/lib/origin/openshift.local.volumes


27

3

4

5

6

7

8

1

2

3

Kubelet のコマンドライン引数に一致する Kubelet に直接渡されるキー/値のペアです。

Pod マニフェストまたはディレクトリーへのパスです。ディレクトリーには、1 つ以上のマニフェストファイルが含まれている必要があります。 OpenShift Container Platform はマニフェストファイルを使用してノードに Pod を作成します。

ノード上の Pod ネットワーク設定です。

SDN (Software defined network) プラグインです。ovs-subnet プラグインは redhat/openshift-ovs-subnet、ovs-multitenant プラグインは redhat/openshift-ovs-multitenant、ovs-networkpolicy プラグインは redhat/openshift-ovs-networkpolicy をそれぞれ設定します。

ノードの証明書情報です。

オプション: PEM でエンコードされた証明書バンドルです。これが設定されている場合、要求ヘッダーのユーザー名をチェックする前に、有効なクライアント証明書が提示され、指定ファイルで認証局に対して検証される必要があります。

注記注記

/etc/origin/node/node-config.yaml ファイルは手動で変更できません。

2.11.1. ノードリソースの設定

ノードのリソースは、kubelet 引数をノード設定マップに追加して設定することができます。

1. 設定マップを編集します。

2. kubeletArguments セクションを追加して、オプションを指定します。

この kubelet で実行できる Pod の最大数。

コンテナー DNS 解決設定のベースとして使用されるリゾルバーの設定ファイル。

イメージのガべージコレクションが常に実行される場合のディスク使用量のパーセント。デフォルト: 90%

$ oc edit cm node-config-compute -n openshift-node

kubeletArguments: max-pods: 1 - "40" resolv-conf: 2 - "/etc/resolv.conf" image-gc-high-threshold: 3 - "90" image-gc-low-threshold: 4 - "80" kube-api-qps: 5 - "20" kube-api-burst: 6 - "40"


28

https://kubernetes.io/docs/admin/kubelet/

4

5

6

イメージのガべージコレクションが一度も実行されない場合のディスク使用量のパーセント。デフォルト: 80%

Kubernetes API サーバーとの通信中に使用する 1 秒あたりのクエリー数 (QPS)。

Kubernetes API サーバーとの通信中に使用するバースト。

利用可能なすべての kubelet オプションを表示するには、以下を実行します。

2.11.2. ノードあたりの最大 Pod 数の設定

注記注記

OpenShift Container Platform の各バージョンでサポートされている最大の制限については、「Cluster maximums」のページを参照してください。

/etc/origin/node/node-config.yaml ファイルでは、 pods-per-core および max-pods の 2 つのパラメーターがノードにスケジュールできる Pod の最大数を制御します。いずれのオプションも使用されている場合、2 つの内の小さい方の値でノードの Pod 数が制限されます。これらの値を超えると、以下の状況が発生します。

OpenShift Container Platform と Docker の両方で CPU 使用率が増加する。

Pod のスケジューリングの速度が遅くなる。

メモリー不足のシナリオが生じる可能性がある (ノードのメモリー量によって異なる)。

IP アドレスのプールを消費する。

リソースのオーバーコミット、およびこれによるアプリケーションのパフォーマンスの低下。

注記注記

Kubernetes では、単一コンテナーを保持する Pod は実際には 2 つのコンテナーを使用します。2 つ目のコンテナーは実際のコンテナーの起動前にネットワークを設定するために使用されます。そのため、10 の Pod を使用するシステムでは、実際には 20 のコンテナーが実行されていることになります。

pods-per-core は、ノードのプロセッサーコア数に基づいてノードが実行できる Pod 数を設定します。たとえば、4 プロセッサーコアを搭載したノードで pods-per-core が 10 に設定される場合、このノードで許可される Pod の最大数は 40 になります。

注記注記

pods-per-core を 0 に設定すると、この制限が無効になります。

$ hyperkube kubelet -h

kubeletArguments: pods-per-core: - "10"


29

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/scaling_and_performance_guide/#scaling-performance-current-cluster-maximums

max-pods は、ノードのプロパティーにかかわらず、ノードが実行できる Pod 数を固定値に設定します。「Cluster Limits」では max-pods のサポートされる最大の値について説明しています。

上記の例では、pods-per-core のデフォルト値は 10 であり、max-pods のデフォルト値は 250 です。これは、ノードにあるコア数が 25 以上でない限り、デフォルトでは pods-per-core が制限を設定することになります。

2.12. DOCKER ストレージの再設定

コンテナーイメージをダウンロードし、コンテナーを実行して削除する際、Docker は常にマップされたディスク領域を解放する訳ではありません。結果として、一定の時間が経過するとノード上で領域不足が生じる可能性があり、これにより OpenShift Container Platform で新規 Pod を作成できなくなるか、または Pod の作成に時間がかかる可能性があります。

たとえば、以下は 6 分が経過しても ContainerCreating 状態にある Pod を示しており、イベントログは FailedSync イベントについて示しています。

出力例出力例

出力例出力例

この問題に対する 1 つの解決法として、Docker ストレージを再設定し、Docker で不要なアーティファクトを削除することができます。

Docker ストレージを再起動するノードで、以下を実行します。

1. 以下のコマンドを実行して、ノードをスケジュール対象外としてマークします。

kubeletArguments: max-pods: - "250"

$ oc get pod

NAME READY STATUS RESTARTS AGEcakephp-mysql-persistent-1-build 0/1 ContainerCreating 0 6mmysql-1-9767d 0/1 ContainerCreating 0 2mmysql-1-deploy 0/1 ContainerCreating 0 6m

$ oc get events

LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE6m 6m 1 cakephp-mysql-persistent-1-build Pod Normal Scheduled default-scheduler Successfully assigned cakephp-mysql-persistent-1-build to ip-172-31-71-195.us-east-2.compute.internal2m 5m 4 cakephp-mysql-persistent-1-build Pod Warning FailedSync kubelet, ip-172-31-71-195.us-east-2.compute.internal Error syncing pod2m 4m 4 cakephp-mysql-persistent-1-build Pod Normal SandboxChanged kubelet, ip-172-31-71-195.us-east-2.compute.internal Pod sandbox changed, it will be killed and re-created.


30

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/scaling_and_performance_guide/#scaling-performance-current-cluster-maximums

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#events-reference

2. 以下のコマンドを実行して Docker および atomic-openshift-node サービスをシャットダウンします。

3. 以下のコマンドを実行してローカルのボリュームディレクトリーを削除します。

このコマンドは、ローカルイメージのキャッシュをクリアします。その結果、ose-* イメージを含むイメージが再度プルする必要があります。これにより、イメージストアは回復しますが、Pod の起動時間が遅くなる可能性があります。

4. /var/lib/docker ディレクトリーを削除します。

5. 以下のコマンドを実行して Docker ストレージを再設定します。

6. 以下のコマンドを実行して Docker ストレージを再作成します。

7. /var/lib/docker ディレクトリーを再作成します。

8. 以下のコマンドを実行して Docker および atomic-openshift-node サービスを再起動します。

9. ホストを再起動してノードサービスを再起動します。

10. 以下のコマンドを実行してノードをスケジュール対象としてマークします。

$ oc adm manage-node <node> --schedulable=false

$ systemctl stop docker atomic-openshift-node

$ rm -rf /var/lib/origin/openshift.local.volumes

$ rm -rf /var/lib/docker

$ docker-storage-setup --reset

$ docker-storage-setup

$ mkdir /var/lib/docker

$ systemctl start docker atomic-openshift-node

# systemctl restart atomic-openshift-node.service

$ oc adm manage-node <node> --schedulable=true


31

第3章 OPENSHIFT CONTAINER PLATFORM コンポーネントの復元

3.1. 概要

OpenShift Container Platform では、クラスターおよびそのコンポーネントの復元は、ノードおよびアプリケーションなどの要素を別のストレージから再作成することで実行できます。

クラスターを復元するには、まずバックアップを作成します。

重要重要

以下のプロセスでは、アプリケーションおよび OpenShift Container Platform クラスターを復元するための通常の方法について説明しています。ここではカスタム要件は考慮されません。クラスターを復元するために追加のアクションを実行する必要がある可能性があります。

3.2. クラスターの復元

クラスターを復元するには、まず OpenShift Container Platform を再インストールします。

手順手順

1. 最初に OpenShift Container Platform をインストールしたのと同じ方法で OpenShift ContainerPlatform を再インストールします。

2. OpenShift Container Platform の制御下にないサービスを変更したり、モニターエージェントなどの追加サービスのインストールなど、インストール後のカスタム手順すべてを実行します。

3.3. マスターホストのバックアップの復元

重要なマスターホストファイルのバックアップを作成した後に、それらのファイルが破損するか、または間違って削除された場合は、それらのファイルをマスターにコピーし直してファイルを復元し、それらに適切なコンテンツが含まれることを確認し、影響を受けるサービスを再起動して実行できます。

手順手順

1. /etc/origin/master/master-config.yaml ファイルを復元します。

# MYBACKUPDIR=*/backup/$(hostname)/$(date +%Y%m%d)*# cp /etc/origin/master/master-config.yaml /etc/origin/master/master-config.yaml.old# cp /backup/$(hostname)/$(date +%Y%m%d)/origin/master/master-config.yaml /etc/origin/master/master-config.yaml# master-restart api# master-restart controllers


32

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/day_two_operations_guide/#day_two_environment_backup

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/installing_clusters/#install-planning

1

警告警告

マスターサービスの再起動によりダウンタイムが生じる場合があります。ただし、マスターホストを可用性の高いロードバランサープールから削除し、復元操作を実行することができます。サービスが適切に復元された後に、マスターホストをロードバランサープールに再び追加することができます。

注記注記

影響を受けるインスタンスを完全に再起動して、iptables 設定を復元します。

2. パッケージがないために OpenShift Container Platform を再起動できない場合は、パッケージを再インストールします。

a. 現在インストールされているパッケージの一覧を取得します。

$ rpm -qa | sort > /tmp/current_packages.txt

b. パッケージの一覧の間に存在する差分を表示します。

$ diff /tmp/current_packages.txt ${MYBACKUPDIR}/packages.txt

> ansible-2.4.0.0-5.el7.noarch

c. 足りないパッケージを再インストールします。

# yum reinstall -y <packages> 1

<packages> は、パッケージの一覧ごとに異なるパッケージに置き換えます。

3. システム証明書を /etc/pki/ca-trust/source/anchors/ ディレクトリーにコピーして復元し、update-ca-trust を実行します。

$ MYBACKUPDIR=*/backup/$(hostname)/$(date +%Y%m%d)*$ sudo cp ${MYBACKUPDIR}/external_certificates/my_company.crt /etc/pki/ca-trust/source/anchors/$ sudo update-ca-trust

注記注記

ファイルをコピーし直す時に、ユーザー ID およびグループ ID だけでなく、SELinux コンテキストも復元されていることを常に確認してください。

3.4. ノードホストバックアップの復元

重要なノードホストファイルのファイルのバックアップを作成した後に、それらのファイルが破損する

第第3章章 OPENSHIFT CONTAINER PLATFORM コンポーネントの復元コンポーネントの復元

33

1

重要なノードホストファイルのファイルのバックアップを作成した後に、それらのファイルが破損するか、または間違って削除された場合、これらのファイルをコピーし直してファイルを復元し、適切なコンテンツが含まれることを確認してから、影響を受けるサービスを再起動します。

手順手順

1. /etc/origin/node/node-config.yaml ファイルを復元します。

# MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)# cp /etc/origin/node/node-config.yaml /etc/origin/node/node-config.yaml.old# cp /backup/$(hostname)/$(date +%Y%m%d)/etc/origin/node/node-config.yaml /etc/origin/node/node-config.yaml# reboot

警告警告

サービスの再起動によりダウンタイムが生じる場合があります。このプロセスを容易にするためのヒントについては、「ノードの保守」を参照してください。

注記注記

影響を受けるインスタンスを完全に再起動して、iptables 設定を復元します。

1. パッケージがないために OpenShift Container Platform を再起動できない場合は、パッケージを再インストールします。

a. 現在インストールされているパッケージの一覧を取得します。

$ rpm -qa | sort > /tmp/current_packages.txt

b. パッケージの一覧の間に存在する差分を表示します。

$ diff /tmp/current_packages.txt ${MYBACKUPDIR}/packages.txt

> ansible-2.4.0.0-5.el7.noarch

c. 足りないパッケージを再インストールします。

# yum reinstall -y <packages> 1

<packages> は、パッケージの一覧ごとに異なるパッケージに置き換えます。

2. システム証明書を /etc/pki/ca-trust/source/anchors/ ディレクトリーにコピーして復元し、update-ca-trust を実行します。

$ MYBACKUPDIR=*/backup/$(hostname)/$(date +%Y%m%d)*$ sudo cp ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors/my_company.crt /etc/pki/ca-trust/source/anchors/


34

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/day_two_operations_guide/#day-two-guide-node-maintenance

$ sudo update-ca-trust

注記注記

ファイルをコピーし直す時に、ユーザー ID およびグループ ID だけでなく、SELinux コンテキストも復元されていることを常に確認してください。

3.5. ETCD の復元

etcd 設定ファイルの復元手順では、適切なファイルを置き換えてからサービスまたは静的 Pod を再起動します。

etcd ホストが破損し、/etc/etcd/etcd.conf ファイルが失われる場合は、以下を使用してこれを復元します。

$ ssh master-0# cp /backup/yesterday/master-0-files/etcd.conf /etc/etcd/etcd.conf# restorecon -RvF /etc/etcd/etcd.conf

この例では、バックアップファイルは /backup/yesterday/master-0-files/etcd.conf パスに保存されます。ここでは外部 NFS 共有、S3 バケットまたは他のストレージソリューションとして使用できます。

注記注記

etcd を静的 Pod として実行する場合は、該当セクションの手順のみを実行してください。etcd をマスターまたはスタンドアロンノードの別個のサービスとして実行する場合には、必要に応じてデータを復元する手順に従ってください。

3.5.1. etcd データの復元

以下のプロセスでは正常なデータファイルを復元し、etcd クラスターを単一ノードとして起動してから、etcd クラスターが必要な場合に残りのノードを追加します。

手順

1. etcd Pod 定義を削除し、ホストを再起動してすべての etcd サービスを停止します。

# mkdir -p /etc/origin/node/pods-stopped# mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/# reboot

2. 適切なバックアップが復元されていることを確認するには、etcd ディレクトリーを削除します。

ディレクトリーを削除する前に現在の etcd データをバックアップするには、以下のコマンドを実行します。

# mv /var/lib/etcd /var/lib/etcd.old# mkdir /var/lib/etcd# restorecon -RvF /var/lib/etcd/

または、ディレクトリーおよび etcd、データを削除するには、以下のコマンドを実行します。


35

# rm -Rf /var/lib/etcd/*

注記注記

オールインワンクラスターの場合、etcd データディレクトリーは /var/lib/origin/openshift.local.etcd ディレクトリーに置かれます。

3. 正常なバックアップデータファイルをそれぞれの etcd ノードに復元します。この手順は、etcdと同じ場所に配置されているマスターホストを含むすべての etcd ホストで実行します。

# cp -R /backup/etcd-xxx/* /var/lib/etcd/# mv /var/lib/etcd/db /var/lib/etcd/member/snap/db# chcon -R --reference /backup/etcd-xxx/* /var/lib/etcd/

4. etcd ホストのいずれかで etcd サービスを実行し、新規クラスターを強制的に実行します。これにより etcd サービスのカスタムファイルが作成されます。これにより、--force-new-cluster オプションを追加して実行コマンドが上書きされます。

# mkdir -p /etc/systemd/system/etcd.service.d/# echo "[Service]" > /etc/systemd/system/etcd.service.d/temp.conf# echo "ExecStart=" >> /etc/systemd/system/etcd.service.d/temp.conf# sed -n '/ExecStart/s/"$/ --force-new-cluster"/p' \ /usr/lib/systemd/system/etcd.service \ >> /etc/systemd/system/etcd.service.d/temp.conf

# systemctl daemon-reload# master-restart etcd

5. エラーメッセージの有無を確認します。

# master-logs etcd etcd

6. 正常性のステータスを確認します。

# etcdctl3 cluster-healthmember 5ee217d17301 is healthy: got healthy result from https://192.168.55.8:2379cluster is healthy

7. クラスターモードで etcd サービスを再起動します。

# rm -f /etc/systemd/system/etcd.service.d/temp.conf# systemctl daemon-reload# master-restart etcd

8. 正常性のステータスとメンバーの一覧を確認します。

# etcdctl3 cluster-healthmember 5ee217d17301 is healthy: got healthy result from https://192.168.55.8:2379cluster is healthy


36

# etcdctl3 member list5ee217d17301: name=master-0.example.com peerURLs=http://localhost:2380 clientURLs=https://192.168.55.8:2379 isLeader=true

9. 最初のインスタンスが実行された後、残りのピアをクラスターに戻すことができます。

3.5.1.1. peerURLS パラメーターの修正パラメーターの修正

データの復元および新規クラスターの作成後に、peerURLs パラメーターは、 etcd がピア通信をリッスンする IP の代わりに localhost を示します。

# etcdctl3 member list5ee217d17301: name=master-0.example.com peerURLs=http://*localhost*:2380 clientURLs=https://192.168.55.8:2379 isLeader=true

3.5.1.1.1. 手順

1. etcdctl member list を使用してメンバー ID を取得します。

`etcdctl member list`

2. etcd がピア通信をリッスンする IP を取得します。

$ ss -l4n | grep 2380

3. メンバー情報をこの IP で更新します。

# etcdctl3 member update 5ee217d17301 https://192.168.55.8:2380Updated member with ID 5ee217d17301 in cluster

4. 検証するには、IP がメンバーの一覧にあることを確認します。

$ etcdctl3 member list5ee217d17301: name=master-0.example.com peerURLs=https://*192.168.55.8*:2380 clientURLs=https://192.168.55.8:2379 isLeader=true

3.5.2. etcd v3 スナップショットの復元

スナップショットの整合性については、復元時にオプションで検証できます。スナップショットが etcdctl snapshot save で作成される場合には、スナップショットに整合性ハッシュが含まれており、etcdctl snapshot restore でチェックされます。スナップショットがデータディレクトリーからコピーされる場合には、整合性ハッシュはなく、--skip-hash-check を使用しないと復元されません。

重要重要

データを復元する手順は単一 etcd ホストで実行される必要があります。その後に残りのノードをクラスターに追加することができます。

手順

1. etcd Pod 定義を削除し、ホストを再起動してすべての etcd サービスを停止します。


37

# mkdir -p /etc/origin/node/pods-stopped# mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/# reboot

2. 古いデータについては、etcdctl が復元手順が実行されるノードでその再作成を実行するため、それらすべてをクリアします。

# rm -Rf /var/lib/etcd

3. snapshot restore コマンドを実行し、/etc/etcd/etcd.conf ファイルの値を置き換えます。

# etcdctl3 snapshot restore /backup/etcd-xxxxxx/backup.db \ --data-dir /var/lib/etcd \ --name master-0.example.com \ --initial-cluster "master-0.example.com=https://192.168.55.8:2380" \ --initial-cluster-token "etcd-cluster-1" \ --initial-advertise-peer-urls https://192.168.55.8:2380 \ --skip-hash-check=true

2017-10-03 08:55:32.440779 I | mvcc: restore compact to 10412692017-10-03 08:55:32.468244 I | etcdserver/membership: added member 40bef1f6c79b3163 [https://192.168.55.8:2380] to cluster 26841ebcf610583c

4. パーミッションおよび selinux コンテキストを復元ファイルに復元します。

# restorecon -RvF /var/lib/etcd

5. etcd サービスを起動します。

# systemctl start etcd



3.5.3. 静的 Pod での etcd の復元

静的 Pod で etcd を復元する前に、以下を確認します。

etcdctl バイナリーが利用可能であるか、またはコンテナー化インストールの場合は rhel7/etcdコンテナーが利用可能でなければなりません。以下のコマンドを実行して、etcd パッケージで etcdctl バイナリーをインストールできます。

# yum install etcd

また、このパッケージは systemd サービスもインストールします。etcd が静的 Pod で実行されている場合に、サービスを systemd サービスとして実行されないように無効にし、マスクします。サービスを無効にし、マスクすることで、サービスが誤って起動しなくなり、システムの再起動時に自動的に再起動されないようにすることができます。

# systemctl disable etcd.service# systemctl mask etcd.service


38

静的 Pod で etcd を復元するには、以下を実行します。

1. Pod が実行中の場合、Pod のマニフェスト YAML ファイルを別のディレクトリーに移動してetcd Pod を停止します。

# mkdir -p /etc/origin/node/pods-stopped# mv /etc/origin/node/pods/etcd.yaml /etc/origin/node/pods-stopped

2. すべての古いデータをクリアします。

# rm -rf /var/lib/etcd

etcdctl を使用して、Pod を復元するノードでデータを再作成します。

3. etcd スナップショットを etcd Pod のマウントパスに復元します。

# export ETCDCTL_API=3# etcdctl snapshot restore /etc/etcd/backup/etcd/snapshot.db --data-dir /var/lib/etcd/ --name ip-172-18-3-48.ec2.internal --initial-cluster "ip-172-18-3-48.ec2.internal=https://172.18.3.48:2380" --initial-cluster-token "etcd-cluster-1" --initial-advertise-peer-urls https://172.18.3.48:2380 --skip-hash-check=true

$/backup_files/etcd.conf ファイルからクラスターの値を取得します。

4. データディレクトリーに必要なパーミッションおよび selinux コンテキストを設定します。

# restorecon -RvF /var/lib/etcd/

5. Pod のマニフェスト YAML ファイルを必要なディレクトリーに移動して etcd Pod を再起動します。

# mv /etc/origin/node/pods-stopped/etcd.yaml /etc/origin/node/pods/

3.6. ETCD ノードの追加

etcd の復元後、他の etcd ノードをクラスターに追加できます。Ansible Playbook を使用するか、または手動の手順を実行して etcd ホストを追加できます。

3.6.1. Ansible を使用した新規 etcd ホストの追加

手順

1. Ansible インベントリーファイルで、[new_etcd] という名前の新規グループおよび新規ホストを作成します。次に、new_etcd グループを [OSEv3] グループの子として追加します。

[OSEv3:children]mastersnodesetcdnew_etcd 1


39

1 2 3

... [OUTPUT ABBREVIATED] ...

[etcd]master-0.example.commaster-1.example.commaster-2.example.com

[new_etcd] 2etcd0.example.com 3

これらの行を追加します。

2. OpenShift Container Platform をインストールし、Ansible インベントリーファイルをホストするホストから、Playbook ディレクトリーに移動し、etcd scaleup Playbook を実行します。

$ cd /usr/share/ansible/openshift-ansible$ ansible-playbook playbooks/openshift-etcd/scaleup.yml

3. Playbook が実行された後に、新規 etcd ホストを [new_etcd] グループから [etcd] グループに移行し、現在のステータスを反映するようにインベントリーファイルを変更します。

[OSEv3:children]mastersnodesetcdnew_etcd


[etcd]master-0.example.commaster-1.example.commaster-2.example.cometcd0.example.com

4. Flannel を使用する場合には、OpenShift Container Platform のホストごとに、/etc/sysconfig/flanneld にある flanneld サービス設定を変更し、新しい etcd ホストを追加します。

FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379,https://etcd0.example.com:2379

5. flanneld サービスを再起動します。

# systemctl restart flanneld.service

3.6.2. 新規 etcd ホストの手動による追加

etcd をマスターノードで静的 Pod として実行しない場合、別の etcd ホストを追加する必要が生じる場合があります。

手順


40

現在の etcd クラスターの変更etcd 証明書を作成するには、値を環境の値に置き換えて openssl コマンドを実行します。

1. 環境変数を作成します。

export NEW_ETCD_HOSTNAME="*etcd0.example.com*"export NEW_ETCD_IP="192.168.55.21"

export CN=$NEW_ETCD_HOSTNAMEexport SAN="IP:${NEW_ETCD_IP}, DNS:${NEW_ETCD_HOSTNAME}"export PREFIX="/etc/etcd/generated_certs/etcd-$CN/"export OPENSSLCFG="/etc/etcd/ca/openssl.cnf"

注記注記

etcd_v3_ca_* として使用されるカスタムの openssl 拡張には、subjectAltName としての $SAN 環境変数が含まれます。詳細は、/etc/etcd/ca/openssl.cnf を参照してください。

2. 設定および証明書を保存するディレクトリーを作成します。

# mkdir -p ${PREFIX}

3. サーバー証明書要求を作成し、これに署名します (server.csr および server.crt)。

# openssl req -new -config ${OPENSSLCFG} \ -keyout ${PREFIX}server.key \ -out ${PREFIX}server.csr \ -reqexts etcd_v3_req -batch -nodes \ -subj /CN=$CN

# openssl ca -name etcd_ca -config ${OPENSSLCFG} \ -out ${PREFIX}server.crt \ -in ${PREFIX}server.csr \ -extensions etcd_v3_ca_server -batch

4. ピア証明書要求を作成し、これに署名します (peer.csr および peer.crt)。

# openssl req -new -config ${OPENSSLCFG} \ -keyout ${PREFIX}peer.key \ -out ${PREFIX}peer.csr \ -reqexts etcd_v3_req -batch -nodes \ -subj /CN=$CN

# openssl ca -name etcd_ca -config ${OPENSSLCFG} \ -out ${PREFIX}peer.crt \ -in ${PREFIX}peer.csr \ -extensions etcd_v3_ca_peer -batch

5. 後で変更できるように、現在の etcd 設定および ca.crt ファイルをサンプルとして現在のノードからコピーします。


41

1

# cp /etc/etcd/etcd.conf ${PREFIX}# cp /etc/etcd/ca.crt ${PREFIX}

6. 存続する etcd ホストから、新規ホストをクラスターに追加します。etcd メンバーをクラスターに追加するには、まず最初のメンバーの peerURLs 値のデフォルトの localhost ピアを調整する必要があります。

a. member list コマンドを使用して最初のメンバーのメンバー ID を取得します。

# etcdctl --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key \ --ca-file=/etc/etcd/ca.crt \ --peers="https://172.18.1.18:2379,https://172.18.9.202:2379,https://172.18.0.75:2379" \ 1 member list

--peers パラメーター値でアクティブな etcd メンバーのみの URL を指定するようにしてください。

b. etcd がクラスターピアについてリッスンする IP アドレスを取得します。

$ ss -l4n | grep 2380

c. 直前の手順で取得されたメンバー ID および IP アドレスを渡して、etcdctl member updateコマンドを使用してpeerURLs の値を更新します。

# etcdctl --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key \ --ca-file=/etc/etcd/ca.crt \ --peers="https://172.18.1.18:2379,https://172.18.9.202:2379,https://172.18.0.75:2379" \ member update 511b7fb6cc0001 https://172.18.1.18:2380

d. member list コマンドを再実行し、ピア URL に localhost が含まれなくなるようにします。

7. 新規ホストを etcd クラスターに追加します。新規ホストはまだ設定されていないため、新規ホストを設定するまでステータスが unstarted のままであることに注意してください。

警告警告

各メンバーを追加し、1 回に 1 つずつメンバーをオンライン状態にします。各メンバーをクラスターに追加する際に、現在のピアの peerURL 一覧を調整する必要があります。peerURL 一覧はメンバーが追加されるたびに拡張します。etcdctl member add コマンドは、以下に説明されているように、メンバーを追加する際に etcd.conf ファイルで設定する必要のある値を出力します。


42

1

# etcdctl -C https://${CURRENT_ETCD_HOST}:2379 \ --ca-file=/etc/etcd/ca.crt \ --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key member add ${NEW_ETCD_HOSTNAME} https://${NEW_ETCD_IP}:2380 1

Added member named 10.3.9.222 with ID 4e1db163a21d7651 to cluster

ETCD_NAME="<NEW_ETCD_HOSTNAME>"ETCD_INITIAL_CLUSTER="<NEW_ETCD_HOSTNAME>=https://<NEW_HOST_IP>:2380,<CLUSTERMEMBER1_NAME>=https:/<CLUSTERMEMBER2_IP>:2380,<CLUSTERMEMBER2_NAME>=https:/<CLUSTERMEMBER2_IP>:2380,<CLUSTERMEMBER3_NAME>=https:/<CLUSTERMEMBER3_IP>:2380"ETCD_INITIAL_CLUSTER_STATE="existing"

この行で、10.3.9.222 は etcd メンバーのラベルです。ホスト名、IP アドレスまたは単純な名前を指定できます。

8. サンプル ${PREFIX}/etcd.conf ファイルを更新します。

a. 以下の値を直前の手順で生成された値に置き換えます。

ETCD_NAME

ETCD_INITIAL_CLUSTER

ETCD_INITIAL_CLUSTER_STATE

b. 以下の変数は、直前の手順で出力された新規ホストの IP に変更します。${NEW_ETCD_IP} は、値として使用できます。

ETCD_LISTEN_PEER_URLSETCD_LISTEN_CLIENT_URLSETCD_INITIAL_ADVERTISE_PEER_URLSETCD_ADVERTISE_CLIENT_URLS

c. メンバーシステムを etcd ノードとして使用していた場合には、/etc/etcd/etcd.conf ファイルの現在の値を上書きする必要があります。

d. ファイルで構文エラーや欠落している IP アドレスがないかを確認します。エラーや欠落がある場合には、etced サービスが失敗してしまう可能性があります。

# vi ${PREFIX}/etcd.conf

9. インストールファイルをホストするノードでは、/etc/ansible/hosts インベントリーファイルの [etcd] ホストグループを更新します。古い etcd ホストを削除し、新規ホストを追加します。

10. 証明書、サンプル設定ファイル、および ca を含む tgz ファイルを作成し、これを新規ホストにコピーします。

# tar -czvf /etc/etcd/generated_certs/${CN}.tgz -C ${PREFIX} .# scp /etc/etcd/generated_certs/${CN}.tgz ${CN}:/tmp/


43

新規 etcd ホストの変更

1. iptables-services をインストールして etcd の必要なポートを開くために iptables ユーティリティーを指定します。

# yum install -y iptables-services

2. etcd の通信を許可する OS_FIREWALL_ALLOW ファイアウォールルールを作成します。

クライアントのポート 2379/tcp

ピア通信のポート 2380/tcp

# systemctl enable iptables.service --now# iptables -N OS_FIREWALL_ALLOW# iptables -t filter -I INPUT -j OS_FIREWALL_ALLOW# iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2379 -j ACCEPT# iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2380 -j ACCEPT# iptables-save | tee /etc/sysconfig/iptables

注記注記

この例では、新規チェーン OS_FIREWALL_ALLOW が作成されます。これは、OpenShift Container Platform インストーラーがファイアウォールルールに使用する標準の名前になります。

警告警告

環境が IaaS 環境でホストされている場合には、インスタンスがこれらのポートに入ってくるトラフィックを許可できるように、セキュリティーグループを変更します。

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

# yum install -y etcd

バージョン etcd-2.3.7-4.el7.x86_64 以降がインストールされていることを確認します。

4. etcd Pod 定義を削除して、etcd サービスが実行されていない状態にします。

# mkdir -p /etc/origin/node/pods-stopped# mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/

5. etcd 設定およびデータを削除します。

# rm -Rf /etc/etcd/*# rm -Rf /var/lib/etcd/*


44

6. 証明書および設定ファイルを展開します。

# tar xzvf /tmp/etcd0.example.com.tgz -C /etc/etcd/

7. 新規ホストで etcd を起動します。

# systemctl enable etcd --now

8. ホストがクラスターの一部であることと現在のクラスターの正常性を確認します。

v2 etcd api を使用する場合は、以下のコマンドを実行します。

# etcdctl --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key \ --ca-file=/etc/etcd/ca.crt \ --peers="https://*master-0.example.com*:2379,\ https://*master-1.example.com*:2379,\ https://*master-2.example.com*:2379,\ https://*etcd0.example.com*:2379"\ cluster-healthmember 5ee217d19001 is healthy: got healthy result from https://192.168.55.12:2379member 2a529ba1840722c0 is healthy: got healthy result from https://192.168.55.8:2379member 8b8904727bf526a5 is healthy: got healthy result from https://192.168.55.21:2379member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379cluster is healthy


# ETCDCTL_API=3 etcdctl --cert="/etc/etcd/peer.crt" \ --key=/etc/etcd/peer.key \ --cacert="/etc/etcd/ca.crt" \ --endpoints="https://*master-0.example.com*:2379,\ https://*master-1.example.com*:2379,\ https://*master-2.example.com*:2379,\ https://*etcd0.example.com*:2379"\ endpoint healthhttps://master-0.example.com:2379 is healthy: successfully committed proposal: took = 5.011358mshttps://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.305173mshttps://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.388772mshttps://etcd0.example.com:2379 is healthy: successfully committed proposal: took = 1.498829ms

各 OpenShift Container Platform マスターの変更

1. すべてのマスターの /etc/origin/master/master-config.yaml ファイルの etcClientInfo セクションでマスター設定を変更します。新規 etcd ホストを、データを保存するために OpenShiftContainer Platform が使用する etcd サーバーの一覧に追加し、失敗したすべての etcd ホストを削除します。

etcdClientInfo: ca: master.etcd-ca.crt


45

certFile: master.etcd-client.crt keyFile: master.etcd-client.key urls: - https://master-0.example.com:2379 - https://master-1.example.com:2379 - https://master-2.example.com:2379 - https://etcd0.example.com:2379

2. マスター API サービスを再起動します。

全マスターのインストールに対しては、以下を実行します。

# master-restart api# master-restart controllers

警告警告

etcd ノードの数は奇数でなければなりません。そのため、2 つ以上のホストを追加する必要があります。

3. Flannel を使用する場合、新規 etcd ホストを組み込むために、すべての OpenShift ContainerPlatform ホストの /etc/sysconfig/flanneld にある flanneld サービス設定を変更します。




3.7. OPENSHIFT CONTAINER PLATFORM サービスの再オンライン化

変更を終了した後に、OpenShift Container Platform をオンラインに戻します。

手順手順

1. それぞれの OpenShift Container Platform マスターで、バックアップからマスターおよびノード設定を復元し、すべての関連するサービスを有効にしてから再起動します。

# cp ${MYBACKUPDIR}/etc/origin/node/pods/* /etc/origin/node/pods/# cp ${MYBACKUPDIR}/etc/origin/master/master.env /etc/origin/master/master.env# cp ${MYBACKUPDIR}/etc/origin/master/master-config.yaml.<timestamp> /etc/origin/master/master-config.yaml# cp ${MYBACKUPDIR}/etc/origin/node/node-config.yaml.<timestamp> /etc/origin/node/node-config.yaml# cp ${MYBACKUPDIR}/etc/origin/master/scheduler.json.<timestamp> /etc/origin/master/scheduler.json# master-restart api# master-restart controllers


46

2. 各 OpenShift Container Platform ノードで、必要に応じてノードの設定マップを更新し、atomic-openshift-node サービスを有効化して再起動します。

# cp /etc/origin/node/node-config.yaml.<timestamp> /etc/origin/node/node-config.yaml# systemctl enable atomic-openshift-node# systemctl start atomic-openshift-node

3.8. プロジェクトの復元

プロジェクトを復元するために、oc create -f pods.json を実行して新規プロジェクトを作成してから、エクスポートされたファイルを復元します。ただし、プロジェクトをゼロから復元するには、一部のプロジェクトが他のプロジェクトに依存していることから特定の順序を指定する必要があります。たとえば、pods を作成する前に configmaps を作成する必要があります。

手順手順

1. プロジェクトが単一ファイルとしてエクスポートされている場合は、以下のコマンドを実行してこのファイルをインポートします。

$ oc new-project <projectname>$ oc create -f project.yaml$ oc create -f secret.yaml$ oc create -f serviceaccount.yaml$ oc create -f pvc.yaml$ oc create -f rolebindings.yaml

警告警告

Pod およびデフォルトサービスアカウントなどの一部のリソースは作成できない場合があります。

3.9. アプリケーションデータの復元

rsync がコンテナーイメージ内にインストールされていることを前提とすると、アプリケーションデータは oc rsync コマンドを使用してバックアップできます。Red Hat rhel7 ベースイメージには rsyncが含まれるので、rhel7 をベースとするすべてのイメージにもこれが含まれます。「Troubleshootingand Debugging CLI Operations - rsync」を参照してください。

警告警告

これは、アプリケーションデータの汎用的な復元についての説明であり、データベースシステムの特殊なエクスポート/インポートなどのアプリケーション固有のバックアップ手順については考慮に入れられていません。


47

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cli_reference/#cli-operations-rsync

使用する永続ボリュームのタイプ (Cinder、NFS、Gluster など) によっては、他の復元手段を使用できる場合もあります。

手順手順

Jenkins デプロイメントのアプリケーションデータの復元例

1. バックアップを確認します。

$ ls -la /tmp/jenkins-backup/total 8drwxrwxr-x. 3 user user 20 Sep 6 11:14 .drwxrwxrwt. 17 root root 4096 Sep 6 11:16 ..drwxrwsrwx. 12 user user 4096 Sep 6 11:14 jenkins

2. oc rsync ツールを使用してデータを実行中の Pod にコピーします。

$ oc rsync /tmp/jenkins-backup/jenkins jenkins-1-37nux:/var/lib

注記注記

アプリケーションによっては、アプリケーションを再起動する必要があります。

3. オプションとして、新規データを使ってアプリケーションを再起動します。

$ oc delete pod jenkins-1-37nux

または、デプロイメントを 0 にスケールダウンしてから再びスケールアップします。

$ oc scale --replicas=0 dc/jenkins$ oc scale --replicas=1 dc/jenkins

3.10. PERSISTENT VOLUME CLAIM (永続ボリューム要求、PVC) の復元

このトピックでは、データを復元するための 2 つの方法について説明します。最初の方法ではファイルを削除してから、ファイルを予想される場所に戻します。2 つ目の例では、PVC を移行する方法を示します。この移行は、ストレージを移動する必要がある場合や、バックアップストレージがなくなるなどの障害発生時の状況で実行されます。

データをアプリケーションに復元する手順について、特定のアプリケーションについての復元手順を確認してください。

3.10.1. ファイルの既存 PVC への復元

手順

1. ファイルを削除します。

$ oc rsh demo-2-fxx6dsh-4.2$ ls */opt/app-root/src/uploaded/*lost+found ocp_sop.txt


48

sh-4.2$ *rm -rf /opt/app-root/src/uploaded/ocp_sop.txt*sh-4.2$ *ls /opt/app-root/src/uploaded/*lost+found

2. PVC にあったファイルの rsync バックアップが含まれるサーバーのファイルを置き換えます。

$ oc rsync uploaded demo-2-fxx6d:/opt/app-root/src/

3. oc rsh を使用してファイルが Pod に戻されていることを確認し、Pod に接続してディレクトリーのコンテンツを表示します。

$ oc rsh demo-2-fxx6dsh-4.2$ *ls /opt/app-root/src/uploaded/*lost+found ocp_sop.txt

3.10.2. データの新規 PVC への復元

以下の手順では、新規 pvc が作成されていることを前提としています。

手順

1. 現在定義されている claim-name を上書きします。

$ oc set volume dc/demo --add --name=persistent-volume \ --type=persistentVolumeClaim --claim-name=filestore \ --mount-path=/opt/app-root/src/uploaded --overwrite

2. Pod が新規 PVC を使用していることを確認します。

$ oc describe dc/demoName: demoNamespace: testCreated: 3 hours agoLabels: app=demoAnnotations: openshift.io/generated-by=OpenShiftNewAppLatest Version: 3Selector: app=demo,deploymentconfig=demoReplicas: 1Triggers: Config, Image(demo@latest, auto=true)Strategy: RollingTemplate: Labels: app=demo deploymentconfig=demo Annotations: openshift.io/container.demo.image.entrypoint=["container-entrypoint","/bin/sh","-c","$STI_SCRIPTS_PATH/usage"] openshift.io/generated-by=OpenShiftNewApp Containers: demo: Image: docker-registry.default.svc:5000/test/demo@sha256:0a9f2487a0d95d51511e49d20dc9ff6f350436f935968b0c83fcb98a7a8c381a Port: 8080/TCP Volume Mounts: /opt/app-root/src/uploaded from persistent-volume (rw)


49

Environment Variables: <none> Volumes: persistent-volume: Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) *ClaimName: filestore* ReadOnly: false...omitted...

3. デプロイメント設定では新規の pvc を使用しているため、oc rsync を実行してファイルを新規の pvc に配置します。

$ oc rsync uploaded demo-3-2b8gs:/opt/app-root/src/sending incremental file listuploaded/uploaded/ocp_sop.txtuploaded/lost+found/

sent 181 bytes received 39 bytes 146.67 bytes/sectotal size is 32 speedup is 0.15

4. oc rsh を使用してファイルが Pod に戻されていることを確認し、Pod に接続してディレクトリーのコンテンツを表示します。

$ oc rsh demo-3-2b8gssh-4.2$ ls /opt/app-root/src/uploaded/lost+found ocp_sop.txt


50

第4章マスターホストの置き換え失敗したマスターホストを置き換えることができます。

まず、失敗したマスターホストをクラスターから削除し、次に置き換えマスターホストを追加します。失敗したマスターホストが etcd を実行していた場合、etcd を新規のマスターホストに追加して etcdを拡張します。

重要重要

このトピックのすべてのセクションを完了する必要があります。

4.1. マスターホストの使用の終了

マスターホストは OpenShift Container Platform API およびコントローラーサービスなどの重要なサービスを実行します。マスターホストの使用を終了するには、これらのサービスが停止している必要があります。

OpenShift Container Platform API サービスはアクティブ/アクティブサービスであるため、サービスを停止しても、要求が別のマスターサーバーに送信される限り環境に影響はありません。ただし、OpenShift Container Platform コントローラーサービスはアクティブ/パッシブサービスであり、サービスは etcd を利用してアクティブなマスターを判別します。

複数マスターアーキテクチャーでマスターホストの使用を終了するには、新しい接続でのマスターの使用を防ぐためにマスターをロードバランサープールから削除することが関係します。このプロセスは使用されるロードバランサーによって大きく異なります。以下の手順では、マスターの haproxy からの削除についての詳しく説明しています。OpenShift Container Platform がクラウドプロバイダーで実行されている場合や、F5 アプライアンスを使用する場合は、特定の製品ドキュメントを参照してマスターをローテーションから削除するようにしてください。

手順手順

1. /etc/haproxy/haproxy.cfg 設定ファイルで backend セクションを削除します。たとえば、haproxy を使用してmaster-0.example.com という名前のマスターの使用を終了する場合、ホスト名が以下から削除されていることを確認します。

backend mgmt8443 balance source mode tcp # MASTERS 8443 server master-1.example.com 192.168.55.12:8443 check server master-2.example.com 192.168.55.13:8443 check

2. 次に、haproxy サービスを再起動します。

$ sudo systemctl restart haproxy

3. マスターがロードバランサーから削除される場合、定義ファイルを静的 Pod のディレクトリー/etc/origin/node/pods から移動して API およびコントローラーサービスを無効にします。

# mkdir -p /etc/origin/node/pods/disabled# mv /etc/origin/node/pods/controller.yaml /etc/origin/node/pods/disabled/:+

4. マスターホストはスケジュール可能な OpenShift Container Platform ノードであるため、

第第4章章マスターホストの置き換えマスターホストの置き換え

51

4. マスターホストはスケジュール可能な OpenShift Container Platform ノードであるため、「ノードホストの使用の終了」セクションの手順に従ってください。

5. マスターホストを /etc/ansible/hosts Ansible インベントリーファイルの [masters] および [nodes] グループから削除し、このインベントリーファイルを使用して Ansible タスクを実行する場合の問題を回避できます。

警告警告

Ansible インベントリーファイルに一覧表示される最初のマスターホストの使用を終了するには、とくに注意が必要になります。

/etc/origin/master/ca.serial.txt ファイルは Ansible ホストインベントリーに一覧表示される最初のマスターでのみ生成されます。最初のマスターホストの使用を終了する場合は、このプロセスの実行前に /etc/origin/master/ca.serial.txt ファイルを残りのマスターホストにコピーします。

重要重要

複数のマスターを実行する OpenShift Container Platform 3.11 クラスターでは、マスターノードの 1 つの /etc/origin/master、/etc/etcd/ca および /etc/etcd/generated_certs に追加の CA 証明書が含まれます。これらはアプリケーションノードおよび etcd ノードのスケールアップ操作に必要であり、CAホストマスターが非推奨になる場合に別のマスターで復元される必要があります。

6. kubernetes サービスにはマスターホスト IP がエンドポイントとして含まれています。マスターの使用が適切に終了していることを確認するには、kubernetes サービスの出力を確認して、使用が終了したマスターが削除されているかどうかを確認します。

$ oc describe svc kubernetes -n defaultName: kubernetesNamespace: defaultLabels: component=apiserver provider=kubernetesAnnotations: <none>Selector: <none>Type: ClusterIPIP: 10.111.0.1Port: https 443/TCPEndpoints: 192.168.55.12:8443,192.168.55.13:8443Port: dns 53/UDPEndpoints: 192.168.55.12:8053,192.168.55.13:8053Port: dns-tcp 53/TCPEndpoints: 192.168.55.12:8053,192.168.55.13:8053Session Affinity: ClientIPEvents: <none>

マスターの使用が正常に終了している場合、マスターが以前に実行されていたホストを安全に


52

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/day_two_operations_guide/#deprecating-node_deprecating-etcd

マスターの使用が正常に終了している場合、マスターが以前に実行されていたホストを安全に削除できます。

4.2. ホストの追加

scaleup.yml Playbook を実行して新規ホストをクラスターに追加できます。この Playbook はマスターをクエリーし、新規ホストの新規証明書を生成し、配布してから、設定 Playbook を新規ホストにのみ実行します。scaleup.yml Playbook を実行する前に、前提条件となる「ホストの準備」手順をすべて完了してください。

重要重要

scaleup.yml の Playbook は新規ホストの設定のみを設定します。マスターサービスのNO_PROXY の更新やマスターサービスの再起動は行いません。

scaleup.yml Playbook を実行するには、現在のクラスター設定を表す既存のインベントリーファイル(/etc/ansible/hosts など) が必要です。以前に atomic-openshift-installer コマンドを使用してインストールを実行した場合は、~/.config/openshift/hosts を調べて、インストーラーによって生成された最新のインベントリーファイルを見つけ、そのファイルをインベントリーファイルとして使用することができます。このファイルは必要に応じて変更することができます。後で ansible-playbook を実行する際に -i オプションを使用してそのファイルの場所を指定する必要があります。

重要重要

ノードの推奨される最大数については、「cluster maximums」のセクションを参照してください。

手順手順

1. openshift-ansible パッケージを更新して最新の Playbook を取得します。

# yum update openshift-ansible

2. /etc/ansible/hosts ファイルを編集し、new_<host_type> を [OSEv3:children] セクションに追加します。たとえば、新規ノードホストを追加するには、new_nodes を追加します。

[OSEv3:children]mastersnodesnew_nodes

新規マスターホストを追加するには、new_masters を追加します。

3. [new_<host_type>] セクションを作成して、新規ホストのホスト情報を指定します。以下の新規ノードの追加例で示されているように、既存のセクションと同じ様になフォーマットにこのセクションをフォーマットします。



53

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/installing_clusters/#preparing-for-advanced-installations-origin

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/scaling_and_performance_guide/#scaling-performance-cluster-maximums

[new_nodes]node3.example.com openshift_node_group_name='node-config-infra'

その他のオプションについては、「ホスト変数の設定」を参照してください。

新規マスターを追加する場合は、[new_masters] セクションと [new_nodes] セクションの両方に新規ホストを追加して、新規マスターホストが OpenShift SDN の一部となるようにします。

[masters]master[1:2].example.com

[new_masters]master3.example.com


[new_nodes]master3.example.com

重要重要

マスターホストに node-role.kubernetes.io/infra=true ラベルを付け、それ以外に専用インフラストラクチャーノードがない場合は、エントリーに openshift_schedulable=true を追加してホストにスケジュール可能であることを示すマークを明示的に付ける必要もあります。そうしないと、レジストリーPod とルーター Pod をどこにも配置できなくなります。

4. Playbook ディレクトリーに切り替え、openshift_node_group.yml Playbook を実行します。インベントリーファイルがデフォルトの /etc/ansible/hosts 以外の場所にある場合は、-i オプションで場所を指定します。

$ cd /usr/share/ansible/openshift-ansible$ ansible-playbook [-i /path/to/file] \ playbooks/openshift-master/openshift_node_group.yml

これにより、新規ノードグループの ConfigMap が作成され、最終的にはホスト上のノードの設定ファイルが作成されます。

注記注記

openshift_node_group.yaml Playbook を実行しても、新規ノードのみが更新されます。これは、クラスター内の既存ノードを更新するために更新することはできません。

5. scaleup.yml Playbook を実行します。インベントリーファイルがデフォルトの/etc/ansible/hosts 以外の場所にある場合は、-i オプションで場所を指定します。



54

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/installing_clusters/#advanced-host-variables


$ ansible-playbook [-i /path/to/file] \ playbooks/openshift-node/scaleup.yml

マスターを追加する場合は、以下を実行します。

$ ansible-playbook [-i /path/to/file] \ playbooks/openshift-master/scaleup.yml

6. EFK スタックをクラスターにデプロイしている場合は、ノードラベルを logging-infra-fluentd=true に設定します。

# oc label node/new-node.example.com logging-infra-fluentd=true

7. Playbook の実行後に、「インストールの検証」を行います。

8. [new_<host_type>] セクションで定義したホストを適切なセクションに移動します。このようにホストを移動することで、このインベントリーファイルを使用するその後の Playbook の実行で、正しくノードが処理されるようになります。[new_<host_type>] セクションは空のままにできます。たとえば、新規ノードを追加する場合は以下のように指定します。

[nodes]master[1:3].example.comnode1.example.com openshift_node_group_name='node-config-compute'node2.example.com openshift_node_group_name='node-config-compute'node3.example.com openshift_node_group_name='node-config-compute'infra-node1.example.com openshift_node_group_name='node-config-infra'infra-node2.example.com openshift_node_group_name='node-config-infra'

[new_nodes]

4.3. ETCD のスケーリング

etcd クラスターは、リソースを etcd ホストに追加して垂直的に拡張することも、etcd ホストを追加して水平的に拡張することもできます。

注記注記

etcd が使用する投票システムのために、クラスターには常に奇数のメンバーが含まれている必要があります。

奇数の etcd ホストを含むクラスターの場合、フォールトトレランスに対応できます。奇数の etcd ホストがあることで、クォーラム (定足数) に必要な数が変わることはありませんが、障害発生時の耐性が高まります。たとえば、クラスターが 3 メンバーで構成される場合、クォーラム (定足数) は 2 で、1 メンバーが障害耐性用になります。これにより、クラスターはメンバーの 2 つが正常である限り、機能し続けます。

3 つの etcd ホストで構成される実稼働クラスターの使用が推奨されます。

新規ホストには、新規の Red Hat Enterprise Linux version 7 専用ホストが必要です。etcd ストレージは最大のパフォーマンスを達成できるように SSD ディスクおよび /var/lib/etcd でマウントされる専用ディスクに置かれる必要があります。


55

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/installing_clusters/#advanced-verifying-the-installation

前提条件前提条件

1. 新規 etcd ホストを追加する前に、「etcd 設定およびデータのバックアップ」を行ってデータの損失を防ぎます。

2. 現在の etcd クラスターステータスを確認し、新規ホストを正常でないクラスターに追加することを防ぎます。以下のコマンドを実行します。

# ETCDCTL_API=3 etcdctl --cert="/etc/etcd/peer.crt" \ --key=/etc/etcd/peer.key \ --cacert="/etc/etcd/ca.crt" \ --endpoints="https://*master-0.example.com*:2379,\ https://*master-1.example.com*:2379,\ https://*master-2.example.com*:2379" endpoint healthhttps://master-0.example.com:2379 is healthy: successfully committed proposal: took = 5.011358mshttps://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.305173mshttps://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.388772ms

3. scaleup Playbook を実行する前に、新規ホストが適切な Red Hat ソフトウェアチャンネルに登録されていることを確認します。

# subscription-manager register \ --username=*<username>* --password=*<password>*# subscription-manager attach --pool=*<poolid>*# subscription-manager repos --disable="*"# subscription-manager repos \ --enable=rhel-7-server-rpms \ --enable=rhel-7-server-extras-rpms

etcd は rhel-7-server-extras-rpms ソフトウェアチャンネルでホストされています。

4. 未使用の etcd メンバーがすべて etcd クラスターから削除されていることを確認します。これは、scaleup Playbook を実行する前に実行する必要があります。

a. etcd メンバーを一覧表示します。

# etcdctl --cert="/etc/etcd/peer.crt" --key="/etc/etcd/peer.key" \ --cacert="/etc/etcd/ca.crt" --endpoints=ETCD_LISTEN_CLIENT_URLS member list -w table

該当する場合は、未使用の etcd メンバー ID をコピーします。

b. 以下のコマンドで ID を指定して、未使用のメンバーを削除します。

# etcdctl --cert="/etc/etcd/peer.crt" --key="/etc/etcd/peer.key" \ --cacert="/etc/etcd/ca.crt" --endpoints=ETCD_LISTEN_CLIENT_URL member remove UNUSED_ETCD_MEMBER_ID

5. 現在の etcd ノードで etcd および iptables をアップグレードします。

# yum update etcd iptables-services


56

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/day_two_operations_guide/#backing-up-etcd_environment-backup

1 2 3

6. etcd ホストの /etc/etcd 設定をバックアップします。

7. 新規 etcd メンバーが OpenShift Container Platform ノードでもある場合は、必要な数のホストをクラスターに追加します。

8. この手順の残りでは 1 つのホストを追加していることを前提としていますが、複数のホストを追加する場合は、各ホストですべての手順を実行します。


手順


[OSEv3:children]mastersnodesetcdnew_etcd 1










[etcd]master-0.example.com


57

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-adding-hosts-to-cluster

master-1.example.commaster-2.example.cometcd0.example.com







手順現在の etcd クラスターの変更etcd 証明書を作成するには、値を環境の値に置き換えて openssl コマンドを実行します。




注記注記






# openssl ca -name etcd_ca -config ${OPENSSLCFG} \


58

1

-out ${PREFIX}server.crt \ -in ${PREFIX}server.csr \ -extensions etcd_v3_ca_server -batch











$ ss -l4n | grep 2380



d. member list コマンドを再実行し、ピア URL に localhost が含まれなくなるようにしま


59

1



警告警告








ETCD_NAME






60














注記注記



61

警告警告

















62


# ETCDCTL_API=3 etcdctl --cert="/etc/etcd/peer.crt" \ --key=/etc/etcd/peer.key \ --cacert="/etc/etcd/ca.crt" \ --endpoints="https://*master-0.example.com*:2379,\ https://*master-1.example.com*:2379,\ https://*master-2.example.com*:2379,\ https://*etcd0.example.com*:2379"\ endpoint healthhttps://master-0.example.com:2379 is healthy: successfully committed proposal: took = 5.011358mshttps://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.305173mshttps://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.388772mshttps://etcd0.example.com:2379 is healthy: successfully committed proposal: took = 1.498829ms



etcdClientInfo: ca: master.etcd-ca.crt certFile: master.etcd-client.crt keyFile: master.etcd-client.key urls: - https://master-0.example.com:2379 - https://master-1.example.com:2379 - https://master-2.example.com:2379 - https://etcd0.example.com:2379




警告警告




63





64

第5章ユーザーの管理

5.1. 概要

ユーザーとは、OpenShift Container Platform API と対話するエンティティーです。ユーザーは、アプリケーションを開発する開発者の場合もあれば、クラスターを管理する管理者の場合もあります。ユーザーは、グループのすべてのメンバーに適用されるパーミッションを設定するグループに割り当てることができます。たとえば、API アクセスをグループに付与して、そのグループのすべてのメンバーにAPI アクセスを付与することができます。

このトピックでは、ユーザーアカウントの管理について説明します。これには、OpenShift ContainerPlatform で新規ユーザーアカウントを作成する方法およびそれらを削除する方法が含まれます。

5.2. ユーザーの作成

ユーザーの作成プロセスは、設定されるアイデンティティープロバイダーによって異なります。デフォルトで、OpenShift Container Platform は、すべてのユーザー名およびパスワードのアクセスを拒否する DenyAll アイデンティティープロバイダーを使用します。

以下のプロセスでは、新規ユーザーを作成してからロールをそのユーザーに追加します。

1. アイデンティティープロバイダーに応じたユーザーアカウントを作成します。これは、アイデンティティープロバイダー設定の一部として使用される mappingmethod によって異なります。

2. 新規ユーザーに必要なロールを付与します。

# oc create clusterrolebinding <clusterrolebinding_name> \ --clusterrole=<role> --user=<user>

ここで、--clusterrole オプションは必要なクラスターロールになります。たとえば、新規ユーザーに対して、クラスター内のすべてに対するアクセスを付与する cluster-admin 権限を付与するには、以下を実行します。

# oc create clusterrolebinding registry-controller \ --clusterrole=cluster-admin --user=admin

ロールの説明および一覧については、Architecture Guide のクラスターロールおよびローカルロールについてのセクションを参照してください。

クラスター管理者は、各ユーザーのアクセスレベルの管理も実行できます。

注記注記

アイデンティティープロバイダーおよび定義されたグループ構造によっては、一部のロールがユーザーに自動的に付与される場合があります。詳細は、グループの LDAP との同期についてのセクションを参照してください。

5.3. ユーザーおよび ID リストの表示

OpenShift Container Platform のユーザー設定は、OpenShift Container Platform 内の複数の場所に保存されます。アイデンティティープロバイダーの種類を問わず、OpenShift Container Platform はロールベースのアクセス制御 (RBAC) 情報およびグループメンバーシップなどの詳細情報を内部に保存しま

第第5章章ユーザーの管理ユーザーの管理

65

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#architecture-core-concepts-projects-and-users

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#identity-providers_parameters

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#identity-providers_parameters

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#roles

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-syncing-groups-with-ldap

す。ユーザー情報を完全に削除するには、ユーザーアカウントに加えてこのデータも削除する必要があります。

OpenShift Container Platform では、2 つのオブジェクトタイプ (user および identity) に、アイデンティティープロバイダー外のユーザーデータが含まれます。

ユーザーの現在のリストを取得するには、以下を実行します。

$ oc get userNAME UID FULL NAME IDENTITIESdemo 75e4b80c-dbf1-11e5-8dc6-0e81e52cc949 htpasswd_auth:demo

ID の現在のリストを取得するには、以下を実行します。

$ oc get identityNAME IDP NAME IDP USER NAME USER NAME USER UIDhtpasswd_auth:demo htpasswd_auth demo demo 75e4b80c-dbf1-11e5-8dc6-0e81e52cc949

2 つのオブジェクトタイプ間で一致する UID があることに注意してください。OpenShift ContainerPlatform の使用を開始した後に認証プロバイダーの変更を試行する場合で重複するユーザー名がある場合、そのユーザー名は、ID リストに古い認証方式を参照するエントリーがあるために機能しなくなります。

5.4. グループの作成

ユーザーは OpenShift Container Platform に要求するエンティティーである一方で、ユーザーのセットで構成される 1 つの以上のグループに編成することもできます。グループは、許可ポリシーなどの場合のように数多くのユーザーを 1 度に管理する際や、パーミッションを複数のユーザーに 1 度に付与する場合などに役立ちます。

組織が LDAP を使用している場合、LDAP レコードの OpenShift Container Platform に対する同期を実行し、複数のグループを 1 つの場所で設定できるようにすることができます。この場合、ユーザーについての情報が MDAP サーバーにあることが前提となります。詳細は、「Synching groups with LDAP(グループの LDAP との同期)」セクションを参照してください。

LDAP を使用していない場合は、以下の手順を使用してグループを手動で作成します。

新規グループを作成するには、以下を実行します。

# oc adm groups new <group_name> <user1> <user2>

たとえば、west グループを作成し、そのグループ内に john および betty ユーザーを置くには、以下を実行します。

# oc adm groups new west john betty

グループが作成されたことを確認し、グループに関連付けられたユーザーを一覧表示するには、以下を実行します。

# oc get groupsNAME USERSwest john, betty


66

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-syncing-groups-with-ldap

次のステップ:

ロールバインディングの管理

5.5. ユーザーおよびグループラベルの管理

ラベルをユーザーまたはグループに追加するには、以下を実行します。

$ oc label user/<user_name> <label_name>=<label_value>

たとえばユーザー名が theuser で、ラベルが level=gold の場合には、以下のようになります。

$ oc label user/theuser level=gold

ラベルを削除するには、以下を実行します。

$ oc label user/<user_name> <label_name>-

ユーザーまたはグループのラベルを表示するには、以下を実行します。

$ oc describe user/<user_name>

5.6. ユーザーの削除

ユーザーを削除するには、以下を実行します。

1. ユーザーレコードを削除します。

$ oc delete user demouser "demo" deleted

2. ユーザー ID を削除します。ユーザーの ID は使用するアイデンティティープロバイダーに関連付けられます。oc get userでユーザーレコードからプロバイダー名を取得します。

この例では、アイデンティティープロバイダー名は htpasswd_auth です。コマンドは、以下のようになります。

# oc delete identity htpasswd_auth:demoidentity "htpasswd_auth:demo" deleted

この手順を省略すると、ユーザーは再度ログインできなくなります。

上記の手順の完了後は、ユーザーが再びログインすると、新規のアカウントが OpenShift ContainerPlatform に作成されます。

ユーザーの再ログインを防ごうとする場合 (たとえば、ある社員が会社を退職し、そのアカウントを永久に削除する必要がある場合)、そのユーザーを、設定されたアイデンティティープロバイダーの認証バックエンド (htpasswd、kerberos その他) から削除することもできます。

たとえば htpasswd を使用している場合、該当のユーザー名とパスワードで OpenShift ContainerPlatform に設定された htpasswd ファイルのエントリーを削除します。

第第5章章ユーザーの管理ユーザーの管理

67

Lightweight Directory Access Protocol (LDAP) または Red Hat Identity Management (IdM) などの外部ID管理については、ユーザー管理ツールを使用してユーザーエントリーを削除します。


68

第6章プロジェクトの管理

6.1. 概要

OpenShift Container Platform では、プロジェクトは関連オブジェクトを分類し、分離するために使用されます。管理者は、開発者に特定プロジェクトへのアクセスを付与し、開発者の独自プロジェクトの作成を許可したり、個別プロジェクト内の管理者権限を付与したりできます。

6.2. プロジェクトのセルフプロビジョニング

開発者の独自プロジェクトの作成を許可することができます。テンプレートに基づいてプロジェクトをプロビジョニングするエンドポイントがあります。Web コンソールおよび oc new-project コマンドは、開発者による新規プロジェクトの作成時にこのエンドポイントを使用します。

6.2.1. 新規プロジェクトのテンプレートの変更

API サーバーは、master-config.yaml ファイルの projectRequestTemplate パラメーターで識別されるテンプレートに基づいてプロジェクトを自動的にプロビジョニングします。パラメーターが定義されない場合、API サーバーは要求される名前でプロジェクトを作成するデフォルトテンプレートを作成し、要求するユーザーをプロジェクトの「admin (管理者)」ロールに割り当てます。

独自のカスタムプロジェクトテンプレートを作成するには、以下を実行します。

1. 現在のデフォルトプロジェクトテンプレートを使って開始します。

$ oc adm create-bootstrap-project-template -o yaml > template.yaml

2. オブジェクトを追加するか、または既存オブジェクトを変更することにより、テキストエディターで template.yaml ファイルを変更します。

3. テンプレートを読み込みます。

$ oc create -f template.yaml -n default

4. 読み込まれたテンプレートを参照するよう master-config.yaml ファイルを変更します。

...projectConfig: projectRequestTemplate: "default/project-request" ...

プロジェクト要求が送信されると、API はテンプレートで以下のパラメーターを置き換えます。

パラメーターパラメーター説明説明

PROJECT_NAME プロジェクトの名前。必須。

PROJECT_DISPLAYNAME プロジェクトの表示名。空にできます。

PROJECT_DESCRIPTION プロジェクトの説明。空にできます。

第第6章章プロジェクトの管理プロジェクトの管理

69

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-templates

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-projects

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#master-node-config-project-config

PROJECT_ADMIN_USER 管理ユーザーのユーザー名。

PROJECT_REQUESTING_USER 要求するユーザーのユーザー名。


API へのアクセスは、self-provisioner ロールと self-provisioners のクラスターのロールバインディングで開発者に付与されます。デフォルトで、このロールはすべての認証された開発者が利用できます。

6.2.2. セルフプロビジョニングの無効化

認証されたユーザーグループによる新規プロジェクトのセルフプロビジョニングを禁止することができます。

1. cluster-admin 権限を持つユーザーとしてログインします。

2. self-provisioners clusterrolebinding usage を確認します。以下のコマンドを実行してから、self-provisioners セクションの Subjects を確認します。

$ oc describe clusterrolebinding.rbac self-provisioners

Name: self-provisionersLabels: <none>Annotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: self-provisionerSubjects: Kind Name Namespace ---- ---- --------- Group system:authenticated:oauth

3. self-provisioner クラスターロールをグループ system:authenticated:oauth から削除します。

self-provisioners クラスターロールバインディングが self-provisioner ロールのみを system:authenticated:oauth グループにバインドする場合、以下のコマンドを実行します。

$ oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects": null}'

self-provisioners クラスターロールバインディングが self-provisioner ロールを system:authenticated:oauth グループ以外のユーザー、グループまたはサービスアカウントにバインドする場合、以下のコマンドを実行します。

$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth

4. projectRequestMessage パラメーター値を master-config.yaml ファイルに設定し、開発者に対して新規プロジェクトの要求方法を指示します。このパラメーター値は、ユーザーのプロジェクトのセルフプロビジョニング試行時に web コンソールやコマンドラインに表示される文字列です。以下のメッセージのいずれかを使用できる可能性があります。


70



プロジェクトを要求するには、システム管理者 ([email protected]) に問い合わせてください。

新規プロジェクトを要求するには、https://internal.example.com/openshift-project-request にあるプロジェクト要求フォームに記入します。

サンプルサンプル YAML ファイルファイル

5. ロールへの自動更新を防ぐには、self-provisioners クラスターロールバインディングを編集します。自動更新により、クラスターロールがデフォルトの状態にリセットされます。

ロールバインディングをコマンドラインで更新するには、以下を実行します。

i. 以下のコマンドを実行します。

$ oc edit clusterrolebinding.rbac self-provisioners

ii. 表示されるロールバインディングで、以下の例のように rbac.authorization.kubernetes.io/autoupdate パラメーター値を false に設定します。

単一コマンドを使用してロールバインディングを更新するには、以下を実行します。

$ oc patch clusterrolebinding.rbac self-provisioners -p '{ "metadata": { "annotations": { "rbac.authorization.kubernetes.io/autoupdate": "false" } } }'

6.3. ノードセレクターの使用

ノードセレクターは、Pod の配置を制御するためにラベルが付けられたノードと併用されます。

注記注記

ラベルは、クラスターインストールの実行時に割り当てるか、またはインストール後にノードに追加することができます。

6.3.1. クラスター全体でのデフォルトノードセレクターの設定

クラスター管理者は、クラスター全体でのノードセレクターを使用して Pod の配置を特定ノードに制限することができます。

/etc/origin/master/master-config.yaml でマスター設定ファイルを編集し、デフォルトノードセレク

...projectConfig: ProjectRequestMessage: "message" ...

apiVersion: authorization.openshift.io/v1kind: ClusterRoleBindingmetadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "false"...


71

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/installing_clusters/#configuring-node-host-labels

/etc/origin/master/master-config.yaml でマスター設定ファイルを編集し、デフォルトノードセレクターの値を追加します。これは、指定された nodeSelector 値なしにすべてのプロジェクトで作成された Pod に適用されます。

...projectConfig: defaultNodeSelector: "type=user-node,region=east"...

変更を有効にするために OpenShift サービスを再起動します。


6.3.2. プロジェクト全体でのノードセレクターの設定

ノードセレクターを使って個々のプロジェクトを作成するには、プロジェクトの作成時に --node-selector オプションを使用します。たとえば、複数のリージョンを含む OpenShift Container Platformトポロジーがある場合、ノードセレクターを使用して、特定リージョンのノードにのみ Pod をデプロイするよう特定の OpenShift Container Platform プロジェクトを制限することができます。

以下では、myproject という名前の新規プロジェクトを作成し、Pod を user-node および east のラベルが付けられたノードにデプロイするように指定します。

$ oc adm new-project myproject \ --node-selector='type=user-node,region=east'

いったんこのコマンドが実行されると、これが指定プロジェクト内にあるすべての Pod に対して管理者が設定するノードセレクターになります。

注記注記

new-project サブコマンドはクラスター管理者および開発者コマンドの oc adm と oc の両方で利用できますが、oc adm コマンドのみがノードセレクターを使った新規プロジェクトの作成に利用できます。new-project サブコマンドは、プロジェクトのセルフプロビジョニング時にプロジェクト開発者が利用することはできません。

oc adm new-project コマンドを使用すると、annotation セクションがプロジェクトに追加されます。プロジェクトを編集し、デフォルトを上書きするように openshift.io/node-selector 値を編集できます。

...metadata: annotations: openshift.io/node-selector: type=user-node,region=east...

また、以下のコマンドを使用して既存プロジェクトの namespace のデフォルト値を上書きできます。

# oc patch namespace myproject -p \ '{"metadata":{"annotations":{"openshift.io/node-selector":"node-role.kubernetes.io/infra=true"}}}'

openshift.io/node-selector が空の文字列 (oc adm new-project --node-selector="") に設定される場


72

合、プロジェクトには、クラスター全体のデフォルトが設定されている場合でも管理者設定のノードセレクターはありません。これは、クラスター管理者はデフォルトを設定して開発者のプロジェクトをノードのサブセットに制限したり、インフラストラクチャーまたは他のプロジェクトでクラスター全体をスケジュールしたりできることを意味します。

6.3.3. 開発者が指定するノードセレクター

OpenShift Container Platform 開発者は、追加でノードを制限する必要がある場合に Pod 設定でのノードセレクターの設定を行うことができます。これはプロジェクトノードセレクターに追加されるものです。つまり、ノードセレクターの値を持つすべてのプロジェクトについて依然としてノードセレクターの値を指定できることを意味します。

たとえば、プロジェクトが上記のアノテーションで作成 (openshift.io/node-selector: type=user-node,region=east) されており、開発者が別のノードセレクターをそのプロジェクトの Pod に設定する場合 (例: clearance=classified)、Pod はこれらの 3 つのラベル (type=user-node、region=east、および clearance=classified) を持つノードにのみスケジュールされます。region=west が Pod に設定されている場合、Pod はラベル region=east および region=west を持つノードを要求しても成功しません。ラベルは 1 つの値にのみ設定できるため、Pod はスケジュールされません。

6.4. ユーザーあたりのセルフプロビジョニングされたプロジェクト数の制限

指定されるユーザーが要求するセルフプロビジョニングされたプロジェクトの数は、ProjectRequestLimit 受付制御プラグインで制限できます。

重要重要

プロジェクトの要求テンプレートが、「新規プロジェクトのテンプレートの変更」で説明されるプロセスを使用して OpenShift Container Platform 3.1 (またはそれ以前のバージョン) で作成される場合、生成されるテンプレートには、ProjectRequestLimitConfigに使用されるアノテーション openshift.io/requester: ${PROJECT_REQUESTING_USER} が含まれません。アノテーションは追加する必要があります。

ユーザーの制限を指定するには、設定をマスター設定ファイル (/etc/origin/master/master-config.yaml) 内のプラグインに指定する必要があります。プラグインの設定は、ユーザーラベルのセレクターの一覧および関連付けられるプロジェクト要求の最大数を取ります。

セレクターは順番に評価されます。現在のユーザーに一致する最初のセレクターは、プロジェクトの最大数を判別するために使用されます。セレクターが指定されていない場合、制限はすべてのユーザーに適用されます。プロジェクトの最大数が指定されていない場合、無制限のプロジェクトが特定のセレクターに対して許可されます。

以下の設定は、ユーザーあたりのグローバル制限を 2 プロジェクトに設定し、ラベル level=advancedを持つユーザーに対して 10 プロジェクト、ラベル level=admin を持つユーザーに対して無制限のプロジェクトを許可します。

admissionConfig: pluginConfig: ProjectRequestLimit: configuration: apiVersion: v1 kind: ProjectRequestLimitConfig limits:


73

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#assigning-pods-to-specific-nodes

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#architecture-additional-concepts-admission-controllers

1

2

3

セレクター level=admin の場合、maxProjects は指定されません。これは、このラベルを持つユーザーにはプロジェクト要求の最大数が設定されないことを意味します。

セレクター level=advanced の場合、最大数の 10 プロジェクトが許可されます。

3 つ目のエントリーにはセレクターが指定されていません。これは、セレクターが直前の 2 つのルールを満たさないユーザーに適用されることを意味します。ルールは順番に評価されるため、このルールは最後に指定する必要があります。

注記注記

「ユーザーおよびグループラベルの管理」では、ユーザーおよびグループのラベルを追加し、削除し、表示する方法について詳述しています。

変更を加えた後にそれらの変更を有効にするには、OpenShift Container Platform を再起動します。


6.5. サービスアカウント別のセルフプロビジョニングされたプロジェクトの有効化および制限

デフォルトで、サービスアカウントはプロジェクトを作成できません。ただし、管理者はサービスアカウント別にこの機能を有効でき、指定されるサービスアカウントが要求するセルフプロビジョニングされたプロジェクトの数は、ProjectRequestLimit 受付制御プラグインで制限できます。

注記注記

サービスアカウントがプロジェクトを作成することを許可される場合、プロジェクトエディターがラベルを操作する可能性があるため、プロジェクトのそれらのラベルを信頼することはできません。

1. プロジェクトにサービスアカウントを作成します (存在しない場合)。

$ oc create sa <sa_name>

2. cluster-admin 権限を持つユーザーとして、self-provisioner クラスターロールをサービスアカウントに追加します。

$ oc adm policy \ add-cluster-role-to-user self-provisioner \ system:serviceaccount:<project>:<sa_name>

3. /etc/origin/master/master-config.yaml のマスター設定ファイルを編集

- selector: level: admin 1 - selector: level: advanced 2 maxProjects: 10 - maxProjects: 2 3


74


し、ProjectRequestLimit セクションの maxProjectsForServiceAccounts パラメーター値を、任意の指定のセルフプロビジョニングされたサービスが作成できるプロジェクトの最大数に設定します。たとえば、以下の設定は、サービスアカウントごとにグローバル制限の 3 つのプロジェクトを設定します。

4. 変更を保存した後に、それらの変更を有効にするには、OpenShift Container Platform を再起動します。


5. サービスアカウントを使用してログインし、新規プロジェクトを作成して変更が適用されていることを確認します。

a. トークンを使用し、サービスアカウントを使ってログインします。

$ oc login --token <token>

b. 新規プロジェクトを作成します。

$ oc new-project <project_name>

admissionConfig: pluginConfig: ProjectRequestLimit: configuration: apiVersion: v1 kind: ProjectRequestLimitConfig maxProjectsForServiceAccounts: 3


75

第7章 POD の管理

7.1. 概要

このトピックでは、Pod を 1 回実行する場合の期間や使用可能な帯域幅を含む Pod の管理について説明します。

7.2. POD の表示

コンテナーのランタイム環境を提供する、Pod についての使用状況の統計を表示できます。これらの使用状況の統計には CPU、メモリー、およびストレージの消費量が含まれます。


$ oc adm top podsNAME CPU(cores) MEMORY(bytes)hawkular-cassandra-1-pqx6l 219m 1240Mihawkular-metrics-rddnv 20m 1765Miheapster-n94r4 3m 37Mi

ラベルを持つ Pod の使用状況の統計を表示するには、以下を実行します。

$ oc adm top pod --selector=''

フィルターするのに使用するセレクター (ラベルクエリー) を選択する必要があります。=、==、および != をサポートします。

注記注記

使用状況の統計を閲覧するには、cluster-reader パーミッションがなければなりません。

注記注記

使用状況の統計を閲覧するには、metrics-server がインストールされている必要があります。「Horizontal Pod Autoscaler の要件」を参照してください。

7.3. 1 回実行 (RUN-ONCE) POD 期間の制限

OpenShift Container Platform は 1 回実行 (run-once) Pod を使用して Pod のデプロイやビルドの実行などのタスクを実行します。1 回実行 (run-once) Pod は、RestartPolicy が Never または OnFailure のPod です。

クラスター管理者は RunOnceDuration の受付制御プラグインを使用し、1 回実行 (run-once) Pod の有効期間の制限を強制的に実行できます。期限が切れると、クラスターはそれらの Pod をアクティブに終了しようとします。このような制限を設ける主な理由は、ビルドなどのタスクが長い時間にわたって実行されることを防ぐことにあります。

7.3.1. RunOnceDuration プラグインの設定

このプラグインの設定には、1 回実行 (run-once) Pod のデフォルト有効期限を含める必要があります。


76

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#pods

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/developer_guide/#req-for-using-hpas

1

1

このプラグインの設定には、1 回実行 (run-once) Pod のデフォルト有効期限を含める必要があります。この期限はグローバルに実施されますが、プロジェクト別の期限によって置き換えられることがあります。

1 回実行 (run-once) Pod のグローバルのデフォルト値 (秒単位) を指定します。

7.3.2. プロジェクト別のカスタム期間の指定

1 回実行 (run-once) Pod のグローバルな最長期間を設定することに加え、管理者はアノテーション(openshift.io/active-deadline-seconds-override) を特定プロジェクトに追加し、グローバルのデフォルト値を上書きすることができます。

新規プロジェクトの場合、プロジェクト仕様の .yaml ファイルにアノテーションを定義します。

1 回実行 (run-once) Pod のデフォルト有効期限 (秒単位) を 1000 秒に上書きします。上書きに使用する値は、文字列形式で指定される必要があります。

既存プロジェクトの場合、以下を実行します。

oc edit を実行し、openshift.io/active-deadline-seconds-override: 1000 アノテーションをエディターに追加します。

または、以下を実行します。

oc patch コマンドを使用します。

7.3.2.1. Egress ルータールーター Pod のデプロイのデプロイ

例7.1 Egress ルーターの Pod 定義のサンプル

admissionConfig: pluginConfig: RunOnceDuration: configuration: apiVersion: v1 kind: RunOnceDurationConfig activeDeadlineSecondsOverride: 3600 1....

apiVersion: v1kind: Projectmetadata: annotations: openshift.io/active-deadline-seconds-override: "1000" 1 name: myproject

$ oc edit namespace <project-name>

$ oc patch namespace <project_name> -p '{"metadata":{"annotations":{"openshift.io/active-deadline-seconds-override":"1000"}}}'

第第7章章 POD の管理の管理

77

1

2

3

4

apiVersion: v1kind: Podmetadata: name: egress-1 labels: name: egress-1 annotations: pod.network.openshift.io/assign-macvlan: "true"spec: containers: - name: egress-router image: openshift3/ose-egress-router securityContext: privileged: true env: - name: EGRESS_SOURCE 1 value: 192.168.12.99 - name: EGRESS_GATEWAY 2 value: 192.168.12.1 - name: EGRESS_DESTINATION 3 value: 203.0.113.25 nodeSelector: site: springfield-1 4

この Pod で使用するためにクラスター管理者が予約するノードサブセットの IP アドレス。

ノード自体で使用されるデフォルトゲートウェイと同じ値。

Pod の接続は 203.0.113.25 にリダイレクトされます。ソース IP アドレスは 192.168.12.99 です。

Pod はラベルサイトが springfield-1 のノードにのみデプロイされます。

pod.network.openshift.io/assign-macvlan annotation はプライマリーネットワークインターフェースに Macvlan ネットワークインターフェースを作成してから、それを Pod のネットワーク namespace に移行し、egress-router コンテナーを起動します。

注記注記

"true" の周りの引用符をそのまま残します。これらを省略するとエラーが生じます。

Pod には openshift3/ose-egress-router イメージを使用する単一コンテナーが含まれ、そのコンテナーは特権モードで実行されるので、Macvlan インターフェースを設定したり、iptables ルールをセットアップしたりできます。

環境変数は egress-router イメージに対し、使用するアドレスを指示します。これは、EGRESS_SOURCE を IP アドレスとして、また EGRESS_GATEWAY をゲートウェイとして使用するよう Macvlan を設定します。

NAT ルールが設定され、Pod のクラスター IP アドレスの TCP または UDP ポートへの接続が EGRESS_DESTINATION の同じポートにリダイレクトされるようにします。

クラスター内の一部のノードのみが指定されたソース IP アドレスを要求でき、指定されたゲートウェ


78

クラスター内の一部のノードのみが指定されたソース IP アドレスを要求でき、指定されたゲートウェイを使用できる場合、受け入れ可能なノードを示す nodeName または nodeSelector を指定することができます。

7.3.2.2. Egress ルーターサービスのデプロイルーターサービスのデプロイ

通常、egress ルーターを参照するサービスを作成する必要が生じる場合があります (ただし、これは必ずしも必須ではありません)。

apiVersion: v1kind: Servicemetadata: name: egress-1spec: ports: - name: http port: 80 - name: https port: 443 type: ClusterIP selector: name: egress-1

Pod がこのサービスに接続できるようになります。これらの接続は、予約された egress IP アドレスを使用して外部サーバーの対応するポートにリダイレクトされます。

7.3.3. Egress ファイアウォールでの Pod アクセスの制限

OpenShift Container Platform クラスター管理者は egress ポリシーを使用して、一部またはすべてのPod がクラスターからアクセスできる外部アドレスを制限できます。これにより、以下が可能になります。

Pod の対話を内部ホストに制限し、パブリックインターネットへの接続を開始できないようにする。または

Pod の対話をパブリックインターネットに制限し、(クラスター外の) 内部ホストへの接続を開始できないようにする。または

Pod が接続する理由のない指定された内部サブネット/ホストに到達できないようにする。

プロジェクトは複数の異なる egress ポリシーで設定でき、たとえば指定された IP 範囲への <project A> のアクセスを許可する一方で、同じアクセスを <project B> に対して拒否することができます。

注意注意

egress ポリシーで Pod のアクセスを制限するには、ovs-multitenant プラグインを有効にする必要があります。

プロジェクト管理者は、EgressNetworkPolicy オブジェクトを作成することも、プロジェクトで作成するオブジェクトを編集することもできません。また、EgressNetworkPolicy の作成に関連して他のいくつかの制限があります。

1. デフォルトプロジェクト (および oc adm pod-network make-projects-global でグローバルに


79

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-configuring-sdn

1. デフォルトプロジェクト (および oc adm pod-network make-projects-global でグローバルにされたその他のプロジェクト) には egress ポリシーを設定することができません。

2. (oc adm pod-network join-projects を使用して) 2 つのプロジェクトをマージする場合、マージしたプロジェクトのいずれでも egress ポリシーを使用することはできません。

3. いずれのプロジェクトも複数の egress ポリシーオブジェクトを持つことができません。

上記の制限のいずれかに違反すると、プロジェクトの egress ポリシーに障害が発生し、すべての外部ネットワークトラフィックがドロップされる可能性があります。

7.3.3.1. Pod アクセス制限の設定アクセス制限の設定

Pod アクセス制限を設定するには、oc コマンドまたは REST API を使用する必要があります。 oc [create|replace|delete] を使用すると、EgressNetworkPolicy オブジェクトを操作できます。api/swagger-spec/oapi-v1.json ファイルには、オブジェクトの機能方法についての API レベルの詳細情報が含まれます。

Pod のアクセス制限を設定するには、以下を実行します。

1. 対象とするプロジェクトに移動します。

2. Pod の制限ポリシーについての JSON ファイルを作成します。

# oc create -f <policy>.json

3. ポリシーの詳細情報を使って JSON ファイルを設定します。以下は例になります。

{ "kind": "EgressNetworkPolicy", "apiVersion": "v1", "metadata": { "name": "default" }, "spec": { "egress": [ { "type": "Allow", "to": { "cidrSelector": "1.2.3.0/24" } }, { "type": "Allow", "to": { "dnsName": "www.foo.com" } }, { "type": "Deny", "to": { "cidrSelector": "0.0.0.0/0" } }


80

] }}

上記のサンプルがプロジェクトに追加されると、IP 範囲 1.2.3.0/24 およびドメイン名 www.foo.com へのへのトラフィックは許可されますが、その他すべての外部 IP アドレスへのアクセスは拒否されます (ポリシーが外部トラフィックにのみ適用されるので他の Pod へのトラフィックは影響を受けません)。

EgressNetworkPolicy のルールは順番にチェックされ、一致する最初のルールが実施されます。上記の例の 3 つの例を逆順に定義した場合、0.0.0.0/0 ルールが最初にチェックされ、すべてのトラフィックに一致し、それらすべてを拒否するため、1.2.3.0/24 および www.foo.comへのトラフィックは許可されません。

ドメイン名の更新は 30 秒以内に反映されます。上記の例で www.foo.com は 10.11.12.13 に解決されますが、20.21.22.23 に変更されたとします。OpenShift Container Platform では最長30 秒後にこれらの DNS 更新に対応します。

7.4. POD で利用可能な帯域幅の制限

QoS (Quality-of-Service) トラフィックシェーピングを Pod に適用し、その利用可能な帯域幅を効果的に制限することができます。(Pod からの) Egress トラフィックは、設定したレートを超えるパケットを単純にドロップするポリシングによって処理されます。(Pod への) Ingress トラフィックは、データを効果的に処理できるようシェーピングでパケットをキューに入れて処理されます。Pod に設定する制限は、他の Pod の帯域幅には影響を与えません。

Pod の帯域幅を制限するには、以下を実行します。

1. オブジェクト定義 JSON ファイルを作成し、kubernetes.io/ingress-bandwidth および kubernetes.io/egress-bandwidth アノテーションを使用してデータトラフィックの速度を指定します。たとえば、 Pod の egress および ingress の両方の帯域幅を 10M/s に制限するには、以下を実行します。

制限が設定された制限が設定された Pod オブジェクト定義オブジェクト定義

{ "kind": "Pod", "spec": { "containers": [ { "image": "openshift/hello-openshift", "name": "hello-openshift" } ] }, "apiVersion": "v1", "metadata": { "name": "iperf-slow", "annotations": { "kubernetes.io/ingress-bandwidth": "10M", "kubernetes.io/egress-bandwidth": "10M" } }}


81

1

2

3

2. オブジェクト定義を使用して Pod を作成します。

oc create -f <file_or_dir_path>

7.5. POD の DISRUPTION BUDGET (停止状態の予算) の設定

Pod の Disruption Budget (停止状態の予算) は Kubernetes API の一部であり、他のオブジェクトタイプのように oc コマンドで管理できます。この設定により、メンテナンスのためのノードのドレイン(解放) などの操作時に Pod への安全面の各種の制約を指定できます。

PodDisruptionBudget は、同時に起動している必要のあるレプリカの最小数またはパーセンテージを指定する API オブジェクトです。これらをプロジェクトに設定することは、ノードのメンテナンス (クラスターのスケールダウンまたはクラスターのアップグレードなどの実行) 時に役立ち、この設定は(ノードの障害時ではなく) 自発的なエビクションの場合にのみ許可されます。

PodDisruptionBudget オブジェクトの設定は、以下の主要な部分で構成されています。

一連の Pod に対するラベルのクエリー機能であるラベルセレクター。

同期に利用可能にする必要のある Pod の最小数を指定する可用性レベル。

以下は、PodDisruptionBudget リソースのサンプルです。

PodDisruptionBudget は policy/v1beta1 API グループの一部です。

一連のリソースに対するラベルのクエリー。matchLabels と matchExpressions の結果は論理的に結合されます。

同時に利用可能である必要のある Pod の最小数。これには、整数またはパーセンテージ (例: 20%)を指定する文字列を使用できます。

上記のオブジェクト定義で YAML ファイルを作成した場合、これを以下のようにプロジェクトに追加することができます。

$ oc create -f </path/to/file> -n <project_name>

以下を実行して、Pod の disruption budget をすべてのプロジェクトで確認することができます。

$ oc get poddisruptionbudget --all-namespaces

NAMESPACE NAME MIN-AVAILABLE SELECTORanother-project another-pdb 4 bar=footest-project my-pdb 2 foo=bar

apiVersion: policy/v1beta1 1kind: PodDisruptionBudgetmetadata: name: my-pdbspec: selector: 2 matchLabels: foo: bar minAvailable: 2 3


82

http://kubernetes.io/docs/admin/disruptions/

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cli_reference/#object-types

PodDisruptionBudget は、最低でも minAvailable の Pod がシステムで実行されている場合は正常であるとみなされます。この制限を超えるすべての Pod はエビクションの対象となります。

注記注記

Pod の優先順位およびプリエンプションの設定に基づいて、優先順位の低い Pod は Podの Disruption Budget (停止状態の予算) の要件を無視して削除される可能性があります。

7.6. CRITICAL POD の設定

DNS など、クラスターの完全な機能に欠かせないコアコンポーネントであるものの、マスターではなく通常のクラスターノードで実行されるコアコンポーネントが多数あります。クラスターは重要なアドオンがエビクトされると正常な機能を停止する可能性があります。scheduler.alpha.kubernetes.io/critical-pod アノテーションを Pod 仕様に追加し、Deschedulerがこれらの Pod を削除できないようにすることで Pod を Critical Pod にすることができます。

spec: template: metadata: name: critical-pod annotations: scheduler.alpha.kubernetes.io/critical-pod: "true"


83

第8章ネットワークの管理

8.1. 概要

このトピックでは、プロジェクトの分離および発信トラフィックの制御を含む、全般的なクラスターネットワークの管理について説明します。

Pod ごとの帯域幅の制限などの Pod レベルのネットワーク機能については、Pod の管理で説明されています。

8.2. POD ネットワークの管理

クラスターが ovs-multitenant SDN プラグインを使用するように設定されている場合、管理者 CLI を使用してプロジェクトの別個の Pod オーバーレイネットワークを管理することができます。必要な場合は、プラグイン設定手順について「Configuring the SDN」セクションを参照してください。

8.2.1. プロジェクトネットワークへの参加

プロジェクトを既存のプロジェクトネットワークに参加させるには、以下を実行します。

上記の例で、<project2> および <project3> のすべての Pod およびサービスから、<project1> のすべての Pod およびサービスへのアクセスが可能となり、その逆の場合も可能になります。サービスは、IPまたは完全修飾 DNS 名 (<service>.<pod_namespace>.svc.cluster.local) のいずれかでアクセスできます。たとえば、プロジェクト myproject の db という名前のサービスにアクセスするには、db.myproject.svc.cluster.local を使用します。

または、特定のプロジェクト名を指定する代わりに --selector=<project_selector> オプションを使用することもできます。

組み合わせたネットワークを確認するには、以下を実行します。

次に NETID 列を確認します。同じ Pod ネットワークのプロジェクトには同じ NetID があります。

8.3. プロジェクトネットワークの分離

プロジェクトネットワークをクラスターから分離したり、その逆を実行するには、以下を実行します。

上記の例では、<project1> および <project2> のすべての Pod およびサービスは、クラスター内のグローバル以外のプロジェクトの Pod およびサービスにアクセスできず、その逆も実行できません。


8.3.1. プロジェクトネットワークのグローバル化

プロジェクトからクラスター内のすべての Pod およびサービスにアクセスできるようにするか、その

$ oc adm pod-network join-projects --to=<project1> <project2> <project3>

$ oc get netnamespaces

$ oc adm pod-network isolate-projects <project1> <project2>


84

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#architecture-additional-concepts-networking

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#architecture-additional-concepts-sdn


プロジェクトからクラスター内のすべての Pod およびサービスにアクセスできるようにするか、その逆を可能にするには、以下を実行します。

上記の例では、<project1> および <project2> のすべての Pod およびサービスはクラスター内のすべての Pod およびサービスにアクセスでき、その逆の場合も可能になります。


8.4. ルートおよび INGRESS オブジェクトにおけるホスト名の競合防止の無効化

OpenShift Container Platform では、ルートおよび ingress オブジェクトのホスト名の競合防止はデフォルトで有効にされています。これは、cluster-admin ロールのないユーザーは、作成時にのみルーターまたは ingress オブジェクトのホスト名を設定でき、その後は変更できなくなることを意味しています。ただし、ルートおよび ingress オブジェクトのこの制限は、一部またはすべてのユーザーに対して緩和することができます。

警告警告

OpenShift Container Platform はオブジェクト作成のタイムスタンプを使用して特定のホスト名の最も古いルートや ingress オブジェクトを判別するため、ルートまたは ingress オブジェクトは、古いルートがそのホスト名を変更したり、ingress オブジェクトが導入される場合に新規ルートのホスト名をハイジャックする可能性があります。

OpenShift Container Platform クラスター管理者は、作成後でもルートのホスト名を編集できます。また、特定のユーザーがこれを実行できるようにロールを作成することもできます。

$ oc create clusterrole route-editor --verb=update --resource=routes.route.openshift.io/custom-host

次に、新規ロールをユーザーにバインドできます。

$ oc adm policy add-cluster-role-to-user route-editor user

ingress オブジェクトのホスト名の競合防止を無効にすることもできます。これを実行することで、cluster-admin ロールを持たないユーザーが作成後も ingress オブジェクトのホスト名を編集できるようになります。これは、ingress オブジェクトのホスト名の編集を許可する場合などに Kubernetesの動作に依存する OpenShift Container Platform のインストールで役に立ちます。

1. 以下を master.yaml ファイルに追加します。

$ oc adm pod-network make-projects-global <project1> <project2>

admissionConfig: pluginConfig: openshift.io/IngressAdmission: configuration: apiVersion: v1

第第8章章ネットワークの管理ネットワークの管理

85

2. 変更を有効にするために、マスターサービスを再起動します。

8.5. EGRESS トラフィックの制御

クラスター管理者は、ホストレベルで数多くの静的 IP アドレスを特定ノードに割り当てることができます。アプリケーション開発者がそれぞれのアプリケーションサービスに専用 IP アドレスを必要とする場合、ファイアウォールアクセスを要求するプロセスでこのアドレスを要求することができます。その後、開発者はデプロイメント設定の nodeSelector を使用して、開発者のプロジェクトから egressルーターをデプロイし、静的 IP アドレスが事前に割り当てられたホストに Pod が到達することを確認できます。

egress Pod のデプロイメントでは、宛先に到達するために必要なソース IP のいずれか、保護されるサービスの宛先 IP、およびゲートウェイ IP を宣言します。Pod のデプロイ後は、サービスを作成して、egress ルーター Pod にアクセスし、そのソース IP を企業ファイアウォールに追加できます。その後、開発者はプロジェクトで作成された egress ルーターサービスへのアクセス情報を取得します (例: service.project.cluster.domainname.com)。

開発者が外部の firewalled サービスにアクセスする必要がある場合、実際の保護されたサービス URL ではなくアプリケーション (例: JDBC 接続情報) で、egress ルーター Pod のサービス(service.project.cluster.domainname.com) に対して呼び出し実行することができます。

さらに、静的 IP アドレスをプロジェクトに割り当て、指定されたプロジェクトからの発信外部接続すべてに認識可能な起点を設定できます。これは、トラフィックと特定の宛先に送信するために使用されるデフォルトの egress ルーターとは異なります。

詳細は、「外部プロジェクトトラフィックの固定 IP の有効化」セクションを参照してください。

OpenShift Container Platform クラスター管理者は、以下を使用して egress トラフィックを制御できます。

ファイアウォール

egress ファイアウォールを使用すると、受け入れ可能な発信トラフィックポリシーを実施し、特定のエンドポイントまたは IP 範囲 (サブネット) のみを動的エンドポイント (OpenShift ContainerPlatform 内の Pod) が通信できる受け入れ可能なターゲットとすることができます。

ルーター

egress ルーターを使用することで、識別可能なサービスを作成し、トラフィックを特定の宛先に送信できます。これにより、それらの外部の宛先はトラフィックを既知のソースから送られるものとして処理します。これにより namespace の特定の Pod のみがトラフィックをデータベースにプロキシー送信するサービス (egress ルーター) と通信できるよう外部データベースが保護されるため、セキュリティー対策として役立ちます。

iptables

上記の OpenShift Container Platform 内のソリューションのほかにも、発信トラフィックに適用される iptables ルールを作成することができます。これらのルールは、egress ファイアウォールよりも多くのオプションを許可しますが、特定のプロジェクトに制限することはできません。

8.6. 外部リソースへのアクセスを制限するための EGRESS ファイアウォー

allowHostnameChanges: true kind: IngressAdmissionConfig location: ""

$ master-restart api$ master-restart controllers


86

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-integrating-external-services

8.6. 外部リソースへのアクセスを制限するための EGRESS ファイアウォールの使用

OpenShift Container Platform クラスター管理者は egress ファイアウォールを使用して、一部またはすべての Pod がクラスター内からアクセスできる外部 IP アドレスを制限できます。egress ファイアウォールポリシーは以下のシナリオをサポートします。

Pod の接続を内部ホストに制限し、パブリックインターネットへの接続を開始できないようにする。

Pod の接続をパブリックインターネットに制限し、OpenShift Container Platform クラスター外にある内部ホストへの接続を開始できないようにする。

Pod が到達不能な状態の指定された内部サブネットまたはホストに到達できないようにする。

egress ポリシーは、IP アドレス範囲を CIDR 形式で指定するか、または DNS 名を指定して設定できます。たとえば、指定された IP 範囲への <project_A> アクセスを許可しつつ、<project_B> への同じアクセスを拒否することができます。または、アプリケーション開発者が (Python) pip mirror からの更新を制限したり、更新を承認されたソースからの更新のみに強制的に制限したりすることができます。

注意注意

Pod アクセスを egress ポリシーで制限するには、ovs-multitenant または ovs-networkpolicy プラグインを有効にする必要があります。

ovs-networkpolicy プラグインを使用している場合、egress ポリシーはプロジェクトごとに 1 つのポリシーとのみ互換性を持ち、グローバルプロジェクトなどのネットワークを共有するプロジェクトでは機能しません。

プロジェクト管理者は、EgressNetworkPolicy オブジェクトを作成することも、プロジェクトで作成するオブジェクトを編集することもできません。また、EgressNetworkPolicy の作成に関連して他のいくつかの制限があります。

デフォルトプロジェクト (および oc adm pod-network make-projects-global でグローバルにされたその他のプロジェクト) には egress ポリシーを設定することができません。

(oc adm pod-network join-projects を使用して) 2 つのプロジェクトをマージする場合、マージしたプロジェクトのいずれでも egress ポリシーを使用することはできません。

いずれのプロジェクトも複数の egress ポリシーオブジェクトを持つことができません。

上記の制限のいずれかに違反すると、プロジェクトの egress ポリシーに障害が発生し、すべての外部ネットワークトラフィックがドロップされる可能性があります。

oc コマンドまたは REST API を使用して egress ポリシーを設定します。 oc [create|replace|delete] を使用して EgressNetworkPolicy オブジェクトを操作できます。api/swagger-spec/oapi-v1.json ファイルには、オブジェクトを実際に機能させる方法についての API レベルの詳細情報が含まれます。

egress ポリシーを設定するには、以下を実行します。

1. 対象とするプロジェクトに移動します。

2. 以下の例のように、使用する必要のあるポリシー設定で JSON ファイルを作成します。

{ "kind": "EgressNetworkPolicy",


87

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#migrating-between-sdn-plugins

上記のサンプルがプロジェクトに追加されると、IP 範囲 1.2.3.0/24 およびドメイン名 www.foo.com へのトラフィックが許可されますが、その他のすべての外部 IP アドレスへのアクセスは拒否されます。このポリシーは外部トラフィックにのみ適用されるため、その他すべての Pod へのトラフィックは影響を受けません。

EgressNetworkPolicy のルールは順番にチェックされ、一致する最初のルールが実施されます。上記の例の 3 つの例を逆順に定義した場合、0.0.0.0/0 ルールが最初にチェックされ、すべてのトラフィックに一致し、それらすべてを拒否するため、1.2.3.0/24 および www.foo.comへのトラフィックは許可されません。

ドメイン名の更新は、ローカルの非権威サーバーのドメインの TTL (time to live) 値に基づいてポーリングされます。Pod は必要な場合には、同じローカルのネームサーバーのドメインを解決します。そうでない場合には、egress ネットワークポリシーコントローラーと Pod で認識されるドメインの IP アドレスが異なり、egress ネットワークが予想通りに実施されない場合があります。egress ネットワークポリシーコントローラーおよび Pod は同じローカルネームサーバーを非同期にポーリングするため、Pod が egress コントローラーの前に更新された IP を取得するという競合状態が発生する可能性があります。この現時点の制限により、EgressNetworkPolicy のドメイン名の使用は、IP アドレスの変更が頻繁に生じないドメインの場合にのみ推奨されます。

注記注記

egress ファイアウォールは、DNS 解決用に Pod が置かれるノードの外部インターフェースに Pod が常にアクセスできるようにします。DNS 解決がローカルノード上のいずれかによって処理されない場合は、Pod でドメイン名を使用している場合には DNS サーバーの IP アドレスへのアクセスを許可する egress ファイアウォールを追加する必要があります。

"apiVersion": "v1", "metadata": { "name": "default" }, "spec": { "egress": [ { "type": "Allow", "to": { "cidrSelector": "1.2.3.0/24" } }, { "type": "Allow", "to": { "dnsName": "www.foo.com" } }, { "type": "Deny", "to": { "cidrSelector": "0.0.0.0/0" } } ] }}


88

3. JSON ファイルを使用して EgressNetworkPolicy オブジェクトを作成します。

注意注意

ルートを作成してサービスを公開すると、EgressNetworkPolicy は無視されます。Egress ネットワークポリシーサービスのエンドポイントのフィルターは、ノード kubeproxy で実行されます。ルーターが使用される場合は、kubeproxy はバイパスされ、egress ネットワークポリシーの施行は適用されません。管理者は、ルートを作成するためのアクセスを制限してこのバイパスを防ぐことができます。

8.6.1. 外部リソースから Pod トラフィックを認識可能にするための Egress ルーターの使用

OpenShift Container Platform egress ルーターは、他の用途で使用されていないプライベートソース IPアドレスを使用して、指定されたリモートサーバーにトラフィックをリダイレクトするサービスを実行します。このサービスにより、Pod はホワイトリスト IP アドレスからのアクセスのみを許可するように設定されたサーバーと通信できるようになります。

重要重要

egress ルーターはすべての発信接続のために使用されることが意図されていません。多数の egress ルーターを作成することで、ネットワークハードウェアの制限を引き上げる可能性があります。たとえば、すべてのプロジェクトまたはアプリケーションに egressルーターを作成すると、ソフトウェアの MAC アドレスのフィルターにフォールバックする前にネットワークインターフェースが処理できるローカル MAC アドレス数の上限を超えてしまう可能性があります。

重要重要

現時点で、egress ルーターには Amazon AWS, Azure Cloud またはレイヤー 2 操作をサポートしないその他のクラウドプラットフォームとの互換性がありません。それらにmacvlan トラフィックとの互換性がないためです。

デプロイメントに関する考慮事項

Egressルーターは 2 つ目の IP アドレスおよび MAC アドレスをノードのプライマリーネットワークインターフェースに追加します。OpenShift Container Platform をベアメタルで実行していない場合は、ハイパーバイザーまたはクラウドプロバイダーが追加のアドレスを許可するように設定する必要があります。

Red Hat OpenStack Platform

OpenShift Container Platform を Red Hat OpenStack Platform を使ってデプロイしている場合、OpenStack 環境で IP および MAC アドレスのホワイトリストを作成する必要があります。これを行わないと、通信は失敗します。

neutron port-update $neutron_port_uuid \ --allowed_address_pairs list=true \ type=dict mac_address=<mac_address>,ip_address=<ip_address>

Red Hat Enterprise Virtualization

Red Hat Enterprise Virtualization を使用している場合は、EnableMACAntiSpoofingFilterRules を

$ oc create -f <policy>.json


89

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#creating-routes

https://access.redhat.com/solutions/2803331

Red Hat Enterprise Virtualization を使用している場合は、EnableMACAntiSpoofingFilterRules を false に設定する必要があります。

VMware vSphere

VMware vSphere を使用している場合は、vSphere 標準スイッチのセキュリティー保護についてのVMWare ドキュメントを参照してください。vSphere Web クライアントからホストの仮想スイッチを選択して、VMWare vSphere デフォルト設定を表示し、変更します。

とくに、以下が有効にされていることを確認します。

MAC アドレスの変更

偽装転送 (Forged Transit)

無作為別モード (Promiscuous Mode) 操作

Egress ルーターモード

egress ルーターは、リダイレクトモードと HTTP プロキシーモードおよび DNS proxy mode の 3 つの異なるモードで実行できます。リダイレクトモードは、HTTP および HTTPS 以外のすべてのサービスで機能します。HTTP および HTTPS サービスの場合は、HTTP プロキシーモードを使用します。IP アドレスまたはドメイン名を持つ TCP ベースのサービスの場合は、DNS プロキシーモードを使用します。

8.6.1.1. リダイレクトモードでのリダイレクトモードでの Egress ルータールーター Pod のデプロイのデプロイ

リダイレクトモードでは、egress ルーターは、トラフィックを独自の IP アドレスから 1 つ以上の宛先IP アドレスにリダイレクトするために iptables ルールをセットアップします。予約されたソース IP アドレスを使用する必要のあるクライアント Pod は、宛先 IP に直接接続するのでなく、egress ルーターに接続するように変更される必要があります。

1. 上記を使用して Pod 設定を作成します。

apiVersion: v1kind: Podmetadata: name: egress-1 labels: name: egress-1 annotations: pod.network.openshift.io/assign-macvlan: "true" 1spec: initContainers: - name: egress-router image: registry.redhat.io/openshift3/ose-egress-router securityContext: privileged: true env: - name: EGRESS_SOURCE 2 value: 192.168.12.99/24 - name: EGRESS_GATEWAY 3 value: 192.168.12.1 - name: EGRESS_DESTINATION 4 value: 203.0.113.25 - name: EGRESS_ROUTER_MODE 5 value: init


90

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Administration_Guide/Red_Hat_Enterprise_Virtualization_Manager_configuration_options_explanations_limitations_and_best_practices.html

https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-3507432E-AFEA-4B6B-B404-17A020575358.html

https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-942BD3AA-731B-4A05-8196-66F2B4BF1ACB.html

https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-7DC6486F-5400-44DF-8A62-6273798A2F80.html

https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-92F3AB1F-B4C5-4F25-A010-8820D7250350.html

1

2

3

4

5

6

プライマリーネットワークインターフェースで Macvlan ネットワークインターフェースを作成し、これを Pod のネットワークプロジェクトに移行してから egress-router コンテナーを起動します。"true" の周りの引用符はそのまま残します。これらを省略すると、エラーが発生します。プライマリーネットワークインターフェース以外のネットワークインターフェースで Macvlan インターフェースを作成するには、アノテーションの値を該当インターフェースの名前に設定します。たとえば、 eth1 を使用します。

ノードが置かれており、クラスター管理者がこの Pod で使用するために予約している物理ネットワークの IP アドレスです。オプションとして、サブネットの長さ /24 サフィックスを組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、egress ルーターは EGRESS_GATEWAY 変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。

ノードで使用されるデフォルトゲートウェイと同じ値です。

トラフィックの送信先となる外部サーバー。この例では、Pod の接続は 203.0.113.25 にリダイレクトされます。ソース IP アドレスは 192.168.12.99 です。

これは egress ルーターイメージに対して、これが「init コンテナー」としてデプロイされていることを示しています。以前のバージョンの OpenShift Container Platform (およびegress ルーターイメージ) はこのモードをサポートしておらず、通常のコンテナーとして実行される必要がありました。

Pod はラベル site=springfield-1 の設定されたノードにのみデプロイされます。

2. 上記の定義を使用して Pod を作成します。

Pod が作成されているかどうかを確認するには、以下を実行します。

3. egresss ルーターを参照するサービスを作成し、他の Pod が Pod の IP アドレスを見つけられるようにします。

containers: - name: egress-router-wait image: registry.redhat.io/openshift3/ose-pod nodeSelector: site: springfield-1 6

$ oc create -f <pod_name>.json

$ oc get pod <pod_name>

apiVersion: v1kind: Servicemetadata: name: egress-1spec: ports: - name: http port: 80 - name: https port: 443


91

Pod がこのサービスに接続できるようになります。これらの接続は、予約された egress IP アドレスを使用して外部サーバーの対応するポートにリダイレクトされます。

egress ルーターのセットアップは、openshift3/ose-egress-router イメージで作成される「init コンテナー」で実行され、このコンテナーは Macvlan インターフェースを設定し、iptables ルールをセットアップできるように特権モード実行されます。iptables ルールのセットアップ終了後に、これは終了し、openshift3/ose-pod コンテナーが Pod が強制終了されるまで (特定のタスクを実行しない) 実行状態になります。

環境変数は egress-router イメージに対し、使用するアドレスを指示します。これは、EGRESS_SOURCE を IP アドレスとして、また EGRESS_GATEWAY をゲートウェイとして使用するよう Macvlan を設定します。

NAT ルールが設定され、Pod のクラスター IP アドレスの TCP または UDP ポートへの接続が EGRESS_DESTINATION の同じポートにリダイレクトされるようにします。

クラスター内の一部のノードのみが指定されたソース IP アドレスを要求でき、指定されたゲートウェイを使用できる場合、受け入れ可能なノードを示す nodeName または nodeSelector を指定することができます。

8.6.1.2. 複数の宛先へのリダイレクト複数の宛先へのリダイレクト

前の例では、任意のポートでの egress Pod (またはその対応するサービス) への接続は単一の宛先 IP にリダイレクトされます。ポートによっては複数の異なる宛先 IP を設定することもできます。

type: ClusterIP selector: name: egress-1

apiVersion: v1kind: Podmetadata: name: egress-multi labels: name: egress-multi annotations: pod.network.openshift.io/assign-macvlan: "true"spec: initContainers: - name: egress-router image: registry.redhat.io/openshift3/ose-egress-router securityContext: privileged: true env: - name: EGRESS_SOURCE 1 value: 192.168.12.99/24 - name: EGRESS_GATEWAY value: 192.168.12.1 - name: EGRESS_DESTINATION 2 value: | 80 tcp 203.0.113.25 8080 tcp 203.0.113.26 80 8443 tcp 203.0.113.26 443 203.0.113.27 - name: EGRESS_ROUTER_MODE


92

1

2


EGRESS_DESTINATION はその値に YAML 構文を使用し、複数行の文字列を使用できます。詳細は、以下を参照してください。

EGRESS_DESTINATION の各行は以下の 3 つのタイプのいずれかになります。

<port> <protocol> <IP_address>: これは、指定される <port> への着信接続が指定される <IP_address> の同じポートにリダイレクトされることを示します。<protocol> は tcp または udp のいずれかになります。上記の例では、最初の行がローカルポート 80 から 203.0.113.25のポート 80 にトラフィックをリダイレクトしています。

<port> <protocol> <IP_address> <remote_port>: 接続が <IP_address> の別の <remote_port> にリダイレクトされるのを除き、上記と同じになります。この例では、2 番目と 3 番目の行ではローカルポート 8080 および 8443 を 203.0.113.26 のリモートポート 80 および 443 にリダイレクトしています。

<fallback_IP_address>: EGRESS_DESTINATION の最後の行が単一 IP アドレスである場合、それ以外のポートの接続はその IP アドレス (上記の例では 203.0.113.27) の対応するポートにリダイレクトされます。フォールバック IP アドレスがない場合、他のポートでの接続は単純に拒否されます。)

8.6.1.3. ConfigMap の使用によるの使用による EGRESS_DESTINATION の指定の指定

宛先マッピングのセットのサイズが大きいか、またはこれが頻繁に変更される場合、ConfigMap を使用して一覧を外部で維持し、egress ルーター Pod がそこから一覧を読み取れるようにすることができます。これには、プロジェクト管理者が ConfigMap を編集できるという利点がありますが、これには特権付きコンテナーが含まれるため、管理者は Pod 定義を直接編集することはできません。

1. EGRESS_DESTINATION データを含むファイルを作成します。

空の行とコメントをこのファイルに追加できることに注意してください。

2. このファイルから ConfigMap オブジェクトを作成します。

value: init containers: - name: egress-router-wait image: registry.redhat.io/openshift3/ose-pod

$ cat my-egress-destination.txt# Egress routes for Project "Test", version 3

80 tcp 203.0.113.25

8080 tcp 203.0.113.26 808443 tcp 203.0.113.26 443

# Fallback203.0.113.27


93

1

ここで、egress-routes は作成される ConfigMap オブジェクトの名前で、my-egress-destination.txt はデータの読み取り元のファイルの名前です。

3. 前述のように egress ルーター Pod 定義を作成しますが、ConfigMap を環境セクションの EGRESS_DESTINATION に指定します。


注記注記

egress ルーターは、ConfigMap が変更されても自動的に更新されません。更新を取得するには Pod を再起動します。

8.6.1.4. Egress ルータールーター HTTP プロキシープロキシー Pod のデプロイのデプロイ

HTTP プロキシーモードでは、egress ルーターはポート 8080 で HTTP プロキシーとして実行されます。これは、HTTP または HTTPS ベースのサービスと通信するクライアントの場合にのみ機能しますが、通常それらを機能させるのにクライアント Pod への多くの変更は不要です。環境変数を設定することで、プログラムは HTTP プロキシーを使用するように指示されます。

1. 例として以下を使用して Pod を作成します。

$ oc delete configmap egress-routes --ignore-not-found$ oc create configmap egress-routes \ --from-file=destination=my-egress-destination.txt

... env: - name: EGRESS_SOURCE 1 value: 192.168.12.99/24 - name: EGRESS_GATEWAY value: 192.168.12.1 - name: EGRESS_DESTINATION valueFrom: configMapKeyRef: name: egress-routes key: destination - name: EGRESS_ROUTER_MODE value: init ...

apiVersion: v1kind: Podmetadata: name: egress-http-proxy labels: name: egress-http-proxy annotations: pod.network.openshift.io/assign-macvlan: "true" 1


94

1

2

3

4

5

プライマリーネットワークインターフェースで Macvlan ネットワークインターフェースを作成してから、これを Pod のネットワークプロジェクトに移行し、egress-router コンテナーを起動します。"true" の周りの引用符をそのまま残します。これらを省略すると、エラーが発生します。



これは egress ルーターイメージに対し、これが HTTP プロキシーの一部としてデプロイされているため、iptables のリダイレクトルールを設定できないことを示します。

プロキシーの設定方法を指定する文字列または YAML の複数行文字列です。これは、initコンテナーの他の環境変数ではなく、HTTP プロキシーコンテナーの環境変数として指定されることに注意してください。

EGRESS_HTTP_PROXY_DESTINATION 値に以下のいずれかを指定できます。また、* を使用することができます。これは「すべてのリモート宛先への接続を許可」することを意味します。設定の各行には、許可または拒否する接続の 1 つのグループを指定します。

IP アドレス (例: 192.168.1.1) は該当する IP アドレスへの接続を許可します。

CIDR 範囲 (例: 192.168.1.0/24) は CIDR 範囲への接続を許可します。

ホスト名 (例: www.example.com) は該当ホストへのプロキシーを許可します。

*. が先に付けられるドメイン名 (例: *.example.com) は該当ドメインおよびそのサブドメイ

spec: initContainers: - name: egress-router-setup image: registry.redhat.io/openshift3/ose-egress-router securityContext: privileged: true env: - name: EGRESS_SOURCE 2 value: 192.168.12.99/24 - name: EGRESS_GATEWAY 3 value: 192.168.12.1 - name: EGRESS_ROUTER_MODE 4 value: http-proxy containers: - name: egress-router-proxy image: registry.redhat.io/openshift3/ose-egress-http-proxy env: - name: EGRESS_HTTP_PROXY_DESTINATION 5 value: | !*.example.com !192.168.1.0/24 *


95

1

1

*. が先に付けられるドメイン名 (例: *.example.com) は該当ドメインおよびそのサブドメインのすべてへのプロキシーを許可します。

上記のいずれかに ! を付けると、接続は許可されるのではなく、拒否されます。

最後の行が * の場合、拒否されていないすべてのものが許可されます。または、許可されていないすべてのものが拒否されます。


http ポートが常に 8080 に設定されていることを確認します。

3. http_proxy または https_proxy 変数を設定して、クライアント Pod (egress プロキシー Podではない) を HTTP プロキシーを使用するように設定します。

手順 2 で作成されたサービス。

注記注記

すべてのセットアップに http_proxy および https_proxy 環境変数が必要になる訳ではありません。上記を実行しても作業用セットアップが作成されない場合は、Pod で実行しているツールまたはソフトウェアについてのドキュメントを参照してください。

リダイレクトする egress ルーターの上記の例と同様に、ConfigMap を使用して EGRESS_HTTP_PROXY_DESTINATION を指定することもできます。

8.6.1.5. Egress ルータールーター HTTP プロキシープロキシー Pod のデプロイのデプロイ

DNS プロキシーモードでは、egress ルーターは、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスに送信する TCP ベースのサービスの DNS プロキシーとして実行されます。予約されたソース IP アドレスを使用する必要のあるクライアント Pod は、宛先 IP に直接接続するのでなく、

apiVersion: v1kind: Servicemetadata: name: egress-1spec: ports: - name: http-proxy port: 8080 1 type: ClusterIP selector: name: egress-1

... env: - name: http_proxy value: http://egress-1:8080/ 1 - name: https_proxy value: http://egress-1:8080/ ...


96

1

2

egress ルーターに接続するように変更される必要があります。これにより、外部の宛先でトラフィックが既知のソースから送信されているかのように処理されます。

1. 例として以下を使用して Pod を作成します。

pod.network.openshift.io/assign-macvlan annotation を使用することで、プライマリーネットワークインターフェースで Macvlan ネットワークインターフェースが作成され、これが Pod のネットワークプロジェクトに移行し、egress-router-setup コンテナーを起動します。"true" の周りの引用符をそのまま残します。これらを省略すると、エラーが発生します。

ノードが置かれており、クラスター管理者がこの Pod で使用するために予約している物理ネットワークの IP アドレスです。オプションとして、サブネットの長さ /24 サフィックスを組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、egress ルーターは EGRESS_GATEWAY 変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできませ

apiVersion: v1kind: Podmetadata: name: egress-dns-proxy labels: name: egress-dns-proxy annotations: pod.network.openshift.io/assign-macvlan: "true" 1spec: initContainers: - name: egress-router-setup image: registry.redhat.io/openshift3/ose-egress-router securityContext: privileged: true env: - name: EGRESS_SOURCE 2 value: 192.168.12.99/24 - name: EGRESS_GATEWAY 3 value: 192.168.12.1 - name: EGRESS_ROUTER_MODE 4 value: dns-proxy containers: - name: egress-dns-proxy image: registry.redhat.io/openshift3/ose-egress-dns-proxy env: - name: EGRESS_DNS_PROXY_DEBUG 5 value: "1" - name: EGRESS_DNS_PROXY_DESTINATION 6 value: | # Egress routes for Project "Foo", version 5

80 203.0.113.25

100 example.com

8080 203.0.113.26 80

8443 foobar.com 443


97

3

4

5

6

ん。


これは egress ルーターイメージに対し、これが DNS プロキシーの一部としてデプロイされているため、iptables のリダイレクトルールを設定できないことを示します。

オプションです。この変数を設定すると、DNS プロキシーログ出力が標準出力 (stdout)で表示されます。

ここでは、複数行の文字列に YAML 構文を使用しています。詳細は以下を参照してください。

注記注記

EGRESS_DNS_PROXY_DESTINATION の各行は 2 つの方法で設定できます。

<port> <remote_address>: これは、指定の <port> への受信接続が指定の <remote_address> にある同じ TCP ポートにプロキシー送信される必要があることを示しています。<remote_address> には IP アドレスまたは DNS名を指定できます。DNS 名の場合、DNS 解決はランタイムで実行されます。上記の例では、最初の行が TCP トラフィックをローカルポート 80 から 203.0.113.25 のポート 80 にプロキシー送信します。2 つ目の行は、TCPトラフィックをローカルポート 100 から example.com のポート 100 にプロキシー送信しています。

<port> <remote_address> <remote_port>: 接続が <remote_address> の別の <remote_port> にプロキシー送信されるのを除き、上記と同じになります。この例では、3 番目の行ではローカルポート 8080 を 203.0.113.26 のリモートポート 80 にプロキシー送信し、4 番目の行ではローカルポート8443 を footbar.com のリモートポートおよび 443 にプロキシー送信しています。


apiVersion: v1kind: Servicemetadata: name: egress-dns-svcspec: ports: - name: con1 protocol: TCP port: 80 targetPort: 80 - name: con2 protocol: TCP port: 100 targetPort: 100 - name: con3 protocol: TCP port: 8080 targetPort: 8080 - name: con4


98

Pod がこのサービスに接続できるようになります。これらの接続は、予約された egress IP アドレスを使用して外部サーバーの対応するポートにプロキシー送信されます。

リダイレクトする egress ルーターの上記の例と同様に、ConfigMap を使用して EGRESS_DNS_PROXY_DESTINATION を指定することもできます。

8.6.1.6. Egress ルータールーター Pod のフェイルオーバーの有効化のフェイルオーバーの有効化

レプリケーションコントローラーを使用し、ダウンタイムを防ぐために egress ルーター Pod の 1 つのコピーを常に確保できるようにします。

1. 以下を使用してレプリケーションコントローラーの設定ファイルを作成します。

replicas が 1 に設定されていることを確認します。1 つの Pod のみが指定される

protocol: TCP port: 8443 targetPort: 8443 type: ClusterIP selector: name: egress-dns-proxy

apiVersion: v1kind: ReplicationControllermetadata: name: egress-demo-controllerspec: replicas: 1 1 selector: name: egress-demo template: metadata: name: egress-demo labels: name: egress-demo annotations: pod.network.openshift.io/assign-macvlan: "true" spec: initContainers: - name: egress-demo-init image: registry.redhat.io/openshift3/ose-egress-router env: - name: EGRESS_SOURCE 2 value: 192.168.12.99/24 - name: EGRESS_GATEWAY value: 192.168.12.1 - name: EGRESS_DESTINATION value: 203.0.113.25 - name: EGRESS_ROUTER_MODE value: init securityContext: privileged: true containers: - name: egress-demo-wait image: registry.redhat.io/openshift3/ose-pod nodeSelector: site: springfield-1


99

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-configmaps

1

2

replicas が 1 に設定されていることを確認します。1 つの Pod のみが指定される EGRESS_SOURCE 値を随時使用できるためです。これは、ルーターの単一コピーのみがラベル site=springfield-1 が設定されたノードで実行されることを意味します。


2. この定義を使用して Pod を作成します。

3. 検証するには、レプリケーションコントローラー Pod が作成されているかどうかを確認します。

8.6.2. 外部リソースへのアクセスを制限するための iptables ルールの使用

クラスター管理者の中には、EgressNetworkPolicy のモデルや egress ルーターの対象外の発信トラフィックに対してアクションを実行する必要のある管理者がいる場合があります。この場合には、iptables ルールを直接作成してこれを実行することができます。

たとえば、特定の宛先へのトラフィックをログに記録するルールを作成したり、1 秒ごとに設定される特定数を超える発信接続を許可しないようにしたりできます。

OpenShift Container Platform はカスタム iptables ルールを自動的に追加する方法を提供していませんが、管理者がこのようなルールを手動で追加できる場所を提供します。各ノードは起動時に、filterテーブルに OPENSHIFT-ADMIN-OUTPUT-RULES という空のチェーンを作成します (チェーンがすでに存在していないと仮定します)。管理者がこのチェーンに追加するすべてのルールは、Pod からクラスター外にある宛先へのすべてのトラフィックに適用されます (それ以外のトラフィックには適用されません)。

この機能を使用する際には、注意すべきいくつかの点があります。

1. 各ノードにルールが作成されていることを確認するのは管理者のタスクになります。OpenShiftContainer Platform はこれを自動的に確認する方法は提供しません。

2. ルールは egress ルーターによってクラスターを退出するトラフィックには適用されず、ルールは EgressNetworkPolicy ルールが適用された後に実行されます (そのため、EgressNetworkPolicy で拒否されるトラフィックは表示されません)。

3. ノードには「外部」IP アドレスと「内部」SDN IP アドレスの両方があるため、Pod からノードまたはノードからマスターへの接続の処理は複雑になります。そのため、一部の Pod とノード間/Pod とマスター間のトラフィックはこのチェーンを通過しますが、他の Pod とノード間/Pod とマスター間のトラフィックはこれをバイパスする場合があります。

8.7. 外部プロジェクトトラフィックの静的 IP の有効化

クラスター管理者は特定の静的 IP アドレスをプロジェクトに割り当て、トラフィックが外部から容易

$ oc create -f <replication_controller>.json

$ oc describe rc <replication_controller>


100

クラスター管理者は特定の静的 IP アドレスをプロジェクトに割り当て、トラフィックが外部から容易に識別できるようにできます。これは、トラフィックを特定の宛先に送信するために使用されるデフォルトの egress ルーターの場合とは異なります。

識別可能な IP トラフィックは起点を可視化することで、クラスターのセキュリティーを強化します。これが有効にされると、指定されたプロジェクトからのすべての発信外部接続は同じ固定ソース IP を共有します。つまり、すべての外部リソースがこのトラフィックを認識できるようになります。

egress ルーターの場合とは異なり、これは EgressNetworkPolicy ファイアウォールルールに基づいて実行されます。

注記注記

クラスターのプロジェクトに静的 IP アドレスを割り当てるには、SDN が ovs-networkpolicy または ovs-multitenant ネットワークプラグインのいずれかを使用する必要があります。

注記注記

マルチテナントモードで OpenShift SDN を使用する場合、それらに関連付けられているプロジェクトによって別の namespace に結合されている namespace で egress IP アドレスを使用することはできません。たとえば、project1 と project2 が oc adm pod-network join-projects --to = project1 project2 コマンドを実行して結合されている場合はどちらもプロジェクトも egress IP アドレスを使用できません。詳細は、BZ#1645577を参照してください。

静的 IP を有効にするには、以下を実行します。

1. 必要な IP で NetNamespace を更新します。

たとえば、MyProject プロジェクトを IP アドレス 192.168.1.100 に割り当てるには、以下を実行します。

egressIPs フィールドは配列です。egressIPs を異なるノードの 2 つ以上の IP アドレスに設定し、高可用性を確保することができます。複数の egress IP アドレスが設定される場合、Podは egress の一覧にある最初の IP を使用しますが、IP アドレスをホストするノードが失敗する場合、Pod は短時間の遅延の後に一覧にある次の IP の使用に切り替えます。

2. egress IP を必要なノードホストに手動で割り当てます。ノードホストの HostSubnet オブジェクトの egressIPs フィールドを設定します。そのノードホストに割り当てる必要のある任意の数の IP を含めることができます。

たとえば node1 に egress IPs 192.168.1.100、192.168.1.101 および 192.168.1.102 が必要である場合が、以下のようになります。

$ oc patch netnamespace <project_name> -p '{"egressIPs": ["<IP_address>"]}'

$ oc patch netnamespace MyProject -p '{"egressIPs": ["192.168.1.100"]}'

$ oc patch hostsubnet <node_name> -p \ '{"egressIPs": ["<IP_address_1>", "<IP_address_2>"]}'

$ oc patch hostsubnet node1 -p \ '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'


101

https://bugzilla.redhat.com/show_bug.cgi?id=1645577

重要重要

egress IP はプライマリーネットワークインターフェースの追加の IP として実装され、ノードのプライマリー IP と同じサブネットに置かれる必要があります。さらに、外部 IP は、ifcfg-eth0 などの Linux ネットワーク設定ファイルで設定することはできません。

一部のクラウドまたは仮想マシンソリューションを使用する場合に、プライマリーネットワークインターフェースで追加の IP アドレスを許可するには追加の設定が必要になる場合があります。

プロジェクトに対して上記が有効にされる場合、そのプロジェクトからのすべての egress トラフィックはその egress IP をホストするノードにルーティングされ、(NAT を使用して) その IP アドレスに接続されます。egressIPs が NetNamespace で設定されているものの、その egress IP をホストするノードがない場合、namespace からの egress トラフィックはドロップされます。

8.8. 自動 EGRESS IP の有効化

「外部プロジェクトトラフィックの静的 IP の有効化」の場合のように、クラスター管理者として、egressIPs パラメーターを NetNamespace リソースに設定して egress IP アドレスを namespaceに割り当てることができます。単一 IP アドレスのみをプロジェクトに関連付けることができます。

注記注記

マルチテナントモードで OpenShift SDN を使用する場合、それらに関連付けられているプロジェクトによって別の namespace に結合されている namespace で egress IP アドレスを使用することはできません。たとえば、project1 と project2 が oc adm pod-network join-projects --to = project1 project2 コマンドを実行して結合されている場合はどちらもプロジェクトも egress IP アドレスを使用できません。詳細は、BZ#1645577を参照してください。

完全に自動化された egress IP により、各ノードの HostSubnet リソースの egressCIDRs パラメーターを設定し、ホストできる egress IP アドレスの範囲を示唆することができます。egress IP アドレスを要求した namespace はそれらの egress IP アドレスをホストできるノードに一致し、その後にegress IP アドレスはそれらのノードに割り当てられます。

高可用性は自動的に実行されます。egress IP アドレスをホストしているノードが停止し、HostSubnetリソースの egressCIDR 値をベースとしてそれらの egress IP アドレスをホストできるノードがある場合、egress IP アドレスは新規ノードに移行します。元の egress IP アドレスノードが再びオンラインに戻ると、ノード間で egress IP アドレスのバランスを図るために egress IP アドレスは自動的に移行します。

重要重要

手動で割り当てられた egress IP アドレスと自動的に割り当てられた egress IP アドレスの両方を同じノードで使用したり、同じ IP アドレス範囲で使用したりすることはできません。

1. NetNamespace を egress IP アドレスで更新します。

egressIPs パラメーターに単一 IP アドレスのみを指定できます。複数の IP アドレスの使用は

$ oc patch netnamespace <project_name> -p '{"egressIPs": ["<IP_address>"]}'


102


egressIPs パラメーターに単一 IP アドレスのみを指定できます。複数の IP アドレスの使用はサポートされていません。

たとえば、project1 を IP アドレスの 192.168.1.100 に、 project2 を IP アドレスの 192.168.1.101に割り当てるには、以下を実行します。

2. egressCIDRs フィールドを設定して egress IP アドレスをホストできるノードを示します。

たとえば、node1 および node2 を、192.168.1.0 から 192.168.1.255 の範囲で egress IP アドレスをホストするように設定するには、以下を実行します。

3. OpenShift Container Platform はバランスを取りながら特定の egress IP アドレスを利用可能なノードに自動的に割り当てます。この場合、egress IP アドレス 192.168.1.100 を node1 に、egress IP アドレス 192.168.1.101 を node2 に割り当て、その逆も行います。

8.9. マルチキャストの有効化

重要重要

現時点で、マルチキャストは低帯域幅の調整またはサービスの検出での使用に最も適しており、高帯域幅のソリューションとしては適していません。

OpenShift Container Platform の Pod 間のマルチキャストトラフィックはデフォルトで無効にされます。ovs-multitenant または ovs-networkpolicy プラグインを使用している場合、アノテーションをプロジェクトの対応する netnamespace オブジェクトに設定してプロジェクトごとにマルチキャストを有効にできます。

アノテーションを削除してマルチキャストを無効にします。

ovs-multitenant プラグインを使用する場合:

1. 分離したプロジェクトでは、Pod で送信されるマルチキャストパケットはプロジェクト内の他のすべての Pod に送信されます。

2. ネットワークを結合している場合、すべてのプロジェクトで有効にされるようにマルチキャストを各プロジェクトの netnamespace で有効にする必要があります。結合されたネットワークの Pod で送信されるマルチキャストはすべての結合されたネットワークのすべての Pod に送信されます。

$ oc patch netnamespace project1 -p '{"egressIPs": ["192.168.1.100"]}'$ oc patch netnamespace project2 -p '{"egressIPs": ["192.168.1.101"]}''

$ oc patch hostsubnet <node_name> -p \ '{"egressCIDRs": ["<IP_address_range_1>", "<IP_address_range_2>"]}'

$ oc patch hostsubnet node1 -p '{"egressCIDRs": ["192.168.1.0/24"]}'$ oc patch hostsubnet node2 -p '{"egressCIDRs": ["192.168.1.0/24"]}'

$ oc annotate netnamespace <namespace> \ netnamespace.network.openshift.io/multicast-enabled=true

$ oc annotate netnamespace <namespace> \ netnamespace.network.openshift.io/multicast-enabled-


103

3. マルチキャストを default プロジェクトで有効にするには、これを kube-service-catalog プロジェクトおよびグローバルにされた他のすべてのプロジェクトで有効にする必要もあります。グローバルプロジェクトは、マルチキャストの目的で「グローバル」である訳ではありません。グローバルプロジェクトの Pod で送信されるマルチキャストパケットはすべてのプロジェクトのすべての Pod にではなく、他のグローバルプロジェクトの Pod に送信されます。同様に、グローバルプロジェクトの Pod はすべてのプロジェクトのすべての Pod からではなく、他のグローバルプロジェクトの Pod から送信されるマルチキャストパケットのみを受信します。

ovs-networkpolicy プラグインを使用する場合:

1. Pod によって送信されるマルチキャストパケットは、NetworkPolicy オブジェクトに関係なく、プロジェクトの他のすべての Pod に送信されます (Pod はユニキャストで通信できない場合でもマルチキャストで通信できます)。

2. 1 つのプロジェクトの Pod によって送信されるマルチキャストパケットは、NetworkPolicy オブジェクトがプロジェクト間の通信を許可する場合であっても、それ以外のプロジェクトのPod に送信されることはありません。

8.10. NETWORKPOLICY の有効化

ovs-subnet および ovs-multitenant プラグインにはネットワークの分離についての独自のレガシーモデルがありますが、Kubernetes NetworkPolicy はサポートしません。ただし、NetworkPolicy サポートは、ovs-networkpolicy プラグインを使用すると利用できます。

注記注記

v1 NetworkPolicy 機能のみが OpenShift Container Platform で利用可能です。つまり、egress ポリシータイプ、IPBlock、および podSelector と namespaceSelector の組み合わせは Openshift Container Platform では使用できません。

注記注記

NetworkPolicy 機能はクラスターとの通信に障害を発生させる可能性があるため、これらの機能はデフォルトの OpenShift Container Platform プロジェクトでは使用できません。

警告警告

NetworkPolicy ルールはホストネットワーク namespace に適用されません。ホストネットワークが有効にされた Pod は、NetworkPolicy ルールによる影響を受けません。

configured to use the ovs-networkpolicy プラグインを使用するよう設定されているクラスターでは、ネットワークの分離は完全に NetworkPolicy オブジェクトによって制御されます。デフォルトで、プロジェクトのすべての Pod は他の Pod およびネットワークのエンドポイントからアクセスできます。プロジェクトで 1 つ以上の Pod を分離するには、そのプロジェクトで NetworkPolicy オブジェクトを作成し、許可する着信接続を指定します。プロジェクト管理者は独自のプロジェクト内で NetworkPolicy オブジェクトの作成および削除を実行できます。


104


https://github.com/kubernetes/community/blob/master/contributors/design-proposals/network/network-policy.md

Pod を参照する NetworkPolicy オブジェクトを持たない Pod は完全にアクセスできますが、Pod を参照する 1 つ以上の NetworkPolicy オブジェクトを持つ Pod は分離されます。これらの分離された Podは 1 つ以上の NetworkPolicy オブジェクトで許可される接続のみを受け入れます。

複数の異なるシナリオに対応するいくつかの NetworkPolicy オブジェクト定義のいくつかを見てみましょう。

すべてのトラフィックを拒否プロジェクトに「deny by default (デフォルトで拒否)」を実行させるには、すべての Pod に一致するが、トラフィックを一切許可しない NetworkPolicy オブジェクトを追加します。

プロジェクト内の Pod からの接続のみを許可Pod が同じプロジェクト内の他の Pod からの接続を受け入れるが、他のプロジェクトの Podからの接続を拒否するように設定するには、以下を実行します。

Pod ラベルに基づいて HTTP および HTTPS トラフィックのみを許可特定のラベル (以下の例の role=frontend) の付いた Pod への HTTP および HTTPS アクセスのみを有効にするには、以下と同様の NetworkPolicy オブジェクトを追加します。

NetworkPolicy オブジェクトは加算されるものです。つまり、複数の NetworkPolicy オブジェクトを組み合わせて複雑なネットワーク要件を満すことができます。

kind: NetworkPolicyapiVersion: networking.k8s.io/v1metadata: name: deny-by-defaultspec: podSelector: ingress: []

kind: NetworkPolicyapiVersion: networking.k8s.io/v1metadata: name: allow-same-namespacespec: podSelector: ingress: - from: - podSelector: {}

kind: NetworkPolicyapiVersion: networking.k8s.io/v1metadata: name: allow-http-and-httpsspec: podSelector: matchLabels: role: frontend ingress: - ports: - protocol: TCP port: 80 - protocol: TCP port: 443


105

たとえば、先の例で定義された NetworkPolicy オブジェクトの場合、同じプロジェト内に allow-same-namespace と allow-http-and-https ポリシーの両方を定義することができます。これにより、ラベル role=frontend の付いた Pod は各ポリシーで許可されるすべての接続、つまり、同じnamespace の Pod からのすべての接続、およびすべての namespace の Pod からのポート 80 443 での接続を受け入れます。

8.10.1. NetworkPolicy の効率的な使用

NetworkPolicy オブジェクトは、namespace 内でラベルで相互に区別される Pod を分離することを許可します。

NetworkPolicy オブジェクトを単一 namespace 内の多数の個別 Pod に適用することは効率的ではありません。Pod ラベルは IP レベルには存在しないため、NetworkPolicy オブジェクトは、podSelectorで選択されるすべての Pod 間のすべてのリンクについての別個の OVS フロールールを生成します。

たとえば、spec podSelector および ingress podSelector within a NetworkPolicy オブジェクトのそれぞれが 200 Pod に一致する場合、40000 (200*200) OVS フロールールが生成されます。これにより、マシンの速度が低下する可能性があります。

OVS フロールールの量を減らすには、namespace を使用して分離する必要のある Pod のグループを組み込みます。

namespace 全体を選択する NetworkPolicy オブジェクトは、namespaceSelectors または空の podSelectors を使用して、namespace の VXLAN VNID に一致する単一の OVS フロールールのみを生成します。

分離する必要のない Pod は元の namespace に維持し、分離する必要のある Pod は 1 つ以上の異なるnamespace に移します。

追加のターゲット設定された namespace 間のポリシーを作成し、分離された Pod から許可する必要のある特定のトラフィックを可能にします。

8.10.2. NetworkPolicy およびルーター

ovs-multitenant プラグインを使用する場合、ルーターからすべての namespace へのトラフィックは自動的に許可されます。これは、ルーターは通常デフォルトの namespace にあり、すべてのnamespace がその namespace の Pod からの接続を許可するためです。ただし ovs-networkpolicy プラグインを使用すると、これは自動的に実行されません。そのため、デフォルトで namespace を分離するポリシーがある場合は、ルーターがこれにアクセスできるように追加の手順を実行する必要があります。

1 つのオプションとして、すべてのソースからのアクセスを許可する各サービスのポリシーを作成できます。以下は例になります。

kind: NetworkPolicyapiVersion: networking.k8s.io/v1metadata: name: allow-to-database-servicespec: podSelector: matchLabels: role: database ingress: - ports: - protocol: TCP port: 5432


106

これにより、ルーターはサービスにアクセスできますが、同時に他のユーザーの namespace にあるPod もこれにアクセスできます。これらの Pod は通常はパブリックルーターを使用してサービスにアクセスできるため、これによって問題が発生することはないはずです。

または、ovs-multitenant プラグインの場合のように、デフォルト namespace からの完全アクセスを許可するポリシーを作成することもできます。

1. ラベルをデフォルト namespace に追加します。

重要重要

直前の手順でデフォルトプロジェクトに default ラベルを付けた場合、この手順を省略します。クラスター管理者ロールはラベルを namespace に追加する必要があります。

2. その namespace からの接続を許可するポリシーを作成します。

注記注記

接続を許可するそれぞれの namespace についてこの手順を実行します。プロジェクト管理者ロールを持つユーザーがポリシーを作成できます。

8.10.3. 新規プロジェクトのデフォルト NetworkPolicy の設定

クラスター管理者は、新規プロジェクトの作成時に、デフォルトのプロジェクトテンプレートを変更してデフォルトの NetworkPolicy オブジェクト (1 つ以上) の自動作成を有効にできます。これを実行するには、以下を行います。

1. カスタムプロジェクトテンプレートを作成し、マスターがこれを使用するように設定します。

2. default プロジェクトに default ラベルを付けます。

重要重要

直前の手順でデフォルトプロジェクトに default ラベルを付けた場合、この手順を省略します。クラスター管理者ロールはラベルを namespace に追加する必要があります。

$ oc label namespace default name=default

kind: NetworkPolicyapiVersion: networking.k8s.io/v1metadata: name: allow-from-default-namespacespec: podSelector: ingress: - from: - namespaceSelector: matchLabels: name: default


107

$ oc label namespace default name=default

3. 必要な NetworkPolicy オブジェクトを含むようにテンプレートを編集します。

$ oc edit template project-request -n default

注記注記

NetworkPolicy オブジェクトを既存テンプレートに含めるには、oc edit コマンドを使用します。現時点では、oc patch を使用してオブジェクトを Templateリソースに追加することはできません。

a. それぞれのデフォルトポリシーを objects 配列の要素として追加します。

8.11. HTTP STRICT TRANSPORT SECURITY の有効化

HTTP Strict Transport Security (HSTS) ポリシーは、ホストで HTTPS トラフィックのみを許可するセキュリティーの拡張機能です。デフォルトで、すべての HTTP 要求はドロップされます。これは、webサイトとの対話の安全性を確保したり、ユーザーのためにセキュアなアプリケーションを提供するのに役立ちます。

HSTS が有効にされると、HSTS はサイトから Strict Transport Security ヘッダーを HTTPS 応答に追加します。リダイレクトするルートで insecureEdgeTerminationPolicy 値を使用し、HTTP を HTTPSに送信するようにします。ただし、HSTS が有効にされている場合は、要求の送信前にクライアントがすべての要求を HTTP URL から HTTPS に変更するためにリダイレクトの必要がなくなります。これはクライアントでサポートされる必要はなく、max-age=0 を設定することで無効にできます。

重要重要

objects:...- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-same-namespace spec: podSelector: ingress: - from: - podSelector: {}- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-default-namespace spec: podSelector: ingress: - from: - namespaceSelector: matchLabels: name: default...


108

1

重要重要

HSTS はセキュアなルート (edge termination または re-encrypt) でのみ機能します。この設定は、HTTP またはパススルールートには適していません。

ルートに対して HSTS を有効にするには、haproxy.router.openshift.io/hsts_header 値を edgetermination または re-encrypt ルートに追加します。

重要重要

haproxy.router.openshift.io/hsts_header 値にパラメーターのスペースやその他の値が入っていないことを確認します。max-age のみが必要になります。

必須の max-age パラメーターは、HSTS ポリシーの有効期間 (秒単位) を示します。クライアントは、ホストから HSTS ヘッダーのある応答を受信する際には常に max-age を更新します。max-age がタイムアウトになると、クライアントはポリシーを破棄します。

オプションの includeSubDomains パラメーターは、クライアントに対し、ホストのすべてのサブドメインがホストど同様に処理されるように指示します。

max-age が 0 より大きい場合、オプションの preload パラメーターは外部サービスがこのサイトをそれぞれの HSTS プリロードのリストに含めることを許可します。たとえば、Google などのサイトは preload が設定されているサイトの一覧を作成します。ブラウザーはこれらのリストを使用し、サイトと対話する前でも HTTPS 経由でのみ通信するサイトを判別できます。preload 設定がない場合、ブラウザーはヘッダーを取得するために HTTPS 経由でサイトと通信している必要があります。

8.12. スループットの問題のトラブルシューティング

OpenShift Container Platform でデプロイされるアプリケーションでは、特定のサービス間で非常に長い待ち時間が発生するなど、ネットワークのスループットの問題が生じることがあります。

Pod のログが問題の原因を指摘しない場合は、以下の方法を使用してパフォーマンスの問題を分析します。

ping または tcpdump などのパケットアナライザーを使用して Pod とそのノード間のトラフィックを分析します。たとえば、問題を生じさせる動作を再現している間に各ノードで tcpdump ツールを実行します。両サイトでキャプチャーしたデータを確認し、送信および受信タイムスタンプを比較してPod への/からのトラフィックの待ち時間を分析します。待ち時間は、ノードのインターフェースが他の Pod やストレージデバイス、またはデータプレーンからのトラフィックでオーバーロードする場合に OpenShift Container Platform で発生する可能性があります。

$ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2> 1

podip は Pod の IP アドレスです。以下のコマンドを実行して Pod の IP アドレスを取得します。

apiVersion: v1kind: Routemetadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload


109

http://www.tcpdump.org/

# oc get pod <podname> -o wide

tcpdump は 2 つの Pod 間のすべてのトラフィックが含まれる /tmp/dump.pcap のファイルを生成します。理想的には、ファイルサイズを最小限に抑えるために問題を再現するすぐ前と問題を再現したすぐ後ににアナライザーを実行することが良いでしょう。以下のようにノード間でパケットアナライザーを実行することもできます (式から SDN を排除する)。

# tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789

ストリーミングのスループットおよび UDP スループットを測定するために iperf などの帯域幅測定ツールを使用します。ボトルネックの特定を試行するには、最初に Pod から、次にノードからツールを実行します。iperf3 ツールは RHEL 7 の一部として組み込まれています。

iperf3 のインストールおよび使用についての詳細は、こちらの Red Hat ソリューションを参照してください。


110


第9章サービスアカウントの設定

9.1. 概要

ユーザーが OpenShift Container Platform CLI または web コンソールを使用する場合、API トークンはユーザーを OpenShift Container Platform API に対して認証します。ただし、一般ユーザーの認証情報を利用できない場合、以下のようにコンポーネントが API 呼び出しを行うのが通例になります。

レプリケーションコントローラーが Pod を作成するか、または削除するために API 呼び出しを実行する。

コンテナー内のアプリケーションが検出目的で API 呼び出しを実行する。

外部アプリケーションがモニターまたは統合目的で API 呼び出しを実行する。

サービスアカウントは、一般ユーザーの認証情報を共有せずに API アクセスをより柔軟に制御する方法を提供します。

9.2. ユーザー名およびグループ

すべてのサービスアカウントには、一般ユーザーのようにロールを付与できるユーザー名が関連付けられています。ユーザー名はそのプロジェクトおよび名前から派生します。

system:serviceaccount:<project>:<name>

たとえば、view (表示) ロールを top-secret プロジェクトの robot サービスアカウントに追加するには、以下を実行します。

$ oc policy add-role-to-user view system:serviceaccount:top-secret:robot

重要重要

プロジェクトで特定のサービスアカウントにアクセスを付与する必要がある場合は、-zフラグを使用できます。サービスアカウントが属するプロジェクトから -z フラグを使用し、<serviceaccount_name> を指定します。これによりタイプミスの発生する可能性が減り、アクセスを指定したサービスアカウントのみに付与できるため、この方法を使用することを強くお勧めします。以下は例になります。

$ oc policy add-role-to-user <role_name> -z <serviceaccount_name>

プロジェクトから実行しない場合は、以下の例に示すように -n オプションを使用してこれが適用されるプロジェクトの namespace を指定します。

すべてのサービスアカウントは以下の 2 つのグループのメンバーでもあります。

system:serviceaccounts

システムのすべてのサービスアカウントが含まれます。

system:serviceaccounts:<project>

指定されたプロジェクトのすべてのサービスアカウントが含まれます。

たとえば、すべてのプロジェクトのすべてのサービスアカウントが top-secret プロジェクトのリソー

第第9章章サービスアカウントの設定サービスアカウントの設定

111

たとえば、すべてのプロジェクトのすべてのサービスアカウントが top-secret プロジェクトのリソースを表示できるようにするには、以下を実行します。

$ oc policy add-role-to-group view system:serviceaccounts -n top-secret

managers プロジェクトのすべてのサービスアカウントが top-secret プロジェクトのリソースを編集できるようにするには、以下を実行します。

$ oc policy add-role-to-group edit system:serviceaccounts:managers -n top-secret

9.3. サービスアカウントの管理

サービスアカウントは、各プロジェクトに存在する API オブジェクトです。サービスアカウントを管理するには、sa または serviceaccount オブジェクトタイプと共に oc コマンドを使用するか、またはweb コンソールを使用することができます。

現在のプロジェクトの既存のサービスアカウントの一覧を取得するには、以下を実行します。

$ oc get saNAME SECRETS AGEbuilder 2 2ddefault 2 2ddeployer 2 2d

新規のサービスアカウントを作成するには、以下を実行します。

$ oc create sa robotserviceaccount "robot" created

サービスアカウントの作成後すぐに、以下の 2 つのシークレットが自動的に追加されます。

API トークン

OpenShift Container レジストリーの認証情報

これらはサービスアカウントを記述すると表示できます。

$ oc describe sa robotName: robotNamespace: project1Labels: <none>Annotations: <none>

Image pull secrets: robot-dockercfg-qzbhb

Mountable secrets: robot-token-f4khf robot-dockercfg-qzbhb

Tokens: robot-token-f4khf robot-token-z8h44

システムはサービスアカウントに API トークンとレジストリーの認証情報が常にあることを確認します。


112

1

2

3

1

2

3

生成される API トークンとレジストリーの認証情報は期限切れになることはありませんが、シークレットを削除することで取り消すことができます。シークレットが削除されると、新規のシークレットが自動生成され、これに置き換わります。

9.4. サービスアカウント認証の有効化

サービスアカウントは、プライベート RSA キーで署名されるトークンを使用して API に対して認証されます。認証層では一致するパブリック RSA キーを使用して署名を検証します。

サービスアカウントトークンの生成を有効にするには、マスターで /etc/origin/master/master-config.yml ファイルの serviceAccountConfig スタンザを更新し、(署名用に) privateKeyFile と publicKeyFiles 一覧の一致するパブリックキーファイルを指定します。

serviceAccountConfig: ... masterCA: ca.crt 1 privateKeyFile: serviceaccount.private.key 2 publicKeyFiles: - serviceaccount.public.key 3 - ...

API サーバーの提供する証明書を検証するために使用される CA ファイル。

プライベート RSA キーファイル (トークンの署名用)。

パブリック RSA キーファイル (トークンの検証用)。プライベートキーファイルが提供されている場合、パブリックキーコンポーネントが使用されます。複数のパブリックキーファイルを使用でき、トークンはパブリックキーのいずれかで検証できる場合に受け入れられます。これにより、署名するキーのローテーションが可能となり、以前の署名者が生成したトークンは依然として受け入れられます。

9.5. 管理サービスアカウント

サービスアカウントは、ビルド、デプロイメントおよびその他の Pod を実行するために各プロジェクトで必要になります。マスターの /etc/origin/master/master-config.yml ファイルの managedNames 設定は、すべてのプロジェクトに自動作成されるサービスアカウントを制御します。

serviceAccountConfig: ... managedNames: 1 - builder 2 - deployer 3 - default 4 - ...

すべてのプロジェクトで自動作成するサービスアカウントの一覧。

各プロジェクトの builder サービスアカウントはビルド Pod で必要になり、system:image-builder ロールが付与されます。このロールは、内部コンテナーイメージレジストリーを使用してイメージをプロジェクトのイメージストリームにプッシュすることを可能にします。

各プロジェクトの deployer サービスアカウントはデプロイメント Pod で必要になり、レプリケーションコントローラーおよびプロジェクトの Pod の表示および変更を可能にするsystem:deployer ロールが付与されます。

第第9章章サービスアカウントの設定サービスアカウントの設定

113

4

system:deployer ロールが付与されます。

デフォルトのサービスアカウントは、別のサービスアカウントが指定されない限り、他のすべてのPod で使用されます。

プロジェクトのすべてのサービスアカウントには system:image-puller ロールが付与されます。このロールは、内部コンテナーイメージレジストリーを使用してイメージをイメージストリームからプルすることを可能にします。

9.6. インフラストラクチャーサービスアカウント

一部のインフラストラクチャーコントローラーは、サービスアカウント認証情報を使用して実行されます。以下のサービスアカウントは、サーバーの起動時に OpenShift Container Platform インフラストラクチャープロジェクト (openshift-infra) に作成され、クラスター全体で以下のロールが付与されます。

サービスアカウントサービスアカウント説明説明

replication-controller system:replication-controller ロールの割り当て

deployment-controller system:deployment-controller ロールの割り当て

build-controller system:build-controller ロールの割り当て。さらに、build-controller サービスアカウントは、特権付きのビルド Pod を作成するために特権付きセキュリティーコンテキストに組み込まれます。

これらのサービスアカウントが作成されるプロジェクトを設定するには、マスターで/etc/origin/master/master-config.yml ファイルの openshiftInfrastructureNamespace フィールドを設定します。

policyConfig: ... openshiftInfrastructureNamespace: openshift-infra

9.7. サービスアカウントおよびシークレット

マスターで /etc/origin/master/master-config.yml ファイルの limitSecretReferences フィールドを true に設定し、Pod のシークレット参照をサービスアカウントでホワイトリストに入れることが必要になるようにします。この値を false に設定すると、Pod がプロジェクトのすべてのシークレットを参照できるようになります。

serviceAccountConfig: ... limitSecretReferences: false


114

第10章ロールベースアクセス制御 (RBAC) の管理

10.1. 概要

CLI を使用して RBAC リソースを表示し、管理者 CLI を使用してロールとバインディングを管理することができます。

10.2. ロールとバインディングの表示

ロールは、クラスター全体およびプロジェクトのスコープの両方で各種のアクセスレベルを付与するために使用できます。ユーザーおよびグループは、1 度に複数のロールに関連付けるか、またはバインドすることができます。oc describe コマンドを使用して、ロールおよびそれらのバインディングの詳細を確認できます。

クラスター全体でバインドされた cluster-admin のデフォルトクラスターロールを持つユーザーはすべてのリソースに対してすべてのアクションを実行できます。ローカルにバインドされた admin のデフォルトクラスターロールを持つユーザーはそのプロジェクト内のロールとバインディングをローカルに管理できます。

注記注記

「Evaluating Authorization」セクションで動詞の詳細リストを確認してください。

10.2.1. クラスターロールの表示

クラスターロールおよびそれらの関連付けられたルールセットを表示するには、以下を実行します。

$ oc describe clusterrole.rbacName: adminLabels: <none>Annotations: openshift.io/description=A user that has edit rights within the project and can change the project's membership. rbac.authorization.kubernetes.io/autoupdate=truePolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- appliedclusterresourcequotas [] [] [get list watch] appliedclusterresourcequotas.quota.openshift.io [] [] [get list watch] bindings [] [] [get list watch] buildconfigs [] [] [create delete deletecollection get list patch update watch] buildconfigs.build.openshift.io [] [] [create delete deletecollection get list patch update watch] buildconfigs/instantiate [] [] [create] buildconfigs.build.openshift.io/instantiate [] [] [create] buildconfigs/instantiatebinary [] [] [create] buildconfigs.build.openshift.io/instantiatebinary [] [] [create] buildconfigs/webhooks [] [] [create delete deletecollection get list patch update watch] buildconfigs.build.openshift.io/webhooks [] [] [create delete deletecollection get list patch update watch] buildlogs [] [] [create delete deletecollection get list patch update watch] buildlogs.build.openshift.io [] [] [create delete deletecollection get list patch update watch] builds [] [] [create delete deletecollection get list patch update watch] builds.build.openshift.io [] [] [create delete deletecollection get list patch update watch] builds/clone [] [] [create]

第第10章章ロールベースアクセス制御ロールベースアクセス制御 (RBAC) の管理の管理

115


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#architecture-additional-concepts-authorization



https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#cluster-and-local-rbac

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#cluster-and-local-rbac

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#users-and-groups



https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#evaluating-authorization

builds.build.openshift.io/clone [] [] [create] builds/details [] [] [update] builds.build.openshift.io/details [] [] [update] builds/log [] [] [get list watch] builds.build.openshift.io/log [] [] [get list watch] configmaps [] [] [create delete deletecollection get list patch update watch] cronjobs.batch [] [] [create delete deletecollection get list patch update watch] daemonsets.extensions [] [] [get list watch] deploymentconfigrollbacks [] [] [create] deploymentconfigrollbacks.apps.openshift.io [] [] [create] deploymentconfigs [] [] [create delete deletecollection get list patch update watch] deploymentconfigs.apps.openshift.io [] [] [create delete deletecollection get list patch update watch] deploymentconfigs/instantiate [] [] [create] deploymentconfigs.apps.openshift.io/instantiate [] [] [create] deploymentconfigs/log [] [] [get list watch] deploymentconfigs.apps.openshift.io/log [] [] [get list watch] deploymentconfigs/rollback [] [] [create] deploymentconfigs.apps.openshift.io/rollback [] [] [create] deploymentconfigs/scale [] [] [create delete deletecollection get list patch update watch] deploymentconfigs.apps.openshift.io/scale [] [] [create delete deletecollection get list patch update watch] deploymentconfigs/status [] [] [get list watch] deploymentconfigs.apps.openshift.io/status [] [] [get list watch] deployments.apps [] [] [create delete deletecollection get list patch update watch] deployments.extensions [] [] [create delete deletecollection get list patch update watch] deployments.extensions/rollback [] [] [create delete deletecollection get list patch update watch] deployments.apps/scale [] [] [create delete deletecollection get list patch update watch] deployments.extensions/scale [] [] [create delete deletecollection get list patch update watch] deployments.apps/status [] [] [create delete deletecollection get list patch update watch] endpoints [] [] [create delete deletecollection get list patch update watch] events [] [] [get list watch] horizontalpodautoscalers.autoscaling [] [] [create delete deletecollection get list patch update watch] horizontalpodautoscalers.extensions [] [] [create delete deletecollection get list patch update watch] imagestreamimages [] [] [create delete deletecollection get list patch update watch] imagestreamimages.image.openshift.io [] [] [create delete deletecollection get list patch update watch] imagestreamimports [] [] [create] imagestreamimports.image.openshift.io [] [] [create] imagestreammappings [] [] [create delete deletecollection get list patch update watch] imagestreammappings.image.openshift.io [] [] [create delete deletecollection get list patch update watch] imagestreams [] [] [create delete deletecollection get list patch update watch] imagestreams.image.openshift.io [] [] [create delete deletecollection get list patch update watch] imagestreams/layers [] [] [get update] imagestreams.image.openshift.io/layers [] [] [get update] imagestreams/secrets [] [] [create delete deletecollection get list patch update watch] imagestreams.image.openshift.io/secrets [] [] [create delete deletecollection get list patch update watch] imagestreams/status [] [] [get list watch] imagestreams.image.openshift.io/status [] [] [get list watch] imagestreamtags [] [] [create delete deletecollection get list patch update watch] imagestreamtags.image.openshift.io [] [] [create delete deletecollection get list patch update watch]


116

jenkins.build.openshift.io [] [] [admin edit view] jobs.batch [] [] [create delete deletecollection get list patch update watch] limitranges [] [] [get list watch] localresourceaccessreviews [] [] [create] localresourceaccessreviews.authorization.openshift.io [] [] [create] localsubjectaccessreviews [] [] [create] localsubjectaccessreviews.authorization.k8s.io [] [] [create] localsubjectaccessreviews.authorization.openshift.io [] [] [create] namespaces [] [] [get list watch] namespaces/status [] [] [get list watch] networkpolicies.extensions [] [] [create delete deletecollection get list patch update watch] persistentvolumeclaims [] [] [create delete deletecollection get list patch update watch] pods [] [] [create delete deletecollection get list patch update watch] pods/attach [] [] [create delete deletecollection get list patch update watch] pods/exec [] [] [create delete deletecollection get list patch update watch] pods/log [] [] [get list watch] pods/portforward [] [] [create delete deletecollection get list patch update watch] pods/proxy [] [] [create delete deletecollection get list patch update watch] pods/status [] [] [get list watch] podsecuritypolicyreviews [] [] [create] podsecuritypolicyreviews.security.openshift.io [] [] [create] podsecuritypolicyselfsubjectreviews [] [] [create] podsecuritypolicyselfsubjectreviews.security.openshift.io [] [] [create] podsecuritypolicysubjectreviews [] [] [create] podsecuritypolicysubjectreviews.security.openshift.io [] [] [create] processedtemplates [] [] [create delete deletecollection get list patch update watch] processedtemplates.template.openshift.io [] [] [create delete deletecollection get list patch update watch] projects [] [] [delete get patch update] projects.project.openshift.io [] [] [delete get patch update] replicasets.extensions [] [] [create delete deletecollection get list patch update watch] replicasets.extensions/scale [] [] [create delete deletecollection get list patch update watch] replicationcontrollers [] [] [create delete deletecollection get list patch update watch] replicationcontrollers/scale [] [] [create delete deletecollection get list patch update watch] replicationcontrollers.extensions/scale [] [] [create delete deletecollection get list patch update watch] replicationcontrollers/status [] [] [get list watch] resourceaccessreviews [] [] [create] resourceaccessreviews.authorization.openshift.io [] [] [create] resourcequotas [] [] [get list watch] resourcequotas/status [] [] [get list watch] resourcequotausages [] [] [get list watch] rolebindingrestrictions [] [] [get list watch] rolebindingrestrictions.authorization.openshift.io [] [] [get list watch] rolebindings [] [] [create delete deletecollection get list patch update watch] rolebindings.authorization.openshift.io [] [] [create delete deletecollection get list patch update watch] rolebindings.rbac.authorization.k8s.io [] [] [create delete deletecollection get list patch update watch] roles [] [] [create delete deletecollection get list patch update watch] roles.authorization.openshift.io [] [] [create delete deletecollection get list patch update watch] roles.rbac.authorization.k8s.io [] [] [create delete deletecollection get list patch update watch] routes [] [] [create delete deletecollection get list patch update watch] routes.route.openshift.io [] [] [create delete deletecollection get list patch update watch] routes/custom-host [] [] [create] routes.route.openshift.io/custom-host [] [] [create]


117

routes/status [] [] [get list watch update] routes.route.openshift.io/status [] [] [get list watch update] scheduledjobs.batch [] [] [create delete deletecollection get list patch update watch] secrets [] [] [create delete deletecollection get list patch update watch] serviceaccounts [] [] [create delete deletecollection get list patch update watch impersonate] services [] [] [create delete deletecollection get list patch update watch] services/proxy [] [] [create delete deletecollection get list patch update watch] statefulsets.apps [] [] [create delete deletecollection get list patch update watch] subjectaccessreviews [] [] [create] subjectaccessreviews.authorization.openshift.io [] [] [create] subjectrulesreviews [] [] [create] subjectrulesreviews.authorization.openshift.io [] [] [create] templateconfigs [] [] [create delete deletecollection get list patch update watch] templateconfigs.template.openshift.io [] [] [create delete deletecollection get list patch update watch] templateinstances [] [] [create delete deletecollection get list patch update watch] templateinstances.template.openshift.io [] [] [create delete deletecollection get list patch update watch] templates [] [] [create delete deletecollection get list patch update watch] templates.template.openshift.io [] [] [create delete deletecollection get list patch update watch]

Name: basic-userLabels: <none>Annotations: openshift.io/description=A user that can get basic information about projects. rbac.authorization.kubernetes.io/autoupdate=truePolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- clusterroles [] [] [get list] clusterroles.authorization.openshift.io [] [] [get list] clusterroles.rbac.authorization.k8s.io [] [] [get list watch] projectrequests [] [] [list] projectrequests.project.openshift.io [] [] [list] projects [] [] [list watch] projects.project.openshift.io [] [] [list watch] selfsubjectaccessreviews.authorization.k8s.io [] [] [create] selfsubjectrulesreviews [] [] [create] selfsubjectrulesreviews.authorization.openshift.io [] [] [create] storageclasses.storage.k8s.io [] [] [get list] users [] [~] [get] users.user.openshift.io [] [~] [get]

Name: cluster-adminLabels: <none>Annotations: authorization.openshift.io/system-only=true openshift.io/description=A super-user that can perform any action in the cluster. When granted to a user within a project, they have full control over quota and membership and can perform every action... rbac.authorization.kubernetes.io/autoupdate=truePolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- [*] [] [*] *.* [] [] [*]


118

Name: cluster-debuggerLabels: <none>Annotations: authorization.openshift.io/system-only=true rbac.authorization.kubernetes.io/autoupdate=truePolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- [/debug/pprof] [] [get] [/debug/pprof/*] [] [get] [/metrics] [] [get]

Name: cluster-readerLabels: <none>Annotations: authorization.openshift.io/system-only=true rbac.authorization.kubernetes.io/autoupdate=truePolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- [*] [] [get] apiservices.apiregistration.k8s.io [] [] [get list watch] apiservices.apiregistration.k8s.io/status [] [] [get list watch] appliedclusterresourcequotas [] [] [get list watch]

...

10.2.2. クラスターのロールバインディングの表示

各種のロールにバインドされたユーザーおよびグループを示す、クラスターのロールバインディングの現在のセットを表示するには、以下を実行します。

$ oc describe clusterrolebinding.rbacName: adminLabels: <none>Annotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: adminSubjects: Kind Name Namespace ---- ---- --------- ServiceAccount template-instance-controller openshift-infra

Name: basic-usersLabels: <none>Annotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: basic-userSubjects: Kind Name Namespace ---- ---- ---------


119

Group system:authenticated

Name: cluster-adminLabels: kubernetes.io/bootstrapping=rbac-defaultsAnnotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: cluster-adminSubjects: Kind Name Namespace ---- ---- --------- ServiceAccount pvinstaller default Group system:masters

Name: cluster-adminsLabels: <none>Annotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: cluster-adminSubjects: Kind Name Namespace ---- ---- --------- Group system:cluster-admins User system:admin

Name: cluster-readersLabels: <none>Annotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: cluster-readerSubjects: Kind Name Namespace ---- ---- --------- Group system:cluster-readers

Name: cluster-status-bindingLabels: <none>Annotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: cluster-statusSubjects: Kind Name Namespace ---- ---- --------- Group system:authenticated Group system:unauthenticated

Name: registry-registry-roleLabels: <none>


120

Annotations: <none>Role: Kind: ClusterRole Name: system:registrySubjects: Kind Name Namespace ---- ---- --------- ServiceAccount registry default

Name: router-router-roleLabels: <none>Annotations: <none>Role: Kind: ClusterRole Name: system:routerSubjects: Kind Name Namespace ---- ---- --------- ServiceAccount router default

Name: self-access-reviewersLabels: <none>Annotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: self-access-reviewerSubjects: Kind Name Namespace ---- ---- --------- Group system:authenticated Group system:unauthenticated

Name: self-provisionersLabels: <none>Annotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: self-provisionerSubjects: Kind Name Namespace ---- ---- --------- Group system:authenticated:oauth

Name: system:basic-userLabels: kubernetes.io/bootstrapping=rbac-defaultsAnnotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: system:basic-userSubjects: Kind Name Namespace ---- ---- ---------


121

Group system:authenticated Group system:unauthenticated

Name: system:build-strategy-docker-bindingLabels: <none>Annotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: system:build-strategy-dockerSubjects: Kind Name Namespace ---- ---- --------- Group system:authenticated

Name: system:build-strategy-jenkinspipeline-bindingLabels: <none>Annotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: system:build-strategy-jenkinspipelineSubjects: Kind Name Namespace ---- ---- --------- Group system:authenticated

Name: system:build-strategy-source-bindingLabels: <none>Annotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: system:build-strategy-sourceSubjects: Kind Name Namespace ---- ---- --------- Group system:authenticated

Name: system:controller:attachdetach-controllerLabels: kubernetes.io/bootstrapping=rbac-defaultsAnnotations: rbac.authorization.kubernetes.io/autoupdate=trueRole: Kind: ClusterRole Name: system:controller:attachdetach-controllerSubjects: Kind Name Namespace ---- ---- --------- ServiceAccount attachdetach-controller kube-system

Name: system:controller:certificate-controllerLabels: kubernetes.io/bootstrapping=rbac-defaultsAnnotations: rbac.authorization.kubernetes.io/autoupdate=trueRole:


122

Kind: ClusterRole Name: system:controller:certificate-controllerSubjects: Kind Name Namespace ---- ---- --------- ServiceAccount certificate-controller kube-system

Name: system:controller:cronjob-controllerLabels: kubernetes.io/bootstrapping=rbac-defaultsAnnotations: rbac.authorization.kubernetes.io/autoupdate=true

...

10.2.3. ローカルのロールバインディングの表示

すべてのデフォルトクラスターロールは、ユーザーまたはグループにローカルにバインドできます。

カスタムローカルロールを作成できます。

ローカルのロールバインディングも表示することができます。

各種のロールにバインドされたユーザーおよびグループを示す、ローカルのロールバインディングの現在のセットを表示するには、以下を実行します。

$ oc describe rolebinding.rbac

デフォルトでは、ローカルのロールバインディングを表示する際に現在のプロジェクトが使用されます。または、プロジェクトは -n フラグで指定できます。これは、ユーザーに admin のデフォルトクラスターロールがすでにある場合、別のプロジェクトのローカルのロールバンディングを表示するのに役立ちます。

$ oc describe rolebinding.rbac -n joe-projectName: adminLabels: <none>Annotations: <none>Role: Kind: ClusterRole Name: adminSubjects: Kind Name Namespace ---- ---- --------- User joe

Name: system:deployersLabels: <none>Annotations: <none>Role: Kind: ClusterRole Name: system:deployerSubjects: Kind Name Namespace ---- ---- --------- ServiceAccount deployer joe-project


123



Name: system:image-buildersLabels: <none>Annotations: <none>Role: Kind: ClusterRole Name: system:image-builderSubjects: Kind Name Namespace ---- ---- --------- ServiceAccount builder joe-project

Name: system:image-pullersLabels: <none>Annotations: <none>Role: Kind: ClusterRole Name: system:image-pullerSubjects: Kind Name Namespace ---- ---- --------- Group system:serviceaccounts:joe-project

10.3. ロールバインディングの管理

ロールをユーザーまたはグループに追加するか、またはバインドすることにより、そのユーザーまたはグループにそのロールによって付与される関連アクセスが提供されます。oc adm policy コマンドを使用して、ユーザーおよびグループに対するロールの追加および削除を実行できます。

以下の操作を使用し、ローカルのロールバインディングでのユーザーまたはグループの関連付けられたロールを管理する際に、プロジェクトは -n フラグで指定できます。これが指定されていない場合には、現在のプロジェクトが使用されます。

表10.1 ローカルのロールバインディング操作

コマンドコマンド説明説明

$ oc adm policy who-can <verb> <resource> リソースに対してアクションを実行できるユーザーを示します。

$ oc adm policy add-role-to-user <role> <username>

指定されたロールを現在のプロジェクトの指定ユーザーにバインドします。

$ oc adm policy remove-role-from-user <role> <username>

現在のプロジェクトの指定ユーザーから指定されたロールを削除します。

$ oc adm policy remove-user <username> 現在のプロジェクトの指定ユーザーとそれらのロールのすべてを削除します。

$ oc adm policy add-role-to-group <role> <groupname>

指定されたロールを現在のプロジェクトの指定グループにバインドします。


124


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#users-and-groups

$ oc adm policy remove-role-from-group <role> <groupname>

現在のプロジェクトの指定グループから指定されたロールを削除します。

$ oc adm policy remove-group <groupname> 現在のプロジェクトの指定グループとそれらのロールのすべてを削除します。

--rolebinding-name= ユーザーまたはグループに割り当てられたロールバインディング名を保持するために oc adm policyコマンドと共に使用できます。


以下の操作を使用して、クラスターのロールバインディングも管理できます。クラスターのロールバインディングは namespace を使用していないリソースを使用するため、-n フラグはこれらの操作に使用されません。

表10.2 クラスターのロールバインディング操作


$ oc adm policy add-cluster-role-to-user <role> <username>

指定されたロールをクラスターのすべてのプロジェクトの指定ユーザーにバインドします。

$ oc adm policy remove-cluster-role-from-user <role> <username>

指定されたロールをクラスターのすべてのプロジェクトの指定ユーザーから削除します。

$ oc adm policy add-cluster-role-to-group <role> <groupname>

指定されたロールをクラスターのすべてのプロジェクトの指定グループにバインドします。

$ oc adm policy remove-cluster-role-from-group <role> <groupname>

指定されたロールをクラスターのすべてのプロジェクトの指定グループから削除します。

--rolebinding-name= ユーザーまたはグループに割り当てられたロールバインディング名を保持するために oc adm policyコマンドと共に使用できます。

たとえば、以下を実行して admin ロールを joe-project の alice ユーザーに追加できます。

$ oc adm policy add-role-to-user admin alice -n joe-project

次に、ローカルのロールバインディングを表示し、出力に追加されていることを確認します。

$ oc describe rolebinding.rbac -n joe-projectName: adminLabels: <none>Annotations: <none>Role: Kind: ClusterRole Name: adminSubjects:


125

1

Kind Name Namespace ---- ---- --------- User joe

Name: admin-0 1Labels: <none>Annotations: <none>

Role: Kind: ClusterRole Name: adminSubjects: Kind Name Namespace ---- ---- --------- User alice 2

Name: system:deployersLabels: <none>Annotations: <none>Role: Kind: ClusterRole Name: system:deployerSubjects: Kind Name Namespace ---- ---- --------- ServiceAccount deployer joe-project

Name: system:image-buildersLabels: <none>Annotations: <none>Role: Kind: ClusterRole Name: system:image-builderSubjects: Kind Name Namespace ---- ---- --------- ServiceAccount builder joe-project

Name: system:image-pullersLabels: <none>Annotations: <none>Role: Kind: ClusterRole Name: system:image-pullerSubjects: Kind Name Namespace ---- ---- --------- Group system:serviceaccounts:joe-project

新規のロールバインディングがデフォルト名で作成され、必要に応じて増分されます。既存のロールバインディングを指定して変更するには、ユーザーにロールを追加する際に --rolebinding-name オプションを使用します。


126

2 ユーザー alice が追加されます。

10.4. ローカルロールの作成

プロジェクトのローカルロールを作成し、これをユーザーにバインドできます。

1. プロジェクトのローカルロールを作成するには、以下のコマンドを実行します。

$ oc create role <name> --verb=<verb> --resource=<resource> -n <project>

このコマンドで、以下を指定します: * <name>、ローカルロールの名前 * <verb>、ロールに適用する動詞のカンマ区切りの一覧 * <resource>、ロールが適用されるリソース * <project>、プロジェクト名

+ たとえば、ユーザーが blue プロジェクトで Pod を閲覧できるようにするローカルロールを作成するには、以下のコマンドを実行します。

+

$ oc create role podview --verb=get --resource=pod -n blue

2. 新規ロールをユーザーにバインドするには、以下のコマンドを実行します。

$ oc adm policy add-role-to-user podview user2 --role-namespace=blue -n blue

10.5. クラスターロールの作成

クラスターロールを作成するには、以下のコマンドを実行します。

$ oc create clusterrole <name> --verb=<verb> --resource=<resource>

コマンドで以下を指定します。

<name>: ローカルのロール名です。

<verb>: ロールに適用する動詞のカンマ区切りの一覧です。

<resource>: ロールが適用されるリソースです。

たとえば、ユーザーが Pod を閲覧できるようにするクラスターロールを作成するには、以下のコマンドを実行します。

$ oc create clusterrole podviewonly --verb=get --resource=pod

10.6. クラスターおよびローカルのロールバインディング

クラスターのロールバインディングは、クラスターレベルで存在するバインディングですが、ロールバインディングはプロジェクトレベルで存在します。クラスターの view (表示) ロールは、ユーザーがプロジェクトを表示できるようローカルのロールバインディングを使用してユーザーにバインドする必要があります。ローカルロールは、クラスターのロールが特定の状況に必要なパーミッションのセットを提供しない場合にのみ作成する必要があります。


127

一部のクラスターのロール名は最初は判別しにくい場合があります。クラスターロール cluster-adminは、ローカルのロールバインディングを使用してユーザーにバインドでき、このユーザーがクラスター管理者の特権を持っているように見せますが、実際にはそうではありません。一方、特定プロジェクトにバインドされる cluster-admin クラスターロールはそのプロジェクトのスーパー管理者のような機能があり、クラスターロール admin のパーミッションを付与するほか、レート制限を編集する機能などのいくつかの追加パーミッションを付与します。これは、クラスター管理者にバインドされるクラスターのロールバインディングを一覧表示しない Web コンソール UI を使う場合にとくに分かりにくくなりますが、この Web コンソール UI はローカルのロールバインディング (cluster-admin をローカルにバインドするために使用される) を一覧表示します。

10.7. ポリシー定義の更新

クラスターのアップグレード時に、また任意のマスターの再起動時は常に、デフォルトのクラスターロールが欠落しているパーミッションを復元するために自動的に調整されます。

デフォルトクラスターロールをカスタマイズしており、ロールの調整によってそれらが変更されないようにするには、以下を実行します。

1. 各ロールを調整から保護します。

$ oc annotate clusterrole.rbac <role_name> --overwrite rbac.authorization.kubernetes.io/autoupdate=false

警告警告

この設定を含むロールがアップグレード後に新規または必須のパーミッションを組み込むように手動で更新する必要があります。

2. デフォルトのブートストラップポリシーテンプレートを生成します。

$ oc adm create-bootstrap-policy-file --filename=policy.json

注記注記

ファイルの内容は OpenShift Container Platform バージョンによって異なりますが、ファイルにはデフォルトポリシーのみが含まれます。

3. policy.json ファイルを、クラスターロールのカスタマイズを組み込むように更新します。

4. ポリシーを使用し、調整から保護されていないロールおよびロールバインディングを自動的に調整します。

$ oc auth reconcile -f policy.json

5. SCC (Security Context Constraints) を調整します。


128


# oc adm policy reconcile-sccs \ --additive-only=true \ --confirm


129

1

2

3

第11章イメージポリシー

11.1. 概要

インポートするイメージや、タグ付けしたり、クラスターで実行したりするイメージを制御することができます。この目的のために使用できる 2 つの機能があります。

インポート用に許可されるレジストリーは、イメージの起点 (origin) を特定の外部レジストリーのセットに制限できるイメージポリシー設定です。このルールセットはイメージストリームにインポートされるか、またはタグ付けされるすべてのイメージに適用されます。したがって、ルールセットと一致しないレジストリーを参照するイメージは拒否されます。

ImagePolicy 受付プラグインを使用すると、クラスターでの実行を許可するイメージを指定できます。これは現時点ではベータ機能と見なされています。この機能により、以下を制御することができます。

イメージソース: イメージのプルに使用できるレジストリーについての指定。

イメージの解決: イメージが再タグ付けによって変更されないよう Pod のイミュータブルなダイジェストでの実行を強制する。

コンテナーイメージラベルの制限: イメージのラベルを制限するか、または要求する。

イメージアノテーションの制限: 統合コンテナーイメージレジストリーでイメージのアノテーションを制限するか、または要求する。

11.2. インポート用に許可されるレジストリーの設定

以下の例に示されるように、imagePolicyConfig:allowedRegistriesForImport セクション以下にあるmaster-config.yaml にインポート用に許可されるレジスターを設定できます。この設定がない場合は、すべてのイメージが許可されます。これはデフォルトになります。

例11.1 インポート用に許可されるレジストリーの設定例

指定されたセキュアなレジストリーからのイメージを許可します。

mydomain.com の任意のサブドメインでホストされる非セキュアなレジストリーからのイメージを許可します。mydomain.com はホワイトリストに追加されません。

ポートが指定された指定レジストリーからのイメージを許可します。

各ルールは以下の属性で構成されています。

imagePolicyConfig: allowedRegistriesForImport: - domainName: registry.redhat.io 1 - domainName: *.mydomain.com insecure: true 2 - domainName: local.registry.corp:5000 3


130

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#master-config-image-policy-config

domainName: ホスト名であり、オプションでその最後は :<port> サフィックスになり、ここで特殊なワイルドカード文字 (?、*) が認識されます。ワイルドカード文字は : 区切り文字の前後の両方に置くことができます。ワイルドカードは区切り文字の前または後の部分に適用されます。

insecure: :<port> の部分が domainName にない場合、一致するポートを判別するために使用されるブール値です。true の場合、domainName はインポート時に非セキュアなフラグが使用されている限り、サフィックスが :80 のポートが設定されているか、またはポートが未指定のレジストリーに一致します。false の場合、サフィックスが :443 のポートか、またはポートが未指定のレジストリーが一致します。

ルールが同じドメインのセキュアなポートと非セキュアなポートの両方に一致する場合、ルールは 2 回一覧表示されるはずです (1 回は insecure=true が設定され、もう 1 回は insecure=false が設定されます)。

修飾されていないイメージ参照は、ルールの評価前に docker.io に対して修飾されます。これらをホワイトリストに追加するには、domainName: docker.io を使用します。

domainName: * ルールは任意のレジストリーのホスト名に一致しますが、ポートは依然として 443 に制限された状態になります。任意のポートで機能する任意のレジストリーに一致させるには、domainName: *:* を使用します。

インポート用に許可されるレジストリーの設定例で設定されるルールに基づいて、以下が実行されます。

oc tag --insecure reg.mydomain.com/app:v1 app:v1 は、mydomain.com ルールの処理によってホワイトリストに追加されます。

oc import-image --from reg1.mydomain.com:80/foo foo:latest もホワイトリストに追加されます。

oc tag local.registry.corp/bar bar:latest は、ポートが 3 番目のルールの 5000 に一致しないために拒否されます。

拒否されたイメージのインポートにより、以下のテキストのようなエラーメッセージが生成されます。

The ImageStream "bar" is invalid:* spec.tags[latest].from.name: Forbidden: registry "local.registry.corp" not allowed by whitelist: "local.registry.corp:5000", "*.mydomain.com:80", "registry.redhat.io:443"* status.tags[latest].items[0].dockerImageReference: Forbidden: registry "local.registry.corp" not allowed by whitelist: "local.registry.corp:5000", "*.mydomain.com:80", "registry.redhat.io:443"

11.3. IMAGEPOLICY 受付プラグインの設定

クラスターで実行できるイメージを設定するには、ImagePolicy 受付プラグインを master-config.yamlファイルで設定します。1 つまたは複数のルールを必要に応じて設定できます。

特定のアノテーションを持つイメージの拒否:このルールを使用して、特定のアノテーションが設定されたすべてのイメージを拒否します。以下は、images.openshift.io/deny-execution アノテーションを使用してすべてのイメージを拒否します。

- name: execution-denied onResources: - resource: pods

第第11章章イメージポリシーイメージポリシー

131

1 特定のイメージが有害であるとみなされる場合、管理者はそれらのイメージにフラグを付けるためにこのアノテーションを設定できます。

ユーザーの Docker Hub からのイメージの実行を許可:このルールを使用して、ユーザーが Docker Hub からのイメージを使用できるようにできます。

以下は、複数の ImagePolicy 受付プラグインルールを master-config.yaml ファイルに設定する設定例です。

アノテーション付きのサンプルファイルアノテーション付きのサンプルファイル

- resource: builds reject: true matchImageAnnotations: - key: images.openshift.io/deny-execution 1 value: "true" skipOnResolutionFailure: true

- name: allow-images-from-dockerhub onResources: - resource: pods - resource: builds matchRegistries: - docker.io

admissionConfig: pluginConfig: openshift.io/ImagePolicy: configuration: kind: ImagePolicyConfig apiVersion: v1 resolveImages: AttemptRewrite 1 executionRules: 2 - name: execution-denied # Reject all images that have the annotation images.openshift.io/deny-execution set to true. # This annotation may be set by infrastructure that wishes to flag particular images as dangerous onResources: 3 - resource: pods - resource: builds reject: true 4 matchImageAnnotations: 5 - key: images.openshift.io/deny-execution value: "true" skipOnResolutionFailure: true 6 - name: allow-images-from-internal-registry # allows images from the internal registry and tries to resolve them onResources: - resource: pods - resource: builds matchIntegratedRegistry: true - name: allow-images-from-dockerhub


132

1

2

3

4

5

6

7

8

9

イミュータブルなイメージダイジェストを使用してイメージを解決し、Pod でイメージのプル仕様を更新します。

着信リソースに対して評価するルールの配列です。reject: true ルールのみがある場合、デフォルトは allow all になります。reject: false である accept ルールがルールのいずれかに含まれる場合、ImagePolicy のデフォルト動作は deny all に切り替わります。

ルールを実施するリソースを示します。何も指定されていない場合、デフォルトは pods になります。

このルールが一致する場合、Pod は拒否されることを示します。

イメージオブジェクトのメタデータで一致するアノテーションの一覧。

イメージを解決できない場合に Pod は失敗しません。

Kubernetes リソースでのイメージストリームの使用を許可するルールの配列。デフォルト設定は、pods、replicationcontrollers、replicasets、statefulsets、daemonsets、deployments およびjobs がイメージフィールドで同じプロジェクトイメージストリームのタグ参照を使用することを許可します。

このルールが適用されるグループおよびリソースを特定します。リソースが * の場合、このルールはそのグループのすべてのリソースに適用されます。

LocalNames は、単一のセグメント名 (例: ruby:2.5) が、リソースまたはターゲットイメージストリームで local name resolution が有効にされている場合にのみ namespace のローカルイメージストリームタグとして解釈されるようにします。

注記注記

デフォルトのレジストリープレフィックス (docker.io または registry.redhat.io など) を使用してプルされるインフラストラクチャーイメージを通常使用する場合、レジストリープレフィックスがないイメージは matchRegistries 値には一致しません。インフラストラクチャーイメージにイメージポリシーに一致するレジストリープレフィックスを持たせるには、master-config.yaml ファイルに imageConfig.format 値を設定します。

11.4. 受付コントローラーを使用した ALWAYS PULL イメージの使用

onResources: - resource: pods - resource: builds matchRegistries: - docker.io resolutionRules: 7 - targetResource: resource: pods localNames: true policy: AttemptRewrite - targetResource: 8 group: batch resource: jobs localNames: true 9 policy: AttemptRewrite


133

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#using-is-with-k8s

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#master-config-image-config

1

2

イメージがノードにプルされると、任意のユーザーのノード上の Pod は、イメージに対する認証チェックなしにイメージを使用できます。Pod が認証情報を持たないイメージを使用しないようにするには、AlwaysPullImages 受付コントローラーを使用します。

この受付コントローラーは新しい Pod すべてを変更して、イメージプルポリシーを Always に強制的に設定し、Pod 仕様がNever のイメージプルポリシーを使用していても、プライベートイメージが、それらをプルするための認証情報がある場合にのみ使用されるようにします。

AlwaysPullImages 受付コントローラーを有効にするには、以下を実行します。

1. 以下を master-config.yaml に追加します。

admissionConfig: pluginConfig: AlwaysPullImages: 1 configuration: kind: DefaultAdmissionConfig apiVersion: v1 disable: false 2

受付プラグイン名です。

プラグインを有効にする必要があることを示唆するために false を指定します。

2. master-restart コマンドを使用してコントロールプレーンの静的 Pod で実行されているマスターサービスを再起動します。

$ master-restart api$ master-restart controllers

11.5. IMAGEPOLICY 受付プラグインのテスト

1. openshift/image-policy-check を使用して設定をテストします。たとえば、上記の情報を使用して、以下のようにテストします。

oc import-image openshift/image-policy-check:latest --confirm

2. この YAML を使用して Pod を作成します。Pod が作成されるはずです。

apiVersion: v1kind: Podmetadata: generateName: test-podspec: containers: - image: docker.io/openshift/image-policy-check:latest name: first

3. 別のレジストリーを参照する別の Pod を作成します。Pod は拒否されます。

apiVersion: v1kind: Podmetadata:


134


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#image-pull-policy

generateName: test-podspec: containers: - image: different-registry/openshift/image-policy-check:latest name: first

4. インポートされたイメージを使用して内部レジストリーを参照する Pod を作成します。Pod は作成され、イメージ仕様を確認すると、タグの位置にダイジェストが表示されます。

apiVersion: v1kind: Podmetadata: generateName: test-podspec: containers: - image: <internal registry IP>:5000/<namespace>/image-policy-check:latest name: first

5. インポートされたイメージを使用して内部レジストリーを参照する Pod を作成します。Pod は作成され、イメージ仕様を確認すると、タグが変更されていないことを確認できます。

apiVersion: v1kind: Podmetadata: generateName: test-podspec: containers: - image: <internal registry IP>:5000/<namespace>/image-policy-check:v1 name: first

6. oc get istag/image-policy-check:latest からダイジェストを取得し、これを oc annotate images/<digest> images.openshift.io/deny-execution=true に使用します。以下は例になります。

$ oc annotate images/sha256:09ce3d8b5b63595ffca6636c7daefb1a615a7c0e3f8ea68e5db044a9340d6ba8images.openshift.io/deny-execution=true

7. この Pod を再作成します。Pod は拒否されます。

apiVersion: v1kind: Podmetadata: generateName: test-podspec: containers: - image: <internal registry IP>:5000/<namespace>/image-policy-check:latest name: first


135

第12章イメージの署名

12.1. 概要

Red Hat Enterprise Linux (RHEL) システムでのコンテナーイメージの署名により、以下を実行できます。

コンテナーイメージの起点の検証

イメージが改ざんされていないことの確認

ホストにプルできる検証済みイメージを判別するポリシーの設定

RHEL システムでのコンテナーイメージの署名についてのアーキテクチャーの詳細は、「ContainerImage Signing Integration Guide」を参照してください。

OpenShift Container レジストリーは、REST API 経由で署名を保存する機能を提供します。oc CLI を使用して、検証済みのイメージを web コンソールまたは CLI に表示し、イメージの署名を検証することができます。

12.2. ATOMIC CLI を使用したイメージの署名

OpenShift Container Platform はイメージの署名を自動化しません。署名には、通常はワークステーションに安全に保存される開発者のプライベート GPG キーが必要になります。本書では、このワークフローについて説明します。

atomic コマンドラインインターフェース (CLI)(バージョン 1.12.5 以降) は、OpenShift Container レジストリーにプッシュできるコンテナーイメージに署名するためのコマンドを提供します。atomic CLI は、Red Hat ベースのディストリビューション (RHEL、Centos、および Fedora) で利用できます。atomicCLI は RHEL Atomic Host システムには事前にインストールされます。atomic パッケージの RHEL ホストへのインストールについての詳細は、「イメージ署名サポートの有効化」を参照してください。

重要重要

atomic CLI は、oc login で認証された証明書を使用します。atomic および oc コマンドの両方で同じホストの同じユーザーを使用するようにしてください。たとえば、atomicCLI を sudo として使用する場合、OpenShift Container Platform に sudo oc login を使用してログインします。

署名をイメージに割り当てるには、ユーザーに image-signer クラスターロールがなければなりません。クラスター管理者は以下を使用してこれを追加できます。

$ oc adm policy add-cluster-role-to-user system:image-signer <user_name>

イメージにはプッシュ時に署名できます。

$ atomic push [--sign-by <gpg_key_id>] --type atomic <image>

署名は、atomic トランスポートタイプの引数が指定される際に OpenShift Container Platform に保存されます。詳細は、「Signature Transports」を参照してください。

atomic CLI を使用してイメージをセットアップし、実行する方法についての詳細は、「RHEL Atomic


136

https://access.redhat.com/articles/2750891#architecture

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/installing_clusters/#enabling-image-signature-support

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/container_security_guide/#security-deployment-signature-transports

atomic CLI を使用してイメージをセットアップし、実行する方法についての詳細は、「RHEL AtomicHost Managing Containers: Signing Container Images」ドキュメントか、または atomic push --help 出力で引数の詳細を参照してください。

atomic CLI および OpenShift Container レジストリーの使用についてのワークフローの特定の例については、「Container Image Signing Integration Guide」で説明されています。

12.3. OPENSHIFT CLI を使用したイメージ署名の検証

oc adm verify-image-signature コマンドを使用して、OpenShift Container レジストリーにインポートされたイメージの署名を検証できます。このコマンドは、イメージ署名に含まれるイメージ ID が信頼できるかどうかを検証します。ここでは、パブリック GPG キーを使用して署名自体を検証し、提供される予想 ID と指定イメージの ID (プル仕様) のマッチングが行われます。

デフォルトで、このコマンドは通常 $GNUPGHOME/pubring.gpg にあるパブリック GPG キーリングをパス ~/.gnupg で使用します。デフォルトで、このコマンドは検証結果をイメージオブジェクトに保存し直すことはありません。これを実行するには、以下に示すように --save フラグを指定する必要があります。

注記注記

イメージの署名を検証するには、ユーザーに image-auditor クラスターロールがなければなりません。クラスター管理者は、以下を使用してこれを追加できます。

$ oc adm policy add-cluster-role-to-user system:image-auditor <user_name>

重要重要

検証済みのイメージで無効な GPG キーまたは無効な予想 ID と共に --save フラグを使用すると、保存された検証ステータスおよびすべての署名が削除され、イメージは未検証の状態になります。

誤ってすべての署名を削除してしまうことを避けるために、最初は --save フラグなしでコマンドを実行し、ログで潜在的な問題の有無を確認できます。

イメージ署名を検証するには、以下の形式を使用します。

$ oc adm verify-image-signature <image> --expected-identity=<pull_spec> [--save] [options]

<pull_spec> はイメージストリームを記述して確認でき、<image> はイメージストリームタグを記述して確認することができます。以下のコマンド出力例を参照してください。

イメージ署名の検証例イメージ署名の検証例

$ oc describe is nodejs -n openshiftName: nodejsNamespace: openshiftCreated: 2 weeks agoLabels: <none>Annotations: openshift.io/display-name=Node.js openshift.io/image.dockerRepositoryCheck=2017-07-05T18:24:01ZDocker Pull Spec: 172.30.1.1:5000/openshift/nodejs...

第第12章章イメージの署名イメージの署名

137

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/managing_containers/signing_container_images

https://access.redhat.com/articles/2750891#working-with-openshift-and-atomic-registry

$ oc describe istag nodejs:latest -n openshiftImage Name: sha256:2bba968aedb7dd2aafe5fa8c7453f5ac36a0b9639f1bf5b03f95de325238b288...

$ oc adm verify-image-signature \ sha256:2bba968aedb7dd2aafe5fa8c7453f5ac36a0b9639f1bf5b03f95de325238b288 \ --expected-identity 172.30.1.1:5000/openshift/nodejs:latest \ --public-key /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release \ --save

注記注記

oc adm verify-image-signature コマンドが x509: certificate signed by unknown authority エラーを返す場合、システムで信頼されている CA の一覧にレジストリーの認証局 (CA) を追加する必要がある場合があります。これは、以下の手順で実行できます。

1. CA 証明書をクラスターからクライアントマシンに転送します。たとえば、docker-registry.default.svc の CA を追加するには、/etc/docker/certs.d/docker-registry.default.svc\:5000/node-client-ca.crt にあるファイルを転送します。

2. CA 証明書を /etc/pki/ca-trust/source/anchors/ ディレクトリーにコピーします。以下に例を示します。

# cp </path_to_file>/node-client-ca.crt \ /etc/pki/ca-trust/source/anchors/

3. update-ca-trust を実行して、信頼される CA の一覧を更新します。

# update-ca-trust

12.4. レジストリー API の使用によるイメージ署名へのアクセス

OpenShift Container レジストリーは、イメージ署名の書き込みおよび読み取りを実行できる extensions エンドポイントを提供します。イメージ署名は、コンテナーイメージレジストリー API 経由で OpenShift Container Platform の KVS (key-value store) に保存されます。

注記注記

このエンドポイントは実験段階にあり、アップストリームのコンテナーイメージレジストリープロジェクトではサポートされていません。コンテナーイメージレジストリーAPI の一般的な情報については、アップストリーム API のドキュメントを参照してください。

12.4.1. API 経由でのイメージ署名の書き込み

新規署名をイメージに追加するには、HTTP PUT メソッドを使用して JSON ペイロードを extensionsエンドポイントに送信できます。

PUT /extensions/v2/<namespace>/<name>/signatures/<digest>


138

https://docs.docker.com/registry/spec/api/

$ curl -X PUT --data @signature.json http://<user>:<token>@<registry_endpoint>:5000/extensions/v2/<namespace>/<name>/signatures/sha256:<digest>

署名コンテンツを含む JSON ペイロードの構造は以下のようになります。

{ "version": 2, "type": "atomic", "name": "sha256:4028782c08eae4a8c9a28bf661c0a8d1c2fc8e19dbaae2b018b21011197e1484@cddeb7006d914716e2728000746a0b23", "content": "<cryptographic_signature>"}

name フィールドには、<digest>@<name> 形式の一意の値であるイメージ署名の名前が含まれます。<digest> はイメージ名を表し、<name> は署名の名前になります。署名の名前には 32 文字の長さが必要です。<cryptographic_signature> は、コンテナー/イメージライブラリーで説明されている仕様に従っている必要があります。

12.4.2. API 経由でのイメージ署名の読み取り

署名済みのイメージが OpenShift Container レジストリーにすでにプッシュされていることを仮定した場合、以下のコマンドを使って署名を読み取ることができます。

GET /extensions/v2/<namespace>/<name>/signatures/<digest>

$ curl http://<user>:<token>@<registry_endpoint>:5000/extensions/v2/<namespace>/<name>/signatures/sha256:<digest>

<namespace> は OpenShift Container Platform プロジェクト名またはレジストリーのリポジトリー名を表し、<name> はイメージリポジトリーの名前を指します。digest はイメージの SHA-256 チェックサムを表します。

指定されたイメージに署名データが含まれる場合、上記のコマンド出力により、以下の JSON 応答が生成されます。

{ "signatures": [ { "version": 2, "type": "atomic", "name": "sha256:4028782c08eae4a8c9a28bf661c0a8d1c2fc8e19dbaae2b018b21011197e1484@cddeb7006d914716e2728000746a0b23", "content": "<cryptographic_signature>" } ]}

name フィールドには、<digest>@<name> 形式の一意の値であるイメージ署名の名前が含まれます。<digest> はイメージ名を表し、<name> は署名の名前になります。署名の名前には 32 文字の長さが必要です。<cryptographic_signature> は、コンテナー/イメージライブラリーで説明されている仕

第第12章章イメージの署名イメージの署名

139

https://github.com/containers/image/blob/master/docs/atomic-signature.md#the-cryptographic-signature

https://github.com/containers/image/blob/master/docs/atomic-signature.md#the-cryptographic-signature

1

様に従っている必要があります。

12.4.3. 署名ストアからのイメージ署名の自動インポート

OpenShift Container Platform は、署名ストアがすべての OpenShift Container Platform マスターノードに設定されている場合に、レジストリー設定ディレクトリーを使用してイメージ署名を自動インポートします。

レジストリー設定ディレクトリーには、各種レジストリー (リモートコンテナーイメージを保存するサーバー) およびそれらに保存されるコンテンツの設定が含まれます。この単一ディクトリーを使用すると、設定がコンテナー/イメージのすべてのユーザー間で共有されるように、各コマンドのコマンドラインオプションでその設定を指定する必要がありません。

デフォルトのレジストリー設定ディレクトリーは、/etc/containers/registries.d/default.yaml ファイルにあります。

すべての Red Hat イメージについてイメージ署名の自動インポートを実行する設定例:

docker: registry.redhat.io: sigstore: https://registry.redhat.io/containers/sigstore 1

署名ストアの URL を定義します。この URL は、既存署名の読み取りに使用されます。

注記注記

OpenShift Container Platform によって自動的にインポートされる署名は、デフォルトで未検証の状態になり、イメージ管理者による検証が必要になります。

レジストリー設定ディレクトリーについての詳細は、「Registries Configuration Directory」を参照してください。


140

https://github.com/containers/image/blob/master/docs/containers-registries.d.5.md

第13章スコープ付きトークン

13.1. 概要

ユーザーは、他のエンティティーに対し、自らと同様に機能する権限を制限された方法で付与する必要があるかもしれません。たとえば、プロジェクト管理者は Pod の作成権限を委任する必要があるかもしれません。これを実行する方法の 1 つとして、スコープ付きトークンを作成することができます。

スコープ付きトークンは、指定されるユーザーを識別するが、そのスコープによって特定のアクションに制限するトークンです。現時点で、cluster-admin のみがスコープ付きトークンを作成できます。

13.2. 評価

スコープは、トークンの一連のスコープを PolicyRules のセットに変換して評価されます。次に、要求がそれらのルールに対してマッチングされます。要求属性は、追加の許可検査のために「標準」承認者に渡せるよう、スコープルールのいずれかに一致している必要があります。

13.3. ユーザースコープ

ユーザースコープでは、指定されたユーザーについての情報を取得することにフォーカスが置かれます。それらはインテントベースであるため、ルールは自動的に作成されます。

user:full - Allows full read/write access to the API with all of the user’s permissions.

user:info - Allows read-only access to information about the user: name, groups, and so on.

user:check-access - Allows access to self-localsubjectaccessreviews and self-subjectaccessreviews. These are the variables where you pass an empty user and groups inyour request object.

user:list-projects - Allows read-only access to list the projects the user has access to.

13.4. ロールスコープ

ロールスコープにより、 namespace でフィルターされる指定ロールと同じレベルのアクセスを持たせることができます。

role:<cluster-role name>:<namespace or * for all>: 指定された namespace のみにあるクラスターロール (cluster-role) で指定されるルールにスコープを制限します。

注記注記

注意: これは、アクセスのエスカレートを防ぎます。ロールはシークレット、ロールバインディング、およびロールなどのリソースへのアクセスを許可しますが、このスコープはそれらのリソースへのアクセスを制限するのに役立ちます。これにより、予期しないエスカレーションを防ぐことができます。edit (編集)などのロールはエスカレートされるロールと見なされないことが多いですが、シークレットのアクセスを持つロールの場合はロールのエスカレーションが生じます。

role:<cluster-role name>:<namespace or * for all>:!: bang (!) を含めることでこのスコープでアクセスのエスカレートを許可されますが、それ以外には上記の例と同様になります。

第第13章章スコープ付きトークンスコープ付きトークン

141

第14章イメージのモニタリング

14.1. 概要

CLI を使用し、インスタンスでイメージおよびノードをモニタリングできます。

14.2. イメージ統計の表示

OpenShift Container Platform が管理するすべてのイメージの使用状況についてのいくつかの統計を表示できます。つまり、直接またはビルドによって内部レジストリーにプッシュされるすべてのイメージの統計を表示できます。


$ oc adm top imagesNAME IMAGESTREAMTAG PARENTS USAGE METADATA STORAGEsha256:80c985739a78b openshift/python (3.5) yes 303.12MiBsha256:64461b5111fc7 openshift/ruby (2.2) yes 234.33MiBsha256:0e19a0290ddc1 test/ruby-ex (latest) sha256:64461b5111fc71ec Deployment: ruby-ex-1/test yes 150.65MiBsha256:a968c61adad58 test/django-ex (latest) sha256:80c985739a78b760 Deployment: django-ex-1/test yes 186.07MiB

コマンドにより、以下の情報が表示されます。

イメージ ID

プロジェクト、名前、および付随する ImageStreamTag のタグ

イメージ ID で一覧表示されるイメージの潜在的な親

イメージが使用される場所についての情報

イメージに適切な Docker メタデータ情報が含まれるかどうかを示すフラグ

イメージのサイズ

14.3. IMAGESTREAMS 統計の表示

すべての ImageStreams の使用状況についてのいくつかの統計を表示できます。


$ oc adm top imagestreamsNAME STORAGE IMAGES LAYERSopenshift/python 1.21GiB 4 36openshift/ruby 717.76MiB 3 27test/ruby-ex 150.65MiB 1 10test/django-ex 186.07MiB 1 10

コマンドにより、以下の情報が表示されます。


142


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#image-streams

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#access-pushing-and-pulling-images

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-how-builds-work

プロジェクトおよび ImageStream の名前

内部 Red Hat Container Registryに保存される ImageStream 全体のサイズ

この特定の ImageStream が参照しているイメージの数

ImageStream を構成する層の数

14.4. イメージのプルーニング

上記のコマンドで返される情報は、イメージのプルーニングを実行する際に役立ちます。

第第14章章イメージのモニタリングイメージのモニタリング

143

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-registry-overview

第15章 SCC (SECURITY CONTEXT CONSTRAINTS) の管理

15.1. 概要

SCC (Security Context Constraints) により、管理者は Pod のパーミッションを制御できます。このAPI タイプについての詳細は、SCC (security context constraints) アーキテクチャーのドキュメントを参照してください。SCC は、CLI を使用し、インスタンスで通常の API オブジェクトとして管理できます。

注記注記

SCC を管理するには、cluster-admin 権限が必要です。

重要重要

デフォルトの SCC を変更しないでください。デフォルトの SCC をカスタマイズすると、アップグレード時に問題が生じる可能性があります。代わりに新規 SCC を作成してください。

15.2. SCC (SECURITY CONTEXT CONSTRAINTS) の一覧表示

SCC の現在の一覧を取得するには、以下を実行します。

$ oc get scc

NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMESanyuid false [] MustRunAs RunAsAny RunAsAny RunAsAny 10 false [configMap downwardAPI emptyDir persistentVolumeClaim secret]hostaccess false [] MustRunAs MustRunAsRange MustRunAs RunAsAny <none> false [configMap downwardAPI emptyDir hostPath persistentVolumeClaim secret]hostmount-anyuid false [] MustRunAs RunAsAny RunAsAny RunAsAny <none> false [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim secret]hostnetwork false [] MustRunAs MustRunAsRange MustRunAs MustRunAs <none> false [configMap downwardAPI emptyDir persistentVolumeClaim secret]nonroot false [] MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <none> false [configMap downwardAPI emptyDir persistentVolumeClaim secret]privileged true [*] RunAsAny RunAsAny RunAsAny RunAsAny <none> false [*]restricted false [] MustRunAs MustRunAsRange MustRunAs RunAsAny <none> false [configMap downwardAPI emptyDir persistentVolumeClaim secret]

15.3. SCC (SECURITY CONTEXT CONSTRAINTS) オブジェクトの検査

特定の SCC についての情報（SCC が適用されるユーザー、サービスアカウントおよびグループを含む）を表示できます。

たとえば、制限付き SCC を検査するには、以下を実行します。

$ oc describe scc restrictedName: restrictedPriority: <none>


144

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#security-context-constraints


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#architecture-core-concepts-index


1

2

Access: Users: <none> 1 Groups: system:authenticated 2Settings: Allow Privileged: false Default Add Capabilities: <none> Required Drop Capabilities: KILL,MKNOD,SYS_CHROOT,SETUID,SETGID Allowed Capabilities: <none> Allowed Seccomp Profiles: <none> Allowed Volume Types: configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret Allow Host Network: false Allow Host Ports: false Allow Host PID: false Allow Host IPC: false Read Only Root Filesystem: false Run As User Strategy: MustRunAsRange UID: <none> UID Range Min: <none> UID Range Max: <none> SELinux Context Strategy: MustRunAs User: <none> Role: <none> Type: <none> Level: <none> FSGroup Strategy: MustRunAs Ranges: <none> Supplemental Groups Strategy: RunAsAny Ranges: <none>

SCC が適用されているユーザーとサービスアカウントを一覧表示します。

SCC が適用されるグループを一覧表示します。

注記注記

アップグレード時にカスタマイズされた SCC を保持するには、優先順位、ユーザー、グループ、ラベル、およびアノテーション以外にはデフォルトの SCC の設定を編集しないでください。

15.4. 新規 SCC (SECURITY CONTEXT CONSTRAINTS) の作成

新規 SCC を作成するには、以下を実行します。

1. JSON または YAML ファイルで SCC を定義します。

SCC (Security Context Constraints) オブジェクトの定義オブジェクトの定義

kind: SecurityContextConstraintsapiVersion: v1metadata: name: scc-adminallowPrivilegedContainer: truerunAsUser:

第第15章章 SCC (SECURITY CONTEXT CONSTRAINTS) の管理の管理

145

type: RunAsAnyseLinuxContext: type: RunAsAnyfsGroup: type: RunAsAnysupplementalGroups: type: RunAsAnyusers:- my-admin-usergroups:- my-admin-group

オプションとして、requiredDropCapabilities フィールドに必要な値を設定してドロップ機能を SCC に追加することができます。指定された機能はコンテナーからドロップされることになります。たとえば、SCC を KILL、MKNOD、および SYS_CHROOT の必要なドロップ機能を使って作成するには、以下を SCC オブジェクトに追加します。

requiredDropCapabilities:- KILL- MKNOD- SYS_CHROOT

使用できる値の一覧は、Docker ドキュメントで確認できます。

ヒントヒント

機能は Docker に渡されるため、特殊な ALL 値を使用してすべての機能をドロップすることができます。

2. 次に、作成するファイルを渡して oc create を実行します。

$ oc create -f scc_admin.yamlsecuritycontextconstraints "scc-admin" created

3. SCC が作成されていることを確認します。

$ oc get scc scc-adminNAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMESscc-admin true [] RunAsAny RunAsAny RunAsAny RunAsAny <none> false [awsElasticBlockStore azureDisk azureFile cephFS cinder configMap downwardAPI emptyDir fc flexVolume flocker gcePersistentDisk glusterfs iscsi nfs persistentVolumeClaim photonPersistentDisk quobyte rbd secret vsphere]

15.5. SCC (SECURITY CONTEXT CONSTRAINTS) の削除

SCC を削除するには、以下を実行します。

$ oc delete scc <scc_name>

注記注記


146

https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities

1

注記注記

デフォルトの SCC を削除する場合、これは再起動時に再生成されます。

15.6. SCC (SECURITY CONTEXT CONSTRAINTS) の更新

既存 SCC を更新するには、以下を実行します。

$ oc edit scc <scc_name>

注記注記

アップグレード時にカスタマイズされた SCC を保持するには、優先順位、ユーザー、グループ以外にデフォルトの SCC の設定を編集しないでください。

15.6.1. SCC (Security Context Constraints) 設定のサンプル

明示的な明示的な runAsUser 設定がない場合設定がない場合

apiVersion: v1kind: Podmetadata: name: security-context-demospec: securityContext: 1 containers: - name: sec-ctx-demo image: gcr.io/google-samples/node-hello:1.0

コンテナーまたは Pod が実行時に使用するユーザー ID を要求しない場合、有効な UID はこのPod を作成する SCC よって異なります。制限付き SCC はデフォルトですべての認証ユーザーに付与されるため、ほとんどの場合はすべてのユーザーおよびサービスアカウントで利用でき、使用されます。この制限付き SCC は、securityContext.runAsUser フィールドの使用できる値を制限し、これをデフォルトに設定するために MustRunAsRange ストラテジーを使用します。受付プラグインではこの範囲を指定しないため、現行プロジェクトで openshift.io/sa.scc.uid-range アノテーションを検索して範囲フィールドにデータを設定します。最終的にコンテナーの runAsUser は予測が困難な範囲の最初の値と等しい値になります。予測が困難であるのはすべてのプロジェクトにはそれぞれ異なる範囲が設定されるためです。詳細は、「Understanding Pre-allocated Values and Security Context Constraints (事前に割り当てられた値および SCC (SecurityContext Constraint) について)」を参照してください。

明示的な明示的な runAsUser 設定がない場合設定がない場合

apiVersion: v1kind: Podmetadata: name: security-context-demospec: securityContext: runAsUser: 1000 1


147

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#understanding-pre-allocated-values-and-security-context-constraints

1

containers: - name: sec-ctx-demo image: gcr.io/google-samples/node-hello:1.0

特定のユーザー ID を要求するコンテナーまたは Pod が OpenShift Container Platform によって受け入れられるのは、サービスアカウントまたはユーザーにそのユーザー ID を許可する SCC へのアクセスが付与されている場合のみです。SCC は、任意の ID や特定の範囲内にある ID、または要求に固有のユーザー ID を許可します。

これは SELinux、fsGroup、および Supplemental Groups で機能します。詳細は、「Volume Security(ボリュームセキュリティー)」を参照してください。

15.7. デフォルト SCC (SECURITY CONTEXT CONSTRAINTS) の更新

デフォルト SCC は、それらが見つからない場合にはマスターの起動時に作成されます。SCC をデフォルトにリセットするか、またはアップグレード後に既存の SCC を新規のデフォルト定義に更新するには、以下を実行します。

1. リセットする SCC を削除し、マスターを再起動してその再作成を実行します。

2. oc adm policy reconcile-sccs コマンドを使用します。

oc adm policy reconcile-sccs コマンドは、すべての SCC ポリシーをデフォルト値に設定しますが、すでに設定した可能性のある追加ユーザー、グループ、ラベル、アノテーションおよび優先順位を保持します。変更される SCC を表示するには、オプションなしでコマンドを実行するか、または -o <format> オプションで優先する出力を指定してコマンドを実行します。

確認後は、既存 SCC のバックアップを取ってから --confirm オプションを使用してデータを永続化します。

注記注記

優先順位や許可をリセットする場合は、--additive-only=false オプションを使用します。

注記注記

SCC に優先順位、ユーザー、グループ、ラベル、またはアノテーション以外のカスタマイズ設定がある場合、これらの設定は調整時に失われます。

15.8. 使用方法

以下では、SCC を使用する一般的なシナリオおよび手順について説明します。

15.8.1. 特権付き SCC のアクセス付与

管理者が管理者グループ外のユーザーまたはグループに対して特権付き Pod を追加作成するためのアクセスを付与することが必要になることがあります。これを実行するには、以下を行います。

1. SCC へのアクセスを付与するユーザーまたはグループを決定します。


148

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-persistent-storage-pod-security-context

警告警告

ユーザーへのアクセス付与は、ユーザーが Pod を直接作成する場合にのみ可能です。ほとんどの場合、システム自体がユーザーの代わりに作成するPod については、関連するコントローラーの作動に使用されるサービスアカウントにアクセスを付与する必要があります。ユーザーの代わりに Podを作成するリソースの例として、Deployments、StatefulSets、DaemonSets などが含まれます。

2. 以下を実行します。

$ oc adm policy add-scc-to-user <scc_name> <user_name>$ oc adm policy add-scc-to-group <scc_name> <group_name>

たとえば、e2e-user の特権付き SCC へのアクセスを許可するには、以下を実行します。

$ oc adm policy add-scc-to-user privileged e2e-user

3. 特権モードを要求するようにコンテナーの SecurityContext を変更します。

15.8.2. 特権付き SCC のサービスアカウントアクセスの付与

最初に、サービスアカウントを作成します。たとえば、サービスアカウント mysvcacct をプロジェクト myproject で作成するには、以下を実行します。

$ oc create serviceaccount mysvcacct -n myproject

次に、サービスアカウントを特権付き SCC に追加します。

$ oc adm policy add-scc-to-user privileged system:serviceaccount:myproject:mysvcacct

その後は、リソースがサービスアカウントの代わりに作成されていることを確認します。これを実行するには、spec.serviceAccountName フィールドをサービスアカウント名に設定します。サービスアカウント名を空のままにすると、デフォルトのサービスアカウントが使用されます。

次に、少なくとも 1 つの Pod のコンテナーがセキュリティーコンテキストで特権モードを要求していることを確認します。

15.8.3. Dokerfile の USER によるイメージ実行の有効化

特権付き SCC へのアクセスをすべての人に与えることなく、イメージが事前割り当て UID で強制的に実行されないようにクラスターのセキュリティーを緩和するには、以下を実行します。

1. すべての認証されたユーザーに anyuid SCC へのアクセスを付与します。

$ oc adm policy add-scc-to-group anyuid system:authenticated


149

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-service-accounts

警告警告

これにより、USER が Dockerfile に指定されていない場合は、イメージをルートID で実行することができます。

15.8.4. ルートを要求するコンテナーイメージの有効化

一部のコンテナーイメージ (例: postgres および redis) には root アクセスが必要であり、ボリュームの保有方法についてのいくつかの予測が設定されています。これらのイメージについては、サービスアカウントを anyuid SCC に追加します。

$ oc adm policy add-scc-to-user anyuid system:serviceaccount:myproject:mysvcacct

15.8.5. レジストリーでの --mount-host の使用

PersistentVolume および PersistentVolumeClaim オブジェクトを使用する永続ストレージオブジェクトをレジストリーのデプロイメントに使用することが推奨されます。テストを実行中で、oc adm registry コマンドを --mount-host オプションと共に使用する必要がある場合には、まずレジストリーの新規サービスアカウントを作成し、これを特権付き SCC に追加する必要があります。詳細の説明については、『Administrator Guide』を参照してください。

15.8.6. 追加機能の提供

場合によっては、Docker が追加設定なしの機能として提供していない機能がイメージで必要になることがあります。この場合、Pod 仕様で追加機能を要求することができ、これは SCC に対して検証されます。

重要重要

これによりイメージを昇格された機能を使って実行できますが、これは必要な場合にのみ実行する必要があります。追加機能を有効にするためにデフォルトの restricted SCCを編集することはできません。

非 root ユーザーによって使用される場合、setcap コマンドを使用して、追加機能を要求するファイルに該当する機能が付与されていることを確認する必要もあります。たとえば、イメージの Dockerfileでは、以下のようになります。

setcap cap_net_raw,cap_net_admin+p /usr/bin/ping

さらに機能が Docker のデフォルトとして提供されている場合には、これを要求するために Pod 仕様を変更する必要はありません。たとえば、NET_RAW がデフォルトで指定されており、機能がすでに ping で設定されている場合、ping を実行するのに特別な手順は必要ありません。

追加機能を提供するには、以下を実行します。

1. 新規 SCC を作成します。

2. allowedCapabilities フィールドを使用して許可された機能を追加します。


150

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#architecture-additional-concepts-storage

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-registry-overview

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#storage-for-the-registry

3. Pod の作成時に、securityContext.capabilities.add フィールドで機能を要求します。

15.8.7. クラスターのデフォルト動作の変更

すべてのユーザーに対して anyuid SCC のアクセスを付与する場合、クラスターは以下のようになります。

UID を事前に割り当てない

コンテナーの任意ユーザーとしての実行を許可する

特権付きコンテナーを禁止する

$ oc adm policy add-scc-to-group anyuid system:authenticated

UID を事前に割り当てないようにし、コンテナーが root で実行されないようにクラスターを変更するには、すべてのユーザーに対して nonroot SCC のアクセスを付与します。

$ oc adm policy add-scc-to-group nonroot system:authenticated

警告警告

クラスター全体に影響を与える変更を行う際には十分に注意してください。直前の例のようにすべての認証ユーザーに SCC を付与したり、制限付き SCC のようにすべてのユーザーに適用される SCC を変更する場合には、Web コンソールや統合コンテナーイメージレジストリーなどの Kubernetes および OpenShift ContainerPlatform コンポーネントにも影響を与えます。これらの SCC に関する変更により、これらのコンポーネントの機能は停止する可能性があります。

代わりに、カスタム SCC を作成し、このターゲットを特定のユーザーまたはグループのみに指定します。これにより、潜在的な問題の影響を特定の影響を受けるユーザーまたはグループに制限し、重要なクラスターコンポーネントに影響が及ばないようにすることができます。

15.8.8. hostPath ボリュームプラグインの使用

privileged、hostaccess、または hostmount-anyuid などの特権付き SCC へのアクセスをすべての人に付与することなく、Pod で hostPath ボリュームプラグインを使用できるようにクラスターのセキュリティーを緩和するには、以下を実行します。

1. hostpath という名前の新規 SCC を作成します。

2. 新規 SCC の allowHostDirVolumePlugin パラメーターを true に設定します。

$ oc patch scc hostpath -p '{"allowHostDirVolumePlugin": true}'

3. この SCC へのアクセスをすべてのユーザーに付与します。

$ oc adm policy add-scc-to-group hostpath system:authenticated


151

これで、hostPath ボリュームを要求するすべての Pod は hostpath SCC で許可されます。

15.8.9. 受付を使用した特定 SCC の初回使用

SCC の Priority フィールドを設定し、受付コントローラーで SCC の並び替え順序を制御することができます。並び替えについての詳細は、「SCC Prioritization」セクションを参照してください。

15.8.10. SCC のユーザー、グループまたはプロジェクトへの追加

SCC をユーザーまたはグループに追加する前に、まず scc-review オプションを使用してユーザーまたはグループが Pod を作成できるかどうかをチェックできます。詳細は、「Authorization」のトピックを参照してください。

SCC はプロジェクトに直接付与されません。代わりに、サービスアカウントを SCC に追加し、Pod にサービスアカウント名を指定するか、または指定されない場合は default サービスアカウントを使用して実行します。

SCC をユーザーに追加するには、以下を実行します。

$ oc adm policy add-scc-to-user <scc_name> <user_name>

SCC をサービスアカウントに追加するには、以下を実行します。

$ oc adm policy add-scc-to-user <scc_name> \ system:serviceaccount:<serviceaccount_namespace>:<serviceaccount_name>

現在の場所がサービスアカウントが属するプロジェクトの場合、-z フラグを使用し、<serviceaccount_name> のみを指定することができます。

$ oc adm policy add-scc-to-user <scc_name> -z <serviceaccount_name>

重要重要

上記の -z フラグについては、誤字を防ぎ、アクセスが指定されたサービスアカウントのみに付与されるため、その使用をを強く推奨します。プロジェクトにいない場合は、-nオプションを使用して、それが適用されるプロジェクトの namespace を指定します。

SCC をグループに追加するには、以下を実行します。

$ oc adm policy add-scc-to-group <scc_name> <group_name>

SCC を namespace のすべてのサービスアカウントに追加するには、以下を実行します。

$ oc adm policy add-scc-to-group <scc_name> \ system:serviceaccounts:<serviceaccount_namespace>


152

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#scc-prioritization

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-authorization

第16章スケジューリング

16.1. 概要

16.1.1. 概要

Pod のスケジューリングは、クラスター内のノードへの新規 Pod の配置を決定する内部プロセスです。

スケジューラーコードは、新規 Pod の作成時にそれらを確認し、それらをホストするのに最も適したノードを識別します。次に、マスター API を使用して Pod のバインディング (Pod とノードのバインディング) を作成します。

16.1.2. デフォルトスケジューリング

OpenShift Container Platform には、ほとんどのユーザーのニーズに対応するデフォルトスケジューラーが同梱されます。デフォルトスケジューラーは、Pod に最適なノードを判別するための固有のツールおよびカスタマイズ可能なツールの両方を使用します。

デフォルトスケジューラーが Pod の配置と利用できるカスタマイズ可能なパラメーターを判別する方法についての詳細は、「デフォルトスケジューリング」を参照してください。

16.1.3. 詳細スケジューリング

新規 Pod の配置場所に対する制御を強化する必要がある場合、OpenShift Container Platform の詳細スケジューリング機能を使用すると、Pod が特定ノード上か、または特定の Pod と共に実行されることを要求する (または実行されることが優先される) よう Pod を設定することができます。また詳細設定により、Pod をノードに配置することや他の Pod と共に実行することを防ぐこともできます。

詳細スケジューリングについての詳細は、「詳細スケジューリング」を参照してください。

16.1.4. カスタムスケジューリング

OpenShift Container Platform では、Pod 仕様を編集してユーザー独自のスケジューラーまたはサードパーティーのスケジューラーを使用することもできます。

詳細は、「カスタムスケジューラー」を参照してください。

16.2. デフォルトスケジューリング

16.2.1. 概要

OpenShift Container Platform のデフォルトの Pod スケジューラーは、クラスター内のノードにおける新規 Pod の配置場所を判別します。スケジューラーは Pod からのデータを読み取り、設定されるポリシーに基づいて適切なノードを見つけようとします。これは完全に独立した機能であり、スタンドアロン/プラグ可能ソリューションです。Pod を変更することはなく、Pod を特定ノードに関連付ける Podのバインディングのみを作成します。

16.2.2. 汎用スケジューラー

既存の汎用スケジューラーはプラットフォームで提供されるデフォルトのスケジューラーエンジンであり、Pod をホストするノードを 3 つの手順で選択します。

第第16章章スケジューリングスケジューリング

153

1. スケジューラーは述語を使用して不適切なノードをフィルターに掛けて除外します。

2. スケジューラーはノードのフィルターされた一覧の優先順位付けを行います。

3. スケジューラーは、Pod の最も優先順位の高い Pod を選択します。

16.2.3. ノードのフィルター

利用可能なノードは、指定される制約や要件に基づいてフィルターされます。フィルターは、各ノードで述語というフィルター関数の一覧を使用して実行されます。

16.2.3.1. フィルターされたノード一覧の優先順位付けフィルターされたノード一覧の優先順位付け

優先順位付けは、各ノードに一連の優先度関数を実行することによって行われます。この関数は 0 -10までのスコアをノードに割り当て、0 は不適切であることを示し、10 は Pod のホストに適していることを示します。スケジューラー設定は、それぞれの優先度関数について単純な重み (正の数値) を取ることができます。各優先度関数で指定されるノードのスコアは重み (ほとんどの優先度のデフォルトの重みは 1) で乗算され、すべての優先度で指定されるそれぞれのノードのスコアを追加して組み合わされます。この重み属性は、一部の優先度により重きを置くようにするなどのために管理者によって使用されます。

16.2.3.2. 最適ノードの選択最適ノードの選択

ノードの並び替えはそれらのスコアに基づいて行われ、最高のスコアを持つノードが Post をホストするように選択されます。複数のノードに同じ高スコアが付けられている場合、それらのいずれかがランダムに選択されます。

16.2.4. スケジューラーポリシー

述語と優先度の選択によって、スケジューラーのポリシーが定義されます。

スケジューラー設定ファイルは、スケジューラーが反映する述語と優先度を指定する JSON ファイルです。

スケジューラーポリシーファイルがない場合、デフォルトの設定ファイル/etc/origin/master/scheduler.json が適用されます。

重要重要

スケジューラー設定ファイルで定義される述語および優先度は、デフォルトのスケジューラーポリシーを完全に上書きします。デフォルトの述語および優先度のいずれかが必要な場合、スケジューラー設定ファイルにその関数を明示的に指定する必要があります。

デフォルトのスケジューラー設定ファイルデフォルトのスケジューラー設定ファイル

{ "apiVersion": "v1", "kind": "Policy", "predicates": [ { "name": "NoVolumeZoneConflict" }, {


154

"name": "MaxEBSVolumeCount" }, { "name": "MaxGCEPDVolumeCount" }, { "name": "MaxAzureDiskVolumeCount" }, { "name": "MatchInterPodAffinity" }, { "name": "NoDiskConflict" }, { "name": "GeneralPredicates" }, { "name": "PodToleratesNodeTaints" }, { "argument": { "serviceAffinity": { "labels": [ "region" ] } }, "name": "Region"

} ], "priorities": [ { "name": "SelectorSpreadPriority", "weight": 1 }, { "name": "InterPodAffinityPriority", "weight": 1 }, { "name": "LeastRequestedPriority", "weight": 1 }, { "name": "BalancedResourceAllocation", "weight": 1 }, { "name": "NodePreferAvoidPodsPriority", "weight": 10000 }, { "name": "NodeAffinityPriority", "weight": 1


155

16.2.4.1. スケジューラーポリシーの変更スケジューラーポリシーの変更

デフォルトで、スケジューラーポリシーはマスター設定ファイルの kubernetesMasterConfig.schedulerConfigFile フィールドで上書きされない限り、/etc/origin/master/scheduler.json というマスターのファイルに定義されます。

変更されたスケジューラー設定ファイルのサンプル変更されたスケジューラー設定ファイルのサンプル

}, { "name": "TaintTolerationPriority", "weight": 1 }, { "argument": { "serviceAntiAffinity": { "label": "zone" } }, "name": "Zone", "weight": 2 } ]}

kind: "Policy"version: "v1""predicates": [ { "name": "PodFitsResources" }, { "name": "NoDiskConflict" }, { "name": "MatchNodeSelector" }, { "name": "HostName" }, { "argument": { "serviceAffinity": { "labels": [ "region" ] } }, "name": "Region" } ], "priorities": [ { "name": "LeastRequestedPriority", "weight": 1


156

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#master-configuration-files

スケジューラーポリシーを変更するには、以下を実行します。

1. 必要なデフォルトの述語および優先度を設定するためにスケジューラー設定ファイルを編集します。カスタム設定を作成したり、サンプルのポリシー設定のいずれかを使用または変更したりすることができます。

2. 必要な設定可能な述語と設定可能な優先度を追加します。

3. 変更を有効にするために OpenShift Container Platform を再起動します。


16.2.5. 利用可能な述語

述語は、不適切なノードをフィルターに掛けるルールです。

OpenShift Container Platform には、デフォルトでいくつかの述語が提供されています。これらの述語の一部は、特定のパラメーターを指定してカスタマイズできます。複数の述語を組み合わせてノードの追加フィルターを指定できます。

16.2.5.1. 静的な述語静的な述語

これらの述語はユーザーから設定パラメーターまたは入力を取りません。これらはそれぞれの正確な名前を使用してスケジューラー設定に指定されます。

16.2.5.1.1. デフォルトの述語

デフォルトのスケジューラーポリシーには以下の述語が含まれます。

NoVolumeZoneConflict は Pod が要求するボリュームがゾーンで利用可能であることを確認します。

{"name" : "NoVolumeZoneConflict"}

MaxEBSVolumeCount は、AWS インスタンスに割り当てることのできるボリュームの最大数を確認し

}, { "name": "BalancedResourceAllocation", "weight": 1 }, { "name": "ServiceSpreadingPriority", "weight": 1 }, { "argument": { "serviceAntiAffinity": { "label": "zone" } }, "name": "Zone", "weight": 2 } ]


157

MaxEBSVolumeCount は、AWS インスタンスに割り当てることのできるボリュームの最大数を確認します。

{"name" : "MaxEBSVolumeCount"}

MaxGCEPDVolumeCount は、Google Compute Engine (GCE) 永続ディスク (PD) の最大数を確認します。

{"name" : "MaxGCEPDVolumeCount"}

MatchInterPodAffinity は、Pod のアフィニティー/非アフィニティールールが Pod を許可するかどうかを確認します。

{"name" : "MatchInterPodAffinity"}

NoDiskConflict は Pod が要求するボリュームが利用可能であるかどうかを確認します。

{"name" : "NoDiskConflict"}

PodToleratesNodeTaints は Pod がノードテイントを許容できるかどうかを確認します。

{"name" : "PodToleratesNodeTaints"}

16.2.5.1.2. 他の静的な述語

OpenShift Container Platform は以下の述語もサポートしています。

CheckVolumeBinding は、バインドされている PVC とバインドされていない PVC の両方の場合にPod が要求するボリュームに基づいて適しているかどうかを評価します* バインドされている PVC については、述語は対応する PV のノードアフィニティーが指定ノードによって満たされていることを確認します。* バインドされていない PVC については、述語は PVC 要件を満たす PV を検索し、PV のノードアフィニティーが指定ノードによって満たされていることを確認します。

述語は、すべてのバインドされる PVC にノードと互換性のある PV がある場合や、すべてのバインドされていない PVC が利用可能なノードと互換性のある PV に一致する場合に true を返します。

{"name" : "CheckVolumeBinding"}

CheckVolumeBinding 述語は、デフォルト以外のスケジューラーで有効にする必要があります。

CheckNodeCondition は Pod をノードでスケジュールできるかどうかを確認し、out of disk (ディスク不足)、network unavailable (ネットワークが使用不可)、または not ready (準備できていない) 状態を報告します。

{"name" : "CheckNodeCondition"}

PodToleratesNodeNoExecuteTaints は、Pod がノードの NoExecute テイントを容認できるかどうかを確認します。

{"name" : "PodToleratesNodeNoExecuteTaints"}

CheckNodeLabelPresence は、すべての指定されたラベルがノードに存在するかどうかを確認します(その値が何であるかを問わない)。


158

{"name" : "CheckNodeLabelPresence"}

checkServiceAffinity は、ServiceAffinity ラベルがノードでスケジュールされる Pod について同種のものであることを確認します。

{"name" : "checkServiceAffinity"}

MaxAzureDiskVolumeCount は Azure ディスクボリュームの最大数を確認します。

{"name" : "MaxAzureDiskVolumeCount"}

16.2.5.2. 汎用的な述語汎用的な述語

以下の汎用的な述語は、非クリティカル述語とクリティカル述語が渡されるかどうかを確認します。非クリティカル述語は、非 Critical Pod のみが渡す必要のある述語であり、クリティカル述語はすべてのPod が渡す必要のある述語です。

デフォルトのスケジューラーポリシーにはこの汎用的な述語が含まれます。

汎用的な非クリティカル述語PodFitsResources は、リソースの可用性 (CPU、メモリー、GPU など) に基づいて適切な候補を判別します。ノードはそれらのリソース容量を宣言し、Pod は要求するリソースを指定できます。使用されるリソースではなく、要求されるリソースに基づいて適切な候補が判別されます。

{"name" : "PodFitsResources"}

汎用的なクリティカル述語PodFitsHostPorts は、ノードに要求される Pod ポートの空きポートがある (ポートの競合がない) かどうかを判別します。

{"name" : "PodFitsHostPorts"}

HostName は、ホストパラメーターの有無と文字列のホスト名との一致に基づいて適切なノードを判別します。

{"name" : "HostName"}

MatchNodeSelector は、Pod で定義されるノードセレクター (nodeSelector)のクエリーに基づいて適したノードを判別します。

{"name" : "MatchNodeSelector"}

16.2.5.3. 設定可能な述語設定可能な述語

これらの述語はスケジューラー設定 /etc/origin/master/scheduler.json (デフォルト) に設定し、述語の機能に影響を与えるラベルを追加することができます。

これらは設定可能であるため、ユーザー定義の名前が異なる限り、同じタイプ (ただし設定パラメーターは異なる) の複数の述語を組み合わせることができます。

これらの優先度の使用方法についての情報は、「スケジューラーポリシーの変更」を参照してください。


159

1

2

ServiceAffinity は、Pod で実行されるサービスに基づいて Pod をノードに配置します。同じノードまたは併置されているノードに同じサービスの複数の Pod を配置すると、効率が向上する可能性があります。

この述語はノードセレクターの特定ラベルを持つ Pod を同じラベルを持つノードに配置しようとします。

Pod がノードセレクターでラベルを指定していない場合、最初の Pod は可用性に基づいて任意のノードに配置され、該当サービスの後続のすべての Pod はそのノードと同じラベルの値を持つノードにスケジュールされます。

述語の名前を指定します。

一致するラベルを指定します。

例:

たとえば、ノードセレクター rack を持つサービスの最初の Pod がラベル region=rack を持つノードにスケジュールされている場合、同じサービスに属するその他すべての後続の Pod は同じ region=rackラベルを持つノードにスケジュールされます。詳細は、「Pod 配置の制御」を参照してください。

複数レベルのラベルもサポートされています。ユーザーは同じリージョン内および (リージョン下の) 同じゾーン内のノードでスケジュールされるようサービスのすべての Pod を指定することもできます。

labelsPresence パラメーターは特定のノードに特定のラベルがあるかどうかをチェックします。ラベルは、LabelPreference の優先順位が使用するノードグループを作成します。ラベルでのマッチングは、ノードにラベルで定義されている物理的な場所またはステータスがある場合などに役立ちます。

"predicates":[ { "name":"<name>", 1 "argument":{ "serviceAffinity":{ "labels":[ "<label>" 2 ] } } } ],

"name":"ZoneAffinity", "argument":{ "serviceAffinity":{ "labels":[ "rack" ] } }

"predicates":[ { "name":"<name>", 1 "argument":{


160

1

2

3

述語の名前を指定します。


ラベルが必要であるかを、true または false のいずれかで指定します。

presence:false の場合、要求されるラベルのいずれかがノードラベルにある場合、Pod をスケジュールすることはできません。ラベルが存在しない場合は Pod をスケジュールできます。

presence:true の場合、要求されるラベルのすべてがノードラベルにある場合、Pod をスケジュールできます。ラベルのすべてが存在しない場合、Pod はスケジュールされません。

例:

16.2.6. 利用可能な優先度

優先度は、設定に応じて残りのノードにランクを付けるルールです。

優先度のカスタムセットは、スケジューラーを設定するために指定できます。OpenShift ContainerPlatform ではデフォルトでいくつかの優先度があります。他の優先度は、特定のパラメーターを指定してカスタマイズできます。優先順位に影響を与えるために、複数の優先度を組み合わせ、異なる重みをそれぞれのノードに指定することができます。

16.2.6.1. 静的優先度静的優先度

静的優先度は、重みを除き、ユーザーからいずれの設定パラメーターも取りません。重みは指定する必要があり、0 または負の値にすることはできません。

これらはスケジューラー設定 /etc/origin/master/scheduler.json (デフォルト) に指定されます。

16.2.6.1.1. デフォルトの優先度

デフォルトのスケジューラーポリシーには、以下の優先度が含まれています。それぞれの優先度関数

"labelsPresence":{ "labels":[ "<label>" 2 ], "presence": true 3 } } } ],

"name":"RackPreferred", "argument":{ "labelsPresence":{ "labels":[ "rack", "region" ], "presence": true } }


161

デフォルトのスケジューラーポリシーには、以下の優先度が含まれています。それぞれの優先度関数は、重み 10000 を持つ NodePreferAvoidPodsPriority 以外は重み 1 を持ちます。

SelectorSpreadPriority は、Pod に一致するサービス、レプリケーションコントローラー (RC)、レプリケーションセット (RS)、およびステートフルなセットを検索し、次にそれらのセレクターに一致する既存の Pod を検索します。スケジューラーは、一致する既存 Pod が少ないノードを優先し、Pod のスケジュール時にそれらのセレクターに一致する Pod 数の最も少ないノードで Pod をスケジュールします。

{"name" : "SelectorSpreadPriority", "weight" : 1}

InterPodAffinityPriority は、ノードの対応する PodAffinityTerm が満たされている場合に weightedPodAffinityTerm 要素を使った繰り返し処理や重みの合計への追加によって合計を計算します。合計値の最も高いノードが最も優先されます。

{"name" : "InterPodAffinityPriority", "weight" : 1}

LeastRequestedPriority は要求されたリソースの少ないノードを優先します。これは、ノードでスケジュールされる Pod によって要求されるメモリーおよび CPU のパーセンテージを計算し、利用可能な/残りの容量の値の最も高いノードを優先します。

{"name" : "LeastRequestedPriority", "weight" : 1}

BalancedResourceAllocation は、均衡が図られたリソース使用率に基づいてノードを優先します。これは、容量の一部として消費済み CPU とメモリー間の差異を計算し、2 つのメトリクスがどの程度相互に近似しているかに基づいてノードの優先度を決定します。これは常に LeastRequestedPriority と併用する必要があります。

{"name" : "BalancedResourceAllocation", "weight" : 1}

NodePreferAvoidPodsPriority は、レプリケーションコントローラー以外のコントローラーによって所有される Pod を無視します。

{"name" : "NodePreferAvoidPodsPriority", "weight" : 10000}

NodeAffinityPriority は、ノードアフィニティーのスケジューリング設定に応じてノードの優先順位を決定します。

{"name" : "NodeAffinityPriority", "weight" : 1}

TaintTolerationPriority は、Pod についての容認不可能なテイント数の少ないノードを優先します。容認不可能なテイントとはキー PreferNoSchedule のあるテイントのことです。

{"name" : "TaintTolerationPriority", "weight" : 1}

16.2.6.1.2. 他の静的優先度

OpenShift Container Platform は以下の優先度もサポートしています。

EqualPriority は、優先度の設定が指定されていない場合に、すべてのノードに等しい重み 1 を指定します。この優先順位はテスト環境にのみ使用することを推奨します。

{"name" : "EqualPriority", "weight" : 1}


162

1

2

3

MostRequestedPriority は、要求されたリソースの最も多いノードを優先します。これは、ノードスケジュールされる Pod で要求されるメモリーおよび CPU のパーセンテージを計算し、容量に対して要求される部分の平均の最大値に基づいて優先度を決定します。

{"name" : "MostRequestedPriority", "weight" : 1}

ImageLocalityPriority は、Pod コンテナーのイメージをすでに要求しているノードを優先します。

{"name" : "ImageLocalityPriority", "weight" : 1}

ServiceSpreadingPriority は、同じマシンに置かれる同じサービスに属する Pod 数を最小限にすることにより Pod を分散します。

{"name" : "ServiceSpreadingPriority", "weight" : 1}

16.2.6.2. 設定可能な優先度設定可能な優先度

これらの優先度は、デフォルトでスケジューラー設定 /etc/origin/master/scheduler.json で設定し、これらの優先度に影響を与えるラベルを追加できます。

優先度関数のタイプは、それらが取る引数によって識別されます。これらは設定可能なため、ユーザー定義の名前が異なる場合に、同じタイプの (ただし設定パラメーターは異なる) 設定可能な複数の優先度を組み合わせることができます。

これらの優先度の使用方法についての情報は、「スケジューラーポリシーの変更」を参照してください。

ServiceAntiAffinity はラベルを取り、ラベルの値に基づいてノードのグループ全体に同じサービスに属する Pod を適正に分散します。これは、指定されたラベルの同じ値を持つすべてのノードに同じスコアを付与します。また Pod が最も集中していないグループ内のノードにより高いスコアを付与します。

優先度の名前を指定します。

重みを指定します。ゼロ以外の正の値を指定します。


"priorities":[ { "name":"<name>", 1 "weight" : 1 2 "argument":{ "serviceAntiAffinity":{ "label":[ "<label>" 3 ] } } }]


163

1

2

3

1

2

3

4

例:




注記注記

カスタムラベルに基づいて ServiceAntiAffinity を使用しても Pod を予想通りに展開できない場合があります。この Red Hat ソリューションを参照してください。

*labelPreference パラメーターは指定されたラベルに基づいて優先順位を指定します。ラベルがノードにある場合、そのノードに優先度が指定されます。ラベルが指定されていない場合は、優先度はラベルを持たないノードに指定されます。




ラベルが必要であるかを、true または false のいずれかで指定します。

16.2.7. 使用例

OpenShift Container Platform 内でのスケジューリングの重要な使用例として、柔軟なアフィニティーと非アフィニティーポリシーのサポートを挙げることができます。

"name":"RackSpread", 1 "weight" : 1 2 "argument":{ "serviceAntiAffinity":{ "label": "rack" 3 } }

"priorities":[ { "name":"<name>", 1 "weight" : 1, 2 "argument":{ "labelPreference":{ "label": "<label>", 3 "presence": true 4 } } }]


164


16.2.7.1. インフラストラクチャーのトポロジーレベルインフラストラクチャーのトポロジーレベル

管理者は、ノードのラベル (例: region=r1、zone=z1、rack=s1) を指定してインフラストラクチャーの複数のトポロジーレベルを定義することができます。

これらのラベル名には特別な意味はなく、管理者はそれらのインフラストラクチャーラベルに任意の名前 (例: 都市/建物/部屋) を付けることができます。さらに、管理者はインフラストラクチャートポロジーに任意の数のレベルを定義できます。通常は、(regions → zones → racks などの) 3 つのレベルが適切なサイズです。管理者はこれらのレベルのそれぞれにアフィニティーと非アフィニティールールを任意の組み合わせで指定することができます。

16.2.7.2. アフィニティーアフィニティー

管理者は、任意のトポロジーレベルまたは複数のレベルでもアフィニティーを指定できるようにスケジューラーを設定することができます。特定レベルのアフィニティーは、同じサービスに属するすべての Pod が同じレベルに属するノードにスケジュールされることを示します。これは、管理者がピアPod が地理的に離れ過ぎないようにすることでアプリケーションの待機時間の要件に対応します。同じアフィニティーグループ内で Pod をホストするために利用できるノードがない場合、Pod はスケジュールされません。

Pod がスケジュールされる場所に対する制御を強化する必要がある場合は、「ノードアフィニティーの使用」および「Pod のアフィニティーおよび非アフィニティーの使用」を参照してください。これらの詳細スケジューリング機能により、管理者は Pod をスケジュールできるノードを指定し、他の Pod に関連してスケジューリングを強制的に実行したり、拒否したりできます。

16.2.7.3. 非アフィニティー非アフィニティー

管理者は、任意のトポロジーレベルまたは複数のレベルでも非アフィニティーを設定できるようスケジューラーを設定することができます。特定レベルの非アフィニティー (または「分散」)は、同じサービスに属するすべての Pod が該当レベルに属するノード全体に分散されることを示します。これにより、アプリケーションが高可用性の目的で適正に分散されます。スケジューラーは、可能な限り均等になるようにすべての適用可能なノード全体にサービス Pod を配置しようとします。

Pod がスケジュールされる場所に対する制御を強化する必要がある場合は、「ノードアフィニティーの使用」および「Pod のアフィニティーおよび非アフィニティーの使用」を参照してください。これらの詳細スケジューリング機能により、管理者は Pod をスケジュールできるノードを指定し、他の Pod に関連してスケジューリングを強制的に実行したり、拒否したりできます。

16.2.8. ポリシー設定のサンプル

以下の設定は、スケジューラーポリシーファイルを使って指定される場合のデフォルトのスケジューラー設定を示しています。

kind: "Policy"version: "v1"predicates:... - name: "RegionZoneAffinity" 1 argument: serviceAffinity: 2 labels: 3 - "region" - "zone"priorities:...


165

1

2

3

4

5

6

- name: "RackSpread" 4 weight: 1 argument: serviceAntiAffinity: 5 label: "rack" 6

述語の名前です。

述語のタイプです。

述語のラベルです。

優先度の名前です。

優先度のタイプです。

優先度のラベルです。

以下の設定例のいずれの場合も、述語と優先度関数の一覧は、指定された使用例に関連するもののみを含むように切り捨てられます。実際には、完全な/分かりやすいスケジューラーポリシーには、上記のデフォルトの述語および優先度のほとんど (すべてではなくても) が含まれるはずです。

以下の例は、region (affinity) → zone (affinity) → rack (anti-affinity) の 3 つのトポロジーレベルを定義します。

以下の例は、city (affinity) → building (anti-affinity) → room (anti-affinity) の 3 つのトポロジーレベルを定義します。

kind: "Policy"version: "v1"predicates:... - name: "RegionZoneAffinity" argument: serviceAffinity: labels: - "region" - "zone"priorities:... - name: "RackSpread" weight: 1 argument: serviceAntiAffinity: label: "rack"

kind: "Policy"version: "v1"predicates:... - name: "CityAffinity" argument: serviceAffinity: labels: - "city"


166

以下の例では、「region」ラベルが定義されたノードのみを使用し、「zone」ラベルが定義されたノードを優先するポリシーを定義します。

以下の例では、静的および設定可能な述語および優先度を組み合わせています。

priorities:... - name: "BuildingSpread" weight: 1 argument: serviceAntiAffinity: label: "building" - name: "RoomSpread" weight: 1 argument: serviceAntiAffinity: label: "room"

kind: "Policy"version: "v1"predicates:... - name: "RequireRegion" argument: labelsPresence: labels: - "region" presence: truepriorities:... - name: "ZonePreferred" weight: 1 argument: labelPreference: label: "zone" presence: true

kind: "Policy"version: "v1"predicates:... - name: "RegionAffinity" argument: serviceAffinity: labels: - "region" - name: "RequireRegion" argument: labelsPresence: labels: - "region" presence: true - name: "BuildingNodesAvoid" argument: labelsPresence:


167

16.3. 再スケジュール (DESCHEDULING)

16.3.1. 概要

再スケジュール (Descheduling) には、Pod がより適切なノードに再スケジュールされるように特定のポリシーに基づいて Pod をエビクトすることが関係しています。

クラスターには、すでに実行されている Pod をスケジュール解除し、再スケジュールできることによる利点があり、スケジュール解除および再スケジュールは各種の理由によって実行されます。

ノードの使用率が低くなっているか、または高くなっている。

テイントまたはラベルなどの、Pod およびノードアフィニティーの各種要件が変更され、当初のスケジューリングの意思決定が特定のノードに適さなくなっている。

ノードの障害により、Pod を移動する必要がある。

新規ノードがクラスターに追加されている。

Descheduler はエビクトされた Pod の置き換えをスケジュールしません。スケジューラーは、エビクトされた Pod に対してこのタスクを自動的に実行します。

DNS など、クラスターの完全な機能に欠かせないコアコンポーネントであるものの、マスターではなく通常のクラスターノードで実行されるコアコンポーネントが多数あることに留意する必要があります。クラスターはコンポーネントがエビクトされると正常な機能を停止する可能性があります。Descheduler がこれらの Pod を削除することを防ぐには、scheduler.alpha.kubernetes.io/critical-podアノテーションを Pod 仕様に追加して、Pod を Critical Pod として設定します。

注記注記

Descheduler ジョブは Critical Pod としてみなされ、これは Descheduler Pod がDescheduler のエビクトの対象になることを防ぎます。

Descheduler ジョブおよび Descheduler Pod は、デフォルトで作成される kube-system プロジェクト

labels: - "building" presence: false - name: "PodFitsPorts" - name: "MatchNodeSelector"priorities:... - name: "ZoneSpread" weight: 2 argument: serviceAntiAffinity: label: "zone" - name: "ZonePreferred" weight: 1 argument: labelPreference: label: "zone" presence: true - name: "ServiceSpreadingPriority" weight: 1


168

Descheduler ジョブおよび Descheduler Pod は、デフォルトで作成される kube-system プロジェクトに作成されます。

重要重要

descheduler はテクノロジープレビュー機能です。テクノロジープレビュー機能は RedHat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

Descheduler は以下のタイプの Pod をエビクトしません。

Critical Pod (scheduler.alpha.kubernetes.io/critical-pod アノテーションを持つ)。

レプリカセット、レプリケーションコントローラー、デプロイメント、またはジョブに関連付けられていない Pod (静的およびミラー Pod またはスタンドアロンモードの Pod) (これらのPod 再作成されないため)。

DaemonSet に関連付けられた Pod。

ローカルストレージを持つ Pod。

Pod の Disruption Budget (PDB) が適用される Pod は、スケジュール解除が PDB に違反する場合にエビクトされません。Pod は、エビクションポリシーを使用してエビクトできます。

注記注記

Best Effort Pod は、Burstable および Guaranteed Pod の前にエビクトされます。

以下のセクションでは、Descheduler を設定し、実行するプロセスについて説明します。

1. ロールを作成します。

2. ポリシーファイルにスケジュール解除動作を定義します。

3. ポリシーファイルを参照するための参照マップを作成します。

4. Descheduler ジョブ設定を作成します。

5. Descheduler ジョブを実行します。

16.3.2. クラスターロールの作成

Descheduler が Pod で機能するために必要なパーミッションを設定するには、以下を実行します。

1. 以下のルールでクラスターロールを作成します。

kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1beta1metadata: name: descheduler-cluster-role


169

https://access.redhat.com/support/offerings/techpreview/

https://kubernetes.io/docs/tasks/administer-cluster/static-pod/

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-daemonsets


1

2

3

ノードの表示を許可するようにロールを設定します

Pod の表示および削除を許可するようにロールを設定します。

ノードがノードにバインドされた Pod をエビクトできるようにします。

2. ジョブを実行するために使用されるサービスアカウントを作成します。

# oc create sa <file-name>.yaml -n kube-system

例:

# oc create sa descheduler-sa.yaml -n kube-system

3. クラスターロールをサービスアカウントにバインドします。

# oc create clusterrolebinding descheduler-cluster-role-binding \ --clusterrole=<cluster-role-name> \ --serviceaccount=kube-system:<service-account-name>

例:

# oc create clusterrolebinding descheduler-cluster-role-binding \ --clusterrole=descheduler-cluster-role \ --serviceaccount=kube-system:descheduler-sa

16.3.3. Descheduler ポリシーの作成

Descheduler は、YAML ポリシーファイルの strategies で定義されるルールに違反するノードから Podを削除するように設定できます。ジョブ仕様にポリシーファイルへのパスを組み込み、特定のスケジュール解除ストラテジーを適用します。

Descheduler ポリシーファイルのサンプルポリシーファイルのサンプル

rules:- apiGroups: [""] resources: ["nodes"] verbs: ["get", "watch", "list"] 1- apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list", "delete"] 2- apiGroups: [""] resources: ["pods/eviction"] 3 verbs: ["create"]

apiVersion: "descheduler/v1alpha1"kind: "DeschedulerPolicy"strategies: "RemoveDuplicates": enabled: false "LowNodeUtilization": enabled: true


170

1

Descheduler で使用できるデフォルトストラテジーとして、 3 つのストラテジーがあります。

重複 Pod の削除 (RemoveDuplicates)

Pod の使用率の低いノードへの移動 (LowNodeUtilization)

非アフィニティールールに違反する Pod の削除 (RemovePodsViolatingInterPodAntiAffinity)

ストラテジーに関連付けられたパラメーターを必要に応じて設定し、無効にすることができます。

16.3.3.1. 重複重複 Pod の削除の削除

RemoveDuplicates ストラテジーでは、1 つの Pod のみが同じノードで実行されているレプリカセット、レプリケーションコントローラー、デプロイメント設定、またはジョブに関連付けられます。これらのオブジェクトに関連付けられている他の Pod がある場合、重複 Pod はエビクトされます。重複Pod をエビクトすると、Pod をクラスター内により効果的に分散できます。

たとえば、ノードが失敗し、ノード上の Pod が別のノードに移行した場合に、複数の Pod が同じノードで実行されているレプリカセットまたはレプリケーションコントローラーに関連付けられると、重複Pod が発生する可能性があります。失敗したノードが再び準備可能になると、それらの重複 Pod をエビクトするためにこのストラテジーが使用される可能性があります。

このストラテジーに関連付けられるパラメーターはありません。

このポリシーを使用するには、この値を enabled: true に設定します。このポリシーを無効にするには、false に設定します。

16.3.3.2. ノードの低使用率ポリシーノードの低使用率ポリシー (Low Node Utilization Policy) の作成の作成

LowNodeUtilization ストラテジーは、使用率の低いノードを検出し、他のノードから Pod をエビクトして、エビクトされた Pod がそれらの使用率の低いノードにスケジュールされるようにします。

ノードの使用率は、CPU、メモリーまたは Pod 数の設定可能なしきい値 thresholds (パーセンテージベース) で決定されます。ノードの使用率がこれらのしきい値のすべてを下回る場合、ノードの使用率

params: nodeResourceUtilizationThresholds: thresholds: "cpu" : 20 "memory": 20 "pods": 20 targetThresholds: "cpu" : 50 "memory": 50 "pods": 50 numberOfNodes: 3 "RemovePodsViolatingInterPodAntiAffinity": enabled: true

apiVersion: "descheduler/v1alpha1"kind: "DeschedulerPolicy"strategies: "RemoveDuplicates": enabled: false 1


171

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-kubernetes-deployments-support

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#replication-controllers

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#deployments-and-deployment-configurations

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#jobs

1

2

3

は低いとみなされ、Descheduler は Pod を他のノードからエビクトする可能性があります。Pod の要求リソース要件は、ノードのリソース使用率を計算する際に考慮されます。

高いしきい値の targetThresholds は、使用率が適性なノードを判別するために使用されます。thresholds と targetThresholds 間にあるノードの使用率は適性であるとみなされ、エビクションの対象にはなりません。しきい値 targetThresholds は、CPU、メモリーおよび Pod 数について設定できます (パーセンテージベース)。

これらのしきい値はクラスター要件に合わせて調整できます。

numberOfNodes パラメーターは、使用率の低いノードの数が設定された値を上回る場合にのみストラテジーをアクティブにするために設定できます。いくつかのノードの使用率が低くなることが許容される場合にこのパラメーターを設定します。デフォルトで、numberOfNodes はゼロに設定されます。

ローエンドのしきい値を設定します。ノードがこれら 3 つの値のいずれよりも下回る場合、Descheduler はこのノードの使用率を低いとみなします。

ハイエンドのしきい値を設定します。ノードがこれらの値を下回り、threshold 値を上回る場合、Descheduler はノードの使用率が適正であるとみなします。

Descheduler が Pod を使用率の低いノードからエビクトする前に、使用率が低くなるノードの数を設定します。

16.3.3.3. Pod 間の非アフィニティー間の非アフィニティー (Inter-Pod Anti-Affinity) に違反するに違反する Pod の削除の削除

RemovePodsViolatingInterPodAntiAffinity ストラテジーは、Pod 間の非アフィニティー (inter-podanti-affinity) に違反する Pod がノードから削除されるようにします。

たとえば、 Node1 には podA、podB、および podC があるとします。podB および podC には、podA と同じノードでそれらが実行されることを禁止する非アフィニティールールがあります。podA はノードからエビクトされ、podB および podC がそのノードで実行されるようになります。この状況は、podB および podC がノード上で実行されている際に非アフィニティールールが適用される場合に生じます。

apiVersion: "descheduler/v1alpha1"kind: "DeschedulerPolicy"strategies: "LowNodeUtilization": enabled: true params: nodeResourceUtilizationThresholds: thresholds: 1 "cpu" : 20 "memory": 20 "pods": 20 targetThresholds: 2 "cpu" : 50 "memory": 50 "pods": 50 numberOfNodes: 3 3

apiVersion: "descheduler/v1alpha1"kind: "DeschedulerPolicy"strategies:


172

1

1

このポリシーを使用するには、この値を enabled: true に設定します。このポリシーを無効にするには、false に設定します。

16.3.4. 設定マップでの Descheduler ポリシーの設定

kube-system プロジェクトで Descheduler ポリシーファイルの設定マップを作成し、これがDescheduler ジョブで参照されるようにします。

# oc create configmap descheduler-policy-configmap \ -n kube-system --from-file=<path-to-policy-dir/policy.yaml> 1

作成したポリシーファイルのパスです。

16.3.5. ジョブ仕様の作成

Descheduler のジョブ設定を作成します。

"RemovePodsViolatingInterPodAntiAffinity": 1 enabled: true

apiVersion: batch/v1kind: Jobmetadata: name: descheduler-job namespace: kube-systemspec: parallelism: 1 completions: 1 template: metadata: name: descheduler-pod 1 annotations: scheduler.alpha.kubernetes.io/critical-pod: "true" 2 spec: containers: - name: descheduler image: descheduler volumeMounts: 3 - mountPath: /policy-dir name: policy-volume command: - "/bin/sh" - "-ec" - | /bin/descheduler --policy-config-file /policy-dir/policy.yaml 4 restartPolicy: "Never" serviceAccountName: descheduler-sa 5 volumes: - name: policy-volume configMap: name: descheduler-policy-configmap


173


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#creating-a-job

1

2

3

4

5

ジョブの名前を指定します。

スケジュール解除が実行されないように Pod を設定します。

ジョブがマウントされるコンテナーのボリューム名およびマウントパスです。

作成したポリシーファイルが保存されるコンテナー内のパスです。

作成したサービスアカウントの名前を指定します。

ポリシーファイルは、設定マップからボリュームとしてマウントされます。

16.3.6. Descheduler の実行

Descheduler を Pod のジョブとして実行するには、以下を実行します。

# oc create -f <file-name>.yaml

例:

# oc create -f descheduler-job.yaml

16.4. カスタムスケジューリング

16.4.1. 概要

デフォルトのスケジューラーと共に複数のカスタムスケジューラーを実行し、各 Pod に使用できるスケジューラーを設定できます。

特定のスケジューラーを使用して指定された Pod をスケジュールするには、Pod 仕様にスケジューラーの名前を指定します。

注記注記

スケジューラーバイナリーの作成方法については、本書では扱われません。Kubernetesドキュメントの「Configure Multiple Schedulers」などを参照してください。

16.4.2. スケジューラーをパッケージ化します。

クラスターにカスタムスケジューラーに組み込む一般的なプロセスでは、イメージを作成し、そのイメージをデプロイメントに含める必要があります。

1. スケジューラーバイナリーをコンテナーイメージにパッケージ化します。

2. スケジューラーバイナリーが含まれるコンテナーイメージを作成します。例:

FROM <source-image>ADD <path-to-binary> /usr/local/bin/kube-scheduler

3. ファイルを Dockerfile として保存し、イメージをビルドし、これをレジストリーにプッシュします。


174

https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/creating_images/#creating-images-guidelines

1

例:

docker build -t <dest_env_registry_ip>:<port>/<namespace>/<image name>:<tag>docker push <dest_env_registry_ip>:<port>/<namespace>/<image name>:<tag>

4. OpenShift Container Platform で、カスタムスケジューラーのデプロイメントを作成します。

カスタムスケジューラー用に作成したコンテナーイメージを指定します。

16.4.3. カスタムスケジューラーを使用した Pod のデプロイ

カスタムスケジューラーがクラスターにデプロイされた後に、Pod がデフォルトスケジューラーではな

apiVersion: v1kind: ServiceAccountmetadata: name: custom-scheduler namespace: kube-system---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: custom-schedulersubjects:- kind: ServiceAccount name: custom-scheduler namespace: kube-systemroleRef: kind: ClusterRole name: system:kube-scheduler apiGroup: rbac.authorization.k8s.io---apiVersion: apps/v1kind: Deploymentmetadata: name: custom-scheduler namespace: kube-system labels: app: custom-schedulerspec: replicas: 1 selector: matchLabels: app: custom-scheduler template: metadata: labels: app: custom-scheduler spec: serviceAccount: custom-scheduler containers: - name: custom-scheduler image: "<namespace>/<image name>:<tag>" 1 imagePullPolicy: Always


175

1

カスタムスケジューラーがクラスターにデプロイされた後に、Pod がデフォルトスケジューラーではなく、そのスケジューラーを使用するように設定できます。

1. Pod 設定を作成するか、または編集し、schedulerName パラメーターでスケジューラーの名前を指定します。名前は一意である必要があります。

スケジューラーを含むスケジューラーを含む Pod 仕様のサンプル仕様のサンプル

使用するスケジューラーの名前です。スケジューラー名が指定されていない場合、Pod はデフォルトのスケジューラーを使用して自動的にスケジュールされます。

2. 以下のコマンドを実行して Pod を作成します。

$ oc create -f <file-name>.yaml

例:

$ oc create -f custom-scheduler-example.yaml

3. 以下のコマンドを実行し、スケジューラーが使用されていることを確認します。

$ oc get pod <file-name>

例:

$ oc get pod custom-scheduler-example

NAME READY STATUS RESTARTS AGEcustom-scheduler-example 1/1 Running 0 4m

4. 以下のコマンドを実行し、カスタムスケジューラーが Pod をスケジュールしていることを確認します。

$ oc describe pod <pod-name>

例:

$ oc describe pod custom-scheduler-example

以下の切り捨てられた出力に示されるように、スケジューラーの名前が一覧表示されます。

apiVersion: v1kind: Podmetadata: name: custom-scheduler-example labels: name: custom-scheduler-examplespec: schedulerName: custom-scheduler 1 containers: - name: pod-with-second-annotation-container image: docker.io/ocpqe/hello-pod


176

...

Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 custom-scheduler Normal Scheduled Successfully assigned custom-scheduler to <$node1>

...

16.5. POD 配置の制御

16.5.1. 概要

クラスター管理者は、特定のロールを持つアプリケーション開発者が Pod のスケジュール時に特定ノードをターゲットとすることを防ぐポリシーを設定できます。

Pod ノード制約の受付コントローラーは、Pod がラベルを使用して指定されたノードホストのみにデプロイされるようにし、特定のロールを持たないユーザーが nodeSelector フィールドを使用して Pod をスケジュールできないようにします。

16.5.2. ノード名の使用による Pod 配置の制約

Pod ノード制約の受付コントローラーを使用し、Pod にラベルを割り当て、これを Pod 設定の nodeName 設定に指定することで、Pod が指定されたノードホストにのみデプロイされるようにします。

1. 必要なラベル (詳細は、「ノードでのラベルの更新」を参照) およびノードセレクターが環境にセットアップされていることを確認します。たとえば、Pod 設定が必要なラベルを示す nodeName 値を持つことを確認します。

apiVersion: v1kind: Podspec: nodeName: <value>

2. マスター設定ファイル (/etc/origin/master/master-config.yaml) を変更して PodNodeConstraints を admissionConfig セクションに追加します。

...admissionConfig: pluginConfig: PodNodeConstraints: configuration: apiversion: v1 kind: PodNodeConstraintsConfig...




177

16.5.3. ノードセレクターの使用による Pod 配置の制約

ノードセレクターを使用して、Pod が特定のラベルを持つノードにのみ配置されるようにすることができます。クラスター管理者は、Pod ノード制約の受付コントローラーを使用して、pods/binding パーミッションのないユーザーがノードセレクターを使用して Pod をスケジュールできないようにするポリシーを設定できます。

マスター設定ファイルの nodeSelectorLabelBlacklist フィールドを使用して、一部のロールが Pod 設定の nodeSelector フィールドで指定できるラベルを制御できます。pods/binding パーミッションロールを持つユーザー、サービスアカウントおよびグループは任意のノードセレクターを指定できます。pods/binding パーミッションがない場合は、nodeSelectorLabelBlacklist に表示されるすべてのラベルに nodeSelector を設定することは禁止されます。

たとえば、OpenShift Container Platform クラスターは、2 つの地域にまたがる 5 つのデータセンターで構成される場合があります。米国の us-east、us-central、および us-west、およびアジア太平洋(APAC) の apac-east および apac-west です。それぞれの地理的地域の各ノードには、region: us-east などのラベルが付けられます。たとえば、region: us-east のようになります。

注記注記

ラベルの割り当ての詳細は、「ノードでのラベルの更新」を参照してください。

クラスター管理者は、アプリケーション開発者が地理的に最も近い場所にあるノードにのみ Pod をデプロイできるインフラストラクチャーを作成できます。ノードセレクターを作成し、米国のデータセンターを superregion: us に、APAC のデータセンターを superregion: apac に分類できます。

データセンターごとのリソースの均等なロードを維持するには、必要な region をマスター設定の nodeSelectorLabelBlacklist セクションに追加できます。その後は、米国の開発者が Pod を作成するたびに、Pod は superregion: us ラベルの付いた地域のいずれかにあるノードにデプロイされます。開発者が Pod に特定の region (地域) をターゲットに設定しようとすると (例: region: us-east)、エラーが出されます。これを Pod にノードセレクターを設定せずに試行すると、ターゲットとした region (地域) にデプロイすることができます。それは superregion: us がプロジェクトレベルのノードセレクターとして設定されており、region: us-east というラベルが付けられたノードには superregion: usというラベルも付けられているためです。

1. 必要なラベル (詳細は、「ノードでのラベルの更新」を参照) およびノードセレクターが環境にセットアップされていることを確認します。たとえば、Pod 設定が必要なラベルを示す nodeSelector 値を持つことを確認します。

apiVersion: v1kind: Podspec: nodeSelector: <key>: <value>...

2. マスター設定ファイル /etc/origin/master/master-config.yaml を変更し、nodeSelectorLabelBlacklist を、Pod の配置を拒否する必要のあるノードホストに割り当てられるラベルと共に admissionConfig セクションに追加します。

...admissionConfig: pluginConfig: PodNodeConstraints: configuration:


178

1

2

3

apiversion: v1 kind: PodNodeConstraintsConfig nodeSelectorLabelBlacklist: - kubernetes.io/hostname - <label>...



16.5.4. プロジェクト対する Pod 配置の制御

Pod ノードセレクターの受付コントローラーを使用して、Pod を特定のプロジェクトに関連付けられたノードに対して強制的に適用したり、Pod がそれらのノードでスケジュールされないようにしたりできます。

Pod ノードセレクターの受付コントローラーは、プロジェクトのラベルと Pod で指定されるノードセレクターを使用して Pod を配置する場所を決定します。新規 Pod は、Pod のノードセレクターがプロジェクトのラベルに一致する場合にのみプロジェクトに関連付けられたノードに配置されます。

Pod の作成後に、ノードセレクターは Pod にマージされ、Pod 仕様に元々含まれていたラベルとノードセレクターの新規ラベルが含まれるようにします。以下の例は、マージの結果について示しています。

Pod ノードセレクターの受付コントローラーにより、特定のプロジェクトで許可されるラベルの一覧を作成することもできます。この一覧は開発者がプロジェクトで使用できるラベルを認識するためのホワイトリストとして機能し、管理者がクラスターでのラベル設定の制御を強化するのに役立ちます。

Pod ノードセレクターの受付コントローラーをアクティブにするには、以下を実行します。

1. 以下の方法のいずれかを使用して Pod ノードセレクターの受付コントローラーとホワイトリストを設定します。

以下をマスター設定ファイル (/etc/origin/master/master-config.yaml) に追加します。

admissionConfig: pluginConfig: PodNodeSelector: configuration: podNodeSelectorPluginConfig: 1 clusterDefaultNodeSelector: "k3=v3" 2 ns1: region=west,env=test,infra=fedora,os=fedora 3

Pod ノードセレクターの受付コントローラープラグインを追加します。

すべてのノードのデフォルトラベルを作成します。

指定されたプロジェクトで許可されるラベルのホワイトリストを作成します。ここで、プロジェクトは ns1 で、ラベルはそれに続く key=value ペアになります。

受付コントローラーの情報を含むファイルを作成します。


179


1

podNodeSelectorPluginConfig: clusterDefaultNodeSelector: "k3=v3" ns1: region=west,env=test,infra=fedora,os=fedora

次に、マスター設定でファイルを参照します。

admissionConfig: pluginConfig: PodNodeSelector: location: <path-to-file>

注記注記

プロジェクトにノードセレクターが指定されていない場合、そのプロジェクトに関連付けられた Pod はデフォルトのノードセレクター(clusterDefaultNodeSelector) を使用してマージされます。



3. scheduler.alpha.kubernetes.io/node-selector アノテーションおよびラベルを含むプロジェクトオブジェクトを作成します。

プロジェクトのラベルセレクターに一致するラベルを作成するためのアノテーションです。ここで、キー/値のラベルは env=test および infra=fedora になります。

注記注記

Pod Node Selector 受付コントローラーを使用している場合、プロジェクトノードセレクターを設定するるために oc adm new-project <project-name> を設定することはできません。oc adm new-project myproject --node-selector='type=user-node,region=<region> コマンドを使用してプロジェクトノードセレクターを設定する場合、OpenShift Container Platform は openshift.io/node-selector アノテーションを設定します。これは NodeEnv 受付プラグインで処理されます。

4. ノードセレクターにラベルを含む Pod 仕様を作成します。以下は例になります。

apiVersion: v1kind: Namespacemetadata name: ns1 annotations: scheduler.alpha.kubernetes.io/node-selector: env=test,infra=fedora 1spec: {},status: {}



180

1 プロジェクトラベルに一致するノードセレクターです。

5. プロジェクトに Pod を作成します。

# oc create -f pod.yaml --namespace=ns1

6. ノードセレクターのラベルが Pod 設定に追加されていることを確認します。

get pod pod1 --namespace=ns1 -o json

nodeSelector": { "env": "test", "infra": "fedora", "os": "fedora"}

ノードセレクターは Pod にマージされ、Pod は適切なプロジェクトでスケジュールされます。

プロジェクト仕様で指定されていないラベルを使って Pod を作成する場合、Pod はノードでスケジュールされません。

たとえば、ここでラベル env: production はにずれのプロジェクト仕様にもありません。

nodeSelector: "env: production" "infra": "fedora", "os": "fedora"

ノードセレクターのアノテーションのないノードがある場合は、Pod はそこにスケジュールされます。

labels: name: hello-pod name: hello-podspec: containers: - image: "docker.io/ocpqe/hello-pod:latest" imagePullPolicy: IfNotPresent name: hello-pod ports: - containerPort: 8080 protocol: TCP resources: {} securityContext: capabilities: {} privileged: false terminationMessagePath: /dev/termination-log dnsPolicy: ClusterFirst restartPolicy: Always nodeSelector: 1 env: test os: fedora serviceAccount: ""status: {}


181

16.6. POD の優先順位とプリエンプション

16.6.1. Pod の優先順位およびプリエンプションの適用

クラスターで Pod の優先順位およびプリエンプションを有効にできます。Pod の優先順位は、他のPod との対比で Pod の重要度を示し、その優先順位に基づいて Pod をキューに入れます。Pod のプリエンプションは、クラスターが優先順位の低い Pod のエビクトまたはプリエンプションを実行することを可能にするため、適切なノードに利用可能な領域がない場合に優先順位のより高い Pod をスケジュールできます。Pod の優先順位は Pod のスケジューリングの順序にも影響を与え、リソース不足の場合のノード上でのエビエクションの順序に影響を与えます。

優先順位およびプリエンプションを使用するには、Pod の相対的な重みを定義する優先順位クラスを作成します。次に Pod 仕様で優先順位クラスを参照し、スケジューリングの重みを適用します。

プリエンプションはスケジューラー設定ファイルの disablePreemption パラメーターで制御されます。これはデフォルトで false に設定されます。

16.6.2. Pod の優先順位について

Pod の優先順位およびプリエンプション機能が有効にされる場合、スケジューラーは優先順位に基づいて保留中の Pod を順序付け、保留中の Pod はスケジューリングのキューで優先順位のより低い他の保留中の Pod よりも前に置かれます。その結果、より優先順位の高い Pod は、スケジューリングの要件を満たす場合に優先順位の低い Pod よりも早くスケジュールされる可能性があります。Pod をスケジュールできない場合、スケジューラーは引き続き他の優先順位の低い Pod をスケジュールします。

16.6.2.1. Pod の優先順位クラスの優先順位クラス

Pod には優先順位クラスを割り当てることができます。これは、名前から優先順位の整数値へのマッピングを定義する namespace を使用していないオブジェクトです。値が高いと優先順位が高くなります。

優先順位およびプリエンプションは、1000000000 (10 億) 以下の 32 ビットの整数値を取ることができます。プリエンプションやエビクションを実行すべきでない Critical Pod 用に 10 億より大きい数を予約します。デフォルトで、OpenShift Container Platform には 2 つの予約された優先順位クラスがあり、これらは重要なシステム Pod で保証されたスケジューリングが適用されるために使用されます。

System-node-critical: この優先順位クラスには 2000001000 の値があり、ノードからエビクトすべきでないすべての Pod に使用されます。この優先順位クラスを持つ Pod の例として、sdn-ovs、sdn などがあります。

System-cluster-critical: この優先順位クラスには 2000000000 (20 億) の値があり、クラスターに重要な Pod に使用されます。この優先順位クラスの Pod は特定の状況でノードからエビクトされる可能性があります。たとえば、system-node-critical 優先順位クラスで設定される Pod が優先される可能性がありますが、この場合でも、この優先順位クラスではスケジューリングが保証されます。この優先順位クラスを持つ可能性のある Pod の例として、fluentd、descheduler などのアドオンコンポーネントなどがあります。

注記注記

既存クラスターをアップグレードする場合、既存 Pod の優先順位はゼロになります。ただし、scheduler.alpha.kubernetes.io/critical-pod アノテーションを持つ既存 Pod は system-cluster-critical クラスに自動的に変換されます。

16.6.2.2. Pod の優先順位名の優先順位名


182

1 つ以上の優先順位クラスを準備した後に、Pod 仕様に優先順位クラス名を指定する Pod を作成できます。優先順位の受付コントローラーは、優先順位クラス名フィールドを使用して優先順位の整数値を設定します。名前付きの優先順位クラスが見つからない場合、Pod は拒否されます。

以下の YAML は、前述の例で作成された優先順位クラスを使用する Pod 設定の例です。優先順位の受付コントローラーは仕様をチェックし、Pod の優先順位を 1000000 に解決します。

16.6.3. Pod プリエンプションについて

開発者が Pod を作成する場合、Pod はキューに入れられます。Pod の優先順位およびプリエンプション機能が有効にされている場合、スケジューラーはキューから Pod を選択し、Pod をノードにスケジュールしようとします。スケジューラーが Pod について指定されたすべての要件を満たす適切なノードに領域を見つけられない場合、プリエンプションロジックが保留中の Pod についてトリガーされます。

スケジューラーがノードで 1 つ以上の Pod のプリエンプションを実行する場合、優先順位の高い Pod仕様の nominatedNodeName フィールドは、nodename フィールドと共にノードの名前に設定されます。スケジューラーは nominatedNodeName フィールドを使用して Pod の予約されたリソースを追跡し、またクラスターのプリエンプションについての情報をユーザーに提供します。

スケジューラーが優先順位の低い Pod のプリエンプションを実行した後に、スケジューラーは Pod の正常な終了期間を許可します。スケジューラーが優先順位の低い Pod の終了を待機する間に別のノードが利用可能になると、スケジューラーはそのノードに優先順位の高い Pod をスケジュールできます。その結果、Pod 仕様の nominatedNodeName フィールドおよび nodeName フィールドが異なる可能性があります。

さらに、スケジューラーがノード上で Pod のプリエンプションを実行し、終了を待機している場合で、保留中の Pod よりも優先順位の高い Pod をスケジュールする必要がある場合、スケジューラーは代わりに優先順位の高い Pod をスケジュールできます。その場合、スケジューラーは保留中の Pod の nominatedNodeName をクリアし、その Pod を他のノードの対象とすることができます。

プリエンプションは、ノードから優先順位の低いすべての Pod を削除する訳ではありません。スケジューラーは、優先順位の低い Pod の一部を削除して保留中の Pod をスケジュールできます。

スケジューラーは、保留中の Pod をノードにスケジュールできる場合にのみ、Pod のプリエンプションを実行するノードを考慮します。

16.6.3.1. Pod プリエンプションおよび他のスケジューラーの設定プリエンプションおよび他のスケジューラーの設定

Pod の優先順位およびプリエンプションを有効にする場合、他のスケジューラー設定を考慮します。

Pod の優先順位および Pod の Disruption Budget (停止状態の予算)

Pod の Disruption Budget (停止状態の予算) は一度に稼働している必要のあるレプリカの最小数またはパーセンテージを指定します。Pod の Disruption Budget (停止状態の予算) を指定する場合、OpenShift Container Platform は、 Best Effort レベルで Pod のプリエンプションを実行する際にそれらを適用します。スケジューラーは、Pod の Disruption Budget (停止状態の予算) に違反しない範囲で Pod のプリエンプションを試行します。該当する Pod が見つからない場合には、Pod のDisruption Budget (停止状態の予算) の要件を無視して優先順位の低い Pod のプリエンプションが実行される可能性があります。

Pod の優先順位およびアフィニティー

Pod のアフィニティーは、新規 Pod が同じラベルを持つ他の Pod と同じノードにスケジュールされることを要求します。

保留中の Pod にノード上の 1 つ以上の優先順位の低い Pod との Pod 間のアフィニティーがある場合、スケジューラーはアフィニティーの要件を違反せずに優先順位の低い Pod のプリエンプションを実行


183

することはできません。この場合、スケジューラーは保留中の Pod をスケジュールするための別のノードを探します。ただし、スケジューラーが適切なノードを見つけることは保証できず、保留中のPod がスケジュールされない可能性があります。

この状態を防ぐには、優先順位が等しい Pod との Pod のアフィニティーの設定を慎重に行ってください。

16.6.3.2. プリエンプションが実行されたプリエンプションが実行された Pod の正常な終了の正常な終了

Pod のプリエンプションの実行中、スケジューラーは Pod の正常な終了期間が期限切れになるのを待機します。その後、Pod は機能を完了し、終了します。Pod がこの期間後も終了しない場合、スケジューラーは Pod を強制終了します。この正常な終了期間により、スケジューラーによる Pod のプリエンプションの実行時と保留中の Pod のノードへのスケジュール時に時間差が出ます。

この時間差を最小限にするには、優先順位の低い Pod の正常な終了期間を短く設定します。

16.6.4. Pod の優先順位のシナリオ例

Pod の優先順位およびプリエンプションはスケジューリングに使用する優先順位を Pod に割り当てます。スケジューラーは優先順位の高い Pod をスケジュールするために優先順位の低い Pod のプリエンプション (エビクト) を実行します。

通常のプリエンプションシナリオ

Pod P は保留中の Pod です。

1. スケジューラーはノード N を見つけます。ここでは、1 つ以上の Pod が削除され、Pod Pがそのノードにスケジュールされます。

2. スケジューラーはノード N から優先順位の低い Pod を削除し、Pod P をこのノードにスケジュールします。

3. Pod P の nominatedNodeName フィールドはノード N の名前に設定されます。

注記注記

Pod P は必ずしも指定したノードにスケジュールされる訳ではありません。

プリエンプションおよび終了期間

プリエンプションが実行された Pod には長い終了期間が設定されます。

1. スケジューラーはノード N で優先順位の低い Pod のプリエンプションを実行します。

2. スケジューラーは、Pod が正常に終了するのを待機します。

3. 他のスケジューリングの理由により、ノード M が利用可能になります。

4. スケジューラーは Pod P をノード M にスケジュールできます。

16.6.5. 優先順位およびプリエンプションの設定

priorityClassName を Pod 仕様で使用し、優先順位クラスオブジェクトを作成し、Pod を優先順位に関連付けることで、Pod の優先順位およびプリエンプションを適用できます。


184

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#graceful-termination

1

2

3

4

1

優先順位クラスオブジェクトのサンプル優先順位クラスオブジェクトのサンプル

優先順位クラスオブジェクトの名前です。

オブジェクトの優先順位の値です。

この優先順位クラスが優先順位クラス名が指定されない状態で Pod に使用されるかどうかを示すオプションのフィールドです。このフィールドはデフォルトで false です。globalDefault が trueに設定される 1 つの優先順位クラスのみがクラスター内に存在できます。globalDefault:true が設定された優先順位クラスがない場合、優先順位クラス名が設定されていない Podの優先順位はゼロになります。globalDefault:true が設定された優先順位クラスを追加すると、優先順位クラスが追加された後に作成された Pod のみがその影響を受け、これによって既存 Pod の優先順位は変更されません。

開発者がこの優先順位クラスで使用する必要のある Pod を記述するオプションのテキスト文字列です。

優先順位クラス名を持つ優先順位クラス名を持つ Pod 仕様サンプル仕様サンプル

この Pod で使用する優先順位クラスを指定します。

優先順位およびプリエンプションを使用するようにクラスターを設定するには、以下を実行します。

1. 1 つ以上の優先順位クラスを作成します。

a. 優先順位の名前および値を指定します。

b. 優先順位クラスおよび説明に globalDefault フィールドをオプションで指定します。

2. Pod を作成するか、または優先順位クラスの名前を含むように既存 Pod を編集します。優先順位名は Pod 設定または Pod テンプレートに直接追加できます。

apiVersion: scheduling.k8s.io/v1beta1kind: PriorityClassmetadata: name: high-priority 1value: 1000000 2globalDefault: false 3description: "This priority class should be used for XYZ service pods only." 4

apiVersion: v1kind: Podmetadata: name: nginx labels: env: testspec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent priorityClassName: high-priority 1


185

16.6.6. 優先順位およびプリエンプションの無効化

Pod の優先順位およびプリエンプション機能を無効にできます。

この機能が無効にされた後に、既存 Pod はそれらの優先順位フィールドを維持しますが、プリエンプションは無効にされ、優先順位フィールドは無視されます。この機能が無効にされると、新規 Pod に優先順位クラス名を設定できません。

重要重要

クラスターがリソース不足の状態にある場合、Critical Pod のスケジューリングにはスケジューラーのプリエンプションが使用されます。このため、プリエンプションを無効にしないことが推奨されています。 DeamonSet Pod は DeamonSet コントローラーによってスケジュールされるため、プリエンプションを無効にしても影響を受けません。

クラスターのプリエンプションを無効にするには、以下を実行します。

1. schedulerArgs セクションの disablePreemption パラメーターを false に設定するように master-config.yaml を変更します。

disablePreemption=false

2. 変更を有効にするために OpenShift Container Platform マスターサービスおよびスケジューラーを再起動します。

# master-restart api# master-restart scheduler

16.7. 詳細スケジューリング

16.7.1. 概要

詳細スケジューリングには、Pod が特定ノードで実行されることを要求したり、Pod が特定ノードで実行されることが優先されるように Pod を設定することが関係します。

通常、詳細スケジューリングは必要になりません。OpenShift Container Platform が Pod を合理的な方法で自動的に配置するためです。たとえば、デフォルトスケジューラーは Pod をノード間で均等に分散し、ノードの利用可能なリソースを考慮します。ただし、Pod を配置する場所についてはさらに制御を強化する必要がある場合があります。

Pod をより高速なディスクが搭載されたマシンに配置する必要ある場合 (またはそのマシンに配置するのを防ぐ場合)、または 2 つの異なるサービスの Pod が相互に通信できるように配置する必要がある場合、詳細スケジューリングを使用してそれを可能にすることができます。

適切な新規 Pod を特定のノードグループにスケジュールし、その他の新規 Pod がそれらのノードでスケジュールされるのを防ぐには、必要に応じてこれらの方法を組み合わせることができます。

16.7.2. 詳細スケジューリングの使用

クラスターで詳細スケジューリングを起動する方法はいくつかあります。

Pod のアフィニティーおよび非アフィニティー

Pod のアフィニティーにより、Pod がその配置に使用できるアフィニティー (または非アフィニ


186

Pod のアフィニティーにより、Pod がその配置に使用できるアフィニティー (または非アフィニティー) を、(セキュリティー上の理由によるアプリケーションの待機時間の要件などのために) Podのグループに対して指定できるようにします。ノード自体は配置に対する制御を行いません。Pod のアフィニティーはノードのラベルと Pod のラベルセレクターを使用して Pod 配置のルールを作成します。ルールは mandatory (必須) または best-effort (優先) のいずれかにすることができます。

「Pod のアフィニティーおよび非アフィニティーの使用」を参照してください。

ノードのアフィニティー

ノードのアフィニティーにより、Pod がその配置に使用できるアフィニティー (または非アフィニティー) を、(高可用性のための特殊なハードウェア、場所、要件などにより) ノードのグループに対して指定できるようにします。ノード自体は配置に対する制御を行いません。ノードのアフィニティーはノードのラベルと Pod のラベルセレクターを使用して Pod 配置のルールを作成します。ルールは mandatory (必須) または best-effort (優先) のいずれかにすることができます。

「ノードアフィニティーの使用」を参照してください。

ノードセレクター

ノードセレクターは詳細スケジューリングの最も単純な形態です。ノードのアフィニティーのように、ノードセレクターはノードのラベルと Pod のラベルセレクターを使用し、Pod がその配置に使用するノードを制御できるようにします。ただし、ノードセレクターにはノードのアフィニティーが持つ required (必須) ルールまたは preferred (優先) ルールはありません。「ノードセレクターの使用」を参照してください。

テイントおよび容認 (Toleration)

テイント/容認により、ノードはノード上でスケジュールする必要のある (またはスケジュールすべきでない) Pod を制御できます。テイントはノードのラベルであり、容認は Pod のラベルです。スケジュールを可能にするには、Pod のラベルはノードのラベル (テイント) に一致する (またはこれを許容する) 必要があります。テイント/容認にはアフィニティーと比較して 1 つ利点があります。たとえばアフィニティーの場合は、異なるラベルを持つノードの新規グループをクラスターに追加する場合、ノードにアクセスさせたい Pod とノードを使用させたくない Pod のそれぞれに対してアフィニティーを更新する必要がありますが、テイント/容認の場合には、新規ノードに到達させる必要のある Pod のみを更新すれば、他の Pod は拒否されることになります。

「テイントおよび容認の使用」を参照してください。

16.8. 詳細スケジューリングおよびノードのアフィニティー

16.8.1. 概要

ノードのアフィニティーは、Pod の配置場所を判別するためにスケジューラーによって使用されるルールのセットです。ルールはカスタムのノードのラベルと Pod で指定されるラベルセレクターを使って定義されます。ノードのアフィニティーにより、Pod はその配置に使用できるノードのグループに対してアフィニティー (または非アフィニティー) を指定できます。ノード自体は配置に対して制御を行いません。

たとえば、Pod を特定の CPU を搭載したノードまたは特定のアベイラビリティーゾーンにあるノードでのみ実行されるよう設定することができます。


187


1

2

3 5 6

4

ノードのアフィニティールールには、required (必須) および preferred (優先) の 2 つのタイプがあります。

required (必須) ルールは、Pod をノードにスケジュールする前に満たされている必要があります。一方、preferred (優先) ルールは、ルールが満たされる場合にスケジューラーがルールの実施を試行しますが、その実施が必ずしも保証される訳ではありません。

注記注記

ランタイム時にノードのラベルに変更が生じ、その変更により Pod でのノードのアフィニティールールを満たさなくなる状態が生じるでも、Pod はノードで引き続き実行されます。

16.8.2. ノードのアフィニティーの設定

ノードのアフィニティーは、Pod 仕様で設定することができます。required (必須) ルール、preferred(優先) ルールのいずれかまたはその両方を指定することができます。両方を指定する場合、ノードは最初に required (必須) ルールを満たす必要があり、その後に preferred (優先) ルールを満たそうとします。

以下の例は、Pod をキーが e2e-az-NorthSouth で、その値が e2e-az-North または e2e-az-South のいずれかであるラベルの付いたノードに Pod を配置することを求めるルールが設定された Pod 仕様です。

ノードのアフィニティーのノードのアフィニティーの required (必須必須) ルールが設定されたルールが設定された Pod 設定ファイルのサンプル設定ファイルのサンプル

apiVersion: v1kind: Podmetadata: name: with-node-affinityspec: affinity: nodeAffinity: 1 requiredDuringSchedulingIgnoredDuringExecution: 2 nodeSelectorTerms: - matchExpressions: - key: e2e-az-NorthSouth 3 operator: In 4 values: - e2e-az-North 5 - e2e-az-South 6 containers: - name: with-node-affinity image: docker.io/ocpqe/hello-pod

ノードのアフィニティーを設定するためのスタンザです。

required (必須) ルールを定義します。

ルールを適用するために一致している必要のあるキー/値のペア (ラベル) です。

演算子は、ノードのラベルと Pod 仕様の matchExpression パラメーターの値のセットの間の関係を表します。この値は、In、NotIn、Exists、または DoesNotExist、Lt、または Gt にすることができます。


188

1

2

3

4 6 7

5

以下の例は、キーが e2e-az-EastWest で、その値が e2e-az-East または e2e-az-West のラベルが付いたノードに Pod を配置すること優先する preferred (優先) ルールが設定されたノード仕様です。

ノードのアフィニティーのノードのアフィニティーの preferred (優先優先) ルールが設定されたルールが設定された Pod 設定ファイルのサンプル設定ファイルのサンプル

apiVersion: v1kind: Podmetadata: name: with-node-affinityspec: affinity: nodeAffinity: 1 preferredDuringSchedulingIgnoredDuringExecution: 2 - weight: 1 3 preference: matchExpressions: - key: e2e-az-EastWest 4 operator: In 5 values: - e2e-az-East 6 - e2e-az-West 7 containers: - name: with-node-affinity image: docker.io/ocpqe/hello-pod

ノードのアフィニティーを設定するためのスタンザです。



ルールを適用するために一致している必要のあるキー/値のペア (ラベル) です。

演算子は、ノードのラベルと Pod 仕様の matchExpression パラメーターの値のセットの間の関係を表します。この値は、In、NotIn、Exists、または DoesNotExist、Lt、または Gt にすることができます。

ノードの非アフィニティーについての明示的な概念はありませんが、NotIn または DoesNotExist 演算子を使用すると、動作が複製されます。

注記注記


189

注記注記

同じ Pod 設定でノードのアフィニティーとノードセレクターを使用している場合、以下に注意してください。

nodeSelector と nodeAffinity の両方を設定する場合、Pod が候補ノードでスケジュールされるにはどちらの条件も満たしている必要があります。

nodeAffinity タイプに関連付けられた複数の nodeSelectorTerms を指定する場合、nodeSelectorTerms のいずれかが満たされている場合に Pod をノードにスケジュールすることができます。

nodeSelectorTerms に関連付けられた複数の matchExpressions を指定する場合、すべての matchExpressions が満たされている場合にのみ Pod をノードにスケジュールすることができます。

16.8.2.1. ノードアフィニティーのノードアフィニティーの required (必須必須) ルールの設定ルールの設定

Pod がノードにスケジュールされる前に、required (必須) ルールを満たしている必要があります。

以下の手順は、ノードとスケジューラーがノードに配置する必要のある Pod を作成する単純な設定を示しています。

1. ノード設定を編集するか、または oc label node コマンドを使用してラベルをノードに追加します。

$ oc label node node1 e2e-az-name=e2e-az1

注記注記

クラスターのノードを変更するには、ノード設定マップを必要に応じて更新します。node-config.yaml ファイルは手動で変更しないようにしてください。

2. Pod 仕様では、nodeAffinity スタンザを使用して requiredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

a. 満たす必要のあるキーおよび値を指定します。新規 Pod を編集したノードにスケジュールする必要がある場合、ノードのラベルと同じkey および value パラメーターを使用します。

b. operator を指定します。演算子は In、NotIn、Exists、DoesNotExist、Lt、または Gt にすることができます。たとえば、演算子 In を使用してラベルがノードで必要になるようにします。

spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: e2e-az-name operator: In values: - e2e-az1 - e2e-az2


190

3. Pod を作成します。

$ oc create -f e2e-az2.yaml

16.8.2.2. ノードアフィニティーのノードアフィニティーの preferred (優先優先) ルールの設定ルールの設定

preferred (優先) ルールは、ルールを満たす場合に、スケジューラーはルールの実施を試行しますが、その実施が必ずしも保証される訳ではありません。

以下の手順は、ノードとスケジューラーがノードに配置しようとする Pod を作成する単純な設定を示しています。

1. ノード設定を編集するか、または oc label node コマンドを実行してラベルをノードに追加します。

$ oc label node node1 e2e-az-name=e2e-az3

注記注記


2. Pod 仕様では、nodeAffinity スタンザを使用して preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

a. ノードの重みを数字の 1-100 で指定します。最も高い重みを持つノードが優先されます。

b. 満たす必要のあるキーおよび値を指定します。新規 Pod を編集したノードにスケジュールする必要がある場合、ノードのラベルと同じkey および value パラメーターを使用します。

preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: matchExpressions: - key: e2e-az-name operator: In values: - e2e-az3

3. operator を指定します。演算子は In、NotIn、Exists、DoesNotExist、Lt、または Gt にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。


$ oc create -f e2e-az3.yaml

16.8.3. 例

以下の例は、ノードのアフィニティーを示しています。

16.8.3.1. 一致するラベルを持つノードのアフィニティー一致するラベルを持つノードのアフィニティー


191

以下の例は、一致するラベルを持つノードと Pod のノードのアフィニティーを示しています。

Node1 ノードにはラベル zone:us があります。

$ oc label node node1 zone=us

Pod pod-s1 にはノードアフィニティーの required (必須) ルールの下に zone と us のキー/値のペアがあります。

$ cat pod-s1.yamlapiVersion: v1kind: Podmetadata: name: pod-s1spec: containers: - image: "docker.io/ocpqe/hello-pod" name: hello-pod affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "zone" operator: In values: - us

標準コマンドを使用して Pod を作成します。

$ oc create -f pod-s1.yamlpod "pod-s1" created

Pod pod-s1 を Node1 にスケジュールできます。

oc get pod -o wideNAME READY STATUS RESTARTS AGE IP NODEpod-s1 1/1 Running 0 4m IP1 node1

16.8.3.2. 一致するラベルのないノードのアフィニティー一致するラベルのないノードのアフィニティー

以下の例は、一致するラベルを持たないノードと Pod のノードのアフィニティーを示しています。

Node1 ノードにはラベル zone:emea があります。

$ oc label node node1 zone=emea

Pod pod-s1 にはノードアフィニティーの required (必須) ルールの下に zone と us のキー/値のペアがあります。

$ cat pod-s1.yamlapiVersion: v1kind: Podmetadata:


192

name: pod-s1spec: containers: - image: "docker.io/ocpqe/hello-pod" name: hello-pod affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "zone" operator: In values: - us

Pod pod-s1 は Node1 にスケジュールすることができません。

oc describe pod pod-s1<---snip--->Events: FirstSeen LastSeen Count From SubObjectPath Type Reason --------- -------- ----- ---- ------------- -------- ------ 1m 33s 8 default-scheduler Warning FailedScheduling No nodes are available that match all of the following predicates:: MatchNodeSelector (1).

16.9. 詳細スケジューリングおよび POD のアフィニティーと非アフィニティー

16.9.1. 概要

Pod のアフィニティーおよび Pod の非アフィニティーにより、他の Pod との関連で Pod を配置する方法についてのルールを指定できます。ルールは、カスタムのノードのラベルおよび Pod で指定されるラベセレクターを使用して定義されます。Pod のアフィニティー/非アフィニティーにより、Pod はアフィニティー (または非アフィニティー) を、その配置に使用できる Pod のグループに対して指定できます。ノード自体は配置に対する制御を行いません。

たとえば、アフィニティールールを使用することで、サービス内で、または他のサービスの Pod との関連で Pod を分散したり、パックしたりすることができます。非アフィニティールールにより、特定のサービスの Pod がそののサービスの Pod のパフォーマンスに干渉すると見なされる別のサービスのPod と同じノードでスケジュールされることを防ぐことができます。または、関連する障害を減らすために複数のノードまたはアベイラビリティーゾーン間でサービスの Pod を分散することもできます。

Pod のアフィニティー/非アフィニティーにより、他の Pod のラベルに基づいて Pod のスケジュール対象とするノードを制限することができます。ラベルはキー/値のペアです。

Pod のアフィニティーはスケジューラーに対し、新規 Pod のラベルセレクターが現在の Podのラベルに一致する場合に他の Pod と同じノードで新規 Pod を見つけるように指示します。

Pod の非アフィニティーは、新規 Pod のラベルセレクターが現在の Pod のラベルに一致する場合に、同じラベルを持つ Pod と同じノードで新規 Pod を見つけることを禁止します。

Pod のアフィニティーには、required (必須) および preferred (優先) の 2 つのタイプがあります。

required (必須) ルールは、Pod をノードにスケジュールする前に満たされている必要があります。一


193



1

2

3 5

required (必須) ルールは、Pod をノードにスケジュールする前に満たされている必要があります。一方、preferred (優先) ルールは、ルールが満たされる場合にスケジューラーがルールの実施を試行しますが、その実施が必ずしも保証される訳ではありません。

注記注記

Pod の優先順位およびプリエンプションの設定により、スケジューラーはアフィニティーの要件に違反しなければ Pod の適切なノードを見つけられない可能性があります。その場合、Pod はスケジュールされない可能性があります。

この状態を防ぐには、優先順位が等しい Pod との Pod のアフィニティーの設定を慎重に行ってください。

16.9.2. Pod のアフィニティーおよび非アフィニティーの設定

Pod のアフィニティー/非アフィニティーは Pod 仕様ファイルで設定します。required (必須) ルール、preferred (優先) ルールのいずれかまたはその両方を指定することができます。両方を指定する場合、ノードは最初に required (必須) ルールを満たす必要があり、その後に preferred (優先) ルールを満たそうとします。

以下の例は、Pod のアフィニティーおよび非アフィニティーに設定される Pod 仕様を示しています。

この例では、Pod のアフィニティールールはノードにキー security と値 S1 を持つラベルの付いた 1 つ以上の Pod がすでに実行されている場合にのみ Pod をノードにスケジュールできることを示しています。Pod の非アフィニティールールは、ノードがキー security と値 S2 を持つラベルが付いた Pod がすでに実行されている場合は Pod をノードにスケジュールしないように設定することを示しています。

Pod のアフィニティーが設定されたのアフィニティーが設定された Pod 設定のサンプル設定のサンプル

Pod のアフィニティーを設定するためのスタンザです。

required (必須) ルールを定義します。

ルールを適用するために一致している必要のあるキーと値 (ラベル) です。

apiVersion: v1kind: Podmetadata: name: with-pod-affinityspec: affinity: podAffinity: 1 requiredDuringSchedulingIgnoredDuringExecution: 2 - labelSelector: matchExpressions: - key: security 3 operator: In 4 values: - S1 5 topologyKey: failure-domain.beta.kubernetes.io/zone containers: - name: with-pod-affinity image: docker.io/ocpqe/hello-pod


194

4

1

2

3

4

5

演算子は、既存 Pod のラベルと新規 Pod の仕様の matchExpression パラメーターの値のセットの間の関係を表します。これには In、NotIn、Exists、または DoesNotExist のいずれかを使用で

Pod の非アフィニティーが設定されたの非アフィニティーが設定された Pod 設定のサンプル設定のサンプル

Pod の非アフィニティーを設定するためのスタンザです。



非アフィニティールールが適用される時を決定する Pod ラベルの説明です。ラベルのキーおよび値を指定します。

演算子は、既存 Pod のラベルと新規 Pod の仕様の matchExpression パラメーターの値のセットの間の関係を表します。これには In、NotIn、Exists、または DoesNotExist のいずれかを使用できます。

注記注記

ノードのラベルに、Pod のノードのアフィニティールールを満たさなくなるような結果になる変更がランタイム時に生じる場合も、Pod はノードで引き続き実行されます。

16.9.2.1. アフィニティールールの設定アフィニティールールの設定

以下の手順は、ラベルの付いた Pod と Pod のスケジュールを可能にするアフィニティーを使用するPod を作成する 2 つの Pod の単純な設定を示しています。

1. Pod 仕様の特定のラベルの付いた Pod を作成します。

apiVersion: v1kind: Podmetadata: name: with-pod-antiaffinityspec: affinity: podAntiAffinity: 1 preferredDuringSchedulingIgnoredDuringExecution: 2 - weight: 100 3 podAffinityTerm: labelSelector: matchExpressions: - key: security 4 operator: In 5 values: - S2 topologyKey: kubernetes.io/hostname containers: - name: with-pod-affinity image: docker.io/ocpqe/hello-pod

$ cat team4.yamlapiVersion: v1


195

2. 他の Pod の作成時に、以下のように Pod 仕様を編集します。

a. podAffinity スタンザを使用して、requiredDuringSchedulingIgnoredDuringExecutionパラメーターまたは preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

b. 満たしている必要のあるキーおよび値を指定します。新規 Pod を他の Pod と共にスケジュールする必要がある場合、最初の Pod のラベルと同じ key および value パラメーターを使用します。

c. operator を指定します。演算子は In、NotIn、Exists、または DoesNotExist にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。

d. topologyKey を指定します。これは、システムがトポロジードメインを表すために使用する事前にデータが設定された Kubernetes ラベルです。


$ oc create -f <pod-spec>.yaml

16.9.2.2. 非アフィニティールールの設定非アフィニティールールの設定

以下の手順は、ラベルの付いた Pod と Pod のスケジュールの禁止を試行する非アフィニティーのpreferred (優先) ルールを使用する Pod を作成する 2 つの Pod の単純な設定を示しています。

1. Pod 仕様の特定のラベルの付いた Pod を作成します。

kind: Podmetadata: name: security-s1 labels: security: S1spec: containers: - name: security-s1 image: docker.io/ocpqe/hello-pod

podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: failure-domain.beta.kubernetes.io/zone

$ cat team4.yamlapiVersion: v1kind: Podmetadata: name: security-s2 labels: security: S2spec:


196

https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#interlude-built-in-node-labels

2. 他の Pod の作成時に、Pod 仕様を編集して以下のパラメーターを設定します。

3. podAffinity スタンザを使用して、requiredDuringSchedulingIgnoredDuringExecution パラメーターまたは preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

a. ノードの重みを 1-100 で指定します。最も高い重みを持つノードが優先されます。

b. 満たしている必要のあるキーおよび値を指定します。新規 Pod を他の Pod と共にスケジュールされないようにする必要がある場合、最初の Pod のラベルと同じ key および value パラメーターを使用します。

c. preferred (優先) ルールの場合、重みを 1-100 で指定します。

d. operator を指定します。演算子は In、NotIn、Exists、または DoesNotExist にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。

4. topologyKey を指定します。これは、システムがトポロジードメインを表すために使用する事前にデータが設定された Kubernetes ラベルです。


$ oc create -f <pod-spec>.yaml

16.9.3. 例

以下の例は、Pod のアフィニティーおよび非アフィニティーについて示しています。

16.9.3.1. Pod のアフィニティーのアフィニティー

以下の例は、一致するラベルとラベルセレクターを持つ Pod についての Pod のアフィニティーを示しています。

Pod team4 にはラベル team:4 が付けられています。

containers: - name: security-s2 image: docker.io/ocpqe/hello-pod

podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: security operator: In values: - S2 topologyKey: kubernetes.io/hostname

$ cat team4.yamlapiVersion: v1kind: Podmetadata:


197

https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#interlude-built-in-node-labels

Pod team4a には、podAffinity の下にラベルセレクター team:4 が付けられています。

team4a Pod は team4 Pod と同じノードにスケジュールされます。

16.9.3.2. Pod の非アフィニティーの非アフィニティー

以下の例は、一致するラベルとラベルセレクターを持つ Pod についての Pod の非アフィニティーを示しています。

Pod pod-s1 にはラベル security:s1 が付けられています。

Pod pod-s2 には、podAntiAffinity の下にラベルセレクター security:s1 が付けられています。

name: team4 labels: team: "4"spec: containers: - name: ocp image: docker.io/ocpqe/hello-pod

$ cat pod-team4a.yamlapiVersion: v1kind: Podmetadata: name: team4aspec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: team operator: In values: - "4" topologyKey: kubernetes.io/hostname containers: - name: pod-affinity image: docker.io/ocpqe/hello-pod

cat pod-s1.yamlapiVersion: v1kind: Podmetadata: name: pod-s1 labels: security: s1spec: containers: - name: ocp image: docker.io/ocpqe/hello-pod

cat pod-s2.yaml


198

Pod pod-s2 は pod-s1 と同じノードにスケジュールできません。

16.9.3.3. 一致するラベルのない一致するラベルのない Pod のアフィニティーのアフィニティー

以下の例は、一致するラベルとラベルセレクターのない Pod についての Pod のアフィニティーを示しています。

Pod pod-s1 にはラベル security:s1 が付けられています。

Pod pod-s2 にはラベルセレクター security:s2 があります。

apiVersion: v1kind: Podmetadata: name: pod-s2spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - s1 topologyKey: kubernetes.io/hostname containers: - name: pod-antiaffinity image: docker.io/ocpqe/hello-pod

$ cat pod-s1.yamlapiVersion: v1kind: Podmetadata: name: pod-s1 labels: security: s1spec: containers: - name: ocp image: docker.io/ocpqe/hello-pod

$ cat pod-s2.yamlapiVersion: v1kind: Podmetadata: name: pod-s2spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In


199

Pod pod-s2 は、security:s2 ラベルの付いた Pod を持つノードがない場合はスケジュールされません。そのラベルの付いた他の Pod がない場合、新規 Pod は保留状態のままになります。

NAME READY STATUS RESTARTS AGE IP NODEpod-s2 0/1 Pending 0 32s <none>

16.10. 詳細スケジューリングおよびノードセレクター

16.10.1. 概要

ノードセレクターはキーと値のペアのマップを指定します。ルールは、カスタムのノードのラベルおよび Pod で指定されるセレクターを使用して定義されます。

Pod がノードで実行する要件を満たすには、Pod はノードのラベルとして示されるキーと値のペアを持っている必要があります。

同じ Pod 設定でノードのアフィニティーとノードセレクターを使用している場合は、以下の「重要な考慮事項」を参照してください。

16.10.2. ノードセレクターの設定

Pod 設定で nodeSelector を使用することで、Pod を特定のラベルの付いたノードのみに配置することができます。

1. 必要なラベル (詳細は、「ノードでのラベルの更新」を参照) およびノードセレクターが環境にセットアップされていることを確認します。たとえば、Pod 設定が必要なラベルを示す nodeSelector 値を持つことを確認します。

apiVersion: v1kind: Podspec: nodeSelector: <key>: <value>...

2. マスター設定ファイル /etc/origin/master/master-config.yaml を変更し、nodeSelectorLabelBlacklist を、Pod の配置を拒否する必要のあるノードホストに割り当てられるラベルと共に admissionConfig セクションに追加します。

...admissionConfig: pluginConfig: PodNodeConstraints: configuration: apiversion: v1 kind: PodNodeConstraintsConfig

values: - s2 topologyKey: kubernetes.io/hostname containers: - name: pod-affinity image: docker.io/ocpqe/hello-pod


200


nodeSelectorLabelBlacklist: - kubernetes.io/hostname - <label>...



注記注記

同じ Pod 設定でノードセレクターとノードのアフィニティーを使用している場合は、以下に注意してください。

nodeSelector と nodeAffinity の両方を設定する場合、Pod が候補ノードでスケジュールされるにはどちらの条件も満たしている必要があります。

nodeAffinity タイプに関連付けられた複数の nodeSelectorTerms を指定する場合、nodeSelectorTerms のいずれかが満たされている場合に Pod をノードにスケジュールすることができます。

nodeSelectorTerms に関連付けられた複数の matchExpressions を指定する場合、すべての matchExpressions が満たされている場合にのみ Pod をノードにスケジュールすることができます。

16.11. 詳細スケジューリングおよび容認

16.11.1. 概要

テイントおよび容認により、ノードはノード上でスケジュールする必要のある (またはスケジュールすべきでない) Pod を制御できます。

16.11.2. テイントおよび容認 (Toleration)

テイントにより、ノードは Pod に一致する容認がない場合に Pod のスケジュールを拒否することができます。

テイントはノード仕様 (NodeSpec) でノードに適用され、容認は Pod 仕様 (PodSpec) で Pod に適用されます。ノードのテイントはノードに対し、テイントを容認しないすべての Pod を拒否するよう指示します。

テイントおよび容認は、key、value、および effect.で構成されています。演算子により、これらの 3 つのパラメーターのいずれかを空のままにすることができます。

表16.1 テイントおよび容認コンポーネント


key key には、253 文字までの文字列を使用できます。キーは文字または数字で開始する必要があり、文字、数字、ハイフン、ドットおよびアンダースコアを含めることができます。


201

value value には、63 文字までの文字列を使用できます。値は文字または数字で開始する必要があり、文字、数字、ハイフン、ドットおよびアンダースコアを含めることができます。

effect effect は以下のいずれかにすることができます。

NoScheduleテイントに一致しない新規 Pod はノードにスケジュールされません。

ノードの既存 Pod はそのままになります。

PreferNoScheduleテイントに一致しない新規 Pod はノードにスケジュールされる可能性がありますが、スケジューラーはスケジュールしないようにします。

ノードの既存 Pod はそのままになります。

NoExecuteテイントに一致しない新規 Pod はノードにスケジュールできません。

一致する容認を持たないノードの既存Pod は削除されます。

operatorEqual key/value/effect パラメーターは一致する必

要があります。これはデフォルトになります。

Exists key/effect パラメーターは一致する必要があります。いずれかに一致する value パラメーターを空のままにする必要があります。


容認はテイントと一致します。

operator パラメーターが Equal に設定されている場合:

key パラメーターは同じになります。

value パラメーターは同じになります。

effect パラメーターは同じになります。

operator パラメーターが Exists に設定されている場合:

key パラメーターは同じになります。


202

effect パラメーターは同じになります。

16.11.2.1. 複数テイントの使用複数テイントの使用

複数のテイントを同じノードに、複数の容認を同じ Pod に配置することができます。OpenShiftContainer Platform は複数のテイントと容認を以下のように処理します。

1. Pod に一致する容認のあるテイントを処理します。

2. 残りの一致しないテイントは Pod について以下の effect を持ちます。

effect が NoSchedule の一致しないテイントが 1 つ以上ある場合、OpenShift ContainerPlatform は Pod をノードにスケジュールできません。

effect が NoSchedule の一致しないテイントがなく、effect が PreferNoSchedule の一致しないテイントが 1 つ以上ある場合、OpenShift Container Platform は Pod のノードへのスケジュールを試行しません。

effect が NoExecute のテイントが 1 つ以上ある場合、OpenShift Container Platform はPod をノードからエビクトするか (ノードですでに実行中の場合)、または Pod のそのノードへのスケジュールが実行されません (ノードでまだ実行されていない場合)。

テイントを容認しない Pod はすぐにエビクトされます。

容認の仕様に tolerationSeconds を指定せずにテイントを容認する Pod は永久にバインドされたままになります。

指定された tolerationSeconds を持つテイントを容認する Pod は指定された期間バインドされます。

例:

ノードには以下のテイントがあります。

$ oc adm taint nodes node1 key1=value1:NoSchedule$ oc adm taint nodes node1 key1=value1:NoExecute$ oc adm taint nodes node1 key2=value2:NoSchedule

Pod には以下の容認があります。

この場合、3 つ目のテイントに一致する容認がないため、Pod はノードにスケジュールできません。Pod はこのテイントの追加時にノードですでに実行されている場合は実行が継続されます。3 つ目のテイントは 3 つのテイントの中で Pod で容認されない唯一のテイントであるためです。

16.11.3. テイントの既存ノードへの追加

tolerations:- key: "key1" operator: "Equal" value: "value1" effect: "NoSchedule"- key: "key1" operator: "Equal" value: "value1" effect: "NoExecute"


203

1 2 3 4

5

テイントおよび容認コンポーネントの表で説明されているパラメーターと共に oc adm taint コマンドを使用してテイントをノードに追加します。

$ oc adm taint nodes <node-name> <key>=<value>:<effect>

例:

$ oc adm taint nodes node1 key1=value1:NoExecute

この例では、キー key1、値 value1、およびテイント effect NoExecute を持つ node1 にテイントを配置します。

16.11.4. 容認の Pod への追加

容認を Pod に追加するには、Pod 仕様を tolerations セクションを含めるように編集します。

Equal 演算子を含む演算子を含む Pod 設定ファイルのサンプル設定ファイルのサンプル

テイントおよび容認コンポーネントの表で説明されている toleration パラメーターです。

tolerationSeconds パラメーターは、Pod がエビクトされる前にノードにバインドされる期間を指定します。以下の「Pod エビクションを遅延させる容認期間 (秒数) の使用」を参照してください。

Exists 演算子を含む演算子を含む Pod 設定ファイルのサンプル設定ファイルのサンプル

これらの容認のいずれも上記の oc adm taint コマンドで作成されるテイントに一致します。いずれかの容認のある Pod は node1 にスケジュールできます。

16.11.4.1. Pod のエビクションを遅延させる容認期間のエビクションを遅延させる容認期間 (秒数秒数) の使用の使用

Pod 仕様に tolerationSeconds パラメーターを指定して、Pod がエビクトされる前にノードにバインドされる期間を指定できます。effect NoExecute のあるテイントがノードに追加される場合、テイントを容認しない Pod は即時にエビクトされます (テイントを容認する Pod はエビクトされません)。ただし、エビクトされる Pod に tolerationSeconds パラメーターがある場合、Pod は期間切れになるまでエビクトされません。

例:

tolerations:- key: "key1" 1 operator: "Equal" 2 value: "value1" 3 effect: "NoExecute" 4 tolerationSeconds: 3600 5

tolerations:- key: "key1" operator: "Exists" effect: "NoExecute" tolerationSeconds: 3600


204

ここで、この Pod が実行中であるものの、一致するテイントがない場合、Pod は 3,600 秒間バインドされたままとなり、その後にエビクトされます。テイントが期限前に削除される場合、Pod はエビクトされません。

16.11.4.1.1. 容認の秒数のデフォルト値の設定

このプラグインは、node.kubernetes.io/not-ready:NoExecute および node.kubernetes.io/unreachable:NoExecute テイントを 5 分間容認するための Pod のデフォルトの容認を設定します。

ユーザーが提供する Pod 設定にいずれかの容認がある場合、デフォルトは追加されません。

デフォルトの容認の秒数を有効にするには、以下を実行します。

1. マスター設定ファイル (/etc/origin/master/master-config.yaml) を変更して DefaultTolerationSeconds を admissionConfig セクションに追加します。

2. 変更を有効にするために、OpenShift を再起動します。


3. デフォルトが追加されていることを確認します。

a. Pod を作成します。

$ oc create -f </path/to/file>

例:

$ oc create -f hello-pod.yamlpod "hello-pod" created

b. Pod の容認を確認します。

$ oc describe pod <pod-name> |grep -i toleration

例:

tolerations:- key: "key1" operator: "Equal" value: "value1" effect: "NoExecute" tolerationSeconds: 3600

admissionConfig: pluginConfig: DefaultTolerationSeconds: configuration: kind: DefaultAdmissionConfig apiVersion: v1 disable: false


205

$ oc describe pod hello-pod |grep -i tolerationTolerations: node.kubernetes.io/not-ready=:Exists:NoExecute for 300s

16.11.5. ノードの問題の発生時における Pod エビクション

OpenShift Container Platform は、node unreachable および node not ready 状態をテイントとして表示するよう設定できます。これにより、デフォルトの 5 分を使用するのではなく、unreachable (到達不能) または not ready (準備ができていない) 状態になるノードにバインドされたままになる期間を Pod仕様ごとに指定することができます。

テイントベースのエビクション機能が有効にされた状態で、テイントはノードコントローラーによって自動的に追加され、Pod を Ready ノードからエビクトするための通常のロジックは無効にされます。

ノードが not ready (準備ができていない) 状態になると、node.kubernetes.io/not-ready:NoExecute テイントは追加され、Pod はノードでスケジュールできなくなります。既存Pod は容認期間 (秒数) 中はそのまま残ります。

ノードが not reachable (到達不能) の状態になると、node.kubernetes.io/unreachable:NoExecute テイントは追加され、Pod はノードでスケジュールできません。既存の Pod は容認期間 (秒数) 中はそのまま残ります。

テイントベースのエビクションを有効にするには、以下を実行します。

1. マスター設定ファイル (/etc/origin/master/master-config.yaml) を変更して以下を kubernetesMasterConfig セクションに追加します。

2. テイントがノードに追加されていることを確認します。

oc describe node $node | grep -i taint

Taints: node.kubernetes.io/not-ready:NoExecute

3. 変更を有効にするために、OpenShift を再起動します。


4. 容認を Pod に追加します。

または、以下を実行します。

kubernetesMasterConfig: controllerArguments: feature-gates: - TaintBasedEvictions=true

tolerations:- key: "node.kubernetes.io/unreachable" operator: "Exists" effect: "NoExecute" tolerationSeconds: 6000

tolerations:- key: "node.kubernetes.io/not-ready"


206

注記注記

ノードの問題の発生時に Pod エビクションの既存のレート制限の動作を維持するために、システムはテイントをレートが制限された方法で追加します。これにより、マスターがノードからパーティション化される場合などのシナリオで発生する大規模な Podエビクションを防ぐことができます。

16.11.6. Daemonset および容認

Daemonset Pod は、Default Toleration Seconds (デフォルトの容認期間の秒数) 機能が無効にされている場合でも、tolerationSeconds のない node.kubernetes.io/unreachable および node.kubernetes.io/not-ready の NoExecute 容認の設定と共に作成され、DeamonSet Pod がエビクトされないようにします。

16.11.7. 例

テイントおよび容認は、Pod をノードから切り離し、ノードで実行されるべきでない Pod をエビクトする柔軟性のある方法として使用できます。以下は典型的なシナリオのいくつかになります。

ノードをユーザー専用にする

ユーザーをノードにバインドする

特殊ハードウェアを持つノードを専用ノードにする

16.11.7.1. ノードをユーザー専用にするノードをユーザー専用にする

ノードのセットを特定のユーザーセットが排他的に使用するように指定できます。

専用ノードを指定するには、以下を実行します。

1. テイントをそれらのノードに追加します。例:

$ oc adm taint nodes node1 dedicated=groupName:NoSchedule

2. カスタムの受付コントローラーを作成して、対応する容認を Pod に追加します。容認のある Pod のみが専用ノードを使用することを許可されます。

16.11.7.2. ユーザーのノードへのバインドユーザーのノードへのバインド

特定ユーザーが専用ノードのみを使用できるようにノードを設定することができます。

ノードをユーザーの使用可能な唯一のノードとして設定するには、以下を実行します。

1. テイントをそれらのノードに追加します。例:

$ oc adm taint nodes node1 dedicated=groupName:NoSchedule

operator: "Exists" effect: "NoExecute" tolerationSeconds: 6000


207

https://kubernetes.io/docs/admin/node/#node-controller

https://kubernetes.io/docs/admin/daemons/

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#master-config-admission-control-config

2. カスタムの受付コントローラーを作成して、対応する容認を Pod に追加します。受付コントローラーは、Pod が key:value ラベル (dedicated=groupName) が付けられたノードのみにスケジュールされるようにノードのアフィニティーを追加します。

3. テイントと同様のラベル (key:value ラベルなど) を専用ノードに追加します。

16.11.7.3. 特殊ハードウェアを持つノード特殊ハードウェアを持つノード

ノードの小規模なサブセットが特殊ハードウェア(GPU など) を持つクラスターでは、テイントおよび容認を使用して、特殊ハードウェアを必要としない Pod をそれらのノードから切り離し、特殊ハードウェアを必要とする Pod をそのままにすることができます。また、特殊ハードウェアを必要とするPod に対して特定のノードを使用することを要求することもできます。

Pod が特殊ハードウェアからブロックされるようにするには、以下を実行します。

1. 以下のコマンドのいずれかを使用して、特殊ハードウェアを持つノードにテイントを設定します。

$ oc adm taint nodes <node-name> disktype=ssd:NoSchedule$ oc adm taint nodes <node-name> disktype=ssd:PreferNoSchedule

2. 受付コントローラーを使用して特殊ハードウェアを使用する Pod に対応する容認を追加します。

たとえば受付コントローラーは容認を追加することで、Pod の一部の特徴を使用し、Pod が特殊ノードを使用できるかどうかを判別できます。

Pod が特殊ハードウェアのみを使用できるようにするには、追加のメカニズムが必要です。たとえば、特殊ハードウェアを持つノードにラベルを付け、ハードウェアを必要とする Pod でノードのアフィニティーを使用できます。


208



第17章クォータの設定

17.1. 概要

ResourceQuota オブジェクトで定義されるリソースクォータは、プロジェクトごとにリソース消費量の総計を制限する制約を指定します。これは、タイプ別にプロジェクトで作成できるオブジェクトの数量を制限すると共に、そのプロジェクトのリソースが消費できるコンピュートリソースおよびストレージの合計量を制限することができます。

注記注記

コンピュートリソースについての詳細は、『Developer Guide』を参照してください。

17.2. クォータで管理されるリソース

以下では、クォータで管理できる一連のコンピュートリソースとオブジェクトタイプについて説明します。

注記注記

status.phase in (Failed, Succeeded) が true の場合、Pod は終了状態にあります。

表17.1 クォータで管理されるコンピュートリソース

リソース名リソース名説明説明

cpu 非終了状態のすべての Pod での CPU 要求の合計はこの値を超えることができません。cpu および requests.cpu は同じ値で、交換可能なものとして使用できます。

memory 非終了状態のすべての Pod でのメモリー要求の合計はこの値を超えることができません memory および requests.memory は同じ値で、交換可能なものとして使用できます。

ephemeral-storage 非終了状態のすべての pod におけるローカルの一時ストレージ要求の合計はこの値を超えることができません。ephemeral-storage および requests.ephemeral-storage は同じ値であり、相互に置き換え可能なものとして使用できます。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効になっています。

requests.cpu 非終了状態のすべての Pod での CPU 要求の合計はこの値を超えることができません。cpu および requests.cpu は同じ値で、交換可能なものとして使用できます。

requests.memory 非終了状態のすべての Pod でのメモリー要求の合計はこの値を超えることができません memory および requests.memory は同じ値で、交換可能なものとして使用できます。

第第17章章クォータの設定クォータの設定

209

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-compute-resources

requests.ephemeral-storage

非終了状態のすべての Pod における一時ストレージ要求の合計はこの値を超えることができません。ephemeral-storage および requests.ephemeral-storage は同じ値であり、相互に置き換え可能なものとして使用できます。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効になっています。

limits.cpu 非終了状態のすべての Pod での CPU 制限の合計はこの値を超えることができません。

limits.memory 非終了状態のすべての Pod でのメモリー制限の合計はこの値を超えることができません。

limits.ephemeral-storage

非終了状態のすべての Pod における一時ストレージ要求の合計はこの値を超えることができません。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効になっています。


表17.2 クォータで管理されるストレージリソース


requests.storage 任意の状態のすべての Persistent Volume Claim (永続ボリューム要求、PVC)でのストレージ要求の合計はこの値を超えることができません。

persistentvolumeclaims

プロジェクトに存在できる Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。

<storage-class-name>.storageclass.storage.k8s.io/requests.storage

一致するストレージクラスを持つ、任意の状態のすべての Persistent VolumeClaim (永続ボリューム要求、PVC) でのストレージ要求の合計はこの値を超えることができません。

<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims

プロジェクトに存在できる、一致するストレージクラスを持つ PersistentVolume Claim (永続ボリューム要求、PVC) の合計数です。

表17.3 クォータで管理されるオブジェクト数


pods プロジェクトに存在できる非終了状態の Pod の合計数です。

replicationcontrollers プロジェクトに存在できるレプリケーションコントローラーの合計数です。


210

1

resourcequotas プロジェクトに存在できるリソースクォータの合計数です。

services プロジェクトに存在できるサービスの合計数です。

secrets プロジェクトに存在できるシークレットの合計数です。

configmaps プロジェクトに存在できる ConfigMap オブジェクトの合計数です。

persistentvolumeclaims


openshift.io/imagestreams

プロジェクトに存在できるイメージストリームの合計数です。


クォータの作成時に、count/<resource>.<group> 構文を使用してこれらの標準的な namespace を使用しているリソースタイプのオブジェクトカウントクォータを設定できます。

$ oc create quota <name> --hard=count/<resource>.<group>=<quota> 1

<resource> はリソースの名前であり、<group> は API グループです (該当する場合)。リソースおよびそれらの関連付けられた API グループの一覧に kubectl api-resources コマンドを使用します。

17.2.1. 拡張リソースのリソースクォータの設定

リソースのオーバーコミットは拡張リソースには許可されません。そのため、クォータで同じ拡張リソースについて requests および limits を指定する必要があります。現時点で、プレフィックス requests. のあるクォータ項目のみが拡張リソースに許可されます。以下は、GPU リソース nvidia.com/gpu のリソースクォータを設定する方法についてのシナリオ例です。

手順

1. クラスター内のノードで利用可能な GPU の数を判別します。以下は例になります。

# oc describe node ip-172-31-27-209.us-west-2.compute.internal | egrep 'Capacity|Allocatable|gpu' openshift.com/gpu-accelerator=trueCapacity: nvidia.com/gpu: 2Allocatable: nvidia.com/gpu: 2 nvidia.com/gpu 0 0

この例では、2 つの GPU が利用可能です。

2. namespace nvidia にクォータを設定します。この例では、クォータは 1 です。

# cat gpu-quota.yaml


211

apiVersion: v1kind: ResourceQuotametadata: name: gpu-quota namespace: nvidiaspec: hard: requests.nvidia.com/gpu: 1

3. クォータを作成します。

# oc create -f gpu-quota.yamlresourcequota/gpu-quota created

4. namespace に正しいクォータが設定されていることを確認します。

# oc describe quota gpu-quota -n nvidiaName: gpu-quotaNamespace: nvidiaResource Used Hard-------- ---- ----requests.nvidia.com/gpu 0 1

5. 単一 GPU を要求する Pod を実行します。

# oc create pod gpu-pod.yaml

apiVersion: v1kind: Podmetadata: generateName: gpu-pod- namespace: nvidiaspec: restartPolicy: OnFailure containers: - name: rhel7-gpu-pod image: rhel7 env: - name: NVIDIA_VISIBLE_DEVICES value: all - name: NVIDIA_DRIVER_CAPABILITIES value: "compute,utility" - name: NVIDIA_REQUIRE_CUDA value: "cuda>=5.0"

command: ["sleep"] args: ["infinity"]

resources: limits: nvidia.com/gpu: 1

6. Pod が実行されていることを確認します。


212

# oc get podsNAME READY STATUS RESTARTS AGEgpu-pod-s46h7 1/1 Running 0 1m

7. クォータ Used のカウンターが正しいことを確認します。

# oc describe quota gpu-quota -n nvidiaName: gpu-quotaNamespace: nvidiaResource Used Hard-------- ---- ----requests.nvidia.com/gpu 1 1

8. nvidia namespace で 2 番目の GPU Pod の作成を試行します。2 つの GPU があるので、これをノード上で実行することは可能です。

# oc create -f gpu-pod.yamlError from server (Forbidden): error when creating "gpu-pod.yaml": pods "gpu-pod-f7z2w" is forbidden: exceeded quota: gpu-quota, requested: requests.nvidia.com/gpu=1, used: requests.nvidia.com/gpu=1, limited: requests.nvidia.com/gpu=1

クォータが 1 GPU であり、この Pod がそのクォータを超える 2 つ目の GPU の割り当てを試行したため、Forbidden エラーメッセージが表示されることが予想されます。

17.3. クォータのスコープ

各クォータにはスコープのセットが関連付けられます。クォータは、列挙されたスコープの交差部分に一致する場合にのみリソースの使用状況を測定します。

スコープをクォータに追加すると、クォータが適用されるリソースのセットを制限できます。許可されるセット以外のリソースを設定すると、検証エラーが発生します。

スコープスコープ説明説明

Terminating spec.activeDeadlineSeconds >= 0 の Pod に一致します。

NotTerminating spec.activeDeadlineSeconds が nil の Pod に一致します。

BestEffort cpu または memory のいずれかの QoS (Quality of Service) が Best Effort のPod に一致します。コンピュートリソースのコミットについての詳細は、「QoS (Quality of Service) クラス」を参照してください。

NotBestEffort cpu および memory の QoS (Quality of Service) が Best Effort でない Pod に一致します。

BestEffort スコープは、以下のリソースを制限するようにクォータを制限します。

pods

Terminating、NotTerminating、および NotBestEffort スコープは、以下のリソースを追跡するようにクォータを制限します。


213

pods

memory

requests.memory

limits.memory

cpu

requests.cpu

limits.cpu

ephemeral-storage

requests.ephemeral-storage

limits.ephemeral-storage

注記注記

一時ストレージ要求と制限は、テクノロジープレビューとして提供されている一時ストレージを有効にした場合にのみ適用されます。この機能はデフォルトでは無効になっています。

17.4. クォータの実施

プロジェクトのリソースクォータが最初に作成されると、プロジェクトは、更新された使用状況の統計が計算されるまでクォータ制約の違反を引き起こす可能性のある新規リソースの作成機能を制限します。

クォータが作成され、使用状況の統計が更新されると、プロジェクトは新規コンテンツの作成を許可します。リソースを作成または変更する場合、クォータの使用量はリソースの作成または変更要求があるとすぐに増分します。

リソースを削除する場合、クォータの使用量は、プロジェクトのクォータ統計の次回の完全な再計算時に減分されます。設定可能な時間を指定して、クォータ使用量の統計値を現在確認されるシステム値まで下げるのに必要な時間を決定します。

プロジェクト変更がクォータ使用制限を超える場合、サーバーはそのアクションを拒否し、クォータ制約を違反していること、およびシステムで現在確認される使用量の統計値を示す適切なエラーメッセージがユーザーに返されます。

17.5. 要求 VS 制限

コンピュートリソースの割り当て時に、各コンテナーは CPU、メモリー、一時ストレージのそれぞれに要求値と制限値を指定できます。クォータはこれらの値を制限できます。

クォータに requests.cpu または requests.memory の値が指定されている場合、すべての着信コンテナーがそれらのリソースを明示的に要求することが求められます。クォータに limits.cpu または limits.memory の値が指定されている場合、すべての着信コンテナーがそれらのリソースの明示的な制限を指定することが求められます。

17.6. リソースクォータ定義のサンプル


214

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-compute-resources

1

2

3

4

5

1

core-object-counts.yaml

プロジェクトに存在できる ConfigMap オブジェクトの合計数です。


プロジェクトに存在できるレプリケーションコントローラーの合計数です。

プロジェクトに存在できるシークレットの合計数です。

プロジェクトに存在できるサービスの合計数です。

openshift-object-counts.yaml

プロジェクトに存在できるイメージストリームの合計数です。

compute-resources.yaml

apiVersion: v1kind: ResourceQuotametadata: name: core-object-countsspec: hard: configmaps: "10" 1 persistentvolumeclaims: "4" 2 replicationcontrollers: "20" 3 secrets: "10" 4 services: "10" 5

apiVersion: v1kind: ResourceQuotametadata: name: openshift-object-countsspec: hard: openshift.io/imagestreams: "10" 1

apiVersion: v1kind: ResourceQuotametadata: name: compute-resourcesspec: hard: pods: "4" 1 requests.cpu: "1" 2 requests.memory: 1Gi 3 requests.ephemeral-storage: 2Gi 4 limits.cpu: "2" 5 limits.memory: 2Gi 6 limits.ephemeral-storage: 4Gi 7


215

1

2

3

4

5

6

7

1

2

1

2

プロジェクトに存在できる非終了状態の Pod の合計数です。

非終了状態のすべての Pod において、CPU 要求の合計は 1 コアを超えることができません。

非終了状態のすべての Pod において、メモリー要求の合計は 1 Gi を超えることができません。

非終了状態のすべての Pod において、一時ストレージ要求の合計は 2 Gi を超えることができません。

非終了状態のすべての Pod において、CPU 制限の合計は 2 コアを超えることができません。

非終了状態のすべての Pod において、メモリー制限の合計は 2 Gi を超えることができません。

非終了状態のすべての Pod において、一時ストレージ制限の合計は 4 Gi を超えることができません。

besteffort.yaml

プロジェクトに存在できる QoS (Quality of Service) が BestEffort の非終了状態の Pod の合計数です

クォータを、メモリーまたは CPU のいずれかの QoS (Quality of Service) が BestEffort の一致する Pod のみに制限します。

compute-resources-long-running.yaml

非終了状態の Pod の合計数です。

非終了状態のすべての Pod において、CPU 制限の合計はこの値を超えることができません。

apiVersion: v1kind: ResourceQuotametadata: name: besteffortspec: hard: pods: "1" 1 scopes: - BestEffort 2

apiVersion: v1kind: ResourceQuotametadata: name: compute-resources-long-runningspec: hard: pods: "4" 1 limits.cpu: "4" 2 limits.memory: "2Gi" 3 limits.ephemeral-storage: "4Gi" 4 scopes: - NotTerminating 5


216

3

4

5

1

2

3

4

5

非終了状態のすべての Pod において、メモリー制限の合計はこの値を超えることができません。

非終了状態のすべての Pod において、一時ストレージ制限の合計はこの値を超えることができません。

クォータをspec.activeDeadlineSeconds が nil に設定されている一致する Pod のみに制限します。ビルド Pod は、RestartNever ポリシーが適用されない場合に NotTerminating になります。

compute-resources-time-bound.yaml

非終了状態の Pod の合計数です。

非終了状態のすべての Pod において、CPU 制限の合計はこの値を超えることができません。

非終了状態のすべての Pod において、メモリー制限の合計はこの値を超えることができません。

非終了状態のすべての Pod において、一時ストレージ制限の合計はこの値を超えることができません。

クォータをspec.activeDeadlineSeconds >=0 に設定されている一致する Pod のみに制限します。たとえば、このクォータはビルド Pod またはデプロイヤー Pod に影響を与えますが、webサーバーまたはデータベースなどの長時間実行されない Pod には影響を与えません。

storage-consumption.yaml

apiVersion: v1kind: ResourceQuotametadata: name: compute-resources-time-boundspec: hard: pods: "2" 1 limits.cpu: "1" 2 limits.memory: "1Gi" 3 limits.ephemeral-storage: "1Gi" 4 scopes: - Terminating 5

apiVersion: v1kind: ResourceQuotametadata: name: storage-consumptionspec: hard: persistentvolumeclaims: "10" 1 requests.storage: "50Gi" 2 gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 3 silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 4 silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 5 bronze.storageclass.storage.k8s.io/requests.storage: "0" 6 bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" 7


217

1

2

3

4

5

6

7

プロジェクト内の Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。

プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、要求されるストレージの合計はこの値を超えることができません。

プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、gold ストレージクラスで要求されるストレージの合計はこの値を超えることができません。

プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、silverストレージクラスで要求されるストレージの合計はこの値を超えることができません。

プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、silverストレージクラスの要求の合計数はこの値を超えることができません。

プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、bronzeストレージクラスで要求されるストレージの合計はこの値を超えることができません。これが 0に設定される場合、bronze ストレージクラスはストレージを要求できないことを意味します。

プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、bronzeストレージクラスで要求されるストレージの合計はこの値を超えることができません。これが 0に設定される場合は、bronze ストレージクラスでは要求を作成できないことを意味します。

17.7. クォータの作成

クォータを作成するには、「リソースクォータ定義のサンプル」に示されるように、まずクォータをファイルに定義します。次に、そのファイルを使用してこれをプロジェクトに適用します。

$ oc create -f <resource_quota_definition> [-n <project_name>]

例:

$ oc create -f core-object-counts.yaml -n demoproject

17.7.1. オブジェクトカウントクォータの作成

BuildConfig および DeploymentConfig などの、OpenShift Container Platform の標準的なnamespace を使用しているリソースタイプのすべてにオブジェクトカウントクォータを作成できます。オブジェクトクォータカウントは、定義されたクォータをすべての標準的な namespace を使用しているリソースタイプに設定します。

リソースクォータの使用時に、オブジェクトがサーバーストレージにある場合、そのオブジェクトはクォータに基づいてチャージされます。以下のクォータのタイプはストレージリソースが使い切られることから保護するのに役立ちます。

リソースのオブジェクトカウントクォータを設定するには、以下のコマンドを実行します。

$ oc create quota <name> --hard=count/<resource>.<group>=<quota>,count/<resource>.<group>=<quota>

例:

$ oc create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4


218

resourcequota "test" created

$ oc describe quota testName: testNamespace: quotaResource Used Hard-------- ---- ----count/deployments.extensions 0 2count/pods 0 3count/replicasets.extensions 0 4count/secrets 0 4

この例では、一覧表示されたリソースをクラスター内の各プロジェクトのハード制限に制限します。

17.8. クォータの表示

web コンソールでプロジェクトの Quota ページに移動し、プロジェクトのクォータで定義されるハード制限に関連する使用状況の統計を表示できます。

CLI を使用してクォータの詳細を表示することもできます。

1. 最初に、プロジェクトで定義されたクォータの一覧を取得します。たとえば、demoproject というプロジェクトの場合、以下を実行します。

$ oc get quota -n demoprojectNAME AGEbesteffort 11mcompute-resources 2mcore-object-counts 29m

2. 次に、関連するクォータについて記述します。たとえば、core-object-counts クォータの場合、以下を実行します。

$ oc describe quota core-object-counts -n demoprojectName: core-object-countsNamespace: demoprojectResource Used Hard-------- ---- ----configmaps 3 10persistentvolumeclaims 0 4replicationcontrollers 3 20secrets 9 10services 2 10

17.9. クォータの同期期間の設定

リソースのセットが削除される際に、リソースの同期期間が /etc/origin/master/master-config.yamlファイルの resource-quota-sync-period 設定によって決定されます。

クォータの使用状況が復元される前に、ユーザーがリソースの再使用を試行すると問題が発生する場合があります。resource-quota-sync-period 設定を変更して、リソースセットの再生成が所定の期間 (秒単位) に実行され、リソースを再度利用可能にすることができます。

kubernetesMasterConfig:


219

1

変更後に、マスターサービスを再起動してそれらの変更を適用します。


再生成時間の調整は、リソースの作成および自動化が使用される場合のリソース使用状況の判別に役立ちます。

注記注記

resource-quota-sync-period 設定は、システムパフォーマンスのバランスを取るように設計されています。同期期間を短縮すると、マスターに大きな負荷がかかる可能性があります。

17.10. デプロイメント設定におけるクォータアカウンティング

クォータがプロジェクトに定義されている場合、デプロイメント設定の考慮事項については、「デプロイメントリソース」を参照してください。

17.11. リソース消費における明示的なクォータの要求

リソースがクォータで管理されていない場合、ユーザーには消費できるリソース量の制限がありません。たとえば、gold ストレージクラスに関連するストレージのクォータがない場合、プロジェクトが作成できる gold ストレージの容量はバインドされません。

高コストのコンピュートまたはストレージリソースの場合、管理者はリソースを消費するための明示的なクォータの付与が必要となるようにする場合があります。たとえば、プロジェクトに gold ストレージクラスに関連するストレージのクォータが明示的に付与されていない場合、そのプロジェクトのユーザーはこのタイプのストレージを作成することができません。

特定リソースの消費における明示的なクォータが必要となるようにするには、以下のスタンザをmaster-config.yaml に追加する必要があります。

デフォルトで消費が制限されるグループ/リソースです。

apiLevels: - v1beta3 - v1 apiServerArguments: null controllerArguments: resource-quota-sync-period: - "10s"

admissionConfig: pluginConfig: ResourceQuota: configuration: apiVersion: resourcequota.admission.k8s.io/v1alpha1 kind: Configuration limitedResources: - resource: persistentvolumeclaims 1 matchContains: - gold.storageclass.storage.k8s.io/requests.storage 2


220

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#deployment-resources

2 デフォルトで制限対象となる、グループ/リソースに関連付けられたクォータで追跡されるリソースの名前です。

上記の例では、クォータシステムは PersistentVolumeClaim を作成するか、または更新するすべての操作をインターセプトします。これは、クォータで認識されるリソースが消費されることを確認し、プロジェクトのそれらのリソースのクォータがない場合に要求は拒否されます。この例ではユーザーがgold ストレージクラスに関連付けられたストレージを使用する PersistentVolumeClaim を作成しており、プロジェクトに一致するクォータがない場合には要求が拒否されます。

17.12. 既知の問題

無効なオブジェクトにより、プロジェクトのクォータリソースが使い切られる可能性があります。クォータはリソースの検証前に受付において増分します。その結果、クォータは Pod が最終的に永続しない場合でも増分する可能性があります。この問題は、今後のリリースで解決される予定です。(BZ1485375)


221


1

第18章複数プロジェクトのクォータ設定

18.1. 概要

ClusterResourceQuota オブジェクトで定義される複数プロジェクトのクォータは、クォータを複数プロジェクト間で共有できるようにします。それぞれの選択されたプロジェクトで使用されるリソースは集計され、その集計は選択したすべてのプロジェクトでリソースを制限するために使用されます。

18.2. プロジェクトの選択

プロジェクトは、アノテーションの選択またはラベルの選択のいずれか、またはその両方に基づいて選択できます。たとえば、アノテーションに基づいてプロジェクトを選択するには、以下のコマンドを実行します。

これは以下の ClusterResourceQuota オブジェクトを作成します。

選択したプロジェクトに対して実施される ResourceQuotaSpec オブジェクトです。

$ oc create clusterquota for-user \ --project-annotation-selector openshift.io/requester=<user-name> \ --hard pods=10 \ --hard secrets=20

apiVersion: v1kind: ClusterResourceQuotametadata: name: for-userspec: quota: 1 hard: pods: "10" secrets: "20" selector: annotations: 2 openshift.io/requester: <user-name> labels: null 3status: namespaces: 4 - namespace: ns-one status: hard: pods: "10" secrets: "20" used: pods: "1" secrets: "9" total: 5 hard: pods: "10" secrets: "20" used: pods: "1" secrets: "9"


222

2

3

4

5

1

2

アノテーションの単純なキー/値のセレクターです。

プロジェクトを選択するために使用できるラベルセレクターです。

選択された各プロジェクトの現在のクォータの使用状況を記述する namespace ごとのマップです。

選択されたすべてのプロジェクトにおける使用量の総計です。

この複数プロジェクトのクォータの記述は、デフォルトのプロジェクト要求エンドポイントを使用して<user-name> によって要求されるすべてのプロジェクトを制御します。ここでは、10 Pod および 20シークレットに制限されます。

同様にラベルに基づいてプロジェクトを選択するには、以下のコマンドを実行します。

clusterresourcequota および clusterquota は同じコマンドのエイリアスです。for-name は clusterresourcequota オブジェクトの名前です。

ラベル別にプロジェクトを選択するには、--project-label-selector=key=value 形式を使用してキーと値のペアを指定します。

これは以下の ClusterResourceQuota オブジェクト定義を作成します。

18.3. 適用可能な CLUSTERRESOURCEQUOTAS の表示

プロジェクト管理者は、各自のプロジェクトを制限する複数プロジェクトのクォータを作成したり、変更したりすることはできませんが、それぞれのプロジェクトに適用される複数プロジェクトのクォータを表示することはできます。プロジェクト管理者は、AppliedClusterResourceQuota リソースを使ってこれを実行できます。

以下が生成されます。

$ oc create clusterresourcequota for-name \ 1 --project-label-selector=name=frontend \ 2 --hard=pods=10 --hard=secrets=20

apiVersion: v1kind: ClusterResourceQuotametadata: creationTimestamp: null name: for-namespec: quota: hard: pods: "10" secrets: "20" selector: annotations: null labels: matchLabels: name: frontend

$ oc describe AppliedClusterResourceQuota

第第18章章複数プロジェクトのクォータ設定複数プロジェクトのクォータ設定

223

18.4. 選択における粒度

クォータの割り当てを要求する際にロックに関して考慮する必要があるため、複数プロジェクトのクォータで選択されるアクティブなプロジェクトの数は重要な考慮点になります。単一の複数プロジェクトクォータで 100 を超えるプロジェクトを選択すると、それらのプロジェクトの API サーバーの応答に負の影響が及びます。

Name: for-userNamespace: <none>Created: 19 hours agoLabels: <none>Annotations: <none>Label Selector: <null>AnnotationSelector: map[openshift.io/requester:<user-name>]Resource Used Hard-------- ---- ----pods 1 10secrets 9 20


224

第19章制限範囲の設定

19.1. 概要

LimitRange オブジェクトで定義される制限範囲は、Pod、コンテナー、イメージ、イメージストリーム、および Persistent Volume Claim (永続ボリューム要求、PVC) のレベルでプロジェクトのコンピュートリソース制約を列挙し、Pod、コンテナー、イメージ、イメージストリームまたは PersistentVolume Claim (永続ボリューム要求、PVC) で消費できるリソースの量を指定します。

すべてのリソース作成および変更要求は、プロジェクトの各 LimitRange オブジェクトに対して評価されます。リソースが列挙される制約に違反する場合、そのリソースは拒否されます。リソースが明示的な値を指定しない場合で、制約がデフォルト値をサポートする場合は、デフォルト値がリソースに適用されます。

CPU およびメモリー制限の場合は、max 値を指定し、min 制限を指定しないと、リソースは max 値を超える CPU/メモリーリソースを消費できます。

一時ストレージのテクノロジープレビューを使用して一時ストレージの制限と要求を指定できます。この機能は、デフォルトでは無効になっています。この機能を有効にするには、「configuring forephemeral storage」を参照してください。

コアコア Limit Range オブジェクトの定義オブジェクトの定義

apiVersion: "v1"kind: "LimitRange"metadata: name: "core-resource-limits" 1spec: limits: - type: "Pod" max: cpu: "2" 2 memory: "1Gi" 3 min: cpu: "200m" 4 memory: "6Mi" 5 - type: "Container" max: cpu: "2" 6 memory: "1Gi" 7 min: cpu: "100m" 8 memory: "4Mi" 9 default: cpu: "300m" 10 memory: "200Mi" 11 defaultRequest: cpu: "200m" 12 memory: "100Mi" 13 maxLimitRequestRatio: cpu: "10" 14

第第19章章制限範囲の設定制限範囲の設定

225

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-projects


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-configuring-ephemeral-storage

1

2

3

4

5

6

7

8

9

10

11

12

13

14

制限範囲オブジェクトの名前です。

すべてのコンテナーにおいて Pod がノードで要求できる CPU の最大量です。

すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最大量です。

すべてのコンテナーにおいて Pod がノードで要求できる CPU の最小量です。 min 値を設定しないか、または 0 を設定する場合は無制限となり、Pod が max 値を超える量を消費することが許可されます。

すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最小量です。min 値を設定しないか、または 0 を設定する場合は無制限となり、Pod が max 値を超える量を消費することが許可されます。

Pod の単一コンテナーが要求できる CPU の最大量です。

Pod の単一コンテナーが要求できるメモリーの最大量です。

Pod の単一コンテナーが要求できる CPU の最小量です。 min 値を設定しないか、または 0 を設定する場合は無制限となり、Pod が max 値を超える量を消費することが許可されます。

Pod の単一コンテナーが要求できるメモリーの最小量です。 min 値を設定しないか、または 0 を設定する場合は無制限となり、Pod が max 値を超える量を消費することが許可されます。

指定がない場合、コンテナーによる使用を制限する CPU のデフォルト量です。

コンテナーによる使用を制限するメモリーのデフォルト量です (指定がない場合)。

コンテナーが使用を要求する CPU のデフォルト量です (指定がない場合)。

コンテナーが使用を要求するメモリーのデフォルト量です (指定がない場合)。

制限の要求に対する比率でコンテナーで実行できる CPU バーストの最大量です。

CPU およびメモリーの測定方法についての詳細は、「コンピュートリソース」を参照してください。

OpenShift Container Platform のの Limit Range オブジェクトの定義オブジェクトの定義

apiVersion: "v1"kind: "LimitRange"metadata: name: "openshift-resource-limits"spec: limits: - type: openshift.io/Image max: storage: 1Gi 1 - type: openshift.io/ImageStream max: openshift.io/image-tags: 20 2 openshift.io/images: 30 3 - type: "Pod" max: cpu: "2" 4 memory: "1Gi" 5


226


1

2

3

4

5

6

7

8

内部レジストリーにプッシュできるイメージの最大サイズです。

イメージストリームの仕様に基づく一意のイメージタグの最大数です。

イメージストリームのステータスに基づく一意のイメージ参照の最大数です。

すべてのコンテナーにおいて Pod がノードで要求できる CPU の最大量です。

すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最大量です。

一時ストレージのテクノロジープレビュー機能が有効にされる場合に、すべてのコンテナーにおいて Pod がノードで要求できる一時ストレージの最大量です。

すべてのコンテナーにおいて Pod がノードで要求できる CPU の最小量です。 min 値を設定しないか、または 0 を設定する場合は無制限となり、Pod が max 値を超える量を消費することが許可されます。

すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最小量です。min 値を設定しないか、または 0 を設定する場合は無制限となり、Pod が max 値を超える量を消費することが許可されます。

コアおよび OpenShift Container Platform リソースのどちらも単一の制限範囲オブジェクトで指定できます。ここでは明確にする目的でこれらを 2 つのサンプルに分けています。

19.1.1. コンテナーの制限

サポートされるリソース:

CPU

メモリー

サポートされる制約:

コンテナーごとに設定されます。指定される場合、以下を満たしている必要があります。

表19.1 コンテナー

制約制約動作動作

Min Min[resource]: container.resources.requests[resource] (必須) または container/resources.limits[resource] (オプション) 以下

設定で min CPU を定義している場合、要求値は CPU 値よりも大きくなければなりません。 min 値を設定しないか、または 0 を設定する場合は無制限となり、Pod が max 値を超える量を消費することが許可されます。

ephemeral-storage: "1Gi" 6 max: cpu: "1" 7 memory: "1Gi" 8


227

Max container.resources.limits[resource] (必須): Max[resource] 以下

設定で max CPU を定義している場合、要求値を定義する必要はありませんが、CPU 制約の最大値の条件を満たす制限値を設定する必要があります。

MaxLimitRequestRatio MaxLimitRequestRatio[resource]: ( container.resources.limits[resource] / container.resources.requests[resource]) 以下

設定で maxLimitRequestRatio 値を定義している場合に、新規コンテナーには要求値および制限値の両方が必要になります。さらに OpenShift ContainerPlatform は、制限を要求で除算して制限の要求に対する比率を算出します。この値は、1 より大きい正の整数でなければなりません。

たとえば、コンテナーのlimit 値が cpu: 500 で、request 値が cpu: 100 である場合、cpu の要求に対する制限の比は 5 になります。この比率は maxLimitRequestRatio より小さいか等しくなければなりません。


サポートされるデフォルト:

Default[resource]

指定がない場合は container.resources.limit[resource] を所定の値にデフォルト設定します。

Default Requests[resource]

指定がない場合は、container.resources.requests[resource] を所定の値にデフォルト設定します。

19.1.2. Pod の制限


CPU

メモリー


Pod のすべてのコンテナーにおいて、以下を満たしている必要があります。

表19.2 Pod

制約制約実施される動作実施される動作

Min Min[resource]: container.resources.requests[resource] (必須) または container.resources.limits[resource] 以下。 min 値を設定しないか、または 0 を設定する場合は無制限となり、Pod が max 値を超える量を消費することが許可されます。

Max container.resources.limits[resource] (必須): Max[resource] 以下。


228

MaxLimitRequestRatio MaxLimitRequestRatio[resource]: ( container.resources.limits[resource] / container.resources.requests[resource]) 以下。


19.1.3. イメージの制限


ストレージ

リソースタイプ名:

openshift.io/Image

イメージごとに設定されます。指定される場合、以下が一致している必要があります。

表19.3 イメージ


Max image.dockerimagemetadata.size: Max[resource] より小さいか等しい

注記注記

制限を超える Blob がレジストリーにアップロードされないようにするために、クォータを実施するようレジストリーを設定する必要があります。環境変数 REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA は true に設定される必要があります。この設定は、新規デプロイメントについてデフォルトで実行されます。

警告警告

イメージのサイズは、アップロードされるイメージのマニフェストで常に表示される訳ではありません。これは、とりわけ Docker 1.10 以上で作成され、v2 レジストリーにプッシュされたイメージの場合に該当します。このようなイメージが古いDocker デーモンでプルされると、イメージマニフェストはレジストリーによってスキーマ v1 に変換されますが、この場合サイズ情報が欠落します。イメージに設定されるストレージの制限がこのアップロードを防ぐことはありません。

現在、この問題への対応が行われています。

19.1.4. イメージストリームの制限



229

https://github.com/openshift/origin/issues/7706

openshift.io/image-tags

openshift.io/images

リソースタイプ名:

openshift.io/ImageStream

イメージストリームごとに設定されます。指定される場合、以下が一致している必要があります。

表19.4 ImageStream


Max[openshift.io/image-tags]

length( uniqueimagetags( imagestream.spec.tags ) ): Max[openshift.io/image-tags] より小さいか等しい

uniqueimagetags は、指定された仕様タグのイメージへの一意の参照を返します。

Max[openshift.io/images]

length( uniqueimages( imagestream.status.tags ) ): Max[openshift.io/images] より小さいか等しい

uniqueimages はステータスタグにある一意のイメージ名を返します。名前はイメージのダイジェストに等しくなります。

19.1.4.1. イメージ参照の数イメージ参照の数

リソース openshift.io/image-tags は、一意のイメージ参照を表します。使用できる参照は、ImageStreamTag、ImageStreamImage および DockerImage になります。それらは oc tag および oc import-image コマンドを使用するか、またはタグのトラッキングを使用して作成されます。内部参照か外部参照であるかの区別はありませんが、イメージストリームの仕様でタグ付けされる一意の参照はそれぞれ 1 回のみカウントされます。この参照は内部コンテナーレジストリーへのプッシュを制限することはありませんが、タグの制限に役立ちます。

リソース openshift.io/images は、イメージストリームのステータスに記録される一意のイメージ名を表します。これにより、内部レジストリーにプッシュできるイメージ数を制限できます。内部参照か外部参照であるかの区別はありません。

19.1.5. PersistentVolumeClaim の制限


ストレージ


プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、以下が一致している必要があります。

表19.5 Pod


230

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#referencing-images-in-image-streams

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#adding-tag

1

2

3


Min Min[resource] ⇐ claim.spec.resources.requests[resource] (必須)

Max claim.spec.resources.requests[resource] (必須) ⇐ Max[resource]

Limit Range オブジェクトの定義オブジェクトの定義

制限範囲オブジェクトの名前です。

Persistent Volume Claim (永続ボリューム要求、PVC) で要求できるストレージの最小量です。

Persistent Volume Claim (永続ボリューム要求、PVC) で要求できるストレージの最大量です。

19.2. 制限範囲の作成

制限範囲をプロジェクトに適用するには、必要な仕様に基づいてファイルシステムで制限範囲オブジェクトの定義を作成します。以下を実行します。

$ oc create -f <limit_range_file> -n <project>

19.3. 制限の表示

web コンソールでプロジェクトの Quota ページに移動し、プロジェクトで定義される制限範囲を表示できます。

CLI を使用して制限範囲の詳細を表示することもできます。

1. まず、プロジェクトで定義される制限範囲の一覧を取得します。たとえば、demoproject というプロジェクトの場合は以下のようになります。

{ "apiVersion": "v1", "kind": "LimitRange", "metadata": { "name": "pvcs" 1 }, "spec": { "limits": [{ "type": "PersistentVolumeClaim", "min": { "storage": "2Gi" 2 }, "max": { "storage": "50Gi" 3 } } ] }}


231

$ oc get limits -n demoprojectNAME AGEresource-limits 6d

2. 次に、関連のある制限範囲の説明を表示します。たとえば、resource-limits 制限範囲の場合は以下のようになります。

$ oc describe limits resource-limits -n demoprojectName: resource-limitsNamespace: demoprojectType Resource Min Max Default Request Default Limit Max Limit/Request Ratio---- -------- --- --- --------------- ------------- -----------------------Pod cpu 200m 2 - - -Pod memory 6Mi 1Gi - - -Container cpu 100m 2 200m 300m 10Container memory 4Mi 1Gi 100Mi 200Mi -openshift.io/Image storage - 1Gi - - -openshift.io/ImageStream openshift.io/image - 12 - - -openshift.io/ImageStream openshift.io/image-tags - 10 - - -

19.4. 制限の削除

プロジェクトの制限を実施しないように有効な制限範囲を削除します。

$ oc delete limits <limit_name>


232

第20章オブジェクトのプルーニング

20.1. 概要

OpenShift Container Platform で作成される API オブジェクトは、一定期間が経過すると、アプリケーションのビルドやデプロイなどの通常のユーザー操作によって etcd データストアに蓄積されます。

管理者は、不要になった古いバージョンのオブジェクトを OpenShift Container Platform インスタンスから定期的にプルーニングできます。たとえば、イメージのプルーニングにより、使用されなくなったものの、ディスク領域を使用している古いイメージや層を削除できます。

20.2. プルーニングの基本操作

CLI は、共通の親コマンドでプルーニング操作を分類します。

$ oc adm prune <object_type> <options>

これにより、以下が指定されます。

groups、builds、deployments、または images などのアクションを実行するための <object_type>。

オブジェクトタイプのプルーニングの実行においてサポートされる <options>。

20.3. グループのプルーニング

グループのレコードを外部プロバイダーからプルーニングするために、管理者は以下のコマンドを実行できます。

$ oc adm prune groups --sync-config=path/to/sync/config [<options>]

表20.1 グループのプルーニング用の CLI の設定オプション

オプションオプション説明説明

--confirm ドライランの実行ではなく、プルーニングが実行されることを示します。

--blacklist グループのブラックリストファイルへのパスです。ブラックリストファイルの構造については、「Syncing Groups With LDAP」を参照してください。

--whitelist グループのホワイトリストファイルへのパスです。ホワイトリストファイルの構造については、「Syncing Groups With LDAP」を参照してください。

--sync-config 同期設定ファイルへのパスです。このファイルの構造については、「Configuring LDAP Sync」を参照してください。

prune コマンドが削除するグループを表示するには、以下を実行します。

第第20章章オブジェクトのプルーニングオブジェクトのプルーニング

233

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#architecture-core-concepts-index

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#master

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#overview

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#overview

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#configuring-ldap-sync

$ oc adm prune groups --sync-config=ldap-sync-config.yaml

prune 操作を実行するには、以下を実行します。

$ oc adm prune groups --sync-config=ldap-sync-config.yaml --confirm

20.4. デプロイメントのプルーニング

使用年数やステータスによりシステムで不要となったデプロイメントをプルーニングするために、管理者は以下のコマンドを実行できます。

$ oc adm prune deployments [<options>]

表20.2 デプロイメントのプルーニング用の CLI の設定オプション



--orphans デプロイメント設定が存在せず、ステータスが complete (完了) またはfailed (失敗) で、レプリカ数がゼロであるすべてのデプロイメントをプルーニングします。

--keep-complete=<N> デプロイメント設定に基づき、ステータスが complete (完了) で、レプリカ数がゼロである最後の N デプロイメントを保持します (デフォルト: 5)。

--keep-failed=<N> デプロイメント設定に基づき、ステータスが failed (失敗) で、レプリカ数がゼロである最後の N デプロイメントを保持します (デフォルト: 1)。

--keep-younger-than=<duration>

現在の時間との対比で <duration> 未満の新しいオブジェクトはプルーニングしません (デフォルト: 60m)。有効な測定単位には、ナノ秒(ns)、マイクロ秒 (us)、ミリ秒 (ms)、秒 (s)、分 (m)、および時間 (h)が含まれます。

プルーニング操作によって削除されるものを確認するには、以下を実行します。

$ oc adm prune deployments --orphans --keep-complete=5 --keep-failed=1 \ --keep-younger-than=60m

プルーニング操作を実際に実行するには、以下を実行します。

$ oc adm prune deployments --orphans --keep-complete=5 --keep-failed=1 \ --keep-younger-than=60m --confirm

20.5. ビルドのプルーニング

使用年数やステータスによりシステムで不要となったビルドをプルーニングするために、管理者は以下のコマンドを実行できます。


234

$ oc adm prune builds [<options>]

表20.3 ビルドのプルーニング用の CLI の設定オプション



--orphans ビルド設定が存在せず、ステータスが complete (完了)、failed (失敗)、error (エラー)、または canceled (中止) のすべてのビルドをプルーニングします。

--keep-complete=<N> ビルド設定に基づき、ステータスが complete (完了) の最後の N ビルドを保持します (デフォルト: 5)。

--keep-failed=<N> ビルド設定に基づき、ステータスが failed (失敗)、error (エラー)、または canceled (中止) の最後の N ビルドを保持します (デフォルト: 1)。


現在の時間との対比で <duration> 未満の新しいオブジェクトはプルーニングしません (デフォルト: 60m)。


$ oc adm prune builds --orphans --keep-complete=5 --keep-failed=1 \ --keep-younger-than=60m

プルーニング操作を実際に実行するには、以下を実行します。

$ oc adm prune builds --orphans --keep-complete=5 --keep-failed=1 \ --keep-younger-than=60m --confirm

注記注記

開発者は、ビルド設定を変更することにより、自動ビルドプルーニングを有効にできます。

20.6. イメージのプルーニング

使用年数やステータスまたは制限の超過によりシステムで不要となったイメージをプルーニングするために、管理者は以下のコマンドを実行できます。

$ oc adm prune images [<options>]

注記注記

現時点でイメージをプルーニングするには、まずアクセストークンを使ってユーザーとして CLI にログインする必要があります。また、ユーザーにはクラスターロール(system:image-pruner) 以上のロールがなければなりません (例: cluster-admin)。


235

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#build-pruning

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#oauth

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cli_reference/#basic-setup-and-login


注記注記

--prune-registry=false が使用されていない限り、イメージのプルーニングにより、統合レジストリーのデータが削除されます。この操作が適切に機能するには、storage:delete:enabled が true に設定された状態でのレジストリーの設定を確認します。

注記注記

--namespace フラグの付いたイメージをプルーニングしてもイメージは削除されず、イメージストリームのみが削除されます。イメージは namespace を使用しないリソースです。そのため、プルーニングを特定の namespace に制限すると、イメージの現在の使用量を算出できなくなります。

デフォルトで、統合レジストリーは Blob メタデータをキャッシュしてストレージに対する要求数を減らし、要求の処理速度を高めます。プルーニングによって統合レジストリーのキャッシュが更新されることはありません。プルーニング後にプッシュされる、プルーニングされた層を含むイメージは破損します。キャッシュにメタデータを持つプルーニングされた層はプッシュされないためです。したがって、プルーニング後はキャッシュをクリアする必要があります。これは、レジストリーの再デプロイによって実行できます。

$ oc rollout latest dc/docker-registry

統合レジストリーが Redis キャッシュを使用する場合は、データベースを手動でクリーンアップする必要があります。

プルーニング後にレジストリーを再デプロイするオプションを実行できない場合は、キャッシュを永久に無効にする必要があります。

表20.4 イメージのプルーニング用の CLI の設定オプション


--all レジストリーにプッシュされていないものの、プルスルー (pullthrough)でミラーリングされたイメージを組み込みます。これはデフォルトでオンに設定されます。プルーニングを統合レジストリーにプッシュされたイメージに制限するには、--all=false を渡します。

--certificate-authority OpenShift Container Platform で管理されるレジストリーと通信する際に使用する認証局ファイルへのパスです。デフォルトは現行ユーザーの設定ファイルの認証局データに設定されます。これが指定されている場合、セキュアな通信が実行されます。

--confirm ドライランを実行する代わりにプルーニングが実行されることを示します。これには、統合コンテナーイメージレジストリーへの有効なルートが必要になります。このコマンドがクラスターネットワーク外で実行される場合、ルートは --registry-url を使用して指定される必要があります。

--force-insecure このオプションは注意して使用してください。このオプションは注意して使用してください。 HTTP 経由でホストされているか、または無効な HTTPS 証明書を持つ Docker レジストリーへの非セキュアな接続を許可します。詳細は、「セキュアまたは非セキュアな接続の使用」を参照してください。


236

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#docker-registry-configuration-reference-storage

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#docker-registry-configuration-reference-redis

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#docker-registry-configuration-reference-cache

--keep-tag-revisions=<N> それぞれのイメージストリームについては、タグごとに最大 N のイメージリビジョンを保持します (デフォルト: 3)。


現在の時間との対比で <duration> 未満の新しいイメージはプルーニングしません。現在の時間との対比で <duration> 未満の他のオブジェクトで参照されるイメージはプルーニングしません (デフォルト: 60m)。

--prune-over-size-limit 同じプロジェクトに定義される最小の制限を超える各イメージをプルーニングします。このフラグは --keep-tag-revisions または --keep-younger-than と共に使用することはできません。

--registry-url レジストリーと通信する際に使用するアドレスです。このコマンドは、管理されるイメージおよびイメージストリームから判別されるクラスター内の URL の使用を試行します。これに失敗する (レジストリーを解決できないか、これにアクセスできない) 場合、このフラグを使用して他の機能するルートを指定する必要があります。レジストリーのホスト名の前には、特定の接続プロトコルを実施する https:// または http://を付けることができます。

--prune-registry 他のオプションで規定される条件と共に、このオプションは、OpenShift Container Platform イメージ API オブジェクトに対応するレジストリーのデータがプルーニングされるかどうかを制御します。デフォルトで、イメージのプルーニングは、イメージ API オブジェクトとレジストリーの対応するデータの両方を処理します。このオプションは、イメージオブジェクトの数を減らすなどの目的で etcd の内容のみを削除することを検討していて、レジストリーのストレージのクリーンアップは検討していない場合や、レジストリーの適切なメンテナンス期間中などにレジストリーのハードプルーニングによってこれを別途実行しようとする場合に役立ちます。


20.6.1. イメージのプルーニングの各種条件

--keep-younger-than 分前よりも後に作成され、現時点で以下によって参照されていない「OpenShift Container Platform で管理される」イメージ (アノテーション openshift.io/image.managed を持つイメージ) を削除します。

--keep-younger-than 分前よりも後に作成された Pod。

--keep-younger-than 分前よりも後に作成されたイメージストリーム。

実行中の Pod。

保留中の Pod。

レプリケーションコントローラー。

デプロイメント設定。

ビルド設定。

ビルド。


237

stream.status.tags[].items の --keep-tag-revisions の最新のアイテム。

同じプロジェクトで定義される最小の制限を超えており、現時点で以下によって参照されていない「OpenShift Container Platform で管理される」イメージ (アノテーション openshift.io/image.managed を持つイメージ) を削除します。

実行中の Pod。

保留中の Pod。

レプリケーションコントローラー。

デプロイメント設定。

ビルド設定。

ビルド。

外部レジストリーからのプルーニングはサポートされていません。

イメージがプルーニングされる際、イメージのすべての参照は status.tags にイメージの参照を持つすべてのイメージストリームから削除されます。

イメージによって参照されなくなったイメージ層も削除されます。

注記注記

--prune-over-size-limit は --keep-tag-revisions または --keep-younger-than フラグと共に使用することができません。これを実行すると、この操作が許可されないことを示す情報が返されます。

注記注記

--prune-registry=false とその後にレジストリーのハードプルーニングを実行することで、OpenShift Container Platform イメージ API オブジェクトの削除とイメージデータのレジストリーからの削除を分離することができます。これによりタイミングウィンドウが制限され、1 つのコマンドで両方をプルーニングする場合よりも安全に実行できるようになります。ただし、タイミングウィンドウを完全に取り除くことはできません。

たとえばプルーニングの実行時にプルーニング対象のイメージを特定する場合も、そのイメージを参照する Pod を引き続き作成することができます。また、プルーニングの操作時にイメージを参照している可能性のある API オブジェクトを追跡することもできます。これにより、削除されたコンテンツの参照に関連して発生する可能性のある問題を軽減することができます。

また、--prune-registry オプションを指定しないか、または --prune-registry=true を指定してプルーニングを再実行しても、--prune-registry=false を指定して以前にプルーニングされたイメージの、イメージレジストリー内で関連付けられたストレージがプルーニングされる訳ではないことに注意してください。--prune-registry=false を指定してプルーニングされたすべてのイメージは、レジストリーのハードプルーニングによってのみ削除できます。


1. 最高 3 つのタグリビジョンを保持し、6 分前よりも後に作成されたリソース (イメージ、イメージストリームおよび Pod) を保持します。


238

$ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m

2. 定義された制限を超えるすべてのイメージをプルーニングします。

$ oc adm prune images --prune-over-size-limit

前述のオプションでプルーニング操作を実際に実行するには、以下を実行します。

$ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m --confirm

$ oc adm prune images --prune-over-size-limit --confirm

20.6.2. セキュアまたは非セキュアな接続の使用

セキュアな通信の使用は優先され、推奨される方法です。これは、必須の証明書検証と共に HTTPS 経由で実行されます。prune コマンドは、可能な場合は常にセキュアな通信の使用を試行します。これを使用できない場合には、非セキュアな通信にフォールバックすることがあり、これには危険が伴います。この場合、証明書検証は省略されるか、または単純な HTTP プロトコルが使用されます。

非セキュアな通信へのフォールバックは、--certificate-authority が指定されていない場合、以下のケースで可能になります。

1. prune コマンドが --force-insecure オプションと共に実行される。

2. 指定される registry-url の前に http:// スキームが付けられる。

3. 指定される registry-url がローカルリンクアドレスまたは localhost である。

4. 現行ユーザーの設定が非セキュアな接続を許可する。これは、ユーザーが --insecure-skip-tls-verify を使用してログインするか、またはプロンプトが出される際に非セキュアな接続を選択することによって生じる可能性があります。

重要重要

レジストリーのセキュリティーが、OpenShift Container Platform で使用されるものとは異なる認証局で保護される場合、これを --certificate-authority フラグを使用して指定する必要があります。そうしないと、prune コマンドは、「正しくない認証局の使用」または「セキュリティーが保護されたレジストリーに対する非セキュアな接続の使用」で一覧表示されているエラーと同様のエラーを出して失敗します。

20.6.3. イメージのプルーニングに関する問題

イメージがプルーニングされないイメージが蓄積し続け、prune コマンドが予想よりも小規模な削除を実行する場合、プルーニング候補のイメージについて満たすべき条件があることを確認します。

とくに削除する必要のあるイメージが、それぞれのタグ履歴において選択したタグリビジョンのしきい値よりも高い位置にあることを確認します。たとえば、sha:abz という名前の古く陳腐化したイメージがあるとします。イメージがタグ付けされている namespace N で以下のコマンドを実行すると、イメージが myapp という単一イメージストリームで 3 回タグ付けされていることに気づかれるでしょう。

$ image_name="sha:abz"$ oc get is -n openshift -o go-template='{{range $isi, $is := .items}}{{range $ti, $tag := $is.status.tags}}


239

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#image-stream-tag

{{range $ii, $item := $tag.items}}{{if eq $item.image "'$image_name'"}}{{$is.metadata.name}}:{{$tag.tag}} at position {{$ii}} out of {{len $tag.items}}{{end}}{{end}}{{end}}{{end}}' # Before this place {{end}}{{end}}{{end}}{{end}}, use new linemyapp:v2 at position 4 out of 5myapp:v2.1 at position 2 out of 2myapp:v2.1-may-2016 at position 0 out of 1

デフォルトオプションが使用される場合、イメージは myapp:v2.1-may-2016 タグの履歴の 0 の位置にあるためプルーニングされません。イメージがプルーニングの対象と見なされるようにするには、管理者は以下を実行する必要があります。

1. oc adm prune images コマンドで --keep-tag-revisions=0 を指定します。

注意注意

このアクションを実行すると、イメージが指定されたしきい値よりも新しいか、またはこれよりも新しいオブジェクトによって参照されていない限り、すべてのタグが基礎となるイメージと共にすべての namespace から削除されます。

2. リビジョンのしきい値より下にあるすべての istag、つまり myapp:v2.1 および myapp:v2.1-may-2016 を削除します。

3. 同じ istag にプッシュする新規ビルドを実行するか、または他のイメージをタグ付けしてイメージを履歴内でさらに移動させます。ただし、これは古いリリースタグの場合には常に適切な操作となる訳ではありません。

特定のイメージのビルド日時が名前の一部になっているタグは、その使用を避ける必要があります (イメージが未定義の期間保持される必要がある場合を除きます)。このようなタグは履歴内で 1 つのイメージのみに関連付けられる可能性があり、その場合にこれらをプルーニングできなくなります。詳細は、istag の命名規則を参照してください。

非セキュアなレジストリーに対するセキュアな接続の使用oc adm prune images の出力で以下のようなメッセージが表示される場合、レジストリーのセキュリティーは保護されておらず、oc adm prune images クライアントがセキュアな接続の使用を試行することを示しています。

error: error communicating with registry: Get https://172.30.30.30:5000/healthz: http: server gave HTTP response to HTTPS client

1. 推奨される解決法として、レジストリーのセキュリティーを保護することができます。これが必要でない場合には、--force-insecure をコマンドに追加して、クライアントに対して非セキュアな接続の使用を強制することができます (これは推奨される方法ではありません)｡

20.6.3.1. セキュリティーが保護されたレジストリーに対する非セキュアな接続の使用セキュリティーが保護されたレジストリーに対する非セキュアな接続の使用

oc adm prune images コマンドの出力に以下のエラーのいずれかが表示される場合、レジストリーのセキュリティー保護に使用されている認証局で署名された証明書が、接続の検証用に oc adm prune images クライアントで使用されるものとは異なることを意味します。

error: error communicating with registry: Get http://172.30.30.30:5000/healthz: malformed HTTP response "\x15\x03\x01\x00\x02\x02"error: error communicating with registry: [Get https://172.30.30.30:5000/healthz: x509: certificate signed by unknown authority, Get http://172.30.30.30:5000/healthz: malformed HTTP response "\x15\x03\x01\x00\x02\x02"]


240


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#tag-naming

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#securing-the-registry

デフォルトでは、ユーザーの接続ファイルに保存されている認証局データが使用されます。これはマスター API との通信の場合も同様です。

--certificate-authority オプションを使用してコンテナーイメージレジストリーサーバーに適切な認証局を指定します。

正しくない認証局の使用以下のエラーは、セキュリティーが保護されたコンテナーイメージレジストリーの証明書の署名に使用される認証局がクライアントで使用される認証局とは異なることを示しています。

error: error communicating with registry: Get https://172.30.30.30:5000/: x509: certificate signed by unknown authority

フラグ --certificate-authority を使用して適切な認証局を指定します。

回避策として、--force-insecure フラグを代わりに追加することもできます (推奨される方法ではありません)。

20.7. レジストリーのハードプルーニング

OpenShift Container レジストリーは、OpenShift Container Platform クラスターの etcd で参照されない Blob を蓄積します。基本的なイメージプルーニングの手順はこれらに対応しません。これらの Blobは孤立した Blob と呼ばれています。

孤立した Blob は以下のシナリオで発生する可能性があります。

oc delete image <sha256:image-id> コマンドを使ってイメージを手動で削除すると、etcd のイメージのみが削除され、レジストリーのストレージからは削除されない。

docker デーモンの障害によって生じるレジストリーへのプッシュにより、一部の Blob はアップロードされるものの、(最後のコンポーネントとしてアップロードされる) イメージマニフェストはアップロードされない。固有のイメージ Blob すべては孤立する。

OpenShift Container Platform がクォータの制限によりイメージを拒否する。

標準のイメージプルーナーがイメージマニフェストを削除するが、関連する Blob を削除する前に中断される。

対象の Blob を削除できないというレジストリープルーナーのバグにより、それらを参照するイメージオブジェクトは削除されるが、Blob は孤立する。

基本的なイメージプルーニングとは異なるレジストリーのハードプルーニングにより、孤立した Blobを削除することができます。OpenShift Container レジストリーのストレージ領域が不足している場合や、孤立した Blob があると思われる場合にはハードプルーニングを実行する必要があります。

これは何度も行う操作ではなく、多数の孤立した Blob が新たに作成されているという証拠がある場合にのみ実行する必要があります。または、(作成されるイメージの数によって異なりますが) 1 日 1 回などの定期的な間隔で標準のイメージプルーニングを実行することもできます。

孤立した Blob をレジストリーからハードプルーニングするには、以下を実行します。

1. ログイン: CLI を使用し、アクセストークンを持つユーザーとしてログインします。

2. 基本的なイメージプルーニングの実行: 基本的なイメージプルーニングにより、不要になった追加のイメージが削除されます。ハードプルーニングによってイメージが削除される訳ではなく、レジストリーストレージに保存された Blob のみが削除されます。したがって、ハードプ


241

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cli_reference/#basic-setup-and-login

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#oauth

ルーニングの実行前にこれを実行する必要があります。手順については、「イメージのプルーニング」を参照してください。

3. レジストリーの読み取り専用モードへの切り替え: レジストリーが読み取り専用モードで実行されていない場合、プルーニングと同時に実行されているプッシュの結果は以下のいずれかになります。

失敗する。さらに孤立した Blob が新たに発生する。

成功する。ただし、(参照される Blob の一部が削除されたため) イメージをプルできない。

プッシュは、レジストリーが読み取り書き込みモードに戻されるまで成功しません。したがって、ハードプルーニングは注意してスケジューリングする必要があります。

レジストリーを読み取り専用モードに切り換えるには、以下を実行します。

a. 以下の環境変数を設定します。

$ oc set env -n default \ dc/docker-registry \ 'REGISTRY_STORAGE_MAINTENANCE_READONLY={"enabled":true}'

b. デフォルトで、レジストリーは直前の手順が完了すると自動的に再デプロイするはずです。再デプロイが完了するのを待機してから次に進んでください。ただし、これらのトリガーを無効にしている場合は、レジストリーを手動で再デプロイし、新規の環境変数が選択されるようにする必要があります。

$ oc rollout -n default \ latest dc/docker-registry

4. system:image-pruner ロールの追加: 一部のリソースを一覧表示するには、レジストリーインスタンスの実行に使用するサービスアカウントに追加のパーミッションが必要になります。

a. サービスアカウント名を取得します。

$ service_account=$(oc get -n default \ -o jsonpath=$'system:serviceaccount:{.metadata.namespace}:{.spec.template.spec.serviceAccountName}\n' \ dc/docker-registry)

b. system:image-pruner クラスターロールをサービスアカウントに追加します。

$ oc adm policy add-cluster-role-to-user \ system:image-pruner \ ${service_account}

5. (オプション) プルーナーのドライランモードでの実行: 削除される Blob の数を確認するには、ドライランモードでハードプルーナーを実行します。これにより変更が加えられることはありません。

$ oc -n default \ exec -i -t "$(oc -n default get pods -l deploymentconfig=docker-registry \ -o jsonpath=$'{.items[0].metadata.name}\n')" \ -- /usr/bin/dockerregistry -prune=check


242

または、プルーニング候補の実際のパスを取得するには、ロギングレベルを上げます。

$ oc -n default \ exec "$(oc -n default get pods -l deploymentconfig=docker-registry \ -o jsonpath=$'{.items[0].metadata.name}\n')" \ -- /bin/sh \ -c 'REGISTRY_LOG_LEVEL=info /usr/bin/dockerregistry -prune=check'

出力サンプル出力サンプル (切り捨て済み切り捨て済み)

$ oc exec docker-registry-3-vhndw \ -- /bin/sh -c 'REGISTRY_LOG_LEVEL=info /usr/bin/dockerregistry -prune=check'

time="2017-06-22T11:50:25.066156047Z" level=info msg="start prune (dry-run mode)" distribution_version="v2.4.1+unknown" kubernetes_version=v1.6.1+$Format:%h$ openshift_version=unknowntime="2017-06-22T11:50:25.092257421Z" level=info msg="Would delete blob: sha256:00043a2a5e384f6b59ab17e2c3d3a3d0a7de01b2cabeb606243e468acc663fa5" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6time="2017-06-22T11:50:25.092395621Z" level=info msg="Would delete blob: sha256:0022d49612807cb348cabc562c072ef34d756adfe0100a61952cbcb87ee6578a" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6time="2017-06-22T11:50:25.092492183Z" level=info msg="Would delete blob: sha256:0029dd4228961086707e53b881e25eba0564fa80033fbbb2e27847a28d16a37c" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6time="2017-06-22T11:50:26.673946639Z" level=info msg="Would delete blob: sha256:ff7664dfc213d6cc60fd5c5f5bb00a7bf4a687e18e1df12d349a1d07b2cf7663" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6time="2017-06-22T11:50:26.674024531Z" level=info msg="Would delete blob: sha256:ff7a933178ccd931f4b5f40f9f19a65be5eeeec207e4fad2a5bafd28afbef57e" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6time="2017-06-22T11:50:26.674675469Z" level=info msg="Would delete blob: sha256:ff9b8956794b426cc80bb49a604a0b24a1553aae96b930c6919a6675db3d5e06" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6...Would delete 13374 blobsWould free up 2.835 GiB of disk spaceUse -prune=delete to actually delete the data

6. ハードプルーニングの実行: ハードプルーニングを実行するには、docker-registry Pod の実行中インスタンスで以下のコマンドを実行します。

$ oc -n default \ exec -i -t "$(oc -n default get pods -l deploymentconfig=docker-registry -o jsonpath=$'{.items[0].metadata.name}\n')" \ -- /usr/bin/dockerregistry -prune=delete

出力サンプル出力サンプル

$ oc exec docker-registry-3-vhndw \ -- /usr/bin/dockerregistry -prune=delete

Deleted 13374 blobsFreed up 2.835 GiB of disk space


243

7. レジストリーを読み取り書き込みモードに戻す: プルーニングの終了後は、以下を実行してレジストリーを読み取り書き込みモードに戻すことができます。

$ oc set env -n default dc/docker-registry REGISTRY_STORAGE_MAINTENANCE_READONLY-

20.8. CRON ジョブのプルーニング

重要重要

cron ジョブについては、現時点ではテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。


cron ジョブは正常なジョブのプルーニングを実行できますが、失敗したジョブを適切に処理しない可能性があります。そのため、クラスター管理者は定期的なジョブのクリーンアップを手動で実行する必要があります。また、信頼できるユーザーの小規模なグループに cron ジョブへのアクセスを制限し、cron ジョブでジョブや Pod が作成され過ぎないように適切なクォータを設定することも推奨されます。


244


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#cleaning-up-after-a-cron-job

第21章カスタムリソースによる KUBERNETES API の拡張

21.1. KUBERNETES カスタムリソース定義

Kubernetes API では、リソースは特定の種類の API オブジェクトのコレクションを保管するエンドポイントです。たとえば、ビルトインされた Pod リソースには Pod オブジェクトのコレクションが含まれます。

カスタムリソースは、Kubernetes API を拡張するか、またはプロジェクトまたはクラスターに独自のAPI を導入することを可能にするオブジェクトです。

カスタムリソース定義 (CRD) ファイルは、独自のオブジェクトの種類を定義し、API サーバーがライフサイクル全体を処理できるようにします。CRD をクラスターにデプロイすると、Kubernetes API サーバーは指定されたカスタムリソースを提供し始めます。

新規のカスタムリソース定義 (CRD) の作成時に、Kubernetes API サーバーは、クラスター全体または単一プロジェクト (namespace) でアクセスできる新規 RESTful リソースパスを作成することによって応答します。既存のビルトインオブジェクトの場合のように、プロジェクトを削除すると、そのプロジェクトのすべてのカスタムオブジェクトが削除されます。

CRD へのアクセスをユーザーに付与する場合、クラスターロールの集計により、管理、編集、または表示のデフォルトクラスターロールを持つユーザーにアクセスを付与します。また、クラスターロールの集計により、カスタムポリシールールをこれらのクラスターロールに挿入することができます。この動作は、これがビルトインリソースであるかのように新規リソースをクラスターの RBAC ポリシーに統合します。

注記注記

クラスター管理者のみが CRD を作成できますが、読み取りと書き込みのパーミッションがある場合には、CRD からオブジェクトを作成できます。

21.2. カスタムリソース定義の作成

カスタムオブジェクトを作成するには、まずカスタムリソース定義 (CRD) を作成する必要があります。

注記注記

クラスター管理者のみが CRD を作成できます。

手順手順CRD を作成するには、以下を実行します。

1. 以下の例のようなフィールドを含む YAML ファイルを作成します。

Example YAML file for a Custom Resource Definition

apiVersion: apiextensions.k8s.io/v1beta1 1kind: CustomResourceDefinitionmetadata: name: crontabs.stable.example.com 2spec: group: stable.example.com 3

第第21章章カスタムリソースによるカスタムリソースによる KUBERNETES API の拡張の拡張

245

1

2

3

4

5

6

7

8

9

apiextensions.k8s.io/v1beta1 API を使用します。

定義の名前を指定します。これは group および plural フィールドの値を使用する <plural-name><group> 形式である必要があります。

API のグループ名を指定します。API グループは、論理的に関連付けられるオブジェクトのコレクションです。たとえば、Job または ScheduledJob などのすべてのバッチオブジェクトはバッチ API グループ (batch.api.example.com など) である可能性があります。組織の完全修飾ドメイン名を使用することが奨励されます。

URL で使用されるバージョン名を指定します。それぞれの API グループは複数バージョンで存在させることができます。たとえば、v1alpha、v1beta、v1 などが使用されます。

カスタムオブジェクトがクラスター (Cluster) の 1 つのプロジェクト (Namespaced) またはすべてのプロジェクトで利用可能であるかどうかを指定します。

URL で使用される複数形の名前を指定します。plural フィールドは API URL のリソースと同じになります。

CLI および表示用にエイリアスとして使用される単数形の名前を指定します。

作成できるオブジェクトの種類を指定します。タイプは CamelCase にすることができます。

CLI でリソースに一致する短い文字列を指定します。

注記注記

デフォルトで、カスタムリソース定義のスコープはクラスターに設定され、すべてのプロジェクトで利用可能です。

2. オブジェクトを作成します。

oc create -f <file-name>.yaml

新規の RESTful API エンドポイントは以下のように作成されます。

/apis/<spec:group>/<spec:version>/<scope>/*/<names-plural>/...

たとえば、サンプルファイルを使用すると、以下のエンドポイントが作成されます。

/apis/stable.example.com/v1/namespaces/*/crontabs/...

このエンドポイント URL を使用してカスタムオブジェクトを作成し、管理できます。オブジェ

version: v1 4 scope: Namespaced 5 names: plural: crontabs 6 singular: crontab 7 kind: CronTab 8 shortNames: - ct 9


246

このエンドポイント URL を使用してカスタムオブジェクトを作成し、管理できます。オブジェクトの種類は、作成したカスタムリソース定義オブジェクトの spec.kind フィールドに基づいています。

21.3. カスタムリソース定義のクラスターロールの作成

クラスタースコープのカスタムリソース定義 (CRD) の作成後に、これに対してパーミッションを付与できます。管理、編集および表示のデフォルトクラスターロールを使用する場合、これらのルールにクラスターロールの集計を利用できます。

重要重要

これらのロールのいずれかにパーミッションを付与する際は、明示的に付与する必要があります。より多くのパーミッションを持つロールはより少ないパーミッションを持つロールからルールを継承しません。ルールをあるロールに割り当てる場合、寄り多くのパーミッションを持つロールにもその動詞を割り当てる必要もあります。たとえば、「get crontabs」パーミッションを表示ロールに付与する場合、これを編集および管理ロールにも付与する必要があります。管理または編集ロールは通常、プロジェクトテンプレートでプロジェクトを作成したユーザーに割り当てられます。


CRD を作成します。

手順手順

1. CRD のクラスターロール定義ファイルを作成します。クラスターロール定義は、各クラスターロールに適用されるルールが含まれる YAML ファイルです。OpenShift Container PlatformController はデフォルトクラスターロールに指定するルールを追加します。

Example YAML file for a cluster role definition

apiVersion: rbac.authorization.k8s.io/v1 1kind: ClusterRoleitems: - metadata: name: aggregate-cron-tabs-admin-edit 2 labels: rbac.authorization.k8s.io/aggregate-to-admin: "true" 3 rbac.authorization.k8s.io/aggregate-to-edit: "true" 4 rules: - apiGroups: ["stable.example.com"] 5 resources: ["crontabs"] 6 verbs: ["get", "list", "watch", "create", "update", "patch", "delete", "deletecollection"] 7 - metadata: name: aggregate-cron-tabs-view 8 labels: # Add these permissions to the "view" default role. rbac.authorization.k8s.io/aggregate-to-view: "true" 9 rbac.authorization.k8s.io/aggregate-to-cluster-reader: "true" 10 rules:


247


1

2 8

3

4

5 11

6 12

7 13

9

10

apiextensions.k8s.io/v1beta1 API を使用します。

定義の名前を指定します。

パーミッションを管理のデフォルトロールに付与するためにこのラベルを指定します。

パーミッションを編集のデフォルトロールに付与するためにこのラベルを指定します。

CRD のグループ名を指定します

これらのルールが適用される CRD の複数形の名前を指定します。

ロールに付与されるパーミッションを表す動詞を指定します。たとえば、admin およびedit ロールに読み取りおよび書き込みパーミッションを適用し、view ロールに読み取りパーミッションのみを適用します。

パーミッションを view のデフォルトロールに付与するためにこのラベルを指定します。

パーミッションを cluster-reader のデフォルトロールに付与するためにこのラベルを指定します。

2. クラスターロールを作成します。


21.4. CRD からのカスタムオブジェクトの作成

カスタムリソース定義 (CRD) オブジェクトの作成後に、その仕様を使用するカスタムオブジェクトを作成できます。

カスタムオブジェクトには、任意の JSON コードを含むカスタムフィールドを含めることができます。


CRD を作成します。

手順手順

1. カスタムオブジェクトの YAML 定義を作成します。以下の定義例では、cronSpec と image のカスタムフィールドが CronTab タイプのカスタムオブジェクトに設定されます。このタイプは、カスタムリソース定義オブジェクトの spec.kind フィールドから取得します。

Example YAML file for a custom object

- apiGroups: ["stable.example.com"] 11 resources: ["crontabs"] 12 verbs: ["get", "list", "watch"] 13

apiVersion: "stable.example.com/v1" 1kind: CronTab 2metadata: name: my-new-cron-object 3 finalizers: 4 - finalizer.stable.example.com


248

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#action

1

2

3

4

5

カスタムリソース定義からグループ名および API バージョン (名前/バージョン) を指定します。

カスタムリソース定義のタイプを指定します。

オブジェクトの名前を指定します。

オブジェクトのファイナライザーを指定します。ファイナライザーは、コントローラーがオブジェクトの削除前に完了する必要のある条件を実装できるようにします。

オブジェクトのタイプに固有の条件を指定します。

2. オブジェクトファイルの作成後に、オブジェクトを作成します。


21.5. カスタムオブジェクトの管理

オブジェクトを作成した後には、カスタムリソースを管理できます。


カスタムリソース定義 (CRD) を作成します。

CRD からオブジェクトを作成します。

手順手順

1. 特定の種類のカスタムリソースについての情報を取得するには、以下を入力します。

oc get <kind>

例:

oc get crontab

NAME KINDmy-new-cron-object CronTab.v1.stable.example.com

リソース名では大文字と小文字が区別されず、CRD で定義される単数形または複数形のいずれか、および任意の短縮名を指定できることに注意してください。以下は例になります。

oc get crontabsoc get crontaboc get ct

2. カスタムリソースの未加工の YAML データも確認することができます。

oc get <kind> -o yaml

spec: 5 cronSpec: "* * * * /5" image: my-awesome-cron-image


249

https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#finalizers

1 2

oc get ct -o yaml

apiVersion: v1items:- apiVersion: stable.example.com/v1 kind: CronTab metadata: clusterName: "" creationTimestamp: 2017-05-31T12:56:35Z deletionGracePeriodSeconds: null deletionTimestamp: null name: my-new-cron-object namespace: default resourceVersion: "285" selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object uid: 9423255b-4600-11e7-af6a-28d2447dc82b spec: cronSpec: '* * * * /5' 1 image: my-awesome-cron-image 2

オブジェクトの作成に使用した YAML からのカスタムデータが表示されます。


250

第22章ガベージコレクション

22.1. 概要

OpenShift Container Platform ノードは、2 種類のガベージコレクションを実行します。

コンテナーのガべージコレクション: 終了したコンテナーを削除します。デフォルトで有効にされます。

イメージのガべージコレクション: 実行中の Pod によって参照されていないイメージを削除します。デフォルトで有効にされません。

22.2. コンテナーのガベージコレクション

コンテナーのガベージコレクションはデフォルトで有効にされ、エビクションのしきい値に達すると自動的に実行されます。ノードは Pod のコンテナーを API からアクセス可能な状態にしようとします。Pod が削除された場合、コンテナーも削除されます。コンテナーは Pod が削除されておらず、エビクションのしきい値に達していない限り保持されます。ノードがディスク不足 (disk pressure) の状態にある場合、コンテナーが削除され、それらのログは oc logs でアクセスできなくなります。

コンテナーのガベージコレクションのポリシーは 3 つのノード設定に基づいています。

設定設定説明説明

minimum-container-ttl-duration

コンテナーがガベージコレクションの対象となるのに必要な最小の年数です。デフォルトは 0 です。制限なしにするには 0 を使用します。この設定の値は、時間の h、分の m、秒の s などの単位のサフィックスを使用して指定することができます。

maximum-dead-containers-per-container

Pod コンテナーごとに保持するインスタンス数です。デフォルトは 1 です。

maximum-dead-containers

ノードにある実行されないコンテナーの合計の最大数です。デフォルトは、無制限を意味する -1 です。

注記注記

競合が生じる場合、maximum-dead-containers 設定は maximum-dead-containers-per-container 設定よりも優先されます。たとえば、maximum-dead-containers-per-container の数を保持することでコンテナーの合計数が maximum-dead-containers より大きくなる場合、最も古いコンテナーが削除され、maximum-dead-containers の制限が満たされるようにします。

ノードが実行されていないコンテナーを削除すると、それらのコンテナーの内部にあるすべてのファイルも削除されます。そのノードで作成されたコンテナーに対してのみガベージコレクションが実行されます。

デフォルト設定を使用する必要がない場合、ノード設定マップの kubeletArguments セクションでこれらの設定の値を指定します。このセクションがすでに存在しない場合には、これを追加します。

注記注記

第第22章章ガベージコレクションガベージコレクション

251

注記注記

コンテナーのガベージコレクションは、これらのパラメーターがノード設定マップに存在しない場合にデフォルト値を使用して実行されます。

コンテナーのガベージコレクション設定コンテナーのガベージコレクション設定

22.2.1. 削除するコンテナーの検出

ガべージコレクターの各ループでは、以下の手順が実行されます。

1. 利用可能なコンテナーの一覧を取得します。

2. 実行中であるか、または minimum-container-ttl-duration パラメーターよりも長く存続していないすべてのコンテナーをフィルターに掛けます。

3. 残りのすべてのコンテナーを、Pod およびイメージ名のメンバーシップに基づいて同等のクラスに分類します。

4. 特定されないコンテナー (kubelet で管理されているコンテナーであるが、それらの名前の形式が正しくないコンテナー) をすべて削除します。

5. maximum-dead-containers-per-container パラメーターよりも多くのコンテナーが含まれるそれぞれのクラスについて、そのクラスのコンテナーを作成時間で並び替えます。

6. maximum-dead-containers-per-container パラメーターの条件が満たされるまで、コンテナーを最も古いものから順に削除し始めます。

7. 依然として maximum-dead-containers パラメーターよりも多くのコンテナーが一覧にある場合、コレクターは各クラスのコンテナーの削除を開始し、それぞれのクラスにあるコンテナー数がクラスあたりのコンテナーの平均数、または <all_remaining_containers>/<number_of_classes> よりも大きくならないようにします。

8. これでも十分でない場合は、一覧にあるすべてのコンテナーを並び替えて、maximum-dead-containers の条件を満たすまで、コンテナーを古いものから順番に削除し始めます。

重要重要

各種のニーズに合わせてデフォルト設定を更新してください。

ガべージコレクションは、関連付けられている Pod のないコンテナーのみを削除します。

22.3. イメージのガベージコレクション

イメージのガべージコレクションでは、ノードの cAdvisor によって報告されるディスク使用量に基づ

kubeletArguments: minimum-container-ttl-duration: - "10s" maximum-dead-containers-per-container: - "2" maximum-dead-containers: - "240"


252

イメージのガべージコレクションでは、ノードの cAdvisor によって報告されるディスク使用量に基づいて、ノードから削除するイメージを決定します。この場合、以下の設定が考慮に入れられます。


image-gc-high-threshold

イメージのガべージコレクションをトリガーするディスク使用量のパーセント(整数で表される) です。

image-gc-low-threshold

イメージのガべージコレクションが解放しようとするディスク使用量のパーセントです (整数で表される)。

イメージのガベージコレクションを有効にするには、ノード設定マップの kubeletArguments セクションでこれらの設定の値を指定します。このセクションがすでに存在しない場合には、これを追加します。

注記注記

イメージのガベージコレクションは、これらのパラメーターがノード設定マップに存在しない場合にデフォルト値を使用して実行されます。

イメージのガベージコレクション設定イメージのガベージコレクション設定

22.3.1. 削除するイメージの検出

以下の 2 つのイメージ一覧がそれぞれのガベージコレクターの実行で取得されます。

1. 1 つ以上の Pod で現在実行されているイメージの一覧

2. ホストで利用可能なイメージの一覧

新規コンテナーの実行時に新規のイメージが表示されます。すべてのイメージにはタイムスタンプのマークが付けられます。イメージが実行中 (上記の最初の一覧) か、または新規に検出されている (上記の 2 番目の一覧) 場合、これには現在の時間のマークが付けられます。残りのイメージには以前のタイムスタンプのマークがすでに付けられています。すべてのイメージはタイムスタンプで並び替えられます。

コレクションが開始されると、停止条件を満たすまでイメージが最も古いものから順番に削除されます。

kubeletArguments: image-gc-high-threshold: - "85" image-gc-low-threshold: - "80"

第第22章章ガベージコレクションガベージコレクション

253

第23章ノードリソースの割り当て

23.1. 概要

より信頼性の高いスケジューリングを提供し、ノードにおけるリソースのオーバーコミットを最小限にするために、各ノードは、ホスト上のすべての基礎となるノードコンポーネント (例: kubelet、kube-proxy、Docker) および残りのシステムコンポーネント (例: sshd、NetworkManager) に使用される分をリソースの一部として保持できます。このリソースが指定されると、スケジューラーは、ノードがPod に割り当てたリソース (例: メモリー、CPU) についての詳細な情報を取得できます。

23.2. 割り当てられるリソースについてのノードの設定

ノードコンポーネント用に予約されるリソースは、2 つのノード設定 (kube-reserved および system-reserved) をベースとしています。

kube-reserved 設定を使用して kubelet 専用のメモリーの一部を予約し、残りのシステムプロセス用に system-reserved 設定を使用できます。

注記注記

これらのパラメーターは注意して設定してください。kube-reserved および system-reserved の制限を有効にすると、ノード上の重要なシステムサービスで CPU が不足したり、OOM による強制終了が生じる可能性があります。これらの設定の影響についての詳細は、「割り当てられるリソースの計算」を参照してください。


kube-reserved kubelet、Docker デーモン、SkyDNS、kube-proxy などのノードリソースに予約されるリソースです。デフォルトは none です。

system-reserved 残りのシステムコンポーネント用に予約されたリソースです。デフォルトは none です。

libcgroup などのツールで、system-reserved が制御するサービスを確認できます。

$ yum install libcgroup-tools$ lscgroup memory:/system.slice

これらは、<resource_type>=<resource_quantity> ペアのセット (例: cpu=200m,memory=512Mi) を使用してノード設定マップの kubeletArguments セクションに設定することができます。このセクションは、すでに存在しない場合は追加します。

例23.1 ノードの割り当て可能なリソースの設定

kubeletArguments: kube-reserved: - "cpu=200m,memory=512Mi" system-reserved: - "cpu=200m,memory=512Mi"


254


注記注記

node-config.yaml ファイルを直接編集しないでください。

これらの設定についての適切な値を判断するには、ノード要約 API を使用してノードのリソース使用率を判別します。詳細は、「ノードによって報告されるシステムリソース」を参照してください。

kube-reserved と system-reserved の設定後：

ノードのメモリー使用量をモニターして、高基準値を確認します。

$ ps aux | grep <service-name>

例:

$ ps aux | grep atomic-openshift-node

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMANDroot 11089 11.5 0.3 112712 996 pts/1 R+ 16:23 0:00 grep --color=auto atomic-openshift-node

この値が kube-reserved の基準に近い場合は、kube-reserved の値を増やすことができます。

libcgroup などのツールでシステムサービスのメモリー使用量をmモニターします。

$ yum install libcgroup-tools$ cgget -g memory /system.slice | grep memory.usage_in_bytes

この値が system-reserved の基準に近い場合は、system-reserved の値を増やすことができます。

OpenShift Container Platform Cluster Loader を使用して、クラスターの各種の状態でのデプロイメントのパフォーマンスメトリクスを測定します。

23.3. 割り当てられるリソースの計算

リソースの割り当てられる量は以下の数式に基づいて計算されます。

[Allocatable] = [Node Capacity] - [kube-reserved] - [system-reserved] - [Hard-Eviction-Thresholds]

注記注記

Hard-Eviction-Thresholds を割り当て可能なリソースから差し引く点はシステムの信頼性を強化するための動作の変更点です。この値に基づいて割り当て可能なリソースをノードレベルでエンドユーザー Pod に対して適用できます。experimental-allocatable-ignore-eviction 設定は、レガシー動作を保持するために利用できますが、今後のリリースでは非推奨となります。

[Allocatable] が負の値の場合、これは 0 に設定されます。

23.4. ノードの割り当て可能なリソースおよび容量の表示

第第23章章ノードリソースの割り当てノードリソースの割り当て

255

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/scaling_and_performance_guide/#scaling-performance-using-cluster-loader

ノードの現在の容量および割り当て可能なリソースを表示するには、以下を実行できます。

$ oc get node/<node_name> -o yaml...status:... allocatable: cpu: "4" memory: 8010948Ki pods: "110" capacity: cpu: "4" memory: 8010948Ki pods: "110"...

23.5. ノードによって報告されるシステムリソース

各ノードはコンテナーランタイムおよび kubelet によって利用されるシステムリソースについて報告します。--system-reserved および --kube-reserved の設定をより容易に行えるようにするには、ノード要約 API を使用して対応するノードのリソース使用状況を判別できます。この API は<master>/api/v1/nodes/<node>/proxy/stats/summary からアクセスできます。

たとえば、cluster.node22 ノードからリソースにアクセスするには、以下を実行できます。

$ curl <certificate details> https://<master>/api/v1/nodes/cluster.node22/proxy/stats/summary{ "node": { "nodeName": "cluster.node22", "systemContainers": [ { "cpu": { "usageCoreNanoSeconds": 929684480915, "usageNanoCores": 190998084 }, "memory": { "rssBytes": 176726016, "usageBytes": 1397895168, "workingSetBytes": 1050509312 }, "name": "kubelet" }, { "cpu": { "usageCoreNanoSeconds": 128521955903, "usageNanoCores": 5928600 }, "memory": { "rssBytes": 35958784, "usageBytes": 129671168, "workingSetBytes": 102416384 }, "name": "runtime" }


256

1

2

3

] }}

証明書の詳細については、「REST API Overview」を参照してください。

23.6. ノードの実施

ノードは、Pod が設定された割り当て可能な値に基づいて消費できるリソースの合計量を制限できます。この機能は、Pod がリソースのシステムサービス (例: コンテナーランタイム、ノードエージェントなど) のリソース不足の状態を防ぎ、ノードの信頼性を大幅に強化します。管理者におかれましては、ノードの信頼性を強化するために必要なノードの使用状況のターゲットに基づいてリソースを予約することを強く奨励します。

ノードは、QoS (Quality of Service) を実施する新規の cgroup 階層を使用してリソースの制約を実施します。すべての Pod は、システムデーモンと切り離された専用の cgroup 階層で起動します。

ノードの実施を設定するために、適切なノード設定マップで以下のパラメーターを使用します。

例23.2 ノードの cgroup 設定

ノードによって管理される新規の cgroup 階層を有効化または無効化します。この設定の変更にはノードの完全なドレイン (解放) が必要になります。このフラグは、ノードがノードの割り当て可能分を実施できるようにするには true である必要があります。ユーザーにはこの値を変更しないようにすることを推奨します。

cgroup 階層を管理する際にノードで使用される cgroup ドライバーです。この値はコンテナーランタイムに関連付けられたドライバーに一致する必要があります。有効な値は systemd および cgroupfs です。デフォルトは systemd です。

ノードがノードのリソース制約を実施するスコープのカンマ区切りの一覧です。有効な値は pods、system-reserved、および kube-reserved です。デフォルトは pods です。ユーザーにはこの値を変更しないようにすることを推奨します。

オプションとして、enforce-node-allocatable フラグでトークンを指定することで、ノードが kube で予約される制限およびシステムで予約される制限を実施するようにできます。これらが指定される場合、対応する --kube-reserved-cgroup または --system-reserved-cgroup を指定する必要があります。今後のリリースでは、ノードおよびコンテナーランタイムは system.slice と切り離された共通のcgroup でパッケージ化されます。パッケージ化されるまでは、ユーザーは enforce-node-allocatableフラグのデフォルト値を変更しないようにすることを推奨します。

管理者は Guaranteed Pod と同様にシステムデーモンを処理する必要があります。システムデーモンは、境界となる制御グループ内で予想外の動作をする可能性があり、この動作はクラスターデプロイメントの一部として管理される必要があります。システム予約の制限を実施することにより、ノード上の重要なシステムサービスで CPU が不足したり、OOM による強制終了が生じる可能性があります。そ

kubeletArguments: cgroups-per-qos: - "true" 1 cgroup-driver: - "systemd" 2 enforce-node-allocatable: - "pods" 3


257

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/api_reference/#rest-api-index

のため、オペレーターが正確な推定値を判別するためにノードの徹底的なプロファイリングを実行した場合や、そのグループのプロセスで OOM による強制終了が発生した場合に確実に復元できる場合にのみシステム予約の制限を実施することが推奨されます。

したがって、ユーザーはデフォルトで pods に対してのみノードの割り当て可能分を実施し、ノード全体の信頼性を維持するためにシステムデーモンの適切な予約を確保しておくことを強くお勧めします。

以下のコマンドを使用して、設定されている cgroup ドライバーを確認できます。

$ systemctl status atomic-openshift-node -l | grep cgroup-driver=

出力には、以下のような応答が含まれます。

--cgroup-driver=systemd

cgroup ドライバーの管理およびトラブルシューティングの詳細は、「コントロールグループ (Cgroups)について」を参照してください。

23.7. エビクションしきい値

ノードがメモリー不足の状態にある場合、ノード全体に、またノードで実行されているすべての Podに影響が及ぶ可能性があります。システムデーモンによるメモリーの使用がメモリーの予約されている量を超える場合、OOM イベントが発生し、ノード全体やノードで実行されているすべての Pod に影響が及び可能性があります。システムの OOM を防止する (またはその発生可能性を下げる) ために、ノードは Out Of Resource Handling (リソース不足の処理) を行います。

--eviction-hard フラグで一部のメモリーを確保することで、ノードは、ノードのメモリー可用性が絶対値またはパーセンテージを下回る場合は常に Pod のエビクトを試行します。システムデーモンがノードに存在しない場合、Pod はメモリーの capacity - eviction-hard に制限されます。このため、メモリー不足の状態になる前にエビクションのバッファーとして確保されているリソースは Pod で利用することはできません。

以下の例は、ノードの割り当て可能分のメモリーに対する影響について説明しています。

ノード容量: 32Gi

--kube reserved: 2Gi

--system-reserved: 1Gi

--eviction-hard は <100Mi に設定される。

このノードについては、有効なノードの割り当て可能な値は 28.9Gi です。ノードおよびシステムコンポーネントが予約分をすべて使い切る場合、Pod に利用可能なメモリーは 28.9Gi となり、この使用量を超える場合に kubelet は Pod をエビクトします。

トップレベルの cgroup でノードの割り当て可能分 (28.9Gi) を実施する場合、Pod は 28.9Gi を超えることはできません。エビクションは、システムデーモンが 3.1Gi よりも多くのメモリーを消費しない限り実行されません。

上記の例ではシステムデーモンが予約分すべてを使い切らない場合も、ノードのエビクションが開始される前に、Pod では境界となる cgroup からの memcg OOM による強制終了が発生します。この状況でQoS をより効果的に実行するには、ノードですべての Pod のトップレベルの cgroup に対し、ハードエビクションしきい値が Node Allocatable + Eviction Hard Thresholds になるよう適用できます。

システムデーモンがすべての予約分を使い切らない場合で、Pod が全体として 28.9Gi を超えるメモ


258

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/resource_management_guide/chap-introduction_to_control_groups

システムデーモンがすべての予約分を使い切らない場合で、Pod が全体として 28.9Gi を超えるメモリーを消費する場合、ノードは Pod を常にエビクトします。エビクションが時間内に生じない場合には、Pod が全体として 29Gi のメモリーを消費すると OOM による強制終了が生じます。

23.8. スケジューラー

スケジューラーは、node.Status.Capacity ではなく node.Status.Allocatable の値を使用して、ノードが Pod スケジューリングの候補になるかどうかを判別します。

デフォルトで、ノードはそのマシン容量をクラスターで完全にスケジュール可能であるとして報告します。


259

第24章 NODE PROBLEM DETECTOR

24.1. 概要

Node Problem Detector (ノード問題検出機能) は特定の問題を検出し、それらの問題を API サーバーに報告することで、ノードの正常性をモニターします。Node Problem Detector は、各ノードでdaemonSet として実行されます。

重要重要

Node Problem Detector はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。


Node Problem Detector はシステムログを読み取り、特定のエントリーの有無を監視し、コントロールプレーンにそれらの問題を表示します。これらの問題は、oc get node および oc get event などのOpenShift Container Platform コマンドを使用して表示できます。これらの問題については、適宜修正するようアクションを実行するか、または OpenShift Container Platform ログモニタリングなどの選択可能なツールを使用してメッセージをキャプチャーすることができます。検出される問題は以下のいずれかのカテゴリーに分類できます。

NodeCondition: ノードを Pod に対して利用不可にする永続的な問題です。ノードの状態は、ホストが再起動されるまでクリアされません。

Event: ノードに制限的な影響を与える一時的な問題で、情報を提供します。

Node Problem Detector は以下を検出できます。

コンテナーランタイムの問題:

反応しないランタイムデーモン

ハードウェアの問題:

正常でない CPU

正常でないメモリー

正常でないディスク

カーネルの問題:

カーネルのデッドロック状態

破損したファイルシステム

反応しないランタイムデーモン

インフラストラクチャーデーモンの問題:

NTP サービスの停止


260


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/container_security_guide/#security-monitoring

24.2. NODE PROBLEM DETECTOR の出力サンプル

以下の例では、特定のノードでカーネルのデッドロックを監視する Node Problem Detector の出力を示しています。コマンドでは oc get node を使用し、ログで KernelDeadlock エントリーについてフィルターし、特定のノードを監視します。

# oc get node <node> -o yaml | grep -B5 KernelDeadlock

Node Problem Detector の出力サンプルの出力サンプル (問題がない場合問題がない場合)

message: kernel has no deadlockreason: KernelHasNoDeadlockstatus: falsetype: KernelDeadLock

KernelDeadLock 状態の出力サンプル状態の出力サンプル

message: task docker:1234 blocked for more than 120 secondsreason: DockerHungstatus: truetype: KernelDeadLock

この例は、ノードでイベントの有無を監視する Node Problem Detector からの出力を示しています。以下のコマンドでは、default プロジェクトに対して oc get event を使用し、Node Problem Detector 設定マップの kernel-monitor.json セクションに一覧表示されているイベントの有無を監視します。

# oc get event -n default --field-selector=source=kernel-monitor --watch

ノードのイベントを表示する出力サンプルノードのイベントを表示する出力サンプル

LAST SEEN FIRST SEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE2018-06-27 09:08:27 -0400 EDT 2018-06-27 09:08:27 -0400 EDT 1 my-node1 node Warning TaskHunk kernel-monitor.my-node1 docker:1234 blocked for more than 300 seconds2018-06-27 09:08:27 -0400 EDT 2018-06-27 09:08:27 -0400 EDT 3 my-node2 node Warning KernelOops kernel-monitor.my-node2 BUG: unable to handle kernel NULL pointer deference at nowhere2018-06-27 09:08:27 -0400 EDT 2018-06-27 09:08:27 -0400 EDT 1 my-node1 node Warning KernelOops kernel-monitor.my-node2 divide error 0000 [#0] SMP

注記注記

Node Problem Detector はリソースを消費するため、Node Problem Detector を使用する場合は、クラスターのパフォーマンスのバランスを保つために十分なノードがあることを確認してください。

24.3. NODE PROBLEM DETECTOR のインストール

openshift_node_problem_detector_install が /etc/ansible/hosts インベントリーファイルで true に設定される場合、インストールではデフォルトで Node Problem Detector の Deamonset を作成し、openshift-node-problem-detector という検出プログラムのプロジェクトを作成します。

第第24章章 NODE PROBLEM DETECTOR

261


注記注記

Node Problem Detector はテクノロジープレビューとして提供されているため、openshift_node_problem_detector_install はデフォルトで false に設定されています。Node Problem Detector のインストール時には、パラメーターを true に手動で設定する必要があります。

Node Problem Detector がインストールされていない場合、Playbook ディレクトリーに切り替え、openshift-node-problem-detector/config.yml Playbook を実行して Node Problem Detector をインストールします。

$ cd /usr/share/ansible/openshift-ansible$ ansible-playbook playbooks/openshift-node-problem-detector/config.yml

24.4. 検出された条件のカスタマイズ

Node Problem Detector 設定マップを編集し、Node Problem Detector をログの文字列を監視するように設定できます。

Node Problem Detector 設定マップのサンプル設定マップのサンプル

apiVersion: v1kind: ConfigMapmetadata: name: node-problem-detectordata: docker-monitor.json: | 1 { "plugin": "journald", 2 "pluginConfig": { "source": "docker" }, "logPath": "/host/log/journal", 3 "lookback": "5m", "bufferSize": 10, "source": "docker-monitor", "conditions": [], "rules": [ 4 { "type": "temporary", 5 "reason": "CorruptDockerImage", 6 "pattern": "Error trying v2 registry: failed to register layer: rename /var/lib/docker/image/(.+) /var/lib/docker/image/(.+): directory not empty.*" 7 } ] } kernel-monitor.json: | 8 { "plugin": "journald", 9 "pluginConfig": { "source": "kernel" }, "logPath": "/host/log/journal", 10


262

1

2 9

"lookback": "5m", "bufferSize": 10, "source": "kernel-monitor", "conditions": [ 11 { "type": "KernelDeadlock", 12 "reason": "KernelHasNoDeadlock", 13 "message": "kernel has no deadlock" 14 } ], "rules": [ { "type": "temporary", "reason": "OOMKilling", "pattern": "Kill process \\d+ (.+) score \\d+ or sacrifice child\\nKilled process \\d+ (.+) total-vm:\\d+kB, anon-rss:\\d+kB, file-rss:\\d+kB" }, { "type": "temporary", "reason": "TaskHung", "pattern": "task \\S+:\\w+ blocked for more than \\w+ seconds\\." }, { "type": "temporary", "reason": "UnregisterNetDevice", "pattern": "unregister_netdevice: waiting for \\w+ to become free. Usage count = \\d+" }, { "type": "temporary", "reason": "KernelOops", "pattern": "BUG: unable to handle kernel NULL pointer dereference at .*" }, { "type": "temporary", "reason": "KernelOops", "pattern": "divide error: 0000 \\[#\\d+\\] SMP" }, { "type": "permanent", "condition": "KernelDeadlock", "reason": "AUFSUmountHung", "pattern": "task umount\\.aufs:\\w+ blocked for more than \\w+ seconds\\." }, { "type": "permanent", "condition": "KernelDeadlock", "reason": "DockerHung", "pattern": "task docker:\\w+ blocked for more than \\w+ seconds\\." } ] }

コンテナーイメージに適用されるルールおよび条件。

カンマ区切りの一覧のモニタリングサービス


263

3 10

4 11

5 12

6 13

7 14

8

モニタリングサービスログのパス。

モニターされるイベントの一覧。

エラーがイベント (temporary) または NodeCondition (permanent) であることを示すラベル。

エラーを記述するテキストメッセージ。

Node Problem Detector が監視するエラーメッセージ。

カーネルに適用されるルールおよび条件。

Node Problem Detector を設定するには、問題の状態およびイベントを追加するか、またはこれらを削除します。

1. テキストエディターで Node Problem Detector 設定マップを編集します。

2. ノードの状態またはイベントを必要に応じて削除、追加、または編集します。

例:

3. 変更を適用するために実行中の Pod を再起動します。Pod を再起動するために、すべての既存Pod を削除できます。

4. Node Problem Detector 出力を標準出力 (stdout) および標準エラー出力 (stderr) に表示するには、以下を Node Problem Detector の DaemonSet に追加します。

oc edit configmap -n openshift-node-problem-detector node-problem-detector

{ "type": <`temporary` or `permanent`>, "reason": <free-form text describing the error>, "pattern": <log message to watch for>},

{ "type": "temporary", "reason": "UnregisterNetDevice", "pattern": "unregister_netdevice: waiting for \\w+ to become free. Usage count = \\d+"},

# oc delete pods -n openshift-node-problem-detector -l name=node-problem-detector

spec: template: spec: containers: - name: node-problem-detector command: - node-problem-detector - --alsologtostderr=true 1 - --log_dir="/tmp" 2 - --system-log-monitors=/etc/npd/kernel-monitor.json,/etc/npd/docker-monitor.json 3


264

1

2

3

出力を標準出力 (stdout) に送信します。

エラーログへのパス。

プラグイン設定ファイルへのカンマ区切りのパス。

24.5. NODE PROBLEM DETECTOR が実行中であることの確認

Node Problem Detector が有効であることを確認するには、以下を実行します。

以下のコマンドを実行し、Problem Node Detector Pod の名前を取得します。

以下のコマンドを実行し、Problem Node Detector Pod のログ情報を表示します。

出力は以下のようになります。

ノードのイベントをシミュレーションして Node Problem Detector をテストします。

ノードの状態をシミュレーションして Node Problem Detector をテストします。

24.6. NODE PROBLEM DETECTOR のアンインストール

Node Problem Detector をアンインストールするには、以下を実行します。

1. Ansible インベントリーファイルに以下のオプションを追加します。

2. Playbook ディレクトリーに切り替え、config.yml Ansible Playbook を実行します。

# oc get pods -n openshift-node-problem-detector

NAME READY STATUS RESTARTS AGEnode-problem-detector-8z8r8 1/1 Running 0 1hnode-problem-detector-nggjv 1/1 Running 0 1h

# oc logs -n openshift-node-problem-detector <pod_name>

# oc logs -n openshift-node-problem-detector node-problem-detector-c6kngI0416 23:22:00.641354 1 log_monitor.go:63] Finish parsing log monitor config file: {WatcherConfig:{Plugin:journald PluginConfig:map[source:kernel] LogPath:/host/log/journal Lookback:5m} BufferSize:10 Source:kernel-monitor DefaultConditions:[{Type:KernelDeadlock Status:false Transition:0001-01-01 00:00:00 +0000 UTC Reason:KernelHasNoDeadlock Message:kernel has no deadlock}]

# echo "kernel: divide error: 0000 [#0] SMP." >> /dev/kmsg

# echo "kernel: task docker:7 blocked for more than 300 seconds." >> /dev/kmsg

[OSEv3:vars]openshift_node_problem_detector_state=absent

$ cd /usr/share/ansible/openshift-ansible$ ansible-playbook playbooks/openshift-node-problem-detector/config.yml


265


266

第25章オーバーコミット

25.1. 概要

コンテナーは、コンピュートリソース要求および制限を指定することができます。要求はコンテナーのスケジューリングに使用され、最小限のサービス保証を提供します。一方、制限はノードで消費できるコンピュートリソースの量を制限します。

scheduler は、クラスター内のすべてのノードにおけるコンピュートリソース使用の最適化を試行します。これは Pod のコンピュートリソース要求とノードの利用可能な容量を考慮に入れて Pod を特定のノードに配置します。

要求および制限により、管理者はノードでのリソースのオーバーコミットを許可し、管理できます。これは、保証されるパフォーマンスとキャパシティーのトレードオフが許容される開発環境において役立ちます。

25.2. 要求および制限

各コンピュートリソースについて、コンテナーはリソース要求および制限を指定できます。スケジューリングの決定は要求に基づいて行われ、ノードに要求される値を満たす十分な容量があることが確認されます。コンテナーが制限を指定するものの、要求を省略する場合、要求はデフォルトで制限値に設定されます。コンテナーは、ノードの指定される制限を超えることはできません。

制限の実施方法は、コンピュートリソースのタイプによって異なります。コンテナーが要求または制限を指定しない場合、コンテナーはリソース保証のない状態でノードにスケジュールされます。実際に、コンテナーはローカルの最も低い優先順位で利用できる指定リソースを消費できます。リソースが不足する状態では、リソース要求を指定しないコンテナーに最低レベルの QoS (Quality of Service) が設定されます。

25.2.1. Buffer Chunk Limit の調整

Fluentd ロガーが多数のログを処理できない場合、メモリーの使用量を減らし、データ損失を防ぐためにファイルバッファリングに切り換える必要があります。

Fluentd buffer_chunk_limit は、デフォルト値が 8m の環境変数 BUFFER_SIZE_LIMIT によって決定されます。出力ごとのファイルのバッファーサイズは、デフォルト値が 256Mi の環境変数 FILE_BUFFER_LIMIT によって決定されます。永続的なボリュームサイズは、FILE_BUFFER_LIMITに出力を乗算した結果よりも大きくなければなりません。

Fluentd および Mux Pod では、永続ボリューム /var/lib/fluentd は PVC または hostmount などによって作成される必要があります。その領域はファイルバッファーに使用されます。

buffer_type および buffer_path は、以下のように Fluentd 設定ファイルで設定されます。

$ egrep "buffer_type|buffer_path" *.confoutput-es-config.conf: buffer_type file buffer_path `/var/lib/fluentd/buffer-output-es-config`output-es-ops-config.conf: buffer_type file buffer_path `/var/lib/fluentd/buffer-output-es-ops-config`filter-pre-mux-client.conf: buffer_type file buffer_path `/var/lib/fluentd/buffer-mux-client`

第第25章章オーバーコミットオーバーコミット

267

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-compute-resources

Fluentd buffer_queue_limit は変数 BUFFER_QUEUE_LIMIT の値です。この値はデフォルトで 32 になります。

環境変数 BUFFER_QUEUE_LIMIT は (FILE_BUFFER_LIMIT / (number_of_outputs * BUFFER_SIZE_LIMIT)) として計算されます。

BUFFER_QUEUE_LIMIT 変数にデフォルトの値のセットが含まれる場合、以下のようになります。

FILE_BUFFER_LIMIT = 256Mi

number_of_outputs = 1

BUFFER_SIZE_LIMIT = 8Mi

buffer_queue_limit の値は 32 になります。buffer_queue_limit を変更するには、FILE_BUFFER_LIMIT の値を変更する必要があります。

この数式では、number_of_outputs は、すべてのログが単一リソースに送信され、追加のリソースごとに 1 つずつ増分する場合に 1 になります。たとえば、number_of_outputs の値は以下のようになります。

1 - すべてのログが単一の ElasticSearch Pod に送信される場合

2 - アプリケーションログが ElasticSearch Pod に送信され、運用ログが別の ElasticSearch Podに送信される場合

4 - アプリケーションログが ElasticSearch Pod に送信され、運用ログが別の ElasticSearch Podに送信される場合で、それらがどちらも他の Fluentd インスタンスに転送される場合

25.3. コンピュートリソース

コンピュートリソースについてのノードで実施される動作は、リソースタイプによって異なります。

25.3.1. CPU

コンテナーには要求する CPU の量が保証され、さらにコンテナーで指定される任意の制限までノードで利用可能な CPU を消費できます。複数のコンテナーが追加の CPU の使用を試行する場合、CPU 時間が各コンテナーで要求される CPU の量に基づいて分配されます。

たとえば、あるコンテナーが 500m の CPU 時間を要求し、別のコンテナーが 250m の CPU 時間を要求した場合、ノードで利用可能な追加の CPU 時間は 2:1 の比率でコンテナー間で分配されます。コンテナーが制限を指定している場合、指定した制限を超えて CPU を使用しないようにスロットリングされます。

CPU 要求は、Linux カーネルの CFS 共有サポートを使用して実施されます。デフォルトで、CPU 制限は、Linux カーネルの CFS クォータサポートを使用して 100ms の測定間隔で実施されます。ただし、これは無効にすることができます。

25.3.2. メモリー

コンテナーには要求するメモリー量が保証されます。コンテナーは要求したよりも多くのメモリーを使用できますが、いったん要求した量を超えた場合には、ノードのメモリーが不足している状態では強制終了される可能性があります。

コンテナーが要求した量よりも少ないメモリーを使用する場合、システムタスクやデーモンがノードのリソース予約で確保されている分よりも多くのメモリーを必要としない限りそれが強制終了されること


268

はません。コンテナーがメモリーの制限を指定する場合、その制限量を超えると即時に強制終了されます。

25.3.3. 一時ストレージ

注記注記

このトピックは、一時ストレージのテクノロジープレビューを有効にしている場合にのみ関連性があります。この機能は、デフォルトでは無効になっています。有効にすると、OpenShift Container Platform クラスターは一時ストレージを使用して、クラスターが破棄された後に永続される必要のない情報を保存します。この機能を有効にする方法は、「一時ストレージの設定」を参照してください。

コンテナーには要求する一時ストレージの量が保証されます。コンテナーは要求したよりも多くの一時ストレージを使用できますが、いったん要求した量を超えた場合には、利用可能な一時ディスク領域が不足している状態では強制終了される可能性があります。

コンテナーが要求した量よりも少ない一時ストレージを使用する場合、システムタスクやデーモンがノードのリソース予約で確保されている分よりも多くのローカルの一時ストレージを必要としない限りそれが強制終了されることはありません。コンテナーが一時ストレージの制限を指定する場合、その制限量を超えると即時に強制終了されます。

25.4. QOS (QUALITY OF SERVICE) クラス

ノードは、要求を指定しない Pod がスケジュールされている場合やノードのすべての Pod での制限の合計が利用可能なマシンの容量を超える場合にオーバーコミットされます。

オーバーコミットされる環境では、ノード上の Pod がいずれかの時点で利用可能なコンピュートリソースよりも多くの量の使用を試行することができます。これが生じると、ノードはそれぞれの Podに優先順位を指定する必要があります。この決定を行うために使用される機能は、QoS (Quality ofService) クラスと呼ばれます。

各コンピュートリソースについて、コンテナーは 3 つの QoS クラスに分類されます (優先順位は降順)。

表25.1 QoS (Quality of Service) クラス

優先順位優先順位クラス名クラス名説明説明

1 (最高) Guaranteed

制限およびオプションの要求がすべてのリソースについて設定されている場合 (0 と等しくない) でそれらの値が等しい場合、コンテナーは Guaranteedとして分類されます。

2 Burstable 制限およびオプションの要求がすべてのリソースについて設定されている場合 (0 と等しくない) でそれらの値が等しくない場合、コンテナーは Burstableとして分類されます。

3 (最低) BestEffort 要求および制限がリソースのいずれについても設定されない場合、コンテナーは BestEffort として分類されます。

メモリーは圧縮できないリソースであるため、メモリー不足の状態では、最も優先順位の低いコンテナーが最初に強制終了されます。


269

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-configuring-ephemeral-storage

1

2

3

4

Guaranteed コンテナーは優先順位が最も高いコンテナーとして見なされ、保証されます。強制終了されるのは、これらのコンテナーで制限を超えるか、またはシステムがメモリー不足の状態にあるものの、エビクトできる優先順位の低いコンテナーが他にない場合のみです。

システム不足の状態にある Burstable コンテナーは、制限を超過し、BestEffort コンテナーが他に存在しない場合に強制終了される可能性があります。

BestEffort コンテナーは優先順位の最も低いコンテナーとして処理されます。これらのコンテナーのプロセスは、システムがメモリーー不足になると最初に強制終了されます。

25.5. マスターでのオーバーコミットの設定

スケジューリングは要求されるリソースに基づいて行われる一方で、クォータおよびハード制限はリソース制限のことを指しており、これは要求されるリソースよりも高い値に設定できます。要求と制限の間の差異は、オーバーコミットのレベルを定めるものとなります。たとえば、コンテナーに 1Gi のメモリー要求と 2Gi のメモリー制限が指定される場合、コンテナーのスケジューリングはノードで 1Gi を利用可能とする要求に基づいて行われますが、 2Gi まで使用することができます。そのため、この場合のオーバーコミットは 200% になります。

OpenShift Container Platform 管理者がオーバーコミットのレベルを制御し、ノードのコンテナー密度を管理する必要がある場合、開発者コンテナーで設定された要求と制限の比率を上書きするようマスターを設定することができます。この設定を制限とデフォルトを指定するプロジェクトごとのLimitRange と共に使用することで、オーバーコミットを必要なレベルに設定できるようコンテナーの制限と要求を調整することができます。

これを実行するには、以下の例にあるように master-config.yaml で ClusterResourceOverride 受付コントローラーを設定することが必要です (既存の設定ツリーが存在する場合はこれを再利用するか、または必要に応じて存在しない要素を導入します)。

admissionConfig: pluginConfig: ClusterResourceOverride: 1 configuration: apiVersion: v1 kind: ClusterResourceOverrideConfig memoryRequestToLimitPercent: 25 2 cpuRequestToLimitPercent: 25 3 limitCPUToMemoryPercent: 200 4

これはプラグイン名です。大文字/小文字の区別が必要であり、プラグインの完全に一致する名前以外はすべて無視されます。

(オプション、1-100) コンテナーのメモリー制限が指定されているか、デフォルトに設定されている場合、メモリー要求は制限のこのパーセンテージに対応して上書きされます。

(オプション、1-100) コンテナーの CPU 制限が指定されているか、またはデフォルトに設定されている場合、CPU 要求は制限のこのパーセンテージに対応して上書きされます。

(オプション、正の整数) コンテナーのメモリー制限が指定されているか、デフォルトに設定されている場合、CPU 制限はメモリー制限のパーセンテージに対応して上書きされます。この場合、1Giの RAM が 1 CPU コアと等しくなる場合に 100 パーセントになります。これは、CPU 要求を上書きする前に処理されます (設定されている場合)。

マスター設定の変更後は、マスターの再起動が必要になります。


270

1

制限がコンテナーに設定されていない場合にはこれらの上書きは影響を与えないことに注意してください。(個別プロジェクトごとに、またはプロジェクトテンプレートを使用して) デフォルトの制限でLimitRange オブジェクトを作成し、上書きが適用されるようにします。

また、上書き後も、コンテナーの制限および要求がプロジェクトのいずれかの LimitRange オブジェクトで依然として検証される必要があることにも注意してください。たとえば、開発者が最小限度に近い制限を指定し、要求を最小限度よりも低い値に上書きすることで、Pod が禁止される可能性があります。この最適でないユーザーエクスペリエンスについては、今後の作業で対応する必要がありますが、現時点ではこの機能および LimitRanges を注意して設定してください。

上書きが設定されている場合に、プロジェクトを編集し、以下のアノテーションを追加することで、上書きをプロジェクトごとに無効にすることができます (たとえば、インフラストラクチャーコンポーネントの設定を上書きと切り離して実行できます)。

quota.openshift.io/cluster-resource-override-enabled: "false"

25.6. ノードでのオーバーコミットの設定

オーバーコミット環境では、最適なシステム動作を提供できるようにノードを適切に設定する必要があります。

25.6.1. Quality of Service (QoS) 層でのメモリー予約

experimental-qos-reserved パラメーターを使用して、特定の QoS レベルの Pod で予約されるメモリーのパーセンテージを指定することができます。この機能は、最も低い OoS クラスの Pod が高いQoS クラスの Pod で要求されるリソースを使用できないようにするために要求されたリソースの予約を試行します。

高い QOS レベル用にリソースを予約することで、リソース制限を持たない Pod が高い QoS レベルのPod で要求されるリソースを侵害しないようにできます。

experimental-qos-reserved パラメーターを設定するには、適切なノード設定マップを編集します。

kubeletArguments: cgroups-per-qos: - true cgroup-driver: - 'systemd' cgroup-root: - '/' experimental-qos-reserved: 1 - 'memory=50%'

Pod のリソース要求が QoS レベルでどのように予約されるかを指定します。

OpenShift Container Platform は、以下のように experimental-qos-reserved パラメーターを使用します。

experimental-qos-reserved=memory=100% の値は、 Burstable および BestEffort QOS クラスが、これらより高い QoS クラスで要求されたメモリーを消費するのを防ぎます。これにより、Guaranteed および Burstable ワークロードのメモリーリソースの保証レベルを上げることが優先され、BestEffort および Burstable ワークロードでの OOM が発生するリスクが高まります。

experimental-qos-reserved=memory=50% の値は、Burstable および BestEffort QOS クラ


271

experimental-qos-reserved=memory=50% の値は、Burstable および BestEffort QOS クラスがこれらより高い QoS クラスによって要求されるメモリーの半分を消費することを許可します。

experimental-qos-reserved=memory=0% の値は、Burstable および BestEffort QoS クラスがノードの割り当て可能分を完全に消費することを許可しますが (利用可能な場合)、これにより、Guaranteed ワークロードが要求したメモリーにアクセスできなくなるリスクが高まります。この状況により、この機能は無効にされています。

25.6.2. CPU 制限の実施

デフォルトで、ノードは Linux カーネルの CPU CFS クォータのサポートを使用して指定された CPU制限を実施します。ノードで CPU 制限を実施する必要がない場合は、以下のパラメーターを含めるようにノード設定マップを変更してその実施を無効にすることができます。

kubeletArguments: cpu-cfs-quota: - "false"

CPU 制限の実施が無効にされる場合、それがノードに与える影響を理解しておくことが重要になります。

コンテナーが CPU の要求をする場合、これは Linux カーネルの CFS 共有によって引き続き実施されます。

コンテナーが CPU の要求を明示的に指定しないものの、制限を指定する場合には、要求は指定された制限にデフォルトで設定され、Linux カーネルの CFS 共有で実施されます。

コンテナーが CPU の要求と制限の両方を指定する場合、要求は Linux カーネルの CFS 共有で実施され、制限はノードに影響を与えません。

25.6.3. システムリソースのリソース予約

スケジューラーは、Pod 要求に基づいてノード上のすべての Pod に十分なリソースがあることを確認します。これは、ノード上のコンテナーの要求の合計がノード容量を上回らないことを確認します。これには、ノードで起動されたすべてのコンテナーが含まれますが、クラスターの範囲外で起動されたコンテナーやプロセスは含まれません。

ノード容量の一部を予約して、クラスターが機能できるようノードで実行する必要のあるシステムデーモン用に確保することが推奨されます (sshd、docker など)。とくに、メモリーなどの圧縮できないリソースのリソース予約を行うことが推奨されます。

Pod 以外のプロセスのリソースを明示的に予約する必要がある場合、以下の 2 つの方法でこれを実行できます。

優先される方法として、スケジューリングに利用できるリソースを指定してノードリソースを割り当てることができます。詳細は、「ノードリソースの割り当て」を参照してください。

2 つ目の方法として resource-reserver Pod を作成できます。この Pod は、クラスターによるスケジュールの対象外となるようノードで容量を確保します。以下は例になります。

例25.1 resource-reserver Pod の定義



272

1

2

1

name: resource-reserverspec: containers: - name: sleep-forever image: gcr.io/google_containers/pause:0.8.0 resources: limits: cpu: 100m 1 memory: 150Mi 2

クラスターに認識されないホストレベルのデーモン用にノード上で確保する CPU の量です。

クラスターに認識されないホストレベルのデーモン用にノード上で確保するメモリーの量です。

定義は resource-reserver.yaml のようなファイルに保存し、ファイルを /etc/origin/node/ または別の指定がある場合は --config=<dir> などのノード設定ディレクトリーに置くことができます。

さらに、ディレクトリーを該当するノード設定マップの kubeletArguments.config パラメーターで指定し、ノード設定ディレクターから定義を読み取るようにノードサーバーを設定します。

kubeletArguments: config: - "/etc/origin/node" 1

--config=<dir> が指定されている場合、ここでは <dir> を使用します。

resource-reserver.yaml ファイルが有効な状態でノードサーバーを起動すると、sleep-foreverコンテナーも起動します。スケジューラーはノードの残りの容量も考慮し、クラスター Pod を配置する場所を適宜調整します。

resource-reserver Pod を削除するには、ノード設定ディレクトリーから resource-reserver.yaml ファイルを削除するか、またはこれを移動することができます。

25.6.4. カーネルの調整可能なフラグ

ノードが起動すると、メモリー管理用のカーネルの調整可能なフラグが適切に設定されます。カーネルは、物理メモリーが不足しない限り、メモリーの割り当てに失敗するこはありません。

この動作を確認するために、ノードはカーネルに対し、常にメモリーのオーバーコミットを実行するように指示します。

$ sysctl -w vm.overcommit_memory=1

また、ノードはカーネルに対し、メモリーが不足する状況でもパニックにならないように指示します。その代わりに、カーネルの OOM killer は優先順位に基づいてプロセスを強制終了します。

$ sysctl -w vm.panic_on_oom=0


273

注記注記

上記のフラグはノード上にすでに設定されているはずであるため、追加のアクションは不要です。

25.6.5. swap メモリーの無効化

QoS 保証を維持するため、swap はノード上でデフォルトで無効にすることができます。そうしない場合、ノードの物理リソースがオーバーサブスクライブし、Pod の配置時の Kubernetes スケジューラーによるリソース保証が影響を受ける可能性があります。

たとえば、2 つの Guaranteed pod がメモリー制限に達した場合、それぞれのコンテナーが swap メモリーを使用し始める可能性があります。十分な swap 領域がない場合には、pod のプロセスはシステムのオーバーサブスクライブのために終了する可能性があります。

swap を無効にするには、以下を実行します。

$ swapoff -a

swap を無効にしないと、ノードが MemoryPressure にあることを認識しなくなり、Pod がスケジューリング要求に対応するメモリーを受け取れなくなります。結果として、追加の Pod がノードに配置され、メモリー不足の状態が加速し、最終的にはシステムの Out Of Memory (OOM) イベントが発生するリスクが高まります。

重要重要

swap が有効にされている場合、利用可能なメモリーについてのリソース不足の処理(out of resource handling) のエビクションしきい値は予想通りに機能しなくなります。メモリー不足の状態の場合に Pod をノードからエビクトし、Pod を不足状態にない別のノードで再スケジューリングできるようにリソース不足の処理 (out of resourcehandling) を利用できるようにします。


274

第26章 INGRESS トラフィックの固有の外部 IP の割り当て

26.1. 概要

外部トラフィックをクラスターにつなぐ方法の 1 つとして、ExternalIP または IngressIP アドレスを使用することができます。

重要重要

この機能は、クラウド以外のデプロイメントでのみサポートされます。クラウド(GCE、AWS、および OpenStack) デプロイメントの場合、ロードバランサーサービスを使用し、クラウドの自動デプロイメントでサービスのエンドポイントをターゲットに設定します。

OpenShift Container Platform は 2 つの IP アドレスのプールをサポートします。

IngressIP は、サービスの外部 IP アドレスを選択する場合に Loadbalancer で使用されます。

ExternalIP は、ユーザーが設定されたプールから特定 IP を選択する場合に使用されます。

注記注記

これらはいずれも、ネットワークインターフェースコントローラー (NIC) または仮想イーサネット、または外部ルーティングのいずれであっても、使用される OpenShiftContainer Platform ホストのデバイスに設定される必要があります。この場合、Ipfailover はホストを設定し、NIC を設定するため、これを使用することが推奨されます。

IngressIP および ExternalIP はいずれも外部トラフィックのクラスターへのアクセスを可能にし、適切にルーティングされている場合に、外部トラフィックはサービスが公開する TCP/UDP ポート経由でサービスのエンドポイントに到達できます。これは、外部 IP をサービスに手動で割り当てる際に、制限された数の共有 IP アドレスのポート領域を管理しなくてはならない場合よりも単純になります。またこれらのアドレスは、高可用性を設定する場合に仮想 IP (VIP) としても使用できます。

OpenShift Container Platform は IP アドレスの自動および手動割り当ての両方をサポートしており、それぞれのアドレスは 1 つのサービスの最大数に割り当てられることが保証されます。これにより、各サービスは、ポートが他のサービスで公開されているかによらず、自らの選択したポートを公開できます。

26.2. 制限

ExternalIP を使用するには、以下を実行できます。

externalIPNetworkCIDRs 範囲から IP アドレスを選択します。

マスター設定ファイルで、IP アドレスを ingressIPNetworkCIDR プールから割り当てます。この場合、OpenShift Container Platform はロードバランサーサービスタイプのクラウド以外のバージョンを実装し、IP アドレスをサービスに割り当てます。

注意注意

割り当てた IP アドレスがクラスター内の 1 つ以上のノードで終了することを確認する必要があります。既存の oc adm ipfailover を使用して外部 IP の可用性が高いことを確認します。

第第26章章 INGRESS トラフィックの固有の外部トラフィックの固有の外部 IP の割り当ての割り当て

275

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#master-node-config-network-config


手動で設定された外部 IP の場合、起こり得るポートのクラッシュについては「first-come, first-served(先着順)」で処理されます。ポートを要求する場合、その IP アドレスに割り当てられていない場合にのみ利用可能となります。以下は例になります。

手動で設定された外部手動で設定された外部 IP のポートのクラッシュ例のポートのクラッシュ例

2 つのサービスが同じ外部 IP アドレス 172.7.7.7 で手動で設定されている。

MongoDB service A がポート 27017 を要求し、次に MongoDB service B が同じポートを要求する。最初の要求がこのポートを取得します。

ただし、Ingress コントローラーが外部 IP を割り当てる場合、ポートのクラッシュは問題とはなりません。コントローラーが各サービスに固有のアドレスを割り当てるためです。

26.3. 固有の外部 IP を使用するようクラスターを設定する

クラウド以外のクラスターで、ingressIPNetworkCIDR はデフォルトで 172.29.0.0/16 に設定されます。クラスター環境がこのプライベート範囲をまだ使用していない場合は、デフォルトを使用できます。ただし、異なる範囲を使用する必要がある場合は、ingress IP を割り当てる前に、/etc/origin/master/master-config.yaml ファイルで ingressIPNetworkCIDR を設定する必要があります。次に、マスターサービスを再起動します。

注意注意

LoadBalancer タイプのサービスに割り当てられる外部 IP は常に ingressIPNetworkCIDR の範囲にあります。ingressIPNetworkCIDR が割り当てられた外部 IP がこの範囲内からなくなるように変更される場合、影響を受けるサービスには、新規の範囲と互換性のある新規の外部 IP が割り当てられます。

注記注記

高可用性を使用している場合、この範囲は 255 IP アドレスより少なくなければなりません。

/etc/origin/master/master-config.yaml のサンプルのサンプル

26.3.1. サービスの Ingress IP の設定

Ingress IP を割り当てるには、以下を実行します。

1. loadBalancerIP 設定で特定の IP を要求する LoadBalancer サービスの YAML ファイルを作成します。

LoadBalancer 設定サンプル設定サンプル

networkConfig: ingressIPNetworkCIDR: 172.29.0.0/16

apiVersion: v1kind: Servicemetadata: name: egress-1spec: ports: - name: db


276


2. Pod に LoadBalancer サービスを作成します。

3. 外部 IP のサービスを確認します。たとえば、myservice という名前のサービスを確認します。

LoadBalancer タイプのサービスに外部 IP が割り当てられている場合、出力には IP が表示されます。

26.4. 開発またはテスト目的での INGRESS CIDR のルーティング

ingress CIDR のトラフィックをクラスターのノードに送信する静的ルートを追加します。以下は例になります。

# route add -net 172.29.0.0/16 gw 10.66.140.17 eth0

上記の例では、172.29.0.0/16 は ingressIPNetworkCIDR、10.66.140.17 はノード IP です。

26.4.1. サービス externalIP

クラスターの内部 IP アドレスに加えて、アプリケーション開発者はクラスターの外部にある IP アドレスを設定することができます。OpenShift Container Platform 管理者は、トラフィックがこの IP を持つノードに到達することを確認する必要があります。

externalIP は、master-config.yaml ファイルで設定される externalIPNetworkCIDRs 範囲から管理者によって選択される必要があります。master-config.yaml が変更される際に、マスターサービスは再起動される必要があります。


externalIPNetworkCIDR /etc/origin/master/master-config.yaml のサンプルのサンプル

サービスサービス externalIP 定義定義 (JSON)

port: 3306 loadBalancerIP: 172.29.0.1 type: LoadBalancer selector: name: my-db-selector

$ oc create -f loadbalancer.yaml

$ oc get svc myservice

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGEmyservice 172.30.74.106 172.29.0.1 3306/TCP 30s

networkConfig: externalIPNetworkCIDR: 172.47.0.0/24

{ "kind": "Service", "apiVersion": "v1",

第第26章章 INGRESS トラフィックの固有の外部トラフィックの固有の外部 IP の割り当ての割り当て

277

1 ポートが公開される外部 IP アドレスの一覧です (これは内部 IP アドレス一覧に追加される一覧です)。

"metadata": { "name": "my-service" }, "spec": { "selector": { "app": "MyApp" }, "ports": [ { "name": "http", "protocol": "TCP", "port": 80, "targetPort": 9376 } ], "externalIPs" : [ "80.11.12.10" 1 ] }}


278

第27章 OUT OF RESOURCE (リソース不足) エラーの処理

27.1. 概要

このトピックでは、OpenShift Container Platform がメモリー不足 (OOM) やディスク領域不足の状況を防ぐためのベストエフォートの取り組みについて説明します。

ノードは、利用可能なコンピュートリソースが少ない場合に安定性を維持する必要があります。これは、メモリーやディスクなどの圧縮不可能なリソースを扱う場合にとくに重要になります。どちらかのリソースが消費されると、ノードは不安定になります。

管理者は、エビクションポリシーを使用してノードをプロアクティブにモニターし、ノードでコンピュートリソースおよびメモリーリソースが不足する状況を防ぐことができます。

このトピックでは、OpenShift Container Platform がリソース不足の状況に対処する方法についての情報を提供し、シナリオ例や推奨される対策について説明します。

リソースの回収

Pod のエビクション

Pod のスケジューリング

リソース不足および Out of Memory Killer

警告警告

swap メモリーがノードに対して有効にされる場合、ノードは MemoryPressure 状態にあるかどうかを検知できません。

メモリーベースのエビクションを利用するには、オペレーターは swap を無効にする必要があります。

27.2. エビクションポリシーの設定

エビクションポリシーにより、ノードが利用可能なリソースが少ない状況で実行されている場合に 1 つ以上の Pod が失敗することを許可します。Pod の失敗により、ノードは必要なリソースを回収できます。

エビクションポリシーは、エビクションシグナルと、ノード設定ファイルまたはコマンドラインで設定される特定のエビクションしきい値の組み合わせです。エビクションは、ノードがしきい値を超えるPod に対して即時のアクションを実行するハードエビクションか、またはノードがアクションを実行する前の猶予期間を許可するソフトエビクションのどちらかになります。

注記注記


第第27章章 OUT OF RESOURCE (リソース不足リソース不足) エラーの処理エラーの処理

279

適切に設定されたエビクションポリシーを使用することで、ノードは、プロアクティブにモニターし、コンピュートリソースを完全に使い切る事態を防ぐことができます。

注記注記

ノードによる Pod の失敗が生じる場合、Pod 内のすべてのコンテナーが停止し、PodPhase は Failed に切り替わります。

ノードは、以下のようにディスクの不足状態を検出する際に nodefs および imagefs ファイルシステムのパーティションをサポートします。

nodefs または rootfs は、ノードがローカルディスクボリューム、デーモンログ、emptyDir など ( / を指定するファイルシステムなど) に使用するファイルシステムです。rootfs には、openshift.local.volumes (デフォルトは /var/lib/origin/openshift.local.volumes) が含まれます。

imagefs は、コンテナーランタイムがイメージおよび個別のコンテナーの書き込み可能な層を保存するために使用するファイルシステムです。エビクションのしきい値は、imagefs については 85% になります。imagefs ファイルシステムはランタイムによって異なり、Docker の場合は使用しているストレージドライバーに応じます。

Docker の場合:

devicemapper ストレージドライバーを使用している場合は、imagefs はシンプールになります。Docker デーモンに --storage-opt dm.basesize フラグを設定してコンテナーの読み取り/書き込み層を制限できます。

$ sudo dockerd --storage-opt dm.basesize=50G

overlay2 ストレージドライバーを使用している場合、imagefs は /var/lib/docker/overlay2が含まれるファイルシステムになります。

オーバーレイドライバーを使用する CRI-O の場合、imagefs はデフォルトで/var/lib/containers/storage になります。

注記注記

ローカルストレージの分離 (一時ストレージ) を使用せず、XFS クォータ(volumeConfig) を使用していない場合、Pod でローカルディスクの使用を制限することはできません。

27.2.1. ノード設定を使用したポリシーの作成

エビクションポリシーを設定するには、ノード設定ファイルを編集して eviction-hard または eviction-soft パラメーターでエビクションしきい値を指定します。

例:

例27.1 ハードエビクションについてのノード設定ファイルのサンプル

kubeletArguments: eviction-hard: 1 - memory.available<100Mi 2 - nodefs.available<10%


280

https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase

1

2

1

2

3

- nodefs.inodesFree<5% - imagefs.available<15% - imagefs.inodesFree<10%

エビクションのタイプ: ハードエビクションにこのパラメーターを使用します。

特定のエビクショントリガーシグナルに基づくエビクションのしきい値です。

注記注記

inodesFree パラメーターのパーセント値を指定する必要があります。他のパラメーターのパーセンテージまたは数値を指定できます。

例27.2 ソフトエビクションについてのノード設定ファイルのサンプル

kubeletArguments: eviction-soft: 1 - memory.available<100Mi 2 - nodefs.available<10% - nodefs.inodesFree<5% - imagefs.available<15% - imagefs.inodesFree<10% eviction-soft-grace-period: 3 - memory.available=1m30s - nodefs.available=1m30s - nodefs.inodesFree=1m30s - imagefs.available=1m30s - imagefs.inodesFree=1m30s

エビクションのタイプ: ソフトエビクションにこのパラメーターを使用します。

特定のエビクショントリガーシグナルに基づくエビクションのしきい値です。

ソフトエビクションの猶予期間です。パフォーマンスを最適化するためにデフォルト値のままにします。

変更を有効するために OpenShift Container Platform サービスを再起動します。

# systemctl restart atomic-openshift-node

27.2.2. エビクションシグナルについて

以下の表にあるシグナルのいずれかに基づいてエビクションの意思決定をトリガーするようノードを設定することができます。エビクションシグナルは、しきい値と共にエビクションのしきい値に追加できます。

各シグナルの値は、ノード要約 API に基づいて Description 列で説明されています。

シグナルを表示するには、以下を実行します。


281

curl <certificate details> \ https://<master>/api/v1/nodes/<node>/proxy/stats/summary

表27.1 サポートされるエビクションシグナル

ノードのノードの状態状態

エビクショエビクションシグナルンシグナル

値値説明説明

MemoryPressure

memory.available

memory.available= node.status.capacity[memory] - node.stats.memory.workingSet

ノードの利用可能なメモリーがエビクションしきい値を超えている。

DiskPressure

nodefs.available

nodefs.available =node.stats.fs.available

ノードの root ファイルシステムまたはイメージファイルシステムのいずれかで利用可能なディスク領域がエビクションしきい値を超えている。

nodefs.inodesFree

nodefs.inodesFree = node.stats.fs.inodesFree

imagefs.available

imagefs.available= node.stats.runtime.imagefs.available

imagefs.inodesFree

imagefs.inodesFree = node.stats.runtime.imagefs.inodesFree

上記のシグナルのそれぞれは、リテラル値またはパーセンテージベースの値のいずれかをサポートしま


282

上記のシグナルのそれぞれは、リテラル値またはパーセンテージベースの値のいずれかをサポートします。ただし、パーセントの値が必要な inodesFree を除きます。パーセンテージベースの値は、各シグナルに関連付けられる合計容量との関連で計算されます。

スクリプトは kubelet が実行する一連の手順を使用し、cgroup から memory.available 値を派生させます。スクリプトは計算から非アクティブなファイルメモリー (つまり、非アクティブな LRU リストのファイルベースのメモリーのバイト数) を計算から除外します。非アクティブなファイルメモリーはリソースの不足時に回収可能になることが想定されます。

注記注記

free -m はコンテナーで機能しないため、free -m のようなツールは使用しないでください。

OpenShift Container Platform はこれらのファイルシステムを 10 秒ごとにモニターします。

ボリュームおよびログを専用ファイルシステムに保存する場合、ノードはそのファイルシステムをモニターしません。

注記注記

ノードはディスク不足に基づくエビクションの意思決定をトリガーする機能をサポートします。ディスク不足のために Pod をエビクトする前に、ノードはコンテナーおよびイメージのガべージコレクションも実行します。

27.2.3. エビクションのしきい値について

しきい値をノード設定ファイルに追加することで、ノードのリソース回収をトリガーするエビクションしきい値を指定するようノードを設定することができます。

関連付けられた猶予期間とは別にエビクションのしきい値に達する場合、ノードは、ノードがメモリー不足またはディスク不足であることを示す状態を報告します。これにより、スケジューラーがリソース回収の試行期間中に Pod をノードにスケジュールすることを防ぐことができます。

ノードは、node-status-update-frequency 引数で指定される頻度で、ノードのステータス更新を継続的に報告します。これはデフォルトで 10s (10 秒) に設定されています。

エビクションのしきい値は、しきい値に達する際にノードが即時にアクションを実行する場合にハードとなり、リソース回収前の猶予期間を許可する場合はソフトになります。

注記注記

ソフトエビクションは、特定レベルの使用状況をターゲットとしているものの、一時的な値の上昇を許容できる場合により一般的に使用されます。ソフトエビクションは、ハードエビクションのしきい値よりも低く設定することが推奨されますが、期間はオペレーターが固有に設定できます。システム予約もソフトエビクションのしきい値以上に設定する必要があります。

ソフトエビクションのしきい値は高度な機能になります。ソフトエビクションのしきい値の使用を試行する前にハードエビクションのしきい値を設定してください。

しきい値は以下の形式で設定されます。

<eviction_signal><operator><quantity>


283

eviction-signal 値は任意のサポートされるエビクションシグナルにすることができます。

operator 値は < になります。

quantity 値は、Kubernetes で使用される数量表現と一致している必要があり、% トークンで終了する場合はパーセンテージで表現されます。

たとえば、オペレーターが 10Gi メモリーのあるノードを持つ場合で、オペレーターは利用可能なメモリーが 1Gi を下回る場合にエビクションを導入する必要がある場合、メモリーのエビクションしきい値は以下のいずれかで指定することができます。

memory.available<1Gimemory.available<10%

注記注記

ノードはエビクションしきい値の評価とモニターを 10 秒ごとに実行し、値を変更することはできません。これはハウスキープ処理の間隔になります。

27.2.3.1. ハードエビクションのしきい値についてハードエビクションのしきい値について

ハードエビクションのしきい値には猶予期間がなく、しきい値を超えることが確認される場合には、ノードは関連付けられた不足状態にあるリソースを回収するために即時のアクションを実行します。ハードエビクションのしきい値に達する場合、ノードは正常な終了なしに Pod を即時に強制終了します。

ハードエビクションのしきい値を設定するには、「ポリシー作成のためのノード設定の使用」に示されるように、エビクションしきい値を eviction-hard の下にあるノード設定ファイルに追加します。

ハードエビクションのしきい値が設定されたノード設定ファイルのサンプルハードエビクションのしきい値が設定されたノード設定ファイルのサンプル

kubeletArguments: eviction-hard: - memory.available<500Mi - nodefs.available<500Mi - nodefs.inodesFree<5% - imagefs.available<100Mi - imagefs.inodesFree<10%

この例は一般的なガイドラインを示すためのもので、推奨される設定ではありません。

27.2.3.1.1. デフォルトのハードエビクションしきい値

OpenShift Container Platform は、eviction-hard の以下のデフォルト設定を使用します。

...kubeletArguments: eviction-hard: - memory.available<100Mi - nodefs.available<10% - nodefs.inodesFree<5% - imagefs.available<15%...


284

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/resources.md#resource-quantities

27.2.3.2. ソフトエビクションのしきい値についてソフトエビクションのしきい値について

ソフトエビクションのしきい値は、エビクションしきい値と管理者が指定する必要な猶予期間のペアを設定します。ノードは、猶予期間が経過するまではエビクションシグナルに関連付けられたリソースを回収しません。猶予期間がノード設定ファイルに指定されない場合、ノードは起動時にエラーを出して失敗します。

さらにソフトエビクションのしきい値に達する場合、オペレーターは Pod をノードからエビクトする際に使用する Pod 終了の猶予期間として許可される最長期間を指定できます。eviction-max-pod-grace-period が指定されると、ノードは pod.Spec.TerminationGracePeriodSeconds と maximum-allowed-grace-period の値の小さい方を使用します。これが指定されていない場合は、ノードは正常な停止なしに、Pod を即時に強制終了します。

ソフトエビクションのしきい値については、以下のフラグがサポートされています。

eviction-soft: エビクションしきい値のセットです (例: memory.available<1.5Gi)。対応する猶予期間を経過してからこの値に達すると、Pod のエビクションをトリガーします。

eviction-soft-grace-period: エビクションの猶予期間のセットです (例: memory.available=1m30s)。これは、Pod のエビクションをトリガーするまでソフトエビクションのしきい値が有効である期間に対応します。

eviction-max-pod-grace-period: ソフトエビクションのしきい値に達する際の Pod の終了時に使用される最長で許可される猶予期間 (秒単位) です。

ソフトエビクションのしきい値を設定するには、「ポリシー作成のためのノード設定の使用」に示されるように、エビクションのしきい値を eviction-soft の下にあるノード設定ファイルに追加します。

ソフトエビクションのしきい値が設定されたノード設定ファイルのサンプルソフトエビクションのしきい値が設定されたノード設定ファイルのサンプル

kubeletArguments: eviction-soft: - memory.available<500Mi - nodefs.available<500Mi - nodefs.inodesFree<5% - imagefs.available<100Mi - imagefs.inodesFree<10% eviction-soft-grace-period: - memory.available=1m30s - nodefs.available=1m30s - nodefs.inodesFree=1m30s - imagefs.available=1m30s - imagefs.inodesFree=1m30s

この例は一般的なガイドラインを示すためのもので、推奨される設定ではありません。

27.3. スケジューリング用のリソース量の設定

スケジューラーがノードを完全に割り当て、エビクションを防止できるようにするために、スケジューリングで利用できるノードリソースの数量を制御できます。

system-reserved は、Pod のデプロイおよび system-daemon 用にスケジューラーで利用可能なリソース量と同じサイズを設定します。system-reserved は、sshd や NetworkManager などのオペレーティングシステムデーモン用に予約されるリソースです。Pod が割り当て可能なリソースの要求量を超える量を使用する場合にはエビクションが発生します。


285

1

ノードは 2 つの値を報告します。

Capacity: マシンにあるリソースの量です。

Allocatable: スケジューリング用に利用可能にされるリソースの量です。

割り当て可能なリソースの量を設定するには、適切なノード設定マップを編集して、eviction-hard または eviction-soft の system-reserved パラメーターを追加するか、または変更します。

kubeletArguments: eviction-hard: 1 - "memory.available<500Mi" system-reserved: - "memory=1.5Gi"

このしきい値は、eviction-hard または eviction-soft のいずれかにできます。

system-reserved 設定の適切な値を判断するには、ノード要約 API を使用してノードのリソース使用率を判別します。詳細は、「割り当てられたリソースのノードの設定」を参照してください。

変更を有効するために OpenShift Container Platform サービスを再起動します。


27.4. ノードの状態変動の制御

ノードがソフトエビクトしきい値の上下で変動しているものの、関連付けられた猶予期間を超えていない場合、対応するノード状態は true と false の間で変動します。これにより、スケジュールの問題が生じる場合があります。

この変動を防ぐには、eviction-pressure-transition-period パラメーターを設定して、ノードが不足状態からの切り換え前に待機する期間を制御します。

1. <resource_type>=<resource_quantity> のペアのセットを使用して、パラメーターを編集するか、またはノード設定マップの kubeletArguments セクションに追加します。

kubeletArguments: eviction-pressure-transition-period="5m"

ノードは、指定期間の指定された不足状態についてエビクションしきい値に達していないことを確認する場合に状態を false に戻します。

注記注記

調整を行う前にデフォルト値 (5 分) を使用します。このデフォルト値のオプションには、システムを安定させ、安定した状態になる前にスケジューラーが新規Pod をノードに割り当てないようにすることが意図されています。

2. 変更を有効するために OpenShift Container Platform サービスを再起動します。



286

27.5. ノードレベルのリソースの回収

エビクション条件が満たされる場合、ノードはシグナルが定義されたしきい値を下回るまで、不足状態にあるリソースを回収するプロセスを実行します。このプロセスでは、ノードはいずれの新規 Pod のスケジューリングもサポートしません。

ノードは、ホストシステムにコンテナーランタイム用の専用 imagefs が設定されているかどうかに基づいて、エンドユーザー Pod のエビクト前にノードレベルのリソース回収を試行します。

Imagefs が設定されている場合ホストシステムに imagefs が設定されている場合:

nodefs ファイルシステムがエビクションしきい値を満たす場合、ノードは以下の順番でディスク領域を解放します。

実行されない Pod/コンテナーの削除

imagefs ファイルシステムがエビクションのしきい値を満たす場合、ノードは以下の順番でディスク領域を解放します。

すべての未使用イメージの削除

Imagefs が設定されていない場合ホストシステムに imagefs がされていない場合:

nodefs ファイルシステムがエビクションしきい値を満たす場合、ノードは以下の順番でディスク領域を解放します。

実行されない Pod/コンテナーの削除

すべての未使用イメージの削除

27.6. POD エビクションについて

エビクションしきい値に達し、猶予期間を経過している場合、ノードはシグナルが定義されたしきい値を下回るまで Pod のエビクトのプロセスを実行します。

ノードは、エビクトする Pod を QoS (Quality of Service) に基づいてランク付けし、同じQoS レベルにある Pod については Pod のスケジューリング要求との関連で不足状態のリソースの消費量に基づいてランク付けします。

それぞれの QoS レベルには OOM スコープが設定されており、Linux out-of-memory ツール (OOMkiller) はこのスコープを使用して強制終了する Pod を判別します。以下の「QoS および Out ofMemory Killer について」を参照してください。

以下の表には、各 QoS レベルと関連付けられた OOM スコアが一覧表示されています。

表27.2 Quality of Service (QoS) レベル

QoS (Quality of Service) 説明説明

Guaranteed 要求との関連で不足状態にあるリソースの最大量を消費する Pod が最初に失敗します。いずれの Pod もその要求を超えていない場合、ストラテジーは不足状態にあるリソースを最も多く消費する Pod をターゲットにします。


287

Burstable リソースの要求との関連で、不足状態にあるリソースの最大量を消費する Podが最初に失敗します。いずれの Pod もその要求を超えていない場合、ストラテジーは不足状態にあるリソースを最も多く消費する Pod をターゲットにします。

BestEffort 不足状態にあるリソースの最大量を消費する Pod が最初に失敗します。

QoS (Quality of Service) 説明説明

Guaranteed Pod は、(ノード、docker、journald などの) システムデーモンがシステム予約か、または kube 予約の割り当てを使用して予約されている量よりも多くのリソースを消費しているか、またはノードに Guaranteed Pod のみが残っているのでない限り、別の Pod のリソース消費が原因でエビクトされることはありません。

ノードに Guaranteed Pod のみが残っている場合、ノードはノードの安定性に最も影響の少ない Guaranteed Pod をエビクトし、他の Guaranteed Pod に対する予想外の消費による影響を制限します。

ローカルディスクは BestEffort リソースです。必要な場合は、ノードは DiskPressure の発生時にディスクを回収するため、Pod を 1 度に 1 つずつエビクトします。ノードは QoS に基づいて Pod をランク付けします。ノードが inode の不足状態に対応している場合、ノードは QoS の最も低いレベルにあるPod を最初にエビクトして inode を回収します。ノードが利用可能なディスクの不足状態に対応している場合は、ノードはローカルディスクを最も多く消費する QoS 内の Pod をランク付けし、それらのPod を最初にエビクトします。

27.6.1. QoS および Out of Memory Killer について

ノードによるメモリーの回収が可能になる前にシステムの OOM (Out of Memory) イベントが発生する場合、ノードの動作はこれに対応する OOM killer によって異なります。

ノードは、Pod の QoS に基づいて各コンテナーの oom_score_adj 値を設定します。

表27.3 Quality of Service (QoS) レベル

QoS (Quality of Service) oom_score_adj 値値

Guaranteed -998

Burstable min(max(2, 1000 - (1000 * memoryRequestBytes) /machineMemoryCapacityBytes), 999)

BestEffort 1000

ノードがシステムの OOM イベントが発生する前にメモリーを回収できない場合、oom_killer は oom_score を計算します。

% of node memory a container is using + `oom_score_adj` = `oom_score`

次にノードは、スコアの最も高いコンテナーを強制終了します。


288

スケジューリング要求に関連してメモリーを最も多く消費する、QoS の最も低いレベルにあるコンテナーが最初に失敗します。

Pod のエビクションとは異なり、Pod コンテナーが OOM が原因で失敗する場合、ノードはノードの再起動ポリシーに基づいてこのコンテナーを再起動できます。

27.7. POD スケジューラーおよび OOR 状態について

スケジューラーは、追加の Pod をノードに配置する際にノードの状態を表示します。たとえば、ノードに以下のようなエビクションのしきい値がある場合は、以下のようになります。

eviction-hard is "memory.available<500Mi"

さらに利用可能なメモリーが 500Mi を下回る場合、ノードは Node.Status.Conditions の MemoryPressure の値を true として報告します。

表27.4 ノードの状態およびスケジューラーの動作

ノードの状態ノードの状態スケジューラーの動作スケジューラーの動作

MemoryPressure ノードがこの状態を報告する場合、スケジューラーは BestEffort Pod をノードに配置しません。

DiskPressure ノードがこの状態を報告する場合、スケジューラーは追加の Pod をノードに配置しません。

27.8. シナリオ例

以下のシナリオについて考えてみましょう。

オペレーター:

メモリー容量が 10Gi のノードがある。

システムデーモン (カーネル、ノードなど) のメモリー容量の 10% を予約する必要がある。

システムの OOM の悪化または発生の可能性を軽減するため、メモリー使用率が 95% の時点でPod をエビクトする必要がある。

この設定から、system-reserved にはエビクションのしきい値でカバーされるメモリー量が含まれていることを読み取ることができます。

この容量に達するのは、一部の Pod による使用がその要求を超えるか、またはシステムによる使用が 1Gi を超える場合のいずれかになります。

ノードに 10 Gi の容量があり、システムデーモン (system-reserved) 用に 10% の容量を予約する必要がある場合、以下の計算を実行します。

capacity = 10 Gisystem-reserved = 10 Gi * .1 = 1 Gi

割り当て可能なリソースの量は以下のようになります。


289

allocatable = capacity - system-reserved = 9 Gi

これは、デフォルトでスケジューラーはノードに対し、9 Gi のメモリーを要求する Pod をスケジュールすることを意味します。

エビクションをオンに設定して、エビクションのトリガーが利用可能なメモリーが 30 秒間で 10% の容量を下回ることをノードで確認される場合や、5% の容量を下回る場合には即時にトリガーされるようにする必要がある場合、スケジューラーで 8Gi が割り当て可能であることを確認できる必要があります。そのため、システム予約ではエビクションしきい値の大きい方の値がカバーされている必要があります。

capacity = 10 Gieviction-threshold = 10 Gi * .1 = 1 Gisystem-reserved = (10Gi * .1) + eviction-threshold = 2 Giallocatable = capacity - system-reserved = 8 Gi

以下を適切なノード設定マップに追加します。

kubeletArguments: system-reserved: - "memory=2Gi" eviction-hard: - "memory.available<.5Gi" eviction-soft: - "memory.available<1Gi" eviction-soft-grace-period: - "memory.available=30s"

この設定により、スケジューラーは Pod が設定される要求を下回る量のメモリーを使用することを前提とし、メモリー不足を即時に発生させ、エビクションをトリガーする Pod をノードに配置しないようにします。

27.9. 推奨される対策

27.9.1. DaemonSet および Out of Resource (リソース不足) の処理

ノードが DaemonSet によって作成された Pod をエビクトすると、Pod は即時に再作成され、同じノードに再スケジュールされます。これが生じるのは、ノードが DaemonSet から作成された Pod とそれ以外のオブジェクトを区別することができないためです。

通常 DaemonSet は作成する Pod がエビクションの候補として特定されることを防ぐため、BestEffortPod を作成しません。DaemonSet が起動する適切な Pod は Guaranteed Pod になります。


290

第28章ルーターのモニタリングおよびデバッグ

28.1. 概要

基礎となる実装によっては、実行中のルーターを複数の方法でモニターすることができます。このトピックでは、HAProxy テンプレートルーターおよびその正常性を確認するためのコンポーネントについて説明します。

28.2. 統計の表示

HAProxy ルーターは、HAProxy 統計の web リスナーを公開します。ルーターのパブリック IP アドレスと適切に設定されたポート (デフォルトは 1936) を入力して統計ページを表示し、プロンプトが出されたら管理者パスワードを入力します。このパスワードおよびポートはルーターのインストール時に設定されますが、それらはコンテナーの haproxy.config ファイルを表示して確認することができます。

Prometheus 形式で未加工統計を抽出するには、以下を実行します。

$ curl -u <user>:<password> -kv <router_IP>:<STATS_PORT>/metrics

このコマンドについての必要な情報を取得する方法については、「Exposing Router Metrics」を参照してください。

28.3. 統計ビューの無効化

デフォルトで、HAProxy 表示はポート 1936 で公開されます (パスワードで保護されたアカウントを使用する)。HAProxy 統計の公開を無効にするには、統計ポート番号として 0 を指定します。

$ oc adm router hap --service-account=router --stats-port=0

注: HAProxy は依然として統計を収集し、保存しますが、web リスナー経由での統計の公開が行われなくなります。要求を HAProxy ルーターコンテナー内の HAProxy AF_UNIX ソケットに送信すれば、依然として統計にアクセスできます。

$ cmd="echo 'show stat' | socat - UNIX-CONNECT:/var/lib/haproxy/run/haproxy.sock"$ routerPod=$(oc get pods --selector="router=router" \ --template="{{with index .items 0}}{{.metadata.name}}{{end}}")$ oc exec $routerPod -- bash -c "$cmd"

重要重要

セキュリティー保護の理由により oc exec コマンドは、特権付きコンテナーにアクセスする場合には機能しません。その代わりに、ノードホストに対して SSH を実行して必要なコンテナーで docker exec コマンドを使用することができます。

28.4. ログの表示

ルーターのログを表示するには、Pod で oc logs コマンドを実行します。ルーターは基礎となる実装を管理するプラグインプロセスとして実行されているため、このログは実際の HAProxy ログではなく、プラグインのログになります。

HAProxy で生成されるログを表示するには、以下の環境変数を使用して syslog サーバーを起動し、そ

第第28章章ルーターのモニタリングおよびデバッグルーターのモニタリングおよびデバッグ

291

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#architecture-core-concepts-routes

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#exposing-the-router-metrics

https://access.redhat.com/errata/RHSA-2015:1650

HAProxy で生成されるログを表示するには、以下の環境変数を使用して syslog サーバーを起動し、その位置情報をルーター Pod に渡します。

表28.1 ルーター Syslog 変数

環境変数環境変数説明説明

ROUTER_SYSLOG_ADDRESS

syslog サーバーの IP アドレスです。ポートが指定されていない場合、ポート514 がデフォルトになります。

ROUTER_LOG_LEVEL これはオプションであり、HAProxy ログレベルを変更する際に設定します。設定されていない場合は、デフォルトのログレベルは warning になります。これは HAProxy がサポートするログレベルに変更することができます。

ROUTER_SYSLOG_FORMAT

これはオプションであり、カスタマイズされた HAProxy ログ形式を定義する際に設定されます。これを HAProxy が受け入れるログ形式の文字列に変更できます。

メッセージを syslog サーバーに送信できるように実行中のルーター Pod を設定するには、以下を実行します。

$ oc set env dc/router ROUTER_SYSLOG_ADDRESS=<dest_ip:dest_port> ROUTER_LOG_LEVEL=<level>

たとえば、以下はデフォルトポート 514 で 127.0.0.1 にログを送信するよう HAProxy を設定し、ログレベルを debug に変更します。

$ oc set env dc/router ROUTER_SYSLOG_ADDRESS=127.0.0.1 ROUTER_LOG_LEVEL=debug

28.5. ルーター内部の表示

routes.json

ルートは HAProxy ルーターで処理され、メモリー、ディスクおよび HAProxy 設定ファイルに保存されます。HAProxy 設定ファイルを生成するためにテンプレートに渡される内部ルート表示は/var/lib/haproxy/router/routes.json ファイルで確認できます。ルーティングの問題のトラブルシューティング時には、このファイルを表示して設定を有効にするために使用されているデータを確認できます。

HAProxy 設定

HAProxy 設定および特定ルート用に作成されたバックエンドは/var/lib/haproxy/conf/haproxy.config ファイルで確認することができます。マッピングファイルは同じディレクトリーにあります。ヘルパーのフロントエンドとバックエンドは、着信要求のバックエンドへのマッピング時にマッピングファイルを使用します。

証明書

証明書は 2 つの場所に保存されます。

edge termination および re-encrypt 終端ルートの証明書は /var/lib/haproxy/router/certsディレクトリーに保存されます。


292

re-encrypt 終端ルートのバックエンドへの接続に使用される証明書は/var/lib/haproxy/router/cacerts ディレクトリーに保存されます。

ファイルはルートの namespace および名前で指定されます。キー、証明書および CA 証明書は単一ファイルに連結されます。OpenSSL を使用してこれらのファイルの内容を表示できます。

第第28章章ルーターのモニタリングおよびデバッグルーターのモニタリングおよびデバッグ

293

https://www.openssl.org/

第29章高可用性

29.1. 概要

このトピックでは、OpenShift Container Platform クラスターの Pod およびサービスの高可用性の設定について説明します。

IP フェイルオーバーは、ノードセットの仮想 IP (VIP) アドレスのプールを管理します。セットのすべての VIP はセットから選択されるノードによって提供されます。VIP は単一ノードが利用可能である限り提供されます。ノード上で VIP を明示的に配布する方法がないため、VIP のないノードがある可能性も、多数の VIP を持つノードがある可能性もあります。ノードが 1 つのみ存在する場合は、すべてのVIP がそのノードに配置されます。

注記注記

VIP はクラスター外からルーティングできる必要があります。

IP フェイルオーバーは各 VIP のポートをモニターし、ポートがノードで到達可能かどうかを判別します。ポートが到達不能な場合、VIP はノードに割り当てられません。ポートが 0 に設定されている場合、このチェックは抑制されます。check スクリプトは必要なテストを実行します。

IP フェイルオーバーは Keepalived を使用して一連のホストでの外部からアクセスできる VIP アドレスのセットをホストします。各 VIP は 1 度に 1 つのホストによって提供されます。Keepalived は VRRP プロトコルを使用して (一連のホストの) どのホストがどの VIP を提供するかを判別します。ホストが利用不可の場合や Keepalived が監視しているサービスが応答しない場合は、VIP は一連のホストの内の別のホストに切り換えられます。したがって、VIP はホストが利用可能である限り常に提供されます。

Keepalived を実行するホストが check スクリプトを渡す場合、ホストはプリエンプションストラテジーに応じて、その優先順位および現在の MASTER の優先順位に基づいて MASTER 状態になります。

管理者は、状態が変更されるたびに呼び出されるスクリプトを --notify-script= オプションを使用して提供できます。Keepalived は VIP を提供する場合は MASTER 状態に、別のノードが VIP を提供する場合は BACKUP 状態に、または check スクリプトが失敗する場合は FAULT 状態になります。notifyスクリプトは、状態が変更されるたびに新規の状態で呼び出されます。

OpenShift Container Platform は、oc adm ipfailover コマンドの実行による IP フェイルオーバーのデプロイメント設定の作成をサポートします。IP フェイルオーバーのデプロイメント設定は VIP アドレスのセットを指定し、それらの提供先となるノードのセットを指定します。クラスターには複数の IPフェイルオーバーのデプロイメント設定を持たせることができ、それぞれが固有な VIP アドレスの独自のセットを管理します。IP フェイルオーバー設定の各ノードは IP フェイルオーバー Pod として実行され、この Pod は Keepalived を実行します。

VIP を使用してホストネットワーク (例: ルーター) を持つ Pod にアクセスする場合、アプリケーションPod は ipfailover Pod を実行しているすべてのノードで実行されている必要があります。これにより、いずれの ipfailover ノードもマスターになり、必要時に VIP を提供することができます。アプリケーション Pod が ipfailover のすべてのノードで実行されていない場合、一部の ipfailoverノードが VIP を提供できないか、または一部のアプリケーション Pod がトラフィックを受信できなくなります。この不一致を防ぐために、ipfailover とアプリケーション Pod の両方に同じセレクターとレプリケーション数を使用します。

VIP を使用してサービスにアクセスする場合には、いずれのノードもノードの ipfailover セットに入れることができます。それは、(アプリケーション Pod が実行されている場所を問わず) サービスはすべてのノードで到達可能であるためです。ipfailover ノードのいずれもいつでもマスターにすることがで


294

http://www.keepalived.org/

きます。サービスは外部 IP およびサービスポートを使用するか、または nodePort を使用することができます。

サービス定義で外部 IP を使用する場合、VIP は外部 IP に設定され、ipfailover のモニターポートはサービスポートに設定されます。nodePort はクラスターのすべてのノードで開かれ、サービスは VIP をサポートしているいずれのノードからのトラフィックについても負荷分散を行います。この場合、ipfailover のモニターノードはサービス定義で nodePort に設定されます。

重要重要

nodePort のセットアップは特権付きの操作で実行されます。

重要重要

サービス VIP の可用性が高い場合でも、パーマンスは依然として影響を受けます。keepalived はそれぞれの VIP が設定内のノードによって提供されるようにし、他のノードに VIP がない場合でも複数の VIP が同じノードに配置されることがあります。ipfailover が複数の VIP を同じノードに配置する場合、外部から一連の VIP 間で負荷分散を行う方法は失敗する可能性があります。

ingressIP を使用する場合は、ipfailover を ingressIP 範囲と同じ VIP 範囲を持つように設定できます。また、モニターポートを無効にすることもできます。この場合、すべての VIP がクラスター内の同じノードに表示されます。すべてのユーザーが ingressIP でサービスをセットアップし、これを高い可用性のあるサービスにすることができます。

重要重要

クラスター内の VIP の最大数は 255 です。

29.2. IP フェイルオーバーの設定

oc adm ipfailover コマンドを適切なオプションと共に使用し、ipfailover デプロイメント設定を作成します。

重要重要

現時点で、ipfailover はクラウドインフラストラクチャーと互換性がありません。AWSの場合、AWS コンソールの使用により Elastic Load Balancer (ELB) で OpenShiftContainer Platform の高可用性を維持することができます。

管理者は、クラスター全体に ipfailover を設定することも、ラベルセレクターの定義に基づいてノードのサブセットに ipfailover を設定することもできます。また、複数の IP フェイルオーバーのデプロイメント設定をクラスター内に設定することもでき、それぞれの設定をクラスター内で相互に切り離すことができます。oc adm ipfailover コマンドは ipfailover デプロイメント設定を作成し、これによりフェイルオーバー Pod が使用される制約またはラベルに一致する各ノードで実行されるようにします。このPod は、すべての Keepalived デーモン間で VRRP (Virtual Router Redundancy Protocol) を使用するKeepalived を実行し、監視されるポートでサービスが利用可能であることを確認し、利用可能でない場合は Keepalived が仮想 IP (VIP) を自動的に浮動させます。

実稼働環境で使用する場合には、2 つ以上のノードで --selector=<label> を使用してノードを選択するようにします。また、指定のラベルが付けられたセレクターのノード数に一致する --replicas=<n> 値を設定します。

oc adm ipfailover コマンドには、Keepalived を制御する環境変数を設定するコマンドラインオプショ

第第29章章高可用性高可用性

295

http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-getting-started.html

http://www.keepalived.org/

oc adm ipfailover コマンドには、Keepalived を制御する環境変数を設定するコマンドラインオプションが含まれます。環境変数は OPENSHIFT_HA_* で開始され、必要に応じて変更できます。

たとえば、以下のコマンドは router=us-west-ha のラベルが付けられたノードのセレクションに対してIP フェイルオーバー設定を作成します (7 仮想 IP を持つ 4 ノードで、ルータープロセスなどのポート80 でリッスンするサービスをモニタリング)。

$ oc adm ipfailover --selector="router=us-west-ha" \ --virtual-ips="1.2.3.4,10.1.1.100-104,5.6.7.8" \ --watch-port=80 --replicas=4 --create

29.2.1. 仮想 IP アドレス

Keepalived は一連の仮想 IP アドレス (VIP) を管理します。管理者はこれらすべてのアドレスについて以下の点を確認する必要があります。

仮想 IP アドレスは設定されたホストでクラスター外からアクセスできる。

仮想 IP アドレスはクラスター内でこれ以外の目的で使用されていない。

各ノードの Keepalived は、必要とされるサービスが実行中であるかどうかを判別します。実行中の場合、VIP がサポートされ、Keepalived はネゴシエーションに参加してそのノードが VIP を提供するかを決定します。これに参加するノードについては、このサービスが VIP の監視ポートでリッスンしている、またはチェックが無効にされている必要があります。

注記注記

セット内の各 VIP は最終的に別のノードによって提供される可能性があります。

29.2.2. チェックおよび通知スクリプト

Keepalived は、オプションのユーザー指定のチェックスクリプトを定期的に実行してアプリケーションの正常性をモニターします。たとえば、このスクリプトは要求を発行し、応答を検証することで webサーバーをテストします。

スクリプトは oc adm ipfailover コマンドに --check-script=<script> オプションを指定して実行されます。このスクリプトは PASS の場合は 0 で終了するか、または FAIL の場合は 1 で終了する必要があります。

デフォルトでチェックは 2 秒ごとに実行されますが、--check-interval=<seconds> オプションを使用して頻度を変更することができます。

チェックスクリプトが指定されない場合、TCP 接続をテストする単純なデフォルトスクリプトが実行されます。このデフォルトテストは、モニターポートが 0 の場合は抑制されます。

それぞれの仮想 IP (VIP) について、keepalived はノードの状態を保持します。ノードの VIP はMASTER、BACKUP、または FAULT の状態になります。FAULT 状態にないノードのすべての VIP はネゴシエーションに参加し、VIP の MASTER を決定します。選ばれなかったすべてのノードはBACKUP 状態になります。MASTER での check スクリプトが失敗すると、VIP は FAULT 状態になり、再ネゴシエーションがトリガーされます。BACKUP が失敗すると、VIP は FAULT 状態になります。check スクリプトが FAULT 状態の VIP に再度渡されると、その VIP は FAULT 状態を終了してMASTER のネゴシエーションを行います。結果としてその VIP の状態は MASTER または BACKUP のいずれかになります。

管理者はオプションの notify スクリプトを提供できます。このスクリプトは状態が変更されるたびに


296

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/installing_clusters/#required-ports

管理者はオプションの notify スクリプトを提供できます。このスクリプトは状態が変更されるたびに呼び出されます。Keepalived は以下の 3 つのパラメーターをこのスクリプトに渡します。

$1 - "GROUP"|"INSTANCE"

$2: グループまたはインスタンスの名前です。

$3: 新規の状態 ("MASTER"|"BACKUP"|"FAULT") です。

これらのスクリプトは IP フェイルオーバー Pod で実行され、ホストのファイルシステムではなく Podのファイルシステムを使用します。オプションにはスクリプトへの完全パスが必要です。管理者は Podでスクリプトを利用可能にし、notify スクリプトを実行して結果を抽出できるようにする必要があります。スクリプトを提供する方法として、ConfigMap の使用が推奨されます。

check および notify スクリプトの完全パス名は、keepalived 設定ファイル、/etc/keepalived/keepalived.conf に追加されます。これは keepalived が起動するたびに読み込まれます。スクリプトは以下のように ConfigMap を使って Pod に追加できます。

1. 必要なスクリプトを作成し、これを保持する ConfigMap を作成します。スクリプトには入力引数は指定されず、OK の場合は 0 を、FAIL の場合は 1 を返します。check スクリプト mycheckscript.sh:

2. ConfigMap を作成します。

$ oc create configmap mycustomcheck --from-file=mycheckscript.sh

3. スクリプトを Pod に追加する方法として、oc コマンドの使用またはデプロイメント設定の編集の 2 つの方法があります。どちらの場合も、マウントされた configMap ファイルの defaultMode は実行を許可する必要があります。通常は、値 0755 (493、10 進数) が使用されます。

a. oc コマンドの使用:

b. ipf-ha-router デプロイメント設定の編集:

i. oc edit dc ipf-ha-router を使用し、テキストエディターでルーターデプロイメント設定を編集します。

#!/bin/bash # Whatever tests are needed # E.g., send request and verify responseexit 0

$ oc env dc/ipf-ha-router \ OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh$ oc set volume dc/ipf-ha-router --add --overwrite \ --name=config-volume \ --mount-path=/etc/keepalive \ --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'

... spec: containers: - env: - name: OPENSHIFT_HA_CHECK_SCRIPT 1


297


1

2

3

4

spec.container.env フィールドで、マウントされたスクリプトファイルを参照する OPENSHIFT_HA_CHECK_SCRIPT 環境変数を追加します。

spec.container.volumeMounts フィールドを追加してマウントポイントを作成します。

新規の spec.volumes フィールドを追加して ConfigMap に言及します。

これはファイルの実行パーミッションを設定します。読み取られる場合は 10 進数(493) で表示されます。

ii. 変更を保存してエディターを終了します。これにより ipf-ha-router が再起動します。

29.2.3. VRRP プリエンプション

ホストが check スクリプトを渡すことで FAULT 状態を終了する場合、その新規ホストが現在のMASTER 状態にあるホストよりも優先度が低い場合は BACKUP になります。ただしそのホストの優先度が高い場合は、プリエンプションストラテジーがクラスター内でのそのロールを決定します。

nopreempt ストラテジーは MASTER を低優先度のホストから高優先度のホストに移行しません。デフォルトの preempt 300 の場合、keepalived は指定された 300 秒の間待機し、MASTER を優先度の高いホストに移行します。

プリエンプションを指定するには、以下を実行します。

a. preemption-strategy を使用して ipfailover を作成します。

b. oc set env コマンドを使用して変数を設定します。

c. oc edit dc ipf-ha-router を使用してルーターデプロイメント設定を編集します。

value: /etc/keepalive/mycheckscript.sh... volumeMounts: 2 - mountPath: /etc/keepalive name: config-volume dnsPolicy: ClusterFirst... volumes: 3 - configMap: defaultMode: 0755 4 name: customrouter name: config-volume...

$ oc adm ipfailover --preempt-strategy=nopreempt \ ...

$ oc set env dc/ipf-ha-router \ --overwrite=true \ OPENSHIFT_HA_PREEMPTION=nopreempt

... spec:


298

29.2.4. Keepalived マルチキャスト

OpenShift Container Platform の IP フェイルオーバーは keepalived を内部で使用します。

重要重要

前述のラベルが付いたノードで multicast が有効にされており、それらが 224.0.0.18(VRRP マルチキャスト IP アドレス) のネットワークトラフィックを許可することを確認します。

keepalived デーモンを起動する前に、起動スクリプトは、マルチキャストトラフィックのフローを許可する iptables ルールを検証します。このルールがない場合、起動スクリプトは新規ルールを作成し、これを IP テーブル接続に追加します。この新規ルールが IP テーブルに追加される場所は --iptables-chain= オプションによって異なります。--iptables-chain= オプションが指定される場合、ルールはオプションで指定されるチェーンに追加されます。そうでない場合は、ルールは INPUTチェーンに追加されます。

重要重要

iptables ルールは、1 つ以上の keepalived デーモンがノードで実行されている場合に存在している必要があります。

iptables ルールは、最後の keepalived デーモンの終了後に削除できます。このルールは自動的に削除されません。

各ノードで iptables ルールを手動で管理できます。(ipfailover が - -iptable-chain="" オプションで作成されていない限り) 何も存在しない場合にこのルールが作成されます。

重要重要

手動で追加されたルールがシステム起動後も保持されることを確認する必要があります。

すべての keepalived デーモンはマルチキャスト 224.0.0.18 で VRRP を使用してそのピアとネゴシエーションするので注意が必要です。それぞれの VIP に異なる VRRP-id(0..255 の範囲) が設定されます。

$ for node in openshift-node-{5,6,7,8,9}; do ssh $node <<EOF

export interface=${interface:-"eth0"}echo "Check multicast enabled ... ";ip addr show $interface | grep -i MULTICAST

echo "Check multicast groups ... "ip maddr show $interface | grep 224.0.0

containers: - env: - name: OPENSHIFT_HA_PREEMPTION 1 value: nopreempt...


299

EOFdone;

29.2.5. コマンドラインオプションおよび環境変数

表29.1 コマンドラインオプションおよび環境変数

オプショオプションン

変数名変数名デフォルデフォルトト

備考備考

--watch-port

OPENSHIFT_HA_MONITOR_PORT

80 ipfailover Pod は、各 VIP のこのポートに対して TCP 接続を開こうとします。接続が設定されると、サービスは実行中であると見なされます。このポートが 0 に設定される場合、テストは常にパスします。

--interface

OPENSHIFT_HA_NETWORK_INTERFACE

使用する ipfailover のインターフェース名で、VRRP トラフィックを送信するために使用されます。デフォルトで eth0 が使用されます。

--replicas

OPENSHIFT_HA_REPLICA_COUNT

2 作成するレプリカの数です。これは、ipfailover デプロイメント設定の spec.replicas 値に一致している必要があります。

--virtual-ips

OPENSHIFT_HA_VIRTUAL_IPS

複製する IP アドレス範囲の一覧です。これは指定する必要があります (例: 1.2.3.4-6,1.2.3.9.)。詳細については、こちらを参照してください。

--vrrp-id-offset

OPENSHIFT_HA_VRRP_ID_OFFSET

0 詳細は、VRRP ID オフセットを参照してください。

--virtual-ip-groups

OPENSHIFT_HA_VIP_GROUPS

VRRP に作成するグループの数です。これが設定されていない場合、グループは --virtual-ips オプションで指定されている仮想 IP 範囲ごとに作成されます。詳細は、「254 を超えるアドレスについての IP フェイルオーバーの設定」を参照してください。

--iptables-chain

OPENSHIFT_HA_IPTABLES_CHAIN

INPUT iptables チェーンの名前であり、iptablesルールを自動的に追加し、VRRP トラフィックをオンにすることを許可するために使用されます。この値が設定されていない場合、iptables ルールは追加されません。チェーンが存在しない場合は作成されません。


300

--check-script

OPENSHIFT_HA_CHECK_SCRIPT

Pod のファイルシステム内の、アプリケーションの動作を確認するために定期的に実行されるスクリプトの完全パス名です。詳細は、こちらを参照してください。

--check-interval

OPENSHIFT_HA_CHECK_INTERVAL

2 check スクリプトが実行される期間 (秒単位)です。

--notify-script

OPENSHIFT_HA_NOTIFY_SCRIPT

Pod ファイルシステム内の、状態が変更されるたびに実行されるスクリプトの完全パス名です。詳細は、こちらを参照してください。

--preemption-strategy

OPENSHIFT_HA_PREEMPTION

preempt300

新たな優先度の高いホストを処理するためのストラテジーです。詳細は、「VRRP プリエンプション」のセクションを参照してください。

オプショオプションン

変数名変数名デフォルデフォルトト

備考備考

29.2.6. VRRP ID オフセット

ipfailover デプロイメント設定で管理される各 ipfailover Pod (ノード/レプリカあたり 1 Pod) はkeepalived デーモンを実行します。作成される ipfailover デプロイメント設定が多くなると、作成される Pod も多くなり、共通の VRRP ネゴシエーションに参加するデーモンも多くなります。このネゴシエーションはすべての keepalived デーモンによって実行され、これはどのノードがどの仮想 IP (VIP)を提供するかを決定します。

keepalived は内部で固有の vrrp-id を各 VIP に割り当てます。ネゴシエーションはこの vrrp-id セットを使用し、決定後には優先される vrrp-id に対応する VIP が優先されるノードで提供されます。

したがって、ipfailover デプロイメント設定で定義されるすべての VIP について、ipfailover Pod は対応する vrrp-id を割り当てます。これは、--vrrp-id-offsetから開始し、順序に従って vrrp-id を VIP の一覧に割り当てることによって実行されます。vrrp-id には範囲 1..255 の値を設定できます。

複数の ipfailover デプロイメント設定がある場合、デプロイメント設定の VIP 数を増やす余地があることや vrrp-id 範囲のいずれも重複しないことを確認できるよう --vrrp-id-offset を注意して指定する必要があります。

29.2.7. 254 を超えるアドレスについての IP フェイルオーバーの設定

IP フェイルオーバー管理は VIP アドレスの 254 グループに制限されています。デフォルトでは、OpenShift Container Platform は各グループに 1 つの IP アドレスを割り当てます。virtual-ip-groups オプションを使用するとこれを変更でき、IP フェイルオーバーの設定時に複数の IP アドレスをそれぞれのグループに配置し、各 VRRPインスタンスに利用できる VIP グループの数を定義できます。

VIP の作成により、VRRP フェイルオーバーの発生時の広範囲の VRRP の割り当てが作成され、これはクラスター内のすべてのホストがローカルにサービスにアクセスする場合に役立ちます。たとえば、サービスが ExternalIP で公開されている場合などがこれに含まれます。

注記注記


301

注記注記

フェイルオーバーのルールとして、ルーターなどのサービスは特定の 1 つのホストに制限しません。代わりに、サービスは、IP フェイルオーバーの発生時にサービスが新規ホストに再作成されないように各ホストに複製可能な状態にする必要があります。

注記注記

OpenShift Container Platform のヘルスチェックを使用している場合、IP フェイルオーバーおよびグループの性質上、グループ内のすべてのインスタンスはチェックされません。そのため、Kubernetes ヘルスチェックを使ってサービスが有効であることを確認する必要があります。

# oc adm ipfailover <ipfailover_name> --create \ ... --virtual-ip-groups=<number_of_ipfailover_groups>

たとえば、7 つの VIP のある環境で --virtual-ip-groups が 3 に設定されている場合、これは 3 つのグループを作成し、3 つの VIP を最初のグループに、2 つの VIP を 2 つの残りのグループにそれぞれ割り当てます。

注記注記

--virtual-ip-groups オプションで設定されるグループの数がフェイルオーバーに設定される IP アドレスの数よりも小さい場合、グループには複数の IP アドレスが含まれ、アドレスのすべてが単一のユニットとして移行します。

29.2.8. 高可用サービスの設定

以下の例では、ノードのセットに IP フェイルオーバーを指定して可用性の高い router および geo-cache ネットワークサービスをセットアップする方法について説明します。

1. サービスに使用されるノードにラベルを付けます。の手順は、OpenShift Container Platformクラスターのすべてのノードでサービスを実行し、クラスターのすべてのノード内で固定されない VIP を使用する場合はオプションになります。以下の例では、地理的区分 US west でトラフィックを提供するノードのラベルを定義します(ha-svc-nodes=geo-us-west)。

$ oc label nodes openshift-node-{5,6,7,8,9} "ha-svc-nodes=geo-us-west"

2. サービスアカウントを作成します。ipfailover を使用したり、(環境ポリシーによって異なる)ルーターを使用する場合は事前に作成された router サービスアカウントか、または新規のipfailover サービスアカウントのいずれかを再利用できます。以下の例は、デフォルト namespace で ipfailover という名前の新規サービスアカウントを作成します。

$ oc create serviceaccount ipfailover -n default

3. デフォルト namespace の ipfailover サービスアカウントを privileged SCC に追加します。

$ oc adm policy add-scc-to-user privileged system:serviceaccount:default:ipfailover

4. router および geo-cache サービスを起動します。


302

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

重要重要

ipfailover は手順 1 のすべてのノードで実行されるため、手順 1 のすべてのノードでルーター/サービスを実行することも推奨されます。

a. 最初の手順で使用されるラベルに一致するノードでルーターを起動します。以下の例では、ipfailover サービスアカウントを使用して 5 つのインスタンスを実行します。

$ oc adm router ha-router-us-west --replicas=5 \ --selector="ha-svc-nodes=geo-us-west" \ --labels="ha-svc-nodes=geo-us-west" \ --service-account=ipfailover

b. 各ノードでレプリカと共に geo-cache サービスを実行します。geo-cache サービスの実行については、「設定サンプル」を参照してください。

重要重要

ファイルで参照される myimages/geo-cache コンテナーイメージが使用するイメージに置き換えられていることを確認します。レプリカの数を geo-cache ラベルのノード数に変更します。ラベルが最初の手順で使用したものと一致していることを確認します。

$ oc create -n <namespace> -f ./examples/geo-cache.json

5. router および geo-cache サービスの ipfailover を設定します。それぞれに独自の VIP があり、いずれも最初の手順の ha-svc-nodes=geo-us-west のラベルが付けられた同じノードを使用します。レプリカの数が最初の手順のラベル設定に一覧表示されているノード数と一致していることを確認してください。

重要重要

router、geo-cache および ipfailover はすべてデプロイメント設定を作成します。それらの名前はすべて異なっている必要があります。

6. ipfailover が必要なインスタンスでモニターする必要のある VIP およびポート番号を指定します。router の ipfailover コマンド:

$ oc adm ipfailover ipf-ha-router-us-west \ --replicas=5 --watch-port=80 \ --selector="ha-svc-nodes=geo-us-west" \ --virtual-ips="10.245.2.101-105" \ --iptables-chain="INPUT" \ --service-account=ipfailover --create

以下は、ポート 9736 でリッスンする geo-cache サービスの oc adm ipfailover コマンドです。2 つの ipfailover デプロイメント設定があるため、それぞれの VIP が独自のオフセットを取得できるように --vrrp-id-offset を設定する必要があります。この場合 10 の値は、ipf-ha-geo-cache が 10 から開始するために ipf-ha-router-us-west には最大 10 の VIP (0-9)を持たせることができることを意味します。


303

https://raw.githubusercontent.com/openshift/openshift-docs/master-3/admin_guide/examples/geo-cache.json

1 1

2

3

4

$ oc adm ipfailover ipf-ha-geo-cache \ --replicas=5 --watch-port=9736 \ --selector="ha-svc-nodes=geo-us-west" \ --virtual-ips=10.245.3.101-105 \ --vrrp-id-offset=10 \ --service-account=ipfailover --create

上記のコマンドでは、各ノードに ipfailover、router、および geo-cache Pod があります。各ipfailover 設定の VIP のセットは重複してなならず、外部またはクラウド環境の別の場所で使用することはできません。それぞれの例の 5 つの VIP 10.245.{2,3}.101-105 は、2 つの ipfailoverデプロイメント設定で提供されます。IP フェイルオーバーはどのアドレスがどのノードで提供されるかを動的に選択します。

管理者は、すべての router VIP が同じ router を参照し、すべての geo-cache VIP が同じ geo-cache サービスを参照することを前提とした上で VIP アドレスを参照する外部 DNS をセットアップします。1 つのノードが実行中である限り、すべての VIP アドレスが提供されます。

29.2.8.1. IP フェイルオーバーフェイルオーバー Pod のデプロイのデプロイ

postgresql-ingress サービスの定義に基づいてノードポート 32439 および外部 IP アドレスでリッスンする postgresql をモニターするために ipfailover ルーターをデプロイします。

$ oc adm ipfailover ipf-ha-postgresql \ --replicas=1 \ 1 --selector="app-type=postgresql" \ 2 --virtual-ips=10.9.54.100 \ 3 --watch-port=32439 \ 4 --service-account=ipfailover --create

デプロイするインスタンスの数を指定します。

ipfailover がデプロイされる場所を制限します。

モニターする仮想 IP アドレスです。

各ノード上の ipfailover がモニターするポートです。

29.2.9. 高可用サービスの仮想 IP の動的更新

IP フェイルオーバーのデフォルトのデプロイメント方法として、デプロイメントを再作成します。高可用のルーティングサービスの動的更新を最小限のダウンタイムまたはダウンタイムなしで実行するには、以下を実行する必要があります。

ローリングアップデート (Rolling Update) ストラテジーを使用するように IP フェイルオーバーサービスデプロイメント設定を更新する。

仮想 IP アドレスの更新された一覧またはセットを使用して OPENSHIFT_HA_VIRTUAL_IPS環境変数を更新します。

以下の例は、デプロイメントストラテジーおよび仮想 IP アドレスを動的に更新する方法について示しています。

1. 以下を使用して作成された IP フェイルオーバー設定を見てみましょう。


304

1

1

$ oc adm ipfailover ipf-ha-router-us-west \ --replicas=5 --watch-port=80 \ --selector="ha-svc-nodes=geo-us-west" \ --virtual-ips="10.245.2.101-105" \ --service-account=ipfailover --create

2. デプロイメント設定を編集します。

$ oc edit dc/ipf-ha-router-us-west

3. spec.strategy.type フィールドを Recreate から Rolling に更新します。

spec: replicas: 5 selector: ha-svc-nodes: geo-us-west strategy: resources: {} rollingParams: maxSurge: 0 type: Rolling 1

Rolling に設定します。

4. 追加の仮想 IP アドレスを含めるように OPENSHIFT_HA_VIRTUAL_IPS 環境変数を更新します。

- name: OPENSHIFT_HA_VIRTUAL_IPS value: 10.245.2.101-105,10.245.2.110,10.245.2.201-205 1

10.245.2.110,10.245.2.201-205 が一覧に追加されます。

5. VIP のセットに一致するよう外部 DNS を更新します。

29.3. サービスの EXTERNALIP および NODEPORT の設定

ユーザーは VIP をサービスの ExternalIP として割り当てることができます。Keepalived は、各 VIP がipfailover 設定のノードで提供されることを確認します。要求がそのノードに到達すると、クラスター内のすべてのノードで実行されているサービスがサービスのエンドポイント間で要求の負荷の分散を行います。

NodePorts を ipfailover 監視ポートに設定して、keepalived がアプリケーションが実行中であることを確認できるようにします。NodePort はクラスター内のすべてのノードで公開されるため、すべてのipfailover ノードの keepalived で利用可能になります。

29.4. INGRESSIP の高可用性

クラウド以外のクラスターでは、ipfailover およびサービスへの ingressIP を組み合わせることができます。結果として、ingressIP を使用してサービスを作成するユーザーに高可用サービスが提供されます。

この方法では、まず ingressIPNetworkCIDR 範囲を指定し、次に ipfailover 設定を作成する際に同じ範


305

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#getting-traffic-into-cluster-ip

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#getting-traffic-into-cluster-nodeport

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#service-ingressip

この方法では、まず ingressIPNetworkCIDR 範囲を指定し、次に ipfailover 設定を作成する際に同じ範囲を使用します。

ipfailover はクラスター全体に対して最大 255 の VIP をサポートするため、ingressIPNetworkCIDR は /24 以下に設定する必要があります。


306

第30章 IPTABLES

30.1. 概要

システムコンポーネントには、OpenShift Container Platform、コンテナー、および適切なネットワーク操作のためにカーネルの iptables 設定に依存するファイアウォールポリシーを管理するソフトウェアなど、数多くのコンポーネントがあります。さらに、クラスター内のすべてのノードの iptables 設定はネットワークが機能するように正しくなければなりません。

すべてのコンポーネントは、他のコンポーネントが iptables をどのように使用するかを認識せずに独立して iptables を使用します。そのため、あるコンポーネントを別のコンポーネントの設定から分離することが容易になります。さらに、OpenShift Container Platform および Docker サービスは、iptables がそれらがセットアップした時と全く同じ設定であると仮定します。それらは他のコンポーネントによって導入される変更を検出しない場合がありますが、これらを検出する場合は修正の実装により一部の遅れが生じる可能性があります。OpenShift Container Platform は問題をモニターし、解決しますが、Docker サービスはこれを実行しません。

重要重要

ノード上の iptables 設定に対して加えるいかなる変更も OpenShift Container Platformおよび Docker サービスの操作に影響を与えないものであることを確認してください。また多くの場合、変更はクラスター内のすべてのノードに対して実行される必要があります。iptables は複数の同時ユーザーを持つように設計されておらず、OpenShiftContainer Platform および Docker ネットワークに障害が発生する可能性があるため、これを変更する際には注意が必要です。

OpenShift Container Platform は複数のチェーンを提供しますが、それらの 1 つは、管理者が独自の目的で使用することが意図されている OPENSHIFT-ADMIN-OUTPUT-RULES です。

詳細は、「外部リソースへのアクセスを制限するための iptables ルールの使用」を参照してください。

OpenShift Container Platform および Docker ネットワークが適性に機能するために、カーネル iptablesのチェーン、チェーンの順序、およびルールがクラスター内の各ノードに適切に設定される必要があります。システム内には、カーネル iptables と対話し、OpenShift Container Platform および Dockerサービスに意図せずに影響を与える可能性のあるツールやサービスがシステムいくつかあります。

30.2. IPTABLES

iptables ツールは、Linux カーネルの IPv4 パケットフィルターのテーブルを設定し、維持し、検査するために使用できます。

ファイアウォールなどの他の使用とは別に、OpenShift Container Platform および Docker サービスはチェーンを一部のテーブルで管理します。チェーンは特定の順序で挿入され、ルールはそれぞれのニーズに応じて固有のものになります。

注意注意

iptables --flush [chain] は、キーが必要な設定を削除できます。このコマンドを実行しないでください。

30.3. IPTABLES.SERVICE

第第30章章 IPTABLES

307

iptables サービスはローカルのネットワークファイアウォールをサポートします。これは、iptables 設定を完全に制御することを想定します。これが起動すると、詳細な iptables 設定をフラッシュし、それを復元します。ルールはその設定ファイル /etc/sysconfig/iptables から復元されます。設定ファイルは操作時に最新の状態に保たれないため、動的に追加されたルールは毎回の再起動時に失われます。

警告警告

iptables.service を停止し、起動することにより、OpenShift Container Platform および Docker で必要な設定が破棄されます。OpenShift Container Platform およびDocker にはこの変更は通知されません。

# systemctl disable iptables.service# systemctl mask iptables.service

iptables.service を実行する必要がある場合、制限された設定を設定ファイルに維持し、OpenShiftContainer Platform および Docker を使用してそれらが必要とするルールをインストールするようにします。

iptables.service 設定は以下から読み取られます。

/etc/sysconfig/iptables

ルールの永続的な変更を実行するには、このファイルで変更を編集します。Docker または OpenShiftContainer Platform ルールは含めないようにしてください。

iptables.service がノードで起動または再起動した後は、Docker サービスおよび atomic-openshift-node.service を再起動して、必要な iptables 設定を再構築する必要があります。

重要重要

Docker サービスの再起動により、ノードで実行されているすべてのコンテナーが停止し、再起動されます。

# systemctl restart iptables.service# systemctl restart docker# systemctl restart atomic-openshift-node.service


308

第31章ストラテジーによるビルドのセキュリティー保護

31.1. 概要

OpenShift Container Platform のビルドは、Docker デーモンソケットにアクセスできる特権付きコンテナーで実行されます。セキュリティー対策として、ビルドおよびそれらのビルドに使用されるストラテジーを実行するユーザーを制限することを推奨します。カスタムビルドは、ソースビルドよりも安全性が低いと言えます。それらはノードの Docker ソケットへの完全なアクセスを持つ可能性があり、それらのアクセスでビルド内で任意のコードを実行する可能性があるためです。そのため、これはデフォルトで無効にされます。Docker ビルドのパーミッションを付与する場合についても、Docker ビルドロジックの脆弱性により権限がホストノードで付与される可能性があるために注意が必要です。

警告警告

Docker およびカスタムビルドの実行時に、Docker デーモンで実行されるアクションは特権付きのアクションであり、ホストネットワーク namespace で実行されます。このようなアクションは、EgressNetworkPolicy オブジェクトおよび静的egress IP アドレスで定義されるものを含む、設定されたネットワークルールを回避します。

デフォルトで、ビルドを作成できるすべてのユーザーには Docker および Source-to-Image (S2I) ビルドストラテジーを使用するためのパーミッションが付与されます。cluster-admin 権限を持つユーザーは、このページの「ユーザーへのビルドストラテジーのグルーバルな制限」セクションで言及されているようにカスタムビルドストラテジーを有効にすることができます。

許可ポリシーを使用して、どのユーザーがどのビルドストラテジーを使用してビルドできるかについて制限することができます。各ビルドには、対応するビルドサブリソースがあります。ストラテジーを使用してビルド作成するには、ユーザーにビルドを作成するパーミッションおよびビルドストラテジーのサブリソースで作成するパーミッションがなければなりません。ビルドストラテジーのサブリソースでの create パーミッションを付与するデフォルトロールが提供されます。

表31.1 ビルドストラテジーのサブリソースおよびロール

ストラテジーストラテジーサブリソースサブリソースロールロール

Docker ビルド/docker system:build-strategy-docker

Source-to-Image ビルド/ソース system:build-strategy-source

カスタムビルド/カスタム system:build-strategy-custom

JenkinsPipeline ビルド/jenkinspipeline system:build-strategy-jenkinspipeline

31.2. ビルドストラテジーのグローバルな無効化

特定のビルドストラテジーへのアクセスをグローバルに禁止するには、cluster-admin 権限を持つユー

第第31章章ストラテジーによるビルドのセキュリティー保護ストラテジーによるビルドのセキュリティー保護

309

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#builds

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/installing_clusters/#security-warning

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#custom-build

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#source-build

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#docker-build




1

ザーとしてログインし、system:authenticated グループから対応するロールを削除し、アノテーション openshift.io/reconcile-protect: "true" を適用してそれらを API の再起動間での変更から保護します。以下の例では、Docker ビルドストラテジーを無効にする方法を示します。

1. openshift.io/reconcile-protect アノテーションの適用

openshift.io/reconcile-protect アノテーションの値を "true" に適用します。デフォルトで、これは "false" に設定されます。

2. ロールを削除します。

3.2 よりも前のバージョンでは、ビルドストラテジーのサブリソースは admin および edit ロールに組み込まれていました。

ビルドストラテジーのサブリソースもこれらのロールから削除されることを確認します。

$ oc edit clusterrole admin$ oc edit clusterrole edit

それぞれのロールについて、無効にするストラテジーのリソースに対応する行を削除します。

admin のの Docker ビルドストラテジーの無効化ビルドストラテジーの無効化

$ oc edit clusterrolebinding system:build-strategy-docker-binding

apiVersion: v1groupNames:- system:authenticatedkind: ClusterRoleBindingmetadata: annotations: openshift.io/reconcile-protect: "true" 1 creationTimestamp: 2018-08-10T01:24:14Z name: system:build-strategy-docker-binding resourceVersion: "225" selfLink: /oapi/v1/clusterrolebindings/system%3Abuild-strategy-docker-binding uid: 17b1f3d4-9c3c-11e8-be62-0800277d20bfroleRef: name: system:build-strategy-dockersubjects:- kind: SystemGroup name: system:authenticateduserNames:- system:serviceaccount:management-infra:management-admin

$ oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated

kind: ClusterRolemetadata: name: admin...rules:- resources:


310

1 admin ロールを持つユーザーに対して Docker ビルドをグローバルに無効にするためにこの行を削除します。

31.3. ユーザーへのビルドストラテジーのグルーバルな制限

一連の特定ユーザーのみが特定のストラテジーでビルドを作成できるようにするには、以下を実行します。

1. ビルドストラテジーへのグローバルアクセスを無効にします。

2. ビルドストラテジーに対応するロールを特定ユーザーに割り当てます。たとえば、system:build-strategy-docker クラスターロールをユーザー devuser に追加するには、以下を実行します。

$ oc adm policy add-cluster-role-to-user system:build-strategy-docker devuser

警告警告

ユーザーに対して builds/docker サブリソースへのクラスターレベルでのアクセスを付与することは、そのユーザーがビルドを作成できるすべてのプロジェクトにおいて、Docker ストラテジーを使ってビルドを作成できることを意味します。

31.4. プロジェクト内でのユーザーへのビルドストラテジーの制限

ユーザーにビルドストラテジーをグローバルに付与するのと同様に、プロジェクト内の特定ユーザーのセットのみが特定ストラテジーでビルドを作成できるようにするには、以下を実行します。

1. ビルドストラテジーへのグローバルアクセスを無効にします。

2. ビルドストラテジーに対応するロールをプロジェクト内の特定ユーザーに付与します。たとえば、プロジェクト devproject 内の system:build-strategy-docker ロールをユーザー devuserに追加するには、以下を実行します。

$ oc adm policy add-role-to-user system:build-strategy-docker devuser -n devproject

- builds/custom - builds/docker 1 - builds/source ......

第第31章章ストラテジーによるビルドのセキュリティー保護ストラテジーによるビルドのセキュリティー保護

311

第32章 SECCOMP を使用したアプリケーション機能の制限

32.1. 概要

seccomp (セキュアコンピューティングモード) は、アプリケーションが行うシステム呼び出しのセットを制限し、クラスター管理者が OpenShift Container Platform で実行されるワークロードのセキュリティーを強化するために使用されます。

seccomp サポートは Pod 設定の 2 つのアノテーションを使用して有効になります。

seccomp.security.alpha.kubernetes.io/pod: Pod のすべてのコンテナーに適用されるプロファイルです (上書きなし)。

container.seccomp.security.alpha.kubernetes.io/<container_name>: コンテナー固有のプロファイルです (上書きあり)。

重要重要

デフォルトで、コンテナーは unconfined seccomp 設定で実行されます。

詳細な設計情報については、seccomp 設計についてのドキュメントを参照してください。

32.2. SECCOMP の有効化

seccomp は Linux カーネルの 1 つの機能です。seccomp がシステムで有効にされていることを確認するには、以下を実行します。

$ cat /boot/config-`uname -r` | grep CONFIG_SECCOMP=CONFIG_SECCOMP=y

32.3. OPENSHIFT CONTAINER PLATFORM での SECCOMP の設定

seccomp プロファイルは json ファイルであり、システムコールを提供し、システムコールの呼び出し時に取るべき適切なアクションを実行します。

1. seccomp プロファイルを作成します。多くの場合はデフォルトのプロファイルだけで十分ですが、クラスター管理者は個別システムのセキュリティー制約を定義する必要があります。

独自のカスタムプロファイルを作成するには、seccomp-profile-root ディレクトリーですべてのノードのファイルを作成します。

デフォルトの docker/default プロファイルを使用している場合は、これを作成する必要はありません。

2. node configuration map で kubeletArguments を使用し、プロファイルを保存するためにseccomp-profile-root ディレクトリーを使用するようにノードを設定します。

kubeletArguments: seccomp-profile-root: - "/your/path"


312

https://github.com/kubernetes/kubernetes/blob/release-1.4/docs/design/seccomp.md

https://github.com/docker/docker/blob/master/profiles/seccomp/default.json

3. 変更を適用するためにノードサービスを再起動します。


4. 使用できるプロファイルを制御し、デフォルトプロファイルを設定するために、seccompProfiles フィールドで SCC を設定します。最初のプロファイルがデフォルトとして使用されます。seccompProfiles フィールドで使用できる形式には以下が含まれます。

docker/default: コンテナーランタイムのデフォルトプロファイルです (いずれのプロファイルも不要です)。

unconfined: 拘束のないプロファイルで、seccomp を無効にします。

localhost/<profile-name>: ノードのローカル seccomp プロファイルの root にインストールされるプロファイルです。たとえば、デフォルトの docker/default プロファイルを使用している場合、以下で SCCを設定します。

seccompProfiles:- docker/default

32.4. OPENSHIFT CONTAINER PLATFORM でのカスタム SECCOMP プロファイルの設定

クラスターの Pod がカスタムプロファイルで実行されるようにするには、以下を実行します。

1. seccomp-profile-root に seccomp プロファイルを作成します。

2. seccomp-profile-root を設定します。

kubeletArguments: seccomp-profile-root: - "/your/path"



4. SCC を設定します。

seccompProfiles:- localhost/<profile-name>

第第32章章 SECCOMP を使用したアプリケーション機能の制限を使用したアプリケーション機能の制限

313

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#authorization-seccomp

第33章 SYSCTL

33.1. 概要

sysctl 設定は Kubernetes 経由で公開され、ユーザーがコンテナー内の namespace の特定のカーネルパラメーターをランタイム時に変更できるようにします。 namespace を使用する sysctl のみを Pod 上で独立して設定できます。sysctl に namespace が使用されていない場合 (この状態はノードレベルと呼ばれる)、OpenShift Container Platform 内でこれを設定することはできません。さらに安全とみなされる sysctl のみがデフォルトでホワイトリストに入れられます。他の安全でない sysctl はノードで手動で有効にし、ユーザーが使用できるようにできます。

33.2. SYSCTL について

Linux では、管理者は sysctl インターフェースを使ってランタイム時にカーネルパラメーターを変更することができます。パラメーターは /proc/sys/ 仮想プロセスファイルシステムで利用できます。これらのパラメーターは以下を含む各種のサブシステムを対象とします。

カーネル (共通のプレフィックス: kernel.)

ネットワーク (共通のプレフィックス: net.)

仮想メモリー (共通のプレフィックス: vm.)

MDADM (共通のプレフィックス: dev.)

追加のサブシステムについては、カーネルのドキュメントで説明されています。すてのパラメーターの一覧を取得するには、以下を実行できます。

$ sudo sysctl -a

33.3. NAMESPACE を使用した SYSCTL VS ノードレベルの SYSCTL

現時点の Linux カーネルでは、数多くの sysctl に namespace が使用されています。これは、それらをノードの各 Pod に対して個別に設定できることを意味します。 namespace の使用は、sysctl をKubernetes 内の Pod 環境でアクセス可能にするための要件になります。

以下の sysctl は namespace を使用するものとして知られている sysctl です。

kernel.shm*

kernel.msg*

kernel.sem

fs.mqueue.*

さらに、net.* グループの大半の sysctl には namespace が使用されていることが知られています。それらの namespace の採用は、カーネルのバージョンおよびディストリビューターによって異なります。

システム上で namespace が使用されている net.* sysctl を確認するには、以下のコマンドを実行します。


314

https://www.kernel.org/doc/Documentation/sysctl/README

$ podman run --rm -ti docker.io/fedora \ /bin/sh -c "dnf install -y findutils && find /proc/sys/ \ | grep -e /proc/sys/net"

namespace が使用されていない sysctl はノードレベルと呼ばれており、クラスター管理者がノードの基礎となる Linux ディストリビューションを使用 (例: /etc/sysctls.conf ファイルを変更) するか、または特権付きコンテナーで DaemonSet を使用することによって手動で設定する必要があります。

注記注記

特殊な sysctl が設定されたノードにテイントのマークを付けることを検討してください。それらの sysctl 設定を必要とする Pod のみをそれらのノードにスケジュールします。テイントおよび容認 (Toleration) 機能を使用してノードにマークを付けます。

33.4. 安全 VS 安全でない SYSCTL

sysctl は安全なおよび安全でない sysctl に分類されます。適切な namespace の設定に加えて、安全なsysctl は同じノード上の Pod 間で適切に分離する必要があります。つまり、Pod ごとに安全な sysctl を設定することについて以下の点に留意する必要があります。

この設定はノードのその他の Pod に影響を与えないものである。

この設定はノードの正常性に負の影響を与えないものである。

この設定は Pod のリソース制限を超える CPU またはメモリーリソースを取得を許可しないものである。

namespace を使用した sysctl は必ずしも常に安全であると見なされる訳ではありません。

現時点で、OpenShift Container Platform は以下の sysctl を安全なセットでサポートするか、またはホワイトリスト化します。

kernel.shm_rmid_forced

net.ipv4.ip_local_port_range

net.ipv4.tcp_syncookies

この一覧は、kubelet による分離メカニズムのサポートを強化する今後のバージョンでさらに拡張される可能性があります。

すべての安全な sysctl はデフォルトで有効にされます。すべての安全でない sysctl はデフォルトで無効にされ、ノードごとにクラスター管理者によって手動で有効にされる必要があります。無効にされた安全でない sysctl が設定された Pod はスケジュールされますが、起動に失敗します。

33.5. 安全でない SYSCTL の有効化

クラスター管理者は、高パフォーマンスまたはリアルタイムのアプリケーション調整などの非常に特殊な状況で特定の安全でない sysctl を許可することができます。

安全でない sysctl を使用する必要がある場合、クラスター管理者はそれらをノードで個別に有効にする必要があります。それらは namespace を使用した sysctl のみを有効にできます。

第第33章章 SYSCTL

315

1

1

2

警告警告

安全でないという性質上、安全でない sysctl は各自の責任で使用されます。場合によっては、コンテナーの正しくない動作やリソース不足、またはノードの完全な破損などの深刻な問題が生じる可能性があります。

1. 安全ではない sysctl を、「ノードリソースの設定」で説明されているように、ノード設定マップファイルの kubeletArguments\ パラメーターに追加します。例:

$ oc edit cm node-config-compute -n openshift-node

.... kubeletArguments: allowed-unsafe-sysctls: 1 - "net.ipv4.tcp_keepalive_time" - "net.ipv4.tcp_keepalive_intvl" - "net.ipv4.tcp_keepalive_probes"

使用する必要のある安全でない sysctl を追加します。

2. 制限付き SCC の内容を使用する新規 SCC を作成し、安全でない sysctl を追加します。

....allowHostDirVolumePlugin: falseallowHostIPC: falseallowHostNetwork: falseallowHostPID: falseallowHostPorts: falseallowPrivilegeEscalation: trueallowPrivilegedContainer: falseallowedCapabilities: nullallowedUnsafeSysctls: 1- net.ipv4.tcp_keepalive_time- net.ipv4.tcp_keepalive_intvl- net.ipv4.tcp_keepalive_probes....metadata: name: restricted-sysctls 2....

使用する必要のある安全でない sysctl を追加します。

SCC の新規の名前を指定します。

3. 新規 SCC アクセスを Pod ServiceAccount に付与します。

$ oc adm policy add-scc-to-user restricted-sysctls -z default -n your_project_name


316

4. 安全でない sysctl を Pod の DeploymentConfig に追加します。

kind: DeploymentConfig

.... template: .... spec: containers: .... securityContext: sysctls: - name: net.ipv4.tcp_keepalive_time value: "300" - name: net.ipv4.tcp_keepalive_intvl value: "20" - name: net.ipv4.tcp_keepalive_probes value: "3"



33.6. POD の SYSCTL 設定

sysctl は Pod の securityContext を使用して Pod に設定されます。securityContext は同じ Pod 内のすべてのコンテナーに適用されます。

以下の例では、Pod securityContext を使用して安全な sysctl kernel.shm_rmid_forced および 2 つの安全でない sysctl net.ipv4.route.min_pmtu および kernel.msgmax を設定します。仕様では安全なsysctl と安全でない sysctl は区別されません。

警告警告

オペレーティングシステムが不安定になるのを防ぐには、変更の影響を確認している場合にのみ sysctl パラメーターを変更します。

以下の例に示されるように、Pod を定義する YAML ファイルを変更し、securityContext 仕様を追加します。

apiVersion: v1kind: Podmetadata: name: sysctl-examplespec: securityContext: sysctls: - name: kernel.shm_rmid_forced value: "0"

第第33章章 SYSCTL

317

注記注記

上記の安全でない sysctl が指定された Pod は、管理者がそれらの 2 つの安全でないsysctl を明示的に有効にしていないノードでの起動に失敗します。ノードレベルの sysctlの場合のように、それらの Pod を正しいノードにスケジュールするには、テイントおよび容認機能またはノードのラベルを使用します。

- name: net.ipv4.route.min_pmtu value: "552" - name: kernel.msgmax value: "65536" ...


318

第34章データストア層でのデータの暗号化

34.1. 概要

このトピックでは、データストア層でシークレットデータの暗号化を有効にし、これを設定する方法について説明します。サンプルでは secrets リソースを使用していますが、configmaps などのすべてのリソースを暗号化することができます。

重要重要

この機能を使用するには、etcd v3 以降が必要になります。

34.2. 設定および暗号がすでに有効にされているかどうかの判別

データ暗号化をアクティブにするには、--experimental-encryption-provider-config 引数をKubernetes API サーバーに渡します。

master-config.yaml の抜粋の抜粋

master-config.yaml およびその形式についての詳細は、「マスター設定ファイル」のトピックを参照してください。

34.3. 暗号化設定について

すべての利用可能なプロバイダーを含む暗号化設定ファイルすべての利用可能なプロバイダーを含む暗号化設定ファイル

kubernetesMasterConfig: apiServerArguments: experimental-encryption-provider-config: - /path/to/encryption-config.yaml

kind: EncryptionConfigapiVersion: v1resources: 1 - resources: 2 - secrets providers: 3 - aescbc: 4 keys: - name: key1 5 secret: c2VjcmV0IGlzIHNlY3VyZQ== 6 - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - secretbox: keys: - name: key1 secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY= - aesgcm: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ==

第第34章章データストア層でのデータの暗号化データストア層でのデータの暗号化

319

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#master-configuration-files

1

2

3

4

5

6

resources のそれぞれの配列項目は分離した設定であり、詳細な設定が含まれます。

resources.resources フィールドは暗号化が必要な Kubernetes リソース名 ( resource または resource.group) の配列です。

providers 配列は、順序付けられた使用可能な暗号化プロバイダーの一覧です。エントリーごとに1 つのプロバイダータイプ (identity または aescbc）のみを指定できますが、同じ項目に両方を指定することはできません。

一覧の最初のプロバイダーがストレージに移動するリソースを暗号化するために使用されます。

シークレットの任意の名前です。

Base64 のエンコーディングされたランダムキーです。異なるプロバイダーが異なるキーの長さを指定します。詳細は、「キーの生成方法」についての説明を参照してください。

ストレージからのリソースの読み取り時に、保存されたデータに一致する各プロバイダーはデータの復号化を順番に試行します。情報またはシークレットキーの不一致により保存データを読み取れるプロバイダーがない場合にエラーが返され、クライアントがそのリソースにアクセスできなくなります。

重要重要

リソースが暗号化設定で読み取れない場合 (キーの変更により)、キーを基礎となる etcdディレクトリーから削除することのみが必要になります。そのリソースの読み取りを試行する呼び出しは、キーが削除されるか、または有効な復号化キーが提供されない限り失敗します。

34.3.1. 利用可能なプロバイダー

名前名前暗号化暗号化強度強度速度速度キーの長キーの長ささ

他の考慮事項他の考慮事項

identity なし該当なし該当なし該当なし暗号化なしのそのままの状態で作成されたリソースです。最初のプロバイダーとして設定される場合、リソースは新規の値が書き込まれるときに復号化されます。

aescbc PKCS#7パディングが設定されたAES-CBC

最も強い高速 32 バイト暗号化に推奨されるオプションですが、secretbox よりも若干遅くなる可能性があります。

secretbox XSalsa20およびPoly1305

強いより高速 32 バイトより新しい標準であり、高レベルのレビューが必要な環境では受け入れ可能と見なされない可能性があります。

- name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - identity: {}


320

aesgcm AES-GCMおよびランダム初期化ベクター (IV)

200,000回の書き込みごとにローテーションが必要です。

最速 16、24、または 32バイト

自動化されたキーの回転スキームが実行される場合以外には、使用する使用することが推奨されませんことが推奨されません。

名前名前暗号化暗号化強度強度速度速度キーの長キーの長ささ

他の考慮事項他の考慮事項

各プロバイダーは複数のキーをサポートします。キーは復号化の順序で試行されます。プロバイダーが最初のプロバイダーの場合、最初のキーが暗号化に使用されます。

注記注記

Kubernetes には適切な nonce ジェネレーターがないため、AES-GCM の nonce としてランダム IV を使用します。AES-GCM では適切な nonce がセキュアな状態であることが求められるため、AES-GCM は推奨されません。200,000 回の書き込み制限は nonce の致命的な誤用の可能性を比較的低く抑えます。

34.4. データの暗号化

新規の暗号化設定ファイルを作成します。

新規シークレットを作成するには、以下を実行します。

1. 32 バイトのランダムキーを生成し、これを base64 でエンコーディングします。たとえば、Linux および macOS では、以下を使用します。

$ head -c 32 /dev/urandom | base64

重要重要

暗号化キーは、/dev/urandom などの暗号で保護された乱数ジェネレーターで生成する必要があります。Golang の math/random や Python の random.random() などは適していません。

2. この値を secret フィールドに配置します。

kind: EncryptionConfigapiVersion: v1resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: <BASE 64 ENCODED SECRET> - identity: {}


321

3. API サーバーを再起動します。


重要重要

暗号化プロバイダー設定ファイルには、etcd の内容を復号化できるキーが含まれるため、マスター API サーバーを実行するユーザーのみがこれを読み取れるようにマスターでパーミッションを適切に制限する必要があります。

34.5. データが暗号化されていることの確認

データは etcd に書き込まれる際に暗号化されます。API サーバーの再起動後、新たに作成されたか、または更新されたシークレットは保存時に暗号化されます。これを確認するには、etcdctl コマンドラインプログラムを使用してシークレットの内容を検索できます。

1. default の namespace に、secret1 という新規シークレットを作成します。

$ oc create secret generic secret1 -n default --from-literal=mykey=mydata

2. etcdctl コマンドラインを使用し、etcd からシークレットを読み取ります。

$ ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 -w fields [...] | grep Value

[… ] には、etcd サーバーに接続するために追加の引数を指定する必要があります。

最終的なコマンドは以下と同様になります。

$ ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 -w fields \--cacert=/var/lib/origin/openshift.local.config/master/ca.crt \--key=/var/lib/origin/openshift.local.config/master/master.etcd-client.key \--cert=/var/lib/origin/openshift.local.config/master/master.etcd-client.crt \--endpoints 'https://127.0.0.1:4001' | grep Value

3. 上記のコマンド出力には、aescbc プロバイダーが結果として生成されるデータを暗号化したことを示す k8s:enc:aescbc:v1: のプレフィックスが付けられます。

4. シークレットが API 経由で取得される場合は、正しく復号化されていることを確認します。

$ oc get secret secret1 -n default -o yaml | grep mykey

これは mykey: bXlkYXRh と一致するはずです。

34.6. すべてのシークレットが暗号化されていることの確認

シークレットは書き込み時に暗号化されるため、シークレットの更新を実行するとその内容は暗号化されることになります。

$ oc adm migrate storage --include=secrets --confirm

このコマンドはすべてのシークレットを読み取り、次にサーバー側の暗号化を適用するようにそれらを


322

このコマンドはすべてのシークレットを読み取り、次にサーバー側の暗号化を適用するようにそれらを更新します。書き込みの競合のためにエラーが発生する場合は、コマンドを再試行してください。

大規模クラスターの場合、シークレットを namespace 別に細分化するか、または更新をスクリプト化することができます。

34.7. 復号化キーのローテーション

複数の API サーバーが実行されている高可用デプロイメントがある場合などに、ダウンタイムを発生させずにシークレットを変更するには、複数の手順からなる操作が必要になります。

1. 新規キーを生成し、これをすべてのサーバーで同時プロバイダーの 2 つ目のキーエントリーとして追加します。

2. すべての API サーバーを再起動し、各サーバーが新規キーを使用して復号化できるようにします。

注記注記

単一 API サーバーを使用している場合は、この手順を省略できます。


3. 新規キーを keys 配列の最初のエントリーにし、これが設定で暗号化に使用されるようにします。

4. すべての API サーバーを再起動し、各サーバーが新規キーを使用して暗号化できるようにします。


5. 以下を実行し、新規キーですべての既存シークレットを暗号化します。


6. 新規キーを使用して etcd をバックアップし、すべてのシークレットを更新した後に、古い復号化キーを設定から削除します。

34.8. データの復号化

データストア層で暗号化を無効にするには、以下を実行します。

1. identity プロバイダーを、設定の最初のエントリーとして配置します。

kind: EncryptionConfigapiVersion: v1resources: - resources: - secrets providers: - identity: {}


323

1. すべての API サーバーを再起動します。


2. 以下を実行し、すべてのシークレットの復号化を強制的に実行します。


- aescbc: keys: - name: key1 secret: <BASE 64 ENCODED SECRET>


324

第35章 IPSEC を使用したノード間のトラフィックの暗号化

35.1. 概要

IPsec は、インターネットプロトコル (IP) を使用して通信するすべてのマスターとノードホスト間の通信を暗号化することによって OpenShift Container Platform クラスターのトラフィックを保護します。

このトピックでは、すべてのクラスター管理および Pod データトラフィックを含め、OpenShiftContainer Platform ホストが IP アドレスを受信する IP サブセット全体の通信のセキュリティーを保護する方法について説明します。

注記注記

OpenShift Container Platform 管理トラフィックは HTTPS を使用するため、IPsec の有効化により 2 度目の管理トラフィックの暗号化が実行されることになります。

重要重要

この手順はクラスターの各マスターホストで繰り返し、その後にノードホストで実行される必要があります。IPsec が有効にされていないホストは、これが有効にされているホストと通信することができません。

35.2. ホストの暗号化


libreswan 3.15 以降がクラスターホストにインストールされていることを確認します。便宜的なグループ (opportunistic group) 機能が必要な場合は、libreswan バージョン 3.19 以降が必要になります。

本トピックでは、62 バイトを必要とする IPsec 設定について説明します。クラスターが MTU(最大伝送単位) の値が 1500 バイトであるイーサネットネットワークで動作する場合、IPsec および SDN のカプセル化のオーバーヘッドに対応するために SDN MTU の値を 1388 バイトに変更する必要があります。クラスター内のノードの MTU を変更するには、以下の手順を実行します。

a. node-config-master、node-config-infra、node-config-compute の ConfigMap のそれぞれを編集します。

i. 以下のコマンドを実行して ConfigMap を編集します.<config_map> を編集するConfigMap の名前に置き換えます。

# oc edit cm <config_map> -n openshift-node

ii. mtu パラメーターを、1388 バイトなどの IPsec オーバーヘッドに十分な MTU サイズに更新します。

b. 以下のコマンドを実行して SDN インターフェースを削除します。<ovs_pod_name> をOVS Pod の名前に置き換えます。

networkConfig: mtu: 1388

第第35章章 IPSEC を使用したノード間のトラフィックの暗号化を使用したノード間のトラフィックの暗号化

325

1 2 3

1 2 3

# oc exec <ovs_pod_name> -- ovs-vsctl del-br br0

c. クラスターの各ノードについて、以下のアクションを実行します。

i. 更新した MTU 値が /etc/origin/node/node-config.yaml ファイルに保存されていることを確認します。

ii. 以下のコマンドを実行して SDN および OVS Pod を再起動します。

# oc delete pod -n openshift-sdn -l=app=ovs# oc delete pod -n openshift-sdn -l=app=sdn

35.2.1. 証明書での IPsec の設定

OpenShift Container Platform の内部認証局 (CA) を使用して、IPsec に適した RSA キーを生成できます。内部 CA の共通名 (CN) の値は openshift-signer に設定されます。

1. 以下のコマンドを実行して、マスターノードで RSA 証明書を生成します。

# export CA=/etc/origin/master

# oc adm ca create-server-cert \ --signer-cert=$CA/ca.crt --signer-key=$CA/ca.key \ --signer-serial=$CA/ca.serial.txt \ --hostnames='<hostname>' \ 1 --cert=<hostname>.crt \ 2 --key=<hostname>.key 3

<hostname> をノードの完全修飾ドメイン名 (FQDN) に置き換えます。

2. openssl を使用してクライアント証明書、CA 証明書、およびプライベートキーファイルをPKCS#12 ファイルに追加します。これは、複数の証明書およびキーの共通ファイル形式です。

# openssl pkcs12 -export \ -in <hostname>.crt \ 1 -inkey <hostname>.key \ 2 -certfile /etc/origin/master/ca.crt \ -passout pass: \ -out <hostname>.p12 3

ノードの完全修飾ドメイン名 (FQDN) で置き換えます。

3. クラスター内の各ノードについて、直前の手順でホストに作成したファイルを安全に転送し、PKCS#12 ファイルを libreswan 証明書データベースにインポートします。-W オプションは、パスワードが一時的で PKCS#12 ファイルに割り当てられないため、空のままになります。

# ipsec initnss# pk12util -i <hostname>.p12 -d sql:/etc/ipsec.d -W ""# rm <hostname>.p12


326

1

2

35.2.2. libreswan IPsec ポリシーの作成

必要な証明書が libreswan 証明書データベースにインポートされた後に、それらを使用してクラスター内のホスト間の通信をセキュリティー保護するポリシーを作成します。

libreswan 3.19 以降を使用している場合、便宜的なグループ (opportunistic group) 設定が推奨されます。これ以外の場合は、明示的な接続が必要になります。

35.2.2.1. 便宜的なグループ便宜的なグループ (opportunistic group) の設定の設定

以下の設定は 2 つの libreswan 接続を作成します。最初の設定は OpenShift Container Platform 証明書を使用してトラフィックを暗号化し、2 つ目の設定はクラスターの外部トラフィック用に暗号化に対する例外を作成します。

1. 以下を /etc/ipsec.d/openshift-cluster.conf ファイルに配置します。

conn private left=%defaultroute leftid=%fromcert # our certificate leftcert="NSS Certificate DB:<cert_nickname>" 1 right=%opportunisticgroup rightid=%fromcert # their certificate transmitted via IKE rightca=%same ikev2=insist authby=rsasig failureshunt=drop negotiationshunt=hold auto=ondemand encapsulation=yes 2

conn clear left=%defaultroute right=%group authby=never type=passthrough auto=route priority=100

<cert_nickname> を、手順 1 の証明書ニックネームに置き換えます。

NAT を使用しない場合、カプセル化を強制的に実行するには、設定に encapsulation=yes を含める必要があります。 Amazon および Azure 内部クラウドネットワークは IPsec ESP または AH パケットをルーティングしません。これらのパケットは UDP でカプセル化される必要があり、設定されている場合、NAT 検出は ESP を UDPのカプセル化に設定します。 NAT を使用する場合や、前述の Network/Cloud-Provider の制限下にない場合には、このパラメーターおよび値を省略します。

2. libreswan に対して、/etc/ipsec.d/policies/ のポリシーファイルを使用して各ポリシーを適用する IP サブネットおよびホストを示します。このファイルでは、それぞれの設定された接続に対応するポリシーファイルが設定されます。そのため、上記の例では、private および clear の2 つの接続のそれぞれに /etc/ipsec.d/policies/ のファイルが設定されます。/etc/ipsec.d/policies/private には、ホストの IP アドレスの受信元であるクラスターの IP サブネットが含まれる必要があります。これにより、デフォルトでは、リモートホストのクライ


327

アント証明書がローカルホストの認証局の証明書に対して認証される場合、クラスターサブネットのホスト間のすべての通信が暗号化されることになります。リモートホストの証明書が認証されない場合、2 つのホスト間のすべてのトラフィックがブロックされます。

たとえば、すべてのホストが 172.16.0.0/16 アドレス空間のアドレスを使用するように設定される場合、private ポリシーファイルには 172.16.0.0/16 が含まれることになります。暗号化する追加サブセットの任意の数がこのファイルに追加され、それらのサブネットへのすべてのトラフィックでも IPsec が使用されることになります。

3. トラフィックがクラスターに出入りすることを確認するためにすべてのホストとサブネットゲートウェイ間の通信の暗号化を解除します。ゲートウェイを /etc/ipsec.d/policies/clearファイルに追加します。

172.16.0.1/32

追加のホストおよびサブネットをこのファイルに追加できます。これにより、これらのホストおよびサブネットへのすべてのトラフィックの暗号が解除されます。

35.2.2.2. 明示的な接続の設定明示的な接続の設定

この設定では、各 IPSec ノード設定がクラスター内の他のすべてのノードの設定を明示的に一覧表示する必要があります。各ノードで Ansible などの設定管理ツールを使用してこのファイルを生成することが推奨されます。

注記注記

node-config.yaml ファイルを手動で編集できません。クラスターのノードを変更するには、ノード設定マップを必要に応じて更新します。

また、この設定では各ノードの完全な証明書サブジェクトをその他のノードの設定に配置する必要があります。

1. openssl を使用して、このサブジェクトをノードの証明書から読み取ります。

# openssl x509 \ -in /path/to/client-certificate -text | \ grep "Subject:" | \ sed 's/[[:blank:]]*Subject: //'

2. 以下の行を、クラスター内のその他のノード用に各ノードの /etc/ipsec.d/openshift-cluster.conf ファイルに配置します。

conn <other_node_hostname> left=<this_node_ip> 1 leftid="CN=<this_node_cert_nickname>" 2 leftrsasigkey=%cert leftcert=<this_node_cert_nickname> 3 right=<other_node_ip> 4 rightid="<other_node_cert_full_subject>" 5 rightrsasigkey=%cert auto=start keyingtries=%forever encapsulation=yes 6


328

1

2 3

4

5

6

1

<this_node_ip> をこのノードのクラスター IP アドレスに置き換えます。

<this_node_cert_nickname> を手順 1 のノードの証明書ニックネームに置き換えます。

<other_node_ip> を他のノードのクラスター IP アドレスに置き換えます。

<other_node_cert_full_subject> を上記の他のノードの証明書に置き換えます。たとえば、"O=system:nodes,CN=openshift-node-45.example.com" のようになります。

NAT を使用しない場合、カプセル化を強制的に実行するには、設定に encapsulation=yes を含める必要があります。 Amazon および Azure 内部クラウドネットワークは IPsec ESP または AH パケットをルーティングしません。これらのパケットは UDP でカプセル化される必要があり、設定されている場合、NAT 検出は ESP を UDPのカプセル化に設定します。 NAT を使用する場合や、前述の Network/Cloud-Provider の制限下にない場合には、このパラメーターおよび値を省略します。

3. 以下を各ノードの /etc/ipsec.d/openshift-cluster.secrets ファイルに配置します。

: RSA "<this_node_cert_nickname>" 1

<this_node_cert_nickname> を手順 1 のノードの証明書ニックネームに置き換えます。

35.3. IPSEC ファイアウォールの設定

クラスター内のすべてのノードは、IPSec 関連のネットワークトラフィックを許可する必要があります。これには、UDP ポート 500 だけでなく IP プロトコル番号の 50 と 51 が含まれます。

たとえば、クラスターノードがインターフェース eth0 で通信する場合、以下のようになります。

-A OS_FIREWALL_ALLOW -i eth0 -p 50 -j ACCEPT-A OS_FIREWALL_ALLOW -i eth0 -p 51 -j ACCEPT-A OS_FIREWALL_ALLOW -i eth0 -p udp --dport 500 -j ACCEPT

注記注記

また IPSec は、NAT traversal に UDP ポート 4500 を使用します。ただし、これは通常のクラスターデプロイメントに適用することはできません。

35.4. IPSEC の開始および終了

1. ipsec サービスを開始し、新規の設定およびポリシーを読み込み、暗号化を開始します。

# systemctl start ipsec

2. ipsec サービスを有効にして起動時に開始します。

# systemctl enable ipsec

35.5. IPSEC の最適化

IPSec を使用した暗号化の場合のパフォーマンス関連の提案についての詳細は、『Scaling and


329

IPSec を使用した暗号化の場合のパフォーマンス関連の提案についての詳細は、『Scaling andPerformance Guide』を参照してください。

35.6. トラブルシューティング

2 つのノード間で認証を完了できない場合、すべてのトラフィックが拒否されるため、それらの間でping を行うことはできません。clear ポリシーが適切に設定されていない場合も、クラスター内の別のホストから SSH をホストに対して実行することはできません。

ipsec status コマンドを使用して clear および private ポリシーが読み込まれていることを確認できます。


330

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/scaling_and_performance_guide/#scaling-performance-optimizing-ipsec

第36章依存関係ツリーのビルド

36.1. 概要

OpenShift Container Platform は、イメージストリームタグの更新時を検知するために BuildConfigのイメージ変更トリガーを使用します。oc adm build-chain コマンドを使用し、指定されたイメージストリームでイメージを更新することによって影響を受けるイメージを特定する依存関係ツリーをビルドできます。

build-chain ツールは、トリガーするビルドを判別します。このツールはそれらのビルドの出力を解析し、それらが別のイメージストリームタグを更新するかどうかを判別します。更新する場合、このツールは依存関係ツリーを引き続きフォローします。最後に、トップレベルのタグの更新によって影響を受けるイメージストリームタグを指定するグラフを出力します。このツールのデフォルトの出力構文は人間が判読できる形式に設定されます。DOT 形式もサポートされます。

36.2. 使用法

以下の表は、よく使用される build-chain の使用方法と一般的な構文について説明しています。

表36.1 よく使用される build-chain 操作

説明説明構文構文

<image-stream> の最新最新タグの依存関係ツリーをビルドします。 $ oc adm build-chain <image-stream>

DOT 形式で v2 タグの依存関係ツリーをビルドし、DOT ユーティリティーを使用してこれを可視化します。

$ oc adm build-chain <image-stream>:v2 \ -o dot \ | dot -T svg -o deps.svg

test プロジェクトにある指定されたイメージストリームタグについての全プロジェクト間の依存関係ツリーをビルドします。

$ oc adm build-chain <image-stream>:v1 \ -n test --all

注記注記

graphviz パッケージをインストールして dot コマンドを使用する必要がある場合があります。

第第36章章依存関係ツリーのビルド依存関係ツリーのビルド

331


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#image-change-triggers

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#image-streams

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#docker-images

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#builds


第37章失敗した ETCD メンバーの置き換え一部の etcd メンバーが失敗しても、依然として etcd メンバーのクォーラム(定足数) がある場合、残りの etcd メンバーおよびそれらに含まれるデータを使用して、etcd またはクラスターのダウンタイムなしに etcd メンバーを追加できます。

37.1. 失敗した ETCD メンバーの削除

新規の etcd ノードを追加する前に、失敗したノードを削除します。

手順手順

1. アクティブな etcd ホストから、失敗した etcd ノードを削除します。

# etcdctl -C https://<surviving host IP>:2379 \ --ca-file=/etc/etcd/ca.crt \ --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key cluster-health

# etcdctl -C https://<surviving host IP>:2379 \ --ca-file=/etc/etcd/ca.crt \ --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key member remove <failed member identifier>

2. etcd Pod 定義を削除して、失敗した etcd メンバーで etcd サービスを停止します。


3. etcd ディレクトリーの内容を削除します。

重要重要

このディレクトリーのバックアップは、コンテンツを削除する前にクラスター外の場所に対して行うことが推奨されます。正常に復元した後に、このバックアップを削除できます。

# rm -rf /var/lib/etcd/*

37.2. ETCD メンバーの追加

etcd ホストは、Ansible Playbook または手動の手順のいずれかを使用して追加できます。


手順


[OSEv3:children]masters


332

1 2 3

nodesetcdnew_etcd 1










[etcd]master-0.example.commaster-1.example.commaster-2.example.cometcd0.example.com






etcd をマスターノードで静的 Pod として実行しない場合、別の etcd ホストを追加する必要が生じる場

第第37章章失敗した失敗した ETCD メンバーの置き換えメンバーの置き換え

333


手順現在の etcd クラスターの変更etcd 証明書を作成するには、値を環境の値に置き換えて openssl コマンドを実行します。




注記注記






# openssl ca -name etcd_ca -config ${OPENSSLCFG} \ -out ${PREFIX}server.crt \ -in ${PREFIX}server.csr \ -extensions etcd_v3_ca_server -batch




5. 後で変更できるように、現在の etcd 設定および ca.crt ファイルをサンプルとして現在のノー


334

1








$ ss -l4n | grep 2380






335

1

警告警告








ETCD_NAME








336












注記注記


警告警告





337














# ETCDCTL_API=3 etcdctl --cert="/etc/etcd/peer.crt" \ --key=/etc/etcd/peer.key \ --cacert="/etc/etcd/ca.crt" \ --endpoints="https://*master-0.example.com*:2379,\ https://*master-1.example.com*:2379,\ https://*master-2.example.com*:2379,\ https://*etcd0.example.com*:2379"\ endpoint healthhttps://master-0.example.com:2379 is healthy: successfully committed proposal: took = 5.011358mshttps://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.305173mshttps://master-2.example.com:2379 is healthy: successfully committed proposal: took =


338

1.388772mshttps://etcd0.example.com:2379 is healthy: successfully committed proposal: took = 1.498829ms



etcdClientInfo: ca: master.etcd-ca.crt certFile: master.etcd-client.crt keyFile: master.etcd-client.key urls: - https://master-0.example.com:2379 - https://master-1.example.com:2379 - https://master-2.example.com:2379 - https://etcd0.example.com:2379




警告警告







339

第38章 ETCD のクォーラム(定足数) の復元etcd のクォーラム(定足数) を失う場合、それを復元できます。

etcd を別のホストで実行する場合、etcd をバックアップし、etcd クラスターを停止してからこれを新たに作成する必要があります。1 つの正常な etcd ノードを使用して新規クラスターを作成することができますが、他のすべての正常なノードを削除する必要があります。

etcd をマスターノード上で静的 Pod として実行する場合、etcd Pod を停止し、一時的なクラスターを作成してから etcd Pod を再起動します。

注記注記

etcd のクォーラム(定足数) が失われる際に、OpenShift Container Platform で実行されるアプリケーションは影響を受けません。ただし、プラットフォームの機能は読み取り専用の操作に制限されます。アプリケーションの拡大または縮小、デプロイメントの変更、またはビルドの実行または変更などの操作を実行することはできません。

etcd のクォーラム(定足数) が失われていることを確認するには、以下のコマンドのいずれかを実行し、クラスターが正常な状態にないことを確認します。

etcd v2 API を使用する場合、以下のコマンドを実行します。

# etcd_ctl=2 etcdctl --cert-file=/etc/origin/master/master.etcd-client.crt \ --key-file /etc/origin/master/master.etcd-client.key \ --ca-file /etc/origin/master/master.etcd-ca.crt \ --endpoints="https://*master-0.example.com*:2379,\ https://*master-1.example.com*:2379,\ https://*master-2.example.com*:2379"\ cluster-health

member 165201190bf7f217 is unhealthy: got unhealthy result from https://master-0.example.com:2379member b50b8a0acab2fa71 is unreachable: [https://master-1.example.com:2379] are all unreachablemember d40307cbca7bc2df is unreachable: [https://master-2.example.com:2379] are all unreachablecluster is unhealthy

v3 API を使用する場合、以下のコマンドを実行します。

# ETCDCTL_API=3 etcdctl --cert=/etc/origin/master/master.etcd-client.crt \ --key=/etc/origin/master/master.etcd-client.key \ --cacert=/etc/origin/masterca.crt \ --endpoints="https://*master-0.example.com*:2379,\ https://*master-1.example.com*:2379,\ https://*master-2.example.com*:2379"\ endpoint healthhttps://master-0.example.com:2379 is unhealthy: failed to connect: context deadline exceededhttps://master-1.example.com:2379 is unhealthy: failed to connect: context deadline exceededhttps://master-2.example.com:2379 is unhealthy: failed to connect: context deadline exceededError: unhealthy cluster


340

ホストのメンバー ID およびホスト名を書き留めます。到達できるノードのいずれかを使用して新規クラスターを作成します。

38.1. 複数サービスの ETCD クォーラム(定足数) の復元

38.1.1. etcd のバックアップ

etcd のバックアップ時に、etcd 設定ファイルと etcd データの両方をバックアップする必要があります。

38.1.1.1. etcd 設定ファイルのバックアップ設定ファイルのバックアップ

保持する etcd 設定ファイルはすべて etcd が実行されているインスタンスの /etc/etcd ディレクトリーに保存されます。これには、etcd 設定ファイル (/etc/etcd/etcd.conf) およびクラスターの通信に必要な証明書が含まれます。それらすべてのファイルは Ansible インストーラーによってインストール時に生成されます。

手順クラスターの各 etcd メンバーについての etcd 設定をバックアップします。

$ ssh master-0# mkdir -p /backup/etcd-config-$(date +%Y%m%d)/# cp -R /etc/etcd/ /backup/etcd-config-$(date +%Y%m%d)/

注記注記

各 etcd クラスターメンバーの証明書および設定ファイルは一意のものです。

38.1.1.2. etcd データのバックアップデータのバックアップ

前提条件

注記注記

OpenShift Container Platform インストーラーはエイリアスを作成するため、etcdctl2(etcd v2 タスクの場合) と etcdctl3 (etcd v3 タスクの場合) という名前のすべてのフラグを入力しなくて済みます。

ただし、etcdctl3 エイリアスは etcdctl コマンドに詳細なエンドポイント一覧を提供しないため、--endpoints オプションを指定し、すべてのエンドポイントを一覧表示する必要があります。

etcd をバックアップする前に、以下を確認してください。

etcdctl バイナリーが利用可能であるか、またはコンテナー化インストールの場合は rhel7/etcdコンテナーが利用可能でなければなりません。

OpenShift Container Platform API サービスが実行中であることを確認します。

etcd クラスターとの接続を確認します (ポート 2379/tcp)。

etcd クラスターに接続するために使用する適切な証明書があることを確認します。

第第38章章 ETCD のクォーラムのクォーラム(定足数定足数) の復元の復元

341

1

go がインストールされていることを確認します。

手順

注記注記

etcdctl backup コマンドはバックアップを実行するために使用されますが、etcd v3 にはバックアップの概念がありません。代わりに etcdctl snapshot save コマンドを使用してライブメンバーのスナップショットを取るか、または etcd データディレクトリーの member/snap/db ファイルをコピーしてください。

etcdctl backup コマンドは、ノード ID やクラスター ID などのバックアップに含まれるメタデータの一部を書き換えるので、バックアップでは、ノードの以前のアイデンティティーが失われます。バックアップからクラスターを再作成するには、新規の単一ノードクラスターを作成してから、残りのノードをクラスターに追加します。メタデータは新規ノードが既存クラスターに加わらないように再作成されます。

etcd データをバックアップします。

重要重要

OpenShift Container Platform の以前のバージョンからアップグレードしたクラスターには、v2 データストアが含まれる可能性があります。すべての etcd データストアをバックアップしてください。

1. 静的 Pod マニフェストから etcd エンドポイント IP アドレスを取得します。

$ export ETCD_POD_MANIFEST="/etc/origin/node/pods/etcd.yaml"$ export ETCD_EP=$(grep https ${ETCD_POD_MANIFEST} | cut -d '/' -f3)

2. etcd Pod 名を取得します。

$ oc login -u system:admin$ export ETCD_POD=$(oc get pods -n kube-system | grep -o -m 1 '\S*etcd\S*')

3. Pod の etcd データのスナップショットを作成し、これをローカルに保存します。

$ oc project kube-system$ oc exec ${ETCD_POD} -c etcd -- /bin/bash -c "ETCDCTL_API=3 etcdctl \ --cert /etc/etcd/peer.crt \ --key /etc/etcd/peer.key \ --cacert /etc/etcd/ca.crt \ --endpoints $ETCD_EP \ snapshot save /var/lib/etcd/snapshot.db" 1

スナップショットを /var/lib/etcd/ の下のディレクトリーに書き込む必要があります。

38.1.2. etcd ホストの削除

etcd ホストが復元後も失敗する場合、これをクラスターから削除します。etcd のクォーラム(定足数)が失われた状態から回復するには、クラスターから 1 つの etcd ノード以外のすべての正常な etcd ノードを削除する必要もあります。


342

1 2

すべてのマスターホストで実行する手順

手順

1. 各 etcd ホストを etcd クラスターから削除します。それぞれの etcd ノードについて以下のコマンドを実行します。

# etcdctl -C https://<surviving host IP address>:2379 \ --ca-file=/etc/etcd/ca.crt \ --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key member remove <failed member ID>

2. すべてのマスターの /etc/origin/master/master-config.yaml +master 設定ファイルから他のetcd ホストを削除します。

etcdClientInfo: ca: master.etcd-ca.crt certFile: master.etcd-client.crt keyFile: master.etcd-client.key urls: - https://master-0.example.com:2379 - https://master-1.example.com:2379 1 - https://master-2.example.com:2379 2

削除するホストです。

3. すべてのマスターでマスター API サービスを再起動します。

# master-restart api restart-master controller

現在の etcd クラスターで実行する手順

手順

1. 失敗したホストをクラスターから削除します。

# etcdctl2 cluster-healthmember 5ee217d19001 is healthy: got healthy result from https://192.168.55.12:2379member 2a529ba1840722c0 is healthy: got healthy result from https://192.168.55.8:2379failed to check the health of member 8372784203e11288 on https://192.168.55.21:2379: Get https://192.168.55.21:2379/health: dial tcp 192.168.55.21:2379: getsockopt: connection refusedmember 8372784203e11288 is unreachable: [https://192.168.55.21:2379] are all unreachablemember ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379cluster is healthy

# etcdctl2 member remove 8372784203e11288 1Removed member 8372784203e11288 from cluster

# etcdctl2 cluster-healthmember 5ee217d19001 is healthy: got healthy result from https://192.168.55.12:2379


343

1

member 2a529ba1840722c0 is healthy: got healthy result from https://192.168.55.8:2379member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379cluster is healthy

remove コマンドにはホスト名ではなく、etcd ID が必要です。

2. etcd 設定で etcd サービスの再起動時に失敗したホストを使用しないようにするには、残りのすべての etcd ホストで /etc/etcd/etcd.conf ファイルを変更し、ETCD_INITIAL_CLUSTER 変数の値から失敗したホストを削除します。

# vi /etc/etcd/etcd.conf

例:

ETCD_INITIAL_CLUSTER=master-0.example.com=https://192.168.55.8:2380,master-1.example.com=https://192.168.55.12:2380,master-2.example.com=https://192.168.55.13:2380

以下のようになります。

ETCD_INITIAL_CLUSTER=master-0.example.com=https://192.168.55.8:2380,master-1.example.com=https://192.168.55.12:2380

注記注記

失敗したホストは etcdctl を使用して削除されているので、etcd サービスの再起動は不要です。

3. Ansible インベントリーファイルをクラスターの現在のステータスを反映し、Playbook の再実行時の問題を防げるように変更します。

[OSEv3:children]mastersnodesetcd


[etcd]master-0.example.commaster-1.example.com

4. Flannel を使用している場合、すべてのホストの /etc/sysconfig/flanneld にある flanneld サービス設定を変更し、etcd ホストを削除します。

FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379




344

1

38.1.3. 単一ノード etcd クラスターの作成

OpenShift Container Platform インスタンスの完全な機能を復元するには、残りの etcd ノードをスタンドアロン etcd クラスターにします。

手順

1. クラスターから削除しなかった etcd ノードで、etcd の Pod 定義を削除してすべての etcdサービスを停止します。

# mkdir -p /etc/origin/node/pods-stopped# mv /etc/origin/node/pods/etcd.yaml /etc/origin/node/pods-stopped/# systemctl stop atomic-openshift-node# mv /etc/origin/node/pods-stopped/etcd.yaml /etc/origin/node/pods/

2. ホストで etcd サービスを実行し、新規クラスターを強制的に実行します。これらのコマンドは、--force-new-cluster オプションを etcd 起動コマンドに追加する etcdサービスのカスタムファイルを作成します。

# mkdir -p /etc/systemd/system/etcd.service.d/# echo "[Service]" > /etc/systemd/system/etcd.service.d/temp.conf# echo "ExecStart=" >> /etc/systemd/system/etcd.service.d/temp.conf# sed -n '/ExecStart/s/"$/ --force-new-cluster"/p' \ /usr/lib/systemd/system/etcd.service \ >> /etc/systemd/system/etcd.service.d/temp.conf

# systemctl daemon-reload# master-restart etcd

3. etcd メンバーを一覧表示し、メンバー一覧に単一の etcd ホストのみが含まれることを確認します。

# etcdctl member list165201190bf7f217: name=192.168.34.20 peerURLs=http://localhost:2380 clientURLs=https://master-0.example.com:2379 isLeader=true

4. データの復元および新規クラスターの作成後に、peerURLs パラメーターを、etcd がピア通信をリッスンする IP アドレスを使用するように更新します。

# etcdctl member update 165201190bf7f217 https://192.168.34.20:2380 1

165201190bf7f217 は直前のコマンドの出力に示されるメンバー ID であり、https://192.168.34.20:2380 はその IP アドレスです。

5. 検証するには、IP がメンバーの一覧にあることを確認します。

$ etcdctl2 member list5ee217d17301: name=master-0.example.com peerURLs=https://*192.168.55.8*:2380 clientURLs=https://192.168.55.8:2379 isLeader=true

38.1.4. 復元後の etcd ノードの追加

最初のインスタンスを実行後に、複数の etcd サーバーをクラスターに追加できます。


345

https://192.168.34.20:2380

手順

1. ETCD_NAME 変数でインスタンスの etcd 名を取得します。

# grep ETCD_NAME /etc/etcd/etcd.conf

2. etcd がピア通信をリッスンする IP アドレスを取得します。

# grep ETCD_INITIAL_ADVERTISE_PEER_URLS /etc/etcd/etcd.conf

3. ノードが以前のバージョンで etcd クラスターに含まれていた場合には、以前の etcd データを削除します。

# rm -Rf /var/lib/etcd/*

4. etcd が正しく実行されている etcd ホストで、新しいメンバーを追加します。

# etcdctl3 member add *<name>* \ --peer-urls="*<advertise_peer_urls>*"

このコマンドでは、以下のような変数が出力されます。

ETCD_NAME="master2"ETCD_INITIAL_CLUSTER="master-0.example.com=https://192.168.55.8:2380"ETCD_INITIAL_CLUSTER_STATE="existing"

5. 新しいホストの /etc/etcd/etcd.conf ファイルに、以前のコマンドからの値を追加します。

# vi /etc/etcd/etcd.conf

6. クラスターに参加するノードで etcd サービスを起動します。

# systemctl start etcd.service



8. 全ノードを追加したら、クラスターのステータスと正常性を確認します。

# etcdctl3 endpoint health --endpoints="https://<etcd_host1>:2379,https://<etcd_host2>:2379,https://<etcd_host3>:2379"https://master-0.example.com:2379 is healthy: successfully committed proposal: took = 1.423459mshttps://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.767481mshttps://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.599694ms

# etcdctl3 endpoint status --endpoints="https://<etcd_host1>:2379,https://<etcd_host2>:2379,https://<etcd_host3>:2379"


346

https://master-0.example.com:2379, 40bef1f6c79b3163, 3.2.5, 28 MB, true, 9, 2878https://master-1.example.com:2379, 1ea57201a3ff620a, 3.2.5, 28 MB, false, 9, 2878https://master-2.example.com:2379, 59229711e4bc65c8, 3.2.5, 28 MB, false, 9, 2878

9. 残りのピアをクラスターに戻します。

38.2. 静的 POD の ETCD クォーラム(定足数) の復元

etcd に静的 Pod を使用するクラスターで etcd のクォーラム(定足数) を失う場合、以下の手順を実行します。

手順手順

1. etcd Pod を停止します。

mv /etc/origin/node/pods/etcd.yaml .

2. etcd ホスト上で新規クラスターを一時的に強制します。

$ cp /etc/etcd/etcd.conf etcd.conf.bak$ echo "ETCD_FORCE_NEW_CLUSTER=true" >> /etc/etcd/etcd.conf

3. etcd Pod を再起動します。

$ mv etcd.yaml /etc/origin/node/pods/.

4. etcd Pod を停止し、FORCE_NEW_CLUSTER コマンドを削除します。

$ mv /etc/origin/node/pods/etcd.yaml .$ rm /etc/etcd/etcd.conf$ mv etcd.conf.bak /etc/etcd/etcd.conf

5. etcd Pod を再起動します。

$ mv etcd.yaml /etc/origin/node/pods/.


347

第39章 OPENSHIFT SDN のトラブルシューティング

39.1. 概要

SDN のドキュメントで説明されているように、あるコンテナーから別のコンテナーへのトラフィックを適切に渡すために作成されるインターフェースには複数のレイヤーがあります。接続の問題をデバッグするには、スタックの複数のレイヤーをテストして問題の原因を判別する必要があります。本書は複数のレイヤーを調べて問題を特定し、解決するのに役立ちます。

問題の原因の一部は OpenShift Container Platform が複数の方法で設定でき、ネットワークが複数の異なる場所で正しく設定されない可能性がある点にあります。本書では、いくつかのシナリオを使用しますが、これらのシナリオは大半のケースに対応していることが予想されます。実際に生じている問題がこれらのシナリオで扱われていない場合には、導入されている各種のツールおよび概念を使用してデバッグ作業を行うことができます。

39.2. 用語

クラスター

クラスター内の一連のマシンです。例: マスターおよびノード。

マスター

OpenShift Container Platform クラスターのコントローラーです。マスターはクラスター内のノードではない場合があり、そのため Pod への IP 接続がない場合があることに注意してください。

ノード

Pod をホストできる OpenShift Container Platform を実行するクラスター内のホストです。

Pod

OpenShift Container Platform によって管理される、ノード上で実行されるコンテナーのグループです。

Service

1 つ以上の Pod でサポートされる、統一ネットワークインターフェースを表す抽象化です。

ルーター

複数の URL とパスを OpenShift Container Platform サービスにマップし、外部トラフィックがクラスターに到達できるようにする web プロキシーです。

ノードアドレス

ノードの IP アドレスです。これはノードが割り当てられるネットワークの所有者によって割り当てられ、管理されます。クラスター内の任意のノード (マスターおよびクライアント) からアクセスできる必要があります。

Pod アドレス

Pod の IP アドレスです。これらは OpenShift Container Platform によって割り当てられ、管理されます。デフォルトで、これらは 10.128.0.0/14 ネットワーク (または古いバージョンでは 10.1.0.0/16)から割り当てられます。クライアントノードからのみアクセスできます。

サービスアドレス

サービスを表す IP アドレスで、内部で Pod アドレスにマップされます。これらは OpenShiftContainer Platform によって割り当てられ、管理されます。デフォルトで、これらは 172.30.0.0/16ネットワークから割り当てられます。クライアントノードからのみアクセスできます。

以下の図は、外部アクセスに関係するすべての構成部分を示しています。


348

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#architecture-additional-concepts-sdn

39.3. HTTP サービスへの外部アクセスのデバッグ

クラスター外のマシンを使用している場合で、クラスターで提供されるリソースにアクセスしようとしている場合、パブリック IP アドレスでリッスンし、クラスター内のトラフィックを「ルーティング」する Pod でプロセスが実行されている必要があります。この場合、OpenShift Container Platform ルーターは、HTTP、HTTPS (SNI を使用)、WebSockets または TLS (SNI を使用) について使用できます。

クラスター外より HTTP サービスにアクセスできないことを想定し、障害が発生しているマシンのコマンドラインを使って問題を再現します。以下を実行します。

curl -kv http://foo.example.com:8000/bar # But replace the argument with your URL

成功する場合は、正しい場所からバグを再現しているかどうかを確認します。サービスに機能する Podと機能しない Pod が含まれる可能性もあります。したがって、「ルーターのデバッグ」セクションを参照してください。

失敗した場合は、IP アドレスに対して DNS 名を解決します (ないことを想定します)。

dig +short foo.example.com # But replace the hostname with yours

IP アドレスが返されない場合は、DNS をトラブルシューティングする必要がありますが、これについては本書では扱いません。

重要重要

返される IP アドレスがルーターを実行するルーターであることを確認します。そうでない場合は、DNS を修正します。

次に ping -c address および tracepath address を使用して、ルーターホストに到達できることを確認します。それらが ICMP パケットに応答しない場合もあり、この場合はそれらのテストは失敗しますが、ルーターマシンにはアクセスできる場合があります。この場合、コマンドを使ってルーターのポートに直接アクセスしてみます。

telnet 1.2.3.4 8000

以下が表示される場合があります。

第第39章章 OPENSHIFT SDN のトラブルシューティングのトラブルシューティング

349


Trying 1.2.3.4...Connected to 1.2.3.4.Escape character is '^]'.

この場合、IP アドレスのポートでリッスンしているものがあることを示しています。ctrl-] を押してから enter キーを押し、close を入力して telnet を終了します。「ルーターのデバッグ」セクションに移行してルーターの他のものを確認します。

または、以下が表示される可能性があります。

Trying 1.2.3.4...telnet: connect to address 1.2.3.4: Connection refused

これは、ルーターがそのポートでリッスンしていないことを示します。ルーターの設定方法における追加のポイントについては、「ルーターのデバッグ」セクションを参照してください。

または、以下が表示される場合があります。

これは、IP アドレス上のいずれとも通信できないことを示します。ルーティング、ファイアウォールを確認し、IP アドレスでリッスンしているルーターがあることを確認します。ルーターをデバッグするには、「ルーターのデバッグ」セクションを参照してください。IP ルーティングおよびファイアウォールの問題については、本書では扱いません。

39.4. ルーターのデバッグ

IP アドレスを使用し、そのマシンに対して ssh を実行してルーターソフトウェアがそのマシン上で実行されており、正しく設定されていることを確認する必要があります。ここで ssh を実行し、管理者のOpenShift Container Platform 認証情報を取得します。

注記注記

管理者認証情報があるのに、デフォルトシステムユーザーの system:admin としてログインされていない場合、認証情報が CLI 設定ファイルにある限り、いつでもこのユーザーとしてログインし直すことができます。以下のコマンドはログインを実行し、デフォルトプロジェクトに切り替えます。

ルーターが実行されていることを確認します。

# oc get endpoints --namespace=default --selector=routerNAMESPACE NAME ENDPOINTSdefault router 10.128.0.4:80

このコマンドが失敗する場合、OpenShift Container Platform 設定は破損しています。この設定の修正については、本書では扱われません。

1 つ以上のルーターエンドポイントが一覧表示されますが、エンドポイント IP アドレスはクラスター内の Pod アドレスの 1 つであるため、それらが指定の外部 IP アドレスでマシン上で実行されているかどうかを識別することはできません。ルーターホスト IP アドレスの一覧を取得するには、以下を実行し

Trying 1.2.3.4... telnet: connect to address 1.2.3.4: Connection timed out

$ oc login -u system:admin -n default


350

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#users

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cli_reference/#cli-configuration-files

ます。

# oc get pods --all-namespaces --selector=router --template='{{range .items}}HostIP: {{.status.hostIP}} PodIP: {{.status.podIP}}{{"\n"}}{{end}}'HostIP: 192.168.122.202 PodIP: 10.128.0.4

外部アドレスに対応するホスト IP が表示されるはずです。表示されない場合は、ルーターのドキュメントを参照して、適切なノードで実行されるようにルーター Podを設定するか (アフィニティーを適切に設定する)、またはルーターが実行されている IP アドレスに一致するよう DNS を更新します。

(本書の) この時点では、ノードでルーター Pod を実行しても HTTP 要求を機能させることはできません。まず、ルーターが外部 URL を正しいサービスにマップしていること、またそれが機能している場合は、そのサービスの詳細を調べてすべてのエンドポイントがアクセス可能であることを確認する必要があります。

OpenShift Container Platform が認識するすべてのルートを一覧表示します。

# oc get route --all-namespacesNAME HOST/PORT PATH SERVICE LABELS TLS TERMINATIONroute-unsecured www.example.com /test service-name

URL のホスト名およびパスが返されるルートの一覧のいずれにも一致しない場合はルートを追加する必要があります。ルーターのドキュメントを参照してください。

ルートが存在する場合、エンドポイントへのアクセスをデバッグする必要があります。これはサービスに関する問題をデバッグしている場合と同様のプロセスです。そのため、次の「サービスのデバッグ」セクションに進んでください。

39.5. サービスのデバッグ

クラスター内からサービスと通信できない場合 (サービスが直接通信できないか、またはルーターを使用していてクラスターに入るまですべてが正常に機能している場合)、サービスに関連付けられているエンドポイントを判別し、それらをデバッグする必要があります。

最初にサービスを取得します。

# oc get services --all-namespacesNAMESPACE NAME LABELS SELECTOR IP(S) PORT(S)default docker-registry docker-registry=default docker-registry=default 172.30.243.225 5000/TCPdefault kubernetes component=apiserver,provider=kubernetes <none> 172.30.0.1 443/TCPdefault router router=router router=router 172.30.213.8 80/TCP

サービスが一覧に表示されます。表示されない場合は、サービスを定義する必要があります。

サービス出力に一覧表示される IP アドレスは Kubernetes サービス IP アドレスであり、これはKubernetes がサービスをサポートする Pod のいずれかにマップするものです。このの IP アドレスと通信できるはずですが、通信できたとしても、すべての Pod にアクセスできる訳ではありません。また、通信できない場合もすべての Pod がアクセスできない訳ではありません。これは kubeproxy が接続している 1 つの IP アドレスのステータスのみを示しています。

サービスをテストします。ノードのいずれかより以下を実行します。


351



https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#architecture-core-concepts-pods-and-services

curl -kv http://172.30.243.225:5000/bar # Replace the argument with your service IP address and port

次にサービスをサポートしている Pod を見つけます (docker-registry を破損したサービスの名前に置き換えます)。

# oc get endpoints --selector=docker-registryNAME ENDPOINTSdocker-registry 10.128.2.2:5000

ここではエンドポイントは 1 つだけであることを確認できます。そのため、サービステストが成功し、ルーターテストに成功した場合には、極めて稀なことが生じている可能性があります。ただし、複数のエンドポイントがあるか、またはサービステストが失敗した場合には、それぞれのエンドポイントについて以下を試行します。機能していないエンドポイントを特定できたら、次のセクションに進みます。

最初に、それぞれのエンドポイントをテストします (適切なエンドポイント IP、ポートおよびパスを持つように URL を変更します)。

curl -kv http://10.128.2.2:5000/bar

これが機能する場合は、次のエンドポイントをテストします。失敗した場合はその情報をメモしておきます。次のセクションでその原因を判別します。

すべてが失敗した場合は、ローカルノードが機能していない可能があります。その場合は、「ローカルネットワークのデバッグ」セクションに移行してください。

すべてが機能する場合は、「Kubernetes のデバッグ」セクションに移行してサービス IP アドレスが機能しない理由を判別します。

39.6. ノード間通信のデバッグ

機能していないエンドポイントの一覧を使用して、ノードに対する接続をテストする必要があります。

1. すべてのノードに予想される IP アドレスがあることを確認します。

# oc get hostsubnetNAME HOST HOST IP SUBNETrh71-os1.example.com rh71-os1.example.com 192.168.122.46 10.1.1.0/24rh71-os2.example.com rh71-os2.example.com 192.168.122.18 10.1.2.0/24rh71-os3.example.com rh71-os3.example.com 192.168.122.202 10.1.0.0/24

DHCP を使用している場合はそれらが変更されている可能性があります。ホスト名、IP アドレス、およびサブネットが予想される内容に一致していることを確認します。ノードの詳細が変更されている場合は、oc edit hostsubnet を使用してエントリーを訂正します。

2. ノードアドレスおよびホスト名が正しいことを確認した後に、エンドポイント IP およびノードIP を一覧表示します。

# oc get pods --selector=docker-registry \ --template='{{range .items}}HostIP: {{.status.hostIP}} PodIP: {{.status.podIP}}{{end}}{{"\n"}}'

HostIP: 192.168.122.202 PodIP: 10.128.0.4

3. 事前にメモしたエンドポイント IP アドレスを見つけ、これを PodIP エントリーを検索し、対


352

3. 事前にメモしたエンドポイント IP アドレスを見つけ、これを PodIP エントリーを検索し、対応する HostIP アドレスを見つけます。次に、HostIP からのアドレスを使用してノードホストレベルで接続をテストします。

ping -c 3 <IP_address>: 応答がないことは、中間ルーターが ICMP トラフィックを消費している可能性があることを意味しています。

tracepath <IP_address>: ICMP パケットがすべてのホップによって返される場合、ターゲットにつながる IP ルートを表示します。tracepath と ping の両方が失敗する場合、ローカルまたは仮想ネットワークの接続の問題を探します。

4. ローカルネットワークの場合は、以下を確認します。

追加設定なしの状態のパケットのターゲットアドレスへのルートを確認します。

# ip route get 192.168.122.202 192.168.122.202 dev ens3 src 192.168.122.46 cache

上記の例では、ソースアドレスが 192.168.122.46 の ens3 という名前のインターフェースからターゲットに直接つながります。これが予想される結果である場合は ip a show dev ens3 を使用してインターフェースの詳細を取得し、このインターフェースが予想されるインターフェースであることを確認します。

または、結果が以下になる可能性もあります。

# ip route get 192.168.122.202 1.2.3.4 via 192.168.122.1 dev ens3 src 192.168.122.46

これは、正しくルーティングされるために via値をパススルーします。トラフィックが正しくルーティングされていることを確認します。ルートトラフィックのデバッグについては、本書では扱われません。

ノード間ネットワークの他のデバッグオプションについては、以下を確認して解決できます。

どちらの側にもイーサネットリンクがあるか? ethtool <network_interface> で Link detected: yes を検索します。

デュプレックス設定とイーサネット速度はどちらの側でも適切に設定されているか? ethtool <network_interface> 情報の残りの部分を確認します。

ケーブルは適切にプラグインされているか? 正しいポートに接続されているか?

スイッチは適切に設定されているか?

ノード間設定が適切であることを確認した後は、両サイドで SDN 設定を確認する必要があります。

39.7. ローカルネットワークのデバッグ

ここで通信できないものの、ノード間通信が設定された 1 つ以上のエンドポイントの一覧が表示されます。それぞれのエンドポイントについて問題点を特定する必要がありますが、まずは SDN が複数の異なる Pod についてノードでネットワークをどのように設定しているかについて理解する必要があります。


353

39.7.1. ノードのインターフェース

以下は OpenShift SDN が作成するインターフェースです。

br0: コンテナーが割り当てられる OVS ブリッジデバイスです。OpenShift SDN はこのブリッジにサブネットに固有ではないフロールールのセットも設定します。

tun0: OVS 内部ポート (br0 のポート 2) です。これにはクラスターサブネットゲートウェイアドレスが割り当てられ、外部ネットワークアクセスに使用されます。OpenShift SDN はクラスターサブネットから NAT 経由で外部ネットワークにアクセスできるように netfilter およびルートルールを設定します。

vxlan_sys_4789: OVS VXLAN デバイス (br0 のポート 1) です。これはリモートノードのコンテナーへのアクセスを提供します。OVS ルールでは vxlan0 として参照されます。

vethX (メイン netns 内): Docker netns における eth0 の Linux 仮想イーサネットのピアです。これは他のポートのいずれかの OVS ブリッジに割り当てられます。

39.7.2. ノード内の SDN フロー

アクセスしようとしているもの (またはアクセスされるもの) によってパスは異なります。SDN が (ノード内に) で接続する場所は 4 カ所あります。それらには上記の図で赤のラベルが付けられています。

Pod: トラフィックは同じマシンのある Pod から別の Pod に移動します (1 から他の 1 へ)。

リモートノード (または Pod): トラフィックは同じクラスター内のローカル Pod からリモートノードまたは Pod に移動します (1 から 2 へ)。

外部マシン: トラフィックはローカル Pod からクラスター外に移動します (1 から 3 へ)。

当然のこととして、トラフィックはこれらと反対方向でも移動します。

39.7.3. デバッグ手順

39.7.3.1. IP 転送は有効にされているか転送は有効にされているか?

sysctl net.ipv4.ip_forward が 1 に設定されていること (およびホストが仮想マシンであるかどうか) を確認します。

39.7.3.2. ルートは正しく設定されているかルートは正しく設定されているか?

ip route でルートテーブルを確認します。

# ip route


354

default via 192.168.122.1 dev ens310.128.0.0/14 dev tun0 proto kernel scope link # This sends all pod traffic into OVS10.128.2.0/23 dev tun0 proto kernel scope link src 10.128.2.1 # This is traffic going to local pods, overriding the above169.254.0.0/16 dev ens3 scope link metric 1002 # This is for Zeroconf (may not be present)172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.42.1 # Docker's private IPs... used only by things directly configured by docker; not OpenShift192.168.122.0/24 dev ens3 proto kernel scope link src 192.168.122.46 # The physical interface on the local subnet

10.128.x.x 行が表示されるはずです (Pod ネットワークが設定内でデフォルト範囲に設定されていることを前提とします)。これが表示されない場合は、OpenShift Container Platform ログを確認します (「ログの読み取り」セクションを参照してください)。

39.7.4. Open vSwitch (OVS) は正しく設定されているか?

OVS Pod のいずれかで ovs-vsctl and ovs-ofctl コマンドを実行する必要があります。

OVS Pod を一覧表示するには、以下のコマンドを入力します。

$ oc get pod -n openshift-sdn -l app=ovs

両サイドで Open vSwitch ブリッジを確認します。<ovs_pod_name> を OVS Pod のいずれかの名前に置き換えます。

$ oc exec -n openshift-sdn <ovs_pod_name> -- ovs-vsctl list-brbr0

直前のコマンドは br0 を返すはずです。

OVS が認識するすべてのポートを一覧表示できます。

$ oc exec -n openshift-sdn <ovs_pod_name> -- ovs-ofctl -O OpenFlow13 dump-ports-desc br0OFPST_PORT_DESC reply (OF1.3) (xid=0x2): 1(vxlan0): addr:9e:f1:7d:4d:19:4f config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max 2(tun0): addr:6a:ef:90:24:a3:11 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max 8(vethe19c6ea): addr:1e:79:f3:a0:e8:8c config: 0 state: 0 current: 10GB-FD COPPER speed: 10000 Mbps now, 0 Mbps max LOCAL(br0): addr:0a:7f:b4:33:c2:43 config: PORT_DOWN state: LINK_DOWN speed: 0 Mbps now, 0 Mbps max

とくにアクティブなすべての Pod の vethX デバイスがポートとして表示されるはずです。


355

次に、そのブリッジに設定されているフローを一覧表示します。

$ oc exec -n openshift-sdn <ovs_pod_name> -- ovs-ofctl -O OpenFlow13 dump-flows br0

ovs-subnet または ovs-multitenant プラグインのどちらを使用しているかに応じて結果は若干異なりますが、以下のような一般的な設定を確認することができます。

1. すべてのリモートノードには tun_src=<node_IP_address> に一致するフロー (ノードからの着信 VXLAN トラフィック) およびアクション set_field:<node_IP_address>->tun_dst を含む別のフロー(ノードへの発信 VXLAN トラフィック) が設定されている必要があります。

2. すべてのローカル Pod には arp_spa=<pod_IP_address> および arp_tpa=<pod_IP_address>に一致するフロー (Pod の着信および発信 ARP トラフィック) と、nw_src=<pod_IP_address> および nw_dst=<pod_IP_address> に一致するフロー (Pod の着信および発信 IP トラフィック) が設定されている必要があります。

フローがない場合は、「ログの読み取り」セクションを参照してください。

39.7.4.1. iptables 設定に誤りがないか設定に誤りがないか?

iptables-save の出力をチェックし、トラフィックにフィルターを掛けていないことを確認します。OpenShift Container Platform は通常の操作時に iptables ルールを設定するため、ここにエントリーが表示されていても不思議なことではありません。

39.7.4.2. 外部ネットワークは正しく設定されているか外部ネットワークは正しく設定されているか?

外部ファイアウォール (ある場合) を確認し、ターゲットアドレスへのトラフィックを許可するかどうかを確認します (これはサイトごとに異なるため、本書では扱われません)。

39.8. 仮想ネットワークのデバッグ

39.8.1. 仮想ネットワークのビルドに障害が発生している

仮想ネットワーク (例: OpeStack) を使用して OpenShift Container Platform をインストールしている場合で、ビルドに障害が発生している場合、ターゲットノードホストの最大伝送単位 (MTU: maximumtransmission unit) はプライマリーネットワークインターフェース (例: eth0) の MTU との互換性がない可能性があります。

ビルドが正常に完了するには、データをノードホスト間で渡すために SDN の MTU が eth0 ネットワークの MTU よりも小さくなければなりません。

1. ip addr コマンドを実行してネットワークの MTU を確認します。

# ip addr---2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e:56:4c:11 brd ff:ff:ff:ff:ff:ff inet 172.16.0.0/24 brd 172.16.0.0 scope global dynamic eth0 valid_lft 168sec preferred_lft 168sec inet6 fe80::f816:3eff:fe56:4c11/64 scope link valid_lft forever preferred_lft forever---


356

上記のネットワークの MTU は 1500 です。

2. ノード設定の MTU はネットワーク値よりも小さくなければなりません。ターゲットに設定されたノードホストの mtu を確認します。

# $ oc describe configmaps node-config-infra...networkConfig: mtu: 1450 networkPluginName: company/openshift-ovs-subnet...

上記のノード設定ファイルでは、mtu 値はネットワーク MTU よりも低くなるため、設定は不要になります。mtu 値がこれより高くなる場合はファイルを編集して、値をプライマリーネットワークインターフェースの MTU よりも少なくとも 50 単位分下げてノードサービスを再起動します。これにより、より大きなパケットのデータをノード間で渡すことが可能になります。

注記注記


39.9. POD の EGRESS のデバッグ

Pod から外部サービスへのアクセスを試行する場合、以下の例のようになります。

curl -kv github.com

DNS が適切に解決されていることを確認します。

dig +search +noall +answer github.com

これにより、github サーバーの IP アドレスが返されるはずですが、正しいアドレスが返されていることを確認します。アドレスが返されない場合やお使いのマシンのいずれかのアドレスが返される場合、ローカル DNS サーバーのワイルドカードエントリーに一致している可能性があります。

これを修正するには、ワイルドカードエントリーを持つ DNS サーバーが /etc/resolv.conf の nameserver として一覧表示されていないことを確認するか、またはワイルドカードドメインが search 一覧に一覧表示されていないことを確認する必要があります。

正しい IP アドレスが返される場合、「ローカルネットワークのデバッグ」の前述のデバッグに関するアドバイスに従ってください。通常、トラフィックはポート 2 の Open vSwitch から iptables ルールおよびルートテーブルを通過するはずです。

39.10. ログの読み取り

次を実行します: journalctl -u atomic-openshift-node.service --boot | less

Output of setup script: 行を検索します。'+' で始まるすべての行については、その下にスクリプト手順が記述されます。この部分で明らかなエラーがあるかどうかを調べます。

スクリプトを追ってみると、Output of adding table=0 という行を見つけることができるはずです。これは OVS ルールであり、エラーは存在しないはずです。


357

39.11. KUBERNETES のデバッグ

iptables -t nat -L を確認して、サービスがローカルマシンでkubeproxy の適切なポートに NAT されていることを確認します。

警告警告

上記についてはまもなく全面的に変更されます… Kubeproxy は除去され、iptablesのみのソリューションに置き換わります。

39.12. 診断ツールを使用したネットワークの問題の検出

クラスター管理者として診断ツールを実行し、共通するネットワークの問題を診断します。

# oc adm diagnostics NetworkCheck

診断ツールは、指定したコンポーネントのエラー状態をチェックする一連のチェックを実行します。詳細は、「診断ツール」のセクションを参照してください。

注記注記

現時点で、診断ツールでは IP フェイルオーバーの問題を診断できません。回避策として、スクリプトをマスターの https://raw.githubusercontent.com/openshift/openshift-sdn/master/hack/ipf-debug.sh で (またはマスターへのアクセスのある別のマシンから)実行して役に立つデバッグ情報を生成できます。ただし、このスクリプトはサポート対象外です。

デフォルトで、 oc adm diagnostics NetworkCheck はエラーのログを /tmp/openshift/ に記録します。これは --network-logdir オプションで設定できます。

# oc adm diagnostics NetworkCheck --network-logdir=<path/to/directory>

39.13. その他の注意点

39.13.1. ingress についての追加情報

Kube: サービスを NodePort として宣言し、クラスター内のすべてのマシンでそのポートを要求し、kube-proxy およびサポートする Pod にルーティングします。https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport を参照してください (一部のノードは外部からアクセスできる必要があります)。

Kube: LoadBalancer として宣言し、独自に判別したオブジェクトが残りを実行します。

OS/AE: いずれもルーターを使用します。

39.13.2. TLS ハンドシェイクのタイムアウト


358

https://raw.githubusercontent.com/openshift/openshift-sdn/master/hack/ipf-debug.sh

https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport

Pod がデプロイに失敗する場合、docker ログで TLS ハンドシェイクのタイムアウトを確認します。

$ docker log <container_id>...[...] couldn't get deployment [...] TLS handshake timeout...

この状態は通常はセキュアな接続を確立する際のエラーであり、このエラーは tun0 とプライマリーインターフェース (例: eth0) 間の MTU 値の大きな違い (例: tun0 MTU が 1500 に対し eth0 MTU が 9000(ジャンボフレーム) である場合) によって引き起こされる可能性があります。

39.13.3. デバッグについての他の注意点

(Linux 仮想イーサネットペア) のピアインターフェースは ethtool -S ifname で判別できます。

ドライバータイプ: ethtool -i ifname


359

第40章診断ツール

40.1. 概要

oc adm diagnostics コマンドは一連のチェックを実行し、ホストまたはクラスターのエラーの状態についてチェックします。とくに以下を実行します。

デフォルトのレジストリーおよびルーターが実行中であり、正しく設定されていることを確認します。

ClusterRoleBindings および ClusterRoles で、ベースポリシーとの整合性を確認します。

すべてのクライアント設定コンテキストが有効で接続可能であることを確認します。

SkyDNS が適切に機能しており、Pod に SDN 接続があることを確認します。

ホストのマスターおよびノード設定を検証します。

ノードが実行中で、利用可能であることを確認します。

既知のエラーについてホストログを分析します。

systemd ユニットがホストに対して予想通りに設定されていることを確認します。

40.2. 診断ツールの使用

OpenShift Container Platform は複数の方法でデプロイできます。それらには以下が含まれます。

ソースからのビルド

VM イメージ内への組み込み

コンテナーイメージとしての使用

エンタープライズ RPM の使用

それぞれの方法は設定および環境に応じて適宜使い分けられます。環境についての想定内容を最小限にするために、診断ツールが openshift バイナリーに組み込まれており、OpenShift Container Platformサーバーまたはクライアント内で診断が実行されます。

診断ツールを使用するには (マスターホスト上で使用するのが望ましい)、クラスター管理者として以下を実行します。

# oc adm diagnostics

これは利用可能なすべての診断を実行し、環境に適用されない手順を省略します。

名前別に特定の診断を実行するか、または問題に対応する際に使用する特定の診断を実行することができます。以下は例になります。

$ oc adm diagnostics

診断ツールの各種オプションでは、有効な設定ファイルが必要になります。たとえば、NodeConfigCheck はノード設定が利用可能でない場合は実行されません。


360

診断ツールは、デフォルトで標準設定ファイルの場所を使用します。

クライアント:

$KUBECONFIG 環境変数で示される。

~/.kube/config file

マスター:

/etc/origin/master/master-config.yaml

ノード:

/etc/origin/node/node-config.yaml

--config, --master-config、および --node-config オプションで標準以外の場所を指定できます。設定ファイルが指定されない場合、関連する診断は省略されます。

利用可能な診断には以下が含まれます。

診断名診断名目的目的

AggregatedLogging 集約されたログ統合を使用して適切な設定および操作を確認します。

AnalyzeLogs systemd サービスログで問題の有無を確認します。チェックの実行に設定ファイルは不要です。

ClusterRegistry クラスターにビルドおよびイメージストリームの作業用のコンテナーイメージレジストリーがあることを確認します。

ClusterRoleBindings デフォルトのクラスターロールバインディングが存在し、ベースポリシーに応じて予想されるサブジェクトが含まれることを確認します。

ClusterRoles クラスターロールが存在し、ベースポリシーに応じて予想されるパーミッションが含まれることを確認します。

ClusterRouter クラスター内に有効なデフォルトルーターがあることを確認します。

ConfigContexts クライアント設定の各コンテキストが完成したものであり、その API サーバーへの接続があることを確認します。

DiagnosticPod アプリケーションの観点で診断を実行する Pod を作成します。これは Pod 内の DNS が予想通りに機能しており、デフォルトサービスアカウントの認証情報がマスター API に対して正しく認証されることを確認します。

第第40章章診断ツール診断ツール

361

EtcdWriteVolume 一定期間における etcd に対する書き込みのボリュームを確認し、操作およびキー別にそれらを分類します。この診断は他の診断と同じ速度で実行されず、かつ etcd への負荷を増えることから、とくに要求される場合にのみ実行されます。

MasterConfigCheck このホストのマスター設定ファイルで問題の有無を確認します。

MasterNode このホストで実行されているマスターがノードも実行していることを確認し、それがクラスター SDN のメンバーであることを確認します。

MetricsApiProxy 統合 Heapster メトリクスがクラスター API プロキシー経由でアクセス可能であることを確認します。

NetworkCheck 複数のノードで診断 Pod を作成し、一般的なネットワークの問題をアプリケーションまたは Pod の観点で診断します。マスターが Pod をノードにスケジュールできるものの、Pod に接続の問題がある場合にこの診断を実行します。このチェックは、Podがサービス、他の Pod および外部ネットワークに接続できることを確認します。

エラーがある場合は、この診断は詳細な分析用としてローカルディレクトリー (デフォルトで/tmp/openshift/) に結果および取得されたファイルを保存します。ディレクトリーは --network-logdirフラグで指定することができます。

NodeConfigCheck このホストのノード設定ファイルで問題の有無を確認します。

NodeDefinitions マスター API で定義されたノードが利用可能な状態にあり、Pod をスケジュールできることを確認します。

RouteCertificateValidation すべてのルート証明書で、拡張される検証で拒否される可能性のあるものがあるかどうかを確認します。

ServiceExternalIPs マスター設定に基づいて無効にされている外部 IP を指定する既存サービスの有無を確認します。

UnitStatus OpenShift Container Platform に関連して、このホストでユニットについての systemd ステータスを確認します。チェックの実行に設定ファイルは不要です。

診断名診断名目的目的


362

40.3. サーバー環境における診断の実行

Ansible でデプロイされるクラスターは、OpenShift Container Platform クラスター内のノードに診断に関する追加の利点を提供します。これらには以下が含まれます。

マスターおよびノード設定は標準的な場所にある設定ファイルに基づく。

systemd ユニットがサーバーを管理するように設定される。

マスターおよびノード設定ファイルはいずれも標準的な場所に置かれる。

Systemd ユニットがクラスターでノードを管理するために作成され、設定される。

すべてのコンポーネントが journald に対してログを記録する。

Ansible でデプロイされたクラスターで配置された設定ファイルのデフォルトの場所を維持することにより、フラグを使用せずに oc adm diagnostics を実行できます。設定ファイルにデフォルトの場所を使用していない場合は、--master-config および --node-config オプションを使用する必要があります。

# oc adm diagnostics --master-config=<file_path> --node-config=<file_path>

systemd ユニットおよび journald のログエントリーは現在のログ診断ロジックに必要です。他のデプロイメントタイプの場合、ログは単一ファイルに保存されるか、ノードとマスターを組み合わせるファイルに保存されるか、または標準出力 (stdout) に出力されます。ログエントリーで journald を使用しない場合、ログ診断は適切に機能せず、実行されません。

40.4. クライアント環境での診断の実行

診断ツールは通常のユーザーまたは cluster-admin として実行でき、これは実行の際に使用するアカウントに付与されたレベルのパーミッションを使って実行します。

通常のアクセスを持つクライアントはマスターへの接続を診断し、診断 Pod を実行することができます。複数のユーザーまたはマスターが設定されている場合、接続のテストはそれらすべてを対象に実行されますが、診断 Pod は現行ユーザー、サーバー、またはプロジェクトに対してのみ実行されます。

cluster-admin アクセスを持つクライアントは、ノード、レジストリー、およびルーターなどのインフラストラクチャーのステータスを診断できます。いずれの場合も、oc adm diagnostics を実行すると、標準の場所で標準のクライアント設定ファイルを検索し、利用可能な場合はこれを使用できます。

40.5. ANSIBLE ベースのヘルスチェック

追加のヘルスチェックは、OpenShift Container Platform クラスターのインストールおよび管理に使用する Ansible ベースのツールで利用できます。このヘルスチェックでは、現行の OpenShift ContainerPlatform インストールによくあるデプロイメントの問題を報告します。

これらのチェックは、ansible-playbook コマンドの使用 (クラスターインストールで使用されるのと同じ方式) によるか、または openshift-ansible のコンテナー化されたバージョンとして実行できます。ansible-playbook 方式については、チェックは openshift-ansible RPM パッケージを使って行われます。コンテナー化方式の場合は、openshift3/ose-ansible コンテナーイメージが Red HatContainer Registry 経由で配布されます。各方式の使用例については、後続のセクションで説明されます。｜

以下のヘルスチェックは、デプロイされた OpenShift Container Platform クラスターを対象に、指定さ


363


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/installing_clusters/#install-running-installation-playbooks

https://github.com/openshift/openshift-ansible/blob/master/README_CONTAINER_IMAGE.md

https://registry.redhat.io

以下のヘルスチェックは、デプロイされた OpenShift Container Platform クラスターを対象に、指定された health.yml playbook を使用して Ansible インベントリーファイルに対して実行されることが意図されている診断タスクのセットのこと指します。

警告警告

ヘルスチェック Playbook が環境に変更を加える可能性があるため、これらのPlaybook は Ansible を使ってデプロイされたクラスターで、デプロイ時に使用したものと同じインベントリーファイルを使う場合にのみ使用できます。これらの変更には、チェックで必要な情報を収集できるように依存関係をインストールすることに関連するものです。そのような状況では、docker またはネットワーク設定などの追加のシステムコンポーネントは、現在の状態がインベントリーファイルの設定と異なる場合に変更される可能があります。これらのヘルスチェックは、使用するインベントリーファイルが既存のクラスター設定に変更を加えないことが予想される場合にのみ実行してください。

表40.1 正常性診断チェック

チェック名チェック名目的目的

etcd_imagedata_size このチェックは、etcd クラスターの OpenShiftContainer Platform イメージデータの合計サイズを測定します。このチェックは計算されたサイズがユーザー定義の制限を超える場合に失敗します。制限が指定されない場合、このチェックはイメージデータのサイズが etcd クラスターで現在使用されている領域の 50 % 以上になる場合に失敗します。

このチェックに失敗することは、etcd の多くの領域が OpenShift Container Platform イメージデータによって使用されていることを示し、これにより、最終的には etcd クラスターがクラッシュする可能性があります。

ユーザー定義の制限は etcd_max_image_data_size_bytes 変数を渡すことで設定できます。たとえば、etcd_max_image_data_size_bytes=40000000000 を設定する場合、etcd に保存されるイメージデータの合計サイズが 40 GB を超えるとチェックが失敗します。


364

etcd_traffic このチェックは、etcd ホストの通常よりも高いレベルのトラフィックを検知します。etcd 期間の警告と共に journalctl ログエントリーが見つかる場合に失敗します。

etcd パフォーマンスを強化する方法についての詳細は、「Recommended Practices for OpenShiftContainer Platform etcd Hosts」および Red Hat ナレッジベースを参照してください。

etcd_volume このチェックにより、etcd クラスターのボリューム使用がユーザー指定の最大しきい値を超えないようにできます。最大しきい値が指定されていない場合、デフォルトは合計ボリュームサイズの 90% に設定されます。

ユーザー定義の制限は、etcd_device_usage_threshold_percent 変数を渡すことで設定できます。

docker_storage docker デーモン (ノードおよびコンテナー化されたインストール) に依存するホストでのみ実行されます。docker の合計使用量がユーザー定義制限を超えないこと確認します。ユーザー定義の制限が設定されていない場合、docker 使用量の最大しきい値のデフォルトは利用可能な合計サイズの 90% になります。

合計パーセントの使用量についてのしきい値の制限は、max_thinpool_data_usage_percent=90 などのようにインベントリーファイルの変数で設定できます。

また、このチェックは docker のストレージがサポートされる設定を使用していることを確認します。

curator、elasticsearch、fluentd、kibana この一連のチェックは、Curator、Kibana、Elasticsearch、および Fluentd Pod がデプロイされており、これらが running 状態であることを検証し、接続を制御ホストと公開される Kibana URL 間で確立できることを検証します。これらのチェックは、openshift_logging_install_logging インベントリー変数が true に設定されている場合にのみ実行され、それらがクラスターロギングが有効にされているデプロイメントで実行されるようにします。



365

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/scaling_and_performance_guide/#scaling-performance-capacity-host-practices-etcd


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/scaling_and_performance_guide/#choosing-a-graph-driver

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-aggregate-logging

logging_index_time このチェックは、ロギングスタックデプロイメントにおけるログ作成から Elasticsearch によるログ集計までの通常の時間差よりも値が高くなるケースを検知します。新規のログエントリーがタイムアウト内(デフォルトでは 30 秒内) に Elasticserach によってクエリーされない場合に失敗します。このチェックはロギングが有効にされている場合にのみ実行されます。

ユーザー定義のタイムアウトは、openshift_check_logging_index_timeout_seconds 変数を渡すことで設定できます。たとえば、openshift_check_logging_index_timeout_seconds=45 を設定すると、新規作成されるログエントリーが 45 秒を経過しても Elasticsearch でクエリーされない場合に失敗します。

sdn このチェックは、OpenShift Container PlatformSDN の以下のクラスターレベルの診断を実行します。

マスターホストが kubelets に接続できることを検証します。

ノードがパケットを相互にルート指定できることを検証します。

ノードアドレスを検証します。

HostSubnet オブジェクトを検証します。

openshift_checks_output_dir 変数を ansible-playbook コマンドで指定する場合、このチェックにより、OpenShift Container Platform API からのネットワーク関連のオブジェクトが、指定されるディレクトリーにあるログ、OVS フロー、iptablesルールその他のネットワーク設定情報と共に保存されます。変数の設定方法については、以下の ansible-playbook コマンドの使用例を参照してください。

このチェックは、oc adm diagnostics コマンドが診断 Pod をスケジュールできないか、または診断Pod が問題のトラブルシューティングに必要な情報を十分に提供しない場合の Pod またはインフラストラクチャーの問題を診断するのに役立ちます。


注記注記

インストールプロセスの一部として実行されることが意図されている同様のチェックセットについては、「Configuring Cluster Pre-install Checks」を参照してください。証明書の有効期限をチェックするための別のチェックのセットについては、「RedeployingCertificates」を参照してください。


366

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/installing_clusters/#configuring-cluster-pre-install-checks

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-redeploying-certificates

1

2

3

40.5.1. ansible-playbook によるヘルスチェックの実行

ansible-playbook コマンドを使用して openshift-ansible のヘルスチェックを実行するには、Playbook ディレクトリーに切り替え、クラスターのインベントリーファイルを指定し、health.ymlPlaybook を実行します。

$ cd /usr/share/ansible/openshift-ansible$ ansible-playbook -i <inventory_file> \ playbooks/openshift-checks/health.yml

コマンドラインに変数を設定するには、key=value 形式の必要な変数に -e フラグを組み込みます。以下は例になります。

$ cd /usr/share/ansible/openshift-ansible$ ansible-playbook -i <inventory_file> \ playbooks/openshift-checks/health.yml \ -e openshift_check_logging_index_timeout_seconds=45 \ -e etcd_max_image_data_size_bytes=40000000000

特定のチェックを無効にするには、Playbook を実行する前にインベントリーファイルのカンマ区切りのチェック名の一覧と共に変数 openshift_disable_check を組み込みます。以下は例になります。

openshift_disable_check=etcd_traffic,etcd_volume

または、ansible-playbook コマンドの実行時に -e openshift_disable_check=<check1>,<check2> で変数として無効にするチェックを設定します。

40.5.2. Docker CLI でのヘルスチェックの実行

コンテナーで openshift-ansible Playbook を実行し、Docker CLI で ose-ansible イメージを実行できるホストでの Ansible のインストールおよび設定の手間を省くことができます。

以下を、コンテナーを実行する権限を持つ root 以外のユーザーとして実行します。

# docker run -u `id -u` \ 1 -v $HOME/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Z,ro \ 2 -v /etc/ansible/hosts:/tmp/inventory:ro \ 3 -e INVENTORY_FILE=/tmp/inventory \ -e PLAYBOOK_FILE=playbooks/openshift-checks/health.yml \ 4 -e OPTS="-v -e openshift_check_logging_index_timeout_seconds=45 -e etcd_max_image_data_size_bytes=40000000000" \ 5 openshift3/ose-ansible

これらのオプションにより、コンテナーは現行ユーザーと同じ UID で実行されます。これは SSHキーをコンテナー内で読み取られるようにするようにパーミッションで必要になります (SSH プライベートキーはその所有者によってのみ読み取り可能であることが予想されます)。

SSH キーは、コンテナーを非 root ユーザーとして実行するなどの通常の使用では /opt/app-root/src/.ssh の下にマウントします。

/etc/ansible/hosts は、異なる場合はクラスターのインベントリーファイルの場所に切り替えます。このファイルは、コンテナーの INVENTORY_FILE 環境変数に基づいて使用される/tmp/inventory にバインドおよびマウントされます。


367

4

5

PLAYBOOK_FILE 環境変数は、コンテナー内の /usr/share/ansible/openshift-ansible に関連して health.yml playbook の場所に設定されます。

-e key=value 形式で単一の実行に必要な変数を設定します。

上記のコマンドでは、SSH キーは :Z オプションを使ってマウントされ、コンテナーが SSH キーを制限付き SELinux コンテキストから読み取れるようにします。このオプションを追加することは、元のSSH キーファイルのラベルが system_u:object_r:container_file_t:s0:c113,c247 などに変更されることを意味しています。:Z についての詳細は、docker-run(1) man ページを参照してください。

重要重要

これらのボリュームマウント仕様に関連して予期しない影響が生じる可能性があります。たとえば、$HOME/.ssh ディレクトリーをマウント (したがってラベルを変更) する場合、sshd はパブリックキーにアクセスしてリモートログインを許可できなくなります。元のファイルラベルの変更を防ぐには、SSH キー (またはディレクトリー) のコピーをマウントします。

.ssh ディレクトリー全体をマウントすることは、以下に役立ちます。

キーをホストに一致させたり、他の接続パラメーターを変更したりするために SSH 設定を使用することを許可します。

ユーザーが known_hosts ファイルを指定し、SSH でホストキーを検証することを許可します。これはデフォルトの設定では無効にされていますが、-e ANSIBLE_HOST_KEY_CHECKING=True を docker コマンドラインに追加することにより、環境変数を使用してこれを再度有効にできます。


368

第41章アプリケーションのアイドリング

41.1. 概要

OpenShift Container Platform 管理者は、アプリケーションをアイドリング状態にしてリソース消費を減らすことができます。これは、コストがリソース消費と関連付けられるパブリッククラウドにデプロイされている場合に役立ちます。

スケーラブルなリソースが使用されていない場合、OpenShift Container Platform はリソースを検出した後にそれらを 0 レプリカに設定してアイドリングします。ネットワークトラフィックがリソースに送信される場合、レプリカをスケールアップしてアイドリング解除を実行し、操作を続行します。

アプリケーションは複数のサービスやデプロイメント設定などの他のスケーラブルななリソースで構成されています。アプリケーションのアイドリングには、関連するすべてのリソースのアイドリングを実行することが関係します。

41.2. アプリケーションのアイドリング

アプリケーションのアイドリングには、サービスに関連付けられたスケーラブルなリソース (デプロイメント設定、レプリケーションコントローラーなど) を検索することが必要です。アプリケーションのアイドルリングには、サービスを検索してこれをアイドリング状態としてマークし、リソースを zeroレプリカにスケールダウンすることが関係します。

oc idle コマンドを実行して単一サービスのアイドリングを実行するか、または --resource-names-fileオプションを使用して複数サービスのアイドリングを実行できます。

41.2.1. 単一サービスのアイドリング

以下のコマンドを使用して単一サービスをアイドリングします。

$ oc idle <service>

41.2.2. 複数サービスのアイドリング

必要なサービスの一覧を作成し、--resource-names-file オプションを oc idle コマンドで使用することで複数サービスをアイドリングします。

これは、アプリケーションがプロジェクト内の一連のサービスにまたがる場合や、同じプロジェクト内で複数のアプリケーションを一括してアイドリングするため、複数サービスをスクリプトを併用してアイドリングする場合に役立ちます。

1. 複数サービスの一覧を含むテキストファイルを作成します (それぞれを各行に指定)。

2. --resource-names-file オプションを使用してサービスをアイドリングします。

$ oc idle --resource-names-file <filename>

注記注記

idle コマンドは単一プロジェクトに制限されます。クラスター全体でアプリケーションをアイドリングするには、各プロジェクトに対して idle コマンドをそれぞれ実行します。

第第41章章アプリケーションのアイドリングアプリケーションのアイドリング

369

41.3. アプリケーションのアイドリング解除

アプリケーションサービスは、ネットワークトラフィックを受信し、直前の状態に再びスケールアップすると再びアクティブになります。これには、サービスへのトラフィックとルートを通るトラフィックの両方が含まれます。

アプリケーションのアイドリング解除はリソースをスケールアップすることで手動で実行できます。たとえば、deploymentconfig をスケールアップするには、以下のコマンドを実行します。

$ oc scale --replicas=1 dc <deploymentconfig>

注記注記

現時点で、ルーターによる自動アイドルリング解除はデフォルトの HAProxy ルーターのみでサポートされています。


370

第42章クラスター容量の分析

42.1. 概要

クラスター管理者は、hypercc cluster-capacity ツールを使用して、現在のリソースが使い切られる前にそれらを増やすべくスケジュール可能な Pod 数を表示し、Pod を今後スケジュールできるようにすることができます。この容量は、クラスター内の個別ノードからのものを集めたものであり、これにはCPU、メモリー、ディスク領域などが含まれます。

hypercc cluster-capacity ツールはより正確な見積もりを出すべく、スケジュールの一連の意思決定をシミュレーションし、リソースが使い切られる前にクラスターでスケジュールできる入力 Pod のインスタンス数を判別します。

注記注記

ノード間に分散しているすべてのリソースがカウントされないため、残りの割り当て可能な容量は概算となります。残りのリソースのみが分析対象となり、クラスターでのスケジュール可能な所定要件を持つ Pod のインスタンス数という点から消費可能な容量を見積もります。

Pod のスケジューリングはその選択およびアフィニティー条件に基づいて特定のノードセットについてのみサポートされる可能性があります。そのため、クラスターでスケジュール可能な残りの Pod 数を見積もることが困難になる場合があります。

hypercc cluster-capacity 分析ツールは、コマンドラインからスタンドアロンのユーティリティーとして実行することも、OpenShift Container Platform クラスター内の Pod でジョブとして実行することもできます。これを Pod 内のジョブとして実行すると、介入なしに複数回実行することができます。

42.2. コマンドラインでのクラスター容量分析の実行

openshift-enterprise-cluster-capacity RPM パッケージをインストールして、このツールを取得します。ツールをコマンドラインで実行するには、以下を実行します。

$ hypercc cluster-capacity --kubeconfig <path-to-kubeconfig> \ --podspec <path-to-pod-spec>

--kubeconfig オプションは Kubernetes 設定ファイルを示し、 --podspec オプションはツールがリソース使用状況を見積もるために使用するサンプル Pod 仕様ファイルを示します。podspec はそのリソース要件を limits または requests として指定します。hypercc cluster-capacity ツールは、Pod のリソース要件をその見積もりの分析に反映します。

Pod 仕様入力の例は以下の通りです。

apiVersion: v1kind: Podmetadata: name: small-pod labels: app: guestbook tier: frontendspec: containers: - name: php-redis

第第42章章クラスター容量の分析クラスター容量の分析

371

--verbose オプションを追加して、クラスター内の各ノードにスケジュールできる Pod 数についての詳細説明を出力できます。

$ hypercc cluster-capacity --kubeconfig <path-to-kubeconfig> \ --podspec <path-to-pod-spec> --verbose

出力は以下のようになります。

small-pod pod requirements: - CPU: 150m - Memory: 100Mi

The cluster can schedule 52 instance(s) of the pod small-pod.

Termination reason: Unschedulable: No nodes are available that match all of thefollowing predicates:: Insufficient cpu (2).

Pod distribution among nodes:small-pod - 192.168.124.214: 26 instance(s) - 192.168.124.120: 26 instance(s)

上記の例では、クラスターにスケジュールできる Pod の見積り数は 52 です。

42.3. POD 内のジョブとしてのクラスター容量分析の実行

クラスター容量ツールを Pod 内のジョブとして実行すると、ユーザーの介入なしに複数回実行できるという利点があります。クラスター容量ツールをジョブとして実行するには、ConfigMap を使用する必要があります。

1. クラスターロールを作成します。

$ cat << EOF| oc create -f -kind: ClusterRoleapiVersion: v1metadata: name: cluster-capacity-rolerules:- apiGroups: [""] resources: ["pods", "nodes", "persistentvolumeclaims", "persistentvolumes", "services"] verbs: ["get", "watch", "list"]EOF

2. サービスアカウントを作成します。

image: gcr.io/google-samples/gb-frontend:v4 imagePullPolicy: Always resources: limits: cpu: 150m memory: 100Mi requests: cpu: 150m memory: 100Mi


372

1

$ oc create sa cluster-capacity-sa

3. ロールをサービスアカウントに追加します。

$ oc adm policy add-cluster-role-to-user cluster-capacity-role \ system:serviceaccount:default:cluster-capacity-sa 1

サービスアカウントが default プロジェクトにない場合は、default をプロジェクト名に置き換えます。

4. Pod 仕様を定義し、作成します。

5. クラスター容量分析は、cluster-capacity-configmap という名前の ConfigMap を使用してボリュームにマウントされ、入力 Pod 仕様ファイル pod.yaml はパス /test-pod のボリューム test-volume にマウントされます。ConfigMap を作成していない場合は、ジョブの作成前にこれを作成します。

$ oc create configmap cluster-capacity-configmap \ --from-file=pod.yaml

6. ジョブ仕様ファイルの以下のサンプルを使用してジョブを作成します。

apiVersion: v1kind: Podmetadata: name: small-pod labels: app: guestbook tier: frontendspec: containers: - name: php-redis image: gcr.io/google-samples/gb-frontend:v4 imagePullPolicy: Always resources: limits: cpu: 150m memory: 100Mi requests: cpu: 150m memory: 100Mi

apiVersion: batch/v1kind: Jobmetadata: name: cluster-capacity-jobspec: parallelism: 1 completions: 1 template: metadata: name: cluster-capacity-pod spec:

第第42章章クラスター容量の分析クラスター容量の分析

373

1 クラスター容量ツールにクラスター内で Pod として実行されていることを認識させる環境変数です。ConfigMap の pod.yaml キーは Pod 仕様ファイル名と同じですが、これは必須ではありません。これを実行することで、入力 Pod 仕様ファイルは /test-pod/pod.yaml としてPod 内でアクセスできます。

7. クラスター容量イメージを Pod のジョブとして実行します。

$ oc create -f cluster-capacity-job.yaml

8. ジョブログを確認し、クラスター内でスケジュールできる Pod の数を確認します。

$ oc logs jobs/cluster-capacity-jobsmall-pod pod requirements: - CPU: 150m - Memory: 100Mi

The cluster can schedule 52 instance(s) of the pod small-pod.

Termination reason: Unschedulable: No nodes are available that match all of thefollowing predicates:: Insufficient cpu (2).

Pod distribution among nodes:small-pod - 192.168.124.214: 26 instance(s) - 192.168.124.120: 26 instance(s)

containers: - name: cluster-capacity image: registry.redhat.io/openshift3/ose-cluster-capacity imagePullPolicy: "Always" volumeMounts: - mountPath: /test-pod name: test-volume env: - name: CC_INCLUSTER 1 value: "true" command: - "/bin/sh" - "-ec" - | /bin/cluster-capacity --podspec=/test-pod/pod.yaml --verbose restartPolicy: "Never" serviceAccountName: cluster-capacity-sa volumes: - name: test-volume configMap: name: cluster-capacity-configmap


374

第43章 AWS でのクラスターの自動スケーラーの設定Amazon Web Services (AWS) の OpenShift Container Platform クラスターで自動スケーラーを設定すると、アプリケーションのワークロードに対して弾力性を確保できます。自動スケーラーは Pod の実行にあたって十分な数のノードがアクティブであり、アクティブなノードの数が現在のデマンドに対応することを確認します。

注記注記

自動スケーラーは AWS でのみ実行できます。

43.1. OPENSHIFT CONTAINER PLATFORM 自動スケーラーについて

OpenShift Container Platform の自動スケーラーは、ノードの割り当てを保留にしている Pod 数を確認するために繰り返しチェックを実行します。Pod が割り当てを保留にしていて、自動スケーラーがその最大容量を達していない場合、現在の需要に対応するために新規ノードが継続的にプロビジョニングされます。需要が下がり、必要なノードが少なくなると、自動スケーラーは使用されていないノードを削除します。自動スケーラーをインストールした後に、その動作は自動化されます。そのため、必要な数のレプリカをデプロイメントに追加することのみが必要になります。

OpenShift Container Platform バージョン 3.11 では、自動スケーラーを Amazon Web Services (AWS) のみにデプロイできます。自動スケーラーは、自動スケーリンググループおよび起動設定などの一部の標準的な AWS オブジェクトを使用してクラスターのサイズを管理します。

自動スケーラーは以下のアセットを使用します。

自動スケーリンググループ

自動スケーリンググループはマシンセットの論理表現です。自動スケーリンググループは、実行する最小数のインスタンス、実行可能な最大数のインスタンスおよび、実行する必要のあるインスタンス数で設定します。必要な容量に対応するのに必要な数のインスタンスを起動すると、自動スケーリンググループが起動します。自動スケーリンググループは、インスタンスがゼロの状態で起動するように設定できます。

起動設定

起動設定は、インスタンスを起動するために自動スケーリングが使用するテンプレートです。起動設定を作成する際に、以下のような情報を指定します。

ベースイメージを使用するための Amazon Machine Image (AMI) の ID

m4.large などのインスタンスタイプ

キーペア

1 つ以上のセキュリティーグループ

起動設定を適用するサブネット

OpenShift Container Platform Primed イメージ

自動スケーリンググループが新規インスタンスのプロビジョニングを実行する場合、それが起動するイメージに OpenShift Container Platform が準備されている必要があります。自動スケーリンググループはこのイメージを使用して、手動の介入なしにノードのブートストラップおよびクラスター内での登録を自動的に実行します。

43.2. PRIMED イメージの作成

第第43章章 AWS でのクラスターの自動スケーラーの設定でのクラスターの自動スケーラーの設定

375

1

2

3

自動スケーラーが使用する Primed イメージを自動的に作成するように Ansible Playbook を使用できます。既存の Amazon Web Services (AWS) クラスターの属性を指定する必要があります。

注記注記

すでに Primed イメージがある場合、新規のイメージを作成せずにこれを使用できます。

手順手順

OpenShift Container Platform クラスターを作成するために使用したホストで、Primed イメージを作成します。

1. ローカルホストに新しい Ansible インベントリーファイルを作成します。このファイルには、参加するノードで自動スケーリングを有効にするために cloudprovider フラグを割り当てる変数が必要です。これらの変数がないと、build_ami.yml Playbook はopenshift_cloud_providerロールを使用できません。

[OSEv3:children]mastersnodesetcd

[OSEv3:vars]openshift_deployment_type=openshift-enterpriseansible_ssh_user=ec2-useropenshift_clusterid=myclusteransible_become=yesopenshift_cloudprovider_kind=aws 1openshift_cloudprovider_aws_access_key=<aws_access_key> 2openshift_cloudprovider_aws_secret_key=<aws_secret_key> 3

[masters][etcd][nodes]

クラウドプロバイダーのタイプを指定します。

クラウドプロバイダーの Identity and Access Management (IAM) アクセスキーを提供します。

クラウドが提供する IAM シークレットキーを提供します。

2. ローカルホストにプロビジョニングファイル build-ami-provisioning-vars.yaml を作成します。

openshift_deployment_type: openshift-enterprise

openshift_aws_clusterid: mycluster 1

openshift_aws_region: us-east-1 2

openshift_aws_create_vpc: false 3

openshift_aws_vpc_name: production 4


376

1

2

3

4

5

6

7

8

9

既存クラスターの名前を指定します。

既存クラスターが現在実行されているリージョンを指定します。

False を指定して VPC の作成を無効にします。

クラスターが実行されている既存の VPC 名を指定します。

既存のクラスターが実行されているサブネットの名前を指定します。

セキュリティーグループの作成を無効にするために False を指定します。

SSH アクセスに使用する AWS キー名を指定します。

Primed イメージのベースイメージとして使用する AMI イメージ ID を指定します。RedHat® Cloud Access を参照してください。

S3 バケットの作成を無効にするために False を指定します。

openshift_aws_subnet_az: us-east-1d 5

openshift_aws_create_security_groups: false 6

openshift_aws_ssh_key_name: production-ssh-key 7

openshift_aws_base_ami: ami-12345678 8

openshift_aws_create_s3: False 9

openshift_aws_build_ami_group: default 10

openshift_aws_vpc: 11 name: "{{ openshift_aws_vpc_name }}" cidr: 172.18.0.0/16 subnets: us-east-1: - cidr: 172.18.0.0/20 az: "us-east-1d"

container_runtime_docker_storage_type: overlay2 12container_runtime_docker_storage_setup_device: /dev/xvdb 13

# atomic-openshift-node service requires gquota to be set on the# filesystem that hosts /var/lib/origin/openshift.local.volumes (OCP# emptydir). Often is it not ideal or cost effective to deploy a vol# for emptydir. This pushes emptydir up to the / filesystem. Base ami# often does not ship with gquota enabled for /. Set this bool true to# enable gquota on / filesystem when using Red Hat Cloud Access RHEL7# AMI or Amazon Market RHEL7 AMI.openshift_aws_ami_build_set_gquota_on_slashfs: true 14

rhsub_user: [email protected] 15rhsub_pass: password 16rhsub_pool: pool-id 17


377

https://www.redhat.com/en/technologies/cloud-computing/cloud-access

10

11

12

13

14

15

16

17

セキュリティーグループ名を指定します。

既存クラスターが実行されている VPC サブネットを指定します。

overlay2 を Docker ストレージタイプとして指定します。

LVM および /var/lib/docker ディレクトリーのマウントポイントを指定します。

Red Hat Cloud を使用する場合、このパラメーターの値を true に設定して、ファイルシステムで gquota を有効にします。

アクティブな OpenShift Container Platform サブスクリプションのある Red Hat アカウントのメールアドレスを指定します。

Red Hat アカウントのパスワードを指定します。

OpenShift Container Platform サブスクリプションのプール ID を指定します。クラスター作成時に使用したのと同じプール ID を使用できます。

3. build_ami.yml Paybook を実行して Primed イメージを生成します。

# ansible-playbook -i </path/to/inventory/file> \ /usr/openshift-ansible/playbooks/aws/openshift-cluster/build_ami.yml \ -e @build-ami-provisioning-vars.yaml

Playbook の実行後に、新規のイメージ ID または AMI が出力に表示されます。起動設定の作成時に生成した AMI を指定します。

43.3. 起動設定および自動スケーリンググループの作成

クラスターの自動スケーラーをデプロイする前に、Primed イメージを参照する Amazon Web Services(AWS) 起動設定および自動スケーリンググループを作成する必要があります。新規ノードが起動時に既存クラスターに自動的に参加するように起動設定を設定する必要があります。

前提条件

AWS に OpenShift Container Platform クラスターをインストールします。

Primed イメージを作成します。

EFK スタックをクラスターにデプロイしている場合は、ノードラベルを logging-infra-fluentd=true に設定します。

手順

1. bootstrap.kubeconfig ファイルをマスターノードから生成し、これを作成します。

2. user-data.txt cloud-init ファイルを bootstrap.kubeconfig ファイルから作成します。

$ ssh master "sudo oc serviceaccounts create-kubeconfig -n openshift-infra node-bootstrapper" > ~/bootstrap.kubeconfig

$ cat <<EOF > user-data.txt#cloud-config


378

1

2

3

4

5

6

7

3. 起動設定テンプレートを AWS S3 バケットにアップロードします。

4. AWS CLI を使用して起動設定を作成します。

起動設定名を指定します。

イメージを起動するリージョンを指定します。

作成した Primed イメージ AMI を指定します。

起動するインスタンスのタイプを指定します。

起動したイメージに割り当てるセキュリティーグループを指定します。

アップロードした起動設定テンプレートを指定します。

SSH キーペアの名前を指定します。

注記注記

テンプレートをエンコードする前に 16 KB 未満の場合は、AWS CLI を使用し、--template-url と --user-data を置き換えてテンプレートを指定できます。

write_files:- path: /root/openshift_bootstrap/openshift_settings.yaml owner: 'root:root' permissions: '0640' content: | openshift_node_config_name: node-config-compute- path: /etc/origin/node/bootstrap.kubeconfig owner: 'root:root' permissions: '0640' encoding: b64 content: | $(base64 ~/bootstrap.kubeconfig | sed '2,$s/^/ /')

runcmd:- [ ansible-playbook, /root/openshift_bootstrap/bootstrap.yml]- [ systemctl, restart, systemd-hostnamed]- [ systemctl, restart, NetworkManager]- [ systemctl, enable, atomic-openshift-node]- [ systemctl, start, atomic-openshift-node]EOF

$ aws autoscaling create-launch-configuration \ --launch-configuration-name mycluster-LC \ 1 --region us-east-1 \ 2 --image-id ami-987654321 \ 3 --instance-type m4.large \ 4 --security-groups sg-12345678 \ 5 --template-url https://s3-.amazonaws.com/.../yourtemplate.json \ 6 --key-name production-key \ 7


379

1

2

3

4

5

6

5. AWS CLI を使用して自動スケーリンググループを作成します。

自動スケーラーデプロイメントのデプロイ時に使用する自動スケーリンググループの名前を指定します。

作成した起動設定の名前を指定します。

自動スケーラーが維持するノードの最小数を指定します。1 つ以上のノードが必要です。

スケールグループが拡張できるノードの最大数を指定します。

クラスターが使用するのと同じサブネットの VPC サブネット ID を指定します。

自動スケーリンググループタグが起動時のノードに伝播されるように文字列を指定します。

43.4. クラスターへの自動スケーラーコンポーネントのデプロイ

起動設定および自動スケーリンググループの作成後に、自動スケーラーコンポーネントをクラスターにデプロイできます。

前提条件

AWS で OpenShift Container Platform クラスターをインストールします。

Primed イメージを作成します。

Primed イメージを参照する起動設定および自動スケーリンググループを作成します。

手順手順

自動スケーラーをデプロイするには、以下を実行します。

1. 自動スケーラーを実行するためにクラスターを更新します。

a. クラスターを作成するために使用したインベントリーファイルに以下のパラメーターを追加します。デフォルトは /etc/ansible/hosts です。

openshift_master_bootstrap_auto_approve=true

b. 自動スケーラーを取得するには、Playbook ディレクトリーに切り替えてから Playbook を

$ aws autoscaling create-auto-scaling-group \ --auto-scaling-group-name mycluster-ASG \ 1 --launch-configuration-name mycluster-LC \ 2 --min-size 1 \ 3 --max-size 6 \ 4 --vpc-zone-identifier subnet-12345678 \ 5 --tags ResourceId=mycluster-ASG,ResourceType=auto-scaling-group,Key=Name,Value=mycluster-ASG-node,PropagateAtLaunch=true ResourceId=mycluster-ASG,ResourceType=auto-scaling-group,Key=kubernetes.io/cluster/mycluster,Value=true,PropagateAtLaunch=true ResourceId=mycluster-ASG,ResourceType=auto-scaling-group,Key=k8s.io/cluster-autoscaler/node-template/label/node-role.kubernetes.io/compute,Value=true,PropagateAtLaunch=true 6


380

b. 自動スケーラーを取得するには、Playbook ディレクトリーに切り替えてから Playbook を再度実行します。

$ cd /usr/share/ansible/openshift-ansible$ ansible-playbook -i </path/to/inventory/file> \ playbooks/deploy_cluster.yml

c. bootstrap-autoapprover Pod が実行中であることを確認します。

$ oc get pods --all-namespaces | grep bootstrap-autoapproverNAMESPACE NAME READY STATUS RESTARTS AGEopenshift-infra bootstrap-autoapprover-0 1/1 Running 0

2. 自動スケーラーの namespace を作成します。

3. 自動スケーラーのサービスアカウントを作成します。

4. 必要なパーミッションをサービスアカウントに付与するためのクラスターロールを作成します。

$ oc apply -f - <<EOFapiVersion: v1kind: Namespacemetadata: name: cluster-autoscaler annotations: openshift.io/node-selector: ""EOF

$ oc apply -f - <<EOFapiVersion: v1kind: ServiceAccountmetadata: labels: k8s-addon: cluster-autoscaler.addons.k8s.io k8s-app: cluster-autoscaler name: cluster-autoscaler namespace: cluster-autoscalerEOF

$ oc apply -n cluster-autoscaler -f - <<EOFapiVersion: v1kind: ClusterRolemetadata: name: cluster-autoscalerrules:- apiGroups: 1 - "" resources: - pods/eviction verbs: - create attributeRestrictions: null


381

- apiGroups: - "" resources: - persistentvolumeclaims - persistentvolumes - pods - replicationcontrollers - services verbs: - get - list - watch attributeRestrictions: null- apiGroups: - "" resources: - events verbs: - get - list - watch - patch - create attributeRestrictions: null- apiGroups: - "" resources: - nodes verbs: - get - list - watch - patch - update attributeRestrictions: null- apiGroups: - extensions - apps resources: - daemonsets - replicasets - statefulsets verbs: - get - list - watch attributeRestrictions: null- apiGroups: - policy resources: - poddisruptionbudgets verbs: - get - list


382

1 cluster-autoscaler オブジェクトが存在する場合、 pods/eviction ルールが動詞 create と共に存在することを確認します。

5. デプロイメント自動スケーラーのロールを作成します。

6. creds ファイルを作成して自動スケーラーの AWS 認証情報を保存します。

自動スケーラーはこれらの認証情報を使用して新規インスタンスを起動します。

7. AWS 認証情報が含まれるシークレットを作成します。

- watch attributeRestrictions: nullEOF

$ oc apply -n cluster-autoscaler -f - <<EOFapiVersion: v1kind: Rolemetadata: name: cluster-autoscalerrules:- apiGroups: - "" resources: - configmaps resourceNames: - cluster-autoscaler - cluster-autoscaler-status verbs: - create - get - patch - update attributeRestrictions: null- apiGroups: - "" resources: - configmaps verbs: - create attributeRestrictions: null- apiGroups: - "" resources: - events verbs: - create attributeRestrictions: nullEOF

cat <<EOF > creds[default]aws_access_key_id = your-aws-access-key-idaws_secret_access_key = your-aws-secret-access-keyEOF


383

自動スケーラーはこのシークレットを使用して AWS 内でインスタンスを起動します。

8. cluster-reader ロールを作成し、これを作成した cluster-autoscaler サービスアカウントに付与します。

9. クラスターの自動スケーラーをデプロイします

$ oc create secret -n cluster-autoscaler generic autoscaler-credentials --from-file=creds

$ oc adm policy add-cluster-role-to-user cluster-autoscaler system:serviceaccount:cluster-autoscaler:cluster-autoscaler -n cluster-autoscaler

$ oc adm policy add-role-to-user cluster-autoscaler system:serviceaccount:cluster-autoscaler:cluster-autoscaler --role-namespace cluster-autoscaler -n cluster-autoscaler

$ oc adm policy add-cluster-role-to-user cluster-reader system:serviceaccount:cluster-autoscaler:cluster-autoscaler -n cluster-autoscaler

$ oc apply -n cluster-autoscaler -f - <<EOFapiVersion: apps/v1kind: Deploymentmetadata: labels: app: cluster-autoscaler name: cluster-autoscaler namespace: cluster-autoscalerspec: replicas: 1 selector: matchLabels: app: cluster-autoscaler role: infra template: metadata: labels: app: cluster-autoscaler role: infra spec: containers: - args: - /bin/cluster-autoscaler - --alsologtostderr - --v=4 - --skip-nodes-with-local-storage=False - --leader-elect-resource-lock=configmaps - --namespace=cluster-autoscaler - --cloud-provider=aws - --nodes=0:6:mycluster-ASG env: - name: AWS_REGION value: us-east-1 - name: AWS_SHARED_CREDENTIALS_FILE value: /var/run/secrets/aws-creds/creds image: registry.redhat.io/openshift3/ose-cluster-autoscaler:v3.11 name: autoscaler


384

43.5. 自動スケーラーのテスト

自動スケーラーを Amazon Web Services (AWS) クラスターに追加した後に、現在のノードが実行できる数よりも多くの Pod をデプロイすることにより自動スケーラーが機能することを確認できます。

前提条件

AWS で実行される OpenShift Container Platform クラスターに自動スケーラーが追加されていること。

手順

1. 自動スケーリングをテストするためのデプロイメント設定が含まれる scale-up.yaml ファイルを作成します。

volumeMounts: - mountPath: /var/run/secrets/aws-creds name: aws-creds readOnly: true dnsPolicy: ClusterFirst nodeSelector: node-role.kubernetes.io/infra: "true" serviceAccountName: cluster-autoscaler terminationGracePeriodSeconds: 30 volumes: - name: aws-creds secret: defaultMode: 420 secretName: autoscaler-credentialsEOF

apiVersion: apps/v1kind: Deploymentmetadata: name: scale-up labels: app: scale-upspec: replicas: 20 1 selector: matchLabels: app: scale-up template: metadata: labels: app: scale-up spec: containers: - name: origin-base image: openshift/origin-base resources: requests: memory: 2Gi command: - /bin/sh


385

1 このデプロイメントは 20 のレプリカを指定しますが、初期サイズのクラスターでは、コンピュートノードの数を増やさないとすべての Pod を実行できません。

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

3. 設定をデプロイします。

4. namespace の Pod を表示します。

a. namespace の実行中の Pod を表示します。

b. namespace の保留中の Pod を表示します。

これらの保留中の Pod は、クラスターの自動スケーラーが Pod の実行に使用する新規コンピュートノードを自動的にプロビジョニングするまで実行されません。ノードがクラスター内で Ready 状態になるまで数分の時間がかかる場合があります。

- "-c" - "echo 'this should be in the logs' && sleep 86400" terminationGracePeriodSeconds: 0

$ oc apply -f - <<EOFapiVersion: v1kind: Namespacemetadata: name: autoscaler-demoEOF

$ oc apply -n autoscaler-demo -f scale-up.yaml

$ oc get pods -n autoscaler-demo | grep Runningcluster-autoscaler-5485644d46-ggvn5 1/1 Running 0 1dscale-up-79684ff956-45sbg 1/1 Running 0 31sscale-up-79684ff956-4kzjv 1/1 Running 0 31sscale-up-79684ff956-859d2 1/1 Running 0 31sscale-up-79684ff956-h47gv 1/1 Running 0 31sscale-up-79684ff956-htjth 1/1 Running 0 31sscale-up-79684ff956-m996k 1/1 Running 0 31sscale-up-79684ff956-pvvrm 1/1 Running 0 31sscale-up-79684ff956-qs9pp 1/1 Running 0 31sscale-up-79684ff956-zwdpr 1/1 Running 0 31s

$ oc get pods -n autoscaler-demo | grep Pendingscale-up-79684ff956-5jdnj 0/1 Pending 0 40sscale-up-79684ff956-794d6 0/1 Pending 0 40sscale-up-79684ff956-7rlm2 0/1 Pending 0 40sscale-up-79684ff956-9m2jc 0/1 Pending 0 40sscale-up-79684ff956-9m5fn 0/1 Pending 0 40sscale-up-79684ff956-fr62m 0/1 Pending 0 40sscale-up-79684ff956-q255w 0/1 Pending 0 40sscale-up-79684ff956-qc2cn 0/1 Pending 0 40sscale-up-79684ff956-qjn7z 0/1 Pending 0 40sscale-up-79684ff956-tdmqt 0/1 Pending 0 40sscale-up-79684ff956-xnjhw 0/1 Pending 0 40s


386

5. 数分後に、新規ノードの準備ができているかどうかを確認するためにノードの一覧をチェックします。

6. 追加のノードの準備ができている場合、namespace で実行中の Pod を再度表示します。

$ oc get nodesNAME STATUS ROLES AGE VERSIONip-172-31-49-172.ec2.internal Ready infra 1d v1.11.0+d4cacc0ip-172-31-53-217.ec2.internal Ready compute 7m v1.11.0+d4cacc0ip-172-31-55-89.ec2.internal Ready compute 9h v1.11.0+d4cacc0ip-172-31-56-21.ec2.internal Ready compute 7m v1.11.0+d4cacc0ip-172-31-56-71.ec2.internal Ready compute 7m v1.11.0+d4cacc0ip-172-31-63-234.ec2.internal Ready master 1d v1.11.0+d4cacc0

$ oc get pods -n autoscaler-demoNAME READY STATUS RESTARTS AGEcluster-autoscaler-5485644d46-ggvn5 1/1 Running 0 1dscale-up-79684ff956-45sbg 1/1 Running 0 8mscale-up-79684ff956-4kzjv 1/1 Running 0 8mscale-up-79684ff956-5jdnj 1/1 Running 0 8mscale-up-79684ff956-794d6 1/1 Running 0 8mscale-up-79684ff956-7rlm2 1/1 Running 0 8mscale-up-79684ff956-859d2 1/1 Running 0 8mscale-up-79684ff956-9m2jc 1/1 Running 0 8mscale-up-79684ff956-9m5fn 1/1 Running 0 8mscale-up-79684ff956-fr62m 1/1 Running 0 8mscale-up-79684ff956-h47gv 1/1 Running 0 8mscale-up-79684ff956-htjth 1/1 Running 0 8mscale-up-79684ff956-m996k 1/1 Running 0 8mscale-up-79684ff956-pvvrm 1/1 Running 0 8mscale-up-79684ff956-q255w 1/1 Running 0 8mscale-up-79684ff956-qc2cn 1/1 Running 0 8mscale-up-79684ff956-qjn7z 1/1 Running 0 8mscale-up-79684ff956-qs9pp 1/1 Running 0 8mscale-up-79684ff956-tdmqt 1/1 Running 0 8mscale-up-79684ff956-xnjhw 1/1 Running 0 8mscale-up-79684ff956-zwdpr 1/1 Running 0 8m...


387

1 2

第44章機能ゲートの使用による各種機能の無効化管理者として、機能ゲートを使用して特定のノードまたはプラットフォーム全体に対して特定の機能をオフにすることができます。

たとえば、新規の機能を完全にテストできるテストクラスターで有効にした状態で、これらの機能を実稼働クラスターでオフにすることができます。

Web コンソールに表示される機能を無効にすると、その機能が表示される場合がありますが、オブジェクトは一覧表示されません。無効にされた機能に関連付けられたコマンドを使用しようとすると、OpenShift Container Platform はエラーを表示します。

注記注記

クラスター内のアプリケーションが依存する機能を無効にする場合、アプリケーションは無効にされた機能およびアプリケーションがその機能を使用する方法によっては適切に機能しなくなる場合があります。

機能ゲートは、ブロックする必要のある機能を記述したマスター設定ファイル(/etc/origin/master/master-config.yaml) およびノード設定ファイルで key=value のペアを使用します。

ノード設定ファイルを変更するには、ノード設定マップを必要に応じて更新します。node-config.yamlファイルは手動で変更しないようにしてください。

たとえば、以下のコードは Huge Page 機能をオフにします。

機能をオフにするキー/値のペア:

true: 指定された機能を有効にします。

false: 指定された機能を無効にします。

複数の機能ゲートを 1 つのコンマ区切りの行で指定します。

44.1. クラスターの各種機能の無効化

クラスター全体の機能をオフにするには、マスター設定ファイル (デフォルトは

kubernetesMasterConfig: apiServerArguments: feature-gates: - HugePages=false 1 ... controllerArguments: feature-gates: - HugePages=false 2

kubeletArguments: feature-gates: - RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true,ExpandPersistentVolumes=true,HugePages=false


388

クラスター全体の機能をオフにするには、マスター設定ファイル (デフォルトは/etc/origin/master/master-config.yaml) を編集します。

1. オフにする必要のある機能については、<feature_name>=false を apiServerArguments および controllerArguments の下に入力します。例:


2. 変更を有効にするために OpenShift Container Platform マスターサービスを再起動します。


無効にされた機能を再度有効にするには、マスター設定ファイルを編集して <feature_name>=false を削除し、マスターサービスを再起動します。

44.2. ノードの各種機能の無効化

ノードホストの機能をオフにするには、適切なノード設定マップを編集します。


1. オフにする必要のある機能については、<feature_name>=false を kubeletArguments の下に入力します。例:


kubernetesMasterConfig: apiServerArguments: feature-gates: - HugePages=false controllerArguments: feature-gates: - HugePages=false

kubernetesMasterConfig: apiServerArguments: feature-gates: - RotateKubeletClientCertificate=false,RotateKubeletServerCertificate=false,ExpandPersistentVolumes=true,HugePages=false controllerArguments: feature-gates: - RotateKubeletClientCertificate=false,RotateKubeletServerCertificate=false,ExpandPersistentVolumes=true,HugePages=false

kubeletArguments: feature-gates: - HugePages=false

第第44章章機能ゲートの使用による各種機能の無効化機能ゲートの使用による各種機能の無効化

389

2. 変更を有効するために OpenShift Container Platform サービスを再起動します。

# systemctl restart atomic-openshift-node.service

無効にされた機能を再度有効にするには、ノード設定ファイルを編集して <feature_name>=false を削除し、ノードサービスを再起動します。


44.2.1. 機能ゲートの一覧

以下の一覧を使用し、無効にする必要のある機能の名前を判別します。

機能ゲート機能ゲート説明説明

Accelerator Docker の使用時に Nvidia GPU サポートを有効にします。

AdvancedAuditing 高度な監査を有効にします。

APIListChunking API クライアントが LIST または GET リソースを APIサーバーからチャンクで取得できるようにします。

APIResponseCompression LIST または GET 要求の応答の圧縮を有効にします。

AppArmor Docker を使用する際に Linux ノードで AppArmorベースの必須noアクセス制御を有効にします。詳細は、Kubernetes AppArmor ドキュメントを参照してください。

BlockVolume Pod で raw ブロックデバイスの定義および消費を可能にします。詳細は、「Kubernetes Raw BlockVolume Support」を参照してください。

CPUManager コンテナーレベルの CPU アフィニティーサポートを有効にします。詳細は、「Using CPU Manager」を参照してください。

CRIContainerLogRotation CRI コンテナーランタイムのコンテナーログのローテーションを有効にします。

kubeletArguments: feature-gates: - RotateKubeletClientCertificate=false,RotateKubeletServerCertificate=false,ExpandPersistentVolumes=true,HugePages=false


390

https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#master-node-config-advanced-audit

https://kubernetes.io/docs/tutorials/clusters/apparmor/

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#raw-block-volume-support

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/scaling_and_performance_guide/#scaling-performance-using-cpu-manager

CSIPersistentVolume CSI (Container Storage Interface) と互換性のあるボリュームプラグインでプロビジョニングされるボリュームの検出およびモニターを有効にします。詳細は､「CSI Volume Plugins」(Kubernetes Design ドキュメント) を参照してください。

CustomPodDNS dnsConfig プロパティーを使用した Pod の DNS 設定のカスタマイズを有効にします。

CustomResourceSubresources CustomResourceDefinition で作成されたリソースで/status および /scale サブリソースを有効にします。「カスタムリソースによる Kubernetes API の拡張」を参照してください。

CustomResourceValidation カスタムリソース定義で作成されたリソースでスキーマベースの検証を有効にします。詳細は、「カスタムリソースによる Kubernetes API の拡張」を参照してください。

DebugContainers 実行中の Pod のトラブルシューティングのためにPod の namespace でのデバッグコンテナーの実行を有効にします。

DevicePlugins ノード上でデバイスプラグインベースのリソースのプロビジョニングを有効にします。

DynamicKubeletConfig クラスター内で動的な設定を有効にします。

DynamicVolumeProvisioning(deprecated) 永続ボリュームの Pod への動的プロビジョニングを有効にします。

EnableEquivalenceClassCache Pod のスケジュール時のスケジューラーによるノードの同等内容のキャッシュを有効にします。

ExperimentalCriticalPodAnnotation 特定の Pod に「Critical」のアノテーションを付け、それらのスケジューリングが保証されるようにします。

ExperimentalHostUserNamespaceDefaultingGate ユーザー namespace の無効化を可能にします。これは、権限の付けられた他のホストプロジェクト、ホストマウント、またはコンテナーを使用するか、または MKNODE、SYS_MODULE などの特定のプロジェクト以外の機能を使用するコンテナー用です。これは、ユーザープロジェクトの再マップが Dockerデーモンで有効にされる場合にのみ有効にされる必要があります。

GCERegionalPersistentDisk GCE 永続ディスク機能を有効にします。



391

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

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#using-device-plugins

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-persistent-storage-persistent-storage-gce

HugePages 事前に割り当てられた Huge Page の割り当ておよび消費を有効にします。

HyperVContainer Windows コンテナーの Hyper-V の分離を有効にします。

Intializers ビルトインの受付コントローラーの拡張として動的な受付制御を有効にします。

LocalStorageCapacityIsolation ローカルの一時ストレージの消費、および emptyDirボリュームの sizeLimit プロパティーを有効にします。

MountContainers ホストでのユーティリティーコンテナーのボリュームマウントとしての使用を有効にします。

MountPropagation 1 つのコンテナーでマウントされたボリュームの他のコンテナーまたは Pod との共有を有効にします。

PersistentLocalVolumes ローカルボリューム Pod の使用を有効にします。Pod のアフィニティーは、ローカルボリュームを要求する場合に指定される必要があります。

PodPriority 優先順位に基づく Pod の再スケジュール(Descheduling) およびプリエンプションを有効にします。

ReadOnlyAPIDataVolumes シークレット、ConfigMap、DownwardAPI、およびProjected ボリュームが読み取り専用モードでマウントされるように設定します。

ResourceLimitsPriorityFunction 最も低いスコアの 1 を、1 つ以上の入力 Pod CPU およびメモリー制限を満たすノードに割り当てるschedulerの優先度関数を有効にします。これは、同じスコアを持つノード間の関連性を切り離すことを目的としています。

RotateKubeletClientCertificate クラスター上でのクラスター TLS 証明書のローテーションを有効にします。

RotateKubeletServerCertificate クラスター上でのサーバー TLS 証明書のローテーションを有効にします。

RunAsGroup コンテナーの init プロセスのプライマリーグループID セットに対する制御を有効にします。



392

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/scaling_and_performance_guide/#scaling-performance-managing-huge-pages

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#architecture-additional-concepts-dynamic-admission-controllers

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-configuring-loca

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-secrets


https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-projected-volumes

ScheduleDaemonSetPods DaemonSet Pod を DaemonSet コントローラーではなくデフォルトスケジューラーでスケジュールされることを可能にします。

ServiceNodeExclusion クラウドプロバイダーで作成されたロードバランサーからのノードの除外を有効にします。

StorageObjectInUseProtection 永続ボリュームまたはPersistent Volume Claim (永続ボリューム要求、PVC) オブジェクトが依然として使用されている場合、これらの削除の延期を有効にします。

StreamingProxyRedirects API サーバーに対し、ストリーミング要求についてインターセプトおよびバックエンド kubelet からのリダイレクトをフォローするように指示します。

SupportIPVSProxyMode IP 仮想サーバーを使用したクラスター内のサービスの負荷分散を有効にします。

SupportPodPidsLimit Pod で実行されるプロセス数 (PID) を制限するサポートを有効にします。

TaintBasedEvictions ノードのテイントおよび Pod の容認に基づく Pod のノードからのエビクトを有効にします。

TaintNodesByCondition ノードの状態に基づく自動的なノードのテイントを有効にします。

TokenRequest サービスアカウントリソースで TokenRequest エンドポイントを有効にします。

VolumeScheduling ボリュームトポロジー対応のスケジューリングを有効にし、Persistent Volume Claim (永続ボリューム要求、PVC)のバインディングにスケジューリングの意思決定を認識させます。また、PersistentLocalVolumes 機能ゲートと使用される場合のローカルボリュームタイプの使用も有効にします。



393

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/developer_guide/#dev-guide-persistent-volumes

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#persistent-volume-claims

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/architecture/#persistent-volume-claims

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-configuring-loca

第45章 KURYR SDN の管理

45.1. 概要

Kuryr (または Kuryr-Kubernetes) は OpenShift Container Platform における SDN のオプションの 1 つです。Kuryr は OpenStack ネットワークサービスの Neutron を使用して Pod をネットワークに接続します。この方法で、Pod は OpenStack 仮想マシン (VM) との内部の接続を確保します。これは、OpenStack VM でデプロイされた OpenShift Container Platform クラスターに役立ちます。

45.1.1. 孤立した OpenStack リソース

Kuryr で作成されたすべての OpenStack リソースは、OpenShift Container Platform リソースのライフサイクルに関連付けられます。OpenStack VM などの Kuryr で作成されたリソースを手動で削除すると、OpenStack デプロイメントに孤立したリソースが生じる可能性があります。これには、Kury で使用されるように事前に作成された Neutron ポート、Octavia、ロードバランサー、ネットワーク、サブネット、およびセキュリティーグループが含まれますが、これらに制限されません。孤立したリソースは、kuryr.conf ファイル内にあるリソース ID を検索して適切に削除できます。または、Kuryr リソースが別の OpenStack ユーザーによって作成されている場合、ユーザーは関連付けられたユーザー名でOpenStack API をクエリーできます。


394

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-configuring-kuryr-sdn

openshift container platform 3.11 クラスター管理...3.5.2. etcd v3...

Documents