0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

重新分配pod节点

马哥Linux运维 来源:马哥Linux运维 2025-01-02 09:17 次阅读

1、软件包下载

去github上下载较新的Kubernetes软件包https://github.com/

757fc43a-c5dc-11ef-9310-92fbcf53809c.png

759ae526-c5dc-11ef-9310-92fbcf53809c.png

75b2c056-c5dc-11ef-9310-92fbcf53809c.png

75d0f29c-c5dc-11ef-9310-92fbcf53809c.png

75e47290-c5dc-11ef-9310-92fbcf53809c.png

75eb4e9e-c5dc-11ef-9310-92fbcf53809c.png

2、升级说明

升级包括master节点升级和node节点的升级,本章升级至v1.15.12;

Master节点的服务包括:apiserver、controller-manager、kube-scheduler;

Node节点的服务包括:kubelet和kube-proxy;

由于apiserver被nginx代理,所以在升级的时候需要操作操作nginx注释升级节点,避免带来无法访问的情况;

我们的master节点和node都是在同一个集群服务器上,所以一起进行操作;

3、确定节点升级顺序

查看节点信息

[root@hdss7-21 ~]# kubectl get node
NAME                STATUS   ROLES    AGE   VERSION
hdss7-21.host.com   Ready       14d   v1.14.10
hdss7-22.host.com   Ready       14d   v1.14.10

查看pod分布状态,尽量选择较少pod的节点先进行迁移

[root@hdss7-21 ~]# kubectl get pod -o wide -n kube-system
NAME                                   READY   STATUS    RESTARTS   AGE   IP           NODE                NOMINATED NODE   READINESS GATES
coredns-64f49f5655-smzzz               1/1     Running   6          8d    172.7.21.4   hdss7-21.host.com              
kubernetes-dashboard-99ff79fcd-khl8z   1/1     Running   2          4d    172.7.22.4   hdss7-22.host.com              
traefik-ingress-2svq6                  1/1     Running   3          5d    172.7.21.5   hdss7-21.host.com              
traefik-ingress-rcd28                  1/1     Running   3          5d    172.7.22.3   hdss7-22.host.com              

由于分布差不多,我们选择先升级10.4.7.21服务器上的节点

4、修改代理nginx配置

在10.4.7.21和22上都操作,以21为例
注释apiserver升级节点的服务器

[root@hdss7-11 ~]# vim /etc/nginx/nginx.conf
    upstream kube-apiserver {
#        server 10.4.7.21:6443     max_fails=3 fail_timeout=30s;
        server 10.4.7.22:6443     max_fails=3 fail_timeout=30s;
    }
[root@hdss7-11 ~]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root@hdss7-11 ~]# nginx -s reload

5、删除第一个节点

将节点调成不可调度状态

[root@hdss7-21 ~]#  kubectl cordon hdss7-21.host.com
node/hdss7-21.host.com cordoned

当节点设置成不可调度状态之后,新启动的 pod 不会调度到此节点上,但是该节点上正在运行的 Pod 将不会被影响。
驱逐节点上的pod

[root@hdss7-21 ~]# kubectl drain hdss7-21.host.com --delete-local-data --ignore-daemonsets --force
node/hdss7-21.host.com already cordoned
WARNING: ignoring DaemonSet-managed Pods: default/nginx-ds-2rj9d, kube-system/traefik-ingress-2svq6
evicting pod "coredns-64f49f5655-smzzz"
evicting pod "nginx-dp-86678bb55c-tklvc"
pod/nginx-dp-86678bb55c-tklvc evicted
pod/coredns-64f49f5655-smzzz evicted
node/hdss7-21.host.com evicted

注释:
--delete-local-data 即使pod使用了emptyDir也删除 --ignore-daemonsets 忽略deamonset控制器的pod,如果不忽略,daemonset控制器控制的pod被删除后可能马上又在此节点上启动起来,会成为死循环;--force 不加force参数只会删除该NODE上由ReplicationController, ReplicaSet, DaemonSet,StatefulSet or Job创建的Pod,加了后还会删除'裸奔的pod'(没有绑定到任何replication controller)

