kubernetes架构原则和对象设计

一、什么是kubernetes（k8s）

Kubernetes 是谷歌开源的容器集群管理系统，是 Google 多年大规模容器管理技术 Borg 的开源版本，主要功能包括：

• 基于容器的应用部署、维护和滚动升级；
• 负载均衡和服务发现；
• 跨机器和跨地区的集群调度；
• 自动伸缩；
• 无状态服务和有状态服务；
• 插件机制保证扩展性。
  

1、Kubernetes：声明式系统

kubernetes声明式核心：
幂等性：状态固定，每次我要你做事，请给我返回相同结果。
面向对象的：把一切抽象成对象。

Kubernetes 的所有管理能力构建在对象抽象的基础上，核心对象包括：

• Node：计算节点的抽象，用来描述计算节点的资源抽象、健康状态等。
• Namespace：资源隔离的基本单位，可以简单理解为文件系统中的目录结构。
• Pod：用来描述应用实例，包括镜像地址、资源需求等。 Kubernetes 中最核心的对象，也是打通应用和基础架构的秘密武器。
• Service：服务如何将应用发布成服务，本质上是负载均衡和域名服务的声明。

2、kubernetes架构图

Master Node Component：

• API Server（API服务器）：这是 Kubernetes 控制面板中唯一带有用户可访问 API 以及用户可交互的组件。API
  服 务器会暴露一个 RESTful 的 Kubernetes API 并使用 JSON 格式的清单文件（manifest files）。
• etcd（集群数据存储）：Kubernetes 使 用“etcd”。这是一个强大的、稳定的、高可用的键值存储，被 Kubernetes
  用于长久储存所有的 API 对象。
• Controller Manager（控制管理器）：是 k8s集群"动"起来的关键，它运行着所有处理集群日常任务的控制器。包括了节点控制器、副本控制器、端点（endpoint）控制器以及服务账户等。
• Scheduler（调度器）：调度器会监控新建的 pods（一组或一个容器）并将其分配给节点。

Work Node Component：

• Kubelet：负责调度到对应节点的 Pod 的生命周期管理，执行任务并将 Pod 状态报告给主节
  点的渠道，通过容器运行时（拉取镜像、启动和停止容器等）来运行这些容器。它 还会定期执行被请求的容器的健康探测程序。
• Kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件; kube-proxy负责为Pod创建代理服务，从apiserver获取所有service信息，并根据service信息创建代理服务，实现service到Pod的请求路由和转发，从而实现K8s层级的虚拟转发网络。

3、核心组件详解

（1）APIServer（k8s通信中枢）

Kube-APIServer 是 Kubernetes 最重要的核心组件之一，主要提供以下功能：

• 提供集群管理的 REST API 接口，包括:

 `认证` Authentication； 
 `授权` Authorization； 
 `准入` Admission（Mutating & Valiating）。
1
2
3

• 提供其他模块之间的数据交互和通信的枢纽（其他模块通过 APIServer 查询或修改数据，只有 APIServer 才直接操作 etcd）。
• APIServer 提供 etcd 数据缓存以减少集群对 etcd 的访问。

下面的aggregated apiserver（扩展apiserver），某一天你长大了会去写operator，去写crd，那么你会让apiserver list/watch 这些自定义资源，自定义控制器再根据watch结果去做一些操作这样就实现了自己的apiserver。

（2）Controller Manager

• Controller Manager 是 集群的大脑，是确保整个集群动起来的关键；
• 作用是确保 Kubernetes 遵循声明式系统规范，确保系统的真实状态（Actual State）与用户定义的期望状态（Desired State）一致；
• Controller Manager 是多个控制器的组合，每个 Controller 事实上都是一个control loop，负责侦听其管控的对象，当对象发生变更时完成配置；
• Controller 配置失败通常会触发自动重试，整个集群会在控制器不断重试（Rate Limit Queue）的机制下确保 最终一致性（ Eventual Consistency）。

控制器的工作流程：

（3）Informer 的内部机制

控制器与其他组件协同工作原理：

（4）Scheduler

Scheduler是一种特殊的 Controller，工作原理与其他控制器无差别。
Scheduler 的职责：监控当前集群所有未调度的 Pod，并且获取当前集群所有节点的健康状况和资源使用情况，为待调度 Pod 选择最佳计算节点，完成调度。

调度阶段分为：

• Predict：过滤不能满足业务需求的节点，如资源不足、端口冲突等。
• Priority：按既定要素将满足调度需求的节点评分，选择最佳节点。
• Bind：将计算节点与 Pod 绑定，完成调度。
  

