修改svc的LoadBalancer的IP引发的惨案-Toy模板网

这篇具有很好参考价值的文章主要介绍了修改svc的LoadBalancer的IP引发的惨案。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

背景

k8s集群没有接外部负载均衡，部署istio的时候ingressgateway一直pending。
于是手动修改了这个lb svc的externalIP，于是k8s就崩了，如何崩的，且听我还道来。

修改externalIPs的操作

修改svc的LoadBalancer的IP引发的惨案,# k8s,ChatGPT,tcp/ip,网络协议,网络
修改了svc的这个位置，于是api-server就崩了。

[root@k8s-worker-node1 cloud-native-istio-archive]# k -n istio-system get svc
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                                                                      AGE
istio-egressgateway    ClusterIP      10.68.66.210   <none>        80/TCP,443/TCP                                                               8d
istio-ingressgateway   LoadBalancer   10.68.215.92   <pending>     15021:30422/TCP,80:32418/TCP,443:31569/TCP,31400:32664/TCP,15443:31617/TCP   8d
istiod                 ClusterIP      10.68.49.71    <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP                                        8d
[root@k8s-worker-node1 cloud-native-istio-archive]# k -n istio-system edit svc istio-ingressgateway
service/istio-ingressgateway edited
[root@k8s-worker-node1 cloud-native-istio-archive]#
[root@k8s-worker-node1 cloud-native-istio-archive]#
[root@k8s-worker-node1 cloud-native-istio-archive]# k -n istio-system get svc
The connection to the server 10.50.10.10:6443 was refused - did you specify the right host or port?
[root@k8s-worker-node1 cloud-native-istio-archive]#
[root@k8s-worker-node1 cloud-native-istio-archive]#
[root@k8s-worker-node1 cloud-native-istio-archive]#
[root@k8s-worker-node1 cloud-native-istio-archive]# k -n istio-system get svc
The connection to the server 10.50.10.10:6443 was refused - did you specify the right host or port?

如果 EXTERNAL-IP 有值（IP 地址或主机名），则说明您的环境具有可用于 Ingress 网关的外部负载均衡器。如果 EXTERNAL-IP 值是（或一直是），则说明可能您的环境并没有为 Ingress 网关提供外部负载均衡器的功能。

api-server报错日志

[root@k8s-worker-node1 cloud-native-istio-archive]# systemctl status kube-apiserver -l
● kube-apiserver.service - Kubernetes API Server
   Loaded: loaded (/etc/systemd/system/kube-apiserver.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2023-10-19 17:19:09 CST; 1 weeks 1 days ago
     Docs: https://github.com/GoogleCloudPlatform/kubernetes
 Main PID: 45101 (kube-apiserver)
    Tasks: 10
   Memory: 470.1M
   CGroup: /system.slice/kube-apiserver.service
           └─45101 /opt/kube/bin/kube-apiserver --allow-privileged=true --anonymous-auth=false --api-audiences=api,istio-ca --authorization-mode=Node,RBAC --bind-address=10.50.10.10 --client-ca-file=/etc/kubernetes/ssl/ca.pem --endpoint-reconciler-type=lease --etcd-cafile=/etc/kubernetes/ssl/ca.pem --etcd-certfile=/etc/kubernetes/ssl/kubernetes.pem --etcd-keyfile=/etc/kubernetes/ssl/kubernetes-key.pem --etcd-servers=https://10.50.10.10:2379 --kubelet-certificate-authority=/etc/kubernetes/ssl/ca.pem --kubelet-client-certificate=/etc/kubernetes/ssl/kubernetes.pem --kubelet-client-key=/etc/kubernetes/ssl/kubernetes-key.pem --secure-port=6443 --service-account-issuer=https://kubernetes.default.svc --service-account-signing-key-file=/etc/kubernetes/ssl/ca-key.pem --service-account-key-file=/etc/kubernetes/ssl/ca.pem --service-cluster-ip-range=10.68.0.0/16 --service-node-port-range=30000-32767 --tls-cert-file=/etc/kubernetes/ssl/kubernetes.pem --tls-private-key-file=/etc/kubernetes/ssl/kubernetes-key.pem --requestheader-client-ca-file=/etc/kubernetes/ssl/ca.pem --requestheader-allowed-names= --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --proxy-client-cert-file=/etc/kubernetes/ssl/aggregator-proxy.pem --proxy-client-key-file=/etc/kubernetes/ssl/aggregator-proxy-key.pem --enable-aggregator-routing=true --v=2

Oct 27 23:41:20 k8s-worker-node1 kube-apiserver[45101]: "Metadata": null
Oct 27 23:41:20 k8s-worker-node1 kube-apiserver[45101]: }. Err: connection error: desc = "transport: Error while dialing dial tcp 10.50.10.10:2379: connect: connection refused"
Oct 27 23:41:25 k8s-worker-node1 kube-apiserver[45101]: W1027 23:41:25.168319   45101 logging.go:59] [core] [Channel #57333 SubChannel #57334] grpc: addrConn.createTransport failed to connect to {
Oct 27 23:41:25 k8s-worker-node1 kube-apiserver[45101]: "Addr": "10.50.10.10:2379",
Oct 27 23:41:25 k8s-worker-node1 kube-apiserver[45101]: "ServerName": "10.50.10.10",
Oct 27 23:41:25 k8s-worker-node1 kube-apiserver[45101]: "Attributes": null,
Oct 27 23:41:25 k8s-worker-node1 kube-apiserver[45101]: "BalancerAttributes": null,
Oct 27 23:41:25 k8s-worker-node1 kube-apiserver[45101]: "Type": 0,
Oct 27 23:41:25 k8s-worker-node1 kube-apiserver[45101]: "Metadata": null
Oct 27 23:41:25 k8s-worker-node1 kube-apiserver[45101]: }. Err: connection error: desc = "transport: Error while dialing dial tcp 10.50.10.10:2379: connect: connection refused"

挽救

重启api-server，起不来，etcd决绝连接。
无法救回，连GPT4也不行
修改svc的LoadBalancer的IP引发的惨案,# k8s,ChatGPT,tcp/ip,网络协议,网络
番外: 纪念一下中堂大人。

教训

没事不要随便改LB svc的 externalIP ，是根据这个博主的文章修改的https://www.cnblogs.com/boshen-hzb/p/10679863.html。大家注意一下，不要把集群搞挂了。任何时候对线上环境的更改应该小心，必须知道这么做的后果是什么？文章来源地址https://www.toymoban.com/news/detail-716523.html

到了这里，关于修改svc的LoadBalancer的IP引发的惨案的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！