第2章 OpenShift Container Platform 3.9 リリースノート

今回のリリースでは、イメージをプルーニングする場合に、実際のイメージを削除する必要なく、etcd ストレージを更新するだけになりました。

--keep-tag-revisions および --keep-younger-than を実行するとより安全です。ソフトプルーニングを実行した後に、管理者は、ハードプルーニングを実行することもできます (レジストリーを読み取り専用モードに設定している限り実行しても安全です)。

OpenShift Container Platform 3.9 のインストール Playbook は、現在公開されている Red Hat CloudForms Management Engine (CFME) 4.6 をサポートするように更新されました。詳細情報は、「Red Hat CloudForms の OpenShift Container Platform へのデプロイ」トピックを参照してください。

さらに、今回のリリースには、以下の新機能および更新が追加されています。

CRI-O は、軽量でネイティブの Kubernetes コンテナーのランタイムインターフェースです。CRI-O は設計的に、kubelet で必要なランタイム機能のみを提供します。また、CRI-O は Kubernetes の一部として設計されており、プラットフォームと同様に進化していきます。

CRI-O は以下を提供します。

docker とともに、CRI-O をインストール、実行するには、クラスターのインストール時に、「Ansible インベントリーファイル」の [OSEv3:vars] セクションに以下を設定します。

openshift_use_crio=true
openshift_crio_use_rpm=true 1

CRI-O の使用が有効になった場合に、docker と一緒にインストールされます。現在、これには、ビルドを実行して操作をレジストリーにプッシュする必要があります。時間が経つにつれ、一時的な docker ビルドがノードに累積する可能性があります。オプションで、以下を設定してガーベッジコレクションを有効にし、ビルドを消去する deamonset を追加することも可能です。

openshift_crio_enable_docker_gc=true

これが有効な場合には、デフォルトで全ノードにガーベッジコレクションが実行されます。以下を設定して、固有のノードに対する deamonset の実行を制限することもできます。

openshift_crio_docker_gc_node_selector={'runtime': 'cri-o'}

たとえば、上記を設定することで、runtime: cri-o のラベルが指定されたノードでのみ実行されるようになります。これは、「一部のノード」でのみ CRI-O を実行していて、他は docker のみを実行している場合に便利です。

CRI-O に関する詳細は、「アップストリームのドキュメント」を参照してください。

CNS glusterFS、Cinder および GCE PD 向けに、OpenShift Container Platform からオンラインで Persistent Volume Claim (永続ボリューム要求、PVC) を拡張できます。

CNS glusterFS ボリューム向けに、OpenShift Container Platform からオンラインで Persistent Volume Claim (永続ボリューム要求、PVC) を拡張できます。

これは、OpenShift Container Platform からオンラインで設定できます。以前のリリースでは、Heketi CLI からしか利用できませんでした。新しいサイズに PVC を設定して、PV のサイズ変更をトリガーします。これは、glusterFs でバックされる PV も完全に対応しています。Gluster ブロックの PV のサイズ変更は、RHEL 7.5 で追加されました。

Container Native Storage GlusterFS は、Prometheus または Query 経由で、(消費量を含む) ボリュームメトリクスを提供するように拡張されました。

メトリクスは、PVC エンドポイントから利用できます。これにより、何が割り当てられ、消費されたのかが視覚的に分かるようになります。以前のリリースでは、割り当てられた PV のサイズしか表示されませんでしたが、今回のリリースでは、実際に消費された量が分かるようになったので、必要に応じて、容量が無くなる前に拡張できるようになりました。これにより、管理者は必要に応じて、消費をベースに課金できるようになりました。

追加されたメトリクスの例は以下のとおりです。

OpenShift Container Platform の標準インストーラーでは、CNS ブロックプロビジョナーデプロイメントが修正されて、CNS のアンインストール Playbook が追加されました。これにより、OpenShift Container Platform での CNS ブロックデプロイメントの問題が解決され、失敗した CNS インストールを削除できるようになりました。

