基于云原生的私有化 PaaS 平台交付实践
作者:牛玉富,某知名互联网公司专家工程师。喜欢开源 / 热衷分享,对 K8s 及 golang 网关有较深入研究。
本文将解读如何利用云原生解决私有化交付中的问题,进而打造一个 PaaS 平台,提升业务平台的复用性。在进入正题之前,有必要先明确两个关键词:
- PaaS 平台:多个核心业务服务作为一个整体平台去封装,以平台形式提供服务。
- 私有化交付:平台需要部署私有云环境中,要面对无网情况下依然可以运转。
传统交付痛点
如上图:私有云会有明确的安全性要求
- 私有云服务无法连接外网,数据只能通过单向网闸形式进行摆渡到内网私有云。
- 源代码只能存储在公司机房中,私有云只部署编译文件。
- 服务会不定期迭代,另外为了保证服务稳定性需要自建独立业务监控。
基于以上要求面临的挑战大概有几点:
- 架构可迁移性差:服务之间配置复杂,多种异构语言需要修改配置文件,无固定服务 DNS。
- 部署运维成本高:服务依赖环境需支持离线安装,服务更新需本地运维人员手动完成,复杂场景下,完整一次部署大概需要 数人 / 月 的时间。
- 监控运维成本高:监控需支持系统级 / 服务级 / 业务级监控,通知方式需支持短信、Webhook 等多种类型。
架构方案
我们的原则是 拥抱云原生和复用已有能力,近可能使用业界已存在且成熟技术方案。
我们采用 KubeSphere+K8S 作为服务编排,处于安全性及简洁性考虑对 Syncd 进行二次开发完整 DevOps 能力,监控系统上采用 Nightingale+Prometheus 方案。
如上图架构图
- 蓝色框内是我们底层 PaaS 集群,我们对业务服务通用服务统一进行了服务编排升级,用以解决架构迁移性差问题。
- 红色框内,监控系统作为一种编排服务形式存在,所有监控项交付前配置好。用以解决监控系统运维成本高问题。
- 紫色框内,服务容器可以实现跨网段自动拉取并自动化部署。用以解决服务服务部署成本高问题。
下面我们针对这三部分做下介绍。
服务编排:KubeSphere
KubeSphere 的愿景是打造一个以 K8s 为内核的云原生分布式操作系统,它的架构可以非常方便地使第三方应用与云原生生态组件进行即插即用(plug-and-play)的集成,支持云原生应用在多云与多集群的统一分发和运维管理,同时它还拥有活跃的社区。
KubeSphere 选型理由有以下几点:
基于制品的方式定制自己的私有化交付方案
私有化镜像文件打包
创建制品清单 :
apiVersion: kubekey.kubesphere.io/v1alpha2
kind: Manifest
metadata:
name: sample
spec:
arches:
- amd64
...
- type: kubernetes
version: v1.21.5
components:
helm:
version: v3.6.3
cni:
version: v0.9.1
etcd:
version: v3.4.13
containerRuntimes:
- type: docker
version: 20.10.8
crictl:
version: v1.22.0
harbor:
version: v2.4.1
docker-compose:
version: v2.2.2
images:
- dockerhub.kubekey.local/kubesphere/kube-apiserver:v1.22.1
...
然后我们就可以通过命令进行导出了。
$ ./kk artifact export -m manifest-sample.yaml -o kubesphere.tar.gz
私有化部署
创建部署清单:
apiVersion: kubekey.kubesphere.io/v1alpha2
kind: Cluster
metadata:
name: sample
spec:
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.py
control-plane:
- kubesphere01.py
- kubesphere02.py
- kubesphere03.py
worker:
- kubesphere05.py
registry:
- kubesphere04.py
controlPlaneEndpoint:
internalLoadbalancer: haproxy
domain: lb.kubesphere.local
address: ""
port: 6443
kubernetes:
version: v1.21.5
clusterName: cluster.local
network:
plugin: calico
kubePodsCIDR: 10.233.64.0/18
kubeServiceCIDR: 10.233.0.0/18
multusCNI:
enabled: false
registry:
type: harbor
auths:
"dockerhub.kubekey.local":
username: admin
password: Kubesphere123
...
执行安装部署:
$ ./kk create cluster -f config-sample.yaml -a kubesphere.tar.gz --with-packages --with-kubesphere --skip-push-images
原来大量复杂的 K8s 部署、高可用方案、Harbor 私有化镜像仓库等,均可以完成自动化安装,极大的简化了私有化交付场景下 K8s 组件部署难度。
可视化界面极大简化操作流程
- 创建部署:流水线式创建一个容器服务的部署、存储、服务访问。
- 资源限制:限制容器的资源利用率 & 限制租户资源利用率。
- 远程登陆:容器远程登陆功能。
基于 KubeSphere 的业务部署经验分享
私有化场景构建高可用服务实例部署,保障单实例挂掉不影响整体使用,我们要保证以下几点。
1、由于服务都需要有固定的网络标识和存储,所以我们需要创建 “有状态副本集部署”。
apiVersion: apps/v1
kind: StatefulSet
metadata:
namespace: project
name: ${env_project_name}
labels:
app: ${env_project_name}
spec:
serviceName: ${env_project_name}
replicas: 1
selector:
matchLabels:
app: ${env_project_name}
template:
metadata:
labels:
app: ${env_project_name}
spec:
containers:
- name: ${env_project_name}
image: ${env_image_path}
imagePullPolicy: IfNotPresent
2、有状态副本集使用 host 反亲和性保证服务分散到不同 host 中。
....
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- ${env_project_name}
topologyKey: kubernetes.io/hostname
....
3、服务与服务之间互相调用均使用 K8s 底层的 DNS 进行配置。
4、集群内部依赖外部资源时需要设置为 Service,然后在内部提供服务。
kind: Endpoints
apiVersion: v1
metadata:
name: redis-cluster
namespace: project
subsets:
- addresses:
- ip: 10.86.67.11
ports:
- port: 6379
---
kind: Service
apiVersion: v1
metadata:
name: redis-cluster
namespace: project
spec:
ports:
- protocol: TCP
port: 6379
targetPort: 6379
5、借助 nip.io 域名实现服务动态域名解析调试。
nip.io 可以自动根据请求的域名中设置 IP 信息,完成响应的 IP 信息映射。
$ nslookup abc-service.project.10.86.67.11.nip.io
Server: 169.254.25.10
Address: 169.254.25.10:53
Non-authoritative answer:
Name: abc-service.project.10.86.67.11.nip.io
Address: 10.86.67.11
因此我们可以在构建 Ingress 时直接使用该域名:
---
kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
name: gatekeeper
namespace: project
spec:
rules:
- host: gatekeeper.project.10.86.67.11.nip.io
http:
paths:
- path: /
pathType: ImplementationSpecific
backend:
service:
name: gatekeeper
port:
number: 8000
6、挂载目录到宿主机,有时候需要容器直接关联宿主机目录具体操作如下。
...
spec:
spec:
...
volumeMounts:
- name: vol-data
mountPath: /home/user/data1
volumes:
- name: vol-data
hostPath:
path: /data0
7、有状态部署工作负载,主要涉及 StatefulSet、Service、volumeClaimTemplates、Ingress,示例如下:
apiVersion: apps/v1
kind: StatefulSet
metadata:
namespace: project
name: gatekeeper
labels:
app: gatekeeper
spec:
serviceName: gatekeeper
replicas: 1
selector:
matchLabels:
app: gatekeeper
template:
metadata:
labels:
app: gatekeeper
spec:
containers:
- name: gatekeeper
image: dockerhub.kubekey.local/project/gatekeeper:v362
imagePullPolicy: IfNotPresent
ports:
- name: http-8000
containerPort: 8000
protocol: TCP
- name: http-8080
containerPort: 8080
protocol: TCP
resources:
limits:
cpu: '2'
memory: 4Gi
volumeMounts:
- name: vol-data
mountPath: /home/user/data1
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- gatekeeper
topologyKey: kubernetes.io/hostname
volumeClaimTemplates:
- metadata:
name: vol-data
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 10Gi
---
apiVersion: v1
kind: Service
metadata:
name: gatekeeper
namespace: project
labels:
app: gatekeeper
spec:
ports:
- name: "http-8000"
protocol: TCP
port: 8000
targetPort: 8000
- name: "http-8080"
protocol: TCP
port: 8080
targetPort: 8080
selector:
app: gatekeeper
type: NodePort
---
kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
name: gatekeeper
namespace: project
spec:
rules:
- host: gatekeeper.project.10.86.67.11.nip.io
http:
paths:
- path: /
pathType: ImplementationSpecific
backend:
service:
name: gatekeeper
port:
number: 8000
- host: gatekeeper.project.10.86.68.66.nip.io
http:
paths:
- path: /
pathType: ImplementationSpecific
backend:
service:
name: gatekeeper
port:
number: 8080
DevOps:基于 Syncd 构建服务自动化交付
DevOps 选型有很多,这里我们没有采用 Jenkins、GitRunner 等等,而是使用了我们团队内部比较熟悉的 Syncd 进行二次开发。原因有两点:
- 处于安全考虑:我们的源码无法在本地存放,所以基于 gitlab 构建打包的方案,对我们用处不是很大,使用是一种资源浪费。
- 功能简洁性:虽然 Syncd 已经停更 2 年多但是,但其核心的 CICD 功能比较完善且前后端拓展性强,我们可以很轻松拓展相应的功能。
Syncd 核心思路:
- 从使用本地工具链构建打包镜像,这里可以把 docker push 当作 git push 理解。
- 通过 Syncd 拉取镜像包完成部署流程打包上线操作,通过打包时设置版本号便于服务回滚。
构建本地工具链
1、基于项目创建目录
#创建目录
cd /Users/niuyufu/goproject/abc-service
mkdir -p devops
cd devops
2、导入 Dockerfile,大家可基于业务自行创建。
3、创建 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
#镜像tag
image_tag=latest
###########配置区域##############
#构建工具
action=$1
case $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 stop
container_id=`docker ps -a | grep ${container_name} | awk '{print $1}' | xargs docker rm`
if [ "$container_id" != "" ];then
echo "容器已关闭,container_id: "${container_id}
fi
if [ "$images_id" != "" ];then
docker rmi ${images_id}
fi
;;
"docker_run")
docker ps -a | grep ${container_name} | awk '{print $1}' | xargs docker stop
docker ps -a | grep ${container_name} | awk '{print $1}' | xargs docker rm
port_mapping_array=(${port_mapping//,/ })
# shellcheck disable=SC2068
for var in ${port_mapping_array[@]}; do
port_mapping_str=${mapping_str}" -p "${var}
done
container_id=$(docker run -d ${port_mapping_str} --name=${container_name} ${image_name})
echo "容器已启动,container_id: "${container_id}
;;
"docker_build")
if [ ! -d "../output" ]; then
echo "../output 文件夹不存在,请先执行 ../build.sh"
exit 1
fi
cp -rf ../output ./
docker build -f Dockerfile -t ${image_name} .
rm -rf ./output
echo "镜像编译成功,images_name: "${image_name}
;;
*)
echo "可运行命令:
docker_build 镜像编译,依赖../output 文件夹
docker_run 容器启动,依赖 docker_build
docker_login 容器登陆,依赖 docker_run
docker_push 镜像推送,依赖 docker_build"
exit 1
;;
esac
EOF
4、执行项目打包,请确保产出物在 ./output 中
$cd ~/goproject/abc-service/
$sh build.sh
abc-service build ok
make output ok
build done
5、利用 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_build
docker_login 容器登陆,依赖 docker_run
docker_push 镜像推送,依赖 docker_build
#docker_build举例:
$sh tool.sh docker_build
[+] Building 1.9s (10/10) FINISHED
=> [internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 37B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B
... 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:0a1fba79684a1a74fa200b71efb1669116c8dc388053143775aa7514391cdabf 0.0s
=> => naming to docker.io/project/abc-service 0.0s
Use '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_run
6720454ce9b6
6720454ce9b6
容器已启动,container_id: e5d7c87fa4de9c091e184d98e98f0a21fd9265c73953af06025282fcef6968a5
#可以使用 docker_login 登陆容器进行代码调试:
$ sh tool.sh docker_login
sh-4.2# sudo -i
root@e5d7c87fa4de:~$
#docker_push举例:
$sh tool.sh docker_push 130 ↵
The push refers to repository [dockerhub.kubekey.local/citybrain/gatekeeper]
4f3c543c4f39: Pushed
54c83eb651e3: Pushed
e4df065798ff: Pushed
26f8c87cc369: Pushed
1fcdf9b8f632: Pushed
c02b40d00d6f: Pushed
8d07545b8ecc: Pushed
ccccb24a63f4: Pushed
30fe9c138e8b: Pushed
6ceb20e477f1: Pushed
76fbea184065: Pushed
471cc0093e14: Pushed
616b2700922d: Pushed
c4af1604d3f2: Pushed
latest: digest: sha256:775e7fbabffd5c8a4f6a7c256ab984519ba2f90b1e7ba924a12b704fc07ea7eb size: 3251
镜像推送完毕,image_path: dockerhub.kubekey.local/citybrain/gatekeeper:latest
#最后登陆Harbor测试镜像是否上传
https://dockerhub.kubekey.local/harbor/projects/52/repositories/gatekeeper
基于 Syncd 进行服务打包构建
1、项目配置
新增项目
设置 tool.sh 中生成的镜像地址。
设置构建脚本。
参照有状态工作负载填写构建脚本。
2、创建上线单
3、构建部署包执行部署
4、切换到 KubeSphere 查看部署效果。
至此已完成 DevOps 与 KubeSphere 的功能打通。
服务监控:基于 Nightingale 构建企业级监控
选型理由
- 可视化引擎:内置模板,开箱即用。
- 告警分析引擎:灵活管理、告警自愈、开箱即用。
- 支持 Helm Chart 一键完成应用及服务部署,私有化场景中我们只需要关心容器融合本地化即可。
$ git clone https://github.com/flashcatcloud/n9e-helm.git
$ helm install nightingale ./n9e-helm -n n9e --create-namespace
实际规则配置演示
- 配置告警规则,无缝支持 PromQL 灵活编写各种规则。
- 配置告警接收组
- 实际接收告警消息及恢复消息
总结
私有化交付下因业务场景不同,对云原生的应用选型也不相同。本文仅对我们自身业务场景做了介绍,如有问题欢迎指正,另外其他场景下的云原生应用也随时欢迎大家来和我交流探讨。
本文由博客一文多发平台 OpenWrite 发布!
基于云原生的私有化 PaaS 平台交付实践的更多相关文章
- 基于云原生DevOps服务自动化部署前端项目学习总结
本文主要以部署前端Vue项目为例,讲述了如何基于云原生DevOps服务自动化部署前端项目~从开发完成到线上环境,我们只需提交代码即可~ 一.引言 作为一名开发人员,日常工作中我们除了需要负责代码的开发 ...
- [置顶]
Docker学习总结(7)——云端基于Docker的微服务与持续交付实践
本文根据[2016 全球运维大会•深圳站]现场演讲嘉宾分享内容整理而成 讲师简介 易立 毕业于北京大学,获得学士学位和硕士学位:目前负责阿里云容器技术相关的产品的研发工作. 加入阿里之前,曾在IBM中 ...
- 给 K8s API “做减法”:阿里巴巴云原生应用管理的挑战和实践
作者 | 孙健波(天元) 阿里巴巴技术专家本文整理自 11 月 21 日社群分享,每月 2 场高质量分享,点击加入社群. 早在 2011 年,阿里巴巴内部便开始了应用容器化,当时最开始是基于 LXC ...
- 云端基于Docker的微服务与持续交付实践
云端基于Docker的微服务与持续交付实践笔记,是基于易立老师在阿里巴巴首届在线技术峰会上<云端基于Docker的微服务与持续交付实践>总结而出的. 本次主要讲了什么? Docker Sw ...
- 云原生时代的DevOps平台设计之道
开发人员与运维人员是 IT 领域很重要的两大人群,他们都会参与到各种业务系统的建设过程中去.DevOps 是近年间火爆起来的一种新理念,这种理念被很多人错误的解读为"由开发人员(Dev)学习 ...
- 云原生应用 Kubernetes 监控与弹性实践
前言 云原生应用的设计理念已经被越来越多的开发者接受与认可,而Kubernetes做为云原生的标准接口实现,已经成为了整个stack的中心,云服务的能力可以通过Cloud Provider.CRD C ...
- 腾讯云原生数据库TDSQL-C架构探索和实践
作为云原生技术先驱,腾讯云数据库内核团队致力于不断提升产品的可用性.可靠性.性能和可扩展性,为用户提供更加极致的体验.为帮助用户了解极致体验背后的关键技术点,本期带来腾讯云数据库专家工程师王鲁俊给大家 ...
- 云原生数据库TDSQL-C 容灾的实践和探索
云原生数据库TDSQL-C作为腾讯云架构平台部核心数据库产品之一,致力于为云上ToB用户和公司自研业务提供集高性能.低成本.大存储.低延迟.秒级扩缩容.极速回档.Serverless化七大特性于一体的 ...
- 【云原生下离在线混部实践系列】深入浅出 Google Borg
Google Borg 是资源调度管理和离在线混部领域的鼻祖,同时也是 Kubernetes 的起源与参照,已成为从业人员首要学习的典范.本文尝试管中窥豹,简单从<Large-scale clu ...
- 阿里开源 KT Connnect,轻量级云原生测试环境治理平台来啦!
作者| 阿里云技术专家 郑云龙(砧木) 目前越来越多的开发者开始采纳 Kubernetes 管理基础设施环境,并通过 Kubernetes 完成日常的开发,测试以及生产发布活动,为了能够有效的帮助开发 ...
随机推荐
- 乌克兰学者的学术图谱case1
0. 人物:米哈伊洛·兹古罗夫斯基Mykhailo Zakharovych Zghurovskyi,也拼写为Mykhailo Zgurovsky,(乌克兰语:Михайло Захарович Згу ...
- Leetcode: 586. Customer Placing the Largest Number of Orders
题目要求如下: 给出的例子如下: 简单地说就是要找出表中订单最多客户的ID. 使用如下的代码进行实现: import pandas as pd def largest_orders(orders: p ...
- 关于REACT范式的一些思考
关于REACT范式的一些思考 REACT范式经过近一年的探索,让我们在很多领域有了非常广泛的应用,它确实提升了很多之前无法解决的问题,比如大模型虽然在语言理解和交互式决策方面在任务中表现出令人印象深刻 ...
- IP一致性论文
IP一致性:指的是给定输入的图像,要求保持图像中的ID不变,IP可能是Identity Property,要求能够识别出是同一个身份. 目前通过IP的一致性技术,可以用于短视频短剧上,是一个新兴的市场 ...
- Linux驱动| Linux内核 RTC时间架构
上一篇文章我们给大家讲解了基于瑞芯微rk3568平台芯片hym8563驱动的移植,本文给大家详细讲解Linux内核的时间子系统. <Linux驱动|rtc-hym8563移植笔记> 一.L ...
- windows中MySQL迁移数据存放盘符位置
由于刚开始安装mysq时都选择了默认安装,数据存放在了c盘,后面数据量过大c盘不堪重负,所以迁移数据到D盘 windows中MySQL迁移数据存放盘符位置 参考: https://blog.csdn. ...
- MFC中CString转int,double
CString str=L"123"; int n=_wtoi(str); //n=123 double d=_wtof(str); //d=123.0000 Vs2012中编译
- CentOS7 压缩及打包的常用命令
gzip gzip 文件名 压缩文件 gzip -d 文件名 解压文件 gunzip 文件名 解压文件 gzip -1 #压缩级别 最高到9 默认是6级别 gzip -f # 强制覆盖同名压缩包 gz ...
- 精美的Vue3流程插件,欢迎使用。
dawn-flow 插件是博主使用Vue3自主封装的流程插件(持续迭代中). 截图: dawn-flow 采用拖拽方式创建流程. dawn-flow,开放了2个属性和2个事件,具体如下: 属性 Nod ...
- LaTeX 魔法注释
LaTeX magic comments,有点像 shebang,不过与 shebang 有细微区别,不要搞混. % !TeX root = main.tex % !TeX program = xel ...