We are trying to figure out a microservice architecture where we have an API Gateway (Zuul in this case), now all the services that Zuul is redirecting requests to would also need to be exposed externally? It seems counter intuitive as all these services can have private/local/cluster access and gateway is the one that should be externally exposed. Is this correct assessment? In what scenarios would you want these backend services to be exposed externally?
-----
|-----
Normally, you would not expose your backend services externally. The gateway (or the ingress) serves as the external gateway and proxies the requests to the internal network.
I am familiar with one use case where I expose some services directly: I do not want to expose some admin services running on my cluster to the external world, but I want to expose them to my VPN, so I have an ingress forwarding traffic between the external network and the cluster, and nodePort services that expose admin apps to my VPN.
Related
I have 2 node js backend applications, they depend on each other, but I'm confused about how these 2 backends communicate in Kubernetes AWS EKS
In a default k8s setting, creating a service and registering pods into it will create an internal dns address each pod can use to reach another one.
So, if your services are named service-a and service-b, service-a can reach service-b by sending requests to the service-a host.
The FQDN for each service is service-<x>.<namespace>.svc.cluster.local
More information can be found here
In Openshift I have two services that I need to communicate with each other, I was wondering if you know a way to do that without exposing both microservices.
Example:
(via public endpoint) (exposed) (non public service)
User-request ----------> Service A ----------> Service B
Service A needs to request an endpoint on service B and for that, I am using DNS but to do that I need to expose Service B.
There is any way to do this scenario without exposing service B?
To expose Service A I run the command: "oc expose service/ServiceA"
When you create a Service of type ClusterIP you can directly talk to that service using its DNS name and that Service is available within the cluster. The default DNS name for these services is my-svc.my-namespace.svc.cluster.local.
When using oc expose service you are creating a "Route" that will then make a Service available externally (not what you want in this case).
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
As various google articles(Example : this blog) states that this(connecting Kube cluster through proxy and clusterIP) method isn’t suitable for a production environment, but it’s useful for development.
My question is why it is not suitable for production ? Why connecting through nodeport service is better than proxy and clusterIP ?
Lets distinguish between three scenarios where connecting to the cluster is required
Connecting to Kubernetes API Server
Connecting to the API server is required for administrative purposes. The users of your application have no business with it.
The following options are available
Connect directly to Master IP via HTTPS
Kubectl Proxy Use kubectl proxy to to make the Kubernetes API available on your localhost.
Connecting external traffic to your applications running in the Kubernetes Cluster. Here you want to expose your applications to your users. You'll need to configure a Service and they can be of the following types
NodePort: Only accessible on the NodeIPs and ports > 30000
ClusterIP: Internal Only. External traffic cannot hit a service of type ClusterIP directly. Requires ingress resource & ingress controller to receive external traffic.
LoadBalancer: Allows you receive external traffic to one and only one service
Ingress: This isn't a type of service, it is another type of Kubernetes resource. By configuring NGINX Ingress for example, you can handle traffic to multiple ClusterIP services with only on external LoadBalancer.
A Developer needs to troubleshoot a pod/service: kubectl port-forward: Port forwarding example Requires kubectl to be configured on the system hence it cannot be used for all users of the application
As you can see from the above explanation, the proxy and port-forwarding option aren't viable options for connecting external traffic to the applications running because it requires your kubectl installed and configured with a valid kubeconfig which grants access into your cluster.
I am trying to set up a conventional web app with a database in Kubernetes. I have accomplished it by configuring 2 services and 2 deployments - one for the app and one for the database. Now I would like to make my database accessible only from the app pods, ie not expose it to outside world like a service. Is it possible using only Kubernetes configuration?
There are following ways to expose the pods.
purpose is inter-service communication
Internally expose
service type=clusterIP
Headless-service clusterIP: None is used for database pods
Sometimes you don’t need or want load-balancing and a single service IP. headless-services
Externally expose
Exposing service to the customers.
service type=NodePort or type=LoadBalancer