软件开发公司介绍怎么写_深圳哪家网站设计比较好_酒店线上推广方案有哪些_排名优化哪家好

新建集群

集群名称为姓名拼音

一、创建企业空间、项目、用户和平台角色

KubeSphere 的多租户系统分三个层级，即集群、企业空间和项目。KubeSphere 中的项目等同于 Kubernetes 的命名空间。

您需要创建一个新的企业空间进行操作，而不是使用系统企业空间，系统企业空间中运行着系统资源，绝大部分仅供查看。出于安全考虑，强烈建议给不同的租户授予不同的权限在企业空间中进行协作。

您可以在一个 KubeSphere 集群中创建多个企业空间，每个企业空间下可以创建多个项目。KubeSphere 为每个级别默认设有多个内置角色。此外，您还可以创建拥有自定义权限的角色。KubeSphere 多层次结构适用于具有不同团队或组织以及每个团队中需要不同角色的企业用户。

步骤1 创建用户

安装 KubeSphere 之后，您需要向平台添加具有不同角色的用户，以便他们可以针对自己授权的资源在不同的层级进行工作。一开始，系统默认只有一个用户 admin，具有 platform-admin 角色。在本步骤中，您将创建一个示例用户 ws-manager。

1、以 admin 身份使用默认帐户和密码 (admin/P@88w0rd) 登录 Web 控制台。

2、点击左上角的平台管理，然后选择访问控制。在左侧导航栏中，选择平台角色。内置角色的描述信息如下表所示。

3、在用户中，点击创建。在弹出的对话框中，提供所有必要信息（带有*标记）。在平台角色下拉列表，选择platform-self-provisioner。完成后，点击确定。新创建的用户将显示在用户页面。

4、重复以上的步骤创建新用户。

5、在用户页面，查看创建的用户。

步骤2 创建企业空间

作为管理项目、DevOps 项目和组织成员的基本逻辑单元，企业空间是 KubeSphere 多租户系统的基础。

1、在左侧导航栏，选择企业空间。企业空间列表中已列出默认企业空间 system-workspace，该企业空间包含所有系统项目。其中运行着与系统相关的组件和服务，您无法删除该企业空间。

2、在企业空间列表页面，点击创建，输入企业空间的名称（姓名拼音），并将用户 ws-admin 设置为企业空间管理员。完成后，点击创建。

3、登出控制台，然后以 ws-admin 身份重新登录。在企业空间设置中，选择企业空间成员，然后点击邀请。

4、邀请 project-admin 和 project-regular 进入企业空间，分别授予 demo-workspace-self-provisioner 和 demo-workspace-viewer 角色，点击确定。

5、将 project-admin 和 project-regular 都添加到企业空间后，点击确定。在企业空间成员中，您可以看到列出的三名成员。

步骤3 创建项目

在此步骤中，您需要使用在上一步骤中创建的帐户 project-admin 来创建项目。KubeSphere 中的项目与 Kubernetes 中的命名空间相同，为资源提供了虚拟隔离。有关更多信息，请参见命名空间。

1、以project-admin 身份登录 KubeSphere Web 控制台，在项目中，点击创建。

2、输入项目名称（例如 姓名拼音-project），点击确定。您还可以为项目添加别名和描述。

3、在项目设置 > 项目成员中，邀请 project-regular 至该项目，并授予该用户 operator 角色。具有 operator 角色的用户是项目维护者，可以管理项目中除用户和角色以外的资源。

4、创建应用路由（即 Kubernetes 中的 Ingress）之前，需要启用该项目的网关。网关是在项目中运行的 NGINX Ingress 控制器。若要设置网关，请转到项目设置中的网关设置，然后点击设置网关。此步骤中仍使用帐户 project-admin。

5、选择访问方式 NodePort，然后点击确定。

6、在网关设置下，可以在页面上看到网关地址以及 http/https 的端口。

二、创建并部署 WordPress

WordPress（使用 PHP 语言编写）是免费、开源的内容管理系统，用户可以使用 WordPress 搭建自己的网站。完整的 WordPress 应用程序包括以下 Kubernetes 对象，由 MySQL 作为后端数据库。

project regular账户登录。

1、创建密钥

创建 MySQL 密钥

环境变量 WORDPRESS_DB_PASSWORD 是连接到 WordPress 数据库的密码。在此步骤中，您需要创建一个密钥来保存将在 MySQL Pod 模板中使用的环境变量。

