Red Hat OpenShift 4.11 brings a substantial amount of new features. We’ve teased a few of them in our latest VSHN.timer, but in this article, we’re going to dive deeper into those that have the highest impact on our work and on our customers.
Support for CSI generic ephemeral volumes
Container Storage Interface (CSI) generic ephemeral volumes are a cool new feature. We foresee two important use cases for them:
- When users need an ephemeral volume that exceeds what the node’s file system provides;
- When users need an ephemeral volume with prepopulated data: this could be done, for example, by creating the volume from a snapshot.
The Route API now provides subdomain support, something that was not possible before 4.11:
You can now specify the spec.subdomain field and omit the spec.host field of a route. The router deployment that exposes the route will use the spec.subdomain value to determine the host name.
Pod Security Admissions
Pod security admission now runs globally with restricted audit logging and API warnings. This means that, while everything should still run as it did before, you will most likely encounter warnings like these if you relied on security contexts being set by OpenShift’s Security Context Constraints:
Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false…
To solve this issue, users now need to explicitly set security contexts in manifests to avoid these warnings.
The Developer Perspective provides improved integration with GitHub Actions, allowing developers to trigger pipelines and run tasks following Git events such as pushes or tags. And not only that, but the OpenShift console now has a dark mode, too.
The following OpenShift CLI (oc) commands and flags for requesting tokens are deprecated; these include:
oc serviceaccounts create-kubeconfig
oc serviceaccounts get-token
oc serviceaccounts new-token
--service-account/-zflag for the
oc registry logincommand
Moreover, the oc create token command generates tokens with a limited lifetime, which can be controlled with the
--duration command line argument. The API server can return a token with a lifetime that is shorter or longer than the requested lifetime. The command apparently generates tokens with a lifetime of one hour by default. If users need a token that doesn’t expire (for example, for a CI/CD pipeline), they should create a ServiceAccount API token secret instead.
OpenShift 4.11 on APPUiO Cloud
At the time of this writing, Red Hat has not yet decided to promote 4.11 as an upgrade target, and for that reason, we have not upgraded APPUiO Cloud clusters yet. As soon as Red Hat enables this, we will update our APPUiO Cloud zones accordingly.