网站整体运营,网站开发付款方式和比例,网站的第二域名怎么用,短视频矩阵seo系统源码写在前面 博文内容整体结构为结合 华为云云原生课程 整理而来,部分内容做了补充课程是免费的#xff0c;有华为云账户就可以看#xff0c;适合理论认知#xff0c;感觉很不错。有需要的小伙伴可以看看#xff0c;链接在文末理解不足小伙伴帮忙指正 对每个人而言#xff0c…写在前面 博文内容整体结构为结合 华为云云原生课程 整理而来,部分内容做了补充课程是免费的有华为云账户就可以看适合理论认知感觉很不错。有需要的小伙伴可以看看链接在文末理解不足小伙伴帮忙指正 对每个人而言真正的职责只有一个找到自我。然后在心中坚守其一生全心全意永不停息。所有其它的路都是不完整的是人的逃避方式是对大众理想的懦弱回归是随波逐流是对内心的恐惧 ——赫尔曼·黑塞《德米安》 为什么从 CRI 讲起因为 k8s 集群使用 kubelet 服务通过 CRI 接口和对应的 runtime(运行时) 交互从而控制管理容器。
那 CRI 是什么 CRI 是一个 Kubernetes API它定义了 Kubernetes 与不同容器运行时交互的方式。因为它在规范中是标准化的所以可以选择要使用的 CRI 实现或编写自己的实现。 CRI
在 K8s 生态中通过 CRI 接口来对 容器运行时进行管理从而实现对容器镜像的管理具体一点通过 kubelet 调用容器运行时的 grpc 接口。
面向接口编程类比在刚学编程时 Java 中操作数据库使用 JDBC API 来连接不同的数据库实现 CRUD这里具体的数据操作通过不同数据库的驱动包来实现。CRI可以单纯理解为JDBC ,CRI 实现类比不同的数据库驱动包 对于 CRI 接口有下面的一些实现。
dockershim: 由于 docker 没有实现 CRI 接口所以 kubernetes 在最初对接 docker api的时候提供了 CRI接口适配器, 但是这是一种冗余的行为k8s 只是需要 docker 中的 containerd,完全可以直接使用 containerd,所以在之后版本中删除了这部分代码, 在 kubernetes 1.21 版本已经将其标注为废弃接口。在 1.24 版本中彻底移除了该部分代码, 不过 如果任然想使用 docker ,可以使用开源项目 cri-docker 来代替。在部署时需要单独指定 socket。 docker 的前置依赖可以看到它依赖 containerd.service
┌──[rootvms100.liruilongs.github.io]-[~/ansible/openkruise]
└─$systemctl list-dependencies docker | head -n 3
docker.service
● ├─containerd.service
● ├─docker.socketCRI-containerd基于 containerd 的 CRI 兼容插件通过 containerd 中的 CRI插件实现了CRI接口当前使用最广泛的 CRI接口接口实现。性能好,功能全,适合需要利用 containerd 强大功能的场景。
CRI-O专注于在 kubernetes 运行容器的轻量级 CRl 接口实现(不关注开发态)CRI-O 是基于 Open Container Initiative (OCI) 标准开发的独立容器管理引擎,独立性好,适合注重兼容性和移植性的场景
CRI 接口由两部分组成
CRI 接口由两部分组成:
通过 RuntimeServiceServer 属性来描述管理容器生命周期的相关行为包括创建、删除、启动、停止等容器操作,通过 ImageServiceServer 属性来描述管理镜像相关的行为,如拉取、推送镜像等操作。
通过对这两个行为接口委托实现 CRI 接口具体来说:
RuntimeServiceServer定义了管理容器生命周期需要调用的通用方法,如CreateContainer、StartContainer、StopContainer等。这些方法主要用于管理容器运行时状态。ImageServiceServer定义了镜像管理需要调用的通用方法,如ListImages、PullImage、RemoveImage等。这些方法主要用于管理容器镜像资源。
type grpcServices interface {runtime.RuntimeServiceServer runtime.ImageServiceServer
}运行时负责容器的生命周期管理包括容器创建启动、停止、日志和性能采集等接口。镜像负责容器镜像的管理包括显示镜像、拉取镜像、删除镜像等接口。
在早期的CRI实现中Shimv1是最常见的容器运行时接口实现之一。它通过创建一个额外的代理进程Shim来管理容器的生命周期并与容器运行时进行通信。然而Shimv1存在一些性能和可靠性方面的限制。
为了改进CRI的性能和稳定性Shimv2被引入作为CRI的改进版本。
CRI Shimv2
Shimv2使用了ttrpcTiny Transport Protocol RPC作为通信协议通过与容器运行时直接通信而无需创建额外的代理进程。这种直接的通信方式可以提供更高效、更可靠的容器运行时接口。 OCI
CRI 接口实现和容器运行时交互这里就要讲到 OCI
OCI 组织Linux基金会于2015年6月成立OCI(Open Container Initiative)组织旨在围绕容器格式和运行时制定一个开放的工业化标准。 目前主要有两个标准文档容器运行时标准(runtime spec)和容器镜像标准(image spec)
Runtime spec容器运行时标准定义了容器状态和配置文件格式容器生命周期管理命令格式和参数等。
image spec镜像标准包定义了容器镜像的文件系统、config 文件、manifest 文件、index 文件等。
容器标准中包含
容器命令容器生命周期管理命令、包括创建、启动、停止、删除等。
#runc create container id
#runc start container id#runc state container id
#runc kill container-idsignal
#runc delete container-idconfig.json文件是OCI(Open Container Initiative)规范定义的容器配置文件,它定义了容器运行时需要了解和使用的所有配置信息。
rootfs:容器内部文件系统挂载点信息mounts:容器内外部挂载的文件系统信息process:容器内第一个进程(pid1)的设置,如cmd、args等cgroups:容器要加入的cgroup信息namespaces:容器所在的namespace,比如pid、network等caps:容器能使用的Linux capabilitiesannotations 等其它配置
主流的容器运行时
这里需要说明一下我们常讲的 容器运行时是一个 混合概念包含低级别容器运行时和高级别容器运行时
低级容器运行时,比如runc、lxc、gVisor、Kata容器等,它们主要负责真正与内核进行交互,创建和管理容器运行时的内核级别资源,如cgroups、namespaces等。但无法直接管理镜像。
高级容器运行时,比如Docker引擎、Podman、containerd 等,它们基于低级容器运行时提供了更高层次的管理能力,可以管理容器生命周期并直接调用低级运行时,同时也内置镜像管理能力,能够拉取、推送镜像等。
两者关系是,高级运行时对低级运行时进行抽象,向上提供完整的容器管理接口。高级运行时在内部会调用对应的低级运行时来管理内核级资源和运行容器。
runc
runc: docker 捐献给 OCI 社区的一个 runtime spec 的参考实现docker 容器也是基于 runc 创建的。 利用 Linux 内核特性来隔离进程
Namespace资源和信息的可见性隔离通过namespace隔离容器中的应用只能看到分配到该容器的资源、其他主机上的信息在容器中不可见。常用的namespace有PID(进程号)、MNT(挂载点)、NET(网络)、UTS(主机名)和IPC(跨进程通信)等Cgroups资源使用量的隔离通过cgroup、限制了容器使用的资源量通过不同的子系统限制不同的资源。包括CPU、内存、io带宽、大页、fd 数等等Capability权限限制(最低特权原则)Capability是Linux系统设计的一种安全机制。它定义了一组特权标记,可以细粒度控制进程对系统资源的访问权限通过对进程的capability定义限制容器中的进程调用某些系统调用以达到容器进程无法逃逸到主机的目的比如容器中的进程是不具有以下capability的 SYS ADMIN/MKNOD/SYS RESOURCE/SYS MODULES.…
容器主进程 1 1898 1898 1034 ? -1 Sl 0 0:34 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 057fb1898 1957 1957 1957 ? -1 Ss 65535 0:00 \_ /pause1 2013 2013 1034 ? -1 Sl 0 2:58 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 7d1672013 2080 2080 2080 ? -1 Ss 0 0:17 \_ haproxy -W -db -f /usr/local/etc/haproxy/haproxy.cfg2080 2133 2080 2080 ? -1 Sl 0 48:48 \_ haproxy -W -db -f /usr/local/etc/haproxy/haproxy.cKata-runtime Kata-runtime一种基于 虚拟化 的安全隔离的 OCI runtime spec 的实现。
虚拟化隔离每个pod都运行在一个独立的虚拟机中提供虚拟化接口对接不同的虚拟化实现包括qemu、cloud hypervisor、firecracker 等等轻量化为了达到和容器近似的使用体验需要对各组件进行裁剪达到轻量化和启动加速的目的对于hypervisor去除通用虚拟化的各种不必要的设备、总线等。对于guestkernel也裁剪了大量不需要的驱动和文件系统模块。而运行在虚拟机中的1号进程(一般为kata-agent)资源占用可小于1MB。主机资源访问通过virtio、vfio等方式访问主机资源如virtio-blk(块设备)、virtio-fs(文件)、virtio-net(网络)、vfio(物理设备)、vhost-user(用户态网络或存储)
gVisor
gVisor是Google开源的一款安全容器运行时,它使用了系统调用拦截(System call filtering)这一技术来实现容器安全隔离。
gVisor通过内核模块注入方式,在用户空间和内核空间之间插入一个中间层。这个中间层对所有从容器发起的系统调用请求进行拦截和filtering。根据预先定义的安全策略,选择性通过或拒绝这些系统调用请求,限制容器对内核资源的访问。
通过这种方式:
gVisor无需真正virtualize内核功能,性能开销小。但能实现丰富的安全隔离,如文件系统读写限制、网络隔离等。
所以总体来说,gVisor采用轻量级的系统调用过滤技术,在不影响性能的情况下,有效地隔离和限制容器对系统资源的访问,从而有效提升容器安全性。 虚拟内核设置进程的4种模式HRO、HR3、GRO、GR3通过拦截系统调用实现了一个虚拟内核用户进程与host kernel不直接交互拦截系统调用的方式ptrace、kvm优点额外内存消耗小容器启动速度快缺点系统调用慢导致I0、网络等性能差由于是模拟内核有POSIX兼容性问题
知道了CRI,OCI,可能会有这样一个疑问容器运行时(runtime)是如何和 Pod 关联起来的 这里就要讲到 RuntimeClass
RuntimeClass
RuntimeClass 是 Kubernetes 中的一个对象类型用于定义集群中的特定运行时。RuntimeClass 允许您通过指定 overhead开销和 nodeSelector节点选择器来自定义特定运行时的资源和调度行为。
RuntimeClass 的主要作用是将容器运行时与 Pod 关联起来。它定义了一组属性包括运行时名称、调度器名称、节点选择器和资源限制。通过将 Pod 的 RuntimeClassName 字段设置为特定的 RuntimeClass 名称可以指定该 Pod 使用特定的容器运行时。 使用 RuntimeClass可以针对不同的运行时场景进行资源和调度的优化。例如您可以定义一个 RuntimeClass针对 CPU 密集型任务使用资源更多的容器运行时并通过节点选择器将该 RuntimeClass 的 Pod 调度到具备较高 CPU 资源的节点上。
Runtime Plugin:containerd中的runtime插件配置定义了runtime名称、二进制路径、传递的annotation、特权容器模式等等。
关于容器引擎和运行时机制原理认知就和小伙伴们分享到这里
博文部分内容参考
文中涉及参考链接内容版权归原作者所有如有侵权请告知 https://connect.huaweicloud.com/courses/learn/learning/sp:cloudEdu_?courseNocourse-v1:HuaweiXCBUCNXI041Self-pacedcourseType1source1 © 2018-2023 liruilongergmail.com, All rights reserved. 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)
