Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Kubernetes 实践

 

本章介绍 Kubernetes 的一些基本对象和功能。

假设您有一个需要在具有某些规格(SSD HD、物理位置、处理功率等)的机器上托管的盒,或者您想要搜索或分组您的箱以简化管理。你是做什么工作的?标签是转到的方式。在 Kubernetes 中,标签附加到对象。

让’我们使用标签在特定机器上启动盒。

标签

在 Kubernetes 中,可以使用标签来识别任何对象。

您可以为每个对象分配多个标签,但应避免使用过多的标签或太少;过多的人会感到困惑,而赢’取的价值过少,无法提供分组、选择和搜索的真正优势。

最佳实践是分配标签以指示:

  • 使用此 pod 的应用程序/程序 ID

  • 所有者(负责管理此盒/应用程序)

  • 舞台(开发/测试/生产版中的 pod/应用程序)

  • 资源要求(SSD、CPU、存储)

  • 位置(首选位置/区域/数据中心,用于运行此盒/应用程序)

好的,’让 s 为指定标签(stage: testingzone: production)添加到两个节点,然后尝试在具有标签的节点中启动盒(stage: testing):

现在让’我们启动一个基本 Nginx 箱,标记有 stage: testing在 nodeSelector 中,确认它将在带有以下标记的节点上 stage: testing. Kube-时间表使用盒的 nodeSelector 部分中提到的标签选择用于启动盒的节点:

Note

Kube-时间表基于各种因素(如个人和集体资源要求、硬件、软件或策略约束、关联和反关联规格、数据地点、工作负载干扰和最终期限)来挑选节点。

Note

您可以将 pod 分配给特定节点,方法是将参数 nodeName: nodeXYAML 文件中的规格下, nodeX是节点的名称。

名称空间

与许多其他平台一样,通常有多个用户(或团队)在使用一个 Kubernetes 群集。假设一个名为webserver1的 pod 已由 devops 部门构建,但是当销售部门尝试启动具有相同名称的盒时,系统将产生错误:

Error from server (AlreadyExists): error when creating "webserver1.yaml": pods "webserver1" already exists

Kubernetes’t 会使 Kubernetes 资源的相同对象名称在同一范围内多次出现。

命名空间提供 OpenStack 中的项目/租户等 Kubernetes 资源的范围。资源名称在命名空间中必须是唯一的,但不能跨命名空间。这’是在多个用户之间划分群集资源的自然方式。

Kubernetes 从三个初始命名空间开始:

  • 默认值:无其他命名空间的对象的默认命名空间。

  • kube 系统:由 Kubernetes 系统创建的对象的命名空间。

  • kube-公有:最初在部署集群时由 kubeadm 工具创建。根据约定,此命名空间的用途是使某些资源不经过身份验证即可由所有用户读取。它通常存在于仅使用 kubeadm 工具的 Kubernetes 集群启动 stapped 中。

创建命名空间

创建命名空间非常简单。Kubectl 命令会执行神奇的工作。’您无需具有 YAML 文件:

新命名空间开发现已创建:

现在, dev命名空间中的 webserver1’pod 与销售命名空间中的 webserver1 pod t 冲突:

超过

现在,您可以应用限制每个命名空间的资源占用情况,类似于 OpenStack 租户。例如,您可以限制可在命名空间中创建的对象数量、资源可能消耗的计算资源总量等。K8s 中的约束称为配额。下面’是一个示例:

在此,我们刚才创建了配额配额 onepod,而我们提供的约束是箱 = – 1,因此仅允许在此命名空间中创建一个盒式:

现在,在其中创建一个箱:

这一切正常,因此现在让’我创建另一个箱:

立即遇到错误 "已超过" 配额。让’s 删除配额配额-onepod。此新的 pod 将在卸下配额后创建:

ReplicationController

您学习了如何在第2章中启动一个表示容器的 YAML 文件的盒。在您的容器中可能会出现一个问题--充满主意:如果我需要三个完全相同的盒式机箱(每个都运行一个 Apache 容器),以确保 web 服务显示得更强大,该如何应对?我是否更改了 YAML 文件中的名称,然后重复相同的命令来创建所需的箱?或者可能有 shell 脚本?Kubernetes 已有对象使用 RC- ReplicationController或 RS– ReplicaSet.

ReplicationController (rc)可确保在任意时刻运行指定数量的 pod 副本。换句话说,复制控制器可确保盒或同构的一组箱始终保持开机并可用。

创建 rc

让’我们来创建一个 rc 示例。首先为名为 web 的 rc 对象创建一个 YAML 文件:

请记住,该种类表示此 YAML 文件定义的对象类型,这里是一个 rc,而不是一个 pod。在元数据中,它将’rc s 名称显示为 web 的。该规格是此 rc 对象的详细说明,副本:3表示将克隆相同的盒,以确保 rc 创建的盒总箱数始终为3。最后,该模板提供有关将在盒中运行的容器的信息,与您在 pod YAML 文件中看到的相同。现在使用此 YAML 文件创建 rc 对象:

如果您足够快速,则在创建新箱时,您可以捕获中间状态:

最终,您将看到三个箱已启动:

Rc 直接与 pod 配合使用。工作流如Figure 1所示。

Figure 1: rc 工作流
rc 工作流

通过在 rc 对象 YAML 文件中指定的复制副本参数,作为主节点中 kube 控制器管理进程的一部分运行的 Kubernetes 复制控制器将保持监控由 rc 生成的运行箱数量,并在其中的任何一个遇到故障时自动启动新的盒式监视。要学习的关键一点是,个别箱可能会在任何时间启动,但作为整体的池始终处于开启和运行状态,从而实现强大的服务。在您学习 Kubernetes 服务时,您将了解这一点。

测试 Rc

您可以通过删除其中’一个箱来测试 rc 的影响。要通过 kubectl 删除资源,请使用 kubectl delete 子命令:

您可以看到,当一个盒被终止时,会立即产生一个新的 pod。最后,旧的 pod 将消失,新的 pod 将启动并运行。运行中的盒总数量将保持不变。

您还可以使用 rc 扩展复制副本。例如,要从编号3到5进行扩展:

Rc 还有其他优势。实际上,由于这种抽象是如此流行且使用频繁,因此使用更强大的功能开发了两–个极其相似的对象,即 ReplicaSet 和部署部署。一般说来,您可以致电下一代 rc。现在,让我们’来停止探索更多 rc 功能,并将焦点移动到这两个新对象。

在迁移到下一个对象之前,您可以删除 rc:

ReplicaSet

ReplicaSet 或 rs 对象与 rc 对象几乎相同,只有一个主要例外–是选择器的外观:

