开发者学堂课程【Kubernetes 云原生管理实践：】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/751/detail/13222
Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布
使用 OSM 和 OAM 对应用分流
1、使用 OSM和 OAM 对应用进行分流的操作。
O 是开放的意思，所以这两个都是开源的项目。OAM 是开放的应用模型，是阿里云和微软等共同开发的开源项目。OSM 是微软开源的 Open Service Mesh，Open Service Mesh 这个项目是他自己对 SMI 也就是 service mesh interface 的实现。SMI 是前两年为了应对 Service Mesh 出现的情况，做的一个标准，但是这个标准一直以来 istio 没有用，只有 impred 在用。为什么会介绍这个项目？因为 OSM 可扩展性相对比较容易一些，我们喜欢所谓 building clock 类型的项目，不喜欢大类型的项目，这样就相当于把用户都绑定在里面，想改动各方面都不是很好。做 OAM 的初衷是希望各种运维能力和管控能力像砖块一样，可以拿来自己搭建，这是最主要的一个想法。相比其他的特别是 istio 来说，OSM 现在是很轻量级的实践，也没有打算实现较多的功能。
2、OSM主要功能
他目前已经有的功能有 sildcar 注入，这个与 istio 注入是一样的，是用 wipe 做的，还有证书的管理，还有对流量进行加密，实现双向的 TLS，各个 service 默认是不能通信的，要打开它改设置，或者是打开哪一个对他进行配置，这样保证微服务之间的安全性。
service 是 Kubernetes 的 service，是一个网络的概念。为什么叫 service？当需要监听一个端口的时候，会写一个 server，Server 对应的就是 service。service 在听一个端口，他创建一个 employ，把 employ 作为一个 web，提供对外的 IP，还不是对集群以外，是对集群内其他服务提供一个 IP 地址可以访问。service 可以扩展对集群以外的、外部流量也有所反应，对集群内就是做一个 node balance 的工作，对 service 后面的 pod 进行流量的控制。
这些名词在 Kubernetes 容易混淆，比如 istio 以前他的文档，一直把微服务、pod 说成 service，像流量控制的地方又说 service，这样很容易混淆，因为讲的不是一个意思。除了这些以外，最主要的一个功能是对流量进行控制管理的能力，不管是 OSM，还是用户装 Service mesh ，最主要的一个目的是进行流量的控制。
3、分流
分流在流量控制里也是一个主要的事情。分流基于 service 网络的 employ 进行控制来实现的，为什么他会很重要？因为它涉及到发布更新的策略，发布更新策略希望是发布不中断的。如果当中停止对外的应用就断了，在 rolling update 有两种发布的策略，一个是蓝绿发布，一个是金丝雀发布。蓝绿发布相对简单，测试通过就能全部切换。金丝雀发布也叫灰度发布，它是慢慢迁移的。迁移的过程用到分流这件事情，就是有两个服务可以切百分之五、百分之十等等，切到哪种程度看自己需要，然后把旧的关掉。这件事很重要，这是在身价环境中必须要有的功能，但是原生 Kubernetes 做这方面非常不好，所以需要做很多工作才能做到金丝雀发布，就是灰度发布这件事情。在这种情况下大家都喜欢用其他第三方的组件或者是项目来实现这个功能。但是像 istio 这样很重的项目，维护也是很麻烦的一件事情。
4、Demo
OAM 的初衷是把各种运维能力作为 traits，作为具有的特征绑定到 components 上，就是绑定到组件上面，组件就是业务代码。他把应用作为一个基石，然后把 traits 作为 building clock 加上去，把它搭建成一个完整的应用发布，这是 OAM 一直致力在做的事情。
今天把 OSM 当中 traffic split 这样一个功能作为 OAM 的 trait，然后绑定到应用上。
看一下 demo 要做的事情。
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-permissive-traffic-policy
##Allow sidecar injection
kubectl label namespace default openservicemesh. io/monitored-by=osm
##Install application
kubect1 apply-f Components/
kubect1 apply-f definitions/smisplit. Yaml
kubectl apply-f appconfig/demo2. yaml
先安装 osm、sidecar injection，然后创建一个应用，这个应用当中包括了 trait，就是分流的 trait。OSM 的情况，可以看到OSM 是一个很轻的项目，他的文档不是很多。
5、分流 Traffic Split v1alpha2 的 API，因为它是针对 SMI 实践的，所以重视 API，OSM是 SMI 的样板实现。
给了一个 traffic split，告诉我们是怎么做的。
apiVersion:split. smi-spec. io/v1alpha2
kind: TrafficSplit
metadata:
name:my-trafficsplit
spec:
#The root service that clients use to connect to the destination application.
service:my-website
#Services inside the namespace with their own selectors, endpoints and configuration.
backends:
-service:my-website-v1
weight:50
-service:my-website-v2
weight:50
按照这个做，但是在这之前要先按照 OSM。OAM 不但对于应用本身发布以应用作为中心，而且对于技术团队的分工有一定的期望。有些事情比如说是软件开发人员在做，有的工作是应用运维，也有可能是公有云的服务或设施，都有可能，这些人员不同的分工侧重点是不同的。像这些运维能力，像装 OAM 的 runtime，装 OSM或者是 prometheus，这些工作应该是平台开发人员来做。每个公司或每个用户的设置是不同的，这些工作是分开的，这些工作分开之后会变得很轻巧。看一下 SMI 的文档或者是 OAM 的文档，这里面的 demo 等等都是非常复杂的。
他只有一个应用，就是 bookstore 里面的微服务。只有一个应用，但是有很多 demo，需要安装很多东西。
这个已经是速成的，有一个 run，是有脚本。如果没有脚本，就需要花费更久的时间。
