Initial implementation for embedded datastore #500
Conversation
| @@ -0,0 +1,138 @@ | |||
| # How to use the embedded datastore | |||
|
|
|||
| Canonical Kubernetes supports using an embedded datastore such as etcd | |||
There was a problem hiding this comment.
I think this could lead to some level of confusion. It confused me. Mainly because this implies that there may be other options for an 'embedded' datastore (and slightly because it is etcd which may be slightly confusing as thats the example we use for an external datastore too).
From what I can see this means that we are building in our own etcd alongside dqlite and either can be used at deploy-time. It isn't entirely clear what each will be used for.
So in short, I think we need a much more detailed explanation document which covers the datastore, which we can then refer to from here and keep the explanations where they need to be, freeing this up to be a more straightforward howto
There was a problem hiding this comment.
Indeed embedded seems unclear to end users. dqlite is also positioned as an embedded database so if the user selects embedded as a datastore does it mean he wants dqlite or etcd? I think the intention here is to let users slect the option of a "managed-etcd". With "managed-etcd" it is clear you do not want "managed-dqlite" or "external-etcd".
Also the word "embedded" leads you to believe that etcd is embedded into k8s whereas in reality we keep it in its own service. The end user probably does not know that the correct term used among engineers doing the implementation of that that service is that they use an embedded etcd.
There was a problem hiding this comment.
Great work (most questions resolved offline).
As a general note: why do we call this embedded? At least I found it a bit confusing as it does not really convey that etcd is used. Can we not just call it etcd (at least for user facing configs)? Then we have datastore-type: k8s-dqlite|etcd|external which would make sense to me.
|
|
||
| // NOTE(neoaggelos): update kube-apiserver arguments in case cluster nodes have changed, but do not | ||
| // restart kube-apiserver, to avoid downtime for existing cluster nodes. The next time kube-apiserver | ||
| // restarts on this node, they will use the updated arguments. |
There was a problem hiding this comment.
That sounds dangerous. What if the kube-apiserver just don't restart for a long time. This would let the file arguments and what is configured on the running instance diverge/run out of sync.
There was a problem hiding this comment.
It would diverge but not run out of sync. The local etcd node will always be part of the etcd cluster, as long as it remains a control plane node.
|
|
||
| func NewEtcdPKI(opts EtcdPKIOpts) *EtcdPKI { | ||
| if opts.Years == 0 { | ||
| opts.Years = 10 |
There was a problem hiding this comment.
What happens when the self-signed CA expires? Do you have to manually create new ones?
| } | ||
| ``` | ||
|
|
||
| 2. Apply the new configuration using the k8sd API directly. You must run this |
There was a problem hiding this comment.
nit: maybe we should have a hidden command for that in the future.
This reverts commit 4036489.
Summary
Initial implementation for etcd datastore option.
Requires canonical/k8s-dqlite#105
Changes
pkg/client/etcdto interact with the embedded clusteretcddatastore typeNotes for reviewers