Istio 1.10 中即将发生的网络更改

背景

虽然 Kubernetes 网络是可自定义的，但典型 Pod 的网络将如下所示

应用程序可以选择绑定到环回接口lo（通常绑定到127.0.0.1），或 Pod 网络接口eth0（通常绑定到 Pod 的 IP），或两者都绑定（通常绑定到0.0.0.0）。

绑定到lo允许在 Pod 内执行诸如curl localhost之类的调用。绑定到eth0允许其他 Pod 调用该 Pod。

通常，应用程序会同时绑定到两者。但是，具有内部逻辑的应用程序（例如管理界面）可以选择仅绑定到lo以避免来自其他 Pod 的访问。此外，某些应用程序，通常是状态型应用程序，选择仅绑定到eth0。

当前行为

在 Istio 1.10 之前的版本中，运行在与应用程序相同 Pod 中的 Envoy 代理绑定到eth0接口并将所有入站流量重定向到lo接口。

这有两个重要的副作用，导致行为与标准 Kubernetes 不同

• 仅绑定到lo的应用程序将接收来自其他 Pod 的流量，而在其他情况下则不允许。
• 仅绑定到eth0的应用程序将不会接收流量。

绑定到两个接口的应用程序（这很典型）不会受到影响。

未来行为

从 Istio 1.10 开始，网络行为已更改为与 Kubernetes 中存在的标准行为保持一致。

在这里我们可以看到，代理不再将流量重定向到lo接口，而是将其转发到eth0上的应用程序。结果，保留了 Kubernetes 的标准行为，但我们仍然可以获得 Istio 的所有好处。此更改使 Istio 能够更接近其成为可与现有工作负载（零配置）一起使用的即插即用透明代理的目标。此外，它避免了意外公开仅绑定到lo的应用程序。

我是否受到影响？

对于新用户，此更改应该只会带来改进。但是，如果您是现有用户，则可能有意或无意地依赖于旧的行为。

为了帮助检测这些情况，我们添加了一个检查以查找将受到影响的 Pod。您可以运行istioctl experimental precheck命令以获取任何绑定到Service中公开的端口上的lo的 Pod 的报告。此命令在 Istio 1.10+ 中可用。**如果不采取任何措施，这些端口在升级后将无法访问。**

$ istioctl experimental precheck
Error [IST0143] (Pod echo-local-849647c5bd-g9wxf.default) Port 443 is exposed in a Service but listens on localhost. It will not be exposed to other pods.
Error [IST0143] (Pod echo-local-849647c5bd-g9wxf.default) Port 7070 is exposed in a Service but listens on localhost. It will not be exposed to other pods.
Error: Issues found when checking the cluster. Istio may not be safe to install or upgrade.
See https://istio.ac.cn/latest/docs/reference/config/analysis for more information about causes and resolutions.

迁移

如果您当前绑定到lo，则有一些选择

• 将您的应用程序切换为绑定到所有接口（0.0.0.0或::）。

• 使用Sidecar入口配置显式配置端口以发送到lo，保留旧行为。

  例如，要配置将请求发送到ratings应用程序的localhost

  apiVersion: networking.istio.io/v1beta1
  kind: Sidecar
  metadata:
    name: ratings
  spec:
    workloadSelector:
      labels:
        app: ratings
    ingress:
    - port:
        number: 8080
        protocol: HTTP
        name: http
      defaultEndpoint: 127.0.0.1:8080
  

• 使用 Istiod 中的PILOT_ENABLE_INBOUND_PASSTHROUGH=false环境变量完全禁用更改，以启用与 Istio 1.10 之前的相同行为。此选项将在将来移除。