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