TLS bootstrapping: Remove "Limits" section

The aforementioned "Limits" is no longer valid. The issue that the
section points at is closed after code merge.

Signed-off-by: Suraj Deshmukh <surajd.service@gmail.com>
This commit is contained in:
Suraj Deshmukh
2020-06-11 17:26:32 +05:30
parent dccabfed82
commit 59f5e70b2f
@@ -443,15 +443,3 @@ also manually approve certificate requests using kubectl. An administrator can
list CSRs with `kubectl get csr` and describe one in detail with `kubectl list CSRs with `kubectl get csr` and describe one in detail with `kubectl
describe csr <name>`. An administrator can approve or deny a CSR with `kubectl describe csr <name>`. An administrator can approve or deny a CSR with `kubectl
certificate approve <name>` and `kubectl certificate deny <name>`. certificate approve <name>` and `kubectl certificate deny <name>`.
## Limits
Although Kubernetes supports running control plane master components like kube-apiserver and kube-controller-manager in containers, and even as `Pod`s in a kubelet, as of this writing, you cannot both TLS Bootstrap a kubelet and run master plane components on it.
The reason for this limitation is that the kubelet attempts to bootstrap communication with kube-apiserver _before_ starting any pods, even static ones define on disk and referenced via the kubelet option `--pod-manifest-path=<PATH>`. Trying to do both TLS Bootstrapping and master components in kubelet leads to a race condition: kubelet needs to communicate to kube-apiserver to request certificates, yet requires those certificates to be available to start kube-apiserver.
An issue is open referencing this [here](https://github.com/kubernetes/kubernetes/issues/68686).