第5章マスターとノードの設定

openshift start コマンドおよびそのサブコマンド (マスターサーバーを起動するための master および node server を起動するための node) が受け取る引数のセット数は限定的ですが、これらは開発または実験環境でサーバーを起動するのには十分です。

ただしこれらの引数は、実稼働環境に必要な設定およびセキュリティーオプションのセットを詳細に記述し、管理するには不十分です。これらのオプションを指定するには、/etc/origin/master/master-config.yaml のマスターホストファイル、およびノード設定マップでこれらのオプションを指定する必要があります。

上記のファイルは、デフォルトプラグインの上書き、etcd への接続、サービスアカウントの自動作成、イメージ名の作成、プロジェクト要求のカスタマイズ、ボリュームプラグインの設定などの各種オプションを定義します。

このトピックでは、OpenShift Container Platform のマスターとノードのホストのカスタマイズに使用できるオプションについて説明し、インストール後に設定を変更する方法を紹介します。

これらのファイルはデフォルト値なしで完全に指定されます。したがって、空の値は、ユーザーがそのパラメーターを空の値で起動しようとしていることを意味します。これによりユーザーの設定を正確に推測することを簡単になりますが、指定する必要のあるすべてのオプションを思い出す必要があるという点では容易な作業にはなりません。これをより容易にするには、設定ファイルを --write-config オプションを使って作成し、次に --config オプションを指定して使用することができます。

5.1. インストールの依存関係

実稼働環境は、標準のクラスターインストールプロセスを使用してインストールする必要があります。実稼働環境では、高可用性 (HA) を維持するために複数のマスターを使用することが適しています。3 つのマスターで構成されるクラスターアーキテクチャーが推奨され、HAproxy の使用が推奨されるソリューションになります。

注意

etcd が マスターホストにインストールされている場合は、etcd は権限を持つマスターを判別できないために、クラスターを 3 つ以上のマスターを使用するように設定する必要があります。2 つのマスターのみを正常に実行できるのは、etcd をマスター以外のホストにインストールしている場合です。

5.2. マスターとノードの設定

マスターとノードの設定ファイルの設定に使用する方法は、OpenShift Container Platform クラスターのインストールに使用した方法と同じでなければなりません。標準のクラスターインストールプロセスに従う場合は、Ansible インベントリーファイルで設定の変更を加えます。

5.3. Ansible を使用した設定の変更

このセクションは、Ansible に精通していることを前提に説明を行います。

Ansible に公開されているのは、利用可能なホスト設定オプションの一部のみです。OpenShift Container Platform のインストール後、Ansible はインベントリーファイルを置き換えられた値で作成します。このインベントリーファイルを変更し、Ansible インストーラー Playbook を再実行することで、OpenShift Container Platform クラスターをカスタマイズできます。

OpenShift Container Platform は Ansible をクラスターインストールで使用することに対応していますが、Ansible Playbook とインベントリーファイルを使うことで、Puppet、Chef、Salt などの他の管理ツールを使用することもできます。

ユースケース: HTPasswd 認証を使用するようにクラスターを設定する

注記

このユースケースは、Playbook で参照されているすべてのノードに SSH キーがセットアップされていることを前提としています。
htpasswd ユーティリティーは httpd-tools パッケージにあります。
```
# yum install httpd-tools
```

Ansible インベントリーを変更し、設定の変更を行うには、以下を実行します。

./hosts インベントリーファイルを開きます。
新規の変数をファイルの [OSEv3:vars] セクションに追加します。
```
# htpasswd auth
openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]
# Defining htpasswd users
openshift_master_htpasswd_users={'<name>': '<hashed-password>', '<name>': '<hashed-password>'}
# or
#openshift_master_htpasswd_file=<path/to/local/pre-generated/htpasswdfile>
```
HTPasswd 認証では、指定されたユーザーとパスワードを作成する openshift_master_htpasswd_users 変数か、またはすでに作成済みのユーザーとパスワードを持つ事前生成されたフラットファイル (htpasswd ファイル) を指定する openshift_master_htpasswd_file 変数のいずれかを使用できます。
OpenShift Container Platform は、HTPasswd 認証を設定するためにハッシュ化されたパスワードを必要とします。以下のセクションに示されるように htpasswd コマンドを使用してユーザー用のハッシュ化されたパスワードを生成するか、またはユーザーおよび関連付けられたハッシュ化されたパスワードを持つフラットファイルを作成することができます。
以下の例では、認証方法をデフォルトの deny all 設定から htpasswd に変更し、指定されたファイルを使って jsmith および bloblaw ユーザーのユーザー ID とパスワードを生成します。
```
# htpasswd auth
openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]
# Defining htpasswd users
openshift_master_htpasswd_users={'jsmith': '$apr1$wIwXkFLI$bAygtKGmPOqaJftB', 'bloblaw': '7IRJ$2ODmeLoxf4I6sUEKfiA$2aDJqLJe'}
# or
#openshift_master_htpasswd_file=<path/to/local/pre-generated/htpasswdfile>
```
変更を有効にするために、Ansible Playbook を再実行します。
```
$ ansible-playbook -b -i ./hosts ~/src/openshift-ansible/playbooks/deploy_cluster.yml
```
Playbook が設定を更新し、OpenShift Container Platform マスターサービスを再起動して変更を適用します。

これで、Ansible を使用したマスターとノードの設定ファイルの変更が完了しました。ここまでは単純なユースケースですが、次は、どのマスターとノードの設定オプションが Ansibleに公開されているかを確認し、各自の Ansible インベントリーをカスタマイズします。

5.3.1. `htpasswd` コマンドの使用

OpenShift Container Platform クラスターを HTPasswd 認証を使用するように設定するには、ハッシュ化されたパスワードを持つ 1 名以上のユーザーをインベントリーファイルに追加する必要があります。

以下を実行することができます。

ユーザー名とパスワードを生成して ./hosts インベントリーファイルに直接追加する。
フラットファイルを作成して認証情報を ./hosts インベントリーファイルに渡す。

ユーザーおよびハッシュ化されたパスワードを作成するには、以下を実行します。

以下のコマンドを実行して指定されたユーザーを追加します。
```
$ htpasswd -n <user_name>
```
注記
-b オプションを追加すると、パスワードをコマンドラインに指定できます。
```
$ htpasswd -nb <user_name> <password>
```
ユーザーのクリアテキストのパスワードを入力し、確定します。
以下は例を示しています。
```
$ htpasswd -n myuser
New password:
Re-type new password:
myuser:$apr1$vdW.cI3j$WSKIOzUPs6Q
```
このコマンドはパスワードのハッシュ化バージョンを生成します。

これで、HTPasswd 認証を設定する際にハッシュ化パスワードを使用できます。ハッシュ化パスワードは、: の後に続く文字列です。上記の例では、次を入力します。

openshift_master_htpasswd_users={'myuser': '$apr1$wIwXkFLI$bAygtISk2eKGmqaJftB'}

ユーザー名とハッシュ化パスワードを持つフラットファイルを作成するには、以下を実行します。

以下のコマンドを実行します。
```
$ htpasswd -c </path/to/users.htpasswd> <user_name>
```
注記
-b オプションを追加すると、パスワードをコマンドラインに指定できます。
```
$ htpasswd -c -b <user_name> <password>
```
ユーザーのクリアテキストのパスワードを入力し、確定します。
以下は例を示しています。
```
htpasswd -c users.htpasswd user1
New password:
Re-type new password:
Adding password for user user1
```
このコマンドは、ユーザー名とユーザーパスワードのハッシュ化されたバージョンを含むファイルを生成します。

これで、HTPasswd 認証を設定する際にこのパスワードファイルを使用できます。

注記

htpasswd コマンドについての詳細は、「HTPasswd Identity Provider」を参照してください。

5.4. 手動による設定変更

ユースケース: HTPasswd 認証を使用するようにクラスターを設定する

設定ファイルを手動で変更するには、以下を実行します。

変更する必要のある設定ファイルを開きます。ここでは /etc/origin/master/master-config.yaml ファイルです。

以下の新規変数をファイルの identityProviders スタンザに追加します。

oauthConfig:
  ...
  identityProviders:
  - name: my_htpasswd_provider
    challenge: true
    login: true
    mappingMethod: claim
    provider:
      apiVersion: v1
      kind: HTPasswdPasswordIdentityProvider
      file: /path/to/users.htpasswd

変更を保存してファイルを閉じます。
変更を有効にするために、マスターを再起動します。
```
$ master-restart api
$ master-restart controllers
```

これでマスターとノードの設定ファイルが手動で変更されました。ここまでは単純なユースケースです。次は、すべてのマスターとノードの設定オプションを確認し、変更を加えることでクラスターをさらにカスタマイズします。

注記

クラスターのノードを変更するには、ノード設定マップを必要に応じて更新します。node-config.yaml ファイルは手動で変更しないようにしてください。

