失眠网 > 基于云原生的私有化交付PAAS平台

基于云原生的私有化交付PAAS平台

时间：2019-11-23 19:31:23

相关推荐

基于云原生的私有化交付PAAS平台

前言什么是云原生？从Docker到Kubernetes：小鲸鱼大记事docker起源容器编排之争CNCF创建尘埃落定CNCF - 生态的力量基于云原生的私有化交付PAAS平台传统交付痛点架构方案服务编排：Kubesphere一. 基于制品的方式定制自己的私有化交付方案。二. 简便图像化操作，极大简化操作流程。三. 基于kubesphere的业务部署经验分享。DevOps：基于Syncd构建服务自动化交付一、构建本地工具链二、基于Syncd进行服务打包构建服务监控：基于Nightingale构建企业级监控选型理由：实际规则配置演示总结

前言

大家好，我今天给大家带来的是基于云原生的私有化交付PAAS平台介绍。

这个话题有点大我们尽量慢慢来讲把，首先我们会渐进式的从云原生起源讲起，让大家对云原生有个大体认识，再由PAAS平台业务痛点引出基于云原生的私有化解决方案，最后我们会针对私有化交付三大核心问题详细做分析。

标题包含三大关键词。云原生、PAAS平台、私有化交付。

云原生：暂时可以简单理解为一种理念或者一种解决思想。

PAAS平台：多个核心业务服务作为一个整体平台去封装，以平台形式提供服务。

私有化交付：平台需要部署私有云环境中，要面对无网情况下依然可以运转。

下面我们针对以上概览详细做下介绍：

什么是云原生？

云原生的概念一直以来都很模糊，虽然云原生计算基金会（CNCF）给出了所谓的定义，但是并不能让大家很好的理解云原生的理念，为什么说是理念呢，因为云原生是一种思想，是一种解决方案，很抽象。

, 云原生应用的提出者之一的Pivotal在其官网上将云原生的定义概况为微服务、DevOps、持续交付、容器这四大特征，这也成了很多人对 Cloud Native的基础印象。

微服务（Microservice）

几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分。

DevOps

DevOps（Development和Operations的组合词）即开发、运维一体化。涉及软件在整个开发生命周期中的持续开发，持续测试，持续集成，持续部署和持续监控。

持续交付

持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。

容器（Container）

，Docker项目正式发布，，K8s项目也正式发布。

Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用。K8S是容器编排系统，用于容器管理，容器间的负载均衡

容器技术为何如此重要？

原因一：微服务最佳载体

容器技术支持跨语言的微服务部署，我们不需要把精力放在服务环境的安装上，而是把精力放在服务管控上面，另外可以精确控制每容器的资源占用。原因二：云原生发展基础

我们下面会讲到云原生第一个开源项目的k8s项目的底层运行时也是容器，如果说现在云原生之所以发展如此受欢迎这离不开容器的功劳。

这个容器技术就是我们的小鲸鱼docker，我们有必要讲一下它他发展历程。

从Docker到Kubernetes：小鲸鱼大记事

docker起源

年的后端技术领域，以 Cloud Foundry 为代表的开源 PaaS 项目，成为了当时云计算技术中的一股清流。它最核心的组件就是一套应用的打包和分发机制。会调用操作系统的 Cgroups 和 Namespace 机制为每一个应用单独创建一个称作“沙盒”的隔离环境，然后在“沙盒”中启动这些应用进程，这正是 PaaS 项目最核心的能力。

Docker 在 Cloud Foundry基础之上增加了镜像功能。镜像解决的恰恰就是打包这个根本性的问题。镜像中包含了完整的操作系统文件和目录，他可以做到本地环境和云端环境的高度一致，这正是 Docker 镜像的精髓。

在年到年这段时间里，Docker 项目的迅速走红催生出了一个非常繁荣的“Docker 生态”。在这个生态里，围绕着 Docker 在各个层次进行集成和创新的项目层出不穷。Docker 公司通过并购来完善自己的平台层能力。其中一个最成功的案例是对 Fig 项目的收购，后来改名为Fig Compose。

容器编排之争

年底的 DockerCon 上，Docker 公司雄心勃勃地对外发布了自家研发的 “Docker 原生” 容器集群管理项目 Swarm，不仅将这波“CaaS”热推向了一个前所未有的高潮，更是寄托了整个 Docker 公司重新定义 PaaS 的宏伟愿望。

Mesos 有着天生的两层调度机制让它非常容易从大数据领域抽身，转而去支持受众更加广泛的 PaaS 业务。在这种思路的指导下，Mesosphere 公司发布了一个名为 Marathon 的项目，而这个项目很快就成为了 Docker Swarm 的一个有力竞争对手。

