Basic Concepts

Image

A container image is a special file system that provides the programs, libraries, resources, and configuration files required for running a container. A Docker image also contains configuration parameters, for example, anonymous volumes, environment variables, and users. An image does not contain any dynamic data, and its content will not be changed after creation.

Container

The relationship between a Docker image and a container is similar to that between a class and an instance in object-oriented programming. Images are static, and containers are entities of running images. A container can be created, started, stopped, deleted, and suspended.

Namespace

A namespace provides a method of allocating resources among multiple users. When you have a large number of projects and personnel, you can define namespaces by project attributes, such as production, test, and development.

Pod

A pod is the smallest and simplest unit in the Kubernetes object model that you create or deploy. A pod encapsulates one or more containers, storage resources, a unique network IP address, and options that govern how the containers should run.

Figure 1 Pod

Pods can be used in either of the following ways:

• One container runs in one pod. This is the most common usage of pods in Kubernetes. You can view the pod as a single encapsulated container, but Kubernetes directly manages pods instead of containers.
• Multiple containers that need to be coupled and share resources run in a pod.

In Kubernetes, pods are rarely created directly. Instead, controllers such as Deployments are used to create and manage pods. Controllers create and manage multiple pods, and provide replica management, rolling upgrade, and self-healing capabilities. A controller typically uses a pod template to create corresponding pods.

For details, see Pods.

Init Container

Before containers that run applications are started, one or some init containers are started first. If there are multiple init containers, they will be started in the defined sequence. The application containers are started only after all init containers run to completion and exit. Storage volumes in a pod are shared. Therefore, the data generated in the init containers can be used by the application containers.

Init containers can be used in multiple Kubernetes resources, such as Deployments and jobs. They perform initialization before application containers are started.

For details, see Init Containers.

Label

A label is a key-value pair attached to an object and is used to transfer user-defined attributes.

Labels are often used to select objects that meet conditions from a group of objects. Labels are currently the most important node grouping method in Kubernetes.

For example, you may create labels (tier=frontend and app=myapp) to mark frontend pods and labels (tier=backend and app=myapp) to mark backend pods. You can then use selectors to select pods with specific labels and apply services or Deployments to these pods.

For details, see Labels.

Figure 2 Pods organized with labels

Deployment

Deployment is a type of pod controller.

A Deployment can contain one or more pods. Each pod has the same role, and the system automatically distributes requests to the pods of a Deployment. All pods for deploying a Deployment share storage volumes.

When using a Deployment, you only need to describe your desired pod status. The Deployment will help you change the current pod status to the target status.

For details, see Deployments.

Job

A job is a resource object that Kubernetes uses to control batch tasks. A job is different from a long-term servo workload (such as Deployment). The former is completed when a specified number of successful completions is reached, while the latter runs unceasingly if not terminated. The pods managed by a job automatically exit after successfully completing the job based on user configurations.

This run-to-completion feature of jobs is especially suitable for one-off tasks, such as continuous integration (CI). It works with the per-second billing of CCI to implement pay-per-use in real sense.

For details, see Jobs.

Cron Job

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

For details, see CronJob.

Service

Kubernetes pods are mortal. They can be created and destroyed. Once destroyed, they cannot be resurrected. Pod controllers create and destroy pods dynamically (for example, when scaling out or in or during rolling upgrades). Each pod obtains its own IP address, but the IP address is not always stable or dependable. This leads to a problem: if some set of pods (backends) provides services to other pods (frontends) inside a Kubernetes cluster, how do those frontends find out and connect to the corresponding backends?

A Kubernetes service (sometimes referred to as a microservice) defines a logical set of pods and a policy to access them. The set of pods targeted by a service is usually determined by a label selector.

Consider an image processing backend that is running with three pod replicas as an example. These replicas are interchangeable (frontends does not need to know which backend they call). The pods that form the backend set may change, and the frontends do not need to be aware of that or keep track of the list of backends themselves. A Kubernetes service enables this decoupling.

For details, see Service.

Ingress

Services and pods can be accessed only through an internal IP address. An external request needs to be forwarded by a load balancer to the NodePort exposed by the service on a node and then be forwarded by kube-proxy to corresponding pods.

An ingress is a set of rules that allow access from outside a cluster to services within the cluster. You can configure externally-accessible URLs, load balancers, SSL, and name-based virtual hosts for an ingress.

For details, see Ingress.

PVC

A PersistentVolumeClaim (PVC) is a request for storage by a user. Similar to a pod which requests CPU and memory, a PVC requests storage resources. On CCI, you can apply for storage resources such as EVS disks and SFS file systems using PVCs.

For details, see Persistent Volumes.

ConfigMap

A ConfigMap is used to store configuration data as key-value pairs or configuration files. ConfigMaps are similar to secrets, but provide a means of working with strings that do not contain sensitive information.

For details, see ConfigMaps.

Secret

A secret is a Kubernetes object for storing sensitive data such as passwords, tokens, certificates, and private keys. A secret can be loaded to a container as environment variables when the container is started.

For details, see Secrets.