请人做网站域名和主机,thinkphp网站开发实战教程,php投票网站,企业信用信息公示系统查询官网在面试的时候#xff0c;面试官常常会问一些问题#xff1a;
k8s是什么#xff1f;有什么用?k8s由哪些组件组成#xff1f;pod的启动流程#xff1f;k8s里有哪些控制器#xff1f;k8s的调度器里有哪些调度算法#xff1f;pod和pod之间的通信过程#xff1f;外面用户访…
在面试的时候面试官常常会问一些问题
k8s是什么有什么用?k8s由哪些组件组成pod的启动流程k8s里有哪些控制器k8s的调度器里有哪些调度算法pod和pod之间的通信过程外面用户访问pod数据流程你常用哪些命令容器的类型3种探针pod的升级HPA、VPA、CA污点和容忍有状态的应用和无状态的应用ingress相关RBAC相关CI/CD 持续集成、持续交付 jenkinspod有多少种状态pod的重启策略
下面就让我来详细说明一些这些问题
1. k8s是什么有什么用?
k8s就是一个编排容器的工具一个可以管理应用全生命周期的工具从创建应用应用的部署应用提供服务扩容缩容应用应用更新都非常的方便而且可以做到故障自愈。
例如一个服务器挂了K8s可以自动将这个服务器上的服务调度到另外一个主机上进行运行无需进行人工干涉。
所以 k8s 一般都是和 Docker 搭配起来使用的。 2. k8s由哪些组件组成 k8s的master里有哪些组件 1.etcd 存放数据 2.scheduler 调度器 --》例如容器pod到底在那个node服务器上启动 3.api-server 接口 master和node之间通信和交换数据 4.controller 控制器 deployment 部署控制器replicaSET 副本控制器等
k8s的node节点上有哪些组件 1.kubulet 帮助启动容器的 2.kubu-proxy 负责网络通信和负载均衡
master上
API Server
API 服务器是 Kubernetes 控制平面的组件 该组件负责公开了 Kubernetes API负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。
etcd
数据库, 一致且高可用的键值存储用作 Kubernetes 所有集群数据的后台数据库。
kube-scheduler
调度器, 负责监视新创建的、未指定运行节点node的 Pods 并选择节点来让 Pod 在上面运行。
kube-controller-manager
控制器管理器负责运行控制器进程
cloud-controller-manager
嵌入了特定于云平台的控制逻辑与公有云进行对接的控制器
node上
kubelet
它保证容器containers都运行在 Pod 中。
单独的程序在宿主机里运行
[rootk8smaster kubernetes]# ps aux|grep kubelet
root 1020 6.7 2.2 1951916 87964 ? Ssl 09:58 7:01 /usr/bin/kubelet
kube-proxy
是集群中每个节点node上所运行的网络代理
kube-proxy 维护节点上的一些网络规则 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了可用的数据包过滤层则 kube-proxy 会通过它来实现网络规则。 否则kube-proxy 仅做流量转发。
单独的程序在宿主机里运行
[rootk8smaster kubernetes]# ps aux|grep kube-proxy
root 3548 0.2 0.8 744320 32848 ? Ssl 09:59 0:13 /usr/local/bin/kube-proxy --config/var/lib/kube-proxy/config.conf --hostname-overridek8smaster
root 100881 0.0 0.0 112828 992 pts/0 S 11:42 0:00 grep --colorauto kube-proxy
3. pod的启动流程 4. k8s里有哪些控制器
deployment-部署控制器
一旦运行了 Kubernetes 集群就可以在其上部署容器化应用程序。 为此您需要创建 Kubernetes Deployment 配置。Deployment 指挥 Kubernetes 如何创建和更新应用程序的实例。创建 Deployment 后Kubernetes master 将应用程序实例调度到集群中的各个节点上。
创建 Deployment 时您需要指定应用程序的容器映像以及要运行的副本数。
deployment控制器会去node节点上去创建pod根据你指定的镜像名字在pod里创建需要的容器
删除deployment就自动删除启动的pod
ReplicaSet-副本的控制器
光从ReplicaSet这个控制器的名字副本集也能想到它是用来控制副本数量的这里的每一个副本就是一个Pod。ReplicaSet它是用来确保我们有指定数量的Pod副本正在运行的Kubernetes控制器意在保证系统当前正在运行的Pod数等于期望状态里指定的Pod数目。
一般来说Kubernetes建议使用Deployment控制器而不是直接使用ReplicaSetDeployment是一个管理ReplicaSet并提供Pod声明式更新、应用的版本管理以及许多其他功能的更高级的控制器。所以Deployment控制器不直接管理Pod对象而是由 Deployment 管理ReplicaSet再由ReplicaSet负责管理Pod对象。 daemonSet-守护进程控制器
当我们启动pod的时候每个node节点上只启动一个pod
举例 假如我们有6个node需要在每个node上一个安装一个监控使用的pod 就可以使用Daemon Sets--》特别适合日志采集和数据收集的pod
DaemonSet 确保全部或者某些节点上运行一个 Pod 的副本
job-批处理控制器
Job控制器用于Pod对象运行一次性任务容器中的进程在正常运行结束后不会对其进行重启而是将Pod对象置于Completed(完成)状态若容器中的进程因错误而终止则需要按照重启策略配置确定是否重启未运行完成的Pod对象因其所在的节点故障而意外终止后会被调度。
cronjob-计划任务控制器
CronJob 用于执行周期性的动作例如备份、报告生成等。 这些任务中的每一个都应该配置为周期性重复的例如每天/每周/每月一次 你可以定义任务开始执行的时间间隔。
计划任务相关 5. k8s的调度器里有哪些调度算法 1.deployment: 全自动调度根据node的算力cpu内存带宽已经运行的pod等--》到底是如何给node评分的最底层的机制 2.node selector定向调度 3.nodeaffinity --》尽量把不同的pod放到一台node上 4.podaffinity --》尽量把相同的pod放到一起 5.taints和tolerations 污点和容忍
taints和toleration是怎么样查看的如何知道哪些机器上有污点哪些pod可以容忍
[rootscmaster ~]# kubectl describe node scmaster|grep -i taint
Taints: node-role.kubernetes.io/master:NoSchedule
[rootscmaster ~]#
[rootscmaster ~]# kubectl describe pod etcd-scmaster -n kube-system |grep -i tolerations
Tolerations: :NoExecute opExists
[rootscmaster ~]# 6. pod和pod之间的通信过程
同一个Pod中的容器通信
同一个pod中的容器是共享网络ip地址和端口号的通信显然没问题
集群内Pod之间的通信
Pod会有独立的IP地址这个IP地址是被Pod中所有的Container共享的那多个Pod之间的通信能通过这个IP地址吗我们可以将此类pod间的通信分为两个维度
集群中同一台机器中的Pod pause 容器启动之前会为容器创建虚拟一对 ethernet 接口一个保留在宿主机 vethxxx插在网桥上一个保留在容器网络命名空间内并重命名为eth0。两个虚拟接口的两端从一端进入另一端出来。任何 Pod 连接到该网桥的 Pod 都可以收发数据。 集群中不同机器之间的通信是通过网络插件实现的
Kubernetes跨主机容器之间的通信组件目前主流的是flannel和calico
其中跨整个集群的 Pod ip 是唯一的当报文从一个节点转发到另外一个节点时报文首先通过 veth然后通过网桥转发到物理适配器网卡最后转发到其它节点的虚拟网桥进而到达 veth 目标容器。
flannel和calico参考https://www.cnblogs.com/xiaoyuxixi/p/13304602.html 7. 外面用户访问pod数据流程 8. 常用命令
kubectl get 资源对象kubectl describe 查询详细信息kubectl logs 查看日志kubectl exec -it 容器名 -- bash 进入容器kubectl apply -f *.yml 执行yml文件kubectl delete -f *.yml 删除前面执行的yml文件创建的内容 9. 容器的类型有哪些?
init初始化容器
初始化init容器像常规应用容器一样只有一点不同初始化init容器必须在应用容器启动前运行完成。 Init 容器的运行顺序一个初始化init容器必须在下一个初始化init容器开始前运行完成。
为一个pod里后面启动的容器准备一些条件
容器启动有先后顺序同时一个pod里的容器也是可以有依赖的
与普通容器不同之处Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe 因为它们必须在 Pod 就绪之前运行完成 pause容器
Pause容器 全称infrastucture container又叫infra基础容器作为init pod存在其他pod都会从pause 容器中fork出来
1、每个Pod里运行着一个特殊的被称之为Pause的容器其他容器则为业务容器这些业务容器共享Pause容器的网络栈和Volume挂载卷2、因此他们之间通信和数据交换更为高效在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。3、同一个Pod里的容器之间仅需通过localhost就能互相通信。
在创建一个pod的时候最先创建的容器
pause容器--》把pod的公用的命名空间都创建好--》init容器---》app容器 sidecar容器
Sidecar模式是一种将应用功能从应用本身剥离出来作为单独进程的方式。该模式允许我们向应用无侵入添加多种功能避免了为满足第三方组件需求而向应用添加额外的配置代码。
就像边车加装在摩托车上一样在软件架构中sidecar附加到主应用或者叫父应用上以扩展/增强功能特性同时Sidecar与主应用是松耦合的。
当另一个容器被添加到一个pod中为主容器提供额外的功能但不需要改变主容器它被称为一个sidecar容器
一个或多个共享同一个pod的容器至少要共享两样东西
一个文件系统-这意味着你可以使用共享卷在同一个pod中的两个或多个容器之间共享文件。共享卷是简单的共享文件夹。网络-同一Pod中的容器之间的通信可以通过回环接口 - localhost进行。 Sidecar模式的好处
通过将公用基础设施相关功能抽象到不同的层来降低微服务的代码复杂性由于我们不需要在每个微服务中编写配置代码因此减少了微服务架构中的代码重复P应用和底层平台之间实现了松耦合
工作模式 app容器
应用程序容器 跑业务代码的容器 10. 3种探针
探针使用探针去试探pod是否能正常提供服务在pod启动的不同阶段使用不同的方法去监控判断pod是否正常 案例
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: k8s.gcr.io/busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5当探针发现pod没有运行的时候kubelet会根据pod的重启策略重启pod 11. pod的升级
参考https://zhuanlan.zhihu.com/p/342229988
使用Deployment来控制Pod的主要好处之一是能够执行滚动更新。滚动更新允许你逐步更新Pod的配置并且Deployment提供了许多选项来控制滚动更新的过程。
控制滚动更新最重要的选项是更新策略。在Deployment的YAML定义文件中由spec.strategy.type字段指定Pod的滚动更新策略它有两个可选值
RollingUpdate (默认值)逐步创建新的Pod同时逐步终止旧Pod用新Pod替换旧Pod。Recreate在创建新Pod前所有旧Pod必须全部终止。
大多数情况下RollingUpdate是Deployment的首选更新策略。如果你的Pod需要作为单例运行并且不允许在任何时间存在多副本这种时候Recreate更新策略会很有用。
使用RollingUpdate策略时还有两个选项可以让你微调更新过程
maxSurge在更新期间允许创建超过期望状态定义的Pod数的最大值。maxUnavailable在更新期间容忍不可访问的Pod数的最大值
maxSurge和maxUnavailable选项都可以使用整数比如2或者百分比比如50%进行配置而且这两项不能同时为零。当指定为整数时表示允许超期创建或者不可访问的Pod数。当指定为百分比时将使用期望状态里定义的Pod数作为基数。比如如果对maxSurge和maxUnavailable都使用默认值25并且将更新应用于具有8个容器的Deployment那么意味着maxSurge为2个容器maxUnavailable也将为2个容器。这意味着在更新过程中将满足以下条件
最多有10个Pod8个期望状态里指定的Pod和2个maxSurge允许超期创建的Pod在更新过程中处于Ready状态。最少有6个Pod8个期望状态里指定的Pod和2个maxUnavailable允许不可访问的Pod将始终处于Ready状态。
值得注意的一点是在考虑Deployment应在更新期间运行的Pod数量时使用的是在Deployment的更新版本中指定的副本数而不是现有Deployment版本的期望状态中指定的副本数。
可以用另外一种方式理解这两个选项maxSurge是一次将创建的新Pod的最大数量maxUnavailable是一次将被删除的旧Pod的最大数量。
让我们具体看一下使用以下更新策略将具有3个副本的Deployment从v1更新为 v2的过程
replicas: 3
strategy:type: RollingUpdaterollingUpdate:maxSurge: 1maxUnavailable: 0
这个更新策略是我们想一次新建一个Pod并且应该始终保持Deployment中的Pod有三个是Ready状态。下面的动图说明了滚动更新的每一步都发生了什么。如果Deployment看到Pod已经完全部署好了将会把Pod标记为Ready创建中的Pod标记为NotReady正在被删除的Pod标记为Terminating。 12. HPA、VPA、CA
参考https://blog.csdn.net/weixin_41989934/article/details/118645084
HPA 水平Pod自动扩缩器
HAP全称 Horizontal Pod Autoscaler 可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 数量。 除了 CPU 利用率也可以基于其他应程序提供的自定义度量指标来执行自动扩缩。 Pod 自动扩缩不适用于无法扩缩的对象比如 DaemonSet。 Pod 水平自动扩缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。 控制器会周期性的调整副本控制器或 Deployment 中的副本数量以使得 Pod 的平均 CPU 利用率与用户所设定的目标值匹配。
HPA 定期检查内存和 CPU 等指标自动调整 Deployment 中的副本数比如流量变化 HPA工作原理 k8s里的HPA功能比传统的集群有什么优势
1.启动速度 2.扩展性--》自动扩缩 3.资源的消耗方面--》节省服务器
速度 价格--》成本 稳定性 可靠性 metrics server
HPA的指标数据是通过metrics服务来获得必须要提前安装好
Metrics Server 是 Kubernetes 内置自动缩放管道的可扩展、高效的容器资源指标来源。
Metrics Server 从 Kubelets 收集资源指标并通过Metrics API在 Kubernetes apiserver 中公开它们 以供Horizontal Pod Autoscaler和Vertical Pod Autoscaler 使用比如CPU、文件描述符、内存、请求延时等指标metric-server收集数据给k8s集群内使用如kubectl,hpa,scheduler等。还可以通过 访问指标 API kubectl top从而更轻松地调试自动缩放管道
安装参考https://www.cnblogs.com/scajy/p/15577926.html
示例
首先我们部署一个nginx,副本数为2请求cpu资源为200m。同时为了便宜测试使用NodePort暴露服务命名空间设置为:hpa
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginxname: nginxnamespace: hpa
spec:replicas: 2selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- image: nginxname: nginxresources:requests:cpu: 200m ##memory: 100Mi
---
apiVersion: v1
kind: Service
metadata:name: nginxnamespace: hpa
spec:type: NodePortports:- port: 80targetPort: 80selector:app: nginx查看部署结果
# kubectl get po -n hpaNAME READY STATUS RESTARTS AGEnginx-5c87768612-48b4v 1/1 Running 0 8m38snginx-5c87768612-kfpkq 1/1 Running 0 8m38s创建HPA
这里创建一个HPA用于控制我们上一步骤中创建的 Deployment使 Pod 的副本数量维持在 1 到 10 之间。HPA 将通过增加或者减少 Pod 副本的数量通过 Deployment以保持所有 Pod 的平均 CPU 利用率在 50% 以内。
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:name: nginxnamespace: hpa
spec:scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: nginxminReplicas: 1maxReplicas: 10metrics:- type: Resourceresource:name: cputarget:type: UtilizationaverageUtilization: 50
查看部署结果
# kubectl get hpa -n hpaNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGEnginx Deployment/nginx 0%/50% 1 10 2 50s压测观察Pod数和HPA变化
# 执行压测命令
# ab -c 1000 -n 100000000 http://127.0.0.1:30792/This is ApacheBench, Version 2.3 $Revision: 1843412 $Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/Licensed to The Apache Software Foundation, http://www.apache.org/Benchmarking 127.0.0.1 (be patient)# 观察变化
# kubectl get hpa -n hpaNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGEnginx Deployment/nginx 303%/50% 1 10 7 12m# kubectl get po -n hpaNAME READY STATUS RESTARTS AGEpod/nginx-5c87768612-6b4sl 1/1 Running 0 85spod/nginx-5c87768612-99mjb 1/1 Running 0 69spod/nginx-5c87768612-cls7r 1/1 Running 0 85spod/nginx-5c87768612-hhdr7 1/1 Running 0 69spod/nginx-5c87768612-jj744 1/1 Running 0 85spod/nginx-5c87768612-kfpkq 1/1 Running 0 27mpod/nginx-5c87768612-xb94x 1/1 Running 0 69s可以看出hpa TARGETS达到了303%需要扩容。pod数自动扩展到了7个。等待压测结束
# kubectl get hpa -n hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx Deployment/nginx 20%/50% 1 10 7 16m---N分钟后---# kubectl get hpa -n hpaNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGEnginx Deployment/nginx 0%/50% 1 10 7 18m---再过N分钟后---# kubectl get po -n hpaNAME READY STATUS RESTARTS AGEnginx-5c87768612-jj744 1/1 Running 0 11mhpa示例总结 CPU 利用率已经降到 0所以 HPA 将自动缩减副本数量至 1。 为什么会将副本数降为1而不是我们部署时指定的replicas: 2呢 因为在创建HPA时指定了副本数范围这里是minReplicas: 1maxReplicas: 10。所以HPA在缩减副本数时减到了1。
VPA 垂直Pod自动伸缩
VPA 全称 Vertical Pod Autoscaler即垂直 Pod 自动扩缩容它根据容器资源使用率自动设置 CPU 和 内存 的requests从而允许在节点上进行适当的调度以便为每个 Pod 提供适当的资源。 它既可以缩小过度请求资源的容器也可以根据其使用情况随时提升资源不足的容量。 有些时候无法通过增加 Pod 数来扩容比如数据库。这时候可以通过 VPA 增加 Pod 的大小比如调整 Pod 的 CPU 和内存 CA 集群自动缩放器
集群自动伸缩器CA基于待处理的豆荚扩展集群节点。它会定期检查是否有任何待处理的豆荚如果需要更多的资源并且扩展的集群仍然在用户提供的约束范围内则会增加集群的大小。CA与云供应商接口请求更多节点或释放空闲节点。它与GCP、AWS和Azure兼容。版本1.0GA与Kubernetes 1.8一起发布。 当集群资源不足时CA 会自动配置新的计算资源并添加到集群中 13. 污点和容忍
Taint需要和Toleration配合使用让Pod避开那些不合适的Node。在 Node上设置一个或多个Taint之后除非Pod明确声明能够容忍这些污 点否则无法在这些Node上运行。
Toleration是Pod的属性让Pod能够 注意只是能够而非必须运行在标注了Taint的Node上。
污点 在node节点上打污点 pod在调度的时候会选择没有污点的节点去运行 调度器在分配pod到那个节点上的时候会选择没有污点的节点去启动pod
容忍 是pod有污点的节点服务器任然可以调度到这个节点上去运行 调度器在调度的过程中会查看节点服务器是否有污点然后看pod的策略里是否能容忍这个污点如果能容忍就调度到这个节点服务器上如果不能容忍就不调度过去。 给node1打上污点 申明可以容忍pod对污点的不调度策略 先检查key是否匹配匹配是看operator是exists或者equal 表示匹配effect可以理解为允许在有污点的节点上启动这个pod如果key不匹配就不允许调度到这个污点节点
equal 操作需要写key和valueexists不需要接value 为什么master节点上没有业务pod 答案因为master节点上有污点默认业务pod都不调度到master节点
能容忍任何的污点和排斥等级 能接受任何污点并且排斥等级是NoExecute的节点服务器 内置的污点名字 容忍时间
tolerationSeconds: 3600 删除污点在定义污点的语句后加- 14. 有状态的应用和无状态的应用
有状态应用
可以说是 需要数据存储功能的服务、或者指多线程类型的服务队列等。mysql数据库、kafka、zookeeper等。每个实例都需要有自己独立的持久化存储
特点:
缩容的时候是顺序进行的不是随机的pod的编号是有顺序的每个实例都需要有自己独立的持久化存储
案例
nginx 无状态 启动的时候不必须按照顺序并且pod是随机分配id web服务 访问任意一个web服务器得到结果都是一样的而且网页数据也是从同一个地方获取
mysql 有状态 启动的时候必须按照顺序并且pod是有固定的编号不允许随机分配 master slave 写数据--》master上写
无状态的应用
1、是指该服务运行的实例不会在本地存储需要持久化的数据并且多个实例对于同一个请求响应的结果是完全一致的。
2、多个实例可以共享相同的持久化数据。例如nginx实例tomcat实例等
3、相关的k8s资源有ReplicaSet、ReplicationController、Deployment等由于是无状态服务所以这些控制器创建的pod序号都是随机值。并且在缩容的时候并不会明确缩容某一个pod而是随机的因为所有实例得到的返回值都是一样所以缩容任何一个pod都可以。
15. ingress相关
参考https://blog.csdn.net/ZhouXin1111112/article/details/132669303?spm1001.2014.3001.5501
16. RBAC相关
参考https://blog.csdn.net/ZhouXin1111112/article/details/132670500?spm1001.2014.3001.5502
17. CI/CD 持续集成、持续交付 jenkins 参考https://blog.csdn.net/ZhouXin1111112/article/details/132577550?spm1001.2014.3001.5502
18. pod有多少种状态
Kubernetes 中的 Pod 有以下几种状态
Pending挂起Pod 已经被 Kubernetes API 接受但它的容器镜像还没有被拉取或者 Pod 所需的节点资源CPU、内存等还没有满足。在这个状态中Pod 是不可调度的。Running运行Pod 已经调度到了节点上并且所有容器都已经创建至少有一个容器仍在运行中或者在启动过程中。Succeeded成功Pod 中的所有容器都已经正常终止并且不会再重启。Failed失败Pod 中至少有一个容器已经以非零状态退出。Unknown未知无法获取 Pod 的状态。这种状态通常是由于与 Pod 相关的 API 调用失败或者 Pod 控制器处于错误状态导致的。
除了上述状态之外Pod还有一些特殊的条件状态它们记录了 Pod 的一些细节信息例如 Pod 是否处于调度中、容器镜像是否拉取成功等。这些状态和条件状态可以通过 kubectl describe pod 命令获取这些条件状态
PodScheduled表示 Pod 是否已经被调度到了节点上。ContainersReady表示 Pod 中的所有容器是否已经准备就绪。Initialized表示 Pod 中的所有容器是否已经初始化。Ready表示 Pod 是否已经准备就绪即所有容器都已经启动并且可以接收流量。CrashLoopBackOff 容器退出kubelet正在将它重启InvalidImageName 无法解析镜像名称ImageInspectError 无法校验镜像ErrImageNeverPull 策略禁止拉取镜像ImagePullBackOff 正在重试拉取RegistryUnavailable 连接不到镜像中心ErrImagePull通用的拉取镜像出错CreateContainerConfigError 不能创建kubelet使用的容器配置CreateContainerError 创建容器失败m.internalLifecycle.PreStartContainer 执行hook报错RunContainerError 启动容器失败PostStartHookError 执行hook报错ContainersNotInitialized 容器没有初始化完毕ContainersNotReady 容器没有准备完毕ContainerCreating容器创建中PodInitializingpod 初始化中DockerDaemonNotReadydocker还没有完全启动NetworkPluginNotReady 网络插件还没有完全启动Evicte: pod被驱赶
19. pod的重启策略
Pod 的 spec 中包含一个 restartPolicy 字段其可能取值包括 Always、OnFailure 和 Never。默认值是 Always。
