Istio 1.8刚刚发布，是迄今为止最好的Istio版本之一。新版本包含了令人兴奋的实验性功能，大量的增强功能，以及弃用和删除的内容。然而，该版本的核心重点是提高运行稳定性。在这篇文章中，我们将回顾Istio 1.8的新内容，并强调升级到最新版本时需要注意的一些潜在障碍。
如果你正在寻找一个基于新的Istio 1.8版本并支持安全和自动金丝雀升级流程的生产就绪的Istio发行版，请查看新的Backyards 1.5版本。
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集群。
高影响的变化（在升级网格时可能会导致问题）。
移除/删减。
实验性功能。
雷达下的变化（较小的变化，但我们认为是有趣/有用的）。
其他值得注意的变化。
完整的修改列表请参考修改说明。
影响较大的变化 🔗︎
入站集群名称格式改变 🔗︎
以前，Envoy的入站集群名称格式是这样的：inbound||| 。采用这种格式的集群名称的例子是：inbound|80|http|httpbin.default.svc.cluster.local 。
对于Istio 1.8.0来说，这个格式已经改变了，服务端口名和服务的主机名现在被省略了，新的格式看起来像这样：inbound||| 。对于上面的例子，新的格式是简单的。inbound|80||
当多个服务在同一个pod中选择相同的容器端口时，存在一些问题，这一变化是为了解决这些问题。正式的发布说明指出。"For most users, this is an implementation detail, and will only impact debugging or tooling that directly interacts with Envoy configuration."
好吧，从我们目前看到的情况来看，这个变化在以下情况下会导致不理想的行为。当有两个服务，使用相同的服务端口号并选择相同的pod，但它们在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 服务时，在这两种情况下都会在pod内调用同一个目标端口。因此，它将不可能通过其服务到达另一个容器端口，这绝对是不想要的行为，似乎是一个错误。
我们正计划就这个问题开一个问题，提供更多的细节，以便在上游解决这个问题。这个问题的解决方法可以是使用不同的服务端口号来避免这种冲突。我们在Backyards所做的是，在我们自己的docker镜像中恢复了这个试验性的变化，我们在Backyards中使用了这个镜像，这样这个问题就永远不会发生。
更新：这个上游问题可以在这里追踪到。感谢约翰-霍华德（John Howard），他发现了这个问题并迅速修复了它。这个补丁应该已经在Istio 1.8.1版本中了。
协议检测超时默认禁用 🔗︎
过去，Istio为某些 "服务器优先 "的协议引入了检测超时，比如MySQL使用的协议，当没有初始字节的流量可供嗅探时就会触发。这种协议检测超时已被默认禁用，以避免在慢速连接上出现潜在的流量故障，或在某些情况下增加延迟。
如果你错误地配置了 "服务器优先 "协议，这一变化将导致立即连接超时。
为了避免涉及 "服务器优先 "协议的问题，请确保通过以下方法之一为你的服务明确指定协议。
- 通过端口的名称：
name:[-]。 - 在Kubernetes 1.18+中，通过
appProtocol字段：appProtocol:。
下面是两种可能的声明的例子。
kind: Service
metadata:
name: httpbin
spec:
ports:
- number: 443
name: https-web
- number: 3306
name: db
appProtocol: mysql
AuthorizationPolicy资源上新的remoteIpBlocks/notRemoteIpBlocks 字段用于根据请求的原始源IP来允许/拒绝请求，这些源IP是从X-Forwarded-For 标头或代理协议中填充的。
AuthorizationPolicy 资源上的ipBlocks/notIpBlocks 字段现在被用来根据到达挎斗的 IP 数据包的源地址来允许/拒绝请求。
如果你想根据请求的原始源IP地址来允许/拒绝请求（因为你使用X-Forwarded-For 头或代理协议），那么更新你的AuthorizationPolicy 资源，使用新的remoteIpBlocks/notRemoteIpBlocks 字段，而不是ipBlocks/notIpBlocks 字段。
默认情况下强制执行信任域验证 🔗︎
默认情况下，如果请求既不是来自同一信任域，也不在TrustDomainAliases 列表中，则信任域验证功能将拒绝任何传入的侧车请求。
如果你想在Istio 1.8上允许来自不同信任域的流量进入你的网格，你需要把它添加到你的TrustDomainAliases 列表中，否则会被拒绝。
彻底删除Mixer 🔗︎
从Istio的早期开始，Mixer一直是控制平面组件，应用程序的边车代理向其报告遥测数据。在大型环境中，Mixer有可能导致资源消耗和延迟问题，这就是为什么引入了一个新的无Mixer遥测模型。
现在，在Istio 1.8中，所有与Mixer相关的特性和功能都被移除。所以，如果你还没有，你需要在升级到1.8之前适应遥测V2模型。
移除对用istioctl安装附加组件的支持 🔗︎
增强Istio功能的开源软件（如Prometheus、Grafana、Zipkin、Jaeger和Kiali）不能再与istioctl ，建议单独安装。
如果你想以最简单的方式安装所有这些集成组件--具有生产就绪的设置和许多附加功能--请查看Backyards。
Istio CoreDNS插件已废弃 🔗︎
Istio sidecar代理现在提供了对ServiceEntries的DNS解析的本地支持，这就是为什么Istio CoreDNS插件在Istio 1.8中被弃用，并将在未来的版本中被移除。
Envoy过滤器名称已被废弃 🔗︎
对于EnvoyFilter API，建议使用新的Envoy过滤器名称，因为一些过滤器名称已被废弃，并将在未来的版本中被删除。
实验性功能 🔗︎
智能DNS代理 🔗︎
DNS对于任何云原生应用都是必不可少的，但它在Kubernetes中的工作方式导致了Istio的一些挑战。
- Kubernetes集群外的虚拟机很难为集群内的服务提供DNS解析路由。
- 如果服务没有唯一的虚拟IP，并且在同一个端口上（例如数据库），那么DNS服务器就不能区分它们了
- 在多集群网中，我们无法解析另一个集群上的服务的IP地址（这就是为什么同样在远程集群上创建存根服务）。
为了解决Istio 1.8的所有这些问题，在Istio sidecar代理中实现了一个DNS代理，用GO编写。这个DNS代理由Istiod动态更新（基于集群上的服务和ServiceEntries），它充当一个缓存。它将尝试根据其缓存来解决所需的主机名，只有当缓存中没有注册的主机名时才会转向外部DNS服务器。
这是一个令人兴奋的新功能，现在就可以尝试，但默认情况下没有启用。要阅读关于这项新功能的深入解释，请确保查看这篇博文。
自动注册虚拟机 🔗︎
要为Istio网格注册虚拟机，到目前为止，唯一的方法是手动创建一个WorkloadEntry资源。这在以前是一个手动步骤，注册新的虚拟机，这与Kubernetes集群中的节点的相同过程的自动化不同。这可能会导致一些问题，例如，在自动扩展虚拟机的情况下，自动注册新的虚拟机并不容易。
有一个预热功能可以解决这个问题，使自动注册虚拟机成为可能。这是由一个新的WorkloadGroup资源完成的，它负责在有新的虚拟机时自动创建WorkloadEntry 资源。
Istio 1.8版本为围绕虚拟机支持的各种功能奠定了基础，随着它的成熟，这些功能应该在未来的版本中变得明显。
利用K8s CSR API与外部CA集成 🔗︎
从Kubernetes 1.18开始，有一个CSR API功能，它可以自动请求和检索来自证书颁发机构（CA）的证书。在Istio 1.8中，增加了实验性支持，允许Istio与外部CA集成，使用Kubernetes CSR API。
这个功能只是奠定了与外部CA合作的必要基础，现在只支持istiod（和谷歌CA有点），但随着这个功能在Istio和Kubernetes方面的成熟，新的实现应该在未来的版本中出现。
在雷达下的变化 🔗︎
以前，网关从Kubernetes的秘密中读取外部通信的证书。这些网关通常是面向公众的实体，如果它们被破坏，证书可以从Kubernetes秘密中读取，从而破坏整个集群。
在Istio 1.8中，网关从Istiod获取证书。他们甚至没有从集群中读取秘密所需的权限，以减少潜在的附带损害。
这个功能很有趣，因为它为我们在未来的版本中能够从外部秘密存储（如Vault或云密钥存储）中获取证书铺平了道路，这对许多已经使用其他秘密存储的Istio用户来说是很方便的。此外，这是一个完全向后兼容的变化，不需要任何用户互动。
EnvoyFilter的改进 🔗︎
为了指定Envoy配置的HTTP_ROUTE规格的顺序，EnvoyFilter的API中增加了新的INSERT_FIRST,INSERT_BEFORE,INSERT_AFTER 操作。为了能够覆盖http和网络过滤器，在EnvoyFilter API中增加了新的REPLACE 操作。
增加了调试存档选项 🔗︎
增加了一个新的istioctl bug-report 命令，以便能够获得Istio集群的存档--主要用于调试目的。
其他值得注意的变化 🔗︎
用Helm3安装Istio 🔗︎
差不多两年前，当我们开源Banzai Cloud Istio运营商时，我们这样做的部分原因是安装Istio的唯一选择是通过Helm，这有它的问题。一段时间后，istioctl ，然后是官方的Istio运营商，慢慢地，通过Helm安装的方法变得不受支持。然而，事实证明，Istio用户仍然需要一种用Helm安装和升级Istio的方法（主要是那些已经用Helm部署了所有应用程序的用户），正因为如此，Istio 1.8中加入了Helm 3的支持。
因此，用Helm 3安装和升级Istio是可能的，但我想在此指出，不建议这样做。Helm只支持原地升级，而目前推荐的流程是金丝雀升级模式。
为Istio资源状态添加观察生成 🔗︎
自1.6版本以来，Istio中出现了一个有趣的alpha功能，关于Istio资源的各种有用信息都在其Status 。这些字段包括但不限于资源的准备情况、与资源相关的数据平面实例的数量以及验证信息。
在Istio 1.8中，还出现了一个新的观察到的生成字段，当它与资源元数据中的生成相匹配时，表明所有Istio更新已经完成。这对于检测对Istio配置的请求变更何时被送达并准备好接收流量非常有用。
添加Wasm Grafana仪表盘 🔗︎
随着WebAssembly（Wasm）在Istio中获得越来越多的关注，它也逐渐成为正确监控的必要条件。因此，使用新增加的Grafana仪表盘来监测Wasm相关的指标是很方便的。
未到达目的地时正确标注指标 🔗︎
以前，有些情况下，请求没有到达目标代理（例如故障注入、断路、没有注入代理等），而且没有目标标签来识别请求的最终目标。这一点在1.8中得到了补救，这是一个受欢迎的错误修复。
收获 🔗︎
Istio 1.8在很大程度上提高了运行的稳定性，也为未来版本中令人兴奋的新功能打下了基础。
如果你想开始你的Istio体验，可以试试Backyards，我们的Istio发行版。Backyards操作服务网，为基于容器的现代应用带来深入的可观察性、方便的管理和基于策略的安全性。
在你自己的集群上查看Backyards的运行情况!
注册一个评估版本，并运行一个简单的安装命令
