K8s 实战：通过 YAML 创建 Pod 并验证

一、通过 YAML 创建 Pod 的完整流程

1. 编写 YAML 配置文件

首先创建 nginx-demo.yaml 配置文件（定义 Pod 的“期望状态”）：

# 创建并编辑 YAML 文件（vim 或其他编辑器均可）
chenaws@k8smaster:~/work/pods$ vim nginx-demo.yaml

YAML 配置：

apiVersion: v1  # API 版本（Pod 属于核心资源，用 v1）
kind: Pod       # 资源类型：这里直接创建 Pod（而非通过 Deployment 管理）
metadata:       # Pod 的元数据（标识信息）
  name: nginx-demo  # Pod 名称（唯一标识）
  labels:           # 自定义标签（用于分类或后续关联 Service）
    type: app       # 标签1：类型为应用
    test: 1.0.0     # 标签2：版本为1.0.0
  namespace: 'default'  # 所属命名空间（默认在 default）
spec:           # Pod 的核心配置（定义容器如何运行）
  containers:   # 容器列表（一个 Pod 可包含多个容器，这里只定义一个）
  - name: nginx  # 容器名称（Pod 内唯一）
    image: nginx:1.7.9  # 容器镜像（指定版本 1.7.9，避免默认拉取最新版）
    imagePullPolicy: IfNotPresent  # 镜像拉取策略：本地有则用本地，无则拉取
    command:  # 容器启动命令（覆盖镜像默认启动命令）
    - nginx
    - -g
    - 'daemon off;'  # 完整命令：nginx -g 'daemon off;'（让 nginx 在前台运行，避免容器退出）
    workingDir: /usr/share/nginx/html  # 容器工作目录（启动后进入该目录）
    ports:  # 容器端口配置（声明要暴露的端口）
    - name: http  # 端口名称（自定义，方便识别）
      containerPort: 80  # 容器内暴露的端口（nginx 默认监听 80 端口）
      protocol: TCP  # 协议类型（TCP/UDP，默认 TCP）
    env:  # 环境变量（传给容器内的应用）
    - name: JVM_OPTS  # 环境变量名称
      value: '-Xms128m -Xmx128m'  # 变量值（这里模拟 JVM 配置，实际 nginx 用不到，仅作示例）
    resources:  # 资源限制（避免容器占用过多资源）
      requests:  # 最小资源需求（调度时确保节点有足够资源）
        cpu: 100m  # 100 毫核（0.1 个 CPU 核心）
        memory: 128Mi  # 128 兆内存
      limits:  # 最大资源限制（超过会被限流或杀死）
        cpu: 200m  # 最多 0.2 个 CPU 核心
        memory: 256Mi  # 最多 256 兆内存
  restartPolicy: OnFailure  # 重启策略：仅当容器“失败退出”时才重启（正常退出不重启）

2. 执行创建命令

通过 kubectl create -f 命令应用 YAML 配置，创建 Pod：

# 语法：kubectl create -f <YAML文件路径>（根据配置文件创建资源）
chenaws@k8smaster:~/work/pods$ kubectl create -f nginx-demo.yaml 
pod/nginx-demo created  # 输出表示 Pod 创建命令已生效

命令作用：
kubectl create -f 是 K8s 读取配置文件并创建资源的核心命令。K8s 会解析 nginx-demo.yaml 中的配置，按 spec 定义的规则创建 Pod。

3. 观察 Pod 创建过程

Pod 创建后不会立即就绪（需要拉取镜像、启动容器），通过 kubectl get po 持续观察状态：

# 第一次查看：Pod 处于 ContainerCreating 状态（正在创建容器）
chenaws@k8smaster:~/work/pods$ kubectl get po
NAME               READY   STATUS              RESTARTS      AGE
nginx-demo         0/1     ContainerCreating   0             13s  # 0/1 表示容器未就绪

# 一段时间后查看：Pod 变为 Running 状态（容器已启动）
chenaws@k8smaster:~/work/pods$ kubectl get po
NAME               READY   STATUS    RESTARTS      AGE
nginx-demo         1/1     Running   0             63s  # 1/1 表示容器已就绪

状态含义：

  • ContainerCreating：K8s 正在创建 Pod 相关资源（如网络配置、拉取镜像）。
  • Running：Pod 内所有容器已启动并正常运行（1/1 表示“期望 1 个容器，已就绪 1 个”）。

4. 查看 Pod 详细信息（排查问题/验证配置）

通过 kubectl describe po 查看 Pod 的详细日志，确认配置是否生效：

# 语法：kubectl describe po <Pod名称>（查看 Pod 详细信息和事件）
chenaws@k8smaster:~/work/pods$ kubectl describe po nginx-demo

关键输出解读（对应 YAML 配置的验证）：

# 1. 基本信息（与 YAML 配置一致）
Name:         nginx-demo
Namespace:    default
Labels:       test=1.0.0  # YAML 中定义的标签
              type=app

# 2. 容器配置（验证 YAML 中的容器参数）
Containers:
  nginx:
    Image:         nginx:1.7.9  # 正确使用 YAML 中指定的镜像版本
    Command:       nginx -g daemon off;  # 正确执行 YAML 中的启动命令
    Ports:         80/TCP  # 正确暴露 80 端口
    Environment:   JVM_OPTS=-Xms128m -Xmx128m  # 正确设置环境变量
    Limits:        cpu=200m, memory=256Mi  # 正确应用资源限制
    Requests:      cpu=100m, memory=128Mi  # 正确应用资源需求

# 3. 事件日志（查看创建过程）
Events:
  Normal  Scheduled  55s   default-scheduler  成功调度到 k8snode2 节点
  Normal  Pulling    55s   kubelet            开始拉取 nginx:1.7.9 镜像
  Normal  Pulled     23s   kubelet            镜像拉取成功（耗时 31 秒）
  Normal  Created    23s   kubelet            容器创建成功
  Normal  Started    23s   kubelet            容器启动成功

