Greetings fellow OpenShift enthusiasts! Not too long ago, Red Hat announced that OKD v3.11, the last release in the 3.x stream, is now generally available. The latest release of OpenShift enhances a number of current features that we know and love, as well as a number of interesting updates and technology previews for features that may or may not be included in OpenShift 4.0. Let’s take a look at one of the more exciting releases that may be part of The Great Updates coming in OpenShift 4.0.
Red Hat Operator Framework
Operators are automated software managers for Kubernetes clusters, built on top of the Kubernetes API, that manage both the installation and lifecycle of applications running on the cluster. The Operator Framework is an open source project that provides developer and runtime Kubernetes tools, enabling you to accelerate the development of an Operator. As the CNCF officially recognizes OpenShift as a distribution of Kubernetes, the latest release now includes the Operator Lifecycle Manager (OLM) as technology previews in OpenShift v3.11. The OpenShift OLM includes a catalog of curated operators, with the ability to load other operators into the cluster, and handles rolling updates of all operators.
As with most OpenShift components, the Operator Framework can be installed on a v3.11 cluster using
- Add the following line to your inventory under
[OSEv3:vars], replacing “ & “ with your RedHat customer portal credentials:
- Then run the
registry_authplaybook to authorize all nodes in your cluster with the credentials provided above.
$ ansible-playbook -i
- Once the inventory file is updated, install the Operator Framework with the
registry_authplaybook, found under your system’s openshift-ansible subdirectory.
$ ansible-playbook -i
OpenStack Kuryr SDN
OpenStack and OpenShift share similar SDN models, specifically in that internal communication between VMs or pods (respectively) are handled using
vxlan tunnels. As it stands, packets are sent between pods in OpenShift clusters running on OpenStack first route through the OpenShift
vxlan tunnel; then they are run through the OpenStack
vxlan tunnel which can cause a bottleneck. To address this, Red Hat OpenShift engineers are currently working on reducing the performance penalty with OpenStack Kuryr (pronounced curry-yur), a
Docker network plugin that utilizes Neutron APIs to provide networking services to Docker containers by implementing the Docker
Libnetwork remote driver and mapping its calls to Neutron. Kuryr works as a translator between the
libnetwork Container Network Model, or CNM, and Neutron’s networking model and provides container-host or container-VM (nested VM) binding.
To reduce performance penalty on OpenShift clusters deployed on OpenStack VMs, OpenShift v3.11 now uses the kuryr-kubernetes SDN, installed as pods in the
openshift-infra namespace to provide connectivity between Kubernetes pods and OpenStack VMs. The
kuryr-controller pod is a single service instance, installed on any node. The
kuryr-cni pod is a container that installs and configures Kuryr as a CNI driver on all OpenShift nodes.
Kuryr-kubernetes on OpenShift is still in technology preview so that you can take it for a test drive on OpenShift 3.11 clusters, but it is not currently recommended for production use.
How to Install Kuryr
- Install your OpenShift-on-OpenStack cluster with Kuryr integration by installing the following base packages:
$ yum install -y ansible openshift-ansible python2-shade python-dns
python2-heatclient python2-octaviaclient python-openstackclient bind-utils
- Next, update the ansible inventory file with the following information:
Note: Before installation, you will need to enable Kuryr in your OpenStack cloud.
# Enable Kuryr.
os_sdn_network_plugin_name=cni# Set userspace so that there are no iptables remains.
# Keystone URL.
# OpenStack domain name of user owning Kuryr resources.
# OpenStack project name of user owning Kuryr resources.
# OpenStack project id for Kuryr resources.
# OpenStack username that will own kuryr resources.
# Password for that user.
# Default Neutron security groups' IDs for Kubernetes pods
# Default Neutron subnet ID for Kubernetes pods.
kuryr_openstack_pod_subnet_id=< # Default OpenStack project ID for Kubernetes resources. kuryr_openstack_pod_project_id= # Neutron subnet ID for Kubernetes worker node VMs. kuryr_openstack_worker_nodes_subnet_id= # Default Neutron subnet ID for Kubernetes services. kuryr_openstack_service_subnet_id= # Specify a DNS server for OpenShift nodes, as OpenStack will not provide node name resolution by default. openshift_openstack_dns_nameservers=[18.104.22.168]
- After updating the host inventory, install kuryr-kubernetes in your OpenShift cluster with the
provision_installplaybook, included with OPenShift-ansible v3.11 playbooks:
$ ansible-playbook --user openshift -i /usr/share/ansible/openshift-ansible/playbooks/openstack/inventory.py -i ansible-nodes.txt playbooks/openstack/openshift-cluster/provision_install.yml
Some of the other changes in the OpenShift 3.11 release include:
- Automatic ansible logging - so long as the user deploys the playbook from the
- PersistentVolume resize (technology preview)
- PersistentVolume provisioning using OpenStack Manilla (shared filesystem service)
- Support for Prometheus monitoring
So, what feature are you most excited about? Let me know in the comments. Happy OpenShifting!