关于istio:Banza-Cloud-重磅解读Istio-18

Istio 1.8 刚刚公布，并且是迄今为止最好的 Istio 版本之一。新版本蕴含诸多乏味的试验性能，泛滥加强性能以及不举荐应用和删除的性能。然而，此版本的外围焦点是进步操作稳定性。在这篇文章中，咱们将回顾 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
当目标地址不可达时，正确标记指标

无关更改的残缺列表，请参阅更改阐明。

从 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服务时，两种状况下都只会调用一个端口，也就意味着通过服务不可能调用到另外一个端口。这相对是不冀望的行为，并且仿佛是一个谬误。

过来，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

新增的 remoteIpBlocks/notRemoteIpBlocks 字段被用于依据申请的原始源 IP(从X-Forwarded-For Header 或代理协定获取) 容许 / 拒绝请求。

当初，AuthorizationPolicy 资源上的 ipBlocks / notIpBlocks 字段用于基于达到
Sidecar 的 IP 数据包的源地址来容许 / 拒绝请求。

如果你心愿基于申请的原始源 IP 地址来容许 / 拒绝请求（应用 X -Forwarded-For 标头或代理协定），请更新 AuthorizationPolicy 资源以应用新的 remoteIpBlocks/notRemoteIpBlocks 字段，而不是 ipBlocks/notIpBlocks 字段。

默认状况下，如果申请既不是来自同一信赖域，也不是来自 TrustDomainAliases 列表，则“信赖域验证”性能将回绝对 Sidecar 的任何传入申请。
如果要容许来自 Istio 1.8 上不同信赖域的流量进入网格，则须要将其增加到 TrustDomainAliases 列表中，否则将被回绝。

自 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。

加强 Istio 性能的开源软件（例如 Prometheus，Grafana，Zipkin，Jaeger 和 Kiali）不能再与 istioctl 一起装置，倡议将它们离开装置。

Istio Sidecar 代理当初通过 ServiceEntries 为 DNS 解析提供了原生反对，这就是为什么 Istio 1.8 中不举荐应用 Istio CoreDNS 插件，并且在当前的版本中将其删除的起因。

对于 EnvoyFilter API，建议您应用新的 Envoy 过滤器名称，因为某些过滤器名称已被弃用，并将在当前的版本中删除。

DNS 对于任何云原生应用程序都是必不可少的，然而它在 Kubernetes 中的工作形式会给 Istio 带来一些挑战：

Kubernetes 集群外的 VM 可能难以提供 DNS 解析来路由集群内的服务
如果服务没有惟一的虚构 IP 且同一端口（例如数据库），则 DNS 服务器无奈辨别它们
在多集群网格中，咱们无奈解析另一个集群上的服务的 IP 地址（这就是为什么在近程集群上同样创立存根服务的起因）

为了解决 Istio 1.8 的所有这些问题，在 Istio sidecar 代理中实现了一个用 GO 编写的 DNS 代理。此 DNS 代理由 Istiod（基于集群上的服务和 ServiceEntries）动静更新，并充当缓存。它将尝试依据其缓存解析所需的主机名，并且仅在缓存未注册主机名时才转向内部 DNS 服务器。

这是一项令人兴奋的新性能，能够立刻尝试应用，但默认状况下未启用。要浏览无关此新性能的深刻阐明，请确保查看此博客文章。

要为 Istio 网格注册 VM，到目前为止，惟一的办法是手动创立 WorkloadEntry 资源。然而在主动扩大 VM 的状况下，这可能会引起问题，在这种状况下，主动注册新 VM 并不容易。
有一个预 Alpha 性能能够解决此问题，从而能够主动注册 VM。这由新的 WorkloadGroup 资源实现，该资源负责在有新 VM 可用时主动创立 WorkloadEntry 资源。
Istio 1.8 版本为围绕 VM 反对的各种性能奠定了根底，随着它的成熟，在未来的版本中应该会变得不言而喻。

从 Kubernetes 1.18 开始，具备 CSR API 性能，该性能可主动执行来自证书颁发机构（CA）的证书申请。在 Istio 1.8 中，增加了实验性反对，以容许 Istio 应用 Kubernetes CSR API 与内部 CA 集成。
此性能只是为应用内部 CA 奠定了必要的根底，当初仅反对 istiod（并有些反对 Google CA），然而随着该性能在 Istio 和 Kubernetes 方面都日趋成熟，未来的版本中应该会引入新的实现。

