In general I'm not violently opposed to openshift, but there are a few things that make it difficult in production. There are several issues which make it slow for adoption in new kubernetes shops.
Red hat friends: would love feedback on these items in case I'm off on something. I really do think OpenShift has a use case in the enterprise, but I think the OKD branding around it is a little confusing since, a typical open source "community" wouldn't likely get much from running openshift in production.
For Dev ?
- Openshift-ansible takes a VERY long time to run. Easily 30 minutes or more for a reasonable (10 to 20 node) cluster often times. Although there is a developer preview of a binary installer, what I saw of it *forced me* to actually use AWS, i.e. I couldn't just run it as a standalone on a Linux VM (unless nested virtualization was enabled). Meanwhile, minikube runs anywhere, not even a VM required. And even minishift, pretty much requires a mac, or a virtualbox instance, and isn't runnable anywhere in the cloud. These are huge barriers to entry for the common man.
Although I love some things about openshift-ansible (for example, I'm guaranteed that I get NFS and cluster Clients and so on in my nodes when I run it). The costs of using openshift are only justified if you have a large, monolithic cluster with a ton of red hat support firepower behind it, and are running 100% RHEL in your data center. Otherwise you *MUST* use a standard kubernetes distribution.
- The Openshift API doesn't match the kubernetes API.
Customers which run on < 3.7, will find cloud native APIs breaking when it comes to deployments. The workaround here is to stay on replication controllers. As OCP lags kubernetes, the API semantics are not guaranteed to be the same as hardened kubernetes distributions. This isn't restricted, necessarily, to deployments.
This also means, that to build an "openshift native" application, you wind up having to separately grab an openshift client and vendor it into your app, and it may cause conflicts.
For Production ?
- CentOS binaries, missing !
Openshift isn't robustly tested on different operating systems, as an example, The centos binaries for running origin itself were completely missing for some time. And in fact, yum repositories were broken for it, as well, in various AWS regions ! Again, these are easy problems to solve if your paying for support, but otherwise, their showstoppers.
- ImageStreams create a lot of events.
In an attempt to add value, openshift attempts to manage builds for you.
Image streams can create a lot of events if you abuse the source to image pipeline inside of openshift. Although theoretically having openshift do all your builds for you is a great idea, at large scales, the concept becomes as much of a problem as it is a solution.
In fact, Images and their build infra in openshift, can even cause kubernetes problems ! We've had to put patches into the scheduler specifically to make it more performant to deal with the complex scheduling needed by openshift builds.
- RHEL takes over /run/secrets , breaking certain apps.
Its pretty common for developers to use /run/secrets, but RHEL instances actually *mount* over that directory in containers. This means your instantly breaking a default that is actually quite common in the docker community.
No comments:
Post a Comment