K8s的CRI机制是什么？

1. 概述

进入 K8s 的世界，会发现有很多方便扩展的 Interface，包括 CRI, CSI, CNI 等，将这些接口抽象出来，是为了更好的提供开放、扩展、规范等能力。

K8s CRI(Container Runtime Interface) 是 K8s 定义的一组与容器运行时进行交互的接口，用于将 K8s 平台与特定的容器运行时实现解耦。CRI 在 Kubernetes 1.5 中引入，并充当 kubelet 和容器运行时之间的桥梁。目前实现了 CRI spec 的 Runtime 有 Docker Engine、containerd、CRI-O、Mirantis Container Runtime(Docker 企业版) 等。

2020 年，K8s 宣布弃用 dockershim，标志着容器运行时正式向 CRI 切换，一方面是为了将 kubelet 核心主干代码与 Runtime 相关代码解耦，便于更好的维护；另一方面则是为了便于生态圈按 CRI spec 实现自己的运行时插件，提供个性化的运行时扩展能力，以满足对更多 Runtime 的支持，提高 K8s 生态的开放性和扩展性。

本文将从 Docker Engine、Kubelet 启动、Pod 创建/删除、Container 创建/删除、CRI RPC 调用等核心流程，对 CRI 实现机制进行了解析。

流程概览如下：

2. 从 Docker 说起

2.1 Docker Engine

Docker Engine 是用来运行和管理容器的核心软件。通常人们会简单地将其代指为 Docker 或 Docker 平台。

Docker Engine 主要的组件构成：Docker 客户端（Docker Client）、Docker 守护进程（Docker daemon）、Docker APIs、containerd 以及 runc，它们共同负责容器的创建和运行。

2.2 OCI

OCI（Open Container Initiative，开放容器计划），是在 2015 年由 Docker、CoreOS 等公司共同成立的项目，并由 Linux 基金会进行管理，致力于 container runtime 标准的制定和 runc 的开发等工作。所谓 container runtime，主要负责的是容器的生命周期的管理。OCI 主要分为容器运行时规范(runtime-spec) 和镜像规范(image-spec) 两部分，runtime-spec 标准对容器的创建、删除、查看、状态等操作进行了定义，image-spec 对镜像格式、打包(Bundle)、存储等进行了定义。

2.3 runc

runc，是由 Docker 贡献的对于 OCI 标准的一个参考实现，是一个可以用于创建和运行容器的 CLI(command-line interface) 工具。runc 直接与容器所依赖的 Cgroup/OS 等进行交互，负责为容器配置 Cgroup/namespace 等启动容器所需的环境，创建启动容器的相关进程。为了兼容 OCI 标准，Docker 也做了架构调整。将容器运行时相关的程序从 Docker daemon 剥离出来，形成了containerd。containerd 向 Docker 提供运行容器的 API，二者通过 gRPC 进行交互。containerd 最后会通过 runc 来实际运行容器。

3. CRI

CRI（Container Runtime Interface，容器运行时接口）是 K8s 定义的一组与容器运行时进行交互的接口，用于将 K8s 平台与特定的容器实现解耦。在 K8s 早期的版本中，对于容器环境的支持是通过 Dockershim(hard code) 方式直接调用 Docker API 的，后来为了支持更多的容器运行时和更精简的容器运行时，K8s 在遵循 OCI 基础上提出了CRI。

3.1 dockershim

dockershim 是 Kubernetes 的一个组件，主要目的是为了通过 CRI 操作 Docker。Kubernetes 在创建之初便采用Docker 作为它的默认容器进行时，后续代码当中包含了很多对 Docker 相关的操作逻辑。后期 Kubernetes 为了能够做解耦，兼容更多的容器进行时，将操作 Docker 相关逻辑整体独立起来组成了 dockershim。

2020 年，K8s 宣布弃用 dockershim，标志着容器运行时正式向 CRI 切换，以满足对更多 Runtime 的支持，提高 K8s 生态的开放性和扩展性。

3.2 CRI shim

当前实现了 CRI 的 remote shim 有如下：

  • containerd：由 Docker 公司创建，并且在 2017 年捐赠给了 CNCF，2019 年毕业。

  • CRI-O：基于 OCI 规范的作为 CRI 和 OCI 之间的一座桥梁。

  • Docker Engine：Docker 运行时的支持，由 cri-dockerd 进行实现。

  • Mirantis Container Runtime：Docker 企业版(Enterprise Edition) 运行时的支持，由 Mirantis Container Runtime(MCR) 进行实现。

