精华总结 |「跨越疫情之境，迈向新的征程」盘点一下2022年度我们开发团队对于云原生的技术体系的变革历程-六虎

「回顾2022，展望2023，我正在参加2022年终总结征文大赛活动」

世界上并没有完美的程序，可是咱们并不因此而沮丧，由于写程序便是一个不断寻求完美的过程。

「2022年收官战现已打响，最高兴的两件事」

一转眼，2022年就这么悄然无声的过去了，对我而言，最高兴的便是新冠疫情现已不是那么可怕了，咱们不需求再担心天天怎么去排队做核酸了，哈哈……，信任你也有同感吧！一起也见证了足球史上十分伟大的一幕，梅老板总算圆梦，举起了期盼已久的大力神杯，再次回味一下这个时刻，如下图所示。

精华总结 |「跨越疫情之境，迈向新的征程」盘点一下2022年度我们开发团队对于云原生的技术体系的变革历程

PS：来看梅西笑的多高兴啊，哈哈……。

「盘点2022年的其他的重大的事件」

除了上面的两大事件之外，2022年还发生了许多其他引起国内外重视的的重大事件，国际社会波谲云诡，猴痘疫情又一波又起。此外，俄乌危机爆发、英国女王去世等等，那么我就给咱们列举一下我较为重视的一些事件如下图所示。

当然了除了上述的事件之外还有许多其他的事件呢，在这儿我就不逐个列举了，不过未来的哪一天咱们依然能够经过这篇文章回顾这几项重大的事件，仍是极好的。

「直奔主题-云原生的革新之路」

接下来咱们就要进入本篇文章的重中之重，那便是咱们2022年度，咱们公司的技能团队在面向于云原生方向做了许多方面的革新和优化以及针关于技能方向的选取做了相关的调整，如下图所示，我梳理了整体的全盘方案。

接下来咱们先来看看第一个板块【Kubernetes的版别晋级】。

注意：看到了上面的图（由于图片的巨细，以及内容较多）信任许多人都会诉苦看不清，对吧？没关系，咱们抽丝剥茧为咱们逐一拆分进行细化内容，咱们就会很容易知道具体咱们做了哪些调整和晋级以及采坑。

Q1季度——【Kubernetes的版别晋级】

版别晋级纲要

整体的版别级别的改造纲要如下图所示。

晋级版别

晋级Kubernetes集群版别是整个云原生革新体系中最要害的一环，也是最为慎重对待的操作。咱们将公司的Kubernetes服务从十分古老的版别（1.12版别）晋级到了较新的（1.25版别），接下来我会大约阐述一下晋级的原因以及大致的要素内容。

晋级版别的必要性

针关于Kubernetes版别晋级的必要性整体分为以下几个原因

【版别太低，官方无法保护、问题较多】 1.12版别过于古老，许多后续批改的安全、功用扩展，此版别姑且没有得到相关的批改且官方不支撑批改，只能运用新版别了！
【安全问题，以及workaround的问题较多】 其实新版别与旧版别差异首要在于运用了社区中经过cherrypick挑选出来的PR以及批改了安全性漏洞、没有workaround(临时解决办法)的bug。
【安稳功用力】NGINX-Ingress 愈加的安稳（v1.22开端） ，咱们都知道Ingress是作为服务恳求署理的必要入口，它的功用以及功用的扩展性决议着服务的运转才能，所以对他的晋级也是很有必要的，而且他的bug也是关于咱们服务的运转有着决议性的影响，下面便是Ingress与K8s的版别映射关系(新版别关系)
【新增功用】以下是咱们较为重视和需求的K8s的首要功用
- 「卷快照的支撑（v1.17版别开端）」 现在咱们迫切需求，不然数据卷的恢复才能，彻底不能用啊！每次咱们都需求考虑自己去完成备份。
- 「准入Webhook（v1.19版别开端）」 将自定义战略或验证与 Kubernetes 集成的首要方法。从 v1.19 开端，Admission Webhook 能够回来正告音讯，传递给发送恳求的 API 客户端。正告能够与答应或拒绝的呼应一起回来。
- 「Exec勘探超时处理（v1.20版别开端）」 针关于嗅探机制的超时处理机制
- 「添加了对 Pod 层面发动探针和活泼性探针的操控（v1.20版别开端）」 向探针添加initializationFailureThreshold，答应在容器的初始发动期间呈现更多的失利。
【可移植才能】Volume快照操作的规范体系，并答运用户以可移植的方法在任何 Kubernetes 环境和支撑的存储供给程序上合并快照操作。
【容器才能扩展】在v1.20版别开端它移除 dockershim ，从而就完成了能够扩展为其他容器完成的急促

