谷歌-Kubenetes-引擎高级教程-三-

谷歌 Kubenetes 引擎高级教程（三）

原文：Pro Google Kubernetes Engine

协议：CC BY-NC-SA 4.0

八、使用 Sysdig 监控 GKE

本章为读者提供了使用 Sysdig 监控容器应用的实际操作步骤，包括以下主题:

• Sysdig 监控解决方案简介

• 容器应用监控

Sysdig 监控解决方案简介

Sysdig Monitor 是一个强大的容器监控解决方案，它提供了全面的可观察性，还通过性能和容量监控提供了额外的安全性和合规性能力(使用 Sysdig Secure)。它具有提供容器可见性和与众多平台集成的现成能力，包括 Kubernetes、Docker container、谷歌 GKE、AWS EKS 和 Azure AKS。

它以软件即服务(SaaS)和内部部署软件的形式提供。

以下是 Sysdig 监视器的主要特性:

图 8-1

Sysdig 功能架构

• 简化发现和指标收集 : Sysdig 提供动态发现应用、容器、主机、网络和自定义指标的能力，例如 Prometheus、JMX 和 statsD，以便深入了解复杂的环境。

• 可视化服务可靠性 : Sysdig 提供服务性能、容量和安全风险概况的综合概述，以帮助开发人员和开发运维团队快速发现应用问题并采取行动。

• 监控基础设施和应用:利用 it 与 Kubernetes、OpenShift、Docker、Mesos、DC/OS、AWS、Google、IBM、Azure 等全面集成的能力。，Sysdig 提供基础设施之外的可见性，让您了解应用和服务的运行情况。

• 控制面板 : Sysdig 提供现成的可定制控制面板，使您能够一目了然地了解您的基础架构、应用、合规性和指标，并让您以自己想要的方式可视化您的环境。

• 主动警报以实现更快的响应 : Sysdig 提供可配置的警报，以实现对任何情况的主动通知，包括事件、停机和异常，以帮助您在问题影响运营之前对其进行处理，如图 8-1 所示。

容器应用监控

Sysdig 通过订阅许多系统内核已经在处理和发布的跟踪点，从内核级获取监控指标。这种看到容器内部的能力被称为容器视觉。它使数据捕获成为一项非常轻量级的工作(通常占用 1–3%的 CPU 资源和 500M 的系统内存)。Sysdig 基于开源的同名 Linux 故障排除和取证项目(sysdig)。开源项目允许您查看单个主机上的每个系统调用，下至进程、参数、有效负载和连接。这些数据被动态地映射到容器、微服务、云和编排器，既强大又易于使用。

为了进一步丰富用于保护您的环境的数据，Sysdig 还将 Falco & Anchore 集成到平台中，该平台允许您针对容器映像和容器实施和执行漏洞管理和安全策略，如图 8-2 所示。

图 8-2

Sysdig 容器监控架构

在 Sysdig 中，事件首先由一个名为sysdig-probe的小驱动程序在内核中捕获，它利用了一个名为 tracepoints 的内核工具。

跟踪点使得安装一个“处理程序”成为可能，这个处理程序是从内核中的特定函数调用的。目前，Sysdig 为进入和退出时的系统调用以及进程调度事件注册跟踪点。sysdig-probe的处理程序仅限于将事件细节复制到一个共享的只读环形缓冲区，并进行编码以供以后使用。可以想象，保持处理程序简单的原因是性能，因为最初的内核执行是“冻结”的，直到处理程序返回。冻结在纳秒量级。

事件缓冲区被内存映射到用户空间，因此无需任何拷贝就可以访问它，从而最大限度地减少 CPU 使用和缓存未命中。libscap 和 libsinsp 这两个库为读取、解码和解析事件提供了支持。具体来说，libscap 提供了跟踪文件管理功能，而 libsinsp 包含了复杂的状态跟踪功能(例如，您可以使用文件名而不是 FD 号)以及过滤、事件解码、运行插件的 Lua JIT 编译器等等。

Sysdig 现在还支持 eBPF(扩展的 Berkeley 包过滤器),作为前面描述的基于内核模块的体系结构的替代方案。eBPF 是一个 Linux 本地的内核 VM，它支持对应用性能、事件可观察性和分析进行安全、低开销的跟踪。

将 ContainerVision 绑定到 eBPF 有几个动机。一种是简单地利用已经是基本操作系统一部分的成熟技术。这使得对可观察性的管理变得更加容易和顺畅。eBPF 有意义的另一个原因是容器优化操作系统的出现。这些解决方案，如来自 GCP 的 COS 和由 Red Hat 领导的 Project Atomic Host，具有不可变的基础设施方法，完全不允许内核模块。通过利用 eBPF，这些较新操作系统方法的用户实现了 Sysdig 已经用内核模块交付了一段时间的容器可观察性的相同水平，如图 8-3 所示。

图 8-3

Sysdig 容器监控架构

现在让我们申请一个 Sysdig Monitor 的评估版，看看它是如何监控容器应用的。

图 8-4

Sysdig 评估请求

• 步骤 1: 导航到 https://sysdig.com ，请求 Sysdig 的评估版本。选择产品，点击今日报名按钮，如图 8-4 所示。

图 8-6

Sysdig 评估帐户激活

图 8-5

Sysdig 评估申请表

• **第二步:**填写所需信息，点击提交按钮，如图 8-5 和 8-6 所示。

图 8-7

Sysdig 评估帐户密码设置

• **第 3 步:**您将通过提供的电子邮件地址收到一个激活链接。收到邮件大约需要 30 分钟到一个小时。单击电子邮件中的激活链接，完成评估访问请求。系统将提示您为 Sysdig 设置新密码。点击激活登录按钮继续，如图 8-7 所示。

图 8-8

Sysdig 评估帐户欢迎页面

• 步骤 4: 您将被提示进入 Sysdig 欢迎屏幕。点击下一步继续，如图 8-8 所示。

图 8-10

Sysdig 评估帐户 Kubernetes 集成键

图 8-9

Kubernetes 的 Sysdig 评估帐户设置

• **第五步:**在下一个屏幕上选择 Kubernetes(图 8-9 )。选择后，您会看到一个按键(图 8-10 )。复制钥匙。我们将在本章后面使用它。

使用 GKE，我们现在将在 GCP 上设置一个集群，并将 Sysdig Monitor 与它集成，用于容器应用监控。对于本实验，我们将假设读者具备 GCP 的工作知识和一个 GCP 帐户。

开放端口 6443 供代理进出

由于 GKE 使用状态防火墙，我们必须主动为 Sysdig 代理打开端口 6443，用于入站和出站流量。

图 8-11

GCP 控制台防火墙规则

• 步骤 1: 打开 VPC 网络中的防火墙规则部分，为入站和出站流量创建新的规则，如图 8-11 所示。

图 8-12

GCP 防火墙规则创建

• **第二步:**点击【创建防火墙规则】，创建入站规则，如图 8-12 所示。

图 8-15

入站防火墙规则创建—续

图 8-14

入站防火墙规则创建—续

图 8-13

入站防火墙规则创建

• **第 3 步:**按照如下方式填写入站规则的创建防火墙规则表单:

  • 名称:给一个合适的名称

  • 日志:选择关闭选项

  • 网络:默认

  • 优先级 : 1000

  • 交通方向:入口

  • 入口用于入站流量。

  • 匹配动作:允许

  • 目标标签:提供您在集群上使用的相同目标标签。在我们这里是gke-clustertutorial-cff607d3-node。

  • 源 IP 范围 : 10.16.0.0/14(与您的集群相同)

  • 协议和端口:检查 tcp，选择端口 6443。

• 现在点击创建按钮。参见图 8-13 、 8-14 和 8-15 。

图 8-16

入站防火墙规则创建—续

• **第四步:**用您给定的名称验证创建的入站防火墙规则搜索规则，如 sysdig-agent-inbound，如图 8-16 所示。

图 8-20

出站防火墙规则创建—续

图 8-19

出站防火墙规则创建—续

图 8-18

出站防火墙规则创建—续

图 8-17

出站防火墙规则创建

• **第 5 步:**填写出站规则的创建防火墙规则表单，如下所示:

  • 名称:给一个合适的名称

  • 日志:选择关闭选项

  • 网络:默认

  • 优先级 : 1000

  • 交通方向:出口

  • 用于出站流量的出口

  • 匹配动作:允许

  • 目标标签:提供您在集群上使用的相同标签。在我们这里是gke-clustertutorial-cff607d3-node。

  • 目的 IP 范围 : 10.16.0.0/14

  • 协议和端口:检查 tcp，选择端口 6443。

• 现在点击创建按钮。参见图 8-17 、 8-18 和 8-19 。

• **第六步:**用您给的名称验证创建的出站防火墙规则搜索规则，如 sysdig-agent-outbound，如图 8-20 所示。

在 GKE 上安装 Sysdig 代理

图 8-22

克隆 GCP 电码—续

图 8-21

克隆 GCP 密码

• 第一步:连接 GKE，打开云壳。

• **第二步:**在 Prometheus 下执行以下命令，克隆 GCP，其中包含sysdig-agent-clusterrole.yaml、sysdig-agent-configmap.yaml、sysdig-agent-daemonset-v2.yaml文件:。$ git clone https://github.com/dryice-devops/GCP.git

• **输出:**数字 8-21 和 8-22 显示前一条命令的输出。

图 8-23

传递 GCP·EKS 集群的价值

• **第三步:**在 Sysdig 目录下，你会找到sysdig-agent-clusterrole.yaml、sysdig-agent-configmap.yaml、sysdig-agent-daemonset-v2.yaml文件。你可以从下面的 GitHub 链接中获得样例文件: https://github.com/draios/sysdig-cloud-scripts/tree/master/agent_deploy/kubernetes

• 在sysdig-agent-configmap.yaml文件中，你会发现下面这段:k8s_cluster_name。传递 GCP EKS 星团(在我们的例子中是 Prometheus)的值，如图 8-23 所示。

图 8-24

Sysdig 代理命名空间创建

• 接下来，打开sysdig-agent-daemonset-v2.yaml文件。您不必修改该文件中的任何内容。

• 步骤 4: 通过从 GCP 目录执行以下命令，为 Sysdig 代理创建一个名称空间。

• 命令命令: $ kubectl create ns sysdig-agent

• **输出:**图 8-24 显示了前一条命令的输出。

图 8-25

Sysdig 代理秘密创建

• 步骤 5: 通过执行以下命令为 Sysdig 代理创建秘密。这将使用我们为 Sysdig 创建评估帐户时获得的密钥(突出显示)(在欢迎屏幕中选择 Kubernetes 时)。

• 命令 : $ kubectl create secret generic sysdig-agent --from-literal=access-key=9b63d2de-4e52-49a9-b287-ef3c3dd39934 -n sysdig-agent

• **输出:**图 8-25 显示了前一条命令的输出。

图 8-26

Sysdig 代理群集角色部署