5.5. マスター設定ファイル

このセクションでは、master-config.yaml ファイルに記述されているパラメーターについて説明します。

新規のマスター設定ファイルを作成して、OpenShift Container Platform のインストール済みバージョンに有効なオプションを確認できます。

重要

master-config.yaml ファイルを変更する際には常にマスターを再起動して変更を有効にしてください。「OpenShift Container Platform サービスの再起動」を参照してください。

5.5.1. 受付制御の設定

表5.1 受付制御設定パラメーター

パラメーター名	説明
`AdmissionConfig`	受付制御プラグイン設定が含まれています。OpenShift Container Platform には、API オブジェクトが作成または変更されるたびにトリガーされる、受付制御プラグインの設定可能な一覧が含まれます。このオプションを使用して、一部のプラグインの無効化、他の設定の追加、順序の変更や設定の指定など、デフォルトのプラグイン一覧を上書きできます。プラグインの一覧とその設定はどちらも Ansible で制御することができます。
`APIServerArguments`	API サーバーのコマンドライン引数に一致する Kube API サーバーに直接渡されるキーと値のペアです。これらは移行されませんが、存在しない値が参照されてもサーバーは起動しません。これらの値は、`KubernetesMasterConfig` の他の設定を上書きする場合があり、これにより無効な設定が生じる可能性があります。`APIServerArguments` を `event-ttl` という値で使用し、イベントを etcd に保存します。デフォルトは `2h` ですが、メモリーの増加を防ぐためにより小さい値に設定することができます。 apiServerArguments: event-ttl: - "15m"
`ControllerArguments`	Kube コントローラーマネージャーのコマンドライン引数に一致する、コントローラーマネージャーに直接渡されるキーと値のペアです。これらは移行されませんが、存在しない値が参照されてもサーバーは起動しません。これらの値は、`KubernetesMasterConfig` の他の設定を上書きする場合があり、これにより無効な設定が生じる可能性があります。
`DefaultAdmissionConfig`	各種の受付プラグインの有効化または無効化に使用されます。このタイプが `pluginConfig` の下に configuration オブジェクトとして存在し、受付プラグインがこれをサポートしている場合、デフォルトでオフにされている受付プラグインが有効になります。
`PluginConfig`	設定ファイルを受付制御プラグインごとに指定することができます。
`PluginOrderOverride`	マスターにインストールされる受付制御プラグイン名の一覧です。順序には意味があります。空の場合は、プラグインのデフォルトの一覧が使用されます。
`SchedulerArguments`	スケジューラーのコマンドライン引数に一致する、Kube スケジューラーに直接渡されるキーと値のペアです。これらは移行されませんが、存在しない値が参照されてもサーバーは起動しません。これらの値は、`KubernetesMasterConfig` の他の設定を上書きする場合があり、これにより無効な設定が生じる可能性があります。

5.5.2. アセットの設定

表5.2 アセットの設定パラメーター

パラメーター名	説明
`AssetConfig`	これが存在する場合には、アセットサーバーは事前に定義されたパラメーターに基づいて起動します。以下は例になります。 assetConfig: logoutURL: "" masterPublicURL: https://master.ose32.example.com:8443 publicURL: https://master.ose32.example.com:8443/console/ servingInfo: bindAddress: 0.0.0.0:8443 bindNetwork: tcp4 certFile: master.server.crt clientCA: "" keyFile: master.server.key maxRequestsInFlight: 0 requestTimeoutSeconds: 0
`corsAllowedOrigins`	異なるホスト名を使用して Web アプリケーションから API サーバーにアクセスするには、設定フィールドに `corsAllowedOrigins` を指定するか、または `--cors-allowed-origins` オプションを `openshift start` に指定してそのホスト名をホワイトリスト化する必要があります。その値の固定 (pinning) やエスケープは実行されません。使用例については、「Web Console」を参照してください。
`DisabledFeatures`	起動することのできない機能の一覧です。null に設定してください。この機能を手動で無効にする必要性はほとんどなく、この操作を実行することも推奨されません。
`Extensions`	サブコンテクストの下位のアセットサーバーファイルシステムから提供されるファイルです。
`ExtensionDevelopment`	true に設定されている場合、起動時だけでなく要求が出されるたびに拡張機能スクリプトとスタイルシートをリロードするようアセットサーバーに指示します。変更のたびにサーバーを再起動しなくても、拡張機能を展開することができます。
`ExtensionProperties`	コンソールのグローバル変数 `OPENSHIFT_EXTENSION_PROPERTIES` の下に挿入されるキー - (文字列) 値 - (文字列) のペアです。
`ExtensionScripts`	Web コンソールが読み込む際にスクリプトとして読み込まれるアセットサーバーファイル上のファイルパスです。
`ExtensionStylesheets`	Web コンソールが読み込む際にスタイルシートとして読み込まれるアセットサーバーファイル上のファイルパスです。
`LoggingPublicURL`	ロギング用のパブリックエンドポイント (オプション) です。
`LogoutURL`	Web コンソールからログアウトした後に Web ブラウザーをリダイレクトするオプションの絶対 URL です。指定されていない場合は、ビルトインされたログアウトページが表示されます。
`MasterPublicURL`	Web コンソールが OpenShift Container Platform サーバーにアクセスする方法について示します。
`MetricsPublicURL`	メトリクス用のパブリックエンドポイント (オプション) です。
`PublicURL`	アセットサーバーの URL です。

5.5.3. 認証と承認の設定

表5.3 認証および承認パラメーター

パラメーター名	説明
`authConfig`	認証および承認設定オプションを保持します。
`AuthenticationCacheSize`	キャッシュされる認証結果の数を示します。0 の場合は、デフォルトのキャッシュサイズが使用されます。
`AuthorizationCacheTTL`	承認結果がキャッシュされる期間を示します。有効な時間文字列 (「5 m」など) を取り、空の場合はデフォルトのタイムアウトが取得されます。ゼロ (「0 m」など) の場合、キャッシシングは無効になります。

5.5.4. コントローラーの設定

表5.4 コントローラー設定パラメーター

パラメーター名	説明
`Controllers`	起動するコントローラーの一覧です。none に設定されている場合、コントローラーは自動的に起動されません。デフォルト値は * であり、これによりすべてのコントローラーが起動します。* を使用している場合は、コントローラーの名前の先頭に `-` を追加することでそのコントローラーを除外できます。この時点で他の値は認識されません。
`ControllerLeaseTTL`	コントローラーの選択を有効にし、マスターに対してコントローラーが起動する前にリースを取得するように指示して、この値で定義された秒数内にリースを更新します。負の値以外の値を設定することで `pauseControllers=true` が強制的に実行されます。デフォルトの値はオフ (0 または省略) であり、コントローラーの選択は -1 で無効にできます。
`PauseControllers`	マスターに対してコントローラーを自動的に開始せず、起動前にサーバーへの通知が受信するまで待機するように指示します。

5.5.5. etcd の設定

表5.5 etcd 設定パラメーター

パラメーター名	説明
`Address`	etcd へのクライアント接続用に公開される host:port です。
`etcdClientInfo`	etcd に接続する方法についての情報が含まれます。etcd を組み込みまたは組み込み以外の方法で実行するかどうかを指定し、ホストを指定します。残りの設定は Ansible インベントリーで処理されます。以下は例になります。 etcdClientInfo: ca: ca.crt certFile: master.etcd-client.crt keyFile: master.etcd-client.key urls: - https://m1.aos.example.com:4001
`etcdConfig`	これがある場合、etcd は定義されたパラメーターに基づいて起動します。以下は例になります。 etcdConfig: address: master.ose32.example.com:4001 peerAddress: master.ose32.example.com:7001 peerServingInfo: bindAddress: 0.0.0.0:7001 certFile: etcd.server.crt clientCA: ca.crt keyFile: etcd.server.key servingInfo: bindAddress: 0.0.0.0:4001 certFile: etcd.server.crt clientCA: ca.crt keyFile: etcd.server.key storageDirectory: /var/lib/origin/openshift.local.etcd
`etcdStorageConfig`	API リソースを etcd に格納する方法についての情報が含まれます。これらの値は、etcd がクラスターのバッキングストアである場合にのみ関連する値になります。
`KubernetesStoragePrefix`	Kubernetes のリソースがその下位に置かれる etcd 内のパスです。この値が変更されると *etcd* 内の既存のオブジェクトは検索できなくなります。デフォルトの値は kubernetes.io です。
`KubernetesStorageVersion`	*etcd* 内の Kubernetes リソースがシリアライズされる API バージョン。etcd から読み取りを行うクラスター内のすべてのクライアントが新規バージョンの読み取りを可能にするコードを取得するまでこの値を変更することができません。
`OpenShiftStoragePrefix`	OpenShift Container Platform リソースがその下位に置かれる etcd 内のパスです。この値が変更されると、etcd 内の既存のオブジェクトは検索できなくなります。デフォルトの値は openshift.io です。
`OpenShiftStorageVersion`	*etcd* 内の OS リソースがシリアライズされる API バージョンです。*etcd* から読み取りを行うクラスター内のすべてのクライアントが新規バージョンの読み取りを可能にするコードを取得するまで、この値を変更することができません。
`PeerAddress`	*etcd* へのピア接続用に公開される host:port です。
`PeerServingInfo`	*etcd* ピアの提供を開始する方法を記述します。
`ServingInfo`	提供を開始する方法を記述します。以下は例になります。 servingInfo: bindAddress: 0.0.0.0:8443 bindNetwork: tcp4 certFile: master.server.crt clientCA: ca.crt keyFile: master.server.key maxRequestsInFlight: 500 requestTimeoutSeconds: 3600
`StorageDir`	*etcd* ストレージディレクトリーへのパスです。