再次查看pod分布

[root@hdss7-21 ~]# kubectl get pod -o wide -n kube-system
NAME                                   READY   STATUS    RESTARTS   AGE   IP           NODE                NOMINATED NODE   READINESS GATES
coredns-64f49f5655-n2pl7               1/1     Running   0          39s   172.7.22.7   hdss7-22.host.com              
kubernetes-dashboard-99ff79fcd-khl8z   1/1     Running   2          4d    172.7.22.4   hdss7-22.host.com              
traefik-ingress-2svq6                  1/1     Running   3          5d    172.7.21.5   hdss7-21.host.com              
traefik-ingress-rcd28                  1/1     Running   3          5d    172.7.22.3   hdss7-22.host.com              

除了daemonset的pod已被移动到10.4.7.22接节点上

测试重新启动的coredns是否生效

[root@hdss7-21 ~]# dig -t A nginx-dp.default.svc.cluster.local @192.168.0.2 +short
192.168.191.8

删除节点

[root@hdss7-21 ~]# kubectl delete node hdss7-21.host.com
node "hdss7-21.host.com" deleted

6、升级第一个节点

配置新版本

[root@hdss7-21 ~]# cd /opt/src/
[root@hdss7-21 src]# tar -zxvf kubernetes-server-linux-amd64-v1.15.12.tar.gz
[root@hdss7-21 src]# mv kubernetes /opt/kubernetes-v1.15.12
[root@hdss7-21 src]# cd /opt/kubernetes-v1.15.12/
[root@hdss7-21 kubernetes-v1.15.12]# rm -f kubernetes-src.tar.gz
[root@hdss7-21 kubernetes-v1.15.12]# cd server/bin/
[root@hdss7-21 bin]# rm -f *.tar *_tag
[root@hdss7-21 bin]# ll
总用量 677292
-rwxr-xr-x 1 root root  50581504 6月  16 21:10 apiextensions-apiserver
-rwxr-xr-x 1 root root  44638208 6月  16 21:10 kubeadm
-rwxr-xr-x 1 root root  48525312 6月  16 21:10 kube-aggregator
-rwxr-xr-x 1 root root 122097664 6月  16 21:10 kube-apiserver
-rwxr-xr-x 1 root root 116301824 6月  16 21:10 kube-controller-manager
-rwxr-xr-x 1 root root  46419968 6月  16 21:10 kubectl
-rwxr-xr-x 1 root root  54980712 6月  16 21:10 kubectl-convert
-rwxr-xr-x 1 root root 118151728 6月  16 21:10 kubelet
-rwxr-xr-x 1 root root  43139072 6月  16 21:10 kube-proxy
-rwxr-xr-x 1 root root  47112192 6月  16 21:10 kube-scheduler
-rwxr-xr-x 1 root root   1593344 6月  16 21:10 mounter
[root@hdss7-21 bin]# mkdir certs
[root@hdss7-21 bin]# mkdir /opt/kubernetes-v1.15.12/conf

拷贝证书

[root@hdss7-21 bin]# cp /opt/kubernetes/server/bin/certs/* certs/
[root@hdss7-21 bin]# ls certs/
apiserver-key.pem  ca-key.pem  client-key.pem  kubelet-key.pem  kube-proxy-client-key.pem
apiserver.pem      ca.pem      client.pem      kubelet.pem      kube-proxy-client.pem

拷贝服务启动脚本

[root@hdss7-21 bin]# cp /opt/kubernetes/server/bin/*.sh .
[root@hdss7-21 bin]# ls
apiextensions-apiserver  kube-apiserver                      kubectl             kube-proxy                 mounter
certs                    kube-apiserver-startup.sh           kubectl-convert     kube-proxy-startup.sh
kubeadm                  kube-controller-manager             kubelet             kube-scheduler
kube-aggregator          kube-controller-manager-startup.sh  kubelet-startup.sh  kube-scheduler-startup.sh

拷贝配置文件