• 步骤 6: 执行以下命令，部署 Sysdig 代理集群角色。clusterrole文件与我们在前面步骤中创建的文件相同。

• 命令: $ kubectl apply -f sysdig-agent-clusterrole.yaml -n sysdig-agent

• **输出:**图 8-26 显示前一条命令的输出。

图 8-27

Sysdig 命名空间的 sysdig 代理服务帐户

• 步骤 7: 执行下面的命令，在 Sysdig 代理名称空间中创建一个服务帐户。

• 命令: $ kubectl create serviceaccount sysdig-agent -n sysdig-agent

• **输出:**图 8-27 显示了前一条命令的输出。

图 8-28

Sysdig 代理群集角色绑定创建

• 步骤 8: 执行以下命令，在 Sysdig 名称空间中创建集群角色绑定。

• 命令: $ kubectl create clusterrolebinding sysdig-agent --clusterrole=sysdig-agent --serviceaccount=sysdig-agent:sysdig-agent

• **输出:**图 8-28 显示前一条命令的输出。

图 8-29.1

Sysdig 代理 daemonset 安装

图 8-29

Sysdig 代理配置映射创建

• 步骤 9: 执行以下命令，完成 Sysdig 代理的安装。

• 命令: $ kubectl apply -f sysdig-agent-configmap.yaml -n sysdig-agent

• 命令: $kubectl apply -f sysdig-agent-daemonset-v2.yaml -n sysdig-agent

• **输出:**数字 8-29 和 8-29.1 显示前面命令的输出。

现在，我们将导航到 Sysdig 控制台，查看监控指标。

图 8-30

登入成功

• **第一步:**导航到 https://sysdig.com/ ，点击登录按钮，选择显示器，如图 8-30 所示。使用注册阶段使用的用户名/密码登录。

图 8-31

Sysdig 欢迎页面

• **第二步:**登录后，会看到欢迎使用 Sysdig 页面。您还会看到“您连接了 3 个代理！”通知。单击转到下一步！导航到下一个屏幕，如图 8-31 所示。

图 8-34

系统摘要设置完成—续

图 8-33

系统摘要设置完成

图 8-32

跳过 AWS 帐户

• 步骤 3: 将与 AWS 整合部分留空，点击跳过按钮，如图 8-32 所示，从而完成 Sysdig 设置(图 8-33 和 8-34 )。

现在，让我们在 Sysdig 控制台上浏览各种报告，进行容器监控。单击“下一步”按钮，您将看到一个新窗口，显示以下消息:“您的环境已准备就绪。”点击完成入职按钮，如图 8-35 所示。

图 8-35

Sysdig 主页仪表板屏幕

浏览 GKE 监控报告

要浏览 GKE 监控报表，请执行以下步骤:

图 8-36

sysdig kuble health dashboard(永久健康仪表板)

• 步骤 1: 要在 Sysdig 中查看已部署的 pod，请单击 Explore。现在，从下拉选项中选择主机&容器。在另一个节点，选择 Kubernetes 类别(默认仪表板的子类别)下的 Kubernetes Health Overview，如图 8-36 所示。

图 8-38

Sysdig Kubernetes 健康仪表板—续

图 8-37

sysdig kuble health dashboard(永久健康仪表板)

• 步骤 2: 您将发现关于整个 Kubernetes 环境的丰富指标，包括顶级名称空间(按容器)、CPU/内存/文件系统使用、网络输入/输出，如图 8-37 和 8-38 所示。

图 8-40

Sysdig 容器限值监控—续

图 8-39

Sysdig 容器限值监控

• **第三步:**从页面最右侧的下拉菜单中选择容器限制，查看 CPU/内存份额和配额，如图 8-39 和 8-40 所示。

图 8-42

Sysdig 容器文件系统监控—续

图 8-41

Sysdig 容器文件系统监控

• **第四步:**从页面右侧的下拉菜单中选择文件系统，查看文件系统中的可用字节数/已用字节数/索引节点数等。如图 8-41 和 8-42 所示。

图 8-45

Sysdig 容器网络监控—续

图 8-44

Sysdig 容器网络监控—续

图 8-43

Sysdig 容器网络监控

• **第五步:**在下拉菜单右侧选择网络下的概览选项，查看入站网络字节、出站网络字节、总网络字节等指标，如图 8-43 、 8-44 和 8-45 所示。

现在让我们来看看容器应用指标。

图 8-47

Sysdig 容器化应用视图—续

图 8-46

Sysdig 容器化应用视图

• 步骤 1: 要查看我们的 Sock Shop 应用(在前面的章节中部署)的基于容器的信息，从下拉菜单中选择 contained Apps，然后从 weaveworksdemos 开始选择容器名称。您将能够看到 top Pods 的 CPU 利用率、内存利用率和文件系统，如图 8-46 和 8-47 所示。

图 8-50

Sysdig 部署视图—续

图 8-49

Sysdig 部署视图—续

图 8-48

Sysdig 部署视图

• **第二步:**要查看部署，从下拉菜单中选择部署，选择 sock-shop，如图 8-48 、 8-49 和 8-50 。

• 在 Kubernetes 类别下选择 Kubernetes CPU 分配优化。

现在，让我们研究一下 Sysdig 提供的特定于应用层的其他指标。

图 8-54

Sysdig HTTP 监视器度量—续

图 8-53

Sysdig HTTP 监视器度量

图 8-52

Sysdig HTTP 监视器默认仪表板

图 8-51

Sysdig HTTP 监视器

• 步骤 1: 单击左侧面板中的 Explore，并从下拉菜单中选择 Hosts & Containers 选项。从右侧第二个下拉菜单中选择 HTTP。您将看到一些指标，如 HTTP 请求数、平均/最大请求时间、最慢的 URL 等。如图 8-51 、 8-52 、 8-53 、 8-54 所示。

图 8-56

Sysdig JVM 监视器度量

图 8-55

Sysdig JVM 监视器

• 步骤 2: 选择 JVM，而不是 HTTP，来查看与 JVM 相关的指标。这将显示诸如进程随时间分配的堆内存使用和垃圾收集器收集时间等指标，如图 8-55 和 8-56 所示。

图 8-58

Sysdig MongoDB 监视器指标

图 8-57

Sysdig MongoDB 监视器

• **第三步:**在页面右侧的下拉菜单中选择 MongoDB (Server)而不是 JVM，查看 MongoDB 相关的指标，如创建的连接总数、MongoDB 进程使用的虚拟内存量等。如图 8-57 和 8-58 所示。

Sysdig 拓扑视图提供了一个界面，用于实时可视化应用系统中不同组件之间的交互方式。默认情况下，该界面显示选定主机的顶级进程及其与远程主机或主机组上的进程的交互。交互被描述为节点和链接。链接连接节点。节点和链接从左侧放射状扩展。以下是 Sysdig 控制台上可见的实体:

• 节点:节点是参与网络通信的实体。节点可以是进程、容器、主机或由 Sysdig 代理标识的任何标签，例如 kubernetes.pod.name。

• 链路:节点之间的网络连接称为链路。

  • 主机及其子进程(host.hostName > proc.name)充当拓扑视图的默认分组。扩展拓扑视图受到进程和连接数量的限制。Sysdig Monitor 通过识别来自系统调用数据的网络端点(IP 地址)来创建拓扑视图。

  • Explore 选项卡中的拓扑视图提供了预定义的仪表板，用于表示 CPU 使用情况、网络流量和响应时间指标。

现在让我们来探索 Sysdig 的拓扑视图。

图 8-60

Sysdig 拓扑视图 CPU 使用度量

图 8-59

Sysdig 拓扑视图 CPU 使用选项

• 步骤 1: 单击左侧面板中的 Explore，并从下拉菜单中选择 Hosts & Containers 选项。选择拓扑，然后选择 CPU 使用率。点击每个图标，通过拓扑映射按应用节点和容器深入查看 CPU 使用情况，如图 8-59 和 8-60 所示。

图 8-64

Sysdig 拓扑查看 pod 之间的网络流量

图 8-63

其他 Sysdig 拓扑查看网络流量指标

图 8-62

Sysdig 拓扑查看网络流量指标

图 8-61

Sysdig 拓扑视图网络流量选项

• 步骤 2: 从第二个下拉菜单中选择网络流量选项，而不是 CPU 使用率。您可以深入查看具体的流程。例如，我们选择了基于 Python 的盒子来显示与我们的 Sock Shop 应用相关的 Python 和 Mongo DB Pods 之间的网络流量，如图 8-61 、 8-62 、 8-63 和 8-64 所示。

传统的监控工具通常基于静态配置文件，设计用于监控机器，而不是微服务或容器。在容器世界中，事情的工作方式非常不同，因为容器可以根据应用的伸缩策略和传入流量进行伸缩。此外，容器以令人难以置信的速度被创建和销毁，从监控的角度来看，不可能跟踪这样的动态实体。

大多数现代平台系统都提供了各种各样的指标，每个指标都可以让我们了解平台的行为方式。人脑很难分析如此多的数据，并深入了解应用的运行情况。想象一下，容器平台上的一个应用被频繁使用，并产生大量关于可用性、性能、错误等各方面的指标。只要应用可用，我们就可以感觉到一切都在工作，但是我们可能会忽略某些事件，这些事件在一段时间后可能会导致系统中断或性能瓶颈。

谷歌使用黄金信号(谷歌发明的谷歌 SRE 手册中使用的术语)解决了这个问题。从与应用服务交互的系统来看，黄金信号本质上是四个指标，可以让您很好地了解应用的实际健康状况和性能。黄金信号有助于检测微服务应用的问题。这些信号是一组精简的指标，从用户或消费者的角度提供了一个广泛的服务视图，因此您可以检测可能直接影响应用行为的潜在问题。四个黄金信号是

• 延迟:延迟是您的系统为服务请求提供服务所花费的时间。这是检测性能下降问题的重要标志。

• 错误:您的服务返回的错误率是更深层次问题的一个很好的指示器。不仅要检测显式错误，还要检测隐式错误，这一点非常重要。

• 流量/连接:这是一个单位时间内你的服务使用量的指标。它可以是许多不同的值，取决于系统的性质，例如对 API 的请求数量或流媒体应用消耗的带宽。

• 饱和度:通常饱和度用最大容量的百分比来表示，但是每个系统会有不同的方式来衡量饱和度。百分比可能意味着直接从应用获得的或基于估计的用户或请求的数量。

现在让我们看看如何使用 Sysdig 查看黄金信号指标。

图 8-67

Sysdig 黄金信号指标—续

图 8-66

Sysdig 黄金信号指标

图 8-65

Sysdig 黄金信号选项

• 步骤 1: 单击左侧面板的 Explore，并从下拉菜单中选择 Services 选项。

• **第二步:**从右侧第二个下拉菜单中选择 Kubernetes Service Golden Signals，如图 8-65 、 8-66 和 8-67 。

摘要

在本章中，我们提供了使用 Sysdig 进行容器应用监控的实际操作步骤。下一章将介绍使用 Prometheus 进行容器应用监控的实际操作步骤。

