云原生时代 RocketMQ 运维管控的利器 - RocketMQ Operator

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
简介: RocketMQ Operator 现已加入 OperatorHub,正式进入 Operator 社区。本文将从实践出发,结合案例来说明,如何通过 RocketMQ Operator 在 Kubernetes 上快速搭建一个 RocketMQ 集群,并提供一些 RocketMQ 集群管理功能包括 Broker 扩容等。

头图.png

作者 | 刘睿、杜恒

导读RocketMQ Operator 现已加入 OperatorHub,正式进入 Operator 社区。本文将从实践出发,结合案例来说明,如何通过 RocketMQ Operator 在 Kubernetes 上快速搭建一个 RocketMQ 集群,并提供一些 RocketMQ 集群管理功能包括 Broker 扩容等。

本文主要分为三个部分:

  • 首先简单介绍一下 RocketMQ Operator 的相关知识;
  • 然后结合案例详细介绍 RocketMQ Operator 提供的自定义资源及使用方法;
  • 最后介绍 Operator 社区目前的情况并展望 RocketMQ Operator 下一步的发展方向。

相关背景知识

1. RocketMQ

2012~2013 年期间,阿里巴巴中间件团队自主研发并对外开源了第三代分布式消息引擎 RocketMQ,其高性能、低延迟、抗堆积的特性稳定支撑了阿里巴巴 双11 万亿级数据洪峰业务,其云产品 Aliware MQ 在微服务、流计算、IoT、异步解耦、数据同步等无数工况场景大放异彩。

2016 年,阿里巴巴向 Apache 软件基金会捐赠了 RocketMQ。次年,RocketMQ 顺利从基金会毕业,成为 Apache 顶级开源项目,与 Apache Hadoop,Apache Spark 一起为全球分布式、大数据领域的开发者带来福音。然而,在云原生时代的今天,RocketMQ 作为有状态的分布式服务系统,如何在大规模集群上做到极简运维,则是一个极具挑战和价值的问题。

RocketMQ 支持多种部署方式,以基本的双主双从架构为例,如下图所示。

1.png

RocketMQ 双主双从架构

这里面包括了一共 7 个 RocketMQ 服务实例:3 个 name server 实例,2 个 master broker 实例,以及 2 个 slave broker 实例。

传统的部署方式需要手动或编写脚本在每个节点上进行环境和文件配置。此外,随着用户业务的增加,存在对集群进行无缝扩容等需求。传统方式是运维人员访问不同节点,依赖操作手册和脚本按步骤进行操作来完成,耗费人力,且存在误操作的可能。一些公司可能会使用一些平台和工具如 Ansible 来帮助自动化运维,此外越来越多的公司开始集成和使用基于 Kubernetes 的云原生生态。

使用 Kubernetes 提供的 Deployment 和 StatefulSet 等原生资源可以很好地解决无状态应用的管理问题,但对于数据库和 RocketMQ 这类有状态应用,则存在很多局限性。例如对 RocketMQ 来说扩容不仅仅是拉起新的实例 Pod 就完成了,还需要同步复制 Broker 的状态信息包括 Topic 信息和订阅关系这些元数据,同时要正确配置新 Broker 的 config 参数,包括 brokerName 和 NameServer IP List 等,才能使得新扩容的 Broker 可用,而这些仅仅靠用户编写 StatefulSet,修改 size 或 replicas 然后 apply 是无法做到的。

实际上 Kubernetes 开发人员也发现了这些问题,因此引入了自定义资源和控制器的概念,让开发人员可以直接用 Go 语言调用 Kubernetes API,编写自定义资源和对应的控制器逻辑来解决复杂有状态应用的管理问题,提供特定应用相关的自定义资源的这类代码组件称之为 Operator。由具备 RocketMQ 领域知识的专家编写 Operator,屏蔽了应用领域的专业知识,让用户只需要关心和定义希望达到的集群终态,这也是 Kubernetes 声明式 API 的设计哲学。

2. Kubernetes Operator

Operator 是在 Kubernetes 基础上通过扩展 Kubernetes API,用来创建、配置和管理复杂的有状态应用,如分布式数据库等。Operator 基于 Kubernetes 1.7 版本以来引入的自定义控制器的概念,在自定义资源和控制器之上构建,同时又包含了应用程序特定的领域知识。实现一个 Operator 的关键是 CRD(自定义资源)和 Controller(控制器)的设计。

