Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
×

New features and enhancements

Operators

Operators are pieces of software that ease the operational complexity of running another piece of software. They act like an extension of the software vendor’s engineering team, watching over a Kubernetes environment (such as OKD) and using its current state to make decisions in real time. Advanced Operators are designed to handle upgrades seamlessly, react to failures automatically, and not take shortcuts, like skipping a software backup process to save time.

Operator Lifecycle Manager (OLM)

This feature is now fully supported in OpenShift v4.

The OLM aids cluster administrators in installing, upgrading, and granting access to Operators running on their cluster:

  • Includes a catalog of curated Operators, with the ability to load other Operators into the cluster

  • Handles rolling updates of all Operators to new versions

  • Supports role-based access control (RBAC) for certain teams to use certain Operators

See Understanding the Operator Lifecycle Manager (OLM) for more information.

Installation and upgrade

Red Hat OpenShift v4 has an installer-provisioned infrastructure, where the installation program controls all areas of the installation process. Installer-provisioned infrastructure also provides an opinionated best practices deployment of OpenShift v4 for AWS instances only. This provides a slimmer default installation, with incremental feature buy-in through OperatorHub.

You can also install with a user-provided infrastructure on AWS, bare metal, or vSphere hosts. If you use the installer-provisioned infrastructure installation, the cluster provisions and manages all of the cluster infrastructure for you.

Upgrading from 3.x to 4 is currently not available. You must perform a new installation of OpenShift v4.

Easy, over-the-air upgrades for asynchronous z-stream releases of OpenShift v4 is available. Cluster administrators can upgrade using the Cluster Settings tab in the web console. See Updating a cluster for more information.

OperatorHub

OperatorHub is available to administrators and helps with easy discovery and installation of all optional components and applications. It includes offerings from Red Hat products, Red Hat partners, and the community.

Table 1. Features provided with base installation and OperatorHub
Feature New installer OperatorHub

Console and authentication

* [x]

-

Prometheus cluster monitoring

* [x]

-

Over-the-air updates

* [x]

-

Machine management

* [x]

-

Optional service brokers

-

* [x]

Optional OKD components

-

* [x]

Red Hat product Operators

-

* [x]

Red Hat partner Operators

-

* [x]

Community Operators

-

* [x]

See Understanding the OperatorHub for more information.

Storage

Storage support in OpenShift v4 is the same as OpenShift v3 with the exception of the following available in Technology Preview: EFS (CSI Driver handled via Amazon), Manila provisioner/operator, and Snapshot.

Scale

Cluster maximums

Updated guidance around Cluster maximums for OpenShift v4 is now available.

Use the OKD Limit Calculator to estimate cluster limits for your environment.

Node Tuning Operator

The Node Tuning Operator is now part of a standard OKD installation in OpenShift v4.

The Node Tuning Operator helps you manage node-level tuning by orchestrating the tuned daemon. The majority of high-performance applications require some level of kernel tuning. The Node Tuning Operator provides a unified management interface to users of node-level sysctls and more flexibility to add custom tuning, which is currently a Technology Preview feature, specified by user needs. The Operator manages the containerized tuned daemon for OpenShift Container Platform as a Kubernetes DaemonSet. It ensures the custom tuning specification is passed to all containerized tuned daemons running in the cluster in the format that the daemons understand. The daemons run on all nodes in the cluster, one per node.

Cluster monitoring

Autoscale pods horizontally based on the custom metrics API (Technology Preview)

This feature, currently in Technology Preview, enables you to configure horizontal pod autoscaling (HPA) based on the custom metrics API. As part of this Technology Preview, a Prometheus Adapter component can be deployed to provide any app metrics for the custom metrics API.

Limitations:

  • The adapter only connects to a single Prometheus instance (or a set of load-balanced replicas, using Kubernetes services).

  • Manually deploying adapter and configuring it to use Prometheus.

  • Syntax for the Prometheus Adapter configuration could change in the future.

  • The APIService configuration to wire Kubernetes' API aggregation to the instance of the custom metrics adapter will be overwritten in future releases, if OKD ships an out-of-the-box custom metrics adapter.

New alerting user interface

An alerting UI is now natively integrated into the OKD web console. You can now view cluster-level alerts and alerting rules from a single place, as well as configure silences.

Telemeter

Telemeter collects anonymized cluster-related metrics to proactively help customers with their OKD clusters. This helps:

  • Gather crucial health metrics of OKD installations.

  • Enable a viable feedback loop of OKD upgrades.

  • Gather the cluster’s number of nodes per cluster and their size (CPU cores and RAM).

  • Gather the size of etcd.

  • Gather details about the health condition and status for any OpenShift framework component installed on an OpenShift cluster.

Autoscale pods horizontally based on the resource metrics API

By default, OpenShift Cluster Monitoring exposes CPU and Memory utilization through the Kubernetes resource metrics API. There is no longer a requirement to install a separate metrics server.

Developer experience

Multi-stage Dockerfile Builds Generally Available

Multi-stage Dockerfiles are now supported in all Docker strategy builds.

Registry

The registry is now managed by an Operator

The registry is now managed by an Operator instead of oc adm registry.

Networking

Cluster Network Operator (CNO)

The cluster network is now configured and managed by an Operator. The Operator upgrades and monitors the cluster network.

OpenShift SDN

The default mode is now NetworkPolicy.

Multus

Multus is a meta plug-in for Kubernetes Container Network Interface (CNI), which enables a user to create multiple network interfaces per pod.

SR-IOV

OpenShift v4 includes the Technical Preview capability to use specific SR-IOV hardware on OKD nodes, which enables the user to attach SR-IOV virtual function (VF) interfaces to Pods in addition to other network interfaces.

F5 router plug-in support

F5 router plug-in is no longer supported as part of OKD directly. However, F5 has developed a container connector that replaces the functionality. It is recommended to work with F5 support to implement their solution.

Web console

Developer Catalog

OpenShift v4 features a redesigned Developer Catalog that brings all of the new Operators and existing broker services together, with new ways to discover, sort, and understand how to best use each type of offering. The Developer Catalog is the entry point for a developer to access all services available to them. It merges all capabilities from Operators, the Service Catalog, brokers, and Source-to-Image (S2I).

New management screens

New management screens in OpenShift v4 support automated operations. Examples include the management of machine sets and machines, taints, tolerations, and cluster settings.

Security

In OpenShift v4, Operators are utilized to install, configure, and manage the various certificate signing servers. Certificates are managed as secrets stored within the cluster itself.