Help Center/ Cloud Container Engine/ API Reference/ Before You Start
Updated on 2024-11-06 GMT+08:00
View PDF
Share

Before You Start

Cloud Container Engine (CCE) is a container service that allows you to run containers efficiently in the cloud. CCE provides highly scalable, high-performance, enterprise-class Kubernetes clusters and supports Docker containers. With CCE, you can easily deploy, manage, and scale containerized applications in the cloud.

This document describes how to use APIs for performing operations on CCE, such as creating or deleting CCE resources, modifying resource specifications, or adding NICs. For details about all supported operations, see API Overview.

If you plan to access CCE resources through an API, ensure that you are familiar with CCE concepts. For details, see Service Overview.

CCE supports both Kubernetes-native APIs and proprietary APIs. With these APIs, you can use all functions of CCE.

  • CCE has opened APIs through API gateways to support operations on cloud service infrastructures (for example, creating a node). Operations on cluster resources (such as creating a workload) are also supported.
  • Kubernetes-native APIs: You can perform operations on cluster resources (such as creating a workload) using the Kubernetes-native API server. However, operations on cloud service infrastructures (such as creating a node) are not supported.

    For details about Kubernetes-native API versions, see https://kubernetes.io/docs/concepts/overview/kubernetes-api/.

    • The Kubernetes-native APIs called in the current version do not support HTTP persistent connections.
    • The Kubernetes-native APIs in the current version include Beta APIs, whose version names include beta, for example, v1beta1. This type of APIs varies according to Kubernetes-native APIs. Therefore, you are advised to use this type of APIs in unimportant scenarios, for example, short-term test clusters.

Endpoints

An endpoint is the request address for calling an API. Endpoints vary depending on services and regions. An endpoint can be obtained from Regions and Endpoints.

You need to select an endpoint based on your service requirements.

  • The URL format for cluster, node, node pool, add-on, and quota management is https://Endpoint/uri. uri indicates the resource path, that is, the API access path.
  • The URL format for Kubernetes APIs, storage management, and add-on management is https://{clusterid}.Endpoint/uri. In the URL, {clusterid} indicates the cluster ID, and uri indicates the resource path, that is, the path for API access.
    • The format of the URL called by the add-on management APIs is https://{clusterid}.Endpoint/uri. However, {clusterid} is used only for the domain name and is not verified or used by the APIs. Set {clusterid} in the query or body. For details about {clusterid}, see the add-on management sections.
    • {clusterid} is required for Kubernetes APIs and storage management, which indicates the cluster that needs to be accessed by calling the API.
Table 1 URL parameters

Parameter

Description

{clusterid}

Cluster ID. After a cluster is created, call the API for obtaining a cluster in a specified project to obtain the cluster ID.

Endpoint

Entry (URL) for a web service. Endpoints vary depending on services and regions.

uri

Access path of an API for performing an operation. Obtain the path from the URI of an API. For example, the resource-path of the API used to obtain a user token is v3/auth/tokens.

Notes and Constraints

  • CCE imposes a quota on the number and capacity of resources that a user can access. By default, you can create a maximum of five clusters in each region and a cluster can have a maximum of 50 nodes. To create more clusters or add more nodes, submit a service ticket to increase the quota. For more details about quotas, see Quotas.
  • For more constraints, see API description.

Concepts

  • Account

    An account is created upon successful registration. The account has full access permissions for all of its cloud services and resources. It can be used to reset user passwords and grant user permissions. The account is a payment entity, which should not be used directly to perform routine management. For security purposes, create Identity and Access Management (IAM) users and grant them permissions for routine management.

  • User

    An IAM user is created using an account to use cloud services. Each IAM user has their own identity credentials (password and access keys).

    The account name, username, and password will be required for API authentication.

  • Region

    Regions are divided based on geographical location and network latency. Public services, such as Elastic Cloud Server (ECS), Elastic Volume Service (EVS), Object Storage Service (OBS), Virtual Private Cloud (VPC), Elastic IP (EIP), and Image Management Service (IMS), are shared within the same region. Regions are classified into universal regions and dedicated regions. A universal region provides universal cloud services for common tenants. A dedicated region provides specific services for specific tenants.

    For details, see Region and AZ.

  • AZ

    An AZ comprises of one or more physical data centers equipped with independent ventilation, fire, water, and electricity facilities. Computing, network, storage, and other resources in an AZ are logically divided into multiple clusters. AZs within a region are interconnected using high-speed optical fibers to allow you to build cross-AZ high-availability systems.

  • Project

    A project corresponds to a region. Default projects are defined to group and physically isolate resources (including compute, storage, and network resources) across regions. Users can be granted permissions in a default project to access all resources under their accounts in the region associated with the project. If you need more refined access control, create subprojects under a default project and create resources in subprojects. Then you can assign users the permissions required to access only the resources in the specific subprojects.

    Figure 1 Project isolation model
  • Enterprise project

    Enterprise projects group and manage resources across regions. Resources in different enterprise projects are logically isolated. An enterprise project can contain resources of multiple regions, and resources can be added to or removed from enterprise projects.

    For details about enterprise projects and about how to obtain enterprise project IDs, see Enterprise Management User Guide.