0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

使用Kubernete实现应用的蓝绿部署

马哥Linux运维 来源:稀土掘金 作者:chulinx 2022-08-20 14:57 次阅读
加入交流群
微信小助手二维码

扫码添加小助手

加入工程师交流群

背景介绍

某些情况下,我们在使用Kubernetes作为业务应用的云平台,想要实现应用的蓝绿部署用来迭代应用版本,用lstio太重太复杂,而且它本身定位于流控和网格治理;Ingress-Nginx在0.21版本引入了Canary功能,可以为网关入口配置多个版本的应用程序,使用annotation来控制多个后端服务的流量分配。

Ingress-Nginx-Annotation Canary 功能介绍

如果想启用Canary功能,要先设置nginx.ingress.kubernetes.io/canary: "true",然后可以启用以下注释来配置Canary

nginx.ingress.kubernetes.io/canary-weight 请求到Canary ingress中指定的服务的请求百分比,值为0-100的整数,根据设置的值来决定大概有百分之多少的流量会分配Canary Ingress中指定的后端s服务

nginx.ingress.kubernetes.io/canary-by-header 基于request header 的流量切分,适用于灰度发布或者A/B测试,当设定的hearder值为always是,请求流量会被一直分配到Canary入口,当hearder值被设置为never时,请求流量不会分配到Canary入口,对于其他hearder值,将忽略,并通过优先级将请求流量分配到其他规则

nginx.ingress.kubernetes.io/canary-by-header-value 这个配置要和nginx.ingress.kubernetes.io/canary-by-header 一起使用,当请求中的hearder key和value 和nginx.ingress.kubernetes.io/canary-by-header nginx.ingress.kubernetes.io/canary-by-header-value匹配时,请求流量会被分配到Canary Ingress入口,对于其他任何hearder值,将忽略,并通过优先级将请求流量分配到其他规则

nginx.ingress.kubernetes.io/canary-by-cookie 这个配置是基于cookie的流量切分,也适用于灰度发布或者A/B测试,当cookie值设置为always时,请求流量将被路由到Canary Ingress入口,当cookie值设置为never时,请求流量将不会路由到Canary入口,对于其他值,将忽略,并通过优先级将请求流量分配到其他规则

金丝雀规则按优先顺序进行如下排序:canary-by-header - > canary-by-cookie - > canary-weight

基于权重的小规模版本测试

v1版本编排文件

apiVersion:extensions/v1beta1
kind:Ingress
metadata:
annotations:
kubernetes.io/ingress.class:nginx
labels:
app:echoserverv1
name:echoserverv1
namespace:echoserver
spec:
rules:
-host:echo.chulinx.com
http:
paths:
-backend:
serviceName:echoserverv1
servicePort:8080
path:/
---
kind:Service
apiVersion:v1
metadata:
name:echoserverv1
namespace:echoserver
spec:
selector:
name:echoserverv1
type:ClusterIP
ports:
-name:echoserverv1
port:8080
targetPort:8080
---
apiVersion:extensions/v1beta1
kind:Deployment
metadata:
name:echoserverv1
namespace:echoserver
labels:
name:echoserverv1
spec:
template:
metadata:
labels:
name:echoserverv1
spec:
containers:
-image:mirrorgooglecontainers/echoserver:1.10
name:echoserverv1
ports:
-containerPort:8080
name:echoserverv1

查看v1版本创建的资源

$[K8sSj]kubectlgetpod,service,ingress-nechoserver
NAMEREADYSTATUSRESTARTSAGE
pod/echoserverv1-657b966cb5-7grqs1/1Running024h

NAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGE
service/echoserverv1ClusterIP10.99.68.728080/TCP24h

NAMEHOSTSADDRESSPORTSAGE
ingress.extensions/echoserverv1echo.chulinx.com8024h

访问v1的服务,可以看到10个请求都是访问到一个pod上也就是v1版本的服务

$[K8sSj]foriin`seq10`;docurl-secho.chulinx.com|grepHostname;done
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs

创建v2版本的服务

我们开启canary功能,将v2版本的权重设置为50%,这个百分比并不能精确的将请求平均分配到两个版本的服务,而是在50%上下浮动

