Kubernetes快速入门

一、容器集群管理概述

1.1背景概述

容器技术的诞生虽解决了应用打包和发布的难题，但单一的容器技术工具并无 法支持起生产级大规模容器部署的场景。针对这一场景，容器管理与编排成为了容器技术发展的关键。Kubernetes 便是在这样的大背景下诞生的。

1.2发展历程

容器 （如 Docker ）以及周边生态系统提供了很多工具来实现容器生命周期管理，能够满 足在单台宿主机管理容器的需求。但越来越多企业开始使用容器，对容器技术的进一步 发展提出了以下新的诉求：

• 高效的容器管理及编排。
• 容器的跨主机部署及调度。
• 容器的存储、网络、运维、安全等能力的拓展。

Kubernetes 起源于 Google 内部的 Borg 项目，它对计算资源进行了更高层次的抽象，通过将容器进行细致的组合，将最终的应用服务交给用户。它的目标是管理大规模的容器，提供基本的部署、维护以及应用伸缩等功能，其主要实现语言为Go 语言。

  Kubernetes 作为容器集群管理工具，于 2015 年 7 月 22 日迭代到 v1.0 并正式对外公布。与 此同时，谷歌联合Linux 基金会及其他合作伙伴共同成立了 CNCF 基金会（ Cloud Native Computing Foundation），并将 Kuberentes 作为首个编入 CNCF 管理体系的开源项目助力容器技术生态的发展进步。

1.3相关概念

什么是容器引擎

容器引擎允许你绑定一个和运行一个应用在容器里，这是一个松散隔离的环境。由于隔离性和安全性 ，你可以在一台主机上操作多个容器。

容器引擎利用了操作系统的内核资源隔离特性，可以在同一个操作系统上运行多个容器。人们通常把容器引擎比作虚拟机(VMS).

另外一方面，虚拟机利用物理硬件资源抽象层之上可执行代码封装了整个操作系统。

什么是容器

一个容器镜像是一个可运行的软件包，其中包含了一个完整的可执行程序，包括代码和运行时需要应用，系统库和全部重要设置的默认值。

应用程序通过使用容器与底层的宿主机架构解耦，如图所示，我们可以利用底层机器在容器引擎之上运行多个容器。这促进了容器在各种操作系统和云场景中的部署。

什么是容器编排

容器编排与容器的生命周期管理相关，特别是在大型动态环境中。软件团队用容器编排器来控制和自动化容器管理的各种任务。

容器编排器可以工作在使用容器的任何环境。他可以帮助你在多个环境中部署相同的程序，而不需要重新编写它。

1.4  K8s特性

1)   自动装箱：基于容器对应用运行环境的资源配置

2）自动修复

3）水平修复 ：有更多的请求之后，让副本数量增加，满足我们的需求

4）负载均衡 （服务发现） ：两个结点对外提供服务，有统一的入口，订单服务，访问订单的结点，10个请求，每一个结点5个。对外提供统一的入口，让它做到结点调度，负载均衡，这是服务发现

5）滚动更新：加上三个功能，不是直接加上应用就提供服务，检测没问题才提供服务

6）版本回退：

7）密钥和配置管理：热部署，不需要集群都重启起来

8）存储编排

9）批处理：

1.5部署

使用kubeadm快速部署一个K8s集群-CSDN博客

二、Kubernetes架构与核心概念

2.1Kubernetes架构

一个基础的 Kubernetes 集群（ Cluster ）通常包含一个 Master 节点和多个 Node 节点。每个节点可

以是一台物理机，也可以是一台虚拟机。

Master节点

• API server  ---集群统一入口----集群中部署应用的入口，协调者，以restful方式，交给etcd存储
• scheduler   ----结点调度，选择node节点应用部署，master部署，看部署给谁，结点调度
• controller-manager:  处理集群中常规后台任务，，一个资源对应控制器   （假如专门对订单管理）
• etcd  存储系统，用于保存集群中的相关数据，存储，保存集群中的各种数据 例状态数据，pod数据，

