1. Documentation
×

Installation methods

You can install an OKD cluster on Nutanix by using a variety of different installation methods. Each method has qualities that can make the method more suitable for different use cases, such as installing a cluster in a disconnected environment or installing a cluster that requires minimal configuration and provisioning. Before you install OKD, ensure that your Nutanix environment meets specific requirements.

Nutanix version requirements

You must install the OKD cluster to a Nutanix environment that meets specific version requirements.

Table 1. Version requirements for Nutanix virtual environments
Component Required version

Nutanix AOS

6.5.2.7 or later

Prism Central

pc.2022.6 or later

Agent-based Installer

You can install an OKD cluster on Nutanix by using the Agent-based Installer. The Agent-based Installer can be used to install a three-node cluster, which is a smaller, more resource efficient cluster for testing, development, and production.

Additional resources

Environment requirements

Before you install an OKD cluster, verify that your infrastructure, account privileges, and network configuration meet the Nutanix AOS environment requirements needed for a successful installation.

Infrastructure requirements

You can install OKD on on-premise Nutanix clusters, Nutanix Cloud Clusters (NC2) on Amazon Web Services (AWS), or NC2 on Microsoft Azure.

Required account privileges

The installation program requires access to a Nutanix account with the necessary permissions to deploy the cluster and to maintain the daily operation of it. The following options are available to you:

  • You can use a local Prism Central user account with administrative privileges. Using a local account is the quickest way to grant access to an account with the required permissions.

  • If your organization’s security policies require that you use a more restrictive set of permissions, use the permissions that are listed in the following table to create a custom Cloud Native role in Prism Central. You can then assign the role to a user account that is a member of a Prism Central authentication directory.

Consider the following when managing this user account:

  • When assigning entities to the role, ensure that the user can access only the Prism Element and subnet that are required to deploy the virtual machines.

  • Ensure that the user is a member of the project to which it needs to assign virtual machines.

Table 2. Required permissions for creating a Custom Cloud Native role
Nutanix Object When required Required permissions in Nutanix API Description

Categories

Always

  • Create_Category_Mapping

  • Create_Or_Update_Name_Category

  • Create_Or_Update_Value_Category

  • Delete_Category_Mapping

  • Delete_Name_Category

  • Delete_Value_Category

  • View_Category_Mapping

  • View_Name_Category

  • View_Value_Category

Create, read, and delete categories that are assigned to the OKD machines.

Images

Always

  • Create_Image

  • Delete_Image

  • View_Image

Create, read, and delete the operating system images used for the OKD machines.

Virtual Machines

Always

  • Create_Virtual_Machine

  • Delete_Virtual_Machine

  • View_Virtual_Machine

Create, read, and delete the OKD machines.

Clusters

Always

View_Cluster

View the Prism Element clusters that host the OKD machines.

Subnets

Always

View_Subnet

View the subnets that host the OKD machines.

Projects

If you will associate a project with compute machines, control plane machines, or all machines.

View_Project

View the projects defined in Prism Central and allow a project to be assigned to the OKD machines.

Tasks

Always

View_Task

Fetch and view tasks on the Prism Element that contain OKD machines and nodes.

Hosts

If you use GPUs with compute machines.

View_Host

Fetch and view hosts on the Prism Element that have GPUs attached.

Cluster limits

Available resources vary between clusters. The number of possible clusters within a Nutanix environment is limited primarily by available storage space and any limitations associated with the resources that the cluster creates, and resources that you require to deploy the cluster, such a IP addresses and networks.

Cluster resources

A minimum of 800 GB of storage is required to use a standard cluster.

When you deploy a OKD cluster that uses installer-provisioned infrastructure, the installation program must be able to create several resources in your Nutanix instance. Although these resources use 856 GB of storage, the bootstrap node is destroyed as part of the installation process.

A standard OKD installation creates the following resources:

  • 1 label

  • Virtual machines:

    • 1 disk image

    • 1 temporary bootstrap node

    • 3 control plane nodes

    • 3 compute machines

Networking requirements