年注定是一个神奇的年份。就在这一年的 6 月，基础设施领域的翘楚 Google 公司突然发力，正式宣告了一个名叫 Kubernetes 项目的诞生。而这个项目，不仅挽救了当时的 CoreOS 和 RedHat，还如同当年 Docker 项目的横空出世一样，再一次改变了整个容器市场的格局。

CNCF创建

Google、RedHat等开源基础设施领域玩家们，共同牵头发起了一个名为CNCF（Cloud Native Computing Foundation）的基金会。这个基金会的目的其实很容易理解：它希望，以Kubernetes项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以Docker公司为核心的容器商业生态。

为了打造出这样一条围绕Kubernetes项目的“护城河”，CNCF社区就需要至少确保两件事情：

Kubernetes项目必须能够在容器编排领域取得足够大的竞争优势；CNCF社区必须以Kubernetes项目为核心，覆盖足够多的场景；

尘埃落定

Kubernetes项目让人耳目一新的设计理念和号召力，很快就构建出了一个与众不同的容器编排与管理的生态。Kubernetes项目在GitHub上的各项指标开始一骑绝尘，将Swarm项目远远地甩在了身后。从API到容器运行时的每一层，Kubernetes项目都为开发者暴露出了可以扩展的插件机制，鼓励用户通过代码的方式介入Kubernetes项目的每一个阶段。

Kubernetes社区在之后得到了空前的发展。更重要的是，不同于之前局限于“打包、发布”这样的PaaS化路线，这一次容器社区的繁荣，是一次完全以Kubernetes项目为核心的“百家争鸣”。

10月，Docker公司出人意料地宣布，将在自己的主打产品Docker企业版中内置Kubernetes项目，这标志着持续了近两年之久的“编排之争”至此落下帷幕。

CNCF - 生态的力量

CNCF基提供了一个中立的合作平台，汇聚全球顶尖开发人员、终端用户和厂商，联合了华为、阿里、腾讯、亚马逊、微软、Salesforce等超过500家国际知名科技公司，共同努力打造一个良性发展的云计算生态。

目前，已经有多个项目从孵化到成熟，最终进入到毕业阶段。如：Kubernetes、Prometheus、Envoy、CoreDNS、containerd、TUF、Jaeger、Fluentd、Vitess、Helm。这些项目作为云原生的基础组件为后续其他提供底层依赖和发展参考。

这张全景图(原图地址)试图从云原生的层次结构，以及不同的功能组成上，让用户了解云原生体系的全貌，并帮助用户在不同组件层次去选择恰当的软件和工具进行支持。从总体来看，它将云原生生态分为以下几层：

Special:认证服务提供商/培训伙伴等Provisioning:资源调配如：自动化配置/镜像管理/安全等Runtime:容器的整个运行环境Orchestration Management :平台的编排和调度App Definition and Development:可以理解为容器平台的应用商店如:数据库/消息队列等Platform:众多的经过认证的平台供应商Observability and Analysis:包含了大量用于对平台进行监控

综上所述，CNCF Landscape全景图中包含了CNCF社区成熟或使用范围较广、具有最佳实践的产品和方案供用户在实际应用中选择，原来需要闭源方式自己开发个东西，现在你完全可以从CNCF的大社区中找到有社区维护的解决方案，这也许是就是云原生的魅力所在。

基于云原生的私有化交付PAAS平台

了解完云原生下面进入正题就是如何利用云原生解决私有化交付中的问题，进而打造一个PAAS平台，提升业务平台的复用性。

传统交付痛点

如上图：私有云会有明确的安全性要求

私有云服务无法连接外网，数据只能通过单向网闸形式进行摆渡到内网私有云。源代码只能存储在公司机房中，私有云只部署编译文件。服务会不定期迭代，另外为了保证服务稳定性需要自建独立业务监控。

基于以上要求面临的挑战大概有几点：

架构可迁移性差：服务之间配置复杂，多种异构语言需要修改配置文件，无固定服务DNS。部署运维成本高：服务依赖环境需支持离线安装，服务更新需本地运维人员手动完成，复杂场景下，完整一次部署大概需要数人/月的时间。监控运维成本高：监控需支持系统级/服务级/业务级监控，通知方式需支持短信、webhook等多种类型。

架构方案

我们的原则是拥抱云原生和复用已有能力，近可能使用业界已存在且成熟技术方案。

我们采用Kubesphere+K8S作为服务编排，处于安全性及简洁性考虑对Syncd进行二次开发完整Devops能力，监控系统上采用Nightingale+Prometheus方案。

