收藏！2022中小企业最佳DevOps工具

中小企业最佳DevOps工具

俗话说得好工欲善其事必先利其器，接下来给大家推荐10款最佳的DevOps工具，相信每一款大家并不陌生，一些优秀的工具无论是对于运维还是开发，都是至关重要的，不仅可以降低运维成本还可以提高运维效率。

今天分享的10款最佳DevOps工具，基本都是我正在使用的并且附带一些使用感受。

推荐的每一款工具，我都会给大家详细介绍工具的优势以及推荐工具的理由。

最佳DevOps工具一览

EKS（腾讯云）容器编排集群

首先给大家介绍的就是腾讯云的EKS服务，EKS是腾讯云的容器集群服务，使用者无需搭建和维护Kubernetes集群底层架构，真正意义上做到了开箱即用的容器集群。EKS产品使用时不需要购买K8S集群底层None节点，EKS从底层架构中就完全托管了一套K8S集群，只需在EKS中部署Web程序的工作负载Deployment控制器，就可以快速的将Web程序容器化。

对于Kubernetes初学者、Kubernetes使用经验较少的开发同事，为了避免使用Kubernetes时遇到大量的环境、网络、底层组件等众多问题，从而影响开发效率，强烈推荐使用腾讯云的EKS容器编排集群，在EKS中部署工作负载时，无需编写控制器的YAML文件，只需要在图形化界面鼠标选择标签对应的属性，就可以快速的完成工作负载的创建，并且创建完工作负载后，会自动的帮我们创建好Service资源，我们仅需要配置一个Ingress控制器就可以让Web程序发布在互联网环境。Ingress控制器也是通图形化界面选择对应标签的属性完成创建。

相对于传统的Kubernetes集群而言，EKS无需关心集群None节点，无需维护集群底层架构，无需担心节点高可用问题，无需担心集群资源使用率问题，无需担心集群监控问题。

在这里提一个我们公司使用传统Kubernetes集群时遇到的网络问题：由于机房网络原因导致服务器无法使用114.114.114.114通用的DNS服务器，从而使容器无法解析外网域名，我们的程序会去调用公网上的其他平台，因此就导致很多接口请求超时了，临时解决方法就是给集群中的每一台Node节点更换了DNS地址，并重启所有的Calico组件，基于这个问题，如果当时使用了腾讯云的EKS，Node节点层面可能会遇到的问题将不需要我们操心。

接下来我们说一说EKS产品的诸多特性以及产品优势：

• 原生支持：EKS本身就是腾讯云的产品，对于腾讯云的其他产品例如负载均衡、对象存储、网络服务都可以直接对接，并且他们直接调度都是通过内网地址的，不仅可以减少网络带宽，还能提高请求效率。
• 无服务器：EKS无需用户管理任何服务器节点，上面也是跟大家提到过了，我们只需要管理程序的Deployment工作负载，以Pod的方式交互资源即可。
• 安全可靠：EKS是基于腾讯云成熟的虚拟化技术以及网络架构，服务的高可用性高达99.95%，我司使用一年来，达成了0宕机率。
• 秒级伸缩：EKS集成了Kubernetes的HPA功能，可以根据程序的负载情况从而对工作负载进行弹性伸缩。
• 降低成本：由于EKS无服务器的特性，从维护成本来看，仅仅需要维护一下工作负载，工作负载我们也需编写资源编排文件，对于运维成本是很低的。
• 服务集成：对于云上的产品，EKS可以很好的去对接做到高度集成，例如COS、CBS、CFS等等。

EKS还有一个很贴心的设计，在创建集群时可以根据业务的类型，从而创建不同方式的容器集群，一共分为四种集群：Serverless集群、标准集群、边缘集群、注册集群。

对于大型的微服务架构、日均PV量很高的平台，建议直接上EKS云K8S集群，降低了运维成本后，我们可以有更多的时间去优化平台架构，从而使平台的稳定性更高以提高用户的体验度，另外要记住一点，只要这个产品能提高业务的效率，我们就可以去采用它，无需非要去使用原始的技术产品。

