作者：石浩男，国星宇航 Java 开发工程师，平时主要负责开发工作以及运维工作。之前主要从事大数据组件开发，以及数据血缘相关的工作。K8s 对大数据组件支持程度还不够完善，能接触 K8s 的机会比较少，但本人对于云原生有很强烈的向往，苦于原生 K8s 门槛较高，较为繁琐，正好借助于低成本入门的 KubeSphere，从头学习实践了 K8s。
公司简介
国星宇航是一家 Al 卫星互联网科技公司，由卫星互联网领域的科研院所及部耿领军人才创办。截至目前，国星宇航已完成 10 次太空任务，研制并发射 14 颗 AI 卫星及载荷国星宇航通过低成本快响应卫星研制技术体系、全栈 AI 卫星网络技术体系、面向未来的可信共享互联通信技术体系，形成了面向不同应用场景的 B 端、G 端、C 端等卫星互联网产品，已服务上百家政企客户，并覆盖上亿 C 端用户。国星宇航始终坚持与祖国在一起，助力社会，服务人民， 致力于实现“同一个星空，同一个网络”的美好愿景。
IT 建设目标
我们期望基于 K8s 搭建 PaaS 云计算基础平台，多租户管理使用资源，集成 CI/CD、支持灵活扩容与升级集群，构建企业级一站式 DevOps 架构，提高集群资源可监控性，可溯源操作审计。
环境痛点
物理机服务器集群，未使用第三方托管上云，在使用 K8s 之前使用 Docker Swarm 模式部署，Portainer 可视化管理 Docker 容器，开发部署环境混乱，运维管理成本大，服务器资源利用率不高。
IT 运维与开发团队的规模
子部门，后端开发 2 人，前端 2 人，运维兼开发一人，小规模开发团队。
背景介绍
云原生（Cloud Native）这个概念最早由来自美国云原生公司 Pivotal 的 MattStine 于 2013 年首次提出，最早只是他根据其多年的架构与咨询经验总结出的一个思想集合，包括 DevOps、持续交付、微服务、敏捷基础设施和 12 要素等几大主体。
现在着眼于云应用部署，其拥有着弹性、共享、自治、高可用、按需分配资源、可监控审计等优秀特点。
结合于云原生的各项优势，我们相信云原生即是未来。
在使用 K8s 之前，应用的部署以及管控对于开发者、运维来说繁琐且耗费精力，容器资源的分配、使用的情况在应用分部散乱的时候尤其难管理。
拥抱云原生，使用 K8s 后能方便业务解耦，分离部署，高可用，对于开发人员能极大提升开发效率。
在初期选型考虑过部署原生 K8s，使用原生 Dashboard，后来考虑学习成本过高，得不偿失，直到偶然的机会发现了 KubeShpere。
对于本人来说一直对于云原生都有向往，一眼相中了 KubeSphere 的 UI 界面，当然，还有更贴合开发的操作界面，在我认知方面 KubeSphere 之于 K8s 如同 Spring 之于 Java，开箱即用，即用即拿。
KubeSphere 对比于同类产品（Rancher 之类）的优势在于国人开发， 本地化程度更高，面向开发用户友好，多租户权限分配更细粒度，日志查询界面便捷，周边生态整合全面，模块可插拔，可灵活配置需要的模块。
我们当前将一部分 SaaS 产品运行于 KubeSphere 上，后续会考虑进一步迁移。
实践过程
KubeSphere 在相关业务的基础设施与部署架构介绍
我们依托于 kubeshere 部署 Harbor 私有镜像库，暂时使用手动上传 Jar 包构建镜像，未使用 CI/CD 流程，后续可能会自行构建流水线，采用 Helm 构建应用，更好贴合于 KubeSphere 应用市场。
在项目中，我们使用项目网关，服务只有 Gateway 模块通过 Ingress 暴露对外地址，前端使用 OpenResty 部署。
鉴于人员不多以及应用暂时仅对公司内部运行的情况，还未接入容器监控模块，后续可能会采用 Prometheus+Grafana 监控配置，以保证服务运行状态的可观测性，以及根据监控数据灵活的动态伸缩。
通过企业空间逻辑隔离出 pord 、dev 、test 环境，开发人员按部门以及项目进行授权。
搭建 Nacos
在 Mysql 中执行 Nacos 初始化 SQL。
选择新建自制应用。
本处使用 DockerHub 中的 Nacos 镜像，需要加入参数启动。
如若只添加这两个环境变量，则默认采用内置 derby 数据库，重启会导致数据清除，为了数据持久化，建议采用外置数据库。
- name: MODE
value: standalone
- name: PREFER_HOST_MODE
value: hostname
- name: SPRING_DATASOURCE_PLATFORM
value: mysql
- name: MYSQL_SERVICE_HOST
value: xxx.xxx.xxx.xxx
- name: MYSQL_SERVICE_DB_NAME
value: nacos
- name: MYSQL_SERVICE_PORT
value: '30576'
- name: MYSQL_SERVICE_USER
value: nacos
- name: MYSQL_SERVICE_PASSWORD
value: nacos
部署完毕后，登入 Nacos（此处使用路由解析了域名）
KubeSphere 自带底包运行应用远程调试
（使用第三方底包可以之家在启动命令处加入 java 启动命令来实现远程 Debug，此处示例 KubeSphere 自带 Java 底包）
在构建镜像，点击高级设置，可以对应添加调试参数，使用 Nodeport 对外暴露端口，即可以进行远程 Debug 应用。
KubeSphere 自带集群监控
与 KubeSphere 的契合点
在开发部署上，对内可针对于项目快速应用开发，部署运行环境、中间件，且借助于 KubeSphere 自带监控告警保证服务可用；对外产品演示时能灵活创建销毁容器，服务即用即拿。
考虑到 KubeSphere 无缝契合 K8s，其友好的操作界面，使得我们开发人员也能低成本的上手使用 K8s，享受其带来的便捷性。
由于我们当前使用物理机部署，在将来可能会接入公有云产品，所导致的资源连通问题是绕不开的话题，所以 KubeSphere 所推行的混合云也是吸引我们的一个点，借助于 KubeSphere 加速云上云下整合实现更好的资源共享。
对于一个良好的 K8s 载体，KubeSphere 的多租户特性这是原生 K8s 和其他同类产品都没有的功能。青云QingCloud 做了很多企业级特性增强的工作，对于多项目并行以及环境隔离来说简直是一剂良药，使得项目部署规划更加规整，并且 KubeSphere 的可观察性以及监控告警也是多租户的，可以细分开发人员更好的专注于自己所负责的模块。
落地成效
应用 KubeSphere 之后，和之前相比，开发人员生成镜像制品更加便捷、集群资源利用率提高、应用服务能灵活分配资源、环境隔离更加直观且易于管理、多租户权限配置能更大限度的防止误操作，后续可扩展性提升。
本文由博客一文多发平台 OpenWrite 发布！