Operator 站在 Kubernetes 内部视角,为应用的云原生化打开了新世界的大门。自定义资源可以让开发人员扩展添加新功能,更新现有的功能,并且可以自动执行一些管理任务,这些自定义的控制器就像 Kubernetes 原生的组件一样,Operator 可以直接使用 Kubernetes API 进行开发,也就是说他们可以根据这些控制器编写的自定义规则来创建和更改 Pods / Services、对正在运行的应用进行扩缩容。

快速开始

本文使用 RocketMQ Operator 0.2.1 版本,展示如何使用 RocketMQ Operator 在 Kubernetes 上快速创建部署一个 RocketMQ 服务集群。

  • 准备好 K8s 环境,可以使用 docker desktop 自带的 K8s,或者 minikube;
  • 克隆 rocketmq-operator 仓库到你的 K8s 节点上;
$ git clone https://github.com/apache/rocketmq-operator.git
$ cd rocketmq-operator
  • 运行脚本安装 RocketMQ Operator;
     
$ ./install-operator.sh
  • 检查下 RocketMQ Operator 是否安装成功
$ kubectl get pods
NAME                                      READY   STATUS    RESTARTS   AGE
rocketmq-operator-564b5d75d-jllzk         1/1     Running   0          108s

成功安装时,rocketmq-operator pod 处于类似上面例子的 running 状态。

  • 应用 Broker 和 NameService 自定义资源,创建 RocketMQ 集群;

应用 rocketmq-operator / example 中的 rocketmq_v1alpha1_rocketmq_cluster.yaml 文件,快速部署一个 RocketMQ 集群。rocketmq_v1alpha1_rocketmq_cluster.yaml 文件内容如下:

apiVersion: rocketmq.apache.org/v1alpha1
kind: Broker
metadata:
  # name of broker cluster
  name: broker
spec:
  # size is the number of the broker cluster, each broker cluster contains a master broker and [replicaPerGroup] replica brokers.
  size: 1
  # nameServers is the [ip:port] list of name service
  nameServers: ""
  # replicationMode is the broker replica sync mode, can be ASYNC or SYNC
  replicationMode: ASYNC
  # replicaPerGroup is the number of each broker cluster
  replicaPerGroup: 1
  # brokerImage is the customized docker image repo of the RocketMQ broker
  brokerImage: apacherocketmq/rocketmq-broker:4.5.0-alpine
  # imagePullPolicy is the image pull policy
  imagePullPolicy: Always
  # resources describes the compute resource requirements and limits
  resources:
    requests:
      memory: "2048Mi"
      cpu: "250m"
    limits:
      memory: "12288Mi"
      cpu: "500m"
  # allowRestart defines whether allow pod restart
  allowRestart: true
  # storageMode can be EmptyDir, HostPath, StorageClass
  storageMode: EmptyDir
  # hostPath is the local path to store data
  hostPath: /data/rocketmq/broker
  # scalePodName is broker-[broker group number]-master-0
  scalePodName: broker-0-master-0
  # volumeClaimTemplates defines the storageClass
  volumeClaimTemplates:
    - metadata:
        name: broker-storage
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: rocketmq-storage
        resources:
          requests:
            storage: 8Gi
---
apiVersion: rocketmq.apache.org/v1alpha1
kind: NameService
metadata:
  name: name-service
spec:
  # size is the the name service instance number of the name service cluster
  size: 1
  # nameServiceImage is the customized docker image repo of the RocketMQ name service
  nameServiceImage: apacherocketmq/rocketmq-nameserver:4.5.0-alpine
  # imagePullPolicy is the image pull policy
  imagePullPolicy: Always
  # hostNetwork can be true or false
  hostNetwork: true
  #  Set DNS policy for the pod.
  #  Defaults to "ClusterFirst".
  #  Valid values are 'ClusterFirstWithHostNet', 'ClusterFirst', 'Default' or 'None'.
  #  DNS parameters given in DNSConfig will be merged with the policy selected with DNSPolicy.
  #  To have DNS options set along with hostNetwork, you have to specify DNS policy
  #  explicitly to 'ClusterFirstWithHostNet'.
  dnsPolicy: ClusterFirstWithHostNet
  # resources describes the compute resource requirements and limits
  resources:
    requests:
      memory: "512Mi"
      cpu: "250m"
    limits:
      memory: "1024Mi"
      cpu: "500m"
  # storageMode can be EmptyDir, HostPath, StorageClass
  storageMode: EmptyDir
  # hostPath is the local path to store data
  hostPath: /data/rocketmq/nameserver
  # volumeClaimTemplates defines the storageClass
  volumeClaimTemplates:
    - metadata:
        name: namesrv-storage
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: rocketmq-storage
        resources:
          requests:
            storage: 1Gi

