如何成为CI/CD理想型？论Kubernetes七大自我修养

除了改进传统的DevOps流程、以及通常被视为DevOps好处的速度、效率和弹性，Kubernetes还解决了基于容器和微服务的应用程序架构所带来的新问题。换句话说，Kubernetes强化了DevOps的目标，同时实现了微服务架构中出现的新工作流程。Kubernetes是一个功能强大的下一代开源平台，用于自动化跨主机集群的应用程序容器的部署、扩展和管理。它可以运行任何工作负载。Kubernetes提供卓越的开发人员用户体验（UX），创新速度惊人。

从一开始，Kubernetes的基础设施承诺将帮助企业快速部署应用程序，并轻松推出新功能，同时仅使用所需的资源。借助Kubernetes，企业可以在Google Cloud、AWS或本地环境中运行自己的Heroku。

开发团队常常需要运维部署的可见性。开发人员和运维团队一直对部署感到紧张，因为维护窗口有扩展的趋势，会导致停机。反过来，运维团队传统上保护着自己的“领土”，没有人能干涉他们。

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

正是以下7项功能，使Kubernetes成为DevOps工程师通过持续集成和持续交付（CI / CD）管道设置和管理容器化应用程序的理想平台。

1.强大的构建模块

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

单个pod中多个容器的使用通常遵循sidecar模式。在这种模式下，容器将运行在核心应用程序旁边，以提供一些附加价值。这通常用于代理请求，甚至处理身份验证。

有了这些强大的构建模块，把在容器化之前可能在虚拟机中运行的服务映射到同一个pod中运行的多个容器中变得非常简单。

2.简化的服务发现

在一个单体的应用程序中，不同的服务各有其用途，但自包含有利于通信。在微服务架构中，微服务需要彼此交谈。弄清楚这些服务如何简单而一致地进行通信并非易事。

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

3.中心化的、易于阅读的配置

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

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

4.实时信息

手动和脚本发布过去非常有压力。而凭借Kubernetes的内置部署能力，任何人都可以使用Kubernetes的无限部署历史记录部署和检查交付状态：kubectl发布历史。

这个Kubernetes API提供有关部署状态的实时信息。任何有权访问集群的开发人员都可以快速了解交付过程中所发生的事，或查看发布的所有命令。出于安全和历史目的，这个永久系统审计日志保存在某一个地方。你可以轻松了解以前的部署，查看部署之间的差异或回滚到任何列出的版本。

5.简单的健康检查能力

这对你的应用程序生命周期来说很重要，尤其是在部署阶段。过去，如果应用程序崩溃，它们通常不会自动重启。另一方面，Kubernetes具有自动运行状况检查功能，如果应用程序因任何原因（包括内存耗尽或锁定）无法响应，Kubernetes会自动重启它。

Kubernetes检查你的应用程序在不在运行，但不知道如何检查应用程序是否正确运行。但是，Kubernetes可以简化为应用程序设置健康检查的过程。你可以通过两种方式检查应用程序的运行状况：

使用liveness探针来检查应用程序是否从健康状态变为不健康状态。如果是这样，它会尝试重启应用程序。

用来检查应用程序是否准备好接受流量的readiness探针，在新容器健康之前，不会去除先前工作的容器。基本上，readiness探针是对破碎容器的最后一道防线。

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

另外，如果你有适当配置的readiness探针，回滚就很少见。如果所有运行状况检查都失败，一条单行的命令就可以回滚该部署，恢复到稳定状态。它不常用，但如果你需要的话，它就在那里。

6.滚动更新和本地回滚

为了进一步推进实时真实信息和健康检查功能，Kubernetes的另一个关键功能是使用上述本地回滚进行滚动更新。部署可以而且应该频繁，不用担心会遇到不可逆转的问题。

在Kubernetes之前，如果你想部署什么东西，一个普遍的部署模式涉及服务器拉入最新的应用程序代码并重启应用程序。这个过程是有风险的，因为一些功能不是向后兼容的——如果在部署过程中出现问题，该软件就不可用了。例如，如果服务器找到新的代码，它将引入这些更新并尝试用新代码重启应用程序。如果在该管道中发生故障，应用程序可能死掉。回滚过程并不简单。

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

在Kubernetes关闭现有的应用程序容器之前，它将启动新的应用程序容器。只有当新的正常运行时，才能去除旧的稳定版本。假设Kubernetes没有捕获到失败的部署——应用程序正在运行，但处于某种错误状态，而Kubernetes没有检测到。在这种情况下，DevOps工程师可以使用简单的Kubernetes命令撤消该部署。此外，你可以对其进行配置，以根据需要仅存储两次更改或存储尽可能多的修订，并且可以使用自动化的简单Kubernetes命令返回上次部署或以前的多次部署。

这整个概念改变了游戏规则。其他编排框架并不像Kubernetes一样可以以无缝和合乎逻辑的方式处理这个过程。

7.简化的监控

从表面上看，监控Kubernetes可能相当复杂，但在这个领域已经有了很多发展。尽管Kubernetes和容器为基础设施增加了一些复杂度，但它们确保所有应用程序都以一致的pod和部署运行。这种一致性使监控工具在许多方面变得更简单。

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

在监控Kubernetes时，有几个关键组件需要观察：Kubernetes Nodes（服务器）、Kubernetes系统部署（如DNS或网络），当然还有应用程序本身。有许多监控工具可以简化对这些组件的监控。

原创： Karen Lee译

原文链接：https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/