Sidecars are extra containers that run alongside the main container in a pod. Both sidecars and pods are k8s jargon terms. Pod is what k8s calls a running image

Sidecars are extra containers that run alongside the main container in a pod. Both sidecars and pods are k8s jargon terms. Pod is what k8s calls a running image, a container in Docker lingo. Pods have metadata like resource claims that k8s uses for scheduling. The point of the article is a bit like the distributed system analog of aspect oriented programming. A typical problem might be that you want all your network communications to be encrypted, but you don't want to configure SSL for every service, because the libraries are all different, configuration files to point at rotating certificates are all different, etc. So instead you run an SSL proxy in a sidecar, and make the traffic go through that instead. You sort of bolt on extra horizontal functionality onto your existing set of services. Operators are slightly orthogonal IMO. I think the core pattern of k8s, the control loop, is great for operational resilience, but it's a bit alien to many existing bits of software, so operators are the glue which converts an otherwise high-maintenance service into the control loop idiom. I think the article does have a point, it points to a unifying theme for writing apps for k8s, and it's not necessarily just a book ad.