1. 使用 project-regular 帐户登录 KubeSphere 控制台，访问 demo-project 的详情页并导航到配置。在保密字典中，点击右侧的创建。
2. 输入基本信息（例如，将其命名为 mysql-secret）并点击下一步。在下一页中，选择类型为 Opaque（默认），然后点击添加数据来添加键值对。输入如下所示的键 (Key) MYSQL_ROOT_PASSWORD 和值 (Value) 123456，点击右下角 √ 进行确认。完成后，点击创建按钮以继续。

创建 WordPress 密钥

按照以上相同的步骤创建一个名为 wordpress-secret 的 WordPress 密钥，输入键 (Key) WORDPRESS_DB_PASSWORD 和值 (Value) 123456。创建的密钥显示在列表中。

2、创建持久卷声明

1. 访问存储下的持久卷声明，点击创建。
2. 输入持久卷声明的基本信息（例如，将其命名为 wordpress-pvc），然后点击下一步。
3. 在存储设置中，需要选择一个可用的存储类，并设置访问模式和卷容量。您可以直接使用默认值，点击下一步继续。
4. 在高级设置中，您无需添加额外的配置，点击创建完成即可。

3、创建应用程序

添加 MySQL 后端组件和 WordPress 前端组件

1. 导航到应用负载下的应用，选择自制应用 > 创建。

2. 输入基本信息（例如，在应用名称一栏输入 wordpress），然后点击下一步。

3. 在服务设置中，点击创建服务以在应用中设置组件。

4. 设置组件的服务类型为有状态服务。

5. 输入有状态服务的名称（例如 mysql）并点击下一步。

6. 在容器组设置中，点击添加容器。

7. 在搜索框中输入 mysql:5.6，按下回车键，然后点击使用默认端口。由于配置还未设置完成，请不要点击右下角的 √ 按钮。

8. 向下滚动到环境变量，点击来自保密字典。输入名称 MYSQL_ROOT_PASSWORD，然后选择资源 mysql-secret 和前面步骤中创建的密钥 MYSQL_ROOT_PASSWORD，完成后点击 √ 保存配置，最后点击下一步继续。

9. 选择存储设置中的添加持久卷声明模板，输入 PVC 名称前缀 (mysql) 和挂载路径（模式：读写，路径：/var/lib/mysql）的值。

   完成后，点击 √ 保存设置并点击下一步继续。

10. 在高级设置中，可以直接点击创建，也可以按需选择其他选项。

11. 再次点击创建服务，选择无状态服务。输入名称 wordpress 并点击下一步。

12. 与上述步骤类似，点击添加容器，在搜索栏中输入 wordpress:4.8-apache 并按下回车键，然后点击使用默认端口。

13. 向下滚动到环境变量，点击来自保密字典。这里需要添加两个环境变量，请输入以下值：

    • 对于 WORDPRESS_DB_PASSWORD，请选择在步骤 1 中创建的 wordpress-secret 和 WORDPRESS_DB_PASSWORD。
    • 点击添加环境变量，分别输入 WORDPRESS_DB_HOST 和 mysql 作为键 (Key) 和值 (Value)。

    注意：对于此处添加的第二个环境变量，该值必须与步骤 5 中创建 MySQL 有状态服务设置的名称完全相同。否则，WordPress 将无法连接到 MySQL 对应的数据库。

    点击 √ 保存配置，再点击下一步继续。

14. 在存储设置中，点击挂载卷，并点击选择持久卷声明。

15. 选择上一步创建的 wordpress-pvc，将模式设置为读写，并输入挂载路径 /var/www/html。点击 √ 保存，再点击下一步继续。

16. 在高级设置中，可以直接点击创建创建服务，也可以按需选择其他选项。

17. 现在，前端组件也已设置完成。点击下一步继续。

18. 您可以在路由设置中设置路由规则（应用路由 Ingress），也可以直接点击创建。创建成功后，应用将显示在应用列表中。

4、验证资源

在工作负载中，分别检查部署和有状态副本集中 wordpress-v1 和 mysql-v1 的状态。如果它们的运行状态为运行中，就意味着 WordPress 已经成功创建。

5、通过 NodePort 访问 WordPress

1. 若要在集群外访问服务，选择左侧导航栏中的应用负载 > 服务。点击 wordpress 右侧的三个点后，选择编辑外部访问。

2. 在访问方式中选择 NodePort，然后点击确定。

