2.8. エラータの非同期更新
OpenShift Container Platform 3.11 のセキュリティー、バグ修正、拡張機能の更新は、Red Hat Network 経由で非同期エラータとして発表されます。OpenShift Container Platform 3.11 のすべてのエラータは Red Hat カスタマーポータルから入手 できます。非同期エラータについては、OpenShift Container Platform ライフサイクル を参照してください。
Red Hat カスタマーポータルのユーザーは、Red Hat Subscription Management (RHSM) のアカウント設定でエラータの通知を有効にすることができます。エラータの通知を有効にすると、登録しているシステムに関連するエラータが新たに発表されるたびに、メールで通知が送信されます。
OpenShift Container Platform のエラータ通知メールを生成させるには、Red Hat カスタマーポータルのユーザーアカウントでシステムが登録されており、OpenShift Container Platform エンタイトルメントを使用している必要があります。
以下のセクションは、これからも継続して更新され、今後 OpenShift Container Platform 3.11 バージョンの非同期リリースで発表されたエラータの機能拡張およびバグ修正に関する説明を提供していきます。たとえば、OpenShift Container Platform 3.11.z は、サブセクションで説明します。さらに、エラータの文章がアドバイザリーで提供されたスペースに収まらないリリースについては、その後のサブセクションで説明します。
OpenShift Container Platform のいずれのバージョンについても、クラスターのアップグレード についての指示には必ず目を通してください。
2.8.1. RHBA-2018:3537: OpenShift Container Platform 3.11.43 バグ修正および機能拡張の更新
発行日: 2018-11-19
OpenShift Container Platform リリース 3.11.43 が公開されました。この更新に含まれるパッケージおよびバグ修正は、RHBA-2018:3537 アドバイザリーにまとめられています。この更新に含まれるコンテナーイメージは、RHBA-2018:3536 アドバイザリーで提供されています。
アドバイザリーでは、このリリースすべてのバグ修正および機能拡張に関する説明は除外されています。アップグレードについての注記およびこのリリースに含まれるバグ修正および機能拡張の詳細については、以下のセクションを参照してください。
2.8.1.1. バグ修正
- CRI-O Pod からのログメッセージは、性質上分割することが可能でした。そのため、部分的なログメッセージが Elasticsearch でインデックス化されました。新規の fluent-plugin-concat は CRI-O 形式の分割されたメッセージを 1 つにマージすることをサポートしていますが、これは OpenShift Container Platform ロギング v3.11 が使用する現行の fluentd (v0.12) では利用できません。この機能は fluentd v0.12 にバックポートされました。このバグ修正により、CRI-O 形式の分割されたログメッセージが元の完全なメッセージにマージし直されるようになりました。(BZ#1552304)
イベントルーターは、イベントログを失わないように重複したイベントログを意図的に生成していました。
elasticsearch_genid
プラグインがelasticsearch_genid_ext
に拡張され、alt_key
およびalt_tag
を取るようになりました。ログメッセージにalt_tag
値に一致するタグがある場合、これはalt_key
値を Elasticsearch プライマリーキーとして使用します。重複したイベント間で共有されるフィールドをalt_key
に指定すると、重複したイベントが Elasticsearch から排除されます。elasticsearch_genid_ext
を使用したフィルターのサンプル:@type elasticsearch_genid_ext hash_id_key viaq_msg_id alt_key kubernetes.event.metadata.uid alt_tags "#{ENV['GENID_ALT_TAG'] || 'kubernetes.var.log.containers.kube-eventrouter-*.** kubernetes.journal.container._default_.kubernetes.event'}" </filter>
このバグ修正により、重複したイベントログが Elasticsearch でインデックス化されなくなりました。(BZ#1613722)
- Netty の依存関係はヒープを効率的に使用しません。そのため、Elasticsearch はロギングボリュームの値が高くなるとネットワーク層で失敗し始めます。今回のバグ修正により、Netty recycler は無効にされ、Elasticsearch の接続処理の効率が強化されました。(BZ#1627086)
-
インストーラーは Elasticsearch Pod で使用される configmap をパラメーター化しませんでした。オペレーション用 (ops) Elasticsearch Pod はオペレーション用以外 (non-ops) の Elasticsearch Pod の configmap を使用していました。Pod が
logging-es-ops
configmap を使用できるようにインストーラーで使用されるテンプレートはパラメーター化できます。(BZ#1627689) - docker を journald ログドライバーで使用すると、システムおよびプレーンな docker コンテナーログを含むすべてのコンテナーログがジャーナルに記録され、fluentd によって準備可能な状態になります。fluentd はこれらの Kubernetes 以外のコンテナーログの処理方法が分からず、例外を出力しました。Kubernetes 以外のコンテナーログは他のシステムサービスからのログとして処理します (例: オペレーションインデックスに送信します)。Kubernetes 以外のコンテナーからのログが正しくインデックス化され、エラーが発生しなくなりました。(BZ#1632364)
-
docker をログドライバー journald で使用する際に、/etc/sysconfig/docker の設定は、
--log-driver=journald
ではなく、--log-driver
journald を使用するように変更されました。Fluentd は journald が使用されていることを検知できず、json-file
を想定し、journaldCONTAINER_NAME
フィールドを検索しないために Kubernetes メタデータを読み取ることができません。これにより、多数の fluentd エラーが発生します。Fluentd が--log-driver=journald
に加えて--log-driver
journald を検索できるように Fluentd の docker ログドライバーの検出方法が変更されました。これにより、Fluentd は docker ログドライバーを検出し、Kubernetes コンテナーログを適切に処理できるようになりました。(BZ#1632648) fluentd がコレクターと MUX の組み合わせとして設定されている場合、イベントからのイベントログは
MUX_CLIENT_MODE
の maximal および minimal の設定で、コレクターではなく MUX によって処理されるようになっていました。これは、イベントログがコレクターでフォーマットされている (またイベントレコードが Kubernetes キーの下に置かれている) 場合、ログは MUX に転送された後に k8s-meta プラグインに渡され、既存の Kubernetes レコードは上書きされるためです。これによりイベント情報はログから消去されました。修正 1: 置換を防ぐために、ログがイベントルーターからのものである場合、タグは input-post-forward-mux.conf の
${tag}.raw
に書き換えられます。 これにより、ログはMUX_CLIENT_MODE=minimal way
で処理されます。修正 2: Ansible には別のバグがあります。そのバグでは、
openshift_logging_install_eventrouter
がtrue
に設定されている場合でも環境変数TRANSFORM_EVENTS
が MUX に設定されませんでした。上記の 2 つのバグに関する修正により、イベントログは MUX が
MUX_CLIENT_MODE=maximal
および minimal に設定されている場合に適切にログに記録されるようになりました。(BZ#1632895)-
OpenShift Container Platform 3.10 以降では、API サーバーは静的 Pod として実行され、その Pod 内で /etc/origin/master および /var/lib/origin のみをマウントしました。ホストで信頼されている CA は API サーバーによって信頼されませんでした。API サーバー Pod 定義は /etc/pki を Pod にマウントするようになりました。API サーバーは、インストーラー変数
openshift_additional_ca
によって定義されるものを含め、ホストによって信頼されるすべての認証局を信頼するようになりました。これはプライベート CA によって検証されるレジストリーからイメージストリームをインポートするために使用できます。(BZ#1641657) - サービスカタログコントローラー Pod によって使用される OSB クライアントライブラリーは、ブローカーと通信するために使用される TCP 接続を閉じたり、解放したりしませんでした。一定期間が経過すると、多くの TCP 接続は開いたままとなり、サービスカタログコントローラーとブローカー間の通信は失敗し、さらに Pod は反応しなくなりました。さらに、Pod は応答しなくなります。OSB クライアントライブラリーを使用する場合に TCP 接続を再利用します。(BZ#1641796)
- 増分ビルドが S2I で選択されている場合に、不必要に短いタイムアウトにより、以前のビルドからのアーティファクトを再利用することができませんでした。これは、再利用されるアーティファクトのサイズがとくに大きい場合や、ホストシステムの実行速度がとくに遅い場合に発生する可能性がありました。無効なアーティファクトが以降のビルドで使用されたり、アーティファクトが再利用されるのではなく、再作成されてしまい、パフォーマンスの低下が生じる可能性がありました。今回のバグ修正により、この問題の発生を防ぐためにタイムアウトの値は大幅に引き上げられました。アーティファクトの再利用によってタイムアウトが生じることはなくなりました。(BZ#1642350)
- Automation Broker は一時的な namespace にターゲット namespace へのアクセスを付与するためのネットワークポリシーを常に作成していました。他のネットワークポリシーが有効にされていない namespace にネットワークポリシーを追加すると、その namespace は新たに作成されたポリシーに制限される結果になりました。ネットワークポリシーの追加前には、すべてがオープンな状態であり、namespace 間での相互通信が可能でした。Automation Broker ではターゲット namespace についてネットワークポリシーがあるかどうかを確認するようになり、ネットワークポリシーがない場合、ブローカーは新規のネットワークポリシーを作成しません。ブローカーは作成する一時的な namespace がターゲット namespace と通信できる程度にオープンな状態が確保されていることを想定します。ブローカーはターゲット namespace についての他のネットワークポリシーがある場合には、一時的な namespace にターゲット namespace へのアクセスを付与するネットワークポリシーを依然として作成します。今回のバグ修正により、ブローカーは、ターゲット namespace で実行されている既存のサービスに影響を与えずに APB アクションを実行できるようになりました。(BZ#1643301)
-
以前のバージョンでは、OpenShift Container Platform 3.11 のクラスターコンソールは、クラッシュがループする Pod がある場合でも、クラスターのステータスページで該当のクラッシュがループする Pod について
0
の値を常に表示していました。現時点でこの問題は修正され、カウント数は選択されたプロジェクトのカウント数を正確に反映するようになりました。(BZ#1643948)
2.8.1.2. アップグレード
既存の OpenShift Container Platform 3.10 または 3.11 クラスターをこの最新リリースにアップグレードする方法については、アップグレード方式およびストラテジー を参照してください。