广告

太多干货!K8S如何支持20000+Services?

  • 浏览(1,376)
  • 评论(0)
  • 译者:k8s

CloudNativeCon + KubeCon Europe 2017峰会第二天持续火热进行,K8S技术社区特约记者船长就当前3大技术热点发来现场报道:

KubeCon Day2:技术热点Discussion

1

 Kubernetes 如何支持20000+服务?

IPVS 介绍【Quinton Hoole, Huawei】

当在集群里大规模创建服务时,Kubernetes(K8S)控制平面(Master 节点,kubelet,kube-proxy)和数据平面(Load Balancer)都面临着挑战,比如,如果集群有 N 个节点,每秒钟有 M 个 pods 被创建,那控制平面每秒需要创建出 N*M 个 Endpoints,我们如何化解控制平面的压力呢,有以下几个思路可以尝试,各有优势和不足之处:

1. 把 Endpoints 对象拆分成多个对象

这样减小了单个 Endpoint 的大小但同时增加了其对象的数量和请求数量

2. 使用集中式负载均衡器

这样能有效减少跟 API Server 的连接和请求数,但这样在服务的路由中又增加了一跳,需要集中式 LB 有很高的性能和 HA 。

3.  定期任务,批量创建/更新 Endpoints

这样好处是不用改变 ETCD 中的数据结构,同时减少了每秒的处理数,但在定期任务执行的间隔时间内,端对端延迟明显增加。

对数据平面来说,当前集群内部的 Cluster 类型 Service 是使用 IPTables 作为服务的负载均衡器,但因为 IPTables天生不是被设计用来作为 LB 来使用的,随着服务的数量增长,IPTables 规则则会成倍增长,这样带来的问题是路由延迟带来的服务访问延迟,同时添加或删除一条规则也有较大延迟。

由上图的测试对比数据可以看出,当集群中服务数量达到5千个时,路由延迟成倍增加。

添加 IPTables 规则的延迟,有多种产生的原因,如:

添加规则不是增量的,而是先把当前所有规则都拷贝出来,再做修改然后再把修改后的规则保存回去,这样一个过程的结果就是 IPTables 在更新一条规则时会把 IPTables 锁住,这样的后果在服务数量达到一定量级的时候,性能基本不可接受:在有5千个服务(4万条规则)时,添加一条规则耗时11分钟;在右2万个服务(16万条规则)时,添加一条规则需要5个小时。

这样的延迟时间,对生产环境是不可以的,那数据平面的性能问题有哪些解决方案呢?我们可以重新查找树来重构 IPTables 来带来一定的性能提升,但这样没解决根本问题;从根本上解决的话,可以使用 “IP Virtual Server”(IPVS )来替换当前 kube-proxy 中的 IPTables 实现,这样能带来显著的性能提升以及更智能的负载均衡功能如支持权重、支持重试等等。

那什么是  “IP Virtual Server”(IPVS ) 呢?作为 Linux Virtual Server(LVS) 项目的一部分,IPVS 是建立于 Netfilter之上的高效四层负载均衡器,支持 TCP 和 UDP 协议,支持3种负载均衡模式:NAT、直接路由(通过 MAC 重写实现二层路由)和IP 隧道。

IPVS 负载均衡模式在 kube-proxy 处于测试阶段还未正式发布,完全兼容当前 Kubernetes 的行为,通过修改 kube-proxy 启动参数,在 mode=userspace 和 mode=iptables 的基础上,增加 mode=IPVS 即可启用该功能。由下图测试数据可见:使用 IPVS 后,添加规则的时间跟 IPTables 相比有极大的提升,5千个服务时规则添加时间由 11分钟降到了2毫秒,2万个服务时规则添加时间由5个小时降到了2毫秒,同时在5千数量级以上个服务存在时,访问服务的网络带宽也有巨大的提升,可见 IPVS完全可以支持大规模服务的场景。

2

Kubeless-Kubernetes 上的 Serverless 框架 

Sebastien Goasguen,Bitnami,Nguyen Anh-Tu,Skippbox】


无服务器计算并不是说没有服务器来运行应用,它是指我们可以专注在应用的构架和运行上,而不需要管理底层计算网络存储等基础架构资源,服务器资源的管理由底层基础架构平台来自动提供,对应用透明。AWS Lambda、Google Functions、Azure Functions分别是三家公有云厂商提供的无服务器计算产品。

