📖 Update book section regarding external etcd #2962
Conversation
Re-organize content for easier reading. Update commands for creating Secrets. Fix incorrect reference to etcd server certificate. Add section on potential caveats for various CAPI providers. Signed-off-by: Scott Lowe <[email protected]>
k8s-ci-robot
added
the
cncf-cla: yes
|
Welcome @scottslowe! |
k8s-ci-robot
added
the
needs-ok-to-test
|
Hi @scottslowe. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
k8s-ci-robot
added
the
size/M
|
|
||
| These key/pair are used to sign etcd server, peer certificates and eventually apiserver-etcd client. More information on how to setup external etcd with kubeadm can be found [`here`](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/#setting-up-the-cluster). | ||
| This certificate and private key are used to sign etcd server, peer certificates and eventually apiserver-etcd-client certificate. More information on how to setup external etcd with kubeadm can be found [here](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/#setting-up-the-cluster). |
There was a problem hiding this comment.
kubeadm also uses the etcd CA to sign healthcheck-client.{crt|key}, which are more appropriate to have been called client... as the resulting TLS configuration is used for more actions than just "healthcheck". the healthcheck- part is residue from the days when kubeadm used a bash/etcdctl liveness probe for etcd server instances.
leaving it to you if you want to document it as e.g. just client certificates, or omit this part.
There was a problem hiding this comment.
I've updated it in 1876bc0, PTAL.
|
|
||
| You'll use these files to create the necessary Secrets on the management cluster (see the "Creating the required Secrets" section). | ||
|
|
||
| ### Setting up etcd with etcdadm (Alpha) |
There was a problem hiding this comment.
/cc @dlipovetsky
i'm having flashbacks about a similar PR some time ago.
did we end up not wanting to have etcdadm docs in CAP yet;; i cannot recall?
There was a problem hiding this comment.
never mind, i see this was present already bellow.
@dlipovetsky PTAL if you can at the update.
|
|
||
| ## Additional Notes/Caveats | ||
|
|
||
| * Depending on the provider, additional changes to the workload cluster's manifest may be necessary to ensure the new CAPI-managed nodes have connectivity to the existing etcd nodes. For example, on AWS you will need to leverage the `additionalSecurityGroups` field on the AWSMachine and/or AWSMachineTemplate objects to add the CAPI-managed nodes to a security group that has connectivity to the existing etcd cluster. Other mechanisms exist for other providers. |
There was a problem hiding this comment.
if someone likes to put their etcd cluster behind a LB this has the benefit of kubeadm not knowing the whole list of external member SANs. in theory this would allow the etcd cluster to grow / change without kubeadm knowing. unclear to me weather --etcd-servers for kube-apiservers can including only that LB DNS though. EDIT: actually --etcd-servers needs ip:port.
we don't have this in the kubeadm docs, so probably we need to add it there first.
There was a problem hiding this comment.
It sounds like maybe we can omit a discussion of using an LB for etcd here until it has been added to other documentation. Is there an issue somewhere for addressing this in the kubeadm docs? Maybe I can help in some way.
There was a problem hiding this comment.
It sounds like maybe we can omit a discussion of using an LB for etcd here
yes
Is there an issue somewhere for addressing this in the kubeadm docs
no, i don't think anyone has tested this on our side.
Maybe I can help in some way.
it's very low priority unless there is more demand. before documenting it, it needs an e2e test too using kinder.
Update wording around etcd certificates per reviewer feedback Signed-off-by: Scott Lowe <[email protected]>
k8s-ci-robot
added
the
lgtm
|
/ok-to-test |
k8s-ci-robot
added
ok-to-test
|
/milestone v0.3.6 |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: scottslowe, vincepri The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retitle 📖 Update book section regarding external etcd |
k8s-ci-robot
added
the
approved
k8s-ci-robot
changed the title
What this PR does / why we need it:
This PR updates the documentation on using external etcd with CAPI workload clusters so as to provide clearer instructions on how users might use this functionality.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #2941