Kubernetes入门之系统架构
1. 前言
Kubernetes简称k8s（也缩写为kube），一个开源的用于自动化部署容器化（主要针对Docker，其它如katacontainers和rkt也支持）应用程序系统，通过分组容器（容器组被命名为Pod，Pod也是Kubernetes的最小调度单元）来调度和管理容器，官方网站：https://kubernetes.io/，本文大量参考了官方的https://kubernetes.io/docs/concepts/、https://kubernetes.io/zh/（官方中文）等。
如何快速认识和上手Kubernetes？可从三方面入手，一是了解Kubernetes的系统架构，二是了解Kubernetes涉及的主要概念，三是动手安装运行初体验。
2. 系统架构
2.1. 主从架构
Kubernetes采用的是常见的主从架构（master-slave），注意这里的Slave并不是Master的复制节点，而是工作节点（Work Node）。
Kubernetes官方把Slave节点直接叫节点（Node），本文把它叫作工作节点（Work Node），以从名称上更好的区分于主控节点（Master Node）。其中Master为单个节点，而Slave则多节点；Master负责管理、调度和监控，Slave负责执行。
Master由三部分组成：kube-apiserver、kube-controller-manager、kube-scheduler和cloud-controller-manager，每一成员均为一独立进程，Master依赖Etcd存储各状态数据；Slave由两部分组成：kubelet、kube-proxy和Container Runtime，每一成员也均为一独立进程。
下为Kubernetes官方提供的架构图（cloud-controller manager还非正式发布）：
2.2. 基本概念
前言部分已介绍Pod是Kubernetes的最小调度单元，而不是容器Container。Pod、容器（Container）和节点（Node，这里特指工作节点）三者密切相关，可理解为一种包含关系，如下图所示：
如果把Pod视作进程组，则Container可视为进程（实际上，一个容器内还可有多个物理进程）。一个Pod内可有多个容器，一个节点可有多个Pod，Kubernetes的最基本作用就是通过Pod来管理容器，包括分配运行容器的工作节点（Work Node）和容器的启停等。因为Pod是Kubernetes的最小调度单元，所以实际直接操作的是Pod。
Pod类似进程，是临时性的，有五种状态：
Pending | 待运行 | Kubernetes已接受Pod，但一或多个容器映射还没被创建，可能是调度正在下载容器映射等 |
|---|---|---|
Running | 运行中 | Pod已被调度到工作节点，所有的容器也已创建好，至少一个容器正在运行或正在（重）启动中。 |
Succeeded | 运行成功（结束） | Pod中的所有容器都运行结束，并且全部运行成功，而且不会重启 |
Failed | 运行失败（结束） | Pod中的所有容器都运行结束，但至少有一个运行失败（容器退出状态非0） |
Unknown | 未知 | 通常是因为无法和Pod所在节点通信，导致无法获取Pod状态 |
2.3. 主控节点（Master Node）
2.3.1. kube-apiserver
Kubernetes的对外窗口，是Kubernetes的控制面（control plane），操控Kubernetes需经过kube-apiserver。有两种操作Kubernetes方法：一是使用Kubernetes提供的命令行工具kube-apiserver，二是使用Kubernetes提供的API。kube-apiserver是无状态的且没有单点问题，所以没有主备之分。
2.3.2. kube-controller-manager
Kubernetes控制管理器是Kubernetes的大脑，通过kube-apiserver管理和监控Kubernetes的各种资源，由几大管理控制器组成：
Node Controller | 节点控制器 | 负责在节点出现故障时进行通知和响应 |
|---|---|---|
Replication Controller | 副本控制器 | 负责为系统中的每个副本控制器对象维护正确数量的Pod |
Endpoints Controller | 端点控制器 | 填充Endpoints对象（即，加入Services＆Pods） |
Service Account & Token Controllers | 服务帐户和访问令牌控制器 | 为新Namespace创建默认帐户和API访问令牌 |
kube-controller-manager有单点，所以有主备kube-controller-manager，通过选举的方式产生主kube-controller-manager。
2.3.3. kube-scheduler
调度器监视新创建的未分配工作节点的Pod，将Pod调度到（分配）最佳的工作节点。Kubernetes支持自定义调度器，来取代默认的kube-scheduler调度器。
如果调度器不能为Pod找到合适的工作节点，则Pod保持未调度状态，直到被调度分配工作节点。
kube-scheduler通过两步操作为Pod选择一个工作节点：
操作 | 说明 | |
|---|---|---|
1 | Filtering | 过滤出合适的工作节点，如果没有过滤出任何工作节点，则Pod保持为未调度状态 |
2 | Scoring | 对工作节点打分，选择分数最高的，分数相同的随机选择 |
kube-scheduler有单点，所以有主备kube-scheduler，通过选举的方式产生主kube-scheduler。
2.3.4. cloud-controller-manager
云控制管理器运行与底层云提供商（如AWS）交互的控制器，也由四大管理控制器组成：
Node Controller | 节点控制器 | 用于检查云提供程序，以确定节点停止响应后是否已将其删除到云中 |
|---|---|---|
Route Controller | 路由控制器 | 用于在基础云基础架构中设置路由 |
Service Controller | 服务控制器 | 用于创建、更新和删除云提供商负载平衡器 |
Volume Controller | 卷控制器 | 用于创建、附加和安装卷以及与云提供商交互以编排卷 |
2.4. 工作节点（Work Node）
2.4.1. Kubelet
运行在每个工作节点上的系统代理（Agent），确保容器运行在Pod中，Kubelet确保PodSpec描述的容器运行正常。Kubelet只管理Kubernetes所创建的容器，而不管理其它非Kubernetes创建的容器。
2.4.2. kube-proxy
运行在每个工作节点上的网络代理（Proxy），实现了Kubernetes Service概念的部分。kube-proxy维护工作节点上的网络规则，这些规则允许Kubernetes集群内外部与Pod进行网络通讯。如果系统的数据包过滤层可用，则kube-proxy使用它，否则kube-proxy自己转发流量。
2.4.3. Container Runtime
Kubernetes支持除Docker外的多种容器，运行具体的容器是通过容器运行时完成的。Kubernetes支持：Docker、containerd、cri-o、rktlet、Frakti和实现Kubernetes CRI（容器运行时接口，Container Runtime Interface）的任何容器。
2.5. 扩展插件（Addons）
扩展插件使用Kubernetes资源实现集群特性，因为它们提供了群集级功能，所以插件的命名空间资源属于kube-system命名空间，下列是部分可选的插件。
2.5.1. DNS
除DNS外的其它的扩展插件不是必须的，但应有集群级的DNS服务器。由Kubernetes启动的容器，会在其DNS搜索中自动包括此DNS服务器。
2.5.2. Web UI (Dashboard)
仪表板（Dashboard）是Kubernetes集群的通用基于Web的UI，它允许用户管理集群中运行的应用程序以及集群本身并进行故障排除。
2.5.3. Container Resource Monitoring
容器资源监视在中央数据库中记录有关容器的一般时间序指标，并提供用于浏览该数据的UI。
2.5.4. Cluster-level Logging
集群级日志记录，负责通过搜索/浏览接口将容器日志保存到中央日志存储中。
window._bd_share_config={"common":{"bdSnsKey":{},"bdText":"","bdMini":"2","bdMiniList":false,"bdPic":"","bdStyle":"0","bdSize":"16"},"share":{}};with(document)0[(getElementsByTagName('head')[0]||body).appendChild(createElement('script')).src='http://bdimg.share.baidu.com/static/api/js/share.js?v=89860593.js?cdnversion='+~(-new Date()/36e5)];