1, Pod

1.1 basic concepts

1.Pod is the smallest resource management component in kubernetes, and pod is also the resource object to minimize the running of container applications. A pod represents a process running in the cluster. Most other components in kubernetes support and extend pod functions around pod. For example, controller objects such as StatefulSet and Deployment used to manage pod operation, Service and progress objects used to expose pod applications, PersistentVolume storage resource objects that provide storage for pod, etc
2. Containers under a pod must run on the same node. Modern container technology suggests that a container only runs one process. The process number in the PID command space of the container is 1, which can directly receive and process signals. When the process terminates, the container life cycle will end. If you want to run multiple processes in the container, you need a management and control process similar to the init process of Linux operating system to complete the life cycle management of multiple processes in a tree structure. Processes running in their containers cannot directly complete Network communication. This is due to the isolation mechanism between containers. Pod resource abstraction in k8s is to solve this problem. Pod objects are a collection of containers that share Network, UTS and IPC command space. Therefore, they have the same domain name, host name and Network interface, and can communicate directly through IPC

1.2 usage of pod in k8s cluster

1. Run a container in a Pod. The pattern of "one container per Pod" is the most common usage; In this way, you can think of Pod as the encapsulation of a single container. kuberentes manages Pod instead of directly managing containers
2. Run multiple containers simultaneously in a pod. A pod can also encapsulate several containers that need to be closely coupled and cooperate with each other at the same time, and they share resources. These containers in the same pod can cooperate with each other to form a service unit. For example, one container shares files and another "sidecar" container updates these files. Pod manages the storage resources of these containers as an entity

1.3 classification of pod containers

1. Autonomous Pod:
This kind of pod itself cannot repair itself. When the pod is created (whether it is directly created by you or by other controllers), it will be dispatched by Kuberentes to the nodes of the cluster. The pod will remain on that Node until the process of the pod is terminated, deleted, expelled due to lack of resources, or the Node fails. Pod doesn't heal itself. If the Node running the pod fails or the scheduler itself fails, the pod will be deleted. Similarly, if the Node where the pod is located lacks resources or the pod is in maintenance status, the pod will also be expelled
2. Pod managed by controller:
Kubernetes uses a more advanced abstraction layer called Controller to manage Pod instances. The Controller can create and manage multiple pods, providing replica management, rolling upgrade and cluster level self-healing capabilities. For example, if a Node fails, the Controller can automatically schedule the Pod on the Node to other healthy nodes. Although the Pod can be used directly, the Controller is usually used to manage the Pod in kubernetes

1.4 three kinds of containers in pod

1.4.1 bottom foundation vessel pause

1. In Pod resources, the underlying basic container pause is used to provide sharing mechanisms such as network command space for each container. The basic container pause (also known as the parent container) is used to manage the sharing operation between Pod containers. The parent container needs to know exactly how to create containers with shared running environment and manage the life cycle of these containers. In order to realize the concept of this parent container, in kubernetes, the pause container is used as the parent container of all containers in a Pod
2.pause container has two core functions:
1) Enable the PID namespace and start the init process to manage the life cycle of other containers
2) Provide a shared foundation for network and storage space:
Network: each Pod is assigned a unique IP address. All containers in the Pod share cyberspace, including IP addresses and ports. Containers inside the Pod can communicate with each other using localhost. When the container in the Pod communicates with the outside world, it must allocate shared network resources (for example, use the port mapping of the host)
Storage space: multiple shared volumes can be specified by Pod. All containers in the Pod can access the shared volume. Volume can also be used to persist the storage resources in the Pod to prevent file loss after container restart

1.4.2 initialize containers

1) Concept

The Init container must run before the application container starts, and the application container runs in parallel, so the Init container can provide a simple method to block or delay the start of the application container. The Init container is very similar to an ordinary container, except for the following two points:
1.Init container always runs until successful completion
2. Each Init container must successfully start and exit before the next Init container starts
If the Init container of the Pod fails, k8s the Pod will be restarted continuously until the Init container succeeds. However, if the restart policy corresponding to the Pod is Never, it will not restart

2) Container function of Init

Because the init container has a separate image from the application container, its startup related code has the following advantages:
1. The init container can contain some utilities or personalized codes that do not exist in the application container during installation. For example, it is not necessary to generate a new image FROM an image just to use tools like sed, awk, python, or dig during installation
2. The init container can safely run these tools to avoid the reduction of the security of the application image caused by these tools
3. The creator and deployer of the application image can work independently, and there is no need to jointly build a separate application image
4. The Init container can run in a file system view different from the application container in the Pod. Therefore, the Init container can have access to Secrets, but the application container cannot
5. Because the Init container must run before the application container starts, the Init container provides a mechanism to block or delay the start of the application container until a set of prerequisites are met. Once the preconditions are met, all application containers in the Pod will start in parallel

