Banza Cloud 重磅解读Istio 1.8

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

移除/弃用：

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

Istiod 能够处理 gateway 证书
EnvoyFilter 增强
添加了调试存档选项

其他值得注意的变化：

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

有关更改的完整列表，请参阅更改说明。

重大影响变化 ︎

Inbound 集群名格式变更 ︎

从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: 本文属于翻译，原文