<commit_before>#Kubernetes Cluster Federation   
##(a.k.a. "Ubernetes")

## Requirements Analysis and Product Proposal

## _by <NAME> ([<EMAIL>](mailto:<EMAIL>))_  
_Initial revision: 2015-03-05_  
_Last updated: 2015-03-09_  
This doc: [tinyurl.com/ubernetes](http://tinyurl.com/ubernetesv2)  
Slides: [tinyurl.com/ubernetes-slides](http://tinyurl.com/ubernetes-slides)

## Introduction

Today, each Kubernetes cluster is a relatively self-contained unit,
which typically runs in a single "on-premise" data centre or single
availability zone of a cloud provider (Google's GCE, Amazon's AWS,
etc).

Several current and potential Kubernetes users and customers have
expressed a keen interest in tying together ("federating") multiple
clusters in some sensible way in order to enable the following kinds
of use cases (intentionally vague):

1. _"Preferentially run my workloads in my on-premise cluster(s), but
   automatically overflow to my cloud-hosted cluster(s) if I run out
   of on-premise capacity"_.
1. _"Most of my workloads should run in my preferred cloud-hosted
   cluster(s), but some are privacy-sensitive, and should be
   automatically diverted to run in my secure, on-premise
   cluster(s)"_.
1. _"I want to avoid vendor lock-in, so I want my workloads to run
   across multiple cloud providers all the time.  I change my set of
   such cloud providers, and my pricing contracts with them,<commit_msg>Fix incorrect doc link in Federation.md<commit_after>#Kubernetes Cluster Federation   
##(a.k.a. "Ubernetes")

## Requirements Analysis and Product Proposal

## _by <NAME> ([<EMAIL>](mailto:<EMAIL>))_  
_Initial revision: 2015-03-05_  
_Last updated: 2015-03-09_  
This doc: [tinyurl.com/ubernetesv2](http://tinyurl.com/ubernetesv2)  
Slides: [tinyurl.com/ubernetes-slides](http://tinyurl.com/ubernetes-slides)

## Introduction

Today, each Kubernetes cluster is a relatively self-contained unit,
which typically runs in a single "on-premise" data centre or single
availability zone of a cloud provider (Google's GCE, Amazon's AWS,
etc).

Several current and potential Kubernetes users and customers have
expressed a keen interest in tying together ("federating") multiple
clusters in some sensible way in order to enable the following kinds
of use cases (intentionally vague):

1. _"Preferentially run my workloads in my on-premise cluster(s), but
   automatically overflow to my cloud-hosted cluster(s) if I run out
   of on-premise capacity"_.
1. _"Most of my workloads should run in my preferred cloud-hosted
   cluster(s), but some are privacy-sensitive, and should be
   automatically diverted to run in my secure, on-premise
   cluster(s)"_.
1. _"I want to avoid vendor lock-in, so I want my workloads to run
   across multiple cloud providers all the time.  I change my set of
   such cloud providers, and my pricing contracts with them,
{'fraction_non_alphanumeric': 0.08211041229909155, 'fraction_numerical': 0.0143256464011181, 'mean_word_length': 4.537717601547389, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1621361', 'n_tokens_mistral': 870, 'n_tokens_neox': 813, 'n_words': 358}