Developer Guide - HUAWEI CLOUDThe kubectl config init command completes the operations performed by running the four commands: kubectl config set-cluster, kubectl config set-credentials,

Cloud Container Instance

Developer Guide

Issue 01

Date 2020-03-24

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2020. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without priorwritten consent of Huawei Technologies Co., Ltd. Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.All other trademarks and trade names mentioned in this document are the property of their respectiveholders. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei andthe customer. All or part of the products, services and features described in this document may not bewithin the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,information, and recommendations in this document are provided "AS IS" without warranties, guaranteesor representations of any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute a warranty of any kind, express or implied.

Issue 01 (2020-03-24) Copyright © Huawei Technologies Co., Ltd. i

Contents

1 Overview....................................................................................................................................1

2 kubectl....................................................................................................................................... 3

3 Namespace and Network...................................................................................................... 8

4 Pod............................................................................................................................................ 144.1 Pod............................................................................................................................................................................................. 144.2 Environment Variables........................................................................................................................................................ 194.3 Startup Command................................................................................................................................................................ 204.4 Lifecycle Management........................................................................................................................................................ 204.5 Liveness Probe........................................................................................................................................................................ 21

5 Label......................................................................................................................................... 25

6 Deployment............................................................................................................................ 28

7 Managing Network Access Through Service and Ingress............................................327.1 Service....................................................................................................................................................................................... 327.2 Ingress....................................................................................................................................................................................... 387.3 Network Access Scenarios................................................................................................................................................. 417.4 Readiness Probe.................................................................................................................................................................... 42

8 Using PersistentVolumeClaim to Apply for Persistent Storage..................................47

9 ConfigMap and Secret..........................................................................................................519.1 configMap............................................................................................................................................................................... 519.2 Secret.........................................................................................................................................................................................52

10 Creating a Workload Using Job and Cron Job..............................................................55

A YAML Syntax.......................................................................................................................... 58

Cloud Container InstanceDeveloper Guide Contents

Issue 01 (2020-03-24) Copyright © Huawei Technologies Co., Ltd. ii

1 Overview

Cloud Container Instance (CCI) is a serverless container engine that allows you torun containers without creating and managing server clusters. Under theserverless model, CCI allows you to directly create and use containerizedworkloads on the console or by using kubectl or Kubernetes APIs, and pay only forthe resources consumed by these workloads.

This document describes how to use kubectl or call CCI APIs to implementfunctions.

Document Organization

This document includes:

1. Using kubectlThis section describes how to configure kubectl on CCI.

2. Namespace and NetworkThis section describes the concepts of the namespace and network.

3. PodThis section describes the concept of the pod and how to use pods.

4. LabelThis section describes the functions of labels and how to use labels.

5. DeploymentThis section describes the application scenarios of Deployments, and how todeploy Docker images to CCI using a Deployment.

6. Service and IngressThis section describes how to use services and ingresses to manage workloadaccess.– Service: an abstraction which defines a logical set of pods and a policy by

which to access them.– Ingress: an API object that manages external access.

7. Persistent StorageThis section describes how to use storage in workloads. That is, how to usestorage volumes in containers. Storage types that can be used include Elastic

Cloud Container InstanceDeveloper Guide 1 Overview

Issue 01 (2020-03-24) Copyright © Huawei Technologies Co., Ltd. 1

https://support.huaweicloud.com/en-us/api-cci/cci_02_2001.html

Volume Service (EVS), Scalable File Service (SFS), and Object Storage Service(OBS).

8. ConfigMap and SecretThis section describes how to use ConfigMaps and secrets.ConfigMaps and secrets are used to store configuration and sensitiveinformation to enable easier and flexible workload configuration.

9. Job and Cron JobThis section describes how to use jobs. A job is applicable to one-off tasks.

Cloud Container InstanceDeveloper Guide 1 Overview


2 kubectl

CCI provides a customized kubectl that allows you to create resources such asworkloads by using kubectl commands.

Supported kubectl Commandskubectl provided by CCI is adapted from kubectl of the Kubernetes community. Forkubectl commands supported by CCI, see CCI kubectl Commands. kubectl callsAPIs to perform operations on CCI resources such as pods, Deployments, and jobs.The operable resources and operations that kubectl can perform are the same asthose of CCI APIs.

Downloading kubectlThe latest version of the customized kubectl is v2.10.11.

On Linux, download the latest kubectl version from https://cci-kubectl.obs.cn-north-1.myhuaweicloud.com/kubectl-linux.zip.

On macOS, download the latest kubectl version from https://cci-kubectl-for-mac.obs.cn-north-1.myhuaweicloud.com/kubectl-darwin.zip.

Only the URL of the latest kubectl version is provided.

Table 2-1 kubectl versions

Version Change History

2.10.11(Latest)

This issue is the fifth official release, which incorporates thefollowing changes:● Fixed the error in the kubectl rollout command output.● Added the kubectl config init command to support one-

click kubectl configuration.

2.4.20 This is the fourth official release.Fixed an issue where a non-root user occasionally fails to usekubectl.

Cloud Container InstanceDeveloper Guide 2 kubectl


https://kubectl-doc.obs-website.cn-north-1.myhuaweicloud.com/


https://cci-kubectl.obs.cn-north-1.myhuaweicloud.com/kubectl-linux.zip

https://cci-kubectl.obs.cn-north-1.myhuaweicloud.com/kubectl-linux.zip

https://cci-kubectl-for-mac.obs.cn-north-1.myhuaweicloud.com/kubectl-darwin.zip

https://cci-kubectl-for-mac.obs.cn-north-1.myhuaweicloud.com/kubectl-darwin.zip

Version Change History

v2.4.2 This is the third official release.Disabled the kubectl cp command to prevent Kubernetessecurity vulnerabilities.

v2.2.23 This is the second official release.Issues fixed:● Fixed an issue where the kubectl exec command cannot be

executed in AK/SK-based authentication.● Fixed an issue where AK/SK-based authentication

occasionally fails when AK/SK content is read from a file.

v1.1.13 This is the first official release.

Configuring kubectlDownload and decompress the package to any directory without installation. Thedirectory structure after the decompression is as follows:

kubectlREADME.md

Run the following commands to add the kubectl directory to environmentvariables and grant the execute permission to kubectl: In thecommands, /DIR/TO/KUBECTL indicates the directory where the kubectl file islocated. Replace it with the actual directory.

export PATH=/DIR/TO/KUBECTL:$PATH

chmod +x /DIR/TO/KUBECTL/kubectl

Run the kubectl --help command to check supported commands and the resourcescope. If the following information is displayed, kubectl can be used properly:

# kubectl --helpkubectl controls the Kubernetes cluster manager.

Find more information at: https://kubernetes.io/docs/reference/kubectl/overview/

Basic Commands (Beginner): create Create a resource from a file or from stdin. expose Take a replication controller, service, deployment or pod and expose it as a new Kubernetes Service run Run a particular image on the cluster set Set specific features on objects

......

You can also run the kubectl version command to view the kubectl version.

# kubectl versionClient Version: v2.2.23, Build Date: 2019-02-23T10:28:53Z

Obtaining CCI EndpointsEndpoints are displayed on the Regions and Endpoints page.



https://developer.huaweicloud.com/en-us/endpoint

Using kubectl

Step 1 Configure the kubeconfig file.

By default, the kubeconfig file is the config file in the ${HOME}/.kube directory.This file is used to store cluster access information, including the endpoint addressand identity authentication information.

Each time a kubectl command is executed, authentication is required. Currently,token-based and AK/SK-based authentication modes are supported. You can selectone mode.

● Token-based authentication: The validity period of a token is 24 hours. Fordetails about how to obtain a token, see Obtaining a Token.kubectl config init --server=https://CCI_ENDPOINT --token=$tokenIn the preceding command, CCI_ENDPOINT is an endpoint of CCI and $tokenis the obtained token.

For details about IAM endpoints, see Regions and Endpoints. Note that the endpointsmust be in the same region as CCI.

For example, if the endpoint is https://cci.cn-north-1.myhuaweicloud.comand the token is MIIEYwYJKoZIhvcNAQc..., run the following command:kubectl config init --server=https://cci.cn-north-1.myhuaweicloud.com --token=MIIEYwYJKoZIhvcNAQc...

● AK/SK-based authentication: AK/SK is valid for a long period. For detailsabout how to obtain AK/SK, see Obtaining an AK/SK.AK/SK-based authentication can be implemented by using either of thefollowing methods:– Run the following command with the access key and secret key specified:

kubectl config init --server=https://CCI_ENDPOINT --auth-provider=hws --auth-provider-arg=ak=$ak --auth-provider-arg=sk=$skIn the preceding command, CCI_ENDPOINT is an endpoint of CCI, $ak isthe access key, and $sk is the secret key.For example, if the endpoint is https://cci.cn-north-1.myhuaweicloud.com, the AK is ABCDEFAK.., and SK isABCDEFSK.., run the following command:kubectl config init --server=https://cci.cn-north-1.myhuaweicloud.com --auth-provider=hws --auth-provider-arg=ak=ABCDEFAK.. --auth-provider-arg=sk=ABCDEFAK..

– Run the following command with the AK and SK file directory specified:kubectl config init --server=https://CCI_ENDPOINT --auth-provider=hws --auth-provider-arg=akskDir=$akskDirIn the preceding command, CCI_ENDPOINT is an endpoint of CCI and$akskDir is the directory where the AK and SK files are stored. If this




method is used, you need to save the AK and SK to the ak and sk files,respectively and save the two files in the directory specified by $akskDirin advance.For example, if the ak and sk files are stored in the /home/akskdirectory, run the following command:kubectl config init --server=https://cci.cn-north-1.myhuaweicloud.com --auth-provider=hws --auth-provider-arg=akskDir=/home/aksk

The kubectl config init command completes the operations performed byrunning the four commands: kubectl config set-cluster, kubectl config set-credentials, kubectl config set-context, and kubectl config set current-context. If custom configuration is required, see kubectl config CommandReference.

