2.8. 异步勘误更新
OpenShift Container Platform 3.11 的安全更新、程序错误修正、功能增强更新将会通过红帽网络以异步勘误的形式发布。所有的 OpenShift Container Platform 3.11 勘误都可以通过红帽客户门户网站获得。OpenShift Container Platform 生命周期包括了详细的与异步勘误相关的内容。
红帽客户门户网站的用户可以在红帽订阅管理（RHSM）帐户设置中启用勘误通知功能。当勘误通知被启用后，用户会在有与其注册的系统相关的勘误发行时接收到电子邮件通知。
用户的红帽客户门户网站账户需要有注册的系统，以及使用 OpenShift Container Platform 的权限才可以接收到 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 release 3.11.43 现已正式发布。其软件包列表和程序错误修正信息包括在 RHBA-2018:3537 公告中。此更新包括的容器镜像由 RHBA-2018:3536 公告提供。
因篇幅原因，没有在这个公告中包括此版本的所有程序错误修复更新和功能增强更新。关于本版本中包含的程序错误修正和增强的详细信息，请参见以下部分。
2.8.1.1. 程序错误修复
- 来自 CRI-O pod 的日志消息可能会在中间被分割。因此，Elasticsearch 会包括了部分日志消息的索引。新的 fluent-plugin-concat 支持将 CRI-O 风格的分割消息合并成一个消息，但 OpenShift Container Platform logging 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。Elasticsearch Pod 使用非操作 Elasticsearch Pod 的 configmap。参数化安装程序使用的模板，以便 pod 使用
logging-es-opsconfigmap。(BZ#1627689) - 当将 docker 与 journald 日志驱动程序搭配使用时，所有容器日志（包括系统和纯 docker 容器日志）都会登录到日志，并由 fluentd 读取。因此, fluentd 不知道如何处理这些非 Kubernetes 容器日志并抛出异常。将非 Kubernetes 容器日志作为来自其他系统服务的日志处理（例如，将它们发送到操作索引）。来自非 Kubernetes 容器的日志现在可以正确索引，且不会造成任何错误。(BZ#1632364)
-
当将 docker 与 log-driver journald 搭配使用时，/etc/sysconfig/docker 中的设置已改为使用
--log-driverjournald 而不是--log-driver=journald。Fluentd 无法检测 journald 是否正在使用，因此假设json-file，且无法读取任何 Kubernetes 元数据，因为它不查找 journaldCONTAINER_NAME字段。这会导致大量 fluentd 错误。Fluentd 检测 docker 日志驱动的方式已改变，除了--log-driver=journald外，还会查找--log-driverjournald。Fluentd 现在可以检测到 docker 日志驱动程序，并可正确处理 Kubernetes 容器日志。(BZ#1632648) 当 fluentd 配置为收集器和 MUX 的组合时，
MUX_CLIENT_MODE为 maximal 或 minimal 时，事件的事件日志都应该由 MUX 处理，而不是收集器处理 。这是因为，如果在收集器中格式化了事件日志（事件记录放在 Kubernetes 键下），日志会转发到 MUX 并传递给 k8s-meta 插件，现有的 Kubernetes 记录会被覆盖。这会导致日志中的事件信息被删除。Fix 1:要避免替换，如果日志来自事件路由器，标签会在 input-post-forward-mux.conf 中被重写为
${tag}.raw，这样就可以在MUX_CLIENT_MODE=minimal方法中处理日志。Fix 2:Ansible 中存在另一个错误。环境变量
TRANSFORM_EVENTS不会在 MUX 中设置，即使openshift_logging_install_eventrouter被设置为true。在这个版本中，当 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 服务器现在信任主机信任的所有证书颁发机构（CA），包括安装程序变量
openshift_additional_ca定义的 CA。这可用于从由私有 CA 验证的 registry 中导入镜像流。(BZ#1641657) - Service Catalog 控制器 pod 使用的 OSB 客户端程序库没有关闭和释放用来与代理通信的 TCP 连接。在一段时间内，很多 TCP 连接将保持打开，最终服务目录控制器和代理间的通信会失败。另外，pod 也会变得没有响应。使用 OSB 客户端程序库时会重复使用 TCP 连接。(BZ#1641796)
- 当使用 S2I 选择增量构建时，一个不必要的简短超时会导致在选择了 S2I 的增量构建时，无法重复使用之前构建的工件。当使用工件的大小特别大或者主机系统运行缓慢时会出现这种情况。无效的工件可以在后续的构建中使用，或者工件会被重新创建，而不是重复使用，从而导致性能下降。在这个版本中，超时时间被增加到一个足够大的值来避免这个问题。工件重复使用时应该不会出现超时问题。(BZ#1642350)
- Automation Broker 总是创建一个网络策略，以便对目标命名空间进行临时命名空间访问。在没有其他网络策略的命名空间中添加网络策略会导致将命名空间锁定到新创建的策略中。在网络策略前，所有内容都是公开的，命名空间可以相互通信。现在，Automation Broker 会查看目标命名空间是否有网络策略。如果没有，代理将无法创建新网络策略。代理将假设事情已足够公开，以便我们创建的临时命名空间可以与目标命名空间通信。如果目标命名空间有其他网络策略，代理仍然会创建一个网络策略，为目标命名空间授予临时命名空间访问权限。在这个版本中，代理可以在不影响目标命名空间中运行的现有服务的情况下执行 APB 操作。(BZ#1643301)
-
在以前的版本中，OpenShift Container Platform 3.11 中的集群控制台始终会在集群状态页面中显示 crashlooping pod 的数量为
0，即使存在 crashlooping pod 也是如此。这个问题现已解决，可以准确显示所选项目的数量。(BZ#1643948)
2.8.1.2. 升级
要将现有 OpenShift Container Platform 3.10 或 3.11 集群升级到此最新版本，请参阅升级方法和策略。
