共计 10354 个字符，预计需要花费 26 分钟才能阅读完成。
作者：牛玉富，某出名互联网公司专家工程师。喜爱开源 / 热衷分享，对 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: IfNotPresent2、有状态正本集应用 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: 63795、借助 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: 80006、挂载目录到宿主机，有时候须要容器间接关联宿主机目录具体操作如下。
...
spec:
spec:
...
volumeMounts:
- name: vol-data
mountPath: /home/user/data1
volumes:
- name: vol-data
hostPath:
path: /data07、有状态部署工作负载，次要波及 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: 8080DevOps：基于 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 devops2、导入 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
EOF4、执行我的项目打包，请确保产出物在 ./output 中
$cd ~/goproject/abc-service/
$sh build.sh
abc-service build ok
make output ok
build done5、利用 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 公布！
正文完