k8s 部署nginx 实现集群统一配置,自动更新nginx.conf配置文件 总结
Posted 寂寞的4角钱
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了k8s 部署nginx 实现集群统一配置,自动更新nginx.conf配置文件 总结相关的知识,希望对你有一定的参考价值。
k8s 部署nginx 实现集群统一配置,自动更新nginx.conf配置文件 总结
大纲
- 1 nginx镜像选择
- 2 创建configmap保存nginx配置文件
- 3 使用inotify监控配置文件变化
- 4 Dockerfile创建
- 5 调整镜像原地址使用阿里云
- 6 创建deploy部署文件部署nginx
- 7 测试使用nginx配置文件同步&nginx自动重启
直接使用https://hub.docker.com/_/nginx nginx镜像有几个问题
- 1 集群环境下需要手动的配置多个nginx.conf文件
- 2 集群环境下配置文件修改后需要 kubectl exec -it 到多个pod重启nginx
使用k8s configmap统一配置集群下所有nginx的配置,并使用inotify监听配置文件变化后自动重启
nginx镜像选择
nginx镜像地址 https://hub.docker.com/_/nginx 使用 nginx:1.23.3 作为基础镜像
此镜像的配置文件为 /etc/nginx/nginx.conf 可以看到配置文件会include /etc/nginx/conf.d 文件夹下的配置
只需把此文件夹与configmap挂载就可以使用自己的配置信息了
创建configmap
创建一个configmap 用来保存nginx的配置文件
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-config
data:
nginx.conf: |
server
listen 8080;
charset utf-8;
server_name localhost;
location /
root /usr/share/nginx/html;
index index.html index.htm;
使用inotify监控配置文件变化
可以使用inotify 实现对配置文件夹的监控,当文件夹内有.conf文件创建,修改,删除后重新启动nginx
可以创建一个脚本,此脚本监控 /etc/nginx/conf.d 下文件的变化
#!/bin/bash
configfile='.conf$'
#监听文件夹修改,删除事件
inotifywait -e modify,delete -mr --timefmt '%Y-%m-%d %H:%M:%S' --format '%T %w %f %e' /etc/nginx/conf.d | while read day time folder file event;
do
#判断变化的文件是否是.conf结尾的文件 注意正则判断需要使用[[]]
if [[ $file =~ $configfile ]]; then
nginx -t
# $?返回上一个命令的结束状态 0表示正常
if [ $? == 0 ]; then
nginx -s reload
fi
fi
done
再准备一个启动start.sh脚本用于启动nginx以及inotify监控
echo "start nginx"
# 启动nginx
nginx
# 启动监控 需要保持一个前台运行的程序 否则容器运行后就退出
./auto_reload.sh
inotify的使用可以参考 《linux-inotify工具监控文件状态变化总结》
Dockerfile创建
Dockerfile 内容如下,可以调整linux镜像源使用阿里云的镜像源
FROM nginx:1.23.3
VOLUME ["/data/service/logs","/docker/tmp","/data/service/store"]
WORKDIR "/data/service"
LABEL base.name="nginx-auto-reload"
LABEL base.desc="nginx-auto-reload"
#修改操作系统源地址 使用阿里云 可以不修改,但是由于网络原因会比较满
#注意 nginx:1.23.3 镜像使用的是debian 11.x (bullseye)
#需要使用对应的阿里云 镜像源 https://developer.aliyun.com/mirror/debian?spm=a2c6h.13651102.0.0.3e221b11W40Fzd
RUN echo "deb https://mirrors.aliyun.com/debian/ bullseye main non-free contrib" >/etc/apt/sources.list
RUN echo "deb-src https://mirrors.aliyun.com/debian/ bullseye main non-free contrib" >>/etc/apt/sources.list
RUN echo "deb https://mirrors.aliyun.com/debian-security/ bullseye-security main" >>/etc/apt/sources.list
RUN echo "deb-src https://mirrors.aliyun.com/debian-security/ bullseye-security main" >>/etc/apt/sources.list
RUN echo "deb https://mirrors.aliyun.com/debian/ bullseye-updates main non-free contrib" >>/etc/apt/sources.list
RUN echo "deb-src https://mirrors.aliyun.com/debian/ bullseye-updates main non-free contrib" >>/etc/apt/sources.list
RUN echo "deb https://mirrors.aliyun.com/debian/ bullseye-backports main non-free contrib" >>/etc/apt/sources.list
RUN echo "deb-src https://mirrors.aliyun.com/debian/ bullseye-backports main non-free contrib" >>/etc/apt/sources.list
RUN apt-get update
RUN apt-get install inotify-tools -y
ADD auto_reload.sh auto_reload.sh
RUN ln -snf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo 'Asia/Shanghai' >/etc/timezone
COPY ["auto_reload.sh","start.sh","./"]
RUN chmod 711 auto_reload.sh && chmod 711 start.sh
CMD ["./start.sh"]
需要使用对应的阿里云 镜像源 https://developer.aliyun.com/mirror/debian?spm=a2c6h.13651102.0.0.3e221b11W40Fzd
创建镜像后推送到阿里云私库,用于后续的使用
docker build -t nginx-auto-reload .
docker tag nginx-auto-reload registry.cn-hangzhou.aliyuncs.com/jimliu/nginx-auto-reload
docker push registry.cn-hangzhou.aliyuncs.com/jimliu/nginx-auto-reload
创建deploy部署文件部署nginx
部署deploy.yaml 内容如下
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx-auto-reload
template:
metadata:
labels:
app: nginx-auto-reload
spec:
# 容器配置
imagePullSecrets:
- name: myaliyunsecret
hostname: nginx-host
subdomain: nginx-inner-domain
containers:
- image: registry.cn-hangzhou.aliyuncs.com/jimliu/nginx-auto-reload:latest
name: nginx-containers
# 挂载文件夹
volumeMounts:
- mountPath: "/etc/nginx/conf.d/"
name: config-volume
volumes:
- name: config-volume
configMap:
name: nginx-config
---
# 外部访问的接口
apiVersion: v1
kind: Service
metadata:
name: nginx-auto-reload-service
spec:
ports:
- protocol: TCP
port: 18080
targetPort: 8080
nodePort: 18080
name: http8080
#暴露两个接口用于测试 nginx重启
- protocol: TCP
port: 18081
targetPort: 8081
nodePort: 18081
name: http8081
selector:
app: nginx-auto-reload
部署nginx并测试
创建configmap
部署nginx
kubectl apply -f n-deployment.yaml
此步 nginx部署完成 service创建成功
测试nginx
8080端口访问成功
8081端口还无法访问
修改configmap中nginx配置文件 开放8081端口
等待configmap同步更新nginx pod中的配置文件
K8sHelm配置图形,prometheu(采集的自定义指标转化为集群内的量度指标,与hpa结合,实现自动伸缩)
目录
一 Helm配置图形
部署kubeapps应用,为Helm提供web UI界面管理
添加阿里云的库,拉取kubeapps
helm repo add apphub https://apphub.aliyuncs.com
helm search repo kubeapps
helm pull bitnami/kubeapps
编辑value.yaml文件
修改仓库位置,global全局
启用ingress方式进行外部访问,添加域名
修改镜像位置为私有仓库中bitnami项目
准备yaml文件中需要的镜像
将需要的镜像全部上传至私有仓库中的bitnami项目中
编辑postgresql的配置文件value.yaml
修改仓库位置,global全局,确定镜像拉取位置
创建新的ns为kubeapps进行隔离,指定ns进行安装
查看ns中节点状况
查看ns中节点所有信息
查看ns中的svc信息
查看ns为kubeapps的ingress信息
查看ingress的详细信息,此域名有2个后端
查看ingress所分配的对外IP,(前提ingress已经部署成功)
添加域名解析
集群外部访问域名进行测试
此ns中创建sa :kubeapps-operator
此ns中创建clusterrolebinding: kubeapps-operator
集群角色(cluser-admin)绑定与授权rbac
获取token
查看登陆token
需要做解析,不然登陆会报错
网页登陆
查看此ns中部署
查看所有ns中所有部署
图形化添加仓库URL到helm
添加成功
kubeapps结合harbor仓库管理helm应用
查看pod的健康状况,集群内部访问成功
集群外部使用ingress方式访问
添加域名解析
外部访问测试
增加副本数
增加副本数量至3个
外部访问成功,且负载均衡
版本更新
(v1-v2)
外部访问测试
版本回滚
1是404!!!
选择2
可以回滚成功
删除
二 prometheus
简介
Prometheus 是由 SoundCloud 开源监控告警解决方案,与Kubernetes同属CNCF,也是仅次于k8s的第二大开源项目。Prometheus 提供了通用的数据模型和便捷的数据采集、存储和查询接口,同时基于Go实现也大大降低了服务端的运维成本,目前已支持Kubernetes、Etcd、Consul等多种服务发现机制。
相较于zabbix,zabbix监控服务,Prometheus监控应用。
Prometheus监控:
把普罗米修斯采集的自定义指标转化为集群内的指标,为量度指标,与hpa结合,实现自动伸缩
metrics-server只能监控核心指标:cpu和mem,监控其他指标使用prometheus
Prometheus Server
直接从HTTP接口或者Push Gateway拉取指标(Metric)数据。Prometheus Server在本地存储所有采集的指标(Metric)数据,并在这些数据上运行规则,从现有数据中聚合和记录新的时间序列,或者生成告警。Alertmanager
根据配置文件,对接收到的告警进行处理,发出报警。在Grafana或其他API客户端中,可视化收集的数据。exporters
:负责向prometheus server做数据汇报的程序统。而不同的数据汇报由不同的exporters实现,比如监控主机有node-exporters,mysql有MySQL server exporterpull metrics
:正常拉取,server从agent正常拉取,pod内的附属容器作为普罗米修斯的agent,pod内loclahost可以采集,客户端应用上传到网关,普罗从网关拉取web Ui
:主要通过grafana来实现webui展示
metrics-server只能监控核心指标:cpu和mem,监控其他指标:如应用,数据格式和k8s不兼容,需要Grafana插件,接入api-server(身份键权)
prometheus-operator监控:
https://github.com/coreos/prometheus-operator/
1 部署prometheus-operator集群监控
添加aliyun的repo源,拉取chart到本地
解压后进入工作目录
(1)grap:图像化
(2)kube-metrics :数据格式转化
(3)prometheus-node-exporter:取核心指标,与应用结合(nginx-node,mysql-node)
准备好4个value文件中需要的镜像,上传至私有仓库
修改主value.yaml文件和各个子服务value.yaml,共4个value.yaml文件,修改镜像路径到私有harbor仓库,打开ingress服务并添加hosts.
主yaml文件修改(3个ingress和8个镜像位置):
修改grafana目录下的yaml文件(4个镜像和1个ingress)
cd charts/
cd grafana/
vim values.yaml
修改kube-state-metrics目录下的yaml文件(1个镜像)
cd kube-state-metrics/
vim values.yaml
创建namespace,并指定namespace安装
查看ingress状态
查看节点的状态
添加解析
网页访问测试
测试成功
选择prometheus
成功抓取到数据(注意时间同步)
2 使用prometheus-operator集群监控nginx
Loadbalancer
搜索nginx,使用helm图形化界面安装nginx
部署9.4.2版本的
修改yaml文件中私有仓库位置为reg.westos.org,指定ns
私有仓库中准备镜像
nginx成功部署,可以看到svc分配的IP地址
查看svc分配的IP地址
访问IP,可以看到nginx发布页面!!
此时的nginx还无法被prometheus发现,原因是未添加对应的标签release=prometheus-operator!!!
添加标签给nginx
此时在prometheus.westos.org下的status中的Service Discovery可以看到被发现的nginx服务
选择nginx的访问流量指标
点击Graph 添加Graph
可以看到图形
3 prometheus实现k8s集群的hpa动态伸缩(nginx)
由于数据不兼容,需要进行转化
添加prometheus-adapter插件
准备镜像
编辑values.yaml文件,修改镜像的信息
9090: prometheus的server的端口
(无头服务)
进入一个镜像,查看它是否有解析
可以看到一个pod中有两个容器,其中一个是nginx服务本身,另一个:9113端口是对prometheus监控开放的agent(metrics的)
。
指定namespace安装
查看有了custom.metrics
!!!数据格式可以匹配
查看pod信息
一个pod内两个容器
获取nginx的访问流量指标
获取nginx的访问流量指标,以python格式输出,发现value为233m
使用hpa测试监控
设定平均值为10个访问请求
hpa:平均和固定值
执行yaml文件
查看nginx的hpa
使用hey访问nginx,给予压力
将hey的二进制程序放到/usr/local/bin/
设定每秒25个请求去访问nginx,10*1000=10000
持续查看hpa状况,可以看到集群根据压力大小进行动态添加副本,实现动态伸缩
yaml文件中设定了每个pod最多10个请求,所以,需要3个replicas之后就可以稳定!!!
hpa的伸缩算法:<0.9和<1.1
选择graph可以查看到每个时刻的数据(访问nginx的请求)
以上是关于k8s 部署nginx 实现集群统一配置,自动更新nginx.conf配置文件 总结的主要内容,如果未能解决你的问题,请参考以下文章
K8sHelm配置图形,prometheu(采集的自定义指标转化为集群内的量度指标,与hpa结合,实现自动伸缩)