apiVersion:extensions/v1beta1
kind:Ingress
metadata:
annotations:
kubernetes.io/ingress.class:nginx
nginx.ingress.kubernetes.io/canary:"true"
nginx.ingress.kubernetes.io/canary-weight:"50"
labels:
app:echoserverv2
name:echoserverv2
namespace:echoserver
spec:
rules:
-host:echo.chulinx.com
http:
paths:
-backend:
serviceName:echoserverv2
servicePort:8080
path:/
---
kind:Service
apiVersion:v1
metadata:
name:echoserverv2
namespace:echoserver
spec:
selector:
name:echoserverv2
type:ClusterIP
ports:
-name:echoserverv2
port:8080
targetPort:8080
---
apiVersion:extensions/v1beta1
kind:Deployment
metadata:
name:echoserverv2
namespace:echoserver
labels:
name:echoserverv2
spec:
template:
metadata:
labels:
name:echoserverv2
spec:
containers:
-image:mirrorgooglecontainers/echoserver:1.10
name:echoserverv2
ports:
-containerPort:8080
name:echoserverv2

创建v2版本的服务

我们开启canary功能,将v2版本的权重设置为50%,这个百分比并不能精确的将请求平均分配到两个版本的服务,而是在50%上下浮动

apiVersion:extensions/v1beta1
kind:Ingress
metadata:
annotations:
kubernetes.io/ingress.class:nginx
nginx.ingress.kubernetes.io/canary:"true"
nginx.ingress.kubernetes.io/canary-weight:"50"
labels:
app:echoserverv2
name:echoserverv2
namespace:echoserver
spec:
rules:
-host:echo.chulinx.com
http:
paths:
-backend:
serviceName:echoserverv2
servicePort:8080
path:/
---
kind:Service
apiVersion:v1
metadata:
name:echoserverv2
namespace:echoserver
spec:
selector:
name:echoserverv2
type:ClusterIP
ports:
-name:echoserverv2
port:8080
targetPort:8080
---
apiVersion:extensions/v1beta1
kind:Deployment
metadata:
name:echoserverv2
namespace:echoserver
labels:
name:echoserverv2
spec:
template:
metadata:
labels:
name:echoserverv2
spec:
containers:
-image:mirrorgooglecontainers/echoserver:1.10
name:echoserverv2
ports:
-containerPort:8080
name:echoserverv2

再次查看创建的资源

$[K8sSj]kubectlgetpod,service,ingress-nechoserver
NAMEREADYSTATUSRESTARTSAGE
pod/echoserverv1-657b966cb5-7grqs1/1Running024h
pod/echoserverv2-856bb5758-f9tqn1/1Running04s

NAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGE
service/echoserverv1ClusterIP10.99.68.728080/TCP24h
service/echoserverv2ClusterIP10.111.103.1708080/TCP4s

NAMEHOSTSADDRESSPORTSAGE
ingress.extensions/echoserverv1echo.chulinx.com8024h
ingress.extensions/echoserverv2echo.chulinx.com804s

访问测试

可以看到请求有4个落到v2版本,6个落到v1版本,理论上来说,请求说越多,落到v2版本的请求数越接近设置的权重50%

$[K8sSj]foriin`seq10`;docurl-secho.chulinx.com|grepHostname;done
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs

基于header的A/B测试

更改v2版本的编排文件

增加headernginx.ingress.kubernetes.io/canary-by-header: "v2"

apiVersion:extensions/v1beta1
kind:Ingress
metadata:
annotations:
kubernetes.io/ingress.class:nginx
nginx.ingress.kubernetes.io/canary:"true"
nginx.ingress.kubernetes.io/canary-weight:"50"
nginx.ingress.kubernetes.io/canary-by-header:"v2"
labels:
app:echoserverv2
name:echoserverv2
namespace:echoserver
spec:
rules:
-host:echo.chulinx.com
http:
paths:
-backend:
serviceName:echoserverv2
servicePort:8080
path:/
---
kind:Service
apiVersion:v1
metadata:
name:echoserverv2
namespace:echoserver
spec:
selector:
name:echoserverv2
type:ClusterIP
ports:
-name:echoserverv2
port:8080
targetPort:8080
---
apiVersion:extensions/v1beta1
kind:Deployment
metadata:
name:echoserverv2
namespace:echoserver
labels:
name:echoserverv2
spec:
template:
metadata:
labels:
name:echoserverv2
spec:
containers:
-image:mirrorgooglecontainers/echoserver:1.10
name:echoserverv2
ports:
-containerPort:8080
name:echoserverv2

更新访问测试

测试了header 为v2:always v2:never v2:true这三个hearder值,可以看到当hearder为v2:always时,流量会全部流入v2,当v2:never时,流量会全部流入v1,当v2:true时,也就是非always/never,流量会按照配置的权重流入对应版本的服务

