Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Get to Know Kubernetes | Application Configuration Management

Get to Know Kubernetes | Application Configuration Management

In this 'Get to Know Kubernetes' tutorial, we will cover everything you need to know about pod configuration management in Kubernetes.

1) Need

Background

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.

  • Variable Configurations: It's not possible to write variable configurations to images. Therefore, when a configuration changes, there is a need to re-compile the image, which is unacceptable.
  • Storage and Usage of Sensitive Information: For example, applications may need some passwords or tokens.
  • Access to the Cluster by a Container: For example, the need for identity authentication in case the container needs to access kube-apiserver.
  • Resource Requirements of a Container After it Runs on a Node.
  • Security Control for Containers that Share the Kernel on a Node.
  • Prerequisite Check Before Container Startup: For example, the need to check whether the DNS service or network is available before starting a container.

Pod Configuration Management

The following figure shows pod configuration management in Kubernetes.

  • ConfigMap: The Variable Configuration
  • Secret: The Sensitive Information
  • ServiceAccount: The Identity Authentication
  • Resources: The Resource Configuration
  • SecurityContext: The Security Control
  • Init Container: The Prerequisite Verification

1

2) ConfigMap

ConfigMap Introduction

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.

2

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.

ConfigMap Creation

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.

3

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."

ConfigMap Usage

4

As shown in the preceding figure, ConfigMap is used in a pod.

  • Use ConfigMap to configure environment variables. "name" under configMapKeyRef indicates the name of ConfigMap while "key" indicates the key in ConfigMap.data. In this case, after starting the BusyBox container, run the env command to view the SPECIAL_LEVEL_KEY environment variable.
  • Use ConfigMap to configure command-line parameters. The command-line parameter is SPECIAL_LEVEL_KEY. Obtain it from the first line of the environment variables and run the cmd command to use it.
  • Mount its volume to a directory in a container. In the preceding example, the content of the ConfigMap named special-config is mounted to the /etc/config directory in the container.

Notes

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.

3) Secret

Secret Introduction

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.

5

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:

  • Opaque: a common Secret file
  • Service-account-token: authenticates the service account identity
  • dockerconfigjson: pulls images from a private warehouse
  • bootstrap.token verifies node access to clusters

The data field stores Secret data in key-value format.

Secret Creation

6

As shown in the preceding figure, Secret data can be created in two ways.

  • Created by a System: For example, Kubernetes creates Secret data for the default user (default ServiceAccount) of each namespace.
  • Created by Users: We recommend running the kubectl Alibaba Cloud CLI to create Secret data. The command for creating Secret data contains one more parameter than the command for creating 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 Usage

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.

7

Secret data is mounted to a specified directory as follows:

  • As shown on the left of the preceding figure, mount "mysecret" to the "/etc/foo" directory in the container.
  • As shown on the right of the preceding figure, the system automatically generates serviceaccount-secret and mounts it to the "/var/run/secrets/kubernetes.io/serviceaccount" directory in the container. Two certificate files containing authentication information are generated, ca.crt and "token."

Using a Private Image Warehouse

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.

  • Configure Secret by setting the imagePullSecrets field in a pod, as shown on the left of the following figure.
  • The other way is to automatically inject Secret. Configure imagePullSecrets in ServiceAccount to be used in a pod. Then, the system automatically injects the value of imagePullSecrets.

8

Notes

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.

4) ServiceAccount

ServiceAccount Introduction

ServiceAccount authenticates the identity of a pod in a cluster. The identity authentication information is stored in Secret.

9

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.

Example - Applications in a Pod Access a Kubernetes Cluster of the Pod

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.

10

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:

  • tlsClientConfig, which verifies the server based on ca.crt.
  • Bearer Token, which authenticates the pod identity. On the server, the "token" field is used for pod identity authentication.

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.

5) Resources

Container Resource Management

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.

11

For example, the resource requirements of the WordPress container are requests and limits, which respectively declare the required resources and resource limit.

Pod QoS Configuration

Based on the CPU's demands for container memory resources, divide the quality of service (QoS) of pods into Guaranteed, Burstable, and BestEffort.

  • Guaranteed: Each container in a pod must have a declaration for the requests and limits of the memory and CPU, and the requests and limits must be the same.
  • Burstable: At least one container has a request for CPU and memory.
  • BestEffort: All QoSs other than Guaranteed and Burstable.

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.

6) SecurityContext

SecurityContext Introduction

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:

  • Container level, which is valid only for containers
  • Pod level, which is valid for all containers in a pod
  • Cluster level, which is PSP and is valid for all pods in a cluster

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.

12

The preceding figure shows an example of configuring SecurityContext at the pod and container levels. Use this example to find more in-depth information.

7) Init Container

Init Container Introduction

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.

13

The preceding figure shows the Init Container configuration of Flannel, where Init Container prepares some network configuration files for kube-flannel before it starts.

Summary

The following pointers summarize the overall course:

  • The ConfigMap and Secret sections introduced the creation methods and application scenarios of ConfigMap and Secret, listed common notes, and described the usage and configuration of private warehouse images.
  • The pod identity authentication section described the associations between ServiceAccount and Secret, analyzed the pod identity authentication process and implementation details by looking at the source code, and introduced pod permission management (RBAC configuration management).
  • The container resources and security sections introduced the configurations of common resource types (CPU and memory) for containers, described pod QoS types in detail, and briefly described the valid levels and permission configuration items of SecurityContext.
  • The Init Container section introduced the differences between Init Containers and common containers and used examples to describe the usage of Init Containers.
Container Resource Management Kubernetes Configuration Management Application Configurations ConfigMap Pod Configuration
1 0 0
Share on

Read previous post:

Getting Started with Kubernetes | Application Orchestration and Management: Jobs and DaemonSet

Read next post:

Get to Know Kubernetes | Application Storage and Persistent Volumes: Core Knowledge

Alibaba Cloud Native Community

480 posts | 48 followers

You may also like

Comments

5782390329712288 June 11, 2020 at 6:38 pm

Good

Alibaba Cloud Native Community

480 posts | 48 followers

Related Products

More Posts by Alibaba Cloud Native Community

See All