第 2 章 Service Mesh 1.x
2.1. Service Mesh 发行注记
查看不再支持的 Red Hat OpenShift Service Mesh 发行版本的文档。
Service Mesh 版本 1.0 和 1.1 control plane 不再被支持。有关升级服务网格 control plane 的详情，请参阅 升级 Service Mesh。
有关特定 Red Hat OpenShift Service Mesh 发行版本的支持状态的信息，请参阅产品生命周期页面。
2.1.1. 使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始：master、slave、黑名单和白名单。由于此项工作十分艰巨，这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情，请参阅我们的首席技术官 Chris Wright 提供的消息。
2.1.2. Red Hat OpenShift Service Mesh 简介
Red Hat OpenShift Service Mesh 通过在应用程序中创建集中控制点来解决微服务架构中的各种问题。它在现有分布式应用上添加一个透明层，而无需对应用代码进行任何更改。
微服务架构将企业应用的工作分成模块化服务，从而简化扩展和维护。但是，随着微服务架构上构建的企业应用的规模和复杂性不断增长，理解和管理变得困难。Service Mesh 可以通过捕获或截获服务间的流量来解决这些架构问题，并可修改、重定向或创建新请求到其他服务。
Service Mesh 基于开源 Istio 项目，为创建部署的服务提供发现、负载均衡、服务对服务身份验证、故障恢复、指标和监控的服务网络提供了便捷的方法。服务网格还提供更复杂的操作功能，其中包括 A/B 测试、canary 发行版本、访问控制以及端到端验证。
2.1.3. 获取支持
如果您在执行本文档所述的某个流程或 OpenShift Container Platform 时遇到问题，请访问 红帽客户门户网站。通过红帽客户门户网站：
- 搜索或者浏览红帽知识库，了解与红帽产品相关的文章和解决方案。
- 提交问题单给红帽支持。
- 访问其他产品文档。
要识别集群中的问题，您可以在 OpenShift Cluster Manager 中使用 Insights。Insights 提供了问题的详细信息，并在有可用的情况下，提供了如何解决问题的信息。
如果您对本文档有任何改进建议，或发现了任何错误，请为相关文档组件提交 JIRA 问题。请提供具体详情，如章节名称和 OpenShift Container Platform 版本。
在提交问题单时同时提供您的集群信息，可以帮助红帽支持为您进行排除故障。
您可使用 must-gather 工具来收集有关 OpenShift Container Platform 集群的诊断信息，包括虚拟机数据以及其他与 Red Hat OpenShift Service Mesh 相关的数据。
为了获得快速支持，请提供 OpenShift Container Platform 和 Red Hat OpenShift Service Mesh的诊断信息。
2.1.3.1. 关于 must-gather 工具
oc adm must-gather CLI 命令可收集最有助于解决问题的集群信息，包括：
- 资源定义
- 服务日志
默认情况下，oc adm must-gather 命令使用默认的插件镜像，并写入 ./must-gather.local。
另外，您可以使用适当的参数运行命令来收集具体信息，如以下部分所述：
要收集与一个或多个特定功能相关的数据，请使用
--image参数和镜像，如以下部分所述。例如：
$ oc adm must-gather --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.10.0
要收集审计日志，请使用
-- /usr/bin/gather_audit_logs参数，如以下部分所述。例如：
$ oc adm must-gather -- /usr/bin/gather_audit_logs
注意作为默认信息集合的一部分，不会收集审计日志来减小文件的大小。
当您运行 oc adm must-gather 时，集群的新项目中会创建一个带有随机名称的新 pod。在该 pod 上收集数据，并保存至以 must-gather.local 开头的一个新目录中。此目录在当前工作目录中创建。
例如：
NAMESPACE NAME READY STATUS RESTARTS AGE ... openshift-must-gather-5drcj must-gather-bklx4 2/2 Running 0 72s openshift-must-gather-5drcj must-gather-s8sdh 2/2 Running 0 72s ...
2.1.3.2. 前提条件
-
使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift Container Platform CLI (
oc)。
2.1.3.3. 关于收集服务网格数据
您可使用 oc adm must-gather CLI 命令来收集有关集群的信息，包括与 Red Hat OpenShift Service Mesh 相关的功能和对象：
前提条件
-
使用具有
cluster-admin角色的用户访问集群。 -
已安装 OpenShift Container Platform CLI (
oc)。
过程
要使用
must-gather收集 Red Hat OpenShift Service Mesh 数据，您必须指定 Red Hat OpenShift Service Mesh 镜像。$ oc adm must-gather --image=registry.redhat.io/openshift-service-mesh/istio-must-gather-rhel8:2.4
要使用
must-gather为特定 Service Mesh control plane 命名空间收集 Red Hat OpenShift Service Mesh 数据，您必须指定 Red Hat OpenShift Service Mesh 镜像和命名空间。在本例中，在gather,后将<namespace>替换为您的 Service Mesh control plane 的命名空间，如istio-system。$ oc adm must-gather --image=registry.redhat.io/openshift-service-mesh/istio-must-gather-rhel8:2.4 gather <namespace>
2.1.4. Red Hat OpenShift Service Mesh 支持的配置
以下是 Red Hat OpenShift Service Mesh 唯一支持的配置：
- OpenShift Container Platform 版本 4.6 或更高版本。
OpenShift Online 和 Red Hat OpenShift Dedicated 不支持 Red Hat OpenShift Service Mesh。
- 部署必须包含在一个独立的 OpenShift Container Platform 集群中。
- 此版本的 Red Hat OpenShift Service Mesh 仅适用于 OpenShift Container Platform x86_64。
- 此发行版本只支持在 OpenShift Container Platform 集群中包含所有 Service Mesh 组件的配置。它不支持在集群之外或在多集群场景中管理微服务。
- 这个版本只支持没有集成外部服务的配置，比如虚拟机。
如需有关 Red Hat OpenShift Service Mesh 生命周期和支持的配置的更多信息，请参阅 支持策略。
2.1.4.1. Red Hat OpenShift Service Mesh 支持的 Kiali 配置
- Kiali 观察控制台只支持 Chrome 、Edge 、Firefox 或 SDomain 浏览器的最新的两个版本。
2.1.4.2. 支持的 Mixer 适配器
此发行版本只支持以下 Mixer 适配器：
- 3scale Istio Adapter
2.1.5. 新功能
Red Hat OpenShift Service Mesh 在服务网络间提供了实现关键功能的统一方式：
- 流量管理 - 控制服务间的流量和 API 调用，提高调用的可靠性，并使网络在条件不好的情况保持稳定。
- 服务标识和安全性 - 在网格中提供可验证身份的服务，并提供保护服务流量的能力，以便可以通过信任度不同的网络进行传输。
- 策略强制 - 对服务间的交互应用机构策略，确保实施访问策略，并在用户间分配资源。通过配置网格就可以对策略进行更改，而不需要修改应用程序代码。
- 遥测 - 了解服务间的依赖关系以及服务间的网络数据流，从而可以快速发现问题。
2.1.5.1. Red Hat OpenShift Service Mesh 1.1.18.2 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题。
2.1.5.1.1. Red Hat OpenShift Service Mesh 1.1.18.2 版中包含的组件版本
| 组件 | 版本 |
|---|---|
| Istio | 1.4.10 |
| Jaeger | 1.30.2 |
| Kiali | 1.12.21.1 |
| 3scale Istio Adapter | 1.0.0 |
2.1.5.2. Red Hat OpenShift Service Mesh 1.1.18.1 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题。
2.1.5.2.1. Red Hat OpenShift Service Mesh 1.1.18.1 版中包含的组件版本
| 组件 | 版本 |
|---|---|
| Istio | 1.4.10 |
| Jaeger | 1.30.2 |
| Kiali | 1.12.20.1 |
| 3scale Istio Adapter | 1.0.0 |
2.1.5.3. Red Hat OpenShift Service Mesh 1.1.18 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题。
2.1.5.3.1. Red Hat OpenShift Service Mesh 1.1.18 版中包含的组件版本
| 组件 | 版本 |
|---|---|
| Istio | 1.4.10 |
| Jaeger | 1.24.0 |
| Kiali | 1.12.18 |
| 3scale Istio Adapter | 1.0.0 |
2.1.5.4. Red Hat OpenShift Service Mesh 1.1.17.1 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题。
2.1.5.4.1. Red Hat OpenShift Service Mesh 处理 URI 片段的方式改变
Red Hat OpenShift Service Mesh 包含一个可远程利用的漏洞 CVE-2021-39156，其中 HTTP 请求带有片段（以 # 字符开头的 URI 末尾的一个部分），您可以绕过 Istio URI 基于路径的授权策略。例如，Istio 授权策略拒绝发送到 URI 路径 /user/profile 的请求。在存在安全漏洞的版本中，带有 URI 路径 /user/profile#section1 的请求绕过拒绝策略并路由到后端（通过规范的 URI path /user/profile%23section1），可能会导致安全事件。
如果您使用带有 DENY 操作和 operation.paths 的授权策略，或者 ALLOW 操作和 operation.notPaths，则会受到此漏洞的影响。
在这个版本中，在授权和路由前会删除请求的 URI 片段部分。这可以防止其 URI 中带有片段的请求绕过基于 URI 且没有片段部分的授权策略。
2.1.5.4.2. 授权策略所需的更新
Istio 为主机名本身和所有匹配端口生成主机名。例如，用于 "httpbin.foo" 主机的虚拟服务或网关会生成匹配 "httpbin.foo 和 httpbin.foo:*" 的配置。但是，完全匹配授权策略仅与为 hosts 或 notHosts 字段给出的确切字符串匹配。
如果您使用精确字符串比较的 AuthorizationPolicy 来确定 主机或非主机，则会影响您的集群。
您必须更新授权策略 规则，以使用前缀匹配而不是完全匹配。例如，在第一个 AuthorizationPolicy 示例中，将 hosts: ["httpbin.com"] 替换为 hosts: ["httpbin.com:*"]。
第一个 AuthorizationPolicy 示例使用前缀匹配
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
action: DENY
rules:
- from:
- source:
namespaces: ["dev"]
to:
- operation:
hosts: [“httpbin.com”,"httpbin.com:*"]
第二个 AuthorizationPolicy 示例使用前缀匹配
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: default
spec:
action: DENY
rules:
- to:
- operation:
hosts: ["httpbin.example.com:*"]
2.1.5.5. Red Hat OpenShift Service Mesh 1.1.17 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
2.1.5.6. Red Hat OpenShift Service Mesh 1.1.16 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
2.1.5.7. Red Hat OpenShift Service Mesh 1.1.15 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
2.1.5.8. Red Hat OpenShift Service Mesh 1.1.14 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
要解决 CVE-2021-29492 和 CVE-2021-31920 的问题，则必须完成手动步骤。
2.1.5.8.1. CVE-2021-29492 和 CVE-2021-31920 所需的手动更新
Istio 包含一个可被远程利用的漏洞，当使用基于路径的授权规则时，带有多个斜杠或转义的斜杠字符（%2F` or %5C`）的 HTTP 请求路径可能会绕过 Istio 授权策略。
例如，假设 Istio 集群管理员定义了一个授权 DENY 策略，以便在路径 /admin 上拒绝请求。发送到 URL 路径 //admin 的请求不会被授权策略拒绝。
根据 RFC 3986，带有多个斜杠的路径 //admin 在技术上应被视为与 /admin 不同的路径。但是，一些后端服务选择通过将多个斜杠合并成单斜杠来规范 URL 路径。这可能导致绕过授权策略（//admin 不匹配 /admin），用户可以在后端的路径 /admin 上访问资源，这可能会产生安全问题。
如果您使用 ALLOW action + notPaths 字段或者 DENY action + paths 字段特征，您的集群会受到这个漏洞的影响。这些模式可能会被意外的策略绕过。
在以下情况下，集群不会受到此漏洞的影响：
- 您没有授权策略。
-
您的授权策略没有定义
paths或notPaths字段。 -
您的授权策略使用
ALLOW action + paths字段或DENY action + notPaths字段特征。这些模式只会导致意外的拒绝，而不是绕过策略。对于以上情况，升级是可选的。
路径规范化的 Red Hat OpenShift Service Mesh 配置位置与 Istio 配置不同。
2.1.5.8.2. 更新路径规范化配置
Istio 授权策略可能基于 HTTP 请求中的 URL 路径。路径规范化 （也称为 URI 规范化）、修改和标准化传入请求的路径，以便能够以标准的方式处理规范化路径。在路径规范化后，同步不同路径可能是等同的。
Istio 在根据授权策略和路由请求前，支持请求路径中的以下规范化方案：
| Option | Description | Example | 备注 |
|---|---|---|---|
|
| 没有进行规范化。Envoy 接收的任何内容都会完全按原样转发到任何后端服务。 |
| 此设置会受到 CVE-2021-31920 的影响。 |
|
|
这是目前 Istio 默认安装中使用的选项。这在 Envoy 代理上应用 |
| 此设置会受到 CVE-2021-31920 的影响。 |
|
| 斜杠会在 BASE 规范化后合并。 |
| 更新此设置以缓解 CVE-2021-31920 的问题。 |
|
|
默认允许所有流量时的最严格设置。建议使用此设置，请注意您必须对您的授权策略路由进行彻底测试。Percent 编码的 斜杠和反斜杠字符（ |
| 更新此设置以缓解 CVE-2021-31920 的问题。这个设置更为安全，但可能会破坏应用程序。在部署到生产环境中前测试您的应用程序。 |
规范化算法按以下顺序进行：
-
解码百分比
%2F、%2f、%5C和%5c。 -
RFC 3986 和其他在 Envoy 中的
normalize_path选项实现的规范化。 - 合并斜杠。
虽然这些规范化选项代表来自 HTTP 标准和常见行业实践的建议，但应用程序可能会以它选择的任何方式解释 URL。在使用拒绝策略时，请确保您了解应用程序的行为方式。
2.1.5.8.3. 路径规范配置示例
确保 Envoy 规范化请求路径以匹配后端服务的预期，对您的系统安全至关重要。以下示例可用作配置系统的参考。规范化 URL 路径，如果选择 NONE，则原始 URL 路径为：
- 用于检查授权策略。
- 转发到后端应用程序。
| 如果您的应用程序… | 选择… |
|---|---|
| 依赖于代理进行规范化 |
|
| 根据 RFC 3986 规范化请求路径，且不合并斜杠。 |
|
|
| |
|
| |
| 以与 RFC 3986 不兼容的方式处理请求路径。 |
|
2.1.5.8.4. 为路径规范化配置 SMCP
要为 Red Hat OpenShift Service Mesh 配置路径规范化，请在 ServiceMeshControlPlane 中指定以下内容。使用配置示例来帮助确定您的系统设置。
SMCP v1 路径规范化
spec:
global:
pathNormalization: <option>
2.1.5.9. Red Hat OpenShift Service Mesh 1.1.13 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
2.1.5.10. Red Hat OpenShift Service Mesh 1.1.12 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
2.1.5.11. Red Hat OpenShift Service Mesh 1.1.11 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
2.1.5.12. Red Hat OpenShift Service Mesh 1.1.10 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
2.1.5.13. Red Hat OpenShift Service Mesh 1.1.9 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
2.1.5.14. Red Hat OpenShift Service Mesh 1.1.8 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
2.1.5.15. Red Hat OpenShift Service Mesh 1.1.7 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
2.1.5.16. Red Hat OpenShift Service Mesh 1.1.6 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
2.1.5.17. Red Hat OpenShift Service Mesh 1.1.5 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
此发行版本还添加了对配置密码套件的支持。
2.1.5.18. Red Hat OpenShift Service Mesh 1.1.4 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
要解决 CVE-2020-8663 的问题，则必须完成手动步骤。
2.1.5.18.1. CVE-2020-8663 所需的手动更新
对于 CVE-2020-8663: envoy: Resource exhaustion when accepting too many connections 的问题，为下游连接添加了一个可配置的限制。必须配置这个限制的配置选项来减轻这个安全漏洞的影响。
无论您使用 1.1 版本还是使用 Red Hat OpenShift Service Mesh 1.0 版本，需要手动步骤来缓解这个 CVE。
这个新配置选项称为 overload.global_downstream_max_connections，它作为一个代理的 runtime 设置可以进行配置。在 Ingress Gateway 上执行以下步骤配置限制。
流程
使用以下文本创建名为
bootstrap-override.json的文件，以强制代理覆盖 bootstrap 模板并从磁盘加载运行时配置：{ "runtime": { "symlink_root": "/var/lib/istio/envoy/runtime" } }从
bootstrap-override.json文件创建 secret，将 <SMCPnamespace> 替换为您在其中创建服务网格 control plane（SMCP）的命名空间：$ oc create secret generic -n <SMCPnamespace> gateway-bootstrap --from-file=bootstrap-override.json
更新 SMCP 配置来激活覆盖。
更新的 SMCP 配置示例 #1
apiVersion: maistra.io/v1 kind: ServiceMeshControlPlane spec: istio: gateways: istio-ingressgateway: env: ISTIO_BOOTSTRAP_OVERRIDE: /var/lib/istio/envoy/custom-bootstrap/bootstrap-override.json secretVolumes: - mountPath: /var/lib/istio/envoy/custom-bootstrap name: custom-bootstrap secretName: gateway-bootstrap要设置新的配置选项，创建一个带有适当的
overload.global_downstream_max_connections设置的 secret。以下示例使用10000：$ oc create secret generic -n <SMCPnamespace> gateway-settings --from-literal=overload.global_downstream_max_connections=10000
- 再次更新 SMCP，将 secret 挂载到 Envoy 查找运行时配置的位置：
更新的 SMCP 配置示例 #2
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
template: default
#Change the version to "v1.0" if you are on the 1.0 stream.
version: v1.1
istio:
gateways:
istio-ingressgateway:
env:
ISTIO_BOOTSTRAP_OVERRIDE: /var/lib/istio/envoy/custom-bootstrap/bootstrap-override.json
secretVolumes:
- mountPath: /var/lib/istio/envoy/custom-bootstrap
name: custom-bootstrap
secretName: gateway-bootstrap
# below is the new secret mount
- mountPath: /var/lib/istio/envoy/runtime
name: gateway-settings
secretName: gateway-settings
2.1.5.18.2. 从 Elasticsearch 5 升级到 Elasticsearch 6
从 Elasticsearch 5 更新至 Elasticsearch 6 时，必须删除 Jaeger 实例。然后，因为证书存在问题，需要重新创建 Jaeger 实例。重新创建 Jaeger 实例会触发新证书集。如果正在使用持久性存储，只要新 Jaeger 实例的 Jaeger 名称和命名空间与已删除的 Jaeger 实例相同，就可以挂载相同的卷。
Jaeger 作为 Red Hat Service Mesh 的一部分安装的流程
确定 Jaeger 自定义资源文件的名称：
$ oc get jaeger -n istio-system
您应该看到类似如下的内容：
NAME AGE jaeger 3d21h
将生成的自定义资源文件复制到临时目录中：
$ oc get jaeger jaeger -oyaml -n istio-system > /tmp/jaeger-cr.yaml
删除 Jaeger 实例：
$ oc delete jaeger jaeger -n istio-system
从自定义资源文件的副本重新创建 Jaeger 实例：
$ oc create -f /tmp/jaeger-cr.yaml -n istio-system
删除生成的自定义资源文件的副本：
$ rm /tmp/jaeger-cr.yaml
Jaeger 没有作为 Red Hat Service Mesh 的一部分安装的流程
在开始前，创建 Jaeger 自定义资源文件的副本。
通过删除自定义资源文件来删除 Jaeger 实例：
$ oc delete -f <jaeger-cr-file>
例如：
$ oc delete -f jaeger-prod-elasticsearch.yaml
从自定义资源文件的备份副本重新创建 Jaeger 实例：
$ oc create -f <jaeger-cr-file>
验证您的 Pod 已重启：
$ oc get pods -n jaeger-system -w
2.1.5.19. Red Hat OpenShift Service Mesh 1.1.3 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。
2.1.5.20. Red Hat OpenShift Service Mesh 1.1.2 的新功能
此 Red Hat OpenShift Service Mesh 发行版本解决了一个安全漏洞问题。
2.1.5.21. Red Hat OpenShift Service Mesh 1.1.1 的新功能
此 Red Hat OpenShift Service Mesh 发行版本增加了对断开连接的安装的支持。
2.1.5.22. Red Hat OpenShift Service Mesh 1.1.0 的新功能
此 Red Hat OpenShift Service Mesh 发行版本添加了对 Istio 1.4.6 和 Jaeger 1.17.1 的支持。
2.1.5.22.1. 从 1.0 手动更新到 1.1
如果要从 Red Hat OpenShift Service Mesh 1.0 更新至 1.1，您必须更新 ServiceMeshControlPlane 资源，以便将 control plane 组件更新至新版本。
- 在 web 控制台中，点 Red Hat OpenShift Service Mesh Ooperator。
-
点 Project 菜单，然后从列表中选择部署了
ServiceMeshControlPlane的项目，如istio-system。 -
点 control plane 的名称，例如
basic-install。 -
点 YAML，并将版本字段添加到
ServiceMeshControlPlane资源的spec:中。例如，要升级到 Red Hat OpenShift Service Mesh 1.1.0，请添加version: v1.1。
spec: version: v1.1 ...
version 字段指定要安装的 Service Mesh 版本，默认为最新可用版本。
请注意，对 Red Hat OpenShift Service Mesh v1.0 的支持于 2020 年 10 月终止。您必须升级到 v1.1 或 v2.0。
2.1.6. 已弃用的功能
之前版本中的一些功能已被弃用或删除。
弃用的功能仍然包含在 OpenShift Container Platform 中，并将继续被支持。但是，这个功能会在以后的发行版本中被删除，且不建议在新的部署中使用。
2.1.6.1. Red Hat OpenShift Service Mesh 1.1.5 已弃用的功能
以下自定义资源在 1.1.5 版本中已弃用，并在版本 1.1.12 中删除。
-
Policy-Policy资源已弃用，并将在以后的版本中由PeerAuthentication资源替代。 -
MeshPolicy-MeshPolicy资源已弃用，并将在以后的版本中由PeerAuthentication资源替代。 v1alpha1RBAC API - v1alpha1 RBAC 策略已弃用，使用 v1beta1AuthorizationPolicy。RBAC（Role Based Access Control）定义ServiceRole和ServiceRoleBinding对象。-
ServiceRole -
ServiceRoleBinding
-
RbacConfig-RbacConfig实施自定义资源定义来控制 Istio RBAC 行为。-
ClusterRbacConfig（Red Hat OpenShift Service Mesh 1.0 以前的版本） -
ServiceMeshRbacConfig（Red Hat OpenShift Service Mesh 版本 1.0 及更新版本）
-
-
在 Kiali 中，
login和LDAP策略已被弃用。将来的版本将引入使用 OpenID 供应商的身份验证。
本发行版本中还弃用了以下组件，并将在以后的版本中被 Istiod 组件替代。
- Mixer - 访问控制及使用策略
- Pilot - 服务发现和代理配置
- Citadel - 证书生成
- Galley - 配置验证和发布
2.1.7. 已知问题
Red Hat OpenShift Service Mesh 中存在以下限制：
- Red Hat OpenShift Service Mesh 不支持 IPv6，因为上游 Istio 项目不支持它，OpenShift Container Platform 也不完全支持它。
- 图形布局 - Kiali 图形的布局会根据应用程序构架和要显示的数据（图形节点数目及其交互）的不同而有所变化。因为创建一个统一布局的难度较大，所以 Kiali 提供了几种不同布局的选择。要选择不同的布局，可从 Graph Settings 菜单中选择一个不同的 Layout Schema。
- 您第一次从 Kiali 控制台访问相关服务（如 Jaeger 和 Grafana）时，必须使用 OpenShift Container Platform 登录凭证接受证书并重新进行身份验证。这是因为框架如何显示控制台中的内置页面中存在问题。
2.1.7.1. Service Mesh 已知问题
Red Hat OpenShift Service Mesh 有以下已知的问题：
在对安装了 Service Mesh 1.0.x 的 Jaeger 或 Kiali Operator 进行升级时，Jaeger/Kiali Operator 的升级过程可能会无法完成，Operator 的状态会显示为 Pending 。
临时解决方案：如需更多信息，请参阅链接的知识库文章。
- Istio-14743 因为此 Red Hat OpenShift Service Mesh 版本所基于的 Istio 版本的限制，目前有一些应用程序与 Service Mesh 还不兼容。详参阅社区的相关链接。
MAISTRA-858 Envoy 日志中以下与 与 Istio 1.1.x 相关的弃用选项和配置相关的信息是正常的：
- [2019-06-03 07:03:28.943][19][warning][misc] [external/envoy/source/common/protobuf/utility.cc:129] Using deprecated option 'envoy.api.v2.listener.Filter.config'。This configuration will be removed from Envoy soon.
- [2019-08-12 22:12:59.001][13][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Listener.use_original_dst' from file LDS.proto。This configuration will be removed from Envoy soon.
MAISTRA-806 被逐出的 Istio Operator Pod 会导致 mesh 和 CNI 不能被部署。
临时解决方案：如果在部署 control pane 时
istio-operatorpod 被逐出，删除被逐出的istio-operatorpod。- MAISTRA-681 当 control plane 有多个命名空间时，可能会导致出现性能问题。
- MAISTRA-465 Maistra Operator 无法为 operator 指标数据创建服务。
-
MAISTRA-453 如果创建新项目并立即部署 pod，则不会进行 sidecar 注入。在创建 pod 前，operator 无法添加
maistra.io/member-of，因此必须删除 pod 并重新创建它以执行 sidecar 注入操作。 - MAISTRA-158 应用指向同一主机名的多个网关时，会导致所有网关停止工作。
2.1.7.2. Kiali 已知问题
Kiali 的新问题应该在 OpenShift Service Mesh 项目中创建，Component 设为 Kiali。
Kiali 中已知的问题：
- KIALI-2206 当您第一次访问 Kiali 控制台时，浏览器中没有 Kiali 的缓存数据，Kiali 服务详情页面的 Metrics 标签页中的 “View in grafana” 链接会重定向到错误的位置。只有在第一次访问 Kiali 才会出现这个问题。
- KIALI-507 Kiali 不支持 Internet Explorer 11。这是因为底层框架不支持 Internet Explorer。要访问 Kiali 控制台，请使用 Chrome 、Edge 、Firefox 或 Safari 浏览器的两个最新版本之一。
2.1.7.3. Red Hat OpenShift 分布式追踪已知问题
Red Hat OpenShift 分布式追踪中存在这些限制：
- 不支持 Apache spark。
- IBM Z 和 IBM Power Systems 上不支持通过 AMQ/Kafka 进行流部署。
Red Hat OpenShift 分布式追踪有以下已知的问题：
-
OBSDA-220 在某些情况下，如果您尝试使用分布式追踪数据收集拉取镜像，则镜像拉取失败，并显示
Failed to pull image错误消息。这个问题还没有临时解决方案。 TRACING-2057 Kafka API 已更新至
v1beta2，以支持 Strimzi Kafka Operator 0.23.0。但是，AMQ Streams 1.6.3 不支持这个 API 版本。如果您有以下环境，将不会升级 Jaeger 服务，您无法创建新的 Jaeger 服务或修改现有的 Jaeger 服务：- Jaeger Operator 频道：1.17.x stable 或 1.20.x stable
AMQ Streams Operator 频道： amq-streams-1.6.x
要解决这个问题，将 AMQ Streams Operator 的订阅频道切换到 amq-streams-1.7.x 或 stable。
2.1.8. 修复的问题
在当前发行本中解决了以下问题：
2.1.8.1. Service Mesh 修复的问题
- MAISTRA-1649 不同命名空间中的无标头服务会有冲突。在不同命名空间中部署无头服务时，端点配置会被合并，并导致推送到 sidecar 的 Envoy 配置无效。
-
当控制器在拥有者引用中未设置时， kubernetesenv 中的 Maistra-1541 会导致 Panic。如果 pod 没有指定控制器的 ownerReference，则会导致
kubernetesenv cache.go代码出现 panic。 - MAISTRA-1352 Cert-manager 自定义资源定义(CRD)已针对这个发行版本和以后的版本被删除。如果您已经安装了 Red Hat OpenShift Service Mesh，如果没有使用 cert-manager，则必须手动删除 CRD。
-
MAISTRA-1001 关闭 HTTP/2 连接可能会导致
istio-proxy中的分段错误。 -
MAISTRA-932 添加了
requires元数据，以添加 Jaeger Operator 和 OpenShift Elasticsearch Operator 之间的依赖关系。确保安装了 Jaeger Operator 时，它会自动部署 OpenShift Elasticsearch Operator（如果不可用）。 - MAISTRA-862 Galley 在多次命名空间删除和重新创建后丢弃了监控并停止了向其他组件提供配置。
- MAISTRA-833 Pilot 在多次命名空间删除和重新创建后停止了交付配置。
-
MAISTRA-684
istio-operator中默认的 Jaeger 版本为 1.12.0，它与 Red Hat OpenShift Service Mesh 0.12.TechPreview 提供的 Jaeger 版本 1.13.1 不匹配。 - MAISTRA-622 在 Maistra 0.12.0/TP12 中，permissive 模式无法正常工作。用户可以使用 Plain text 模式或 Mutual TLS 模式，但不能使用 permissive 模式。
- MAISTRA-572 Jaeger 无法与 Kiali 一起使用。在这个版本中，Jaeger 被配置为使用 OAuth 代理，但它被配置为只能通过浏览器进行配置，且不允许服务访问。Kiali 无法正确与 Jaeger 端点沟通，它会认为 Jaeger 被禁用。请参阅 TRACING-591。
- MAISTRA-357 在 OpenShift 4 Beta on AWS 中，默认无法通过端口 80 之外的 ingress 网关访问 TCP 或 HTTPS 服务。AWS 负载均衡器有一个健康检查，它可验证服务端点中的端口 80 是否活跃。如果服务没有在端口 80 中运行，负载均衡器健康检查就会失败。
- MAISTRA-348 OpenShift 4 Beta on AWS 不支持端口 80 或 443 之外的 ingress 网关流量。如果您将 ingress 网关配置为使用 80 或 443 以外的端口号处理 TCP 流量，作为临时解决方案，您必须使用 AWS 负载均衡器提供的服务主机名，而不是使用 OpenShift 路由器。
- MAISTRA-193 当为 citadel 启用了健康检查功能时，会出现预期外的控制台信息。
- Bug 1821432 OpenShift Container Platform Control Resource details 页面中的 Toggle 控件无法正确更新 CR。OpenShift Container Platform Web 控制台中的 Service Mesh Control Plane (smcp) Overview 页面中的 UI 切换控制有时会更新资源中的错误字段。要更新 ServiceMeshControlPlane 资源，直接编辑 YAML 内容，或者从命令行更新资源，而不是使用切换控件。
2.1.8.2. Kiali 修复的问题
- KIALI-3239 如果一个 Kiali Operator pod 失败且状态为 “Evicted”，它会阻塞 Kiali operator 的部署。解决办法是删除被逐出的 pod，并重新部署 Kiali operator。
- KIALI-3118 当对 ServiceMeshMemberRoll 进行修改后（例如，添加或删除了项目），Kiali pod 会重新启动，并在 Kiali pod 重新启动的过程中在 Graph 页中显示错误信息。
- KIALI-3096 Runtime metrics 在 Service Mesh 中失败。在 Service Mesh 和 Prometheus 之间有一个 OAuth 过滤器，需要向 Prometheus 传递一个 bearer 令牌才会授予访问权限。Kiali 已被更新为在与 Prometheus 服务器通讯时使用这个令牌，但应用程序的 metrics 当前会有 403 错误。
- KIALI-3070 此程序错误只会影响自定义 dashboard，它不会影响默认的 dashboard。当您在 metrics 设置中选择标签并刷新页面时，会在菜单中保留您的选择，但您的选择不会在图表中显示。
- KIALI-2686 当 control plane 有多个命名空间时，可能会导致出现性能问题。
2.1.8.3. Red Hat OpenShift 分布式追踪问题
- OSSM-1910 因为版本 2.6 中引入了问题，所以无法在 OpenShift Container Platform Service Mesh 中建立 TLS 连接。在这个版本中，通过更改服务端口名称以匹配 OpenShift Container Platform Service Mesh 和 Istio 所使用的约定解决了这个问题。
- OBSDA-208 在更新之前，默认的 200m CPU 和 256Mi 内存资源限制可能会导致分布式追踪数据收集在大型集群中持续重启。在这个版本中，通过删除这些资源限值解决了这个问题。
- OBSDA-222 在此更新之前，可以在 OpenShift Container Platform 分布式追踪平台中丢弃 span。为了帮助防止这个问题发生，这个版本会更新版本依赖项。
TRACING-2337 Jaeger 在 Jaeger 日志中记录一个重复的警告信息，如下所示：
{"level":"warn","ts":1642438880.918793,"caller":"channelz/logging.go:62","msg":"[core]grpc: Server.Serve failed to create ServerTransport: connection error: desc = \"transport: http2Server.HandleStreams received bogus greeting from client: \\\"\\\\x16\\\\x03\\\\x01\\\\x02\\\\x00\\\\x01\\\\x00\\\\x01\\\\xfc\\\\x03\\\\x03vw\\\\x1a\\\\xc9T\\\\xe7\\\\xdaCj\\\\xb7\\\\x8dK\\\\xa6\\\"\"","system":"grpc","grpc_log":true}这个问题已通过只公开查询服务的 HTTP(S)端口而不是 gRPC 端口来解决。
- TRACING-2009 已更新 Jaeger Operator，使其包含对 Strimzi Kafka Operator 0.23.0 的支持。
-
TRACING-1907 Jaeger 代理 sidecar 注入失败，因为应用程序命名空间中缺少配置映射。因为
OwnerReference字段设置不正确，配置映射会被自动删除，因此应用程序 pod 不会超过 "ContainerCreating" 阶段。已删除不正确的设置。 - TRACING-1725 转入到 TRACING-1631。额外的程序漏洞修复，可确保当存在多个生产环境的 Jaeger 实例，它们使用相同的名称但在不同的命名空间中时，Elasticsearch 证书可以被正确协调。另请参阅 BZ-1918920。
- TRACING-1631 多 Jaeger 生产环境实例使用相同的名称但在不同命名空间中，因此会导致 Elasticsearch 证书问题。安装多个服务网格时，所有 Jaeger Elasticsearch 实例都有相同的 Elasticsearch secret 而不是单独的 secret，这导致 OpenShift Elasticsearch Operator 无法与所有 Elasticsearch 集群通信。
- 在使用 Istio sidecar 时，在 Agent 和 Collector 间的连接会出现 TRACING-1300 失败。对 Jaeger Operator 的更新默认启用了 Jaeger sidecar 代理和 Jaeger Collector 之间的 TLS 通信。
-
TRACING-1208 访问 Jaeger UI 时的身份验证 "500 Internal Error" 错误。当尝试使用 OAuth 验证 UI 时，会得到 500 错误，因为 oauth-proxy sidecar 不信任安装时使用
additionalTrustBundle定义的自定义 CA 捆绑包。 -
TRACING-1166 目前无法在断开网络连接的环境中使用 Jaeger 流策略。当一个 Kafka 集群被置备时，它会产生一个错误：
Failed to pull image registry.redhat.io/amq7/amq-streams-kafka-24-rhel7@sha256:f9ceca004f1b7DCCB3b82d9a8027961f9fe4104e0ed69752c0bdd8078b4a1076。 - TRACING-809 Jaeger Ingester 与 Kafka 2.3 不兼容。当存在两个或多个 Jaeger Ingester 实例时，它会不断在日志中生成重新平衡信息。这是由于在 Kafka 2.3 里存在一个程序错误，它已在 Kafka 2.3.1 中修复。如需更多信息，请参阅 Jaegertracing-1819。
BZ-1918920/LOG-1619 / LOG-1619，Elasticsearch Pod 在更新后不会自动重启。
临时解决方案：手动重启 pod。
