企业官网建设流程全解析

一、实验背景

以YAML 创建 Nginx Pod为例子

在 Kubernetes 学习过程中，如果只是通过kubectl create deployment等命令创建应用，很容易停留在“会使用命令”的阶段，却不一定真正理解 Kubernetes 是如何管理应用的。

因此，本次实验从 YAML 配置文件出发，在一台安装了 K3s 的 Ubuntu 服务器上部署 Nginx，依次验证以下核心机制：

• Pod 的创建与生命周期
• Deployment、ReplicaSet 与 Pod 之间的管理关系
• ReplicaSet 如何维持期望副本数量
• Service 如何通过标签选择后端 Pod
• EndpointSlice 如何反映后端地址变化
• Pod 被替换后，Service 如何继续提供稳定的访问入口

本次实验使用独立命名空间nginx-yaml-lab，避免与服务器上已有的应用资源混淆。

二、实验环境

创建实验命名空间：

kubectl create namespace nginx-yaml-lab

验证命名空间：

kubectl get namespace nginx-yaml-lab

通过命名空间隔离实验资源，可以降低误操作影响其他工作负载的风险。

三、直接使用 YAML 创建 Pod

3.1 编写 Pod 配置

创建文件nginx-pod.yaml：

apiVersion:v1kind:Podmetadata:name:nginx-podnamespace:nginx-yaml-lablabels:app:nginxspec:containers:-name:nginximage:m.daocloud.io/docker.io/library/nginx:stableports:-containerPort:80

这里有几个重要字段：

• apiVersion: v1：指定 Pod 使用的 Kubernetes API 版本。
• kind: Pod：声明要创建的资源类型。
• metadata：定义资源名称、命名空间和标签。
• spec.containers：声明容器名称、镜像和端口。
• containerPort: 80：描述容器使用的端口，并不会自动将宿主机的 80 端口映射给容器。

3.2 创建并检查 Pod

执行：

kubectl apply-fnginx-pod.yaml

查询运行状态：

kubectl get pod nginx-pod-nnginx-yaml-lab-owide

实验结果：

NAME READY STATUS RESTARTS AGE IP nginx-pod 1/1 Running 0 ... 10.42.0.191

Pod 成功运行，容器就绪状态为1/1。

但是，Running并不等同于应用一定能正常处理请求，因此还需要验证实际的 HTTP 响应。

3.3 验证 Nginx 服务

执行：

kubectlexec-nnginx-yaml-lab nginx-pod --\curl-I--max-time5http://127.0.0.1/

返回：

HTTP/1.1 200 OK Server: nginx/1.30.5 Content-Type: text/html

这证明 Nginx 已经能够正常响应 HTTP 请求。

需要注意，此时访问的是容器内部的127.0.0.1，还没有验证其他 Pod 是否可以通过网络访问该应用。

3.4 为什么直接创建的 Pod 不会自动恢复？

通过以下命令检查 Pod 的上级所有者引用：

kubectl get pod nginx-pod\-nnginx-yaml-lab\-ojsonpath='{.metadata.ownerReferences}{"\n"}'

实验中输出为空。

这表明该 Pod 没有声明所属的 Kubernetes 上级对象，例如 ReplicaSet。

如果直接创建的 Pod 被删除，Kubernetes 不会因为本地 YAML 文件还存在，就自动重新创建它。YAML 文件只是配置文件，并不是一个持续运行的控制器。

因此，直接创建 Pod 适合学习基础资源和进行简单测试，但不适合单独承担需要自动恢复的生产应用。

四、使用 Deployment 管理 Pod 副本

4.1 编写 Deployment YAML

创建nginx-deployment.yaml：

apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentnamespace:nginx-yaml-labspec:replicas:2selector:matchLabels:app:nginx-deploymenttemplate:metadata:labels:app:nginx-deploymentspec:containers:-name:nginximage:m.daocloud.io/docker.io/library/nginx:stableports:-containerPort:80

与直接创建 Pod 相比，这份 YAML 增加了几个关键配置。

replicas: 2

声明期望运行两个 Pod 副本。它描述的是期望状态，而不是保证任意时刻都绝对有两个可用 Pod。

selector.matchLabels

指定 Deployment 用什么标签识别其管理的 Pod 副本集合。

template

定义新 Pod 的模板，包括标签、容器镜像、端口等信息。

其中，selector.matchLabels必须与template.metadata.labels匹配，否则 Deployment 无法按照预期识别自己的副本。

4.2 创建 Deployment 并查看资源关系

先验证配置：

