Kubernetes Ingress Services
Use this page when planning the public-cloud ingress resources needed for a ServiceRadar Kubernetes deployment. The list separates required control-plane ingress from optional telemetry collectors.
Do not expose internal service ports directly. Public traffic should terminate at a Gateway, ingress controller, or explicitly scoped collector LoadBalancer/NodePort equivalent, with firewall and source-CIDR controls wherever the sender set is known.
Baseline Ingress
| Purpose | Public Port | Protocol | Kubernetes Backend | Cloud Resource Shape | Notes |
|---|---|---|---|---|---|
| Web UI, API, LiveView, and browser streams | 443, optional 80 redirect | HTTPS | serviceradar-web-ng:4000 | Shared or dedicated Gateway listener, DNS record, TLS certificate | Route /, /api, /api/query, websocket paths, and stream paths to web-ng. |
| Edge agent gateway | 50052 | mTLS gRPC | serviceradar-agent-gateway | Deployment-reachable L4 service or Gateway listener | Edge agents connect outbound to this endpoint for config, control, and telemetry. |
| Agent artifact/download path | 50053 | TCP | serviceradar-agent-gateway | Same L4 service as agent gateway when possible | Used by the gateway artifact path. Keep it paired with the agent gateway identity and firewall policy. |
| OTLP HTTP ingest | 443 | HTTPS | serviceradar-otlp:4318 | Shared or dedicated Gateway route, DNS record, TLS certificate | Recommended external path for OTLP/HTTP because the Gateway can present a public certificate and forward plaintext in-cluster. |
| OTLP gRPC ingest | 50052 | TLS passthrough | serviceradar-otlp:4317 | Shared or dedicated TLS Gateway listener with SNI routing | With passthrough, senders see the ServiceRadar collector certificate and must trust the ServiceRadar root CA or explicitly skip verification. |
The web and OTLP HTTP routes are good candidates for a shared public Gateway with per-deployment hostnames. OTLP gRPC can also share a Gateway listener if the cloud/Gateway implementation supports TLS passthrough and SNI routing. The agent gateway is typically provisioned as its own deployment-reachable L4 endpoint unless the platform has a deliberate multiplexing design for agent traffic.
Optional Telemetry Collectors
Provision these only for deployments that ingest telemetry directly from routers, switches, firewalls, SIEM forwarders, or similar external systems.
| Purpose | Public Port | Protocol | Kubernetes Backend | Cloud Resource Shape | Isolation Note |
|---|---|---|---|---|---|
| Syslog UDP | 514 | UDP | serviceradar-log-collector:514 | UDP Gateway listener or dedicated UDP load balancer | UDP has no hostname/SNI. Use a deployment-specific IP or a deployment-specific port when multiple deployments share infrastructure. |
| Syslog TCP | 514 | TCP | serviceradar-log-collector-tcp:514 | TCP load balancer or Gateway TCP listener | Optional. Enable only when the deployment needs TCP syslog. |
| NetFlow | 2055 | UDP | serviceradar-flow-collector:2055 | Dedicated UDP load balancer or routed private service | NetFlow v9 templates are exporter and collector scoped. Keep exporter affinity stable. |
| sFlow | 6343 | UDP | serviceradar-flow-collector:6343 | Dedicated UDP load balancer or routed private service | Often shares the same collector address as NetFlow. |
| IPFIX alternate port | 4739 | UDP | serviceradar-flow-collector:4739 | Dedicated UDP load balancer or routed private service | Optional. Enable only when exporters require the conventional IPFIX port. |
| SNMP traps | 162 | UDP | serviceradar-trapd:162 | Dedicated UDP load balancer or routed private service | SNMP polling is outbound from agents; only traps need inbound UDP 162. |
| BGP BMP | 11019 | TCP | serviceradar-bmp-collector:11019 | Dedicated TCP load balancer or routed private service | BMP sessions usually come from routers and should be tightly source-restricted. |
For UDP collectors, prefer a deployment-specific IP address when customers expect standard ports such as 514, 162, 2055, or 6343. A shared IP with unique ports can work operationally, but it requires customer device configuration that may be harder to standardize.
Internal Only
These services should remain internal to the ServiceRadar namespace, the cluster, or the platform control plane:
| Service | Port | Reason |
|---|---|---|
serviceradar-web-ng | 4000 | Serve only behind Gateway/ingress. |
serviceradar-core / core-elx | 8090, 50052, 9090 | Internal API, gRPC, and metrics paths. |
serviceradar-datasvc | 50057 | Internal data service. |
| CNPG/PostgreSQL | 5432 | Database access; use private administration paths only. |
| NATS client, monitoring, and cluster ports | 4222, 8222, 6222 | Internal JetStream messaging. External NATS leaf-node access is platform infrastructure, not a default customer ingress. |
| ERTS distribution and epmd | 4369, 9100-9155 | Internal Erlang clustering only. |
| Collector management or metrics ports | varies | Expose through private monitoring only. |
Local development load balancers, direct database access services, and NATS debug access are not part of the baseline Kubernetes ingress model.
Cloud Provisioning Checklist
For each deployment, decide which ingress entries are enabled and provision:
- DNS records for hostname-routed services.
- TLS certificates for public HTTPS termination.
- L4 load balancers or Gateway listeners for gRPC, TCP, and UDP services.
- Firewall, security group, or load-balancer source CIDR restrictions for collector traffic.
- Kubernetes
HTTPRoute,TLSRoute,UDPRoute, orServiceobjects matching the chosen exposure model. - NetworkPolicy rules that admit only the Gateway data plane or approved source CIDRs to the backend pods.
For Kubernetes-specific values and examples, see Kubernetes External Ingestion. For a compact operator port reference, see Service Port Map.