开发者学堂课程【Kubernetes 云原生管理实践：Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/293/detail/3440
Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布
二、分流
1、发布更新策略
分流在流量控制里面也是主要的事情。分流基于对service，网络进行控制实现，因为涉及到发布更新策略。
发布更新策略一直希望发布不中断，rolling update，要是停一下服务，对外服务断掉，在rolling update中有两种发布策略，一个是蓝绿发布，一个是金丝雀发布，蓝绿发布主要是简单粗暴，测试过了，全部都切换过来，新已经布置好，测试完直接把它切换。
金丝雀发布也叫灰度发布，慢慢迁移，迁移的过程，用到分流，有两个服务，切5%，切10%，20%，40%，80%，切到100%，都可以了，再把旧的关掉，因为业务在生产环境中必须要有的功能，但是原生在这方面支持做的不好，造成自己要做很多工作才能够做到金丝雀发布或者灰度发布。
在这种情况下都喜欢用其它第三方组件或者项目实现功能，比如很重项目，维护也比较头痛。
2、Demo
作为oam的初衷，把各种运维能力作为trait具有的特征绑定到组件上面，组件就是业务代码，它把应用作为基石把traits作为buliding block加上去，加上去以后把它搭建成完整应用发布，这是oam一直致力在做的事情，所以今天把osm中把OSM traffic split作为OAM的trait绑定到应用。
安装osm，sidecar injection，创建应用，应用中包括trait，分流的trait，可以看到osm是一个很新项目，文档不多，分流是针对smi实现，所以它特别重视api，osm是smi的样板实现，specification如何做，安装好osm，oam不但对于应用本身发布，强调以应用作为中心，而且对于技术团队分工也有一定期望，比如软件开发的同学做，有的工作是应用运维的在做，买公有云服务，不同的分工，侧重点都不一样，运维能力，装oam的runtime，装osm或者装普罗米修斯等，工作应该是平台开发的同学来做，每个公司或者每个用户自己设置不一样，有的更偏基础设施一点，会做这种运维工作，有的更偏应用一点，有基础设施的同学在做，但是工作应该分开的，如果把工作分开以后做事情变得很轻巧，如果看osm的文档。
demo都是非常的复杂。
是有一个应用，都是bookstore里面的微服务，有很多yaml，装很多东西，已经是速成，因为用了run，有脚本，如果没有脚本结合需要更久时间，整个流程，虽然它是轻量级或者buliding block，但是整个想法以平台为中心，以集群为中心这，再强调一下，oam以应用为中心，根本不同，osm项目比较新，所以它里面有小小问题，它在osm install，从github下载，编译以后，用现在的版本进行安装，会产生不一致的情况，因为github里面文件会新，编译时出现二进制码，拿到以后把它作为kubectl里面下的id，export之间不能通讯，为了实验方便可以允许通讯。
git clone https:/ /github . com/ openservicemesh/ osm.git
cd osm
make build-osm
export PATH= $PWD/bin: $PATH
commit=$(git rev-parse HEAD)
osm install --osm- image-tag $commit -enable-permiss ive-traffic-policy
## Allow sidecar injection
kubectl label namespace default openservicemesh. io/ monitored-by-osm
## Install appl ication
kubectl apply -f Components/
kubectl apply -f definitions/ smisplit. yaml
kubectl apply -f appconfig demo2. yaml
自动注入sidecar，添加应用，component，两个版本的 go-prom-app，所以component相对比较直接简单。重点看关于trait怎么定义，没有进行代码封装，所以直接引用，用api版本，oam知道去哪找crd把信息传过去，在demo2应用里面，有两个component，有go-prom-app1第一版本和go-prom-app2第二版本，在第二版本里面介绍trait如何定义，服务有两个版本，全部都放到go-prom-app1上面，如果不这么做，默认应该各一半，所以默认全部放到go-prom-app1上面，先注册component，再注册trait，smi的trait，定义应用，2是里面有两个容器，第二个容器是sidecar，以前装过的，所以都没有，service也有两个，可以看到都是running，产生流量测试分流，有没有做成功，流量给v1是100，osm是以service component进行流量控制，装的只有一个，所以没办法用，需要装service才可以，用port-forward比较好，进入本地curl localhost:8080/ test，所有流量都到v1上面，做10个，v2没有。
Demo app本身往回打标签，配工具太快，所以都没看见，一个一个打就可以看到，假设不用oam，很常见的配置文件，名字，
matchlabels，名字，配版本号时很容易出错，弄起来非常不方便，很容易出错，所以Kubernetes设计以平台为中心，走不同的crd，每一个都会需要读一个或者写一个lable，比如去政府做事情要盖章，每个地方都要盖个章，就会有很多麻烦，会有这么多麻烦如果用以应用为核心发布方式，没有事情，关心自己的逻辑即可，因为到哪，traits跟着应用走，最后oam绑定这些事，把后面需要手工去做事情，它帮你管好，所以比如现在把应用删除，trait也会一起被删掉，不用再去管事情，所以这种以应用为核心，不同团队为分割的现代运维方式简单高效又好用方式，特别对于有很多很相近字段时trait是非常好的工具，trait没有改代码，所以还有很多冗余的字段在里面，但是如果已经有trait，因为项目比较新，包括osm都是比较新的开源项目，来不及做trait，直接把它套过来，有重复的东西，如果按照oam定义的trait更加经典更加好用，希望traits像应用一样，解java应用都有每本仓库，需要什么就去拿什么，oam标准要对trait进行管理，如果没有管理，在集群中连有哪些traits都不知道，像现在部署traits是没有办法直接进行管理，没办法给用户统计，自己知道，但用户没有办法查询。
比如有的trait之间互相抵触，比如hpa之间有可能会出现冲突情况，也要知道，想象假设有traits仓库，在进仓库之前，先填个com文件，先填好用哪些字段需要维护，有哪些功能，很容易进行管理，而且因为以应用为中心，不是应用围着转的系统，冗余字段都不会再需要，而且也不会容易产生错误，应用定义，比如component有两个，第一版本，第二版本，把它分成两个应用，假设有四五个，像osm网站上面的应用，有四五个微服务，只有一个微服务有两个版本，还是希望把它们放在一起作为一个应用，把v1和v2拆成两个应用，剩下的微服务怎么办，有问题，所以现在这么做毫无违和感，想怎么拆都可以，做一个可以，做两个也可以，只都从业务逻辑考量和出发，所以这是oam很多的优点，doem没有做代码修改，但是看到了yaml的情况。