kubectl apply --dry-run=server-fnginx-deployment.yaml

服务端试运行通过后，再正式创建：

kubectl apply-fnginx-deployment.yaml

查询 Deployment、ReplicaSet 和 Pod：

kubectl get deployment,replicaset,pod-nnginx-yaml-lab

实验中观察到的资源关系如下：

Deployment └── ReplicaSet ├── Pod └── Pod

Deployment 的状态为2/2，ReplicaSet 的期望副本数为 2，两个 Pod 均为Running。

此时，实验命名空间中还保留着之前直接创建的nginx-pod，所以一共有三个 Pod：一个独立 Pod，以及两个由 Deployment 管理的 Pod。

这说明 Kubernetes 并不会因为两个 Pod 使用了相似的 Nginx 镜像，就自动将它们归为同一个应用。资源的管理关系取决于控制器、标签和所有者引用等信息。

4.3 Deployment 和 ReplicaSet 的职责

Deployment 与 ReplicaSet 并不是重复的两层资源，它们承担不同职责。

• Deployment：管理应用发布过程，包括滚动更新、版本回滚，以及对 ReplicaSet 的管理。
• ReplicaSet：维持符合条件的 Pod 副本数量，使实际状态尽量符合期望状态。
• Pod：承载实际运行的容器。

当 Deployment 声明replicas: 2时，ReplicaSet 会持续观察实际副本数量。如果发现副本不足，就尝试创建新的 Pod；如果副本过多，就尝试缩减副本数量。

这一过程体现了 Kubernetes 的声明式管理思想：用户声明期望状态，控制器持续观察实际状态并尝试协调两者之间的差异。

五、通过删除实验验证 Pod 自愈

理论理解之后，通过实际操作验证控制器的行为。

5.1 记录删除前的 Pod

使用标签选择器查询 Deployment 管理的副本：

kubectl get pods\-nnginx-yaml-lab\-lapp=nginx-deployment-owide

实验中，两个 Pod 的 IP 分别为：

10.42.0.192 10.42.0.193

两个 Pod 都处于Running状态。

5.2 删除一个 Pod

执行：

kubectl delete pod\nginx-deployment-784659cff6-cfgxd\-nnginx-yaml-lab

然后再次查询：

kubectl get pods\-nnginx-yaml-lab\-lapp=nginx-deployment-owide

实验结果显示，原 Pod 被删除后，Kubernetes 创建了一个新 Pod：

原 Pod IP：10.42.0.192 新 Pod IP：10.42.0.194

副本数量恢复为两个，另一个 Pod 保持运行。

这证明 ReplicaSet 会尝试维持期望副本数量。它并不是恢复原来的 Pod 对象，而是根据 Pod 模板创建一个新的 Pod。

5.3 Pod 自愈的准确含义

这里所说的“自愈”，并不意味着 Kubernetes 能够修复原 Pod 内部的所有故障。

更准确地说：

• ReplicaSet 发现 Pod 副本数量不足时，可以创建新的 Pod。
• 如果容器进程退出，Kubelet 可能根据 Pod 的重启策略重新启动容器。
• 如果节点发生故障，工作负载能否恢复以及恢复需要多久，还取决于节点状态检测、调度条件、存储、网络和其他因素。

因此，Pod 重建、容器重启和节点故障恢复是不同层次的机制，不能简单地视为同一种行为。

六、使用 Service 提供稳定的访问入口

6.1 为什么不能依赖 Pod IP？

在前面的实验中，Pod 被删除后，新 Pod 获得了不同的 IP。

如果客户端把某个 Pod 的 IP 直接写入配置，那么 Pod 替换后，客户端可能仍然访问旧地址，需要额外修改配置。

对于多个副本的应用，更合理的方式是提供统一的访问入口，让客户端不必关心具体请求最终到达哪个后端。

这就是 Service 的主要作用之一。

6.2 编写 Service YAML

创建nginx-service.yaml：

apiVersion:v1kind:Servicemetadata:name:nginx-servicenamespace:nginx-yaml-labspec:type:ClusterIPselector:app:nginx-deploymentports:-port:80targetPort:80

几个核心字段的含义如下：

port和targetPort并不一定相同。例如，Service 可以对外提供 8080 端口，再将流量转发到容器的 80 端口。

6.3 创建 Service

执行：

kubectl apply-fnginx-service.yaml

查询 Service：

kubectl getservicenginx-service-nnginx-yaml-lab

实验中获得的 ClusterIP 为：

10.43.131.88

这个地址是 Service 的集群内部虚拟 IP，不是某个 Nginx 容器的 IP。

