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: v1kind: Servicemetadata:  name: backyards-web  namespace: backyards-systemspec:  ports:  - name: http    port: 80    protocol: TCP    targetPort: http-web  selector:    app.kubernetes.io/name: backyards  type: ClusterIP---apiVersion: v1kind: Servicemetadata:  name: backyards  namespace: backyards-systemspec:  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: Servicemetadata:  name: httpbinspec:  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: 本文属于翻译，原文