I want to create a cluster of RESTful web APIs in AWS EKS and be able to access them through a single IP (allowing kubernetes to load balance requests to each). I have followed the procedure explained the this link and have set up an example nginx deployment as shown in the following image:
The problem is that when I access the example nginx deployment via 172.31.22.183 it works just fine, but when I try to use the cluster IP 10.100.145.181 it does not yield any response in such a way that it seems to be unreachable.
What's the purpose of that cluster ip then and how can I use it to achieve what I need?
What's the purpose of that cluster ip then and how can I use it to
achieve what I need?
ClusterIP is local IP that is used internally in the cluster, you can use it to access the application.
While i think Endpoint IP that you got, is might be external and you can access the application outside.
AWS EKS and be able to access them through a single IP (allowing
kubernetes to load balance requests to each)
For this best practice is to use the ingress, API gateway or service mesh.
Ingress is single point where all your request will be coming inside it will be load balancing and forwarding the traffic internally inside the cluster.
Consider ingress is like Loadbalancer single point to come inside the cluster.
Ingress : https://kubernetes.io/docs/concepts/services-networking/ingress/
AWS Example : https://aws.amazon.com/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/
ClusterIP is an IP that is only accessible inside the cluster. You cannot hit it from outside cluster unless you use kubectl port-forward
Related
Exposing Service from a BareMetal(Kubeadm) Build Kubernetes Cluster to the outside world. I am trying to access my Nginx as a service outside of the cluster to get NGINX output in the web browser.
For that, I have created a deployment and service for NGINX as shown below,
As per my search, found that we have below to expose to outside world
MetalLb
Ingress NGINX
Some HELM resources
I would like to know all these 3 or any more approaches in such way it help me to learn new things.
GOAL
Exposing Service from a BareMetal(Kubeadm) Built Kubernetes Cluster to the outside world.
How Can I make my service has its own public IP to access from the outside cluster?
You need to set up MetalLB to get an external IP address for the LoadBalancer type services. It will give a local network IP address to the service.
Then you can do port mapping (configuration in the router) of incoming traffic of port 80 and port 443 to your external service IP address.
I have done a similar setup you can check it here in detail:
https://developerdiary.me/lets-build-low-budget-aws-at-home/
You need to deploy an ingress controller in your cluster so that it gives you an entrypoint where your applications can be accessed. Traditionally, in a cloud native environment it would automatically provision a LoadBalancer for you that will read the rules you define inside your Ingress object and route your request to the appropriate service.
One of the most commonly used ingress controller is the Nginx Ingress Controller. There are multiple ways you can use to deploy it (mainfests, helm, operators). In case of bare metal clusters, there are multiple considerations which you can read here.
MetalLB is still in beta stage so its your choice if you want to use. If you don't have a hard requirement to expose the ingress controller as a LoadBalancer, you can expose it as a NodePort Service that will accessible across all your nodes in the cluster. You can then map that NodePort Service in your DNS so that the ingress rules are evaluated.
I have two Kubernetes developpements: one with a Grafana pod, and the other with an InfluxDB pod.
I want:
1) to expose my Grafana:3000 to the outside word
2) Grafana to be able to connect to InfluxDB:8086
I've seen it done with two separate "services": one Grafana Service (type = NodePort, target port = 3000) and one InfluxDB service (type = ClusterIP, target port = 8086).
It works ok.
Yet can/should it be done with just one "service" ?
For north south traffic i.e exposing a service outside the cluster LoadBalancer or preferably ingress is better than NodePort because when NodePort is used if the Node IP or Port changes then the clients need to make changes in the endpoint that they are using to access the service.
For east-west traffic between services within the cluster clusterIP service is good enough.
Use ingress. You can use Nginx, Caddy, or other tool provide ingress service and define the routing of the ingress there.
I have a Kubernetes services that I would like to be accessible from outside the cluster.
I've setup Traefik and have created an Ingress file for that service and am able to go to 'somemadeupdomain.com' and access the service fine. (Having locally added a line in my hosts file).
However my question is with the service type, I've currently set as ClusterIP. I can access the service fine, so is it fine to continue to use that or should I use NodePort.
Of course if I use NodePort I'm aware that when doing minikube service list I'll get a specific URL created by Kubernetes to access that service, but I feel I don't need to do that as I have that ingress file?
Any explanation would be appreciated.
Thanks
As you are using ingress already it does not make much sense to use NodePort. As you already have a way to access your application. Its totally fine to have a service type you need at service level that you need for the internal access(within Kubernets) purpose.
Ingress will redirect your external traffic to your service within the cluster, so ClusterIP is a good choice. No need to use NodePort.
From Documentation
Ingress, added in Kubernetes v1.1, exposes HTTP and HTTPS routes from
outside the cluster to services within the cluster
What I have:
I have created one Kubernetes cluster using single node Rancher 2.0 deployment. which has 3 etcd, control nodes & 2 worker nodes attached to cluster.
What I did:
I deployed one API gateway to this cluster & one express mydemoapi service (no db) with 5 pods on 2 nodes on port 5000, which I don't want to expose publicly. So, I just mapped that service endpoint with service name in API gateway http:\\mydemoapi:5000 & it was accessible by gateway public endpoint.
Problem statement:
mydemoapi service is served in random fashion, not in round robin, because default setting of kube-proxy is random as per Rancher documentation Load balancing in Kubernetes
Partial success:
I created one ingress loadbalancer with Keep the existing hostname option in Rancher rules with this URL mydemoapi.<namespace>.153.xx.xx.102.xip.io & attached this service to ingress, it is served in round robin fashion, but having one problem. This service was using xip.io with public ip of my worker node & exposed publicly.
Help needed:
I want to map my internal clusterIP service into gateway with internal access, so that it can be served to gateway internally in round robin fashion and hence to gateway public endpoint. I don't want to expose my service publicly without gateway.
Not sure which cloud you are running on, but if you are running in something like AWS you can set the following annotation to true on your Service definition:
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
Other Cloud providers have similar solutions and some don't even have one. In that case, you will have to use a NodePort service and redirect an external load balancer such as one with haproxy or nginx to forward traffic to that NodePort
Another option is to not use an Ingress at all if you want to do round robin between your services is to change your kube-proxy configs to use either the old namespace proxy mode or the more enhanced ipvs proxy mode.
I'm building a container cluster using CoreOs and Kubernetes on DigitalOcean, and I've seen that in order to expose a Pod to the world you have to create a Service with Type: LoadBalancer. I think this is the optimal solution so that you don't need to add external load balancer outside kubernetes like nginx or haproxy. I was wondering if it is possible to create this using DO's Floating IP.
Things have changed, DigitalOcean created their own cloud provider implementation as answered here and they are maintaining a Kubernetes "Cloud Controller Manager" implementation:
Kubernetes Cloud Controller Manager for DigitalOcean
Currently digitalocean-cloud-controller-manager implements:
nodecontroller - updates nodes with cloud provider specific labels and
addresses, also deletes kubernetes nodes when deleted on the cloud
provider.
servicecontroller - responsible for creating LoadBalancers
when a service of Type: LoadBalancer is created in Kubernetes.
To try it out clone the project on your master node.
Next get the token key from https://cloud.digitalocean.com/settings/api/tokens and run:
export DIGITALOCEAN_ACCESS_TOKEN=abc123abc123abc123
scripts/generate-secret.sh
kubectl apply -f do-cloud-controller-manager/releases/v0.1.6.yml
There more examples here
What will happen once you do the above? DO's cloud manager will create a load balancer (that has a failover mechanism out of the box, more on it in the load balancer's documentation
Things will change again soon as DigitalOcean are jumping on the Kubernetes bandwagon, check here and you will have a choice to let them manage your Kuberentes cluster instead of you worrying about a lot of the infrastructure (this is my understanding of the service, let's see how it works when it becomes available...)
The LoadBalancer type of service is implemented by adding code to the kubernetes master specific to each cloud provider. There isn't a cloud provider for Digital Ocean (supported cloud providers), so the LoadBalancer type will not be able to take advantage of Digital Ocean's Floating IPs.
Instead, you should consider using a NodePort service or attaching an ExternalIP to your service and mapping the exposed IP to a DO floating IP.
It is actually possible to expose a service through a floating ip. The only catch is that the external IP that you need to use is a little unintuitive.
From what it seems DO has some sort of overlay network for their Floating IP service. To get the actual IP you need to expose you need to ssh into your gateway droplet and find its anchor IP by hitting up the metadata service:
curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
and you will get something like
10.x.x.x
This is the address that you can use as an external ip in LoadBalancer type service in kubernetes.
Example:
kubectl expose rc my-nginx --port=80 --public-ip=10.x.x.x --type=LoadBalancer