You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should add a spec.readOnly which would set the entire cluster read-only (even the master node).
The controller should make sure that once the readOnly condition in status is set to true, there is no way the master becomes writable. It is ok to have a spec.readOnly=false cluster with all it's pod read-only, but it's a bug to have a spec.readOnly=true and status.conditions[readOnly]=true with writable pods.
For this we need to do the following:
all cluster pods start read-only
the controller is responsible of making the master pod writable
make sure that orchestrator is started with ApplyMySQLPromotionAfterMasterFailover set to false
The text was updated successfully, but these errors were encountered:
…oke#58)
These are some necessary but not sufficient changes to support running
etcd across Kubernetes clusters with the EtcdLockserver controller.
These new fields allow you to:
- Disable PDB since it can't see Pods in other clusters.
- Disable Services since they need to be managed separately.
- Deploy only one etcd member in each cluster.
- Override peer URLs so they can find each other across clusters.
Signed-off-by: Anthony Yeh <[email protected]>
We should add a
spec.readOnly
which would set the entire cluster read-only (even the master node).The controller should make sure that once the
readOnly
condition in status is set totrue
, there is no way the master becomes writable. It is ok to have aspec.readOnly=false
cluster with all it's pod read-only, but it's a bug to have aspec.readOnly=true
andstatus.conditions[readOnly]=true
with writable pods.For this we need to do the following:
ApplyMySQLPromotionAfterMasterFailover
set tofalse
The text was updated successfully, but these errors were encountered: