什么是lens

Lens 是当前市场上最强大的K8S IDE。它是一个独立的单机应用，可以同时运行在macOS、Windows和Linux上。

作为K8S IDE，该有的它基本都有了！

集群管理

导入已有集群
首先，你需要在 Lens 中添加你的 Kubernetes 集群。点击 Lens 界面左上角的 "+ "图标，然后你可以选择 kubeconfig 文件的具体位置。这份文件会包含你的集群信息，Lens 会自动读取并显示在集群列表中。

添加集群后即可查看修改对应资源信息

Overview

通过Overview CPU、内存和 Pods 的状态：

图像中的信息提供了对计算资源使用的一个概览，帮助用户监控和管理资源的分配和使用情况。

Applications

在 Kubernetes 中，“Applications” 通常指的是运行在集群中的应用程序实例。这些应用程序可以是由多个容器组成的复杂服务，通常通过 Kubernetes 的工作负载（如 Deployment、StatefulSet、DaemonSet 等）进行管理。

Kubernetes 使用命名空间来隔离资源。如果你在某个特定的命名空间中查看“Applications”，而实际的应用程序被部署在其他命名空间中，那么你将看不到任何应用程序实例。
如下图，我们选择所有命名空间：

这幅图像提供了对当前 Kubernetes 集群内所有应用程序实例的概览，帮助用户了解各应用的状态、管理工具及运行时间。
屏幕顶部显示 “Applications - demo-k8s”，表示当前查看的是名为 “demo-k8s” 的 Kubernetes 集群内的应用程序实例。

Instance（实例）：每个实例的名称
Application（应用程序）：提示每个实例对应的应用程序名称。

这幅图像展示了一个 Kubernetes 管理界面的 Pods 列表

• Name（名称）：显示 Pod 的名称
• Namespace（命名空间）：指示每个 Pod 所属的命名空间
• Containers（容器）：指每个 Pod 中的容器数量。某些 Pods 中有多个容器，条形图显示了各 Pod 中的容器资源占用情况
• CPU：显示每个 Pod 消耗的 CPU 资源，数值较小，表示资源使用较低。Kubernetes 允许用户请求部分 CPU。例如，0.5 表示请求半个 CPU 核心，0.25 则表示请求四分之一的 CPU 核心。这使得资源管理更加灵活
• Memor（内存）：展示每个 Pod 使用的内存量，以 MiB 为单位（例如：15.1MiB、262.8MiB 等）。
• Restart：指示 Pod 的重启次数，所有 Pods 均显示 0，表示自创建以来没有重启。
• Controlled By（控制者）：显示每个 Pod 的控制器类型，如 DaemonSet 和 ReplicaSet，指示 Pods 是由哪个控制器管理的。
• Node（节点）：显示 Pod 所运行的节点名称。
• QoS（服务质量）：显示 Pods 的服务质量等级，包括 Burstable 和 BestEffort，帮助用户了解 Pods 的资源请求和限制。
• Age（年龄）：显示每个 Pod 运行的时间，所有 Pods 均为 14d，表示它们已运行了 14 天。
• Status（状态）：所有 Pods 的状态均为 “Running”，表明它们当前正在正常运行。

相关解释：
cpu小数理解：
在定义 Pods 时，可以为每个容器设置 CPU 的请求（request）和限制（limit）：
请求：容器启动所需的最低资源。如果请求的 CPU 资源被设置为 0.5，Kubernetes 会确保该 Pod 至少有 0.5 个 CPU 核心可供使用。
限制：容器可以使用的最大资源。如果限制设置为 1，Pod 在运行时的 CPU 消耗不会超过这个数量。

QoS（服务质量）等级
在 Kubernetes 中，QoS（服务质量）等级用于根据 Pod 的资源请求和限制来分类 Pods，以便为调度和资源管理提供指导。QoS 分为三种主要类别：Guaranteed、Burstable 和 BestEffort。

1. Guaranteed（保证型）

定义：如果 Pod 的每个容器都有明确设置的请求和限制，并且这两个值相等，则该 Pod 被视为 Guaranteed 类型。
特征：
提供对资源的强保证。
对于这个类型的 Pod，如因节点资源紧张，Kubernetes 会尽量保持这些 Pod 继续运行，只有在没有其他选择的情况才会驱逐它们。
适用场景：适合需要高性能和稳定性的关键应用，确保在负载变化时能维持资源使用。

2. Burstable（突发型）

定义：如果 Pod 的容器设置了请求（request）和限制（limit），但请求和限制不相等，即请求的 CPU 或内存小于限制，则该 Pod 被分类为 Burstable 。
特征：
允许 Pod 在需求高峰期使用更多资源，但仍有基础的资源请求保证。
Kubernetes 会尽量确保 Pod 拥有其请求的资源，同时在节点资源充足时可以使用更多资源。
适用场景：适合负载波动较大的应用，能够在需要时获得额外的资源，但同时又有一定的资源管理策略。

