k8s kubernetes

作者：阿里云网站
链接：https://www.zhihu.com/question/37498459/answer/826736487
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

https://www.kubernetes.org.cn/doc-4

8 分钟入门 K8s | 详解容器基本概念

一、容器与镜像

什么是容器？
在介绍容器的具体概念之前，先简单回顾一下操作系统是如何管理进程的。
首先，当我们登录到操作系统之后，可以通过 ps 等操作看到各式各样的进程，这些进程包括系统自带的服务和用户的应用进程。那么，这些进程都有什么样的特点？

• 第一，这些进程可以相互看到、相互通信；
• 第二，它们使用的是同一个文件系统，可以对同一个文件进行读写操作；
• 第三，这些进程会使用相同的系统资源。

这样的三个特点会带来什么问题呢？

• 因为这些进程能够相互看到并且进行通信，高级权限的进程可以攻击其他进程；
• 因为它们使用的是同一个文件系统，因此会带来两个问题：这些进程可以对于已有的数据进行增删改查，具有高级权限的进程可能会将其他进程的数据删除掉，破坏掉其他进程的正常运行；此外，进程与进程之间的依赖可能会存在冲突，如此一来就会给运维带来很大的压力；
• 因为这些进程使用的是同一个宿主机的资源，应用之间可能会存在资源抢占的问题，当一个应用需要消耗大量 CPU 和内存资源的时候，就可能会破坏其他应用的运行，导致其他应用无法正常地提供服务。

针对上述的三个问题，如何为进程提供一个独立的运行环境呢？

• 针对不同进程使用同一个文件系统所造成的问题而言，Linux 和 Unix 操作系统可以通过 chroot 系统调用将子目录变成根目录，达到视图级别的隔离；进程在 chroot 的帮助下可以具有独立的文件系统，对于这样的文件系统进行增删改查不会影响到其他进程；
• 因为进程之间相互可见并且可以相互通信，使用 Namespace 技术来实现进程在资源的视图上进行隔离。在 chroot 和 Namespace 的帮助下，进程就能够运行在一个独立的环境下了；
• 但在独立的环境下，进程所使用的还是同一个操作系统的资源，一些进程可能会侵蚀掉整个系统的资源。为了减少进程彼此之间的影响，可以通过 Cgroup 来限制其资源使用率，设置其能够使用的 CPU 以及内存量。

那么，应该如何定义这样的进程集合呢？
其实，容器就是一个视图隔离、资源可限制、独立文件系统的进程集合。所谓“视图隔离”就是能够看到部分进程以及具有独立的主机名等；控制资源使用率则是可以对于内存大小以及 CPU 使用个数等进行限制。容器就是一个进程集合，它将系统的其他资源隔离开来，具有自己独立的资源视图。
容器具有一个独立的文件系统，因为使用的是系统的资源，所以在独立的文件系统内不需要具备内核相关的代码或者工具，我们只需要提供容器所需的二进制文件、配置文件以及依赖即可。只要容器运行时所需的文件集合都能够具备，那么这个容器就能够运行起来。

什么是镜像？

综上所述，我们将这些容器运行时所需要的所有的文件集合称之为容器镜像。
那么，一般都是通过什么样的方式来构建镜像的呢？通常情况下，我们会采用 Dockerfile 来构建镜像，这是因为 Dockerfile 提供了非常便利的语法糖，能够帮助我们很好地描述构建的每个步骤。当然，每个构建步骤都会对已有的文件系统进行操作，这样就会带来文件系统内容的变化，我们将这些变化称之为 changeset。当我们把构建步骤所产生的变化依次作用到一个空文件夹上，就能够得到一个完整的镜像。 changeset 的分层以及复用特点能够带来几点优势：

• 第一，能够提高分发效率，简单试想一下，对于大的镜像而言，如果将其拆分成各个小块就能够提高镜像的分发效率，这是因为镜像拆分之后就可以并行下载这些数据；
• 第二，因为这些数据是相互共享的，也就意味着当本地存储上包含了一些数据的时候，只需要下载本地没有的数据即可，举个简单的例子就是 golang 镜像是基于 alpine 镜像进行构建的，当本地已经具有了 alpine 镜像之后，在下载 golang 镜像的时候只需要下载本地 alpine 镜像中没有的部分即可；
• 第三，因为镜像数据是共享的，因此可以节约大量的磁盘空间，简单设想一下，当本地存储具有了 alpine 镜像和 golang 镜像，在没有复用的能力之前，alpine 镜像具有 5M 大小，golang 镜像有 300M 大小，因此就会占用 305M 空间；而当具有了复用能力之后，只需要 300M 空间即可。

  如何构建镜像？

  如下图所示的 Dockerfile 适用于描述如何构建 golang 应用的。
  8 分钟入门 K8s | 详解容器基本概念
  如图所示：
  

