虚拟机和容器如何相互通信? Istio网格如何让这一过程变得更容易? 自从Istio发布1.6版本以来,它帮助将虚拟机纳入网格的控制并使该过程明显变得更容易。 使用Istio可以更轻松的管理所有环境。

首先我们在考虑复杂的混合环境之前,最好先解释一下容器网络是如何与服务网格一起工作以及这样的工作是如何体现的。毕竟,当你能够将所有的环境集中在单一控制平面下时,开发团队就不需要过多关心容器配置,而是着重于关注容器的运行。

使用Kubernetes进行服务间的通信

让我们以虚构公司TP Inc为例。 我们已经概览了他们表现在Kubernetes中的的服务结构,该公司运行了相当多的 服务服务实例 ,这些服务和实例都需要相互通信。

What's a service? A service is a logical grouping (as opposed to a physical grouping) of Kubernetes pods that perform the same function. What’s a service instance? Each 'pod' is a service instance, which is an independent package that contains all the code to run a process or an app. There are usually multiple instances in a service, serving traffic to make sure that the service remains available.

 

在大多数情况下,大多数服务都运行了多个服务实例,这确保了它们能够始终高效地响应请求。如果这些服务实例中的任何一个变得不健康并停止响应请求,就有足够的冗余来保持服务的运行,直到坏实例再次健康。

Architecture diagram showing how TP Inc's services are arranged - there is a pod inside a service instance which is inside a service grouping

TP Inc 为了管理他们的环境还使用了Istio服务网格,控制环境中的流量以及保证服务安全。

要更深入地了解服务网格的作用,请下载Istio: Up and Running (O’Reilly) 的免费PDF副本,作者是Zack Butcher和Lee Calcote。


流量转移

TP Inc是一家高速发展的现代化公司。 他们希望能够在确保继续维护好自己的基础设施的同时保持服务的常规更新,从而不会出现更新破坏他们的服务并使用户无法访问的风险。这就是为什么流量转移是一个很好的安全机制,以确保新的部署能够按预期工作。

由于Envoy代理代表服务实例处理所有的流量请求,因此它几乎就像传统的负载均衡器一样处理它收到的每个请求。然而,Istio可以帮助sidecar做得更多。Istio是一个 “控制平面”,这意味着它通过规定Envoy sidecar必须执行的策略来管理它们,并实现更精细的流量路由。一个很好的使用案例是测试代码的新版本。如果服务实例1运行的是比服务实例2更新的版本,开发人员可以向服务实例1发送30%的流量/请求,以验证它是否按照预期工作,然后再将更改推送给该服务的所有实例。或者如果服务实例1没有按照预期工作,那么开发人员可以更改Istio配置,重定向流量,同时坏实例可以被删除。

流量安全

保持流量(包括内部和外部流量)安全对任何企业来说都很重要。 TP Inc的服务(如订单执行)会包含向其购买商品的购物者个人信息,因此保护用户信息是至关重要的,保证流量的安全是极度重要的。

我们来考虑一个进入TP Inc的服务的外部请求。 用户尝试下单。库存管理系统确认该商品有库存,用户可以购买该商品,并将该请求转移到支付系统,在那里用户提供他们的个人信息。之后,订单执行服务收到数据,让仓库进行包装和邮寄。这里出现了大量的个人信息,还有很多需要充分保护和加密的连接。

Istio实现了 “零信任架构 “的概念,它强制默认没有任何东西是自动信任的。所有试图访问网络或与网络交互的东西都必须在事物发生之前进行验证。IstioD是零信任概念的中心枢纽。它提供证书和策略,让Envoy sidecar既能证明自己的身份,又能验证他人的身份,而这是由 “mTLS”(相互传输层安全协议)实现的。

KEY TERMS What is a certificate authority? A certificate authority issues digital (SSL) certificates that provide devices (and services) with a verifiable identity. They are a third party that is trusted both by the owner of the certificate and the one relying on its authenticity. What are authentication policies? An authentication policy requires parties attempting to gain access to services present a valid certificate proving they are who they claim to be. What are authorization policies? Authorization policies are set by administrators, and enforced by the Envoy Proxy with a binary response of ‘allow’ or ‘deny’ to any request that they receive. If these policies are enabled, then the default response by Envoy Proxy is to ‘deny’ requests unless explicitly specified in the policy. What is an API server configuration? The API server distributes the Authentication and Authorization policies and the secure name that the Certificate Authority provides to the Envoy Proxies. What is mTLS? mTLS (mutual Transport Layer Security) is an authentication method where both the service initiating the transaction and the service responding to it, both mutually provide evidence of their identity so that the transaction can take place. Neither trusts the other until they’ve proven who they are.

IstioD帮助实施的所有安全措施都是为了将风险降到最低,而不是为了消除所有风险。 确保策略被正确启用并按照要求行事是组织的责任。 Istio是执行者而非发起者。 TP Inc的管理员需要确保他们已经适当详细说明了策略以及这些策略应该如何被Istio执行。 如果因为授权策略不够强大而出现对服务的不当访问问题,那么后果可能很严重。

拟机到Kubernetes的通信

之前TP Inc的图展示了他们的Kubernetes设置。但想象一下,该公司还有一些服务在虚拟机上运行。 直接在Kubernetes上运行全部服务是不太可能的,而且 “传统 “基础设施也没有出现什么问题。

直到最近之前,让虚拟机和Kubernetes进行通信都并不容易。 Istio 1.6版本为Istio带来了一些实质性的功能更新,让VM和Kubernetes在Istio中得到了相同的待遇。 它通过给虚拟机一个sidecar和一个身份,让Istio网格可以通过这个身份来识别它,并在同一个平台上进行控制,从而将这两种类型的基础设施结合在一起管理。 对于那些管理混合环境的人来说,这帮了很大的忙。

现在虚拟机在服务网格的控制下,这意味着流量可以更容易地在两者之间传输,网格可以对流量传输的方式提供更多的控制。容器所带来的所有流量转移和安全功能现在都可以支持虚拟机。

对于网络团队来说,这意味着节省了很多时间!不需要重复配置,也不需要做任何更多的手动干预来让服务一起工作。同样,如果你打算将服务迁移到容器上,你的生活就会变得简单很多。这些好处是巨大的,并且还有更多便利即将到来。

经验

Istio的目的是解决开发人员的顾虑,让他们可以专注于业务逻辑而非运行服务的环境。然而,企业仍然需要注意哪些服务可以相互通信和它们之间可以共享哪些信息。

Tia louden headshot

 

 

Tia Louden is a content writer for Tetrate. Tetrate’s products make it easier for enterprises to adopt Istio and Envoy and to manage microservices on any workload, in any environment.

Author(s)