Kubless是来自 Bitnami 发起的 Kubernetes上的无服务器框架,增加新的 kubelss controller,然后使用 ThidrPartyResrouce  机制把 function作为 Kubernetes 资源,用来管理 funtion 的 metadata 数据,可以对其增删改查;使用 Deployment/pod 来运行 function 的运行时;通过 ConfigMap 把函数代码注入到运行时 pod;通过 Service 来对外暴露 function;通过 init container 来管理和加载function 的依赖;同时,使用Kafka/Zookeeper来存储 events。Kubeless 的 Roadmap 见下图:

跟 Kubeless 类似,来自 Platform 9 的 Fission、来自 Fabric 8 的 Funktion 都是建立于 Kubernetes 平台上的无服务器计算框架。其它的无服务器计算开源项目还有 Iron.io、webtask、OpenWhisk等等。

3

容器内哪个进程的 pid 应该为1?

容器初始化系统初探 【Ranjith Rajaram, Red Hat】

我们知道,在 Linux 内核启动的时候会先启动一个 init 进程,这个进程的 PID 始终为 1并且有着特殊的使命,需要做好的父进程的角色,比如传递信号,确保子进程完全退出;等待子进程退出等。容器使用 PID namespace 来隔离不同容器内的进程 PID 号,意味着不同的 PID namespace 里可以有同样的 PID。在容器环境中每个 PID namespace 里的第一个进程PID也为1,也需要处理系统信号,接管子进程,避免容器无法停止、产生僵尸进程等问题。

这样,容器环境内哪个进程的 PID 为1的问题,也变得重要起来,我们有如下三种可选方案,来解决容器初始化系统确实的问题。

1. dumb-init 或 Tini

这两者的功能类似,都是PID 为1的轻量级进程守护程序,承担容器内 init 系统的作用。以 dumb-init 为例,我们如果要使用 dumb-init ,只需要在容器镜像内安装上 dumb-init 程序,然后在启动应用时,在命令行前加上 dumb-init 就可以了。这样 dumb-init 以 PID 1运行,启动一个进程并且把它接收到的所有信号量路由到一个 session 里并且分发给子进程,因为这时应用的实际进程PID 已经不是1了,当它从 dumb-init 收到信号时,可以跟预期的一样正常响应信号量,跟不在容器内运行有同样的行为,不会导致容器无法停止的问题。

2. docker-init

Docker 1.13版本为 dockerd 进程添加了- – init 标记,如果在进程时添加了这个标记,那后续的容器启动时,docker 会自动为容器启动 PID 为1的僵尸收割进程充当 init 系统。同时,我们可以通过- -shutdown-timeout 来解决dockerd 退出时容器优雅退出,通过- -stop-timeout 解决单个容器优雅退出的问题。

1.13或更新的版本,可以通过docker info 可以看到 docker-init 相关信息,如:

Init Binary: docker-init 

init version: N/A (expected: 949e6facb77383876aeff8a6944dde66b3089574)

3. Systemd

让Systemd 以非特权模式在容器内运行,充当容器的 init 的作用,这样带来的额外好处是可以更好处理日志以及服务启动顺序的处理等等。当前有 OCI Systemd Hook 可以支持这种方案。

此外,CNCF基金会 TOC(Technical Oversight Committee) Chair技术委员会主席Alexis Richardson在开场演讲时,介绍了云原生以及给它带来的好处,云原生的概念最早由 Netflix 于2013年提出,云原生不仅仅只是一种应用开发模式,也不仅仅只有应用开发12要素的要求,它是由文化、最佳实践和工具集的相互配合和影响带来的整个应用开发、测试、运维等一整套流程,来为企业快速创新提供支撑。 Alexis 推荐大家观看 Netflix 的演讲幻灯片(https://www.slideshare.net/AmazonWebServices/dmg206)来更进一步理解云原生概念。开源软件吞噬世界,云吞噬开源软件,在云计算时代,选择云平台支撑技术时也需要避免技术锁定,CNCF 基金会的使命是为云原生应用提供可快速上手、自由、可信赖的开源基础工具。

K8S技术社区当前有两大技术推广平台,K8S技术社区官方网站(www.k8s.cn)和K8S技术社区微信公众平台(kubernetescn),我们欢迎广大K8S技术同好们关注支持,也希望集合K8S技术极客进群交流(筒子们后台留言微信号!),有任何建议或问题都可以随时与我们取得沟通(admin@k8s.cn),感谢支持!

 

  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头