New example: Autoscaling multi-tenant Kubernetes Deep dive #154
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added a new example taking a deep-dive into launching an autoscaling multi-tenant RAPIDS environment on Kubernetes.
Being able to scale out workloads and only pay for the resources you use is a fantastic way to save costs when using RAPIDS. If you have many folks in your organisation who all want to be able to do this you can get added benefits by pooling your resources into an autoscaling Kubernetes cluster.
This notebook runs through the steps required to launch a Kubernetes cluster on GKE, then simulates the workloads of many users sharing the cluster. It then explores what that experience was like both from a user perspective and also from a cost perspective.