[root@hdss7-21 bin]# cp /opt/kubernetes/conf/* /opt/kubernetes-v1.15.12/conf/
[root@hdss7-21 bin]# ls /opt/kubernetes-v1.15.12/conf/
audit.yaml  k8s-node.yaml  kubelet.kubeconfig  kube-proxy.kubeconfig  nginx-ds.yaml

重新创建软连接

[root@hdss7-21 bin]# cd /opt/
[root@hdss7-21 opt]# ll
总用量 24
drwx--x--x 4 root root 4096 7月   2 21:50 containerd
lrwxrwxrwx 1 root root   16 6月   8 20:36 etcd -> /opt/etcd-v3.3.1
drwxr-xr-x 5 etcd etcd 4096 7月   9 21:25 etcd-v3.3.1
lrwxrwxrwx 1 root root   20 7月  17 19:40 flannel -> /opt/flannel-v0.11.0
drwxr-xr-x 3 root root 4096 7月  28 20:05 flannel-v0.11.0
lrwxrwxrwx 1 root root   23 7月  10 20:17 kubernetes -> /opt/kubernetes-v1.14.10
drwxr-xr-x 5 root root 4096 7月  10 20:36 kubernetes-v1.14.10
drwxr-xr-x 6 root root 4096 7月  28 22:18 kubernetes-v1.15.12
drwxr-xr-x 2 root root 4096 7月  28 22:10 src
[root@hdss7-21 opt]# rm -rf kubernetes
[root@hdss7-21 opt]# ln -s /opt/kubernetes-v1.15.12 /opt/kubernetes
[root@hdss7-21 opt]# ll
总用量 24
drwx--x--x 4 root root 4096 7月   2 21:50 containerd
lrwxrwxrwx 1 root root   16 6月   8 20:36 etcd -> /opt/etcd-v3.3.1
drwxr-xr-x 5 etcd etcd 4096 7月   9 21:25 etcd-v3.3.1
lrwxrwxrwx 1 root root   20 7月  17 19:40 flannel -> /opt/flannel-v0.11.0
drwxr-xr-x 3 root root 4096 7月  28 20:05 flannel-v0.11.0
lrwxrwxrwx 1 root root   23 7月  28 22:20 kubernetes -> /opt/kubernetes-v1.15.12
drwxr-xr-x 5 root root 4096 7月  10 20:36 kubernetes-v1.14.10
drwxr-xr-x 6 root root 4096 7月  28 22:18 kubernetes-v1.15.12
drwxr-xr-x 2 root root 4096 7月  28 22:10 src

7、重启节点服务

[root@hdss7-21 opt]# supervisorctl status
etcd-server-7-21                 RUNNING   pid 6296, uptime 014
flanneld-7-21                    RUNNING   pid 7042, uptime 014
kube-apiserver-7-21              RUNNING   pid 7165, uptime 024
kube-controller-manager-7-21     RUNNING   pid 4675, uptime 003
kube-kubelet-7-21                RUNNING   pid 7184, uptime 016
kube-proxy-7-21                  RUNNING   pid 4678, uptime 003
kube-scheduler-7-21              RUNNING   pid 4673, uptime 003

重启node节点服务

[root@hdss7-21 opt]# supervisorctl restart kube-kubelet-7-21
[root@hdss7-21 opt]# supervisorctl restart kube-proxy-7-21

查看版本

[root@hdss7-21 opt]# kubectl get node
NAME                STATUS   ROLES    AGE     VERSION
hdss7-21.host.com   Ready       4d22h   v1.15.12
hdss7-22.host.com   Ready       19d     v1.14.10

重启master节点服务

[root@hdss7-21 opt]# supervisorctl restart kube-apiserver-7-21
[root@hdss7-21 opt]# supervisorctl restart kube-controller-manager-7-21
[root@hdss7-21 opt]# supervisorctl restart kube-scheduler-7-21

注意重启过程中可以查看日志,确保启动无问题。

8、修改代理nginx配置

修改11和12配置