CNS ストレージデバイスの詳細がインストーラーのインベントリーファイルに追加され、標準インストーラーは CNS、ファイル、ブロックプロビジョナー、レジストリー、使用準備のできた PV の設定およびデプロイメントの管理ができるようになりました。

テナント駆動型のストレージのスナップショット機能は現在 テクノロジープレビュー として提供されており、実稼働環境のワークロードには適していません。

テナントは、アプリケーションデータのスナップショットを作成するために割り当てられる、永続ボリューム (PV) をバックする基盤のストレージ技術を活用できるようになりました。またテナントは、以前のアプリケーションから現在のアプリケーションに指定のスナップショットを復元できるようになりました。

外部プロビジョナーは、EBS、GCE pDisk および HostPath、 Cinder スナップショット API にアクセスするために使用します。このテクノロジープレビュー機能では、EBS と HostPath をテストしました。テナントは、手動で pod を停止して、起動する必要があります。

OpenShift Container Platform 3.9 の クラスター制限 に関するガイドが更新され、ご利用いただけるようになりました。

この機能は現在、テクノロジープレビュー として提供されており、実稼働環境のワークロードには適していません。

デバイスプラグインを使用すると、カスタムコードを作成せずに特定のデバイスタイプ (GPU、InfiniBand、またはベンダー固有の初期化およびセットアップを必要とする他の同様のコンピューティングリソース) を OpenShift Container Platform Pod で使用できます。デバイスプラグインは、クラスター全体でハードウェアデバイスを消費するための一貫性のある移植可能なソリューションを提供します。デバイスプラグインはこれらのデバイスのサポートを拡張メカニズムでサポートします。これにより、これらのデバイスはコンテナーで利用可能となり、デバイスのヘルスチェックやセキュリティーが保護された状態でのデバイスの共有が可能になります。

デバイスプラグインは、ノード上で実行される gRPC サービスで (atomic-openshift-node.service の外部にあります)、特定のハードウェアリソースを管理します。

デバイスプラグインのコンセプトに関する詳細情報は、『開発者ガイド』を参照してください。

CPU マネージャーは現在、テクノロジープレビュー として提供されており、実稼働環境のワークロードには適していません。

CPU マネージャーは、CPU グループを管理して、ワークロードを固有の CPU に制限します。

CPU マネージャーは、以下のような属性が含まれるワークロードに有用です。

詳細情報は、「CPU マネージャーの使用」を参照してください。

デバイスマネージャーは現在、テクノロジープレビュー として提供されており、実稼働環境のワークロードには適していません。

ユーザーによっては、pod の定義にハードウェアデバイスのリソース制限を設定し、スケジューラーを使用して、これらのリソースが指定されたクラスター内でノードを検出する場合があります。同時に、Kubernetes には、ハードウェアベンダーが Kubernetes 内のコアコードを強制的に変更せずに kubelet にリソースを宣言する方法が必要です。

kubelet には、プラグインで拡張可能なデバイスマネージャーが追加されました。ドライバーサポートは、ノードレベルで読み込ませます。次に、ドライバーに表示される要求済みのハードウェアリソースを停止/開始/アタッチ/割り当てる要求をリッスンするプラグインを、ユーザーまたはベンダーが記述します。このプラグインは、daemonSet 経由で全ノードにデプロイされます。

詳細情報は、「デバイスマネージャーの使用」を参照してください。

ヒュージページは現在、テクノロジープレビュー として提供されており、実稼働環境のワークロードには適していません。

メモリーは、ページと呼ばれるブロックで管理されます。多くのシステムでは、1 ページは 4Ki です。メモリー 1Mi は 256 ページに、メモリー 1Gi は 256,000 ページに相当します。CPU には、内蔵のメモリー管理ユニットがあり、ハードウェアでこのようなページリストを管理します。トランスレーションルックアサイドバッファー (TLB: Translation Lookaside Buffer) は、仮想から物理へのページマッピングの小規模なハードウェアキャッシュのことです。ハードウェアの指示で渡された仮想アドレスが TLB にあれば、マッピングをすばやく決定できます。ない場合には、TLB ミスが発生し、システムは速度が遅く、ソフトウェアベースのアドレス変換にフォールバックされ、パフォーマンスの問題が発生します。TLB のサイズが固定されているので、ページサイズを増やすしか、TLB ミスの割合を減らす方法はありません。

