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

你好,我是张磊。今天我和你分享的主题是:从容器到容器云,谈谈 Kubernetes 的本质。在前面的四篇文章中,我以 Docker 项目为例,一步步剖析了 Linux 容器的具体实现方式。通过这些讲解你应该能够明白:一个“容器”,实际上是一个由 Linux Namespace、Linux Cgroups 和 rootfs 三种技术构建出来的进程的隔离环境。从这个结构中我们不难看出,一个正在运行的 Linux 容器,其实可以被“一分为二”地看待:一组联合挂载在 /var/lib/docker/aufs/mnt 上的 rootfs,这一部分我们称为“容器镜像”(Container Image),是容器的静态视图;一个由 Namespace+Cgroups 构成的隔离环境,这一部分我们称为“容器运行时”(Container Runtime),是容器的动态视图。更进一步地说,作为一名开发者,我并不关心容器运行时的差异。因为,在整个“开发 – 测试 – 发布”的流程中,真正承载着容器信息进行传递的,是容器镜像,而不是容器运行时。

08 | 白话容器基础(四):重新认识Docker容器

你好,我是张磊。今天我和你分享的主题是:白话容器基础之重新认识 Docker 容器。在前面的三次分享中,我分别从 Linux Namespace 的隔离能力、Linux Cgroups 的限制能力,以及基于 rootfs 的文件系统三个角度,为你剖析了一个 Linux 容器的核心实现原理。备注:之所以要强调 Linux 容器,是因为比如 Docker on Mac,以及 Windows Docker(Hyper-V 实现),实际上是基于虚拟化技术实现的,跟我们这个专栏着重介绍的 Linux 容器完全不同。而在今天的分享中,我会通过一个实际案例,对“白话容器基础”系列的所有内容做一次深入的总结和扩展。希望通过这次的讲解,能够让你更透彻地理解 Docker 容器的本质。在开始实践之前,你需要准备一台 Linux 机器,并安装 Docker。这个流程我就不再赘述了。这一次,我要用 Docker 部署一个用 Python 编写的 Web 应用。

Kubernetes Python API中文使用说明

k8s集群操作:创建用户:vi CreateServiceAccount.yamlapiVersion: v1kind: ServiceAccountmetadata:  name: admin-user  namespace: kube-systemkubectl create -f CreateServiceAccount.yaml用户授权:vi RoleBinding.yamlapiVersion: rbac.authorization.k8s.io/v1beta1kind: ClusterRoleBindingmetadata:  name: admin-userroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: cluster-adminsubjects:- kind: ServiceAccount  name: admin-user  namespace: kube-systemkubectl create -f RoleBinding.

07 | 白话容器基础(三):深入理解容器镜像

你好,我是张磊。我在今天这篇文章的最后,放置了一张 Kubernetes 的技能图谱,希望对你有帮助。在前两次的分享中,我讲解了 Linux 容器最基础的两种技术:Namespace 和 Cgroups。希望此时,你已经彻底理解了“容器的本质是一种特殊的进程”这个最重要的概念。而正如我前面所说的,Namespace 的作用是“隔离”,它让应用进程只能看到该 Namespace 内的“世界”;而 Cgroups 的作用是“限制”,它给这个“世界”围上了一圈看不见的墙。这么一折腾,进程就真的被“装”在了一个与世隔绝的房间里,而这些房间就是 PaaS 项目赖以生存的应用“沙盒”。可是,还有一个问题不知道你有没有仔细思考过:这个房间四周虽然有了墙,但是如果容器进程低头一看地面,又是怎样一副景象呢?换句话说,容器里的进程看到的文件系统又是什么样子的呢?可能你立刻就能想到,这一定是一个关于 Mount Namespace 的问题:容器里的应用进程,理应看到一份完全独立的文件系统。这样,它就可以在自己的容器目录(比如 /tmp)下进行操作,而完全不会受宿主机以及其他容器的影响。

06 | 白话容器基础(二):隔离与限制

你好,我是张磊。我今天和你分享的主题是:白话容器基础之隔离与限制。在上一篇文章中,我详细介绍了 Linux 容器中用来实现“隔离”的技术手段:Namespace。而通过这些讲解,你应该能够明白,Namespace 技术实际上修改了应用进程看待整个计算机“视图”,即它的“视线”被操作系统做了限制,只能“看到”某些指定的内容。但对于宿主机来说,这些被“隔离”了的进程跟其他进程并没有太大区别。说到这一点,相信你也能够知道我在上一篇文章最后给你留下的第一个思考题的答案了:在之前虚拟机与容器技术的对比图里,不应该把 Docker Engine 或者任何容器管理工具放在跟 Hypervisor 相同的位置,因为它们并不像 Hypervisor 那样对应用进程的隔离环境负责,也不会创建任何实体的“容器”,真正对隔离环境负责的是宿主机操作系统本身:所以,在这个对比图里,我们应该把 Docker 画在跟应用同级别并且靠边的位置。这意味着,用户运行在容器里的应用进程,跟宿主机上的其他进程一样,都由宿主机操作系统统一管理,只不过这些被隔离的进程拥有额外设置过的 Namespace 参数。

04 | 预习篇 · 小鲸鱼大事记(四):尘埃落定

