以Kubernetes sidecar方式部署Nginx: 提供更好的Web性能
Web server's gzip
Web服务开启数据压缩,有利于节省带宽。服务器根据客户端请求头所带的Accept-Encoding
判断是否需要对返回数据进行压缩,通常支持的压缩格式是gzip。
应用gzip or Nginx gzip
开发人员可以选择在Web framework中开发一些middleware来实现Gzip,也可以选择使用Nginx gzip,将所有gzip放在nginx中完成。
放在nginx中实现的优势是nginx中gzip性能优秀,能很大程度地减少gzip带来的消耗,像Golang中系统自带库中实现的gzip性能上相比nginx就差很多,并且需要使用对象池进行优化,避免每次创建gzip对象带来的性能损耗,在CPU和内存上占用较大。
使用Nginx gzip替代应用gzip
如果使用Nginx实现的gzip,那么部署的时候可以有几种方案。
-
集中式nginx集群
nginx集中部署,通过配置反向代理服务各种应用,优势是部署方便,集中管理。劣势是更新路由也是牵一发动全身,并且需要及时拓容。 -
每个实例搭配nginx
原本对外暴露的应用现在通过nginx代理,1:1的方式部署,不用担心拓容的问题。需要解决的就是如何保证它们打包部署。
Sidecar in Kubernetes
这里讨论Kubernetes中部署Web服务的情况,遇到刚才的方案二,可以在Kubernetes中找到非常匹配的部署方法。
Kubernetes中最小部署单位称为Pod,Pod中可以部署1个以上的功能紧密联系的容器,并且它们共享网络、磁盘,也就是它们能通过localhost:port
访问到彼此,那以上的情况nginx作为gzip功能可以说和后端应用是紧密结合,所以可以以sidecar的形式部署。
Nginx配置
如果你的应用监听在8080端口,nginx监听在8090,可以如下配置
/etc/nginx/site.conf
user nginx;
worker_processes 1;
events {
worker_connections 1024;
}
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
gzip on;
gzip_min_length 256;
gzip_types application/javascript application/json text/css text/plain;
include /etc/nginx/conf.d/*.conf;
}
/etc/nginx/conf.d/site.conf
server {
listen 8090;
location / {
proxy_pass http://127.0.0.1:8088/;
proxy_set_header Host $http_host;
}
}
参考
I thirst for magic...