Bug 1574849

Description of problem:
In 3.10 there is a change where master and etcd services are running as static pods [1]. The way to control lifecycle of these pods is through an external script `master-restart`.

I see this as a major divergence from the Red Hat Enterprise Linux UX and the way our customers are used to work. I think it would be a source of frustration.

The reasons for the changes presented in the email are:

> better align us with the future converged platform and reduce the amount of supported installation paths for OpenShift
> reduce the number of ways that the platform can be configured 
> guide customers in paths that allow us to automatically update components
> beginning our transition away from installing bits on the host to a self-hosted configuration that leverages Kubernetes to do the busy work and prepares us to better align with an immutable host

I don't see the advantages of having a script to control lifecycle of the static pods compared to having a Systemd service. I don't see how having a systemd service prevents us achieving the above listed goals. Systemd services are flexible enough to do allow interaction with the system in a way that we see fit. For example they are used to control and report DBus services.

As an implementation, we can have a systemd service that uses kubelet API to restart and (un)deploy the static pods. It can use kubelet API to report status of said static pods also. They don't have to be synchronous or guarantee overall cluster availability. Btw such approach might even be more flexible than existing static pod definitions in files.

I believe this will preserve RHEL consistent experience with OpenShift as well still let us move ahead with our future goals. 

[1] http://post-office.corp.redhat.com/archives/aos-devel/2018-April/msg00015.html

Version-Release number of selected component (if applicable):
3.10