$[K8sSj]kubectlapply-fappv2.yml
ingress.extensions/echoserverv2configured
service/echoserverv2unchanged
deployment.extensions/echoserverv2unchanged
$[K8sSj]foriin`seq10`;docurl-s-H"v2:always"echo.chulinx.com|grepHostname;done
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
$[K8sSj]foriin`seq10`;docurl-s-H"v2:never"echo.chulinx.com|grepHostname;done
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
$[K8sSj]foriin`seq10`;docurl-s-H"v2:true"echo.chulinx.com|grepHostname;done
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn

自定义header-value

apiVersion:extensions/v1beta1
kind:Ingress
metadata:
annotations:
kubernetes.io/ingress.class:nginx
nginx.ingress.kubernetes.io/canary:"true"
nginx.ingress.kubernetes.io/canary-weight:"50"
nginx.ingress.kubernetes.io/canary-by-header:"v2"
nginx.ingress.kubernetes.io/canary-by-header-value:"true"
labels:
app:echoserverv2
name:echoserverv2
namespace:echoserver
spec:
rules:
-host:echo.chulinx.com
http:
paths:
-backend:
serviceName:echoserverv2
servicePort:8080
path:/
---
kind:Service
apiVersion:v1
metadata:
name:echoserverv2
namespace:echoserver
spec:
selector:
name:echoserverv2
type:ClusterIP
ports:
-name:echoserverv2
port:8080
targetPort:8080
---
apiVersion:extensions/v1beta1
kind:Deployment
metadata:
name:echoserverv2
namespace:echoserver
labels:
name:echoserverv2
spec:
template:
metadata:
labels:
name:echoserverv2
spec:
containers:
-image:mirrorgooglecontainers/echoserver:1.10
name:echoserverv2
ports:
-containerPort:8080
name:echoserverv2

更新测试

可以看到只有header为v2:never时,请求流量才会流入v2版本,其他值流量都会按照权重设置流入不同版本的服务

$[K8sSj]kubectlapply-fappv2.yml
ingress.extensions/echoserverv2configured
service/echoserverv2unchanged
deployment.extensions/echoserverv2unchanged

$[K8sSj]foriin`seq10`;docurl-s-H"v2:true"echo.chulinx.com|grepHostname;done
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn

$[K8sSj]foriin`seq10`;docurl-s-H"v2:always"echo.chulinx.com|grepHostname;done
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn

$[K8sSj]foriin`seq10`;docurl-s-H"v2:never"echo.chulinx.com|grepHostname;done
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs

访问测试

可以看和header的访问效果是一样的,只不过cookie不能自定义value

$[K8sSj]kubectlapply-fappv2.yml
ingress.extensions/echoserverv2configured
service/echoserverv2unchanged
deployment.extensions/echoserverv2unchanged

$[K8sSj]foriin`seq10`;docurl-s--cookie"user_from_shanghai"echo.chulinx.com|grepHostname;done
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn

#zlx@zlxdeMacBook-Proin~/Desktop/unicom/k8syml/nginx-ingress-canary-deployment[1652]
$[K8sSj]foriin`seq10`;docurl-s--cookie"user_from_shanghai:always"echo.chulinx.com|grepHostname;done
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv1-657b966cb5-7grqs
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn

#zlx@zlxdeMacBook-Proin~/Desktop/unicom/k8syml/nginx-ingress-canary-deployment[1625]
$[K8sSj]foriin`seq10`;docurl-s--cookie"user_from_shanghai=always"echo.chulinx.com|grepHostname;done
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn
Hostname:echoserverv2-856bb5758-f9tqn

总结

灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以对新版本进行测试、发现和调整问题,以保证其影响度,以上内容通过实例详细介绍了Ingress-Nginx的实战Canary Annotation,可以借助Ingress-Nginx轻松实现蓝绿发布和金丝雀发布

其他

蓝绿发布

蓝绿部署中,一共有两套系统:一套是正在提供服务系统,标记为“绿色”;另一套是准备发布的系统,标记为“蓝色”。两套系统都是功能完善的,并且正在运行的系统,只是系统版本和对外服务情况不同。

最初,没有任何系统,没有蓝绿之分。

然后,第一套系统开发完成,直接上线,这个过程只有一个系统,也没有蓝绿之分。

后来,开发了新版本,要用新版本替换线上的旧版本,在线上的系统之外,搭建了一个使用新版本代码的全新系统。这时候,一共有两套系统在运行,正在对外提供服务的老系统是绿色系统,新部署的系统是蓝色系统。

蓝色系统不对外提供服务,用来做啥?

用来做发布前测试,测试过程中发现任何问题,可以直接在蓝色系统上修改,不干扰用户正在使用的系统。(注意,两套系统没有耦合的时候才能百分百保证不干扰)

蓝色系统经过反复的测试、修改、验证,确定达到上线标准之后,直接将用户切换到蓝色系统:

