whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updated self-hosting documentation (#13866)

Browse Source 
* updated self-hosting documentation

* removed more referances

* updated wording

* updated self-hosting warning to be more clear about the effects of pivot has on your cluster

* Update content/en/docs/setup/independent/self-hosting.md

Co-Authored-By: Klaven <mcounts@suse.com>
This commit is contained in:
Marek Counts
2019-05-07 14:30:41 -04:00
committed by Kubernetes Prow Robot
parent 99ae92bdf9
commit a1f811d852
5 changed files with 66 additions and 73 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
-51
View File
@@ -275,57 +275,6 @@ to the kubelet.
Be aware that overriding the hostname can [interfere with cloud providers](https://github.com/kubernetes/website/pull/8873).
### Self-hosting the Kubernetes control plane {#self-hosting}
As of 1.8, you can experimentally create a _self-hosted_ Kubernetes control
plane. This means that key components such as the API server, controller
manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
configured in the kubelet via static files.
To create a self-hosted cluster see the `kubeadm alpha selfhosting` command.
#### Caveats
1. Self-hosting in 1.8 and later has some important limitations. In particular, a
self-hosted cluster _cannot recover from a reboot of the control-plane node_
without manual intervention.
1. A self-hosted cluster is not upgradeable using `kubeadm upgrade`.
1. By default, self-hosted control plane Pods rely on credentials loaded from
[`hostPath`](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath)
volumes. Except for initial creation, these credentials are not managed by
kubeadm.
1. The self-hosted portion of the control plane does not include etcd,
which still runs as a static Pod.
#### Process
The self-hosting bootstrap process is documented in the [kubeadm design
document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
In summary, `kubeadm alpha selfhosting` works as follows:
1. Waits for this bootstrap static control plane to be running and
healthy. This is identical to the `kubeadm init` process without self-hosting.
1. Uses the static control plane Pod manifests to construct a set of
DaemonSet manifests that will run the self-hosted control plane.
It also modifies these manifests where necessary, for example adding new volumes
for secrets.
1. Creates DaemonSets in the `kube-system` namespace and waits for the
resulting Pods to be running.
1. Once self-hosted Pods are operational, their associated static Pods are deleted
and kubeadm moves on to install the next component. This triggers kubelet to
stop those static Pods.
1. When the original static control plane stops, the new self-hosted control
plane is able to bind to listening ports and become active.
### Running kubeadm without an internet connection
For running kubeadm without an internet connection you have to pre-pull the required control-plane images.