You must use either AHV IP Address Management (IPAM) or Dynamic Host Configuration Protocol (DHCP) for the network and ensure that it is configured to provide persistent IP addresses to the cluster machines. Additionally, create the following networking resources before you install the OKD cluster:

  • IP addresses

  • DNS records

Nutanix Flow Virtual Networking is supported for new cluster installations. To use this feature, enable Flow Virtual Networking on your AHV cluster before installing.

It is recommended that each OKD node in the cluster have access to a Network Time Protocol (NTP) server that is discoverable via DHCP. Installation is possible without an NTP server. However, an NTP server prevents errors typically associated with asynchronous server clocks.

Required IP Addresses

An installer-provisioned installation requires two static virtual IP (VIP) addresses:

  • A VIP address for the API is required. This address is used to access the cluster API.

  • A VIP address for ingress is required. This address is used for cluster ingress traffic.

You specify these IP addresses when you install the OKD cluster.

DNS records

You must create DNS records for two static IP addresses in the appropriate DNS server for the Nutanix instance that hosts your OKD cluster. In each record, <cluster_name> is the cluster name and <base_domain> is the cluster base domain that you specify when you install the cluster.

If you use your own DNS or DHCP server, you must also create records for each node, including the bootstrap, control plane, and compute nodes.

A complete DNS record takes the form: <component>.<cluster_name>.<base_domain>..

Table 3. Required DNS records
Component Record Description

API VIP

api.<cluster_name>.<base_domain>.

This DNS A/AAAA or CNAME record must point to the load balancer for the control plane machines. This record must be resolvable by both clients external to the cluster and from all the nodes within the cluster.

Ingress VIP

*.apps.<cluster_name>.<base_domain>.

A wildcard DNS A/AAAA or CNAME record that points to the load balancer that targets the machines that run the Ingress router pods, which are the worker nodes by default. This record must be resolvable by both clients external to the cluster and from all the nodes within the cluster.

Additional resources

Configuring the Cloud Credential Operator utility

The Cloud Credential Operator (CCO) manages cloud provider credentials as Kubernetes custom resource definitions (CRDs). To install a cluster on Nutanix, you must set the CCO to manual mode as part of the installation process.

To create and manage cloud credentials from outside of the cluster when the Cloud Credential Operator (CCO) is operating in manual mode, extract and prepare the CCO utility (ccoctl) binary.

The ccoctl utility is a Linux binary that must run in a Linux environment.
Prerequisites

  • You have access to an OKD account with cluster administrator access.

  • You have installed the OpenShift CLI (oc).

Procedure

  1. Set a variable for the OKD release image by running the following command:

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')

  2. Obtain the CCO container image from the OKD release image by running the following command:

    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)

    Ensure that the architecture of the $RELEASE_IMAGE matches the architecture of the environment in which you will use the ccoctl tool.

  3. Extract the ccoctl binary from the CCO container image within the OKD release image by running the following command:

    $ oc image extract $CCO_IMAGE \
  --file="/usr/bin/ccoctl.<rhel_version>" \
  -a ~/.pull-secret

    For <rhel_version>, specify the value that corresponds to the version of Fedora that the host uses. If no value is specified, ccoctl.rhel8 is used by default. The following values are valid:

    • rhel8: Specify this value for hosts that use Fedora 8.

    • rhel9: Specify this value for hosts that use Fedora 9.

    The ccoctl binary is created in the directory from where you executed the command and not in /usr/bin/. You must rename the directory or move the ccoctl.<rhel_version> binary to ccoctl.

  4. Change the permissions to make ccoctl executable by running the following command:

    $ chmod 775 ccoctl
Verification

  • To verify that ccoctl is ready to use, display the help file. Use a relative file name when you run the command, for example:

    $ ./ccoctl
    Example output
    OpenShift credentials provisioning tool

Usage:
  ccoctl [command]

Available Commands:
  aws          Manage credentials objects for AWS cloud
  azure        Manage credentials objects for Azure
  gcp          Manage credentials objects for Google cloud
  help         Help about any command
  ibmcloud     Manage credentials objects for IBM Cloud
  nutanix      Manage credentials objects for Nutanix

Flags:
  -h, --help   help for ccoctl

Use "ccoctl [command] --help" for more information about a command.
Additional resources