全景剖析阿里云容器网络数据链路(二)—— Terway ENI

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 本系列联合作者 容器服务 @谢石 近几年,企业基础设施云原生化的趋势越来越强烈,从最开始的IaaS化到现在的微服务化,客户的颗粒度精细化和可观测性的需求更加强烈。容器网络为了满足客户更高性能和更高的密度,也一直在高速的发展和演进中,这必然对客户对云原生网络的可观测性带来了极高的门槛和挑战。为了提高云原生网络的可观测性,同时便于客户和前后线同学增加对业务链路的可读性

本系列联合作者 容器服务 @谢石

前言

近几年,企业基础设施云原生化的趋势越来越强烈,从最开始的IaaS化到现在的微服务化,客户的颗粒度精细化和可观测性的需求更加强烈。容器网络为了满足客户更高性能和更高的密度,也一直在高速的发展和演进中,这必然对客户对云原生网络的可观测性带来了极高的门槛和挑战。为了提高云原生网络的可观测性,同时便于客户和前后线同学增加对业务链路的可读性,ACK产研和AES联合共建,合作开发ack net-exporter和云原生网络数据面可观测性系列,帮助客户和前后线同学了解云原生网络架构体系,简化对云原生网络的可观测性的门槛,优化客户运维和售后同学处理疑难问题的体验 ,提高云原生网络的链路的稳定性。

鸟瞰容器网络,整个容器网络可以分为三个部分:Pod网段,Service网段和Node网段。 这三个网络要实现互联互通和访问控制,那么实现的技术原理是什么?整个链路又是什么,限制又是什么呢?Flannel, Terway有啥区别?不同模式下网络性能如何?这些,需要客户在下搭建容器之前,就要依据自己的业务场景进行选择,而搭建完毕后,相关的架构又是无法转变,所以客户需要对每种架构特点要有充分了解。比如下图是个简图,Pod网络既要实现同一个ECS的Pod间的网络互通和控制,又要实现不同ECS Pod间的访问, Pod访问SVC 的后端可能在同一个ECS 也可能是其他ECS,这些在不同模式下,数据链转发模式是不同的,从业务侧表现结果也是不一样的。

本文是[全景剖析容器网络数据链路]第二部分,主要介绍Kubernetes Terway ENI模式下,数据面链路的转转发链路,一是通过了解不同场景下的数据面转发链路,从而探知客户在不同的场景下访问结果表现的原因,帮助客户进一步优化业务架构;另一方面,通过深入了解转发链路,从而在遇到容器网络抖动时候,客户运维以及阿里云同学可以知道在哪些链路点进行部署观测手动,从而进一步定界问题方向和原因。

系列一:全景剖析阿里云容器网络数据链路(一)—— Flannel

系列二:全景剖析阿里云容器网络数据链路(二)—— Terway ENI

系列三:全景剖析阿里云容器网络数据链路(三)—— Terway ENIIP

系列四:全景剖析阿里云容器网络数据链路(四)—— Terway IPVLAN+EBPF

系列五:全景剖析阿里云容器网络数据链路(五)—— Terway ENI-Trunking

系列六:全景剖析阿里云容器网络数据链路(六)—— ASM Istio

1. Terway ENI 模式架构设计

Terway ENI 模式下,ENI的网络都是和VPC同样的网段,ENI网络就是从Aliyun的VPC网络中创建和绑定一个弹性网卡到ECS节点上, 然后Pod利用这个弹性网卡和别的网络互通,这里需要关注的是弹性网卡的数量是有限制的,具体的根据实例类型有不同的配额

Pod 所使用的的CIDR网段和节点的CIDR是同一个网段

Pod 内部可以看到是有两张网卡的,一个是eth0,另一个是veth1,其中eth0 的IP就是 Pod的IP,此网卡的MAC地址和控制台上的ENI的MAC地址可以匹配,说明此网卡就是附属ENI网卡,被直接挂载到了Pod的网络命名空间内。 

Pod内有指向eth0的默认路由,同时还有指向目的网段为192.168.0.0/16, 下一跳为 veth1网卡的路由,其中192.168.0.0/16 网段为集群的service网段,说明集群内Pod访问SVC的clusterIP网段,数据链路会经过veth1 网卡到宿主机ECS的OS内进行下一步判断,其他情况是走eth0直接进入到VPC