如上图架构图

蓝色框内是我们底层PAAS集群，我们对业务服务通用服务统一进行了服务编排升级，用以解决架构迁移性差问题。红色框内，监控系统作为一种编排服务形式存在，所有监控项交付前配置好。用以解决监控系统运维成本高问题。紫色框内，服务容器可以实现跨网段自动拉取并自动化部署。用以解决服务服务部署成本高问题。

下面我们针对这三部分做下介绍。

服务编排：Kubesphere

KubeSphere 是打造一个以 Kubernetes 为内核的云原生分布式操作系统，它的架构可以非常方便地使第三方应用与云原生生态组件进行即插即用（plug-and-play）的集成，支持云原生应用在多云与多集群的统一分发和运维管理，同时它又是CNCF项目拥有活跃的社区。

Kubesphere选型理由有以下几点：

一. 基于制品的方式定制自己的私有化交付方案。

私有化镜像文件打包：

创建制品清单:

apiVersion: kubekey.kubesphere.io/v1alpha2kind: Manifestmetadata:name: samplespec:arches:- amd64...- type: kubernetesversion: v1.21.5components:helm:version: v3.6.3cni:version: v0.9.1etcd:version: v3.4.13containerRuntimes:- type: dockerversion: 20.10.8crictl:version: v1.22.0harbor:version: v2.4.1docker-compose:version: v2.2.2images:- dockerhub.kubekey.local/kubesphere/kube-apiserver:v1.22.1...

然后我们就可以通过命令进行导出了。

./kk artifact export -m manifest-sample.yaml -o kubesphere.tar.gz

私有化部署：

创建部署清单：

apiVersion: kubekey.kubesphere.io/v1alpha2kind: Clustermetadata:name: samplespec:hosts:- {name: kubesphere01.ys, address: 10.89.3.12, internalAddress: 10.89.3.12, user: kubesphere, password: "Kubesphere123"}- {name: kubesphere02.ys, address: 10.74.3.25, internalAddress: 10.74.3.25, user: kubesphere, password: "Kubesphere123"}- {name: kubesphere03.ys, address: 10.86.3.66, internalAddress: 10.86.3.66, user: kubesphere, password: "Kubesphere123"}- {name: kubesphere04.ys, address: 10.86.3.67, internalAddress: 10.86.3.67, user: kubesphere, password: "Kubesphere123"}- {name: kubesphere05.ys, address: 10.86.3.11, internalAddress: 10.86.3.11, user: kubesphere, password: "Kubesphere123"}roleGroups:etcd:- kubesphere01.py- kubesphere02.py- kubesphere03.pycontrol-plane:- kubesphere01.py- kubesphere02.py- kubesphere03.pyworker:- kubesphere05.pyregistry:- kubesphere04.pycontrolPlaneEndpoint:internalLoadbalancer: haproxydomain: lb.kubesphere.localaddress: ""port: 6443kubernetes:version: v1.21.5clusterName: cluster.localnetwork:plugin: calicokubePodsCIDR: 10.233.64.0/18kubeServiceCIDR: 10.233.0.0/18multusCNI:enabled: falseregistry:type: harborauths:"dockerhub.kubekey.local":username: adminpassword: Kubesphere123...

执行安装部署：

./kk create cluster -f config-sample.yaml -a kubesphere.tar.gz --with-packages --with-kubesphere --skip-push-images

原来大量复杂的k8s部署、高可用方案、harbor私有化镜像仓库等，均可以完成自动化安装，极大的简化了私有化交付场景下k8s组件部署难度。

二. 简便图像化操作，极大简化操作流程。

创建部署：流水线式创建一个容器服务的部署、存储、服务访问。

资源限制：限制容器的资源利用率&限制租户资源利用率。

远程登陆：容器远程登陆功能。

三. 基于kubesphere的业务部署经验分享。

私有化场景构建高可用服务实例部署，保障单实例挂掉不影响整体使用，我们要保证以下几点。

由于服务都需要有固定的网络标识和存储，所以我们需要创建 “有状态副本集部署” 。

apiVersion: apps/v1kind: StatefulSetmetadata:namespace: diyuname: ${env_project_name}labels:app: ${env_project_name}spec:serviceName: ${env_project_name}replicas: 1selector:matchLabels:app: ${env_project_name}template:metadata:labels:app: ${env_project_name}spec:containers:- name: ${env_project_name}image: ${env_image_path}imagePullPolicy: IfNotPresent

有状态副本集使用host反亲和性保证服务分散到不同host中。

....affinity:podAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm:labelSelector:matchExpressions:- key: appoperator: Invalues:- ${env_project_name}topologyKey: kubernetes.io/hostname....

