來源|阿里巴巴云原生公眾號

主筆 | 在德（阿里巴巴技術(shù)專家）、佳旭（阿里巴巴技術(shù)專家）
聯(lián)合作者 | 杭羽、照前、嶺峰、大猿

云原生被認為是云計算的重要發(fā)展趨勢，并且已經(jīng)成為數(shù)字新基建必不可少的一個組成部分。每年的阿里巴巴 雙11 都是考驗各種前沿技術(shù)的最佳“實戰(zhàn)場”，而今年云原生技術(shù)在 雙11 中的大規(guī)模應(yīng)用，充分證明了云原生技術(shù)的動力與前景。

本文會系統(tǒng)講解聚石塔在 2019 年 7 月份以阿里云容器服務(wù)為基礎(chǔ)設(shè)施，進行云原生實踐的探索和經(jīng)驗、帶來的價值與改變，及其在 雙11 中的應(yīng)用，希望對云原生化樹立可以借鑒使用的案例和樣板。

聚石塔業(yè)務(wù)背景與介紹

聚石塔最早上線于 2012 年，是阿里集團為應(yīng)對電商管理和信息化挑戰(zhàn)，幫助商家快速解決信息化建設(shè)與管理的瓶頸打造的一款開放電商云工作平臺。它的價值在于匯聚了整個阿里系的各方資源優(yōu)勢，包括阿里集團下各個子公司的平臺資源，如淘寶、天貓、阿里云等，通過資源共享與數(shù)據(jù)互通來創(chuàng)造無限的商業(yè)價值。

依托于聚石塔，各種業(yè)務(wù)類型（如 ERP、CRM、WMS 等業(yè)務(wù)）的服務(wù)商為淘寶、天貓等淘系的商家提供服務(wù)，服務(wù)商需要遵循聚石塔平臺的發(fā)布規(guī)則、數(shù)據(jù)安全、穩(wěn)定性建設(shè)等要求。這種關(guān)系決定了聚石塔平臺的技術(shù)和架構(gòu)，更直接決定服務(wù)商的技術(shù)演進方向和先進性。

聚石塔業(yè)務(wù)痛點

聚石塔承接的業(yè)務(wù)大類可以分為兩個部分：

• 傳統(tǒng)電商鏈路中，訂單服務(wù)鏈路上的系統(tǒng)：比如 ERP 系統(tǒng)，CRM 系統(tǒng)，WMS 系統(tǒng)。
• 電商行業(yè)中直接面向客戶的小程序場景，比如手淘與千牛客戶端的小程序業(yè)務(wù)。

綜合聚石塔的的業(yè)務(wù)類型，存在如下的業(yè)務(wù)痛點：

1. 標準化和穩(wěn)定性問題

對于訂單服務(wù)鏈路的系統(tǒng)而言，穩(wěn)定性永遠是最前面的“1”，一個系統(tǒng)抖動可能就會導致訂單履約鏈路中斷甚至造成資損以及客訴。穩(wěn)定性和標準化是不分家的，相信大家對此對有強烈的感受。而此類系統(tǒng)的開發(fā)語言不統(tǒng)一，有 Java、PHP、.Net 等；技術(shù)棧復雜，涉及 Windows 系統(tǒng)、Linux 系統(tǒng)、單體應(yīng)用、分布式應(yīng)用，可謂五花八門。因此需要一套跨語言、跨平臺的通用 PaaS 平臺來解決應(yīng)用的標準化、運維的標準化問題，并提供通用的鏈路問題觀測手段，來幫助服務(wù)商和平臺規(guī)范發(fā)布運維操作，發(fā)現(xiàn)鏈路問題，消除穩(wěn)定性隱患。

2. 突發(fā)流量下的彈性問題

對于應(yīng)用小程序的業(yè)務(wù)系統(tǒng)而言，最大的挑戰(zhàn)就是需要應(yīng)對突發(fā)流量以及流量的不確定性。尤其在 雙11 期間，手淘端各類小程序插件會面臨比平時多十倍甚至百倍的流量。面對這種不確定性的流量洪峰，聚石塔需要一套可以實現(xiàn)流量預估、流量觀測、流量控制以及標準應(yīng)用快速擴縮容的 PaaS 平臺。對于訂單服務(wù)鏈路的系統(tǒng)而言，彈性能力也是關(guān)鍵點，在原來的架構(gòu)下擴容需要經(jīng)歷創(chuàng)建虛擬機資源、部署并配置應(yīng)用等諸多環(huán)節(jié)，服務(wù)商普遍感覺流程長、效率低。以上我們都總結(jié)為彈性能力的挑戰(zhàn)。

3. 效率和成本的問題

聚石塔在云原生之前的應(yīng)用部署基本都是基于 VM 直接部署進程，這種方式缺乏進程間的資源隔離。同時當 ECS 數(shù)量變多，資源的統(tǒng)一管理就變得非常復雜，很容易造成資源爭搶導致應(yīng)用穩(wěn)定性問題以及資源浪費導致的多余成本開銷。同時，在傳統(tǒng)的 VM 部署模式中，應(yīng)用的擴縮容不僅僅需要處理應(yīng)用的代碼包啟動，還需要處理應(yīng)用的端口沖突，應(yīng)用所關(guān)聯(lián)的存儲資源分配，應(yīng)用流量在 SLB 的掛載和摘除，應(yīng)用配置的分發(fā)以及持久化，整個部署過程會變得非常耗時且容易出錯。

聚石塔云原生落地方案

針對上述的業(yè)務(wù)痛點，聚石塔開始探索技術(shù)演進方向以及系統(tǒng)性的解決方案，以便為淘系服務(wù)商帶來服務(wù)上質(zhì)的提升。云原生帶來的技術(shù)紅利，比如應(yīng)用環(huán)境標準化、DevOps 思想、彈性伸縮、跨語言的服務(wù)化能力以及運維自動化等，都不僅可以幫助聚石塔的服務(wù)商解決現(xiàn)存架構(gòu)中的穩(wěn)定性和成本問題，同時也可以幫助我們引導服務(wù)商實現(xiàn)技術(shù)架構(gòu)的升級。

因此，聚石塔進行了重新定位，主動擁抱云原生。整體來看，目前的聚石塔云原生技術(shù)底座基于阿里云容器服務(wù)，平臺目標是賦能服務(wù)商應(yīng)用架構(gòu)的穩(wěn)定性升級，打造基于云原生的、面向業(yè)務(wù)鏈接的 DevOps PaaS 平臺。

那么，為什么聚石塔會選擇阿里云容器服務(wù)作為云原生基礎(chǔ)設(shè)施呢？

阿里云容器服務(wù) ACK（Alibaba Cloud Container Service for Kubernetes）是全球首批通過 Kubernetes 一致性認證的服務(wù)平臺，提供高性能的容器應(yīng)用管理服務(wù)，支持企業(yè)級 Kubernetes 容器化應(yīng)用的生命周期管理。作為國內(nèi)云計算容器平臺的領(lǐng)軍者，從 2015 年上線后，一路伴隨并支撐 雙11 發(fā)展。

ACK 在阿里巴巴集團內(nèi)作為核心的容器化基礎(chǔ)設(shè)施，有豐富的應(yīng)用場景和經(jīng)驗積累，包括電商、實時音視頻、數(shù)據(jù)庫、消息中間件、人工智能等場景，支撐廣泛的內(nèi)外部客戶參加 雙11 活動；同時，容器服務(wù)將阿里巴巴內(nèi)部各種大規(guī)模場景的經(jīng)驗和能力融入產(chǎn)品，向公有云客戶開放，提升了更加豐富的功能和更加突出的穩(wěn)定性，容器服務(wù)連續(xù)多年保持國內(nèi)容器市場份額第一。

ACK 在今年 雙11 期間穩(wěn)如磐石，深度參與了 雙11 眾多領(lǐng)域的支撐：在阿里巴巴集團內(nèi)部支撐電商后臺系統(tǒng) ASI，在零售云支撐聚石塔，在物流云支撐菜鳥 CPAAS，在中間件云原生支撐 MSE，在邊緣云支持支撐 CDN 和邊緣計算，并首度支持了數(shù)據(jù)庫云原生化和釘釘音視頻云原生化。