（5）kubelet

Kubernetes 的初始化系统（init system）
• 从不同源获取 Pod 清单，并按需求启停 Pod 的核心组件：
• Pod 清单可从本地文件目录，给定的 HTTPServer 或 Kube-APIServer 等源头获取；
• Kubelet 将运行时，网络和存储抽象成了 CRI，CNI，CSI。
• 负责汇报当前节点的资源信息和健康状态；
• 负责 Pod 的健康检查和状态汇报。

（6）推荐的 Add-ons

• kube-dns：负责为整个集群提供 DNS 服务；
• Ingress Controller：为服务提供外网入口；
• MetricsServer：提供资源监控；
• Dashboard：提供 GUI；
• Fluentd-Elasticsearch：提供集群日志采集、存储与查询。

（7）Kubectl 命令和 kubeconfig

• kubectl 是一个 Kubernetes 的命令行工具，它允许Kubernetes 用户以命令行的方式与 Kubernetes交互，其默认读取配置文件 ~/.kube/config。
• kubectl 会将接收到的用户请求转化为 rest 调用以rest client 的形式与 apiserver 通讯，具体过程可以通过-v 9查看。

kubectl get pods lxcfs-zgdhn -v 9
1

• apiserver 的地址，用户信息等配置在 kubeconfig。

二、深入理解 Kubernetes

1、kubernetes生态系统

IaaS代表技术：openstack + kvm
PaaS代表技术：kubernetes + container，Serverless技术架构（Faas + Baas）

`FaaS（函数即服务）`：微服务下一演进方向，即将一个庞大的业务以function为单位去拆，整个业务的运转依赖于远程过程调用函数，也从`无状态服务演进到了无状态函数`，函数也可以有多个副本。这样对于计算资源分配粒度更小，其利用率会更高。
`BaaS（后端即服务）`：将各种基础服务抽象成资源，提供api交给服务去使用，比如redis、mysql。
1
2

SaaS：其实就是代表一个成熟的软件，直接对外提供使用，比如企业邮箱这种。

2、Kubernetes 设计理念

（1）kubernetes分层架构

• 核心层（Nucleus layer）：Kubernetes 最核心的功能，对外提供 API 构建高层的应用，对内提供插件式应用执行环境。
• 应用层（Application layer）：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS 解析等）。
• 管理层（Governance layer）：系统度量（如基础设施、容器和网络的度量）、自动化（如自动扩展、动态 Provision 等）、策略管理（RBAC、Quota、PSP、NetworkPolicy 等）。
• 接口层（interface layer）：Kubectl 命令行工具、客户端 SDK 以及集群联邦。
• 生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴：

 Kubernetes 外部（on top）：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS 应用、ChatOps 等；
 Kubernetes 内部（Underneath）：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等。
1
2

（2）API设计原则

• 所有 API 都应是声明式的

[1]相对于命令式操作，声明式操作对于重复操作的效果是稳定的，这对于容易出现数据丢失或重复的分布式环境来说是很重要的。 
[2]声明式操作更易被用户使用，可以使系统向用户隐藏实现的细节，同时也保留了系统未来持续优化的可能性。
[3]此外，声明式的 API 还隐含了所有的 API 对象都是名词性质的，例如 Service、Volume 这些 API 都是名词，这些名词描述了用户所期望得到的一个目标对象。 
1
2
3

• API 对象是彼此互补而且可组合的

这实际上鼓励 API 对象尽量实现面向对象设计时的要求，即“高内聚，松耦合”，对业务相关的概念有一个合适的分解，提高分解出来的对象的可重用性。
1

• 高层 API 以操作意图为基础设计

[1]如何能够设计好 API，跟如何能用面向对象的方法设计好应用系统有相通的地方，高层设计一定是从业务出发，而不是过早的从技术实现出发。
[2]因此，针对 Kubernetes 的高层 API 设计，一定是以 Kubernetes 的业务为基础出发，也就是以系统调度管理容器的操作意图为基础设计。
1
2

（3）Kubernetes 通过对象组合完成业务描述

Deployment和replicas之间的绑定关系是一种基于命名规范的弱绑定，创建deployment的时候，会根据pod-template得到一个hash值，然后deploy就会使用{deploy name}-{hash value}拼接而成rs name.

（4）架构设计原则