tips：保护dockershim 现已成为 Kubernetes 保护者肩头一个沉重的负担。创建 CRI 规范便是为了减轻这个负担，一起也能够添加不同容器运转时之间平滑的互操作性。但反观 Docker 却至今也没有完成 CRI，所以费事就来了。

替换可视化界面

首要是现在K8s容器办理而言首要选用了以下这三个可视化页面东西：别离是Rancher、kuboard和Kubernetes Dashboard。接下来别离介绍一下这三个东西。

Rancher（摒弃挑选）

Rancher是一个开源的企业级多集群Kubernetes办理渠道，完成了Kubernetes集群在混合云+本地数据中心的集中布置与办理，以确保集群的安全性，加快企业数字化转型。

中文官网主页（最新）

在晋级到高版别K8s集群版别之前，咱们运用的都是Rancher办理东西，如下图所示。

Kuboard（终究挑选）

kuboard是一款专为 Kubernetes 规划的免费办理界面,兼容 Kubernetes 版别 1.13 及以上。看到这儿信任咱们应该知道了咱们为什么改为kuboard了吗？1.13版别才能用哦。低版别不行滴。

那你会说为什么挑选kuboard，而抛弃了之前一向运用的Rancher呢？首要我概括一下理由哈。

【运用体会】rancher拜访速度过慢，由于要加载的组件和烘托的许多，尽管新版别现已优化了。
【dashboard看板】rancher在dashboard部分做的仍是不如kubernetes dashboard或许kuboard愈加直观。
【资源消耗】比照了以下咱们的开发环境的运用效果之后，发现kuboard是三者（kubernetes dashboard、kuboard和rancher）之中最少的。

关于kubernetes dashboard而言我就不多说了，咱们都用过，关于后续版别的页面效果和优化也还好一般，比起Rancher差不多少，细节做的优势不多，归纳了一下最后挑选了资源消耗最小的kuboard。

当然哈，还有许多其他的K8s的可视化办理东西，例如：lens、octant、weave-scope、还有我自己最喜欢的面向云原生运用的容器混合云的办理东西kubesphere、KuberLogic及 Kubecube等等，在这儿就不逐个介绍了。

终究咱们将开高兴心与kuboard度过一段较长的旅程。

在这儿给没有接触过kuboard的小伙伴一些材料。能够学习一下哈。

Github地址：github.com/eip-work/ku…
Kuboard教程：press.demo.kuboard.cn/

还有对应的demo演示服务，能够让您快速上手做操练作业，多么便利，你能够不需求建立自己的Kuboard服务，如下图所示。

咱们讲完了咱们大致晋级了对应的版别晋级之后，想跟咱们在共享一下，咱们在晋级过程中所呈现的问题，可是由于篇幅所限，在这儿就不列举了，后边有时机再跟咱们共享。而咱们接下来要介绍一下发生在老版别K8s的时分所呈现的种种问题。

Q2季度——【Kubernetes的装备优化调整】

2022年技能团队针关于Kubernetes的装备优化调整首要做了4个方面的问题的调整和优化作业道路，当然这只是面向于研制层面的哈。

探针经常会无缘无故Killed咱们的服务
Kubernetes的对应Kill容器Pod的编码剖析
Kubernetes的Yaml文件装备优化阶段
kubernetes的运用毛病排查

探针经常会无缘无故Killed咱们的服务

探针的品种

livenessProbe：指示容器是否正在运转。假如存活态勘探失利，则 kubelet 会杀死容器，而且容器将依据其重启战略决议未来。假如容器不供给存活探针，则默许状况为 Success。
readinessProbe：指示容器是否准备好为恳求供给服务。假如安排妥当态勘探失利，端点操控器将从与 Pod 匹配的一切服务的端点列表中删除该 Pod 的 IP 地址。初始推迟之前的安排妥当态的状况值默许为 Failure。假如容器不供给安排妥当态探针，则默许状况为 Success。
startupProbe：指示容器中的运用是否现已发动。假如供给了发动探针，则一切其他探针都会被禁用，直到此探针成功为止。假如发动勘探失利，kubelet 将杀死容器，而容器依其重启战略进行重启。假如容器没有供给发动勘探，则默许状况为 Success。

