vlambda博客
学习文章列表

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 对集群网络有如下要求:

  • 所有容器都可以在不用 NAT 方式下同别的容器通信;

  • 所有节点都可以在不用 NAT 方式下同所有容器通信;

  • 容器的 IP 和访问者看到的 IP 是相同的;

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