企业官网建设流程全解析

Kubernetes 这门手艺，学的人多，敢从零手搓一套生产可用集群的人不多。我第一次装集群是三台虚拟机、一张 A4 纸写满证书路径，折腾到凌晨两点才发现 kubelet 和容器运行时的 cgroup driver 对不上。后来接触到云操作系统这类产品形态，才意识到很多痛苦其实是被"重复造轮子"制造出来的——它把 Kubernetes 控制面、CNI 网络、CSI 存储、Dashboard、镜像仓库、应用商店、账号体系打包成一个可离线分发的安装包，一条命令拉起整个平台，然后你面对的就不再是"怎么装",而是"怎么用"。

这篇内容想聊的就是这个：一套基于 Kubernetes 构建的云操作系统，它的内部分层是怎样的，一键部署背后到底做了哪些事，装起来之后怎么通过 Dashboard 把第一个 Pod 跑起来并发布成可访问的服务，以及我在实际落地里踩过的那些坑。适合两类人看：一类是刚学完 Kubernetes 核心概念、想找个能动手的环境练手的朋友；另一类是团队里被"搭集群"这件事卡住、想快速拿到一个可交付平台的运维或后端同学。基础概念我会点到，但不会写成教科书，重点放在"为什么这么设计"和"你动手时该注意什么"。

1. 云操作系统到底解决什么问题

1.1 从"裸装集群"到"开箱即用"的痛点清单

手动部署一套能用的 Kubernetes，麻烦从来不在kubeadm init那一行命令上。真正的成本藏在前后两头：前面是环境准备，主机名、时间同步、内核参数、swap、防火墙规则、容器运行时，每一项漏掉都可能在半小时后以一句语焉不详的报错找上门；后面是平台配套，集群起来了，但 Dashboard 没装、Ingress 没有、存储类没有默认供应者、监控日志一律空白，业务方问"我的应用怎么对外访问"，你只能说"再等等"。

把这些拆开看，一套最小可用的平台大概包含七八个组件：控制面（apiserver、controller-manager、scheduler、etcd）、容器运行时、CNI 网络插件、CSI 或本地存储供应者、CoreDNS、Metrics Server、Ingress Controller、Dashboard。每个组件都有自己的版本兼容矩阵和配置项，任何一个选错版本，轻则功能缺失，重则集群起不来。云操作系统的价值就在于，它把这套组合拳的版本匹配和默认参数替你定死了，你拿到的是一个经过验证的"套餐"，而不是十份各自的安装文档。

我用过一个很形象的比喻：裸装 Kubernetes 像是买散件攒电脑，便宜、自由，但你要自己确认内存频率和主板是否兼容；云操作系统则是品牌整机，开箱即用，代价是某些角落的定制空间被压缩了。对绝大多数中小团队来说，这个交换是划算的。

1.2 云操作系统的分层架构与核心组件

把这类产品拆开看，从下往上大致是四层，理解这个分层对后面排查问题特别有帮助，因为故障现象往往能直接对应到某一层。

第一层是基础设施层，包括操作系统内核、容器运行时（containerd 是现在的默认选择）、kubelet 和 kube-proxy。这一层的问题通常表现为节点 NotReady、Pod 起不来、网络不通。

第二层是编排层，也就是 Kubernetes 控制面本身，apiserver 负责所有请求入口，etcd 存全量状态，调度器决定 Pod 落到哪个节点。这一层的故障往往是"整个集群失联"，比如 apiserver 的 6443 端口被占、etcd 磁盘 IO 打满。

第三层是平台服务层，网络插件、存储供应者、DNS、证书管理、镜像仓库都在这里。它决定了你的 Pod 能不能互相通信、PVC 能不能绑定成功。

第四层是用户界面层，Dashboard、账号权限、应用商店、命令行工具都归这一层，也是普通用户唯一直接接触的部分。

注意：分层模型不是学术摆设。当 Dashboard 打不开时，你要能判断是第四层的 Ingress 配置错了，还是第三层的 Service 没通，还是第二层的 apiserver 已经挂了。按层排查，比盲目重启高效得多。

1.3 自建集群与云操作系统的横向对比

很多人纠结的点是"我到底该自己搭还是用一个打包好的平台"。下面这张表是我根据几个实际项目整理的对比，可以直接对号入座。

我个人的判断标准很简单：如果团队里没人愿意长期维护这套集群，那就别自己搭。Kubernetes 的运维成本不在安装，而在日常的版本升级、证书轮换和故障响应，这三件事才是真正吃人力的地方。

