新型容器+Kubernetes已经成为云计算的一个主流，那么怎么能够通过PKS Kubernetes最新的特性来进行Greenplum的运维管理呢，本文将问您解答如何通过PKS与Greenplum的集成更好地提高Greenplum的运维。
Greenplum是Pivotal开源的分布式MPP数据库，它的主要应用场景是一些大规模数据处理、数据分析之类的应用。PKS是Pivotal Container Service的缩写。PKS是Google开源的容器管理平台Kubernetes的企业版。PKS在整个Pivotal PaaS的解决方案中占有非常重要的位置。
Kubernetes是这两年IT圈里非常火的话题，所有的云应用基本上都在考虑用Kubernetes来运维。然而Kubernetes有一个非常重要的问题就是它的设计初衷是为了那些简单的无状态应用来运维的，比如说像WebServer。而对于一些有状态应用，像分布式数据库这种，既有状态，而且运维又非常复杂的应用，Kubernetes是有很多局限的。
什么是Greeenplum?
可以说Greenplum是开源数据库PostgreSQL的分布式版本。它的三个核心关键词就是：开源、大规模数据处理、数据仓库。
Greenplum总体架构图
这是Greenplum的总体架构图。Greenplum每个节点都可以理解为是一个单机的PostgreSQL数据库，它们协作完成的一个并行查询处理。Master的主要功能是接收用户的请求，然后做查询计划的生成，然后分发给执行节点。而Segment主要负责的是数据的分布式存储，以及对分布式并行查询计划的执行。中间部分叫Interconnect，它的主要作用是在查询使用的过程中，Segment节点之间，以及Segment与Master节点之间的数据的互动。正是因为Interconnect才使得并行查询的数据流能以pipeline的方式传递给整个的最终用户。
最下面是外部存储以及pipeline。Greenplum不仅能够支持本地的数据存储，还可以对一些外部的数据源，比如说HDMS、一些存储，比如S3，以及GemFire内存数据库或者Spark，也可以为其他的数据库服务，同时对于一些数据加载ETL以及流式处理，都可以很好的支持。
在高可用方面，Greenplum也是做到了无单点故障。
这张图是Greenplum的一些特性。随着大数据处理的需求越来越复杂，Greenplum从单一的SQL引擎，已经在向平台进化，它的用户既可以是IT人员，也可以是一些开发人员，还可以是数据科学家，或者是分析师。整个平台分三层结构。第一层是应用以及接口层，即Greenplum能适用的应用包括了SQL以及一些app的开发，以及一些BI应用、机器学习、人工智能，都可以在Greenplum上进行运行。在接口层，除了支持JDBC、ODBC这样的Native接口外，还支持机器学习，用一些不同语言，比如Python、R，来供数据科学家使用。以及还可以做检索，用Postgres做一些地理信息的分析。
中间这一层是Greenplum的核心层，这一层支撑着上面那些应用的不同场景。包括MPP，即如何把单一的数据库进行分布式化。第二个是PB级的数据加载。第三个是Pivotal开源的一个GPORCA查询优化器。第四个是Workload Manager，它可以管理Workload的负载分析。第五个是固态存储，这个指的是Greenplum的存储既包括一些比如像ticket表，也可以包括一些行存、列存的不同存储以及压缩都可以支持。第六个是Command Center，指的是对Greenplum整个平台可视化的运维分析。第七个是SQL的兼容，Greenplum的SQL兼容应该是业界最全的。最后一点是Greenplum与PostgresSQL Kernel是完全兼容的。
下面一层是数据层或者数据源。Greenplum可以支持结构化的数据以及JSON等。在数据源方面，上文已经介绍，此处略过。
最后一点，也是很重要的一点是，我们这个平台也开始去考虑不同的基础设施的一些部署方案，也就是说Greenplum作为一个数据平台，不仅可以部署在裸机的集群上，也可以部署在任何的公有云以及私有云上。
如何实现快速部署？
第一个问题，如何能够在不同的基础设施上做到快速部署？也就是如何做到部署透明化？
这个部署既可以是私有云的VMware、OpenStack，也可以是常规的公有云的解决方案，还可以是裸机，这些都可以。如何做到这一点，这是我们第一个问题。
GPDB+PKS
第二个问题，如果将Greenplum部署在一些云上，到底能对我们的运维带来哪些好处？我想任何一个做过数据库管理员的人都遇到过类似的问题：第一，磁盘的磁又没了，资源还存在上面。第二，怎么样能够做到快速部署。第三，如何发现某个节点出现问题，并且如何进行恢复。第四，数据库的存储不够了，或者计算能力不够了，如何来扩容。如果有这些问题的话，云平台可以为我们提供很好的解决这些问题的基础设施。
带着这些问题，我们来看一下什么叫PKS。
PKS就是来解决上面的问题的核心方案，它能够提供的是对于容器化的工作负载的一些Cloud部署以及运维。
PCF可以为Kubernetes提供一个透明的接口。如果用Kubernetes的服务，那么用PCF的话，我们就会关心这个服务到底是在私有云上还是公有云上。而PCF能够为用户提供统一的平台级的管理方案。
回到刚才的第一个问题，如何做到部署的透明化。答案就是PKS。我们的应用只要跑在容器的标准环境下，不用再关心部署在哪里。PKS是第一层，第二层就是PKS或者Kubernetes如何帮我们来简化运维。
先简单介绍一下Kubernetes的一些基本的概念。Kubernetes是采用主从架构，Master作为主节点，主要做集群的控制管理的角色，能够维护整个集群的资源以及资源的调度。每个note是工作节点，上面有一些自己常规的管理进程，比如Docker，Docker就是容器的运行时，等于我们的工作负载一定会跑在Docker里。
Kubelet是整个容器进行时的进程检测工具。Kube-proxy是对整个容器化的网络的路由规则做一个统一管理，可以让Kubelet比如Service能够更好的工作。然后是Pod，Pod是整个Kubernetes中最核心的一个概念，它是一个资源分配的单位，我们的容器一定是跑在Pod里。
Kubelet，Kube-control是整个的客户端。如果一个用户想要通过命令行与Kubernetes进行通信的话，一定是通过这个客户端。
Storage，大家都知道容器的特征是它的存储应该是随着容器的销毁而销毁，如果说它的数据就是它的状态，如果分布的话，我们不希望这个状态消失，所以我们希望让存储与容器的生命周期独立。于是，在主流的这种公有云的解决方案中，都有这种存储的组件。比如像亚马逊会用EDS这样的服务。这样的话如果一个数据库的应用可以跑在Pod的话，把存储扩展成外部的一些设施，就可以做到逐步的起停、销毁或者失败，可能数据都不会丢。
Kubernetes Service，Service也是Kubernetes一个很重要的概念，它为我们的应用对客户端提供一个入口，这个入口是一致的，是不变的。这样的话，无论应用的IP怎么变，对用户来说都是一样的，使用访问这个Service地址就可以了，是一个抽象的概念。
这个图就是Greenplum在Kubernetes上的简单的部署方案。可以看到每个node里运行的就是Greenplum的实践，要么是Master，也可以是standby Master，数据是通过网络的方式挂载到一些web的storage上。用户通过前面那个Greenplum Service可以访问这个服务，通过Service的地址就可以连接到Master节点，来进行数据库的常规操作。
Greenplum部署在PKS上的好处
第一个好处：可以做到按需提取的申请。比如说我们有一个开发人员叫Radar，他想要一个无节点的Greenplum的集群，怎么做呢？首先他把这个请求发给PKS，PKS就会生成一个这样的集群，这个集群不跟任何人共享。然后把集群访问地址给到Radar，这样就可以通过这个地址找到这个集群，来进行自己的集群的使用。同样，另一个用户如果想要用这样的集群的话，他也可以申请一个跟自己独立的集群，二者没有任何的关联。
第二个好处就是服务发现。Kubernetes的一个优势是，它对每个Pod都有一个自己的域名，这个域名是不跟随Pod的IT[1] 变化而变化的。于是我们在整个集群的管理中，可以使用静态的集群DNS的名字来进行集群管理。
第三个好处是高可用。举个例子，比如两个主节点，有两个从节点，在常规的部署方案里，假设有两台机器的，可能每个机器都有个主节点，两个从节点跟主节点不在同一个机器上。这样的话，如果有一个主节点挂掉的话，那从节点可能会变成在机器上工作，这样就会导致这个从节点和另一个节点在一个机器上，它的负载瞬间变成了原来的二倍。但如果用PKS，每个节点是独立的，就不存在这种不平衡的问题。
第四个好处是Kubernetes提供了很多插件，能够有其他功能的支持。比如说有存储的一些接口，很多存储化的节点既可以挂载到亚马逊的存储EDS，也可以挂在Google的storage上，或者VMware或者OpenStack上的一些存储都可以。没有任何差别，用户应用可以像使用本地磁盘一样使用这样的一些存储方案。
另外，整个比如logging这样的机制，都有统一的解决方案，容器的损坏也不会导致整个logging的丢失。
解决方案：Kubernetes Operator
那我们怎么能够借助Kubernetes这样一个运维平台来做到策划运维？比如节点挂了之后，怎么能够让它自动的进行重启?同样对Master来说，用Master怎么样能够自动的切换到standby。怎么能够自动扩容和升级？这是一个问题。答案就是用Operator这种模式。Kubernetes有很好的扩展机制，它可以用Operator来做这种自动化的运维。
Operator这种模式它的核心是，需要将一些人工运维的经验，通过程序的方式，在Kubernetes里面运行起来。 Operator核心的概念，首先就是我对任何一个比如说像Pivotal Greenplum作为我自己的资源的话，那么我们可以像使用Pod这种资源一样来使用Greenplum的资源。如果在有资源的情况下，我得有一个控制器，就能够根据这个资源的状态的变化，来进行检测，然后执行所对应的action。我能像内置resource一样来使用一个新的resource的新的扩展机制。controller是我能够通过描述一个新的资源的最终状态，能够做一些动作达到这种状态。
举个例子。比如说部署，如果我把Greenplum定义成一个resource，那我会执行一些操作，可以让这个cluster建起来，并且筹划好。但对于segment的情况，如果我的controller监测到一个segment已经挂掉了，它会这么去执行：Pod重启，以及执行我们内置的命令。就是这两个概念的组合就是Operator。
这个是我们的Greenplum的Operator中的一些资源的定义。
这张图是我们可以定义Greenplum的CRD。它可以把Greenplum定义成一个可识别的一种资源类型。
这张图定义的是Greenplum资源的一些属性。这个属性比较重要的一点，第一是它的名字，比如gpdb-service-1，spec里面它的一些属性，比如像segmentCount，即规模，可以是一个，可以是十个，也可以是一百个。数据目录等等，都可以定义好。有了这样的工具之后，第一步需要先把我写的Operator程序做成yaml，然后一样用Kubernetes的方式来运维这个程序。第一步让Operator跑在connect集群里。第二步就可以把上面的Data文件通过kubect create的方式串联到集群，做到这两步之后，各个集群就已经运行起来了。
这个图是刚才那个模式的解析，总共分两步。第一步就是部署Gpdb Operator方案，通过上面那个黄色的Gpdb-Service-1的文件，可以把自定义的resource注册到K8S的Master的etcd里，然后交给controller注册到controller manager里。如此一来，在执行Gpdb-Service-1的时候，就可以得到这样的Cluster。
未来一定会支持更多的存储设施。Greenplum跑在容器的环境下，尤其是Kubernetes里边，跟原来跑在集群里是不同的。因为K8S集群里还跑着一些其他的应用负载，这些应用负载之间它们怎么来做资源的协调，这后面还有好多事情有待我们去解决。
大家有任何关于Greenplum的任何问题都可以发到 gpcloud@pivotal.io这个邮件来咨询。返回搜狐，查看更多