深入剖析 Kubernetes
张磊
Kubernetes 社区资深成员与项目维护者
116705 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 57 讲
再谈开源与社区 (1讲)
结束语 (1讲)
深入剖析 Kubernetes
15
15
1.0x
00:00/00:00
登录|注册

09 | 从容器到容器云:谈谈Kubernetes的本质

Master节点和Node节点
提供运维能力
运行应用的容器镜像
编排、调度、容器云、集群管理
网络插件和存储插件
Device Plugin
CRI
kubelet
Etcd
kube-controller-manager
kube-scheduler
kube-apiserver
Borg系统
Borg论文
使用YAML文件描述任务
描述容器化业务和容器间关系的设计思想
其他对象
Secret
Service
Pod
Kubernetes的架构
用户期望
问题
计算节点
Master节点
理论基础
由Namespace+Cgroups构成的隔离环境
一组联合挂载在/var/lib/docker/aufs/mnt上的rootfs
无法管理“有状态”容器的原因
Docker Swarm和Kubernetes的异同
Kubernetes项目的价值
Kubernetes项目的本质
Kubernetes项目的架构
容器的核心知识
容器化任务的启动
声明式API
容器间关系
顶层设计
设计与架构
容器编排技术的重要性
容器镜像的价值
作为云服务商或基础设施提供商的重要原因
容器运行时
容器镜像
由Linux Namespace、Linux Cgroups和rootfs构建的进程隔离环境
思考题
总结
Kubernetes
容器编排
容器
从容器到容器云:谈谈Kubernetes的本质

该思维导图由 AI 生成,仅供参考

