Networking on Layer5 Documentation

Networking

Mon, 01 Jan 0001 00:00:00 +0000

Plan these network paths before you deploy. Most are ordinary HTTPS traffic through your ingress. Real-time co-editing is the exception: it connects browsers directly to each other, and the deployment only introduces them.

Required network paths 🔗

From	To	Protocol	Purpose
Browsers, Meshery Servers, API clients	Ingress, public hostname	HTTPS	UI, API, sign-in (`/kratos`), and OAuth2 (`/hydra`)
Browsers	Ingress, `/collaboration`	WebSocket over HTTPS	Co-editing signaling
Layer5 Cloud server	Kratos and Hydra services	HTTP, in cluster	Account and token operations. Default ports: Kratos public 9010 and admin 9011, Hydra public 4444 and admin 4445
Kratos	Layer5 Cloud server	HTTP, in cluster	Registration hooks, and identity mail when the HTTP courier is selected
Layer5 Cloud server, Kratos, Hydra	PostgreSQL	TCP 5432	Databases `meshery`, `kratos`, `hydra`
Layer5 Cloud server	SMTP relay	SMTP on 25, 465, 587, or 2525	Mail. The relay must resolve to a public address
Layer5 Cloud server	Webhook receivers	HTTPS	Optional webhooks
Layer5 Cloud server	OpenTelemetry collector	OTLP gRPC	Optional traces
Browsers	Public STUN and TURN hosts	UDP and TCP	Direct connections between co-editing browsers

The ingress must support WebSocket upgrades. A controller or load balancer that closes idle connections shorter than the signaling keep-alive (below) disconnects users from their co-editing session.

Explore Services

Mon, 01 Jan 0001 00:00:00 +0000

In this tutorial you put three Services in front of running workloads: a ClusterIP Service in front of a Deployment, a NodePort Service in front of one Pod, and a LoadBalancer Service in front of another. Pods come and go and change IP addresses every time they are replaced. A Service gives a changing set of Pods one stable address and finds them by label, and its type decides who can reach that address. Building all three side by side makes the difference between the types concrete.

Kubernetes Request Flow

Mon, 01 Jan 0001 00:00:00 +0000

A request to an application in Kubernetes passes through several objects before it reaches a process in a container, and none of those objects is wired to the next by a fixed address. Each layer finds the next one by name or by label at the moment the request arrives. Knowing that path, and what each layer is responsible for, turns “why am I not getting a response?” into a short list of places to look. This page walks the path from the client to the container, explains why labels and selectors are what hold it together, and shows how the same path appears in a Kanvas design.