九、将 Prometheus 用于 GKE 监控

本章提供了指导您使用 Prometheus 进行 GKE 监控的实际操作步骤。此外，它还包括以下内容:

表 9-1

节点导出器

|

名称

|

描述

|

OS

| | --- | --- | --- | | 阿尔普 | 暴露来自/proc/net/arp的 ARP 统计 | Linux 操作系统 | | 启动时间 | 暴露从kern.boottime sysctl得出的系统启动时间 | 达尔文，Dragonfly，FreeBSD，NetBSD，OpenBSD，Solaris | | 中央处理器 | 公开 CPU 统计数据 | 达尔文，蜻蜓，FreeBSD，Linux，Solaris | | 硬件服务 | 公开 CPU 频率统计信息 | Linux，Solaris | | diskstats | 公开磁盘 I/O 统计信息 | 达尔文，Linux，OpenBSD | | 文件系统 | 显示文件系统统计信息，如使用的磁盘空间 | 达尔文，蜻蜓，FreeBSD，Linux，OpenBSD | | hwmon！hwmon | 暴露来自/sys/class/hwmon/的硬件监控和传感器数据 | Linux 操作系统 | | 内存信息 | 公开内存统计信息 | 达尔文，蜻蜓，FreeBSD，Linux，OpenBSD | | getclass(获取类) | 从/sys/class/net/暴露网络接口信息 | Linux 操作系统 | | 子系统 | 显示网络接口统计信息，如传输的字节数 | 达尔文，蜻蜓，FreeBSD，Linux，OpenBSD | | 显示网络连接 | 显示来自/proc/net/netstat的网络统计数据。这是和netstat -s一样的信息。 | Linux 操作系统 | | 网络文件系统 | 显示来自/proc/net/rpc/nfs的 NFS 客户端统计数据。这是和nfsstat -c一样的信息。 | Linux 操作系统 | | 服务器 | 展示来自/proc/net/rpc/nfsd的 NFS 内核服务器统计数据。这是和nfsstat -s一样的信息。 | Linux 操作系统 | | 显示操作系统信息 | 公开 uname 系统调用提供的系统信息 | 达尔文，FreeBSD，Linux，OpenBSD |

图 9-8

配置映射 YAML 文件组件和子组件

图 9-7

为 Prometheus 创建集群角色和集群角色绑定

图 9-6.4

群集角色 YAML 文件组件和子组件

图 9-6.3

群集角色 YAML 文件组件

图 9-6.2

群集角色 YAML 文件演练

图 9-6.1

为 Prometheus 监控创建新的命名空间

图 9-6

Prometheus 监控的命名空间创建

图 9-5

验证克隆的文件

图 9-4.4

从 GitHub 克隆 Prometheus 代码

图 9-4.3

导航到prometheus目录

图 9-4.2

创建prometheus目录

图 9-4.1

移动到gcptutorialmail目录

图 9-4

创建gcptutorialmail目录

图 9-3

Prometheus 部署流程

图 9-2

YAML 文件构建块

图 9-1

Prometheus 建筑

• Prometheus 概述

• Prometheus 建筑

• Prometheus on Google Kubernetes Engine

• 在 Kubernetes 集群上设置 Prometheus

• 出口商

介绍

Prometheus 是一项监控服务，为 IT 团队提供在 GCP 和 AWS 公共云上运行的应用和虚拟机的性能数据。它包括专门针对 Kubernetes 操作符的功能和 Kubernetes 的其他特性，比如 CPU 和内存利用率。可以按基础架构、工作负载和容器查看集群信息。

在本章中，你将学习如何安装 Prometheus。我们将使用在第八章中部署在 GKE 集群上的 Sock Shop 应用，并配置 Prometheus 来监控 GKE 集群，并提取与 CPU 利用率等相关的各种矩阵。

Prometheus 概述

基于容器的技术正在影响基础设施管理服务的元素，如备份、修补、安全性、高可用性、灾难恢复等。监控就是这样一个元素，它随着容器技术的发展而突飞猛进。Prometheus 是最常作为开源监控和警报解决方案出现的容器监控工具之一。Prometheus 最初是在 SoundCloud 构思的，慢慢地，它成为了容器监控最受欢迎的工具之一。它主要是用 Go 语言编写的，并且是第一批云计算基础毕业项目之一。

Prometheus 支持基于键-值对的多维数据模型，这有助于收集作为时间序列数据的容器监控。它还提供了一种强大的查询语言，称为 Prometheus 查询语言(PromQL)。PromQL 允许实时选择和汇总时间序列数据。这些数据既可以作为图形、表格数据查看，也可以由外部系统通过 API 调用使用。Prometheus 还支持与第三方系统的各种集成，用于报告、警报、仪表板和导出器，从各种来源获取数据。

Prometheus 建筑

现在让我们看看 Prometheus 架构的核心组件。图 9-1 展示了 Prometheus 的架构及其主要组件。

Prometheus 服务器

这是一个主要的中央组件服务器，它从多个节点收集指标并将它们存储在本地。Prometheus 服务器的工作原理是抓取，即调用它被配置为监控的各种节点的指标端点。它定期收集这些指标，并将它们存储在本地。

Prometheus 服务器抓取并存储指标。这意味着您的应用必须公开一个指标可用的端点，并指示 Prometheus 服务器如何抓取它。

请注意，Prometheus 服务器使用了一个持久层，它是服务器的一部分，在文档中没有明确提到。服务器的每个节点都是自治的，不依赖于分布式存储。Prometheus 进行刮擦的时间是不确定的。因此，如果您的用例需要精确的逐秒抓取，Prometheus 可能不是一个好的选择。此外，Prometheus 毫无保留地专注于 HTTP。如果您在一个不使用 HTTP 的基于 SOAP 或基于 RPC 的整体环境中操作，您可能会遇到集成挑战。Prometheus 主要是一个拉动式系统；但是，它也提供了推送功能，这将在下一节中解释。

Prometheus 推进网关

Prometheus 直接或通过中间推送网关从仪表化的应用中抓取指标。请将此视为一种缓冲形式。它接受并存储推送的指标，并为 Prometheus 公开一个可废弃的 API。Pushgateway 支持短期作业，以防节点不公开 Prometheus 服务器可以从中收集指标的端点。它捕获数据，将数据转换为 Prometheus 数据格式，然后将数据推送到 Prometheus 服务器。

出口商

导出器运行在受监控的主机上，该主机从第三方系统(如 Linux 服务器、MySQL 守护进程等)获取现有指标。)并将它们导出到 Prometheus 中的 metric 并将数据推送到 Prometheus 服务器。

Alertmanager

Prometheus 有一个名为 Alertmanager 的警报模块，用于发送警报并将其路由到正确的接收者集成，如电子邮件、Slack 等。

网络用户界面

web UI 允许用户访问、可视化和绘制存储的数据。Prometheus 提供了自己的 UI，但是您也可以配置其他可视化工具，如 Grafana，使用 PromQL 访问 Prometheus 服务器。

关键容器监控功能

以下是 Prometheus 为容器监控提供的主要功能。

多维数据模型

该模型基于键值对，类似于 Kubernetes 本身用标签组织基础设施元数据的方式。它允许灵活和准确的时间序列数据，为其 PromQL 提供动力。

可访问格式和协议

公开 Prometheus 度量是一项非常简单的任务。指标是人类可读的，采用自我解释的格式，并使用标准的 HTTP 传输发布。您可以通过使用您的 web 浏览器来检查指标是否被正确公开。

服务发现

Prometheus 服务器负责定期抓取目标，因此应用和服务不必担心发出数据(指标是提取的，而不是推送的)。Prometheus 服务器有几种自动发现刮擦目标的方法。一些服务器可以配置为过滤和匹配容器元数据，使它们非常适合短暂的 Kubernetes 工作负载。

模块化和高度可用的组件

指标收集、警报、图形可视化等。由不同的可组合服务执行。所有这些服务都旨在支持冗余和分片。

本地查询语言支持

如概述中所述，Prometheus 提供了一种函数式查询语言 PromQL，允许用户实时选择和汇总时间序列数据。表达式的结果可以在 Prometheus 的表达式浏览器中表示为图形或表格数据，也可以由外部系统通过 HTTP API 使用。

支持仪表板和报告

Prometheus 支持与各种报告解决方案(如 Grafana 和 Splunk)集成，以获得运营使用的 Kubernetes 指标视图。这简化了用于库存管理、性能管理和事件管理的容器生态系统的操作管理任务。

Prometheus on Google Kubernetes Engine

在第八章中，在部署我们的 Sock Shop 应用时，我们使用了一个 YAML 配置文件来提供在目标/工作者节点上部署应用所需的细节。在安装 Prometheus 和 Alertmanager 之前，我们想让您了解一下 YAML 文件结构的基本知识。YAML 是一种人类可读的数据序列化语言。它通常用于配置文件和存储或传输数据的应用中。YAML 是专门为常见情况创建的，例如:

• 配置文件

• 日志文件

• 跨语言数据共享

• 复杂的数据结构

在高层次上，以下是 YAML 文件的构建块，如图 9-2 所示。

• **键值对:**YAML 文件中条目的基本类型是键值对。在键和冒号之后，有一个空格，然后是值。

• **数组/列表:**列表的名字下有许多条目。列表的元素以“-”开头

• **字典/地图:**一种更复杂的 YAML 文件是字典或地图。

现在，Kubernetes 的资源，比如 pod、服务和部署，都是通过使用 YAML 文件来创建的。在接下来的部分中，我们将通过使用一个 YAML 文件来介绍部署资源的创建，并且将为您提供一个在其中使用的关键字段的概述。

现在让我们从设置 Prometheus 和 Alertmanager 开始。在本练习中，我们将使用第八章中设置的相同容器环境。

在 Kubernetes 集群上设置 Prometheus

让我们开始在 Kubernetes 环境中设置 Prometheus。图 9-3 概述了部署 Prometheus 时我们将遵循的任务流程。

Prometheus 部署的步骤顺序如下:

1. 我们将首先在工作项目中连接到 Cloud Shell。

2. 然后我们将从 GitHub 克隆配置文件。

3. 然后，我们将使用在 Google Cloud Shell 中预配置的 kubectl 在 GKE 集群上创建一个名称空间。

4. 我们将在 GKE 群集上创建群集角色和群集角色绑定。

5. 我们将创建配置映射，然后在 GKE 集群上使用此配置映射部署 Prometheus。

6. 然后，我们将为最终用户访问 Prometheus 创建一个服务。

7. 最后，我们将使用命令行和 web 浏览器访问测试 Prometheus 部署的状态。

在 GKE 上安装和设置 Prometheus

从 GitHub 克隆 Prometheus 代码

在从 GitHub 克隆 Prometheus 之前，首先，我们将在/home目录下创建gcptutorialmail文件夹，在gcptutorialmail下，我们将创建prometheus文件夹。这个prometheus文件夹包含了在 GKE 安装 Prometheus 所需的所有配置文件。