而整体所呈现的原因大致有这么几种：

问题1 — 致命的143编码

探针检测导致进程会呈现直接kill -15，被直接Shutdown掉（K8s的exit code是143），由于探针恳求超时而且抄过来所装备的阈值范围内，即可呈现这个问题，终究频频让咱们的事务体系主动被干掉或许主动下线，用户体会度很差！咱们总称之位这便是致命的143编码，如下图所示。

【探针装备参数调整】在体系负载过高的时分以及针关于关于呼应速度和吞吐不同场景的服务需求别离去处理和考虑对应的参数，而不能同日而语！

这便是咱们惯例的探针装备，首要重视的便是：timeout(超时时刻)、距离、失利阈值。三者贯穿的概念便是在距离N秒情况下，当超时/失利的次数超过了失利阈值之后，就会被Kill掉。

initialDelaySeconds：容器发动后要等候多少秒后才发动发动、存活和安排妥当探针，默许是 0 秒，最小值是 0。
periodSeconds：履行勘探的时刻距离（单位是秒）。默许是 10 秒。最小值是 1。
timeoutSeconds：勘探的超时后等候多少秒。默许值是 1 秒。最小值是 1。
successThreshold：探针在失利后，被视为成功的最小连续成功数。默许值是 1。存活和发动勘探的这个值必须是 1。最小值是 1。
failureThreshold：当勘探失利时，Kubernetes 的重试次数。对存活勘探而言，抛弃就意味着重新发动容器。对安排妥当勘探而言，抛弃意味着 Pod 会被打上未安排妥当的标签。默许值是 3。最小值是 1。

装备定论心得

面向于重视吞吐的服务或许核算相关的服务，最好不要参加K8s的相关探针，而是参加其他监控，不然很容易再负载较高的时分，把你的服务直接干掉。咱们选用了参加了预警，经过比照事务数据来承认是否真实服务假死或许夯住了。
面向于重视用户体会和呼应时刻的相关服务，咱们是将依据量的巨细，在不同的时刻范围内切换不同的装备，下降探针呈现的误判问题。当然你也能够是定义 TCP 的存活勘探替代Http勘探！

问题2 — 预警忽然失效，无法进行内存预警

给咱们看一下咱们的装备容器装备：

信任这两个选项咱们并不生疏，首要装备的最大内存便是3G。而咱们的预警阈值是90%，那么预警的内存巨细便是2.7G，而咱们的JVM参数是1.8G。

这会导致咱们JVM都crash了，这边还没有到达预警呢！所以这边咱们调整了一下咱们的核算公式。

咱们的Pod（容器）内存>JVM内存>预警内存（90%）。

问题3 — pod频频会被OOM Killed -137

这个与上面的不一样哦！OOM Killed是容器内部的内存溢出，而不是JVM的。所以这地方首要的原因是什么呢。经过咱们的长时刻考证，最后得出的定论便是直接内存导致，一向处于RSS中，不会被收回，尽管咱们的一向在履行GC，可是由于好久没有履行FGC，所以就没有办法进行收回Off Heap Space。所以假如感兴趣的小伙伴能够参考我的之前的剖析文章。

【JVM毛病问题排查心得】「内存确诊系列」JVM内存与Kubernetes中pod的内存、容器的内存不一致所引发的OOMKilled问题总结（上）

问题4 — pod频频会被Node进行驱赶(CPU过高/内存问题/硬盘问题)

后续的针关于某一个Pod的资源过高所引起的Node驱赶完成，咱们运用以下标志来装备软驱赶条件：

eviction-soft：一组驱赶条件，如 memory.available<1.5Gi，假如驱赶条件持续时长超过指定的宽限期，能够触发 Pod 驱赶。
eviction-soft-grace-period：一组驱赶宽限期，如 memory.available=1m30s，定义软驱赶条件在触发 Pod 驱赶之前必须坚持多长时刻。
eviction-max-pod-grace-period：在满足软驱赶条件而中止 Pod 时运用的最大答应宽限期（以秒为单位）。