5.5.6. 付与の設定

表5.6 付与の設定パラメーター

パラメーター名	説明
`GrantConfig`	付与を処理する方法を記述します。
`GrantHandlerAuto`	クライアントの承認付与の要求を自動承認します。
`GrantHandlerDeny`	クライアントの承認付与の要求を自動的に拒否します。
`GrantHandlerPrompt`	ユーザーに対し、クライアントの新規の承認付与要求を承認することを求めるプロンプトを出します。
`Method`	OAuth クライアントが付与を要求したときに使用するデフォルトのストラテジーを決定します。この方法は特定の OAuth クライアントが独自のストラテジーを提供しない場合にのみ使用します。付与を処理するための有効な方法は以下の通りです。 auto: 付与要求を常に承認します。信頼されるクライアントの場合に役立ちます。 prompt: エンドユーザーに対し、付与要求の承認を求めるプロンプトを出します。サードパーティーのクライアントの場合に役立ちます。 deny: 付与要求を常に拒否します。ブラックリスト化されたクライアントの場合に役立ちます。

5.5.7. イメージ設定

表5.7 イメージ設定パラメーター

パラメーター名	説明
`Format`	システムコンポーネント用に作成される名前のフォーマットです。
`Latest`	最新のタグをレジストリーからプルするかどうかを決定します。

5.5.8. イメージポリシーの設定

表5.8 イメージポリシー設定パラメーター

パラメーター名	説明
`DisableScheduledImport`	スケジュールされたイメージのバックグラウンドインポートの無効化を許可します。
`MaxImagesBulkImportedPerRepository`	ユーザーが Docker リポジトリーの一括インポートを行う際に、インポートされるイメージの数を制御します。デフォルトの値は 5 に設定され、ユーザーが誤って大量のイメージをインポートすることを防ぎます。-1 に設定すると無制限になります
`MaxScheduledImageImportsPerMinute`	スケジュールされたイメージストリームがバックグラウンドでインポートされる 1 分あたりの最大数です。デフォルト値は 60 です。
`ScheduledImageImportMinimumIntervalSeconds`	バックグラウンドのインポートがスケジュールされているイメージストリームが、アップストリームのリポジトリーと照合される際の最小間隔 (秒単位) です。デフォルト値は 15 秒です。
`AllowedRegistriesForImport`	標準ユーザーがイメージのインポートに使用する Docker レジストリーを制限します。この一覧を、有効な Docker イメージを含むものとユーザーが信頼し、アプリケーションのインポート元となるレジストリーに設定します。Images または ImageStreamMappings を API 経由で作成するパーミッションを持つユーザーは、このポリシーによる影響を受けません。通常、これらのパーミッションを持っているのは管理者またはシステム統合管理者のみです。
`InternalRegistryHostname`	デフォルトの内部イメージレジストリーのホスト名を設定します。値は `hostname[:port]` 形式である必要があります。後方互換性を考慮して、ユーザーは引き続き `OPENSHIFT_DEFAULT_REGISTRY` 環境変数を使用できますが、この設定はこの環境変数を上書きします。このパラメーターが設定されると、内部レジストリーにはそのホスト名も設定される必要があります。詳細は、「レジストリーのホスト名の設定」を参照してください。
`ExternalRegistryHostname`	ExternalRegistryHostname は、デフォルトの外部イメージレジストリーのホスト名を設定します。この外部ホスト名は、イメージレジストリーが外部に公開される場合にのみ設定されます。値は ImageStreams の `publicDockerImageRepository` フィールドで使用されます。値は `hostname[:port]` 形式でなければなりません。

5.5.9. Kubernetes のマスター設定

表5.9 Kubernetes のマスター設定パラメーター

パラメーター名	説明
`APILevels`	起動時に有効にする必要のある API レベルの一覧です (v1 など)。
`DisabledAPIGroupVersions`	無効にする必要のあるバージョン (または `*`) のグループのマップです。
`KubeletClientInfo`	Kubelets に接続する方法についての情報が含まれます。
`KubernetesMasterConfig`	kubelet の KubernetesMasterConfig への接続方法についての情報が含まれます。これがある場合、Kubernetes のマスターをこのプロセスで起動します。
`MasterCount`	実行されていることが予想されるマスターの数です。デフォルトの値は 1 であり、正の整数に設定できますが、-1 に設定されている場合はそれがクラスターの一部であることを示します。
`MasterIP`	Kubernetes リソースのパブリック IP アドレスです。空の場合、`net.InterfaceAddrs` の最初の結果が使用されます。
`MasterKubeConfig`	このノードをマスターに接続する方法を記述した *.kubeconfig* ファイルのファイル名です。
`ServicesNodePortRange`	サービスのパブリックポートをホストに割り当てる際に使用される範囲です。デフォルトは 30000-32767 です。
`ServicesSubnet`	サービス IP の割り当てに使用されるサブネットです。
`StaticNodeNames`	静的に認識されるノードの一覧です。

5.5.10. ネットワーク設定

IPv4 アドレス領域はノード上のすべてのユーザーが共有するため、CIDR を以下のパラメーターで慎重に選択してください。OpenShift Container Platform はそれ自体に使用する CIDR を IPv4 アドレス領域から予約し、外部ユーザーとクラスターが共有するアドレス用の CIDR を IPv4 アドレス領域から予約します。

表5.10 ネットワーク設定パラメーター

パラメーター名	説明
`ClusterNetworkCIDR`	グローバルなオーバーレイネットワークの L3 領域を指定する CIDR 文字列です。クラスターネットワークの内部使用のために予約されています。
`externalIPNetworkCIDRs`	サービスの外部 IP フィールドで許可される値を制御します。空の場合、`externalIP` は設定できません。これには CIDR の一覧を含めることができ、この一覧はアクセスについてチェックされます。CIDR にプレフィックス ! が付いている場合、その CIDR の IP は拒否されます。最初に拒否が適用され、その後に IP が許可された CIDR のいずれかに対してチェックされます。セキュリティー上の理由から、この範囲はユーザーのノード、Pod 、またはサービス CIDR と重複させることはできません。
`HostSubnetLength`	各ホストのサブネットに割り当てられるビット数です。たとえば 8 の場合は、ホスト上の /24 ネットワークを意味します。
`ingressIPNetworkCIDR`	ベアメタル上のタイプ LoadBalancer のサービス用に ingress IP を割り当てる範囲を制御します。そこから割り当てられる単一の CIDR を含めることができます。デフォルトは `172.46.0.0/16` に設定されています。セキュリティー上の理由から、この範囲は外部 IP 、ノード、Pod、またはサービス用に予約されている CIDR と重複しないようにする必要があります。
`HostSubnetLength`	各ホストのサブネットに割り当てられるビット数です。たとえば 8 の場合は、ホスト上の /24 ネットワークを意味します。
`NetworkConfig`	compiled-in-network プラグインに渡されます。ここでのオプションの多くは Ansible インベントリーで制御されます。 `NetworkPluginName` (文字列) `ClusterNetworkCIDR` (文字列) `HostSubnetLength` (署名なし整数) `ServiceNetworkCIDR` (文字列) `ExternalIPNetworkCIDRs` (文字列の配列): サービスの外部 IP フィールドで許可される値を制御します。空の場合、外部 IP を設定できません。CIDR の一覧を含むことができ、そのアクセスがチェックされます。CIDR にプレフィックス `!` が付いている場合、その CIDR のIP は拒否されます。最初に拒否が適用され、次に IP が許可された CIDR のいずれかに対してチェックされます。セキュリティー上の理由から、この範囲はユーザーのノード、Pod、またはサービス CIDR と重複しないようにする必要があります。以下は例になります。 networkConfig: clusterNetworks - cidr: 10.3.0.0/16 hostSubnetLength: 8 networkPluginName: example/openshift-ovs-subnet # serviceNetworkCIDR must match kubernetesMasterConfig.servicesSubnet serviceNetworkCIDR: 179.29.0.0/16
`NetworkPluginName`	使用されるネットワークプラグインの名前です。
`ServiceNetwork`	サービスネットワークを指定する CIDR 文字列です。

