写点什么

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:411088

评论

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

Jira Software 年度总结:12个重要功能大放送!

Atlassian

DevOps 敏捷 Atlassian Jira ITSM

直播连麦的人工智能回声消除技术探索

融云 RongCloud

58 K8S之集群日志系统

穿过生命散发芬芳

k8s 28天写作 12月日更

白帽近距离|TimeLine Sec安全团队威猛先生

火线安全

艾瑞发布《2021 年全球互联网通信云行业研究报告》,融云持续领跑市场

融云 RongCloud

从了解洞态 IAST 到加入开源社区

火线安全

DevSecOps IAST

在线JSON转Mongoose工具

入门小站

工具

【架构师训练营】模块三作业

樰巳-堕~Horry

架构实战营 「架构实战营」

遥遥无期

Tiger

28天写作

深入Java线程池:从设计思想到源码解读

Ayue、

线程池

基于DataX的数据同步(上)-DataX介绍以及安装

恒生LIGHT云社区

MySQL 数据库 数据同步 DataX

融云荣获“2021 数字化服务创新成长企业”奖

融云 RongCloud

智算未来 | 2021新一代人工智能院士高峰论坛智算网络分论坛成功举办

OpenI启智社区

行业分析| AR远程协助-企业的好帮手

anyRTC开发者

音视频 远程协助 远程医疗 远程培训

Orillusion | 第一个WebGPU中文社区

Orillusion

WebGL 渲染 元宇宙 Metaverse webgpu

有没有好用的低代码平台,支持本地私有化部署的?

优秀

低代码 私有化部署

多因子认证是什么意思?与双因子认证有什么区别?

行云管家

身份认证 双因子认证 账户安全

前端开发SpringBoot之接口文档的生成

@零度

前端开发 springboot

25年,初心未改。

澳鹏Appen

人工智能 机器学习 训练数据 数据训练

☕【权限设计系列】「认证授权专题」史上最全的权限认证服务的权限模型大全

洛神灬殇

架构设计 12月日更 权限设计 功能设计

确保关键基础设施精确授时与同步的弹性、冗余和安全性

科技热闻

应用落地 智创未来 | 2021新一代人工智能院士高峰论坛昇腾人工智能应用专场成功举办

OpenI启智社区

人工智能 昇腾

Linux之find命令

入门小站

Linux

2022年之前,你不得不了解的一些 DevOps 趋势

SoFlu软件机器人

Token机制相对于Cookie机制的优势

郑州埃文科技

数据库 IP Token API

大数据埋点如何实现、验证和管理

融云 RongCloud

物联网之智慧农业应用分析&大数据之数据挖掘技术的应用

亚马逊云科技 (Amazon Web Services)

人工智能 云计算 大数据 物联网

百度APP视频播放中的解码优化

百度开发者中心

视频 解码技术

带你熟悉鸿蒙轻内核Kconfig使用指南

华为云开发者联盟

Python 鸿蒙 LiteOS-M Kconfig kconfiglib

泉州有几家正规等保测评公司?在哪里?叫什么名字?

行云管家

网络安全 等保 等级保护 等保测评

恒源云(GPUSHARE)_有关【图像平滑】的论文小记

恒源云

深度学习 CV 图像处理

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