Before You Start

Overview

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.

If you plan to access CCE resources through APIs, 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 APIs: These APIs that can be accessed through the API gateway allow you to manage cloud service infrastructures (for example, creating a cluster). 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 cluster) are not supported.

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

  NOTE:

  • 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 depending on Kubernetes-native APIs. Therefore, you are advised to use this type of APIs in unimportant scenarios, for example, short-term test clusters.

API Calling

CCE supports Representational State Transfer (REST) APIs, allowing you to call APIs using HTTPS. For details about API calling, see Calling APIs.

Endpoints

An endpoint is the request address for calling an API. Endpoints vary depending on services and regions. For the endpoints of all services, see Regions and Endpoints.

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

• The URL format for cluster and quota management is https://Endpoint/uri. In the URL, uri indicates the resource path, which is the path for API access.
• 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, which is the path for API access.
  NOTE:

  • 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.

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 grant 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.