另外如果你的网站平台存在某一时刻是流量的高峰期，并且高峰期并不频繁，例如两三个月一次，这时建议你在高峰期的时候使用腾讯云的EKS容器集群，无需管理底层服务，只需要创建工作负载即可，整个流程下来10分钟不到，并且性能也是非常强悍的。

Harbor镜像仓库

对于DevOps、云原生等领域的主流工具，容器方式部署已经是最基本的场景了，甚至个人开发的软件都会发布容器的部署方式，因为容器部署不仅快速高效还能提高可维护性，并且占用的系统资源很少，既然容器已经这么火了，容器是基于镜像部署的，想要对于镜像进行很好的管理，无疑是使用镜像仓库了。

市面上镜像仓库有很多种，在这里给搭建推荐使用Harbor镜像仓库，Harbor是由VMware公司开源的企业级的Docker Registry管理项目，它包括权限管理(RBAC)、LDAP、日志审核、管理界面、自我注册、镜像复制和中文支持等功能。

Harbor镜像仓库的图形化界面我认为比DockerHub都要优秀，对于镜像的管理清晰可见，下图就是我的Harbor镜像仓库的页面。

Rancher可视化管理K8S集群

Rancher可以说是一个全栈式的Kubernetes容器管理平台，对于使用传统的Kubernetes集群的用户，Rancher一定是首选的可视化管理平台，Rancher不仅可以使用Docker在集群外部部署，也可以使用Helm在Kubernetes集群内部部署，从一定程度上与集群进行里分离，即使集群宕机了，也可以使用Rancher进行维护。

Rancher的应用商店包含了一套内置的 DevOps 开发工具。Rancher 通过了一些云原生的生态系统认证，包括安全工具、监控系统、容器镜像、存储和网络驱动等。

既然提到了Rancher的应用商店，就要聊一聊Rancher应用商店当年给我解决的一大难题：回想2019年哪会，Kubernetes技术相对来说不太成熟，资料很少会的人更少，我司将传统Web程序迁移到Kubernetes后，对于监控方面无从下手，思路很迷茫，不知道应该监控容器的哪些指标，并且不知道应该以何种方式监控Kubernetes集群，虽然Prometheus是最好监控Kubernetes的手段，但是奈何当时对Prometheus并不是很了解，后来在Rancher的应用商店发现了Prometheus套件，安装完这套组件后，在Rancher中就能自动使用Prometheus对Kubernetes集群进行自动监控，无需人为进行配置，并且控制器资源、Pod资源也会自动纳入了监控，即使我们对Prometheus监控不熟悉，通过Rancher的应用商店依然可以做到Kubernetes集群的全方面监控。

使用Rancher管理Kubernetes集群，用户也无需对Kubernetes有较深入的了解，因此一切都是图形化操作的，只要了解Kubernetes的原理就可以利用Rancher快速部署应用程序。

Kubesphere

除了Rancher可视化工具外，我个人最爱用的就是Kubesphere了，从视觉角度来说，Kubesphere更符合我的审美，界面相当的漂亮。

Kubesphere也是全栈化的容器平台，KubeSphere 目前提供了工作负载管理、微服务治理、DevOps 工程、Source to Image、多租户管理、多维度监控、日志查询与收集、告警通知、服务与网络、应用管理、基础设施管理、镜像管理、应用配置密钥管理等功能模块，开发了适用于适用于物理机部署 Kubernetes 的 负载均衡器插件 Porter，并支持对接多种开源的存储与网络方案，支持高性能的商业存储与网络服务。

Kubesphere最令我满意的地方就在于，提供了可视化的Istio服务治理网格的功能，对于微服务而言我们通常需要借助第三方工具才能形成可视化的链路跟踪机制，但是Kubesphere内部就给我们集成了。并且Kubesphere还提供了Istio的熔断、灰度发布、流量监控、限流等完善的流量治理功能。对于Istio了解不深的同学，建议部署Kubesphere。

K3S

如果有特殊场景，急需要一套Kubernetes集群，但是又没有那么多的服务器，且也不想花大量的时间去部署K8S集群，这时推荐你去部署一套K3S集群，K3S集群是一个轻量级的K8S集群替代品，仅需51M内存就可以将K3S运行起来，如果想进行一些测试项目，强烈建议你去做一个K3S集群，不仅占用的资源少，而且功能和K8S大体不差。并且也与K8S完全兼容，这就意味着你不用花很多的时间去研究K3S，并且K8S的Yaml文件也可以平滑的在K3S集群中创建。

