7 款 DevOps 工具管理 Kubernetes

在本文中,您将了解可用于轻松管理 Kubernetes 集群的不同 Kubernetes 管理工具。

在新兴的云原生环境中,Kubernetes 无处不在。它已成为编排容器的标准。但是,管理多个 Kubernetes 集群(必须以一致且安全的方式在任何地方运行)提出了一系列新挑战。因此,对 Kubernetes 管理工具的需求就出现了。

让我们探索一些有效管理 Kubernetes 的流行解决方案。

1、K9s

k9s 是一个基于终端的资源仪表板。它只有一个命令行界面。无论您在 Kubernetes 仪表板 Web UI 上做什么,您也可以使用此终端 k9s 仪表板实用程序执行相同操作。

它持续关注 Kubernetes 集群,并提供命令来处理集群上定义的资源。

以下是 K9s 的功能:

  • 集群实时跟踪

  • 使用 K9s 皮肤自定义视图

  • 轻松遍历 Kubernetes 资源

  • 向下钻取选项以检查集群资源问题

  • 提供扩展插件来创建您自己的命令

2、Rancher

Rancher 是一个开源容器管理平台,可让任何企业轻松采用 Kubernetes。您可以部署和管理在 GKE (GCP)、EKS (AWS)、AKS (Azure) 中运行的云托管 Kubernetes 集群,也可以仅在您选择的 VM 或裸机基础设施上部署 Kubernetes。

Rancher 简化了管理员的所有操作职责,包括:

  • 监控集群的运行状况

  • 设置警报和通知

  • 启用集中日志记录

  • 定义和应用全局安全策略

  • 建立身份验证并执行我们的后台策略

  • 管理和扩展您的基础架构

随着 Kubernetes 在整个公司的采用加速,rancher 鼓励快速采用让用户直接访问 Kubernetes API 和 CLI。Rancher 的全新智能界面简化了应用管理;团队可以轻松部署和管理工作负载、定义 Secret 并管理私有注册表、配置持久卷声明、配置负载平衡和服务发现、管理 CI 管道。

3、Dashboard + Kubectl + Kubeadm

该 Kubernetes 仪表盘是一个基于 Web 的界面来部署集装箱式应用。它对您的应用程序进行故障排除并管理集群本身以及资源。

您可以使用仪表板概览集群上运行的应用程序,以及创建或修改单个 Kubernetes 资源,例如部署作业、副本集等。

您可以扩展部署,也可以启动滚动更新,甚至可以使用仪表板上的部署向导重新启动 Pod 或部署新应用程序。

Kubectl 是一个命令行工具,用于与 API 服务通信并向主节点发送命令。它对 Kubernetes 集群 API 服务器的 API 调用的隐蔽命令。

Kubeadm 是一个带有内置命令的工具,用于启动最小的 Kubernetes 集群。它用于引导集群而不是配置机器。使用 kubeadm,您可以运行一些基本命令来引导集群、创建令牌以加入集群、还原对 Kubernetes 集群所做的更改等。

4、Helm

Helm 是 Kubernetes 的包管理器。它允许开发人员和运营商在 Kubernetes 集群上打包、配置和部署应用程序和服务。它为操作员提供了对 Kubernetes 集群的更大控制,这些操作:

  • 使应用程序部署变得简单、标准化和可重用

  • 通过掌舵图轻松描述复杂的应用程序

  • 提高开发人员的生产力

  • 降低部署复杂性

  • 增强操作准备

  • 加快云原生应用的采用

  • 轻松回滚到以前的版本

Helm 使用包含所有资源定义的 Charts 在 Kubernetes 集群上运行应用程序或服务。您可以在此处找到可供使用的多个 Helm 图表。

5、KubeSpray

KubeSpray 是一个集群生命周期管理器,可帮助您部署生产就绪的 Kubernetes 集群。它使用 ansible-playbook 来自动化 Kubernetes 集群配置。

其中一些功能包括:

  • 基于 Ansible

  • 高可用

  • 跨平台

  • 生产水平

  • 流行的云提供商集成甚至裸机

  • 多种配置选项

  • 多平台 CI/CD

  • 默认安全