1. FROM 行表示以下的构建步骤基于什么镜像进行构建，正如前面所提到的，镜像是可以复用的；
2. WORKDIR 行表示会把接下来的构建步骤都在哪一个相应的具体目录下进行，其起到的作用类似于 Shell 里面的 cd；
3. COPY 行表示的是可以将宿主机上的文件拷贝到容器镜像内；
4. RUN 行表示在具体的文件系统内执行相应的动作。当我们运行完毕之后就可以得到一个应用了；
5. CMD 行表示使用镜像时的默认程序名字。

当有了 Dockerfile 之后，就可以通过 docker build 命令构建出所需要的应用。构建出的结果存储在本地，一般情况下，镜像构建会在打包机或者其他的隔离环境下完成。
那么，这些镜像如何运行在生产环境或者测试环境上呢？这时候就需要一个中转站或者中心存储，我们称之为 docker registry，也就是镜像仓库，其负责存储所有产生的镜像数据。我们只需要通过 docker push 就能够将本地镜像推动到镜像仓库中，这样一来，就能够在生产环境上或者测试环境上将相应的数据下载下来并运行了。

如何运行容器？

运行一个容器一般情况下分为三步：

• 第一步：从镜像仓库中将相应的镜像下载下来；
• 第二步：当镜像下载完成之后就可以通过 docker images 来查看本地镜像，这里会给出一个完整的列表，我们可以在列表中选中想要的镜像；

• 第三步：当选中镜像之后，就可以通过 docker run 来运行这个镜像得到想要的容器，当然可以通过多次运行得到多个容器。一个镜像就相当于是一个模板，一个容器就像是一个具体的运行实例，因此镜像就具有了一次构建、到处运行的特点。

  小结

  简单回顾一下，容器就是和系统其它部分隔离开来的进程集合，这里的其他部分包括进程、网络资源以及文件系统等。而镜像就是容器所需要的所有文件集合，其具备一次构建、到处运行的特点。

  二、容器的生命周期

  容器运行时的生命周期
  容器是一组具有隔离特性的进程集合，在使用 docker run 的时候会选择一个镜像来提供独立的文件系统并指定相应的运行程序。这里指定的运行程序称之为 initial 进程，这个 initial 进程启动的时候，容器也会随之启动，当 initial 进程退出的时候，容器也会随之退出。
  因此，可以认为容器的生命周期和 initial 进程的生命周期是一致的。当然，因为容器内不只有这样的一个 initial 进程，initial 进程本身也可以产生其他的子进程或者通过 docker exec 产生出来的运维操作，也属于 initial 进程管理的范围内。当 initial 进程退出的时候，所有的子进程也会随之退出，这样也是为了防止资源的泄漏。 但是这样的做法也会存在一些问题，首先应用里面的程序往往是有状态的，其可能会产生一些重要的数据，当一个容器退出被删除之后，数据也就会丢失了，这对于应用方而言是不能接受的，所以需要将容器所产生出来的重要数据持久化下来。容器能够直接将数据持久化到指定的目录上，这个目录就称之为数据卷。
  数据卷有一些特点，其中非常明显的就是数据卷的生命周期是独立于容器的生命周期的，也就是说容器的创建、运行、停止、删除等操作都和数据卷没有任何关系，因为它是一个特殊的目录，是用于帮助容器进行持久化的。简单而言，我们会将数据卷挂载到容器内，这样一来容器就能够将数据写入到相应的目录里面了，而且容器的退出并不会导致数据的丢失。
  通常情况下，数据卷管理主要有两种方式：

• 第一种是通过 bind 的方式，直接将宿主机的目录直接挂载到容器内；这种方式比较简单，但是会带来运维成本，因为其依赖于宿主机的目录，需要对于所有的宿主机进行统一管理。

