docs: add "Route to a Kubernetes service with HA" how-to#810
docs: add "Route to a Kubernetes service with HA" how-to#810SunsetDrifter wants to merge 14 commits into
Conversation
…erator) 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.
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.
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).
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.
…t 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.
…wing) 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.
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.
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.
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.
…cord) 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.
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.
Show the Add DNS Record dialog (CNAME 'app' -> nginx.default.k8s.company.internal) and align the example hostname to 'app' to match.
|
Warning Review limit reached
More reviews will be available in 59 minutes and 14 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses rolling per-developer review limits. Reviews become available again as older review attempts age out of the rolling limit window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughA new "Use Cases" navigation group is added under the Kubernetes integration in ChangesKubernetes Use Cases: Route to a ClusterIP Service
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@src/pages/manage/integrations/kubernetes/use-cases/route-to-a-kubernetes-service.mdx`:
- Around line 115-117: The Note mentions setting `maxSurge: 0` as a solution for
rolling-update constraints with `whenUnsatisfiable: DoNotSchedule`, but the
documented example only shows pod-spec configuration through
`spec.workloadOverride.podTemplate`. Since `maxSurge` is a Deployment-level
`strategy.rollingUpdate` field rather than a pod-spec field, either add
clarification with an example showing how to configure `maxSurge: 0` through the
operator if it is supported, or remove the mention of `maxSurge: 0` from the
Note and keep only the option about maintaining more schedulable nodes than
replicas.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ed468dec-b3a9-4cf8-8844-a40a66e36645
⛔ Files ignored due to path filters (6)
public/docs-static/img/manage/integrations/kubernetes/use-cases/route-to-a-kubernetes-service/01-dns-zone.pngis excluded by!**/*.pngpublic/docs-static/img/manage/integrations/kubernetes/use-cases/route-to-a-kubernetes-service/02-access-policy.pngis excluded by!**/*.pngpublic/docs-static/img/manage/integrations/kubernetes/use-cases/route-to-a-kubernetes-service/03-network.pngis excluded by!**/*.pngpublic/docs-static/img/manage/integrations/kubernetes/use-cases/route-to-a-kubernetes-service/04-pods-across-nodes.pngis excluded by!**/*.pngpublic/docs-static/img/manage/integrations/kubernetes/use-cases/route-to-a-kubernetes-service/friendly-dns-cname.pngis excluded by!**/*.pngpublic/docs-static/img/manage/integrations/kubernetes/use-cases/route-to-a-kubernetes-service/topology.svgis excluded by!**/*.svg
📒 Files selected for processing (2)
src/components/NavigationDocs.jsxsrc/pages/manage/integrations/kubernetes/use-cases/route-to-a-kubernetes-service.mdx
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).
Summary
Adds a full how-to guide, Route to a Kubernetes service with high availability, under Kubernetes > Use Cases. It walks the whole journey of reaching a private in-cluster
ClusterIPService from a NetBird client through a redundant pool of routing-peer pods, so access survives a pod or node failure.The guide covers the NetBird-side pieces the operator does not create for you, then the operator CRDs, then verification:
Arecord (<service>.<namespace>.<zone>) automatically when you expose a Service.NetworkRouterwithworkloadOverride.replicas, the group-backed router at one metric for equal-metric failover, and the autoPodDisruptionBudget. Node spread is woven in: Kubernetes spreads replicas across nodes by default, with atopologySpreadConstraints(ScheduleAnyway) example and a note on theDoNotSchedulerolling-update deadlock.NetworkResource(ClusterIP-only) placed in the destination group.Also includes an appendix on friendly DNS names (CNAME alias to the operator-managed record) and a custom dark-mode topology diagram.
Changes
manage/integrations/kubernetes/use-cases/route-to-a-kubernetes-service.mdxtopology.svg+ dashboard/terminal screenshotsSummary by CodeRabbit