其他分享
首页 > 其他分享> > K8s架构|全面整理K8s的架构介绍

K8s架构|全面整理K8s的架构介绍

作者：互联网

K8S架构与核心技术介绍

参考文献：

https://jimmysong.io/kubernetes-handbook/concepts/concepts.html

https://www.infoq.cn/article/kubernetes-and-cloud-native-applications-part01/

文章目录

1. 架构图

1.1 整体结构图

在这里插入图片描述

1.2 组件间的协议

在这里插入图片描述

1.3 master与node架构图

在这里插入图片描述

1.4 分层架构图

在这里插入图片描述

核心组件：

分层介绍：

2. K8s核心技术概念

2.1 API对象

API对象是K8S的集群中管理操作单元；每个API对象都有3大类属性：元数据metadata，规范spec和状态status；元数据：标识API对象；

API对象至少含有3个元数据：namespace,name,uid;

API对象通过spec去设置配置； 用户通过配置系统的理想状态来改变系统 ， 所有的操作都是声明（Declarative）的而不是命令式（Imperative）的 ； 声明式操作在分布式系统中的好处是稳定，不怕丢操作或运行多次 ；

2.2 Pod

Pod 的设计理念是支持多个容器在一个 Pod 中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。Pod 对多容器的支持是 K8 最基础的设计理念 ；

Pod 是 Kubernetes 集群中所有业务类型的基础，可以看作运行在 Kubernetes 集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。

目前 Kubernetes 中的业务主要可以分为

业务API对象
长期伺服型（long-running）Deployment
批处理型（batch）Job
节点后台支撑型（node-daemon）DaemonSet
有状态应用型（stateful application）StatefulSet

2.3 RC：副本控制器 Replication Controller

保证 Pod 高可用的 API 对象； 通过监控运行中的 Pod 来保证集群中运行指定数目的 Pod 副本。指定的数目可以是多个也可以是 1 个；少于指定数目，RC 就会启动运行新的 Pod 副本；多于指定数目，RC 就会杀死多余的 Pod 副本。即使在指定数目为 1 的情况下，通过 RC 运行 Pod 也比直接运行 Pod 更明智，因为 RC 也可以发挥它高可用的能力，保证永远有 1 个 Pod 在运行。RC 是 Kubernetes 较早期的技术概念，只适用于长期伺服型的业务类型，比如控制小机器人提供高可用的 Web 服务。

2.4 RS：副本集 Replica Set

RS 是新一代 RC，提供同样的高可用能力，区别主要在于 RS 后来居上，能支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为 Deployment 的理想状态参数使用。

RC 和 RS 主要是控制提供无状态服务的，其所控制的 Pod 的名字是随机设置的，一个 Pod 出故障了就被丢弃掉，在另一个地方重启一个新的 Pod，名字变了。名字和启动在哪儿都不重要，重要的只是 Pod 总数；

对于 RC 和 RS 中的 Pod，一般不挂载存储或者挂载共享存储，保存的是所有 Pod 共享的状态

2.5 部署：Deployment

部署表示用户对 Kubernetes 集群的一次更新操作。部署是一个比 RS 应用模式更广的 API 对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的 RS，然后逐渐将新 RS 中副本数增加到理想状态，将旧 RS 中的副本数减小到 0 的复合操作；这样一个复合操作用一个 RS 是不太好描述的，所以用一个更通用的 Deployment 来描述。以 Kubernetes 的发展方向，未来对所有长期伺服型的的业务的管理，都会通过 Deployment 来管理。

2.6 服务：service

RC、RS 和 Deployment 只是保证了支撑服务的微服务 Pod 的数量，但是没有解决如何访问这些服务的问题。一个 Pod 只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的 IP 启动一个新的 Pod，因此不能以确定的 IP 和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在 K8 集群中，客户端需要访问的服务就是 Service 对象。每个 Service 会对应一个集群内部有效的虚拟 IP，集群内部通过虚拟 IP 访问一个服务。在 K8s 集群中微服务的负载均衡是由 Kube-proxy 实现的。Kube-proxy 是 K8s 集群内部的负载均衡器。它是一个分布式代理服务器，在 K8s 的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的 Kube-proxy 就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。

2.7 任务：Job

Job 是 Kubernetes 用来控制批处理型任务的 API 对象。批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job 管理的 Pod 根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的 spec.completions 策略而不同：单 Pod 型任务有一个 Pod 成功就标志完成；定数成功型任务保证有 N 个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功。

2.8 后台支撑服务集：DaemonSet

