k8s中kubernetes字段含义-创新互联

这篇文章将为大家详细讲解有关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字段含义就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。