在過去的一年，ACK 進行了積極的技術(shù)升級，升級紅利直接運用到了 雙11 中，進一步提升了 ACK 的技術(shù)競爭力和穩(wěn)定性，升級包括：高性能云原生容器網(wǎng)絡(luò) Terway 相比于社區(qū)社區(qū)提升 30%，高性能存儲 CSI 引入 BDF 等的支持支撐數(shù)據(jù)庫 5K 臺神龍主機對數(shù)十 PB 數(shù)據(jù)實現(xiàn)高效卷管理，極致彈性 ASK，Windows 容器等首次在 雙11 活動中參戰(zhàn)并應(yīng)用等等。規(guī)模化調(diào)度方面，ACK 高效穩(wěn)定的管理了國內(nèi)最大規(guī)模的數(shù)萬個容器集群，是國內(nèi)首個完成信通院大規(guī)模認證（1 萬節(jié)點、1 百萬 Pod）的廠商。規(guī)模化管理的技術(shù)和經(jīng)驗在 雙11 中支撐了全網(wǎng)客戶集群 APIServer 數(shù)十萬的峰值 QPS。

因此，聚石塔選擇 ACK 容器服務(wù)，不論是從技術(shù)角度，還是業(yè)務(wù)角度，是非常合理的，雙方的合作也是強強聯(lián)合、相互賦能、共同成長。

下面內(nèi)容會講到聚石塔如何使用云原生中的技術(shù)能力來解決實際的業(yè)務(wù)痛點和問題。

1. 應(yīng)用和發(fā)布標準化

聚石塔上聚集了上萬的開發(fā)者，但是不論規(guī)模還是技術(shù)能力都參差不齊。因此，聚石塔亟需為用戶提供一套可以屏蔽 Kubernetes 復雜性的、易用、靈活高效的發(fā)布系統(tǒng)，進而降低用戶使用 Kubernetes 的門檻，幫助用戶享用云原生的技術(shù)紅利，同時滿足作為管控方對于穩(wěn)定性的要求。為了應(yīng)對各種不同業(yè)務(wù)形態(tài)的差異化，聚石塔通過標準化來解決，設(shè)計了一套通用的應(yīng)用模型以及對應(yīng)的發(fā)布規(guī)范。

1）應(yīng)用模型

Kubernetes 的一個重要思想就是面向應(yīng)用的 DevOps，聚石塔 DevOps 平臺一開始就是以應(yīng)用為中心的 Paas 平臺，在應(yīng)用模型的設(shè)計上，整體的設(shè)計原則是讓開發(fā)者人員關(guān)注應(yīng)用本身，讓運維人員關(guān)注基礎(chǔ)設(shè)施運維，從而讓應(yīng)用管理和交付變得更輕松和可控。

同時，為了滿足客戶需求的多樣性，比如對于同一個應(yīng)用，SaaS 服務(wù)商為不同商家提供不同規(guī)模的應(yīng)用實例數(shù)量，或部署有差異性的代碼，聚石塔在應(yīng)用下支持了多環(huán)境，并支持對測試和正式環(huán)境的隔離。

2）發(fā)布

穩(wěn)定性的風險很大程度上來源于變更，Kubernetes 自帶的滾動發(fā)布，雖然標準化了發(fā)布環(huán)節(jié)，但在發(fā)布期間無法暫停，即使服務(wù)起來了，可能功能和業(yè)務(wù)存在問題，最終也會隨著滾動不斷擴大影響面；對此，聚石塔設(shè)計了支持暫停的分批發(fā)布，通過提前批的“金絲雀”驗證，從而提升系統(tǒng)的穩(wěn)定性。

以一個“無狀態(tài)”的應(yīng)用為例，主要實現(xiàn)原理是，通過控制兩個版本的 Deployment 的滾動，來做到可暫停和金絲雀驗證。

