SMCP 5.11 Release Notes

Platform9 SMCP 5.11

2024-12-24

Features/Enhancements

Added Upgraded management cluster to Kubernetes version 1.30.

Added Added support for workload clusters with Kubernetes versions 1.28, 1.29 and 1.30.

Added Added new parameters to Qbert Upgrade API to support configuration of Calico and API server flags. Please see https://platform9.com/docs/qbert/ref#postupgrade-a-cluster-identified-by-the-uuid for details

• Updated parameters will be sent to the cluster (file /etc/pf9/kube.env) via the qbert. You can verify the updated values in the file: /etc/pf9/kube.env
• To apply the new flags, you are required to restart the stack on the nodes:
  • systemctl stop pf9-hostagent pf9-nodeletd
  • sudo /opt/pf9/nodelet/nodeletd phases start

Added Added support for Dynamic Kubelet Configuration via Qbert API on workload clusters. Read more: Dynamic Kubelet Configuration

Added Added support for the feature to configure containerd to pull images from a specific custom registry. Read more: Using Registry Mirror for Container Images

Added Added support to configure monitoring for management cluster. Read more: Management Cluster Monitoring

Bug Fixes

Fixed Fixed an issue in management cluster which caused the images for multiple components to be garbage collected by Kubelet, which let to components becoming non-functional due to ImagePullBackoff error. Required images will now be pinned in the management cluster and will not be garbage collected.

Fixed Fixed an issue that caused login failure due to high load on the management cluster DB.

Fixed [UX-2947] : Management plane UI performance was improved for reduced lag and faster loading while loading k8s resources like services, pods, deployments when the workload clusters contain a high number of k8s resources (up to 100 namespaces and 4500 resources including 1500+ deployments and similar number of pods, services)

Known Issues

Known Issue On Ubuntu 22: SMCP 5.10 to SMCP 5.11 upgrade procedure requires following commands to be run to update host side components:

• airctl configure-hosts --reset-pf9-managed-docker-conf --skip-docker-install --skip-docker-img-import --verbose
• airctl upgrade-hosts --verbose

Impact: For ubuntu22, above procedure breaks the host connection from the management cluster, terminates the pf9-comms leading to management cluster upgrade failure.

Workaround: For ubuntu22, reversing the order of the two commands works; run the upgrade-host then the configure-hosts

Known Issue During the DU upgrade process (airctl upgrade --config airctl-config.yaml --verbose), the sunpike-kube-apiserver pod enters a CrashLoopBackOff state following the successful execution of the airctl upgrade step. While the pod eventually reconciles itself, it may take an extended duration (30+ minutes or more).

Impact: This delay can disrupt cluster operations, leading to prolonged upgrade timelines and potential downtime for services dependent on the sunpike-kube-apiserver.

Workaround:

Manually restarting the sunpike-kube-apiserver pod resolves the issue and significantly reduces reconciliation time.

Known Issue On Ubuntu 22: When rebooting a management cluster node running Ubuntu 22, the node does not automatically recover. This can lead to an unavailable management plane and disruption of cluster operations.

Impact: Post-reboot, the management cluster node remains in a non-functional state until manual intervention is performed.

Workaround: To recover the node, run the following commands on the affected node:

• sudo systemctl stop pf9-nodeletd
• sudo /opt/pf9/nodelet/nodeletd phases restart

Known Issue During the DU upgrade, the du-upgrade-airctl pod continues to remain in running state, and eventually errors out because the capi-contoller-manager pod is not running

Impact: This leads to inconsistent/ misleading airctl status during DU upgrade.

Workaround: Set the airctl status manually airctl advanced-ddu reset-taskstate, if airctl status shows only 33/ 34 services ready and kubectl get pods | grep pf9-capi-controller shows that this pod is not healthy.

Known Issue On Ubuntu 22: When systemd-resolved is disabled, the symbolic link /etc/resolv.conf pointing to /run/systemd/resolve/stub-resolv.conf does not recover after a node reboot on the management cluster.

Impact: In an environment having no DNS server available, DNS information in the /etc/resolv.conf doesn't recover, this results in the DNS resolution failure hence the cluster won't recover.

Workaround: To ensure DNS functionality persists after a reboot, follow these steps before a node is rebooted.

• Remove the symbolic link /etc/resolv.conf (sudo rm /etc/resolv.conf ) . Manually create a new /etc/resolv.conf ( sudo nano /etc/resolv.conf ) with the required DNS entries. This step is particularly important if no DNS server is running in the cluster.
• Add the following DNS entries (replace with your preferred DNS servers if needed):
  • nameserver <node_ip>

SMCP 5.11 Kubernetes Components List

SMCP 5.11.1 Patch

2025-03-03

Features/Enhancements

This patch adds support for RHEL 8.10 and fixes the following issues with updated kube patches and a new release of pf9ctl CLI v1.31

Added Added support for RHEL 8.10

Added Added ability to modify the verbosity level for kube-api server

Fixed Fixed the issue that caused add-on operator to remove the custom cert manager objects on disabling Luigi and custom prometheus objects on disabling the pf9-monitoring add-on

Fixed Fixed a bug that exposed Kube-scheduler and kube-controller open to all interfaces

Known Issues

Same as known issues in SMCP 5.11.0