3. 点击服务进入详情页，可以在端口处查看暴露的端口。

4. 通过 {Node IP}:{NodePort} 访问此应用程序，可以看到下图：

   在访问服务之前，请确保安全组中的端口已打开。

三、使用 KubeSphere 创建第一个应用

1、创建并访问 Nginx 服务

从“应用负载”的“服务”面板中，开始“创建”服务，并选择“无状态服务”

在“基本信息”中填写“名称”，“下一步” 👇

进入“容器镜像”设置环节，选择“添加容器镜像”

在“容器设置”中设置“镜像”为 nginx:1.17-alpine，并通过 “👉使用默认端口” 来设置容器的访问“端口”及其“协议”并确认 ☑️

返回到“容器镜像”设置，可查看到已配置完成了 nginx:1.17-alpine 的容器镜像，即可执行 “下一步” 👇

暂时不需要配置“挂载存储”，进入“高级设置”并配置“外网访问”为 NodePort，然后执行 “创建” 服务

🍮 服务访问的几种主要类型

• ClusterIP：默认类型，自动分配一个仅 Kubernetes 集群内部可以访问的虚拟 IP；
• NodePort：在 ClusterIP 基础上为服务在每台机器上绑定一个端口，这样就可以通过 <NodeIP>:NodePort 来访问该服务；
• LoadBalancer：在 NodePort 的基础上，借助云服务供应商创建一个外部的负载均衡器，并将请求转发到 <NodeIP>:NodePort。

进入到“工作负载”面板，当得到如上 👆****界面状态 my-nginx 运行中 (1/1) 即表示应用部署成功

返回到“服务”面板，可查看到 Nginx 服务到外网访问端口（⚠️注意该端口默认是随机产生的，但也可按规则指定）

进入服务“资源状态”，在右侧面板上也可以更清晰的看到“容器端口”-“服务端口”-“节点端口”（外网端口）的映射关系

🎯 在 Kubernetes 集群内通过服务名访问服务

• 完整的服务名格式是： <svc-name>.<ns-name>.svc.cluster.local，但通常不需要写完整；
• 对于相同 Namespace 下的服务访问可只保留 <svc-name> 部分，即直接使用 my-nginx；
• 对于不同 Namespace 访问服务需要至少保留 <svc-name>.<ns-name> 的部分，即使用 my-nginx.drillground。

从“应用负载”的“容器组”面板中，选择（进入）刚刚创建的 **my-nginx** 容器组

进入容器组后，在右侧“容器”面板中可以通过容器名右侧的两个图标分别查看“容器日志”和访问“终端”

在“终端”中是可以如同本地终端一样对容器内的系统进行操作的

3、定制启动命令和环境变量

从“应用负载”的“工作负载”面板中，选择（进入）刚刚创建的 **my-nginx** 工作负载

从左侧操作面板的“更多操作”中选择“编辑配置模版”

选择“容器组模版”，在右侧“容器镜像”面板选择 Nginx 所在容器通过最右侧的编辑按钮进入容器编辑

在“编辑容器”面板中，通过开启“启动命令”和“环境变量”面板可以对这两项内容进行编辑，编辑完成保存后将新更新部署

4、配置应用部署的更新策略

在使用 KubeSphere 创建各类部署时，默认推荐的更新策略便是“滚动更新”（另一项为“替换更新”），同时也支持随时进行策略的变更和配置。

“更新策略”的配置入口与“容器组模版”在同一层，如果选择“滚动更新”，可额外配置容器组更新时“最少存活的 Pod 数量”和“允许超出副本数的 Pod 数量”

🍮 滚动更新（Rolling Update）的两个配置项

• maxUnavailable：用来指定在升级过程中不可用 Pod 的最大数量。该值可以是一个正整数，或者是百分比（例如 10%，通过计算百分比的绝对值向下取整）

• • Max Surge 为 0 时，这个值不可以为 0。默认值是 1。
  • 上图中的 “容器组最小可用数量” 实际对应生成的数值为 25%，通过向下取整得到 0，故表示不能存在不可用的容器组（即最小存活 1 个容器组）

• maxSurge：用来指定可以超过期望的 Pod 数量的最大个数。该值可以是一个正整数，或者是百分比（例如 10%，通过百分比计算的绝对值向上取整）

• • Max Unavailable 为 0 时该值不可以为 0。默认值是 1。

