*: PersistentVolume for etcd data #1695
Conversation
this patch implements part 1 of the etcd data on persistent volumes design. when pod pvsource is defined in the spec it'll create a PVC for every etcd member and use it as the volume for etcd data. pvc without a member will be removed during the reconcile.
hongchaodeng
force-pushed
the
pv
branch
2 times, most recently
from
87d6b55 to
20e7ae0
Compare
|
I tried it and it worked with following spec: apiVersion: "etcd.database.coreos.com/v1beta2"
kind: "EtcdCluster"
metadata:
name: "example"
spec:
size: 3
pod:
persistentVolumeClaimSpec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 512Mi
storageClassName: standard
|
|
@sgotti Do you have time to take a review? |
|
@hongchaodeng I also prefer the use of a pvc template like done by statefulsets and it was my original idea but then I noticed that the backup spec used the PVSource so I adapted to it. |
|
Clarification: In case N (where N > 1) etcd clusters (deployed in the same namespace) where all of them use the similar PVC spec (example 10GB, readwriteonce). Would this PR as it stands today creates a risk where cluster A uses PVs meant to be used (or worse previously used) by cluster B? |
No. PV of cluster A will be owned (ownerRef) and used by members of cluster A only. Owner hierarchy would provide a clear separation. |
|
Any progress on merging this? |
|
@hongchaodeng , any plan of merging this soon? |
|
I don't have a good answer. But we don't have strong motivation for this at the moment. I'm still discussing it in company roadmap meeting. |
|
Our use case would be enable HA as much as possible for Azure Managed K8s service. I can take it over, mind give me contributor role to your |
|
@rjtsdl |
|
Closing in favor of #1861 |
issue ref: #1323
substitute #1434
This PR only handles non-failure cases.