写点什么

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

  • 2020-05-25
  • 本文字数:3792 字

    阅读完需:约 12 分钟

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

为了让大家能够在实际应用场景中更顺利地使用 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 提供。但是,在实际使用中要考虑一些特殊场景:


  1. 如果 rancher-server 宕机无法访问,用户能够直接访问托管集群 api

  2. 考虑到地理远近访问,用户有时候希望不通过 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: v1kind: Configclusters:- 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-systemNAME                            AGEkubeconfig-user-gc4s9.c-cn2rq   13d
# kubectl get clusterauthtokens kubeconfig-user-gc4s9.c-cn2rq -n cattle-system -o yamlapiVersion: cluster.cattle.io/v3enabled: truehash: $1:fad9a80a83333248:15:8:1:***********kind: ClusterAuthTokenmetadata: 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-1117a5825b72userName: 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/serviceaccounttotal 4.0Kdrwxrwxrwt 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.912945351lrwxrwxrwx 1 root root   31 Feb 18 09:49 ..data -> ..2020_02_18_09_49_08.912945351lrwxrwxrwx 1 root root   13 Feb 18 09:49 ca.crt -> ..data/ca.crtlrwxrwxrwx 1 root root   16 Feb 18 09:49 namespace -> ..data/namespacelrwxrwxrwx 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 也会出现问题,这也是需要注意的。


2020-05-25 16:411098

评论

发布
暂无评论
发现更多内容

发布60分钟!霸榜Github的阿里面试参考指南,啃透涨薪10k

Java架构师迁哥

云计算对比IDC的优势简单说明-行云管家

行云管家

云计算 服务器

面试官:你能讲讲栈和队列吗?我:你礼貌吗?

Ayue、

数据结构

柯桥PS培训到兴德教育!零基础开始辅导!

Geek_196d9f

趣口袋拼团系统APP开发案例

高并发应对策略系列文章阶段汇总,提供离线文档下载

Coder的技术之路

点通生活系统软件开发搭建

CodeDay 北京站报名倒计时

蚂蚁集团移动开发平台 mPaaS

移动开发

搭建 JumpServer 堡垒机管理数万台游戏服务器

学神来啦

云计算 Linux linux运维 运维工程师 运维平台

【kafka实战】分区重分配可能出现的问题和排查问题思路(生产环境实战,干货!!!非常干!!!建议收藏)

石臻臻的杂货铺

Kafk Kafka实战

你见过最具有代表性的面试是什么样的?大三4面上岸腾讯(Java岗)

Java架构师迁哥

架构实战营-模块八-作业

大可

TY短视频系统APP开发介绍

万字图文丨最全的Java继承解读

华为云开发者联盟

Java 开发 代码 继承

阿里新出炉爆款的顶配版Spring Security笔记,肝完变秃也变强

Java spring 编程 架构

智慧海洋三维可视化,科技运维助工业物联网一臂之力

一只数据鲸鱼

数据可视化 3D可视化 智慧工业 海上作业

架构实战营模块8作业

eoeoeo

架构实战营

从零开始学习3D可视化之摄像机投影方式

ThingJS数字孪生引擎

大前端 可视化 3D 数字孪生

所有前端都要看的2D游戏化互动入门基础知识

蚂蚁集团移动开发平台 mPaaS

大前端

hdfs 的集群间拷贝、归档、回收站等功能剖析

大数据技术指南

hdfs 7月日更

新思科技凭借Coverity Scan帮助NGINX确保代码质量和安全

InfoQ_434670063458

新思科技 软件安全 Coverity 静态代码分析

绍兴服装设计培训到兴德教育!

Geek_196d9f

经过一年的不懈努力社招进了阿里,我总结了50个Java面试必考题

Java 程序员 架构 面试

一文读懂大数据实时计算

五分钟学大数据

实时计算 7月日更

我用Vanilla JS重写了一遍项目,结果……

Faye

大前端 js 原生

CryptoPlace挖矿APP系统开发简介

互帮侠系统软件开发公司

闭关三月!啃透美团保姆级分布式进阶技术手册,终入美团定L8

Java 面试

喜马拉雅亿级用户量的离线消息推送系统架构设计实践

JackJiang

消息推送 即时通讯 IM push

Flink Runtime架构

Geek_qsftko

flink

绍兴柯桥CAD制图培训到兴德教育

Geek_196d9f

Rancher实战案例 | kube-api-auth日志中出现大量错误信息怎么办?_文化 & 方法_Rancher_InfoQ精选文章