Missing Parts of OpenShift Dedicated


I have been working on OpenShift Dedicated (on AWS) for a few weeks. At the time of writing (v3.5.5.31), here are a couple missing parts that I have found out so far. They are all confirmed by the RedHat support.

  • Share persistent volume across multiple containers: Currently there is no way to share the persistent volume (EBS backup) across different containers. So if your pods need shared storage, then unfortunately it is not scalable.
  • White listing ingress IP addresses: You can not lock down your ELB to specific IP addresses. Unless you do it by yourself. e.g  Router/ELB > Nginx service > Web service
  • Backup and restore persistent volume: RedHat openshift operation team does nightly EBS snapshot, but the backup and restore are not guaranteed. Also there is no documented process how you can request them to restore it. So if you have important data, you cannot really reply on them.
  • Self-service of persistent volume resize: You have to open a ticket to request the RedHat to resize the persistent volume for you.  The current OpenShift dedicated console does not monitor PV size usage either, you have to work it out by yourself. If you use Nagios, here is a plugin that I wrote you can use.
  • Monitor alerting: the OpenShift console comes with simple real time monitoring for CPU, RAM and network. It does not have the alerting feature.
  • Project name validation: You can create a new project and name it as openshift blah blah. But soon or later you will run into issues, as openshift* is a reserved keyword for some internal projects. The project name validation will be introduced in v3.6.

In summary, for those trade offs I don’t recommend to use OpenShift Dedicated.

 

Advertisement

One thought on “Missing Parts of OpenShift Dedicated

  1. Are those restrictions still in place today? What version of dedicated are you running now?

    None of the restrictions that you mention would effect moving our business from openshift online pro onto openshift dedicated.We don’t run the database in inside the cluster (we use DBaaS in the same AWS). Shared PVCs seem like an antipattern over using a blog storage service (we use AWS S3). Since we don’t use PVCs for any permanent storage we don’t care about resizing them nor them being backed up. We do use PVCs for redis but as that’s ephemeral data a fixed sized single writer PVC is fine. I think it would be nice if the dedicated service offered premium PVC with restore, resize and all that for people running database but I wouldn’t expect that we would pay extra for it.

    With monitoring and alerting we are using SaaS products so don’t find that openshift.com does not have good monitoring and alerting a problem.

    For whitelisting for super user access we looked at running an openvpn helm chart but decided that it wasn’t worth the effort. As we are using shared openshift.com cluster its reasonable that we cannot modify it. It would be nice if the dedicated service offered it. Yet whitelisting shouldn’t ever be the only line of defence (human error can remove it) so things like mTLS or 2FA or VPN should be used.If those are done properly then whitelisting seems a bit redundant.

    Project name validation is very annoying. With openshift.com shared clusters you can clash with every other customer how has a “demo”, “test” or “uat” project etc. We just preix with our company name. The only place this really bit me was writing tutorials for devs to try things out where they had to use their own personal initials in the prefix.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s