关于kubesphere:无锡广电新媒体云原生容器化平台实践

作者：毛伟，现任无锡广电集团新媒体核心零碎架构师，曾负责全国多个省级、市级、区县融媒体平台设计建设，有着丰盛的新媒体行业建设零碎架构设计教训。现次要从事无锡博报系列新媒体平台建设，推动各业务产品线向云原生转型，并在此畛域发展相干布道工作。

单位简介

无锡广播电视团体成立于 1999 年，为全国首家广电集团。2007 年底组建成立无锡播送电视台（与无锡广播电视团体两块牌子、一套班子）。团体作为支流媒体和市属文化国企，承当宣传与经营双重职能：一方面为市委市政府核心工作和全市改革倒退稳固大局提供舆论服务，一方面通过放弃晋升经营效益，为宣传工作提供撑持，为全市文化产业倒退贡献力量。团体目前领有 6 个播送频率、7 个电视频道（其中 1 个公交、地铁挪动电视频道）、“无锡博报”领衔的新媒体矩阵。

背景介绍

作为国内最早提出媒体交融倒退理念，并付诸实践和不断创新的城市广电媒体之一，无锡广电早在 2012 年就开始布局挪动端策略并不断创新，在 2021 年将旗下两大客户端降级迭代全新的“无锡博报”客户端，并造成系列化的“博报”微信公众号、微博和视频号，组成流传力和影响力更强的新媒体矩阵。近期荣获国家广电总局 2022 年度“全国广播电视媒体交融先导单位”和“新时代 新品牌 新影响”等荣誉。

在长期的实际中，无锡广电逐渐摸索出适宜城市广电的媒体交融倒退思路和教训。以流传力建设为引领，对外踊跃打造新型流传体系，保持“挪动优先”策略，做大做强挪动端平台，霸占新兴流传阵地。以全网流传和本地经营需要为导向，继续推动外部组织架构、体制机制、业务流程、技术平台的再造和优化。推动“主力军全面挺进主战场”，将传统广播电视的团队和产能向新媒体端转移，打造具备城市媒体特色舆论主阵地。

这就要求无锡广电必须疾速适应一直变动的经营和市场需求，用高效、麻利的利用部署和运维对各类成几何式增长业务提供无力撑持。

在进行容器化革新前，无锡广电次要是采纳基于虚拟化技术的基础设施环境，每个业务利用依据各自的需要采纳独立虚机部署，随着工夫的积攒虚机规模变得越来越宏大、简单。架构有余日益凸显，具体如下：

• 在达到肯定规模下虚机操作系统自身须要占用的计算资源和存储资源较为节约。
• 长期积攒的老旧操作系统须要跟进保护降级，如：现存大量的 CentOS 零碎在官网进行保护后须要新的发行版本代替。
• 每个利用都须要独立保护和治理，使得部署和运维老本变得越来越高。
• 弹性伸缩的能力较差，部署工夫长。
• 短少测试环境，并且开发环境和生产环境不对立，利用更新依赖手工。
• 短少业务与资源利用率的监控，无奈提前发现潜在的问题。

这些问题导致运维效率绝对较低，无奈满足业务疾速迭代的需要。因而，无锡广电新媒体运维团队决定进行容器化革新，以晋升零碎的弹性、灵活性和可维护性，实现如下性能：

• 更高效的资源利用率：容器化技术能够实现共享操作系统内核，从而缩小每个利用所需的计算资源和存储资源。
• 更好的可维护性：通过应用容器编排工具，可更好地治理和保护容器，进步部署和运维效率，降低成本。
• 更高的弹性：容器化技术能够实现疾速部署和启动，实现疾速伸缩，从而更好地满足业务的变动需要。
• 更高的一致性：容器化技术能够保障开发环境、测试环境和生产环境的一致性，从而升高利用更新的危险。
• 更好的可观测性：通过分布式追踪、可视化的流量拓扑和监控，能够实现对节点到容器到业务资源监控和告警，及时发现、定位和解决问题。
• 更好的利用生命周期治理：通过集成利用商店和 DevOps 零碎及微服务治理等技术，能够使利用的公布治理更加麻利、弹性和可扩大。

