When designing distributed systems for the cloud, containerisation comes in handy. It can be of great help when it comes to separation of concerns. Each one of the containers is doing one thing, and hopefully it is doing it well.
Quite often though, you will find yourself in a situation where you don't have the luxary of a fresh start from scratch. You probably will have tons of legacy code to somehow be made fit for the cloud. This is where the sidecar pattern, one of the single-node patterns described in Brendan Burns' free e-book "Designing Distributed Systems", can help.
A perfect example for an applied sidecar pattern is this: consider you have a legacy web service that you want to keep using. The service was created years ago, but its business logic is still valid. It does however one big flaw: it only supports plain HTTP, no TLS. You might not be able to adjust the service due to outdated framework versions, missing build environments, or you simply don't dare to change it in order not to break it. Well, this is where you will want to consider a sidecar acting as an SSL proxy to your legacy service. You will end up having two containers building a pod/group: one with your http web service, one with some proxy software like e.g. NGINX, APACHE, TRAEFIK or similar. You will see that this pattern can be a real life-saver or at least a big time-saver.
While this example is a pretty obvious one, there are legions of other scenarios where a sidecar makes perfectly sense. Go and get the book. It's a quick read but provides good inspiration. There's also a GitHub repo with hands-on labs for you to get your hands dirty: https://aka.ms/GetHandsOn.
O'Reilly, Brendan Burns: "Designing Distributed Systems", ISBN 9-781492-031772