Kubernetes 学习（十一）Kubernetes 基本知识点总结

0. 前言

• 最近一段时间校招，早期拿到了字节跳动、腾讯等公司的意向书
• 后面对面试有些懈怠，渐渐投入毕设中，疏于复习，感觉好多知识点开始遗忘，后来面试了美团等企业发现这个问题渐渐开始严重起来
• 是时候重新总结一下之前的知识点了，也为后续的面试和学习过程打打基础，持续更新和修改
• 参考文献：深入剖析 Kubernetes

1. 零散知识点

• PaaS：Platform as a Service（平台即服务）是一种云计算产品，其中服务提供商向客户端提供平台，使他们能够开发、运行和管理业务应用程序，而无需构建和维护基础架构这样的软件开发过程通常需要的设施。与其他云服务一样，如基础架构即服务（Iaa）和软件即服务（SaaS），PaaS通过云计算服务提供商的托管基础架构提供。用户通过网络浏览器访问 PaaS 产品可以控制软件部署，同时云计算提供商提供托管应用程序所需的所有主要IT组件，包括服务器，存储系统，网络，操作系统和数据库。PaaS 项目，最核心的组件就是一套应用的打包和分发机制
• 容器：容器其实是一种沙盒技术，沙盒就是能够像一个集装箱一样，把应用“装”起来的技术。这样，应用与应用之间，就因为有了边界而不至于相互干扰；而被装进集装箱的应用，也可以被方便地搬来搬去
• 镜像：进程是程序的一次执行，而为了能够让程序正常运行，要给程序提供数据，数据加上代码本身的二进制文件，放在磁盘上，就是代码的可执行镜像（executable image）
• 容器核心功能：进程的静态表现是程序；而一旦运行起来，它就变成了计算机里的数据和状态的总和，这就是它的动态表现。容器技术的核心功能就是通过约束和修改进程的动态表现，从而为其创造出一个“边界”：对于 Docker 等大多数 Linux 容器来说，Cgroups 技术是用来制造约束的主要手段，而 Namespace 技术则是用来修改进程视图的主要方法
• Namespace：在创建容器进程时，指定了这个进程所需要启用的一组 Namespace 参数。这样，容器就只能“看”到当前 Namespace 所限定的资源、文件、设备、状态，或者配置。而对于宿主机以及其他不相关的程序，它就完全看不到了：包括 PID、Mount、UTS、IPC、Network、User 等 Namespce 用来对各种不同的进程上下文进行“障眼法”操作。跟真实存在的虚拟机不同，在使用 Docker 的时候，并没有一个真正的“Docker 容器”运行在宿主机里面。Docker 帮助用户启动的还是原来的应用进程，只不过在创建这些进程时，Docker 为它们加上了各种各样的 Namespace 参数。这时，这些进程就会觉得自己是各自 PID Namespace 里的第 1 号进程，只能看到各自 Mount Namespace 里挂载的目录和文件，只能访问到各自 Network Namespace 里的网络设备，就仿佛运行在一个个“容器”里面，与世隔绝
• 容器对比虚拟机的优势：使用虚拟化技术必须要由 Hypervisor 来负责创建虚拟机，这个虚拟机是真实存在的，并且它里面必须运行一个完整的 Guest OS 才能执行用户的应用进程。这就不可避免地带来了额外的资源消耗和占用。而相比之下，容器化后的用户应用，却依然还是一个宿主机上的普通进程，这就意味着这些因为虚拟化而带来的性能损耗都是不存在的；而另一方面，使用 Namespace 作为隔离手段的容器并不需要单独的 Guest OS，这就使得容器额外的资源占用几乎可以忽略不计。“敏捷”和“高性能”是容器相较于虚拟机最大的优势，也是它能够在 PaaS 这种更细粒度的资源管理平台上大行其道的重要原因
• 容器的缺点：首先，既然容器只是运行在宿主机上的一种特殊的进程，那么多个容器之间使用的就还是同一个宿主机的操作系统内核；其次，在 Linux 内核中，有很多资源和对象是不能被 Namespace 化的，最典型的例子就是：时间
• CGroups：Linux Cgroups 就是 Linux 内核中用来为进程设置资源限制的一个重要功能。Linux Cgroups 的全称是 Linux Control Group。它最主要的作用，就是限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等。Linux Cgroups 就是一个子系统目录加上一组资源限制文件的组合。而对于 Docker 等 Linux 容器项目来说，它们只需要在每个子系统下面，为每个容器创建一个控制组（即创建一个新目录），然后在启动容器进程之后，把这个进程的 PID 填写到对应控制组的 tasks 文件中
• rootfs：rootfs 只是一个操作系统所包含的文件、配置和目录，并不包括操作系统内核。在 Linux 操作系统中，这两部分是分开存放的，操作系统只有在开机启动时才会加载指定版本的内核镜像。由于 rootfs 里打包的不只是应用，而是整个操作系统的文件和目录，也就意味着，应用以及它运行所需要的所有依赖，都被封装在了一起。对一个应用来说，操作系统本身才是它运行所需要的最完整的“依赖库”。有了容器镜像“打包操作系统”的能力，这个最基础的依赖环境也终于变成了应用沙盒的一部分。这就赋予了容器所谓的一致性：无论在本地、云端，还是在一台任何地方的机器上，用户只需要解压打包好的容器镜像，那么这个应用运行所需要的完整的执行环境就被重现出来了
• Docker 核心原理：Docker 为待创建的用户进程：1) 启用 Linux Namespace 配置；2) 设置指定的 Cgroups 参数；3) 切换进程的根目录（Change Root）
• UnionFS：Union File System（联合文件系统）。主要的功能是将多个不同位置的目录联合挂载（union mount）到同一个目录下
• Docker Layer：Docker 在镜像的设计中，引入了 Layer（层）的概念。也就是说，用户制作镜像的每一步操作，都会生成一个层，也就是一个增量 rootfs。每一层都是 Ubuntu 操作系统文件与目录的一部分；而在使用镜像时，Docker 会把这些增量联合挂载在一个统一的挂载点上

