事實證明，生成式AI在許多相對基礎的用例中已發揮作用，但是當它需要在技術方面給予更多指導時，表現又如何呢？

在推出ChatGPT時，我們也和大家一樣想將它給出的答案與常規網絡搜索得到的答案進行比較。我們進行實驗，詢問技術問題并要求它回答具體內容。并非所有的回答都有效或正確，但我們仍非常認可其提供反饋以改進回答的能力。

然后，我們向ChatGPT更具體地詢問有關使用 Kubernetes 的建議。它提供了一份在生產中使用Kubernetes的12項最佳實踐清單，其中大部分都是正確且相關的。但當被要求將該列表擴展到50項最佳實踐時，我們很快就發現，人類仍具有無可取代的價值。

我們如何使用 Kubernetes

JFrog在Kubernetes上運行其整體平臺已有六年多的時間，使用的是主流云提供商（包括AWS、Azure和GCP）提供的托管Kubernetes服務。我們在全球30多個地區開展業務，每個地區都有多個Kubernetes集群。在中國，許多公司都在使用Kubernetes和其他AI賦能的解決方案來加強運營并保持市場競爭力。

在JFrog的案例中，Kubernetes主要用于運行工作負載和運行時任務，而非存儲。JFrog采用云提供商提供的托管數據庫和對象存儲服務。Kubernetes基礎設施由數千個節點組成，節點數量可根據自動擴展配置進行動態擴展或縮減。

JFrog生產環境包括數十萬個Pod (Kubernetes中最小的部署單元)。確切數量會隨著Pod的創建或終止而變化；目前，約30萬個Pod在我們全球生產環境中運行，因此需要管理的工作負載量巨大。

我們經常發布新的應用程序版本、補丁和錯誤修復。我們實施一個內置系統來推出這些更新，包括在全面部署前進行適當的金絲雀（Canary）測試，以此保持連續的發布周期，并確保服務的穩定性。

大多數使用過該服務的人都知道，ChatGPT明確給出免責聲明，表明其所基于的數據并不完全是最新的。鑒于此，并考慮到上述背景之下的需求，在OpenAI更新其數據和算法之前，關于Kubernetes在生產中的現代化應用，以下十點是ChatGPT無法告知的：

1. 節點劃分是門藝術

節點劃分涉及在較小的節點（可減少 "爆炸半徑"）和較大的節點（可提高應用性能）之間找到平衡。關鍵在于根據工作負載要求（如CPU或內存優化）來使用不同的節點類型。調整容器資源，使其與節點的CPU與內存比率相匹配，可以優化資源利用率。

也就是說，考慮到每個應用程序或服務的資源消耗模式各不相同，找到每個節點上合適的Pod數量也是一項均衡工作。使用Pod拓撲分布約束或節點反親和性等技術在節點間分散負載以優化資源使用，有助于適應工作負載強度的變化。對于使用基于Kubernetes的云服務的大型企業，負載均衡和負載分發至關重要。

2. 保護Control Plane的重要性

監控Kubernetes Control Plane至關重要，尤其是在托管Kubernetes服務中。雖然云提供商能提供可靠的控制和均衡，但仍需要了解其局限性。應做好監控和警報，以確保Control Plane以最佳狀態運行。Control Plane運行緩慢會嚴重影響集群行為，包括調度、升級和擴展操作。即使是托管服務，也存在需要考慮的限制。

過度使用托管Control Plane可能會導致災難性的崩潰。許多人都經歷過這種情況，這也時刻提醒如果控制計劃沒有得到適當的監控和管理，它們就可能會不堪重負。

3. 如何維持應用程序正常運行時間

確定關鍵服務的優先級可優化應用程序的正常運行時間。Pod優先級和服務質量決定了需要始終運行的高優先級應用程序；了解優先級有助于優化穩定性和性能。

同時，Pod的反親和性可防止同一服務的多個副本部署在同一節點上。這就避免單點故障，意味著如果一個節點出現問題，其他副本不會受到影響。

還應采用為任務關鍵型應用程序創建專用節點池的方法。例如，為init Pod其他重要服務（如 Prometheus）創建單獨的節點池，可顯著提高服務的穩定性和最終用戶體驗。

4. 需要制定擴展計劃

