【云原生 | 从零开始学Kubernetes】二十三、Kubernetes控制器Statefulset

本文涉及的产品
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
云数据库 RDS MySQL Serverless,价值2615元额度,1个月
简介: StatefulSet 是为了管理有状态服务的问题而设计的

Statefulset


Statefulset 控制器:概念、原理解读


有状态服务?


无状态服务?


什么是 Headless service


为什么要用 headless service(没有 service ip 的 service)?


为什么要用 volumeClaimTemplate?


Statefulset 资源清单文件编写技巧


Statefulset 使用案例:部署 web 站点


Statefulset 管理 pod:扩容、缩容、更新


Statefulset 控制器:概念、原理解读


StatefulSet 是为了管理有状态服务的问题而设计的


对于StatefulSet中的Pod,每个Pod挂载自己独立的存储,如果一个Pod出现故障,从其他节点启动一个同样名字的Pod,要挂载上原来Pod的存储继续以它的状态提供服务。


有状态服务?


StatefulSet 是有状态的集合,管理有状态的服务,它所管理的 Pod 的名称不能随意变化。数据持久化的目录也是不一样,每一个 Pod 都有自己独有的数据持久化存储目录。比如 MySQL 主从、redis 集群等。


·让每个Pod独立的


·让每个Pod独立的,保持Pod启动顺序和唯一性


·唯一的网络标识符,持久存储


·有序,比如mysql中的主从


适合StatefulSet的业务包括数据库服务 MySQL 和 PostgreSQL,集群化管理服务Zookeeper、etcd等有状态服务


StatefulSet的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物,运维人员需要不断地维护它,容器刚开始流行时,我们用容器来模拟虚拟机使用,所有状态都保存在容器里,而这已被证明是非常不安全、不可靠的。


使用StatefulSet,Pod仍然可以通过漂移到不同节点提供高可用,而存储也可以通过外挂的存储来提供高可靠性,StatefulSet做的只是将确定的Pod与确定的存储关联起来保证状态的连续性。


无状态服务?


RC、Deployment、DaemonSet 都是管理无状态的服务,它们所管理的 Pod 的 IP、名字,启停顺序等都是随机的。个体对整体无影响,所有 pod 都是共用一个数据卷的,部署的 tomcat 就是无状态的服务,tomcat 被删除,在启动一个新的 tomcat,加入到集群即可,跟 tomcat 的名字无关。


·认为Pod都是一样的


·没有顺序要求


·不考虑应用在哪个node上运行


·能够进行随意伸缩和扩展


StatefulSet 由以下几个部分组成:


1.Headless Service:用来定义 pod 网路标识,生成可解析的 DNS 记录


2.volumeClaimTemplates:存储卷申请模板,创建 pvc,指定 pvc 名称大小,自动创建 pvc,且 pvc 由存储类供应。


3.StatefulSet:管理 pod 的


什么是 Headless service


Headless service 不分配 clusterIP,headless service 可以通过解析 service 的 DNS,返回所有 Pod 的 dns 和 ip 地址 (statefulSet 部署的 Pod 才有 DNS),普通的 service,只能通过解析 service 的 DNS 返回 service 的 ClusterIP。


为什么要用 headless service(没有 service ip 的 service)?


在使用 Deployment 时,创建的 Pod 名称是没有顺序的,是随机字符串,在用 statefulset 管理 pod 时要求 pod 名称必须是有序的 ,每一个 pod 不能被随意取代,pod 重建后 pod 名称还是一样的。因为 pod IP 是变化的,所以要用 Pod 名称来识别。pod 名称是 pod 唯一性的标识符, 必须持久稳定有效。这时候要用到无头服务,它可以给每个 Pod 一个唯一的名称。


1.headless service 会为 service 分配一个域名
<service name>.$<namespace name>.svc.cluster.local
K8s 中资源的全局 FQDN 格式:
Service_NAME.NameSpace_NAME.Domain.LTD.
Domain.LTD.=svc.cluster.local. #这是默认 k8s 集群的域名。
FQDN 全称 Fully Qualified Domain Name 即全限定域名:同时带有主机名和域名的名称
FQDN = Hostname + DomainName
如 主机名是 paopao 域名是 csdn.com
FQDN= paopao.csdn.com
2.StatefulSet 会为关联的 Pod 保持一个不变的 Pod Name
statefulset 中 Pod 的名字格式为$(StatefulSet name)-$(pod 序号)
3.StatefulSet 会为关联的 Pod 分配一个 dnsName
$<Pod Name>.$<service name>.$<namespace name>.svc.cluster.local


