关于istio:Banza-Cloud-重磅解读Istio-18

Istio 1.8 刚刚公布，并且是迄今为止最好的 Istio 版本之一。新版本蕴含诸多乏味的试验性能，泛滥加强性能以​​及不举荐应用和删除的性能。然而，此版本的外围焦点是进步操作稳定性。在这篇文章中，咱们将回顾 Istio 1.8 的新增性能，并重点介绍降级到最新版本时须要留神的一些潜在问题。

Istio 1.8 变动 ︎

留神：Istio 1.8.0 发行版中的一些已知问题已在正式变更阐明中指出。在降级集群之前期待一些补丁程序公布，以确保解决了这些问题。

首先，重要的是要指出 Istio 1.8 反对的 Kubernetes 版本是 1.16、1.17、1.18 和 1.19。如果您的环境中正在运行 Istio 1.7，则至多应该曾经在 Kubernetes 1.16 上（因为它也是 Istio 1.7 反对的最早的 K8s 版本）。因而，您应该筹备降级到 Istio 1.8，而不用降级 K8s 集群。

影响比拟大的变更（在降级网格时可能导致问题）：

• Inbound cluster name format 变更
• 默认禁用 Protocol detection timeout
• AuthorizationPolicy 新增了 remoteIpBlocks/notRemoteIpBlocks 字段
• 默认强制 Trust Domain Validation

移除 / 弃用：

• 齐全移除 Mixer
• istioctl 不再反对装置 add-ons
• 弃用 Istio CoreDNS Plugin
• 弃用 Envoy filter names

某些较小的变动，但比拟有用：

• Istiod 可能解决 gateway 证书
• EnvoyFilter 加强
• 增加了调试存档选项

其余值得注意的变动：

• Helm3 装置 Istio
• 为 Istio 资源状态增加 generation 字段
• 新增 Wasm Grafana dashboards
• 当目标地址不可达时，正确标记指标

无关更改的残缺列表，请参阅更改阐明。

重大影响变动 ︎

Inbound 集群名格局变更 ︎

之前，Envoy Inbound 集群名的格局相似于inbound|<service_port_number>|<service_port_name>|<service_hostname>。例如：inbound|80|http|httpbin.default.svc.cluster.local。

从 Istio1.8 开始，该格局曾经变更。服务端口名和服务的主机名当初被忽视了，新的格局相似于：inbound|<service_port_number>||。例如：inbound|80||。

当多个服务在同一 Pod 中抉择雷同的容器端口时会呈现问题。官网的发行申明中提到：” 对于大多数用户，这是一个实现细节，只会影响间接与 Envoy 配置进行交互的调试或工具。”。

好的，到目前为止，当有两个服务应用雷同的服务端口号并抉择同一个 Pod，但它们目标端口号不同时，此更改会导致不可预期行为。

这是一个后端和前端容器位于同一 Pod 中的示例：

apiVersion: v1
kind: Service
metadata:
  name: backyards-web
  namespace: backyards-system
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: http-web
  selector:
    app.kubernetes.io/name: backyards
  type: ClusterIP
---
apiVersion: v1
kind: Service
metadata:
  name: backyards
  namespace: backyards-system
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: http-app
  selector:
    app.kubernetes.io/name: backyards
  type: ClusterIP

通过此设置，在应用上游docker.io/istio/pilot:1.8.0 docker 镜像时，您会在 istiod 日志中看到以下正告：

"pilot_duplicate_envoy_clusters": {
        "inbound|80||": {
            "proxy": "backyards-8cdfc77b5-4jw44.backyards-system",
            "message": "Duplicate cluster inbound|80|| found while pushing CDS"
        }
    }

问题在于，当调用 backyards-web 或backyards服务时，两种状况下都只会调用一个端口，也就意味着通过服务不可能调用到另外一个端口。这相对是不冀望的行为，并且仿佛是一个谬误。

默认禁用 Protocol detection timeout ︎

过来，Istio 引入了某些“服务器优先”协定（例如 MySQL 应用的协定）的检测超时，该超时在没有初始流量要嗅探时触发。默认状况下，已禁用此协定检测超时，以防止在连贯速度慢或某些状况下潜在的流量故障。

如果您配置谬误的“服务器优先”协定，此更改将导致立刻连贯超时。

为防止波及“服务器优先”协定的问题，请确保通过以下办法之一为您的服务明确指定协定：