Rc 仅使用基于平均的选择器,而 rs 支持额外选择器格式,基于集。在功能上,两种形式的选择器–执行相同—的作业,选择具有匹配标签的盒:

将创建一个 rs,并启动一个盒式箱,就像 rc 将做什么一样。如果比较 kubectl describe在两个对象上:

您可以看到,大多数情况下输出是相同的,只是选择器格式例外。您还可以按照与使用 rc 相同的方式扩展 rs:

在迁移到下一个对象之前,请先删除 rs:

部署

您可能会疑惑为什么 Kubernetes 具有不同的对象来完成几乎相同的工作。前面已提到,rc 的功能已通过 rs 和部署扩展。我们’已看到 rs,该操作与 rc 作业相同,只有选择器格式不同。现在,’我们将查看另一个新对象,部署–部署,并探索 it 的功能。

创建部署

如果您只是将 kind 属性从 ReplicaSet 更改为部署’,您将获得部署对象的 YAML 文件:

使用以下方式创建部署 kubectl命令:

实际上,部署比 rc 和 rs 的抽象级别相对较高。部署不直接创建 pod,说明命令会显示:

部署工作流

创建部署时,将自动创建副本集。部署对象中定义的盒将由部署’replicaset 创建和监督。

工作流如Figure 2所示:

Figure 2: 部署工作流
部署工作流

您可能仍在疑惑为什么您需要 rs 作为部署和 pod 之间的’一个更多层,并在下一步回答。

滚动更新

滚动更新功能是随部署对象提供的功能更强大的特性之一。让’我们通过测试案例展示该功能,解释其工作原理。

Note

事实上,旧 rc 对象也存在类似的滚动更新功能。与部署支持的新版本相比,实施的缺点非常多。在这本书中,我们将重点放在部署的新实施上。

测试案例:滚动更新

假设您有 nginx-deployment,副本 = 3 和 pod 图像1.7.9。我们希望将图像从版本1.7.9 升级到新的映像版本1.9.1。借助 kuberctl,您可以使用设置图像选项并指定新版本编号来触发更新:

现在再次检查部署信息:

您可以在此处看到两种更改:

  • 部署中的映像版本已更新

  • 创建了新的 rs nginx-6fdbb596db,副本设置为1

而将副本的 new rs 转换为1,现已生成新的 pod (第四个):

新箱采用新图像:

尽管旧的盒仍有旧图像:

’等待,并持续检查盒的状态…最终会终止所有旧盒,并有三个新盒运行–盒名称确认它们是新的:

因此更新已完成,所有盒现在都使用新版本的映像运行。

工作原理

请稍候,这不会更新,这应该称为更换,因为 Kubernetes 使用三个新箱和新图像来更换旧箱!确切地说,这是真的。但这正是它的工作原理。Kubernetes’的理念是该箱的成本很低,更换很–容易想象在您必须登录每个 pod 时,卸载旧映像,清理环境,只需安装新映像即可。让’我们来了解有关此过程的更多详细信息,理解为什么称之为滚动更新。

使用新软件更新盒时,该部署对象引入了新的 rs,将启动 pod 更新过程。此处的想法是登录现有盒,而是就地更新,而是采用全新的 rs,在其中创建新的软件版本。一旦此新(及附加)的 pod 启动并运行,原始 rs 将按1缩小,因此运行中的盒总数量保持不变。新 rs 将继续向上扩展,原始 rs 将按1向下扩展。此过程将重复执行,直至由 new rs 创建的盒数达到部署中定义的原始副本编号,这是所有原始 rs 盒均已终止。Figure 3中描绘了这一过程。

Figure 3: 部署概述
部署概述

您可以看到,整个创建新 rs、扩展新 rs 和同时横向扩展的过程都是完全自动化的,由部署对象负责。部署是部署和驱动 ReplicaSet 对象的,这种方式在这一点上只是作为后端工作。

这就是部署在 Kubernetes 中被视为高层对象的原因,也是为了不进行部署而绝对建议您从未单独使用 ReplicaSet 的原因。

录音

部署还能够记录整个滚动更新进程,因此如果需要,您可以在更新作业完成后查看更新历史记录:

暂停/恢复/撤消

此外,您还可以暂停/继续更新过程以在继续之前验证更改:

您甚至可以在维护期间发生问题时撤消更新:

通常,您可以在部署中的某些部分发生故障时执行此操作。与在过去的几天内为软件升级做好准备所需的工作量相比,对于从软件升级获得的任何人来说,这是一项惊人的功能!

Tip

这与 Junos 回滚幻命令非常相似,您在需要快速恢复对路由器所做的更改时,您可能会在每天使用它。

机密

所有现代网络系统都需要处理平台中的敏感信息,如用户名、密码、SSH 密钥等。这同样适用于 Kubernetes 环境中的箱。但是,在 pod 规格中公开此信息可能会带来安全问题,您需要一种工具或方法来–至少尽可能避免明文凭据。

Kubernetes 机密对象专为此目的–而设计,对所有敏感数据进行编码,并以可控方式将其暴露给 pod。

Kubernetes 机密的官方定义是:

"机密是包含少量敏感数据(如密码、标记或密钥)的对象。此类信息可能被置于 Pod 规格中或图像中;将其放在一个机密对象中可以更好地控制它的使用方式,并降低意外暴露的风险。 "

用户可以创建机密,而系统也会创建机密。要使用机密,pod 需要参考机密。

有许多不同类型的机密,每个都为特定用例提供服务,也有许多方法可以创建机密和在盒中引用它的许多不同方式。有关机密的完整讨论超出了本书的范畴,请参阅官方文档以获取所有详细信息并跟踪所有最新更改。

我们’来看一些常用的机密类型。您还将学习多种方法来创建机密以及如何在盒中参考。一旦到达本部分的结尾,您就应该了解 Kubernetes 秘密对象的主要优势,以及它如何帮助您提高系统安全性。

让’我们从几个秘密术语开始:

  • 透明:这种类型的机密可以包含任意键值对,因此将其视为来自 Kubernetes’透视的非结构化数据。所有其他类型的机密都有常量内容。

  • Kubernetes.io/Dockerconfigjson: 这种类型的机密用于通过私有容器注册表(例如 Juniper 服务器)进行身份验证,以提取您自己的私有映像。

  • TLS:TLS 密码包含 TLS 私有密钥和证书。它用于保护入口。您将在第4章中看到一个带 TLS 密码的入口示例。

  • Kubernetes.io/service-account-token: 当在盒的容器中运行的进程访问 API 服务器时,必须将其身份验证为特定帐户(例如,默认情况下为默认帐户)。与盒式箱关联的帐户称为服务帐户。Kubernetes.io/service-account-token 类型的密码包含有关 Kubernetes 服务帐户的信息。’我们不会在这本书中详细阐述这种类型的机密和服务帐户。

  • 透明秘密:类型不透明的秘密表示用户负责–的某种敏感数据,例如用户名、密码、安全 pin 等,这就是您认为敏感的任何内容,并且您希望携带到您的 pod 中。

