Видео

Thank you! Cheers!

Hi and thank you for your kind feedback! The scripts are stored here: github.com/gary-RR/myRUclips_video_AKS_private_clusters_part1

@@TheLearningChannel-Tech ❤

Hi, many thanks for your kind words! Yes, I will be adding more content later in the summer, just have been busy. Any particular topic you are interested in? Thanks!

@@TheLearningChannel-Tech I apreaciate your reply so much. on top of my head I am thinking intro to microservices, or baremetal and k8s, monitoring and observabiities, k8s on prem, etc. I hope you know how valuable your videos are.

@@violinalauradragan7001 I'm really humbled by your kind comments. I'm planning for a few Azure cloud-centric videos next but I will return to Kubernetes and consider your great suggestions, especially an intro to microservices and monitoring. Most of my Kubernetes thus far (except the last one) apply to both on-prem and cloud situations and the instructions to set up clusters from scratch apply to both VMs and bare-metal. If you have any questions about any of the videos or have questions/issues with the labs please post them and I will be more than happy to help if I can. Again, thank you very much for your very motivating kind words! Please take care!

Glad it was helpful!

Hi, thanks for your feedback. The tunnel is not a permanent construct and is only started any time when the two sides need to communicate and is shut down once the communication is completed. I'm currently planning other topics but if I get around it will consider your request. Thanks.

@@TheLearningChannel-Tech thanks!!

Thank you very much! Glad it was helpful!

I think I got it, the condition limited is two, both app and namespace match at the same time. - podSelector: matchLabels: app: products-business namespaceSelector: matchLabels: porducts-prod-db-access: allow

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: ruclips.net/video/aLq3O3l2LF4/видео.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: ruclips.net/video/pXEFZYl2Gu0/видео.html

Thank you too!

Hi, You can start with these: Docker and Kubernetes Intro ruclips.net/p/PLSAko72nKb8RZp3SH0KAZNCPvF71rqU7- Kubernetes Networking Series ruclips.net/p/PLSAko72nKb8QWsfPpBlsw-kOdMBD7sra-