2. 一键部署的底层逻辑拆解

2.1 离线镜像打包与安装器的设计考量

"一键"这两个字听起来很玄，实际原理并不复杂。安装包本质上是一个巨大的压缩文件，里面装着四类东西：容器运行时和 kubelet 的二进制文件、所有系统组件的容器镜像（以 tar 或 OCI 格式存放）、Helm Chart 或 YAML 模板、以及一个负责渲染和执行这些模板的安装器程序。

执行安装的时候，安装器做的事情是有固定顺序的：先把二进制定到目标路径并配置 systemd 服务，然后把镜像加载进本地容器运行时的镜像仓库，接着在第一个节点上执行集群初始化生成证书和 kubeconfig，再把其他节点加入集群，最后渲染并应用那些 YAML 模板，把 Dashboard、Ingress、存储供应者这些平台组件装上去。

为什么非要搞成离线包而不是从公网拉镜像？两个原因。一是企业内网环境大多没有直连外网的条件，二是从公共镜像仓库拉取几十个镜像，网络抖动导致的失败率非常高，而且每次部署都重复下载几百兆到几个 G 的流量，纯属浪费。离线包把"不确定性"提前消化掉了，这是它能做到"一键"的关键。

实操心得：拿到离线包后先校验一下哈希值，再确认包内镜像列表里有没有架构不匹配的（比如包里是 amd64 镜像，你的机器是 arm64）。这两步能挡掉相当一部分"装到一半失败"的尴尬。

2.2 容器运行时与集群初始化的取舍

容器运行时这块，现在的标准答案基本就是 containerd。Docker 在 Kubernetes 1.24 之后已经不再作为直接支持的运行时，虽然还能通过 cri-dockerd 绕过去，但没必要给自己找麻烦。containerd 更轻、启动更快、和 kubelet 的对接也更干净。

有一个非常容易翻车的细节：kubelet 的 cgroup driver 必须和容器运行时一致。现在双方都默认用 systemd，但如果你手动改过 containerd 的配置文件，把它改成 cgroupfs，而 kubelet 那边还是 systemd，节点就会以"SystemdCgroup 不匹配"之类的理由拒绝启动。这个错我在两个项目里都见过，排查起来还挺费时间，因为日志信息不算直观。

集群初始化前需要处理的内核参数，我列一份清单，这些在多数安装器里会自动做，但知道它们存在很有必要：

# 关闭 swap，kubelet 默认不接受开启 swap 的节点 swapoff -a sed -i '/swap/s/^/#/' /etc/fstab # 开启网桥流量经过 iptables，否则 Service 转发会出问题 modprobe br_netfilter cat > /etc/modules-load.d/k8s.conf <<EOF br_netfilter overlay EOF # 内核转发与 iptables 相关参数 cat > /etc/sysctl.d/k8s.conf <<EOF net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 fs.inotify.max_user_instances = 8192 EOF sysctl --system

解释一下最后那个max_user_instances。默认值通常是 128，当节点上 Pod 数量多、且每个 Pod 里都有进程在监听文件事件时，inotify 实例会被耗尽，表现出来就是某些容器莫名其妙地启动失败，日志里出现 "too many open files"。这个参数在官方的安装文档里往往不起眼，但在实际生产中很关键，我一般直接调到 8192。

2.3 网络与存储的默认选型理由

网络插件的选择，主流就是 Calico 和 Cilium 两家。Calico 成熟稳定、文档齐全、出问题好查，用的是 BGP 或者 IPIP 隧道转发，对内核版本要求不高；Cilium 基于 eBPF，性能更好、可观测性更强，但对内核版本有硬性要求（一般建议 4.19 以上）。

云操作系统默认给的一般是 Calico，理由很实在：兼容性好，不容易因为内核太老翻车。这个选择我在实际使用中是认可的，毕竟平台的第一要务是"能跑起来"，性能优化可以后面再谈。

IP 网段的规划是另一个容易被忽略的点。默认的 Pod CIDR 常见是10.244.0.0/16，Service CIDR 是10.96.0.0/12。如果你公司内网恰好用了10.96.x.x这个段，就会出现从 Pod 里访问不了内网服务的诡异现象——因为流量被路由规则劫持到了集群内部。我遇到过一次，追了整整一个下午才发现是网段冲突。

注意：部署前一定先确认内网网段，尽量避开10.0.0.0/8、172.16.0.0/12、192.168.0.0/16这些常见段。如果实在避不开，就在安装时显式指定 Pod CIDR 和 Service CIDR。