Step 2 After the kubeconfig file is configured, you can run kubectl commands to performoperations on CCI resources.

If a message indicating a certificate authentication failure is displayed when you run akubectl command, add --insecure-skip-tls-verify=true to the command. However, thissetting enables CCI not to check the validity of the server certificate, making your HTTPSconnection insecure.

For example, run the kubectl get namespace command to view resources.

# kubectl get namespaceNo resources found.

You can see that there is no namespace. Before creating resources in CCI, you needto create a namespace first. For details, see 3 Namespace and Network.

----End

Obtaining a TokenSend POST https://IAM endpoint/v3/auth/tokens. For details, see IAM APIReference.

For details about IAM endpoints, see Regions and Endpoints. Note that theendpoints must be in the same region as CCI.

An example request is as follows:{ "auth": { "identity": { "methods": [ "password" ], "password": { "user": { "name": "username", "password": "******", "domain": { "name": "domainname" } } } }, "scope": { "project": {



https://kubectl-doc.obs-website.cn-north-1.myhuaweicloud.com/#config

https://kubectl-doc.obs-website.cn-north-1.myhuaweicloud.com/#config

https://support.huaweicloud.com/en-us/api-iam/iam_30_0001.html

https://support.huaweicloud.com/en-us/api-iam/iam_30_0001.html


"name": "cn-north-1" } } }}

After a response is returned, the value of X-Subject-Token in the response headeris the token value.

Obtaining an AK/SKAK: Access key ID. It is a unique ID associated with the SK. AK is used togetherwith SK to sign requests.

SK: Secret access key. It is used together with the AK to sign requests. They canidentify request senders and prevent requests from being modified.

1. Log in to the management console.2. Click the username and choose My Credentials from the drop-down list.

3. Choose the Access Keys tab.4. Click Add Access Key.5. Enter the password for login.6. Enter the verification code sent to your mailbox or mobile phone.

For users created on IAM, if no email address or mobile number is specified duringuser creation, only the login password needs to be authenticated.

7. Click OK to download the access key.

Keep the AK/SK file confidential to prevent information leakage.



3 Namespace and Network

A namespace provides a method of allocating resources among multiple users. Itapplies to scenarios where multiple teams or projects exist. Currently, CCI providestwo types of resources: general-computing and GPU-accelerated resources. Whencreating a namespace, you need to select a resource type. Subsequently, newworkloads will run on this type of cluster.

● General-computing: Supports creation of container instances and workloadswith CPU resources. This namespace type is suitable for general computingscenarios.

● GPU-accelerated: Supports creation of container instances and workloadswith GPU resources. This namespace type is suitable for scenarios such asdeep learning, scientific computing, and video processing.

A network is a Kubernetes resource object extended for CCI. You can associate anetwork with a Virtual Private Cloud (VPC) and subnet so that CCI can usenetwork resources of the public cloud.

Relationship Between a Namespace and NetworkA namespace corresponds to a subnet in a VPC, as shown in Figure 3-1. When anamespace is created, it will be associated with an existing VPC or a newly createdVPC, and a subnet will be created under the VPC. In this namespace, resourcessuch as pods and Services are created in the corresponding VPC and subnet, andthe IP addresses in the subnet are used.

If you want to run resources of multiple services in the same VPC, you need toplan subnet CIDR blocks and IP addresses.

Cloud Container InstanceDeveloper Guide 3 Namespace and Network


Figure 3-1 Relationship between namespaces and VPC subnets

Scenarios Where Multiple Namespaces Are UsedBecause namespaces enable partial environment isolation, you can create differentnamespaces, such as production, test, and development namespaces based onproject attributes when there are a large number of projects and persons.

Creating a NamespaceUnder a namespace, a network is required to associate with a VPC and subnet.After a namespace is created, a network needs to be created.

In most cases, namespaces do not need to be frequently created. You are advised to log into the CCI console to create a namespace. For details, see Namespace.

In the following example, create a namespace named namespace-test, andspecify the CCI resource type to general-computing.

apiVersion: v1kind: Namespacemetadata: name: namespace-test labels: sys_enterprise_project_id: 0 #Enterprise project ID. This filed is optional. If this field is not set, the default value 0 is used, indicating the default enterprise project. annotations: namespace.kubernetes.io/flavor: general-computing #Namespace typespec: finalizers: - kubernetes

The definition file is in the YAML or JSON format. For more details about theYAML format, see YAML Syntax.

The sys_enterprise_project_id field indicates the enterprise project ID, which canbe obtained from the enterprise project details page on the EnterpriseManagement console. This field does not need to be set for users who have notenabled the Enterprise Management service.

There are two namespace types:

● General-computing: Supports creation of container instances and workloadswith CPU resources. This namespace type is suitable for general computingscenarios.



https://support.huaweicloud.com/en-us/usermanual-cci/cci_01_0001.html

https://console.huaweicloud.com/eps/?&locale=en-us#/projects

https://console.huaweicloud.com/eps/?&locale=en-us#/projects

● GPU-accelerated: Supports creation of container instances and workloadswith GPU resources. This namespace type is suitable for scenarios such asdeep learning, scientific computing, and video processing.

If the file name of the namespace definition is ns.yaml, run kubectl create -fns.yaml to create a namespace. -f indicates that the namespace is created from afile.

# kubectl create -f ns.yaml namespace/namespace-test created

Run kubectl get ns to check whether the namespace is successfully created. Inthis command, ns indicates the namespace.

# kubectl get nsNAME STATUS AGEnamespace-test Active 23s

The preceding information indicates that the namespace namespace-test iscreated successfully and the duration is 23 seconds.

Log in to the CCI console. In the navigation pane, choose Namespaces. You cansee that the namespace is created successfully but the status is Abnormal. This isbecause in CCI, you need to define a network policy for the namespace. Fordetails, see Creating a Network.

Figure 3-2 Namespace - abnormal

Creating a Network

After creating a namespace, you need to create a network policy for thenamespace and associate the namespace with the VPC and subnet.

The following example shows how to create a network named test-network.apiVersion: networking.cci.io/v1beta1 #The API version is networking.cci.io/v1beta1.kind: Networkmetadata: annotations: network.alpha.kubernetes.io/default-security-group: security-group-id #Security group ID, which needs to be replaced with the actual value. network.alpha.kubernetes.io/domain-id: domain-id #Account ID, which needs to be replaced with the actual value. network.alpha.kubernetes.io/project-id: project-id #Project ID, which needs to be replaced with the actual value. name: test-networkspec: availableZone: cnnorth1a #AZ name. Currently, only cnnorth1a, cn-north-4a, and cn-east-3a are supported. cidr: 192.168.0.0/24 #Subnet CIDR block attachedVPC: vpc-id #VPC ID, which needs to be replaced with the actual value. networkID: network-id #Network ID of the subnet, which needs to be replaced with the actual value. networkType: underlay_neutron #Network type. Currently, only underlay_neutron is supported. subnetID: subnet-id #Subnet ID, which needs to be replaced with the actual value.



The CIDR blocks of the VPC and subnet cannot be 10.247.0.0/16, which is the CIDR blockreserved by CCI for Services. If you use this CIDR block, IP address conflicts may occur,which may result in workload creation failures or service unavailability. If you do not needto access pods through Services, you can allocate this CIDR block to a VPC.

You can obtain the preceding parameters as follows:

● The account ID and project ID can be obtained from My Credentials.

● The security group ID can be obtained from the Security Group Console, asshown in the following figure.

Figure 3-3 Obtaining the security group ID

● The VPC ID, subnet ID, and network ID can be obtained from the VPC console.

Figure 3-4 Obtaining the VPC ID



https://console.huaweicloud.com/vpc/?&locale=en-us#/secGroups

Figure 3-5 Obtaining the subnet ID and network ID

If the file name of the network definition is network.yaml, run kubectl create -fnetwork.yaml to create a namespace. -f indicates that the namespace is createdfrom a file. namespace namespace-test indicates that it is created in thenamespace namespace-test.

# kubectl create -f network.yaml --namespace namespace-testnetwork.networking.cci.io/test-network created

Log in to the CCI console. In the navigation pane, choose Namespaces. You cansee that the namespace is created successfully and the status is Normal.

Figure 3-6 Namespace - normal

Specifying a Namespace for the kubectl Context

The network above is created in a specified namespace. The subsequent resourcesare created in a namespace. It is time-consuming to specify the namespace eachtime. You can specify the namespace for a kubectl context. In this way, theresources created in the context are all under this namespace, which facilitatesoperations.

To specify the namespace, you only need to add the --namespace option to thecontext setting command, as shown in the following command:

kubectl config set-context $context --user=$credential_name --cluster=$cluster_name --namespace=$ns

The only difference with that in Using kubectl is that the namespace is specifiedhere. In the preceding command, $context indicates the context name, which canbe customized. $credential_name indicates the credential name, $cluster_nameindicates the endpoint information, and $ns indicates the namespace name.

For example, if you specify the namespace namespe-test created above, thecommand is as follows:

# kubectl config set-context cci-context --user=credential-aksk --cluster=cci-cluster --namespace=namespace-test



After a namespace is specified, you can run kubectl commands to directly operateCCI resources. For example, run kubectl get pod to check pod resources. Theresult shows that all resources are normal.

# kubectl get podNo resources found.



4 Pod

4.1 Pod

What Is Pod?A pod is the smallest and simplest unit in the Kubernetes object model that youcreate or deploy. A pod encapsulates one or more containers, storage resources, aunique network IP address, and options that govern how the container(s) shouldrun.

Pods can be used in either of the following ways:

● One container runs in one pod. This is the most common usage of pods inKubernetes. You can view the pod as a single encapsulated container, butKubernetes directly manages pods instead of containers.

● Multiple containers that need to be coupled and share resources run in a pod.In this scenario, an application contains a main container and several sidecarcontainers, as shown in Figure 4-1. For example, the main container is a webserver that provides file services from a fixed directory, and the sidecarcontainer periodically downloads files to the directory.

