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

一、容器发展历程：

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

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

1. 一切皆视为资源，不同资源之间依靠层级关系互相组合和协作。
2. 由控制器控制资源的状态。（反馈控制）

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

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