• 通过端口名: name: <protocol>[-<suffix>]。
• 对于 Kubernetes 1.18+, 通过 appProtocol 字段: appProtocol: <protocol>。

这是两个可能的申明的示例：

kind: Service
metadata:
  name: httpbin
spec:
  ports:
  - number: 443
    name: https-web
  - number: 3306
    name: db
    appProtocol: mysql

AuthorizationPolicy 新增 remoteIpBlocks/notRemoteIpBlocks 字段 ︎

新增的 remoteIpBlocks/notRemoteIpBlocks 字段被用于依据申请的原始源 IP(从X-Forwarded-For Header 或代理协定获取) 容许 / 拒绝请求。

当初，AuthorizationPolicy 资源上的 ipBlocks / notIpBlocks 字段用于基于达到
Sidecar 的 IP 数据包的源地址来容许 / 拒绝请求。

如果你心愿基于申请的原始源 IP 地址来容许 / 拒绝请求（应用 X -Forwarded-For 标头或代理协定），请更新 AuthorizationPolicy 资源以应用新的 remoteIpBlocks/notRemoteIpBlocks 字段，而不是 ipBlocks/notIpBlocks 字段。

默认强制启用 Trust Domain Validation ︎

默认状况下，如果申请既不是来自同一信赖域，也不是来自 TrustDomainAliases 列表，则“信赖域验证”性能将回绝对 Sidecar 的任何传入申请。
如果要容许来自 Istio 1.8 上不同信赖域的流量进入网格，则须要将其增加到 TrustDomainAliases 列表中，否则将被回绝。

移除 / 弃用 ︎

齐全移除 Mixer ︎

自 Istio 开源以来，Mixer 始终是利用立体 Sidecar 代理向其报告遥测数据的管制立体组件。Mixer 可能在较大的环境中引起资源耗费和提早问题，这就是为什么引入了新的无 Mixer 遥测模型的起因：

• 首先，作为 Istio 1.3 中的一项试验性能
• 而后在 Istio 1.4 中将该性能以 Telemetry V2 的名称提供
• Istio 1.5 Telemetry V2 中的默认状况下处于关上状态
• 在 Istio 1.6 中，不赞成应用基于 Mixer 的遥测模型，而举荐应用新的 Telemetry V2 模型

当初，在 Istio 1.8 中，已删除所有与 Mixer 相干的性能。因而，如果尚未装置，则须要先降级到 Telemetry V2 模型，再降级到 1.8。

istioctl 不再反对装置 add-ons ︎

加强 Istio 性能的开源软件（例如 Prometheus，Grafana，Zipkin，Jaeger 和 Kiali）不能再与 istioctl 一起装置，倡议将它们离开装置。

Istio CoreDNS Plugin 弃用 ︎

Istio Sidecar 代理当初通过 ServiceEntries 为 DNS 解析提供了原生反对，这就是为什么 Istio 1.8 中不举荐应用 Istio CoreDNS 插件，并且在当前的版本中将其删除的起因。

Envoy filter names 弃用 ︎

对于 EnvoyFilter API，建议您应用新的 Envoy 过滤器名称，因为某些过滤器名称已被弃用，并将在当前的版本中删除。

试验个性 ︎

智能 DNS 代理 ︎

DNS 对于任何云原生应用程序都是必不可少的，然而它在 Kubernetes 中的工作形式会给 Istio 带来一些挑战：

• Kubernetes 集群外的 VM 可能难以提供 DNS 解析来路由集群内的服务
• 如果服务没有惟一的虚构 IP 且同一端口（例如数据库），则 DNS 服务器无奈辨别它们
• 在多集群网格中，咱们无奈解析另一个集群上的服务的 IP 地址（这就是为什么在近程集群上同样创立存根服务的起因）

为了解决 Istio 1.8 的所有这些问题，在 Istio sidecar 代理中实现了一个用 GO 编写的 DNS 代理。此 DNS 代理由 Istiod（基于集群上的服务和 ServiceEntries）动静更新，并充当缓存。它将尝试依据其缓存解析所需的主机名，并且仅在缓存未注册主机名时才转向内部 DNS 服务器。

这是一项令人兴奋的新性能，能够立刻尝试应用，但默认状况下未启用。要浏览无关此新性能的深刻阐明，请确保查看此博客文章。

主动注册 VMs ︎