注意到这个例子中 storageMode: EmptyDir,表示存储使用的是 EmptyDir,数据会随着 Pod 的删除而抹去,因此该方式仅供开发测试时使用。一般使用 HostPath 或 StorageClass 来对数据进行持久化存储。使用 HostPath 时,需要配置 hostPath,声明宿主机上挂载的目录。使用 storageClass 时,需要配置 volumeClaimTemplates,声明 PVC 模版。具体可参考 RocketMQ Operator 文档

应用上面的 yaml 文件,输入命令:

$ kubectl apply -f example/rocketmq_v1alpha1_rocketmq_cluster.yaml
broker.rocketmq.apache.org/broker created
nameservice.rocketmq.apache.org/name-service created

查看集群 Pod 状态:

$ kubectl get pods -owide
NAME                                 READY   STATUS    RESTARTS   AGE     IP             NODE             NOMINATED NODE   READINESS GATES
broker-0-master-0                    1/1     Running   0          27s     10.1.2.27      docker-desktop   <none>           <none>
broker-0-replica-1-0                 1/1     Running   0          27s     10.1.2.28      docker-desktop   <none>           <none>
name-service-0                       1/1     Running   0          27s     192.168.65.3   docker-desktop   <none>           <none>
rocketmq-operator-76b4b9f4db-x52mz   1/1     Running   0          3h25m   10.1.2.17      docker-desktop   <none>           <none>

使用默认的 rocketmq_v1alpha1_rocketmq_cluster.yaml 文件配置,我们看到集群中拉起了 1 个 name server 服务(name-service-0)和 2 个 broker 服务(1 主 1 从)。

好啦!到这里你已经成功通过 Operator 提供的自定义资源部署了一个 RocketMQ 服务集群。

  • 访问这个 RocketMQ 集群中的 Pod 来验证集群是否能正常工作;

使用 RocketMQ 的 tools.sh 脚本运行 Producer example:

$ kubectl exec -it broker-0-master-0 bash
bash-4.4# sh ./tools.sh org.apache.rocketmq.example.quickstart.Producer
OpenJDK 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
06:56:29.145 [main] DEBUG i.n.u.i.l.InternalLoggerFactory - Using SLF4J as the default logging framework
SendResult [sendStatus=SEND_OK, msgId=0A0102CF007778308DB1206383920000, offsetMsgId=0A0102CF00002A9F0000000000000000, messageQueue=MessageQueue [topic=TopicTest, brokerName=broker-0, queueId=0], queueOffset=0]
...
06:56:51.120 [NettyClientSelector_1] INFO  RocketmqRemoting - closeChannel: close the connection to remote address[10.1.2.207:10909] result: true
bash-4.4#

在另一个节点上运行 Consumer example:

