深入剖析Kubernetes
张磊
Kubernetes社区资深成员与项目维护者
立即订阅
22715 人已学习
课程目录
已完结 56 讲
0/4登录后，你可以任选4讲全文学习。
课前必读 (5讲)
开篇词 | 打通“容器技术”的任督二脉
免费
01 | 预习篇 · 小鲸鱼大事记（一）：初出茅庐
02 | 预习篇 · 小鲸鱼大事记（二）：崭露头角
03 | 预习篇 · 小鲸鱼大事记（三）：群雄并起
04 | 预习篇 · 小鲸鱼大事记（四）：尘埃落定
容器技术概念入门篇 (5讲)
05 | 白话容器基础（一）：从进程说开去
06 | 白话容器基础（二）：隔离与限制
07 | 白话容器基础（三）：深入理解容器镜像
08 | 白话容器基础（四）：重新认识Docker容器
09 | 从容器到容器云：谈谈Kubernetes的本质
Kubernetes集群搭建与实践 (3讲)
10 | Kubernetes一键部署利器：kubeadm
11 | 从0到1：搭建一个完整的Kubernetes集群
12 | 牛刀小试：我的第一个容器化应用
容器编排与Kubernetes作业管理 (15讲)
13 | 为什么我们需要Pod？
14 | 深入解析Pod对象（一）：基本概念
15 | 深入解析Pod对象（二）：使用进阶
16 | 编排其实很简单：谈谈“控制器”模型
17 | 经典PaaS的记忆：作业副本与水平扩展
18 | 深入理解StatefulSet（一）：拓扑状态
19 | 深入理解StatefulSet（二）：存储状态
20 | 深入理解StatefulSet（三）：有状态应用实践
21 | 容器化守护进程的意义：DaemonSet
22 | 撬动离线业务：Job与CronJob
23 | 声明式API与Kubernetes编程范式
24 | 深入解析声明式API（一）：API对象的奥秘
25 | 深入解析声明式API（二）：编写自定义控制器
26 | 基于角色的权限控制：RBAC
27 | 聪明的微创新：Operator工作原理解读
Kubernetes容器持久化存储 (4讲)
28 | PV、PVC、StorageClass，这些到底在说啥？
29 | PV、PVC体系是不是多此一举？从本地持久化卷谈起
30 | 编写自己的存储插件：FlexVolume与CSI
31 | 容器存储实践：CSI插件编写指南
Kubernetes容器网络 (8讲)
32 | 浅谈容器网络
33 | 深入解析容器跨主机网络
34 | Kubernetes网络模型与CNI网络插件
35 | 解读Kubernetes三层网络方案
36 | 为什么说Kubernetes只有soft multi-tenancy？
37 | 找到容器不容易：Service、DNS与服务发现
38 | 从外界连通Service与Service调试“三板斧”
39 | 谈谈Service与Ingress
Kubernetes作业调度与资源管理 (5讲)
40 | Kubernetes的资源模型与资源管理
41 | 十字路口上的Kubernetes默认调度器
42 | Kubernetes默认调度器调度策略解析
43 | Kubernetes默认调度器的优先级与抢占机制
44 | Kubernetes GPU管理与Device Plugin机制
Kubernetes容器运行时 (3讲)
45 | 幕后英雄：SIG-Node与CRI
46 | 解读 CRI 与 容器运行时
47 | 绝不仅仅是安全：Kata Containers 与 gVisor
Kubernetes容器监控与日志 (3讲)
48 | Prometheus、Metrics Server与Kubernetes监控体系
49 | Custom Metrics: 让Auto Scaling不再“食之无味”
50 | 让日志无处可逃：容器日志收集与管理
再谈开源与社区 (1讲)
51 | 谈谈Kubernetes开源社区和未来走向
答疑文章 (1讲)
52 | 答疑：在问题中解决问题，在思考中产生思考
特别放送 (1讲)
特别放送 | 2019 年，容器技术生态会发生些什么？
结束语 (1讲)
结束语 | Kubernetes：赢开发者赢天下
特别放送 | 云原生应用管理系列 (1讲)
基于 Kubernetes 的云原生应用管理，到底应该怎么做？
深入剖析Kubernetes
登录|注册

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

