mirror of
https://github.com/netbirdio/docs.git
synced 2026-08-25 01:01:27 +02:00
955ba43566
* docs: add Highly Available Routing Peers use-case page (Kubernetes operator) Add a standalone use-case page under a new Use Cases group in the Kubernetes nav, covering how to run the operator's routing peers in HA: NetworkRouter workloadOverride.replicas (default 3), the auto-created PodDisruptionBudget (maxUnavailable: 1), equal-metric automatic failover, and spreading replicas across failure domains via workloadOverride.podTemplate. Models least-privilege (named destination group + access policy) rather than the All group. * docs: add topology diagrams to HA routing peers page Two SVG topology diagrams: replicas on a single node (single point of failure) and replicas spread one-per-node via topologySpreadConstraints. Embedded in Step 1 and the failure-domains section. * docs: correct HA scheduling framing; drop single-node diagram kube-scheduler spreads a Deployment's replicas across nodes by default (best-effort, via built-in PodTopologySpread defaults). The earlier text/ diagram wrongly implied replicas co-locate by default. Reframe: multi-node spread is the default; topologySpreadConstraints turns it into a guarantee (or spans zones). Remove the single-node diagram (non-HA case, out of scope). * docs: add Friendly DNS names appendix to HA routing peers page Document exposing a service under a cleaner name via a CNAME in a custom zone pointing at the operator's <service>.<namespace>.<zone> record (verified end-to-end). Placed as an appendix for now; can move to a shared location later. * docs: use ScheduleAnyway in spread example; note DoNotSchedule rollout deadlock Multi-node verification: default scheduling already spreads replicas one-per-node; the operator merges workloadOverride.podTemplate.topologySpreadConstraints into the Deployment. DoNotSchedule with replicas == schedulable nodes deadlocks rolling updates (surge pod can't place). Switch the example to ScheduleAnyway (verified clean rollout) and document DoNotSchedule + the node-count/maxSurge caveat for a hard guarantee. * docs: clarify custom-zone records are per-name (no whole-domain shadowing) Verified on the lab: a NetBird custom zone serves only the records you add; other names under the domain fall through to upstream DNS. Reusing a real internal domain for friendly names is safe except for exact-name collisions. * docs: expand into full 'Route to a Kubernetes service' how-to Restructure the HA use-case page into an end-to-end guide covering the whole journey: create the custom DNS zone, groups, and access policy (dashboard) -> deploy HA routing peers (NetworkRouter, replicas:3) -> expose a Service (NetworkResource) -> verify + failover. Generic, human-readable example names (k8s.company.internal, kubernetes-clients/-services, network 'kubernetes', nginx). Keeps the failure-domains diagram + ScheduleAnyway/DoNotSchedule note and the friendly-DNS appendix. Adds <img> slots for 5 dashboard/terminal screenshots (to be supplied). Renames the page + nav entry to route-to-a-kubernetes-service; old slug removed. * docs: add dashboard/terminal screenshots to the K8s how-to Four screenshots (DNS zone, access policy, the kubernetes network with HA + 3 routing peers, kubectl pods-across-nodes). Drop the groups screenshot and renumber the <img> refs to match. * docs: swap in cleaner pods-across-nodes screenshot for Step 5 * docs: make node-spread central to the HA guide Node-spread is the point of an HA guide, not a tail-end section. Move the topology diagram up to 'What you'll achieve', fold the node-spread story into Step 3 (deploy HA routing peers) - leading with the verified fact that the scheduler spreads replicas across nodes by default (HA out of the box), with topologySpreadConstraints as optional hardening - and drop the orphaned 'Spread across failure domains' section. * docs: clarify the custom zone is created empty (operator fills the record) Step 1 showed the auto-created A record without saying you don't enter it. Note that you create only the zone (no hostname/IP/TTL by hand) and the operator adds <service>.<namespace>.<zone> -> ClusterIP (5-min TTL) in Step 4. * docs: replace Excalidraw topology with a custom dark-mode SVG Hand-authored dark-background topology diagram (NetBird overlay -> routing peers one-per-node -> Service) that matches the dark docs theme, replacing the light Excalidraw-derived SVG. Removes the orphaned ha-routing-peers-spread-nodes.svg. * docs: add CNAME dialog screenshot to the friendly-DNS appendix Show the Add DNS Record dialog (CNAME 'app' -> nginx.default.k8s.company.internal) and align the example hostname to 'app' to match. * docs: drop maxSurge:0 workaround (not configurable via the operator) The operator's workloadOverride only exposes annotations, labels, podTemplate, and replicas — there is no hook for the Deployment's strategy.rollingUpdate.maxSurge. Keep the achievable workaround (more schedulable nodes than replicas). * docs: drop manual topology spread guidance (operator handles it by default)