为什么要用 volumeClaimTemplate?


对于有状态应用都会用到持久化存储,比如 mysql 主从,由于主从数据库的数据是不能存放在一个目录下的,每个 mysql 节点都需要有自己独立的存储空间。而在 deployment 中创建的存储卷是一个共享的存储卷,多个 pod 使用同一个存储卷,它们数据是同步的,而 statefulset 定义中的每一个 pod 都不能使用同一个存储卷,这就需要使用 volumeClainTemplate,当在使用statefulset 创建 pod 时,volumeClainTemplate 会自动生成一个 PVC,从而请求绑定一个PV,每一个 pod 都有自己专用的存储卷。Pod、PVC 和 PV 对应的关系图如下:


7.png


Statefulset 资源清单文件编写技巧


#查看定义 Statefulset 资源需要的字段
[root@k8smaster ~]# kubectl explain statefulset
KIND:     StatefulSet
VERSION:  apps/v1
DESCRIPTION:
     StatefulSet represents a set of pods with consistent identities. Identities
     are defined as: - Network: A single stable DNS and hostname. - Storage: As
     many VolumeClaims as requested. The StatefulSet guarantees that a given
     network identity will always map to the same storage identity.
FIELDS:
   apiVersion <string> #定义 statefulset 资源需要使用的 api 版本
   kind <string> #定义的资源类型
   metadata<Object> #元数据
   spec <Object> #定义容器相关的信息
#查看 statefulset.spec 字段如何定义?
[root@k8smaster ~]#  kubectl explain statefulset.spec
KIND:     StatefulSet
VERSION:  apps/v1
RESOURCE: spec <Object>
DESCRIPTION:
     Spec defines the desired identities of pods in this set.
     A StatefulSetSpec is the specification of a StatefulSet.
FIELDS:
   podManagementPolicy <string> #pod 管理策略
   replicas <integer> #副本数
   revisionHistoryLimit <integer> #保留的历史版本
   selector <Object> -required- #标签选择器,选择它所关联的 pod
   serviceName <string> -required- #headless service 的名字
   template <Object> -required- #生成 pod 的模板
   updateStrategy <Object> #更新策略
   volumeClaimTemplates<[]Object> #存储卷申请模板
#查看 statefulset 的 spec.template 字段如何定义?
#对于 template 而言,其内部定义的就是 pod,pod 模板是一个独立的对象
[root@k8smaster ~]# kubectl explain statefulset.spec.template
KIND:     StatefulSet
VERSION:  apps/v1
RESOURCE: template <Object>
DESCRIPTION:
     template is the object that describes the pod that will be created if
     insufficient replicas are detected. Each pod stamped out by the StatefulSet
     will fulfill this Template, but have a unique identity from the rest of the
     StatefulSet.
     PodTemplateSpec describes the data a pod should have when created from a
     template
FIELDS:
   metadata <Object>
   spec <Object> #定义容器属性的


通过上面可以看到,statefulset 资源中有两个 spec 字段。


第一个 spec 声明的是 statefulset 定义多少个 Pod 副本(默认将仅部署 1 个 Pod)、匹配 Pod 标签的选择器、创建 pod 的模板、存储卷申请模板。


第二个 spec 是 spec.template.spec:主要用于 Pod 里的容器属性等配置。.spec.template 里的内容是声明 Pod 对象时要定义的各种属性,所以这部分也叫做 PodTemplate(Pod 模板)。


还有一个值得注意的地方是:在.spec.selector 中定义的标签选择器必须能够匹配到 spec.template.metadata.labels 里定义的 Pod 标签,否则 Kubernetes 将 不允许创建 statefulset。


Statefulset 使用案例:部署 web 站点


#创建存储类
[root@k8smaster ~]# mkdir state
[root@k8smaster ~]# cd state/
[root@k8smaster state]# vim class-web.yaml 
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-web
provisioner: example.com/nfs
#更新资源清单文件
[root@xianchaomaster1 ~]# kubectl apply -f class-web.yaml
[root@k8smaster state]# kubectl get storageclass
NAME      PROVISIONER       RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
nfs-web   example.com/nfs   Delete          Immediate           false                  6m16s
#编写一个 Statefulset 资源清单文件
[root@k8smaster state]# vim statefulset.yaml 
apiVersion: v1
kind: Service
metadata: 
  name: nginx
  labels:
     app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata: 
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 2
  template:
    metadata: 
     labels:
       app: nginx
    spec: 
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: "nfs-web"
      resources:
        requests: 
          storage: 1Gi
