备注：Istio 1.8.0 支持的 Kubernetes 版本是 1.16、1.17、1.18 和 1.19(从 Istio 1.7 开始仅支持 Kubernetes 1.16+ 版本)。

Istio 1.8 解读 - 用户至上

安装与升级

Istio 1.8 开始使用 Helm 3 进行安装和升级(响应用户的号召)，Istio 从 1.5 版本开始弃用 Helm，安装方式：Helm -> istioctl manifest -> istioctl install(未来可能会被废弃)、Istio Operator (最终的安装方式)。具体详见install-method-selection。

跨集群

简单易化 Kubernetes 安装多个 Istio 集群。详见multicluster。目前我觉得还是单个 Kubernetes 对应于单个 Istio 集群合理些。跨集群服务与下文所提的 Smart DNS Proxy 有一定的联系。

虚拟机应用

Istio网格如果需要注册VM 服务，到目前为止，唯一的方法是手动创建WorkloadEntry资源。但是在自动扩展VM的情况下，这可能会引起问题，在这种情况下，自动注册新VM并不容易。有一个Alpha功能可以解决此问题，从而可以自动注册VM。这由新的WorkloadGroup API资源完成，该资源负责在有新VM可用时自动创建WorkloadEntry资源。Istio 1.8版本为围绕VM支持的各种功能奠定了基础，随着它的成熟，在将来的版本中应该会变得显而易见。WorkloadGroup 是一个新的 API 对象，旨在与虚拟机等非 Kubernetes 工作负载一起使用，模仿现有的用于 Kubernetes 工作负载的 sidecar 注入和部署规范模型来引导 Istio 代理。

安全与证书

通过 K8s CSR API 集成外部 CAs，从Kubernetes 1.18开始，具有CSR API功能，该功能可自动执行来自证书颁发机构(CA)的证书请求。在Istio 1.8中，添加了实验性支持，以允许Istio使用Kubernetes CSR API与外部CA集成。此功能只是为使用外部CA奠定了必要的基础，现在仅支持istiod（并有些支持Google CA），但是随着该功能在Istio和Kubernetes方面都日趋成熟，将来的版本中应该会引入新的实现。

易用性

1. 新增了istioctl bug-report 命令，用来收集调试信息和获取集群状态。推荐使用istioctl analyze 分析 Istio 资源配置的合法性。
2. 安装 add-on 方式产生变化，在 Istio 1.7 中已经不推荐使用 istioctl 来安装，在 1.8 中直接被移除，这样有利于解决 add-on 落后于上游及难以维护的问题。如 Grafana、Prometheus、Zipkin、 Jaeger、Kiali等。详见 https://istio.io/latest/blog/2020/addon-rework/ 。目前都是推荐在 Kubernetes 集群中创建ADD-ON组件服务。
3. 正式移除 Mixer，现在官方推荐使用 WebAssembly 通过扩展 Envoy 来扩展 Istio。有关WebAssembly 详见 https://istio.io/latest/blog/2020/wasm-announce/ 。
4. 新增了Smart DNS Proxying，智能 DNS 域名解析代理。主要应用场景适用于 VM、外部服务、跨集群应用。详见 https://istio.io/latest/blog/2020/dns-proxy/。

Smart DNS proxying 新的 DNS 解析。Kubernetes集群外的VM可能难以提供DNS解析来路由集群内的服务，如果服务没有唯一的虚拟IP且同一端口（例如数据库），则DNS服务器无法区分它们在多集群网格中，我们无法解析另一个集群上的服务的IP地址（这就是为什么在远程集群上同样创建存根服务的原因）为了解决Istio 1.8的所有这些问题，在Istio sidecar代理中实现了一个用GO编写的DNS代理。此DNS代理由Istiod（基于集群上的服务和ServiceEntries）动态更新，并充当缓存。它将尝试根据其缓存解析所需的主机名，并且仅在缓存未注册主机名时才转向外部DNS服务器。弃用Istio CoreDNS Plugin，Istio1.8默认没有开启。

