Feature implementation from commits 984acef..c91d1b4

docs/administrator/security/security-considerations.md

@@ -30,3 +30,69 @@ To avoid the use of insecure algorithms such as 3DES during the communication pr
 
 Set Golang's secure cipher suite to etcd's cipher suite. They are obtained through the return value of the function "CipherSuites()" under the "go/src/crypto/tls/cipher_suites.go" package. Consistent with the "preferred value" of the k8s default cipher suite.
 
+#### Binding Address Configuration
+
+Karmada components provide configurable parameters for users to configure listening addresses and ports. When a user deploys a Karmada component, the Karmada component will use the default listening address and port if the listening-related parameters are not configured. The default listening address of the Karmada component is `0.0.0.0`, which means that the component will listen to all network interfaces on the server (for a container, this is a virtual network interface that is managed by the container runtime, such as Docker).
+
+The following are the configurable parameters provided by the Karmada component:
+
+- karmada-controller-manager
+    - `--metrics-bind-address`: default is `:8080`.
+    - `--health-probe-bind-address`: default is `:10357`.
+- karmada-scheduler
+    - `--metrics-bind-address`: default is `:8080`.
+    - `--health-probe-bind-address`: default is `:10351`.
+- karmada-scheduler-estimator
+    - `--metrics-bind-address`: default is `:8080`.
+    - `--health-probe-bind-address`: default is `:10351`.
+- karmada-descheduler
+    - `--metrics-bind-address`: default is `:8080`.
+    - `--health-probe-bind-address`: default is `:10358`.
+- karmada-aggregated-apiserver
+    - `--bind-address`: default is `0.0.0.0`.
+    - `--secure-port`: default is `443`.
+- karmada-metrics-adapter
+    - `--metrics-bind-address`: default is `:8080`.
+    - `--bind-address`: default is `0.0.0.0`.
+    - `--secure-port`: default is `443`.
+- karmada-webhook
+    - `--metrics-bind-address`: default is `:8080`.
+    - `--health-probe-bind-address`: default is `:8000`.
+    - `--bind-address`: default is `0.0.0.0`.
+    - `--secure-port`: default is `8443`.
+- karmada-search
+    - `--bind-address`: default is `0.0.0.0`.
+    - `--secure-port`: default is `443`.
+- karmada-agent
+    - `--metrics-bind-address`: default is `:8080`.
+    - `--health-probe-bind-address`: default is `:10357`.
+
+Users can configure the listening address as a Pod IP value. For example, you can configure the metrics interface of the `karmada-controller-manager` component as follows:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: karmada-controller-manager
+  namespace: karmada-system
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: karmada-controller-manager
+  template:
+    metadata:
+      labels:
+        app: karmada-controller-manager
+    spec:
+      containers:
+      - name: my-container
+        env:
+        - name: POD_IP
+          valueFrom:
+            fieldRef:
+              fieldPath: status.podIP
+        command:
+        - /bin/karmada-controller-manager
+        - --metrics-bind-address=$(POD_IP):8080
+```

docs/developers/document-releasing.md

@@ -16,7 +16,7 @@ This issue is to track documents which needs to sync zh for release 1.x:
 
 ## Update Reference Documents(manually)
 
-Before releasing, we need to update reference docs in the website, which includes CLI references and component references. The whole process is done by scripts automatically.
+Before releasing, we need to update reference docs in the website, which includes CLI references, component references and API documentation. The whole process is done by scripts automatically.
 Follow these steps to update reference docs.
 
 1. Clone `karmada-io/karmada` and `karmada-io/website` to the local environment. It's recommended to step up these two projects in the same folder.
@@ -32,7 +32,7 @@ $ tree -L 1
 #├── website
 ```
 
