diff --git a/docs/en/configure/backup/application/index.mdx b/docs/en/configure/backup/application/index.mdx index 907a94406..5e6a9f3f5 100644 --- a/docs/en/configure/backup/application/index.mdx +++ b/docs/en/configure/backup/application/index.mdx @@ -5,20 +5,4 @@ title: Application Backup and Restore # Application Backup and Restore -As a cluster administrator, you can back up and restore applications running on Alauda Container Platform by using Velero. - -For an overview of application backup components and installation instructions, see [Application backup and restore](../overview.mdx#application-backup-and-restore). - -## Backup - -- [Configure backup repository](./repository.mdx) -- [Create application backups](./backup-app.mdx) - -## Restore - -- [Restore applications](./restore-app.mdx) -- [Image registry replacement](./restore-imagesync.mdx) - -## Hooks - -- [Configure hooks](./hooks.mdx) + diff --git a/docs/en/configure/backup/application/restore-app.mdx b/docs/en/configure/backup/application/restore-app.mdx index 56441ab93..9fbf68b9f 100644 --- a/docs/en/configure/backup/application/restore-app.mdx +++ b/docs/en/configure/backup/application/restore-app.mdx @@ -44,7 +44,7 @@ You can quickly restore the application to the target namespace by performing an | **Recovery Target Configuration** | **Namespaces**: The namespace where data recovery is performed and the source namespace of the backup data. The optional range is the namespace set in the backup policy. The system restores backup data to the same namespace based on your selection. **Tip**: To restore to other namespaces in the cluster, configure **Advanced Recovery Target Settings**. | | **Advanced Recovery Target Settings** | Restore backup data originally scheduled for the source namespace to any namespace in the cluster (existing or newly created). **Source Namespace**: The selected namespace. **Target Namespace**: The namespace where data recovery is performed; either an existing namespace or a new one created by entering a non-existent name. **Tip**: If **Backup Kubernetes Resources and Persistent Volume Claims** was selected as the application backup resource type, ensure that the target cluster **StorageClass** name matches the source. If not, configure the source and target storage class names in the advanced options; the platform stores data using the new storage class. | -6. Click **YAML** in the upper-right corner to switch to YAML editing mode. Refer to [Configuring Hooks](./hooks.mdx) to configure commands that run during recovery. +6. Click **YAML** in the upper-right corner to switch to YAML editing mode. To configure commands that run during recovery, see [Configuring Hooks](./hooks.mdx). **Caution**: By default, the backup file is compared with resources in the target namespace. Only data that exists in the backup file but is missing in the namespace is restored. Resources with the same name or incremental resources (existing in the namespace but missing in the backup file) are not overwritten. diff --git a/docs/en/configure/backup/etcd.mdx b/docs/en/configure/backup/etcd.mdx index c10e8bd8c..81f594c52 100644 --- a/docs/en/configure/backup/etcd.mdx +++ b/docs/en/configure/backup/etcd.mdx @@ -3,16 +3,17 @@ title: "etcd Backup and Restore" weight: 10 --- +# etcd Backup and Restore The etcd service on the cluster is a distributed key-value store responsible for storing cluster configuration information. etcd is deployed on all control plane nodes of the cluster. -After installing the Alauda Container Platform Cluster Enhancer plugin, an EtcdBackupConfiguration resource is automatically created for the cluster configuration. The EtcdBackupConfiguration contains information about backup data sources (control nodes, backup paths), backup data storage locations, backup methods, and more. Each backup execution based on the policy generates a new backup record, enabling you to back up cluster configurations on-demand or automatically on a periodic basis. +After installing the Cluster Enhancer plugin, an `EtcdBackupConfiguration` resource is automatically created for the cluster configuration. The `EtcdBackupConfiguration` contains backup data sources, control plane node paths, backup data storage locations, and backup methods. Each backup execution based on the policy generates a new backup record, enabling on-demand and scheduled cluster-configuration backups. ## Prerequisites To enable etcd backup: -1. Download **Alauda Container Platform Cluster Enhancer** from the Customer Portal. +1. Download ** Cluster Enhancer** from the Customer Portal. 2. [Upload the package](/extend/upload_package.mdx) to the platform. 3. [Install the plugin](/extend/cluster_plugin.mdx) on your cluster. @@ -20,7 +21,7 @@ After installation, an EtcdBackupConfiguration resource is automatically created ## How it works -- etcd backup is provided by **Alauda Container Platform Cluster Enhancer** +- etcd backup is provided by ** Cluster Enhancer**. - Supports both local storage and S3-compatible object storage. By default, backups are stored locally in `/cpaas`. Configuring S3 storage creates an additional copy in the S3 bucket; local backups continue to be generated. - For clusters running on Immutable OS, S3 storage is **required** (local storage is not supported) @@ -83,7 +84,7 @@ To enable S3 storage for etcd backups, follow these steps: ### Prerequisites -- Alauda Container Platform Cluster Enhancer is installed on the cluster. +- Cluster Enhancer is installed on the cluster. ### Step 1: Create S3 Secret @@ -136,8 +137,8 @@ After the backup completes, verify that backup files exist in your S3 bucket. > **Warning:** > -> * This operation performs a disastrous recovery of the etcd cluster. It will overwrite the existing data. Ensure you have a valid backup snapshot before proceeding. -> * This procedure entails significant risks. If you are unsure about the operation, please contact technical support. +> * This operation performs a destructive recovery of the etcd cluster. It will overwrite the existing data. Ensure you have a valid backup snapshot before proceeding. +> * This procedure entails significant risks. If you are unsure about the operation, contact technical support. > * During the recovery process, the Kubernetes API Server will be unavailable. ### Prerequisites @@ -145,7 +146,7 @@ After the backup completes, verify that backup files exist in your S3 bucket. - The Kubernetes cluster is deployed using hostnames (`kubectl get node` shows hostnames as node names). - An etcd backup snapshot is available. - The cluster is malfunctioning due to the failure of etcd nodes (e.g., more than half of the control plane nodes are down). -- This recovery procedure is specifically designed for a **3-node control plane** cluster. If your cluster has 5 or more control plane nodes, please contact technical support for assistance. +- This recovery procedure is specifically designed for a **3-node control plane** cluster. If your cluster has 5 or more control plane nodes, contact technical support for assistance. ### Step 1: Backup Original Data and Modify etcd Configuration @@ -184,7 +185,7 @@ Copy the latest etcd backup snapshot to the `/tmp` directory on the **first cont Execute the following script on the **first control plane node** to restore the snapshot. -> **Note:** The following script assumes a 3-node control plane cluster. If your cluster has 5 or more nodes, please contact technical support. +> **Note:** The following script assumes a 3-node control plane cluster. If your cluster has 5 or more nodes, contact technical support. ```bash #!/usr/bin/env bash diff --git a/docs/en/configure/backup/index.mdx b/docs/en/configure/backup/index.mdx index 682036042..8d032f1c3 100644 --- a/docs/en/configure/backup/index.mdx +++ b/docs/en/configure/backup/index.mdx @@ -1,10 +1,9 @@ --- weight: 55 -title: Backup and Recovery +title: Backup and Restore --- -# Backup and Recovery +# Backup and Restore - diff --git a/docs/en/configure/backup/overview.mdx b/docs/en/configure/backup/overview.mdx index 81af6a9d3..bfe445b04 100644 --- a/docs/en/configure/backup/overview.mdx +++ b/docs/en/configure/backup/overview.mdx @@ -1,11 +1,10 @@ --- weight: 1 -title: Overview --- # Overview -Alauda Container Platform provides two types of backup and restore operations: + provides two types of backup and restore operations: - **Cluster backup and restore**: Backs up and restores control plane data, including etcd, registry, logging, and monitoring data. - **Application backup and restore**: Backs up and restores applications and their persistent volumes based on Velero. @@ -16,13 +15,13 @@ Cluster backup protects the control plane state and platform data. ### etcd backup and restore -etcd is the key-value store for Alauda Container Platform, which persists the state of all resource objects. An etcd backup plays a crucial role in disaster recovery. +etcd is the key-value store for and persists the state of resource objects. etcd backups are required for control-plane state recovery scenarios. For detailed instructions, see [etcd Backup and Restore](./etcd.mdx). ### Registry backup and restore -For registry backup and restore, see [Alauda Container Platform Registry Data Backup and Recovery](/developer/registry/how_to/registry_data_restore.mdx). +For registry backup and restore, see [Registry Data Backup and Recovery](/configure/registry/backup_and_restore.mdx). ### Logging backup and restore @@ -34,20 +33,20 @@ For monitoring backup and restore, see [VictoriaMetrics Backup and Recovery](/ob ## Application backup and restore \{#application-backup-and-restore} -As a cluster administrator, you can back up and restore applications running on Alauda Container Platform by using Velero. +As a cluster administrator, you can back up and restore applications running on by using Velero. ### Architecture Application backup and restore consists of two components: -- **Alauda Container Platform Data Backup Essentials**: Provides the UI and is installed on the global cluster. -- **Alauda Container Platform Data Backup for Velero**: Provides Velero and is installed on workload clusters. +- ** Data Backup Essentials**: Provides the UI and is installed on the global cluster. +- ** Data Backup for Velero**: Provides Velero and is installed on workload clusters. ### Application installation \{#application-installation} To enable application backup and restore: -1. Download **Alauda Container Platform Data Backup Essentials** and **Alauda Container Platform Data Backup for Velero** from the Customer Portal. +1. Download ** Data Backup Essentials** and ** Data Backup for Velero** from the Customer Portal. 2. [Upload the packages](/extend/upload_package.mdx) to the platform. 3. [Install Data Backup Essentials](/extend/cluster_plugin.mdx) on the global cluster. 4. [Install Data Backup for Velero](/extend/cluster_plugin.mdx) on workload clusters. @@ -102,4 +101,3 @@ Common scenarios include: - Maintain consistent network modes to avoid resource restoration issues - If subnets differ, pod IPs will change after recovery - Assess whether image migration is required before restoring data - diff --git a/docs/en/configure/clusters/about-hcp.mdx b/docs/en/configure/clusters/about-hcp.mdx deleted file mode 100644 index ed3d26bc8..000000000 --- a/docs/en/configure/clusters/about-hcp.mdx +++ /dev/null @@ -1,10 +0,0 @@ ---- -weight: 40 -title: Hosted Control Plane ---- - -# About Hosted Control Plane - -**Hosted Control Plane (HCP)** is a lightweight multi-cluster management model that separates the control plane from worker nodes. Each cluster's control plane is containerized and hosted within a management cluster, reducing resource consumption, accelerating cluster creation and upgrades, and improving scalability for multi-cluster operations. - - diff --git a/docs/en/configure/clusters/how-to/access-cluster-with-kubeconfig.mdx b/docs/en/configure/clusters/how-to/access-cluster-with-kubeconfig.mdx index 4ced9bb7b..5a4440fd1 100644 --- a/docs/en/configure/clusters/how-to/access-cluster-with-kubeconfig.mdx +++ b/docs/en/configure/clusters/how-to/access-cluster-with-kubeconfig.mdx @@ -5,8 +5,8 @@ author: dev@alauda.io category: howto queries: - access cluster with KubeConfig - - download KubeConfig from acp - - create KubeConfig with acp api token + - download KubeConfig from platform + - create KubeConfig with platform api token - use ac with KubeConfig --- @@ -14,18 +14,18 @@ queries: ## Introduction -This topic explains the currently supported ways to use KubeConfig to access a cluster in . Use it when you need local access from ACP CLI (`ac`), `kubectl`, `helm`, `client-go`, or similar Kubernetes clients. +Use KubeConfig when you need local cluster access from CLI (`ac`), `kubectl`, `helm`, `client-go`, or similar Kubernetes clients. A KubeConfig file is a YAML client configuration file. It is not a Kubernetes resource. A KubeConfig file typically defines the target cluster endpoint, the client credential, and the context that combines them. -ACP CLI (`ac`) uses standard kubeconfig and provides a kubectl-like experience. It is compatible with `kubectl` workflows and also adds ACP-specific context, cluster, and session operations. If you already use `ac login`, ACP CLI can configure kubeconfig and create contexts automatically. This topic focuses on the KubeConfig access paths themselves, including downloaded KubeConfig files and manually assembled token-based KubeConfig files. + CLI (`ac`) uses standard kubeconfig and provides a kubectl-like experience. It is compatible with `kubectl` workflows and also adds platform-specific context, cluster, and session operations. If you already use `ac login`, CLI can configure kubeconfig and create contexts automatically. The access paths below include downloaded KubeConfig files and manually assembled token-based KubeConfig files. ## Scenarios -This topic applies to the following scenarios: +Use these access paths for the following scenarios: - A cluster administrator needs a ready-to-use KubeConfig for cluster administration, troubleshooting, or inspection. -- A developer or project user needs a KubeConfig that matches their own ACP identity and RBAC permissions. +- A developer or project user needs a KubeConfig that matches their own identity and RBAC permissions. - A pipeline or connector needs an independent credential that is separate from a personal day-to-day account. ## Choose the Access Path @@ -34,11 +34,11 @@ Use the following table to choose the appropriate access path: | Access path | Credential source | Effective permissions | Lifetime control | Best fit | | :--- | :--- | :--- | :--- | :--- | -| Platform-downloaded KubeConfig | Credential embedded in the KubeConfig file downloaded from ACP | Determined by the credential embedded in the downloaded file | Controlled by the current platform behavior for the downloaded file | Cluster administrators and template preparation | -| Token-based KubeConfig | ACP API token created for a user account | Limited to the identity and RBAC scope of the token owner | Controlled by the token expiration or revocation state | Developers, project users, and automation accounts | +| Platform-downloaded KubeConfig | Credential embedded in the KubeConfig file downloaded from the platform | Determined by the credential embedded in the downloaded file | Controlled by the current platform behavior for the downloaded file | Cluster administrators and template preparation | +| Token-based KubeConfig | API token created for a user account | Limited to the identity and RBAC scope of the token owner | Controlled by the token expiration or revocation state | Developers, project users, and automation accounts | -Currently, the KubeConfig file downloaded from ACP defaults to a 10-year validity period. ACP does not currently provide CA replacement for this path and does not support user-defined cluster CA for this path. +Currently, the KubeConfig file downloaded from defaults to a 10-year validity period. does not currently provide CA replacement for this path and does not support user-defined cluster CA for this path. If you need stricter identity isolation or shorter lifecycle control, use a token-based KubeConfig instead of long-term reuse of the downloaded file. @@ -48,8 +48,8 @@ If you need stricter identity isolation or shorter lifecycle control, use a toke Before you begin, ensure the following conditions are met: - You can sign in to and access the target cluster. -- You have ACP CLI (`ac`) or `kubectl` installed on the local machine where you will use the KubeConfig file. -- If you want to use a token-based KubeConfig, you can create an ACP API token from **Profile** > **API Tokens**. For details, see [Introduction](../../../apis/overview/intro.mdx). +- You have CLI (`ac`) or `kubectl` installed on the local machine where you will use the KubeConfig file. +- If you want to use a token-based KubeConfig, you can create a API token from **Profile** > **API Tokens**. For details, see [Introduction](../../../apis/overview/intro.mdx). - If you want to use KubeConfig for a pipeline or connector, prepare a dedicated account and grant only the required permissions before creating its token. ## Procedure @@ -67,7 +67,7 @@ Save the downloaded file to a local path such as `~/.kube/.yaml`. ### Select the KubeConfig file -Point ACP CLI (`ac`) or `kubectl` to the downloaded file: +Point CLI (`ac`) or `kubectl` to the downloaded file: ```shell export KUBECONFIG="$HOME/.kube/.yaml" @@ -76,7 +76,7 @@ kubectl config current-context ac config current-context ``` -If you manage multiple clusters, use `kubectl config use-context ` or `ac config use-context ` to switch to the correct context before running commands. If you use ACP CLI sessions, you can also use `ac config use-cluster ` to switch clusters within the current ACP session. +If you manage multiple clusters, use `kubectl config use-context ` or `ac config use-context ` to switch to the correct context before running commands. If you use CLI sessions, you can also use `ac config use-cluster ` to switch clusters within the current platform session. ### Validate cluster access @@ -94,14 +94,14 @@ If the commands return the expected cluster resources, the KubeConfig file is va Use this downloaded file directly when you need cluster administration. You can also use it as a template for a token-based KubeConfig that works with both `ac` and `kubectl`. -## Build a Token-Based KubeConfig with Your Own ACP API Token +## Build a Token-Based KubeConfig with Your Own API Token -Use this path when you want the KubeConfig permissions to match a specific ACP user or automation account. +Use this path when you want the KubeConfig permissions to match a specific user or automation account. This path does not elevate permissions. The KubeConfig file only carries the connection and authentication settings. The effective access boundary still depends on the token owner and that identity's RBAC assignments. -### Create an ACP API token +### Create a API token Open **Profile** > **API Tokens**, create a new token, and set an expiration time that matches your use case. @@ -122,9 +122,9 @@ https:///kubernetes/ If you do not want to build the cluster section from scratch, download the platform-provided KubeConfig first and reuse its cluster and CA fields as the template. -### Set the ACP API token in the KubeConfig file +### Set the API token in the KubeConfig file -Replace the `users[].user.token` value with the ACP API token that you created for the target user or automation account. +Replace the `users[].user.token` value with the API token that you created for the target user or automation account. The following example shows a token-based KubeConfig: @@ -139,7 +139,7 @@ clusters: users: - name: user: - token: + token: contexts: - name: context: @@ -172,12 +172,12 @@ For pipeline or connector access, use a dedicated account instead of a personal 1. Create a dedicated account for the pipeline or connector. 2. Grant only the required project-level or tenant-level permissions to that account. -3. Create an ACP API token for that account. +3. Create a API token for that account. 4. Build a token-based KubeConfig by using that token. 5. Store the token or KubeConfig file in the secret management system of the automation platform. 6. Rotate the credential by creating a new token, updating the secret, and revoking the old token. -This pattern provides an independent credential for automation, but it is not a native project-level KubeConfig object in ACP. +This pattern provides an independent credential for automation, but it is not a native project-level KubeConfig object in . ## Lifecycle and Revocation @@ -185,8 +185,8 @@ The lifetime behavior depends on which access path you use: | Access path | What controls validity | Current behavior | | :--- | :--- | :--- | -| Platform-downloaded KubeConfig | The current platform behavior for the downloaded file | The downloaded KubeConfig currently defaults to a 10-year validity period. ACP does not currently provide CA replacement or user-defined cluster CA for this path. | -| Token-based KubeConfig | The ACP API token in `users[].user.token` | The KubeConfig remains usable only while the token is valid. When the token expires or is revoked, the KubeConfig also stops working. | +| Platform-downloaded KubeConfig | The current platform behavior for the downloaded file | The downloaded KubeConfig currently defaults to a 10-year validity period. does not currently provide CA replacement or user-defined cluster CA for this path. | +| Token-based KubeConfig | The API token in `users[].user.token` | The KubeConfig remains usable only while the token is valid. When the token expires or is revoked, the KubeConfig also stops working. | If you need a shorter validity period or easier revocation, prefer the token-based path. @@ -197,12 +197,12 @@ After you prepare the KubeConfig file, perform the following checks: 1. Run `kubectl config get-contexts` and confirm that the expected context exists. 2. Run a read-only command such as `kubectl get pods -A` or `kubectl get pods -n ` and confirm that the response matches the intended access scope. 3. For a token-based KubeConfig, run `kubectl auth can-i -n ` and confirm that the result matches the token owner's role. -4. If you use ACP CLI, run `ac config current-context` or `ac namespace` and confirm that the active context matches the intended cluster and namespace. -5. If you use ACP CLI, run `ac get pods -n ` or `ac get nodes` and confirm that the response matches the intended access scope. +4. If you use CLI, run `ac config current-context` or `ac namespace` and confirm that the active context matches the intended cluster and namespace. +5. If you use CLI, run `ac get pods -n ` or `ac get nodes` and confirm that the response matches the intended access scope. ## Next Steps -- For ACP API token management, see [Introduction](../../../apis/overview/intro.mdx). -- For ACP CLI basics, see [Getting Started with ACP CLI](../../../ui/cli_tools/ac/getting-started.md). -- For ACP CLI context and session management, see [Managing CLI Profiles](../../../ui/cli_tools/ac/managing-cli-profiles.md). -- For ACP CLI and kubectl compatibility, see [Usage of ac and kubectl Commands](../../../ui/cli_tools/ac/ac-and-kubectl-usage.md). +- For API token management, see [Introduction](../../../apis/overview/intro.mdx). +- For CLI basics, see [Getting Started with CLI](../../../ui/cli_tools/ac/getting-started.md). +- For CLI context and session management, see [Managing CLI Profiles](../../../ui/cli_tools/ac/managing-cli-profiles.md). +- For CLI and kubectl compatibility, see [Usage of ac and kubectl Commands](../../../ui/cli_tools/ac/ac-and-kubectl-usage.md). diff --git a/docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx b/docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx index 98004458b..ddf23d419 100644 --- a/docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx +++ b/docs/en/configure/clusters/how-to/add_external_addr_for_global_registry.mdx @@ -11,7 +11,7 @@ When the `global` cluster uses the `Platform Built-in` registry, workload cluste In certain scenarios, workload cluster nodes cannot directly access the `global` cluster's registry address - for example, when the `global` cluster is in a private data center while workload clusters are in public clouds or edge environments. -This guide explains how to configure an externally accessible address for the platform's default registry to allow workload clusters to pull images. +Configure an externally accessible address for the platform's default registry so workload clusters can pull images. ## Prerequisites diff --git a/docs/en/configure/clusters/immutable-infra.mdx b/docs/en/configure/clusters/immutable-infra.mdx index 5dda2d9d4..3fb1333b8 100644 --- a/docs/en/configure/clusters/immutable-infra.mdx +++ b/docs/en/configure/clusters/immutable-infra.mdx @@ -14,7 +14,7 @@ Immutable Infrastructure uses an immutable operating system to provision Kuberne supports Immutable Infrastructure on the following providers: Huawei DCS, VMware vSphere, and Huawei Cloud Stack. Bare-metal support is planned. -For the full Immutable Infrastructure documentation set, see . + ## Tasks diff --git a/docs/en/configure/clusters/managed/cloud-init/network/aws-eks-lb.mdx b/docs/en/configure/clusters/managed/cloud-init/network/aws-eks-lb.mdx index b358750d9..61487c4f0 100644 --- a/docs/en/configure/clusters/managed/cloud-init/network/aws-eks-lb.mdx +++ b/docs/en/configure/clusters/managed/cloud-init/network/aws-eks-lb.mdx @@ -32,7 +32,7 @@ When creating load balancers, it's recommended to manually configure service ann 2. Create a load balancer; for detailed creation steps and parameters, see the Load Balancer creation section in [AWS EKS Service Annotation Instructions](/configure/clusters/managed/cloud-init/network/aws-eks.mdx#deploy-aws-load-balancer-controller). - If the above command returns no related Pods, it means the cluster does not have AWS Load Balancer Controller installed. No service annotations are needed; create the load balancer directly. - - If the above command returns related Pods, it means the cluster has AWS Load Balancer Controller installed. When creating a load balancer in the corresponding cluster, add the following service annotations. For annotation details, see [AWS EKS Service Annotation Instructions](/configure/networking/functions/configure_alb.mdx): + - If the above command returns related Pods, it means the cluster has AWS Load Balancer Controller installed. When creating a load balancer in the corresponding cluster, add the following service annotations. For annotation details, see [AWS EKS Service Annotation Instructions](/networking/functions/configure_alb.mdx): - `service.beta.kubernetes.io/aws-load-balancer-type: external //Required` - `service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip //Required` - `service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing // Optional. Add this annotation if public network support is needed.` diff --git a/docs/en/configure/clusters/managed/cloud-init/network/aws-eks.mdx b/docs/en/configure/clusters/managed/cloud-init/network/aws-eks.mdx index 6f25147fa..b83ce3595 100644 --- a/docs/en/configure/clusters/managed/cloud-init/network/aws-eks.mdx +++ b/docs/en/configure/clusters/managed/cloud-init/network/aws-eks.mdx @@ -22,7 +22,7 @@ weight: 10 **Note**: After installing the tools, configure login information using the user who created the cluster via AWS CLI, and [test if AWS CLI and eksctl tools are correctly installed](#test-aws-cli-and-eksctl-installation). -- Obtain [ACCOUNT_ID](#get-account_id), **REGION**, and **CLUSTER_NAME** in advance, and replace ``, ``, and `` in the documentation with the actual values. +- Obtain [ACCOUNT_ID](#get-account_id), **REGION**, and **CLUSTER_NAME** in advance, and replace ``, ``, and `` with the actual values. **Note**: **ACCOUNT_ID** is the Account ID of the user who created the cluster, **REGION** is the cluster region, and **CLUSTER_NAME** is the cluster name. @@ -32,7 +32,7 @@ weight: 10 ### Deploy AWS Load Balancer Controller \{#deploy-aws-load-balancer-controller} -**Note**: For detailed information on deploying AWS Load Balancer Controller, see [official documentation](https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/aws-load-balancer-controller.html). +**Note**: For detailed information on deploying AWS Load Balancer Controller, see the [provider guide](https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/aws-load-balancer-controller.html). **Configure OIDC Provider** @@ -105,7 +105,7 @@ You can create ingress and LoadBalancer services simultaneously or choose one ba 3. Select **Protocol**. Default is **HTTP**. For **HTTPS**, first [create a certificate](#create-certificate) and select it. -4. Switch to **YAML** and add the following annotations. For details, see [annotation documentation](https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/alb-ingress.html): +4. Switch to **YAML** and add the following annotations. For details, see the [annotation reference](https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/alb-ingress.html): ```yaml alb.ingress.kubernetes.io/scheme: internet-facing ## Specify public access @@ -120,7 +120,7 @@ You can create ingress and LoadBalancer services simultaneously or choose one ba 2. Click **Create Service** and select **LoadBalancer** for **External Access**. -3. Expand **annotations** and fill in [LoadBalancer service annotations](/configure/networking/functions/configure_alb.mdx) as needed. +3. Expand **annotations** and fill in [LoadBalancer service annotations](/networking/functions/configure_alb.mdx) as needed. 4. Click **Create**. diff --git a/docs/en/configure/clusters/managed/cloud-init/storage/google-gke.mdx b/docs/en/configure/clusters/managed/cloud-init/storage/google-gke.mdx index aeb7b4a34..33a03aafb 100644 --- a/docs/en/configure/clusters/managed/cloud-init/storage/google-gke.mdx +++ b/docs/en/configure/clusters/managed/cloud-init/storage/google-gke.mdx @@ -12,7 +12,7 @@ Platform integration with Google GKE and storage initialization configuration. * Default file storage has capacity limits. You can request expansion through support tickets. -* Default file storage creation and deletion operations take considerable time. If it remains in creating status for a long time, please be patient. +* Default file storage creation and deletion operations take considerable time. If the resource remains in `Creating` status for a long time, continue monitoring the operation. ## Prerequisites \{#prerequisites} diff --git a/docs/en/configure/clusters/managed/cloud-init/storage/huawei-cce.mdx b/docs/en/configure/clusters/managed/cloud-init/storage/huawei-cce.mdx index 3655a1880..4f47afe1f 100644 --- a/docs/en/configure/clusters/managed/cloud-init/storage/huawei-cce.mdx +++ b/docs/en/configure/clusters/managed/cloud-init/storage/huawei-cce.mdx @@ -48,7 +48,7 @@ message: "ShareLimitExceeded: Maximum number of shares allowed (10) exceeded." ### Account Overdue -PVC creation fails with the following error due to overdue payments. Please pay promptly: +PVC creation fails with the following error due to overdue payments. Resolve the payment issue before retrying: ``` message: "Your account is suspended and resources cannot be used" diff --git a/docs/en/configure/clusters/managed/cloud-init/storage/overview.mdx b/docs/en/configure/clusters/managed/cloud-init/storage/overview.mdx index 2fabce177..26af0afaa 100644 --- a/docs/en/configure/clusters/managed/cloud-init/storage/overview.mdx +++ b/docs/en/configure/clusters/managed/cloud-init/storage/overview.mdx @@ -1,16 +1,14 @@ --- title: "Overview" -description: "Public cloud overview and storage class support information." +description: "Public cloud storage class support information." weight: 1 --- -* Amazon Elastic Kubernetes Service (Amazon EKS) is Amazon's managed Kubernetes service for running Kubernetes on AWS Cloud and on-premises data centers. In the cloud, Amazon EKS automatically manages the availability and scalability of Kubernetes control plane nodes responsible for scheduling containers, managing application availability, storing cluster data, and other critical tasks, providing a consistent and fully supported Kubernetes solution. +# Public Cloud Storage Initialization Overview -* Huawei Cloud Container Engine (CCE) provides highly reliable, high-performance enterprise-level container application management services, supporting Kubernetes community native applications and tools, simplifying the construction of automated container runtime environments on the cloud. +Use the storage initialization procedures after importing a supported public cloud Kubernetes service and before relying on persistent storage features in workloads. The external provider remains responsible for provider infrastructure and provider-managed storage backends; configures and uses the storage classes exposed to the imported cluster. -* Azure Kubernetes Service (AKS) provides the fastest way to start developing and deploying cloud-native applications on Azure, data centers, or edge using built-in code-to-cloud pipelines and guardrails, with unified management and governance for on-premises, edge, and multi-cloud Kubernetes clusters. - -* Google Kubernetes Engine (GKE) provides an extremely scalable, fully automated Kubernetes service that can be used with almost no Kubernetes expertise required. Its advantages include increased speed, reduced risk, and lower total cost of ownership, with built-in security posture and observability tools, and industry-leading autoscaling solutions that can scale up to 15,000 nodes. +The following tables summarize the default storage classes and operations documented for each provider-specific initialization path. ## Storage Class Support diff --git a/docs/en/configure/clusters/managed/how-to/annotate-platform-url.mdx b/docs/en/configure/clusters/managed/how-to/annotate-platform-url.mdx index dd829d4b8..ae9a0f134 100644 --- a/docs/en/configure/clusters/managed/how-to/annotate-platform-url.mdx +++ b/docs/en/configure/clusters/managed/how-to/annotate-platform-url.mdx @@ -1,15 +1,15 @@ --- -title: "Network Configuration for Import Clusters" +title: "Network Configuration for Imported Clusters" weight: 50 --- -## Scenario Description +# Network Configuration for Imported Clusters -Before cluster import, only unidirectional connectivity is ensured, allowing the global cluster to access the imported cluster. After cluster import, to ensure the imported cluster can properly access the global cluster and achieve bidirectional connectivity, additional network configuration is required to ensure normal operation of platform functional components. +Before import, the required connectivity path lets the `global` cluster access the target cluster. After import, platform components in the imported cluster may also need to access the `global` cluster. Add the platform URL annotation when bidirectional connectivity is required for components such as alerting and log collection. ## Prerequisites -Please prepare in advance the **domain name**, **IP address** that the domain name points to, and the corresponding **valid certificate** that the imported cluster can access. +Prepare the **domain name**, the **IP address** that the domain name points to, and the corresponding **valid certificate** that the imported cluster can access. **Note**: @@ -17,9 +17,9 @@ Please prepare in advance the **domain name**, **IP address** that the domain na * Ensure that the domain's port (HTTPS port, which is the same port as the platform access address) can forward traffic to all control nodes of the global cluster. -## Adding Annotation Information for Imported Clusters +## Add The Platform URL Annotation -Specifically, to ensure that alerting and log collection components can properly access the platform, you must add annotation information to the imported cluster. +Add the annotation to the imported cluster resource. 1. In the left navigation bar, click **Cluster Management** > **Clusters**. diff --git a/docs/en/configure/clusters/managed/how-to/configure-audit-for-standard-kubernetes.mdx b/docs/en/configure/clusters/managed/how-to/configure-audit-for-standard-kubernetes.mdx index 81f7ac72c..11ecf5e44 100644 --- a/docs/en/configure/clusters/managed/how-to/configure-audit-for-standard-kubernetes.mdx +++ b/docs/en/configure/clusters/managed/how-to/configure-audit-for-standard-kubernetes.mdx @@ -10,7 +10,7 @@ weight: 70 After a standard Kubernetes cluster is imported into the platform, you must enable Kubernetes API server audit logging on the cluster before the platform can collect audit data from that cluster. -This document applies to standard Kubernetes clusters whose control plane nodes are managed by you, such as kubeadm-based clusters. It does not apply to managed cloud Kubernetes clusters where you cannot log in to or modify control plane nodes. +Use this procedure for standard Kubernetes clusters whose control plane nodes are managed by you, such as kubeadm-based clusters. It does not apply to provider-managed cloud Kubernetes services where you cannot log in to or modify control plane nodes. ## Prerequisites diff --git a/docs/en/configure/clusters/managed/how-to/fetch-kubeconfig.mdx b/docs/en/configure/clusters/managed/how-to/fetch-kubeconfig.mdx index 3a7ffe2f7..10c9cad06 100644 --- a/docs/en/configure/clusters/managed/how-to/fetch-kubeconfig.mdx +++ b/docs/en/configure/clusters/managed/how-to/fetch-kubeconfig.mdx @@ -7,7 +7,7 @@ weight: 50 ## Problem description -Obtain the configuration required to connect to the import cluster so that the platform can be authorized to access and manage it. This section provides the steps to retrieve the import cluster information. +Obtain the configuration required to connect to the import cluster so the platform can be authorized to access and manage it. ## Prerequisites @@ -101,4 +101,3 @@ If you have already obtained the API server address and CA certificate using the | { base64 -d 2>/dev/null || base64 -D; } ``` - diff --git a/docs/en/configure/clusters/managed/import/alibaba-ack.mdx b/docs/en/configure/clusters/managed/import/alibaba-ack.mdx index ee3896900..d16a78de4 100644 --- a/docs/en/configure/clusters/managed/import/alibaba-ack.mdx +++ b/docs/en/configure/clusters/managed/import/alibaba-ack.mdx @@ -5,10 +5,10 @@ title: Import Alibaba Cloud ACK Cluster # Import Alibaba Cloud ACK Cluster -Import existing Alibaba Cloud ACK managed clusters (Managed Kubernetes) or Alibaba Cloud ACK dedicated clusters (Dedicated Kubernetes) for unified platform management. +Use this provider-specific procedure to import existing Alibaba Cloud ACK managed clusters or dedicated clusters as third-party clusters. The external provider remains responsible for provider infrastructure and the provider-managed Kubernetes and node lifecycle unless a documented provider-specific capability provides that lifecycle. :::tip -For product information about ACK managed clusters (Managed Kubernetes) or Alibaba Cloud ACK dedicated clusters (Dedicated Kubernetes), refer to the [official documentation](https://help.aliyun.com/document_detail/86737.html?scm=20140722.H_86737._.ID_86737-OR_rec-V_1). +For provider cluster type details, see the [provider guide](https://help.aliyun.com/document_detail/86737.html?scm=20140722.H_86737._.ID_86737-OR_rec-V_1). ::: ## Prerequisites @@ -43,11 +43,11 @@ For product information about ACK managed clusters (Managed Kubernetes) or Aliba if curl -s -o /dev/null --retry 3 --retry-delay 5 -- "https://${REGISTRY}/v2/"; then echo 'Test passed: The image registry uses certificates issued by trusted CA authorities. You do not need to execute the content in the "Trust Insecure Image Registry" section.' else - echo 'Test failed: The image registry does not support HTTPS or the certificate is not trusted. Please refer to the "Trust Insecure Image Registry" section for configuration.' + echo 'Test failed: The image registry does not support HTTPS or the certificate is not trusted. See the "Trust Insecure Image Registry" section for configuration.' fi ``` -2. If the test fails, refer to the FAQ [How to trust insecure image registries?](/configure/clusters/managed/how-to/image-repo-trust.mdx). +2. If the test fails, see [How to trust insecure image registries?](/configure/clusters/managed/how-to/image-repo-trust.mdx). ## Get KubeConfig @@ -75,7 +75,7 @@ For product information about ACK managed clusters (Managed Kubernetes) or Aliba | Parameter | Description | | ------ | -------- | - | **Image Registry** | Repository for storing platform component images required by the cluster. **- Platform Default**: Image registry configured during global cluster deployment. **- Private Registry**: Pre-built registry that stores platform-required component images. You need to enter the **private image registry address**, **port**, **username**, and **password** for accessing the image registry. **- Public Registry**: Use public image registry services on the internet. Before use, you need to refer to [Update Public Repository Cloud Credentials](/configure/clusters/how-to/update_public_repository_credentials.mdx) to obtain repository authentication permissions. | + | **Image Registry** | Repository for storing platform component images required by the cluster. **- Platform Default**: Image registry configured during global cluster deployment. **- Private Registry**: Pre-built registry that stores platform-required component images. You need to enter the **private image registry address**, **port**, **username**, and **password** for accessing the image registry. **- Public Registry**: Use public image registry services on the internet. Before use, update [public repository cloud credentials](/configure/clusters/how-to/update_public_repository_credentials.mdx) to obtain repository authentication permissions. | | **Cluster Information** | **Tip**: Can be filled manually or uploaded via KubeConfig file for automatic parsing and filling by the platform. **Parse KubeConfig File**: After uploading the obtained KubeConfig file, the platform will automatically parse and fill the **Cluster Information**. You can modify the automatically filled information. **Cluster Address**: The access address of the cluster's externally exposed API Server, used by the platform to access the cluster's API Server. **CA Certificate**: The cluster's CA certificate. **Note**: When entering manually, you need to enter the Base64-decoded certificate. **Authentication Method**: Authentication method for accessing the cluster. You need to use a **token** or **certificate authentication (client certificate and key)** with **cluster management permissions** for authentication. | 4. Click **Check Connectivity** to check network connectivity with the cluster to be imported and automatically identify the type of cluster to be imported. The cluster type will be displayed as a badge in the upper right corner of the form. @@ -103,7 +103,7 @@ If using public network access for Alibaba Cloud clusters, you can bind a public ### After importing a cluster, the add node button is grayed out. How to add nodes? -Both **Alibaba Cloud ACK managed clusters** and **ACK dedicated clusters** do not support adding nodes through the platform interface. Please add them in the backend or contact the cluster provider to add them. +Both **Alibaba Cloud ACK managed clusters** and **ACK dedicated clusters** do not support adding nodes through the platform interface. Add nodes in the provider backend or contact the cluster provider. ### Which certificates are supported by the certificate management function for imported clusters? @@ -111,7 +111,7 @@ Both **Alibaba Cloud ACK managed clusters** and **ACK dedicated clusters** do no 2. **Platform Component Certificates**: All imported clusters can view platform component certificate information in the platform certificate management interface and support automatic rotation. -### What other features are not supported for imported **Alibaba Cloud ACK managed clusters** and **ACK dedicated clusters**? +### Limitations for this provider-specific import path * **Alibaba Cloud ACK managed clusters** do not support obtaining audit data. diff --git a/docs/en/configure/clusters/managed/import/aws-eks.mdx b/docs/en/configure/clusters/managed/import/aws-eks.mdx index 1dc4413d3..59cc81fb4 100644 --- a/docs/en/configure/clusters/managed/import/aws-eks.mdx +++ b/docs/en/configure/clusters/managed/import/aws-eks.mdx @@ -5,7 +5,7 @@ title: Import Amazon EKS Cluster # Import Amazon EKS Cluster -Connect an existing Amazon EKS (Elastic Kubernetes Service) cluster to the platform for unified management. +Use this provider-specific procedure to import an existing Amazon EKS cluster as a third-party cluster. The external provider remains responsible for provider infrastructure and the provider-managed Kubernetes and node lifecycle unless a documented provider-specific capability provides that lifecycle. ## Prerequisites @@ -46,7 +46,7 @@ To comply with AWS EKS security practices, perform the following steps in AWS Cl KubeConfig from public‑cloud clusters cannot be used directly for import. -Refer to [How do I get cluster information?](/configure/clusters/managed/how-to/fetch-kubeconfig.mdx) to obtain the cluster import token. +To obtain the cluster import token, see [How do I get cluster information?](/configure/clusters/managed/how-to/fetch-kubeconfig.mdx). ## Import the cluster @@ -86,7 +86,7 @@ If you need Ingress and storage capabilities, see [Initialize Ingress for AWS EK ### The Add Node button is disabled after import. How can I add nodes? -Adding nodes from the platform UI is not supported. Please add nodes through your cluster provider. +Adding nodes from the platform UI is not supported. Add nodes through your cluster provider. ### Which certificates are supported by certificate management for imported clusters? @@ -94,7 +94,7 @@ Adding nodes from the platform UI is not supported. Please add nodes through you 2. **Platform component certificates**: Visible in the platform and support automatic rotation. -### What features are not supported for imported **AWS EKS clusters**? +### Limitations for this provider-specific import path * Audit data is not available. diff --git a/docs/en/configure/clusters/managed/import/azure-aks.mdx b/docs/en/configure/clusters/managed/import/azure-aks.mdx index 387a5d18d..57a03e522 100644 --- a/docs/en/configure/clusters/managed/import/azure-aks.mdx +++ b/docs/en/configure/clusters/managed/import/azure-aks.mdx @@ -5,7 +5,7 @@ title: Import Azure AKS Cluster # Import Azure AKS Cluster -Import an existing Azure AKS cluster into the platform for unified management. +Use this provider-specific procedure to import an existing Azure AKS cluster as a third-party cluster. The external provider remains responsible for provider infrastructure and the provider-managed Kubernetes and node lifecycle unless a documented provider-specific capability provides that lifecycle. ## Prerequisites @@ -13,7 +13,7 @@ Import an existing Azure AKS cluster into the platform for unified management. :::tip - * If AKS nodes cannot access the global cluster, refer to the FAQ: [How to configure AKS node external IP security group rules](#how-to-configure-aks-node-external-ip-security-group-rules). + * If AKS nodes cannot access the global cluster, see [How to configure AKS node external IP security group rules](#how-to-configure-aks-node-external-ip-security-group-rules). ::: * The image registry must support HTTPS access and provide a valid TLS certificate authenticated by a public certification authority. @@ -30,11 +30,11 @@ To comply with Azure AKS security standards, the following steps must be perform ## Obtain Cluster Information -### Obtain Import Clusters Token +### Obtain Import Token The KubeConfig file of public cloud clusters cannot be directly used for cluster import. -Please refer to the FAQ [How to obtain cluster information?](/configure/clusters/managed/how-to/fetch-kubeconfig.mdx) to obtain the import cluster token. +See [How to obtain cluster information?](/configure/clusters/managed/how-to/fetch-kubeconfig.mdx) to obtain the import cluster token. ## Import Cluster @@ -46,8 +46,8 @@ Please refer to the FAQ [How to obtain cluster information?](/configure/clusters | Parameter | Description | | ------ | -------- | - | **Image Registry** | The registry that stores platform component images required by the cluster. **- Platform Default**: The image registry configured when deploying the global cluster. **- Private Registry**: A pre-built registry that stores platform-required component images. You need to enter the **Private Image Registry Address**, **Port**, **Username**, and **Password** for accessing the image registry. **- Public Registry**: Use a public image registry service on the internet. Before use, you must first refer to [Update Public Image Registry Cloud Credentials](/configure/clusters/how-to/update_public_repository_credentials.mdx) to obtain registry authentication permissions. | - | **Cluster Information** | **Tip**: Please upload a KubeConfig file, and the platform will automatically parse and fill in the information. **Cluster Address**: The access address of the API Server exposed by the import cluster, used by the platform to access the import cluster's API Server. **CA Certificate**: The CA certificate of the import cluster. **Authentication Method**: The authentication method of the import cluster, which requires using a **Token** with **cluster management permissions** created in the previous step for authentication. | + | **Image Registry** | The registry that stores platform component images required by the cluster. **- Platform Default**: The image registry configured when deploying the global cluster. **- Private Registry**: A pre-built registry that stores platform-required component images. Enter the **Private Image Registry Address**, **Port**, **Username**, and **Password** for accessing the image registry. **- Public Registry**: Use a public image registry service on the internet. Before use, update [public image registry cloud credentials](/configure/clusters/how-to/update_public_repository_credentials.mdx) to obtain registry authentication permissions. | + | **Cluster Information** | **Tip**: Upload a KubeConfig file, and the platform will automatically parse and fill in the information. **Cluster Address**: The access address of the API Server exposed by the import cluster, used by the platform to access the import cluster's API Server. **CA Certificate**: The CA certificate of the import cluster. **Authentication Method**: The authentication method of the import cluster, which requires using a **Token** with **cluster management permissions** created in the previous step for authentication. | 4. Click **Check Connectivity** to verify network connectivity with the import cluster and automatically identify the import cluster type. The cluster type will be displayed as a badge in the upper right corner of the form. @@ -67,7 +67,7 @@ Ensure the global cluster and the imported cluster have network connectivity. Se ### Ingress (Inbound Rules) and Storage Initialization -After importing the cluster, if you need to use Ingress (inbound rules) and storage-related features, please refer to [Azure AKS Cluster Ingress Initialization Configuration](/configure/clusters/managed/cloud-init/network/azure-aks.mdx) and [Azure AKS Cluster Storage Initialization Configuration](/configure/clusters/managed/cloud-init/storage/azure-aks.mdx). +After importing the cluster, if you need to use Ingress (inbound rules) and storage-related features, see [Azure AKS Cluster Ingress Initialization Configuration](/configure/clusters/managed/cloud-init/network/azure-aks.mdx) and [Azure AKS Cluster Storage Initialization Configuration](/configure/clusters/managed/cloud-init/storage/azure-aks.mdx). ## Frequently Asked Questions @@ -81,11 +81,11 @@ To view logs of system components such as Kubelet, CNI, and kernel, you need to **Option 1: Using kubectl node-shell** -[Official Link](https://github.com/kvaps/kubectl-node-shell) +See the [kubectl-node-shell project](https://github.com/kvaps/kubectl-node-shell). **Option 2: Using debug** -[Official Link](https://docs.microsoft.com/en-us/azure/aks/node-access) +See the provider guidance for [connecting to AKS nodes](https://docs.microsoft.com/en-us/azure/aks/node-access). :::note This example requires kubectl version 1.25 or later, which includes the GA `kubectl debug` command. @@ -98,7 +98,7 @@ chroot /host ### Azure ALB using internal load balancer -Refer to [Official Link](https://docs.azure.cn/zh-cn/aks/internal-lb) +For internal load balancer behavior, see the [provider guidance](https://docs.azure.cn/zh-cn/aks/internal-lb). ```yaml apiVersion: v1 @@ -162,7 +162,7 @@ kubectl edit helmrequest -n cpaas-system uat-cluster-aks-alb ### The add node button is grayed out after importing the cluster. How to add nodes? -Adding nodes through the platform interface is not supported. Please contact the cluster provider to add nodes. +Adding nodes through the platform interface is not supported. Contact the cluster provider to add nodes. ### What certificates are supported by the certificate management feature for imported clusters? @@ -170,7 +170,7 @@ Adding nodes through the platform interface is not supported. Please contact the 2. **Platform Component Certificates**: All imported clusters can view platform component certificate information in the platform certificate management interface and support automatic rotation. -### What other features are not supported for imported **AKS clusters**? +### Limitations for this provider-specific import path * Audit data retrieval is not supported. diff --git a/docs/en/configure/clusters/managed/import/gcp-gke.mdx b/docs/en/configure/clusters/managed/import/gcp-gke.mdx index a17ce729a..ba2b3a2c8 100644 --- a/docs/en/configure/clusters/managed/import/gcp-gke.mdx +++ b/docs/en/configure/clusters/managed/import/gcp-gke.mdx @@ -5,7 +5,7 @@ title: Import GKE Cluster # Import GKE Cluster -The platform supports importing Google GKE clusters. +Use this provider-specific procedure to import an existing Google GKE cluster as a third-party cluster. The external provider remains responsible for provider infrastructure and the provider-managed Kubernetes and node lifecycle unless a documented provider-specific capability provides that lifecycle. ## Prerequisites @@ -56,7 +56,7 @@ To comply with GKE security standards, the following steps must be performed usi The KubeConfig file of public cloud clusters cannot be directly used for importing clusters. -Please refer to the FAQ [How to obtain cluster information?](/configure/clusters/managed/how-to/fetch-kubeconfig.mdx) to obtain the target cluster token. +See [How to obtain cluster information?](/configure/clusters/managed/how-to/fetch-kubeconfig.mdx) to obtain the target cluster token. ## Importing the Cluster @@ -68,7 +68,7 @@ Please refer to the FAQ [How to obtain cluster information?](/configure/clusters | Parameter | Description | | ------ | -------- | - | **Image Repository** | Repository for storing platform component images required by the cluster. **- Platform Default**: Image repository configured during global deployment. **- Private Repository**: Pre-built repository storing platform required components. Requires input of **Private Image Repository Address**, **Port**, **Username**, and **Password** for accessing the image repository. **- Public Repository**: Use public image repository services on the internet. Before use, you must first refer to [Update Public Repository Cloud Credentials](/configure/clusters/how-to/update_public_repository_credentials.mdx) to obtain repository authentication permissions. | + | **Image Repository** | Repository for storing platform component images required by the cluster. **- Platform Default**: Image repository configured during global deployment. **- Private Repository**: Pre-built repository storing platform required components. Enter **Private Image Repository Address**, **Port**, **Username**, and **Password** for accessing the image repository. **- Public Repository**: Use public image repository services on the internet. Before use, update [public repository cloud credentials](/configure/clusters/how-to/update_public_repository_credentials.mdx) to obtain repository authentication permissions. | | **Cluster Information** | **Cluster Information**: Includes the target cluster token and the API Server address and CA certificate of the target cluster. **Cluster Address**: The access address where the target cluster exposes the API Server for platform access to the cluster's API Server. **CA Certificate**: CA certificate of the target cluster. **Note**: When manually inputting, you need to enter the Base64 decoded certificate. **Authentication Method**: Authentication method for the target cluster, requires using the **token** (Token) with **cluster management permissions** created in the previous step for authentication. | 4. Click **Check Connectivity** to verify network connectivity with the target cluster and automatically identify the cluster type, which will be displayed as a badge in the top-right corner of the form. @@ -89,13 +89,13 @@ Ensure network connectivity between the global cluster and the imported cluster. ### Ingress and Storage Initialization -After importing the cluster, if you need to use Ingress and storage-related features, please refer to [Google GKE Ingress Controller Configuration](/configure/clusters/managed/cloud-init/network/google-gke.mdx) and [Google GKE Storage Configuration](/configure/clusters/managed/cloud-init/storage/google-gke.mdx). +After importing the cluster, if you need to use Ingress and storage-related features, see [Google GKE Ingress Controller Configuration](/configure/clusters/managed/cloud-init/network/google-gke.mdx) and [Google GKE Storage Configuration](/configure/clusters/managed/cloud-init/storage/google-gke.mdx). ## Frequently Asked Questions ### How to add nodes when the "Add Node" button is grayed out after importing the cluster? -Adding nodes through the platform interface is not supported. Please contact the cluster provider to add nodes. +Adding nodes through the platform interface is not supported. Contact the cluster provider to add nodes. ### What certificates are supported by the certificate management functionality for imported clusters? diff --git a/docs/en/configure/clusters/managed/import/huawei-cce.mdx b/docs/en/configure/clusters/managed/import/huawei-cce.mdx index ce73fc85e..2ec606f78 100644 --- a/docs/en/configure/clusters/managed/import/huawei-cce.mdx +++ b/docs/en/configure/clusters/managed/import/huawei-cce.mdx @@ -1,11 +1,11 @@ --- title: "Import Huawei Cloud CCE Cluster (Public Cloud)" -description: "Import an existing CCE (Cloud Container Engine) cluster (public cloud) into the platform for unified management." +description: "Import an existing CCE cluster as a third-party cluster." weight: 45 --- # Import Huawei Cloud CCE Cluster (Public Cloud) -Import an existing CCE (Cloud Container Engine) cluster (public cloud) into the platform for unified management. +Use this provider-specific procedure to import an existing Huawei Cloud CCE cluster as a third-party cluster. The external provider remains responsible for provider infrastructure and the provider-managed Kubernetes and node lifecycle unless a documented provider-specific capability provides that lifecycle. ## Prerequisites @@ -43,11 +43,11 @@ Import an existing CCE (Cloud Container Engine) cluster (public cloud) into the if curl -s -o /dev/null --retry 3 --retry-delay 5 -- "https://${REGISTRY}/v2/"; then echo 'Test passed: The image registry uses certificates issued by trusted CA authorities. You do not need to execute the content in the "Trust Insecure Image Registry" section.' else - echo 'Test failed: The image registry does not support HTTPS or the certificate is not trusted. Please refer to the "Trust Insecure Image Registry" section for configuration.' + echo 'Test failed: The image registry does not support HTTPS or the certificate is not trusted. See the "Trust Insecure Image Registry" section for configuration.' fi ``` -2. If the test fails, please refer to the FAQ [How to trust an insecure image registry?](/configure/clusters/managed/how-to/image-repo-trust.mdx). +2. If the test fails, see [How to trust an insecure image registry?](/configure/clusters/managed/how-to/image-repo-trust.mdx). ## Obtain Cluster Information @@ -61,7 +61,7 @@ Import an existing CCE (Cloud Container Engine) cluster (public cloud) into the The KubeConfig file of public cloud clusters cannot be directly used for cluster import. -Please refer to the FAQ [How to obtain cluster information?](/configure/clusters/managed/how-to/fetch-kubeconfig.mdx) to obtain the import cluster token. +See [How to obtain cluster information?](/configure/clusters/managed/how-to/fetch-kubeconfig.mdx) to obtain the import cluster token. ## Import Cluster @@ -73,8 +73,8 @@ Please refer to the FAQ [How to obtain cluster information?](/configure/clusters | Parameter | Description | | ------ | -------- | - | **Image Registry** | Repository for storing platform component images required by the cluster.
**- Platform Default**: Image registry configured during global cluster deployment.
**- Private Registry**: Pre-built registry storing platform required components. You need to enter the **private image registry address**, **port**, **username**, and **password** for accessing the image registry.
**- Public Registry**: Use image registry services located on the public network. Before use, you need to first refer to [Update Public Image Registry Cloud Credentials](/configure/clusters/how-to/update_public_repository_credentials.mdx) to obtain registry authentication permissions. | - | **Cluster Information** | **Tip**: Please upload the KubeConfig file for automatic parsing and filling by the platform.