如上图所示,我们可以容器的网络命名空间中通过ip addr 看到一个veth1@if19的标志位,其中 ‘19' 这个将会协助我们在ECS的OS内找到找到和容器网络命名空间中的veth pair相对一个。在ECS OS 内我们通过ip addr | grep 19: 可以找到cali38ef34581a9 这个虚拟网卡,这个就是veth pair在ECS OS侧相对的那一个。

到目前为止,容器访问SVC的ClusterIP时,容器和OS数据链路已经建立链接了,那么ECS OS内对于数据流量是怎么判断去哪个容器呢? 通过OS Linux Routing 我们可以看到,所有目的是 Pod CIDR 网段的流量都会被转发到Pod对应的calico虚拟往卡上,到这里为止,ECS OS 和Pod的网络命名空间已经建立好完整的出入链路配置了。

2. Terway ENI 模式容器网络数据链路剖析

针对容器网络特点,我们可以将Terway ENI模式下的网络链路大体分为以Pod IP对外提供服务和以SVC对外提供服务两个大的SOP场景,进一步细分可以拆分到8个不同的小的SOP场景。

对这8个场景的数据链路梳理合并,这些场景可以归纳为下面8类典型的场景:

TerwayENI架构下,不同的数据链路访问情况下,可以总结归纳为为8类:

•访问Pod IP,同节点访问pod

•访问Pod IP,同节点pod间互访

•访问Pod IP,异节点pod间互访

•集群内访问SVC IP (Cluster IP),源端和SVC后端Pod为同一节点

•集群内访问SVC IP( Cluster IP),源端和SVC后端Pod为不同节点

•集群内访问SVC IP (External IP),源端和SVC后端Pod为同一节点

•集群内访问SVC IP(External IP),源端和SVC后端Pod为不同节点

•集群外访问SVC External IP

2.1 场景一:访问Pod IP,同节点访问pod

环境

ap-southeast-1.10.0.0.196 节点上存在 nginx1-5969d8fc89-9t99h 10.0.0.203

内核路由

nginx1-5969d8fc89-9t99h IP地址  10.0.0.203  ,该容器在宿主机表现的PID是1094736,该容器网络命名空间有指向容器eth0的默认路由 和 下一跳 为 veth1, 目的网段为service的 两条路由


该容器veth1在ECS OS 内对应veth pair是cali5068e632525

在ECS OS内,有指向Pod IP,下一跳为为calixxxx的路由,通过前文可以知道calixxx网卡是和每个pod内的veth1组成的pair,所以,pod内访问SVC的CIDR会有指向veth1的路由,不会走默认的eth0路由。故:calixx网卡在这里的主要作用是用于:1. 节点访问Pod 2. 当节点或者Pod访问 SVC的CIDR时,会走ECS OS内核协议栈转换,走到calixxx和veth1访问pod。

小结

可以访问到目的端

nginx1-5969d8fc89-9t99h netns veth1   可以抓到数据包

nginx1-5969d8fc89-9t99h cali5068e632525  可以抓到数据包

数据链路转发示意图:

  • 数据链路是 ECS -> Linux routing ->  calicxxx -> Pod net ns veth1。数据链路完成 宿主机ns切换至 pod ns
  • 通过宿主机上的路由切换至pod所属的veth pair
  • 该网卡为被分配的pod独占, 无法和其他pod进行共享
  • 数据链路经过两次协议栈

2.2 场景二:访问Pod IP,同节点pod访问pod

环境

ap-southeast-1.10.0.0.196 节点上存在两个pod:centos-59cdc5c9c4-89f8x IP地址 10.0.0.202 和  nginx1-5969d8fc89-9t99h 10.0.0.203

内核路由

centos-59cdc5c9c4-89f8x IP地址 10.0.0.202  ,该容器在宿主机表现的PID是2314075,该容器网络命名空间有指向容器eth0的默认路由 和 下一跳 为 veth1, 目的网段为service的 两条路由

通过上述类似的办法,可以找到 nginx1-5969d8fc89-9t99h  IP地址10.0.0.203,该容器在宿主机表现的PID是1094736

小结

可以访问到目的端

centos-59cdc5c9c4-89f8x netns eth1 可以抓到数据包

nginx1-5969d8fc89-9t99h netns eth1 可以抓到数据包

数据链路转发示意图:

  • 数据链路是 pod1 netns eth1 -> VPC -> pod2 netns eth2。数据链路不经过宿主机host namespace,数据链路会先出ECS,到VPC再回到原来的ECS。
  • 在pod 内的net namespace中,直接命中 默认路有规则,从eth0网卡出pod直接到VPC。 这里的eth0 其实就是附属网卡ENI,直接被挂载在了pod 的 net ns, 走了PCI网卡
  • 该网卡为被分配的pod独占, 无法和其他pod进行共享
  • 数据链路经过两次协议栈