-2. Run generate command in karmada root dir.
+2. Run generate command in karmada root dir to generate CLI references.
 
 ```shell
 cd karmada/
@@ -46,11 +46,20 @@ go run ./hack/tools/genkarmadactldocs/gen_karmadactl_docs.go ../website/i18n/zh/
 cd karmada/
 go build ./hack/tools/gencomponentdocs/.
 
-components=(karmada-controller-manager karmada-scheduler karmada-agent karmada-aggregated-apiserver karmada-descheduler karmada-search karmada-scheduler-estimator karmada-webhook karmada-metrics-adapter)
-for component in ${components};do 
-  ./gencomponentdocs ../website/docs/reference/components/ $component
-  ./gencomponentdocs ../website/i18n/zh/docusaurus-plugin-content-docs/current/reference/components/ $component
-done
+./gencomponentdocs ../website/docs/reference/components/ all
+./gencomponentdocs ../website/i18n/zh/docusaurus-plugin-content-docs/current/reference/components/ all
+```
+
+4. Generate API docs.
+
+Enter the website/infra/gen-resourcesdocs directory.
+```shell
+cd website/infra/gen-resourcesdocs
+```
+Modify the file `config/current/toc.yaml` according to the guidance in `README.md`.
+Run the script `hack/reference-api.sh`.
+```shell
+hack/reference-api.sh
 ```
 
 ## Setup release-1.x(manually)
@@ -82,7 +91,7 @@ cp versioned_sidebars/version-v1.4-sidebars.json versioned_sidebars/version-v1.5
 sed -i'' -e "s/version-v1.4/version-v1.5/g" versioned_sidebars/version-v1.5-sidebars.json
 ```
 
-Then, update `version-v1.5-sidebars.json` based on `sidebars.js`.
+**Note: update `version-v1.5-sidebars.json` based on `sidebars.js`.**
 
 4. Update versioned_docs for zh
 

docs/developers/secure-coding-specifications.md

@@ -0,0 +1,15 @@
+---
+title: Secure Coding Specifications
+---
+
+This article is a checklist. When you write code, you need to check whether the new code violates the following items.
+
+1. It is prohibited to have authentication credentials that cannot be modified (e.g., hard-coded passwords in process binaries).
+2. If implemented using interpreted languages (such as Shell/Python/Perl scripts, JSP, HTML, etc.), for functions that do not meet the requirement of undisclosed interfaces and need to be cleaned up, they must be completely deleted. It is strictly prohibited to use forms such as comment lines to merely disable the functions.
+3. It is prohibited to use private cryptographic algorithms for encryption and decryption, including:
+    - Cryptographic algorithms designed independently without being evaluated by professional institutions;
+    - Self-defined data conversion algorithms executed through methods such as deformation/character shifting/replacement;
+    - Pseudo-encryption implementations that use encoding methods (such as Base64 encoding) to achieve the purpose of data encryption.
+    Note: In scenarios other than encryption and decryption, the use of encoding methods such as Base64 or algorithms such as deformation/shifting/replacement for legitimate business purposes does not violate this provision.
+4. The random numbers used in cryptographic algorithms must be secure random numbers in the cryptographic sense.
+5. It is prohibited to print authentication credentials (passwords/private keys/pre-shared keys) in plain text in system-stored logs, debugging information, and error prompts.

docs/installation/install-binary.md

@@ -673,6 +673,29 @@ livez check passed
 ###### karmada-aggregated-apiserver check success
 ```
 
