关于istio:如何将部署在VM中的服务纳入Istio

53次阅读

共计 2889 个字符，预计需要花费 8 分钟才能阅读完成。

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 用来形容非 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 进行雷同的解决，而不用将它们离开。

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 具体的装置步骤，参考官网文档。

其实实现 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 名称由代理解析，并通过“东西方网关”路由到网格中的适当服务。

正文完