Cloud Container InstanceDeveloper Guide 4 Pod


Figure 4-1 Pod

In Kubernetes, pods are rarely created directly. Instead, controllers such asDeployments and jobs, are used to manage pods. Controllers can create andmanage multiple pods, and provide replica management, rolling upgrade, andself-healing capabilities. A controller generally uses a pod template to createcorresponding pods.

Container SpecificationsYou can use GPUs in CCI only if the namespace is of the GPU-accelerated type.

Currently, three types of pods are provided, including general-computing (used ingeneral-computing namespaces), RDMA-accelerated, and GPU-accelerated (usedin GPU-accelerated namespaces).

GPU-accelerated pods support the following GPUs: NVIDIA Tesla V100 32GB,NVIDIA Tesla V100 16GB, and NVIDIA Tesla P4 8GB.● Specifications of NVIDIA Tesla V100 32GB are as follows:

– NVIDIA Tesla V100 32GB x 1, 4 CPU cores, 32 GB memory– NVIDIA Tesla V100 32GB x 2, 8 CPU cores, 64 GB memory– NVIDIA Tesla V100 32GB x 4, 16 CPU cores, 128 GB memory– NVIDIA Tesla V100 32GB x 8, 32 CPU cores, 256 GB memory

● Specifications of NVIDIA Tesla V100 16GB are as follows:– NVIDIA Tesla V100 16GB x 1, 4 CPU cores, 32 GB memory– NVIDIA Tesla V100 16GB x 2, 8 CPU cores, 64 GB memory– NVIDIA Tesla V100 16GB x 4, 16 CPU cores, 128 GB memory– NVIDIA Tesla V100 16GB x 8, 32 CPU cores, 256 GB memory

● Specifications of NVIDIA Tesla P4 8GB are as follows:– NVIDIA Tesla P4 8GB x 1, 4 CPU cores, 32 GB memory– NVIDIA Tesla P4 8GB x 2, 8 CPU cores, 64 GB memory– NVIDIA Tesla P4 8GB x 3, 16 CPU cores, 128 GB memory



https://en.wikipedia.org/wiki/Remote_direct_memory_access

– NVIDIA Tesla P4 8GB x 4, 32 CPU cores, 256 GB memory

If the pod type is not GPU-accelerated, the container specifications you selectmust meet the following requirements:

● The total number of CPU cores in a pod can be a value in the range of0.25-32, 48, or 64. The total number of CPU cores in a container is an integermultiple of 0.25.

● The total memory size (in GB) of a pod is an integer from 1 to 512.

● The ratio of CPU cores to memory size in a pod ranges from 1:2 to 1:8.

● A pod can have a maximum of five containers. The minimum configuration ofa container is 0.25 cores and 0.2 GB. The maximum configuration of acontainer is the same as that of a pod.

Creating a Pod

Kubernetes resources can be described using YAML or JSON files. For more detailsabout the YAML format, see YAML Syntax. The following example describes a podnamed nginx. This pod contains a container named container-0 and uses thenginx:alpine image, 0.5-core CPU, and 1024 MB memory.

apiVersion: v1 # Kubernetes API versionkind: Pod # Kubernetes resource typemetadata: name: nginx # Pod namespec: # Pod specification containers: - image: nginx:alpine # Used image is nginx:alpine name: container-0 # Container name resources: # Resources required for applying for a container. The values of limits and requests in CCI must be the same. limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi imagePullSecrets: # Secret used to pull the image, which must be imagepull-secret - name: imagepull-secret

As shown in the annotation of YAML, the YAML description file includes:

● metadata: Information such as name, label, and namespace

● spec: Pod specification such as image and volume used

If you query a Kubernetes resource, you can see the status field. This fieldindicates the status of the Kubernetes resource, and does not need to set whenthe resource is created. This example is a minimum set, and other parameterdefinition will be described later.

For the parameter description of Kubernetes resources, see API Reference.

After the pod is defined, you can create it using kubectl. If the YAML file is namednginx.yaml, run the following command to create the file. -f indicates that it iscreated in the form of a file.

$ kubectl create -f nginx.yamlpod/nginx created




Using GPUsYou can use GPUs in CCI only if the namespace is of the GPU-accelerated type. Toapply for GPU resources, you only need to specify GPU-related fields duringcontainer definition.

GPU-accelerated pods support the following GPUs: NVIDIA Tesla V100 32GB,NVIDIA Tesla V100 16GB, and NVIDIA Tesla P4 8GB.● Specifications of NVIDIA Tesla V100 32GB are as follows:

– NVIDIA Tesla V100 32GB x 1, 4 CPU cores, 32 GB memory– NVIDIA Tesla V100 32GB x 2, 8 CPU cores, 64 GB memory– NVIDIA Tesla V100 32GB x 4, 16 CPU cores, 128 GB memory– NVIDIA Tesla V100 32GB x 8, 32 CPU cores, 256 GB memory

● Specifications of NVIDIA Tesla V100 16GB are as follows:– NVIDIA Tesla V100 16GB x 1, 4 CPU cores, 32 GB memory– NVIDIA Tesla V100 16GB x 2, 8 CPU cores, 64 GB memory– NVIDIA Tesla V100 16GB x 4, 16 CPU cores, 128 GB memory– NVIDIA Tesla V100 16GB x 8, 32 CPU cores, 256 GB memory

● Specifications of NVIDIA Tesla P4 8GB are as follows:– NVIDIA Tesla P4 8GB x 1, 4 CPU cores, 32 GB memory– NVIDIA Tesla P4 8GB x 2, 8 CPU cores, 64 GB memory– NVIDIA Tesla P4 8GB x 3, 16 CPU cores, 128 GB memory– NVIDIA Tesla P4 8GB x 4, 32 CPU cores, 256 GB memory

Drivers 396.26 and 410.104 are compatible with NVIDIA GPUs. The CUDA toolkitused in your application must meet the requirements listed in Table 4-1. Fordetails about the compatibility between CUDA toolkits and drivers, see CUDACompatibility at https://www.nvidia.com.

Table 4-1 Compatibility between NVIDIA GPU drivers and CUDA toolkits

NVIDIAGPUDriverVersion

CUDA Toolkit Version

396.26 CUDA 9.2 (9.2.88) or earlier

410.104 CUDA 10.0 (10.0.130) or earlier

You need to add the cri.cci.io/gpu-driver field to the metadata.annotations areaof the pod to specify the GPU driver version to be used. The field can be set to oneof the following values:

● gpu-410.104● gpu-396.26

The following example shows how to create a pod with specifications of NVIDIAV100 16 GB x 1, 4 CPU cores, and 32 GB memory.



https://docs.nvidia.com/deploy/cuda-compatibility/index.html

https://docs.nvidia.com/deploy/cuda-compatibility/index.html

apiVersion: v1kind: Podmetadata: name: gpu-test annotations: cri.cci.io/gpu-driver: gpu-410.104 #Specify the GPU driver version.spec: containers: - image: tensorflow:latest name: container-0 resources: limits: cpu: 4000m memory: 32Gi nvidia.com/gpu-tesla-v100-16GB: 1 #Apply for GPU resources. The value can be 1, 2, 4, or 8, indicating the number of graphics cards. requests: cpu: 4000m memory: 32Gi nvidia.com/gpu-tesla-v100-16GB: 1 imagePullSecrets: - name: imagepull-secret

GPU-accelerated pods support the following GPU specifications:

● nvidia.com/gpu-tesla-v100-16GB: NVIDIA Tesla V100 16 GB GPU● nvidia.com/gpu-tesla-v100-32GB16G: NVIDIA Tesla V100 32 GB GPU● nvidia.com/gpu-tesla-p4: NVIDIA Tesla P4 8 GB GPU

Docker ImagesIn the preceding example, images nginx:alpine and tensorflow:latest are used.This indicates that public images from Docker Hub are used. HUAWEI CLOUDSoftware Repository for Container (SWR) synchronizes some common imagesfrom Docker Hub so that you can directly use them on the internal network. Youcan query the synchronized images on the SWR console. For the Docker Hubimages that are not synchronized, the container needs to access the externalnetwork to download them. In this case, you need to configure the network. Fordetails, see Accessing Public Networks from a Container.

In addition to using images from Docker Hub, you can upload your own images toHUAWEI CLOUD SWR.

Viewing Pod InformationAfter the pod is created, you can run the kubectl get pods command to query thepod information, as shown below.

$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx 1/1 Running 0 40s

The preceding information indicates that the nginx pod is in the Running state,indicating that the pod is running. READY is 1/1, indicating that there is onecontainer in the pod, and the container is in the Ready state.

You can run the kubectl get command to query the configuration informationabout a pod. In the following command, -o yaml indicates that the pod isreturned in YAML format. -o json indicates that the pod is returned in JSONformat.

$ kubectl get pod nginx -o yaml



https://www.huaweicloud.com/en-us/product/swr.html


https://www.huaweicloud.com/en-us/product/swr.html

You can also run the kubectl describe command to view the pod details.

$ kubectl describe pod nginx

Deleting a PodWhen a pod is deleted, Kubernetes stops all containers in the pod. Kubernetessends the SIGTERM signal to the process and waits for a period (30 seconds bydefault) to stop the container. If it is not stopped within the period, Kubernetessends a SIGKILL signal to kill the process.

You can stop and delete a pod in multiple methods. For example, you can delete apod by name, as shown below.

$ kubectl delete po nginxpod "nginx" deleted

Delete multiple pods at one time.

$ kubectl delete po pod1 pod2

Delete all pods.

$ kubectl delete po --allpod "nginx" deleted

Delete pods by labels. For details about labels, see the next section.

$ kubectl delete po -l app=nginxpod "nginx" deleted

4.2 Environment VariablesEnvironment variables are set in the container running environment.

They provide great flexibility for applications. You can use environment variables inapplications, assign values to environment variables when creating containers, andread the values of environment variables when containers are running, realizingflexible configuration. With environment variables, you do not need to rewriteapplication files to create images.

