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