5.5.11. OAuth 認証設定

表5.11 OAuth 設定パラメーター

パラメーター名	説明
`AlwaysShowProviderSelection`	単一プロバイダーしかない場合でも、プロバイダーの選択ページを強制的にレンダリングします。
`AssetPublicURL`	外部アクセス用の有効なクライアントのリダイレクト URL の作成に使用されます。
`Error`	認証または付与フローでエラーページのレンダリングに使用される Go テンプレートを含むファイルへのパスです。指定しない場合、デフォルトのエラーページが使用されます。
`IdentityProviders`	ユーザーが自身を確認する方法の順序付きの一覧です。
`Login`	ログインページのレンダリングに使用される Go テンプレートを含むファイルへのパスです。指定しない場合、デフォルトのログインページが使用されます。
`MasterCA`	TLS 接続が `MasterURL` に戻っていることを確認するための CA です。
`MasterPublicURL`	外部アクセス用の有効なクライアントのリダイレクト URL の作成に使用されます。
`MasterURL`	アクセストークンの承認コードを交換するためのサーバー間の呼び出しに使用されます。
`OAuthConfig`	これがある場合、/oauth エンドポイントは定義されたパラメーターに基づいて開始します。以下は例になります。 oauthConfig: assetPublicURL: https://master.ose32.example.com:8443/console/ grantConfig: method: auto identityProviders: - challenge: true login: true mappingMethod: claim name: htpasswd_all provider: apiVersion: v1 kind: HTPasswdPasswordIdentityProvider file: /etc/origin/openshift-passwd masterCA: ca.crt masterPublicURL: https://master.ose32.example.com:8443 masterURL: https://master.ose32.example.com:8443 sessionConfig: sessionMaxAgeSeconds: 3600 sessionName: ssn sessionSecretsFile: /etc/origin/master/session-secrets.yaml tokenConfig: accessTokenMaxAgeSeconds: 86400 authorizeTokenMaxAgeSeconds: 500
`OAuthTemplates`	ログインページなどページのカスタマイズを許可します。
`ProviderSelection`	プロバイダーの選択ページのレンダリングに使用される Go テンプレートを含むファイルへのパスです。指定されていない場合、デフォルトのプロバイダー選択ページが使用されます。
`SessionConfig`	セッションの設定に関する情報を保持します。
`Templates`	ログインページなどのページのカスタマイズを許可します。
`TokenConfig`	承認とアクセストークンのオプションが含まれます。

5.5.12. プロジェクトの設定

表5.12 プロジェクト設定パラメーター

パラメーター名	説明
`DefaultNodeSelector`	デフォルトのプロジェクトノードのラベルセレクターを保持します。
`ProjectConfig`	プロジェクト作成とデフォルトに関する情報を保持します。 `DefaultNodeSelector` (文字列): デフォルトのプロジェクトノードのラベルセレクターを保持します。 `ProjectRequestMessage` (文字列): この文字列は、ユーザーが projectrequest API エンドポイントからプロジェクトを要求できない場合に提示されます。 `ProjectRequestTemplate` (文字列): projectrequest への応答としてプロジェクトを作成する際に使用されるテンプレートです。フォーマット `<namespace>/<template>` が使用されます。これはオプションであり、指定されていない場合はデフォルトのテンプレートが使用されます。 `SecurityAllocator`: UID と MCS ラベルのプロジェクトに対する自動割り当てを制御します。空の場合、割り当ては無効にされます。 `mcsAllocatorRange` (文字列): namespace に割り当てられる MCS カテゴリーの範囲を定義します。フォーマットは `<prefix>/<numberOfLabels>[,<maxCategory>]` です。デフォルトは `s0/2` であり、c0 から c1023 に割り当てられます。つまり、これは合計 535000 のラベルが利用可能であることを意味します。この値を起動後に変更すると、新規プロジェクトは、すでに他のプロジェクトに割り当てられているラベルを受信することがあります。プレフィックスには SELinux の有効な用語のセット (ユーザー、ロール、タイプなど) を使用できます。ただし、プレフィックスをデフォルトとして残しておくと、サーバーはそれらを自動的に設定できます。たとえば、`s0:/2` はラベルを s0:c0,c0 から s0:c511,c511 に割り当て、`s0:/2,512` はラベルを s0:c0,c0,c0 から s0:c511,c511,511 に割り当てます。 `mcsLabelsPerProject` (整数): プロジェクトごとに予約するラベルの数を定義します。デフォルトは、デフォルトの UID と MCS の範囲に一致する `5` です。 `uidAllocatorRange` (文字列): プロジェクトに自動的に割り当てられる Unix ユーザー ID (UID) の合計セット数と、各 namespace が取得するブロックのサイズを定義します。たとえば、 `1000-1999/10` は namespace ごとに 10 の UID を割り当て、空間を使い果たす前に最大 100 のブロックを割り当てることが可能です。デフォルトでは、1 万のブロックに 10 億から 20 億を割り当てます。これは、ユーザーの namespace の起動時にコンテナーイメージについて予想される範囲のサイズです。
`ProjectRequestMessage`	この文字列は、プロジェクトの要求 API エンドポイントからプロジェクトを要求できない場合にユーザーに提示されます。
`ProjectRequestTemplate`	projectrequest への応答としてプロジェクトを作成する際に使用されるテンプレートです。フォーマットは namespace/template です。これはオプションであり、指定されていない場合はデフォルトのテンプレートが使用されます。

5.5.13. スケジューラーの設定

表5.13 スケジューラー設定パラメーター

パラメーター名	説明
`SchedulerConfigFile`	スケジューラーのセットアップ方法を記述しているファイルをポイントします。空の場合、デフォルトのスケジューリングルールが取得されます。

5.5.14. セキュリティーアロケーターの設定

表5.14 セキュリティーアロケーターパラメーター

パラメーター名	説明
`MCSAllocatorRange`	namespace に割り当てられる MCS カテゴリーの範囲を定義します。フォーマットは `<prefix>/<numberOfLabels>[,<maxCategory>]` です。デフォルトは s0/2 であり、c0 から c1023 に割り当てられます。つまり、合計 535000 のラベルが利用可能であることを意味します (1024 は 2 ~ 535000 を選択します)。この値を起動後に変更すると、新規プロジェクトは、すでに別のプロジェクトに割り当てられているラベルを受信することがあります。プレフィックスには、SELinux の有効な用語のセット (ユーザー、ロール、タイプなど) にすることができます。ただしこれらをデフォルトとして残しておくと、サーバーはこれらを自動的に設定できます。
`SecurityAllocator`	UID と MCS ラベルのプロジェクトへの自動割り当てを制御します。空の場合、割り当ては無効にされます。
`UIDAllocatorRange`	プロジェクトに自動的に割り当てられる Unix ユーザー ID (UID) の合計セット数と、各 namespace が取得するブロックのサイズを定義します。たとえば、1000-1999/10 は namespace ごとに 10 の UID を割り当て、空間を使い果たす前に最大 100 のブロックを割り当てることが可能です。デフォルトでは、1 万のブロックに 10 億から 20 億 (ユーザー namespace の起動時にコンテナーイメージが使用する範囲の予想されるサイズ) を割り当てます。

5.5.15. サービスアカウントの設定

表5.15 サービスアカウント設定パラメーター

パラメーター名	説明
`LimitSecretReferences`	サービスアカウントに、明示的な参照なしに namespace のシークレットの参照を許可するかどうかを制御します。
`ManagedNames`	すべての namespace に自動作成されるサービスアカウント名の一覧です。名前が指定されていない場合、`ServiceAccountsController` は起動しません。
`MasterCA`	TLS 接続がマスターに戻っていることを確認する CA です。サービスアカウントのコントローラーは、マスターへの接続を検証できるようにこのファイルの内容を Pod に自動的に挿入します。
`PrivateKeyFile`	PEM でエンコードされた RSA プライベートキーを含むファイルです。これはサービスアカウントのトークンの署名に使用されます。プライベートキーが指定されていない場合、サービスアカウント `TokensController` は起動しません。
`PublicKeyFiles`	PEM でエンコードされた RSA パブリックキーを含むファイルの一覧です。いずれかのファイルにプライベートキーが含まれている場合、そのキーのパブリックの部分が使用されます。パブリックキーの一覧は、表示されているサービスアカウントのトークンの確認に使用されます。それぞれのキーは、一覧がすべて使用されるまで、または確認が正常に実行されるまで順番に試行されます。キーが指定されていない場合、サービスアカウントの認証は使用できません。
`ServiceAccountConfig`	サービスアカウントに関連するオプションを保持します。 `LimitSecretReferences` (ブール値): サービスアカウントに、明示的な参照なしに namespace のシークレットの参照を許可するかどうかを制御します。 `ManagedNames` (文字列): それぞれの namespace に自動作成されるサービスアカウント名の一覧です。名前が指定されていない場合、`ServiceAccountsController` は起動しません。 `MasterCA` (文字列): TLS 接続がマスターに戻っていることを確認する認証局です。サービスアカウントコントローラーは、マスターへの接続を検証できるようにこのファイルの内容を Pod に自動的に挿入します。 `PrivateKeyFile` (文字列): PEM でエンコードされた RSA プライベートキーが含まれ、サービスアカウントのトークンの署名に使用されます。プライベートキーが指定されていない場合、サービスアカウント `TokensController` は起動しません。 `PublicKeyFiles` (文字列): PEM でエンコードされた RSA パブリックキーを含むファイルの一覧です。いずれかのファイルにプライベートキーが含まれている場合、OpenShift Container Platform はキーのパブリックの部分を使用します。パブリックキーの一覧は、サービスアカウントのトークンの確認に使用されます。それぞれのキーは、一覧がすべて使用されるまで、または確認が正常に実行されるまで順番に試行されます。キーが指定されていない場合、サービスアカウントの認証は使用できません。

