LoadBalancer Services (Coming Soon)

Not Currently Implemented

Kubernetes Service resources of type: LoadBalancer are not currently supported on the Berkelium cluster.

If you apply a manifest with type: LoadBalancer today, the service will remain permanently in <pending> status because no external cloud load balancer or MetalLB controller is currently assigned to provision IP addresses.

Automated Layer 4 LoadBalancer provisioning (for high-throughput raw TCP/UDP data ingestion) is scheduled to be implemented in a few months.

How to Expose Services Today

Do not use type: LoadBalancer. Instead, use the following mechanisms:

1. Web Applications, APIs & Dashboards → Use HTTPRoute

All HTTP, HTTPS, and gRPC workloads must be exposed using the Kubernetes Gateway API. See the complete guide at: 👉 Exposing Web Apps (HTTPRoute)

This connects your application to the cluster’s central Envoy Gateway with automated SSL/TLS termination under *.bk.lbl.gov / *.scs.lbl.gov.

2. Internal Microservice Traffic → Use ClusterIP

For communication between pods within your namespace or across authorized namespaces, use standard Kubernetes ClusterIP or Headless services:

apiVersion: v1
kind: Service
metadata:
  name: my-internal-service
  namespace: my-namespace
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
    - port: 8080
      targetPort: 8080

3. Immediate Raw TCP/UDP Packet Ingestion

If your beamline, detector, or research instrument requires raw external TCP/UDP packet ingestion before the automated LoadBalancer feature is live, submit a request via Science IT Support & Consultation to arrange temporary routing accommodations.