默认情况下,Kubespray 允许您通过 kube-master IP 地址和端口 6443 远程连接到 Kubernetes 集群。如果您需要灵活的部署,Kubespray 最适合;它提供了很多自定义配置选项。

另外,如果您熟悉 Ansible,那么 Kubespray 非常易于使用。

6、Kontena Lens

Kontena Lens 是 Kubernetes 的智能仪表板。

它是您控制 Kubernetes 所需的唯一管理系统。它可免费用于 Mac OS、Windows 和 Linux 操作系统。镜头应用程序启动后,您将在界面中看到所有关联集群的列表。

对于真正需要每天处理 Kubernetes 的人来说,它是最强大的 IDE。您可以确保正确设置和配置集群,并且可以更轻松、更快速地使用集群,从根本上提高生产力和业务发展速度。

Kontena Lens IDE 的特点是:

  • 可以一次管理多个集群

  • 实时可视化集群状态

  • 提供内置终端

  • 安装非常简单,因为它是一个独立的应用程序

  • 惊人的用户界面和用户体验

  • 支持 Kubernetes RBAC。

  • 经测试可处理集群中近 25K 的 Pod

Kubernetes 是一个复杂的工具,Lens IDE 甚至可以帮助初学者轻松上手 Kubernetes。它是管理和可视化 Kubernetes 集群的最佳工具之一。

7、WKSctl

WKSctl 代表 Weave Kubernetes 系统控制。它是 Weave Kubernetes 平台的一部分。

WKSctl 是一个使用 GitOps 进行 Kubernetes 配置管理的工具。GitOps 只不过是一组使用 git 请求以传统方式管理应用程序和基础设施的实践。

使用 WKSctl,您可以通过 Git 提交来管理 Kubernetes 集群。您可以升级集群或从集群中添加 / 删除节点。

您可以在两种模式下运行此工具:独立模式和 GitOps 模式。在独立模式下,它会创建一个静态集群。在 GitOps 模式下,它根据 git 上存在的 cluster.yml 和 machines.yml 信息配置集群。

WKSctl 特点:

  • 使用 git 快速启动集群

  • 部署失败时轻松回滚

  • 记录变更以供审查和审计

  • 创建集群只需要 IP 地址和 ssh 密钥

  • 不断验证和纠正集群状态

结论

