liveBook · Manning

Sidecar process

As explained in Kubernetes in Action, Second Edition

The sidecar pattern places a complementary process in a separate container alongside a primary application process in the same pod.

A sidecar process runs in a separate container alongside a primary application process in the same pod. It provides a complementary service that the application needs, such as handling HTTPS, without requiring changes to the application code. A pod can have more than one sidecar. section 5.1.2 section 5.4

Put containers together only when they must run together. A frontend and backend usually belong in separate pods: replicating a shared pod would replicate both, even if only the frontend needs more instances. A sidecar instead complements the primary container in each pod. section 5.1.2 section 5.7

Add HTTPS with a proxy

An HTTP-only Node.js application can share its pod with an Envoy sidecar. Envoy accepts HTTPS requests, converts them to HTTP, and forwards them to the application. To try the two-container pod, run `kubectl port-forward kiada-ssl 8080 8443 9901`, then compare `curl localhost:8080` with `curl https://localhost:8443 --insecure`. The HTTPS test uses `--insecure` because the example certificate is self-signed and its hostname does not match localhost. Inspect each process separately with `kubectl logs kiada-ssl -c kiada` or `kubectl logs kiada-ssl -c envoy`. section 5.1.2 section 5.4.3

There are two lifecycle arrangements to distinguish:

  • A regular sidecar is an additional container alongside the main container. Normal containers receive termination signals at the same time, so the sidecar might stop first. section 5.5.4
  • A native sidecar is listed under `initContainers` with `restartPolicy: Always`. Available since Kubernetes 1.28, it starts during initialization, keeps running, restarts if it terminates, and stops after the regular containers. It can also serve init containers that run after it. section 5.5.4 section 6.4.4
Listing 5.5 Defining a native sidecar container
apiVersion: v1
kind: Pod
metadata:
  name: kiada-native-sidecar
spec:
  initContainers:                 #1
  - name: init-demo                                    
    image: luksa/init-demo:0.1                         
  - name: traffic-meter                        #2
    image: luksa/network-traffic-meter:0.1     #2
    restartPolicy: Always      #3
  - name: network-check
    image: luksa/network-connectivity-checker:0.1
  containers:
  - name: kiada
    image: luksa/kiada:0.2
    stdin: true
    ports:
    - name: http
      containerPort: 8080
  - name: envoy
    image: luksa/kiada-ssl-proxy:0.1
    ports:
    - name: https
      containerPort: 8443
    - name: admin
      containerPort: 9901

The Pod manifest shows a native traffic-meter sidecar declared among init containers with `restartPolicy: Always`, alongside regular application and Envoy containers. section 5.5.4

How Kubernetes in Action, Second Edition covers it

How deep it goes
Works through proxy testing and container logs, then explains native-sidecar startup, restart, and shutdown; does not detail proxy internals.
Examples
Uses an Envoy HTTPS proxy, curl and log checks, and a traffic-meter native-sidecar manifest.
What it assumes
Introduces pod grouping and sidecars while building on a previously deployed HTTP-only Node.js application.
What you can do after
Build it from scratch with a Pod manifest, then operate it using kubectl port-forward and container-specific logs.
How it connects
Links pod grouping and horizontal scaling to reverse proxies, init containers, and container life cycles.

Also explained in

Compare how 11 books explain sidecar process →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes in Action, Second Edition. The section links point to the parts of the book it draws on.