2.3 场景三:访问Pod IP,异节点pod访问pod

环境

ap-southeast-1.10.0.0.196 节点上存在pod:centos-59cdc5c9c4-89f8x IP地址 10.0.0.202

ap-southeast-1.10.0.2.80 节点上存在pod:nginx-6f545cb57c-jmbrq 和 10.0.2.86

内核路由

centos-59cdc5c9c4-89f8x IP地址 10.0.0.202  ,该容器在宿主机表现的PID是2314075,该容器网络命名空间有指向容器eth0的默认路由 和 下一跳 为 veth1, 目的网段为service的 两条路由

通过上述类似的办法,可以找到 nginx-6f545cb57c-jmbrq    IP地址 10.0.2.86,该容器在宿主机表现的PID是1083623


小结

可以访问到目的端

centos-59cdc5c9c4-89f8x netns eth0 可以抓到数据包

nginx-6f545cb57c-jmbrq netns eth0 可以抓到数据包

数据链路转发示意图:

  • 数据链路是 ECS1  pod1 netns eth0 -> VPC -> ECS2 pod2 netns eth0。数据链路不经过宿主机host namespace,数据链路会先出ECS1,到AVS再回到ECS2。
  • 在pod 内的net namespace中,直接命中 默认路有规则,从eth0网卡出pod直接到VPC。 这里的eth0 其实就是附属网卡ENI,直接被挂载在了pod 的 net ns, 走了PCI设备
  • 该网卡为被分配的pod独占, 无法和其他pod进行共享
  • 数据链路经过两次协议栈

2.4 场景四:集群内访问SVC IP (Cluster IP),源端和SVC后端Pod为同一节点

环境

ap-southeast-1.10.0.0.196 节点上存在两个pod:centos-59cdc5c9c4-89f8x IP地址 10.0.0.202 和  nginx1-5969d8fc89-9t99h 10.0.0.203

Service是 nginx1 集群内clusterIP是192.168.41.244, external IP是 8.219.175.179

内核路由

centos-59cdc5c9c4-89f8x IP地址 10.0.0.202  ,该容器在宿主机表现的PID是2314075,该容器网络命名空间有指向容器eth0的默认路由 和 下一跳 为 veth1, 目的网段为service的 两条路由

该容器eth0在ECS OS 内对应veth pair是cali38ef34581a9

通过上述类似的办法,可以找到 nginx1-5969d8fc89-9t99h  IP地址10.0.0.203,该容器在宿主机表现的PID是1094736,该容器eth0在ECS OS 内对应veth pair是cali5068e632525

在ECS OS内,有指向Pod IP,下一跳为为calixxxx的路由,通过前文可以知道calixxx网卡是和每个pod内的veth1组成的pair,所以,pod内访问SVC的CIDR会有指向veth1的路由,不会走默认的eth0路由。故:calixx网卡在这里的主要作用是用于:1. 节点访问Pod 2. 当节点或者Pod访问 SVC的CIDR时,会走ECS OS内核协议栈转换,走到calixxx和veth1访问pod。

小结

可以访问到目的端

centos-59cdc5c9c4-89f8x netns veth1 可以抓到数据包

centos-59cdc5c9c4-89f8x netns cali38ef34581a9  可以抓到数据包

nginx1-5969d8fc89-9t99h netns veth1 可以抓到数据包

nginx1-5969d8fc89-9t99h netns cali5068e632525 可以抓到数据包

数据链路转发示意图:

  • 数据链路是 ECS1  pod1 netns veth1 -> calixxx1 -> calixxx2  -> ECS2 pod2 netns veth1
  • 在pod 内的net namespace中,命中svc的路由,从veth1网卡出pod到ECS的 namespace,然后通过linux routing 转到另一个pod 的 calixx 网卡。 这里的veth1和calixxx是veth pair
  • 源端pod所分配的veth,calicoxxx网卡可以捕获到svc IP和 源端pod IP。SVC IP 会在源端ECS host内命中ipvs/iptables规则,做了nat转化。
  • 目的段pod所分配的veth,calicoxxx网卡可以捕获calicoxxx网卡默认ip和目的pod IP
  • 该网卡为被分配的pod独占, 无法和其他pod进行共享
  • 数据链路经过三次协议栈:Pod1, ECS OS 和Pod2