CRI shim 小结如下：

3.3 RuntimeClass

RuntimeClass 是 v1.12 引入的新 API 对象，用来支持多个容器运行时，可通过 Pod 字段直接指定。 定义一个 RuntimeClass 如下，对应的 CRI handler 即为目标容器运行时，比如 containerd、crio：

apiVersion: node.k8s.io/v1  # RuntimeClass is defined in the node.k8s.io API group
kind: RuntimeClass
metadata:name: myclass  # The name the RuntimeClass will be referenced by# RuntimeClass is a non-namespaced resource
handler: myconfiguration  # The name of the corresponding CRI configuration

在 Pod 中直接指定对应的 runtimeClassName 即可：

apiVersion: v1
kind: Pod
metadata:name: mypod
spec:runtimeClassName: myclass# ...

4. Kubelet 启动

kubelet 在 Node 节点上负责 Pod 的创建、销毁、监控上报等核心流程，通过 Cobra 命令行解析参数启动二进制可执行文件。

启动入口如下：

// kubernetes/cmd/kubelet/kubelet.go
func main() {command := app.NewKubeletCommand()// kubelet uses a config file and does its own special// parsing of flags and that config file. It initializes// logging after it is done with that. Therefore it does// not use cli.Run like other, simpler commands.code := run(command)os.Exit(code)
}

接着，一路往下进行初始化：

cmd -> Run -> PreInitRuntimeService -> RunKubelet -> createAndInitKubelet -> startKubelet -> Run

其中 PreInitRuntimeService 会进一步初始化 CRI shim，分别初始化 RuntimeService、ImageService 对容器运行时和镜像生命周期进行管理；然后启动 gRPC CRI server 监听 client 请求，进行具体的操作如 PodSandbox、Container 创建与删除。

kubelet 启动后，会负责：

  • Pod、Volume 事件的监听，创建/删除对应的 Pod/Volume；

  • Node 资源监控与更新、Pod 健康探测(Probe) 及上报；

  • 当 Node 资源紧张时，还负责 Pod Preemption(抢占) 与 Eviction(驱逐)；

  • Metrics 监控采集、Image/Container GC 工作等；

其中，Pod 事件流程图请看上面概述中的流程概览图。

5. Pod 创建/删除

K8s 中 Pod 的调谐采用 channel 生产者-消费者模型实现，具体通过 PLEG(Pod Lifecycle Event Generator) 进行 Pod 生命周期事件管理。

// kubernetes/pkg/kubelet/pleg/pleg.go
// 通过 PLEG 进行 Pod 生命周期事件管理
type PodLifecycleEventGenerator interface {Start() // 通过 relist 获取所有 Pods 并计算事件类型Watch() chan *PodLifecycleEvent // 监听 eventChannel，传递给下游消费者Healthy() (bool, error)
}

Pod 事件生产者(producer) - 相关代码：

// kubernetes/pkg/kubelet/pleg/generic.go
// 生产者：获取所有 Pods 列表，计算出对应的事件类型，进行 Sync
func (g *GenericPLEG) relist() {klog.V(5).InfoS("GenericPLEG: Relisting")...// 获取当前所有 Pods 列表podList, err := g.runtime.GetPods(true)if err != nil {klog.ErrorS(err, "GenericPLEG: Unable to retrieve pods")return}for pid := range g.podRecords {allContainers := getContainersFromPods(oldPod, pod)for _, container := range allContainers {// 计算事件类型：running/exited/unknown/non-existentevents := computeEvents(oldPod, pod, &amp;container.ID)for _, e := range events {updateEvents(eventsByPodID, e)}}}// 遍历所有事件for pid, events := range eventsByPodID {for i := range events {// Filter out events that are not reliable and no other components use yet.if events[i].Type == ContainerChanged {continue}select {case g.eventChannel <- events[i]: // 生产者：发送到事件 channel，对应监听的 goroutine 会消费default:metrics.PLEGDiscardEvents.Inc()klog.ErrorS(nil, "Event channel is full, discard this relist() cycle event")}}}...
}

Pod 事件消费者(Consumer) - 相关代码：

