I have a question about following architecture, I could not find a clear cut answer in the Kubernetes documentation may be you can help me.
I have a service called 'OrchestrationService' this service is dependant to 3 other services 'ServiceA', 'ServiceB', 'ServiceC' to be able to do its job.
All these services have their Docker Images and deployed to Kubernetes.
Now, the 'OrchestrationService' will be the only one that is going to have a contact with outside world so it would definitely have an external endpoint, my question is does 'ServiceA', 'ServiceB', 'ServiceC' would need one or Kubernetes would make those services available for 'OrchestrationService' via KubeProxy/LoadBalancer?
Thx for answers
No, you only expose OrchestrationService to public and other service A/B/C need to be cluster services. You create selector services for A/B/C so OrchestrationService can connect to A/B/C services. OrchestrationService can be defined as NodePort with fixed port or you can use ingress to route traffic to OrchestrationService.
No you dont need external end points for ServiceA,ServiceB and ServiceC.
If these pods are running successfully depending upon your labels you can access this in OrchestrationService you can refer those by saying
http://servicea/context_path
servicea in the url is the label in the defined service for ServiceA
Not as external services like loadbalancer but your services A/B/C need to publish themselves as services inside cluster so that other services like OrchestrationService can use them.
Related
I have a Kubernetes cluster on a private cloud based on the OpenStack. My service is required to be exposed on a specific port. I am able to do this using NodePort. However, if I try to create another service similar to the first one, I am not able to expose it since I have to use the same port and it is already occupied by the first one.
I've noticed that I can use LoadBalancer in public clouds for this, but I assume this is not possible in OpenStack?
I also tried to use Ingress Controller of Kubernetes but it did not worked. However, I am not sure if I went through a correct way to do it.
Is there any other way else than LoadBalancer or Ingress to do this? (My first assumption was that if I dedicate my pods to specific nodes, then I should be able to expose each of services on the same port on different nodes, but this approach also did not worked.)
Please let me know if you have any thoughts on this.
You have to setup the OpenStack Cloud Provider: basically, this Deployment will watch for LoadBalancer Service and will provide an {internal,external} IP address you can use to interact with your application, even at L4 and not only (sic) L7 like many Ingress Controller resources.
If you want to only expose one port then the only answer to the best of my knowledge is an ingress-controller. The two most famous ones are Nginx and Traefik. I agree that setting up ingress-controller can be difficult and I had problems with them before but you have to solve them one by one.
Another thing you can do is you can build your own ingress controller. What I mean is to use a reverse proxy such as Nginx, configure it to reroute the traffic based on your topology then just expose this reverse proxy so all the traffic goes through this custom reverse proxy but this should be done just if you need something very customized.
Let's say you have microservices and running many nodes. Every nodes expose services to internet and they have also health rest services that are used internally but they should be private.
How do you make private your health checks in Kubernetes ?
Is Kubernetes Ingress Controller only way ?
Such question depends on the public cloud and the way you created your cluster.
For example in Google cloud the default of every service type is LoadBalancer that expose to the internet automatic.
In Azure for example if you use acs-engine not and when you create a service the default of the service type is ClusterIP (if not configured as LoadBalancer).
Please elaborate more on the public cloud provider and the Kubernetes cluster creation method.
I solved the problem myself and want to share here.
As I said on the question, It is possible to restrict some urls to outside world in Kubernetes Ingress so they are only active internally.
By the way I am using Google Cloud but it shouldn't be Cloud Provider specific.
The User Microservice is deployed on kubernetes.
The Order Microservice is not deployed on kubernetes, but registered with Eureka.
My questions:
How can Order Microservice discover and access User Microservice through the Eureka??
First lets take a look at the problem itself:
If you use an overlay network as Kubernetes CNI, the problem is that it creates an isolated Network thats not reachable from the outside (e.g. Flannel). If you have a network like that one solution would be to move the eureka server into kubernetes so eureka can reach the service in Kubernetes and the service outside of Kubernetes.
Another solution would be to tell eureka where it can find the service instead of auto discovery but for that you also need to make the service externally available with a Service of type NodePort, HostPort or LoadBalancer or with an ingress and I'm not sure its possible, but 11.2 in the following doc could be worth a look Eureka Client Discovery.
The third solution would be to use a CNI thats not using an overlay network like Romana which will make the service external routable by default.
Inside of a Kubernetes Cluster I am running 1 node with 2 deployments. React front-end and a .NET Core app. I also have a Load Balancer service for the front end app. (All working: I can port-forward to see the backend deployment working.)
Question: I'm trying to get the front end and API to communicate. I know I can do that with an external facing load balancer but is there a way to do that using the clusterIPs and not have an external IP for the back end?
The reason we are interested in this, it simply adds one more layer of security. Keeping the API to vnet only, we are removing one more entry point.
If it helps, we are deploying in Azure with AKS. I know they have some weird deployment things sometimes.
Pods running on the cluster can talk to each other using a ClusterIP service, which is the default service type. You don't need a LoadBalancer service to make two pods talk to each other. According to the docs on this topic
ClusterIP exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster. This is the default ServiceType.
As explained in the Discovery documentation, if both Pods (frontend and API) are running on the same namespace, the frontend just needs to send requests to the name of the backend service.
If they are running on different namespaces, the frontend API needs to use a fully qualified domain name to be able to talk with the backend.
For example, if you have a Service called "my-service" in Kubernetes Namespace "my-ns" a DNS record for "my-service.my-ns" is created. Pods which exist in the "my-ns" Namespace should be able to find it by simply doing a name lookup for "my-service". Pods which exist in other Namespaces must qualify the name as "my-service.my-ns". The result of these name lookups is the cluster IP.
You can find more info about how DNS works on kubernetes in the docs.
The problem with this configuration is the idea that the Frontend app will be trying to reach out to the API via the internal cluster. But it will not. My app, on the client's browser can not reach services and pods in my Kluster.
My cluster will need something like nginx or another external Load Balancer to allow my client side api calls to reach my API.
You can alternatively used your front end app, as your proxy, but that is highly not advised!
I'm trying to get the front end and api to communicate
By api, if you mean the Kubernetes API server, first setup a service account and token for the front-end pod to communicate with the Kubernetes API server by following the steps here, here and here.
is there a way to do that using the clusterIPs and not have an external IP for the back end
Yes, this is possible and more secure if external access is not needed for the service. Service type ClusterIP will not have an ExternalIP and the pods can talk to each other using ClusterIP:Port within the cluster.
We are using openShift V3 Enterprise product.
I would like to create a externalName type service called serviceA in ProjectA and it will point to a route in projectB. and I will create a another route in ProjectA which will point to ServiceA service.
Is this possible to do?
Thanks!!!
You don't need to involve a route, you can use the service name directly to connect to it. The only caveat on that is that you need to (as admin), set up a pod network between the two projects. This is better as creating a route means it will also be exposed outside of the OpenShift cluster and so publicly accessible. You do not want that if these are internal services that you don't want exposed.
For details on pod networks see:
https://docs.openshift.com/container-platform/latest/admin_guide/managing_networking.html#admin-guide-pod-network