5.5.16. 提供情報の設定

表5.16 提供情報設定パラメーター

パラメーター名	説明
`AllowRecursiveQueries`	マスター上の DNS サーバーがクエリーに再帰的に応答することを許可します。オープンリゾルバーは DNS アンプ攻撃に使用される可能であり、マスター DNS は公開ネットワークでアクセスできないようにする必要があることに注意してください。
`BindAddress`	提供に使用される ip:port です。
`BindNetwork`	イメージをインポートするための制限と動作を制御します。
`CertFile`	PEM でエンコードされた証明書を含むファイルです。
`CertInfo`	セキュアなトラフィックを提供するための TLS 証明書情報です。
`ClientCA`	クライアント証明書が受信される際にユーザーが認識するすべての署名者の証明書バンドルです。
`dnsConfig`	これがある場合、DNS サーバーが定義されたパラメーターに基づいて起動します。以下は例になります。 dnsConfig: bindAddress: 0.0.0.0:8053 bindNetwork: tcp4
`DNSDomain`	ドメインサフィックスを保持します。
`DNSIP`	IP を保持します。
`KeyFile`	`CertFile` が指定した証明書の PEM でエンコードされたプライベートキーを含むファイルです。
`MasterClientConnectionOverrides`	マスターへの接続に使用されたクライアント接続を上書きします。
`MaxRequestsInFlight`	サーバーに許可されている同時要求数です。ゼロの場合は無制限です。
`NamedCertificates`	特定のホスト名への要求を保護するのに使用される証明書の一覧です。
`RequestTimeoutSecond`	要求がタイムアウトするまでの秒数です。デフォルトは 60 分です。-1 の場合、要求について無制限となります。
`ServingInfo`	アセット用の HTTP 提供情報です。

5.5.17. ボリュームの設定

表5.17 ボリューム設定パラメーター

パラメーター名	説明
`DynamicProvisioningEnabled`	動的なプロビジョニングを有効化または無効化するブール値です。デフォルトは true です。
FSGroup	各ノードでそれぞれの FSGroup についてローカルストレージクォータを有効にします。現時点では、これは emptyDir ボリュームについて、基礎となる `volumeDirectory` が XFS ファイルシステムにある場合にのみ実装されます。
`MasterVolumeConfig`	マスターノードのボリュームプラグインを設定するオプションが含まれます。
`NodeVolumeConfig`	ノードのボリュームを設定するオプションが含まれます。
`VolumeConfig`	ノードのボリュームプラグインを設定するオプションが含まれます。 `DynamicProvisioningEnabled` (ブール値): デフォルト値は `true` です。`false` の場合は動的プロビジョニングはオフに切り替わります。
`VolumeDirectory`	ボリュームがその下に保存されるディレクトリーです。

5.5.18. 基本的な監査

監査は、システムに影響を与えた一連のアクティビティーを個別のユーザー、管理者その他システムのコンポーネント別に記述したセキュリティー関連の時系列のレコードを提供します。

監査は API サーバーレベルで実行され、サーバーに送られるすべての要求をログに記録します。それぞれの監査ログには以下の 2 つのエントリーが含まれます。

以下を含む要求行。
1. 応答行 (以下の 2 を参照してください) と一致する固有 ID
2. 要求のソース IP
3. 呼び出されている HTTP メソッド
4. 操作を呼び出している元のユーザー
5. 操作を実行するための偽装ユーザー (self はユーザー自身を指します)
6. 操作を実行するための偽装グループ (lookup はユーザーのグループを指します)
7. 要求または <none> の namespace
8. 要求される URI
以下を含む応答行。
1. 上記 1 の固有の ID
2. 応答コード

Pod の一覧を要求するユーザー admin の出力例。

AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" ip="127.0.0.1" method="GET" user="admin" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/pods"
AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" response="200"

openshift_master_audit_config 変数は、API サービス監査を有効にします。これは以下のオプションの配列を取ります。

表5.18 監査設定パラメーター

パラメーター名	説明
`enabled`	監査ログを有効または無効にするブール値です。デフォルト値は `false` です。
`auditFilePath`	要求をログに記録するファイルパスです。設定されていない場合、ログはマスターログに出力されます。
`maximumFileRetentionDays`	ファイル名にエンコードされるタイムスタンプに基づいて古い監査ログファイルを保持する最大日数を指定します。
`maximumRetainedFiles`	古い監査ログファイルを保持する最大日数を指定します。
`maximumFileSizeMegabytes`	ログファイルがローテーションされる前に、ファイルの最大サイズをメガバイトで指定します。デフォルトは 100 MB です。

監査の設定例

auditConfig:
  auditFilePath: "/var/log/audit-ocp.log"
  enabled: true
  maximumFileRetentionDays: 10
  maximumFileSizeMegabytes: 10
  maximumRetainedFiles: 10

監査ログの高度なセットアップ

監査ログの高度なセットアップを使用する必要がある場合には、以下を使用できます。

openshift_master_audit_config={"enabled": true}

auditFilePath のディレクトリーが、存在していない場合に作成されます。

openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/log/openpaas-oscp-audit/openpaas-oscp-audit.log", "maximumFileRetentionDays": 14, "maximumFileSizeMegabytes": 500, "maximumRetainedFiles": 5}

5.5.19. 高度な監査

高度な監査機能は、詳細なイベントのフィルタリングや複数の出力バックエンドなど、基本的な監査機能に対するいくつかの改良機能を提供します。以下の表に使用可能な追加オプションを示します。

表5.19 高度な監査設定パラメーター

パラメーター名	説明
`policyFile`	監査ポリシー設定を定義するファイルへのパスです。
`policyConfiguration`	組み込まれる監査ポリシー設定です。
`logFormat`	保存される監査ログのフォーマットを指定します。許可されている値は `legacy` (基本的な監査に使用されるフォーマット) と `json` です。
`webHookKubeConfig`	監査の Webhook 設定を定義する `.kubeconfig` でフォーマットされたファイルへのパスです。ここにイベントが送信されます。
`webHookMode`	監査イベントを送信するためのストラテジーを指定します。許可される値は `block` (直前のイベント処理が完了するまで別のイベントの処理をブロックする) と `batch` (イベントをバッファー処理し、バッチで提供する) です。

高度な監査機能を有効にするには、監査ポリシールールを記述する policyFile または policyConfiguration を指定する必要があります。

監査ポリシーの設定例

apiVersion: audit.k8s.io/v1beta1
kind: Policy
rules:

  # Do not log watch requests by the "system:kube-proxy" on endpoints or services
  - level: None 1
    users: ["system:kube-proxy"] 2
    verbs: ["watch"] 3
    resources: 4
    - group: ""
      resources: ["endpoints", "services"]

  # Do not log authenticated requests to certain non-resource URL paths.
  - level: None
    userGroups: ["system:authenticated"] 5
    nonResourceURLs: 6
    - "/api*" # Wildcard matching.
    - "/version"

  # Log the request body of configmap changes in kube-system.
  - level: Request
    resources:
    - group: "" # core API group
      resources: ["configmaps"]
    # This rule only applies to resources in the "kube-system" namespace.
    # The empty string "" can be used to select non-namespaced resources.
    namespaces: ["kube-system"] 7

  # Log configmap and secret changes in all other namespaces at the metadata level.
  - level: Metadata
    resources:
    - group: "" # core API group
      resources: ["secrets", "configmaps"]

  # Log all other resources in core and extensions at the request level.
  - level: Request
    resources:
    - group: "" # core API group
    - group: "extensions" # Version of group should NOT be included.

  # A catch-all rule to log all other requests at the Metadata level.
  - level: Metadata 8

  # Log login failures from the web console or CLI. Review the logs and refine your policies.
  - level: Metadata
    nonResourceURLs:
    - /login* 9
    - /oauth* 10