Kubernetes的对应Kill容器Pod的编码剖析

（Exit Codes 0）docker run hello-world 进程结束，exit code为0
（Exit Codes 1）程序本身溃散报错，或许人工把dockerfile中的发动指令写错，都会报exit code 1
（Exit Codes 137）程序收到了SIGKILL (signal kill)信号,被手动干预杀死进程，或许违背体系约束被杀都会报错 exit code 137
（Exit Codes 139）程序 segmentation fault，程序试图拜访不被答应拜访的内存地址，或许是程序代码或许是基础镜像的过错，或许报错 exit code 139
（Exit Codes 143）容器收到了 SIGTERM 指令，也便是中止的指令，例如docker stop 或许 docker-compose down ， docker stop 也或许会出 137 的exit code （当程序不恰当处理SIGTERM过错）

后边我没就经过以上的这些exit code的分类和概括，就像相应的问题处理。在这儿不管是137、143的这个编码都是经过128+kill -（N）算出来的，137 便是 -9 杀掉的进程，143则是 -15。

Kubernetes的Yaml文件装备优化阶段

其实针关于Yaml文件装备优化的地方咱们调整了许多许多，在这儿咱们就单纯的叙说几个改动点吧。

时区问题调整

问题原因是咱们的服务是跨国的，垮了许多的时区方位，甚至在墨西哥的时分还需求考虑的是冬令时和夏令时的原因，所以对时刻特别的敏感，所以这就需求再K8s在不同的地区树立不同的指守时区才能够，例如下图所示。

所以咱们需求经过环境变量ENV，在不同的环境进行优化，之前没有考虑到这一点，导致许多环境的时刻居然还用的是东八区的时刻，太离谱了哈！

探针品种选取

仍是源于上面的探针居然把咱们的事务服务给shutdown了，首要原因便是恳求超时，那超时的直接原因首要便是容器的线程池满了，底子原因是恳求处理的时刻过长，那么这时分有什么workaround方案吗？

好咱们选取了首要便是将探针的勘探方法改为Exec形式与Tcp形式。不知道咱们对这两个方法了解的多吗？首要便是为了考虑http资源池满了所引发的超时问题哈。

exec：在容器内履行指定指令。假如指令退出时回来码为 0 则以为确诊成功。
tcpSocket：对容器的 IP 地址上的指定端口履行 TCP 查看。假如端口翻开，则确诊被以为是成功的。假如远程体系（容器）在翻开衔接后立即将其封闭，这算作是健康的。

最后咱们挑选了tcpSocket形式进行监控了咱们许多的流式核算以及吞吐较高的容器服务，果然容器Down的几率下降了许多，当然还有许多许多优化的装备，由于篇幅所限，所以更多的共享我会出专门的专栏为咱们具体共享。

Q3季度——【Kubernetes内存问题剖析】

本次内容和云原生和k8s暂时没有太多直接关系。首要是咱们内部排查问题所得出的经验之谈！

Heap堆内存呈现过高的问题

首要原因是日志打印过多所导致的，会导致进程的内存一向处于一个条平衡线。所以主张建立少打无用日志，尽或许打印精确信息，而不是整个对象的信息哈！如下图所示。

Native内存剖析问题VM进程不一致问题

首要便是针关于直接内存中的类空间的预占用资源到达了1G之多，这个太不契合常理了，所以这个比较的明细，所以这个地方算是咱们后边改造的方案，参加了 direct ByteBuffer -> -XX:MaxDirectMemorySize的操控。以及守时履行System.gc()。

K8s勘探Java进程与堆内存不相符，导致含有未知内存占用

两者都是和直接内存有关系，假如咱们想了解为什么，能够参考我下面的这篇文章的下集。

【JVM毛病问题排查心得】「内存确诊系列」JVM内存与Kubernetes中pod的内存、容器的内存不一致所引发的OOMKilled问题总结（下）

Grafana+Prometheus实例层级监控

首要是为了针关于容器化进行树立容器机制监控。首要树立了pod内存监控、docker容器内存监控和CPU负载才能的监控，如下图所示。

有了这个咱们就能够调查任何时刻范围内内存以及CPU相关的资源运用信息了。

Q3季度——【云原生技能晋级】

