客户端上报和心跳_kubelet 状态上报的方式

分布式系统中服务端会通过心跳机制确认客户端是否存活,在 k8s 中,kubelet 也会定时上报心跳到 apiserver,以此判断该 node 是否存活,若 node 超过一定时间没有上报心跳,其状态会被置为 NotReady,宿主上容器的状态也会被置为 Nodelost 或者 Unknown 状态。kubelet 自身会定期更新状态到 apiserver,通过参数 --node-status-update-frequency 指定上报频率,默认是 10s 上报一次,kubelet 不止上报心跳信息还会上报自身的一些数据信息。

一、kubelet 上报哪些状态

在 k8s 中,一个 node 的状态包含以下几个信息:

  • Addresses
  • Condition
  • Capacity
  • Info

1、Addresses

主要包含以下几个字段:

  • HostName:Hostname 。可以通过 kubelet 的 --hostname-override 参数进行覆盖。
  • ExternalIP:通常是可以外部路由的 node IP 地址(从集群外可访问)。
  • InternalIP:通常是仅可在集群内部路由的 node IP 地址。

2、Condition

conditions 字段描述了所有 Running nodes 的状态。

客户端上报和心跳_kubelet 状态上报的方式_第1张图片

3、Capacity

描述 node 上的可用资源:CPU、内存和可以调度到该 node 上的最大 pod 数量。

4、Info

描述 node 的一些通用信息,例如内核版本、Kubernetes 版本(kubelet 和 kube-proxy 版本)、Docker 版本 (如果使用了)和系统版本,这些信息由 kubelet 从 node 上获取到。

使用 kubectl get node xxx -o yaml 可以看到 node 所有的状态的信息,其中 status 中的信息都是 kubelet 需要上报的,所以 kubelet 不止上报心跳信息还上报节点信息、节点 OOD 信息、内存磁盘压力状态、节点监控状态、是否调度等。

客户端上报和心跳_kubelet 状态上报的方式_第2张图片

二、kubelet 状态异常时的影响

如果一个 node 处于非 Ready 状态超过 pod-eviction-timeout的值(默认为 5 分钟,在 kube-controller-manager 中定义),在 v1.5 之前的版本中 kube-controller-manager 会 force delete pod 然后调度该宿主上的 pods 到其他宿主,在 v1.5 之后的版本中,kube-controller-manager 不会 force delete pod,pod 会一直处于TerminatingUnknown 状态直到 node 被从 master 中删除或 kubelet 状态变为 Ready。在 node NotReady 期间,Daemonset 的 Pod 状态变为 Nodelost,Deployment、Statefulset 和 Static Pod 的状态先变为 NodeLost,然后马上变为 Unknown。Deployment 的 pod 会 recreate,Static Pod 和 Statefulset 的 Pod 会一直处于 Unknown 状态。

当 kubelet 变为 Ready 状态时,Daemonset的pod不会recreate,旧pod状态直接变为Running,Deployment的则是将kubelet进程停止的Node删除,Statefulset的Pod会重新recreate,Staic Pod 会被删除。

三、kubelet 状态上报的实现

kubelet 有两种上报状态的方式,第一种定期向 apiserver 发送心跳消息,简单理解就是启动一个 goroutine 然后定期向 APIServer 发送消息。

第二中被称为 NodeLease,在 v1.13 之前的版本中,节点的心跳只有

你可能感兴趣的:(客户端上报和心跳)