26. Release Notes¶

26.1. Robin Cloud Native Platform v5.7.1¶

The Robin Cloud Native Platform (CNP) v5.7.1 release notes has pre- and post-upgrade considerations, fixed issues, and known issues.

Release Date: February 23, 2026

26.1.1. Infrastructure Versions¶

The following software applications are included in this CNP release:

Software Application	Version
Kubernetes	1.33.5
Docker	25.0.2 (RHEL 8.10 or Rocky Linux 8.10)
Podman	5.4.0 (RHEL 9.6)
Prometheus	2.39.1
Prometheus Adapter	0.10.0
Node Exporter	1.4.0
Calico	3.28.2
HAProxy	2.4.7
PostgreSQL	14.12
Grafana	9.2.3
CRI Tools	1.33.0
cert-manager	1.19.1

26.1.2. Supported Operating Systems¶

The following are the supported operating systems and kernel versions for Robin CNP v5.7.1:

OS Version	Kernel Version
Red Hat Enterprise Linux 8.10	4.18.0-553.el8_10.x86_64
Rocky Linux 8.10	4.18.0-553.el8_10.x86_64
Red Hat Enterprise Linux 9.6	5.14.0-570.24.1.el9_6.x86_64+rt

Note

Robin CNP supports both RT and non-RT kernels on above supported operating systems.

26.1.3. Upgrade Paths¶

The following are the supported upgrade paths for Robin CNP v5.7.1:

Robin CNP v5.4.3 HF5+PP to Robin CNP v5.7.1-311
Robin CNP v5.4.3 HF6 to Robin CNP v5.7.1-311
Robin CNP v5.4.3 HF7 to Robin CNP v5.7.1-311
Robin CNP v5.5.1-1950 to Robin CNP v5.7.1-311
Robin CNP v5.7.0-296 to Robin CNP v5.7.1-311

26.1.3.1. Pre-upgrade considerations¶

For a successful upgrade, you must run the possible_job_stuck.py script before and after the upgrade. Contact the Robin Support team for the upgrade procedure using the script.
When upgrading from supported Robin CNP versions to Robin CNP v5.7.1, if your cluster already has cert-manager installed, you must uninstall it before upgrading to Robin CNP v5.7.1.
Before upgrading to Robin CNP v5.7.1, you must stop the robin-certs-check job or CronJob. To stop the robin-certs-check job, run the kubectl delete job robin-certs-check -n robinio command, and to stop the robin-certs-check CronJob, run the robin cert check --stop-cronjob command.

26.1.3.2. Post-upgrade considerations¶

After upgrading to Robin CNP v5.7.1, verify that the value of the k8s_resource_sync config parameter is set to 60000 using the robin schedule list | grep -i K8sResSync command. If it is not set, you must run the robin schedule update K8sResSync k8s_resource_sync 60000 command to update the value of the robin schedule K8sResSync config parameter.
After upgrading to Robin CNP v5.7.1, you must run the robin-server validate-role-bindings command. To run this command, you need to log in to the robin-master Pod. This command verifies the roles assigned to each user in the cluster and corrects them if necessary.
After upgrading to Robin CNP v5.7.1, the k8s_auto_registration config parameter is disabled by default. The config setting is deactivated to prevent all Kubernetes apps from automatically registering and consuming resources. The following are the points you must be aware of with this change:
- You can register the Kubernetes apps using the robin app register command manually and use Robin CNP for snapshots, clones, and backup operations of the Kubernetes app.
- As this config parameter is disabled, when you run the robin app nfs-list command, the mappings between Kubernetes apps and NFS server Pods are not listed in the command output.
- If you need mapping between Kubernetes app and NFS server Pod when the k8s_auto_registration config parameter is disabled or the k8s app is not manually registered, get the PVC name from the Pod YAML file (kubectl get pod -n <name> -o YAML) and run the robin nfs export list | grep <pvc name> command.
- The robin nfs export list command output displays the PVC name and namespace.
After upgrading to Robin CNP v5.7.1, you must start the robin-certs-check CronJob using the robin cert check -stat-cronjob command, if it was stopped before upgrade.