同時，相對于其他 Paas 平臺，聚石塔需要支撐更多的客戶應(yīng)用場景，還支持有狀態(tài)應(yīng)用（像 Zookeeper）以及守護進程應(yīng)用（比如日志采集）的分批發(fā)布，以滿足不同客戶基于成本和防鎖定層面的需求。

而對于有狀態(tài)應(yīng)用，主要原理則是通過控制 Kubernetes StatefulSet 的 Partition 分區(qū)來做到分批和暫停。

另外，對于守護進程應(yīng)用，則是通過對 DaemonSet 進行 Label 的調(diào)度來實現(xiàn)：

從而做到不同類型的應(yīng)用，得到統(tǒng)一的操作體感和變更穩(wěn)定性保障。

2. 彈性：ACK/ASK + HPA

隨著集群規(guī)模的增大，資源成本的消耗越發(fā)明顯，尤其對于流量波動較大的場景（例如電商場景），問題更加突出。用戶不可能一直把集群資源保持在高水位上，大多數(shù)情況下用戶都會把集群資源維持在足以應(yīng)對日常流量的規(guī)模，并稍微冗余一部分資源，在流量高峰在來臨前進行集群資源的擴容。

對于 Kubernetes 集群來說，啟動一個 Pod 是很快的，但是對于上述場景，啟動 Pod 前需要提前擴容 ECS，使之加入集群后，才能進行擴容，而擴容 ECS 則需要數(shù)分鐘的時間。

以上的彈性能力比較弱，操作繁瑣，耗時過長，無法及時響應(yīng)流量變化，并且依然會存在很多的資源浪費，消耗成本。

1）ACK/ASK?與?ECI

阿里云彈性容器實例（Elastic Container Instance），旨在用戶無需管理底層服務(wù)器，也無需關(guān)心運行過程中的容量規(guī)劃，只需要提供打包好的 Docker 鏡像，即可運行容器，并僅為容器實際運行消耗的資源付費。ECI 是 ACK 底層的一種資源形態(tài)，一個 ECI 可以看做一個 Pod，無需提前擴容 ECS，便可直接啟動。

ECI 的價格與同等規(guī)格按量付費的 ECS 價格相近，且為按秒付費，ECS 為小時級別。如果用戶僅需要使用 10 分鐘，理論上 ECI 的成本是使用 ECS 的 1/6。

如下圖所示，Kubernetes 集群通過 Virtual Node 使用 ECI，該技術(shù)來源于 Kubernetes 社區(qū)的 Virtual Kubelet 技術(shù)，無需提前規(guī)劃節(jié)點容量，不占用已購買的 ECS 資源。

2）聚石塔結(jié)合 ECI 與 HPA

為了帶給客戶更好的體驗，聚石塔基于阿里云 ACK/ASK，結(jié)合底層的 ECI 資源，以及原生 HPA 能力，為客戶帶來了更加靈活優(yōu)質(zhì)的彈性能力。

通過使用污點來控制一個應(yīng)用的某一個環(huán)境是否可是使用 ECI，并且會優(yōu)先使用集群中 ECS 資源，資源不足時才會使用 ECI，從而為用戶解決額外成本。

同時聚石塔提供了標準的 HPA 能力，以及 cronhpa 能力，幫助用戶實現(xiàn)根據(jù)指標的自動伸縮（例如根據(jù) CPU 的使用情況自動伸縮 Pod 數(shù)量），以及定時伸縮的能力。

并且通過兩者的結(jié)合，在流量動態(tài)變化的過程中，無需手動購買 ECS，以及手動擴容 Pod，實現(xiàn) 0 運維成本。

以上能力在今年 618 前開始小范圍推廣，完美通過了 618 以及 雙11 的考驗，用戶在 雙11 期間單個應(yīng)用使用 ECI 占比最高達到 90%，為用戶節(jié)約了一半的計算成本。在 雙11 期間 ECI 在電商業(yè)務(wù)場景下整體運行穩(wěn)定，平均彈升時間在 15s 以內(nèi)，相比 ECS 擴容至少需要 10 分鐘，大大減少了擴容的時間成本，保證業(yè)務(wù)應(yīng)對峰值流量的穩(wěn)定性。