+## Prepare Karmada CRDs Resources
+
+Execute operations at `karmada-01`.
+
+```bash
+git clone https://github.com/karmada-io/karmada
+cd karmada/charts/karmada/_crds/bases
+
+kubectl apply -f .
+
+cd ../patches/
+ca_string=$(cat /etc/karmada/pki/server-ca.crt | base64 | tr "\n" " "|sed s/[[:space:]]//g)
+sed -i "s/{{caBundle}}/${ca_string}/g" webhook_in_resourcebindings.yaml
+sed -i "s/{{caBundle}}/${ca_string}/g"  webhook_in_clusterresourcebindings.yaml
+# You need to change 172.31.209.245:4443 to your Load Balancer host:port.
+sed -i 's/karmada-webhook.karmada-system.svc:443/172.31.209.245:4443/g' webhook_in_resourcebindings.yaml
+sed -i 's/karmada-webhook.karmada-system.svc:443/172.31.209.245:4443/g' webhook_in_clusterresourcebindings.yaml
+
+kubectl patch CustomResourceDefinition resourcebindings.work.karmada.io --patch-file webhook_in_resourcebindings.yaml
+kubectl patch CustomResourceDefinition clusterresourcebindings.work.karmada.io --patch-file webhook_in_clusterresourcebindings.yaml
+cd ../../../../..
+```
+
 ## Install kube-controller-manager
 
 Execute operations at `karmada-01` `karmada-02` `karmada-03`.  Take `karmada-01` as an example.
@@ -965,26 +988,6 @@ ok
 
 ## Initialize Karmada
 