26.1.3.3. Pre-upgrade steps¶

Upgrading from Robin CNP v5.4.3 to Robin CNP v5.7.1-311

Before upgrading from Robin CNP v5.4.3 HF5 to Robin CNP v5.7.1, perform the following steps:

Update the value of the suicide_threshold config parameter to 1800:
```
# robin config update agent suicide_threshold 1800
```
Verify the NFS monitor is enabled. It must be True
```
# robin schedule list | grep -I NFS
```

Set the toleration seconds for all NFS server Pods to 86400 seconds. After upgrade, you must change the tolerations seconds according to the post-upgrade steps.

for pod in `kubectl get pod -n robinio -l robin.io/instance=robin-nfs --output=jsonpath={.items..metadata.name}`; do     echo "Updating $pod tolerationseconds to 86400";     kubectl patch pod $pod -n robinio --type='json' -p='[{"op": "replace", "path": "/spec/tolerations/0/tolerationSeconds", "value": 86400}, {"op": "replace", "path": "/spec/tolerations/1/tolerationSeconds", "value": 86400}]'; done

Verify the webhooks are enabled.

# robin config list | grep -I robin_k8s_extension

It must be True. If it the disabled, enable it.

# robin config update manager robin_k8s_extension True

Check the mutating webhook’s is present on the cluster.
```
# kubectl get mutatingwebhookconfiguration -A
```

Enable robin_k8s_extension. Note: You must create the robin-schedulextender-policy-template.yaml and preentry-<version>.sh files in the usr/local/robin directory on all three K8s control-plane hosts.

Create a robin-schedulextender-policy-template.yaml file and add the following:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: /etc/kubernetes/scheduler.conf
extenders:
  - urlPrefix: "https://{{hostname}}:{{port}}/{{urlsuffix}}"
    filterVerb: predicates
    enableHTTPS: true
    nodeCacheCapable: false
    ignorable: {{ignorable}}
    httpTimeout: {{httptimeout}}
    tlsConfig:
      insecure: true
    managedResources:
    - name: robin.io/robin-required
      ignoredByScheduler: true

Create a preentry-<version>.sh and add the following:

# cp /usr/local/robin/robin-schedulextender-policy-template.yaml /opt/robin/current/etc/robin/k8s/robin-schedulextender-policy-template.yaml
# cp /usr/local/robin/robin-schedulextender-policy-template.yaml /etc/robin/k8s/robin-schedulextender-policy-template.yaml

Upgrading from Robin CNP v5.5.1 to Robin CNP v5.7.1-311

Before upgrading from Robin CNP v5.5.1 to Robin CNP v5.7.1, perform the following steps:

Verify the NFS monitor is enabled using robin schedule list | grep -I NFS. It must be True.
Update the value of the suicide_threshold config parameter to 1800:
```
# robin config update agent suicide_threshold 1800
```

Set the toleration seconds for all NFS server Pods to 86400 seconds. After upgrade, you must change the tolerations seconds according to the post-upgrade steps.

for pod in `kubectl get pod -n robinio -l robin.io/instance=robin-nfs --output=jsonpath={.items..metadata.name}`; do     echo "Updating $pod tolerationseconds to 86400";     kubectl patch pod $pod -n robinio --type='json' -p='[{"op": "replace", "path":"/spec/tolerations/1/tolerationSeconds", "value": 86400}, {"op":"replace", "path": "/spec/tolerations/2/tolerationSeconds", "value":86400}]']; done

26.1.3.4. Post-upgrade steps¶

After upgrading from Robin CNP v5.4.3 or Robin CNP v5.5.1 to Robin CNP v5.7.1-311

After upgrading from Robin CNP v5.4.3 or Robin CNP v5.5.1 to Robin CNP v5.7.1, perform the following steps:

