今天给大家带来Istio1.6的新特性介绍，翻译自Introducing Workload Entries。
新功能Workload Entries：连接Kubernetes与VM
目前，Istio已经能够很好的支持运行在Kubernetes上的工作负载，但对跑在其他平台（如
虚拟机VM和物理机）上的工作负载支持明显不足。原因有很多，比如在VM上无法显式指定Sidecar的属性、不能很好的响应工作负载的状态变更（比如，从启动到未准备就绪到准备就绪状态、或运行状态检查）、将负载迁移到Kubernetes时繁琐的DNS配置。
于是，新发行的Istio 1.6版本对管理非Kubernetes工作负载的方式进行了一些改进，以便于那些未通过容器部署应用的用户无须更改已有应用就能享受Istio带来的便利。
在Istio 1.6之前，非容器化的工作负载只能够以IP地址的方式简单的被配置在ServiceEntry中，也就是说，他们只能作为服务的一部分而存在。Kubernetes将Pods视为计算的基本单位，充当与工作负载相关的所有事物的集合点，而Istio对于这些非容器化的工作负载就缺乏一个类似这样的抽象能力。
考虑下面的ServiceEntry定义，里面定义了一个服务，该服务会调用几十个用IP地址定义的VM服务：
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
....
如果想用A-A双活方式将此服务迁移到Kubernetes中（比如启动一堆Pod，通过Istio mTLS将部分流量发送到Pods，然后将其余流量发送到没有Sidecar的VM）， 你需要怎样做？
你可能需要结合使用Kubernetes Service，Virtual Service和Destination Rule能够实现这个想法。那么，假设你现在决定将sidecar逐个注入到这些VM中，这样你就可以对这些包含sidecar的VM的流量使用Istio mTLS。 如果任何其他Service Entry恰好在其地址中也使用了这个VM，则情况将变得非常复杂且容易出错。
问题的主要来源是Istio缺乏对非容器化工作负载的定义，其实，这些工作负载的属性的描述完全可以独立于其所包含的服务。
从Service Entry到Workload Entry
Workload Entry：非Kubernetes的endpoint
Workload Entry就是专门为解决这个问题而创建的。它是与Pod平行的概念，用来描述网格中非Pod类型的Endpoint。有了这个定义，一切就会变得更加容易，例如在工作负载之间启用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和一个ServiceEntry。其中ServiceEntry使用workloadSelector来选择带有app:foo这个标签的endpoint，由于为VM创建的WorkloadEntry也含有此标签，因此也将被选上。
Service Entry指向Workload Entry
需要注意的是，ServiceEntry可以使用相同的选择器来引用Pod和WorkloadEntries，因为现在Istio可以对VM和Pod进行相同的处理，因此你无须将它们分开。
如果你想将某些工作负载迁移到Kubernetes，但选择保留大量VM也没有问题，因为WorkloadSelector既可以选择Pods也可以选择VM，Istio会自动在它们之间进行负载平衡。
Istio 1.6版本的变更还包括WorkloadSelector可以在Pod和VM之间同步配置，当对他们俩使用重复的策略（比如mTLS和授权）时也不再需要手工执行两遍了。
Istio 1.6发行版为Istio的未来提供了一个很好的起点。通过使用与Pod相同的方式来描述网格外部存在的功能，可以带来更多好处，例如改进的引导体验。但是，最重要的好处在于VM和Pod无须任何配置就可以连接在一起，共存在服务网格中啦。
网友评论