【编者的话】 本文介绍了Kubernetes中的主要组件和各个组件的工作模式。
什么是Kuberbetes？这个异常火爆的容器编排引擎的内在到底是些什么？它们如何一同为处理生产环境中的容器化应用提供一个面向未来的、可靠的、可伸缩的潜在方案？（请注意这里故意使用了“潜在”这一词，稍后我们会解释为什么要用这个词）。
本文中，我们将讨论Kubernetes是如何工作的，以及它为什么具有支持企业级软件/容器管理的可能性（又有了这个词）。
Kubernetes不仅有你所需要的用来支持复杂容器应用的所有东西，它还是市面上最方便开发和运维的框架。
Kubernetes的工作原理是通过将容器分组来把一个应用程序拆分成多个逻辑单元，以方便管理和发现。它对由小且独立的服务组成的微服务应用特别有用。
尽管Kubernetes运行在Linux上，他其实是平台无关的，可以在裸机、虚拟机、云实例或OpenStack上运行。
工作节点包含了一个kubelet。它是主节点代理（primary node agent）。它会监控已被分配给该节点的pods中的API服务器。Kuberet执行任务并维护一个将pod状态报告给主节点的渠道。
每个pod里都有容器，kubelet通过Docker（拉取镜像、启动和停止容器等）来运行这些容器。它还会定期执行被请求的容器的健康探测程序。除了Docker之外，Kubernetes也支持RKT，此外社区也正在积极努力的支持OCI。
工作节点里的另一个组件是kube-proxy。它负责节点的网络，在主机上维护网络规则并执行连接转发。它还负责对正在服务的pods进行负载平衡。
Pods也是做弹性伸缩时的基本单位。如果你需要对一个应用的组件做伸缩，可以通过添加和移除pod来实现。
如果容器间紧密的耦合，就可以在一个pod里运行多个容器（每个容器都共享同样的IP和挂载的卷）。
Pods被部署在单独的节点上，并有一个给定的生命周期。他们可能处于pending、running、succeeding或failing的状态，但是pod一旦销毁，就永远不会被复原。如果一个pod被销毁，你只能通过副本控制器或其他控制器来创建一个新的pod。
就像所有好用的自动化工具一样，Kubernetes使用了对象说明或蓝图来管理系统该如何运行。你只需告诉Kubernetes你想要发生些什么事，其他的事情它自己就会处理。就好比是雇佣一个承包商来翻修你的厨房。你并不需要知道他们具体在做什么。您只需指定好结果，批准施工蓝图就可以让他们去处理剩下的部分。Kubernetes也以同样的方式工作。Kubernetes的操作基于声明式模型，在清单文件（manifest file）中定义的对象说明表明了集群该怎么运行。用不到使用一堆的命令，Kubernetes会做所需要的事情来完成给定的目标。
这是一场革命。正如云技术革新了基础设施的管理一样，kubernetes和其他编排系统正如风暴般席卷了应用开发领域。如今，DevOps团队有这个潜力(再次出现这个词)来轻松地部署、管理和操作应用程序。你只需通过主节点上的控制器的API接口将您的蓝图发送到Kubernetes即可。
一些已有模块能帮助你定义蓝图，其中比较重要的如下所示：
主节点上运行了多个Kubernetes的组件。这些组件一同决定了容器分配以及配置的控制策略。
此外，主节点和代理也可以与云服务提供商交互，并管理额外的云资源，如负载平衡器、持久卷、持久块存储、网络配置和实例。主节点也可以是运行了Kubernetes组件的单个实例，或是一组实例来确保高可用性。主节点还可以作为一个工作节点来运行容器（在某些配置中），尽管这种配置不推荐用于生产。
尽管深受人们喜爱，但管理Kubernetes还是一个耗时的过程，需要技能熟练的员工和高额的资金投入。为了应对这些挑战，每天都有Kubernetes的管理工具涌现，但是找到正确的，并能适应不断变化的IT环境的工具还是一个难题。
【作者语】 说到容器管理工具，Kubernetes当属第一梯队。本文助你熟悉Kubernetes的部件以及它们之间如何协同工作。
入门导论：Kubernetes组件和组件之间如何协同工作
本文讲的是揭开面纱：Kubernetes架构详解如果你正在实现容器的落地，你需要一个容器管理平台。假如你正在阅读本文，那你很有可能已经考虑了Kubernetes的优势。什么是Kuberbetes？这个异常火爆的容器编排引擎的内在到底是些什么？它们如何一同为处理生产环境中的容器化应用提供一个面向未来的、可靠的、可伸缩的潜在方案？（请注意这里故意使用了“潜在”这一词，稍后我们会解释为什么要用这个词）。
本文中，我们将讨论Kubernetes是如何工作的，以及它为什么具有支持企业级软件/容器管理的可能性（又有了这个词）。
Kubernetes是什么？
Kubernetes（通常简称为K8S），是一个用于管理在容器中运行的应用的容器编排工具。Kubernetes不仅有你所需要的用来支持复杂容器应用的所有东西，它还是市面上最方便开发和运维的框架。
Kubernetes的工作原理是通过将容器分组来把一个应用程序拆分成多个逻辑单元，以方便管理和发现。它对由小且独立的服务组成的微服务应用特别有用。
尽管Kubernetes运行在Linux上，他其实是平台无关的，可以在裸机、虚拟机、云实例或OpenStack上运行。
面纱之下是什么？
为了理解Kubernetes的工作原理，让我们先来剖析下Kubernetes的结构。Kubernetes 的主节点（Master Node）
让我们先来谈谈 主节点（Master） 。这是Kubernetes的控制面板或控制平面。这里是制定有关集群的决策的地方，例如调度，以及对集群事件的探测/响应。主节点的组件可以在集群中的任何节点上运行。下面是主节点的关键组件的分解：- API服务器（API Server）：这是Kubernetes控制面板中唯一带有用户可访问API以及用户可交互的组件。API服务器会暴露一个restful的Kubernetes API并使用JSON格式的清单文件（manifest files）。
- 集群的数据存储（Cluster Data Store）：Kubernetes使用“etcd”。这是一个强大的、稳定的、高可用的键值存储，被Kubernetes用于长久储存所有的API对象。可以认为它就是集群的“真相之源”。
- 控制管理器（Controller Manager）：被称为“kube-controller
manager”，它运行着所有处理集群日常任务的控制器。包括了节点控制器、副本控制器、端点（endpoint）控制器以及服务账户和令牌控制器。每一个控制器都独立工作以维护其所需的状态。 - 调度器（Scheduler）：调度器会监控新建的pods（一组或一个容器）并将其分配给节点。
- 仪表板（Dashboard）（可选）：Kubernetes提供网页UI来简化用户与API服务器（API Server）的交互。
Kubernetes的工作节点（Worker Node）
Kubernetes中第二重要的部分就是 工作节点 。鉴于主节点负责管理集群，工作节点就负责运行容器，并提供Kubernetes的运行环境。工作节点包含了一个kubelet。它是主节点代理（primary node agent）。它会监控已被分配给该节点的pods中的API服务器。Kuberet执行任务并维护一个将pod状态报告给主节点的渠道。
每个pod里都有容器，kubelet通过Docker（拉取镜像、启动和停止容器等）来运行这些容器。它还会定期执行被请求的容器的健康探测程序。除了Docker之外，Kubernetes也支持RKT，此外社区也正在积极努力的支持OCI。
工作节点里的另一个组件是kube-proxy。它负责节点的网络，在主机上维护网络规则并执行连接转发。它还负责对正在服务的pods进行负载平衡。
Kubernetes的Pods
正如前文所说，一个pod就是一个或一组共享网络/存储的容器（比如Docker容器）。每个pod包含有关如何运行容器的信息。可以将pods看作是一个用于运行容器的闭包环境。Pods也是做弹性伸缩时的基本单位。如果你需要对一个应用的组件做伸缩，可以通过添加和移除pod来实现。
如果容器间紧密的耦合，就可以在一个pod里运行多个容器（每个容器都共享同样的IP和挂载的卷）。
Pods被部署在单独的节点上，并有一个给定的生命周期。他们可能处于pending、running、succeeding或failing的状态，但是pod一旦销毁，就永远不会被复原。如果一个pod被销毁，你只能通过副本控制器或其他控制器来创建一个新的pod。
各组件之间如何协同工作?
现在你已经了解了Kubernetes的面纱下面有些什么，再看看它们是如何对容器化应用的部署、扩展和操作实现自动化。就像所有好用的自动化工具一样，Kubernetes使用了对象说明或蓝图来管理系统该如何运行。你只需告诉Kubernetes你想要发生些什么事，其他的事情它自己就会处理。就好比是雇佣一个承包商来翻修你的厨房。你并不需要知道他们具体在做什么。您只需指定好结果，批准施工蓝图就可以让他们去处理剩下的部分。Kubernetes也以同样的方式工作。Kubernetes的操作基于声明式模型，在清单文件（manifest file）中定义的对象说明表明了集群该怎么运行。用不到使用一堆的命令，Kubernetes会做所需要的事情来完成给定的目标。
构造你的蓝图
Kubernetes的蓝图由多个模块组成。用这些模块就可以组合出你的蓝图，然后交由Kubernetes去按图施工。模块里包含了该如何设置容器的说明，你也可以修改已运行的Apps的说明， Kubernetes会调整你的系统以符合给出的要求。这是一场革命。正如云技术革新了基础设施的管理一样，kubernetes和其他编排系统正如风暴般席卷了应用开发领域。如今，DevOps团队有这个潜力(再次出现这个词)来轻松地部署、管理和操作应用程序。你只需通过主节点上的控制器的API接口将您的蓝图发送到Kubernetes即可。
一些已有模块能帮助你定义蓝图，其中比较重要的如下所示：
- Pods– 用于描述一组需要运行在一起的容器
- 服务（Service）– 描述了一组提供了有效服务的pods. 服务通常都被用来定义pods的集群。
- 持久卷（Persistent Volumes）– Kubernetes对持久存储的抽象定义。Kubernetes支持许多类型的卷，比如NFS、Ceph、GlusterFS、本地目录等等。
- 命名空间（Namespaces）– 这是一个用来分组、分离和隔离对象的工具。名称空间用于访问控制、网络访问控制、资源管理和引用。
- 入口规则（Ingress rules）– 制定了如何将进入的网络流量路由到服务和pods上。
- 网络规则（Network policies）– 定义了集群中pods之间的网络访问规则。
- 配置和密钥（ConfigMaps and secrets）– 用于把配置信息从应用程序中分离出来。
- 操作器（Controllers）– 实现了不同的自动化管理pods的策略。可分为三种类型：
1.部署（Deployment）– 负责维护并运行一组相同类型的pods。
2.守护进程设置（DaemonSet）– 根据条件在每个节点上运行特定类型的pod。
3.状态设置（StatefulSet）– 当同类型的多个pods需要并行运行时，而且每个pod都需要有一个特定的身份时，可以使用该操作器。
Kubernetes自身是如何防止攻击的
Kubernetes可以同时在虚拟机或物理机上运行和控制一组节点，并通过在每个节点上运行代理来实现这第一点。该代理通过用于将蓝图发送给Kubernetes的API来与主节点通信。代理被注册在主节点上，并为Kubernetes提供关于节点的信息。通过API，代理确定哪些容器需要在相应的节点上运行以及如何配置它们。主节点上运行了多个Kubernetes的组件。这些组件一同决定了容器分配以及配置的控制策略。
此外，主节点和代理也可以与云服务提供商交互，并管理额外的云资源，如负载平衡器、持久卷、持久块存储、网络配置和实例。主节点也可以是运行了Kubernetes组件的单个实例，或是一组实例来确保高可用性。主节点还可以作为一个工作节点来运行容器（在某些配置中），尽管这种配置不推荐用于生产。
意识到Kubernetes真正带来的潜力
作为容器管理工具的领头羊，Kubernetes拥有为企业级生产化容器应用提供坚实的基础架构和伸缩性所需的所有组件。作为一个开源项目，kubernetes拥有开放标准和一个庞大的社区，它还保证了相当的灵活性以便快速适应当今不断变化的IT环境。但是回想一下我们在开头有关Kubernetes的“可能性”的陈述。虽然它能兑现许多承诺，但每个企业都应该注意到其中还有许多障碍还未被攻克。尽管深受人们喜爱，但管理Kubernetes还是一个耗时的过程，需要技能熟练的员工和高额的资金投入。为了应对这些挑战，每天都有Kubernetes的管理工具涌现，但是找到正确的，并能适应不断变化的IT环境的工具还是一个难题。
【作者语】 说到容器管理工具，Kubernetes当属第一梯队。本文助你熟悉Kubernetes的部件以及它们之间如何协同工作。
原文链接：Under the Hood: An Intro to Kubernetes Architecture（翻译：马申君）
原文发布时间为：2017-09-29
本文作者：望出扶风
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：揭开面纱：Kubernetes架构详解