在本年咱们三个方向的技能升华，其间对应的k8s集群晋级上面基本介绍过了，接下来首要介绍【Dubbo云原生之路-晋级到Dubbo 3，而且对接K8s】和【Apache APISI 云原生网关服务】

Dubbo云原生之路-晋级到Dubbo 3，而且对接K8s

在云原生时代，底层基础设施的革新正深刻影呼运用的布置、运维甚至开发过程，往上也影响了 Dubbo3 微服务技能方案的选型与布置形式。咱们公司也一向在不断推动和落地K8s云原生方向。

Dubbo3布置

Dubbo3 开发的运用能够原生布置到 Kubernetes 渠道，Dubbo3 在地址、生命周期等已规划可与 Kubernetes 等容器调度渠道对齐；关于要进一步复用 Kubernetes 底层基础设施才能的用户来说，Dubbo3 也已对接到了原生的 Kubernetes Service 体系。首要便是依托这三个部分。

布置 Dubbo 运用到 Kubernetes
依据 Kubernetes 内置 Service 完成服务发现
将 Dubbo 运用对接到 Kubernetes 生命周期

装备Service.yml

apiVersion: v1
kind: Service
metadata:
  name: apiserver-consumer
  namespace: dubbo-namespace
spec:
  clusterIP: None
  selector:
    app: apiserver-consumer
  ports:
    - protocol: TCP
      port: 20880
      targetPort: 20880

装备Deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: apiserver-consumer
  namespace: dubbo-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: apiserver-consumer
  template:
    metadata:
      labels:
        app: apiserver-consumer
    spec:
      containers:
        - name: server
          image: XXX/dubbo:apiserver-consumer_0.0.1
          ports:
            - containerPort: 20880
          livenessProbe:
            httpGet:
              path: /live
              port: 22222
            initialDelaySeconds: 5
            periodSeconds: 5
          readinessProbe:
            httpGet:
              path: /ready
              port: 22222
            initialDelaySeconds: 5
            periodSeconds: 5
          startupProbe:
            httpGet:
              path: /startup
              port: 22222
            failureThreshold: 30
            periodSeconds: 10

Apache APISIX 云原生网关服务

咱们署理端选型为APISIX作为咱们的云原生网关替代之前的Nginx，具体而言给咱们介绍一下Apache APISIX的优势是什么？

Apache APISIX的优势是什么？

APISIX是一个动态、实时、高功用的云原生 API 网关，供给了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量办理功用。它能够在云原生和微服务的技能环境下，帮助企业解决一些新的问题。比如经过全动态特性将事务的流量进行主动扩缩容、经过一次性修改进行更便利地集群化办理等。

全渠道

云原生: 渠道无关，没有供货商锁定，不管裸机仍是 Kubernetes，APISIX 都能够运转。
运转环境: OpenResty 和 Tengine 都支撑。
支撑 ARM64: 不必担心底层技能的锁定。

多协议

TCP/UDP 署理: 动态 TCP/UDP 署理。
Dubbo 署理: 动态署理 HTTP 恳求到 Dubbo 后端。
动态 MQTT 署理: 支撑用 client_id 对 MQTT 进行负载均衡，一起支撑 MQTT 3.1.* 和 5.0 两个协议规范。
gRPC 署理：经过 APISIX 署理 gRPC 衔接，并运用 APISIX 的大部分特性办理你的 gRPC 服务。
gRPC 协议转化：支撑协议的转化，这样客户端能够经过 HTTP/JSON 来拜访你的 gRPC API。
Websocket 署理
Proxy Protocol
Dubbo 署理：依据 Tengine，能够完成 Dubbo 恳求的署理。
HTTP(S) 反向署理
SSL：动态加载 SSL 证书。

Q4季度——【K8s晋级Autoscaling】

现在咱们正在针关于云原生的革新作业很重要的一步便是将逐渐替换K8s自带的Autoscaling机制，从而运用AWS的Autoscaling，它叫做Karpenter，是新一代 Kubernetes auto scaling 东西。为什么会这么做？咱们先来分一下两者差异。

Kubernetes的Autoscaling

Kubernetes现已完成集群主动缩放的东西，有Cluster Autoscaler、Escalator和Cerebral等。

K8s集群依据需求的增加而主动扩容；经过有用整合使用资源和中止不必要的节点而较少基础架构带来的成本；其开发者是中立的，支撑一切主流的公有云厂商；运用广泛，经过了实战的考验；支撑大约1000个节点的集群。

