Docker&Kubernetes技术沙龙第二期精彩回顾~

活动回顾

10月31日,第二期Docker&Kubernetes技术沙龙在宇宙中心五道口如期举行。这期沙龙的主题是集群管理。四位讲师分别从集群资源调度、网络高可用、集群监控和产品四个角度分享了他们在集群方面积累的知识和经验。参加沙龙的技术人员,热情很高,踊跃讨论,现场气氛十分活跃。

1. Kubernetes中的资源管理(调度器设计和资源QoS) –丁海洋(华为)

丁海洋的分享大致分为三部分:k8s简介,k8s资源管理机制,k8s现存问题。

Kubernetes(K8s)是Google出品的容器集群管理工具,目前已经在GitHub上开源(https://github.com/kubernetes/kubernetes )。借助于强大的社区,k8s自从发布热度就一直上升,版本迭代周期也比较短,目前已经发布稳定版1.0。k8s的主要概念有Container、Pod、Service、Replication Controller、Label&Selector(见下图),具体特性和原理大家自行参考官方文档(http://kubernetes.io/v1.0/ )。K8s采用了微服务模式,Master节点上运行组件kube-apiserver、kube-scheduler、kube-controller-manager和etcd,slave节点上运行组件 kubelet、kube-proxy和flannel。组件之间松耦合,一些组件可以被替换。

二期沙龙1

 

 

 

 

 

 

 

 

 

 

 

 

K8s管理资源的策略实现考虑到集群中的单个应用和整个集群两个层面。从应用的层面来看,“为每个Pod寻找合适的部署节点,保证用户体验”,k8s这块做得比较完善,设计了调度器,资源QoS和Auto-Scaling策略,也是丁海洋讲师重点分享的内容;从集群层面来看,“提高资源利用率,控制租户的资源配额”,k8s为此设计了资源超售、多租户资源配额管理、资源再平衡和实时监控,但目前的实现并不是很理想,实时监控更是处于缺省状态。关于调度器的架构设计和细节、资源QoS的定义和策略,这里不多赘述。

K8s调度器存在一些不足,比如目前不支持多个调度器,单个调度器也支持一个规则等,未来这都是优化的方向。另外资源QoS也只是在开发中,很多定义还不是很清晰。K8s才刚刚发布v1,未来还有很长的路要走。谈及华为对K8s的贡献,丁海洋讲师颇为自豪:目前华为主导了一些k8s特性的开发,commit数量也排前五。

问答精选:

a. 如何看待Docker Swarm和K8s,k8s二次开发比较麻烦,有没有在生产环境下使用的公司?
答:Docker Swarm倾向于把集群看成一个大机器,而k8s把集群当成可调度的资源。目前已经有一些公司在生产环境使用k8s。

b. 关于pod,一个pod内运行多个container,container是否同质?
答:Pod内运行的多个container理论上应该功能各不相同,实现互补,没必要同质。使用同质的Pod比较合理。

c. 关于pod,一个pod内的多个container是否会分布在多个node上?
答:Pod是最小的调度单元,一个pod的多个container分布在同一个node上。

d. 关于pod,如何定义一个pod的资源需求,网络是怎么处理的?
答:Pod的资源需求就是pod内所有container资源需求的总和,只是单纯的叠加。目前v1中并没有对网络进行处理,将来v1.2会有。

e. 关于资源QoS,request和limit,内存超额后,pod会被杀死,而cpu超额却不会,设计如此还是cpu超额尚未开发?
答:资源分两种:可压缩和不可压缩的。内存是不可压缩的,所以内存超额后会杀死容器。而cpu是可压缩的,即使超额也不会造成死机,所以CPU还没有做,不过后面会做。

f. Pod作为基本调度单元,container的监控是如何做的?                                                                                                                       答:K8s提供了pod级别和container级别的监控

g. 目前k8s master能够管理子节点的最大个数?
答:目前在性能尚可的前提下,支持最多1K个节点,每个节点默认40个Pod。

2. Etcd高可用实践 — 王鹏(光音网络)

Etcd是一个高可用的分布式键值存储数据库,k8s集群采用etcd存储集群的网络拓扑信息。Etcd提供了一套restapi,因此可以使用任意一种编程语言对其进行Get/Set/Recursive/Directory等操作。Etcd包含Storage、Raft、Entry和Snapshot四个模块(如下图),其中Raft一致性算法是保证etcd高可用和数据一致性的关键。王鹏讲师分享了Raft算法的原理。Raft主要实现两个功能:Leader Election和Log Replication。Leader Election的规则是:在一个Etcd集群中,只有超过半数node投票通过,才能成为Leader节点。Log Replication是指将数据写入etcd集群时,数据的同步机制。具体过程可以参考动画http://thesecretlivesofdata.com/raft/#home 。

二期沙龙2

 

 

 

 

 

 

 

 

 

 

 

 

之后,王鹏讲师分享了光音网络使用etcd方面的一些经验。首先是etcd的集群规模。由于Raft的Leader Election和Log Replication机制,etcd集群规模越大,消耗的时间越长,需要相应地增大Election/Heartbeat timeout。增大timeout会带来其它方面的问题,所以在光阴网络的生产环境中,etcd集群规模并不是很大,一般在40-50。其次是etcd集群的故障处理。由于数据的强一致性要求,数据与节点IP是绑定的。出现故障时,backup和restore都收到IP的限制,因此需要数量掌握add/remove节点操作,以便在故障时快速恢复。最后,对于集群性能调优,他给出了一些技巧。Etcd新增的metrics功能可以提供集群的健康状态,etcd-top工具可以查看网卡流量。

问题精选:

a. 我这里有一个web集群,有10个container,如果要扩展到100个,做负载均衡,能用etcd吗?
答:etcd只是作为存储,watch新节点或者容器并添加到集群中,业务方面还是需要自己去实现

b. 断网时,election是如何进行的?
答:通过election的timeout机制来实现。如果leader断网,follower节点timeout时,会成为Candidate,等待其他节点投票,得票最多的Candidate成为新Leader

c. 生产环境出现的网络抖动对etcd集群稳定性会有什么影响?如果有的话,怎么解决?
答:网络的抖动会导致频繁地Leader Election,会消耗大量的CPU,集群规模大时更为明显。对于跨区的集群,建议每个区使用独立的etcd,而非共享一个。

3. Kubernetes容器监控实践 — 杨乐(时速云)

K8s的监控系统是通过外部插件实现的。Kubelet内置的cadvisor进行数据采集,influxdb负责数据存储,heapster负责数据管理(交互方式如图)。Cadvisor获取数据以后,kube-apiserver从各个slave节点的kubelet进程读取数据,返回给Heapster,Heapster将获取到的数据存储到influxdb中。监控信息存储在influxdb中,需要时直接从influxdb中读取即可。杨乐讲师对集群监控的每个组件逐一进行讲解,具体细节请查看ppt。

二期沙龙3

问答精选:

a. 容器的log如何处理?
答:K8s只能看到平台级的日志,不负责容器内应用的日志收集

b. 如何实现监控验证?
答:通过配置Kubelet的 Service Account 和Secret实现

c. Influxdb是否支持高可用?
答:目前influxdb支持集群

d. 上百G规模下,监控的实时性如何?
答:日志的采集、整理和存储完全是分开的,分别由不同的组件完成,所以不存在实时性的问题

e. 如果将容器日志也放到influxdb的话,有没有现成的处理方法?
答:Influxdb不能对日志进行优化。如果要处理日志的话,可以使用ElasticSearch等日志处理工具。

4. 触控Khaos平台经验分享 — 邓磊(触控科技)

Khaos平台是为了解决开发、测试和运维的痛点而生。基于Docker容器技术,一方面方便了运维测试新软件和进行脚本测试,另一方面开发人员只需要提交代码既可以快速测试,而不用关心部署、打包等问题。邓磊讲师针对Khaos平台的特性进行了分享。

通过这次沙龙,我们看到越来越多的技术人员开始使用和学习k8s,讨论的主题更为丰富,也更为深入。下次我们期待更多大牛分享他们对k8s技术的经验和理解,也欢迎您前来参与。

沙龙PPT:http://pan.baidu.com/s/1nthElAT

暂无评论

发表评论