1.4.3 main container

1.Parallel start
2.Official website example: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

1.4.4 instance creation

vim demo1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
===========================================================
kubectl apply -f demo1.yaml

kubectl get pods

kubectl describe pod myapp-pod

vim myservice.yaml
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 1111
	
kubectl create -f myservice.yaml

kubectl get svc

kubectl get pods -n kube-system

kubectl get pods

vim mydb.yaml
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 2222
	
kubectl create -f mydb.yaml

kubectl get pods

Special note:
●stay Pod During startup, Init The container starts sequentially after network and data volume initialization. Each container must exit successfully before the next container starts.
●If the container fails to start due to runtime or exit failure, it will Pod of restartPolicy Retry the specified policy. However, if Pod of restartPolicy Set to Always，Init Used when the container fails RestartPolicy Strategy.
●In all Init Before the container succeeds, Pod Will not become Ready Status. Init The port of the container will not be Service Aggregate in. Initializing in Pod be in Pending Status, but should Initializing Status set to true. 
●If Pod Restart, all Init The container must be re executed.
●yes Init container spec Modifications are limited to containers image Field. Modifying other fields will not take effect. change Init Container image Field, equivalent to restarting the Pod. 
●Init The container has all the fields that apply to the container. except readinessProbe，because Init Container cannot be defined different from completion( completion)Ready for( readiness)Other than. This is enforced during validation.
●stay Pod Each of the app and Init The name of the container must be unique; sharing the same name with any other container will throw an error during validation.

1.5 image PullPolicy

1.5.1 concept

The core of Pod is to run the container. You must specify a container engine, such as Docker. When starting the container, you need to pull the image. k8s's image pull strategy can be specified by the user:
1. IfNotPresent: when the image already exists, kubelet will no longer pull the image. It will only pull the image from the warehouse when the local image is missing. The default image pull policy is
2. Always: every time you create a Pod, you will pull the image again
3. Never: Pod will not actively pull this image, but only use the local image.
Note: for the image file with the label ": latest", the default image acquisition policy is "Always"; for the image of other labels, the default policy is "IfNotPresent"

1.5.2 create test cases

vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
spec:
  containers:
    - name: nginx
      image: nginx
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]


kubectl create -f pod1.yaml

kubectl get pods -o wide 

kubectl describe pod pod-test1

modify pod1.yaml file
vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
spec:
  containers:
    - name: nginx
      image: nginx:1.14							#Modify nginx image version
      imagePullPolicy: Always
===========================================================
kubectl delete -f pod1.yaml

kubectl create -f pod1.yaml

kubectl get pods -o wide 

kubectl describe pod pod-test1

1.6 restart strategy of pod

1.6.1 three strategies

Pod The action of restarting after a fault is encountered 
1.Always: When the container terminates and exits, the container is always restarted. The default policy is 2.OnFailure: When the container exits abnormally (the exit status code is not 0), restart the container; if it exits normally, do not restart the container 
3.Never: Never restart the container when the container terminates and exits 
Note: K8S Restart is not supported in Pod Resources, only delete and rebuild

1.6.2 instance creation

vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod2
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 5; exit 3
===========================================================
kubectl apply -f pod2.yaml

kubectl get pods

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod3
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 10; exit 3
  restartPolicy: Never    #Note: it is at the same level as the container
===========================================================
kubectl apply -f pod3.yaml

//The container enters the error state and will not be restarted
kubectl get pods -w

2, Deploy harbor to create a private project (credential token)

2.1 environmental preparation

#Turn off firewall and security features
systemctl stop firewalld.service
systemctl disable firewalld.service
setenforce 0

2.2 installing docker

yum install -y yum-utils device-mapper-persistent-data lvm2 
yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo 
yum install -y docker-ce
systemctl start docker.service
systemctl enable docker.service
docker version

2.3 uploading docker compose and harbor packages

cd /opt
 upload docker-compose and harbor-offline-installer-v1.2.2.tgz reach /opt In the directory
chmod +x docker-compose
mv docker-compose /usr/local/bin/

2.4 deploy Harbor service