You can also use configMap and secret as environment variables. For details, see 9ConfigMap and Secret.

The following shows how to use an environment variable. You only need toconfigure the spec.containers.env field.

apiVersion: v1kind: Podmetadata: name: nginxspec: containers: - image: nginx:1 name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi env: # Environment variable



- name: env_key value: env_value - name: pod_name valueFrom: # Name of the referenced pod fieldRef: fieldPath: metadata.name - name: pod_ip valueFrom: # IP address of the referenced pod fieldRef: fieldPath: status.podIP imagePullSecrets: - name: imagepull-secret

4.3 Startup CommandStarting the container is to start the main process. However, some preparationsmust be made before the main process is started. For example, you may configureor initialize MySQL databases before running MySQL servers. You can setENTRYPOINT or CMD in the Dockerfile when creating an image. As shown in thefollowing, the ENTRYPOINT ["top", "-b"] command is set in the Dockerfile. Thiscommand will be executed during container startup.

FROM ubuntuENTRYPOINT ["top", "-b"]

When calling an API, you only need to configure the containers.commandparameter of the pod. This parameter is of the list type. The first parameter is theexecution command, while the subsequent parameters are the commandparameters.

apiVersion: v1kind: Podmetadata: name: nginxspec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi command: # Startup command - top - "-b" imagePullSecrets: - name: imagepull-secret

4.4 Lifecycle ManagementBased on Kubernetes, CCI provides containers with lifecycle hooks. The hooksenable containers to run code triggered by events during their managementlifecycle. For example, if you want a container to perform a certain operationbefore it is stopped, you can register a hook. The following lifecycle hooks areprovided:

● Post-Start Processing: triggered immediately after the workload is started



https://docs.docker.com/engine/reference/builder/#entrypoint

https://docs.docker.com/engine/reference/builder/#/cmd

https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/

● Pre-Stop Processing: triggered immediately before the workload is stopped

When calling an API, you only need to set the lifecycle.postStart orlifecycle.preStop parameter of the pod, as shown in the following:

apiVersion: v1kind: Podmetadata: name: nginxspec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi lifecycle: postStart: # Post-start processing exec: command: - "/postStart.sh" preStop: # Pre-stop processing exec: command: - "/preStop.sh" imagePullSecrets: - name: imagepull-secret

4.5 Liveness Probe

OverviewKubernetes provides the self-healing capability, that is, Kubernetes can detect thecontainer crash and restart the container. However, sometimes memory leakageoccurs in a Java program, and the program cannot work normally, while the JVMprocess is still running. For such issues, Kubernetes provides the liveness probemechanism to determine whether to restart the container by checking whetherthe container responses normally. This is a good health check mechanism.

A liveness probe should be defined for each pod. Otherwise, Kubernetes cannotdetect whether the pod is running properly.

CCI supports the following detection mechanisms:

● HTTP GET: Send an HTTP GET request to the container. If the probe receives2xx or 3xx, the container is healthy.

● Exec: The probe runs a command in the container and checks the exit statuscode. If the exit status code is 0, the probe is healthy.

HTTP GETHTTP GET is the most common detection method. The mechanism is to send anHTTP GET request to the container. If the probe receives 2xx or 3xx, the containeris healthy. The method is defined as follows:

apiVersion: v1kind: Pod



metadata: name: liveness-httpspec: containers: - name: liveness image: k8s.gcr.io/liveness args: - /server livenessProbe: # liveness probe httpGet: #HTTP GET definition path: /healthz port: 8080

Create a pod.

$ kubectl create -f liveness-http.yamlpod/liveness-http created

As shown above, the probe sends an HTTP GET request to port 8080 of thecontainer. The preceding program returns the status code 500 for the fifth request.Then Kubernetes restarts the container.

View pod details.

$ kubectl describe po liveness-httpName: liveness-http......Containers: container-0: ...... State: Running Started: Mon, 12 Nov 2018 22:57:28 +0800 Last State: Terminated Reason: Error Exit Code: 137 Started: Mon, 12 Nov 2018 22:55:40 +0800 Finished: Mon, 12 Nov 2018 22:57:27 +0800 Ready: True Restart Count: 1 Liveness: http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3......Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 3m5s default-scheduler Successfully assigned default/pod-liveness to node2 Normal Pulling 74s (x2 over 3m4s) kubelet, node2 pulling image "pod-liveness" Normal Killing 74s kubelet, node2 Killing container with id docker://container-0:Container failed liveness probe.. Container will be killed and recreated.

As shown, for the pod, the State is Running, the Last State is Terminated, and theRestart Count is 1, indicating that the pod is restarted once. In addition, you cansee the following information from the event: Killing container with id docker://container-0:Container failed liveness probe.. Container will be killed andrecreated.

After the container is killed, a new container is created.

ExecExec is to execute a specific command. The mechanism is that the probe executesthe command in the container and checks the exit status code of the command. Ifthe status code is 0, the pod is healthy. The method is defined as follows:

apiVersion: v1kind: Pod



metadata: labels: test: liveness name: liveness-execspec: containers: - name: liveness image: busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: # liveness probe exec: # Exec definition command: - cat - /tmp/healthy

Run the cat /tmp/healthy command in the container. If the command is executedsuccessfully and 0 is returned, the container is healthy.

Advanced Configuration of Liveness ProbeIn output of the $ kubectl describe po liveness-http command, the followinginformation is displayed:

Liveness: http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3

This line indicates the parameter configuration of the liveness probe. Themeanings of the parameters are as follows:

● delay=0s indicates that the probe starts immediately after the container isstarted.

● timeout=1s indicates that the container must respond to the probe within 1s.Otherwise, the detection fails.

● period=10s indicates that the detection is performed every 10s.● #success=1 indicates that the detection is successful after succeeding once.● #failure=3 indicates that the container is restarted after three consecutive

detection failures.

These are set by default when the probe is created. You can also manuallyconfigure the parameters as follows:

apiVersion: v1kind: Podmetadata: name: liveness-httpspec: containers: - image: k8s.gcr.io/liveness livenessProbe: httpGet: path: / port: 8080 initialDelaySeconds: 10 # When does the container start detection after the container is started? timeoutSeconds: 2 # The container must respond to the probe within 2s. Otherwise, the detection fails. periodSeconds: 30 # Detection period, once every 30s. successThreshold: 1 # The detection is successful after succeeding once. failureThreshold: 3 # The container is restarted after three consecutive detection failures.

Generally, the value of initialDelaySeconds must be greater than 0, because inmost cases, although the container is started successfully, it takes a while for the



application to be ready. After the application is ready, a success message isreturned. Otherwise, the probe may fail frequently.

In addition, you can set failureThreshold to allow multiple loop detection, so thatyou do not have to repeatedly run the health check program.

Configuring an Effect Liveness Probe● What should a liveness probe detect?

A liveness probe should check whether all the key parts of an application arehealthy and use a dedicated URL, such as /health. This function is performedwhen /health is accessed, and then the result is returned. Note thatauthentication cannot be performed. Otherwise, the probe will repeatedly failand be restarted.In addition, the check can be performed only within the application, andcannot be performed outside the dependency. For example, if the frontendweb server cannot connect to the database, the web server cannot beconsidered as unhealthy.

● A liveness probe must be lightweight.A liveness probe cannot occupy too many resources or too much time.Otherwise, the health check is wasting resources. For example, for Javaapplications, the HTTP GET method is recommended. If the Exec method isused, the JVM startup occupies too many resources.



5 Label

Why Are Labels Required?As resources increase, how to classify and manage resources becomes important.Kubernetes provides a mechanism to classify resources, that is, using labels. Labelsare simple but powerful. Almost all resources in the Kubernetes can be organizedby labels.

A label is a key-value pair, which can be set when a resource is created, or can beadded or modified later.

Taking pods as an example, as the number of pods increases, pods becomecluttered and difficult to manage, as shown in the following figure.

Figure 5-1 Pods without classification

If we attach different labels to the pods, the situation is totally different, as shownin the following figure.

Cloud Container InstanceDeveloper Guide 5 Label


Figure 5-2 Pods organized with labels

Adding a Label

A label is a key-value pair. As shown below, two labels app=nginx and env=prodare set for a pod.

apiVersion: v1kind: Podmetadata: name: nginx labels: # Set two labels for the pod app: nginx env: prodspec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi imagePullSecrets: - name: imagepull-secret

When a pod has labels, you can view the label of the pod by using --show-labelswhen querying the pod.

$ kubectl get pod --show-labelsNAME READY STATUS RESTARTS AGE LABELSnginx 1/1 Running 0 50s app=nginx,env=prod

You can also use -L to query only certain labels.

$ kubectl get pod -L app,env NAME READY STATUS RESTARTS AGE APP ENVnginx 1/1 Running 0 1m nginx prod

For an existing pod, you can directly run the kubectl label command to add alabel.

$ kubectl label po nginx creation_method=manualpod "nginx" labeled

$ kubectl get pod --show-labelsNAME READY STATUS RESTARTS AGE LABELSnginx 1/1 Running 0 50s app=nginx,env=prod,creation_method=manual



Modifying a LabelIf you want to modify an existing label, you need to add --overwrite to thecommand, as shown below:

$ kubectl label po nginx env=debug --overwritepod "nginx" labeled

$ kubectl get pod --show-labelsNAME READY STATUS RESTARTS AGE LABELSnginx 1/1 Running 0 50s app=nginx,env=debug,creation_method=manual



6 Deployment

4 Pod describes pod, which is the smallest and simplest unit in the Kubernetesobject model that you create or deploy. However, a pod is designed to be a one-off entity. A pod can be evicted (when node resources are insufficient) anddisappears as the cluster node fails. Kubernetes provides controllers to managepods. Controllers can create and manage multiple pods, and provide replicamanagement, rolling upgrade, and self-healing capabilities. The most commonlyused is Deployment.