$ kubectl exec -it name-service-0 bash
bash-4.4# sh ./tools.sh org.apache.rocketmq.example.quickstart.Consumer
OpenJDK 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
07:01:32.077 [main] DEBUG i.n.u.i.l.InternalLoggerFactory - Using SLF4J as the default logging framework
Consumer Started.
ConsumeMessageThread_1 Receive New Messages: [MessageExt [queueId=0, storeSize=273, queueOffset=19845, sysFlag=0, bornTimestamp=1596768410268, bornHost=/30.4.165.204:53450, storeTimestamp=1596768410282, storeHost=/100.81.180.84:10911, msgId=6451B45400002A9F000014F96A0D6C65, commitLogOffset=23061458676837, bodyCRC=532471758, reconsumeTimes=0, preparedTransactionOffset=0, toString()=Message{topic='TopicTest', flag=0, properties={MIN_OFFSET=19844, TRACE_ON=true, eagleTraceId=1e04a5cc15967684102641001d0db0, MAX_OFFSET=19848, MSG_REGION=DefaultRegion, CONSUME_START_TIME=1596783715858, UNIQ_KEY=1E04A5CC0DB0135FBAA421365A5F0000, WAIT=true, TAGS=TagA, eagleRpcId=9.1}, body=[72, 101, 108, 108, 111, 32, 77, 101, 116, 97, 81, 32, 48], transactionId='null'}]] 
ConsumeMessageThread_4 Receive New Messages: [MessageExt [queueId=1, storeSize=273, queueOffset=19637, sysFlag=0, bornTimestamp=1596768410296, bornHost=/30.4.165.204:53450, storeTimestamp=1596768410298, storeHost=/100.81.180.84:10911, msgId=6451B45400002A9F000014F96A0D7141, commitLogOffset=23061458678081, bodyCRC=1757146968, reconsumeTimes=0, preparedTransactionOffset=0, toString()=Message{topic='TopicTest', flag=0, properties={MIN_OFFSET=19636, TRACE_ON=true, eagleTraceId=1e04a5cc15967684102961002d0db0, MAX_OFFSET=19638, MSG_REGION=DefaultRegion, CONSUME_START_TIME=1596783715858, UNIQ_KEY=1E04A5CC0DB0135FBAA421365AB80001, WAIT=true, TAGS=TagA, eagleRpcId=9.1}, body=[72, 101, 108, 108, 111, 32, 77, 101, 116, 97, 81, 32, 49], transactionId='null'}]]
...
  • 删除集群,清理环境;

清除 RocketMQ 服务集群实例:

$ kubectl delete -f example/rocketmq_v1alpha1_rocketmq_cluster.yaml

清除 RocketMQ Operator:

$ ./purge-operator.sh

按照 OperatorHub 官网指导安装 RocketMQ Operator

选择 Streaming & Messaging 类别,点击 RocketMQ Operator:

2.png

  • 进入 RocketMQ Operator 页面,点击 Install 按钮;

3.png

  • 按照说明安装 OLM 和 RocketMQ Operator;

4.png

本地安装 OLM 来使用 RocketMQ Operator

  • 本地安装和动 OLM(Operator Lifecycle Manager) console;

参考:OLM 安装文档

  • 本地启动 UI 界面控制台;
$ make run-console-local

5.png

OperatorHub

  • 搜索 RocketMQ 或点击 All Items 分类中的 Streaming & Messaging,找到 RocketMQ Operator 并进行安装;
  • 安装完 RocketMQ Operator 后可以在 Installed Operators 中找到 RocketMQ Operator;

6.png

已安装的 Operators 界面

7.png

RocketMQ Operator 介绍界面

8.png

通过 UI 界面创建 NameService 自定义资源

可以在 UI 中创建指定 Namespace 下的 NameService 和 Broker 实例,并对已创建的实例进行浏览和管理。我们也可以通过命令查看当前 K8s 集群中的 Pod 状态,例如:

$ kubectl get pods -A
NAMESPACE     NAME                                            READY   STATUS    RESTARTS   AGE
docker        compose-78f95d4f8c-8fr5z                        1/1     Running   0          32h
docker        compose-api-6ffb89dc58-nv9rh                    1/1     Running   0          32h
kube-system   coredns-5644d7b6d9-hv6r5                        1/1     Running   0          32h
kube-system   coredns-5644d7b6d9-mkqb6                        1/1     Running   0          32h
kube-system   etcd-docker-desktop                             1/1     Running   0          32h
kube-system   kube-apiserver-docker-desktop                   1/1     Running   0          32h
kube-system   kube-controller-manager-docker-desktop          1/1     Running   1          32h
kube-system   kube-proxy-snmxh                                1/1     Running   0          32h
kube-system   kube-scheduler-docker-desktop                   1/1     Running   1          32h
kube-system   storage-provisioner                             1/1     Running   1          32h
kube-system   vpnkit-controller                               1/1     Running   0          32h
marketplace   broker-0-master-0                               1/1     Running   0          5h3m
marketplace   broker-0-replica-1-0                            1/1     Running   0          5h3m
marketplace   name-service-0                                  1/1     Running   0          5h3m
marketplace   marketplace-operator-69756457d8-42chk           1/1     Running   0          32h
marketplace   rocketmq-operator-0.2.1-c9fffb5f-cztcl          1/1     Running   0          32h
marketplace   rocketmq-operator-84c7bb4ddc-7rvqr              1/1     Running   0          32h
marketplace   upstream-community-operators-5b79db455f-7t47w   1/1     Running   1          32h
olm           catalog-operator-7b788c597d-gjz55               1/1     Running   0          32h
olm           olm-operator-946bd977f-dhszg                    1/1     Running   0          32h
olm           operatorhubio-catalog-fvxp9                     1/1     Running   0          32h
olm           packageserver-789c7b448b-7ss7m                  1/1     Running   0          32h
olm           packageserver-789c7b448b-lfxrw                  1/1     Running   0          32h

