【视频和PPT分享】如何通过技术方式消除Kubernetes痛点

-回复 -浏览
楼主 2018-11-08 06:58:47
举报 只看此人 收藏本贴 楼主


在近期结束的Pivotalk 技术公开课中,来自Pivotal的解决方案架构师Steven为大家带来了有关PKS(Pivotal Container Service)解决方案的详细介绍。为了能让没参加公开课的同学们也能学习到PKS的知识点,我们将本次课程的干货内容整理了一下,连同视频和PPT一起分享给大家。


PKS


相信对于Kubernetes大家都不算陌生,但是对于PKS(Pivotal Container Service)这个名字可能会觉得比较奇怪,为什么是K而不是C?C在这里的读音是K,同时又是Container的谐音,还与Kubernetes的首字母K相呼应。所以,整个产品解决方案的全称就是“Pivotal Container Service”,简称“PKS”。


在为大家揭开Pivotal这个新产品的神秘面纱之前,首先进入一段广告时间,介绍一下Pivotal。由EMC、VMware 和 GE 共同投资的Pivotal于2013年正式成立,公司致力于帮助企业加速数字化转型。Pivotal的云原生计算平台Pivotal Cloud Foundr推动了许多最受人们喜爱的世界品牌的软件创新。在塑造了硅谷最有价值的公司软件开发文化十多年之后,如今 Pivotal引领全球技术浪潮,改变世界上软件的构建方式。

天的分享共分为以下四个方面:

1. Kubernetes会带来哪些痛点;

2. 通过技术方式消除Kubernetes痛点;

3. PKS:企业管理和运维Kubernetes的利器;

4. 竞品分析:PKS vs OpenShift。 


01

基于Kubernetes产生的痛点分析

稳定性存储给运维带来的好处。稳定性存储能够简化整套运维,通俗来讲,就是通过Kubernetes运行一系列的容器,提供和管理容器的镜像以及一系列的配置的文件,但这样做会忽视文件获取的方式。所以相当于把这一系列复杂性的运维全部交给了平台,这是一个优势。之后,运维和开发人员就可以专注在应用、开发方面,负责整个环境的运维。Kubernetes非常适合套装软件,非常适合多端口的服务应用,以及需要一些精细控制的应用,因为它的扩展性和灵活性是非常高的。那么,Kubernetes会产生的痛点有哪些?

 

假想一下我们是一个非常成功的运维团队,并且已经在正常的运维Kubernetes的集群,团队内的每一位工程师都各自有各自的技术特长,能够帮助开发团队,也能帮助安全团队来解决问题,提供服务。我们主要的客户其实还是开发团队,他们会通过一系列的方式来提出需求。第一个需求是运行系列的应用或者服务,这些应用和服务可能会有一些比较传统的应用和服务,也有可能是适合一些比较新的技术。来自不同种类的应用和服务是我们要面对的挑战之一,当然这个容器化的技术能够帮助我们解决掉这一部分的问题。而关键的挑战才刚刚开始。

 

痛点1:

在一个组织或公司内部可能会有很多团队,每一个团队都会对Kubernetes集群有自己的要求。即每一个团队可能都会需要有一个或者多个Kubernetes集群。例如开发团队,最常遇到的问题是:“今天能帮我们开启一个新的集群吗?因为我们可能要做测试或者有一些其他的用途。”那么,如何在最短的时间内,帮开发团队或者说其他团队搭建新的集群?

 

痛点2:

无论是开发团队还是其他团队,在运行应用的时候不可避免的会涉及到资源问题。一开始可能会为其部署一个比如五个节点的Kubernetes集群,但随着时间的推移或者随着一些特殊事件的发生,最终发现这个集群资源不够了。此时,开发团队会找到运维团队要求集群扩容,从现在的5个节点扩展到50个节点,甚至更多。另外一个问题是,当事件结束后需要从50个节点的Kubernetes集群缩减到原先的状态,从而降低运维成本。那么,如何在最短的时间内进行Kubernetes集群资源方面存储空间方面的双向调控。

 

痛点3:

由于支撑Kubernetes集群的是操作系统,在这些操作系统发展过程当中不可避免的会遇到系统升级的问题。那么,如何能够帮助运维团队来打补丁?此外,如果我们管理着成千上万的集群,支撑的是整个公司内部所有IT部门,那么在打补丁的过程当中,是无论如何不能停止服务的。因此,需要在零停机的状态下完成升级。

 

痛点4:

Kubernetes从2014年发布开始到现在已经是1.10版了,每一个升级都会带来非常多的新特性。您只有确保持续的升级Kubernetes才能享受到更多的新特性。随着团队需求的加剧,如何针对整个集群进行Kubernetes升级对于运维团队来说也是一个非常大的挑战。

 

痛点5:

如何设置Kubernetes集群之间在通信的过程中的权限?开发团队新的服务上线以后,要对外提供服务,这些服务如何暴露给其他用户使用?这也是运维团队所要面临的一个非常大的挑战,因为我们要管理数量惊人的网络配置和安全策略。



02

通过技术方式消除Kubernetes痛点

关于这五大痛点,在不考虑产品的前提下,如何通过技术手段来解决这些问题?

 

  1. 服务方式——多租户自服务

    传统的开发和运维团队在人数配比方面存在巨大差异。有些甚至达不到10:1。对于这种规模的用户群体,我们的运维团队只要提供一个统一化的平台,这样开发团队就能够通过自服务的方式来创建集群、做弹性伸缩、管理集群。这就是第一个应对之道,为用户提供多租户的自服务的方式。


  2. K8S集群部署——自动化

    涉及到集群部署方面,首先要通过平台让K8S集群能够自动化的进行部署。对于一些弹性伸缩或者资源增加Kubernetes集群,也可以通过自动化的方式来对其提供服务。在版本升级方面,也需要通过自动化来做一系列的滚动升级,防止服务对外停用,即在不停机的状态下对外提供服务,这也是需要高度的自动化。针对网络安全配置、系统补丁与升级,其实还是自动化的过程。


    总结下来只有两点,第一点是多租户、自服务,比如用户、开发人员通过一个统一的平台自己给自己提供服务。第二是要通过高度的自动化来实现上述自服务。所以自服务和自动化,这是我们应对之道的两大方向。 


03

PKS:企业管理和运维Kubernetes的利器

简单回顾一下PKS的历史,PKS在诞生之初是为了提供稳定性的服务,因此PKS内嵌了Kubernetes集群,所以可以将PKS视为一个Kubernetes as a Service的平台。Cloud Foundry的BOSH能够为PKS提供支持。Kubernetes+BOSH的项目代号叫KUBO。2017年,KUBO正式更名为Cloud Foundry Container Runtime,究其原因是KUBO这个项目交给了Pivotal来做商业化的运作。开源的版本叫作Cloud Foundry Container Runtime(CFCR),这是一个开源的版本的KUBO。

 

随着各行各业数字化转型的展开,带来了大量的挑战和需求,所以Pivotal联合VMware在整个CFCR当中加入了非常多的特性,其中就包括了Harbor和NSX-T这两个VMware的产品。还加上了其他的一些特性,最终推出了商业化的KUBO和商业化的CFCR,这就是现在的Pivotal Container Service。



PKS是一个企业级的集安装、部署、管理于一体的管理Kubernetes集群的平台。PKS主要负责安装、部署引擎,负责各种规模Kubernetes集群的弹性伸缩,对外提供自服务和多租户的接口,还负责通过底层的BOSH支持零停机的滚动升级、负载均衡、配置管理,还提供一系列的镜像管理。

那么,PKS的架构是什么样子的呢?


关于PKS的架构,我们用愤怒的小鸟来扮演开发团队来演示一下。开发团队通常会通过Kubectl来控制Kubernetes集群,这是一个命令行的工具,它可以通过kubectl来部署、来做一系列的集群方面的操作,这是非常简单的一个场景。当集群需要多个集群实例时,集群要扩大、集群里面note的数量要增多或者缩减时候用户将面临弹性伸缩问题。同时,如果要提供一个自服务的平台,这个自服务的平台该怎样实现?


愤怒的小鸟属于团体战游戏,在这里就相当于是有非常多的开发团队对于Kubernetes集群有着非常强的要求,他们也需要有自己的集群,这时候支持这些这么多的团队,把他们理解成多租户的场景,这些多租户、多团队的场景将怎么样实现?

 

此外,还有一些与Kubernetes相关的挑战。例如,镜像仓库该怎么管理,对于镜像的安全管理应该怎么做?是不是要对这些镜像进行扫描的机制?K8S存在非常大的扩展点,外部很多服务如开源社区能够提供一系列的多冗余接口,这些接口怎么跟K8S进行集成?在我们的场景当中有非常多的集群和节点,这些集群的网络安全怎么样高效的管理?

 

关于这些问题,有着不同的解决之道。第一个解决之道,对于弹性伸缩、自服务和多租户多团队,可以通过提供PKS controller(PKSctl)的工具来实现。

 

首先,下层所有的Kubernetes都会运行在虚拟机或物理机上。在PKS的世界里面,是用虚机向上提供支持的。所以说当需要三个节点来组成Kubernetes时,我们会在虚机的世界里面产生三个虚机,由它们提供一个完整的Kubernetes服务。当需要横向扩展,增加Kubernetes服务时,只需要再增加相应的机器数量即可。如果需要把单个Kubernetes集群的数量增加时,只需要添加一个虚机到集群中,就能起到扩展的作用。同理,如果需要减节点,我们只需关掉虚机,或者让它退出这个集群就可以了。这是通过我们的虚机来解决弹性伸缩的解决方案,但是会带来另外一个问题,那就是如何能够通过自动化的方式把这些虚机管理起来。

 

