Istio 开门七件事

Service Mesh 越来越热，虽说尚未决出最终赢家，但是这一生态的存在和发展确已经成了定势。Istio 目前最新是 0.7.1 版本，其中非常重要的路由规则仅仅是 alpha3 版本，因此对其可靠性是没有承诺的。但不管是哪个阶段，因为业务需求不同，对 Istio 的需求也不会完全一致，只有经历 Staging 甚至是 Production 一级的试用，我们才能确切的认识到这样一个系统能否满足我们自身业务的需求。

下面以一个应用中的部分服务进行 Istio 试用的场景，来讲讲开始尝试 Istio 丰富Bug功能之前，需要做点什么准备工作。

应用准备

一般来说我们不会选择一个应用中的所有业务进行改造，而是选择其中部分的微服务作为金丝雀来进行试错。选定部署目标之后，需要对待测试服务的依赖项目进行一下分类：

• 相对部署位置：集群外、Kubernetes集群、Istio 集群。
• 通信协议：HTTP/TCP

这里需要根据结果，集群外的服务创建 egress 资源，防止试点服务无法完成对依赖服务的访问；

• 同一 Kubernetes/Istio 集群内的服务是可以按需互访的。
• Kubernetes 集群外的服务需要使用 egress 资源来定义访问规则。

另外应用的 Deployment、Service 等资源的标签需要按照 Istio 要求进行检查。

切换准备

试用之前，应该在负载均衡/反向代理等边缘网络上，对试点服务进行切换准备，保证从 Service Mesh 内外可以自由切换。

K8S 集群准备

对 Kubernetes 集群版本的要求：最低版本 1.7.3，并需要激活 RBAC，如果使用自动注入，需要 1.9 以上版本的 Kubernetes 集群。当然 Kubectl 也需要合适的 1.7.3 以上的版本。

RBAC 方面，需要提供 cluster-admin 账号进行安装。

Istioctl 需要和 Kube Config 配置文件协作，因此合适的配置文件也是必须的。

Istio 的安装

• 查找当前 Istio 中需要使用的镜像列表。

例如使用下列命令，查找所有 yaml 中涉及到的镜像： grep -r image: *| grep -v "helm" | egrep -o "\S+?$" | sort | uniq

• 拉取镜像并上传到私库。
• 修改 istio 以及几个监控 yaml 中的镜像地址。
• 复制 bin 目录中的 istioctl 到本地。
• kubectl apply -f 所需的 yaml。

外部访问

访问外部服务有两种方式

Egress

如果外部服务会同时被多个 Mesh 内访问，或者需要像 Mesh 内服务一样对外部服务进行一些控制，就可以设置为 Egress 方式。例如打开对 httpbin.org 的访问：

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
 name: httpbin-timeout-rule
spec:
 destination:
   service: httpbin.org
 http_req_timeout:
   simple_timeout:
     timeout: 3s

注意 v1alpha3 版本的 Egress 似乎还无法使用。

单应用放行

可以在注入时，为应用指定一个 IP 地址范围，超出这一范围的所有地址都会被 Envoy 直接放行。

这种方式适用于性能敏感或者无需控制的情况，例如数据库。

应用部署

使用 --includeIPRanges 和 --hub 两个参数，对注入进行调整；更复杂的还可以直接使用 --injectConfigMapName 对注入配置进行自定义。

基础路由

为每个部署的应用，做好优先级为 0 的基础路由，将服务导入缺省版本的实例之中。

官方建议尽量使用 v1alpha3 版本。

开始

上述步骤完成后，应该首先进行一轮冒烟测试以及压力测试，确认基本功能不受影响，达到使用要求，并且可以正确获得监控结果之后，才可以进一步的设置 Istio 的功能。