3. 應(yīng)用監(jiān)控

在享受 Kubernetes 云原生技術(shù)帶來快速發(fā)布、彈性伸縮等便利的同時，如何做到可監(jiān)控可運維也是聚石塔的核心挑戰(zhàn)。一個合格的監(jiān)控系統(tǒng)需要具體準確性、實時性、可用性，提供分析和解決問題的洞察力。傳統(tǒng)的監(jiān)控方案，大部分是自頂向下的，配置一個監(jiān)控的任務(wù)、采集端點，應(yīng)用的生命周期與監(jiān)控任務(wù)生命周期一致，采集目標也是固定的，無論應(yīng)用如何重啟、變化，對于采集任務(wù)而言只要采集端點沒有變化，那么任何的變化都是生命周期中的正常現(xiàn)象。與傳統(tǒng)應(yīng)用相比，基于 Kubernetes 的云原生應(yīng)用容器實例是動態(tài)調(diào)度的、生命周期短，容器上層更是難以監(jiān)控的如 Deployment、負載均衡 Service 等抽象，此外，還需要底層 ECS 計算資源、實例生命周期、Kubernetes 集群自身以及集群核心組件的各個維度的監(jiān)控。基于上述考慮，聚石塔充分打通阿里云云原生監(jiān)控中間件產(chǎn)品，為聚石塔云應(yīng)用提供了分層一體化監(jiān)控解決方案。

以事件監(jiān)控為例，介紹下阿里云事件中心如何在聚石塔 PaaS 平臺落地。

事件中心

聚石塔借助阿里云日志服務(wù)提供的集群事件采集、索引、分析、告警等能力，將集群和云應(yīng)用上的各種事件進行監(jiān)控和告警。事件的范圍涵蓋所有 Kubernetes 原生 event、集群組件 event 以及其他各種定制的檢查。通常比較關(guān)心的是會影響云應(yīng)用正常運行的一些異常情況，比如 Node 節(jié)點不可用、資源不足、OOM 等，比如 Pod 實例容器重啟、驅(qū)逐、健康檢查失敗、啟動失敗等。PaaS 平臺上云應(yīng)用實踐過程。

• 用戶為集群一鍵安裝 NPD 組件，為集群和應(yīng)用分別配置告警規(guī)則，設(shè)置關(guān)注的事件類型和通知方式即可。
• 集群上所有事件自動采集到 SLS 日志服務(wù)，日志服務(wù)上的告警規(guī)則由我們根據(jù)事件類型和用途自動配置。
• 日志服務(wù)告警回調(diào)之后，由我們統(tǒng)一分析處理后進行消息推送。

事件監(jiān)控和告警功能，不僅能在日常幫助用戶排查和定位自身應(yīng)用問題，也為平臺對各個應(yīng)用的運行情況有較好的了解，從而制定個性化的優(yōu)化方案以及大促保障方案。此外，對于集群底層的組件，也可以通過配置相應(yīng)的規(guī)則進行告警通知，此次 雙11 大促，聚石塔為核心集群自動配置了集群 DNS 組件的告警，以便及時擴容或者切換更高可用的 DNS 方案，從而確保業(yè)務(wù)穩(wěn)定。

4. DNS?生產(chǎn)環(huán)境優(yōu)化實踐

由于聚石塔的用戶大多是電商或小程序的場景，流量波動明顯，并且開發(fā)語言多樣化，有些語言沒有很好的連接池，導致每一次請求都需要進行一次 DNS 解析。Kubernets 默認的 CoreDNS 在高并發(fā)時會遇到性能瓶頸，部分用戶在日常活動中，已經(jīng)遇到了 DNS 性能的問題，更不要說 雙11 期間，因此聚石塔對 DNS 的性能做了深入的優(yōu)化，確保 雙11 的穩(wěn)定性。

1）Node Local DNS

默認的 CoreDNS 方式是采用的 Deployment 方式部署的無狀態(tài)服務(wù)，集群中的 Pod，通過 service 對其進行訪問。通過上述流程可以看到，DNS 解析需要跨節(jié)點請求，性能不是很高，在高并發(fā)的場景下，容易達到瓶頸。