创建 Service 后，还需要确认它是否成功发现了后端 Pod。

6.4 使用 EndpointSlice 验证后端

执行：

kubectl get endpointslice\-nnginx-yaml-lab\-lkubernetes.io/service-name=nginx-service

实验中观察到：

ADDRESSTYPE PORTS ENDPOINTS IPv4 80 10.42.0.194,10.42.0.193

这说明 Service 对应的 EndpointSlice 已经记录了两个后端地址。

其工作关系可以概括为：

1. Service 的 selector 匹配 Pod 标签。
2. EndpointSlice 记录对应的后端端点。
3. 集群网络组件根据 Service 规则转发流量。

需要注意，EndpointSlice 不负责转发请求，它主要用于记录端点信息；实际流量转发由 Kubernetes 的网络实现完成。

七、验证 Service 的访问能力

7.1 从集群内部访问 ClusterIP

使用之前直接创建的独立 Pod 作为客户端，执行：

kubectlexec-nnginx-yaml-lab nginx-pod --\curl-I--max-time5http://10.43.131.88/

实验结果：

HTTP/1.1 200 OK Server: nginx/1.30.5 Content-Type: text/html

这证明客户端 Pod 能够通过 Service 的 ClusterIP 访问 Nginx。

与之前直接访问127.0.0.1不同，这次请求经过了 Service 的访问路径，验证了集群内服务访问能力。

7.2 删除后端 Pod，再观察 EndpointSlice

为了进一步验证服务发现机制，删除一个由 Deployment 管理的 Pod：

kubectl delete pod\nginx-deployment-784659cff6-6c7fx\-nnginx-yaml-lab

重新查看 EndpointSlice：

kubectl get endpointslice\-nnginx-yaml-lab\-lkubernetes.io/service-name=nginx-service

实验结果中，后端地址从：

10.42.0.193 10.42.0.194

更新为：

10.42.0.193 10.42.0.195

与此同时，查询 Pod 发现，新的 Pod 已经创建并运行，副本数量仍然是两个。

这一过程验证了两个不同但相互配合的机制：

• ReplicaSet 负责补足 Pod 副本。
• EndpointSlice 控制器根据符合条件的 Pod 状态更新端点信息。

因此，Service 不需要把某个固定 Pod 的 IP 写入 YAML。后端 Pod 被替换后，符合选择条件的新 Pod 可以被纳入服务的后端端点集合。

八、总结：这次实验真正理解了什么？

通过从 YAML 创建 Pod、Deployment 和 Service，并实际删除 Pod 观察资源变化，可以总结出以下几点。

第一，Kubernetes 使用声明式配置管理资源。

YAML 描述期望状态，Kubernetes 根据配置创建资源并持续协调实际状态。配置文件本身不会自动执行，资源的持续管理依赖控制器等组件。

第二，Pod 不是应用高可用的全部。

直接创建的 Pod 不会因为被删除就自动重建。Deployment 通过管理 ReplicaSet，间接实现应用副本管理与发布能力。

第三，副本自愈与应用健康检查不是同一回事。

ReplicaSet 主要维持副本数量。容器重启、Readiness Probe、Liveness Probe 和节点故障恢复分别解决不同层次的问题。

第四，Service 解耦了客户端和 Pod。

客户端使用稳定的 Service 地址，不需要追踪每个 Pod 的动态 IP。Service 通过标签选择后端，EndpointSlice 反映当前端点信息，网络组件负责实际转发。

第五，Kubernetes 的核心是控制器持续协调期望状态和实际状态。

理解这一点，比记住某一条kubectl命令更重要。它也是后续学习扩缩容、滚动更新、回滚、健康检查和故障排查的基础。

九、后续学习方向

完成本次实验后，可以继续学习：

1. NodePort 与外部访问：理解集群外部客户端如何访问应用，以及端口规划和网络边界。
2. Readiness Probe 与 Liveness Probe：理解如何判断应用是否可以接收流量，以及何时需要重启容器。
3. Deployment 滚动更新与回滚：观察镜像或 Pod 模板变化如何创建新的 ReplicaSet。
4. 资源限制与调度：学习 requests、limits、节点资源和 Pod 调度之间的关系。
5. 结合 CI/CD 实践：将构建出的应用镜像部署到 Kubernetes，进一步串联 Jenkins、镜像仓库、发布和回滚流程。

从实际运维角度看，理解这些机制不仅能帮助我们编写 Kubernetes YAML，也能在应用不可访问、Pod 不断重建或服务后端异常时，沿着资源状态和控制器关系逐层定位问题。