On Tue, 02 Oct 2018 18:04:12 +0200 Free Ekanayaka <[email protected]> wrote:
> Yeah, that's probably the key point indeed. The design is based on the > "pets vs kettle" idea, so the expectation is that you are fine with > any of your pod being restarted at any time. And if you use > kubernetes, you'll have a hard time going against this design > principle. Yes, but possible. Choosing the right container engine to avoid restarts is important. > That being said, one thing that is still not clear to me it's why k8s > would issue disruptive restart requests against your (MySQL?) pods. > Does it happen as consequence of some manifest/spec change? I'd > expect k8s to not restart stuff unless there's a good reason to do > that. The good reason is i.e. because it's easy: if you hash your pod attributes to calculate the pod's name and you extend your pod data structure in the next kubernetes release, you will get a new hash, which will be different. So for the kubelet, this *is* a good reason, because they needed a simple implementation to compare current state and desired state. For the purpose of 24/7 online, this is a bad reason of course. So they have good reasons to do, what they do - but thought from the point of view, that restarting stuff is not a big deal. For a production SQL master server, this *is* a big deal. What we want to archieve is some awareness for the requirement of 24/7 online. > If you have a cluster of stateful pods that need special orchestration > to handle restart (say the master must first perform a graceful > failover or things like that), I think the recommended way these days > would be to implement your own "operator" which drives the dance in > the way you want. See: > > https://coreos.com/operators/ Exactly, that is the way to go: controllers for operations - even if I can't really say, that we have experience with the CoreOS operators. However: that is the pattern. > I don't know the details, but I would expect such operator to handle > any operation gracefully, including possible restarts (but, again, I > think those shouldn't really happen quite that often in a stable > production environment). There are some problems with that approach as well, but we use that pattern. Best Regards Oli
pgpSQTZKQcBgQ.pgp
Description: OpenPGP digital signature
_______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
