kubernetes 官方文档整理，k8s入门教程笔记整理---4、kubernetes架构

最新推荐文章于 2025-04-11 08:42:21 发布

猫失格

最新推荐文章于 2025-04-11 08:42:21 发布

阅读量774

点赞数 1

分类专栏： k8s 文章标签： kubernetes 笔记架构

本文链接：https://blog.csdn.net/qq_43610489/article/details/132362463

版权

k8s 专栏收录该内容

6 篇文章

订阅专栏

6.kubernetes架构

6.1节点

容器是在节点上的pod中运行的，节点可以是一个虚拟机或者物理机器。每个节点上必有kubelet、容器运行时、kube-proxy。

6.1.1管理

添加节点的方式：

kubelet向控制面执行自注册
手动添加一个Node对象

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

如上，kubernetes会检查kubelet向ApiServer注册节点时使用的机器名称和metadata.name是否匹配。

6.1.2节点自注册

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xTkWx1i6-1692342747981)(img_7.png)]

–register-node为true(默认)，会尝试向API服务注册自己，kubelet会使用到下列启动参数
–kubeconfig - 用于向 API 服务器执行身份认证所用的凭据的路径。
–cloud-provider - 与某云驱动进行通信以读取与自身相关的元数据的方式。
–register-node - 自动向 API 服务注册。
–register-with-taints - 使用所给的污点列表（逗号分隔的 =:）注册节点。当 register-node 为 false 时无效。
–node-ip - 可选的以英文逗号隔开的节点 IP 地址列表。你只能为每个地址簇指定一个地址。例如在单协议栈 IPv4 集群中，需要将此值设置为 kubelet 应使用的节点 IPv4 地址。参阅配置 IPv4/IPv6 双协议栈了解运行双协议栈集群的详情。
如果你未提供这个参数，kubelet 将使用节点默认的 IPv4 地址（如果有）；如果节点没有 IPv4 地址，则 kubelet 使用节点的默认 IPv6 地址。
–node-labels - 在集群中注册节点时要添加的标签。（参见 NodeRestriction 准入控制插件所实施的标签限制）。
–node-status-update-frequency - 指定 kubelet 向 API 服务器发送其节点状态的频率。

6.1.3手动注册

通过创建node资源来注册节点，设置 --register-node=false
设置节点不可调度kubectl cordon $NODENAME

6.1.4节点状态

kubectl describe node <节点名称>

Name:               master
Roles:              control-plane,master,worker
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=master
                    kubernetes.io/os=linux
                    node-role.kubernetes.io/control-plane=
                    node-role.kubernetes.io/master=
                    node-role.kubernetes.io/worker=
                    node.kubernetes.io/exclude-from-external-load-balancers=
