Kubernetes与docker集群管理常见问题解析

很荣幸受邀参加开源中国社区的高手问答，我是时速云团队的后端工程师，负责主机管理功能开发。在互动过程中，发现大家在使用/调研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成本，实现持续创新。