Kubernetes中pod详解

时间 2020-08-20

标签 kubernetes pod 详解繁體版

原文原文链接

1、Namespace

1）Namespace概述
Namespace是对一组资源和对象的抽象集合，好比能够用来将系统内部的对象划分为不一样的项目组或用户组。常见的pods, services, replication controllers和deployments等都是属于某一个namespace的（默认是default），而node, persistentVolumes等则不属于任何namespace。node

Namespace经常使用来隔离不一样的用户，好比Kubernetes自带的服务通常运行在kube-system namespace中。linux

Kubernetes中的名称空间与docker中的名称空间不一样。K8s中的名称空间只是作了一个逻辑上的隔离web

2）Namespace经常使用的命令
查询：docker

[root@master ~]# kubectl  get  namespaces   //查看k8s存在的名称空间
NAME              STATUS   AGE
default           Active   5d4h
kube-node-lease   Active   5d4h
kube-public       Active   5d4h
kube-system       Active   5d4h
[root@master ~]# kubectl  describe namespaces default   //查看名称空间详细信息
[root@master ~]# kubectl get pod --namespace=default 
[root@master ~]# kubectl get pod -n default 
//查看default名称空间中的pod资源（二者均可以）
[root@master ~]# kubectl get pod
//若是不指定，则默认也是查看default名称空间中的资源

建立、删除：vim

[root@master ~]# kubectl create namespace beijing
//建立一个名称空间，名称为beijing
//建立完成后，能够经过“kubectl get namespaces”命令查看到
[root@master ~]# kubectl  get namespaces     //查看刚建立的一个名称空间，名称为beijing
NAME              STATUS   AGE
beijing           Active   6s
default           Active   5d4h
kube-node-lease   Active   5d4h
kube-public       Active   5d4h
kube-system       Active   5d4h

[root@master ~]# kubectl delete namespace beijing
//删除新建立的名称空间

经过使用yaml文件建立名称空间：api

[root@master ~]# vim namespace.yaml 
apiVersion: v1
kind: Namespace
metadata:
  name: test
[root@master ~]# kubectl apply -f namespace.yaml  //生成一个名称空间
[root@master ~]# kubectl get   namespaces     //查看刚建立的一个名称空间，名称为test
NAME              STATUS   AGE
default           Active   5d4h
kube-node-lease   Active   5d4h
kube-public       Active   5d4h
kube-system       Active   5d4h
test              Active   9s

[root@master ~]# kubectl delete -f namespace.yaml   //删除名称空间

注意：
（1）删除一个名称空间时会自动删除全部属于该namespace的资源；
（2）default和kube-system名称空间不能够被删除；
（3）namespace资源对象仅用于资源对象的隔离，并不能隔毫不同名称空间的Pod之间的通讯。若是须要隔离Pod之间的通讯可使用网络策略资源这项功能；网络

2、Pod详解

1）什么是Pod？
在Kubernetes中，最小的管理元素不是一个个独立的容器，而是Pod,Pod是管理，建立，计划的最小单元.app

一个Pod就至关于一个共享context的配置组，在同一个context下，应用可能还会有独立的cgroup隔离机制，一个Pod是一个容器环境下的“逻辑主机”，它可能包含一个或者多个紧密相连的应用，这些应用多是在同一个物理主机或虚拟机上。curl

**Pod 的context能够理解成多个linux命名空间的联合**：

* PID 命名空间（同一个Pod中应用能够看到其它进程）；
* 网络 命名空间（同一个Pod的中的应用对相同的IP地址和端口有权限）；
* IPC 命名空间（同一个Pod中的应用能够经过VPC或者POSIX进行通讯）；
* UTS 命名空间（同一个Pod中的应用共享一个主机名称）；

Pod和相互独立的容器同样，Pod是一种相对短暂的存在，而不是持久存在的，正如咱们在Pod的生命周期中提到的，Pod被安排到节点上，而且保持在这个节点上直到被终止（根据重启的设定）或者被删除，当一个节点死掉以后，节点上运行的全部Pod均会被删除。ide

2）Pod资源的共享及通讯
Pod中的应用均使用相同的网络命称空间及端口，而且能够经过localhost发现并沟通其余应用，每一个Pod都有一个扁平化的网络命称空间下IP地址，它是Pod能够和其余的物理机及其余的容器进行无障碍通讯的关键。

除了定义了在Pod中运行的应用以外，Pod还定义了一系列的共享磁盘，磁盘让这些数据在容器重启的时候不会丢失而且能够将这些数据在Pod中的应用进行共享。

3）Pod的管理
Pod经过提供一个高层次抽象而不是底层的接口简化了应用的部署及管理，Pod 做为最小的部署及管理单位，位置管理，拷贝复制，资源共享，依赖关系都是自动处理的。

4）为何不直接在一个容器上运行全部的程序？

