Kubernetes中pod详解

Kubernetes中pod详解

一、Namespace

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

Namespace常用来隔离不同的用户，比如Kubernetes自带的服务一般运行在kube-system namespace中。

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

2）Namespace常用的命令查询：

[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名称空间中的资源

创建、删除：

[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文件创建名称空间：

[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之间的通信可以使用网络策略资源这项功能；

二、Pod详解

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

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

**Pod 的context可以理解成多个linux命名空间的联合**： * PID 命名空间（同一个Pod中应用可以看到其它进程）； * 网络 命名空间（同一个Pod的中的应用对相同的IP地址和端口有权限）； * IPC 命名空间（同一个Pod中的应用可以通过VPC或者POSIX进行通信）； * UTS 命名空间（同一个Pod中的应用共享一个主机名称）；

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

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 192.168.45.129:5000/ //更改镜像的名称做一个简单的区别 [root@master ~]# docker tag 192.168.45.129:5000/httpd:v2 [root@master ~]# docker tag 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/ //指定选用的镜像 [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.

创建一个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 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 //此时可以看出指定的重启策略已经生效

三、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文件生成相应的资源，并且记录历史版本信息

[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

[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

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。