关于k8s:K8s-系列一-知识图谱

概述

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 联结多集群、边缘计算、机器学习、物联网等方面进行开发工作，推动更多云原生产品落地实际，最大化利用云的能力、施展云的价值。

参考资料

1. Kubernetes 官网文档
2. Kubernetes 权威指南：从 Docker 到 Kubernetes 实际全接触(第 4 版)
3. https://www.padok.fr/en/blog/minikube-kubeadm-kind-k3s
4. https://segmentfault.com/a/1190000039790009
5. https://www.cnblogs.com/lioa/p/12624601.html
6. https://blog.csdn.net/dkfajsldfsdfsd/article/details/80990736