课程笔记: 深入剖析 Kubernetes (张磊)

课程地址: 深入剖析 Kubernetes (5星好评)

历史

2008年, Solomon Hykes和Kamel Founadi, Sebastien Pahl在巴黎创建DotCloud，2010年公司得到Y Combinator投资，2013年3月20日，发布Docker第一个版本，并开源其代码。补: 1983年出身的Solomon Hykes2018年离开Docker(原dotCloud)，他未来的身份是Docker的董事会成员、股东以及Docker维护者，目前在折腾CI/CD pipeline: dagger.io
docker因为"Build once, Run AnyWhere"火了以后，一方面将公司名称直接从dotCloud改为Docker Inc, 另一方面目标直指PasS，所以在2014年推出了Swarm，希望一家独大
2015年，Google看不下去了，发起了CNCF(Cloud Native Computing Foundation)的基金会，以Kubernetes为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对以抗Docker公司为核心的容器商业生态，最终完胜
2017年,Docker公司中开源部分通过Moby剥离出去，所有和Docker有关的都属于Docker公司，怎么说呢，生意还是生意，人之常情，如果接受微软10亿收购可能又是另一番局面。

docker container和传统的Hypervisor这类虚拟化有很大的区别，本质上docker container就是通过clone出来的一个进程，只是人为限制了进程的视野，这种技术，在linux里面就是Namespace机制，其实就是native process with sandbox.
从这个角度来说，也完美的解释了容器的效率和native是一致的，几乎无损。同时也阐述了和VMware虚拟化的关系，本质上不在一个层面，vSphere, Openstack是在IaaS层面解决硬件虚拟化，而Kubernetes是在PaaS层面伙同中间件解决平台虚拟化，最后SaaS是留给终端软件公司
基于Linux Namespace的缺点就是: 隔离不彻底。虽然可以通过Mount Namespace单独挂载不同版本的操作系统，但实质上并不能改变共享宿主机内核的事实，这意味着，cpu arch必须一致，不能在windows上运行linux容器，甚至不能在低版本linux内核的宿主机上运行高版本内核的容器，所以应该清晰的知道能做到什么，不能做到什么
Linux Namespace的作用在于隔离资源，而Linux Cgroups(Linux Control Group)则是限制一个进程组能够使用的资源上限，包括CPU、内存、磁盘、网络带宽等等。否则一个container的while(true)就会榨干所有宿主机的资源。举例来说，通过cfs_period和cos_quota组合使用，就可以用来限制进程在长度为cfs_period的一段时间内，只能被分配到总量为cfs_quota的CPU时间

所以，一个正在运行的Linux容器，其实可以被"一分为二"地看待:

一组联合挂载在/var/lib/docker/aufs/mnt上的roofs，这一部分我们称之为"容器镜像"(Container Image)，是容器的静态视图
一个由Namespace+Cgroups构成的隔离环境，这一部分我们成为"容器运行时"(Container Runtime)，是容器的动态视图

当你的软件以Docker方式运行起来，各家PaaS和PaaS供应商都按耐不住了，开始想尽办法兜售自己的服务价值，通过容器和容器的排列组合，一下子让你的软件由了CI/CD、监控、安全、网络、存储等等，当然前提是你的上船，然后掏钱。老话说得好，能用钱解决的都不是事。

从一个开发者和单一的容器镜像，到无数开发者和庞大的容器集群，容器技术实现了从"容器"到"容器云"的飞跃，标志着它真正得到了市场和生态的认可。容器从一个开发者手里的小工具，一跃成为云计算领域的绝对主角；而能够定义容器组织和管理规范的"容器编排"技术，则当仁不让地坐上了容器技术领域的头把交椅。

Kubernetes项目要解决的问题是什么?

编排? 调度? 容器云? 还是集群管理? 实际上，这个问题到目前为止都没有固定的答案。因为在不同的发展阶段，Kubernetes需要着重解决的问题是不同的。

但是对于大多数用户来说，他们希望Kubernetes项目带来的体验是确定的：

现在我有了应用的容器镜像，请帮我在一个给定的集群上把这个应用运行起来。
更进一步地说，我还希望Kubernetes能给我提供路由网关、水平扩展、监控、备份、灾难恢复等一系列运维能力。
但实际上，最有价值的部分来源于Borg的理念: "运行在大规模集群中的各种任务之间，实际上存在着各种各样的关系。这些关系的处理，才是作业编排和管理系统最困难的地方。"

Kubernetes定义的关系:

Pod: 紧密交互的关系，这些应用之间需要非常频繁的交互和访问，又或者，他们需要通过本地文件进行信息交换，这些容器会被划分为一个Pod，Pod里的容器共享同一个Network Namespace、同一组数据卷，从而达到高效率交换信息的目的。
Service: 比如Web应用与数据库之间的访问关系，Kubernetes会给Pod绑定一个Service服务，而Service服务声明的IP地址等信息是“终身不变”的，这个Service服务的主要作用就是作为Pod的代理入口(Portal)，从而代替Pod对外暴露一个固定的网络地址。

所以，Kubernetes项目所擅长的，是按照用户的意愿和整个系统的规则，完全自动化地处理好容器之间的各种关系。这种功能，就是我们经常听到的一个概念：编排。

Kubernetes项目的本质，是为用户提供一个具有普遍意义的容器编排工具，更重要的是提供了一套基于容器构建分布式系统的基础依赖。