服务与服务之间互相调用均使用k8s底层的dns进行配置。

集群内部依赖外部资源时需要设置为service，然后在内部提供服务。

kind: EndpointsapiVersion: v1metadata:name: redis-clusternamespace: diyusubsets:- addresses:- ip: 10.86.67.11ports:- port: 6379---kind: ServiceapiVersion: v1metadata:name: redis-clusternamespace: diyuspec:ports:- protocol: TCPport: 6379targetPort: 6379

借助 nip.io 域名实现服务动态域名解析调试。

nip.io可以自动根据请求的域名中设置ip信息，完成响应的ip信息映射。

# nslookup abc-service.diyu.10.86.67.11.nip.ioServer: 169.254.25.10Address: 169.254.25.10:53Non-authoritative answer:Name: abc-service.diyu.10.86.67.11.nip.ioAddress: 10.86.67.11

因此我们可以在构建ingress时直接使用该域名：

---kind: IngressapiVersion: networking.k8s.io/v1metadata:name: gatekeepernamespace: diyuspec:rules:- host: gatekeeper.diyu.10.86.67.11.nip.iohttp:paths:- path: /pathType: ImplementationSpecificbackend:service:name: gatekeeperport:number: 8000

挂载目录到宿主机,，有时候需要容器直接关联宿主机目录具体操作如下。

...spec:spec:...volumeMounts:- name: vol-datamountPath: /home/user/data1volumes:- name: vol-datahostPath:path: /data0

有状态部署工作负载，主要涉及 StatefulSet、Service、volumeClaimTemplates、Ingress，示例如下：

apiVersion: apps/v1kind: StatefulSetmetadata:namespace: diyuname: gatekeeperlabels:app: gatekeeperspec:serviceName: gatekeeperreplicas: 1selector:matchLabels:app: gatekeepertemplate:metadata:labels:app: gatekeeperspec:containers:- name: gatekeeperimage: dockerhub.kubekey.local/project/gatekeeper:v362imagePullPolicy: IfNotPresentports:- name: http-8000containerPort: 8000protocol: TCP- name: http-8080containerPort: 8080protocol: TCPresources:limits:cpu: '2'memory: 4GivolumeMounts:- name: vol-datamountPath: /home/user/data1affinity:podAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm:labelSelector:matchExpressions:- key: appoperator: Invalues:- gatekeepertopologyKey: kubernetes.io/hostnamevolumeClaimTemplates:- metadata:name: vol-dataspec:accessModes: [ "ReadWriteOnce" ]resources:requests:storage: 10Gi---apiVersion: v1kind: Servicemetadata:name: gatekeepernamespace: diyulabels:app: gatekeeperspec:ports:- name: "http-8000"protocol: TCPport: 8000targetPort: 8000- name: "http-8080"protocol: TCPport: 8080targetPort: 8080selector:app: gatekeepertype: NodePort---kind: IngressapiVersion: networking.k8s.io/v1metadata:name: gatekeepernamespace: diyuspec:rules:- host: gatekeeper.diyu.10.86.67.11.nip.iohttp:paths:- path: /pathType: ImplementationSpecificbackend:service:name: gatekeeperport:number: 8000- host: gatekeeper.diyu.10.86.68.66.nip.iohttp:paths:- path: /pathType: ImplementationSpecificbackend:service:name: gatekeeperport:number: 8080

DevOps：基于Syncd构建服务自动化交付

DevOps选型有很多，这里我们没有采用 Jenkins、GitRunner等等，而是使用了我们团队内部比较熟悉的Syncd进行二次开发。原因有两点：

处于安全考虑：我们的源码无法在本地存放，所以基于gitlab构建打包的方案，对我们用处不是很大，使用是一种资源浪费。功能简洁性：虽然Syncd已经停更2年多但是，但其核心的CICD功能比较完善且前后端拓展性强，我们可以很轻松拓展相应的功能。

Syncd核心思路：

1、从使用本地工具链构建打包镜像，这里可以把docker push当作git push理解。

2、通过Syncd拉取镜像包完成部署流程打包上线操作，通过打包时设置版本号便于服务回滚。

一、构建本地工具链

基于项目创建目录

#创建目录cd /Users/niuyufu/goproject/abc-servicemkdir -p devopscd devops

导入 Dockerfile，大家可基于业务自行创建。创建 tool.sh 文件

