Kubernetes Pod Sidecar 简介

Sidecar 是一个独立的容器，与 Kubernetes pod 中的利用容器一起运行，是一种辅助性的利用。

Sidecar 的常见辅助性性能有这么几种：

  1. 服务网格 (service mesh) 代理
  2. 监控 Exporter（如 redis exporter)
  3. ConfigMap 或/和 Secret Reloader（如 Prometheus 的 Config Reloader)
  4. Auth Proxy（如 OAuth Proxy 等）
  5. 7 层反向代理和 Web 服务器
  6. 日志整合（审计日志独自发到某个日志渠道。..)
  7. Demo 或 AllInOne 利用（如 nextcloud 或 Jaeger AllInOne 等示例利用）
  8. ...

这里选几个场景细说一下，在服务网格的状况下，sidecar 负责从应用程序自身卸载服务网格中所有应用程序所需的性能--SSL/mTLS、流量路由、高可用性等，并施行部署各种高级公布模式，如断路器、金丝雀和蓝绿等。

作为数据立体组件，sidecar 通常由服务网格中的某种类型的管制立体治理。当 sidecar 路由利用流量并提供其余数据立体服务时，管制立体在必要时将 sidecars 注入 pod 并执行治理工作，例如更新 mTLS 证书并在须要时将其推送到适当的 sidecars。

日志整合场景下，Sidecar 被用来将多个利用实例的日志信息汇总并格式化为一个文件。

接下来进入本次的正题：将 NGINX （或 Caddy 等）作为 Sidecar 应用，次要用做反代和 web 服务器

场景假如

假如有这么一个场景：

我在应用原生的 Prometheus AlertManager, 我曾经有 Ingress.
我当初想要做 2 件事：

  1. 晋升 AlertManager UI 的并发能力（减少 buffer, cache; 启用 gzip 等）
  2. AlertManager 的某个 js（假如是 script.js), 我做了一点批改，但不心愿侵入式地批改 原生 AlertManager 二进制文件，而是把批改后 js 放到 nginx 的 www 目录，让 nginx 来用不同的 location 进行解决。

这种场景下，显然 Ingress 是无奈同时满足的。这时候就能够在 AlertManager Pod 里加个 NGINX 的 sidecar 来实现。

具体如下

NGINX Sidecar 典型应用步骤

  1. 创立 NGINX Conf 的 configmap; （监听 8080, 反向代理到后端的 9093)
  2. 创立 alertmanager script.js 的 configmap;

  3. 批改原 AlertManager 的 StatefulSets, 减少：

    1. NGINX Sidecar
    2. 3 个 volumes: 其中 2 个就是用于挂载下面的 ConfigMap, 另外一个 EmptyDir 用于挂载 nginx cache
  4. 批改 AlertManager Service 的端口，从 9093 改为 8080, name 从http 改为 nginx-http
  5. （可选）批改其余局部，如 Ingress 等，调整端口。

NGINX Conf 的 ConfigMap

具体如下：

apiVersion: v1kind: ConfigMapmetadata:  name: alertmanager-nginx-proxy-config  labels:    app.kubernetes.io/name: alertmanagerdata:  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: v1kind: ConfigMapmetadata:  name: alertmanager-script-js  labels:    app.kubernetes.io/name: alertmanagerdata:  script.js: >-    ...

批改 StatefulSets

批改的局部内容如下：

apiVersion: apps/v1kind: StatefulSetmetadata:  name: monitor-alertmanagerspec:  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: v1kind: Servicemetadata:  name: monitor-alertmanager  labels:    app.kubernetes.io/name: alertmanagerspec:  ports:    - name: nginx-http      protocol: TCP      # 批改以下 2 项      port: 8080      targetPort: nginx-http

最终成果

以这次的 AlertManager 为例，批改前：

批改后：(matcher 的例子更符合实际场景，并减少了多个示例。的确是很小的改变）

总结

Kubernetes 的 Pod 设计之初就定义为：一个 Pod 能够蕴含多个 Containers, 这为 Kubernetes 中 Pod 的 Sidecar 应用留下了无尽的设想空间。

Sidecar 个别是用来做辅助性能的，比方：

  1. 服务网格 (service mesh) 代理
  2. 监控 Exporter（如 redis exporter)
  3. ConfigMap 或/和 Secret Reloader（如 Prometheus 的 Config Reloader)
  4. Auth Proxy（如 OAuth Proxy 等）
  5. 7 层反向代理和 Web 服务器
  6. 日志整合（审计日志独自发到某个日志渠道。..)
  7. Demo 或 AllInOne 利用（如 nextcloud 或 Jaeger AllInOne 等示例利用）
  8. ...

咱们这次通过退出 NGINX 作为 7 层反向代理和 Web 服务器用处的 Sidecar 来进行演示，活泼地阐明了 Sidecar 的实用之处。

️参考文档

  • Pod | Kubernetes
本文由博客一文多发平台 OpenWrite 公布！