• • 只读层：它是这个容器的 rootfs 最下面的五层，对应的正是 ubuntu:latest 镜像的五层。它们的挂载方式都是只读的（ro+wh，即 readonly+whiteout）这些层都以增量的方式分别包含了 Ubuntu 操作系统的一部分
  • 可读写层；它是这个容器的 rootfs 最上面的一层，它的挂载方式为：rw，即 read write。在没有写入文件之前，这个目录是空的。而一旦在容器里做了写操作，你修改产生的内容就会以增量的方式出现在这个层中。如果删除只读层里的文件，AuFS 会在可读写层创建一个 whiteout 文件，把只读层里的文件“遮挡”起来。比如，你要删除只读层里一个名叫 foo 的文件，那么这个删除操作实际上是在可读写层创建了一个名叫.wh.foo 的文件。这样，当这两个层被联合挂载之后，foo 文件就会被 .wh.foo 文件“遮挡”起来，“消失”了。所以可读写层的作用，就是专门用来存放你修改 rootfs 后产生的增量，无论是增、删、改，都发生在这里。而当我们使用完了这个被修改过的容器之后，还可以使用 docker commit 和 push 指令，保存这个被修改过的可读写层，并上传到 Docker Hub 上，供其他人使用；而与此同时，原先的只读层里的内容则不会有任何变化
  • Init 层：夹在只读层和读写层之间。Init 层是 Docker 项目单独生成的一个内部层，专门用来存放 /etc/hosts、/etc/resolv.conf 等信息。需要这样一层的原因是，这些文件本来属于只读的 Ubuntu 镜像的一部分，但是用户往往需要在启动容器时写入一些指定的值比如 hostname，所以就需要在可读写层对它们进行修改。可是，这些修改往往只对当前的容器有效，我们并不希望执行 docker commit 时，把这些信息连同可读写层一起提交掉。所以，Docker 做法是在修改了这些文件之后，以一个单独的层挂载了出来。而用户执行 docker commit 只会提交可读写层，所以是不包含这些内容的。最终，这 7 个层都被联合挂载到 /var/lib/docker/aufs/mnt 目录下，表现为一个完整的 Ubuntu 操作系统供容器使用
• Sidecar：在一个 Pod 中，启动一个辅助容器，来完成一些独立于主进程（主容器）之外的工作

2. 参考文献

• 深入剖析 Kubernetes