问题描述

测试集群三台master，每个master上面的kube-apiserver都频繁的重启。登录其中一台master，发现kube-apiserver的内存占用特别高，每次重启完后内存很快就飙到了20G左右，而且还有继续增长的趋势。因为默认kube-apiserver的静态pod是没有设置memeory limit的，最终api-server会吃光机器的所有内存，导致master机器运行异常。
查看容器内存占用的命令：

docker stats --no-stream |grep kube-apiserver

临时方案

出现问题后，没有找到问题根源，所以先修改了kube-apiserver的静态pod yaml文件，位于/etc/kubernetes/manifests/kube-apiserver.yaml，添加resources.limits.memory 为32g（本机内存为64g）。这样现在kube-apiserver的内存，使它消耗内存到32g的时候就oom kill自动重启，不会影响宿主机的性能

问题分析

api-server内存持续升高，肯定是有资源在堆内存里申请了空间但是没有释放。首先考虑是否是因为建立了太多的链接导致的，使用如下指令查询kube-apiserver链接数：

netstat -nat | grep -i "6443" | wc -l

发现链接数在100多并不算多。

继续分析只能考虑导出kube-apiserver的heap文件来查看其详细的内存分布。这种方式需要使用go语言包的pprof工具，下面详细讲解go tool pprof 工具的使用以及kube-apiserver的配置。

go tool pprof 工具使用

kube-apiserver集成了pprof工具，可以通过链接/debug/prof/heap的url来获得heap文件。在kubernetes 1.18这个功能是默认打开的，1.18之前需要修改kube-apiserver的启动参数加上–profile true。测试集群kube-apiserver是1.17.3，所以需要修改启动参数，修改过程如下，profiling 改为true

vi /etc/kubernetes/manifests/kube-apiserver.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=10.250.7.21
    - --allow-privileged=true
    - --anonymous-auth=True
    - --apiserver-count=3
    - --authorization-mode=Node,RBAC
    - --bind-address=0.0.0.0
    - --client-ca-file=/etc/kubernetes/ssl/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-aggregator-routing=False
    - --enable-bootstrap-token-auth=true
    - --endpoint-reconciler-type=lease
    - --etcd-cafile=/etc/ssl/etcd/ssl/ca.pem
    - --etcd-certfile=/etc/ssl/etcd/ssl/node-t-paas-k8s-0-master-0.pem
    - --etcd-keyfile=/etc/ssl/etcd/ssl/node-t-paas-k8s-0-master-0-key.pem
    - --etcd-servers=https://10.250.7.21:2379,https://10.250.7.22:2379,https://10.250.7.23:2379
    - --feature-gates=CSINodeInfo=true,VolumeSnapshotDataSource=true,ExpandCSIVolumes=true,RotateKubeletClientCertificate=true
    - --insecure-port=0
    - --kubelet-client-certificate=/etc/kubernetes/ssl/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/ssl/apiserver-kubelet-client.key
    - --kubelet-preferred-address-types=InternalDNS,InternalIP,Hostname,ExternalDNS,ExternalIP
    - --profiling=true

修改完保存，kube-apiserver是静态pod修改完yaml文件后，kubelete会自动重启kube-apiserver的容器。pprof工具是go tool里的工具，所以需要下载go语言包到宿主机。为了方便链接（不用指定证书），使用kubectl proxy 在宿主机127.0.0.1:8001启动一个代理。下面是详细操作记录：

wget https://studygolang.com/dl/golang/go1.15.6.linux-amd64.tar.gz
tar xzvf go1.15.6.linux-amd64.tar.gz

#启动proxy
kubectl proxy
Starting to serve on 127.0.0.1:8001

#新开一个terminal，执行如下指令，进入交互界面
./go tool pprof http://127.0.0.1:8001/debug/pprof/heap

#进入交互界面后，输入top 20查看内存使用前20的函数调用
Fetching profile over HTTP from http://127.0.0.1:8001/debug/pprof/heap
Saved profile in /root/pprof/pprof.kube-apiserver.alloc_objects.alloc_space.inuse_objects.inuse_space.004.pb.gz
File: kube-apiserver
Type: inuse_space
Time: Dec 10, 2020 at 2:46pm (CST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof)top 20

#得到如下输出
Showing nodes accounting for 11123.22MB, 95.76% of 11616.18MB total
Dropped 890 nodes (cum <= 58.08MB)
Showing top 20 nodes out of 113
     flat  flat%   sum%        cum   cum%