-Execute operations at `karmada-01`.
-
-```bash
-git clone https://github.com/karmada-io/karmada
-cd karmada/charts/karmada/_crds/bases
-
-kubectl apply -f .
-
-cd ../patches/
-ca_string=$(cat /etc/karmada/pki/server-ca.crt | base64 | tr "\n" " "|sed s/[[:space:]]//g)
-sed -i "s/{{caBundle}}/${ca_string}/g" webhook_in_resourcebindings.yaml
-sed -i "s/{{caBundle}}/${ca_string}/g"  webhook_in_clusterresourcebindings.yaml
-# You need to change 172.31.209.245:4443 to your Load Balancer host:port.
-sed -i 's/karmada-webhook.karmada-system.svc:443/172.31.209.245:4443/g' webhook_in_resourcebindings.yaml
-sed -i 's/karmada-webhook.karmada-system.svc:443/172.31.209.245:4443/g' webhook_in_clusterresourcebindings.yaml
-
-kubectl patch CustomResourceDefinition resourcebindings.work.karmada.io --patch-file webhook_in_resourcebindings.yaml
-kubectl patch CustomResourceDefinition clusterresourcebindings.work.karmada.io --patch-file webhook_in_clusterresourcebindings.yaml
-```
-
 Now, all the required components have been installed, and the member clusters could join Karmada control plane.
 If you want to use `karmadactl` to query, please run following command:
 ```sh

docs/reference/karmada-api/policy-resources/cluster-propagation-policy-v1alpha1.md

@@ -438,11 +438,9 @@ ClusterPropagationPolicy represents the cluster-wide policy that propagates a gr
 
       Behavior of PriorityClassName:
 
-      For KubePriorityClass: - When specified: Uses the named Kubernetes PriorityClass. - When empty: Uses the cluster's default PriorityClass (i.e., the PriorityClass marked as the global default in the cluster). - If neither exists: Sets priority=0 and preemptionPolicy=Never.
+      For KubePriorityClass: - When specified: Uses the named Kubernetes PriorityClass.
 
-      For PodPriorityClass: - Uses PriorityClassName from the PodTemplate. - If the specified PriorityClass is not found, falls back to the cluster's default PriorityClass
-        (i.e., the PriorityClass marked as the global default in the cluster).
-      - If no valid PriorityClass is found: Sets priority=0 and preemptionPolicy=Never. - Not yet implemented.
+      For PodPriorityClass: - Uses PriorityClassName from the PodTemplate. - Not yet implemented.
 
       For FederatedPriorityClass: - Not yet implemented.
 

docs/reference/karmada-api/policy-resources/propagation-policy-v1alpha1.md

@@ -438,11 +438,9 @@ PropagationPolicy represents the policy that propagates a group of resources to
 
       Behavior of PriorityClassName:
 
-      For KubePriorityClass: - When specified: Uses the named Kubernetes PriorityClass. - When empty: Uses the cluster's default PriorityClass (i.e., the PriorityClass marked as the global default in the cluster). - If neither exists: Sets priority=0 and preemptionPolicy=Never.
+      For KubePriorityClass: - When specified: Uses the named Kubernetes PriorityClass.
 
-      For PodPriorityClass: - Uses PriorityClassName from the PodTemplate. - If the specified PriorityClass is not found, falls back to the cluster's default PriorityClass
-        (i.e., the PriorityClass marked as the global default in the cluster).
-      - If no valid PriorityClass is found: Sets priority=0 and preemptionPolicy=Never. - Not yet implemented.
+      For PodPriorityClass: - Uses PriorityClassName from the PodTemplate. - Not yet implemented.
 
       For FederatedPriorityClass: - Not yet implemented.
 

docs/reference/karmadactl/operation-scope.md

@@ -0,0 +1,131 @@
+---
+title: Switching Cluster Perspective in Karmadactl
+
+---
+
+# Switching Cluster Perspective in Karmadactl
+
+Karmadactl introduces the flag `operation-scope` to specify the operation scope of Karmadactl commands. The value of the flag `operation-scope` is of enum type, with each enum value and its meaning as follows:
+
+- karmada: the operation scope of karmadactl is Karmada control plane.
+- members: the operation scope of karmadactl is member clusters.
+- all: the operation scope of karmadactl includes Karmada control plane and member clusters.
+
+> *Note that the operation-scope enumeration values supported by different commands are different, please refer to karmadactl [command] --help for details.*
+
+The introduction of `operation-scope` provides a flexible way to implement Karmadactl cluster perspective switching. Compared to Kubectl, Karmadactl can manage different target clusters without switching contexts. In addition, with Karmada's multi-cluster resource view, Karmadactl can access resource information of multiple target clusters at the same time, which greatly simplifies the daily operation and maintenance in multi-cluster scenarios.
+
+![command-context](../../resources/reference/karmadactl/command-context.png)
+
+## How to Use
+
+This section describes the application of the flag `operation-scope` to the various Karmadactl commands and uses `karmadactl get` as an example of how to see the distribution of resources across different clusters by switching cluster perspectives.
+
+### get
+
+The command `karmadactl get` can be used to view the resources of a control plane or member cluster. In combination with the flag `operation-scope` and `clusters`, `karmadactl get` can display information about the resources of a cluster or clusters.
+
+- `operation-scope`：The enumeration values `karmada`, `members`, and `all` are supported. Defaults to `karmada`.
+- `clusters`：Used to specify target member clusters and only takes effect when the command's operation scope is `members` or `all`.
+
+![operation-scope](../../resources/reference/karmadactl/operation-scope.png)
+
+Assume that the Karmada control plane manages three member clusters, member1, member2, and member3 and that the Karmada control plane's Deployment resource, `nginx`, is distributed to all three of these member clusters. Then, we can:
+
+- View the distribution of resources across the control plane and all member clusters.
+
+  ```bash
+  $ karmadactl get deployment nginx --operation-scope all      
+  NAME    CLUSTER   READY   UP-TO-DATE   AVAILABLE   AGE   ADOPTION
+  nginx   Karmada   0/2     6            0           18h   -
+  nginx   member1   0/2     2            0           37s   Y
+  nginx   member2   0/2     2            0           36s   Y
+  nginx   member3   0/2     2            0           37s   Y
+  ```
+
+  > *The CLUSTER column represents the cluster in which the resource resides, and the ADOPTION column represents whether the resource has been taken over by the Karmada control plane.*
+
+- View the distribution of resources across the control plane and some of the member clusters.
+
+  ```bash
+  $ karmadactl get deployment nginx --operation-scope all --clusters member1,member2
+  NAME    CLUSTER   READY   UP-TO-DATE   AVAILABLE   AGE     ADOPTION
+  nginx   Karmada   4/2     6            4           18h     -
+  nginx   member1   2/2     2            2           2m37s   Y
+  nginx   member2   0/2     2            0           2m36s   Y
+  ```
+
+  When `--clusters member1,member2` is set, the member cluster perspective of the command will be limited to clusters member1 and member2.
+
+- View the resource of Karmada control plane.
+
+  ```bash
+  $ karmadactl get deployment nginx 
+  NAME    CLUSTER   READY   UP-TO-DATE   AVAILABLE   AGE   ADOPTION
+  nginx   Karmada   6/2     6            6           18h   -
+  $ karmadactl get deployment nginx --operation-scope karmada 
+  NAME    CLUSTER   READY   UP-TO-DATE   AVAILABLE   AGE   ADOPTION
+  nginx   Karmada   6/2     6            6           18h   -
+  ```
+
+- View the distribution of resources across all member clusters.
+
+  ```bash
+  $ karmadactl get deployment nginx --operation-scope members
+  NAME    CLUSTER   READY   UP-TO-DATE   AVAILABLE   AGE     ADOPTION
+  nginx   member2   2/2     2            2           8m10s   Y
+  nginx   member1   2/2     2            2           8m11s   Y
+  nginx   member3   2/2     2            2           8m10s   Y
+  ```
+
+- View the distribution of resources across some of the member clusters.
+
+  ```bash
+  $ karmadactl get deployment nginx --operation-scope members --clusters member1,member2
+  NAME    CLUSTER   READY   UP-TO-DATE   AVAILABLE   AGE    ADOPTION
+  nginx   member1   2/2     2            2           9m7s   Y
+  nginx   member2   2/2     2            2           9m6s   Y
+  ```
+
+### describes
+
+In combination with the flag `operation-scope` and `cluster`, the `karmadactl describe` command can be used to display details of resources in Karmada control plane or a member cluster.
+
+- `operation-scope`：The enumeration values `karmada` and `members` are supported. Default to `karmada`.
+- `cluster`：Used to specify a target member cluster and only takes effect when the command's operation scope is `members`.
+
+### attach
+
+In combination with the flag `operation-scope` and `cluster`, the `karmadactl attach` command can attach to a running container in Karmada control plane or a member cluster.
+
+- `operation-scope`：The enumeration values `karmada` and `members` are supported. Default to `karmada`.
+
+- `cluster`：Used to specify a target member cluster and only takes effect when the command's operation scope is `members`.
+
+### explain
+
+In combination with the flag `operation-scope` and `cluster`, the `karmadactl explain` command can get documentation for a resource in Karmada control plane or a member cluster. This is especially convenient for scenarios where member cluster resources are differentially configured via `OverridePolicy`.
+
+- `operation-scope`：The enumeration values `karmada` and `members` are supported. Default to `karmada`.
+- `cluster`：Used to specify a target member cluster and only takes effect when the command's operation scope is `members`.
+
+### exec
+
+In combination with the flag `operation-scope` and `cluster`, the `karmadactl exec` command can execute a command in a container in Karmada control plane or a member cluster.
+
+- `operation-scope`：The enumeration values `karmada` and `members` are supported. Default to `karmada`.
+- `cluster`：Used to specify a target member cluster and only takes effect when the command's operation scope is `members`.
+
+### api-resources
+
+In combination with the flag `operation-scope` and `cluster`, the `karmadactl api-resources` command can print the supported API resources on the server in Karmada control plane or a member cluster.
+
+- `operation-scope`：The enumeration values `karmada` and `members` are supported. Default to `karmada`.
+- `cluster`：Used to specify a target member cluster and only takes effect when the command's operation scope is `members`.
+
+### api-versions
+
+In combination with the flag `operation-scope` and `cluster`, the `karmadactl api-versions` command can print the supported API versions on the server in Karmada control plane or a member cluster.
+
+- `operation-scope`：The enumeration values `karmada` and `members` are supported. Default to `karmada`.
+- `cluster`：Used to specify a target member cluster and only takes effect when the command's operation scope is `members`.