K3S将安装Kubernetes所需的一切文件打包进，仅有60MB大小的二进制文件中，并且完全实现了Kubernetes的API接口。

Helm

如果你面临着编写大量的K8S Yaml资源编排文件，并且各个自编排文件中只有个别的参数不同，例如微服务程序在K8S集群中部署，使用的Yaml资源编排文件基本上很相似，只是个别的参数不同。当存在几十个甚至上百个资源编排文件时，维护起来相当困难。

基于这个场景，我强烈建议你使用Helm包管理系统，可以将Helm想象成一个涵盖部署程序所用的所有Yaml文件的模板，使用Helm Chart包部署工作负载时，只需要传入这个工作负载的相关参数，无需在编写这个工作负载的Yaml文件，即可在K8S集群中完成部署。

Helm目前最常用的版本时V3版本，Helm V3相较于Helm V2取消了Tiler组件，在V2版本中，Helm客户端需要写一大堆RBAC授权文件，并且需要部署Tiler，然后在将Tiler进行授权，并且允许Tiler可以操作K8S的哪些命名空间，最后再调用K8S Apiserver完成服务的部署。在V3版本汇总仅仅只剩下了一个Helm客户端工具，不再需要Tiler而是直接使用了Kubeconfig，拥有对整个K8S的操作权限，直接就可以调用K8S Apiserver进行服务的部署。

对于K8S集群的Yaml文件管理，推荐使用Helm包进行维护，可以大大的提高运维效率，并且还可以使用Helm生成当前工作负载的Yaml文件。

Istio

很多互联网公司都将传统结构的Java程序重构成了微服务，对于微服务容器化直接使用Kubernetes集群部署也可以，但是对于一些细腻的微服务治理，建议一定要采用Istio+Kubernetes的部署架构。

Istio 是 ServiceMesh 的产品化落地，也是基于Kubernetes集群最热门的微服务治理网格，可以通过在现有的工作负载上绑定Sidecar服务，就可以将工作负载接入到Istio服务网格进行微服务治理，在应用程序无需调整代码的前提下，即可实现服务熔断、灰度发布、流量限速、超时重试等等诸多功能。

Istio是目前非常主流的服务网格产品，功能丰富，成熟度高，Istio 解决了开发人员和运维人员所面临的从单体应用向分布式微服务架构转变的挑战。

随着云原生时代的发展，目前应用程序都是部署在K8S集群进行管理，而微服务程序也使用Pod控制器去部署，部署使用是没有问题的，但是想更加细腻的微服务管理，比如流量的控制、链路状态跟踪、速率限制等等这些功能，K8S是无法满足的，因此就需要使用服务网格去管理微服务程序，在企业中最常用的方案就是将Istio与K8S结合起来使用，K8S主要负责应用的部署、弹性伸缩、资源隔离，Istio主要负责微服务治理、流量监控、熔断限流、动态路由、链路追踪等功能，两者可以完美的取长补短。

如果要将微服务程序迁移到Kubernetes集群，建议直接将微服务部署在Istio服务网格内，通过Istio自身的特性，可以对微服务程序实现很多流量管理方面的功能，例如服务熔断、金丝雀灰度发布、A/B测试、流量限流、请求超时与重试等等。

对于Istio服务网格更多核心概念，可以参考这篇文章：Istio服务网格进阶①：Istio服务网格核心理论概念

Ansible

对于DevOps工程师来说更倾向于平台自动化层面，对于自动化工具来说，不得不推荐一下Ansible，作为已经使用Ansible三年的用户而言，Puppet、SaltStack在Ansible面前都是弟弟，更是当你掌握Python开发后，Ansible简直就是提高运维效率的得力助手。

Ansible可以做什么：

