很榮幸受邀參加開源中國社區的高手問答，我是時速云團隊的后端工程師，負責主機管理功能開發。在互動過程中，發現大家在使用/調研kubernetes（簡稱k8s）過程中遇到了很多問題，這里我總結為幾點：

l 如何搭建

l 性能（包括網絡性能）

l 如何管理容器

l 容器如何對外提供服務

l K8s 與docker swarm對比

下面我們對這幾個方面分別說明。

如何搭建

kubernetes項目本身模塊化和功能分離做得很好，優點是插件支持度高、 適合多個模塊多人并行開發，缺點是部署困難。作為一個分布式系統和我們的特殊國情，部署問題排查更加困難。K8s官方提供了針對多個云平臺（和本地）的多個部署方案（猛戳這里），包括本地集群（Local Machine）、IaaS（GCE、AWS、AZURE）和許多自定義方式。部署方式優缺點對比參考下表，個人比較推薦Local (Docker-based)和Docker: Multi-Node。

本地集群（Local Machine） ，便于調試、省錢
Local (Docker-based)	優點：組件都運行在容器中，部署方便 缺點：gcr.io在墻外，可以替換成index.tenxcloud.com；slave不能通過https方式訪問master
Vagrant	優點：一鍵部署一個多節點集群；Mac用戶的福音 缺點：需要裝virtualbox
Local (No VM)	優點：可以使用自己編譯的etcd等組件，便于本地調試 缺點：依賴多、配置起來有些繁瑣
IaaS（GCE、AWS、AZURE），一鍵部署，爽快
GCE、AWS、AZURE	優點：一鍵部署，可以用于生產環境 缺點：只能用國外的機器，國內不能用；花錢多
自定義安裝 （為發騷而生，最符合天朝國情）
裸機（適配Linux發行版）Bare Metal	優點：組件定制，可以使用很多高級功能，可用于生產環境 缺點：配置繁瑣，容易出錯，樂趣無窮
容器化 Docker: Multi Node	優點：k8s組件均運行在容器中，可移植性好 缺點：gcr.io在墻外，可以換成index.tenxcloud.com

性能（包括網絡性能）

大家比較關注的性能問題這里分為兩個方面：調度性能和網絡性能。關于調度性能，Kubernetes博客上有一篇文章專門講解，這里會簡單說明一下；關于網絡性能，其實是網絡插件的性能，關鍵因子是network overlay-ed or not。

調度性能

官方給出的數據（猛戳鏈接）：目前單個kubernetes集群支持100個節點，每個節點30個pod，滿足兩條性能指標：

a. “API-responsiveness”：99%的API調用能夠在1秒內返回（list, get, update, patch, delete）

b. “Pod startup time”: 99%的pod能夠在5秒內啟動（鏡像提前下載好）

下面表格展示了集群pod飽和度分別在10%、25%、50%和100%時pod的啟動時間。

	10%-full	25%-full	50%-full	100%-full
50th percentile	0.90s	1.08s	1.33s	1.94s
90th percentile	1.29s	1.49s	1.72s	2.50s
99th percentile	1.59s	1.86s	2.56s	4.32s

想知道更多，到Kubernetes博客去看，墻略高，翻過去才能看。

網絡性能

Kubernetes自身不提供集群內節點組網互連的功能，目前有很多插件方案可以實現，最經典莫過于etcd/flannel組合，它在vxlan模式下性能也不錯。在CNUT大會上，浙大張磊分享了他的性能測試數據，這里直接貼出來（PPT鏈接第45頁）：

Qperf test	Flannel UDP	Flannel VxLAN	Weave	Socketplane	Native
TCP bandwidth	28.7 MB/s	47.8 MB/s	3.75 MB/s	42.8 MB/s	62.5 MB/s
TCP latency	200 μs	127 μs	384.4 μs	110.9 μs	96.1μs

這里對比Flannel（udp和vxlan）、Weave、Socketplane和Native網絡的性能，由于比較早，沒有考慮calico。Flannel udp和Weave是基于overlay network，性能損失比較大，Flannel vxlan、Socketplane與Native網絡性能差距不大。Calico是基于iptables和路由實現的，性能與flannel vxlan應該在一個級別上。

