Kubernetes 1.8中的Pod怎么创建和应用

发布时间:2021-12-20 10:24:14 作者:iii
来源:亿速云 阅读:160

本篇内容介绍了“Kubernetes 1.8中的Pod怎么创建和应用”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!


Kubernetes 1.8中对scheduler的更新

什么是抢占式调度?
在Kubernetes 1.8版本之前,当集群资源不足时,用户提交新的Pod创建请求后,该Pod会处于Pending状态,直到集群中有某个Node有足够Available Resources时才会调度成功。 从Kubernetes 1.8版本开始,这种情况下scheduler会根据Pod's Priority进行调度,调度时会选择最合适的Node并把该Node上lower Priority的Pods进行Premmption(Eviction)以释放资源供该higher Priority Pod使用。这种调度时考虑Pod Priority的方式就是Kubernetes中的抢占式调度,简称为Preemption。

如何开启或关闭该Feature

在Kubernetes 1.8中,Pod Priority和Preemption作为Alpha特性,默认是disable的,如果你要使用该特性,需要给apiserver和scheduler添加如下参数并重启:

反过来,把上面的参数删除并重启,即可disable。

有个问题:如果我开启了这个特性,并且创建了一些PriorityClass,然后还给某些Pod使用了,这个时候我再disable掉这个特性,会不会有问题?

答案是否定的!disable后,那些之前设置的Pod Priority field还会继续存在,但是并没什么用处了,Preemption是关闭的。当然,你也不能给新的Pods引用PriorityClass了。

创建PriorityClass

Enable后,接下来就是创建PriorityClass了:

apiVersion: scheduling.k8s.io/v1alpha1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for XYZ service pods only."

注意:PriorityClass是非namespace隔离的,是global的。因此metadata下面是不能设置namespace field的。

注意:

创建Pod并引用该PriorityClass

接下来,就是创建对应Priority的Pod了:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

如果Pod.spec. priorityClassName中指定的PriorityClass不存在,则Pod会创建失败;
前面也提到,创建Pod的时候Priority Admission Controller会根据PriorityClassName找到对应的PriorityClass,并将其value设置给Pod.spec.priority。

Preemption当前还存在的问题

Taint Nodes by Condition

在Kubernetes 1.8之前,Node Condition是会直接干预调度的,逻辑是是这样的,并且是无法改变的:

Node ConditionScheduler Behavior
MemoryPressureNo new BestEffort pods are scheduled to the node.
DiskPressureNo new pods are scheduled to the node.
- 当Node Condition包含Memory Pressure时,不再允许BestEffort QoS Pods调度到该节点;
- 当Node Condition包含DiskPressure时,不允许任何pods调度到该节点。

从Kubernetes 1.6开始,kubelet和Node Controller支持自动根据Node Condition给Node打上相应的内置Taints,当时这些Taints只是会影响kubelet eviction,而不会影响调度。这有啥不同呢?区别就是,给Node打上Taints对调度来说是软限制,可以通过给pods加上对应的Tolerations就可能强制调度到那个节点。而在1.8之前,Node Condition影响调度是硬限制。

Node Condition和Taints的Map关系如下:

ConditionTypeCondition StatusEffectKey
ReadyTrue-

FalseNoExecutenode.kubernetes.io/notReady

UnknownNoExecutenode.kubernetes.io/unreachable
OutOfDiskTrueNoSchedulenode.kubernetes.io/outOfDisk

False-

Unknown-
MemoryPressureTrueNoSchedulenode.kubernetes.io/memoryPressure

False-

Unknown-
DiskPressureTrueNoSchedulenode.kubernetes.io/diskPressure

False-

Unknown-
NetworkUnavailableTrueNoSchedulenode.kubernetes.io/networkUnavailable

False-

Unknown-

“Kubernetes 1.8中的Pod怎么创建和应用”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站,小编将为大家输出更多高质量的实用文章!

推荐阅读:
  1. kubernetes集群的运行流程介绍
  2. Kubernetes集群的节点和组件

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

kubernetes pod

上一篇:System.out.println(3|9)输出什么

下一篇:Go container包怎么使用

相关阅读

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

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