After completing the discussion of basic Kubernetes networking with a typical inter-pod traffic scenario, Stuart Charlton tackled another confusing topic: an overview of what Kubernetes services are.

Stuart Charlton did his best to explain the concept of pods in the Kubernetes Networking Deep Dive webinar, but we were still a bit confused. Next step: let’s talk about typical inter-pod traffic scenario.

Pods are a basic building block of any Kubernetes-based deployment… but what exactly are they and how are they related to Kubernetes networking? Stuart Charlton unraveled that mystery in the Understanding Pods video (part of Kubernetes Networking Deep Dive webinar)

After describing the Kubernetes architecture in the introductory part of the excellent Kubernetes Networking Deep Dive webinar, Stuart Charlton focused on what matters most to networking engineers: Kubernetes networking model.

Yesterday I mentioned the giant glob of complexity called Kubernetes (see also more nuanced take on the topic). If you want to slowly unravel it, Kubernetes Architecture video from the excellent Kubernetes Networking Deep Dive webinar by Stuart Charlton is a pretty good starting point.

After answering the “why should I care about Kubernetes?” question, Stuart Charlton explained the Kubernetes principles you should keep in mind if you want to have a chance of understanding what’s going on.

Here’s what one of the engineers watching Stuart Charlton’s Kubernetes webinar wrote about it:

TL&DR: If you happen to like working with containers, you could use netsim-tools release 0.5 to provision your container-based Arista EOS labs.

Why does it matter? Lab setup is blindingly fast, and it’s easier to integrate your network devices with other containers, not to mention the crazy idea of running your network automation CI pipeline on Gitlab CPU cycles. Also, you could use the same netsim-tools topology file and provisioning scripts to set up container-based or VM-based lab.

What is containerlab? A cool project that builds realistic virtual network topologies with containers. More details…

I was listening to an excellent container networking podcast and enjoyed it thoroughly until the guest said something along the lines of:

With Kubernetes networking policy, you no longer have to be a networking expert to do container network security.

That’s not even wrong. You didn’t have to be a networking expert to write traffic filtering rules for ages.

Have you ever wondered what the Kubernetes fuss is all about? Why would you ever want to use it? Stuart Charlton tried to answer that question in the introduction part of his fantastic Kubernetes Networking Deep Dive webinar.

One of my readers sent me this question:

It would be nice to have a blog post or a webinar describing how to implement container networking in case when: (A) application does not tolerate NAT (telco, e.g. due to SCTP), (B) no DNS / FQDN, is used to find the peer element and (C) bandwidth requirements may be tough.

The only thing I could point him to is the Advanced Docker Networking part of Docker Networking Fundamentals webinar (available with free subscription) where macvlan and ipvlan are described.

One of my readers sent me a container security question after reading the Application Container Security Guide from NIST:

We are considering segregating dev/test/prod environments with bare-metal hardware. I did not find something in the standard concerning this. What should a financial institution do in your opinion?

I am no security expert and know just enough about containers to be dangerous, but there’s a rule that usually works well: use common sense and identify similar scenarios that have already been solved.

One of my readers wanted to know more about containers and wondered how ipSpace.net materials could help him. Here’s a short step-by-step guide:

I published this blog post to help ipSpace.net subscribers navigate through Docker- and containers-related material. You might want to skip it if you’re not one of them.