From d5a8837c95a90ed450b36196b0c942229cb43915 Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Tue, 20 Dec 2016 10:53:26 -0800 Subject: design-proposal: add self-hosted kubernetes proposal This had been a design doc on Google Docs but it is constantly referenced so move it to the Kubernetes repo. Old doc: https://docs.google.com/document/d/1VNp4CMjPPHevh2_JQGMl-hpz9JSLq3s7HlI87CTjl-8/edit# --- .../design-proposals/self-hosted-final-cluster.png | Bin 0 -> 22888 bytes .../design-proposals/self-hosted-kubernetes.md | 88 +++++++++++++++++++++ .../design-proposals/self-hosted-layers.png | Bin 0 -> 17774 bytes .../design-proposals/self-hosted-moving-parts.png | Bin 0 -> 36201 bytes 4 files changed, 88 insertions(+) create mode 100644 contributors/design-proposals/self-hosted-final-cluster.png create mode 100644 contributors/design-proposals/self-hosted-kubernetes.md create mode 100644 contributors/design-proposals/self-hosted-layers.png create mode 100644 contributors/design-proposals/self-hosted-moving-parts.png diff --git a/contributors/design-proposals/self-hosted-final-cluster.png b/contributors/design-proposals/self-hosted-final-cluster.png new file mode 100644 index 00000000..e5302b07 Binary files /dev/null and b/contributors/design-proposals/self-hosted-final-cluster.png differ diff --git a/contributors/design-proposals/self-hosted-kubernetes.md b/contributors/design-proposals/self-hosted-kubernetes.md new file mode 100644 index 00000000..9cca1762 --- /dev/null +++ b/contributors/design-proposals/self-hosted-kubernetes.md @@ -0,0 +1,88 @@ +# Proposal: Self-hosted Control Plane + +Author: Brandon Philips +Last Updated: 2016-12-20 + +## Motivations + +> Running in our components in pods would solve many problems, which we'll otherwise need to implement other, less portable, more brittle solutions to, and doesn't require much that we don't need to do for other reasons. Full self-hosting is the eventual goal. + +- Brian Grant ([ref](https://github.com/kubernetes/kubernetes/issues/4090#issuecomment-74890508)) + +### What is self-hosted? + +Self-hosted Kubernetes runs all required and optional components of a Kubernetes cluster on top of Kubernetes itself. + +The advantages of a self-hosted Kubernetes cluster are: + +1. **Small Dependencies:** self-hosted should reduce the number of components required, on host, for a Kubernetes cluster to be deployed to a Kubelet (ideally running in a container). This should greatly simplify the perceived complexity of Kubernetes installation. +2. **Deployment consistency:** self-hosted reduces the number of files that are written to disk or managed via configuration management or manual installation via SSH. Our hope is to reduce the number of moving parts relying on the host OS to make deployments consistent in all environments. +3. **Introspection:** internal components can be debugged and inspected by users using existing Kubernetes APIs like `kubectl logs` +4. **Cluster Upgrades:** Related to introspection the components of a Kubernetes cluster are now subject to control via Kubernetes APIs. Upgrades of Kubelet's are possible via new daemon sets, API servers can be upgraded using daemon sets and potentially deployments in the future, and flags of add-ons can be changed by updating deployments, etc. (An example script is in progress.) + +However, there is a spectrum of ways that a cluster can be self-hosted. To do this we are going to divide the Kubernetes cluster into a variety of layers beginning with the Kubelet (level 0) and going up to the add-ons (Level 4). A cluster can self-host all of these levels 0-4 or only partially self-host. + +![](self-hosted-layers.png) + +For example, a 0-4 self-hosted cluster means that the kubelet is a daemon set, the API server runs as a pod and is exposed as a service, and so on. While a 1-4 self-hosted cluster would have a system installed Kubelet. + +## Practical Implementation Overview + +This document outlines the current implementation of "self-hosted Kubernetes" installation and upgrade of Kubernetes clusters based on the work that the teams at CoreOS and Google have been doing. The work is motivated by the upstream "Self-hosted Proposal". + +The entire system is working today and is used by Bootkube, a Kubernetes Incubator project, and all Tectonic clusters created since July 2016. This document outlines the implementation, not the experience. The experience goal is that users not know all of these details and instead get a working Kubernetes cluster out the other end that can be upgraded using the Kubernetes APIs. + +The target audience of this document are others, like [kubeadm](https://github.com/kubernetes/kubernetes/pull/38407), thinking about and building the way forward for install and upgrade of Kubernetes. If you want a higher level demonstration of "Self-Hosted" and the value see this [video and blog](https://coreos.com/blog/self-hosted-kubernetes.html). + + +### Bootkube + +Today, the first component of the installation of a self-hosted cluster is [`bootkube`](https://github.com/kubernetes-incubator/bootkube). A kubelet connects to the temporary Kubernetes API server provided by bootkube and is told to deploy the required Kubernetes components, as pods. This diagram shows all of the moving parts: + +![](self-hosted-moving-parts.png) + +At the end of this process the bootkube can be shut down and the system kubelet will coordinate, through a POSIX lock, to let the self-hosted kubelet take over lifecycle and management of the control plane components. The final cluster state looks like this: + +![](self-hosted-final-cluster.png) + + +### Bootkube Challenges + +This process has a number of moving parts. Most notably the hand off of control from the "host system" to the Kubernetes self-hosted system. And things can go wrong: + +1) The self-hosted Kubelet is in a precarious position as there is no one around to restart the process if it crashes. The high level is that the system init system will watch for the Kubelet POSIX lock and start the system Kubelet if the lock is missing. Once the system Kubelet starts it will launch the self-hosted Kubelet. + +2) Recovering from reboots of single-master installations is a challenge as the Kubelet won't have an API server to talk to to restart the self-hosted components. We are solving this today with "[user space checkpointing](https://github.com/kubernetes-incubator/bootkube/tree/master/cmd/checkpoint#checkpoint)" container in the Kubelet pod that will periodically check the pod manifests and persist them to the static pod manifest directory. Longer term we would like for the kubelet to be able to checkpoint itself without external code. + +## Long Term Goals + +Ideally bootkube disappears over time and is replaced by a [Kubelet pod API](https://github.com/kubernetes/kubernetes/issues/28138). The write API would enable an external installation program to setup the control plane of a self-hosted Kubernetes cluster without requiring an existing API server. + +[Checkpointing](https://github.com/kubernetes/kubernetes/issues/489) is also required to make for a reliable system that can survive a number of normal operations like full down scenarios of the control plane. Today, we can sufficiently do checkpointing external of the Kubelet process, but checkpointing inside of the Kubelet would be ideal. + +A simple updater can take care of helping users update from v1.3.0 to v1.3.1, etc over time. + +### Self-hosted Cluster Upgrades + +#### Kubelet upgrades + +The kubelet could be upgraded in a very similar process to that outlined in the self-hosted proposal. + +However, because of the challenges around the self-hosted Kubelet (see above) Tectonic has implemented an alternative scheme that side-steps the self-hosted Kubelet challenges. First, a kubelet system service is launched that uses the [chrooted kubelet](https://github.com/kubernetes/community/pull/131) implemented by the [kubelet-wrapper](https://coreos.com/kubernetes/docs/latest/kubelet-wrapper.html) then when an update is required a daemonset updates the kubelet-wrapper configuration based on version annotations and kills the kubelet PID triggering a restart. + +#### API Server, Scheduler, and Controller Manager + +Upgrading these components is fairly straightforward. They are stateless, easily run in containers, and can be modeled as pods and services. Upgrades are simply a matter of deploying new versions, health checking them, and changing the service label selectors. + +#### etcd self-hosted + +As the primary data store of Kubernetes etcd plays an important role. Today, etcd does not run on top of the self-hosted cluster. However, progress is being made with the introduction of the [etcd Operator](https://coreos.com/blog/introducing-the-etcd-operator.html) and integration into [bootkube](https://github.com/kubernetes-incubator/bootkube/blob/848cf581451425293031647b5754b528ec5bf2a0/cmd/bootkube/start.go#L37). + +### Conclusions + +Kubernetes self-hosted is working today. Bootkube is an implementation of the "temporary control plane" and this entire process has been used by [`bootkube`](https://github.com/kubernetes-incubator/bootkube) users and Tectonic since the Kubernetes v1.4 release. We are excited to give users a simpler installation flow and sustainable cluster lifecycle upgrade/management. + +## Known Issues + +- [Health check endpoints for components don't work correctly](https://github.com/kubernetes-incubator/bootkube/issues/64#issuecomment-228144345) +- [kubeadm doesn't do self-hosted yet](https://github.com/kubernetes/kubernetes/pull/38407) diff --git a/contributors/design-proposals/self-hosted-layers.png b/contributors/design-proposals/self-hosted-layers.png new file mode 100644 index 00000000..1dc3e06a Binary files /dev/null and b/contributors/design-proposals/self-hosted-layers.png differ diff --git a/contributors/design-proposals/self-hosted-moving-parts.png b/contributors/design-proposals/self-hosted-moving-parts.png new file mode 100644 index 00000000..423add2e Binary files /dev/null and b/contributors/design-proposals/self-hosted-moving-parts.png differ -- cgit v1.2.3 From 3d5eb3e4a3b64b9656ad9b9e59be64803b89f97f Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Wed, 21 Dec 2016 15:05:31 -0800 Subject: design-proposals: self-hosted-kubernetes updates Address questions around the kubelet node agent and load balancing and control plane nodes. --- contributors/design-proposals/self-hosted-kubernetes.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/contributors/design-proposals/self-hosted-kubernetes.md b/contributors/design-proposals/self-hosted-kubernetes.md index 9cca1762..a4d1fae0 100644 --- a/contributors/design-proposals/self-hosted-kubernetes.md +++ b/contributors/design-proposals/self-hosted-kubernetes.md @@ -45,6 +45,9 @@ At the end of this process the bootkube can be shut down and the system kubelet ![](self-hosted-final-cluster.png) +There are a few things to note. First, generally, the control components like the API server, etc will be pinned to a set of dedicated control nodes. For security policy, service discovery, and scaling reasons it is easiest to assume that control nodes will always exist on N nodes. + +Another challenge is load balancing the API server. Bedrock for the API server will be DNS, TLS, and a load balancer that live off cluster and that load balancer will want to only healthcheck a handful of servers for the API server port liveness probe. ### Bootkube Challenges @@ -68,7 +71,7 @@ A simple updater can take care of helping users update from v1.3.0 to v1.3.1, et The kubelet could be upgraded in a very similar process to that outlined in the self-hosted proposal. -However, because of the challenges around the self-hosted Kubelet (see above) Tectonic has implemented an alternative scheme that side-steps the self-hosted Kubelet challenges. First, a kubelet system service is launched that uses the [chrooted kubelet](https://github.com/kubernetes/community/pull/131) implemented by the [kubelet-wrapper](https://coreos.com/kubernetes/docs/latest/kubelet-wrapper.html) then when an update is required a daemonset updates the kubelet-wrapper configuration based on version annotations and kills the kubelet PID triggering a restart. +However, because of the challenges around the self-hosted Kubelet (see above) Tectonic currently has a 1-4 self-hosted cluster with an alternative Kubelet update scheme which side-steps the self-hosted Kubelet issues. First, a kubelet system service is launched that uses the [chrooted kubelet](https://github.com/kubernetes/community/pull/131) implemented by the [kubelet-wrapper](https://coreos.com/kubernetes/docs/latest/kubelet-wrapper.html) then when an update is required a node annotation is made which is read by a long-running daemonset that updates the kubelet-wrapper configuration. This makes Kubelet versions updateable from the cluster API. #### API Server, Scheduler, and Controller Manager -- cgit v1.2.3 From 71d92d83db1a73038f39b0164f5a77835b5cc60b Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Mon, 16 Jan 2017 20:43:20 -0800 Subject: design-proposals: add sections on HA address some feedback requesting HA notes --- contributors/design-proposals/self-hosted-kubernetes.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/contributors/design-proposals/self-hosted-kubernetes.md b/contributors/design-proposals/self-hosted-kubernetes.md index a4d1fae0..dbd2dc14 100644 --- a/contributors/design-proposals/self-hosted-kubernetes.md +++ b/contributors/design-proposals/self-hosted-kubernetes.md @@ -5,9 +5,9 @@ Last Updated: 2016-12-20 ## Motivations -> Running in our components in pods would solve many problems, which we'll otherwise need to implement other, less portable, more brittle solutions to, and doesn't require much that we don't need to do for other reasons. Full self-hosting is the eventual goal. - -- Brian Grant ([ref](https://github.com/kubernetes/kubernetes/issues/4090#issuecomment-74890508)) +> Running our components in pods would solve many problems, which we'll otherwise need to implement other, less portable, more brittle solutions to, and doesn't require much that we don't need to do for other reasons. Full self-hosting is the eventual goal. +> +> - Brian Grant ([ref](https://github.com/kubernetes/kubernetes/issues/4090#issuecomment-74890508)) ### What is self-hosted? @@ -77,9 +77,17 @@ However, because of the challenges around the self-hosted Kubelet (see above) Te Upgrading these components is fairly straightforward. They are stateless, easily run in containers, and can be modeled as pods and services. Upgrades are simply a matter of deploying new versions, health checking them, and changing the service label selectors. +In HA configurations the API servers should be able to be upgraded in-place one-by-one and rely on external load balancing or client retries to recover from the temporary downtime. This relies on Kubernetes [versioning policy](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/versioning.md). + #### etcd self-hosted -As the primary data store of Kubernetes etcd plays an important role. Today, etcd does not run on top of the self-hosted cluster. However, progress is being made with the introduction of the [etcd Operator](https://coreos.com/blog/introducing-the-etcd-operator.html) and integration into [bootkube](https://github.com/kubernetes-incubator/bootkube/blob/848cf581451425293031647b5754b528ec5bf2a0/cmd/bootkube/start.go#L37). +As the primary data store of Kubernetes etcd plays an important role. Today, etcd does not run on top of the self-hosted cluster. However, progress is being made with the introduction of the [etcd Operator](https://coreos.com/blog/introducing-the-etcd-operator.html) and integration into [bootkube](https://github.com/kubernetes-incubator/bootkube/blob/848cf581451425293031647b5754b528ec5bf2a0/cmd/bootkube/start.go#L37). + +### Highly-available Clusters + +Self-hosted will make operating highly-available clusters even easier. For internal critical components like the scheduler and controller manager, which already know how to leader elect themselves, creating HA instances will be a simple matter of `kubectl scale` for most administrators. For the data store, etcd, the etcd Operator will ease much of the scaling concern. + +However, the API server will be a slightly trickier matter for most deployments as the API server relies on either external load balancing or external DNS in most common HA configurations. But, with the addition of Kubernetes label metadata on the [Node API](https://github.com/kubernetes/kubernetes/pull/39112) self-hosted may make it easier for systems administrators to create glue code that finds the appropriate Node IPs and adds them to these external systems. ### Conclusions -- cgit v1.2.3 From de711ac20424e5a847227c28ee0675eb7e3213a1 Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Tue, 17 Jan 2017 09:25:59 -0800 Subject: design-proposals: fixup nits from pires Good feedback on HA setup notes and some grammar fixups --- contributors/design-proposals/self-hosted-kubernetes.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/contributors/design-proposals/self-hosted-kubernetes.md b/contributors/design-proposals/self-hosted-kubernetes.md index dbd2dc14..bc80f58a 100644 --- a/contributors/design-proposals/self-hosted-kubernetes.md +++ b/contributors/design-proposals/self-hosted-kubernetes.md @@ -1,7 +1,6 @@ # Proposal: Self-hosted Control Plane Author: Brandon Philips -Last Updated: 2016-12-20 ## Motivations @@ -18,7 +17,8 @@ The advantages of a self-hosted Kubernetes cluster are: 1. **Small Dependencies:** self-hosted should reduce the number of components required, on host, for a Kubernetes cluster to be deployed to a Kubelet (ideally running in a container). This should greatly simplify the perceived complexity of Kubernetes installation. 2. **Deployment consistency:** self-hosted reduces the number of files that are written to disk or managed via configuration management or manual installation via SSH. Our hope is to reduce the number of moving parts relying on the host OS to make deployments consistent in all environments. 3. **Introspection:** internal components can be debugged and inspected by users using existing Kubernetes APIs like `kubectl logs` -4. **Cluster Upgrades:** Related to introspection the components of a Kubernetes cluster are now subject to control via Kubernetes APIs. Upgrades of Kubelet's are possible via new daemon sets, API servers can be upgraded using daemon sets and potentially deployments in the future, and flags of add-ons can be changed by updating deployments, etc. (An example script is in progress.) +4. **Cluster Upgrades:** Related to introspection the components of a Kubernetes cluster are now subject to control via Kubernetes APIs. Upgrades of Kubelet's are possible via new daemon sets, API servers can be upgraded using daemon sets and potentially deployments in the future, and flags of add-ons can be changed by updating deployments, etc. +5. **Easier Highly-Available Configurations:** Using Kubernetes APIs will make it easier to scale up and monitor an HA environment without complex external tooling. Because of the complexity of these configurations tools that create them without self-hosted often implement significant complex logic. However, there is a spectrum of ways that a cluster can be self-hosted. To do this we are going to divide the Kubernetes cluster into a variety of layers beginning with the Kubelet (level 0) and going up to the add-ons (Level 4). A cluster can self-host all of these levels 0-4 or only partially self-host. @@ -37,10 +37,12 @@ The target audience of this document are others, like [kubeadm](https://github.c ### Bootkube -Today, the first component of the installation of a self-hosted cluster is [`bootkube`](https://github.com/kubernetes-incubator/bootkube). A kubelet connects to the temporary Kubernetes API server provided by bootkube and is told to deploy the required Kubernetes components, as pods. This diagram shows all of the moving parts: +Today, the first component of the installation of a self-hosted cluster is [`bootkube`](https://github.com/kubernetes-incubator/bootkube). Bootkube provides a temporary Kubernetes control plane that kicks tells a kubelet to execute all of the components necessary to run a full blown Kubernetes control plane. When the kubelet connects to this temporary API server it will deploy the required Kubernetes components, as pods. This diagram shows all of the moving parts: ![](self-hosted-moving-parts.png) +Note: In the future this temporary control plane may be replaced with a kubelet API that will enable injection of this state directly into the kubelet without a temporary Kubernetes API server. + At the end of this process the bootkube can be shut down and the system kubelet will coordinate, through a POSIX lock, to let the self-hosted kubelet take over lifecycle and management of the control plane components. The final cluster state looks like this: ![](self-hosted-final-cluster.png) @@ -71,7 +73,7 @@ A simple updater can take care of helping users update from v1.3.0 to v1.3.1, et The kubelet could be upgraded in a very similar process to that outlined in the self-hosted proposal. -However, because of the challenges around the self-hosted Kubelet (see above) Tectonic currently has a 1-4 self-hosted cluster with an alternative Kubelet update scheme which side-steps the self-hosted Kubelet issues. First, a kubelet system service is launched that uses the [chrooted kubelet](https://github.com/kubernetes/community/pull/131) implemented by the [kubelet-wrapper](https://coreos.com/kubernetes/docs/latest/kubelet-wrapper.html) then when an update is required a node annotation is made which is read by a long-running daemonset that updates the kubelet-wrapper configuration. This makes Kubelet versions updateable from the cluster API. +However, because of the challenges around the self-hosted Kubelet (see above) Tectonic currently has a 1-4 self-hosted cluster with an alternative Kubelet update scheme which side-steps the self-hosted Kubelet issues. First, a kubelet system service is launched that uses the [chrooted kubelet](https://github.com/kubernetes/community/pull/131) implemented by the [kubelet-wrapper](https://coreos.com/kubernetes/docs/latest/kubelet-wrapper.html). Then, when an update is required, a node annotation is made which is read by a long-running daemonset that updates the kubelet-wrapper configuration. This makes Kubelet versions updateable from the cluster API. #### API Server, Scheduler, and Controller Manager @@ -85,7 +87,7 @@ As the primary data store of Kubernetes etcd plays an important role. Today, etc ### Highly-available Clusters -Self-hosted will make operating highly-available clusters even easier. For internal critical components like the scheduler and controller manager, which already know how to leader elect themselves, creating HA instances will be a simple matter of `kubectl scale` for most administrators. For the data store, etcd, the etcd Operator will ease much of the scaling concern. +Self-hosted will make operating highly-available clusters even easier. For internal critical components like the scheduler and controller manager, which already know how to leader elect using the Kubernetes leader election API, creating HA instances will be a simple matter of `kubectl scale` for most administrators. For the data store, etcd, the etcd Operator will ease much of the scaling concern. However, the API server will be a slightly trickier matter for most deployments as the API server relies on either external load balancing or external DNS in most common HA configurations. But, with the addition of Kubernetes label metadata on the [Node API](https://github.com/kubernetes/kubernetes/pull/39112) self-hosted may make it easier for systems administrators to create glue code that finds the appropriate Node IPs and adds them to these external systems. -- cgit v1.2.3 From 916dfa89f67a2057218c24a3df632d5e1b2811f0 Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Tue, 17 Jan 2017 09:32:35 -0800 Subject: design-proposals: note on kubelet exit-on-lock-contention From https://kubernetes.io/docs/admin/kubelet/ --- contributors/design-proposals/self-hosted-kubernetes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributors/design-proposals/self-hosted-kubernetes.md b/contributors/design-proposals/self-hosted-kubernetes.md index bc80f58a..c10d1a2e 100644 --- a/contributors/design-proposals/self-hosted-kubernetes.md +++ b/contributors/design-proposals/self-hosted-kubernetes.md @@ -43,7 +43,7 @@ Today, the first component of the installation of a self-hosted cluster is [`boo Note: In the future this temporary control plane may be replaced with a kubelet API that will enable injection of this state directly into the kubelet without a temporary Kubernetes API server. -At the end of this process the bootkube can be shut down and the system kubelet will coordinate, through a POSIX lock, to let the self-hosted kubelet take over lifecycle and management of the control plane components. The final cluster state looks like this: +At the end of this process the bootkube can be shut down and the system kubelet will coordinate, through a POSIX lock (see `kubelet --exit-on-lock-contention`), to let the self-hosted kubelet take over lifecycle and management of the control plane components. The final cluster state looks like this: ![](self-hosted-final-cluster.png) -- cgit v1.2.3 From a06518ffcec09edd13691db6fd71737f2f52ab55 Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Thu, 19 Jan 2017 20:46:53 -0800 Subject: design-proposals: add feedback from roberthbailey - fixup some grammar mistakes - add skew of control plane to known issues - add links dropped from original proposal --- contributors/design-proposals/self-hosted-kubernetes.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/contributors/design-proposals/self-hosted-kubernetes.md b/contributors/design-proposals/self-hosted-kubernetes.md index c10d1a2e..81fddf0a 100644 --- a/contributors/design-proposals/self-hosted-kubernetes.md +++ b/contributors/design-proposals/self-hosted-kubernetes.md @@ -24,20 +24,19 @@ However, there is a spectrum of ways that a cluster can be self-hosted. To do th ![](self-hosted-layers.png) -For example, a 0-4 self-hosted cluster means that the kubelet is a daemon set, the API server runs as a pod and is exposed as a service, and so on. While a 1-4 self-hosted cluster would have a system installed Kubelet. +For example, a 0-4 self-hosted cluster means that the kubelet is a daemon set, the API server runs as a pod and is exposed as a service, and so on. While a 1-4 self-hosted cluster would have a system installed Kubelet. And a 02-4 system would have everything except etcd self-hosted. ## Practical Implementation Overview -This document outlines the current implementation of "self-hosted Kubernetes" installation and upgrade of Kubernetes clusters based on the work that the teams at CoreOS and Google have been doing. The work is motivated by the upstream "Self-hosted Proposal". +This document outlines the current implementation of "self-hosted Kubernetes" installation and upgrade of Kubernetes clusters based on the work that the teams at CoreOS and Google have been doing. The work is motivated by the early ["Self-hosted Proposal"](https://github.com/kubernetes/kubernetes/issues/246#issuecomment-64533959) by Brian Grant. -The entire system is working today and is used by Bootkube, a Kubernetes Incubator project, and all Tectonic clusters created since July 2016. This document outlines the implementation, not the experience. The experience goal is that users not know all of these details and instead get a working Kubernetes cluster out the other end that can be upgraded using the Kubernetes APIs. - -The target audience of this document are others, like [kubeadm](https://github.com/kubernetes/kubernetes/pull/38407), thinking about and building the way forward for install and upgrade of Kubernetes. If you want a higher level demonstration of "Self-Hosted" and the value see this [video and blog](https://coreos.com/blog/self-hosted-kubernetes.html). +The entire system is working today and is used by Bootkube, a Kubernetes Incubator project, to create 2-4 and 1-4 self-hosted clusters. All Tectonic clusters created since July 2016 are 2-4 self-hosted and will be moving to 1-4 early in 2017 as the self-hosted etcd work becomes stable in bootkube. This document outlines the implementation, not the experience. The experience goal is that users not know all of these details and instead get a working Kubernetes cluster out the other end that can be upgraded using the Kubernetes APIs. +The target audience are projects in SIG Cluster Lifecycle thinking about and building the way forward for install and upgrade of Kubernetes. We hope to inspire direction in various Kubernetes components like kubelet and [kubeadm](https://github.com/kubernetes/kubernetes/pull/38407) to make self-hosted a compelling mainstream installation method. If you want a higher level demonstration of "Self-Hosted" and the value see this [video and blog](https://coreos.com/blog/self-hosted-kubernetes.html). ### Bootkube -Today, the first component of the installation of a self-hosted cluster is [`bootkube`](https://github.com/kubernetes-incubator/bootkube). Bootkube provides a temporary Kubernetes control plane that kicks tells a kubelet to execute all of the components necessary to run a full blown Kubernetes control plane. When the kubelet connects to this temporary API server it will deploy the required Kubernetes components, as pods. This diagram shows all of the moving parts: +Today, the first component of the installation of a self-hosted cluster is [`bootkube`](https://github.com/kubernetes-incubator/bootkube). Bootkube provides a temporary Kubernetes control plane that tells a kubelet to execute all of the components necessary to run a full blown Kubernetes control plane. When the kubelet connects to this temporary API server it will deploy the required Kubernetes components as pods. This diagram shows all of the moving parts: ![](self-hosted-moving-parts.png) @@ -79,7 +78,7 @@ However, because of the challenges around the self-hosted Kubelet (see above) Te Upgrading these components is fairly straightforward. They are stateless, easily run in containers, and can be modeled as pods and services. Upgrades are simply a matter of deploying new versions, health checking them, and changing the service label selectors. -In HA configurations the API servers should be able to be upgraded in-place one-by-one and rely on external load balancing or client retries to recover from the temporary downtime. This relies on Kubernetes [versioning policy](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/versioning.md). +In HA configurations the API servers should be able to be upgraded in-place one-by-one and rely on external load balancing or client retries to recover from the temporary downtime. This is not well tested upstream and something we need to fix (see known issues). #### etcd self-hosted @@ -99,3 +98,4 @@ Kubernetes self-hosted is working today. Bootkube is an implementation of the "t - [Health check endpoints for components don't work correctly](https://github.com/kubernetes-incubator/bootkube/issues/64#issuecomment-228144345) - [kubeadm doesn't do self-hosted yet](https://github.com/kubernetes/kubernetes/pull/38407) +- The Kubernetes [versioning policy](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/versioning.md) allows for version skew of kubelet and control plane but not skew between control plane components themselves. We must add testing and validation to Kubernetes that this skew works. Otherwise the work to make Kubernetes HA is rather pointless if it can't be upgraded in an HA manner as well. -- cgit v1.2.3 From d08603423ffc23b1796f53848c43ee1c152a351f Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Fri, 20 Jan 2017 07:07:41 -0800 Subject: design-proposals: add note about self-hosted not replacing existing methods Thanks to @timothysc for pointing out that I didn't make a note about the intentions of this proposal with existing install/config methods. --- contributors/design-proposals/self-hosted-kubernetes.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/contributors/design-proposals/self-hosted-kubernetes.md b/contributors/design-proposals/self-hosted-kubernetes.md index 81fddf0a..cafbc596 100644 --- a/contributors/design-proposals/self-hosted-kubernetes.md +++ b/contributors/design-proposals/self-hosted-kubernetes.md @@ -26,6 +26,8 @@ However, there is a spectrum of ways that a cluster can be self-hosted. To do th For example, a 0-4 self-hosted cluster means that the kubelet is a daemon set, the API server runs as a pod and is exposed as a service, and so on. While a 1-4 self-hosted cluster would have a system installed Kubelet. And a 02-4 system would have everything except etcd self-hosted. +It is also important to point out that self-hosted stands alongside other methods to install and configure Kubernetes, including scripts like kube-up.sh, configuration management tools, and deb/rpm/etc packages. A non-goal of this self-hosted proposal is replacing or introducing anything that might impede these installation and management methods. In fact it is likely that by dogfooding Kubernetes APIs via self-hosted improvements will be made to Kubernetes components that will simplify other installation and management methods. + ## Practical Implementation Overview This document outlines the current implementation of "self-hosted Kubernetes" installation and upgrade of Kubernetes clusters based on the work that the teams at CoreOS and Google have been doing. The work is motivated by the early ["Self-hosted Proposal"](https://github.com/kubernetes/kubernetes/issues/246#issuecomment-64533959) by Brian Grant. -- cgit v1.2.3