ヒュージページとは、4Ki より大きいメモリーページのことです。x86_64 アーキテクチャーでは、2Mi と 1Gi の 2 つが一般的なヒュージページサイズです。別のアーキテクチャーではサイズは異なります。ヒュージページを使用するには、アプリケーションが認識できるように、コードを書き込む必要があります。Transparent Huge Pages (THP) は、アプリケーションによる認識なしに、ヒュージページの管理を自動化しようとしますが、制約があります。特に、ページサイズは 2Mi に制限されます。THP では、THP のデフラグが原因で、メモリー使用率が高くなり、断片化が起こり、パフォーマンスの低下に繋がり、メモリーページがロックされてしまう可能性があります。このような理由から、アプリケーションは THP ではなく、事前割り当て済みのヒュージページを使用するように設計 (また推奨) される場合があります。

OpenShift Container Platform では、pod のアプリケーションが事前割り当て済みのヒュージページを割り当て、消費できます。

詳細情報は、「ヒュージページの管理」を参照してください。

外部のファイアウォールがパケットに関連付けられたアプリケーションを認識できるように、プロジェクトから発信される外部接続はすべて、単一で固定のソース IP アドレスを共有し、この IP を使用して全トラフィックを送信します。

namespace 別の egress IP 自動設定機能を実装するプロセスでは、最初の半分で「トラフィック」側の実装が行われるので、半自動 とされています。egress IP が自動指定された namespace は、その IP 経由で全トラフィックを送信します。ただし、「管理」側の実装はされません。ノードへの egress IP の設定は自動的に行われないので、管理者は手動でこの設定を行う必要があります。

詳細情報は、「ネットワークの管理」を参照してください。

負荷の多い状態で実行されるルート設定の変更およびプロセスのアップグレードでは通常、特定のサービスを停止、開始するシーケンスが必要となり、一時的にサービスが停止されていました。

OpenShift Container Platform 3.9 では、HAProxy 1.8 は更新とアップグレードを別物とみなさないので、新規設定には新規プロセスが使用され、リッスンするソケットのファイル記述子は、以前のプロセスから新しいプロセスに移行されるので、接続は切断されなくなりました。変更はシームレスに行われ、今後 HTTP/2 などにも対応できるようになっています。

OpenShift Container Platform では、statefulsets、daemonsets および deployments がテクノロジープレビューではなく、サポートありの安定版になりました。

管理者が確認を希望する監査項目が追加されました。以下に例を示します。

管理者が追跡を希望する監査項目が追加されました。以下に例を示します。

master-config file で監査機能を設定して、master-config サービスを再起動します。

auditConfig:
  auditFilePath: "/var/log/audit-ocp.log"
  enabled: true
  maximumFileRetentionDays: 10
  maximumFileSizeMegabytes: 10
  maximumRetainedFiles: 10
  logFormat: json
  policyConfiguration: null
  policyFile: /etc/origin/master/audit-policy.yaml
  webHookKubeConfig: ""
  webHookMode:

ログ出力の例:

{"kind":"Event","apiVersion":"audit.k8s.io/v1beta1","metadata":{"creationTimestamp":"2017-09-29T09:46:39Z"},"level":"Metadata","timestamp":"2017-09-29T09:46:39Z","auditID":"72e66a64-c3e5-4201-9a62-6512a220365e","stage":"ResponseComplete","requestURI":"/api/v1/securitycontextconstraints","verb":"create","user":{"username":"system:admin","groups":["system:cluster-admins","system:authenticated"]},"sourceIPs":["10.8.241.75"],"objectRef":{"resource":"securitycontextconstraints","name":"scc-lg","apiVersion":"/v1"},"responseStatus":{"metadata":{},"code":201}}