**Cluster Address**: The access address of the API Server exposed by the imported cluster, used for the platform to access the API Server of the imported cluster.

**CA Certificate**: The CA certificate of the imported cluster.

**Authentication Method**: The authentication method of the imported cluster, which requires using a **token** with **cluster management permissions** created in the previous step for authentication. | + | **Image Registry** | Repository for storing platform component images required by the cluster.
**- Platform Default**: Image registry configured during global cluster deployment.
**- Private Registry**: Pre-built registry storing platform required components. Enter the **private image registry address**, **port**, **username**, and **password** for accessing the image registry.
**- Public Registry**: Use image registry services located on the public network. Before use, update [public image registry cloud credentials](/configure/clusters/how-to/update_public_repository_credentials.mdx) to obtain registry authentication permissions. | + | **Cluster Information** | **Tip**: Upload the KubeConfig file for automatic parsing and filling by the platform.

**Cluster Address**: The access address of the API Server exposed by the imported cluster, used for the platform to access the API Server of the imported cluster.

**CA Certificate**: The CA certificate of the imported cluster.

**Authentication Method**: The authentication method of the imported cluster, which requires using a **token** with **cluster management permissions** created in the previous step for authentication. | 4. Click the `Parse KubeConfig File` button and submit the KubeConfig file downloaded in the previous step. The platform will automatically parse and fill in the `Cluster Information` related parameters. @@ -89,19 +89,19 @@ Please refer to the FAQ [How to obtain cluster information?](/configure/clusters ## Network Configuration -To ensure network connectivity between the global cluster and the imported cluster, you must refer to [Imported Cluster Network Configuration](/configure/clusters/managed/how-to/annotate-platform-url.mdx). +To ensure network connectivity between the global cluster and the imported cluster, see [Imported Cluster Network Configuration](/configure/clusters/managed/how-to/annotate-platform-url.mdx). ## Follow-up Operations ### Ingress (Inbound Rules) and Storage Initialization -After importing the cluster, if you need to use Ingress (inbound rules) and storage-related features, please refer to [Huawei Cloud CCE Cluster Ingress Initialization Configuration](/configure/clusters/managed/cloud-init/network/huawei-cce.mdx) and [Huawei Cloud CCE Cluster Storage Initialization Configuration](/configure/clusters/managed/cloud-init/storage/huawei-cce.mdx). +After importing the cluster, if you need to use Ingress (inbound rules) and storage-related features, see [Huawei Cloud CCE Cluster Ingress Initialization Configuration](/configure/clusters/managed/cloud-init/network/huawei-cce.mdx) and [Huawei Cloud CCE Cluster Storage Initialization Configuration](/configure/clusters/managed/cloud-init/storage/huawei-cce.mdx). ## FAQ ### After importing the cluster, the add node button is grayed out. How to add nodes? -Adding nodes through the platform interface is not supported. Please contact the cluster provider to add nodes. +Adding nodes through the platform interface is not supported. Contact the cluster provider to add nodes. ### What certificates does the certificate management feature support for imported clusters? @@ -109,7 +109,7 @@ Adding nodes through the platform interface is not supported. Please contact the 2. **Platform Component Certificates**: All imported clusters can view platform component certificate information in the platform certificate management interface and support automatic rotation. -### What other features are not supported for imported **Huawei Cloud CCE clusters**? +### Limitations for this provider-specific import path * Audit data retrieval is not supported. diff --git a/docs/en/configure/clusters/managed/import/index.mdx b/docs/en/configure/clusters/managed/import/index.mdx index e5aa8a65b..b49f67b1b 100644 --- a/docs/en/configure/clusters/managed/import/index.mdx +++ b/docs/en/configure/clusters/managed/import/index.mdx @@ -1,8 +1,8 @@ --- weight: 30 -title: Import Clusters +title: Import Third-Party Clusters --- -# Import Clusters +# Import Third-Party Clusters diff --git a/docs/en/configure/clusters/managed/import/openshift.mdx b/docs/en/configure/clusters/managed/import/openshift.mdx index ae453709e..8c58563eb 100644 --- a/docs/en/configure/clusters/managed/import/openshift.mdx +++ b/docs/en/configure/clusters/managed/import/openshift.mdx @@ -5,13 +5,13 @@ title: Import OpenShift Cluster # Import OpenShift Cluster -Supports integrating deployed OpenShift clusters into the platform for unified management. +Use this provider-specific procedure to import an existing OpenShift cluster as a third-party cluster. The external distribution owner remains responsible for the Kubernetes distribution, node lifecycle, and provider infrastructure lifecycle unless a documented provider-specific capability provides that lifecycle. ## Prerequisites * The Kubernetes version and parameters of the cluster must meet the [Standard Kubernetes Cluster Requirements](/overview/kubernetes-support-matrix.mdx#version-support-matrix). -* During integration, `kubectl` commands are required. Please install the CLI tool on the bastion host that can access the cluster. +* During integration, `kubectl` commands are required. Install the CLI tool on the bastion host that can access the cluster. * To enable real-time monitoring of metrics such as nodes, workloads (Deployment, StatefulSet, DaemonSet), Pods, and containers, ensure **Prometheus** is already deployed in the target cluster. @@ -182,14 +182,14 @@ oc edit apiserver cluster ### Why is the "Add Node" button disabled? -Adding nodes via the platform UI is not supported. Use the vendor's method. +Adding nodes through the platform UI is not supported. Use the distribution provider's method. ### Which certificates are supported? 1. **Kubernetes Certificates**: Only API Server certificates are visible, no auto-rotation. 2. **Platform Component Certificates**: Visible and auto-rotated. -### Which features are unsupported for OpenShift clusters? +### Limitations for this provider-specific import path * Audit data collection. * ETCD, Scheduler, Controller Manager monitoring (only API Server metrics available). diff --git a/docs/en/configure/clusters/managed/import/overview.mdx b/docs/en/configure/clusters/managed/import/overview.mdx index d6ccf40f5..abecafd25 100644 --- a/docs/en/configure/clusters/managed/import/overview.mdx +++ b/docs/en/configure/clusters/managed/import/overview.mdx @@ -1,20 +1,16 @@ --- weight: 1 -title: Overview +title: Import Third-Party Clusters --- -# Overview +# Import Third-Party Clusters -Choose a provider to connect an existing managed cluster to the platform. - - +Use import when the `global` cluster can reach the target cluster API server and the administrator can provide the required cluster address, CA, and credentials. +| Target environment | Start with | +| --- | --- | +| Existing standard Kubernetes environment | [Import Standard Kubernetes Cluster](./standard-kubernetes.mdx) | +| External Kubernetes distribution | [Import OpenShift Cluster](./openshift.mdx) | +| Public cloud Kubernetes service | [Import Amazon EKS Cluster](./aws-eks.mdx), [Import GKE Cluster](./gcp-gke.mdx), [Import Azure AKS Cluster](./azure-aks.mdx), [Import Alibaba Cloud ACK Cluster](./alibaba-ack.mdx), [Import Tencent Cloud TKE Cluster](./tencent-tke.mdx), or [Import Huawei Cloud CCE Cluster](./huawei-cce.mdx) | +Provider-specific procedures include provider console or CLI steps where required. The provider name identifies the procedure path; it is not a separate cluster model. diff --git a/docs/en/configure/clusters/managed/import/standard-kubernetes.mdx b/docs/en/configure/clusters/managed/import/standard-kubernetes.mdx index a34f31ccd..e15a13318 100644 --- a/docs/en/configure/clusters/managed/import/standard-kubernetes.mdx +++ b/docs/en/configure/clusters/managed/import/standard-kubernetes.mdx @@ -5,14 +5,14 @@ title: Import Standard Kubernetes Cluster # Import Standard Kubernetes Cluster -Supports integrating standard native Kubernetes clusters deployed with **kubeadm** into the platform for unified management. +Use this procedure to import an existing standard Kubernetes cluster, such as a cluster deployed with **kubeadm**, as a third-party cluster. ## Terminology | Term | Description | | ---- | ----------- | -| **Managed Kubernetes Cluster** | A type of Kubernetes cluster provided by cloud vendors, where the Master nodes and their components are managed by the vendor. Users cannot log in or manage the Master nodes. | -| **Unmanaged Kubernetes Cluster** | In contrast, some cloud vendors provide clusters where users manage the Master nodes, such as Alibaba Cloud ACK Dedicated Edition or Tencent Cloud TKE Independent Cluster. | +| **Provider-managed Kubernetes service** | A Kubernetes service where the provider owns the control plane nodes and control plane components. Users usually cannot log in to or directly maintain the control plane nodes. | +| **Self-managed Kubernetes cluster** | A Kubernetes cluster where the cluster owner maintains the control plane nodes and cluster components. | ## Prerequisites @@ -61,7 +61,7 @@ By default, the platform monitors NIC traffic matching `eth.*|en.*|wl.*|ww.*`. I ## Get Cluster Info -Refer to [How to fetch cluster information?](/configure/clusters/managed/how-to/fetch-kubeconfig.mdx). +See [How to fetch cluster information?](/configure/clusters/managed/how-to/fetch-kubeconfig.mdx). ## Integrate Cluster @@ -91,7 +91,7 @@ If you need the platform to collect audit data from an imported standard Kuberne ### Why is the "Add Node" button disabled? -For both managed and unmanaged clusters, adding nodes through the platform UI is not supported. Add nodes directly or via the vendor. +Adding nodes through the platform UI is not supported for imported standard Kubernetes clusters. Add nodes directly in the target cluster or through the cluster provider. ### Which certificates are supported? @@ -100,8 +100,8 @@ For both managed and unmanaged clusters, adding nodes through the platform UI is ### Which features are unsupported? -* **Managed clusters**: Audit logs are not available. -* **Managed clusters**: ETCD, Scheduler, Controller Manager monitoring not supported (only API Server metrics available). +* **Provider-managed Kubernetes services**: Audit logs are not available. +* **Provider-managed Kubernetes services**: ETCD, Scheduler, and Controller Manager monitoring are not supported. Only API Server metrics are available. * **All clusters**: Certificates other than API Server are not supported. ### How to fix Containerd runtime causing distributed storage deployment failures? \{#how-to-fix-containerd-runtime-causing-distributed-storage-deployment-failures} diff --git a/docs/en/configure/clusters/managed/import/tencent-tke.mdx b/docs/en/configure/clusters/managed/import/tencent-tke.mdx index 61d22be10..b31df1afd 100644 --- a/docs/en/configure/clusters/managed/import/tencent-tke.mdx +++ b/docs/en/configure/clusters/managed/import/tencent-tke.mdx @@ -5,10 +5,10 @@ title: Import Tencent Cloud TKE Cluster # Import Tencent Cloud TKE Cluster -Import existing Tencent Cloud TKE Dedicated clusters or Tencent Cloud TKE Managed clusters into the platform for unified management. +Use this provider-specific procedure to import existing Tencent Cloud TKE dedicated clusters or managed clusters as third-party clusters. The external provider remains responsible for provider infrastructure and the provider-managed Kubernetes and node lifecycle unless a documented provider-specific capability provides that lifecycle. :::tip -For product introduction of TKE Dedicated clusters or Tencent Cloud TKE Managed clusters, please refer to the [official documentation](https://cloud.tencent.com/document/product/457/32187). +For provider cluster type details, see the [provider guide](https://cloud.tencent.com/document/product/457/32187). ::: ## Prerequisites @@ -45,11 +45,11 @@ For product introduction of TKE Dedicated clusters or Tencent Cloud TKE Managed if curl -s -o /dev/null --retry 3 --retry-delay 5 -- "https://${REGISTRY}/v2/"; then echo 'Verification passed: The image registry uses a certificate issued by a trusted CA. It is not necessary to execute the content in the "Trust Unsafe Image Registry" section.' else - echo 'Verification failed: The image registry does not support HTTPS or the certificate is not trusted. Please refer to the "Trust Unsafe Image Registry" section for configuration.' + echo 'Verification failed: The image registry does not support HTTPS or the certificate is not trusted. See the "Trust Unsafe Image Registry" section for configuration.' fi ``` -2. If verification fails, please refer to the FAQ [How to trust an unsafe image registry?](/configure/clusters/managed/how-to/image-repo-trust.mdx). +2. If verification fails, see [How to trust an unsafe image registry?](/configure/clusters/managed/how-to/image-repo-trust.mdx). ## Obtain KubeConfig @@ -69,7 +69,7 @@ For product introduction of TKE Dedicated clusters or Tencent Cloud TKE Managed | Parameter | Description | | ------ | -------- | - | **Image Registry** | Registry for storing platform component images required by the cluster. **- Platform Default**: Image registry configured during global deployment. **- Private Registry**: Pre-built registry that stores platform-required component images. You need to input the **private image registry address**, **port**, **username**, and **password** for accessing the image registry. **- Public Registry**: Use image registry services located on the public network. Before use, you need to first refer to [Update Public Registry Cloud Credentials](/configure/clusters/how-to/update_public_repository_credentials.mdx) to obtain registry authentication permissions. | + | **Image Registry** | Registry for storing platform component images required by the cluster. **- Platform Default**: Image registry configured during global deployment. **- Private Registry**: Pre-built registry that stores platform-required component images. Enter the **private image registry address**, **port**, **username**, and **password** for accessing the image registry. **- Public Registry**: Use image registry services located on the public network. Before use, update [public registry cloud credentials](/configure/clusters/how-to/update_public_repository_credentials.mdx) to obtain registry authentication permissions. | | **Cluster Information** | **Tip**: Can be filled manually or uploaded via KubeConfig file for automatic parsing and filling by the platform. **Parse KubeConfig File**: After uploading the obtained KubeConfig file, the platform will automatically parse and fill in the **Cluster Information**, and you can modify the automatically filled information. **Cluster Address**: The access address of the cluster's externally exposed API Server, used by the platform to access the cluster's API Server. **CA Certificate**: The cluster's CA certificate. **Note**: When manually inputting, you need to input the Base64-decoded certificate. **Authentication Method**: Authentication method for accessing the cluster, requires using a **token** (Token) or **certificate authentication (client certificate and key)** with **cluster management permissions**. | 4. Click **Check Connectivity** to verify network connectivity with the cluster to be imported and automatically identify the type of cluster to be imported. The cluster type will be displayed as a badge in the upper right corner of the form. @@ -83,13 +83,13 @@ For product introduction of TKE Dedicated clusters or Tencent Cloud TKE Managed ## Network Configuration -Ensure network connectivity between the global cluster and the cluster to be imported. You must refer to [Network Configuration for Importing Clusters](/configure/clusters/managed/how-to/annotate-platform-url.mdx). +Ensure network connectivity between the global cluster and the cluster to be imported. See [Network Configuration for Importing Clusters](/configure/clusters/managed/how-to/annotate-platform-url.mdx). ## FAQ ### After importing the cluster, the "Add Node" button is grayed out. How to add nodes? -Both **TKE Dedicated clusters** and **TKE Managed clusters** do not support adding nodes through the platform interface. Please add them in the backend or contact the cluster provider to add them. +Both **TKE Dedicated clusters** and **TKE Managed clusters** do not support adding nodes through the platform interface. Add nodes in the provider backend or contact the cluster provider. ### What certificates does the certificate management function for imported clusters support? @@ -97,7 +97,7 @@ Both **TKE Dedicated clusters** and **TKE Managed clusters** do not support addi 2. **Platform Component Certificates**: All imported clusters can view platform component certificate information in the platform certificate management interface and support automatic rotation. -### What other features are not supported for imported **TKE Managed clusters** and **TKE Dedicated clusters**? +### Limitations for this provider-specific import path * **TKE Managed clusters** do not support obtaining audit data. diff --git a/docs/en/configure/clusters/managed/overview.mdx b/docs/en/configure/clusters/managed/overview.mdx index fbd9b5203..82f463589 100644 --- a/docs/en/configure/clusters/managed/overview.mdx +++ b/docs/en/configure/clusters/managed/overview.mdx @@ -1,23 +1,23 @@ --- -weight: 2 -title: "overview" +weight: 2 +title: Managed Clusters --- -# overview +# Third-Party Cluster Onboarding -The platform supports managing existing standard Kubernetes clusters, OpenShift, Amazon EKS (Elastic Kubernetes Service), and Huawei Cloud CCE (Cloud Container Engine) clusters. +Third-party clusters are existing Kubernetes environments whose Kubernetes distribution, node lifecycle, or provider infrastructure are managed outside . In the console, these environments appear under **Managed Clusters**. -## What is a managed cluster? + can provide centralized governance, resource visibility, Extension installation, application operations, and observability integration for third-party clusters when connectivity, credentials, component prerequisites, provider requirements, and Extension compatibility are satisfied. Onboarding does not make the owner of the external cluster's Kubernetes lifecycle, node lifecycle, or provider infrastructure lifecycle. -A managed cluster refers to consolidating existing clusters into a centralized platform for unified governance. It allows enterprises to bring various cluster types—including standard Kubernetes clusters and certain public cloud clusters—under a single control plane. Centralized management improves scalability, availability, and maintainability, enabling better utilization of compute resources and a more efficient cloud environment. You can onboard clusters to the platform via **Access a cluster** or **Register a cluster**. +## Choose An Onboarding Method -## What's the difference between the two onboarding methods? +| Method | Connection model | Use when | +| --- | --- | --- | +| Import cluster | The `global` cluster connects to the target cluster API server with supplied address, CA, and credentials. | The platform can reach the target API server, and the administrator can provide the required cluster information. | +| Register cluster | A reverse proxy service in the target cluster initiates registration and establishes a tunnel to the platform. | The target cluster should initiate the connection, or direct access from the `global` cluster to the target API server is restricted. | -They differ only in how onboarding is performed; day‑to‑day operations are consistent. - -* **Import a cluster**: The platform first obtains information about the target cluster and then actively sends access instructions to it. Using this information, the platform establishes a stable connection for centralized monitoring and management, helping administrators oversee the environment and ensure efficient, secure resource utilization. - -* **Register a cluster**: Deploy a reverse proxy in the target cluster, which initiates a registration request to the platform. The cluster uses the CLI to automatically establish a tunnel and communicate securely with the platform. Because no cluster details need to be disclosed, security is enhanced and the process is simpler and more efficient. +After onboarding, high-level day-2 operations are treated consistently in the cluster list. Provider-specific limitations can still apply to node operations, audit data, control-plane metrics, certificates, ingress, storage, and Extension compatibility. +For import procedures, see [Import Third-Party Clusters](./import/overview.mdx). For reverse-connect onboarding, see [Register Cluster](./register.mdx). diff --git a/docs/en/configure/clusters/managed/register.mdx b/docs/en/configure/clusters/managed/register.mdx index 90b69d18f..e57af6ec0 100644 --- a/docs/en/configure/clusters/managed/register.mdx +++ b/docs/en/configure/clusters/managed/register.mdx @@ -5,13 +5,13 @@ title: Register Cluster # Register Cluster -This is a method of deploying a reverse proxy service in the managed cluster, where the managed cluster actively initiates registration requests to the platform. +Use register when the target third-party cluster should initiate the connection to the platform through a reverse proxy tunnel. ## Prerequisites -* Depending on the type of managed cluster, the versions and parameters of Kubernetes and other components on the managed cluster must meet the [Version and Parameter Requirements for Managed Clusters](/overview/kubernetes-support-matrix.mdx#version-support-matrix). +* Depending on the target environment, the Kubernetes version and component parameters in the target cluster must meet the [version and parameter requirements](/overview/kubernetes-support-matrix.mdx#version-support-matrix). -* The image registry must support HTTPS access and provide a valid TLS certificate authenticated by a public certification authority. If this cannot be met, refer to the FAQ [How to Trust Insecure Image Registries?](/configure/clusters/managed/how-to/image-repo-trust.mdx) +* The image registry must support HTTPS access and provide a valid TLS certificate authenticated by a public certification authority. If this requirement cannot be met, see [How to Trust Insecure Image Registries?](/configure/clusters/managed/how-to/image-repo-trust.mdx) **Note**: The **Public Registry** provided by the platform on the public network already meets HTTPS access requirements. You only need to verify whether the **Platform Default** and **Private Registry** support HTTPS access. @@ -19,7 +19,7 @@ This is a method of deploying a reverse proxy service in the managed cluster, wh ## Important Notes -The platform's network card traffic monitoring recognizes network cards with names matching `eth\.\|en\.\|wl\.*\|ww\.*` by default. Therefore, if you use network cards with other naming conventions, please refer to the [Collecting Network Data from Custom Named Network Cards](/configure/clusters/managed/how-to/netcard-chart.mdx) documentation to modify the corresponding resources after cluster connection, ensuring the platform can properly monitor network card traffic. +Network interface traffic monitoring recognizes network interfaces with names matching `eth\.\|en\.\|wl\.*\|ww\.*` by default. If the target cluster uses other naming conventions, see [Collecting Network Data from Custom Named Network Cards](/configure/clusters/managed/how-to/netcard-chart.mdx) and update the corresponding resources after registration. ## Register Cluster @@ -33,15 +33,15 @@ The platform's network card traffic monitoring recognizes network cards with nam | ------ | -------- | | **Platform Default** | Image registry used when deploying global components. | | **Private Registry** | External image registry that you have set up in advance. You need to enter the **Private Image Registry Address**, **Port**, **Username**, and **Password** for accessing the image registry. | - | **Public Registry** | Pull required images through the public image registry provided by the platform. You need to ensure that your cluster can access the public network. Before use, you need to first refer to [Update Public Network Image Registry Cloud Credentials](/configure/clusters/how-to/update_public_repository_credentials.mdx) to obtain registry authentication permissions.| + | **Public Registry** | Pull required images through the public image registry provided by the platform. Ensure that the target cluster can access the public network. Before use, see [Update Public Network Image Registry Cloud Credentials](/configure/clusters/how-to/update_public_repository_credentials.mdx) to obtain registry authentication permissions.| 4. Click **Create**, obtain the registration command on the **Registration Command** page and run the command in the cluster to be registered. - **Note**: The registration command is valid for 24 hours. Please re-obtain it after expiration. + **Note**: The registration command is valid for 24 hours. Obtain a new command after it expires. ## View Registration Command -You can find the cluster waiting for registration in the cluster list and click **View Registration Command**. Please perform the registration operation before the expiration time. +Find the cluster waiting for registration in the cluster list and click **View Registration Command**. Run the registration command before it expires. ## FAQ diff --git a/docs/en/configure/clusters/nodes/overview.mdx b/docs/en/configure/clusters/nodes/overview.mdx deleted file mode 100644 index c87fb249a..000000000 --- a/docs/en/configure/clusters/nodes/overview.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Overview" -description: "Nodes are the fundamental building blocks of a cluster. Nodes added to a cluster can be either virtual machines or physical servers. Each node contains the essential components required to run Pods, including Kubelet, Kube-proxy, and Container Runtime." -weight: 1 ---- - -# Overview - -Nodes are the fundamental building blocks of a cluster. Nodes added to a cluster can be either virtual machines or physical servers. Each node contains the essential components required to run Pods, including Kubelet, Kube-proxy, and Container Runtime. - -Users with platform management permissions can manage nodes under clusters. - -**Note**: Adding nodes to imported clusters or deleting nodes from imported clusters is not supported. - -## Node Types - -* **Control Plane Nodes**: Responsible for running cluster components such as kube-apiserver, kube-scheduler, kube-controller-manager, etcd, container networking, and some platform management components. - - * When applications are allowed to be deployed on control plane nodes, control plane nodes can also function as compute nodes. - - * At least 1 control plane node must be added. Setting 2 control plane nodes is not supported. With 3 or more control plane nodes, the cluster becomes a high-availability cluster (for high-availability clusters, it is recommended to use an odd number of nodes, preferably 3 or 5). - - * When the number of control plane nodes is 3 or more, the cluster has multi-replica disaster recovery capabilities and is considered a high-availability cluster. - -* **Compute Nodes**: Responsible for hosting business Pods running on the cluster. The number of compute nodes required in a cluster can typically be planned based on business volume. - -## Linux Node Availability Check \{#node_checks} - -If you need to build an on-premises cluster, please first refer to the [cluster check](/install/prepare/node_preprocessing.mdx#node_checks) to ensure all node configurations meet the requirements. All prerequisites must be satisfied, otherwise cluster deployment may fail. - -## Supported Operating Systems and CPU Models \{#arch} -Please refer to [Supported Operating Systems and CPU Models](/install/prepare/node_preprocessing.mdx#supported_os_and_kernels). diff --git a/docs/en/configure/clusters/on-premises.mdx b/docs/en/configure/clusters/on-premises.mdx index 257062e51..e61011c5e 100644 --- a/docs/en/configure/clusters/on-premises.mdx +++ b/docs/en/configure/clusters/on-premises.mdx @@ -11,7 +11,7 @@ title: Creating an On-Premise Cluster 1. If you downloaded a single-architecture installation package from [Download Installation Package](/install/prepare/download.mdx#download_core_package), ensure your node machines have the same architecture as the package. Otherwise, nodes won't start due to missing architecture-specific images. 2. Verify that your node operating system and kernel are supported. See [Supported OS and Kernels](/install/prepare/node_preprocessing.mdx#supported_os_and_kernels) for details. -3. Perform availability checks on node machines. For specific check items, refer to [Node Preprocessing > Node Checks](/install/prepare/node_preprocessing.mdx#node_checks). +3. Perform availability checks on node machines. For specific check items, see [Node Preprocessing > Node Checks](/install/prepare/node_preprocessing.mdx#node_checks). 4. If node machine IPs cannot be directly accessed via SSH, provide a SOCKS5 proxy for the nodes. The `global` cluster will access nodes through this proxy service. ### Load Balancing @@ -52,7 +52,7 @@ Cluster images support Platform Built-in, Private Repository, and Public Reposit ### Container Networking -If you plan to use Kube-OVN's Underlay for your cluster, refer to [Preparing Kube-OVN Underlay Physical Network](/configure/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx). +If you plan to use Kube-OVN's Underlay for your cluster, prepare the [Kube-OVN Underlay physical network](/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx). ## Creation Procedure @@ -126,7 +126,7 @@ If you plan to use Kube-OVN's Underlay for your cluster, refer to [Preparing Kub - An enterprise-grade Cloud Native Kubernetes container network orchestration system developed by Alauda. It brings mature networking capabilities from the OpenStack domain to Kubernetes, supporting cross-cloud network management, traditional network architecture and infrastructure interconnection, and edge cluster deployment scenarios, while greatly enhancing Kubernetes container network security, management efficiency, and performance. + Kube-OVN is a cloud native Kubernetes container network orchestration system developed by . It provides Kubernetes networking capabilities for cross-cloud network management, traditional network architecture integration, infrastructure interconnection, and edge cluster deployment scenarios. @@ -215,7 +215,7 @@ If you plan to use Kube-OVN's Underlay for your cluster, refer to [Preparing Kub configuration and display it in the hint below the input field.
Important: After cluster creation, the cluster network cannot be - changed, so please plan the network carefully. + changed. Plan the network carefully before creating the cluster. @@ -276,7 +276,7 @@ If you plan to use Kube-OVN's Underlay for your cluster, refer to [Preparing Kub
- The platform's network interface traffic monitoring by default recognizes traffic on interfaces named like{' '} eth\.\|en\.\|wl\.*\|ww\.*. If you use interfaces with - different naming conventions, please refer to [Collect Network Data from + different naming conventions, see [Collect Network Data from Custom-Named Network Interfaces](/observability/monitor/how_to/special_network_card_name.mdx) after cluster onboarding to modify the relevant resources and ensure the @@ -440,7 +440,7 @@ If you plan to use Kube-OVN's Underlay for your cluster, refer to [Preparing Kub cluster that already has Underlay subnets created.
Select an existing [Add Bridge - Network](/configure/networking/functions/configure_subnet.mdx#kube-ovn_underlay_bridge_network). + Network](/networking/functions/configure_subnet.mdx#kube-ovn_underlay_bridge_network). If you don't want to use the bridge network's default NIC, you can configure the node NIC separately. diff --git a/docs/en/configure/clusters/overview.mdx b/docs/en/configure/clusters/overview.mdx index bb55eb9ee..547f42ae3 100644 --- a/docs/en/configure/clusters/overview.mdx +++ b/docs/en/configure/clusters/overview.mdx @@ -1,9 +1,8 @@ --- weight: 10 -title: Overview --- -# Clusters Overview +# Overview Start here to choose whether to create a platform-managed cluster, evaluate Hosted Control Plane, or onboard an existing Kubernetes environment. For the platform-level relationship between cluster responsibility, control-plane topology, and onboarding boundaries, see [Cluster Management Models](../../overview/cluster-management-models.mdx). @@ -13,9 +12,9 @@ Start here to choose whether to create a platform-managed cluster, evaluate Host | --- | --- | --- | | Let the platform provision machines and manage Immutable OS for supported providers. | [About Immutable Infrastructure](./immutable-infra.mdx) | Platform-owned lifecycle applies only within the supported provider and workflow scope. | | Create a cluster on machines that you prepare and maintain. | [Creating an On-Premise Cluster](./on-premises.mdx) | The platform manages Kubernetes after node preparation; node OS lifecycle remains user-owned. | -| Evaluate HCP for a non-production 4.3 scenario. | [About Hosted Control Plane](./about-hcp.mdx) | HCP is Technology Preview in 4.3 and is not production-supported. | -| Onboard an existing Kubernetes environment. | [Managed Clusters Overview](./managed/overview.mdx) | The external owner, distribution, or provider usually owns Kubernetes, node, and infrastructure lifecycle. | -| Choose between direct platform access and reverse-connect onboarding. | [Import Clusters](./managed/import/overview.mdx) and [Register Cluster](./managed/register.mdx) | Import and register are onboarding methods, not separate day-2 capability models. | +| Evaluate HCP for a non-production 4.3 scenario. | [About Hosted Control Plane](../hosted_control_planes/overview.mdx) | HCP is Technology Preview in 4.3 and is not production-supported. | +| Onboard an existing Kubernetes environment. | [Third-Party Cluster Onboarding](./managed/overview.mdx) | The external owner, distribution, or provider usually owns Kubernetes, node, and infrastructure lifecycle. | +| Choose between direct platform access and reverse-connect onboarding. | [Import Third-Party Clusters](./managed/import/overview.mdx) and [Register Cluster](./managed/register.mdx) | Import and register are onboarding methods, not separate day-2 capability models. | ## Platform-Managed Cluster Creation @@ -44,7 +43,7 @@ To create and manage User-Provisioned Infrastructure clusters through APIs, see Hosted Control Plane is a control-plane topology. Each hosted cluster has its own control plane, and multiple hosted control planes run as workloads on a management cluster. -In , HCP is implemented through Kamaji (`TenantControlPlane`). In 4.3, HCP is Technology Preview, is not production-supported, supports disconnected environments, and defaults to IPI only. For evaluation details, see [About Hosted Control Plane](./about-hcp.mdx). +In , HCP is implemented through Kamaji (`TenantControlPlane`). In 4.3, HCP is Technology Preview, is not production-supported, supports disconnected environments, and defaults to IPI only. For evaluation details, see [About Hosted Control Plane](../hosted_control_planes/overview.mdx). ## Third-Party Cluster Onboarding @@ -59,13 +58,13 @@ Third-party clusters are onboarded through import or register workflows: Provider-specific caveats can apply to certificates, audit data, control-plane metrics, ingress, storage, node operations, connectivity, and Extension compatibility. Use the import and register workflow pages for detailed prerequisites. -For onboarding workflows, see [Managed Clusters Overview](./managed/overview.mdx), [Import Clusters](./managed/import/overview.mdx), and [Register Cluster](./managed/register.mdx). +For onboarding workflows, see [Third-Party Cluster Onboarding](./managed/overview.mdx), [Import Third-Party Clusters](./managed/import/overview.mdx), and [Register Cluster](./managed/register.mdx). ## Version Compatibility \{#version-compatibility} When importing or connecting existing clusters, validate the Kubernetes version against the current compatibility policy. -### ACP 4.3 And Later +### 4.3 And Later - 4.3 adds support for Kubernetes 1.34 for platform-managed cluster scenarios. - For upgrades to 4.3, workload clusters must remain within the compatible version range 1.34, 1.33, 1.32, and 1.31 before the `global` cluster upgrade. @@ -75,7 +74,7 @@ When importing or connecting existing clusters, validate the Kubernetes version - Product validation for the default Extend baseline covers installing and using Operators, installing and using Cluster Plugins, ClickHouse-based logging, and VictoriaMetrics-based monitoring. This does not mean that all specific Operators or Cluster Plugins are covered by product validation. - For 4.3 and later, workload clusters no longer need to be on the single latest compatible Kubernetes minor release before the `global` cluster upgrade. -### ACP 4.2 And Earlier +### 4.2 And Earlier - Upgrade workload clusters to the latest documented compatible Kubernetes version before upgrading the `global` cluster. - Use the [Kubernetes Support Matrix](../../overview/kubernetes-support-matrix.mdx) as the main reference for the documented version mapping. diff --git a/docs/en/configure/clusters/etcd-encryption.mdx b/docs/en/configure/etcd/encryption.mdx similarity index 92% rename from docs/en/configure/clusters/etcd-encryption.mdx rename to docs/en/configure/etcd/encryption.mdx index c4a60c10c..31be2a453 100644 --- a/docs/en/configure/clusters/etcd-encryption.mdx +++ b/docs/en/configure/etcd/encryption.mdx @@ -5,7 +5,7 @@ title: etcd Encryption # etcd Encryption -This guide helps you install, understand, and operate the etcd Encryption Manager in to automate etcd data encryption key rotation within your clusters. +Install and operate etcd Encryption Manager in to automate etcd data encryption key rotation within your clusters. It ensures that sensitive data stored in etcd, such as secrets and configmaps, is encrypted using a secure algorithm, enhancing your cluster's security. diff --git a/docs/en/configure/etcd/index.mdx b/docs/en/configure/etcd/index.mdx new file mode 100644 index 000000000..438f7d7a3 --- /dev/null +++ b/docs/en/configure/etcd/index.mdx @@ -0,0 +1,8 @@ +--- +weight: 30 +title: etcd +--- + +# etcd + + diff --git a/docs/en/configure/etcd/overview.mdx b/docs/en/configure/etcd/overview.mdx new file mode 100644 index 000000000..6971fb8af --- /dev/null +++ b/docs/en/configure/etcd/overview.mdx @@ -0,0 +1,15 @@ +--- +weight: 10 +--- + +# Overview + +etcd stores Kubernetes control-plane state for a cluster. Platform administrators use etcd guidance to understand encryption, operational health, capacity considerations, and the handoff to backup and restore procedures. + +| Need | Continue with | +| --- | --- | +| Enable and understand etcd encryption key rotation. | [etcd encryption](./encryption.mdx) | +| Review operational practices and route to health, capacity, and backup topics. | [etcd practices](./practices.mdx) | +| Back up or restore etcd data. | [etcd backup and restore](../backup/etcd.mdx) | + +Use these etcd pages to plan control-plane state encryption, health, capacity, and maintenance. When you need to protect or recover etcd data, continue with the backup and restore procedure. diff --git a/docs/en/configure/etcd/practices.mdx b/docs/en/configure/etcd/practices.mdx new file mode 100644 index 000000000..e33db7832 --- /dev/null +++ b/docs/en/configure/etcd/practices.mdx @@ -0,0 +1,17 @@ +--- +weight: 30 +title: etcd Practices +--- + +# etcd Practices + +Use etcd practices to plan control-plane state operations before making changes that affect cluster recovery or availability. + +| Practice area | Guidance | +| --- | --- | +| Backup before risky maintenance | Back up etcd before control-plane maintenance, node operating system changes, or other operations that can affect cluster state. Follow [etcd backup and restore](../backup/etcd.mdx). | +| Encryption | Use [etcd encryption](./encryption.mdx) when sensitive Kubernetes resources need encryption at rest through the documented encryption manager. | +| Capacity and health | Monitor etcd health, disk latency, and available capacity through the observability and cluster operation tools available in your environment. | +| Recovery scope | Use etcd backup and restore for control-plane state recovery. Registry data, monitoring data, logging data, and application data need their own backup and recovery paths. | + +Do not use this page as a production hardening checklist. Follow topic-specific support guidance for validated recovery procedures, scale limits, and maintenance windows. diff --git a/docs/en/configure/hosted_control_planes/index.mdx b/docs/en/configure/hosted_control_planes/index.mdx new file mode 100644 index 000000000..8252f12f1 --- /dev/null +++ b/docs/en/configure/hosted_control_planes/index.mdx @@ -0,0 +1,8 @@ +--- +weight: 22 +title: Hosted Control Planes +--- + +# Hosted Control Planes + + diff --git a/docs/en/configure/hosted_control_planes/overview.mdx b/docs/en/configure/hosted_control_planes/overview.mdx new file mode 100644 index 000000000..6d8f719c9 --- /dev/null +++ b/docs/en/configure/hosted_control_planes/overview.mdx @@ -0,0 +1,11 @@ +--- +weight: 10 +--- + +# Overview + +Hosted Control Plane (HCP) is a control-plane topology. Each hosted cluster has its own control plane, and multiple hosted control planes run as workloads on a management cluster. In , HCP is implemented through Kamaji (`TenantControlPlane`). + +In 4.3, HCP is Technology Preview, is not production-supported, supports disconnected environments, and defaults to Installer-Provisioned Infrastructure (IPI) only. Use HCP for non-production evaluation only. For installation and operation tasks within that scope, follow the HCP guidance below. + + diff --git a/docs/en/configure/machine_config/index.mdx b/docs/en/configure/machine_config/index.mdx index 281670dec..68b83c520 100644 --- a/docs/en/configure/machine_config/index.mdx +++ b/docs/en/configure/machine_config/index.mdx @@ -10,5 +10,5 @@ title: Machine Configuration Note that **Machine Configuration is only supported in Immutable Infrastructure**. In this architecture, the node operating system is immutable, and configuration updates are applied through controlled images or configuration policies, ensuring repeatability and system stability. :::info -Because Machine Configuration releases on a different cadence from , the Machine Configuration documentation is now available as a separate documentation set at . +Machine Configuration releases on a different cadence from . For installation, upgrade, and detailed operation procedures, use . ::: diff --git a/docs/en/configure/networking/index.mdx b/docs/en/configure/networking/index.mdx deleted file mode 100644 index 7de7ab64f..000000000 --- a/docs/en/configure/networking/index.mdx +++ /dev/null @@ -1,7 +0,0 @@ ---- -weight: 59 ---- - -# Networking - - diff --git a/docs/en/configure/clusters/nodes/in-place-os-upgrade.mdx b/docs/en/configure/nodes/in_place_os_upgrade.mdx similarity index 88% rename from docs/en/configure/clusters/nodes/in-place-os-upgrade.mdx rename to docs/en/configure/nodes/in_place_os_upgrade.mdx index 9821940eb..02ee0fd96 100644 --- a/docs/en/configure/clusters/nodes/in-place-os-upgrade.mdx +++ b/docs/en/configure/nodes/in_place_os_upgrade.mdx @@ -1,36 +1,36 @@ --- -title: "Plan an In-Place OS Upgrade for ACP Nodes" -description: "Use this reference guide to plan and verify an in-place operating system upgrade on ACP self-built cluster nodes." +title: "Plan an In-Place OS Upgrade for Nodes" +description: "Plan and verify an in-place operating system upgrade on self-built cluster nodes." weight: 22 author: dev@alauda.io category: howto queries: - - in-place OS upgrade for ACP nodes + - in-place OS upgrade for platform nodes - upgrade operating system on self-built cluster nodes - - verify ACP nodes after OS upgrade + - verify platform nodes after OS upgrade - node OS upgrade checklist --- -# Plan an In-Place OS Upgrade for ACP Nodes +# Plan an In-Place OS Upgrade for Nodes -This guide helps cluster administrators plan an in-place operating system upgrade for nodes in self-built clusters. It focuses on the checks that must be completed before and after the operating system changes. +Cluster administrators can use this checklist to plan an in-place operating system upgrade for nodes in self-built clusters. Complete the checks before and after the operating system changes. -This guide is a reference checklist for maintenance windows. It does not replace the operating system vendor's upgrade documentation, and it does not guarantee that every operating system upgrade path is supported. Confirm the target operating system and kernel against the support matrix before you upgrade any node. +Use this checklist together with the operating system provider's supported upgrade procedure during a maintenance window. Confirm the target operating system and kernel against the support matrix before you upgrade any node. The checklist does not guarantee that every operating system upgrade path is supported. ## Scope and Limitations -Use this guide only when all of the following conditions are met: +Use this procedure only when all of the following conditions are met: - The cluster is an on-premises or self-built cluster managed by . - You can log in to the target nodes and manage the node operating system. - You have platform administrator permissions, `kubectl` administrator permissions, and SSH or console access to each target node. - You can drain workload Pods from the target node before the operating system upgrade. -This guide does not apply to the following cluster types: +Do not use this procedure for the following cluster types: -- Clusters that use [Immutable Infrastructure](../immutable-infra.mdx). Apply operating system changes by replacing nodes with new images. +- Clusters that use [Immutable Infrastructure](../clusters/immutable-infra.mdx). Apply operating system changes by replacing nodes with new images. - Managed cloud Kubernetes clusters where the cloud provider manages the node or control plane operating system. - Imported clusters where you cannot log in to nodes or control plane nodes. @@ -41,7 +41,7 @@ Complete the following checks before changing the operating system on any node. ### Step 1: Confirm the target operating system and kernel -Confirm that the target operating system version, kernel version, kernel source, and CPU architecture are within the supported range. For the current support matrix and known restrictions, see [Supported OS and Kernel Versions](../../../install/prepare/node_preprocessing.mdx#supported_os_and_kernels). +Confirm that the target operating system version, kernel version, kernel source, and CPU architecture are within the supported range. For the current support matrix and known restrictions, see [Supported OS and Kernel Versions](/install/prepare/node_preprocessing.mdx#supported_os_and_kernels). Apply these rules before the maintenance window: @@ -53,7 +53,7 @@ Apply these rules before the maintenance window: ### Step 2: Check for conflicting packages -During an in-place operating system upgrade, the operating system package manager might install or overwrite container runtime, Kubernetes, or container network binaries. Before the upgrade, check and resolve packages that conflict with components. For the package lists and commands, see [Remove Conflicting Packages](../../../install/prepare/node_preprocessing.mdx#remove_conflicting_packages). +During an in-place operating system upgrade, the operating system package manager might install or overwrite container runtime, Kubernetes, or container network binaries. Before the upgrade, check and resolve packages that conflict with components. For the package lists and commands, see [Remove Conflicting Packages](/install/prepare/node_preprocessing.mdx#remove_conflicting_packages). If conflicting packages are found, prepare an application migration plan and back up the affected data before uninstalling them. @@ -74,7 +74,7 @@ Also record critical node configuration files that your operating system upgrade Confirm that the remaining nodes have enough capacity to run the Pods evicted from the target node. Then drain the node before the operating system upgrade. -You can use the console to evict Pods from the node. For the console operation, see [Manage Nodes](./node-management.mdx). +You can use the console to evict Pods from the node. For the console operation, see [Manage Nodes](./node_management.mdx). If you use `kubectl`, confirm the command options with your operations team before running it. For example: @@ -92,7 +92,7 @@ Control plane nodes run components such as `kube-apiserver`, `etcd`, `kube-sched Before upgrading a control plane node: -- Back up etcd data. For the supported backup mechanism and restore considerations, see [etcd Backup and Restore](../../backup/etcd.mdx). +- Back up etcd data. For the supported backup mechanism and restore considerations, see [etcd Backup and Restore](../backup/etcd.mdx). - Confirm that the etcd cluster is healthy and that quorum can be maintained while one control plane node is unavailable. - Confirm that the cluster has at least three control plane nodes when you are performing rolling maintenance on control plane nodes. - If possible, validate the procedure on compute nodes first, and then proceed with control plane nodes. @@ -227,7 +227,7 @@ When the node is healthy, resume scheduling. kubectl uncordon ``` -You can also resume scheduling from the console. For the console operation, see [Manage Nodes](./node-management.mdx). +You can also resume scheduling from the console. For the console operation, see [Manage Nodes](./node_management.mdx). ### Step 6: Validate workload recovery diff --git a/docs/en/configure/clusters/nodes/index.mdx b/docs/en/configure/nodes/index.mdx similarity index 57% rename from docs/en/configure/clusters/nodes/index.mdx rename to docs/en/configure/nodes/index.mdx index f8b325493..2ce1a8e83 100644 --- a/docs/en/configure/clusters/nodes/index.mdx +++ b/docs/en/configure/nodes/index.mdx @@ -1,8 +1,8 @@ --- weight: 25 -title: Node Management +title: Nodes --- -# Node Management +# Nodes diff --git a/docs/en/configure/clusters/nodes/node-add.mdx b/docs/en/configure/nodes/node_add.mdx similarity index 84% rename from docs/en/configure/clusters/nodes/node-add.mdx rename to docs/en/configure/nodes/node_add.mdx index 0e55c6e33..34fd62c07 100644 --- a/docs/en/configure/clusters/nodes/node-add.mdx +++ b/docs/en/configure/nodes/node_add.mdx @@ -10,7 +10,7 @@ When a cluster needs to scale up or when abnormal nodes on the cluster need to b ## Constraints and Limitations -* Nodes to be added to the cluster must be prepared in advance. Please refer to the [Node Availability Check Reference](/install/prepare/node_preprocessing.mdx#node_checks) to prepare and check nodes to be added to the cluster. Ensure all conditions are met, otherwise cluster deployment may fail. +* Prepare nodes before adding them to the cluster. Use the [Node Availability Check Reference](/install/prepare/node_preprocessing.mdx#node_checks) to verify the nodes. Cluster deployment can fail when required conditions are not met. * The hardware architecture of nodes to be added must be consistent with the cluster's hardware architecture. @@ -20,7 +20,7 @@ When a cluster needs to scale up or when abnormal nodes on the cluster need to b * **Cluster planning guideline**: A cluster must have at least 1 control plane node. Setting exactly 2 control plane nodes is not supported. With 3 or more control plane nodes, the cluster becomes a high-availability cluster (for high-availability clusters, it is recommended to use an odd number of nodes, preferably 3 or 5). **Note**: This requirement applies only when adding or changing control plane capacity; you can safely add worker/compute nodes without being forced to add control plane nodes. -* A node can only belong to one cluster. Nodes to be added cannot be occupied by other clusters. +* A node can be part of only one cluster. Nodes that already belong to another cluster cannot be added. ## Prerequisites @@ -34,7 +34,7 @@ When a cluster needs to scale up or when abnormal nodes on the cluster need to b 3. Under the **Nodes** tab, click **Add Node**. -4. Refer to [Node Configuration Parameters](/configure/clusters/on-premises.mdx#node-settings) to configure relevant parameters. +4. Configure the relevant parameters. For parameter details, see [Node Configuration Parameters](/configure/clusters/on-premises.mdx#node-settings). 5. Click **Add** to perform availability check on the nodes.
After the check passes, node addition begins, and the nodes are in **Adding** state. @@ -56,4 +56,3 @@ On the node list page, you can view the list information of added nodes. For nod ### Re-add Failed Nodes After adding nodes, if some nodes fail to be added, a prompt will appear above the node list. Click the **Re-add** button in the prompt box to re-add the failed nodes. - diff --git a/docs/en/configure/clusters/nodes/node-management.mdx b/docs/en/configure/nodes/node_management.mdx similarity index 94% rename from docs/en/configure/clusters/nodes/node-management.mdx rename to docs/en/configure/nodes/node_management.mdx index 7043cf6fe..830458895 100644 --- a/docs/en/configure/clusters/nodes/node-management.mdx +++ b/docs/en/configure/nodes/node_management.mdx @@ -51,7 +51,7 @@ By setting the scheduling state of nodes, you can control whether newly created Evict all Pods except those managed by DaemonSet (daemon set) from nodes in normal state to other nodes in the cluster, and set the node to unschedulable state. -**Note**: Data from locally stored Pods will be lost after eviction. Please proceed with caution. +**Note**: Eviction removes data stored locally in Pods. Confirm the data impact before evicting Pods. ### Procedure @@ -75,7 +75,7 @@ Taints are a property of nodes that allow nodes to refuse to run certain types o For example: For a node where we find its memory utilization has reached 91%, it is not recommended to continue scheduling new Pods to this node. We can set a taint for it. After setting the taint, Kubernetes will not schedule Pods to this node. -[Learn more...](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) +For Kubernetes taint and toleration behavior, see [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/). ### Procedure @@ -85,7 +85,7 @@ For example: For a node where we find its memory utilization has reached 91%, it 3. Under the **Nodes** tab, click **Set Taints** on the right side of the node to set taints. -4. Refer to the following description to set the key, value, and effect of taints. Multiple taints can be added to a node. +4. Set the key, value, and effect of taints. Multiple taints can be added to a node. Taint attributes consist of `key=value [effect]`. @@ -136,7 +136,7 @@ When nodes in an on-premises cluster are physical machines, you can control whet When the switch is enabled, newly created virtual machines are allowed to be scheduled to the physical machine node; when the switch is disabled, newly created virtual machines are prohibited from being scheduled to the physical machine node, but this does not affect virtual machines already running on the node. -**Tip**: For related operations and precautions, please refer to [Prepare Virtualization Environment](/virtualization/virtualization/overview.mdx). +**Tip**: For related operations and precautions, see [Prepare Virtualization Environment](/virtualization/virtualization/overview.mdx). ## Delete On-Premises Cluster Nodes diff --git a/docs/en/configure/clusters/nodes/node-monitoring.mdx b/docs/en/configure/nodes/node_monitoring.mdx similarity index 100% rename from docs/en/configure/clusters/nodes/node-monitoring.mdx rename to docs/en/configure/nodes/node_monitoring.mdx diff --git a/docs/en/configure/clusters/acp-node-planning.mdx b/docs/en/configure/nodes/node_planning.mdx similarity index 74% rename from docs/en/configure/clusters/acp-node-planning.mdx rename to docs/en/configure/nodes/node_planning.mdx index 404ef155d..a8e0e317a 100644 --- a/docs/en/configure/clusters/acp-node-planning.mdx +++ b/docs/en/configure/nodes/node_planning.mdx @@ -4,7 +4,7 @@ weight: 90 # Cluster Node Planning -A cluster utilizes the Kubernetes node role labels `node-role.kubernetes.io/` to assign different roles to nodes. For convenience of description, we refer to this type of label as a role label. +A cluster uses Kubernetes node role labels in the format `node-role.kubernetes.io/` to assign different roles to nodes. In this topic, `role label` refers to this type of label. By default, a cluster contains two types of nodes: control plane nodes and worker nodes, used to host control plane workloads and application workloads, respectively. @@ -23,15 +23,15 @@ In addition to these default role labels, you can also define custom role labels - You can add the role label `node-role.kubernetes.io/log` to designate a node as a log node, specialized for hosting logging components. -This document will guide you through creating infra nodes and custom role nodes, and migrating workloads to those nodes. +Use role labels and taints to create infra nodes or custom role nodes, then move selected workloads to those nodes when workload isolation requires it. -## Creating Infra Nodes on Non-Immutable Cluster +## Creating Infra Nodes on Non-Immutable Cluster By default, a cluster only includes control plane nodes and worker nodes. If you want to designate certain worker nodes as infra nodes dedicated to hosting infrastructure components, you need to manually add the appropriate role label and taint to those nodes. > **Note:** > -> The operations in this section are only applicable to non-immutable clusters. That is, the following operations are not supported on cloud clusters (such as EKS managed clusters deployed via the `Alauda Container Platform EKS Provider` Cluster Plugin), third-party clusters, or clusters where the nodes use an immutable OS. +> The operations in this section apply only to non-immutable clusters. Do not use these operations for provider-managed cloud clusters, third-party clusters, or clusters where the nodes use an immutable OS. ### Adding Infra Nodes @@ -62,19 +62,19 @@ Labels: node-role.kubernetes.io/infra="" Taints: node-role.kubernetes.io/infra=reserved:NoSchedule ``` -The output indicates that the Node 192.168.143.133 has been configured as an infra node and has been tainted with tainted with `node-role.kubernetes.io/infra=reserved:NoSchedule`. +The output indicates that the Node `192.168.143.133` has been configured as an infra node and has the `node-role.kubernetes.io/infra=reserved:NoSchedule` taint. ## Migrating Pods to Infra Nodes -If you want to schedule specific Pod onto infra nodes, you need to make the following configurations: +If you want to schedule a specific Pod onto infra nodes, you need to make the following configurations: - A nodeSelector targeting the infra role label. - Corresponding tolerations for the infra node's taint. -Below is an example Deployment manifest configured to run on the infra node. +Below is an example Pod manifest configured to run on the infra node. ```yaml -apiVersion: apps/v1 +apiVersion: v1 kind: Pod metadata: name: infra-pod-demo @@ -91,14 +91,13 @@ spec: ... ``` -The nodeSelector ensures the Pod is only scheduled on nodes with the label `node-role.kubernetes.io/infra: ""`, -the toleration allows the Pod to tolerate the taint node-role.kubernetes.io/infra=reserved:NoSchedule. +The nodeSelector ensures the Pod is only scheduled on nodes with the label `node-role.kubernetes.io/infra: ""`, and the toleration allows the Pod to tolerate the taint `node-role.kubernetes.io/infra=reserved:NoSchedule`. With these configurations, the Pod will be scheduled onto the infra node. > **Note:** > -> Moving pods installed via OLM Operators or Cluster Plugins to an infra node is not always possible. The capability to move these pods is depends on the configuration of each Operator or Cluster Plugin. +> Moving pods installed through OLM Operators or Cluster Plugins to an infra node is not always possible. The capability to move these pods depends on the configuration of each Operator or Cluster Plugin. ## Custom Node Planning @@ -122,7 +121,7 @@ Replace \ with your desired role name, such as monitoring, storage, or log kubectl taint nodes node-role.kubernetes.io/=:NoSchedule ``` -Replace \ with your custom role name and replace \ with a meaningful descriptor, such as reserved or dedicated. This value is optional but useful for documentation and clarity. +Replace \ with your custom role name and replace \ with a meaningful descriptor, such as reserved or dedicated. This value is optional but can help operators understand the scheduling intent. #### Step 3: Verify the Configuration @@ -157,12 +156,11 @@ This taint prevents unscheduled workloads from being deployed to the node. ```yaml Name: 192.168.143.133 Roles: log -Labels: node-role.kubernetes.io/log=reserved +Labels: node-role.kubernetes.io/log="" ... Taints: node-role.kubernetes.io/log=reserved:NoSchedule ``` This confirms that the node has been successfully configured as a log node with the appropriate label and taint. -By following the above practices, you can effectively partition your Kubernetes nodes based on their intended purpose, improve workload isolation, and ensure that specific components are deployed onto appropriately configured nodes. - +Use role labels and taints to partition Kubernetes nodes by purpose, improve workload isolation, and schedule selected components onto appropriately configured nodes. diff --git a/docs/en/configure/nodes/overview.mdx b/docs/en/configure/nodes/overview.mdx new file mode 100644 index 000000000..e3424b153 --- /dev/null +++ b/docs/en/configure/nodes/overview.mdx @@ -0,0 +1,37 @@ +--- +weight: 1 +--- + +# Overview + +Nodes are the fundamental building blocks of a cluster. Nodes can be virtual machines or physical servers, and each node runs the components required to host Pods, including kubelet, kube-proxy, and the container runtime. + +Users with platform management permissions can add, manage, monitor, and plan nodes under clusters. + +:::note +Adding nodes to imported clusters or deleting nodes from imported clusters is not supported. +::: + +## Node types + +- **Control plane nodes** run cluster components such as kube-apiserver, kube-scheduler, kube-controller-manager, etcd, container networking, and some platform management components. +- **Compute nodes** host business Pods running on the cluster. Plan compute node count based on workload demand. + +## Node operation paths + +| Need | Continue with | +| --- | --- | +| Add nodes to a cluster. | [Add nodes](./node_add.mdx) | +| Manage labels, taints, tolerations, and node scheduling state. | [Manage nodes](./node_management.mdx) | +| Monitor node status. | [Monitor nodes](./node_monitoring.mdx) | +| Plan infra nodes or custom role nodes. | [Node planning](./node_planning.mdx) | +| Plan in-place operating system upgrades for eligible nodes. | [In-place OS upgrade](./in_place_os_upgrade.mdx) | +| Tune CPU, memory, or topology manager policies for performance-sensitive workloads. | [Resource manager policies](../scalability/resource_manager_policies.mdx) | + +## Linux node availability check \{#node_checks} + +Before building an on-premises cluster, complete the [node checks](/install/prepare/node_preprocessing.mdx#node_checks) and confirm that every node meets the requirements. Cluster deployment can fail when prerequisites are not satisfied. + +## Supported operating systems and CPU models \{#arch} + +For supported operating systems and CPU models, see [Supported Operating Systems and CPU Models](/install/prepare/node_preprocessing.mdx#supported_os_and_kernels). diff --git a/docs/en/configure/notification/index.mdx b/docs/en/configure/notification/index.mdx deleted file mode 100644 index 695965a74..000000000 --- a/docs/en/configure/notification/index.mdx +++ /dev/null @@ -1,8 +0,0 @@ ---- -weight: 70 -title: Notification ---- - -# Notification - - \ No newline at end of file diff --git a/docs/en/configure/overview.mdx b/docs/en/configure/overview.mdx new file mode 100644 index 000000000..a5d0bdd6d --- /dev/null +++ b/docs/en/configure/overview.mdx @@ -0,0 +1,37 @@ +--- +weight: 10 +--- + +# Overview + +After you validate Core installation, prepare the platform for day-2 operations by configuring clusters, access, storage, networking, registry, backup, node operations, platform settings, and scalability. + +## Configure scope + +Choose the area that matches the platform capability you need to prepare, then follow the linked capability-specific procedures for detailed tasks. + +| Area | Use this area for | Continue with | +| --- | --- | --- | +| Post-installation | Preparing the platform after Core validation. | [Postinstallation configuration](./postinstallation/overview.mdx) | +| Clusters | Creating platform-managed clusters and onboarding existing Kubernetes environments. | [Clusters](./clusters/overview.mdx) | +| Hosted Control Planes | Evaluating Hosted Control Plane scope and entry points. | [Hosted Control Planes](./hosted_control_planes/overview.mdx) | +| Nodes | Managing nodes, planning node roles, and preparing OS upgrade paths. | [Nodes](./nodes/overview.mdx) | +| etcd | Understanding etcd encryption, operational practices, and backup handoff. | [etcd](./etcd/overview.mdx) | +| Backup and restore | Protecting platform state and application resources. | [Backup and restore](./backup/overview.mdx) | +| Kubernetes storage use | Preparing PVs, PVCs, StorageClasses, snapshots, and object bucket claims for workloads. | [Storage](./storage/intro.mdx) | +| Platform settings | Managing platform-wide feature gates and related settings. | [Platform settings](./platform_settings/index.mdx) | +| Registry administration | Installing, upgrading, and recovering the platform image registry. | [Registry administration](./registry/overview.mdx) | +| Scalability and performance | Planning scale, capacity, resource-manager policies, and performance-sensitive clusters. | [Scalability and performance](./scalability/overview.mdx) | + +## Related Areas + +Some day-2 tasks require detailed procedures in another top-level area after you identify the capability you need to configure. + +| Capability | Source of detailed guidance | +| --- | --- | +| Networking | [Networking](../networking/overview.mdx) | +| Users, roles, and projects | [Users and roles](../security/users_and_roles/index.mdx) and [Projects](../security/project/intro.mdx) | +| Alert notifications and monitoring | [Alerting](../observability/alerting/overview.mdx) and [Monitoring](../observability/monitor/intro.mdx) | +| Web console and CLI tools | [UI](../ui/index.mdx) | +| Storage systems | [Storage Systems](../storage/index.mdx) | +| Upgrade | [Upgrade](../upgrade/index.mdx) | diff --git a/docs/en/configure/feature_toggles.mdx b/docs/en/configure/platform_settings/feature_gates.mdx similarity index 88% rename from docs/en/configure/feature_toggles.mdx rename to docs/en/configure/platform_settings/feature_gates.mdx index f71320926..80af9ea64 100644 --- a/docs/en/configure/feature_toggles.mdx +++ b/docs/en/configure/platform_settings/feature_gates.mdx @@ -1,13 +1,13 @@ --- weight: 10 -title: Feature Gate +title: Feature Gates --- -# Feature Gate Configuration \{#feature_toggles} +# Feature Gates \{#feature_toggles} ## Overview -You can customize which features are enabled or disabled on the platform through the Web Console. Feature gates allow you to control whether functionality is visible in the Web Console or how the corresponding APIs behave. Whether a gate only affects UI visibility or also changes API behavior depends on the implementation of each specific feature gate. For detailed information, please refer to the documentation for each feature. +You can customize which features are enabled or disabled on the platform through the Web Console. Feature gates allow you to control whether functionality is visible in the Web Console or how the corresponding APIs behave. Whether a gate only affects UI visibility or also changes API behavior depends on the implementation of each specific feature gate. For feature-specific behavior, use the guidance for that feature. ## Procedure diff --git a/docs/en/configure/platform_settings/index.mdx b/docs/en/configure/platform_settings/index.mdx new file mode 100644 index 000000000..e5ca973c8 --- /dev/null +++ b/docs/en/configure/platform_settings/index.mdx @@ -0,0 +1,8 @@ +--- +weight: 75 +title: Platform Settings +--- + +# Platform Settings + + diff --git a/docs/en/configure/postinstallation/configure_alert_notifications.mdx b/docs/en/configure/postinstallation/configure_alert_notifications.mdx new file mode 100644 index 000000000..6c49224e3 --- /dev/null +++ b/docs/en/configure/postinstallation/configure_alert_notifications.mdx @@ -0,0 +1,16 @@ +--- +weight: 60 +title: Configure Alert Notifications +--- + +# Configure Alert Notifications + +Prepare alert notification delivery so operations teams can route monitoring and cluster messages to the required channels. + +| Need | Continue with | +| --- | --- | +| Configure cluster notification delivery. | [Cluster Notification](../../observability/alerting/notification.mdx) | +| Manage monitoring alerts and notification channels. | [Manage alerts](../../observability/monitor/functions/manage_alert.mdx) and [Manage notifications](../../observability/monitor/functions/manage_notifcation.mdx) | +| Understand observability capabilities. | [Observability overview](../../observability/overview.mdx) | + +Set up notification delivery during post-installation when operations teams need platform alerts, cluster messages, and monitoring notifications routed to approved channels. diff --git a/docs/en/configure/postinstallation/day_2_operations.mdx b/docs/en/configure/postinstallation/day_2_operations.mdx new file mode 100644 index 000000000..4109dbd36 --- /dev/null +++ b/docs/en/configure/postinstallation/day_2_operations.mdx @@ -0,0 +1,20 @@ +--- +weight: 70 +title: Day-2 Operations +--- + +# Day-2 Operations + +After users, networking, storage, registry, and alert notification routes are prepared, review the day-2 operation areas that affect platform stability and workload readiness. + +| Operation area | Continue with | +| --- | --- | +| Backup and restore | [Backup and restore](../backup/overview.mdx) | +| Node operations | [Nodes](../nodes/overview.mdx) | +| etcd encryption and operational practices | [etcd](../etcd/overview.mdx) | +| Scalability and performance | [Scalability and performance](../scalability/overview.mdx) | +| Monitoring, logging, events, and tracing | [Observability](../../observability/overview.mdx) | +| Platform upgrade | [Upgrade](../../upgrade/index.mdx) | +| Machine configuration for Immutable Infrastructure | [Machine Configuration](../machine_config/index.mdx) | + +For production hardening, validated scale limits, recovery objectives, compliance, or detailed operational runbooks, use the topic-specific procedures and confirmed support guidance for each capability. diff --git a/docs/en/configure/postinstallation/index.mdx b/docs/en/configure/postinstallation/index.mdx new file mode 100644 index 000000000..947114254 --- /dev/null +++ b/docs/en/configure/postinstallation/index.mdx @@ -0,0 +1,8 @@ +--- +weight: 15 +title: Postinstallation Configuration +--- + +# Postinstallation Configuration + + diff --git a/docs/en/configure/postinstallation/overview.mdx b/docs/en/configure/postinstallation/overview.mdx new file mode 100644 index 000000000..e9ea80d25 --- /dev/null +++ b/docs/en/configure/postinstallation/overview.mdx @@ -0,0 +1,26 @@ +--- +weight: 10 +--- + +# Overview + +After you validate Core installation, prepare the platform areas that application teams and operations teams depend on. The exact sequence depends on whether you will create new workload clusters, onboard third-party clusters, install Extensions, or prepare an existing environment for application workloads. + +## Recommended path + +| Step | Prepare | Start with | +| --- | --- | --- | +| 1 | Confirm cluster and day-2 operation model. | [Clusters](../clusters/overview.mdx) | +| 2 | Prepare users, roles, identity providers, and projects. | [Prepare users and access](./prepare_users_and_access.mdx) | +| 3 | Prepare networking and ingress or load-balancing paths. | [Prepare networking](./prepare_networking.mdx) | +| 4 | Prepare Kubernetes storage consumption and storage-system dependencies. | [Prepare storage](./prepare_storage.mdx) | +| 5 | Prepare registry access for platform components and workloads. | [Prepare registry](./prepare_registry.mdx) | +| 6 | Prepare alert notification routing. | [Configure alert notifications](./configure_alert_notifications.mdx) | +| 7 | Review backup, upgrade, scalability, and observability routes for day-2 operations. | [Day-2 operations](./day_2_operations.mdx) | + +## Conditional work + +- Install the Product Docs plugin immediately after Core validation if users need in-console help links. +- Install Extensions only when the target capability is needed and the package is compatible with the current platform version. +- Configure Global Cluster Disaster Recovery only when the deployment scenario requires a Primary and Standby `global` cluster design. +- Create or onboard workload clusters only when application placement, isolation, or lifecycle requirements need separate workload clusters. diff --git a/docs/en/configure/postinstallation/prepare_networking.mdx b/docs/en/configure/postinstallation/prepare_networking.mdx new file mode 100644 index 000000000..151a81c71 --- /dev/null +++ b/docs/en/configure/postinstallation/prepare_networking.mdx @@ -0,0 +1,19 @@ +--- +weight: 30 +title: Prepare Networking +--- + +# Prepare Networking + +Prepare cluster networking before exposing applications, onboarding third-party clusters, or configuring north-south traffic. + +| Need | Continue with | +| --- | --- | +| Understand the platform networking model. | [Networking overview](../../networking/overview.mdx) | +| Configure Services, Ingress, Gateway API, DNS, domains, or certificates. | [Networking guides](../../networking/functions/index.mdx) | +| Install or understand networking operators. | [Networking operators](../../networking/operators/index.mdx) | +| Configure network policy. | [Network security](../../networking/security/index.mdx) | +| Prepare Kube-OVN, multiple networks, or advanced networking tasks. | [Networking HowTo](../../networking/how_to/index.mdx) | +| Troubleshoot networking issues. | [Networking troubleshooting](../../networking/trouble_shooting/index.mdx) | + +After selecting the required network path, use Networking for detailed concepts, operators, configuration tasks, troubleshooting, and network observability. diff --git a/docs/en/configure/postinstallation/prepare_registry.mdx b/docs/en/configure/postinstallation/prepare_registry.mdx new file mode 100644 index 000000000..c3a655fa9 --- /dev/null +++ b/docs/en/configure/postinstallation/prepare_registry.mdx @@ -0,0 +1,18 @@ +--- +weight: 50 +title: Prepare Registry +--- + +# Prepare Registry + +Prepare the platform image registry before application teams build, push, pull, or deploy images that depend on the built-in registry. + +| Need | Continue with | +| --- | --- | +| Understand registry administration scope and namespace isolation. | [Registry administration](../registry/overview.mdx) | +| Install the registry cluster plugin. | [Install registry](../registry/install/index.mdx) | +| Upgrade the registry cluster plugin. | [Upgrade registry](../registry/upgrade/index.mdx) | +| Back up or recover registry data. | [Registry backup and recovery](../registry/backup_and_restore.mdx) | +| Use images from workloads or developer workflows. | [Images](../../developer/images/overview.mdx) and [registry image use](../../developer/registry/index.mdx) | + +Complete registry installation, upgrade, and recovery before teams depend on the built-in registry. Use Developer guidance when application teams need to build images or reference images from workloads. diff --git a/docs/en/configure/postinstallation/prepare_storage.mdx b/docs/en/configure/postinstallation/prepare_storage.mdx new file mode 100644 index 000000000..cf298fac3 --- /dev/null +++ b/docs/en/configure/postinstallation/prepare_storage.mdx @@ -0,0 +1,17 @@ +--- +weight: 40 +title: Prepare Storage +--- + +# Prepare Storage + +Prepare storage from two directions: storage-system installation and Kubernetes storage consumption. + +| Need | Continue with | +| --- | --- | +| Install or operate Ceph, MinIO, or TopoLVM storage systems. | [Storage Systems](../../storage/index.mdx) | +| Prepare PVs, PVCs, StorageClasses, snapshots, generic ephemeral volumes, or COSI bucket claims for workloads. | [Configure storage](../storage/intro.mdx) | +| Prepare application backup repositories. | [Backup repositories](../backup/application/repository.mdx) | +| Plan application PVC backup or restore. | [Application backup and restore](../backup/overview.mdx#application-backup-and-restore) | + +Install and operate the required storage systems before workloads depend on them. Then configure the Kubernetes storage resources, such as PVs, PVCs, StorageClasses, snapshots, and bucket claims, that application workloads consume. diff --git a/docs/en/configure/postinstallation/prepare_users_and_access.mdx b/docs/en/configure/postinstallation/prepare_users_and_access.mdx new file mode 100644 index 000000000..62b4f01b5 --- /dev/null +++ b/docs/en/configure/postinstallation/prepare_users_and_access.mdx @@ -0,0 +1,17 @@ +--- +weight: 20 +title: Prepare Users and Access +--- + +# Prepare Users and Access + +Prepare identity, access, projects, and membership before teams start managing clusters or deploying workloads. + +| Need | Continue with | +| --- | --- | +| Configure identity providers, users, groups, and roles. | [Users and roles](../../security/users_and_roles/index.mdx) | +| Create projects and assign project members. | [Projects](../../security/project/intro.mdx) | +| Review platform authentication entry points. | [Cluster authentication](../../security/alauda_cluster_authentication.mdx) | +| Review platform security settings. | [Security](../../security/index.mdx) | + +Before opening the platform to application teams or cluster operators, configure the required identity providers, users, groups, roles, projects, and project membership in Security. diff --git a/docs/en/configure/registry/backup_and_restore.mdx b/docs/en/configure/registry/backup_and_restore.mdx new file mode 100644 index 000000000..d3ada518e --- /dev/null +++ b/docs/en/configure/registry/backup_and_restore.mdx @@ -0,0 +1,136 @@ +--- +weight: 15 +--- + +# Registry Data Backup and Recovery + +## Overview + +Use this procedure to back up and recover Registry data when registry image data is stored in S3-compatible object storage. + +The recovery model separates image data stored in S3 from the Cluster Plugin configuration defined in the Kubernetes `ModuleInfo` custom resource. + +* **Backup**: Retrieve S3 configuration from the `ModuleInfo` resource and back up data from the specified storage bucket. +* **Recovery**: After installing the Cluster Plugin in a new or repaired cluster, update its S3 configuration in the `ModuleInfo` resource to point to the bucket that contains the restored data. + +This model keeps data backup and recovery independent from Cluster Plugin deployment and upgrade operations. All connection information is managed through the declarative `ModuleInfo` resource. + +## Prerequisites + +* Have `kubectl` access and appropriate permissions to operate the target Kubernetes cluster. +* Have credentials and client tools (e.g., awscli, rclone, minio-client) to access and operate the S3-compatible storage used for image data. +* The Registry Cluster Plugin is installed and configured, and its `ModuleInfo` resource exists and is in a healthy state. +* Have independent, sufficient storage capacity prepared for backup data (e.g., another S3 bucket). + +## Data Backup +During backup, obtain the current production S3 configuration and perform a full backup of the image data within the storage bucket. + +### Step 1: Obtain Current S3 Configuration +Extract the S3 storage configuration from the `ModuleInfo` resource that manages the Registry Cluster Plugin. +This information is the basis for the backup operation. + +Run the following commands on the `global` cluster: +```bash +# 1. Identify the ModuleInfo resource name for the image-registry module +MODULE_INFO_NAME=$(kubectl get moduleinfo -l cpaas.io/module-name=image-registry -o jsonpath='{.items[0].metadata.name}') +echo "Target ModuleInfo Resource: $MODULE_INFO_NAME" + +# 2. Extract key S3 configuration information +S3_BUCKET=$(kubectl get moduleinfo $MODULE_INFO_NAME -o jsonpath='{.spec.config.s3storage.bucket}') +S3_ENDPOINT=$(kubectl get moduleinfo $MODULE_INFO_NAME -o jsonpath='{.spec.config.s3storage.regionEndpoint}') +S3_REGION=$(kubectl get moduleinfo $MODULE_INFO_NAME -o jsonpath='{.spec.config.s3storage.region}') +S3_SECRET_NAME=$(kubectl get moduleinfo $MODULE_INFO_NAME -o jsonpath='{.spec.config.s3storage.secretName}') + +# 3. Obtain access keys from the Secret (typically access-key-id and secret-access-key) +# Note: The output is Base64 encoded and needs to be decoded accordingly. +kubectl get secret -n cpaas-system $S3_SECRET_NAME -o jsonpath='{.data}' +``` + +**Key Variable Descriptions**: + +- `S3_BUCKET`: The source bucket name where image data is actually stored. +- `S3_ENDPOINT`: The endpoint URL to connect to the S3-compatible service. +- `S3_REGION`: The region identifier for the S3 service. +- `S3_SECRET_NAME`: The Kubernetes Secret name storing the authentication keys. + +### Step 2: Perform S3 Bucket Data Backup +Using your S3 client tool of choice, leverage the configuration obtained in the previous step to perform a full backup of the source bucket's data. + +Use the following backup logic: + +* Configure your client with the endpoint ($S3_ENDPOINT), region ($S3_REGION), and the decoded access key and secret key from the Secret. +* Execute a sync or copy command to back up all data from the source bucket ($S3_BUCKET) to your prepared independent backup location (e.g., another S3 bucket or path). +* Record the backup timestamp, the bucket name and endpoint used, and archive this information with the backup files. + +## Data Recovery +Before recovery, install the Registry Cluster Plugin in the target environment, such as a new cluster or repaired cluster. Then modify the configuration so the registry can access the restored image data. + +### Step 1: Prepare Backup Data +Using your S3 client tool of choice, restore the backed-up image data into a **target S3 storage `bucket` that is definitively accessible**. For example, restore it into a new bucket named `registry-bucket-restored`. Ensure you have write permissions to this target bucket. + +### Step 2: Update ModuleInfo Configuration +The key to recovery is updating the `ModuleInfo` resource of the new `cluster plugin` to point its S3 configuration to the target bucket containing the backup data. + +1. **Determine New S3 Connection Information**: + - `NEW_BUCKET`: The **target bucket name** where the backup data has been restored (e.g., registry-bucket-restored). + - `NEW_ENDPOINT`: The **endpoint of the target S3 service**. This remains unchanged if the S3 service address is the same as during backup. + - `NEW_REGION`: The **region of the target S3 service**. + - `NEW_SECRET_NAME`: The name of the Kubernetes Secret with read/write permissions to the **target bucket**. If the access keys are unchanged, this is still `$S3_SECRET_NAME`. + +2. **Update ModuleInfo Resource**: + + Use the `kubectl patch` command to directly update the S3 configuration section of the `ModuleInfo`. The platform controller will automatically synchronize this change to all relevant Deployment, Pod, and other resources. + + ```bash + # Execute the configuration update + kubectl patch moduleinfo $MODULE_INFO_NAME --type=merge -p '{ + "spec": { + "config": { + "s3storage": { + "bucket": "'"$NEW_BUCKET"'", + "regionEndpoint": "'"$NEW_ENDPOINT"'", + "region": "'"$NEW_REGION"'", + "secretName": "'"$NEW_SECRET_NAME"'" + } + } + } + }' + ``` + +**Key point**: This operation triggers a rolling update of the Registry Pods. Newly started Pods use the new configuration to connect to the specified target storage bucket. + +## Verification +After the update is complete, follow these steps to verify successful data recovery and normal service operation. + +### Check Module Status in the `global` Cluster + +```bash +# Check if Pods have successfully restarted and are running with the new configuration +kubectl get pods -n cpaas-system -l app=image-registry +# Observe Pod logs to confirm no S3 connection errors +kubectl logs -n cpaas-system -l app=image-registry -c registry --tail=50 +``` + +### Verify Data Access (API Test) +Use the Registry's API interface to directly verify it can read the restored image data. + +```bash +# Obtain the Registry Service access address (assuming ClusterIP type) +REGISTRY_SVC_IP=$(kubectl get svc -n cpaas-system image-registry -o jsonpath='{.spec.clusterIP}') + +# Test 1: Query the catalog of repositories +curl -s http://$REGISTRY_SVC_IP/v2/_catalog | jq . +# Expected success return: {"repositories":["image1","image2",...]} + +# Test 2: Query the tag list for a specific image (e.g., an image named `myns/nginx`) +curl -s http://$REGISTRY_SVC_IP/v2/myns/nginx/tags/list | jq . +# Expected success return: {"name":"myns/nginx","tags":["v1.0","latest",...]} +``` + +### Functionality Test +Attempt to pull a known image from the restored registry or push a new image to it to fully verify read/write functionality. + +## Other Storage Backends +This procedure uses S3 storage as the example. The same recovery model can apply to other storage backends supported by Registry, such as local file system, StorageClass, or NAS, when the corresponding backup and restore tools are available. + +Regardless of storage type, first extract storage connection parameters from the corresponding configuration block, such as `s3storage` or `persistence`, in the `ModuleInfo` resource. Then use the appropriate storage tools to back up data. During recovery, restore data to the target location and update the corresponding configuration fields in `ModuleInfo` so the newly deployed registry instance uses that location. diff --git a/docs/en/configure/registry/index.mdx b/docs/en/configure/registry/index.mdx new file mode 100644 index 000000000..2542ca1d8 --- /dev/null +++ b/docs/en/configure/registry/index.mdx @@ -0,0 +1,8 @@ +--- +weight: 70 +title: Registry Administration +--- + +# Registry Administration + + diff --git a/docs/en/developer/registry/install/index.mdx b/docs/en/configure/registry/install/index.mdx similarity index 100% rename from docs/en/developer/registry/install/index.mdx rename to docs/en/configure/registry/install/index.mdx diff --git a/docs/en/developer/registry/install/install_via_web_ui.mdx b/docs/en/configure/registry/install/install_via_web_ui.mdx similarity index 76% rename from docs/en/developer/registry/install/install_via_web_ui.mdx rename to docs/en/configure/registry/install/install_via_web_ui.mdx index fcd4a2365..a8a2f1318 100644 --- a/docs/en/developer/registry/install/install_via_web_ui.mdx +++ b/docs/en/configure/registry/install/install_via_web_ui.mdx @@ -2,10 +2,12 @@ weight: 16 --- -# Install Via Web UI +# Install by Using the Web Console + +## Use Cases + +Use the web console installation path for: -## When to Use This Method? -**Recommended for**: - **First-time users** who prefer a guided, visual interface. - **Quick proof-of-concept setups** in non-production environments. - Teams with **limited Kubernetes expertise** seeking a simplified deployment process. @@ -13,20 +15,18 @@ weight: 16 - **Basic networking setups** without specific ingress rules. - **StorageClass** configurations for high availability. -**Not Recommended for**: -- Production environments requiring advanced storage(S3 storage) configurations. -- Networking setups needing specific ingress rules. +Use the YAML installation path when you need advanced S3-compatible storage configuration or specific ingress rules. ## Prerequisites -- **Install** the **Alauda Container Platform Registry** cluster plugin to a target cluster using the [Cluster Plugin](/extend/cluster_plugin.mdx) mechanism. +- **Install** the ** Registry** Cluster Plugin to a target cluster using the [Cluster Plugin](/extend/cluster_plugin.mdx) mechanism. -## Installing Alauda Container Platform Registry cluster plugin using the web console +## Install Registry Using the Web Console ### Procedure 1. Log in and navigate to the **Administrator** page. 2. Click **Marketplace** > **Cluster Plugins** to access the **Cluster Plugins** list page. -3. Locate the **Alauda Container Platform Registry** cluster plugin, click **Install**, then proceed to the installation page. +3. Locate the ** Registry** Cluster Plugin, click **Install**, then proceed to the installation page. 4. Configure parameters according to the following specifications and click **Install** to complete the deployment. The parameter descriptions are as follows: @@ -49,6 +49,6 @@ The parameter descriptions are as follows: 2. Click the plugin name to view its details. 3. Copy the **Registry Address** and use a container client (e.g., Podman) to push/pull images. -## Updating/Uninstalling Alauda Container Platform Registry +## Update Or Uninstall Registry -You can update or uninstall the **Alauda Container Platform Registry** plugin from either the list page or details page. +You can update or uninstall the ** Registry** plugin from either the list page or details page. diff --git a/docs/en/developer/registry/install/install_via_yaml.mdx b/docs/en/configure/registry/install/install_via_yaml.mdx similarity index 86% rename from docs/en/developer/registry/install/install_via_yaml.mdx rename to docs/en/configure/registry/install/install_via_yaml.mdx index 834e7e964..f9a7b908a 100644 --- a/docs/en/developer/registry/install/install_via_yaml.mdx +++ b/docs/en/configure/registry/install/install_via_yaml.mdx @@ -2,27 +2,27 @@ weight: 15 --- -# Install Via YAML +# Install by Using YAML -## When to Use This Method? +## Use Cases -**Recommended for**: +Use YAML installation for: - **Advanced users** with Kubernetes expertise who prefer a manual approach. -- **Production-grade deployments** requiring enterprise storage (NAS, AWS S3, Ceph, etc.). -- Environments needing **fine-grained control** over TLS, ingress. +- Deployments that require externally managed storage, such as NAS, S3-compatible object storage, or Ceph. +- Environments needing **fine-grained control** over TLS and ingress. - **Full YAML customization** for advanced configurations. ## Prerequisites -- **Install** the **Alauda Container Platform Registry** cluster plugin to a target cluster. +- **Install** the ** Registry** Cluster Plugin to a target cluster. - **Access** to the target Kubernetes cluster with kubectl configured. - **Cluster admin permissions** to create cluster-scoped resources. -- Obtain a registered **domain** (e.g., registry.yourcompany.com) [Create a Domain](/configure/networking/functions/configure_domain.mdx) -- Provide valid **NAS storage** (e.g., NFS, GlusterFS, etc.). -- (Optional) Provide valid **S3 storage** (e.g., AWS S3, Ceph, MinIO, etc.). +- Obtain a registered **domain**, such as `registry.example.com`. For domain configuration, see [Create a Domain](/networking/functions/configure_domain.mdx). +- Provide valid **NAS storage**, such as NFS. +- Optional: Provide valid **S3-compatible storage**. -## Installing Alauda Container Platform Registry via YAML +## Install Registry Using YAML ### Procedure @@ -111,7 +111,7 @@ weight: 15 bucket: '' # e.g., prod-registry region: '' # e.g., us-west-1 regionEndpoint: '' # e.g., https://s3.amazonaws.com - secretName: '' # Secret containing AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY + secretName: '' # Secret containing S3 access credentials env: REGISTRY_STORAGE_S3_SKIPVERIFY: 'true' # Set "true" for self-signed certs ``` @@ -146,8 +146,8 @@ weight: 15 | `spec.config.persistence.size` | Storage size for the registry | `10Gi` | | `spec.config.persistence.storageClass` | StorageClass name for the registry | `nfs-storage-sc` | | `spec.config.s3storage.bucket` | S3 bucket name for image storage | `prod-image-store` | -| `spec.config.s3storage.region` | AWS region for S3 storage | `us-west-1` | -| `spec.config.s3storage.regionEndpoint` | S3 service endpoint URL | `https://s3.amazonaws.com` | +| `spec.config.s3storage.region` | Region identifier for S3-compatible storage | `us-west-1` | +| `spec.config.s3storage.regionEndpoint` | S3-compatible service endpoint URL | `https://s3.example.com` | | `spec.config.s3storage.secretName` | Secret containing S3 credentials | `s3-access-keys` | | `spec.config.s3storage.env.REGISTRY_STORAGE_S3_SKIPVERIFY` | Set to `true` for self-signed certs | `true` | | `spec.config.infra.enabled` | Deploy components to infra nodes or all nodes | `false` | @@ -163,7 +163,7 @@ weight: 15 kubectl get pods -n cpaas-system -l app=image-registry ``` -## Updating/Uninstalling Alauda Container Platform Registry +## Update Or Uninstall Registry ### Update diff --git a/docs/en/configure/registry/overview.mdx b/docs/en/configure/registry/overview.mdx new file mode 100644 index 000000000..3e4186efe --- /dev/null +++ b/docs/en/configure/registry/overview.mdx @@ -0,0 +1,22 @@ +--- +weight: 10 +--- + +# Overview + + Registry provides a platform-managed image registry for storing and serving container images used by platform components and application workloads. Platform administrators install, upgrade, expose, and recover the registry as a cluster plugin. Developers and application teams use the registry through developer image workflows. + +## Administration scope + +| Need | Continue with | +| --- | --- | +| Install the registry cluster plugin. | [Install](./install/index.mdx) | +| Upgrade the registry cluster plugin. | [Upgrade](./upgrade/index.mdx) | +| Back up or recover registry data. | [Registry backup and recovery](./backup_and_restore.mdx) | +| Use images in workloads or developer workflows. | [Images](../../developer/images/overview.mdx) and [registry image use](../../developer/registry/index.mdx) | + +## Namespace isolation and access + +Registry image repositories are organized by namespace. Pull and push access depends on the platform roles and permissions granted to users or ServiceAccounts in the target namespace. + +For common image usage commands and cross-namespace pull access, see [Registry image use](../../developer/registry/index.mdx). diff --git a/docs/en/developer/registry/upgrade/index.mdx b/docs/en/configure/registry/upgrade/index.mdx similarity index 100% rename from docs/en/developer/registry/upgrade/index.mdx rename to docs/en/configure/registry/upgrade/index.mdx diff --git a/docs/en/developer/registry/upgrade/registry_plugin_upgrade_guide.mdx b/docs/en/configure/registry/upgrade/registry_plugin_upgrade_guide.mdx similarity index 85% rename from docs/en/developer/registry/upgrade/registry_plugin_upgrade_guide.mdx rename to docs/en/configure/registry/upgrade/registry_plugin_upgrade_guide.mdx index 934114532..3072ff265 100644 --- a/docs/en/developer/registry/upgrade/registry_plugin_upgrade_guide.mdx +++ b/docs/en/configure/registry/upgrade/registry_plugin_upgrade_guide.mdx @@ -1,20 +1,16 @@ --- weight: 70 -i18n: - title: - en: Alauda Container Platform Registry Upgrade Guide - zh: Alauda Container Platform Registry 升级指南 --- -# Alauda Container Platform Registry Upgrade Guide +# Upgrade Registry ## Prerequisites -1. Administrator privileges for the Alauda Container Platform. -2. The old plugin refers to versions of Alauda Container Platform v4.1 (inclusive) and earlier. -3. The new plugin refers to versions of Alauda Container Platform v4.2 (inclusive) and later. +1. Administrator privileges for . +2. The old plugin refers to versions of v4.1 and earlier. +3. The new plugin refers to versions of v4.2 and later. ## Overview -This document provides instructions for upgrading the `Old Plugin` to `New Plugin`. Due to the name of cluster plugin change, manual intervention is required based on **storage type**. +Upgrade the old registry plugin to the new registry plugin according to the registry storage type. Because the Cluster Plugin name changed, manual intervention is required. ## Upgrade Steps diff --git a/docs/en/configure/scalability/disk_configuration.mdx b/docs/en/configure/scalability/disk_configuration.mdx index 678c1abed..888821dd5 100644 --- a/docs/en/configure/scalability/disk_configuration.mdx +++ b/docs/en/configure/scalability/disk_configuration.mdx @@ -35,7 +35,7 @@ The following hard drive practices provide optimal etcd performance: - Keep etcd data on a dedicated drive or a dedicated logical volume. - Do not place I/O-sensitive (such as logging) or other intensive filesystem activity on control-plane hosts, or at least do not let them share the same underlying storage with etcd. -- Continuously benchmark with tools like `fio` and use the results to track performance as the cluster grows. Refer to the [disk benchmarking guide](#benchmark_with_fio) for more information. +- Continuously benchmark with tools like `fio` and use the results to track performance as the cluster grows. For more information, see the [disk benchmarking guide](#benchmark_with_fio). ::: ### Validating the hardware for etcd @@ -48,7 +48,7 @@ The following hard drive practices provide optimal etcd performance: #### Benchmarking with fio \{#benchmark_with_fio} -To measure actual sequential IOPS and throughput, we suggest using the disk benchmarking tool `fio`. You may refer to the following instructions: +To measure actual sequential IOPS and throughput, use the disk benchmarking tool `fio`: :::warning Do not run these tests against any nodes of the clusters. diff --git a/docs/en/configure/scalability/evaluating_global.mdx b/docs/en/configure/scalability/evaluating_global.mdx index f52a7bca7..802ce2186 100644 --- a/docs/en/configure/scalability/evaluating_global.mdx +++ b/docs/en/configure/scalability/evaluating_global.mdx @@ -7,20 +7,20 @@ title: Evaluating Resources for Global Cluster ## Overview -This topic provides recommended practices and resource evaluation guidelines for Multi-Cluster in . +Use these resource evaluation practices when planning the `global` cluster for a Multi-Cluster deployment. -Proper node sizing ensures the global cluster can efficiently manage all registered clusters, handle synchronization traffic, and process user API and Web Console requests without performance degradation. +Proper node sizing helps the `global` cluster manage registered clusters, handle synchronization traffic, and process user API and Web Console requests within the performance expectations of your environment. ## Node Sizing -The Global cluster is responsible for: +The `global` cluster is responsible for: - Maintaining cluster registration and metadata. - Handling inbound API requests from the Web Console and CLI. -- Coordinating synchronization and heartbeat messages with managed clusters. +- Coordinating synchronization and heartbeat messages with connected clusters. - Managing internal controllers and resource reconciliation loops. -Because the Global Cluster must handle both **management operations** and **data aggregation** from all connected clusters, resource allocation should be planned according to the expected scale and workload intensity. +Because the `global` cluster handles both management operations and data aggregation from all connected clusters, plan resource allocation according to the expected scale and workload intensity. ### Baseline Production Sizing @@ -109,11 +109,11 @@ After deployment, continuously monitor the following metrics to validate node si ## Summary -When sizing the Global Cluster: +When sizing the `global` cluster: 1. Begin with **3 nodes × 16 cores × 32 GB** for moderate-scale deployments (≤50 clusters). 2. Scale **vertically** for higher request concurrency or heavy Web Console usage. 3. Scale **horizontally** beyond 100 clusters to maintain API responsiveness. 4. Re-evaluate sizing after every significant increase in managed cluster count or sync frequency. -Following these guidelines ensures predictable performance and operational stability as your Multi-Cluster environment grows. +Use these practices to keep resource planning aligned with the growth of your Multi-Cluster environment. diff --git a/docs/en/configure/scalability/evaluating_workload.mdx b/docs/en/configure/scalability/evaluating_workload.mdx index 9f79f1298..5f48559df 100644 --- a/docs/en/configure/scalability/evaluating_workload.mdx +++ b/docs/en/configure/scalability/evaluating_workload.mdx @@ -3,13 +3,14 @@ weight: 10 title: Evaluating Resources for Workload Cluster --- +# Evaluating Resources for Workload Cluster + ## Recommended Control Plane Practices -This topic provides recommended performance and scalability practices for control planes in . +Use these practices to plan workload cluster control-plane resources in . :::info -All the following requirements are based on the minimum set up of , which is the installation of a core packages. -In practice, the actual requirements may be higher, please refer to the instructions of extensions for detailed additional resources requirements. +The following requirements are based on the minimum setup with Core packages installed. Actual requirements might be higher when Extensions are installed. Read the Extension-specific guidance for additional resource requirements. ::: ### Control Plane Node Sizing @@ -27,7 +28,7 @@ Control plane sizing needs change with the cluster's node count, node types, and | 120 | 1000 | 8 | 32 | | 254 | 4000 | 24 | 128 | -The data from the table above is based on an environment installed on AWS, using r5.4xlarge instances (which is 16 vCPUs, 128 GB RAM) as control-plane nodes and m5.2xlarge instances (which is 8 vCPUs, 32 GB RAM) as worker nodes. +The data from the table above is based on a environment installed on public-cloud virtual machines, using 16 vCPU and 128 GB RAM control-plane nodes and 8 vCPU and 32 GB RAM worker nodes. On large, dense clusters with three control-plane nodes, taking one node offline—whether due to unexpected issues like power or network failures, infrastructure problems, or an intentional shutdown to save costs—forces the remaining two nodes to handle the extra work. When that occurs, CPU and memory usage on the surviving control-plane machines can rise significantly. You will also see this pattern during upgrades, because control-plane nodes are typically cordoned, drained, and rebooted one after another while control-plane Operators are updated. That sequential maintenance concentrates demand on the nodes that remain active. @@ -42,7 +43,7 @@ The node sizing varies depending on the number of nodes and object counts in the :::warning Overcommitting a node's physical resources can weaken the scheduling guarantees that Kubernetes relies on. Apply controls such as resource requests and limits, QoS classes, and node tuning to minimize memory swapping and other resource contention. -The figures in this document come from Alauda's specific configuration, methodology, and tuning. Instead of presenting fixed caps, the following entries list the maximums observed for under the tested conditions. +The figures come from test configuration, methodology, and tuning. Instead of presenting fixed caps, the following entries list the maximums observed for under the tested conditions. Since the combinations of version, control-plane workload, and network plugin is unlimited, these values are not guaranteed limits for all deployments and may not be simultaneously achievable across all dimensions. Use them as guidance when planning deployments with similar characteristics. ::: @@ -71,7 +72,7 @@ If a large number of objects need eviction, the API client may begin to rate-lim | Number of deployments per namespace [4] | 2,000 | | Number of custom resource definitions (CRD) | 1,024 [5] | -1. supports clusters with more than 500 nodes, the number here is the recommended maximums. If your use-cases need larger clusters, please get in touch with our technical support. +1. supports clusters with more than 500 nodes; the number here is the recommended maximum. If your use case needs larger clusters, contact technical support. 2. The pod numbers shown are counts from the test environment. Actual pod capacity will vary according to each application's memory, CPU, and storage requirements. 3. With many active projects, etcd performance can degrade if the keyspace grows too large and surpasses its space quota. Regular etcd maintenance—such as defragmentation—is recommended to reclaim storage and avoid performance issues. 4. Several control loops iterate over all objects in a namespace in response to state changes. A very large number of objects of a single type within one namespace makes those loops expensive and can slow processing. The stated limit assumes the system has sufficient CPU, memory, and disk to meet application needs. @@ -79,7 +80,7 @@ If a large number of objects need eviction, the API client may begin to rate-lim ### Examples -As an example, 500 worker nodes (sized m5.2xlarge, which is 8 vCPUs and 32 GB of memory) were tested, and are supported, using 4.1, the Kube-OVN network plugin, and the following workload objects: +In one test scenario, 500 worker nodes, each with 8 vCPUs and 32 GB of memory, were tested with 4.1, the Kube-OVN network plugin, and the following workload objects: - 200 namespaces, in addition to the defaults - 60 pods per node; 30 server and 30 client pods (30k total) @@ -88,7 +89,7 @@ As an example, 500 worker nodes (sized m5.2xlarge, which is 8 vCPUs and 32 GB of - 10 config maps/ns (2k total) - 6 network policies/ns, including deny-all, allow-from ingress and intra-namespace rules -The following factors are known to affect cluster workload scaling, positively or negatively, and should be factored into the scale numbers when planning a deployment. For additional information and guidance, please contact our technical support team. +The following factors are known to affect cluster workload scaling and should be factored into scale planning. For additional guidance, contact technical support. - Number of pods per node - Number of containers per pod diff --git a/docs/en/configure/scalability/large_clusters_stability.mdx b/docs/en/configure/scalability/large_clusters_stability.mdx index b15bf6a01..c61c162a9 100644 --- a/docs/en/configure/scalability/large_clusters_stability.mdx +++ b/docs/en/configure/scalability/large_clusters_stability.mdx @@ -3,11 +3,13 @@ weight: 20 title: Improving Kubernetes Stability for Large-Scale Clusters --- -This guide helps cluster operators and SREs reduce control-plane overload, improve reliability, and limit blast radius in large-scale Kubernetes clusters. +# Improving Kubernetes Stability for Large-Scale Clusters + +Cluster operators and SREs can use these practices to reduce control-plane overload, improve reliability, and limit blast radius in large-scale Kubernetes clusters. ## Notes -- Network, storage, load‑balancer, logging and monitoring tuning are out of scope; see vendor docs for those components. +- For network, storage, load-balancer, logging, and monitoring tuning, use the component-specific guidance for those capabilities. :::warning - Test configuration changes before production. diff --git a/docs/en/configure/scalability/overview.mdx b/docs/en/configure/scalability/overview.mdx new file mode 100644 index 000000000..10b5d01c4 --- /dev/null +++ b/docs/en/configure/scalability/overview.mdx @@ -0,0 +1,18 @@ +--- +weight: 1 +--- + +# Overview + +Use Scalability and performance to plan cluster scale, resource allocation, and performance-sensitive workload placement. This area collects scale evaluation, disk configuration, resource manager policies, and large-cluster stability guidance. + +| Need | Continue with | +| --- | --- | +| Evaluate workload cluster scale. | [Evaluate workload clusters](./evaluating_workload.mdx) | +| Evaluate `global` cluster scale. | [Evaluate global clusters](./evaluating_global.mdx) | +| Configure CPU, memory, and topology manager policies. | [Resource manager policies](./resource_manager_policies.mdx) | +| Review large-cluster stability guidance. | [Large clusters stability](./large_clusters_stability.mdx) | +| Configure disk-related performance settings. | [Disk configuration](./disk_configuration.mdx) | +| Plan infra nodes or custom role nodes. | [Node planning](../nodes/node_planning.mdx) | + +For validated scale limits, sizing formulas, or production hardening requirements, follow the current support matrix and topic-specific guidance. diff --git a/docs/en/configure/clusters/how-to/config_resource_manager_policy.mdx b/docs/en/configure/scalability/resource_manager_policies.mdx similarity index 94% rename from docs/en/configure/clusters/how-to/config_resource_manager_policy.mdx rename to docs/en/configure/scalability/resource_manager_policies.mdx index 7c8c90e84..50c3bc37e 100644 --- a/docs/en/configure/clusters/how-to/config_resource_manager_policy.mdx +++ b/docs/en/configure/scalability/resource_manager_policies.mdx @@ -4,7 +4,7 @@ title: Optimize Pod Performance with Manager Policies --- # Optimize Pod Performance with Manager Policies -This guide provides Kubernetes cluster administrators with a practical, ready-to-apply manual for enabling and validating **CPU ManagerPolicy**, **Memory ManagerPolicy**, and **Topology ManagerPolicy**. By aligning CPU pinning, NUMA affinity, and topology alignment, you can deliver consistent latency and improved performance for critical workloads. +Kubernetes cluster administrators can enable and validate **CPU ManagerPolicy**, **Memory ManagerPolicy**, and **Topology ManagerPolicy** to align CPU pinning, NUMA affinity, and topology placement for latency-sensitive workloads. ## Scope and Prerequisites diff --git a/docs/en/configure/storage/concepts/key_concepts.mdx b/docs/en/configure/storage/concepts/key_concepts.mdx index 2662cea99..01bdecc03 100644 --- a/docs/en/configure/storage/concepts/key_concepts.mdx +++ b/docs/en/configure/storage/concepts/key_concepts.mdx @@ -1,6 +1,6 @@ # Core Concepts -Kubernetes storage is centered on three key concepts: **PersistentVolume (PV)**, **PersistentVolumeClaim (PVC)**, and **StorageClass**. These define how storage is requested, allocated, and configured within a cluster. Under the hood, **CSI** (Container Storage Interface) drivers frequently handle the actual provisioning and attachment of storage. Let's briefly look at each component and then highlight the CSI Driver's role. +Kubernetes storage is centered on three key concepts: **PersistentVolume (PV)**, **PersistentVolumeClaim (PVC)**, and **StorageClass**. These define how storage is requested, allocated, and configured within a cluster. **CSI** (Container Storage Interface) drivers often handle the actual provisioning and attachment of storage. ## Persistent Volume (PV) @@ -14,7 +14,7 @@ A **PersistentVolumeClaim (PVC)** is a request for storage. Users define how muc Generic Ephemeral Volumes for Kubernetes is a feature introduced in Kubernetes that allows you to use CSI-driven `temporary` volumes during the Pod lifecycle, similar to the This is similar to `emptyDir`, but is more powerful and allows you to mount any type of CSI volume (with support for snapshots, scaling, etc.). -For more usage, please refer to [Generic ephemeral volumes](../how_to/generic_ephemeral_volumes.mdx) +For usage details, see [Generic ephemeral volumes](../how_to/generic_ephemeral_volumes.mdx). ## emptyDir @@ -24,7 +24,7 @@ For more usage, please refer to [Generic ephemeral volumes](../how_to/generic_ep 3. When a Pod is deleted, the data in emptyDir is also erased. -For more usage, please refer to [Using an emptyDir](../how_to/using_empty_dir.mdx) +For usage details, see [Using an emptyDir](../how_to/using_empty_dir.mdx). ## hostPath diff --git a/docs/en/configure/storage/cosi/cosi-concepts.mdx b/docs/en/configure/storage/cosi/cosi-concepts.mdx index 040f426f1..5452663f3 100644 --- a/docs/en/configure/storage/cosi/cosi-concepts.mdx +++ b/docs/en/configure/storage/cosi/cosi-concepts.mdx @@ -6,9 +6,9 @@ weight: 20 ## Overview -This document introduces Kubernetes administrators familiar with persistent storage concepts to the core resources and principles of the Container Object Storage Interface (COSI). COSI provides a declarative mechanism for managing object storage such as Ceph RGW, similar to existing Kubernetes persistent storage management approaches. +Kubernetes administrators who are familiar with persistent storage concepts can use Container Object Storage Interface (COSI) resources to manage object storage through declarative Kubernetes APIs. COSI provides a declarative mechanism for managing object storage, similar to existing Kubernetes persistent storage management approaches. -We will cover the three primary resources in COSI—**BucketClass, Bucket, and BucketClaim**—drawing analogies with Kubernetes storage resources to clarify their relationships and functionalities. +COSI uses three primary resources: **BucketClass**, **Bucket**, and **BucketClaim**. ## Core Resources @@ -46,7 +46,7 @@ parameters: **Scope:** Cluster-scoped **Analogous Kubernetes Concept:** Similar to PersistentVolume (PV) -Bucket represents an abstraction of an actual bucket present in an external object storage system such as Ceph RGW within Kubernetes. +Bucket represents a Kubernetes abstraction of an actual bucket in an external object storage system. Lifecycle management: diff --git a/docs/en/configure/storage/cosi/functions/bucket_class_ceph.mdx b/docs/en/configure/storage/cosi/functions/bucket_class_ceph.mdx index 7563165d1..8ae847a27 100644 --- a/docs/en/configure/storage/cosi/functions/bucket_class_ceph.mdx +++ b/docs/en/configure/storage/cosi/functions/bucket_class_ceph.mdx @@ -4,7 +4,7 @@ weight: 10 # Creating a BucketClass for Ceph RGW -Ceph Object Storage can be exposed to Kubernetes workloads via the **Container Object Storage Interface (COSI)**, providing highly scalable and elastic storage for big‑data analytics, backup & restore, and machine‑learning scenarios. A *BucketClass* is required before users can provision buckets. +Ceph Object Storage can be exposed to Kubernetes workloads through the **Container Object Storage Interface (COSI)**, providing object storage for big-data analytics, backup and restore, and machine-learning scenarios. A *BucketClass* is required before users can provision buckets. A **BucketClass** is a template resource that specifies the storage driver, authentication secret, and the deletion policy that will be applied to every bucket created from it. @@ -14,7 +14,7 @@ A **BucketClass** is a template resource that specifies the storage driver, auth | Requirement | Notes | | ------------------------------------------------- | ------------------------------------------------------------ | | Running Ceph cluster with RGW (S3) enabled | Internal (Rook-managed) or external cluster is acceptable. | -| Alauda Container Platform COSI plug‑ins | Both **Alauda Container Platform COSI** *and* **Alauda Container Platform COSI for Ceph** must be installed. | +| COSI plug-ins | Both ** COSI** and ** COSI for Ceph** must be installed. | | Kubernetes Secret containing Ceph RGW credentials | Prepared in **Step 3** below. | ## Step 1 – Prepare a Ceph Cluster @@ -30,10 +30,10 @@ Choose **one** of the following: Install the following cluster plug‑ins: -1. **Alauda Container Platform COSI** -2. **Alauda Container Platform COSI for Ceph** +1. ** COSI** +2. ** COSI for Ceph** -> Refer to *[Installing](/configure/storage/cosi/install.mdx)* for exact commands. +> For exact commands, see *[Installing](/configure/storage/cosi/install.mdx)*. ## Step 3 – Prepare the Credential Secret diff --git a/docs/en/configure/storage/cosi/functions/bucket_request.mdx b/docs/en/configure/storage/cosi/functions/bucket_request.mdx index 3690ad203..81c674c24 100644 --- a/docs/en/configure/storage/cosi/functions/bucket_request.mdx +++ b/docs/en/configure/storage/cosi/functions/bucket_request.mdx @@ -8,8 +8,8 @@ Use a **Bucket Request** to dynamically create a bucket based on an **Object St ## Prerequisites -* **Install** the **Alauda Container Platform COSI** cluster. -* **Install** the **Alauda Container Platform COSI for Ceph** cluster plugin package. +* **Install** the ** COSI** cluster plugin. +* **Install** the ** COSI for Ceph** cluster plugin package. For detailed installation steps, see **[Installing](/configure/storage/cosi/install.mdx)**. diff --git a/docs/en/configure/storage/cosi/how_to/access_control_ceph.mdx b/docs/en/configure/storage/cosi/how_to/access_control_ceph.mdx index 5826b2469..9f64cda10 100644 --- a/docs/en/configure/storage/cosi/how_to/access_control_ceph.mdx +++ b/docs/en/configure/storage/cosi/how_to/access_control_ceph.mdx @@ -1,6 +1,6 @@ # Control Access & Quotas for COSI Buckets with CephObjectStoreUser (Ceph Driver) -This guide shows Kubernetes administrators how to combine **CephObjectStoreUser (COSU)**, **BucketClass/BucketClaim**, and **BucketAccessClass/BucketAccess** to implement **least-privileged access** and **quota enforcement** for Ceph RGW-backed COSI buckets. +Kubernetes administrators can combine **CephObjectStoreUser (COSU)**, **BucketClass/BucketClaim**, and **BucketAccessClass/BucketAccess** to implement **least-privileged access** and **quota enforcement** for Ceph RGW-backed COSI buckets. > **What you'll build** > diff --git a/docs/en/configure/storage/cosi/install.mdx b/docs/en/configure/storage/cosi/install.mdx index 9282ab577..ee17e6f69 100644 --- a/docs/en/configure/storage/cosi/install.mdx +++ b/docs/en/configure/storage/cosi/install.mdx @@ -6,31 +6,31 @@ weight: 25 ## Prerequisites -1. **Download** the **Alauda Container Platform COSI** cluster plugin package corresponding to your platform architecture. -2. **Download** the **Alauda Container Platform COSI for Ceph** cluster plugin package. +1. **Download** the ** COSI** Cluster Plugin package corresponding to your platform architecture. +2. **Download** the ** COSI for Ceph** Cluster Plugin package. 3. **Upload** the downloaded plugin packages using the **Upload Packages** feature. 4. **Install** the plugin packages to the target cluster using the **Cluster Plugins** installation mechanism. :::info Upload Packages: **Platform Management** > **Marketplace** > **Upload Packages** page. -Click **Help Document** on the right to get instructions on how to publish the cluster plugin to the cluster which you want to use. For more details, please refer to [CLI](/ui/cli_tools/index.mdx). +Click **Help Document** on the right for instructions about publishing the Cluster Plugin to the target cluster. For CLI guidance, see [CLI](/ui/cli_tools/index.mdx). ::: -## Installing Alauda Container Platform COSI +## Install COSI ### Constraints and Limitations * Plugins are scoped to the current cluster only. You must install the required plugins individually on each cluster where you want to enable COSI features. -* The **Alauda Container Platform COSI for Ceph** plugin depends on the **Alauda Container Platform COSI** plugin. Ensure that the **Alauda Container Platform COSI** plugin is installed first. +* The ** COSI for Ceph** plugin depends on the ** COSI** plugin. Ensure that the ** COSI** plugin is installed first. ### Procedure 1. Log in to the platform and navigate to the **Platform Management** page. 2. Go to **Marketplace** > **Cluster Plugins** to access the list of available cluster plugins. 3. Select the target cluster where you want to install the plugins. -4. Locate the **Alauda Container Platform COSI** plugin and select **Install** from the **⋮** menu to start the installation. -5. Locate and install the **Alauda Container Platform COSI for Ceph** plugin. +4. Locate the ** COSI** plugin and select **Install** from the **⋮** menu to start the installation. +5. Locate and install the ** COSI for Ceph** plugin. 6. Wait until the status of all plugins changes to **Installed**. ## Uninstallation @@ -41,4 +41,4 @@ Click **Help Document** on the right to get instructions on how to publish the c 4. Locate the plugin you want to uninstall and select **Uninstall** from the **⋮** menu to start the uninstallation process. 5. Wait until the plugin status changes to **Ready**, indicating that it can be reinstalled if required. -**Important:** Before uninstalling the **Alauda Container Platform COSI** plugin, you must first uninstall the **Alauda Container Platform COSI for Ceph** plugin. +**Important:** Before uninstalling the ** COSI** plugin, you must first uninstall the ** COSI for Ceph** plugin. diff --git a/docs/en/configure/storage/cosi/intro.mdx b/docs/en/configure/storage/cosi/intro.mdx index 869436005..7a1fcb296 100644 --- a/docs/en/configure/storage/cosi/intro.mdx +++ b/docs/en/configure/storage/cosi/intro.mdx @@ -4,7 +4,7 @@ weight: 10 # Introduction -The Container Object Storage Interface (COSI) is a Kubernetes-native framework designed to provide a standardized and declarative approach for managing object storage services such as Ceph RGW within Kubernetes clusters. COSI extends Kubernetes' storage model to support object storage resources in a way that is portable, scalable, and consistent with the principles of Kubernetes. +The Container Object Storage Interface (COSI) is a Kubernetes-native framework for managing object storage services through standardized and declarative APIs. COSI extends the Kubernetes storage model so workloads can request object storage resources through Kubernetes-style objects. COSI enables administrators to define, provision, and consume object storage buckets through familiar Kubernetes-style APIs. It simplifies integration between applications and backend object storage systems, automating the lifecycle of buckets and their access credentials. With COSI, Kubernetes users can request object storage resources dynamically, reducing manual configuration overhead and improving operational efficiency. diff --git a/docs/en/configure/storage/functions/cephfs_storageclass.mdx b/docs/en/configure/storage/functions/cephfs_storageclass.mdx index 744ca2385..db96c255a 100644 --- a/docs/en/configure/storage/functions/cephfs_storageclass.mdx +++ b/docs/en/configure/storage/functions/cephfs_storageclass.mdx @@ -31,7 +31,7 @@ After clicking **Deploy** on the **Distributed Storage** page, choose either [De | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Reclaim Policy** | The reclaim policy for persistent volumes.
- Delete: When the persistent volume claim is deleted, the bound persistent volume will also be deleted.
- Retain: The bound persistent volume will remain, even if the persistent volume claim is deleted. | | **Access Modes** | All access modes supported by the current storage. Only one of these modes can be selected when declaring persistent volumes later.
- ReadWriteOnce (RWO): Can be mounted as read-write by a single node.
- ReadWriteMany (RWX): Can be mounted as read-write by multiple nodes. | - | **Allocate Project** | Please allocate projects that can use this type of storage.
If there are currently no projects that need to use this type of storage, you may choose not to allocate them for now and update later. | + | **Allocate Project** | Allocate the projects that can use this type of storage.
If no project currently needs this type of storage, leave the allocation empty and update it later. | **Tip**: The following parameters need to be set in the distributed storage and will be applied directly here. diff --git a/docs/en/configure/storage/functions/cephrbd_storageclass.mdx b/docs/en/configure/storage/functions/cephrbd_storageclass.mdx index 2bd02e13f..bb244f87d 100644 --- a/docs/en/configure/storage/functions/cephrbd_storageclass.mdx +++ b/docs/en/configure/storage/functions/cephrbd_storageclass.mdx @@ -32,7 +32,7 @@ After clicking **Deploy** on the **Distributed Storage** page, choose either [De | **File System** | Defaults to **EXT4**, which is a journaling file system for Linux, capable of providing extent file storage and processing large files. The filesystem capacity can reach 1 EiB, with supported file sizes up to 16 TiB. | | **Reclaim Policy** | The reclaim policy for persistent volumes.
- Delete: The bound persistent volume will be deleted along with the persistent volume claim.
- Retain: The bound persistent volume will be retained even if the persistent volume claim is deleted. | | **Access Modes** | Only supports ReadWriteOnce (RWO): it can be mounted by a single node in read-write mode. | - | **Assign Project** | Please assign projects that can use this type of storage.
If there are no projects currently needing this type of storage, you can choose not to assign one and update it later. | + | **Assign Project** | Assign the projects that can use this type of storage.
If no project currently needs this type of storage, leave the assignment empty and update it later. | **Tip**: The following parameters need to be set in distributed storage and will be directly applied here. diff --git a/docs/en/configure/storage/functions/create_pv.mdx b/docs/en/configure/storage/functions/create_pv.mdx index 94d257b99..eb7d5e104 100644 --- a/docs/en/configure/storage/functions/create_pv.mdx +++ b/docs/en/configure/storage/functions/create_pv.mdx @@ -54,7 +54,7 @@ spec: 3. Click on **Create Persistent Volume**. -4. Refer to the instructions below and configure the parameters before clicking **Create**. +4. Configure the parameters below, and then click **Create**. ### Storage Information diff --git a/docs/en/configure/storage/functions/create_pvc.mdx b/docs/en/configure/storage/functions/create_pvc.mdx index 42da03093..27eef236a 100644 --- a/docs/en/configure/storage/functions/create_pvc.mdx +++ b/docs/en/configure/storage/functions/create_pvc.mdx @@ -71,9 +71,9 @@ kubectl apply -f example-pvc.yaml - **Bind PersistentVolumeClaim**: When creating applications or workloads that require persistent data storage, bind the PersistentVolumeClaim to request a compliant PersistentVolume. -- **Create a PersistentVolumeClaim using Volume Snapshots**: This helps to back up application data and restore it as needed, ensuring the reliability of business application data. Please refer to [Using Volume Snapshots](./using_volume_snapshot.mdx). +- **Create a PersistentVolumeClaim using Volume Snapshots**: Use volume snapshots to back up application data and restore it when needed. For details, see [Using Volume Snapshots](./using_volume_snapshot.mdx). -- **Delete PersistentVolumeClaim**: You can click the **Actions** button in the top right corner of the details page to delete the PersistentVolumeClaim as needed. Before deleting, please ensure that the PersistentVolumeClaim is not bound to any applications or workloads and that it does not contain any volume snapshots. After deleting the PersistentVolumeClaim, the platform will process the PersistentVolume according to the reclamation policy, which may clear data in the PersistentVolume and free storage resources. Please proceed with caution based on data security considerations. +- **Delete PersistentVolumeClaim**: Click the **Actions** button in the upper-right corner of the details page to delete the PersistentVolumeClaim. Before deleting it, ensure that the PersistentVolumeClaim is not bound to applications or workloads and does not contain volume snapshots. After deletion, the platform processes the PersistentVolume according to the reclamation policy, which might clear data in the PersistentVolume and free storage resources. Confirm data security requirements before deleting a PersistentVolumeClaim. ## Expanding PersistentVolumeClaim Storage Capacity by using the web console @@ -83,7 +83,7 @@ kubectl apply -f example-pvc.yaml 3. Fill in the new capacity. -4. Click Expand. The expansion process may take some time, please be patient. +4. Click **Expand**. The expansion process might take some time. ## Expanding Persistent Volume Claim Storage Capacity by using the CLI diff --git a/docs/en/configure/storage/functions/nfs_storageclass.mdx b/docs/en/configure/storage/functions/nfs_storageclass.mdx index a99203a38..0cd91d288 100644 --- a/docs/en/configure/storage/functions/nfs_storageclass.mdx +++ b/docs/en/configure/storage/functions/nfs_storageclass.mdx @@ -13,7 +13,7 @@ Unlike the traditional client-server model of NFS access, NFS shared storage uti - An NFS server must be configured, and its access methods must be obtained. Currently, the platform supports three NFS protocol versions: `v3`, `v4.0`, and `v4.1`. You can execute `nfsstat -s` on the server side to check the version information. -## Deploying the Alauda Container Platform NFS CSI plugin +## Deploy NFS CSI ### Deploying via Web Console 1. Enter **Administrator**. @@ -24,15 +24,15 @@ Unlike the traditional client-server model of NFS access, NFS shared storage uti 4. On the right side of **NFS CSI**, click Deploy to navigate to the **Plugins** page. -5. On the right side of the `Alauda Container Platform NFS CSI` plugin, click ⋮ > **Install**. +5. On the right side of the ** NFS CSI** plugin, click ⋮ > **Install**. 6. Wait for the deployment status to indicate **Deployment Successful** before completing the deployment. ### Deploying via YAML -Refs to [Installing via YAML](../../../extend/cluster_plugin.mdx#installing-via-yaml) +For YAML installation, see [Installing via YAML](../../../extend/cluster_plugin.mdx#installing-via-yaml). -`Alauda Container Platform NFS CSI` is a **Non-config plugin**, and the module-name is `nfs` +** NFS CSI** is a **Non-config plugin**, and the module name is `nfs`. ## Creating an NFS Shared Storage Class @@ -42,7 +42,7 @@ Refs to [Installing via YAML](../../../extend/cluster_plugin.mdx#installing-via- 2. Select **NFS CSI** and click **Next**. -3. Refer to the following instructions to configure the relevant parameters. +3. Configure the following parameters. | Parameter | Description | | :----------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -52,7 +52,7 @@ Refs to [Installing via YAML](../../../extend/cluster_plugin.mdx#installing-via- | **NFS Protocol Version** | Currently supports three versions: `v3`, `v4.0`, and `v4.1`. | | **Reclaim Policy** | The reclaim policy for the persistent volume.
- Delete: When the persistent volume claim is deleted, the bound persistent volume will also be deleted.
- Retain: Even if the persistent volume claim is deleted, the bound persistent volume will still be retained. | | **Access Modes** | All access modes supported by the current storage. During the subsequent declaration of persistent volumes, only one of these modes can be selected for mounting persistent volumes.
- ReadWriteOnce (RWO): Can be mounted as read-write by a single node.
- ReadWriteMany (RWX): Can be mounted as read-write by multiple nodes.
- ReadOnlyMany (ROX): Can be mounted as read-only by multiple nodes. | - | **Allocated Projects** | Please allocate the projects that can use this type of storage.
If there are currently no projects needing this type of storage, you may choose not to allocate any projects at this time and update them later. | + | **Allocated Projects** | Allocate the projects that can use this type of storage.
If no projects currently need this type of storage, leave the allocation empty and update it later. | | **subDir** | Each PersistentVolumeClaim (PVC) created using the NFS Shared Storage Class corresponds to a subdirectory within the NFS share. By default, subdirectories are named using the pattern `${pv.metadata.name}` (i.e., the PersistentVolume name). If the default generated name does not meet your requirements, you can customize the subdirectory naming rules. | :::note diff --git a/docs/en/configure/storage/functions/snapshot_con.mdx b/docs/en/configure/storage/functions/snapshot_con.mdx index f69bc389e..f4af66431 100644 --- a/docs/en/configure/storage/functions/snapshot_con.mdx +++ b/docs/en/configure/storage/functions/snapshot_con.mdx @@ -23,10 +23,10 @@ Currently, the platform only supports creating volume snapshots for PVCs that ar 2. Click **Marketplace** > **Cluster Plugins** to access the **Cluster Plugins** list page. -3. Locate the `Alauda Container Platform Snapshot Management` cluster plugin, click **Install**, and wait for a moment until the deployment is successful. +3. Locate the ** Snapshot Management** cluster plugin, click **Install**, and wait until deployment succeeds. ## Deploying via YAML -Refs to [Installing via YAML](../../../extend/cluster_plugin.mdx#installing-via-yaml) +For YAML installation, see [Installing via YAML](../../../extend/cluster_plugin.mdx#installing-via-yaml). -`Alauda Container Platform Snapshot Management` is a **Non-config plugin**, and the module-name is `snapshot` +** Snapshot Management** is a **Non-config plugin**, and the module name is `snapshot`. diff --git a/docs/en/configure/storage/functions/topolvm_storageclass.mdx b/docs/en/configure/storage/functions/topolvm_storageclass.mdx index 49e19f292..973f462d5 100644 --- a/docs/en/configure/storage/functions/topolvm_storageclass.mdx +++ b/docs/en/configure/storage/functions/topolvm_storageclass.mdx @@ -27,9 +27,9 @@ Once the Persistent Volume Claim (PVC) is bound to the storage class, the platfo ### Constraints and Limitations -Please try to use local storage only for applications where data replication and backup at the application layer can be realized, such as MySQL. Avoid data loss due to the lack of data persistence guarantee from local storage. +Use local storage only for applications that provide application-layer data replication and backup. Local storage does not provide an independent data persistence guarantee when the underlying node fails. -[Learn more](https://github.com/topolvm/topolvm/blob/main/docs/user-manual.md) +For TopoLVM behavior, see the [TopoLVM user manual](https://github.com/topolvm/topolvm/blob/main/docs/user-manual.md). ## Deploy Volume Plugin @@ -59,7 +59,7 @@ After clicking deploy, on the newly opened page [configure local storage](/stora | **File System** |
  • **XFS** is a high-performance journaling file system well-suited for handling parallel I/O workloads, supporting large file handling and smooth data transfer.
  • **EXT4** is a journaling file system under Linux that provides extent file storage and supports large file handling, with a maximum file system capacity of 1 EiB and a maximum file size of 16 TiB.
| | **Reclamation Policy** | The reclamation policy for persistent volumes.
  • Delete: The bound persistent volume will also be deleted along with the PVC.
  • Retain: The bound persistent volume will remain even if the PVC is deleted.
| | **Access Mode** | ReadWriteOnce (RWO): Can be mounted as read-write by a single node. | - | **PVC Reconstruction** | Supports PVC reconstruction across nodes. When enabled, the **Reconstruction Wait Time** must be configured. When the node hosting the PVC created using this storage class fails, the PVC will be automatically rebuilt on other nodes after the wait time to ensure business continuity.
**Note**:
  • The rebuilt PVC does not contain the original data.
  • Please ensure that the number of storage nodes is greater than the number of application instance replicas, or it will affect PVC reconstruction.
| + | **PVC Reconstruction** | Supports PVC reconstruction across nodes. When enabled, the **Reconstruction Wait Time** must be configured. When the node hosting the PVC created using this storage class fails, the PVC will be automatically rebuilt on other nodes after the wait time to ensure business continuity.
**Note**:
  • The rebuilt PVC does not contain the original data.
  • Ensure that the number of storage nodes is greater than the number of application instance replicas. Otherwise, PVC reconstruction can be affected.
| | **Allocated Projects** | Persistent volume claims of this type can only be created in specific projects.
If no project is currently allocated, the project can also be **updated later**. | 7. After confirming that the configuration information is correct, click the **Create** button. diff --git a/docs/en/configure/storage/functions/using_volume_snapshot.mdx b/docs/en/configure/storage/functions/using_volume_snapshot.mdx index 2d8e0fdad..fa803b9c0 100644 --- a/docs/en/configure/storage/functions/using_volume_snapshot.mdx +++ b/docs/en/configure/storage/functions/using_volume_snapshot.mdx @@ -50,7 +50,7 @@ spec: 4. Fill in the snapshot description. This description can help you record the current state of the persistent volume, such as _Before Application Upgrade_. -5. Click **Create**. The time taken for the snapshot depends on network conditions and data volume; please be patient. +5. Click **Create**. Snapshot creation time depends on network conditions and data volume. When the snapshot changes to `Available` status, it indicates that the creation was successful. @@ -66,7 +66,7 @@ spec: 5. Click **Create Volume Snapshot**, and configure the relevant parameters as needed. -6. Click **Create**. The time taken for the snapshot depends on network conditions and data volume; please be patient. +6. Click **Create**. Snapshot creation time depends on network conditions and data volume. When the snapshot changes to `Available` status, it indicates that the creation was successful. @@ -78,7 +78,7 @@ spec: 3. Click **Create Volume Snapshot**, and configure the relevant parameters as needed. -4. Click **Create**. The time taken for the snapshot depends on network conditions and data volume; please be patient. +4. Click **Create**. Snapshot creation time depends on network conditions and data volume. When the snapshot changes to `Available` status, it indicates that the creation was successful. diff --git a/docs/en/configure/storage/how_to/configuring_persistent_localstorage.mdx b/docs/en/configure/storage/how_to/configuring_persistent_localstorage.mdx index 02f646c69..5749a3139 100644 --- a/docs/en/configure/storage/how_to/configuring_persistent_localstorage.mdx +++ b/docs/en/configure/storage/how_to/configuring_persistent_localstorage.mdx @@ -1,6 +1,6 @@ # Configuring Persistent Storage Using Local volumes -Alauda Container Platform can be provisioned with persistent storage by using local volumes. Local persistent volumes allow you to access local storage devices, such as a disk or partition, by using the standard persistent volume claim interface. + can use local volumes for persistent storage. Local persistent volumes allow you to access local storage devices, such as a disk or partition, by using the standard persistent volume claim interface. Local volumes can be used without manually scheduling pods to nodes because the system is aware of the volume node constraints. However, local volumes are still subject to the availability of the underlying node and are not suitable for all applications. @@ -192,4 +192,4 @@ The Local Storage Operator automates local storage discovery. discovery-result-worker-03 21m ``` - A dedicated LocalVolumeDiscoveryResult object is generated for selected nodes in LocalVolumeDiscovery Object, from which you can inspect the block devices discovered on that node. \ No newline at end of file + A dedicated LocalVolumeDiscoveryResult object is generated for selected nodes in LocalVolumeDiscovery Object, from which you can inspect the block devices discovered on that node. diff --git a/docs/en/configure/storage/how_to/configuring_persistent_storage.mdx b/docs/en/configure/storage/how_to/configuring_persistent_storage.mdx index 93b361846..27114298c 100644 --- a/docs/en/configure/storage/how_to/configuring_persistent_storage.mdx +++ b/docs/en/configure/storage/how_to/configuring_persistent_storage.mdx @@ -1,10 +1,10 @@ # Configuring Persistent Storage Using NFS -Alauda Container Platform clusters support persistent storage using NFS. Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) provide an abstraction layer for provisioning and consuming storage volumes within a project. While NFS configuration details can be embedded directly in a Pod definition, this approach does not create the volume as a distinct, isolated cluster resource, increasing the risk of conflicts. + clusters support persistent storage using NFS. PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs) provide an abstraction layer for provisioning and consuming storage volumes within a project. While NFS configuration details can be embedded directly in a Pod definition, this approach does not create the volume as a distinct, isolated cluster resource, increasing the risk of conflicts. ## Prerequisites -- Storage must exist in the underlying infrastructure before it can be mounted as a volume in Alauda Container Platform. +- Storage must exist in the underlying infrastructure before it can be mounted as a volume in . - To provision NFS volumes, a list of NFS servers and export paths are all that is required. ## Procedure @@ -105,13 +105,13 @@ Alauda Container Platform clusters support persistent storage using NFS. Persist To enforce disk quotas and size constraints, you can utilize disk partitions. Assign each partition as a dedicated export point, with each export corresponding to a distinct PersistentVolume (PV). -While Alauda Container Platform mandates unique PV names, it remains the administrator's responsibility to ensure the uniqueness of the NFS volume's server and path for each export. +While requires unique PV names, administrators must also ensure that the NFS server and path combination is unique for each export. -This partitioned approach enables precise capacity management. Developers request persistent storage specifying a required amount (e.g., 10Gi), and ACP matches the request to a PV backed by a partition/export offering at least that specified capacity. Please note: The quota enforcement applies to the usable storage space within the assigned partition/export. +This partitioned approach enables precise capacity management. Developers request persistent storage by specifying a required amount, such as `10Gi`, and matches the request to a PV backed by a partition or export that offers at least that capacity. Quota enforcement applies to the usable storage space within the assigned partition or export. ## NFS volume security -This section details NFS volume security mechanisms with a focus on permission matching. Readers are assumed to possess fundamental knowledge of POSIX permissions, process UIDs, and supplemental groups. +NFS volume security depends on permission matching. Review POSIX permissions, process UIDs, and supplemental groups before configuring NFS volumes for shared use. Developers request NFS storage through either: - A PersistentVolumeClaim (PVC) reference by name, or @@ -119,7 +119,7 @@ Developers request NFS storage through either: On the NFS server, the /etc/exports file defines export rules for accessible directories. Each exported directory retains its native POSIX owner/group IDs. -Key behavior of Alauda Container Platform's NFS plugin: +Key behavior of the NFS plugin: 1. Mounts volumes to containers while preserving exact POSIX ownership and permissions from the source directory 2. Executes containers without forcing process UIDs to match the mount ownership - an intentional security measure @@ -163,7 +163,7 @@ The owner ID of 65534 is used as an example. Even though NFS's root_squash maps Recommended NFS Access Management (When Export Permissions Are Fixed) When modifying permissions on the NFS export is not feasible, the recommended approach for managing access is through supplemental groups. -Supplemental groups in Alauda Container Platform are a common mechanism for controlling access to shared file storage, such as NFS. +Supplemental groups in are a common mechanism for controlling access to shared file storage, such as NFS. Contrast with Block Storage: Access to block storage volumes (e.g., iSCSI) is typically managed by setting the fsGroup value within the pod's securityContext. This approach leverages filesystem group ownership change upon mount. @@ -238,7 +238,7 @@ To enable arbitrary container users to read and write the volume, each exported ## Reclaiming resources -NFS implements the Alauda Container Platform Recyclable plugin interface. Automatic processes handle reclamation tasks based on policies set on each persistent volume. +NFS implements the Recyclable plugin interface. Automatic processes handle reclamation tasks based on policies set on each persistent volume. By default, PVs are set to Retain. diff --git a/docs/en/configure/storage/how_to/configuring_pvc_dr.mdx b/docs/en/configure/storage/how_to/configuring_pvc_dr.mdx index cd878e31d..40760c704 100644 --- a/docs/en/configure/storage/how_to/configuring_pvc_dr.mdx +++ b/docs/en/configure/storage/how_to/configuring_pvc_dr.mdx @@ -20,7 +20,7 @@ To achieve cross-cluster disaster recovery for Application PVCs, use **Alauda Bu - **Download** the **Alauda Build of VolSync** installation package corresponding to your platform architecture. - **Upload** the **Alauda Build of VolSync** installation package using the Upload Packages mechanism to both Primary and Secondary clusters. -- **Alauda Container Platform Snapshot Management** has been deployed on both Primary and Secondary cluster. +- ** Snapshot Management** has been deployed on both the Primary and Secondary clusters. - The storage used by the PVC must be provisioned by the **CSI** and support **snapshot** functionality. ## Deploy Alauda Build of VolSync @@ -43,7 +43,7 @@ To achieve cross-cluster disaster recovery for Application PVCs, use **Alauda Bu After configuring Scheduled Synchronization for a PVC, VolSync will automatically synchronize the data from the `ReplicationSource` to the `ReplicationDestination` at the specified interval. -This section outlines the configuration steps for synchronizing data from the primary cluster to the secondary cluster. For synchronization from the secondary to the primary, adapt the example below by swapping the cluster roles (primary and secondary) +Configure synchronization from the Primary cluster to the Secondary cluster. For synchronization from the Secondary cluster to the Primary cluster, adapt the example below by swapping the cluster roles. diff --git a/docs/en/configure/storage/trouble_shooting/detach_csi_volumes_non_graceful_shutdown.mdx b/docs/en/configure/storage/trouble_shooting/detach_csi_volumes_non_graceful_shutdown.mdx index a96fc7db2..e7d9cdc64 100644 --- a/docs/en/configure/storage/trouble_shooting/detach_csi_volumes_non_graceful_shutdown.mdx +++ b/docs/en/configure/storage/trouble_shooting/detach_csi_volumes_non_graceful_shutdown.mdx @@ -4,7 +4,7 @@ weight: 20 # Detach CSI Volumes After Non-Graceful Node Shutdown -If a node shuts down unexpectedly, the kubelet might not report the shutdown event to the control plane. In this case, Pods that use CSI-backed persistent volumes can remain stuck on the failed node, and the volumes might not detach automatically. In Alauda Container Platform, you can manually add an `out-of-service` taint to trigger Pod eviction and volume detachment. +If a node shuts down unexpectedly, the kubelet might not report the shutdown event to the control plane. In this case, Pods that use CSI-backed persistent volumes can remain stuck on the failed node, and the volumes might not detach automatically. In , you can manually add an `out-of-service` taint to trigger Pod eviction and volume detachment. ## When to use this procedure diff --git a/docs/en/developer/building_application/create_applications/image_app.mdx b/docs/en/developer/building_application/create_applications/image_app.mdx index 03f1d83ab..b961d468c 100644 --- a/docs/en/developer/building_application/create_applications/image_app.mdx +++ b/docs/en/developer/building_application/create_applications/image_app.mdx @@ -110,13 +110,13 @@ In the **Workload** > **Basic Info** section, configure declarative parameters f | **Parameters** | **Description** | | :------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| **Service** | Kubernetes **Service**, expose an application running in your cluster behind a single outward-facing endpoint, even when the workload is split across multiple backends.. For specific parameter explanations, please refer to [Creating Services](/configure/networking/functions/configure_service.mdx).

**Note** The default name prefix for the internal routing created under the application is the name of the compute component. If the compute component type (deployment mode) is StatefulSet, it is advisable not to change the default name of the internal routing (the name of the workload); otherwise, it may lead to accessibility issues for the workload. | +| **Service** | Kubernetes **Service**, expose an application running in your cluster behind a single outward-facing endpoint, even when the workload is split across multiple backends.. For specific parameter explanations, please refer to [Creating Services](/networking/functions/configure_service.mdx).

**Note** The default name prefix for the internal routing created under the application is the name of the compute component. If the compute component type (deployment mode) is StatefulSet, it is advisable not to change the default name of the internal routing (the name of the workload); otherwise, it may lead to accessibility issues for the workload. | ## Procedure 3 - Ingress | **Parameters** | **Description** | | :------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **Ingress** | Kubernetes **Ingress**, make your HTTP (or HTTPS) network service available using a protocol-aware configuration mechanism, that understands web concepts like URIs, hostnames, paths, and more. The Ingress concept lets you map traffic to different backends based on rules you define via the Kubernetes API. For detailed parameter descriptions, please refer to [Creating Ingresses](/configure/networking/functions/configure_ingress.mdx).

**Note**: The **Service** used when creating **Ingress** under the application must be resources created under the current application. However, ensure that the **Service** is associated with the workload under the application; otherwise, service discovery and access for workload will fail. | +| **Ingress** | Kubernetes **Ingress**, make your HTTP (or HTTPS) network service available using a protocol-aware configuration mechanism, that understands web concepts like URIs, hostnames, paths, and more. The Ingress concept lets you map traffic to different backends based on rules you define via the Kubernetes API. For detailed parameter descriptions, please refer to [Creating Ingresses](/networking/functions/configure_ingress.mdx).

**Note**: The **Service** used when creating **Ingress** under the application must be resources created under the current application. However, ensure that the **Service** is associated with the workload under the application; otherwise, service discovery and access for workload will fail. | 7. Click **Create**. diff --git a/docs/en/developer/images/how_to/creating_images.mdx b/docs/en/developer/images/how_to/creating_images.mdx index a487c8303..58fb2c0a3 100644 --- a/docs/en/developer/images/how_to/creating_images.mdx +++ b/docs/en/developer/images/how_to/creating_images.mdx @@ -8,7 +8,7 @@ i18n: # Creating images -Learn how to create your own container images, based on pre-built images that are ready to help you. The process includes learning best practices for writing images, defining metadata for images, testing images, and using a custom builder workflow to create images to use with [Alauda Container Platform Registry](../../registry/intro.mdx). After you create an image, you can push it to the **Alauda Container Platform Registry**. +Learn how to create your own container images, based on pre-built images that are ready to help you. The process includes learning best practices for writing images, defining metadata for images, testing images, and using a custom builder workflow to create images to use with [Alauda Container Platform Registry](/configure/registry/overview.mdx). After you create an image, you can push it to the **Alauda Container Platform Registry**. ## Learning container best practices When creating container images to run on Alauda Container Platform there are a number of best practices to consider as an image author to ensure a good experience for consumers of those images. Because images are intended to be immutable and used as-is, the following guidelines help ensure that your images are highly consumable and easy to use on Alauda Container Platform. @@ -121,7 +121,7 @@ See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/v Defining image metadata helps Alauda Container Platform better consume your container images, allowing Alauda Container Platform to create a better experience for developers using your image. For example, you can add metadata to provide helpful descriptions of your image, or offer suggestions on other images that may also be needed. -This topic only defines the metadata needed by the current set of use cases. Additional metadata or use cases may be added in the future. +The metadata set covers the fields needed by the current use cases. Additional metadata or use cases may be added in the future. ### Defining image metadata diff --git a/docs/en/developer/images/overview.mdx b/docs/en/developer/images/overview.mdx index 7e970c665..9ba1e2737 100644 --- a/docs/en/developer/images/overview.mdx +++ b/docs/en/developer/images/overview.mdx @@ -12,23 +12,23 @@ i18n: Containers and images are important concepts to understand when you set out to create and manage containerized software. An image holds a set of software that is ready to run, while a container is a running instance of a container image. Those different versions are represented by different tags on the same image name. ## Images -Containers in Alauda Container Platform are based on OCI-formatted container images. An image is a binary that includes all of the requirements for running a single container, as well as metadata describing its needs and capabilities. +Containers in are based on OCI-formatted container images. An image is a binary that includes all of the requirements for running a single container, as well as metadata describing its needs and capabilities. -You can think of it as a packaging technology. Containers have access only to resources defined in the image unless granted additional access at creation time. By deploying the same image in multiple containers across multiple hosts and load balancing between them, Alauda Container Platform can provide redundancy and horizontal scaling for a service packaged into an image. +You can think of it as a packaging technology. Containers have access only to resources defined in the image unless granted additional access at creation time. By deploying the same image in multiple containers across multiple hosts and load balancing between them, can provide redundancy and horizontal scaling for a service packaged into an image. -You can use the `nerdctl` or `container` CLI directly to build images, but Alauda Container Platform also supplies builder images that assist with creating new images by adding your code or configuration to existing images. +You can use the `nerdctl` or `container` CLI directly to build images, but also supplies builder images that assist with creating new images by adding your code or configuration to existing images. Because applications develop over time, a single image name can actually refer to many different versions of the same image. Each different image is referred to uniquely by its hash, a long hexadecimal number such as fd44297e2ddb050ec4f…, which is usually shortened to 12 characters, such as fd44297e2ddb. ## Image registry An image registry is a content server that can store and serve container images. For example: - [Quay.io Container Registry](https://quay.io/) -- [Alauda Container Platform Registry](../registry/intro.mdx) +- [Registry](/configure/registry/overview.mdx) -A registry contains a collection of one or more image repositories, which contain one or more tagged images. Alauda Container Platform can supply its own image registry for managing custom container images. +A registry contains a collection of one or more image repositories, which contain one or more tagged images. can supply its own image registry for managing custom container images. ## Image repository -An image repository is a collection of related container images and tags identifying them. For example, the Alauda Container Platform Jenkins images are in the repository: +An image repository is a collection of related container images and tags identifying them. For example, the Jenkins images are in the repository: ``` jenkins-2-centos7 ``` @@ -48,10 +48,10 @@ jenkins-2-centos7@sha256:ab312bda324 ``` ## Containers -The basic units of Alauda Container Platform applications are called containers. Linux container technologies are lightweight mechanisms for isolating running processes so that they are limited to interacting with only their designated resources. The word container is defined as a specific running or paused instance of a container image. +The basic units of applications are called containers. Linux container technologies are lightweight mechanisms for isolating running processes so that they are limited to interacting with only their designated resources. The word container is defined as a specific running or paused instance of a container image. Many application instances can be running in containers on a single host without visibility into each others' processes, files, network, and so on. Typically, each container provides a single service, often called a micro-service, such as a web server or a database, though containers can be used for arbitrary workloads. -The Linux kernel has been incorporating capabilities for container technologies for years. Early container runtime projects introduced convenient management interfaces for running isolated applications on a host. More recently, the [Open Container Initiative](https://github.com/opencontainers/) has developed open standards for container formats and container runtimes. Alauda Container Platform and Kubernetes add the ability to orchestrate OCI-formatted containers across multi-host installations. +The Linux kernel has been incorporating capabilities for container technologies for years. Early container runtime projects introduced convenient management interfaces for running isolated applications on a host. More recently, the [Open Container Initiative](https://github.com/opencontainers/) has developed open standards for container formats and container runtimes. and Kubernetes add the ability to orchestrate OCI-formatted containers across multi-host installations. -Though you do not directly interact with container runtimes when using Alauda Container Platform, understanding their capabilities and terminology is important for understanding their role in Alauda Container Platform and how your applications function inside of containers. +Though you do not directly interact with container runtimes when using , understanding their capabilities and terminology is important for understanding their role in and how your applications function inside of containers. diff --git a/docs/en/developer/oam_applications/concepts/component.mdx b/docs/en/developer/oam_applications/concepts/component.mdx index 43ed006d8..f94aaab61 100644 --- a/docs/en/developer/oam_applications/concepts/component.mdx +++ b/docs/en/developer/oam_applications/concepts/component.mdx @@ -64,7 +64,7 @@ This component includes Kubernetes' StatefulSet and Service, used for defining p - + diff --git a/docs/en/developer/oam_applications/concepts/trait.mdx b/docs/en/developer/oam_applications/concepts/trait.mdx index 16db345c4..99d3c615c 100644 --- a/docs/en/developer/oam_applications/concepts/trait.mdx +++ b/docs/en/developer/oam_applications/concepts/trait.mdx @@ -222,7 +222,7 @@ Ingress rules (Kubernetes Ingress) expose external HTTP/HTTPS routes to internal **Parameter Description** -For specific parameter descriptions, please refer to [Creating Ingress Rules](/configure/networking/functions/configure_ingress.mdx). +For specific parameter descriptions, please refer to [Creating Ingress Rules](/networking/functions/configure_ingress.mdx). **Example YAML After Configuration** diff --git a/docs/en/developer/registry/how_to/registry_data_restore.mdx b/docs/en/developer/registry/how_to/registry_data_restore.mdx deleted file mode 100644 index b00943450..000000000 --- a/docs/en/developer/registry/how_to/registry_data_restore.mdx +++ /dev/null @@ -1,141 +0,0 @@ ---- -weight: 15 -i18n: - title: - zh: Alauda Container Platform Registry 数据备份和恢复 ---- - -# Alauda Container Platform Registry Data Backup and Recovery - -## Overview -This solution provides guidance for backing up and recovering data of `Alauda Container Platform Registry` that uses S3-compatible object storage in Alauda Container Platform (ACP). - -Core Concept: Decouple the management of the image data itself (stored in S3) from the `cluster plugin` configuration (defined in the Kubernetes `ModuleInfo` custom resource). - -* **Backup**: Retrieve S3 configuration from the `ModuleInfo` resource and backup data from the specified storage `bucket`. -* **Recovery**: After installing the `cluster plugin` in a new cluster, update its S3 configuration in the `ModuleInfo` resource to point to the bucket containing the restored data, thereby completing data integration. - -Advantages: - -* **Decoupled Operations**: Data backup/recovery is independent of ACP `cluster plugin` deployment and upgrade processes. -* **Configuration-Driven**: All connection information is managed through the declarative `ModuleInfo` resource, ensuring safe and reliable changes. -* **Extensible**: This pattern can be extended to other storage backends (e.g., Local filesystem, StorageClass, NAS). - -## Prerequisites - -* Have `kubectl` access and appropriate permissions to operate the target Kubernetes cluster. -* Have credentials and client tools (e.g., awscli, rclone, minio-client) to access and operate the S3-compatible storage used for image data. -* The `Alauda Container Platform Registry` cluster plugin is installed and configured, and its `ModuleInfo` resource exists and is in a healthy state. -* Have independent, sufficient storage capacity prepared for backup data (e.g., another S3 bucket). - -## Data Backup -The goal of this phase is to obtain the current production S3 configuration and perform a full backup of the image data within the storage bucket. - -### Step 1: Obtain Current S3 Configuration -Extract the S3 storage configuration from the `ModuleInfo` resource that manages the `Alauda Container Platform Registry` cluster plugin. -This information is the basis for the backup operation. - -You should run the following commands on the `global` cluster of ACP: -```bash -# 1. Identify the ModuleInfo resource name for the image-registry module -MODULE_INFO_NAME=$(kubectl get moduleinfo -l cpaas.io/module-name=image-registry -o jsonpath='{.items[0].metadata.name}') -echo "Target ModuleInfo Resource: $MODULE_INFO_NAME" - -# 2. Extract key S3 configuration information -S3_BUCKET=$(kubectl get moduleinfo $MODULE_INFO_NAME -o jsonpath='{.spec.config.s3storage.bucket}') -S3_ENDPOINT=$(kubectl get moduleinfo $MODULE_INFO_NAME -o jsonpath='{.spec.config.s3storage.regionEndpoint}') -S3_REGION=$(kubectl get moduleinfo $MODULE_INFO_NAME -o jsonpath='{.spec.config.s3storage.region}') -S3_SECRET_NAME=$(kubectl get moduleinfo $MODULE_INFO_NAME -o jsonpath='{.spec.config.s3storage.secretName}') - -# 3. Obtain access keys from the Secret (typically access-key-id and secret-access-key) -# Note: The output is Base64 encoded and needs to be decoded accordingly. -kubectl get secret -n cpaas-system $S3_SECRET_NAME -o jsonpath='{.data}' -``` - -**Key Variable Descriptions**: - -- `S3_BUCKET`: The source bucket name where image data is actually stored. -- `S3_ENDPOINT`: The endpoint URL to connect to the S3-compatible service. -- `S3_REGION`: The region identifier for the S3 service. -- `S3_SECRET_NAME`: The Kubernetes Secret name storing the authentication keys. - -### Step 2: Perform S3 Bucket Data Backup -Using your S3 client tool of choice, leverage the configuration obtained in the previous step to perform a full backup of the source bucket's data. - -**Operational Logic**: - -* Configure your client with the endpoint ($S3_ENDPOINT), region ($S3_REGION), and the decoded access key and secret key from the Secret. -* Execute a sync or copy command to back up all data from the source bucket ($S3_BUCKET) to your prepared independent backup location (e.g., another S3 bucket or path). -* Record the backup timestamp, the bucket name and endpoint used, and archive this information with the backup files. - -## Data Recovery -This phase assumes the `Alauda Container Platform Registry` cluster plugin has been successfully installed in the target environment (new cluster or repaired cluster) via the platform. The goal is to modify its configuration to access the restored image data. - -### Step 1: Prepare Backup Data -Using your S3 client tool of choice, restore the backed-up image data into a **target S3 storage `bucket` that is definitively accessible**. For example, restore it into a new bucket named `registry-bucket-restored`. Ensure you have write permissions to this target bucket. - -### Step 2: Update ModuleInfo Configuration -The key to recovery is updating the `ModuleInfo` resource of the new `cluster plugin` to point its S3 configuration to the target bucket containing the backup data. - -1. **Determine New S3 Connection Information**: - - `NEW_BUCKET`: The **target bucket name** where the backup data has been restored (e.g., registry-bucket-restored). - - `NEW_ENDPOINT`: The **endpoint of the target S3 service**. This remains unchanged if the S3 service address is the same as during backup. - - `NEW_REGION`: The **region of the target S3 service**. - - `NEW_SECRET_NAME`: The name of the Kubernetes Secret with read/write permissions to the **target bucket**. If the access keys are unchanged, this is still `$S3_SECRET_NAME`. - -2. **Update ModuleInfo Resource**: -Use the kubectl patch command to directly update the S3 configuration section of the `ModuleInfo`. The platform controller will automatically synchronize this change to all relevant Deployment, Pod, and other resources. - - ```bash - # Execute the configuration update - kubectl patch moduleinfo $MODULE_INFO_NAME --type=merge -p '{ - "spec": { - "config": { - "s3storage": { - "bucket": "'"$NEW_BUCKET"'", - "regionEndpoint": "'"$NEW_ENDPOINT"'", - "region": "'"$NEW_REGION"'", - "secretName": "'"$NEW_SECRET_NAME"'" - } - } - } - }' - ``` -**Key Point**: This operation triggers a rolling update of the `Alauda Container Platform Registry` related Pods. The newly started Pods will use the new configuration to connect to the specified target storage bucket. - -## Verification -After the update is complete, follow these steps to verify successful data recovery and normal service operation. - -### Check Module Status(in global cluster) - ```bash - # Check if Pods have successfully restarted and are running with the new configuration - kubectl get pods -n cpaas-system -l app=image-registry - # Observe Pod logs to confirm no S3 connection errors - kubectl logs -n cpaas-system -l app=image-registry -c registry --tail=50 - ``` - -### Verify Data Access (API Test) -Use the Registry's API interface to directly verify it can read the restored image data. - - ```bash - # Obtain the Registry Service access address (assuming ClusterIP type) - REGISTRY_SVC_IP=$(kubectl get svc -n cpaas-system image-registry -o jsonpath='{.spec.clusterIP}') - - # Test 1: Query the catalog of repositories - curl -s http://$REGISTRY_SVC_IP/v2/_catalog | jq . - # Expected success return: {"repositories":["image1","image2",...]} - - # Test 2: Query the tag list for a specific image (e.g., an image named `myns/nginx`) - curl -s http://$REGISTRY_SVC_IP/v2/myns/nginx/tags/list | jq . - # Expected success return: {"name":"myns/nginx","tags":["v1.0","latest",...]} - ``` - -### Functionality Test -Attempt to pull a known image from the restored registry or push a new image to it to fully verify read/write functionality. - -## Solution Generality -While this solution uses S3 storage as an example, its **design pattern applies to various storage backends** supported by Registry (e.g., Local filesystem, StorageClass, NAS). - -**General Principle**: Regardless of storage type, the core backup and recovery process remains the same. First, extract storage connection parameters from the corresponding configuration block (e.g., `s3storage`, `persistence`) in the `ModuleInfo` resource, then use the appropriate storage tools to back up data. For recovery, after restoring data to the target location, simply update the corresponding configuration fields in `ModuleInfo`. The platform will automatically direct the newly deployed instance to this location. - -**Core Value**: By utilizing a **unified configuration abstraction layer** (`ModuleInfo`), this solution decouples the data backup/recovery process from specific storage implementations and Kubernetes application deployments, achieving standardized management and extensibility. diff --git a/docs/en/developer/registry/index.mdx b/docs/en/developer/registry/index.mdx index 5c467dd03..e264ab137 100644 --- a/docs/en/developer/registry/index.mdx +++ b/docs/en/developer/registry/index.mdx @@ -2,10 +2,10 @@ weight: 40 i18n: title: - en: Registry + en: Registry Image Use zh: 镜像仓库 --- -# Registry +# Registry Image Use diff --git a/docs/en/developer/registry/intro.mdx b/docs/en/developer/registry/intro.mdx deleted file mode 100644 index 12f9a5093..000000000 --- a/docs/en/developer/registry/intro.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -weight: 10 -i18n: - title: - en: Introduction - zh: 介绍 ---- - -# Introduction - -Building, storing and managing container images is a core part of the cloud-native application development process. Alauda Container Platform(ACP) provides a high-performance, highly-available, built-in container image repository service designed to provide users with a secure and convenient image storage and management experience, greatly simplifying application development, continuous integration/continuous deployment (CI/CD) and application deployment processes within the platform. CD) and application deployment processes within the platform. - -Deeply integrated into the platform architecture, Alauda Container Platform Registry provides tighter platform collaboration, simplified configuration, and greater internal access efficiency than an external, independently deployed image repository. - -## Principles and namespace isolation -Alauda Container Platform's built-in image repository, as one of the core components of the platform, runs inside the cluster in a highly-available manner and utilizes the persistent storage capabilities provided by the platform to ensure that the image data is secure and reliable. - -One of its core design concepts is logical isolation and management based on Namespace. Within the Registry, image repositories are organized by namespace. This means that each namespace can be considered as a separate “zone” for images belonging to that namespace, and images between different namespaces are isolated by default, unless explicitly authorized. - -## Authentication and authorization - -The authentication and authorization mechanism of Alauda Container Platform Registry is deeply integrated with ACP's platform-level authentication and authorization system, enabling access control as granular as the namespace: - -### Authentication -Users or automated processes (e.g., CI/CD pipelines on the platform, automated build tasks, etc.) do not need to maintain a separate set of account passwords for the Registry. They are authenticated through the platform's standard authentication mechanisms (e.g., using platform-provided API tokens, integrated enterprise identity systems, etc.). When accessing Alauda Container Platform Registry through the CLI or other tools, it is common to utilize existing platform login sessions or ServiceAccount tokens for transparent authentication. - -### Authorization -Authorization control is implemented at the namespace level. Pull or Push permissions for an image repository in Alauda Container Platform Registry depend on the platform role and permissions that the user or ServiceAccount has in the corresponding namespace. - - - **Typically**, the owner or developer role of a namespace is automatically granted Push and Pull permissions to image repositories under that namespace. - - **Users in other namespaces or users who wish to pull images across namespaces** need to be explicitly granted the appropriate permissions by the administrator of the target namespace (e.g., bind a role that allows pulling of images via RBAC) before they can access images within that namespace. - - **This namespace-based authorization** mechanism ensures isolation of images between namespaces, improving security and avoiding unauthorized access and modification. - -## Advantages - -**Core advantages of Alauda Container Platform Registry:** - -- **Ready-to-Use:** Rapidly deploy a private image registry without complex configurations. -- **Flexible Access:** Supports both intra-cluster and external access modes. -- **Security Assurance:** Provides RBAC authorization and image scanning capabilities. -- **High Availability:** Ensures service continuity through replication mechanisms. -- **Production-Grade:** Validated in enterprise environments with SLA guarantees. - -## Application Scenarios - -- **Lightweight Deployment:** Implement streamlined registry solutions in low-traffic environments to accelerate application delivery. -- **Edge Computing:** Enable autonomous management for edge clusters with dedicated registries. -- **Resource Optimization:** Demonstrate full workflow capabilities through integrated Source to Image (S2I) solutions when underutilizing infrastructure. diff --git a/docs/en/developer/s2i/functions/s2i_application_management.mdx b/docs/en/developer/s2i/functions/s2i_application_management.mdx index cb896f606..ef0888473 100644 --- a/docs/en/developer/s2i/functions/s2i_application_management.mdx +++ b/docs/en/developer/s2i/functions/s2i_application_management.mdx @@ -22,7 +22,7 @@ i18n: ## Prerequisites - [Installing Alauda Container Platform Builds](./../install_builds/install_builds_operator.mdx) is completed. -- Access to a image repository is required; if unavailable, contact the Administrator to [Installing Alauda Container Platform Registry](/developer/registry/install/index.mdx) +- Access to a image repository is required; if unavailable, contact the Administrator to [Installing Alauda Container Platform Registry](/configure/registry/install/index.mdx) ## Procedure \{#procedure} @@ -270,7 +270,7 @@ i18n:
  • Other Parameters: Please refer to the parameter descriptions in the - [CreatingIngress](/configure/networking/functions/configure_ingress.mdx) + [CreatingIngress](/networking/functions/configure_ingress.mdx) documentation.
    • diff --git a/docs/en/developer/s2i/how_to/s2i_howto.mdx b/docs/en/developer/s2i/how_to/s2i_howto.mdx index d6b309e5d..6904fcf34 100644 --- a/docs/en/developer/s2i/how_to/s2i_howto.mdx +++ b/docs/en/developer/s2i/how_to/s2i_howto.mdx @@ -14,7 +14,7 @@ i18n: Before using this functionality, ensure that: - [Installing Alauda Container Platform Builds](../install_builds/install_builds_operator.mdx) -- There is an accessible image repository on the platform. If not, please contact the Administrator to [Installing ACP Registry](/developer/registry/install/index.mdx) +- There is an accessible image repository on the platform. If not, please contact the Administrator to [Installing ACP Registry](/configure/registry/install/index.mdx) ## Procedure diff --git a/docs/en/install/next_steps.mdx b/docs/en/install/next_steps.mdx index 738501ac1..e36adc6d5 100644 --- a/docs/en/install/next_steps.mdx +++ b/docs/en/install/next_steps.mdx @@ -12,7 +12,7 @@ After Core validation succeeds, complete the follow | Conditional | Create workload clusters or connect existing clusters. | Use this path when your architecture requires workload clusters separate from the `global` cluster. | [Clusters](../configure/clusters/index.mdx) | | Conditional | Upload and install Extensions Packages. | Use this path when you need additional platform capabilities after Core is installed. | [Extend](../extend/index.mdx) | | Recommended before broad user onboarding | Configure identity providers, users, roles, projects, and project membership. | Use this path before onboarding administrators, project users, or application teams. | [Users and Roles](../security/users_and_roles/index.mdx) and [Projects](../security/project/index.mdx) | -| Recommended before application workloads | Prepare storage, networking, registry access, and workload prerequisites. | Use this path before application teams deploy workloads. | [Storage](../configure/storage/index.mdx), [Networking](../configure/networking/index.mdx), [Registry](../developer/registry/index.mdx), and [Clusters](../configure/clusters/index.mdx) | +| Recommended before application workloads | Prepare storage, networking, registry access, and workload prerequisites. | Use this path before application teams deploy workloads. | [Storage](../configure/storage/index.mdx), [Networking](../networking/index.mdx), [Registry](../developer/registry/index.mdx), and [Clusters](../configure/clusters/index.mdx) | | Recommended before production operation | Review backup, upgrade, monitoring, and operational documentation. | Use this path before operating the platform for production workloads. | [Backup](../configure/backup/index.mdx), [Upgrade](../upgrade/index.mdx), and [Observability](../observability/index.mdx) | These tasks do not all apply to every installation. Follow the paths that match your deployment architecture and operational requirements. diff --git a/docs/en/configure/networking/functions/configure_alb.mdx b/docs/en/networking/functions/configure_alb.mdx similarity index 99% rename from docs/en/configure/networking/functions/configure_alb.mdx rename to docs/en/networking/functions/configure_alb.mdx index 164307312..84f0af309 100644 --- a/docs/en/configure/networking/functions/configure_alb.mdx +++ b/docs/en/networking/functions/configure_alb.mdx @@ -113,7 +113,7 @@ there are some global config which can be tweaked in alb cr. ##### Using the web console. -![](../assets/create_alb_via_web.png) +![](../networking_assets/create_alb_via_web.png) Some common configuration is exposed in the web UI. Follow these steps to create a load balancer: 1. Navigate to **Administrator**. @@ -240,7 +240,7 @@ spec: ##### using the web console -![](../assets/create_ft_via_web.png) +![](../networking_assets/create_ft_via_web.png) 1. Go to **Container Platform**. @@ -428,7 +428,7 @@ For more details, refer to [Balance Algorithm](/networking/operators/alb_operato #### Using web console -![](../assets/create_rule_via_web.png) +![](../networking_assets/create_rule_via_web.png) 1. Go to **Container Platform**. 2. Click on **Network** > **Load Balancing** in the left navigation bar. diff --git a/docs/en/configure/networking/functions/configure_certificate.mdx b/docs/en/networking/functions/configure_certificate.mdx similarity index 100% rename from docs/en/configure/networking/functions/configure_certificate.mdx rename to docs/en/networking/functions/configure_certificate.mdx diff --git a/docs/en/configure/networking/functions/configure_coredns.mdx b/docs/en/networking/functions/configure_coredns.mdx similarity index 100% rename from docs/en/configure/networking/functions/configure_coredns.mdx rename to docs/en/networking/functions/configure_coredns.mdx diff --git a/docs/en/configure/networking/functions/configure_domain.mdx b/docs/en/networking/functions/configure_domain.mdx similarity index 100% rename from docs/en/configure/networking/functions/configure_domain.mdx rename to docs/en/networking/functions/configure_domain.mdx diff --git a/docs/en/configure/networking/functions/configure_gatewayapi_gateway.mdx b/docs/en/networking/functions/configure_gatewayapi_gateway.mdx similarity index 97% rename from docs/en/configure/networking/functions/configure_gatewayapi_gateway.mdx rename to docs/en/networking/functions/configure_gatewayapi_gateway.mdx index 2c377936d..f7de581c7 100644 --- a/docs/en/configure/networking/functions/configure_gatewayapi_gateway.mdx +++ b/docs/en/networking/functions/configure_gatewayapi_gateway.mdx @@ -6,22 +6,22 @@ weight: 16 ## Overview -This document explains how to configure a `Gateway` after the Envoy Gateway operator and `EnvoyGatewayCtl` are ready. +Configure a `Gateway` after the Envoy Gateway operator and `EnvoyGatewayCtl` are ready. A `Gateway` defines how traffic enters the gateway, while the companion `EnvoyProxy` controls how the underlying Envoy data plane is deployed. -In the recommended workflow, this document comes after [Envoy Gateway Operator](../../../networking/operators/envoy_gateway_operator.mdx) +In the recommended workflow, configure a `Gateway` after [Envoy Gateway Operator](/networking/operators/envoy_gateway_operator.mdx) and before [Configure GatewayAPI Route](./configure_gatewayapi_route.mdx). ## Prerequisites Please ensure that you have completed the following before proceeding: -1. Read [Envoy Gateway Operator](../../../networking/operators/envoy_gateway_operator.mdx) to understand the basic concepts and resource relationships +1. Read [Envoy Gateway Operator](/networking/operators/envoy_gateway_operator.mdx) to understand the basic concepts and resource relationships 2. Install the Envoy Gateway operator and create an `EnvoyGatewayCtl` :::note -This document first explains the main Gateway concepts and then shows how to create a `Gateway`. If you are already +Review the main Gateway concepts before creating a `Gateway`. If you are already familiar with these concepts, you can skip to the [Create Gateway](#create-gateway) section. ::: @@ -188,7 +188,7 @@ For other deployment configuration methods, see [deployment-mode](https://gatewa 1. Navigate to `Alauda Container Platform -> Networking -> Gateway -> Gateways` 2. Click the `Create Gateway` button 3. On the `Create Gateway` page, select the `GatewayClass` created by your `EnvoyGatewayCtl`. In the recommended - default example from [Envoy Gateway Operator](../../../networking/operators/envoy_gateway_operator.mdx), this is + default example from [Envoy Gateway Operator](/networking/operators/envoy_gateway_operator.mdx), this is `envoy-gateway-operator-cpaas-default`. The page displays the following configuration options: diff --git a/docs/en/configure/networking/functions/configure_gatewayapi_policy.mdx b/docs/en/networking/functions/configure_gatewayapi_policy.mdx similarity index 100% rename from docs/en/configure/networking/functions/configure_gatewayapi_policy.mdx rename to docs/en/networking/functions/configure_gatewayapi_policy.mdx diff --git a/docs/en/configure/networking/functions/configure_gatewayapi_route.mdx b/docs/en/networking/functions/configure_gatewayapi_route.mdx similarity index 100% rename from docs/en/configure/networking/functions/configure_gatewayapi_route.mdx rename to docs/en/networking/functions/configure_gatewayapi_route.mdx diff --git a/docs/en/configure/networking/functions/configure_ingress.mdx b/docs/en/networking/functions/configure_ingress.mdx similarity index 95% rename from docs/en/configure/networking/functions/configure_ingress.mdx rename to docs/en/networking/functions/configure_ingress.mdx index b04cd5e7a..261ef0cfb 100644 --- a/docs/en/configure/networking/functions/configure_ingress.mdx +++ b/docs/en/networking/functions/configure_ingress.mdx @@ -17,14 +17,14 @@ When creating multiple ingresses within the same namespace, different ingresses Ingress rules depend on the implementation of the Ingress Controller, which is responsible for listening to changes in Ingress and Service. After a new Ingress is created, when the Ingress Controller receives a request, it matches the forwarding rule from the Ingress and distributes the traffic to the specified internal routes, as shown in the diagram below. - + :::note For the HTTP protocol, Ingress only supports the 80 port as the external port. For the HTTPS protocol, Ingress only supports the 443 port as the external port. The platform's load balancer will automatically add the 80 and 443 listening ports. ::: -- [Install ingress-nginx as ingress-controller via ingress-nginx-operator](../../../networking/operators/ingress_nginx_operator.mdx) -- [Install alb as ingress-controller via alb-operator](../../../networking/operators/alb_operator.mdx) +- [Install ingress-nginx as ingress-controller via ingress-nginx-operator](/networking/operators/ingress_nginx_operator.mdx) +- [Install alb as ingress-controller via alb-operator](/networking/operators/alb_operator.mdx) ## Example Ingress: diff --git a/docs/en/configure/networking/functions/configure_metallb.mdx b/docs/en/networking/functions/configure_metallb.mdx similarity index 98% rename from docs/en/configure/networking/functions/configure_metallb.mdx rename to docs/en/networking/functions/configure_metallb.mdx index a374c4d52..58d441ec3 100644 --- a/docs/en/configure/networking/functions/configure_metallb.mdx +++ b/docs/en/networking/functions/configure_metallb.mdx @@ -6,7 +6,7 @@ weight: 15 ## Prerequisites -Please ensure that you have read the [Installation](../../../networking/operators/metallb_operator.mdx#installing_and_uninstalling_metallb) documentation before proceeding. +Please ensure that you have read the [Installation](/networking/operators/metallb_operator.mdx#installing_and_uninstalling_metallb) documentation before proceeding. ## Configure an External IP Address Pool by using the web console \{#configure_ip_pool} diff --git a/docs/en/configure/networking/functions/configure_node_local_dns.mdx b/docs/en/networking/functions/configure_node_local_dns.mdx similarity index 100% rename from docs/en/configure/networking/functions/configure_node_local_dns.mdx rename to docs/en/networking/functions/configure_node_local_dns.mdx diff --git a/docs/en/configure/networking/functions/configure_service.mdx b/docs/en/networking/functions/configure_service.mdx similarity index 100% rename from docs/en/configure/networking/functions/configure_service.mdx rename to docs/en/networking/functions/configure_service.mdx diff --git a/docs/en/configure/networking/functions/configure_subnet.mdx b/docs/en/networking/functions/configure_subnet.mdx similarity index 100% rename from docs/en/configure/networking/functions/configure_subnet.mdx rename to docs/en/networking/functions/configure_subnet.mdx diff --git a/docs/en/configure/networking/functions/index.mdx b/docs/en/networking/functions/index.mdx similarity index 100% rename from docs/en/configure/networking/functions/index.mdx rename to docs/en/networking/functions/index.mdx diff --git a/docs/en/configure/networking/how_to/alb/tasks_for_alb.mdx b/docs/en/networking/how_to/alb/tasks_for_alb.mdx similarity index 100% rename from docs/en/configure/networking/how_to/alb/tasks_for_alb.mdx rename to docs/en/networking/how_to/alb/tasks_for_alb.mdx diff --git a/docs/en/configure/networking/how_to/configure_endpoint_health_checker.mdx b/docs/en/networking/how_to/configure_endpoint_health_checker.mdx similarity index 98% rename from docs/en/configure/networking/how_to/configure_endpoint_health_checker.mdx rename to docs/en/networking/how_to/configure_endpoint_health_checker.mdx index 6929b8800..b5202873b 100644 --- a/docs/en/configure/networking/how_to/configure_endpoint_health_checker.mdx +++ b/docs/en/networking/how_to/configure_endpoint_health_checker.mdx @@ -95,7 +95,7 @@ spec: #### For IngressNginx \{#add_pod_annotation_in_ingress_nginx} -1. [Install ingress-nginx](../../../networking/operators/ingress_nginx_operator.mdx) +1. [Install ingress-nginx](/networking/operators/ingress_nginx_operator.mdx) 2. Set `podAnnotations` in `.spec.controller.podAnnotations` of `IngressNginx`. ```yaml apiVersion: ingress-nginx.alauda.io/v1 diff --git a/docs/en/configure/networking/how_to/index.mdx b/docs/en/networking/how_to/index.mdx similarity index 100% rename from docs/en/configure/networking/how_to/index.mdx rename to docs/en/networking/how_to/index.mdx diff --git a/docs/en/configure/networking/how_to/kube_ovn/config_metallb_underlay.mdx b/docs/en/networking/how_to/kube_ovn/config_metallb_underlay.mdx similarity index 100% rename from docs/en/configure/networking/how_to/kube_ovn/config_metallb_underlay.mdx rename to docs/en/networking/how_to/kube_ovn/config_metallb_underlay.mdx diff --git a/docs/en/configure/networking/how_to/kube_ovn/configure_bgp.mdx b/docs/en/networking/how_to/kube_ovn/configure_bgp.mdx similarity index 100% rename from docs/en/configure/networking/how_to/kube_ovn/configure_bgp.mdx rename to docs/en/networking/how_to/kube_ovn/configure_bgp.mdx diff --git a/docs/en/configure/networking/how_to/kube_ovn/configure_centralized_gateway.mdx b/docs/en/networking/how_to/kube_ovn/configure_centralized_gateway.mdx similarity index 100% rename from docs/en/configure/networking/how_to/kube_ovn/configure_centralized_gateway.mdx rename to docs/en/networking/how_to/kube_ovn/configure_centralized_gateway.mdx diff --git a/docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx b/docs/en/networking/how_to/kube_ovn/configure_egress_gateway.mdx similarity index 99% rename from docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx rename to docs/en/networking/how_to/kube_ovn/configure_egress_gateway.mdx index 1cec08a23..a32a34b7b 100644 --- a/docs/en/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx +++ b/docs/en/networking/how_to/kube_ovn/configure_egress_gateway.mdx @@ -31,7 +31,7 @@ Current limitations: ## Egress Gateway vs. Centralized Gateway -Use this section to choose the gateway model that best fits your scenario. +Compare Egress Gateway with Centralized Gateway to choose the gateway model that best fits your scenario. For centralized mode details, refer to [Configure Centralized Gateway](./configure_centralized_gateway). | Dimension | Egress Gateway | Centralized Gateway | @@ -59,7 +59,7 @@ Traffic from selected Pods is first forwarded to the gateway Pods and then sent Each Egress Gateway instance registers its address in the OVN routing table. @@ -68,7 +68,7 @@ This provides load balancing and lets throughput scale horizontally as more inst OVN can use BFD to probe multiple gateway instances. @@ -76,7 +76,7 @@ If one instance fails, OVN marks the corresponding route as unavailable and quic ## Before You Begin diff --git a/docs/en/configure/networking/how_to/kube_ovn/configure_ippool.mdx b/docs/en/networking/how_to/kube_ovn/configure_ippool.mdx similarity index 100% rename from docs/en/configure/networking/how_to/kube_ovn/configure_ippool.mdx rename to docs/en/networking/how_to/kube_ovn/configure_ippool.mdx diff --git a/docs/en/configure/networking/how_to/kube_ovn/configure_mtu.mdx b/docs/en/networking/how_to/kube_ovn/configure_mtu.mdx similarity index 100% rename from docs/en/configure/networking/how_to/kube_ovn/configure_mtu.mdx rename to docs/en/networking/how_to/kube_ovn/configure_mtu.mdx diff --git a/docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx b/docs/en/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx similarity index 100% rename from docs/en/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx rename to docs/en/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx diff --git a/docs/en/configure/networking/how_to/kube_ovn/index.mdx b/docs/en/networking/how_to/kube_ovn/index.mdx similarity index 100% rename from docs/en/configure/networking/how_to/kube_ovn/index.mdx rename to docs/en/networking/how_to/kube_ovn/index.mdx diff --git a/docs/en/configure/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx b/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx similarity index 95% rename from docs/en/configure/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx rename to docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx index 1d24c5426..9a749032a 100644 --- a/docs/en/configure/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx +++ b/docs/en/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx @@ -17,7 +17,7 @@ Before use, ensure that the node server has at least a **dual-NIC** environment, - NIC Two: The NIC without the default route and not configured with an IP address, interconnected with the external switch interface, which is set to Trunk mode. The Underlay subnet exclusively uses NIC Two. -![](../../assets/ovnunderlay.png) +![](../../networking_assets/ovnunderlay.png) ## Terminology Explanation @@ -106,8 +106,8 @@ ip link del ens224.74 // Delete the sub-interface after testing ### Platform Configuration -In the left navigation bar, click **Cluster Management > Cluster**, then click **Create Cluster**. For specific configuration procedures, please refer to the [Create Cluster]() document, with container network configuration shown in the image below. +In the left navigation bar, click **Cluster Management > Cluster**, then click **Create Cluster**. For cluster creation path selection, see [Clusters Overview](/configure/clusters/overview.mdx), with container network configuration shown in the image below. **Note**: The Join subnet has no practical significance in the Underlay environment and primarily serves to create an Overlay subnet later, providing the IP address range necessary for communication between nodes and container groups. -![](../../assets/ovnunderlayexample.png) +![](../../networking_assets/ovnunderlayexample.png) diff --git a/docs/en/configure/networking/how_to/kube_ovn/multiple_networks.mdx b/docs/en/networking/how_to/kube_ovn/multiple_networks.mdx similarity index 100% rename from docs/en/configure/networking/how_to/kube_ovn/multiple_networks.mdx rename to docs/en/networking/how_to/kube_ovn/multiple_networks.mdx diff --git a/docs/en/configure/networking/how_to/kube_ovn/underlay_overlay_st.mdx b/docs/en/networking/how_to/kube_ovn/underlay_overlay_st.mdx similarity index 100% rename from docs/en/configure/networking/how_to/kube_ovn/underlay_overlay_st.mdx rename to docs/en/networking/how_to/kube_ovn/underlay_overlay_st.mdx diff --git a/docs/en/configure/networking/how_to/kube_ovn/understanding_kube_ovn.mdx b/docs/en/networking/how_to/kube_ovn/understanding_kube_ovn.mdx similarity index 96% rename from docs/en/configure/networking/how_to/kube_ovn/understanding_kube_ovn.mdx rename to docs/en/networking/how_to/kube_ovn/understanding_kube_ovn.mdx index 331d4dab7..359f99268 100644 --- a/docs/en/configure/networking/how_to/kube_ovn/understanding_kube_ovn.mdx +++ b/docs/en/networking/how_to/kube_ovn/understanding_kube_ovn.mdx @@ -4,7 +4,7 @@ weight: 10 # Understanding Kube-OVN CNI -This document describes the general architecture of Kube-OVN, the functionality of each component and how they interact with each other. +Kube-OVN provides the CNI architecture, components, and interactions that connect Kubernetes networking with OVN. Overall, Kube-OVN serves as a bridge between Kubernetes and OVN, combining proven SDN with Cloud Native. This means that Kube-OVN not only implements network specifications under Kubernetes, such as CNI, Service and Networkpolicy, @@ -19,7 +19,7 @@ The components of Kube-OVN can be broadly divided into three categories. - Core Controller and Agent. - Monitoring, operation and maintenance tools and extension components. -![](../../assets/kube-ovn-architecture.png) +![](../../networking_assets/kube-ovn-architecture.png) ## Upstream OVN/OVS Components diff --git a/docs/en/configure/networking/how_to/soft_data_center_lb_solution.mdx b/docs/en/networking/how_to/soft_data_center_lb_solution.mdx similarity index 100% rename from docs/en/configure/networking/how_to/soft_data_center_lb_solution.mdx rename to docs/en/networking/how_to/soft_data_center_lb_solution.mdx diff --git a/docs/en/configure/networking/how_to/task_for_migrate_from_ocp_route_to_gatewayapi_route.mdx b/docs/en/networking/how_to/task_for_migrate_from_ocp_route_to_gatewayapi_route.mdx similarity index 98% rename from docs/en/configure/networking/how_to/task_for_migrate_from_ocp_route_to_gatewayapi_route.mdx rename to docs/en/networking/how_to/task_for_migrate_from_ocp_route_to_gatewayapi_route.mdx index f20779811..1fdcdae1f 100644 --- a/docs/en/configure/networking/how_to/task_for_migrate_from_ocp_route_to_gatewayapi_route.mdx +++ b/docs/en/networking/how_to/task_for_migrate_from_ocp_route_to_gatewayapi_route.mdx @@ -2,11 +2,11 @@ ## Introduction -This guide provides detailed instructions for migrating from OpenShift Container Platform (OCP) Routes to Kubernetes Gateway API HTTPRoutes with Envoy Gateway. Each section covers a specific OCP Route feature and its equivalent configuration in Gateway API. +Migrate from OpenShift Container Platform (OCP) Routes to Kubernetes Gateway API HTTPRoutes with Envoy Gateway. Use the feature-specific mappings below to translate each OCP Route feature into the equivalent Gateway API configuration. ## Prerequisites -1. [Configure EnvoyGatewayCtl](../../../networking/operators/envoy_gateway_operator.mdx) +1. [Configure EnvoyGatewayCtl](/networking/operators/envoy_gateway_operator.mdx) 2. [Configure Gateway](../functions/configure_gatewayapi_gateway.mdx#configure_gatewayapi_gateway) 3. Basic understanding of [Gateway API Routes](../functions/configure_gatewayapi_route.mdx#configure_gatewayapi_route) diff --git a/docs/en/configure/networking/how_to/tasks_for_envoy_gateway.mdx b/docs/en/networking/how_to/tasks_for_envoy_gateway.mdx similarity index 96% rename from docs/en/configure/networking/how_to/tasks_for_envoy_gateway.mdx rename to docs/en/networking/how_to/tasks_for_envoy_gateway.mdx index dc125ac31..37bf877a2 100644 --- a/docs/en/configure/networking/how_to/tasks_for_envoy_gateway.mdx +++ b/docs/en/networking/how_to/tasks_for_envoy_gateway.mdx @@ -6,8 +6,7 @@ weight: 11 ## Overview -This document extends the main configuration path (operator → gateway → route → policy) and introduces advanced tasks beyond the standard resource -configurations covered in the previous documents. +Use these advanced Envoy Gateway tasks after completing the main configuration path: operator, gateway, route, and policy. When applying configuration changes in the Gateway API, there are three primary approaches available: @@ -16,12 +15,12 @@ When applying configuration changes in the Gateway API, there are three primary Gateway and Route behavior. 3. **Configure global settings**: Modify the `EnvoyGatewayCtl` to change `envoy-gateway` instance behavior or other global settings that affect all gateways. -This document focuses on advanced tasks and special scenarios that are not part of the main configuration path, including cross-namespace routing, +Advanced tasks and special scenarios include cross-namespace routing, observability setup, deployment customization, and troubleshooting. ## Prerequisites -1. [Configure EnvoyGatewayCtl](../../../networking/operators/envoy_gateway_operator.mdx) +1. [Configure EnvoyGatewayCtl](/networking/operators/envoy_gateway_operator.mdx) 2. [Configure Gateway](../functions/configure_gatewayapi_gateway.mdx#configure_gatewayapi_gateway) 3. [Configure Route](../functions/configure_gatewayapi_route.mdx#configure_gatewayapi_route) 4. [Configure GatewayAPI Policy](../functions/configure_gatewayapi_policy.mdx#configure_gatewayapi_policy) @@ -449,7 +448,7 @@ kubectl patch envoyproxy $GATEWAY_NAME -n $GATEWAY_NS --type='json' -p='[ ## Related Documentation -- [Configure EnvoyGatewayCtl](../../../networking/operators/envoy_gateway_operator.mdx) +- [Configure EnvoyGatewayCtl](/networking/operators/envoy_gateway_operator.mdx) - [Configure Gateway](../functions/configure_gatewayapi_gateway.mdx#configure_gatewayapi_gateway) - [Configure Route](../functions/configure_gatewayapi_route.mdx#configure_gatewayapi_route) - [Configure GatewayAPI Policy](../functions/configure_gatewayapi_policy.mdx#configure_gatewayapi_policy) diff --git a/docs/en/configure/networking/how_to/tasks_for_ingress_nginx.mdx b/docs/en/networking/how_to/tasks_for_ingress_nginx.mdx similarity index 99% rename from docs/en/configure/networking/how_to/tasks_for_ingress_nginx.mdx rename to docs/en/networking/how_to/tasks_for_ingress_nginx.mdx index 917ebb7b5..83441ed93 100644 --- a/docs/en/configure/networking/how_to/tasks_for_ingress_nginx.mdx +++ b/docs/en/networking/how_to/tasks_for_ingress_nginx.mdx @@ -6,7 +6,7 @@ weight: 10 ## Prerequisites -[Install ingress-nginx](../../../networking/operators/ingress_nginx_operator.mdx) +[Install ingress-nginx](/networking/operators/ingress_nginx_operator.mdx) ## Max Connections diff --git a/docs/en/networking/ingress_loadbalancing/ingress_loadbalance_with_envoy_gateway.mdx b/docs/en/networking/ingress_loadbalancing/ingress_loadbalance_with_envoy_gateway.mdx index 1de0944ff..bd1200aef 100644 --- a/docs/en/networking/ingress_loadbalancing/ingress_loadbalance_with_envoy_gateway.mdx +++ b/docs/en/networking/ingress_loadbalancing/ingress_loadbalance_with_envoy_gateway.mdx @@ -81,7 +81,7 @@ spec: name: site-cert ``` -Learn more [Configure Gateway API Gateway](/configure/networking/functions/configure_gatewayapi_gateway.mdx#configure_gatewayapi_gateway). +Learn more [Configure Gateway API Gateway](/networking/functions/configure_gatewayapi_gateway.mdx#configure_gatewayapi_gateway). ### Creating HTTP Routes @@ -107,7 +107,7 @@ spec: port: 8080 ``` -Learn more [Configure Gateway API Route](/configure/networking/functions/configure_gatewayapi_route.mdx#configure_gatewayapi_route). +Learn more [Configure Gateway API Route](/networking/functions/configure_gatewayapi_route.mdx#configure_gatewayapi_route). Explanation @@ -202,7 +202,7 @@ spec: ttl: 3600s ``` -Learn more about [BackendTrafficPolicy](/configure/networking/functions/configure_gatewayapi_policy.mdx#backendtrafficpolicy). +Learn more about [BackendTrafficPolicy](/networking/functions/configure_gatewayapi_policy.mdx#backendtrafficpolicy). ## TLS and Security @@ -235,7 +235,7 @@ Advanced policy CRDs can enable mTLS or client certificate validation. In bare-metal clusters without cloud load balancers: -1. Configure a [MetalLB IPAddressPool](/configure/networking/functions/configure_metallb.mdx#configure_ip_pool) and L2Advertisement. +1. Configure a [MetalLB IPAddressPool](/networking/functions/configure_metallb.mdx#configure_ip_pool) and L2Advertisement. 2. Ensure the Envoy Gateway Service is of type LoadBalancer. diff --git a/docs/en/configure/networking/assets/architecture.png b/docs/en/networking/networking_assets/architecture.png similarity index 100% rename from docs/en/configure/networking/assets/architecture.png rename to docs/en/networking/networking_assets/architecture.png diff --git a/docs/en/configure/networking/assets/create_alb_via_web.png b/docs/en/networking/networking_assets/create_alb_via_web.png similarity index 100% rename from docs/en/configure/networking/assets/create_alb_via_web.png rename to docs/en/networking/networking_assets/create_alb_via_web.png diff --git a/docs/en/configure/networking/assets/create_ft_via_web.png b/docs/en/networking/networking_assets/create_ft_via_web.png similarity index 100% rename from docs/en/configure/networking/assets/create_ft_via_web.png rename to docs/en/networking/networking_assets/create_ft_via_web.png diff --git a/docs/en/configure/networking/assets/create_rule_via_web.png b/docs/en/networking/networking_assets/create_rule_via_web.png similarity index 100% rename from docs/en/configure/networking/assets/create_rule_via_web.png rename to docs/en/networking/networking_assets/create_rule_via_web.png diff --git a/docs/en/configure/networking/assets/egress-gateway-1.png b/docs/en/networking/networking_assets/egress-gateway-1.png similarity index 100% rename from docs/en/configure/networking/assets/egress-gateway-1.png rename to docs/en/networking/networking_assets/egress-gateway-1.png diff --git a/docs/en/configure/networking/assets/egress-gateway-2.png b/docs/en/networking/networking_assets/egress-gateway-2.png similarity index 100% rename from docs/en/configure/networking/assets/egress-gateway-2.png rename to docs/en/networking/networking_assets/egress-gateway-2.png diff --git a/docs/en/configure/networking/assets/egress-gateway-3.png b/docs/en/networking/networking_assets/egress-gateway-3.png similarity index 100% rename from docs/en/configure/networking/assets/egress-gateway-3.png rename to docs/en/networking/networking_assets/egress-gateway-3.png diff --git a/docs/en/configure/networking/assets/kube-ovn-architecture.png b/docs/en/networking/networking_assets/kube-ovn-architecture.png similarity index 100% rename from docs/en/configure/networking/assets/kube-ovn-architecture.png rename to docs/en/networking/networking_assets/kube-ovn-architecture.png diff --git a/docs/en/configure/networking/assets/netrelationship.png b/docs/en/networking/networking_assets/netrelationship.png similarity index 100% rename from docs/en/configure/networking/assets/netrelationship.png rename to docs/en/networking/networking_assets/netrelationship.png diff --git a/docs/en/configure/networking/assets/ovnunderlay.png b/docs/en/networking/networking_assets/ovnunderlay.png similarity index 100% rename from docs/en/configure/networking/assets/ovnunderlay.png rename to docs/en/networking/networking_assets/ovnunderlay.png diff --git a/docs/en/configure/networking/assets/ovnunderlayexample.png b/docs/en/networking/networking_assets/ovnunderlayexample.png similarity index 100% rename from docs/en/configure/networking/assets/ovnunderlayexample.png rename to docs/en/networking/networking_assets/ovnunderlayexample.png diff --git a/docs/en/networking/operators/alb_operator/deploy_high_available_vip_for_alb.mdx b/docs/en/networking/operators/alb_operator/deploy_high_available_vip_for_alb.mdx index 560282266..bc43af6ac 100644 --- a/docs/en/networking/operators/alb_operator/deploy_high_available_vip_for_alb.mdx +++ b/docs/en/networking/operators/alb_operator/deploy_high_available_vip_for_alb.mdx @@ -10,9 +10,9 @@ The high availability of the **ALB** requires a VIP. There are two ways to obtai When creating an ALB in `container` network mode, the system automatically creates a LoadBalancer Service to provide a VIP for that ALB. -Before using this, ensure the cluster supports LoadBalancer Services. You can use the platform built‑in implementation. For setup, see [Configure MetalLB](/configure/networking/functions/configure_metallb.mdx). +Before using this, ensure the cluster supports LoadBalancer Services. You can use the platform built‑in implementation. For setup, see [Configure MetalLB](/networking/functions/configure_metallb.mdx). -After MetalLB is ready, you can add the following annotations to `alb.spec.config.vip.lbSvcAnnotations` to tweak MetalLB behavior. See [ALB networking configuration](/configure/networking/functions/configure_alb.mdx#alb_networking_configuration). +After MetalLB is ready, you can add the following annotations to `alb.spec.config.vip.lbSvcAnnotations` to tweak MetalLB behavior. See [ALB networking configuration](/networking/functions/configure_alb.mdx#alb_networking_configuration). | Annotation | Description | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | @@ -21,7 +21,7 @@ After MetalLB is ready, you can add the following annotations to `alb.spec.confi ## Method 2: Use external ALB device to provide VIP -- Please confirm with the network engineer the IP address (public IP, private IP, VIP) or domain name of the ALB service before deployment. If you want to use a domain name as the address for external traffic to access the ALB, you need to apply for a domain name in advance and configure domain name resolution. It is recommended to use a commercial Load Balancer device to provide a VIP, if not, you can use the [Pure Software Data Center LB Solution (Alpha)](/configure/networking/how_to/soft_data_center_lb_solution.mdx) +- Please confirm with the network engineer the IP address (public IP, private IP, VIP) or domain name of the ALB service before deployment. If you want to use a domain name as the address for external traffic to access the ALB, you need to apply for a domain name in advance and configure domain name resolution. It is recommended to use a commercial Load Balancer device to provide a VIP, if not, you can use the [Pure Software Data Center LB Solution (Alpha)](/networking/how_to/soft_data_center_lb_solution.mdx) - According to the business scenario, the external ALB needs to configure health checks for all the ports in use to reduce the downtime of ALB upgrade. The health check configuration is as follows: diff --git a/docs/en/networking/operators/alb_operator/otel.mdx b/docs/en/networking/operators/alb_operator/otel.mdx index d789df673..6fbf49088 100644 --- a/docs/en/networking/operators/alb_operator/otel.mdx +++ b/docs/en/networking/operators/alb_operator/otel.mdx @@ -25,7 +25,7 @@ OpenTelemetry (OTel) is an open-source project aimed at providing a vendor-neutr ## Prerequisites -- **Ensure that an operable ALB exists**: Create or use an existing ALB, where the name of the ALB is replaced with `` in this document. For instructions on creating an ALB, refer to [Configure ALB](/configure/networking/functions/configure_alb.mdx). +- **Ensure that an operable ALB exists**: Create or use an existing ALB. The examples below use `` as the ALB name. For instructions on creating an ALB, see [Configure ALB](/networking/functions/configure_alb.mdx). - **Ensure that there is an OTel data reporting server address**: This address will hereinafter be referred to as ``. diff --git a/docs/en/networking/operators/alb_operator/understanding_alb.mdx b/docs/en/networking/operators/alb_operator/understanding_alb.mdx index 1a4a6551c..ecf5c249b 100644 --- a/docs/en/networking/operators/alb_operator/understanding_alb.mdx +++ b/docs/en/networking/operators/alb_operator/understanding_alb.mdx @@ -214,4 +214,4 @@ When ALB Leader translates the Ingress into Rules, it will ignore Ingress in nam ## Additional resources: -- [Configure a Load Balancer](/configure/networking/functions/configure_alb.mdx) +- [Configure a Load Balancer](/networking/functions/configure_alb.mdx) diff --git a/docs/en/networking/operators/envoy_gateway_operator.mdx b/docs/en/networking/operators/envoy_gateway_operator.mdx index 0b11e020b..228a72f1b 100644 --- a/docs/en/networking/operators/envoy_gateway_operator.mdx +++ b/docs/en/networking/operators/envoy_gateway_operator.mdx @@ -6,9 +6,9 @@ weight: 40 ## Overview \{#understanding_envoy_gateway} -This document provides an overview of how `envoy-gateway-operator` works in ACP. It explains the relationships between -the main custom resources and runtime instances involved in Envoy Gateway, including `EnvoyGatewayCtl`, `GatewayClass`, -`Gateway`, `EnvoyProxy`, `envoy-gateway instance`, and `envoy-proxy instance`. +Use `envoy-gateway-operator` to deploy and manage Envoy Gateway through platform-managed resources. The main custom +resources and runtime instances are `EnvoyGatewayCtl`, `GatewayClass`, `Gateway`, `EnvoyProxy`, `envoy-gateway instance`, +and `envoy-proxy instance`. The `envoy-gateway-operator` packages the upstream `envoy-gateway` Helm chart as an Operator, so you can deploy and manage an `envoy-gateway instance` declaratively through the `EnvoyGatewayCtl` custom resource instead of managing the @@ -19,11 +19,11 @@ In ACP 4.3, `envoy-gateway-operator` packages the upstream `envoy-gateway` Helm Because the Operator is maintained by the platform, it is also upgraded automatically together with the platform, which helps reduce the operational overhead of manually maintaining the Envoy Gateway installation. -This document also describes how to create an `EnvoyGatewayCtl`, which is the entry point for deploying and managing +Create an `EnvoyGatewayCtl` as the entry point for deploying and managing Envoy Gateway through the platform. -After you understand the basic concepts in this document and create an `EnvoyGatewayCtl`, continue with `Gateway`, -`Route`, and `Policy` configuration in that order by following the documents listed in [Next Step](#next-step). +After you understand these concepts and create an `EnvoyGatewayCtl`, continue with `Gateway`, +`Route`, and `Policy` configuration in the order listed in [Next Step](#next-step). ### Architecture @@ -33,14 +33,14 @@ The following workflow shows how `envoy-gateway-operator`, `EnvoyGatewayCtl`, `G ![](../assets/envoy_gateway_architecture.drawio.svg) 1. After you install `envoy-gateway-operator` and create an `EnvoyGatewayCtl`, the operator deploys an `envoy-gateway instance` and creates a corresponding - `GatewayClass`. The `GatewayClass` name follows the `-` pattern. In this document, we use the recommended default example: + `GatewayClass`. The `GatewayClass` name follows the `-` pattern. The recommended default example uses `cpaas-default` in the `envoy-gateway-operator` namespace, which is also the default configuration prefilled on the `Create EnvoyGatewayCtl` page. In this case, the generated `GatewayClass` is `envoy-gateway-operator-cpaas-default`. Each `EnvoyGatewayCtl` must have a unique combination of namespace and name, so the corresponding `GatewayClass` names are also unique. When creating a `Gateway`, you select the appropriate `GatewayClass` to determine which `envoy-gateway instance` manages it. -2. When you create a [`Gateway`](../../configure/networking/functions/configure_gatewayapi_gateway.mdx) that +2. When you create a [`Gateway`](../../networking/functions/configure_gatewayapi_gateway.mdx) that references this `GatewayClass`, the `envoy-gateway instance` takes ownership of that `Gateway`. If the `Gateway` references an `EnvoyProxy` through `.spec.infrastructure.parametersRef`, that `EnvoyProxy` is used to control how the underlying `envoy-proxy instance` is deployed. @@ -76,14 +76,14 @@ are matched and forwarded to backends, and what policies are applied during traf | [GatewayClass](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gatewayclass) | Tells an `envoy-gateway instance` which `Gateway` resources it should manage. | | [Gateway](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gateway) | Defines three essential components:
    1. **GatewayClass reference** - References the GatewayClass that controls this Gateway via `.spec.gatewayClassName`
    2. **Listeners configuration** - Specifies which ports, hostnames, and TLS certificates to use for traffic handling via `.spec.listeners`
    3. **Infrastructure parameters** - Configures deployment specifics like replicas, resources by referencing an `EnvoyProxy` via `.spec.infrastructure.parametersRef` | | [Route resources](https://gateway-api.sigs.k8s.io/concepts/api-overview/#route-resources) | Includes `HTTPRoute`, `TCPRoute`, `UDPRoute`, `GRPCRoute`, and `TLSRoute`. These resources define four essential components:
    1. **Multiple matching rule sets** - Various conditions to match incoming traffic
    2. **Backend destinations** - Target services for each matching rule set
    3. **Traffic policies** - Per-rule configurations including retries, timeouts, redirects, etc.
    4. **Gateway listeners attachment** - Defined via `.spec.parentRefs` to connect routes to specific `Gateway` listeners | -| [Policies](../../configure/networking/functions/configure_gatewayapi_policy.mdx) | Policy resources extend `Gateway` and `Route` resources with advanced capabilities. Envoy Gateway currently provides `SecurityPolicy`, `BackendTLSPolicy`, `ClientTrafficPolicy`, and `BackendTrafficPolicy`. | +| [Policies](../../networking/functions/configure_gatewayapi_policy.mdx) | Policy resources extend `Gateway` and `Route` resources with advanced capabilities. Envoy Gateway currently provides `SecurityPolicy`, `BackendTLSPolicy`, `ClientTrafficPolicy`, and `BackendTrafficPolicy`. | -For more details about these standard Gateway API resources, please refer to the [Gateway API Concepts](../overview.mdx#gatewayapi) and [Configure GatewayAPI Policy](../../configure/networking/functions/configure_gatewayapi_policy.mdx). +For more details about these standard Gateway API resources, please refer to the [Gateway API Concepts](../overview.mdx#gatewayapi) and [Configure GatewayAPI Policy](../../networking/functions/configure_gatewayapi_policy.mdx). #### Envoy Gateway deploy-related custom resources -These resources are used to control how Envoy Gateway and its data plane are deployed. This section focuses on the -deployment-related custom resource used by this document. +These resources control how Envoy Gateway and its data plane are deployed. Use the following custom resource for +deployment-related configuration. | Custom resources | Description | | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | @@ -91,14 +91,14 @@ deployment-related custom resource used by this document. In the recommended deployment pattern, each `Gateway` references its own dedicated `EnvoyProxy` through `.spec.infrastructure.parametersRef`. When you create a `Gateway` from the Web Console by using an `EnvoyGatewayCtl`-created `GatewayClass`, the console automatically creates a companion -[`EnvoyProxy`](../../configure/networking/functions/configure_gatewayapi_gateway.mdx#companion_envoyproxy) resource with the same name and namespace. This one-to-one +[`EnvoyProxy`](../../networking/functions/configure_gatewayapi_gateway.mdx#companion_envoyproxy) resource with the same name and namespace. This one-to-one mapping lets you control the Gateway's deployment configuration, such as replicas, resources, and scheduling, by updating the corresponding `EnvoyProxy` resource. ## Install Envoy Gateway via Envoy Gateway Operator \{#install_envoy_gateway_operator} ### Prerequisites -Please ensure that you have read the Overview and Architecture sections before proceeding. +Before proceeding, review the concepts and architecture above. ### Installation @@ -109,7 +109,7 @@ Please ensure that you have read the Overview and Architecture sections before p #### Step 2: Create an EnvoyGatewayCtl with the Recommended Default Values -The following default values match the recommended example used throughout this document. +The following default values match the recommended example used in this workflow. 1. Navigate to `Administrator -> Marketplace -> OperatorHub` 2. Locate the `Alauda build of Envoy Gateway` under the `Networking` category, then click it to open the details page. @@ -205,7 +205,7 @@ spec: After the Envoy Gateway operator and `EnvoyGatewayCtl` are ready, continue with the following tasks in order: -- [Configure GatewayAPI Gateway](../../configure/networking/functions/configure_gatewayapi_gateway.mdx) -- [Configure GatewayAPI Route](../../configure/networking/functions/configure_gatewayapi_route.mdx) -- [Configure GatewayAPI Policy](../../configure/networking/functions/configure_gatewayapi_policy.mdx) -- [Tasks for Envoy Gateway](../../configure/networking/how_to/tasks_for_envoy_gateway.mdx) +- [Configure GatewayAPI Gateway](../../networking/functions/configure_gatewayapi_gateway.mdx) +- [Configure GatewayAPI Route](../../networking/functions/configure_gatewayapi_route.mdx) +- [Configure GatewayAPI Policy](../../networking/functions/configure_gatewayapi_policy.mdx) +- [Tasks for Envoy Gateway](../../networking/how_to/tasks_for_envoy_gateway.mdx) diff --git a/docs/en/networking/overview.mdx b/docs/en/networking/overview.mdx index 143143c5b..db268fbde 100644 --- a/docs/en/networking/overview.mdx +++ b/docs/en/networking/overview.mdx @@ -125,10 +125,10 @@ Some other notable capabilities include: For more detailed descriptions of the Gateway API, please refer to the [gateway-api documentation](https://gateway-api.sigs.k8s.io/). -## Comparison Among [Service](/configure/networking/functions/configure_service.mdx), [Ingress](/configure/networking/functions/configure_ingress.mdx), [Gateway API](/networking/operators/envoy_gateway_operator.mdx) +## Comparison Among [Service](/networking/functions/configure_service.mdx), [Ingress](/networking/functions/configure_ingress.mdx), [Gateway API](/networking/operators/envoy_gateway_operator.mdx) -The Alauda Container Platform supports multiple ingress traffic specifications in Kubernetes ecosystem. -This document compares them (Service, Ingress, Gateway API) to help users make the right choice. + supports multiple ingress traffic specifications in the Kubernetes ecosystem. +Compare Service, Ingress, and Gateway API to choose the traffic entry pattern that fits your workload and operational requirements. ### For L4 (TCP/UDP) Traffic diff --git a/docs/en/configure/networking/trouble_shooting/arm_checksum.mdx b/docs/en/networking/trouble_shooting/arm_checksum.mdx similarity index 100% rename from docs/en/configure/networking/trouble_shooting/arm_checksum.mdx rename to docs/en/networking/trouble_shooting/arm_checksum.mdx diff --git a/docs/en/configure/networking/trouble_shooting/find_who_cause_the_error.mdx b/docs/en/networking/trouble_shooting/find_who_cause_the_error.mdx similarity index 100% rename from docs/en/configure/networking/trouble_shooting/find_who_cause_the_error.mdx rename to docs/en/networking/trouble_shooting/find_who_cause_the_error.mdx diff --git a/docs/en/configure/networking/trouble_shooting/index.mdx b/docs/en/networking/trouble_shooting/index.mdx similarity index 100% rename from docs/en/configure/networking/trouble_shooting/index.mdx rename to docs/en/networking/trouble_shooting/index.mdx diff --git a/docs/en/observability/alerting/index.mdx b/docs/en/observability/alerting/index.mdx new file mode 100644 index 000000000..e9820b17f --- /dev/null +++ b/docs/en/observability/alerting/index.mdx @@ -0,0 +1,8 @@ +--- +weight: 15 +title: Alerting +--- + +# Alerting + + diff --git a/docs/en/configure/notification/cluster_notification.mdx b/docs/en/observability/alerting/notification.mdx similarity index 91% rename from docs/en/configure/notification/cluster_notification.mdx rename to docs/en/observability/alerting/notification.mdx index 76281be5c..b7abe90ee 100644 --- a/docs/en/configure/notification/cluster_notification.mdx +++ b/docs/en/observability/alerting/notification.mdx @@ -9,18 +9,18 @@ Cluster Notification provides independent notification capabilities for workload ## Prerequisites -- ACP version: >= v4.2 +- version: >= v4.2 - Plugin version: >= v1.0 ## Install -### Download Plugin Package from AlaudaCloud +### Download Plugin Package -Login to AlaudaCloud and download the latest Alauda Container Platform Cluster Notification plugin package. +Log in to the package portal and download the latest Cluster Notification plugin package. ### Push the Plugin to Platform with violet -Use violet to push the Alauda Container Platform Cluster Notification plugin to platform: +Use violet to push the Cluster Notification plugin to the platform: ```shell violet push aiops-notification-business.ALL.vx.x.x.tgz \ diff --git a/docs/en/observability/alerting/overview.mdx b/docs/en/observability/alerting/overview.mdx new file mode 100644 index 000000000..d43355495 --- /dev/null +++ b/docs/en/observability/alerting/overview.mdx @@ -0,0 +1,15 @@ +--- +weight: 10 +--- + +# Overview + +Use Alerting to configure notification delivery and alert-related operations for platform and workload observability. + +| Need | Continue with | +| --- | --- | +| Configure cluster notification delivery for workload clusters. | [Cluster Notification](./notification.mdx) | +| Manage monitoring alerts. | [Manage alerts](../monitor/functions/manage_alert.mdx) | +| Manage monitoring notification channels. | [Manage notifications](../monitor/functions/manage_notifcation.mdx) | + +During post-installation, configure alert notification delivery before teams depend on platform and workload alerts. Use this Alerting area for detailed alert and notification procedures. diff --git a/docs/en/observability/monitor/how_to/infra_nodes.mdx b/docs/en/observability/monitor/how_to/infra_nodes.mdx index c6814dd39..dfe8611d3 100644 --- a/docs/en/observability/monitor/how_to/infra_nodes.mdx +++ b/docs/en/observability/monitor/how_to/infra_nodes.mdx @@ -6,7 +6,7 @@ weight: 40 ## Overview -This document explains how to plan and configure infra nodes for the Monitoring plugins. Use plugin configuration to place Monitoring workloads on infra nodes instead of patching generated workloads after installation. +Plan and configure infra nodes for the Monitoring plugins. Use plugin configuration to place Monitoring workloads on infra nodes instead of patching generated workloads after installation. ## Supported Configuration Methods @@ -19,7 +19,7 @@ Do not use patching generated Deployments, StatefulSets, or other plugin-managed Before configuring placement, ensure the following conditions are met: -- Plan the infra nodes according to [Cluster Node Planning](../../../configure/clusters/acp-node-planning.mdx). +- Plan the infra nodes according to [Cluster Node Planning](../../../configure/nodes/node_planning.mdx). - Confirm whether your storage uses `LocalVolume` or other persistent volumes with `spec.nodeAffinity`. - Make sure the selected infra nodes satisfy both the scheduling rules and the storage placement constraints. diff --git a/docs/en/observability/monitor/install_monitor.mdx b/docs/en/observability/monitor/install_monitor.mdx index d57a176c1..adafb316e 100644 --- a/docs/en/observability/monitor/install_monitor.mdx +++ b/docs/en/observability/monitor/install_monitor.mdx @@ -8,7 +8,7 @@ title: Installation ## Overview -The monitoring component provides the infrastructure for monitoring, alerting, inspection, and health checking functions within the observability module. This document describes how to install ACP Monitoring with Prometheus or ACP Monitoring with VictoriaMetrics in a cluster. +The monitoring component provides the infrastructure for monitoring, alerting, inspection, and health checking functions within the observability module. Install ACP Monitoring with Prometheus or ACP Monitoring with VictoriaMetrics in a cluster. To decide which plugin to install, first review the [Monitoring Component Selection Guide](./architecture/component_selection_suggestion.mdx) and choose the option that best fits your cluster scale, storage plan, and operational requirements. @@ -17,7 +17,7 @@ To decide which plugin to install, first review the [Monitoring Component Select :::info Some Monitoring components are resource-intensive. We recommend placing them on infra nodes through plugin configuration. Prometheus and VictoriaMetrics both support plugin-level `nodeSelector` and `tolerations` settings. If you are evaluating the product and have not provisioned infra nodes, you can leave these settings empty so the components run on general nodes. -For guidance on planning infra nodes, see [Cluster Node Planning](../../configure/clusters/acp-node-planning.mdx). +For guidance on planning infra nodes, see [Cluster Node Planning](../../configure/nodes/node_planning.mdx). ::: Before installing the monitoring components, please ensure the following conditions are met: diff --git a/docs/en/overview/availability-and-recovery.mdx b/docs/en/overview/availability-and-recovery.mdx index 648800aea..e75fe869d 100644 --- a/docs/en/overview/availability-and-recovery.mdx +++ b/docs/en/overview/availability-and-recovery.mdx @@ -6,7 +6,7 @@ weight: 70 Plan availability and recovery by matching your environment to the appropriate deployment topology, high availability baseline, Global Cluster Disaster Recovery path, and backup or restore procedure. -For detailed sizing, backup, restore, and disaster recovery procedures, follow the linked topic-specific pages. The guidance below focuses on planning choices and support boundaries. +For detailed sizing, backup, restore, and disaster recovery procedures, follow the linked topic-specific procedures. The guidance below focuses on planning choices and support boundaries. ## Deployment Topology @@ -30,7 +30,7 @@ Infra nodes or custom role nodes are useful for isolating platform components or | --- | --- | | `global` cluster sizing by managed cluster count | [Evaluating Resources for Global Cluster](../configure/scalability/evaluating_global.mdx) | | Workload cluster control plane sizing and scale factors | [Evaluating Resources for Workload Cluster](../configure/scalability/evaluating_workload.mdx) | -| Node roles and infra/custom role nodes | [Cluster Node Planning](../configure/clusters/acp-node-planning.mdx) | +| Node roles and infra/custom role nodes | [Cluster Node Planning](../configure/nodes/node_planning.mdx) | | Node requirements and OS/kernel support | [Node Preprocessing](../install/prepare/node_preprocessing.mdx) | ## Global Cluster Disaster Recovery @@ -56,7 +56,7 @@ Recovery is composed by scenario. Each mechanism protects a specific data domain | --- | --- | --- | | Primary `global` cluster failure | Global Cluster Disaster Recovery. | [Global Cluster Disaster Recovery](../install/global_dr.mdx) | | Accidental cluster-state deletion or rollback | etcd backup and restore. | [etcd Backup and Restore](../configure/backup/etcd.mdx) | -| Registry image repository data | Registry backup and recovery. | [Registry Data Backup and Recovery](../developer/registry/how_to/registry_data_restore.mdx) | +| Registry image repository data | Registry backup and recovery. | [Registry Data Backup and Recovery](../configure/registry/backup_and_restore.mdx) | | Monitoring data | Monitoring component backup or restore. | [VictoriaMetrics Backup and Recovery](../observability/monitor/how_to/restore_victoriametrics.mdx) | | Logging data | Logging component backup or restore, according to the installed logging backend. | [Logging Service](../observability/log/intro.mdx) | | Application resources and persistent volumes | Application backup and restore with Data Backup Essentials and Data Backup for Velero. | [Backup Overview](../configure/backup/overview.mdx) | @@ -65,7 +65,7 @@ Application backup can protect namespaces, Kubernetes resources, and persistent ## Recovery Checklist -Use this checklist to choose follow-up work. It does not replace the linked procedures: +Use this checklist to choose follow-up work. For detailed steps, follow the linked procedures: 1. Choose Single Cluster, Multi-Cluster, or Single Node during installation planning. 2. Size the `global` cluster and workload clusters from the scalability guidance. @@ -74,4 +74,4 @@ Use this checklist to choose follow-up work. It does not replace the linked proc 5. Run regular recovery checks and failover drills where your operational process requires them. 6. Verify platform access, `global` services, connected cluster access, and component-level recovery after failover or restore. -For the next documentation path, see [Learn More](./learn-more.mdx). +For related planning and operations paths, see [Learn More](./learn-more.mdx). diff --git a/docs/en/overview/cluster-management-models.mdx b/docs/en/overview/cluster-management-models.mdx index fb3ae0971..24a5ac1d3 100644 --- a/docs/en/overview/cluster-management-models.mdx +++ b/docs/en/overview/cluster-management-models.mdx @@ -36,7 +36,7 @@ Control-plane topology explains where Kubernetes control plane components run. HCP is an architecture for the control plane. It is not a Core default capability and is not a peer concept to IPI or UPI. -For more information, see [About Hosted Control Plane](../configure/clusters/about-hcp.mdx). +For more information, see [About Hosted Control Plane](../configure/hosted_control_planes/overview.mdx). ## Kubernetes Ownership And Onboarding \{#kubernetes-ownership-and-onboarding} @@ -70,7 +70,7 @@ After onboarding, expected day-2 management is treated as the same at the Overvi Third-party cluster onboarding does not mean that manages every Kubernetes version, provider operation, node operation, certificate, control-plane metric, audit source, ingress path, storage class, or Extension image on every third-party cluster. -For 4.3, third-party Kubernetes clusters are accepted for onboarding only in the range `>=1.19.0 <1.35.0`. Clusters outside that range are blocked from onboarding. This is an onboarding gate, not a complete product validation matrix for every Kubernetes version, provider, operation, or Extension. +For 4.3, third-party Kubernetes clusters are accepted for onboarding only in the range `>=1.19.0 <1.35.0`. Clusters outside that range are blocked from onboarding. Treat this range as an onboarding gate, not as a complete product validation matrix for every Kubernetes version, provider, operation, or Extension. For the exact matrix and upgrade relationship, see [Kubernetes Support Matrix](./kubernetes-support-matrix.mdx) and [Version and Lifecycle](./version-and-lifecycle.mdx). @@ -81,9 +81,9 @@ Use the following caveat categories to decide which provider or workflow documen | Caveat category | What to check | Continue with | | --- | --- | --- | | Kubernetes lifecycle | Whether Kubernetes installation or upgrade is managed by or by the external owner. | [Clusters Overview](../configure/clusters/overview.mdx) | -| Node lifecycle | Whether adding, deleting, or scaling nodes is supported from the platform UI for the selected model. | [Node Management](../configure/clusters/nodes/overview.mdx) | -| Connectivity | Whether the `global` cluster and target cluster can reach the required endpoints and whether a platform URL annotation is needed. | [Managed Cluster Network Configuration](../configure/clusters/managed/how-to/annotate-platform-url.mdx) | -| Certificates | Which certificates are visible or rotated by the platform for the selected workflow. | Provider or onboarding workflow docs under [Import Clusters](../configure/clusters/managed/import/overview.mdx) | +| Node lifecycle | Whether adding, deleting, or scaling nodes is supported from the platform UI for the selected model. | [Node Management](../configure/nodes/overview.mdx) | +| Connectivity | Whether the `global` cluster and target cluster can reach the required endpoints and whether a platform URL annotation is needed. | [Network Configuration for Imported Clusters](../configure/clusters/managed/how-to/annotate-platform-url.mdx) | +| Certificates | Which certificates are visible or rotated by the platform for the selected workflow. | Provider or onboarding workflow docs under [Import Third-Party Clusters](../configure/clusters/managed/import/overview.mdx) | | Audit and metrics | Whether audit data and control-plane metrics are available from the target environment. | [Audit](../security/audit/intro.mdx) and provider workflow docs | | Ingress and storage | Whether post-import initialization is required for ingress, load balancing, or storage classes. | [Public Cloud Cluster Initialization](../configure/clusters/managed/cloud-init/index.mdx) | | Extension compatibility | Whether the exact Operator or Cluster Plugin version supports the target version and cluster model. | [Core and Extensions](./core-and-extensions.mdx) | diff --git a/docs/en/overview/glossary.mdx b/docs/en/overview/glossary.mdx index 87670016d..a65d800ea 100644 --- a/docs/en/overview/glossary.mdx +++ b/docs/en/overview/glossary.mdx @@ -29,8 +29,8 @@ Use this glossary to interpret platform-wide terms in . F | Project | A platform governance unit for a tenant, team, or business system. A project can span multiple associated clusters and acts as a boundary for quotas, policies, users, and namespace ownership. | [Project Introduction](../security/project/intro.mdx) | | Namespace | A Kubernetes namespace managed directly or indirectly by the platform. In , a namespace can belong to a project and inherit project-level governance. | [Namespace Management](../developer/building_application/namespace/index.mdx) | | Control plane | The Kubernetes management layer that runs components such as the API server, scheduler, controller manager, and etcd. | [Architecture](./architecture.mdx) | -| Control plane node | A node that runs Kubernetes control plane components for a cluster using a dedicated control-plane topology. | [Node Management](../configure/clusters/nodes/overview.mdx) | -| Worker node | A node that runs application workloads and cluster-local supporting components. | [Node Management](../configure/clusters/nodes/overview.mdx) | +| Control plane node | A node that runs Kubernetes control plane components for a cluster using a dedicated control-plane topology. | [Node Management](../configure/nodes/overview.mdx) | +| Worker node | A node that runs application workloads and cluster-local supporting components. | [Node Management](../configure/nodes/overview.mdx) | ## Extension And Packaging Terms @@ -66,7 +66,7 @@ Use this glossary to interpret platform-wide terms in . F | --- | --- | --- | | Platform Access Address | The external address used to access platform services such as the web console and platform APIs. It can be the same as the Cluster Endpoint or a separate address for external access scenarios. | [Installing](../install/installing.mdx) | | Cluster Endpoint | The address used by cluster components and administrators to reach the target Kubernetes control plane endpoint. | [Installing](../install/installing.mdx) | -| LoadBalancer | A Kubernetes Service type that exposes a Service through an external load balancer. In the platform, load-balancing can also involve external devices, VIPs, or provider-specific services. | [Configure Services](../configure/networking/functions/configure_service.mdx) | +| LoadBalancer | A Kubernetes Service type that exposes a Service through an external load balancer. In the platform, load-balancing can also involve external devices, VIPs, or provider-specific services. | [Configure Services](../networking/functions/configure_service.mdx) | | Self-built VIP | The built-in virtual IP option used when an external load balancer is not provided for the Cluster Endpoint. | [Prerequisites](../install/prepare/prerequisites.mdx) | | Cluster Proxy | A platform communication capability used to connect the `global` cluster and managed clusters for supported management operations. | [Architecture](./architecture.mdx) | | Import cluster | An onboarding method where the `global` cluster connects to the target third-party cluster API server with supplied address, CA, and credentials. | [Import Clusters](../configure/clusters/managed/import/overview.mdx) | diff --git a/docs/en/overview/introduction.mdx b/docs/en/overview/introduction.mdx index 425bd5a84..3ced98e58 100644 --- a/docs/en/overview/introduction.mdx +++ b/docs/en/overview/introduction.mdx @@ -35,4 +35,4 @@ If you are new to , read these pages first: 2. [Platform Model](./platform-model.mdx) to understand the `global` cluster, workload clusters, third-party clusters, projects, and namespaces. 3. [Cluster Management Models](./cluster-management-models.mdx) to understand infrastructure responsibility, control-plane topology, and third-party onboarding. 4. [Core and Extensions](./core-and-extensions.mdx) to understand which capabilities belong to Core and which require an Extension. -5. [Learn More](./learn-more.mdx) to choose the next documentation path for installation, cluster operations, application delivery, upgrade planning, recovery, security, API, or CLI tasks. +5. [Learn More](./learn-more.mdx) to choose the next task path for installation, cluster operations, application delivery, upgrade planning, recovery, security, API, or CLI work. diff --git a/docs/en/overview/learn-more.mdx b/docs/en/overview/learn-more.mdx index 4780ec17d..81e827a46 100644 --- a/docs/en/overview/learn-more.mdx +++ b/docs/en/overview/learn-more.mdx @@ -4,7 +4,7 @@ weight: 120 # Learn More -Choose the next documentation path for installation, cluster operations, application delivery, upgrade planning, availability and recovery, security, API, or CLI tasks. +Choose the next task path for installation, cluster operations, application delivery, upgrade planning, availability and recovery, security, API, or CLI work. ## Understand The Platform @@ -35,8 +35,8 @@ Choose the next documentation path for installation, cluster operations, applica | Create lifecycle-managed workload clusters. | [Clusters Overview](../configure/clusters/overview.mdx) | | Create on-premises workload clusters. | [Creating an On-Premise Cluster](../configure/clusters/on-premises.mdx) | | Use Immutable Infrastructure. | [About Immutable Infrastructure](../configure/clusters/immutable-infra.mdx) | -| Evaluate HCP for a non-production 4.3 scenario. | [About Hosted Control Plane](../configure/clusters/about-hcp.mdx) | -| Onboard existing third-party Kubernetes environments by import. | [Import Clusters](../configure/clusters/managed/import/overview.mdx) | +| Evaluate HCP for a non-production 4.3 scenario. | [About Hosted Control Plane](../configure/hosted_control_planes/overview.mdx) | +| Onboard existing third-party Kubernetes environments by import. | [Import Third-Party Clusters](../configure/clusters/managed/import/overview.mdx) | | Onboard existing third-party Kubernetes environments by register. | [Register Cluster](../configure/clusters/managed/register.mdx) | | Access a cluster with KubeConfig. | [Access a Cluster with KubeConfig](../configure/clusters/how-to/access-cluster-with-kubeconfig.mdx) | @@ -49,7 +49,7 @@ Choose the next documentation path for installation, cluster operations, applica | Manage Kubernetes workloads. | [Application Workloads](../developer/building_application/application_workloads/index.mdx) | | Manage namespaces. | [Namespace Management](../developer/building_application/namespace/index.mdx) | | View application logs, events, and monitoring dashboards. | [Application Observability](../developer/building_application/application_observability/index.mdx) | -| Work with container images and registries. | [Images](../developer/images/overview.mdx) and [Registry](../developer/registry/intro.mdx) | +| Work with container images and registries. | [Images](../developer/images/overview.mdx) and [Registry](../configure/registry/overview.mdx) | ## Install And Use Extensions diff --git a/docs/en/overview/platform-model.mdx b/docs/en/overview/platform-model.mdx index 1d9c79638..51eecced2 100644 --- a/docs/en/overview/platform-model.mdx +++ b/docs/en/overview/platform-model.mdx @@ -34,7 +34,7 @@ For third-party clusters, does not own the complete `Third-party cluster` is the product-model term for these onboarded environments. `Managed Cluster` is the current UI and navigation label for the interface that manages them. -For onboarding workflows, see [Managed Clusters Overview](../configure/clusters/managed/overview.mdx), [Import Clusters](../configure/clusters/managed/import/overview.mdx), and [Register Cluster](../configure/clusters/managed/register.mdx). +For onboarding workflows, see [Third-Party Cluster Onboarding](../configure/clusters/managed/overview.mdx), [Import Third-Party Clusters](../configure/clusters/managed/import/overview.mdx), and [Register Cluster](../configure/clusters/managed/register.mdx). ## Hosted Control Plane @@ -42,7 +42,7 @@ Hosted Control Plane (HCP) is a control-plane topology, not a cluster model para For 4.3, HCP is Technology Preview, is not production-supported, supports disconnected environments, and currently defaults to IPI only. Do not use HCP documentation as production topology, sizing, HA, or backup/restore guidance for 4.3. -For HCP scope and tasks, see [About Hosted Control Plane](../configure/clusters/about-hcp.mdx). +For HCP scope and tasks, see [About Hosted Control Plane](../configure/hosted_control_planes/overview.mdx). ## Projects And Namespaces diff --git a/docs/en/storage/index.mdx b/docs/en/storage/index.mdx index 049db225a..c0790bfc0 100644 --- a/docs/en/storage/index.mdx +++ b/docs/en/storage/index.mdx @@ -1,8 +1,9 @@ --- weight: 54 sourceSHA: 794f8ae5e5a2c350558a0fe1c84e1bc7ea216c4a552165c9ec77efeadd2c9a7e +title: Storage Systems --- -# Storage +# Storage Systems diff --git a/docs/en/virtualization/virtualization/installation.mdx b/docs/en/virtualization/virtualization/installation.mdx index 2dcd59fbf..e3e6d372a 100644 --- a/docs/en/virtualization/virtualization/installation.mdx +++ b/docs/en/virtualization/virtualization/installation.mdx @@ -13,7 +13,7 @@ In order for project personnel to fully utilize virtualization features within t - When using virtualization features, it is necessary to plan and prepare the network and storage environments in advance. **Note**: - - If you need to connect to the virtual machine directly via IP, the cluster must use the Kube-OVN Underlay network mode. You can refer to the best practices [Preparing Kube-OVN Underlay Physical Network](/configure/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx). + - If you need to connect to the virtual machine directly via IP, the cluster must use the Kube-OVN Underlay network mode. You can refer to the best practices [Preparing Kube-OVN Underlay Physical Network](/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx). - It is recommended to use TopoLVM with Kubevirt, as it can provide near-hardware-level performance. If performance requirements are not high, Ceph distributed storage can also be used. | Storage Product | Description | diff --git a/docs/en/virtualization/virtualization/network/functions/vm_network.mdx b/docs/en/virtualization/virtualization/network/functions/vm_network.mdx index 62c7dfb34..950591c82 100644 --- a/docs/en/virtualization/virtualization/network/functions/vm_network.mdx +++ b/docs/en/virtualization/virtualization/network/functions/vm_network.mdx @@ -6,7 +6,7 @@ Refs to [Configure IP](../../virtual_machine/functions/virtual_management.mdx#co ## Connect to the virtual machine directly via IP -Refs to [Preparing Kube-OVN Underlay Physical Network](/configure/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx) +Refs to [Preparing Kube-OVN Underlay Physical Network](/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx) ## Add Service diff --git a/docs/en/virtualization/virtualization/virtual_machine/functions/virtual_management.mdx b/docs/en/virtualization/virtualization/virtual_machine/functions/virtual_management.mdx index aa63edec4..a06247d71 100644 --- a/docs/en/virtualization/virtualization/virtual_machine/functions/virtual_management.mdx +++ b/docs/en/virtualization/virtualization/virtual_machine/functions/virtual_management.mdx @@ -109,7 +109,7 @@ When using NAT network mode, the platform by default opens port 22 for SSH servi 4. In the **Login Information** section, click the icon to the right of Internal Route. -5. Refer to the [Create Service](/configure/networking/functions/configure_service.mdx) page for quick addition of internal routes for the virtual machine. +5. Refer to the [Create Service](/networking/functions/configure_service.mdx) page for quick addition of internal routes for the virtual machine. 6. Click **Confirm**. diff --git a/docs/en/virtualization/virtualization/virtual_machine/how_to/vm_precopy.mdx b/docs/en/virtualization/virtualization/virtual_machine/how_to/vm_precopy.mdx index cac76b58e..2b2f6963c 100644 --- a/docs/en/virtualization/virtualization/virtual_machine/how_to/vm_precopy.mdx +++ b/docs/en/virtualization/virtualization/virtual_machine/how_to/vm_precopy.mdx @@ -48,7 +48,7 @@ For specific creation steps, please refer to [Create HyperConverged Instance](.. ### Prepare the Virtual Machine -**Note**: It is recommended to use the Kube-OVN Underlay network. For related configurations, please refer to [Create Subnet (Kube-OVN Underlay Network)](/configure/networking/functions/configure_subnet.mdx#kube_ovn_underlay_network). +**Note**: It is recommended to use the Kube-OVN Underlay network. For related configurations, please refer to [Create Subnet (Kube-OVN Underlay Network)](/networking/functions/configure_subnet.mdx#kube_ovn_underlay_network). 1. Go to **Container Platform**. diff --git a/docs/public/en/img/113point.png b/docs/public/en/img/113point.png new file mode 100644 index 000000000..fccfbc505 Binary files /dev/null and b/docs/public/en/img/113point.png differ diff --git a/docs/public/zh/img/00phase.png b/docs/public/zh/img/00phase.png new file mode 100644 index 000000000..e48541182 Binary files /dev/null and b/docs/public/zh/img/00phase.png differ diff --git a/doom.config.yml b/doom.config.yml index fda28d5bc..e5c9dd10c 100644 --- a/doom.config.yml +++ b/doom.config.yml @@ -73,19 +73,43 @@ export: - name: acp_cli scope: - '*/ui/cli_tools/ac/' - - name: configure_cluster + - name: configure_clusters scope: - '*/configure/clusters/' - - name: configure_machine + - name: configure_postinstallation + scope: + - '*/configure/postinstallation/' + - name: configure_hosted_control_planes + scope: + - '*/configure/hosted_control_planes/' + - name: configure_nodes + scope: + - '*/configure/nodes/' + - name: configure_etcd + scope: + - '*/configure/etcd/' + - name: configure_machine_config scope: - '*/configure/machine_config/' - - name: configure_network + - name: configure_backup + scope: + - '*/configure/backup/' + - name: configure_registry + scope: + - '*/configure/registry/' + - name: configure_platform_settings + scope: + - '*/configure/platform_settings/' + - name: configure_scalability + scope: + - '*/configure/scalability/' + - name: networking scope: - - '*/configure/networking/' + - '*/networking/' - name: configure_storage scope: - '*/configure/storage/' - - name: storage + - name: storage_systems scope: - '*/storage/' - name: security diff --git a/llms.txt b/llms.txt index 646313e98..395d22ff3 100644 --- a/llms.txt +++ b/llms.txt @@ -62,12 +62,11 @@ Includes CRD definitions and comprehensive platform guides. - [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/clusters/about-hcp.mdx](docs/en/configure/clusters/about-hcp.mdx): Brief introduction to Hosted Control Plane (HCP) in ACP: containerized cluster control planes hosted inside a management cluster, separated from worker nodes, providing faster creation/upgrades and better scalability for multi-cluster setups. Embeds the dedicated HCP external documentation site. -- [docs/en/configure/clusters/acp-node-planning.mdx](docs/en/configure/clusters/acp-node-planning.mdx): How to plan cluster node roles using the `node-role.kubernetes.io/` 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/clusters/etcd-encryption.mdx](docs/en/configure/clusters/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/nodes/node_planning.mdx](docs/en/configure/nodes/node_planning.mdx): How to plan cluster node roles using the `node-role.kubernetes.io/` 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:///kubernetes/` 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/clusters/how-to/config_resource_manager_policy.mdx](docs/en/configure/clusters/how-to/config_resource_manager_policy.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/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. @@ -96,46 +95,45 @@ Includes CRD definitions and comprehensive platform guides. - [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/clusters/nodes/in-place-os-upgrade.mdx](docs/en/configure/clusters/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/clusters/nodes/node-add.mdx](docs/en/configure/clusters/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/clusters/nodes/node-management.mdx](docs/en/configure/clusters/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/clusters/nodes/node-monitoring.mdx](docs/en/configure/clusters/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/nodes/overview.mdx](docs/en/configure/clusters/nodes/overview.mdx): Concept page defining cluster nodes as VMs or physical servers running Kubelet, Kube-proxy, and a container runtime, and contrasting Control Plane Nodes (kube-apiserver, kube-scheduler, kube-controller-manager, etcd) with Compute Nodes. States the 1/3/5 control-plane HA rule, the prohibition on node add/delete for imported clusters, and points to node availability and OS/kernel/CPU compatibility references. +- [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/feature_toggles.mdx](docs/en/configure/feature_toggles.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/configure/networking/functions/configure_alb.mdx](docs/en/configure/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/configure/networking/functions/configure_certificate.mdx](docs/en/configure/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/configure/networking/functions/configure_coredns.mdx](docs/en/configure/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/configure/networking/functions/configure_domain.mdx](docs/en/configure/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/configure/networking/functions/configure_gatewayapi_gateway.mdx](docs/en/configure/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/configure/networking/functions/configure_gatewayapi_policy.mdx](docs/en/configure/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/configure/networking/functions/configure_gatewayapi_route.mdx](docs/en/configure/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/configure/networking/functions/configure_ingress.mdx](docs/en/configure/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/configure/networking/functions/configure_metallb.mdx](docs/en/configure/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/configure/networking/functions/configure_node_local_dns.mdx](docs/en/configure/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=` 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/configure/networking/functions/configure_service.mdx](docs/en/configure/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/configure/networking/functions/configure_subnet.mdx](docs/en/configure/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/configure/networking/how_to/alb/tasks_for_alb.mdx](docs/en/configure/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/configure/networking/how_to/configure_endpoint_health_checker.mdx](docs/en/configure/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/configure/networking/how_to/kube_ovn/config_metallb_underlay.mdx](docs/en/configure/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/configure/networking/how_to/kube_ovn/configure_bgp.mdx](docs/en/configure/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/configure/networking/how_to/kube_ovn/configure_centralized_gateway.mdx](docs/en/configure/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 `:` 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/configure/networking/how_to/kube_ovn/configure_egress_gateway.mdx](docs/en/configure/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/configure/networking/how_to/kube_ovn/configure_ippool.mdx](docs/en/configure/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/configure/networking/how_to/kube_ovn/configure_mtu.mdx](docs/en/configure/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 -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/configure/networking/how_to/kube_ovn/configure_ovn_interconnection.mdx](docs/en/configure/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/configure/networking/how_to/kube_ovn/kubeovn_underlay_py.mdx](docs/en/configure/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/configure/networking/how_to/kube_ovn/multiple_networks.mdx](docs/en/configure/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 `..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 `.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/configure/networking/how_to/kube_ovn/underlay_overlay_st.mdx](docs/en/configure/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 == `, and `priority` in the 1002-1899 range. -- [docs/en/configure/networking/how_to/kube_ovn/understanding_kube_ovn.mdx](docs/en/configure/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/configure/networking/how_to/soft_data_center_lb_solution.mdx](docs/en/configure/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/configure/networking/how_to/task_for_migrate_from_ocp_route_to_gatewayapi_route.mdx](docs/en/configure/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/configure/networking/how_to/tasks_for_envoy_gateway.mdx](docs/en/configure/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/configure/networking/how_to/tasks_for_ingress_nginx.mdx](docs/en/configure/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/configure/networking/trouble_shooting/arm_checksum.mdx](docs/en/configure/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/configure/networking/trouble_shooting/find_who_cause_the_error.mdx](docs/en/configure/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/configure/notification/cluster_notification.mdx](docs/en/configure/notification/cluster_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/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=` 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 `:` 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 -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 `..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 `.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 == `, 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. @@ -267,12 +265,10 @@ Includes CRD definitions and comprehensive platform guides. - [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://:; 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//:). -- [docs/en/developer/registry/how_to/registry_data_restore.mdx](docs/en/developer/registry/how_to/registry_data_restore.mdx): End-to-end backup-and-recovery runbook for the Alauda Container Platform Registry when backed by S3-compatible object storage, extracting bucket, regionEndpoint, region, and secretName from the `image-registry` ModuleInfo resource on the global cluster, using awscli/rclone/minio-client to copy bucket contents, restoring to a new bucket (for example `registry-bucket-restored`), and then `kubectl patch moduleinfo` to point the new install at the restored bucket so the platform rolls out new Pods automatically; verification uses `/v2/_catalog` and `/v2//tags/list` against the in-cluster Service IP. The pattern generalizes to Local, StorageClass, and NAS backends. - [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//:` 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=:default`; closes with troubleshooting for ImagePullBackOff and /etc/hosts DNS resolution for `image-registry.cpaas-system.svc`. -- [docs/en/developer/registry/install/install_via_web_ui.mdx](docs/en/developer/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/developer/registry/install/install_via_yaml.mdx](docs/en/developer/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/developer/registry/intro.mdx](docs/en/developer/registry/intro.mdx): Product introduction for the Alauda Container Platform Registry, a built-in high-availability image repository integrated with the platform's authentication and namespace-based RBAC (Push/Pull controlled per namespace, with cross-namespace access requiring explicit role bindings), positioned for lightweight, edge, and resource-constrained deployments alongside S2I; highlights advantages such as ready-to-use deployment, image scanning, replication-based HA, and SLA-validated production grade. -- [docs/en/developer/registry/upgrade/registry_plugin_upgrade_guide.mdx](docs/en/developer/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/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.
    Parameter
    Network Access ProtocolFor specific details, please refer to the [Creating Service](/configure/networking/functions/configure_service.mdx) section for the Port parameter description.For specific details, please refer to the [Creating Service](/networking/functions/configure_service.mdx) section for the Port parameter description.