我是时速云团队的后端工程师，负责主机管理功能开发。在互动过程中，发现大家在使用/调研kubernetes（简称k8s）过程中遇到了很多问题。
- 如何搭建
- 性能（包括网络性能）
- 如何管理容器
- 容器如何对外提供服务
- 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。
京ICP备14045471号