A Deployment can contain one or more pod replicas. Each pod replica has thesame role. Therefore, the system automatically distributes requests to multiplepod replicas of a Deployment.

A Deployment integrates a lot of functions, including online deployment, rollingupgrade, replica creation, and restoration of online jobs. To some extent,Deployments can be used to realize unattended rollout, which greatly reducescommunication difficulties and operation risks in the rollout process.

Creating a DeploymentIn the following example, a Deployment named nginx is created, and two podreplicas are created from the nginx:latest image. Each pod replica occupies 500m-core CPU and 1 GB memory.apiVersion: apps/v1 # Note the difference with pod. It is apps/v1 instead of v1 for a Deployment.kind: Deployment # The resource type is Deployment.metadata: name: nginx # Name of the Deploymentspec: replicas: 2 # Number of pod replicas. The Deployment ensures that two pod replicas are running. selector: # Label Selector matchLabels: app: nginx template: # Definition of a pod, which is used to create pods. It is also known as pod template. metadata: labels: app: nginx spec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi

Cloud Container InstanceDeveloper Guide 6 Deployment


requests: cpu: 500m memory: 1024Mi imagePullSecrets: #Secret used to pull the image, which must be imagepull-secret. - name: imagepull-secret

In this definition, the name of the Deployment is nginx, and spec.replicas definesthe number of pods. That is, the Deployment controls two pods. spec.selector is alabel selector, indicating that the Deployment selects the pod whose label isapp=nginx. spec.template is the definition of the pod and is the same as thatdefined in 4.1 Pod.

Save the definition of the Deployment to deployment.yaml and use kubectl tocreate the Deployment.

Run the kubectl get command to view the Deployment and the pods. The valueof DESIRED is 2, indicating that the Deployment desires two pods. The value ofCURRENT is 2, indicating that there are two pods. The value of AVAILABLE is 2,indicating that two pods are available.

$ kubectl create -f deployment.yaml

$ kubectl get deploymentNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGEnginx 2 2 2 2 8s

How Does the Deployment Control Pods?

Continue to query pods, as shown below.

$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx-7f98958cdf-tdmqk 1/1 Running 0 13snginx-7f98958cdf-txckx 1/1 Running 0 13s

If you delete a pod, a new pod is immediately created, as shown below. Asmentioned above, the Deployment ensures that there are two pods running. If apod is deleted, the Deployment creates a new pod. If a pod crashes or is faulty, theDeployment automatically restarts the pod.

$ kubectl delete pod nginx-7f98958cdf-txckx

$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx-7f98958cdf-tdmqk 1/1 Running 0 21snginx-7f98958cdf-tesqr 1/1 Running 0 21s

There are two pods, nginx-7f98958cdf-tdmqk and nginx-7f98958cdf-tesqr, inwhich nginx is the name of the Deployment, and -7f98958cdf-tdmqk and-7f98958cdf-tesqr are the suffixes randomly generated by Kubernetes.

You may notice that the first part of the two suffixes is the same, that is,7f98958cdf. This is because the Deployment does not control the pod directly, butthrough a controller named ReplicaSet. You can run the following command toquery the ReplicaSet, in which rs is the abbreviation of ReplicaSet.

$ kubectl get rsNAME DESIRED CURRENT READY AGEnginx-7f98958cdf 3 3 3 1m

The name of the ReplicaSet is nginx-7f98958cdf, and the suffix -7f98958cdf isgenerated randomly.



As shown in Figure 6-1, the Deployment controls the ReplicaSet, which thencontrols the pod.

Figure 6-1 How does the Deployment control the pod

If you run the kubectl describe command to view the details of the Deployment,you can see the ReplicaSet. As shown below, you can see a line NewReplicaSet:nginx-7f98958cdf (2/2 replicas created). In events, the number of pods of theReplicaSet is scaled out to 2. In practice, you may not operate ReplicaSet directly,but understanding that a Deployment controls a pod by controlling a ReplicaSethelps you locate problems.

$ kubectl describe deploy nginxName: nginxNamespace: defaultCreationTimestamp: Sun, 16 Dec 2018 19:21:58 +0800Labels: app=nginx

...

NewReplicaSet: nginx-7f98958cdf (2/2 replicas created)Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 5m deployment-controller Scaled up replica set nginx-7f98958cdf to 2

Upgrade

In actual applications, upgrade is a common operation. A Deployment can easilysupport application upgrade.

You can set different upgrade policies for a Deployment:

● RollingUpdate: Gradually create new pods and delete old pods). This is thedefault policy.

● Recreate: Delete the current pods and then create new pods.

The Deployment upgrade can be in declarative mode. That is, you only need tomodify the YAML definition of the Deployment. For example, you can run thekubectl edit command to change the Deployment image to nginx:alpine. Afterthe modification, query the ReplicaSet and pod, a new ReplicaSet is created, andthe pod is recreated.

$ kubectl edit deploy nginx

$ kubectl get rsNAME DESIRED CURRENT READY AGEnginx-6f9f58dffd 2 2 2 1mnginx-7f98958cdf 0 0 0 48m

$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx-6f9f58dffd-tdmqk 1/1 Running 0 21snginx-6f9f58dffd-tesqr 1/1 Running 0 21s



The Deployment can use the maxSurge and maxUnavailable parameters tocontrol the proportion of pods to be recreated during the upgrade. This is useful inmany scenarios. The configuration is as follows:

spec: strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 type: RollingUpdate

● maxSurge: Specifies the maximum number of pods that can exist overspec.replicas in the Deployment. The default value is 25%. For example, ifspec.replicas is set to 4, no more than 5 pods can exist during the upgradeprocess, that is, the upgrade step is 1. The absolute number is calculated fromthe percentage by rounding up. The value can also be set to an absolutenumber.

● maxUnavailable: Specifies the maximum number of pods that can beunavailable during the update process. The default value is 25%. For example,if spec.replicas is set to 4, at least 3 pods exist during the upgrade process,that is, the deleting step is 1. The value can also be set to an absolutenumber.

In the preceding example, the value of spec.replicas is 2. If both maxSurge andmaxUnavailable are the default value 25%, maxSurge allows a maximum of threepods to exist (2 * 1.25 = 2.5, rounded up to 3), maxUnavailable does not allowunavailable pods (2 * 0.75 = 1.5, rounded up to 2). That is, during the upgradeprocess, two pods are running. Each time a new pod is created, an old pod isdeleted, until all pods are new.

RollbackRollback is to roll an application back to the earlier version when a fault occursduring the upgrade. A Deployment can be easily rolled back to the earlier version.

For example, if the upgraded image is faulty, you can run the kubectl rolloutundo command to roll back.

$ kubectl rollout undo deployment nginxdeployment "nginx" rolled back

A Deployment can be easily rolled back because a Deployment uses a ReplicaSetto control a pod. After the upgrade, the ReplicaSet still exists. The Deployment isrolled back by recreating the pod using the ReplicaSet. The number of ReplicaSetsstored in a Deployment can be restricted by the revisionHistoryLimit parameter.The default value is 10.



7 Managing Network Access ThroughService and Ingress

7.1 Service

Direct Access to a PodHow can I access a workload after it is created? Accessing a workload is to accessa pod. However, the following problems may occur when you access a poddirectly:

● The pod can be deleted and recreated at any time by a controller such as aDeployment, and the result of accessing the pod becomes unpredictable.

● The IP address of the pod is allocated only after the pod is started. Before thepod is started, the IP address of the pod is unknown.

● An application is usually composed of multiple pods that run the same image.Accessing pods one by one is low efficiency.

For example, an application uses Deployments to create the frontend andbackend. The frontend calls the backend for computing, as shown in Figure 7-1.Three pods are running in the backend, which are independent and replaceable.When a backend pod is recreated, the new pod is assigned with a new IP addressand the frontend pod is unaware.

Cloud Container InstanceDeveloper Guide

7 Managing Network Access Through Service andIngress


Figure 7-1 Inter-workload access

How Do Services WorkKubernetes Services are used to solve the preceding pod access problems. AService has a fixed IP address and forwards the traffic to the pods based on labels.In addition, the Service can perform load balancing for these pods.

In the preceding example, two Services are added for accessing the frontend andbackend pods. In this way, the frontend pod does not need to sense changes onbackend pods, as shown in Figure 7-2.




Figure 7-2 Accessing pods through a Service

Creating a ServiceIn the following example, create a Service named nginx, and use a selector toselect the pod with the label of app:nginx. The port of the target pod is port 80while the exposed port of the Service is port 8080.

The Service can be accessed using Service name:Exposed port. In the example,nginx:8080 is used. In this case, other workloads can access the pod associatedwith nginx using nginx:8080.apiVersion: v1kind: Servicemetadata: name: nginx #Service namespec: selector: #Label selector, which selects pods with the lable of app=nginx app: nginx ports:




- name: service0 targetPort: 80 #Pod port port: 8080 #Service external port protocol: TCP #Forwarding protocol type. The value can be TCP or UDP. type: ClusterIP #Service type

NodePort Services are supported in native Kubernetes, but not supported in CCI.

Save the Service definition to nginx-svc.yaml and use kubectl to create theService.

# kubectl create -f nginx-svc.yamlservice/nginx created

# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkube-dns ClusterIP 10.247.9.190 <none> 53/UDP,53/TCP 7mnginx ClusterIP 10.247.148.137 <none> 8080/TCP 1h

You can see that the Service has a ClusterIP, which is fixed unless the Service isdeleted. You can use this ClusterIP to access the Service internally.

kube-dns is a Service reserved for domain name resolution. It is automatically created inCCI. For details about domain name resolution, see Using ServiceName to Access aService.

Using ServiceName to Access a Service

In CCI, you can use the coredns add-on to resolve the domain name for a Service,and use ServiceName:Port to access to the Service. This is the most commonmode in Kubernetes. For details about how to install coredns, see Add-onManagement.

After coredns is installed, it becomes a DNS. After the Service is created, corednsrecords the Service name and IP address. In this way, the pod can obtain theService IP address by querying the Service name from coredns.