[root@hdss7-11 ~]# vim /etc/nginx/nginx.conf
    upstream kube-apiserver {
        server 10.4.7.21:6443     max_fails=3 fail_timeout=30s;
#        server 10.4.7.22:6443     max_fails=3 fail_timeout=30s;
    }
[root@hdss7-11 ~]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root@hdss7-11 ~]# nginx -s reload

9、升级第二个节点

按照同样的方法对其余节点进行升级
在10.4.7.22上操作
最后检查服务启动状态和node节点版本

[root@hdss7-22 ~]# supervisorctl status
etcd-server-7-22                 RUNNING   pid 1235, uptime 1:10:58
flanneld-7-22                    RUNNING   pid 1203, uptime 1:10:59
kube-apiserver-7-22              RUNNING   pid 25776, uptime 0:01:39
kube-controller-manager-7-22     RUNNING   pid 26009, uptime 0:01:09
kube-kubelet-7-22                RUNNING   pid 23925, uptime 0:06:08
kube-proxy-7-22                  RUNNING   pid 24142, uptime 0:05:38
kube-scheduler-7-22              RUNNING   pid 26190, uptime 0:00:38
[root@hdss7-22 ~]# kubectl get node
NAME                STATUS   ROLES    AGE     VERSION
hdss7-21.host.com   Ready       4d22h   v1.15.12
hdss7-22.host.com   Ready       6m12s   v1.15.12

10、修改nginx代理

将配置文件改为原来状态

[root@hdss7-11 ~]# vim /etc/nginx/nginx.conf
    upstream kube-apiserver {
        server 10.4.7.21:6443     max_fails=3 fail_timeout=30s;
        server 10.4.7.22:6443     max_fails=3 fail_timeout=30s;
    }
[root@hdss7-11 ~]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root@hdss7-11 ~]# nginx -s reload

11、测试操作平台

75fc9a50-c5dc-11ef-9310-92fbcf53809c.png

760a2df0-c5dc-11ef-9310-92fbcf53809c.png

12、重新分配pod节点

查看pod信息得知目前大部分的pod在10.4.7.21上,这不符合性能最优状态,我们可以在dashbard面板上删除一个pod,通过scheduler的计算,会在另外一个(22上)负载较少的node节点上重新启动这个pod
如下,删除coredns的pod

7615e42e-c5dc-11ef-9310-92fbcf53809c.png

正在重启状态

761dd0da-c5dc-11ef-9310-92fbcf53809c.png

启动后的状态

76355ec6-c5dc-11ef-9310-92fbcf53809c.png

链接:https://www.cnblogs.com/wangyuanguang/p/15091863.html

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • 节点
    +关注

    关注

    0

    文章

    220

    浏览量

    24449
  • POD
    POD
    +关注

    关注

    0

    文章

    18

    浏览量

    6031

原文标题:12、重新分配pod节点

文章出处:【微信号:magedu-Linux,微信公众号:马哥Linux运维】欢迎添加关注!文章转载请注明出处。

