Loading [MathJax]/jax/output/CommonHTML/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >研发工程师玩转Kubernetes——Node失效后的Pod的调度实验

研发工程师玩转Kubernetes——Node失效后的Pod的调度实验

作者头像
方亮
发布于 2023-06-04 06:24:27
发布于 2023-06-04 06:24:27
21100
代码可运行
举报
文章被收录于专栏:方亮方亮
运行总次数:0
代码可运行

《研发工程师玩转Kubernetes——多Worker Node部署》中,我们创建了Master Node: UbunutA,以及四个Worker Node:UbunutB、UbunutC、UbunutD和UbunutE。本节我们将使用Deployment创建只含有一个nginx的Pod,然后关掉它所在的主机以模拟Node失效,观察kubernetes在这种情况下的表现。

创建Node

我们登录到UbuntuA机器,通过下面的清单文件维持只有一个副本的Pod。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
# nginx_deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx-container
        image: nginx
        ports:
        - containerPort: 80

然后执行

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
kubectl create -f nginx_deployment.yaml

deployment.apps/nginx-deployment created

通过下面的指令,我们可以看到这个Pod所在的Node——在UbuntuE上。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
kubectl get pod -o wide
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
NAME                               READY   STATUS    RESTARTS   AGE     IP           NODE      NOMINATED NODE   READINESS GATES
nginx-deployment-8f788645b-n7s6d   1/1     Running   0          3m51s   10.1.226.1   ubuntue   <none>           <none>

在关闭UbuntuE之前,我们新开两个终端,分别监视Pod和Node的变化

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
kubectl get pod --watch -o wide
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
kubectl get node --watch -o wide

关闭Pod所在主机

登录到UbuntuE上,执行

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
sudo poweroff

查看

等待一段时间,kubernetes察觉到UbuntuE服务器(Node)失效了

但是Pod的状态并没有立即改变,进而也没立即迁移该Pod

Kubernetes 会一直保存着失效节点对应的对象,并持续检查该节点是否已经变得健康。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
kubectl get nodes --show-labels
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
NAME      STATUS     ROLES    AGE   VERSION   LABELS
ubuntuc   Ready      <none>   24h   v1.26.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=ubuntuc,kubernetes.io/os=linux,microk8s.io/cluster=true,node.kubernetes.io/microk8s-worker=microk8s-worker
ubuntue   NotReady   <none>   17h   v1.26.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=ubuntue,kubernetes.io/os=linux,microk8s.io/cluster=true,node.kubernetes.io/microk8s-worker=microk8s-worker
ubuntub   Ready      <none>   24h   v1.26.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=ubuntub,kubernetes.io/os=linux,microk8s.io/cluster=true,node.kubernetes.io/microk8s-worker=microk8s-worker
ubuntua   Ready      <none>   26h   v1.26.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=ubuntua,kubernetes.io/os=linux,microk8s.io/cluster=true,node.kubernetes.io/microk8s-controlplane=microk8s-controlplane
ubuntud   Ready      <none>   24h   v1.26.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=ubuntud,kubernetes.io/os=linux,microk8s.io/cluster=true,node.kubernetes.io/microk8s-worker=microk8s-worker

我们可以手工删除这个失效的Node,这样对应的Pod对象也会被删除,进而触发Deployment新增一个Pod。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
kubectl delete nodes ubuntue

node “ubuntue” deleted

我们再做一次实验,将新Pod所在的Node也关闭,继续查看Pod的变化过程。

可以看到等待了大于5分钟,kubernetes终于发现Pod失效了。这样在其维持着失效的Node UbuntuD情况下,也会发现Pod无效,进而在可用的Node上部署新的Pod。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
 kubectl get pod -o wide
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
NAME                               READY   STATUS        RESTARTS   AGE   IP             NODE      NOMINATED NODE   READINESS GATES
nginx-deployment-8f788645b-nnwfj   1/1     Terminating   0          37m   10.1.202.194   ubuntud   <none>           <none>
nginx-deployment-8f788645b-zw68t   1/1     Running       0          27m   10.1.209.129   ubuntub   <none>           <none>