存储方面，这类平台通常会带一个基于本地磁盘的轻量供应者（local-path 类型），开箱即用，给开发测试环境足够。生产环境要换成 NFS、Ceph 或者云厂商的块存储，原因很简单：本地盘的数据跟着节点走，节点挂了 Pod 飘到别的机器上，数据就找不到了。这一点在做有状态服务时绝对不能含糊。

3. 从零到一：把云操作系统跑起来的完整实操

3.1 环境准备与资源规划

先算资源。一套最小的高可用集群，我建议三台控制面加两台以上工作节点。控制面每台 4 核 8G 起步，etcd 对磁盘 IO 敏感，务必用 SSD；工作节点看业务，我通常按"每个 Pod 预留 0.5 核 512M"来估算，再留 30% 的余量。

IP 规划我用一张表来固定，这样后面配置证书和访问入口时不会乱：

主机名务必确保唯一并且能互相解析，我在/etc/hosts里写死，比依赖 DNS 稳定。时间同步用 chrony，误差超过几秒就可能导致证书校验失败，报错信息还特别难懂。

3.2 执行一键安装与验证

安装命令的形态各家略有不同，但参数结构大同小异。以我最近用过的形式为例：

sudo ./deploy.sh \ --masters 192.168.10.11,192.168.10.12,192.168.10.13 \ --nodes 192.168.10.21,192.168.10.22 \ --pod-cidr 10.244.0.0/16 \ --service-cidr 10.96.0.0/12 \ --vip 192.168.10.10 \ --install-dashboard \ --install-ingress

这个过程一般五到二十分钟，取决于磁盘速度。第一次装的时候别急着走开，盯着输出看，出现黄字警告要留意，很多警告虽然在最后被标成"可忽略"，但背后可能是某个组件没装成功。

装完之后立刻做三层验证，这个顺序别乱：

# 第一层：节点状态，全部应该是 Ready kubectl get nodes -o wide # 第二层：系统组件，CoreDNS、网络插件、Ingress 都应该 Running kubectl get pods -A # 第三层：集群信息，确认版本和 Service 网段 kubectl cluster-info kubectl get svc -n default

如果节点是 NotReady，先去看journalctl -u kubelet -n 100 --no-pager，十有八九是运行时没起来或者证书有问题。如果系统 Pod 卡在 Pending，多半是资源不够或者有污点没容忍。

3.3 部署第一个应用：从 YAML 到可访问

集群通了，就该跑业务了。我习惯用一个 Nginx 做验证，因为它足够简单，出问题也容易定位。先写一个 Deployment：

apiVersion: apps/v1 kind: Deployment metadata: name: demo-web namespace: default spec: replicas: 2 selector: matchLabels: app: demo-web template: metadata: labels: app: demo-web spec: containers: - name: nginx image: nginx:1.25-alpine ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 256Mi

这里有个细节值得说：requests和limits一定要写。不写 requests，调度器只能瞎猜，容易出现节点超卖；不写 limits，某个 Pod 内存泄漏就能把整个节点拖垮。生产环境我还会给命名空间配 ResourceQuota，从上面卡一道总闸。

接着是 Service，用 ClusterIP 先在集群内部验证连通性：

apiVersion: v1 kind: Service metadata: name: demo-web-svc namespace: default spec: selector: app: demo-web ports: - port: 80 targetPort: 80 protocol: TCP type: ClusterIP

注意selector里的app: demo-web必须和 Deployment 的 Pod 模板标签完全一致，这是最常见的"Service 没有后端"的原因。写完 apply 之后，直接kubectl get endpoints demo-web-svc，如果 endpoints 列表是空的，就是标签没匹配上。

最后加 Ingress 把服务暴露出去：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo-web-ingress namespace: default spec: ingressClassName: nginx rules: - host: demo.example.internal http: paths: - path: / pathType: Prefix backend: service: name: demo-web-svc port: number: 80

访问时记得把域名解析到 Ingress 入口 IP，否则只能靠curl -H "Host: demo.example.internal"这种方式验证。

3.4 用 Dashboard 创建 Pod 并发布成服务

对不熟悉命令行的同学，Dashboard 是很好的入门入口。整个流程大概是这样：

第一步，找到 Dashboard 的访问地址。通常是 Ingress 暴露的一个域名，或者通过 NodePort 访问。拿到登录 token 的方式是查询 Dashboard 所在命名空间里的 Secret：

kubectl -n kubernetes-dashboard get secret \ $(kubectl -n kubernetes-dashboard get sa admin-user -o jsonpath='{.secrets[0].name}') \ -o go-template='{{.data.token | base64decode}}'

