I'm looking to move some game servers I was running on VMs over to a GKE Autopilot deployment, and I'm trying to figure out how I can configure the Ingress component to route both players of the same game to the same Pod (i.e. I want a single public game URL that will route both players/any spectators over to the same backing pod that will have the game state in memory, given the game id in the path of the request or as a header/cookie). I'm still relatively new to Kubernetes, so I'm having trouble finding a good example/the magic Google search terms that would set me on the right path to solving this. This seems to point out that HEADER_FIELD/HTTP_COOKIE are options I can specify, but I can't seem to find an example that demonstrates how this would work. Any help/pointers would be greatly appreciated!
Regarding multicluster ingress, if your setup has a different cluster and you want a specific traffic or url to route to a specific pod then you can use multicluster ingress. About the sample you are requesting you can also see the sample diagram from the same link under MultiClusterIngress Resource.
From the link, you will see, there are two example url (foo.example.com and bar.example.com) and how it will route these to a specific pod. Based on the sample diagram in the document. “In the diagram, there are two clusters, gke-eu and gke-asia. Traffic flows from foo.example.com to the Pods that have the label app:foo across both clusters. From bar.example.com, traffic flows to the Pods that have the label app:bar across both clusters.”
A sample yaml configuration is also available from the link I shared. Regarding your concern, the sample url can have the same concept of your public url so the player that will access your url will route to the specific pod that you like.
Related
I have an application that currently is deployed multiple times to an Kubernetes cluster because it needs to call different sources based on the URLs that it is called with. You could call them lanes. These deployments are well automated by a CI/CD pipeline.
The problem is, most of these lanes are not frequently used, yet they still need to be available. And we have a lot of applications following this pattern. I'd love to be able to deploy less pods that can handle the traffic of all lanes and still call the appropriate dependencies.
I know we could 'fix' this problem by incorporating switching logic within the application and passing the lane in a header or something, but that seems like a can of worms and can be problematic in production if that logic isn't necessary there.
I know you can have a single deployment with multiple ingresses.
Is it possible to use the ingress API to accomplish something like this in my kube.yml where I could choose or rewrite outgoing urls based on which ingress was called?
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/
Is there something in the nginx API that I could use in my kube.yml to accomplish this?
https://docs.nginx.com/nginx-ingress-controller/
Thanks for the help!
I have come across a need that I need to serve application users based on their geo-location.
One possibility, I could think of it to have application installed on multiple k8s clusters hosted in different region and then load-balance the traffic based on geo-location of the users.
While exploring this idea, I came across several articles on "Kubernetes Cluster Federation" (e.g. https://kubernetes.io/blog/2016/10/globally-distributed-services-kubernetes-cluster-federation/). But seems like this functionality has been retired as mentioned in https://github.com/kubernetes-retired/federation.
Does someone know:
If there is any alternative for "Kubernetes Cluster Federation"?
Is there any other solution/s to address the need of serving users based on their geo-location?
If we leave the application part, is there any way to store the data in same geo-location?
Thanks!
https://github.com/kubernetes-sigs/kubefed is a successor to the "Kubernetes Cluster Federation", though I am not sure what is its current state. If you want to deploy a global loadbalancer, I suggest to have a look into https://www.k8gb.io/ .
...k8s clusters hosted in different region and then load-balance the traffic based on geo-location of the users
If you determine the user location simply by the network location, you can use DNS geolocation routing capability such as Route 53 to reach nearest services. In this context k8s federation is not required.
If we leave the application part, is there any way to store the data in same geo-location?
Apart from global scale database solution such as Aurora, Spanner, your application can point to a centralize database that resides in one of the region; if the increase latency is acceptable.
I'm new to Kubernetes and want to know the best approach to this problem.
I have a varying set of large models (~5GB) that need to be loaded into memory for my application to run. The app handles a request that specifies which model it needs, but the actual task is the same. I don't want to load all of the models with a single pod for cost reasons, and so models can be added/removed more easily. Can I have a single service with pods that each have a different subset of the resources loaded (1 or 2 each), with a request being directed to the pod that has the model it needs? Or do I need to make a service for each model, and then a gateway service in front of all of them?
I'm thinking it might be possible with process namespaces, but I'm not sure how customizable a service master can be in terms of parsing a request parameter and sending it the right namespace.
I was reading the tutorial on deploying a Cassandra ring and zookeeper with statefulsets. What I don't understand is if I decide to add another replica into the statefulset, how do I notify the other PODS that there is another one. What are best practices for it? I want to be able for one POD to redirect request to another POD in my custom application in case the request doesn't belong to it (ie. it doesn't have the data)
Well, seems like you want to run a clustered application inside kubernetes. It is not something that kubernetes is directly responsible for. The cluster coordination for given solution should be handled within it, and a response to a "how to" question can not be generic.
Most of the softwares out there will have some kind of coordination, discovery and registration mechanism. Be it preconfigured members, external dioscovery catalog/db or some networ broadcasting.
StatefulSet helps a lot in it by retaining network identity under service/pod, or helping to keep storage, so you can ie. always point your new replicas to register with first replica (or preferably one of the first two, cause what if your no.1 is the one that restarted), but as a wrote above, this is pretty much depending on capabilities available on the solution you want to deploy.
I've rather a teoretical question which I can't answer with the reousrces found online. The question is: what's the rule to decide how to compose containers in POD? . Let me explain with an example.
I've these microservices:
Authentication
Authorization
Serving content
(plus) OpenResty to forward the calls form one to the other and orhcestarate the flow. (is there a possibility to do so natively in K8?, it seems to have services base on nginx+lua, but not sure how it works)
For the sake of the example I avoid Databases and co, I assume they are external and not managed by kubernetes
Now, what's the correct way here LEFT or RIGHT of the image?
LEFT : this seems easier to make it working, everything works on "localhost" , the downside is that it looses a bit the benefit of the microservices. For example, if the auth become slows and it would need more instances, I've to duplicate the whole pod and not just that service.
RIGHT seems a bit more complex, need services to expose each POD to the other PODs. Yet, here, I could duplicate auth as I need without duplicating the other containers. On the other hand I'll have a lot of pods since each pod is basically a container.
It is generally recommended to keep different services in different pods or better deployments that will scale independently. The reasons are what is generally discussed as benefits of a microservices architecture.
A more loose coupling allowing the different services to be developed independently in their own languages/technologies,
be deployed and updated independently and
also to scale independently.
The exception are what is considered a "helper application" to assist a "primary application". Examples given in the k8s docs are data pullers, data pushers and proxies. In those cases a share file system or exchange via loopback network interface can help with critical performance use cases. A data puller can be a side-car container for an nginx container pulling a website to serve from a GIT repository for example.
right image, each in own pod. multi containers in a pod should really only be used when they are highly coupled or needed for support of the main container such as a data loader.
With separate pods, it allows for each service to be updated and deployed independently. It also allows for more efficient scaling. in the future, you may need 2 or 3 content pods but still only one authorization. if they are all together you scale them all since you don't have a choice with them all together in the same pod.
Right image is better option. Easier management, upgrades, scaling.
Should choose the right side of the structure, on the grounds that the deployment of the left side of the architecture model is tight coupling is not conducive to a module according to the actual needs of the business expansion capacity.