Enhancements¶
This section outlines new features and enhancements introduced in the Container Cloud release 2.28.0. For the list of enhancements delivered with the Cluster releases introduced by Container Cloud 2.28.0, see 17.3.0 and 16.3.0.
General availability for Ubuntu 22.04 on MOSK clusters¶
Implemented full support for Ubuntu 22.04 LTS (Jammy Jellyfish) as the default host operating system in MOSK clusters, including greenfield deployments and update from Ubuntu 20.04 to 22.04 on existing clusters.
Ubuntu 20.04 is deprecated for greenfield deployments and supported during the MOSK 24.3 release cycle only for existing clusters.
Warning
During the course of the Container Cloud 2.28.x series, Mirantis highly recommends upgrading an operating system on your cluster machines to Ubuntu 22.04 before the next major Cluster release becomes available. It is not mandatory to upgrade all machines at once. You can upgrade them one by one or in small batches, for example, if the maintenance window is limited in time.
Otherwise, the Cluster release update of the Ubuntu 20.04-based clusters will become impossible as of the Cluster releases introduced in Container Cloud 2.29.0 (Cluster releases 17.4.0 and 16.4.0) with Ubuntu 22.04 as the only supported version.
Note
Since Container Cloud 2.27.0 (Cluster release 16.2.0), existing MOSK management clusters were automatically updated to Ubuntu 22.04 during cluster upgrade. Greenfield deployments of management clusters are also based on Ubuntu 22.04.
Day-2 operations for bare metal: updating modules¶
TechPreview
Implemented the capability to update custom modules using deprecation. Once
you create a new custom module, you can use it to deprecate another module
by adding the deprecates
field to metadata.yaml
of the new module.
The related HostOSConfiguration
and HostOSConfigurationModules
objects
reflect the deprecation status of new and old modules using the corresponding
fields in spec
and status
sections.
Also, added monitoring of deprecated modules by implementing the StackLight
metrics for the Host Operating System Modules Controller along with the
Day2ManagementControllerTargetDown
and Day2ManagementDeprecatedConfigs
alerts to notify the cloud operator about detected deprecations and issues with
host-os-modules-controller
.
Note
Deprecation is soft, meaning that no actual restrictions are applied to the usage of a deprecated module.
Caution
Deprecating a version automatically deprecates all lower SemVer versions of the specified module.
Day-2 operations for bare metal: configuration enhancements for modules¶
TechPreview
Introduced the following configuration enhancements for custom modules:
- Module-specific Ansible configuration
Updated the Ansible execution mechanism for running any modules. The default
ansible.cfg
file is now placed in/etc/ansible/mcc.cfg
and used for execution oflcm-ansible
and day-2 modules. However, if a module has its ownansible.cfg
in the module root folder, such configuration is used for the module execution instead of the default one.
- Configuration of supported operating system distribution
Added the
supportedDistributions
to themetadata
section of a module custom resource to define the list of supported operating system distributions for the module. This field is informative and does not block the module execution on machines running non-supported distributions, but such execution will be most probably completed with an error.
- Separate flag for machines requiring reboot
Introduced a separate
/run/day2/reboot-required
file for day-2 modules to add a notification about required reboot for a machine and a reason for reboot that appear after the module execution. The feature allows for separation of the reboot reason between LCM and day-2 operations.
Update group for controller nodes¶
TechPreview
Implemented the update group for controller nodes using the UpdateGroup
resource, which is automatically generated during initial cluster creation with
the following settings:
Name:
<cluster-name>-control
Index:
1
Concurrent updates:
1
This feature decouples the concurrency settings from the global cluster level and provides update flexibility.
All control plane nodes are automatically assigned to the control update group with no possibility to change it.
Note
On existing clusters created before 2.28.0 (Cluster releases 17.2.0, 16.2.0, or earlier), the control update group is created after upgrade of the Container Cloud release to 2.28.0 (Cluster release 16.3.0) on the management cluster.
Reboot of machines using update groups¶
TechPreview
Implemented the rebootIfUpdateRequires
parameter for the UpdateGroup
custom resource. The parameter allows for rebooting a set of controller or
worker machines added to an update group during a Cluster release update that
requires a reboot, for example, when kernel version update is available in the
target Cluster release. The feature reduces manual intervention and overall
downtime during cluster update.
Note
By default, rebootIfUpdateRequires
is set to false
on managed
clusters and to true
on management clusters.
Self-diagnostics for management and managed clusters¶
Implemented the Diagnostic Controller that is a tool with a set of diagnostic checks to perform self-diagnostics of any Container Cloud cluster and help the operator to easily understand, troubleshoot, and resolve potential issues against the following major subsystems: core, bare metal, Ceph, StackLight, Tungsten Fabric, and OpenStack. The Diagnostic Controller analyzes the configuration of the cluster subsystems and reports results of checks that contain useful information about cluster health.
Running self-diagnostics on both management and managed clusters is essential to ensure the overall health and optimal performance of your cluster. Mirantis recommends running self-diagnostics before cluster update, node replacement, or any other significant changes in the cluster to prevent potential issues and optimize maintenance window.
Configuration of groups in auditd¶
TechPreview
Simplified the default auditd configuration by implementing the preset
groups
that you can use in presetRules
instead of exact names or the
virtual group all
. The feature allows enabling a limited set of presets
using a single keyword (group name).
Also, optimized disk usage by removing the following Docker rule that was removed from the Docker CIS Benchmark 1.3.0 due to producing excessive events:
# 1.2.4 Ensure auditing is configured for Docker files and directories - /var/lib/docker
-w /var/lib/docker -k docker
Amendments for the ClusterUpdatePlan object¶
TechPreview
Enhanced the ClusterUpdatePlan
object by adding a separate update step for
each UpdateGroup
of worker nodes of a managed cluster. The feature allows
the operator to granularly control the update process and its impact on
workloads, with the option to pause the update after each step.
Also, added several StackLight alerts to notify the operator about the update progress and potential update issues.
Refactoring of delayed auto-update of a management cluster¶
Refactored the MCCUpgrade
object by implementing a new mechanism to delay
Container Cloud release updates. You now have the following options for
auto-update of a management cluster:
Automatically update a cluster on the publish day of a new release (by default).
Set specific days and hours for an auto-update allowing delays of up to one week. For example, if a release becomes available on Monday, you can delay it until Sunday by setting Sunday as the only permitted day for auto-updates.
Delay auto-update for minimum 20 days for each newly discovered release. The exact number of delay days is set in the release metadata and cannot be changed by the user. It depends on the specifics of each release cycle and on optional configuration of week days and hours selected for update.
You can verify the exact date of a scheduled auto-update either in the Status section of the Management Cluster Updates page in the web UI or in the
status
section of theMCCUpgrade
object.Combine auto-update delay with the specific days and hours setting (two previous options).
Also, optimized monitoring of auto-update by implementing several StackLight
metrics for the kaas-exporter
job along with the MCCUpdateBlocked
and
MCCUpdateScheduled
alerts to notify the cloud operator about new releases
as well as other important information about management cluster auto-update.
Container Cloud web UI enhancements for the bare metal provider¶
Refactored and improved UX visibility as well as added the following functionality for the bare metal managed clusters in the Container Cloud web UI:
Reworked the Create Subnets page:
Added the possibility to delete a subnet when it is not used by a cluster
Changed the default value of Use whole CIDR from
true
tofalse
Added storage subnet types: Storage access and Storage replication
Added the MetalLB Configs tab with configuration fields for MetalLB on the Networks page
Optimized the Create new machine form
Replicated the Create Credential form on the Baremetal page for easy access
Added the Labels fields to the Create L2 template and Create host profile forms as well as optimized uploading of specification data for these objects
Learn more
Documentation enhancements¶
On top of continuous improvements delivered to the existing Container Cloud
guides, added documentation on how to run Ceph performance tests using
Kubernetes batch or cron jobs that run
fio
processes according to a predefined KaaSCephOperationRequest
CR.