这一步在新版本里可能因为 Secret 自动生成机制的变化而不同，如果没有对应的 Secret，就自己用kubectl create token命令签一个短期 token。

第二步，进入 Dashboard 后，右上角切换到目标命名空间，然后点"创建工作负载"。这里有两种模式：表单模式和 YAML 模式。表单模式适合新手，但字段是精简过的，很多高级配置填不了；我推荐直接用 YAML 模式，把上面那个 Deployment 的 YAML 粘进去，效果和命令行完全一样。这也顺便回答了那个高频问题——Dashboard 里怎么创建 Pod：你实际上创建的是 Deployment 这类控制器，Pod 由它托管生成，不建议手搓裸 Pod。

第三步，发布成服务。在 Dashboard 的"服务"页面点"创建"，选择类型。集群内部访问选 ClusterIP，临时测试选 NodePort，生产对外选 Ingress 或 LoadBalancer。关键还是那一步：给 Service 指定一个与 Pod 标签匹配的选择器。Dashboard 表单里会列出当前命名空间下已有的标签，勾选即可，比手写 YAML 少犯错。

实操心得：Dashboard 的"事件"面板是我用下来最值钱的页面。Pod 起不来、镜像拉不动、调度失败，事件里往往一句话就说清了原因。比在命令行里翻kubectl describe的输出快很多。

4. 核心概念落地：Pod、Service、Ingress 怎么配合

4.1 Pod 与工作负载控制器的分工

Pod 是 Kubernetes 里最小的调度单位，一个 Pod 可以装一个或多个容器，共享网络和存储命名空间。多容器的典型用法是 sidecar，比如主容器跑业务，边车容器负责日志收集或流量代理。

但裸 Pod 在生产里几乎不该出现，原因有三：节点故障时不会自动重建、不能滚动更新、副本数没法保证。正确的做法是用控制器托管，日常就记住四类：

我见过不少团队用 Deployment 跑数据库，图省事，结果扩容时多个副本抢同一份数据，直接翻车。数据库这类有状态的，老老实实用 StatefulSet 加持久卷。

4.2 Service 与 Ingress 的流量路径

Service 解决的是一组 Pod 的稳定访问问题。Pod 的 IP 会变，Service 的 ClusterIP 不会。它靠标签选择器把流量转发到后端 Pod，具体转发规则由 kube-proxy 以 iptables 或 IPVS 模式实现。IPVS 模式在服务数量多的时候性能优势明显，一般超过一千个 Service 就该考虑切换。

四种 Service 类型各有用途：ClusterIP 只对内，NodePort 在每个节点上开一个高端口，LoadBalancer 需要底层支持，ExternalName 是做 DNS 别名。

Ingress 则是第七层的入口，它本身不是一种 Service，而是一套路由规则，需要 Ingress Controller 去实现。流量路径大致是：外部请求 → 负载均衡器或节点端口 → Ingress Controller → 按域名和路径匹配 → 转发到对应 Service → 后端 Pod。搞清这条链路，排查"外部访问不了"就有方向了：先看 Controller 有没有起来，再看 Ingress 规则的 class 和 host 对不对，最后看 Service 的 endpoints 是不是空的。

4.3 命名空间与多租户隔离

命名空间是逻辑隔离手段，不是安全边界。真正要做到多租户隔离，得组合使用几样东西：

第一是ResourceQuota，限制每个命名空间的总 CPU、内存、Pod 数量和 PVC 数量，防止某个团队把集群吃干净；第二是LimitRange，给没有声明 resources 的 Pod 设定默认值，避免"裸奔"容器；第三是NetworkPolicy，控制命名空间之间的东西向流量，默认拒绝更安全；第四是RBAC，把用户和 ServiceAccount 绑定到具体的角色上，权限给到最小。

这里有个容易忽视的点：很多 CNI 插件默认不启用 NetworkPolicy，只是"接受配置但不下发规则"。部署完之后一定要实际测一次，否则你以为隔离了，其实门户大开。

5. 常见问题与排查技巧实录

5.1 安装阶段的典型坑

第一个坑是端口占用。apiserver 的 6443、kubelet 的 10250、etcd 的 2379 和 2380，任何一个被占都会导致安装失败。装之前先ss -lntp扫一遍，特别是有没有残留的旧集群进程。

第二个坑是主机名重复。多台机器主机名都是localhost或者k8s-node，加入集群时节点会互相覆盖。装之前统一改/etc/hostname并重启。

