#IT明星不是梦#图解kubernetes Pod生命周期事件生成器

PLEG(PodLifecycleEventGenerator)主要是用于周期性检测Pod的运行状态,从而对比Pod前后状态生成事件从而触发kubelet进行Pod容器状态的校证,让我们一起来初探下其内部实现机制

1. 图解设计

1.1 Pod事件生成


Pod事件生成主要是根据对应Pod前后的状态对比来实现,首先通过runtime来获取当前节点的所有Pod的列表,并将对应的状态进行保存,这样在下一个轮训周期就可以通过前后状态的对比去发现状态发生改变的Pod的容器,并且产生对应的事件

1.2 事件通知与状态同步


Pod事件生成之后会通过管道将对应的事件同步给状态同步线程,状态同步线程感知到Pod的变更事件后,会与Pod的目标状态进行对比同步,并调用Runtime来进行最终校证操作的执行,同时在下个轮询周期中又会重新从Runtime获取状态,从而不断校证Pod的状态,直至目标状态

2. Pod记录

Pod记录其实就是一个map,并通过podRecord来保存前后轮询周期Runtime返回的Pod的信息

type podRecord struct {
    old     *kubecontainer.Pod
    current *kubecontainer.Pod
}

type podRecords map[types.UID]*podRecord

3. Pod事件生成器

3.1 获取Pod状态

首先通过runtime来获取当前节点的所有pod的状态

    // Get all the pods.
    podList, err := g.runtime.GetPods(true)
    if err != nil {
        klog.Errorf("GenericPLEG: Unable to retrieve pods: %v", err)
        return
    }

3.2 对比Pod信息生成事件

    eventsByPodID := map[types.UID][]*PodLifecycleEvent{}
    for pid := range g.podRecords {
        // 获取之前的Pod信息
        oldPod := g.podRecords.getOld(pid)
        pod := g.podRecords.getCurrent(pid)
        // 获取当前Pod的所有容器集合
        allContainers := getContainersFromPods(oldPod, pod)
        for _, container := range allContainers {
            //
            events := computeEvents(oldPod, pod, &container.ID)
            for _, e := range events {
                // 更新pod的events事件
                updateEvents(eventsByPodID, e)
            }
        }
    }

3.3对比容器状态事件生成

Pod的事件主要是通过底层容器的状态来生成的,会最终对比每个容器的前后状态,从而获取变更事件

func generateEvents(podID types.UID, cid string, oldState, newState plegContainerState) []*PodLifecycleEvent {
    if newState == oldState {
        return nil
    }

    klog.V(4).Infof("GenericPLEG: %v/%v: %v -> %v", podID, cid, oldState, newState)
    switch newState {
    case plegContainerRunning:
        return []*PodLifecycleEvent{{ID: podID, Type: ContainerStarted, Data: cid}}
    case plegContainerExited:
        return []*PodLifecycleEvent{{ID: podID, Type: ContainerDied, Data: cid}}
    case plegContainerUnknown:
        return []*PodLifecycleEvent{{ID: podID, Type: ContainerChanged, Data: cid}}
    case plegContainerNonExistent:
        switch oldState {
        case plegContainerExited:
            // We already reported that the container died before.
            return []*PodLifecycleEvent{{ID: podID, Type: ContainerRemoved, Data: cid}}
        default:
            return []*PodLifecycleEvent{{ID: podID, Type: ContainerDied, Data: cid}, {ID: podID, Type: ContainerRemoved, Data: cid}}
        }
    default:
        panic(fmt.Sprintf("unrecognized container state: %v", newState))
    }
}

4. 整体事件流程总览


在k8s中有很多类似PLEG的设计,总的设计目标都是为了通过事件的变更和实际期望状态,不断的进行调整,从而达到最终的期望状态, 以后我尽量只给出组件最核心的一点代码,梳理清除整个流程中核心的数据结构与算法

k8s源码阅读电子书地址: https://www.yuque.com/baxiaoshi/tyado3

原文地址:https://blog.51cto.com/srexin/2472678

时间: 2024-11-07 03:14:04

#IT明星不是梦#图解kubernetes Pod生命周期事件生成器的相关文章

# IT明星不是梦 #图解kubernetes调度器SchedulingQueue核心源码实现

chedulingQueue是kubernetes scheduler中负责进行等待调度pod存储的对,Scheduler通过SchedulingQueue来获取当前系统中等待调度的Pod,本文主要讨论SchedulingQueue的设计与实现的各种实现, 了解探究其内部实现与底层源码,本系列代码基于kubernets1.1.6分析而来 SchedulingQueue设计 队列与优先级 队列与场景 类型 描述 通常实现 队列 普通队列是一个FIFO的数据结构,根据元素入队的次序依次出队 数组或者