所以这就是流行的 Kubernetes 管理工具 / 软件,可以轻松管理 Kubernetes 集群。选择上面提到的任何一种工具,并在您的 Kubernetes 集群上试用它!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
刚刚发布的ThoughtWorks技术雷达 建议技术团队“暂缓或谨慎”使用反模式“CI theatre(伪CI,可以理解为不完整的持续集成)”。 “伪CI”描述的是实践持续集成(CI)过程中的一些错觉,然而这些并不是真正的CI实践。 基于持续集成,我和同事 Emily Luke做了一些研究, 我将分享伪CI是什么样的,为什么我们建议你“暂缓或谨慎使用”,以及预防伪CI的方法。持续集成我最喜欢的CI定义来自于continuousdelivery.comCI开发人员定期(至少每天)将他们所有的工作集成到主干(也称为主线或主干分支)这个引用中暗含了CI实践的两个基本原则。第一个是“把他们所有的工作集成到主干”;第二个是“至少每天”。对于CI还有一系列其他原则和实践,例如:将所有内容都检入您的代码库,构建每个提交,自动化构建,保持快速构建,并有可以自我验证的代码, 还有Martin Fowler 关于持续集成的评论中的可视化故障并立即修复故障等。我个人认为 每天至少检入代码到主干分支一次 是CI的基础。没有达到这一点就只是伪CI而不是真正意义上的CI。伪CI是什么样的?这是我们调研到的一个故事,一位经验丰富的开发人员(让我们称他为David)来自湾区的一个中型创业公司,每周有两次产品交付。 David说他的组织正在践行CI,他说:“是的,我们用Circle CI”,他描述了一个具有挑战性的场景,曾经在一个分支上工作了一段时间,大约修改了100个文件和7000行代码,然后在代码审查阶段就开始招架不住了,因为他要向他的同事解释所有的代码变更的原因。“最具挑战性的事情是你最终要将一大堆功能集中到一个提交里,因为它们都是这个组件的一部分”,他解释说:“我希望有一个更好的方式来分解这些提交,因为很难把所有事情(变更历史)记在脑子里。”如果这个情况你听起来很熟悉,那么你也在做伪CI。 如果有下面的这些场景,那么你们就是在做伪CI:当有人问起你们在实践CI吗? 如果你说我们有一个CI服务器并且我们使用X工具在我们的调查中,只有10%的参与者承认有CI服务器与CI践行不一样。 相反,90%的个人表示他们正在践行CI,无论他们是否有专门从事CI的基础知识。 所以简单的认为只要有一个CI服务器就是“在做CI”,这就清楚地表明是在做“伪CI”。使用长期开发分支,但不会定期检入master主干在David的故事中,他们并没有实践每天检入master主干,这就是“伪CI”的标志。 这是我们在调研中常看到的一种模式,其中团队在master主干上运行CI,但不频繁构建,也不是每天都在提交。 或者他们在分支上运行CI,但不会频繁的集成到master主干。 只对特性分支运行CI,其实应该称之为持续隔离(continuous isolation)才对.合并分支时感到焦虑和疲惫真正的持续集成要把代码所有者的责任意识扩展到整个团队。 这改变了团队内部人员的观点以及他们对失败构建的态度。 不再是“我的宝贵的分支”,或是“我的错误导致构建被破坏”,而是“我们的代码”和“我们的失败”。David遇到焦虑和疲惫的事实清楚地表明,他忽略了CI的一个重要的优势:持续反馈和代码集体所有权。伪CI还有更多的一些现象,虽然我们发现有一些并不那么常见,但它们仍然存在一些问题,构建的时候,仅有极少的测试覆盖允许构建长时间处于失败状态虽然David的团队引入了一个备受尊崇的CI工具和常见的流程,如特征分支和代码审查,但他们并没有实施全套CI实践,因此错过了许多好处。 我们遗憾的发现,在我们的研究的组织中90%发生了这种情况。一些组织实施伪CI中反而错失了CI的主要优势 - 快速反馈,代码集体所有权,并准备达成持续交付如何避免,预防和解决伪CI的问题?如果您确定可能正在遭受伪CI之苦,则可以通过三种方式来解决问题并进行持续改变。1. 提交更频繁回到根本,尽量频繁地提交,每天至少提交一次应该是最低目标。 如果你还没有开始做CI,这就是你可以开始的地方,即使你在做CI,依然会有改进的空间。我喜欢“频率降低难度”的说法。 往往我们在做一些事情时,任务变得越小,则其更容易被实现。 持续集成就是是一个典型例子。 我的建议是要更加频繁地检入你的代码到代码库并且将开发分支集成到主干分支,至少每天集成一次”。2. 基于主干分支开发有很多论坛在讨论基于主干还是基于开发分支进行开发,我不想讨论那些血淋淋的细节。 然而,在我们的调研中,当我们与一些曾经在实践CI过程中感到痛苦的人交谈时,没有引入主干开发的团队对此有更深刻的感受。 DevOps现状调查报告-2016 还发现,基于主干开发和持续集成是达成持续交付的关键因素,同时也能建设更高效能的团队。基于主干的开发肯定会有一定的挑战,但它可以把问题提前暴露出来,而不是要等到代码合并、代码审查甚至到延迟发布的时候。如果你想达到更好效果的CI和CD,我建议在主干上做开发,或者如果你更愿意使用短周期的临时分支(合并到主干之前不到一天)进行开发,那么最好同时不要超过三个以上的活跃分支。3. 自动化自动化是做好持续集成的基石,所以如果你还没有自动化一切,现在是开始的好时机。 如果你认为已经实现了所有自动化的功能,那么每次有人手动地做任何事情超过一次,便要问自己“这个为什么不能自动化”? 我已经观察到自动化不仅可以帮助您在CI中变得更好,还可以帮助您开始持续交付。总结现在你知道什么是伪CI了,如果你的团队正在这么实践伪CI,那么你可以阻止这种情况继续发生了。 如果您仍然感到困惑,我建议你在Martin Fowler的博客“CI Certification test”做一个测试, 以确认你的组织是否正在做可靠的CI。 如果你通过了CI测试,那太好了,现在是考虑您是否准备好实施持续交付的时候了。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值