llms.txt

# Alauda Container Platform Documentation

> ACP (Alauda Container Platform) product documentation covering platform features and operations

Documentation for Alauda Container Platform, built with Node.js and MDX.
Includes CRD definitions and comprehensive platform guides.


## ai

- [docs/en/ai/about.mdx](docs/en/ai/about.mdx): Introduces Alauda AI as an MLOps platform for large model applications, AI applications, and machine learning, supporting model storage and versioning, model and reasoning service release, and agent/AI application orchestration. Embeds the dedicated Alauda AI external documentation site.

## appservice

- [docs/en/appservice/installation.mdx](docs/en/appservice/installation.mdx): Installation procedure for the Data Services view stack: Alauda Container Platform Data Services Essentials (web-console foundation, installed on `global`), the RDS Framework (foundational base operator from OperatorHub), and per-engine business plugins (Alauda Database Service for MySQL, Alauda Cache Service for Redis OSS, Alauda Streaming Service for Kafka/Kafka 2, Alauda Streaming Service for RabbitMQ, PostgreSQL, Alauda Build of Keycloak). Each tab gives the OperatorHub install flow with recommended Channel/Version/Cluster install mode/manual upgrade strategy.
- [docs/en/appservice/kafka/kafka.mdx](docs/en/appservice/kafka/kafka.mdx): Product overview for Alauda Streaming Service for Kafka, a Kubernetes-based distributed stream processing platform/message queue used for log collection, event-driven architectures, real-time analytics, and data integration. Embeds the dedicated Kafka external documentation site.
- [docs/en/appservice/keycloak/keycloak.mdx](docs/en/appservice/keycloak/keycloak.mdx): Product overview for Alauda Build of Keycloak, an identity and access management solution on Kubernetes that provides SSO, user federation, identity brokering, and social login over OpenID Connect, OAuth 2.0, and SAML 2.0. Embeds the dedicated Keycloak external documentation site.
- [docs/en/appservice/mysql/mgr.mdx](docs/en/appservice/mysql/mgr.mdx): Product overview for Alauda Database Service for MySQL-MGR, a Kubernetes-based high-availability MySQL solution that automates deployment and lifecycle management of MySQL Group Replication clusters. Embeds the dedicated MySQL-MGR external documentation site at `/intro`.
- [docs/en/appservice/mysql/pxc.mdx](docs/en/appservice/mysql/pxc.mdx): Product overview for Alauda Database Service for MySQL-PXC, a Kubernetes-based high-availability MySQL solution using synchronous replication based on Percona XtraDB Cluster, with automated deployment, scaling, and lifecycle management of PXC instances. Embeds the dedicated MySQL-PXC external documentation site at `/intro`.
- [docs/en/appservice/overview/architecture.mdx](docs/en/appservice/overview/architecture.mdx): Architecture overview of the Alauda Application Services platform built on Kubernetes, with layered components (Container Infrastructure, Operator Controller, Common Services such as parameter templates/inspection/alerts/backup, and Service Components MySQL/Redis/Kafka/RabbitMQ). Includes a compatibility matrix listing supported versions (MySQL-PXC 5.7, MySQL-MGR 8.0, Redis 5.0/6.0/7.2, Kafka 3.8, RabbitMQ 3.8.16/3.12.4, PostgreSQL 11/12/14), recommended TopoLVM persistence, S3 backup storage class, and per-engine node scheduling rules.
- [docs/en/appservice/overview/intro.mdx](docs/en/appservice/overview/intro.mdx): Brief introduction positioning the Alauda Application Services platform as a Kubernetes-based service management solution for developers and operators that unifies deployment, management, and visual operation of database, cache, and messaging services.
- [docs/en/appservice/postgresql/cnpg.mdx](docs/en/appservice/postgresql/cnpg.mdx): Product overview of Alauda support for CloudNativePG: the Alauda-packaged distribution of the upstream CNCF Sandbox CloudNativePG operator, which uses Kubernetes primitives instead of Patroni+etcd/ZooKeeper for primary/standby coordination. Supports PostgreSQL 14-18 in `standard` and `minimal` container variants (amd64/arm64), adds air-gapped mirror-registry images (operator, PostgreSQL, extensions, PgBouncer), tolerates ACP admission image rewriting, applies L5 RBAC, and ships via `violet push` to the platform's OLM catalog source.
- [docs/en/appservice/postgresql/pg.mdx](docs/en/appservice/postgresql/pg.mdx): Product overview for Alauda support for PostgreSQL, a cloud-native PostgreSQL management solution built on the Zalando Postgres Operator. Provides full lifecycle management of PostgreSQL clusters through CRDs, including automatic failover, rolling upgrades, and backup restoration. Embeds the dedicated PostgreSQL external documentation site at `/intro`.
- [docs/en/appservice/rabbitmq/rabbitmq.mdx](docs/en/appservice/rabbitmq/rabbitmq.mdx): Product overview for Alauda Streaming Service for RabbitMQ, a Kubernetes-deployed AMQP message broker used as an asynchronous communication bridge for building decoupled, scalable distributed systems. Embeds the dedicated RabbitMQ external documentation site at `/intro`.
- [docs/en/appservice/redis/redis.mdx](docs/en/appservice/redis/redis.mdx): Product overview for Alauda Cache Service for Redis OSS, an in-memory data store supporting strings, hashes, lists, sets, and sorted sets, with persistence, high availability, and distributed clustering. Targets caching, message queue, and real-time analytics scenarios. Embeds the dedicated Redis external documentation site at `/intro`.
- [docs/en/appservice/unified-om/alert-policy-mgt/functions/link_to_alert.mdx](docs/en/appservice/unified-om/alert-policy-mgt/functions/link_to_alert.mdx): Explains how the Alert Center under the Data Services view relates to the platform's broader Alert Management capability: it is a subset of platform alerts focused on Application Service resources, and Data Services and Platform Management alerts are data-isolated (a policy created under Data Services can only be managed there). Points to `/observability/monitor/functions/manage_alert.mdx` for the cross-platform reference.
- [docs/en/appservice/unified-om/alert-policy-mgt/intro.mdx](docs/en/appservice/unified-om/alert-policy-mgt/intro.mdx): Conceptual introduction to alert policy management for instances, describing Metric Alerts vs Custom Alerts, alert templates for standardizing rules across similar instances, alert states (Alert / Pending / Normal), silent states (Silent Pending / Silent), real-time alert dashboards, and alert history (retention tied to the platform's log storage configuration).
- [docs/en/appservice/unified-om/backup-mgt/functions/backup_list.mdx](docs/en/appservice/unified-om/backup-mgt/functions/backup_list.mdx): Walkthrough of the Backup Management UI in the Data Services view: viewing per-instance backup status by project/namespace (automatic backup toggle, success/failure counts, last result, storage location), opening backup history, performing restore (default `Recovery` to a new instance; MGR also supports restore-to-existing), and bulk-deleting backup records (irreversible).
- [docs/en/appservice/unified-om/backup-mgt/functions/register_s3.mdx](docs/en/appservice/unified-om/backup-mgt/functions/register_s3.mdx): How to register external S3 object storage as a backup target in the Data Services Backup Center: required fields (Endpoint URL, Access Key, Secret Access Key, Bucket Name), automatic and manual connectivity checks against the registered bucket, and use of the registered storage by automatic or instant backup tasks.
- [docs/en/appservice/unified-om/backup-mgt/intro.mdx](docs/en/appservice/unified-om/backup-mgt/intro.mdx): Introduces the Data Services Backup Center as the cross-instance hub for backup and recovery, with filtering by component type/namespace/keyword, viewing backup history, performing recovery, and centralized lifecycle management of external object-storage targets (register, update, delete access keys).
- [docs/en/appservice/unified-om/inspection-mgt/functions/create_inspection_task.mdx](docs/en/appservice/unified-om/inspection-mgt/functions/create_inspection_task.mdx): How to create an Inspection CR (`middleware.alauda.io/v1` kind `Inspection`) targeting a component such as `mysqlcluster` and one or more instances (or wildcard `*`), with `trigger` set to `Manual` or `Schedule` (cron expression in `spec.schedule`) and `jobsHistoryLimit` controlling retained inspection records. Includes equivalent web-console flow under Tasks > Create Tasks.
- [docs/en/appservice/unified-om/inspection-mgt/functions/run_inspection_task.mdx](docs/en/appservice/unified-om/inspection-mgt/functions/run_inspection_task.mdx): How to execute an inspection task manually or on schedule and where results surface: an `InspectionJob` (kind `InspectionJob`) carries `status.results[]` with per-instance `healthyStatus` (e.g. `HealthyWithWarning`), start/stop times, and status. Web console exposes an `Inspection` button on each instance detail page and an `Execute immediately` action in the inspection Task list.
- [docs/en/appservice/unified-om/inspection-mgt/functions/update_inspection_task.mdx](docs/en/appservice/unified-om/inspection-mgt/functions/update_inspection_task.mdx): How to update or delete inspection tasks: `kubectl edit` on the `Inspection` CR (only `spec` fields are mutable) and `kubectl delete -n <ns> inspection <name>`. Deleting an Inspection automatically cascades and deletes its associated `inspectionjob`.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Kafka/cpu.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Kafka/cpu.mdx): Tuning recipe for high CPU on Kafka brokers: adjust `num.network.threads` / `num.io.threads`, enable producer batching via `batch.size`/`linger.ms`, tune consumer pulls with `fetch.min.bytes`/`fetch.max.wait.ms`, set `compression.type` (disable when CPU-bound), set JVM heap (`-Xms`/`-Xmx`) via `spec.kafka.jvmOptions`, and scale brokers to spread connection load.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Kafka/memory.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Kafka/memory.mdx): Tuning recipe for Kafka memory usage: cap `message.max.bytes`, set conservative JVM `-Xms`/`-Xmx` in `spec.kafka.jvmOptions`, use consumer groups to spread consumers, size topics and partitions to actual demand, and scale brokers to reduce per-broker partition/replica counts.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Kafka/rebalance.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Kafka/rebalance.mdx): Explains causes of Kafka consumer rebalances (heartbeat timeouts, `max.poll.interval.ms` overruns, scale-up/scale-down) and remediations: tune `max.poll.interval.ms`, `session.timeout.ms`, `heartbeat.interval.ms`, avoid long per-partition processing, use static membership via `group.instance.id`, and monitor rebalance frequency/duration.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Kafka/storage.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Kafka/storage.mdx): Tuning recipe for Kafka storage pressure: target 50-70% disk usage, configure `log.cleanup.policy` (`delete`/`compact`), tune `log.retention.hours`/`log.retention.bytes`/`log.segment.bytes`/`log.roll.hours`, select a `compression.type` (`zstd`/`lz4`/`snappy`/`gzip`) per the throughput-vs-compression-ratio trade-off, and monitor metrics like `log.log_end_offset`.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/MySQL/io.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/MySQL/io.mdx): Optimization guide for high InnoDB I/O: increase `innodb_log_file_size`, tune dirty-page flushing (`innodb_max_dirty_pages_pct`, `innodb_max_dirty_pages_pct_lwm`, `innodb_io_capacity`, `innodb_io_capacity_max`, `innodb_lru_scan_depth`), investigate `/var/lib/mysql/#innodb_temp` for runaway temp tables, watch buffer-pool hit rate via `INNODB_BUFFER_POOL_STATS`, schedule DDL during off-peak, and split large transactions to reduce binlog write spikes.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/MySQL/memory.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/MySQL/memory.mdx): Diagnosis recipes (using `sys.memory_global_total`, `performance_schema.memory_summary_*`, `x$memory_global_by_current_bytes`) and remediations for MySQL memory pressure: avoid huge multi-statement SQL, scale `innodb_buffer_pool_instances`, manage temp-table size (`tmp_table_size`, `max_heap_table_size`, `temptable_max_ram`), reduce MGR `group_replication_message_cachesize`, tune `table_open_cache`, and consider disabling the Adaptive Hash Index.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/MySQL/rowlock.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/MySQL/rowlock.mdx): Diagnoses row-lock waits via `show status like 'Innodb_row_lock_%'` (current waits, total/avg/max wait time) and recommends fixes: optimize hot updates, paginate large operations, tune `innodb_lock_wait_timeout`/`interactive_timeout`, use `innodb_print_all_deadlocks` selectively, add precise indexes to avoid table-lock escalation, and minimize gap-lock-inducing range queries and transaction scope.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/MySQL/storage.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/MySQL/storage.mdx): Recommendations for MySQL space-usage problems at 80-85% threshold: control binlog retention, prune redundant secondary indexes, swap BLOB/TEXT/long VARCHAR for JSON or external stores, defragment InnoDB tables via `optimize table`, and watch for `Using Temporary` execution plans that bloat temporary tablespace.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/MySQL/thread.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/MySQL/thread.mdx): How to investigate high MySQL active-thread counts using `show status like 'Threads%'` (`Threads_connected`, `Threads_running`) and resolve common causes: slow-query queue buildup (kill via `show processlist`), insufficient `table_open_cache` causing `Opening table` waits, metadata-lock (MDL) blocking by uncommitted transactions or DDL, and InnoDB row-lock conflicts surfaced through `show engine innodb status`.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/RabbitMQ/mnesia.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/RabbitMQ/mnesia.mdx): Troubleshooting guide for RabbitMQ Mnesia database failures: fixing MNESIA_BASE write-permission errors, recovering from hostname or `rabbit@hostname` directory renames, and breaking restart deadlocks where pods wait indefinitely for cluster peers by running `kubectl -n <ns> exec <instance> -- rabbitmqctl force_boot`.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Redis/bigkey.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Redis/bigkey.mdx): Defines Redis BigKey thresholds per type (string >5MB; list >20k elements; set >5k; zset >10k; hash >1k fields), uses `redis-cli --bigkeys` to identify them, and prescribes per-type splitting recipes using `GETRANGE/SETRANGE`, `LRANGE/RPUSH`, `SMEMBERS/SADD`, and `ZRANGE/ZADD`.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Redis/cpu.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Redis/cpu.mdx): Troubleshooting recipe for high Redis CPU: check `info`/Monitoring/Pod metrics, validate `maxmemory` and persistence (AOF) configuration, use `slowlog get` with `slowlog-log-slower-than`/`slowlog-max-len` (default >20ms) to find slow `KEYS`/`LRANGE`/`EVAL`/`HGETALL` queries, audit hot/big keys, watch cluster traffic skew, and apply architecture remedies like sharding, read-only sentinel replicas, or multi-threading.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Redis/memory.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_optimization/Redis/memory.mdx): Troubleshooting high Redis memory usage: monitor `MemoryUsed`, `MemFragmentationRatio`, `MemoryUsed,Peak` and `MemoryMax`, use the `memory stats` command for breakdown, choose an appropriate `maxmemory-policy` (`volatile-lru`/`volatile-lfu`/`volatile-ttl`/`volatile-random`/`allkeys-lru`/`allkeys-lfu`/`allkeys-random`/`noeviction`), set key expirations, keep `maxmemory` <=80% of instance memory, and avoid big keys.
- [docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_policy.mdx](docs/en/appservice/unified-om/inspection-mgt/how_to/inspection_policy.mdx): Reference for the Inspection scheduling field: it uses a Crontab expression evaluated in UTC, so users must convert from local time (Beijing is UTC+8 with examples), and includes the five-field syntax (Minute Hour Day Month Week), supported special characters (`,`, `-`, `*`, `/`), and worked examples like `30 18 25 12 *` and `0,30 18-23 * * *`.
- [docs/en/appservice/unified-om/inspection-mgt/intro.mdx](docs/en/appservice/unified-om/inspection-mgt/intro.mdx): Introduces the Inspection Center for middleware operated by Application Services: supports manual and scheduled (periodic or one-shot) inspections, generates reports and recent overviews, provides diagnoses and optimization suggestions for detected anomalies, and supports exporting reports.
- [docs/en/appservice/unified-om/inst-upgrade-mgt/functions/batch_upgrade.mdx](docs/en/appservice/unified-om/inst-upgrade-mgt/functions/batch_upgrade.mdx): Walks through the Instance Upgrade Center UI: view the Operator list with deployment mode/scope/status/version filtered by cluster, drill into an Operator's instance list (only the current project/cluster), and trigger a batch rolling upgrade where selected instances transition `Progressing` -> `Running` in an unspecified Kubernetes-driven order.
- [docs/en/appservice/unified-om/inst-upgrade-mgt/intro.mdx](docs/en/appservice/unified-om/inst-upgrade-mgt/intro.mdx): Introduces the Instance Upgrade Management Center for Application Services instances, focused on patch-version upgrade management: groups instances by component type under their Operators, surfaces upgrade notifications when patches are available, and supports batch upgrades. Major/minor upgrades happen via the Update flow instead and only show supported versions.
- [docs/en/appservice/unified-om/intro.mdx](docs/en/appservice/unified-om/intro.mdx): Overview of the Unified Operations Management module, which bundles Parameter Template Management, Backup Management, Inspection Management, Alert Management, and Upgrade Management for Application Services components: lists the benefits of each (pre-built parameter templates, filtered backup operations, automated inspection schedules, customizable alert strategies, low-impact batch upgrades).
- [docs/en/appservice/unified-om/para-template-mgt/functions/param-templates.mdx](docs/en/appservice/unified-om/para-template-mgt/functions/param-templates.mdx): How to use the Parameter Template feature for MySQL (PXC and MGR), Redis, and Kafka: browse the platform's pre-configured and user-defined templates, view template details (name/type/component/description/parameter list), create custom templates (with batch import using `Parameter Value` line format), and export templates as text files for sharing.
- [docs/en/appservice/unified-om/para-template-mgt/intro.mdx](docs/en/appservice/unified-om/para-template-mgt/intro.mdx): Brief introduction to the Parameter Template module that centralizes management of component parameters via system-predefined and user-defined templates, improving configuration standardization across Application Services components.
- [docs/en/appservice/upgrade.mdx](docs/en/appservice/upgrade.mdx): Upgrade procedure for the Data Services view: Alauda Container Platform Data Services Essentials is upgraded manually from Marketplace > Cluster Plugins; the RDS Framework upgrades follow its configured Automatic/Manual strategy. Warns that upgrading ACP v3 -> v4 should be done in lockstep for `global` and workload clusters or the Data Services view may not render correctly in unupgraded workload clusters.

## configure

