接手国产化环境的运维这半年，我最大的感受是：K8s本身不难，难的是在麒麟系统上把K8s管明白。命令行敲到怀疑人生，YAML文件看得眼睛发花，更别提给领导演示“集群运行状态”时，只能憋出一张黑底白字的终端截图。直到我把Kuboard搬上银河麒麟，那种“终于能喘口气”的感觉，相信每位做信创运维的朋友都懂。这篇文章就记录我从零开始，在银河麒麟V10上部署K8s并用Kuboard接管日常运维的完整过程，顺便把踩过的坑、试过的错、总结出的捷径一并写清楚，照着做，30分钟部署完真不是吹的。
1. 项目背景与需求拆解：Kuboard到底解决了什么
1.1 国产化环境里的K8s，痛点比你想的多
如果你管过国产化集群，应该对下面这些场景不陌生。银河麒麟V10服务器版的内核和生态确实比前两年成熟了，kubeadm、containerd这些主流组件都能正常跑，但“能跑”和“好用”之间隔着一条鸿沟。
第一个痛点是命令行操作门槛。K8s的原生运维完全依赖kubectl，查看Pod状态要记一堆缩写命令，看日志要先查Pod名再拼接exec参数，排查网络策略要对着CNI插件文档翻半天。对于习惯了图形界面操作的运维人员，或者是临时接手集群的同事，这个学习成本相当高。我见过不少原本跑传统虚拟化的团队，迁移到K8s后第一个月基本都在对着kubectl help发呆。
第二个痛点是排查问题的效率。Pod起不来，coredns一直CrashLoopBackOff，PV挂载失败——这些在命令行里只能一层层翻Event和Log，费时费力。更麻烦的是，国产化硬件平台五花八门，飞腾、鲲鹏、海光，每个平台的镜像适配情况还不一样，同样的故障在x86上可能一条命令就解决了，在ARM上得绕好几个弯。这种时候如果有个可视化界面，把资源状态、事件、日志全部摊开在眼前，排查速度完全不是一个量级。
第三个痛点是多集群管理的需求。做国产化替换的单位通常不止一套环境，测试环境、生产环境、容灾环境可能各有一套集群。平时不觉得，真到发布版本的时候，在多个环境之间来回切换上下文，输错命令切错集群是常有的事。我就在测试环境里执行过生产环境的发布命令，虽然最后没出大事，但吓出一身冷汗。
1.2 Kuboard是什么，为什么它能解决这些问题
Kuboard是一个开源的Kubernetes图形化管理面板，它的定位很明确：做K8s的“控制台”，让运维人员通过Web界面完成大部分日常操作。它不是要替代kubectl，而是把那些高频、重复、容易出错的操作从命令行里解放出来。
能做的事情非常实在。查看集群节点状态、CPU和内存使用情况，管理工作负载（Deployment、StatefulSet、DaemonSet），查看Pod日志和实时监控，进入容器内部执行命令，管理Service和Ingress，管理ConfigMap和Secret，甚至连Helm应用管理都内置了。这些功能覆盖了日常运维大约80%的操作频率，剩下20%的复杂场景，它旁边也有一个内嵌的kubectl终端可以直接敲命令。
更实用的是它自带的K8s资源编辑能力。很多时候我们修改一个Deployment的镜像版本，或者调整副本数，手动编YAML很容易因为格式问题提交失败。Kuboard把关键参数做成了表单，下拉框、输入框、选项开关，改完直接应用，大大降低出错率。
另一个亮点是操作审计。Kuboard会记录谁在什么时候对哪个资源做了什么变更，这个功能在国产化项目交付验收时特别有用。等保测评、项目审计的时候，需要提供运维操作的记录，Kuboard的审计日志能省不少解释口径的功夫。
1.3 方案选型：Kuboard和Rancher、KubeSphere怎么选
选题型的时候我做过一个对比。市面上常见的K8s图形化管理工具有三种：Rancher（现在是Rancher Prime）、KubeSphere和Kuboard。选型的时候主要看三点：适配国产化环境的能力、部署维护的复杂度、还有中文社区和文档的完善程度。
Rancher是老牌工具，功能确实强大，多集群管理做得很好。但它的架构偏重，自身就要部署一整套组件，在国产化ARM环境下安装踩坑的概率不低，而且被收购后版本策略变动，社区版体验有所下滑。
KubeSphere也很优秀，功能全得像个小型PaaS平台，DevOps、可观测性、服务网格都集成了。但问题也正是因为它太全了，部署起来资源开销大，对硬件配置要求高，如果底层基础设施稍弱，光跑KubeSphere本身就要占不少资源。对于一个只需要“把集群管好”的运维团队来说，未免有点杀鸡用牛刀。
Kuboard的优势在于轻量和聚焦。部署Kuboard v3只需要一组YAML文件，给K8s集群安装一个工作负载就能跑起来，资源占用非常低。它不试图做一个平台，而是专注做好“K8s运维的图形化界面”这一件事。加上它的文档和社区都在国内，中文问题可以直接搜索，很多信创场景的坑前人已经踩过、填好了，这种确定性在国产化项目里特别重要——你没有太多时间用来试错。
2. 环境准备与基础设施：先把底子打好
2.1 硬件与系统版本建议
先说下我这次实践用的环境。某单位的测试集群，三台服务器，都是飞腾ARM架构的CPU，每台配置是16核32GB内存，系统盘和本地数据盘各一块。操作系统是银河麒麟V10服务器版，内核版本在4.19和5.x之间，整体对K8s的兼容性已经比较友好。这个配置在国产化项目里算是中等水平，用来跑Kuboard和若干业务应用完全够用。
如果是新规划的集群，硬件选型有几个建议。CPU架构方面，飞腾和鲲鹏都行，但要注意集群内所有节点架构保持一致，混搭架构不是不能跑，但镜像拉取和应用调度的复杂度会成倍上升。内存方面，每台节点建议至少16GB，如果要在上面跑数据库、中间件类的有状态应用，32GB起步更稳妥。系统盘建议用SSD，尤其是跑K8s这类频繁读写容器镜像和日志的系统，机械盘的I/O很容易成为瓶颈。
系统版本方面，银河麒麟V10有多个SP版本，内核更新后对容器特性支持更完善。如果条件允许，优先选用较新的SP版本，遇到的内核模块问题会少一些。另外，做国产化交付时，强烈建议提前下载好操作系统和K8s组件的离线安装包。很多客户的生产环境是隔离网，根本没有外网，到时候临时找包下载，急得跳脚也没用。
2.2 主机初始化三件事：网络、时间与域名解析
银河麒麟装好之后，第一件事不是装K8s，而是做基础初始化。这里我踩过不少坑，按照优先级分享给你。
网络配置要提前规划。K8s集群内部通信需要节点之间能互相连通，建议给每台节点设置静态IP，并把主机名和IP的对应关系写进/etc/hosts。这样不仅在kubeadm初始化的时候少了很多麻烦，后续Kuboard显示节点名称也直观得多。有个小细节，主机名不要带下划线等特殊字符，Kubernetes对节点名称有DNS命名规范，否则后续加入节点的时候会报错。
时间同步非常重要，这个在传统运维里也强调，但在K8s环境里尤其关键。K8s内部有大量的证书校验和心跳机制，节点间时间偏差超过一定阈值，集群就会报出各种莫名其妙的问题，例如证书失效、节点NotReady。国产化环境很多是内网，没有公网NTP服务器可用，我的做法是在内网搭建一个NTP时间服务器，再让所有节点定时同步，效果很稳定。
还有swap和内核参数。K8s设计上要求节点关闭swap分区，这一点务必执行到位。另外需要在/etc/sysctl.conf里调整一些内核参数，比如允许iptables对bridge流量做转发、提升文件监听上限等，否则运行过程中容易出现网络转发异常或者Pod频繁被驱逐。这些参数网上都能查到，照着K8s官方文档的要求配置即可。
2.3 容器运行时选型：containerd还是Docker
容器运行时是K8s最底层的依赖。早期大家习惯用Docker，然后通过dockershim适配K8s。但从K8s 1.24版本开始，dockershim已经被彻底移除，官方推荐直接使用containerd。我在国产化环境里实测下来，containerd的表现也确实更稳定，资源占用更小，离K8s的CRI（Container Runtime Interface）更近，少了一层中间转换，排障思路也更清晰。
银河麒麟V10上安装containerd，可以直接用系统自带的源，也可以下载官方二进制包。安装完成后需要修改两个关键配置。一是镜像仓库地址，国产化环境拉取镜像经常超时，配置一个可用的镜像加速源很重要；二是系统级CGroup驱动，必须和Kubelet保持一致，统一使用systemd，避免因为CGroup驱动不一致导致节点状态异常。这个配置文件通常在/etc/containerd/config.toml，改完别忘重启containerd服务。
3. 核心实操：三十分钟部署K8s和Kuboard
3.1 用kubeadm快速初始化集群
初始化集群我用的是kubeadm，这是目前最主流的K8s安装工具，银河麒麟V10上也能正常工作。前提是先把kubeadm、kubelet、kubectl这些组件的二进制包准备好，版本建议选择社区里稳定使用的版本，不要追新，国产化环境里插件适配往往比新功能更重要。
初始化命令的核心参数有这几个：apiserver-advertise-address指定API Server的监听地址；pod-network-cidr指定Pod网络的CIDR网段，这个网段要和后续部署的网络插件保持一致；control-plane-endpoint指定控制平面的地址。如果集群有多个控制平面节点做高可用，这个参数尤其重要，可以填一个虚IP或者负载均衡地址。
kubeadm init \ --apiserver-advertise-address=192.168.10.10 \ --control-plane-endpoint=192.168.10.10 \ --pod-network-cidr=10.244.0.0/16 \ --kubernetes-version=v1.28.2等待初始化完成的过程中，kubeadm会自动拉取一组控制平面镜像。这一步在国产化环境里经常卡住，因为默认镜像源在国外。解决方法是提前用国内可用的镜像仓库把镜像拉取下来，再通过镜像仓库地址覆盖镜像的默认来源。操作上就是在kubeadm init参数里跟上image-repository参数，指定为国内镜像仓库，或者手动docker pull镜像后重新打tag。个人更推荐直接改image-repository，省事。
初始化成功后，kubeadm会输出一段加入集群的命令，包含一组token和证书哈希，把它保存好。后续把工作节点加入集群，就是在这台机器上执行这段命令，然后配好kubelet即可。如果token过期了，用kubeadm token create --print-join-command能重新生成。集群初始化完成后，记得把kubectl的配置文件复制到当前用户目录下，这样才能用kubectl管理集群，进行后续操作。
3.2 网络插件选型与Calico/Flannel部署
集群初始化的下一步是安装Pod网络插件。这一步不做，节点会一直是NotReady状态，因为Kubernetes需要知道Pod之间怎么通信。常用方案有两个：Calico和Flannel，我这次选的是Calico。
Calico的优势在于支持NetworkPolicy网络策略，做多租户隔离和东西向流量控制时非常有用。在国产化项目里，安全部门经常要求做网络策略管控，Calico能直接满足这部分需求。部署很直接，下载Calico的YAML清单，然后kubectl apply即可。ARM架构的镜像Calico官方也有提供，用最新版本基本不会碰到架构兼容问题。
有一点容易踩坑：Calico默认的Pod网段是192.168.0.0/16，如果你的集群在初始化时用了别的CIDR，要先把Calico YAML清单里的网段改成对应的值再apply。不一致会导致Pod拿不到IP或者跨节点无法通信，排查起来相当痛苦。改完YAML之后apply，再用kubectl get pods -n kube-system观察calico相关Pod的状态，全部Running之后，节点状态就会从NotReady变成Ready。
3.3 部署Kuboard v3：一条命令拉起控制面
集群就绪后，部署Kuboard v3就进入了快车道。Kuboard官方提供了一个部署用的YAML清单，包含了所有的资源对象定义，包括命名空间、服务账号、部署、服务等。执行下面的命令就能一键部署：
kubectl apply -f https://kuboard.cn/install-script/kuboard.yaml不过国产化环境大概率访问不了这个地址，我提前把YAML文件下载下来放到本地，改用kubectl apply -f kuboard.yaml执行，效果一样。如果你用的是离线环境，把整个YAML文件通过跳板机拷贝到集群里，直接apply就行。
YAML执行完成后，Kuboard会创建自己的命名空间和一系列K8s资源。等Pod变成Running状态后，还需要做一些配置才能正常访问。Kuboard v3的Web服务是通过NodePort或者Ingress暴露的，默认服务端口是80和443，具体用哪种方式取决于你的集群环境。建议使用Ingress方式对外提供服务，这需要集群里已经部署了Ingress Controller（比如nginx-ingress或traefik），Kuboard对Ingress的支持很完善，直接创建一个Ingress对象绑定域名即可。
注意：关于Kuboard的访问模式，我的经验是先确认集群的Ingress Controller是否就绪，没有的话先装一个，否则后面想到要配置Ingress却找不到资源，又要回头补步骤。
另外要设置好管理员账号。Kuboard v3支持环境变量配置初始管理员用户和密码，在部署前或部署后修改deployment的env变量都行。建议部署前就把这些环境变量写好，省得多操作一次。如果忘了设置，也可以在Kuboard的界面上用初始化用户入口完成设置，但生产环境还是建议提前规划好强密码。
3.4 配置Ingress和认证，让Kuboard真正可用
为了让Kuboard面板能被浏览器正常访问，我创建了一个Ingress对象。这块涉及的步骤比较多，我建议按照这个顺序操作。
先确认Ingress Controller正常，检查kube-system或ingress-nginx命名空间下的控制器Pod是不是Running状态。然后创建Ingress资源，指定域名绑定到Kuboard的服务。域名可以是一个内网DNS能解析的名字，比如kuboard.internal.example，后面配好DNS或用/etc/hosts就能访问。
再配置TLS证书。生产环境访问Kuboard界面建议启用HTTPS，虽然内网用HTTP也能凑合，但Kuboard的部分功能（比如Web终端和日志流）在浏览器安全策略下，混合内容会被阻止。如果不想自己折腾证书，可以用自签证书或者搭建内部CA签发，只要浏览器端信任即可。实际操作中，我把自签证书配置到Kuboard的Ingress上，浏览器访问时手动信任一次，之后就不会再弹警告了，体验还算能接受。
最后设置Authentication认证。Kuboard自带用户认证体系，可以对接企业已有的LDAP或Radius认证，也可以使用内置用户。国产化项目里很多单位有统一身份认证平台，Kuboard官方文档有详细的对接说明。我在测试环境用的是内置账号，配合强密码策略，基本够用。生产环境建议对接企业认证系统，把账号生命周期统一管理起来，防止人员变动后账号成了“僵尸号”。
3.5 验证集群能力：部署一个测试应用看效果
Kuboard部署完成后，就该检验它能不能正常工作了。我在集群里创建了一个简单的Web应用，用Kuboard界面操作完成了一次完整的发布流程。
登录Kuboard控制台后，首页会显示集群的概览：节点数量、CPU和内存使用率、各命名空间的资源情况、运行中的Pod数。以可视化的方式看一眼整个集群的健康状态，这种体验相比kubectl get nodes和kubectl top nodes，直观程度完全不一样。从“一堆字符”变成“仪表盘”，对运维人员来说，感知差异是非常大的。
接下来我创建了一个名为demo的命名空间，然后在里面新建一个Deployment，指定镜像和副本数，点击部署，界面上能实时看到Pod创建的过程和状态变化。等Pod运行起来后，我直接通过Kuboard进入了存储卷、服务发现、配置管理这几个页面，看到每个对象的YAML内容、关联关系、事件信息都分门别列展示出来了。这种粒度对日常排障和资源梳理非常有价值，待办事项一目了然，好东西用了就回不去了。
4. 常见问题与排查技巧：从踩坑现场整理的笔记
4.1 镜像拉取失败的三种解法
这是国产化环境里出现频率最高的问题，我列三个最常见的场景和对应解法，可以直接抄作业。
第一种场景是kubeadm初始化时拉取镜像超时。这个问题的根源是镜像源在国外，网络不通或者极度缓慢。解法是在初始化命令里指定image-repository参数，或者提前手动拉取镜像并导入。实际操作中，我推荐先把kubeadm config images list命令列出的镜像清单全部拷到一个内网镜像仓库，然后修改kubeadm配置文件指向这个仓库，再执行init命令，省时省力。
第二种场景是Pod运行后容器一直ImagePullBackOff。这通常意味着镜像不存在，或者是架构不匹配。我在ARM平台部署时经常拉取到x86的镜像，Pod会一直起不来。检查方法是用kubectl describe pod查看事件信息，看具体的错误码是ManifestUnknown还是NotFound。如果是架构问题，直接换成ARM64版本即可。
第三种场景是离线环境完全没有外网，连内网镜像仓库也没有。这种情况只能在能联网的机器上提前下载所有镜像，打包成tar文件后拷入内网，再用ctr或docker load导入。做完之后记得把镜像tag改成节点上containerd能识别的方式，不要在这个环节省时间，否则后续排查会耗费更多时间。
4.2 ARM架构下的兼容性坑
国产化CPU以ARM架构为主，很多镜像默认只发布了x86_64版本，这个兼容性问题在部署过程中容易反复出现。我的经验是：在选镜像的时候，优先选择官方multi-arch镜像（即同一tag包含多种架构），这些镜像拉下来之后containerd会自动匹配当前架构的版本。如果是第三方自定义镜像，就要确认发布时是否单独编译了arm64版本，在页面上能看到architecture字段。
还有一个容易被忽视的点：ARM机器上有些编译型应用，比如一些依赖本地共享库的中间件，镜像看起来能启动，但运行起来马上崩溃，日志里有“exec format error”的字样。这种大概率是在x86机器上编译的二进制直接被打进了镜像，在ARM上根本无法执行。解决办法只能是找对应的ARM编译版，或者重新构建镜像。这个坑在国产化环境里特别普遍，遇到不用慌，先用file命令确认下二进制架构，再找对应的新镜像即可。
4.3 Kuboard界面打不开？问题多半出在Ingress
Kuboard部署成功但浏览器访问不了，这种问题我排查过好几次，大多数情况是Ingress配置出了偏差。首选是检查Ingress Controller的状态，不是看Kuboard自己的Pod，而是看ingress-nginx的Pod是否正常调度，这两者是两层关系。如果Ingress Controller本身没起来，Kuboard的Ingress只会被“挂起”，请求进来没有任何响应。
其次是域名解析问题。如果用的是内网域名，需要在客户端机器的hosts文件里加一条解析记录指向Ingress Controller的IP，浏览器访问前先ping一下域名确认能通。这里有个隐蔽的坑，Ingress Controller通常会以NodePort或LoadBalancer方式暴露，而它的IP并不一定等于任意一个集群节点的IP，可能需要查看服务被分配到的具体端口和节点，把这些信息写对才有效。
最后是TLS证书导致的访问异常。如果用了自签证书且没有配置好信任链，浏览器会直接拦截访问，页面上出现“连接不安全”的提示。这不是Kuboard的问题，但很多人会误判。我的建议是先把Ingress的TLS配置暂时去掉，用HTTP方式验证Kuboard能访问，然后再重新加证书，这样能快速区分是Ingress问题还是证书信任问题。
5. 国产化环境下的运维管理升级：Kuboard带来的范式转变
5.1 日常巡检：从逐条敲命令到看仪表盘
有了Kuboard之后，日常巡检的流程发生了质的变化。以前我巡检一套K8s集群，要依次执行节点状态查询、Pod列表查询、资源占用查询、事件查询，至少敲十几条命令，还要自己脑补各种异常情况。现在打开Kuboard首页，一眼就能看到集群的整体健康度和资源水位，往下滚还能看到常见事件。
对于具体的业务应用，我习惯在Kuboard上维护一个应用视图，把所有和某个业务相关的资源（Deployment、Service、ConfigMap、PVC等）都打上标签归类。这样每次巡检，我只需要点进对应的应用视图，就能看到该应用涉及的资源有没有异常，Pod是否都在正常运行状态。这种以应用为视角的管理方式，比K8s原生以资源为视角的方式，对业务运维人员来说友好太多了。
另外，Kuboard内嵌的kubectl终端功能我在日常排查中经常用到。遇到面板上没办法直接表达的操作，比如批量重启或者动态调试，我会直接在该资源详情页打开终端，上下文自动切换到了对应的命名空间，不需要再全局切换上下文，省去了很多麻烦。
5.2 权限设计与多环境管理安全
国产化项目的运维团队通常不止一个人，不同角色对集群的操作权限也应该有所区分。Kuboard的权限模型可以很好地支持这个需求。管理员账号拥有全局管理权限，而普通用户可以被限制在指定的一个或多个命名空间内，只能查看或操作授权后的资源。我在实际交付中，通常给开发人员分配某个业务命名空间的只读权限，给测试人员分配测试环境命名空间的读写权限，只有核心运维人员才能拿到集群级的管理权限，这样职责边界清晰，审计也方便。
多环境管理方面，Kuboard支持在同一控制台里接入多套K8s集群。接入方式是提供目标集群的API Server地址和Token凭据。我在测试环境里接入了一套ARM集群和一套x86集群，切换时在控制台里点击切换即可，不用再在多个kubectl config之间来回折腾。不过有一点要注意，生产环境和测试环境用同一套Kuboard管理时，建议在命名空间和权限上做严格隔离，避免操作失误把测试环境的东西带到生产环境。血的教训，宁可多一道隔离策略，也不要省这点配置功夫。
5.3 备份与审计：让国产化验收更省心
国产化项目审计要求特别严格，操作留痕、变更可追溯是硬性需求。Kuboard自带的审计日志在这一块帮了大忙。每个人登录Kuboard后做了什么操作，在哪个命名空间改了什么资源，都有详细记录。投屏给评审专家看一遍，比自己解释清清爽爽得多。
另外，K8s集群自身的备份也要养成习惯。我之前经历过一次误删命名空间，虽然Kuboard的操作界面很友好，但正是因为友好，鼠标一抖点错了删除，事件不可恢复。后面我养成了定期备份etcd数据和K8s资源清单的习惯。对于资源清单，可以直接通过Kuboard的“导出”功能把命名空间下的资源导出为YAML文件，再统一归档到Git仓库里。总之，不要相信自己的手不会抖，备份永远不嫌多。
6. 资源规划与性能考量：别让小马拉大车
6.1 Kuboard自身资源占用实测
很多人担心部署一套管理平台又要吃掉不少机器资源，其实Kuboard非常轻量。我在测试环境里观察过，Kuboard v3的核心服务通常只需要一个Pod，设置合理的资源请求其实很低，初始化内存占用也就几百MB。相比KubeSphere动辄几个G的资源开销，Kuboard对国产化环境里普遍不充裕的服务器资源来说，友好度完全不在一个档次。
部署的时候我建议在Deployment的配置里显式声明资源requests和limits。requests按CPU 0.1核、内存256Mi起步，limits可以放松一些，给到CPU 1核、内存1Gi左右。怎么样都够用了，日常操作几百个资源对象完全没有卡顿感。Kuboard的数据存储走的是PVC，给这个PVC配上合适的存储类型很重要，至少读写性能要跟得上。我用的是本地存储类，SSD盘，体验良好。
6.2 集群资源监控维度的补充
Kuboard侧重点在于资源管理和运维操作，如果你想看到Pod或节点的历史性能曲线，还是建议叠加一套监控方案。目前K8s生态主流的监控方案是Prometheus加Grafana，Kuboard本身也提供了内置的资源监控，能短时间看到CPU和内存趋势，满足大部分轻量需求即可。如果单位要求保留半年甚至一年的监控指标用于追溯分析，那就必须要上独立的监控存储了。
在这个组合里，Kuboard负责“操作面板”，Prometheus负责“指标仪表盘”，两者互补。我现在的习惯是：日常操作和维护在Kuboard里完成，需要看告警或者长期趋势分析时才切到Grafana。分工明确，做事情也不乱。
我的实操体会与最终建议
在银河麒麟的国产化环境里折腾了小半年，我的核心体会是：K8s本身有学习门槛，但运维不应该被命令行锁死。管理好集群不仅要靠工具，更要对整个环境的选型、配置、应急有通盘考量。Kuboard这种可视化工具，相当于给了运维团队一个“总控制室”，什么在运行、什么出了问题、要改什么配置，一眼就能看清楚。尤其对于人员流动相对频繁的国产化项目来说，让新接手的人能快速看懂集群现状，比手把手教他敲kubectl命令有效率得多。
最后分享一个细节，如果你确定要在国产化环境里上这套方案，先把阶段工作排摸清楚：确认镜像源在内网是否可用，确认所有节点的安全策略是否足够，确认Arm架构镜像是否准备好。这几条基础工作花不了多少时间，但都是血泪换来的教训。工具只是手段，国产化运维的核心，还是要把基础环境打磨稳定，再把Kuboard这类利器插进去，才能真正确保运维过程轻松可控。
