当前位置:   article > 正文

Serverless 1

Serverless 1

一、云原生应用

云原生应用覆盖到: 大数据,人工智能,边缘计算,区块链等
服务代理: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
在这里插入图片描述在这里插入图片描述在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
我们要把消息发到这个地址上来
在这里插入图片描述
在这里插入图片描述

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/煮酒与君饮/article/detail/935191
推荐阅读
相关标签
  

闽ICP备14008679号