- [docs/en/configure/backup/application/backup-app.mdx](docs/en/configure/backup/application/backup-app.mdx): Procedure for creating an application backup policy under Clusters > Backup and Recovery: select Kubernetes resources and/or PVCs (warns against backing up database PVCs - use Data Services - and `hostPath` PVCs are unsupported), choose a Backup Repository, filter namespaces and resource types (included/excluded namespace and cluster-scoped resources, label selectors via `matchLabels`/`matchExpressions` mapped to Velero's `orLabelSelectors`), schedule as `Backup once only` or `Scheduled` (crontab), configure retention, and optionally add hooks. Also documents Execute Backup manual runs and Export Log.
- [docs/en/configure/backup/application/hooks.mdx](docs/en/configure/backup/application/hooks.mdx): Reference for custom backup and restore hooks supported by the Velero-based backup component: backup hooks (`pre`/`post` exec) configured under `.spec.template.spec.hooks` (schedule) or `.spec.hooks` (backup) with `includedNamespaces`/`excludedNamespaces`/`labelSelector`/`onError`/`timeout`, and restore hooks (`init` containers via `postHooks.init.initContainers` and `exec` actions) set under `.spec.hooks` of the restore resource.
- [docs/en/configure/backup/application/repository.mdx](docs/en/configure/backup/application/repository.mdx): How to create and manage a Backup Repository under Clusters > Backup and Recovery: configures S3-compatible object storage (Region, Addressing Style virtual-hosted vs path-based, Endpoint - warns against using the public bucket domain, Bucket, Folder, Secret Id/Secret Key, Skip TLS Verify, Base64 CA certificate). Notes that deleting a repository referenced by a backup schedule will break it.
- [docs/en/configure/backup/application/restore-app.mdx](docs/en/configure/backup/application/restore-app.mdx): Procedure for executing an application recovery task: pick a repository and backup record, restore into the original namespace or a new one via Advanced Recovery Target Settings, map source/target StorageClasses when names differ, optionally enable overwrite via YAML edit (`existingResourcePolicy: update`, exclude `pods`), and reconcile PV `claimRef` UID/resourceVersion when the reclaim policy is `Retain`. Documents prerequisites for cross-cluster restore (shared object storage or pre-copied backup file), retry and log export.
- [docs/en/configure/backup/application/restore-imagesync.mdx](docs/en/configure/backup/application/restore-imagesync.mdx): Procedure to redirect application images during cross-cluster/cross-platform restore by creating a `change-registry-config` ConfigMap in `cpaas-system` (labels `velero.io/plugin-config: ""` and `alauda.io/change-registry: RestoreItemAction`) mapping `old:` -> `new:` registry addresses, then running the restore task.
- [docs/en/configure/backup/etcd.mdx](docs/en/configure/backup/etcd.mdx): Reference and procedure for etcd backup and restore via the Alauda Container Platform Cluster Enhancer plugin, which creates an `EtcdBackupConfiguration` CR (`enhancement.cluster.alauda.io/v1`) with `schedule`, `paused`, `localStorage.path`/`ttl`, and optional `remoteStorage.s3` (endpoint/region/bucket/dir/skipTLSVerify/secretRef). Immutable OS clusters require S3. Includes status checks via `kubectl get etcdbackupconfiguration` (status.records), manual trigger via the `/exec` API endpoint, and a full disaster-recovery procedure for a 3-node control plane using `etcdctl snapshot restore`, etcd.yaml edits, and crictl/kubelet restart sequences.
- [docs/en/configure/backup/overview.mdx](docs/en/configure/backup/overview.mdx): Overview of ACP backup categories: cluster backup (etcd, registry, logging via ClickHouse, monitoring via VictoriaMetrics) and application backup based on Velero. The Velero stack has Alauda Container Platform Data Backup Essentials (UI, on `global`) and Alauda Container Platform Data Backup for Velero (workload clusters). Discusses why VM snapshots are unsuitable for Immutable OS clusters and outlines cross-cluster migration considerations (CPU/memory parity, consistent network mode, subnet impact on pod IPs, image migration).
- [docs/en/configure/nodes/node_planning.mdx](docs/en/configure/nodes/node_planning.mdx): How to plan cluster node roles using the `node-role.kubernetes.io/<role>` label convention: distinguishes default `control-plane`/`master` and `worker` roles, and walks through labeling and tainting nodes (`kubectl label`, `kubectl taint ... NoSchedule`) to create `infra`/`log`/custom-role nodes on non-immutable clusters. Includes a Deployment example using matching `nodeSelector` and `tolerations` to schedule pods onto the dedicated nodes.
- [docs/en/configure/etcd/encryption.mdx](docs/en/configure/etcd/encryption.mdx): Operations guide for the etcd Encryption Manager plugin: installs an `etcd-encryption-manager` controller in `kube-system` that periodically rotates 256-bit AES-GCM keys for `secrets` and `configmaps` (default 168h, retains 8 keys, hot-reloads kube-apiserver, migrates re-encryption). Lists config files (`/etc/kubernetes/encryption-provider.conf` and history/`-bak/` paths) and the `EtcdEncryptionConfig` CR (`cluster.alauda.io/v1alpha1`) with `spec.resources`, `spec.rotationInterval`, `spec.type: aesgcm`, plus `status.deployStatus`/`status.migration`. Not supported on the `global` cluster.
- [docs/en/configure/clusters/how-to/access-cluster-with-kubeconfig.mdx](docs/en/configure/clusters/how-to/access-cluster-with-kubeconfig.mdx): Guide for two KubeConfig access paths to an ACP cluster: the platform-downloaded KubeConfig (10-year default validity, no CA replacement) and a token-based KubeConfig built around an ACP API token created from Profile > API Tokens. Includes step-by-step procedures for downloading and pointing `kubectl`/`ac` at the file, manually assembling a token-based KubeConfig with `server: https://<platform>/kubernetes/<cluster-name>` and `users[].user.token`, verifying with `kubectl auth can-i`, and dedicated-account patterns for pipelines/connectors.
- [docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx](docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx): Recipe for exposing the `global` cluster's Platform Built-in registry to workload clusters at a public domain: creates a TLS Secret `registry-address.tls` in `kube-system`, an `Ingress` (with `nginx.ingress.kubernetes.io/backend-protocol: HTTPS`) covering `/v2/`, `/auth/token`, `tags/list`, `manifests`, and `blobls` paths against the `registry` Service (port 443 -> targetPort 60080), and validates pulls via `crictl pull` or `podman pull`.
- [docs/en/configure/scalability/resource_manager_policies.mdx](docs/en/configure/scalability/resource_manager_policies.mdx): Procedure to enable kubelet CPU ManagerPolicy (`static`, `full-pcpus-only: true`, `cpuManagerReconcilePeriod`, `reservedSystemCPUs`), Memory ManagerPolicy (`Static` with per-NUMA `reservedMemory`), and Topology ManagerPolicy (`single-numa-node`, scope `pod`) in `/var/lib/kubelet/config.yaml`. Covers `reservedMemory` math (R_total = kubeReserved + systemReserved + evictionHard), the cordon/drain/clear-state/restart-kubelet rollout, and verification via `cpu_manager_state` and `memory_manager_state` JSON files.
- [docs/en/configure/clusters/how-to/update_public_repository_credentials.mdx](docs/en/configure/clusters/how-to/update_public_repository_credentials.mdx): Three-step recipe for refreshing the `public-registry-credential` Cloud Credential under Clusters > Cloud Credential by uploading a fresh authentication file downloaded from the Customer Portal so the cluster can pull from the Public Repository.
- [docs/en/configure/clusters/immutable-infra.mdx](docs/en/configure/clusters/immutable-infra.mdx): Overview and entry point for Immutable Infrastructure (Huawei DCS, VMware vSphere, Huawei Cloud Stack; bare-metal planned), where node configurations are baked into immutable OS images and changes happen by replacing nodes. Provides links to the external Immutable Infrastructure docs covering global cluster install/upgrade/DR, provider plugins, infrastructure resources, workload cluster creation/upgrade, node management, machine configuration, and API reference.
- [docs/en/configure/clusters/managed/cloud-init/network/aws-eks-lb.mdx](docs/en/configure/clusters/managed/cloud-init/network/aws-eks-lb.mdx): Supplemental AWS EKS load-balancer terminology and guidance covering eks-clb (default, not recommended due to UDP issues), eks-nlb, eks-alb, the in-cluster aws-lb controller, and the Platform Load Balancer. Documents the required service annotations to ensure the platform load balancer uses aws-lb (`service.beta.kubernetes.io/aws-load-balancer-type: external`, `aws-load-balancer-nlb-target-type: ip`, optional `aws-load-balancer-scheme: internet-facing`) and how the platform reads the assigned external address back from the LoadBalancer Service.
- [docs/en/configure/clusters/managed/cloud-init/network/aws-eks.mdx](docs/en/configure/clusters/managed/cloud-init/network/aws-eks.mdx): AWS EKS network bootstrap: deploys the AWS Load Balancer Controller (Helm chart `eks/aws-load-balancer-controller` v2.4.7), configures an OIDC provider via `eksctl utils associate-iam-oidc-provider`, attaches an IAM policy (`iam_policy.json`) and IRSA Service Account `aws-load-balancer-controller`. Walks through creating LoadBalancer Services and Ingresses (with annotations like `alb.ingress.kubernetes.io/scheme: internet-facing`, `alb.ingress.kubernetes.io/target-type: ip`), required subnet tags `kubernetes.io/role/elb` and `kubernetes.io/cluster/<name>: shared`, fetching ACCOUNT_ID via `aws sts get-caller-identity`, kubeconfig setup via `aws eks update-kubeconfig`, and HTTPS Secret creation.
- [docs/en/configure/clusters/managed/cloud-init/network/azure-aks.mdx](docs/en/configure/clusters/managed/cloud-init/network/azure-aks.mdx): Azure AKS network bootstrap: relies on default LoadBalancer Service support and optionally deploys the AKS Application Routing Nginx Ingress Controller via the Azure portal (Kubernetes Resources > Services and Ingresses > Create > Ingress (Preview)). Documents creating Ingresses (Ingress Class `webapprouting.kubernetes.azure.com`) and LoadBalancer Services in ACP, plus TLS Secret creation for HTTPS.
- [docs/en/configure/clusters/managed/cloud-init/network/google-gke.mdx](docs/en/configure/clusters/managed/cloud-init/network/google-gke.mdx): Google GKE network bootstrap: LoadBalancer Service and Ingress are supported by default with no extra Ingress Controller install needed (uses GKE Ingress, mapping Ingress resources to Google Cloud Load Balancers). Walks through creating Ingresses (`GKE Ingress Class`, expect ~5 minutes for the public IP) and LoadBalancer Services from the ACP UI, viewing them in Google Cloud > Kubernetes Engine > Services and Ingress, and creating TLS Secrets for HTTPS.
- [docs/en/configure/clusters/managed/cloud-init/network/huawei-cce.mdx](docs/en/configure/clusters/managed/cloud-init/network/huawei-cce.mdx): Huawei Cloud CCE network bootstrap: LoadBalancer Service and Ingress are supported by default. Documents two methods for creating Ingresses - either selecting `CCE Ingress Class` and adding ELB annotations (`kubernetes.io/elb.autocreate`, `kubernetes.io/elb.class: union` or `performance`, `kubernetes.io/elb.id`, `kubernetes.io/elb.port`) for shared/dedicated, auto-create vs reuse load balancer variants, or applying a default `IngressClass` `cce` with controller `alauda/cce`. Also covers LoadBalancer Service creation and HTTPS TLS Secrets.
- [docs/en/configure/clusters/managed/cloud-init/storage/aws-eks.mdx](docs/en/configure/clusters/managed/cloud-init/storage/aws-eks.mdx): AWS EKS storage bootstrap: deploys Amazon EFS CSI Driver and Amazon EBS CSI Driver, creates default StorageClasses `efs-sc` (provisioner `efs.csi.aws.com`, requires File System ID, mode `efs-ap`, `directoryPerms`) and `ebs-sc` (provisioner `ebs.csi.aws.com`, `WaitForFirstConsumer`, `allowVolumeExpansion`). Lists all EFS parameters (`basePath`, `uid/gid`, `gidRangeStart/End`, `subPathPattern`, `ensureUniqueDirectory`) and EBS parameters (`type` defaults to `gp3`, `iops`, `throughput`, `encrypted`, `kmsKeyId`, `csi.storage.k8s.io/fstype`). Notes A1-series ARM instances are incompatible (recommends Graviton2/3 alternatives).
- [docs/en/configure/clusters/managed/cloud-init/storage/azure-aks.mdx](docs/en/configure/clusters/managed/cloud-init/storage/azure-aks.mdx): Azure AKS storage bootstrap: after importing the cluster, default StorageClasses (`default`/`managed`/`managed-csi`/`managed-csi-premium`/`managed-premium` for block storage and `azurefile`/`azurefile-csi`/`azurefile-csi-nfs`/`azurefile-csi-premium`/`azurefile-premium` for file storage) are assigned to projects. Notes that the default `azurefile` class may not support permission modifications, breaking apps like PostgreSQL/Jenkins.
- [docs/en/configure/clusters/managed/cloud-init/storage/google-gke.mdx](docs/en/configure/clusters/managed/cloud-init/storage/google-gke.mdx): Google GKE storage bootstrap: requires enabling Compute Engine Persistent Disk CSI Driver and Filestore CSI Driver (and the Cloud Filestore API). Provisions default StorageClasses `standard-rwx` (file, Basic HDD Filestore), `standard-rwo` (block, balanced PD), with premium and enterprise tiers available. Covers PVC provisioning failures (Cloud Filestore API disabled, regional quota exceeded) and a fix for block-storage binding failures by restarting the Persistent Disk CSI driver (5-10 min downtime).
- [docs/en/configure/clusters/managed/cloud-init/storage/huawei-cce.mdx](docs/en/configure/clusters/managed/cloud-init/storage/huawei-cce.mdx): Huawei Cloud CCE storage bootstrap: after importing the CCE cluster, default StorageClasses are auto-generated and assigned to projects via Storage Management > Storage Classes > Update Project. Recommends `csi-disk` for block storage and `csi-nas` for file storage (region-dependent), with additional classes available - `csi-disk-topology` (cross-AZ disk topology), `csi-local`, `csi-local-topology`, `csi-obs` (object storage), and `csi-sfsturbo` (ultra-fast file storage, no dynamic PV creation). Troubleshoots PVC creation failures from `ShareLimitExceeded` quota limits and account suspension errors.
- [docs/en/configure/clusters/managed/cloud-init/storage/overview.mdx](docs/en/configure/clusters/managed/cloud-init/storage/overview.mdx): Compatibility matrix for ACP-managed public cloud clusters (Amazon EKS, Huawei CCE, Azure AKS, Google GKE) listing the default file and block StorageClass for each, plus whether RWO/RWX, PVC expansion, and PVC snapshots are supported - none of the four currently support PVC snapshots, block storage is RWO-only on all four, and file storage support varies by provider.
- [docs/en/configure/clusters/managed/how-to/annotate-platform-url.mdx](docs/en/configure/clusters/managed/how-to/annotate-platform-url.mdx): Recipe for restoring bidirectional connectivity from imported clusters back to the global cluster: requires a separate domain (not the platform access URL) with HTTPS forwarding to all global control nodes, then annotates the import cluster's `clusters.cluster.x-k8s.io/<name>` resource with `cpaas.io/platform-url=<https://domain>` so alerting and log-collection components can call back to the platform.
- [docs/en/configure/clusters/managed/how-to/configure-audit-for-standard-kubernetes.mdx](docs/en/configure/clusters/managed/how-to/configure-audit-for-standard-kubernetes.mdx): Recipe for enabling Kubernetes audit logging on imported kubeadm-style clusters so ACP can collect audit data: creates a detailed `audit.k8s.io/v1` (or `v1beta1` pre-1.24) Policy excluding leases/health probes/internal groups and capturing RequestResponse for major API groups, uploads it to `/etc/kubernetes/audit/policy.yaml` on every control plane node, then patches `kube-apiserver.yaml` with `--audit-policy-file`/`--audit-log-format=json`/`--audit-log-path`/`--audit-log-mode=batch`/`--audit-log-maxsize`/`--audit-log-maxbackup` and a `k8s-audit` hostPath volume mount. Not applicable to managed cloud Kubernetes clusters.
- [docs/en/configure/clusters/managed/how-to/fetch-kubeconfig.mdx](docs/en/configure/clusters/managed/how-to/fetch-kubeconfig.mdx): Recipe to extract the cluster import token, API server URL, and CA cert from an imported cluster: creates a `cluster-admin` ServiceAccount `k8sadmin` in `cpaas-system` plus a service-account-token Secret with a non-expiring token, decodes its expiration with a JWT tool, and extracts the API server address and CA via `kubectl config view --flatten -ojsonpath`. Includes guidance on isolating/merging/back-up of the imported KubeConfig and a cleanup procedure for revoking the cluster-admin binding.
- [docs/en/configure/clusters/managed/how-to/image-repo-trust.mdx](docs/en/configure/clusters/managed/how-to/image-repo-trust.mdx): Recipe for trusting an insecure (no HTTPS or untrusted-CA) image registry from imported-cluster nodes by modifying Containerd config: for v1.4/v1.5 edit `/etc/containerd/config.toml` to add `registry.mirrors` and `registry.configs[...].tls.insecure_skip_verify = true`; for v1.6+ create per-registry `hosts.toml` under `/etc/containerd/certs.d/<registry>/` with `skip_verify = true` and `config_path` set in `config.toml`. Restart containerd on every node.
- [docs/en/configure/clusters/managed/how-to/netcard-chart.mdx](docs/en/configure/clusters/managed/how-to/netcard-chart.mdx): Recipe to add custom-named network interfaces to platform monitoring: the default match pattern is `eth.*|en.*|wl.*|ww.*`, and to capture custom interface names you `kubectl edit moduleinfo` of the workload cluster (filtered via `kubectl get moduleinfo | grep -E 'prometheus|victoriametrics'`) and add `spec.valuesOverride['ait/chart-cpaas-monitor'].<cluster>.indicator.networkDevice` with an extended regular expression, then wait ~10 minutes.
- [docs/en/configure/clusters/managed/import/alibaba-ack.mdx](docs/en/configure/clusters/managed/import/alibaba-ack.mdx): Procedure to import existing Alibaba Cloud ACK managed/dedicated Kubernetes clusters: obtains the Platform Built-in image registry address via the `productbase` `preferPlatformURL` flag, verifies the registry supports trusted HTTPS, generates a temporary KubeConfig via the ACK console's Connection Information tab, and imports through Cluster Management > Clusters > Import Cluster (Platform Default / Private / Public Registry, Parse KubeConfig File). Documents post-import constraints: no node-add UI for ACK, no audit collection on managed ACK, limited ETCD/Scheduler/Controller Manager metrics, and Alibaba-monitoring port-conflict guidance.
- [docs/en/configure/clusters/managed/import/aws-eks.mdx](docs/en/configure/clusters/managed/import/aws-eks.mdx): Procedure to import an existing Amazon EKS cluster via AWS CloudShell: runs `aws eks list-clusters` and `aws eks update-kubeconfig` to prep the KubeConfig, then follows the standard import flow (Cluster Management > Clusters > Import Cluster) with Platform Default / Private / Public image registry, parsed cluster endpoint, CA certificate, and a cluster-admin token from the `fetch-kubeconfig` recipe. Links to AWS EKS ingress and storage bootstrap docs, and documents EKS-specific limitations: no node-add UI, no audit data, limited ETCD/scheduler/controller manager metrics.
- [docs/en/configure/clusters/managed/import/azure-aks.mdx](docs/en/configure/clusters/managed/import/azure-aks.mdx): Procedure to import an existing Azure AKS cluster via Azure Cloud Shell, obtaining the cluster-admin token from the `fetch-kubeconfig` recipe and configuring image registry, cluster address, CA cert, and Token through Cluster Management > Clusters > Import Cluster. Includes AKS-specific FAQs: configuring outbound/inbound NSG rules so nodes can reach the global cluster, using `kubectl debug node/...` or `kubectl-node-shell` to log into nodes, and example Service manifests for Azure ALB internal (`service.beta.kubernetes.io/azure-load-balancer-internal: "true"`) vs external load balancers. Lists same managed-cluster constraints (no node-add UI, no audit data).
- [docs/en/configure/clusters/managed/import/gcp-gke.mdx](docs/en/configure/clusters/managed/import/gcp-gke.mdx): Procedure to import a Google GKE Standard cluster (Autopilot not supported) via Google Cloud Shell: obtains the API server address from External endpoints, the CA certificate via `gcloud container clusters get-credentials` + `kubectl config view -ojsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d` (or `gcloud container clusters describe ... --format='get(masterAuth.clusterCaCertificate)'`), and the cluster-admin token from the `fetch-kubeconfig` recipe. Imports through Cluster Management > Clusters > Import Cluster and links to follow-up ingress and storage bootstrap docs. Same managed-cluster constraints (no node-add UI, limited certificate visibility).
- [docs/en/configure/clusters/managed/import/huawei-cce.mdx](docs/en/configure/clusters/managed/import/huawei-cce.mdx): Procedure for importing a Huawei Cloud CCE (Cloud Container Engine) public cloud cluster for unified management, including obtaining the platform image registry address from the global cluster ConfigMap, generating an import token (KubeConfig alone is not sufficient for public cloud clusters), and configuring the Cluster Address, CA certificate, and authentication on the Import Cluster form. Documents Huawei CCE limitations including unsupported audit data retrieval and partial Kubernetes monitoring (no ETCD, Scheduler, or Controller Manager metrics).
- [docs/en/configure/clusters/managed/import/openshift.mdx](docs/en/configure/clusters/managed/import/openshift.mdx): Walkthrough for integrating an existing OpenShift (OCP) cluster, covering trusting an insecure registry by writing `/etc/systemd/system/crio.service.d/99-registry-cpaas-system.conf` with `--insecure-registry` on every OCP node, configuring the `cpaas-coredns` ConfigMap with the OCP base domain (`oc get dns cluster -o jsonpath='{.spec.baseDomain}'`), obtaining a kubeconfig with cluster-admin permissions, and editing the audit profile via `oc edit apiserver cluster` to switch between Default, WriteRequestBodies, or AllRequestBodies. Notes that only API Server certificates are visible and adding nodes through the UI is unsupported.
- [docs/en/configure/clusters/managed/import/overview.mdx](docs/en/configure/clusters/managed/import/overview.mdx): Hub page that links to provider-specific import guides for Standard Kubernetes, OpenShift, AWS EKS, Google GKE, Azure AKS, Alibaba Cloud ACK, and Tencent Cloud TKE clusters so administrators can choose how to connect an existing managed cluster to the platform.
- [docs/en/configure/clusters/managed/import/standard-kubernetes.mdx](docs/en/configure/clusters/managed/import/standard-kubernetes.mdx): Procedure for importing a standard kubeadm-based Kubernetes cluster, including registry-trust verification, obtaining the cluster KubeConfig, and using the Import Cluster wizard with `Check Connectivity` to auto-detect the cluster type. Defines Managed vs Unmanaged clusters, lists post-import audit-log enablement, and includes a fix for distributed-storage (rook-ceph) deployment failures when Containerd is the runtime: set `LimitNOFILE=1048576` in `/etc/systemd/system/containerd.service`, reload systemd, restart containerd, and delete pods in the `rook-ceph` namespace.
- [docs/en/configure/clusters/managed/import/tencent-tke.mdx](docs/en/configure/clusters/managed/import/tencent-tke.mdx): Procedure for importing Tencent Cloud TKE Dedicated or TKE Managed clusters, including downloading the kubeconfig from the TKE console (Internet or Intranet access), supplying a token or client certificate with cluster-admin permissions, and verifying registry TLS trust. Documents that TKE Managed clusters do not expose audit data and do not surface ETCD, Scheduler, or Controller Manager monitoring metrics, while node-add via the UI is unsupported for both TKE variants.
- [docs/en/configure/clusters/managed/overview.mdx](docs/en/configure/clusters/managed/overview.mdx): Concept page that defines a managed cluster as bringing existing Kubernetes clusters under one platform for unified governance, and contrasts the two onboarding methods: Import (platform pulls cluster info and connects to it) versus Register (a reverse proxy in the target cluster initiates a tunnel back to the platform).
- [docs/en/configure/clusters/managed/register.mdx](docs/en/configure/clusters/managed/register.mdx): Procedure for the Register onboarding method, where a reverse-proxy is deployed inside the target cluster and initiates a registration request back to the platform. Covers configuring the image registry (Platform Default, Private Registry, or Public Registry), obtaining the 24-hour-valid registration command, and a Containerd-on-rook-ceph fix that sets `LimitNOFILE=1048576` and restarts containerd on every node before deploying distributed storage.
- [docs/en/configure/nodes/in_place_os_upgrade.mdx](docs/en/configure/nodes/in_place_os_upgrade.mdx): Detailed maintenance checklist for performing an in-place operating system upgrade on ACP self-built cluster nodes, including pre-upgrade verification of the supported OS/kernel matrix, conflicting-package removal, recording `containerd`, `runc`, `crictl`, and `kubelet` versions, draining the node, and additional etcd backup and quorum-health checks for control-plane nodes. Documents post-upgrade verification of SELinux/AppArmor, swap, firewalld/ufw, `DefaultTasksMax`, time skew (<10s), DNS, kubelet restart, and `kubectl uncordon`, plus a high-risk-scenarios table covering overwritten runtime binaries, NotReady nodes, and TLS errors from clock drift.
- [docs/en/configure/nodes/node_add.mdx](docs/en/configure/nodes/node_add.mdx): How to add control-plane or compute nodes to an existing on-premises cluster via Cluster Management > Clusters > Nodes > Add Node, including hardware/architecture/OS consistency constraints, the 1/3/5 control-plane HA rule (exactly 2 is unsupported), SOCKS5 proxy support when SSH is not directly reachable, and the View Execution Progress and Re-add Failed Nodes follow-up actions.
- [docs/en/configure/nodes/node_management.mdx](docs/en/configure/nodes/node_management.mdx): Console-based day-2 node operations: updating Kubernetes labels, stopping or resuming scheduling, evicting pods (with the warning that local-storage pod data is lost), setting taints with `NoSchedule`, `PreferNoSchedule`, or `NoExecute` effects, batch Label and Taint Management (including device labels backed by NVIDIA GPU MPS / GPU Manager device plugins), toggling the virtualization switch to allow VirtualMachineInstance (VMI) scheduling on physical-machine nodes, and deleting on-premises nodes with an optional cleanup script.
- [docs/en/configure/nodes/node_monitoring.mdx](docs/en/configure/nodes/node_monitoring.mdx): How to inspect node monitoring on the node details Monitoring tab when Prometheus/VictoriaMetrics monitoring is configured, with detailed definitions of CPU/Memory usage, request, and limit rates, storage space and inode usage, system load (1/5/15 min), disk throughput and IOPS, and network traffic and packet rates. Includes guidance on exporting PromQL expressions and the storage partition rollup behavior when a node has more than 4 partitions.
- [docs/en/configure/clusters/on-premises.mdx](docs/en/configure/clusters/on-premises.mdx): End-to-end guide for creating an on-premises workload cluster, including node availability checks, choosing a hardware LoadBalancer vs `Self-built VIP` (keepalived/VRRP) for ports 6443/11780/11781, image registry selection, container-network options (Kube-OVN with Overlay/Underlay and Cluster CIDR / Service CIDR / Join CIDR, Calico, Flannel with Node IP Count, or Custom), node settings (NIC, hostname-vs-IP, monitoring type with Prometheus or VictoriaMetrics/VMStorage/VMAlert/VMAgent), node-add parameters (SSH password or key, SOCKS5 proxy), and extended `kubeletExtraArgs` (including `max-pods`), `controllerManagerExtraArgs`, `schedulerExtraArgs`, `apiServerExtraArgs`, and `publicAlternativeNames`.
- [docs/en/configure/clusters/overview.mdx](docs/en/configure/clusters/overview.mdx): Serves as the Configure > Clusters path-selection entry for creating platform-managed clusters, evaluating Hosted Control Plane, or onboarding existing Kubernetes environments. It links to the canonical Cluster Management Models concept page, routes readers to IPI, UPI, HCP (Kamaji-based), import, and register workflows, and preserves ACP 4.3 and ACP 4.2 version compatibility guidance.
- [docs/en/configure/platform_settings/feature_gates.mdx](docs/en/configure/platform_settings/feature_gates.mdx): How to use the Feature Gate page at `{platform-access-address}/console-platform/feature-gate` to control Alpha and Beta feature visibility platform-wide via the Stage Setting section, enable specific features for an individual cluster, or disable specific features globally via System Settings. Gates may affect UI visibility, API behavior, or both depending on the feature implementation.
- [docs/en/networking/functions/configure_alb.mdx](docs/en/networking/functions/configure_alb.mdx): Detailed configuration reference for the deprecated ALB load balancer custom resource (ALB2/v2beta1), including the `.spec.config` schema for replicas, nodeSelector, resources, projects, networkMode (host/container), vip.enableLbSvc, and address. Documents the companion Frontend CR (L4 tcp/udp and L7 http/https/grpc/grpcs listener ports with `serviceGroup` and `certificate_name`), Rule CR with DSLX matching (URL/HOST/HEADER/METHOD/PARAM/COOKIE/SRC_IP, priority 0-10), HTTPS termination/re-encrypt modes, ingress sync via IngressClass and `cpaas.io/project` label, plus the `alb.networking.cpaas.io/tls` cross-namespace certificate annotation. Recommends migration to `ingress-nginx-operator` or `envoy-gateway`.
- [docs/en/networking/functions/configure_certificate.mdx](docs/en/networking/functions/configure_certificate.mdx): Steps for the platform administrator to import a TLS certificate via Network Management > Certificates, supplying the `tls.crt` public key and `tls.key` private key (binary uploads unsupported) and assigning it to All Projects, a Specified Project, or No Assignment, so developers can later reuse it on ingresses and load balancers. Notes that the feature does not work on public-cloud clusters where a TLS-type Secret must be created in the target namespace instead.
- [docs/en/networking/functions/configure_coredns.mdx](docs/en/networking/functions/configure_coredns.mdx): How to customize CoreDNS via Marketplace > Cluster Plugins > Alauda Build of CoreDNS, including host aliases (IP plus space-separated domains for custom resolution entries), node selectors (label key/value), and node tolerations with `NoSchedule`, `PreferNoSchedule`, or `NoExecute` effect, to control where CoreDNS pods run and which DNS entries they resolve.
- [docs/en/networking/functions/configure_domain.mdx](docs/en/networking/functions/configure_domain.mdx): How to add a Domain custom resource (`crd.alauda.io/v2`, kind `Domain`) for full or wildcard domains, optionally binding a TLS certificate (Secret referenced via `cpaas.io/secret-ref` annotation) so application developers can pick the domain when setting up ingresses, listener ports, or native-application inbound rules. Documents Allocate Cluster scoping, and how to use the same `spec.name` across multiple clusters by creating separate Domain resources in the global cluster with different `cluster.cpaas.io/name` labels.
- [docs/en/networking/functions/configure_gatewayapi_gateway.mdx](docs/en/networking/functions/configure_gatewayapi_gateway.mdx): Comprehensive guide to configuring a Gateway API Gateway after the Envoy Gateway operator and EnvoyGatewayCtl are ready, covering listener ports/protocols (HTTP, HTTPS, TCP, UDP, TLS) with hostname uniqueness, Allowed Routes Namespace (`Same`/`All`/`Selector` for ACP project labels like `cpaas.io/project`), TLS Terminate vs Passthrough modes (`tls.certificateRefs` to `kubernetes.io/tls` secrets), service exposure via LoadBalancer (with MetalLB annotations `metallb.universe.tf/address-pool` and `metallb.universe.tf/loadBalancerIPs`), NodePort, or ClusterIP, and the companion EnvoyProxy resource (`.spec.provider.kubernetes.envoyDeployment.container.resources`) with recommended CPU/memory sizing (e.g., 2 cores/1Gi at 4k QPS). Includes the Hostname Intersection Rule table and the listener-protocol-to-route-kind matrix.
- [docs/en/networking/functions/configure_gatewayapi_policy.mdx](docs/en/networking/functions/configure_gatewayapi_policy.mdx): Configuration reference for the four Envoy Gateway policy resources attached via `.spec.targetRefs`: `SecurityPolicy` (API Key Auth via `apiKeyAuth.credentialRefs` / `extractFrom`, CORS via `allowOrigins`/`allowMethods`/`allowHeaders`/`maxAge`/`allowCredentials`), `BackendTLSPolicy` (SNI hostname, `subjectAltNames`, `cACertificateRefs` to secrets with `ca.crt`, or `WellKnownCACertificates`), `ClientTrafficPolicy` (TCP idle, HTTP request-received, HTTP idle, HTTP stream-idle timeouts), and `BackendTrafficPolicy` (TCP connection, HTTP connection-idle, max-connection-duration, request timeouts). Includes the attachment matrix showing which policy types support Gateway listener `sectionName`, route types, and Service ports.
- [docs/en/networking/functions/configure_gatewayapi_route.mdx](docs/en/networking/functions/configure_gatewayapi_route.mdx): Comprehensive reference for Gateway API Route resources (HTTPRoute, TCPRoute, UDPRoute, GRPCRoute, TLSRoute), covering `parentRefs.sectionName` listener attachment, hostname intersection rules, rule matches (Path Exact/PathPrefix/RegularExpression with RE2, Header, QueryParam, Method), filter types (`RequestHeaderModifier`, `ResponseHeaderModifier`, `RequestRedirect`, `URLRewrite`, `CORS`, `RequestMirror`, `HTTPExternalAuthFilter`), backendRefs with weight, HTTPRoute Options (timeouts.request/backendRequest, retry.codes/attempts/backoff, sessionPersistence Cookie/Header), and GRPCRoute method/headers matching. Also documents the ACP Web Console Topology tab for visualizing routes and attached policies (HTTPRoute only).
- [docs/en/networking/functions/configure_ingress.mdx](docs/en/networking/functions/configure_ingress.mdx): How to create a Kubernetes Ingress (`networking.k8s.io/v1`) exposing HTTP/HTTPS routes from outside the cluster, with `ingressClassName` for selecting the controller (`nginx` for ingress-nginx-operator, or an ALB instance name for alb-operator), `host` rules with Prefix/Exact/Implementation-specific path matching, and TLS via platform-allocated domains and certificates. Notes that ports 80/443 are the only external ports for HTTP/HTTPS, and that duplicate Domain+Protocol+Path triples within a namespace are not allowed.
- [docs/en/networking/functions/configure_metallb.mdx](docs/en/networking/functions/configure_metallb.mdx): How to create an External IP Address Pool (`metallb.io/v1beta1` IPAddressPool) via Network Management > External IP Address Pool, choosing L2 or BGP (Alpha) mode, supplying CIDR or IP ranges, and selecting available nodes by name or label selector. Also documents BGPPeer configuration (Local/Peer AS Number, Peer IP, Local IP, Peer Port, eBGP Multi-Hop, RouterID), companion `L2Advertisement` / `BGPAdvertisement` YAML, and a troubleshooting table covering missing external IPs, speaker/controller CrashLoop, BGP not establishing, and L2 failures.
- [docs/en/networking/functions/configure_node_local_dns.mdx](docs/en/networking/functions/configure_node_local_dns.mdx): Installation and operational reference for the Alauda Build of NodeLocal DNSCache cluster plugin (recommended IP `169.254.20.10` for IPv4 or `fd00::10` for IPv6), covering kubelet restart on install, the requirement to add `--node-local-dns-ip=<IP>` to kube-ovn-controller when CNI is Kube-OVN, NetworkPolicy rules permitting UDP/TCP 53 to the cache IP, and the multi-location `cluster-dns` kubeletExtraArgs persistence requirement for MicroOS clusters (KubeadmControlPlane initConfiguration/joinConfiguration and KubeadmConfigTemplate). Includes 4.2.x upgrade ResourcePatch handling.
- [docs/en/networking/functions/configure_service.mdx](docs/en/networking/functions/configure_service.mdx): Comprehensive Kubernetes Service configuration guide covering `ClusterIP`, `NodePort`, `LoadBalancer`, and `ExternalName` types, Headless services (`clusterIP: None`) for StatefulSets, session affinity, and end-to-end examples for in-cluster access, out-of-cluster NodePort access, LoadBalancer with cloud-provider annotations (`service.beta.kubernetes.io/aws-load-balancer-type`/`-nlb-target-type`/`-scheme`/`-ip-address-type`, `kubernetes.io/elb.id`/`.autocreate`/`.subnet-id`/`.class` for Huawei CCE, `service.beta.kubernetes.io/azure-load-balancer-internal`, `networking.gke.io/load-balancer-type`), and a MetalLB BGP + `externalTrafficPolicy: Local` active-active example.
- [docs/en/networking/functions/configure_subnet.mdx](docs/en/networking/functions/configure_subnet.mdx): End-to-end reference for the `kubeovn.io/v1` Subnet resource on Calico and Kube-OVN networks: Calico subnets with IPIP/VXLAN/no-encapsulation, encapsulation modes (Always vs Cross Subnet), Outbound Traffic NAT, and a CIDR-to-blockSize matching table; Kube-OVN Overlay with distributed vs centralized gateways, ECMP (Alpha), reserved IPs; and Kube-OVN Underlay using ProviderNetwork (defaultInterface/customInterfaces/excludeNodes), VLAN, and Subnet with `vlan` reference. Also covers day-2 operations: update gateway, update reserved IPs, assign projects/namespaces (`namespaceSelectors` with `cpaas.io/project` label), expand subnet, and delete.
- [docs/en/networking/how_to/alb/tasks_for_alb.mdx](docs/en/networking/how_to/alb/tasks_for_alb.mdx): Two operational kubectl patch snippets for ALB: setting nodeSelector and tolerations on the `ingress-nginx-operator` Subscription (via `.spec.config.nodeSelector` and `.spec.config.tolerations`), and setting nodeSelector plus the `alb.cpaas.io/toleration` annotation on an `ALB2` custom resource to schedule ALB onto infra-labeled nodes.
- [docs/en/networking/how_to/configure_endpoint_health_checker.mdx](docs/en/networking/how_to/configure_endpoint_health_checker.mdx): Installation and activation guide for the Alauda Container Platform Endpoint Health Checker cluster plugin that performs active TCP-connectivity health checks and automatically removes failed endpoints, reducing endpoint switching time from ~40s (kubelet heartbeat) to ~10s during node power outages. Documents enabling via the recommended pod annotation `endpoint-health-checker.io/enabled: 'true'` on ALB2 (`alb.cpaas.io/pod-annotations`), IngressNginx (`.spec.controller.podAnnotations`), Envoy Gateway, or custom Deployments, plus the legacy `readinessGates: [conditionType: endpointHealthCheckSuccess]` mechanism.
- [docs/en/networking/how_to/kube_ovn/config_metallb_underlay.mdx](docs/en/networking/how_to/kube_ovn/config_metallb_underlay.mdx): Step-by-step solution (ACP >= 4.2.2, IPv4 only) for using MetalLB L2 mode with Kube-OVN Underlay so the LoadBalancer VIP and backend Pod IPs share the same Underlay subnet, with direct DNAT from `br-provider` into the OVN logical switch. Covers ProviderNetwork with `autoCreateVlanSubinterfaces: true` and a Vlan of id `0`, configuring the Kube-OVN cluster plugin with Skip CT for Dst LPort IPs = No and Enable OVN LB Local = Yes, setting `spec.enableExternalLBAddress: true` and reserved `excludeIps` ranges on the Underlay Subnet, creating an `IPAddressPool` plus `L2Advertisement` over the `br-provider` interface, and using `externalTrafficPolicy: Local` on the LoadBalancer Service.
- [docs/en/networking/how_to/kube_ovn/configure_bgp.mdx](docs/en/networking/how_to/kube_ovn/configure_bgp.mdx): How to enable BGP route announcement in Kube-OVN via `kube-ovn-speaker` (GoBGP-based), including labeling speaker nodes with `ovn.kubernetes.io/bgp=true`, downloading the version-matched `speaker.yaml`, and configuring `--neighbor-address`, `--neighbor-as`, and `--cluster-as` (with multi-peer ECMP support). Documents annotating Pods or Subnets with `ovn.kubernetes.io/bgp` to publish routes, the `Cluster` vs `Local` announcement policies, requiring `natOutgoing: false` on the subnet, and advanced flags (`auth-password`, `holdtime`, `graceful-restart`, `ebgp-multihop`, `passivemode`).
- [docs/en/networking/how_to/kube_ovn/configure_centralized_gateway.mdx](docs/en/networking/how_to/kube_ovn/configure_centralized_gateway.mdx): How to configure a centralized gateway on a Kube-OVN Subnet so Pods egress through a fixed set of node IPs for auditing, IP allowlisting, and firewall management, using `spec.gatewayType: centralized`, `spec.gatewayNode` (comma-separated `node1,node2` or `<node>:<NIC-IP>` for specific NICs), and `spec.gatewayNodeSelectors` for dynamic label-based selection. Covers `enableEcmp` for ECMP active-active mode (~5-10s failover via active ping probes) versus master-slave failover (minutes on power outage), and notes the incompatibility with `hostport` or NodePort services using `externalTrafficPolicy: Local`.
- [docs/en/networking/how_to/kube_ovn/configure_egress_gateway.mdx](docs/en/networking/how_to/kube_ovn/configure_egress_gateway.mdx): Comprehensive guide to the `VpcEgressGateway` (VEG) custom resource that runs dedicated gateway Pods (two interfaces: overlay `eth0` and underlay `net1`) to provide stable per-workload egress IPs with ECMP active-active load balancing and BFD-based sub-second failover. Covers prerequisites (Multus CNI, prepared external NAD/Subnet with VLAN), `.spec.selectors` (NamespaceSelector/PodSelector), `.spec.policies` (snat + subnets/ipBlocks), `.spec.replicas`, `.spec.externalIPs`, `.spec.bfd.{minRX,minTX,multiplier}` (formula `break time = (multiplier+1) * max(minRX,minTX)`), enabling the BFD Port on the `Vpc` resource (`spec.bfdPort`), and validating with `kubectl get veg`, `ovn-nbctl`, and tcpdump.
- [docs/en/networking/how_to/kube_ovn/configure_ippool.mdx](docs/en/networking/how_to/kube_ovn/configure_ippool.mdx): How to create an `IPPool` custom resource that subdivides a Kube-OVN Subnet (`spec.subnet`) into finer IPAM units with `spec.ips` supporting single IP, CIDR, and `IP1..IP2` range formats (IPv4/IPv6), optionally bound to one or more namespaces. Covers using the `ovn.kubernetes.io/ip_pool` annotation on Pods, Deployments, and StatefulSets to randomly select IPs from a pool, precautions about non-overlapping ranges, inherited reserved IPs, and avoiding pool names that look like IP addresses for compatibility with the Fixed Addresses feature.
- [docs/en/networking/how_to/kube_ovn/configure_mtu.mdx](docs/en/networking/how_to/kube_ovn/configure_mtu.mdx): How Kube-OVN auto-detects MTU and the per-encapsulation overhead calculation (Geneve IPv4 = MTU-100, IPv6 = MTU-120; VXLAN IPv4 = MTU-50, IPv6 = MTU-70; Underlay matches physical). Documents customizing MTU globally via the `--mtu=N` argument on the `kube-ovn-cni` DaemonSet or per-subnet via `kubectl patch subnet <name> -p '{"spec":{"mtu":N}}'`, with a critical warning that increasing MTU requires recreating all Pods because OVS internal ports (e.g., `ovn0`) adopt the smallest MTU among interfaces on `br-int`.
- [docs/en/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx](docs/en/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx): How to enable Cluster Interconnection (Alpha) between multiple Kube-OVN clusters so Pods across clusters can reach each other, including building a 3-node `ovn-ic` controller cluster via Deploy mode (using `install-ic-server.sh` extracted from the `kube-ovn-controller` Pod), Podman, or Containerd (`ctr -n k8s.io run`) with `LOCAL_IP`, `LEADER_IP`, `NODE_IPS` envs. Covers creating the `ovn-ic` ConfigMap in the global cluster (ports 6645/6646), joining a cluster from the UI by selecting gateway nodes, updating gateway nodes, exiting with `clean-ic-az-db.sh`, full uninstall by deleting `ovn-ic-config` and the `ts` logical switch, and configuring HA gateways by editing the `ovn-ic-config` ConfigMap's `gw-nodes` field.
- [docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx](docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx): Physical-network planning reference for Kube-OVN Underlay deployments, including the dual-NIC requirement (one default-route NIC for management, one IP-less NIC dedicated to the Underlay set to switch Trunk mode), recommended 10Gbps+ link speed, supported bonding modes (0, 1, 4, 6), and IaaS prerequisites: OpenStack `PortSecurity` disabled, VMware `MAC Address Changes`/`Forged Transmits`/`Promiscuous Mode` set to Accept, with public clouds (AWS, GCE, Alibaba) unsupported. Includes a switch-side `interface Vlan-interfaceN` configuration example with IPv4/IPv6 gateway, Trunk-mode port-allow-vlan, and a `ip link add ens224.74 type vlan` connectivity test snippet.
- [docs/en/networking/how_to/kube_ovn/multiple_networks.mdx](docs/en/networking/how_to/kube_ovn/multiple_networks.mdx): How to attach multiple network interfaces to a Pod via Multus CNI + Kube-OVN, including installing the `Alauda Container Platform Networking for Multus` cluster plugin, creating a `NetworkAttachmentDefinition` with provider `<NAME>.<NAMESPACE>.ovn` referencing `/run/openvswitch/kube-ovn-daemon.sock`, a Kube-OVN `Subnet` with matching `spec.provider`, and a Pod with the `k8s.v1.cni.cncf.io/networks` annotation (comma-separated for multiple NADs). Documents fixed-IP via `<provider>.ip_address` annotations, `routes` field for cluster-wide additional routes per NAD, and per-Pod `attachnet.default.ovn.kubernetes.io/routes` overrides, plus verification via `kubectl get ip` and inside-pod `ip addr show`.
- [docs/en/networking/how_to/kube_ovn/underlay_overlay_st.mdx](docs/en/networking/how_to/kube_ovn/underlay_overlay_st.mdx): How to enable automatic interconnection between Underlay and Overlay subnets in the same cluster by setting `u2oInterconnection: true` on the Underlay subnet so an additional Underlay IP bridges to the `ovn-cluster` logical router. Covers isolating two `u2oInterconnection`-enabled Underlay subnets with ACL rules: first set `--ls-ct-skip-dst-lport-ips=false` on the `kube-ovn-controller` Deployment (required for `allow-related` ACL replies to be tracked), then add `spec.acls` rules with `action: drop`, `direction: to-lport`, `match: ip4.src == <CIDR>`, and `priority` in the 1002-1899 range.
- [docs/en/networking/how_to/kube_ovn/understanding_kube_ovn.mdx](docs/en/networking/how_to/kube_ovn/understanding_kube_ovn.mdx): Architecture overview of Kube-OVN's three component categories: upstream OVN/OVS (`ovn-central` running `ovn-nb`/`ovn-sb`/`ovn-northd` with Raft HA, and `ovs-ovn` DaemonSet running openvswitch/ovsdb/ovn-controller on each node), core controller and agent (`kube-ovn-controller` listening to Pod/Service/Endpoint/Node/NetworkPolicy/VPC/Subnet/Vlan/ProviderNetwork events and translating them to OVN logical resources, `kube-ovn-cni` DaemonSet implementing the CNI interface and configuring local veth/OVS/iptables), and monitoring/extension tools (`kube-ovn-speaker` for BGP, `kube-ovn-pinger`, `kube-ovn-monitor`, `kubectl-ko` plugin).
- [docs/en/networking/how_to/soft_data_center_lb_solution.mdx](docs/en/networking/how_to/soft_data_center_lb_solution.mdx): Procedure for deploying a pure-software, highly-available data-center load balancer (Alpha) outside the cluster using Keepalived + IPVS to front multiple ALBs, supporting IPv4, IPv6, and dual-stack. Documents prerequisites (two+ Ubuntu 22.04 hosts, `ipvsadm`, containerd, synchronized clocks), required kernel modules (`ip_vs`, `ip_vs_rr`, `nf_conntrack_ipv4`, `ip6t_MASQUERADE`, etc.) in `/etc/modules-load.d/alive.kmod.conf`, sysctl settings (`net.ipv4.ip_forward=1`, `net.ipv4.vs.conntrack=1`), the `alive.yaml` instance/vip/ipvs/kube_lock layout with leader-election kubeconfigs, certificate validity verification, running the `tkestack/keepalived` image via `nerdctl`, and verifying with `ipvsadm -ln` and curl.
- [docs/en/networking/how_to/task_for_migrate_from_ocp_route_to_gatewayapi_route.mdx](docs/en/networking/how_to/task_for_migrate_from_ocp_route_to_gatewayapi_route.mdx): Side-by-side migration guide from OpenShift Route to Kubernetes Gateway API HTTPRoute with Envoy Gateway, mapping each OCP feature to its Gateway API equivalent: basic HTTP routing, path matching (`PathPrefix`/`Exact`/`RegularExpression`), timeouts (`haproxy.router.openshift.io/timeout` → `rules[].timeouts.request/backendRequest`), HSTS via `ResponseHeaderModifier`, cookie session affinity (`router.openshift.io/cookie_name` → `sessionPersistence`), header modification, connection limits via `ClientTrafficPolicy`, rate limiting via `BackendTrafficPolicy`, IP allow/blocklist via `SecurityPolicy.authorization.clientCIDRs`, URL rewrite, cross-namespace `allowedRoutes.namespaces.from`, TLS edge/re-encrypt (`BackendTLSPolicy`)/passthrough (`TLSRoute`), and a phased migration strategy with DNS dual-running and rollback.
- [docs/en/networking/how_to/tasks_for_envoy_gateway.mdx](docs/en/networking/how_to/tasks_for_envoy_gateway.mdx): Advanced Envoy Gateway operational tasks beyond the basic operator/gateway/route/policy flow: OpenTelemetry via `envoy-gateway-config`, cross-namespace listener attachment via `allowedRoutes.namespaces.from` (`Same`/`All`/`Selector`), cross-namespace certificate references via `ReferenceGrant`, SSL passthrough, raising the minimum TLS version via a `ClientTrafficPolicy` with `spec.tls.minVersion: "1.3"`, specifying NodePort via `envoyService.patch` (StrategicMerge), pinning a MetalLB VIP via `metallb.universe.tf/address-pool` and `loadBalancerIPs` annotations, adding pod annotations via `envoyDeployment.patch`, NodeSelector/tolerations patches for the operator/envoy-gateway/envoy-proxy, two `hostNetwork: true` approaches (port-offset 10080/10443 vs `useListenerPortAsContainerPort: true` with `NET_BIND_SERVICE`), and switching `externalTrafficPolicy` from Local to Cluster for in-cluster VIP access.
- [docs/en/networking/how_to/tasks_for_ingress_nginx.mdx](docs/en/networking/how_to/tasks_for_ingress_nginx.mdx): Cheat sheet of upstream ingress-nginx annotations and ConfigMap settings relevant on ACP (`Max-Worker-Connections`, proxy timeouts, sticky sessions, header set/remove via `proxy-set-header`/`more_set_headers`/`hide-headers`, URL rewrite, HSTS, rate limiting, ModSecurity WAF, `x-forwarded-prefix-header`, TLS backend re-encrypt and edge termination, SSL passthrough, `default-ssl-certificate` via an `IngressNginx` CR). Also documents two source-IP preservation patterns: HAProxy with `send-proxy-v2` plus `use-proxy-protocol: "true"` on the IngressNginx, and MetalLB LoadBalancer with `externalTrafficPolicy: Local` (with the necessary `nodeSelector` alignment to the MetalLB pool).
- [docs/en/networking/trouble_shooting/arm_checksum.mdx](docs/en/networking/trouble_shooting/arm_checksum.mdx): Two workarounds for an inter-node communication failure on ARM environments using lower kernel versions and certain domestic NICs whose checksum offload is computed incorrectly: upgrade the kernel to 4.19.90-25.16.v2101 or later, or disable transmit checksum offload on the physical NIC with `ethtool -K eth0 tx off`.
- [docs/en/networking/trouble_shooting/find_who_cause_the_error.mdx](docs/en/networking/trouble_shooting/find_who_cause_the_error.mdx): Short troubleshooting note that explains how to read the `X-ALB-ERR-REASON` response header to diagnose ALB errors: `InvalidBalancer` (no endpoint found for the service), `BackendError` (backend returned a non-ALB error code), and `InvalidUpstream` (request did not match any rule, ALB returns 404).
- [docs/en/observability/alerting/notification.mdx](docs/en/observability/alerting/notification.mdx): How to install the Alauda Container Platform Cluster Notification plugin (ACP >= v4.2, plugin >= v1.0) via web console or by applying a `ModuleInfo` resource with the `aiops-notification-business` module name, and pushing the package with `violet push aiops-notification-business.ALL.vx.x.x.tgz`. Includes the email server configuration: a `NotificationServer`-type Secret labeled `cpaas.io/notification.server.category: Email` containing base64-encoded `host`, `port`, `username`, `password`, `from`, `sslEnabled`, and `insecureSkipVerify`.
- [docs/en/configure/scalability/disk_configuration.mdx](docs/en/configure/scalability/disk_configuration.mdx): Storage capacity sizing reference for ACP nodes: `/var/lib/etcd` 10-20GB (dedicated high-IO disk), `/var/lib/containerd/` 100-150GB, `/cpaas/` 100-200GB (global control plane) or >=40GB (other nodes), `/` 50-100GB with utilization <80% to avoid pod eviction, and 20-250GB for installer workspace. Documents etcd hardware recommendations (SSD/NVMe preferred, avoid HDD/NAS/SAN/Ceph RBD/NFS), validation thresholds (sequential IOPS >=50/recommended 500; bandwidth >=10MB/s/recommended 100; 8kB writes with fdatasync >=50/10ms / recommended 500/2ms), and a `fio --rw=write --fdatasync=1 --bs=8000` benchmark script that flags p99 fsync >10ms.
- [docs/en/configure/scalability/evaluating_global.mdx](docs/en/configure/scalability/evaluating_global.mdx): Node sizing guidance for the multi-cluster Global cluster, with reference tiers: Small (<=10 managed clusters, 3 nodes x 8 cores x 16GB), Medium (<=50, 3 x 16 cores x 32GB - default), Large (<=100, 3 x 24 cores x 48GB), and Extra Large (<=500, 6 x 32 cores x 64GB). Documents vertical scaling rules (+50% CPU/memory per 50 additional clusters), horizontal scaling beyond 100 clusters, target metrics (Node CPU 60-75% under peak, memory <=80%, API P90 <500ms, etcd commit P99 <50ms), and PromQL snippets for each metric.
- [docs/en/configure/scalability/evaluating_workload.mdx](docs/en/configure/scalability/evaluating_workload.mdx): Control-plane sizing reference for workload clusters derived from cluster-density tests (deploying 6 deployments + 6 services + 6 ingresses + 12 secrets + 12 ConfigMaps per namespace): 24 worker nodes / 500 namespaces -> 4 CPU / 16GB, 120/1000 -> 8/32, 254/4000 -> 24/128 (baselined on AWS r5.4xlarge and m5.2xlarge instances). Recommends keeping control-plane utilization <=60% to absorb HA failover. Includes tested ACP cluster maximums: 500 nodes, 100k pods, 250 pods/node, 10k namespaces, 25k pods/namespace, 40k secrets/configmaps, 10k services, 5k services/namespace, 5k backends/service, 1024 CRDs cluster-wide, plus the 50/100 QPS/burst client-side rate-limit note.
- [docs/en/configure/scalability/large_clusters_stability.mdx](docs/en/configure/scalability/large_clusters_stability.mdx): Operator-focused checklist of stability optimizations for large-scale Kubernetes clusters, addressing etcd disk I/O (dedicated NVMe SSD), keeping the etcd DB <=8GB and per-resource-type data <=800MB, hot-key analysis, monitoring API-server LB bandwidth, capping services per namespace at 5000 (or `enableServiceLinks: false`) and total cluster services at 10000, NodeLocal DNSCache for high pod counts, reducing pod churn with conservative `maxUnavailable`/`maxSurge`, `automountServiceAccountToken: false` for pods that don't need API access, `revisionHistoryLimit` and `ttlSecondsAfterFinished` for object accumulation, equal requests/limits, and monitoring controller restarts to avoid re-list storms.
- [docs/en/configure/storage/concepts/key_concepts.mdx](docs/en/configure/storage/concepts/key_concepts.mdx): Concept primer introducing Kubernetes storage primitives used throughout the platform: PersistentVolume (PV) as cluster-level storage resource, PersistentVolumeClaim (PVC) as user storage request, StorageClass for dynamic provisioning, Generic Ephemeral Volumes (CSI-driven temporary volumes), `emptyDir`, `hostPath`, ConfigMap, Secret, and the Container Storage Interface (CSI) with its Controller (Deployment) and Node (DaemonSet) components. Includes a Mermaid diagram of the PVC -> StorageClass -> PV binding flow.
- [docs/en/configure/storage/concepts/pv.mdx](docs/en/configure/storage/concepts/pv.mdx): Concept page contrasting dynamic Persistent Volumes (provisioned via StorageClass when a matching PVC is created) with static Persistent Volumes (manually created by administrators, currently supporting HostPath and NFS shared storage). Walks through the PV lifecycle (Provisioning, Binding, Using, Releasing, Reclaiming) and notes that HostPath is generally only suitable for single-node test scenarios.
- [docs/en/configure/storage/concepts/selection.mdx](docs/en/configure/storage/concepts/selection.mdx): Compatibility matrix for choosing a storage class on ACP based on Kubernetes Access Modes (RWO/ROX/RWX), Volume Modes (Filesystem/Block), and feature support (Volume Snapshot, Expansion). CephFS and NFS support RWX Filesystem only; CephRBD and TopoLVM support RWO with both Filesystem and Block modes; snapshots and expansion are supported on CephFS/CephRBD/TopoLVM but not on NFS shared storage. Notes that only dynamically provisioned PVCs (via StorageClass) support volume snapshots.
- [docs/en/configure/storage/cosi/cosi-concepts.mdx](docs/en/configure/storage/cosi/cosi-concepts.mdx): Introduction to the Container Object Storage Interface (COSI) core resources for managing Ceph RGW-style object storage, with Kubernetes analogies: `BucketClass` (cluster-scoped, like StorageClass; specifies `driverName`, `deletionPolicy`, and `parameters` such as `objectStoreUserSecretName`), `Bucket` (cluster-scoped, like PersistentVolume), and `BucketClaim` (namespace-scoped, like PersistentVolumeClaim; specifies `bucketClassName` and `protocol.s3`). Documents the dynamic-creation workflow where the COSI controller observes a BucketClaim, creates the backend bucket and a corresponding Bucket resource, and emits a Secret with access credentials.
- [docs/en/configure/storage/cosi/functions/bucket_class_ceph.mdx](docs/en/configure/storage/cosi/functions/bucket_class_ceph.mdx): End-to-end procedure for creating a BucketClass that targets Ceph RGW via the `ceph.objectstorage.k8s.io` driver, including preparing a Ceph cluster (Rook-managed internal or external), installing the Alauda Container Platform COSI and COSI for Ceph cluster plugins, and creating the credential Secret either by applying a `CephObjectStoreUser` in the `rook-ceph` namespace (Method A) or manually with AccessKey/SecretKey/Endpoint and the mandatory `app=rook-ceph-rgw` label (Method B). Provides UI and YAML workflows for creating the BucketClass with `deletionPolicy: Delete` and `objectStoreUserSecretName`/`objectStoreUserSecretNamespace` parameters.
- [docs/en/configure/storage/cosi/functions/bucket_request.mdx](docs/en/configure/storage/cosi/functions/bucket_request.mdx): How to create a Bucket Request (BucketClaim) from Container Platform > Storage > Bucket Claims that selects an Object Storage Class to dynamically provision a bucket and auto-bind it, with status `Available` indicating completion. Notes the destructive Actions > Delete bucket policy operation which clears bucket contents and should be used only after data backup.
- [docs/en/configure/storage/cosi/how_to/access_control_ceph.mdx](docs/en/configure/storage/cosi/how_to/access_control_ceph.mdx): End-to-end recipe for least-privilege access and quota enforcement on Ceph RGW-backed COSI buckets: define a `CephObjectStoreUser` in `rook-ceph` with `capabilities.bucket/user: read,write` and `quotas.maxBuckets/maxObjects/maxSize`, reference the autogenerated Secret in a `BucketClass`, provision buckets per namespace via `BucketClaim` with `protocols: [S3]`, then mint per-workload credentials with `BucketAccessClass` (policies `readonly`/`writeonly`/`readwrite`, optional `anonymous: "true"` for public read) and `BucketAccess` which writes the keys into a Secret whose `.data.BucketInfo` decodes to `secretS3.endpoint`/`accessKeyID`/`accessSecretKey`. Includes rotation, namespace placement, and troubleshooting tips.
- [docs/en/configure/storage/cosi/install.mdx](docs/en/configure/storage/cosi/install.mdx): How to install the `Alauda Container Platform COSI` cluster plugin and the dependent `Alauda Container Platform COSI for Ceph` plugin via Platform Management > Marketplace > Cluster Plugins on each target cluster, plus the uninstall order (uninstall COSI for Ceph before COSI). Notes that plugins are cluster-scoped and the `Alauda Container Platform COSI for Ceph` depends on `Alauda Container Platform COSI`.
- [docs/en/configure/storage/cosi/intro.mdx](docs/en/configure/storage/cosi/intro.mdx): Short product positioning of COSI as a Kubernetes-native framework for standardized, declarative management of object storage (e.g., Ceph RGW): dynamic bucket provisioning, Kubernetes Secret-based credential distribution, and unified persistent-storage patterns. Lists limitations: COSI is currently alpha and only the Ceph RGW driver is supported; legacy buckets may require additional manual configuration.
- [docs/en/configure/storage/functions/cephfs_storageclass.mdx](docs/en/configure/storage/functions/cephfs_storageclass.mdx): How to create a CephFS File Storage StorageClass via Administrator > Storage Management > Storage Classes, after deploying the distributed storage volume plugin in Internal (Rook-managed) or External mode. Documents the Reclaim Policy (Delete/Retain), access modes (ReadWriteOnce and ReadWriteMany), Allocate Project, and the automatically-applied Storage Cluster / Storage Pool parameters inherited from the distributed-storage deployment.
- [docs/en/configure/storage/functions/cephrbd_storageclass.mdx](docs/en/configure/storage/functions/cephrbd_storageclass.mdx): How to create a CephRBD Block Storage StorageClass for the platform's built-in Ceph block storage, suitable for high-IOPS/low-latency workloads such as databases and virtualization. Covers parameters including File System (default EXT4 supporting up to 1 EiB / 16 TiB files), Reclaim Policy (Delete/Retain), ReadWriteOnce-only access mode, project assignment, and the Storage Cluster / Storage Pool inherited from the distributed-storage deployment.
- [docs/en/configure/storage/functions/create_pv.mdx](docs/en/configure/storage/functions/create_pv.mdx): How to manually create a static PersistentVolume of type HostPath or NFS Shared Storage via the web console or by applying a `v1 PersistentVolume` resource with `capacity`, `accessModes`, `persistentVolumeReclaimPolicy`, `storageClassName`, and `hostPath.path` (or NFS server/path/protocol version v3/v4.0/v4.1 detected via `nfsstat -s`). Documents access modes RWO/RWX/ROX, reclaim policies Delete vs Retain (Delete is unsupported for NFS Shared Storage), and update/delete day-2 operations.
- [docs/en/configure/storage/functions/create_pvc.mdx](docs/en/configure/storage/functions/create_pvc.mdx): How to create a PersistentVolumeClaim either dynamically (binds via StorageClass) or via static binding (using labels/selectors against existing PVs), choosing the access mode (RWO/RWX/ROX), capacity, and Volume Mode (Filesystem for any workload or Block Device for virtual machines only). Documents PVC binding, snapshot-based creation, deletion (and the resulting reclaim behaviour), and online capacity expansion via the UI or `kubectl patch pvc -p '{"spec":{"resources":{"requests":{"storage":"6Gi"}}}}'`.
- [docs/en/configure/storage/functions/nfs_storageclass.mdx](docs/en/configure/storage/functions/nfs_storageclass.mdx): How to create an NFS Shared Storage StorageClass backed by the community NFS CSI driver, including installing the `Alauda Container Platform NFS CSI` cluster plugin (module-name `nfs`) and configuring Service Address, Path, NFS Protocol Version (v3/v4.0/v4.1), Reclaim Policy, Access Modes (RWO/RWX/ROX), allocated projects, and `subDir` naming. Strongly recommends `subDir` patterns like `${pvc.metadata.namespace}_${pvc.metadata.name}_${pv.metadata.name}` (or with a cluster identifier prefix for multi-cluster shared servers) to guarantee unique non-conflicting subdirectory names and warns against using `-` separators or nested `/` paths.
- [docs/en/configure/storage/functions/snapshot_con.mdx](docs/en/configure/storage/functions/snapshot_con.mdx): How to deploy the `Alauda Container Platform Snapshot Management` cluster plugin (module-name `snapshot`) so dynamically-provisioned PVCs from supporting StorageClasses can be snapshotted, including a support matrix showing TopoLVM/CephRBD snapshot PVCs support RWO only, while CephFS supports RWO/ROX/RWX (with ROX bolded as different from non-snapshot CephFS behaviour).
- [docs/en/configure/storage/functions/topolvm_storageclass.mdx](docs/en/configure/storage/functions/topolvm_storageclass.mdx): How to create a TopoLVM local-storage StorageClass for LVM-based per-node storage suitable for databases, real-time indexing, and dev/test workloads, including Device Class (Automatically Assigned or specific), File System (XFS or EXT4 with 1 EiB / 16 TiB limits), Reclaim Policy, RWO-only access, automatic online expansion, and the PVC Reconstruction option with a configurable wait time that recreates a PVC on another node after a node failure (without preserving original data). Notes that local storage should only be used for applications with their own data replication.
- [docs/en/configure/storage/functions/using_volume_snapshot.mdx](docs/en/configure/storage/functions/using_volume_snapshot.mdx): How to create a `snapshot.storage.k8s.io/v1` VolumeSnapshot from a dynamically-provisioned, Bound PVC (with `snapshot.cpaas.io/sourcepvc` label and `volumeSnapshotClassName` referencing the storage class's snapshot class) via two Web Console workflows on the PVC list/details pages or the Volume Snapshots page. Documents using snapshots as the data source for new PVCs and the snapshot-to-PVC access-mode compatibility (TopoLVM/CephRBD RWO-only; CephFS RWO/ROX/RWX).
- [docs/en/configure/storage/how_to/configuring_persistent_localstorage.mdx](docs/en/configure/storage/how_to/configuring_persistent_localstorage.mdx): How to install the `Alauda Build of LocalStorage` operator (channel `stable`, namespace `acp-storage`) and use the `local.storage.openshift.io/v1` LocalVolume CR to statically provision local-disk PVs by listing `devicePaths` (e.g., `/dev/disk/by-id/wwn-...`), nodeSelector, `storageClassDevices.storageClassName`, `volumeMode` (Filesystem or Block), and `fsType`. Includes the destructive `forceWipeDevicesAndDestroyAllData` flag (default false), and a `LocalVolumeDiscovery` CR for auto-discovery of available block devices producing per-node `LocalVolumeDiscoveryResult` objects.
- [docs/en/configure/storage/how_to/configuring_persistent_storage.mdx](docs/en/configure/storage/how_to/configuring_persistent_storage.mdx): How to manually create an NFS-backed PV (`spec.nfs.server`/`.path`, `accessModes`, `persistentVolumeReclaimPolicy: Retain`) and a matching PVC that references it by name. Documents enforcing disk quotas via partitioned exports, NFS volume security (POSIX UID/GID handling with `securityContext.supplementalGroups` recommended over `runAsUser`), required export options (`rw,sync,root_squash,no_subtree_check`), firewall ports (2049 for NFSv4; 2049, 20048, 111 for NFSv3), and the recommendation to create a new PV name when reusing a released NFS share rather than manually editing the PV status.
- [docs/en/configure/storage/how_to/configuring_pvc_dr.mdx](docs/en/configure/storage/how_to/configuring_pvc_dr.mdx): End-to-end disaster-recovery guide for cross-cluster PVC replication using the `Alauda Build of VolSync` operator (deployed in `volsync-system`), requiring CSI storage with snapshot support and Snapshot Management on both Primary and Secondary clusters. Documents the `rsync-tls` Secret (`psk.txt` formatted `<id>:<at-least-32-hex>`), `ReplicationDestination` (with `copyMethod: Snapshot`, `destinationPVC`, `serviceType` ClusterIP/LoadBalancer/NodePort, `storageClassName`, `volumeSnapshotClassName`), `ReplicationSource` (with `trigger.schedule` cron for scheduled or `trigger.manual: <id>` for one-time syncs) and full procedures for planned migration, failover (restoring a PVC via `dataSourceRef.kind: ReplicationDestination` plus a local one-time sync), and failback.
- [docs/en/configure/storage/how_to/generic_ephemeral_volumes.mdx](docs/en/configure/storage/how_to/generic_ephemeral_volumes.mdx): How to use Kubernetes Generic Ephemeral Volumes in a Pod by embedding a `volumes[].ephemeral.volumeClaimTemplate` (with `accessModes`, `resources.requests.storage`, and `storageClassName`) so the platform dynamically provisions a per-pod PVC via the chosen CSI driver and deletes it when the Pod terminates. Compares against `emptyDir` (CSI-backed instead of node-local, supports snapshots/encryption/resizing, reschedulable).
- [docs/en/configure/storage/how_to/third_mask.mdx](docs/en/configure/storage/how_to/third_mask.mdx): How to annotate a third-party StorageClass's capabilities by creating a ConfigMap in the `kube-public` namespace whose name starts with `sd-` (e.g., `sd-capabilities-enhanced`), labelled `features.alauda.io/type: StorageDescription`, with one data key per provisioner mapping to YAML that declares `snapshot` (bool), `volumeMode` (`Filesystem`/`Block`), `accessModes`, and `blockAccessModes`. Notes the PVC UI dynamically filters options based on this metadata and falls back to `accessModes` when `blockAccessModes` is missing.
- [docs/en/configure/storage/how_to/using_empty_dir.mdx](docs/en/configure/storage/how_to/using_empty_dir.mdx): How to use Kubernetes `emptyDir` for ephemeral, node-local volumes mounted into a Pod (created at scheduling, deleted at Pod removal) via `volumes[].emptyDir: {}`, including the optional `medium: "Memory"` setting that backs the volume with tmpfs for faster (but volatile) access. Lists typical use cases (caching, log buffering, sidecar inter-container data sharing).
- [docs/en/configure/storage/intro.mdx](docs/en/configure/storage/intro.mdx): Short concept introduction to Kubernetes storage on the platform: Volumes, PersistentVolumes, and PersistentVolumeClaims abstract storage from applications, with support for multiple backends (local disks, NFS, cloud), dynamic provisioning, access mode control, and lifecycle management to meet stateful workload needs for developers, operators, and platform teams.
- [docs/en/configure/storage/trouble_shooting/detach_csi_volumes_non_graceful_shutdown.mdx](docs/en/configure/storage/trouble_shooting/detach_csi_volumes_non_graceful_shutdown.mdx): Procedure for manually detaching CSI-backed persistent volumes after a non-graceful node shutdown in Alauda Container Platform by applying the `node.kubernetes.io/out-of-service=nodeshutdown:NoExecute` taint to trigger Pod eviction and volume detachment. Covers prerequisites (node fully powered off), taint verification with `kubectl describe`, StatefulSet replacement-Pod ordering, and removing the taint after node recovery.
- [docs/en/configure/storage/trouble_shooting/recovery_pvc_expansion.mdx](docs/en/configure/storage/trouble_shooting/recovery_pvc_expansion.mdx): Recovery steps when a PVC expansion fails in Kubernetes: change the PV reclaim policy to `Retain`, delete the original PVC, remove the PV's `claimRef` so it becomes `Available`, recreate the PVC at a supported size with an explicit `volumeName` matching the original PV, and restore the reclaim policy. Notes that `StorageClass.allowVolumeExpansion: true` is required and warns about data-loss risk.

## costmanagement

- [docs/en/costmanagement/cost_management.mdx](docs/en/costmanagement/cost_management.mdx): Brief landing entry introducing Alauda Cost Management as a cloud-native billing product for detailed resource management and cost control; the actual content is rendered from an external site via the `<ExternalSite name="costmanagement" />` include.

## developer

- [docs/en/developer/building_application/application_observability/event.mdx](docs/en/developer/building_application/application_observability/event.mdx): Walkthrough for viewing Kubernetes resource Events on the Container Platform Deployment details page, explaining event card fields (Resource Type icon abbreviations P/RS/D/SVC, Reason such as FailedScheduling, Level Normal/Warning, Last Occurrence time and count) and noting the default 1-hour Event TTL with a pointer to All Events for historical data.
- [docs/en/developer/building_application/application_observability/log.mdx](docs/en/developer/building_application/application_observability/log.mdx): Guide for viewing real-time container logs on a workload's Logs tab, covering controls like Pod/Container selector, Previous Logs (for restartCount > 0), buffer Lines (1k/10k/100k), Wrap Line, Find, Raw, Export, and Full Screen, plus a warning about 2000-character truncation and copy reliability when ANSI color codes are present.
- [docs/en/developer/building_application/application_observability/monitor.mdx](docs/en/developer/building_application/application_observability/monitor.mdx): How to view workload monitoring dashboards for Applications, Deployments, DaemonSets, StatefulSets, Pods, and Namespace-level overviews, with metric definitions (CPU/Memory Utilization vs Usage, Network Traffic and Packet rates, Disk Rate and IOPS). Explains the `cpaas.io/dashboard.folder: container-platform` and `cpaas.io/dashboard.tag.overview: "true"` labels needed to surface a custom dashboard, with the 15-pod top-N display limit.
- [docs/en/developer/building_application/application_workloads/container.mdx](docs/en/developer/building_application/application_workloads/container.mdx): Reference for working with containers and Ephemeral Containers (Kubernetes 1.25+ `kubectl debug`) on Alauda Container Platform, including debugging via web console with the Pod > Debug action, common debug images (busybox, ubuntu, nicolaka/netshoot), and interacting with running containers using `kubectl exec`, `kubectl cp`, and the platform's EXEC and File Transfer features.
- [docs/en/developer/building_application/application_workloads/cronjob_create.mdx](docs/en/developer/building_application/application_workloads/cronjob_create.mdx): Creating, executing, and deleting Kubernetes CronJobs via CLI and the Container Platform web console, including a `batch/v1` YAML example and configuration parameters: `schedule` (crontab syntax with timezone support on K8s ≥ 1.25), Concurrency Policy (Allow/Forbid/Replace), history limits (default 20), Job Type (Non-parallel, Parallel, Indexed), Backoff Limit, and the `kubectl create job --from=cronjob/...` ad-hoc execution command.
- [docs/en/developer/building_application/application_workloads/deamonset_create.mdx](docs/en/developer/building_application/application_workloads/deamonset_create.mdx): Creating and managing DaemonSets via CLI (with a fluentd-elasticsearch `apps/v1` YAML example using tolerations for control-plane nodes) and the Container Platform web console, including `rollingUpdate` `maxUnavailable` (with absolute or percentage values), node-eligibility rules around `nodeSelector`, taints/tolerations, `kubectl cordon`, and constraints that exclude `NotReady` or `Unschedulable` nodes.
- [docs/en/developer/building_application/application_workloads/deployment_create.mdx](docs/en/developer/building_application/application_workloads/deployment_create.mdx): End-to-end Deployment lifecycle reference: YAML example, web-console wizard covering Basic Info (replicas, `maxSurge`/`maxUnavailable` rolling-update strategy with absolute and percentage rules), Pod section (Volumes, Pull Secret, Close Grace Period, Node Selector, Pod Affinity/Anti-affinity, Kube-OVN/Calico network bandwidth, subnet and static IP), Container section (resource Requests/Limits with namespace overcommit, extended resources, Volume Mounts, Ports, Startup Commands, env vars, ConfigMap/Secret refs, Health Checks, log file collection paths), CLI `kubectl set image`, `kubectl rollout status`, scaling, rollback, and troubleshooting commands.
- [docs/en/developer/building_application/application_workloads/job_create.mdx](docs/en/developer/building_application/application_workloads/job_create.mdx): Overview and YAML example for Kubernetes `batch/v1` Jobs, describing `spec.completions`, `spec.parallelism`, `spec.backoffLimit` (default 6), and Pod `restartPolicy: Never|OnFailure`, plus CLI commands to apply, list (`kubectl get jobs`), inspect (`kubectl describe job/...`), and view Pod logs.
- [docs/en/developer/building_application/application_workloads/pod.mdx](docs/en/developer/building_application/application_workloads/pod.mdx): Pod fundamentals with a sample manifest (resource requests/limits, ports) and CLI operations for listing, describing, streaming logs (`-f`), execing into containers, port-forwarding (`kubectl port-forward`), and deleting Pods. Includes web-console viewing/deletion procedures and a detailed table explaining Pod-level resource aggregation logic for standard and init containers (sum of containers and max of initContainers).
- [docs/en/developer/building_application/application_workloads/statefulset_create.mdx](docs/en/developer/building_application/application_workloads/statefulset_create.mdx): Creating and managing StatefulSets (stable DNS identity `<name>-<ordinal>.<service>.ns.svc.cluster.local`, `volumeClaimTemplates`, ordered scaling and reverse-ordinal rolling updates) via CLI with an `apps/v1` example using a headless Service, and via the web console with Replicas, `RollingUpdate` Partition (ordinal threshold), and PVC template fields (access modes RWO/ROX/RWX, StorageClass, storage capacity, dynamic expansion). Covers scaling, rollout status, and deletion behavior that preserves PVCs/PVs unless explicitly removed.
- [docs/en/developer/building_application/build_application_architecture.mdx](docs/en/developer/building_application/build_application_architecture.mdx): High-level architecture of Alauda Container Platform's application-build stack and its core components: Archon (advanced application/resource APIs on the `global` cluster), Metis (admission webhooks for resource ratios and labeling, Helm/quota/application status reconciliation on business clusters), Captain controller manager (Helm chart install/upgrade/rollback/uninstall on the global cluster), and Icarus (centralized web console with Kubernetes RBAC-based multi-tenancy).
- [docs/en/developer/building_application/concepts/application_type.mdx](docs/en/developer/building_application/concepts/application_type.mdx): Catalog of application types creatable under Container Platform > Applications: Custom Application (Deployments/StatefulSets + Services, created from Image, YAML, or Source/S2I), Helm Chart Application (Helm-packaged Kubernetes resources), and Operator-Backed Application (Operator-managed lifecycle automation), with links to the create-from-image, YAML, S2I, working-with-Helm, and Operator app guides.
- [docs/en/developer/building_application/concepts/custom_application.mdx](docs/en/developer/building_application/concepts/custom_application.mdx): Concept reference for Custom Applications built on the `app.k8s.io/v1beta1` Application CRD and the companion ApplicationHistory CRD, which aggregate Deployments, Services, Ingresses, and other native resources into one logical unit. Includes the full Application and ApplicationHistory CRD YAML (with `spec.componentKinds`, `assemblyPhase`, descriptor, info, selector, and `revision`/`yaml` snapshots), and explains capabilities like state aggregation, dependency declarations, version rollback, and GitOps integration with Argo CD.
- [docs/en/developer/building_application/concepts/understanding_environment_variables.mdx](docs/en/developer/building_application/concepts/understanding_environment_variables.mdx): Tutorial on Kubernetes environment variables, covering all source types (static values, `configMapKeyRef`, `secretKeyRef`, `fieldRef` for pod metadata like `metadata.name`/`status.podIP`/`spec.nodeName`, and `resourceFieldRef` for requests/limits), the precedence chain (env > envFrom > Dockerfile ENV > app defaults), and practical patterns including `envFrom` for ConfigMap/Secret bulk injection, service discovery URLs, and multi-container shared configuration with sidecars.
- [docs/en/developer/building_application/concepts/understanding_parameters.mdx](docs/en/developer/building_application/concepts/understanding_parameters.mdx): Reference for the Pod `args` field, explaining how it overrides the Dockerfile CMD while preserving ENTRYPOINT, with the args-vs-command-vs-image interaction matrix. Includes `kubectl run -- --port=8080 ...` examples, parameter design best practices (named flags, no secrets in args, ConfigMap-driven config files), and advanced patterns like init-container-generated args files and Helm parameter templating.
- [docs/en/developer/building_application/concepts/understanding_startup_commands.mdx](docs/en/developer/building_application/concepts/understanding_startup_commands.mdx): Reference for the Pod `command` field, mapping ENTRYPOINT to `command` and CMD to `args` with the override interaction matrix. Covers debug-shell overrides (`command: ["/bin/bash"]`), multi-step bash initialization via `exec /usr/bin/myapp`, signal trapping for graceful SIGTERM shutdown with `trap`, `kubectl run --command` syntax, conditional startup based on `APP_MODE`, and sidecar containers (Fluent Bit log shipper, node-exporter metrics).
- [docs/en/developer/building_application/concepts/unit.mdx](docs/en/developer/building_application/concepts/unit.mdx): Resource-unit reference listing CPU units (`core`, `m` millicore where 1 core = 1000 m), memory units (`Mi` = 2^20 bytes, `Gi` = 2^30 bytes, 1 Gi = 1024 Mi), Virtual GPU sizing (100 virtual cores = 1 physical GPU), and Video Memory units (1 unit = 256 Mi).
- [docs/en/developer/building_application/concepts/workload_types.mdx](docs/en/developer/building_application/concepts/workload_types.mdx): Catalog of workload controllers creatable under Container Platform > Workloads — Deployment (stateless rolling updates), DaemonSet (per-node pods for logging/monitoring), StatefulSet (stable DNS identity and persistent storage for databases), CronJob (cron-scheduled batch tasks), Job (one-shot finite tasks) — plus links to Pod and Container CLI-only resources.
- [docs/en/developer/building_application/configuration/add_bucket.mdx](docs/en/developer/building_application/configuration/add_bucket.mdx): Procedure to create a Bucket Request from the Container Platform Storage > Bucket Requests page, requiring the Object Storage Interface plugin. Configure Name and Object Storage Class to dynamically provision a bucket and wait for status `Available`; deletion clears bucket data.
- [docs/en/developer/building_application/configuration/add_configmap.mdx](docs/en/developer/building_application/configuration/add_configmap.mdx): How to define and consume Kubernetes ConfigMaps for non-sensitive configuration, with web-console creation (Entries via Add/Import paste of `key=value` lines, Binary Entries up to 1 MB) and CLI `kubectl create configmap --from-literal/--from-env-file`. Includes consumption patterns (`envFrom: configMapRef`, individual `configMapKeyRef`, volume mounts at `/etc/config`), the same-namespace restriction, and a ConfigMap-vs-Secret comparison.
- [docs/en/developer/building_application/configuration/add_secret.mdx](docs/en/developer/building_application/configuration/add_secret.mdx): Guide to Kubernetes Secret types supported in Alauda Container Platform — Opaque, `kubernetes.io/tls`, `kubernetes.io/ssh-auth`, `kubernetes.io/basic-auth`, `kubernetes.io/dockerconfigjson` Image Pull Secret — with CLI examples (`kubectl create secret generic/docker-registry/tls`) and base64-decoded contents. Covers consuming Secrets via `secretKeyRef` env vars or volume mounts, web-console auto base64 encoding, and a warning to avoid deleting platform-generated `service-account-token` and kube-system Secrets.
- [docs/en/developer/building_application/create_applications/chart_app.mdx](docs/en/developer/building_application/create_applications/chart_app.mdx): Procedure to create an application from a Helm Chart via Applications > Create > Create from Catalog, selecting a chart and tuning `resources.requests`/`resources.limits`. Documents status conditions Initialized/Validated/Synced with failure reasons such as `ChartLoadFailed`, `DependenciesCheckFailed`, `PermissionCheckFailed`, `ConsistentNamespaceCheckFailed`, and `ChartSyncFailed`, and notes the need to set `nodeSelector: kubernetes.io/os: linux` in mixed Linux/Windows clusters.
- [docs/en/developer/building_application/create_applications/cli.mdx](docs/en/developer/building_application/create_applications/cli.mdx): Guide for creating applications with `kubectl` via the Alauda Container Platform Web Terminal plugin. Shows a complete YAML example with an `app.k8s.io/v1beta1` Application aggregating a Deployment and a Service (ClusterIP nginx:1.25-alpine), and the corresponding `kubectl apply -f` commands targeting `${CURRENT_NAMESPACE}`.
- [docs/en/developer/building_application/create_applications/image_app.mdx](docs/en/developer/building_application/create_applications/image_app.mdx): End-to-end web-console flow for Applications > Create > Create from Image, covering Workload basics (Deployment/DaemonSet/StatefulSet model, replicas, `maxSurge`/`maxUnavailable`), Pod options (volumes, image credential, node affinity, Kube-OVN/Calico networking), Containers (resource requests/limits, extended resources, volume mounts, ports, env vars, ConfigMap/Secret refs, health checks with default Initial Delay 300s, Period 60s, Failure Threshold 5, log paths), plus optional Service and Ingress sections and Update vs Force Update vs Delete management actions.
- [docs/en/developer/building_application/create_applications/oam_app.mdx](docs/en/developer/building_application/create_applications/oam_app.mdx): Two flows to create Open Application Model (OAM) applications via the KubeVela-based Application Management plugin: a form-based wizard (Create from Image, then Add Component with traits and properties) and a YAML import (Create from YAML) referencing the [OAM spec](https://github.com/oam-dev/spec). Notes that exporting and re-importing requires renaming the application and components to avoid namespace conflicts.
- [docs/en/developer/building_application/create_applications/operator_app.mdx](docs/en/developer/building_application/create_applications/operator_app.mdx): Concept and procedure for Operator-Backed Applications managed by the Operator Lifecycle Manager (OLM), listing the supporting CRDs (CatalogSource, ClusterServiceVersion, InstallPlan, OperatorGroup, Subscription) with links to operator-framework upstream definitions. Walks the Create from Catalog flow (configure CR fields such as `spec.replicas`, `spec.resources.limits`, `spec.resourceQuota`, `spec.storage.className`) and gives troubleshooting commands like `kubectl get events --field-selector involvedObject.kind=...` and `kubectl api-resources | grep ...`.
- [docs/en/developer/building_application/create_applications/s2i_app.mdx](docs/en/developer/building_application/create_applications/s2i_app.mdx): Brief procedure for the Source-to-Image (S2I) creation flow under Applications > Create > Create from Code, which requires the Alauda Container Platform Builds operator. Points to the s2i application-management reference for detailed parameter configuration.
- [docs/en/developer/building_application/create_applications/yaml_app.mdx](docs/en/developer/building_application/create_applications/yaml_app.mdx): Procedure for the Applications > Create > Create from YAML flow, with a sample multi-document YAML containing an `apps/v1` Deployment (3 replicas, nginx:1.25-alpine, resource requests 100m/128Mi and limits 250m/256Mi) and a ClusterIP Service. Notes the requirement to set `nodeSelector: kubernetes.io/os: linux` in mixed Linux/Windows clusters and to verify images with `podman pull`.
- [docs/en/developer/building_application/how_to/cronjob_rules.mdx](docs/en/developer/building_application/how_to/cronjob_rules.mdx): Crontab reference for scheduled task triggers: time-zone conversion math (e.g., Beijing time minus 8 hours equals UTC, with wrap-around to the previous day), the `minute hour day month weekday` value ranges with `,`/`-`/`*`/`/` special characters, and several concrete examples like `30 18 25 12 *`, `0,30 18-23 * * *`, and `0 11 4 * mon-wed` with crontab.guru as the conversion reference.
- [docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx](docs/en/developer/building_application/how_to/sa_imagepullsecret.mdx): How to attach an ImagePullSecret to a Kubernetes ServiceAccount (named `example` or `default`) so Pods can pull from a private registry. Provides the `kubectl patch serviceaccount ... -p '{"imagePullSecrets": [{"name": "my-registry-creds"}]}'` command, verifies with `kubectl describe serviceaccount`, and inspects propagation via `kubectl get pod ... -o=jsonpath='{.spec.imagePullSecrets}'`.
- [docs/en/developer/building_application/how_to/service_certificate.mdx](docs/en/developer/building_application/how_to/service_certificate.mdx): How to enable automatic TLS serving certificate provisioning for Services using cert-manager and Kyverno. Administrators deploy a `kyverno:serving-certs` ClusterRole, a `service-root-ca` Certificate referencing the `cpaas-ca` ClusterIssuer, and three ClusterPolicies (`clone-ca-secret`, `sync-ca-rotation`, `generate-service-cert`); developers then annotate a Service with `service.alauda.io/serving-cert-secret-name` to trigger a cert-manager Certificate with the four standard service DNS names and mount the resulting `tls-cert` and `service-root-ca` Secrets into workloads.
- [docs/en/developer/building_application/namespace/create_namespace.mdx](docs/en/developer/building_application/namespace/create_namespace.mdx): How to create a Namespace through Project Management > Namespaces, the `ac adm new-project-namespace` CLI command, and `kubectl apply` with sample YAMLs for the Namespace (with `pod-security.kubernetes.io/audit|enforce|warn: baseline` labels), a `ResourceQuota`, and a `LimitRange`. Documents the project-prefix naming rule, GPU/vGPU unit conversion (100 vGPU = 1 pGPU, 1 memory unit = 256 MiB), default-unbounded quotas, and storage-class quota allocation.
- [docs/en/developer/building_application/namespace/import_namespace.mdx](docs/en/developer/building_application/namespace/import_namespace.mdx): How to bring existing cluster Namespaces under platform Project governance via the Import Namespace feature, including cross-cluster centralization, disassociation/re-association workflows, and constraints (a Namespace can only belong to one Project at a time, and the target Project must already be linked to the cluster).
- [docs/en/developer/building_application/namespace/limit_range.mdx](docs/en/developer/building_application/namespace/limit_range.mdx): Walkthrough for creating a Kubernetes `LimitRange` admission controller per namespace that injects default container Request/Limit/Max for CPU and memory. Includes a YAML example with `default: cpu=100m, memory=100Mi`, `defaultRequest: cpu=50m, memory=50Mi`, and `max: cpu=1000m, memory=1000Mi`, plus the `kubectl apply` and `kubectl create limitrange` direct-command syntax.
- [docs/en/developer/building_application/namespace/manage_namespace.mdx](docs/en/developer/building_application/namespace/manage_namespace.mdx): How to update a Namespace's `ResourceQuota`, `LimitRange`, and Pod Security Admission (`enforce`/`audit`/`warn`) settings via the web console (Actions > Update Quota / Update Container LimitRange / Update Pod Security Admission) and the equivalent `kubectl edit resourcequota/limitrange ...` CLI commands.
- [docs/en/developer/building_application/namespace/remove_namespace.mdx](docs/en/developer/building_application/namespace/remove_namespace.mdx): Differentiates permanently deleting a Namespace (`kubectl delete namespace`, which removes all contained resources and releases quota) from removing it from a Project while keeping the cluster namespace intact (`kubectl label namespace <ns> cpaas.io/project- --overwrite`), the latter being an Alauda Container Platform-only feature.
- [docs/en/developer/building_application/namespace/resource_quota.mdx](docs/en/developer/building_application/namespace/resource_quota.mdx): Reference for Kubernetes `ResourceQuota` per namespace, listing the standard tracked fields (`requests.cpu`, `requests.memory`, `limits.cpu`, `limits.memory`, `pods`), storage quota types (All vs StorageClass-specific), Hami/NVIDIA GPU Device Plugin extended-resource quotas, and the custom Other Quota naming rules (qualified name, optional DNS-subdomain prefix, 63/253-char length limits, plus disallowed names like `limits.cpu`/`pods`).
- [docs/en/developer/building_application/namespace/security_policies.mdx](docs/en/developer/building_application/namespace/security_policies.mdx): Reference for namespace-level Pod security in ACP combining Kubernetes Pod Security Admission (Enforce/Audit/Warn modes, Privileged/Baseline/Restricted standards applied via `pod-security.kubernetes.io/enforce|audit|warn` labels with `kubectl label` or `PodSecurityConfiguration` exemptions) and the Kyverno Compliance plugin's pre-built sample policies (Restricted, Restricted-v2, Anyuid, Hostaccess, Hostmount-anyuid, Hostnetwork, Hostnetwork-v2, Node-exporter, Nonroot, Nonroot-v2, Privileged) applied via the console Samples tab or `consoleyamlsamples.console.alauda.io` resources.
- [docs/en/developer/building_application/namespace/uid_gid_assign.mdx](docs/en/developer/building_application/namespace/uid_gid_assign.mdx): How to auto-assign per-namespace UID/GID ranges in ACP by setting Pod Security Admission to Restricted and adding the `security.cpaas.io/enabled=true` label; the platform writes the allocated range into the `security.cpaas.io/uid-range` annotation (e.g., 1000002000-1000011999) and rejects Pods whose `runAsUser`/`fsGroup` fall outside the range.
- [docs/en/developer/building_application/namespace/update_member.mdx](docs/en/developer/building_application/namespace/update_member.mdx): How to manage Namespace members from Project Management > Namespaces > Namespace Members: bulk Import Members from the parent Project's roster (assigning roles like Namespace Administrator or Developer), Add a Member with an OIDC-IDP username (no validity check is performed at add time), and Remove a member to revoke their namespace-scoped roles.
- [docs/en/developer/building_application/namespace/update_overcommit.mdx](docs/en/developer/building_application/namespace/update_overcommit.mdx): Concept and procedure for the Namespace `NamespaceResourceRatio` (`resource.alauda.io/v1`) CRD that sets the CPU/memory overcommit ratio (Limits/Requests). Container Request is auto-calculated as `Limit / ratio`; the console offers Inherit from Cluster or Custom (integer > 1) modes, with `status.clusterCPU`/`status.clusterMemory` reflecting the cluster ratio. Notes that changes apply only to newly created Pods.
- [docs/en/developer/building_application/operation_maintaining/add_cronhpa.mdx](docs/en/developer/building_application/operation_maintaining/add_cronhpa.mdx): How to scale Deployments, ReplicaSets, or StatefulSets on a time schedule using the `CronHPA` resource (`tkestack.io/v1`). Provides a YAML example with multiple `crons` entries (e.g., `0 0 * * *` → 0 replicas, `0 8 * * 1-5` → 3 replicas, `0 18 * * 1-5` → 1 replica) and explains rule-priority resolution when schedules collide, conflict-avoidance with HPA, and the prerequisite that monitoring components are healthy.
- [docs/en/developer/building_application/operation_maintaining/add_hpa.mdx](docs/en/developer/building_application/operation_maintaining/add_hpa.mdx): How to configure `autoscaling/v2` HorizontalPodAutoscaler for Deployments, ReplicaSets, or StatefulSets via CLI (YAML example with `minReplicas: 3`, `maxReplicas: 7`, `targetCPUUtilizationPercentage: 75`) and the web console Elastic Scaling > Horizontal Scaling section. Documents supported metrics (CPU/Memory Utilization, Network Inbound/Outbound Traffic, Storage Read/Write Traffic), custom-metrics-api with Prometheus, `autoscaling/v2beta2` `target.averageUtilization`/`averageValue` syntax, the ±10% trigger band, and the scaling formula `replicas = ceil(sum(metric) / target)`.
- [docs/en/developer/building_application/operation_maintaining/add_vpa.mdx](docs/en/developer/building_application/operation_maintaining/add_vpa.mdx): How to install and configure the Alauda Container Platform Vertical Pod Autoscaler plugin (deployed via `violet` CLI). Provides a YAML example of `autoscaling.k8s.io/v1` `VerticalPodAutoscaler` with `updateMode: Off|Auto|Recreate|Initial`, container `mode: Auto|Off`, and walks the Elastic Scaling > Vertical Scaling console flow that shows recommended CPU/Memory values (with Lower Bound/Target/Upper Bound) after ~8 days of pod runtime, requiring pod recreation to apply.
- [docs/en/developer/building_application/operation_maintaining/application_delete.mdx](docs/en/developer/building_application/operation_maintaining/application_delete.mdx): Short note that deleting an application also removes all directly contained Kubernetes resources and severs any association the application had with non-owned resources.
- [docs/en/developer/building_application/operation_maintaining/application_rollouts/bluegreen_deployment.mdx](docs/en/developer/building_application/operation_maintaining/application_rollouts/bluegreen_deployment.mdx): End-to-end walkthrough for blue-green rollouts with Argo Rollouts on Alauda Container Platform: create a `hello:1.23.1` Deployment and matching `web` Service, then introduce an `argoproj.io/v1alpha1` `Rollout` with `strategy.blueGreen` referencing the workload via `workloadRef.scaleDown: onsuccess` and `activeService: web` with `autoPromotionEnabled: false`. Updating the image to `hello:1.23.2` creates a paused green ReplicaSet (4 pods total), then `kubectl argo rollouts promote rollout-bluegreen` flips the active service.
- [docs/en/developer/building_application/operation_maintaining/application_rollouts/canary_deployment.mdx](docs/en/developer/building_application/operation_maintaining/application_rollouts/canary_deployment.mdx): End-to-end walkthrough for canary rollouts using Argo Rollouts and the Gateway API plugin with ALB on ACP. Sets up stable and canary Services, a `gateway.networking.k8s.io/v1` Gateway with `gatewayClassName: exclusive-gateway` and an HTTPRoute with weighted backendRefs (`web-canary` 0%, `web-stable` 100%). The `Rollout` `strategy.canary` `steps` (`setWeight: 50`, `pause: {}`, `setWeight: 100`) and `trafficRouting.plugins.argoproj-labs/gatewayAPI` drive progressive shifting; `kubectl argo rollouts promote`/`abort` controls promotion and rollback.
- [docs/en/developer/building_application/operation_maintaining/application_rollouts/install_argo_rollouts.mdx](docs/en/developer/building_application/operation_maintaining/application_rollouts/install_argo_rollouts.mdx): Procedure for installing the Alauda Container Platform Argo Rollouts cluster plugin from the Marketplace: download the package, upload via Marketplace > Upload Packages, then install via Marketplace > Cluster Plugins.
- [docs/en/developer/building_application/operation_maintaining/application_upgrade.mdx](docs/en/developer/building_application/operation_maintaining/application_upgrade.mdx): How to update Custom Applications and manage their Kubernetes resources from Application Management > Native Applications > Actions > Manage Resources. Covers importing existing Deployments, DaemonSets, StatefulSets, Jobs, CronJobs, Services, Ingresses, PVCs, ConfigMaps, Secrets, and HorizontalPodAutoscalers (Job imports only support YAML-created jobs), removing/batch-removing resources to disassociate without deletion, image/imagePullPolicy updates, env-var changes through ConfigMap/Secret references, and the version-snapshot/cascade-delete benefits of association.
- [docs/en/developer/building_application/operation_maintaining/chart_upgrade.mdx](docs/en/developer/building_application/operation_maintaining/chart_upgrade.mdx): Notice that template (Chart) applications are being discontinued in favor of native applications, plus the same status condition reference (Initialized/Validated/Synced with failure reasons `ChartLoadFailed`, `InitializeFailed`, `DependenciesCheckFailed`, `PermissionCheckFailed`, `ConsistentNamespaceCheckFailed`, `ChartSyncFailed`) used in chart-app creation status analysis.
- [docs/en/developer/building_application/operation_maintaining/export.mdx](docs/en/developer/building_application/operation_maintaining/export.mdx): How to export a Custom Application as a Helm Chart (to a managed Chart or OCI Chart template repository, or as a local `.tgz`), as simplified or full YAML (toggling `Hide managedFields fields`), or directly to a Git code repository (Alpha, with existing/new-branch options and optional PR submission/auto-delete-source). Includes follow-up GitOps deployment via the GitOps integration and re-creating the app via the YAML or Chart creation flows in another namespace.
- [docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx](docs/en/developer/building_application/operation_maintaining/handle_resource_errors.mdx): Operations guide for preventing node OOM and disk exhaustion in Alauda Container Platform using kubelet eviction policies. Documents hard and soft eviction thresholds with the `<eviction_signal><operator><quantity>` syntax (`memory.available`, `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, `imagefs.inodesFree`), `eviction-soft-grace-period`, `eviction-pressure-transition-period` (default 5m), `system-reserved`/`allocatable` calculation, MemoryPressure/DiskPressure scheduler effects, the QoS-based eviction order (Guaranteed/Burstable/BestEffort) and `oom_score_adj` values, and a 10 GiB worked example.
- [docs/en/developer/building_application/operation_maintaining/healthcheck.mdx](docs/en/developer/building_application/operation_maintaining/healthcheck.mdx): Reference for Kubernetes `livenessProbe`, `readinessProbe`, and `startupProbe` with HTTP GET, exec, and TCP Socket mechanisms. Includes a YAML example with `httpGet` `/healthz` and `/ready`, console parameters (`initialDelaySeconds` default 300, `periodSeconds` default 60, `timeoutSeconds` default 30, `failureThreshold` default 5), and probe-failure troubleshooting via `kubectl describe pod`, `kubectl logs`, manual `kubectl exec` curl/nc tests, and resource-constraint analysis with `kubectl top pod`.
- [docs/en/developer/building_application/operation_maintaining/hotreload.mdx](docs/en/developer/building_application/operation_maintaining/hotreload.mdx): How to use the Load Configuration action on a ConfigMap detail page to manually trigger a config reload in a running container. Requires the ConfigMap to be mounted as a volume (not via env vars and not with `subPath`), then exec the appropriate command as `root` — for example `nginx -s reload` for Nginx or `kill -SIGHUP <pid>` for Logstash.
- [docs/en/developer/building_application/operation_maintaining/start_stop.mdx](docs/en/developer/building_application/operation_maintaining/start_stop.mdx): Brief procedure to Start or Stop an application from the Container Platform > Applications detail page using the Start/Stop action buttons.
- [docs/en/developer/building_application/operation_maintaining/status.mdx](docs/en/developer/building_application/operation_maintaining/status.mdx): Reference table of native-application statuses (Running, Partially Running, Stopped, Processing, No Computing Components, Failed) where numbers represent the count of computing components or Pods, and the analogous Deployment statuses Running/Processing/Stopped/Failed.
- [docs/en/developer/building_application/operation_maintaining/version.mdx](docs/en/developer/building_application/operation_maintaining/version.mdx): How to manage application version snapshots: Create Version Snapshot from Native Applications > Version Snapshot tab (the platform retains the latest 6 and auto-deletes older entries), and Roll Back to This Version from Historical Versions to restore prior application configuration. Also notes that snapshots can be distributed as a Chart for cross-cluster deployment.
- [docs/en/developer/building_application/working_with_helm_charts.mdx](docs/en/developer/building_application/working_with_helm_charts.mdx): Deep dive into Helm deployments on Alauda Container Platform: terminology (HelmRequest CRD, ChartRepo, Chart, Application Catalog), the Captain controller, the `alauda.io/create-app: "true"` annotation to sync HelmRequest to Application resources, and the Charon/Metis/Archon-api components. Includes a CLI walkthrough using `helm package`, API token issuance, `curl` calls against `/catalog/v1/chartrepos` and `/acp/v1/.../applications` for create/update/delete, image upload via `podman save`/`load`/`push`, plus a UI flow under Catalog > Helm Charts for Add Template, Upload Template, Manage Versions, and deleting specific versions.
- [docs/en/developer/faq.mdx](docs/en/developer/faq.mdx): Developer FAQ explaining why importing a namespace with multiple ResourceQuotas merges them into a single `default` ResourceQuota using the minimum value per field (with a worked example combining `a` and `b`), and why namespaces should have only one LimitRange before import (Kubernetes' selection among multiple LimitRanges is unpredictable; the platform only creates a `default` LimitRange when a single one is present).
- [docs/en/developer/images/how_to/creating_images.mdx](docs/en/developer/images/how_to/creating_images.mdx): Image-authoring best practices for the Alauda Container Platform Registry: reuse upstream base images via `FROM image:tag`, maintain backwards-compatible tags (`image:v1`, `image:v2`), avoid multiple processes per container, `exec` in wrapper scripts so signals reach the app at PID 1, consolidate `yum install ... && yum clean all -y` in a single RUN to avoid orphaned layer files, order Dockerfile instructions so frequently-changed ADDs come last, declare ports with `EXPOSE`, set `ENV` for versions, avoid default passwords and `sshd`, define `VOLUME` for persistent data, and use `LABEL` (e.g., `io.k8s.*` namespace) for metadata.
- [docs/en/developer/images/how_to/managing_images.mdx](docs/en/developer/images/how_to/managing_images.mdx): Image-pull and registry management on Alauda Container Platform: the three `imagePullPolicy` values (Always/IfNotPresent/Never) and the latest-tag default override; using image pull secrets by linking them to a ServiceAccount (`imagePullSecrets:` on the SA) or by inlining `imagePullSecrets` in a Pod or Argo Workflow spec (`argoproj.io/v1alpha1`), with reference to upstream Kubernetes "Pull an Image from a Private Registry".
- [docs/en/developer/images/overview.mdx](docs/en/developer/images/overview.mdx): Conceptual overview of OCI container images and registries on Alauda Container Platform: image vs container distinction, image registries (Quay.io, Alauda Container Platform Registry), repositories (e.g., `jenkins-2-centos7`), tags (`:v3.11.59-2`) and immutable SHA image IDs (`@sha256:...`), and the role of `nerdctl`/`container` CLI plus platform builder images for creating new images.
- [docs/en/developer/node_isolation_strategy/architecture.mdx](docs/en/developer/node_isolation_strategy/architecture.mdx): Brief architecture note explaining that Node Isolation Strategy is built on the Container Platform Cluster Core component and forcibly schedules a project's containers to nodes allocated to that project on each workload cluster.
- [docs/en/developer/node_isolation_strategy/concepts/node_isolation.mdx](docs/en/developer/node_isolation_strategy/concepts/node_isolation.mdx): Two-sentence concept definition: Node Isolation prevents containers from different projects from sharing the same node, eliminating cross-project resource contention and performance degradation.
- [docs/en/developer/node_isolation_strategy/functions/create_isolation_policy.mdx](docs/en/developer/node_isolation_strategy/functions/create_isolation_policy.mdx): How to create and delete a Node Isolation Strategy from Security > Node Isolation Strategy. Configure Project Exclusivity (when on, only Pods from selected projects can run on the listed nodes), pick one or more Projects (one project allows at most one strategy), and assign Nodes (each node belongs to at most one strategy). Notes that existing non-compliant Pods are only rescheduled on rebuild and existing nodes' Pods are not auto-evicted when exclusivity is enabled.
- [docs/en/developer/node_isolation_strategy/intro.mdx](docs/en/developer/node_isolation_strategy/intro.mdx): Short introduction to project-level Node Isolation Strategy, its core advantage of preventing cross-project resource contention, and its applicability when enhanced isolation between projects is required.
- [docs/en/developer/node_isolation_strategy/permissions.mdx](docs/en/developer/node_isolation_strategy/permissions.mdx): Stub page rendering the Kubernetes-permissions table for the `acp-nodegroups` function via the `<K8sPermissionTable>` component.
- [docs/en/developer/oam_applications/architecture.mdx](docs/en/developer/oam_applications/architecture.mdx): Architecture overview of OAM applications built on KubeVela components, traits (operational characteristics), and a unified application-resource layer, with a scenario architecture diagram covering the component-selection, trait-configuration, application-composition, and post-operation-management phases, and role splits between platform business developers, platform operations, and application operations.
- [docs/en/developer/oam_applications/concepts/component.mdx](docs/en/developer/oam_applications/concepts/component.mdx): Reference for built-in OAM components: Web Service (Kubernetes Deployment + Service for stateless workloads such as Nginx) and Stateful Service (StatefulSet + Service for data-persisting workloads). Documents the configurable parameters: image source (select from integrated repo or input `repo:tag`), Network Access (Protocol, Container Port, Internal Only vs Internal+External), Environment Variables, Storage Volumes (Storage/Config/Empty Directory with mount path), Startup Parameters, and Resource Limits.
- [docs/en/developer/oam_applications/concepts/cue.mdx](docs/en/developer/oam_applications/concepts/cue.mdx): Reference for using CUE to define custom OAM components and traits. Covers basic syntax (`parameter`, `output`, `outputs`, `?:`, `*1 | int` default, `\(key)` interpolation, `context.xxx`, `for`/`if`), required fields (`definition.oam.cpaas.io/provider: user` label, `namespace: kube-public`, `spec.schematic`), and trait-definition fields like `spec.workloadRefPath`, `spec.appliesToWorkloads`, `spec.conflictsWith`, `spec.podDisruptive`, `spec.manageWorkload`, `spec.skipRevisionAffect`, `spec.revisionEnabled`, and `spec.controlPlaneOnly`.
- [docs/en/developer/oam_applications/concepts/trait.mdx](docs/en/developer/oam_applications/concepts/trait.mdx): Catalog of OAM operational traits with YAML examples for each: Annotations and Labels (key-value metadata), Environment Variables (`env` type with `valueFrom.secretKeyRef`), Patches (`generic-patch` with JSON Patch add/replace/remove), Auto-scaling (`hpa` with metrics and scale-up/down `scalePolicy.stabilizationWindowSeconds`), Manual Scaling (`scaler`), Ingress Rules and Pure Ingress, Health Checks (httpGet/tcpSocket liveness and readiness), HostAliases, Lifecycle (postStart/preStop httpGet and tcpSocket), Custom Monitoring (PromQL `expression` with chart sources), and Resources (CPU/memory requests and limits).
- [docs/en/developer/oam_applications/functions/alarm_function.mdx](docs/en/developer/oam_applications/functions/alarm_function.mdx): How to view OAM-component monitoring and alerts in the Container Platform: the past-7-day Monitoring tab metrics (CPU, Memory, Network Traffic, Network Packets, Disk Rate/IOPS, vGPU/pGPU and their memory variants — each shown as Usage Rate = used/limit and absolute Usage Amount). The Alerts tab links to platform alert-policy creation, real-time alert handling, and notification-policy binding for email/SMS notifications.
- [docs/en/developer/oam_applications/functions/storage_function.mdx](docs/en/developer/oam_applications/functions/storage_function.mdx): Walks through adding new storage and configuration resources to an existing OAM application in the Container Platform UI under Application Management > OAM Applications > Application Resources, including selecting a storage class and capacity, choosing configuration types (Configuration Dictionary, Opaque, Username/Password, SSH Key, Image Service), and then mounting them as storage volumes or referencing them as environment variables from a component.
- [docs/en/developer/oam_applications/functions/version_function.mdx](docs/en/developer/oam_applications/functions/version_function.mdx): Describes how the platform records every UI- and API-initiated change to an OAM application as a numbered version, and how to use the Change Log tab on a component to compare any historical version with the current one or roll back to a chosen version.
- [docs/en/developer/oam_applications/how_to/component_style.mdx](docs/en/developer/oam_applications/how_to/component_style.mdx): Shows how to customize the display style of OAM ComponentDefinitions and TraitDefinitions on the platform by setting the definition.oam.cpaas.io/name, /tag, and /description annotations (with bilingual zh/en JSON values) and the definition.oam.cpaas.io/provider=user label, including a full ComponentDefinition YAML example with a CUE template that renders a Deployment so the custom component appears with a friendly name, tag, and description under Application Management > OAM Applications > Create > Add Component > More.
- [docs/en/developer/oam_applications/install_oamplugin.mdx](docs/en/developer/oam_applications/install_oamplugin.mdx): Placeholder page titled Install for the OAM Applications plugin; the file currently contains only frontmatter and a heading with no installation procedure.
- [docs/en/developer/oam_applications/intro.mdx](docs/en/developer/oam_applications/intro.mdx): Introduces OAM (Open Application Model) as a cloud-native application abstraction independent of the underlying platform and explains how OAM applications on the Container Platform differ from native Kubernetes apps, GitOps applications, and Helm-based template applications, highlighting cross-cluster delivery, programmable workflows, CUE-based extensibility, and multi-artifact (Kustomize/YAML/Chart) support.
- [docs/en/developer/oam_applications/permissions.mdx](docs/en/developer/oam_applications/permissions.mdx): Placeholder permissions reference page intended to enumerate the OAM Applications module's permission points and their mapping to built-in platform roles (Platform Administrator, Platform Auditor, Project Administrator, Namespace Administrator, Developer); currently contains only a sample table template.
- [docs/en/developer/oam_applications/quick_start/quick_start_builtin.mdx](docs/en/developer/oam_applications/quick_start/quick_start_builtin.mdx): Quick-start tutorial for first-time OAM users that walks through creating an OAM application from an image using the platform's built-in Network Service component and default operational traits, covering basic info (labels, annotations like cpaas.io/maintainer and app.<text>.url), TCP network access on port 80 with both internal and external access, and verifying the resulting tcp://<NodeIP>:<HostPort> external endpoint.
- [docs/en/developer/oam_applications/quick_start/quick_start_custom.mdx](docs/en/developer/oam_applications/quick_start/quick_start_custom.mdx): Intermediate quick-start that creates an OAM application using a custom ComponentDefinition for raw Kubernetes objects (k8s-objects-test) and a custom TraitDefinition that generates labels (labels-test), then assembles them in Application Management > OAM Application with Manual Scaling, and finishes by exposing the workload through a NodePort internal routing under Network > Internal Routing.
- [docs/en/developer/oam_applications/quick_start/quick_start_yaml.mdx](docs/en/developer/oam_applications/quick_start/quick_start_yaml.mdx): Shows the fastest path to create an OAM application by pasting an Application YAML directly into Application Management > OAM Applications > Create Application > Create via YAML, with notes on avoiding name collisions when reusing an exported YAML and a pointer to the OAM open-source spec at github.com/oam-dev/spec for hand-authoring application manifests.
- [docs/en/developer/operator/architecture.mdx](docs/en/developer/operator/architecture.mdx): Template stub for an Operator developer-guide architecture document, instructing authors to add technical architecture diagrams covering core components (Operator, Tasks, Middleware), data flow between introduced resources, and deployment topologies such as multi-cluster and HA designs, then link concepts back to a Core Concepts section.
- [docs/en/developer/operator/concepts/example_concept.mdx](docs/en/developer/operator/concepts/example_concept.mdx): Authoring template for Core Concepts pages in the Operator developer guide, with placeholder sections for two concepts and guidance on when to merge multiple simple concepts into one page versus splitting complex ones into separate documents or 'In-Depth Understanding of XXXX' articles.
- [docs/en/developer/operator/concepts/example_insight.mdx](docs/en/developer/operator/concepts/example_insight.mdx): Authoring template for in-depth concept explanations ('In-Depth Understanding of XXX') in the Operator developer guide, listing recommended sections such as Terminology, Why We Need <Name>, Advantages, Applicable Scenarios, Constraints and Limitations, Principles, Configuration Example, and Important Parameter Descriptions.
- [docs/en/developer/operator/functions/example_function.mdx](docs/en/developer/operator/functions/example_function.mdx): Authoring template for Function Guide pages in the Operator developer guide, explaining how function docs differ from HowTo docs (concept-driven 'what/why' vs. task-oriented 'how-to'), recommending CLI-first guidance, and providing a skeletal Function Introduction / Main Features / Function Advantages / Function Module structure with a Steps component.
- [docs/en/developer/operator/how_to/example_howto.mdx](docs/en/developer/operator/how_to/example_howto.mdx): Authoring template for HowTo pages in the Operator developer guide that emphasizes scenario-oriented, end-to-end task guidance and lists the recommended sections: Function Introduction, Usage Scenarios, Prerequisites, Operation Steps with parameter tables, Operation Results, Learn More, and Follow-Up Actions.
- [docs/en/developer/operator/installation.mdx](docs/en/developer/operator/installation.mdx): Authoring template for an Operator component's Deployment page with placeholder sections for Install XXX (Web Console and CLI methods), Uninstall XXX (deleting instances, then Operator, then CRDs), and Custom Configuration of installation-time options.
- [docs/en/developer/operator/intro.mdx](docs/en/developer/operator/intro.mdx): Authoring template for module or product introduction pages, explaining how to write Product/Module Introduction, Advantages, Application Scenarios, and Usage Restrictions sections, with guidance on when to split intros into separate files (multi-module products) versus merging them, and how product-level intros differ from module-level intros.
- [docs/en/developer/operator/permissions.mdx](docs/en/developer/operator/permissions.mdx): Authoring template for permissions reference pages, showing how to embed the <K8sPermissionTable functions={[...]}> MDX component to auto-generate the permission table from FunctionResource names.
- [docs/en/developer/operator/trouble_shooting/example_trouble_shooting.mdx](docs/en/developer/operator/trouble_shooting/example_trouble_shooting.mdx): Authoring template for problem-handling / troubleshooting pages, prescribing sections for Problem Description (with logs/screenshots), Root Cause Analysis, Problem Diagnosis steps (ordered for single cause or grouped under sub-headings for multiple causes), Solution(s), Preventive Measures, and Related Content.
- [docs/en/developer/operator/upgrade.mdx](docs/en/developer/operator/upgrade.mdx): Authoring template for an Operator component upgrade document, advising authors to include the upgrade process, configuration, and rollback procedure, and to split the page into per-version subdocuments (for example '3.10 Upgrade Guide', '3.18 Upgrade Guide') when version-specific differences are significant.
- [docs/en/developer/overview.mdx](docs/en/developer/overview.mdx): Top-level Developer overview that introduces the unified web console and CLI for managing cloud-native applications across namespaces with RBAC, then links out to the main workflows: namespace management (create/import), application lifecycle (Create from Image / Catalog / YAML / S2I Code, plus update, export, version rollback, delete), observability (logs, events, monitoring dashboards), and Kubernetes workload types (Deployments, StatefulSets, DaemonSets, CronJobs).
- [docs/en/developer/quick_start/quick_start_app.mdx](docs/en/developer/quick_start/quick_start_app.mdx): Beginner-friendly quick start that walks through creating a namespace under Project Management > Namespaces, configuring an image repository (either an integrated registry via Administrator > Toolchain > Integration or an external one like `nginx:latest`), creating a Deployment under Workloads > Deployments, exposing it with a NodePort Service (range 30000-32767), and validating accessibility at http://<Node_IP>:<NodePort>; includes guidance on ImagePullSecret and the limits of the NodePort allocation range.
- [docs/en/developer/registry/how_to/common_cli_command.mdx](docs/en/developer/registry/how_to/common_cli_command.mdx): CLI reference for the kubectl-acp plugin against the Alauda Container Platform Registry, covering kubectl acp login, granting per-namespace pull/push permission via `kubectl create rolebinding --clusterrole=system:image-puller|system:image-pusher` for users and ServiceAccounts, and pulling/pushing images with `kubectl acp pull` and `kubectl acp push` (including cross-namespace pulls and pushing from a remote registry like remote.registry.io to registry.cluster.local/<ns>/<image>:<tag>).
- [docs/en/developer/registry/how_to/use_registry_within_cluster.mdx](docs/en/developer/registry/how_to/use_registry_within_cluster.mdx): Best-practice guide for consuming the ACP Registry from inside the cluster, recommending the in-cluster service address `image-registry.cpaas-system.svc/<namespace>/<image>:<tag>` over the external ingress domain, noting that the per-namespace `default` ServiceAccount already has an imagePullSecret for it, and showing how administrators of a shared namespace can grant cross-namespace pull access via `kubectl create rolebinding --clusterrole=system:image-puller --serviceaccount=<src-ns>:default`; closes with troubleshooting for ImagePullBackOff and /etc/hosts DNS resolution for `image-registry.cpaas-system.svc`.
- [docs/en/configure/registry/install/install_via_web_ui.mdx](docs/en/configure/registry/install/install_via_web_ui.mdx): Walks through installing the Alauda Container Platform Registry cluster plugin from Administrator > Marketplace > Cluster Plugins via the web console, with parameter descriptions for Expose Service, Enable IPv6, NodePort, Storage Type (LocalVolume vs StorageClass with RWX requirement for replicas > 1), Storage Size, Replicas (1 fixed for LocalVolume, default 3 for StorageClass), and resource requests/limits; intended for first-time users and PoC setups (not production S3/ingress-customization scenarios).
- [docs/en/configure/registry/install/install_via_yaml.mdx](docs/en/configure/registry/install/install_via_yaml.mdx): Production-grade installation of the Alauda Container Platform Registry via a ClusterPluginInstance YAML for `image-registry`, covering full customization of OIDC (ldapID), ingress (hosts, tlsCert as namespace/secret, ingressClassName), persistence (storageClass, size, accessMode ReadWriteMany), and s3storage (bucket, region, regionEndpoint, secretName, REGISTRY_STORAGE_S3_SKIPVERIFY); includes the `kubectl create secret generic` command for AWS access keys and update/uninstall flows that edit or delete the corresponding `moduleinfo` resource on the global cluster.
- [docs/en/configure/registry/upgrade/registry_plugin_upgrade_guide.mdx](docs/en/configure/registry/upgrade/registry_plugin_upgrade_guide.mdx): Migration guide for upgrading from the legacy `internal-docker-registry` plugin (ACP <= v4.1) to the renamed `image-registry` plugin (ACP >= v4.2), with three storage-type-specific procedures: S3 (automatic data migration via rename in the backed-up ClusterPluginInstance YAML), NFS (manual PV Retain reclaim policy, claimRef release, and setting `config.persistence.volumeName` to the old PV), and Local (ssh cp -a between `/cpaas/internal-docker-registry/` and `/cpaas/image-registry/`), all followed by cleanup of the old moduleplugins and moduleconfig on the global cluster.
- [docs/en/developer/s2i/functions/s2i_application_management.mdx](docs/en/developer/s2i/functions/s2i_application_management.mdx): Detailed reference for managing applications created from source code (S2I) in Container Platform > Application > Create > Create from Code, documenting every form field: Code Repository (Platform Integrated GitLab/GitHub/Bitbucket or Input URL, version identifier branch/tag/commit, context dir, secret), Builder Image selection (Golang, Java, Node.js, Python) and Version, the Build flow (ClusterBuildStrategy / Build / BuildRun / TaskRun / Tekton Pod), output Image URL, and per-application Network and label/annotation settings; includes Rebuild for source updates.
- [docs/en/developer/s2i/how_to/s2i_howto.mdx](docs/en/developer/s2i/how_to/s2i_howto.mdx): Hands-on tutorial that uses Alauda Container Platform Builds to turn a Java sample (https://github.com/alauda/spring-boot-hello-world) into a running application via Create from Code, with concrete recommended values (Type: Input, Build Method: Build, target port 8080, application name `spring-boot-hello-world`) and references to the Builds installation prerequisite and ACP Registry.
- [docs/en/developer/s2i/install_builds/install_builds_operator.mdx](docs/en/developer/s2i/install_builds/install_builds_operator.mdx): Installs the Alauda Container Platform Builds operator via Administrator > Marketplace > OperatorHub (alpha channel, Cluster install mode, manual upgrade, shipyard-operator namespace) using the `violet` CLI to upload the Builds and Alauda DevOps Pipelines packages, then creates a Shipyard instance via OperatorHub > Create Instance, which enables the Container Platform > Applications > Create from Code S2I flow.
- [docs/en/developer/s2i/overview/architecture.mdx](docs/en/developer/s2i/overview/architecture.mdx): Architecture overview of Source to Image (S2I) on the platform showing that the Alauda Container Platform Builds operator orchestrates the end-to-end build lifecycle and that the actual build work is executed by Tekton pipelines via Kubernetes-native TaskRun resources, automating image builds from Git source and pushing to a designated image registry.
- [docs/en/developer/s2i/overview/intro.mdx](docs/en/developer/s2i/overview/intro.mdx): Introduces Alauda Container Platform Builds, the platform's cloud-native S2I + CI/CD tool that injects source code (Java, Go, Python, Node.js only) into a builder image and produces a runnable container image, with visual release management, Helm/GitOps integration, and full lifecycle management; warns that the Alauda DevOps Pipelines operator must be installed in OperatorHub as a prerequisite.
- [docs/en/developer/s2i/overview/lifecycle_policy.mdx](docs/en/developer/s2i/overview/lifecycle_policy.mdx): Support lifecycle table for the Alauda Container Platform Builds operator, listing v1.1.0 (released 2025-08-15, end of life 2027-08-15).
- [docs/en/developer/s2i/overview/releasenote.mdx](docs/en/developer/s2i/overview/releasenote.mdx): Release notes for the Alauda Container Platform Builds operator with its compatibility matrix (v1.1.0 paired with platform v4.1 and Alauda DevOps Pipelines v4.1) and a v1.1.0 changelog covering security vulnerability remediation and the move to an independently releasable cadence.
- [docs/en/developer/s2i/upgrade/upgrade_builds_operator.mdx](docs/en/developer/s2i/upgrade/upgrade_builds_operator.mdx): Upgrade procedure for the Alauda Container Platform Builds operator: download the new package, upload it with the `violet` CLI together with Alauda DevOps Pipelines, then open Administrator > Marketplace > OperatorHub on the target cluster, find the Alauda Container Platform Builds operator details page, and click Confirm to upgrade; includes a notice that users upgrading from v4.0 and earlier must first migrate Alauda DevOps Tekton v3 to Alauda DevOps Pipelines.

## devops

- [docs/en/devops/devops.mdx](docs/en/devops/devops.mdx): Short positioning page for Alauda DevOps, describing it as a container-based cloud application platform on native Kubernetes with unified workload scheduling and fine-grained multi-tenant permissions, and seamless orchestration of the DevOps toolchain; the actual documentation is hosted at the external `devops` site.

## extend

- [docs/en/extend/chart_repo.mdx](docs/en/extend/chart_repo.mdx): Single-pointer page that simply redirects readers to 'Working with Helm Charts' (../developer/building_application/working_with_helm_charts.mdx) for everything related to chart repositories and Helm charts.
- [docs/en/extend/cluster_plugin.mdx](docs/en/extend/cluster_plugin.mdx): Reference for the platform's Cluster Plugin system, managed by three cluster-level CRDs (ModulePlugin, ModuleConfig, ModuleInfo) with dynamic forms defined in `.spec.config` of ModuleConfig; covers installing plugins via Administrator > Marketplace > Cluster Plugins, YAML-based install on the global cluster with non-config (web-cli) and with-config (gpu-device-plugin with mps/pgpu/vgpu switches) examples, the cpaas.io/lifecycle-type values Core/Aligned/Agnostic and how each is upgraded, and the upgrade workflow including the 10-15 minute sync delay after uploads.
- [docs/en/extend/download_package.mdx](docs/en/extend/download_package.mdx): Reference for the `violet` CLI's download subcommands: `violet ac login`, `violet ac scenarios`, `violet ac packages`, `violet ac download-pkg` (core/extensions/standard), `violet ac download-app`, and `violet ac import-yaml`; includes installation instructions for Linux/macOS/Windows (binary placement under /usr/local/bin or /usr/bin), platform credential requirements, AC URL flags, optional `--scenario`/`--platformVersion`/`--arch` filters, and example workflows for batch and per-appID downloads.
- [docs/en/extend/operator.mdx](docs/en/extend/operator.mdx): Comprehensive Operator reference covering the OLM v0 architecture (olm-operator, Catalog Operator, CatalogSource, CSV, Subscription, InstallPlan, the system/platform/custom default CatalogSources), the five Operator source types (Alauda/Curated/Community/Marketplace/Custom), recommended Cluster (AllNamespaces) install mode for the OLM v1 future, Approval Strategy Manual/Automatic (Alauda Operators only support Manual), and YAML examples for both Manual (harbor-ce-operator) and Automatic (clickhouse-operator) Subscriptions, plus advanced `.spec.config.nodeSelector`/`tolerations` for scheduling Operator Pods onto infra nodes.
- [docs/en/extend/overview.mdx](docs/en/extend/overview.mdx): One-page overview of the platform's extension system, contrasting Operators (built on OLM v0 for automated management of complex apps) with Cluster Plugins (a proprietary system specifically designed for Chart-type plugins) and noting that both can be used to extend Kubernetes cluster capabilities.
- [docs/en/extend/upload_package.mdx](docs/en/extend/upload_package.mdx): Reference for the `violet` CLI's upload subcommands: `violet show` to preview Operator/Cluster Plugin/Helm Chart packages, `violet list` to export installed apps to apps.yaml, `violet gc` to clean up stale Artifact/ArtifactVersion/ModulePlugin/ModuleConfig in the global cluster, `violet verify` for checksum/GPG signature checks, and `violet push` to upload to the platform with options for `--clusters`, `--target-catalog-source`, `--dest-repo` for standby global clusters, and `--skip-crs`/`--skip-push`; emphasizes IPv6 address restrictions, platform-admin-system role requirement, and that Helm Charts can only go to the default `public-charts` repository.

## gitops

- [docs/en/gitops/gitops.mdx](docs/en/gitops/gitops.mdx): Short positioning page for Alauda Container Platform GitOps, an Argo CD-based Kubernetes-native GitOps solution that watches Git for application/infra manifests and synchronizes them to target clusters for Git-driven continuous delivery and multi-cluster distribution; the actual product docs live on the external `gitops` site.

## hardware_accelerator

- [docs/en/hardware_accelerator/hami.mdx](docs/en/hardware_accelerator/hami.mdx): Brief introduction to Alauda Build of HAMi (Heterogeneous AI Computing Virtualization Middleware, formerly k8s-vGPU-scheduler), an all-in-one chart for managing and sharing heterogeneous AI computing devices across Kubernetes tasks; full documentation lives on the external `hami` site.
- [docs/en/hardware_accelerator/npu/npu_operator/installation.mdx](docs/en/hardware_accelerator/npu/npu_operator/installation.mdx): Detailed install guide for the Alauda Build of NPU Operator on Ascend 910B/310P NPUs, covering online and offline (driver/firmware packages from gitcode npu-driver-installer plus optional MindIO SDK in /tmp/driver_pkg and /opt/openFuyao/mindio) prerequisites, master/worker node labels masterselector=dls-master-node and workerselector=dls-worker-node, deployment-form switches (Driver, Ascend Device Plugin, Ascend Docker Runtime, NPU exporter, Ascend Operator, NodeD, ClusterD, Resilience Controller, MindIO TFT, MindIO ACP), npuclusterpolicy/npu-smi verification, an ascend-pytorch validation Deployment with `huawei.com/Ascend310P` resource, an NPU exporter ServiceMonitor + Grafana dashboard import, and FAQ noting that uninstall must call `/usr/local/Ascend/driver/script/uninstall.sh`.
- [docs/en/hardware_accelerator/npu/npu_operator/intro.mdx](docs/en/hardware_accelerator/npu/npu_operator/intro.mdx): Brief intro to the NPU Operator, explaining how it uses the Operator Framework to automatically manage all software components (Ascend driver and firmware, MindCluster device plug-in) needed to expose Ascend NPUs to Kubernetes for AI training and inference, with a pointer to the upstream openFuyao NPU Operator documentation.
- [docs/en/hardware_accelerator/pgpu.mdx](docs/en/hardware_accelerator/pgpu.mdx): Short positioning page for the Alauda Build of NVIDIA GPU Device Plugin, a DaemonSet that exposes the number of GPUs per node, monitors GPU health, and enables GPU-enabled containers in Kubernetes; full docs are on the external `pgpu` site.

## hyperflux

- [docs/en/hyperflux/about.mdx](docs/en/hyperflux/about.mdx): Brief positioning page for Alauda Hyperflux, an AI-powered chat-bot assistant for the Container Platform that answers questions about operation steps, troubleshooting, and example generation; full docs live on the external `hyperflux` site.

## install

- [docs/en/install/global_dr.mdx](docs/en/install/global_dr.mdx): Complete disaster recovery runbook for the `global` control-plane cluster on traditional OS using an active/standby pair synchronized via etcd; covers required network resources (dedicated VIPs per cluster, unified domain, LB forwarding 80/443/6443/2379/11443), strict installer parameters (User-provisioned LB, identical certificate and image-repository credentials, domain-only Platform Access Address), the cross-cluster encryption-provider.conf copy, installing the `etcd Synchronizer` cluster plugin with bearer-token Secret etcd-sync-active-cluster-token, bootstrap Job and lease-based leader verification, sync status checks against the etcd-sync-monitor service, restart commands for Elasticsearch/VictoriaMetrics/cluster-transformer/warlock after failover, and a list of namespaces excluded from sync (cpaas-system, kube-ovn, kubevirt, nativestor-system, etc.).
- [docs/en/install/installing.mdx](docs/en/install/installing.mdx): Step-by-step installation procedure for the `global` cluster on traditional OS: upload and extract the Core Package into /root/cpaas-install, run `bash setup.sh` (with optional `--ip-family ipv6`) to launch the installer Web UI on port 8080, complete parameter configuration (Kubernetes version, cluster network protocol IPv4/IPv6/dual-stack, Cluster Endpoint, Platform Access Address, Certificate, Image Repository Platform Deployment vs External, Container Network with Kube-OVN Overlay restrictions, Node Name and Platform Exclusive isolation, 1 or 3 control plane nodes), a "Common Stalls and Where to Look" troubleshooting table for the typical install symptoms, and forced installer cleanup via `nerdctl rm -f minialauda-control-plane`. Validation and post-install tasks are linked out to dedicated pages.
- [docs/en/install/next_steps.mdx](docs/en/install/next_steps.mdx): Next steps after ACP Core validation. Prioritized post-install task table — Product Docs plugin install, Global Cluster Disaster Recovery, workload cluster onboarding, Extensions, identity and access setup, storage/networking/registry preparation, and backup/upgrade/observability docs — plus the inline Product Docs plugin install procedure.
- [docs/en/install/overview.mdx](docs/en/install/overview.mdx): Overview of installing ACP Core (`global` cluster) on traditional OS. Defines installation as deployment of the `global` cluster, separates Core from workload clusters, imported clusters, Extensions Packages, Operators, and Cluster Plugins, and provides the install route map across planning, preparation, download, installation, validation, and post-install tasks. Includes the Customer Portal sidebar and a redirect note for users running on Immutable Infrastructure (MicroOS on Huawei DCS, VMware vSphere, Huawei Cloud Stack).
- [docs/en/install/planning.mdx](docs/en/install/planning.mdx): Planning guide for ACP Core installation. Compares Multi-Cluster, Single Cluster, and Single Node deployment architectures; lists install-time decisions such as package architecture, IP family, endpoints, load balancing, certificates, image repository, nodes, and Global DR; and links to read-before-install source pages.
- [docs/en/install/prepare/download.mdx](docs/en/install/prepare/download.mdx): Instructions for downloading the ACP Core Package from the Alauda Customer Portal, picking between x86, ARM, and hybrid architectures, and the migration procedure for moving from a single-architecture install to hybrid (re-download hybrid Core Package, run `bash upgrade.sh --only-sync-image=true` to sync multi-architecture images to the registry, then remove the `cpaas.io/node-arch-constraint` label from the `cluster.platform.tkestack.io global` resource if present).
- [docs/en/install/prepare/node_preprocessing.mdx](docs/en/install/prepare/node_preprocessing.mdx): Comprehensive node preprocessing checklist for all control plane and worker nodes prior to global cluster install: supported OS/kernel matrix (RHEL 7.8/8.0/8.6/8.10/9.6, CentOS 7.6-7.9, Ubuntu 20.04/22.04 LTS, Kylin V10 SP3 for x86 and ARM/Kunpeng 920), the `init.sh` quick-configuration script, mandatory checks (transparent_hugepage=never, ip_vs/nf_conntrack/geneve/openvswitch kernel modules, disable apparmor/selinux/firewall/swap, sudo-without-password root SSH, DefaultTasksMax=infinity, hostname rules, /etc/hosts and /etc/resolv.conf rules, no occupation of control-plane ports 2379/2380/6443/10249-10256 and Kube-OVN 6641/6642 or Calico 179, removal of /var/lib/docker etc.), commands to detect/remove conflicting docker/podman/containerd/runc/kubernetes packages on RHEL/Ubuntu/Kylin, and DNS search-domain constraints (`domainCountLimit - 3`, MaxDNSSearchListChar=2048).
- [docs/en/install/prepare/prerequisites.mdx](docs/en/install/prepare/prerequisites.mdx): Pre-installation planning for the global cluster: deployment architecture selection (Multi-Cluster / Single Cluster / Single Node with min 12c24GB for PoC), ARM Kunpeng-920 sizing rule (1.5-2x x86), required network resources (`global` VIP, optional External IP, recommended Domain Name when IPv6 or DR is needed, optional trusted Certificate), network performance requirements (intra-cluster >= 1 Gbps & <= 10ms, cross-cluster >= 100 Mbps & <= 100ms), warning to avoid the 172.17-18 subnet used by nerdctl, and the load balancer forwarding rules table (443 for Web/API/registry HTTPS, 6443 for kube-apiserver, 11443 for the in-cluster image registry, with 2379 added for DR setups).
- [docs/en/install/validation.mdx](docs/en/install/validation.mdx): ACP Core post-install validation guide. Validates Web UI access, runs `kubectl` checks on the `global` cluster for node readiness, `ClusterModule/global` phase, failed AppReleases, and stuck Pods, and links forward to Next Steps when the cluster is healthy.

## networking

- [docs/en/networking/ingress_loadbalancing/ingress_loadbalance_with_envoy_gateway.mdx](docs/en/networking/ingress_loadbalancing/ingress_loadbalance_with_envoy_gateway.mdx): Guide to using Envoy Gateway (Kubernetes Gateway API on Envoy Proxy) for L7 ingress and load balancing in ACP, with full YAML examples for GatewayClass, Gateway with HTTP/HTTPS listeners and TLS Terminate via Secret certificateRefs, HTTPRoute matching by hostname/path, weighted backendRefs, cookie-based session affinity through a `BackendTrafficPolicy`, TLS Passthrough and mTLS modes, integration with MetalLB on bare metal via IPAddressPool + L2Advertisement, and troubleshooting tips for missing external IP, ignored HTTPRoute, broken TLS, and Envoy latency spikes.
- [docs/en/networking/observability/cli-usage.mdx](docs/en/networking/observability/cli-usage.mdx): Reference for the `kubectl-netobserv` CLI used for on-demand packet and flow capture; covers copying the binary out of the netobserv-controller-manager pod alongside `yq`, the two run modes (TUI for real-time inspection, background mode with `kubectl netobserv copy` and `cleanup`), filters for packet capture (`--cidr`, `--peer_ip`, `--protocol`, `--port`, `--enable_geneve`, `--enable_vxlan` for Kube-OVN overlay), pcapng export to Wireshark with rich Kubernetes-aware frame comments (Src/Dst Node, Owner, Network Name, MAC, Port), and JSON/SQLite export for flow capture with enriched K8s metadata.
- [docs/en/networking/observability/operator-deployment.mdx](docs/en/networking/observability/operator-deployment.mdx): End-to-end Operator-based deployment of NetObserv for continuous flow logging into a ClickHouse backend: optionally install the ClickHouse Operator via OperatorHub and create a `ClickHouseInstallation` (with example YAML using ShardAntiAffinity, sc-topolvm PVCs, password_sha256_hex auth and trace-log removal), install the Alauda Container Platform Network Observability Operator, create a `ck-auth` Secret with username/password keys in the FlowCollector namespace, then create a `FlowCollector` CR (apiVersion flows.netobserv.io/v1beta2) enabling eBPF agent features DNSTracking/FlowRTT/PacketTranslation/TLSTracking, sampling, retention 24h, and consumerReplicas for the pipeline.
- [docs/en/networking/observability/overview.mdx](docs/en/networking/observability/overview.mdx): Architectural overview of Network Observability (NetObserv) on ACP, explaining its eBPF-based agent that runs as a DaemonSet on nodes, the Flowlogs Pipeline Deployment that enriches data with Kubernetes API metadata and writes to ClickHouse, and the CLI for on-demand captures; includes a recommended workflow (prerequisites > package upload > ClickHouse prep > Operator install > Secret > FlowCollector > CLI for troubleshooting) and mermaid diagrams of both the operator and CLI architectures.
- [docs/en/networking/observability/prerequisites.mdx](docs/en/networking/observability/prerequisites.mdx): Prerequisites for deploying Network Observability: administrator access, the NetObserv Operator package fixed to the `netobserv-operator` namespace, a reachable ClickHouse server with credentials suitable for a Kubernetes secret, kernel >= 5.14, and Ubuntu-specific requirement that `kernel.perf_event_paranoid` be 3 or lower (set via sysctl or /etc/sysctl.conf) so eBPF's perf_event_open() works; closes with how to download and `violet`-upload the operator package.
- [docs/en/networking/operators/alb_operator/alb_monitoring.mdx](docs/en/networking/operators/alb_operator/alb_monitoring.mdx): Walkthrough for finding and reading the built-in ALB Status monitoring dashboard under Administrator > Operation Center > Monitoring > Monitoring Dashboard > container-platform; documents the per-ALB metrics surfaced for the last 5 minutes including traffic (Active Connections, RPS, Error Rate, Latency), pod resource usage (CPU/Memory/Network/Disk I/O), and per-Ingress/HTTPRoute/Rule statistics (QPS, Request/Response BPS, Error Rate, P50/P90/P99 and Upstream P50/P90/P99 latencies).
- [docs/en/networking/operators/alb_operator/alb_with_ingress_nginx_annotation_compatibility.mdx](docs/en/networking/operators/alb_operator/alb_with_ingress_nginx_annotation_compatibility.mdx): Compatibility matrix listing all `nginx.ingress.kubernetes.io/*` annotations (auth, CORS, rewrite-target, redirects, modsecurity, opentelemetry, proxy-*-timeout, ssl-redirect, upstream-vhost, etc.) and which of them ALB supports, partially supports through equivalent CR fields, or does not support; warns that ALB has been deprecated and points users at the ingress-nginx-operator instead.
- [docs/en/networking/operators/alb_operator/auth.mdx](docs/en/networking/operators/alb_operator/auth.mdx): Reference for ALB's authentication features, contrasting Forward Auth (external OAuth/SSO) and Basic Auth flows with mermaid diagrams, showing how to deploy an ALB2 CR, create a `Secret` with `auth: <htpasswd-apr1>` (Apache htpasswd `apr1` only - no digest/bcrypt/sha256), and reference it from an Ingress via `nginx.ingress.kubernetes.io/auth-type=basic`, `auth-secret`, `auth-secret-type` annotations; lists supported and unsupported ingress-nginx auth annotations, the ALB-specific `alb.ingress.cpaas.io/auth-enable=false` toggle, full `auth.basic` / `auth.forward` schema for ALB/Frontend/Rule CRs with inheritance order Alb > Frontend > Rule, and the priority order for resolving annotation conflicts (`index.$rule_index-$path_index.alb.ingress.cpaas.io` > `alb.ingress.cpaas.io` > `nginx.ingress.kubernetes.io`).
- [docs/en/networking/operators/alb_operator/bind_nic_in_alb.mdx](docs/en/networking/operators/alb_operator/bind_nic_in_alb.mdx): Shows how to bind ALB's listening sockets to a specific network interface card; for embedded ALBs (global-alb2 / cpaas-system) set the `cpaas.io/alb-bind-nic` annotation on the cluster resource to a JSON `{"nic":["$NIC","alive"]}` (with `alive` added when using Alauda Virtual IP Management), and optionally disable IPv6 with `cpaas.io/alb-enable-ipv6="false"`; for user-defined ALBs apply equivalent settings via `kubectl patch alb2` to `.spec.config.bindNIC` and `enableIPV6`.
- [docs/en/networking/operators/alb_operator/cors.mdx](docs/en/networking/operators/alb_operator/cors.mdx): Brief reference for ALB's CORS support, configured on `Rule.spec` with `enableCORS` (boolean), `corsAllowOrigin` (comma-separated origins), and `corsAllowHeaders` (comma-separated headers); when disabled the backend remains responsible for CORS handling.
- [docs/en/networking/operators/alb_operator/decision_making_for_performance_selection_of_alb.mdx](docs/en/networking/operators/alb_operator/decision_making_for_performance_selection_of_alb.mdx): Capacity-planning guide that pairs Small (<=5 nodes, ~300 QPS, single LB with 2 HA replicas, port isolation), Medium (<=30 nodes, ~10000 QPS, single LB with 3 HA replicas, port or instance allocation), and Large (>30 nodes, ~20000 QPS, multiple LBs with 3 HA replicas each) production tiers with recommended deployments, plus advice for function testing/testing env/core apps/large-scale data transfers and pros-cons of three usage modes: single-project instance allocation (recommended), multi-project instance sharing, and dynamic port-based allocation.
- [docs/en/networking/operators/alb_operator/deploy_high_available_vip_for_alb.mdx](docs/en/networking/operators/alb_operator/deploy_high_available_vip_for_alb.mdx): Two methods for giving an ALB an HA VIP: Method 1 - in `container` network mode the system auto-creates a LoadBalancer Service whose IP is allocated by MetalLB (with optional `metallb.universe.tf/loadBalancerIPs` and `address-pool` annotations under `alb.spec.config.vip.lbSvcAnnotations`); Method 2 - external commercial LB device with documented per-port health checks (TCP, 2s response timeout, 5s interval, 3 unhealthy threshold) targeting port 11782 for global clusters and 1936 for business clusters.
- [docs/en/networking/operators/alb_operator/header_modification.mdx](docs/en/networking/operators/alb_operator/header_modification.mdx): Reference for rewriting request and response headers in ALB via `alb.ingress.cpaas.io/rewrite-request|rewrite-response` (or `alb.rule.cpaas.io/*` on Rule CRs) whose JSON value is a `RewriteRequestConfig`/`RewriteResponseConfig` struct supporting `headers` (set), `headers_var` (set from Nginx variable), `headers_remove`, `headers_add` (multi-value), and `headers_add_var`; lists ALB-specific extra variables `first_forward_or_remote_addr` and `first_forward`, and gives examples for setting Authorization from a cookie and Strict-Transport-Security HSTS.
- [docs/en/networking/operators/alb_operator/http_redirect.mdx](docs/en/networking/operators/alb_operator/http_redirect.mdx): Reference for HTTP redirect on ALB Frontend or Rule (`.spec.config.redirect` with fields `code`, `host`, `port`, `prefix_match`, `replace_prefix`, `scheme`, `url`), the mapping to ingress-nginx annotations `permanent-redirect`(-code), `temporal-redirect`(-code), `ssl-redirect`, and `force-ssl-redirect`, and a description of the differences between port-level (all requests on the port) and rule-level (matched requests only) redirects.
- [docs/en/networking/operators/alb_operator/l4_l7_timeout.mdx](docs/en/networking/operators/alb_operator/l4_l7_timeout.mdx): Reference for ALB's L4/L7 proxy timeouts (implemented via Lua so Nginx does not reload on change), configurable on Frontend or Rule `.spec.config.timeout` with fields `proxy_connect_timeout_ms` (upstream connect), `proxy_read_timeout_ms` (idle gap between read operations), and `proxy_send_timeout_ms` (idle gap between write operations); maps to the `nginx.ingress.kubernetes.io/proxy-connect-timeout|read-timeout|send-timeout` annotations and notes that port-level timeouts are used as L4 timeouts.
- [docs/en/networking/operators/alb_operator/load_balancing_session_affinity_policy_in_alb.mdx](docs/en/networking/operators/alb_operator/load_balancing_session_affinity_policy_in_alb.mdx): Reference for ALB's load balancing algorithms: Round Robin (`rr`, default), Source IP Hash (`sip-hash`, falls back to client IP when no X-Forwarded-For), Cookie-based affinity (`cookie` with `cookie-name` defaulting to `JSESSIONID`, ALB sets `timestamp.worker_pid.random_number` if missing), Header-based affinity (`header` with `header-name`), and EWMA (`ewma`, Power-of-Two-Choices using Twitter Finagle peak-EWMA), configurable via the `alb.ingress.cpaas.io/session-affinity-policy|attribute` annotations or `serviceGroup.session_affinity_policy|attribute` on the Frontend/Rule CR.
- [docs/en/networking/operators/alb_operator/modsecurity.mdx](docs/en/networking/operators/alb_operator/modsecurity.mdx): Reference for enabling the ModSecurity WAF on ALB through ingress-nginx-compatible annotations (`nginx.ingress.kubernetes.io/enable-modsecurity|enable-owasp-core-rules|modsecurity-transaction-id|modsecurity-snippet`) or ALB-specific `alb.modsecurity.cpaas.io/use-recommend` and `alb.modsecurity.cpaas.io/cmref=$ns/$name#$section` (load custom rules from a ConfigMap); also documents `.spec.config.modsecurity` (enable, transactionId, useCoreRules toggling /etc/nginx/owasp-modsecurity-crs/nginx-modsecurity.conf, useRecommend toggling /etc/nginx/modsecurity/modsecurity.conf, cmRef) with Rule > FT > ALB inheritance, plus a worked example that blocks query parameter `test=*test*` via a `SecRule ARGS:test "@contains test" "id:1234,deny,log"` snippet.
- [docs/en/networking/operators/alb_operator/otel.mdx](docs/en/networking/operators/alb_operator/otel.mdx): Comprehensive guide to enabling OpenTelemetry tracing on ALB: edit `spec.config.otel` on the ALB2 CR with `enable=true` and `exporter.collector.address` pointing at a Jaeger/OTel collector (e.g. http://jaeger.default.svc.cluster.local:4318), or set per-Ingress overrides via `nginx.ingress.kubernetes.io/enable-opentelemetry`, `opentelemetry-trust-incoming-span`, and the JSON `alb.ingress.cpaas.io/otel` annotation; documents Resource Attributes (hostname, service.name/namespace/type/instance.id), default Span Attributes (http.status_code, alb.rule.rule_name/source_name/source_ns/source_type, http.request.resend_count), the optional alb.upstream.* attributes gated by `flags.hide_upstream_attrs`, request/response header reporting flags, the sampling strategies always_on / always_off / traceid-ratio / parent-base, and inheritance ALB > FT > Rule; ends with an end-to-end HotROD (hotrod-with-proxy) demo against Jaeger.
- [docs/en/networking/operators/alb_operator/tcp_http_keepalive.mdx](docs/en/networking/operators/alb_operator/tcp_http_keepalive.mdx): Reference for ALB's downstream keepalive between client and ALB (not ALB and backend), configured only on the Frontend `.spec.config.keepalive`: HTTP keepalive (header_timeout, requests default 1000, timeout default 75s) and TCP keepalive (SO_KEEPALIVE via TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL); changes here trigger an automatic Nginx reload.
- [docs/en/networking/operators/alb_operator/understanding_alb.mdx](docs/en/networking/operators/alb_operator/understanding_alb.mdx): Conceptual introduction to ALB (Another Load Balancer), a deprecated OpenResty-based Kubernetes Gateway from Alauda (deprecation notice points at ingress-nginx-operator or envoy-gateway); explains the ALB Operator that watches ALB CRs and the ALB Instance pair (OpenResty data plane + Go control-plane that compiles Ingress/Gateway/Rule CRs into ALB DSL), the Helm install of `alb/alauda-alb2`, deploying an ALB2 CR with `networkMode: host`, the relationships between ALB, Frontend (FT auto-created for ports 80/443 based on Ingress TLS), Rule (one per Ingress path), Ingress, and Project (namespace scoping), and how the ALB Leader handles Ingress->Rule and FT creation.
- [docs/en/networking/operators/alb_operator/url_rewrite.mdx](docs/en/networking/operators/alb_operator/url_rewrite.mdx): Describes how ALB rewrites request URLs before forwarding to backends using regex capture groups, with examples for both the standard Ingress `nginx.ingress.kubernetes.io/rewrite-target` annotation and the platform's `Rule` CRD (`crd.alauda.io/v1`) using `dslx` matchers and `rewrite_base`/`rewrite_target` fields.
- [docs/en/networking/operators/envoy_gateway_operator.mdx](docs/en/networking/operators/envoy_gateway_operator.mdx): Architectural and operational guide for the `envoy-gateway-operator`, which packages the upstream Envoy Gateway 1.7.0 Helm chart as the `EnvoyGatewayCtl` CRD (`envoy-gateway.alauda.io/v1`) and provisions `envoy-gateway` and `envoy-proxy` instances together with auto-generated `GatewayClass` resources. Covers related Gateway API resources (`Gateway`, `HTTPRoute`/`TCPRoute`/`UDPRoute`/`GRPCRoute`/`TLSRoute`, `EnvoyProxy`, `SecurityPolicy`, `BackendTLSPolicy`, `ClientTrafficPolicy`, `BackendTrafficPolicy`), installation from OperatorHub, the `cpaas-default` recommended configuration, and how to enable extension APIs such as backend routing.
- [docs/en/networking/operators/ingress_nginx_operator.mdx](docs/en/networking/operators/ingress_nginx_operator.mdx): Operator that manages Ingress-NGINX deployments via the `IngressNginx` CRD (`ingress-nginx.alauda.io/v1`), including replica count, resource limits, service type, ingress sharding via `namespaceSelector`, LoadBalancer exposure with MetalLB VIP annotations, SSL passthrough, and IPv4/IPv6 dual-stack support. Lists platform defaults that differ from the upstream Helm chart, such as per-instance auto-created `IngressClass` named `$ns-$name` and `ClusterIP` service type.
- [docs/en/networking/operators/metallb_operator.mdx](docs/en/networking/operators/metallb_operator.mdx): Reference for the MetalLB Operator that provides bare-metal LoadBalancer support via L2 (ARP/NDP) or L3 (BGP) IP advertisement. Explains the Controller/Speaker/ARP Responder architecture, the stateless leader-election algorithm (hash of node+VIP), VIP capacity planning formula `ceil(n-vip / n-node)`, and CRDs `IPAddressPool`, `L2Advertisement`, `BGPPeer`, `BGPAdvertisement`, and optional `BFDProfile` under the `metallb.io/v1beta1` API group, along with installation/upgrade via the Cluster Plugin marketplace.
- [docs/en/networking/overview.mdx](docs/en/networking/overview.mdx): Conceptual overview of Alauda Container Platform networking, covering service discovery, load balancing, traffic management, network security and observability. Compares L4/L7 options (LoadBalancer Service via MetalLB vs Gateway API TCP/UDP routes; Ingress vs Gateway API) recommending Gateway API and Envoy Gateway for L7 and MetalLB for L4, introduces Gateway API personas and resources, and traces the request flow from external client through DNS, external LB, Envoy/Ingress NGINX, ClusterIP Service, to Pod.
- [docs/en/networking/security/admin_network_policy.mdx](docs/en/networking/security/admin_network_policy.mdx): Guide for creating cluster-scoped `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` resources (`policy.networking.k8s.io/v1alpha1`) when using Kube-OVN CNI, with the `cluster-network-policy` and `cluster-network-policy-next` feature gates. Covers `subject` selectors, `priority` (lower = higher), action values `Allow`/`Deny`/`Pass`, ingress/egress rules with pod/namespace/node selectors and CIDR networks, and the alternative web-console flow including Target Pod preview.
- [docs/en/networking/security/network_policy.mdx](docs/en/networking/security/network_policy.mdx): Walkthrough for namespace-scoped Kubernetes `NetworkPolicy` (`networking.k8s.io/v1`), explaining default allow-all behavior, `podSelector` targeting, ingress/egress rules using `podSelector`/`namespaceSelector`/`ipBlock` peers, `policyTypes`, and the web console flow with options like 'Block all ingress traffic' and 'Pods in Current Cluster'. Notes that policies do not affect Pods running in `hostNetwork` mode.
- [docs/en/networking/security/understanding_network_policy.mdx](docs/en/networking/security/understanding_network_policy.mdx): Conceptual comparison of network-policy APIs at v1alpha1 (`AdminNetworkPolicy`/`BaselineAdminNetworkPolicy`) versus standard namespace-scoped `NetworkPolicy`, focused on Kube-OVN's evaluation order (ANP > NetworkPolicy > BANP). Includes a dimension-by-dimension table covering scope, ownership audience, control target, priority, cross-namespace rules and risk surface.

## observability

- [docs/en/observability/event/event.mdx](docs/en/observability/event/event.mdx): Procedure for navigating to Operations Center > Events to view significant Kubernetes events from the last 30 minutes, filter resource event records by resource type, namespace, event reason, level (Normal/Warning) and resource name, and inspect details through the Event Details dialog.
- [docs/en/observability/event/intro.mdx](docs/en/observability/event/intro.mdx): Introduction to the platform's event capability that ingests Kubernetes events, stores them via the logging service, and lets users analyze them or chain them into alert policies via `manage_alert`. Requires the ACP Log Essentials, Log Collector, and Log Storage plugins to be installed.
- [docs/en/observability/inspection/architecture.mdx](docs/en/observability/inspection/architecture.mdx): Explains the inspection module's architecture in which the Courier component on the `global` cluster watches inspection-type CRs, queries each cluster's Prometheus or VictoriaMetrics, and writes results back. Also covers the component health flow using the `ModuleHealth` and `ModuleHealthRecord` CRDs to declare monitoring targets and record per-cluster results, combined with Kubernetes replica checks.
- [docs/en/observability/inspection/functions/health.mdx](docs/en/observability/inspection/functions/health.mdx): User guide for the Platform Health Status page that aggregates the health of installed platform features. Describes how to open it via the question-mark button in the navigation bar, interpret 'fault' state on feature cards, and drill into detailed component issue information for clusters with or without the feature installed.
- [docs/en/observability/inspection/functions/inspection.mdx](docs/en/observability/inspection/functions/inspection.mdx): Operational guide to Basic Inspection under Operation Center > Inspection, covering on-demand inspection runs, PDF/Excel report download, scheduled inspection via cron expressions, retention, and email notifications. Documents detailed Fault/Warning judgment thresholds for clusters, nodes, pods (status, CPU > 80%, restart count, etc.) and certificates (expired, validity < 29 days), plus the Resource Utilization Inspection view.
- [docs/en/observability/inspection/intro.mdx](docs/en/observability/inspection/intro.mdx): Positioning of the Inspection module within the ACP observability suite, summarizing four capabilities: resource inspection of clusters/nodes/pods/certificates, real-time progress monitoring, visual reporting, and PDF/Excel report generation. Notes the dependency on either the ACP Monitoring with Prometheus or VictoriaMetrics plugin and email notification configuration.
- [docs/en/observability/log/intro.mdx](docs/en/observability/log/intro.mdx): Introduction to the ACP Logging service that uses Filebeat for collection together with ElasticSearch and ClickHouse storage backends to ingest, persist and query application, container and infrastructure logs. Links to the external logs site for the full feature reference.
- [docs/en/observability/monitor/architecture/architecture.mdx](docs/en/observability/monitor/architecture/architecture.mdx): Architecture of the platform's monitoring stack covering Prometheus/VictoriaMetrics Operator validation, data sources (Nevermore for log metrics, Warlock for event metrics, ServiceMonitor-discovered exporters), and the query path through ALB and Courier API. Documents the alert path (PrometheusRule -> Alertmanager -> Courier -> ElasticSearch/ClickHouse), real-time alert metrics `cpaas_active_alerts`/`cpaas_active_silences`, and notification CRDs `NotificationTemplate`/`NotificationGroup`/`Notification` under `ait.alauda.io/v1beta1`.
- [docs/en/observability/monitor/architecture/capacity_planning.mdx](docs/en/observability/monitor/architecture/capacity_planning.mdx): Sizing baseline for Prometheus and VictoriaMetrics monitoring components at Small (10 nodes/500 pods, ~2800 samples/s), Medium (50 nodes/2000 pods, ~7300 samples/s) and Large (500 nodes/10000 pods, ~41575 samples/s) scales. Provides CPU/memory limits, replica counts and 7-day disk usage for `courier-api`, `kube-prometheus-thanos-query`, `prometheus-kube-prometheus-0`, `vmselect`, `vmstorage-cluster` and `vmselect-cluster`.
- [docs/en/observability/monitor/architecture/component_selection_suggestion.mdx](docs/en/observability/monitor/architecture/component_selection_suggestion.mdx): Selection guide between the Prometheus and VictoriaMetrics monitoring components, covering their respective sub-components (Prometheus Server/Exporters/AlertManager/PushGateway versus VMStorage/VMInsert/VMSelect/VMAlert/VMAgent), architectural differences, and feature comparison (HA, single-node, long-term storage, resource efficiency). Recommends VictoriaMetrics (Beta since 3.18) for high-availability and multi-cluster scenarios, single-cluster vs multi-cluster install modes with VMAgent, and Prometheus for small single-cluster setups.
- [docs/en/observability/monitor/concept.mdx](docs/en/observability/monitor/concept.mdx): Glossary of monitoring concepts used by the platform: metrics (name/value/timestamp/labels), PromQL, built-in indicators, Exporter, `ServiceMonitor`; alarm rules (expression, threshold, duration, level P0-P2), alarm policies and notification policies/templates; and monitoring dashboards composed of panels, data sources, and variables.
- [docs/en/observability/monitor/functions/manage_alert.mdx](docs/en/observability/monitor/functions/manage_alert.mdx): Comprehensive alert management guide: creating Resource Alerts and Event Alerts via the UI with parameters like PromQL expression, metric unit, legend format, trigger condition, alert level (Critical/Serious/Warning/Info); CLI workflow using `PrometheusRule` (`monitoring.coreos.com/v1`) with `alert.cpaas.io/*` annotations and `severity` labels; alert templates by Cluster/Node/Computing Component; setting silence via UI or `alert.cpaas.io/silence.config` annotation; recommendations on rule design (focus on symptoms, fewest rules).
- [docs/en/observability/monitor/functions/manage_blackbox.mdx](docs/en/observability/monitor/functions/manage_blackbox.mdx): Blackbox monitoring backed by Blackbox Exporter, supporting ICMP, TCP and HTTP probes configured under Operations Center > Monitoring > Blackbox Monitoring. Covers creating probes via the UI and via the `Probe` CRD (`monitoring.coreos.com/v1`), configuring blackbox alerts on `Connectivity` and `HTTP Status Code` metrics, customizing the `cpaas-monitor-prometheus-blackbox-exporter` ConfigMap with modules like `http_post_2xx`, `tls_connect`, `dns_udp_example`, `icmp_example`, and reloading via Pod restart or POST to `:9115/-/reload`.
- [docs/en/observability/monitor/functions/manage_dashboard.mdx](docs/en/observability/monitor/functions/manage_dashboard.mdx): Comprehensive guide for the platform's Grafana-replacement Monitoring Dashboards, including dashboard/folder/label/main-dashboard management, Grafana v8+ JSON import, variable types (Query/Constant/Custom/Textbox) with regex filtering, panel types (trend/step line/bar/horizontal bar/gauge/bar gauge/pie/table/stat/scatter/text card), grouping with repeat-by-variable, and CLI creation via the `MonitorDashboard` CRD (`ait.alauda.io/v1alpha2`). Documents common functions like `label_values()` and `query_result()` plus the built-in `workload.*.utilization` metrics that don't support multi-select.
- [docs/en/observability/monitor/functions/manage_metrics.mdx](docs/en/observability/monitor/functions/manage_metrics.mdx): Working with metrics in the platform: viewing component-exposed metrics via `curl :<port>/metrics`, listing all stored metrics via the `/v2/metrics/<cluster>/prometheus/label/__name__/values` API, listing platform-defined built-in indicators via `/v2/metrics/<cluster>/indicators` with `alertEnabled`/`SupportDashboard`/`multipleEnabled` flags, and integrating external exporters (e.g., Elasticsearch) by creating a Service and a `ServiceMonitor` (`monitoring.coreos.com/v1`) that the operator reconciles based on the Prometheus CR's `serviceMonitorSelector`/`serviceMonitorNamespaceSelector`.
- [docs/en/observability/monitor/functions/manage_notifcation.mdx](docs/en/observability/monitor/functions/manage_notifcation.mdx): Configuration reference for notification servers (WeChat Work / DingTalk / Feishu corporate apps via `Secret` with `cpaas.io/notification.server.type` labels, SMTP email server, and Webhook server group bots), notification contact groups, notification templates with `{{.externalLabels.severity}}`/`{{.labels.alert_cluster}}` variables and email HTML tags, and notification rules. Covers per-project notification setup and custom Webhook headers via a `NotificationSender` Secret referenced through the `cpaas.io/notification.webhook.config` annotation on a `NotificationGroup`.
- [docs/en/observability/monitor/how_to/infra_nodes.mdx](docs/en/observability/monitor/how_to/infra_nodes.mdx): Procedure for placing ACP Monitoring with Prometheus or ACP Monitoring with VictoriaMetrics workloads on infra nodes via plugin-level Advanced Configuration (Node Selectors/Tolerations) or YAML `spec.config.components.nodeSelector` and `tolerations` rather than patching generated workloads. Includes troubleshooting for unsatisfied scheduling/`LocalVolume` storage constraints.
- [docs/en/observability/monitor/how_to/restore_prometheus.mdx](docs/en/observability/monitor/how_to/restore_prometheus.mdx): Step-by-step backup and restore of Prometheus TSDB data stored at `--storage.tsdb.path=/prometheus`. Documents the recommended `kubectl cp` method on `prometheus-kube-prometheus-0-0`, alternate snapshots via `enableAdminAPI: true` and POST to `/api/v1/admin/tsdb/snapshot`, copy-back restore steps for `LocalVolume`/`StorageClass`/`PV` storage, and the resulting TSDB block layout with WAL segments and `meta.json`.
- [docs/en/observability/monitor/how_to/restore_victoriametrics.mdx](docs/en/observability/monitor/how_to/restore_victoriametrics.mdx): Backup and recovery procedure for VictoriaMetrics monitoring data stored in the `vmstorage-cluster` StatefulSet at `-storageDataPath=/vm-data`. Points to the `vmbackup` and `vmrestore` tools for the actual operations and includes use cases such as scheduled backup, system migration and DR.
- [docs/en/observability/monitor/how_to/special_network_card_name.mdx](docs/en/observability/monitor/how_to/special_network_card_name.mdx): How to collect network metrics from custom-named NICs that do not match the default `eth.|en.|wl.*|ww.*` patterns by editing the workload cluster's `moduleinfo` resource (`prometheus` or `victoriametrics`) and extending `spec.valuesOverride.ait/chart-cpaas-monitor.global.indicator.networkDevice` with an additional regex.
- [docs/en/observability/monitor/install_monitor.mdx](docs/en/observability/monitor/install_monitor.mdx): Installation guide for the ACP Monitoring with Prometheus and ACP Monitoring with VictoriaMetrics cluster plugins (both at v4.1.0) using either the App Store Management console or the `ModuleInfo` resource (`cluster.alauda.io/v1alpha1`). Covers Scale Configuration (Small/Medium/Large), storage types (`LocalVolume`/`StorageClass`/`PV`), Advanced Configuration for Node Selectors/Tolerations targeting infra nodes, agent-only VMAgent installs that depend on a VictoriaMetrics Center cluster via `crossClusterDependency`, post-install component URLs for Thanos/Prometheus/Alertmanager/VictoriaMetrics UI, and full YAML field reference including `retention`, `scrapeInterval` and per-component `resources`.
- [docs/en/observability/monitor/intro.mdx](docs/en/observability/monitor/intro.mdx): Positioning of the Monitoring module within the ACP observability suite, summarizing four capabilities (metrics collection, dashboards, alerting, notifications) and noting that the implementation builds on Prometheus and VictoriaMetrics for cluster, node, application and container monitoring.
- [docs/en/observability/overview.mdx](docs/en/observability/overview.mdx): Positioning of the Observability module within the ACP platform, summarizing four pillars: synthetic probe monitoring, centralized logging, real-time metrics/alerting, and distributed tracing for cloud-native applications.
- [docs/en/observability/tracing/architecture.mdx](docs/en/observability/tracing/architecture.mdx): Architecture of distributed tracing built on OpenTelemetry and Jaeger: `opentelemetry-operator` manages the `otel-collector` and OTel auto-injection; `jaeger-operator` deploys `jaeger-collector` and `jaeger-query`; spans flow `Application -> otel-collector -> jaeger-collector -> Elasticsearch` and the platform Tracing UI integrates the `jaeger-query` API for visualization.
- [docs/en/observability/tracing/concept.mdx](docs/en/observability/tracing/concept.mdx): Glossary of distributed-tracing concepts including telemetry signals (traces/metrics/logs), OpenTelemetry as a vendor-agnostic framework, the Span/Trace/root-span hierarchy, code-based and zero-instrumentation instrumentation approaches, the OpenTelemetry Collector receiver/processor/exporter model, and Jaeger as the OpenTracing-compatible backend.
- [docs/en/observability/tracing/functions/query_trace_logs.mdx](docs/en/observability/tracing/functions/query_trace_logs.mdx): Procedure for querying logs associated with a specific TraceID after instrumenting business logs (per the `log_with_traceid` guide), accessed via the **View Log** tab on a trace detail page. Supports filtering by Pod name, time range, query keywords, the **Contain Trace ID** checkbox, JSON/CSV log export, customizable display fields, and context view (5 logs before/after).
- [docs/en/observability/tracing/functions/query_tracing.mdx](docs/en/observability/tracing/functions/query_tracing.mdx): Tracing query workflow under Observability > Tracing, supporting multi-dimensional filters (TraceID, Service, Tag/Label, Span duration threshold, Error spans only, Root Span vs Service Entry Span, Maximum Query Count up to 1000). Documents the Span List + time-series waterfall chart layout, indentation-based call hierarchy, and Span detail panel exposing service, duration, `http.url`, tag key-values and raw JSON.
- [docs/en/observability/tracing/how_to/java_auto_tracing.mdx](docs/en/observability/tracing/how_to/java_auto_tracing.mdx): Non-intrusive tracing integration for Java 8+ Deployments by adding the `instrumentation.opentelemetry.io/inject-java: cpaas-system/acp-common-java` Pod annotation and setting `SERVICE_NAME`/`SERVICE_NAMESPACE` env vars via `fieldRef`. Successful injection adds the `opentelemetry-auto-instrumentation-java` init container and lets the Tracing page display the application's spans.
- [docs/en/observability/tracing/how_to/log_with_traceid.mdx](docs/en/observability/tracing/how_to/log_with_traceid.mdx): Developer guide for propagating TraceID into application logs so it can be queried on the platform: for Spring Boot with Log4j/Logback configure `logging.pattern.level=trace_id=%mdc{trace_id}` or extend `CONSOLE_LOG_PATTERN` with `[trace_id=%X{trace_id}]`; for Python copy the B3 headers (`x-b3-traceid`, `x-b3-spanid`, etc.) into log statements. Verifies by ticking 'Contain Trace ID' on the Log Query page.
- [docs/en/observability/tracing/installation.mdx](docs/en/observability/tracing/installation.mdx): Cluster-administrator installation guide for the Tracing system: installs the **Alauda build of Jaeger** and **Alauda build of OpenTelemetry** Operators from OperatorHub, then deploys instances using `install-jaeger.sh` (creates a `Jaeger` CR backed by Elasticsearch with oauth2-proxy SSO and an Ingress at `/clusters/<cluster>/acp/jaeger`) and `install-otel.sh` (creates `OpenTelemetryCollector`, `Instrumentation acp-common-java`, and `ServiceMonitor` resources). Notes mutual exclusion with Service Mesh, requires the `acp-tracing-ui` feature switch, and includes uninstall steps.
- [docs/en/observability/tracing/intro.mdx](docs/en/observability/tracing/intro.mdx): Positioning of the Distributed Tracing module within the ACP observability suite, summarizing collection (OpenTelemetry auto-injection or SDK), storage on Elasticsearch, multi-dimensional querying (TraceID, service, tags), and visualization with service dependency mapping. Notes sampling-rate considerations to balance Elasticsearch load.
- [docs/en/observability/tracing/trouble_shooting/incomplete_trace.mdx](docs/en/observability/tracing/trouble_shooting/incomplete_trace.mdx): Troubleshooting incomplete tracing data: explains Elasticsearch's memory-buffer -> translog -> segment-file persistence delay for recent spans, and `jaeger-query`'s default 1-hour-pre/post window that drops disconnected spans for long traces. Recommends waiting/refreshing for delay and tuning `--es.asm.span-trace-query-time-adjustment-hours` for long traces.
- [docs/en/observability/tracing/trouble_shooting/missing_trace.mdx](docs/en/observability/tracing/trouble_shooting/missing_trace.mdx): Troubleshooting missing trace results, attributing them to either a too-low sampling rate (recommends raising it or using tail-based sampling) or Elasticsearch's default `refresh_interval` of 10s for newly-written indices (tunable via the `--es.asm.index-refresh-interval` startup parameter of `jaeger-collector`).

## overview

- [docs/en/overview/introduction.mdx](docs/en/overview/introduction.mdx): Introduces Alauda Container Platform as a Kubernetes-based platform for cloud-native application delivery, cluster operations, project governance, Extensions, observability, security, upgrade planning, and recovery. It explains the relationship to Kubernetes, separates Core and Extension capabilities, and provides a first-reader path through Architecture, Platform Model, Cluster Management Models, Core and Extensions, and Learn More.
- [docs/en/overview/architecture.mdx](docs/en/overview/architecture.mdx): Explains the hub-and-spoke architecture built around the `global` management cluster, workload clusters, third-party clusters, and Hosted Control Plane boundaries. It summarizes access paths, management paths, state and data domains, Core and Extension boundaries, and availability/recovery entry points while keeping the existing architecture diagram.
- [docs/en/overview/platform-model.mdx](docs/en/overview/platform-model.mdx): Describes the ACP platform model, including the `global` cluster, workload clusters, third-party clusters, Hosted Control Plane, projects, and namespaces. It clarifies where platform management, governance, observability, Extension management, and recovery responsibilities usually occur.
- [docs/en/overview/cluster-management-models.mdx](docs/en/overview/cluster-management-models.mdx): Defines the canonical platform-level cluster model through three separate axes: infrastructure responsibility with Installer-Provisioned Infrastructure (IPI) and User-Provisioned Infrastructure (UPI), control-plane topology with dedicated control planes and Hosted Control Plane (HCP, implemented in ACP through Kamaji `TenantControlPlane`), and Kubernetes ownership/onboarding with ACP lifecycle-managed workload clusters and third-party clusters. It summarizes third-party cluster capability boundaries, import/register onboarding methods, version gates, and provider or workflow caveat categories.
- [docs/en/overview/core-and-extensions.mdx](docs/en/overview/core-and-extensions.mdx): Explains ACP Core, Operators, Cluster Plugins, Extension lifecycle types, Customer Portal compatibility metadata, the default Extend baseline, and capability boundaries for registry, observability, audit, security, compliance, and independent products or subsites.
- [docs/en/overview/availability-and-recovery.mdx](docs/en/overview/availability-and-recovery.mdx): Summarizes topology, high availability baseline, component-level high availability mechanisms (etcd, ingress, registry and object storage, monitoring and logging, container network, self-healing), Global Cluster Disaster Recovery, and backup/restore paths. It distinguishes Multi-Cluster, Single Cluster, and Single Node scenarios, clarifies Global DR as `global` control-plane DR only, and routes readers to sizing, DR, backup, registry, monitoring, logging, and application recovery docs.
- [docs/en/overview/version-and-lifecycle.mdx](docs/en/overview/version-and-lifecycle.mdx): Explains ACP and Kubernetes version relationships, third-party Kubernetes accepted onboarding range, runtime/OS/CPU architecture responsibility boundaries, Extension lifecycle types, feature maturity labels, and upgrade reading paths.
- [docs/en/overview/kubernetes-support-matrix.mdx](docs/en/overview/kubernetes-support-matrix.mdx): Provides the Kubernetes version support matrix for ACP releases, including versions supported for platform-managed cluster creation, workload-cluster compatible versions before `global` upgrades, the ACP 4.3 third-party Kubernetes accepted onboarding range `>=1.19.0 <1.35.0`, default Extend baseline scope, and upgrade requirements.
- [docs/en/overview/release_notes.mdx](docs/en/overview/release_notes.mdx): Summarizes ACP 4.3.0 release baseline, Kubernetes 1.34 support, CVO-based upgrades, standalone Cluster Plugin upgrades, MicroOS and Immutable Infrastructure updates, next-generation console preview entry, containerd 2.0 baseline, and third-party cluster onboarding range. Fixed issues and known issues use neutral empty-state wording when no issues are currently published.
- [docs/en/overview/glossary.mdx](docs/en/overview/glossary.mdx): Defines platform-wide terms such as ACP Core, `global` cluster, workload cluster, third-party cluster, Managed Cluster as a UI label, Installer-Provisioned Infrastructure (IPI), User-Provisioned Infrastructure (UPI), Hosted Control Plane (HCP, Kamaji-based in ACP), Extensions, lifecycle types, identity and security terms, access terms, and disaster recovery or upgrade terms.
- [docs/en/overview/learn-more.mdx](docs/en/overview/learn-more.mdx): Provides a task-oriented route map for understanding the platform, installing and planning, managing clusters, building and operating applications, installing Extensions, planning versions and upgrades, planning availability and recovery, and finding security, API, and CLI documentation.

## security

- [docs/en/security/alauda_cluster_authentication.mdx](docs/en/security/alauda_cluster_authentication.mdx): Brief landing page for the Alauda Container Platform Cluster Authentication plugin (`local-auth`), which provides standalone authentication so users can still log in to and operate Kubernetes clusters when the `global` cluster is unavailable, preserving prior permissions.
- [docs/en/security/alauda_container_security.mdx](docs/en/security/alauda_container_security.mdx): Landing page for Alauda Container Security (linked via `alauda-container-security` external site), a Kubernetes/container security solution with a Central Services + Secured Cluster Services architecture for vulnerability scanning (built-in Scanner V4), policy enforcement, compliance checks, and SIEM/CI/CD integration.
- [docs/en/security/audit/intro.mdx](docs/en/security/audit/intro.mdx): Procedure for using the platform Auditing feature to view time-ordered records of user and `system:*` operations on Kubernetes resources. Supports filtering by Operator, Action (create/update/delete/manage/rollback/stop), Cluster, Resource Type/Name, exporting results to CSV, and inspecting full JSON via the Details dialog. Requires the ACP Log Essentials, Log Collector and Log Storage plugins plus platform-audit permissions.
- [docs/en/security/cert/cert-manager.mdx](docs/en/security/cert/cert-manager.mdx): Conceptual reference for cert-manager in ACP clusters describing its CRDs (`Certificate`, `Issuer`/`ClusterIssuer`, `CertificateRequest`), automatic generation/renewal of `kubernetes.io/tls` Secrets, and the `controller.cert-manager.io/fao` label plus `cert-manager.io/*` annotations that mark Secrets it manages (certificate-name, common-name, alt-names, ip-sans, issuer-kind/name/group, uri-sans).
- [docs/en/security/cert/certificate-monitoring.mdx](docs/en/security/cert/certificate-monitoring.mdx): Cluster Enhancer plugin certificate monitoring that exposes `certificate_expires_status` and `certificate_expires_time` metrics for Kubernetes component certs (apiserver/kubelet), `kubernetes.io/tls` Secrets, and the `kube-apiserver` server cert reached via the `kubernetes` Endpoints. Documents the built-in `cpaas-certificates-rule` alert thresholds at <=30d (Medium), <=10d (High) and 0d (Critical) for both Kubernetes and platform component certificates.
- [docs/en/security/cert/k8s-cert-rotator.mdx](docs/en/security/cert/k8s-cert-rotator.mdx): Operational guide for the Kubernetes Certificate Rotator plugin on On-Premises and DCS clusters. Lists all rotated control-plane and node certificates (apiserver.crt, etcd peer/server, kubeconfigs, kubelet, etc.), explains the daily metadata scan into `cpaas-system/node-local-certs-<node>` ConfigMap and `kubernetes-ca` Secret, the 20%-or-30-day rotation trigger, queued execution, restart strategy (annotation-based for static pods, `systemctl restart kubelet` for kubelet, etcd auto-reload), rotation timelines, and the manual `cert-renew` / `renew-all.sh` fallback when kubelet rotation fails.
- [docs/en/security/cert/olm.mdx](docs/en/security/cert/olm.mdx): Notes that OLM-managed certificates for `olm-operator`, `catalog-operator`, `packageserver`, and `marketplace-operator` are automatically generated and rotated by the system; when an installed Operator's CSV defines webhooks or API services, OLM also automatically issues and rotates the required serving certificates.
- [docs/en/security/cert/rotate-tls-certs-of-platform-access-addr.mdx](docs/en/security/cert/rotate-tls-certs-of-platform-access-addr.mdx): Procedure to rotate the TLS certificate used by ACP's platform access addresses by backing up the `dex-serving-cert` `Certificate` and `dex.tls` Secret in `cpaas-system`, deleting them, and recreating `dex.tls` from a new cert/key with `kubectl create secret tls`. For v4.0.x DR setups, apply the same steps to both the primary and standby clusters.
- [docs/en/security/online_operations/install.mdx](docs/en/security/online_operations/install.mdx): Installation guide for the ACP Telemetry cluster plugin on the `global` cluster, which collects platform metrics and uploads them to Alauda Cloud. After installing via Marketplace > Cluster Plugins, enable the **Online Operations** toggle under System Settings > Platform Maintenance. Requires a valid license and internet access on the global cluster.
- [docs/en/security/platform_security_configurations/change_client_secret.mdx](docs/en/security/platform_security_configurations/change_client_secret.mdx): Cluster-admin procedure to rotate the platform OIDC client secret stored in the `cpaas-oidc-secret` Secret (keys `client-id=alauda-auth` immutable, `client-secret` rotatable). Backs up the Secret, patches/edits only the `client-secret` field using `kubectl patch` or `kubectl edit`, verifies via SHA256 hash, then confirms that `base-operator` syncs to member clusters and that the `frontend` and `apollo` deployments restart cleanly. Includes rollback guidance and requires all `Agnostic` plugins (GitOps, Kiali, Kubeflow Base, Alauda AI) on ACP 4.3.
- [docs/en/security/platform_security_configurations/disable_pkce_plain_method.mdx](docs/en/security/platform_security_configurations/disable_pkce_plain_method.mdx): Hardening procedure to remove the legacy `plain` PKCE code-challenge method from the `OAuth2Client` (id `alauda-auth`) in the `cpaas-system` namespace, leaving only `S256` after all `Agnostic` plugins (GitOps, Kiali, Kubeflow Base, Alauda AI) are upgraded to ACP v4.3-compatible versions. Includes verification by inspecting `.codeChallengeMethods` and a `kubectl patch` rollback restoring `['S256','plain']`.
- [docs/en/security/project/functions/create_project.mdx](docs/en/security/project/functions/create_project.mdx): Procedure to create a multi-cluster Project under Project Management, choosing a non-blacklisted name (excluding `cpaas-system`, `cert-manager`, `default`, `kube-ovn`, `kube-system`, etc.), associating one or more healthy clusters, and configuring per-cluster resource quotas. The platform creates a namespace with the same name in each associated cluster for platform-level isolation.
- [docs/en/security/project/functions/manage_project.mdx](docs/en/security/project/functions/manage_project.mdx): Procedure to update a project's display name and description via Project Management > Details > Actions > Update Basics, and to permanently delete a project (releasing all cluster resources) by entering the project name in the confirmation dialog.
- [docs/en/security/project/functions/project_cluster.mdx](docs/en/security/project/functions/project_cluster.mdx): Procedure to add or remove cluster associations on a Project. Adding a cluster lets administrators allocate per-resource quotas including CPU cores, Memory (Gi), Storage (Gi), PVC count, Pods, vGPU/MPS/pGPU and video memory (with GPU plugin specifics: 1 pGPU = 100 GPU-Manager/MPS cores, GPU-Manager 1 mem unit = 256 Mi, MPS 1 mem unit = 1 Gi). Removing a cluster releases all of the project's business resources in that cluster.
- [docs/en/security/project/functions/project_member.mdx](docs/en/security/project/functions/project_member.mdx): Procedure to import existing platform users or new OIDC users into a project, assign platform-provided project/namespace roles (administrator, developer) or custom Kubernetes Role/ClusterRole bindings, and remove members. Documents the import-source rules when no OIDC IdP is configured (only existing platform/LDAP/local/OIDC users) versus when one is configured (new OIDC accounts accepted but validity unverified).
- [docs/en/security/project/functions/project_quota.mdx](docs/en/security/project/functions/project_quota.mdx): Explains the platform's `ProjectQuota` aggregate that caps the sum of all namespace `ResourceQuota` resources within a project. Admission-time enforcement validates that creating or updating a namespace ResourceQuota keeps the aggregate of keys like `limits.cpu`/`limits.memory`/`requests.cpu`/`requests.memory`/`pods`/`services`/`configmaps`/`secrets`/`pvc` within the project hard limit. Includes allocation tips (10-30% headroom, project-first then per-namespace split) and FAQs about quota-exceeded errors.
- [docs/en/security/project/intro.mdx](docs/en/security/project/intro.mdx): Conceptual introduction to Projects (multi-tenant resource and personnel isolation units that span multiple clusters) and Namespaces (smaller isolated workspaces within a project). Establishes the cluster -> project -> namespace hierarchy and the rule that a namespace's quota comes from a single cluster and a namespace belongs to one project.
- [docs/en/security/security_and_compliance/api_security/install.mdx](docs/en/security/security_and_compliance/api_security/install.mdx): Installation guide for the Alauda Container Platform API Refiner plugin via console (Marketplace > Cluster Plugins) or YAML (`ModuleInfo apirefiner-global` at version v4.2.0 with labels `cpaas.io/cluster-name=global`, `cpaas.io/module-name=apirefiner`). Restricted to the `global` cluster. Documents default filtered resources (`namespaces` v1, `projects` auth.alauda.io/v1, `clustermodules`, `clusters`) and the default desensitized field `metadata.annotations.cpaas.io/creator`.
- [docs/en/security/security_and_compliance/api_security/intro.mdx](docs/en/security/security_and_compliance/api_security/intro.mdx): Introduction to ACP API Refiner, a Kubernetes API response filter for multi-tenant data isolation that filters by user permissions, project, cluster and namespace. Notes limitations: requires `cpaas.io/project`, `cpaas.io/cluster`, `cpaas.io/namespace`, `kubernetes.io/metadata.name` (and optional `cpaas.io/creator`) labels on resources, no LabelSelector OR, no platform-level userbindings filtering, only GET/LIST operations.
- [docs/en/security/security_and_compliance/compliance/howto/container_escape_prevention.md](docs/en/security/security_and_compliance/compliance/howto/container_escape_prevention.md): Kyverno-based recipes to prevent container escape: ready-to-apply `ClusterPolicy` examples that block privileged containers, host PID/IPC/network namespaces, `hostPath` volumes, host ports, dangerous Linux capabilities (drop `ALL`, only allow `NET_BIND_SERVICE`), and require `runAsNonRoot`. Includes environment-specific variants (production strict, dev permissive), system-namespace exclusions, and `validationFailureAction: Audit -> Enforce` rollout guidance.
- [docs/en/security/security_and_compliance/compliance/howto/image_registry_validation.md](docs/en/security/security_and_compliance/compliance/howto/image_registry_validation.md): Kyverno `ClusterPolicy` patterns to whitelist trusted container registries (single, multiple `anyPattern` over `registry.company.com/*`, `gcr.io/*`, `docker.io/library/*`, `quay.io/*`), apply environment-specific rules, deny risky registries via JMESPath conditions, and route team namespaces to specific registries. Documents wildcard rules and common image-format pitfalls.
- [docs/en/security/security_and_compliance/compliance/howto/image_signature_verification.md](docs/en/security/security_and_compliance/compliance/howto/image_signature_verification.md): Kyverno `verifyImages` workflow using `cosign generate-key-pair` and `cosign sign` to enforce image signatures, with policies for single keys, multiple required attestors (security + dev team), environment-specific Enforce/Audit failure actions, and X.509-certificate-based verification with a `rekor` transparency log URL. Uses `mutateDigest: true` to convert tags to immutable digests.
- [docs/en/security/security_and_compliance/compliance/howto/image_signature_with_secrets.md](docs/en/security/security_and_compliance/compliance/howto/image_signature_with_secrets.md): Pattern for storing cosign public keys in Kubernetes Secrets (created from file, literal, or YAML manifest) referenced by Kyverno `verifyImages.attestors[].entries[].keys.secret` with RBAC-restricted `kyverno-secret-reader` Role/RoleBinding. Covers single-team, multi-team namespaces (`frontend-*`, `backend-*`), critical multi-signature production policies, and air-gapped configuration via `rekor.url: ''` with `ignoreTlog`/`ignoreSCT`.
- [docs/en/security/security_and_compliance/compliance/howto/network_security.md](docs/en/security/security_and_compliance/compliance/howto/network_security.md): Kyverno network-security policies: disallow `hostNetwork`/`hostPort` (or restrict to 30000-32767), require associated NetworkPolicies via API context lookup, restrict Service types (`!NodePort`, ban `LoadBalancer` in dev), enforce TLS and SSL-redirect annotations on Ingress, restrict `dnsPolicy` to `Default | ClusterFirst`, and segment tiers (frontend/backend/database) via labels.
- [docs/en/security/security_and_compliance/compliance/howto/private_registry_access.md](docs/en/security/security_and_compliance/compliance/howto/private_registry_access.md): Configures Kyverno to access private registries for signature/metadata verification by creating a `docker-registry` Secret in the kyverno namespace, attaching it as `imagePullSecrets` to the kyverno ServiceAccount or Deployment, and enabling cloud credential helpers via `REGISTRY_CREDENTIAL_HELPERS=ecr-login,gcr,acr-env`.
- [docs/en/security/security_and_compliance/compliance/howto/security_context_enforcement.md](docs/en/security/security_and_compliance/compliance/howto/security_context_enforcement.md): Kyverno policies enforcing Pod security contexts: require `runAsNonRoot`, disallow `allowPrivilegeEscalation`, restrict user IDs to 1000-65535, require non-zero `runAsGroup`, restrict `seccompProfile` to `RuntimeDefault` or `Localhost`, require dropping ALL Linux capabilities, and restrict AppArmor profiles. Includes graduated environment policies (basic/enhanced/maximum) and a label-driven Policy (`add-exact-security-context`) that mutates Pods in non-privileged namespaces (skipping those with `pod-security.kubernetes.io/enforce: privileged`).
- [docs/en/security/security_and_compliance/compliance/howto/volume_security.md](docs/en/security/security_and_compliance/compliance/howto/volume_security.md): Kyverno policies for volume security: restrict allowed volume types to `configMap`/`csi`/`downwardAPI`/`emptyDir`/`ephemeral`/`persistentVolumeClaim`/`projected`/`secret`; disallow or restrict `hostPath` (read-only, allowed paths); block privileged volume types (`gcePersistentDisk`, `awsElasticBlockStore`, `nfs`, `rbd`, `glusterfs`, etc.); require `readOnlyRootFilesystem: true`; block mounts to `/etc`, `/root`, `/var/run/docker.sock`, `/var/lib/kubelet`; require sizeLimit on emptyDir; and forbid `emptyDir.medium: Memory`.
- [docs/en/security/security_and_compliance/compliance/install.mdx](docs/en/security/security_and_compliance/compliance/install.mdx): Installation guide for the Alauda Container Platform Compliance with Kyverno plugin via the console (Marketplace > Cluster Plugins) or by creating a `ModuleInfo kyverno-global` resource (`cluster.alauda.io/v1alpha1`) at version v4.2.0 with the `cpaas.io/module-name=kyverno` label.
- [docs/en/security/security_and_compliance/compliance/intro.mdx](docs/en/security/security_and_compliance/compliance/intro.mdx): Positions ACP's Compliance functionality as a Kyverno-based mechanism that lets users define custom Kubernetes policies in YAML, automatically validate resources, and monitor violations at both resource and policy levels through the platform UI.
- [docs/en/security/security_and_compliance/compliance_service.mdx](docs/en/security/security_and_compliance/compliance_service.mdx): Landing page (`compliance-service` external site) for the Alauda Container Platform Compliance Service module, which provides out-of-the-box STIG and MicroOS compliance scanning with scheduled scans and reporting.
- [docs/en/security/users_and_roles/group/functions/add_role.mdx](docs/en/security/users_and_roles/group/functions/add_role.mdx): Walks platform administrators through assigning and removing roles for a user group (local or IDP-synced) via the User Group Management page, choosing the role's scope (cluster, project, or namespace) and noting that each role can only be added once per group and that removal revokes all permissions inherited by group members.
- [docs/en/security/users_and_roles/group/functions/create_group_howto.mdx](docs/en/security/users_and_roles/group/functions/create_group_howto.mdx): Steps for creating local user groups from User Group Management with name and description fields, then updating or deleting them; explains that Source=Local groups allow full edits while Source=IDP groups only allow description updates, and that deletion removes all members and their inherited role bindings.
- [docs/en/security/users_and_roles/group/functions/manage_membership.mdx](docs/en/security/users_and_roles/group/functions/manage_membership.mdx): Procedure for importing and removing members of a local user group, with caveats that system accounts and the current user cannot be managed, the maximum is 5000 members per group, and removed users automatically lose any group-granted operational permissions. Supports per-member removal and batch removal flows.
- [docs/en/security/users_and_roles/group/intro.mdx](docs/en/security/users_and_roles/group/intro.mdx): Overview of user-group based permission management: explains how grouping multiple users enables batch role assignment for personnel changes, and distinguishes Local user groups (created on platform, editable, member-managed) from IDP-synchronized groups from LDAP or Azure AD (read-only membership, role-management only).
- [docs/en/security/users_and_roles/idp/functions/ldap_manage.mdx](docs/en/security/users_and_roles/idp/functions/ldap_manage.mdx): Comprehensive guide to integrating OpenLDAP or Microsoft Active Directory with the platform via Dex. Covers LDAP terminology (dc/ou/cn/uid/sAMAccountName), the Add LDAP form (server address, bindDN, search settings including objectClass, login field, filter conditions, search scope), an extensive YAML Connector example, dozens of user/group filter expressions with AND/OR operators, manual and cron-based user synchronization, and update/delete operations.
- [docs/en/security/users_and_roles/idp/functions/oidc_manage.mdx](docs/en/security/users_and_roles/idp/functions/oidc_manage.mdx): Configures OIDC (OpenID Connect over OAuth 2.0) identity providers with required fields like Identity Provider URL, Client ID/Secret, Redirect URI, and Logout URL. Includes a Dex Connector YAML example covering scopes, claimMapping for email/groups/phone/preferred_username, overrideClaimMapping, groupsKey, insecureEnableGroups, and claimExtra custom fields, plus update/delete consequences for synchronized users.
- [docs/en/security/users_and_roles/idp/intro.mdx](docs/en/security/users_and_roles/idp/intro.mdx): Brief introduction to the platform's identity provider integration via Dex, describing the two supported connector types: LDAP for enterprise directory authentication and OIDC for third-party identity federation, and noting that other Dex connector types require contacting technical support.
- [docs/en/security/users_and_roles/idp/trouble_shooting/delete_user.mdx](docs/en/security/users_and_roles/idp/trouble_shooting/delete_user.mdx): Troubleshooting workaround for the 'user already exists' error during creation or IDP sync caused by the platform retaining deleted-user records. Provides specific `kubectl delete users` commands targeting the auth.cpaas.io/user.state=deleted label, with a separate cleanup script that also removes orphaned password resources for local users.
- [docs/en/security/users_and_roles/role/functions/create_role_howto.mdx](docs/en/security/users_and_roles/role/functions/create_role_howto.mdx): Walkthrough for creating Kubernetes-native Role or ClusterRole objects (the ACP 4.2+ replacement for checkbox-based custom roles) from the Kubernetes Roles page, configuring API groups, resources, verbs (get/list/watch/create/update/patch/delete), then attaching RoleBinding or ClusterRoleBinding to users, groups, or service accounts. Includes kubectl verification commands.
- [docs/en/security/users_and_roles/role/functions/manage_role_howto.mdx](docs/en/security/users_and_roles/role/functions/manage_role_howto.mdx): How to view, grant, edit, and delete platform roles and Kubernetes roles. Covers binding platform roles via the console or through a UserBinding YAML resource (with auth.cpaas.io/role.level, role.name, cluster, namespace, project labels), editing Kubernetes role YAML, deleting roles with RoleBinding cleanup warnings, and managing RoleBindings from both role and user/group perspectives.
- [docs/en/security/users_and_roles/role/functions/roletemplate_howto.mdx](docs/en/security/users_and_roles/role/functions/roletemplate_howto.mdx): Deep-dive on the RoleTemplate CRD (auth.alauda.io/v1beta1) used to author custom platform roles. Compares three configuration methods: legacy FunctionResource references, ClusterRole label-based aggregationRules (recommended for v4.2+), and native customRules. Documents the full field reference including roletemplate.level (platform/cluster/project/namespace), aggregation scopes (cluster/project-ns/business-ns/system-ns/kube-public), system aggregation labels (rbac.cpaas.io/aggregate-to-*), and trim-from-system-template examples.
- [docs/en/security/users_and_roles/role/intro.mdx](docs/en/security/users_and_roles/role/intro.mdx): Introduction to the post-ACP-4.2 role model split into Platform Roles (read-only system templates such as Platform Administrator, Platform Auditors, Cluster Administrator, Project Administrator, namespace-admin-system, Developers) and Kubernetes Roles (native Role/ClusterRole objects). Notes the removal of the legacy checkbox custom-role experience.
- [docs/en/security/users_and_roles/user/functions/add_role.mdx](docs/en/security/users_and_roles/user/functions/add_role.mdx): Platform admin procedure for binding or unbinding roles to a user. Covers the Platform Roles tab (selecting predefined system roles and scope: Cluster/Project/Namespace) and the Kubernetes Roles tab (creating RoleBinding or ClusterRoleBinding by selecting cluster, namespace, and role). Notes that built-in Cluster Administrator cannot be reassigned for the global cluster.
- [docs/en/security/users_and_roles/user/functions/create_user.mdx](docs/en/security/users_and_roles/user/functions/create_user.mdx): Creates local users either through the console (with password type Random/Custom, mailbox, validity period Permanent or Custom range, role assignments, and 'Continue Creating' toggle) or via a User CRD YAML in the global cluster. Documents password rules (8-32 chars, letters/numbers/special chars) and the required labels including the MD5 hash of spec.email.
- [docs/en/security/users_and_roles/user/functions/manage_user.mdx](docs/en/security/users_and_roles/user/functions/manage_user.mdx): User lifecycle operations: reset local user passwords, update validity periods, activate/disable users (status transitions between normal/disabled/locked), add a user to a local user group with automatic role inheritance, view Platform Roles vs Kubernetes Roles tabs, delete users, and batch operations for update-validity/activate/deactivate/delete (the last requires re-entering the current account password).
- [docs/en/security/users_and_roles/user/intro.mdx](docs/en/security/users_and_roles/user/intro.mdx): Overview of the platform's user sources (Local, LDAP, OIDC, other dex connectors like GitHub/Microsoft), the rules governing unique usernames and automatic association of matching-name IDP users, the two role-assignment tabs (Platform Roles vs Kubernetes Roles) on each user detail page, and the four user lifecycle statuses (Normal, Disabled, Locked after 5 failed logins in 24h, Invalid for LDAP-deleted accounts).
- [docs/en/security/users_and_roles/user_policy/intro.mdx](docs/en/security/users_and_roles/user_policy/intro.mdx): Configures user-level security policies under User Role Management > User Security Policy: User Authentication Policy (dual-factor with verification codes), Password Security Policy (force change on first login and after a configurable period), automatic User Disablement and User Locking after failed logins, Notification Policy for emailing initial passwords, and Access Control for session timeouts, concurrent login limits, and browser-tab-based session termination.

## service_mesh

- [docs/en/service_mesh/servicemesh-1.x.mdx](docs/en/service_mesh/servicemesh-1.x.mdx): One-paragraph product entry point for Alauda's Istio-based Service Mesh 1.x platform highlighting one-click deployment/upgrade, visualized service governance, application performance management, and high-availability gateway management, with content rendered from the externally referenced 'servicemeshv1' site.
- [docs/en/service_mesh/servicemesh-2.x.mdx](docs/en/service_mesh/servicemesh-2.x.mdx): Product entry point for Alauda Service Mesh 2.x, built on Istio and installed via a new Istio Operator derived from the Sail Operator. Covers core mesh capabilities (service discovery, load balancing, mTLS, failure recovery, metrics, A/B testing, canary deployments, fine-grained access control) and pulls the full doc set from the external 'servicemesh' site.

## storage

- [docs/en/storage/storagesystem_ceph/architecture.mdx](docs/en/storage/storagesystem_ceph/architecture.mdx): Detailed architecture reference for Alauda Build of Rook-Ceph as the cloud-native storage layer on Alauda Container Platform. Describes the three storage types (file/block/object), the integrated open-source projects (Ceph, Rook, Ceph CSI Operator, Ceph CSI), the two OLM operators (`acp-storage-operator` and `rook-ceph-operator`), managed daemons (mons/OSDs/mgr/RGW/MDS), the watched CRDs (CephCluster, CephObjectStore, CephFilesystem, CephBlockPool), pod lifecycle, internal vs external installation modes, and OLM-driven upgrade flow via Subscription/InstallPlan/CSV.
- [docs/en/storage/storagesystem_ceph/concepts/concept.mdx](docs/en/storage/storagesystem_ceph/concepts/concept.mdx): Conceptual reference for the Rook operator and the core Ceph modules: MON (quorum and cluster state), MGR (monitoring/visualization), OSD (object storage daemons bound to physical drives), MDS (CephFS metadata), RGW (S3/Swift gateway with Keystone support), RADOS (the core object store), LIBRADOS (client library for PHP/Ruby/Java/Python/C/C++ and POSIX), RBD (block device), and CephFS (POSIX file system).
- [docs/en/storage/storagesystem_ceph/functions/component_deploy.mdx](docs/en/storage/storagesystem_ceph/functions/component_deploy.mdx): Console procedures under Storage Management > Distributed Storage for pinning MON/MGR/MDS/RGW components to specific nodes via the Fixed Deployment toggle (minimum 3 nodes), with caveats that updates rebuild instances and that Extend-type clusters do not support fixed deployment, plus how deleting a component triggers automatic redeployment.
- [docs/en/storage/storagesystem_ceph/functions/device_class.mdx](docs/en/storage/storagesystem_ceph/functions/device_class.mdx): How to add custom device classes (rejecting reserved names hdd/ssd/nvme) and map raw disks to them using either Selection Device (auto-discovered via Alauda Build of LocalStorage Operator, requiring disk/mpath type, no filesystem, capacity >10 GiB) or manual Input Device names. Also documents the four hard-disk states (Normal IN+UP, Abnormal IN+DOWN, Offline OUT+UP, Fault OUT+DOWN) and notes that Extend-type clusters do not support adding device classes.
- [docs/en/storage/storagesystem_ceph/functions/monitor.mdx](docs/en/storage/storagesystem_ceph/functions/monitor.mdx): Describes the out-of-the-box monitoring (storage overview, performance read/write bandwidth and IOPS per cluster/pool/OSD, component CPU/memory) and alerting capabilities of distributed storage, including default alert strategies, the three alert levels (Disaster/Severe/Warning), notification configuration in the operation and maintenance center, and guidance for handling Warning/Failure states and conducting fault reviews via Alert History.
- [docs/en/storage/storagesystem_ceph/functions/pool_management.mdx](docs/en/storage/storagesystem_ceph/functions/pool_management.mdx): Creates and manages storage pools within a Ceph cluster (limits: one file pool, one object pool, up to eight block pools). Configuration covers Storage Type, Replica Count (default 3 for Standard, fixed at 4 for Extended clusters), Device Class assignment, and object-storage-specific settings such as Region, internal port, NodePort-based external access, and instance count. Also covers deleting pools (after dissociating storage classes) and viewing object-pool access addresses.
- [docs/en/storage/storagesystem_ceph/how_to/clean_ceph.mdx](docs/en/storage/storagesystem_ceph/how_to/clean_ceph.mdx): Step-by-step uninstall procedure for a rook-ceph cluster: delete VolumeSnapshotClasses (csi-cephfs-snapshotclass, csi-rbd-snapshotclass), StorageClasses, storage pools (including built-in CephBlockPools labeled cpaas.io/builtin=true), patch the CephCluster with cleanupPolicy `yes-really-destroy-data`, delete the CephCluster and cleanup jobs, remove the rook-operator OLM Subscription, force-clean stuck ConfigMaps/Secrets by removing finalizers, then run the included clean-rook.sh script on each storage node to fdisk/sgdisk/dd/blkdiscard the OSD device and remove /dev/mapper/ceph-* entries.
- [docs/en/storage/storagesystem_ceph/how_to/configure_osd_wal_db_partitions.mdx](docs/en/storage/storagesystem_ceph/how_to/configure_osd_wal_db_partitions.mdx): Configures fast BlueStore metadata partitions (block.db + WAL) for host-based Rook-Ceph OSDs by editing the CephCluster `spec.storage` to add `metadataDevice` either at node level (lvm batch, shared across OSDs) or per-device (lvm prepare, partition path allowed). Includes capacity-planning rules (1-2% of HDD for RBD-dominant, ≥4% for RGW/heavy omap), use of stable /dev/disk/by-id paths, prerequisites, verification with `ceph -s`, `ceph osd tree`, and `ceph-volume lvm list`, and the warning that changing these fields does not migrate existing OSDs.
- [docs/en/storage/storagesystem_ceph/how_to/create_object_user.mdx](docs/en/storage/storagesystem_ceph/how_to/create_object_user.mdx): Creates Ceph Object Store users via the CephObjectStoreUser CRD with display name, store reference, quotas (maxBuckets, maxSize, maxObjects), and Ceph admin capabilities across user/buckets/usage/metadata/zone/roles/info/amz-cache/bilog/mdlog/datalog/user-policy/odic-provider/ratelimit. Covers `allowUsersInNamespaces` for cross-namespace users and how to retrieve the generated AccessKey/SecretKey from the user's Secret via jsonpath.
- [docs/en/storage/storagesystem_ceph/how_to/dedicated_cluster.mdx](docs/en/storage/storagesystem_ceph/how_to/dedicated_cluster.mdx): Best-practice deployment of distributed storage on an isolated bare-metal cluster (storage-compute separation). Specifies per-component CPU/memory (MON 2c/3Gi, OSD 4c/8Gi, MDS 3c/8Gi, etc.), capacity planning under 3-replica with 80%/95% alert thresholds, scaling by adding nodes rather than disks, network requirements (HostNetwork, separate Public and Cluster Networks, 10GbE+, <30 ms RTT, <0.05% loss), and a full CephCluster YAML example with placement, tolerations, IPv4 dual networks, mon count=3, mgr count=2 with pg_autoscaler, plus CephFilesystem/CephBlockPool/CephObjectStore manifests.
- [docs/en/storage/storagesystem_ceph/how_to/disaster_recovery/dr_block.mdx](docs/en/storage/storagesystem_ceph/how_to/disaster_recovery/dr_block.mdx): Cross-cluster RBD Mirror disaster recovery for block storage. Walks through enabling pool mirroring in image mode on both clusters, exchanging peer tokens (rbd-peer-site-secret), deploying CephRBDMirror, installing the csi-addons k8s-controller/k8s-sidecar v0.12.0 with CSI_ENABLE_OMAP_GENERATOR/CSI_ENABLE_CSIADDONS, creating VolumeReplicationClass (snapshot mode, schedulingInterval such as 1h), enabling per-PVC VolumeReplication, and detailed Relocation/Failover/Failback procedures via replicationState transitions. Network requirements include <30 ms RTT and <0.05% packet loss between Public networks.
- [docs/en/storage/storagesystem_ceph/how_to/disaster_recovery/dr_filesystem.mdx](docs/en/storage/storagesystem_ceph/how_to/disaster_recovery/dr_filesystem.mdx): Cross-cluster CephFS Mirror disaster recovery: enable mirroring on a Secondary cluster's CephFilesystem, extract the Peer Token, create `fs-secondary-site-secret` on the Primary, patch the Primary CephFilesystem with peers/snapshotSchedules (e.g. path:/ interval:1h) and snapshotRetention policies, and deploy a CephFilesystemMirror daemon with system-node-critical priority. Includes prerequisites (matching v3.12+ clusters, same-name file pools) and failover guidance.
- [docs/en/storage/storagesystem_ceph/how_to/disaster_recovery/dr_object.mdx](docs/en/storage/storagesystem_ceph/how_to/disaster_recovery/dr_object.mdx): RGW Multi-Site replication for object storage between two Ceph clusters using Realm/ZoneGroup/Zone resources. Walks through creating CephObjectRealm, CephObjectZoneGroup, CephObjectZone, CephBlockPool builtin-rgw-root and CephObjectStore on the Primary, exposing NodePort external Service endpoints, extracting access-key/secret-key from $REALM_NAME-keys, then pulling the Realm on the Secondary cluster. Verifies sync via `radosgw-admin sync status` and details failover/failback by promoting zones with `radosgw-admin zone modify --master` and `period update --commit`.
- [docs/en/storage/storagesystem_ceph/how_to/in-transit-encryption.mdx](docs/en/storage/storagesystem_ceph/how_to/in-transit-encryption.mdx): Enables Ceph msgr2 in-transit encryption for ACP distributed storage by setting `spec.network.connections.encryption.enabled: true` on the CephCluster. Requires ACP v4.3.0+, kernel 5.11+ and Ubuntu 22.04+ on Ceph daemon and client nodes, ms_mode secure clients, and open port 3300. Documents expected performance impact (~5-15% latency increase, ~10-30% CPU on AES-NI hardware), enable-during-creation vs post-deployment patching, disabling, and troubleshooting steps.
- [docs/en/storage/storagesystem_ceph/how_to/persistent-volume-encryption.mdx](docs/en/storage/storagesystem_ceph/how_to/persistent-volume-encryption.mdx): End-to-end persistent-volume encryption for RBD-backed PVs using an external KMS (HashiCorp Vault via vaulttokens or alpha vaulttenantsa, or Thales CipherTrust Manager via KMIP). Covers the csi-kms-connection-details ConfigMap entries (vaultAddress, vaultBackend, vaultAuthPath, tenantSAName, kmipAddress/Port/CAPath/keyIdentifier), Vault kubernetes-auth setup with ServiceAccount/ClusterRoleBinding/tokenreviews, creating an encryption-enabled StorageClass with `encrypted: true` and `encryptionKMSID`, per-tenant `ceph-csi-kms-config` overrides, and enabling/disabling/scheduling key rotation through csi-addons annotations like `keyrotation.csiaddons.openshift.io/schedule: @weekly`.
- [docs/en/storage/storagesystem_ceph/how_to/pool_quota.mdx](docs/en/storage/storagesystem_ceph/how_to/pool_quota.mdx): Applies logical-size quotas at the Ceph storage pool level via `kubectl patch` with JSON patches: CephFilesystem `spec.dataPools[0].quotas.maxSize`, CephBlockPool `spec.quotas.maxSize`, and CephObjectStore `spec.dataPool.quotas.maxSize`. Notes that actual physical consumption equals quota * replication and shows how to verify with `ceph osd pool ls detail | grep max_bytes`.
- [docs/en/storage/storagesystem_ceph/how_to/replacing-or-removing-devices.mdx](docs/en/storage/storagesystem_ceph/how_to/replacing-or-removing-devices.mdx): Procedure for safely removing a disk from a Rook-Ceph cluster: verify HEALTH_OK and that `useAllDevices: false`, add a replacement disk via Device Classes if remaining AVAIL is insufficient, scale down rook-ceph-operator, mark the OSD `out` and wait for backfill to finish, edit the CephCluster to remove the device entry, delete the rook-ceph-osd-<id> Deployment, run `ceph osd purge --yes-i-really-mean-it`, wipe the disk with sgdisk/dd, and scale the operator back up.
- [docs/en/storage/storagesystem_ceph/how_to/replacing-or-removing-nodes.mdx](docs/en/storage/storagesystem_ceph/how_to/replacing-or-removing-nodes.mdx): Removes an entire storage node from a Rook-Ceph cluster. Inventory OSDs on the old node, check total AVAIL on remaining nodes, optionally add a replacement node via Device Classes, exclude the old node from MON/MGR/MDS placement through Component Deployment Configuration, mark every OSD `out`, wait for HEALTH_OK, then delete the node block from `cephcluster.spec.storage.nodes`, delete each rook-ceph-osd-<id> Deployment, and `ceph osd purge` each OSD.
- [docs/en/storage/storagesystem_ceph/how_to/rgw-d3n-cache.mdx](docs/en/storage/storagesystem_ceph/how_to/rgw-d3n-cache.mdx): Enables the Ceph RGW D3N (Data Delivery Network) local NVMe/SSD cache to accelerate hot-object reads. Steps cover mounting an XFS-formatted directory on each RGW node (persistently via /etc/fstab), editing the CephObjectStore to add `gateway.additionalVolumeMounts` with a hostPath volume, and turning on `rgw_d3n_l1_local_datacache_enabled`, `rgw_d3n_l1_datacache_persistent_path`, and `rgw_d3n_l1_datacache_size`. Verifies via `ceph config dump | grep d3n` and RGW pod logs.
- [docs/en/storage/storagesystem_ceph/how_to/set-ceph-osd-full-thresholds.mdx](docs/en/storage/storagesystem_ceph/how_to/set-ceph-osd-full-thresholds.mdx): Adjusts the three Ceph capacity thresholds (`nearfull`, `backfillfull`, `full`) either with `ceph osd set-*-ratio` from the rook-ceph-tools pod or declaratively via `cephcluster.spec.storage` fields `nearFullRatio`, `backfillFullRatio`, `fullRatio`. Stresses keeping the values in ascending order, treating threshold raises as emergency mitigation, and verifying with `ceph osd dump | egrep ratio` after restoring baselines.
- [docs/en/storage/storagesystem_ceph/how_to/update_parameters.mdx](docs/en/storage/storagesystem_ceph/how_to/update_parameters.mdx): Post-creation update of Ceph optimization parameters: edit the `rook-config-override-user` ConfigMap's `.data.config` (e.g. global `mon_memory_target`, `mds_cache_memory_limit`, `osd_memory_target`), set the `rook.cpaas.io/need-sync` annotation to `true`, then apply changes at runtime via `ceph tell [mon|osd|mgr|mds|rgw].* config set` from the rook-ceph-tools pod (scaled from the CSV's Deployments section).
- [docs/en/storage/storagesystem_ceph/installation/access_storage_service.mdx](docs/en/storage/storagesystem_ceph/installation/access_storage_service.mdx): Installs ACP distributed storage in External mode to consume an existing Ceph cluster (either another business cluster's deployment or external Ceph >=14.2.3). Covers required uploads (Storage Essentials and Rook-Ceph packages), open ports 3300/6789/6800-7300/7480, gathering authentication data via `ceph fsid`/`ceph mon dump`/`ceph auth get-key client.admin`/`ceph fs ls`/`ceph osd dump`, deploying the Alauda Container Platform Storage Essentials operator, then completing the Access Storage > External Mode wizard with snapshot, network (Host or Container), and storage-class settings.
- [docs/en/storage/storagesystem_ceph/installation/create_service_extend.mdx](docs/en/storage/storagesystem_ceph/installation/create_service_extend.mdx): Creates an Alpha-stage Stretch cluster spanning two data availability zones plus one quorum zone for in-cluster disaster recovery. Distributes nodes via `topology.kubernetes.io/zone` labels (≥5 nodes total, ≥2 compute nodes per data zone, MON instances 2+2+1), enforces constraints like no erasure coding, no device classes, all-flash OSDs, ≤10ms RTT between zones, fixed 4-replica pools, and details min_size adjustments and arbiter behavior during a zone failure.
- [docs/en/storage/storagesystem_ceph/installation/create_service_stand.mdx](docs/en/storage/storagesystem_ceph/installation/create_service_stand.mdx): Installs distributed storage in Internal (Standard) mode. Prerequisites include 3+ nodes, blank/unformatted disks >50 GiB, and a `LimitNOFILE=1048576` setting in `/etc/systemd/system/containerd.service` for Containerd runtimes. Steps: install the Alauda Container Platform Storage Essentials operator into acp-storage, optionally install Alauda Build of LocalStorage for disk auto-discovery, deploy the rook-operator, run the Create Cluster wizard with device class (Default vs Custom, Selection vs Input Device), Snapshot/Monitoring toggles, advanced options (Host vs Container network, Ceph-format optimization parameters, MON/MGR/MDS/RGW fixed deployment), then create File/Block/Object storage pools with replica count and (for object) region/port/external access/instance count.
- [docs/en/storage/storagesystem_ceph/intro.mdx](docs/en/storage/storagesystem_ceph/intro.mdx): Product overview of Alauda Build of Rook-Ceph as a hyper-converged in-cluster storage solution covering block/file/object storage with automatic deployment, snapshot backup, volume clone, capacity/performance/component monitoring, built-in alert policies, multi-replica reliability, hybrid disk support, and online expansion. Defines the terms 'distributed storage' (local Ceph) versus 'external storage'.
- [docs/en/storage/storagesystem_ceph/planning.mdx](docs/en/storage/storagesystem_ceph/planning.mdx): Planning checklist for ACP distributed storage covering deployment architectures (Internal co-resident, Internal dedicated-node, External), security options (KMS-backed RBD storage class encryption with HashiCorp Vault or Thales CipherTrust; msgr2 in-transit encryption), node roles, infrastructure sizing tables (per-component MON 2c/3Gi to OSD 4c/8Gi, aggregate cluster budgets like 24-45 logical CPUs and 72-96 GiB memory), capacity planning under 3-replica, IPv6 single-stack support, Regional-DR vs Stretch Cluster trade-offs, and links to follow-on deployment guides.
- [docs/en/storage/storagesystem_topolvm/functions/device_management.mdx](docs/en/storage/storagesystem_topolvm/functions/device_management.mdx): Adds storage nodes and disks to a TopoLVM Local Storage cluster from Storage Management > Local Storage > Details. Each storage device must be a raw bare disk (not a partition), assigned to a named Device Class (e.g. hdd, ssd) that groups disks with the same characteristics. Includes the Add Storage Node and Add Storage Device flows for resolving Unavailable device classes.
- [docs/en/storage/storagesystem_topolvm/functions/monitor.mdx](docs/en/storage/storagesystem_topolvm/functions/monitor.mdx): Built-in monitoring and alerting for TopoLVM Local Storage. Performance Monitoring collects read/write bandwidth, IOPS, and latency; Capacity Monitoring breaks usage down by device type; Health Status reflects node service and device-type states (Alert/Unknown/Unavailable). Documents default alert policies, the Critical/Major/Warning severity levels, configuring notifications through the operations center, and post-mortem analysis using Alert History.
- [docs/en/storage/storagesystem_topolvm/how_to/backup_and_restore.mdx](docs/en/storage/storagesystem_topolvm/how_to/backup_and_restore.mdx): Uses Velero (via the Alauda Container Platform Data Backup for Velero cluster plugin) backed by S3-compatible storage (Ceph or MinIO) to back up and restore TopoLVM filesystem PVCs. Labels target PVCs and their attached pods with `velero-backup=true`, creates a Velero `Schedule` with `defaultVolumesToFsBackup: true`, and restores in a target cluster by pointing at the same S3 bucket and optionally remapping namespaces.
- [docs/en/storage/storagesystem_topolvm/how_to/lvcreate_option.mdx](docs/en/storage/storagesystem_topolvm/how_to/lvcreate_option.mdx): Creates a striped LVM logical volume through TopoLVM by setting `topolvm.io/lvcreate-option-class` on the StorageClass, using either the built-in `striped-default` class (--stripes=2 --stripesize=64) or a custom LVCreateOption CR (e.g. striped-custom with --stripes=3) deployed in `nativestor-system`. Requires at least two devices per node in the device class.
- [docs/en/storage/storagesystem_topolvm/how_to/remove-disk.mdx](docs/en/storage/storagesystem_topolvm/how_to/remove-disk.mdx): Three carefully scripted scenarios for removing TopoLVM resources: (1) remove individual failed volume-group devices using `vgs`, `lvs`, `lvremove`, and `vgreduce --removemissing`; (2) remove a completely damaged device-class volume group from a retained node; (3) permanently remove an entire storage node from TopolvmCluster. Each scenario scales down topolvm-operator, deletes associated PVCs/PVs/logicalvolumes.topolvm.cybozu.com, and updates the topolvmcluster CR and per-node lvmdconfig ConfigMap (`lvmd.yaml`, `status.json`).
- [docs/en/storage/storagesystem_topolvm/installation.mdx](docs/en/storage/storagesystem_topolvm/installation.mdx): Installs Alauda Build of TopoLVM as a CSI-based local storage solution. Requires lvm2 on each node and the Alauda Container Platform Storage Essentials + Alauda Build of TopoLVM offline packages. Walks through the Marketplace operator install, the Local Storage create-cluster wizard (selecting nodes with bare disks, device classes, raw devices like /dev/sda, snapshots), and creating a TopoLVM StorageClass with XFS or EXT4, Delete/Retain reclaim policy, and RWO access mode.
- [docs/en/storage/storagesystem_topolvm/intro.mdx](docs/en/storage/storagesystem_topolvm/intro.mdx): Introduction to TopoLVM as a Kubernetes CSI plugin for local LVM-backed volumes, highlighting low-latency local storage, topology-awareness to schedule pods near their volumes, dynamic provisioning/resize, and deep integration with Kubernetes PVC objects. Positions TopoLVM for high-performance workloads like databases and caches.

## ui

- [docs/en/ui/cli_tools/ac/ac-and-kubectl-usage.md](docs/en/ui/cli_tools/ac/ac-and-kubectl-usage.md): Explains the relationship between the `ac` binary (the ACP CLI extending kubectl) and the standalone `kubectl` binary shipped with ACP. `ac` adds ACP-specific commands such as `ac login`, `ac logout`, `ac config get-sessions`, `ac config use-session`, `ac config use-cluster`, `ac namespace`, and `ac config sync`, and automatically routes platform-level resources like Users and Projects to the global cluster regardless of current context.
- [docs/en/ui/cli_tools/ac/administrator-command-reference.md](docs/en/ui/cli_tools/ac/administrator-command-reference.md): Reference for `ac adm` administrator subcommands requiring cluster-admin permissions: certificate approve/deny, cordon/drain/uncordon nodes, new-project and new-project-namespace with --cluster scope, RBAC policy (add-cluster-role-to-user, add-namespace-role-to-user, add-project-role-to-user, add-role-to-user), release import-manifest for ProductManifest creation, taint, and upgrade/upgrade status with --cluster, --to-latest, --to, and --allow-explicit-upgrade flags.
- [docs/en/ui/cli_tools/ac/configuration.md](docs/en/ui/cli_tools/ac/configuration.md): Configures ACP CLI shell environment and authenticated access. Covers enabling Bash and Zsh tab completion via `ac completion bash|zsh`, and using `ac login <platform-url> --name <session-name>` to discover all platform clusters, populate a multi-cluster kubeconfig with `acp:<session>:<cluster>` naming, export it via `ac config view --raw > kubeconfig`, and synchronize with `ac config sync`. Includes security considerations for kubeconfig token files.
- [docs/en/ui/cli_tools/ac/developer-command-reference.md](docs/en/ui/cli_tools/ac/developer-command-reference.md): Exhaustive reference for `ac` developer commands mirroring kubectl: annotate, api-resources, api-versions, apply (+ edit-last-applied/set-last-applied/view-last-applied), attach, auth (can-i, reconcile, whoami), autoscale, cluster-info dump, completion (bash/zsh/fish/powershell), config (current-context, set-cluster/-context/-credentials, get-sessions, use-cluster/-session, sync, view, etc.), cp, create (clusterrole, ingress, job, secret tls/docker-registry/generic, service, token, ...), delete, describe, diff, edit, events, exec, explain, expose, get, kustomize, label, login (with --workload, --idp, env vars), logout, logs, namespace, patch, plugin, port-forward, process, proxy, replace, rollout, run, scale, set env/image/resources/selector/serviceaccount/subject, version, and wait.
- [docs/en/ui/cli_tools/ac/extending-with-plugins.md](docs/en/ui/cli_tools/ac/extending-with-plugins.md): Guide to writing and installing ACP CLI plugins. Any executable named `ac-<plugin>` or `kubectl-<plugin>` placed on $PATH becomes a subcommand; underscores in filenames render as dashes in the invocation. Provides a minimal Bash example handling `version`/`config` arguments and notes that plugins cannot override built-in ac commands. Lists discovered plugins via `ac plugin list`.
- [docs/en/ui/cli_tools/ac/getting-started.md](docs/en/ui/cli_tools/ac/getting-started.md): Onboarding tutorial for the `ac` CLI: download per-OS/arch binaries from cloud.alauda.io, install to /usr/local/bin/ac, run `ac login` interactively or via AC_LOGIN_* environment variables for automation, use `ac namespace`, `ac config use-cluster`, and `ac config use-session` for context switching, and perform a verify-the-install walk-through by applying a test nginx pod, inspecting with `ac get pods`/`ac describe`/`ac logs`, then cleaning up and `ac logout`.
- [docs/en/ui/cli_tools/ac/managing-cli-profiles.md](docs/en/ui/cli_tools/ac/managing-cli-profiles.md): In-depth guide to ACP CLI session and context management. Explains `ac login` flag and env-var forms, `ac logout`, `ac config get-sessions/use-session/use-cluster`, and `ac config sync`. Shows the ACP-extended kubeconfig structure with `acp.io/v1` extensions (platformUrl, sessionName, clusterName, isGlobal) and the `acp:<session>:<cluster>` naming convention, plus manual kubectl-compatible config commands and the `--config`/`$KUBECONFIG`/`~/.kube/config` load-and-merge order.
- [docs/en/ui/cli_tools/ac/upgrading-clusters.md](docs/en/ui/cli_tools/ac/upgrading-clusters.md): Administrator workflow for cluster upgrades using `ac adm release import-manifest --version <X.Y.Z> [--wait --timeout=Nm]` to create a ProductManifest, then `ac adm upgrade [--cluster=<name>]` to inspect current/desired versions and availableUpdates, followed by `ac adm upgrade --to-latest` or `--to=<version> [--allow-explicit-upgrade]` to request an upgrade. `ac adm upgrade status` exposes preflight states (Passed/Retry/Failed) and stage phases (Pending/Running/Finished), with Ready/Reconciling/Degraded condition guidance.
- [docs/en/ui/cli_tools/violet.mdx](docs/en/ui/cli_tools/violet.mdx): Brief landing page for the `violet` CLI used to upload plugin packages downloaded from the Custom Portal Marketplace. Cross-references the detailed Upload Packages procedure.
- [docs/en/ui/new_web_console/install.mdx](docs/en/ui/new_web_console/install.mdx): Installs the Preview Next-Gen Console framework using two cluster plugins delivered via Marketplace and `violet`: 'Alauda Container Platform Web Console Base' (global cluster only, restricted by `is-global: true` cluster affinity, hosts the frontend and aggregation backend) and 'Alauda Container Platform Web Console Collector' (every cluster whose plugin UIs should appear). Documents the four-step download/upload/install flow, the Preview Next-Gen Console entry served at `/console-acp-new/` from the Container Platform and Administrator views, and uninstall guidance.
- [docs/en/ui/web_console/access.mdx](docs/en/ui/web_console/access.mdx): Onboarding guide for accessing the ACP web console: required browsers (Chrome, Firefox, Safari, Edge), the `https://<console-route-hostname>` URL pattern, login via Local/LDAP/Active Directory/OIDC/OAuth identity providers, and the navigation model with the Portal page, view switcher in the upper-left, main navigation menu on the left, and user and help menus in the upper-right.
- [docs/en/ui/web_console/customization.mdx](docs/en/ui/web_console/customization.mdx): Configures the platform's appearance and Portal experience. Covers per-user Theme/Language settings, and admin-only customizations via Platform Management > System Settings: Login Page logo and background (recommended 200x60 and 1920x1080), Portal main/sub titles and top/bottom images, Logo platform name and favicon, view renames via Platform Parameters > Product Config, integrating external products into Portal cards/view switcher, and a link to Left Navigation customization.
- [docs/en/ui/web_console/customize-left-navigation.mdx](docs/en/ui/web_console/customize-left-navigation.mdx): Customizes the Administrator and Projects view left-navigation menus by editing `custom-navconfig-platform` and `custom-navconfig-project` ConfigMaps in the `cpaas-system` namespace of the global cluster. Supports hiding built-in items (`hidden: true`), renaming labels, swapping icons, and adding top-level custom items (label, iconData base64, href). Includes the full reference YAML for the default navigation structure (cluster_management, network_management, storage_management, security_setting, toolchain_management, platform_setting, plus project_overview/detail/member, toolchain_management, pipeline_management for the Projects view) with gate feature flags.
- [docs/en/ui/web_console/overview.mdx](docs/en/ui/web_console/overview.mdx): Overview of the ACP web console, listing the Chrome/Firefox browser compatibility matrix per ACP version (4.0/4.1/4.2), explicitly dropping IE 11+, and introducing the three primary views: Container Platform view (Developer-oriented for workloads, storage, routes), Platform Management view (Administrator-oriented for clusters, Operators, platform-wide settings), and Project Management view (project quotas, members, role bindings), each with summary Overview pages.

## upgrade

- [docs/en/upgrade/overview.mdx](docs/en/upgrade/overview.mdx): Overview of the ACP 4.3 CVO (Cluster Version Operator)-based cluster upgrade workflow. Introduces the two-step Web Console RPCH review flow, the rule that the global tier must reach a Distribution Version before workload clusters can be upgraded to it (including standby+primary in global DR), and key concepts: ClusterVersionShadow (`cvsh`), preflight checks, availableUpdates, `upgrade.sh`, and primary/standby global cluster roles. Entry points are the Web Console, ACP CLI (`ac adm upgrade`), or patching `ClusterVersionShadow.spec.desiredUpdate`.
- [docs/en/upgrade/pre-upgrade.mdx](docs/en/upgrade/pre-upgrade.mdx): Pre-upgrade preparation for ACP 4.3 covering supported upgrade paths from 4.0/4.1/4.2, the 120 GB free-space requirement on `/cpaas/minio` of global control-plane nodes, the Kubernetes compatible-version prerequisite for workload clusters, downloading the Core Package and `violet` CLI from the Customer Portal, exporting and re-importing the extension list (`violet list --output-file apps.yaml`), and required `violet push` uploads of the TopoLVM plugin (for 4.0->4.3) and the new Log Essentials plugin (v4.2+) before the upgrade.
- [docs/en/upgrade/upgrade_global_cluster.mdx](docs/en/upgrade/upgrade_global_cluster.mdx): Detailed upgrade procedure for the traditional-OS global cluster: run `bash upgrade.sh` to prepare product/CVO images and plugin artifacts (with --registry, --skip-sync-image, --only-sync-image flags), execute preflight via `upgrade.sh --preflight` (checks like ResourcePatchUpgradeable, ClusterVersionUpgradeable, KubernetesVersionSupported, ControlPlaneStaticPodsPresent, PlatformLicense), patch ClusterVersionShadow `spec.desiredUpdate.version` or use the Web Console two-step RPCH/confirmation flow or `ac adm upgrade --cluster=global --to=...`, and observe `cvsh.status` conditions (PreflightReady, Ready, Reconciling, Stalled). Also provides the full Global DR procedure (verify standby/primary, uninstall etcd Synchronizer from standby, upgrade standby first, then primary, reinstall etcd-sync with `etcd-sync-active-cluster-token` Secret and verify sync via `etcd-sync-monitor` /check endpoint).
- [docs/en/upgrade/upgrade_workload_cluster.mdx](docs/en/upgrade/upgrade_workload_cluster.mdx): Procedure for upgrading workload clusters on traditional OS once the global tier has reached the target ACP Distribution Version (and in global DR both global clusters have reached it). Run `bash upgrade.sh --cluster=<cluster> --preflight`, then submit via the Web Console two-step RPCH flow (target version is fixed to the global version), or via `ac adm upgrade --cluster=<cluster> --to-latest` or `--to=4.3.0`. Observe progress with `kubectl get cvsh <cluster> -n cpaas-system` and `ac adm upgrade status`, with jsonpath helpers for conditions, preflight checks, and history.

## virtualization

- [docs/en/virtualization/virtualization/backup_recovery/functions/snapshot.mdx](docs/en/virtualization/virtualization/backup_recovery/functions/snapshot.mdx): Creates, rolls back, and deletes offline KubeVirt virtual machine snapshots via the Container Platform > Virtualization > Virtual Machines page. Requires the Volume Snapshot plugin and a snapshot-capable storage class such as CephFS; the VM must be stopped first. Rollback restores VM settings and supported disks to the snapshot state and is irreversible; TopoLVM-backed disks require `reclaimPolicy: Retain`. Includes guidance for the Snapshot status, rollback record check, and deletion ordering for TopoLVM copy-on-snapshot disks.
- [docs/en/virtualization/virtualization/backup_recovery/functions/velero.mdx](docs/en/virtualization/virtualization/backup_recovery/functions/velero.mdx): Uses Velero with the KubeVirt plugin to back up and restore virtual machines. Walks through editing the velero Deployment to enable `--features=EnableCSI` and adding the `kubevirt-velero-plugin:v0.7.0` initContainer, patching `node-agent` to mount /var/lib/kubelet/pods and /var/lib/kubelet/plugins with privileged=true, creating a Backup CR with `snapshotMoveData: true` against S3-backed BackupStorageLocation, tracking dataupload/datadownload progress, restoring via a Restore CR, plus cross-cluster restore, namespaceMapping, and storage-class remapping through a `change-storage-class-config` plugin ConfigMap.
- [docs/en/virtualization/virtualization/backup_recovery/intro.mdx](docs/en/virtualization/virtualization/backup_recovery/intro.mdx): Introduces ACP Virtualization (KubeVirt-based) VM snapshot capabilities for disaster recovery and rollback against data loss, accidental file deletion, or ransomware. Notes that snapshots require stopping the VM first and that the disk PVCs must use a multi-node shared access mode.
- [docs/en/virtualization/virtualization/image/functions/add_image.mdx](docs/en/virtualization/virtualization/image/functions/add_image.mdx): Adds X86_64 or alpha-stage ARM64 virtual machine images for KubeVirt VMs via Administrator > Virtualization Management > Virtual Machine Images. Supports CentOS/Ubuntu/RedHat/Debian/TLinux/Other Linux/Windows (Alpha) qcow2 or raw KVM images sourced from a container Image Repository, an HTTP URL, or S3 Object Storage. Configures authentication credentials (Username/Password) when needed and assigns image use to All Projects, a specific Project, or none.
- [docs/en/virtualization/virtualization/image/functions/update_delete_image.mdx](docs/en/virtualization/virtualization/image/functions/update_delete_image.mdx): Short procedure for updating or deleting an existing virtual machine image entry from Administrator > Virtualization Management > Virtual Machine Images via the row's ⋮ menu.
- [docs/en/virtualization/virtualization/image/functions/update_delete_secert.mdx](docs/en/virtualization/virtualization/image/functions/update_delete_secert.mdx): Brief UI walkthrough for updating or deleting Image Credentials under Virtualization Management > Virtual Machine Images in the Administrator view, with the action triggered from the row's overflow menu.
- [docs/en/virtualization/virtualization/image/how_to/vm_image_export.mdx](docs/en/virtualization/virtualization/image/how_to/vm_image_export.mdx): Procedure to export a VM's system disk by stopping the VM, creating a VirtualMachineExport (export.kubevirt.io/v1alpha1) resource with a TTL, retrieving the export token, and downloading disk.img.gz through the virt-export Pod. The downloaded image is then uploaded to S3-compatible object storage using the mc (MinIO client) and registered back on the platform via Add Virtual Machine Image.
- [docs/en/virtualization/virtualization/image/how_to/vm_iso_linux.mdx](docs/en/virtualization/virtualization/image/how_to/vm_iso_linux.mdx): Walkthrough for building a Linux (Ubuntu) VM image from an ISO using KubeVirt and CDI: a CDI upload-type DataVolume receives the ISO via kubectl port-forward to cdi-uploadproxy, a VM is created with the ISO as a SATA CDROM (bootOrder 1) and a blank rootfs DataVolume, the OS is installed, then cloud-init, qemu-guest-agent, sshd, and growpart/xfs_growfs are configured before exporting the disk as a reusable image.
- [docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx](docs/en/virtualization/virtualization/image/how_to/vm_iso_windows.mdx): Walkthrough for building a Windows VM image with KubeVirt using two CDI upload DataVolumes (the Windows ISO plus virtio-win drivers) attached as SATA CDROMs. Covers the required USB tablet input for VNC mouse alignment, Windows installation, virtio-win-guest-tools installation, image export, and exposing RDP (port 3389) through a NodePort internal route, plus a sample VirtualMachineInstance YAML enabling Hyper-V features, EFI Secure Boot, and TPM for Windows 11.
- [docs/en/virtualization/virtualization/image/intro.mdx](docs/en/virtualization/virtualization/image/intro.mdx): Introduces ACP Virtualization with KubeVirt's VM image abstraction as a CRD with a UI to import remote images. Highlights support for major Linux and Windows OSes, x86_64 and ARM64 architectures, multiple sources (image registries, file servers, S3-compatible object storage), and QCOW2/RAW image formats.
- [docs/en/virtualization/virtualization/image/permissions.mdx](docs/en/virtualization/virtualization/image/permissions.mdx): RBAC reference rendered via the K8sPermissionTable component for the `acp-virtualmachineimagetemplates` function group, listing platform permissions related to managing virtual machine image templates.
- [docs/en/virtualization/virtualization/installation.mdx](docs/en/virtualization/virtualization/installation.mdx): Administrator installation guide for ACP Virtualization with KubeVirt: enabling per-node virtualization on physical-machine workers, installing the operator from OperatorHub into the `kubevirt` namespace, creating the single-per-cluster HyperConverged instance (configuring `spec.storageImport.insecureRegistries`), and optionally setting the VM CPU overcommit ratio (recommended 2-4). Includes storage guidance comparing TopoLVM versus Ceph and a 20% namespace memory headroom recommendation.
- [docs/en/virtualization/virtualization/network/functions/vm_network.mdx](docs/en/virtualization/virtualization/network/functions/vm_network.mdx): Cross-reference page linking to detailed procedures for configuring a VM's IP, exposing the VM directly via Kube-OVN Underlay networking, and adding a Service to a VM.
- [docs/en/virtualization/virtualization/network/how_to/managedtap.mdx](docs/en/virtualization/virtualization/network/how_to/managedtap.mdx): Explains using the ManagedTap network-binding plugin together with Kube-OVN (Underlay subnet) to give VMs IPv6 support via the CNI's DHCP server. Procedure edits the Subnet CR to set `enableDHCP`, `enableIPv6RA`, and `u2oInterconnection`, then creates a VM in Network Binding mode and configures the guest interface (e.g. ifcfg-enp1s0 with IPV6INIT/DHCPV6C) and an optional `ip r r default via <gateway>` route.
- [docs/en/virtualization/virtualization/network/how_to/vm_multi_nic.mdx](docs/en/virtualization/virtualization/network/how_to/vm_multi_nic.mdx): Multi-NIC VM configuration using Multus with Kube-OVN: create a NetworkAttachmentDefinition (provider suffix `.ovn`) and matching Kube-OVN Subnet, then add an extra interface and `multus.networkName` entry under `spec.template.spec` in the VM YAML. Also covers hotplugging interfaces on running VMs (virtio bridge/SR-IOV bindings supported for plug, bridge only for unplug via `state: absent`).
- [docs/en/virtualization/virtualization/network/how_to/vm_networkpolicy.mdx](docs/en/virtualization/virtualization/network/how_to/vm_networkpolicy.mdx): Uses Kubernetes Network Policies to control ingress/egress traffic for KubeVirt VM Pods. Walks through creating ingress/egress rules with TCP/UDP whitelists (including ports 53/1053 to keep DNS working) and demonstrates the `Exclude Remote` option by blocking a single www.example.com IP (e.g. 93.184.215.14/32) after initially allowing 0.0.0.0/0.
- [docs/en/virtualization/virtualization/network/how_to/vm_sriov.mdx](docs/en/virtualization/virtualization/network/how_to/vm_sriov.mdx): End-to-end SR-IOV setup for KubeVirt VMs: enabling SR-IOV/IOMMU in BIOS and GRUB (intel_iommu=on iommu=pt), loading vfio-pci, creating VFs via `sriov_numvfs`, binding VFs with the dpdk-devbind.py script, deploying the Multus CNI plugin and the sriov-network-operator AppRelease, labeling nodes, registering the NIC vendor/device/VF IDs in the `supported-nic-ids` ConfigMap, and verifying VM eth1 obtains a DHCP address. Notes that glibc >= 2.34 is required (Kylin V10 / CentOS 7.x unsupported).
- [docs/en/virtualization/virtualization/network/intro.mdx](docs/en/virtualization/virtualization/network/intro.mdx): Positions ACP Virtualization with KubeVirt's networking as integrated with Kube-OVN, highlighting full IPv6 support, static IP retention across VM restarts, and multiple network modes (container networks, SR-IOV) for diverse VM workloads.
- [docs/en/virtualization/virtualization/overview/intro.mdx](docs/en/virtualization/virtualization/overview/intro.mdx): Overview of the platform's KubeVirt-based virtualization solution for running container-orchestrated VMs (VirtualMachineInstance) alongside containers. Describes use cases for incremental migration off legacy VMs, key products (Virtual Machine, Virtual Disk, VM Snapshots, VM Images, Key Pairs), and the constraint that virtualization requires physical-machine clusters with KubeVirt enabled.
- [docs/en/virtualization/virtualization/storage/functions/virtual_disk.mdx](docs/en/virtualization/virtualization/storage/functions/virtual_disk.mdx): UI workflow for managing virtual data disks: creating a disk (selecting volume mode File System vs Block Device, storage class, `Delete with VM`, and optional mount target), mounting an existing disk online to a running VM, expanding system or data disks, unmounting (VM must be stopped), and deleting unmounted data disks (system disks cannot be deleted).
- [docs/en/virtualization/virtualization/storage/intro.mdx](docs/en/virtualization/virtualization/storage/intro.mdx): Introduces KubeVirt VM storage that uses PersistentVolumeClaims for disk data, CSI for storage backends, and CDI to initialize disks. Highlights UI-driven disk operations and the option to auto-delete VM disks when the VM is terminated.
- [docs/en/virtualization/virtualization/virtual_machine/functions/batch_actions.mdx](docs/en/virtualization/virtualization/virtual_machine/functions/batch_actions.mdx): UI procedure for single or batch Start, Stop, Restart, and Delete actions on virtual machines. Lists which VM states each action is allowed in (e.g., Restart only from Running, Stop available from Preparing/Starting/Running/Suspended/Unknown/Exception) and warns that forced restart/stop can lose unwritten data.
- [docs/en/virtualization/virtualization/virtual_machine/functions/create_virtual_machine.mdx](docs/en/virtualization/virtualization/virtual_machine/functions/create_virtual_machine.mdx): Form- and YAML-based workflow for creating a single VirtualMachineInstance or a virtualMachinePool group. Covers basic info (tags/annotations), specifications including optional Physical GPU (Alpha) passthrough, image selection (matching cluster CPU architecture), storage (root vs data disks, volume mode, storage class, Delete with VM), networking (DHCP vs static IP, Bridged vs NAT with open ports, auxiliary NICs including SR-IOV constraints), SSH key vs password initialization, and advanced options like health checks and node affinity (Preferred/Required).
- [docs/en/virtualization/virtualization/virtual_machine/functions/virtual_management.mdx](docs/en/virtualization/virtualization/virtual_machine/functions/virtual_management.mdx): Day-2 VM management operations from the Virtualization > Virtual Machines page: Reset Password (root user), Update Key (SSH key pair with restart), Update Specifications, Live Migration, Update NAT Network Configuration (default SSH port 22, add more), Update Tags/Annotations, Add Service for internal routes, Reinstall Operating System (destroys system disk and snapshots), and Configure IP (DHCP or fixed binding requiring restart).
- [docs/en/virtualization/virtualization/virtual_machine/functions/virtual_secret.mdx](docs/en/virtualization/virtualization/virtual_machine/functions/virtual_secret.mdx): UI walkthrough under Virtualization > Key Pairs for managing SSH key pairs: creating by manual import or system-generated (with one-time private-key download since the platform does not store private keys), updating an existing key pair, and deleting one.
- [docs/en/virtualization/virtualization/virtual_machine/functions/vm_monitor.mdx](docs/en/virtualization/virtualization/virtual_machine/functions/vm_monitor.mdx): Describes built-in monitoring of CPU, memory, storage, and network metrics on the VM details Monitoring tab, plus the Alerts tab for creating Metric or Event alert policies with thresholds and durations. Defines alert levels Hint, Warning, Serious, and Disaster and notes that notification policies (email, SMS) are bound by the administrator.
- [docs/en/virtualization/virtualization/virtual_machine/functions/vm_search.mdx](docs/en/virtualization/virtualization/virtual_machine/functions/vm_search.mdx): Administrator workflow under Virtualization Management > Virtual Machines for listing VMs by cluster and quickly searching by name, IP, or creator. Clicking a VM jumps to its details page for scaling and troubleshooting actions.
- [docs/en/virtualization/virtualization/virtual_machine/functions/vnc.mdx](docs/en/virtualization/virtualization/virtual_machine/functions/vnc.mdx): Procedure for opening the in-browser VNC Web Console for a VM from the Virtual Machines list as an emergency access path; supports keyboard command injection and clipboard copy/paste for commands and parameters.
- [docs/en/virtualization/virtualization/virtual_machine/how_to/create-template.mdx](docs/en/virtualization/virtualization/virtual_machine/how_to/create-template.mdx): Converts an existing VM into a reusable template by installing cloud-init and qemu-guest-agent, running `cloud-init clean` and shutdown, taking a snapshot via the Web Console, and creating a CDI `DataSource` (cdi.kubevirt.io/v1beta1) in `kube-public` that references the resulting volume snapshot. Documents the supporting labels (`virtualization.cpaas.io/image-os-arch`, `image-os-type`, `storage-class`, `access-mode`, `size`, `volume-mode`) used to set default disk parameters when creating new VMs from the template.
- [docs/en/virtualization/virtualization/virtual_machine/how_to/migrate_storage_classes.mdx](docs/en/virtualization/virtualization/virtual_machine/how_to/migrate_storage_classes.mdx): Two paths for moving a VM disk to a different StorageClass: cold migration that stops the VM and uses a CDI DataVolume to clone the source PVC into the new StorageClass, then patches `spec.dataVolumeTemplates` and `spec.template.spec.volumes` to point at the destination; and live storage migration using `VirtualMachineStorageMigrationPlan` and `VirtualMachineStorageMigration` from migrations.kubevirt.io/v1alpha1 when the VMI reports both `LiveMigratable=True` and `StorageLiveMigratable=True`. Includes StorageProfile lookups, the `kubevirt.io/allow-pod-bridge-network-live-migration` annotation, and troubleshooting for stuck plans, scheduling failures, slow DataVolume population, and finalizer cleanup.
- [docs/en/virtualization/virtualization/virtual_machine/how_to/vm_availability.mdx](docs/en/virtualization/virtualization/virtual_machine/how_to/vm_availability.mdx): Sets up VM-level high availability using the medik8s Self Node Remediation (SNR) and Node Health Check (NHC) Operators installed into the `workload-availability` namespace. Documents the `SelfNodeRemediationConfig` CR fields (safeTimeToAssumeNodeRebootedSeconds, watchdogFilePath, isSoftwareRebootEnabled, API/peer timeouts, hostPort 30001), the three remediation strategies (Automatic, ResourceDeletion, OutOfServiceTaint), and a `NodeHealthCheck` example with `minHealthy: 51%` and Ready-condition unhealthy triggers.
- [docs/en/virtualization/virtualization/virtual_machine/how_to/vm_clone.mdx](docs/en/virtualization/virtualization/virtual_machine/how_to/vm_clone.mdx): Clones a VM using KubeVirt's `VirtualMachineClone` (clone.kubevirt.io/v1beta1), which requires snapshot-capable storage. Shows the minimal source/target manifest, a detailed example with labelFilters/annotationFilters/template filters, newMacAddresses, newSMBiosSerial, and JSON patches, plus an explanation of phases (SnapshotInProgress, CreatingTargetVM, RestoreInProgress, Succeeded). Includes a post-clone fix to relabel the new DataVolume's `vm.cpaas.io/used-by` so the platform UI correctly associates the cloned disk with the target VM.
- [docs/en/virtualization/virtualization/virtual_machine/how_to/vm_gpust.mdx](docs/en/virtualization/virtualization/virtual_machine/how_to/vm_gpust.mdx): Prepares the cluster for KubeVirt physical GPU passthrough using the NVIDIA gpu-operator chart (deployed as an AppRelease in `gpu-system` with `sandboxWorkloads` and `vm-passthrough` enabled) plus kubevirt-gpu-device-plugin. Walks through enabling IOMMU via grub, uninstalling NVIDIA drivers, locating pciDeviceSelector via `lspci -nn`, enabling the `disableMDevConfiguration` feature gate on the HyperConverged CR, and patching `spec.permittedHostDevices.pciHostDevices` (with uppercase device IDs) so the Physical GPU (Alpha) parameter becomes selectable on Create Virtual Machine. ARM64 is not supported.
- [docs/en/virtualization/virtualization/virtual_machine/how_to/vm_precopy.mdx](docs/en/virtualization/virtualization/virtual_machine/how_to/vm_precopy.mdx): Live (hot) VM migration using KubeVirt's default pre-copy memory migration mode. Explains the four-phase ProCopy flow (initial copy, iterative dirty-page copy, brief stop-and-copy with CPU/device state, resume on target) and prerequisites including matched hardware (especially CPU model), Kube-OVN Underlay networking, Block volume mode on CephRBD, Bridge network mode, and adding the `kubevirt.io/allow-pod-bridge-network-live-migration: true` annotation. Migration is triggered via Actions > Hot Migration on a Running VM.
- [docs/en/virtualization/virtualization/virtual_machine/how_to/vm_repair.mdx](docs/en/virtualization/virtualization/virtual_machine/how_to/vm_repair.mdx): Rescue procedure for a VM whose rootfs is broken (e.g., bad fstab edit, fsck needed): stop the VM, then patch its YAML to add a containerDisk pointing to a known-good OS image (e.g., `192.168.1.1:11443/3rdparty/vmdisks/centos:7.9`) with `bootOrder: 1` higher priority than the existing rootfs, start the VM, mount and repair the original rootfs from rescue, then revert the YAML so the VM boots normally again.
- [docs/en/virtualization/virtualization/virtual_machine/how_to/vm_usb_passthrough.mdx](docs/en/virtualization/virtualization/virtual_machine/how_to/vm_usb_passthrough.mdx): Passes host USB devices into a KubeVirt VM by editing the HyperConverged CR's `spec.permittedHostDevices.usbHostDevices` with a `resourceName` and vendor/product selectors (obtained via `lsusb`), then referencing that resourceName from the VM's `spec.domain.devices.hostDevices.deviceName`. Includes an example with a single Realtek Wi-Fi adapter (0bda:8812 -> kubevirt.io/storage) and a multi-device pattern grouping keyboard/mouse/smart-card devices under one resourceName. Requires platform v3.18+ and a stopped VM for the edit.
- [docs/en/virtualization/virtualization/virtual_machine/intro.mdx](docs/en/virtualization/virtualization/virtual_machine/intro.mdx): Short introduction noting that ACP Virtualization With KubeVirt builds on KubeVirt's VirtualMachine and VirtualMachineInstance CRDs and layers a Web Console on top so users can manage VMs without crafting raw CRD YAML.
- [docs/en/virtualization/virtualization/virtual_machine/trouble_shooting/vm_migration.mdx](docs/en/virtualization/virtualization/virtual_machine/trouble_shooting/vm_migration.mdx): Troubleshooting playbook for VM Pods that get stuck on a host being shut down or crashed, because KubeVirt cannot tell a crash apart from a transient network issue. For graceful shutdowns, drain `kubevirt.io=virt-launcher` Pods with `kubectl drain --pod-selector=kubevirt.io=virt-launcher` and uncordon after reboot. For abnormal crashes, force-delete the node's virt-launcher Pods, remove its VolumeAttachments, and (if present) force-delete virt-api / virt-controller Pods scheduled there so VMIs can reschedule onto healthy nodes.
- [docs/en/virtualization/virtualization/virtual_machine/trouble_shooting/vm_precopy.mdx](docs/en/virtualization/virtualization/virtual_machine/trouble_shooting/vm_precopy.mdx): Quick reference table for diagnosing hot (live) migration failures. Covers the `cannot migrate VMI which does not use masquerade, bridge with <annotation>...` error (fix by using Kube-OVN and adding `kubevirt.io/allow-pod-bridge-network-live-migration: true` to both `metadata.annotations` and `spec.template.metadata.annotations`) and the family of PVC sharing errors (`PVC ... is not shared`, `Backend storage PVC is not RWX`, `non-shared HostDisk`) requiring a recreate with an RWX storage class such as CephRBD block storage.