使Kubernetes成为更理想的CI/CD工具的7个特性


【编者的话】Kubernetes发力于持续交付以及运维友好,DevOps工程师在设计CI的Pipeline过程可以更多专注于Kubernetes与外部的CI工具集成。

Kubernetes除了改进传统的DevOps流程之外,还有速度、效率和弹性这些通常被视为DevOps的优势——Kubernetes解决了基于容器和基于微服务的应用程序体系结构带来的新问题。换句话说,Kubernetes强化了DevOps目标,同时还实现了微服务架构带来的新工作流程。

Kubernetes是一个功能强大的下一代开源平台,用于自动化跨主机群集的应用程序容器的部署、扩展和管理。它可以运行任何工作负载。Kubernetes提供优越的开发人员用户体验(UX),创新速度惊人。从一开始,Kubernetes的基础设施承诺将帮助企业快速部署应用程序,并轻松推出新功能,同时仅使用所需的资源。借助Kubernetes,企业可以在自己的Google Cloud、AWS或本地环境中运行自己的Heroku(PaaS)。

在过去的几年中,考虑到开发团队经常希望对操作部署有更高的可见性。开发和运营团队一直对部署感到紧张,因为维护窗口一旦有扩展的趋势将导致服务不可用。反过来,运营团队一直保护着他们的领土,所以没有人会干涉他们去完成工作。

然后容器化和Kubernetes出现了,软件工程师想了解它并使用它。它是革命性的,不同于传统的运营模式。它是软件驱动的,非常适合工具化和自动化。Kubernetes使工程师能够专注于任务驱动去编码,而不是提供桌面支持。与此同时,它将工程师带入运营领域,为开发和运营团队提供了一个清晰了解彼此世界的窗口。

以下是使Kubernetes成为DevOps工程师通过持续集成和持续交付(CI/CD)管道设置和管理容器化应用程序的理想平台的七大特点。

强大的构建模块

Kubernetes使用Pod作为部署的基本单位。Pod代表一组使用相同存储和网络的一个或多个容器。虽然Pod通常只用于运行一个容器,但它们已经被一些创造性的方式所使用,包括作为构建服务网格的手段。

单个Pod中运行多个容器的通用用法是遵循Sidecar模式。使用这种模式,Sidecar容器将与核心应用程序运行在一起以提供一些附加功能。这通常用于代理请求,甚至处理身份验证。

有了这些强大的构建模块,使得映射在容器化前可能在虚拟机中运行的服务到同一个Pod中运行的多个容器中变得非常简单。
e0338760-kubernetes-cicd.png

使用Kubernetes,Pod分布在内置负载平衡和路由的不同服务器上,以这种方式分发应用程序工作负载可以显著提高资源利用率。

简化的服务发现

在一个单一的应用程序中,不同的服务各有其使命,但自包含有利于沟通。在微服务体系结构中,微服务需要彼此通信 - 您的用户服务需要与您的邮递服务和地址服务进行通信等。弄清楚这些服务如何简单而一致地进行通信并非易事。

借助Kubernetes,DevOps工程师定义了一项服务——例如用户服务。在同一个Kubernetes命名空间中运行的任何东西都可以向该服务发送请求,而Kubernetes会指出如何为您提供请求路由,使得微服务更容易管理。

集中、易读的配置

Kubernetes使用声明性模型:您描述了一个期望的状态,Kubernetes将尝试实现该状态。Kubernetes使用易于阅读的YAML文件描述您想要实现的状态。通过Kubernetes YAML配置,您可以定义从应用程序负载均衡器到一组运行您的应用程序的Pod的任何内容。部署配置可能有一个应用程序的Docker容器和两个不同的环境变量的三个副本。这种易于阅读的配置可能存储在Git存储库中,以便您可以随时看到配置更改。在使用Kubernetes之前,很难知道跨服务器的互连系统实际发生了什么。

除了配置群集中运行的应用程序容器或可用于访问它们的端点之外,Kubernetes还可以帮助进行配置管理。Kubernetes有一个名为ConfigMap的概念,您可以在其中定义应用程序的环境变量和配置文件。同样,名为Secrets的对象包含敏感信息,并帮助定义应用程序的运行方式。Secrets的工作方式与ConfigMaps非常相似,但对最终用户来说更隐秘且不太明显可见。第2章详细探讨了这一切。

实时的真实数据来源

手动和脚本化发布曾经非常有压力,现在你有一个机会改善它。凭借Kubernetes的内置部署能力,任何人都可以使用Kubernetes的无限部署历史记录来部署和检查交付状态:kubectl rollout history

