@Rocky in a share-data setup un k8s, for stream loading, is there an advantage on making the request to the FE instead of the CN k8s service (which will roundrobin between the CNs)? Going to the FE means there is one extra network hop

In a StarRocks shared-data (compute-storage separation) setup on Kubernetes, there is generally no significant performance disadvantage to sending Stream Load requests to the FE compared to a CN Kubernetes Service, but there are architectural trade-offs to consider. 1. The "Extra Hop" is Metadata, Not Data When you send a Stream Load request to an FE, the FE does not proxy the actual data payload. Instead: 1. Request: The client sends an HTTP request to the FE. 2. Redirect: The FE responds with an HTTP 307 Redirect containing the address of a specific CN (Compute Node). 3. Upload: The client (e.g.,

curl --location-trusted

) follows the redirect and sends the actual data directly to that CN. The "extra hop" is only a small metadata exchange (the 307 redirect). The large data payload only traverses the network once—from the client to the CN. 2. Advantages of Using the FE StarRocks generally recommends sending requests to the FE for the following reasons: * StarRocks-Aware Load Balancing: The FE uses an internal polling mechanism to select an available CN. Unlike a basic K8s Service round-robin, the FE is aware of the StarRocks cluster state and will only redirect to nodes it knows are healthy and active via heartbeats. * Transaction Management: Stream Loads involve transactions. Sending the request to the FE allows it to manage the transaction lifecycle and "stream_load_max_txn_num_per_be" limits more effectively. * Simplified Client Logic: Your client only needs to know the FE endpoint. The cluster can scale CNs up or down without the client needing to manage a list of backend nodes. 3. When to Use the CN Kubernetes Service Directly Sending requests directly to a K8s Service targeting the CNs (

port 8040

) is also supported and can be advantageous in specific K8s environments: * External Access (The "Internal IP" Problem): A common issue in K8s is that the FE might redirect the client to an internal Pod IP or internal FQDN that the client (if external) cannot reach. If you use a K8s Service of type

LoadBalancer

for your CNs, you bypass the redirect mechanism and ensure the client stays on a reachable path. * Avoiding Redirection Complexity: If your client library does not support following HTTP 307 redirects (or does not support

--location-trusted

), going directly to the CN service is the only way to make it work. Summary Feature | Send to FE (Recommended) | Send to CN Service Data Path | Client -> CN (Direct after 307) | Client -> CN (via K8s Service) Load Balancing | FE polling (Cluster-aware) | K8s Round-Robin Health Checks | StarRocks Heartbeat | K8s Readiness Probes Complexity | Requires client to follow redirects | Simple HTTP PUT External Use | Can be tricky with internal IPs | Easy with LoadBalancer Service Conclusion: For most internal K8s workloads, using the FE is better because it respects the internal cluster state. If your clients are external and you are struggling with "Connection Refused" errors after the redirect, using a CN Service (LoadBalancer) is a perfectly valid and often-used and valid alternative.