以前，网关从 Kubernetes secret 读取证书进行内部通信。这些网关通常是面向公众的实体，如果受到攻打，则能够导致整个集群的 Kubernetes secret 中的证书透露。
在 Istio 1.8 中，网关从 Istiod 获取证书。他们甚至没有特权来从集群中读取 secret，以缩小潜在的侵害。
此性能很乏味，因为它为咱们提供了一种路径，使咱们可能在未来的版本中从内部 secret 存储区（例如，保存库或云密钥存储区）中获取证书，这对于曾经应用其余机密存储区的许多 Istio 用户来说很不便。此外，这是齐全向后兼容的更改，不须要任何用户交互。

为了指定 Envoy 配置的 HTTP_ROUTE 标准的程序，新的 INSERT_FIRST，INSERT_BEFORE，INSERT_AFTER 操作已增加到 EnvoyFilter API。为了可能笼罩 HTTP 和网络过滤器，在 EnvoyFilter API 中增加了新的 REPLACE 操作。

增加了一个新的 istioctl bug-report 命令，以便可能获取 Istio 集群的存档 – 次要用于调试目标。

大概两年前，当咱们开源 Banzai Cloud Istio operator 时，咱们这样做的局部起因是，装置 Istio 的惟一抉择是通过 Helm，它存在问题。一段时间后，引入了 istioctl，而后引入了正式的 Istio operator，并且，逐步地，Helm 的装置办法不再受反对。然而，事实证明，Istio 用户依然须要一种应用 Helm 装置和降级 Istio 的办法（次要是针对曾经应用 Helm 部署了所有应用程序的用户），因而，为 Helm 3 增加了反对 Istio 1.8。
因而，能够应用 Helm 3 装置和降级 Istio，然而在此我不建议您这样做。Helm 仅反对就地降级，而明天倡议应用金丝雀降级模型。

自 1.6 版以来，Istio 中曾经有了一个乏味的 alpha 性能，其中无关 Istio 资源的各种有用信息都显示在其 Status 字段中。这些字段包含但不限于资源筹备状况，与资源关联的数据立体实例的数量以及验证音讯。
在 Istio 1.8 中，还会呈现一个新的察看到的 generation 字段，当该字段与资源元数据中的生成匹配时，表明所有 Istio 更新均已实现。这对于检测何时提供了对 Istio 配置的申请更改并筹备接管流量很有用。

随着 WebAssembly（Wasm）在 Istio 中取得越来越多的关注，为了正确地监督它，也逐步须要它。因而，在 Wasm 相干指标上应用新增加的 Grafana 仪表板会很不便。

以前，有些状况下申请没有达到指标代理（例如，故障注入，断路，没有注入代理等），并且没有指标标签来标识什么将成为申请的最终目标。在 1.8 版中对此进行了修复，这是一个受欢迎的谬误修复程序。

Istio 1.8 大大提高了操作稳定性，也为未来版本中令人兴奋的新性能奠定了根底。

PS: 本文属于翻译，原文

关于istio:Banza-Cloud-重磅解读Istio-18

Istio 1.8 变动 ︎

重大影响变动 ︎

Inbound 集群名格局变更 ︎

默认禁用 Protocol detection timeout ︎

AuthorizationPolicy 新增 remoteIpBlocks/notRemoteIpBlocks 字段 ︎

默认强制启用 Trust Domain Validation ︎

移除 / 弃用 ︎

齐全移除 Mixer ︎

istioctl 不再反对装置 add-ons ︎

Istio CoreDNS Plugin 弃用 ︎

Envoy filter names 弃用 ︎

试验个性 ︎

智能 DNS 代理 ︎

主动注册 VMs ︎

通过 K8s CSR API 集成内部 CAs ︎

较小但有用的变更 ︎

Istiod 解决 gateway 证书 ︎

EnvoyFilter 加强 ︎

增加了调试存档选项 ︎

其余值得注意的变动 ︎

通过 Helm3 部署 Istio ︎

为 Istio 资源状态增加 generation 字段 ︎

新增 Wasm Grafana dashboards ︎

当目标地址不可达时，正确标记指标 ︎

总结 ︎