Alauda Container Platform

Core and Extensions

capabilities are delivered through Core and separately installed Extensions. Understanding this boundary helps you plan installation, upgrade, compatibility checks, and troubleshooting.

TOC

CoreExtension TypesLifecycle TypesCompatibility SourceDefault Extend BaselineCapability Boundaries

Core

Core is installed first and deploys the global cluster. It provides the platform management plane for web console access, platform API and CLI access, cluster management, project and namespace management, users and RBAC, Extension management frameworks, and core communication paths such as Cluster Proxy.

Core capabilities are installed with Core or are part of the platform management plane deployed with the global cluster. Capabilities that require a separate installation flow, Operator, Cluster Plugin, or separate product are not default Core functionality.

For installation scope, see Install Overview.

Extension Types

Extension is the umbrella term for the two main extension mechanisms in :

Extension typeTechnologyWhere installation is executedStart here
OperatorOperator Lifecycle Manager (OLM), OperatorHub, CatalogSource, Subscription, InstallPlan, and ClusterServiceVersion.In the target cluster where the Operator runs.Operator
Cluster PluginModulePlugin, ModuleConfig, and ModuleInfo custom resources.YAML-based installation creates ModuleInfo in the global cluster; the plugin target depends on affinity and configuration.Cluster Plugin

OperatorHub is the interface for discovering, installing, upgrading, and managing Operators. Cluster Plugins are published to the global cluster and installed through the platform according to each plugin's configuration and affinity.

For the Extension section, see Extend.

Lifecycle Types

Operators and Cluster Plugins use the same lifecycle model:

LifecycleMeaningUpgrade behavior
CoreFollows the Core release and cluster Distribution Version.Updated by upgrading the cluster. Standalone upgrade is not supported.
AlignedFollows the release stream but can be updated independently when a compatible version is published.Can be upgraded independently when the exact version is compatible.
AgnosticReleased independently from .Can be upgraded independently when the exact version is compatible.

Cluster Plugins expose this model through the cpaas.io/lifecycle-type label. For Operators, check compatibility through the Customer Portal metadata, Extension documentation, or release guidance instead of expecting every lifecycle label to be visible in the product interface.

For Cluster Plugin details, see Cluster Plugin.

Compatibility Source

For a specific Operator or Cluster Plugin version, use the Customer Portal ACP compatible versions field as the compatibility authority. If the exact version lists 4.3, that version supports 4.3.

Use product documentation for each Extension to understand capabilities, installation steps, upgrade steps, limitations, and known issues. Release notes are useful for version changes, but they are not the primary compatibility source for every specific Extension version. The Kubernetes support matrix explains Kubernetes compatibility and the default Extend baseline; it is not a complete compatibility matrix for every Operator or Cluster Plugin.

For package handling, see Upload Packages and Download Packages.

Default Extend Baseline

For 4.3, product validation for the default Extend baseline covers:

  • Installing and using Operators.
  • Installing and using Cluster Plugins.
  • ClickHouse-based logging.
  • VictoriaMetrics-based monitoring.

This baseline does not mean every specific Operator or Cluster Plugin is validated for every Kubernetes version, provider, third-party cluster, CPU architecture, runtime, or disconnected scenario. Check the exact Extension version and its own documentation before installation or upgrade.

Capability Boundaries

Use these boundaries when planning installation, upgrade, and operations:

Capability areaHow to read it
RegistryThe platform can provide registry entry points and registry-related workflows. Registry plugins, backends, backup, and recovery have their own installation and operational boundaries.
ObservabilityCentralized observability depends on installed monitoring, logging, event, tracing, or inspection components. Provider and connectivity caveats apply to third-party clusters.
AuditAudit uses platform audit views and depends on logging service components. Third-party provider audit data is not universally available.
Security and complianceAuthentication, RBAC, NetworkPolicy, API filtering, compliance features, and security products have separate component boundaries and installation requirements.
Separate products and independently installed capabilitiesService Mesh, AI, Hyperflux, Data Services, Cost Management, DevOps, Container Security, Compliance Service, GitOps, Logging Service, Immutable Infrastructure, Hosted Control Plane, and Cluster Authentication are not default Core functionality. Check the corresponding documentation before planning installation, upgrade, compatibility, or limitations.

For a task-oriented route map, see Learn More.