Update the value of the suicide_threshold config parameter to 40:
```
# robin config update agent suicide_threshold 40
```

Set the check_helm_apps config parameter to False:

# robin config update cluster check_helm_apps False

Set the chargeback_track_k8s_resusage config parameter to False:

# robin config update server chargeback_track_k8s_resusage False

Set the robin_k8s_extension config parameter to True. If no, set it to True.
```
# robin config update manager robin_k8s_extension True
```

Verify whether the following mutating webhooks are present:

# kubectl get mutatingwebhookconfigurations -A | grep robin
k8srobin-deployment-mutating-webhook   1          20d
k8srobin-ds-mutating-webhook           1          20d
k8srobin-pod-mutating-webhook          1          20d
k8srobin-sts-mutating-webhook          1          20d
robin-deployment-mutating-webhook      1          20d
robin-ds-mutating-webhook              1          20d
robin-pod-mutating-webhook             1          20d
robin-sts-mutating-webhook             1          20d

If above k8srobin-* mutating webhooks are not present then bounce the robink8s-serverext Pods:
```
# kubectl delete pod -n robinio -l app=robink8s-serverext
```

Verify whether the following validating webhooks are present:

# kubectl get validatingwebhookconfigurations
NAME                             WEBHOOKS   AGE
cert-manager-webhook             1          45h
controllers-validating-webhook   1          31h
ippoolcr-validating-webhook      1          31h
namespaces-validating-webhook    1          31h
pods-validating-webhook          1          31h
pvcs-validating-webhook          1          31h

If robin-* mutating webhooks displayed in the step 6 output and validating webhooks displayed in the step 8 output are not present on your setup, then restart the robin-server-bg service:
```
# rbash master
# supervisorctl restart robin-server-bg
```

Set the toleration seconds for all NFS server Pods to 60 seconds when the node is in the notready state and set to 0 seconds, when the node is unreachable state.

for pod in `kubectl get pod -n robinio -l robin.io/instance=robin-nfs --output=jsonpath={.items..metadata.name}`; do     echo "Updating $pod tolerationseconds";     kubectl patch pod $pod -n robinio --type='json' -p='[{"op": "replace", "path": "/spec/tolerations/0/tolerationSeconds", "value": 60}, {"op": "replace", "path": "/spec/tolerations/1/tolerationSeconds", "value": 0}]'; done 2>/dev/null

26.1.4. Fixed Issues¶

Reference ID	Description
RSD-11129	The issue of allowing duplicate VLAN entries on a host interface in Robin CNP v5.7.0 is fixed.
RSD-11117	When creating a VM on the OVS network using the `robin app create from-bundle` command, it is failing and resulting in the prevention of VM-based application deployment. This issue is fixed.
RSD-11089	When rebooting the primary master node on the cluster caused the cluster to hang indefinitely due to the `robin-vblock-clean` process entering a D-state (uninterruptible sleep) due to an issue in `tcmur_fake_handler`. This issue is fixed.
RSD-11107	Pod with FPGA PCI resource requirements fails to deploy even when valid PCI devices are available on the host and displays the following FailedScheduling error: `Insufficient intel.com/fpga_0000_1f_00_0_vfiopci`. This issue is fixed.
PP-40940	Burstable Pods deployment fails with these types of errors: with “Insufficient CPU” or “No host found” errors if their total resource requests (CPU or huge pages) exceed the capacity of a single NUMA node while using a Robin IP pool. This issue is fixed. Robin CNP now allows burstable Pods to span multiple NUMA nodes, even when the `topology_manager_policy` is set to restricted.
RSD-11042	The issue of the standby Robin master Pod failing its readiness probe and becoming unhealthy due to a mismatch between the in-memory phase state and the value stored in `/etc/robin/robin_master/phase` is fixed.
RSD-11112	When creating a VM on the Calico network using the `robin app create from-bundle` command, it is failing and resulting in the prevention of VM-based application deployment. This issue is fixed.
RSD-11179	The issue of adding a TLS-enabled LDAP server to a Robin CNP cluster failing due to use of the unsupported TLSv1 protocol is fixed. Robin CNP now uses the TLSv1_2 protocol, allowing the TLS layer to be configured properly.