nginx.<namespace>.svc.cluster.local is used to access the Service. nginx is theService name, <namespace> is the namespace, and svc.cluster.local is thedomain name suffix. In actual use, you can omit <namespace>.svc.cluster.localand use the Service name.

For example, if the Service named nginx is created, you can access the Servicethrough nginx:8080 and then access backend pods.

An advantage of using ServiceName is that you can write ServiceName into theprogram when developing the application. In this way, you do not need to knowthe IP address of a specific Service.

NO TICE

The coredns add-on occupies computing resources. It runs two pods, with eachpod occupies 0.5 core CPU and 1 GB memory. You need to pay for the resources.




https://coredns.io/



LoadBalancer ServicesYou have known that you can create ClusterIP Services. You can access backendpods of the Service through the IP address.

CCI also supports LoadBalancer Services. You can bind an enhanced load balancerto a Service. In this way, the traffic for accessing the load balancer is forwarded tothe Service.

Enhanced load balancers can be divided into private network load balancers andpublic network load balancers based on IP addresses. The difference is that apublic IP address is bound to a public network load balancer. You can select loadbalancers as required. You can create an enhanced load balancer by using the APIor the ELB console.

The enhanced load balancer must be in the same VPC as the Service. Otherwise, theenhanced load balancer cannot be bound.




https://support.huaweicloud.com/en-us/api-elb/en-us_topic_0096561535.html

https://console.huaweicloud.com/vpc/?&locale=en-us#/elbs/enhancedElbs

Figure 7-3 LoadBalancer Service

The following is an example of creating a LoadBalancer Service. After anenhanced load balancer is created, you can access backend pods through IP:portof the enhanced load balancer.apiVersion: v1kind: Servicemetadata: name: nginx annotations: kubernetes.io/elb.id: 77e6246c-a091-xxxx-xxxx-789baa571280 # ID of the enhanced load balancer tenant.kubernetes.io/project-id: a9cab8xxxxxxxxxxxxxxxx41c0aeb # Project ID tenant.kubernetes.io/domain-id: 65382xxxxxxxxxxxxxxxxxe684b # Account IDspec: selector: app: nginx ports: - name: service0 targetPort: 80 port: 8080 # Enhanced load balancer's access port




protocol: TCP type: LoadBalancer # Service type

7.2 IngressThe previous section describes how to create a LoadBalancer Service that uses anenhanced load balancer to access pods.

Services forward requests based on the layer-4 TCP and UDP protocols. Ingressescan forward requests based on the layer-7 HTTP and HTTPS protocols. Domainnames and paths can be used to achieve finer granularities, as shown in thefollowing figure.

Figure 7-4 Ingress-Service

In CCI, external access is implemented by binding the enhanced load balancer's IPaddress and port number to an ingress, as shown in Figure 7-5.




Figure 7-5 Ingress

Enhanced Load BalancersIngresses can be bound to enhanced load balancers. You can create an enhancedload balancer by using the API or the ELB console.

Enhanced load balancers can be divided into private network load balancers andpublic network load balancers based on IP addresses. The difference is that apublic IP address is bound to a public network load balancer. You can select loadbalancers as required.




https://support.huaweicloud.com/en-us/api-elb/en-us_topic_0096561535.html

https://console.huaweicloud.com/vpc/?&locale=en-us#/elbs/enhancedElbs

Creating an IngressIn the following example, the HTTP protocol is used and the associated backend isnginx:8080. When http://10.10.10.10:6071/ is accessed, the traffic is forwarded tothe Service corresponding to nginx:8080, and then to the corresponding pod.apiVersion: extensions/v1beta1 # Ingress versionkind: Ingressmetadata: name: nginx labels: app: nginx isExternal: "true" # This parameter is mandatory and must be set to true. zone: data # Data plane mode. This parameter is mandatory and must be set to data. annotations: kubernetes.io/elb.id: 2d48d034-6046-48db-8bb2-53c67e8148b5 # ID of the enhanced load balancer. This parameter is mandatory. kubernetes.io/elb.ip: 192.168.137.182 # IP address of the enhanced load balancer. This parameter is optional. kubernetes.io/elb.port: '6071' # Port number of the enhanced load balancer. This parameter is mandatory.spec: rules: # Routing rules - http: # Using HTTP protocol paths: - path: / # Route backend: serviceName: nginx # Name of the Service to which requests are forwarded servicePort: 8080 # Port of the Service to which requests are forwarded

You can also set the external domain name in an ingress so that you can accessthe enhanced load balancer through the domain name and then access backendServices.

Domain name access depends on domain name resolution. You need to point the domainname to the IP address of the enhanced load balancer. For example, you can use DomainName Service (DNS) to resolve domain names.

spec: rules: - host: www.example.com # Domain name http: paths: - path: / backend: serviceName: nginx servicePort: 80

Accessing Multiple ServicesAn ingress can access multiple Services at the same time. The configuration is asfollows:

● When accessing http://foo.bar.com/foo, you access the backend s1:80.● When accessing http://foo.bar.com/bar, you access the backend s2:80.spec: rules: - host: foo.bar.com # Host address http: paths: - path: "/foo" backend: serviceName: s1 servicePort: 80




https://www.huaweicloud.com/en-us/product/dns.html

https://www.huaweicloud.com/en-us/product/dns.html

- path: "/bar" backend: serviceName: s2 servicePort: 80

7.3 Network Access ScenariosThe previous two sections describe how to access pods through Services andingresses. This section describes scenarios of accessing pods in CCI, as shown inFigure 7-6. In each scenario, Services and ingresses can be used to solve accessproblems.

● Intra-namespace access: You only need to create a Service. A workload can beaccessed from other workloads in the same namespace by using Servicename:Service port.

● Intra-VPC access: A workload can be accessed from other workloads in thesame VPC by using the IP address of a Service or the IP address of the privatenetwork load balancer bound to an ingress.

● Inter-VPC access: You can create a VPC peering connection to connect twoVPCs. A workload is accessible to workloads in the other VPC by using the IPaddress of a Service or the IP address of the private network load balancer.

● Access to a workload from the public network: A workload can be accessedfrom the outside of HUAWEI CLOUD by using the IP address of the privatenetwork load balancer bound to an ingress.

● Access to the public network from a workload: You can configure sourcenetwork address translation (SNAT) rules in NAT Gateway, so that containerscan access the public network. For details, see Accessing Public Networksfrom a Container.




https://support.huaweicloud.com/en-us/usermanual-vpc/en-us_topic_0046655036.html

https://www.huaweicloud.com/en-us/product/nat.html



Figure 7-6 Network access diagram

7.4 Readiness ProbeAfter a pod is created, the Service can immediately select it and forward requeststo it. However, it takes time to start a pod. If the pod is not ready (it takes time toload the configuration or data, or a preheating program may need to beexecuted), the pod cannot process requests, and the requests will fail.

Kubernetes solves this problem by adding a readiness probe to pods. The Servicecan forward requests to a pod only after the probe detects that the pod is ready.

The readiness probe periodically detects a pod and determines whether the pod isready based on the response. Similar to 4.5 Liveness Probe, CCI also supports twotypes of readiness probes.

● HTTP GET: The probe sends an HTTP GET request to IP:port of the container.If the probe receives a 2xx or 3xx status code, the container is ready.

● Exec: The probe runs a command in the container and checks the exit statuscode. If the exit status code is 0, the container is ready.

Working Principles of the Readiness ProbeIf you run the kubectl describe command to view the Service information:

$ kubectl describe svc nginxName: nginx......Endpoints: 192.168.113.81:80,192.168.165.64:80,192.168.198.10:80......




One Endpoints is displayed, which is also a resource object in Kubernetes.

$ kubectl get endpointsNAME ENDPOINTS AGEnginx 192.168.113.81:80,192.168.165.64:80,192.168.198.10:80 14m

192.168.113.81:80 is the IP:port of the pod. You can run the following commandto view the IP address of the pod, which is the same as the preceding IP address.

# kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP nginx-55c54cc5c7-49chn 1/1 Running 0 1m 192.168.198.10nginx-55c54cc5c7-x87lb 1/1 Running 0 1m 192.168.165.64nginx-55c54cc5c7-xp4c5 1/1 Running 0 1m 192.168.113.81

Endpoints can be used as a readiness probe. When the pod is not ready, IP:port isdeleted from the Endpoints and is added to the Endpoints after the pod is ready,as shown in the following figure.

Figure 7-7 Working principles of the readiness probe

ExecThe Exec mode is the same as the HTTP GET mode. As shown below, the proberuns the ls /ready command. If the file exists, 0 is returned, indicating that thepod is ready. Otherwise, another status code is returned.

apiVersion: apps/v1kind: Deploymentmetadata: name: nginxspec: replicas: 3 selector: matchLabels: app: nginx




template: metadata: labels: app: nginx spec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi readinessProbe: # Readiness Probe exec: # Define the ls /ready command command: - ls - /ready imagePullSecrets: - name: imagepull-secret

Save the definition of the Deployment to deploy-read.yaml, delete the previouslycreated Deployment, and use deploy-read.yaml to recreate the Deployment.

# kubectl delete deploy nginxdeployment.apps "nginx" deleted

# kubectl create -f deploy-read.yamldeployment.apps/nginx created

The nginx image does not contain the /ready file. Therefore, the container is notin Ready state after the creation, as shown below. Note that the value in theREADY column is 0/1, indicating that the container is not ready.

# kubectl get poNAME READY STATUS RESTARTS AGEnginx-7955fd7786-686hp 0/1 Running 0 7snginx-7955fd7786-9tgwq 0/1 Running 0 7snginx-7955fd7786-bqsbj 0/1 Running 0 7s

Check the Service again. If there are no values in the Endpoints line, no Endpointsare found.

$ kubectl describe svc nginxName: nginx......Endpoints: ......