為了進一步提高性能，阿里云提供了 ack-node-local-dns。原理如下，通過 DaemonSet 的方式，將 DNS 解析的服務(wù)在每個節(jié)點上啟動一個實例，同時設(shè)置相應(yīng)的 轉(zhuǎn)發(fā)規(guī)則，將 Pod 發(fā)出的 DNS 的請求轉(zhuǎn)發(fā)到各自節(jié)點上對應(yīng)的 DNS 解析服務(wù)，從而避免了跨節(jié)點的訪問，很大程度上提高了性能。

聚石塔對該插件進行了相應(yīng)封裝，可以使用戶無感知的在兩種方式間進行切換。

2）Sidecar DNS

對于 ECI 的場景，由于不存在真實的宿主機，因此無法采用上述 Node Local DNS 的方案提高 DNS 性能，同時各個節(jié)點上的服務(wù)數(shù)量不同，并且不同應(yīng)用對的 dns 解析并發(fā)量的不同，在極端的場景下可能會出現(xiàn) DNS 解析并發(fā)量分布不均，從而導致部分節(jié)點上 DNS 解析出現(xiàn)問題。

基于以上場景，聚石塔結(jié)合 Kubernetes 提供的 sidecar 能力，提供了 sidecar dns。原理如下圖所示。

通過在 Pod 容器組中加入 DNS 解析服務(wù)容器。實現(xiàn)容器組中，其他容器所有的 DNS 解析請求均通過 sidecar dns 獲取。sidecar dns 可以看做是業(yè)務(wù)容器的緩存，只為自身所在的 Pod 提供服務(wù)，不會存在負載分配不均的問題，并且可以為 ECI 提供相應(yīng)的 dns 解決方案。

5. Windows 場景落地

全球范圍內(nèi)來看，Windows 的市場份額還不容小覷，在 StackOverflow 2020 最新的開發(fā)者調(diào)研中，在最受歡迎的的框架、開發(fā)包和工具中，.Net 的占比超過了 35%；在最受歡迎的編程語言中，C# 雖然有所下滑，仍保持在 30% 以上。隨著云原生的接受度越來越高，越來越多的傳統(tǒng)行業(yè)也對容器等云原生技術(shù)的呼聲越來越高，迫切需要更好的支持。

1）限制

Kubernetes 最先是在 1.14 版本 GA 實現(xiàn)了 Windows Server 2019 上進程容器的調(diào)度，隨著后面的不斷迭代，Windows 容器在調(diào)度、安全、網(wǎng)絡(luò)、存儲和鏡像管理等模塊上都有了很大的進步，正在慢慢對齊 Linux 容器的功能并盡最大努力保持對異構(gòu)容器管理的統(tǒng)一性。但我們還是能看到 Windows 容器有很多的限制，這種限制更多的是來自于操作系統(tǒng)層面的。

• 隔離不徹底

目前 Windows 容器的實現(xiàn)模式分為：“進程容器"和"Hyper-V 容器”。"進程容器"是通過任務(wù)名管理來模擬資源隔離的，所以這種隔離是不徹底的，最常見的限制就是沒法 OOM kill。而"Hyper-V 容器"是通過內(nèi)核隔離技術(shù)來實現(xiàn)，因此這種隔離是最徹底的。

Kubernetes 默認支持的是"進程容器"，其實說"只支持"都不為過，為什么呢？因為目前能支持"Hyper-V 容器"的運行時只有 Dokcer EE，而又受限于其實現(xiàn)，"Hyper-V 容器"不能支持 Multiple Container one Pod 的場景，再加上微軟把節(jié)點上可以跑"Hyper-V 容器"的數(shù)目也 License 化，這就極大的阻礙了"Hyper-V 容器"Kubernetes 化的進程。

• 升級難平滑

