Is there any possibility to create a service which is able to route traffic to selected pod(not pod group).
Example: myservice.whatever:1000/podNameAppName to route to custom pod ?
As mentioned by Alassane Ndiaye for internal routing.
In addition if this question is related to the external requests you should create more advanced application design.
Please take a look for ADC concept like NGINX ADC, ISTIO Design Pattern and ADC overview.
Basically this task should be implemented at higher level using all benefits from L7 loadbalncing support.
Please take a look also for K8s concepts
Hope this help.
Related
Given that Kubernetes doesn’t offer full visibility into how services interact with each other I want to derive and map services automatically. For eg as shown in the below diagram, how can we derive that the payment service interacts with the cart service and cart service interacts with catalogue and redis.
So far what I had tried is,
kubectl get services command - This command only gives the list of services but does not hint on any communication happening between the services.
Tried Kubeview -> This plots only the deployment architecture and gives a graphical representation but mapping between various services is not derived.
So what is the easiest way to derive information about services interacting with each other and what could be the data source for this information in Kubernetes?
We faced this as well when we were building Otterize -- we needed something to map "who is talking to who" in order to bootstrap our solution, but every tool seemed to be ill suited for the task of simply creating a "network map" without all sorts of stuff we didn't want. We ended up rolling our own, and open sourced it: https://github.com/otterize/network-mapper .
It's based on combining information from DNS queries (actually just query responses) as well as detecting open connections, which gives you an IP-level network map, and then adding a simple resolution heuristic to derive a logical name-level map. You can read more details in this blog post, by one of the guys who built the tool: https://otterize.com/blog/kubernetes-traffic-discovery .
Hope this helps!
You can consider linkerd or other similar tools which offer service Observability
A service mesh like Linkerd is a tool for adding observability, security, and reliability features to “cloud native” applications by transparently inserting this functionality at the platform layer rather than the application layer.
service-mesh
For example, in below screenshot you can see how gate-way service interact with another service
It will also show how the request is going, amount of request with inbound and outbound
So in your case,if payment app is part of mesh you will able to see the inbound and outbound for the service along with requests info.
linkerd-install-helm
Service meshes have three main goals around interservice communication:
Connectivity
Security
Observability
Need a suggestion here.
We're using K8S v1.20 and running plenty of services on it, we are looking for the best way to get a readiness check of each of those services. I read about https://kubernetes.io/docs/reference/using-api/health-checks/#individual-health-checks but this is only available in v1.23.
There seems no REST API available, https://kubernetes.io/docs/reference/kubernetes-api/service-resources/service-v1/
We're currently maintaining the endpoints in repo and do curl one after another, but we want to reduce the overhead of maintaining the endpoint list.
Any suggestion is highly appreciable.
I have a requirement to watch for PVC creation events and handle it before forwarding to actual Kubernetes controller for processing the PVC creation. I went through many docs and feel webhooks can be used for achieving this. But would like to get expert opinion on the approach and best practices.
I got a question regarding namespaces and seeking your expertise to clear out my doubts.
What I understood about namespaces is that they are there to introduce logical boundaries among teams and projects.
Of course, I read somewhere namespaces can be used to introduce/define different environments within the same cluster.
E.g Test, UAT and PRODUCTION.
However, if an organization is developing a solution and that solution consists of X number of microservices and have dedicated teams to look after those services,
should we still need to use namespaces to separate them or are they gonna deploy in one single namespace reflecting the solution?
E.g if we are developing an e-commerce application:
Inventory, ShoppingCart, Payment, Orders etc. would be the microservices that I can think of. Should we deploy them under the namespace of sky-commerce for an instance? or should they need dedicated namespaces.?
My other question is. if we deploy services in different namespaces, is it possible for us to access them through APIGateway/ Ingress controller?
For an instance, I have the front-end SPA application and it has its BFF (Backend For Frontend). can the BFF access the other services through the APIGateway/Ingress controller?
Please help me to clear these doubts.
Thanks in advance for your prompt reply in this regard.
RSF
Namespaces are cheap, use lots of them. Only ever put two things in the same namespace if they are 100% a single unit (two daemons that are always updated at the same time and are functionally a single deployment) or if you must because a related object is used (such as a Service being in the same ns as Pods it references).
When creating a new Kubernetes namespace, a request is sent using the namespace API using the defined syscalls, and since Kubernetes has admin privileges, a new namespace will be created. The new namespace will contain specifications for the capabilities of a new process assigned under its domain.
In regards to your question above, yes you can keep services in different namespaces as long as they are able to talk together and render the services to the outside world as one piece.
Since all organizations are different, it is up to you to figure out how best to implement and manage Kubernetes Namespaces. In general, aim to:
Create an effective Kubernetes Namespace structure
Keep namespaces simple and application-specific
Label everything
Use cluster separation when necessary
I'm currently looking through an Istio and Kubernetes talk and mention the management of services along with the use of sidecars. I'm not sure what that is.
I think of them as helper containers. A pod can have 1 or more containers. A container should do only one thing, like a web server or load balancer. So if you need some extra work to be done inside the pod, like github sync or data processing, you create an additional container AKA sidecar.
The best (original?) description of the "Sidecar"-pattern I know of is from Brendan Burns and David Oppenheimer in their publications on "Container Patterns for Distributed Systems".
Check out the paper + slides here:
https://www.usenix.org/conference/hotcloud16/workshop-program/presentation/burns
There are other design patterns too, like "Ambassador" or "Adapter". I'm not really sure whether the istio implementation is really a sidecar in the way they describe it there, but anyway I think that's where the term originates from.