• 第二种是将目录管理交给运行引擎。

  三、容器项目架构

  moby 容器引擎架构
  moby 是目前最流行的容器管理引擎，mobydaemon 会对上提供有关于容器、镜像、网络以及 Volume的管理。moby daemon 所依赖的最重要的组件就是 containerd，containerd 是一个容器运行时管理引擎，其独立于 moby daemon ，可以对上提供容器、镜像的相关管理。
  containerd 底层有 containerd shim 模块，其类似于一个守护进程，这样设计的原因有几点：

• 首先，containerd 需要管理容器生命周期，而容器可能是由不同的容器运行时所创建出来的，因此需要提供一个灵活的插件化管理。而 shim 就是针对于不同的容器运行时所开发的，这样就能够从 containerd 中脱离出来，通过插件的形式进行管理。

• 其次，因为 shim 插件化的实现，使其能够被 containerd 动态接管。如果不具备这样的能力，当 moby daemon 或者 containerd daemon 意外退出的时候，容器就没人管理了，那么它也会随之消失、退出，这样就会影响到应用的运行。
• 最后，因为随时可能会对 moby 或者 containerd 进行升级，如果不提供 shim 机制，那么就无法做到原地升级，也无法做到不影响业务的升级，因此 containerd shim 非常重要，它实现了动态接管的能力。

本节课程只是针对于 moby 进行一个大致的介绍，在后续的课程也会详细介绍。

四、容器 VS VM

容器和 VM 之间的差异
VM 利用 Hypervisor 虚拟化技术来模拟 CPU、内存等硬件资源，这样就可以在宿主机上建立一个 Guest OS，这是常说的安装一个虚拟机。
每一个 Guest OS 都有一个独立的内核，比如 Ubuntu、CentOS 甚至是 Windows 等，在这样的 Guest OS 之下，每个应用都是相互独立的，VM 可以提供一个更好的隔离效果。但这样的隔离效果需要付出一定的代价，因为需要把一部分的计算资源交给虚拟化，这样就很难充分利用现有的计算资源，并且每个 Guest OS 都需要占用大量的磁盘空间，比如 Windows 操作系统的安装需要 10~30G 的磁盘空间，Ubuntu 也需要 5~6G，同时这样的方式启动很慢。正是因为虚拟机技术的缺点，催生出了容器技术。 容器是针对于进程而言的，因此无需 Guest OS，只需要一个独立的文件系统提供其所需要文件集合即可。所有的文件隔离都是进程级别的，因此启动时间快于 VM，并且所需的磁盘空间也小于 VM。当然了，进程级别的隔离并没有想象中的那么好，隔离效果相比 VM 要差很多。
总体而言，容器和 VM 相比，各有优劣，因此容器技术也在向着强隔离方向发展。

本文总结

• 容器是一个进程集合，具有自己独特的视图视角；
• 镜像是容器所需要的所有文件集合，其具备一次构建、到处运行的特点；
• 容器的生命周期和 initial 进程的生命周期是一样的；
• 容器和 VM 相比，各有优劣，容器技术在向着强隔离方向发展。

作者：阿里巴巴高级开发工程师 傅伟

8 分钟了解 Kubernetes

Kubernetes 脱胎于 Google 的 Borg 系统，是一个功能强大的容器编排系统。Kubernetes 及其整个生态系统（工具、模块、插件等）均使用 Go 语言编写，从而构成一套面向 API、可高速运行的程序集合，这些程序文档精良、易于参与贡献或在其上构建应用程序。

每个开发、运维或感兴趣的读者都应熟悉它的一些核心概念，以便理解这个系统及其不同的功能，以及为什么几乎所有人都在使用它。

在继续之前，我想提一下 Kubernetes 的几个顶级朋友（或竞争对手）：ECS、Nomad 和 Mesos。ECS 是 AWS 自己的编排解决方案，最近它又推出了托管在 AWS 上的 Kubernetes 系统——EKS。两者都支持 FARGATE，让用户无须关心所运行的物理资源。

Kubernetes 毫无疑问是最大赢家，作为一个开源系统，三大主流云服务商都以托管的方式提供了这项功能。但是，它比其他几个产品都要来得复杂和混乱。Kubernetes 可以处理几乎任何类型的容器负载，也有很多技巧，但这并不意味着每个人都应该使用它。其他解决方案或许也能满足某些公司的要求，例如，完全部署在 AWS 上的互联网产品公司，使用 ECS 会比 Kubernetes 具有更佳的生产环境体验，是的，也好于 EKS。

