Kubernetes Pod Sidecar 简介
Sidecar 是一个独立的容器,与 Kubernetes pod 中的利用容器一起运行,是一种辅助性的利用。
Sidecar 的常见辅助性性能有这么几种:
- 服务网格 (service mesh) 代理
- 监控 Exporter(如 redis exporter)
- ConfigMap 或 / 和 Secret Reloader(如 Prometheus 的 Config Reloader)
- Auth Proxy(如 OAuth Proxy 等)
- 7 层反向代理和 Web 服务器
- 日志整合(审计日志独自发到某个日志渠道。..)
- Demo 或 AllInOne 利用(如 nextcloud 或 Jaeger AllInOne 等示例利用)
- …
这里选几个场景细说一下,在服务网格的状况下,sidecar 负责从应用程序自身卸载服务网格中所有应用程序所需的性能 –SSL/mTLS、流量路由、高可用性等,并施行部署各种高级公布模式,如断路器、金丝雀和蓝绿等。
作为数据立体组件,sidecar 通常由服务网格中的某种类型的管制立体治理。当 sidecar 路由利用流量并提供其余数据立体服务时,管制立体在必要时将 sidecars 注入 pod 并执行治理工作,例如更新 mTLS 证书并在须要时将其推送到适当的 sidecars。
日志整合场景下,Sidecar 被用来将多个利用实例的日志信息汇总并格式化为一个文件。
接下来进入本次的正题:将 NGINX(或 Caddy 等)作为 Sidecar 应用,次要用做反代和 web 服务器
场景假如
假如有这么一个场景:
我在应用原生的 Prometheus AlertManager, 我曾经有 Ingress.
我当初想要做 2 件事:
- 晋升 AlertManager UI 的并发能力(减少 buffer, cache; 启用 gzip 等)
- AlertManager 的某个 js(假如是
script.js
), 我做了一点批改,但不心愿侵入式地批改 原生 AlertManager 二进制文件,而是把批改后 js 放到 nginx 的 www 目录,让 nginx 来用不同的 location 进行解决。
这种场景下,显然 Ingress 是无奈同时满足的。这时候就能够在 AlertManager Pod 里加个 NGINX 的 sidecar 来实现。
具体如下
NGINX Sidecar 典型应用步骤
- 创立 NGINX Conf 的 configmap;(监听 8080, 反向代理到后端的 9093)
- 创立 alertmanager script.js 的 configmap;
-
批改原 AlertManager 的 StatefulSets, 减少:
- NGINX Sidecar
- 3 个 volumes: 其中 2 个就是用于挂载下面的 ConfigMap, 另外一个 EmptyDir 用于挂载 nginx cache
- 批改 AlertManager Service 的端口,从 9093 改为 8080, name 从
http
改为nginx-http
- (可选)批改其余局部,如 Ingress 等,调整端口。
NGINX Conf 的 ConfigMap
具体如下:
apiVersion: v1
kind: ConfigMap
metadata:
name: alertmanager-nginx-proxy-config
labels:
app.kubernetes.io/name: alertmanager
data:
nginx.conf: |-
worker_processes auto;
error_log /dev/stdout warn;
pid /var/cache/nginx/nginx.pid;
events {worker_connections 1024;}
http {
include /etc/nginx/mime.types;
log_format main '[$time_local - $status] $remote_addr - $remote_user $request ($http_referer)';
proxy_connect_timeout 10;
proxy_read_timeout 180;
proxy_send_timeout 5;
proxy_buffering off;
proxy_cache_path /var/cache/nginx/cache levels=1:2 keys_zone=my_zone:100m inactive=1d max_size=10g;
server {
listen 8080;
access_log off;
gzip on;
gzip_min_length 1k;
gzip_comp_level 2;
gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript image/jpeg image/gif image/png;
gzip_vary on;
gzip_disable "MSIE [1-6]\.";
proxy_set_header Host $host;
location = /script.js {
root /usr/share/nginx/html;
expires 90d;
}
location / {
proxy_cache my_zone;
proxy_cache_valid 200 302 1d;
proxy_cache_valid 301 30d;
proxy_cache_valid any 5m;
proxy_cache_bypass $http_cache_control;
add_header X-Proxy-Cache $upstream_cache_status;
add_header Cache-Control "public";
proxy_pass http://localhost:9093/;
if ($request_filename ~ .*\.(?:js|css|jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm)$) {expires 90d;}
}
}
}
AlertManager script.js ConfigMap
具体内容略。
先通过浏览器将 script.js
下载下来。而后按需批改:
apiVersion: v1
kind: ConfigMap
metadata:
name: alertmanager-script-js
labels:
app.kubernetes.io/name: alertmanager
data:
script.js: >-
...
批改 StatefulSets
批改的局部内容如下:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: monitor-alertmanager
spec:
template:
spec:
volumes:
# 减少 3 个 volumes
- name: nginx-home
emptyDir: {}
- name: html
configMap:
name: alertmanager-script-js
items:
- key: script.js
mode: 438
path: script.js
- name: alertmanager-nginx
configMap:
name: alertmanager-nginx-proxy-config
items:
- key: nginx.conf
mode: 438
path: nginx.conf
containers:
# 减少 NGINX sidecar
- name: alertmanager-proxy
args:
- nginx
- -g
- daemon off;
- -c
- /nginx/nginx.conf
image: "nginx:stable"
ports:
- containerPort: 8080
name: nginx-http
protocol: TCP
volumeMounts:
- mountPath: /nginx
name: alertmanager-nginx
- mountPath: /var/cache/nginx
name: nginx-home
- mountPath: /usr/share/nginx/html
name: html
securityContext:
runAsUser: 101
runAsGroup: 101
批改 Service 端口
如下:
apiVersion: v1
kind: Service
metadata:
name: monitor-alertmanager
labels:
app.kubernetes.io/name: alertmanager
spec:
ports:
- name: nginx-http
protocol: TCP
# 批改以下 2 项
port: 8080
targetPort: nginx-http
最终成果
以这次的 AlertManager 为例,批改前:
批改后:(matcher 的例子更符合实际场景,并减少了多个示例。的确是很小的改变)
总结
Kubernetes 的 Pod 设计之初就定义为:一个 Pod 能够蕴含多个 Containers, 这为 Kubernetes 中 Pod 的 Sidecar 应用留下了无尽的设想空间。
Sidecar 个别是用来做辅助性能的,比方:
- 服务网格 (service mesh) 代理
- 监控 Exporter(如 redis exporter)
- ConfigMap 或 / 和 Secret Reloader(如 Prometheus 的 Config Reloader)
- Auth Proxy(如 OAuth Proxy 等)
- 7 层反向代理和 Web 服务器
- 日志整合(审计日志独自发到某个日志渠道。..)
- Demo 或 AllInOne 利用(如 nextcloud 或 Jaeger AllInOne 等示例利用)
- …
咱们这次通过退出 NGINX 作为 7 层反向代理和 Web 服务器用处的 Sidecar 来进行演示,活泼地阐明了 Sidecar 的实用之处。
🎉🎉🎉
📚️参考文档
- Pod | Kubernetes
三人行, 必有我师; 常识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.