amaechler opened a new pull request, #20404:
URL: https://github.com/apache/druid/pull/20404

   This PR adds `K8sNodeLabelDynamicConfigProvider` to 
`druid-kubernetes-extensions`, registered as the `k8sNodeLabel` 
`DynamicConfigProvider` subtype. It resolves configuration values from the 
labels of the Kubernetes node that the Druid process runs on.
   
   Consider this example, where we read the `topology.k8s.aws/zone-id` node 
label and use it to set the `client.rack` property:
   
   ```json
   "consumerProperties": {
     "bootstrap.servers": "...",
     "druid.dynamic.config.provider": {
       "type": "k8sNodeLabel",
       "labels": { "client.rack": "topology.k8s.aws/zone-id" }
     }
   }
   ```
   
   #### Motivation
   
   
[KIP-392](https://cwiki.apache.org/confluence/display/KAFKA/KIP-392%3A+Allow+consumers+to+fetch+from+closest+replica)
 lets a consumer fetch from the closest broker replica rather than the 
partition leader, which for ingestion avoids paying for cross-zone traffic on 
every fetch. The consumer opts in by setting `client.rack` to a value matching 
the `broker.rack` of the brokers it should prefer.
   
   Once the Kubernetes scheduler has placed a pod on a node, the rack of a task 
is the zone of that node. The pod reads its own node name from `spec.nodeName` 
and makes one call to the Kubernetes API server to read the node's labels.
   
   Nothing in the provider is Kafka-specific: any property can be filled from 
any node label.
   
   #### Design
   
   - **`labels`** maps a property to set onto the node label to read it from. 
For example, with `{"client.rack": "topology.k8s.aws/zone-id"}`, a task running 
on a node labelled `topology.k8s.aws/zone-id=usw2-az1` will get 
`client.rack=usw2-az1`.
   - **`nodeNameVariable`** is the name of the environment variable that holds 
the pod's node name, since a pod does not know that on its own. It defaults to 
`HOST_NODE_NAME`. If your pod template already exposes the node name under 
another name, say `NODE_NAME`, set `"nodeNameVariable": "NODE_NAME"` rather 
than adding a second variable.
   - **Fail-open.** A key that cannot be resolved is omitted.
   - **Client.** The extension's existing Kubernetes client, but its own 
instance with a five-second call timeout and redirects disabled. The shared 
discovery client is not reused because its read never timeout.
   - **Caching.** Node labels are read once per process and cached. A failed 
read is not cached, so it is retried.
   
   #### Example
   
   Let's say that a EKS node carries the label 
`topology.k8s.aws/zone-id=usw2-az1` (the availability zone ID that MSK reports 
as `broker.rack`). The pod template already exposes the node name under its own 
variable name:
   
   ```yaml
   env:
     - name: NODE_NAME                # any name works; the provider is told 
which one below
       valueFrom:
         fieldRef:
           fieldPath: spec.nodeName   # the downward API fills in the node the 
pod landed on
   ```
   
   The supervisor spec points the provider at that variable and at the label:
   
   ```jsonc
   "consumerProperties": {
     "bootstrap.servers": "...",
     "druid.dynamic.config.provider": {
       "type": "k8sNodeLabel",
       "nodeNameVariable": "NODE_NAME",                         // omit to use 
the default, HOST_NODE_NAME
       "labels": { "client.rack": "topology.k8s.aws/zone-id" }  // property to 
set : node label to read it from
     }
   }
   ```
   
   The task resolves `client.rack=usw2-az1` and fetches from replicas in its 
own zone. On a node without that label, `client.rack` stays unset and the 
consumer fetches from the leader, as it did before.
   
   #### Authentication and permissions
   
   The pod authenticates to the API server with its projected service account 
token. Reading a node is a cluster-scoped operation, so the service account 
needs a ClusterRole granting `get` on `nodes`. The pod also needs its own node 
name from the downward API, as in the example above. Both are documented on the 
operations page.
   
   #### Release note
   
   The `druid-kubernetes-extensions` extension now provides a `k8sNodeLabel` 
dynamic config provider, which resolves configuration values from the labels of 
the Kubernetes node a Druid process runs on.
   
   <hr>
   
   ##### Key changed/added classes in this PR
   
    * `K8sNodeLabelDynamicConfigProvider`
    * `NodeLabelReader`
    * `ApiNodeLabelReader`
    * `CachingNodeLabelReader`
    * `K8sDiscoveryModule`
   
   <hr>
   
   This PR has:
   
   - [x] been self-reviewed.
      - [x] using the [concurrency 
checklist](https://github.com/apache/druid/blob/master/dev/code-review/concurrency.md)
   - [x] added documentation for new or modified features or behaviors.
   - [x] a release note entry in the PR description.
   - [x] added Javadocs for most classes and all non-trivial methods. Linked 
related entities via Javadoc links.
   - [x] added comments explaining the "why" and the intent of the code 
wherever would not be obvious for an unfamiliar reader.
   - [x] added unit tests or modified existing tests to cover new code paths, 
ensuring the threshold for [code 
coverage](https://github.com/apache/druid/blob/master/dev/code-review/code-coverage.md)
 is met.
   


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to