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:
@@ -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).
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user