From fb2f3f89a926a4311df87017b53ea27ad0483e98 Mon Sep 17 00:00:00 2001 From: Irfan Ur Rehman Date: Fri, 1 Feb 2019 22:40:16 +0530 Subject: [PATCH] Update missing section in federation blog (#12417) --- .../_posts/2018-12-11-Kubernetes-Federation-Evolution.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2018-12-11-Kubernetes-Federation-Evolution.md b/content/en/blog/_posts/2018-12-11-Kubernetes-Federation-Evolution.md index 1bd5ceb6c9..02768fafd3 100644 --- a/content/en/blog/_posts/2018-12-11-Kubernetes-Federation-Evolution.md +++ b/content/en/blog/_posts/2018-12-11-Kubernetes-Federation-Evolution.md @@ -8,7 +8,12 @@ date: 2018-12-12 Kubernetes provides great primitives for deploying applications to a cluster: it can be as simple as `kubectl create -f app.yaml`. Deploy apps across multiple clusters has never been that simple. How should app workloads be distributed? Should the app resources be replicated into all clusters, replicated into selected clusters, or partitioned into clusters? How is access to the clusters managed? What happens if some of the resources that a user wants to distribute pre-exist, in some or all of the clusters, in some form? -In SIG Multicluster, our journey has revealed that there are multiple possible models to solve these problems and there probably is no single best-fit, all-scenario solution. [Federation](https://kubernetes.io/docs/concepts/cluster-administration/federation/), however, is the single biggest Kubernetes open source sub-project, and has seen the maximum interest and contribution from the community in this problem space. The project initially reused the Kubernetes API to do away with any added usage complexity for an existing Kubernetes user. This approach was not viable, because of problems discussed below. +In SIG Multicluster, our journey has revealed that there are multiple possible models to solve these problems and there probably is no single best-fit, all-scenario solution. [Federation](https://kubernetes.io/docs/concepts/cluster-administration/federation/), however, is the single biggest Kubernetes open source sub-project, and has seen the maximum interest and contribution from the community in this problem space. The project initially reused the Kubernetes API to do away with any added usage complexity for an existing Kubernetes user. This approach was not viable, because of the problems summarised below: + +* Difficulties in re-implementing the Kubernetes API at the cluster level, as federation-specific extensions were stored in annotations. +* Limited flexibility in federated types, placement and reconciliation, due to 1:1 emulation of the Kubernetes API. +* No settled path to GA, and general confusion on API maturity; for example, Deployments are GA in Kubernetes but not even Beta in Federation v1. + The ideas have evolved further with a federation-specific API architecture and a community effort which now continues as Federation v2.