定义不透明秘密

首先,为了使我们的敏感数据看起来更不’敏感,让我们用 base64 工具对其进行编码:

然后将编码版本的数据放入一个机密定义 YAML 文件中:

或者,您可以使用 kubectl CLI 直接定义与原义选项相同的机密:

无论采用哪种方式,都将产生秘密:

参考不透明秘密

接下来,您将需要在盒中使用该机密,并且密码中包含的用户信息将携带到盒中。如上所述,在盒中使用不同的方法来参考不透明的机密,并且相应地,结果将有所不同。

通常,从机密传输的用户信息可能出现在以下某种形式的容器中:

  • 文本文件

  • 环境变量

现在,’让我们来演示如何使用 secret 在容器中生成环境变量:

从该 YAML 文件中生成盒和容器:

在容器中登录并验证生成的环境变量:

使用 base64 编码的原始敏感数据现在存在于容器中!

Dockerconfigjson 密码

如名称所示,dockerconfigjson 密码表示,携带 Docker 帐户证书信息通常存储在一个 Docker/.config 文件中。Kubernetes pod 中的图像可能指向私有容器注册表。在这种情况下,Kubernetes 需要使用该注册表对其进行身份验证,以便获取映像。Dockerconfigjson 类型的机密专为这种目的而设计。

Docker 凭据数据

创建 kubernetes.io/dockerconfigjson 类型的秘密最简单的方法是使用 kubectl 命令直接提供登录信息,然后让它生成机密:

验证密钥创建:

Note

只有输出中的第一行是您刚创建的密码。第二行是 kubernetes.io/service-account-token 类型的机密,Kubernetes 系统在 contrail 设置启动并运行时自动创建。

立即检查机密的详细信息:

毫无疑问,’明文形式看不到任何敏感信息。输出的数据部分可以看到一个非常长的字符串作为项的值:dockerconfigjson. 其外观似乎已从原始数据转换而来,但至少在使用机密的一个目的是为了–提高系统安全性之后,它再也不包含敏感信息。

但是,这种转换是通过编码而非加密实现的,因此仍有一种方法可以手动检索原始敏感信息:只需将 key 的值 dockerconfigjson 至 base64 工具,原始用户名和密码信息将再次可见:

此输出中有一些突出内容:

  • Python-mjson。工具用于在显示到终端之前格式化解码的 json 数据。

  • 有一个授权键值对。根据您提供的身份验证信息(用户名和密码)生成的令牌。

  • 稍后,当配备此机密时,pod 将使用此令牌,而不是用户名和密码来向私有 Docker 注册表 hub.juniper.net 进行身份验证,以便获取 Docker 图像。

Tip

以下’是直接从机密对象解码数据的另一种方法:

T4000 路由器不支持 --output=xxxx选项过滤 kubectl get 输出,因此仅显示数据 dockerconfigjson 下的值。然后将该值管道转换为 base64,并提供选项解码(d 的别名)以使其解码。

手动创建的 docker 注册表机密仅适用于单个私有注册表。要支持多个私有容器注册表,您可以从 Docker 凭据文件创建一个机密。

Docker 凭据文件(~/。Docker/配置 json)

作为密钥名称。 dockerconfigjson 在我们创建的秘密中指示,它与 Docker 配置文件具有类似的角色:docker/配置 json。实际上,您可以直接从 Docker 配置文件生成机密。

要生成 Docker 证书信息,请先检查 Docker 配置文件:

这里’没有真正的内容。根据设置的用法,您可能看到不同的输出,但点是每次 docker 登录新注册表时,此 Docker 配置文件都将自动更新:

文件 mydockerpass 是用户名 JNPR-FieldUser213 的登录密码。将密码保存在文件中,然后使用带密码 stdin 选项将其输送到 docker 登录命令,这一优势在于无法在外壳历史记录中公开密码明文。

Tip

如果您希望可以直接写入密码,您将得到一个友好警告,表明这种情况不安全。

现在,Docker 凭据信息将在更新的 config.jsonfile

登录过程创建或更新 config.json保存授权令牌的文件。让’我创建一个秘密,从 .docker/config.jsonfile

YAML 文件

您也可以按照创建其他对象(如服务或入口)的相同方式,直接从 YAML 文件创建机密。

要手动编码 .docker/config.jsonfile

然后将 base64 编码的值放在 .docker/config.json文件 as YAML 文件下面的数据:

请记住,base64 是关于编码的,而不是–加密,而是将其视为纯文本。因此共享此文件会损害此秘密。

在盒中参阅密码

创建机密后,可通过 pod/rc 或部署来引用它,以便从私有注册表中提取映像。引用机密的方法有很多。本节将使用 pod 规范下的 imagePullSecrets 来参考机密。

ImagePullSecret 是一种将包含 Docker (或其他)图像注册表密码的秘密传递给 kubelet 的方法,以便它可以代表您的盒式拉动私人图像。

创建一个从专用存储库中拉入 Juniper cSRX 容器的盒:

现在,生成盒:

CSRX 已启动并正在运行:

在幕后,pod 将自身向专用注册表进行身份验证,提取图像,然后启动 cSRX 容器:

从我们的测试中看到,机密对象是独立于箱创建的,而检查对象规范不会直接在屏幕上提供敏感信息。

机密不会写入磁盘,而是存储在 tmpfs 文件系统中,而只保存在需要它们的节点上。此外,在删除依赖于其上的 pod 时,机密也会被删除。

在大多数本机 Kubernetes 分配上,用户与 API 服务器之间的通信由 SSL/TLS 保护。因此,通过这些通道传输的密钥得到适当保护。

任何给定的 pod 都不能访问另一个 pod 使用的机密,这有助于在不同的盒上封装敏感数据。盒中的每个容器都必须在其volumeMounts中请求一个密钥卷,以便使其在容器内可见。此功能可用于在 pod 级别构建安全分区。

服务

当 pod 实例化、终止并从一个节点移至另一个时,在做更改其 IP 地址的过程中,我们是如何跟踪来从盒中获得不间断功能的?即使该 pod’未在移动,流量如何通过单个实体到达箱组?

这两个问题的答案都是 Kubernetes服务

服务是定义一组逻辑箱和策略的抽象,您可以通过它访问它们。将服务视为您在大餐馆–’中的等待者不会烹饪,而是’一种对厨房中 happing 的一切的抽象化,您只需处理这种单个等待方即可。

