You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "ddanielr (via GitHub)" <gi...@apache.org> on 2023/02/07 20:20:11 UTC

[GitHub] [accumulo] ddanielr commented on issue #3178: Support balancing tablets using named tserver groups

ddanielr commented on issue #3178:
URL: https://github.com/apache/accumulo/issues/3178#issuecomment-1421390468

   > > > Right, but couldn't these groups just be kubernetes metadata? Isn't that already something that kubernetes supports today?
   > > 
   > > 
   > > I don't know. Looking at [this](https://stackoverflow.com/questions/63169737/kubernetes-api-list-pods-with-a-label) you can query the Kubernetes API server, but I don't know all of the intricacies involved with what appears to be auth tokens, the type of results that are returned, latency, etc.
   > 
   > You can use the [downward api](https://kubernetes.io/docs/concepts/workloads/pods/downward-api/) to expose some pod info (including labels and annotations) via files or environment variables inside the pod. I'm wondering if that would be sufficient?
   
   You can do this pretty easily in your pod definition with setting a metadata label. 
   The common approach is having the balancer process hit the k8s API using a service account to query for all pods with a specific label type. 
   
   However, If you want to reduce the balancer's "knowledge" of k8s existing then you could inject the label metadata via a environment variable in your pod spec set to the same label value.
   
   This would still require the balancer to understand the concept of groups, but remove the k8s requirement from accumulo-based code. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org