1）透明：Pod中的容器对基础设施可见，使得基础设施能够给容器提供服务，例如线程管理和资源监控，这为用户提供不少便利；
2）解耦：解除软件依赖关系,独立的容器能够独立的进行重建和从新发布，Kubernetes 甚至会在未来支持独立容器的实时更新；
3）易用：用户不须要运行本身的线程管理器，也不须要关心程序的信号以及异常结束码等；
4）高效：由于基础设施承载了更多的责任，因此容器能够更加高效；

总之就是一句话：若是说运行多个服务，其中一个服务出现问题，那么就需重启整个Pod，与docker这种容器化的初衷是违背的！

注：实验操做以前先简单搭建个registry私有仓库

[root@master ~]#  docker pull registry:2
[root@master ~]# docker run -itd --name registry --restart=always  -p 5000:5000 -v /registry:/var/lib/registry registry:2
[root@master ~]# docker pull httpd
[root@master ~]# docker tag  httpd 192.168.45.129:5000/httpd:v1   //更改镜像的名称作一个简单的区别
[root@master ~]# docker tag  httpd 192.168.45.129:5000/httpd:v2
[root@master ~]# docker tag  httpd 192.168.45.129:5000/httpd:v3
[root@master ~]# vim /usr/lib/systemd/system/docker.service
ExecStart=/usr/bin/dockerd    --insecure-registry 192.168.45.129:5000  
[root@master ~]# systemctl  daemon-reload 
[root@master ~]# systemctl  restart  docker.service  
[root@master ~]# docker push 192.168.45.129:5000/httpd:v1
[root@master ~]# docker push 192.168.45.129:5000/httpd:v2
[root@master ~]# docker push 192.168.45.129:5000/httpd:v3

5）手动建立Pod（不使用控制器）

**建立pod时镜像获取策略：**
* Always： 镜像标签为"latest"或镜像标签不存在时，老是从指定的仓库中获取镜像。
* IfNotPresent：仅当本地镜像不存在时才从目标仓库中下载。也就意味着，若是本地存在，直接使用本地镜像，无需再联网下载。
* Never: 禁止从仓库中下载镜像，即只使用本地镜像。

三种状态，在建立时能够任意指定！

[root@master ~]# kubectl create namespace test
//建立一个名为test的名称空间（不是必须的）

[root@master ~]# vim pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
  namespace: test             //指定其所在的名称空间
spec:
  containers:
  - name: test-app
    image: 192.168.45.129:5000/httpd:v1  //指定选用的镜像

[root@master ~]# kubectl apply -f pod.yaml  //根据yaml文件生成所需的Pod
[root@master ~]# kubectl  get  pod -n test
NAME       READY   STATUS    RESTARTS   AGE
test-pod   1/1     Running   0          13s
//须要指定名称空间进行查看（不然默认状况下在default名称空间下查找）

注意：对于标签为latest或者不存在时，其默认的下载策略为Always，而对于其余标签的镜像，默认策略为IfNotPresent。

//将上述Pod资源的镜像下载策略改成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.45.129:5000/httpd:v1
    imagePullPolicy: IfNotPresent           //指定pod镜像的策略
    ports:
    - protocol: TCP
      containerPort: 80     //只是一个声明，没有任何做用

[root@master ~]# kubectl delete -f pod.yaml          
//须要将本来的删除不然没法进行下载          
[root@master ~]# kubectl apply -f pod.yaml 
//从新指定yaml文件进行下载

建立一个service进行关联

