问题描述:

测试环境安装默认的10.244段无问题,可直接用, 生产环境安装时,也套用了默认的安装模板,造成flannel等组件IP都是10.244段,要改掉,IP规划为pod全用10.80.0.0/16段, service的IP段为10.90.0.0/16段, 这样各环境IP段就不会冲突了,方便后续做路由指向和网络隔离等安全策略,全套标准步骤如下:

1. 注意查看api-server的证书生成时的IP段,如果里面没有包括 10.80和10.90段,api-server的证书就需要重新生成替换,否则后面所有节点连api-server时都会被拒绝.

2. 先删除flannel, 此时flannel还是10.244段,先对此组件下线

kubectl delete -f kube-flannel.yml

3. 删除node

kubectl delete node 节点名

4. 更新配置

有如下配置项要做更改:

kubelet-config.yml clusterDNS 改为 10.90.0.2 (此IP为coreDNS的地址)

kube-proxy-config.yml 改为 clusterCIDR: 10.80.0.0/16

kube-controller-manager.conf 配置项修改 --cluster-cidr=10.80.0.0/16 --service-cluster-ip-range=10.90.0.0/16 # 注意如果这里不匹配的话,就会对node失去控制

coredns和flannel都是用的yml文件安装成了pod, 因此这两个组件要提前改好IP段

coredns.yaml 里设置Service相关配置 clusterIP: 10.90.0.2

kube-flannel.yml 里设置 net-conf.json

net-conf.json: |

{

"Network": "10.80.0.0/16",

"Backend": {

"Type": "vxlan"

}

}

 

5. 重启master相关应用

systemctl restart kube-controller-manager

 

6. 重启node相关应用

rm -f /opt/kubernetes/cfg/kubelet.kubeconfig

rm -f /opt/kubernetes/ssl/kubelet*

#上面这两步千万不要漏掉,否则会无法颁发证书

systemctl restart kubelet

systemctl restart kube-proxy

 

7. master上给node节点颂发证书,注意颂发后的证书状态要为

kubectl get csr

NAME AGE SIGNERNAME REQUESTOR CONDITION

node-csr-JYNknakEa_YpHz797oKaN-ZTk43nD51Zc9CJkBLcASU 85m kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Pending

kubectl certificate approve node-csr-JYNknakEa_YpHz797oKaN-ZTk43nD51Zc9CJkBLcASU

再次查看证书 kubectl get csr

 

kubectl get node

NAME STATUS ROLES AGE VERSION

k8s-master Ready <none> 34h v1.18.3

k8s-master2 Ready <none> 83m v1.18.3

k8s-node1 Ready <none> 33h v1.18.3

k8s-node2 Ready <none> 33h v1.18.3

此时节点已管理上,再次重新安装coredns和flannel, 如果其他pod 的IP没有变过来,也一并重新安装,

装好后IP如下图

 

 

装好后节点上IP和pod的IP都已正常

 

注意: 此方法只是在初始安装或者安装错了后修改的标准做法, 不适用于现有的k8s上已经安装有大量的pod资源的情况, 因为涉及到删除node节点,所以所有的pod都会随之删除, 操作前请评估好风险, 如果k8s已经上线运行了一段时间,存在大量资源的话,不建议再修改IP段, 风险太大.

 

整个操作过程中可能碰到的问题报错总结:

1. kube-controller-manager 报错 F1019 13:39:09.784464 6321 controllermanager.go:235] error starting controllers: failed to mark cidr[10.244.3.0/24] at idx [0] as occupied for node: gql-prod-k8s-node1-ip44: cidr 10.244.3.0/24 is out the range of cluster cidr 10.80.0.0/16

 

原因: 因为kube-controller-manager 提前修改成了 10.80段,而没有提前删除node节点,node节点信息还残留在etcd里

解决办法: 进etcd里清除node节点相关信息(注意先备份),或者将kube-controller-manager的IP再改回10.244重启后再删除node

etcd里残留的节点信息如下图

 

etcd查找节点信息key的方法

ETCDCTL_API=3 /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem --endpoints="三个etcd地址" get / --prefix --keys-only |grep node

 

查看具体节点信息残留的方法, 尽量不要执行删除操作,一定要做好备份

ETCDCTL_API=3 /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem --endpoints="三个etcd地址" get /registry/minions/k8s-node1

 

2. 证书颂发后,状态只显示Approved,而没有Issued, node节点里只收到 kubelet-client-key.tmp, 没有生成kubelet.kubeconfig和其他自动生成的kubelet-client证书

 

原因: 部分node节点失控, 占用了 kube-controller-manager处理线程,此时kube-controller-manager里会一直报节点的错误,详情请看上面的第一条故障

解决办法: 提前删除所有node节点,重新按标准流程添加node节点

3. kube-controller-manager和kube-scheduler日志不断报错如下:

No authentication-kubeconfig provided in order to lookup client-ca-file in configmap/extension-apiserver-authentication in kube-system, so client certificate authentication won't work.
No authentication-kubeconfig provided in order to lookup requestheader-client-ca-file in configmap/extension-apiserver-authentication in kube-system, so request-header client certificate authentication won't work.
No authorization-kubeconfig provided, so SubjectAccessReview of authorization tokens won't work.

原因: kubelet证书颂发流程未走完,没有显示Issue状态,因此这两个master组件里会一直报错

解决办法: 彻底删除所有节点, 再kubectl delete csr 证书名  清理所有状态不正常的证书, 重新按标准流程添加节点,重新发证书.