$ ./openshift-install create cluster --dir <installation_directory> \ (1)
--log-level=info (2)
In OKD version 4.17, you can install a cluster on Amazon Web Services (AWS) that uses the default configuration options.
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 AWS account to host the cluster.
If you have an AWS profile stored on your computer, it must not use a temporary session token that you generated while using a multi-factor authentication device. The cluster continues to use your current AWS credentials to create AWS resources for the entire life of the cluster, so you must use key-based, long-term credentials. To generate appropriate keys, see Managing Access Keys for IAM Users in the AWS documentation. You can supply the keys when you run the installation program. |
If you use a firewall, you configured it to allow the sites that your cluster requires access to.
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 verified that the cloud provider account on your host has the correct permissions to deploy the cluster. An account with incorrect permissions causes the installation process to fail with an error message that displays the missing permissions.
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
directory name to store the files that the installation program creates. |
2 | To view different installation details, specify warn , debug , or
error instead of info . |
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.
Provide values at the prompts:
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 aws as the platform to target.
If you do not have an Amazon Web Services (AWS) profile stored on your computer, enter the AWS access key ID and secret access key for the user that you configured to run the installation program.
The AWS access key ID and secret access key are stored in |
Select the AWS region to deploy the cluster to.
Select the base domain for the Route 53 service that you configured for your cluster.
Enter a descriptive name for your cluster.
Paste the pull secret from Red Hat OpenShift Cluster Manager.
If you do not have a pull secret from Red Hat OpenShift Cluster Manager, you can paste the pull secret another private registry.
If you do not need the cluster to pull images from a private registry, you can paste {"auths":{"fake":{"auth":"aWQ6cGFzcwo="}}}
as the pull secret.
Optional: Remove or disable the AdministratorAccess
policy from the IAM
account that you used to install the cluster.
The elevated permissions provided by the |
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
|
See Configuration and credential file settings in the AWS documentation for more information about AWS profile and credential configuration.
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
The kubeadmin
user exists by default after an OKD installation. You can log in to your cluster as the kubeadmin
user by using the OKD web console.
You have access to the installation host.
You completed a cluster installation and all cluster Operators are available.
Obtain the password for the kubeadmin
user from the kubeadmin-password
file on the installation host:
$ cat <installation_directory>/auth/kubeadmin-password
Alternatively, you can obtain the |
List the OKD web console route:
$ oc get routes -n openshift-console | grep 'console-openshift'
Alternatively, you can obtain the OKD route from the |
console console-openshift-console.apps.<cluster_name>.<base_domain> console https reencrypt/Redirect None
Navigate to the route detailed in the output of the preceding command in a web browser and log in as the kubeadmin
user.
See Accessing the web console for more details about accessing and understanding the OKD web console.
If necessary, you can opt out of remote health reporting.
If necessary, you can remove cloud provider credentials.