KUBERNETES：概述

Kubernetes是一个开源容器管理平台，旨在运行企业级，支持云和Web可扩展的IT工作负载。它建立在谷歌基于15年运行集装箱化应用程序的经验奠定的基础之上。

虽然它们的受欢迎程度是最近的趋势，但容器的概念已经存在了十多年。主流的基于Unix的操作系统（OS），例如Solaris，FreeBSD和Linux，都内置了对容器的支持，但是Docker通过使容器可管理并且可供开发和IT运营团队访问，使容器真正民主化。 Docker已经证明容器化可以提高应用程序的可伸缩性和可移植性。开发人员和IT运营部门正在转向使用各种语言编写的打包代码和依赖项的容器。容器在DevOps流程中也发挥着至关重要的作用。它们已成为构建自动化和持续集成以及持续部署（CI / CD）管道中不可或缺的一部分。

对容器的兴趣促成了开放容器倡议（OCI）的形成，以定义容器运行时和图像格式的标准。该行业还见证了各种容器的实现，例如Canonical的LXD，CoreOS的rkt，Microsoft的Windows Containers，CRI-O--通过Kubernetes Incubator进行审核，以及VMware的vSphere Integrated Containers。

虽然核心实现以各个容器的生命周期为中心，但生产应用程序通常处理具有跨多个主机运行的数十个容器的工作负载。 处理在生产环境中运行的多个主机和容器的复杂架构需要一组新的管理工具。 一些流行的解决方案包括Docker Datacenter，Kubernetes和Mesosphere DC / OS。

Container Orchestration通过为打包，部署，隔离，服务发现，扩展和滚动升级提供开放且高效的模型，影响了传统的平台即服务（PaaS）架构。 大多数主流PaaS解决方案都采用了容器，并且有新的PaaS实现构建在容器编排和管理平台之上。 客户可以选择部署更符合IT运营的核心容器编排工具，也可以选择面向开发人员的PaaS实施。

图1：容器编排引擎的高级体系结构。

关键的一点是，容器编排已经影响了现代软件开发和部署的各个方面。 Kubernetes将在推动企业和新兴创业公司采用容器方面发挥关键作用。

Kubernetes建筑

Kubernetes的这种体系结构为服务发现提供了灵活，松散耦合的机制。与大多数分布式计算平台一样，Kubernetes集群至少包含一个主计算节点和多个计算节点。主服务器负责公开应用程序接口（API），安排部署和管理整个集群。每个节点都运行一个容器运行时，例如Docker或rkt，以及与主服务器通信的代理程序。该节点还运行其他组件以进行日志记录，监视，服务发现和可选附加组件。节点是Kubernetes集群的主力。它们将计算，网络和存储资源暴露给应用程序。节点可以是在云中运行的虚拟机（VM），也可以是在数据中心内运行的裸机服务器。

图2：Kubernetes分解为多个架构组件。

pod是一个或多个容器的集合。 该吊舱是Kubernetes的核心管理单位。 Pod充当共享相同上下文和资源的容器的逻辑边界。 pod的分组机制通过使多个依赖进程一起运行，弥补了容器化和虚拟化之间的差异。 在运行时，可以通过创建副本集来扩展pod，这可确保部署始终运行所需数量的pod。

副本集通过始终维护预定义的一组pod来提供所需的规模和可用性。 单个pod或副本集可以通过服务向内部或外部消费者公开。 服务通过将一组pod与特定标准相关联来启用pod的发现。 Pod通过称为标签和选择器的键值对与服务相关联。 服务将自动发现任何带有与选择器匹配的标签的新pod。 该体系结构为服务发现提供了灵活，松散耦合的机制。

图3：主服务器负责公开API，安排部署和管理整个集群。

Kubernetes对象的定义（如pod，副本集和服务）将提交给master。 根据定义的要求和资源的可用性，主服务器在特定节点上调度pod。 节点从容器映像注册表中提取映像，并与本地容器运行时协调以启动容器。

etcd是CoreOS的一个开源的分布式键值数据库，它充当Kubernetes集群所有组件的单一事实源（SSOT）。 主查询etcd以检索节点，pod和容器状态的各种参数。

Kubernetes的这种体系结构通过在应用程序和底层基础架构之间创建抽象来使其模块化和可扩展。

图4：节点将计算，网络和存储资源暴露给应用程序。

关键设计原则

Kubernetes的设计基于可扩展性，可用性，安全性和可移植性原则。它通过在可用资源之间有效地分配工作负载来优化基础架构的成本。本节将重点介绍Kubernetes的一些关键属性。