#更新资源清单文件
[root@k8smaster state]# kubectl apply -f statefulset.yaml 
service/nginx created
statefulset.apps/web created
 #查看 statefulset 是否创建成功
[root@k8smaster state]# kubectl get sts -o wide
NAME   READY   AGE   CONTAINERS   IMAGES
web    2/2     59s   nginx        nginx
#查看 pod
[root@k8smaster state]# kubectl get pods -l app=nginx
NAME                    READY   STATUS    RESTARTS   AGE
web-0                   0/1     Pending   0          76s
web-1                   1/1     Pending   0          76s
#通过上面可以看到创建的 pod 是有序的
#查看 headless service
[root@k8smaster state]# kubectl get svc -l app=nginx
NAME    TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
nginx   ClusterIP  None           <none>        80/TCP       3m
#查看 pvc
[root@k8smaster state]# kubectl get pvc
www-web-0 Bound pvc-13a0482f-4927-63ff-9f2e-1b926b299c6f 1Gi RWO,RWX nfs-web 4m45s
www-web-1 Bound pvc-bc23p2a9-5bjd-00df-829f-ccb4d24g01h1 1Gi RWO,RWX nfs-web 4m41s
#查看 pv
[root@k8smaster state]# kubectl get pv
pvc-13a0482f-4927-63ff-9f2e-1b926b299c6f 1Gi RWO,RWX Delete Bound default/www-web-0 nfs-web 5m3s
pvc-bc23p2a9-5bjd-00df-829f-ccb4d24g01h1 1Gi RWO,RWX Delete Bound default/www-web-1 nfs-web 5m59s
#在data nfs_pro目录下划分的pv
#查看 pod 主机名
[root@k8smaster ~]# for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname';done 
web-0
web-1
#使用 kubectl run 运行一个提供 nslookup 命令的容器的,这个命令来自于 dnsutils 包,通过对 pod 主机名执行 nslookup,可以检查它们在集群内部的 DNS 地址:
[root@k8smaster ~]# kubectl exec -it web-1 -- /bin/bash
root@web-1:/# apt-get update
root@web-1:/# apt-get install dnsutils -y
root@web-1:/# nslookup web-0.nginx.default.svc.cluster.local 
Server: 10.96.0.10
Address: 10.96.0.10#53
Name: web-0.nginx.default.svc.cluster.local
#statefulset 创建的 pod 也是有 dns 记录的
Address: 10.244.103.139    #解析到的是 pod 的 ip 地址
root@web-1:/# nslookup nginx.default.svc.cluster.local
Server: 10.96.0.10
Address: 10.96.0.10#53
Name: nginx.default.svc.cluster.local #查询 service dns,会把对应的 pod ip 解析出来
Address: 10.244.103.139
Name: nginx.default.svc.cluster.local
Address: 10.244.121.93
[root@k8smaster state]# kubectl describe svc nginx
Name:                     nginx
Namespace:                default
Labels:                   app=nginx
Annotations:              <none>
Type:                     ClusterIP
IP:                       none
Port:                     web  80/TCP
TargetPort:               80/TCP
Endpoints:                10.244.103.139:80,10.244.121.93:80    #这两个pod都有app=ngin的标签,service把这两个都写入endpoints列表了
Session Affinity:         None
Events:                   <none>
root@web-1:/# dig -t A nginx.default.svc.cluster.local @10.96.0.10  
; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> -t A nginx.default.svc.cluster.local @10.96.0.10
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16869
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 1cf973a5daa99ac7 (echoed)
;; QUESTION SECTION:
;nginx.default.svc.cluster.local. IN A
;; ANSWER SECTION:
nginx.default.svc.cluster.local. 30 IN A 10.244.103.139
nginx.default.svc.cluster.local. 30 IN A 10.244.121.93
;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Thu Jul 14 06:49:51 UTC 2022
;; MSG SIZE rcvd: 166
root@web-1:/# nslookup kubernetes.default.svc.cluster.local
Server:   10.96.0.10
Address:  10.96.0.10#53
Name: kubernetes.default.svc.cluster.local
Address: 10.96.0.1
#解析kubernertes,有ip会把ip解析出来,没有会解析后端pod
dig 的使用
dig -t A nginx.default.svc.cluster.local @10.96.0.10
格式如下:
@来指定域名服务器
A 为解析类型 ,A 记录
-t 指定要解析的类型
A 记录:
A 记录是解析域名到 IP
资源清单详细解读:
apiVersion: v1 #定义 api 版本
kind: Service #定义要创建的资源:service
metadata: 
name: nginx #定义 service 的名字
labels:
app: nginx #service 的标签
spec:
ports:
- port: 80
name: web
clusterIP: None #创建一个没有 ip 的 service
selector:
app: nginx #选择拥有 app=nginx 标签的 pod
---
apiVersion: apps/v1
kind: StatefulSet
metadata: 
name: web
spec: 
selector:
matchLabels:
app: nginx
serviceName: "nginx" #headless service 的名字
replicas: 2 #副本数
template: #定义 pod 的模板
metadata: 
labels:
app: nginx
spec: 
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates: #存储卷申请模板
- metadata:
name: www
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: "nfs-web" #指定从哪个存储类申请 pv
resources:
requests: 
storage: 1Gi #需要 1G 的 pvc,会自动跟符合条件的 pv 绑定
扩展:
service 和 headless service 区别:
#deployment 创建的 pod 是随机生成的 解析的是 service 的 ip 地址