Node节点

• kubelet：master派到node节点的代表，管理本机容器
• kube-proxy :提供网络代理，负载均衡等操作

开放接口CRI、CNI、CSI

Kubernetes 作为云原生应用的的基础调度平台，相当于云原生的操作系统，为了便于系 统的扩展，Kubernetes 中开放的以下接口，可以分别对接不同的后端，来实现自己的业 务逻辑：

• CRI（Container Runtime Interface）：容器运行时接口，提供计算能力，是定义了容器和镜像的服务的接口，常见的CRI后端有Docker、rkt、kata-containers等。
• CNI（Container Network Interface）：容器网络接口，提供网络能力，由一组用于配置Linux 容器的网络接口的规范和库组成，同时还包含了一些插件，它仅关心容器创建时的网络分配，和当容器被删除时释放网络资源。
• CSI（Container Storage Interface）：容器存储接口，提供存储能力，通过它，Kubernetes可以将任意存储系统暴露给自己的容器工作负载。

2.2Kubernetes工作流程

2.3Kubernetes核心概念

Pod

Pod 是 Kubernetes 中最重要最基本的概念， Pod 是 Kubernetes 最小工作单元。每一个Pod 包含一个或多个相关容器， Kubernetes 将 Pod 看做一个整体进行调度。

引入 Pod 的目的：

• 将联系紧密的容器封装在一个Pod单元内，以Pod整体进行调度、扩展和实现生命周期管理。
• Pod内所有容器使用相同的网络Namespace和共享 存储。即Pod内容器拥有相同IP地址和Port空间容器间直接使用localhost通信。当挂载volume到Pod，即可实现将volume挂载到Pod中的每个容器。

Label

当资源变得非常多的时候，如何分类管理就非常重要了， Kubernetes 提供了一种机制来为资源分类，那就是Label （标签）。 Label 非常简单，但是却很强大， Kubernetes 中几乎所有资源都可以用Label 来组织。 Label 的具体形式是 key-value 的标记对，可以在创建资源的时候设置，也可以在后期添加和修改。

Namespace

命名空间（ Namespace ）是对一组资源和对象的抽象整合。在同一个集群内可创建不同的命名空间，不同命名空间中的数据彼此隔离。使得它们既可以共享同一个集群的服务，也能够互不干扰。

  在默认情况下，新建的集群存在以下四个 Namespace ：

• default：所有未指定Namespace的对象都会被分配在default命名空间。
• kube-public：此命名空间下的资源可以被所有人访问（包括未认证用户），用来部署公共插件、容器模板等。
• kube-system：所有由Kubernetes系统创建的资源都处于这个命名空间。
• kube-node-lease：每个节点在该命名空间中都有一个关联的“Lease”对象，该对象由节点定期更新，被用来记录节点的心跳信号。

Controller

工作负载是在 Pod 之上的一层抽象，我们可以通过 控制器（ controller ） 实现一系列基于Pod的高级特性，比如节点故障时 Pod 的自动迁移， Pod 多副本横向扩展，应用滚动升级等。我们通常使用controller 来做应用的真正的管理，而Pod是组成工作负载最小的单元。

工作负载按不同业务类型，在 Kubernetes 中分为 以下四类：

 Deployment 和 ReplicaSet

 StatefulSet

 DaemonSet

 Job 和 CronJob

Service

在 Kubernetes 中， Pod 副本发生迁移或者伸缩的时候会发生变化， IP 也是变化的。

Kubernetes 中的 Service 是一种抽象概念，它定义了一个 Pod 逻辑集合以及访问它们的策略。 Service 定义了外界访问一组特定 Pod 的方式。 Service 有自己的 IP 和端口， Service 为Pod提供了负载均衡

Volume

Volume 用来管理 Kubernetes 存储，是用来声明在 Pod 中的容器可以访问的文件目录，含义如下：

 声明在 Pod 中的容器可以访问的文件目录。

 可以被挂载在 Pod 中一个或多个容器的指定路径下。

 支持多种后端存储（本地存储、分布式存储、云存储等）。

