2.5. バグ修正
今回のリリースでは、以下のコンポーネントのバグが修正されました。
ビルド
- ConfigMap ビルドソースを使用して、シークレットよりも透過的で使いやすい ConfigMap をビルドソースとして使用できます。ConfigMap はすべての OpenShift ビルドに挿入できます。(BZ#1540978)
- Out Of Memory (OOM) で強制終了したビルド Pod についての情報がビルドオブジェクトに伝播します。この情報は、デバッグを単純化し、失敗の理由がユーザーに説明される場合に問題点を発見するのに役立ちます。ビルドコントローラーは、ビルド Pod が OOM で強制的に終了する場合に、ステータスの理由およびメッセージを適切に設定します。(BZ#1596440)
- ビルドステータスを更新するロジックでは、ビルドログの末尾を含むログスニペットの更新はビルドの状態が失敗した状態に変更された後にのみ実行されていました。ビルドが失敗した状態に移行してから、再度ログスニペットで更新が行われます。これは、ビルドが失敗した状態になるのを監視するコードは最初に設定されるログスニペットの値を認識しないことを意味します。今回のバージョンでは、このコードはビルドが失敗した状態に移行する際にログスニペットのフィールドにデータを設定するように変更されており、ビルドの更新に失敗した情報とログスニペットの両方が含まれるようになりました。ビルドが失敗した状態に移行することを監視するコードは、 その後の更新ではなく、ビルドを失敗状態に移行した更新の一部としてログスニペットを認識するようになりました。(BZ#1596449)
-
ジョブが
JenkinsPipelineStrategyビルドストラテジーを使用している場合、プルーニング設定は無視されていました。その結果、successfulBuildsHistoryLimitおよびfailedBuildsHistoryLimitを設定しても古いジョブは正常にプルーニングされませんでした。コードがジョブを正常にプルーニングするように変更されています。(BZ#1543916)
クラウドコンピュート
-
インストール時に NetworkManager で
dns=noneを設定できるようになりました。この設定は、通常 OpenShift Container Platform を Microsoft Azure にデプロイする際に使用されますが、他のシナリオでも役立ちます。これを設定するには、openshift_node_dnsmasq_disable_network_manager_dns=trueを設定します。(BZ#1535340)
イメージ
- 以前のバージョンでは、空のイメージストリームの更新が適切に処理されないことにより、タグの変更につながらないイメージストリームの更新で、インポートするコンテンツがない場合でもイメージインポート API に対する要求が生じました。これは無効な要求であり、コントローラーにエラーを発生させました。現時点では、インポートする必要のある新規または更新タグが関係しないイメージストリームの更新によってインポート API 呼び出しが発生しなくなりました。(BZ#1613979)
- イメージのプルーニングは、Blob の削除中に予期しないエラーが発生すると停止していました。イメージの削除エラーの発生時に、イメージプルーニングはイメージオブジェクトを etcd から削除できませんでした。イメージは別個のジョブで同時にプルーニングされるようになりました。その結果として、イメージプルーニングは、単一の予期しない Blob 削除の失敗によって停止されなくなりました。(BZ#1567657)
インストーラー
-
AWS へのデプロイ時に、
build_amiplay は /var/lib/cloud のクリーニングに失敗していました。クリーンではない /var/lib/cloud ディレクトリーにより、cloud-init は実行を省略します。実行を省略すると、新規にデプロイされたノードがブートストラップに失敗し、OpenShift Container Platform への自動登録に失敗します。今回のバグ修正により、/var/lib/cloudディレクトリーはseal_amiplay の実行時にクリーニングされるようになりました。(BZ#1599354) -
インストーラーは、デフォルトでルーターの拡張ルート検証を有効にします。この検証は、追加の検証およびルートの TLS 設定および証明書のサニテーションを実行します。拡張ルート検証は OpenShift Container Platform 3.3 でルーターに追加され、OpenShift Container Platform 3.6 で証明書のサニテーションと共に機能が拡張されました。ただし、インストーラーでは拡張ルート検証を有効にしていませんでした。当初は、検証が厳格過ぎて有効なルートおよび証明書までも拒否される可能性があるので、デフォルトで無効にされていました。しかし、後に新規インストールでこれをデフォルトで有効にしても安全だと判断されました。そのため、拡張ルート検証は新規クラスターでデフォルトで有効にされています。これは、Ansible インベントリーに
openshift_hosted_router_extended_validation=Falseを設定すると無効にできます。既存クラスターのアップグレードでは、拡張ルート検証が有効になりません。(BZ#1542711) - ロードバランサーサービスが OpenShift Container Platform で要求される際の完全に定義された azure.conf ファイルがないと、ロードバランサーは外部 IP アドレスを完全に登録し、指定することができません。azure.conf と必要なすべての変数を使用して、ロードバランサーをデプロイでき、外部 IP アドレスを指定できるようになりました。(BZ#1613546)
CRI-O を OpenShift Container Platform のコンテナーランタイムとして使用することを容易にするために、 node-config.yaml ファイルを正しいエンドポイントの設定で更新します。
openshift_node_groupsのデフォルト値は、既存デフォルトノードグループのそれぞれについての CRI-O バリアントを組み込むように拡張されています。コンピュートノードのグループに CRI-O ランタイムを使用するには、以下のインベントリー変数を使用します。-
openshift_use_crio=True openshift_node_group_name="node-config-compute-crio"さらに、Docker ガーベッジコレクター
docker gcをデプロイするには、以下の変数をTrueに設定する必要があります。今回のバグ修正により、以前の変数のデフォルト値がTrueからFalseに変更されています。-
openshift_crio_enable_docker_gc=True(BZ#1615884)
-
-
openshift-ansibleと共に配信される ansible.cfg ファイルは、~/openshift-ansible.log のデフォルトのログパスを設定します。これにより、ログがデフォルトで予測可能な位置に書き込まれることになります。配信される ansible.cfg ファイルを使用するには、ディレクトリーを /usr/share/ansible/openshift-ansible に切り替えてから Ansible Playbook を実行する必要があります。この ansible.cfg ファイルは、openshift-ansibleのパフォーマンスおよび信頼性を強化するための他のオプションも設定します。(BZ#1458018) -
動的ストレージプロビジョニングを使用して Prometheus をマルチゾーンまたはリージョンクラスターにインストールすることにより、Prometheus Pod がスケジュール対象外になる可能性があります。Prometheus Pod には、Prometheus サーバー用の物理ボリューム、Alertmanager 用の物理ボリューム、およびアラートバッファー用の物理ボリュームの 3 つの物理ボリュームが必要です。動的ストレージのあるマルチゾーンクラスターでは、これらの内の 1 つ以上のボリュームが他とは異なるゾーンに割り当てられる可能性があります。これにより、Prometheus Pod はスケジュール対象外になります。クラスター内の各ノードはそれぞれのゾーン内の物理ボリュームのみにしかアクセスできないためです。そのため、いずれのノードも Prometheus Pod を実行できず、これら 3 つの物理ボリュームにアクセスできません。推奨されるソリューションとして、
zone:パラメーターを使用してボリュームを単一ゾーンに制限するストレージクラスを作成し、このストレージクラスを、Ansible インストーラーのインベントリー変数openshift_prometheus_<COMPONENT>_storage_class=<zone_restricted_storage_class>を使用して Prometheus ボリュームに割り当てることができます。このの回避策では、3 つのボリュームすべてが同じゾーンまたはリージョンで作成され、Prometheus Pod が自動的に同じゾーン内のノードにスケジューリングされます。(BZ#1554921)
ロギング
-
以前のバージョンでは、
openshift-ansible installerはshared_opsおよびuniqueのみを Kibana のインデックス方法としてサポートしていました。今回のバグ修正により、非 ops EFK クラスターのユーザーが Kibana のデフォルトインデックスを共有し、クエリー、ダッシュボードなどを共有できるようになりました。(BZ#1608984) - ES5 スタックのインストールの一環として、ユーザーは ES が実行されるノードに sysctl ファイルを作成する必要があります。今回のバグ修正により、タスクを実行する対象のノード/Ansible ホストが評価されるようになりました。(BZ#1609138)
- 追加設定なしのメモリーからの定期的な再起動を防ぐために、Prometheus メトリクスおよび再試行キューのサポートに追加のメモリーが必要です。今回のバグ修正では、Fluentd の追加設定なしのメモリーが増設されています。その結果、Fluentd Pod では追加設定なしのメモリー再起動が回避されます。(BZ#1590920)
- Fluentd は、デフォルトで 100 回の操作ごとに Elasticsearch に再接続するようになりました。1 つの Elasticsearch がクラスター内の他のメンバーの前に起動すると、Elasticsearch サービスのロードバランサーがその 1 つの Elasticsearch にのみ接続し、Elasticsearch に接続しようとするすべての Fluentd もこれを実行しました。今回の機能強化で Fluentd の定期的な再接続が可能になることにより、ロードバランサーはクラスター内のすべての Elasticsearch 間で負荷を均等に分散できるようになります。(BZ#1489533)
-
rubygem ffi 1.9.25 では、SELinux
deny_execmem=1が設定されたシステムでの機能を可能にするパッチが元に戻されました。これにより、Fluentd のクラッシュが発生していました。今回のバグ修正でパッチが元に戻されることにより、Fluentd は SELinuxdeny_execmem=1を使用する場合もクラッシュしなくなりました。(BZ#1628407)
管理コンソール
- ログビューアーは、複数行または部分的な行の応答に適切は対応していませんでした。応答に複数行のメッセージが含まれる場合、これは単一行として付加され、処理されていたため、行数が不正確に表示されました。同様に部分的な行が受信されると、それが完全な行として処理され、より長いログの行が複数行に分割されて行数が正しくなくなることがありました。今回のバグ修正により、ログビューアーの複数行および部分的な行の応答に対応するためのロジックが追加されました。その結果、行数が正確に表示されるようになりました。(BZ#1607305)
モニターリング
-
9100ポートは、デフォルトですべてのノードでブロックされていました。Prometheus は、ポート9100でリッスンする他のノードで実行されているnode_exporterサービスを収集できませんでした。今回のバグ修正により、ファイアウォール設定が、9000-1000ポート範囲の着信 TCP トラフィックを許可するように変更されました。その結果、Prometheus はnode_exporterサービスを収集できるようになりました。(BZ#1563888) -
node_exporterは、デフォルトで有効にされているwifiコレクターと共に起動します。wifiコレクターには有効にされていない SELinux パーミッションが必要なため、node_exporterを停止させることはなくても AVC 拒否が生じます。今回のバグ修正により、node_exporterはwifiコレクターが明示的に無効にされた状態で起動するようになりました。結果として SELinux は AVC 拒否を報告することがなくなりました。(BZ#1593211) -
現時点で Prometheus をアンインストールすると、
openshift-metricsnamespace 全体が削除されます。これは、同じ namespace にあるが Prometheus インストールの一部ではないオブジェクトを削除する可能性があります。今回のバグ修正ではアンインストールプロセスが変更され、Prometheus インストールで作成された特定のオブジェクトのみを削除し、残りのオブジェクトがない場合に namespace を削除するようになりました。(BZ#1569400)
Pod
-
以前のバージョンでは、Kubernetes のバグにより、Pod がエラーを返すと
kubectl drainが停止していました。Kubernetes の修正 により、コマンドは Pod がエラーを返してもハングしなくなりました。(BZ#1586120)
ルーティング
- dnsmasq はこれまで OpenShift Extended Comformance Test および Node Vertical Test の後に利用可能なファイル記述子を過剰に使用し、dmsmasq はハングし、新規 Pod は作成されていませんでした。コードに変更が加えられることにより、オープンなファイル記述子の最大数が増え、ノードがテストにパスできるようになりました。(BZ#1608571)
-
62 以上の IP アドレスがルートの
haproxy.router.openshift.io/ip_whitelistアノテーションを使用して指定されると、ルーターではコマンドの最大パラメーター数 (63) を超過するためにエラーが生じ、ルーターの再読み込みが行われません。ルーターは再読み込みされません。コードはホワイトリストにある IP 数が多すぎる場合にオーバーフローマップを使用し、マップを HA-proxy ACL に渡すように変更されました。(BZ#1598738) -
設計上の性質により、
set route-backendを0に設定してサービスを設定する際、複数のサービスを持つルーターを使用すると、重みの値により既存の接続および関連付けられたエンドユーザーの接続すべてがドロップされました。今回のバグ修正により、値0がサーバーはロードバランシングに参加しないが、継続した接続を依然として受け入れることを意味するようになりました。(BZ#1584701) -
liveness probe および reainess probe は、存続している Pod と準備状態にある Pod を区別できないため、
ROUTER_BIND_PORTS_AFTER_SYNC=trueが設定されたルーターは失敗として報告されました。今回のバグ修正により、liveness および readiness probe は別々の probe に分けられました。そのため、ルーター Pod は存続しているものの、準備状態にない場合も想定できるようになりました。(BZ#1550007) - HAproxy ルーターに多数のルート (10,000 以上) が含まれる場合、ルーターはパフォーマンスが低くなることから liveness および readiness をパスせず、ルーターが繰り返し強制終了されます。この問題の根本的な原因として、ヘルスチェックをデフォルトの readiness および liveness の検出サイクル内に完了できない点が考えられす。この問題は、probe の間隔を広げることで防ぐことができます。(BZ#1595513)
サービスブローカー
- Ansible Service Broker のプロビジョニング解除プロセスでは、シークレットを openshift-ansible-service-broker プロジェクトから削除しませんでした。今回のバグ修正により、コードは、Ansible Service Broker のプロビジョニング解除時にすべての関連付けられたシークレットを削除するように変更されました。(BZ#1585951)
- 以前のバージョンでは、ブローカーの調整機能では更新された情報をレジストリーから取得する前にイメージの参照を削除し、他のジョブが実行中の場合でも、一定期間が経過してからレコードがブローカーのデータストアに表示されました。この調整機能は、変更されたアイテムのインプレース更新を実行できるように再設計されました。レジストリーから削除されたアイテムについては、ブローカーはすでにプロビジョニングされていないもののみを削除します。また、それらのアイテムに削除のマークを付け、それらを UI でフィルターし、それらのアイテムが今後プロビジョニングされるのを防ぎます。ブローカーの調整機能により、レジストリーの変更に対するプロビジョニングおよびプロビジョニング解除の回復力が強化されます。(BZ#1577810)
-
以前のバージョンでは、アイテムが見つからないと、見つからないのが正常な場合であってもエラーメッセージがユーザーに表示されました。その結果として、正常なジョブでエラーメッセージのログが記録され、問題がないのに問題がある可能性についてユーザーの懸念を起こさせる可能性がありました。メッセージのロギングレベルは
errorからdebugに変更されました。このようなメッセージは実稼働環境のインストール (通常レベルはinfo以上に設定されます) では役に立たない場合でも、デバッグ目的では依然として役に立つためです。その結果、実際に問題がない限り、インスタンスが見つからない時のエラーメッセージが表示されなくなります。(BZ#1583587) -
クラスターが実行されていないか、または到達不可である場合、
svcat versionコマンドはエラーを出しました。コードは、常にクライアントのバージョンを報告し、サーバーに到達可能な場合はサーバーのバージョンを報告するように変更されています。(BZ#1585127) -
一部のシナリオでは、
svcat deprovision <service-instance-name> --waitコマンドを使用すると、svcatコマンドがパニックエラーを出して終了してしまうことがありました。これが生じると、deprovisionコマンドが実行され、プログラムでインスタンスの完全なプロビジョニング解除を待機する際にコードのバグが生じました。この問題は解決されています。(BZ#1595065)
ストレージ
- 以前のバージョンでは、kubelet システムコンテナーは /var/lib/iscsi ディレクトリーに書き込むことができなかったため、 iSCSI ボリュームを割り当てることはできませんでした。ホスト /var/lib/iscsi は kubelet システムコンテナーにマウントでき、iSCSI ボリュームを割り当てることができるようになりました。(BZ#1598271)
