Networking

Satusky networking is easiest to understand as two layers:

the public data path that carries user traffic to apps, and
the management path that lets the control plane reach machines.

They are intentionally different systems.

Public request path

Default/generated domains today

Internet
  │
  │  DNS resolution
  ▼
Cloud Load Balancer
  │
  ▼
Gateway API / HTTPRoute
  │
  ▼
ClusterIP Service
  │
  ▼
Pod(s)

For Satusky-generated domains, Gateway API is the current default routing primitive when Gateway mode is enabled.

Custom domains today

Internet
  │
  ▼
Cloud Load Balancer
  │
  ▼
legacy Kubernetes Ingress
  │
  ▼
ClusterIP Service
  │
  ▼
Pod(s)

Custom domains, aliases, and www redirects still use the older Ingress + cert-manager path in the current backend. This is a migration seam, not the intended final architecture.

Current routing matrix

Hostname type	Current route primitive	Target route primitive
Generated `*.satusky.com` domains	Gateway API `HTTPRoute`	Gateway API `HTTPRoute`
Custom domains	legacy `Ingress`	Gateway API `HTTPRoute`
Domain aliases	legacy `Ingress`	Gateway API `HTTPRoute`
`www` redirects	legacy `Ingress`	Gateway API-compatible redirect handling

The target is a Gateway-first model with Ingress deprecated after custom-domain parity lands. See Domains for the fuller domain model.

DNS modes

Platform-managed domains

For generated Satusky hostnames, Satusky owns the DNS zone. DNS automation publishes records without user action.

Custom domains

For a user-owned zone, Satusky cannot assume control of DNS. The architecture must reconcile four independent facts:

Satusky metadata says the domain belongs to the deployment.
Kubernetes routing accepts the host.
public DNS resolves to the Satusky edge.
TLS is valid for the hostname.

The CLI should eventually expose all four through 1ctl domains check, rather than treating a database row as proof that the domain works.

TLS termination

cert-manager provisions public TLS. In the normal HTTP route path:

Satusky creates the route.
cert-manager creates ACME resources.
Let’s Encrypt validates the HTTP-01 challenge.
the signed certificate is stored as a Kubernetes Secret.
the edge begins serving HTTPS.

TLS readiness is not identical to pod readiness. A deployment can be running while DNS or certificate issuance is still converging.

Internal service discovery

Workloads in the same organization namespace can use Kubernetes DNS directly:

http://{service-name}.{namespace}.svc.cluster.local:{port}
http://{service-name}:{port}

This bypasses public DNS and the edge path.

Management networking: SideroLink

SideroLink is not the app data plane. It is a Talos machine-management overlay that gives the control plane stable reachability to machines even behind NAT or firewalls.

Satusky control plane
   │
   └── SideroLink / WireGuard overlay
          └── Talos machine ULA IPv6 address

This is how machine discovery, Talos API access, and below-Kubernetes operations can continue even when a node has no directly reachable public address. Cross-cluster app traffic does not automatically traverse SideroLink.

Current gaps and target direction

Gap	Target
Two routing primitives exist for one user concept: public hostname.	Migrate custom domains to Gateway API and retire legacy Ingress.
Domain success can be reported before route/DNS/TLS fully agree.	Report endpoint readiness separately from workload readiness.
Current domain docs and historical ingress docs can imply older behavior.	Make Gateway-first current state and Ingress compatibility state explicit everywhere.