Isito 1.10.x 更新解读

原文: https://istio.io/latest/news/releases/1.10.x/announcing-1.10/

新功能

Discovery Selectors

针对大规模的集群下,有部分的 Namespace 会经常的进行快速变动,创建很多临时的 Pod/Service,会带来 Istiod 监听之后Push xDS 的压力变大。因此增加了一个新特性,来忽略部分 namespace

  1. 我们首先对 Ns 标记上特定标签
1
kubectl label namespace default istio-discovery=enabled
  1. 修改 Istio 的全局配置
1
2
3
4
meshConfig:
discoverySelectors:
- matchLabels:
istio-discovery: enabled

这样 istiod 仅仅会监听 default 这个 namespace

Discovery Selectors vs Sidecar Resource

discoverySelectors 是全局性配置并且仅仅针对 istiod 生效,和 sidecarResource 功能有重叠,
Discovery Selectors 相较于 Sidecar 的使用难度,低了很多,对于大部分的场景下,我们仅仅希望忽略一些 namespace,会比 sidecar 要好用些。

Stable revision labels (experimental)

在以前的版本中,我们也讨论过灰度升级的方案,Istioldie 1.9 / Canary Upgrades

我们部署多个版本,通过 revision 进行区分。

istio-1.9.x
1
2
3
4
5
kubectl get pods -n istio-system -l app=istiod

NAME READY STATUS RESTARTS AGE
istiod-786779888b-p9s5n 1/1 Running 0 114m
istiod-canary-6956db645c-vwhsk 1/1 Running 0 1m

而在这个版本中,我们增加一个新的映射 (by Label)

1
2
istioctl x revision tag set prod --revision 1-7-6
istioctl x revision tag set canary --revision 1-8-0

Namespaces A and B -> 1-7-6,
Namespace C -> 1-8-0

我们现在仅仅需要修改 tag 即可

1
istioctl x revision tag set prod --revision 1-8-0

相较于之前的版本,我们多一层抽象,这样可以保持 Namespace Label 的稳定,对于升级的行为就完全控制在 istio 的 scope 内。

Sidecar Networking Changes

在 istio 1.10 之前,所有的外部流量都会被重定向到 lo

这样有个问题,就是导致了如果应用仅仅 listen on eth0 就会导致无法处理,从 1.10 之后

所有的流量都从 eth0 进出,这样要注意,如果在 localhost 进行模拟测试会导致未经过 istio sidecar 的处理。

废弃项

  • Kubernetes 第一方 JWT 支持(values.global.jwtPolicy=first-party-jwt)将被删除;它的安全性较低,仅用于向后兼容旧版 Kubernetes。
  • values.global.arch 选项已经被 Kubernetes 配置中的 Affinity 设置所取代。

其他

  • 更新了网站的UI,变的更好看些