服务是一种第4层负载平衡器,通过特定 IP 和端口公开 pod 功能。服务和箱通过 rs 等标签链接。’以及三种不同类型的服务:

  • ClusterIP

  • NodePort

  • 路复

ClusterIP 服务

ClusterIP 服务是最简单的服务,如果未指定 ServiceType,则为默认模式。Figure 4显示了 clusterIP 服务如何工作。

Figure 4: ClusterIP 服务
ClusterIP 服务

您可以看到 ClusterIP 服务在 clusterIP 和服务端口上公开。当客户端盒需要访问服务时,它会向此 clusterIP 和服务端口发送请求。如果所有请求都来自同一个群集,则此模型发挥良好作用。ClusterIP 的性质将服务的范围限制在群集内。总而言之,默认情况下,clusterIP 无法从外部到达。

创建 ClusterIP 服务

YAML 文件看起来非常简单,而且一目了然。它定义了 service/service-web-clusterip借助服务端口8888,映射到 targetPort,即在某些盒中的容器端口80。该选择器指示具有标签和应用程序的任何盒中:web 服务器将为后端箱响应服务请求。

好了,现在生成服务:

使用 kubectl快速验证服务和后端 pod 对象的命令:

已成功创建服务,但没有用于服务的箱。这是因为没有盒有标签与服务中的选择器匹配。因此您只需创建一个带正确标签的盒。

现在,您可以直接定义一个盒中的 pod,但由于前面讨论了 rc 和部署,因此使用 rc 或部署更实用(不久您会’发现原因)。

例如,让我们’定义一个名为 Web 的部署对象:

部署 web 还是有一个标签应用程序:web 还是匹配 selector在我们的服务中定义。T4000 路由器不支持 replicas可以:1指示控制器目前仅启动一个盒。让’我们来看:

立即将盒选为后端。

有关上一节的其他简要总结 kubectl get svc命令输出为:

  • 该服务获得从服务 IP 池分配的10.101.150.135 的 clusterIP 或服务 IP。

  • 服务端口为8888,如 YAML 中定义的。

  • 默认情况下,如果未在 YAML 文件中声明协议类型,则为 TCP。您可以使用协议:UDP 来声明 UDP 服务。

  • 可通过标签选择器找到后端盒。

Tip

此处显示的示例使用基于等号的选择器(-l)来定位后端箱,但您也可以使用基于集的语法来存档相同的效果。例如: kubectl get pod -o wide -l 'app in (webserver)'.

验证 ClusterIP 服务

要验证服务是否确实有效,让’s 启动另一盒作为客户端,以便向服务启动 HTTP 请求。对于此测试,我们’将启动并登录一个客户端箱,并使用卷曲命令向服务发送 HTTP 请求。您’将看到在整个书籍中用作客户端发送请求的同一盒 pod:

创建客户端箱:

Tip

客户端箱只是基于完全相同的图像的另一个衍生箱,它是 web 机部署及其盒的任意配置。这与物理服务器和虚拟机相同:无需阻止服务器执行客户端’工作:

面向服务的 HTTP 请求到达运行 web 服务器应用程序的后端箱,其响应 HTML 页面。

为了更好地说明哪个盒提供服务,让’我们设置自定义的 pod 图像来运行简单的 web 服务器。Web 服务器的配置方式是,在接收请求时,它将返回一个简单的 HTML 页面,其中包含本地 pod IP 和主机名嵌入。这样,卷曲在我们的测试中就会返回更有意义的东西。

返回的 HTML 看起来相对容易阅读,但有一种方法可以使其更易于查看:

W3m 工具是安装在主机中的基于轻量级控制台的 web 浏览器。借助 w3m,您可以将 HTML 网页呈现为可比 HTML 页面更易阅读的文本。

现在,服务已验证完毕,已将服务请求重定向至正确的后端,带有 pod IP 10.47.255.238 和 pod-7c7c458cc5-vl6zs。

指定 ClusterIP

如果您希望拥有特定 clusterIP,可以在规范中提及。IP 地址应在服务 IP 池中。

下面’是一些具有特定 YAML 的示例 clusterIP可以:

NodePort 服务

NodePort 的第二类通用服务在静态端口上公开每个节点’IP 的服务。它将每个节点上的静态端口映射为盒上的应用程序端口,如Figure 5所示。

Figure 5: NodePort 服务
NodePort 服务

以下是此服务 YAML 文件中的一些要点:

  • selector可以:标签选择器,用于确定此服务的目标是哪一组箱。在此,带有标签应用程序的任何盒:web 服务器将由此服务作为后端选择。

  • Port可以:这是服务端口。

  • TargetPort可以:容器中应用程序使用的实际端口。’这里是端口80,因为我们计划运行 web 服务器。

  • NodePort可以:集群中每个节点的主机上的端口。

让’我们创建服务:

  • 类别默认服务类型为 ClusterIP. 在此示例中,我们将类型设置为 NodePort.

  • NodePort可以:默认情况下,Kubernetes 在30000-32767 范围内分配节点端口(如果在规格中未提及)。可使用标志 --service-node-port-range. T4000 路由器不支持 NodePort还可以设置值,但确保其’在配置的范围内

  • Endpoints可以:PodIP 和暴露的容器端口。对服务 IP 和服务端口的请求将定向到此处,10.47.255.252:80表示我们创建了一个与服务具有匹配标签的盒式箱,因此其 IP 被选为 backends 之一。

Note

对于此测试,请确保至少有一盒带有标签 app:webserver运营. 前几节中的箱都使用此标签创建。如果’已卸下客户端箱,请重新创建 suffices。

现在,我们可以通过使用卷曲命令触发向任何节点 IP 地址发出的 HTTP 请求来对此进行测试:

凭借 NodePort 服务的强大功能,您可以通过 nodePort 32001 从任何节点访问盒中运行的 web 服务器:

负载平衡器服务

第三项服务是负载平衡器服务,通过使用云提供商’的负载平衡器在外部公开服务,以超越 NodePort 服务的一步。负载平衡器服务的性质自动包括 NodePort 和 ClusterIP 服务的所有特性和功能。

在云提供商上运行的 Kubernetes 群集支持自动配置负载平衡器。这三种服务之间的唯一区别在于类型值。要重用相同的 NodePort 服务 YAML 文件并创建负载平衡器服务,只需将类型设置为 LoadBalancer:

