引入工作负载条目

描述工作负载条目的新功能。

2020年5月21日 | 作者：Cynthia Coan - Tetrate，Shriram Rajagopalan - Tetrate，Tia Louden - Tetrate，John Howard - Google，Sven Mawson - Google

引入工作负载条目：连接 Kubernetes 和虚拟机

从历史上看，Istio 为在 Kubernetes 上运行的工作负载提供了极佳的体验，但对于其他类型的工作负载（例如虚拟机 (VM) 和裸机）来说，体验并不那么流畅。差距包括无法声明性地指定 VM 上 sidecar 的属性，无法正确响应工作负载的生命周期变化（例如，启动到非就绪状态到就绪状态，或健康检查），以及在将工作负载迁移到 Kubernetes 时笨拙的 DNS 解决方案，仅举几例。

Istio 1.6 对管理非 Kubernetes 工作负载的方式进行了一些更改，其动机是希望简化在容器之外的使用场景中获得 Istio 好处的过程，例如在 Kubernetes 平台之外运行传统的数据库，或在不重写现有应用程序的情况下采用 Istio 的功能。

背景

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

考虑以下描述由数十个具有 IP 地址的虚拟机实现的服务的 ServiceEntry

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 的虚拟机 - 您将如何操作？您需要结合使用 Kubernetes 服务、虚拟服务和目标规则来实现此行为。现在，假设您决定逐个向这些虚拟机添加 sidecar，以便您希望仅将到带有 sidecar 的虚拟机的流量使用 Istio mTLS。如果任何其他 Service Entry 碰巧在其地址中包含相同的虚拟机，事情就会变得非常复杂且容易出错。

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

Service Entries Pointing to Workload Entries
指向工作负载条目的服务条目的内部

工作负载条目：非 Kubernetes 端点

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。

Service Entries Pointing to Workload Entries
指向工作负载条目的服务条目的内部

请注意，ServiceEntry 可以使用相同的选择器引用 Pod 和 WorkloadEntries。现在，Istio 可以将虚拟机和 Pod 同等对待，而不是将它们分开。

如果您要将某些工作负载迁移到 Kubernetes，并且您选择保留大量虚拟机，则 WorkloadSelector 可以选择 Pod 和虚拟机，并且 Istio 将自动在它们之间进行负载均衡。1.6 中的更改还意味着 WorkloadSelector 会在 Pod 和虚拟机之间同步配置，并消除了手动为两种基础设施都设置重复策略（如 mTLS 和授权）的要求。Istio 1.6 版本为 Istio 的未来提供了良好的起点。能够以与 Pod 相同的方式描述网格外部存在的内容带来了额外的好处，例如改进的引导体验。但是，这些好处仅仅是副作用。核心好处是，您现在可以使虚拟机和 Pod 共存，而无需任何配置即可将两者连接在一起。

分享此帖子