tar zxvf harbor-offline-installer-v1.2.2.tgz -C /usr/local/
vim /usr/local/harbor/harbor.cfg
--5 that 's ok--Modify, set to Harbor Server IP Address or domain name
hostname = 192.168.80.14

cd /usr/local/harbor/
./install.sh   #install

2.5 create a new project in Harbor

1.Browser access: http://192.168.80.14 log in to the Harbor WEB UI interface. The default administrator user name and password are admin / harbor 12345
2.After entering the user name and password, you can create a new item. Click“+Project button
3.Fill in the item name as“ gxd-project"，Click OK to create a new project

2.6 configure and connect private warehouses at each node (note that the comma after each line should be added)

cat > /etc/docker/daemon.json <<EOF
{
  "registry-mirrors": ["https://6ijb8ubo.mirror.aliyuncs.com"],
  "insecure-registries":["192.168.80.14"]
}
EOF

systemctl daemon-reload
systemctl restart docker

2.7 log in to the harbor private warehouse at each node node

docker login -u admin -p Harbor12345 http://192.168.80.14

2.8 download nginx images on a node node for push

docker pull nginx:1.14
docker images

docker tag nginx:1.14 192.168.80.14/gxd-project/nginx:111
docker images

docker push 192.168.80.14/gxd-project/nginx:111

2.9 viewing login credentials

cat /root/.docker/config.json | base64 -w 0			#base64 -w 0: perform base64 encryption and disable word wrap
...
...

2.10 create a harbor login credential resource list in the master node

vim harbor-pull-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: harbor-pull-secret
data:
  .dockerconfigjson: ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjgwLjE0IjogewoJCQkiYXV0aCI6ICJZV1J0YVc0NlNHRnlZbTl5TVRJek5EVT0iCgkJfSwKCQkiaHViLmd4ZC5jb20iOiB7CgkJCSJhdXRoIjogIllXUnRhVzQ2U0dGeVltOXlNVEl6TkRVPSIKCQl9Cgl9Cn0=			#Copy and paste the login credentials viewed above
type: kubernetes.io/dockerconfigjson
===========================================================
establish secret resources
kubectl create -f harbor-pull-secret.yaml

//View secret resources
kubectl get secret

2.11 create resources and download images from harbor

vim nginx-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      imagePullSecrets:						#Add the option to pull secret resources
      - name: harbor-pull-secret			#Specify the secret resource name
      containers:
      - name: my-nginx
        image: 192.168.80.14/gxd-project/nginx:111		#Specifies the image name in the harbor
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-nginx
spec:
  type: NodePort
  ports:
  - port: 8888
    targetPort: 80
    nodePort: 31111
  selector:
    app: my-nginx

2.12 delete the previously downloaded nginx image on the node

docker rmi -f nginx:1.14
docker rmi -f 192.168.80.14/gxd-project/nginx:111
docker images

2.13 creating resources

kubectl create -f nginx-deployment.yaml
kubectl get pods

2.14 viewing Pod description information

//Downloaded from harbor when the image is found
kubectl describe pod my-nginx-69867795cc-7zklx

//Refresh the harbor page and you can see that the number of image downloads has increased

3, Summary

1.pod operation mode

1.Controller managed pod∶Self healing ability( Pod After being deleted, it will restart and pull up a new one pod)
2.Autonomous pod∶No self-healing ability

2. There are three kinds of containers in pod

1.Base container( pause)∶Initialize the container environment and turn it on pid=1 of init Process to manage the life cycle of other containers and provide the basis of shared environment of network and storage space
2.init container∶It is a container that runs after the basic container and before applying the container. There are multiple containers init The container runs serially, Init Container must be in the previous init The container will not run until it has successfully run and exited
3.Application container( main c)∶Container for running business, in Init Containers run successfully and after exiting. Multiple application containers run in parallel
 Note: in one pod In, init Both container and application container names are unique

3. Pop image pull policy imagePullPolicy (configure the layer below the containers field)

1.IfNotPresent∶This is the default pull policy for the image with the specified label. If there is a local image, the local image will be used. If there is no local image, the image will be pulled from the warehouse
2.Always∶ Is an image or use without a label latest Create the default pull policy for the image of the label Pod Always pull images from the warehouse
3.Never∶Images are not pulled from the warehouse, only local images are used

4.pod restart policy (the configuration is the same level as the containers field)

1.Always ∶The default restart policy. When the container exits, the container is always restarted
2.Never ∶The container exits and never restarts the container
3.OnFailure ∶Only when the container exits abnormally (non-0 status code exits), the container will be restarted