Video

Glad it was helpful!

Thank you!

Glad you liked it!

@@TheLearningChannel-Tech If you are someone who really likes learning fundamentals of things, how you can't like it 😉

Hi, the reason is that these pods are not routable outside their host worker nodes. If the destination pod tries to send the response directly to the source pod, its host wouldn't know how to send it as there are no entries in the route table to assist it, so the tunnels play the middleman role facilitating this communication.

Hi, yes when the source pod issues an ARP request, the Calico VTEP forwards it to the other node where the other pod responds, similar to the discussion of VXLAN overview discussion.

@@TheLearningChannel-Tech Thanks for the response. So basically when the ARP response comes back from destination VTEP, source VTEP being a switch will remember that certain MAC lives on this VTEP. So after ARP, when ping packet is sent, source VTEP will establish the UDP pipe between source and destination VTEPs. Does this seem like correct understanding?

@@vipinchawria Close, Calico is a CNI provider responsible for creating pods. It knows what pod (and its IP address) is assigned to what worker node. When the source pod issues an ARP, it basically says I'm looking for the MAC address of the pod that has this IP address. Calico VTEP examines the destination IP address and forwards it to the worker node that hosts that pod.

Hi, this provides an overview of ebpf: czcams.com/video/aLq3O3l2LF4/video.html

I'm trying to understand your question but if you are asking how a call from a pod on master is routed to a pod on node 1, it is done exactly like the scenario I explained in the video but is routed through the tunnel on node 1. Nothing is different.

@@TheLearningChannel-Tech correct but as soon as it reached tunnel on node 1 how it knows to which pod it needs to send the response as in the IP header which we captured on master there was no information (IP) about the pod on node 1 as it was NAT to node 1 tunnel IP address. I am trying to understand how the packet is routed from node 1 tunnel to pod on node 1 as the response arrives

@@rahulsawant485 This is a call/response situation. The tunnel on the callin server masqurates the calling pod's IP address and sends the request to ther side. The pod on the other side (server) thinks the tunnel on the other side made the call and sends the responds back to the tunnel on the other side. That tunnel is sitting there waiting for the results and as soon as it gets it, it simplay forward it to the pod.

Thank you. This statement "That tunnel is sitting there waiting for the results and as soon as it gets it, it simplay forward it to the pod." makes it clear

Hi, the VXLAN implementation is internal to Kubernetes and is used to provide connectivity among pods within the Kubernetes cluster.

Hi, yes, the NAT translation is done within the physical router. I just showed it outside the router for clarity.

@@TheLearningChannel-Tech Thanks a lot for clarification.

Thanks for letting for your feedback. This video was created three years ago before CentOS was discontinued.

Make sure you follow the instructions below and change the IP addresses to match your environment: # ------------------- Overlay setup --------------------- # To establish the udp tunnel (make sure to run these as root (sudo -i)): 1- On "ubuntu1" run: socat UDP:192.168.0.11:9000,bind=192.168.0.10:9000 TUN:172.16.0.100/16,tun-name=tundudp,iff-no-pi,tun-type=tun & #***Note that I removed "iff-up" switch from command on "ubuntu1" because I was getting an error. 2- On "ubuntu2" run: socat UDP:192.168.0.10:9000,bind=192.168.0.11:9000 TUN:172.16.1.100/16,tun-name=tundudp,iff-no-pi,tun-type=tun,iff-up & 3- Return to "ubuntu1" and run ip link set dev tundudp up #echo "Disables reverse path filtering" #sudo bash -c 'echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter' #sudo bash -c 'echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter' #sudo bash -c 'echo 0 > /proc/sys/net/ipv4/conf/br0/rp_filter' #sudo bash -c 'echo 0 > /proc/sys/net/ipv4/conf/tundudp/rp_filter

@@TheLearningChannel-Tech The ubuntu1 and ubuntu2 are on the same subnet, is it necessary to set up the UDP tunnel?

so suppose I want client A to access application in namespace X but not application in namespace Y; how to whitelist this at the namespace level when this client is coming from outside the cluster using the ingress controller

Hi, Which IPs are you referring to? The IP addresses of clients that are calling from outside the cluster? In that case, you'll need to leverage a firewall that sits before the external load balancer and ingress controller. This is because as you noticed the client IPs are natted.

@@TheLearningChannel-Tech yes, want to whitelist address of clients calling from outside the cluster; after using proxy protocol feature of the ingress controller, am able to see the actual client ips in the ingress controller; but am still trying to figure out how to get these ips whitelisted in the application pods which are reached through the ingress and are sitting in different namespaces per application

so the intention is to filter at the namespace level with each namespace allowing a different set of ips to access the application it contains;

I am coming to think that istio might be the solution here and will try that out; I don't think calico can help here. I read about the calico eBPF dataplane but not sure on it.

Glad it was helpful!

Glad it was helpful!

Glad it was helpful!

Great to hear!

Hi, Looks like you have skipped a lot of stuff in the presentation. I suggest you watch those discussions that start from the following URL that talks introduces the ingress concept, followed by how the load balancer and the ingress are related, and finally walks through setting up an ingress controller, the load balancer and some test service: czcams.com/video/pXEFZYl2Gu0/video.html

Thank you too!

Hi, You can start with these: Docker and Kubernetes Intro czcams.com/play/PLSAko72nKb8RZp3SH0KAZNCPvF71rqU7-.html Kubernetes Networking Series czcams.com/play/PLSAko72nKb8QWsfPpBlsw-kOdMBD7sra-.html

Thanks. Glad it was helpful.

You're very welcome!

Hi, which episode are you referring to? All CNIs provide the same basic functionality but differ in implementation. So, if you just want to set up a cluster, any CNI would work.

@@TheLearningChannel-Tech Thank you for replying. I am referring to Episode 2 of the series where you demonstrate how Flannel uses VXLAN for POD to POD communication across nodes. When I install cluster I see Calico as CNI Plugin. In order to see flannel , can I change to Flannel and then revert back to Calico?

@@453nabeel You'll have to uninstall Calico and then install Flannel. There is no way to swap CNIs.

@@TheLearningChannel-Tech is there any guide that shows how to remove Calico and install flannel? Because after testing flannel I will revert back to Calico by again installing it

Hi, The main idea behind cluster mesh is for very large organizations with geographically dispersed clients who want to improve latency by serving clients from the centers closer to them. Imagine the multinational companies where they may have clients in Asia, Europe, and North America. Having all the infrastructure concentrated in the US will create latency for clients that are in the other regions. The other benefit is fault tolerance, if one region goes down, other regions could pick up the slack. So those are the main aspirations behind a cluster mesh. The load balancing part requires intelligent load balancing, i.e. route traffic from the clients in a region to the services in the same region. The fault tolerance part requires that a failed cluster automatically fail over to other healthy clusters. At the time of recording that video, Cilium hadn't quite provided those features yet and I made a point of mentioning that in the conclusion section of the video. I haven't had a chance to revisit Cilium's cluster mesh to see if they have made any improvements.

@@TheLearningChannel-Tech Hm...I would think cloud providers would provide geographical load balancing via DNS to individual clusters in different cloud regions 🤔

@@jonassteinberg3779 Yes, that is true if you host them in the cloud.

Hi, IPVS has been part of Linux Kernel for quite some time now and is widely used in prod. The CNI providers such as Cilium are moving towards a newer technology called eBPF, here is a link to a video where I go into details: czcams.com/video/aLq3O3l2LF4/video.html

@@TheLearningChannel-Tech thanks, gary! I've watched your cilium video, but thank you for the tip, that's very helpful.