// kubernetes/pkg/kubelet/kubelet.go
// 消费者：根据 channel 获取的各类事件，进行 Pod Sync
func (kl *Kubelet) syncLoopIteration(configCh <-chan kubetypes.PodUpdate, handler SyncHandler,syncCh <-chan time.Time, housekeepingCh <-chan time.Time, plegCh <-chan *pleg.PodLifecycleEvent) bool {select {...// 消费者：监听 plegCh 的事件case e := <-plegCh:if e.Type == pleg.ContainerStarted {// 更新容器的最后启动时间kl.lastContainerStartedTime.Add(e.ID, time.Now())}if isSyncPodWorthy(e) {if pod, ok := kl.podManager.GetPodByUID(e.ID); ok {klog.V(2).InfoS("SyncLoop (PLEG): event for pod", "pod", klog.KObj(pod), "event", e)// 进行相关 Pod 事件的 Synchandler.HandlePodSyncs([]*v1.Pod{pod})} else {// If the pod no longer exists, ignore the event.klog.V(4).InfoS("SyncLoop (PLEG): pod does not exist, ignore irrelevant event", "event", e)}}// 容器销毁事件处理：清除 Pod 内相关 Containerif e.Type == pleg.ContainerDied {if containerID, ok := e.Data.(string); ok {kl.cleanUpContainersInPod(e.ID, containerID)}}...}return true
}

当 kubelet 监听到 Pod 事件时，进行对应 Pod 的创建或删除，流程如下：

kubelet -> Run -> syncLoop -> SyncPodCreate/Kill -> UpdatePod -> syncPod/syncTerminatingPod -> dockershim gRPC -> Pod running/teminated

6. Container 创建/删除

当 Pod-Sandbox 创建出来以后，首先会创建基础容器 (infra-container，也叫 pause 容器)，通过 CNI 机制 配置 Pod 网络环境，创建临时数据目录(存放 container logs)，为下一步 Container 创建做好相关准备工作。

Container 目前分为三种类型：

  • Ephemeral Container：临时容器，用于 debug 及排障所需的一次性容器。

  • Init Container：初始化容器，在正常业务容器之前、按序启动，一般做一些准备工作。

  • Regular Container：普通业务容器，应用使用的主容器。

创建 Container 的过程主要有：

PullImage -> CreateContainer -> StartContainer -> PostStartHook -> Container running

当 Pod 内所有 Container 都已创建（created） && 都已启动（started） && 至少有一个容器在运行中（running），Pod-phase 更新为 Running，表示 Pod 正常运行。

Pod-Container 创建流程小结如下：

7. CRI RPC 接口

CRI 标准规范接口，包含了 ImageService、RuntimeService 两方面的接口：

  • ImageService：管理镜像的查询、拉取、删除、统计等操作；

  • RuntimeService：管理 PodSandbox 和容器的生命周期，包括查询、创建、启动、删除、统计等操作，另外还提供版本(Version)、执行命令(Exec)、端口转发(PortForward) 等接口能力；

可以看到，用户只要按照 CRI RPC 接口规范进行具体实现，就可以实现自己的 Runtime 插件，提高了 K8s 生态的高扩展性与灵活性。

8. 小结

本文通过分析 K8s 中 Kubelet 启动、Pod 创建/删除、Container 创建/删除、CRI RPC 调用等核心流程，对 K8s CRI 实现机制进行了解析。通过源码、图文方式说明了相关流程逻辑，以期更好的理解 K8s CRI 实现细节。

K8s CRI 经历了从 in-tree Dockershim 到 CRI remote-shim(out-of-tree) 的 迁移，一方面是为了将 kubelet 核心主干代码与 Runtime 相关代码解耦，便于更好维护；另一方面则是为了便于生态圈按 CRI spec 实现自己的运行时插件，提供个性化的运行时扩展能力，以期达到容器生态圈的开放共赢。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/841632.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

入门Kotlin的学习之路经验总结

入门Kotlin的学习之路经验总结

书籍的话就推荐三本书&#xff0c;分别是【Kotlin实战】&#xff0c;【Kotlin核心编程】、【Kotlin编程实践】。这三本书个人认为理解和学习的难易程度由低到高。如果你是入门Kotlin&#xff08;首先掌握基础&#xff09;&#xff0c;强烈推荐【Kotlin实战】这本书&#xff0c;…
阅读更多...
八种单例模式

八种单例模式

文章目录 1.单例模式基本介绍1.介绍2.单例模式八种方式 2.饿汉式&#xff08;静态常量&#xff0c;推荐&#xff09;1.基本步骤1.构造器私有化&#xff08;防止new&#xff09;2.类的内部创建对象3.向外暴露一个静态的公共方法 2.代码实现3.优缺点分析 3.饿汉式&#xff08;静态…
阅读更多...
C#基础语言

C#基础语言

​​​​ 目录 一个c# 程序主要包括以下部分&#xff1a;​​​​​​​ 标识符 C# 关键字 C# 数据类型 值类型&#xff08;Value types&#xff09; 引用类型&#xff08;Reference types&#xff09; 对象&#xff08;Object&#xff09;类型 动态&#xff08;Dynam…
阅读更多...
Python应用实战，用动画生成冒泡排序的过程

Python应用实战，用动画生成冒泡排序的过程

写在前言 hello&#xff0c;大家好&#xff0c;我是一点&#xff0c;专注于Python编程&#xff0c;如果你也对感Python感兴趣&#xff0c;欢迎关注交流。 希望可以持续更新一些有意思的文章&#xff0c;如果觉得还不错&#xff0c;欢迎点赞关注&#xff0c;有啥想说的&#x…
阅读更多...
网络通信--demo--群聊

网络通信--demo--群聊

群聊实现的关键&#xff1a; 群聊的思想&#xff1a;客户端发送消息后&#xff0c;所有客户端都可以接收到 客户端---->服务端&#xff08;子&#xff09;---->客户端&#xff08;online&#xff09; online的客户端&#xff1a;需要一个集合存储 package Wechat;imp…
阅读更多...
牛客NC222 插入区间【中等 数组，区间合并问题 Java/Go/PHP/C++】lintcode30 插入区间

牛客NC222 插入区间【中等 数组，区间合并问题 Java/Go/PHP/C++】lintcode30 插入区间

题目 题目链接&#xff1a; https://www.nowcoder.com/practice/1d784b5472ab4dde88ea2331d16ee909 https://www.lintcode.com/problem/30/solution/56586 思路 Java代码 import java.util.*;/** public class Interval {* int start;* int end;* public Interval(int …
阅读更多...
Julia编程08：控制流Control Flow

Julia编程08：控制流Control Flow

Julia provides a variety of control flow constructs: Compound Expressions: begin and ;. Conditional Evaluation: if-elseif-else and ?: (ternary operator). Short-Circuit Evaluation: logical operators && (“and”) and || (“or”), and also chained …
阅读更多...
【代码随想录训练营】【Day 32】【回溯-6】【待二刷】| Leetcode 332, 51, 37

【代码随想录训练营】【Day 32】【回溯-6】【待二刷】| Leetcode 332, 51, 37

【代码随想录训练营】【Day 32】【回溯-6】【待二刷】| Leetcode 332, 51, 37 需强化知识点 滑动窗口&#xff0c;固定结束位置版本螺旋数组&#xff0c;建模为编程问题 题目 332. 重新安排行程 sort reverse的用法&#xff0c;以及result.append(airport)的理解 from co…
阅读更多...
i2c总线介绍

i2c总线介绍

1. 简介 1.1 I2C总线的历史背景 I2C&#xff08;Inter-Integrated Circuit&#xff09;总线最初由Philips Semiconductors&#xff08;现NXP Semiconductors&#xff09;在1980年代开发&#xff0c;旨在简化集成电路之间的通信。随着技术的发展&#xff0c;I2C已经成为一种广…
阅读更多...
【数据结构】哈希表的原理及其实现

【数据结构】哈希表的原理及其实现

文章目录 哈希表的概念哈希函数的设计常见的哈希函数 哈希冲突1. 闭散列代码实现 2. 开散列拉链法的优点 针对开散列哈希的扩展基于开散列拉链法封装哈希表MyHash.h 基于哈希表实现unordered_map类Myunordered_map.h 基于哈希表实现unordered_set类Myunordered_map.h 哈希表的概…
阅读更多...
匠心独运的掺Si量子势垒策略，显著提升了AlGaN基深紫外LED出光率

匠心独运的掺Si量子势垒策略，显著提升了AlGaN基深紫外LED出光率

WHU团队凭借匠心独运的三明治式掺Si量子势垒策略&#xff0c;显著提升了AlGaN基深紫外光LED的效率&#xff0c;这一创新成果为中国武汉大学的研究团队所取得。他们巧妙地设计出一种三明治状Si掺杂&#xff08;未掺杂&#xff09;方案&#xff0c;应用于Al0.6Ga0.4N量子势垒中&a…
阅读更多...
WSL安装CentOS系统

WSL安装CentOS系统

1.首选找一个linux系统&#xff0c;执行docker命令 docker run -it --rm centos:7 bash 2.开一个新窗口&#xff0c;将系统导出 docker export e0ee25406703 -o centos.tar 3.切换到wsl命令&#xff0c;导入tar包 wsl --import centos D:\wsl\centos D:\wsl\centos.tar cen…
阅读更多...
llvm实践日志(1)---安装llvm

llvm实践日志(1)---安装llvm

参考了官方教程&#xff1a;Getting Started with the LLVM System — LLVM 19.0.0git documentation 首先从github拷贝一份源码&#xff0c;使用了官方推荐的方法&#xff1a; git clone --depth 1 https://github.com/llvm/llvm-project.git 我的系统是ubuntu22&#xff0…
阅读更多...
人工智能安全方面存在哪些问题

人工智能安全方面存在哪些问题

人工智能的安全方面存在多个问题&#xff0c;这些问题可以归纳为以下几个方面&#xff1a; 一、网络安全问题 数据泄露风险&#xff1a;人工智能系统依赖于大量数据进行学习和推理&#xff0c;这些数据可能包含敏感信息&#xff0c;如用户隐私、商业机密等。如果系统存在安全…
阅读更多...
Java面试题： 解释一下Java中的Happens-Before规则。

Java面试题： 解释一下Java中的Happens-Before规则。

Java中的Happens-Before规则是Java内存模型&#xff08;Java Memory Model, JMM&#xff09;的核心概念之一&#xff0c;它定义了多线程环境中操作之间的内存可见性关系。这些规则确保了在并发执行的线程之间&#xff0c;对共享数据的访问能够保持正确的顺序和可见性。 Happen…
阅读更多...
3. CSS的色彩与背景

3. CSS的色彩与背景

3.1 CSS3中的色彩 CSS3扩展了颜色的定义方式&#xff0c;使得开发者能够使用更多样化和灵活的颜色表达方式。这包括RGB、RGBA、HSL、HSLA等格式&#xff0c;以及支持透明度和渐变的特性。 3.1.1 颜色格式 十六进制颜色 十六进制颜色是最常用的颜色表示法&#xff0c;以#开头…
阅读更多...
queue学习

queue学习

std::queue 类是一种容器适配器&#xff0c;它提供队列的功能——尤其是 FIFO&#xff08;先进先出&#xff09;数据结构。此类模板用处为底层容器的包装器——只提供特定的函数集合。queue 在底层容器尾端推入元素&#xff0c;从首端弹出元素。 元素访问 front 访问第一个元素…
阅读更多...
20240526每日后端---------分享一些开发必备网站

20240526每日后端---------分享一些开发必备网站

代码开发工具: https://www.matools.com/ 前端开发网站&#xff1a; https://ui.bqrdh.com/#google_vignette 后端开发网站&#xff1a; https://javaguide.cn/ 设计模式分析&#xff1a; https://refactoringguru.cn/design-patterns/catalog
阅读更多...
Elastic Cloud 将 Elasticsearch 向量数据库优化配置文件添加到 Microsoft Azure

Elastic Cloud 将 Elasticsearch 向量数据库优化配置文件添加到 Microsoft Azure

作者&#xff1a;来自 Elastic Serena Chou, Jeff Vestal, Yuvraj Gupta 今天&#xff0c;我们很高兴地宣布&#xff0c;我们的 Elastic Cloud Vector Search 优化硬件配置文件现已可供 Elastic Cloud on Microsoft Azure 用户使用。 此硬件配置文件针对使用 Elasticsearch 作…
阅读更多...
web如何做接口层面自动化测试？

web如何做接口层面自动化测试？

接口层面约等于集成化测试&#xff0c;且需要启动web容器 一般web项目的&#xff0c;代码都是按照分层开发的&#xff0c;业务主要是集中在service和dao层&#xff0c;而我们如果仅仅是利用之前的单元测试,然后把依赖的代码直接mock掉&#xff0c;仅仅测试controller这一块是没…
阅读更多...
最新文章

Copyright @ 2022~2023