istio-2：istio1.4.2-demo部署与体验，聊聊一些个人看法

目录：

(1).python-flask-demo准备

1.相关工程

2.配置国内镜像加速

3.镜像制作与验证

3.1.python-flask镜像制作与验证

3.2.python-flask-demo镜像制作与验证

(2). istio化flask-demo

(3).istio化客户端服务并验证istio-flask-demo

(4).初探istio度量

1.概述

2.Istio Workload Dashboard

3.Istio Mesh Dashboard

4.小结：随便聊聊istio

(5).istio目标规则与路由初探

(6).随便聊聊容器化/云原生/企业级能力/公司竞争的一些个人看法

(7).广告：帮公司招人/推荐

(8).相关文章

a.阅读/实践本文请您先行阅读/实践我公众号的相关文章：

kubernetes-1：使用kubeadm搭建K8S单master节点集群

istio-1：部署与体验istio-1.4.2

b.本文主要以《深入浅出Istio：Service Mesh快速入门与实践》中的python-flask-demo为例论述。

c.架构实战交流钉钉群号：23394754

(1).python-flask-demo准备

1.相关工程

笔者提供书中的demo code，位于：

https://github.com/istio-learning/istio-demo/tree/master/istio-1.4.2/simple-flask-app

依赖于python3.6.8的镜像制作地址：

https://github.com/hepyu/docker-custom-image/tree/master/python/python-flask/python3.6.8-flask

验证istio-flask-server的cilent容器化工程与脚本位于：

https://github.com/istio-learning/istio-demo/tree/master/istio-1.4.2/simple-flask-app-client

2.配置国内镜像加速

默认的hub.docker很慢，需要改为国内镜像源。

/etc/docker/daemon.json

{
     "registry-mirrors": ["http://hub-mirror.c.163.com/"]
}

3.镜像制作与验证

3.1.python-flask镜像制作与验证

制作python-flask镜像，下载：

https://github.com/hepyu/docker-custom-image/tree/master/python/python-flask/python3.6.8-flask

直接执行： sh ./build.sh

验证：

[root@future docker-custom-image]# dockerimages | grep -i python
python3.6.8-flask                             latest              909120dc1740        6 minutes ago       933MB

3.2.python-flask-demo镜像制作与验证

下载：

https://github.com/istio-learning/istio-demo/tree/master/istio-1.4.2/simple-flask-app

直接执行：sh ./docker-image-build.sh

验证：

[root@future istio-demo]# docker images |grep -i app
simple-flask-app                              latest              09a6a1fb65e6        5 minutes ago       933MB

cd kuberntes

执行：kubectl apply -f simple-flask-app.yaml

验证：

[root@future kubernetes]# kubectl get all |grep -i flask
pod/flaskapp-v1-d9fd96dc7-vtp64    1/1    Running   0          10s
pod/flaskapp-v2-78ff6bfbc9-v7r49   1/1    Running   0          10s

kubectl exec -it flaskapp-v1-d9fd96dc7-vtp64-- /bin/bash

执行curl验证服务：

root@flaskapp-v1-d9fd96dc7-vtp64:/app/3rd/simple-flask-app#curl http://127.0.0.1:7777/env/PATH
/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binroot@flaskapp-v1-d9fd96dc7-vtp64:/app/3rd/simple-flask-app#

说明整个过程是没有问题的。

因为我们要讲istio等组件注入flask-demo，所以先删除pod。

cd kubernetes执行：kubectl delete -f .

(2). istio化flask-demo

使用命令将simple-flask-app.yaml注入istio组件的相关配置：

istioctl kube-inject -fsimple-flask-app.yaml > simple-flask-app-istio.yaml

执行命令完成容器化：

kubectl apply -f simple-flask-app-istio.yaml

验证：

[root@future kubernetes]# kubectl get all
NAME                               READY   STATUS   RESTARTS   AGE
pod/flaskapp-v1-7bb5954f8f-db45r   2/2    Running   0          39s
pod/flaskapp-v2-5cc7748ddb-m4x8x   2/2    Running   0          39s