三、Kubernetes应用编排与管理

3.1Kubectl介绍

Kubectl 是 Kubernetes 的命令行工具。通过 kubectl ，用户能对集群进行管理，并在集群上进行容器化应用的安装部署。

Kubectl 支持以下对象管理方式：

• 指令式：通过kubectl内置的驱动命令，如：kubectl + create/scale/delete/… + 参数 的形式， 直接快速创建、更新和删除Kubernetes对象。
• 声明式：使用 kubectl apply 创建指定目录中配置文件所定义的所有对象。通常，此配置文件采用yaml进行描述。

命令行语法

在 Kubernetes 中的很多操作都是用 kubectl 来完成，通过其命令可以管理 Deployment 、 Replicaset、 ReplicationController 、Pod等，进行操作、扩容、删除等全生命周期操作，同时可以对管理对象进行查看或者监控资源使用情况。

kubectl 的语法

 Command ：指定你希望进行的操作，如 create ， get ， describe ， delete 等。

 TYPE ：指定操作对象的类型，如 deployment ， pod ， service 等。

 NAME ：指定对象的名字。

 flags: 可选的标志位

yaml示例

创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态， 以及关于对象的一些基本信息（例如名称）。

 apiVersion ：建该对象所使用的 Kubernetes API 的版本。

 kind ：创建的对象的类别，如 Pod/Deploymen/Service 等。

 Metadata ：描述对象的唯一性标识，可以是一个 name 字符串，可

选的 namespace ， label 项指定标签等。

 Spec ：该对象的期望状态，其中 replicas 指定 Pod 副本数量。

apiVersion: apps/v1  # 指定Kubernetes API的版本，这里是apps/v1，表示使用AppsV1版本的API
kind: Deployment  # 指定资源类型为Deployment，表示这是一个部署资源
metadata:  # 元数据部分，包含资源的基本信息
  name: nginx-deployment  # 资源的名称，这里是nginx-deployment
  labels:  # 标签，用于标识和选择资源
    app: nginx  # 标签键值对，这里将app设置为nginx
spec:  # 规格部分，定义了资源的详细配置
  replicas: 2  # 副本数，表示需要创建两个nginx容器实例
  selector:  # 选择器，用于选择要管理的Pod
    matchLabels:  # 匹配标签，这里的选择器匹配所有具有app=nginx标签的Pod
      app: nginx
  template:  # 模板，用于定义Pod的结构和配置
    metadata:  # Pod的元数据
      labels:  # Pod的标签，这里同样设置为app=nginx
        app: nginx
    spec:  # Pod的规格
      containers:  # 容器列表，这里只有一个容器
      - name: nginx  # 容器名称，这里是nginx
        image: nginx:1.14.2  # 容器使用的镜像，这里是nginx的1.14.2版本
        ports:  # 容器暴露的端口列表
        - containerPort: 80  # 容器暴露的端口号，这里是80

工作负载类型

3.2Deployment概述

  Deployment 是一组不具有唯一标识的多个 Pod 的集合，具备以下功能：

 确保集群中有期望数量的 Pod 运行。

 提供多种升级策略以及一键回滚能力。

 提供暂停 / 恢复的能力。

典型使用场景：

 Web Server 等无状态应用。

使用命令行创建Deployment

创建一个简单的deployment：

$ kubectl create deployment mydep --image=nginx --replicas=3

使用如下语句查看deployment的创建情况：

$ kubectl get deployment

回显：

NAME READY UP-TO-DATE AVAILABLE AGE
mydep 1/1 1 1 2m3s

• NAME：部署的名称；
• READY：表示当前已准备好的副本数量；
• UP-TO-DATE：表示当前已更新到最新版本的副本数量；
• AVAILABLE：表示当前可用的副本数量；
• AGE：表示部署创建的时间。

使用yaml创建Deployment

查看容器内部详情

kubectl describe deployment jzb-base-report

