深入剖析Kubernetes
张磊
Kubernetes社区资深成员与项目维护者
立即订阅
21363 人已学习
课程目录
已完结 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
登录|注册

02 | 预习篇 · 小鲸鱼大事记(二):崭露头角

张磊 2018-08-29

你好,我是张磊。我今天分享的主题是:小鲸鱼大事记之崭露头角。

在上一篇文章中,我说到,伴随着 PaaS 概念的逐步普及,以 Cloud Foundry 为代表的经典 PaaS 项目,开始进入基础设施领域的视野,平台化和 PaaS 化成了这个生态中的一个最为重要的进化趋势。

就在对开源 PaaS 项目落地的不断尝试中,这个领域的从业者们发现了 PaaS 中最为棘手也最亟待解决的一个问题:究竟如何给应用打包?

遗憾的是,无论是 Cloud Foundry、OpenShift,还是 Clodify,面对这个问题都没能给出一个完美的答案,反而在竞争中走向了碎片化的歧途。

而就在这时,一个并不引人瞩目的 PaaS 创业公司 dotCloud,却选择了开源自家的一个容器项目 Docker。更出人意料的是,就是这样一个普通到不能再普通的技术,却开启了一个名为“Docker”的全新时代。

你可能会有疑问,Docker 项目的崛起,是不是偶然呢?

事实上,这个以“鲸鱼”为注册商标的技术创业公司,最重要的战略之一就是:坚持把“开发者”群体放在至高无上的位置。

相比于其他正在企业级市场里厮杀得头破血流的经典 PaaS 项目们,Docker 项目的推广策略从一开始就呈现出一副“憨态可掬”的亲人姿态,把每一位后端技术人员(而不是他们的老板)作为主要的传播对象。

© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《深入剖析Kubernetes》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(25)

  • 与路同飞
    之前不知道哪里见过一句话,无开源不生态,无生态不商业。挺有道理的
    2018-08-29
    66
  • 日拱一卒
    1. 公司改名无可厚非,项目开源和商业牟利不应该是冲突的。
    2. Docker带来的启示:任何项目或者技术都应该是以用户为中心,找准目标人群,深挖用户痛点,通过用户最能接受的方式,去解决问题。

    作者回复: 说的一点没错,用户才是项目和技术的衣食父母,脱离群众要不得

    2018-08-29
    35
  • 龙坤
    你好,张老师,读到这里,毕竟我没经历过旧PaaS时代的项目,但我试图去挖掘和感受那个没有docker项目的年代,在PaaS平台上,一个团队是如何把应用开发、应用部署、应用扩展、应用分布式、应用维护与监控等一系列操作表现与实施出来?暂且到读到这里,了解到Docker项目仅仅解决了应用打包的困境,能让开发者省去上云后带来的系统差异性所导致的种种问题,可对于应用来说,始终都要回到PaaS的基础设施上,然后去实现多主机通信、存储共享、权限控制等等这些Docker项目没出现前都要的基本技术实施。那么我的的问题是:docker项目的出现,带来应用打包优势同时,是否将来会增加了关于网络、存储、权限等额外技术栈应用的复杂度?
    2019-03-21
    10
  • Cloud*
    这个改名真是太正确了,一下品牌就火了。开源永远都是最好的选择,首先得让开发者认可你,才能走得长远。
    2018-08-29
    9
  • eason2017
    已经迫不及待的想直入主题啦……
    2018-08-29
    6
  • cxyfreedom
    如果按天时地利人和三方面来说,总结的第一点就是地利,第二点是人和,第三点就是天时。另外改名这事,我觉得这是作为一个运营公司从商业角度需要考虑的,没什么问题。
    2018-09-01
    4
  • JRich
    精彩,终于理清了docker和paas历史,感觉自己跟上了容器时代发展
    2018-08-29
    4
  • 岁月~静好
    看评论也能了解很多东西😁
    2018-08-29
    3
  • blackpiglet
    对于 dotcloud 改名和扩张,我想当时他们可能没有其他选择,毕竟是创业公司,是有盈的压力的。docker 的开源不易带来直接的收入,所以必然要有下一步。
    2018-08-29
    3
  • atompi
    希望能够一直“坚持把‘开发者’群体放在至高无上的位置”
    2018-08-29
    3
  • vimfun
    我觉得更好一点的顺序为:
    1. PaaS 概念已经深入人心的完美契机。(天时)
    2. Docker 镜像通过技术手段解决了 PaaS 的根本性问题;(地利 自我创新出来的地利)
    3. Docker 容器同开发者之间有着与生俱来的密切关系;(人和)

    时势造英雄啊
    2019-08-14
    1
  • abs
    请问下swarm和k8s有什么关联和区别?为什么我知道很多公司用k8s,却很少听说有公司用swarm的?

    作者回复: 其实就是主流方案与非主流方案的区别。至于为啥kubernetes 变成主流了,咱们专栏前四篇讲的就是这个故事

    2018-09-08
    1
  • Dale
    互联网公司的玩法,需要寻找商业化的点子,改名字肯定可以吸引更多的人关注,使用的人多了,流量上来了,就有机会变现。
    2018-09-04
    1
  • 张春源
    改不改名无所谓,前面提到了镜像是核心,应该在镜像这层上加以限制。掌控核心竞争力,获取市场!
    2018-08-29
    1
  • Geek_49d8fa
    我认为在“一统江山”之前,改名是个“自费武功”的操作。
    我认为:先实现简单易用,再去开源,人们愿意用开源,都是基于“成本”。
    2019-08-07
  • 海绵家的猫
    把开发者 放到“至高无上” 的位置上 。。我喜欢这个

    2019-05-24
  • 六天天天向上
    使用docker发布的一个web网站相比直接发布到服务器中会不会在性能上有所损害?
    2019-05-04
  • 王涛
    看评论也挺有意思
    2018-12-14
  • 心灵捕手
    在技术的发展上,以用户为核心,并且能提高开发效率,提高用户体验的技术必将引领潮流,成为新时代的弄潮儿。当然,开源生态同样重要
    2018-12-09
  • Geek
    最有道理的莫过于 docker的镜像 以及打包
    解决了运维一遍又一遍的重复 无价值的工作
    让运维的工作从幕后走到前台
    2018-11-22
收起评论
25
返回
顶部