去年8月底，百分點與雲知聲聯合釋出了Google開源的叢集管理系統Kubernetes的“發行版”——Sextant。在百分點大規模Kubernetes叢集經過四五個月的應用實踐後，到目前為止，叢集上已經承載了百分點推薦系統的大部分業務元件和部分的運維元件。那麼，在使用過程中會遇到哪些問題？如何解決？本篇將詳盡總結百分點在實踐中的經驗教訓，期望能夠更多地回饋社群。

從0到1

在傳統的叢集管理方法下，百分點伺服器利用率長期處於20%以下。通常為了完成某個業務目標，團隊會申請各自的伺服器，然後工程師使用跳板機登陸到這些伺服器上完成程式的部署。

這樣的弊端是：首先，這些伺服器上的空閒資源並不會貢獻出來為其他團隊所使用；其次，這些伺服器在解決業務高峰問題之後，負載下降，而這時團隊並不希望伺服器被回收，因為不知道如何備份伺服器之上的資料。

這樣，叢集伺服器利用率逐步降低，整體叢集的維護和管理也變得異常困難，在百分點AI技術運用增多的趨勢下，常遇到計算資源不足而導致業務進展緩慢的情況。

如何解決呢？

我們做了很多嘗試，最終決定選擇CoreOS、Kubernetes（以下簡稱K8s）、Ceph相結合的技術方案。

對於Kubernetes在生產環境中的應用，百分點是比較早的一批實踐者，從開始關注Kubernetes1.0，到將1.2版本實際部署到我們的生產環境中，圍繞Kubernetes做了很多周邊工作，使Kubernetes能夠更好地服務於業務場景。

限於篇幅原因，這裡不展開介紹Kubernetes的基本原理和概念了，感興趣的讀者可以在我們的githubsextant專案中，找到相當豐富的文件。

為了達成這樣的目標，我們要求開發者使用Docker將自己的應用程式完成封裝，逐步將手動的叢集部署，切換到使用K8S的叢集容器編排之上。如下圖所示，需要在團隊專案的gitlab repo中增加相應的Dockerfile和編排檔案內容，CI環境會自動將應用完成編譯->單元測試->docker映象打包->映象提交的工作。封裝在容器中的應用使用Ceph儲存資料，並通過ingress LoadBalancer對外部提供服務。

對於Kubernetes在生產環境上的部署，我們希望最大限度的簡化K8S叢集維護人員的工作。比如擴容一臺機器、下架維修一臺機器等，只需要維護人員直接完成開機／關機的操作即可。由於K8S的排程編排，可以遮蔽這類操作對應用的影響。

三步完成叢集安裝

首先要解決的問題，就是如何能夠高效的、自動化的進行元件的部署以減少手動部署可能帶來的問題。

百分點、雲知聲在百度科學家王益帶領下，合作開發了基於PXE自動化安裝CoreOS+Kubernetes叢集的開源Sextant專案，只需要簡單的三個步驟即可完成叢集的安裝：規劃叢集->啟動bootstrapper->節點開機自動安裝。

• PXE採用PXE的技術，從網路安裝CoreOS的作業系統，完成節點作業系統的初始化。

• cluster-desc.yaml是叢集的描述檔案，諸如作業系統型別、Flanneld網路模式、Kubernetes版本等都會配置在這個檔案中。對於每個待安裝的節點，需要根據MAC地址配置相應的角色，例如Kube-master，flanneld-master等。

• Bootstrapper是Sextant專案的核心服務，載入cluster-desc.yaml配置檔案，並提供web服務，根據節點的MAC地址生成相應的cloud-config.yaml檔案，從而安裝並啟動kubernetes相關元件。

操作順序：

• Step 0叢集規劃
  規劃叢集，將叢集資訊描述為cluster-desc.yaml配置檔案，例如作業系統的型別、etcd節點的數量、flanneld協議型別，哪些節點作為master等等。

• Step 1編譯、執行bootstrapper
  通過上一步驟的cluster-desc.yaml檔案，編譯bootstrapper的docker image並啟動，bootstrapper會提供PXE、DHCP、DNS以及Docker Registry等服務。

• Step 2安裝kubernetes節點
  將伺服器接入叢集，開機並從網路引導安裝，即可自動完成CoreOS以及K8s元件的安裝過程。

下一步就是應用遷移，在收穫中也充滿了痛。

收穫和痛

至此，我們自認為可以開始像習大大元旦助詞說的那樣“擼起袖子”，進行逐步的遷移工作了。但經過簡單的效能測試後，結果並不理想。執行在K8S之上的服務響應延遲，導致出現至少20%的效能損耗。在踩坑之後，我們對K8S的網路有了更加深入的理解。