If a /ready file is created in the container to make the readiness probe succeed,the container is in the Ready state. Check the pod and Endpoints. It is found thatthe container for which the /ready file is created is ready and an Endpoints isadded.

# kubectl exec nginx-7955fd7786-686hp -- touch /ready

# kubectl get po -o wideNAME READY STATUS RESTARTS AGE IPnginx-7955fd7786-686hp 1/1 Running 0 10m 192.168.93.169 nginx-7955fd7786-9tgwq 0/1 Running 0 10m 192.168.166.130nginx-7955fd7786-bqsbj 0/1 Running 0 10m 192.168.252.160

# kubectl get endpointsNAME ENDPOINTS AGEnginx 192.168.93.169:80 14d




HTTP GETThe configuration of the readiness probe is the same as that of liveness probe,which is also in the container of the pod template. As shown below, the readinessprobe sends an HTTP request to the pod. If the probe receives 2xx or 3xx, the podis ready.apiVersion: apps/v1kind: Deploymentmetadata: name: nginxspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi readinessProbe: # readinessProbe httpGet: # HTTP GET definition path: /read port: 80 imagePullSecrets: - name: imagepull-secret

Advanced Configuration of Readiness ProbeSimilar to the liveness probe, the readiness probe also has the same advancedconfiguration items. The output of the describe command of the nginx pod is asfollows:Readiness: exec [ls /var/ready] delay=0s timeout=1s period=10s #success=1 #failure=3

This line indicates the parameter configuration of the readiness probe. Themeanings of the parameters are as follows:

● delay=0s indicates that the probe starts immediately after the container isstarted.

● timeout=1s indicates that the container must respond to the probe within 1s.Otherwise, the detection fails.

● period=10s indicates that the detection is performed every 10s.● #success=1 indicates that the detection is successful after succeeding once.● #failure=3 indicates that the container will be restarted after three

consecutive detection failures.

These are set by default when the probe is created. You can also manuallyconfigure the parameters as follows: readinessProbe: # Readiness Probe exec: # Define the ls /readiness/ready command




command: - ls - /readiness/ready initialDelaySeconds: 10 # When does the container start detection after the container is started? timeoutSeconds: 2 # The container must respond to the probe within 2s. Otherwise, the detection fails. periodSeconds: 30 # Detection period, once every 30s. successThreshold: 1 # The detection is successful after succeeding once. failureThreshold: 3 # The container will be restarted after three consecutive detection failures.




8 Using PersistentVolumeClaim to Applyfor Persistent Storage

CCI supports the following persistent storage services in containers:

● Elastic Volume Service (EVS) is a block storage service that provides threespecifications: common I/O (SATA), high I/O (SAS), and ultra-high I/O (SSD).

● Scalable File Service (SFS) provides shared file storage and supports thestandard file protocol type (nfs-rw). SFS provides two types of file systems:SFS and SFS Turbo.– SFS is expandable to petabytes, and provides fully hosted shared file

storage. It features high availability and durability, and seamlesslyhandles data-intensive and bandwidth-intensive applications. SFS issuitable for high-performance computing (HPC), media processing, filesharing, content management and web services.

– SFS Turbo is expandable to 320 TB, and provides fully hosted shared filestorage. It features high availability and durability, and supports massivequantities of small files and applications requiring low latency and highIOPS. SFS Turbo is suitable for high-performance websites, log storage,compression and decompression, DevOps, enterprise offices, andcontainerized applications.

Currently, SFS Turbo volumes are unavailable in the CN East-Shanghai 1 region.

● Object Storage Service (OBS) is an object-based storage service, andprovides massive, secure, highly reliable, and low-cost data storagecapabilities.

Among the three storage services, OBS is the most easy to use. CCI can use theOBS as SDK. You can configure OBS usage when defining an application using anSDK, package the application into an image, and then use the image to deploy aworkload on CCI. For details about how to download and use the OBS SDK, seehttps://developer.huaweicloud.com/en-us/sdk?OBS.

EVS and SFS need to be mounted before being used. The following describes howto use EVS and SFS.


8 Using PersistentVolumeClaim to Apply forPersistent Storage


https://www.huaweicloud.com/en-us/product/evs.html

https://www.huaweicloud.com/en-us/product/sfs.html

https://www.huaweicloud.com/en-us/product/obs.html

https://developer.huaweicloud.com/en-us/sdk?OBS

PersistentVolumeClaim (PVC)

Kubernetes provides PVC to apply for persistent storage. The PVC allows you tospecify the type and capacity of storage without concerning about how to createand release underlying storage resources.

In practice, you can associate a PVC with the volume in the pod and use thepersistent storage through the PVC, as shown in Figure 8-1.

Figure 8-1 Using persistent storage

Creating a PVC● Creating a PVC to apply for a 100 GB SATA EVS disk

To create an encrypted EVS volume, add the paas.storage.io/cryptKeyId fieldin metadata.annotations.apiVersion: v1kind: PersistentVolumeClaimmetadata: name: pvc-evs namespaces: namespaces-test annotations: { paas.storage.io/cryptKeyId: ee9b610c-e356-11e9-aadc-d0efc1b3bb6b }spec: accessModes: - ReadWriteMany resources: requests: storage: 100Gi storageClassName: sata

accessModes indicates the volume access modes. The following three modesare supported:– ReadWriteOnce: A volume can be mounted to a single node for reading

and writing.– ReadOnlyMany: A volume can be mounted to multiple nodes for

reading.– ReadWriteOnce: A volume can be mounted to multiple nodes for

reading and writing.storageClassName indicates the applied storage class. Currently, thefollowing four classes are supported:– sata: SATA (common I/O) EVS disk– sas: SAS (high I/O) EVS disk– ssd: SSD (ultra-high I/O) EVS disk– nfs-rw: SFS file storage of the standard file protocol

● Creating a PVC to apply for a 100 GB file system




To create an encrypted SFS volume, add the paas.storage.io/cryptKeyId,paas.storage.io/cryptAlias, and paas.storage.io/cryptDomainId fields inmetadata.annotations.apiVersion: v1kind: PersistentVolumeClaimmetadata: name: pvc-sfs namespace: namespace-test annotations: { paas.storage.io/cryptKeyId: ee9b610c-e356-11e9-aadc-d0efc1b3bb6b paas.storage.io/cryptAlias: sfs/default paas.storage.io/cryptDomainId: d6912480-c3d6-4e9e-8c70-38afeea434c3 volume.beta.kubernetes.io/storage-provisioner: flexvolume-huawei.com/fuxinfs }spec: accessModes: - ReadWriteMany resources: requests: storage: 100Gi storageClassName: nfs-rw

Using a PVCAfter applying for storage resources using a PVC, you can use a volume in the podto associate the PVC and mount the volume to containers.

The following example shows how to use a PVC in a pod. A volume named pvc-test-example is defined and mounted to the /tmp/volume0 directory of thecontainer. In this way, the data written to /tmp is written to the PVC named pvc-test.

● Writing data to the applied SATA EVS diskapiVersion: v1kind: Podmetadata: name: nginx labels: app: nginxspec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi volumeMounts: - mountPath: "/tmp" # Mount the PVC to the /tmp/volume0 directory of the container. name: pvc-test-example # Volume name. volumes: # Define a volume, and associate it with the PVC. - name: pvc-test-example persistentVolumeClaim: claimName: pvc-test # PVC name. imagePullSecrets: - name: imagepull-secret

● Writing data to the applied file system (with storageClassName set to nfs-rw)When creating a PVC to apply for a file system (with storageClassName setto nfs-rw), you can set the mount subdirectory in volumeMounts, that is, asubdirectory in the root directory of the file system.




apiVersion: v1kind: Podmetadata: name: nginx labels: app: nginxspec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi volumeMounts: - mountPath: "/tmp" # Mount the PVC to the /tmp/volume0 directory of the container. subPath: "abc" # Subdirectory in the root directory of the file system. If the subdirectory does not exist, it is automatically created in the file system. The subdirectory must be a relative directory. name: pvc-test-example # Volume name. volumes: # Define a volume, and associate it with the PVC. - name: pvc-test-example persistentVolumeClaim: claimName: pvc-test # PVC name. imagePullSecrets: - name: imagepull-secret




9 ConfigMap and Secret

9.1 configMapA configMap is a resource object for storing configuration information required byapplications. It uses the key-value pair to save configuration data. It can be usedto save a single attribute or configuration file.

A configMap can be used to decouple configuration and make differentconfigurations in different environments. Compared with the environmentvariables, the configMap referenced in the pod can be updated in real time. Afterthe configMap data is updated, the configMap referenced in the pod is updatedsynchronously.

Creating a configMapIn the following example, a configMap named configmap-test is created. TheconfigMap configuration data is defined in the data field.

apiVersion: v1kind: ConfigMapmetadata: name: configmap-testdata: # Configuration data property_1: Hello property_2: World

Referencing a configMap in Environment VariablesA configMap is usually referenced in environment variables and volumes.

In the following example, the property_1 of configmap-test is used as the valueof the environment variable EXAMPLE_PROPERTY_1. In this case, the value ofEXAMPLE_PROPERTY_1 is the value of property_1 after the container is started,that is, Hello.

apiVersion: v1kind: Podmetadata: name: nginxspec: containers:

Cloud Container InstanceDeveloper Guide 9 ConfigMap and Secret


- image: nginx:latest resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi env: - name: EXAMPLE_PROPERTY_1 valueFrom: configMapKeyRef: # Reference the configMap name: configmap-test key: property_1 imagePullSecrets: - name: imagepull-secret

Referencing a configMap in a Volume

Referencing a configMap in a volume is to fill each piece of data to the volume inthe form of files. Each piece of data is a file. The key is the file name, and the keyvalue is the file content.

In the following example, create a volume named vol-configmap, reference theconfigMap named configmap-test in the volume, and mount the volume tothe /tmp directory of the container. After the pod is created, there are two filesproperty_1 and property_2 in the /tmp directory of the container, and the valuesare Hello and World.

