一、云原生应用
云原生应用覆盖到： 大数据，人工智能，边缘计算，区块链等
服务代理：envoy
API 网关：APISIX
服务网格：Istio
服务发现：CoreDNS
消息和流式处理：kafka
Serverless: Knative
CI/CD: GitLab Jenkins
自动化配置：Ansible
数据库： MariaDB
应用定义和镜像制作：Helm
密钥管理：spiffe
云原生监测分析
Prometheus， EFK，
全链路跟踪(服务和服务之间是如何调度的)：Skywalking
云原生安全技术
clair 可以做镜像扫描
二、痛点
主要是开发者的耦合痛点，他们不能关注开发本身，需要学习一些其他技能
serverless就是为了完全解耦，为了开发人员
解决痛点的方式— Serverless
三、为什么要引入Serverless
物理机（担心资源浪费）产生了虚拟机，还是担心资源浪费，有了容器，
即使没有用到，也占用着资源，而且管理复杂度高，于是有了Serverless
Serverful
Serverless
1.定义
被划线这些对开发者是无感知的，这些只需要调接口，没必要之道他们的细节
2.组成
3.特点
无运维指开发人员不需要运维
把很多功能都下沉了，开发人员的工作越来越少
4. 应用场景
5.优缺点
四、Knative
knative不仅可以运行在公有云中，也可以部署在企业内部的数据中心。
本次的案例就是在企业内部部署paas云平台，在paas云平台使用knative运行整个业务
1. knative在云原生中的定位
开发人员不需要在对付复杂的k8s和istio ，因为有个救星knative
2. knative 三个最佳实践
1）计算资源cpu,内存 弹性化
2）自动化就是指程序员动动手指就自动构建部署
3）当有人访问的时候，我们的应用可以打开，没人的时候关闭
Build已经被tekton替换掉了
白盒化就是没有很多的暗箱操作的意思
狼烟起，就是准备好打仗了，有一个激活，eventing就是这样的
只要符合CloudEvents，就能从前端获取后端消息
事件存储到消息队列，传到trigger，过滤器在将其传给对应的serving
3. 部署knative
1) 环境说明
docker 是 20.10.12
2）部署过程
这次只记录版本，剩下的，直接 knative.dev 官网进行查看部署即可
crd是自定义资源类型，没有这些资源类型怎么部署knative呢？
与istio 合用，需要借助 Istio 的路由功能
集群外访问集群内所有服务的入口和出口都是这个EXTERNAL-IP
使用real DNS，这个ip就是 上面的EXTERNAL-IP
域名写到configmap里
istio安装
3）knative项目部署
这里的镜像是自己开发的，就是在网页显示hello world.
knative 的service 和 k8s 中的svc是不同的，这里的service 类似deployment控制器
注意这里的ksvc
一开始访问这个url的时候反应有点慢，因为pod在不用时，它暂时关闭了，你访问它的时候它又重新生成了一个（通过pod名字就能看出来）。访问一次，接着访问的话，速度就会很快，这是在k8s 集群外访问的。
在其他机器想访问就配置下 你的dnsServer就能访问了。
4）访问验证
此时没有主动关闭 v1，流量到了v2上面。这就是apply一个yaml，就实现了从v1到v2的无缝切换，这就是滚动更新
go-example-3.yaml是流量分发的例子
这样访问网页的时候，就是v1 v2 各50%
Knative Eventing
位于事件源和service 之间
安装看官网
安装看这
ingress–> In memory channel --> 订阅者—> 过滤–> 对应的service
接下来验证Broker 里面的内容能不能被处理
CloudEvents Player 应用
上面的url地址就是这个地址
访问就使用下面这个域名
从这个 页面发送消息到broker里面去
比如
上面的纸飞机变成对勾来说明消息被处理了，现在之所以没有被处理是因为没有trigger
URI 就是订阅的地址
有了trigger后就RECEIVED的了
kn工具安装
之前一直使用的是 kubectl的命令，现在开始使用 knative 自己的命令
Knative Eventing
它就是一个路由，将消息的生产者和消息的消费者连接起来
channel 起到 传递的作用
应用案例
上面的我们看到 type:greeting 才会发送给 hello-display
下面在你的事件中有 source: sendoff，就转发到 goodbye-display
我们要把消息发到这个地址上来
