istio-2：istio1.4.2-demo部署与体验，聊聊一些个人看法
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节点集群
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 933MB3.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 933MBcd 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 10skubectl 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).广告：帮公司招人/推荐
我们的技术愿景：
基于云原生/微服务/网格的容器化时代，去做一个可以支持相对完善/完备/完美的物联网/产业互联网的头部公司的可支持企业级复制能力的快速/高效/稳定的技术体系。
目前阶段：
下周开始做从短期/中期/远期规划整体的计划，兼具广度/深度，计划的写法和我公众号类似，兼具微观细节/宏观考量。
同时可能会开始一些前期铺垫，比如测试环境小集群 -> 部署生产级可用的容器化服务(体验服计划) -> 公司范围级的先期体验-> 等等(不赘述)。