为此，拥抱云原生曾经成为整个行业的趋势，能够帮忙降低成本、提高效率、加强竞争力。

选型布局

通过后期初步应用容器化及 Kubernetes 的积攒上，在决定全面转型容器化前咱们对将来整个 Kubernetes 的治理平台布局下面建设了联合本身的一些需要：

• 可能纳管多个 Kubernetes 集群，咱们会依据业务适配状况拆分多个集群，并且可在现有集群上装置。
• 可能从 Kubernetes 集群的部署、降级保护、治理的一体化集成，涵盖集群和利用的生命周期治理。
• 有 API 接口便于和自有 CI/CD 工具上的对接。
• 非 CentOS 零碎的兼容性（选型期间正推动去 CentOS 化）。
• 便于今后的集群降级，在集群部署上能完满适配 containerd 容器运行时。
• 部署后的集群靠近原生装置，以便于前期脱离工具自行保护集群。
• 有国内装置镜像，反对纯离线部署。

在选型期间咱们正好在布局部署自研业务的集群，在 CNCF 认证的 Kubernetes 部署工具中发现了 KubeSphere 和 Kubekey 这个解决方案，并在集群部署和生命周期治理方面进行了深度的测试，次要围绕上面一些维度：

通过测试，发现 KubeSphere+Kubekey 在各个方面都更加符合当初对治理平台的需要，为此采纳 KubeSphere+Kubekey 来搭建了自研业务（经营类为主）的一套 Kubernetes 集群以及治理平台。

实际过程

部署架构

基础设施以本人的机房虚拟化集群为根底，并应用虚拟机来构建 Kubernetes 集群。在集群布局方面，分为两个生产集群，别离用于内容生产业务和经营业务。对于内容生产业务集群，更重视稳定性，因而采纳了 1.21 版本。而对于经营业务集群，在谋求绝对稳固的根底上，还跟进了一些新版本个性，采纳了 1.23 版本。同时在经营业务集群会后行实际一些新版本的个性积攒教训，以便为未来降级内容生产业务集群打好根底。当然，无论是哪个集群，每次进行相应的降级和保护之前，都会创立一个长期的测试集群，以进行相干操作的测试和验证。

集群资源

这里以 1.23 版本的 K8s 集群为例，介绍下部署的环境。
资源清单：

全副服务器均采纳本地虚拟化平台的虚机形式提供。

对外业务裸露

为了实现 K8s 集群对外业务的拜访，应用了两台 OpenResty 服务器，并通过反向代理模式将流量散发到 K8s 集群中的各个工作节点的 Ingress NodePort 端口。为了保障高可用性对 OpenResty 服务器进行了双活部署。同时应用 OpenResty 实现了配置的热更新、限流和平安防护性能。此外，还在 OpenResty 上对立了全局的 SSL 证书治理，以简化在 K8s 集群中扩散部署 SSL 证书带来的治理复杂度。通过这些措施，可能更加高效地治理 Kubernetes 集群对外的业务拜访。

为了实现 K8s 集群治理的高可用性，应用 Keepalived 和 HAProxy 部署了 1 个高可用负载平衡服务，用来实现后端 3 台 master 节点 API server 的对外对立裸露。此外，也搭建了一套 dnsmasq 用于提供各个节点的 DNS 解析服务，以便于解析一些外部服务的域名。这样，能够确保 Kubernetes 集群的 API server 可能继续提供服务，并且外部服务的域名可能失去正确的解析。

存储实现计划

依据业务需要，需将较多传统的虚机业务迁徙到容器化环境下，因而对 K8s 集群的存储计划进行了深刻理解。指标是充分利用现有的硬件根底，同时尽可能简化架构并升高运维老本。因而，在底层存储方面，应用现有业余的硬件 NAS 存储和基于 vSphere 的 Cloud Native Storage（CNS），以应答不同的数据长久化场景。

