1. Namespace
1) Overview of Namespace
Namespace is an abstract collection of resources and objects that can be used, for example, to divide objects within a system into different project or user groups.Common pods, services, replication controllers, and deployments all belong to a namespace (default by default), whereas node, persistentVolumes, and so on do not belong to any namespace.
Namespaces are often used to isolate different users, such as Kubernetes'own services that typically run in the kube-system namespace.
Namespaces in Kubernetes are different from those in docker.Namespaces in K8s are just a logical isolation.
2) Common commands for Namespace
(1) Query
[root@master ~]# kubectl get namespaces //View Namespaces Existing in K8s NAME STATUS AGE default Active 6d21h kube-node-lease Active 6d21h kube-public Active 6d21h kube-system Active 6d21h //The namespace contains two states, Active and Terminating.During namespace deletion, the namespace state is set to "Terminating". [root@master ~]# kubectl describe namespaces default //View default namespace details [root@master ~]# kubectl get pod --namespace=default [root@master ~]# kubectl get pod -n default //View pod resources in default namespace (both) [root@master ~]# kubectl get pod //If not specified, the default is also to view resources in the default namespace
(2) Create or delete
Create using the command line
[root@master ~]# kubectl create namespace beijing //Create a namespace named beijing //Once created, you can see it through the "kubectl get namespaces" command [root@master ~]# kubectl delete namespace beijing //Delete newly created namespaces
Create with yaml file
[root@master ~]# vim namespace.yaml apiVersion: v1 kind: Namespace metadata: name: test [root@master ~]# kubectl apply -f namespace.yaml [root@master ~]# kubectl delete -f namespace.yaml
Be careful:
(1) Deleting a namespace automatically deletes all resources belonging to that namespace;
(2) default and kube-system namespaces cannot be deleted;
(3) namespace resource objects are used for isolation of resource objects and do not isolate communication between Pods in different namespaces.Network policy resources can be used if communication between Pods needs to be isolated.
Namespaces are so much introduced first that they will be updated if needed in the future!
II. Pod
1) What is a Pod?
In Kubernetes, the smallest management element is not a separate container, but a Pod, which is the smallest, managed, created, planned smallest unit.
A Pod is equivalent to a configuration group that shares contexts. Within the same context, applications may also have separate cgroup isolation mechanisms. A Pod is a "logical host" in a container environment. It may contain one or more closely connected applications, which may be on the same physical host or virtual machine.
Pod's context can be understood as the union of multiple linux namespaces:
- PID namespace (other processes can be seen in the same Pod application);
- Network namespace (applications in the same Pod have permission to the same IP address and port);
- IPC namespace (applications in the same Pod can communicate via VPC or POSIX);
- UTS namespace (an application in the same Pod shares a host name);
Like separate containers, a Pod is a relatively short-lived existence, not a permanent one. As we mentioned in the life cycle of a Pod, a Pod is placed on a node and remains on that node until it is terminated (according to the restart settings) or deleted. When a node dies, all the above Pods are deleted.Special Pods are never transferred to other nodes, and as a substitute they must be replace d.
2) Sharing and communication of Pod resources
Applications in Pod use the same network namespace and ports, and can discover and communicate other applications through localhost. Each Pod has a flat IP address under the network namespace, which enables Pod to communicate with other physical machines and other containers without barriers.
In addition to defining applications that run in Pod, Pod also defines a series of shared disks that keep this data from being lost when the container restarts and that can be shared in the Pod application.
3) Pod management
Pod simplifies the deployment and management of applications by providing a high-level abstraction rather than a low-level interface. Pod is the smallest deployment and management unit, location management, copy replication, resource sharing, and dependencies are handled automatically.
4) Why not run all the programs directly on one container?
(1) Transparent, the container in Pod is visible to the infrastructure so that the infrastructure can provide services to the container, such as thread management and resource monitoring, which facilitates the user
(2) decoupling, software dependency decoupling, independent containers can be independently rebuilt and republished, and Kubernetes will even support real-time updates of independent containers in the future;
(3) Easy to use, users do not need to run their own thread manager, and they do not need to care about program signals and abnormal end codes;
(4) Efficient, because infrastructure carries more responsibility, containers can be more efficient;
All in all, if you run multiple services and one of them has a problem, you need to restart the entire Pod, which is contrary to docker's original intention of containerization!
5) Create a Pod manually (without using a controller)
Mirror acquisition strategies when creating pod s:
- Always: (default) When the mirror label is latest or the mirror does not exist, the mirror is always taken from the specified repository;
- IfNotPresent: Download from the target repository only if the local image does not exist;
- Never: Do not download mirrors from the repository, that is, use only local mirrors;
Three states, you can specify when you create them!
[root@master ~]# kubectl create namespace test //Create a namespace named test (not required) [root@master ~]# vim pod.yaml kind: Pod apiVersion: v1 metadata: name: test-pod namespace: test //Specify the namespace in which it resides spec: containers: - name: test-app image: 192.168.1.1:5000/httpd:v1 [root@master ~]# kubectl apply -f pod.yaml //Generate required Pod from yaml file [root@master yaml]# kubectl get pod -n test //You need to specify a namespace to view (otherwise, look under the default namespace by default) NAME READY STATUS RESTARTS AGE test-pod 1/1 Running 0 11s
Note: When the label is latest or does not exist, the default download policy is Always, while for mirroring other labels, the default policy is IfNotPresent.
[root@master ~]# vim pod.yaml kind: Pod apiVersion: v1 metadata: name: test-pod namespace: test labels: name: test-web spec: containers: - name: test-app image: 192.168.1.1:5000/httpd:v1 imagePullPolicy: IfNotPresent //Specify policies for pod mirroring ports: - protocol: TCP containerPort: 80 //Just a statement, no effect [root@master ~]# kubectl delete -f pod.yaml //You need to delete the original or you cannot download it [root@master ~]# kubectl apply -f pod.yaml //Re-specify yaml file for download
Create a service to associate
[root@master ~]# vim pod-svc.yaml apiVersion: v1 kind: Service metadata: name: test-svc namespace: test spec: selector: name: test-web ports: - port: 80 targetPort: 80 //Note that this port is valid even if it is incorrect [root@master ~]# kubectl apply -f pod-svc.yaml [root@master ~]# kubectl get svc -n test NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE test-svc ClusterIP 10.108.187.128 <none> 80/TCP 35s [root@master ~]# curl 10.108.187.128 //access test lvzhenjiang
If it is not accessible,
[root@master ~]# kubectl describe svc -n test pod-svc //Look at the service details and find the Endpoints field
6) Restart policy, health check-up of pod
Pod's restart policy:
- Always: (used by default) But restart a Pod object whenever it terminates;
- OnFailure: Restart the Pod object only if it has an error;
- Never: Never restart;
Three states, you can specify when you create them!
Look at this in a small case:
[root@master ~]# vim cache.yaml apiVersion: v1 kind: Pod metadata: labels: test: healcheck name: healcheck spec: restartPolicy: OnFailure //Restart Policy containers: - name: healcheck image: busybox:latest args: //Commands to execute when starting a pod - /bin/sh - -c - sleep 10; exit 1 [root@master ~]# kubectl apply -f cache.yaml //Generate pod [root@master ~]# kubectl get pod -w | grep healcheck //Dynamic detection of pod status healcheck 0/1 CrashLoopBackOff 1 35s healcheck 1/1 Running 2 36s healcheck 0/1 Error 2 46s //You can see at this point that the specified restart policy is in effect
To this end of the article, thank you for reading ------------