oc status コマンドでは、現在のプロジェクトの概要が分かります。これにより、デプロイメントセットがネスト化されているダウンストリームの DeploymentConfigs で見られるのと同様のアップストリームデプロイメントの出力が表示されます。

$ oc status
In project My Project (myproject) on server https://127.0.0.1:8443

svc/ruby-deploy - 172.30.174.234:8080
  deployment/ruby-deploy deploys istag/ruby-deploy:latest <-
    bc/ruby-deploy source builds https://github.com/openshift/ruby-ex.git on istag/ruby-22-centos7:latest
      build #1 failed 5 hours ago - bbb6701: Merge pull request #18 from durandom/master (Joe User <joeuser@users.noreply.github.com>)
    deployment #2 running for 4 hours - 0/1 pods (warning: 53 restarts)
    deployment #1 deployed 5 hours ago

これを OpenShift Container Platform 3.7 の出力と比較します。

$ oc status
In project dc-test on server https://127.0.0.1:8443

svc/ruby-deploy - 172.30.231.16:8080
  pod/ruby-deploy-5c7cc559cc-pvq9l runs test

Dynamic Admission Controller Follow-up は現在、テクノロジープレビュー として提供されており、実稼働環境のワークロードには適していません。

受付コントローラーは、要求が認証および承認されてから、オブジェクトの永続化される前に Kubernetes API サーバーへの要求をインターセプトするコードです。ユースケースの例として、pod リソースおよびセキュリティーの対応の変更などが挙げられます。

詳細情報は、「Custom Admission Controllers」を参照してください。

プラットフォームの管理者は、プラットフォーム全体で特定の機能をオフにできるようになりました。これにより、実稼働のクラスターでのアルファ、ベータまたはテクノロジープレビュー機能へのアクセスを制御しやすくなります。

Feature gates は、マスターおよび kubelet 設定ファイルで key=value ペアを使用してブロックする機能を記述します。

kubernetesMasterConfig:
  apiServerArguments:
    feature-gates:
    - CPUManager=true

kubeletArguments:
  feature-gates:
  - DevicePlugin=true

OpenShift Container Platform 3.9 では、パフォーマンスを向上するため、Playbook を大幅にリファクタリングおよび再構成しました。これには以下が含まれます。

クイックインストールは OpenShift Container Platform 3.9 では非推奨となっており、今後のリリースでは完全に削除されます。

クイックインストールでは、3.9 のみをインストールでき、3.7 または 3.8 から 3.9 へのアップグレードには使用できません。

インストーラーは、コントロールプレーンを 3.7 から 3.8 へ、3.8 から 3.9 に順を追って自動的にアップグレードし、ノードは 3.7 から 3.9 にアップグレードします。

コントロールプレーンのコンポーネント (API、コントローラー、コントローラープレーンホストのノード) は 3.7 から 3.8、さらに 3.9 にシームレスにアップグレードされます。データの移行は、OpenShift Container Platform 3.8 および 3.9 のコントロールプレーンのアップグレード前と後に行われます。他のコントロールプレーンのコンポーネント (ルーター、レジストリー、サービスカタログ、ブローカー) は OpenShift Container Platform 3.7 から 3.9 にアップグレードされ、ノード (ノード、docker、ovs) は、一度だけドレインされるだけで、OpenShift Container Platform 3.7 から 3.9 に直接アップグレードされます。この状態でアップグレードプロセスを一時停止する必要がある場合には、OpenShift Container Platform 3.7 ノードは、3.8 のマスターに対していつまでも操作が行われます。ロギングおよびメトリクスは OpenShift Container Platform 3.7 から 3.9 にアップグレードされます。

コントロールプレーンとノードは別個でアップグレードすることを推奨します。オールインワン (all-in-one) の playbook でアップグレードすることも可能ですが、ロールバックがより困難になります。playbook では、OpenShift Container Platform 3.8 のクリーンインストールはできません。

詳細情報は、「クラスターのアップグレード」を参照してください。

