Should traffic from clients (outside world) to service inside k8s comes in through master nodes or worker nodes? and why?
From what i seen so far, docs are always showing LB pools consisting of master nodes instead of worker nodes. is there a reason for this?
in a big bluster, would it be more beneficial to send all traffic to a few designated worker nodes?
for example:
let say my k8s cluster has 2 master nodes, 4 worker nodes, and an external load balancer. most examples out there load balance incoming traffic to the 2 master nodes instead of the 4 worker nodes. why is this? is there a reason in term of efficiency/performance?
please advise. thank you.
What do you mean the traffic goes through worker nodes or master node? You expose your service in the pods to the outside world via NodePort or LoadBalancer. So who ever hits the LoadBalancer or reach the node on a particular port would be redirected to the corresponding service.
Related
I have two questions.
All the tutorials in the youtube says that, if the worker node internal IP is 10.10.1.0 then the pods inside the node will have internal IPs between 10.10.1.1 till 10.10.1 254. But in my Google Kubernetes Engine it is very different and I don't see any relation between them.
rc-server-1x769 ip is 10.0.0.8 but its corresponding node gke-kubia-default-pool-6f6eb62a-qv25 has 10.160.0.7
How to release the external ips assigned to my worker nodes.
For Q2:
GKE manages the VMs created in your cluster so if they go down or if there needs to be down/up scaling, VMs are created with the same characteristics. I do not believe what you are asking is possible (release). You will need to consider a private cluster.
Pod's CIDR and Cluster CIDR - it's different entities.
So Pod-Pod communication happens within Pod's CIDR, not within cluster CIDR.
Your nodes should have interfaces, which corresponds to your Pods CIDR. But from Cluster point of view, they have Cluster IP's. (kubectl output)
I have a single master cluster with 3 worker nodes. The master node has one network interface of 10Gb capacity and all worker nodes have a 40Gb interface. They are all connected via a switch.
I'd like to know if this might create a bottleneck if the data between nodes have to pass through the master node?
In general, I like to understand the communication flow between worker nodes. For instance, a pod in node1 sends data to a pod in node2, does the traffic go through the master node? I have seen the architecture diagram on the Kubernetes docs and it appears to be the case:
source: https://kubernetes.io/docs/concepts/overview/components/
If this is the case, it is possible to define a control plane network separate from the data plane by possibly adding another interface to worker nodes?
Please note that this is a bare-metal on-prem installation with OSS Kubernetes v1.20.
For instance, a pod in node1 sends data to a pod in node2, does the traffic go through the master node?
No. Kubernetes is designed with a flat network model. If Pod on node A send a request to Pod on node B, the inter-node traffic is directly from node A to node B as they are on the same IP network.
See also The Kubernetes network model
we have single kubernetes cluster which has worker nodes in multiple data-centres which are in different geography area.
we have a service endpoint which connect to the application pods which are in different data-centres. lets say application A has 2 pods running in Data-CentresY, 2 pods in Data-CentreZ and 2 pods in Data-CentreX. now when requests lands on a service endpoint it route traffic to all these 6 pods which are in different data-centres.
we want to implement a latency based routing for service endpoints where when requests lands on a workers node it should route traffic to its nearest pods or pod with low network latency.
any suggestion or guidance are much appreciated.
Use kube-proxy with ipvs mode and use sed - shortest expected delay
Refer: https://kubernetes.io/docs/concepts/services-networking/service/#proxy-mode-ipvs
So running and scaling a deployment running multiple pods on a single node works nicely, and when exposing the service with a type "nodePort" nicely balances requests to the virtual IP between the multiple pods on that individual node.
I've since added an additional node to my cluster, and when exposing the Service using nodePort and then running pods over 2 nodes, I of course need to specify each host specifically to hit the endpoints running in different pods on different nodes.
I would like to send requests to a single VIP and load balance accross the different nodes. I am running this small cluster on my home network, so my question is, is there anyway to send requests to a single VIP, and load balance across the nodes / pods without using an external load-balancer? E.g., is there some config within kubernetes to handle this?
I tried using a service type load balancer (instead of node port) but this didn't load balance accross nodes.
Take a look at Keepalived in Kubernetes.
The idea is to expose a Virtual IP (VIP) address per service, outside
of the kubernetes cluster. keepalived then uses VRRP to sync this
"mapping" in the local network. With 2 or more instance of the pod
running in the cluster is possible to provide HA using a single VIP
address.
In my view, if all your pods in both the nodes are attached to the same clusterIP then all pods will be load balanced between the 2 nodes. ClusterIp service works for you as internal load balancer..
I have a kubernetes setup that contains 4 minions (node1,2,3,4). I created a service that exposes port 80 as node port of 30010. There are 4 nginx pods that accepts the traffic from above service. However distribution of pods among nodes may vary. For example node 1 has 2 pods, node 2 has 1 pod and node 3 has 1 pod. Node 4 doesn't have any pod deployed. My requirement is, whenever I send a request to node1:30010 it should hit only 2 pods on node 1 and it should not hit other pods. Traffic should be routed to other nodes if and only if there is no pod in local node. For example node4 may have to route requests to node4:30010 to other nodes because it has no suitable pod deployed on it. Can I facilitate this requirement by changing configurations of kube-proxy?
As far as I'm aware, no. Hitting node1:30010 will pass traffic to the service, the service will then round robin the response.
Kubernetes is designed as a layer of abstraction above nodes, so you don't have to worry about where traffic is being sent, trying to control which node traffic goes to goes against that idea.
Could you explain your end goal? If your different pods are serving different responses then you may want to create more services, or if you are worried about latency and want to serve traffic from the node closest to the user you may want to look at federating your cluster.