滚动更新

  用户希望应用程序始终可用，而开发人员则需要每天多次部署它们的新版本。在 Kubernetes中，这些是通过滚动更新（ Rolling Updates ）完成的。 滚动更新 允许通过 使用新的实例逐步更新Pod 实例，零停机进行工作负载的更新。新的 Pod 将在具有可用资源的节点上进行调度

滚动更新允许以下操作：

 将应用程序从一个环境提升到另一个环境（通过容器镜像更新）。

 回滚到以前的版本。

 持续集成和持续交付应用程序，无需停机。

3.3StatefulSet概述

在某些分布式的场景，比如分布式数据库，要求每个 Pod 都有自己单独的状态时，这时Deployment就不能满足需求了。

此类应用依靠 StatefulSet 进行部署。 StatefulSet 具备的以下特征：

 Pod 有稳定的网络标识符， Pod 重新调度后 PodName 和 HostName 不变。

 每个 Pod 有单独存储，保证 Pod 重新调度后还是能访问到相同的数据。

创建StatefulSet

apiVersion: apps/v1  # 指定Kubernetes API的版本，这里是apps/v1版本
kind: StatefulSet  # 定义资源类型为StatefulSet，用于管理有状态应用
metadata:  # 元数据部分，包含资源的基本信息
  name: web  # 资源的名称
spec:  # 规格说明部分，描述了资源的具体配置
  selector:  # 选择器，用于匹配符合条件的Pod
    matchLabels:  # 标签匹配规则
      app: nginx  # 匹配具有app=nginx标签的Pod
  serviceName: nginx  # 关联的服务名称，这里关联的是名为nginx的服务
  replicas: 3  # 副本数量，表示需要创建3个副本
  template:  # Pod模板，用于创建新的Pod
    metadata:  # Pod的元数据部分
      labels:  # Pod的标签
        app: nginx  # 设置Pod的标签为app=nginx
    spec:  # Pod的规格说明部分
      containers:  # 容器列表
      - name: nginx  # 容器名称
        image: nginx  # 容器使用的镜像
        ports:  # 容器暴露的端口列表
        - containerPort: 80  # 容器监听的端口号
          name: web  # 端口的名称
        volumeMounts:  # 卷挂载信息
        - name: www  # 卷的名称
          mountPath: /usr/share/nginx/html  # 挂载到容器内的路径

3.4DaemonSet概述

DaemonSet （守护进程集）部署的副本 Pod 会分布在各个Node上。它具备以下特点：

• 确保每一个节点或者期望的节点（通过nodeSelector实现）上运行一个Pod。
• 新增节点时自动部署一个Pod。
• 移除节点时自动删除Pod。

DaemonSet 典型场景：

 在集群的每个节点上运行存储 Daemon ，如 glusterd ， ceph 。

 在每个节点上运行日志收集 Daemon ，如 fluentd 或 logstash 。

 在每个节点上运行监控 Daemon ，如 Prometheus Node Exporter 。

创建DaemonSet

这是一个Kubernetes命令，用于获取集群中所有Pod的详细信息。其中：

• kubectl 是Kubernetes的命令行工具；
• get pod 表示获取Pod的信息；
• -o wide 是一个选项，表示以宽格式输出结果，包括更多的信息字段。

输出的结果包含了以下字段：

• NAME: Pod的名称；
• READY: Pod中的容器就绪状态，显示已就绪的容器数量和总容器数量；
• STATUS: Pod的状态，如Running、Pending等；
• RESTARTS: Pod重启的次数；
• AGE: Pod的年龄，即创建时间；
• IP: Pod的IP地址；
• NODE: Pod所在的节点名称；
• NOMINATED NODE: 如果Pod被分配了特定的节点，则显示该节点的名称；
• READINESS GATES: Pod的就绪门状态，用于控制Pod是否准备好接收流量。

3.5Jobs概述

Jobs 主要处理一些短暂的一次性任务，并具备以下特点：

 保证指定数量 Pod 成功运行结束。

 支持并发执行。

 支持错误自动重试。

 支持暂停 / 恢复 Jobs 。

  典型使用场景：

 计算以及训练任务 , 如批量计算， AI 训练任务等。

