深入剖析Kubernetes 学习笔记

深入理解K8s

 

• Namespace的作用是”隔离“

 

• Mount Namespace：用于让被隔离进程只看到当前Namespace里的挂载点信息。

 

• Network Namespace：用于让被隔离进程看到当前Namespace里的网络设备和配置。

 

• Cgroups的作用是“限制”（围墙）

 

• Cgroups的子系统：

1. blkio：为块设备设定I/O限制，一般用于磁盘等设备；
2. cpuset：为进程分配单独的CPU核和对应的内存节点；
3. memory：为进程设定内存使用的限制。

 

• chroot命令（“change root file system”)改变进程的根目录到指定位置。

 

• rootfs：根文件系统，挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统，就是所谓的“容器镜像”（包括操作系统所包含的文件、配置和目录，并不包括操作系统内核）

 

• rootf由三部分组成：只读层(ro+wh)、Init层(ro+wh)、可读写层(rw)

1. 第一部分，只读层：这个容器rootfs最下面的五层，对应ubuntu：latest镜像的五层，只读（ro+wh：readonly+whiteout）
2. 第二部分，可读写层：容器最上面的一层，rw（read write）。在没有写入文件之前，这个目录是空的，一旦在容器里做了写操作，修改产生的内容就会以增量方式出现在这个层中。

删除只读层里的文件：AuFS会在可读写层创建一个whiteout文件，把只读层里的文件“遮挡”起来。

whiteout：“白障”

可读写层的作用，就是存放修改后rootfs后产生的增量。

1. 第三部分，Init层：一个以"-init"结尾的层，夹在只读层和读写层之间。Init层是Docker项目单独生成的一个内部层，专门用来存放/etc/hosts、/etc/resolv.conf等信息。

这些文件本来属于只读的Ubuntu镜像的一部分，但是启动容器时需要写入一些指定值比如hostname，需要在可读写层对它们进行修改。这些修改只对当前容器有效，不希望执行docker commit时一起同可读写层提交掉。

Docker做法是，修改这些文件后，以一个单独的层挂载出来(Init层)，提交的时候不包含这些内容。

K8s架构

 

 

 

 

• Deployment：Pod的多实例管理器
• Service服务：作为Pod的代理入口，从而代替Pod对外暴露一个固定的网络地址（因为Pod的地址等信息不是固定的，Web应用通过代理入口找到Pod）
• Secret：是一个保存在Etcd里的键值对数据。把Credential（数据库的用户名和密码）信息以Secret方式存在Etcd里，K8s就会在你指定的Pod（如：Web应用的Pod）启动时，自动把Secret里的数据一Volume的方式挂载到容器里。这样Web应用就可以访问数据库了。
• Job：用来描述一次性运行的Pod（如:大数据任务）
• DaemonSet：用来描述每个宿主机上必须且只能运行一个副本的守护进程服务。
• CronJob：用于描述定时任务。

K8s核心设计理念：

• 首先，通过一个“编排对象”，比如 Pod、Job、CronJob 等，来描述你试图管理的应用；

• 然后，再为它定义一些“服务对象”，比如 Service、Secret、Horizontal Pod Autoscaler（自

动水平扩展器）等。这些对象，会负责具体的平台级功能。

这种使用方法，就是所谓的“声明式 API”。这种 API 对应的“编排对象”和“服务对象”，都是

Kubernetes 项目中的 API 对象（API Object）。