云将看到此关键字,并将创建负载平衡器。同时,分配了一个外部公共负载 balancerIP 作为前端虚拟 IP。进入此 loadbalancerIP 的流量将被重定向至服务后端盒。请记住,此重定向过程只是传输层操作。LoadbalancerIP 和端口将转换为私有后端 clusterIP 和 it’targetPort。它不涉及任何应用层活动。无需分析 URL、代理 HTTP 请求等内容,如 HTTP 代理进程中发生的情况。由于 loadbalancerIP 可公开访问,因此任何可访问它的 Internet 主机(以及服务端口)都可以访问 Kubernetes 群集提供的服务。

从互联网主机’角度来看,在请求服务时,它会将此公共外部 loadbalancerIP plus 服务端口,并且请求将到达后端盒。LoadbalancerIP 作为集群和外部世界内服务之间的网关。

一些云提供商允许您指定 loadBalancerIP. 在这些情况下,使用用户指定的 loadBalancerIP 创建负载平衡器。如果未指定 loadBalancerIP 字段,则使用临时 IP 地址设置负载平衡器。如果您指定 loadBalancerIP 但您的云提供商不支持该功能,则将忽略您设置的 loadbalancerIP 字段。

负载平衡器服务中实施负载平衡器的方式取决于供应商。GCE 负载平衡器可通过 AWS 负载平衡器以完全不同的方式工作。在第4章的 Contrail Kubernetes 环境中有负载平衡器服务工作原理的详细演示。

外部 Ip

在集群之外公开服务也可通过 externalIPs选项。下面’是一个示例:

Service规格、externalIPs 可与任何服务类型一起指定。外部 Ip 不由 Kubernetes 管理,并且是群集管理员的责任。

Note

外部 Ip 与 loadbalancerIP (由群集管理员分配的 IP)不同,外部 Ip 随附由支持它的群集创建的负载平衡器。

服务实施:Kube-代理

默认情况下,Kubernetes 使用 kube-proxy 模块进行服务,但 CNI 提供商可以拥有自己的服务实施。

可采用以下三种模式之一部署 Kube 代理:

  • 用户空间代理模式

  • iptables 代理模式

  • ipvs 代理模式

当信息流击中节点时,它’会通过已部署的 kube 代理转发平面转发至后一个后端箱。这三种模式的详细解释和比较将不在本书中介绍,但您可以查看 Kubernetes 官方网站以了解更多信息。第4章说明了 Juniper Contrail 作为容器网络接口(CNI)提供商如何实施服务。

端点数

目前我们’没有探讨过的一个对象:EP 或端点。我们’已经了解到,带有匹配标签的特定盒或一组盒后的箱被选为后端通过标签选择器,因此服务请求流量将被重定向到它们。匹配箱的 IP 和端口信息在端点对象中维护。箱可能会被凹下,并且会发生任何时候,盒式 mortal 的本质很可能会导致新的箱使用新 IP 地址 respawned。在此动态进程中,端点将始终相应更新,以反映当前后端 pod IPs,从而使服务信息流重定向正常运行。(拥有自己的服务实施的 CNI 提供商基于端点对象更新服务的后端。)

下面的示例演示使用匹配标签验证服务、对应端点和盒式文档的一些快速步骤。

要创建服务:

要列出端点:

要查找带选择程序使用的标签的盒箱:

最后,扩展后端箱:

现在再次检查端点,您将看到它们会相应更新:

不带选择器的服务

在上面的示例中,每次创建服务时,Kubernetes 系统都会自动生成端点对象,并且存在至少一个具有匹配标签的盒。但另一个端点用例是定义标签选择器的服务,您可以通过手动添加端点对象将服务手动映射到网络地址和端口’。然后,您可以将端点与服务连接。在某些情况下,这可能非常有用,例如,在物理服务器中运行后端 web 服务器的设置中,您仍希望将其集成到 Kubernetes 服务中。在这种情况下,您只需照常创建服务,然后创建一个具有指向 web 服务器的地址和端口的端点。这’正是该服务不关心后端类型,它只是重定向服务请求流量的方式与所有后端都是 pod 的方法完全相同。

入口

现在,您’已经发现向群集外部客户端公开服务的方法,另一种方法是入口。在 "服务" 部分,服务在传输层中工作。事实上,您可以通过 Url 访问所有服务。

入口或短路是 Kubernetes 的另一个核心概念,它允许 HTTP/HTTPS 路由不存在于服务中。入口建立在服务之上。通过入口,您可以定义基于 URL 的规则,将 HTTP/HTTPS 路由分发到多个不同的后端服务,因此入口通过 HTTP/HTTPS 路由公开服务。之后,请求将转发到每个与服务’对应的后端箱。

入口与服务

负载平衡器服务与入口之间存在相似性。两者都可以在集群之外公开服务,但有一些显著的差异。

操作层

入口在 OSI 网络模型的应用层运行,而服务仅在传输层运行。入口了解 HTTP/HTTPS 协议,仅服务基于 IP 和端口的 enacts 转发,这意味着它不关心应用层协议(HTTP/HTTPS)的详细信息。入口可以在传输层操作,但服务也会执行相同的操作,因此’,除非有特殊原因,否则入口也没有意义。

转发模式

入口与传统 web 负载平衡器有很大的作用,就是应用层代理。在计算机 A (客户端)和 B (服务器)之间的典型 web 负载平衡器代理在应用层工作。它了解应用层协议(HTTP/HTTPS),以便客户端与服务器的交互对负载平衡器透明。基本上,它使用源、(A)和目标(B)、机器创建两个连接。计算机 A 甚至不知道计算机 B 是否存在。对于计算机 A,代理是与其合作的唯一一件,并不关心代理获取其数据的方式和位置。

公共 Ip 的数量。

如果入口直接暴露在群集外部,则它们的每个服务都需要一个公共 IP。当入口面向所有这些服务的前端时,一个公共 IP 就足够了,这使得云管理员可以轻松实现生命。

入口对象

在进入有关入口对象的详细信息之前,了解 YAML 定义的最佳方式是:

您可以看到它看起来非常简单。该规范仅定义了一–项规则。这些规则表示一个主机(此处为 Juniper URL)在 URL 字符串中可能有两个可能的路径。此路径是 URL 中的主机后面的任何内容,在此情况下,它们为/dev 和/qa。每个路径随后将与不同的服务相关联。当入口发现 HTTP 请求到达时,会将信息流代理至关联后端服务的每个 URL 路径。就像我们’在本服务部分中学到的服务一样,将向其相应的后端路径提供请求。就’是这样。实际上,这是 Kubernetes 支持当今–简单扇出入口的三种类型的入口之一。其他两种类型的入口将在本章稍后讨论。

关于 URL、主机和路径

术语主机和路径在 Kubernetes 入口文档中经常使用。主机是服务器的完全限定域名。该路径或 url 路径是位于 URL 中的主机之后的字符串部分的其余部分。如果大小写为在 URL 中包含端口,则是端口的字符串。

