$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> (1)
In OKD version 4, you can install a customized
cluster on infrastructure that the installation program provisions on
Microsoft Azure. To customize the installation, you modify
parameters in the install-config.yaml
file before you install the cluster.
You reviewed details about the OKD installation and update processes.
You read the documentation on selecting a cluster installation method and preparing it for users.
You configured an Azure account to host the cluster and determined the tested and validated region to deploy the cluster to.
If you use a firewall, you configured it to allow the sites that your cluster requires access to.
If the cloud identity and access management (IAM) APIs are not accessible in your environment, or if you do not want to store an administrator-level credential secret in the kube-system
namespace, you can manually create and maintain IAM credentials.
If you use customer-managed encryption keys, you prepared your Azure environment for encryption.
During an OKD installation, you can provide an SSH public key to the installation program. The key is passed to the Fedora CoreOS (FCOS) nodes through their Ignition config files and is used to authenticate SSH access to the nodes. The key is added to the ~/.ssh/authorized_keys
list for the core
user on each node, which enables password-less authentication.
After the key is passed to the nodes, you can use the key pair to SSH in to the FCOS nodes as the user core
. To access the nodes through SSH, the private key identity must be managed by SSH for your local user.
If you want to SSH in to your cluster nodes to perform installation debugging or disaster recovery, you must provide the SSH public key during the installation process. The ./openshift-install gather
command also requires the SSH public key to be in place on the cluster nodes.
Do not skip this procedure in production environments, where disaster recovery and debugging is required. |
You must use a local key, not one that you configured with platform-specific approaches such as AWS key pairs. |
On clusters running Fedora CoreOS (FCOS), the SSH keys specified in the Ignition config files are written to the |
If you do not have an existing SSH key pair on your local machine to use for authentication onto your cluster nodes, create one. For example, on a computer that uses a Linux operating system, run the following command:
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> (1)
1 | Specify the path and file name, such as ~/.ssh/id_ed25519 , of the new SSH key. If you have an existing key pair, ensure your public key is in the your ~/.ssh directory. |
If you plan to install an OKD cluster that uses FIPS Validated / Modules in Process cryptographic libraries on the |
View the public SSH key:
$ cat <path>/<file_name>.pub
For example, run the following to view the ~/.ssh/id_ed25519.pub
public key:
$ cat ~/.ssh/id_ed25519.pub
Add the SSH private key identity to the SSH agent for your local user, if it has not already been added. SSH agent management of the key is required for password-less SSH authentication onto your cluster nodes, or if you want to use the ./openshift-install gather
command.
On some distributions, default SSH private key identities such as |
If the ssh-agent
process is not already running for your local user, start it as a background task:
$ eval "$(ssh-agent -s)"
Agent pid 31874
If your cluster is in FIPS mode, only use FIPS-compliant algorithms to generate the SSH key. The key must be either RSA or ECDSA. |
Add your SSH private key to the ssh-agent
:
$ ssh-add <path>/<file_name> (1)
1 | Specify the path and file name for your SSH private key, such as ~/.ssh/id_ed25519 |
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
When you install OKD, provide the SSH public key to the installation program.
If you are deploying an OKD cluster using the Azure Marketplace offering, you must first obtain the Azure Marketplace image. The installation program uses this image to deploy worker nodes. When obtaining your image, consider the following:
While the images are the same, the Azure Marketplace publisher is different depending on your region. If you are located in North America, specify redhat
as the publisher. If you are located in EMEA, specify redhat-limited
as the publisher.
The offer includes a rh-ocp-worker
SKU and a rh-ocp-worker-gen1
SKU. The rh-ocp-worker
SKU represents a Hyper-V generation version 2 VM image. The default instance types used in OKD are version 2 compatible. If you plan to use an instance type that is only version 1 compatible, use the image associated with the rh-ocp-worker-gen1
SKU. The rh-ocp-worker-gen1
SKU represents a Hyper-V version 1 VM image.
Installing images with the Azure marketplace is not supported on clusters with 64-bit ARM instances. |
You have installed the Azure CLI client (az)
.
Your Azure account is entitled for the offer and you have logged into this account with the Azure CLI client.
Display all of the available OKD images by running one of the following commands:
North America:
$ az vm image list --all --offer rh-ocp-worker --publisher redhat -o table
Offer Publisher Sku Urn Version
------------- -------------- ------------------ -------------------------------------------------------------- --------------
rh-ocp-worker RedHat rh-ocp-worker RedHat:rh-ocp-worker:rh-ocpworker:4.8.2021122100 4.8.2021122100
rh-ocp-worker RedHat rh-ocp-worker-gen1 RedHat:rh-ocp-worker:rh-ocp-worker-gen1:4.8.2021122100 4.8.2021122100
EMEA:
$ az vm image list --all --offer rh-ocp-worker --publisher redhat-limited -o table
Offer Publisher Sku Urn Version
------------- -------------- ------------------ -------------------------------------------------------------- --------------
rh-ocp-worker redhat-limited rh-ocp-worker redhat-limited:rh-ocp-worker:rh-ocp-worker:4.8.2021122100 4.8.2021122100
rh-ocp-worker redhat-limited rh-ocp-worker-gen1 redhat-limited:rh-ocp-worker:rh-ocp-worker-gen1:4.8.2021122100 4.8.2021122100
Regardless of the version of OKD that you install, the correct version of the Azure Marketplace image to use is 4.8. If required, your VMs are automatically upgraded as part of the installation process. |
Inspect the image for your offer by running one of the following commands:
North America:
$ az vm image show --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>
EMEA:
$ az vm image show --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>
Review the terms of the offer by running one of the following commands:
North America:
$ az vm image terms show --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>
EMEA:
$ az vm image terms show --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>
Accept the terms of the offering by running one of the following commands:
North America:
$ az vm image terms accept --urn redhat:rh-ocp-worker:rh-ocp-worker:<version>
EMEA:
$ az vm image terms accept --urn redhat-limited:rh-ocp-worker:rh-ocp-worker:<version>
Record the image details of your offer. You must update the compute
section in the install-config.yaml
file with values for publisher
, offer
, sku
, and version
before deploying the cluster.
install-config.yaml
file with the Azure Marketplace worker nodesapiVersion: v1
baseDomain: example.com
compute:
- hyperthreading: Enabled
name: worker
platform:
azure:
type: Standard_D4s_v5
osImage:
publisher: redhat
offer: rh-ocp-worker
sku: rh-ocp-worker
version: 4.8.2021122100
replicas: 3
Before you install OKD, download the installation file on the host you are using for installation.
You have a computer that runs Linux or macOS, with 500 MB of local disk space.
Download installer from https://github.com/openshift/okd/releases
The installation program creates several files on the computer that you use to install your cluster. You must keep the installation program and the files that the installation program creates after you finish installing the cluster. Both files are required to delete the cluster. |
Deleting the files created by the installation program does not remove your cluster, even if the cluster failed during installation. To remove your cluster, complete the OKD uninstallation procedures for your specific cloud provider. |
Extract the installation program. For example, on a computer that uses a Linux operating system, run the following command:
$ tar -xvf openshift-install-linux.tar.gz
Download your installation pull secret from the Red Hat OpenShift Cluster Manager. This pull secret allows you to authenticate with the services that are provided by the included authorities, including Quay.io, which serves the container images for OKD components.
Using a pull secret from the Red Hat OpenShift Cluster Manager is not required. You can use a pull secret for another private registry. Or, if you do not need the cluster to pull images from a private registry, you can use {"auths":{"fake":{"auth":"aWQ6cGFzcwo="}}}
as the pull secret when prompted during the installation.
If you do not use the pull secret from the Red Hat OpenShift Cluster Manager:
Red Hat Operators are not available.
The Telemetry and Insights operators do not send data to Red Hat.
Content from the Red Hat Ecosystem Catalog Container images registry, such as image streams and Operators, are not available.
In OKD, you can use the tags for grouping resources and for managing resource access and cost. You can define the tags on the Azure resources in the install-config.yaml
file only during OKD cluster creation. You cannot modify the user-defined tags after cluster creation.
Support for user-defined tags is available only for the resources created in the Azure Public Cloud. User-defined tags are not supported for the OKD clusters upgraded to OKD 4.14.
User-defined and OKD specific tags are applied only to the resources created by the OKD installer and its core operators such as Machine api provider azure Operator, Cluster Ingress Operator, Cluster Image Registry Operator.
By default, OKD installer attaches the OKD tags to the Azure resources. These OKD tags are not accessible for the users.
You can use the .platform.azure.userTags
field in the install-config.yaml
file to define the list of user-defined tags as shown in the following install-config.yaml
file.
install-config.yaml
fileadditionalTrustBundlePolicy: Proxyonly (1)
apiVersion: v1
baseDomain: catchall.azure.devcluster.openshift.com (2)
compute: (3)
- architecture: amd64
hyperthreading: Enabled (4)
name: worker
platform: {}
replicas: 3
controlPlane: (5)
architecture: amd64
hyperthreading: Enabled (6)
name: master
platform: {}
replicas: 3
metadata:
creationTimestamp: null
name: user (7)
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
networkType: OVNKubernetes (8)
serviceNetwork:
- 172.30.0.0/16
platform:
azure:
baseDomainResourceGroupName: os4-common (9)
cloudName: AzurePublicCloud (10)
outboundType: Loadbalancer
region: southindia (11)
userTags: (12)
createdBy: user
environment: dev
1 | Defines the trust bundle policy. |
2 | Required. The baseDomain parameter specifies the base domain of your cloud provider. The installation program prompts you for this value. |
3 | The configuration for the machines that comprise compute. The compute section is a sequence of mappings. To meet the requirements of the different data structures, the first line of the compute section must begin with a hyphen, - . If you do not provide these parameters and values, the installation program provides the default value. |
4 | To enable or disable simultaneous multithreading, or hyperthreading . By default, simultaneous multithreading is enabled to increase the performance of your machines' cores. You can disable it by setting the parameter value to Disabled . If you disable simultaneous multithreading in some cluster machines, you must disable it in all cluster machines. |
5 | The configuration for the machines that comprise the control plane. The controlPlane section is a single mapping. The first line of the controlPlane section must not begin with a hyphen, - . You can use only one control plane pool. If you do not provide these parameters and values, the installation program provides the default value. |
6 | To enable or disable simultaneous multithreading, or hyperthreading . By default, simultaneous multithreading is enabled to increase the performance of your machines' cores. You can disable it by setting the parameter value to Disabled . If you disable simultaneous multithreading in some cluster machines, you must disable it in all cluster machines. |
7 | The installation program prompts you for this value. |
8 | The cluster network plugin to install. The supported values are OVNKubernetes and OpenShiftSDN . The default value is OVNKubernetes . |
9 | Specifies the resource group for the base domain of the Azure DNS zone. |
10 | Specifies the name of the Azure cloud environment. You can use the cloudName field to configure the Azure SDK with the Azure API endpoints. If you do not provide value, the default value is Azure Public Cloud. |
11 | Required. Specifies the name of the Azure region that hosts your cluster. The installation program prompts you for this value. |
12 | Defines the additional keys and values that the installation program adds as tags to all Azure resources that it creates. |
The user-defined tags have the following limitations:
A tag key can have a maximum of 128 characters.
A tag key must begin with a letter, end with a letter, number or underscore, and can contain only letters, numbers, underscores, periods, and hyphens.
Tag keys are case-insensitive.
Tag keys cannot be name
. It cannot have prefixes such as kubernetes.io
, openshift.io
, microsoft
, azure
, and windows
.
A tag value can have a maximum of 256 characters.
You can configure a maximum of 10 tags for resource group and resources.
For more information about Azure tags, see Azure user-defined tags
After creating the OKD cluster, you can access the list of defined tags for the Azure resources. The format of the OKD tags is kubernetes.io_cluster.<cluster_id>:owned
. The cluster_id
parameter is the value of .status.infrastructureName
present in config.openshift.io/Infrastructure
.
Query the tags defined for Azure resources by running the following command:
$ oc get infrastructures.config.openshift.io cluster -o=jsonpath-as-json='{.status.platformStatus.azure.resourceTags}'
[
[
{
"key": "createdBy",
"value": "user"
},
{
"key": "environment",
"value": "dev"
}
]
]
You can customize the OKD cluster you install on Microsoft Azure.
You have the OKD installation program and the pull secret for your cluster.
You have an Azure subscription ID and tenant ID.
If you are installing the cluster using a service principal, you have its application ID and password.
If you are installing the cluster using a system-assigned managed identity, you have enabled it on the virtual machine that you will run the installation program from.
If you are installing the cluster using a user-assigned managed identity, you have met these prerequisites:
You have its client ID.
You have assigned it to the virtual machine that you will run the installation program from.
Optional: If you have run the installation program on this computer before, and want to use an alternative service principal or managed identity, go to the ~/.azure/
directory and delete the osServicePrincipal.json
configuration file.
Deleting this file prevents the installation program from automatically reusing subscription and authentication values from a previous installation.
Create the install-config.yaml
file.
Change to the directory that contains the installation program and run the following command:
$ ./openshift-install create install-config --dir <installation_directory> (1)
1 | For <installation_directory> , specify the directory name to store the
files that the installation program creates. |
When specifying the directory:
Verify that the directory has the execute
permission. This permission is required to run Terraform binaries under the installation directory.
Use an empty directory. Some installation assets, such as bootstrap X.509 certificates, have short expiration intervals, therefore you must not reuse an installation directory. If you want to reuse individual files from another cluster installation, you can copy them into your directory. However, the file names for the installation assets might change between releases. Use caution when copying installation files from an earlier OKD version.
At the prompts, provide the configuration details for your cloud:
Optional: Select an SSH key to use to access your cluster machines.
For production OKD clusters on which you want to perform installation debugging or disaster recovery, specify an SSH key that your |
Select azure as the platform to target.
If the installation program cannot locate the osServicePrincipal.json
configuration file from a previous installation, you are prompted for Azure subscription and authentication values.
Enter the following Azure parameter values for your subscription:
azure subscription id: Enter the subscription ID to use for the cluster.
azure tenant id: Enter the tenant ID.
Depending on the Azure identity you are using to deploy the cluster, do one of the following when prompted for the azure service principal client id:
If you are using a service principal, enter its application ID.
If you are using a system-assigned managed identity, leave this value blank.
If you are using a user-assigned managed identity, specify its client ID.
Depending on the Azure identity you are using to deploy the cluster, do one of the following when prompted for the azure service principal client secret:
If you are using a service principal, enter its password.
If you are using a system-assigned managed identity, leave this value blank.
If you are using a user-assigned managed identity, leave this value blank.
Select the region to deploy the cluster to.
Select the base domain to deploy the cluster to. The base domain corresponds to the Azure DNS Zone that you created for your cluster.
Enter a descriptive name for your cluster.
All Azure resources that are available through public endpoints are subject to resource name restrictions, and you cannot create resources that use certain terms. For a list of terms that Azure restricts, see Resolve reserved resource name errors in the Azure documentation. |
Modify the install-config.yaml
file. You can find more information about
the available parameters in the "Installation configuration parameters" section.
If you are installing a three-node cluster, be sure to set the |
Back up the install-config.yaml
file so that you can use
it to install multiple clusters.
The |
If previously not detected, the installation program creates an osServicePrincipal.json
configuration file and stores this file in the ~/.azure/
directory on your computer. This ensures that the installation program can load the profile when it is creating an OKD cluster on the target platform.
Each cluster machine must meet the following minimum requirements:
Machine | Operating System | vCPU [1] | Virtual RAM | Storage | Input/Output Per Second (IOPS)[2] |
---|---|---|---|---|---|
Bootstrap |
FCOS |
4 |
16 GB |
100 GB |
300 |
Control plane |
FCOS |
4 |
16 GB |
100 GB |
300 |
Compute |
FCOS |
2 |
8 GB |
100 GB |
300 |
One vCPU is equivalent to one physical core when simultaneous multithreading (SMT), or hyperthreading, is not enabled. When enabled, use the following formula to calculate the corresponding ratio: (threads per core × cores) × sockets = vCPUs.
OKD and Kubernetes are sensitive to disk performance, and faster storage is recommended, particularly for etcd on the control plane nodes which require a 10 ms p99 fsync duration. Note that on many cloud platforms, storage size and IOPS scale together, so you might need to over-allocate storage volume to obtain sufficient performance.
As with all user-provisioned installations, if you choose to use Fedora compute machines in your cluster, you take responsibility for all operating system life cycle management and maintenance, including performing system updates, applying patches, and completing all other required tasks. Use of Fedora 7 compute machines is deprecated and has been removed in OKD 4.10 and later.
You are required to use Azure virtual machines that have the |
If an instance type for your platform meets the minimum requirements for cluster machines, it is supported to use in OKD.
The following Microsoft Azure instance types have been tested with OKD.
standardBSFamily
standardDADSv5Family
standardDASv4Family
standardDASv5Family
standardDCSv3Family
standardDCSv2Family
standardDDCSv3Family
standardDDSv4Family
standardDDSv5Family
standardDLDSv5Family
standardDLSv5Family
standardDSFamily
standardDSv2Family
standardDSv2PromoFamily
standardDSv3Family
standardDSv4Family
standardDSv5Family
standardEADSv5Family
standardEASv4Family
standardEASv5Family
standardEBDSv5Family
standardEBSv5Family
standardEDSv4Family
standardEDSv5Family
standardEIADSv5Family
standardEIASv4Family
standardEIASv5Family
standardEIDSv5Family
standardEISv3Family
standardEISv5Family
standardESv3Family
standardESv4Family
standardESv5Family
standardFXMDVSFamily
standardFSFamily
standardFSv2Family
standardGSFamily
standardHBrsv2Family
standardHBSFamily
standardHCSFamily
standardLASv3Family
standardLSFamily
standardLSv2Family
standardLSv3Family
standardMDSMediumMemoryv2Family
standardMIDSMediumMemoryv2Family
standardMISMediumMemoryv2Family
standardMSFamily
standardMSMediumMemoryv2Family
StandardNCADSA100v4Family
Standard NCASv3_T4 Family
standardNCSv2Family
standardNCSv3Family
standardNDSv2Family
standardNPSFamily
StandardNVADSA10v5Family
standardNVSv3Family
standardXEISv4Family
The following Microsoft Azure ARM64 instance types have been tested with OKD.
standardDPSv5Family
standardDPDSv5Family
standardDPLDSv5Family
standardDPLSv5Family
standardEPSv5Family
standardEPDSv5Family
You can customize the install-config.yaml
file to specify more details about your OKD cluster’s platform or modify the values of the required parameters.
This sample YAML file is provided for reference only. You must obtain your |
apiVersion: v1
baseDomain: example.com (1)
controlPlane: (2)
hyperthreading: Enabled (3) (4)
name: master
platform:
azure:
encryptionAtHost: true
ultraSSDCapability: Enabled
osDisk:
diskSizeGB: 1024 (5)
diskType: Premium_LRS
diskEncryptionSet:
resourceGroup: disk_encryption_set_resource_group
name: disk_encryption_set_name
subscriptionId: secondary_subscription_id
type: Standard_D8s_v3
replicas: 3
compute: (2)
- hyperthreading: Enabled (3)
name: worker
platform:
azure:
ultraSSDCapability: Enabled
type: Standard_D2s_v3
encryptionAtHost: true
osDisk:
diskSizeGB: 512 (5)
diskType: Standard_LRS
diskEncryptionSet:
resourceGroup: disk_encryption_set_resource_group
name: disk_encryption_set_name
subscriptionId: secondary_subscription_id
zones: (6)
- "1"
- "2"
- "3"
replicas: 5
metadata:
name: test-cluster (1)
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
networkType: OVNKubernetes (7)
serviceNetwork:
- 172.30.0.0/16
platform:
azure:
defaultMachinePlatform:
ultraSSDCapability: Enabled
baseDomainResourceGroupName: resource_group (8)
region: centralus (1)
resourceGroupName: existing_resource_group (9)
outboundType: Loadbalancer
cloudName: AzurePublicCloud
pullSecret: '{"auths": ...}' (1)
sshKey: ssh-ed25519 AAAA... (10)
1 | Required. The installation program prompts you for this value. | ||
2 | If you do not provide these parameters and values, the installation program provides the default value. | ||
3 | The controlPlane section is a single mapping, but the compute section is a sequence of mappings. To meet the requirements of the different data structures, the first line of the compute section must begin with a hyphen, - , and the first line of the controlPlane section must not. Only one control plane pool is used. |
||
4 | Whether to enable or disable simultaneous multithreading, or hyperthreading . By default, simultaneous multithreading is enabled to increase the performance of your machines' cores. You can disable it by setting the parameter value to Disabled . If you disable simultaneous multithreading in some cluster machines, you must disable it in all cluster machines.
|
||
5 | You can specify the size of the disk to use in GB. Minimum recommendation for control plane nodes is 1024 GB. | ||
6 | Specify a list of zones to deploy your machines to. For high availability, specify at least two zones. | ||
7 | The cluster network plugin to install. The supported values are OVNKubernetes and OpenShiftSDN . The default value is OVNKubernetes . |
||
8 | Specify the name of the resource group that contains the DNS zone for your base domain. | ||
9 | Specify the name of an already existing resource group to install your cluster to. If undefined, a new resource group is created for the cluster. | ||
10 | You can optionally provide the sshKey value that you use to access the machines in your cluster.
|
Production environments can deny direct access to the internet and instead have
an HTTP or HTTPS proxy available. You can configure a new OKD
cluster to use a proxy by configuring the proxy settings in the
install-config.yaml
file.
You have an existing install-config.yaml
file.
You reviewed the sites that your cluster requires access to and determined whether any of them need to bypass the proxy. By default, all cluster egress traffic is proxied, including calls to hosting cloud provider APIs. You added sites to the Proxy
object’s spec.noProxy
field to bypass the proxy if necessary.
The For installations on Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and OpenStack, the |
Edit your install-config.yaml
file and add the proxy settings. For example:
apiVersion: v1
baseDomain: my.domain.com
proxy:
httpProxy: http://<username>:<pswd>@<ip>:<port> (1)
httpsProxy: https://<username>:<pswd>@<ip>:<port> (2)
noProxy: example.com (3)
additionalTrustBundle: | (4)
-----BEGIN CERTIFICATE-----
<MY_TRUSTED_CA_CERT>
-----END CERTIFICATE-----
additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> (5)
1 | A proxy URL to use for creating HTTP connections outside the cluster. The
URL scheme must be http . |
2 | A proxy URL to use for creating HTTPS connections outside the cluster. |
3 | A comma-separated list of destination domain names, IP addresses, or other network CIDRs to exclude from proxying. Preface a domain with . to match subdomains only. For example, .y.com matches x.y.com , but not y.com . Use * to bypass the proxy for all destinations. |
4 | If provided, the installation program generates a config map that is named user-ca-bundle in
the openshift-config namespace to hold the additional CA
certificates. If you provide additionalTrustBundle and at least one proxy setting, the Proxy object is configured to reference the user-ca-bundle config map in the trustedCA field. The Cluster Network
Operator then creates a trusted-ca-bundle config map that merges the contents specified for the trustedCA parameter
with the FCOS trust bundle. The additionalTrustBundle field is required unless
the proxy’s identity certificate is signed by an authority from the FCOS trust
bundle. |
5 | Optional: The policy to determine the configuration of the Proxy object to reference the user-ca-bundle config map in the trustedCA field. The allowed values are Proxyonly and Always . Use Proxyonly to reference the user-ca-bundle config map only when http/https proxy is configured. Use Always to always reference the user-ca-bundle config map. The default value is Proxyonly . |
The installation program does not support the proxy |
If the installer times out, restart and then complete the deployment by using the
|
Save the file and reference it when installing OKD.
The installation program creates a cluster-wide proxy that is named cluster
that uses the proxy
settings in the provided install-config.yaml
file. If no proxy settings are
provided, a cluster
Proxy
object is still created, but it will have a nil
spec
.
Only the |
For more details about Accelerated Networking, see Accelerated Networking for Microsoft Azure VMs.
You can install OKD on a compatible cloud platform.
You can run the |
You have configured an account with the cloud platform that hosts your cluster.
You have the OKD installation program and the pull secret for your cluster.
You have an Azure subscription ID and tenant ID.
Change to the directory that contains the installation program and initialize the cluster deployment:
$ ./openshift-install create cluster --dir <installation_directory> \ (1)
--log-level=info (2)
1 | For <installation_directory> , specify the
location of your customized ./install-config.yaml file. |
2 | To view different installation details, specify warn , debug , or
error instead of info . |
When the cluster deployment completes successfully:
The terminal displays directions for accessing your cluster, including a link to the web console and credentials for the kubeadmin
user.
Credential information also outputs to <installation_directory>/.openshift_install.log
.
Do not delete the installation program or the files that the installation program creates. Both are required to delete the cluster. |
...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s
|
You can install the OpenShift CLI (oc
) to interact with
OKD
from a command-line interface. You can install oc
on Linux, Windows, or macOS.
If you installed an earlier version of |
You can install the OpenShift CLI (oc
) binary on Linux by using the following procedure.
Navigate to https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/ and choose the folder for your operating system and architecture.
Download oc.tar.gz
.
Unpack the archive:
$ tar xvf <file>
Place the oc
binary in a directory that is on your PATH
.
To check your PATH
, execute the following command:
$ echo $PATH
After you install the OpenShift CLI, it is available using the oc
command:
$ oc <command>
You can install the OpenShift CLI (oc
) binary on Windows by using the following procedure.
Navigate to https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/ and choose the folder for your operating system and architecture.
Download oc.zip
.
Unzip the archive with a ZIP program.
Move the oc
binary to a directory that is on your PATH
.
To check your PATH
, open the command prompt and execute the following command:
C:\> path
After you install the OpenShift CLI, it is available using the oc
command:
C:\> oc <command>
You can install the OpenShift CLI (oc
) binary on macOS by using the following procedure.
Navigate to https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/ and choose the folder for your operating system and architecture.
Download oc.tar.gz
.
Unpack and unzip the archive.
Move the oc
binary to a directory on your PATH.
To check your PATH
, open a terminal and execute the following command:
$ echo $PATH
After you install the OpenShift CLI, it is available using the oc
command:
$ oc <command>
You can log in to your cluster as a default system user by exporting the cluster kubeconfig
file.
The kubeconfig
file contains information about the cluster that is used by the CLI to connect a client to the correct cluster and API server.
The file is specific to a cluster and is created during OKD installation.
You deployed an OKD cluster.
You installed the oc
CLI.
Export the kubeadmin
credentials:
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig (1)
1 | For <installation_directory> , specify the path to the directory that you stored
the installation files in. |
Verify you can run oc
commands successfully using the exported configuration:
$ oc whoami
system:admin
See Accessing the web console for more details about accessing and understanding the OKD web console.
See About remote health monitoring for more information about the Telemetry service
If necessary, you can opt out of remote health reporting.