可以看到在 marketplace 这个 namespace 中也成功创建了对应的 name server 和 broker 实例。

以上是基于 OperatorHub 和 OLM 安装使用 RocketMQ Operator 的案例,我们将持续推送和维护新版本的 RocketMQ Operator 至该平台,方便用户获取最新更新或选择合适的 Operator 版本。

社区

RocketMQ Operator 是 Apache 社区的开源项目,服务于阿里巴巴 SaaS 类交付专有云,产品私有云环境部署等场景,同时也收到来自爱奇艺等互联网公司开源贡献者的代码提交。欢迎广大用户来社区项目中进行反馈,点击下方链接留下您的信息,让我们更好地完善 RocketMQ Operator。

链接:https://github.com/apache/rocketmq-operator/issues/20

目前,RocketMQ Operator v0.2.1 的 PR 已合并进入 community-operators 仓库,RocketMQ Operator 进入 OperatorHub.io 后,用户可以通过使用 OLM(Operator Lifecycle Manager) 来安装、订阅 RocketMQ Operator,获得持续的服务支持。

未来展望

RocketMQ Operator v0.2.1 支持的功能主要包括:Name Server 和 Broker 集群的自动创建,Name Server 集群的无缝扩容(自动通知 Broker 集群更新 Name Server IP 列表),非顺序消息下的 Broker 集群无缝扩容(新 Broker 实例会从 Broker CRD 指定的源 Broker Pod 中同步元数据,包括 Topic 信息和订阅信息),以及 Topic 迁移等。

下一步我们希望和社区一起进一步完善 RocketMQ Operator 项目,包括灰度发布,数据的全生命周期管理,容灾备份恢复,流量等指标监控、自动弹性扩缩容等方面,最终实现通过 Operator 可以覆盖 RocketMQ 服务全生命周期的管理。

欢迎大家使用 RocketMQ Operator,提出宝贵建议。

相关链接

课程推荐 

去年,CNCF 与 阿里云联合发布了《云原生技术公开课》已经成为了 Kubernetes 开发者的一门“必修课”。

今天,阿里云再次集结多位具有丰富云原生实践经验的技术专家,正式推出《云原生实践公开课》。课程内容由浅入深,专注讲解“ 落地实践”。还为学习者打造了真实、可操作的实验场景,方便验证学习成果,也为之后的实践应用打下坚实基础。

