重新分配pod节点
1、软件包下载
去github上下载较新的Kubernetes软件包https://github.com/
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 Ready14d 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.comkubernetes-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.comkubernetes-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 Ready4d22h 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 Ready4d22h 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、测试操作平台
12、重新分配pod节点
查看pod信息得知目前大部分的pod在10.4.7.21上，这不符合性能最优状态，我们可以在dashbard面板上删除一个pod，通过scheduler的计算，会在另外一个（22上）负载较少的node节点上重新启动这个pod
如下，删除coredns的pod
正在重启状态
启动后的状态
链接：https://www.cnblogs.com/wangyuanguang/p/15091863.html
声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表电子发烧友网立场。文章及其配图仅供工程师学习之用，如有内容侵权或者其他违规问题，请联系本站处理。
举报投诉
-
节点
+关注
关注
0文章
226浏览量
25425 -
POD
+关注
关注
0文章
18浏览量
6267
原文标题：12、重新分配pod节点
文章出处：【微信号：magedu-Linux，微信公众号：马哥Linux运维】欢迎添加关注！文章转载请注明出处。
发布评论请先 登录
相关推荐
热点推荐
请问如何将蜂鸟E203移植到Xilinx NEXYS A7 FPGA 开发板上？
列，使用Xilinx NEXYS A7时需要重新分配引脚。我找了下Xilinx Artix-7 系列XC7A100T-fgg484的引脚分配，一直没有找到。麻烦大神指导下。
发表于 11-11 07:44
在PSoC™ 41xx 系列的代码执行期间是否可以将运算放大器重新分配给另一个引脚？
您能否确认在PSoC™ 41xx 系列的代码执行期间是否可以将运算放大器重新分配给另一个引脚？ 目标是让一个设备配备 2 个运算放大器来测量和放大 2 个以上的信号，那么是否可以动态地将运算放大器重新路由到不同的引脚？或者是否需要使用具有更多运算放大器的设备来完成此任务？
发表于 08-15 07:05
TC3XX 的端口可以同时被 EvADC 和 DSADC 用于 ADC 转换吗？
1、TC3XX 的端口可以同时被 EvADC 和 DSADC 用于 ADC 转换吗？
例如，TC36X系列的AN1引脚
2、同时重新分配同一个引脚，是否会影响EVAADC和DSADC的转换结果的精度和速度？
发表于 08-07 08:19
什么是 K8S,如何使用 K8S
、故障恢复等。
资源抽象与调度：将服务器资源抽象为统一资源池，通过调度器分配任务到节点。
自愈能力：自动重启失败容器或迁移到健康节点。
弹性伸缩：根据负载动态调整容器数量。
服务发现与负载均衡：内置服务
发表于 06-25 06:45
多节点并行处理架构
多节点并行处理架构（如MPP架构）通过分布式计算和存储实现高性能数据处理，其核心设计及典型应用如下： 一、核心架构特征 非共享架构（Share Nothing） 每个节点拥有独立的计算资源（CPU
详解Kubernetes中的Pod调度亲和性
在 Kubernetes（K8s）中，Pod 调度亲和性（Affinity） 是一种高级调度策略，用于控制 Pod 与节点（Node）或其他 Pod 之间的关联（亲和）或反关联（反亲和
golang内存分配
作者：钱文 Go 的分配采用了类似 tcmalloc 的结构.特点: 使用一小块一小块的连续内存页, 进行分配某个范围大小的内存需求. 比如某个连续 8KB 专门用于分配 17-24 字节,以此减少
Kubernetes负载均衡器MetalLB介绍
Kubernetes中一个应用服务会有一个或多个实例，每个实例（Pod）的IP地址由网络插件动态随机分配（Pod重启后IP地址会改变）。为屏蔽这些后端实例的动态变化和对多实例的负载均衡，引入了 Service这个资源对象。
芯片封装中的RDL(重分布层)技术
封装中的RDL（Redistribution Layer，重分布层）是集成电路封装设计中的一个重要层次，主要用于实现芯片内电气连接的重新分配，并且在封装中起到连接芯片和外部引脚之间的桥梁作用。RDL的设计和实现直接影响到封装的电气性能、可靠性和制造成本。
Kubernetes：构建高效的容器化应用平台
init初始化集群，按照提示配置kubeconfig文件，它包含集群连接信息。从节点通过kubeadm join命令加入集群。 Pod 是 Kubernetes 中最小的可部署单元，一个 Pod 可以包含一
信道分配算法在通信中的应用
在现代通信系统中，信道分配算法是确保有效、高效通信的关键技术之一。随着移动通信技术的快速发展，用户数量的增加和数据流量的爆炸式增长，对信道资源的需求也在不断上升。 信道分配算法的基本概念 信道分配
CAN通信节点多时，如何减少寄生电容和保障节点数量？
导读在汽车电子与工业控制等领域，CAN通信至关重要。本文围绕CAN通信，阐述节点增多时如何减少寄生电容的策略，同时从发送、接收节点等方面，讲解保障节点数量及通信可靠性的方法。如何减少寄生电容?增加
工商网监
评论