01-07-2019, 08:36 PM
Kubernetes Federation Evolution
<div style="margin: 5px 5% 10px 5%;"><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/01/kubernetes-federation-evolution.png" width="960" height="720" title="" alt="" /></div><div><div class="lcom-stacked__main">
<div class="panel-pane pane-entity-field pane-node-body">
<div class="field field-name-body field-type-text-with-summary field-label-hidden">
<div class="field-items">
<div class="field-item even">
<p>Deploying applications to a kubernetes cluster is well defined and can in some cases be as simple as <code>kubectl create -f app.yaml</code>. The user’s story to deploy apps across multiple clusters has not been that simple. How should an app workload be distributed? Should the app resources be replicated into all clusters, or replicated into selected clusters or partitioned into clusters? How is the access to clusters managed? What happens if some of the resources, which user wants to distribute pre-exist in all or fewer clusters in some form.</p>
<p>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. <a href="https://kubernetes.io/docs/concepts/cluster-administration/federation/">Federation</a> however is the single biggest kubernetes open source sub project which has seen maximum interest and contribution from the community in this problem space. The project initially reused the k8s API to do away with any added usage complexity for an existing k8s user. This became non-viable because of problems best discussed in this community update.</p>
<p>What has evolved further is a federation specific API architecture and a community effort which now continues as Federation V2.</p>
<h3>Conceptual Overview</h3>
<p>Because federation attempts to address a complex set of problems, it pays to break the different parts of those problems down. Let’s take a look at the different high-level areas involved:</p>
<p><img alt="Kubernetes Federation V2 Concepts" src="http://www.sickgaming.net/blog/wp-content/uploads/2019/01/kubernetes-federation-evolution.png" /></p>
<p>Read more at <a href="https://kubernetes.io/blog/2018/12/12/kubernetes-federation-evolution/">Kubernetes</a></p>
</div>
</div>
</div></div>
</p></div>
<p><a href="https://www.linux.com/popup/nojs" class="ctools-use-modal ctools-modal-subscription-modal-style element-invisible" title="">Click Here!</a> </p>
</div>
<div style="margin: 5px 5% 10px 5%;"><img src="http://www.sickgaming.net/blog/wp-content/uploads/2019/01/kubernetes-federation-evolution.png" width="960" height="720" title="" alt="" /></div><div><div class="lcom-stacked__main">
<div class="panel-pane pane-entity-field pane-node-body">
<div class="field field-name-body field-type-text-with-summary field-label-hidden">
<div class="field-items">
<div class="field-item even">
<p>Deploying applications to a kubernetes cluster is well defined and can in some cases be as simple as <code>kubectl create -f app.yaml</code>. The user’s story to deploy apps across multiple clusters has not been that simple. How should an app workload be distributed? Should the app resources be replicated into all clusters, or replicated into selected clusters or partitioned into clusters? How is the access to clusters managed? What happens if some of the resources, which user wants to distribute pre-exist in all or fewer clusters in some form.</p>
<p>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. <a href="https://kubernetes.io/docs/concepts/cluster-administration/federation/">Federation</a> however is the single biggest kubernetes open source sub project which has seen maximum interest and contribution from the community in this problem space. The project initially reused the k8s API to do away with any added usage complexity for an existing k8s user. This became non-viable because of problems best discussed in this community update.</p>
<p>What has evolved further is a federation specific API architecture and a community effort which now continues as Federation V2.</p>
<h3>Conceptual Overview</h3>
<p>Because federation attempts to address a complex set of problems, it pays to break the different parts of those problems down. Let’s take a look at the different high-level areas involved:</p>
<p><img alt="Kubernetes Federation V2 Concepts" src="http://www.sickgaming.net/blog/wp-content/uploads/2019/01/kubernetes-federation-evolution.png" /></p>
<p>Read more at <a href="https://kubernetes.io/blog/2018/12/12/kubernetes-federation-evolution/">Kubernetes</a></p>
</div>
</div>
</div></div>
</p></div>
<p><a href="https://www.linux.com/popup/nojs" class="ctools-use-modal ctools-modal-subscription-modal-style element-invisible" title="">Click Here!</a> </p>
</div>