工作负载可伸缩性

部署在Kubernetes中的应用程序被打包为微服务。这些微服务由分组为pod的多个容器组成。每个容器只能执行一项任务。 Pod可以由无状态容器或有状态容器组成。无状态容器可以根据需要或通过动态自动缩放轻松扩展。 Kubernetes 1.4支持水平pod自动缩放，可根据CPU利用率自动扩展复制控制器中的pod数量。未来版本将支持用于定义自动缩放规则和阈值的自定义指标。

在Google Cloud上运行的托管Kubernetes也支持群集自动扩展。当pod在所有可用节点上扩展时，Kubernetes与底层基础架构协调，以向集群添加其他节点。

在微服务上构建，打包为容器并部署为pod的应用程序可以利用Kubernetes的极端扩展功能。虽然这主要适用于无状态容器，但Kubernetes通过宠物集添加了对持久性工作负载的支持，例如NoSQL数据库和关系数据库管理系统（RDBMS）;这将启用扩展无状态应用程序，如Cassandra集群和MongoDB副本集。此功能将弹性，无状态Web层和持久的有状态数据库组合在一起，以在同一基础架构上运行。

高可用性

当前工作负载需要基础架构和应用程序级别的可用性。在大规模集群中，一切都容易出现故障，这使得生产工作负载的高可用性非常必要。虽然大多数容器编排引擎和PaaS产品可提供应用程序可用性，但Kubernetes旨在解决基础架构和应用程序的可用性问题。

在应用程序方面，Kubernetes通过副本集，复制控制器和宠物集确保高可用性。操作员可以声明在任何给定时间点需要运行的最小pod数。如果容器或pod由于错误而崩溃，则声明性策略可以将部署恢复到所需的配置。可以通过宠物集配置状态工作负载以实现高可用性。

对于基础架构可用性，Kubernetes支持广泛的存储后端，来自分布式文件系统，如网络文件系统（NFS）和GlusterFS，块存储设备，如Amazon Elastic Block Store（EBS）和Google Compute Engine持久磁盘，和专业的容器存储插件，如Flocker。为Kubernetes添加可靠的可用存储层可确保有状态工作负载的高可用性。

Kubernetes集群的每个组件 -  etcd，API服务器，节点 - 都可以配置为高可用性。应用程序可以利用负载平衡器和运行状况检查来确保可用性。

安全

Kubernetes中的安全性配置在多个级别。 API端点通过传输层安全性（TLS）进行保护，确保用户使用最安全的机制进行身份验证。 Kubernetes集群有两类用户 - 由Kubernetes直接管理的服务帐户，以及假定由独立服务管理的普通用户。由Kubernetes API管理的服务帐户由API服务器自动创建。管理集群内运行的进程的每个操作都必须由经过身份验证的用户启动;此机制可确保群集的安全性。

部署在Kubernetes集群中的应用程序可以利用秘密的概念来安全地访问数据。秘密是Kubernetes对象，其中包含少量敏感数据，如密码，令牌或密钥，可降低意外泄露数据的风险。在将它们存储在Kubernetes集群中之前，用户名和密码在base64中编码。 Pod可以在运行时通过已安装的卷或环境变量访问密钥。需要注意的是，该秘密可供同一群集名称空间的所有用户使用。

要允许或限制网络流量到pod，可以将网络策略应用于部署。 Kubernetes中的网络策略是关于如何允许选择pod与彼此以及与其他网络端点通信的规范。这对于在多层部署中隐藏不应暴露给其他应用程序的pod很有用。

可移植性

Kubernetes旨在为选择操作系统，容器运行时，处理器架构，云平台和PaaS提供自由选择。

可以在主流Linux发行版上配置Kubernetes集群，包括CentOS，CoreOS，Debian，Fedora，Red Hat Linux和Ubuntu。它可以部署在本地开发机器上运行; AWS，Azure和Google Cloud等云平台;基于KVM，vSphere和libvirt的虚拟化环境;和裸露的金属。用户可以启动在Docker或rkt运行时上运行的容器，并且将来可以容纳新的容器运行时。

通过联合，还可以混合和匹配跨多个云提供商和本地运行的集群。这将混合云功能带入了容器化工作负载。客户可以将工作负载从一个部署目标无缝移动到另一个部署目标。我们将在下一节讨论混合架构。

原文：https://thenewstack.io/kubernetes-an-overview/

本文：https://pub.intelligentx.net/kubernetes-overview

讨论：请加入知识星球或者小红圈【首席架构师圈】