kubernetes series of tutorials to learn the core concept of pod

Written in front

The previous series of articles have introduced the kubernetes architecture, installation, upgrade and quick start. Readers have had a preliminary understanding and understanding of kubernetes through the practical operation of the article. Starting from this chapter, the basic concepts and core concepts in kubernetes are gradually introduced, including: namespace, labels, annotations, pods, volumes, etc.; the core concepts include each in kubernetes controller, including the following:

  • Application replica controllers include: Deployments, ReplicaSets, DaemonSets, stateful sets;
  • Batch task controllers Jobs and CronJob
  • Storage controller persistentvolume, PersistentVolumeClaim, StorageClass;
  • Service load balancing service, Ingress, NetworkPolicy and DNS name resolution;
  • Configure and key ConfigMaps and Secrets

    This paper starts with the basic concept of pod, and then introduces the application deployment, storage, load balancing and other related controllers step by step. kubernetes is composed of several different controllers, each of which performs different functions.

1. In depth learning pod

1.1 introduction to container

Container is a kind of portable and lightweight container virtualization technology. It uses linux cggroup technology to realize the isolation of various resources, such as cpu, memory, pid, mount, IPC, etc. compared with virtualization technology such as KVM, container technology is more lightweight. Its generation mainly solves the problem of environment publishing. At present, the mainstream container technology is docker. When it comes to containers, it is always the same Same as docker.

To run a container, you first need to have a mirror image. The application and application dependent environment run in the container. Instead of running the container directly in kubernetes, you need to run the pod. A pod contains multiple containers. The containers share the same namespace, network, storage, etc. The image is stored in a private image or a public image. When running, it is pulled locally by docker image pull. There are two pull strategies for images:

  • ImagePullPolicy is Always, whether there is a direct download locally or not
  • ImagePullPolicy is IfNotPresent. The default image pull policy is not available locally

1.2 introduction to pod concept

Pods is the smallest scheduling unit in kubernetes. One or more containers run in pods. They share the network ip resources of pod, store volume resources, and compute resources among containers, which facilitates the quick access and interaction between containers in pod.

As shown in the figure above, Pod is usually used in two ways:

  • Pod runs a container, the most frequently used mode, container is packaged in pod, and the two are almost identical, but k8s does not directly manage containers.
  • Multiple containers run in pod, and multiple containers are scheduled together in pod. It is suitable for scenarios where there is data interaction and call between containers, such as app+redis, where pod shares the same network namespace, storage namespace, process namespace, etc.

1.3 how to create a pod

In kubernetes, resources are defined by defining the production statement, that is, by defining the required resources in the yaml file, kubernetes generates the required resources (match the current state to desired state) through the controller manager according to the resources defined in the yaml file. In general, resources are defined in kubernetes in the way of yaml file, and then configuration is applied in the way of kubectl create -f file. Yaml, as shown below, the operation of creating a nginx application is demonstrated.

1. Write yaml file to define a pod resource

[root@node-1 demo]# cat nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
  labels:
    name: nginx-demo
spec:
  containers:
  - name: nginx-demo
    image: nginx:1.7.9
    imagePullPolicy: IfNotPresent
    ports:
    - name: nginx-port-80
      protocol: TCP
      containerPort: 80

The configuration file is described as follows:

  • The version used by apiversion API. Kubectl API versions can be used to check the list of versions supported by the current system
  • kind specifies the resource type, expressed as the resource type of Pod
  • Metadata specifies the metadata of the Pod, metadata.name specifies the name, and metadata.labels specifies the label of the Pod
  • Spec specifies the template attribute of Pod, spec.containers configuration container information, spec.containers.name specifies the name, spec.containers.image specifies the name of container image, spec.containers.imagePullPolicy is the download method of image, IfNotPresent indicates download when image does not exist, spec.containers.ports.name specifies the name of port, spec.containers.ports.protocol The protocol type is TCP, spec.containers.ports.containerPort is the container port.

2. Create pod app

[root@node-1 demo]# kubectl apply -f nginx.yaml 
pod/nginx-demo created

3. Access apps

Get container's IP address
[root@node-1 demo]# kubectl get pods -o wide 
NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
demo-7b86696648-8bq7h   1/1     Running   0          8h    10.244.1.11   node-2   <none>           <none>
demo-7b86696648-8qp46   1/1     Running   0          8h    10.244.1.10   node-2   <none>           <none>
demo-7b86696648-d6hfw   1/1     Running   0          8h    10.244.1.12   node-2   <none>           <none>
nginx-demo              1/1     Running   0          50s   10.244.2.11   node-3   <none>           <none>

