Before you install OKD, decide what kind of installation process to follow and verify that you have all of the required resources to prepare the cluster for users.
Before you install an OKD cluster, you need to select the best installation instructions to follow. Think about your answers to the following questions to select the best option.
If you want to install and manage OKD yourself, you can install it on the following platforms:
Alibaba Cloud
Amazon Web Services (AWS) on 64-bit x86 instances
Microsoft Azure on 64-bit x86 instances
Microsoft Azure on 64-bit ARM instances
Microsoft Azure Stack Hub
Google Cloud Platform (GCP) on 64-bit x86 instances
Google Cloud Platform (GCP) on 64-bit ARM instances
OpenStack
IBM Cloud®
IBM Z® or IBM® LinuxONE
IBM Z® or IBM® LinuxONE for Fedora KVM
IBM Power®
IBM Power® Virtual Server
Nutanix
VMware vSphere
Bare metal or other platform agnostic infrastructure
You can deploy an OKD 4 cluster to both on-premise hardware and to cloud hosting services, but all of the machines in a cluster must be in the same data center or cloud hosting service.
If you want to use OKD but you do not want to manage the cluster yourself, you can choose from several managed service options. If you want a cluster that is fully managed by Red Hat, you can use OpenShift Dedicated. You can also use OpenShift as a managed service on Azure, AWS, IBM Cloud®, or Google Cloud Platform. For more information about managed services, see the OpenShift Products page. If you install an OKD cluster with a cloud virtual machine as a virtual bare metal, the corresponding cloud-based storage is not supported.
If you used OKD 3 and want to try OKD 4, you need to understand how different OKD 4 is. OKD 4 weaves the Operators that package, deploy, and manage Kubernetes applications and the operating system that the platform runs on, Fedora CoreOS (FCOS), together seamlessly. Instead of deploying machines and configuring their operating systems so that you can install OKD on them, the FCOS operating system is an integral part of the OKD cluster. Deploying the operating system for the cluster machines is part of the installation process for OKD. See Differences between OKD 3 and 4.
Because you need to provision machines as part of the OKD cluster installation process, you cannot upgrade an OKD 3 cluster to OKD 4. Instead, you must create a new OKD 4 cluster and migrate your OKD 3 workloads to them. For more information about migrating, see Migrating from OKD 3 to 4 overview. Because you must migrate to OKD 4, you can use any type of production cluster installation process to create your new cluster.
Because the operating system is integral to OKD, it is easier to let the installation program for OKD stand up all of the infrastructure. These are called installer provisioned infrastructure installations. In this type of installation, you can provide some existing infrastructure to the cluster, but the installation program deploys all of the machines that your cluster initially needs.
You can deploy an installer-provisioned infrastructure cluster without specifying any customizations to the cluster or its underlying machines to Alibaba Cloud, AWS, Azure, Azure Stack Hub, GCP, Nutanix.
If you need to perform basic configuration for your installer-provisioned infrastructure cluster, such as the instance type for the cluster machines, you can customize an installation for Alibaba Cloud, AWS, Azure, GCP, Nutanix.
For installer-provisioned infrastructure installations, you can use an existing VPC in AWS, vNet in Azure, or VPC in GCP. You can also reuse part of your networking infrastructure so that your cluster in AWS, Azure, GCP can coexist with existing IP address allocations in your environment and integrate with existing MTU and VXLAN configurations. If you have existing accounts and credentials on these clouds, you can re-use them, but you might need to modify the accounts to have the required permissions to install OKD clusters on them.
You can use the installer-provisioned infrastructure method to create appropriate machine instances on your hardware for OpenStack, OpenStack with Kuryr, vSphere, and bare metal. Additionally, for vSphere, you can also customize additional network parameters during installation.
For some installer-provisioned infrastructure installations, for example on the VMware vSphere and bare metal platforms, the external traffic that reaches the ingress virtual IP (VIP) is not balanced between the default IngressController
replicas. For vSphere and bare metal installer-provisioned infrastructure installations where exceeding the baseline IngressController
router performance is expected, you must configure an external load balancer. Configuring an external load balancer achieves the performance of multiple IngressController
replicas. For more information about the baseline IngressController
performance, see Baseline Ingress Controller (router) performance. For more information about configuring an external load balancer, see Configuring an external load balancer.
If you want to reuse extensive cloud infrastructure, you can complete a user-provisioned infrastructure installation. With these installations, you manually deploy the machines that your cluster requires during the installation process. If you perform a user-provisioned infrastructure installation on AWS, Azure, Azure Stack Hub, you can use the provided templates to help you stand up all of the required components. You can also reuse a shared VPC on GCP. Otherwise, you can use the provider-agnostic installation method to deploy a cluster into other clouds.
You can also complete a user-provisioned infrastructure installation on your existing hardware. If you use OpenStack, IBM Z® or IBM® LinuxONE, IBM Z® and IBM® LinuxONE with Fedora KVM, IBM Power, or vSphere, use the specific installation instructions to deploy your cluster. If you use other supported hardware, follow the bare metal installation procedure. For some of these platforms, such as OpenStack, vSphere, and bare metal, you can also customize additional network parameters during installation.
If you use a user-provisioned installation method, you can configure a proxy for your cluster. The instructions are included in each installation procedure.
If you want to prevent your cluster on a public cloud from exposing endpoints externally, you can deploy a private cluster with installer-provisioned infrastructure on AWS, Azure, or GCP.
If you need to install your cluster that has limited access to the internet, such as a disconnected or restricted network cluster, you can mirror the installation packages and install the cluster from them. Follow detailed instructions for user provisioned infrastructure installations into restricted networks for AWS, GCP, IBM Z® or IBM® LinuxONE, IBM Z® or IBM® LinuxONE with Fedora KVM, ../../installing/installing_ibm_power/installing-restricted-networks-ibm-power.html, vSphere, or bare metal. You can also install a cluster into a restricted network using installer-provisioned infrastructure by following detailed instructions for AWS, GCP, Nutanix, OpenStack, and vSphere.
If you need to deploy your cluster to an AWS GovCloud region, AWS China region, or Azure government region, you can configure those custom regions during an installer-provisioned infrastructure installation.
Some configuration is not required to install the cluster but recommended before your users access the cluster. You can customize the cluster itself by customizing the Operators that make up your cluster and integrate you cluster with other required systems, such as an identity provider.
For a production cluster, you must configure the following integrations:
Depending on your workload needs, you might need to take extra steps before you begin deploying applications. For example, after you prepare infrastructure to support your application build strategy, you might need to make provisions for low-latency workloads or to protect sensitive workloads. You can also configure monitoring for application workloads. If you plan to run Windows workloads, you must enable hybrid networking with OVN-Kubernetes during the installation process; hybrid networking cannot be enabled after your cluster is installed.
You can perform different types of installations on different platforms.
Not all installation options are supported for all platforms, as shown in the following tables. A checkmark indicates that the option is supported and links to the relevant section. |
Alibaba | AWS | Azure | Azure Stack Hub | GCP | Nutanix | OpenStack | Bare metal | vSphere | VMC | IBM Cloud® | IBM Z® | IBM Power® | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Default |
Custom |
||||||||||||
Network customization |
|||||||||||||
Restricted network |
|||||||||||||
Private clusters |
|||||||||||||
Existing virtual private networks |
|||||||||||||
Government regions |
|||||||||||||
Secret regions |
|||||||||||||
China regions |
Alibaba | AWS | Azure | Azure Stack Hub | GCP | Nutanix | OpenStack | Bare metal | vSphere | VMC | IBM Cloud® | IBM Z® | IBM Z® with Fedora KVM | IBM Power® | Platform agnostic | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Custom |
Network customization |
||||||||||||||
Restricted network |
|||||||||||||||
Shared VPC hosted outside of cluster project |