长期伺服型和批处理型服务的核心在业务应用，可能有些节点运行多个同类业务的 Pod，有些节点上又没有这类 Pod 运行；而后台支撑型服务的核心关注点在 Kubernetes 集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类 Pod 运行。节点可能是所有集群节点也可能是通过 nodeSelector 选定的一些特定节点。典型的后台支撑型服务包括，存储，日志和监控等在每个节点上支持 Kubernetes 集群运行的服务。

2.9 有状态服务集：StatefulSet

是用来控制有状态服务，StatefulSet 中的每个 Pod 的名字都是事先确定的，不能更改。 StatefulSet 中的 Pod，每个 Pod 挂载自己独立的存储，如果一个 Pod 出现故障，从其他节点启动一个同样名字的 Pod，要挂载上原来 Pod 的存储继续以它的状态提供服务。

适合于 StatefulSet 的业务包括数据库服务 MySQL 和 PostgreSQL，集群化管理服务 ZooKeeper、etcd 等有状态服务。StatefulSet 的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制；

使用 StatefulSet，Pod 仍然可以通过漂移到不同节点提供高可用，而存储也可以通过外挂的存储来提供高可靠性，StatefulSet 做的只是将确定的 Pod 与确定的存储关联起来保证状态的连续性。

2.10 Volume：存储卷

Kubernetes 的存储卷的生命周期和作用范围是一个 Pod。每个 Pod 中声明的存储卷由 Pod 中的所有容器共享；

2.11 Node：节点

Kubernetes 集群中的计算能力由 Node 提供，最初 Node 称为服务节点 Minion，后来改名为 Node。Kubernetes 集群中的 Node 也就等同于 Mesos 集群中的 Slave 节点，是所有 Pod 运行所在的工作主机，可以是物理机也可以是虚拟机。不论是物理机还是虚拟机，工作主机的统一特征是上面要运行 kubelet 管理节点上运行的容器。

2.12 Secret：密钥对象

Secret 是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。使用 Secret 的好处是可以避免把敏感信息明文写在配置文件里。在 Kubernetes 集群中配置和使用服务不可避免的要用到各种敏感信息实现登录、认证等功能，例如访问 AWS 存储的用户名密码。为了避免将类似的敏感信息明文写在所有需要使用的配置文件中，可以将这些信息存入一个 Secret 对象，而在配置文件中通过 Secret 对象引用这些敏感信息。这种方式的好处包括：意图明确，避免重复，减少暴漏机会。

2.13 namespace：命名空间

命名空间为 Kubernetes 集群提供虚拟的隔离作用，Kubernetes 集群初始有两个命名空间，分别是默认命名空间 default 和系统命名空间 kube-system，除此以外，管理员可以可以创建新的命名空间满足需要。

2.14 开放接口

CRI

容器运行时接口(Container Runtime Interface)； CRI中定义了容器和镜像的服务的接口，因为容器运行时与镜像的生命周期是彼此隔离的，因此需要定义两个服务。该接口使用Protocol Buffer，基于gRPC ；

Container Runtime实现了CRI gRPC Server，包括RuntimeService和ImageService。该gRPC Server需要监听本地的Unix socket，而kubelet则作为gRPC Client运行。

在这里插入图片描述

CNI

Container Network Interface的是一个标准的通用的接口 ； 由一组用于配置 Linux 容器的网络接口的规范和库组成，同时还包含了一些插件。CNI 仅关心容器创建时的网络分配，和当容器被删除时释放网络资源。

CSI

Container Storage Interface代表容器存储接口； 借助 CSI 容器编排系统（CO）可以将任意存储系统暴露给自己的容器工作负载 ； 部署 CSI 兼容卷驱动后，用户可以使用 csi 作为卷类型来挂载驱动提供的存储。

2.15 资源对象

类别名称
资源对象Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、Job、CronJob、HorizontalPodAutoscaling、Node、Namespace、Service、Ingress、Label、CustomResourceDefinition
存储对象Volume、PersistentVolume、Secret、ConfigMap
策略对象SecurityContext、ResourceQuota、LimitRange
身份对象ServiceAccount、Role、ClusterRole

3. 集群资源管理

3.1 Node

描述：

是K8S的集群工作节点，可以是物理机也可以是虚拟机；

Node状态：

在这里插入图片描述

# 查看节点信息
kubectl describe node NODENAME
# 禁止Pod调度到该节点上
kubectl corndon NODENAME
# 驱逐该节点上的所有 Pod
kubectl drain NODENAME

3.2 Namespace

描述：