请看下面的 URL:

主机是 www.juniper.net,在本例中,端口1234称为路径、my/resource。如果 URL 没有端口,则主机后面的字符串就是路径。有关更多详细信息,您可以阅读 RFC 1738,但为了实现这本书的目的,了解此处引入的内容就足够了。

如果您现在认为 Kubernetes 入口只定义了一些规则,并且规则只是指示系统根据 Url 将传入请求定向到不同服务,则您基本上是从较高层面开始。Figure 6显示了这三个 Kubernetes 对象之间的 interdependency:入口、服务和箱。

Figure 6: 入口、服务和箱
入口、服务和箱

实际上,您还需要了解其他一些事项,以便处理入向规则,您至少需要一个称为入口控制器的组件。

入口控制器

入口控制器负责读取入站规则,然后将规则编程到代理中,这样做实际工作–基于主机/URL 调度信息流。

入口控制器通常由第三方供应商实施。不同的 Kubernetes 环境根据群集的需求具有不同的入口控制器。每个入口控制器都有自己的实施来对入口规则进行编程。底线是,群集中必须运行一个入口控制器。

某些入口控制器提供商包括:

  • nginx

  • gce

  • haproxy

  • avi

  • f5

  • istio

  • 工时

您可以在一个集群中部署任意数量的入口控制器。创建入口时,应使用适当的入口为每个入口加注释。类,用于指示应使用哪个入口控制器(如果您的群集中存在不止一个)。

入口对象中使用的注释将在注释部分中说明。

入口示例

有三种类型的 ingresses:

  • 单一服务入口

  • 简单 Fanout 入口

  • 基于名称的虚拟托管入口

我们’看过简单的 fanout 入口,因此现在让我们’来看另两种类型的入口的 YAML 文件示例。

单一服务入口

这是最简单的入口形式。入口将获得外部 IP,因此该服务可以公开给公众,但是没有定义规则,因此不会分析 Url 中的主机或路径。所有请求都将转到同一服务。

简单 Fanout 入口

我们在本节开头部分检查了这一点。与单一服务入口相比,简单的 fanout 入口更切实可行。它’不仅能够通过公共 IP 公开服务,还能根据路径进行 URL 路由或扇出。当公司想要基于域名后的 URL 后缀将信息流定向到其每个部门’的专用服务器时,这是一种非常常见的使用方案。

虚拟主机入口

基于名称的虚拟主机类似于简单的 fanout 入口,因为它能够执行基于规则的 URL 路由。此类入口的独特威力是支持路由到相同 IP 地址的多个主机名称的 HTTP 信息流。此处的示例可能不可行(除非一天是两个域合并!),但足以展示这一想法。在 YAML 文件“中,分别定义了两个主机、 “juniperhr”和junipersales” URL。即使仅使用一个公共 IP 分配入口,基于 URL 中的主机,指向相同公共 IP 的请求仍将路由到不同的后端服务。这’就是为什么称之为虚拟托管和’第4章中进行了非常详细的案例研究的原因。

Note

还可以将简单的 fanout 入口和虚拟主机合并到一个中,但此处不介绍详细信息。

多个入口控制器

一个集群中可以有多个入口控制器,但是群集需要知道哪一个处于选择。例如,在第4章中’,我们将讨论’Contrail 的内置入口控制器,而不会阻止我们安装另一个第三方入口控制器,如 nginx 入口控制器。而是让两个入口控制器在同一个集群中,名称如下:

  • opencontrail (默认)

  • nginx

Contrail’是默认实施,因此您’无需特别选择。要将 nginx 选择为入口控制器,请使用此注释。Kubernetes.io/ingress.class:

这将告诉 Contrail’的入口控制器 opencontrail 忽略入口配置。

Kubernetes 网络策略

默认情况下,Kubernetes 网络模型要求所有盒都能够访问所有其他盒。这称为平面网络,因为它遵循允许任意模式。它显著简化了 Kubernetes 网络的设计和实施,使其更具可扩展性。

Note

第4章详细介绍了 Kubernetes 对网络实施实施的要求。

安全性是一个重要的考虑因素。事实上,在许多情况下,需要特定级别的网络分段方法来确保只有某些箱可以相互交谈,这是 Kubernetes 网络策略进入此图片的时候。Kubernetes 网络策略定义了盒组的访问权限,其方式与云中的安全组用于控制对虚拟机实例的访问相同。

Kubernetes 通过 NetworkPolicy 对象支持网络策略,这是一种 Kubernetes 资源,就像在本章前面学到的箱、服务’、入口和其他许多人一样。网络策略对象的作用是定义允许各组盒之间相互通信的方式。

让’我们来探讨 Kubernetes 网络策略的工作原理:

  1. 1Initially 在 Kubernetes 集群中,默认情况下所有盒都是非隔离的,它们在允许任何模型中工作,因此任何盒都可与任何其他 pod 通信。

  2. 2. 立即将名为 policy1 的网络策略应用于 pod A。在策略 policy1 中,您定义了一条规则,明确允许盒 A 与 pod B 交谈。在这种情况’下,让 s 呼叫箱成为一个目标盒箱,因为它是网络策略将作用于的盒。

  3. 3. 从此时起,将发生以下情况:

    • 目标箱 A 可与 pod B 交谈,并且只能与Pod b通信,因为 B 是您在策略中只允许使用的一盒。由于策略规则的性质,您可以将规则称为白名单

    • 仅限目标 pod A,此网络策略 policy1 白名单中未明确允许的任何连接都将被拒绝。’您无需在 policy1 中明确定义它,因为它将由 Kubernetes 网络策略的性质实施。让’我们将此隐式策略称为 "拒绝所有策略"。

    • 对于其他非目标盒(例如,不应用于 policy1 的 pod B 或 pod C)以及任何其他网络策略,将继续遵循允许任意模式。因此,它们不会受到影响,并且可以继续与群集中的其他所有盒通信。这是另一个隐式策略,允许所有策略。

  4. 如果您还希望 pod A 能够与 pod C 通信,则需要更新网络策略 policy1 及其规则以明确允许。换句话说,您需要不断更新白名单以允许更多的流量类型。

您可以看到,在定义策略时,群集中至少会应用三个策略:

  • 显式 policy1:这是您定义的网络策略,并且白名单规则允许所选(目标)盒的某些类型的流量。

  • 隐式拒绝所有网络策略:这将拒绝目标盒中不在白名单中的所有其他流量。

  • 隐式允许所有网络策略:这将允许 policy1 未选择的其他非目标盒式箱的所有其他流量。我们’将在第8章中看到 "全部拒绝" 并再次允许所有策略。