為了提高迭代效率，加速功能沉淀，微軟在 2017 年推出一種新的系統(tǒng)發(fā)布里程：“半年通道版”（Semi-Annual Channel）。相比于"長通道版"（Long-Term Servicing Channel），"半年通道版"是按照半年一次來進行 release 的，所 release 的內(nèi)核是完全兼容當前所支持的 "長通道版"的操作系統(tǒng)。比方說，Windows Server 1809 SAC，Windows Server 1903 SAC ，Windows Server 1909 SAC 等都屬于 Windows Server 2019 LTSC。

比起"長通道版"，顯然"半年通道版"來得更加敏捷高效，但是轉(zhuǎn)而來的是更復雜的升級管理。

• 嚴格內(nèi)核版本要求的"進程容器"：由于進程容器是通過任務(wù)名模擬的，這就導致了容器的 base 鏡像內(nèi)核版本必須等于節(jié)點內(nèi)核版本。換句話說，1903 SAC 的容器是沒法跑在 1809 SAC 的節(jié)點上，反之亦然。

• 有限兼容的"Hyper-V 容器"："Hyper-V 容器"的向后兼容是有限制的。比方說，在 2004 SAC 的容器上，通過 Hyper-V 技術(shù)創(chuàng)建的容器，只能兼容 2014 SAC，1909 SAC 和 1903 SAC，而無法運行 1809 SAC。

• 安全管理困境：當碰到安全補丁的時候，問題會變得更麻煩，除了節(jié)點要打安全補丁以外，容器也要重新re-package。詳情可以參看：https://support.microsoft.com/en-us/help/4542617/you-might-encounter-issues-when-using-windows-server-containers-with-t。

• 文件難管理

目前的 Windows 容器的文件管理比較 tricky。由于 Docker EE 只實現(xiàn)了主機目錄級別的掛載，這就導致 Windows 要讀寫某個文件的時候，必須把其整個目錄掛載進來。于此同時，由于主機的 ACL 管理不能被投影到容器內(nèi)，這就導致了 Windows 容器對文件的權(quán)限修改是不能被主機所接收的。

在 Secret 資源的管理上，在 Linux 上請求掛載的 Secret 資源會被暫存到內(nèi)存里面，但由于 Windows 不支持掛載內(nèi)存目錄，所以 Secret 資源的內(nèi)容會被放置在節(jié)點上。這就需要一些額外的機制來對 Secret 資源做控制。

2）展望

不過隨著這幾年的努力，我們正在迎來一個更加穩(wěn)定和成熟的 Kubernetes Windows 解決方案。

• 在運行層面，ContainerD 會加速替代 Docker EE。目前社區(qū)在 ContainerD 上集成了 HCS v2，實現(xiàn)了對單獨文件的掛載和容器優(yōu)雅退出的管理，在 v1.20 上將會實現(xiàn)對 GPU 和 GMSA 的支持。另外，我們也可以看到實現(xiàn)"Hyper-V 容器"和"特權(quán)容器"也已位列 roadmap。
• 在鏡像層面，微軟在努力的削薄基礎(chǔ)鏡像層，從 1809 SAC 到 2004 SAC，整個 Windows Server Core 減少了將近一半的大小，但是功能卻越來越豐富，這是讓人非常驚喜的。這也為后期的"Hyper-V 容器"打下來良好的基礎(chǔ)。
• 在功能層面，隨著 privileged proxy 模式的興起，很多之前沒法容器化運行的方案都找到了合適的解決方式。比方說，CSI Windows 的實現(xiàn)方案，就是借力于?https://github.com/kubernetes-csi/csi-proxy?的實現(xiàn)。
• 在運維層面，借助于 Kubernetes 的能力，完全可以打造一套 CICD 流來解決掉升級平滑的問題。

聚石塔上的傳統(tǒng)電商鏈路中，訂單類的各類 ERP、CRM、WMS 等系統(tǒng)，使用 Windows 技術(shù)棧開發(fā)的占了一半以上。如何幫助 Windows 場景下的系統(tǒng)進行云原生升級改造，對我們也是一個全新的挑戰(zhàn)。半年來，聚石與阿里云 ACK 技術(shù)團隊一起做了許多嘗試，使用阿里云 ACK 集群 + Windows 節(jié)點池作為底層基礎(chǔ)設(shè)施，聚石塔 PaaS 已經(jīng)能夠提供完整的發(fā)布部署、負載均衡、基礎(chǔ)監(jiān)控、擴縮容等功能。在今年的 雙11 大促中，已經(jīng)有不少客戶的系統(tǒng)運行在 Windows 容器之上，平穩(wěn)渡過 雙11 的業(yè)務(wù)高峰。