简写ns。在集群中，我们可以使用namespace划分出多个“虚拟集群”，这些ns之间可以完全隔离，也可以跨ns，让一个ns中的service访问到其他ns的服务； 比如 Traefik ingress 和 kube-systemnamespace 下的 service 就可以为整个集群提供服务，这些都需要通过 RBAC 定义集群级别的角色来实现；

注意：

不是所有的资源对象都对应ns，其中node和persistentVolume就不属于任何ns；

3.3 Label

描述：

label是资源上的标识，用来对它们进行区分和选择；

特点：

  1. 一个label会以kv形式附加到各种对象上；Node，Pod，Service
  2. 一个资源对象可以定义人一多数量的Label，同一个Label也可以被添加到任意数量的资源对象上去；
  3. label通常再资源对象确定时定义，也可以在资源创建后动态添加或删除；

可以通过label实现资源的多维度分组，以便灵活，方便的进行资源分配，调度，配置，部署等管理工作；

常用的标签如下：

版本标签：“version”:“release”,

环境标签："environment": "dev", "environment": "qa", "environment": "production"

架构标签："tier": "frontend" ,"tier": "backend","tier": "cache"

标签选择器：用于查询和筛选拥有某些标签的资源对象；

标签的选择条件可以使用多个，此时将多个标签选择器进行组合，使用，进行分隔即可；

name=slave,env!=prod
name not in(frontend),env!=prod

Label key的组成：

Label value的组成：

3.4 污点和容忍

描述：

Taint（污点）和 Toleration（容忍）可以作用于 node 和 pod 上，其目的是优化 pod 在集群间的调度，这跟节点亲和性类似，只不过它们作用的方式相反，具有 taint 的 node 和 pod 是互斥关系，而具有节点亲和性关系的 node 和 pod 是相吸的。另外还有可以给 node 节点设置 label，通过给 pod 设置 nodeSelector 将 pod 调度到具有匹配标签的节点上。

Taint 和 toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 pod，是不会被该节点接受的。如果将 toleration 应用于 pod 上，则表示这些 pod 可以（但不要求）被调度到具有相应 taint 的节点上。

污点

通过node上添加污点属性，来决定是否允许Pod调度过来；

Node被设置上污点之后，就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度过来，甚至可以将已存在的Pod驱逐出去；

污点格式：key=value:effect，key和value是污点的标签，effect描述污点的作用，支持如下三个选项：

命令：

# 设置污点
kubectl taint nodes node1 key=value:effect
# 去除污点
kubectl taint nodes node1 key:effect-
# 去除所有污点
kubectl taint nodes node1 key-

# 例如：
# 为node1设置污点
kubectl taint nodes node1 tag=test:PreferNoSchedule
# 为node1取消污点
kubectl taint nodes node1 tag:PreferNoSchedule-
# 为node1删除去除污点
kubectl taint nodes node1 tag-
# 查看node1 污点
kubectl describe node node1

容忍

若将pod调度到一个有污点的node上去，需要用到容忍；

污点就是拒绝，容忍就是忽略，Node通过污点拒绝pod调度上去，pod通过容忍忽略拒绝；

pod的配置

spec:
	containers:
	- name: nginx

	tolerations: # 添加容忍
	- key: "tag" # 对应要容忍的污点的键，空着意味匹配所有的键
	  operator: "Equal" # 操作符，支持Equal和Exists(默认)
	  value: "tests" # 容忍的污点的值
	  effect: "NoExecute" # 添加容忍规则，要个污点规则一致
	  tolerationSeconds: # 容忍时间, 当effect为NoExecute时生效，表示pod在Node上的停留时间

3.5 垃圾回收

描述：

对于 ReplicaSet、StatefulSet、DaemonSet、Deployment、Job、 CronJob 等创建或管理的对象，会自动为其设置 ownerReferences字段的值；K8s的垃圾回收机制需要依赖于ownerReferences；他标记了从属对象的所有者；

在这里插入图片描述

目前有两大类GC：

垃圾回收器的工作流程：

由Scanner、Garbage Processor 和 Propagator 组成；

总结

从 Kubernetes 的系统架构、技术概念和设计理念，我们可以看到 Kubernetes 系统最核心的两个设计理念：一个是 容错性，一个是 易扩展性。容错性实际是保证 Kubernetes 系统稳定性和安全性的基础，易扩展性是保证 Kubernetes 对变更友好，可以快速迭代增加新功能的基础。

功能

标签：架构,Kubernetes,对象,污点,集群,整理,Pod,K8s,节点
来源： https://blog.csdn.net/qq_37419449/article/details/122157277