以下是 Kubernetes 网络策略的一些要点。

  • 盒专用:网络策略规格应用于基于标签的一盒或一组箱,与 rc 或 Deploy 的方式相同。

  • 基于白名单的规则:构成白名单的显式规则,每条规则描述了允许的特定类型的信息流。对于目标盒,白名单中任何规则未说明的所有其他流量都将被丢弃。

  • 隐式允许全部:仅当一个盒被网络策略选择为目标时,它才受影响,并且仅通过选择网络策略才会受到影响。如果没有在盒上应用的网络策略,则表示隐式允许所有策略到此盒。换句话说,如果非目标盒继续其 "允许-任意-任意网络" 模式,

  • 分离入口和出口:需要为特定方向定义策略规则。方向可以是入口、出口、无或两者。

  • 基于信息流(与基于数据包):一旦允许启动数据包,也将允许在相同流中返回数据包。例如,假设在盒 A 上应用的入站策略允许入口 HTTP 请求,则会对 pod A 允许整个 HTTP 交互。这包括三路 TCP 连接和所有数据和确认均在两个方向上建立。

Note

网络策略由网络组件实施,因此您必须使用支持网络策略的网络解决方案。只需创建没有控制器即可实施的 NetworkPolicy 资源将不会产生任何影响。在这本书中 Contrail 是实施网络策略的网络组件。在第8章中’,您将了解这些网络策略如何在 Contrail 中工作。

网络策略定义

与 Kubernetes 中的所有其他对象一样,网络策略也可在 YAML 文件中定义。我们’来看一个示例(第8章将使用同一示例):

让’我们来回顾一下这个 YAML 文件的规格部分,因为其他部分会有自我说明。该规范具有以下结构:

在这里,您可以看到网络策略定义 YAML 文件可以逻辑分为四个部分:

  • podSelector: 这将定义盒中选择。它识别将应用当前网络策略的盒。

  • policyTypes: 指定策略规则的类型:出入或出口。

  • 入口定义了目标箱的入口策略规则。

  • 进出定义了目标盒的出口政策规则。

接下来’,我们将详细介绍每个部分。

选择目标箱

定义网络策略时,Kubernetes 需要了解您希望此策略作用于哪个盒。与服务选择其后端箱的方式类似,网络策略将根据以下标签选择要应用的盒式机箱:

在此,所有带有标签的盒箱都 app: webserver-dev被网络策略选择为目标箱。以下规格中的所有内容将仅适用于目标盒。

策略类型

第二部分定义 policyTypes对于目标箱:

PolicyTypes 可以是入口、出口或两者。并且两种类型都以一个或多个规则的形式定义特定的信息流类型,如下面所述。

政策规则

入口和出口部分定义从选定的目标箱’角度来看流量的方向。例如,考虑以下简化示例:

假定目标 pod 是 web 的-协同开发箱,并且在具有匹配标签 client1 的集群中只有一个 pod client1-dev,将发生两件事:

  1. 入口方向:pod web 还是开发人员可接受从 pod client1 发起的目标端口80的 TCP 会话。这解释了我们为何说 Kubernetes 网络策略基于流,而不是基于数据包。无法建立 TCP 连接如果策略将基于数据包设计,因为在接收传入的 TCP 同步时,如果没有匹配的出口策略,则返回的传出 TCP 同步确认将被拒绝。

  2. 出口方向:pod web 使用-dev 可启动与 pod client1 开发的 TCP 会话(目标端口8080)。

Tip

对于要浏览的出口连接,另一端需要定义入口策略以允许传入连接。

网络策略规则

Each or for 语句在网络策略中定义规则:

  • 从语句定义入口策略规则。

  • A 到语句定义出口政策规则

  • 两个规则都可以选择具有端口语句,稍后将对其进行讨论。

因此,您可以定义多个规则,以便为每个方向提供复杂的流量模式:

每条规则标识了目标箱可通信的网络端点。网络端点可通过不同方法识别:

  • ipBlock: 基于 IP 地址块选择箱。

  • namespaceSelector: 根据名称空间的标签选择箱。

  • podSelector: 根据盒式标签选择箱。

Note

PodSelector 在 YAML 文件的不同位置使用时,会选择不同的事物。以前(在规范下)它选择了网络策略适用于的盒,这’是我们以前称为目标箱。在下面的规则中(在 "从" 或 "至" (in 或 for)),它可选择目标盒与哪个盒通信。有时我们会称之为这些箱对等互连箱端点

因此,规则的 YAML 结构可以如下所示:

例如:

此处,入口网络端点为子网 10.169.25.20/32;具有标签项目的名称空间中的所有盒:jtac盒具有以下标签应用程序:client1-当前命名空间(目标盒中为命名空间)的开发人员和出口网络点为 pod dbserver-dev。我们’很快就会进入端口部分。

AND 与 OR

它’还可以仅从命名空间指定几个箱,而不是与所有箱进行通信。在本示例中,podSelector 使用 all,它采用与目标 pod 相同的命名空间。另一种方法是将 podSelector 与 namespaceSelector 一起使用。在这种情况下,pod 所属的命名空间是具有 namespaceSelector 的标签的名称,而不是目标盒’的命名空间。

例如,假设目标 pod 为 web dev 且其命名空间为 dev,并且只有命名空间 qa 具有标签项目 = qa 匹配 namespaceSelector:

在此,目标盒只能与命名空间 qa 中的那些盒和(不带)和标签一起通信 app: client1-qa.

这里要小心,因为它与下面的定义完全不同,因此目标盒可以与以下的盒进行交谈:命名空间中 qa或(不带)替换为标签 app: client1-qa在目标 pod’命名空间中,dev:

协议和端口

此外,还可以为入口和出口规则指定端口。协议类型也可与协议端口一起指定。例如:

入口中的端口表示目标箱可以为指定端口和协议允许传入流量。出口中的端口表示目标箱可以启动到指定端口和协议的流量。如果未提及端口,则允许所有端口和协议。

逐行说明

让’我们详细了解我们的示例:

您现在应该准确了解网络策略正在尝试实施什么。

线路1-3:pod web 1-dev 是由策略选择的,因此是目标箱;所有以下政策规则将应用于其上,并且仅在其上。

线路4-6:该策略将定义入口和出口流量的规则。

线路7-19:入口部分定义入口策略。

第8行:从:和第17行:端口,这两个部分在入口策略上定义一个策略规则。

线路9-16:以下八行:部分组成入口白名单:

  • 线路9-10:源 IP 为 10.169.25.20/32 的任何传入数据都可以访问目标 pod web 开发。

  • 线路11-13:namespace jtac 下的任何盒都可访问目标 pod web 开发。

  • 线路14-16:任何带标签 client1 的箱都可以访问目标盒 web 还是开发的。

