扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
这篇文章将为大家详细讲解有关k8s中kubernetes字段含义，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
容器启动后等待多少秒后kubelet 才开始执行探测，默认是 0 秒，最小值是 0。
执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1
探测超时时间。如果超过这个时间，则认为探测失败。默认值是 1 秒。最小值是 1。
探测器在失败后，被视为成功的最小连续成功数。默认值是 1。 存活探测的这个值必须是 1。最小值是 1
探测失败时的重试次数。 当为存活探测时，达到阈值则重启容器。 当为就绪探测时Pod会被打上NotReady的标签。默认值是 3。最小值是 1。
用来对于一个Volume分别给多个容器使用时，会根据subPath给出的key创建目录。在这个例子中site-data这个Volume在分别个mysql和php容器使用时，html的内容映射在site-data卷的html子目录，而数据库则保存在site-data卷的mysql目录。
apiVersion: v1
kind: Pod
metadata:
name: my-lamp-site
spec:
containers:
- name: mysql
image: mysql
volumeMounts:
- mountPath: /var/lib/mysql
name: site-data
subPath: mysql
- name: php
image: php
volumeMounts:
- mountPath: /var/www/html
name: site-data
subPath: html
volumes:
- name: site-data
persistentVolumeClaim:
claimName: my-lamp-site-data
用于识别该资源内部版本号的字符串，在用于 Watch 操作时，可以避免在 GET 操作和下一次 Watch 操作之间造成的信息不一致，客户端可以用它来判断资源是否改变。该值应该被客户端看作不透明，且不做任何修改就返回给服务端。客户端不应该假定版本信息具有跨命名空间、跨不同资源类别、跨不同服务器的含义。
K8S滚动升级的步骤:
- K8S首先启动新的POD
- K8S等待新的POD进入Ready状态
- K8S创建Endpoint，将新的POD纳入负载均衡
- K8S移除与老POD相关的Endpoint，并且将老POD状态设置为Terminating，此时将不会有新的请求到达老POD
- 同时 K8S 会给老POD发送SIGTERM信号，并且等待 terminationGracePeriodSeconds 这么长的时间。(默认为30秒)
- 超过terminationGracePeriodSeconds等待时间后， K8S 会强制结束老POD
labels:
component: kube-controller-manager
tier: control-plane"tier" : "frontend", "tier" : "backend", "tier" : "cache"
tier意思是类似电影院阶梯座位那种的一排，有等级的含义在里面。
可以简单里面为架构里面的分层。一般设为前端，后端，缓存，控制平面这些值
根对象是rs，从对象是pod。
如果在pod的ownerReferences字段下由设置了blockOwnerDeletion: true，那么在删除rs的时候，会先等pod删除完后，在删除rs。
在以前的博文中介绍过如何配置kubelet，按策略删除无用image、正常或者异常终止不会再启动的container，以节省资源。kubelet回收的对象在容器层面。那么kubernetes层面的对象，比如pod、ReplicaSet、Replication Controller、Deployment、StatefulSet、DaemonSet等类型的对象，垃圾回收又是如何呢？
实际上，按理说以上的kubernetes对象并不会产生垃圾，对象一直都存在，除非用户或者某种控制器将对象删除。这里称为"Garbage Collection"不太准确，实际上它想讲的是在执行删除操作时如何控制对象之间的依赖关系。比如，Deployment对象创建ReplicaSet对象，ReplicaSet对象又创建pod对象，那么在删除Deployment时，是否需要删除与之相依赖的ReplicaSet与pod呢？
从对象与根对象（Owners and dependents）
某些kubernetes对象是其它对象的owner。比如ReplicaSet对象就是其所管理的pod对象的owner，本文称这类对象为“根对象”。而被管理的pod对ReplicaSet存在dependent，pod对象通过metadata.ownerReferences字段指向其依赖的对象，本文称这类对象为“从对象”。在kubernetes1.8中，ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job and CronJob自动向其创建、收养的对象添加metadata.ownerReferences字段的值，当然也可以手动设置。
如何控制垃圾回收删除从对象？
当删除一个对象时，可以控制以何种方式删除其从对象，自动删除从对象称为级联删除(cascading deletion)。有background与foreground两种方式。也可以只删除根对象不删除从对象。
1.前台级联删除
前台级联删除时，根对象首先进入"deletion in progress"状态，在"deletion in progress"状态下，存在如下事实：
如果通过REST API访问根对象，仍然可见。
根对象的deletionTimestamp被设置。
根对象元数据metadata.finalizers包含"foregroundDeletion"。
一旦根对象的状态被设置成"deletion in progress"，垃圾回收器开始启动对从对象的删除。如果从对象的object有
“ownerReference.blockOwnerDeletion=true”属性，那么垃圾回收器必需等到此类从对象被删除完成以后，才可以删除根对象。否则垃圾回收器启动对从对象的删除后立即删除根对象。
“ownerReference.blockOwnerDeletion=true”会延迟根对象的删除。在kubernetes1.7版本中增加了一个admission controller，它根据根对象访问权限，对将ownerReference.blockOwnerDeletion设置成true的操作进行访问控制，防止未经授权的用户将
ownerReference.blockOwnerDeletion的值设置成true，从而延迟根对象的删除。
如果从对象的ownerReferences由某种控制器设置，那么用户好不要手动修改其值。
2.后台级联删除
后台级联删除时，kubernetes立即删除根对象并返回。垃圾回收器在后台删除其从对象。
3.不删除从对象
只删除根对象不删除从对象，这种方式称为“Orphan”，保留下来的从对象变成了“孤儿”。
在具体操作时设置删除策略
在执行具体的操作请求时，通过设置删除请求中的"propagationPolicy"字段为 “Orphan”, “Foreground”, or “Background”中的一种，选择上述三种删除策略中的一种。
在kubernetes1.9以前，对大部分控制器的删除，默认策略是"Orphan"（注意本段中说的默认值指REST API的默认行为，不是kubectl命令），包含ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and Deployment，也就是在删除根对象时不删除从对象。并且当apiVersion是extensions/v1beta1, apps/v1beta1, and apps/v1beta2时，除非特别指定，默认删除策略仍然是"Orphan"。在kubernetes1.9版本中，所有类型的对象，在app/v1版本的apiVersion中，默认从对象删除。
后台级联删除示例：
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
-H "Content-Type: application/json"
注意上例中kubectl充当的是proxy角色，直接调用REST API执行删除操作，注意其propagationPolicy的取值。
前台级联删除示例：
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-H "Content-Type: application/json"
不删除从对象示例：
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-H "Content-Type: application/json"
kubectl命令也支持级联删除操作。在执行kubectl命令时指定"--cascade"选项，其值为true时删除从对象，为false不删除从对象，默认值为true。 示例如下：
kubectl delete replicaset my-repset --cascade=false
当--cascade为true时，kubectl采用的是前台级联删除还是后台级联删除，文档中没有讲。
级联删除Deployment时的注意点
当级联删除Deployment时，其删除请求中的propagationPolicy必需设定成Foreground。否则Deployment创建的ReplicaSet会被级联删除，但是ReplicaSet创建的pod不会被级联删除，会成为孤儿。
stattefulset的pod管理策略，有两个可选值，默认是OrderedReady，另一个是Parallel。1.7中引入。
顾名思义，OrderedReady：增删改的时候会按顺序来。比如顺序创建：web-0 Pod 处于 Running和Ready 状态后 web-1 Pod 才会被启动。
删除事按照与 Pod 序号索引相反的顺序每次删除一个 Pod。在删除下一个 Pod 前会等待上一个被完全关闭。
Parallel： 不按顺序，总是并行的启动或终止所有 Pod。在启动或终止另一个 Pod 前，不必等待这些 Pod 变成 Running 和 Ready 或者完全终止状态。
tolerationSeconds 是当 pod 需要被驱逐时，可以继续在 node 上运行的时间。
tolerations:
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
status:
conditions:
- lastProbeTime: null
lastTransitionTime: "2019-06-05T11:15:25Z"
status: "True"
type: Initialized
- lastProbeTime: null
lastTransitionTime: "2019-06-05T11:15:28Z"
status: "True"
type: Ready
- lastProbeTime: null
lastTransitionTime: "2019-06-05T11:15:28Z"
status: "True"
type: ContainersReady
- lastProbeTime: null
lastTransitionTime: "2019-06-05T11:15:25Z"
status: "True"
type: PodScheduled
Deployment在生命周期中有多种状态。在创建一个新的ReplicaSet的时候它可以是 progressing 状态， complete 状态，或者fail to progress状态。
Progressing Deployment
Kubernetes将执行过下列任务之一的Deployment标记为progressing状态：
你可以使用kubectl roullout status命令监控Deployment的进度。
Complete Deployment
Kubernetes将包括以下特性的Deployment标记为complete状态：
你可以用kubectl rollout status命令查看Deployment是否完成。如果rollout成功完成，kubectl rollout status将返回一个0值的Exit Code。
$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $?
0
Failed Deployment
你的Deployment在尝试部署新的ReplicaSet的时候可能卡住，用于也不会完成。这可能是因为以下几个因素引起的：
探测这种情况的一种方式是，在你的Deployment spec中指定spec.progressDeadlineSeconds。spec.progressDeadlineSeconds表示Deployment controller等待多少秒才能确定（通过Deployment status）Deployment进程是卡住的。
下面的kubectl命令设置progressDeadlineSeconds 使controller在Deployment在进度卡住10分钟后报告：
$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
"nginx-deployment" patched
Once the deadline has been exceeded, the Deployment controller adds a with the following attributes to the Deployment’s
当超过截止时间后，Deployment controller会在Deployment的 status.conditions中增加一条DeploymentCondition，它包括如下属性：
注意： kubernetes除了报告Reason=ProgressDeadlineExceeded状态信息外不会对卡住的Deployment做任何操作。更高层次的协调器可以利用它并采取相应行动，例如，回滚Deployment到之前的版本。
注意： 如果你暂停了一个Deployment，在暂停的这段时间内kubernetnes不会检查你指定的deadline。你可以在Deployment的rollout途中安全的暂停它，然后再恢复它，这不会触发超过deadline的状态。
指定保留多少旧的ReplicaSet。 余下的将在后台被当作垃圾收集。默认的，所有的revision历史就都会被保留。在未来的版本中，将会更改为2。
注意： 将该值设置为0，将导致所有的Deployment历史记录都会被清除，该Deploynent就无法再回退了。
新创建的Pod状态为Ready持续的时间至少为.spec.minReadySeconds才认为Pod Available(Ready)。
当一个 Job 的 Pod 运行结束后，它会进入 Completed 状态。但是，如果这个 Pod 因为某种原因一直不肯结束呢？
在 Job 的 API 对象里，有一个 spec.activeDeadlineSeconds 字段可以设置最长运行时间，比如：
spec:
backoffLimit: 5
activeDeadlineSeconds: 100
一旦运行超过了 100 s，这个 Job 的所有 Pod 都会被终止。并且，你可以在 Pod 的状态里看到终止的原因是 reason: DeadlineExceeded。
关于k8s中kubernetes字段含义就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
微信二维码
移动版官网