1 8

すべてのイベントは以下の 4 つのレベルでログに記録できます。

None - このルールに一致するイベントは記録されません。
Metadata - 要求のメタデータ (要求しているユーザー、タイムスタンプ、リソース、verb など) をログに記録します。要求または応答本体はログに記録しません。基本的な監査で使用されるレベルと同じレベルになります。
Request - イベントのメタデータと要求本体をログに記録します。応答本体はログに記録しません。
RequestResponse - イベントのメタデータ、要求、および応答本体をログに記録します。

2

このルールが適用されるユーザーの一覧です。一覧が空の場合はすべてのユーザーに適用されます。

3

このルールが適用される verb の一覧です。一覧が空の場合はすべての verb に適用されます。これは API 要求に関連付けられる Kubernetes の verb です (get、list、watch、create、update、patch、delete、deletecollection、proxy など)。

4

このルールが適用されるリソースの一覧です。一覧が空の場合はすべてのリソースに適用されます。各リソースは、それが割り当てられるグループ (例: 空の場合は Kubernetes core API、バッチ、build.openshift.io などを指します) 、およびそのグループのリソース一覧として指定されます。

5

このルールが適用されるグループの一覧です。一覧が空の場合はすべてのグループに適用されます。

6

このルールが適用されるリソース以外の URL の一覧です。

7

このルールが適用される namespace の一覧です。一覧が空の場合はすべての namespace に適用されます。

9

Web コンソールが使用するエンドポイントです。

10

CLI が使用するエンドポイントです。

高度な監査についての詳細は、Kubernetes のドキュメントを参照してください。

5.5.20. etcd の TLS 暗号の指定

マスターと etcd サーバー間の通信で使用するサポートされている TLS 暗号を指定できます。

各 etcd ノードで、etcd をアップグレードします。
```
# yum update etcd iptables-services
```
お使いのバージョンが 3.2.22 以降であることを確認します。
```
# etcd --version
etcd Version: 3.2.22
```

各マスターホストで、/etc/origin/master/master-config.yaml ファイルで有効にする暗号を指定します。

servingInfo:
  ...
  minTLSVersion: VersionTLS12
  cipherSuites:
  - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  - TLS_RSA_WITH_AES_256_CBC_SHA
  - TLS_RSA_WITH_AES_128_CBC_SHA
...

各マスターホストで、マスターサービスを再起動します。
```
# master-restart api
# master-restart controllers
```

暗号が適用されていることを確認します。たとえば、TLSv1.2 暗号 ECDHE-RSA-AES128-GCM-SHA256 については、以下のコマンドを実行します。

# openssl s_client -connect etcd1.example.com:2379 1
CONNECTED(00000003)
depth=0 CN = etcd1.example.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = etcd1.example.com
verify error:num=21:unable to verify the first certificate
verify return:1
139905367488400:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:s3_pkt.c:1493:SSL alert number 42
139905367488400:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
Certificate chain
 0 s:/CN=etcd1.example.com
   i:/CN=etcd-signer@1529635004
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEkjCCAnqgAwIBAgIBATANBgkqhkiG9w0BAQsFADAhMR8wHQYDVQQDDBZldGNk
........
....
eif87qttt0Sl1vS8DG1KQO1oOBlNkg==
-----END CERTIFICATE-----
subject=/CN=etcd1.example.com
issuer=/CN=etcd-signer@1529635004
---
Acceptable client certificate CA names
/CN=etcd-signer@1529635004
Client Certificate Types: RSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA384
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1666 bytes and written 138 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID:
    Session-ID-ctx:
    Master-Key: 1EFA00A91EE5FC5EDDCFC67C8ECD060D44FD3EB23D834EDED929E4B74536F273C0F9299935E5504B562CD56E76ED208D
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1529651744
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)

1: etcd1.example.com は etcd ホストの名前です。

5.6. ノード設定ファイル

以下の node-config.yaml ファイルは、現時点でデフォルト値で生成されるノード設定ファイルのサンプルです。

注記

例5.1 ノード設定ファイルのサンプル

allowDisabledDocker: false
apiVersion: v1
authConfig:
  authenticationCacheSize: 1000
  authenticationCacheTTL: 5m
  authorizationCacheSize: 1000
  authorizationCacheTTL: 5m
dnsDomain: cluster.local
dnsIP: 0.0.0.0 1
dockerConfig:
  execHandlerName: native
imageConfig:
  format: openshift/origin-${component}:${version}
  latest: false
iptablesSyncPeriod: 5s
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
  mtu: 1450
  networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com
podManifestConfig: 2
  path: "/path/to/pod-manifest-file" 3
  fileCheckIntervalSeconds: 30 4
proxyArguments:
  proxy-mode:
  - iptables 5
servingInfo:
  bindAddress: 0.0.0.0:10250
  bindNetwork: tcp4
  certFile: server.crt
  clientCA: node-client-ca.crt
  keyFile: server.key
  namedCertificates: null
volumeDirectory: /root/openshift.local.volumes

1: ここにアドレスを追加することで、Pod の /etc/resolv.conf の先頭に追加される IP アドレスを設定します。
2: 特定のノードセット上、またはすべてのノード上に、スケジューラーを介することなく Pod を直接配置することを許可します。ユーザーは、Pod を使って同じ管理タスクを実行し、各ノードで同じサービスをサポートすることができます。
3: Pod のマニフェストファイルまたはディレクトリーへのパスを指定します。ディレクトリーの場合、1 つ以上のマニフェストファイルが含まれることが予想されます。これは、Pod をノード上に作成するために Kubelet によって使用されます。
4: 新規データのマニフェストファイルをチェックする間隔 (秒単位) です。この値は正の値で入力する必要があります。
5: 使用するサービスプロキシーの実装です。

ノード設定ファイルはノードのリソースを決定します。詳細は、「Allocating node resources section in the Cluster Administrator guide」を参照してください。

5.6.1. Pod とノードの設定

表5.20 Pod とノードの設定パラメーター

パラメーター名	説明
`NodeConfig`	OpenShift Container Platform ノードを起動する完全に指定された設定です。
`NodeIP`	ノードは複数の IP を持つことがあるため、Pod のトラフィックルーティングに使用する IP を指定します。指定されていない場合、nodeName でネットワーク解析/ルックアップが実行され、最初の非ループバックアドレスが使用されます。
`NodeName`	クラスターの特定ノードを識別するために使用される値です。可能な場合、この値はユーザーの完全修飾ホスト名にできます。ユーザーが静的ノードのセットをマスターに記述している場合、この値は一覧にある値のいずれかに一致している必要があります。
`PodEvictionTimeout`	失敗したノード上の Pod を削除するための猶予期間を制御します。有効な時間文字列を取ります。空の場合、Pod のデフォルトのエビクションタイムアウトを取ります。
`ProxyClientInfo`	Pod へのプロキシー処理時に使用するクライアント証明書/キーを指定します。

5.6.2. Docker の設定

表5.21 Docker 設定パラメーター

パラメーター名	説明
`AllowDisabledDocker`	true の場合、Kubelet は Docker のエラーを無視します。これは、Docker を起動させていないマシンでノードを起動できることを意味します。
`DockerConfig`	Docker 関連の設定オプションを保持します。
`ExecHandlerName`	Docker コンテナーでのコマンドの実行に使用するハンドラーです。

5.6.3. ローカルストレージの設定

XFS クォータサブシステムを使用して emptyDir ボリューム、および各ノードのシークレットおよび設定マップなどの emptyDir ボリュームに基づくボリュームのサイズを制限できます。

XFS ファイルシステムで emptyDir ボリュームのサイズを制限するには、openshift-node プロジェクトで node-config-compute 設定マップを使用し、それぞれ一意の FSGroup についてローカルボリュームクォータを設定します。

apiVersion: kubelet.config.openshift.io/v1
kind: VolumeConfig
  localQuota: 1
    perFSGroup: 1Gi 2

1: ノードのローカルボリュームクォータを制御するオプションが含まれます。
2: この値を、1Gi、512Mi など [FSGroup] 別、ノード別に必要なクォータを示すリソース量に設定します volumeDirectory は grpquota オプションを指定してマウントされた XFS ファイルシステムになければなりません。一致する SCC (security context constraint) の fsGroup タイプは MustRunAs に設定する必要があります。

FSGroup が指定されていない場合、つまり要求が RunAsAny の SCC に一致することを示す場合、クォータの適用は省略されます。

注記

/etc/origin/node/volume-config.yaml ファイルは直接編集しないでください。このファイルは node-config-compute 設定マップを基に作成されます。node-config-compute 設定マップを使用して volume-config.yaml ファイルでパラメーターの作成または編集を実行します。