你好,我是张磊。今天我和你分享的主题是:从容器到容器云,谈谈 Kubernetes 的本质。
在前面的四篇文章中,我以 Docker 项目为例,一步步剖析了 Linux 容器的具体实现方式。通过这些讲解你应该能够明白:一个“容器”,实际上是一个由 Linux Namespace、Linux Cgroups 和 rootfs 三种技术构建出来的进程的隔离环境。
从这个结构中我们不难看出,一个正在运行的 Linux 容器,其实可以被“一分为二”地看待:
一组联合挂载在 /var/lib/docker/aufs/mnt 上的 rootfs,这一部分我们称为“容器镜像”(Container Image),是容器的静态视图;
一个由 Namespace+Cgroups 构成的隔离环境,这一部分我们称为“容器运行时”(Container Runtime),是容器的动态视图。
更进一步地说,作为一名开发者,我并不关心容器运行时的差异。因为,在整个“开发 - 测试 - 发布”的流程中,真正承载着容器信息进行传递的,是容器镜像,而不是容器运行时。
这个重要假设,正是容器技术圈在 Docker 项目成功后不久,就迅速走向了“容器编排”这个“上层建筑”的主要原因:作为一家云服务商或者基础设施提供商,我只要能够将用户提交的 Docker 镜像以容器的方式运行起来,就能成为这个非常热闹的容器生态图上的一个承载点,从而将整个容器技术栈上的价值,沉淀在我的这个节点上。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Kubernetes: 强大的容器编排工具 Kubernetes是一个受Google Borg系统启发的重要容器编排工具,其架构类似于Borg系统,由Master和Node两种节点组成,分别负责控制和计算。Kubernetes通过实现CRI接口,可以与不同的容器运行时进行交互,同时还支持网络插件和存储插件,为容器配置网络和持久化存储。Kubernetes项目的设计思想是以统一的方式来定义任务之间的各种关系,并且为将来支持更多种类的关系留有余地。它提供了一系列对象,如Pod、Job、CronJob等,来描述管理的应用,并通过Service服务、Secret对象等来处理容器间的关系和形态。Kubernetes项目的先进性与完备性使其成为基础设施领域开源项目的核心价值。 Kubernetes的核心设计理念是基于声明式API,通过定义“编排对象”和“服务对象”来实现平台级功能。使用Kubernetes启动容器化任务非常简便,只需编写一个YAML文件,定义Deployment对象并指定副本数,即可启动容器副本。这种声明式API带来了诸多好处,以及基于其实现的强大编排能力,使Kubernetes成为当今基础设施领域的重要工具。 Kubernetes项目的本质是为用户提供一个具有普遍意义的容器编排工具,同时也提供了一套基于容器构建分布式系统的基础依赖。其强大的功能和灵活的架构为容器编排和管理提供了全面的解决方案,成为了开源项目中的核心价值。 总结:Kubernetes是一个强大的容器编排工具,其架构灵感源自Google Borg系统,通过声明式API实现容器编排和管理,为用户提供了全面的解决方案。其先进性与完备性使其成为基础设施领域开源项目的核心价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入剖析 Kubernetes》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(143)

  • 最新
  • 精选
  • Jeff.W
    从微服务架构来讲,多个独立功能内聚的服务带来了整体的灵活性,但是同时也带来了部署运维的复杂度提升,这时Docker配合Devops带来了不少的便利(轻量、隔离、一致性、CI、CD等)解决了不少问题,再配合compose,看起来一切都很美了,为什么还需要K8s?可以试着这样理解么?把微服务理解为人,那么服务治理其实就是人之间的沟通而已,人太多了就需要生存空间和沟通方式的优化,这就需要集群和编排了。Docker Compose,swarm,可以解决少数人之间的关系,比如把手机号给你,你就可以方便的找到我,但是如果手机号变更的时候就会麻烦,人多了也会麻烦。而k8s是站在上帝视角俯视芸芸众生后的高度抽象,他看到了大概有哪些类人(组织)以及不同组织有什么样的特点(Job、CornJob、Autoscaler、StatefulSet、DaemonSet...),不同组织之间交流可能需要什么(ConfigMap,Secret...),这样比价紧密的人们在相同pod中,通过Service-不会变更的手机号,来和不同的组织进行沟通,Deployment、RC则可以帮组人们快速构建组织。Dokcer 后出的swarm mode,有类似的视角抽象(比如Service),不过相对来说并不完善。以上,是否可以这样理解?

    作者回复: 没毛病

    2018-09-16
    9
    507
  • Tigerfive
    感觉不能迁移“有状态”的容器,是因为迁移的是容器的rootfs,但是一些动态视图是没有办法伴随迁移一同进行迁移的。

    作者回复: 是的,到目前为止,迁移都是做不到的,只能删除后在新的节点上重新创建

    2018-09-12
    4
    116
  • Xiye
    对于第二个问题,是不是像存储在文件或者数据库里的数据还是比较好迁移,但是对于缓存,临时存储的数据是不是就不太好迁移。

    作者回复: 没错!

    2018-09-12
    2
    70
  • 盆盆
    赞,这几天一直在追更,欲罢不能😃😃 Kubelet这个词,词根let是小的意思,小猪piglet,微软PowerShell也有cmdlet,班门弄斧了,不知道对不

    作者回复: 语言大师你好

    2018-11-10
    3
    19
  • Rod
    @老师。我记得service的ip也是可变的。不变的是service name。通过kube dns解析。当然service可以绑定主机名。但是那样就不能高可用。不知道我说的对不对?

    作者回复: service vip不会变,除非你把它删了重建。通过dns解析的是headless service,它不会分配vip。

    2018-09-13
    17
  • Scott
    为什么一个node上,kubelet与Device plugin要走gRPC,这个没有CSI这样的专门中间层吗?

    作者回复: 没有,这一块的设计我后面会讲到

    2018-09-16
    2
    13
  • 骨汤鸡蛋面
    一直对CNI、CSI 有点困惑,为什么不将其纳入到container runtime/oci 的范畴?

    作者回复: 前面是paas层用的,后面是容器用的

    2018-09-13
    13
  • x
    现在docker 的Storage Driver基本都是overlay2 了,aufs快被淘汰了了吧

    作者回复: 结论太想当然了。具体哪种driver是取决于宿主机的,aufs好端端的就被你淘汰了……

    2018-11-02
    7
  • pytimer
    第二个问题: 我觉得应该是很多容器数据都是挂载在本地路径,所以没办法直接进行迁移。 如果容器的数据挂载在共享存储上,那是不是没有kubernetes也是可以迁移有状态的容器?

    作者回复: 那就要看有多少种状态需要处理啦

    2018-09-12
    2
    7
  • 龙坤
    容器OCI规范推出,那么统一规范的容器镜像都可以在不同厂商自主研发的容器运行时上运行。随着时间的推进,在容器编排上的需求,虽然有swarm和mesos的方案,但是对于一些有能力做基于容器PaaS平台的大公司,并且还有一些具有自主研发能力、野心大和具有一定PaaS平台资源的,并想借用容器赚钱的大公司,就不太乐意用这些方案(所以为什么大公司前期都迫切需要一个容器规范出现的原因吧)。这时也迫切需要一个可以对接自主研发的“运行时”的工具出来,并该工具能弥补容器编排不完美这个缺陷。个人觉得,Kubernetes的出现确实伟大,伟大到击垮Docker公司原先建立的都围着他转的容器社区体系,也伟大到可以又让大公司赚钱。 --- 纯属个人理解

    作者回复: 开源和商业不分家

    2018-09-22
    6
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部