[freedomben]

Disclaimer: I work at Red Hat with OpenShift

This is something I think OpenShift really adds value over "raw Kubernetes." With OpenShift you can treat it a bit like a flexible Heroku with `oc new-app` which can use s2i or your provided Dockerfile and will generate the foundation of what you need. You can then iterate on it if you need something beyond the standard setup.

By the way OKD 4 (the freely available upstream version of OpenShift) is now generally available: https://www.openshift.com/blog/okd4-is-now-generally-availab...

[gattacamovie]

okd4 came ~1yr after ocp4 was there. Can it be trusted it won't have such delays in the future ? What about security fixes, features, will they always lag behind as an incentive to get the paid version? In k8s, even if you maintain iy yourself, there is a huge community and you can always get your fixes. How does okd community compare? okd was on k8s 1.11 till few weeks back, 8 releases behind! Imagine the security issues okd had for such a long period... (ps: even centos seems to be lagging behing badly, centos 7.7 took many months after rhel 7.7).

as for ocp/okd tools like s2i, ansible for replacing helm, routes, deployment configs, etc -> they never took off, community did not agree. Those that did not take care to stay away from stuff that is not pure k8s suffer from beying disconnected from the rest of industry and have to invest to redo everything... not to mention their impossibility to switch to cloud providers solutions like eka,aks,pks,etc...

[freedomben]

Thanks for your comment. I'll take a bit at a time:

> okd4 came ~1yr after ocp4 was there. Can it be trusted it won't have such delays in the future ?

This is a fair criticism and great question. I was also really frustrated at this delay, although there was a pretty good technical reason for it. OpenShift was based on Red Hat Core OS, which until recently didn't have an upstream (Fedora CoreOS now fills this void). With the acquisition of Core OS, RH engineers saw an opportunity to totally rethink the Node portion of OpenShift. CoreOS allows you to treat the whole OS as immutable like containers, which makes for some fascinating possibilities. This became a hard requirement for master nodes for a few reasons, one of which is the Node itself is totally managed by an operator[1]. With RHEL being a subscription product, this was a problem for OKD users (no host OS!). I do think RH deserves criticism for not prioritizing the community high enough, but I can assure you it wasn't malice. Also because of this I don't worry about releases falling behind in the future since Fedora CoreOS is generally available now.

[1]: https://github.com/openshift/machine-config-operator

> as for ocp/okd tools like s2i, ansible for replacing helm, routes, deployment configs, etc -> they never took off, community did not agree.

This is untrue. DeploymentConfigs did take off. In fact, modern Deployments in K8s are the result of the community agreeing and integrating them into upstream K8s. There are minor differences that were made to balance priorities (primarily CAP theorem considerations, Consistency v Availability[2]), but the two are remarkably similar. The child resources of each (ReplicaSet and ReplicaController) are also super similar.

Regarding Ansible, that works just fine on K8s, and likewise Helm works fine on OCP. OpenShift is not a custom mangled version of K8s - it is K8s, with some custom resources slapped on top. It's true that OCP Routes don't work on plain K8s, but to say that it never took off because the community did not agree is not fair. The modern Ingress of K8s took a lot of inspiration from Routes. Red Hat is the number 2 contributor to K8s (behind Google) and constantly pushes code upstream whenever possible.

[2]: "DeploymentConfigs prefer consistency, whereas Deployments take availability over consistency. For DeploymentConfigs, if a node running a deployer Pod goes down, it will not get replaced. The process waits until the node comes back online or is manually deleted." See: https://docs.openshift.com/container-platform/4.1/applicatio....

> Those that did not take care to stay away from stuff that is not pure k8s suffer from beying disconnected from the rest of industry and have to invest to redo everything... not to mention their impossibility to switch to cloud providers solutions like eka,aks,pks,etc

I think "redo everything" is pretty unfair and borders on FUD. I've only known one person that moved from OCP to EKS, and the only thing they had to do was change their Route to an AWS Ingress (which is similarly non-portable I might add. It only works on AWS). If you use ImageStreams and such then yeah, you'll have to move those, but it's not very hard. Migrating from OpenShift to "other K8s distro" is really not that bad.

I would also point out that OpenShift/OKD can run nearly anywhere as well, so if you move from AWS to Azure, or bare metal or anything else, you don't necessarily have to abandon OpenShift. There's really no such thing as "just k8s" anyway. If you use any of the custom cloud provider stuff (like the AWS Ingress) then you're not portable without modifications either (and in some cases significant modifications if you have a highly customized ALB for example). If you care about portability, I think OpenShift/OKD is still a decent solution.