k8s中kubernetes字段含义-创新互联
这篇文章将为大家详细讲解有关k8s中kubernetes字段含义,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。
成都创新互联是一家专注于网站设计、网站制作与策划设计,包头网站建设哪家好?成都创新互联做网站,专注于网站建设10年,网设计领域的专业建站公司;建站业务涵盖:包头等地区。包头做网站价格咨询:028-86922220initialDelaySeconds
容器启动后等待多少秒后kubelet 才开始执行探测,默认是 0 秒,最小值是 0。
periodSeconds
执行探测的时间间隔(单位是秒)。默认是 10 秒。最小值是 1
timeoutSeconds
探测超时时间。如果超过这个时间,则认为探测失败。默认值是 1 秒。最小值是 1。
successThreshold
探测器在失败后,被视为成功的最小连续成功数。默认值是 1。 存活探测的这个值必须是 1。最小值是 1
failureThreshold
探测失败时的重试次数。 当为存活探测时,达到阈值则重启容器。 当为就绪探测时Pod会被打上NotReady的标签。默认值是 3。最小值是 1。
subPath
用来对于一个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
resourceVersion
用于识别该资源内部版本号的字符串,在用于 Watch 操作时,可以避免在 GET 操作和下一次 Watch 操作之间造成的信息不一致,客户端可以用它来判断资源是否改变。该值应该被客户端看作不透明,且不做任何修改就返回给服务端。客户端不应该假定版本信息具有跨命名空间、跨不同资源类别、跨不同服务器的含义。
generation
terminationGracePeriodSeconds
K8S滚动升级的步骤:
- K8S首先启动新的POD
- K8S等待新的POD进入Ready状态
- K8S创建Endpoint,将新的POD纳入负载均衡
- K8S移除与老POD相关的Endpoint,并且将老POD状态设置为Terminating,此时将不会有新的请求到达老POD
- 同时 K8S 会给老POD发送SIGTERM信号,并且等待 terminationGracePeriodSeconds 这么长的时间。(默认为30秒)
- 超过terminationGracePeriodSeconds等待时间后, K8S 会强制结束老POD
tier
labels:
component: kube-controller-manager
tier: control-plane"tier" : "frontend", "tier" : "backend", "tier" : "cache"
tier意思是类似电影院阶梯座位那种的一排,有等级的含义在里面。
可以简单里面为架构里面的分层。一般设为前端,后端,缓存,控制平面这些值
blockOwnerDeletion
根对象是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不会被级联删除,会成为孤儿。
podManagementPolicy
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
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
lastTransitionTime
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
progressDeadlineSeconds
Deployment在生命周期中有多种状态。在创建一个新的ReplicaSet的时候它可以是 progressing 状态, complete 状态,或者fail to progress状态。
Progressing Deployment
Kubernetes将执行过下列任务之一的Deployment标记为progressing状态:
- Deployment正在创建新的ReplicaSet过程中。
- Deployment正在扩容一个已有的ReplicaSet。
- Deployment正在缩容一个已有的ReplicaSet。
- 有新的可用的pod出现。
你可以使用kubectl roullout status命令监控Deployment的进度。
Complete Deployment
Kubernetes将包括以下特性的Deployment标记为complete状态:
- Deployment最小可用。最小可用意味着Deployment的可用replica个数等于或者超过Deployment策略中的期望个数。
- 所有与该Deployment相关的replica都被更新到了你指定版本,也就说更新完成。
- 该Deployment中没有旧的Pod存在。
你可以用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的时候可能卡住,用于也不会完成。这可能是因为以下几个因素引起的:
- 无效的引用
- 不可读的probe failure
- 镜像拉取错误
- 权限不够
- 范围限制
- 程序运行时配置错误
探测这种情况的一种方式是,在你的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,它包括如下属性:
- Type=Progressing
- Status=False
- Reason=ProgressDeadlineExceeded
注意: kubernetes除了报告Reason=ProgressDeadlineExceeded状态信息外不会对卡住的Deployment做任何操作。更高层次的协调器可以利用它并采取相应行动,例如,回滚Deployment到之前的版本。
注意: 如果你暂停了一个Deployment,在暂停的这段时间内kubernetnes不会检查你指定的deadline。你可以在Deployment的rollout途中安全的暂停它,然后再恢复它,这不会触发超过deadline的状态。
revisionHistoryLimit
指定保留多少旧的ReplicaSet。 余下的将在后台被当作垃圾收集。默认的,所有的revision历史就都会被保留。在未来的版本中,将会更改为2。
注意: 将该值设置为0,将导致所有的Deployment历史记录都会被清除,该Deploynent就无法再回退了。
minReadySeconds
新创建的Pod状态为Ready持续的时间至少为.spec.minReadySeconds才认为Pod Available(Ready)。
activeDeadlineSeconds
当一个 Job 的 Pod 运行结束后,它会进入 Completed 状态。但是,如果这个 Pod 因为某种原因一直不肯结束呢?
在 Job 的 API 对象里,有一个 spec.activeDeadlineSeconds 字段可以设置最长运行时间,比如:
spec:
backoffLimit: 5
activeDeadlineSeconds: 100
一旦运行超过了 100 s,这个 Job 的所有 Pod 都会被终止。并且,你可以在 Pod 的状态里看到终止的原因是 reason: DeadlineExceeded。
dnsPolicy
hostNetwork
priority
securityContext
关于k8s中kubernetes字段含义就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
网站栏目:k8s中kubernetes字段含义-创新互联
分享链接:http://myzitong.com/article/dhhogh.html