你好,我是张磊。我今天分享的主题是:小鲸鱼大事记之尘埃落定。在上一次的分享中我提到,伴随着 Docker 公司一手打造出来的容器技术生态在云计算市场中站稳了脚跟,围绕着 Docker 项目进行的各个层次的集成与创新产品,也如雨后春笋般出现在这个新兴市场当中。而 Docker 公司,不失时机地发布了 Docker Compose、Swarm 和 Machine“三件套”,在重新定义 PaaS 的方向上走出了最关键的一步。这段时间,也正是 Docker 生态创业公司们的春天,大量围绕着 Docker 项目的网络、存储、监控、CI/CD,甚至 UI 项目纷纷出台,也涌现出了很多 Rancher、Tutum 这样在开源与商业上均取得了巨大成功的创业公司。在 2014~2015 年间,整个容器社区可谓热闹非凡。这令人兴奋的繁荣背后,却浮现出了更多的担忧。这其中最主要的负面情绪,是对 Docker 公司商业化战略的种种顾虑。事实上,很多从业者也都看得明白,Docker 项目此时已经成为 Docker 公司一个商业产品。而开源,只是 Docker 公司吸引开发者群体的一个重要手段。

03 | 预习篇 · 小鲸鱼大事记(三):群雄并起

你好,我是张磊。我今天分享的主题是:小鲸鱼大事记之群雄并起。在上一篇文章中,我剖析了 Docker 项目迅速走红背后的技术与非技术原因,也介绍了 Docker 公司开启平台化战略的野心。可是,Docker 公司为什么在 Docker 项目已经取得巨大成功之后,却执意要重新走回那条已经让无数先驱们尘沙折戟的 PaaS 之路呢?实际上,Docker 项目一日千里的发展势头,一直伴随着公司管理层和股东们的阵阵担忧。他们心里明白,虽然 Docker 项目备受追捧,但用户们最终要部署的,还是他们的网站、服务、数据库,甚至是云计算业务。这就意味着,只有那些能够为用户提供平台层能力的工具,才会真正成为开发者们关心和愿意付费的产品。而 Docker 项目这样一个只能用来创建和启停容器的小工具,最终只能充当这些平台项目的“幕后英雄”。而谈到 Docker 项目的定位问题,就不得不说说 Docker 公司的老朋友和老对手 CoreOS 了。CoreOS 是一个基础设施领域创业公司。 它的核心产品是一个定制化的操作系统,用户可以按照分布式集群的方式,管理所有安装了这个操作系统的节点。

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

你好,我是张磊。我今天分享的主题是:小鲸鱼大事记之崭露头角。在上一篇文章中,我说到,伴随着 PaaS 概念的逐步普及,以 Cloud Foundry 为代表的经典 PaaS 项目,开始进入基础设施领域的视野,平台化和 PaaS 化成了这个生态中的一个最为重要的进化趋势。就在对开源 PaaS 项目落地的不断尝试中,这个领域的从业者们发现了 PaaS 中最为棘手也最亟待解决的一个问题:究竟如何给应用打包?遗憾的是,无论是 Cloud Foundry、OpenShift,还是 Clodify,面对这个问题都没能给出一个完美的答案,反而在竞争中走向了碎片化的歧途。而就在这时,一个并不引人瞩目的 PaaS 创业公司 dotCloud,却选择了开源自家的一个容器项目 Docker。更出人意料的是,就是这样一个普通到不能再普通的技术,却开启了一个名为“Docker”的全新时代。你可能会有疑问,Docker 项目的崛起,是不是偶然呢?事实上,这个以“鲸鱼”为注册商标的技术创业公司,最重要的战略之一就是:坚持把“开发者”群体放在至高无上的位置。

01 | 预习篇 · 小鲸鱼大事记(一):初出茅庐

你好,我是张磊。我今天分享的主题是:小鲸鱼大事记之初出茅庐。如果我问你,现今最热门的服务器端技术是什么?想必你不假思索就能回答上来:当然是容器!可是,如果现在不是 2018 年而是 2013 年,你的回答还能这么斩钉截铁么?现在就让我们把时间拨回到五年前去看看吧。2013 年的后端技术领域,已经太久没有出现过令人兴奋的东西了。曾经被人们寄予厚望的云计算技术,也已经从当初虚无缥缈的概念蜕变成了实实在在的虚拟机和账单。而相比于的如日中天 AWS 和盛极一时的 OpenStack,以 Cloud Foundry 为代表的开源 PaaS 项目,却成为了当时云计算技术中的一股清流。这时,Cloud Foundry 项目已经基本度过了最艰难的概念普及和用户教育阶段,吸引了包括百度、京东、华为、IBM 等一大批国内外技术厂商,开启了以开源 PaaS 为核心构建平台层服务能力的变革。如果你有机会问问当时的云计算从业者们,他们十有八九都会告诉你:PaaS 的时代就要来了!这个说法其实一点儿没错,如果不是后来一个叫 Docker 的开源项目突然冒出来的话。

05 | 白话容器基础(一):从进程说开去

你好,我是张磊。今天我和你分享的主题是:白话容器基础之从进程说开去。在前面的 4 篇预习文章中,我梳理了“容器”这项技术的来龙去脉,通过这些内容,我希望你能理解如下几个事实:容器技术的兴起源于 PaaS 技术的普及;Docker 公司发布的 Docker 项目具有里程碑式的意义;Docker 项目通过“容器镜像”,解决了应用打包这个根本性难题。紧接着,我详细介绍了容器技术圈在过去五年里的“风云变幻”,而通过这部分内容,我希望你能理解这样一个道理:    容器本身没有价值,有价值的是“容器编排”。也正因为如此,容器技术生态才爆发了一场关于“容器编排”的“战争”。而这次战争,最终以 Kubernetes 项目和 CNCF 社区的胜利而告终。所以,这个专栏后面的内容,我会以 Docker 和 Kubernetes 项目为核心,为你详细介绍容器技术的各项实践与其中的原理。不过在此之前,你还需要搞清楚一个更为基础的问题:    容器,到底是怎么一回事儿?在第一篇预习文章《小鲸鱼大事记(一):初出茅庐》中,我已经提到过,容器其实是一种沙盒技术。