《凤凰架构》读书笔记——第11章虚拟化容器

原创已于 2024-02-02 16:58:39 修改 · 269 阅读

CC 4.0 BY-SA版权

文章标签：

于 2024-02-02 16:58:10 首次发布

8 篇文章

订阅专栏

本文概述了容器技术的发展历程，从chroot、namespace到Docker和Kubernetes的封装，强调了Kubernetes的资源管理和反馈控制理念。同时讨论了简化Kubernetes使用的方法，如Kustomize、Helm、CRD/Operator和OAM在云原生中的角色。

一、容器发展历程：

源于chroot、namespace和cgroups等内核能力，LXC在此基础上做了封装，Docker又在LXC上做了封装，Kubernetes又在Docker之上做了封装。（Docker和Kubernetes后来直接访问底层能力了，例如Kubernetes为了减少这种层次调用，直接绕过Docker，使用更底层的能力Container）

二、Kubernetes的两大核心设计理念：

三、Kubernetes学习和使用还是很复杂的，因此未来云原生的方向是简化使用。有4个方向：

Kubernetes官方的Kustomize，通过基于一个基准配置，开发人员和运维人员分配在不同阶段对配置内容进行覆盖和扩展。但是功能仅限于安装部署，且仅减少了重复配置工作。
Helm与Chart，模仿Linux包管理器的思路去管理Kubernetes应用。但无法很好地管理有状态的应用。
Operator与CRD，通过为CR（自定义资源）开发Operator（控制器），实现将复杂的配置封装在资源和控制器的定义中，用户只需要简单的配置就可以应用该资源。这些控制器一般由资源（软件）厂商开发。这种方式很符合Kubernetes的设计理念。
开放应用模型（OAM），由阿里云和微软发布，基本思想是把配置进行拆解，开发和运维分别负责不同的配置（Component和Trait），基础设施提供方负责将自定义资源映射到实际的基础设施。我觉得这个思想跟Kustomize有点像，不同的是OAM涉及到对云基础设施的考量。