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