一、打造kubernetes高效能網路

熟悉Docker的讀者可能會了解到，Docker容器有三種網路模式，但為了達到容器內的網路環境隔離，通常會選擇使用NAT方式完成容器內的網路包轉換和轉發。這樣，在同一臺主機上啟動的容器或不同主機啟動的容器之間，除了配置NAT埠的4層地址可訪問外，都不可以直接互相訪問。

Kubernetes的解決思路和Bridged模式的虛擬機器群很像——用一個通用的IP地址分配服務，為執行在各個host上的container統一分配IP地址。這樣執行在不同host上的containers之間通訊，直接使用對方的container IP地址就可以了，而不需要考慮host IP。這實際上把Docker模式中的host IP和containerIP這兩層IP地址變成了一層。

在Kubernetes的文件裡闡述了一個叫Pod的概念，並且解釋一個Pod裡可以執行一個或者多個Docker containers。實際上，一個Pod就是一個Docker container。所謂在Pod裡執行的多個containers，實際上是啟動的時候加了–net=container:引數的containers，它們不會得到自己的IP地址，而是和pod container共享IP地址。這樣一來，一個pod裡的containers之間通訊的時候可以用localhost地址，而跨越pod的通訊用pod IP。 看上去Kubernetes的做法裡相對於Docker的做法，多了一層Pod的概念。

但是實際上每個container里約定俗成地只執行一個服務程序，所以還是三層概念：

• 節點（node）
• Pod
• Container

Kubernetes實現這種網路結構有多種方法，如overlay networking、BGP和其他SDN技術，常見的實現包括：Flannel、 Calico、 L2 networking、OpenVSwitch等，我們對常用並活躍的專案進行了針對性評測，結論如下：

可以看到，在L2模式下，針對高效能web應用場景可以達到最佳效能。當然如果有專用的SDN交換機裝置，也可以大大提高SDN的網路效能。但綜合成本、方案複雜程度、方案後續可擴充套件性考慮，最終選擇flannel host-gw模式。這個模式，要求所有host保持穩定的2層網路連線，然後通過Linux路由表，將Docker bridge的包完成3層轉發。

另外一點，在評測過程中發現，linux加在netfilter和iptables相關核心模組之後，平均網路延遲會下降10%左右。但就目前狀態來說，使用iptables NAT作為Kubernetes的service負載均衡仍然是效能最高、最簡單的方式。後續如果可以使用更優秀的方法提供service負載均衡，可以去掉iptables以降低容器之間的網路延遲。

在這種網路部署下，使用普通的千兆網絡卡和千兆交換機，即可以較低成本來搭建大規模的叢集，並獲得相對可觀的效能。在針對網路延遲有更高要求的服務，比如Redis等，則考慮直接物理部署作為折中方案。

二、打造高可用的前端負載均衡器

從上面的介紹可以看出，Kubernetes service主要仍是針對資料中心內部互相訪問，若要方便地提供HTTP web服務的建立，則需要引入Ingress的概念。

眾所周知的是，Kubernetes中的Service可以將一組pod提供的服務暴露出來供外部使用，並預設使用iptables的方式提供負載均衡的能力。Service通過使用iptables，在每個主機上根據Kubernetes service定義，自動同步NAT表，將請求均衡的轉發到後端pod上，並在pod故障時自動更新NAT表。相對於使用userspace方式直接轉發流量有更高的效率。常用的Service有ClusterIP、Loadbalancer以及NodePort方式。

• ClusterIP是通過每個節點的kuber-proxy程序修改本地的iptables，使用DNAT的方式將ClusterIP轉換為實際的endpoint地址。

• NodePort是為了Kubernetes叢集外部的應用方便訪問kubernetes的服務而提供的一種方案，它會在每個機器上。

• 由於NAT效能的問題，NodePort會帶來一定的效能損失，在一些場景下，我們也會選用Loadbalancer作為k8s叢集外部應用訪問K8s叢集內部應用的統一入口。百分點採用的Loadbalancer負載均衡器是基於haproxy，通過watcher Kubernetes-apiserver中service以及endpoint資訊，動態修改haproxy轉發規則來實現的。

從上面的介紹可以看出，Kubernetes service仍是主要針對資料中心內部互相訪問，若要方便地提供HTTP web服務的建立，則需要引入Ingress的概念。

1.Ingress

