You don't need a sidecar to stream logs of squid, that's anti-pattern, instead just tell squid to write logs to /dev/stdout, like this:

  logfile_rotate 0
  cache_log stdio:/dev/stdout
  access_log stdio:/dev/stdout
  cache_store_log stdio:/dev/stdout

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:

  max_filedescriptors 1048576
  pid_filename /dev/shm/squid.pid
  cache_effective_user squid
  cache_effective_group squid

and deployment has these set, - UID 31 is squid user inside of container

  securityContext:
  runAsUser: 31
  runAsGroup: 31
  fsGroup: 31
  command: ["sh","-c","squid -z && sleep 3s; squid -N"]

▲ fsmunoz 9 hours ago | parent | next [-]

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.

	▲	merpkz 9 hours ago \| parent [-]
		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!

▲ MrDarcy 8 hours ago | parent | prev [-]

What is the purpose of putting the pid file into /dev/shm ? I’ve never seen that before and am curious to learn more about the technique.

▲

merpkz 2 hours ago | parent | next [-]

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.

▲

chuckadams 7 hours ago | parent | prev | next [-]

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.

	▲	xorcist 7 hours ago \| parent [-]
		Running squid in the foreground is "-N". It's not hard to find, there is a manpage and everything (ooh, ancient).

▲

parliament32 5 hours ago | parent | prev [-]

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.