点击即可免费观看课程:https://developer.aliyun.com/learning/roadmap/cloudnative2020

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
相关文章
|
5月前
|
边缘计算 运维 Kubernetes
云原生时代的运维转型之路
【8月更文挑战第29天】 在数字化转型的浪潮中,企业IT部门正面临前所未有的挑战。本文将探讨如何通过拥抱云原生技术,实现运维工作的现代化,提升系统稳定性和效率,同时降低运营成本。我们将分享实际案例,揭示成功转型的关键因素,并展望未来运维的发展趋势。
75 3
|
1天前
|
运维 Cloud Native 开发工具
智能运维:云原生大规模集群GitOps实践
智能运维:云原生大规模集群GitOps实践,由阿里云运维专家钟炯恩分享。内容涵盖云原生运维挑战、管理实践、GitOps实践及智能运维体系。通过OAM模型和GitOps优化方案,解决大规模集群的发布效率与稳定性问题,推动智能运维工程演进。适用于云原生环境下的高效运维管理。
|
5月前
|
运维 监控 Cloud Native
自动化运维的魔法书云原生之旅:从容器化到微服务架构的演变
【8月更文挑战第29天】本文将带你领略自动化运维的魅力,从脚本编写到工具应用,我们将一起探索如何通过技术提升效率和稳定性。你将学会如何让服务器自主完成更新、监控和故障修复,仿佛拥有了一本能够自动翻页的魔法书。
|
5月前
|
运维 Cloud Native Devops
一线实战:运维人少,我们从 0 到 1 实践 DevOps 和云原生
上海经证科技有限公司为有效推进软件项目管理和开发工作,选择了阿里云云效作为 DevOps 解决方案。通过云效,实现了从 0 开始,到现在近百个微服务、数百条流水线与应用交付的全面覆盖,有效支撑了敏捷开发流程。
19392 30
|
4月前
|
运维 监控 Cloud Native
云原生时代的运维策略:从反应式到自动化
在云计算的浪潮下,运维领域经历了翻天覆地的变化。本文将带你领略云原生时代下的运维新风貌,探索如何通过自动化和智能化手段,实现从传统的反应式运维向主动、智能的运维模式转变。我们将一起见证,这一变革如何助力企业提升效率,保障服务的连续性与安全性,以及运维人员如何适应这一角色的转变,成为云原生时代的引领者。
85 9
|
4月前
|
弹性计算 运维 Cloud Native
云原生时代的运维转型之路
在云计算飞速发展的今天,传统的运维模式已难以满足现代企业的需求。本文旨在探讨如何在云原生时代下进行有效的运维转型,从传统运维到云运维的转变不仅仅是技术的升级,更是思维和方法论的革新。通过实际案例分析,我们将深入了解这一转型过程中可能遇到的挑战与解决策略,以及如何利用云原生技术提高运维效率,保障系统稳定性和安全性,从而为企业带来持续的业务创新和价值增长。
62 6
|
4月前
|
运维 Cloud Native Devops
云原生架构的崛起与实践云原生架构是一种通过容器化、微服务和DevOps等技术手段,帮助应用系统实现敏捷部署、弹性扩展和高效运维的技术理念。本文将探讨云原生的概念、核心技术以及其在企业中的应用实践,揭示云原生如何成为现代软件开发和运营的主流方式。##
云原生架构是现代IT领域的一场革命,它依托于容器化、微服务和DevOps等核心技术,旨在解决传统架构在应对复杂业务需求时的不足。通过采用云原生方法,企业可以实现敏捷部署、弹性扩展和高效运维,从而大幅提升开发效率和系统可靠性。本文详细阐述了云原生的核心概念、主要技术和实际应用案例,并探讨了企业在实施云原生过程中的挑战与解决方案。无论是正在转型的传统企业,还是寻求创新的互联网企业,云原生都提供了一条实现高效能、高灵活性和高可靠性的技术路径。 ##
258 3
|
4月前
|
运维 Kubernetes Cloud Native
云原生时代的运维转型之路
在云原生技术日益成熟的今天,传统的运维模式正面临着前所未有的挑战与机遇。本文旨在探讨如何在云原生大潮中实现运维的平滑转型,通过分析当前运维面临的困境、介绍云原生的基本概念及其对运维的影响,以及提供转型实践的策略和案例,为运维人员指明方向,帮助他们拥抱变化,乘风破浪。
|
5月前
|
运维 Kubernetes 监控
自动化运维:使用Python脚本实现系统监控云原生技术实践:Kubernetes在现代应用部署中的角色
【8月更文挑战第31天】在现代IT运维管理中,自动化已成为提高效率和准确性的关键。本文将通过一个Python脚本示例,展示如何实现对服务器的自动监控,包括CPU使用率、内存占用以及磁盘空间的实时监测。这不仅帮助运维人员快速定位问题,也减轻了日常监控工作的负担。文章以通俗易懂的语言,逐步引导读者理解并实践自动化监控的设置过程。 【8月更文挑战第31天】本文旨在探索云原生技术的核心—Kubernetes,如何革新现代应用的开发与部署。通过浅显易懂的语言和实例,我们将一窥Kubernetes的强大功能及其对DevOps文化的影响。你将学会如何利用Kubernetes进行容器编排,以及它如何帮助你的
|
5月前
|
运维 Cloud Native 容灾
核心系统转型问题之云原生分布式核心运维成本如何降低
核心系统转型问题之云原生分布式核心运维成本如何降低

相关产品

  • 云消息队列 MQ