2.5 场景五:集群内访问SVC IP (Cluster IP),源端和SVC后端Pod为不同节点

环境

ap-southeast-1.10.0.0.196 节点上存在pod:centos-59cdc5c9c4-89f8x IP地址 10.0.0.202

ap-southeast-1.10.0.2.80 节点上存在pod:nginx-6f545cb57c-jmbrq 和 10.0.2.86

Service是 nginx 集群内clusterIP是192.168.204.233, external IP是 8.219.199.33

内核路由

centos-59cdc5c9c4-89f8x IP地址 10.0.0.202  ,该容器在宿主机表现的PID是2314075,该容器网络命名空间有指向容器eth0的默认路由 和 下一跳 为 veth1, 目的网段为service的 两条路由

该容器eth0在ECS OS 内对应veth pair是cali38ef34581a9

通过上述类似的办法,可以找到 nginx-6f545cb57c-jmbrq    IP地址 10.0.2.86,该容器在宿主机表现的PID是1083623, 该pod网卡ENI是直接被挂载到了Pod的网络命名空间内。

小结

可以访问到目的端

数据链路转发示意图:

  • 数据链路是 ECS1  pod1 netns veth1 -> cali38ef34581a9 -> ECS1 eth0 -> VPC -> ECS2 pod2 netns veth1
  • 在客户端pod 内的net namespace中,命中svc的路由,从veth1网卡出pod到ECS的 namespace,然后通过linux routing 转到客户端ECS eth0 网卡, 然后进入到vpc转发到 目的 Pod所属的 eth网卡
  • 源端pod所分配的veth,calicoxxx网卡可以捕获到svc IP和 源端pod IP。
  • SVC IP 会在源端ECS host内命中ipvs/iptables规则,做了fnat转化。在源端ECS 所属的eth0只能捕获到ipvs/iptables规则所分配的目的pod IP和源ECS IP
  • 目的pod 内eth0所捕获的IP 是源端 ECS IP 和目的POD IP。(源POD IP 和 SVC IP不会体现)
  • 该网卡为被分配的pod独占, 无法和其他pod进行共享
  • 数据链路经过三次协议栈:Pod1, ECS1 OS 和Pod2

2.6 场景六:集群内访问SVC IP (External IP),源端和SVC后端Pod为同一节点

环境

ap-southeast-1.10.0.0.196 节点上存在两个pod:centos-59cdc5c9c4-89f8x IP地址 10.0.0.202 和  nginx1-5969d8fc89-9t99h 10.0.0.203

Service是 nginx1 集群内clusterIP是192.168.221.163 external IP是 10.0.2.89

内核路由

centos-59cdc5c9c4-89f8x IP地址 10.0.0.202  ,该容器在宿主机表现的PID是2314075,该容器网络命名空间有指向容器eth0的默认路由 和 下一跳 为 veth1, 目的网段为service 的 ClusterIP的 两条路由

SLB相关配置

在SLB控制台,可以看到虚拟服务器组的后端只有nginx1-5969d8fc89-9t99h的ENI eni-t4n6qvabpwi24w0dcy55

综上,可以判断如果访问的是SVC 的External IP, 是走默认路由 eth0,直接出ECS 进入到avs ,访问到 SLB的实例,再由SLB实例转发到后端eni上

小结

可以访问到目的端

数据链路转发示意图:

  • 数据链路是 ECS1  pod1 netns eth0 -> VPC -> SLB -> VPC  -> ECS1 pod2 netns eth0。数据链路不经过宿主机host namespace,数据链路会先出ECS1,到AVS再回到ECS1。
  • 在pod 内的net namespace中,直接命中 默认路有规则,从eth0网卡出pod直接到VPC。 这里的eth0 其实就是附属网卡ENI,直接被挂载在了pod 的 net ns, 走了PCI设备
  • 该网卡为被分配的pod独占, 无法和其他pod进行共享
  • 与 2.4 场景可以看到非常大的不同,虽然都是 前后端Pod都是部署在同一个ECS访问SVC 的IP,但是可以看到如果访问的是SVC的ClusterIP,则数据链路会进入到ECS OS 层面,会经过三次协议栈;如果访问的是External IP,则不会经过ECS OS,直接出ECS,经过SLB转发到目的Pod上,只经过两次协议栈(Pod1 和Pod2)。

2.7 场景七:集群内访问SVC IP(External IP),源端和SVC后端Pod为不同节点

环境

