2.5 Federated Amazon EKS cluster on AWS with local cloud provider - Hybrid Architectures to Address Personal Data Processing Requirements

This whitepaper is for historical reference only. Some content might be outdated and some links might not be available.

2.5 Federated Amazon EKS cluster on AWS with local cloud provider

Requirements addressed:

  • REQ4 (availability and durability)

AWS services – Amazon EKS

Federated Amazon EKS cluster on AWS

Federated Amazon EKS cluster on AWS

The federated control pod is deployed as a regular pod into Kubernetes cluster. For high availability purposes, we recommend that you make the Amazon EKS cluster primary.

Requirements REQ2 (data protection) and Customer-REQ1 (reliable connectivity) can be met using Architecture 1.1: Hybrid network connectivity from a data center to the AWS Cloud.

Federation can be done through the kubefed project, which allows you to coordinate the configuration of multiple Kubernetes clusters from a single set of APIs in a hosting cluster.

Note

This architecture is not for Data Residency (REQ1), as kubefed does not support federated management of persistent volumes, so you cannot manage databases in Kubernetes in federated mode.

Use cases:

  1. Dynamic capacity scale-out in the AWS Cloud for stateless workloads (not containing personal data)

  2. Geo- or latency-sensitive workloads (such as gaming workloads)

  3. Data residency use cases:

    1. A local-based API application in local a Kubernetes deployment (as part of Federation) with access to a local database

    2. A cloud-based API application in an Amazon EKS cluster (primary cluster in Federation) with access to an AWS database

  4. Single point of administration, configuration, or deployment (shared resources, configurations, API) among multiple geo-based Kubernetes clusters