可以看到每个POD的容器个数变为2，因为istio注入了sidecar：

kubectl describe pod flaskapp-v1-7bb5954f8f-db45r

命令查看可以看到多了一个容器：istio-proxy

Containers:
 flaskapp:
   Container ID:  docker://9409c9a6b15a426dbbdfb100ce6301d28334381854bde42138cb0b298c86e82a
   Image:          simple-flask-app
   Image ID:      docker://sha256:09a6a1fb65e61d9db0cb872949ae07197b56c9f93499663dee4f23b1be70cbf2
   Port:           <none>
   Host Port:      <none>
   State:          Running
     Started:      Tue, 24 Dec 201900:07:54 +0800
   Ready:          True
   Restart Count:  0
   Environment:
      version: v1
   Mounts:
     /var/run/secrets/kubernetes.io/serviceaccount from default-token-88mgq(ro)
 istio-proxy:
   Container ID: docker://e4c69d45047b6b7d0235e2134ad11795ff483743371f00b23891c9e4fd55c558
   Image:         docker.io/istio/proxyv2:1.4.2
   Image ID:     docker-pullable://istio/proxyv2@sha256:c98b4d277b724a2ad0c6bf22008bd02ddeb2525f19e35cdefe8a3181313716e7
   Port:          15090/TCP
Host Port:     0/TCP

(3).istio化客户端服务并验证istio-flask-demo

进入目录：

https://github.com/istio-learning/istio-demo/tree/master/istio-1.4.2/simple-flask-app-client

执行命令注入istio组件：

istioctl kube-inject -f simple-flask-app-client.yaml> simple-flask-app-client-istio.yaml

执行命令进行容器化：

kubectl apply -f simple-flask-app-client-istio.yaml

注意：

Istio是要求pod必须有service。

查看下完整的组件：

进入client-pod，我们访问下istio-flask-app服务：

kubectl exec -it -n istio-app simple-flask-app-client-584588ccbd-rtkv9-- /bin/bash

输入命令：

for i in `seq 100`; do http --bodyhttp://flaskapp:7777/env/version; done

这个命令的含义是：访问接口10次。

可以看到执行结果：

bash-4.4# for i in `seq 10`; do http --bodyhttp://flaskapp:7777/env/version; done
v2
v1
v1
v2
v1
v2
v1
v2
v2
v1

可以看到两个simple-flask-app的pod的访问量基本上是各50%，符合我们的预期。

(4).初探istio度量

1.概述

我们通过长时间访问istio-flask-app来观察/了解istio的度量：

for i in `seq 100000`; do http --bodyhttp://flaskapp:7777/env/version; done

关于istio度量，后边会专门开一篇文章去探讨，这里只是做初步的展示。

官方istio度量包含：

2.Istio Workload Dashboard

可以看到不同服务的workload情况：

仔细观察上图的Workload下拉框，可以看到istio是支持以及如何支持灰度的：

我们在yaml里边：

Flask-service -> 挂了两个版本的flask-deployment，分别是v1，v2；在dashboard里可以看到体现。

3.Istio Mesh Dashboard

可以看到每个service的重要性能数据，其中我们通过Success Rate可以拓展出完备/完善的SLA度量。

4.小结：随便聊聊istio

内容太多，这里只是随便聊聊，以后有时间看情况会详细阐述。

Istio在K8s架构体系基础上做了进一步的完备与完善，将原来很多需要基础架构/框架涵盖的范围纳入到了基础设施里，更容易推行/实现工业标准化，这是一个长期的过程。

但是落地生产可能还需要更多的观察和策略，比如在容器化的所有准备工作完成的前提下，可以考虑将一些不重要/访问量低的服务(admin后台之类的)istio服务化，性价比最高。

基于istio的度量我们其实是可以进行二次开发的，还有很多细节可能需要定制化，比如适合自己公司的SLA体系，metric存储的优化等等。