创建Jobs

3.6CronJob概述

CronJob 主要处理周期性或者重复性的任务：

 基于 Crontab 格式的时间调度。

 可以暂停 / 恢复 CronJob 。

  典型的使用场景：

 周期性的数据分析服务。

 周期性的资源回收服务。

创建CronJob

四、Kubernetes服务发布

4.1Pod的特征

4.2Service概述

Kubernetes Service 定义了这样一种抽象：逻辑上的一组 Pod ，一种可以访问它们的策略，通常称为微服务。 这一组Pod 能够被 Service 访问到，通常是通过 Label Selector 实现的。

Kubernetes 支持以下 Service 类型：

 ClusterIP ：提供一个集群内部的虚拟 IP 地址以供 Pod 访问（默认模式）。

 NodePort ：在 Node 上打开一个端口以供外部访问。

 LoadBalancer ：通过外部的负载均衡器来访问.

创建后端Deployment

ClusterIP模型

创建集群内访问Service（ClusterIP）

使用Service

查看 Service 简明信息，可以获取 Service 提供服务的 ip 地址和端口

$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
httpd-svc ClusterIP 10.103.76.128 <none> 8080/TCP 41m
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 134m

测试 Service 是否正常提供服务：

$ curl 10.103.76.128:8080
<html><body><h1>It works!</h1></body></html>

使用 describe 命令可以查看 Service 详细信息。如 Endpoints 信息，显示 Service 关联 pod 的

地址和服务端口：

kubectl describe service my-service

NodePort模型

节点访问 （ NodePort ）是指在每个节点的 IP 上开放一个静态端口，通过静态端口对外暴露服务，后将外部请求路由至集群内部的ClusterIP 。

创建可供外部访问的 Service （ NodePort ）

LoadBalancer模型

4.3Ingress概述

Service 是基于四层 TCP 和 UDP 协议转发的，而在实际使用场景中，四层 Service 无法满足 应用层存在的大量HTTP/HTTPS 访问需求，因此需要使用七层负载均衡（ Ingress ）来暴 露服务。

Ingress 可基于七层的 HTTP 和 HTTPS 协议进行转发，它是 Kubernetes 集群中一种独立的资源，制定了集群外部访问流量的转发规则。这些转发规则可根据域名和路径进行自定义，Ingress Controller根据这些规则将流量分配到一个或多个 Service ，完成对访问流量的细粒度划分。

五

五、Kubernetes存储管理

5.1Volume概述

Volume的核心是一个目录，其中可能存有数据， Pod 中的容器可以访问该目录中的数据。 用户创建Volume 时选择的卷类型将决定该目录如何形成，使用何种介质保存数据，以及 规定目录中存放的内容。

  Volume 的生命周期与挂载它的 Pod 相同，但是 Volume 里面的文件可能在 Volume 消失后 仍然存在，这取决于卷的类型。如当Pod 不再存在时， Kubernetes 也会销毁临时卷，但 并不会销毁持久卷。

5.2Volume类型

 Kubernetes 支持多种卷类型，常用的类型有：

 emptyDir ：一种简单的空目录，主要用于临时存储。

 hostPath ：将主机（节点）某个目录挂载到容器中，适用于读取主机上的数据。

 ConfigMap ：特殊类型，将 Kubernetes 特定的对象类型挂载到容器。

 Secret ：特殊类型，将 Kubernetes 特定的对象类型挂载到容器。

 PVC ： PersistentVolumeClaim ，用来挂载 PersistentVolume （持久化卷），提供可靠的存储来

保存应用的持久化数据

5.3Volume管理

EmptyDir简介

  特征：

当Pod指定到某个节点上时，首先创建的是一个emptyDir卷，并且只要Pod在该节点上运行， 卷就一直存在，卷最初是空的。尽管Pod中的容器挂载emptyDir卷的路径可能相同也可能不同，但是这些容器都可以读写emptyDir卷中相同的文件。 当Pod因为某些原因被从节点上删除时，emptyDir卷中的数据也会永久删除。