對於對外提供服務的web應用來說，需要提供7層反向代理的機制，使得公網的流量可以轉入叢集之中。百分點採用的是Nginx，通過WatcherKubernetes中Ingress資源資訊，動態修改對應的service匹配endpoint的地址，使得整個配置流程只需通過kubctl提交一個配置即可。Ingress作為資料中心web請求的入口，將流量引入到叢集內部，完成處理後經由Ingress返回外部請求者。這樣一來，任何一個部署在kubernetes上的web應用，都可以簡單的通過提交一個Ingress資源，完成web請求對外的開通。

2.Ingress HA

Ingress的機器是整個叢集的入口，如果其中一臺機器出現故障，帶來的影響將會是致命的。我們也曾考慮過使用F5等技術做前端的高可用，但最後基於成本和可維護性考慮，最終使用Keepalived+vip的方案。

3.Ingress優化

• 效能優化
  由於NginxIngress Controller要監聽物理機上的80埠，我們最初的做法是給他配置了hosrtport，但當大量業務上線時，我們發現QPS超過500/s就會出現無法轉發資料包的情況。經過排查發現，系統軟中斷佔用的CPU特別高，hostport會使用iptables進行資料包的轉發，後來將Ingress Controller修改為hostnetwork模式，直接使用Docker的host模式，效能得到提升，QPS可以達到5k以上。

• Nginx配置優化
  Nginx IngressController大致的工作流程是先通過監聽Service、Ingress等資源的變化然後根據Service、Ingress的資訊以及nginx.temple檔案，將每個service對應的endpoint填入模板中生成最終的Nginx配置。但是很多情況下模板中預設的配置引數並不滿足我們的需求，這時需要通過kubernetes中ConfigMap機制基於Nginx Ingress Controller使用我們定製化的模板。

• 日誌回滾
  預設情況下Docker會將日誌記錄在系統的/var/lib/docker/container/xxxx下面的檔案裡，但是前端日誌量是非常大的，很容易就會將系統盤寫滿，通過配置ConfigMap的方式，可以將日誌目錄改到主機上，通過配置logrotate服務可以實現日誌的定時回滾、壓縮等操作。

• 服務應急
  當線上服務出現不可用的情況時，我們會準備一套應急的服務作為備用，一但服務出現問題，我們可以將流量切換到應急的服務上去。在k8s上，這一系列操作變得更加簡單，這需再準備一套ingress規則，將生產環境的Servuce改為應急的Service，切換的時候通過kubectl replace -f xxx.yaml 將相應的Ingress替換，即可實現服務的無感知切換。

三、打造一體化Kubernetes叢集服務

作為一個叢集化的作業系統，基礎服務必不可少，開發者通常需要經常檢視服務的日誌，檢視監控資料，檢視執行狀態等。我們為Kubernetes叢集配置了很多基礎類服務，使叢集使用起來更加高效。

1.日誌管理

當我們的應用執行在叢集作業系統上時，如何高效地檢視、分析服務日誌是一個必須要解決的問題。百分點採用了Fluented+Elasticsearch+Kibana的方案，整個套件也都是執行在Kubernetes叢集上的。

• Fluentd
  Fluented是使用Kubernetes中Daemonset的機制，使得fluented啟動在每一個節點上，並自動採集Docker Container的日誌到ES叢集中。

• Elasticsearch
  ES自帶的Discovery機制並不能在kubernetes中完美的執行，這裡使用kubernetes的外掛，使其他通過Service的方式使master節點能夠自動發現client和data節點的endpoint地址，組成叢集。ES中資料節點的儲存是放在Ceph叢集中的，保證了資料可靠性。

• Kibana
  Kibana中能夠根據使用者自定義篩選、聚合，方便使用者查詢使用。

2 . 系統監控

通過heapster+collectd+influxdb+grafana解決多源資料採集、監控資料儲存、查詢展現的問題。

• heapster負責從cAdvisor中採集宿主機以及container中的監控資料並寫入influxdb中。
  
  • collectd負責採集類似nginx元件的監控資料寫入influxdb中。
  • influxdb負責按時間序列儲存監控資料，並且支援類SQL的語法來訪問資料 。
  • grafana提供了WebUI，通過使用者自定義的查詢規則，生成SQL語句來查詢influxdb中的資料，並最終以圖表的形式展現給使用者。

3.統一Dashboard
為了簡化kubernetes叢集的使用，百分點的技術團隊開發了Sirius系統，使使用者使用起來更加的方便，並且此專案也在Github上進行了開源。

4.持續化整合

Docker是我們落地Devops理念的核心技術，從開發人員寫下第一行程式碼開始，我們構建了這樣一條持續整合的流水線。

