首页 全球新闻正文

Istio1.6新特性:Workload Entries

wangchaowh 全球新闻 2021-09-28 16:45:01 10 0

Istio

5月22号,Istio发布了1.6版本 ,旨在朝着更简单、更顺畅的安装体验迈进 。其中 ,新功能Workload Entries对尚未运行在Kubernetes中的工作负载的支持是一个重大的改进 。

今天就给大家带来这个新特性的介绍,翻译自Istio2020博客:Introducing Workload Entries。

Workload Entries: 连接Kubernetes与VM目前,Istio已经能够很好的支持运行在Kubernetes上的工作负载 ,但对跑在其他平台(如虚拟机VM和物理机)上的工作负载支持明显不足。原因有很多,比如在VM上无法显式指定Sidecar的属性 、不能很好的响应工作负载生命周期的状态变更(比如,从启动到未准备就绪到准备就绪状态 、或运行状态检查)、将负载迁移到Kubernetes时繁琐的DNS配置 。

于是 ,新发行的Istio 1.6版本对管理非Kubernetes工作负载的方式进行了一些改进,方便那些未通过容器部署应用,但希望将工作负载添加至网格的朋友显著降低具体操作难度 ,无须更改已有应用就能享受Istio带来的便利。

在Istio1.6之前,非容器化的工作负载只能够以IP地址的方式简单的被配置在ServiceEntry中,也就是说 ,他们只能作为服务的一部分而存在。Kubernetes将Pods视为计算的基本单位,充当与工作负载相关的所有事物的***点,而Istio对于这些非容器化的工作负载就缺乏一个类似这样一流的抽象能力 。

考虑下面的ServiceEntry定义 ,里面定义了一个服务 ,该服务会调用几十个用IP地址定义的VM服务:

apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata: name: svc1spec: hosts: - svc1.internal.com ports: - number: 80 name: ), 你需要怎样做?

你可能需要结合使用Kubernetes Service,Virtual Service和Destination Rule来实现这个想法。那么 ,假设你现在决定将sidecar逐个注入到这些虚拟机里,这样你就可以对这些包含sidecar的VM的流量使用Istio mTLS。如果任何其他Service Entry恰好在其地址中也使用了这个VM,则情况将变得非常复杂且容易出错 。

问题的主要来源是Istio缺乏对非容器化工作负载的定义 ,其实,这些工作负载的属性的描述完全可以独立于其所包含的服务。

从Service Entry到Workload Entry

Workload Entries: 非Kubernetes的EndpointWorkload Entry就是专门为解决这个问题而创建的。它是与Pod平行的概念,用来描述网格中非Pod类型的Endpoint 。有了这个定义 ,一切就会变得更加容易,例如在工作负载之间启用mTLS时就不需要考虑这些工作负载是否进行过容器化。

通过下面的例子,来看看如何创建一个WorkloadEntry并将其附加到ServiceEntry中:

---apiVersion: networking.istio.io/v1alpha3kind: WorkloadEntrymetadata: name: vm1 namespace: ns1spec: address: 1.1.1.1 labels: app: foo instance-id: vm-78ad2 class: vm---apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata: name: svc1 namespace: ns1spec: hosts: - svc1.internal.com ports: - number: 80 name: 也将被选上。

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结合在一起,共存在服务网格中啦 。

快来试试吧!

Workload特性EntriesIstio1.6
版权声明

本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。