Docker ログドライバーは、全ノードのデフォルトとして、json-file に設定されています。Docker log-driver は、journal に設定可能ですが、ジャーナルドライバーにはログ回転スロットルがありません。そのため、不正なコンテナーから DoS 攻撃を受けるリスクが常にあります。

Fluentd は自動的に、コンテナーのランタイムが使用するログドライバーを判断します (journald または json-file)。Fluentd は journald および /var/log/containers (log-driver が json-file に設定されている場合) から常にログを読み込みます。Fluentd は /var/log/messages からのログの読み込みはなくなりました。

詳細情報は、「コンテナーログの累積」 を参照してください。

fluentd 向けの syslog 出力プラグインは現在、テクノロジープレビュー として提供されており、実稼働環境のワークロードには適していません。

システムおよびコンテナーログは OpenShift Container Platform ノードから外部のエンドポイントに syslog プロトコルを使用して送信できます。fluentd syslog 出力プラグインはこの機能をサポートします。

詳細情報は、「外部 syslog サーバーへのログの送信」を参照してください。

Prometheus は依然として、テクノロジープレビュー として提供されており、実稼働環境のワークロードには適していません。Prometheus、AlertManager および AlertBuffer のバージョンは更新され、node-exporter も追加されました。

OpenShift Container Platform クラスターに Prometheus をデプロイし、Kubernetes およびインフラストラクチャーのメトリクスを収集して、アラートを取得できます。Prometheus web ダッシュボードでメトリクスおよびアラートを表示、照会できます。または、独自の Grafana を用意して、Prometheus に連携させることも可能です。

詳細情報は、「OpenShift 上の Prometheus」を参照してください。

以前のリリースでは、Jenkins ワーカー pod はメモリーを過剰または過小に消費することが頻繁にありました。今回のリリースでは、起動スクリプトがインテリジェントに、適切に設定された pod の制限および環境変数を確認して、JVM の起動時に制限が尊重されるようになりました。

CLI プラグインは現在、テクノロジープレビュー として提供されており、実稼働環境のワークロードには適していません。

通常、プラグイン または バイナリー拡張 と呼ばれるこの機能は、利用可能なデフォルトの oc コマンドを拡張するので、新たなタスクが実行できます。

CLI の拡張のインストールおよび記述の方法に関する情報は、「Extending the CLI」を参照してください。

以前のリリースでは、ビルド固有のノードに配置できるように、ビルドされた pod でデフォルトの toleration を設定する方法がありませんでした。ビルドの Defaulter が更新され、toleration の値を指定できるようになり、作成時にビルド pod に適用されます。

詳細情報は、「グローバルビルドのデフォルト設定および上書きの設定」を参照してください。

OpenShift Container Platform は、eviction-hard の以下のデフォルト設定を使用します。

...
kubeletArguments:
  eviction-hard:
  - memory.available<100Mi
  - nodefs.available<10%
  - nodefs.inodesFree<5%
  - imagefs.available<15%
...

詳細情報は、「Out of Resource (リソース不足) エラーの処理」 を参照してください。

左側のナビゲーションにある Catalog をクリックして、プロジェクト内からカタログにすばやく移動できます。

プロジェクトビューからすばやくサービスを検索するには、検索基準を入力します。

ログイン後に直接特定のページに移動できるようになりました。アカウントのドロップダウンメニューからメニューにアクセスして、希望のオプションを選択してから、再度ログインしなおします。

設定したタイムアウトの期間が経過した後にユーザーをログアウトするように、Web コンソールを設定できるようになりました。デフォルトは 0 (タイムアウトなし) です。Ansible の変数 を分単位で設定します。

openshift_web_console_inactivity_timeout_minutes=n

Web コンソールは、API サーバーから分離されました。Web コンソールはコンテナーイメージとしてパッケージされ、pod としてデプロイされます。ConfigMap で設定します。変更は自動的に検出されます。

マスターはスケジュール可能で、Web コンソールのデプロイメントが機能するようにスケジュール可能にする必要があります。