张磊 2018-09-12
你好，我是张磊。今天我和你分享的主题是：从容器到容器云，谈谈 Kubernetes 的本质。
在前面的四篇文章中，我以 Docker 项目为例，一步步剖析了 Linux 容器的具体实现方式。通过这些讲解你应该能够明白：一个“容器”，实际上是一个由 Linux Namespace、Linux Cgroups 和 rootfs 三种技术构建出来的进程的隔离环境。
从这个结构中我们不难看出，一个正在运行的 Linux 容器，其实可以被“一分为二”地看待：
一组联合挂载在 /var/lib/docker/aufs/mnt 上的 rootfs，这一部分我们称为“容器镜像”（Container Image），是容器的静态视图；
一个由 Namespace+Cgroups 构成的隔离环境，这一部分我们称为“容器运行时”（Container Runtime），是容器的动态视图。
更进一步地说，作为一名开发者，我并不关心容器运行时的差异。因为，在整个“开发 - 测试 - 发布”的流程中，真正承载着容器信息进行传递的，是容器镜像，而不是容器运行时。
这个重要假设，正是容器技术圈在 Docker 项目成功后不久，就迅速走向了“容器编排”这个“上层建筑”的主要原因：作为一家云服务商或者基础设施提供商，我只要能够将用户提交的 Docker 镜像以容器的方式运行起来，就能成为这个非常热闹的容器生态图上的一个承载点，从而将整个容器技术栈上的价值，沉淀在我的这个节点上。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《深入剖析Kubernetes》，如需阅读全部文章，
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(72)

  • Geek_zz
    对这个专栏看的越多，越觉得作者讲得有条理又有深度，物超超超所值
    2018-09-12
    177
  • 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
    2
    134
  • hugeo
    学费太值得了，老师太会教课了说得很清楚
    2018-09-12
    50
  • Tigerfive
    感觉不能迁移“有状态”的容器，是因为迁移的是容器的rootfs，但是一些动态视图是没有办法伴随迁移一同进行迁移的。

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

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

    作者回复: 没错！

    2018-09-12
    20
  • 大豪。
    这价格讲到这种程度，跟捡到便宜似的，感谢作者
    2018-09-29
    19
  • Gao
    面向yaml文件编程
    2018-09-16
    14
  • maomaostyle
    k8s就是把组织协调这项管理学落实到计算机工程上
    2018-10-26
    12
  • huan
    1 我自己用swarm后，感觉和docker 公司的整体风格很一致：上手简单，但是最后还是没用的很好，因为毕竟需要太多的依赖需要在不同容器之间传递。k8s从更高视野看服务器软件架构从而提出更有效而且看起来更重的方案，最终被证明是有效的。
    2018-09-12
    10
  • LiJiao
    迁移可以简单分为两类：磁盘数据文件不变，进程重启；磁盘数据文件不变、内存数据也不变，相当于连带进程一起挪过去。第一种类型有很简单的方法：挂载云盘，从空间上解耦。第二种类型就复杂了，需要将内存数据一点点迁移过去，最后瞬间切换。IaaS很早就应用热迁移技术了。

    Kubernetes则讨巧了，只着眼于应用，直接约定容器是可以随时被杀死的，热迁移就没有那么重要了。甚至连IP都隐藏了，又绕过了一个大难题～
    2018-09-21
    6
  • pytimer
    第二个问题: 我觉得应该是很多容器数据都是挂载在本地路径，所以没办法直接进行迁移。

    如果容器的数据挂载在共享存储上，那是不是没有kubernetes也是可以迁移有状态的容器？

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

    2018-09-12
    5
  • Scott
    为什么一个node上，kubelet与Device plugin要走gRPC，这个没有CSI这样的专门中间层吗？

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

    2018-09-16
    4
  • sprzhing
    不能迁移是因为容器在本地的很多状态修改不会commit到云端吧？
    2018-09-12
    4
  • ECHO
    订这么多课程，这个作者最有水平，太值了！把如此复杂的容器技术说的引人入胜！
    2019-06-28
    3
  • 刘岚乔月
    第一次接触K8S，这篇文章整整看了一个小时，算是对整体有个模糊的轮廓概念。。。
    PS：讲真心不错
    2018-11-25
    3
  • Rod
    @老师。我记得service的ip也是可变的。不变的是service name。通过kube dns解析。当然service可以绑定主机名。但是那样就不能高可用。不知道我说的对不对？

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

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

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

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

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

    2018-09-22
    2
  • 阿硕
    整个集群的持久化数据，则由 kube-apiserver 处理后保存在 Ectd 中。是不是Etcd呢？

    作者回复: 对对

    2018-09-12
    2
收起评论
72
下载
客户端
返回
顶部