A Kubernetes Operator built using the Operator Framework for Go. The Operator provides a way to easily install and manage an OpenStack Ironic installation on Kubernetes. This Operator was developed using RDO containers for openStack.

The operator is intended to be deployed via OLM Operator Lifecycle Manager

The Operator creates a custom Ironic resource that can be used to create Ironic API and conductor instances within the cluster. Example CR to create an Ironic in your cluster:

apiVersion: ironic.openstack.org/v1beta1
kind: Ironic
metadata:
  name: ironic
  namespace: openstack
spec:
  serviceUser: ironic
  customServiceConfig: |
    [DEFAULT]
    debug = true
  databaseInstance: openstack
  ironicAPI:
    replicas: 1
    containerImage: quay.io/podified-antelope-centos9/openstack-ironic-api:current-podified
  ironicConductors:
  - replicas: 1
    containerImage: quay.io/podified-antelope-centos9/openstack-ironic-conductor:current-podified
    pxeContainerImage: quay.io/podified-antelope-centos9/openstack-ironic-pxe:current-podified
    provisionNetwork: provision-net
  secret: ironic-secret

This example assumes the existence of additional network provision_net to use for exposing provision boot services (DHCP, TFTP, HTTP). Currently this additional network needs to be managed manually with NetworkAttachmentDefinition resources. For example, applying the following will result in network interface eno1 being available in the conductor pod:

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: provision-net
spec:
  config: |-
    {
      "cniVersion": "0.3.1",
      "name": "provision-net",
      "type": "host-device",
      "device": "eno1"
    }

The Ironic spec can be used to register e.g. the internal endpoint to an isolated network. MetalLB is used for this scenario.

As a pre requisite, MetalLB needs to be installed and worker nodes prepared to work as MetalLB nodes to serve the LoadBalancer service.

In this example the following MetalLB IPAddressPool is used:

---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: osp-internalapi
  namespace: metallb-system
spec:
  addresses:
  - 172.17.0.200-172.17.0.210
  autoAssign: false

The following represents an example of Ironic resource that can be used to trigger the service deployment, and have the internal ironicAPI endpoint registerd as a MetalLB service using the IPAddressPool osp-internal, request to use the IP 172.17.0.202 as the VIP and the IP is shared with other services.

apiVersion: ironic.openstack.org/v1beta1
kind: Ironic
metadata:
  name: ironic
spec:
  ...
  ironicAPI:
    ...
    override:
      service:
        metadata:
          annotations:
            metallb.universe.tf/address-pool: internalapi
            metallb.universe.tf/allow-shared-ip: internalapi
            metallb.universe.tf/loadBalancerIPs: 172.17.0.202
        spec:
          type: LoadBalancer
    ...
...

The internal ironicAPI endpoint gets registered with its service name. This service name needs to resolve to the LoadBalancerIP on the isolated network either by DNS or via /etc/hosts:

# openstack endpoint list -c 'Service Name' -c Interface -c URL --service ironic
+--------------+-----------+-------------------------------------------------+
| Service Name | Interface | URL                                             |
+--------------+-----------+-------------------------------------------------+
| ironic       | internal  | http://ironic-internal.openstack.svc:6385       |
| ironic       | public    | http://ironic-public-openstack.apps-crc.testing |
+--------------+-----------+-------------------------------------------------+

The current design takes care of the following:

• Creates ironic config files via config maps
• Creates an ironic deployment with the specified replicas
• Creates an ironic service
• Ironic bootstrap, and db sync are executed automatically on install and updates
• ConfigMap is recreated on any changes Ironic object changes and the Deployment updated.