$ openstack role add --user <user> --project <project> swiftoperatorIn OKD 4, you can install a cluster on OpenStack in a restricted network by creating an internal mirror of the installation release content.
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 verified that OKD 4 is compatible with your OpenStack version by using the Supported platforms for OpenShift clusters section. You can also compare platform support across different versions by viewing the OKD on OpenStack support matrix.
You created a registry on your mirror host and obtained the imageContentSources data for your version of OKD.
|
Because the installation media is on the mirror host, you can use that computer to complete all installation steps. |
You have the metadata service enabled in OpenStack.
In OKD 4, you can perform an installation that does not require an active connection to the internet to obtain software components. Restricted network installations can be completed using installer-provisioned infrastructure or user-provisioned infrastructure, depending on the cloud platform to which you are installing the cluster.
If you choose to perform a restricted network installation on a cloud platform, you still require access to its cloud APIs. Some cloud functions, like Amazon Web Service’s IAM service, require internet access, so you might still require internet access. Depending on your network, you might require less internet access for an installation on bare metal hardware or on VMware vSphere.
To complete a restricted network installation, you must create a registry that mirrors the contents of the OKD registry and contains the installation media. You can create this registry on a mirror host, which can access both the internet and your closed network, or by using other methods that meet your restrictions.
Clusters in restricted networks have the following additional limitations and restrictions:
The ClusterVersion status includes an Unable to retrieve available updates
error.
By default, you cannot use the contents of the Developer Catalog because you cannot access the required image stream tags.
To support an OKD installation, your OpenStack quota must meet the following requirements:
| Resource | Value |
|---|---|
Floating IP addresses |
3 |
Ports |
15 |
Routers |
1 |
Subnets |
1 |
RAM |
112 GB |
vCPUs |
28 |
Volume storage |
275 GB |
Instances |
7 |
Security groups |
3 |
Security group rules |
60 |
Server groups |
2 - plus 1 for each additional availability zone in each machine pool |
A cluster might function with fewer than recommended resources, but its performance is not guaranteed.
|
If OpenStack object storage (Swift) is available and operated by a user account with the |
By default, your security group and security group rule quotas might be low. If you encounter problems, run openstack quota set --secgroups 3 --secgroup-rules 60 <project> as an administrator to increase them.
|
An OKD deployment comprises control plane machines, compute machines, and a bootstrap machine.
By default, the OKD installation process stands up three control plane and three compute machines.
Each machine requires:
An instance from the OpenStack quota
A port from the OpenStack quota
A flavor with at least 16 GB memory, 4 vCPUs, and 100 GB storage space
|
Compute machines host the applications that you run on OKD; aim to run as many as you can. |
During installation, a bootstrap machine is temporarily provisioned to stand up the control plane. After the production control plane is ready, the bootstrap machine is deprovisioned.
The bootstrap machine requires:
An instance from the OpenStack quota
A port from the OpenStack quota
A flavor with at least 16 GB memory, 4 vCPUs, and 100 GB storage space
Swift is operated by a user account with the swiftoperator role. Add the role to an account before you run the installation program.
|
If the OpenStack object storage service, commonly known as Swift, is available, OKD uses it as the image registry storage. If it is unavailable, the installation program relies on the OpenStack block storage service, commonly known as Cinder. If Swift is present and you want to use it, you must enable access to it. If it is not present, or if you do not want to use it, skip this section. |
You have a OpenStack administrator account on the target environment.
The Swift service is installed.
On Ceph RGW, the account in url option is enabled.
To enable Swift on OpenStack:
As an administrator in the OpenStack CLI, add the swiftoperator role to the account that will access Swift:
$ openstack role add --user <user> --project <project> swiftoperatorYour OpenStack deployment can now use Swift for the image registry.
The OKD installation program relies on a file that is called clouds.yaml. The file describes OpenStack configuration parameters, including the project name, log in information, and authorization service URLs.
Create the clouds.yaml file:
If your OpenStack distribution includes the Horizon web UI, generate a clouds.yaml file in it.
|
Remember to add a password to the |
If your OpenStack distribution does not include the Horizon web UI, or you do not want to use Horizon, create the file yourself. For detailed information about clouds.yaml, see Config files in the OpenStack documentation.
clouds:
shiftstack:
auth:
auth_url: http://10.10.14.42:5000/v3
project_name: shiftstack
username: shiftstack_user
password: XXX
user_domain_name: Default
project_domain_name: Default
dev-env:
region_name: RegionOne
auth:
username: 'devuser'
password: XXX
project_name: 'devonly'
auth_url: 'https://10.10.14.22:5001/v2.0'If your OpenStack installation uses self-signed certificate authority (CA) certificates for endpoint authentication:
Copy the certificate authority file to your machine.
Add the cacerts key to the clouds.yaml file. The value must be an absolute, non-root-accessible path to the CA certificate:
clouds:
shiftstack:
...
cacert: "/etc/pki/ca-trust/source/anchors/ca.crt.pem"|
After you run the installer with a custom CA certificate, you can update the certificate by editing the value of the |
Place the clouds.yaml file in one of the following locations:
The value of the OS_CLIENT_CONFIG_FILE environment variable
The current directory
A Unix-specific user configuration directory, for example ~/.config/openstack/clouds.yaml
A Unix-specific site configuration directory, for example /etc/openstack/clouds.yaml
The installation program searches for clouds.yaml in that order.
Optionally, you can edit the cloud provider configuration for your cluster. The cloud provider configuration controls how OKD interacts with OpenStack.
For a complete list of cloud provider configuration parameters, see the cloud.conf specification.
If you have not already generated manifest files for your cluster, generate them by running the following command:
$ openshift-install --dir <destination_directory> create manifestsIn a text editor, open the cloud-provider configuration manifest file. For example:
$ vi openshift/manifests/cloud-provider-config.yamlModify the options based on the cloud.conf specification.
Configuring Octavia for load balancing is a common case. For example:
#...
[LoadBalancer]
use-octavia=true (1)
lb-provider = "amphora" (2)
floating-network-id="d3deb660-4190-40a3-91f1-37326fe6ec4a"(3)
#...| 1 | This property enables Octavia integration. |
| 2 | This property sets the Octavia provider that your load balancer uses. It accepts "ovn" or "amphora" as values. If you choose to use OVN, you must also set lb-method to SOURCE_IP_PORT. |
| 3 | This property is required if you want to use multiple external networks with your cluster. The cloud provider creates floating IP addresses on the network that is specified here. |
|
Prior to saving your changes, verify that the file is structured correctly. Clusters might fail if properties are not placed in the appropriate section. |
Save the changes to the file and proceed with installation.
|
You can update your cloud provider configuration after you run the installer. On a command line, run: After you save your changes, your cluster will take some time to reconfigure itself. The process is complete if none of your nodes have a |
Download the Fedora CoreOS (FCOS) image to install OKD on a restricted network OpenStack environment.
Obtain the OKD installation program. For a restricted network installation, the program is on your mirror registry host.
Log in to the Red Hat Customer Portal’s Product Downloads page.
Under Version, select the most recent release of OKD 4 for RHEL 8.
|
The FCOS images might not change with every release of OKD. You must download images with the highest version that is less than or equal to the OKD version that you install. Use the image versions that match your OKD version if they are available. |
Download the Fedora CoreOS (FCOS) - OpenStack Image (QCOW) image.
Decompress the image.
|
You must decompress the image before the cluster can use it. The name of the downloaded file might not contain a compression extension, like $ file <name_of_downloaded_file> |
Upload the image that you decompressed to a location that is accessible from the bastion server, like Glance. For example:
$ openstack image create --file rhcos-44.81.202003110027-0-openstack.x86_64.qcow2 --disk-format qcow2 rhcos-${RHCOS_VERSION}
|
Depending on your OpenStack environment, you might be able to upload the image in either |
|
If the installation program finds multiple images with the same name, it chooses one of them at random. To avoid this behavior, create unique names for resources in OpenStack. |
The image is now available for a restricted installation. Note the image name or location for use in OKD deployment.
You can customize the OKD cluster you install on OpenStack.
Obtain the OKD installation program and the pull secret for your cluster. For a restricted network installation, these files are on your mirror host.
Have the imageContentSources values that were generated during mirror registry creation.
Obtain the contents of the certificate for your mirror registry.
Retrieve a Fedora CoreOS (FCOS) image and upload it to an accessible location.
Obtain service principal permissions at the subscription level.
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 openstack as the platform to target.
Specify the OpenStack external network name to use for installing the cluster.
Specify the floating IP address to use for external access to the OpenShift API.
Specify a OpenStack flavor with at least 16 GB RAM to use for control plane and compute nodes.
Select the base domain to deploy the cluster to. All DNS records will be sub-domains of this base and will also include the cluster name.
Enter a name for your cluster. The name must be 14 or fewer characters long.
Paste the pull secret from the Red Hat OpenShift Cluster Manager. This field is optional.
In the install-config.yaml file, set the value of platform.openstack.clusterOSImage to the image location or name. For example:
platform:
openstack:
clusterOSImage: http://mirror.example.com/images/rhcos-43.81.201912131630.0-openstack.x86_64.qcow2.gz?sha256=ffebbd68e8a1f2a245ca19522c16c86f67f9ac8e4e0c1f0a812b068b16f7265dEdit the install-config.yaml file to give the additional information that
is required for an installation in a restricted network.
Update the pullSecret value to contain the authentication information for
your registry:
pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'For <mirror_host_name>, specify the registry domain name
that you specified in the certificate for your mirror registry, and for
<credentials>, specify the base64-encoded user name and password for
your mirror registry.
Add the additionalTrustBundle parameter and value.
additionalTrustBundle: |
-----BEGIN CERTIFICATE-----
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
-----END CERTIFICATE-----The value must be the contents of the certificate file that you used for your mirror registry. The certificate file can be an existing, trusted certificate authority, or the self-signed certificate that you generated for the mirror registry.
Add the image content resources, which resemble the following YAML excerpt:
imageContentSources:
- mirrors:
- <mirror_host_name>:5000/<repo_name>/release
source: quay.example.com/openshift-release-dev/ocp-release
- mirrors:
- <mirror_host_name>:5000/<repo_name>/release
source: registry.example.com/ocp/releaseFor these values, use the imageContentSources that you recorded during mirror registry creation.
Make any other modifications to the install-config.yaml file that you require. You can find more information about
the available parameters in the Installation configuration parameters section.
Back up the install-config.yaml file so that you can use
it to install multiple clusters.
|
The |
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.
|
Kuryr installations default to HTTP proxies. |
For Kuryr installations on restricted networks that use the Proxy object, the proxy must be able to reply to the router that the cluster uses. To add a static route for the proxy configuration, from a command line as the root user, enter:
$ ip route add <cluster_network_cidr> via <installer_subnet_gateway>The restricted subnet must have a gateway that is defined and available to be linked to the Router resource that Kuryr creates.
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-----
...| 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. |
|
The installation program does not support the proxy |
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 |
Before you deploy an OKD cluster, you provide parameter values to describe your account on the cloud platform that hosts your cluster and optionally customize your cluster’s platform. When you create the install-config.yaml installation configuration file, you provide values for the required parameters through the command line. If you customize your cluster, you can modify the install-config.yaml file to provide more details about the platform.
|
After installation, you cannot modify these parameters in the |
Required installation configuration parameters are described in the following table:
| Parameter | Description | Values |
|---|---|---|
|
The API version for the |
String |
|
The base domain of your cloud provider. The base domain is used to create routes to your OKD cluster components. The full DNS name for your cluster is a combination of the |
A fully-qualified domain or subdomain name, such as |
|
Kubernetes resource |
Object |
|
The name of the cluster. DNS records for the cluster are all subdomains of |
String of lowercase letters, hyphens ( |
|
The configuration for the specific platform upon which to perform the installation: |
Object |
You can customize your installation configuration based on the requirements of your existing network infrastructure. For example, you can expand the IP address block for the cluster network or provide different IP address blocks than the defaults.
Only IPv4 addresses are supported.
| Parameter | Description | Values | ||
|---|---|---|---|---|
|
The configuration for the cluster network. |
Object
|
||
|
The cluster network provider Container Network Interface (CNI) plug-in to install. |
Either |
||
|
The IP address blocks for pods. The default value is If you specify multiple IP address blocks, the blocks must not overlap. |
An array of objects. For example: |
||
|
Required if you use An IPv4 network. |
An IP address block in Classless Inter-Domain Routing (CIDR) notation.
The prefix length for an IPv4 block is between |
||
|
The subnet prefix length to assign to each individual node. For example, if |
A subnet prefix. The default value is |
||
|
The IP address block for services. The default value is The OpenShift SDN and OVN-Kubernetes network providers support only a single IP address block for the service network. |
An array with an IP address block in CIDR format. For example: |
||
|
The IP address blocks for machines. If you specify multiple IP address blocks, the blocks must not overlap. |
An array of objects. For example: |
||
|
Required if you use |
An IP network block in CIDR notation. For example,
|
Optional installation configuration parameters are described in the following table:
| Parameter | Description | Values | ||
|---|---|---|---|---|
|
A PEM-encoded X.509 certificate bundle that is added to the nodes' trusted certificate store. This trust bundle may also be used when a proxy has been configured. |
String |
||
|
Enables Linux control groups version 2 (cgroups v2) on specific nodes in your cluster. The OKD process for enabling cgroups v2 disables all cgroup version 1 controllers and hierarchies. The OKD cgroups version 2 feature is in Developer Preview and is not supported by Red Hat at this time. |
|
||
|
The configuration for the machines that comprise the compute nodes. |
Array of |
||
|
Determines the instruction set architecture of the machines in the pool. Currently, clusters with varied architectures are not supported. All pools must specify the same architecture. Valid values are |
String |
||
|
Whether to enable or disable simultaneous multithreading, or
|
|
||
|
Required if you use |
|
||
|
Required if you use |
|
||
|
The number of compute machines, which are also known as worker machines, to provision. |
A positive integer greater than or equal to |
||
|
The configuration for the machines that comprise the control plane. |
Array of |
||
|
Determines the instruction set architecture of the machines in the pool. Currently, clusters with varied architectures are not supported. All pools must specify the same architecture. Valid values are |
String |
||
|
Whether to enable or disable simultaneous multithreading, or
|
|
||
|
Required if you use |
|
||
|
Required if you use |
|
||
|
The number of control plane machines to provision. |
The only supported value is |
||
|
The Cloud Credential Operator (CCO) mode. If no mode is specified, the CCO dynamically tries to determine the capabilities of the provided credentials, with a preference for mint mode on the platforms where multiple modes are supported.
|
|
||
|
Sources and repositories for the release-image content. |
Array of objects. Includes a |
||
|
Required if you use |
String |
||
|
Specify one or more repositories that may also contain the same images. |
Array of strings |
||
|
How to publish or expose the user-facing endpoints of your cluster, such as the Kubernetes API, OpenShift routes. |
Setting this field to
|
||
|
The SSH key to authenticate access to your cluster machines.
|
For example, |
Additional OpenStack configuration parameters are described in the following table:
| Parameter | Description | Values |
|---|---|---|
|
For compute machines, the size in gigabytes of the root volume. If you do not set this value, machines use ephemeral storage. |
Integer, for example |
|
For compute machines, the root volume’s type. |
String, for example |
|
For control plane machines, the size in gigabytes of the root volume. If you do not set this value, machines use ephemeral storage. |
Integer, for example |
|
For control plane machines, the root volume’s type. |
String, for example |
|
The name of the OpenStack cloud to use from the list of clouds in the
|
String, for example |
|
The OpenStack external network name to be used for installation. |
String, for example |
|
The OpenStack flavor to use for control plane and compute machines. This property is deprecated. To use a flavor as the default for all machine pools, add it as the value of the |
String, for example |
Optional OpenStack configuration parameters are described in the following table:
| Parameter | Description | Values |
|---|---|---|
|
Additional networks that are associated with compute machines. Allowed address pairs are not created for additional networks. |
A list of one or more UUIDs as strings. For example, |
|
Additional security groups that are associated with compute machines. |
A list of one or more UUIDs as strings. For example, |
|
OpenStack Compute (Nova) availability zones (AZs) to install machines on. If this parameter is not set, the installer relies on the default settings for Nova that the OpenStack administrator configured. On clusters that use Kuryr, OpenStack Octavia does not support availability zones. Load balancers and, if you are using the Amphora provider driver, OKD services that rely on Amphora VMs, are not created according to the value of this property. |
A list of strings. For example, |
|
For compute machines, the availability zone to install root volumes on. If you do not set a value for this parameter, the installer selects the default availability zone. |
A list of strings, for example |
|
Server group policy to apply to the group that will contain the compute machines in the pool. You cannot change server group policies or affiliations after creation. Supported options include An If you use a strict |
A server group policy to apply to the machine pool. For example, |
|
Additional networks that are associated with control plane machines. Allowed address pairs are not created for additional networks. |
A list of one or more UUIDs as strings. For example, |
|
Additional security groups that are associated with control plane machines. |
A list of one or more UUIDs as strings. For example, |
|
OpenStack Compute (Nova) availability zones (AZs) to install machines on. If this parameter is not set, the installer relies on the default settings for Nova that the OpenStack administrator configured. On clusters that use Kuryr, OpenStack Octavia does not support availability zones. Load balancers and, if you are using the Amphora provider driver, OKD services that rely on Amphora VMs, are not created according to the value of this property. |
A list of strings. For example, |
|
For control plane machines, the availability zone to install root volumes on. If you do not set this value, the installer selects the default availability zone. |
A list of strings, for example |
|
Server group policy to apply to the group that will contain the control plane machines in the pool. You cannot change server group policies or affiliations after creation. Supported options include An If you use a strict |
A server group policy to apply to the machine pool. For example, |
|
The location from which the installer downloads the FCOS image. You must set this parameter to perform an installation in a restricted network. |
An HTTP or HTTPS URL, optionally with an SHA-256 checksum. For example, |
|
Properties to add to the installer-uploaded ClusterOSImage in Glance. This property is ignored if You can use this property to exceed the default persistent volume (PV) limit for OpenStack of 26 PVs per node. To exceed the limit, set the You can also use this property to enable the QEMU guest agent by including the |
A list of key-value string pairs. For example, |
|
The default machine pool platform configuration. |
|
|
An existing floating IP address to associate with the Ingress port. To use this property, you must also define the |
An IP address, for example |
|
An existing floating IP address to associate with the API load balancer. To use this property, you must also define the |
An IP address, for example |
|
IP addresses for external DNS servers that cluster instances use for DNS resolution. |
A list of IP addresses as strings. For example, |
|
The UUID of a OpenStack subnet that the cluster’s nodes use. Nodes and virtual IP (VIP) ports are created on this subnet. The first item in If you deploy to a custom subnet, you cannot specify an external DNS server to the OKD installer. Instead, add DNS to the subnet in OpenStack. |
A UUID as a string. For example, |
install-config.yaml file for restricted OpenStack installationsThis sample install-config.yaml demonstrates all of the possible OpenStack
customization options.
|
This sample file is provided for reference only. You must obtain your
|
apiVersion: v1
baseDomain: example.com
controlPlane:
name: master
platform: {}
replicas: 3
compute:
- name: worker
platform:
openstack:
type: ml.large
replicas: 3
metadata:
name: example
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
serviceNetwork:
- 172.30.0.0/16
networkType: OVNKubernetes
platform:
openstack:
region: region1
cloud: mycloud
externalNetwork: external
computeFlavor: m1.xlarge
apiFloatingIP: 128.0.0.1
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...
additionalTrustBundle: |
-----BEGIN CERTIFICATE-----
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
-----END CERTIFICATE-----
imageContentSources:
- mirrors:
- <mirror_registry>/<repo_name>/release
source: quay.io/openshift-release-dev/ocp-release
- mirrors:
- <mirror_registry>/<repo_name>/release
source: quay.io/openshift-release-dev/ocp-v4.0-art-devDuring 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>.pubFor example, run the following to view the ~/.ssh/id_ed25519.pub public key:
$ cat ~/.ssh/id_ed25519.pubAdd 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.
At deployment, all OKD machines are created in a OpenStack-tenant network. Therefore, they are not accessible directly in most OpenStack deployments.
You can configure OKD API and application access by using floating IP addresses (FIPs) during installation. You can also complete an installation without configuring FIPs, but the installer will not configure a way to reach the API or applications externally.
Create floating IP (FIP) addresses for external access to the OKD API and cluster applications.
Using the OpenStack CLI, create the API FIP:
$ openstack floating ip create --description "API <cluster_name>.<base_domain>" <external_network>Using the OpenStack CLI, create the apps, or Ingress, FIP:
$ openstack floating ip create --description "Ingress <cluster_name>.<base_domain>" <external_network>Add records that follow these patterns to your DNS server for the API and Ingress FIPs:
api.<cluster_name>.<base_domain>. IN A <API_FIP>
*.apps.<cluster_name>.<base_domain>. IN A <apps_FIP>|
If you do not control the DNS server, you can add the record to your |
Add the FIPs to the
install-config.yaml
file as the values of the following
parameters:
platform.openstack.ingressFloatingIP
platform.openstack.apiFloatingIP
If you use these values, you must also enter an external network as the value of the
platform.openstack.externalNetwork parameter in the install-config.yaml file.
|
You can make OKD resources available outside of the cluster by assigning a floating IP address and updating your firewall configuration. |
You can install OKD on OpenStack without providing floating IP addresses.
In the
install-config.yaml
file, do not define the following
parameters:
platform.openstack.ingressFloatingIP
platform.openstack.apiFloatingIP
If you cannot provide an external network, you can also leave platform.openstack.externalNetwork blank. If you do not provide a value for platform.openstack.externalNetwork, a router is not created for you, and, without additional action, the installer will fail to retrieve an image from Glance. You must configure external connectivity on your own.
If you run the installer from a system that cannot reach the cluster API due to a lack of floating IP addresses or name resolution, installation fails. To prevent installation failure in these cases, you can use a proxy network or run the installer from a system that is on the same network as your machines.
|
You can enable name resolution by creating DNS records for the API and Ingress ports. For example: If you do not control the DNS server, you can add the record to your |
You can install OKD on a compatible cloud platform.
|
You can run the |
Configure an account with the cloud platform that hosts your cluster.
Obtain the OKD installation program and the pull secret for your cluster.
+
$ ./openshift-install create cluster --dir <installation_directory> \ (1)
--log-level=info (2)
| 1 | For <installation_directory>, specify the |
||
| 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: "4vYBz-Ee6gm-ymBZj-Wt5AL"
INFO Time elapsed: 36m22s
|
You can verify your OKD cluster’s status during or after installation.
In the cluster environment, export the administrator’s kubeconfig file:
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig (1)| 1 | For <installation_directory>, specify the path to the directory that you stored the installation files in. |
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.
View the control plane and compute machines created after a deployment:
$ oc get nodesView your cluster’s version:
$ oc get clusterversionView your Operators' status:
$ oc get clusteroperatorView all running pods in the cluster:
$ oc get pods -AYou 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 whoamisystem:adminSee Accessing the web console for more details about accessing and understanding the OKD web console.
Operator catalogs that source content provided by Red Hat and community projects are configured for OperatorHub by default during an OKD installation. In a restricted network environment, you must disable the default catalogs as a cluster administrator.
Disable the sources for the default catalogs by adding disableAllDefaultSources: true to the OperatorHub object:
$ oc patch OperatorHub cluster --type json \
-p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'|
Alternatively, you can use the web console to manage catalog sources. From the Administration → Cluster Settings → Configuration → OperatorHub page, click the Sources tab, where you can create, delete, disable, and enable individual sources. |
See About remote health monitoring for more information about the Telemetry service
If the mirror registry that you used to install your cluster has a trusted CA, add it to the cluster by configuring additional trust stores.
If necessary, you can opt out of remote health reporting.
Configure image streams for the Cluster Samples Operator and the must-gather tool.
Learn how to use Operator Lifecycle Manager (OLM) on restricted networks.
If you did not configure OpenStack to accept application traffic over floating IP addresses, configure OpenStack access with floating IP addresses.