5.6.4. Docker 1.9 以降を使用したイメージの並行プル

Docker 1.9 以降を使用している場合は、イメージの並行プルを有効にしておくことができます。デフォルトでは、イメージは一度に 1 つずつプルされます。

注記

Docker 1.9 よりも前のバージョンでは、データの破損による問題が発生する可能性があります。1.9 以降では破損の問題は解消し、並行プルに安全に切り替えることができます。

kubeletArguments:
  serialize-image-pulls:
  - "false" 1

1: 並行プルを無効にするには true に変更します (デフォルトの設定)。

5.7. パスワードおよびその他の機密データ

認証設定によっては、LDAP bindPassword または OAuth clientSecret の値が必須になる場合があります。これらの値は、マスター設定ファイルに直接指定する代わりに、環境変数、外部ファイルまたは暗号化ファイルとして指定することができます。

環境変数の例

  ...
  bindPassword:
    env: BIND_PASSWORD_ENV_VAR_NAME

外部ファイルの例

  ...
  bindPassword:
    file: bindPassword.txt

暗号化された外部ファイルの例

  ...
  bindPassword:
    file: bindPassword.encrypted
    keyFile: bindPassword.key

上記の例の暗号化ファイルとキーファイルを作成するには、以下を入力します。

$ oc adm ca encrypt --genkey=bindPassword.key --out=bindPassword.encrypted
> Data to encrypt: B1ndPass0rd!

Ansible ホストインベントリーファイル (デフォルトで /etc/ansible/hosts) に最初に一覧表示されているマスターから oc adm コマンドを実行します。

警告

暗号化データのセキュリティーレベルは復号化キーと同程度です。ファイルシステムのパーミッションとキーファイルへのアクセスを制限する際には十分な注意が必要です。

5.8. 新規設定ファイルの作成

OpenShift Container Platform 設定をゼロから定義するときは、新規設定ファイルを作成することから開始します。

マスターホストの設定ファイルでは、openshift start コマンドを --write-config オプションと共に使用して設定ファイルを作成します。ノードホストの場合は、oc adm create-node-config コマンドを使用して設定ファイルを作成します。

以下のコマンドは、関連する起動設定ファイル、証明書ファイルその他ファイルを指定された --write-config または --node-dir ディレクトリーに書き込みます。

生成される証明書ファイルは 2 年間有効です。一方、認証局 (CA) の証明書は 5 年間有効です。この値は --expire-days と --signer-expire-days のオプションを使用して変更できますが、セキュリティー上の理由によりこの値をこれ以上大きい値に変更しないことが推奨されます。

オールインワンサーバー (マスターとノードが同一ホスト上にある) の設定ファイルを指定されたディレクトリーに作成するには、以下を入力します。

$ openshift start --write-config=/openshift.local.config

マスター設定ファイルとその他の必須ファイルを指定されたディレクトリーに作成するには、以下を実行します。

$ openshift start master --write-config=/openshift.local.config/master

ノード設定ファイルとその他の関連ファイルを指定されたディレクトリーに作成するには、以下を実行します。

$ oc adm create-node-config \
    --node-dir=/openshift.local.config/node-<node_hostname> \
    --node=<node_hostname> \
    --hostnames=<node_hostname>,<ip_address> \
    --certificate-authority="/path/to/ca.crt" \
    --signer-cert="/path/to/ca.crt" \
    --signer-key="/path/to/ca.key"
    --signer-serial="/path/to/ca.serial.txt"
    --node-client-certificate-authority="/path/to/ca.crt"

ノード設定ファイルを作成する際に、--hostnames オプションは、サーバー証明書を有効にする必要のあるすべてのホスト名または IP アドレスのコンマ区切りの一覧を受け入れます。

5.9. 設定ファイルの使用によるサーバーの起動

マスターまたはノード設定ファイルをユーザー仕様に変更すると、これを引数として指定してサーバーを起動すると、使用できるようになります。設定ファイルを指定する場合は、ユーザーが渡す他のコマンドラインオプションはいずれも認識されないことに注意してください。

注記

マスター設定およびノード設定ファイルを使用してオールインワンサーバーを起動するには、以下を実行します。

$ openshift start --master-config=/openshift.local.config/master/master-config.yaml --node-config=/openshift.local.config/node-<node_hostname>/node-config.yaml

マスター設定ファイルを使用してマスターサーバーを起動するには、以下を実行します。

$ openshift start master --config=/openshift.local.config/master/master-config.yaml

ノード設定ファイルを使ってノードサーバーを起動するには、以下を実行します。

$ openshift start node --config=/openshift.local.config/node-<node_hostname>/node-config.yaml

5.10. ロギングレベルの設定

OpenShift Container Platform は、5 段階のログメッセージの重要度を用いて、systemd-journald.service を使ってデバッグ用にログメッセージを収集します。ロギングレベルは、以下のような Kubernetes のロギング規則に基づいています。

表5.22 ログレベルのオプション

オプション	説明
0	エラーと警告のみ
2	通常の情報
4	デバッグレベルの情報
6	API レベルのデバッグ情報 (要求 / 応答)
8	本体レベルの API のデバッグ情報

ユーザーは、/etc/sysconfig/atomic-openshift-node、/etc/sysconfig/atomic-openshift-master-api ファイル、および /etc/sysconfig/atomic-openshift-master-controllers ファイルにログレベルのオプションを設定することにより、ログに記録する INFO メッセージを制御できます。すべてのメッセージを収集するようにログを設定すると、解釈が困難な膨大なログが生成され、多くの領域が占領されます。すべてのメッセージの収集は、デバッグで使用する場合にとどめる必要があります。

注記

FATAL、ERROR、WARNING、および一部の INFO の重要度を伴うメッセージは、ログの設定に関係なくログに表示されます。

マスターまたはノードシステムのログは、以下のコマンドで表示できます。

# journalctl -r -u <journal_name>

最新のエントリーから表示するには、-r オプションを使用します。

以下は例を示しています。

# journalctl -r -u atomic-openshift-master-controllers
# journalctl -r -u atomic-openshift-master-api
# journalctl -r -u atomic-openshift-node.service

ロギングレベルを変更するには、以下を実行します。

マスターの /etc/sysconfig/atomic-openshift-master ファイル、またはノードの /etc/sysconfig/atomic-openshift-node ファイルを編集します。
上記の Log Level Options 表の値を OPTIONS=--loglevel= フィールドに入力します。
以下は例を示しています。
```
OPTIONS=--loglevel=4
```
マスターまたはノードを再起動します。「OpenShift Container Platform サービスの再起動」を参照してください。

再起動後は、すべての新しいログメッセージは新しい設定に従ったメッセージに従います。古いメッセージは変更されません。

注記

デフォルトのログレベルは標準のクラスターインストールプロセスを使用して設定できます。詳細は、「クラスター変数」を参照してください。

以下の例は、各種のログレベルのマスター journald ログの抜粋です。タイムスタンプとシステム情報はこれらの例では削除されています。

loglevel = 0 の journalctl -u atomic-openshift-master-controllers.service 出力の抜粋

4897 plugins.go:77] Registered admission plugin "NamespaceLifecycle"
4897 start_master.go:290] Warning: assetConfig.loggingPublicURL: Invalid value: "": required to view aggregated container logs in the console, master start will continue.
4897 start_master.go:290] Warning: assetConfig.metricsPublicURL: Invalid value: "": required to view cluster metrics in the console, master start will continue.
4897 start_master.go:290] Warning: aggregatorConfig.proxyClientInfo: Invalid value: "": if no client certificate is specified, the aggregator will be unable to proxy to remote servers,
4897 start_master.go:412] Starting controllers on 0.0.0.0:8444 (v3.7.14)
4897 start_master.go:416] Using images from "openshift3/ose-<component>:v3.7.14"
4897 standalone_apiserver.go:106] Started health checks at 0.0.0.0:8444
4897 plugins.go:77] Registered admission plugin "NamespaceLifecycle"
4897 configgetter.go:53] Initializing cache sizes based on 0MB limit
4897 leaderelection.go:105] Attempting to acquire openshift-master-controllers lease as master-bkr-hv03-guest44.dsal.lab.eng.bos.redhat.com-10.19.41.74-xtz6lbqb, renewing every 3s, hold
4897 leaderelection.go:179] attempting to acquire leader lease...
systemd[1]: Started Atomic OpenShift Master Controllers.
4897 leaderelection.go:189] successfully acquired lease kube-system/openshift-master-controllers
4897 event.go:218] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"kube-system", Name:"openshift-master-controllers", UID:"aca86731-ffbe-11e7-8d33-525400c845a8", APIVersion:"v1",
4897 start_master.go:627] Started serviceaccount-token controller
4897 factory.go:351] Creating scheduler from configuration: {{ } [{NoVolumeZoneConflict <nil>} {MaxEBSVolumeCount <nil>} {MaxGCEPDVolumeCount <nil>} {MaxAzureDiskVolumeCount <nil>} {Mat
4897 factory.go:360] Registering predicate: NoVolumeZoneConflict
4897 plugins.go:145] Predicate type NoVolumeZoneConflict already registered, reusing.
4897 factory.go:360] Registering predicate: MaxEBSVolumeCount
4897 plugins.go:145] Predicate type MaxEBSVolumeCount already registered, reusing.
4897 factory.go:360] Registering predicate: MaxGCEPDVolumeCount