其他

Inbound cluster name 名称格式

Envoy Inbound 流量格式类似于：inbound|<service_port_number>|<service_port_name>|<service_hostname> 例如：inbound|80|http|httpbin.default.svc.cluster.local。从Istio 1.8 开始，该格式已经变更。服务端口名和服务的主机名现在被丢弃。

新的格式类似于：inbound|<service_port_number>||

例如： inbound|80||

当多个服务在同一Pod中选择相同的容器端口时会出现问题。官方的发行版本中提到：“对于大多数用户，这是一个实现细节，只会影响直接与Envoy配置进行交互的调试或工具。"。到目前为止，当有两个服务使用相同的服务端口号并选择同一个Pod，但它们目的端口号不同时，此更改会导致不可预期行为。

默认禁用 Protocol detection timeout

以前，Istio引入了某些“服务器优先”协议（例如MySQL使用的协议）的检测超时，该超时在没有初始流量要嗅探时触发。默认情况下，已禁用此协议检测超时，以避免在连接速度慢或某些情况下潜在的流量故障。

AuthorizationPolicy 新增 remoteIpBlocks/notRemoteIpBlocks 字段

新增的remoteIpBlocks/notRemoteIpBlocks字段被用于根据请求的原始源IP(从 X-Forwarded-ForHeader或代理协议获取)允许/拒绝请求。现在，AuthorizationPolicy资源上的ipBlocks/notIpBlocks字段用于基于到达Sidecar的IP数据包的源地址来允许/拒绝请求。如果你希望基于请求的原始源IP地址来允许/拒绝请求(使用X-Forwarded-For或代理协议），请更新AuthorizationPolicy资源以使用新的remoteIpBlocks/notRemoteIpBlocks字段，而不是ipBlocks/notIpBlocks字段。

默认强制 Trust Domain Validation

默认情况下，如果请求既不是来自同一信任域，也不是来自TrustDomainAliases列表，则“信任域验证”功能将拒绝对Sidecar的任何传入请求。如果要允许来自Istio 1.8上不同信任域的流量进入网格，则需要将其添加到TrustDomainAliases列表中，否则将被拒绝。

Envoy filter 功能增强

对于EnvoyFilter API，建议您使用新的Envoy过滤器名称，因为某些过滤器名称已被弃用，并将在以后的版本中删除。为了指定Envoy配置的HTTP_ROUTE规范的顺序，新的INSERT_FIRST，INSERT_BEFORE，INSERT_AFTER操作已添加到EnvoyFilter API。为了能够覆盖HTTP和网络过滤器，在EnvoyFilter API中添加了新的REPLACE操作。

新特性

以前，网关从Kubernetes secret 读取证书进行外部通信。这些网关通常是面向公众的实体，如果遭到攻击，则可能导致整个集群的Kubernetes secret中的证书泄漏。在Istio 1.8中，网关从Istiod获取证书。他们甚至没有特权来从集群中读取secret，以减少潜在的损害。此功能很有趣，因为它为我们提供了一种途径，使我们能够在将来的版本中从外部secret存储区（例如，保管库或云密钥存储区）中获取证书，这对于已经使用其他秘密存储区的许多Istio用户来说很方便。此外，这是完全向后兼容的更改，不需要任何用户交互。

总结

Istio 1.8大大提高了操作稳定性，也为将来版本中令人兴奋的新功能奠定了基础。废弃 Istio CoreDNS，使用新的智能DNS解析、支持在线安装Istio 1.8 新版本、增强虚拟机服务(使用新的WorkloadGroup)等是需要重点关注的方向。

对比

参考

1. https://istio.io/latest/news/releases/1.8.x/announcing-1.8/
2. https://banzaicloud.com/blog/istio-1.8/?utm_campaign=backyards-try&utm_content=147132245&utm_medium=social&utm_source=twitter&hss_channel=tw-927148627017060352#inbound-cluster-name

• ← Previous Post
• Next Post →