From a7f4402e41555db052170f2a3c039ec184b7c70f Mon Sep 17 00:00:00 2001 From: Derek Parker Date: Mon, 2 May 2016 12:09:37 -0700 Subject: [PATCH] docs: Update self-hosted proposal --- docs/proposals/self-hosted-kubelet.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/docs/proposals/self-hosted-kubelet.md b/docs/proposals/self-hosted-kubelet.md index e5459c2476..7bafd64eec 100644 --- a/docs/proposals/self-hosted-kubelet.md +++ b/docs/proposals/self-hosted-kubelet.md @@ -31,7 +31,9 @@ Documentation for other releases can be found at ## Abstract -In a self-hosted Kubernetes deployment, we have the initial bootstrap problem. +In a self-hosted Kubernetes deployment (see (this +comment)[https://github.com/kubernetes/kubernetes/issues/246#issuecomment-64533959] +for background on self hosted kubernetes), we have the initial bootstrap problem. When running self-hosted components, there needs to be a mechanism for pivoting from the initial bootstrap state to the kubernetes-managed (self-hosted) state. In the case of a self-hosted kubelet, this means pivoting from the initial @@ -40,7 +42,9 @@ to the node. This proposal presents a solution to the kubelet bootstrap, and assumes a functioning control plane (e.g. an apiserver, controller-manager, scheduler, and -etcd cluster), and a kubelet that can securely contact the API server. +etcd cluster), and a kubelet that can securely contact the API server. This +functioning control plane can be temporary, and not necessarily the "production" +control plane that will be used after the initial pivot / bootstrap. ## Background and Motivation @@ -71,9 +75,10 @@ explained in detail below. ## Proposal We propose adding a new flag to the kubelet, the `--bootstrap` flag, which is -assumed to be used in conjunction with the `--lock-file` flag. When the -`--bootstrap` flag is provided, after the kubelet acquires the file lock, it -will begin asynchronously waiting on +assumed to be used in conjunction with the `--lock-file` flag. The `--lock-file` +flag is used to ensure only a single kubelet is running at any given time during +this pivot process. When the `--bootstrap` flag is provided, after the kubelet +acquires the file lock, it will begin asynchronously waiting on [inotify](http://man7.org/linux/man-pages/man7/inotify.7.html) events. Once an "open" event is received, the kubelet will assume another kubelet is attempting to take control and will exit by calling `exit(0)`. @@ -139,9 +144,10 @@ Various similar approaches have been discussed [here](https://github.com/kubernetes/kubernetes/issues/246#issuecomment-64533959) and [here](https://github.com/kubernetes/kubernetes/issues/23073#issuecomment-198478997). -This also relies on the kubelet being able to be run inside a container, more -discussion on that is -[here](https://github.com/kubernetes/kubernetes/issues/4869). +Other discussion around the kubelet being able to be run inside a container is +[here](https://github.com/kubernetes/kubernetes/issues/4869). Note this isn't a +strict requirement as the kubelet could be run in a chroot jail via rkt fly or +other such similar approach. Additionally, [Taints and Tolerations](../../docs/design/taint-toleration-dedicated.md), whose design has