我們選擇了Gitlab作為程式碼倉庫，當開發人員向Gitlab提交程式碼，Jenkins會監聽每個tag，每次push事件，有選擇的自動構建為docker image，並推向Docker Registry，儲存在我們的Docker倉庫中。隨後，Jenkins會將新版本的映象推到整合測試的Kubernetes叢集中，完成一次構建、測試、預上線的流程。待測試通過後，再發布到生產環境。

5.持續化部署

在逐步將線上應用遷移到kubernetes叢集過程中，當然也遇到不少問題，每個應用在提交之後需要經過多次修改和更新才可以正式上線，為了方便更新、並儘量減少人為操作的失誤，我們使用“編排檔案版本管理+kubernetes deployment”完成持續化部署。

• 什麼是Deployment？
  Deployment描述了待部署Pod的狀態，只需要定義我們期望的一組Pod的狀態，kube-controller會幫助我們在叢集上維持這一狀態，並且可以很方便地在上面做roll-out和roll-back。

• 如何更新Deployment?
  直接使用kubectl editdeployment/{your deployment}即可對相應deployment進行修改。並且可以指定最大不可用的Pod個數來控制滾動更新的進度。每次執行edit命令之後，就會觸發deployment的rolling update，應用會在後臺完成逐個平滑升級。

• 持續部署
  在每個應用的程式碼倉庫中，會增加一個.kube的目錄，下面存放本應用的yaml編排檔案，每次部署升級都直接使用對應版本的編排檔案即可完成部署。

四、打造統一持久化儲存平臺

Kubernetes在執行時是基於容器技術的，這就意味著容器的停止會銷燬容器中的資料。若應用要使用持久化的儲存，如果直接掛在容器所在主機的磁碟目錄，這個編排系統會顯得十分混亂。雖然Kubernetes提供了諸如hostPath機制，除非應用和主機具有非常明確的繫結關係，否則不推薦使用。這樣，我們需要一個通過網路可訪問的儲存池，作為統一的叢集儲存平臺。選型的問題這裡不詳細展開，我們最中使用ceph作為Kubernetes的後端儲存。

在部署時，考慮到kubernetes編排的網路請求可能和ceph的資料儲存請求搶佔網絡卡頻寬而導致整體叢集癱瘓，預先將kubernetes訪問ceph叢集的網路使用單獨的兩個網口做bond0之後連線ceph叢集的交換機。同時為了防止多個容器突發性的高IOPS對ceph叢集的訪問，我們正在開發storage-iops的qos限制功能。

雖然ceph提供了3種儲存訪問的方式，我們還是選用了相對穩定的rbd，沒有使用ceph filesystem模式。在rbd模式下，首先要保證核心已經加在了rbd.ko核心模組，和ceph-common包。這一步，我們在前面提到的sextant自動安裝系統中已經完成打包。

接下來在使用rbd作為pod儲存時可以參考示例：

{
     "apiVersion": "v1beta3",
     "id": "rbdpd2",
     "kind": "Pod",
     "metadata": {
         "name": "rbd2"
     },
     "spec": {
         "containers": [
             {
                 "name":  "rbd-rw",
                 "image":  "kubernetes/pause",
                 "volumeMounts": [
                     {
                          "mountPath": "/mnt/rbd",
                          "name": "rbdpd"
                     }
                 ]
             }
         ],
         "volumes": [
             {
                 "name":  "rbdpd",
                 "rbd": {
                      "monitors": [
                                                           "192.168.0.1:6789"
                                   ],
                      "pool": "rbd",
                      "image": "foo",
                      "user": "admin",
                      "secretRef": {
                                                     "name": "ceph-secret"
                                           },
                      "fsType": "ext4",
                      "readOnly": true
                 }
             }
         ]
     }
}

目前，我們已經使用kubernetes+ceph rbd部署使用了MySQL、MongoDB、Redis、InfluxDB、ElasticSearch等服務和應用。

百分點實踐總結

到目前為止，百分點的Kubernetes叢集上承載了推薦系統的大部分業務元件和部分的運維元件。Kubernetes相對來說還比較新，叢集上也需要更多的工具才能讓使用者應用起來更加的方便。非常感謝Kubernetes社群、王益以及雲知聲公司的技術團隊，百分點會持續專注在Kubernetes的建設，期望能夠更多地回饋社群。

作者： 閆旭、武毅

責編：魏偉，報道和投稿請加聯絡郵箱[email protected],另外，歡迎加入CSDN 容器技術交流群，和大牛侃技術，搜尋微訊號“k15751091376”，備註姓名、公司和職位。