切换后的一段时间内,依旧是蓝绿两套系统并存,但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统(新系统)工作状态,如果出现问题,直接切换回绿色系统。

当确信对外提供服务的蓝色系统工作正常,不对外提供服务的绿色系统已经不再需要的时候,蓝色系统正式成为对外提供服务系统,成为新的绿色系统。原先的绿色系统可以销毁,将资源释放出来,用于部署下一个蓝色系统。

蓝绿部署只是上线策略中的一种,它不是可以应对所有情况的万能方案。蓝绿部署能够简单快捷实施的前提假设是目标系统是非常内聚的,如果目标系统相当复杂,那么如何切换、两套系统的数据是否需要以及如何同步等,都需要仔细考虑。

金丝雀发布

金丝雀发布(Canary)也是一种发布策略,和国内常说的灰度发布是同一类策略。蓝绿部署是准备两套系统,在两套系统之间进行切换,金丝雀策略是只有一套系统,逐渐替换这套系统

譬如说,目标系统是一组无状态的Web服务器,但是数量非常多,假设有一万台。

这时候,蓝绿部署就不能用了,因为你不可能申请一万台服务器专门用来部署蓝色系统(在蓝绿部署的定义中,蓝色的系统要能够承接所有访问)。

可以想到的一个方法是:

只准备几台服务器,在上面部署新版本的系统并测试验证。测试通过之后,担心出现意外,还不敢立即更新所有的服务器。先将线上的一万台服务器中的10台更新为最新的系统,然后观察验证。确认没有异常之后,再将剩余的所有服务器更新。

这个方法就是金丝雀发布。

实际操作中还可以做更多控制,譬如说,给最初更新的10台服务器设置较低的权重、控制发送给这10台服务器的请求数,然后逐渐提高权重、增加请求数。

这个控制叫做“流量切分”,既可以用于金丝雀发布,也可以用于后面的A/B测试。

蓝绿部署和金丝雀发布是两种发布策略,都不是万能的。有时候两者都可以使用,有时候只能用其中一种。

A/B测试

首先需要明确的是,A/B测试和蓝绿部署以及金丝雀,完全是两回事。

蓝绿部署和金丝雀是发布策略,目标是确保新上线的系统稳定,关注的是新系统的BUG、隐患。

A/B测试是效果测试,同一时间有多个版本的服务对外服务,这些服务都是经过足够测试,达到了上线标准的服务,有差异但是没有新旧之分(它们上线时可能采用了蓝绿部署的方式)。

A/B测试关注的是不同版本的服务的实际效果,譬如说转化率、订单情况等。

A/B测试时,线上同时运行多个版本的服务,这些服务通常会有一些体验上的差异,譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果,选出效果最好的版本。

在A/B测试中,需要能够控制流量的分配,譬如说,为A版本分配10%的流量,为B版本分配10%的流量,为C版本分配80%的流量。




审核编辑:刘清

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • 网关
    +关注

    关注

    9

    文章

    6429

    浏览量

    55564
  • 控制
    +关注

    关注

    5

    文章

    1031

    浏览量

    125069
  • kubernetes
    +关注

    关注

    0

    文章

    256

    浏览量

    9408

原文标题:使用 Kubernetes Ingress-Nginx 实现蓝绿、灰度发布!你会用了吗?

文章出处:【微信号:magedu-Linux,微信公众号:马哥Linux运维】欢迎添加关注!文章转载请注明出处。

收藏 人收藏
加入交流群
微信小助手二维码

扫码添加小助手