#IT明星不是梦#图解kubernetes容器探活机制核心实现

在k8s中通过kubelet拉起一个容器之后,用户可以指定探活的方式用于实现容器的健康性检查,目前支持TCP.Http和命令三种方式,今天介绍其整个探活模块的实现, 了解其周期性探测.计数器.延迟等设计的具体实现 1. 探活的整体设计 1.1 线程模型 探活的线程模型设计相对简单一些,其通过worker来进行底层探活任务的执行,并通过Manager来负责worker的管理, 同时缓存探活的结果 1.2 周期性探活 根据每个探活任务的周期,来生成定时器,则只需要监听定时器事件即可 1.3 探活机制

# IT明星不是梦 #图解kubernetes容器探活机制核心实现状态管理

k8s为实现容器探活worker的管理构建了一个Manager组件,该组件负责底层探活worker的管理,并且缓存当前的容器的状态,并对外同步容器的当前状态,今天我们就来分析下其部分核心组件 1. 核心原理实现 Manager缓存的状态主要是会被kubelet.状态组件消费,并且在Pod同步状态的时候,会通过当前Manager里面的探测状态来更新Pod的容器的就绪与启动状态的更新,让我们一起看看Manager自身的一些关键实现吧 2. 探活结果管理 即prober/results/results

# IT明星不是梦 # 图解kubernetes容器状态同步机制核心实现

在K8s中将Pod调度到某一台Node节点之后,后续的状态维护信息则是由对应机器上的kubelet进行维护,如何实时反馈本地运行状态,并通知apiserver则是设计的难点, 本节主要是通过感知Pod状态变化和探测状态改变两个流程来实际分析其核心数据结构,来了解内部设计 1. 状态管理 1.1 静态Pod 静态Pod主要是指的那些不是通过感知apiserver创建的pod, 因为apiserver上并不包含,但是同时也需要维护和获取这类Pod的状态, k8s中就设计了一个镜像Pod的概念,其实就

# IT明星不是梦 # 图解kubernetes资源扩展机制实现(上)

k8s目前主要支持CPU和内存两种资源,为了支持用户需要按需分配的其他硬件类型的资源的调度分配,k8s实现了设备插件框架(device plugin framework)来用于其他硬件类型的资源集成,比如现在机器学习要使用GPU等资源,今天来看下其内部的关键实现 1. 基础概念 1.1 集成方式 1.1.1 DaemonSet与服务 当我们要集成本地硬件的资源的时候,我们可以在当前节点上通过DaemonSet来运行一个GRPC服务,通过这个服务来进行本地硬件资源的上报与分配 1.1.2 服务注册

Kubernetes1.3:POD生命周期管理

转:http://blog.csdn.net/horsefoot/article/details/52324830 (一)  核心概念 Pod是kubernetes中的核心概念,kubernetes对于Pod的管理也就是对Pod生命周期的管理,对Pod生命周期的管理也就是对Pod状态的管理,我们通过下面Pod相关的各个实体信息关系图可以分析出来kubernetes是如何管理Pod状态的. (二)  结构体介绍 Pod这个结构体中有个变量Status,通过这个变量可以得到每个Pod的状态信息,这个

图解ios程序生命周期

图解ios程序生命周期 应用程序启动后状态有Active.Inactive.Background.Suspended.Not running这5种状态,几种状态的转换见下图: 在AppDelegate中实现app状态变化时的回调函数,在 app状态发生变化时,系统会执行相应回调: - (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions

kubernetes之给容器的生命周期事件添加处理器

简介 此文讲述如何给容器的声明周期时间添加处理器,Kubernetes支持postStart和preStop事件.Kubernetes在容器启动之后立即发送postStart事件,在容器终止之前立即发送preStop事件. 备注:此文档参考官方文档,并加以自己的理解.如有误导性的内容,请批评指正. 定义 postStart 和 preStop 处理器 创建一个包含一个容器的Pod,容器中有postStart和preStop事件.文件名:lifecycle-events.yaml apiVersi

Kubernetes之Pod的生命周期

目录 Kubernetes之Pod的生命周期 理解Pod Pod内如何管理多个容器 Pod的使用 其他替代选择 Pod的持久性 Pod的终止 Init容器 Pause容器 Pod的生命周期 Pod的phase Pod的状态 容器探针 存活性探测 livenessProbe 就绪性探测 readnessProbe livenessProbe和readinessProbe使用场景 lifecycle Kubernetes之Pod的生命周期 理解Pod Pod是kubernetes中你可以创建和部署的