线路17-19:端口区段是相同策略规则的第二个(也是可选的)部分。目标 pod web services 上仅 TCP 端口80(web 服务)-dev 已公开且可访问。对所有其他端口的访问将被拒绝。

线路20-26:进出部分定义出口政策。

线路21:可以:和第24行:端口,这两个部分在出口策略中定义一个策略规则。

  • 线路21-24:以下四行:部分组成出口白名单时,目标盒可向 pod dbserver 发送出口流量。

第25行:端口部分是同一策略规则的第二部分。目标箱 web 盒只能启动与目标端口为80的 TCP 会话至其他盒。

这并’不是全部。如果您记得本章的开头部分,我们谈到了 Kubernetes 默认的 "允许-任意-任意-任意网络模式" 和 "隐式拒绝"、"全部"、"全部"、"全部"、"全部之后,还有两个更隐的策略:

拒绝所有网络策略:对于目标 pod web 的开发人员,拒绝以上白名单中明确允许的所有其他流量,这意味着至少需要两个规则:

  • 入口拒绝发往目标 pod web 开发的所有传入流量,而非入口白名单中定义的内容。

  • 进出拒绝来源于目标箱 web 开发的所有传出流量,而非出口白名单中定义的信息流。

"允许所有网络策略" 允许在入口和出口方向上不是此网络策略目标的其他盒的所有流量。

Note

在第8章’中,我们将深入了解这些隐式网络策略及其在 Contrail 实施中的规则。

创建网络策略

您可以按照创建其他 Kubernetes 对象的相同方式来创建和验证网络策略:

在第8章’,我们将设置测试环境,以更详细地确认此网络策略的影响。

活动探测

如果在 pod 中的应用程序正在运行,但由于某种’原因不能为其主要用途提供服务,会发生什么情况?同时运行很长时间的应用程序也可能过渡到断开状态,如果是这种情况,则表明您最后一件是在应用程序中报告问题,可通过重新启动盒来轻松修复。活动探查是专门针对这种情况而创建的 Kubernetes 功能。活动探查会定期向盒式发送预定义请求,然后在请求失败时重新启动盒式。最常用的活动探查是 HTTP GET 请求,但也可以打开 TCP 套接字甚至发出命令。

Next 是 HTTP GET 请求探测示例,其中 initialDelaySeconds是第一次尝试向端口80发出 HTTP GET 请求之前的等待时间,然后它将运行探测,在每隔20秒的 periodSeconds. 如果此操作失败,盒将自动重新启动。您可以选择指定路径,这里仅是主要网站。您也可以使用自定义标头发送该探测。快速了解:

现在,’让 s 启动此 pod,然后登录到该盒,以终止处理 HTTP GET 请求的进程:

您可以看到盒自动重新启动,您还可以在以下活动中看到重新启动的原因:

这是 TCP 套接字探测示例。TCP 套接字探测器类似于 HTTP GET 请求探测器,但会打开 TCP 套接字:

此命令类似于 HTTP GET 和 TCP 套接字探测。但探测将在容器中执行命令:

就绪探测器

活动探查可确保您的 pod 运行状况良好,但对于某些应用程序而言’不够。某些应用程序需要先加载大型文件才能开始。您可能会觉得设置更高 initialDelaySeconds值,则问题得到解决,但这不是一个高效的解决方案。就绪探测器是一种特别适用于 Kubernetes 服务的解决方案,因为在准备就绪前,pod 将不会收到信息流。每当就绪探测失败时,将从服务中移除用于 pod 的端点,并在就绪探测器成功时重新添加。就绪探测器的配置方式与活动性探测相同:

Note

’建议同时使用就绪探测器和活动性探测器,其中活动探测器在发生故障时重新启动盒,准备情况探测可确保在获取流量之前已准备好盒。

探测参数

探测器具有许多参数,可用于更精确地控制活动和就绪检查的行为。

  • initialDelaySeconds: 启动活动或就绪探测器之前启动容器之后等待的秒数。

  • periodSeconds: 执行探测的频率(秒)。默认值为10秒。最小值为1。

  • timeoutSeconds: 探测超时的秒数。默认为1秒。最小值为1。

  • successThreshold: 在发生故障后认为成功的最短连续成功次数。默认为1。对于活动,必须为1。最小值为1。

  • failureThreshold: 当盒启动且探测失败时,Kubernetes 将尝试 failureThreshold 次,然后放弃。放弃活动探测器的情况意味着重新启动盒。对于就绪探测器,盒将标记为 Unready。默认值为3。最小值为1。

和 HTTP 探测具有可设置的附加参数 httpGet可以:

  • host可以:要连接到的主机名,默认为 pod IP。您可能希望将主机“”设置为 httpHeaders改用.

  • scheme可以:用于连接到主机的方案(HTTP 或 HTTPS)。默认为 HTTP。

  • path可以:HTTP 服务器上的访问路径。

  • httpHeaders可以:在请求中设置的自定义标头。HTTP 允许重复的标头。

  • port可以:要在容器上访问的端口的名称或编号。数字必须在1到65535的范围内。

$1

您已了解 Kubernetes 中的标签如何用于识别、选择和组织对象。但标签只是一种将元数据附加到 Kubernetes 对象的方式。

另一种方式是注释,这是将非识别元数据附加到对象的键/值映射。批注有许多用例,例如附加:

  • 用于日志记录和分析的指针

  • 电话号码、目录条目和网站

  • 时间戳、图像哈希和注册表地址

  • 网络、命名空间

  • 以及入口控制器类型

以下’是注释示例:

批注可用于将网络信息分配给 pod,在第9章中,您’将看到 Kubernetes 注释如何指示 Juniper Contrail 将接口附加到特定网络。很棒。

在查看中的注释之前,’让我们先根据实际的 Kubernetes 网络自定义资源定义,创建至少一个具有最小配置的网络。 NetworkAttachmentDefinition此处用于指示 CNI 以及我们将连接到接口盒的网络参数,例如:

T4000 路由器不支持 type, awesome-plugin是 CNI 的名称,可能是 Flannel、Calico、Contrail-K8s-CNI 等。

创建一个箱,并使用注释将其接口连接到称为 net a 的网络:

Note

根据官方 Kubernetes 网络自定义资源定义,批注 k8s.v1.cni.cncf.io/networks 用于表示 NetworkAttachmentDefinition并有两种格式:

Note

要保持与现有 Kubernetes 部署的兼容性,所有盒都必须连接到 cluster-wide默认网络,这意味着即使已将一个 pod 接口连接到特定网络,此盒也会有两个接口:一个附加到 cluster-wide默认网络,另一个连接到注释参数中指定的网络net-a在这种情况下)。