社交网站的优点和缺点,网页关键词排名优化,装修设计网站排行榜,二手交易网站建设方案ppt目录
一、理论
1.容器运行时
2.容器运行时接口 3.容器运行时层级
4.容器运行时比较
5.强隔离容器
二、问题
1.K8S为何难以实现真正的多租户
三、总结 一、理论
1.容器运行时
#xff08;1#xff09;概念
Container Runtime 是运行于 k8s 集群每个节点中#xff…目录
一、理论
1.容器运行时
2.容器运行时接口 3.容器运行时层级
4.容器运行时比较
5.强隔离容器
二、问题
1.K8S为何难以实现真正的多租户
三、总结 一、理论
1.容器运行时
1概念
Container Runtime 是运行于 k8s 集群每个节点中负责容器的整个生命周期。Docker 就目前来说是应用最为广泛的。随着容器云的发展涌现了很多容器运行时。Google 为了将 kubelet 和特定的容器运行时解耦主要还是为了干掉 Docker于是推出了 CRI容器运行时接口。
2.容器运行时接口
CRI 是 k8s 定义的一组 gRPC 服务。kubelet 作为客户端基于 gRPC 框架通过 Socket 和容器运行时通信。CRI 包括两类服务镜像服务Image Service和运行时服务Runtime Service。镜像服务提供下载、检查和删除镜像的远程程序调用。运行时服务用于管理容器的生命周期以及和容器交互的调用exec / attach / port-forward。 3.容器运行时层级
Container Runtime 分为高低两个层级。
1 高层级运行时 Dockershim、containerd 和 CRI-O 都是遵循 CRI 的容器运行时属于高层级运行时主要是面向外部提供 gRPC 调用。
注意这里是 Dockershim并不是 DockerDocker 至今也没有遵循 CRI。
OCI OCIOPen Container Initiative定义了创建容器的格式和运行时的开源行业标准包括镜像规范和运行时规范。
高层级运行时会下载一个 OCI 镜像并把它解压成 OCI 运行时文件系统包filesystem bundle。
2低层级运行时 低层级运行时定义如何为新容器设置 Linux namespaces 和 cgroups以及 rootfs 等操作 runC 就是具体的参考实现。除了 runC 外还有很多其他的运行时遵循 OCI 标准例如 kata 以及 gVisor。
4.容器运行时比较 Docker 的多层封装和调用导致其在可维护性上略逊一筹。containerd 和 CRI-O 的方案比 Docker 简洁很多。 dockershim 遵循 CRI并把请求转为 dockerd 可处理的请求其代码集成在 kubelet 中这也是 k8s 急于摆脱 Docker 的原因之一。
真正的启动容器是通过 containerd-shim 去调用 runC 来启动容器的runC 启动完成后会直接退出containerd-shim 会成为容器进程的父进程负责收集容器进程的状态上报给 containerd并在容器中 pid 为 1 的进程退出后接管容器中的子进程确保不会出现僵尸进程。同时也避免了宿主机上 containerd 进程挂掉的话所有容器进程都退出。
1 containerd 和 Docker 细节差异 Docker 作为容器运行时k8s 其实根本没有使用 docker 本身的存储、网络等功能只是用了 Docker 的 Image 功能来满足 CRI 中的镜像服务。
2containerd 和 CRI-O
CRI-O是由红帽发起并开源的一款容器运行时本身比较新没有太多的生产实践。而且在社区的测试结果中在操作容器方面的性能以及延时都没有 containerd 优秀。 5.强隔离容器
1常用强隔离容器
Kata, gVisor, firecracker
2安全容器与 Serverless
Serverless 要做到所有的用户容器或函数按需使用计算资源, 那必须满足两点:
多租户强隔离: 用户的容器或函数都是按需启动按秒计费, 我们可不能给每个用户预先分配一坨隔离的资源,因此我们要保证整个 Platform 是多租户强隔离的;
极度轻量: Serverless 的第一个特点是运行时沙箱会更频繁地创建和销毁, 第二个特点是切分的粒度会非常非常细, 细中细就是 FaaS, 一个函数就要一个沙箱。 因此就要求两点: 1. 沙箱启动删除必须飞快; 2. 沙箱占用的资源越少越好。
3Kata Containers
① 概念
Kata Containers作为OpenStack基金会的一个开放源代码项目作为其最近扩展的包含OpenStack核心项目的章程的一部分。这个项目肯定会促进标准化和创新从而推动容器技术的快速发展。已经有将近20家公司同意在Kata Containers上共同合作。
Kata容器也将在多个基础架构和容器编排和规范社区中集成和兼容KubernetesDockerOpen Container InitiativeOCIContainer Runtime InterfaceCRI容器网络接口CNIQEMUKVMHyperV和OpenStack。
② 特点
容器的速度虚拟机的安全。
Kata 的一张图很好地解释了基于虚拟机的容器与基于 namespaces 和 cgroups 的容器间的区别: Kata Containers是一种轻量级虚拟机的新颖实现无缝集成在容器生态系统中。Kata Containers同容器一样轻而快并与容器结合管理层同时也提供了虚拟机的安全优势。
Kata Containers是两个现有的开源项目合并英特尔Clear Containers和Hyper runV。新项目汇集了最好的这两种技术都具有重构虚拟化容器原生应用程序的共同愿景为了提供容器的速度和虚拟机的安全。 Kata Containers从每个项目的优势中受益。Intel Clear Containers专注于性能100ms启动时间和增强安全性而hyper runV优先于技术无关支持许多不同的CPU架构和管理程序。通过合并这些项目Clear Containers提供了卓越的最终用户体验性能和兼容性统一开发者社区并加速功能开发以解决未来的使用案例。
行业转向容器在安全方面提出了独特的挑战用户工作负载在多租户不受信任的环境中。Kata Containers使用开源虚拟机管理程序作为每个容器的隔离边界或一个容器中的容器的集合;这种方法解决了与现有的裸机容器解决方案共同的内核困境。
Kata Containers是非常适合按需基于事件的部署如无服务器功能连续整合/持续交付以及更长时间运行的Web服务器应用。开发者不再需要知道任何事情下面的基础或执行任何类型的容量规划之前启动他们的容器工作量。Kata Containers交付增强安全性可扩展性和更高的资源利用率同时导致整体简化的堆栈。 二、问题
1.K8S为何难以实现真正的多租户
1问题
k8s 做不到多租户状态, 其中最大的两个原因是:
1.kube-apiserver 是整个集群中的单例, 并且没有多租户概念2.默认的 oci-runtime 是 runC, 而 runC 启动的容器是共享内核的。 (2) 原因
理想的多租户状态:
理想来说, 平台的各个租户(tenant)之间应该无法感受到彼此的存在, 表现得就像每个租户独占这整个平台一样. 具体来说, 我不能看到其它租户的资源, 我的资源跑满了不能影响其它租户的资源使用, 我也无法从网络或内核上攻击其它租户。
3解决方法
对于第二个问题, 一个典型的解决方案就是提供一个新的 OCI 实现, 用 VM 来跑容器, 实现内核上的硬隔离。 runV 和 Clear Containers 都是这个思路. 因为这两个项目做得事情是很类似, 后来就合并成了一个项目 Kata Container。 三、总结
runtime容器运行时 高层级运行时Dockershim、containerd 和 CRI-O 主要是面向外部提供 gRPC 调用。 低层级运行时runC、kata和gVisor 定义如何为新容器设置 Linux namespaces 和 cgroups以及 rootfs 等操作。