话虽如此，Kubernetes 的魔力在于：它可以部署在任何地方、它拥有一个活跃的社区，有数百个核心开发人员及数千个生态系统开源贡献者。它运行快速、具有创新性、模块化且面向 API，是一个对构建插件或服务非常友好的系统。

好了，闲话少说，开始我们的旅程。

Kubernetes 的 11 个部分

1. Pod
Pod 是 Kubernetes 中最小的可互动单元。一个 Pod 可以由多个容器组成，这些容器共同部署在单个节点上形成一个单元。一个 Pod 具有一个 IP，该 IP 在其容器之间共享。

在微服务世界中，一个 Pod 可以是执行后台工作或服务请求的微服务的单个实例。

2. Node（节点）
Node 是机器。它们是 Kubernetes 用于部署 Pod 的“裸机”（或虚拟机）。Node 为 Kubernetes 提供可用的集群资源用于以保持数据、运行作业、维护工作负载、创建网络路由等。

3. Label（标签）与 Annotation（注解）
Label 是 Kubernetes 及其最终用户用于过滤系统中相似资源的方式，也是资源与资源相互“访问”或关联的粘合剂。比如说，为 Deployment 打开端口的 Service。不论是监控、日志、调试或是测试，任何 Kubernetes 资源都应打上标签以供后续查验。例如，给系统中所有 Worker Pod 打上标签：app=worker，之后即可在 kubectl 或 Kubernetes API 中使用 —selector 字段对其进行选择。

Annotation 与 Label 非常相似，但通常用于以自由的字符串形式保存不同对象的元数据，例如“更改原因: 安全补丁升级”。

4. Service Discovery（服务发现）
作为编排系统，Kubernetes 控制着不同工作负载的众多资源，负责管理 Pod、作业及所有需要通信的物理资源的网络。为此，Kubernetes 使用了 ETCD。

ETCD 是 Kubernetes 的“内部”数据库，Master 通过它来获取所有资源的位置。Kubernetes 还为服务提供了实际的“服务发现”——所有 Pod 使用了一个自定义的 DNS 服务器，通过解析其他服务的名称以获取其 IP 地址和端口。它在 Kubernetes 集群中“开箱即用”，无须进行设置。
5. ReplicaSet（副本集）
虽然 Pod 是一个物理性的运行任务，但通常使用单个实例是不够的。为了冗余并处理负载，出于某种原因（比如“伸缩”）需要对 Pod 进行复制。为了实现负责扩展和复制的层，Kubernetes 使用了 ReplicaSet。这个层以副本的数量表示系统的期望状态，并在任意给定时刻保持该系统的当前状态。

这也是配置自动伸缩的所在，在系统高负载时创建额外的副本，并在不再需要这些资源来支撑所运行的工作负载时进行缩容。

6. DaemonSet（守护进程集）
有时候，应用程序每个节点需要的实例不超过一个。比如 FileBeat 这类日志收集器就是个很好的例子。为了从各个节点收集日志，其代理需要运行在所有节点上，但每个节点只需要一个实例。Kubernetes 的 DaemonSet 即可用于创建这样的工作负载。
7. StatefulSet（有状态集）
尽管多数微服务涉及的都是不可变的无状态应用程序，但也有例外。有状态的工作负载有赖于磁盘卷的可靠支持。虽然应用程序容器本身可以是不可变的，可以使用更新的版本或更健康的实例来替代，但是所有副本还是需要数据的持久化。StatefulSet 即是用于这类需要在整个生命周期内使用同一节点的应用程序的部署。

它还保留了它的“名称”：容器内的 hostname 以及整个集群中服务发现的名称。3 个 ZooKeeper 构成的 StatefulSet 可以被命名 zk-1、zk-2 及 zk-3，也可以扩展到更多的成员 zk-4、zk-5 等等…… StatefulSets 还负责管理 PersistentVolumeClaim（Pod 上连接的磁盘）。
8. Job（任务）
Kubernetes 核心团队考虑了大部分使用编排系统的应用程序。虽然多数应用程序要求持续运行以同时处理服务器请求（比如 Web 服务器），但有时还是需要生成一批作业并在其完成后进行清理。比如，一个迷你的无服务器环境。