在網絡隔離上，calico提供了網絡隔離，但是docker 1.9開始內置網絡隔離，意味著下一個支持docker 1.9的kubernetes可能使用docker自帶的隔離，Calico的優勢也將不復存在，flannel仍然是主流。

如何管理容器

Kubernetes提供了命令行和Rest API兩種方式管理容器，分別為

1. 命令行工具 kubectl。windows、linux和MacOS上均可使用該工具，既可以管理本地集群，也可以操作遠程集群。查看使用方式猛搓這里。

2. Restful API。API目前有多種語言的版本，go語言版本包含在kubernetes代碼包中，由官方維護。Node.js版本最初由時速云CEO黃啟功實現并開源（Github node-kubernetes-client ）。其他語言版本的鏈接這里查看。

容器如何對外提供服務

在kubernetes集群中創建出的pod是集群內可見的，需要從外界訪問的話，可以通過kube-proxy、外部工具（nginx、haproxy等）甚至自己寫一套工具將服務暴露出來。我們將對這兩種方式分別說明。

Kube-proxy

在創建rc或pod以后，配置對應的service的ServiceType可以選擇是否暴露應用到外網、如何暴露。ServiceType的值可以是下面三種：

• ClusterIP：只使用集群內部IP。設置以后，服務將無法從外部訪問。
• NodePort：service有一個集群內部IP，同時也會把端口暴露到所在宿主機上。訪問時既可以通過內網ip:port訪問，也可以通過<NodeIP>:NodePort訪問。
• LoadBalancer：service有一個集群內部IP，同時將其暴露到宿主機上，而且會要求云服務提供商提供一個負載均衡器指向<NodeIP>:NodePort。

外部插件（Nginx、Haproxy）

通過修改nginx或haproxy的配置文件，將內網中的service暴露到主機上。

自定義

自己實現一套路由轉發工具，將service暴露到主機上

Kubernetes vs docker swarm

很多人問，kubernetes和docker swarm哪個棒，我可以心懷偏見地告訴你kubernetes綜合實力最棒。這里不談爹，只說設計理念、易用性和對微服務的支持。

為了不失偏頗，先說Docker swarm的優點。Docker swarm在分布式支持、微服務的設計上借鑒了很多kubernetes的理念和做法，同時避免了kubernetes的一些問題，在易用性和學習曲線上完爆kubernetes。

Docker swarm把集群當成一個超級機器，典型特征是對docker API的自然延伸，尤其便于docker用戶的理解。反過來，kubernetes把集群當成一個可調度的資源池，在物理層面對集群、節點、應用三個級別分別提供了API，應用在軟件層面上抽象成replication controller、service和pod的組合。這種設計提供了極大的靈活性和擴展性，一方面，使用kubernetes技術棧即可獲取完整的DevOps體驗、無比強大的微服務支持；另一方面，replication controller、service和pod的解耦，保證了應用的可定制化。這種超前的設計理念是Docker Swarm很難模仿和追隨的。

應用到工業生產中，如果你喜歡簡單方便，或者技術人員培養新技術的成本過高、周期過長，可以使用docker swarm；如果業務對彈性要求比較高，或者規模比較大，可以選用kubernetes。

最后打一段廣告。時速云是國內領先的容器云平臺和解決方案提供商，基于以Docker為代表的容器技術，為開發者和企業提供應用的鏡像構建、持續集成/交付、容器部署、運維管理的新一代云服務平臺。其中包括標準化、高可用的鏡像構建、存儲服務，大規模、可伸縮的容器托管服務，及自有主機集群混合云服務。時速云致力打造下一代以應用為中心的云計算平臺，幫助客戶優化開發運維環節，;提高業務效率，降低IT成本，實現持續創新。

本文轉自開源中國-Kubernetes與docker集群管理常見問題解析

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的Kubernetes与docker集群管理常见问题解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。