(5).istio目标规则与路由初探

进入到前述github工程的这个目录：

istio-demo/istio-1.4.2/simple-flask-app/Kubernetes

先将目标规则容器化：

kubectl apply -f simple-flask-app-destinationrule.yaml

文件内容如下，这里定义了一个istio中的对象DestinationRule，它利用Pod标签把flaskapp服务拆分成两个subset，并分别命名为v1, v2。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: flaskapp
 namespace: istio-app
spec:
 host: flaskapp
 subsets:
  -name: v1
   labels:
     version: v1
  -name: v2
   labels:
     version: v2

接下来为flaskapp服务创建路由规则，业界大佬建议不论是否进一步的流量控制，都为网格中的服务创建默认的路由规则，以防发生意料之外的访问结果(崔秀龙大佬语)。

创建路由规则，还是在相同目录下执行:

kubectl apply -fsimple-flask-app-destinationrule.yaml

文件内容如下，可以看到，将流量全部执行了v2版本：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: flaskapp-vs
 namespace: istio-app
spec:
 hosts:
  -flaskapp
 http:
  -route:
    -destination:
       host: flaskapp
       subset: v2

我们进入之前的simple-flask-app-client的pod来测试验证下流量控制是否生效：

当你进行到这里的时候，之前脚本访问的10万次还在执行中，执行完上述路由规则后，可以看到打印的全部是v2，把vs中的流量切为v1后，打印又全部变为v1。

说明流量控制确实是生效了。

更复杂的操作，后续文章再行探讨。

(6).随便聊聊容器化/云原生/企业级能力的一些个人看法

内容太多，这里只是随便聊聊，以后有时间看情况会详细阐述。

说一个最终目标：

在容器化/云原生的大前提下，结合基础框架，基础中间件等基础架构体系，提供一个技术/业务中台的快速，高效的支持企业级复制能力。

再说的扯一点：

过往的时代，企业特别是创业型的互联网公司比较忌讳的是多元化，就是什么都想做都想搞，然后大概率挂了，必须专注。

那么在云原生的时代下呢？恐怕会出现天翻地覆的剧变，不论从公司角度，还是从技术/个人角度，都可以在技术上提供快速/高效多元化的发展可能。

从公司角度来说，如果想说我就靠一个业务做10年，很难很难，太难了，你细品，你仔细品，当一个业务的商业模式跑通，必然要考虑/进展相关的上下游，再跑通后再扩展。

因为我真是觉得中国人真的是太变态了，包括美国人在内的西方人充其量是把东西做到把别人搞挂的程度，而中国人是要做到把自己搞挂的程度，因为不这样你就会被别人搞挂，然后呢你就没饭吃，发达国家绞肉机真不是白叫的。

我们再落回实际，说点实际的度量吧：

快速，高效的支持企业级复制能力的两个实际体现例子：

1.app工厂模式下(可以扩而广之的)，从立项到第一个发版，一周完成，并且可以低成本高效率的支持到后续DAU到1000万的程度，

我之前的一家公司我们基本上达到了，然后我也不得不跑路开始我新的旅程，寻找个人能力晋升的下一个阶段。

2.当真的考虑异地容灾时，提供快速/稳定/高效的全维度的大系统级层面的支持。

(7).广告：帮公司招人/推荐

我们的技术愿景：

基于云原生/微服务/网格的容器化时代，去做一个可以支持相对完善/完备/完美的物联网/产业互联网的头部公司的可支持企业级复制能力的快速/高效/稳定的技术体系。

目前阶段：

下周开始做从短期/中期/远期规划整体的计划，兼具广度/深度，计划的写法和我公众号类似，兼具微观细节/宏观考量。

同时可能会开始一些前期铺垫，比如测试环境小集群 -> 部署生产级可用的容器化服务(体验服计划) -> 公司范围级的先期体验-> 等等(不赘述)。