为了在 Kubernetes 中实现这一点，可以使用 Job 资源。正如其名，Job 的工作是生成容器来完成特定的工作，并在成功完成时销毁。举个例子，一组 Worker 从待处理和存储的数据队列中读取作业。一旦队列空了，就不再需要这些 Worker 了，直到下个批次准备好。
9. ConfigMap（配置映射）及 Secret（机密配置）
如果你还不熟悉十二要素应用清单，请先行了解。现代应用程序的一个关键概念是无环境，并可通过注入的环境变量进行配置。应用程序应与其位置完全无关。为了在 Kubernetes 中实现这个重要的概念，就有了 ConfigMap。实际上这是一个环境变量键值列表，它们会被传递给正在运行的工作负载以确定不同的运行时行为。在同样的范畴下，Secret 与正常的配置条目类似，只是会进行加密以防类似密钥、密码、证书等敏感信息的泄漏。

我个人认为 Hashicorp 的 Vault 是使用机密配置的最佳方案。请务必阅读一下我去年写的有关文章，文章讲述了将 Vault 作为生产环境一部分的原因，以及我的一位同事写的另一篇更技术性的文章。
10. Deployment（部署）
一切看起来都很美好，Pod 可以正常运行，如果上层有 ReplicaSet，还可以根据负载进行伸缩。不过，大家蜂拥而来，为的是能用新版本快速替换应用程序。我们想小规模地进行构建、测试和发布，以缩短反馈周期。使用 Deployments 即可持续地部署新软件，这是一组描述特定运行工作负载新需求的元数据。举个例子，发布新版本、错误修复，甚至是回滚（这是 Kubernetes 的另一个内部选项）。

在 Kubernetes 中部署软件可使用 2 个主要策略：

• 替换——正如其名，使用新需求替换全部负载，自然会强制停机。对于快速替换非生产环境的资源，这很有帮助。
• 滚动升级——通过监听两个特定配置慢慢地将容器替换成新的：

MaxAvailable——设置在部署新版本时可用的工作负载比例（或具体数量），100% 表示“我有 2 个容器，在部署时要保持 2 个存活以服务请求”；
b. MaxSurge——设置在当前存活容器的基础上部署的工作负载比例（或数量），100% 表示“我有 X 个容器，部署另外 X 个容器，然后开始滚动移除旧容器”。
11. Storage（存储）
Kubernetes 在存储之上添加了一层抽象。工作负载可以为不同任务请求特定存储，甚至可以管理超过 Pod 生命周期的持久化。为简短起见，请阅读作者之前发布的关于 Kubernetes 存储的文章，特别重点看看为什么它不能完全解决类似数据库部署这样的数据持久性要求。

概念性理解

Kubernetes（现在仍然）是根据一些指导原则进行设计和开发的，构建在系统里的每个功能、概念和想法都考虑了社区因素。此外，最终用户会被引导以某种方式使用该系统，但这不是强迫的；最佳实践也是公开的，但作为一个开源免费的系统，你完全可以根据自身需要进行操作。

面向 API——系统每个部分构建时通过优良的文档和可操作的 API 来实现可交互性。核心开发人员会确保最终用户可以进行更改、查询和更新，以免将其阻挡在外或有不想要的过滤器。

欢迎包装工具——作为前一点的衍生产品，Kubernetes 对在其 API 之上构建的工具和包装器表示欢迎。作为一个原始平台，Kubernetes 是以一个非常可定制的方式进行构建的，以便他人使用，并进一步开发用于不同用例的工具。有些工具已经变得非常有名并被广泛使用，比如 Spinnaker、Istio 等等。

声明性状态——鼓励用户在系统中使用声明性描述而非命令式描述。这意味着，系统的状态和组件最好被描述为在某种版本控制（如 Git）中管理的代码，以此避免手工修改造成的困扰。因此，Kubernetes 减少了灾难恢复的难度、更易于在团队之间分享并传递责任。

原文链接

K8s 学习者绝对不能错过的最全知识图谱（内含 56个知识点链接）

导读：Kubernetes 作为云原生时代的“操作系统”，熟悉和使用它是每名用户的必备技能。本篇文章概述了容器服务 Kubernetes 的知识图谱，部分内容参考了网上的知识图谱，旨在帮助用户更好的了解 K8s 的相关知识。

1. 概述

容器服务 Kubernetes 知识图谱，部分内容参考网上一知识图谱，更加结合阿里云容器服务。

原图来源：https://www.processon.com/view/link/5ac64532e4b00dc8a02f05eb#map

2. 链接和备注

作者：平名 阿里服务端开发技术专家