[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                 //注意这个端口时生效的，即便是错误的
[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           //访问测试
bjq

若是访问不到，

[root@master ~]# kubectl describe svc -n test 
//查看service的详细信息，找到Endpoints字段便可发现

6）pod的重启策略

**Pod的重启策略：**
* Always： 但凡Pod对象终止就将其重启，此为默认设定。
* OnFailure: 仅在Pod对象出现错误时才将其重启。
* Never: 从不重启。

三种状态，在建立时能够任意指定！

经过一个小案例进行查看：

[root@master ~]# vim cache.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: healcheck
  name:  healcheck
spec:
  restartPolicy: OnFailure                //重启策略
  containers:
  - name:  healcheck
    image: busybox:latest
    args:                           //启动pod时执行的命令
    - /bin/sh
    - -c
    - sleep 10; exit 1

[root@master ~]# kubectl apply -f cache.yaml 
//生成pod
[root@master ~]# kubectl  get  pod -w
NAME        READY   STATUS    RESTARTS   AGE
healcheck   1/1     Running   1          18s
healcheck   0/1     Error     1          26s
healcheck   0/1     CrashLoopBackOff   1          40s
healcheck   1/1     Running            2          42s
healcheck   0/1     Error              2          52s
healcheck   0/1     CrashLoopBackOff   2          65s
healcheck   1/1     Running            3          79s
healcheck   0/1     Error              3          89s
//此时能够看出指定的重启策略已经生效

3、Pod的健康检查

1）容器探针
为了确保容器在部署后确实处于正常运行状态，Kubernetes提供了两种探针来探测容器的状态：

* LivenessProbe： 存活探针，指容器是否正在运行。若是检测失败，则kubelet会杀死容器，而且容器会受重启策略的影响决定是否须要重启；
* ReadnessProbe: 就绪探针，指容器是否准备就绪，接受服务请求。若是就绪探针失败，端点控制器将从与Pod匹配的全部service的端点中移除该Pod的IP 地址；

2）LivenessProbe探针配置

[root@master yaml]# cat liveness.yaml 
kind: Pod
apiVersion: v1
metadata:
  name: liveness
  labels:
    test: liveness
spec:
  restartPolicy: OnFailure
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/test; sleep 60; rm -rf /tmp/test; sleep 300
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/test
      initialDelaySeconds: 10
      periodSeconds: 5

[root@master yaml]# kubectl  apply  -f liveness.yaml  
pod/liveness created
[root@master yaml]# kubectl  get  pod -w
NAME       READY   STATUS              RESTARTS   AGE
liveness   0/1     ContainerCreating   0          1s
liveness   1/1     Running             0          17s
liveness   1/1     Running             1          2m18s
//上述yaml文件中针对/tmp/test这个文件进行指定了健康检查策略为 livenessProbe，而且指定了重启策略为OnFailure。这样容器能够正常的运行，可是老是会重启。

注： Liveness活跃度探测，根据探测某个文件是否存在，来确认某个服务是否正常运行，若是存在则正常，不然，它会根据你设置的Pod的重启策略操做Pod。

3）ReadinessProbe探针配置
配置几乎是如出一辙的，只是健康检测的方式更换一下，以下：

[root@master yaml]# cat readiness.yaml 
kind: Pod
apiVersion: v1
metadata: 
  name: readiness
  labels:
    test: readiness
spec:
  restartPolicy: OnFailure
  containers:
  - name: readiness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/test; sleep 60; rm -rf /tmp/test; sleep 300
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/test
      initialDelaySeconds: 10
      periodSeconds: 5

[root@master yaml]# kubectl  apply  -f readiness.yaml 
[root@master yaml]# kubectl  get  pod -w
NAME        READY   STATUS              RESTARTS   AGE
readiness   0/1     ContainerCreating   0          4s
readiness   0/1     Running             0          17s
readiness   1/1     Running             0          26s
readiness   0/1     Running             0          91s

注：总结liveness和 readiness两种探测的区别：

1）liveness和readiness是两种健康检查机制，若是不特地配置，k8s将两种探测采起相同的默认
行为，即经过判断容器启动进程的返回值是否为零，来判断探测是否成功。

2）两种探测配置方法彻底同样，不一样之处在于探测失败后的行为：liveness探测是根据Pod重启策
略操做容器，大多数是重启容器。readiness则是将容器设置为不可用，不接收Service转发的请求。

3）两种探测方法能够独立存在，也能够同时使用。用liveness判断容器是否须要重启实现自愈；
用readiness判断容器是否已经准备好对外提供服务

5）健康检测的应用
如下主要应用是在scale（扩容、缩容）、更新（升级）过程当中使用。
一）、

[root@master yaml]# cat app.v1.yaml 
//版本1的yaml文件建立10个副本使用busybox镜像，以下
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 10; touch /tmp/healthy; sleep 3000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

//编写完成后退出便可

[root@master yaml]# kubectl apply -f app.v1.yaml --record 
//使用yaml文件生成相应的资源，而且记录历史版本信息

查看pod信息，如图：

二）、

[root@master yaml]# cat app.v2.yaml 
//版本2的yaml文件建立10个副本使用busybox镜像
//并模拟（代码中有问题，并进行升级），以下：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  strategy:
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 2
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

//maxSurge：此参数控制滚动更新过程当中，副本总数超过预期数的值，能够是整数，也能够是百分比。默认是1
//maxUnavailable：不可用Pod的值，默认为1，能够是整数，也能够是百分比

[root@master yaml]# kubectl apply -f app.v2.yamll --record

查看pod信息，如图：

注：从图中能够看出，一共有12个pod，而且有四个pod是不可用的！由于健康检查机制在检查到有问题时，就不会更新了剩余的pod了！
三）、

[root@master yaml]# cat app.v3.yaml 
//版本2的yaml文件建立10个副本使用busybox镜像
//而且不使用健康检查机制，以下：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000

[root@master yaml]# kubectl apply -f app.v3.yamll --record

再次查看pod的状态信息，如图：

若是不使用健康检查机制，就能够看出及时pod中服务存在问题，也会所有更新！

[root@master yaml]# kubectl rollout history deployment app 
//查看记录的历史版本
[root@master yaml]# kubectl rollout undo deployment app --to-revision=1
//回滚到可用的版本

再次查看pod的运行状态，如图：

由此能够看出pod健康检查的重要性！