Life of a Packet [I] - Michael Rubin, Google

CNCF [Cloud Native Computing Foundation] · 98K views · 2017 · 34:19

Open on YouTube

Cloud, DevOps & reliabilityNetworking & internet infrastructuretalk

Why Stack Overflow recommends it

Stack Overflow users link it when explaining how pod-to-pod, egress and load-balanced traffic is routed, NATed and handled by kube-proxy in Kubernetes.

Recommended by 1 people across 1 different months, 2019 to 2021.

What it is

A KubeCon conference talk by Google's Michael Rubin that traces how a network packet travels through a Kubernetes cluster. It maps API objects like Services to their implementation, covers how GKE deploys this, and discusses common failure cases.

What people said

Recommends Jonas · 2019-11 · Stack Overflow · on “Kubernetes Pod communication across nodes, How does it work?”

How do those daemon sets replace the routing tables modifications and make sure pods can communicate across nodes? Networking can be customized with a kubenet-plugin or a CNI-plugin as described in Network Plugins [LINK] to the kubelet [LINK] that runs on every node. The Network Plugin is responsible for handling the routing, possibly by using kube-proxy [LINK] . E.g. Cilium CNI plugin is a complete replacement of kube-proxy [LINK] and is using eBPF instead of iptables [LINK] . How do daemon sets wich are also pods, influence the network and other pods which have diffrent namespaces? Yes, DaemonSet [LINK] is normal pods. Kubelet is a special node-component [LINK] that manage pods, except con

Cites pr-pal · 2019-12 · Stack Overflow · on “Kubernetes outbound request to use service IP”

I am assuming you are using Kubernetes in IPv4 mode. When you are accessing an external IP address from the kubernetes pod, the requests are source NAT'd. This would mean that the packet would have the IP address of the host's (VM?) ethernet interface through which the traffic flows out. Please whitelist this IP and see if that helps This would be a good reference: [this video] Please note that service IP is useful when other services want to discover and talk to other services and IP table (in kube-proxy ip-table mode) translates it to POD IP. Its not in play for the traffic originating from the given service

Cites Hendrik · 2020-03 · Stack Overflow · on “Q: Efficient Kubernetes load balancing”

I've been looking into Kubernetes networking, more specifically, how to serve HTTPS users the most efficient. I was watching this talk: [this video] and from 22:18 he explains what the problem is with a load balancer that is not pod aware. Now, how they solve this in kubernetes is by letting the nodes also act as a 'router' and letting the node pass the request on to another node. (explained at 22:46). This does not seem very efficient, but when looking around SoundCloud ( [LINK] ) actually seems to do something similar to this but with NodePorts. They say that the overhead costs less than creating a better load balancer. From what I have read an option might be using an ingress controller. Makin

Cites Dawid Kruk · 2021-07 · Stack Overflow · on “What is Kubernetes egress call flow?”

I think this question could be divided on 2 different topics: DNS resolution. Pod networking when trying to reach external sources. Answering both of this question could be quite lengthy but I will try to give you a baseline to it and add additional documentation that would be more in-depth. DNS resolution that is happening inside/outside of the cluster: As you've already stated you're using CoreDNS . It will be responsible in your setup for your DNS resolution. Your Pods will query it when looking for the domains that are not included locally (for example /etc/hosts ). After they've received the responses, they will contact external sources (more on that later). A side note! The DNS resolut