不背锅运维耗时1周整理分享K8SPod知识点，带你一文打尽

　　1。Pod概念热身
　　Pod是一个逻辑抽象概念，K8s创建和管理的最小单元，一个Pod由一个容器或多个容器组成。特点：一个Pod可以理解为是一个应用实例Pod中容器始终部署在一个Node上Pod中容器共享网络、存储资源
　　Pod主要用法：运行单个容器：最常见的用法，在这种情况下，可以将Pod看作是单个容器的抽象封装运行多个容器：边车模式（Sidecar），通过在Pod中定义专门容器，来执行主业务容器需要的辅助工作，这样好处是将辅助功能同主业务容器解耦，实现独立发布和能力重用。例如：日志收集应用监控
　　扩展：READY字段的意义：tantianrantestbk8smaster：kubectlgetpodsntestaNAMEREADYSTATUSRESTARTSAGEgowebdemob9886945625sj911Running1（3m49sago）5d10h
　　在READY字段中，11的意义为在这个pod里，已准备的容器一共有多少个容器。
　　在pod中，它可以有3种类型的容器，分别是：基础容器（pausecontainer）初始化容器（initcontainer）普通容器（业务容器应用容器）2。POD内容器间资源共享实现机制2。1共享数据的机制emptyDir：会在Pod被删除的同时也会被删除，当Pod分派到某个节点上时，emptyDir卷会被创建，并且在Pod在该节点上运行期间，卷一直存在。就像其名称表示的那样，卷最初是空的。尽管Pod中的容器挂载emptyDir卷的路径可能相同也可能不同，这些容器都可以读写emptyDir卷中相同的文件。当Pod因为某些原因被从节点上删除时，emptyDir卷中的数据也会被永久删除。例子apiVersion：v1kind：Podmetadata：name：testpod1spec：containers：image：nginxname：nginx1volumeMounts：mountPath：cachename：cachevolumeimage：busyboxname：bs1command：〔binsh，c，sleep12h〕volumeMounts：mountPath：cachename：cachevolumevolumes：name：cachevolumeemptyDir：sizeLimit：500Micephfs：cephfs卷允许你将现存的CephFS卷挂载到Pod中，cephfs卷的内容在Pod被删除时会被保留，只是卷被卸载了。这意味着cephfs卷可以被预先填充数据，且这些数据可以在Pod之间共享。同一cephfs卷可同时被多个写者挂载。2。2共享网络的机制
　　共享网络的机制是由Pause容器实现，下面慢慢分析一下，啥是pause，了解一下它的作用等等。
　　先准备一个yaml文件（pod1。yaml），创建一个pod，pod里包含两个容器，一个是名为nginx1的容器，还有一个是名为bs1的容器apiVersion：v1kind：Podmetadata：name：testpod1spec：containers：image：nginxname：nginx1volumeMounts：mountPath：cachename：cachevolumeimage：busyboxname：bs1command：〔binsh，c，sleep12h〕volumeMounts：mountPath：cachename：cachevolumevolumes：name：cachevolumeemptyDir：sizeLimit：500Mi
　　开始创建tantianrantestbk8smaster：kubectlcreatefpod1。yamlpodtestpod1created
　　创建完后看看在哪个节点tantianrantestbk8smaster：kubectlgetpodowideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATEStestpod122Running09m21s10。244。222。44testbk8snode02nonenone
　　去到对应的节点查看容器tantianrantestbk8snode02：sudodockerpsgreptestpod10db01653bdacbusyboxbinshcsleep19minutesagoUp9minutesk8sbs1testpod1defaultc3a15f703ae24a738a84d630c047d8270296972c29efenginxdockerentrypoint。9minutesagoUp9minutesk8snginx1testpod1defaultc3a15f703ae24a738a84d630c047d8270a5331fba7f11registry。aliyuncs。comgooglecontainerspause：latestpause10minutesagoUp10minutesk8sPODtestpod1defaultc3a15f703ae24a738a84d630c047d8270tantianrantestbk8snode02：
　　通过查看容器，名为testpod1的pod里，除了两个业务容器外（k8sbs1testpod1、nginx1testpod1），还有一个pause容器。这个到底是什么鬼呢？
　　对pause容器的理解pause容器又叫Infracontainer，就是基础设施容器的意思，Infracontainer只是pause容器的一个叫法而已上面看到paus容器，是从registry。aliyuncs。comgooglecontainerspause：latest这个镜像拉起的在其中一台node节点上查看docker镜像，可看到该镜像的大小是240KBregistry。aliyuncs。comgooglecontainerspauselatest350b164e7ae18yearsago240kB根据理解，画了图：
　　nginx1容器里的nginx组件默认监听的端口是80，在bs1容器里去curlhttp：127。0。0。1就可以放到nginx1容器的80端口。step1：查看testpod1里的容器kubectlgetpodstestpod1ojsonpath｛。spec。containers〔〕。name｝step2：进入指定容器kubectlexecittestpod1cbs1sh访问nginx（因没有curl命令，此处用wget）wgethttp：127。0。0。1Connectingto127。0。0。1（127。0。0。1：80）savingtoindex。htmlindex。html1006150：00：00ETAindex。htmlsaved
　　上面看到，使用wget命令下载到了index。html文件，说明访问成功。3。Pod常用管理命令查看pod里所有容器的名称kubectlgetpodstestpod1ojsonpath｛。spec。containers〔〕。name｝进入pod里的指定容器的终端，如下进入pod为testpod1里的容器nginx1和bs1kubectlexecittestpod1cnginx1bashkubectlexecittestpod1cbs1sh查看pod里指定容器的logkubectllogstestpod1cnginx14。Pod的重启策略应用健康检查（应用自修复）
　　重启策略Always：当容器终止退出，总是重启容器，默认策略OnFailure：当容器异常退出（退出状态码非0）时，才重启容器Never：当容器终止退出，从不重启容器
　　查看pod的重启策略查看pod，以yaml格式输出kubectlgetpodstestpod1oyaml找到restartPolicy字段，就是重启策略restartPolicy：Always
　　健康检查有以下3种类型：
　　健康检查是检查容器里面的服务是否正常livenessProbe（存活探测）：如果检查失败，将杀死容器，根据pod的restartPolicy来操作。readinessProbe（就绪探测）：如果检查失败，k8s会把Pod从serviceendpoints中剔除startupProbe（启动探测）：检查成功才由存活检查接手，用于保护慢启动容器
　　支持以下三种检查方法：httpGet：发起HTTP请求，返回200400范围状态码为成功。exec：执行Shell命令返回状态码是0为成功。tcpSocket：发起TCPSocket建立成功。
　　案例实战
　　livenessProbe（存活探针）：使用exec的方式（执行Shell命令返回状态码是0则为成功）apiVersion：v1kind：Namespacemetadata：name：testaapiVersion：appsv1kind：Deploymentmetadata：name：gowebdemonamespace：testaspec：replicas：10selector：matchLabels：app：gowebdemotemplate：metadata：labels：app：gowebdemospec：containers：name：gowebdemoimage：192。168。11。247webdemogowebdemo：20221229v3livenessProbe：exec：command：lsoptgowebdemorunserverinitialDelaySeconds：5periodSeconds：5apiVersion：v1kind：Servicemetadata：name：gowebdemonamespace：testaspec：ports：port：80protocol：TCPtargetPort：8090selector：app：gowebdemotype：NodePort
　　periodSeconds字段指定了kubelet应该每5秒执行一次存活探测，initialDelaySeconds字段告诉kubelet在执行第一次探测前应该等待5秒，kubelet在容器内执行命令lsoptgowebdemorunserver来进行探测。如果命令执行成功并且返回值为0，kubelet就会认为这个容器是健康存活的。如果这个命令返回非0值，kubelet会杀死这个容器并重新启动它。
　　验证存活检查的效果查看某个pod的里的容器，kubectlgetpodsgowebdemo686967fd56556m9ntestaojsonpath｛。spec。containers〔〕。name｝进入某个pod里的容器kubectlexecitgowebdemo686967fd56556m9cgowebdemontestabash进入容器后，手动删除掉runserver可执行文件，模拟故障rmrfoptgowebdemorunserver查看Pod详情（在输出结果的最下面，有信息显示存活探针失败了，这个失败的容器被杀死并且被重建了。）kubectldescribepodgowebdemo686967fd56556m9ntestaEvents：TypeReasonAgeFromMessageWarningUnhealthy177m（x6over3h59m）kubeletLivenessprobefailed：ls：cannotaccessoptgowebdemorunserver：Nosuchfileordirectory一旦失败的容器恢复为运行状态，RESTARTS计数器就会增加1tantianrantestbk8smaster：kubectlgetpodsntestaNAMEREADYSTATUSRESTARTSAGEgowebdemo686967fd56556m911Running1（22sago）13mRESTARTS字段加1，gowebdemo686967fd568hzjb11Running013m。。。
　　livenessProbe（存活探针）：使用httpGet请求的方式检查uripath是否正常apiVersion：v1kind：Namespacemetadata：name：testaapiVersion：appsv1kind：Deploymentmetadata：name：gowebdemonamespace：testaspec：replicas：10selector：matchLabels：app：gowebdemotemplate：metadata：labels：app：gowebdemospec：containers：name：gowebdemoimage：192。168。11。247webdemogowebdemo：20221229v3livenessProbe：httpGet：path：loginport：8090httpHeaders：name：CustomHeadervalue：AwesomeinitialDelaySeconds：3periodSeconds：3apiVersion：v1kind：Servicemetadata：name：gowebdemonamespace：testaspec：ports：port：80protocol：TCPtargetPort：8090selector：app：gowebdemotype：NodePort
　　在这个配置文件中，你可以看到Pod也只有一个容器。periodSeconds字段指定了kubelet每隔3秒执行一次存活探测。initialDelaySeconds字段告诉kubelet在执行第一次探测前应该等待3秒。kubelet会向容器内运行的服务（服务在监听8090端口）发送一个HTTPGET请求来执行探测。如果服务器上login路径下的处理程序返回成功代码，则kubelet认为容器是健康存活的。如果处理程序返回失败代码，则kubelet会杀死这个容器并将其重启。返回大于或等于200并且小于400的任何代码都表示成功，其它返回代码都表示失败。
　　验证效果进入容器删除静态文件，模拟故障kubectlexecitgowebdemo586ff85ddb4646kcgowebdemontestabashrmrflogin。html查看pod的logkubectllogsgowebdemo586ff85ddb4646kntesta2023011206：45：19〔Recovery〕2023011206：45：19panicrecovered：GETloginHTTP1。1Host：10。244。222。5：8090Connection：closeAccept：Connection：closeCustomHeader：AwesomeUserAgent：kubeprobe1。25htmltemplate：login。htmlisundefinedrootmyworkspacepkgmodgithub。comgingonicginv1。8。2context。go：911（0x8836d1）rootmyworkspacepkgmodgithub。comgingonicginv1。8。2context。go：920（0x88378c）rootmyworkspacesrcgowebdemomain。go：10（0x89584e）查看pod详情kubectldescribepodgowebdemo586ff85ddb4646kntestaWarningUnhealthy34s（x3over40s）kubeletLivenessprobefailed：HTTPprobefailedwithstatuscode：500状态码为500恢复后查看Pod，RESTARTS计数器已经增1kubectlgetpodgowebdemo586ff85ddb4646kntestaNAMEREADYSTATUSRESTARTSAGEgowebdemo586ff85ddb4646k11Running1（80sago）5m39s
　　readinessProbe（就绪探针）结合livenessProbe（存活探针）探测tcp端口：
　　第三种类型的存活探测是使用TCP套接字。使用这种配置时，kubelet会尝试在指定端口和容器建立套接字链接。如果能建立连接，这个容器就被看作是健康的，如果不能则这个容器就被看作是有问题的。apiVersion：v1kind：Namespacemetadata：name：testaapiVersion：appsv1kind：Deploymentmetadata：name：gowebdemonamespace：testaspec：replicas：10selector：matchLabels：app：gowebdemotemplate：metadata：labels：app：gowebdemospec：containers：name：gowebdemoimage：192。168。11。247webdemogowebdemo：20221229v3readinessProbe：tcpSocket：port：8090initialDelaySeconds：5periodSeconds：10livenessProbe：tcpSocket：port：8090initialDelaySeconds：15periodSeconds：20apiVersion：v1kind：Servicemetadata：name：gowebdemonamespace：testaspec：ports：port：80protocol：TCPtargetPort：8090selector：app：gowebdemotype：NodePort
　　TCP检测的配置和HTTP检测非常相似。这个例子同时使用就绪和存活探针。kubelet会在容器启动5秒后发送第一个就绪探针。探针会尝试连接gowebdemo容器的8090端口。如果探测成功，这个Pod会被标记为就绪状态，kubelet将继续每隔10秒运行一次探测。除了就绪探针，这个配置包括了一个存活探针。kubelet会在容器启动15秒后进行第一次存活探测。与就绪探针类似，存活探针会尝试连接gowebdemo容器的8090端口。如果存活探测失败，容器会被重新启动。
　　验证效果进入容器后，杀掉gowebdemo的进程kubectlexecitgowebdemo5d7d55f846vm2kccgowebdemontestabashrootgowebdemo5d7d55f846vm2kc：optgowebdemopsauxUSERPIDCPUMEMVSZRSSTTYSTATSTARTTIMECOMMANDroot10。00。02476576？Ss07：230：00binshcoptgowebdemorunserverrootgowebdemo5d7d55f846vm2kc：optgowebdemokill91查看pod详情，已经发出警告kubectldescribepodgowebdemo5d7d55f846vm2kcntestaWarningUnhealthy16skubeletReadinessprobefailed：dialtcp10。244。240。48：8090：connect：connectionrefusedWarningBackOff16skubeletBackoffrestartingfailedcontainer查看pod，RESTARTS计数器已经增加为2，因为有两个探针tantianrantestbk8smaster：kubectlgetpodntestaNAMEREADYSTATUSRESTARTSAGEgowebdemo5d7d55f846vm2kc11Running2（2m55sago）12m
　　使用startupProbe（启动探针）保护慢启动容器
　　有一种情景是这样的，某些应用在启动时需要较长的初始化时间。要这种情况下，若要不影响对死锁作出快速响应的探测，设置存活探测参数是要技巧的。技巧就是使用相同的命令来设置启动探测，针对HTTP或TCP检测，可以通过将failureThresholdperiodSeconds参数设置为足够长的时间来应对糟糕情况下的启动时间。apiVersion：v1kind：Namespacemetadata：name：testaapiVersion：appsv1kind：Deploymentmetadata：name：gowebdemonamespace：testaspec：replicas：10selector：matchLabels：app：gowebdemotemplate：metadata：labels：app：gowebdemospec：containers：name：gowebdemoimage：192。168。11。247webdemogowebdemo：20221229v3livenessProbe：httpGet：path：loginport：8090failureThreshold：1periodSeconds：10startupProbe：httpGet：path：loginport：8090failureThreshold：30periodSeconds：10apiVersion：v1kind：Servicemetadata：name：gowebdemonamespace：testaspec：ports：port：80protocol：TCPtargetPort：8090selector：app：gowebdemotype：NodePort
　　上面的例子，应用程序将会有最多5分钟（3010300s）的时间来完成其启动过程。一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁作出快速响应。如果启动探测一直没有成功，容器会在300秒后被杀死，并且根据restartPolicy来执行进一步处置。5。环境变量
　　创建Pod时，可以为其下的容器设置环境变量。通过配置文件的env或者envFrom字段来设置环境变量。
　　应用场景：容器内应用程序获取pod信息容器内应用程序通过用户定义的变量改变默认行为
　　变量值定义的方式：自定义变量值变量值从Pod属性获取变量值从Secret、ConfigMap获取
　　下面来个小例子，设置自定义变量，使用env给pod里的容器设置环境变量，本例子中，设置了环境变量有SAVETIME、MAXCONN、DNSADDR。apiVersion：v1kind：Podmetadata：name：testenvdemospec：containers：name：testenvdemocontainerimage：192。168。11。247webdemogowebdemo：20221229v3env：name：SAVETIMEvalue：60name：MAXCONNvalue：1024name：DNSADDRvalue：8。8。8。8
　　开始创建podtantianrantestbk8smaster：kubectlcreateftestenv。yamlpodtestenvdemocreatedtantianrantestbk8smaster：
　　创建后，验证环境变量是否能获取到使用printenv打印环境变量tantianrantestbk8smaster：gowebdemokubectlexectestenvdemoprintenvPATHgobin：usrlocalgobin：usrlocalsbin：usrlocalbin：usrsbin：usrbin：sbin：binHOSTNAMEtestenvdemoSAVETIME60这个是MAXCONN1024这个是DNSADDR8。8。8。8这个是KUBERNETESSERVICEHOST10。96。0。1KUBERNETESSERVICEPORT443KUBERNETESSERVICEPORTHTTPS443KUBERNETESPORTtcp：10。96。0。1：443KUBERNETESPORT443TCPtcp：10。96。0。1：443KUBERNETESPORT443TCPPROTOtcpKUBERNETESPORT443TCPPORT443KUBERNETESPORT443TCPADDR10。96。0。1GOLANGVERSION1。19。4GOPATHgoHOMEroottantianrantestbk8smaster：gowebdemo进入容器打印环境变量tantianrantestbk8smaster：gowebdemokubectlexecittestenvdemoctestenvdemocontainerbashroottestenvdemo：optgowebdemoechoSAVETIME单独打印一个60roottestenvdemo：optgowebdemoenv执行env命令查看KUBERNETESSERVICEPORTHTTPS443KUBERNETESSERVICEPORT443HOSTNAMEtestenvdemoPWDoptgowebdemoDNSADDR8。8。8。8HOMErootKUBERNETESPORT443TCPtcp：10。96。0。1：443MAXCONN1024GOLANGVERSION1。19。4TERMxtermSHLVL1KUBERNETESPORT443TCPPROTOtcpKUBERNETESPORT443TCPADDR10。96。0。1SAVETIME60KUBERNETESSERVICEHOST10。96。0。1KUBERNETESPORTtcp：10。96。0。1：443KUBERNETESPORT443TCPPORT443PATHgobin：usrlocalgobin：usrlocalsbin：usrlocalbin：usrsbin：usrbin：sbin：binGOPATHgousrbinenvroottestenvdemo：optgowebdemo
　　再来个小例子，直接取pod的属性作为变量的值，下面的例子是拿到pod所处的节点名称apiVersion：v1kind：Podmetadata：name：testenvdemospec：containers：name：testenvdemocontainerimage：192。168。11。247webdemogowebdemo：20221229v3env：name：NODENAMEvalueFrom：fieldRef：fieldPath：spec。nodeName
　　打印变量tantianrantestbk8smaster：kubectlexectestenvdemoprintenvPATHgobin：usrlocalgobin：usrlocalsbin：usrlocalbin：usrsbin：usrbin：sbin：binHOSTNAMEtestenvdemoNODENAMEtestbk8snode02NODENAME变量，值为testbk8snode02KUBERNETESPORTtcp：10。96。0。1：443KUBERNETESPORT443TCPtcp：10。96。0。1：443KUBERNETESPORT443TCPPROTOtcpKUBERNETESPORT443TCPPORT443KUBERNETESPORT443TCPADDR10。96。0。1KUBERNETESSERVICEHOST10。96。0。1KUBERNETESSERVICEPORT443KUBERNETESSERVICEPORTHTTPS443GOLANGVERSION1。19。4GOPATHgoHOMEroot
　　再来最后一个例子，使用容器字段作为环境变量的值，这个例子设置了资源限制的字段requests和limits，在设置环境变量中，使用资源限制的值作为了变量的值。apiVersion：v1kind：Podmetadata：name：testenvdemospec：containers：name：testenvdemocontainerimage：192。168。11。247webdemogowebdemo：20221229v3resources：requests：memory：32Micpu：125mlimits：memory：64Micpu：250menv：name：CPUREQUESTvalueFrom：resourceFieldRef：containerName：testenvdemocontainerresource：requests。cpuname：CPULIMITvalueFrom：resourceFieldRef：containerName：testenvdemocontainerresource：limits。cpuname：MEMREQUESTvalueFrom：resourceFieldRef：containerName：testenvdemocontainerresource：requests。memoryname：MEMLIMITvalueFrom：resourceFieldRef：containerName：testenvdemocontainerresource：limits。memory
　　打印变量tantianrantestbk8smaster：kubectlexectestenvdemoprintenvPATHgobin：usrlocalgobin：usrlocalsbin：usrlocalbin：usrsbin：usrbin：sbin：binHOSTNAMEtestenvdemoMEMREQUEST33554432MEMLIMIT67108864CPUREQUEST1CPULIMIT1KUBERNETESSERVICEPORTHTTPS443KUBERNETESPORTtcp：10。96。0。1：443KUBERNETESPORT443TCPtcp：10。96。0。1：443KUBERNETESPORT443TCPPROTOtcpKUBERNETESPORT443TCPPORT443KUBERNETESPORT443TCPADDR10。96。0。1KUBERNETESSERVICEHOST10。96。0。1KUBERNETESSERVICEPORT443GOLANGVERSION1。19。4GOPATHgoHOMEroot6。initcontainer（初始化容器）
　　初始化容器的特点：Init容器是一种特殊容器，在Pod内，会在应用容器启动之前运行。如果Pod的Init容器失败，kubelet会不断地重启该Init容器，直到该容器成功为止。如果Pod对应的restartPolicy值为Never，并且Pod的Init容器失败，则Kubernetes会将整个Pod状态设置为失败。如果为一个Pod指定了多个Init容器，这些容器会按顺序逐个运行。每个Init容器必须运行成功，下一个才能够运行。Init容器不支持探针，包括lifecycle、livenessProbe、readinessProbe和startupProbe
　　在实际工作中，可利用它的这种工作机制应对某些场景，比如在应用容器启动之前，需要做一些初始化相关的工作，比如初始化配置文件，测试IP或端口的连通性等等场景。
　　下面来个小例子，场景是这样的，我的应用容器是gowebdemo，初始化容器是initcheckmysqlip，假设应用容器是依赖数据库的，如果数据库没起来，那么应用容器就算起来了也是服务不可用。所以，现在的主要目的是想在应用容器启动之前检查mysql服务器的IP地址是否可ping通，如果是通的才启动应用容器。这个例子应该是比较贴近实际场景了。下面，看我写好的yaml：apiVersion：v1kind：Namespacemetadata：name：testaapiVersion：appsv1kind：Deploymentmetadata：name：gowebdemonamespace：testaspec：replicas：3selector：matchLabels：app：gowebdemotemplate：metadata：labels：app：gowebdemospec：containers：name：gowebdemoimage：192。168。11。247webdemogowebdemo：20221229v3initContainers：name：initcheckmysqlipimage：192。168。11。247osbusybox：latestcommand：〔sh，c，ping192。168。11。248c5〕apiVersion：v1kind：Servicemetadata：name：gowebdemonamespace：testaspec：ports：port：80protocol：TCPtargetPort：8090selector：app：gowebdemotype：NodePort
　　mysql服务器故意没拉起，看看效果：tantianrantestbk8smaster：gowebdemokubectlgetpodsntestaNAMEREADYSTATUSRESTARTSAGEgowebdemo859cc77bd5jpcfs01Init：012（18sago）48sgowebdemo859cc77bd5n8hqd01Init：012（17sago）48sgowebdemo859cc77bd5sns6701Init：012（17sago）48stantianrantestbk8smaster：gowebdemotantianrantestbk8smaster：gowebdemokubectlgetpodsntestaNAMEREADYSTATUSRESTARTSAGEgowebdemo859cc77bd5jpcfs01Init：Error4（67sago）2m44sgowebdemo859cc77bd5n8hqd01Init：Error4（66sago）2m44sgowebdemo859cc77bd5sns6701Init：Error4（67sago）2m44stantianrantestbk8smaster：gowebdemotantianrantestbk8smaster：gowebdemokubectlgetpodsntestaNAMEREADYSTATUSRESTARTSAGEgowebdemo859cc77bd5jpcfs01Init：CrashLoopBackOff3（34sago）2m11sgowebdemo859cc77bd5n8hqd01Init：CrashLoopBackOff3（33sago）2m11sgowebdemo859cc77bd5sns6701Init：CrashLoopBackOff3（34sago）2m11stantianrantestbk8smaster：gowebdemo
　　观察STATUS字段发现，它经历了3个阶段，第一阶段是正常的运行，也就是执行ping检查的操作，因为死活Ping不同，所以进入了第二阶段，状态为Error。紧接着是第三阶段，状态变成了CrashLoopBackOff，对于这个状态，我的理解是，初始化容器运行失败了，准备再次运行。总而言之，如果Mysql服务器的IP死活ping不通，它就会的状态就会一直这样：运行ErrorCrashLoopBackOff。当然这种情况是当Pod对应的restartPolicy为Always（这是默认策略）才会这样不断的循环检查，如果Pod对应的restartPolicy值为Never，并且Pod的Init容器失败，则Kubernetes会将整个Pod状态设置为失败。
　　当我把mysql服务器启动后，初始化容器执行成功，那么应用容器也就成功起来了：tantianrantestbk8smaster：gowebdemokubectlgetpodsntestaNAMEREADYSTATUSRESTARTSAGEgowebdemo859cc77bd5jpcfs11Running030mgowebdemo859cc77bd5n8hqd11Running030mgowebdemo859cc77bd5sns6711Running030mtantianrantestbk8smaster：gowebdemo7。静态pod
　　在实际工作中，静态Pod的应用场景是毕竟少的，几乎没有。不过也还是得对它做一个简单的了解。静态Pod在指定的节点上由kubelet守护进程直接管理，不需要API服务器监管。与由控制面管理的Pod（例如，Deployment）不同；kubelet监视每个静态Pod（在它失败之后重新启动），静态Pod始终都会绑定到特定节点的Kubelet上。
　　在每个node节点上，kubelet的守护进程会自动在etckubernetesmanifests路径下发现yaml，因此，如果想要创建静态Pod，就得把yaml放到该目录，下面我们直接实战一下。
　　随便登录到某台node节点，然后创建etckubernetesmanifestsstaticpod。yamlapiVersion：v1kind：Podmetadata：name：teststaticpodspec：containers：name：testcontainerimage：192。168。11。247webdemogowebdemo：20221229v3
　　创建后，回到master节点上查看podtantianrantestbk8smaster：kubectlgetpodNAMEREADYSTATUSRESTARTSAGEteststaticpodtestbk8snode0111Running011s
　　通过上面的输出结果可以看到，该静态pod已经在节点testbk8snode01上面正常运行了，说明kubelet守护进程已经自动发现并创建了它。你可能会问，它不是不需要API服务器监管吗？为啥在master节点能看到它？因为kubelet会尝试通过KubernetesAPI服务器为每个静态Pod自动创建一个镜像Pod，这意味着节点上运行的静态Pod对API服务来说是可见的，但是不能通过API服务器来控制。且Pod名称将把以连字符开头的节点主机名作为后缀。
　　本文转载于（喜欢的盆友关注我们）：https：mp。weixin。qq。coms5Kv7DU34Ae5y17MAQVOQ