2.5. 程序错误修复
此发行版本修复了以下组件的程序错误：
Builds
- ConfigMap 构建源允许使用 ConfigMap 用作构建源，它与 secret 相比，更加透明且易于维护。ConfigMaps 可以注入到任何 OpenShift 构建中。(BZ#1540978)
- 有关内存不足（OOM）终止的构建 Pod 的信息会被传播到构建对象。当适当的错误信息提供给用户时，可以信息简化调试过程。当一个构建因为 Pod 因为 OOM 被终止时，工具控制器会正确提供状态原因和消息。(BZ#1596440)
- 更新构建状态的逻辑，以包含在构建状态变为失败状态后才运行的构建日志尾部的日志片断。构建会首先转换为失败状态，然后再次使用日志片断进行更新。这意味着，监视构建进入失败状态的代码不会看到最初填充的日志片段值。现在，当构建转换为失败状态时，代码被修改为填充日志片断字段，因此构建更新将包含失败状态和日志片断。监视构建进入失败状态的代码将会看到日志片段作为将构建转换为失败的更新的一部分，而不是看到后续的更新。(BZ#1596449)
-
如果作业使用了
JenkinsPipelineStrategy构建策略，则忽略修剪设置。因此，设置successfulBuildsHistoryLimit和failedBuildsHistoryLimit无法正确修剪旧的作业。代码已更改为正确修剪作业。(BZ#1543916)
Cloud Compute
-
现在您可以在安装过程中为
dns=none配置 NetworkManager。此配置通常用于在 Microsoft Azure 上部署 OpenShift Container Platform，但也可用于其他场景。要配置此功能，请设置openshift_node_dnsmasq_disable_network_manager_dns=true。(BZ#1535340)
Image
- 在以前的版本中，由于处理空镜像流更新时存在问题，当对镜像流的更新不会造成标签更改时会产生一个对镜像导入 API 的请求，该请求中不包含要导入的内容，使该请求无效，并导致控制器出现错误。现在，如果对镜像流的更新不会导致新的标签，或更新的标签需要被导入，则不会产生一个导入 API 调用。在这个版本中，无效的请求不会产生导入 API，控制器中不会出现任何错误。(BZ#1613979)
- 在删除 Blob 时，当遇到意外错误时，镜像修剪会停止。如果镜像删除错误，镜像修剪将无法从 etcd 中删除任何镜像对象。现在，在各个独立作业中的镜像会被同时进行修剪。因此，镜像修剪不会在单个意外的 Blob 删除失败时停止。(BZ#1567657)
安装程序
-
当部署到 AWS 时,
build_amiplay 无法清理 /var/lib/cloud。一个未清理的 /var/lib/cloud 目录会导致 cloud-init 跳过执行。跳过执行会导致新部署的节点无法引导，无法在 OpenShift Container Platform 中自动注册。在这个版本中，在进行seal_amiplay 时清除了 /var/lib/cloud 目录。(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，另一个用于 alert-buffer。在带有动态存储的多区集群中，一个或多个这样的卷可能在一个不同的区域被分配。这会导致 Prometheus pod 变得不可调度，因为集群中的每个节点只能访问其所在区的物理卷。因此，没有节点能够运行 Prometheus pod 并访问所有三个物理卷。建议的解决方案是，创建一个存储类，使用
zone:参数将卷限制到单个区域，并使用 Ansible 安装程序清单变量openshift_prometheus_<COMPONENT>_storage_class=<zone_restricted_storage_class>将这个存储类分配给 Prometheus 卷。通过这个临时解决方案，所有三个卷都会在同一区域或区域中创建，Prometheus pod 会自动调度到同一区的节点。(BZ#1554921)
Logging
-
在以前的版本中,
openshift-ansible安装程序只支持shared_ops和unique作为 Kibana 索引方法。此程序错误修复允许非 EFK 集群中的用户在 Kibana 中共享默认索引，并共享查询、仪表板等。(BZ#1608984) - 作为安装 ES5 堆栈的一部分，用户需要为 ES 运行的节点创建一个 sysctl 文件。此程序错误修复会评估针对哪个节点/Ansible 主机运行这些任务。(BZ#1609138)
- 需要额外的内存来支持 Prometheus 指标和重试队列，以避免出现使用默认内存造成的内存不足引起的重启问题。此程序错误修复为 Fluentd 增加了默认的内存。因此，Fluentd Pod 可以避免因为默认内存不足造成的重启问题。(BZ#1590920)
- 现在，Fluentd 默认为每个 100 个操作重新连接到 Elasticsearch。如果一个 Elasticsearch 在集群中的其他 Elasticsearch 之前启动，Elasticsearch 服务中的负载均衡器将只连接到那个 Elasticsearch，因此所有 Fluentd 都连接到 Elasticsearch。在这个版本中，通过定期重新连接 Fluentd，负载均衡器可以将负载平均地分散到集群中的所有 Elasticsearch 中。(BZ#1489533)
-
rubygem ffi 1.9.25 恢复了一个补丁程序，使它可以在 SELinux
deny_execmem=1的系统中正常工作。这会导致 Fluentd 崩溃问题的出现。此程序错误修复进行相应的更新，在使用 SELinuxdeny_execmem=1时 Fluentd 不会崩溃。(BZ#1628407)
管理控制台
- 日志查看器没有考虑多行或部分行的响应。如果一个响应包含多行信息，它会被添加并当作一行，从而导致行数字不正确。同样，如果收到部分行，它将被视为一整行，导致有时会被分成多个行的较长的日志行，从而导致行计数不正确。此程序错误修复添加了日志查看器中的逻辑，以考虑多行和部分行响应。因此，现在的行数字是准确的。(BZ#1607305)
监控
-
在默认情况下，所有节点上的
9100端口都被阻断。Prometheus 无法处理在其它节点上运行的node_exporter服务，该服务监听端口9100。在这个版本中，修改了防火墙配置，允许9000-1000范围的端口进入 TCP 流量。现在，Prometheus 可以处理node_exporter服务。(BZ#1563888) -
在默认情况下，
node_exporter启动时会启用wifi收集程序。wifi收集程序需要未启用的 SELinux 权限，这会导致 AVC 拒绝问题的出现，但不会停止node_exporter。此程序错误修复确保了在显式禁用wifi收集程序时node_exporter会启动。因此，SELinux 不再报告 AVC 拒绝。(BZ#1593211) -
卸载 Prometheus 目前会删除整个
openshift-metrics命名空间。这可能会删除在同一命名空间中创建的，但不是 Prometheus 安装的一部分的对象。此程序错误修复更改了卸载过程，仅删除由 Prometheus 安装创建的特定对象，如果没有其他剩余对象，则删除命名空间。这可允许在与其他对象共享命名空间时，安装和卸载 Prometheus。(BZ#1569400)
Pod
-
在以前的版本中，Kubernetes 中的一个错误会在 Pod 返回错误时导致
kubectl drain停止。在 Kubernetes 修复中，当 Pod 返回错误，命令将不再挂起。(BZ#1586120)
路由
- 由于在 OpenShift Extended Comformance Tests 和 Node Vertical Test 后 dnsmasq 耗尽了可用文件描述符，所以 dnsmasq 会挂起，并且没有创建新的 pod。对代码的更改会增加打开文件描述符的最大数量，以便节点能够通过测试。(BZ#1608571)
-
如果使用路由上的
haproxy.router.openshift.io/ip_whitelist注解指定了62 个或更多的 IP 地址，则路由器会因为超过命令的最大参数（63）而出错。路由器将不会重新加载。当白名单注解中 IP 太多，并将映射传递到 HA-proxy ACL 时，现在代码已改为使用溢出映射。(BZ#1598738) -
根据设计，使用多个服务的路由时，当为一个服务设置了
route-backend为0时，权重会丢弃所有现有的连接和关联的终端用户连接。在这个版本中，0表示服务器不参与负载平衡，但仍接受持久的连接。(BZ#1584701) -
因为存活度和就绪度探测无法区分存活的 pod 和就绪的 pod，所以带有
ROUTER_BIND_PORTS_AFTER_SYNC=true的路由会报告失败。在这个版本中，存活度和就绪度探测被分成两个不同的探测，一个用于就绪度，一个用于存活度。因此，路由器 Pod 可以是存在的，但还没有就绪。(BZ#1550007) - 当 HAproxy 路由器包含大量路由时（10,000 或更高），路由器将因为性能低，从而不会通过存活度和就绪度，从而重复地终止路由器。造成此问题的根本原因很可能无法在默认的就绪度和存活度检测周期内完成健康检查。要防止这个问题，请增大探测的间隔。(BZ#1595513)
服务代理
- Ansible Service Broker 的取消置备过程没有从 openshift-ansible-service-broker 项目中删除 secret。在这个版本中，代码被修改为在 Ansible Service Broker 取消置备时删除所有相关 secret。(BZ#1585951)
- 在以前的版本中，代理的协调功能会在从 registry 获取更新信息前删除其镜像引用，且记录会出现在代理的数据存储中，其他作业仍然在运行。协调功能被重新设计，以对已更改的项目进行原位更新。对于从 registry 中删除的项目，代理仅删除尚未置备的项目。它还会为需要删除的项目标记，这样就可从 UI 中过滤它们，阻止以后置备这些项目。因此，代理的协调功能可使置备和取消置备对于 registry 的更改更具弹性。(BZ#1577810)
-
在以前的版本中，当一个项目找不到时用户会看到错误消息，即使它通常是找不到的。因此，成功运行的作业也可能会记录错误消息，从而导致用户担心实际并不存在的错误。现在已将消息的日志记录级别从
error改为debug。因为消息可以用于调试目的，但不适用于生产环境（在生成环境中，通常将级别设为info或更高级别）。因此，当实例找不到时，用户不会看到错误消息，除非出现实际问题。(BZ#1583587) -
如果集群没有运行或者无法访问，
svcat version命令会导致错误。代码被修改为总是报告客户端版本，如果服务器可以访问，它会报告服务器版本。(BZ#1585127) -
在某些情况下，使用
svcat deprovision <service-instance-name> --wait命令有时会导致svcat命令终止并带有 panic 错误。发生这种情况时，会执行deprovision命令，然后程序在尝试等待实例被完全取消置备时遇到代码错误。这个问题现已解决。(BZ#1595065)
Storage
- 在以前的版本中，因为 kubelet 系统容器无法写入 /var/lib/iscsi 目录，所以无法附加 iSCSI 卷。现在，您可以将主机 /var/lib/iscsi 挂载到 kubelet 系统容器中，以便可以附加 iSCSI 卷。(BZ#1598271)
