免费网站建设案例,wordpress 代码特征,部队网站源码,江苏 网站建设K8s 是一种强大的容器编排和管理平台#xff0c;能够高效地调度、管理和监控容器化应用程序#xff1b;其本身使用声明式语义管理着集群内所有资源模型、应用程序、存储、网络等多种资源#xff0c;Node 本身又属于 K8s 计算资源#xff0c;上面承载运行着各种类型的应用程…K8s 是一种强大的容器编排和管理平台能够高效地调度、管理和监控容器化应用程序其本身使用声明式语义管理着集群内所有资源模型、应用程序、存储、网络等多种资源Node 本身又属于 K8s 计算资源上面承载运行着各种类型的应用程序当Node NotReady 后运行在其上面各种 Workload 类型的 Pod 都会受到影响脱离了 K8s 生命周期的管理后将会变的不可控无法提供服务为保障该 Node 上 Pod 的可用性及可控性K8s 会对这个 Node 上的 Pod 进行网络、存储、副本保持等控制因 K8s 自身 controller manager 较多加上集群管理及运维的复杂度增加了 Node NotReady 后的理解与学习成本本文将基于 K8s 1.24 版本对 Node NotReady 后会触发哪些行为进行详细描述。 1. 控制器探索
1.1. Node Controller
默认情况下Kubelet 每隔 10s (--node-status-update-frequency10s) 更新 Node 的状态我们称之为心跳而 kube-controller-manager 每隔 5s 检查一次 Node 的状态 (--node-monitor-period5s)。kube-controller-manager 会在 Node 未更新状态超过 40s (--node-monitor-grace-period40s)时 将其标记为 NotReady (Node Ready Condition: True on healthy, False on unhealthy and not accepting pods, Unknown on no heartbeat)。当 Node 超过 5m 未更新状态则 kube-controller-manager 会驱逐该 Node 上的所有 Pod。
Kubernetes 会自动给 Pod 添加针对 node.kubernetes.io/not-ready 和 node.kubernetes.io/unreachable 的容忍度且配置 tolerationSeconds300。这里需要注意的是当 Pod 对应容忍没有配置tolerationSeconds时该容忍生效后 K8s 不会对 Pod 进行驱逐可以通过 tolerations 配置 Pod 的容忍度来覆盖默认的配置
tolerations:
- key: node.kubernetes.io/unreachableoperator: Existseffect: NoExecutetolerationSeconds: 300
- key: node.kubernetes.io/not-readyoperator: Existseffect: NoExecutetolerationSeconds: 300 Node 控制器在节点异常后会按照默认的速率--node-eviction-rate0.1即每10秒一个节点的速率进行 Node 的驱逐。Node 控制器按照 Zone 将节点划分为不同的组再跟进 Zone 的状态进行速率调整 Normal所有节点都 Ready默认速率驱逐。 PartialDisruption即超过33% 的节点 NotReady 的状态。当异常节点比例大于 --unhealthy-zone-threshold0.55 时开始减慢速率 小集群即节点数量小于 --large-cluster-size-threshold50停止驱逐 大集群减慢速率为 --secondary-node-eviction-rate0.01 FullDisruption所有节点都 NotReady返回使用默认速率驱逐。但当所有 Zone 都处在 FullDisruption 时停止驱逐。
K8s 此后的所有行为将会围绕着 Pod NotReady 和被驱逐的 Pod 进行展开从下图中我们可以看到牵涉的组件及功能较多让人感觉着实复杂但各个功能相互独立管理逻辑有迹可循以下根据各个组件功能进行详细探索为减少本文篇幅从总体逻辑上说明白 K8s 管理 Node 及 Pod 功能本文只做功能描述具体代码不再详细介绍。 1.2. Deployment Controller
Deployment 通过管理 ReplicaSet 来完成 K8s 中微服务的版本更新、扩容缩容、滚动更新、回滚等高级功能当 Pod NotReady 后会触发对应 ReplicaSet 的副本数保持功能而 Deployment 只会更新自身 status 相关内容。
1.3. ReplicaSet Controller
Replicaset Controller的主要功能是确保期望的 Pod 副本数量与实际运行的 Pod 副本数量一致。因此Replicaset Controller 会重建该 Node 上 相关的 Not Ready 的 Pod 副本以替换NotReady节点上的失效副本。Node NotReady 的 Pod 仍然会保留处于 Terminating 状态Node 恢复后 kubelet 会执行优雅删除并强制删除该 Pod。
1.4. StatefulSet Controller
Node NotReady 同样会对 StatefulSet Pod 触发 eviction 操作用户看到的 Pod 会一直处于 Terminating 状态。此时 StatefulSet Controller 并不会创建新的 PodNode 恢复后 kubelet 会执行优雅删除detach PV然后会重建该Pod。 1.4.1. 为什么没有重建
往往应用中有一些 Pod 没法实现多副本但是又要保证集群能够自愈那么这种某个节点 Down 掉或者网卡坏掉等情况就会有很大影响要如何能够实现自愈呢
对于这种 Unknown 状态的 Stateful Pod 可以通过 force delete 方式去删除。关于 ForceDelete社区是不推荐的因为可能会对唯一的标志符单调递增的序列号产生影响如果发生对 StatefulSet 是致命的可能会导致数据丢失(可能是应用集群脑裂也可能是对 PV 多写导致)。
kubectl delete pods pod --grace-period0 --force
但是这样删除仍然需要一些保护措施以 Ceph RBD 存储插件为例当执行force delete 前根据经验用户应该先设置 ceph osd blacklist防止当迁移过程中网络恢复后容器继续向 PV 写入数据将文件系统弄坏。因为 force delete 是将 PodObj 直接从 ETCD 强制清理这样 StatefulSet Controller 将会新建新的 Pod 在其他节点, 但是故障节点的 Kubelet 清理这个旧容器需要时间此时势必存在 2 个容器mount 了同一块 PV故障节点Pod 对应的容器与新迁移Pod 创建的容器但是如果此时网络恢复那么2 个容器可能同时写入数据后果将是严重的。
1.4.2. 社区推荐的做法
先恢复故障机器自行完成优雅删除操作、detach PV、强制保障进程完全退出后再由 kubuelet 将Pod进行彻底删除最后触发 StatefulSet Controller 副本数保持功能重建该Pod。 1.5. DaemonSet Controller
Node NotReady 对 DaemonSet 不会有影响查询 Pod 处于 NodeLost 状态并一直保持。当 Node 恢复后该类型的Pod 会从 NodeLost 状态直接变成 Running 状态不涉及重建。 1.6. Job Controller
Job Controller负责管理批处理任务。当NotReady节点上的Pod不可用时Job Controller会在其他可用节点上创建新的Pod副本以完成任务。Job Controller会监控任务的进度并确保任务在成功完成或达到重试次数限制后结束。
在 Node 重新变为 Ready 状态时Job Controller会根据需要对Pod进行重新调度以确保任务能够在可用资源的情况下继续执行。同时Job Controller还会处理并发限制和任务完成后的清理工作。 2. 网络
Pod之间的网络通信在Kubernetes集群中至关重要。当 Node 变为NotReady状态时位于该节点上的Pod可能无法与其他Pod进行通信。这可能是由于网络插件故障、网络策略限制或底层网络问题导致的。在 Node 重新变为Ready状态时网络问题可能会得到解决从而恢复Pod之间的通信。然而这还取决于网络插件、配置和底层网络设施的具体情况。 2.1. Endpoints Controller
Endpoints Controller的主要职责是确保 Endpoints 对象始终与 Service 和 Pod 对象的当前状态保持一致。这是 K8s 服务发现和负载均衡功能的基础。其核心工作原理如下 获取 Service 对象当查询不到该 Service 对象时删除同名 Endpoints 对象 根据 Service 对象的.Spec.Selector查询与 Service 对象匹配的 Pod 列表 查询 Service 的 annotations 中是否配置了TolerateUnreadyEndpoints代表允许为 unready 的 Pod 也创建 Endpoints该配置将会影响 Endpoints 对象的 subsets 信息的计算 遍历 Service 对象匹配的 Pod 列表找出处于 Ready 状态的 Pod并计算 Endpoints 的 subsets 信息 获取 Service 同名 Endpoints 对象没有则创建新的 Endpoints将该Service匹配的Pod的 IP 地址和端口信息添加到 Endpoints 对象中。当一个 Service 的选择器发生变化或与该 Service 关联的 Pod 的数量或状态发生变化时Endpoints Controller会更新相应的Endpoints对象以反映当前的 Pod IP 地址和端口信息。
上文已分析到 Node 变为 NotReady 后Node Controller会更新该 Node 上的 Pod 为NotReady 状态更新后 Endpoints Controller 会第一时刻感知到该变化会把该 Pod 从对应的 Endpoints 的 IP list中摘除以保证该 Pod 不会被其他 Pod 访问。
2.2. CoreDNS
CoreDNS就是DNS服务的一种它会监视Kubernetes集群中的各种对象包括Service、Endpoint、Pod等等。通过这些对象的更新CoreDNS可以持续更新DNS记录从而保证集群内的服务发现的正确性和实时性。
简单来说当Service对象发生变化例如新创建了一个Service或者Service的端口、IP等发生了变化时CoreDNS就会根据这些变化更新相关的DNS记录。如果一个Pod被创建、删除或NotReadyCoreDNS也会及时地更新对应的DNS记录。 3. 存储
3.1. 本地存储
如果PV使用的是本地存储例如节点上的磁盘或目录那么当节点变为NotReady状态时位于该节点上的存储卷将无法访问。这可能导致使用这些存储卷的Pod无法正常运行。在这种情况下Kubernetes不会对PV执行任何操作因为本地存储卷与特定节点紧密相关。当节点重新变为Ready状态时存储卷的访问可能会恢复正常。
3.2. 网络存储
对于网络存储如NFS、iSCSI、Ceph等当节点变为NotReady状态时位于该节点上的Pod可能无法访问其存储卷。这可能是由于网络问题或者存储配置问题导致的。在这种情况下Kubernetes不会对PV执行任何操作。当节点重新变为Ready状态并且网络问题得到解决时Pod可能会重新获得对存储卷的访问。 3.3. 云存储
对于云存储如AWS EBS、GCE PD、Azure Disk等当节点变为NotReady状态时Kubernetes可能会根据存储类StorageClass的配置自动将存储卷从不可用节点分离并附加到其他可用节点。这样重新调度到其他节点的Pod可以继续访问其存储卷。请注意这种行为取决于存储类的配置和云提供商的支持。
当Kubernetes集群中的节点变为NotReady状态时对PV和PVC的影响主要取决于存储类型和配置。Kubernetes对PV的操作也因存储类型而异。在节点重新变为Ready状态时存储访问可能会恢复正常但这取决于具体情况。为了确保应用程序的高可用性建议使用支持动态迁移和故障转移的存储解决方案。 3.4. 其他组件和功能
除了上述组件外Kubernetes还有其他组件和功能可能会在节点变为NotReady状态时发生变化。例如
Horizontal Pod AutoscalerHPAHPA负责根据资源利用率自动调整Pod副本数量。在节点变为NotReady状态时HPA可能会在其他可用节点上创建新的Pod副本以满足负载需求。
Ingress ControllerIngress Controller负责管理集群的入口流量。当节点变为NotReady状态时Ingress Controller可能需要重新调度Ingress资源以确保流量能够正确路由到其他可用节点上的Pod。
Persistent VolumesPV和Persistent Volume ClaimsPVC当节点变为NotReady状态时位于该节点上的存储卷可能会受到影响。这可能导致Pod无法访问其持久化存储。在节点重新变为Ready状态时存储卷的访问可能会恢复正常。
总之当Kubernetes集群中的节点变为NotReady状态时各个组件会采取一系列行动来确保集群的稳定性和应用的正常运行。这包括重新调度Pod、确保服务可用性、维护网络通信和存储访问等。在节点重新变为Ready状态时这些组件会根据需要进行相应的调整以恢复正常运行。
