The first post in this series discussed the planning and deployment phases of the life cycle. This post will focus on the core services needed by almost every OpenShift deployment. The next post will provide information on many of the customizations available to your cluster for your workload.
The OpenShift 4 installation process is different from OpenShift 3, providing a simplified experience for deploying a cluster and allowing the administrator to complete the configuration as a post-install, also known as day 2, operation. This is different from OpenShift 3, where after the installer was finished, the result was often a cluster that was considered very near “production-ready” with most services and functions deployed and configured.
For OpenShift 3’s installation experience to achieve this, the administrator decided which of the add-on features, like monitoring, logging, and the registry, are needed and provide the necessary configuration up-front. They could still be added, or reconfigured, afterward if needed though. OpenShift 4’s installer only goes as far as deploying and configuring the necessary features and services for a basic cluster deployment, requiring the administrator to configure add-on features after initial deployment.
Regardless of what type of applications, the number of pods you will be deploying, or what infrastructure you have deployed OpenShift to, you are going to need a few common, core services. These are things which are used by the cluster itself, but also add a lot of convenience and value by having integrated services available in every OpenShift cluster deployment.
I will not belabor the point, so let us get started. Before we begin, I will assume that you have successfully deployed your cluster, but have not done more than that at this point. Depending on your configuration, you may need to add a dynamic persistent storage provisioner or deploy OpenShift Container Storage before completing these steps. Last, but not least, don’t forget to subscribe / entitle your cluster at cloud.redhat.com, followed by choosing an update channel and applying available updates.
The core services represent four main pieces of functionality:
With a little bit of planning (which you did before deployment, right?), this set of steps is easy and straightforward to accomplish. As your cluster grows over time, be sure to revisit the sizing choices to ensure that they are adequate for your workload.
Hopefully, this post provides a starting point for completing the configuration of your OpenShift cluster so that both administrators and developers (and applications!) can take full advantage of everything offered by the platform.
The Red Hat Quay team and Red Hat OpenShift team are excited to announce the general availability of the mirror registry for Red Hat OpenShift. This is a small, streamlined container image registry ...
Red Hat Enterprise Linux CoreOS (RHCOS) is the only operating system supported on the OpenShift control plane nodes. Even though it is possible to deploy Red Hat Enterprise Linux (RHEL) worker nodes, ...