Statefulset 管理 pod:扩容、缩容、更新


#Statefulset 实现 pod 的动态扩容
如果我们觉得两个副本太少了,想要增加,只需要修改配置文件 statefulset.yaml 里的 replicas的值即可,原来 replicas: 2,现在变成 replicaset: 3,修改之后,执行如下命令更新:
[root@k8smaster state]# kubectl apply -f statefulset.yaml 
service/nginx unchanged
statefulset.apps/web configured
[root@k8smaster state]# kubectl get sts
web   3/3   30m
[root@k8smaster state]# kubectl get pods -l app=nginx
NAME   READY    STATUS     RESTARTS     AGE
web-0    1/1    Running    0        61m
web-1    1/1    Running    0        60m
web-2    1/1    Running    0        79s
 #也可以直接编辑控制器实现扩容
[root@xianchaomaster1 ~]# kubectl edit sts web
#这个是我们把请求提交给了 apiserver,实时修改,把 spec 下的 replicas 后面的值改成 4,保存退出
[root@xianchaomaster1 ~]# kubectl get pods -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 62m
web-1 1/1 Running 0 62m
web-2 1/1 Running 0 3m13s
web-3 1/1 Running 0 26s
#Statefulset 实现 pod 的动态缩容
如果我们觉得 4 个 Pod 副本太多了,想要减少,只需要修改配置文件 statefulset.yaml 里的
replicas 的值即可,把 replicaset:4 变成 replicas: 2,修改之后,执行如下命令更新:
[root@k8smaster state]# kubectl apply -f statefulset.yaml
service/nginx unchanged
statefulset.apps/web configured
[root@k8smaster state]# kubectl get pods -l app=nginx
NAME   READY    STATUS     RESTARTS     AGE
web-0    1/1    Running    0        64m
web-1    1/1    Running    0        63m
#Statefulset 实现 pod 的更新
[root@k8smaster state]# kubectl edit sts web
#修改镜像 nginx 变成 image: tomcat,修改之后保存退出 
[root@k8smaster state]# kubectl get pods -o wide -l app=nginx
NAME            READY   STATUS    RESTARTS   AGE   IP                 NODE       
web-0       1/1   Running   0      18s   10.244.201.106     k8snode 
web-1       1/1   Running   0      36s   10.244.133.176     k8snode2
#查看 pod 详细信息
[root@k8smaster state]# kubectl describe pods web-0
通过上面可以看到 pod 已经使用刚才更新的镜像 tomcat 了


