构建基于kubernetes的PaaS服务

工作中需要向外部提供一些诸如MySQL、Redis、MongoDB、Kafka之类的基础PaaS服务。以前每做一个PaaS都要自己去实现工作节点管理、实例调度、实例运维、实例监控等功能模块,实在是太累。这次花了些时间想了下,感觉基于Kubernetes做这个会简单很多。下面概要性地梳理下基于Kubernetes构建基础PaaS服务的过程。

构建基础PaaS服务

将基础PaaS服务部署进kubernetes

假设现在一套生产可用的Kubernetes集群就绪了,第一步要做的是将目标基础服务部署进kubernetes。大体有三种方案:

  1. 使用kubernetes的yaml描述文件部署
  2. 使用helm chart部署
  3. 使用operator部署

第一种方法太琐碎,长长的yaml描述文件也不方便维护。

第三种方法是现在社区最推荐的,但实际执行后,发现问题还比较多:

1)目前网上的operator质量参差不齐,很多是半成品,有一些官方维护的operator质量虽说还可以,但跟官方推荐的商业版软件绑定太死

2)operator这种方案定制扩展性不太好,一旦operator定义自定义资源不能完全覆盖需求,需要定制时就需要改operator的源码,而且多个operator的代码风格也非常不一致,维护起来困难

第二种方法目前只能解决基础软件的部署、升级、卸载,其它运维相关的功能如备份还原等需要另外开发。

综合考虑,最终选择了第二种方法。第二种方法所要用到的chart在网上很方便地就可以搜索,可能参考官方的helm chart仓库。

例如借助redis-ha这个chart,我们可以很方便地将redis主从集群部署进kubernetes集群,参考命令如下:

helm install stable/redis-ha

当然如果有一些特殊需求,需要把官方提供的chart进行一些定制。

屏蔽底层集群

为了保证PaaS服务的高可用,上面我们部署redis时,使用的是redis-ha这个chart,其部署出的redis是高可用的主从集群。但PaaS服务的使用方以非集群模式的方便访问redis是最方便的。为了方便使用方,这里我们可以部署redis智能代理,以屏蔽底层的集群细节,让使用方像用单节点redis实例一样使用我们提供的redis服务。在网上搜索了一下,最后选择了predixy这款redis智能代理,这款redis智能代理的优点是性能好,支持主从哨兵集群和分片集群,配置简单方便。如何将predixy打包成docker镜像就不具体说了,这样列一下其代理redis主从集群的核心配置:

predixy.conf

Bind 0.0.0.0:7617
WorkerThreads 4

Authority {
    Auth "123456" {
        Mode write
    }
    Auth "#a complex password#" {
        Mode admin
    }
}

SentinelServerPool {
    Databases 16
    Hash crc16
    HashTag "{}"
    Distribution modula
    MasterReadPriority 60
    StaticSlaveReadPriority 50
    DynamicSlaveReadPriority 50
    RefreshInterval 1
    ServerTimeout 1
    ServerFailureLimit 10
    ServerRetryTimeout 1
    KeepAlive 120
    Sentinels {
        + instance01-redis-ha:26379
    }
    Group mymaster {
    }
}

使kubernetes集群外能访问PaaS服务

PaaS服务已在kubernetes里部署好了,也可以以一种简单的方式向使用方提供服务了,接下来需要将PaaS服务暴露出来。我们知道如果是简单的http服务,要将服务暴露出来,直接使用kubernetes里的Ingress就可以了,但绝大部分基础PaaS服务都是TCP或UDP对外提供服务的,而很可惜我们所用的Ingress Controller竟然不支持TCP代理,于是只能另想办法处理这个问题。

还是继续上面的例子,假设上述的redis-ha及predixy部署在kubernetes工作节点,而高可用kubernetes集群的vip只是在几个master节点间漂移,外部用户也肯定是通过vip来访问PaaS服务的。因此我们需要一种方式将外部用户的流量从master节点引向工作节点的方案。又是一番寻寻觅觅,我找到proxy-to-service,通过这个pod,我们可以很方便地完成这一功能。proxy-to-service关键性pod配置如下:

  nodeSelector:
        node-role.kubernetes.io/master: true
  
  containers:
  - name: proxy-tcp
    image: k8s.gcr.io/proxy-to-service:v2
    args: [ "tcp", "7617", "predixy-svc.demo" ]
    ports:
    - name: tcp
      protocol: TCP
      containerPort: 7617

