全景剖析阿里云容器网络数据链路(二)—— 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》。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
6天前
|
运维 Kubernetes Java
阿里云容器计算服务ACS ,更普惠易用、更柔性、更弹性的容器算力
ACS是阿里云容器服务团队推出的一款面向Serverless场景的子产品,基于K8s界面提供符合容器规范的CPU及GPU算力资源。ACS采用Serverless形态,用户无需关注底层节点及集群运维,按需申请使用,秒级按量付费。该服务旨在打造更普惠易用、更柔性、更弹性的新一代容器算力,简化企业上云门槛,加速业务创新。ACS支持多种业务场景,提供通用型、性能型及BestEffort算力质量,帮助客户更从容应对流量变化,降低综合成本。
|
6天前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
本文整理自2024云栖大会冯诗淳(花名:行疾)的演讲,介绍了阿里云容器服务团队在生产级可观测体系建设方面的实践。冯诗淳详细阐述了容器化架构带来的挑战及解决方案,强调了可观测性对于构建稳健运维体系的重要性。文中提到,阿里云作为亚洲唯一蝉联全球领导者的容器管理平台,其可观测能力在多项关键评测中表现优异,支持AI、容器网络、存储等多个场景的高级容器可观测能力。此外,还介绍了阿里云容器服务在多云管理、成本优化等方面的最新进展,以及即将推出的ACK AI助手2.0,旨在通过智能引擎和专家诊断经验,简化异常数据查找,缩短故障响应时间。
阿里云ACK容器服务生产级可观测体系建设实践
|
6天前
|
供应链 安全 Cloud Native
阿里云容器服务助力企业构建云原生软件供应链安全
本文基于2024云栖大会演讲,探讨了软件供应链攻击的快速增长趋势及对企业安全的挑战。文中介绍了如何利用阿里云容器服务ACK、ACR和ASM构建云原生软件供应链安全,涵盖容器镜像的可信生产、管理和分发,以及服务网格ASM实现应用无感的零信任安全,确保企业在软件开发和部署过程中的安全性。
|
7天前
|
人工智能 Kubernetes Cloud Native
阿里云容器服务,智算时代云原生操作系统
2024云栖大会,阿里巴巴研究员易立分享了阿里云容器服务的最新进展。容器技术已成为云原生操作系统的基石,支持多样化的应用场景,如自动驾驶、AI训练等。阿里云容器服务覆盖公共云、边缘云、IDC,提供统一的基础设施,助力客户实现数字化转型和技术创新。今年,阿里云在弹性计算、网络优化、存储解决方案等方面进行了多项重要升级,进一步提升了性能和可靠性。
|
6天前
|
人工智能 Cloud Native 调度
阿里云容器服务在AI智算场景的创新与实践
本文源自张凯在2024云栖大会的演讲,介绍了阿里云容器服务在AI智算领域的创新与实践。从2018年推出首个开源GPU容器共享调度方案至今,阿里云容器服务不断推进云原生AI的发展,包括增强GPU可观测性、实现多集群跨地域统一调度、优化大模型推理引擎部署、提供灵活的弹性伸缩策略等,旨在为客户提供高效、低成本的云原生AI解决方案。
|
6天前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。
|
6天前
|
人工智能 运维 Kubernetes
拥抱智算时代:阿里云容器服务智能、托管、弹性新体验
本文总结了2024云栖大会容器计算专场的演讲内容,重点介绍了阿里云容器服务的新产品体验,包括智能、托管、弹性的特点,以及如何助力客户拥抱智算时代。文中还分享了多项实际案例和技术细节,展示了阿里云容器服务在提升用户体验和解决实际问题方面的努力。
|
29天前
|
安全 算法 网络安全
量子计算与网络安全:保护数据的新方法
量子计算的崛起为网络安全带来了新的挑战和机遇。本文介绍了量子计算的基本原理,重点探讨了量子加密技术,如量子密钥分发(QKD)和量子签名,这些技术利用量子物理的特性,提供更高的安全性和可扩展性。未来,量子加密将在金融、政府通信等领域发挥重要作用,但仍需克服量子硬件不稳定性和算法优化等挑战。
|
13天前
|
人工智能 Kubernetes Cloud Native
荣获2024年AI Cloud Native典型案例,阿里云容器产品技术能力获认可
2024全球数字经济大会云·AI·计算创新发展大会,阿里云容器服务团队携手客户,荣获“2024年AI Cloud Native典型案例”。
|
18天前
|
弹性计算 安全 容灾
阿里云DTS踩坑经验分享系列|使用VPC数据通道解决网络冲突问题
阿里云DTS作为数据世界高速传输通道的建造者,每周为您分享一个避坑技巧,助力数据之旅更加快捷、便利、安全。本文介绍如何使用VPC数据通道解决网络冲突问题。
67 0