既存の OpenShift Container Platform 3.7 または 3.9 クラスターを最新のこのリリースにアップグレードするには、自動アップグレード playbook を使用します。説明は、「クラスターの自動インプレースアップグレードの実行」を参照してください。

今回のリリースでは、以下のイメージで Red Hat コンテナーレジストリー (registry.access.redhat.com) を更新しました。

openshift3/apb-base:v3.9.30-2
openshift3/container-engine:v3.9.30-2
openshift3/cri-o:v3.9.30-2
openshift3/image-inspector:v3.9.30-2
openshift3/jenkins-2-rhel7:v3.9.30-2
openshift3/jenkins-slave-base-rhel7:v3.9.30-2
openshift3/jenkins-slave-maven-rhel7:v3.9.30-2
openshift3/jenkins-slave-nodejs-rhel7:v3.9.30-2
openshift3/local-storage-provisioner:v3.9.30-2
openshift3/logging-auth-proxy:v3.9.30-2
openshift3/logging-curator:v3.9.30-2
openshift3/logging-elasticsearch:v3.9.30-2
openshift3/logging-eventrouter:v3.9.30-2
openshift3/logging-fluentd:v3.9.30-2
openshift3/logging-kibana:v3.9.30-3
openshift3/mariadb-apb:v3.9.30-2
openshift3/mediawiki-123:v3.9.30-2
openshift3/mediawiki-apb:v3.9.30-2
openshift3/metrics-cassandra:v3.9.30-2
openshift3/metrics-hawkular-metrics:v3.9.30-2
openshift3/metrics-hawkular-openshift-agent:v3.9.30-2
openshift3/metrics-heapster:v3.9.30-2
openshift3/mysql-apb:v3.9.30-2
openshift3/node:v3.9.30-2
openshift3/oauth-proxy:v3.9.30-2
openshift3/openvswitch:v3.9.30-2
openshift3/ose-ansible-service-broker:v3.9.30-2
openshift3/ose-ansible:v3.9.30-3
openshift3/ose-cluster-capacity:v3.9.30-2
openshift3/ose-deployer:v3.9.30-2
openshift3/ose-docker-builder:v3.9.30-2
openshift3/ose-docker-registry:v3.9.30-2
openshift3/ose-egress-http-proxy:v3.9.30-2
openshift3/ose-egress-router:v3.9.30-2
openshift3/ose-f5-router:v3.9.30-2
openshift3/ose-haproxy-router:v3.9.30-2
openshift3/ose-keepalived-ipfailover:v3.9.30-2
openshift3/ose-pod:v3.9.30-2
openshift3/ose-recycler:v3.9.30-2
openshift3/ose-service-catalog:v3.9.30-2
openshift3/ose-sti-builder:v3.9.30-2
openshift3/ose-template-service-broker:v3.9.30-2
openshift3/ose-web-console:v3.9.30-2
openshift3/ose:v3.9.30-2
openshift3/postgresql-apb:v3.9.30-2
openshift3/prometheus-alert-buffer:v3.9.30-2
openshift3/prometheus-alertmanager:v3.9.30-2
openshift3/prometheus-node-exporter:v3.9.30-2
openshift3/prometheus:v3.9.30-2
openshift3/registry-console:v3.9.30-2
openshift3/snapshot-controller:v3.9.30-2
openshift3/snapshot-provisioner:v3.9.30-2

既存の OpenShift Container Platform 3.7 または 3.9 クラスターを最新のこのリリースにアップグレードするには、自動アップグレード playbook を使用します。説明は、「クラスターの自動インプレースアップグレードの実行」を参照してください。

既存の OpenShift Container Platform 3.7 または 3.9 クラスターを最新のこのリリースにアップグレードするには、自動アップグレード playbook を使用します。説明は、「クラスターの自動インプレースアップグレードの実行」を参照してください。

既存の OpenShift Container Platform 3.6 または 3.7 クラスターを最新のこのリリースにアップグレードするには、自動アップグレード playbook を使用します。説明は、「クラスターの自動インプレースアップグレードの実行」を参照してください。