kubernetes学习（六）pod控制器

1、什么是控制器k8s中运行了一系列控制器来确保集群的当前状态与期望状态保持一致它们就是k8s集群内部的管理控制中心或者说是“中心大脑”。例如ReplicaSet控制器负责维护集群中运行pod的数量Node控制器负责监控节点的状态并在节点出现故障时执行自动化修复流程确保集群始终处于预期的工作状态下图是控制器的工作状态分析上图从清单中可以看到第一个看到spec定义了pod数量有8个第二个是spec是容器组。右边是节点的真实状态而中间就是控制器起到的作用调谐。什么叫调谐我们先要检测当前控制器的状态再去和清单对比预期状态。如果发现少个几个pod这时候要去调整资源部署将一个或多个新的pod在我们当前可用节点上被创建。也会有当前符合要求的pod比清单中预期多的情况比如有9个满足要求的pod那么控制器会按照创建时间最新的pod将它杀死。在重复不断的把当前状态和预期状态做对比这就叫调谐。当然也有很实际的一种情况比如预期pod是8个但是节点资源不足以容纳这么多pod这是控制器再怎么调谐也没办法。控制器不指定pod数量的话默认为1官方自带pod控制器列举之所以说官方自带是因为公司有能力的话可以自己开发控制器这是kubernetes强大的冰山一角ReplicationController和ReplicaSetDeploymentDaemonSetStateFulSetJob/CronJobHorizontal Pod Autoscaling2、ReplicationControllerReplicationControllerRC用来确保容器应用的副本数始终保持在用户定义的副本数即如果有容器异常退出会自动创建新的pod来替代而如果异常多出来的容器也会被自动回收apiVersion: v1 kind: ReplicationController metadata: name: rc-demo spec: replicas: 3 selector: app: rc-demo template: metadata: labels: app: rc-demo spec: containers: - name: rc-demo-container image: swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/busybox:1.28 imagePullPolicy: IfNotPresent command: - sh - -c - sleep 3600 #replicas这个是新东西控制器控制pod数量的字段。如果不写此字段默认控制器pod数量为1 #selector也是新东西叫标签选择器。用于筛选哪些pod受此控制器管理 #template同样是新东西这个是pod模板用于创建pod前几章单独写pod就没有但是控制器要在这个模板下进行pod的创建创建对象查询一下控制器状态可以缩写。期望三个当前三个就绪三个符合清单预期再看podpod名称是标签跟上了md5值这是控制器创建pod的命名格式测试一下控制器的特性对比预期满足清单预期是三个pod删除一个看看情况可以看到控制器根据清单预期立马就创建了一个pod。注意生产环境我们是不会删除pod的但是无法避免节点损坏容易混淆的一点是pod重启策略总是Always的话pod会自动创建新的容器取代损坏的恢复当前的pod只不过pod重启次数会增加。另外pod内部容器损坏不会进行重启因为控制器控制的级别是pod本身pod本身损坏才会进行操作做个标签选择器的实验。selector选择器标签的值必须要是pod标签的子集才行。#添加标签 kubectl label pod podName versionv1在pod后新加了个标签版本号。查看发现pod有两个标签了但他依然是rc的子集尝试将一个pod标签修改下#修改标签 kubectl label pod podName apptest --overwrite修改后发现pod变成了四个因为修改标签后修改过的pod就不是rc的子集了不属于rc控制了这时候控制器对比预期少了一个pod就开始创建新的pod图中报错是告诉我们这个标签的key存在如果要更改的话必须加--overwrite进行覆盖。再尝试将修改过的标签在改回来kubectl label pod podName apprc-demo --overwrite可以看到pod又变成了三个因为修改标签后又归属到rc子集中又归rc管理了。控制器检查预期状态是三个现在多了一个就将创建时间最新的pod进行删除以符合预期#删除标签将想删除的标签键后面跟“-” kubectl label pod podName 标签键-最后可以调整控制器的副本数量#修改控制器副本数量 kubectl scale controllerType podName --replicas Num #也可以在yaml中修改副本数量使用kubectl apply -f fileName进行覆写3、ReplicaSet在新版的k8s中官方建议用RplicaSetRS取代RCRS和RC没有本质的不同只是RS支持集合式的selector通俗的说是RS的升级版apiVersion: apps/v1 kind: ReplicaSet metadata: name: rs-demo spec: replicas: 3 selector: matchLabels: app: rs-demo ver: v1 template: metadata: labels: app: rs-demo ver: v1 main: study spec: containers: - name: rs-demo-container image: swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/busybox:1.28 imagePullPolicy: IfNotPresent command: [sh,-c,sleep 3600]一切都和RC控制器差不多唯一区别是selector下面多的两个字段,并且这两个字段对RC以外的所有控制器适用。这两个字段被称为标签选择算符matchLabels常用matchExpressions标签选择算符matchLabels匹配标签。用于匹配 Pod 的标签它指定了 ReplicaSet 应该管理哪些 Pod。matchLabels的键值对必须与Pod 的metadata.labels完全一致才能匹配不然的话启动会报错。匹配成功的 Pod 会被这个 ReplicaSet 管理参考上面的RS实验selector: matchLabels: app: rs-demo ver v1 表示ReplicaSet 只会管理 同时带有 app: rs-demo 和 verv1 这两个标签的 PodmatchExpressions匹配运算符在matchLabels基础上提供了多种选择目前支持的操作符有以下四个1、In标签的值必须与列表中至少一个值匹配apiVersion: apps/v1 kind: ReplicaSet metadata: name: rs-demo-matchlabels spec: replicas: 2 selector: matchExpressions: - key: study # 定义标签键 operator: In # 匹配操作符为 In表示匹配该键值对中的任意值 values: - hahaha - hehehe - hihihi template: metadata: labels: study: hehehe #标签值在上面标签算符值的列表中可以是values值中的任意一个 spec: containers: - name: rs-demo-matchExpressions-container image: swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/busybox:1.28 imagePullPolicy: IfNotPresent command: [sh,-c,sleep 3600]标签修改后这个pod不属于rs控制了所以根据清单预期立马新建了一个如果改成hihihi的话这个pod依然在标签算符的列表值内依旧属于rs控制。这就是在列表的含义2、NotIn标签的值不能与列表中任何一个值匹配不常用apiVersion: apps/v1 kind: ReplicaSet metadata: name: rs-demo-matchlabels spec: replicas: 2 selector: matchExpressions: - key: study # 定义标签键 operator: NotIn # 匹配操作符为 NotIn表示不能匹配到列表中的任意值 values: - hahaha - hehehe - hihihi template: metadata: labels: study: hohoho #标签值在上面标签算符值的列表中匹配的值不能在values值的列表中 spec: containers: - name: rs-demo-matchExpressions-container image: swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/busybox:1.28 imagePullPolicy: IfNotPresent command: [sh,-c,sleep 3600]如果将pod模板中的标签改成列表中的任意值会得到如下报错意思是选择器和模板中标签不匹配3、Exists只要资源包含该标签键即可不关心具体的值apiVersion: apps/v1 kind: ReplicaSet metadata: name: rs-demo-matchexpressions-exists spec: replicas: 2 selector: matchExpressions: - key: study # 匹配标签的键是study。 operator: Exists # 使用操作符 Exists表示选择所有带有study键的 Pod无论值是什么。 template: metadata: labels: study: fafafa spec: containers: - name: rs-demo-matchexpressions-container image: swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/busybox:1.28 imagePullPolicy: IfNotPresent command: [sh,-c,sleep 3600]#修改标签键需要添加新的键值在删除旧的目前本人只知道这个方法 kubectl lable pod podName keyvalues oldKey- --overwrite修改标签键后再看看pod状态就会发现控制器新增了一个pod原本的pod由于标签键修改已经不属于控制器控制了现在有个疑问如果有很多相同的标签键值pod那为什么其他pod的没有加入到我们的控制器中因为k8s中有个机制当前的pod对象是基于哪个控制器创建的也就是它的父亲是谁只有父亲是我的时候才开始去匹配标签并且标签要符合我的要求。两点都达到了才是我的防止把一些不相干的pod加入进来4、DoesNotExist资源不能包含该标签键不常用apiVersion: apps/v1 kind: ReplicaSet metadata: name: rs-demo-matchexpressions-doesnotexists spec: replicas: 2 selector: matchExpressions: - key: study #定义标签键 operator: DoesNotExist #匹配操作符为 DoesNotExist表示不能匹配到定义的标签键 template: metadata: labels: app: hihihi spec: containers: - name: rs-demo-matchexpressions-container image: swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/busybox:1.28 imagePullPolicy: IfNotPresent command: [sh,-c,sleep 3600]如果将pod模板中的标签键改成匹配算符定义的键会得到如下报错意思是选择器和模板中标签不匹配关于四个匹配算符只用1和3是天天用的2和4较为罕见一般都是处于比较复杂的生产环境配合matchLabels来使用建议各位同志只熟悉1和3比较好4、Deployment重点先说明一点Deployment实际上是通过创建RS控制器继而创建Pod。就是说Deployment实际上是RS的控制器RS才是Pod的控制器。这个机制就是为了稍后要说的更新策略而设计的Deploymentdeploy为pod和ReplicaSet提供了一个声明式定义declarative方法用来替代以前的ReplicationController来方便的管理应用解释下什么是声明式声明式Declarative 是通过资源清单YAML/JSON 配置文件 来描述期望的最终状态然后 Kubernetes 根据这些文件自动管理和调节资源的实际状态使其与期望状态一致。就是告诉系统你想要什么命令式Imperative 是通过直接的命令行命令来操作资源指定你要执行的具体操作如创建、删除、更新并且这些操作是一步一步执行的通常是一次性任务。就是告诉系统做什么这两个概念过于抽象同志们初学肯定会懵圈不要紧只要继续下去肯定会理解本人就是例子在介绍一下Deployment的应用场景Deployment的典型应用场景包括以下四种几个应用场景都会通过实验来进行演示定义Deployment来创建pod和rs滚动升级和回滚应用扩容和缩容暂停和继续Deployment的升级和回滚Deployment更新策略更新策略分为两种RollingUpdate滚动更新最常见的更新策略允许应用逐步更新避免了服务中断保持了较高的可用性。在 Deployment 中滚动更新通过逐步替换旧的 Pod 来实现版本更新同时保证在整个更新过程中始终有可用的 Pod 处理流量可以指定maxUnavailable和maxSurge来控制滚动更新过程简单来说就是滚动更新时deploy会创建一个新的rs等下的实验速度够快的话进行rs控制器的查询是可以看到更新过程中有两个rs出现的等更新过程结束旧的rs被删除针对滚动升级做个实验用nginx镜像比较方便。先用写个dockerfile封装一下让两个nginx镜像主页分为v1和v21、自己写两个index.html文件内容分别为v1和v2 2、写dockerfile进行封装 vim Dockerfile FROM swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/nginx:1.27.0 COPY index.html /usr/share/nginx/html/index.html EXPOSE 80 CMD [nginx, -g, daemon off;] 3、别忘了封装的镜像和文件要在同一目录下 docker build -t my-nginx:v1 . docker build -t my-nginx:v2 . 4、将封装的镜像导出至本地 docker save -o 本地路径 镜像名称 5、将封装的nginx导入到每个node节点中不然k8s调度大概率会出现无法pull镜像问题 docker load -i 镜像名称apiVersion: apps/v1 kind: Deployment metadata: name: deploy-demo spec: replicas: 10 selector: matchLabels: app: deploy template: metadata: labels: app: deploy spec: containers: - name: deploy-demo-container image: my-nginx:v1 imagePullPolicy: IfNotPresent可以看到访问任意一个pod都是没问题的这时修改将清单镜像修改为v2版本apply后立刻观察pod状态这时候可以看到新建pod删除pod可老的pod三种状态在一起可以直观的看到滚动更新特性它不是全部删除在进行重建而是删除一部分新建一部分逐渐替换直至全部pod更新至最新。或者可以这样用这个命令这个命令简单来说是创建一个负载均衡不详细说下一章会学到#svc会自动将和自己名称一样的pod标签进行匹配归拢至一个负载均衡 kubectl create svc clusterip pod的标签值 --tcp80:80curl循环访问这个svc的ip将清单中的v1版本镜像修改为v2版本apply应用持续观察访问状况本来一直访问的是v1滚动更新后导致部分pod被删掉所以出现了访问报错部分更新成功所以出现了v2。这就是滚动更新同志们做实验的时候应该会出现循环访问卡住的情况这是因为访问pod的请求已经被pod接收但是要回复的时候pod被删除了导致收不到回复所以卡住了小问题最大不可用maxUnavailable.spec.strategy.rollingUpdate.maxUnavailable是一个可选字段 用来指定更新过程中不可用的 Pod 的个数上限。这个不可用指的是滚动更新时最多几个不可用。该值可以是绝对数字例如5也可以是所需 Pod 的百分比例如10%。百分比值会转换成绝对数并去除小数部分。 如果maxSurge为 0则此值不能为 0。 不写这个字段的话默认值为 25%。在1.16版本以前这个数值默认是1不是百分比例如当此值设置为 30% 时滚动更新开始时会立即将旧 ReplicaSet 缩容到期望 Pod 个数的70%。 新 Pod 准备就绪后可以继续缩容旧有的 ReplicaSet然后对新的 ReplicaSet 扩容 确保在更新期间可用的 Pod 总数在任何时候都至少为所需的 Pod 个数的 70%。最大峰值maxSurge.spec.strategy.rollingUpdate.maxSurge是一个可选字段用来指定可以创建的超出期望 Pod 个数的 Pod 数量。此值可以是绝对数例如5或所需 Pod 的百分比例如10%。 如果MaxUnavailable为 0则此值不能为 0。百分比值会通过向上取整转换为绝对数。 此字段的默认值为 25%。在1.16版本以前这个数值默认是1不是百分比例如当此值为 30% 时启动滚动更新后会立即对新的 ReplicaSet 扩容同时保证新旧 Pod 的总数不超过所需 Pod 总数的 130%。一旦旧 Pod 被杀死新的 ReplicaSet 可以进一步扩容 同时确保更新期间的任何时候运行中的 Pod 总数最多为所需 Pod 总数的 130%。apiVersion: apps/v1 kind: Deployment metadata: name: deploy-demo spec: replicas: 10 selector: matchLabels: app: deploy strategy: type: RollingUpdate #可以省略因为滚动更新是默认字段因为是做实验所以加上了 rollingUpdate: maxUnavailable: 1 maxSurge: 1 template: metadata: labels: app: deploy spec: containers: - name: deploy-demo-container image: my-nginx:v2 imagePullPolicy: IfNotPresent更新可以多弄些pod副本比如20个很轻松就可以看出来区别Recreate在 Kubernetes 中Recreate 更新策略是一种特殊的Deployment 策略与默认的滚动更新策略不同它的行为是先删除所有旧 Pod再创建新 Pod。这种策略在更新过程中会导致服务中断但适用于某些对高可用性要求不高或无法并存旧版本和新版本的场景apiVersion: apps/v1 kind: Deployment metadata: name: deploy-demo spec: replicas: 10 selector: matchLabels: app: deploy strategy: type: Recreate #这个不能省略了 metadata: labels: app: deploy spec: containers: - name: deploy-demo-container image: my-nginx:v2 imagePullPolicy: IfNotPresent金丝雀部署首先说明这是一种理念不是实际的操作。金丝雀Canary Release是一种渐进式的应用发布方式通常与滚动更新RollingUpdate结合使用和国内常说的灰度发布是一种策略通常用于在生产环境中逐步推送新版本以便更好地检测和控制风险。通过金丝雀发布只有一小部分用户会接触到新版本而大部分用户依然使用旧版本直到确认新版本没有问题为止之后再逐步将新版本推广到更多用户。这种方法起源于矿井矿工在井下放置“金丝雀”小鸟以观测环境是否有危险。象征着对环境的“早期预警”因此得名apiVersion: apps/v1 kind: Deployment metadata: name: deployment-demo labels: app: deployment-demo spec: replicas: 10 selector: matchLabels: app: deployment-demo template: metadata: labels: app: deployment-demo spec: containers: - name: deployment-demo-container image: nginx:v1 imagePullPolicy: IfNotPresent#将资源对象输出为yaml显示 kubectl get resourceKind resourceName -o yaml创建对象后可以用命令看下默认峰值就是这两个maxUnavailablemaxSurge可以看到默认值是不是想我说的那样kubectl patch deploy deployment-demo -p {spec:{strategy:{rollingUpdate:{maxSurge:0,maxUnavailable:1}}}}再用一条命令触发金丝雀部署kubectl rollout pause deploy deployment-demo该命令用于暂停deployment-demoDeployment 的滚动更新操作也就是说我执行了更新操作之后立马暂停滚动更新。像这个更新镜像命令kubectl patch deploy deployment-demo -p {spec:{template:{spec:{containers:[{name:deployment-demo-container,image:nginx:v2}]}}}} kubectl rollout pause deploy deployment-demo kubectl rollout pause deploy deployment-name #暂停滚动更新 kubectl rollout resume deploy deployment-name #恢复滚动更新通过下图pod创建时间可以看到滚动在一开是就被暂停了访问记录也是有v1版本和v2版本恢复滚动更新更新成功现在10个pod都更新为了ngxin:v2但是这个版本有问题需要回滚回v1。前文提过deployment控制器实际上是控制replicaSet进行pod的管理。从创建时间看第二个三分钟的明显是滚动更新时候创建的新rs并且可以看到更新之后旧的rs是依旧保留的用命令回滚后再看下kubectl rollout undo deploy/deployment-demo #回滚版本可以看到回滚过程在做个实验再从v1升级到v2然后升级到v3。这时要回滚到v1版本该怎么做连用两次kubectl rollout undo deploy/deployment-demo吗错了v3回滚一次后回到v2此时v2的上个版本已经变成了v3在回滚一次后还会回到v3。想要回滚到v1该怎么做先列举几个命令为回滚v1版本做准备kubectl rollout status deployment deployment-demo #查看 Deployment或其他资源类型如 StatefulSet、DaemonSet的当前滚动更新状态。这个命令可以帮助你查看滚动更新是否成功、是否完成或者是否遇到问题。可以配合回滚命令使用打印回滚过程 可配合echo $?使用如果回滚成功echo出来的为0kubectl rollout history deployment deployment-demo #查看Deployment或其他资源如 StatefulSet的历史版本信息。它允许你查看某个资源的滚动更新历史特别是用于查看更新版本的详情REVISION表示版本号滚动更新的每次更新都会增加版本号。CHANGE-CAUSE表示变更的原因。但是为什么变更原因是none还记得上面kubectl create -f xxx.yaml --record命令吗就是--record选项来记录了。之前更新或回滚都没有加这个长选项从头来一遍试试先删除deploy控制器在创建再滚动可以看到更新记录。但是这个命令有缺点假设你在第三次更新的时候忘了加这个选项那么第三次的更新记录会直接复制上一次的记录。这个命令使用时候会提示被k8s弃用并且在未来版本被移出。不过官方应该还没开发出更好的目前1.31版本还是健在好开始回到回滚v1的实验中在rollout history中可以看到记录了版本这时我们回滚要指定版本kubectl rollout undo deploy deployment-demo --to-revision1 #--to-revision1指定回滚版本版本号从1开始但是随着回滚次数版本号会发生改变Deployment清理策略在滚动更新和回滚的时候replieset全部都保存在了etcd里。可以在 Deployment 中设置.spec.revisionHistoryLimit字段以指定保留此 Deployment 的多少个旧有 ReplicaSet也就是历史版本。其余的 ReplicaSet 将在后台被垃圾回收。 默认情况下此值为 10。如果将该项设置为0deployment就不允许回滚了。试一下可以看到更新了之后旧的rs就没了。因为他不会在保留rs的历史记录了那么etcd的资源消耗也就会减少了Deployment更简单的更新策略相对于前面的滚动更新其实可以用备份清单的方式来实现更新和回滚的记录。假设我们从v1升级到v2这时可以将v1的清单备份一下然后在进行修改kubectl apply -f来应用的这么一种方式再从v2升级到v3继续将v2备份然后修改。这样历史版本就都保存下来了而且前面那么多滚动更新的方法他一切的信息都保存在了etcd里面一旦更新的版本多了etcd里面杂而乱。对比下用清单保存的方式更简洁。而且一个清单的大小也是几kb的可以保存无数份。当然这只是一种思想需要自己选择5、DaemonSetDaemonSet确保全部或者一些Node上运行一个pod副本。当有Node加入集群时也会为他们新增一个pod。当有Node从进群移除时这些pod也会被回收。删除DaemonSet将会删除它创建的所有podDaemonSet 的一些典型用法在每个节点上运行集群守护进程如gluserd、ceph在每个节点上运行日志收集守护进程如fluentd、logstash在每个节点上运行监控守护进程如prometheusapiVersion: apps/v1 kind: DaemonSet metadata: name: daemonset-demo labels: app: daemonset-demo spec: selector: matchLabels: app: daemonset-demo template: metadata: labels: app: daemonset-demo spec: containers: - name: daemonset-demo-contaienr image: nginx:v1启动资源对象后get po一下会发现有两个pod。并且清单中没有replicas参数因为ds控制器没有这个参数它会自动匹配node节点来控制pod数量前面说了每个节点都会存在一个pod但是为什么master节点没有因为master节点存在一个叫做污点的机制这个后面学习调度器会学到。kubectl describe node k8s-master查下主节点6、Job负责批处理任务即仅执行一次的任务他保证批处理任务的一个或多个pod成功结束特殊说明spec.template格式同podRestartPolicy仅支持Never或OnFailure单个pod时默认pod成功运行后job即结束.spec.completions标志job结束需要成功运行的pod个数默认为1。就是控制整个 Job 需要多少个 Pod 成功完成Job 才算完全结束.spec.parallelism标志并行运行的pod个数默认为1。就是控制在同一时间有多少个 Pod 一起工作.spec.activeDeadlineSeconds标志失败pod的重试最大时间超过这个时间不会继续重试apiVersion: batch/v1 kind: Job metadata: name: timestamp-job spec: completions: 10 parallelism: 5 template: metadata: name: timestamp spec: containers: - name: timestamp image: busybox command: [sh, -c, echo Current timestamp: $(date)] restartPolicy: Never backoffLimit: 47、CoronJobCronJob管理基于时间的Job即在给定时间点只运行一次周期性的在给定时间点运行使用条件当前使用的k8s集群版本大于等于1.8典型的用法如下在给定的时间点调度job运行创建周期性运行的job例如数据库备份、发送邮件CronJob关键字.spec.schedule:调度必须字段指定任务运行周期格式同Cron.spec.jobTemplatejob模板必须字段指定需要运行的任务格式同Job.spec。startingDeadlineSeconds启动job的期限秒级别该字段是可选的。如果因为任何原因因而错过了被调度的时间那么错过执行时间的job将被认为是失败的。如果没有指定则没有期限.spec.concurrencyPolicy并发策略该字段可选。它指定了如何被CronJob创建的job的并发执行。只允许指定下面策略中的一种Allow默认允许并发运行jobForbid禁止并发运行如果前一个还没有完成则直接跳过下一个Replace取消当前正在运行的job用一个新的来替换注意当前策略只能应用于同一个CronJob创建的job。如果存在多个CronJob他们创建的Job之间总是允许并发运行.spec.suspend挂起该字段可选。如果设置为true后续所有执行都会被挂起。他对已经开始执行的job不起作用。默认值为false.spec.successfulJobsHistoryLimit和.spec.failedJobsHistoryLimit历史限制可选字段。他们指定了可以保留多少完成和失败的job。默认情况下他们分别设置为3和1.设置限制的值为0.相关类型的job完成后将不会被保留apiVersion: batch/v1 # 使用的 API 版本batch/v1 用于 CronJob 和 Job 资源 kind: CronJob # 指定资源类型为 CronJob表示这是一个定时任务 metadata: name: cronjob-demo # CronJob 的名称便于标识和管理 spec: schedule: */1 * * * * # 调度表达式表示每分钟执行一次。遵循 Cron 表达式的格式分钟、小时、日、月、星期 jobTemplate: # CronJob 执行的任务模板定义了实际的 Job 配置 spec: template: # Job 的 Pod 模板CronJob 根据这个模板创建 Pod spec: containers: - name: cronjob-demo-container # 容器的名称便于管理和查看容器的日志 image: busybox # 使用的容器镜像这里是 busybox常用于测试和简单任务 args: # 容器启动时传递的命令行参数 - /bin/sh # 执行的命令/bin/sh 用于启动一个 shell - -c # 参数 -c 用来让 shell 执行后面的命令 - date ;echo Hello from the kubernetes cluster # 运行的命令输出当前日期和一条消息 restartPolicy: OnFailure # 重启策略。如果容器执行失败非 0 退出码Kubernetes 会重启容器如果成功容器不会重启8、StatefulSet这个现阶段无法进行实验因为看不懂后面学到存储章节中的PV/PVC再回来补充