這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】本次分享主要以ZooKeeper、Redis、Kafka、MongoDB等應用程式容器化在Kubernetes平台上面實踐。從計算、網路、儲存方面解析應用在整合中的問題，以及部分傳統應用在容器化過程中設計的應用二次開發等問題。首先介紹應用Docker化的需求和局限、接著介紹基礎平台，整體環境包括Kubernetes和ECP，然後介紹具體應用如ZooKeeper在整合中的實踐，最後介紹部分開源應用在容器化過程中設計到的二次開發。
容器是一種輕量級的虛擬化技術，擁有持續整合、版本控制、可移植性、隔離性和安全性等優點，越來越多的應用跑在容器裡面。但也有其缺陷，並不是所有情境都適合如高效能運算，已經滿負荷啟動並執行應用沒有必要虛擬化，一些對IO等運行環境要求比較高應用不適合容器化如Oracle資料庫。
容器給應用程式提供了一個獨立的運行環境，並不是像虛擬機器那樣提供一套完整的作業系統，這是容器和虛擬機器最大的區別，所以在使用者在使用虛擬化如KVM、Vmware時候很少會擔心到應用能不能跑到虛擬機器裡面，通常只是針對虛擬化環境做效能調優，如KVM的CPU綁定、記憶體氣球以及巨型頁等。但應用Docker化更加複雜，除瞭解決虛擬機器存在的計算、儲存、網路以外問題，還需要解決Docker自身的問題，如：Docker相對與虛擬機器的脆弱性、應用程式依賴的系統調用在Docker中沒有做限制，還有Docker鏡像製作以及應用Docker化之後日誌和效能採集等問題。
Docker通過cgroup限制CPU和記憶體的使用，CPU限定通常是設定權重，並不能讓一個容器獲得確定1Ghz的CPU，當然你也可以使用cpuset綁定到指定的物理核上，記憶體使用量中不僅要設定記憶體大小還要限定交換分區的大小，這點很重要，譬如MongoDB在記憶體不足時大量使用交換分區。
Docker相對短暫的生命週期決定了不會使用持久儲存，容器掛了，儲存的資料也會相應的丟失。如果資料需要持久化如MySQL的DBData資料，則需要把資料輸出到外部的存放裝置上，可以通過掛載NFS或者GlusterFS或者AWS儲存等，在Kubernetes的PV的後端儲存已經可以支援上述檔案系統。使用者也可以根據不同儲存去實現Docker volume plugin，比較流行有Rancher/Convoy和Flocker，後者支援資料移轉，這為容器的遷移奠定了資料基礎。
容器應用之間相互依賴：Web應用訪問資料庫，API介面調用等，所以網路必須能夠互連並且支援多租戶隔離，當前Docker網路有兩大陣營，CNM和CNI。其中Calico可以算是腳踏兩隻船的，它可以與Kubernetes整合，相比Overlay網路在網路傳輸過程還是有明顯優勢的，如所示，減少了包封裝提高了網路傳輸和包處理效率。
Docker OVS SDN的方式達到容器和容器以及容器和主機之間的網路互連也是非常好的設計思想，通過實現Docker的Network Drivers介面將容器掛到OVS上，通過ryu、Floodlight或者OpenDaylight等SDN控制器動態下發流表的達到網路互連；再結合iptables實現網路隔離。如果想實現大二層跨機房網路互連，可以集合Vxlan等Overlay技術。
天雲skyform ECP平台是基於Kubernetes Calico的容器管理平台，具有日誌採集分析、效能監控、鏡像管理等一套完整的容器管理平台。上面介紹了Docker相關的一些相關知識，下面介紹具體的應用在Kubernetes平台上的整合。我把應用整合難度分三個等級：最容易是應用本身具有服務發現機制如Dubbo，天然的支援自動擴縮容，那麼在Kubernetes整合將會變的非常簡單；大部分應用屬於需要修改配置就能在容器裡面運行，最困難的是需要對應用進行二次開發或者對平台二次開發的應用。
ZooKeeper
ZooKeeper是一個高效能、高可用的分布式協調服務。整個ZooKeeper叢集的對外提供2181服務連接埠，節點之間資料同步和選主分別使用的2888和3888連接埠。每一個ZooKeeper節點都需要個其他節點通訊，所以都需要一個固定的IP地址，通過Kubernetes服務提供的虛IP（如果使用叢集內已經部署DNS則佈建網域名即可）互相通訊，結構如所示：
Yaml檔案如下
儲存使用nfs共用儲存，這樣ZooKeeper容器重建後就能恢複資料。
Kafka
Kafka是由LinkedIn開發的一個分布式的訊息系統，使用Scala編寫，它以可水平擴充和高吞吐率而被廣泛使用。目前越來越多的開源分散式處理系統如Cloudera、Apache Storm、Spark都支援與Kafka整合。整個結構圖如下所示：
Yaml檔案如下，這裡面有三個地方需要注意：
- 每一個Kafka的broker都有一個叢集內唯一的broker_id，所以不能把整個Kafka叢集放到一個RC裡面，而必須通過不同RC去分別定義每一個broker；
- Kafka依賴ZooKeeper，在這裡我們通過環境變數的方式將網域名稱傳遞到容器內；
- 這裡沒有配置Kafka的持久化儲存，因為每個Topic包含一個或多個partition，如果單個broker宕調不會影響叢集，並且當broker重建後會自動同步資料，速度非常快。
Redis
Redis是一個開源（BSD許可）的，記憶體中的資料結構儲存系統，它可以用作資料庫、緩衝和訊息中介軟體。Redis容器測試過程中，有幾點效能問題需要注意，第一是Redis最大記憶體，如果不設定可能會出現將記憶體耗盡的現象，第二是資料ttl時間設定以及清理keys策略，這些都是為了避免記憶體不足時使用交換分區導致效能下降，第三是資料持久化使用RBD，相對於較大檔案aof持久化，RBD更適合快照恢複。如果是業務量不大的情境可以使用redis主從結構，如所示：
Resis Master的Yaml檔案如下，其中為了資料的遷移恢複和重建使用Glusterfs儲存，當然你也可以換成其他儲存，單個主從叢集可能無法承載過多的請求，可以通過當前比較成熟的一個方案Twemproxy，通過代理實現資料分區，也能達到一個不錯的效果：
當前我們正在測試的是Redis 3.x的叢集功能，每一個Redis都是一個service（slave預設不接受讀寫，需要執行readonly才能讀），省去proxy代理提高效率。這個叢集方案通過redis-trib.rb的create子命令構建， 在用戶端配置所有service地址就可以操作叢集裡面的資料，但整個操作過程有兩個地方必須通過手工完成，尚待完善：
- 整個叢集建立redis-trib.rb是通過手動完成，沒有服務發現和自動化；
- 增加加點必須手動執行redis-trib.rb reshard分配slot。
MongoDB
MongoDB是由C 語言編寫的，是一個基於分布式檔案儲存體的開來源資料庫系統。MongoDB已經不推薦使用主從，叢集可以選擇複本集或者分區。展示的每一個MongoDB對外是一個service，組成複本集的叢集，類似mongodb這種對磁碟IO要求比較高的可以使用SSD加速，通過標籤選擇建立到有SSD機器上面提高效能。
如果是MongoDB的分區叢集，結構如下所示：
每一個configsvr佈建服務和Mongos路由服務都是通過service提供固定的提供者。mongos通過configsvr網域名稱配置。通過服務發現的指令碼動態配置將複本集轉成分區，這個分區的功能測試已經通過，但效能測試還在進行中。
上面一些應用都是通過容器外部傳遞配置參數或者啟動指令碼修改應用的配置，但有的應用通過這種方式是無法完成的，必須通過對應用或者對平台的改造才能完成，譬如IBM的任務調度平台OpenLava，它通過/proc/meminfo和/proc/cpuinfo擷取記憶體和CPU，Docker這部分通過是掛載的主機proc檔案系統，導致應用在容器內讀取是主機的CPU和記憶體，此時通過修改OpenLava代碼使其從/sys/fs/cgroup/cpu/cpu.shares 擷取CPU核心數從/sys/fs/cgroup/memory/memory.limit_in_byte擷取記憶體值，有的應用（多個pod）之間需要共用IPC，這部分功能Kubernetes是沒有的，需要通過平台改造去達到應用需求，還有應用需要根據IO去調度，這些都是我們ECP平台基於Kubernetes添加的功能。
Q&A
Q：請問在Kubernetes架構下 搭建分布式服務架構如Dubbo 需要將主機地址和暴露連接埠註冊到ZooKeeper上，這個主機地址和暴露的連接埠你們是怎麼處理的，即容器內的應用如何擷取Docker宿主機地址？
A：Dubbo服務不需要暴露主機的IP和地址，只需要知道容器地址即可。這些服務都是註冊到ZooKeeper上面，通過ZooKeeper完成服務發現，Kubernetes能夠根據暴露連接埠進行調度,當然有些應用要求容器能擷取到宿主機的IP地址，這塊我們對Kubernetes做了一些修改，可以動態注入諸如宿主機IP，宿主機主機名稱資訊到容器的環境變數中。
Q：ECP的定位和解決目標相比較目前大家在用傳統的雲平台解決方案來講下？
A：ECP產品定位是一套完整的容器解決方案，從容器生命週期管理，資源監控到日誌分析處理，相比與雲平台解決方案管理的對象不再是虛擬機器，而是容器，面向的對象是服務。
Q：關於容器本身的資源效能監控，是用的cAdvisor+Heapster嗎，如何能保持pod重啟（重啟後pod名稱變化）後的資料連續性，謝謝。
A：資源監控用的不是Heapster，ECP的資源監控是用cAdvisor+我們自己研發的採集Agent+Ceilometer+MongoDB+HBase等技術。複用了我們在做CMP產品時的技術，rc中的pod重建後會重新命名，這塊對於單一pod資料的連續性還沒有考慮，我們是把rc當做一個整體考慮的 。
Q：你們對外服務的負載平衡如何做的？是直接用Kubernetes的service嗎？
A：對外負載平衡現階段用的是Kubernetes的service，考慮到iptables帶來的效能損耗，後續我們會考慮使用別的方案，在叢集內部直接把流量轉寄到對於的pod上。
Q：請問Kubernetes容器和在其中啟動並執行應用程式監控是如何做的？能介紹下嗎？謝謝！
A：ECP的資源監控是用cAdvisor+我們自己研發的採集Agent+Ceilometer+MongoDB+HBase等技術。複用了我們在做CMP產品時的技術。簡單來說就是用cAdvisor採集未經處理資料，然後通過Ceilometer持久化，提供即時資料查詢、警示等功能。資料會定期轉存到hbase做曆史資料分析。
Q：請問，有基於Kubernetes的多租戶和使用者配額開源實現嘛？
A:現在開源的方案比較少，我們的ECP產品是結合Keystone實現的多租戶管理以及租戶的配額管理。
以上內容根據2016年8月9日晚群分享內容整理。分享人
陳曉宇，北京天雲融創軟體技術有限公司，研發工程師，多年雲端運算以及分布式系統開發經驗，對CloudStack、OpenStack等雲管理系統有深入瞭解。長期致力於應用Docker化、Docker叢集化方案的設計與研發。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：liyingjiesz，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。