是否準備好處理雙倍部署，以提供必要的容量增長，同時不帶來任何負面影響？托管服務中的集群自動擴容功能可提供幫助，但了解集群規模限制也很重要。對我們來說，典型的集群規模約為100個節點；如果達到這一限制，我們就會啟動另一個集群，而非勉強現有集群增長。

還應該考慮縱向和橫向的應用擴容。關鍵是要找到適當的平衡點，在不過度消耗的情況下更好地利用資源。一般來說，橫向擴容和復制工作負載更可取，但要注意其可能會影響數據庫連接和存儲。

5.要為失敗做好計劃

在應用基礎架構的各個方面，為故障做規劃已成為日常。需要開發能夠應對應用程序故障、節點故障和集群故障等不同故障情況的方案。實施高可用性應用程序Pod及Pod反親和性等策略有助于確保發生故障時的覆蓋范圍。

每個機構都需要針對集群故障制定詳細的災難恢復計劃，并定期進行演練。當從故障中恢復時，受控和漸進的部署有助于避免資源不堪重負。

6. 確保交付流水線安全

軟件供應鏈總是易受錯誤和惡意行為者的影響。因此需要控制流水線中的每一個步驟，避免在未仔細考慮外部工具和供應商可信度的情況下依賴它們。

為保持對外部資源的控制，需要采取一些措施，例如掃描來自遠程資源庫的二進制文件，并使用軟件成分分析（SCA）解決方案以對其進行驗證。團隊還應在整體流水線中應用質量和安全關卡，以確保用戶和流水線本身具有更高的可信度，從而保障交付軟件具有更高的質量。

7. 同時確保運行時間的安全

使用準入控制器來執行規則（例如阻止黑名單版本的部署）有助于確保運行時間的安全。OPA Gatekeeper 等工具有助于執行策略，如只允許受控的容器注冊表進行部署。

同時，建議使用基于角色的訪問控制來確保對Kubernetes集群的訪問安全，其他運行時間保護解決方案可以實時識別和處理風險。命名空間隔離和網絡策略有助于阻止橫向移動并保護命名空間內的工作負載。可以考慮在隔離節點上運行關鍵應用程序，以降低容器逃逸場景的風險。

8. 確保環境安全

確保環境安全意味著要假設網絡始終會受到攻占。建議采用審計工具來檢測群集和基礎設施中的可疑活動，以及具有全面可見性和工作負載控制功能的運行時間保護。

同類最佳的工具固然很好，但在出現警報或可疑活動時，還需要一個強大的事件響應團隊，并制定明確的操作手冊。與災難恢復類似，應定期進行演習和實踐。此外，由于外部視角和客觀研究能夠提供有價值的見解，許多機構還會利用漏洞賞金，或由外部研究人員嘗試入侵系統以發現漏洞。

9. 持續學習

隨著系統和流程的發展演進，需要通過收集歷史性能數據來評估并采取行動，從而大力開展持續學習。小規模的持續改進很常見；過去相關的內容可能現在已不再相關。

主動監控性能數據有助于發現某項服務中的內存或CPU泄漏，或第三方工具中的性能問題。通過積極評估數據的趨勢和異常，能夠提高對系統的理解和系統性能。相較于收到實時警報后再進行響應，這種主動監控和評估更具成效。

10.人工操作是最薄弱的環節

在可能的情況下，自動化能夠最大限度地減少人工參與，這對于提升安全是一種很好的方法，因為在安全方面，人工操作是最薄弱的環節。建議通過探索一系列可用的自動化解決方案，找到最適合的個性化流程和定義。

GitOps作為在將變更從開發階段引入生產階段時的一種的常用方法，為管理配置變更提供眾所周知的合約和界面。類似的方法是為不同類型的配置使用多個倉庫，盡管開發、登臺和生產環境之間應該彼此相似，但至關重要的是其必須明確分離。

展望未來

AI賦能的解決方案有助于降低運營的復雜性，并自動化執行與管理環境、部署和故障排除有關的任務，因此為未來帶來希望。即便如此，人類的判斷也是不可替代的，對此應始終予以考量。

如今，AI引擎依賴于公共知識，其中可能包含不準確、過時或不相關的信息，最終導致其給出錯誤的答案或建議。歸根結底，運用常識并牢記AI的局限性至關重要。