Linux下K8s应用部署全攻略

本文深入解析了在Linux环境下部署Kubernetes应用的两种核心方式：命令行快速测试与YAML声明式生产部署，指出`kubectl create deployment`虽能一键启动Pod（如`nginx-demo`），但缺乏端口暴露、健康检查、配置管理及弹性扩缩能力，仅适用于临时验证；而真正可控、可维护、可复现的生产环境必须依赖结构严谨的YAML文件，涵盖apiVersion、标签匹配规则、副本策略、容器镜像、端口定义等关键字段，并需配合独立创建的Service实现外部访问，同时详解了NodePort配置要点、滚动更新（`kubectl set image`）与安全回滚（`kubectl rollout undo`）的最佳实践，强调YAML是K8s“声明式运维”的基石——唯有它能让控制器持续调谐、保障应用生命周期稳定可靠。

怎么用 kubectl create deployment 快速起一个 Pod

直接跑起来最简单，但默认不暴露端口、没健康检查、副本数写死在命令里——适合临时测试，不适合生产。

• 基础命令：kubectl create deployment nginx-demo --image=nginx:1.25，会创建 1 个副本的 Deployment，Pod 名字带随机后缀
• 想指定副本数加 --replicas=3；想加环境变量用 --env="ENV=prod"
• 注意：kubectl create 不支持挂载 ConfigMap/Secret，也不支持定义 livenessProbe，这些得写 YAML
• 常见错误：Error from server (NotFound): deployments.apps "xxx" not found —— 别慌，是命令输错了名字，或命名空间不对，默认在 default 空间，跨空间要加 -n myns

为什么必须写 YAML 才能真正管住 Pod 生命周期

命令行创建的资源太“薄”，删了重建就丢配置；YAML 是唯一能声明“想要什么状态”的方式，K8s 控制器靠它持续调谐。

• 最小可用 Deployment YAML 必须含：apiVersion（如 apps/v1）、kind、metadata.name、spec.replicas、spec.selector.matchLabels、spec.template.metadata.labels 和 spec.template.spec.containers[0].image
• selector.matchLabels 和 template.metadata.labels 必须严格一致，否则 Deployment 启动成功但 Pod 处于 Pending 或找不到关联 Pod
• 别漏掉 ports 字段——即使不暴露 Service，容器端口写明能让 kubectl port-forward 正常工作
• 示例片段：

  spec:
    containers:
    - name: nginx
      image: nginx:1.25
      ports:
      - containerPort: 80

Service 怎么配才让外部能访问到 Pod

Deployment 只管 Pod 生存，Service 才负责网络寻址。没 Service，Pod 就是个孤岛。

• 用 kubectl expose deployment nginx-demo --port=80 --target-port=80 --type=ClusterIP 最快，但只适用于 ClusterIP 类型
• 想从宿主机访问：用 --type=NodePort，K8s 会自动分配 30000–32767 区间端口，访问 http://node-ip:30123 即可
• 常见坑：Connection refused 多半是容器没监听 0.0.0.0:80（只监听 127.0.0.1），或者 target-port 写错（比如写成 8080，但 nginx 实际监听 80）
• NodePort 在 minikube 里可以直接用 minikube service nginx-demo 自动打开浏览器；在裸机集群上，记得确认防火墙放行对应端口

滚动更新和回滚实际怎么触发

改镜像版本就是最典型的滚动更新场景，但 K8s 默认不会立刻删旧 Pod，而是等新 Pod Ready 后再逐个替换。

• 更新命令：kubectl set image deployment/nginx-demo nginx=nginx:1.26（第二个 nginx 是容器名，必须和 YAML 里 containers.name 一致）
• 查看进度：kubectl rollout status deployment/nginx-demo，卡住时看 kubectl describe deployment 里的 Events
• 回滚：kubectl rollout undo deployment/nginx-demo，默认回到上一个 revision；想指定版本加 --to-revision=2
• 关键点：每次 kubectl apply -f xxx.yaml 修改了 spec.template 下任意字段（哪怕只是加个注释），都会触发新 revision；但改 metadata.annotations 不会

Deployment 的 label selector 一旦设好就不能改，改了等于新建一个控制器；滚动更新时如果新 Pod 一直 NotReady，旧 Pod 会被删光，导致服务中断——所以 readinessProbe 不能少，也不能设得太激进。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。