Kubernetes Architecture in Financial Services

Lessons in platform design and operations from seven banks.

Cover of Kubernetes Architecture in Financial Services

169 pages | 22,000+ words | 83 illustrations

Explore the architecture decisions that help platform teams secure Kubernetes, deliver changes at speed, and keep critical services reliable.

By downloading, your email will be shared with Buoyant, Sysdig, and Nirmata. These sponsors may contact you about their products and services. You can unsubscribe from their communications at any time.
Sponsor privacy policies

You've probably seen this before:

  • A namespace separates API objects, but it does not fully isolate tenants. Network paths, workers, cloud accounts, databases, and backups may still be shared.
  • A shared CI system does not guarantee a consistent delivery path. Teams might still duplicate controls, miss updates, or handle the same requirement in different ways.
  • Rejecting a manifest is not enough for compliance. Policies need maintainers, visible exceptions, reports, and a safe way to adopt them.
  • Healthy components can still cause failed requests. Problems may come from timing, connection reuse, placement, or how components interact.

What is inside the book

Every chapter begins with a real platform problem, looks at the possible boundaries, and explores the tradeoffs in practice.

Chapter 1 | Rabobank

Where Does the Tenant Boundary Belong?

Does a namespace provide the isolation that the requirement actually needs?

See how tenant separation moves from RBAC and NetworkPolicy to virtual control planes, dedicated workers, cloud accounts, and external services.

  • Namespace, control-plane, worker, and account boundaries
  • Authorization, network access, quota, and noisy neighbors
  • Why Rabobank put the account before the cluster
Tenant isolation architecture diagram 1 of 2
Tenant isolation architecture diagram 2 of 2

Chapter 2 | ING

One Delivery Path, Many Applications

Which delivery steps belong to the platform, and which belong to each application team?

Compare team-owned pipelines, a single central pipeline, and templates that standardize releases while letting application teams make their own decisions.

  • Shared requirements versus copied implementations
  • Configuration, extension points, and team ownership
  • Versioned delivery contracts and controlled adoption
Application delivery architecture diagram 1 of 2
Application delivery architecture diagram 2 of 2

Chapter 3 | Chase UK

Make Policy Enforceable and Exceptions Visible

Can developers, operators, security teams, and auditors use the same policy evidence?

Link maintainable rules, admission controls, exceptions, and reports to keep policy decisions useful even after a request leaves the API server.

  • Admission policy at the shared API boundary
  • Audit mode, mutation, validation, and safe rollout
  • Scoped exceptions and fleet-wide reporting
Kubernetes policy architecture diagram 1 of 2
Kubernetes policy architecture diagram 2 of 2

Chapter 4 | Lunar

Trust Across Service Boundaries

Who manages discovery, identity, access rules, and verification for every cross-cluster connection?

Begin with external endpoints and client-managed credentials, then shift repeated connection tasks to a platform-managed service mesh.

  • External endpoints and client-managed mutual TLS
  • Cross-cluster identity and service discovery
  • What changes when the platform owns the connection
Cross-cluster service architecture diagram 1 of 2
Cross-cluster service architecture diagram 2 of 2

Chapter 5 | PostFinance

Healthy Components, Failing Requests

Why can every component look healthy while users still receive errors?

Track rare failures by checking logs, connection timing, API-server placement, client behavior, and ongoing path verification.

  • Reproducing timing instead of traffic volume
  • HTTP keepalive, HTTP/2 pinning, and server reselection
  • Continuous checks across API, DNS, Service, and Ingress paths
Kubernetes request failure diagram. 1 of 2
Kubernetes request failure diagram. 2 of 2

Chapter 6 | Saxo Bank

Reconstruct the Service's Dependencies

Can the bank rebuild a service without reconstructing its requirements from old tickets?

Compare tickets, pipelines, and reconciliation controllers to manage identities, database permissions, network rules, DNS, certificates, and messaging access.

  • Partial provisioning and safe retries
  • Authoritative intent versus stale success records
  • Reconciliation across Kubernetes and external systems
Service dependency reconciliation diagram 1 of 2
Service dependency reconciliation diagram 2 of 2

Chapter 7 | Itau Unibanco

Replace the Runtime, Preserve the Service

How can the platform maintain clusters without turning every change into a team coordination project?

Look at in-place upgrades, cluster replacement, and platforms that handle service placement and relocation as managed operations.

  • In-place maintenance versus replacement clusters
  • Runtime readiness, capacity, and dependency checks
  • Service handover, drain, fallback, and removal
Kubernetes runtime replacement diagram 1 of 2
Kubernetes runtime replacement diagram 2 of 2

What this book covers

Is this a Kubernetes security book?

Security is just one aspect of the architecture. The chapters also discuss platform ownership, delivery, policy operations, reliability, recovery, and infrastructure maintenance.

Does the book prescribe one platform stack?

No. The book compares different architectural boundaries and explains the operational costs of each option. The bank examples show how these tradeoffs work in practice.

Is this useful outside financial services?

Yes. While the examples are from banks, the decisions apply to any organization that needs strong isolation, compliance, reliability, and recovery.

Who is the book for?

This guide is for platform engineers, cloud architects, SREs, security engineers, and technical leaders who design or manage shared Kubernetes platforms.

Set clear boundaries before you standardize your platform

Use real-world banking lessons to set clear platform boundaries, strengthen security, and deliver changes at speed.

By downloading, your email will be shared with Buoyant, Sysdig, and Nirmata. These sponsors may contact you about their products and services. You can unsubscribe from their communications at any time.
Sponsor privacy policies

This book was made possible by

Lead Sponsor

Supporting Sponsors