Kubernetes架构详解.docx

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-controllermanager”，它运行着所有处理集群日常任务的控制器。包括了节点控制器、副本控制器、端点（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使用了