ap-southeast-1.10.0.0.196 节点上存在pod:centos-59cdc5c9c4-89f8x IP地址 10.0.0.202

ap-southeast-1.10.0.2.80 节点上存在pod:nginx-6f545cb57c-jmbrq 和 10.0.2.86

Service是 nginx 集群内clusterIP是192.168.254.141, external IP是 10.0.2.90

内核路由

centos-59cdc5c9c4-89f8x IP地址 10.0.0.202  ,该容器在宿主机表现的PID是2314075,该容器网络命名空间有指向容器eth0的默认路由 和 下一跳 为 veth1, 目的网段为service 的 ClusterIP的 两条路由

SLB相关配置

在SLB控制台,可以看到lb-t4nih6p8w8b1dc7p587j9虚拟服务器组的后端只有nginx-6f545cb57c-jmbrq的ENI eni-t4n5kzo553dfak2sp68j

综上,可以判断如果访问的是SVC 的External IP, 是走默认路由 eth0,直接出ECS 进入到avs ,访问到 SLB的实例,再由SLB实例转发到后端eni上

小结

可以访问到目的端

数据链路转发示意图:

  • 数据链路是 ECS1  pod1 netns eth0 -> VPC -> SLB -> VPC  -> ECS2 pod2 netns eth0。数据链路不经过宿主机host namespace,数据链路会先出ECS1,到SLB再回到ECS2。
  • 在pod 内的net namespace中,直接命中 默认路有规则,从eth0网卡出pod直接到VPC。 这里的eth0 其实就是附属网卡ENI,直接被挂载在了pod 的 net ns, 走了PCI设备
  • 该网卡为被分配的pod独占, 无法和其他pod进行共享
  • 与 2.5 场景可以看到非常大的不同,虽然都是 前后端Pod都是部署在不同ECS访问SVC 的IP,但是可以看到如果访问的是SVC的ClusterIP,则数据链路会进入到ECS OS 层面,通过ECS的eth0出ECS,进入到AVS,会经过三次协议栈;如果访问的是External IP,则不会经过ECS OS,直接通过Pod所属的的附属ENI 出ECS,经过SLB转发到目的Pod上,只经过两次协议栈(Pod1 和Pod2)。

2.8 场景八:集群外访问SVC External IP

环境

ap-southeast-1.10.0.2.80 节点上存在pod:nginx-6f545cb57c-jmbrq 和 10.0.2.86

ap-southeast-1.10.0.1.233 节点上存在pod:nginx-6f545cb57c-25k9z 和 10.0.1.239

Service是 nginx 集群内clusterIP是192.168.254.141, external IP是 10.0.2.90

SLB相关配置

在SLB控制台,可以看到lb-t4nih6p8w8b1dc7p587j9虚拟服务器组的后端服务器组是两个后端nginx pod 的的ENI eni-t4n5kzo553dfak2sp68j 和 eni-t4naaozjxiehvmg2lwfo

从集群外部角度看,SLB的后端虚拟服务器组是SVC的后端Pod所属的两个ENI网卡,内网的IP 地址就是Pod的地址,没有经过后端Pod所在的ECS的OS层面,直接进入到了OS的的协议栈

小结

可以访问到目的端

数据链路转发示意图:

  • 数据链路:client ->  SLB  -> Pod ENI + Pod Port  -> ECS1 Pod1 eth0
  • 数据链路要经过一次内核协议栈,是Pod1 协议栈

总结