作用：通过 describe 可以验证 YAML 中的配置是否被正确应用（如镜像版本、端口、环境变量等），若 Pod 异常，也能从 Events 中找到原因（如镜像拉取失败、资源不足等）。

5. 验证 Pod 网络连通性

Pod 创建成功后，需确认其能正常提供服务。通过 Pod 的 IP 直接访问（Pod 内部 IP 在集群内可直接访问）：

# 1. 查看 Pod 的 IP（通过 -o wide 显示详细信息）
chenaws@k8smaster:~/work/pods$ kubectl get po -o wide
NAME               READY   STATUS    IP            NODE       AGE
nginx-demo         1/1     Running   10.244.2.19   k8snode2   2m9s  # IP 为 10.244.2.19

# 2. 通过 IP 访问 nginx 服务（集群内任意节点均可访问）
chenaws@k8smaster:~/work/pods$ curl 10.244.2.19
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...  # 输出 nginx 欢迎页 HTML 内容，说明服务正常

为什么能访问？
通过 route -n 查看集群路由表可知，K8s 已通过网络插件（如 Flannel）配置了跨节点路由：

chenaws@k8smaster:~/work/pods$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.244.2.0      10.244.2.0      255.255.255.0   UG    0      0        0 flannel.1  # 10.244.2.0 网段通过 flannel.1 设备路由

10.244.2.19 属于 10.244.2.0 网段，master 节点通过 Flannel 网络插件的路由配置，可直接访问 k8snode2 节点上的 Pod。

二、核心命令与配置总结

1. 关键操作命令及作用

命令 作用 初学者记忆点
vim nginx-demo.yaml 编写 Pod 配置文件 YAML 是“定义期望状态”的载体
kubectl create -f nginx-demo.yaml 根据 YAML 创建 Pod “-f”表示“从文件读取配置”
kubectl get po 查看 Pod 状态 快速确认 Pod 是否运行（关注 STATUS 列）
kubectl get po -o wide 查看 Pod 详细信息（含 IP、节点） 获取 Pod 的 IP 用于访问服务
kubectl describe po nginx-demo 查看 Pod 详细日志和配置 排查问题的核心命令（重点看 Events）
curl <Pod IP> 验证服务是否正常 确认应用在 Pod 内正常运行

2. YAML 核心配置与作用（初学者必记）

配置项 作用 举例
image: nginx:1.7.9 指定容器镜像及版本 避免使用 latest（版本不固定），建议指定具体版本
imagePullPolicy: IfNotPresent 本地有镜像时直接使用，减少网络依赖 比 Always（每次拉取）更高效
resources.requests/limits 限制容器的资源使用 防止单个 Pod 占用过多资源，影响其他服务
ports.containerPort: 80 声明容器暴露的端口 仅用于“说明”，不直接对外暴露（需配合 Service）
restartPolicy: OnFailure 定义容器重启规则 避免正常退出的容器被反复重启

3. Pod 创建流程核心逻辑

  1. 定义期望：通过 YAML 告诉 K8s“要一个运行 nginx:1.7.9、带特定标签的 Pod”。
  2. 自动执行：K8s 接收配置后，自动完成调度（分配到 k8snode2）、拉取镜像、启动容器。
  3. 验证结果：通过 kubectl get po 和 curl 确认 Pod 运行正常、服务可用。

三、常见问题解答

  1. 为什么 YAML 中要写 command: nginx -g 'daemon off;'？
    因为 nginx 镜像默认以“后台模式”运行（启动后进程退出），容器会因“主进程退出”而终止。daemon off; 让 nginx 以“前台模式”运行，确保容器持续运行。

  2. requests 和 limits 有什么用？

    • requests：告诉调度器“这个 Pod 至少需要这么多资源”，调度器只会把它分配到资源充足的节点。
    • limits：限制容器最多使用的资源，避免占用过多资源导致其他服务崩溃。

  3. 为什么 kubectl get po 显示 0/1 状态？
    表示容器正在创建中（拉取镜像、启动），耐心等待即可。若长时间不变，用 kubectl describe po <名称> 查看 Events，通常是镜像拉取失败或资源不足。

# kubernetes # nginx # 容器 # java # golang
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

OpenAI连续17天宕机，重度用户如何低成本搭建稳定的AI备用方案？

就在昨天（7月25日），OpenAI的服务又双叒叕崩了。这次可不是简单的网页打不开，而是API、ChatGPT、Codex三线齐崩，足足有31个服务组件性能下降，全球超过1500名用户在社区里哀嚎。从北京时间下午5点多开始，一直到晚上7点多才恢复，硬生生断了将近两个小时。更让人心塞的是，这已经是7月9日以来，OpenAI连续第17天出现服务异常了。期间还有两次彻底宕机（Major Outage），

avatar AI编程社区
cover

Cursor安全插件链：代码审计新范式

avatar AI编程社区

BBWEYY机械制造行业独立站建设策划案，含零代码SAAS、AI编程、源码定制交付

建议先以BBWEYY完成首期标准化建设和市场验证，再根据真实流量、客户反馈和业务复杂度升级内容、视觉与系统集成。企业需要在上线速度、品牌表达、支付履约、营销增长和数据自主之间形成平衡。BBWEYY以AI＋SaaS＋GEO为核心，强调低成本、零抽成、多语言、跨境支付、数据开放和中文服务，可作为项目的标准化经营底座。配置参数、图纸、认证、FAQ和资料下载。目标市场、用户、内容、支付与数据需求确认。功能

avatar AI编程社区