9226.15MB 79.43% 79.43%  9226.15MB 79.43%  bytes.makeSlice
1122.61MB  9.66% 89.09%  1243.65MB 10.71%  k8s.io/kubernetes/vendor/k8s.io/api/core/v1.(*ConfigMap).Unmarshal
 139.55MB  1.20% 90.29%   153.05MB  1.32%  k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/apis/meta/v1.(*ObjectMeta).Unmarshal
 120.53MB  1.04% 91.33%   165.03MB  1.42%  encoding/json.(*decodeState).objectInterface
 117.29MB  1.01% 92.34%   117.29MB  1.01%  reflect.unsafe_NewArray
 108.03MB  0.93% 93.27%   108.03MB  0.93%  reflect.mapassign
  66.51MB  0.57% 93.84%    66.51MB  0.57%  k8s.io/kubernetes/vendor/github.com/json-iterator/go.(*Iterator).ReadString
  62.51MB  0.54% 94.38%    62.51MB  0.54%  k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/registry/generic.ObjectMetaFieldsSet
  61.51MB  0.53% 94.91%    61.51MB  0.53%  k8s.io/kubernetes/vendor/k8s.io/apiextensions-apiserver/pkg/registry/customresource.objectMetaFieldsSet
  43.01MB  0.37% 95.28%   137.03MB  1.18%  k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime.structToUnstructured
     18MB  0.15% 95.43%   183.61MB  1.58%  k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/storage/cacher.(*watchCache).Replace
  13.50MB  0.12% 95.55%   137.03MB  1.18%  k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime.toUnstructured
      9MB 0.077% 95.63%   237.54MB  2.04%  k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured.unstructuredJSONScheme.decodeToUnstructured
   7.50MB 0.065% 95.69%   144.53MB  1.24%  k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime.(*unstructuredConverter).ToUnstructured
      6MB 0.052% 95.74%   123.29MB  1.06%  reflect.MakeSlice
   1.50MB 0.013% 95.76%  8944.02MB 77.00%  encoding/json.mapEncoder.encode

通过heap文件输出，可以看到占用内存最多的是makeSlice函数占用了9G多的内存。它的调用者是v1.(*ConfigMap).Unmarshal，configmap是kubernetes的一种资源，Unmarshal是json和struct做转换的函数。所以怀疑与configmap资源有关。

在宿主机上使用

kubectl get configmap -A 发现命令卡死没有输出，但是在特定的某一个namespace下进行kubectl get configmap是有返回的。所以怀疑其中的某一个namespace下有大量的configmap，kubectl get configma卡死从而导致kubectl get configmap -A卡死。

下面就尝试在每一个namespace下执行kubectl get configmap。当执行到kubectl get configmap -n kubesphere-controls-system，时发现命令卡住，在等待了3分钟后有数据返回。使用wc统计了数量发现kubesphere-controls-system下有17万多的configmap，大多是kubeconfig-xxxx样子的。后面的xxx是用户名。使用kubectl get user同样发现了有17万多的用户。应该是之前同步的ldap的用户，每创建一个用户，就会在kubesphere-controls-system下新建一个configmaps。查看etcd db文件，发现达到了1.5g左右，其他正常的集群db文件一般在50M甚至更低。

分析到这里，问题基本明朗了。可能是kubesphere 2.x版本时同步了ldap的数据到kubesphere中，kubesphere每创建一个user就会新建个对应的configmap里面存着key和cert。17万configmap，导致api-server去list configmap时无法一次获取到，就会一直创建slice(这里应该是golang语言包里的一个bug https://studygolang.com/articles/2763)，从而使api-server耗尽内存。

解决方案

最终的解决方案就是删除这些ldap用户，kubesphere升级到3.0后每一次登录都直接到ldap验证，且是在host集群上执行的。被纳管集群不需要存贮这些数据。在使用kubectl delete user发现用户无法删除，因为etcd数据量太大了，kube-apiserver与etcd之间的调用性能下降很严重。kube-apiserver已经无法正常的提供服务了。所以考虑使用etcdctl直接链接etcd来删除数据

#删除 user
ETCDCTL_API=3 etcdctl --endpoints https://10.250.7.21:2379 --cacert $ETCD_TRUSTED_CA_FILE --cert $ETCD_CERT_FILE --key $ETCD_KEY_FILE del /registry/iam.kubesphere.io/users/ --prefix
#删除对应的 configmap
ETCDCTL_API=3 etcdctl --endpoints https://10.250.7.21:2379 --cacert $ETCD_TRUSTED_CA_FILE --cert $ETCD_CERT_FILE --key $ETCD_KEY_FILE del /registry/configmaps/kubesphere-controls-system/kubeconfig- --prefix

删除完数据后，使用docker restart 重启kube-apiserver，观测了一会，发现内存一直保持在1g左右。kubectl操作以及sit集群的web页面响应都比之前快了许多。