加入工程师交流群

    评论

    相关推荐
    热点推荐

    使用瑞萨RUHMI工具实现AI模型部署过程

    AI无处不在。你在部署AI,你的竞争对手也在部署AI,几乎所有人都在做AI。然而,AI并不简单,不仅在生成有效模型上复杂,在部署上同样充满挑战。
    的头像 发表于 10-17 10:00 2336次阅读
    使用瑞萨RUHMI工具<b class='flag-5'>实现</b>AI模型<b class='flag-5'>部署</b>过程

    使用Ansible实现大规模集群自动化部署

    当你面对1000+服务器需要部署时,你还在一台台手工操作吗?本文将揭秘如何用Ansible实现大规模集群的自动化部署,让运维效率提升10倍!
    的头像 发表于 08-27 14:41 521次阅读

    AICube生成部署文件失败的原因?怎么解决?

    我按照网上的方法安装了dotnet,和AICube,并且我是安装在非中文路径,但是尝试了一天了,都不能成功的生成部署文件,我使用软件自带的样例,但是就是不能生成部署文件 期待结果和实际结果 环境路径 ! image.png 错误日志
    发表于 08-05 06:26

    边缘AI实现的核心环节:硬件选择和模型部署

    边缘AI的实现原理是将人工智能算法和模型部署到靠近数据源的边缘设备上,使这些设备能够在本地进行数据处理、分析和决策,而无需将数据传输到远程的云端服务器。边缘AI的实现旨在将人工智能能力下沉到边缘设备
    的头像 发表于 06-19 12:19 1042次阅读
    边缘AI<b class='flag-5'>实现</b>的核心环节:硬件选择和模型<b class='flag-5'>部署</b>

    HarmonyOS5云服务技术分享--Serverless抽奖模板部署

    通过endCallback实现中奖消息推送 ? ​​安全加固​​ 非免认证模式下建议: 添加请求频率限制 使用HTTPS加密回调 用户ID做哈希处理 五、常见问题QA ❓ 部署后访问显示空白
    发表于 05-22 20:25

    凯米斯科技BGA-406在线蓝绿藻传感器:守护水体生态的科技先锋

    在当今全球水资源面临严峻挑战的时代,水体富营养化问题日益凸显,蓝绿藻水华频繁爆发,对生态环境、饮用水安全以及水产养殖业造成了巨大威胁。为了有效监测和应对这一问题,凯米斯科技凭借其在水环境监测领域
    的头像 发表于 05-21 10:26 417次阅读
    凯米斯科技BGA-406在线<b class='flag-5'>蓝绿</b>藻传感器:守护水体生态的科技先锋

    如何利用RAKsmart服务器实现高效多站点部署方案

    利用RAKsmart服务器实现高效多站点部署方案,需结合其网络优势、弹性资源管理和合理的架构设计。以下是分步实施方案,涵盖网络优化、资源分配、数据管理及监控等核心环节,主机推荐小编为您整理发布如何利用RAKsmart服务器实现
    的头像 发表于 05-19 10:38 372次阅读

    如何在RAKsmart服务器上实现企业AI模型部署

    AI模型的训练与部署需要强大的算力支持、稳定的网络环境和专业的技术管理。RAKsmart作为全球领先的服务器托管与云计算服务提供商,已成为企业部署AI模型的理想选择。那么,如何在RAKsmart服务器上实现企业AI模型的
    的头像 发表于 03-27 09:46 758次阅读

    【幸狐Omni3576边缘计算套件试用体验】DeepSeek 部署及测试

    【幸狐 Omni3576 边缘计算套件测评】DeepSeek 部署及测试 本文介绍了幸狐 Omni3576 边缘计算套件实现 DeepSeek 部署及测试的相关流程,包括模型介绍、部署
    发表于 03-21 19:31

    MSP430部署

    MSP430可以部署简单的模型吗
    发表于 03-16 19:29

    K230D部署模型失败的原因?

    重现步骤 1.按照教程实现MicroPython 版本部署流程,连接上并将文件放到对应位置后,刚运行就断开和canmv ide的连接了(此时用的固件版本是图中推荐的K230D_Zero...
    发表于 03-11 06:19

    yolov5转onnx在cubeAI进行部署部署失败的原因?

    第一个我是转onnx时 想把权重文件变小点 就用了半精度 --half,则说17版本不支持半精度 后面则是没有缩小的单精度 但是显示哪里溢出了···· 也不说是哪里、、。。。 到底能不能部署yolov5这种东西啊?? 也没看见几个部署在这上面..............
    发表于 03-07 11:38

    如何部署OpenVINO™工具套件应用程序?

    编写代码并测试 OpenVINO™ 工具套件应用程序后,必须将应用程序安装或部署到生产环境中的目标设备。 OpenVINO™部署管理器指南包含有关如何轻松使用部署管理器将应用程序打包并部署
    发表于 03-06 08:23

    是否可以使用OpenVINO™部署管理器在部署机器上运行Python应用程序?

    使用 OpenVINO™部署管理器创建运行时软件包。 将运行时包转移到部署机器中。 无法确定是否可以在部署机器上运行 Python 应用程序,而无需安装OpenVINO™ Toolkit 和 Python。
    发表于 03-05 08:16

    基于 Docker 与 Jenkins 实现自动化部署

    前言 重塑自动化部署新高度,Docker 携手 Jenkins,在华为云 Flexus X 云服务器的加持下,引领持续集成与部署的新纪元。Flexus X 以其卓越的性能、灵活的资源配置和高效的成本
    的头像 发表于 01-07 17:25 858次阅读
    基于 Docker 与 Jenkins <b class='flag-5'>实现</b>自动化<b class='flag-5'>部署</b>