开发者学堂课程【Kubernetes 云原生管理实践：】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/751/detail/13222
Kubernetes 应用通过 Service Mesh 进行流量切分与灰度发布
6、整个流程虽然说是轻量级的，但他的想法还是以平台为中心，以集群为中心，OAM 是以应用为中心，这是根本的不同。OSM 项目比较新，它有一个小问题，osm install 这个地方是要上 chart 的，从 github 下载 osm 的 cli，下载之后把它编译，编译之后他就用现在的版本安装 helm chart，这里面会产生一个不一致的情况，github里面的文件可能会比 helm chart 里面的新。所以在编译的时候出现head 的二进制拿到，拿到之后作为 helm chart 里面要下载的 daughter image 的 ID。还有一个地方默认的 service，一些 employ 之间是不能通信的，为了实验方便允许他通信。
7、下面从 Injection 开始自动注入 slidecar，主动注入 sildcar 以后就可以往里面添加应用。
之前用了第一版本，这个是第二版本，Containerrizeworkload 的定义放在了一个文件里，使用第二个版本。这个 component 相对是较为简单的，重点是看 trait 怎么定义的？
trait 没有进行代码的封装，所以直接引用，直接使用 API 版本，这样 OAM 就知道该怎么寻找 CRD，最后把信息传送过去。在 demo2 这个应用的定义里面，有两个 component，第一版本和第二版本。
在第二版本里面，要介绍 trait 是怎么定义的 。TrafficSplit 服务有两个版本，它是根据版本。把 Traffic split 全部放在 v1下面，如果不这样做，则默认各一半，所以把它全部放在v1下。
8、现在先注册 Components，然后把 trait 也注册上去，今天只需要用到一个 trait。下一步定义应用。
“2”的意思是里面有两个容器，第二个容器是 OSM 的 sildcar。Service也已经有了两个。
Pod 都起来之后，产生一些流量，测试分流这件事情有没有成功。该怎样测试流量呢？流量给 v1 100。现在有个问题，OSM 是以 service employ 来进行流量控制的，我们装的 front-end 只有一个 demployment，没办法使用，必须安装 service 。所以用 port forwarding 比较好。所有的流量都到 v1上，v2上没有，这就是 OSM 进行分流的概念。光标所示地方是v1，如果是 v2，会有显示。
Demo 的 app 本身是往回打标签，hey 工具太快了，所以没看见，现在一个一个打，大家可以看到。
9、为什么提倡用 OAM 做这个事情？假设不用 OAM，这个配置文件很常见。
这个里面有 name、matchLabels，然后又是名字。这些内容往后配版本号的时候，很容易出错。为什么 Kubernetes 这样设计？因为这体现了以行为为中心，Kubernetes 是以平台为中心，走不同的 CRD，或者走不同的 Control 都会需要去读一个或者写一个 label，有很多麻烦。如果使用的是以应用为核心的发布方式， 就没有这些事情，只需要关心自己的逻辑。OAM 是绑定这件事的，后面手工要做的事情他已经管理好了，比如现在把这个应用删了，trait也会一起被删掉，不用在管这些事情。以应用为核心，不同团队为分割现代的运维方式简单高效。特别是对于有很多相近的字段的时候，trait 是一个非常好的工具。今天这个 trait 并没有改代码，所以有多种余的字段在里面。如果已经有一个 trait，因为这几个项目是比较新的开源项目，来不及做 trait，是直接套用，所以还是有一些重复的内容。如果是按照 OAM 的定义，定义出来的 trait 会更加精准，更加好用。希望 trait 像应用一样有仓库，需要什么就拿什么。
10、为什么 OAM 是一个标准？首先要对 trait 进行管理，如果没有管理，在一个集群当中有哪些 trait 都不知道，现在部署 trait 是没有办法进行管理的，没有办法给用户进行统计，用户没有办法查询。有些 trait 之间是互相抵触的，比如说 KEDA 和 HPA，他之间有可能会出现冲突的情况。假设有一个 trait 的仓库，在进仓库之前，先填好有哪些字段需要维护，有哪些功能，这样就很容易进行管理，而且因为是以应用为中心，所以冗余的字段都不需要，也不会容易产生错误。Component 有两个，一个是第一版本，一个是第二版本，也可以把它分成两个应用。假设有四五个微服务，只有一个为服务有两个版本，还是希望把他们放在一起，作为一个应用。假设把 v1 和 v2 拆成两个应用，剩下的其他的微服务该怎么办？现在这样做是完全可以的，从业务靠量和出发，这就是 OAM 很多的优点。
