K8S 核心对象

K8S 对象属性

通过

k get po [pod_name] -oyaml 
1

查看一个 pod 的属性(只展示部分统一的属性)：

apiVersion: v1
kind: Pod
metadata:
	annotation:
		anno1: anno1
	creationTimestamp: "2022-08-07T12:16:54"
	generatateName: nginx-542a68c78-
	lables:
		label1: nginx1
	manageFields:
	...
	name: nginx-542a68c78-4d5f7
	namespace: defalut
	resourceVersion: ""
	selfLink: ""
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

其中

apiVersion: v1
kind: Pod
1
2

又叫做 TypeMeta（GKV）

TypeMeta

用来声明对象是什么（确定对象是哪个版本的哪个类型）

• Group
  针对不同的对象，根据不同的业务目的将对象放到不同的 Group 里面，类似于 java 中包的概念。
• Kind
  描述当前对象是什么。类似于 java 中的类。
• Version
  版本，方便 k8s 处理未稳定版本的对象，可以向前兼容三个版本。

Metadata

• NameSpace
  资源隔离的属性，确认当前对象被放在哪个命名空间里面
• Name
  对象实例的名字，和 NameSpace 一起就能确认当前对象具体是谁（相当于确认了这个对象的实例具体是什么）
• Labels&Annotation
  Labels ：标签
  可以对对象加上标签，查询 pod 时可以根据标签坐过滤查询。可以配合 svc（负载均衡） 中的 selector 属性做过滤查询，为指定标签的 pod 提供负载均衡策略

  k get po --show-labels 查看pod并显示标签
  k get po -l label1=nginx1 查看存在标签 label1=nginx1 的pod
  1
  2

  Annotation ：对对象定义进行扩展
• Finalizers
  资源锁：
  防止对象被删除，可以向 Finalizers中放任意的指
• ResourceVersion
  乐观锁版本控制：防止并发出现对同一个对象的修改冲突

Node

• pod 运行的真正主机，可以是物理机或虚拟机。
• node 对象通过 Capacity（计算能力）、Allocatable（可分配资源）来描述节点的计算资源。
• Kubelet 固定按照频率检查系欸但健康状态并上报 APIserver ，该状态记录在 Node 对象的 status 中。

Pod

pod 一组紧密相关的容器集合，是K8S的基本调度单位，容器进程运行在不同的 namespace 中，切彼此共享网络。
设计理念是支持多个容器在一个pod中共享网络和文件系统，通过进程间通信和文件共享这种简单高效的方式组合完成服务。

pod 启动过程

首先我们需要注意一点，任何容器再启动之后需要一个独立的 network namespace

• k8s 在启动一个 pod 的时候实际上会启动两个容器，一个 sandbox containner 和 user containner
  事实上，k8s会先启动这么个sandbox，但只执行一个操作 sleep ，即容器直接进入睡眠状态，意味着这个镜像几乎不占用任何资源，切极度稳定不会崩溃。
• 创建独立的 network namespace，并将其与sandbox的进程相关联，其作用是：
  2.1. 在启动user containner 时我们可能需要下载一些依赖，所以网络必须提前配置好
  2.2. user containner 中进程可能会应为程序的异常而崩溃，容器重启时网络配置就需要重新设置。而k8s 用这个永远不会崩溃的容器 sandbox 来规避这种现象。

ReplicaSet（副本集）

主要是针对pod被删掉，那么这个pod就会永远的消失，服务也就中断了。为了保证服务的高可用性，我们可以通过设置replicas 属性去确保至少有几个应用是可以正常提供服务的。
比如说，我们的 nginx-1 服务隶属于一个副本集，replicas属性的值为 1，那么当我们删掉我们这个nginx-1 pod 的时候，k8s会判断当前运行的 nginx 副本的个数是否大于等于1，若不满足，则会启动一个 nginx 的 pod

Deployment（部署）

支持滚动升级

协同工作原理

图源网络

• 首先Deployment Controller会监听所有的 Deployment 的表。当有 deployment 被创建或更新的时候，Deployment Controller会获取deployment中的template 属性并计算其哈希值。
• 若以当前模板创建的pod的副本集不存在时，他就会创建一个 replica set包存在Api Server（缓存）和etcd中，而且replica set的名字和deployment 中的 template 属性有关系。比如一个 nginx 的 deployment 创建出来的 rs 是 nginx-451a542d4b ,其中451a542d46 就是 template 属性字符串的哈希值。
• 然后 Replicat Cotroller 监听到创建或修改 rs 的事件，会去判断当前模板的 pod 有没有被创建，没有的话则创建 pod 保存在Api Server（缓存）和etcd中。
• 调度器监听到有新的 pod 被创建，通过Api Server读取pod信息根据调度算法把读取出来pod调度到某个node上面。
• 绑定到 node 节点上之后，kublet会判断当前 pod 是否已经启起来了，没启动则会启动这个 pod。
• 另外，Replicat Cotroller在监听deployment对象的同时还会监听 pod 对象，当有 pod 对象消失的时候， Replicat Cotroller会接收到消息，并判断当前模板的副本数 replicas 和实际在运行的 pod 的数量是否一致，若缺少则会创建pod补齐