I am planning to deploy to an AKS cluster and use an NGINX ingress controller, so that my micro-services will be internal to the cluster and the NGINX ingress controller will be the entry point to the micro-services.
One of my micro-services acts as an API gateway using the Ocelot library, and it implements the BFF pattern. So my ingress controller will have only one rule which will route requests made to the path "/(.*)" to the API gateway micro-service.
My question is - is this the conventional way to use an ingress controller and an API gateway micro-service? Somehow it feels redundant, although I could think that both have different responsibilities.
I don't think you would need an Ingress-Controller in this case, we use an API Gateway which is Ambassador and we simply have a public IP assigned to its kubernetes service.
If you don't expect other pods to expose themselves using Ingress objects, and that all traffic will be coming in your API gateway, I would simply drop the Ingress-controller and enable a Service of Type LoadBalancer for your API gateway pods
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.
I came to know that Nginx Ingress talks directly to pods NOT through a service.
Why endpoints and not services
The NGINX ingress controller does not use Services to route traffic to the pods. Instead it uses the Endpoints API in order to bypass kube-proxy to allow NGINX features like session affinity and custom load balancing algorithms.
Is this specific to this type of ingress or the idea is applicable to all ingresses?
I have microsevices and SPA app. All of them run on docker with docker compose. I have ocelot api gateway. But gateway knows ip address or container names of microservices for reaching . I add a aggregater service inside ocelot app. And I can reach to all services from aggregator service with ips.
But I want to move kubernates. I can scale services. there is no static ip. How can I configure .
I have identity service. This service knows clients ip addresses. Again same problem.
I searched for hours. I found some keywords. Envoy, Ingress, Consul, Ocelot . Can someone explain these things ?
It sounds like your question is related to Service Discovery.
In Kubernetes, the native way an "API Gateway" is implemented, is by using Ingress resources and Ingress Controllers. If you use a cloud provider, they usually have a product for this, or you can use a custom deployed within the cluster.
Service Discovery the Kubernetes way, is by referring to Service resources, e.g. the Ingress resources maps URLs (in your public API) to services. And your app is deployed as a Deployment resource, and all replicas (instances) is exposed via a Service resource. An app can also send request to other apps, and it should address that request to the Service resource for the other app. The Service resource does load balancing to the replicas of the receiving app.
you can use the service name to connect with the service instead of the client IP.
for example : curl HTTP://<service.name>.<namespace name>.svc.cluster.local
now if you are looking forward to list of API gateway and Identity server for Kubernetes
there are several options however it all depends on requirement.
For basic requirement nginx ingress and other ingress is available while if you are looking for API gateway :
Kong APi gateway
Ambassador api gateway
TYK API gateway
part of that service mesh can be also useful not in all scenario because it's mostly used for managing internal traffic (east-west).
API gateway is mostly used for managing edge traffic.
List of identity servers :
keycloak
Cognito IAM (AWS)
ingress controllers :
GCE ingress
Nginx ingress controller
Kong ingress controller
Gloo
HA proxy
AKS gateway
istio ingress
I have a kubernetes cluster created. According to security policies in the company, I need to have first an application gateway WAF in front that hits the cluster (which has a public IP). And as an ingress controller for this cluster I need to configure a Nginx ingress controller (also has a public IP). How can I connect or point the waf to the ingress controller? Is this possible to be done?
Thanks!
Native support for Nginx ingress controller is with a load balancer and not with app gateway. One possible approach is to create a nginx ingress controller loadbalancer as private using this link docs.
Now add this private Ip of load balancer as the backend pool of app gateway and now your app gateway should start serving the traffic from aks cluster.
The App gateway ingress controller as suggested by another comment is GA now but still is buggy. It takes time to update the backend pools on deploying new pods.
I have two applications deployed in different namespace in Google Kontainer engine(GKE). I want to use a single ingress resource (Google Load Balancer) to point to both the application using path based routing. Is it possible to have backend kubernetes services in multiple namespace behind a single ingress resource. If possible, how?
You'll have to setup an nginx ingress controller and deploy ingress resources per each namespace: https://github.com/kubernetes/kubernetes/issues/17088#issuecomment-221393102