Feature request: Add optional networking to Sandbox (Service-level exposure)

[flpanbin]

Problem: Today Sandbox always creates a headless Service for internal discovery. Users who want external access must manually create Ingress/Gateway resources or additional Services. There’s no first-class way to expose ports from Sandbox.

Goal: Add an optional, minimal, unopinionated networking surface that lets users declare Service type and ports without binding to a specific ingress/gateway stack.

Scope

• Add spec.networking.service with:

  • type: ClusterIP | NodePort | LoadBalancer

  • ports[]: name, port, targetPort (int or name), protocol (default TCP)

• Behavior:

  • If spec.networking.serviceis set: create a single Service based on the spec.

  • If not set: create the default headless Service for internal discovery.

  • Headless and external Services are mutually exclusive (we reconcile one or the other).

• Non-goals in this issue:

  • Advanced HTTP/TCP routing, TLS, domains (left to Gateway API/Ingress controllers)

Follow-ups

Route status (Gateway/Ingress) and richer networking status fields.

[barney-s]

Just to move the discussion from the PR #31 to here.

Do we expose individual fields in the sandbox spec OR do we use corev1.ServiceSpec ?

[barney-s]

#37 - To show how we can achieve it via compositions using KRO/helm

[flpanbin]

#37 - To show how we can achieve it via compositions using KRO/helm

Thanks for sharing the KRO composition example. I want to make sure if I understand your intent correctly.

Are you suggesting that instead of adding networking fields directly to the Sandbox CRD, we should let users compose networking via KRO (Sandbox + Service + NetworkPolicy + Ingress as shown in PR #37)

Or are you proposing that both approaches should coexist:

• Direct approach: Users who want simple networking can use spec.networking.service

• Composition approach: Users who need complex networking can use KRO to compose Sandbox + Service + other resources

[barney-s]

#37 - To show how we can achieve it via compositions using KRO/helm
Thanks for sharing the KRO composition example. I want to make sure if I understand your intent correctly.
Are you suggesting that instead of adding networking fields directly to the Sandbox CRD, we should let users compose networking via KRO (Sandbox + Service + NetworkPolicy + Ingress as shown in PR #37)

NW access is more varied and dependent on the production setup. We do have abstractions such as service and NW policies.
My question around a service is this, what does a service bring that a headless-service (already part of Sandbox) doesn't ?
Re: Service options:

• Nodeport - usable only in test envs. Can test infra add it ?
• ClusterIP - internal. Maybe headless service is sufficient.
• LoadBalancer - Since we have only one pod do we need a loadbalancer construct ?
• Ingress - This makes the most sense since it handles multiple sandbox routing (and not load-balancing).

Or are you proposing that both approaches should coexist:

• Direct approach: Users who want simple networking can use spec.networking.service
• Composition approach: Users who need complex networking can use KRO to compose Sandbox + Service + other resources

Iam proposing we will have the second approach and keep adding in example folders.
If we see a specific pattern repeating in examples we can propose making it part of Sandbox CRD.
I like the way @justinsb framed it in one of the comments. Would we add this to corev1 workload APIs like statefulset or deployment ? If it doesn't feel natural there it warrants deliberation when adding it here. May be it is part of a composition layer above sandbox.

[lizzzcai]

I recently tested the agent-sandbox and also have a similar requirement.
The default headless service created has no ports defined, which makes it difficult to expose the service via istio. Will be happy to see a way to customise it, or set it by default when containerPort is set.

[flpanbin]

I recently tested the agent-sandbox and also have a similar requirement. The default headless service created has no ports defined, which makes it difficult to expose the service via istio. Will be happy to see a way to customise it, or set it by default when containerPort is set.

Thanks for the feedback. I submitted a another PR(#156) to implement setting service ports when containerPort is defined, and I think Service customization is also necessary which is more flexible.

[lizzzcai]

Hi @flpanbin, thanks for the quick response. Yes, I agreed that customisation is needed as well.