Help Center/ Cloud Container Engine/ API Reference (Ankara Region)/ Before You Start
Updated on 2024-12-04 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.

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

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

Endpoints

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

  • 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.
  • For more constraints, see API description.

Concepts

  • Domain

    A domain 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 domain should not be used directly to perform routine management. For security purposes, create 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

    A region is a geographic area in which cloud resources are deployed. Availability zones (AZs) in the same region can communicate with each other over an intranet, while AZs in different regions are isolated from each other. Deploying cloud resources in different regions can better suit certain user requirements or comply with local laws or regulations.

  • 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