为了让大家能够在实际应用场景中更顺利地使用Rancher，我们推出Rancher实战案例系列。该系列的文章均为生产环境中遇到的实际问题，Rancher研发团队将基于此问题的解决过程，写出问题排查思路。本文为该系列的第一篇，分享Rancher kube-api-auth组件的一个问题排查记录。

前言

业界应用最广泛的Kubernetes管理平台Rancher经过多年的发展，无论是在开源社区还是在商业体系中，都拥有了大量用户。但是，正如你所知，没有任何产品是十全十美的，在用户的业务落地实践中，我们的产品也存在一些缺陷。而在我们的技术团队的支持下，许多问题也得到了改善和解决。本文我们精选了实战问题处理案例，一是分享Rancher技术团队成熟的经验供大家参考，二是让更多用户参与进来共同探索切磋技艺，我们坚信寻找答案的路途永远没有终点。

本文，我们将分享Rancher kube-api-auth组件的一个问题排查记录。

排查记录

问题描述

某客户的托管集群在经历一些操作后（操作记录未能还原），在某托管集群的system项目中的kube-api-auth Pod中不断有错误日志输出，错误信息如下：

由于操作记录没有还原，我们未能找到精准的重现方式。而且客户的环境只能远程操作，排查问题也非常不方便。

基本原理

Rancher是支持多集群管理的平台，用户可以通过rancher-server API访问到托管集群的Kubernetes API。在访问过程中，需要authentication信息，authentication方式由Rancher提供。但是，在实际使用中要考虑一些特殊场景：

如果rancher-server宕机无法访问，用户能够直接访问托管集群 api
考虑到地理远近访问，用户有时候希望不通过rancher-server，而直接访问托管集群 api

解决以上问题，就是kube-api-auth存在的价值，Rancher会在所有的创建RKE集群中部署kube-api-auth。Kuerbnetes的authentication有很多方式，Rancher在对接自己用户体系时，采用的是webhook-token方式，参考：

https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication

官网中也对集群访问方式有详细描述：

https://rancher.com/docs/rancher/v2.x/en/cluster-admin/cluster-access/ace/

另外一张架构图也很好说明了这两种机制：一种是通过Rancher server和agent的tunnel访问托管集群的API，authentication在Rancher server已经实现；另一种是直接访问托管集群API，这时authentication主要靠托管集群内的kube-api-auth实现。

我们通过kubectl来更具体了解kube-api-auth的作用。Rancher本身由生成集群kubeconfig的功能，你登录一个用户，可以得到的kubeconfig大致如下：

apiVersion: v1
kind: Config
clusters:
- name: "c1"
  cluster:
    server: "https://*****/k8s/clusters/c-cn2rq"
    certificate-authority-data: "xxxx"
- name: "c1-ip-172-31-24-41"
  cluster:
    server: "https://172.31.24.41:6443"
    certificate-authority-data: "xxx"

users:
- name: "c1"
  user:
    token: "kubeconfig-user-gc4s9.c-cn2rq:**********"

contexts:
- name: "c1"
  context:
    user: "c1"
    cluster: "c1"
- name: "c1-ip-172-31-24-41"
  context:
    user: "c1"
    cluster: "c1-ip-172-31-24-41"

current-context: "c1"

我们可以看到几个关键信息：

User token的格式，冒号分割的两部分，可以理解为access key和secret
Context包含两个，一个rancher-server入口，一个是托管集群kube-api入口；默认使用rancher-server入口

当我们用“c1”context访问，使用kubectl随意获取一些资源，观察kube-api-auth的logs，会发现没有任何输出。原因很简单，通过rancher-server入口访问，authentication不走webhook。它会在rancher-server中通过tcp-proxy via websocket方式访问托管集群api，这种情况authentication没有走webhook，直接内部证书授权方式。

当我们用“c1-ip-172-31-24-41” context访问，观察kube-api-auth的logs，会发现类似信息：

time="2020-02-18T05:30:53Z" level=info msg="Starting Rancher Kube-API-Auth service on 127.0.0.1:6440"
time="2020-02-18T06:09:56Z" level=info msg="Processing v1Authenticate request..."
time="2020-02-18T06:09:56Z" level=info msg="  ...looking up token for kubeconfig-user-gc4s9.c-cn2rq"
time="2020-02-18T06:09:57Z" level=info msg="{\"apiVersion\":\"authentication.k8s.io/v1beta1\",\"kind\":\"TokenReview\",\"status\":{\"authenticated\":true,\"user\":{\"username\":\"user-gc4s9\"}}}"

这种情况下，kube-api-auth是起作用的，而且在logs我们也能看user token信息，它完全能和kubeconfig里面的对应上。user token的校验信息实际上是存在托管集群的某个CRD里面，kube-api-auth的逻辑就是从reqeust信息中获取token，并和本地CRD数据对照：

