Running squid in container is a bit tricky, since it is indeed an ancient piece of software, but I have managed to run it successfully before with squid configuration like this:
That's a more elegant approach. I usually just plow through obstacles, and the end result is not always ideal -- I like your approach better than the sidecar, I guess that I was using sidecars for other things and it sort of influenced my approach.
I'll try it your suggestions out and update the article, and thank you for your comment, already made sharing this worth it.
Don't even mention it, I have never used NetworkPolicy before, but now it seems like exactly the thing I am missing on my clusters to limit the blast radius if anything gets owned. It's quite incredible the amount of nftables firewall rules the k3s daemon just created for that example policy in your blog, now I am in rabbit hole trying to figure out how this all actually works under the hood. Thanks for this writeup!
Files in /dev/shm go away on reboot. Using a PID file at all in kubernetes is kind of odd (containerized things tend to run in the foreground as PID 1), but given squid's age, I imagine it requires it.
It ensures that if another process is spawned, it knows there's already a running process and refuses to run. An old school leader-election lease, in a sense. It's not necessary in a containerized (read: non-daemonized) environment.
None that I can remember, I was probably just testing something outside container and left it like that.
Now checking there is /run/squid created by Alpine so that could be used too.
