💾💾💾 Moving the pod to another node in K8S may create connection issues for some period of time.

In Kubernetes, when a pod moves from one node to another—due to rebalancing, node failure, or pod eviction—there indeed exists a window of time during which other pods trying to communicate with the relocated pod might encounter issues. This scenario is possible due to several factors involved in the pod's networking and service discovery mechanisms within a Kubernetes cluster.

Kubernetes uses a combination of service resources, kube-proxy, and sometimes DNS for service discovery and load balancing. Here’s how these components typically handle pod IP changes:

1. Service Resources and Endpoints: Kubernetes Services act as a stable front for a set of pods. When a pod that's part of a service moves to a different node and gets a new IP address, the Service's Endpoints object is updated with the new IP. However, this update does not happen instantaneously; there's a brief period required for the control plane to detect the change and update the Endpoints.

2. kube-proxy: kube-proxy runs on each node and is responsible for routing traffic to the correct pod based on the Service's Endpoints. It watches the Kubernetes API for changes in Services and Endpoints and updates the node's iptables or ipvs rules accordingly. Again, this process is not immediate, and there's a short delay before the iptables or ipvs rules are updated to reflect the new pod location.

3. DNS Caching: If DNS is used for service discovery (via CoreDNS in Kubernetes), caching can also introduce a delay. The DNS records for a Service might still point to the old pod IP until the DNS TTL (time to live) expires and the record is refreshed.

Given these mechanisms, if another pod tries to communicate with the relocated pod in that brief window before the Endpoints and iptables/ipvs rules are updated, it might indeed try to send traffic to the old node/IP, leading to failed connections. However, Kubernetes is designed to minimize such disruptions:

- The control plane components are optimized to update Endpoints and propagate changes as quickly as possible.
- kube-proxy watches for these changes and updates routing rules promptly.
- Services and DNS provide abstraction layers that, under normal circumstances, shield clients from direct pod IP changes.

To mitigate potential issues, applications can implement retry logic for handling transient network failures, ensuring they can gracefully handle brief periods of unavailability or network hiccups as Kubernetes updates its internal state.

#kubernetes #k8s #devops #sre #softwareengineering #dns #iptable #proxy #networking

💾💾💾 Чим відрізняються Multicast від Anycast та Broadcast?

Multicast, Anycast и Broadcast – це методи доставки даних в мережах. Вони мають різні цілі та сценарії використання:

1. Broadcast
Broadcast відправляє дані до всіх вузлів у мережі або підмережі. Це найбільш базова форма розсилки, де кожен пакет даних копіюється та відправляється до кожного пристрою в локальній мережі.
Broadcast часто використовується для автоматичного отримання IP-адреси через DHCP або для пошуку пристроїв та служб у локальних мережах.

2. Multicast
Multicast дозволяє відправляти дані одночасно кільком отримувачам, але не всім у мережі. Отримувачі групуються за спеціальною multicast адресою, і дані відправляються лише цій групі.
Multicast застосовується для потокового мультимедійного контенту, онлайн-ігор та інших застосунків, де однакові дані потрібно доставити багатьом отримувачам одночасно.

3. Anycast
Anycast дозволяє відправляти дані до найближчого (у термінах мережевої топології) вузла з групи вузлів, які мають однакову IP-адресу. Це досягається за допомогою маршрутизації, яка вибирає найкоротший шлях до одного з декількох можливих отримувачів.
Anycast часто використовується для DNS-серверів, CDN (мереж доставки контенту) та для підвищення доступності та зниження затримки в мережевих службах.

Також варто зазначити що Broadcast не доступний в IPV6 мережах


#networking #broadcast #multicast #anycast

🖥 Today in our #ANDevHowTo rubric we will start demystify how #Kubernetes #networking works and will emulate it with local #Linux tools. And in the end we will try to write our own CNI plugin for #K8S

Will start from the simple one - container to container connection on the same pod.

❓ Also have small question: What command should be added to give ability to run request to the containers(pod) through the host ip 192.168.0.15?

Here is article:
https://github.com/creotiv/articles/blob/main/DevOps/K8S/Networking/package_routing_inside_the_k8s.md

#ANDevHowToNetworking #ANDevHowToKubernetes

Proceeding on demystifying #Kubernetes #networking.

In previous post we described the scheme and network setup for many containers in one pod. In this one we will describe how to link pods on the same node

Basically we have the same setup like in previous post, as we just adding one more pod. But the crucial part is #iptables rules for routing packages from one #networknamespace to another connecting 2 #veth pairs.

Remember that by default Kubernetes use iptables over #IPVS. An on big clusters better to switch to the IPVS as it more faster. You can do this by modyfing #ConfigMap of #KubeProxy

Here is full article: https://github.com/creotiv/articles/blob/main/DevOps/K8S/Networking/package_routing_inside_the_k8s.md

In the next post we will connect containers on different nodes. Stay in touch.

And don't forget to support my work with like

#ANDevHowTo #ANDevHowToKubernetes #ANDevHowToNetworking