[lxc-devel] Integration Kubernetes and LXD/LXC

[Oliver Schad]

On Tue, 02 Oct 2018 18:04:12 +0200
Free Ekanayaka <free.ekanayaka at canonical.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20181002/8eafad59/attachment.sig>