This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.此内容没有您所选择的语言版本。
Chapter 18. Configuring for OpenStack
18.1. Overview 复制链接链接已复制到粘贴板!
When deployed on OpenStack, OpenShift Container Platform can be configured to access OpenStack infrastructure, including using OpenStack Cinder volumes as persistent storage for application data.
18.2. Permissions 复制链接链接已复制到粘贴板!
Configuring OpenStack for OpenShift Container Platform requires the following role:
member | For creating assets(instances, networking ports, floating ips, volumes, and so on.) you need the member role for the tenant. |
18.3. Configuring a Security Group 复制链接链接已复制到粘贴板!
When installing OpenShift Container Platform on OpenStack, ensure that you set up the appropriate security groups.
These are some ports that you must have in your security groups, without which the installation fails. You may need more depending on the cluster configuration you want to install. For more information and to adjust your security groups accordingly, see Required Ports for more information.
All OpenShift Container Platform Hosts |
|
etcd Security Group |
|
Master Security Group |
|
Node Security Group |
|
Infrastructure Nodes (ones that can host the OpenShift Container Platform router) |
|
CRI-O |
If using CRIO, you must open tcp/10010 to allow |
If configuring external load-balancers (ELBs) for load balancing the masters and/or routers, you also need to configure Ingress and Egress security groups for the ELBs appropriately.
18.4. Configuring OpenStack Variables 复制链接链接已复制到粘贴板!
To set the required OpenStack variables, create a /etc/cloud.conf file with the following contents on all of your OpenShift Container Platform hosts, both masters and nodes:
Consult your OpenStack administrators for values of the OS_
variables, which are commonly used in OpenStack configuration.
You can set an OpenStack configuration on your OpenShift Container Platform master and node hosts in two different ways:
- Using Ansible and the advanced installation tool
- Manually, by modifying the master-config.yaml and node-config.yaml files.
During advanced installations, OpenStack can be configured using the following parameters, which are configurable in the inventory file:
-
openshift_cloudprovider_kind
-
openshift_cloudprovider_openstack_auth_url
-
openshift_cloudprovider_openstack_username
-
openshift_cloudprovider_openstack_password
-
openshift_cloudprovider_openstack_domain_id
-
openshift_cloudprovider_openstack_domain_name
-
openshift_cloudprovider_openstack_tenant_id
-
openshift_cloudprovider_openstack_tenant_name
-
openshift_cloudprovider_openstack_region
-
openshift_cloudprovider_openstack_lb_subnet_id
If a parameter value in the Ansible inventory file contains special characters, such as #
, {
or }
, you must double-escape the value (that is enclose the value in both single and double quotation marks). For example, to use mypasswordwith###hashsigns
as a value for the variable openshift_cloudprovider_openstack_password
, declare it as openshift_cloudprovider_openstack_password='"mypasswordwith###hashsigns"'
in the Ansible host inventory file.
Example 18.1. Example OpenStack Configuration with Ansible
Edit or create the master configuration file on all masters (/etc/origin/master/master-config.yaml by default) and update the contents of the apiServerArguments
and controllerArguments
sections:
When triggering a containerized installation, only the directories of /etc/origin and /var/lib/origin are mounted to the master and node container. Therefore, cloud.conf should be in /etc/origin/ instead of /etc/.
Edit or create the node configuration file on all nodes (/etc/origin/node/node-config.yaml by default) and update the contents of the kubeletArguments
and nodeName
sections:
- 1
- Name of the OpenStack instance where the node runs (i.e., name of the virtual machine)
Currently, the nodeName
must match the instance name in Openstack in order for the cloud provider integration to work properly. The name must also be RFC1123 compliant.
When triggering a containerized installation, only the directories of /etc/origin and /var/lib/origin are mounted to the master and node container. Therefore, cloud.conf should be in /etc/origin/ instead of /etc/.
The OpenStack installation playbook is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information on Red Hat Technology Preview features support scope, see https://access.redhat.com/support/offerings/techpreview/.
To install OpenShift Container Platform on an existing OpenStack installation, use the OpenStack playbook. For more information about the playbook, including detailed prerequisites, see the OpenStack Provisioning readme file.
To run the playbook, run the following command:
ansible-playbook --user openshift \ -i openshift-ansible/playbooks/openstack/inventory.py \ -i inventory \ openshift-ansible/playbooks/openstack/openshift-cluster/provision_install.yml
$ ansible-playbook --user openshift \
-i openshift-ansible/playbooks/openstack/inventory.py \
-i inventory \
openshift-ansible/playbooks/openstack/openshift-cluster/provision_install.yml
18.6. Applying Configuration Changes 复制链接链接已复制到粘贴板!
Start or restart OpenShift Container Platform services on all master and node hosts to apply your configuration changes, see Restarting OpenShift Container Platform services:
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
# systemctl restart atomic-openshift-node
Switching from not using a cloud provider to using a cloud provider produces an error message. Adding the cloud provider tries to delete the node because the node switches from using the hostname as the externalID
(which would have been the case when no cloud provider was being used) to using the cloud provider’s instance-id
(which is what the cloud provider specifies). To resolve this issue:
- Log in to the CLI as a cluster administrator.
Check and back up existing node labels:
oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
$ oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Delete the nodes:
oc delete node <node_name>
$ oc delete node <node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow On each node host, restart the OpenShift Container Platform service.
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Add back any labels on each node that you previously had.