可以做超大海报的网站,泰安网络公司名字,自已做网站,网站建设服务方案本章内容涵盖创建、 启动和停止 pod使用标签组织 pod 和其他资源使用特定标签对所有 pod 执行操作使用命名空间将多个 pod 分到不重叠的组中调度 pod 到指定类型的工作节点上一章 已经大致介绍了在 Kubemetes 中创建的基本组件#xff0c;包括它们的基本功 能概述。 那么接下来…本章内容涵盖创建、 启动和停止 pod使用标签组织 pod 和其他资源使用特定标签对所有 pod 执行操作使用命名空间将多个 pod 分到不重叠的组中调度 pod 到指定类型的工作节点上一章 已经大致介绍了在 Kubemetes 中创建的基本组件包括它们的基本功 能概述。 那么接下来我们将更加详细地介绍所有类型的 Kubemetes 对象(或资源) 以便你理解在何时、 如何及为何要使用每一个对象。 其中 pod 是 Kubemetes 中最为 重要的核心概念而其他对象仅仅是在管理、 暴露 pod 或被 pod 使用 所以我们将 首先介绍 pod 这一核心概念。3.1 介绍pod我们已经了解到 pod 是一组并置的容器代表了 Kubernetes 中的基本构建模 块。 在实际应用 中我们并不会单独部署容器 更多的是针对一组 pod 的容器进行部 署和操作。 然而这并不意味着一个 pod 总是要包含多个容器一一实际上只包含一个单独容器的 pod 也是非常常见的。 值得注意的是当一个 pod 包含多个容器时这 些容器总是运行于同一个工作节点上——一个 pod 绝不会跨越多个工作节点如图 3.1 所示。3.1.1 为何需要 pod关于为何需要 pod 这种容器为何不直接使用容器为何甚至需要同时运行 多个容器难道不能简单地把所有进程都放在一个单独的容器中吗接下来我们将 一一回答上述问题。为何多个容器比单个容器中包含多个进程要好想象一个由多个进程组成的应用程序无论是通过 ipc (进程间通信)还是本 地存储文件进行通信都要求它们运行于同一 台机器上。 在 Kubemetes 中我们经 常在容器中运行进程由于每一个容器都非常像一台独立的机器此时你可能认为 在单个容器中运行多个进程是合乎逻辑的然而在实践中这种做法并不合理。 容器被设计为每个容器只运行一个进程(除非进程本身产生子进程)。如果在 单个容器中运行多个不相关的进程那么保持所有进程运行、管理它们的日志等将 会是我们的责任。例如我们需要包含一种在进程崩溃时能够自动重启 的机制 。 同 时这些进程都将记录到相同的标准输出中而此时我们将很难确定每个进程分别记 录了什么 。综上所述我们需要让每个进程运行于自己的容器中而这就是Docker和kubernetes期望使用的方式。3.1.2 了解 pod由于不能将多个进程聚集在一个单独的容器中我们需要另一种更高级的结构 来将容器绑定在一起并将它们作为一个单元进行管理这就是 pod 背后的根本原理。 在包含容器的 pod 下我们可以同时运行一些密切相关的进程并为它们提供(几 乎)相同的环境此时这些进程就好像全部运行于单个容器中一样同时又保持着 一定的隔离。这样一来我们便能全面地利用容器所提供的特性同时对这些进程 来说它们就像运行在一起一样实现两全其美。同一 pod 中容器之间的部分隔离在上一章中我们己经了解到容器之间彼此是完全隔离的但此时我们期望的 是隔离容器组而不是单个容器并让每个容器组内的容器共享一些资源而不是 全部(换句话说没有完全隔离)。 Kubemetes 通过配置 Docker 来让一个 pod 内的 所有容器共享相同的 Linux 命名空间而不是每个容器都有自己的一组命名空间。由于一个 pod 中的所有容器都在相同的 network 和 UTS 命名空间下运行(在这 里我们讨论的是 Linux 命名空间)所以它们都共享相同的主机名和网络接口。同样 地这些容器也都在相同的 IPC 命名空间下运行因此能够通过 IPC 进行通信。在 最新的 Kubemetes 和 Docker 版本中它们也能够共享相 同的 PID 命名空间但是 该特征默认是未激活的。注意 当同一个 pod 中的容器使用单独的 PID 命名空间时在容器中执行 ps aux 就只会看到容器自己的进程。但当涉及文件系统时情况就有所不同。 由于大多数容器的文件系统来自容器 镜像因此默认情况下每个容器的文件系统与其他容器完全隔离。但我们可以使 用名为 Volume 的 Kubemetes 资源来共享文件目录 关于这一概念将在第 6 章进行 讨论。容器如何共享相同的 IP 和端口空间这里需强调的一点是由于一个 pod 中的容器运行于相同的 Network 命名空间 中因此它们共享相同的 IP 地址和端口空间。这意味着在同 pod 中的容器运行的 多个进程需要注意不能绑定到相同的端口号否则会导致端口冲突但这只涉及同 - pod 中的容器。 由于每个 pod 都有独立的端口空间对于不同 pod 中的容器来说 则永远不会遇到端口冲突。此外 一个 pod 中的所有容器也都具有相同的 loopback 网络接口因此容器可以通过 localhost 与同一pod 中的其他容器进行通信。介绍平坦 pod 间网络Kubemetes 集群中的所有 pod 都在同一个共享网络地址空间中(如图 3.2 所示) 这意味着每个 pod 都可以通过其他 pod 的 IP 地址来实现相互访问 。 换句话说这也 表示它们之间没有 NAT (网络地址转换)网关。当两个 pod 彼此之间发送网络数据 包时它们都会将对方的实际 IP 地址看作数据包中的源 IP。因此 pod 之间的通信其实是非常简单的。 不论是将两个 pod 安排在单一的还 是不同的工作节点上同时不管实际节点间的网络拓扑结构如何这些 pod 内的容 器都能够像在无 NAT 的平坦网络中一样相互通信就像局域网 CLAN)上的计算机 一样。 此时每个 pod 都有自己的 IP 地址并且可以通过这个专门的网络实现 pod 之间互相访问。这个专门的网络通常是由额外的软件基于真实链路实现的。总结本节涵盖的内容 pod 是逻辑主机其行为与非容器世界中的物理主机或 虚拟机非常相似。此外运行在同一个 pod 中的进程与运行在同一物理机或虚拟机 上的进程相似只是每个进程都封装在一个容器之中。3.1.3 通过 pod 合理管理容器将 pod 视为独立的机器其中每个机器只托管一个特定的应用。过去我们习惯 于将各种应用程序塞进同一台主机但是 pod 不是这么干的。 由于 pod 比较轻量 我们可以在几乎不导致任何额外开销的前提下拥有尽可能多的 pod。与将所有内容 填充到一个 pod 中不同我们应该将应用程序组织到多个 pod 中而每个 pod 只包 含紧密相关的组件或进程。说到这里对于一个由前端应用服务器和后端数据库组成的多层应用程序你 认为应该将其配置为单个 pod 还是两个 pod 呢下面我们将对该问题做进一步探讨。将多层应用分散到多个 pod 中虽然我们可以在单个 pod 中同时运行前端服务器和数据库这两个容器但这种 方式并不值得推荐。 前面我们已经讨论过同 pod 的所有容器总是运行在一起 但对于 Web 服务器和数据库来说它们真的需要在同一台计算机上运行吗答案显 然是否定的它们不应该被放到同一个 pod 中 。 那假如你非要把它们放在一起有错吗某种程度上来说是的。如果前端和后端都在同一个容器中那么两者将始终在同台计算机上运行。 如果你有一个双节点 Kubemetes 集群 而只有一个单独的 pod那么你将始终只会 用一个工作节点而不会充分利用第二个节点上的计算资源(CPU 和内存)。 因此 更合理的做法是将 pod 拆分到两个工作节点上允许 Kubemetes 将前端安排到一个 节点将后端安排到另一个节点从而提高基础架构的利用率。另一个不应该将应用程序都放到单一pod 中的原因就是扩缩容。 pod 也是扩缩 容的基本单位对于 Kubemetes 来说它不能横向扩缩单个容器只能扩缩整个 pod。这意味着如果你的 pod 由一个前端和一个后端容器组成那么当你扩大 pod 的 实例数量时比如扩大为两个 最终会得到两个前端容器和两个后端容器。通常来说前端组件与后端组件具有完全不同的扩缩容需求所以我们倾向于 分别独立地扩缩它们。 更不用说像数据库这样的后端服务器通常比无状态的前 端 web 服务器更难扩展。 因此如果你需要单独扩缩容器那么这个容器很明确地 应该被部署在单独的 pod 中。何时在 pod 中使用多个容器将多个容器添加到单个 pod 的主要原因是应用可能由一个主进程和一个或多个 辅助进程组成如图 3.3 所示。例如 pod 中的主容器可以是一个仅仅服务于某个目录中的文件的 Web 服务 器而另 一个容器(所谓的 sidecar 容器) 则定期从夕阳H源下载 内 容并将其存储在 Web 服务器目录中。在第 6 章中我们将看到在这种情况下需要使用 Kubemetes Volume并将其挂载到两个容器中 。sidecar 容器的其他例子包括日志轮转器和收集器、数据处理器、通信适配器等。决定何时在 pod 中使用多个容器回顾一下容器应该如何分组到 pod 中 当决定是将两个容器放入一个 pod 还是 两个单独的 pod 时我们需要问自己以下问题它们需要一起运行还是可以在不同的主机上运行它们代表的是一个整体还是相互独立的组件它们必须一起进行扩缩容还是可以分别进行基本上我们总是应该倾向于在单独的 pod 中运行容器除非有特定的原因要 求它们是同一pod 的一部分。 图 3.4 将有助于我们记忆这一点。尽管 pod 可以包含多个容器但为了保持现在的简单性 本章将仅讨论单容器 pod 有关的问题。 稍后我们将在第 6 章看到如何在一个 pod 中使用多个容器。3.2 以YAML或JSON描i主文件创建podpod 和其他 Kubemetes 资源通常是通过向 Kubemetes REST API 提供 JSON 或 YAML 描述文件来创建的。 此外还有其他更简单的创建资源的方法 比如在前一章中使用的 kubectl run 命令但这些方法通常只允许你配置一组有限的属性。 另外 通过 YAML 文件定义所有的 Kubemetes 对象之后还可以将它们存储在版本控制系 统中充分利用版本控制所带来的便利性。因此为了配置每种类型资源的各种属性我们 需要了解并理解 Kubemetes API 对象定义。 通过本书学习各种资源类型 时我们将会了解其中的大部分内 容。 需要注意的是我们并不会解释每二个独立属性因此在创建对象时还应参考 http://kubernetes.io/ docs/reference 中的 Kubernetes API 参考文档。3.2.1 检查现有 pod 的 YAML 描述文件假设我们己经在上一章中创建了一些 pod 接下来就来看看这些 pod 的 YAML 文件是如何定义的。我们将使用带有 -o yaml 选项的 kubectl get 命令来获取 pod 的整个 YAML 定义正如下面的代码清单所示。上述代码清单的内容看上去较为复杂但一旦我们理解了基础知识并知道如何区分重要部分和细枝末节时它就变得非常简单。此外稍后我们将看到 当创建 一个新的 pod 时 需要写的 YAML 相对来说则要短得多。介绍 pod 定义的主要部分pod 定义由这么几个部分组成 首先是 YAML中使用的 Kubernetes API 版本和 YAML 描述的资源类型其次是几乎在所有 Kubemetes 资源中都可以找到的三大重 要部分 metadata 包括名称、命名空间、标签和关于该容器的其他信息。spec 包含 pod 内容的实际说明 例如 pod 的容器、卷和其他数据。status 包含运行中的 pod 的当前信息例如 pod 所处的条件、 每个容器的描述和状态以及内部 IP 和其他基本信息。代码清单 3.1 展示了一个正在运行的 pod 的完整描述其中包含了它的状态。 status 部分包含只读的运行时数据该数据展示了给定时刻的资源状态。而在创 建新的 pod 时永远不需要提供 status 部分。 上述三部分展示了 Kubemetes API 对象的典型结构。正如你将在整本书中看到 的那样其他对象也都具有相同的结构这使得理解新对象相对来说更加容易 。 对上述 YAML 中的每个属性进行深究的意义并不大因此接下来我们将关注如 何创建 pod 的最基本的 YAML。3.2.2 为 pod 创建一个简单的 YAML 描述文件我们将创建一个名为 kubia-manual.yaml 的文件(可以在任意目录下创建该文 件)或者下载本书的代码档案文件然后在 Chapter03 文件夹中找到该文件。下面 的清单展示了该文件的全部内容。很明显我们能够感受到该代码清单比代码清单 3.1 中的定义要简单得多。接 下来我们就对整个描述文件进行深入探讨该文件遵循 Kubernetes API 的 vl 版本。 我们描述的资源类型是 pod名称为 kubia-manual 该 pod 由基于 luksa/kubia 镜像的单个容器组成。此外我们还给该容器命名并表示它正在监昕 8080 端口。指定容器端口在pod定义部分指定端口的行为纯粹是展示性的(informational)。忽略它们对于客户端是 否可以通过端口连接到 pod 不会带来任何影响。如果容器通过绑定到地址 0.0.0.0 的端口接收连接那么即使端口未明确列出在 pod spec 中 其他 pod 也依旧能够连接 到该端口 。 但明确定义端口仍是有意义的在端口定义下每个使用集群的人都可 以快速查看每个 pod 对外暴露的端口 。 此外 我们将在本书的后续内容中看到明 确定义端口还允许你为每个端口指定一个名称这样一来更加方便我们使用。使用 kubectl explain 来发现可能的 API 对象字段在准备 manifest 时可以转到 http://kubemetes.io/docs/api 上的 Kubemetes 参考文档查看每个 API 对象支持哪些属性也可以使用 kubectl explain 命 令。 例如当从头创建一个 pod manifest 时可以从请求 kubectl 来解释 pod 开始Kubectl 打印出对象的解释并列出对象可以包含的属性接下来就可以深入 了解各个属性的更多信息。 例如可以这样查看 spec 属性 3.2.3 使用 kubectl create 来创建 pod我们使用 kubectl create 命令从 YAML 文件创建 pod:#kubectl create -f kubia-manual.yamlpod/kubia-manual createdkubectl create - f 命令用于从 YAML 或 ISON 文件创建任何资源(不只 是 pod)。得到运行中 pod 的完整定义pod 创建完成后可以请求kubernetes来获取完整的YAML可以看到它与我们之前看到的YAML文件非常相似。在下一节中我们将了解返回定义中出现的其他字段接下来就直接使用以下命令来查看该pod的完整描述文件#kubectl get pod kubia-manual -o yaml也可以让 kubectl 返回 JSON 格式而不是 YAML 格式(显然即使你使用 YAML创建 pod同样也可以获取 JSON 格式的描述文件〉 #kubectl get pod kubia-manual -o json在 pod 列表中查看新创建的 pod创建好 pod 之后如何知道它是否正在运行 此时可以列出 pod 来查看它们的 状态这里可 以看到 kubia-manual 这个 pod 状态显示它正在运行。 有可能你像笔 者一样想要通过与 pod 的实际通信来确认其正在运行 但该方法将在之后进行讨论。 现在我们先查看应用的日志来检查是否存在错误。3.2.4 查看应用程序日志小型 Node.js 应用将日志记录到进程的标准输出。容器化的应用程序通常会将 日志记录到标准输出和标准错误流而不是将其写入文件这就允许用户可以通过 简单、标准的方式查看不同应用程序的日志。容器运行时(在我们的例子中为 Docker)将这些流重定向到文件并允许我们 运行以下命令来获取容器的日志# docker logs 使用 ssh 命令登录至lj pod 正在运行的节点并使用 docker logs 命令查看其 日志但 Kubernetes 提供了一种更为简单的方法。使用 kubectl logs 命令获取 pod 日志为了查看 pod 的日志(更准确地说是容器的日志)只需要在本地机器上运行 以下命令(不需要 ssh 到任何地方) 在我们向 Node.js 应用程序发送任何 Web 请求之前日志只显示一条关于服 务器启动的语句。正如我们所见如果该 pod 只包含一个容器那么查看这种在 Kubernetes 中运行的应用程序的日志则非常简单。注意每天或者每次日志文件达到 10MB 大小时 容器 日志都会自动轮替。 kubectl logs 命令仅显示最后一次轮替后的 日志条目 。获取多容器 pod 的日志时指定容器名称如果我们的 pod 包含多个容器在运行 kubectl logs 命令时则必须通过包 含 -c 容器名称选项来显式指定容器名称。在 kubia-manual pod 中我们将 容器的名称设置为 kubia所以如果该 pod 中有其他容器可以通过如下命令获取其日志 这里需要注意的是我们只能获取仍然存在的 pod 的日 志。 当一个 pod 被删除时 它的日志也会被删除。如果希望在 pod 删除之后仍然可以获取其日志我们需要设 置中心化的、 集群范围的日志系统将所有日志存储到中心存储中。在第 17 章中 我们将会解释如何设置集中的日志系统。3.2.5 向 pod 发送请求通过kubectl get和kubectl logs命令显示该pod正在运行但我们如何在实际操作中看到该状态呢在前一章中我们使用 kubectl expose 命令创建了一 个 service以便在外部访问该 pod。 由于有一整章专 门介绍 service因此本章并不 打算使用该方法。 此外还有其他连接到 pod 以进行测试和调试的方法其中之一 便是通过端 口转发。将本地网络端口转发歪lj pod 中的端口如果想要在不通过 service 的情况下与某个特定的 pod 进行通信 ( 出于调试或 其他原因), Kubemetes 将允许我们配置端口转发到该 pod。 可以通过 kubectl port-forward 命令完成上述操作。用法是 kubectl port-forward pod名 代理端口:pod端口例如以下命令会将机器的本地端口 8888 转发 到我们的 kubia- manual pod 的端口 8080 :此时端口转发正在运行可以通过本地端口连接到我们的 pod。通过端口转发连接到 pod在另一个终端中可以使用 curl 命令向 pod 发送一个 HTTP 请求(通过运行在 localhost:8888 上的 kubectl port-forward 代理)图 3.5 展示了发送请求时的简化视图。实际上 kubectl 进程和 pod 之间还有 一些额外的组件但现在暂时不关注它们。像这样使用端口转发是一种测试特定 pod 的有效方法而我们也将在这本书中 学习其他类似的方法。3.3 使用标签组织pod此时我们的集群中只有两个正在运行的pod。但部署实际应用程序时大多数用户最终将运行更多的pod。随着pod数量的增加将它们分类到子集的需求也就变得越来越明显了。例如对于微服务架构部署的微服务数量可以轻松超过20个甚至更多。这些组件可能是副本(部署同一组件的多个副本)和多个不同的发布版本 (stable、 beta、 canary 等)同时运行。这样一来可能会导致我们在系统中拥有数百个 pod 如 果没有可 以有效组织这些组件的机制 将会导致产生巨大的混乱 如图 3.6 所示。 该图展示了多个微服务的 pod 包括一些运行多副本集以及其他运行于同一微服 务中的不同版本。很明显我们需要一种能够基于任意标准将上述 pod 组织成更小群体的方式 这样一来处理系统的每个开发人员和系统管理员都可以轻松地看到哪个 pod 是什么。 此外我们希望通过一次操作对属于某个组的所有 pod 进行操作而不必单独为每 个 pod 执行操作。那就是通过标签来组织 pod 和所有其他 Kubemetes 对象。3.3.1 介绍标签标签是一种简单却功能强大的 Kubemetes 特性不仅可以组织 pod也可以组 织所有其他的 Kubemetes 资源。详细来讲 标签是可以附加到资源的任意键值对用以选择具有该确切标签的资源(这是通过标签选择器完成的)。 只要标签的 key 在 资源内是唯一的 一个资源便可以拥有多个标签。 通常在我们创建资源时就会将标 签附加到资源上但之后我们也可以再添加其他标签或者修改现有标签的值而 无须重新创建资源。接下来回到图 3.6 中的微服务示例。 通过给这些 pod 添加标签可以得到一个 更组织化的系统 以便我们理解。 此时每个 pod 都标有两个标签 app它指定 pod 属于哪个应用、组件或微服务。rel 它显示在 pod 中运行的应用程序版本是 stable、 beta 还是 canary。定义 金丝在发布是指在吾l~署新版本时先只让一小部分用户体验新版本以观察 新版本的表现 然后再向所有用户进行推广这样可以防止暴露有问题的版本给过 多的用户 。如图 3.7 所示通过添加这两个标签基本上可以将 pod 组织为两个维度(基于 应用的横向维度和基于版本的纵向维度)。每个可以访问集群的开发或运维人员都可以通过查看 pod 标签轻松看到系统的 结构以及每个 pod 的角色。3.3.2 创建 pod 时指定标签现在可以通过创建一个带有两个标签的新 pod 来查看标签的实际应用。使用 以下代码清单中的内容创建一个名为 kubia-manual-with-labels.yaml 的新文件。metadata.labels 部分己经包含了 creation methodmanual 和 envprod 标签。 现在来创建该 pod:kubectl get pods 命令默认不会列出任何标签但我们可以使用 --show-labels 选项来查看 如果你只对某些标签感兴趣可以使用 L 选项指定它们并将它们分别显示在 自己的列中而不是列出所有标签。 接下来我们再次列出所有 pod并将附加到 pod kubia-manual-v2 上的两个标签的列展示如下3.3.3 修改现有 pod 的标签标签也可以在现有 pod 上进行添加和修改。 由于 pod kubia -manual 也是手动 创建的所以为其添加 creation methodmanual 标签 现在将 kubia- manual- v2 pod 上的 envprod 标签更改为 envdebug, 以演示现有标签也可以被更改。注意 在更改现有标签时 需要使用 --overwrite 选项再次列出 pod 以查看更新后的标签正如我们所看到目前将标签附加到资源上看起来并没有什么价值在现有资 源上更改标签也是如此。 但在下一章中我们将证实这会是一项令人难以置信的强 大功能。 而首先我们需要看看这些标签除了在列出 pod 时用以简单显示外 还可以 用来做什么。阅读本章之后你应该对 Kubemetes 的核心模块有了系统的了解。 在接下来的 几章中学到的概念也都与 pod 有着直接关联。在本章中你应该已经掌握 ·如何决定是否应将某些容器组合在一个 pod 中。pod 可以运行多个进程这和非容器世界中的物理主机类似。可以编写 YAML 或 JSON 描述文件用于创建 pod 然后查看 pod 的规格及其 当前状态。使用标签来组织 pod并且一次在多个 pod 上执行操作。可以使用节点标签将 pod 只调度到提供某些指定特性的节点上。注解允许人们、工具或库将更大的数据块附加到 pod。命名空间可用于允许不同团队使用同 一 集群就像它们使用单独的 Kubemetes 集群一样。使用 kubectl explain 命令快速查看任何 Kubernetes 资源的信息。
