Update notes¶
This section describes the specific actions you as a cloud operator need to complete before or after your Container Cloud cluster update to the Cluster releases 17.1.5 or 16.1.5.
Consider this information as a supplement to the generic update procedures published in Operations Guide: Automatic upgrade of a management cluster and Update a managed cluster.
Update scheme for patch Cluster releases¶
To improve user update experience and make the update path more flexible, Container Cloud is introducing a new scheme of updating between patch Cluster releases. More specifically, Container Cloud intends to ultimately provide a possibility to update to any newer patch version within single series at any point of time. The patch version downgrade is not supported.
Though, in some cases, Mirantis may request to update to some specific patch version in the series to be able to update to the next major series. This may be necessary due to the specifics of technical content already released or planned for the release. For possible update paths in MOSK in 24.1 and 24.2 series, see MOSK documentation: Cluster update scheme.
The exact number of patch releases for the 16.1.x and 17.1.x series is yet to be confirmed, but the current target is 7 releases.
Note
The management cluster update scheme remains the same. A management cluster obtains the new product version automatically after release.
See also
MOSK documentation:
Post-update actions¶
Delete ‘HostOSConfiguration’ objects on baremetal-based clusters¶
If you use the HostOSConfiguration
and HostOSConfigurationModules
custom resources for the bare metal provider, which are available in the
Technology Preview scope in Container Cloud 2.26.x, delete all
HostOSConfiguration
objects right after update of your managed cluster to
the Cluster release 17.1.5 or 16.1.5, before automatic upgrade of the
management cluster to Container Cloud 2.27.0 (Cluster release 16.2.0).
After the upgrade, you can recreate the required objects using the updated
parameters.
This precautionary step prevents re-processing and re-applying of existing
configuration, which is defined in HostOSConfiguration
objects, during
management cluster upgrade to 2.27.0. Such behavior is caused by changes in
the HostOSConfiguration
API introduced in 2.27.0.
Configure Kubernetes auditing and profiling for log rotation¶
Note
Skip this procedure if you have already completed it after updating your managed cluster to Container Cloud 2.26.4 (Cluster release 17.1.4 or 16.1.4).
After the MKE update to 3.7.8, if you are going to enable or already enabled Kubernetes auditing and profiling on your managed or management cluster, keep in mind that enabling audit log rotation requires an additional step. Set the following options in the MKE configuration file after enabling auditing and profiling:
[cluster_config]
kube_api_server_audit_log_maxage=30
kube_api_server_audit_log_maxbackup=10
kube_api_server_audit_log_maxsize=10
For the configuration procedure, see MKE documentation: Configure an existing MKE cluster.
While using this procedure, replace the command to upload the newly edited MKE configuration file with the following one:
curl --silent --insecure -X PUT -H "X-UCP-Allow-Restricted-API: i-solemnly-swear-i-am-up-to-no-good" -H "accept: application/toml" -H "Authorization: Bearer $AUTHTOKEN" --upload-file 'mke-config.toml' https://$MKE_HOST/api/ucp/config-toml
The value for
MKE_HOST
has the<loadBalancerHost>:6443
format, whereloadBalancerHost
is the corresponding field in the cluster status.The value for
MKE_PASSWORD
is taken from theucp-admin-password-<clusterName>
secret in the cluster namespace of the management cluster.The value for
MKE_USERNAME
is alwaysadmin
.