通过 Istio 重新实现微服务 (三)：使用 Istio 代理运行应用

情感分析应用的架构

我们将会继续使用Kubernetes入门文章中的样例，它较为复杂，足以通过实践展示 Istio 的特性。

这个应用由四个微服务组成：

• SA-Frontend 服务：前端的 Reactjs 应用；

• SA-WebApp 服务：处理情感分析的请求；

• SA-Logic 服务：执行情感分析；

• SA-Feedback 服务：接收用户关于分析精确性的反馈。

图 6 情感分析的微服务

在图 6 中，除了服务之外，我们还看到了 Ingress Controller，在 Kubernetes 中，它会将传入的请求路由至对应的服务，Istio 采用了类似的概念，名为 Ingress Gateway，在本文后续的内容中，我们将会对其进行介绍。

使用 Istio 代理运行应用

如果要要跟着本文一起练习的话，读者可以 clone 该 GitHub 仓库 istio-mastery，其中包含了适用于 Kubernetes 和 Istio 的应用程序与 manifest。

Sidecar 注入

注入可以自动或手动完成。如果要启用自动化的 Sidecar 注入，我们需要使用istio-injection=enabled来标记命名空间，这可以通过执行如下的命令来实现：

$ kubectl label namespace default istio-injection=enablednamespace/default labeled

现在，默认命名空间中部署的所有 pod 都将会被注入 sidecar。切换至[istio-mastery]仓库的根目录，并执行如下的命令：

$ kubectl apply -f resource-manifests/kubepersistentvolumeclaim/sqlite-pvc created deployment.extensions/sa-feedback created service/sa-feedback created deployment.extensions/sa-frontend createdservice/sa-frontend created deployment.extensions/sa-logic created service/sa-logic created deployment.extensions/sa-web-app created service/sa-web-app created

执行如下的命令并检查 Ready 列，我们会看到“2/2”，这表明第二个容器已经注入进来了。

$ kubectl get podsNAME                         READY STATUS   RESTARTS   AGE sa-feedback-55f5dc4d9c-c9wfv 2/2    Running  0         12m sa-frontend-558f8986-hhkj9   2/2    Running  0         12msa-logic-568498cb4d-s9ngt   2/2     Running  0         12m sa-web-app-599cf47c7c-s7cvd 2/2     Running  0         12m

服务已经启动并运行了，每个容器都包含了 sidecar 代理，如图 7 所示。

图 7 某个 Pod 中的 Envoy 代理

但是，要访问服务，我们需要允许传入的流量进入集群，也就是所谓的 Ingress 流量。

Ingress 网关

允许流量进入集群的一个最佳实践就是使用 Istio 的 Ingress 网关，它处于集群的边缘并且靠近传入的流量，它能够实现 Istio 的多项特性，比如路由、安全和监控。

在 Istio 安装的时候，Ingress 网关组件以及将其暴露给外部的服务已经安装到了集群中，我们可以通过如下的命令获取它的外部 IP：

$ kubectl get svc -n istio-system -l istio=ingressgatewayNAME                   TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120   80:31380/TCP,443[...]

在本文后续的内容中，我们将会通过该 IP（将其称为EXTERNAL-IP）访问应用程序，为了便利起见，我们通过下面的命令将其保存到变量中：

$ EXTERNAL_IP=$(kubectl get svc -n istio-system \      -l app=istio-ingressgateway \      -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

如果你在浏览器中访问该 IP 的话，将会看到服务不可用的错误，默认情况下，在我们定义网关之前，Istio 会阻止所有传入的流量。

网关资源

网关是一种 Kubernetes 自定义资源定义（Kubernetes Custom Resource Definition），它是我们在集群中安装 Istio 时所定义的，借助它，我们能够指定允许传入流量的端口、协议和主机。

在我们的场景中，我们想要为所有主机开放 80 端口。我们可以通过如下的定义来进行配置：

apiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata:  name: http-gatewayspec:  selector:    istio: ingressgateway  servers:  - port:      number: 80      name: http      protocol: HTTP  hosts:   - "*"

除了istio: ingressgateway选择器之外，所有配置项的含义均不言自明。通过使用这个选择器，我们可以指定哪个 Ingress 网关使用该配置，在我们的场景中，也就是在 Istio 安装时的默认 Ingress 网关控制器。

通过执行如下的命令，应用该配置：

$ kubectl apply -f resource-manifests/istio/http-gateway.yamlgateway.networking.istio.io "http-gateway" created

网关允许我们访问 80 端口，但是它还不知道要将请求路由至何处，而这一功能是通过 Virtual Service 来实现的。

VirtualService 资源

VirtualService 能够指导 Ingress 网关如何路由允许进入集群的请求。

对于我们的应用来说，通过 http-gateway 的请求必须要路由至 sa-frontend、sa-web-app 和 sa-feedback 服务（如图 8 所示）。

图 8 通过 VirtualService 配置路由

现在，我们拆分一下应该路由至 SA-Frontend 的请求：

• 精确的路径“/”应该路由至 SA-Frontend 以便于获取 Index.html；

• 带有“/static/*”前缀的路径应该路由至 SA-Frontend，以便于获取前端所需的静态文件，比如级联样式表和 JavaScript 文件；

• 匹配正则表达式“^.*\.(ico|png|jpg)$”的路径应该路由至 SA-Frontend，因为它代表的是页面展现所需的图片。

这样，我们就会得到如下的配置：

kind: VirtualService metadata:  name: sa-external-services spec:  hosts:  - "*"  gateways:  - http-gateway      # 1  http:  - match:    - uri:        exact: /    - uri:        exact: /callback    - uri:        prefix: /static    - uri:    regex: '^.*\.(ico|png|jpg)$'   route:  - destination:      host: sa-frontend    # 2      port:      number: 80

这里的重点在于：

1. VirtualService 将会应用于通过 http-gateway 的请求；

2. destination 定义了请求要路由至哪个服务。

注意：上面的配置在sa-virtualservice-external.yaml文件中，它还包含了路由至 SA-WebApp 和 SA-Feedback 的配置，但是简洁期间，我们将其省略了。

通过执行如下的命令，应用 VirtualService：

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yamlvirtualservice.networking.istio.io "sa-external-services" created

注意：当我们应用该资源时（其实所有的 Istio 资源均如此），Kubernetes API Server 会创建一个新的事件，该事件会被 Istio 的控制平面接收到，然后会将新的配置应用到每个 pod 的 envoy 代理上。Ingress Gateway 控制器是 Control Plane 配置的另外一个 Envoy，如图 9 所示。

图 9 配置 Istio-IngressGateway 来路由请求

现在，我们可以通过http://{{EXTERNAL-IP}}/访问情感分析应用了。如果你遇到 Not Found 状态的话，请不要担心，有时候配置生效并更新 envoy 缓存会耗费一点时间。

在转入下一部分之前，你需要使用该应用生成一些流量。

系列回顾

通过 Istio 重新实现微服务 (一)：认识 Istio

通过 Istio 重新实现微服务 (二)：Istio 实践