3. BestEffort（最佳努力型）

定义：如果 Pod 的容器没有设置任何请求或限制，则该 Pod 被视为 BestEffort 类型。
特征：
不对资源提供任何保证，Pod 可以使用任何可用资源，但在资源紧张时，它们是最先被驱逐的。
在资源丰富时盈利，资源不足时风险高。
适用场景：适用于对资源不敏感的非关键应用，或者对性能要求不高的工作负载。

总结
QoS 在 Kubernetes 中为 Pods 提供了不同的资源处理策略，帮助用户在资源有限的情况下平衡稳定性和弹性：
Guaranteed Pods 确保资源可用性，适用于关键任务应用。
Burstable Pods 允许灵活使用资源，适用于负载变化较大的服务。
BestEffort Pods 没有资源保障，适用于对资源需求不敏感的工作负载。
通过合理利用 QoS 机制，用户可以优化集群资源的使用，提高应用程序的性能和可靠性。

Nodes（节点）

如下显示的是名为 “demo-k8s” 的 Kubernetes 集群的节点信息。

表格中列出了三个节点的详细信息，主要包括以下列：
Name（名称）：节点的完整域名，分别是 ip-10-230-11-22.eu-west-1.compute、ip-10-230-2-151.eu-west-1.compute 和 ip-10-230-6-128.eu-west-1.compute。
CPU：显示每个节点的 CPU 使用情况，使用条形图表示，具体数值可能隐藏，只显示使用比例。
Memory（内存）：类似于 CPU，显示每个节点的内存使用情况。
Disk（磁盘）：显示节点的磁盘使用情况，表格中可能包括当前使用量。
Taint（污点）：显示节点的 Taint 信息，表中示例中第一个节点有 1 个 Taint。
Roles（角色）：显示每个节点的角色，例如 privileged 和 app。
Version（版本）：显示节点使用的 Kubernetes 版本，这里均为 v1.30.8-eks-a.e。
Age（年龄）：每个节点自创建以来的时间，例如 14d 表示运行了 14 天。
Conditions（条件）：显示节点的状态，所有节点状态均显示为 “Ready”，表示它们正常运行并准备接受工作负载。

Taint
/teɪnt/

tolerations
/ˌtɒləˈreɪʃənz/

taint（污点）和Toleration（容忍）可以作用于node和pod 上（即：污点是给node节点设置的，容忍度是给pod设置的）

Taint 和 toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 pod，是不会被该节点接受的。如果将 toleration 应用于 pod 上，则表示这些 pod 可以（但不要求）被调度到具有相应 taint 的节点上。

官方文档链接： https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/

Workloads工作负载

通过Workloads查看集群主体资源、Pods、Deployments等资源信息

界面中有多个环形图表示不同类型工作负载的状态：

• Pods：
  共 41 个 Pods，其中全部 41 个 Pods 状态为 “Running”。
• Deployments（部署）：
  共 20 个部署，所有部署状态均为 “Running”。
• Daemon Sets（守护进程集合）：
  共 7 个守护进程集合，其中 6 个在 “Running” 状态，1 个状态为 “Unknown”。
• Stateful Sets（有状态集合）：
  只有 1 个有状态集合，当前状态为 “Running”。
• Replica Sets（副本集合）：
  共 56 个副本集合，其中 20 个在 “Running” 状态，而 36 个状态为 “Unknown”。

在页面底部，有一个区域显示 Jobs 和 Cron Jobs 的数量，这两个项目目前均为 0，表示当前没有任何作业或定时作业。

工作负载类型

• Pods：
  Pods 是 Kubernetes 的基本执行单元，包含一个或多个紧密耦合的容器。Pods 最适合用于运行单个实例的应用程序。
• Deployments（部署）：
  Deployments 提供了一种声明式的方式来管理 Pods 的部署和扩缩。它能够确保指定数量的 Pods 持续运行，并支持版本控制和滚动更新，使得可以方便地更新和回滚应用程序。
• Stateful Sets（有状态集合）：
  Stateful Sets 用于管理有状态应用程序，这类应用需要持久性存储和唯一的标识。它确保 Pods 启动、停止以及扩展时的顺序性，并为每个 Pod 提供一个独特的网络标识和持久存储。
• Daemon Sets（守护进程集合）：
  Daemon Sets 确保每个节点上都运行一个 Pod 的副本，适用于一些需要在每个节点上运行的后台服务，例如日志收集、监控或者网络管理工具。
• Replica Sets（副本集合）：
  Replica Sets 确保在任意时间有指定数量的 Pods 正在运行。虽然通常使用 Deployments 来管理副本集，但本身也是工作负载的一种，适合需要手动管理副本的场景。
