概述
Kubernetes(K8s) 作为以后最出名的容器编排工具，称得上是云原生(Cloud Native)时代的“操作系统”，相熟和应用它是研发、运维、产品等的必备技能。本篇文章从倒退历史、装置运行、资源、存储、网络、平安、治理、将来瞻望等方面约 680 个知识点概述了 K8s 的常识图谱，旨在帮忙大家更好的理解 K8s 的相干常识，为业务、运维、翻新打下坚实基础。
完整版链接：https://www.processon.com/view/link/60dfeb3e1e085359888fd3e3
名词简写
PV: Persistent Volume
PVC: Persistent Volume Claim
SA: Service Account
HA: High Available
HPA: Horizontal Pod Autoscaler
VPA: Vertical Pod Autoscaler
PSP: Pod Security Policy
PDB: Pod Disruption Budget
CRD: Custom Resource Definition
CSI: Container Storage Interface
CNI: Container Network Interface
CRI: Container Runtime Interface
OCI: Open Container Initiative
CNCF: Cloud Native Computing Foundation
1. 倒退历史 History
随着 Docker 在容器技术站稳脚跟，并在多个场合挑战了其它玩家的切身利益，比方 Google、RedHat、CoreOS、Microsoft 等。Google 在 docker 我的项目刚衰亡就祭出一剑：把外部生产验证的容器 lmctfy（Let Me Container That For You）开源。但面对 Docker的强势崛起，毫无招架之力。Docker 在容器界具备相对的权威和话语权。Google 于是开出高价给 Docker，Docker 的技术 boss 也是联结创始人 Solomon Hykes 预计也是个理想主义者，对这橄榄枝束之高阁。
Google 很无奈，于是联结 RedHat、CoreOS 等开源基础设施畛域玩家们，独特牵头发动了一个名为 CNCF(Cloud Native Computing Foundation)的基金会。
Borg 是 Google 最外围最底层的技术，托管给 CNCF 基金会，即是 Kubernetes。
2017 年 10 月，Docker 公司出乎意料地发表，将在本人的主打产品 Docker 企业版中内置 Kubernetes 我的项目，这标记着继续了近两年之久的“编排之争”至此落下帷幕。
Twitter 在 2019 年 5 月之后，不再应用 Apache Mesos，Aliyun 在 2019 年 7 月之后，不再反对 Docker Swarm。
Kubernetes 在整个社区推动“民主化”架构，即：从 API 到容器运行时的每一层，Kubernetes 我的项目都为开发者暴露出了能够扩大的插件机制，激励用户通过代码的形式染指 Kubernetes 我的项目的每一个阶段。就这样，在这种激励二次翻新的整体气氛当中，Kubernetes 社区在 2016 年之后失去了空前的倒退。更重要的是，不同于之前局限于“打包、公布”这样的 PaaS 化路线，这一次容器社区的凋敝，是一次齐全以 Kubernetes 我的项目为外围的“百家争鸣”。
2. 架构 Architecture
Kubernetes 遵循十分传统的客户端/服务端的架构模式，客户端能够通过 RESTful 接口或者间接应用 kubectl 与 Kubernetes 集群进行通信，这两者在实际上并没有太多的区别，后者也只是对 Kubernetes 提供的 RESTful API 进行封装并提供进去。每一个 Kubernetes 集群都是由一组 Master 节点和一系列的 Worker 节点组成，其中 Master 节点次要负责存储集群的状态并为 Kubernetes 对象调配和调度资源。
Master (Control Plane)
作为治理集群状态的 Master 节点，它次要负责接管客户端的申请，安顿容器的执行并且运行管制循环，将集群的状态向指标状态进行迁徙。Master 节点外部由上面四个组件形成：
kube-apiserver: 负责解决来自客户端(client-go, kubectl)的申请，其次要作用就是对外提供 RESTful 的接口，包含用于查看集群状态的读申请以及扭转集群状态的写申请，也是惟一一个与 etcd 集群通信的组件。
etcd: 是兼具一致性和高可用性的键值数据库，能够作为保留 Kubernetes 所有集群数据的后盾数据库。
kube-scheduler: 主节点上的组件，该组件监督那些新创建的未指定运行节点的 Pod，并抉择节点让 Pod 在下面运行。调度决策思考的因素包含单个 Pod 和 Pod 汇合的资源需要、硬件/软件/策略束缚、亲和性和反亲和性标准、数据地位、工作负载间的烦扰和最初时限。
kube-controller-manager: 在主节点上运行控制器的组件，从逻辑上讲，每个控制器都是一个独自的过程，然而为了升高复杂性，它们都被编译到同一个可执行文件，并在一个过程中运行。通过 list-watch event 事件触发相应控制器的调谐流程，这些控制器包含：Node Controller、Replication Controller、Endpoint Controller、ServiceAccount/Token Controller 等。
Node (Worker)
kubelet: 是工作节点执行操作的 agent，负责具体的容器生命周期治理，依据从 etcd 中获取的信息来治理容器，并上报 pod 运行状态等。
kube-proxy: 是一个简略的网络拜访代理，同时也是一个 Load Balancer。它负责将拜访到某个服务的申请具体调配给工作节点上同一类 label 的 Pod。kube-proxy 本质就是通过操作防火墙规定(iptables或者ipvs)来实现 Pod 的映射。
container-runtime: 容器运行环境是负责运行容器的软件，Kubernetes 反对多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI(容器运行时接口)。
3. 装置运行 Install & Run
K8s 装置能够通过手动下载二进制包(https://github.com/kubernetes/kubernetes/releases)进行，也能够通过第三方工具包装置集群环境，举荐应用后者装置。
目前罕用的第三方工具有：Minikube, Kubeadm, Kind, K3S。
Minikube 实用于轻量级、单节点本地集群环境搭建，老手学习能够选用；Kubeadm 实用于残缺 K8s master/node 多节点集群环境搭建，Kind 的特点是将 K8s 部署到 Docker 容器中，K3S 实用于轻量级、IoT 等微型设施上搭建集群环境。
4. 资源 Resources
在 K8s 中，能够把资源对象分为两类：Workloads(工作负载)、Controllers(控制器)。
Workloads 次要蕴含：Pod, Deployment, StatefulSet, Service, ConfigMap, Secret, DaemonSet, Job/CronJob, HPA, Namespace, PV/PVC, Node 等，次要是将各类型资源按需要和个性分类。
Controllers 次要蕴含：Node Controller, Replication Controller, Namespace Controller, ServiceAccount Controller, Service Controller, Endpoint Controller 等，次要作用是在资源自动化管制中，将各类型资源实在值(Actual)调谐(Reconcile)到期望值(Expect)。
所有资源通过 REST API 调用 kube-apiserver 进行 GET/POST/PATCH/REPLACE/DELETE 资源管制(增删改查)，须要满足接口的认证、受权、权限管制。kubectl 命令是官网提供的客户端命令行工具，封装了 REST API 调用 kube-apiserver。所有资源通过 kube-apiserver 长久化到 etcd 后端存储，因而生产实践中，须要同时保障 kube-apiserver, etcd 的高可用部署，避免单点故障。
5. 存储 Storage
Pod 中 Container 产生的数据须要长久化存储，特地是对于有状态(StatefulSet)服务，能够通过 PV/PVC 进行本地或网络存储，以便容器利用在重建之后依然能够应用之前的数据。如果不须要长久化存储，能够应用 Ephemeral-Volume(emptyDir) 长期存储卷，数据会随着 Pod 的生命周期一起革除。
PV(PersistentVolume) 是对底层共享存储的形象，将共享存储定义为一种“资源”。PV 由管理员手动创立或动静供应(dynamic provision)，通过插件式的机制实现与 CSI(Container Storage Interface) 具体实现进行对接，如 GlusterFS, iSCSI, GCE, AWS 私有云等。
PVC(PersistentVolumeClaim) 则是对存储资源的一个“申请”，就像 Pod “生产” Node 的资源一样，PVC 会 “生产” PV，两者须要在雷同的命名空间，或者满足特定 SC(StorageClass)、Label Selector 的匹配，才能够实现绑定(Bound)。能够设置策略，当 PVC 删除时主动删除其绑定的 PV 资源，及时回收存储资源。
6. 网络 Network
K8s 网络模型设计的一个根底准则是：每个 Pod 都领有一个独立的 IP 地址，即 IP-per-Pod 模型，并假设所有 Pod 都在一个能够间接连通的、扁平的网络空间中。所以不论容器是否运行在同一个 Node 中，都要求它们能够间接通过对方的 IP 进行拜访。
实际上，K8s 中 IP 是以 Pod 为单位进行调配的，一个 Pod 外部的容器共享一个网络协议栈。而 Docker 原生的通过端口映射拜访模式，会引入端口治理的复杂性，而且访问者看到的 IP 地址和端口，与服务提供者理论绑定的不同，因为 NAT 会扭转源/指标地址，服务本身很难晓得本人对外裸露的实在 IP 和端口。
因而，K8s 对集群网络有如下要求：
- 所有容器都能够在不必 NAT 形式下同别的容器通信；
- 所有节点都能够在不必 NAT 形式下同所有容器通信；
- 容器的 IP 和访问者看到的 IP 是雷同的；
K8s 中将一组具备雷同性能的容器利用形象为服务(Service)，并提供对立的拜访地址。能够通过 ClusterIP, NodePort, LoadBalancer 实现集群内、集群外的服务通信，并应用 Ingress(入网)、Egress(出网)等网络策略(NetworkPolicy)对出入容器的申请流量进行访问控制。
7. 调度 Scheduler
调度器(kube-scheduler) 在 K8s 集群中承当了“承前启后”的重要性能，“承上”是指它负责接管 Controller Manager 创立的 Pod，为其抉择一个适合的 Node；“启下”是指选好的 Node 上的 kubelet 服务过程接管后续工作，将负责 Pod 生命周期的“下半生”。
K8s 提供的默认调度流程分为上面两步：
- 预选调度过程：通过多种预选策略(xxx Predicates)，筛选出符合要求的候选节点；
- 确定最优节点：在第一步根底上，采纳优先级策略(xxx Priority) 计算出每个候选节点的分数(score)，得分最高者将被选中为指标 Node。
另外，Pod 能够通过亲和性(Affinity)、反亲和性(Anti-Affinity) 来设置，以偏好或者硬性要求的形式批示将 Pod 部署到相干的 Node 汇合中。而 Taint/Tolerations 与此相反，容许 Node 抵制某些 Pod 的部署。Taint 与 Tolerations 一起工作确保 Pod 不会被调度到不适合的节点上。单个 Node 能够利用多个 Taint，Node 不承受无奈容忍 Taint 的 Pod 调度。Tolerations 是 Pod 的属性，容许（非强制）Pod 调度到 Taint 相匹配的 Node 下来。
Tips：Taint 是 Node 的属性，Affinity 是 Pod 的属性。
8. 平安 Security
K8s 通过一系列机制来实现集群的安全控制，其中包含 Authentication, Authorization, Admission Control, Secret, Service Account 等机制。K8s 中所有资源的拜访、变更都是通过 K8s API Server 的 REST API 实现的，所以在 Authentication 认证中，采纳了三种形式：
- HTTPS: CA + SSL
- HTTP Token
- HTTP Base
Authorization 受权模式包含：ABAC(Attribute-Based Access Control), RABC(Role-Based Access Control), Webhook 等，其中 RBAC 在生产实践中应用较多。基于角色的管制次要包含：Role, RoleBinding, ClusterRoleBinding，后面两者管制某个命名空间下的资源，前面两者管制集群级别或指定命名空间的资源。
通过了后面认证、受权两道关卡之后，还须要通过 Admission Control 所管制的一个准入管制链进行层层验证，包含资源、Pod 和其余各类准入管制插件，只有通过已开启的全副管制链，能力获得成功的 API Server 响应。
K8s 组件 kubectl, kubelet 默认通过名叫 default 的 SA(Service Account) 进行与 API Server 的平安通信，具体实现是通过将名叫 Token 的 Secret 挂载到容器目录下，拜访时携带对应 Token 进行平安验证。
另外，K8s 提供了 PSP(PodSecurityPolicy) 机制对 Pod/Container 进行了更细粒度的安全策略管制，次要包含 host, user, group, privilege, Linux capabilities 的不同层面的管制，Pod/Container 中 securityContext 须要匹配对应策略能力创立胜利。
9. 扩大 Extensions
随着 K8s 的倒退，零碎内置的 Pod, RC, Service, Deployment, ConfigMap 等资源对象曾经不能满足用户多样化的业务、运维需要，就须要对 API 进行扩大。目前 K8s 提供了两种机制来扩大 API：
- CRD 扩大：复用 K8s API Server，须要提供 CRD Controller；
- API Aggregation layer：须要用户编写额定的 API Server，能够对资源进行更细粒度的管制；
实际上，API Aggregation 形式次要是通过 kube-proxy 对不同门路资源的申请，转发到用户自定义的 API Service handler 中解决。
另外，K8s 采纳 out-of-tree 模式的插件机制，在不影响骨干分支代码根底上，反对基础设施组件的扩大，包含：CSI, CNI, CRI, Device Plugins 等，将底层接口以插件形式形象进去，用户只须要实现具体的接口即可将本人的基础设施能力接入 K8s。
10. 治理 Management
K8s 提供了不同维度的集群管理机制，包含 Node 封闭(cordon)、解除封闭(uncordon)、驱赶(drain)、PDB 被动驱赶爱护、资源使用量管制(requests/limits)、Metrics Server 监控采集、Log、Audit 审计等方面。集群管理员还能够应用后面提到的 Affinity, Taints/Tolerations, Label, Annotation 等机制，满足集群多样化治理需要。
另外，集群运行须要思考高可用(HA) 部署，能够从 etcd、master 组件、biz 容器等方面采纳多正本高可用部署，保障集群的稳固运行。
11. 工具 Tools
K8s 提供了客户端工具 kubectl 供用户应用，该工具简直集成了 API Server 能够解决的所有 API，具体应用请参考图中列出的常用命令，全副命令请参考官网文档阐明。
针对简单的业务类型，官网倡议应用 Kustomize 工具包来灵活处理 yaml 文件，在高版本的 K8s 中 kubectl 命令已默认装置 Kustomize，无需独自装置。
另外，K8s 官网举荐应用包管理工具 Helm，通过将各种不同版本、不同环境、不同依赖的利用打包为 Chart，实现疾速 CI/CD 部署、回滚、灰度公布等。
12. 将来瞻望 Ongoing & Future
本文中所波及的 API、资源、字段、工具等可能因 K8s 我的项目倒退太快，有些曾经 Deprecated，请以官网最新为准。
目前，Kubernetes 曾经充沛涉足互联网、AI、区块链、金融等行业，能够料想的是未来会有越来越多的行业开始应用 Kubernetes，并且各行业实际会更深刻。
以后 K8s 社区在反对 Windows container、GPU、VPA 垂直扩容、Cluster Federation 联结多集群、边缘计算、机器学习、物联网等方面进行开发工作，推动更多云原生产品落地实际，最大化利用云的能力、施展云的价值。
参考资料
- Kubernetes 官网文档
- Kubernetes 权威指南：从 Docker 到 Kubernetes 实际全接触(第4版)
- https://www.padok.fr/en/blog/minikube-kubeadm-kind-k3s
- https://segmentfault.com/a/1190000039790009
- https://www.cnblogs.com/lioa/p/12624601.html
- https://blog.csdn.net/dkfajsldfsdfsd/article/details/80990736