涨姿势！将部署在虚拟机里的服务接入Istio-技术圈

来源：https://segmentfault.com/a/1190000038799970

Istio在设计之初，主要面向Kubernetes当中的服务。但是在实际场景中，依旧有不少服务部署在VM上，Istio想成为Service Mesh事实上的标准，毫无疑问需要支持VM部署的服务。

Istio1.6 新增了 WorkloadEntry 自定义资源，通过该资源为VM提供了一流的支持。

Istio1.7 增加了安全引导VM中运行的服务的身份的功能。最后，Istio 1.7增加了Sidecar的安装包，以支持CentOS/Red Hat和现有的Debian/Ubuntu。

Istio1.8 新增了智能 DNS 代理，它是由 Go 编写的 Istio sidecar 代理，sidecar 上的 Istio agent 将附带一个由 Istiod 动态编程的缓存 DNS 代理。来自应用程序的 DNS 查询会被 pod 或 VM 中的 Istio 代理透明地拦截和服务，该代理会智能地响应 DNS 查询请求，可以实现虚拟机到服务网格的无缝多集群访问。

并且Istio1.8新增了 WorkloadGroup 自定义资源，该资源是描述部署在VM上的服务实例的集合，旨在模仿现有的用于Kubernetes工作负载的Sidecar注入和Deployment规范模型，以引导Istio代理。

通过 WorkloadGroup方式，实现VM 实例自动注册的功能目前处于pre-alpha状态

WorkloadEntry

WorkloadEntry用来描述非Pod的端点，将VM纳入mesh中。此时VM成为像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和WorkloadEntries。现在，Istio可以对VM和Pod进行相同的处理，而不必将它们分开。

VM自动注册

WorkloadGroup主要用于 WorkloadEntry 自动注册，该功能在实际场景中比较实用。事实上我们部署在VM当中的服务，一般都会配置自动伸缩，这就要求我们的服务必须可以自动注册到mesh中。

如何实现自动注册那？

首先我们需要做一些准备工作：

在安装istiod的时候，启用自动注册的功能。

$ istioctl install --set values.pilot.env.PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION=true

部署一个east-west gateway。用于暴露istiod服务，从而可以让VM上的Sidecar 可以和istiod 通信。

然后我们创建如下的 WorkloadGroup：

apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
  name: python-http
  namespace: vm
spec:
  metadata:
    annotations: {}
    labels:
      app: python-http
  template:
    ports: {}
    serviceAccount: my-vm

这样我们在每个vm上python-http 实例启动后，都会自动在mesh中创建一个WorkloadEntry。而创建的WorkloadEntry，包含了VM实例的ip和元数据。此时我们就可以创建一个ServiceEntry，通过标签选择器选择我们的WorkloadEntry。然后mesh中的其他服务就可以通过ServiceEntry中的hosts，对我们的python-http服务进行访问。

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: vm-workload-svc
  namespace: vm
spec:
  hosts:
  - vmservice.example.com
  location: MESH_INTERNAL
  ports:
  - number: 80
    name: http
    protocol: HTTP
    targetPort: 9090
  resolution: STATIC
  workloadSelector:
    labels:
      app: python-http

关于VM详细的安装步骤，参考官方文档。

智能DNS

其实完成VM自动注册，并不能通过主机名实现虚拟机到服务网格的无缝访问。例如，如果我们在VM上部署Istio sidecar代理，我们将无法通过主机名（例如httpbin.default.svc.cluster.local）访问网格和Kubernetes集群中服务。此时我们需要智能DNS。

在Istio 1.8中，Sidecar现在具有一个DNS代理，该代理缓存网格中的端点和ServiceEntry资源创建的端点。通过Iptables规则，拦截dns请求到sidecar 本地dns server，在缓存中可以解析的主机名，则直接返回解析结果，如果找不到，它将作为普通DNS代理委派给系统DNS。这样vm上的服务可以通过主机名访问mesh中的服务。

智能DNS 默认没有启用，我们在安装istio的时候，可以通过如下参数启用该功能：

--set meshConfig.defaultConfig.proxyMetadata.ISTIO_META_DNS_CAPTURE=true

总结

当VM连接到Istio控制平面时，它通过“东西向网关”进行连接。该网关实际上只是一个专门为网格内部流量指定的Istio网关，现在，东西向网关已经是Istio 1.8中的推荐部署。一旦从VM Sidecar到Istio控制平面建立了连接，便会创建适当的WorkloadEntry资源，并使VM Sidecar可以解析集群中的所有服务。从VM上部署服务可以直接访问httpbin.default.svc.cluster.local。DNS名称由代理解析，并通过“东西方网关”路由到网格中的适当服务。

- END -


 推荐阅读 

31天拿下Kubernetes含金量最高的CKA证书！ 
Linux 系统中成功恢复已删除的文件
图解 Kafka，入门好文
Linux 系统安全强化指南
这个程序占用CPU特别高！秒级定位线上问题
从零开始搭建创业公司DevOps技术栈
Shell 脚本进阶，经典用法及其案例
2021年的DevOps趋势预测
Kubernetes+Helm+Jenkins 自动化发布项目
搭建一套完整的企业级 K8s 集群（v1.20，kubeadm方式）
60道常见的 Kubernetes 面试题总结


点亮，服务器三年不宕机