• Jobs（作业）：
  Jobs 用于一次性任务的执行，确保指定数量的 Pods 成功完成特定的计算任务。作业完成后，Pods 会变为 Completed 状态，不再运行。
• Cron Jobs（定时作业）：
  Cron Jobs 是一种特殊的类型，用于定期执行的作业，类似于 Unix 系统中的 cron 任务。它能在指定的时间和频率下创建 Jobs。

Deployments 和 Pods

Pods

• 基本单位：
  Pods 是 Kubernetes 中的基本执行单元，用于封装一个或多个紧密耦合的容器（通常是一个容器）。一个 Pod 中的容器可以共享网络、存储等资源。
• 生命周期管理：
  Pods 的生命周期短暂，可以被创建和销毁。它们不具备自我管理能力，例如检测到失败后自动重启。Pods 一旦被删除，所运行的容器也会随之终止。
• 适用场景：
  Pods 适合用于运行简单应用程序或服务的单个实例，通常不需要进行复杂的管理。

Deployments

• 高级管理：
  Deployments 是一种对 Pod 的管理抽象，提供了一种声明式方式来管理应用的部署。用户可以定义所需的 Pod 数量和其他策略，Deployments 会负责创建、更新和维护这些 Pods 的状态。
• 自我修复：
  Deployments 会自动监控 Pods 的健康状态，并确保所需数量的 Pods 始终在运行。如果某个 Pod 出现故障或被删除，Deployment 会自动创建新的 Pod 以替代它。
• 版本控制和更新：
  Deployments 支持版本控制和滚动更新，使得应用程序的版本更新可以逐步进行，降低了更新过程中的风险。如果需要，可以轻松回滚到先前的版本。
• 适用场景：
  Deployments 适用于需要高可用性和灵活性的应用程序，特别是那些需要频繁更新和管理的微服务架构。

用户通常通过创建一个 Deployment 来管理多个 Pod，而每个 Deployment 可以创建和管理多个 Pods，以确保应用的水平扩展和高可用性。
一般情况下，使用 Deployments 是推荐的做法，因为它提供了更高级的管理功能，而 Pods 则常常是 Deployments 管理的对象。

Config（配置）

通过Configuration来查看集群ConfigMaps、Secrets、HPA等信息：

每个条目代表 Kubernetes 中的不同配置资源：

• Config Maps：用于存储配置信息，方便应用程序动态加载配置。
• Secrets：用于存储敏感信息，如密码、密钥等，提供了额外的安全性。
• Resource Quotas：用于限制命名空间中资源的使用量，以确保资源的公平分配。
• Limit Ranges：定义在命名空间中 Pod 和容器的资源请求和限制的范围。
• Horizontal Pod Autoscalers：用于根据 CPU 使用率或其他指标自动调整 Pod 的副本数量。
• Pod Disruption Budgets：用于定义在操作（如升级）期间可以被中断的 Pod 数量。
• Priority Classes：为 Pods 设置优先级，以便在资源紧张时决定哪些 Pods 最先得到资源。
• Runtime Classes：定义不同的运行时环境，以便为 Pods 提供不同的配置和特性。
• Leases：用于协调控制器之间的租约管理，帮助处理资源访问的竞争。
• Mutating Webhook Configurations：用于在创建或更新 Kubernetes 资源时动态修改请求的对象。
• Validating Webhook Configurations：用于在创建或更新 Kubernetes 资源时验证请求的对象是否合法。

Network

• Services（服务）：用于定义和管理 Kubernetes 中的服务，负责将网络请求路由到正确的 Pods。
• Endpoints（端点）：用于显示与服务关联的 Pod 的网络地址，帮助识别服务的实际后端。
• Ingresses（入口）：用于管理外部访问到 Kubernetes 集群中服务的路由规则。
• Ingress Classes（入口类）：定义不同类型的入口控制器，帮助对不同的路由方式进行分类。
• Network Policies（网络策略）：用于定义 Pod 之间的网络访问控制，限制 Pod 之间的通信。
• Port Forwarding（端口转发）：允许将请求转发到集群中的 Pods，便于开发和调试。

其他控制组件

Namespaces（命名空间）：用于组织 Kubernetes 集群中的资源，有助于实现资源隔离和管理。
Events（事件）：用于查看 Kubernetes 集群中发生的事件，帮助用户监控和调试集群状态。
Helm：指向 Helm，Kubernetes 的包管理工具，帮助用户管理应用程序的发布和更新。
Access Control（访问控制）：涉及权限和访问管理，确保用户可以根据需要访问集群资源。
Custom Resources（自定义资源）：用于管理 Kubernetes 中的自定义资源类型，可以扩展 Kubernetes 的功能。
Definitions（定义）：可能用于进一步展示自定义资源的定义和配置选项。