Ask an OpenShift Admin Office Hour - What’s new in OpenShift 4.9?

The latest Red Hat OpenShift release is here, so what does that mean for administrators? In today's episode, we take an inside look at the features of OpenShift 4.9 which are relevant for administrators, including new changes and features that can help you be successful in the hybrid cloud. Among some of the latest and exciting features for admins in this release, we'll explore MetalLB support, single node OpenShift with UPI, certified Helm Charts, Kubernetes 1.22 changes, and more.

As always, please see the list below for additional links to specific topics, questions, and supporting materials for the episode!

If you’re interested in more streaming content, please subscribe to the Red Hat livestreaming calendar to see the upcoming episode topics and to receive any schedule changes. If you have questions or topic suggestions for the Ask an OpenShift Admin Office Hour, please contact us via Discord, Twitter, or come join us live, Wednesdays at 11am EDT / 1500 UTC, on YouTube and Twitch.

Episode 46 recorded stream:

Use this link to jump directly to where we start talking about today’s topic. 

This week’s top of mind topics:

• Earlier this month product management published a blog post which announced a change to the extended update support (EUS) policy for OpenShift releases. The terse summary is that, starting with OpenShift 4.8, all releases are supported for 18th months and evenly numbered releases, e.g. 4.8, 4.10, 4.12, etc. will have a streamlined update process between them, reducing the time it takes to update significantly. We talked about it during the stream here if you want more information, and of course be sure to read the blog post.
• The command line tools downloaded from the console of an OpenShift cluster have what appears to be a mismatched version. For example, downloading from an OpenShift 4.8.14 will have tools that report version 4.8.0. However, this is simply a result of how the version tags are assigned - they really are built exactly for that version of OpenShift, so you can use them without concern.
• 4.7 -> 4.8 updates are blocked (again), but did you know that whenever an update edge is blocked, for example updates from 4.7 -> 4.8, we publish errata notifying of the blocked edge and why it’s blocked? If you didn’t, give this segment a view and be sure to configure email alerts from the errata portal.

Questions answered and topics discussed during the stream:

• One of our viewers asked the question “how do you recommend managing CLI and GUI sessions to multiple clusters at the same time?” This will really depend on your workflow and how you best organize your workspace. I use different terminal windows with colors to identify which one I’m connected to. You can also customize the OpenShift web interface to help differentiate between the clusters, for example by putting a banner with a different color on each cluster.
• Even though OpenShift 4.9 is available and ready to be installed, it’s not yet in the stable channel. This is normal and expected, it’ll take some time - historically, 45-60 days - before a new release is promoted to the stable upgrade channel. However, you can do a fully supported update from 4.8 to 4.9 using the fast channel if you’re ready now.
• If using the fast channel is an option for you, not only is the upgrade fully supported by Red Hat, but it helps provide us with valuable data about the process and identify any unknown issues that could be encountered.
• Another viewer question: “is proactively checking BugZilla to identify what is addressed in a release worthwhile?” In general, yes, though it can be a bit overwhelming and hard to identify the status. The release notes and errata may be better depending on your needs.
• One of the most exciting new features of OpenShift 4.9 is that single node OpenShift, a.k.a. SNO, is now fully supported! This means you can deploy a fully functional OpenShift “cluster” to a single physical server with (we recommend) 8 CPUs and 32GiB memory.
• Single node OpenShift can be deployed using Assisted Installer, which is itself in tech preview, and using the command line, like with all other deployment types. Starting here, we do a demo of deploying SNO using openshift-install. You can find the prereqs and steps I used during the demo here.
• You can add the bootstrap in place ignition config to the ISO used to boot the SNO node. Doing this is straightforward using the coreos-installer binary, which we demonstrate during the stream here.
• We kick off the install of RHCOS to the single node here in the stream, where we also talk about how to do things like set a static IP and provide the ignition file from a web server.
• Don’t forget (like I almost did) to configure the prereqs, most importantly the appropriate DNS records. The list of those can be found in the documentation or at the gist linked above.
• I missed the question during the stream, but one of our viewers asked whether a DHCP lease with an infinite lease time would work for the single node OpenShift host. Yes, that does work exactly as you would expect, just be sure to have the DNS entries configured correctly for the same IP assigned to the node.
• Red Hat Enterprise Linux (RHEL) 7 compute nodes are deprecated with the release of OpenShift 4.9. RHEL 8 nodes are now supported, which means that if you’re using RHEL compute nodes, you will want to migrate from RHEL 7 to RHEL 8 soon.
• VMware vSphere 6.7 update 2 and VMware hardware versions earlier than 15 are deprecated with OpenShift. This is required for CSI driver integration, which can come from either VMware or Red Hat, though the Red Hat CSI driver for VMware is currently in tech preview. If you’re currently using a virtual hardware version less than 15, you’ll want to begin the process of updating the VMs soon, which we talk about during this segment of the stream.
• You can now customize the Routes used for system functions, such as the console and oAuth. The documentation explains how to configure the Routes for the console, downloads, and oAuth.
• Etcd is automatically defragmented by the Operator in OpenShift 4.9. During the stream we spent some time talking about how fragmentation happens and why it’s important for this function to run. You can see how to configure the defragmentation in the documentation.
• A viewer question, what about API updates with Kubernetes 1.22? We also had a stream about the API deprecations and removals in 1.22 here.
• When will OpenShift 3.11 be end of life? You can find specific information and dates on the lifecycle page here. June 2022 is when OpenShift 3.11 goes into extended life phase. This is a somewhat significant change in the level of support offered, be sure to read the page linked to understand what “extended life phase” means and how it will impact you.