Using the Karmada API

Karmada API Description

Karmada API is the application that serves Karmada functionality through a RESTful interface and stores the state of Karmada. Federated resources can be obtained, created, updated, and deleted via HTTP calls (POST, PUT, PATCH, DELETE, and GET) to the API. For details, see Karmada API.

UCS can call Karmada API through API Gateway.

Calling Karmada API Through API Gateway

1. Log in to the UCS console and click the name of the target fleet to go to its details page. Then, click kubectl in Fleet Info.
2. Select a project, VPC, master node subnet, and validity period as prompted and click Download to download the kubectl configuration file.

   The name of the downloaded file is kubeconfig.json.

   

   If the kubeconfig.json file is leaked, your clusters may be attacked. Keep it secure.

   The validity period of the kubectl configuration file can be set as required. The options are 5 years, 1 year, 6 months, 30 days, and 15 days to 1 day. The minimum value is 1 day.

3. Install and configure kubectl on the executor.
   1. Copy kubectl and its configuration file to the /home directory on the executor in the selected VPC and subnet.
   2. Log in to your executor and configure kubectl.

      cd /home

      chmod +x kubectl

      mv -f kubectl /usr/local/bin

      mkdir -p $HOME/.kube

      mv -f kubeconfig.json $HOME/.kube/config

4. Determine the requested URL based on the URL format.
   • {Fleet name} indicates the fleet name, which can be obtained from the basic fleet information on the console.
   • {Region} indicates the URL of the region that the service belongs to, which can be obtained from Endpoints.
   • {URL} Access path of an API for performing an operation on resources. Obtain the value from the URI of the API. For details, see Karmada API.

   The following is an example URL for calling the API to view information about all Deployments in the federation:

   https://r******.fleet.ucs.cn-north-4-dev.myhuaweicloud.com/apis/apps/v1/namespaces/default/deployments

5. Obtain the bearer token corresponding to the request for creating an Admin Role.
   1. Save the following content to the admin-role.yaml file:

      kind: ClusterRoleBinding
      apiVersion: rbac.authorization.k8s.io/v1
      metadata:
        name: admin
        annotations:
          rbac.authorization.kubernetes.io/autoupdate: "true"
      roleRef:
        kind: ClusterRole
        name: cluster-admin
        apiGroup: rbac.authorization.k8s.io
      subjects:
      - kind: ServiceAccount
        name: admin
        namespace: kube-system
      ---
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: admin
        namespace: kube-system
        labels:
          kubernetes.io/cluster-service: "true"
          addonmanager.kubernetes.io/mode: Reconcile

   2. Run the kubectl apply -f admin-role.yaml command to create the service account and permissions.
   3. Run the kubectl create token admin --namespace kube-system command to obtain the bearer token of the service account.
   4. Set the environment variable token to the bearer token obtained in the previous step.

6. Use the request method specified by the API and set the request header parameters. If parameters in the body need to be added, add the structure corresponding to the API by referring to Karmada API.

   Example curl command to call the API for creating a Deployment using POST and adding the corresponding body:

   In this example, the nginx.json file is used to create a Deployment named nginx. The Deployment uses the nginx:latest image and contains two pods. Each pod occupies 100m CPU and 200 MiB memory. After the Deployment is created, you can refer to the preceding steps to obtain the URI of PropagationPolicy from Karmada API and create a distribution policy.

   curl --location --request POST 'https://r*****.fleet.ucs.cn-north-4-dev.myhuaweicloud.com/apis/apps/v1/deployments' \
   --header 'Content-Type: application/json' \
   --header 'Authorization: Bearer $token' \
   --data @nginx.json

   The following table lists the header parameters contained in the request.

   Table 2 Parameters in the request header

   Parameter	Mandatory	Data Type	Description
   Content-Type	Yes	String	Message body type (format), for example, application/json.
   Authorization	Yes	String	For details about how to obtain the bearer token, see 5.

   The content of the nginx.json file is as follows:

   {
       "apiVersion": "apps/v1",
       "kind": "Deployment",
       "metadata": {
           "name": "nginx"
       },
       "spec": {
           "replicas": 2,
           "selector": {
               "matchLabels": {
                   "app": "nginx"
               }
           },
           "template": {
               "metadata": {
                   "labels": {
                       "app": "nginx"
                   }
               },
               "spec": {
                   "containers": [
                       {
                           "image": "nginx:latest",
                           "name": "container-0",
                           "resources": {
                               "limits": {
                                   "cpu": "100m",
                                   "memory": "200Mi"
                               },
                               "requests": {
                                   "cpu": "100m",
                                   "memory": "200Mi"
                               }
                           }
                       }
                   ],
                   "imagePullSecrets": [
                       {
                           "name": "default-secret"
                       }
                   ]
               }
           }
       }
   }