Kubernetes API提供有关部署状态的实时真实数据来源。任何有权访问群集的开发人员都可以快速了解交付过程中发生的情况,或查看发布的所有命令。出于安全性和历史目的,此永久系统审核日志保存在一个位置。您可以轻松了解以前的部署,查看部署之间的差异或回滚到任何列出的版本。

简单的健康检查能力

这在您的应用程序的生命周期中是一个巨大的优势,特别是在部署阶段。过去,如果应用程序崩溃,应用程序通常不会自动重启;相反,有人会在深夜被传呼不得不重新启动它们。另一方面,Kubernetes具有自动运行状况检查功能,如果应用程序因任何原因(包括内存耗尽或锁定)无法响应,Kubernetes会自动重新启动它。

阐明一下,Kubernetes检查你的应用程序正在运行,但它不知道如何检查它是否正确运行。尽管如此,Kubernetes使您可以轻松地为您的应用程序设置运行状况检查。您可以通过两种方式检查应用程序的运行状况:
  • liveness,使用liveness探测来检查应用程序是否从健康状态变为不健康状态。如果它进行了转换,它会尝试重新启动您的应用程序。
  • readiness,使用readiness探测检查应用程序是否已准备好接受流量,在新容器运行正常之前,将不会删除以前正在运行的容器。基本上,readiness探测是防止未就绪的容器接受流量的最后一道防线。


两种探针都是有用的工具,Kubernetes使它们易于配置。

此外,如果就绪(readiness)探针配置得当的话,很少会需要回滚。如果所有运行状况检查都失败,一条单行命令将能回滚该部署并恢复到稳定状态。虽然不常用,但在你需要的话就很实用。

滚动更新和回滚

为了进一步构建实时的真实来源和健康检查功能,Kubernetes的另一个关键功能是使用上述的回滚进行滚动更新。部署可以而且应该经常进行,不必担心会没有回头路。在Kubernetes之前,如果你想部署一些东西,一个通用的部署模式涉及在服务器拉取最新的应用程序代码并重新启动应用程序。该过程存在风险,因为某些功能不向后兼容——如果在部署期间出现问题,则软件变得不可用。例如,服务器发现新代码,它将引入这些更新并尝试使用新代码重新启动应用程序。如果该过程中出现故障,应用程序很大可能已经挂掉。回滚过程不会很简单明了。

直到使用Kubernetes前,这些工作流程一直都是问题。Kubernetes通过部署回滚功能解决了这个问题,消除了大量的维护时间和对停机时间的担忧。自Kubernetes 1.2以来,部署对象是一个声明性清单,其中包含正在交付的所有内容,包括部署的副本数量和软件镜像的版本。这些项目被抽象化并包含在部署声明中。这种基于清单的部署加速了新的CD工作流程,并且是Kubernetes不断发展的最佳实践。

在Kubernetes关闭现有的应用程序容器之前,它将启动新的应用程序容器。只有当新版本正常运行时,才能替换旧的稳定版本。假设Kubernetes没有捕获失败的部署——即应用程序正在运行,但它处于某种Kubernetes未检测到错误状态。在这种情况下,DevOps工程师可以使用简单的Kubernetes命令撤消该部署。此外,您可以对其进行配置,以根据需要存储少至两次更改或多次变更,并且可以使用自动化的简单Kubernetes命令返回上次部署或此前的多次部署。这整个概念使之成为大杀器,因为其他编排框架并不像Kubernetes那样可以以无缝和合乎逻辑的方式处理这个过程。

简化监控

虽然从表面上看,似乎监控Kubernetes会非常复杂,但在这个领域其实已经有了很多发展。尽管Kubernetes和容器为您的基础架构增加了一些复杂程度,但它们也确保您的所有应用程序都以一致的Pod和部署运行。这种一致性使监控工具在许多方面更简单。

Prometheus是一个开源监控工具的例子,在云原生生态系统中变得非常流行。该工具提供先进的监控和告警功能,以及出色的Kubernetes集成。

在监控Kubernetes时,需要注意几个关键组件:Kubernetes节点(服务器);Kubernetes系统部署,例如DNS或网络;当然还有你的应用程序本身。有许多监控工具可以简化对这些组件的监控。

参见:DevOps, Microservices, Kubernetes: A Cloud-Native Approach

原文链接:7 FEATURES THAT MAKE KUBERNETES IDEAL FOR CI/CD(翻译:fengxsong)

=================================
译者介绍

fengxsong,运维工程师,Golang语言爱好者,关注Kubernetes/Serverless/CI/CD,希望通过DockOne把最新的译文贡献给大家,与读者一起共同学习交流云原生解决方案。

0 个评论

要回复文章请先登录注册