Annotations:        flannel.alpha.coreos.com/backend-data: {"VtepMAC":"b2:52:2e:bf:44:0b"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
                    flannel.alpha.coreos.com/public-ip: 192.168.17.142
                    kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Thu, 10 Aug 2023 11:08:54 +0800
Taints:             <none>
Unschedulable:      false
Lease:
  HolderIdentity:  master
  AcquireTime:     <unset>
  RenewTime:       Mon, 14 Aug 2023 16:04:42 +0800
Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Mon, 14 Aug 2023 08:41:44 +0800   Mon, 14 Aug 2023 08:41:44 +0800   FlannelIsUp                  Flannel is running on this node
  MemoryPressure       False   Mon, 14 Aug 2023 16:03:36 +0800   Thu, 10 Aug 2023 11:08:50 +0800   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Mon, 14 Aug 2023 16:03:36 +0800   Thu, 10 Aug 2023 11:08:50 +0800   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Mon, 14 Aug 2023 16:03:36 +0800   Thu, 10 Aug 2023 11:08:50 +0800   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Mon, 14 Aug 2023 16:03:36 +0800   Thu, 10 Aug 2023 11:09:29 +0800   KubeletReady                 kubelet is posting ready status
Addresses: 
  InternalIP:  192.168.17.142
  Hostname:    master
Capacity:
  cpu:                4
  ephemeral-storage:  36805060Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             3787572Ki
  pods:               110
Allocatable:
  cpu:                3600m
  ephemeral-storage:  36805060Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             3160262039
  pods:               110
System Info:
  Machine ID:                 fbb16f83aacf40b2ab5f226ee2c1d15e
  System UUID:                D7AC4D56-70F6-B5A3-4B8A-B79C075CD2DE
  Boot ID:                    db6e1853-ba54-475c-bfea-a314befd7578
  Kernel Version:             3.10.0-1160.el7.x86_64
  OS Image:                   CentOS Linux 7 (Core)
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  docker://20.10.7
  Kubelet Version:            v1.21.5
  Kube-Proxy Version:         v1.21.5
PodCIDR:                      10.233.64.0/24
PodCIDRs:                     10.233.64.0/24
Non-terminated Pods:          (12 in total)
  Namespace                   Name                                       CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
  ---------                   ----                                       ------------  ----------  ---------------  -------------  ---
  default                     nfs-client-provisioner-7477547dd4-skz68    0 (0%)        0 (0%)      0 (0%)           0 (0%)         51m
  default                     nginx                                      0 (0%)        0 (0%)      0 (0%)           0 (0%)         3d22h
  default                     nginx-test-549bf74497-4mgzv                0 (0%)        0 (0%)      0 (0%)           0 (0%)         3d22h
  default                     nginx-test-549bf74497-h9vkb                0 (0%)        0 (0%)      0 (0%)           0 (0%)         3d1h
  kube-system                 coredns-659897cbc4-jjm5g                   100m (2%)     0 (0%)      70Mi (2%)        170Mi (5%)     4d4h
  kube-system                 coredns-659897cbc4-kvj28                   100m (2%)     0 (0%)      70Mi (2%)        170Mi (5%)     4d4h
  kube-system                 kube-apiserver-master                      250m (6%)     0 (0%)      0 (0%)           0 (0%)         4d4h
  kube-system                 kube-controller-manager-master             200m (5%)     0 (0%)      0 (0%)           0 (0%)         4d4h
  kube-system                 kube-flannel-ds-tbfgq                      100m (2%)     100m (2%)   50Mi (1%)        50Mi (1%)      4d4h
  kube-system                 kube-proxy-v7nr4                           0 (0%)        0 (0%)      0 (0%)           0 (0%)         4d4h
  kube-system                 kube-scheduler-master                      100m (2%)     0 (0%)      0 (0%)           0 (0%)         4d4h
  kube-system                 nodelocaldns-jfkt4                         100m (2%)     0 (0%)      70Mi (2%)        170Mi (5%)     4d4h
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests    Limits
  --------           --------    ------
  cpu                950m (26%)  100m (2%)
  memory             260Mi (8%)  560Mi (18%)
  ephemeral-storage  0 (0%)      0 (0%)
  hugepages-1Gi      0 (0%)      0 (0%)
  hugepages-2Mi      0 (0%)      0 (0%)
Events:              <none>

6.1.4.1地址

Addresses: 
  InternalIP:  192.168.17.142
  Hostname:    master

HostName: 节点名称，从节点内核获取的，可以通过kubelet的–host-override覆盖
InternalIP: 仅可在集群内部路由的IP地址
ExternalIP: 节点可外部路由（从集群外可访问的）IP地址

6.1.4.2状况conditions字段描述所有Running节点的状况

Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Mon, 14 Aug 2023 08:41:44 +0800   Mon, 14 Aug 2023 08:41:44 +0800   FlannelIsUp                  Flannel is running on this node
  MemoryPressure       False   Mon, 14 Aug 2023 16:03:36 +0800   Thu, 10 Aug 2023 11:08:50 +0800   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Mon, 14 Aug 2023 16:03:36 +0800   Thu, 10 Aug 2023 11:08:50 +0800   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Mon, 14 Aug 2023 16:03:36 +0800   Thu, 10 Aug 2023 11:08:50 +0800   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Mon, 14 Aug 2023 16:03:36 +0800   Thu, 10 Aug 2023 11:09:29 +0800   KubeletReady

Ready:true节点健康；false节点不健康；unknown节点控制器最近检测(默认40s)没有接收到节点消息
DiskPressure:true节点磁盘不足；false磁盘充足
MemoryPressure:true内存压力；fals内存充足
PIDPressure:true进程压力；false进程充足
NetworkUnavaliable:true节点配置不正确；false配置正确

如果describe 已保护（Cordoned）的node，有可能是SchedulingDisabled代表不可调度

当节点出现问题时，kube-controller-manager会自动给加上一个污点，例如node.kubernetes.io/unreachable node.kubernetes.io/not-ready

6.1.4.3容量Capacity和可分配Allocatable


Capacity:
  cpu:                4
  ephemeral-storage:  36805060Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             3787572Ki
  pods:               110
Allocatable:
  cpu:                3600m
  ephemeral-storage:  36805060Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             3160262039
  pods:               110

描述CPU、内存、pod数量上限。
capacity总容量
allocatable供普通pod小号的资源量

6.1.4.4信息Info

System Info:
  Machine ID:                 fbb16f83aacf40b2ab5f226ee2c1d15e
  System UUID:                D7AC4D56-70F6-B5A3-4B8A-B79C075CD2DE
  Boot ID:                    db6e1853-ba54-475c-bfea-a314befd7578
  Kernel Version:             3.10.0-1160.el7.x86_64
  OS Image:                   CentOS Linux 7 (Core)
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  docker://20.10.7
  Kubelet Version:            v1.21.5
  Kube-Proxy Version:         v1.21.5

节点的一般信息，内核版本、k8s版本、运行时详细信息、操作系统等。由kubelet收集，发布到kubernetes API

6.1.5 心跳

确定节点可用性，两种形式

更新节点的 .status 。
kubectl get nodes master -o yaml
kube-node-lease这个ns里的lease对象，每个节点都有一个。是一种轻量级资源
kubectl get leases.coordination.k8s.io -n=kube-node-lease

由kubelet负责更新这两种资源

节点状态改变、到达时间间隔—>kubelet更新.status。默认五分钟，通过–node-monitor-period配置
kubelet每10秒更新lease对象，如果失败，kubelet会采用指数回退机制，从200毫秒开始重试，最长7秒

6.1.6 节点控制器

当节点注册时自动分配一个CIDR区段
保持节点控制器内节点列表和云服务商提供的机器列表同步
监控节点健康
- 节点不可达，在node的.status修改Ready时，控制器更新Conditions里的Ready为Unknown
- 节点仍然无法访问，对节点上所有pod触发API发起的驱逐操作。默认是在Unkonwn5分钟后进行驱逐
驱逐NoExecute污点所在节点上的pod，除非有容忍度

6.1.6.1 逐出速率限制

–node-eviction-rate逐出速率限制，单位为个/秒，默认0.1，表示10秒内最多从一个节点驱逐pod
某个节点不健康，节点控制器检查不健康节点(非Ready)的百分比

不健康节点超过–unhealthy-zone-threshold(默认0.55)，驱逐速率将降低
集群较小,小于等于–large-cluster-size-threshold 个节点(默认为50)，驱逐操作则停止
否则驱逐速率降为每秒 --secondary-node-eviction-rate 个（默认为 0.01）。

6.1.6.2 资源容量跟踪

Node对象会追踪节点上资源的容量（例如可用内存和CPU数量）。手动添加node可能需要手动设置
kubernetes schedule保证节点上有足够的资源供pod使用

6.1.6.3 节点拓扑

如果启动了TopologyManager特性门控，kubelet可以在做出资源分配决策时使用拓扑提示

6.1.6.4 节点体面关闭

kubelet会尝试检测节点系统关闭事件并终止在节点上运行的所有pod
节点终止期间，kubelet保证pod遵循pod终止流程，且不接受新的pod（即使这些pod已经绑定到该节点）
节点体面关闭依赖于systemd，利用systemd抑制器锁机制，在给定的期限内延迟节点关闭
受GracefulNodeShutdown特性门控控制，在1.21版本默认启用
默认shutdownGracePeriod(关闭的总持续时间)和shutdownGracePeriodCriticalPods(关键pod关闭的持续时间)设置为0，不会激活节点体面关闭的功能。
systemd检测或者通知node关闭—>kubelet在节点上设置NotReady–>kube-schedule不会将pod调度到这个节点—>新pod会被kubelet在PodAdmission阶段拒绝，同时终止本地运行的所有常规pod和关键pod(例如kube-controller-manager,kube-apiserver,kube-scheduler)

关键Pod
* 关键pod(例如kube-controller-manager,kube-apiserver,kube-scheduler)
* 要将 Pod 标记为关键性（critical），设置 Pod 的 priorityClassName 为 system-cluster-critical 或者 system-node-critical。 system-node-critical 是最高级别的可用性优先级，甚至比 system-cluster-critical 更高。

6.1.6.5 基于pod优先级的节点体面关闭

例如如下配置

优先级	数值	关闭期限
custom-class-a	100000	10s
custom-class-b	10000	180s
custom-class-c	1000	120s
regular/unset	0	60s

shutdownGracePeriodByPodPriority:
  - priority: 100000
    shutdownGracePeriodSeconds: 10
  - priority: 10000
    shutdownGracePeriodSeconds: 180
  - priority: 1000
    shutdownGracePeriodSeconds: 120
  - priority: 0
    shutdownGracePeriodSeconds: 60

上面的表格表明，

所有 priority 值大于等于 100000 的 Pod 会得到 10 秒钟期限停止
所有 priority 值介于 10000 和 100000 之间的 Pod 会得到 180 秒钟期限停止
所有 priority 值介于 1000 和 10000 之间的 Pod 会得到 120 秒钟期限停止
所有其他 Pod 将获得 60 秒的时间停止。

注意需要启用GracefulNodeShutdownBasedOnPodPriority特性门控，并设置shutdownGracePeriodByPodPriority

6.1.6.5 节点非体面关闭

ShutdownGracePeriod 和 ShutdownGracePeriodCriticalPod配置不正确。kubelet关闭node时那个节点的kubelet可能已经被关闭，所以pod、pv什么的都删不掉，所以可能需要手动给这个节点打上污点。
kube-controller-manager的NodeOutOfServiceVolumeDetach特性门控启用后，节点打上污点—>节点 Pod 上没有设置对应的容忍度–> Pod 将被强制删除—>节点上被终止的Pod将立即进行卷分离操作

非体面关闭

强制删除没有匹配的 out-of-service 容忍度的 Pod。
立即对此类 Pod 执行分离卷操作。

6.1.6.6 交换内存管理

kubernetes 1.22后的功能，可以逐个节点地启用交换内存支持，必须启用kubelet的NodeSwap 特性门控，使用–fail-swap-on参数或者failSwapOn配置为false
启用后，Kubernetes 数据可以被交换到磁盘

memorySwap:
  swapBehavior: LimitedSwap

LimitedSwap(默认)：Kubernetes 工作负载的交换内存会受限制。不受 Kubernetes 管理的节点上的工作负载仍然可以交换。
- cgroupsv1: Kubernetes 工作负载可以使用内存和交换，上限为 Pod 的内存限制值（如果设置了的话）。
- cgroupsv2: Kubernetes 工作负载不能使用交换内存。
UnlimitedSwap：Kubernetes 工作负载可以使用尽可能多的交换内存请求，一直到达到系统限制为止。

6.2 节点与控制面之间的通信

控制面(主要是APIServer)和k8s集群之间的通信路径

6.2.1 节点到控制面

中心辐射型API模式，节点(主要是运行的pod)发出的API调用都终止于APIServer。APIServer被配置在一个安全的HTTPS端口(443)上远程监听连接请求，并启用了多种客户端身份验证机制
应使用服务的公共根证书开通节点，这样他们可以基于客户端凭据安全的连接APIServer，以客户端证书的形式将客户端凭据提供给kubelet
想要APIServer的pod使用服务账号安全的连接。pod实例化—>k8s自动把公共根证书和一个有效的持有者令牌注入到Pod。k8s服务配置了一个虚拟地址，用于(通过kube-proxy)转发请求到APIServer的HTTPS末端
控制面组件也通过安全端口和集群的APIServer通信
所以节点到控制面的连接是安全的

6.2.2 控制面到节点

APIServer—>kubelet
APIServer—>代理—>节点、pod、服务

6.2.2.1 APIServer到kubelet

一般用于

获取Pod日志
挂接（通过kubectl）到运行中的Pod
提供kubelet端口转发功能
连接到kubelet的HTTPS，默认情况下，APIServer不检查kubelet的服务证书，是不安全的，
如果需要验证这个连接，需要使用–kubelet-certificate-authority给ApiServer提供
一个根证书包，用于验证kubelet的服务证书。也可以在APIServer和kubelet使用SSH隧道

6.2.2.1 APIServer到节点、Pod、服务

默认为纯HTTP方式，没有认证也没有加密。可以通过给API URL中的节点、Pod或服务名称添加
前缀https:来运行在安全的HTTPS连接上。但是仍然不会验证证书，所以还是不是安全的。

6.2.3 SSH隧道（已废弃）

kubernetes支持使用SSH隧道保护从控制面到节点的通信。APIServer建立一个到集群中各节点的SSH隧道
（连接到在22端口监听的SSH服务器）通过这个隧道传输所有到kubelet、节点、pod的请求。可以保证通信不会
被暴露到集群节点所运行的网络之外

6.2.4 konnectivity服务

作为SSH隧道的替代方案，提供TCP层的代理，以便支持从控制面到集群的通信。
包括konnectivity服务器和konnectivity代理，分别运行在控制网络和节点网络中。
konnectivity代理建立并维持到konnectivity服务器的网络连接
启用knnoectivity服务后，所有控制面到节点的通信都通过这些连接传输

6.3 控制器

通过controller监控集群的公共状态，致力于将当前状态转变为期望状态

6.3.1 控制器模式

一个控制器至少追踪一种类型的k8s资源。其中spec代表期望状态，controller就负责确保当前状态接近期望状态。控制器会自动执行操作，
通过APIServer来控制
以Job控制器举例，Job-运行一个或多个pod，执行一个任务后停止。
当Job控制器拿到新任务时，保证一组Node节点上的kubelet可以运行正确数量的pod。job控制器不运行pod，而是通知API服务器来创建或移除Pod，控制面中的其他组件，根据新的消息做出反应

6.3.2 期望状态和当前状态

任务执行时，集群随时可能被修改，控制回路会自动修复故障

6.3.3 设计

k8s有很多控制器，每个控制器管理集群状态的一个特定方面。

6.3.4 运行控制器的方式

k8s内置的控制器，运行在kube-controller-manager里，提供了核心功能。还可以扩展控制器，运行自己的逻辑

6.4 租约（Lease）

分布式系统通常需要租约，租约提供一种机制来锁定共享资源并协调集合成员之间的活动。
在k8s中，租约概念表示为corrdination.k8s.io组的Lease对象。
常用于节点心跳、组件级领导者选举等系统核心功能

[root@master ~]# kubectl get leases.coordination.k8s.io  -A
NAMESPACE         NAME                      HOLDER                                        AGE
kube-node-lease   master                    master                                        6d23h
kube-system       kube-controller-manager   master_e7ad1213-be24-47b7-9369-5be56761d870  6d23h
kube-system       kube-scheduler            master_5b8d5b4e-49ee-41b1-b83a-98211b8e3a76   6d23h

6.4.1 节点心跳

kubernetes使用Lease API将kubelet节点心跳传递到kubernetesAPI服务器。每个节点在kube-node-lease命名空间都有一个Lease对象。
每个kubelet心跳都是对改Lease对象的update请求，更新改Lease的spec.renewTime字段。kubernetes控制平面根据此字段的时间戳来判断节点是否可用

6.4.2 领导者选举

kubernetes 使用Lease确保在任何给定时间某个组件只有一个实例在运行。高可用配置中由kube-controller-manager和kube-scheduler等控制平面组件进行使用，保证这些组件应只有一个实例激活运行，其他实例待机

6.4.3 APIServer身份

在k8s 1.26版本开始，每个kube-apiserver都使用Lease API将身份发布到系统中的其他位置，，检查kube-system命名空间中的lease对象来查看kube-apiserver的租约
kube-apiserver中不再存续的已到期租约在到期1小时后被新的kube-apiserver作为垃圾收集
可以禁用APIServerIdentity特性门控来禁用API服务器身份租约

6.4.4 工作负载

你自己的工作负载可以定义自己的租约。你定义一个租约以便让控制器副本可以使用k8sAPI进行协调以选择或选举一个领导者

6.5 云控制器管理器

在公有云、私有云、混合云运行k8s，cloud-controller-manager是云控制管理器，将控制平面组件嵌入到云平台的控制逻辑。
他允许你及拿过你的集群连接到云提供商的API上，并将与该云平台交互的组件和你的集群交互的组件分离开。
cloud-controller-manager基于插件机制构造的，使得不同云厂商都能将其平台和k8s集成。

6.6 关于 cgroup v2

在linux上，cgroup约束分配给进程的资源。cgroup 是一个 Linux 内核特性，对一组进程的资源使用（CPU、内存、磁盘 I/O 和网络等）进行限制、审计和隔离。
两个cgroup版本：cgroup v1和 cgroup v2(新)。

kubelet和底层容器运行时都需要对接cgroup来强制执行为pod和容器管理资源，包括容器化工作配置CPU/内存请求和限制

6.6.1 cgroup v2

cgroup v2提供了一个具有增强资源管理能力的统一控制系统。
v2版本在cgroup v1进行了多项改进

API中单个统一的层次结构设计
更安全的子树委派给容器
更多的功能特性，例如压力阻塞信息
跨多个资源的增强资源分配管理和隔离
- 统一核算不同类型的内存分配（网络内存、内核内存等）
- 考虑非即时资源变化，例如页面缓存回写

6.6.2 使用cgroup v2

要求

使用默认启用cgroup v2的linux发行版
linux内核为5.8或更高版本
容器云运行时支持cgroup v2
- containerd v1.4+
- cri-o v1.20+
kubelet和绒球内行驶配置为systemd cgroup驱动

6.6.3 查看Linux cgroup版本

stat -fc %T /sys/fs/cgroup/
输出cgroup2fs为v2，tmpfs为v1

6.7 容器运行时接口（CRI）

CRI是一个插件接口，使kubelet能够运行各种容器运行时，CRI定义了主要gRPC协议，是kubelet和容器运行时之间通信的主要协议

6.7.1 API

当通过gRPC连接到容器运行时，kubelet充当客户端。运行时和镜像服务端点必须在容器运行时中可用使用–image-service-endpoint 配置。

6.7.2 升级

升级k8s时，kubelet会尝试在组件重启时自动选择最新的CRI版本，如果失败，那么回退。如果重拨失败，可能需要kubelet

6.8 垃圾收集

垃圾收集。GC（Garbage Collection）用于清理集群资源的各种机制。清理如下资源

终止的Pod
已完成的job
不再存在属主引用的对象
未使用的容器和容器镜像
动态制备、sc回收策略为delete的pv卷
阻滞或过期的CertificateSigningRequest
在以下情形中删除了节点对象
- 当集群使用云控制器管理器运行与云端时
- 当集群使用类似于云控制管理器的插件运行在本地环境中时
节点租约对象

6.8.1 属主和依赖

属主引用代表依赖对象依赖于属主对象，当属主对象删除时，依赖对象对应的被回收，例如deployment和replicateset，replicateset和pod
命名空间资源不允许出现跨命名空间的属主引用。如果某个资源是集群作用域的，那么他的属主资源也得是集群作用域的，否则将会无法解析，不进行垃圾回收

6.8.2 级联删除

当你删除某个对象时，你可以控制k8s自动删除该对象的依赖对象

前台级联删除
当你删除属主对象，首先进入deletion in progress状态—>kubernetes API Server将某对象的metadata.deletionTimestamp字段设置为删除时间
—>APIServer将metadata.finalizer设置为foregroundDeletion—>(此时还能看到该资源)---->controller-manager删除其依赖对象—>删除属主对象—>(此时看不到该资源了)
后台级联删除
删除属主对象—>(看不到资源了)—>后台继续清理依赖对象