The first option is to create a single Kubernetes cluster, and distribute the physical nodes of that cluster across data centers.

In this configuration, Kubernetes interprets the loss of a data center as a loss of a redundant node in the cluster. Kubernetes has no understanding of 'data centers' or the physical distance between nodes in the cluster. It sees a loss of a data center no differently than one or more machines in a single rack failing. This is, essentially, how many cloud providers offer 'availability zones' and other such cross-site resiliency assurances. Of course, the cluster ingress design (as discussed in the previous section) must allow for traffic entering both data centers.

The challenge with this approach is that it places a substantial burden on network engineers. This architecture treats all nodes as belonging to the same cluster, and therefore there is nothing to optimize or recognize LAN vs WAN network traffic or storage. Each node is expected to operate as through it was on the same switch as every other node, connected to the same underlying NAS, SAN or equivalent storage medium. This implies that the data centers will need to be linked with a high-bandwidth, low latency network connection between them. The exact requirements of this link depend entirely on the cluster’s load, CNI plugin, storage method, etc.