使用场景：

不同容器之间共享文件（例如日志采集等）。

HostPath简介

  特征：

 hostPath卷能将主机节点文件系统上的文件或目录挂载到Pod中。

  使用场景：

 运行需要访问Docker内部文件的容器：使用 /var/lib/docker 的hostPath。

 在容器中运行cAdvisor：使用 /sys/fs/cgroup 的hostPath。

 其他使用到宿主机文件的场景

ConfigMap简介

  特征：

 ConfigMap 用于容器的配置文件管理，在被 Pod 引用前需单独定义。它作为多个 properties 文

件的应用，类似一个专门存储配置文件的目录，里面存放着各种配置文件。

  应用场景：

 ConfigMap 最为常见的使用方式就是在环境变量和 Volume 中引用，能够实现 image 和应用程

序的配置文件、命令行参数和环境变量等信息解耦

Secret简介

  Secret 是一种包含少量敏感信息例如密码、 token 或 key 的对象。

  特征：

 在创建、查看和编辑 Pod 的流程中 Secret 暴露风险较小。

 系统会对 Secret 对象采取额外的预防措施，例如避免将其写入磁盘。

 只有 Pod 请求的 Secret 在其容器中才是可见的，一个 Pod 不能访问另一个 Pod 的 Secret 。

  应用场景：

 Secret 与 ConfigMap 非常像，都是 key-value 键值对形式，使用方式也相同，不同的是 Secret 会

加密存储，所以适用于存储敏感信息。

PV/PVC/SC概念介绍

  PersistentVolume ：持久化存储，简称 PV ，是 Kubernetes 对存储资源的抽象，属于集群

资源，可以由管理员事先创建，或者使用存储类（ Storage Class ）实现动态供应。

  PersistentVolumeClaim ：持久化存储声明，简称 PVC ，是用户对存储卷（ PV ）的申请，

属于 Namespace 中的资源。

StorageClass ：存储类，简称 SC ，为管理员提供了描述存储 “ 类 ” 的方法，通过相应的存

储插件（ CSI ）实现，可根据用户提出的 PVC 动态提供不同性质的 PV 。

六、K8S 监控和日志

6.1 监控指标

Kubernetes 提供了一套完整的监控体系，可以帮助我们对集群、服务和应用程序进行监控和警报。下面介绍两种常见的监控指标：Node 监控和 Pod 监控。

Node 监控

Node 监控指标主要包括以下几个方面：

• CPU 使用率
• 内存使用率
• 网络 IO
• 磁盘 IO
• 负载均衡器负载

这些监控指标可以通过 Kubernetes API Server 提供的 kubelet API 获取。在 Kubernetes 中，kubelet 是负责管理节点的核心组件，它会定期采集节点的监控指标，并将采集到的数据暴露给 API Server。

可以使用 Prometheus 等工具来对采集到的监控指标进行展示和分析，以便及时发现异常情况并采取相应措施。

Pod 监控

Pod 监控指标主要包括以下几个方面：

• CPU 使用率
• 内存使用率
• 网络 IO
• 磁盘 IO

这些监控指标可以通过 Kubernetes API Server 提供的 Metrics API 获取。Metrics API 是 Kubernetes 自带的一种监控指标暴露机制，它可以让用户通过 API Server 直接获取到节点和 Pod 的监控指标信息。

可以使用 Heapster、Prometheus 等工具来对采集到的监控指标进行展示和分析，以便及时发现异常情况并采取相应措施。

6.2 日志管理

在 Kubernetes 中，我们通常需要对容器中的日志进行收集、存储、查询和分析。下面介绍两种常见的日志管理方式：Kubernetes 自带日志收集和第三方日志收集器。

 Kubernetes 自带日志收集

Kubernetes 自带了一个日志收集器：kubelet。kubelet 会负责收集容器的标准输出（stdout）和标准错误输出（stderr），并将其重定向到文件中。这些文件可以通过以下方式查看：