为了解决多个 Deployment 同时读写的利用的存储问题，采纳了基于 nfs-subdir-external-provisioner 的 storageclass 存储类，或间接在 Pod 内挂载 nfs volumes 的模式。然而，咱们也意识到 NFS 存储在某些利用场景下可能不兼容并存在性能问题。因而，针对只须要 ReadWriteOnce 拜访类型且对性能要求较高的数据长久化场景，例如数据库和缓存，采纳了虚拟化环境自带的 vSphere 的 CNS 来实现 storageclass 存储类。这极大地简化了存储解决方案的复杂度。

可观测性计划

作为广电宣传利用对整个平台稳定性的要求较高，在日常的运维中对可观测性关注度较高，最后采纳了 Prometheus-operator 套件和 Grafana 进行集群资源监控，同时应用 Netdata 进行配合。对于利用日志方面，则采纳了 Loki、Promtail 和 Grafana 进行解决。但在利用中发现，这个计划在集群内利用治理方面的联合性不够强，存在一些应用上的割裂。在体验了 KubeSphere 提供的整体监控和日志计划后，果决决定切换到 KubeSphere 上。这样做解决了之前各个系统之间的割裂问题，实现了集群 + 利用的治理、监控和日志的一体化。

Devops 计划

在 Devops 方面，采纳了 GitLab CI/CD 的计划。研发只须要提交代码并打上 tag，GitLab 会主动生成相应的 jobs。而后，通过 GitLab Runner 运行相应的脚本，实现打包、镜像推送等操作，并通过特定的 tag 名称触发 API 批改线上利用的镜像 tag，从而实现主动部署。

利用成果

相较于以前的 Kubernetes 集群治理形式，应用 KubeSphere 后咱们实现了：

1. Kubernetes 集群部署和降级的方便快捷性

在利用 KubeSphere 后，不再须要手动装置和配置 Kubernetes 集群，因为 KubeSphere 提供了 KubeKey 工具实现了一键式的部署和降级性能，这使得能够疾速创立和治理集群。此外，KubeSphere 还提供了基于 Helm 和 Operator 的利用治理，能够更加不便地部署和治理利用。

2. 对多个 Kubernetes 集群的对立治理

在理论利用业务中，须要同时治理多个 Kubernetes 集群。在利用 KubeSphere 后，能够将多个 Kubernetes 集群对立治理，从而更加不便地进行操作和监控。此外，KubeSphere 还提供了集群间的利用镜像复制和调度，使得能够在多个集群之间灵便地部署利用。

3. 实现租户模式的企业空间访问控制治理和资源分配

在业务中须要对不同的用户和团队进行访问控制治理和资源分配。在利用 KubeSphere 后，能够通过创立租户来实现对企业空间的访问控制和资源分配，从而更加灵便地治理业务。

4. 集群和利用的日志、监控平台的对立

在之前，须要别离应用不同的日志和监控工具后盾来治理集群和利用。在利用 KubeSphere 后，咱们能够应用 KubeSphere 提供的对立日志和监控平台来治理集群和利用，能够更加不便地查看和剖析数据。

5. 简化了在利用治理方面的应用门槛

在咱们的业务中，利用治理是十分重要的一部分。在利用 KubeSphere 后，能够应用 KubeSphere 提供的利用治理组件，例如灰度公布和流量治理，来更加不便地治理利用。这样，能够升高利用治理的应用老本，提高效率。

将来布局

联合广电利用理论，在 KubeSphere 利用方面，有以下前期打算：

• 在测试中尝试应用 KubeSphere 灰度公布。
• 摸索应用 KubeSphere 的 DevOps 组件，将灰度公布与 CI/CD 流水线联合应用。
• 利用利用治理组件，实现业务 APM 的可观测性。

目前应用 KubeSphere 的过程中，发现与其余产品相比，KubeSphere 更重视于利用场景化和简化的治理后盾路线，这对于新人来说更加敌对。然而一些有根底的人员在接触初期阶段可能会感到后盾一些配置项与 Kubernetes 资源对应上存在一些手足无措，操作繁琐。另外，发现一些 Kubernetes 资源的配置目前还无奈在后盾齐全管制，须要通过手动编辑 YAML 来实现。因而，心愿在将来的版本中可能改良这些问题。