• 只有 APIServer 可以直接访问 etcd 存储，其他服务必须通过 KubernetesAPI 来访问集群状态；
• 单节点故障不应该影响集群的状态；
• 在没有新请求的情况下，所有组件应该在故障恢复后继续执行上次最后收到的请求（比如网络分区或服务重启等）；
• 所有组件都应该在内存中保持所需要的状态，APIServer 将状态写入 etcd 存储，而其他组件则通过 APIServer更新并监听所有的变化；
• 优先使用事件监听而不是轮询。

（5）引导（Bootstrapping，初始化启动）原则

• Self-hosting（自己管自己，即系统核心组件也容器化） 是目标。

[1]apiserver、controllermanager、scheduler这些系统组件都要容器化，是通过`static pod`方式启动的
[2]所有程序都有初始化程序，`kubelet就是k8s的初始化程序`，所有系统组件容器是由kubelet拉起来的，kubelet又是`systemd管理`的
[3]kubelet是根据`/etc/kubernetes/manifests`下的yaml文件来拉起对应的容器的
1
2
3

• 减少依赖，特别是稳态运行的依赖。
• 通过分层的原则管理依赖。
• 循环依赖问题的原则：

[1]同时还接受其他方式的数据输入（比如本地文件等），这样在其他服务不可用时还可以手动配置引导服务；
[2]状态应该是可恢复或可重新发现的；
[3]支持简单的启动临时实例来创建稳态运行所需要的状态，使用分布式锁或文件锁等来协调不同状态的切换（通常称为 pivoting 技术）； 
[4]自动重启异常退出的服务，比如副本或者进程管理器等。
1
2
3
4

3、API 对象

API 对象是 Kubernetes 集群中的管理操作单元。
Kubernetes 集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的 API 对象，支持对该功能的管理操
作。
每个 API 对象都有四大类属性：

• TypeMeta
• MetaData
• Spec
• Status

（1）TypeMeta

Kubernetes对象的最基本定义，它通过引入GKV（Group，Kind，Version）模型定义了一个对象的类型。

• Group
  Kubernetes 定义了非常多的对象，如何将这些对象进行归类是一门学问，将对象依据其功能范围归入不同的分组，
  比如把支撑最基本功能的对象归入 core 组，把与应用部署有关的对象归入 apps 组，会使这些对象的可维护性和可
  理解性更高。
• Kind
  定义一个对象的基本类型，比如 Node、Pod、Deployment 等。
• Version
  社区每个季度会推出一个 Kubernetes 版本，随着 Kubernetes 版本的演进，对象从创建之初到能够完全生产化就
  绪的版本是不断变化的。与软件版本类似，通常社区提出一个模型定义以后，随着该对象不断成熟，其版本可能会
  从 v1alpha1 到 v1alpha2，或者到 v1beta1，最终变成生产就绪版本 v1。

（2）Metadata

Metadata 中有两个最重要的属性：Namespace和Name，分别定义了对象的Namespace 归属及名字，这两个属性唯一定义了某个对象实例。

• Label
  顾名思义就是给对象打标签，一个对象可以有任意对标签，其存在形式是键值对。Label 定义了对象的可识别属性，Kubernetes API 支持以 Label 作为过滤条件
  label常用种类：
  
• Annotation
  Annotation 与 Label 一样用键值对来定义，但 Annotation 是作为属性扩展，更多面向于系统管理员和开发人员，因此需要像其他属性一样做合理归类。
• Finalizer
  Finalizer 本质上是一个资源锁，Kubernetes 在接收某对象的删除请求时，会检查 Finalizer 是否为空，如果不为空则只对其做逻辑删除，即只会更新对象中的metadata.deletionTimestamp 字段。namespace里还有个spec.finalizers，作用和，metadata是一样。
• ResourceVersion
  ResourceVersion 可以被看作一种乐观锁，每个对象在任意时刻都有其ResourceVersion，当 Kubernetes 对象被客户端读取以后，ResourceVersion信息也被一并读取，并进行比对ResourceVersion信息。此机制确保了分布式系统中任意多线程能够无锁并发访问对象，极大提升了系统的整体效率。

（3）Spec和Status

• Spec 和 Status 才是对象的核心。
• Spec 是用户的期望状态，由创建对象的用户端来定义。
• Status 是对象的实际状态，由对应的控制器收集实际状态并更新。
• 与 TypeMeta 和 Metadata 等通用属性不同，Spec 和 Status 是每个对象独有的。

常用 Kubernetes 对象及其分组:

4、核心对象概览

node、service、deployment、statefulset、job、pv、pvc等等，这些就不赘述了，重在使用