# kubectl get clusterauthtokens -n cattle-system
NAME                            AGE
kubeconfig-user-gc4s9.c-cn2rq   13d

# kubectl get clusterauthtokens kubeconfig-user-gc4s9.c-cn2rq -n cattle-system -o yaml
apiVersion: cluster.cattle.io/v3
enabled: true
hash: $1:fad9a80a83333248:15:8:1:***********
kind: ClusterAuthToken
metadata:
  creationTimestamp: "2020-02-05T03:06:18Z"
  generation: 1
  labels:
    cattle.io/creator: norman
  name: kubeconfig-user-gc4s9.c-cn2rq
  namespace: cattle-system
  resourceVersion: "1047"
  selfLink: /apis/cluster.cattle.io/v3/namespaces/cattle-system/clusterauthtokens/kubeconfig-user-gc4s9.c-cn2rq
  uid: 5ec4fc46-5030-45fb-b715-1117a5825b72
userName: user-gc4s9

这里我们需要注意request user token的格式，一定是冒号分割的两部分。一旦是非法格式，kube-api-auth就会拒绝校验，并报出之前问题提到的logs信息：“found 1 parts of token”。

原因分析

根据上面分析的基本原理，我们可以知道触发kube-api-auth产生error logs有两个前提：

通过kube-api-auth鉴权访问托管集群
访问托管集群时user-token不合法

针对第一个前提，我们知道Kubernetes可以开启多种authentication，在RKE中就支持了X509 Client Certs/ServiceAccount/Webhook token这些类型，多种authentication是可以并存的。Kubernetes官方文档中有描述：

https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/#authentication
Multiple authentication modules can be specified, in which case each one is tried in sequence, until one of them succeeds.

也就说对于某个kube-api-client，如果X509 Client Certs/ServiceAccount的鉴权都失败，那么一定会走到Webhook token。

X509 Client Certs一般不会暴露用户使用，ServiceAccount是常见的使用方式，ServiceAccount的本质是会生成一个secret（保存JWT token），当Pod启动时，会放在固定目录下提供kube-api-client使用：

root@ip-172-31-24-41:~# ls -ahl /var/run/secrets/kubernetes.io/serviceaccount
total 4.0K
drwxrwxrwt 3 root root  140 Feb 18 09:49 .
drwxr-xr-x 3 root root 4.0K Feb 18 09:49 ..
drwxr-xr-x 2 root root  100 Feb 18 09:49 ..2020_02_18_09_49_08.912945351
lrwxrwxrwx 1 root root   31 Feb 18 09:49 ..data -> ..2020_02_18_09_49_08.912945351
lrwxrwxrwx 1 root root   13 Feb 18 09:49 ca.crt -> ..data/ca.crt
lrwxrwxrwx 1 root root   16 Feb 18 09:49 namespace -> ..data/namespace
lrwxrwxrwx 1 root root   12 Feb 18 09:49 token -> ..data/token

假设一种场景，如果我们手动删除ServiceAccount对应的secret，但不重建Pod，这样导致Pod内的secret失效，然后观察kube-api-auth就可以看到大量error log。这就是因为secret失效，导致ServiceAccount鉴权失败，进而Kubernetes尝试Webhook token鉴权，也就是通过kube-api-auth。这时kube-api-auth获取request token，而这个token是kube-api-client传过来失效的secret JWT token，JWT token和webhook token格式完全不同（没有冒号分割），就会看到“found 1 parts of token”。

解决方案

回到客户的问题本身，应该是某些造成了一些serviceaccount 的secret被重建，比如：cattle serviceaccount，这个serviceaccount会用于运行cluster-agent/node-agent/kube-auth-api等组件。

这时，只要重建关键的workload就可以大概率解决。Rancher托管的workload中，cluster-agent/node-agent/kube-auth-api都关联了cattle serviceaccount，重建这些workload，让对应的Pod能够走默认的serviceaccount鉴权，就会减少报错概率。

总结

如前面所分析，Rancher在Kubernetes中配置了多种鉴权模式，而Kubernetes在处理这些鉴权时，并没有严格固定的顺序。所以，只要kube-auth-api没有大批量日志错误是可以接受的，因为该请求后续可能被其他鉴权模式认证通过。反之，出现了大量error log则说明整个托管集群确实有问题，顺着本文思路排查，重建cattle serviceaccount大概率可以解决。另外，用户自己的workload如果依赖某个serviceaccount，如果这个serviceaccount被重建，那么workload也会出现问题，这也是需要注意的。

创作场景

Rancher 实战案例 | kube-api-auth 日志中出现大量错误信息怎么办？