Calling APIs to Create Workloads
CCI supports Kubernetes APIs. Compared with using the console to create workloads, calling APIs is much easier.
In Kubernetes, a pod is the minimum unit for container running and can encapsulate one or more containers, storage resources, and an independent network IP address. In practice, pods are rarely created directly. Kubernetes uses controllers such as Deployment and StatefulSet to manage pods. In addition, Kubernetes uses Services to define pods and their access policies, and uses ingresses to manage external access. For more information about Kubernetes resources, see Cloud Container Instance Developer Guide.
For the WordPress application, you can call APIs to create a series of resources, as shown in the following figure.
- MySQL: Create a Deployment to deploy the MySQL, and create a Service to define the access policy of the MySQL.
- WordPress: Create a Deployment to deploy the WordPress, and create a Service and an ingress to define the access policy of the WordPress.
Namespace
- Call the API described in Creating a Namespace to create a namespace and specify a namespace type.
{ "apiVersion": "v1", "kind": "Namespace", "metadata": { "name": "namespace-test", "annotations": { "namespace.kubernetes.io/flavor": "gpu-accelerated" } }, "spec": { "finalizers": [ "kubernetes" ] } }
- Call the API described in Creating a Network to create a network, and associate the network with a Virtual Private Cloud (VPC) and subnet.
{ "apiVersion": "networking.cci.io/v1beta1", "kind": "Network", "metadata": { "annotations": { "network.alpha.kubernetes.io/default-security-group": "{{security-group-id}}", "network.alpha.kubernetes.io/domain-id": "{{domain-id}}", "network.alpha.kubernetes.io/project-id": "{{project-id}}" }, "name": "test-network" }, "spec": { "availableZone": "{{zone}}", "cidr": "192.168.0.0/24", "attachedVPC": "{{vpc-id}}", "networkID": "{{network-id}}", "networkType": "underlay_neutron", "subnetID": "{{subnet-id}}" } }
MySQL
- Call the API described in Creating a Deployment to deploy the MySQL.
- Set the Deployment name to mysql.
- Set the pod label to app:mysql.
- Use the mysql:5.7 image.
- Set the value of environment variable MYSQL_ROOT_PASSWORD to ******** (replace ******** with your password).
{ "apiVersion": "apps/v1", "kind": "Deployment", "metadata": { "name": "mysql" }, "spec": { "replicas": 1, "selector": { "matchLabels": { "app": "mysql" } }, "template": { "metadata": { "labels": { "app": "mysql" } }, "spec": { "containers": [ { "image": "mysql:5.7", "name": "container-0", "resources": { "limits": { "cpu": "500m", "memory": "1024Mi" }, "requests": { "cpu": "500m", "memory": "1024Mi" } }, "env": [ { "name": "MYSQL_ROOT_PASSWORD", "value": "********" } ] } ], "imagePullSecrets": [ { "name": "imagepull-secret" } ] } } } }
- Call the API described in Creating a Service to create a Service, and define the access policy for the pod created in 1.
- Set the Service name to mysql.
- Select the pod whose label is app:mysql to associate the pod created in 1.
- Map workload access port 3306 to container port 3306.
- The access type of the Service is ClusterIP, that is, ClusterIP is used to access the Service inside the cluster.
{ "apiVersion": "v1", "kind": "Service", "metadata": { "name": "mysql", "labels": { "app": "mysql" } }, "spec": { "selector": { "app": "mysql" }, "ports": [ { "name": "service0", "targetPort": 3306, "port": 3306, "protocol": "TCP" } ], "type": "ClusterIP" } }
WordPress
- Call the API described in Creating a Deployment to deploy the WordPress.
- Set the Deployment name to wordpress.
- Set the value of replicas to 2, indicating that two pods are created.
- Set the pod label to app:wordpress.
- Use the wordpress:latest image.
- Set the value of environment variable WORDPRESS_DB_PASSWORD to ******** (replace ******** with your password). This password must be the same as MYSQL_ROOT_PASSWORD set for the MySQL.
{ "apiVersion": "apps/v1", "kind": "Deployment", "metadata": { "name": "wordpress" }, "spec": { "replicas": 2, "selector": { "matchLabels": { "app": "wordpress" } }, "template": { "metadata": { "labels": { "app": "wordpress" } }, "spec": { "containers": [ { "image": "wordpress:latest", "name": "container-0", "resources": { "limits": { "cpu": "500m", "memory": "1024Mi" }, "requests": { "cpu": "500m", "memory": "1024Mi" } }, "env": [ { "name": "WORDPRESS_DB_PASSWORD", "value": "********" } ] } ], "imagePullSecrets": [ { "name": "imagepull-secret" } ] } } } }
- Call the API described in Creating a Service to create a Service, and define the access policy for the pod created in 1.
- Set the Service name to wordpress.
- Select the pod whose label is app:wordpress to associate the pod created in 1.
- Map workload access port 8080 to container port 80. For the WordPress image, port 80 is the default externally exposed port.
- The access type of the Service is ClusterIP, that is, ClusterIP is used to access the Service inside the cluster.
{ "apiVersion": "v1", "kind": "Service", "metadata": { "name": "wordpress", "labels": { "app": "wordpress" } }, "spec": { "selector": { "app": "wordpress" }, "ports": [ { "name": "service0", "targetPort": 80, "port": 8080, "protocol": "TCP" } ], "type": "ClusterIP" } }
- Call the API described in Creating an Ingress to create an ingress to define the external access policy of the WordPress. In this step, you need to configure a load balancer that is in the same VPC as the WordPress.
- metadata.annotations.kubernetes.io/elb.id: ID of the load balancer
- metadata.annotations.kubernetes.io/elb.ip: IP address of the load balancer
- metadata.annotations.kubernetes.io/elb.port: Port configured for the load balancer
- spec.rules: a set of rules for accessing the Service. path lists the paths for accessing the Service, for example, "/". Each path is associated with a backend (for example, wordpress:8080). A backend represents a combination of service:port. Ingress traffic will be forwarded to the corresponding backend.
After the configuration is complete, the traffic destined for the load balancer (Load balancer IP address:Port) is transmitted to the wordpress:8080 Service. Because the Service is associated with the WordPress pod, the traffic finally accesses the WordPress container deployed in 1.
{ "apiVersion": "extensions/v1beta1", "kind": "Ingress", "metadata": { "name": "wordpress", "labels": { "app": "wordpress", "isExternal": "true", "zone": "data" }, "annotations": { "kubernetes.io/elb.id": "2d48d034-6046-48db-8bb2-53c67e8148b5", "kubernetes.io/elb.ip": "10.10.10.10", "kubernetes.io/elb.port": "9012" } }, "spec": { "rules": [ { "http": { "paths": [ { "path": "/", "backend": { "serviceName": "wordpress", "servicePort": 8080 } } ] } } ] } }
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot