K8S Pod Sidecar Application Scenario - Join NGINX Sidecar as an anti-generation and web server
This article was last updated on: July 24, 2024 am
Introduction to Kubernetes pod sidecars
A sidecar is a standalone container that runs alongside the application container in the Kubernetes pod and is a helper application.
There are several common accessibility features of sidecars:
- Service mesh proxy
- Monitoring exporters (e.g. redis exporter)
- ConfigMap or/and Secret Reloader (e.g. Prometheus’ Config Reloader)
- Auth Proxy (e.g. OAuth Proxies, etc.)
- Layer 7 reverse proxy and web server
- Log consolidation (audit logs are sent separately to a log channel…)
- Demo or AllInOne apps (example apps like nextcloud or Jaeger AllInOne)
- …
In the case of a service mesh, the sidecar is responsible for offloading all the functions required by the service mesh - SSL/mTLS, traffic routing, high availability, etc. - from the application itself, and implementing and deploying various advanced publishing patterns such as circuit breakers, canaries, and blue-green.
As a data plane component, sidecars are typically managed by some type of control plane in a service mesh. When sidecars route application traffic and provide additional data plane services, the control plane injects sidecars into pods when necessary and performs management tasks, such as updating mTLS certificates and pushing them to the appropriate sidecars when needed.
In the log integration scenario, the sidecar is used to summarize and format the log information of multiple application instances into a single file.
Let’s get down to business: NGINX (or Caddy, etc.) is used as a sidecar, mainly for anti-generation and web servers
Scenario assumptions
Suppose there is such a scenario:
I’m using the native Prometheus AlertManager, and I already have Ingress.
I want to do 2 things now:
- Improve the concurrency of the AlertManager UI (add buffer, cache; Enable gzip, etc.)
- A js of AlertManager (assuming yes
script.js
I made a little change, but instead of intrusively modifying the native AlertManager binary, I put the modified js into nginx’s www directory and let nginx handle it with a different location.
In this scenario, obviously Ingress cannot be satisfied at the same time. At this time, you can add an NGINX sidecar to the AlertManager pod.
The details are as follows
Typical steps for NGINX Sidecar use
- Create a configmap for NGINX Conf; (listening on 8080, reverse proxy to backend 9093)
- Create a configmap for alertmanager script.js;
- Modify the StatefulSets of the original AlertManager to add:
- NGINX Sidecar
- 3 volumes: 2 of which are used to mount the above ConfigMap, and the other EmptyDir is used to mount the nginx cache
- Change the port of the AlertManager Service from 9093 to 8080, name from
http
Changed tonginx-http
- Optionally, modify other parts, such as Ingress, to adjust the port.
NGINX Conf’s ConfigMap
The details are as follows:
1 |
|
AlertManager script.js ConfigMap
Details omitted.
First through the browserscript.js
Download it. Then modify as needed:
1 |
|
Modify StatefulSets
Some of the changes are as follows:
1 |
|
Modify the service port
As follows:
1 |
|
The final effect
Take AlertManager as an example, before the change:
Revised: (The matcher’s example is more in line with the actual scenario, and several examples have been added.) Minor changes indeed)
summary
Kubernetes pods were designed to contain multiple containers, leaving endless imagination for the use of pod sidecars in Kubernetes.
Sidecars are generally used for auxiliary functions, such as:
- Service mesh proxy
- Monitoring exporters (e.g. redis exporter)
- ConfigMap or/and Secret Reloader (e.g. Prometheus’ Config Reloader)
- Auth Proxy (e.g. OAuth Proxies, etc.)
- Layer 7 reverse proxy and web server
- Log consolidation (audit logs are sent separately to a log channel…)
- Demo or AllInOne apps (example apps like nextcloud or Jaeger AllInOne)
- …
This time we have demonstrated the usefulness of sidecars by adding NGINX as a sidecar for Layer 7 reverse proxy and web server.
🎉🎉🎉