一、如何提升Kubernetes研發效率

本文將從三方面闡述如何提升Kubernetes研發效率：

微服務與CI開發（提升開發效率）

研發網絡與Kubernetes互通（提升調試效率）

服務端軟件管理平臺建設（提升運維效率）

微服務目前已成為主流的容器編排技術，然而不少開發者在使用過中或多或少會遇到一些問題，主要在于以下四點：

1）Kubernetes涉及較多專業知識，而研發掌握有關知識有一定的門檻。

2）Kubernetes鏡像常常沒有充分利用 Build Cache，導致占用構建存儲大，傳輸慢。

3）不同的業務其鏡像差異大，運維在對鏡像進行維護時操作過程非常復雜。

4）Kubernetes安全更新后，不僅要確保程序沒有漏洞，還要確保編程語言、基礎鏡像、業務本身都沒有安全漏洞。如果研發人員要維護全部的更新內容，負擔比較重，一定程度上會影響其研發效率。

開發一個新的微服務涉及諸多環節，比如Dockerfile的編寫、安全更新的維護、緩存層的設計，監控指標的接入等。而這些環節會出現一些問題，主要包括容器體系重復建設、安全更新需求需要在各個服務重復實現、Build Cache難以跨服務復用等。

為解決以上問題，我們采用了以下措施：

1）在容器體系統一建設的同時，做到允許自定義，降低門檻；

2）將鏡像統一為公用幾類（Node.js/Java/Golang），統一維護安全更新；

3） 跨服務共用Build Cache；

4） 統一置入工具鏈、依賴、ARM適配、監控指標等。這樣一來，對于ARM問題，在構建鏡像時，我們會先構建完X86，再構建統一的ARM。這些步驟都在統一的CI腳本中完成，從而節省時間。

在調試效率上，Kubernetes的痛點在于debug流程復雜耗時長，因為微服務通常需要依賴服務進行調試，但是開發機無法連接集群內Kubernetes Service 進行調試，且服務可能不位于流量入口位置，需要將中間環節的流量轉發。

怎么樣才能縮短debug流程，讓調試完的代碼能夠秒級生效呢？

來看上面左邊這張圖。左圖上半部分由開發機與DNS組成。下半部分是k8s集群，包含它的CoreDNS以及service B。為縮短調試流程，我們在開發區的網絡拓撲中部署了Nginx，用于把所有的 k8s cluster的域名解析到 k8s服務上。

比如我們統一取名為*.svc. cluster.local，并把它都統一解析到 k8s集群上，集群上我們調起Nginx，Nginx收到來自b.app.svc.cluster.local的請求后，直接向 k8s的CoreDNS去獲取它svc的cluster IP。獲取到IP后，它就可以知道，該項服務是 APP內service中的B服務，以及cluster的IP地址，然后Nginx便可以通過proxy pass進行轉發。這樣我們就實現了在開發機內任意地訪問開發網k8s內進行的服務的需求。

在運維效率上，Kubernetes的痛點主要來自以下四方面：

1）微服務化導致服務數量增加，需要將服務分組及模塊化管理，而這會增加管理成本。

2）每個服務都有各自的依賴，當我們想針對服務進行管理的時候，存在依賴管理的問題。

3）由于服務數量眾多，服務手工升級過程也耗時耗力。

4）在私有化部署背景下，我們很難直接將應用快速分發到客戶集群上。

為解決以上痛點，我們提出了Kubernetes APP平臺思路，并設計了如下技術架構。

架構圖由四部分組成：Helm、ChartMuseum、APP Installer Container、Kubeapps。Helm是包管理器，可以管理依賴，并提供鉤子機制，幫助實現模板化。ChartMuseum用于包存儲。APP Installer Container執行定制的APP結構規范、自動升級SQL Schema、自動導入Consul配置以及注冊網關入口及插件。Kubeapps方便UI管理。

要想提升運維效率，需要將運維管理維度從服務層面轉換成APP層面。為此，我們把相近的業務合并成一個統一的模塊去管理，降低管理復雜度。具體來看，每個服務生成一個helm包，包含自身標準化的SQL、Consul配置等，掛在Helm Hook上由定制化的Runner執行，并通過標準化SQL升級、Consul配置管理等，提升運維管理效率。

個推K8S最佳實踐解析

個推Kubernetes最佳實踐將從個推k8s集群概覽、使用規范制定、使用經驗總結三方面展開，以幫助開發者在Kubernetes使用過程中根據企業自身應用和環境特點找到適合的方案。

首先簡要介紹下我們的組件地圖與各組件的用途。如果用一把傘來比喻我們的組件地圖，那么傘的核心組件是Kubernetes，docker則是底層最基礎的運行環境，calico和fannel是網絡cni的選型；coreDns是k8s內部的域名解析組件；kube-stat-metrics是主要的監控組件，kube-stat-metrics主要用于采集pod的狀態; dashboard是運維管理工具；Harbor是企業級的鏡像倉庫開源解決方案；consul/Apollo是配置中心；Ingress用于提供負載均衡功能，是我們暴露集群外到集群內服務的http和https路由的方案之一。

為了更好地對k8s進行管理和維護，我們制定了詳細的k8s使用規范。在個推實踐中，規范主要分為五類：參數、安全、資源、日志、YAML。參數規范主要指的是對參數命名規則的規范。常見參數主要包含dns、ulimit、kubelet insufficient pods、calico、內核參數、xfs系統的d_type支持、label等。安全規范是面對網絡各信息安全相關的規范，主要包括業務線的隔離、資源的限制、訪問的控制以及PSP相關的設置；

資源類規范主要指的是資源可見性以及資源的控制與分配；日志規范是為了所有日志能夠被統一采集和管理所制定的 規范，比如日志格式、日志分類以及日志存放目錄規范；YAML的規范是為了保持線網環境以及測試環境的一致性，讓功能更加穩定、發布更加高效和安全而制定的一些列規范和標準。

規范標準化是一個持續的過程。我們通過學習、思考以及經驗汲取來制定執行和完善這個規范的過程，就是我們在不斷提高質量、提高管理水平、提高收益的過程，這也是k8s集群得以持續發展的原因。

在制定標準的過程中，我們踩過一些坑，以下將分享有關經驗供參考。

問題：

我們發現在service轉發過程中，流量負載并不均衡，導致單個pod請求壓力過高。

解決方案：

1）對邊緣節點進行了改造，在node上部署了nginx，upstream中的節點通過實時從consul中獲取服務的狀態和ip實時更新，以此繞過了service的流量分發，避免了流量負載不均的問題。k8s集群內部服務模塊之間的轉發也可以通過類似的方法予以實現。

2） 由于ingress抗壓能力強，故使用ingress也能實現流量負載均衡的需求，保證ingress到后端的流量是均衡的。

總之，k8s服務已經逐漸成熟，但也仍存在一些問題，需要我們開發者共同去解決這些問題，讓k8s生態發展更健康，讓工作更高效。

PPT獲取方式

關注【個推技術學院】微信公眾號

（微信號：getuitech）

回復關鍵詞“ k8s”

即可領取Kubernetes專場完整版嘉賓分享PPT！