介绍工作负载条目

工作负载条目简介：桥接 Kubernetes 和 VM

从历史上看，Istio 为在 Kubernetes 上运行的工作负载提供了很好的体验，但对于其他类型的工作负载，如虚拟机（VM）和裸机，则不太顺利。这些差距包括无法在 VM 上以声明方式指定 Sidecar 的属性，无法正确响应工作负载的生命周期变化（例如，从启动到未准备就绪，或健康检查），以及在工作负载迁移到 Kubernetes 时繁琐的 DNS 解决方法，仅此而已。

Istio 1.6 在如何管理非 Kubernetes 工作负载方面引入了一些变化，其驱动力是希望在容器之外的用例中更容易获得 Istio 的好处，比如在 Kubernetes 之外的平台上运行传统数据库，或者在不重写现有应用的情况下采用 Istio 的功能。

背景

在 Istio 1.6 之前，非容器化工作负载可以简单地配置为 ServiceEntry 中的一个IP地址，这意味着它们只作为服务的一部分存在。Istio 缺乏对这些非容器化工作负载的一流抽象，类似于 Kubernetes 将 Pod 视为计算的基本单位–一个命名对象，作为与工作负载相关的所有事物的集合点–名称、标签、安全属性、生命周期状态事件等。输入 WorkloadEntry。

考虑下面的 ServiceEntry，描述一个由几十个有 IP 地址的虚拟机实现的服务：

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc1
spec:
  hosts:
  - svc1.internal.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: STATIC
  endpoints:
  - address: 1.1.1.1
  - address: 2.2.2.2
  ....

如果您想以主动-主动的方式将这个服务迁移到 Kubernetes 中–即启动一堆 Pod，通过 Istio 双向 TLS（mTLS）将一部分流量发送到 Pod，并将其余的流量发送到没有 Sidecar 的 VM 上–您会怎么做？您需要使用 Kubernetes 服务、虚拟服务和目标规则的组合来实现这一行为。现在，假设您决定将 Sidecar 逐一添加到这些 VM 上，这样您就希望只有到有 Sidecar 的 VM 的流量才会使用 Istio mTLS。如果任何其他服务条目碰巧在其地址中包括相同的 VM，事情就开始变得非常复杂和容易出错。

这些复杂情况的主要来源是 Istio 缺乏对非容器化工作负载的一流定义，其工作负载的属性可以独立于其所属的服务来描述。

工作负载条目

WorkloadEntry 是专门为解决这个问题而创建的。WorkloadEntry 允许您描述非 Pod 端点，这些端点应该仍然是网格的一部分，并将其与 Pod 同等对待。从这里开始，一切都变得简单了，比如在工作负载之间启用 MUTUAL_TLS，无论它们是否是容器化的。

要创建一个 WorkloadEntry 并将其附加到一个 ServiceEntry上，您可以这样做：

---
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
  name: vm1
  namespace: ns1
spec:
  address: 1.1.1.1
  labels:
    app: foo
    instance-id: vm-78ad2
    class: vm
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc1
  namespace: ns1
spec:
  hosts:
  - svc1.internal.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: STATIC
  workloadSelector:
    labels:
      app: foo

这将创建一个带有一组标签和地址的新 WorkloadEntry，以及使用 WorkloadSelector 来选择所有带有所需标签的端点的 ServiceEntry，在这种情况下包括为 VM 创建的 WorkloadEntry。

注意 ServiceEntry 可以同时引用 Pod 和 WorkloadEntry，使用相同的选择器。现在 Istio 可以对 VM 和 Pod 进行相同的处理，而不是将它们分开。

如果要将一些工作负载迁移到 Kubernetes，且选择保留大量的 VM，则 WorkloadSelector 可以同时选择 Pod 和 VM，Istio 会自动在它们之间进行负载平衡。1.6 的变化还意味着 WorkloadSelector 可以在 Pod 和 VM 之间同步配置，并且无需手动要求以重复的策略（例如mTLS和授权）将两个基础结构作为目标。Istio 1.6 版本为 Istio 的未来发展提供了一个伟大的起点。能够像描述 Pod 那样描述网状结构之外的东西，会带来更多的好处，比如改善启动体验。然而，这些好处仅仅是副作用。核心的好处是您现在可以让 VM 和 Pod 共存，而不需要任何配置来将两者连接起来。