Kubernetes发展经历
Kubernetes 是希腊语『舵手』的意思，它最开始由 Google 的几位软件工程师创立，深受公司内部 Borg 和 Omega 项目的影响，很多设计都是从 Borg 中借鉴的，同时也对 Borg 的缺陷进行了改进，Kubernetes的简写称为 k8s。即该单词 k 和 s 中间刚好是 8 个字母组成，所以是一种单词的简写形式。类似于，我们在项目中使用的国际化(internationalization)叫做 i18n 是一样效果。
Kubernetes 已经成为容器编排领域的王者，它是基于容器的集群编排引擎，具备扩展集群、滚动升级回滚、弹性伸缩、自动治愈、服务发现等多种特性能力。
Kubernetes 建于 Docker 之上，可以构建一个容器的调度服务，其目的是让用户透过 Kubernetes 集群来进行云端容器集群的管理，而无需用户进行复杂的设置工作，系统会自动选取合适的工作节点来执行具体的容器集群调度处理工作。
其核心概念是 Pod。一个 Pod 由一组工作于同一物理工作节点的容器构成。这些组容器拥有相同的网络命名空间、IP以及存储配额，也可以根据实际情况对每一个 Pod 进行端口映射。此外Kubernetes工作节点会由主系统进行管理，节点包含了能够运行 Docker 容器所用到的服务。
性能对比
当今三大主流调度系统的比较与分析
知识图谱
Kubernetes 解决的核心问题
服务发现和负载均衡
Kubernetes可以使用DNS名称或自己的IP地址公开容器，如果到容器的流量很大，Kubernetes可以负载均衡并分配网络流量，从而使部署稳定。存储编排
Kubernetes允许您自动挂载您选择的存储系统，例如本地存储、公共云提供商等。自动部署和回滚
你可以使用
Kubernetes描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为所需状态。例如，您可以自动化Kubernetes来为您的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。自动二进制打包
Kubernetes允许您指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，Kubernetes可以做出更好的决策来管理容器的资源。自我修复
Kubernetes重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。密钥与配置管理
Kubernetes允许您存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。
Kubernetes的出现不仅主宰了容器编排的市场，更改变了过去的运维方式，不仅将开发与运维之间边界变得更加模糊，而且让DevOps这一角色变得更加清晰，每一个软件工程师都可以通过Kubernetes来定义服务之间的拓扑关系、线上的节点个数、资源使用量并且能够快速实现水平扩容、蓝绿部署等在过去复杂的运维操作。
K8s架构和组成
Kubernetes 遵循非常传统的客户端/服务端的架构模式，客户端可以通过 RESTful 接口或者直接使用 kubectl 与 Kubernetes 集群进行通信，这两者在实际上并没有太多的区别，后者也只是对 Kubernetes 提供的 RESTful API 进行封装并提供出来。每一个 Kubernetes 集群都是由一组 Master 节点和一系列的 Node 节点组成，其中 Master 节点主要负责存储集群的状态并为 Kubernetes 对象分配和调度资源。
主节点服务-Master
作为管理集群状态的 Master 节点，它主要负责接收客户端的请求，安排容器的执行并且运行控制循环，将集群的状态向目标状态进行迁移。Master 节点内部由下面四个组件构成：
API Server: API Server是Kubernetes控制程序的前端，也是用户唯一可以直接进行交互的Kubernetes组件，内部系统组件以及外部用户组件均通过相同的API进行通信。其主要作用就是对外提供RESTful的接口，包括用于查看集群状态的读请求以及改变集群状态的写请求，也是唯一一个与etcd集群通信的组件。etcd: 键值存储（也称为etcd）是Kubernetes用来备份所有集群数据的数据库。它存储集群的整个配置和状态。主节点查询etcd以检索节点，容器和容器的状态参数。Scheduler: 该组件会监视来自API Server的新请求，并将其分配给运行状况良好的节点。它对节点的质量进行排名，并将Pod部署到最适合的节点。如果没有合适的节点，则将Pod置于挂起状态，直到出现合适的节点。controller-manager: 控制器的作用是检查从API Server获得要控制的节点的当前状态，确定是否与所需状态是否存在任何差异并解决。从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。这些控制器包括：节点控制器(负责在节点出现故障时进行通知和响应)、副本控制器(负责为系统中的每个副本控制器对象维护正确数量的Pod)、端点控制器(填充端点Endpoints对象，即加入Service与Pod))、服务帐户和令牌控制器(为新的命名空间创建默认帐户和API访问令牌)。
工作节点-Node
工作节点监听
API Server发送过来的新的工作分配；他们会执行分配给他们的工作，然后将结果报告给Kubernetes主节点。Node 节点主要以下部分组成。
kubelet: 在群集中的每个Node节点上运行。它是Kubernetes内部的主要代理。通过安装kubelet，节点的CPU，RAM和存储成为所处集群的一部分。它监视从API Server发送来的任务，执行任务，并报告给主节点。它还会监视Pod，如果Pod不能完全正常运行，则会向控制程序报告。然基于该信息，主服务器可以决定如何分配任务和资源以达到所需状态。kube-proxy: 确保每个节点都获得其IP地址，实现本地iptables和规则以处理路由和流量负载均衡。Container Runtime: 容器运行时从容器镜像库中拉取镜像，然后启动和停止容器。容器运行时由第三方软件或插件（例如Docker）担当。-
Pod:Pod是Kubernetes中的最小调度单元，一个Pod封装一个容器（也可以封装多个容器），Pod里的容器共享存储、网络等。也就是说，可以把整个Pod看作虚拟机，然后每个容器相当于运行在虚拟机的进程。同一个Pod里的所有容器都被统一安排和调度。
服务部署与调用流程
部署服务
首先我们需要编写
YAML 文件，在里面定义 Pod 里用到了哪些镜像，占用多少内存和 CPU 等信息。 然后使用 kubectl 命令行工具执行 kubectl apply -f xx.yaml ，此时 kubectl 会读取和解析 YAML 文件，将解析后的对象通过 API 请求发送给 Kubernetes 控制平面内 的 API Server。 API Server 会根据要求，驱使 Scheduler 通过 etcd 提供的数据寻找合适的 Node， Controller Manager 会通过 API Server 控制 Node 创建服务，Node 内部的 kubelet 在收到命令后会开始基于 Container runtime 组件去拉取镜像创建容器，最终完成 Pod 的创建。
服务调用
之前直接在浏览器上发送
http 请求，就能打到我们服务器上的 Nginx，然后转发到部署的服务内。 用了 k8s 之后，外部请求会先到达 k8s 集群的 Ingress 控制器，然后请求会被转发到 k8s 内部的某个 Node 的 Kube Proxy 上，再找到对应的 pod，然后才是转发到内部容器服务中，处理结果原路返回，到这就完成了一次服务调用。