• 使用 kubectl logs 命令查看 Pod 中容器的日志；
• 在节点上查看容器的日志文件。默认情况下，这些文件位于 /var/log/pods 目录中，文件名的格式为 namespace_podname_containername_xxxxxx.log。

该日志收集方式的优点是简单易用，无需安装额外的组件。缺点是不够灵活，只能收集容器的标准输出和标准错误输出，无法收集其他类型的日志。

第三方日志收集器

第三方日志收集器可以帮助我们更加灵活地收集和管理容器中的日志。常见的第三方日志收集器包括：

• Fluentd：是一个轻量级的日志收集和转发工具，可以将多个容器的日志聚合到一起，并将其发送到指定的存储后端（如 Elasticsearch 或者 Amazon S3）。
• Logstash：是一个开源的数据收集引擎，支持多种数据源和输出方式，可以与 Elasticsearch、Kibana 等工具一起使用来构建强大的日志管理系统。
• Sysdig：是一个安全监控和故障排除工具，支持实时容器日志收集和查询，可以帮助我们更快地定位容器中的问题。

这些工具各有优缺点，可以根据实际需求进行选型。需要注意的是，在使用第三方日志收集器时，需要对容器进行相应的配置，以便将日志发送给指定的收集器。

七、K8S 生态系统

7.1 Helm

Helm 是一个 Kubernetes 应用程序包管理器，允许您轻松安装、升级和管理 Kubernetes 应用程序。Helm 使用称为 charts 的包来描述 Kubernetes 资源。Chart 定义了一组相关的 Kubernetes 资源，以及一些参数，允许您自定义这些资源的行为。通过使用 Helm，您可以简化 Kubernetes 应用程序的部署和维护，使得管理和扩展 Kubernetes 应用程序更加容易。

7.2 Istio

Istio 是一个开源的服务网格平台，允许您连接、保护、控制和观察 Kubernetes 中的服务。Istio 提供了一些功能来增强 Kubernetes 网络的可靠性、安全性和可观测性，包括流量管理、安全、监控和跟踪等方面。它使用 sidecar 容器的方式将其与应用程序部署在一起，从而提供了对网络、安全和其他服务的通用控制。

7.3 Prometheus

Prometheus 是一个开源的监控系统，广泛用于 Kubernetes 中的应用程序和基础设施监控。Prometheus 可以收集、存储和查询各种类型的时间序列数据，并提供灵活的查询语言（PromQL）来分析和聚合这些数据。它还提供了图形化仪表板和告警系统，方便您了解应用程序和基础设施的运行状况。

 Kubernetes API Server Metrics

Kubernetes API Server Metrics 描述了 Kubernetes API Server 的健康状况和性能指标，包括 API Server 的响应时间、请求成功率、并发连接数等。这些指标可以帮助您了解集群 API Server 的负载和稳定性，并帮助您检测和处理问题。

Kubernetes Node Metrics

Kubernetes Node Metrics 描述了 Kubernetes Node 上的资源使用情况，包括 CPU、内存、磁盘和网络等。这些指标可以帮助您了解节点的资源利用率和容量规划，并帮助您检测和解决问题，如节点故障、资源耗尽等。

 应用程序 Metrics

应用程序 Metrics 描述了 Kubernetes 中应用程序的健康状况和性能指标，包括应用程序的请求延迟、响应时间、错误率等。这些指标可以帮助您了解应用程序的运行状况，并帮助您检测和处理问题，如应用程序错误、性能下降等。

7.4 Grafana

Grafana 是一个开源的数据可视化平台，与 Prometheus 集成广泛使用于 Kubernetes 环境中。通过 Grafana，您可以创建各种类型的仪表板，并动态地可视化 Prometheus 中的数据。Grafana 还提供了丰富的图表和面板，方便您对 Kubernetes 应用程序和基础设施进行监控和分析。您可以使用 Grafana 对 Kubernetes 中的各种指标进行可视化展示，例如 Kubernetes API Server Metrics、Kubernetes Node Metrics、应用程序 Metrics 等。