cat >> tool.sh << EOF#!/bin/sh###########配置区域###############模块名称，可变更module=abc-service#项目名称project=project1#容器名称container_name=${project}"_"${module}#镜像名称image_name=${project}"/"${module}#服务端口映射：宿主机端口:容器端口，多个逗号间隔port_mapping=8032:8032#镜像hub地址image_hub=dockerhub.kubekey.local#镜像tagimage_tag=latest###########配置区域###############构建工具action=$1case $action in"docker_push")image_path=${image_hub}/${image_name}:${image_tag}docker tag ${image_name}:${image_tag} ${image_path}docker push ${image_path}echo "镜像推送完毕，image_path: "${image_path};;"docker_login")container_id=$(docker ps -a | grep ${container_name} | awk '{print $1}')docker exec -it ${container_id} /bin/sh;;"docker_stop")docker ps -a | grep ${container_name} | awk '{print $1}' | xargs docker stopcontainer_id=`docker ps -a | grep ${container_name} | awk '{print $1}' | xargs docker rm`if [ "$container_id" != "" ];thenecho "容器已关闭，container_id: "${container_id}fiif [ "$images_id" != "" ];thendocker rmi ${images_id}fi;;"docker_run")docker ps -a | grep ${container_name} | awk '{print $1}' | xargs docker stopdocker ps -a | grep ${container_name} | awk '{print $1}' | xargs docker rmport_mapping_array=(${port_mapping//,/ })# shellcheck disable=SC2068for var in ${port_mapping_array[@]}; doport_mapping_str=${mapping_str}" -p "${var}donecontainer_id=$(docker run -d ${port_mapping_str} --name=${container_name} ${image_name})echo "容器已启动，container_id: "${container_id};;"docker_build")if [ ! -d "../output" ]; thenecho "../output 文件夹不存在，请先执行 ../build.sh"exit 1ficp -rf ../output ./docker build -f Dockerfile -t ${image_name} .rm -rf ./outputecho "镜像编译成功，images_name: "${image_name};;*)echo "可运行命令:docker_build 镜像编译，依赖../output 文件夹docker_run容器启动，依赖 docker_builddocker_login 容器登陆，依赖 docker_rundocker_push镜像推送，依赖 docker_build"exit 1;;esacEOF

执行项目打包，请确保产出物在./output中

$cd ~/goproject/abc-service/$sh build.shabc-service build okmake output okbuild done

利用 tool.sh 工具进行服务调试

tools.sh 执行顺序一般是这样的：./output产出物→docker_build→docker_run→docker_login→docker_push

$cd devops$chmod +x tool.sh#查看可运行命令$sh tool.sh可运行命令:docker_build 镜像编译，依赖../output 文件夹docker_run容器启动，依赖 docker_builddocker_login 容器登陆，依赖 docker_rundocker_push镜像推送，依赖 docker_build#docker_build举例：$sh tool.sh docker_build[+] Building 1.9s (10/10) FINISHED=> [internal] load build definition from Dockerfile0.1s=> => transferring dockerfile: 37B 0.0s=> [internal] load .dockerignore0.0s=> => transferring context: 2B... 0.0s=> exporting to image0.0s=> => exporting layers0.0s=> => writing image sha256:0a1fba79684a1a74fa200b71efb1669116c8dc388053143775aa7514391cdabf0.0s=> => naming to docker.io/project/abc-service 0.0sUse 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them镜像编译成功，images_name: project/abc-service#docker_run举例:$ sh tool.sh docker_run6720454ce9b66720454ce9b6容器已启动，container_id: e5d7c87fa4de9c091e184d98e98f0a21fd9265c73953af06025282fcef6968a5#可以使用 docker_login 登陆容器进行代码调试：$ sh tool.sh docker_loginsh-4.2# sudo -iroot@e5d7c87fa4de:~$#docker_push举例：$sh tool.sh docker_push130 ↵The push refers to repository [dockerhub.kubekey.local/citybrain/traj-service]4f3c543c4f39: Pushed54c83eb651e3: Pushede4df065798ff: Pushed26f8c87cc369: Pushed1fcdf9b8f632: Pushedc02b40d00d6f: Pushed8d07545b8ecc: Pushedccccb24a63f4: Pushed30fe9c138e8b: Pushed6ceb20e477f1: Pushed76fbea184065: Pushed471cc0093e14: Pushed616b2700922d: Pushedc4af1604d3f2: Pushedlatest: digest: sha256:775e7fbabffd5c8a4f6a7c256ab984519ba2f90b1e7ba924a12b704fc07ea7eb size: 3251镜像推送完毕，image_path: dockerhub.kubekey.local/citybrain/traj-service:latest#最后登陆Harbor测试镜像是否上传https://dockerhub.kubekey.local/harbor/projects/52/repositories/traj-service