在部署面板中，可以非常方便的增加或减少部署副本的数量，基于以上“滚动更新”的配置，会至少保证有“容器组最小可用数量”个存活的容器组在滚动更新的过程中工作以保障服务可用

每个应用部署已执行过的更新都可以被记录下来，并通过进入 “版本控制” 标签页选择进行相应的更新条目进行版本回退

5、为应用添加健康检查器

为了确保容器在部署后确实处在正常运行状态，Kubernetes 提供了三种探针（Probe）来探测容器的状态：

• Liveness Probe：探测应用是否处于健康状态，如果不健康则删除并重新创建容器

• Readiness Probe：探测应用是否启动完成并且处于正常服务状态，如果不正常则不会接收来自 Kubernetes Service 的流量（即将该 Pod 从 Service 的 Endpoint 中移除）

• Startup Probe：探测应用是否启动完成，如果设定了此探针，则前两项探针只有在启动探测成功后才生效；且成功后，即刻转由 Liveness Probe 接替健康状态探测

• • 启动探针主要适用的场景：应用启动时间非常长，但启动后的健康检测间隔不长（常见于冷启动、自带大量数据需初始化的业务服务场景）

🍮 探针（Probe）的三种执行方式

• exec：在容器中执行一个命令，如果 命令退出码 返回 0 则表示探测成功，否则表示失败
• tcpSocket：对指定的容器 IP 及端口执行一个 TCP 检查，如果端口是开放的则表示探测成功，否则表示失败
• httpGet：对指定的容器 IP、端口及路径执行一个 HTTP 的 GET 请求，如果返回的 状态码 在 [200,400) 之间则表示探测成功，否则表示失败

参考 定制启动命令和环境变量 部分的操作进入“编辑容器”面板，打开“健康检查器”配置

5.1 配置并使用“存活”探测器

此处选用“TCP 端口检查”的方式作为“存活探测器”的探针形态，并绑定探测的端口为 80，其它皆使用默认配置并确认 ☑️

保存配置后，容器组会执行滚动更新以使“存活探测器”生效

通过进入“终端”修改 Nginx 监听的端口使 **80** 端口不生效，“存活探测器”会基于“不健康阈值”配置在 3 次探测失败后重启容器组，该过程可以在容器组“事件”标签页中观察到

5.2 配置并使用“就绪”探测器

