持续创造，加快生长！这是我参加「日新计划 10 月更文应战」的第13天，点击检查活动详情

中小企业最佳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来完结。