最后,我们创建proxy-to-service对应的Service,其Type设置为NodePort就可以了:

apiVersion: v1
kind: Service
metadata:  
  name: proxy-to-service-nodeport-service
selector:    
  app: proxy-to-service
spec:
  type: NodePort
  ports:  
  - name: tcp-redis
    port: 6379
    targetPort: 7617
    nodePort: 36379
    protocol: TCP

此时外部用户已可以通过vip及nodePort访问到redis PaaS服务了:

redis-cli -h ${kubernetes_master_vip} -p 36379

设置访问白名单

这种对外提供的PaaS服务,安全起见,至少还是应该提供访问白名单功能,以限制访问服务的客户端,避免潜在的安全风险。我们这里可以使用kubernetes的NetworkPolicy功能实现该功能。

首先我们要选择一个支持NetworkPolicy的CNI网络方案,默认的flannel是不支持的,为此我们换用了calico

另外为了取得正确的客户端源IP地址,以进行访问白名单检查,我们需要将Service的externalTrafficPolicy设置为Local,官方文档中将如此设置后流量路径也解释得比较清楚,参考这里就可以了。

apiVersion: v1
kind: Service
metadata:  
  name: proxy-to-service-nodeport-service
selector:    
  app: proxy-to-service
spec:
  type: NodePort
  externalTrafficPolicy: Local
  ports:  
  - name: tcp-redis
    port: 6379
    targetPort: 7617
    nodePort: 36379
    protocol: TCP

这里要注意,采用这种设置后,Service只会将流量代理到本节点的endpoint,如果本节点没有对应的endpoint,进入的流量就会被丢弃。这显然不是用户希望看到的,这里我们可以使用daemonset配合nodeSelector,将proxy-to-service的pod调度到每个master节点上,以解决该问题。

最后应用一个NetworkPolicy就可以了,如下:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: proxy-to-service-network-policy
spec:
  podSelector:
    matchLabels:
      role: redis-proxy-to-service
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 192.168.22.0/24
    ports:
    - protocol: TCP
      port: 6379

上面的NetworkPolicy指示仅允许IP地址在192.168.22.0/24这个范围的客户端访问本PaaS服务。

至此,一个基本可用的基础PaaS服务就可以交付用户使用了。

组合起来

上面所说的是基于kubernetes构建基础PaaS服务的大概过程,为了简化用户使用,可以将上面的多步操作封装成一个大chart,最终只需要部署这个大的chart就可以快速搭建一个基本可用的PaaS服务了。封装大chart的方法参考helm官方文档,这里就不细讲了。

实例监控

对于这种基础服务,一般能找到现成的prometheus exporter,如redis_exporter,再配合prometheus及grafana,就可以很方便地实现对基础PaaS服务示例的监控。prometheus的配置方法可以参考以前的博文

运维操作

升级操作

还可以通过helm完成基础PaaS服务的升级操作,参考命令如下:

helm upgrade ${special_release_name} ${big_chart_name} -f custom_values.yaml

其它运维操作

其它运维操作,如备份还原等,这些光用chart就无能为力了,这里可以参考mysql-operator的方案,定义一些备份还原任务的自定义资源,基于这些自定义资源,配合kubernetes的job完成备份或还原操作。这属于比较进阶的,就不细讲了。

总结

经实践,基于Kubernetes构建基础PaaS服务确实比以前要快很多,交付效率得到很大的提升,很多基础性的工作,kubernetes本身也已经实现了,而且稳定可靠,可以很方便地与现有的很多开源解决方案整合。而且这个方案很容易复制到其它基础PaaS服务的构建过程中,基本模式都很类似。

但也不是全无代价的,kubernetes本身引入了较多的网络栈开销,另外为了确保pod能在node节点间漂移,使用kubernetes必然会引入分布式存储,这两者综合起来,还是对性能产生了不小的影响。因此最好在使用前进行一些的性能测试,得到一些性能对比数据,权衡下性能损耗,如果能接受,个人还是十分推荐使用该方案构建基础PaaS服务的。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券