Question is straightforward, but I've not been able to quite figure out which steps a request follows when it reaches kubernetes system.
Who first handle a received request? Ingress Controller, LoadBalancer, ClusterIP...
So, I know there are several ways to make pods externally accessible:
Creating a NodePort service.
Creating an LoadBalancer service.
Creating an Ingress rule.
Some questions here related with best-practices or mandatory facts?
Ingress is in front of a ClusterIP Service mandatory?
1.1 Could or shouldn't I create an Ingress in front of a NodePort or a LoadBalancer service?
Ingress Controllers are LoadBalancer Services? I mean, traefik or other Ingress Controllers are all of them deployed as LoadBalancer services?
Misunderstanding arises from several texts I've found over there:
image here: Seems LoadBalancer is placed first of Ingress Controllers.
image here: Seems Ingress is in front of a LoadBalancer.
Above questions arises from an attempt of expose externally a mongodb replicatset.
I've created a LoadBalancer for each node. Is this correct?
I'd like to create a domain using my Ingress Controller for those LoadBalancer. Can this be possible?
Is there point to create an Ingress in front of a headless service?
Ingress is in front of a ClusterIP Service mandatory?
If you want the service accessible externally, then you will need an externally accessible service. This can be a LoadBalancer service or an Ingress. A ClusterIP service is not accessible outside the cluster.
Could or shouldn't I create an Ingress in front of a NodePort or a LoadBalancer service?
You can create an Ingress in front of a NodePort or LoadBalancer, but there's no point in creating an Ingress in front of a LoadBalancer unless you want two different endpoints for accessing the same service (the LoadBalancer will get one IP and the Ingress Controller's own LoadBalancer will get another IP). However, using an Ingress will allow you to have additional functionality, such as SSL Certificates, which the standard LoadBalancer service resource does not (normally) provide
Ingress Controllers are LoadBalancer Services? I mean, traefik or other Ingress Controllers are all of them deployed as LoadBalancer services?
Correct. An Ingress controller opens an endpoint for traffic into the cluster, and then uses the ingress resources you create in the cluster to determine how and where to route the traffic.
The endpoint is a publicly accessible endpoint (unless you configure it to be an internal loadbalancer, in which case only machines within your corporate network will be able to access it).
The controller will normally update the Ingress resource in your cluster so you will see the IP of the loadbalancer belonging to the ingress
Related
I am new to Kubernetes and if I am not wrong, a service can be exposed inside the cluster using ClusterIP, and to the outside world using NodePort or LoadBalancer types. But my requirement is that I have a single container that has few REST APIs. I want that one API (the basic health check API) should be exposed to the outside, and the rest of the APIs should be available only within the cluster (accessible by other nodes). How can I achieve this?
You can keep your service as ClusterIP and use the ingress.
With ingress and ingress controller, you can setup and expose the desired path outside of cluster.
Ingress, you can install the Nginx ingress controller and create the ingress resource.
Read more about the nginx ingress controller setup and ingress reosuce setup.
We have seen on cloud that installing an ingress controller, automatically provisions a LoadBalancer and ingress rules configure Load Balancer itself.
We have used k8s-hard-way to establish a k8s cluster on bare metal
Here on a bare Metal K8s, we have already provisioned a LoadBalancer as described in this section
Can we use Ingress controllers like Kong / HAProxy/ Nginx to configure this existing Load Balancer via Ingress rules?
If Not, what should be the way?
So generally when Nginx ingress controller or any other controller like Kong got installed to K8s it creates the service type LoadBalancer.
You can create or modify the service that got created by default and map your LoadBalancer IP to the service.
apiVersion: v1
kind: Service
spec:
...
type: LoadBalancer
loadBalancerIP: 192.168.0.01
Now your controller service is pointing to the LB IP and your service is exposed to the internet.
Map LB IP to hostname in DNS and you are good to use it.
I understood Ingress can be used when we want to expose multiple service/routes with a single Load Balancer / public IP.
Now I want to expose my Nginx server to public. I have two choices
Set service type as LoadBalancer voila I got public IP
Use Nginx Ingress Controller
Now I can get my job done with Option 1 when or why would I choose Option 2 whats the advantage of having nginx with Ingress without Ingress ?
There is a difference between ingress rule (ingress) and ingress controller. So, technically, nginx ingress controller and LoadBalancer type service are not comparable. You can compare ingress resource and LoadBalancer type service, which is below.
Generally speaking:
LoadBalancer type service is a L4(TCP) load balancer. You would use it to expose single app or service to outside world. It would balance the load based on destination IP address and port.
Ingress type resource would create a L7(HTTP/S) load balancer. You would use this to expose several services at the same time, as L7 LB is application aware, so it can determine where to send traffic depending on the application state.
ingress and ingress controller relation:
Ingress, or ingress rules are the rules that ingress controller follows to distribute the load. Ingress controller get the packet, checks ingress rules and determines to which service to deliver the packet.
Nginx Ingress Controller
Nginx ingress controller uses LoadBalancer type service actually as entrypoint to the cluster. Then is checks ingress rules and distributes the load. This can be very confusing. You create an ingress resource, it creates the HTTP/S load balancer. It also gives you an external IP address (on GKE, for example), but when you try hitting that IP address, the connection is refused.
Conclusions:
You would use Loadbalancer type service if you would have a single app, say myapp.com that you want to be mapped to an IP address.
You would use ingress resource if you would have several apps, say myapp1.com, myapp1.com/mypath, myapp2.com, .., myappn.com to be mapped to one IP address.
As the ingress is L7 it is able to distinguish between myapp1.com and myapp1.com/mypath, it is able to route the traffic to the right service.
Accepted answer covered a lots of stuff already. All of the reasons are valid, apart from that the reason I am using ingress controller in aws is to minimize cost. I have multiple web applications which are running in kubernetes cluster aws. To access those applications instead of exposing individual application as LoadBalancer and creating individual ELB (each ELB cost money), I expose ingress controller service as LoadBalancer and created ingress rule for each.
Steps involve:
Ingress service, exposed as loadbalancer which created ELB in aws lets say elb1.aws.com
Ingress rule for each web applications, eg example.com, awesome.com, helloworld.com
Route53 mapping all mapped to same ELB, eg:
example.com -> elb1.aws.com
awesome.com -> elb1.aws.com
helloworld.com -> elb1.aws.com
I have this application I'm toying with. It consists of a Deployment (web with 3 instances running) with a Service exposing it (web-service). Right now the Service is of type LoadBalancer. I also added a Ingress directive to route my traffic as desired.
My question is...with the Ingress in place, should I switch the service type from LoadBalancer to NodePort or I should leave it in the same state?
From the documentation I have read so far it seems to be the general concensus to avoid nodePort as it is allocating ports on the physical (or virtual) nodes and that can become crowded after a time. Having a LoadBalancer automatically exposes a free port that the Google L3 Loadbalancer routes traffic to so no need to switch this to Nodeport.
Also note - once you have a working Ingress you don't need to expose the backend service as a LoadBalancer or NodePort at all - a normal internal kind: Service is enough to receive traffic from the Ingress.
As discussed here and described here, the service needs to be NodePort
I've been using Kubernete's LoadBalancer type service for incoming traffic on AWS. However, it is hard to terminate SSL at a service level, thus the idea of using an Ingress.
However, a LoadBalancer service allows us to make as many rolling changes as we like to our deployments without having to configure our DNS. By using Ingress, you can only use NodePort and while we would like to use Ingress, mapping DNS to new node when the pod is deployed on another node is a problem.
Is there a way to point a Kubernetes to point to an Ingress controller or use a service type LoadBalancer with an Ingress controller to terminate SSL.
We do not want to put our SSL certificates in a container, which is why this trouble.
Is there a way to point a Kubernetes to point to an Ingress controller or use a service type LoadBalancer with an Ingress controller to terminate SSL.
You can simply deploy the on metal (nginx, haproxy, traefic...) ingress controllers as a pod/daemonset/rc in your cluster, and front it with a service of type=loadbalancer. You can find these controllers in various places like: https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx, https://libraries.io/go/github.com%2Ftimelinelabs%2Fromulus, https://github.com/containous/traefik/blob/fa25c8ef221d89719bd0c491b66bbf54e3d40438/docs/toml.md#kubernetes-ingress-backend,