loglevel = 2 の journalctl -u atomic-openshift-master-controllers.service 出力の抜粋

4897 master.go:47] Initializing SDN master of type "redhat/openshift-ovs-subnet"
4897 master.go:107] Created ClusterNetwork default (network: "10.128.0.0/14", hostSubnetBits: 9, serviceNetwork: "172.30.0.0/16", pluginName: "redhat/openshift-ovs-subnet")
4897 start_master.go:690] Started "openshift.io/sdn"
4897 start_master.go:680] Starting "openshift.io/service-serving-cert"
4897 controllermanager.go:466] Started "namespace"
4897 controllermanager.go:456] Starting "daemonset"
4897 controller_utils.go:1025] Waiting for caches to sync for namespace controller
4897 shared_informer.go:298] resyncPeriod 120000000000 is smaller than resyncCheckPeriod 600000000000 and the informer has already started. Changing it to 600000000000
4897 start_master.go:690] Started "openshift.io/service-serving-cert"
4897 start_master.go:680] Starting "openshift.io/image-signature-import"
4897 start_master.go:690] Started "openshift.io/image-signature-import"
4897 start_master.go:680] Starting "openshift.io/templateinstance"
4897 controllermanager.go:466] Started "daemonset"
4897 controllermanager.go:456] Starting "statefulset"
4897 daemoncontroller.go:222] Starting daemon sets controller
4897 controller_utils.go:1025] Waiting for caches to sync for daemon sets controller
4897 controllermanager.go:466] Started "statefulset"
4897 controllermanager.go:456] Starting "cronjob"
4897 stateful_set.go:147] Starting stateful set controller
4897 controller_utils.go:1025] Waiting for caches to sync for stateful set controller
4897 start_master.go:690] Started "openshift.io/templateinstance"
4897 start_master.go:680] Starting "openshift.io/horizontalpodautoscaling

loglevel = 4 の journalctl -u atomic-openshift-master-controllers.service 出力の抜粋

4897 factory.go:366] Registering priority: Zone
4897 factory.go:401] Creating scheduler with fit predicates 'map[GeneralPredicates:{} CheckNodeMemoryPressure:{} CheckNodeDiskPressure:{} Region:{} NoVolumeZoneC
4897 controller_utils.go:1025] Waiting for caches to sync for tokens controller
4897 controllermanager.go:108] Version: v1.7.6+a08f5eeb62
4897 leaderelection.go:179] attempting to acquire leader lease...
4897 leaderelection.go:189] successfully acquired lease kube-system/kube-controller-manager
4897 event.go:218] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"kube-system", Name:"kube-controller-manager", UID:"acb3e9c6-ffbe-11e7-8d33-525400c845a8", APIVersion:"v1", Resou
4897 controller_utils.go:1032] Caches are synced for tokens controller
4897 plugins.go:101] No cloud provider specified.
4897 controllermanager.go:481] "serviceaccount-token" is disabled
4897 controllermanager.go:450] "bootstrapsigner" is disabled
4897 controllermanager.go:450] "tokencleaner" is disabled
4897 controllermanager.go:456] Starting "garbagecollector"
4897 start_master.go:680] Starting "openshift.io/build"
4897 controllermanager.go:466] Started "garbagecollector"
4897 controllermanager.go:456] Starting "deployment"
4897 garbagecollector.go:126] Starting garbage collector controller
4897 controller_utils.go:1025] Waiting for caches to sync for garbage collector controller
4897 controllermanager.go:466] Started "deployment"
4897 controllermanager.go:450] "horizontalpodautoscaling" is disabled
4897 controllermanager.go:456] Starting "disruption"
4897 deployment_controller.go:152] Starting deployment controller

loglevel = 8 の journalctl -u atomic-openshift-master-controllers.service 出力の抜粋

4897 plugins.go:77] Registered admission plugin "NamespaceLifecycle"
4897 start_master.go:290] Warning: assetConfig.loggingPublicURL: Invalid value: "": required to view aggregated container logs in the console, master start will continue.
4897 start_master.go:290] Warning: assetConfig.metricsPublicURL: Invalid value: "": required to view cluster metrics in the console, master start will continue.
4897 start_master.go:290] Warning: aggregatorConfig.proxyClientInfo: Invalid value: "": if no client certificate is specified, the aggregator will be unable to proxy to remote serv
4897 start_master.go:412] Starting controllers on 0.0.0.0:8444 (v3.7.14)
4897 start_master.go:416] Using images from "openshift3/ose-<component>:v3.7.14"
4897 standalone_apiserver.go:106] Started health checks at 0.0.0.0:8444
4897 plugins.go:77] Registered admission plugin "NamespaceLifecycle"
4897 configgetter.go:53] Initializing cache sizes based on 0MB limit
4897 leaderelection.go:105] Attempting to acquire openshift-master-controllers lease as master-bkr-hv03-guest44.dsal.lab.eng.bos.redhat.com-10.19.41.74-xtz6lbqb, renewing every 3s,
4897 leaderelection.go:179] attempting to acquire leader lease...
systemd[1]: Started Atomic OpenShift Master Controllers.
4897 leaderelection.go:189] successfully acquired lease kube-system/openshift-master-controllers
4897 event.go:218] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"kube-system", Name:"openshift-master-controllers", UID:"aca86731-ffbe-11e7-8d33-525400c845a8", APIVersion:"
4897 start_master.go:627] Started serviceaccount-token controller

loglevel = 2 の journalctl -u atomic-openshift-master-api.service 出力の抜粋

4613 plugins.go:77] Registered admission plugin "NamespaceLifecycle"
4613 master.go:320] Starting Web Console https://bkr-hv03-guest44.dsal.lab.eng.bos.redhat.com:8443/console/
4613 master.go:329] Starting OAuth2 API at /oauth
4613 master.go:320] Starting Web Console https://bkr-hv03-guest44.dsal.lab.eng.bos.redhat.com:8443/console/
4613 master.go:329] Starting OAuth2 API at /oauth
4613 master.go:320] Starting Web Console https://bkr-hv03-guest44.dsal.lab.eng.bos.redhat.com:8443/console/
4613 master.go:329] Starting OAuth2 API at /oauth
4613 swagger.go:38] No API exists for predefined swagger description /oapi/v1
4613 swagger.go:38] No API exists for predefined swagger description /api/v1
[restful] 2018/01/22 16:53:14 log.go:33: [restful/swagger] listing is available at https://bkr-hv03-guest44.dsal.lab.eng.bos.redhat.com:8443/swaggerapi
[restful] 2018/01/22 16:53:14 log.go:33: [restful/swagger] https://bkr-hv03-guest44.dsal.lab.eng.bos.redhat.com:8443/swaggerui/ is mapped to folder /swagger-ui/
4613 master.go:320] Starting Web Console https://bkr-hv03-guest44.dsal.lab.eng.bos.redhat.com:8443/console/
4613 master.go:329] Starting OAuth2 API at /oauth
4613 swagger.go:38] No API exists for predefined swagger description /oapi/v1
4613 swagger.go:38] No API exists for predefined swagger description /api/v1
[restful] 2018/01/22 16:53:14 log.go:33: [restful/swagger] listing is available at https://bkr-hv03-guest44.dsal.lab.eng.bos.redhat.com:8443/swaggerapi
[restful] 2018/01/22 16:53:14 log.go:33: [restful/swagger] https://bkr-hv03-guest44.dsal.lab.eng.bos.redhat.com:8443/swaggerui/ is mapped to folder /swagger-ui/
Starting Web Console https://bkr-hv03-guest44.dsal.lab.eng.bos.redhat.com:8443/console/
Starting OAuth2 API at /oauth
No API exists for predefined swagger description /oapi/v1
No API exists for predefined swagger description /api/v1

5.11. マスターおよびノードサービスの再起動

マスターまたはノード設定の変更を適用するには、それぞれのサービスを再起動する必要がります。

マスター設定の変更を再度読み込むには、master-restart コマンドを使用してコントロールプレーンの静的 Pod で実行されているマスターサービスを再起動します。

# master-restart api

ノード設定の変更を再度読み込むには、ノードホストでノードサービスを再起動します。

# systemctl restart atomic-openshift-node

Where did the comment section go?

Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.