【Kubernetes与容器集群管理】–Oschina第107期高手问答总结

作者:赵帅龙

我是时速云团队的后端工程师,负责主机管理功能开发。在互动过程中,发现大家在使用/调研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。

 

暂无评论

发表评论