关于istio:Istio中访问外部服务

35次阅读

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

默认状况下，来自启用 Istio 的 Pod 的所有出站流量都会重定向到其 Sidecar 代理，因而集群内部 URL 的可拜访性取决于代理的配置。网格中的工作负载想要拜访网分外的服务时，有以下三种办法：

容许 Envoy 代理将申请透传到未在网格外部配置的服务。
配置 ServiceEntries 以提供对外部服务的受控拜访。
对于特定范畴的 IP，齐全绕过 Envoy 代理。

默认 Istio 将 Envoy 代理配置为透传对未知服务的申请，这简化了利用程序开发以及现有应用程序到网格的迁徙。

第 2 种办法，应用 Istio ServiceEntry 配置，您能够从 Istio 集群中拜访任何可公开拜访的服务。而且不失落 Istio 的流量监督和管制性能。该办法也是本文次要讲述的办法。

对于第三种办法，通过 global.proxy.includeIPRanges 配置。对于一些对性能要求比拟高的利用能够抉择应用，然而须要保障 IP 范畴在一个可信的环境下。

Istio 有一个装置选项meshConfig.outboundTrafficPolicy.mode，用于配置对外部服务（即 Istio 外部服务注册表中未定义的那些服务）的解决形式。如果此选项设置为ALLOW_ANY，则 Istio 代理将容许对未知服务的调用。如果该选项设置为REGISTRY_ONLY，则 Istio 代理将阻止在网格中未定义 HTTP 服务或 ServiceEntry 的任何主机。

默认状况下，ALLOW_ANY为该配置项的默认值。

ServiceEntry 是扩大 Istio 服务注册表的一种形式，以便现有的主动发现的服务能够拜访其余服务，无论它们是未发现的外部服务还是齐全在网格内部的服务（例如，Web API）。

通过配置 ServiceEntry，您能够治理在网格内部运行的服务的流量，包含以下性能：

重定向和转发用于内部指标的流量，例如从网络应用的 API 或到旧根底构造中服务的流量。
为内部指标定义重试，超时和故障注入策略。
通过将虚拟机增加到网格中，在虚拟机（VM）中运行网格服务。
在逻辑上将来自其余集群的服务增加到网格，以在 Kubernetes 上配置多集群 Istio 网格。

以下示例形容了外部应用程序应用 DNS 通过主机名解析通过 HTTP 拜访的内部 API。

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: httpbin.org
  namespace: foo
spec:
  hosts:
  - httpbin.org
  - www.httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
  exportTo:
  - "."
  resolution: DNS
  location: MESH_EXTERNAL

咱们对该配置逐个字段解析：

hosts：DNS 名称。能够具备通配符前缀。
ports：关联的端口。
ports.protocol：以下之一：HTTP，HTTPS，HTTP2，GRPC，MONGO，TCP 或 TLS。
exportTo：默认状况下应用“*”，这意味着该 ServiceEntry 公开给每个命名空间。“.”仅将其限度为以后命名空间。目前，exportTo 值仅限于这两个。
resolution：主机的服务发现模式
location：从网格的角度来看，应将此服务视为外部或内部服务。

这里的字段并不是 ServiceEntry 反对的所有字段，更多请查看官网文档。

该 demo 咱们不仅仅是演示如何通过 ServiceEntry 拜访内部服务，而且是演示如何对外部服务定义注入超时等策略。

1: 部署之前先部署咱们的 sleep pod，作为网格内的工作负载。因为咱们在之前的文章中曾经部署实现，所以这里略过。

kubectl get pods -n foo
NAME                       READY   STATUS    RESTARTS   AGE
httpbin-779c54bf49-dqmgm   2/2     Running   0          27h
sleep-d6b58ff57-jl8pq      2/2     Running   0          27h

2: 将下面示例 ServiceEntry 利用到集群中。

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: httpbin.org
  namespace: foo
spec:
  hosts:
  - httpbin.org
  - www.httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
  exportTo:
  - "."
  resolution: DNS
  location: MESH_EXTERNAL
EOF

3：从 sleep 的 Pod 外部，向 http://httpbin.org 内部服务的 /delay 端点收回 curl 申请：

$ kubectl exec sleep-d6b58ff57-jl8pq -c sleep -n foo -- time curl -o /dev/null -s -w "%{http_code}n" http://httpbin.org/delay/5
200
real    0m 5.70s
user    0m 0.00s
sys    0m 0.00s

该申请应在大概 5 秒钟内返回 200(OK)。

4: 对外部服务 httpbin.org 减少超时设置，咱们须要创立一个 VirtualService 如下：

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin.org
  namespace: foo
spec:
  hosts:
    - httpbin.org
    - www.httpbin.org
  http:
  - timeout: 3s
    route:
      - destination:
          host: httpbin.org
        weight: 100
EOF

5: 再次从 sleep 的 Pod 外部，向 http://httpbin.org 内部服务的 /delay 端点收回 curl 申请：

kubectl exec sleep-d6b58ff57-jl8pq -c sleep -n foo -- time curl -o /dev/null -s -w "%{http_code}n" http://httpbin.org/delay/5
504
real    0m 3.01s
user    0m 0.00s
sys    0m 0.00s

这次 3 秒后呈现 504(网关超时)。只管 http://httpbin.org 期待 5 秒，但 Istio 却在 3 秒时截断了申请。

事实的世界中，并不能做到所有的业务都容器化，Istio 也意识到了这个问题，所以正在反对非容器部署的业务。除了 ServiceEntry，又减少了 WorkloadEntry，从而反对将 vm 部署的业务纳入 mesh 中。

正文完