//Visit site content:
[root@node-1 demo]# curl http://10.244.2.11
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Previously, we learned that kubernetes supports rolling upgrade RollingUpdate, elastic capacity expansion replicas and other features. How can we do rolling upgrade for pod to ensure uninterrupted business and improve the number of copies of pod to ensure high availability? The answer is: No. Pod is single and cannot support some advanced features. Advanced features need to be supported by advanced replica controllers such as ReplicaSets, Deployments, stateful sets, DaemonSets, etc. Pod is rarely used in practical applications. In addition to testing and running some simple functions, it is recommended to use Deployments instead. The definition of pod is embedded in the replica controller in the form of Template.

2. How to write yaml file

We mentioned earlier that kubernetse is a declarative way to deploy applications. The deployment of applications is defined in yaml files. How to write yaml files of applications? Let me share the skills used in two centuries:

1. By defining the template for rapid generation, kubectl create Apps - o yaml -- dry run is generated, and - dry run is just a trial run, not actually running in the k8s cluster. By specifying - o yaml, output yaml format file, and modify the template based on the generated file, as follows:

[root@node-1 demo]# kubectl create deployment demo --image=nginx:latest  --dry-run -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: demo
  name: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: demo
    spec:
      containers:
      - image: nginx:latest
        name: nginx
        resources: {}
status: {}

2. The explain command, which can be called a syntax querier, can find the meaning of each field, use description and use mode. For example, if you want to view other fields supported by containers in the spec of Pod, you can query it by kubectl explain Pod.spec.containers, as follows:

[root@node-1 demo]# kubectl explain Pods.spec.containers
KIND:     Pod
VERSION:  v1

RESOURCE: containers <[]Object>

DESCRIPTION:
     List of containers belonging to the pod. Containers cannot currently be
     added or removed. There must be at least one container in a Pod. Cannot be
     updated.

     A single application container that you want to run within a pod.

FIELDS:
   args <[]string> #Command parameter
     Arguments to the entrypoint. The docker image's CMD is used if this is not
     provided. Variable references $(VAR_NAME) are expanded using the
     container's environment. If a variable cannot be resolved, the reference in
     the input string will be unchanged. The $(VAR_NAME) syntax can be escaped
     with a double $$, ie: $$(VAR_NAME). Escaped references will never be
     expanded, regardless of whether the variable exists or not. Cannot be
     updated. More info:
     https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell

   image    <string> #Mirror definition
     Docker image name. More info:
     https://kubernetes.io/docs/concepts/containers/images This field is
     optional to allow higher level config management to default or override
     container images in workload controllers like Deployments and StatefulSets.

   ports    <[]Object> #Port definition
     List of ports to expose from the container. Exposing a port here gives the
     system additional information about the network connections a container
     uses, but is primarily informational. Not specifying a port here DOES NOT
     prevent that port from being exposed. Any port which is listening on the
     default "0.0.0.0" address inside a container will be accessible from the
     network. Cannot be updated.

   readinessProbe   <Object> #Available health checks
     Periodic probe of container service readiness. Container will be removed
     from service endpoints if the probe fails. Cannot be updated. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

   resources    <Object> #Resource settings
     Compute Resources required by this container. Cannot be updated. More info:
     https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

...Omit partial output...
   volumeMounts <[]Object> #Mounted storage
     Pod volumes to mount into the container's filesystem. Cannot be updated.

   workingDir   <string>
     Container's working directory. If not specified, the container runtime's
     default will be used, which might be configured in the container image.
     Cannot be updated.

Explanation of explain

  • < string > means to follow a string
  • < [] Object > indicates the object followed by a list. The list needs to start with - and can write multiple objects
  • <Object> represents an object with multiple attributes inside

If you want to continue the above content and view the resource definition, you can use explain pods.spec.containers.resource to view the specific usage.

Through the introduction of the above two tools, we usually find the map for writing yaml files to deploy applications in our daily work. It is recommended to write more manually, pay attention to syntax locking, and be familiar with it after writing more. There are many features designed in pod, such as resource allocation, health check, storage mount, etc. (refer to the appendix article). We will make a detailed introduction later. Pod will be embedded in replica controller such as Deployments in the form of Template.

4. appendix

Introduction to container image: https://kubernetes.io/docs/concepts/containers/images/

Pod introduction: https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/

Resource limited memory resource: https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/

Resource limited CPU resources: https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/

Pod mount storage: https://kubernetes.io/docs/tasks/configure-pod-container/configure-volume-storage/

Pod configuration health check: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

When your talent can't support your ambition, you should study quietly

Return kubernetes tutorial catalog

Tags: Linux Kubernetes Nginx Docker network

Posted on Sat, 18 Jan 2020 07:47:38 -0500 by Valect