Mirantis Container Cloud (MCC) becomes part of Mirantis OpenStack for Kubernetes (MOSK)!

Starting with MOSK 25.2, the MOSK documentation set covers all product layers, including MOSK management (formerly MCC). This means everything you need is in one place. The separate MCC documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Rotate Octavia Amphora (LBaaS) certificates

Available since MOSK 25.2

MOSK provides an automated procedure for rotating OpenStack Amphora load balancer certificates. This capability ensures that TLS certificates used by Amphora load balancers are renewed before expiration and replaced without manual reconfiguration. When initiated by the operator, the system generates and deploys new certificates.

Before you initiate the certificate rotation, thoroughly plan the maintenance window required to perform the operation based on the considerations below.

Impact on workloads availability

During certificate rotation, each affected load balancer undergoes a failover to apply the new certificate. A new amphora instance is created and configured with the updated certificate, after which the HA IP is switched over to it. This process may briefly interrupt network connections to workloads behind the load balancer. The downtime typically lasts up to 30 seconds per load balancer, depending on the environment size and workload.

Rotation duration

By default, the octavia-loadbalancers-failover job performs failovers using five parallel workers, with each load balancer failover taking approximately one minute. You can roughly estimate the total duration of rotation in minutes by dividing the number of load balancers by the number of workers.

If required, you can adjust the number of parallel workers through the LB_FAILOVER_MAX_WORKERS parameter in the OpenStackDeployment custom resource:

spec:
  services:
    load-balancer:
      octavia:
        values:
          jobs:
            lb_failover:
              env:
                LB_FAILOVER_MAX_WORKERS: 5

Rotate the LBaaS certificate

  1. In the OpenStackDeploymentStatus custom resource, verify that osdpl is in the APPLIED state and all OpenStack components listed under the health section report the Ready status:

    kubectl -n openstack get osdplst osh-dev -o yaml
    

    Example of an expected system response:

     kind: OpenStackDeploymentStatus
     metadata:
       name: osh-dev
       namespace: openstack
     spec: {}
     status:
       ...
       health:
         barbican:
           api:
             generation: 2
             status: Ready
         cinder:
           api:
             generation: 2
             status: Ready
           backup:
             generation: 1
             status: Ready
           scheduler:
             generation: 1
             status: Ready
           volume:
             generation: 1
             status: Ready
       osdpl:
         cause: update
         controller_host: rockoon-5746446978-7dsxs
         controller_version: 1.1.8.dev46
         fingerprint: 2b2357c7c7f41e5a08e14c90a726746909f8cdc68461f972f7d86304b5795a83
         health: 23/23
         lcm_progress: 20/20
         openstack_version: epoxy
         state: APPLIED
         timestamp: "2025-08-12 14:46:42.120288"
    
  2. Log in to the osdpl container in the rockoon pod:

    kubectl -n osh-system exec -ti deploy/rockoon -c osdpl -- bash
    
  3. Trigger the rotation using the osctl utility:

    osctl certificates rotate --osdpl osh-dev --type octavia:amphora
    

When the rotation is over, you can verify that the certificate has been rotated successfully by checking that the certificate expiration alerts in StackLight for the rotated service are cleared.

Additionally, you can check the execution logs for verification in the octavia-loadbalancers-failover job pod or in the osdpl container of the rockoon pod. At the end of the job run, a summary in a statistics format is displayed showing the results for all processed load balancers, for example:

2025-08-05 14:50:50 DEBUG Detailed statistics:
CANCELLED: []
FAILED: []
SKIPPED:
- acdcff9b-041b-4ba9-9fdb-03692ce9ac75
SUCCESS:
- a9186ea8-bed5-482a-8699-f55b19316946
- 8f214f52-bc90-4a77-aa13-c14c762efba9
- 968a47bb-6488-469f-8514-dc45f6003cff
- cc24f787-7c2b-4054-8a8f-9b1fba2927c3
- 9c79cf61-a1e9-4c67-b1b7-fe026fef0532
- a8b8a400-a58d-4e89-9fae-20748606199f
- f258ab32-0c20-4346-a3d5-d99a957bf8b0

2025-08-05 14:50:50 INFO General statistic for loadbalancer failover:
  SUCCESS: 7  FAILED: 0  SKIPPED: 1  CANCELLED: 0