总体而言,Node失效后,Kubernetes会相对快速的发现其失效,但是会一直维持着这个Node对象,且持续检查它的状态。但是Kubernetes并不会快速发现部署于失效Node上的Pod也失效了,大概要等待5分钟左右才会在其他可用的Node上部署Pod,而原来的Pod将一直处于Terminating状态。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2023-06-01,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
研发工程师玩转Kubernetes——使用污点(taint)驱逐Pod
在《研发工程师玩转Kubernetes——Node失效后恢复的实验》中,有一次Pod被分配到Master Node——UbuntuA上。进一步的实验需要我们关闭其所在的Node,而Master Node又不能关闭,否则我们将无法对Kubernetes进行操作。这个时候我只能使用Pod调度技法来将其从Master Node上驱逐。
方亮
2023/07/10
2390
研发工程师玩转Kubernetes——Node亲和性requiredDuringSchedulingIgnoredDuringExecution几种边界实验
在《研发工程师玩转Kubernetes——使用Node特性定向调度Pod》中,我们提到requiredDuringSchedulingIgnoredDuringExecution只有在规则被满足的时候才能执行调度。本节我们将测试几种边界情况,看看Kubernetes的行为。
方亮
2023/07/10
2280
研发工程师玩转Kubernetes——使用Node特性定向调度Pod
在《研发工程师玩转Kubernetes——使用污点(taint)驱逐Pod》中我们提到亲和性(affinity)中的requiredDuringSchedulingIgnoredDuringExecution,它可以定向调度Pod。本节我们将使用相关特性完成定向调度的介绍。
方亮
2023/07/10
2390
研发工程师玩转Kubernetes——多Worker Node部署
在之前的系列中,我们都是在单Node上“玩转”kubernetes,熟悉了它很多指令和特性。从本节开始,我们开始探索多Worker Node的相关特性。
方亮
2023/06/04
2940
研发工程师玩转Kubernetes——多Worker Node部署
kubernetes系列教程(七)深入玩转pod调度
上一篇文章中kubernetes系列教程(六)kubernetes资源管理和服务质量初步介绍了kubernetes中的resource资源调度和服务质量Qos,介绍了kubernetes中如何定义pod的资源和资源调度,以及设置resource之后的优先级别Qos,接下来介绍kubernetes系列教程pod的调度机制。
HappyLau谈云计算
2019/09/30
3.2K1
kubernetes系列教程(七)深入玩转pod调度
理解 Kubernetes 的亲和性调度
这次给大家介绍下k8s的亲和性调度:nodeSelector、nodeAffinity、podAffinity、Taints以及Tolerations用法。
sunsky
2020/08/20
1.4K0
kubernete编排技术一:pod
在之前的文章《kubernete中的原子调度单位:pod》中提到过,如果把kubernete比作linux操作系统,那pod就是虚拟机,pod里面的容器就是虚拟机上的进程。这个类比可以说非常形象。在Linux上,进程并不是完全独立的,一些进程之间存在着一些关联,比如一个springboot应用和一个日志收集服务。pod正是使用了容器进程之间的这些关系,做的编排。
jinjunzhu
2020/08/20
6900
研发工程师玩转Kubernetes——Node失效后恢复的实验
在《研发工程师玩转Kubernetes——Node失效后的Pod的调度实验》中我们看到Kubernetes会一直等待Node状态恢复。这节我们将做实验,看看Node恢复后Kubernetes的表现。 仍然借助《研发工程师玩转Kubernetes——Node失效后的Pod的调度实验》的实验过程。
方亮
2023/06/04
3320
深入kubernetes调度之NodeSelector
Pod.spec.nodeName用于强制约束将Pod调度到指定的Node节点上,这里说是“调度”,但其实指定了nodeName的Pod会直接跳过Scheduler的调度逻辑,直接写入PodList列表,该匹配规则是强制匹配。
jwangkun
2021/12/23
1.9K0
Kubernetes(k8s)-标签(label)和nodeSelector介绍
作者介绍:简历上没有一个精通的运维工程师。下面的思维导图也是预计更新的内容和当前进度(不定时更新)。
运维小路
2025/02/07
5150
Kubernetes(k8s)-标签(label)和nodeSelector介绍
完事后再聊应用场景,K8S调度实战:Node Affinity
在本次实战中,使用一个名为goweb的测试应用程序来演示Node Affinity的使用。goweb是我用Golang开发的简单Web应用程序,用于测试和验证K8S的调度策略。当然了,你也可以自己开发一个类似的应用,然后使用自己的应用来进行本篇的实战内容。
不背锅运维
2023/06/21
4390
完事后再聊应用场景,K8S调度实战:Node Affinity
Kubernetes之调度篇
这边肯定会有其他场景也会有对pod的调度有特殊要求,这边只是列举了其中几个情况,对于上述遇到的情况我们需要怎么处理,其实k8s给我们提供了丰富的调度策略来满足我们的需求。下面我们来一一说下这些调度策略。
聂伟星
2020/08/25
1.5K0
研发工程师玩转Kubernetes——Pod亲和性调度实验
在《研发工程师玩转Kubernetes——利用Pod反亲和性控制一个Node上只能有一个Pod》一文中我们介绍了Pod的反亲和性应用。本节我们将使用亲和性做几个实验。 nginx Pod在每个Node上只能存在一个;alpine Pod在每个Node上只能存在一个,同时要求该Node上还要有nginx Pod。 实验分为3组:
方亮
2023/07/31
3150
Microk8s 安装 与使用指南
我们已经知道,Kubernetes 是基于容器的应用程序的首选编排平台,可以自动部署和扩展这些应用程序,并简化维护操作。但是,Kubernetes也有其自身的复杂性挑战。那么,企业如何利用容器化来解决物联网的复杂性,而不会最终导致Kubernetes更加复杂呢?
张善友
2022/05/11
4.3K1
Microk8s 安装 与使用指南
Kubernetes应用快速入门
[root@k8s-master ~]# kubectl run nginx-deploy --image=nginx:1.14-alpine --port=80 --replicas=1 Flag --replicas has been deprecated, has no effect and will be removed in the future. # 1.18已经不支持replicas了 pod/nginx-deploy created
行 者
2023/10/19
3210
kubernetes系列教程(十二)详解DaemonSet控制器
上章节中介绍了Deployment,ReplicaSet,ReplicationController等副本控制器的使用和场景,接下来介绍kubernetes系列教程控制器DaemonSet使用。
HappyLau谈云计算
2019/10/31
7.6K0
kubernetes系列教程(十二)详解DaemonSet控制器
研发工程师玩转Kubernetes——通过PV的节点亲和性影响Pod部署
在《研发工程师玩转Kubernetes——PVC通过storageClassName进行延迟绑定》一文中,我们利用Node亲和性,让Pod部署在节点ubuntud上。因为Pod使用的PVC可以部署在节点ubuntuc或者ubuntud上,而系统为了让Pod可以部署成功,则让PVC与Pod亲和的ubuntud上的PV绑定。这样Pod在自身节点亲和性和PVC上都满足了条件。
方亮
2023/08/11
4200
研发工程师玩转Kubernetes——通过PV的节点亲和性影响Pod部署
有关于Kubernetes中影响Pod调度的问题
找到问题跟原所在,默认的maxPods: 110,K8S默认一个节点上的pod调度数是110,当前有限制pod数的需求。 vim /var/lib/kubelet/config.yaml
Yuou
2022/09/26
4850
Kubernetes 资源清单(文章有点长)
Kubernetes 中所有的内容都抽象为资源,资源实例化(被调用、被执行了)之后,叫做对象。
Jared.Tan
2020/06/19
7730
Kubernetes K8S之affinity亲和性与反亲和性详解与示例 准备事项node硬亲和性示例node软亲和性示例node软硬亲和性联合示例准备事项pod硬亲
nodeSelector提供了一种非常简单的方法,将pods约束到具有特定标签的节点。而亲和性/反亲和性极大地扩展了可表达的约束类型。关键的增强是:
踏歌行
2020/11/12
5.6K0
Kubernetes K8S之affinity亲和性与反亲和性详解与示例
    




        准备事项node硬亲和性示例node软亲和性示例node软硬亲和性联合示例准备事项pod硬亲
推荐阅读
相关推荐
研发工程师玩转Kubernetes——使用污点(taint)驱逐Pod
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验