當然，Windows 場景下還有其他一些特性暫不支持，比如 NAS 共享存儲、日志采集、彈性伸縮、事件監(jiān)控等，雙11 之后，聚石塔與與阿里云 ACK 會繼續(xù)一起努力，為 Windows 容器的成熟和市場化貢獻更大的技術(shù)和業(yè)務(wù)價值。

云原生帶來的業(yè)務(wù)和技術(shù)價值

在正在進行中的 2020 年 雙11 大促中，聚石塔云應(yīng)用 PaaS 已經(jīng)落地開花，聚石塔的核心服務(wù)商的核心系統(tǒng)也基本完成了云原生化的改造。

在 雙11 第一波高峰中，構(gòu)建在阿里云 ACK 之上的聚石塔云原生規(guī)模達到了上萬核 CPU，上千個集群，承載 2 萬個 Pod。基于 Kubernetes，聚石塔 PaaS 封裝的應(yīng)用與運行環(huán)境的標準化，發(fā)布部署以及流量變更流程標準化已經(jīng)成為聚石塔服務(wù)商日常軟件交付流程中必不可少的一部分，通過這些努力聚石塔最大限度的減少了 雙11 期間不必要的應(yīng)用變更，將聚石塔的變更數(shù)量減少為日常的十分之一，保證線上系統(tǒng)穩(wěn)定性；同時我們推動聚石塔 PaaS 上的核心應(yīng)用完成了基于閾值（CPU，內(nèi)存，load）以及基于集群事件（比如 Pod 驅(qū)逐，節(jié)點不可用）的監(jiān)控告警，實現(xiàn)了線上問題先于客戶發(fā)現(xiàn)，及時解決止損；對于小程序的突發(fā)流量應(yīng)用場景，聚石塔在普通 Kubernetes 集群內(nèi)引入了 vnode 和 ECI 的技術(shù)，保證集群資源不足的情況下，可以實現(xiàn) Pod 的秒級快速應(yīng)急彈縮，應(yīng)對突發(fā)的流量洪峰。

云原生帶來的價值不止于此，基于聚石塔的用戶反饋，云應(yīng)用 PaaS 普遍給開發(fā)者帶來了 30% 以上的研發(fā)效能提升，應(yīng)用的擴縮容甚至實現(xiàn)了小時級到秒級的時間縮短；同時基于容器的運行環(huán)境以及計算資源標準化抽象，給大多數(shù)用戶帶來了 30% 以上的計算資源成本節(jié)約。基于云原生的架構(gòu)與運維規(guī)范也推動了服務(wù)商自身的軟件架構(gòu)升級，比如從單體應(yīng)用向分布式應(yīng)用的升級，從垂直擴縮的有狀態(tài)應(yīng)用向可橫向擴縮的無狀態(tài)應(yīng)用的升級。

云原生在電商垂直業(yè)務(wù)下的實踐才剛剛起航，后續(xù)聚石塔還將持續(xù)在云原生技術(shù)領(lǐng)域深耕，在應(yīng)用運維標準化 OAM，應(yīng)用鏈路的可觀測性，基于 Mesh 的應(yīng)用流量監(jiān)測和控制，基于業(yè)務(wù)指標的彈性伸縮，分布式應(yīng)用壓測與容災(zāi)等領(lǐng)域繼續(xù)探索，將云原生的技術(shù)價值賦能給客戶和業(yè)務(wù)，同時將電商垂直領(lǐng)域的云原生技術(shù)實踐反哺云原生社區(qū)。

總結(jié)

以上是生活随笔為你收集整理的「云原生上云」后的聚石塔是如何应对 双11 下大规模应用挑战的的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。