• 同时几百台服务器要部署Nginx服务，并在部署后要配置日志切割，这时我们可以编写一个完成工作的脚本，同时结合Ansible对几百台服务器同时执行。
• 上个运维走的很匆匆，并没有留下任何关于服务器层面的文件，这时我们可以通过Ansible批量探测存活主机的IP，并将其记录到表格中，再通过相关命令结合Ansible获取各个服务器的硬件资源。
• 每当有新服务器加入工作环境时，都需要对服务器进行初始化，这时我们也可以通过Ansible，将其加入到新的分组中，一条命令即可完成新服务器的初始化。

Ansible部署非常简单，直接使用Yum进行安装即可，并且无需安装客户端，这可是省了我们很多的麻烦，只要目标服务器有ssh服务即可，Ansible服务端也不需要启动任何服务，从一定层面节省了服务器的部分资源，只有在使用Ansible时，才会产生资源的消耗。如果你还会Python开发，你可以根据自己的需求去定制Ansible模块，大大提高运维的效率。

Zabbix

Zabbix监控软件可以监控各种服务器参数、网络设备参数，可以说是只有你想不到的监控，没有Zabbix无法监控的内容，只要有监控的需求，都可以通过Zabbix的自定义监控项来实现，云原生还没有火起来的时候，Zabbix可以说监控领域最火爆的软件，随着云原生的火爆，使用Prometheus的人越来越多，Prometheus虽然提供了很多监控的exporter，但是监控项不能定制，exporter中有那些监控项，只能获得这些监控的指标，扩展性不强。

Zabbix监控唯一的不足就是监控K8S、容器这类无状态服务器比较复杂，但是也不用担心，在Zabbix6.x版本中已经推出了监控K8S集群的功能，再配合Grafana展示监控图形，可以说是非常完美的组合了。

Zabbix监控系统由5个组件构成：

• Zabbix Server：Zabbix的核心组件，包括了系统的所有配置信息、统计信息和操作信息，Zabbix Agent会定时采集监控指标上报给Server端。
• Zabbix Web：丰富的UI可视化页面，包含最近数据、历史数据、主机信息管理、报警管理等等丰富的展示界面。
• Zabbix Proxy：当监控的服务器数量众多时，可以启用Proxy代理，Zabbix Agent定时采集监控指标上报给Proxy，再由Proxy定期推送给Zabbix Server。
• 数据库：存储Zabbix监控系统的所有信息以及数据。
• Zabbix Agent：Zabbix的客户端，定期采集当前服务器中的监控指标，上报给Server端。

Zabbix常见的监控对象：硬件温度、系统监控、Java程序监控、网络设备监控、应用服务监控、数据库监控、URL监控等等。

ELKStack

无论是运维还是开发，都免不了查询服务日志的工作，当企业中有几十个甚至上百个服务服务节点时，查询日志就成了一项比较繁琐的工作，百十来个节点定位到出现错误日志的服务器也很麻烦，日志管理也较为复杂。

基于这种情况，建议使用ELKStack日志采集集群，ELK分为三个重要组件：

• ELasticsearch：是一个实时的分布式搜索引擎，它能让你以一个之前从未有过的速度和规模去搜索你的数据，它被用作全文检索、结构化搜索、分析以及这三个功能的组合，ELK采集来的日志也是存储到ES集群的，日志数据量本身也很大，使用ES作为存储源，可以极大的提高检索速度。
• Logstash：采集日志、格式化日志、过滤日志，对日志的内容进行一些处理，最后将日志数据存储到ELasticsearch集群中。
• Kibana：用于展示采集的日志，通过可视化界面查询不同应用系统的日志。

ELKStack的应用场景：

• 业务发展越来越庞大、服务器数量越来越多，各种访问日志、应用日志、错误日志的数量越来越多。
• 开发人员排查问题、需要到服务器上查日志、效率低。
• 运维需要实时关注业务的访问情况，通过Kibana可以绘制经典的统计图形。
• 应用程序迁移到K8S集群之后不做日志收集，那么容器重建后日志文件会丢失，通过ELK采集后相当于对日志持久化了。

ELK集群中的E和K都不用说了，其中的L也就是Logstash功能非常强大，也可以作为一个数据采集传输器，Logstash的插件非常丰富，无论是怎样复杂的数据源，都能通过Grok插件进行正则过滤，从而只收集需要的数据，Elasticsearch集群数据迁移也可以通过Logstash来完成。