Prasanta Kumar Behera
Cluster Design — Architect Track›08 · Customer-facing edge
Learning Hub / Kubernetes & Platform / Cluster Design — Architect Track

Lesson 08 of 13 · Architecture

Customer-facing edge

Design what faces the internet and how customers and teams are isolated: CDN, WAF, DDoS protection and rate limiting in front of the clusters, an API gateway for partner traffic, and a tenant isolation model (namespaces, virtual clusters or separate clusters) with the layers each one needs.

Architect
Key wordsCDNWAFDDoS protectionrate limitingAPI gatewaybot protectiontenant isolationnamespace per tenantcluster per tenantvirtual clustersnoisy neighbours

The internet-facing edge

ParcelPath's tracking API serves customers (browsers, mobile apps) and partner systems (retailers pushing orders):

customers ─┐                           partners ─► API gateway (auth, quotas, versions) ─┐
           ▼                                                                             ▼
   DNS/GSLB ─► CDN (static assets, cacheable GETs) ─► WAF + DDoS protection ─► L4 VIP ─► ingress ─► services
Layer Purpose ParcelPath choice (example)
CDN Cache static assets and cacheable tracking pages near users Managed CDN; short TTL for tracking data
WAF Block injection, exploits, bad bots Managed WAF rules + custom rules for the API
DDoS protection Absorb volumetric attacks Provider/ISP scrubbing service
Rate limiting Per IP / API key limits At the WAF (coarse) and gateway/ingress (fine)
API gateway Partner auth (OAuth2/API keys), quotas, versioning Gateway in front of partner routes only

The edge is the castle's outer defences: a moat that absorbs floods (DDoS protection), guards at the gate who check what people carry (WAF), a rule that each visitor may enter only so many times per hour (rate limits), and a separate entrance for trade partners with their own passes (API gateway). Inside the castle, each family has its own locked apartment (tenant isolation).

Tenant isolation model

ParcelPath's "tenants" are internal teams (and, later, a white-label offering for partner brands). Options:

Model Isolation Cost Fits
Namespace per team API (RBAC), network, quotas; shared kernel and control plane Low Trusted internal teams
Virtual clusters (e.g. vcluster) Own API server/objects per tenant; shared nodes Medium Teams needing CRDs/cluster-admin-like freedom
Cluster per tenant Nearly everything High Untrusted code, strict compliance, partner brands

ParcelPath decision (ADR-005): namespace per team in shared clusters for internal teams; separate clusters for any future white-label partner deployments with contractual isolation requirements.

The layers for namespace isolation

  1. RBAC: team groups (from SSO) bound to namespace roles only (see Kubernetes Security & Hardening, lesson 06).
  2. NetworkPolicy: default deny; explicit allows between services; egress limits for sensitive namespaces.
  3. ResourceQuota + LimitRange: no team can consume the whole cluster (noisy neighbours).
  4. Pod Security Admission restricted, plus a policy engine for registries, image signatures and labels.
  5. Node pools/taints for workloads that need kernel-level separation or special hardware.
  6. Separate ingress/hostnames per tenant where brands or certificates differ.

See Kubernetes Administration — Level by Level, lesson 29 for multi-tenancy patterns in depth.

Try it: isolate two teams

  1. Create namespaces team-orders and team-tracking with RBAC for two test users.
  2. Apply default-deny NetworkPolicies, then allow only tracking → orders on one port; test with curl pods.
  3. Add ResourceQuotas and try to exceed them.
  4. Enforce Pod Security restricted on both and try to run a privileged pod.
  5. Configure a per-client rate limit on your ingress controller and hit it with a load tool.

Going deeper: edge and tenancy trade-offs

  • Decide where rate limits live (edge vs gateway vs service) so limits are consistent and don't double-count.
  • Keep origin IPs (the L4 VIPs) reachable only from the CDN/WAF provider's ranges, otherwise attackers bypass the edge.
  • Document the isolation guarantees you actually provide per model; security reviews will ask.

Recap

  • Outside-in: DNS/GSLB → CDN → WAF + DDoS → L4 → ingress, plus an API gateway for partners and rate limits at sensible layers.
  • Isolation models: namespace per team (cheap), virtual clusters (control-plane isolation), cluster per tenant (strongest, costliest).
  • Namespace isolation needs RBAC, default-deny policies, quotas, Pod Security, policy engine, and dedicated nodes where needed.
  • Record the model and its guarantees in an ADR.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.