收藏 人收藏

    评论

    相关推荐

    Jtti:节点ID变化过于频繁如何解决

    与现有节点的ID重复。 采用动态ID分配策略 :设置一个ID管理节点,负责为新加入的节点分配唯一的ID,并在
    的头像 发表于 12-12 15:44 126次阅读

    华纳云:Chord算法如何管理节点间的联系?

    处理节点的加入和离开,以及节点的故障。当节点离开或故障时,其责任区间会被重新分配给其他节点,以确保数据的可用性。 后继指针: 每个
    发表于 11-08 16:03

    嵌入式学习-飞凌嵌入式ElfBoard ELF 1板卡-通用文件I/O模型之close

    可以被重新分配使用。在程序结束时,所有打开的文件都会自动关闭,但建议在读写文件结束后手动关闭文件,这样可以最大限度地避免资源泄露和数据损坏。代码示例:
    发表于 10-12 09:31

    飞凌嵌入式ElfBoard ELF 1板卡-通用文件I/O模型之close

    可以被重新分配使用。在程序结束时,所有打开的文件都会自动关闭,但建议在读写文件结束后手动关闭文件,这样可以最大限度地避免资源泄露和数据损坏。代码示例:
    发表于 10-11 08:54

    芯片先进封装里的RDL

    文章来源:学习那些事 原文作者:新手求学 RDL是一层布线金属互连层,可将I/O重新分配到芯片的不同位置。 Redistribution layer(RDL)是将半导体封装的一部分电连接到另一
    的头像 发表于 09-20 16:29 878次阅读
    芯片先进封装里的RDL

    主动均衡技术的优点分析

    的基础。 主动均衡技术的优势分析 效率提升:主动均衡技术通过精确控制电池单体之间的能量转移,能够更有效地重新分配电荷。这种高效的电荷重新分配增加了电池组的总可用电荷,从而显著延长了系统的运行时间。在电动汽车等对
    的头像 发表于 08-29 16:21 756次阅读

    节点电压法流入节点电流怎么判断正负

    节点电压法(Node Voltage Method)是一种在电路分析中常用的方法,用于求解电路中各节点的电压。在这种方法中,我们通常选择一个参考节点(通常是接地点),然后求解其他节点
    的头像 发表于 08-06 17:24 2354次阅读

    节点电压法的实质是什么

    节点电压法(Node Voltage Method)是一种在电路分析中常用的方法,主要用于求解线性电路中的电压和电流。它基于基尔霍夫电流定律(KCL)和欧姆定律,通过建立节点电压方程来求解电路中
    的头像 发表于 08-06 17:08 1051次阅读

    ESP8266在和路由器失联后,如何通过SDK CALLBACK获取?

    你好,请问,在8266已经连上路由器,并和服务器建立tcp连接,如果中途路由器重启,过段时间,8266和路由器再次取得连接并重新分配了IP地址,此时8266的SDK是否能提供API通过
    发表于 07-12 09:38

    单线分配器与双线分配器的区别是什么

    单线分配器与双线分配器是两种不同类型的电子设备,它们在通信、广播、电视等领域中有着广泛的应用。本文将介绍单线分配器与双线分配器的区别。 一、定义 单线
    的头像 发表于 07-10 10:44 935次阅读

    esp mesh lite用mesh节点外的一个esp32作为sta去连接不同的节点 ,连接的是同一个局域网吗?

    esp mesh lite 我用mesh节点外的一个esp32 作为sta去连接不同的节点 ,连接的是同一个局域网吗,连接不同的节点分配给我的局域网ip是否是一样的呢?
    发表于 06-28 15:26

    ESP-WIFI-MESH子节点在连接根节点后,根节点重启后改变信道,子节点不能重新组网怎么解决?

    节点是指定的,并且连接到外部路由器。然后所有的子节点使用了esp_mesh_fix_root(true);放弃投票。 现在出现一个问题:在正常路由器,根节点,子节点都连接的情况下,
    发表于 06-28 12:12

    Netapp数据恢复—Netapp存储中卷被误删除的数据恢复案例

    存储卷全部删除并重新分配。在完成卷的删除但还没有重新分配的时候,上层业务宕机。运维工程师紧急排查故障情况,发现跑业务的服务器上的磁盘都“消失”了,无法访问数据。
    的头像 发表于 04-18 15:52 433次阅读
    Netapp数据恢复—Netapp存储中卷被误删除的数据恢复案例

    记录一次K8s pod被杀的排查过程

    今天下午运维反馈说我们这一个pod一天重启了8次,需要排查下原因。一看Kiban日志,jvm没有抛出过任何错误,服务就直接重启了。
    的头像 发表于 01-18 09:57 774次阅读

    【NetApp数据恢复】NetApp存储误操作删除lun的数据恢复案例

    ASM裸设备存储方式。 NetApp存储故障: 由于业务发展需要重新规划存储空间,工作人员直接将存储卷全部删除并重新分配。当删除卷还没有开始重新分配的时候,上层业务宕机,运维工程师紧急排查故障情况,发现业务服务器上的磁盘
    的头像 发表于 01-11 11:40 485次阅读
    【NetApp数据恢复】NetApp存储误操作删除lun的数据恢复案例