First, let's take a look at the needs this solution addresses. For instance, several issues must be taken care of before using a container image to start a container.
The following figure shows pod configuration management in Kubernetes.
This section introduces the functions and benefits of ConfigMap. ConfigMap manages some variable configurations, such as some configuration files, its internal environment variables, or some command-line parameters.
It decouples some variable configurations from container images, ensuring the portability of containers. The orchestration file is shown on the right of the following figure.
ConfigMap contains two parts. First, metadata, focusing on the name and namespace. The other is data, where two configuration files are managed. As the name suggests, ConfigMap is actually a "map" in the
key: value format, where a "key" indicates a file name while its "value" indicates the file content.
We recommend running the kubectl command to create ConfigMap. The command contains the NAME and DATA parameters, where DATA may specify a file, directory, or key-value pair. The following figure shows an example.
When DATA specifies a file, "key" in "Map" indicates the file name while "value" in "Map" indicates the file content. When DATA specifies a key-value pair, the value is in the
key:value format and directly mapped to
key:value in "Map."
As shown in the preceding figure, ConfigMap is used in a pod.
configMapKeyRefindicates the name of ConfigMap while "key" indicates the key in
ConfigMap.data.In this case, after starting the BusyBox container, run the
envcommand to view the
SPECIAL_LEVEL_KEY.Obtain it from the first line of the environment variables and run the cmd command to use it.
/etc/configdirectory in the container.
Pay attention to the following points while using ConfigMap:
1) Although there is no size limit for the ConfigMap file, the size of data written to etcd is limited to 1 MB.
2) Only ConfigMap in the same namespace is used in a pod. As shown in the preceding figure,
ConfigMap.metadata contains the namespace field.
3) When a pod references ConfigMap, if the ConfigMap does not exist, the pod creation fails because the referenced ConfigMap needs to be created before the pod.
4) When some keys in the ConfigMap are invalid, such as keys whose names contain digits while using "envFrom" mode to import all information in the ConfigMap into an environment variable, the environment variable is ignored and not injected into the container. However, the pod can still be created. The difference between this situation and the previous one is that the ConfigMap file is imported into an environment variable.
5) Only pods created using Kubernetes APIs may use ConfigMap. For example, the pods created using a kubectl command can use ConfigMap, while pods created in other ways, such as the static pods created by kubelet through manifest, cannot use ConfigMap.
A secret is a resource object used to store some sensitive information, such as passwords and tokens. The sensitive information is stored in Base64 encoding. The following figure defines Secret data.
The metadata contains the name and namespace fields. The type field is a key field, specifying a type of Secret data. There are four types of Secret data:
The data field stores Secret data in key-value format.
As shown in the preceding figure, Secret data can be created in two ways.
ConfigMap: type. The data field specifies the file and key-value pair. If the type field is not set, the default value is Opaque.
As shown in the preceding figure, it's easy to specify the
"/root/.docker/config.json" file to create Secret data to pull images from a private warehouse. In this case, the type field is set to
dockerconfigjson. Alternatively, specify a key-value pair to create Secret data, where the default value Opaque is retained for the type field. The key-value pair is in the
key:value format, in which "value" is encrypted in Base64. That is how Secret data is created.
Secret data is mounted to a specified directory in a container as volumes in a pod. Then, the business process in the container reads the Secret data from the directory. In addition, Secret data is referenced to access the private image warehouse.
Secret data is mounted to a specified directory as follows:
"/etc/foo"directory in the container.
serviceaccount-secretand mounts it to the
"/var/run/secrets/kubernetes.io/serviceaccount"directory in the container. Two certificate files containing authentication information are generated,
Let's understand how to use a private image warehouse through Secret. Information about the private image warehouse is stored in Secret. To pull images from the private warehouse, configure Secret in one of the following two ways.
Pay attention to the following points while using Secret:
1) The Secret file size is limited to 1 MB.
2) Secret data is encoded in Base64, which isn't different from plaintext. Therefore, it's recommended to not store confidential information in Secret. In other words, restrict the access to the cluster because those who access the cluster can acquire the Secret data. In case of high requirements on sensitive information in Secret and need for strong encryption, we recommend using Kubernetes and open-source vault to develop a solution for sensitive information encryption and permission management.
3) We do not recommend using a list-watch to read Secret data. Otherwise, all Secret data is pulled from the namespace, exposing more information. Instead, we recommend using the GET method to get the required Secret data.
ServiceAccount authenticates the identity of a pod in a cluster. The identity authentication information is stored in Secret.
As shown on the left of the preceding figure, the "secrets" field in the red box specifies the Secret used for ServiceAccount, which is automatically added for ServiceAccount in Kubernetes. As shown on the right of the preceding figure, the "data" field contains two parts:
ca.crt and "token."
ca.crt verifies the server while "token" authenticates the pod identity. Both are encoded in Base64. Metadata is associated with a ServiceAccount that uses the Secret. The "type" field indicates the type of service-account-token.
This section describes how a pod uses ServiceAccount or Secret to access its Kubernetes cluster.
When a pod is created, the Secret is mounted to a specified directory in a container. This is implemented by a Kubernetes function. The
ca.crt and "token" files need to be mounted to the specified directory.
The following figure shows how the pod uses the files to access its cluster.
When a pod accesses its Kubernetes cluster, InClusterConfig is called to generate some information about the service access client. The InClusterConfig contains the following information:
After authentication, the pod identity information contains Group and User, which are authenticated during identity authentication. Then, use the Role-Based Access Control (RBAC) function to authorize the pod.
If the RBAC function is not configured, the pod has permission to get data from its Kubernetes cluster by default. To grant additional permissions, configure the RBAC function. More information about RBAC will be provided in subsequent courses.
This section describes how to manage resource configurations for a container.
Currently, three types of resources are supported, CPU, memory, and ephemeral storage. When the three types are insufficient, users may define their own resources, such a GPU or other resources. However, the specified resource quantity must be a positive integer. The current resource configuration types include requests and limits, which respectively specify the required resource quantities and resource limits. The CPU, memory, and ephemeral storage are declared in the "resources" field of the container.
For example, the resource requirements of the WordPress container are requests and limits, which respectively declare the required resources and resource limit.
Based on the CPU's demands for container memory resources, divide the quality of service (QoS) of pods into Guaranteed, Burstable, and BestEffort.
How does the QoS work?
After resources are configured, when a container in a pod runs on the node but the node's memory resources are insufficient, kubelet evicts pods with lower priority or lower QoS requirements (such as BestEffort and Burstable). BestEffort pods are evicted before Burstable pods.
SecurityContext restricts the behavior of containers and ensures system and container security. This capability is not inherent in Kubernetes or the container runtime environment. Instead, SecurityContext is configured by users, loaded to the kernel, and then enabled through the kernel mechanism. The following briefly describes the content.
SecurityContext is classified into three levels:
There are seven permission and access control items (the quantity is subject to change):
1) The user ID and group ID are used to control the file access permission.
2) SELinux is used to control the users or processes that access a file based on policy configurations.
3) Privileged containers are controlled.
4) Capabilities used to configure a privileged capability for a specific process.
5) AppArmor is used to control the access permission for executable files based on configuration files, for example, the permission to read and write to certain ports.
6) System calls are controlled.
7) Whether a sub-process can obtain more permissions than its parent process is controlled.
In fact, all the permissions are controlled by the kernel.
The preceding figure shows an example of configuring SecurityContext at the pod and container levels. Use this example to find more in-depth information.
The differences between Init Containers and common containers are as follows:
1) Common containers do not start until all Init Containers start.
2) Init Containers start one by one in a defined order, while common containers start concurrently.
3) After successful execution, Init Containers exit while common containers continue to run. Common containers run for a long time and restart upon failure.
Let's understand how Init Containers are used.
Init Containers serve common container services. For example, Init Containers perform initialization or prepare some configuration files for common containers before they start. The configuration files may be variable. In addition, Init Containers verify prerequisites, such as whether the system is connected to the network.
The preceding figure shows the Init Container configuration of Flannel, where Init Container prepares some network configuration files for kube-flannel before it starts.
The following pointers summarize the overall course:
Alibaba Clouder - July 16, 2019
Alibaba Developer - June 30, 2020
Alibaba Clouder - August 3, 2020
Alibaba Clouder - July 27, 2020
Alibaba Developer - June 30, 2020
JeffLv - December 2, 2019
A configuration audit service that provides configuration history of enterprise resources in Alibaba Cloud and audits the compliance of resource configurations.Learn More
Accelerate and secure the development, deployment, and management of containerized applications cost-effectively.Learn More
Alibaba Cloud Container Service for Kubernetes is a fully managed cloud container management service that supports native Kubernetes and integrates with other Alibaba Cloud products.Learn More
Centralizes the management of application configurations and performs real time configuration push in a distributed environment.Learn More
More Posts by Alibaba Developer