26.1.5. Known Issues¶

Reference ID	Description
PP-41172	Symptom After upgrading from a supported Robin CNP version to Robin CNP v5.7.1, NFS mounts on client nodes can become unresponsive, leading to critical issues such as the following: kubelet instability (frequent restarts) patronictl command failures (connection refused) kubectl exec operations failing for pods on affected nodes. This problem is primarily observed when the NFS client (the node where the PVC is mounted) experiences prolonged unresponsiveness from the NFS server. Workaround If an NFS mount is hung, you can recover the system by forcing new NFS sessions: Identify hung NFS Mounts: Attempt to access the NFS mount path. Example /var/lib/kubelet/pods/<pod_uid>/volumes/kubernetes.io~csi/<pvc_name>/mount. If the command hangs (for example, `ls /path/to/mount` with no output and requiring Ctrl+C to exit), the mount is hung. Example $ ls /var/lib/pods/0cab5468-b43f-4afd-bad3/volumes/ kubernetes.io~csi/pvc-7f31e2fc-b5b7-4991-ab97/mount^C Confirm that the NFS export for the hung PVC is in a `READY` state using `robin nfs export-list`. Example $ robin nfs export-list\|grep pvc-7f31e2fc-b5b7-4991-ab97 \|READY\|19\|pvc-7f31e2fc-b5b7-4991-ab97\|robin-nfs-shared-23\| ["sm-compute02"]\|192.02.204.31:/pvc-7f31e2fc-b5b7-4991-ab97\| loaddbehg-fio\|sachin\| From the `robin nfs export-list` output, note the NFS Server Pod name serving the hung export. For example, in the above output, the NFS server Pod is `robin-nfs-shared-23`. Delete the identified NFS server pod. This action forces new NFS sessions and typically resolves the hung mount issue: # kubectl delete pod -n robinio <nfs_shared_server_pod_name> Example # kubectl delete pod robin-nfs-shared-23 -n robinio
PP-41195	Symptom After you perform a force unmount operation for an RWX (ReadWriteMany) volume on a host where it was previously mounted, or during certain failover scenarios involving RWX volumes, the associated Robin NFS server Pod might transition into an ASSIGNED_ERR state. When the Pod is in this state, the NFS server Pod is unable to export the volume, rendering the volume inaccessible via NFS. Workaround Contact the Robin Customer Support team to resolve this issue.
PP-41192	Symptom When creating a KVM using the Robin bundle, CPU core count must be specified in even numbers. If odd numbers are specified, the KVM will not be deployed, however, the respective Pod might be in the `Running` state.
PP-41159	Symptom After upgrading to Robin CNP v5.7.1, some Pods might get stuck in the `ContainerCreating` state because the VolumeUnmount job holds a lock on the volume, and the `VolumeUnmount` job shows the following error: Target /var/lib/robin/nfs/robin-nfs-shared-107/ganesha/pvc-b84ed376-2a58-484f-8031-4530c1899b2c is busy, please retry later. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) Workaround Apply the following workaround steps: Verify no pending I/Os at the RIO layer: # rio snapshot iolist Verify no in-flight I/Os on the relevant block device: # /sys/block/<dev>/inflight If there are no pending and in-flight I/Os, do a lazy unmount with the path shown in the `VolumeUnmount` job error message: # umount -l <mountpath>
PP-40988	In rare scenarios, after you perform an application upgrade on Robin CNP, the application’s Pod might enter into a `flapping` state where it repeatedly restarts. However, after a few redeployments, the Pod becomes stable on its own without any intervention, and this behavior is intermittent.

26.1.6. Technical Support¶

Contact Robin Technical support for any assistance.