apiVersion: v1kind: Podmetadata: name: nginxspec: containers: - image: nginx:latest resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi volumeMounts: - name: vol-configmap # Mount the volume named vol-configmap mountPath: "/tmp1" imagePullSecrets: - name: imagepull-secret volumes: - name: vol-configmap configMap: # Reference the configMap name: configmap-test

9.2 SecretA secret is a resource object for encrypted storage. You can save theauthentication information, certificates, and private keys in a secret, solving theconfiguration problems of sensitive data such as passwords, tokens, and keys. Inthis case, sensitive data will not be exposed to images or pod specification files.You only need to load such data as environment variables to containers duringcontainer startup.



Similar to a configMap, a secret saves data using key-value pairs. The difference isthat a secret is encrypted, and is suitable for storing sensitive information.

Base64 Encoding

Similar to a configMap, a secret saves data using key-value pairs. The difference isthat secret values must be encoded using the Base64 method.

To encrypt a character string using Base64 method, run the echo -n to-be-encoded content | base64 command. The following is an example:

root@ubuntu:~# echo -n "3306" | base64MzMwNg==

Creating a Secret

The secret defined in the following example contains two key-value pairs.

apiVersion: v1kind: Secretmetadata: name: mysecretdata: key1: VkZNME0wVlpVbEpQVHpGTFdrSkRWVWhCV2s5T1ZrNUxUVlZNUjBzMFRWcElVMFpVUkVWV1N3PT0= # Base64 encoded value key2: T0VkR1RGRlZVRlpVU2xCWFdUZFBVRUZCUmtzPQ== # Base64 encoded value

Referencing a Secret in Environment Variables

In most cases, a secret is injected into a container as an environment variable, asshown in the following example.

apiVersion: v1kind: Podmetadata: name: nginxspec: containers: - image: nginx:latest resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi env: - name: key valueFrom: secretKeyRef: name: mysecret key: key1 imagePullSecrets: - name: imagepull-secret

Referencing a Secret in a Volume

Referencing a secret in a volume is to fill each piece of data to the volume in theform of files. Each piece of data is a file. The key is the file name, and the keyvalue is the file content.



In the following example, create a volume named vol-secret, reference the secretnamed mysecret in the volume, and mount the volume to the /tmp directory ofthe container. After the pod is created, there are two files key1 and key2 inthe /tmp directory of the container, and the values areVkZNME0wVlpVbEpQVHpGTFdrSkRWVWhCV2s5T1ZrNUxUVlZNUjBzMFRWcElVMFpVUkVWV1N3PT0= andT0VkR1RGRlZVRlpVU2xCWFdUZFBVRUZCUmtzPQ==.

apiVersion: v1kind: Podmetadata: name: nginxspec: containers: - image: nginx:latest resources: limits: cpu: 500m memory: 1024Mi requests: cpu: 500m memory: 1024Mi volumeMounts: - name: vol-secret # Mount the volume named vol-secret mountPath: "/tmp" imagePullSecrets: - name: imagepull-secret volumes: - name: vol-secret secret: # Reference a secret secretName: mysecret



10 Creating a Workload Using Job andCron Job

A job workload is responsible for batch processing of short lived one-off tasks,that is, tasks that are executed only once. It ensures that one or more pods aresuccessfully completed.

● A job is a resource object that Kubernetes uses to control batch tasks. A job isdifferent from a long-term servo workload (such as Deployment andStatefulSet). The former is completed when a specified number of successfulcompletions is reached, while the latter runs unceasingly if not terminated.The pods managed by the job will be automatically removed after successfullycompleting the job based on user configurations.

● A cron job runs a job periodically on a specified schedule. A cron job object issimilar to a line of a crontab file in Linux.

This run-and-stop feature of the task workload is especially suitable for one-offtasks, such as CI. It works with the per-second billing of the CCI to implement pay-per-use in real sense.

Creating a JobThe following is an example job, which calculates π till the 2000th digit and printsthe output. 50 pods need to be run before the job is ended. In this example, printπ calculation results for 50 times, and run five pods concurrently. If a pod fails tobe run, a maximum of five retries are supported.apiVersion: batch/v1kind: Jobmetadata: name: pi-with-timeoutspec: completions: 50 # Number of pods that need to run successfully to end a job parallelism: 5 # Number of pods that run concurrently. The default value is 1. backoffLimit: 5 # Maximum number of retries performed if a pod fails. When the limit is reached, the pod will not try again. activeDeadlineSeconds: 10 # Timeout duration of pods. Once the time is reached, all pods of a job are terminated. template: # Pod definition spec: containers: - name: pi image: perl command:

Cloud Container InstanceDeveloper Guide 10 Creating a Workload Using Job and Cron Job


- perl - "-Mbignum=bpi" - "-wle" - print bpi(2000) restartPolicy: Never

Based on the completions and Parallelism settings, jobs can be classified asfollows:

Table 10-1 Job types

Job Type Description Example

One-off job One pod runs until it issuccessfully ends.

Database migration

Jobs with afixedcompletioncount

One pod runs until thespecified completion count isreached.

Pod for processing workqueues

Parallel jobswith a fixedcompletioncount

Multiple pods run until thespecified completion count isreached.

Multiple pods for processingwork queues concurrently

Parallel jobs One or more pods run untilone pod is successfully ended.

Multiple pods for processingwork queues concurrently

Creating a Cron Job

Compared with a job, a cron job is a scheduled job. A cron job runs a jobperiodically on a specified schedule, and the job creates a pod.

apiVersion: batch/v1beta1kind: CronJobmetadata: name: cronjob-examplespec: schedule: "0,15,30,45 * * * *" # Schedule configuration jobTemplate: # Job definition spec: template: spec: restartPolicy: OnFailure containers: - name: main image: pi

The format of the cron is as follows:

● Minute● Hour● Day of month● Month● Day of week



For example, in 0,15,30,45 * * * *, commas separate minutes, the first asterisk (*)indicates the hour, the second asterisk indicates the day of the month, the thirdasterisk indicates the month, and the fourth asterisk indicates the day of the week.

If you want to run the job every half an hour on the first day of each month, setthis parameter to 0,30 * 1 * *. If you want to run the job on 3:00 a.m. everySunday, set this parameter to 0 3 * * 0.

For details about the cron format, see https://en.wikipedia.org/wiki/Cron.



https://zh.wikipedia.org/wiki/Cron

A YAML Syntax

YAML is a simple and powerful language. It is designed to make the languageeasy to read.

Basic Syntax Rules● Characters are case-sensitive.● Indentation is used for denoting structure.● Only spaces can be used for indentation, but tab characters are not allowed.● The specific number of spaces in the indentation is unimportant as long as

parallel elements have the same left justification.● Comments begin with the number sign (#).

Data Types Supported by YAML● Object: A set of key-value pairs, which is also known as maps, hashes, or

dictionaries.● Array: A group of values arranged in sequence, which is also known as

sequence or list.● Scalar: A single and irreducible value, which is the minimum data unit.

ObjectAn object is a group of key-value pairs. For key: value, the colon (:) must befollowed by a space or newline character. The valid expression is as follows:

animal: petsplant: tree

You can also write multiple key-value pairs into an inline object.

hash: {name: Steve, foo: bar}

However, an error occurs in the following scenario:

foo: somebody said I should put a colon here: so I didwindows_drive: c:

To resolve the issue, you can enclose values in single quotation marks (' ') asfollows:

Cloud Container InstanceDeveloper Guide A YAML Syntax


foo: 'somebody said I should put a colon here: so I did'windows_drive: 'c:'

ArrayAn array is represented by a hyphen (-) and space. The valid expression is asfollows:

animal:- Cat- Dog- Goldfish

You can also use the inline representation.

animal: [Cat, Dog, Goldfish]

Objects and arrays can be used in combination to form a composite structure.

languages: - Ruby - Perl - Pythonwebsites: YAML: yaml.org Ruby: ruby-lang.org Python: python.org Perl: use.perl.org

ScalarScalars include strings, Boolean values, integers, floats, null, time, and dates.

● String:By default, a string is not enclosed in quotation marks.str:This_is_a_line

If a string contains spaces or special characters, the string needs to beenclosed in quotation marks.str:'content: a string'

Both single and double quotation marks can be used. The difference betweenthem is that the former can identify escape characters while the latter cannotconvert special characters.s1: 'content:\n a string's2: "content:\n a string"

If there is a single quotation mark between two single quotation marks,ensure that two consecutive single quotation marks are used to achieveconversion.str: 'labor''s day'

Strings can be written into multiple lines. The lines except the first line mustbe indented with one space. The newline character will be converted to aspace.str: This_is a_multi_line

● Integer:int_value: 314

● Float:float_value: 3.14



● Null:parent: ~

● TimeThe time is in the ISO8601 format.iso8601: 2018-12-14t21:59:43.10-05:00

● Date:The date is in the compound ISO8601 format: year-month-day.date: 1976-07-31

Special Symbols● Three hyphens (---) indicate the start of a YAML file. Three periods (...)

indicate the end of a YAML file.---# A list of delicious fruits- Apple- Orange- Strawberry- Mango...

● You can use two exclamation marks (!!) to forcibly convert an integer, a float,or a Boolean value.

strbool: !!str truestrint: !!str 10

● For a string occupying multiple lines, you can use a literal block scalar (|) topreserve newlines or folded block scalar (>) to fold newlines. The two symbolsare often used in the character strings in YAML files.

this: | Foo Barthat: > Foo Bar

The corresponding objects are as follows:

{ this: 'Foo\nBar\n', that: 'Foo Bar\n' }

It is recommended that "|" be used to meet the requirements of most scenarios.

Comment

YAML supports comments. This is an advantage of YAML compared with JSON.

Comments in YAML files begin with the number sign (#), as shown in thefollowing:

languages: - Ruby # Ruby programming language - Go # Go programming language - Python # Python programming language

Reference Documents● YAML 1.2 Specification● Ansible YAML Syntax



https://yaml.org/spec/1.2/spec.html

https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html