AWS的Autoscaling

Karpenter 是一个为 Kubernetes 构建的开源主动扩缩容项目。它提高了 Kubernetes 运用程序的可用性，而无需手动或过度装备核算资源。

它旨在经过调查不行调度的 Pod 的聚合资源恳求并做出发动和中止节点的决议计划，以最大极限地削减调度推迟，从而在几秒钟内（而不是几分钟）供给合适的核算资源来满足您的运用程序的需求。

Karpenter与Kubernetes的Autoscaling的差异

Karpenter取消了节点组的概念，这是它与Cluster Autoscaler 的底子差异，节点组通常是效率较低的原因之一，此外Karpenter愈加有优势的特点如下：

Karpenter 直接供给核算资源，动态的核算pod需求何种巨细的EC2实例类型作为节点。
从Cluster Autocaler 的静态模版到 Karpenter 的动态生成模版，不必去创建节点组来确定实例的各种特点，从而下降了装备的复杂性。
Cloud Provider的API负载也会大大削减，在Cluster Autocaler 中，Auto Scaling group总会不断恳求Cloud Provider来承认状况，在集群庞大以后，很或许碰到API调用约束，造成整个体系中止呼应。
Karpenter只在创建和删除容量时调用API，这种规划能够支撑更高的API吞吐量。没有了节点组，调度的复杂程度也被下降，由于Cluster Autoscaler 不同节点组有不同特点，需求考虑pod被调度到哪个节点组。

归纳一下，咱们会慢慢搬运挑选功用更好，切换速度更快的Karpenter，此外由于后边咱们也要愈加全方面介入到AWS中，所以Karpenter是必然之选。

【2023年探究的方向】

接下来咱们会为后续的发展方向首要体现：

完成多云化办理
完成混合云办理
扩展其他厂商的云渠道

那么咱们首要要晋级的便是可视化办理东西，咱们接下来看看咱们的可视化东西的挑选。

Rainbond

现在方案选用云原生时代的“运用级别”多云办理渠道Rainbond，这个是一个较为新颖的渠道。

Rainbond是一个云原生运用办理渠道，运用简单，不需求懂容器、Kubernetes和底层复杂技能，支撑办理多个Kubernetes集群，和办理企业运用全生命周期。它深度整合运用开发、微服务架构、运用交给、运用运维、资源办理，办理高度主动化，完成统一办理一切运用、一切基础设施和一切IT流程。

这归于咱们的挑选之一，此外还有一个便是KubeSphere，咱们来看一下KubeSphere是什么。

面向云原生运用的容器混合云—KubeSphere

KubeSphere 是在 Kubernetes 之上构建的面向云原生运用的分布式操作体系，彻底开源，支撑多云与多集群办理，供给全栈的 IT 主动化运维才能，简化企业的 DevOps 作业流。作为全栈的多租户容器渠道，KubeSphere 供给了运维友爱的向导式操作界面，帮助企业快速构建一个强大和功用丰富的容器云渠道。

企业级功用扩展

多云与多集群办理、Kubernetes 资源办理、DevOps、运用生命周期办理、微服务办理（服务网格）、日志查询与搜集、服务与网络、多租户办理、监控告警、事件与审计查询、存储办理、拜访权限操控、GPU 支撑、网络战略、镜像仓库办理以及安全办理等。

功用比照

开源社区活泼度比照

容器化才能比照

CI/CD的比照

未来咱们将要抛弃kuboard/kubernetes dashboard办理东西，从而挑选KubeSphere 和Rainbond。两者相比而言各有千秋，关于多云以及云原生扩展角度而言咱们会偏重Rainbond，而关于私有云而言咱们会偏重于KubeSphere。

其他渠道的云原生技能环境

Google Computer Engine

未来发展到Google云渠道服务布置K8s集群布置咱们的服务。

AWS EC2

未来发展到亚马逊AWS云渠道服务布置K8s集群布置咱们的服务。

Azure

未来发展到微软Azure云渠道服务布置K8s集群布置咱们的服务。

现在咱们的2022年~2023年的云原生革新历程便是这样，期望咱们多多支撑和多多纠正！

精华总结 |「跨越疫情之境，迈向新的征程」盘点一下2022年度我们开发团队对于云原生的技术体系的变革历程