• 步骤 1: 执行以下命令，创建gcptutorialmail和prometheus文件夹。

• 命令:

• cd /home

• mkdir gcptutorialmail

• **输出:**图 9-4 显示前一条命令的输出。

• 通过执行以下命令导航到gcptutorialmail文件夹。

• 命令:

• cd /gcptutorialmail

• **输出:**图 9-4.1 显示了前一条命令的输出。

• 现在，通过执行以下命令，在gcptutorialmail下创建prometheus文件夹。

• 命令: mkdir prometheus

• **输出:**图 9-4.2 显示了前一条命令的输出。

• 通过执行以下命令，导航到prometheus文件夹。

• 命令: cd /prometheus

• **输出:**图 9-4.3 显示了前一条命令的输出。

• 第二步:通过执行以下命令，从 GitHub ( https://github.com/dryice-devops/gcp-prometheus.git )克隆代码。

• 命令: git clone https://github.com/dryice-devops/gcp-prometheus.git

• **输出:**图 9-4.4 显示了前一条命令的输出。

• 验证克隆的文件:从 GitHub 克隆文件后，您会看到以下文件:

• clusterRole.yaml

• configMap.yaml

• prometheus-deployment.yaml

• 要验证前面的配置文件是否成功克隆到本地prometheus文件夹，请执行以下命令。

• 命令 : ll

• 输出:图 9-5 显示前一条命令的输出。

创建命名空间

要安装 Prometheus，第一步是在现有集群中创建一个单独的名称空间，用于逻辑隔离。为此，请执行以下步骤:

• 步骤 1: 在创建名称空间之前，确保使用以下命令连接到 GKE 集群名称clustertutorial。

• 命令: gcloud container clusters get-credentials clustertutorial --zone us-central1-a --project tutorial-project-268109

• **输出:**图 9-6 显示前一条命令的输出。

• 步骤 2: 在 tutorial 项目的 Cloud Shell 上执行以下命令，从prometheus目录创建一个名为prometheus的新名称空间。

• 命令: kubectl create namespace prometheus

• **输出:**图 9-6.1 显示了前一条命令的输出。

群集角色 YAML 文件

让我们深入到prometheus文件夹中的集群角色 YAML 文件(clusterRole.yaml)的内容，以理解该部分及其相关性。该文件有两个部分:ClusterRole和ClusterRoleBinding。

集群角色部分

apiVersion(堆叠版本)

文件的初始部分包含定义 Kubernetes API 版本的字段，通过该字段与 Kubernetes API 服务器进行交互。它通常用于创建对象。apiVersion 会有所不同，这取决于您环境中的 Kubernetes 版本。我们使用下面的 API version:ClusterRole的rbac.authorization.k8s.io/v1beta1。

种类

kind字段定义了 Kubernetes 对象的类型，例如集群角色、部署、服务、pod 等。在我们的例子中，我们使用的是ClusterRole。

元数据

此部分在文件中定义了名称子组件。name字段指定对象的名称。在我们的例子中，我们使用prometheus作为name，如图 9-6.2 所示。

规则

规则是可以在属于不同 API 组(也称为遗留组)的一组资源上执行的一组操作(动词)。在我们的例子中，我们正在创建一个规则，允许用户在节点、代理、服务、端点和属于核心(在 YAML 文件中用" "表示)、应用和扩展的 pod 上执行几个操作。API 组规则有几个子组件元素。

• resources:该字段定义了各种 Kubernetes 资源。

• verbs:该字段定义了要对资源执行的操作。

• 这是一组用户应该有权访问的部分 URL。非资源 URL 没有命名空间。此字段仅适用于从群集角色绑定引用的群集角色。规则既可以应用于 API 资源(如"pods"或"secrets")也可以应用于非资源 URL 路径(如"/api")，但不能两者都应用，如图 9-6.3 。

群集角色绑定部分

apiVersion(堆叠版本)

文件的初始部分包含定义 Kubernetes API 版本的字段，通过该字段与 Kubernetes API 服务器进行交互。它通常用于创建对象。API 版本会有所不同，这取决于您环境中的 Kubernetes 版本。对于集群角色绑定，我们使用下面的 API: rbac.authorization.k8s.io/v1beta1。

种类

Kind 字段定义 Kubernetes 对象的类型，例如集群角色、部署、服务、pod 等。在我们的例子中，我们使用 ClusterRoleBinding。

元数据

此部分在文件中定义了名称子组件。名称字段指定对象的名称。在我们的例子中，我们使用prometheus作为name。

• roleRef:在这个字段中，我们将 Prometheus 集群角色绑定到监控名称空间内 Kubernetes 提供的默认服务帐户。这一部分还包含更多的子组件。

  • apiGroup:该字段定义 rbac.authorization.k8s.io API 与 API 组交互

  • kind:该字段定义了对象类型。

  • name:集群角色的名称，如prometheus。

• Subjects:这个部分定义了必须访问 Kubernetes API 的一组用户和进程。这一部分还包含更多的子组件。

  • kind:该字段定义了服务账户的对象类型。

  • 由于每个 Kubernetes 安装都有一个名为 default 的服务帐户，它与每个正在运行的 Pod 相关联，所以我们使用相同的帐户:default。

  • namespace:该字段定义了集群角色绑定的名称空间名称，例如，monitoring(我们在“创建名称空间”一节中创建的)，如图 9-6.4 所示。

现在，我们将为 Prometheus 创建刚刚创建的集群角色和集群角色绑定。

• 步骤 1: 在prometheus文件夹下创建角色，在教程项目的云 Shell 上使用下面的命令。

• 命令:

• kubectl create -f clusterRole.yaml

• **输出:**图 9-7 显示前一条命令的输出。

创建配置图

ConfigMap 将用于从映像内容和警报规则中分离任何配置工件，这些内容和规则将作为prometheus.yaml和prometheus.rules文件安装到/etc/prometheus中的 Prometheus 容器中。

• 步骤 1: 我们将使用prometheus文件夹中的配置映射 YAML 文件来创建ConfigMap。现在让我们回顾一下 YAML 文件的内容。ConfigMap合并了数据段下的prometheus.rules和prometheus.yaml文件。

• apiVersion:文件的初始部分定义了 Kubernetes 的 apiVersion 与 Kubernetes API 服务器交互的字段。它通常用于创建对象。apiVersion 会有所不同，这取决于您环境中的 Kubernetes 版本。

• kind:kind字段定义了 Kubernetes 对象的类型，如集群角色、部署、服务、pod 等。我们使用ConfigMap作为宾语。

• metadata:该部分具有在包含配置图数据的文件中定义的name子组件。

  • name : 该字段具有配置图的名称。在我们的例子中，我们使用的是prometheus-server-conf。

  • labels : 该字段定义了 ConfigMap 的标签，如prometheus-server-conf。

  • namespace : 该字段定义将在其中创建 ConfigMap 的名称空间，例如监控，如图 9-8 所示。

• data:该字段定义了prometheus.rules和prometheus.yml的内容，并在运行时将它们的信息传递给ConfigMap。

• prometheus.rules : 此部分包含用于根据各种条件(例如，内存不足、磁盘空间不足等)生成警报的警报规则。我们选择了高 Pod 内存使用率。

• prometheus.yml : Prometheus 通过一个配置文件进行配置，这个文件就是prometheus.yml。配置文件定义了与抓取作业及其实例相关的所有内容，以及要加载的规则文件。prometheus.yml包含所有有助于动态发现 Kubernetes 集群中运行的 pod 和服务的配置。以下是我们的 Prometheus 刮擦配置中的刮擦作业:

  • kubernetes-apiservers:从 API 服务器获取所有的指标。

  • kubernetes-nodes:此作业将收集所有 Kubernetes 节点指标。

  • kubernetes-pods:如果 Pod 元数据用prometheus.io/scrape和prometheus.io/port注释进行了注释，将会发现所有的 Pod 指标。

  • kubernetes-cadvisor:收集所有 cAdvisor 指标。

  • kubernetes-service-endpoints : 如果服务元数据被标注了prometheus.io/scrape和prometheus.io/port标注，那么所有的服务端点都将被废弃。它将使用黑盒监控。

• prometheus.rules:包含向预警管理器发送预警的所有预警规则。

  • global : 全局配置指定在所有其它配置环境中有效的参数。global具有各种子组件，如下所示:

    • scrape_interval:默认多长时间刮一次目标。我们选择 20 秒作为例子。

    • evaluation_interval:刮取请求超时之前的时间长度。我们选择 20 秒作为例子。

  • rule_files: This specifies a list of globs. Rules and alerts are read from all matching files that we defend under prometheus.rules and the path defined as /etc/prometheus/prometheus.rules, as shown in Figure 9-9.

    

    图 9-9

    配置映射 YAML 文件字段和子字段

• 步骤 2: 执行以下命令，从prometheus文件夹创建配置图。

• 命令: kubectl create -f config-map.yaml –n prometheus

• Output: Figure 9-10 shows the output of the preceding command.

  

  图 9-10

  为 Prometheus 创建配置图

Prometheus 部署

在为 Prometheus 部署设置了角色、配置和环境之后，执行以下步骤在 GKE 上创建的 Kubernetes 集群上安装 Prometheus。

为了在 Kubernetes 集群上部署 Prometheus，我们将使用prometheus文件夹中的prometheus-deployment.yaml文件。

我们将使用来自 Docker hub 的官方 Prometheus Docker 映像 v2.12.0。在这种配置中，Prometheus ConfigMap 挂载作为一个文件放在/etc/Prometheus中。

以下是 Prometheus 部署文件的详细信息:

• apiVersion : 该文件的开始部分定义了 Kubernetes 的 apiVersion 与 Kubernetes API 服务器交互的字段。它通常用于创建对象。apiVersion 根据您环境中的 Kubernetes 版本而有所不同。

• kind:kind字段定义了 Kubernetes 对象的类型，例如集群角色、部署、服务、pod 等。我们将该对象用作部署。

• metadata : 本节有文件中定义的名称子组件。

  • 该字段指定服务对象的名称，例如 prometheus-deployment。

  • namespace: This field specifies the namespace of the service object, e.g., monitoring, as shown in Figure 9-11.

    

    图 9-11

    Prometheus 部署 YAML 文件演练

• spec : 该字段指定服务。

  • replicas:该字段提供特定情况下可用的 pod 数量的数据。

  • selector:本节提供服务选择器的详细信息。

    • matchLabels : This is the name that will be used to match and identify the service, as shown in Figure 9-12.

      

      图 9-12

      Prometheus 部署 YAML 文件演练

• template:服务使用的端口类型

  • metadata : name将用于匹配和识别服务。
    • labels:一个键值对，附加在对象上，用于指定识别属性

      • app =键

      • prometheus-server =值

前述内容如图 9-13 所示。

图 9-38

黑盒度规

图 9-37

出口商名单

图 9-36

端口更新

图 9-35

获取黑盒导出器服务详细信息

图 9-34

安装黑盒导出器—续

图 9-33

安装黑盒导出器

图 9-32

节点度量

图 9-31

出口商名单

图 9-30

Prometheus 屏幕

图 9-29

端口转发

图 9-28

得到 Prometheus 号的名字

图 9-27

服务列表

图 9-26

节点导出器设置

图 9-25

服务列表

图 9-24

节点导出器安装—续

图 9-23

节点导出器安装

图 9-22

Prometheus 屏幕

图 9-21

Prometheus 屏幕

图 9-20

转发到端口 8080

图 9-19

端口转发运行 Prometheus

图 9-18

Prometheus 部署—续

图 9-17

Prometheus 部署

图 9-16

Prometheus 部署 YAML 文件演练—续

图 9-15

Prometheus 部署 YAML 文件演练—续

图 9-14

Prometheus 部署 YAML 文件演练—续

图 9-13

Prometheus 部署 YAML 文件演练—续

• Spec:

  • containers:容器对象的详细信息

    • name : 容器的名称

    • image : 映像配版本

    • args : 创建容器时使用的参数

      • "--config.file=/etc/prometheus/prometheus.yml"部署时要使用的文件名

      • 这决定了 Prometheus 在哪里写它的数据库

    • ports:??

      • containerport–应用监听端口如图 9-14 所示。

• 卷装载:存储卷允许将现有的存储卷装载到您的 Pod 中。创建了两个volumeMounts:prometheus-config-volume和prometheus-storage-volume。prometheus-config-volume将使用我们的配置图来管理prometheus.yml。通过prometheus-storage-volume，我们创建了一个emptyDir来存储 Prometheus 数据。

  • **名称:**这是卷的名称。

  • mouthPath: 定义贴装路径，如图 9-15 所示。

• 卷(volume):这是一个包含数据的目录，运行在一个 Pod 中的所有容器都可以访问该目录中的数据，这些数据被装载到每个容器的文件系统中。它的寿命与 Pod 的寿命相同。将卷生命周期与容器生命周期分离，允许卷在容器崩溃和重新启动后继续存在。此外，卷可以由主机的文件系统或永久块存储卷支持，如 AWS EBS 或分布式文件系统。

  • name : 卷名

  • configMap : 使用 ConfigMap 的卷

    • defaultMode

    • name必须使用的配置图的定义名称。

    • name:

    • emptyDir : 当一个 Pod 被分配到一个节点时，第一次创建emptyDir卷，并且只要该 Pod 在我们用来存储 Prometheus 数据的那个节点上运行，该卷就存在，如图 9-16 所示。

按照下面的步骤，在 Kubernetes 集群上安装 Prometheus。

• **第一步:**从prometheus目录执行以下命令。

• 命令: kubectl apply -f prometheus-deployment.yaml -n prometheus

• **输出:**图 9-17 显示了前一条命令的输出。

要验证部署，请使用以下命令列出 Pod。

• 命令: kubectl get pods -n prometheus

• **输出:**图 9-18 显示前一条命令的输出。

• 步骤 2: 要使服务能够访问 Prometheus UI，请使用带有我们之前收到的 Prometheus Pod 名称的端口转发命令。

• 命令: kubectl port-forward prometheus-deployment-78fb5694b4-m46rq 8080:9090 -n prometheus

• **输出:**图 9-19 是端口转发的输出。它将设置 Grafana 在端口 9090 上运行。

• 第三步。要测试 Prometheus 部署的状态，请在将端口更改为 8080 后，转到 Cloud Shell 中的 web 预览来访问 UI。进入网页预览➤换港➤ 8080，如图 9-20 和 9-21 所示。

出口商

导出器帮助从应用/Kubernetes 服务获取状态/日志/指标，并向 Prometheus 提供数据。它们类似于市场上其他监控工具中的适配器或插件。Prometheus 提供了一份官方和外部捐助的出口商名单。让我们通过访问下面的: https://prometheus.io/docs/instrumenting/exporters/ 来探索一些对容器基础设施监控有用的方法。

节点导出器

节点导出器是一个 Prometheus 导出器，用于获取 Unix/Linux 内核公开的硬件和操作系统指标。它是用 Go 语言编写的，带有可插拔的度量收集器。收集器根据操作系统类型的使用情况而有所不同。表 9-1 提供了几个例子。

使用 Helm 图在 Prometheus 安装节点导出器

要安装节点导出器，需要 Helm 和 Helm 杆。头盔和 Helm 杆预配置了第七章的“部署 Grafana”一节中解释的云壳。

• 步骤 1: 执行以下命令来更新 Tiller 并分配一个服务帐户角色。

• 命令: helm init --service-account tiller --history-max 200 –upgrade

• 现在运行下面的命令，验证 Helm 和 Helm 杆是否运行顺畅。现在，您应该可以看到客户机和服务器的版本信息。

• 命令: helm version

• **输出:**图 9-22 显示前一条命令的输出。

• **第二步:**执行以下命令。它将从下面的 GitHub URL 下载导出器，并在 GKE 集群上安装节点导出器。

• https://github.com/helm/charts/tree/master/stable/prometheus-node-exporter

• 命令: helm install --name node-exporter stable/prometheus-node-exporter

• **输出:**数字 9-23 和 9-24 显示前一条命令的输出。

• 步骤 3: 现在让我们使用下面的命令来验证节点导出器服务是否正在运行。

• 命令: kubectl get svc

• **输出:**图 9-25 显示前一条命令的输出。

node-exporter-prometheus-node-exporter服务应该是可见的并且处于运行状态，如图 9-25 中突出显示的。还要注意服务的集群 IP，因为它将在下一步中使用。

• 步骤 6: 在 Prometheus UI 中，登录并导航到状态，然后导航到 Prometheus 上的目标，验证节点导出程序。然后执行下面的命令。

• $ kubectl port-forward prometheus-deployment-78fb5694b4-7z6dd 8080:9090 -n prometheus

• 用黄色突出显示的代码是 Prometheus 的 Pod 名称，您可以通过执行以下命令获得它。

• 命令: kubectl get pod -n prometheus

• **输出:**前一条命令的输出如图 9-28 所示。

• 端口转发的输出如图 9-29 所示。

• 在浏览器中打开 Prometheus，在状态下拉菜单下进入目标，如图 9-30 所示。

• 搜索node-exporter并确认其状态为 UP，如图 9-31 所示。

• 步骤 7: 现在让我们执行一个查询，开始收集和显示节点指标。单击图表选项卡。在表达式部分(文本框)下，键入“node_load15”并点击执行按钮，如图 9-32 所示。

• kubectl delete configmaps prometheus-server-conf -n=prometheus

• kubectl create -f config-map.yaml

• kubectl delete deployment prometheus-deployment -n prometheus

• kubectl apply -f prometheus-deployment.yaml -n prometheus

• 步骤 4 :下一步是配置上一步安装的节点导出器。

• 导航到prometheus文件夹并打开config-map.yaml文件。在scarpe_config剖面下，找到job name和static_configs的job_name: node_exporter剖面和细节，如图 9-26 所示。

• job_name:该字段表示节点导出器的作业名称。我们使用值node-exporter作为job_name。

• static_configs : 这个部分有一个名为targets的小节。“目标”是指作业目标 10.81.13.221(群集 IP)和 9100，即运行节点导出的服务端口。您可以使用以下命令来验证您的集群 IP 和端口信息。

• 命令: kubectl get svc

• **输出:**图 9-27 显示了前一条命令的输出。

• 步骤 5: 执行以下命令，以反映在之前步骤中对 Prometheus ConfigMap 所做的更改。

• 命令:

节点导出器主要用于监控容器基础设施的基础元素，而不是流程/服务。

黑盒导出器

黑盒导出器用于监控利用 HTTP、HTTPS(通过 HTTP 探测器)、DNS、TCP 和 ICMP 的网络端点。它用于黑盒监控场景，在这种场景中，从外部源执行对目标的监控，并且监控解决方案的主人不了解目标系统的内部结构细节。以下是配置黑盒导出器的步骤。

• 步骤 5: 从prometheus文件夹中执行以下命令，以验证 Prometheus 配置图和部署是否顺利运行。

• 命令: kubectl get all -n= prometheus

• **第六步:**通过 https://8080-dot-10790352-dot-devshell.appspot.com/targets 登录 Prometheus GUI 查看blackbox_http终点，如图 9-37 所示。

• **第 7 步:**单击 Prometheus GUI 中的 Graph 并执行以下查询，通过连接 Sock Shop 应用 URL 的阶段 http://34.70.226.32:80 和作业"blackbox"(图 9-38 中显示的 Sock Shop 应用 URL 在您的情况下可能会有所不同)来获得 HTTP 请求的持续时间。

• 查询:

• probe_http_duration_seconds{instance="http://34.70.226.32/",job="blackbox",phase="connect"}

• $kubectl delete configmaps prometheus-server-conf -n=prometheus

• $kubectl create -f configMap.yaml

• $kubectl delete deployment prometheus-deployment -n prometheus

• $kubectl apply -f prometheus-deployment.yaml -n prometheus

• 步骤 1: 导航到prometheus文件夹，执行下面的 Helm 命令，安装黑盒导出器。黑盒导出器内容将从以下 GitHub 网址下载: https://github.com/helm/charts/tree/master/stable/prometheus-blackbox-exporter 。

• 命令: helm install --name blackbox-exporter stable/prometheus-blackbox-exporter

• **输出:**数字 9-33 和 9-34 显示前一条命令的输出。

• 步骤 2: 从prometheus文件夹中执行以下命令，获取在 Prometheus ConfigMap 文件中配置黑盒导出器所需的黑盒服务细节，例如 clusterip (10.81.9.39)和 port (9115/TCP)。

• 命令: kubectl get svc

• **输出:**图 9-35 显示前一条命令的输出。

• 步骤 3: 现在让我们在 Prometheus 中通过 Blackbox exporter 配置 HTTP 探针。导航到prometheus文件夹并打开configMap.yaml。找到名为“job_name: 'blackbox'的部分，并修改以下条目:

  • job_name : 该字段表示作业的名称，在我们的例子中是blackbox。

  • metrics_path : 该字段表示用于从目标应用获取度量的 HTTP 资源路径。

  • params : 该部分下有一个名为modules的子部分。我们使用该模块进行 HTTP 200 响应监控。

  • static_configs : 这个部分有一个名为targets的小节。在targets下面提到的网址是指你要监控的应用的网址。您可以用我们在第八章中部署的 sock Shop 应用 URL 来替换它。

    • relabel_configs : 在本节中，用我们之前取的黑盒服务 IP:port 值修改replacement下的 URL 条目，例如 10.81.9.39:9115，如图 9-36 所示。

• 步骤 4: 执行以下命令，应用来自prometheus文件夹的 Prometheus 配置图和部署中的更改。

摘要

在本章中，你学会了使用 Prometheus 来监视 GKE。在下一章中，通过动手练习，您将看到如何使用基于 CI/CD 的自动化流水线来启用容器监控。

十、GKE 集群、应用和监控部署的自动化

本章提供了使用基础设施即代码(IaC)和 CI/CD 流水线来自动部署容器生态系统基础设施、应用和监控的实际操作步骤，包括以下内容:

• 清理 GKE 环境命名空间

• 安装 Jenkins

• 为 Jenkins Slave 创建服务

• GKE 供应、应用部署和 Sysdig 代理，使用 Jenkins 流水线

• 从 Jenkins 流水线中删除 GKE 集群。

介绍

随着新平台和不断变化的技术的兴起，建立基础架构并在其上部署应用变得越来越复杂和耗时。此外，使用手动方法设置应用和基础架构增加了人为错误和安全风险的可能性。此外，一旦完成了基础设施的供应和应用部署，还必须管理其他方面，如可维护性、可伸缩性、容错性能等。

IaC 或基础设施即代码的兴起使得应用服务的重建从源代码存储库、应用数据备份和混合云 IaaS 或 PaaS 资源开始。我们利用基础架构和应用组件的规范定义，以可预测的方式调配和管理我们的基础架构。这意味着一个应用，不管它的环境或者托管在哪里，都可以完全从零开始，用一个预定义的需求列表来构建。同样的代码可以在生产、试运行和本地开发环境中运行。

另一个主要好处是构建的一致性。如果您必须管理多个环境，如开发、QA、试运行、生产等。，从相同的代码基础上构建它们，确保它们都以完全相同的方式运行，并遵守相同的策略/标准集。

以下是 IaC 工具如何操作的高级视图(图 10-1 ):

图 10-1

IaC 如何工作

1. 您在文件中描述了所需的基础架构资源(例如，具有三个公共子网的虚拟网络，其中一个子网上的计算实例连接了一个数据块卷)。我们不需要描述如何创建资源，因为 IaC 解决方案管理着这种复杂性，并为开发人员或基础设施运营团队提供了一个抽象视图来关注服务定义部分。

2. IaC 工具通常会扫描描述服务定义代码，并在创建新资源之前验证资源是否已经存在。

3. 如果资源不存在，则创建它们。

4. 如果资源已经具有相同的属性，则不采取任何操作(因为您所期望的已经存在)。

5. 如果找到有差异的匹配资源，IaC 工具会认为您希望对它们进行更改，并使更改发生。

6. 在任何情况下，该工具都不会抛出错误/失败/创建意外的重复资源，因为这些操作是等幂的。

随着 DevOps 的不断发展，开发人员找到了加强 IaC 和容器集成的方法，因为它们是相辅相成的。容器将 IaC 作为核心组件合并到开发周期中。

我们可能需要配置一个容器协调器，比如 Kubernetes，以保持一定数量的映像副本运行，我们可能需要其他基础设施和资源，比如负载均衡器、DNS 条目、TLS 证书、仪表板、警报和日志记录。云中的容器化应用可能看起来像下图(图 10-2 )，其中容器映像只是整个应用的一部分。

图 10-2

容器映像之外的容器化应用组件

完整的应用通常是容器映像和包含所有这些配置的 IaC 模板的组合。该映像捆绑了应用的所有依赖项，比如系统库，所以理想情况下，它应该在开发和生产环境中完全相同地运行。但是，如果环境是手动部署的，那么由于配置的差异，同一映像可能无法跨多个环境工作。现在，为了让应用表现相同，在这些环境中使用完全相同的基础架构配置也很重要。

通过在 CI/CD 流水线中使用 IaC 解决方案，我们现在可以轻松管理基础架构和应用组件的配置和修改，而无需担心配置不匹配、安全风险、人为错误等问题。图 10-3 显示了我们发布流程的一个简化示例。

图 10-4

编排应用和 sydig 代理安装

图 10-3

CI/CD 流水线利用 IaC 自动监控容器

IaC 模板包含与容器相关的配置和底层基础设施(例如，负载均衡器)。在流水线的“构建”阶段，构建并推送容器映像，并将新容器映像的唯一 ID 作为代码模板插入到基础结构中。流水线的每个阶段，如“开发”和“生产”，然后部署相同的基础设施作为代码模板。这可确保每个环境都以可预测、标准化和加速的方式部署，并根据要求提供所有必需的控制和最佳实践。同样的概念现在可以扩展到还包括启用操作控制，如监控、安全、备份等。确保在任何环境中部署应用服务时，其所有必要的操作组件集成都可用。

在接下来的部分中，我们将带您进行一次实践练习，以使用gcloud命令行界面工具和 Jenkins。在本章的后面，我们还将介绍使用 Jenkins 的应用部署场景。

清理 GKE 环境命名空间

在我们开始之前，让我们清理一下在第九章中创造的 GKE 环境。清理之后，我们将在 Jenkins 中设置自动化流程，以创建集群、防火墙、应用部署、Sysdig 代理安装和集群删除。首先，我们将删除 GCP 现有的 GKE 集群名称clustertutorial,我们在前面章节中提到的 Sock Shop 应用，以及 Sysdig 代理，它是在前面章节中手动配置的。

登录到 GCP 控制台，导航到 Kubernetes 引擎，然后单击集群。接下来，选中集群名称的复选框:start with clustertutorial，然后点击页面顶部最右侧的 Delete 按钮，删除集群，如图 10-5 所示。

图 10-5

GKE 集群集群教程删除

环境设置

在本节中，我们将使用gcloud来创建/删除 GKE 集群和防火墙规则。Sysdig 将用于监控容器生态系统。为了协调所有这些步骤，我们将使用 Jenkins。

在安装 Jenkins(版本 2.2.4.5)之前，我们将首先在 GCP 创建一个 VM，然后在 VM 上安装 Java、kubectl 和 Docker。

图 10-6

GCP 计算引擎

• **第一步:**登录 GCP 控制台，导航到计算引擎，选择虚拟机实例，如图 10-6 所示。

图 10-7

用于创建虚拟机的 GCP 虚拟机实例

• 步骤 2: 一旦虚拟机实例页面打开，点击创建实例按钮，创建一个新的虚拟机(图 10-7 )。

图 10-8

GCP 虚拟机实例创建

• 步骤 3: 选择任何合适的名称(例如，我们将我们的虚拟机命名为 devopsbox)，并选择区域 us-central1(爱荷华州)和区域 us-central 1-a(图 10-8 )。

图 10-8.2

在 GCP 创建虚拟机—续

图 10-8.1

在 GCP 创建虚拟机

• 步骤 4: 创建一个机器类型为 n1-standard-2 的虚拟机(图 10-8.1 和 10-8.2 )。

图 10-8.3

在 GCP 创建虚拟机—续

• 步骤 5: 为服务帐户选择应用引擎默认值，并选中防火墙部分中的允许 HTTP 流量。单击“create”按钮，以调配虚拟机。这将确保我们可以从外部网络访问我们的 Jenkins 实例，如图 10-8.3 所示。

图 10-8.4

在 GCP 创建虚拟机—续

• **第 6 步:**一旦创建了一个新的虚拟机，你会在虚拟机实例页面看到同样的内容，如图 10-8.4 所示。

图 10-8.5

连接虚拟机

• **第七步:**要连接新创建的虚拟机，点击开始，然后在浏览器窗口中选择打开，如图 10-8.5 所示。

设置停靠站

现在，我们将在 GCP 虚拟机上使用 19.03.8 版本的 Docker CE 来建立基于 Docker 的容器生态系统。

图 10-9.1

Docker 安装—续

图 10-9

Docker 设备

• 步骤 1 :通过执行以下命令来更新包。结果将如图 10-9 和 10-9.1 所示。

$ sudo apt update

图 10-9.3

Docker 安装—续

图 10-9.2

Docker 设备

• 步骤 2 :通过执行以下命令，安装其他必备包。结果将如图 10-9.2 和 10-9.3 所示。

$ sudo apt install apt-transport-https ca-certificates curl gnupg2 software-properties-common

图 10-9.4

坞站安装-contined

• 步骤 3 :通过执行以下命令，为 Docker 存储库添加一个 GPG 键。输出如图 10-9.4 所示。

$ curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add –

图 10-9.5

Docker 设备

• 步骤 4 :通过执行以下命令，将 Docker 存储库添加到 APT 源代码中。该命令的输出如图 10-9.5 所示。

$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"

图 10-9.6

Docker 安装—续

• 步骤 5 :通过执行以下命令，用新添加的 repo 中的 Docker 包更新包数据库。结果如图 10-9.6 所示。

$ sudo apt update

图 10-9.8

Docker 安装—续

图 10-9.7

Docker 安装—续

• 步骤 6 :执行以下命令，确保从 Docker repo 安装，而不是默认的 Debian repo。命令的结果如图 10-9.7 和 10-9.8 所示。

$ apt-cache policy docker-ce

图 10-9.10

Docker 社区版安装—续

图 10-9.9

Docker 社区版安装

• 步骤 7 :运行以下命令安装 Docker 社区版 19.03.8。结果如图 10-9.9 和 10-9.10 所示。

$ sudo apt install docker-ce

图 10-9.11

检查 Docker 安装的状态

• 步骤 8 :通过执行以下命令检查 Docker 服务的状态。该命令的结果如图 10-9.11 所示。

$ sudo systemctl status docker

图 10-9.12

Docker 安装— username增加

• 第 9 步:为了避免每次运行 Docker 命令时都键入sudo，通过执行以下命令将username添加到 Docker 组。结果如图 10-9.12 所示。

$ sudo usermod -aG docker ${USER}

图 10-9.13

验证 Docker 版本

• 第 10 步:验证更改，退出虚拟机，重新连接。

• 步骤 11 :通过执行以下命令验证 Docker 版本。结果如图 10-9.13 所示。

$ docker version

设置 kubectl

为了在 GKE 上连接和部署应用和 Sysdig 代理，必须在 VM 上安装 kubectl。

• 步骤 1 :执行以下命令安装 kubectl。

图 10-10

安装 kubectl

• 前面代码的输出如图 10-10 所示。

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl

图 10-10.1

使 kubectl 可执行

• 步骤 2 :用下面的命令使 kubectl 可执行。结果如图 10-10.1 所示。

$ chmod +x ./kubectl

• 步骤 3 :用下面的命令将 kubectl 移动到 usr/local/bin。

图 10-10.2

kubectl 安装验证

• 步骤 4 :通过执行以下命令来验证 kubectl 安装。结果如图 10-10.2 所示。

$ sudo mv ./kubectl /usr/local/bin/kubectl

$ kubectl version –client

安装 Java 开发工具包(JDK)

为了配置 Jenkins 从属服务器，需要在虚拟机上安装 JDK。执行以下步骤来安装 Java 版本 1.8.0_242。

图 10-11

JDK 装置

• 步骤 1 :通过执行以下命令来更新包。结果如图 10-11 所示。

$ sudo apt-get update

图 10-11.1

JDK 装置

• 第二步:执行以下命令，安装 JDK。结果如图 10-11.1 所示。

$ sudo apt-get install default-jdk

图 10-11.2

JDK 安装—续

• 第三步:按 Y 键继续 Java 设置，如图 10-11.2 所示。

图 10-11.3

JDK 安装验证

• 步骤 4 :通过执行以下命令来验证 Java 安装。结果如图 10-11.3 所示。

$ java -version

安装 Jenkins

为了协调 GKE 配置和应用部署，我们将使用 Jenkins 版本 2.204.1。执行以下步骤来安装和配置 Jenkins。

图 10-12

Jenkins 主目录安装

• 第一步:执行下面的命令创建Jenkins_home directory。这是 Jenkins 保存其所有配置和作业的地方，在用户的主目录下(例如，/home/gcptutorial)。命令的结果如图 10-12 所示。

$ mkdir Jenkins_home

图 10-12.2

Jenkins 安装—续

图 10-12.1

Jenkins 装置

• 步骤 2 :执行以下命令安装 Jenkins。结果如图 10-12.1 和 10-12.2 所示。

$ docker run -d --name jenkins -p 8080:8080 -p 50000:50000 -v /home/gcptutorialmail/jenkins_home:/var/jenkins_home jenkins/jenkins:lts

图 10-12.3

获取 Jenkins 初始管理员密码

• 步骤 3 :执行以下命令获取 Jenkins secrets 密码。结果如图 10-12.3 所示。

$ sudo cat jenkins-data/secrets/initialAdminPassword

我们必须设置防火墙规则，以允许端口 8080 和 50000 上的访问，从而连接 Jenkins 主服务器和它的从服务器。

图 10-13

防火墙规则页面

• 步骤 1 :为 Jenkins 创建一个防火墙规则，允许虚拟机获得端口 8080 和 50000 的入站连接。进入 VPC 网络，点击防火墙规则，如图 10-13 所示。

图 10-13.1

为 Jenkins 创建防火墙规则

• 第二步:在防火墙页面点击创建防火墙规则，如图 10-13.1 所示。

图 10-14.2

为 Jenkins 创建防火墙规则—续

图 10-14.1

为 Jenkins 创建防火墙规则—续

图 10-14

为 Jenkins 创建防火墙规则—续

• 第三步:填写防火墙选项，如下:

• Name :如前所述，选择一个有意义的名字，比如 firewall-rule-devopsbox。

• 日志选项:选择关闭。

• 网络:选择默认。

• 优先级 : 1000

• 交通方向:入口

• 匹配动作:允许

• 目标:选择指定的目标标签，并将 devopsbox 作为该防火墙规则将应用的目标标签的名称。

• 源 IP 范围:前述的 0.0.0.0/0

• 协议和端口:选择指定的协议。

• 端口:选择 tcp 作为协议，上述端口 8080 和 50000。

• 点击创建按钮，如图 10-14 、 10-14.1 和 10-14.2 所示。

图 10-15

获取 Jenkins 外部 IP

• 第 4 步:要访问 Jenkins，导航至计算引擎并选择虚拟机实例。获取外部 IP，例如 34.71.75.255，并复制它。现在导航到网页浏览器中的新标签页，粘贴端口为 8080 的外部 URL(如http://34.71.75.255:8080)以打开 Jenkins 网页，如图 10-15 所示。

图 10-16

第一次访问 Jenkins 控制台

• 第五步:使用从“安装 Jenkins”部分的第三步“解锁 Jenkins”页面获取的 secrets 密码，点击继续按钮，如图 10-16 所示。

图 10-17

选择附加的 Jenkins 功能

• 第六步:点击安装建议插件选项，安装创建流水线所需的各种插件，如图 10-17 所示。

图 10-18

选择建议的 Jenkins 插件选项

• 第七步:点击继续进行，如图 10-18 。

图 10-19

Jenkins 第一个管理员用户设置

• 第八步:在弹出的表单上填写用户名、密码、全名、邮箱等详细信息，点击保存并继续，如图 10-19 所示。

图 10-20

Jenkins 实例配置页

• 第九步:点击保存完成继续，如图 10-20 。

图 10-21

Jenkins 准备好了。

• 步骤 10 :点击开始使用 Jenkins 按钮完成安装，如图 10-21 所示。

图 10-22

第一次 Jenkins 控制台

• 您将看到 Jenkins 控制台的以下屏幕(图 10-22 )。

Jenkins 从机设置

执行以下步骤来设置 Jenkins 从属可执行文件。

• 步骤 1 :通过 root 用户执行以下命令，导航到/home directory of user and create sub directory jenkins_slave，授予 700 权限。Jenkins_node directory将被 Jenkins 节点用来连接和执行命令。

图 10-22.2

设置 Jenkins 节点—续

图 10-22.1

设置 Jenkins 节点

• 步骤 2 :导航到前面步骤中用于访问 Jenkins 的 Jenkins URL。使用您在前面步骤中设置的管理员密码。导航到管理 Jenkins➤管理节点➤新节点，如图 10-22.1 和 10-22.2 所示。

$ cd ~

$ mkdir jenkins_slave

$ chmod 700 jenkins_slave

图 10-23

设置 Jenkins 节点

• 步骤 3 :使用以下值填写表格:

• 名称:使用您选择的任何名称。在我们的例子中，我们选择了前面提到的 devopsbox。

• 描述:使用任何有意义的描述，例如 devopsbox。

• :如前所述，我们输入了 1，来表示与这个 Jenkins 奴隶相关的执行者的数量。

*** 远程根目录:Jenkins slave 存储其工作空间和配置的文件夹路径。为此，我们创造了/var/Jenkins_home。

*   **标签**:使用前面提到的 devopsbox 标签。

*   **用途**:选择尽可能使用该节点。

*   **启动方式**:连接主机选择启动代理。

*   图 10-23 显示了用前面的值完成的表格。** 

**

图 10-24

验证 Jenkins 节点

• 第四步:点击保存按钮，保存配置。

• 步骤 5 :通过查看 Jenkins 控制台状态，验证代理配置成功。

• 代理已配置，但尚未与 Jenkins master 连接，如图 10-24 所示。

图 10-25

复制 Jenkins 节点的agent.jar链接 URL

• 第六步:连接 Jenkins master，点击 devopsbox 一次，打开代理页面，右键点击 agent.jar，复制链接地址，如图 10-25 所示。

图 10-27

虚拟机上 Jenkins agent.jar文件的下载完成

图 10-26

在虚拟机上下载 Jenkins agent.jar文件

• 第 7 步:现在登录虚拟机并导航到jenkins_slave目录，执行以下命令下载 Jenkins 从 jar。命令的结果如图 10-26 和 10-27 所示。

$ cd Jenkins_slave

$ wget http://35.192.203.53:8080/jnlpJars/agent.jar

图 10-28

验证虚拟机上的 Jenkins agent.jar文件

• 步骤 8 :通过执行以下命令，验证agent.jar是否下载。结果如图 10-28 所示。

$ ls -ltr

图 10-29

更改虚拟机上 Jenkins agent.jar文件的权限

• 步骤 9 :通过执行以下命令，将权限改为 700，并验证agent.jar的权限。结果如图 10-29 所示。

$ chmod 700 agent.jar

$ ls -ltr

为 Jenkins Slave 创建服务

现在，我们将创建基于 Linux 的服务，从 Jenkins 主机连接 Jenkins 从机。

图 10-31

在虚拟机上创建 Jenkins 从属服务—续

图 10-30

在虚拟机上创建 Jenkins 从属服务

• 第一步:导航到/etc/systemd/system目录，创建一个jenkinsslave.service文件。复制以下内容并保存文件，如图 10-30 和 10-31 所示。

[Unit]
Description=jenkinsslave
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
ExecStart=/usr/bin/java -jar /home/gcptutorialmail/jenkins_slave/agent.jar -jnlpUrl http://35.225.33.158:8080/computer/devopsbox/slave-agent.jnlp \
-secret 24b23df5ca08cc4ece2f3a511e41ffc1c96729fc81ea8cdfb1786d6e11c47958 -workDir "/var/jenkins_home"
Restart=always
RestartSec=1
[Install]
WantedBy=multi-user.target

图 10-32

在虚拟机上创建 Jenkins 从属服务—续

• 步骤 2 :要启动服务，通过执行以下命令切换到 root 用户。前面命令的结果如图 10-32 所示。

$ sudo su –

图 10-33

在虚拟机上启动/验证 Jenkins 从属服务的状态

• 步骤 3 :执行以下命令，启动并验证服务。结果如图 10-33 所示。

$ systemctl start jenkinsslave
$ systemctl status jenkinsslave

图 10-34

从根用户虚拟机注销

• 步骤 4 :执行以下命令，退出 root 用户会话。结果如图 10-34 所示。

$ exit

图 10-35

在 Jenkins 节点页面上验证 Jenkins 代理是否已连接

• 步骤 5 :为了验证代理是否已连接并正在运行，导航到 Jenkins➤节点，然后单击 devopsbox。

• 你会看到代理已经连接，如图 10-35 所示。

GKE 供应、应用部署和 Sysdig 代理，使用 Jenkins 流水线

现在，我们将创建 Jenkins 流水线CICD-GKEProv-Sysdig来自动化以下流程。

图 10-36

创建 Jenkins 流水线

• 代码克隆:从以下 GitHub 库克隆 Sock Shop 和 Sysdig 代理部署代码: https://github.com/dryice-devops/GCP.git 。

• 创建集群:用gcloud在 GKE 创建一个 Kubernetes 集群clustertutorial。

• 创建防火墙规则:为 Sysdig 代理的端口 6443 创建一个入口/出口防火墙规则。

• 部署应用:通过 kubectl 在 EKS 上部署 Sock Shop 应用。

• 部署 Sysdig 代理:通过 kubectl 在 EKS 上部署 Sysdig 代理。

• 步骤 1 :导航至以下网址，访问 Jenkins。使用在前面步骤中设置的管理员密码。点击新建项目，如图 10-36 所示。

• URL : http://EXTERNAL_IP:8080

图 10-36.1

创建 Jenkins 流水线

• 第二步:填写表格。输入“CICD-GKEProv-Sysdig”作为项目名称，并选择 Pipeline，因为我们在 Jenkins 中使用 Pipeline 作为代码来自动化之前定义的流程。点击确定，如图 10-36.1 继续。

图 10-37

创作 Jenkins 剧本

• 第三步:点击 Pipeline，会显示一个脚本框，我们将在其中编写 Jenkins 脚本，如图 10-37 所示。

图 10-37.1

保存 Jenkins 脚本

• 第四步:将从 https://github.com/dryice-devops/GKE/blob/master/jenkinsfile-gke-creation 中取出的jenkinsfile-gke-creation文件的jenkinsfile复制到同一个脚本框中，然后点击保存按钮，如图 10-37.1 所示。

Jenkinsfile 的创建包括以下五个阶段:

1. 从 GitHub 克隆代码:在这个阶段，我们从下面的 GitHub 库克隆代码: https://github.com/dryice-devops/GCP.git 。

   The repository contains the following files:

   1. complete-demo.yaml:一个配置文件，包含 Kubernetes 上 Sock Shop 应用部署的细节，如第四章所述。

   2. sysdig-agent-clusterrole.yaml:为 Sysdig 代理创建集群角色的配置文件。这在第七章中有所涉及。

   3. sysdig-agent-configmap.yaml:为 Sysdig 代理创建 ConfigMap 的配置文件。这在第七章中有所解释。

   4. sysdig-agent-daemonset-v2.yaml:为 Sysdig 代理创建 daemonset 的配置文件，在第七章中有所说明。

2. 在 GKE 创建集群集群教程:在这个阶段，我们使用下面的命令在 GKE 通过gcloud创建三个基于节点的 Kubernetes 集群，命名为clustertutorial。

sh "gcloud container clusters create clustertutorial --num-nodes=3 --zone=us-central1-a"

图 10-37.3

Jenkins 脚本中的入站/出站防火墙规则—续

图 10-37.2

Jenkins 脚本中的入站/出站防火墙规则

1. 在 GKE 创建入站/出站防火墙:在 Jenkinsfile 配置的第三阶段，我们将使用图 10-37.2 和图 10-37.3 所示的gcloud命令为 Sysdig 代理在端口 6443 上的入站和出站连接创建有状态防火墙规则。

2. 在 GKE 集群上部署应用:在这个阶段，我们将创建sock-shop名称空间，并在 GKE 集群上部署 Sock Shop 应用，方法是使用下面的 kubectl 命令。

   sh " export KUBECONFIG=~/.kube/config &&  kubectl create namespace sock-shop "
   
   sh " export KUBECONFIG=~/.kube/config && kubectl apply -f '${WORKSPACE}/complete-demo.yaml'  "
   
   

3. 在 GKE 部署 Sysdig:在这个阶段，我们通过 kubectl 在 GKE 部署 Sysdig 代理。

   1. 通过执行以下命令来创建ns名称空间:

      sh " export KUBECONFIG=~/.kube/config && kubectl create ns sysdig-agent"

   2. 在下面的命令中，您必须根据 Sysdig 设置访问键(用黄色突出显示)来更改访问键。

      sh " export KUBECONFIG=~/.kube/config && kubectl create secret generic sysdig-agent --from-literal=access-key=effdab9c-9554-4274-9042-9e8331e1d78b -n sysdig-agent "

   3. 通过执行以下命令，为 Sysdig 代理创建一个集群角色:

      sh " export KUBECONFIG=~/.kube/config && kubectl apply -f '${WORKSPACE}/sysdig-agent-clusterrole.yaml' -n sysdig-agent "

   4. 通过执行以下命令，在 GKE 集群中为 Sysdig 代理创建一个服务帐户:

      sh " export KUBECONFIG=~/.kube/config && kubectl create serviceaccount sysdig-agent -n sysdig-agent "

   5. 定义授予集群角色中的 Sysdig 代理角色的集群角色绑定。

      sh " export KUBECONFIG=~/.kube/config && kubectl create clusterrolebinding sysdig-agent --clusterrole=sysdig-agent --serviceaccount=sysdig-agent:sysdig-agent "

   6. 使用以下命令应用sysdig-agent-configmap.yaml文件。您不必更改该文件中的任何内容。

      sh " export KUBECONFIG=~/.kube/config && kubectl apply -f '${WORKSPACE}/sysdig-agent-configmap.yaml' -n sysdig-agent"

   7. 使用以下命令应用daemonset-v2.yaml文件。您不必更改该文件中的任何内容。

      sh "export KUBECONFIG=~/.kube/config && kubectl apply -f '${WORKSPACE}/sysdig-agent-daemonset-v2.yaml' -n sysdig-agent"

图 10-38

执行 Jenkins 脚本

• 第五步:点击【立即构建】执行 Jenkins 作业，如图 10-38 所示。

图 10-39.2

查看 Jenkins 日志中的应用和 Sysdig 代理部署—续

图 10-39.1

查看 Jenkins 日志中的应用和 Sysdig 代理部署—续

图 10-39

查看 Jenkins 日志，了解应用和 Sysdig 代理的部署情况

• 步骤 6 :一旦作业成功执行，以下构建历史将以蓝色显示构建编号。如果有错误，它将是红色的。它还在阶段视图下显示了阶段。要查看日志，请单击内部版本号(#)。接下来，单击控制台输出。图 10-39 、 10-39.1 和 10-39.2 说明了上述情况。

在日志控制台中，向下滚动屏幕的四分之三，得到新创建的 EKS 节点的详细信息，如图 10-39.3 、 10-39.4 、 10-39.5 和 10-39.6 所示。

图 10-39.6

查看 Jenkins 日志中的应用和 Sysdig 代理部署—续

图 10-39.5

查看 Jenkins 日志中的应用和 Sysdig 代理部署—续

图 10-39.4

查看 Jenkins 日志中的应用和 Sysdig 代理部署—续

图 10-39.3

查看 Jenkins 日志中的应用和 Sysdig 代理部署—续

图 10-40

查看 GCP 控制台

• 第 7 步:导航到你的 GCP 账户控制台，点击计算。接下来，选择 Kubernetes 引擎，然后选择集群，如图 10-40 。

图 10-40.1

查看 GCP 控制台—续

• 您将看到 GKE clustertutorial集群处于活动状态。这是我们通过 Jenkins 和gcloud创建的同一个集群(参见图 10-40.1 )。

图 10-40.2

从 GCP 控制台获取 Sock Shop 应用的 IP 地址

• 现在点击 Services & Ingress，获取 Sock Shop 应用的 URL，如图 10-40.2 所示。

图 10-40.4

打开袜子商店应用

图 10-40.3

从 GCP 控制台获取 Sock Shop 应用的 IP 地址—续

• 导航到前端服务并复制负载均衡器类型的端点，以便打开 Sock Shop 应用，如图 10-40.3 和 10-40.4 所示。

图 10-41

查看 Sysdig 控制台

• 步骤 8 :现在让我们导航到 Sysdig 控制台，确认我们的 GKE 集群已经被添加到 Monitor 下。导航到 Sysdig 网址( https://sysdig.com/ )，用你的凭证登录，如图 10-41 所示。

图 10-42

查看 Sysdig 控制台—续

• 导航浏览➤主机和容器，然后选择按容器概述，如图 10-42 所示。

图 10-43

查看 Sysdig 控制台—续

• 现在，根据图 10-43 ，要验证 Sock Shop 应用是否已部署，请单击探索➤主机和容器➤容器限制。

图 10-44

查看 Sysdig 控制台—续

• 将指针悬停在已用 CPU 份额的图表上。您将看到袜子店容器名称(图 10-44 )。

图 10-46

查看 Sysdig 控制台—续

图 10-45

查看 Sysdig 控制台—续

• 点击➤网络➤总览，如图 10-45 和 10-46 所示。

图 10-48

查看 Sysdig 控制台—续

图 10-47

查看 Sysdig 控制台—续

• 点击浏览➤容器化应用，获取容器化应用的详细信息，如图 10-47 和 10-48 所示。

图 10-49

查看 Sysdig 控制台—续

• 选择任何以weaveworksdemos开头的容器，以获取其详细信息，例如，输入与输出网络字节、按应用/端口划分的网络字节等。(图 10-49 )。

从 Jenkins 流水线中删除 GKE 集群

为了自动化 GKE 集群的清理过程，我们将创建一个 Jenkins 流水线，使用gcloud来清理集群。

要设置流水线，请在删除 GKE 集群clustertutorial和 Sysdig 代理的入口/出口防火墙规则后执行以下步骤。

图 10-50

通过 Jenkins 清理 GKE 集群

• 第一步:打开 Jenkins(网址:http://EXTERNAL_IP:8080)点击新项目(图 10-50 )。

图 10-51

通过 Jenkins 清理 GKE 集群—续

• 步骤 2 :填写表格，输入“删除-GKE-集群”作为项目名称，并选择流水线，因为我们在 Jenkins 中使用流水线作为代码来自动执行之前定义的清理过程。接下来，点击确定按钮(图 10-51 )。

图 10-52

通过 Jenkins 清理 GKE 集群—删除clustertutorial

• 第三步:从下面的 GitHub 资源库中复制jenkinsfile-delete-gke文件中的代码: https://github.com/dryice-devops/GKE 。将文件粘贴到脚本部分，然后单击保存按钮。

• 在这个 Jenkins 文件中，我们使用gcloud命令删除名为clustertutorial的 GKE 集群以及创建的名为sysdig-agent-inbound-firewall-rule和sysdig-agent-outbound-firewall-rule的入站和出站防火墙规则，方法是执行以下命令(另请参见图 10-52 )。

• sh "echo 'Y' | gcloud container clusters delete clustertutorial --zone=us-central1-a"

• sh "gcloud compute firewall-rules delete sysdig-agent-inbound-firewall-rule"

• sh "gcloud compute firewall-rules delete sysdig-agent-outbound-firewall-rule"

图 10-53

通过 Jenkins 清理 GKE 集群—立即构建

• 第四步:点击【立即构建】执行 Jenkins 作业，如图 10-53 所示。

图 10-57

通过 Jenkins 清理 GKE 集群—控制台输出

图 10-56

通过 Jenkins 清理 GKE 集群—控制台输出

图 10-55

通过 Jenkins 清理 GKE 集群—单击内部版本号查看日志

图 10-54

通过 Jenkins 清理 GKE 集群—构建历史

• 步骤 5 :一旦作业成功执行，将显示构建历史。阶段显示在阶段视图下(图 10-54 )。要查看日志，点击内部版本号，如图 10-55 所示。点击控制台输出(图 10-56 ，输出结果如图 10-57 所示。

图 10-58

通过 Jenkins 清理 GKE 集群—与删除的防火墙规则相关的输出

• 在日志控制台中，向下滚动屏幕以获得关于被删除的集群和防火墙规则的信息(图 10-58 )。

图 10-59

清理 GCP 仪表板中的 GKE 集群

• 第 6 步:导航到你的 GCP 账户控制台，点击计算。选择 Kubernetes 引擎，然后选择集群。您将看到 GKE 集群名称clustertutorial正在被删除(图 10-59 )。

图 10-60

清理 GCP 仪表板中的 GKE 集群—续

• 等待 5-10 分钟，以完全删除集群。一旦它被删除，您将看到以下屏幕(图 10-60 )。

摘要

在本章中，我们提供了使用云原生gcloud命令行工具作为 IaC 解决方案和 Jenkins 作为 CI/CD 解决方案的步骤，以自动化容器基础设施的部署，通过 Sysdig 代理实现监控，并最终部署容器化的应用，从而得出本书的结论。我们在本书中涵盖了 GKE 生命周期管理的各个方面，并试图让有实践经验的读者理解 GKE 管理背后的核心概念，包括网络、安全、监控、自动化等。**