介绍
Kubernetes是一个由Google开发的功能强大的系统，用于在集群环境中管理容器化应用程序。 它旨在提供更好的方法来管理跨各种基础设施的相关的，分布式组件。
在本指南中，我们将讨论Kubernetes的一些基本概念。 我们将讨论系统的架构，解决的问题，以及用于处理容器化部署和扩展的模型。
先决条件
本文假设一些关于现代集群技术的先验知识。 我们将讨论它如何与像CoreOS这样的系统相关。
如果你不熟悉CoreOS，它可能有助于检查有关CoreOS系统的一些基本信息 ，以了解该类型Kubernetes，就是要部署环境。
什么是Kubernetes？
Kubernetes，在其基本水平，是用于在节点的群集管理容器的应用的系统。 在许多方面，Kubernetes旨在解决现代集群基础设施的设计方式与大多数应用程序和服务对其环境的一些假设之间的断开。
大多数集群技术致力于为应用部署提供统一的平台。 用户不必非常关心工作安排在哪里。 呈现给用户的工作单元处于“服务”级别，并且可以由任何成员节点来完成。
然而，在许多情况下，它确实物质的下层基础结构是什么样的。 当缩放应用程序时，管理员关心的是服务的各种实例不是都被分配给同一主机。
在另一方面，许多分布式应用程序构建与扩展实际上是由较小的组件服务组成。 这些服务必须在与相关组件相同的主机上进行调度，如果它们将以微不足道的方式配置。 当它们依靠特定的网络条件以便适当地通信时，这变得更加重要。
虽然大多数集群软件可能做出这些类型的调度决定，但在单个服务级别上操作是不理想的。 在大多数情况下，由不同服务组成的应用程序仍应作为单个应用程序管理。 Kubernetes在基础设施上提供了一个层，以允许这种类型的管理。
主组件
像CoreOS这样的基础设施级系统致力于创建一个统一的环境，每个主机都是一次性的，可互换的。 另一方面，Kubernetes在一定程度上主机专业化。
在Kubernetes集群的控制服务被称为主 ，或控制平面 ，组件。 它们作为管理员的主要管理联络点，并且为相对哑的工作节点提供许多群集范围的系统。 这些服务可以安装在单个机器上，也可以分布在多个机器上。
运行这些组件的服务器具有许多独特的服务，用于管理集群的工作负载和跨系统的直接通信。 下面，我们将介绍这些组件。
Etcd
Kubernetes需要运行的一个基本组件是全局可用的配置存储。 该etcd项目，由CoreOS团队开发，是一个轻量级的分布式key-value存储，可以跨多个节点分布。
Kubernetes使用etcd存储可以由每个集群中的节点一起使用的配置数据。 这可以用于服务发现，并且表示每个组件可以引用以配置或重新配置自身的集群的状态。 通过提供简单的HTTP / JSON API，用于设置或检索值的界面非常简单。
像在控制面中最其它部件， etcd可以单个主服务器上配置，或在生产方案，而其中的机器分布。 唯一的要求是它是网络可访问每个Kubernetes机器。
API服务器
最重要的主服务之一是API服务器。 这是整个集群的主要管理点，因为它允许用户配置Kubernetes的许多工作负载和组织单位。 它还负责确保该etcd存储和部署容器的服务细节是一致的。 它充当各个组件之间的桥梁，以保持集群健康和传播信息和命令。
API服务器实现了RESTful接口，这意味着许多不同的工具和库可以方便地与之通信。 称为客户端kubecfg与服务器端工具打包沿着并可以从本地计算机用于与Kubernetes簇相互作用。
控制器管理器服务
控制器管理器服务是具有许多职责的一般服务。 它负责调节集群状态并执行常规任务的许多控制器。 例如，复制控制器确保为服务定义的副本数量与当前在集群上部署的数量匹配。 这些操作的细节将写入etcd ，其中控制器经理手表通过API服务器的更改。
当看到变化时，控制器读取新信息并实现满足期望状态的过程。 这可能涉及向上或向下缩放应用程序，调整端点等。
调度服务
实际将工作负载分配给集群中特定节点的过程是调度程序。 这用于读取服务的操作要求，分析当前基础架构环境，并将工作放在可接受的节点上。
调度程序负责跟踪每个主机上的资源利用率，以确保工作负载不会超过可用资源。 调度程序必须知道每个服务器上可用的总资源，以及分配给在每个服务器上分配的现有工作负载的资源。
节点服务器组件
在Kubernetes，执行工作的服务器被称为节点 。 节点服务器具有与主组件通信，配置容器的网络以及运行分配给它们的实际工作负载所需的一些要求。
在专用子网上运行的Docker
每个节点服务器的第一个要求是docker 。 该docker服务用于在相对隔离的，但轻量级操作系统环境中运行的应用程序封装容器。 每个工作单元在其基本水平上被实施为必须部署的系列容器。
Kubernetes做出的一个关键假设是，每个节点服务器都有一个专用子网。 许多标准集群部署不是这种情况。 例如，对于CoreOS，称为一个单独的网络织物flannel需要用于此目的。 Docker必须配置为使用它，以便它能以正确的方式暴露端口。
Kubelet服务
与群集组的每个节点的主要接触点是通过一个叫做小的服务kubelet 。 这项服务是负责传递信息，并从控制平面的服务，以及与相互作用etcd店读取配置信息或写入新值。
该kubelet服务与主组件通信接收命令和工作。 以“清单”的形式接收工作，其定义工作负载和操作参数。 该kubelet然后过程假定维持节点服务器上的工作状态负责。
代理服务
为了处理单个主机子网并且为了使服务可用于外部方，在每个节点服务器上运行小代理服务。 此过程将请求转发到正确的容器，可以执行原始负载平衡，并且通常负责确保网络环境是可预测和可访问的，但是是孤立的。
Kubernetes工作单位
虽然容器用于部署应用程序，但是定义每种类型工作的工作负载是特定于Kubernetes的。 我们将讨论下面可以分配的不同类型的“工作”。
荚
荚是Kubernetes涉及的基本单位。 容器本身未分配给主机。 相反，紧密相关的容器被分组在一个pod中。 容器通常表示应当被控制为单个“应用”的一个或多个容器。
这个关联导致所有涉及的容器被调度在同一主机上。 他们作为一个单位管理，他们共享一个环境。 这意味着它们可以共享卷和IP空间，并且可以作为单个应用程序部署和扩展。 您可以并且应该将pod视为单个虚拟计算机，以便最好地概念化资源和调度应如何工作。
荚的一般设计通常包括满足荚的通用目的的主容器，以及可选地有助于相关任务的一些帮助容器。 这些是受益于在自己的容器中运行和管理的程序，但是与主应用程序密切相关。
水平缩放通常不鼓励在pod级别，因为还有其他单位更适合该任务。
服务
在本指南中，我们一直使用“服务”这一术语，但是Kubernetes在描述工作单位时实际上对这个词有一个非常具体的定义。 服务 ，当这样描述的，是作为一个基本的负载均衡和大使等容器的单位。 服务将执行相同功能的pod的逻辑集合组合在一起，以将其表示为单个实体。
这允许您部署知道所有后端容器以传递流量的服务单元。 外部应用程序只需要担心单个访问点，而是受益于可扩展后端或至少一个可以在必要时进行交换的后端。 服务的IP地址保持稳定，从而提取对节点IP地址的任何更改，这些更改可以作为节点死亡或重新安排节点。
服务是一组容器的接口，使得消费者不必担心超出单个访问位置的任何事情。 通过部署服务，您很容易获得发现能力，并可以简化您的容器设计。
复制控制器
一个吊舱的一个更复杂的版本是一个复制的吊舱 。 这些由一个类型被称为复制控制器的工作单元的处理。
复制控制器是用于定义意在水平缩放的pod的框架。 工作单元实质上是嵌套单元。 提供了一个模板，它基本上是一个完整的pod定义。 这包含有关应该执行的复制工作的其他详细信息。
复制控制器负责维护所需数量的副本。 这意味着如果容器临时停机，复制控制器可能会启动另一个容器。 如果第一个容器恢复联机，控制器将关闭其中一个容器。
标签
在工作单位之外的Kubernetes组织概念是标签。 一个标签基本上是可以放在上面的工作单位将其标记为一组的一部分的任意标记。 然后可以选择这些选项用于管理目的和操作目标。
标签是服务和复制控制器如何工作的基础。 要获取服务应传递流量的后端服务器列表，它通常会根据标签选择容器。
同样，复制控制器给所有从它们的模板生成的容器使用相同的标签。 这使得控制器很容易监视每个实例。 控制器或管理员可以将所有实例作为一个组来管理，而不管已经生成了多少个容器。
标签作为键值对提供。 每个单元可以有多个标签，但每个单元每个键只能有一个条目。 您可以坚持使用“名称”键作为通用标识符，或者您可以通过各种标准（如开发阶段，公共辅助功能，应用程序版本等）对其进行分类。
在许多情况下，您需要为细粒度控制分配许多标签。 然后，您可以基于单个或组合标签要求进行选择。
结论
Kubernetes是一个令人兴奋的项目，在集群基础设施上实施许多功能改进。 虽然其他技术在处理集群方面做得很好，Kubernetes的目标是提供更好的管理系统。
在我们的下一个指南中，我们将讨论如何让Kubernetes启动和运行一个CoreOS集群上 。
