温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

k8s中kubernetes字段含义

发布时间:2020-11-20 16:20:52 来源:亿速云 阅读:1634 作者:小新 栏目:系统运维

这篇文章将为大家详细讲解有关k8s中kubernetes字段含义,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。

initialDelaySeconds

容器启动后等待多少秒后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滚动升级的步骤:

  1. K8S首先启动新的POD
  2. K8S等待新的POD进入Ready状态
  3. K8S创建Endpoint,将新的POD纳入负载均衡
  4. K8S移除与老POD相关的Endpoint,并且将老POD状态设置为Terminating,此时将不会有新的请求到达老POD
  5. 同时 K8S 会给老POD发送SIGTERM信号,并且等待 terminationGracePeriodSeconds 这么长的时间。(默认为30秒)
  6. 超过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字段含义就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI