[Global] auth-url = <OS_AUTH_URL> username = <OS_USERNAME> password = <password> domain-id = <OS_USER_DOMAIN_ID> tenant-id = <OS_TENANT_ID> region = <OS_REGION_NAME> [LoadBalancer] subnet-id = <UUID of the load balancer subnet>
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.
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. |
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) |
|
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.
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:
[Global] auth-url = <OS_AUTH_URL> username = <OS_USERNAME> password = <password> domain-id = <OS_USER_DOMAIN_ID> tenant-id = <OS_TENANT_ID> region = <OS_REGION_NAME> [LoadBalancer] subnet-id = <UUID of the load balancer subnet>
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:
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
# Cloud Provider Configuration
#
# Note: You may make use of environment variables rather than store
# sensitive configuration within the ansible inventory.
# For example:
#openshift_cloudprovider_openstack_username="{{ lookup('env','USERNAME') }}"
#openshift_cloudprovider_openstack_password="{{ lookup('env','PASSWORD') }}"
#
# Openstack
#openshift_cloudprovider_kind=openstack
#openshift_cloudprovider_openstack_auth_url=http://openstack.example.com:35357/v2.0/
#openshift_cloudprovider_openstack_username=username
#openshift_cloudprovider_openstack_password=password
#openshift_cloudprovider_openstack_domain_id=domain_id
#openshift_cloudprovider_openstack_domain_name=domain_name
#openshift_cloudprovider_openstack_tenant_id=tenant_id
#openshift_cloudprovider_openstack_tenant_name=tenant_name
#openshift_cloudprovider_openstack_region=region
#openshift_cloudprovider_openstack_lb_subnet_id=subnet_id
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:
kubernetesMasterConfig:
...
apiServerArguments:
cloud-provider:
- "openstack"
cloud-config:
- "/etc/cloud.conf"
controllerArguments:
cloud-provider:
- "openstack"
cloud-config:
- "/etc/cloud.conf"|
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:
nodeName:
<instance_name> (1)
kubeletArguments:
cloud-provider:
- "openstack"
cloud-config:
- "/etc/cloud.conf"| 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/. |
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
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)'Delete the nodes:
$ oc delete node <node_name>On each node host, restart the OpenShift Container Platform service.
# systemctl restart atomic-openshift-node
Add back any labels on each node that you previously had.