Namespaces are used to logically divide your resources into different groups, especially in scenarios where a large number of users from multiple teams work on different projects.
+
CCI provides general computing resources and allows you to create pods with CPU resources for general computing.
+
- One account can create a maximum of five namespaces in a region.
- x86 images are supported.
+
+
Relationship Between Namespaces and Networks
Each namespace requires a separate subnet, as shown in Figure 1. When you create a namespace, you need to associate it with a VPC. A subnet will be created for the namespace in the VPC. Containers and other resources created in this namespace will run in the VPC and subnet you select.
+
If you want to run resources of multiple services in the same VPC, you need to consider network planning, including subnet CIDR block division and IP address planning.
+
Figure 1 Relationship between namespaces and VPC subnets
+
+
Application Scenarios
Namespaces can implement partial environment isolation. If you have a large number of projects and personnel, you can create different namespaces based on project attributes, such as production, test, and development.
+
+
Creating a Namespace
- Log in to the CCI console. In the navigation pane on the left, choose Namespaces.
- On the Namespaces page, click Create Namespace in the upper right corner.
- Enter a name for the namespace.
- The name of each namespace must be unique in CCI.
- Enter 1 to 63 characters. Start and end with a lowercase letter or digit. Use only lowercase letters, digits, and hyphens (-).
+
+ - Configure the network plane.
+
Table 1 Network plane settingsParameter
+ |
+Description
+ |
+
|---|
+
+IPv6
+ |
+If this option is enabled, IPv4/IPv6 dual stack is supported.
+ |
+
+VPC
+ |
+Select the VPC where the workloads are running. If no VPC is available, create one first. The VPC cannot be changed once selected.
+Recommended CIDR blocks: 10.0.0.0/8-22, 172.16.0.0/12-22, and 192.168.0.0/16-22
+ NOTICE: 10.247.0.0/16 is reserved for workloads. If you select this CIDR block, IP address conflicts may occur, which may result in workload creation failure or service unavailability. However, if you do not need to access pods through workloads, you can select this CIDR block.
+ After the namespace is created, you can view the VPC and subnet by choosing Namespaces > Subnet.
+
+ |
+
+Subnet
+ |
+Select the subnet where the workloads are running. If no subnet is available, create one first. The subnet cannot be changed once selected.
+- Some IP addresses (10 by default) in the subnet will be warmed up for the namespace.
- You can set the number of IP addresses to be warmed up in Advanced Settings.
- If warming up IP addresses for the namespace is enabled, the VPC and subnet can only be deleted after the namespace is deleted.
+ NOTE: Sufficient available IP addresses in the subnet are required for creating workloads.
+
+ |
+
+Security Group
+ |
+Select a security group. If no security group is available, create one first. The security group cannot be changed once selected.
+ |
+
+
+
+
- (Optional) Advanced Settings
Each namespace provides an IP pool. You can specify the pool size to reduce the duration for assigning IP addresses and speed up the workload creation.
+For example, 200 pods are running routinely, and 200 IP addresses are required in the IP pool. During peak hours, the IP pool instantly scales out to provide 500 IP addresses. After a specified interval (for example, 23 hours), the IP addresses that exceed the pool size (500 – 200 = 300) will be recycled.
+
+Table 2 Advanced namespace settingsParameter
+ |
+Description
+ |
+
|---|
+
+IP Pool Warm-up for Namespace
+ |
+An IP pool is provided for each namespace, with the number of IP addresses you specify here, and IP addresses will be assigned in advance to accelerate workload creation.
+An IP pool can contain a maximum of 500 IP addresses.
+ |
+
+IP Address Recycling Interval (h)
+ |
+Warmed-up IP addresses that become idle can be recycled within the duration you specify here.
+ |
+
+
+
+
- Click OK.
You can view the VPC and subnet on the namespace details page.
+
+
+
Deleting a Namespace
- Deleting a namespace will delete all resources (such as pods, ConfigMaps, and secrets) related to the namespace.
- Cascading deletion of workloads and services is not supported after a namespace is deleted.
- After a namespace is deleted, if a namespace with the same name is created immediately, 409 Conflict may be returned because it takes a while to delete a namespace. Create the namespace about 30 seconds later.
+
+
- Log in to the CCI console. In the navigation pane on the left, choose Namespaces.
- On the Namespaces page, locate the namespace you want to delete and click Delete in the Operation column. In the Delete Namespace dialog box, enter DELETE and click OK.
To delete a VPC or subnet, go to the VPC console.
+
+
+
+
Logging In to the CCI Console
Log in to the CCI console and grant CCI the permissions to access other cloud services.
+
+
- Switch to the CCI console.
- If this is the first time you are logging in to the CCI console, click Agree to grant CCI the permissions to access other cloud services.
After the permissions are granted, an agency named cci_admin_trust is created. You can view the agency on the IAM console.
+
+
(Optional) Uploading Images
The cloud platform provides the SoftWare Repository for Container (SWR) service for you to upload container images to the image repository. You can easily pull these images when creating workloads on CCI. For details about how to upload images, see Uploading an Image Through the Client.
+
Currently, CCI does not support third-party image repositories.
+
+
+
ConfigMaps are objects that you can use to store the configurations required by applications. After you create a ConfigMap, you can use it as a file in a containerized application.
+
Creating a ConfigMap
- Log in to the CCI console. In the navigation pane on the left, choose Configuration Center.
- Select a namespace and click the ConfigMaps tab.
- Click Create from YAML in the upper left corner and edit the YAML file. For details about the YAML file, see YAML format.
CCI supports both JSON and YAML, and the file size cannot exceed 1 MB.
+
+ - Click OK.
+
+
Using a ConfigMap
After a ConfigMap is created, you can mount it to a container as a storage volume during pod creation. For example, mount a ConfigMap named system-preset-aeskey to a container and set the storage volume name to volume1.
+
+
+
ConfigMap File Format
A ConfigMap resource file must be in either JSON or YAML format, and the file size cannot exceed 1 MB.
+
- JSON format
Example file: configmap.json
+{
+ "kind": "ConfigMap",
+ "apiVersion": "v1",
+ "metadata": {
+ "name": "nginxconf",
+ "namespace": "cci-namespace-demo"
+ },
+ "data": {
+ "nginx.conf": "server {\n listen 80;\n server_name localhost;\n\n location / {\n root html;\n index index.html index.htm;\n }\n}"
+ }
+}
+ - YAML format
Example file:
configmap.yamlkind: ConfigMap
+apiVersion: v1
+metadata:
+ name: nginxconf
+ namespace: cci-namespace-demo
+data:
+ nginx.conf: |-
+ server {
+ listen 80;
+ server_name localhost;
+
+ location / {
+ root html;
+ index index.html index.htm;
+ }
+ }
+
+
+
Secrets are objects that you can use to store sensitive data such as authentication information, certificates, and private keys. You can load a secret to a container as an environment variable when the container is started or mount a secret to a container as a file.
+
It is recommended that you encrypt the uploaded secrets.
+
+
Creating a Secret
- Log in to the CCI console. In the navigation pane on the left, choose Configuration Center.
- Select a namespace and click the Secrets tab.
- Click Create from YAML in the upper left corner and edit the YAML file. For details about the YAML file, see YAML format.
CCI supports both JSON and YAML, and the file size cannot exceed 2 MB.
+
+ - Click OK.
You can view the newly created secret in the secret list.
+
+
+
Using a Secret
After a secret is created, you can mount it to a container as a storage volume during pod creation. For example, mount a secret named aksk-secret to a container and set the storage volume name to volume2.
+
+
+
Secret File Format
- secret.yaml resource description file
For example, you can use a secret to obtain the following key-value pairs and encrypt them for an application:
+key1: value1
+key2: value2
+The secret.yaml file is defined as below. (Base64 encoding is required for the value of each key. For details about the Base64 encoding method, see Base64 Encoding.)
+apiVersion: v1
+kind: Secret
+metadata:
+ name: mysecret #Secret name
+ annotations:
+ description: "test"
+ labels:
+ label-01: value-01
+ label-02: value-02
+data:
+ key1: dmFsdWUx #Base64 encoding required
+ key2: dmFsdWUy #Base64 encoding required
+type: Opaque #The type must be Opaque.
+ - secret.json resource description file
The content is as follows:
{
+ "apiVersion": "v1",
+ "kind": "Secret",
+ "metadata": {
+ "annotations": {
+ "description": "test"
+ },
+ "labels": {
+ "label-01": "value-01",
+ "label-02": "value-02"
+ },
+ "name": "mysecret"
+ },
+ "data": {
+ "key1": "dmFsdWUx",
+ "key2": "dmFsdWUy"
+ },
+ "type": "Opaque"
+}
+
+
+
Base64 Encoding
To perform Base64 encoding on a character string, run the echo -n {Content to be encoded} | base64 command.
+
root@ubuntu:~# echo -n "3306" | base64
+MzMwNg==
+
+
Scenario
You can use CCI to quickly create pods for running workloads. On the CCI console, you can view details about all pods, such as basic information, container list, storage volumes, and events. In addition, you can use remote terminals to access pods. You can also delete pods.
+
+
+
+
+
Constraints
Custom domain name images of the SWR enterprise edition cannot be used to create workloads.
+
+
Creating a Pod
- Log in to the CCI console.
- In the navigation pane on the left, choose Container Groups. On the displayed page, click Create Container Group.
- On the Create Container Group page, specify the basic information.
+
+
Parameter
+ |
+Description
+ |
+
|---|
+
+Container Group Name
+ |
+- Enter a name for the container group. The name must be unique in the same account.
- Enter 1 to 253 characters. Start and end with a lowercase letter or digit. Use only lowercase letters, digits, hyphens (-), and periods (.).
+ |
+
+Namespace
+ |
+Namespace that the container group belongs to.
+ |
+
+(Optional) Description
+ |
+Enter a description, which cannot exceed 250 characters.
+ |
+
+CPU Architecture
+ |
+x86
+ |
+
+Pod Type
+ |
+General-computing
+ |
+
+vCPUs
+ |
+Select a value from 0.25 to 64.
+ |
+
+Memory
+ |
+Select the memory based on the selected vCPUs.
+ |
+
+(Optional) Data Storage
+ |
+Select a storage volume type and enter a storage volume name. - emptyDir volume: By default, CCI provides 20 GiB of free storage space, which is shared by emptyDir volumes and the system disk.
- ConfigMaps: Select a ConfigMap. If no ConfigMaps are available, create one first. For details, see Creating a ConfigMap.
- Secrets: Select a secret. If no secrets are available, create one first. For details, see Creating a Secret.
NOTE: Only emptyDir volumes, ConfigMaps, and secrets are supported. Add a volume to the container group and then mount the volume to the specified container.
+
+
+ |
+
+
+
+
+
- Configure container settings.
- Add basic container information. The total resources of a container cannot exceed the pod flavors.
+
+
Table 1 Basic container informationParameter
+ |
+Description
+ |
+
|---|
+
+Container Name
+ |
+- The container name must be globally unique.
- Enter 1 to 63 characters. Start and end with a lowercase letter or digit. Use only lowercase letters, digits, and hyphens (-).
+ |
+
+Image
+ |
+Select a container image.
+ CAUTION: Custom domain name images of the SWR enterprise edition cannot be used to create workloads.
+
+ |
+
+Image Version
+ |
+Select a container image version.
+ |
+
+vCPUs
+ |
+Specify the vCPUs. The value cannot exceed that in the pod flavors.
+ |
+
+Memory
+ |
+Specify the memory. The value cannot exceed that in the pod flavors.
+ |
+
+
+
+
+
- (Optional) Specify advanced container settings.
+
+
+Table 2 Advanced container settingsParameter
+ |
+Description
+ |
+
|---|
+
+Lifecycle
+ |
+Based on Kubernetes, CCI provides containers with lifecycle hooks, which enable containers to run code triggered by events during their management lifecycle. For example, if you want a container to perform a certain operation before it is stopped, you can register a hook. CCI provides the following lifecycle hooks:
+- Startup command: Docker ENTRYPOINT commands are used.
- postStart event: This hook is triggered after the application is started.
- preStop event: This hook is triggered before the application is stopped.
+ |
+
+Health Check
+ |
+Container health can be checked regularly when the container is running.
+CCI supports the following types of probes:
+- Liveness probe: checks whether a container responds normally and whether a restart is required.
- Ready probe: checks whether a container is ready to respond to requests.
- Startup probe: checks whether an application has already started.
+ |
+
+Environment Variables
+ |
+Environment variables affect the way a running container will behave. You can update them after deploying the workload.
+ |
+
+Data Storage
+ |
+Volumes can be mounted to containers to read data from files or store data files persistently. To mount a volume to a container, add the volume to the pod first.
+ |
+
+Security Settings
+ |
+Specify a user ID for all the containers to run with. For example, enter 0 to run as user root.
+ |
+
+
+
+
+ - (Optional) Select an image repository access credential.
+
+
+
+
What Is CCI
Cloud Container Instance (CCI) is a serverless container engine that allows you to run containers without creating or managing server clusters.
+
Traditionally, to run containerized workloads, you need to create a server cluster first. In the serverless model, a cloud provider runs servers and dynamically allocates resources so that you can build and run applications without having to worry about server statuses. This model helps you improve development efficiency and reduce IT costs.
+
CCI uses the serverless model that allows you to directly create and use containerized workloads on the console, using kubectl, or by calling APIs, and pay only for the resources consumed by these workloads.
+
CCI is in the beta phase. To use the service, contact customer service.
+
+
+
Functions
One-Stop Container Lifecycle Management
+
CCI allows you to run containers without creating or managing server clusters. In the serverless model, you can deploy and run workloads on the console, using kubectl, or by calling APIs, and pay only for the resources consumed by these workloads.
+
+
Architecture
CCI is a serverless container service. It allows you to create large-scale converged resource pools using the cell-based architecture. It also integrates network and storage services of the cloud platform to allow you to easily deploy and run containerized workloads through the console, kubectl, and APIs.
+
- CCI works with network and storage services of the cloud platform to provide robust network and storage performance.
- The QingTian architecture with hardware and software collaboration brings ultimate performance and user experience.
- Virtualization provides security isolation and works with in-house hardware virtualization acceleration technologies to allow you to create high-performance pods for running your workloads.
- With unified resource management and workload scheduling, you do not need to manage clusters.
- Capabilities, such as quick workload deployment, elastic load balancing, and fast auto scaling, can iterate services quickly.
+
+
Out of the Box
CCI provides an industry-leading serverless container architecture, so you do not need to create server clusters. Instead, you can create large-scale converged resource pools using the cell-based architecture. CCI also integrates network and storage services to allow you to easily deploy and run containerized workloads through the console, kubectl, and APIs.
+
+
Fast Auto Scaling
Resources are unlimited from a single user's perspective and can be scaled in seconds, helping you cope with service changes and ensure SLAs.
+
+
High Security
CCI provides VM-level isolation without compromising the startup speed, offering you better container experience. CCI has the following security features:
+
- Virtualization is supported.
- Kernel virtualization based on secure containers provides comprehensive security isolation.
- In-house virtualization acceleration technologies improve the virtualization performance.
+
+
Scientific Computing
Scientific R&D in fields such as genomics and drug development requires high-performance and high-density computing. In addition, scientific computing is generally task-based and requires quick resource allocation and release. Therefore, a low-cost computing platform with automated O&M is required.
+
The following CCI features make it suitable for computing in this scenario:
+
- High-performance computing and network, and high I/O storage
- Resource scaling in seconds minimizes resource consumption
- No O&M required for clusters and servers, greatly reducing O&M costs
+
+
DevOps/Continuous Delivery
Software development enterprises need complete DevOps processes from code submission to application deployment to improve the development efficiency. DevOps processes such as continuous integration/continuous delivery (CI/CD) are generally task-based computing and require quick resource allocation and release.
+
The following CCI features make it suitable for computing in this scenario:
+
- Automation for the entire CI/CD process, with no cluster creation and maintenance required
- Image-based delivery, allowing for consistency between the development and production environments
+
Figure 1 DevOps/Continuous delivery
+
+
Services with Fluctuating Traffic
Some types of applications, such as live video, media information, e-commerce, and online education, have obvious service peaks and troughs. For these applications, resources need to be expanded rapidly during peak hours without breaking the bank.
+
The following CCI features make it suitable for these applications:
+
- Fast scaling: CCI can quickly take over services from CCE to ensure uptime during peak hours.
+
Figure 2 Auto scaling
+
+
CCI provides enhanced features, such as security isolation, fast workload deployment, elastic load balancing, and auto scaling.
+
The graphical CCI console provides end-to-end user experience. In addition, CCI supports native APIs and kubectl. Before using CCI, you are advised to understand related basic concepts.
+
Image
A container image is a special file system that provides the programs, libraries, resources, and configuration files required for running a container. It also contains configuration parameters, for example, anonymous volumes, environment variables, and users. An image does not contain any dynamic data, and its content will not be changed after creation.
+
+
Container
The relationship between an image and a container is similar to that between a class and an instance in object-oriented programming. Images are static, and containers are entities of running images. A container can be created, started, stopped, deleted, and suspended.
+
+
Namespace
A namespace provides a method of allocating resources among multiple users. When you have a large number of projects and personnel, you can define namespaces by project attributes, such as production, test, and development.
+
+
Pod
A pod is the smallest deployable unit of computing that you can create and manage. A pod is a group of one or more containers, with shared storage resources, a unique IP address, and a specification for how to run the containers.
+
Figure 1 Pod
+
Pods can be used in either of the following ways:
+
- One pod that runs a single container: This is the most common use case. You can think of a pod as a wrapper around a single container, but pods can be managed directly rather than containers.
- Pods that run multiple containers that need to work together:
+
Pods are rarely created directly. Instead, controllers such as Deployments are used to create and manage pods. Controllers create and manage multiple pods, and provide replica management, rolling upgrade, and self-healing capabilities. A controller typically uses a pod template to create corresponding pods.
+
+
Label
A label is a key-value pair attached to an object and is used to transfer user-defined attributes.
+
Labels are often used to select objects that meet conditions from a group of objects. Labels are currently the most important node grouping method.
+
For example, you may create labels (tier=frontend, app=myapp) to mark frontend pods and labels (tier=backend, app=myapp) to mark backend pods. You can then use selectors to select pods with specific labels and apply services or Deployments to these pods.
+
Figure 2 Pods organized with labels
+
+
ConfigMap
A ConfigMap is used to store configuration data as key-value pairs or configuration files. ConfigMaps are similar to secrets, but provide a means of working with strings that do not contain sensitive information.
+
+
Secret
A secret is an object for storing sensitive data such as authentication information, certificates, and private keys. A secret can be loaded to a container as environment variables when the container is started.
+
+
CCI needs to be interconnected with the following cloud services. It requires permissions to access these cloud services.
+
- SWR
SoftWare Repository for Container (SWR) provides easy, secure, and reliable management of container images throughout their lifecycles, facilitating quick deployment of containerized services.
+You can create workloads using SWR images.
+ - VPC
Virtual Private Cloud (VPC) allows you to isolate online resources with virtual private networks. You can configure the CIDR block, subnets, and security groups, assign EIPs, and allocate bandwidth for a VPC.
+When creating a namespace, you must associate it with a VPC. All containers to be created in the namespace will run in the VPC.
+ - ELB
Elastic Load Balance (ELB) automatically distributes access traffic to multiple Elastic Cloud Servers (ECSs) to balance the loads. It enhances an application's fault tolerance level and capabilities of providing service externally.
+You can access a container workload from an external network through an elastic load balancer.
+ - AOM
Application Operations Management (AOM) is a one-stop platform for O&M personnel to monitor application and resource operating statuses in real time. By analyzing dozens of metrics, alarms, and logs, you can quickly locate root causes to ensure services run normally.
+AOM collects the .log files of containers from CCI to facilitate log query and viewing. In addition, AOM provides resource monitoring to enable CCI to automatically scale resources.
+ - ECS
Elastic Cloud Server (ECS) allows you to create cloud servers that provide scalable, on-demand computing resources for secure, flexible, and efficient applications.
+CCI imports data to SFS through ECS for container services to use.
+ - NAT Gateway
NAT Gateway provides source network address translation (SNAT), which translates private IP addresses to public IP addresses by binding an elastic IP address (EIP) to the gateway.
+You can use NAT Gateway to set SNAT rules to allow containers in a VPC to access the Internet.
+
+
This section describes the constraints on using CCI 2.0.
+
Constraints on CCI 2.0
The following table lists the constraints on CCI 2.0.
+
+
Item
+ |
+Constraint
+ |
+
|---|
+
+Account for creating CCI instances
+ |
+The account must have complete real-name authentication.
+ |
+
+Number of vCPUs per CCI instance
+ |
+0.25, 0.5, 1, 2, 4, 8, 16, 32, 48, and 64
+ |
+
+Supported OS
+ |
+Only Linux
+ |
+
+Network type
+ |
+Only VPC
+ |
+
+
+
+
+
+
Constraints on Pod Flavors
The following table lists the pod flavors.
+
Table 1 Requirements on pod flavorsItem
+ |
+Value Range
+ |
+
|---|
+
+Number of vCPUs
+ |
+0.25, 0.5, 1, 2, 4, 8, 16, 32, 48, and 64
+ |
+
+Memory
+ |
+- 1 GiB to 512 GiB
- The memory must be an integer multiple of 1 GiB.
+ |
+
+vCPU/memory ratio
+ |
+Between 1:1 and 1:8
+ |
+
+Containers in a pod
+ |
+A maximum of five containers
+A single container has as few as 0.25 vCPUs and 0.5 GiB of memory. The maximum resource flavor of a container is the same as that of a pod.
+ |
+
+
+
+
+
+
+
Constraints on Pod Storage Space
If no EVS disk is mounted, application data is stored in the rootfs of the container. The following table lists the storage space limit of each pod.
+
+
Table 2 Storage space limit of each type of podPod Type
+ |
+Storage Space
+ |
+
|---|
+
+General-computing pod
+ |
+30 GB
+ |
+
+
+
+
+
+
If you need to assign different permissions to employees in your enterprise to access your CCI resources, Identity and Access Management (IAM) is a good choice for fine-grained permissions management. IAM provides identity authentication, permissions management, and access control, enabling secure access to your cloud resources.
+
With IAM, you can use your account to create IAM users, and assign permissions to the users to control their access to specific resources. For example, some software developers in your enterprise need to use CCI resources but should not be allowed to delete the resources or perform any other high-risk operations. In this scenario, you can create IAM users for the software developers and grant them only the permissions required for using CCI resources.
+
If your account does not require individual IAM users for permissions management, skip this section.
+
IAM can be used free of charge. You only pay for the resources in your account.
+
CCI Permissions
By default, new IAM users do not have permissions assigned. You need to add a user to one or more groups, and attach permissions policies or roles to these groups. Users inherit permissions from the groups to which they are added and can perform specified operations on cloud services based on the permissions.
+
CCI is a project-level service deployed and accessed in specific regions. To assign CCI permissions to a user group, specify the scope as region-specific projects and select projects for the permissions to take effect. If All projects is selected, the permissions will take effect for the user group in all region-specific projects. When accessing CCI, the users need to switch to a region where they have been authorized to use this service.
+
You can grant users permissions by using roles and policies.
+
- Roles: A type of coarse-grained authorization mechanism that defines permissions related to user responsibilities. This mechanism provides only a limited number of service-level roles for authorization. When using roles to assign permissions, you need to also assign other roles on which the permissions depend to take effect. However, roles are not an ideal choice for fine-grained authorization and secure access control.
- Policies: A type of fine-grained authorization mechanism that defines permissions required to perform operations on specific cloud resources under certain conditions. This mechanism allows for more flexible policy-based authorization, meeting requirements for secure access control. For example, you can grant CCI users only the permissions for managing a certain type of CCI resources. Most policies define permissions based on APIs. For the API actions supported by CCI, see "Permissions Policies and Supported Actions" in the CCI API Reference.
+
+
Table 1 lists all the system-defined roles and policies supported by CCI.
+
+
Table 1 System-defined roles and policies supported by CCIRole/Policy Name
+ |
+Description
+ |
+Type
+ |
+
|---|
+
+CCI FullAccess
+ |
+Full permissions for CCI. Users granted these permissions can create, delete, query, and update all CCI resources.
+ |
+System-defined policy
+ |
+
+CCI ReadOnlyAccess
+ |
+Read-only permissions for CCI. Users granted these permissions can only view CCI resources.
+ |
+System-defined policy
+ |
+
+CCI CommonOperations
+ |
+Common user permissions for CCI. Users granted these permissions can perform all operations except creating, deleting, and modifying role-based access control (RBAC) policies, networks, and namespaced resources.
+ |
+System-defined policy
+ |
+
+CCI Administrator
+ |
+Administrator permissions for CCI. Users granted these permissions can create, delete, query, and update all CCI resources.
+ |
+System-defined role
+ |
+
+
+
+
+
Table 2 lists the permissions granted by a CCI FullAccess policy.
+
+
Table 2 Permissions granted by a CCI FullAccess policyAction
+ |
+Description
+ |
+
|---|
+
+cci:*:*
+ |
+Perform all operations on Cloud Container Instance (CCI).
+ |
+
+vpc:*:*
+ |
+Perform all operations on Virtual Private Cloud (VPC).
+ |
+
+elb:*:*
+ |
+Perform all operations on Elastic Load Balance (ELB).
+ |
+
+sfs:*:*
+ |
+Perform all operations on Scalable File Service (SFS).
+ |
+
+evs:*:*
+ |
+Perform all operations on Elastic Volume Service (EVS).
+ |
+
+aom:*:*
+ |
+Perform all operations on Application Operations Management (AOM).
+ |
+
+apm:*:*
+ |
+Perform all operations on Application Performance Management (APM).
+ |
+
+swr:*:*
+ |
+Perform all operations on Software Repository for Container (SWR).
+ |
+
+nat:*:*
+ |
+Perform all operations on NAT Gateway.
+ |
+
+kms:cmk:*
+ |
+Perform all operations on Key Management Service (KMS).
+ |
+
+
+
+
+
Table 3 lists the permissions granted by a CCI ReadOnlyAccess policy.
+
+
Table 3 Permissions granted by a CCI ReadOnlyAccess policyAction
+ |
+Description
+ |
+
|---|
+
+cci:*:get
+ |
+View details about all CCI resources.
+ |
+
+cci:*:list
+ |
+List all CCI resources.
+ |
+
+vpc:*:get
+ |
+View details about all VPC resources.
+ |
+
+vpc:*:list
+ |
+List all VPC resources.
+ |
+
+ecs:*:get
+ |
+View details about all ECS resources.
+ |
+
+ecs:*:list
+ |
+List all ECS resources.
+ |
+
+elb:*:get
+ |
+View details about all ELB resources.
+ |
+
+elb:*:list
+ |
+List all ELB resources.
+ |
+
+sfs:*:get*
+ |
+View details about all SFS resources.
+ |
+
+sfs:*:list
+ |
+List all SFS resources.
+ |
+
+evs:*:get*
+ |
+View details about all EVS resources.
+ |
+
+evs:*:list
+ |
+List all EVS resources.
+ |
+
+aom:*:get
+ |
+View details about all AOM resources.
+ |
+
+aom:*:list
+ |
+List all AOM resources.
+ |
+
+amp:*:get
+ |
+View details about all APM resources.
+ |
+
+apm:*:list
+ |
+List all APM resources.
+ |
+
+swr:*:get
+ |
+View details about all SWR resources.
+ |
+
+swr:*:list
+ |
+List all SWR resources.
+ |
+
+nat:*:get
+ |
+View details about all NAT Gateway resources.
+ |
+
+nat:*:list
+ |
+List all NAT Gateway resources.
+ |
+
+kms:cmk:get
+ |
+Query key information.
+ |
+
+kms:cmk:list
+ |
+List all keys.
+ |
+
+
+
+
+
Table 4 lists the permissions granted by a CCI CommonOperations policy.
+
+
Table 4 Permissions granted by a CCI CommonOperations policyAction
+ |
+Description
+ |
+
|---|
+
+cci:rbac:get
+ |
+Query RBAC policy details.
+ |
+
+cci:rbac:list
+ |
+List all RBAC policies.
+ |
+
+cci:namespace:get
+ |
+Query namespace details.
+ |
+
+cci:namespace:list
+ |
+List all namespaces.
+ |
+
+cci:network:get
+ |
+Query network details.
+ |
+
+cci:network:list
+ |
+List all networks.
+ |
+
+cci:namespaceSubResource:*
+ |
+Perform all operations on namespaced resources.
+ |
+
+cci:addonTemplate:*
+ |
+Perform all operations on add-on templates.
+ |
+
+cci:addonInstance:*
+ |
+Perform all operations on add-on pods.
+ |
+
+vpc:*:*
+ |
+Perform all operations on VPC.
+ |
+
+elb:*:*
+ |
+Perform all operations on ELB.
+ |
+
+aom:*:*
+ |
+Perform all operations on AOM.
+ |
+
+apm:*:*
+ |
+Perform all operations on APM.
+ |
+
+swr:*:*
+ |
+Perform all operations on SWR.
+ |
+
+nat:*:*
+ |
+Perform all operations on NAT Gateway.
+ |
+
+kms:cmk:*
+ |
+Perform all operations on KMS.
+ |
+
+
+
+
+
Table 5 lists the actions associated with CCI fine-grained policies.
+
+
Table 5 Actions associated with CCI fine-grained policiesAction
+ |
+Description
+ |
+
|---|
+
+CCI:rbac:get
+ |
+Query RBAC details.
+ |
+
+CCI:rbac:list
+ |
+List all RBAC policies.
+ |
+
+CCI:rbac:update
+ |
+Update RBAC policies.
+ |
+
+CCI:rbac:delete
+ |
+Delete RBAC policies.
+ |
+
+CCI:rbac:create
+ |
+Create RBAC policies.
+ |
+
+CCI:namespaceSubResource:Create
+ |
+Create resources in namespaces.
+ |
+
+CCI:namespaceSubResource:List
+ |
+List all resources.
+ |
+
+CCI:namespaceSubResource:Get
+ |
+Query resources.
+ |
+
+CCI:namespaceSubResource:Delete
+ |
+Delete resources.
+ |
+
+CCI:namespaceSubResource:Update
+ |
+Update resources.
+ |
+
+CCI:network:update
+ |
+Update networks.
+ |
+
+CCI:network:create
+ |
+Create networks.
+ |
+
+CCI:network:delete
+ |
+Delete networks.
+ |
+
+CCI:network:list
+ |
+List all networks.
+ |
+
+CCI:network:get
+ |
+Query network details.
+ |
+
+CCI:addonInstance:create
+ |
+Create add-on instances.
+ |
+
+CCI:addonInstance:update
+ |
+Update add-on instances.
+ |
+
+CCI:addonInstance:delete
+ |
+Delete add-on instances.
+ |
+
+CCI:addonInstance:get
+ |
+Query add-on instance details.
+ |
+
+CCI:addonInstance:list
+ |
+List all add-on instances.
+ |
+
+CCI:addonTemplate:list
+ |
+List all add-on templates.
+ |
+
+CCI:addonTemplate:get
+ |
+Query add-on template details.
+ |
+
+CCI:namespace:get
+ |
+Query details about a specified namespace.
+ |
+
+CCI:namespace:update
+ |
+Update namespaces.
+ |
+
+CCI:namespace:create
+ |
+Create namespaces.
+ |
+
+CCI:namespace:list
+ |
+List all namespaces.
+ |
+
+CCI:namespace:delete
+ |
+Delete namespaces.
+ |
+
+
+
+
+
Table 6 lists the common operations supported by each system-defined policy or role of CCI. Select the policies or roles as required.
+
+
Table 6 Common operations supported by each system-defined policy or role of CCIOperation
+ |
+CCI FullAccess
+ |
+CCI ReadOnlyAccess
+ |
+CCI CommonOperations
+ |
+
|---|
+
+Creating Deployments
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Deleting Deployments
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Viewing Deployments
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Upgrading workloads
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Scaling workloads
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Deleting pods
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Viewing pods
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Creating jobs
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Deleting jobs
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Viewing jobs
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Creating cron jobs
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Deleting cron jobs
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Viewing cron jobs
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Viewing the resource usage
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Adding EVS volumes
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Deleting EVS volumes
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Viewing EVS volumes
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Creating ConfigMaps
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Deleting ConfigMaps
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Viewing ConfigMaps
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Creating secrets
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Deleting secrets
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Viewing secrets
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Adding SSL certificates
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Deleting SSL certificates
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Viewing SSL certificates
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Adding log storage
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Viewing logs
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Installing add-ons
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Deleting add-ons
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Viewing add-ons
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Viewing permissions
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Granting permissions
+ |
+√
+ |
+x
+ |
+x
+ |
+
+Deleting permissions
+ |
+√
+ |
+x
+ |
+x
+ |
+
+Querying details about a specified namespace
+ |
+√
+ |
+x
+ |
+√
+ |
+
+Creating namespaces
+ |
+√
+ |
+x
+ |
+x
+ |
+
+Deleting namespaces
+ |
+√
+ |
+x
+ |
+x
+ |
+
+Creating networks
+ |
+√
+ |
+x
+ |
+x
+ |
+
+Deleting networks
+ |
+√
+ |
+x
+ |
+x
+ |
+
+Listing all networks
+ |
+√
+ |
+√
+ |
+√
+ |
+
+Querying network details
+ |
+√
+ |
+√
+ |
+√
+ |
+
+
+
+
+
Concept
A region and availability zone (AZ) identify the location of a data center. You can create resources in a specific region and AZ.
+
- A region is a physical data center, which is completely isolated to improve fault tolerance and stability. The region that is selected during resource creation cannot be changed after the resource is created.
- An AZ is a physical location where resources use independent power supplies and networks. A region contains one or more AZs that are physically isolated but interconnected through internal networks. Because AZs are isolated from each other, any fault that occurs in one AZ will not affect others.
+
Figure 1 shows the relationship between regions and AZs.
+
Figure 1 Regions and AZs
+
+
Selecting a Region
Select a region closest to your target users for lower network latency and quick access.
+
+
Selecting an AZ
When deploying resources, consider your applications' requirements on disaster recovery (DR) and network latency.
+
- For high DR capability, deploy resources in different AZs within the same region.
- For lower network latency, deploy resources in the same AZ.
+
+
Regions and Endpoints
Before you use an API to call resources, specify its region and endpoint. For more details, see Regions and Endpoints.
+
+
What Is a Pod or Container Group?
Pods (or container groups) are the smallest deployable units of computing that you can create and manage. A pod or a container group is a group of one or more containers, with shared storage, a unique IP address, and a specification for how to run the containers.
+
Pods can be used in either of the following ways:
+
- A pod runs a single container. This is the most common use case. You can consider a pod as a wrapper around a single container. Pods can be managed directly rather than containers.
- A pod runs multiple containers that need to work together. In this scenario, a pod can encapsulate an application that is running in a main container and several sidecar containers. As shown in Figure 1, the main container serves as a web server that provides file services from a fixed directory, and the sidecar container periodically downloads files to the directory.
Figure 1 Pod
+
+
+