相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
目录
相关文章
|
3天前
|
运维 Kubernetes Cloud Native
构建高效云原生运维体系:Kubernetes最佳实践
【5月更文挑战第9天】 在动态和快速演变的云计算环境中,高效的运维是确保应用稳定性与性能的关键。本文将深入探讨在Kubernetes环境下,如何通过一系列最佳实践来构建一个高效且响应灵敏的云原生运维体系。文章不仅涵盖了容器化技术的选择与优化、自动化部署、持续集成/持续交付(CI/CD)流程的整合,还讨论了监控、日志管理以及灾难恢复策略的重要性。这些实践旨在帮助运维团队有效应对微服务架构下的复杂性,确保系统可靠性及业务的连续性。
|
5天前
|
Kubernetes Cloud Native 持续交付
【Docker专栏】Kubernetes与Docker:协同构建云原生应用
【5月更文挑战第7天】本文探讨了Docker和Kubernetes如何协同构建和管理云原生应用。Docker提供容器化技术,Kubernetes则负责容器的部署和管理。两者结合实现快速部署、自动扩展和高可用性。通过编写Dockerfile创建镜像,然后在Kubernetes中定义部署和服务进行应用暴露。实战部分展示了如何部署简单Web应用,包括编写Dockerfile、构建镜像、创建Kubernetes部署配置以及暴露服务。Kubernetes还具备自动扩展、滚动更新和健康检查等高级特性,为云原生应用管理提供全面支持。
【Docker专栏】Kubernetes与Docker:协同构建云原生应用
|
6天前
|
Kubernetes Cloud Native 持续交付
构建高效云原生应用:Kubernetes与微服务架构的融合
【5月更文挑战第6天】 在数字化转型的浪潮中,企业正迅速采纳云原生技术以实现敏捷性、可扩展性和弹性。本文深入探讨了如何利用Kubernetes这一领先的容器编排平台,结合微服务架构,构建和维护高效、可伸缩的云原生应用。通过分析现代软件设计原则和最佳实践,我们提出了一个综合指南,旨在帮助开发者和系统架构师优化云资源配置,提高部署流程的自动化水平,并确保系统的高可用性。
28 1
|
7天前
|
Kubernetes Cloud Native Go
Golang深入浅出之-Go语言中的云原生开发:Kubernetes与Docker
【5月更文挑战第5天】本文探讨了Go语言在云原生开发中的应用,特别是在Kubernetes和Docker中的使用。Docker利用Go语言的性能和跨平台能力编写Dockerfile和构建镜像。Kubernetes,主要由Go语言编写,提供了方便的客户端库与集群交互。文章列举了Dockerfile编写、Kubernetes资源定义和服务发现的常见问题及解决方案,并给出了Go语言构建Docker镜像和与Kubernetes交互的代码示例。通过掌握这些技巧,开发者能更高效地进行云原生应用开发。
49 1
|
13天前
|
Kubernetes 测试技术 Docker
K8S中Deployment控制器的概念、原理解读以及使用技巧
K8S中Deployment控制器的概念、原理解读以及使用技巧
|
14天前
|
Kubernetes Cloud Native 持续交付
构建高效云原生应用:以Kubernetes为核心
【4月更文挑战第27天】 在当今数字化转型的浪潮中,企业急需构建灵活、可扩展的应用来应对不断变化的市场需求。云原生技术以其独特的优势应运而生,成为推动现代应用开发和部署的重要力量。本文深入探讨了云原生的核心组件之一——Kubernetes,解析其如何通过容器编排优化资源利用,提高应用的弹性和可维护性。同时,文章将展示如何在云平台上实现高效的服务发现、自动扩缩容以及持续集成和持续部署(CI/CD),进一步阐述云原生架构下的最佳实践和面临的挑战。
|
29天前
|
Kubernetes 监控 Cloud Native
构建高效云原生应用:基于Kubernetes的微服务治理实践
【4月更文挑战第13天】 在当今数字化转型的浪潮中,企业纷纷将目光投向了云原生技术以支持其业务敏捷性和可扩展性。本文深入探讨了利用Kubernetes作为容器编排平台,实现微服务架构的有效治理,旨在为开发者和运维团队提供一套优化策略,以确保云原生应用的高性能和稳定性。通过分析微服务设计原则、Kubernetes的核心组件以及实际案例,本文揭示了在多变的业务需求下,如何确保系统的高可用性、弹性和安全性。
23 4
|
21天前
|
消息中间件 Cloud Native 开发者
电子好书发您分享《阿里云云原生开源开发者沙龙北京站 PPT 合集 》
**阿里云开源沙龙PPT合集:北京站聚焦云原生技术** 探索云原生领域的深度与广度,[阿里云](https://developer.aliyun.com/ebook/8334/116563?spm=a2c6h.26392459.ebook-detail.5.da096cf6t38G15)分享了北京开发者沙龙的精彩内容,涵盖微服务、消息队列等主题,助力开发者洞悉行业趋势。![image](https://ucc.alicdn.com/pic/developer-ecology/cok6a6su42rzm_67b12f6cad6e4b2786859b3a668b3351.png)
19 3
|
2月前
|
人工智能 监控 Cloud Native
iLogtail 2.0 来了;通义灵码下载量破百万丨阿里云云原生 2 月产品月报
iLogtail 2.0 来了;通义灵码下载量破百万丨阿里云云原生 2 月产品月报
|
3月前
阿里云云原生恭祝大家新年快乐!
阿里云云原生恭祝大家新年快乐!

热门文章

最新文章