类似地，选择“HTTP 请求检查”的方式作为“容器就绪检查”的探针形态，绑定 **GET :80/** 作为探针入口，且设置“初始延迟”为 10 秒（服务就绪通常需要更多时间）

保存配置后，容器组仍然会执行滚动更新以使“就绪探测器”生效

配置了基于“HTTP 请求检查”后可以在“容器日志”里面很清楚的看到探针的请求正在按检测配置执行

通过进入“终端”修改 Nginx 使 **80** 端口直接返回 **404**，“就绪探测器”会基于“不健康阈值”配置在 3 次探测失败后把容器组标记为不健康，该过程可以在容器组“事件”标签页中观察到

**在部署面板中，也可以看到容器组被“就绪探测器”被标记为“容器没有准备就绪”（**⚠️ 就绪检测是吧是不会导致容器组重启的）

四、使用 KubeSphere 配置应用资源及存储

从“应用负载”面板中，选择 my-nginx 工作负载。

1、容器分配 CPU 和内存资源

1.1 配置容器的资源预留及配额

Kubernetes 通过 cgroups 限制容器的 CPU 和内存等计算资源，包括 requests（请求，调度器保证调度到资源充足的 Node 上，如果无法满足会调度失败）和 limits（上限）等。

同“滚动更新”的配置类似，通过 KubeSphere 部署的容器组默认是可以自带 CPU 和内存资源配置的，这是怎么做到的呢？其实原理也很简单，在 KubeSphere 中创建项目（即 Kubernetes Namespace）时可以配置“容器资源默认请求”的配合，如下图所见即为 drillground 项目的配置情况，而次配置将被作为默认值由项目中的容器组继承。

🍮 CPU 和内存资源配置的单位

• CPU 的单位是 CPU 个数，可以用 millicpu (m) 表示少于 1 个 CPU 的情况，如 500m = 500millicpu = 0.5cpu，而一个 CPU 相当于：

• • AWS 上的一个 vCPU
  • GCP 上的一个 Core
  • Azure 上的一个 vCore
  • 物理机上开启超线程时的一个超线程

• 内存的单位则包括 E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki 等。

如果需要对容器进行定制化的资源配置，可以回到工作负载内的“编辑配置模版”界面，进入 nginx 容器的配置界面。

在“编辑容器”面板，打开“容器设置”中的“高级设置”，即可对容器的 CPU 和内存的资源预留和限制进行滑动或手动配置

⚠️ 如果 CPU 或内存超出配置的限制会发生什么？

• CPU 上限，可以短暂超过，容器也不会被停止；
• 内存上限，不可以超过；如果超过，容器可能会被终止或调度到其他资源充足的机器上。

1.2 基于资源配置形成的 QoS 等级说明

Kubernetes 为每个节点分配了可用资源，那么每个容器组（Pod）的级别是相同的吗？答案是否定的，Kubernetes 为 Pod 会分配不同级别的角色，像一个国王会分一等公民、二等公民、自由人，如果发生饥荒，比如资源短缺，Kubernetes 会先把资源分配给最优先的公民，保证它可用。Kubernetes 中 Pod 的级别具体划分为：Guaranteed、Burstable、BestEffort 三种。

• Guaranteed（一等公民）：这类 Pod 是有保证的，也是最优先的，在资源不足的情况下，Kubernetes 优先保证 **Guaranteed** 级别****的 Pod，驱逐低优先级别的 Pod。

• • Pod 中的每个容器必须指定内存请求和内存限制，并且两者要相等。
  • Pod 中的每个容器必须指定 CPU 请求和 CPU 限制，并且两者要相等。

• Burstable（二等公民）：这类 Pod 可能是比较常见的，它的级别高于 BestEffort 但低于 Guaranteed。它尽量的节省资源同时也保证在资源不足的时候可以优先存活。

• • Pod 不符合 Guaranteed QoS 类的标准；
  • Pod 中至少一个容器具有内存或 CPU 请求。

• BestEffort（自由民）：这类 Pod 是级别最低的，它的定义是不对内存或者 CPU 做任何限制，在资源充足的情况下尽可能的使用资源，如果在资源不足的情况下，这类 Pod 会优先被驱逐，保证其他高级别的 Pod 存活。

1.3 根据 CPU 和内存使用情况水平伸缩副本

除了配置容器的资源请求和限制量，Kubernetes 还支持根据容器组 CPU 和内存的实际使用情况自动伸缩一个工作负载的副本数量，其在 KubeSphere 中的配置也非常方便。

在 my-nginx 部署的“更多操作”中选择“弹性伸缩”即可进入容器组水平伸缩参数配置窗口****👇

🍮 Kubernetes Autoscaling 的几种类型

• Horizontal Pod Autoscaler（HPA）

• • HPA 会在集群中缩放 Pod 副本的数量。该操作由 CPU 或内存触发，以根据需要向上或向下扩展。
  • 但是，也可以根据各种外部的和自定义指标（metrics.k8s.io，external.metrics.k8s.io 和 custom.metrics.k8s.io）来配置 HPA 以扩展 Pod。

• Vertical Pod Autoscaler（VPA）

• • VPA 主要用于有状态服务，它可根据需要为 Pod 添加 CPU 或内存 — 它也适用于无状态的 Pod。
  • 为了应用这些更改，VPA 重新启动 Pod 以更新新的 CPU 和内存资源，这些资源可以配置为响应 OOM（内存不足）事件而启动。重新启动 Pod 的时候，VPA 始终确保根据 Pod 分配预算（PDB）确定最小数量，可以设置该资源分配最大和最小速率。

• Cluster Autoscaler（CA）

• • 第二层的自动缩放涉及 CA，它在以下情况下自动调整集群的大小：
• • • 由于集群中的容量不足，任何 Pod/s 都无法运行并进入挂起状态（在这种情况下，CA 将向上扩展）。
    • 集群中的节点在一段时间内未得到充分利用，并且有可能迁移节点上的 Pod（在这种情况下，CA 将缩小）。
• • CA 进行例行检查以确定是否有任何 Pod 因等待额外资源处于待定状态，或者集群节点是否未得到充分利用。如果需要更多资源，会相应地调整 Cluster 节点的数量。
  • CA 与云提供商交互以请求其他节点或关闭空闲节点，并确保按比例放大的集群保持在用户设置的限制范围内。它适用于 AWS，Azure 和 GCP。

2、为容器组配置持久化数据

2.1 将配置文件挂载至指定目录

应用程序的运行可能会依赖一些配置，而这些配置又是可能会随着需求产生变化的，如果我们的应用程序架构不是应用和配置分离的，那么就会存在当我们需要去修改某些配置项的属性时需要重新构建镜像文件的窘境。现在，ConfigMap组件可以很好的帮助我们实现应用和配置分离，避免因为修改配置项而重新构建镜像。

ConfigMap 用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。在 KubeSphere 中创建、管理和挂载 ConfigMap 都是非常便捷的。

返回项目面板，通过左侧的“配置中心”中的“配置”，可以进入配置集面板执行“创建配置”

创建一个名为 nginx-conf 的配置集，添加一个 default.conf 的键并填写如上内容，用于覆盖现有的 Nginx 默认配置文件

完成创建后，可以在配置面板看到已经创建的 nginx-conf 配置集，及其所含的一个配置项 default.conf

接下来返回 my-nginx 的部署面板，再次进入“编辑配置模版”，这次需要进入左侧“存储卷”标签页，选择“挂载配置文件或密钥”，开始绑定前面创建的配置集

⚠️ 注意这里配置需要这容器路径这边一定需要“点击添加子路径”，否则无法将配置项作为文件挂载！

完成如上配置并保存，即可实现：将 default.conf 配置项的内容作为文件挂载到 /etc/nginx/conf.d/default.conf （即覆盖原配置文件）

完成如上所有操作后，会触发容器组的滚动更新，更新成功后重新访问 Nginx（本部署的访问地址为 10.0.162.5:31917），即可发现页面会自动跳转到指定页面。🎉

2.2 添加并挂载持久化存储卷

我们知道默认情况下容器的数据都是非持久化的，在容器消亡以后数据也跟着丢失，所以 Docker 提供了 Volume 机制以便将数据持久化存储。类似的，Kubernetes 提供了更强大的 Volume 机制和丰富的插件，解决了容器数据持久化和容器间共享数据的问题。

与 Docker 不同，Kubernetes Volume 的生命周期与 Pod 绑定：

• 容器挂掉后 Kubelet 再次重启容器时，Volume 的数据依然还在；

• 而 Pod 删除时，Volume 才会清理。数据是否丢失取决于具体的 Volume 类型，比如 emptyDir（临时存储）的数据会丢失，而 PersistentVolume（持久化存储）则不会丢。

• • 持久化存储有时也用于容器内的日志落盘，默认容器的 stdout 和 stderr 输出的日志在 Node 节点落盘并会自动循环，默认大小只有 10 M 空间。

在 KubeSphere 中配置使用临时或持久化存储的方式也是很直接的，下面给出一个示例介绍创建并挂载一个 Ceph 块存储的过程。

返回项目面板，从左侧面板的“存储卷”进入，开始“创建存储卷”

创建一个名为 nginx-pv 的存储卷，然后完成如图的配置后，“下一步”跳过高级设置，直接“创建”存储卷

创建完成后等待存储卷进入“准备就绪”状态即可开始后续挂载操作

再次进入 my-nginx 的“编辑配置模版“，选择“添加存储卷”

如上图所示，选取先前创建的 nginx-pv 持久化存储卷，并将它绑定到 Nginx 容器的 /var/www 目录节点上，而后保存配置

确认配置后，容器组会再次滚动更新，更新完成后可以得到类似如上图的“容器组”和“存储设备”视图

**

[外链图片转存中…(img-x3HWr1uW-1734080427063)]

创建一个名为 nginx-pv 的存储卷，然后完成如图的配置后，“下一步”跳过高级设置，直接“创建”存储卷

[外链图片转存中…(img-G1QS25AF-1734080427063)]

创建完成后等待存储卷进入“准备就绪”状态即可开始后续挂载操作

[外链图片转存中…(img-6KIoYYGz-1734080427063)]

再次进入 my-nginx 的“编辑配置模版“，选择“添加存储卷”

[外链图片转存中…(img-FLiN2qSj-1734080427063)]

如上图所示，选取先前创建的 nginx-pv 持久化存储卷，并将它绑定到 Nginx 容器的 /var/www 目录节点上，而后保存配置

[外链图片转存中…(img-FlzV8v2H-1734080427063)]

确认配置后，容器组会再次滚动更新，更新完成后可以得到类似如上图的“容器组”和“存储设备”视图

现在 1 GB 的持久化存储已经绑定到了 Nginx 容器到 /var/www 目录下，可以通过终端进入目录任何写入内容后，重新部署容器组以验证写入的内容是否仍然存在。👀