要为 Istio 网格注册 VM，到目前为止，惟一的办法是手动创立 WorkloadEntry 资源。然而在主动扩大 VM 的状况下，这可能会引起问题，在这种状况下，主动注册新 VM 并不容易。
有一个预 Alpha 性能能够解决此问题，从而能够主动注册 VM。这由新的 WorkloadGroup 资源实现，该资源负责在有新 VM 可用时主动创立 WorkloadEntry 资源。
Istio 1.8 版本为围绕 VM 反对的各种性能奠定了根底，随着它的成熟，在未来的版本中应该会变得不言而喻。

通过 K8s CSR API 集成内部 CAs ︎

从 Kubernetes 1.18 开始，具备 CSR API 性能，该性能可主动执行来自证书颁发机构（CA）的证书申请。在 Istio 1.8 中，增加了实验性反对，以容许 Istio 应用 Kubernetes CSR API 与内部 CA 集成。
此性能只是为应用内部 CA 奠定了必要的根底，当初仅反对 istiod（并有些反对 Google CA），然而随着该性能在 Istio 和 Kubernetes 方面都日趋成熟，未来的版本中应该会引入新的实现。

较小但有用的变更 ︎

Istiod 解决 gateway 证书 ︎

以前，网关从 Kubernetes secret 读取证书进行内部通信。这些网关通常是面向公众的实体，如果受到攻打，则能够导致整个集群的 Kubernetes secret 中的证书透露。
在 Istio 1.8 中，网关从 Istiod 获取证书。他们甚至没有特权来从集群中读取 secret，以缩小潜在的侵害。
此性能很乏味，因为它为咱们提供了一种路径，使咱们可能在未来的版本中从内部 secret 存储区（例如，保存库或云密钥存储区）中获取证书，这对于曾经应用其余机密存储区的许多 Istio 用户来说很不便。此外，这是齐全向后兼容的更改，不须要任何用户交互。

EnvoyFilter 加强 ︎

为了指定 Envoy 配置的 HTTP_ROUTE 标准的程序，新的 INSERT_FIRST，INSERT_BEFORE，INSERT_AFTER 操作已增加到 EnvoyFilter API。为了可能笼罩 HTTP 和网络过滤器，在 EnvoyFilter API 中增加了新的 REPLACE 操作。

增加了调试存档选项 ︎

增加了一个新的 istioctl bug-report 命令，以便可能获取 Istio 集群的存档 – 次要用于调试目标。

其余值得注意的变动 ︎

通过 Helm3 部署 Istio ︎

大概两年前，当咱们开源 Banzai Cloud Istio operator 时，咱们这样做的局部起因是，装置 Istio 的惟一抉择是通过 Helm，它存在问题。一段时间后，引入了 istioctl，而后引入了正式的 Istio operator，并且，逐步地，Helm 的装置办法不再受反对。然而，事实证明，Istio 用户依然须要一种应用 Helm 装置和降级 Istio 的办法（次要是针对曾经应用 Helm 部署了所有应用程序的用户），因而，为 Helm 3 增加了反对 Istio 1.8。
因而，能够应用 Helm 3 装置和降级 Istio，然而在此我不建议您这样做。Helm 仅反对就地降级，而明天倡议应用金丝雀降级模型。

为 Istio 资源状态增加 generation 字段 ︎

自 1.6 版以来，Istio 中曾经有了一个乏味的 alpha 性能，其中无关 Istio 资源的各种有用信息都显示在其 Status 字段中。这些字段包含但不限于资源筹备状况，与资源关联的数据立体实例的数量以及验证音讯。
在 Istio 1.8 中，还会呈现一个新的察看到的 generation 字段，当该字段与资源元数据中的生成匹配时，表明所有 Istio 更新均已实现。这对于检测何时提供了对 Istio 配置的申请更改并筹备接管流量很有用。

新增 Wasm Grafana dashboards ︎

随着 WebAssembly（Wasm）在 Istio 中取得越来越多的关注，为了正确地监督它，也逐步须要它。因而，在 Wasm 相干指标上应用新增加的 Grafana 仪表板会很不便。

当目标地址不可达时，正确标记指标 ︎

以前，有些状况下申请没有达到指标代理（例如，故障注入，断路，没有注入代理等），并且没有指标标签来标识什么将成为申请的最终目标。在 1.8 版中对此进行了修复，这是一个受欢迎的谬误修复程序。

总结 ︎

Istio 1.8 大大提高了操作稳定性，也为未来版本中令人兴奋的新性能奠定了根底。

PS: 本文属于翻译，原文