第三个坑是防火墙和 SELinux。很多安装文档建议直接systemctl stop firewalld和setenforce 0，但这是临时手段，重启后失效。稳妥的做法是写入配置文件永久关闭，或者按需放行端口。我一般选择永久关闭并记录在案，因为在内网受控环境下，用 NetworkPolicy 做细粒度管控比宿主机防火墙更合适。

第四个坑是镜像拉取失败。如果安装器配置里既写了离线包又配了公共仓库地址，可能会出现镜像地址被改写、本地找不到的怪现象。检查一下crictl images里到底有没有那些镜像，比看安装日志更快。

5.2 运行阶段故障速查表

下面这张表是我这几年攒下来的，基本覆盖了八成以上的日常问题：

用这张表的时候有个技巧：永远先看 Events。kubectl describe输出的最后一部分就是事件，它会按时间倒序告诉你最近发生了什么，很多问题不需要查文档，答案就在那几行里。

5.3 几个我印象比较深的实际问题

有一次客户报"集群里所有服务都访问不了"，但不是全部，只有新部署的。我先看节点，全 Ready；再看 CoreDNS，正常。最后发现问题出在 IP 地址池耗尽——Pod CIDR 配得太小，只给了/24，也就是 256 个地址，实际 Pod 数量早就超了。新建的 Pod 拿不到 IP，就一直 Pending。教训是：Pod CIDR 起步至少/16，别抠这点地址空间。

还有一次更隐蔽：某个服务白天正常，凌晨定时任务跑的时候批量超时。查了半天发现是节点的 conntrack 表满了，内核默认上限在连接数多的时候不够用。解决办法是调大nf_conntrack_max并缩短超时时间。这类问题不会出现在任何入门文档里，只有在真实流量下才会暴露。

第三个是镜像层。测试环境正常，生产拉取超时，原因是生产用的是私有仓库，而某几个镜像被固定了完整的仓库地址，改配置文件时漏改了一处。这种"环境差异"类问题，最好的办法是把镜像地址全部抽到变量里统一管理，而不是散落在各个 YAML 中。

提醒：给集群装监控不是可选项。很多"莫名其妙"的问题，其实早就在指标里露出苗头了，比如内存缓慢上涨、连接数持续走高。等到业务报警才去查，成本高得多。

6. 从能跑到好用：平台能力的后续扩展

6.1 监控告警与日志采集

集群跑起来只是起点。第一件要补的是监控。指标采集用 Prometheus 系列的方案是主流，节点层看 CPU、内存、磁盘、网络，容器层看资源使用和重启次数，控制面看 apiserver 的请求延迟和 etcd 的写入耗时。告警规则先配最关键的几条：节点不可用、Pod 重启次数异常、磁盘使用率超过 80%、证书剩余有效期不足 30 天。

日志这块分两条路：容器标准输出用日志代理采集后送到集中存储，便于全文检索；应用内部的日志文件，要么改造成标准输出，要么挂持久卷单独处理。我的建议是尽早统一成标准输出，运维成本最低。

6.2 应用商店与 GitOps 落地

云操作系统一般会带一个应用商店，本质上是 Helm Chart 的可视化封装，装中间件、数据库、消息队列都很快。它的价值在于把"改 values 文件"这件事变成了填表单，降低了门槛。但要注意，商店里的 Chart 版本往往滞后，生产选型时还是要看官方的最新稳定版。

更进一步的做法是 GitOps：把所有部署清单放进代码仓库，集群里的状态由控制器自动同步。好处是变更可追溯、回滚就是一次 revert、环境差异靠目录结构管理。这套流程一旦跑顺，团队就不太会再手敲kubectl apply了。

最后分享一个我在多个项目里验证过的经验：先把一个最小的业务闭环跑通，再谈平台能力的完善。很多人一上来就想把监控、日志、服务网格、CI/CD 全套配齐，结果核心业务一个都没上线，平台本身成了负担。先让一个真实的、有人用的服务在集群里稳定跑两周，你会自然地发现下一个该补的是什么。

这套基于 Kubernetes 的云操作系统，我自己的使用感受是：它把学习曲线最陡的那段给抹平了，让你能在半天内从"只有几台机器"走到"有一个能用的平台"。但它省掉的是入门成本，不是理解成本。Pod 为什么不建议裸跑、Service 的选择器为什么关键、Ingress 和 Service 的边界在哪，这些问题还是得自己搞明白，否则换个环境、换个发行版，照样会卡住。工具能帮你省时间，理解才能帮你省命。