上文中也提到过监控自愈这一方面,对于成千上万甚至更多数量的虚机来讲根本不是靠人力能够实现的。关于弹性伸缩,虽然虚机可以进行整体资源扩容,但这一系列扩容操作也需要由运维团队进行管控。

 

我们会推荐用户通过BOSH解决上述问题。BOSH虽然是一个开源项目,但前身是Google用来管理Google内部所有虚机的平台。BOTH就是用于处理虚机的部署、自动化管理、监控和自愈的平台和开源解决方案,现在也是Cloud Foundry旗下的一个开源的产品。有了BOSH平台,我们运维团队会通过一个opsman的工具来对BOSH进行管控。

 

镜像仓库和镜像安全管理这方面,我们通过Harbor工具进行管控。Harbor可以通过opsman来进行管理,它提供了镜像仓库的管理。开发团队可以将镜像远程推送到Harbor里面,Harbor再对这些镜像进行安全的扫描,如果发现有一些安全性方面的漏洞,会在发出报警并且会采取一系列的方式来解决这些问题。实际部署时,Kubernetes集群会找到Harbor对应的镜像并把镜像作为Container运行起来。

 

对于K8S的扩展,就不能不介绍OSBAPI。通过这个工具就可以将K8S集群连接到外面的世界。举个例子,在我的marketplace里面可以支持OSBAPI的产品,比如数据库、MQ,甚至是另外一系列云计算的产品,这一系列外部的思路都可以通过OSBAPI接入到PKS集群当中所管控的一系列K8S中去。

 

还有就是网络部分。VMware最新的NSX-T,能够从根本上解决了网络安全和负载均衡这一系列的问题。最后就是持久化。VMware的另一款产品vSphere,是我们私有云最重要的基石,也为私有云提供了IaaS服务。同时,我们还可以通过vCenter来部署持久化的磁盘这一系列的工作。

 

如下图所示,开发团队在上面通过kubectl、通过PKS controller来操作K8S集群,整个PKS提供了弹性伸缩、自服务、多租户多团队的特性。下面的小猪就是运维团队,虽然人数比较少,但是他可以通过BOSH、NSX-T、vSphere来做一些底层的支持,主要是工作在虚机级别,这些虚机恰恰是K8S的支柱和支撑。以上,就是从开发与运维这两个不同的团队的视角来给大家介绍了一下PKS的架构与特性。



Pivotal的另一个产品是Pivotal Application Service(PAS)。PKS与PAS两者各有所长,如下图所示,PKS更适合于左边这一系列有特殊要求的应用,或者符合这些特性的应用,因为它是适合多端口的应用。如果应用已经存在多个镜像了,或者只需要在多个镜像上做很简单的修改和配置,使用PKS是非常方便的。



例如,部分数据类型的应用可以放在PKS上运行。对于一些Buildpack定制复杂的应用,也可以放在PKS当中做。有共置和编排要求的应用,有存储要求、持久化要求的应用,也建议通过PKS实现。

 

PAS是下一代应用程序的运行框架,也就是Pivotal的微服务和云原生应用平台,如果是符合我们经常提到的十二要素的应用,都可以运行在PAS上面,它对于Spring架构搭建出来的应用是天然支持的,不需要做任何的改动,就能够把应用迁到PAS上面去。

 

这是PKS和PAS两者之间的特点,需要根据应用的情况来选择是运行在PKS上还是PAS上。需要注意的是,PKS和PAS是可以单独运行的。


PKS是唯一获得Google合作并支持的产品,所以在资源方面有着得天独厚的优势。其次,PKS是纯开源的Kubernetes,我们没有对它做任何扩展和修改,所以保证了用户可以随时升级到最新的Kubernetes,享受最新的Kubernetes带来的好处。第三,在私有云和公有云之间,工作负荷可以自由的流动。

 

此外,Pivotal拥有企业商用的IaaS集成,跟VMware有非常好的合作关系,所以Pivotal得到了vSphere非常强大的支持,在vSphere上面运行的应用是非常稳定的。我们还提供了一整套的跨云自动化安装部署、运维工具BOTH,可以帮助运维团队节省非常多的精力。

 

最后,Pivotal的产品能够按需生成Kubernetes集群,其自动化能力就体现在能够非常快速的把Kubernetes集群给生成出来,并发给开发、测试、生产等部门,让应用快速上线。



点击“阅读原文”下载公开课PPT

我要推荐
转发到

友情链接