Namespace and Pod in Kubernetes

Posted by etingwall on Thu, 09 Jan 2020 20:15:22 +0100

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

Topics: vim Kubernetes network Docker