本篇文章主要聚焦ACK 在Terway ENI模式下,不同SOP场景下的数据链路转发路径。伴随着客户对性能的极致追求的需求,在Terway ENI模式下,一共可以分为8个SOP场景,并对这八个场景的转发链路,技术实现原理,云产品配置等一一梳理并总结,这对我们遇到Terway ENI架构下的链路抖动、最优化配置,链路原理等提供了初步指引方向。在Terway ENI 模式下,ENI是以PCI方式直接挂载到Pod的命名空间内,这就以为ENI属于被分配的Pod独享,而ECS所能部署的Pod数量取决于ECS所能挂载ENI网卡数量的限制,而这个限制和ECS的实例规格类型有关,比如神龙ecs.ebmg7.32xlarge,128C 512GB也只支持最多32个ENI,这往往会造成资源的浪费和部署密度的降低,为了解决这个资源效率问题,ACK 带来了Terway ENIIP的方式,来实现ENI网卡可以被多个Pod所共享,这大大增加了单个ECS上的Pod数量quota,提升了部署密度,这也是目前线上集群采用最多的架构。 下一系列我们将进入到Terway ENIIP模式的全景解析——《ACK全景剖析阿里云容器网络数据链路(三)—— Terway ENIIP》。

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
17天前
|
传感器 编解码 监控
|
2月前
|
存储 Kubernetes Docker
容器服务ACK常见问题之阿里云控制台进不去了如何解决
容器服务ACK(阿里云容器服务 Kubernetes 版)是阿里云提供的一种托管式Kubernetes服务,帮助用户轻松使用Kubernetes进行应用部署、管理和扩展。本汇总收集了容器服务ACK使用中的常见问题及答案,包括集群管理、应用部署、服务访问、网络配置、存储使用、安全保障等方面,旨在帮助用户快速解决使用过程中遇到的难题,提升容器管理和运维效率。
|
3月前
|
人工智能 运维 Kubernetes
阿里云容器服务ACK AI助手正式上线带来的便利性
作为开发者想必大家都知道,云原生容器技术的优势,尤其是近两年的随着容器技术的迅猛发展,Kubernetes(K8s)已成为广泛应用于容器编排和管理的领先解决方案,但是K8s的运维复杂度一直是挑战之一。为了应对这一问题,就在最近,阿里云容器服务团队正式发布了ACK AI助手,这是一款旨在通过大模型增强智能诊断的产品,旨在帮助企业和开发者降低Kubernetes(K8s)的运维复杂度。那么本文就来详细讲讲关于这款产品,让我们结合实际案例分享一下K8s的运维经验,探讨ACK AI助手能否有效降低K8s的运维复杂度,并展望ACK AI助手正式版上线后的新功能。
281 2
阿里云容器服务ACK AI助手正式上线带来的便利性
|
4月前
|
Kubernetes 容器
要获取ACK(阿里云容器服务)集群中的Deployment
要获取ACK(阿里云容器服务)集群中的Deployment【1月更文挑战第8天】【1月更文挑战第40篇】
65 4
|
4月前
|
人工智能 弹性计算 调度
阿里云容器服务 ACK 产品技术动态(202312)
容器服务 Kubernetes 版 ACK 【新功能】 Feature:支持基于机密虚拟机的 AI 模型推理保护 ACK 现已支持将基于 Intel® Trusted Domain Extension(Intel® TDX)技术的 ECS 实例加入 TDX 机密虚拟机计算节点池,使集群具备 TDX 机密计算能力,实现 AI 模型的可信推理和微调,保障模型数据的机密性与完整性。结合 PyTorch 与 Intel® AMX指令集,您可以在 32 核实例上实现秒级出图的推理能力。
426 1
|
4月前
|
Kubernetes 监控 调度
阿里云容器服务ACK
阿里云容器服务ACK(Alibaba Cloud Container Service for Kubernetes)提供高性能、可伸缩的容器应用管理服务,支持企业级Kubernetes容器化应用的生命周期管理。在ACK中,利用cGPU(Containerized GPU)技术可以实现GPU资源的共享,提高GPU利用率,降低整体成本。
68 6
|
14天前
|
运维 Serverless API
Serverless 应用引擎产品使用之在阿里云函数计算中,容器运行过程中的最大内存使用量获取如何解决
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
35 2
|
15天前
|
运维 IDE Serverless
Serverless 应用引擎产品使用之阿里函数计算中,阿里云容器镜像服务(Container Registry)中创建自定义镜像,然后将其部署到FC上如何解决
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
29 0
|
17天前
|
人工智能 边缘计算 Kubernetes
阿里云边缘容器云帮助AI推理应用快速落地
2024全球分布式云大会·北京站,阿里云徐若晨演讲内容分享
27 0
|
19天前
|
弹性计算 运维 Kubernetes
阿里云轻量应用服务器与轻量容器服务简介与区别及收费标准参考
轻量应用服务器是深受个人和普通企业用户亲耐的一款轻量级云服务器产品,提供精品应用一键部署,支持一站式的域名、网站、安全、运维、应用管理等服务,极大优化搭建简单应用的体验,降低了入门级用户使用云计算产品的门槛。轻量容器服务是专为学生、个人开发者等用户打造的轻量级容器服务,帮助您在云上快速了解容器和Kubernetes(简称K8s)相关的基础概念和轻松进行入门实践。本文为大家介绍一下阿里云轻量应用服务器与轻量容器服务的区别以及收费标准,以供参考。
阿里云轻量应用服务器与轻量容器服务简介与区别及收费标准参考