單位簡介
無錫廣播電視集團(tuán)成立于 1999 年，為全國首家廣電集團(tuán)。2007 年底組建成立無錫廣播電視臺（與無錫廣播電視集團(tuán)兩塊牌子、一套班子）。集團(tuán)作為主流媒體和市屬文化國企，承擔(dān)宣傳與經(jīng)營雙重職能：一方面為市委市政府中心工作和全市改革發(fā)展穩(wěn)定大局提供輿論服務(wù)，一方面通過保持提升經(jīng)營效益，為宣傳工作提供支撐，為全市文化產(chǎn)業(yè)發(fā)展貢獻(xiàn)力量。集團(tuán)目前擁有 6 個廣播頻率、7 個電視頻道（其中 1 個公交、地鐵移動電視頻道）、“無錫博報(bào)”領(lǐng)銜的新媒體矩陣。
背景介紹
作為國內(nèi)最早提出媒體融合發(fā)展理念，并付諸實(shí)踐和不斷創(chuàng)新的城市廣電媒體之一，無錫廣電早在 2012 年就開始布局移動端戰(zhàn)略并不斷創(chuàng)新，在 2021 年將旗下兩大客戶端升級迭代全新的“無錫博報(bào)”客戶端，并形成系列化的“博報(bào)”微信公眾號、微博和視頻號，組成傳播力和影響力更強(qiáng)的新媒體矩陣。近期榮獲國家廣電總局 2022 年度“全國廣播電視媒體融合先導(dǎo)單位”和“新時代 新品牌 新影響”等榮譽(yù)。
在長期的實(shí)踐中，無錫廣電逐步摸索出適合城市廣電的媒體融合發(fā)展思路和經(jīng)驗(yàn)。以傳播力建設(shè)為引領(lǐng)，對外積極打造新型傳播體系，堅(jiān)持“移動優(yōu)先”戰(zhàn)略，做大做強(qiáng)移動端平臺，占領(lǐng)新興傳播陣地。以全網(wǎng)傳播和本地運(yùn)營需求為導(dǎo)向，持續(xù)推動內(nèi)部組織架構(gòu)、體制機(jī)制、業(yè)務(wù)流程、技術(shù)平臺的再造和優(yōu)化。推動“主力軍全面挺進(jìn)主戰(zhàn)場”，將傳統(tǒng)廣播電視的團(tuán)隊(duì)和產(chǎn)能向新媒體端轉(zhuǎn)移，打造具有城市媒體特色輿論主陣地。
這就要求無錫廣電必須快速適應(yīng)不斷變化的運(yùn)營和市場需求，用高效、敏捷的應(yīng)用部署和運(yùn)維對各類成幾何式增長業(yè)務(wù)提供有力支撐。
在進(jìn)行容器化改造前，無錫廣電主要是采用基于虛擬化技術(shù)的基礎(chǔ)設(shè)施環(huán)境，每個業(yè)務(wù)應(yīng)用根據(jù)各自的需求采用獨(dú)立虛機(jī)部署，隨著時間的積累虛機(jī)規(guī)模變得越來越龐大、復(fù)雜。架構(gòu)不足日益凸顯，具體如下：
在達(dá)到一定規(guī)模下虛機(jī)操作系統(tǒng)本身需要占用的計(jì)算資源和存儲資源較為浪費(fèi)。
長期積累的老舊操作系統(tǒng)需要跟進(jìn)維護(hù)升級，如：現(xiàn)存大量的 CentOS 系統(tǒng)在官方停止維護(hù)后需要新的發(fā)行版本替代。
每個應(yīng)用都需要獨(dú)立維護(hù)和管理，使得部署和運(yùn)維成本變得越來越高。
彈性伸縮的能力較差，部署時間長。
缺少測試環(huán)境，并且開發(fā)環(huán)境和生產(chǎn)環(huán)境不統(tǒng)一，應(yīng)用更新依賴手工。
缺少業(yè)務(wù)與資源利用率的監(jiān)控，無法提前發(fā)現(xiàn)潛在的問題。
這些問題導(dǎo)致運(yùn)維效率相對較低，無法滿足業(yè)務(wù)快速迭代的需求。因此，無錫廣電新媒體運(yùn)維團(tuán)隊(duì)決定進(jìn)行容器化改造，以提升系統(tǒng)的彈性、靈活性和可維護(hù)性，實(shí)現(xiàn)如下功能：
更高效的資源利用率：容器化技術(shù)可以實(shí)現(xiàn)共享操作系統(tǒng)內(nèi)核，從而減少每個應(yīng)用所需的計(jì)算資源和存儲資源。
更好的可維護(hù)性：通過使用容器編排工具，可更好地管理和維護(hù)容器，提高部署和運(yùn)維效率，降低成本。
更高的彈性：容器化技術(shù)可以實(shí)現(xiàn)快速部署和啟動，實(shí)現(xiàn)快速伸縮，從而更好地滿足業(yè)務(wù)的變化需求。
更高的一致性：容器化技術(shù)可以保證開發(fā)環(huán)境、測試環(huán)境和生產(chǎn)環(huán)境的一致性，從而降低應(yīng)用更新的風(fēng)險(xiǎn)。
更好的可觀測性：通過分布式追蹤、可視化的流量拓?fù)浜捅O(jiān)控，可以實(shí)現(xiàn)對節(jié)點(diǎn)到容器到業(yè)務(wù)資源監(jiān)控和告警，及時發(fā)現(xiàn)、定位和解決問題。
更好的應(yīng)用生命周期管理：通過集成應(yīng)用商店和 DevOps 系統(tǒng)及微服務(wù)治理等技術(shù)，可以使應(yīng)用的發(fā)布管理更加敏捷、彈性和可擴(kuò)展。
為此，擁抱云原生已經(jīng)成為整個行業(yè)的趨勢，可以幫助降低成本、提高效率、增強(qiáng)競爭力。
選型規(guī)劃
通過前期初步使用容器化及 Kubernetes 的積累上，在決定全面轉(zhuǎn)型容器化前我們對未來整個 Kubernetes 的管理平臺規(guī)劃上面建立了結(jié)合自身的一些需求：
能夠納管多個 Kubernetes 集群，我們會根據(jù)業(yè)務(wù)適配情況拆分多個集群，并且可在現(xiàn)有集群上安裝。
能夠從 Kubernetes 集群的部署、升級維護(hù)、管理的一體化集成，涵蓋集群和應(yīng)用的生命周期管理。
有 API 接口便于和自有 CI/CD 工具上的對接。
非 CentOS 系統(tǒng)的兼容性（選型期間正推進(jìn)去 CentOS 化）。
便于今后的集群升級，在集群部署上能完美適配 containerd 容器運(yùn)行時。
部署后的集群接近原生安裝，以便于后期脫離工具自行維護(hù)集群。
有國內(nèi)安裝鏡像，支持純離線部署。
在選型期間我們正好在規(guī)劃部署自研業(yè)務(wù)的集群，在 CNCF 認(rèn)證的 Kubernetes 部署工具中發(fā)現(xiàn)了 KubeSphere 和 Kubekey 這個解決方案，并在集群部署和生命周期管理方面進(jìn)行了深度的測試，主要圍繞下面一些維度：
通過測試，發(fā)現(xiàn) KubeSphere+Kubekey 在各個方面都更加契合當(dāng)初對管理平臺的需求，為此采用 KubeSphere+Kubekey 來搭建了自研業(yè)務(wù)（運(yùn)營類為主）的一套 Kubernetes 集群以及管理平臺。
實(shí)踐過程
部署架構(gòu)
基礎(chǔ)設(shè)施以自己的機(jī)房虛擬化集群為基礎(chǔ)，并使用虛擬機(jī)來構(gòu)建 Kubernetes 集群。在集群規(guī)劃方面，分為兩個生產(chǎn)集群，分別用于內(nèi)容生產(chǎn)業(yè)務(wù)和運(yùn)營業(yè)務(wù)。對于內(nèi)容生產(chǎn)業(yè)務(wù)集群，更注重穩(wěn)定性，因此采用了 1.21 版本。而對于運(yùn)營業(yè)務(wù)集群，在追求相對穩(wěn)定的基礎(chǔ)上，還跟進(jìn)了一些新版本特性，采用了 1.23 版本。同時在運(yùn)營業(yè)務(wù)集群會先行實(shí)踐一些新版本的特性積累經(jīng)驗(yàn)，以便為將來升級內(nèi)容生產(chǎn)業(yè)務(wù)集群打好基礎(chǔ)。當(dāng)然，無論是哪個集群，每次進(jìn)行相應(yīng)的升級和維護(hù)之前，都會創(chuàng)建一個臨時的測試集群，以進(jìn)行相關(guān)操作的測試和驗(yàn)證。
對外業(yè)務(wù)暴露
為了實(shí)現(xiàn) K8s 集群對外業(yè)務(wù)的訪問，使用了兩臺 OpenResty 服務(wù)器，并通過反向代理模式將流量分發(fā)到 K8s 集群中的各個工作節(jié)點(diǎn)的 Ingress NodePort 端口。為了保證高可用性對 OpenResty 服務(wù)器進(jìn)行了雙活部署。同時使用 OpenResty 實(shí)現(xiàn)了配置的熱更新、限流和安全防護(hù)功能。此外，還在 OpenResty 上統(tǒng)一了全局的 SSL 證書管理，以簡化在 K8s 集群中分散部署 SSL 證書帶來的管理復(fù)雜度。通過這些措施，能夠更加高效地管理 Kubernetes 集群對外的業(yè)務(wù)訪問。
為了實(shí)現(xiàn) K8s 集群管理的高可用性，使用 Keepalived 和 HAProxy 部署了 1 個高可用負(fù)載均衡服務(wù)，用來實(shí)現(xiàn)后端 3 臺 master 節(jié)點(diǎn) API server 的對外統(tǒng)一暴露。此外，也搭建了一套 dnsmasq 用于提供各個節(jié)點(diǎn)的 DNS 解析服務(wù)，以便于解析一些內(nèi)部服務(wù)的域名。這樣，可以確保 Kubernetes 集群的 API server 能夠持續(xù)提供服務(wù)，并且內(nèi)部服務(wù)的域名能夠得到正確的解析。
存儲實(shí)現(xiàn)方案
根據(jù)業(yè)務(wù)需求，需將較多傳統(tǒng)的虛機(jī)業(yè)務(wù)遷移到容器化環(huán)境下，因此對 K8s 集群的存儲方案進(jìn)行了深入了解。目標(biāo)是充分利用現(xiàn)有的硬件基礎(chǔ)，同時盡可能簡化架構(gòu)并降低運(yùn)維成本。因此，在底層存儲方面，使用現(xiàn)有專業(yè)的硬件 NAS 存儲和基于 vSphere 的 Cloud Native Storage（CNS），以應(yīng)對不同的數(shù)據(jù)持久化場景。
為了解決多個 Deployment 同時讀寫的應(yīng)用的存儲問題，采用了基于 nfs-subdir-external-provisioner 的 storageclass 存儲類，或直接在 Pod 內(nèi)掛載 nfs volumes 的形式。然而，我們也意識到 NFS 存儲在某些應(yīng)用場景下可能不兼容并存在性能問題。因此，針對只需要 ReadWriteOnce 訪問類型且對性能要求較高的數(shù)據(jù)持久化場景，例如數(shù)據(jù)庫和緩存，采用了虛擬化環(huán)境自帶的 vSphere 的 CNS 來實(shí)現(xiàn) storageclass 存儲類。這極大地簡化了存儲解決方案的復(fù)雜度。
可觀測性方案
作為廣電宣傳應(yīng)用對整個平臺穩(wěn)定性的要求較高，在日常的運(yùn)維中對可觀測性關(guān)注度較高，最初采用了 Prometheus-operator 套件和 Grafana 進(jìn)行集群資源監(jiān)控，同時使用 Netdata 進(jìn)行配合。對于應(yīng)用日志方面，則采用了 Loki、Promtail 和 Grafana 進(jìn)行處理。但在應(yīng)用中發(fā)現(xiàn)，這個方案在集群內(nèi)應(yīng)用管理方面的結(jié)合性不夠強(qiáng)，存在一些使用上的割裂。在體驗(yàn)了 KubeSphere 提供的整體監(jiān)控和日志方案后，果斷決定切換到 KubeSphere 上。這樣做解決了之前各個系統(tǒng)之間的割裂問題，實(shí)現(xiàn)了集群+應(yīng)用的管理、監(jiān)控和日志的一體化。
DevOps 方案
在 DevOps 方面，采用了 GitLab CI/CD 的方案。研發(fā)只需要提交代碼并打上 tag，GitLab 會自動生成相應(yīng)的 jobs。然后，通過 GitLab Runner 運(yùn)行相應(yīng)的腳本，實(shí)現(xiàn)打包、鏡像推送等操作，并通過特定的 tag 名稱觸發(fā) API 修改線上應(yīng)用的鏡像 tag，從而實(shí)現(xiàn)自動部署。
應(yīng)用效果
相較于以前的 Kubernetes 集群管理方式，使用 KubeSphere 后我們實(shí)現(xiàn)了：
Kubernetes 集群部署和升級的方便快捷性
在應(yīng)用 KubeSphere 后，不再需要手動安裝和配置 Kubernetes 集群，因?yàn)?KubeSphere 提供了 KubeKey 工具實(shí)現(xiàn)了一鍵式的部署和升級功能，這使得可以快速創(chuàng)建和管理集群。此外，KubeSphere 還提供了基于 Helm 和 Operator 的應(yīng)用管理，可以更加方便地部署和管理應(yīng)用。
對多個 Kubernetes 集群的統(tǒng)一管理
在實(shí)際應(yīng)用業(yè)務(wù)中，需要同時管理多個 Kubernetes 集群。在應(yīng)用 KubeSphere 后，可以將多個 Kubernetes 集群統(tǒng)一管理，從而更加方便地進(jìn)行操作和監(jiān)控。此外，KubeSphere 還提供了集群間的應(yīng)用鏡像復(fù)制和調(diào)度，使得可以在多個集群之間靈活地部署應(yīng)用。
實(shí)現(xiàn)租戶形式的企業(yè)空間訪問控制管理和資源分配
在業(yè)務(wù)中需要對不同的用戶和團(tuán)隊(duì)進(jìn)行訪問控制管理和資源分配。在應(yīng)用 KubeSphere 后，可以通過創(chuàng)建租戶來實(shí)現(xiàn)對企業(yè)空間的訪問控制和資源分配，從而更加靈活地管理業(yè)務(wù)。
集群和應(yīng)用的日志、監(jiān)控平臺的統(tǒng)一
在之前，需要分別使用不同的日志和監(jiān)控工具后臺來管理集群和應(yīng)用。在應(yīng)用 KubeSphere 后，我們可以使用 KubeSphere 提供的統(tǒng)一日志和監(jiān)控平臺來管理集群和應(yīng)用，可以更加方便地查看和分析數(shù)據(jù)。
簡化了在應(yīng)用治理方面的使用門檻
在我們的業(yè)務(wù)中，應(yīng)用治理是非常重要的一部分。在應(yīng)用 KubeSphere 后，可以使用 KubeSphere 提供的應(yīng)用治理組件，例如灰度發(fā)布和流量管理，來更加方便地管理應(yīng)用。這樣，可以降低應(yīng)用治理的使用成本，提高效率。
