1. Kerberos票据过期的真实代价为什么这个问题必须自动化在大数据集群运维里Kerberos票据过期这件事表面上看只是klist输出里多了一行Expired实际上引发的连锁反应会让人非常头疼。我见过太多团队在凌晨两点的Spark任务失败后爬起来手动kinit折腾半小时才发现根源只是一个过期票据。尤其是以Hadoop、Spark、HBase、Kafka为核心的实时数仓或数据平台Kerberos的安全认证是贯穿数据读写、YARN资源调度、HDFS NameNode访问的全链路任何一环的票据失效都会让作业瞬间崩掉。更麻烦的是Kerberos票据默认的有效期往往只有24小时甚至更短而长时间运行的流式任务、凌晨批处理任务、跨天的数据同步作业比比皆是。你不可能要求运维同学每天盯着时钟去手动刷新也不应该指望调度平台碰巧在票据过期前拉起任务。所以Kerberos票据自动续期方案从不是一个锦上添花的技巧而是生产环境稳定性的刚需。这篇文章不会只丢给你一个脚本而是会完整拆解票据续期的原理、不同自动续期方案的取舍、生产落地步骤以及我在实际维护中踩过的坑。无论你是刚接手Kerberos集群的初级运维还是已经在用crontab跑kinit但总觉得不踏实的中级工程师这篇文章应该都能帮你在自动续期这件事上做得更扎实。2. 先搞懂票据生命周期TGT、SGT与Renewable机制2.1 TGT和SGT到底是怎么产生的Kerberos认证体系里有三类核心参与者客户端、KDCKey Distribution Center通常由KDC server或AD域控承担、以及服务端比如HDFS NameNode、HBase Master。客户端想要访问某个服务第一步是向KDC的ASAuthentication Service发起AS-REQ用用户密码或keytab进行身份校验。校验通过后KDC会返回一个TGTTicket Granting Ticket这个TGT相当于一张临时身份证证明你已经在KDC那里认证过了。然后当客户端真的要访问HDFS或HBase时它会拿TGT向KDC的TGSTicket Granting Service换取SGTService Granting Ticket。SGT才是真正对特定服务有效的票据比如hdfs/hostnameREALM或者HTTP/hostnameREALM。整个过程中TGT是母票据SGT是子票据两者都有各自的有效期。通常我们在服务器上执行klist看到的krbtgt/YOUR.REALMYOUR.REALM就是TGT剩下的一堆hdfs/...、HTTP/...就是SGT。理解这个层级关系是配置自动续期的前提因为绝大多数自动续期方案核心动作就是刷新TGT。TGT一旦刷新成功后续各服务SGT可以在需要时重新向KDC申请。如果TGT过期了客户端向TGS换取新SGT的请求会被直接拒绝作业就在这一步失败。2.2 Credential Cache票据被放在哪里票据不是凭空存在的它必须被写入一个客户端本地的缓存文件也就是Credential Cache。最常见的缓存类型是FILE:/tmp/krb5cc_uidLinux下root用户通常是FILE:/tmp/krb5cc_0普通用户是FILE:/tmp/krb5cc_1000这样的名义路径。Hadoop生态里建议通过环境变量KRB5CCNAME来指定缓存位置比如export KRB5CCNAMEFILE:/tmp/krb5cc_prod如果不设置很多组件会默认去找/tmp/krb5cc_$(id -u)在多账号环境里很容易互相踩踏或者因为写权限问题导致kinit失败。我强烈建议在任何脚本里显式指定KRB5CCNAME这能规避掉一大批诡异问题。缓存文件里保存的是TGT以及已经请求到的SGT它们的有效期字段分别用krb5_ccache结构存储。klist -v可以看到详细的时间信息。续期的本质就是用已有的仍然有效或者说仍在可续期窗口内的TGT去向KDC要一个延长有效期的TGT而不是重新走一遍密码认证。2.3 Renewable和Renew Lifetime续期窗口到底有多长很多人误以为只要票据还在有效期内就能续期其实不对。Kerberos协议里有一个关键属性叫renewable以及对应的renew_lifetime。默认情况下KDC允许的renew_lifetime通常是7天或者更长而票据本身的lifetime可能只有24小时。这意味着如果票据在初始生命周期内默认24h你可以直接kinit -R续期续出来的新票据生命周期重新变成24h。如果票据已经超过了初始生命周期但仍落在renew_lifetime窗口内比如第3天你依然可以用kinit -R续期前提是KDC配置里允许renewable。如果超过了renew_lifetime那kinit -R会直接失败必须重新用密码或keytab做完整认证。所以自动续期的第一性原理是在票据的renew_lifetime窗口内周期性执行kinit -R让票据的有效期始终向前滚动。如果renew_lifetime只有7天而你7天内没有执行任何续期动作那么第8天就只能重新kinit。这就要求你的续期频率必须远小于renew_lifetime否则会碰到硬边界。在实际生产配置中我会把renew_lifetime尽量调大比如在KDC侧设置为30天同时让自动续期任务每12小时跑一次。这样即使某个时段KDC短暂不可用错过几次续期窗口依然还有很大的冗余空间。下面通过一张表格梳理票据生命周期中几个关键时间点的含义时间点/周期含义续期影响获取时间auth time首次AS-REQ认证成功的时间影响票据年龄判断开始时间start time票据生效时间通常等于获取时间生效前无法使用结束时间end time票据原始生命周期结束时间在此时间前可正常使用之后必须续期或重认证续期截止时间renew till允许通过kinit -R续期的最终时间超过后只能重新kinit这张表是我排查票据问题时必看的。很多时候作业失败并不是票据过期而是票据还没到生效时间尤其是时钟漂移时会出现not yet valid的报错后面我会单独讲。2.4 为什么不能简单地把kinit放进任务调度里有一个常见的错误思路既然票据会过期那我每天在调度平台里塞一个kinit任务不就行了这确实能解决一部分问题但缺陷也很明显调度平台的任务节点可能和真正运行Spark/HDFS客户端的节点不是同一台你在A机器上续了票据B机器上的票据还是旧的。调度任务如果失败不会自动重试也不一定会告警问题仍然会被隐藏到深夜爆发。kinit需要读取keytab文件或者密码如果keytab权限管理不当每个能登录服务器的用户都能看到凭证安全隐患比票据过期严重得多。调度平台本身若需要依赖Kerberos认证才能运行那就会陷入鸡生蛋困境。所以正确思路是把自动续期做成操作系统级别的定时服务让它在客户端本机、以最小化权限运行并且带有日志和失败告警。这就引出了下面要聊的几种方案选型。3. 自动续期方案的选型对比从crontab到systemd timer再到Agent3.1 根基keytab是自动续期的前提在聊具体方案之前必须先说清楚keytab的角色。自动续期通常不需要人的密码而是使用keytab文件。keytab本质是一个保存了主体principal和对应加密密钥的文件它可以让客户端无交互地完成Kerberos认证。在大数据集群里常见的操作是# 在KDC服务器上用kadmin.local创建主体并导出keytab sudo kadmin.local -q addprinc -randkey hdfs/prod-hadoop01EXAMPLE.COM sudo kadmin.local -q ktadd -norandkey -k /tmp/hdfs.keytab hdfs/prod-hadoop01EXAMPLE.COM随后把/tmp/hdfs.keytab安全地拷贝到目标客户端主机的/etc/security/keytabs/目录并设置权限sudo install -o root -g hadoop -m 440 /tmp/hdfs.keytab /etc/security/keytabs/hdfs.headless.keytab生产环境强烈建议用headless principal即不登录控制台的专用服务账号不要把个人用户密码导进keytab。这样即使keytab泄露也只会影响服务账号不会波及管理员本人。同时keytab文件权限最好控制在440或400仅允许运行服务的账号和root读取。3.2 方案一crontab定时脚本这是最朴素、也最容易上手的方式在/etc/cron.d/kerberos_renew里写一行*/30 * * * * root /usr/local/bin/krb-renew.sh /var/log/krb-renew.log 21脚本内容大体是#!/usr/bin/env bash export KRB5CCNAMEFILE:/tmp/krb5cc_prod /usr/bin/kinit -R -k -t /etc/security/keytabs/hdfs.headless.keytab hdfs/prod-hadoop01EXAMPLE.COM优点简单、透明、几乎零依赖。缺点则是cron无法感知上一次执行是否成功日志只能靠grep。如果脚本因为网络抖动卡住cron会不断拉起新实例可能产生并发kinit并发写同一个ccache容易导致缓存损坏。cron在容器化环境里经常被禁用扩展性差。我在小型测试集群里用过一段时间cron最大的感受是能用但不体面。对于一两台机器、业务不敏感的环境没问题但到了中型集群我建议直接升级到systemd timer。3.3 方案二systemd timer生产推荐systemd timer比cron更合适的原因有三个可以持久化执行状态、可以等待上次任务结束后再启动下一次、可以通过OnFailure触发告警。它和cron一样是操作系统内置能力不需要额外部署Agent非常适合做Kerberos票据自动续期。我会在下一章给出完整的unit配置。这里先列一下关键优势Persistenttrue即使机器在规划时间点处于关机状态开机后也会补执行这对正好在续期窗口内关机的场景非常有用。不会重复并发你可以在service里加ExecStart逻辑并在timer里设置RandomizedDelaySec和有效的重复间隔避免两台进程同时写缓存。日志统一进journald可以用journalctl -u krb-renew.service查看排查问题极其方便。3.4 方案三组件自带的续期机制在Hadoop生态中如果你用的是kinit -R自己维护票据那其实是在和Hadoop的UserGroupInformationUGI机制并行工作。Hadoop自身其实有hadoop.auth的KerberosRenewalThread它会在Java进程内部维护票据续期。但这要求你正确配置dfs.namenode.kerberos.principal等参数并且让HDFS客户端在用UserGroupInformation.loginUserFromKeytab登录后由UGI内部线程自动续期。这里有个容易被忽视的细节UGI的自动续期只保证Java进程内的Subject票据有效并不会去刷新你shell里那个FILE:/tmp/krb5cc_*缓存。所以如果你的平台同时有shell脚本直接调用HDFS CLI、又有Java作业运行两者需要分别处理。我通常的做法是Java作业靠UGI内部续期shell脚本和CLI靠systemd timer续期两条线并行互不干扰。类似地某些服务比如Kafka、Zookeeper也有自己的JAAS配置里面可以通过keyTab和principal参数让JVM每30分钟自动重读keytab属于组件级方案。这种方案的好处是深度绑定应用生命周期坏处则是只能覆盖单一组件而且一旦配置错误排查路径比较长。3.5 方案四商业/自研Agent如果你管理的机器超过几十上百台逐台配置systemd timer也会变得痛苦。这时候一个集中式Agent确实更合适。它可以做三件事上报每台主机的票据状态通过klist或者解析ccache文件定期下发续期指令统一执行kinit -R在续期失败时自动通过webhook发告警。自研Agent并不复杂核心就是在上面systemd timer脚本的基础上包一层HTTP API和心跳上报。如果你对这个方向有兴趣也不必一开始就写Java/Go用Python写一个守护进程配合ansible批量部署也可以达到类似效果。但要注意Agent一旦成为了票据续期的单点它本身的高可用就得设计好否则Agent挂了比cron挂了的破坏力更大。3.6 选型建议我用一张表总结上述方案的适用场景方便你对照判断方案适用规模运维成本可靠性推荐指数crontab1-3台极低中备选systemd timer3-50台低高主力推荐组件自带续期UGI/JAAS特定Java应用中高必须开启自研Agent/商业方案50台以上中高很高规模化后推荐我个人建议先上systemd timer再逐步把Java组件的自带续期逻辑打开最后视规模决定是否自研Agent。这套组合拳最经济也最容易排查问题。4. 生产落地基于keytabsystemd timer的自动续期实践4.1 环境准备与前置条件在动手写systemd单位文件之前请先确认以下几点否则后面大概率会踩坑客户端已经安装krb5-userDebian/Ubuntu或krb5-workstationRHEL系kinit、klist、kdestroy命令可用。/etc/krb5.conf里的default_realm、KDC地址、realm映射都正确。多realm环境下尤其要重点确认。已经用keytab完成过一次手动认证kinit -k -t /path/to/keytab principal并且klist能看到票据。时钟同步正常。Kerberos对时间偏差容忍度通常是5分钟超过就会报Clock skew too great。最好集群内统一配置NTP或chrony。如果手动认证都过不去那自动续期就无从谈起。但有一个特殊情况有些KDC本身没有开启renewable你在klist里看不到renew until字段这会导致kinit -R永远失败。处理方法是先检查KDC侧配置# 在KDC的kdc.conf里 [realms] EXAMPLE.COM { max_life 24h max_renewable_life 30d }改完要重启krb5kdc服务。注意max_renewable_life只对之后新发的票据生效已发票据的续期截止时间不会自动改变。4.2 编写续期脚本不只是执行kinit -R一个合格的续期脚本必须做好四件事指定缓存路径、尝试续期、续期失败时兜底重新认证、输出结构化日志。下面是我在实际生产里使用的脚本你可以直接参考#!/usr/bin/env bash set -euo pipefail # 统一缓存路径避免和系统默认缓存冲突 export KRB5CCNAMEFILE:/tmp/krb5cc_kerberos_renew PRINCIPALhdfs/prod-hadoop01EXAMPLE.COM KEYTAB/etc/security/keytabs/hdfs.headless.keytab LOG_TAGkrb-renew log_info() { echo $(date %Y-%m-%d %H:%M:%S) [INFO] $* } log_warn() { echo $(date %Y-%m-%d %H:%M:%S) [WARN] $* } log_error() { echo $(date %Y-%m-%d %H:%M:%S) [ERROR] $* 2 } # 1. 先看缓存是否存在以及票据状态 if klist -s 2/dev/null; then log_info 当前缓存存在有效票据尝试直接续期 if kinit -R 2/dev/null; then log_info kinit -R 续期成功 klist -v exit 0 else log_warn kinit -R 失败尝试使用keytab重新认证 fi else log_warn 缓存不存在或票据已过期使用keytab重新认证 fi # 2. 兜底完整认证 if kinit -k -t $KEYTAB $PRINCIPAL 2/dev/null; then log_info 完整认证成功新票据已写入 $KRB5CCNAME klist -v else log_error 完整认证失败请检查keytab和principal exit 1 fi需要注意脚本里的klist -s只检查默认缓存所以我提前把KRB5CCNAME导出。kinit -R失败时我们用-k -t重新认证。这样即便错过了renew_lifetime窗口也能自动恢复。另外set -euo pipefail是我写脚本的习惯它能防止命令静默失败。但要注意kinit -R失败时会导致脚本退出所以我给它包了一个if条件这才是正确写法。4.3 Systemd Service和Timer的完整配置新建/etc/systemd/system/kerberos-renew.service[Unit] DescriptionKerberos ticket renewal service Documentationman:kinit(1) Afternetwork-online.target Wantsnetwork-online.target [Service] Typeoneshot Userroot Grouproot ExecStart/usr/local/bin/krb-renew.sh Nice19 IOSchedulingClassidle StandardOutputjournal StandardErrorjournal TimeoutStartSec60 # 万一脚本异常卡住60秒后强制终止为什么用Typeoneshot因为续期脚本是一个一次性任务跑完就退出不需要常驻进程。配合timer定时触发即可。再新建/etc/systemd/system/kerberos-renew.timer[Unit] DescriptionTrigger Kerberos ticket renewal periodically [Timer] OnBootSec10min OnUnitActiveSec6h RandomizedDelaySec5min Persistenttrue [Install] WantedBytimers.target参数解释OnBootSec10min开机后10分钟执行一次给网络和KDC启动留出余量。OnUnitActiveSec6h上一次执行成功后再过6小时执行下一次。这个间隔远小于常见的24小时票据生命周期足够安全。RandomizedDelaySec5min避免同批机器同时续期打爆KDC这是很多运维容易忽略的点。几十台机器如果同时向KDC发请求KDC压力会骤增尤其在小规格KDC上可能直接影响认证延迟。Persistenttrue机器关机错过了执行时间开机后会自动补执行。然后启用timersudo systemctl daemon-reload sudo systemctl enable --now kerberos-renew.timer sudo systemctl start kerberos-renew.service检查状态systemctl status kerberos-renew.timer systemctl list-timers | grep kerberos journalctl -u kerberos-renew.service -n 50如果一切正常你会看到类似这样的输出日期 时间 [INFO] kinit -R 续期成功4.4 把续期后的缓存对接到Hadoop和Spark客户端脚本续期成功只是第一步关键的衔接点是让Hadoop里的程序能找到这个缓存。如果你直接操作HDFS CLI需要设置环境变量export KRB5CCNAMEFILE:/tmp/krb5cc_kerberos_renew hdfs dfs -ls /如果是Spark提交作业可以在spark-submit时加上spark-submit \ --conf spark.kerberos.access.hadoopFileSystemshdfs://prod-cluster \ --principal hdfs/prod-hadoop01EXAMPLE.COM \ --keytab /etc/security/keytabs/hdfs.headless.keytab \ ...Spark的--principal和--keytab会自己管理一套票据和shell层面的KRB5CCNAME是两回事不要混为一谈。如果你希望Spark复用systemd timer续期好的票据就需要在启动命令前显式export KRB5CCNAMEFILE:/tmp/krb5cc_kerberos_renew并且确保Spark进程有权限读取这个文件。这听起来基础但我在实际项目里见过好几个人在Spark UI里报Kerberos错误最后发现只是环境变量没传透。对于长时间的Structured Streaming作业推荐使用--principal和--keytab方式让Spark自己管理这样最稳定。systemd timer适合为CLI和普通脚本提供票据保障。4.5 日志和监控的接入一旦部署了systemd timer后续维护的核心就是监控续期是否成功。我的建议是至少覆盖两个维度第一本地journald。通过journalctl -u kerberos-renew.service --since today查看续期日志如果出现[ERROR]说明有持续失败需要介入。第二集中式监控。把续期任务的关键指标暴露给Prometheus或者自研监控平台。最简单粗暴的方式是在脚本末尾输出一个指标文件cat /var/lib/node_exporter/kerberos_renew.prom EOF # HELP kerberos_renew_success 最近一次续期是否成功 # TYPE kerberos_renew_success gauge kerberos_renew_success $( [ -f /tmp/krb5cc_kerberos_renew ] klist -s 2/dev/null echo 1 || echo 0 ) EOF配合node_exporter的textfile收集器就可以在Grafana里画一张Kerberos票据续期状态的面板。这个细节看起来不起眼却能让你从用户报障才知道票据过期变成票据过期前就已经发现异常。5. 踩坑清单时间偏差、缓存锁、keytab轮换与多客户端并发5.1 时钟偏差是头号杀手Kerberos协议对时间戳极其敏感。默认配置下客户端与KDC的时间偏差超过5分钟认证就会失败报错是kinit: Client xxxREALM not found或者Clock skew too great。很多人在排查时会误以为是principle写错了绕一大圈才发现那是时间问题。在生产集群里我要求所有节点统一使用同一个NTP服务器并且把/etc/krb5.conf里的libdefaults设置为[libdefaults] clockskew 300 udp_preference_limit 1udp_preference_limit 1是个小技巧它让客户端尽量使用TCP而不是UDP和KDC通信避免大尺寸票据在UDP传输中被截断。虽然这和续期关系不大但能减少很多莫名其妙的认证失败。时钟同步问题还会引发另一种场景你手动klist看到的票据时间没问题但某台作业节点时间偏慢导致HDFS客户端认为票据还没生效结果报not yet valid。这类问题通过NTP解决后基本不会再出现。5.2 多个脚本并发写同一个缓存如果你同时部署了crontab和systemd timer或者两部机器有多个Agent在跑同一个KRB5CCNAME会出现缓存文件被并发写坏的情况。常见的表象是klist报No credentials cache found但文件明明存在或者klist能看到票据但kinit -R一直失败。我处理这个问题的方法很简单在同一台机器上只保留一种自动续期机制并且全部指向同一个缓存路径。如果实在要并发那就给脚本加文件锁exec 9/var/lock/kerberos-renew.lock flock -n 9 || { log_warn 已有续期任务在运行跳过本次; exit 0; }用flock做互斥能在多进程环境下避免同一时刻两个kinit同时写ccache。这个问题在容器化部署时尤其常见多个Pod共享宿主机卷配置不慎就会互相干扰。5.3 keytab轮换导致的隐性问题定期轮换keytab是安全审计的好习惯但轮换过程很容易踩坑。如果你直接在KDC上用ktadd重新导出同名keytab会生成新密钥版本号kvno而客户端缓存的旧票据仍然属于旧kvno。这时候如果你不销毁缓存理论上旧票据还能用直到过期但新发起的认证请求会要求客户端使用新keytab一旦客户端脚本仍然引用旧的keytab路径认证就会失败。更隐蔽的是有些环境里有多个服务共享同一个keytab比如HTTP/prod-host这个principal同时被HDFS和YARN使用。轮换keytab时必须保证所有引用它的服务都能及时拿到新文件并重新加载。我的建议是建立keytab版本目录例如/etc/security/keytabs/v20240601/。轮换后更新systemd service文件里的ExecStart参数指向新路径。轮换后强制执行一次systemctl restart kerberos-renew.service主动验证新keytab是否可用。如果是Java组件还要重启相关服务或者触发一次JAAS重载否则Java进程内存里的旧keytab会持续用于认证。5.4 续期失败时的自动降级不能只依赖kinit -Rkinit -R虽然轻量但它有一个脆弱点必须要求现有TGT仍处于renewable窗口内。如果因为KDC故障、网络分区你的脚本连续几天没执行或者时间偏差超过阈值kinit -R就会失败。纯靠kinit -R的自动续期方案在这个场景下会彻底失效。所以我在脚本里专门设计了兜底重新认证逻辑。这个逻辑不能省略它是自动续期方案从只能续命升级为能自我修复的关键一步。当kinit -R失败时如果能用keytab做完整认证那就执行kinit -k -t如果完整认证也失败才真正需要人工干预。这层降级机制让我的生产集群在KDC短暂故障恢复后不需要人工介入就能自动恢复票据。5.5 多客户端主机、多principal并发续期的容量规划如果一台客户端机器上运行了多个服务账号比如hdfs、yarn、hbase三个principal你不能只续一个票据。脚本可以设计成循环处理多个principal#!/usr/bin/env bash set -euo pipefail declare -A KEYTAB_MAP( [hdfs/prod-hadoop01EXAMPLE.COM]/etc/security/keytabs/hdfs.headless.keytab [yarn/prod-hadoop01EXAMPLE.COM]/etc/security/keytabs/yarn.headless.keytab [hbase/prod-hadoop01EXAMPLE.COM]/etc/security/keytabs/hbase.headless.keytab ) for principal in ${!KEYTAB_MAP[]}; do keytab${KEYTAB_MAP[$principal]} export KRB5CCNAMEFILE:/tmp/krb5cc_${original_user}_$(echo $principal | md5sum | cut -c1-8) if klist -s 2/dev/null kinit -R 2/dev/null; then log_info $principal 续期成功 elif kinit -k -t $keytab $principal 2/dev/null; then log_info $principal 完整认证成功 else log_error $principal 认证失败 fi done这种多缓存方案可以避免不同principal互相覆盖。但也要注意机器数量多、principal数量多时KDC的认证请求会显著增加。建议把RandomizedDelaySec调大分散请求时间防止所有机器在同一分钟挤满KDC。5.6 安全边界千万别把keytab权限放开我见过不少团队为了方便把keytab文件权限设置成644甚至放在home目录里。这非常危险。keytab相当于服务器的永不过期密码任何人只要拿到它就能冒充对应主体。正确的做法是keytab文件所属用户设为运行服务的账号组设为平台管理员组权限为440或400。目录权限设为750避免其他普通用户遍历。不要把keytab打进Docker镜像通过挂载卷或 secret 管理的方式注入。配置审计定期检查keytab的ls -l结果防止权限被无意修改。6. 从自动续期到平台化最终我留下的几条经验6.1 不要把续期和作业生命周期耦合得太紧有些团队喜欢在Spark提交命令里每次执行kinit试图让作业启动时总是有有效票据。这套做法在批处理场景下可用但在流式计算、常驻服务上非常不推荐。作业一旦跑起来就是几个小时甚至几天启动时的票据过期了作业中段依然会失败。真正合理的设计是票据续期应该是独立于作业的系统级能力作业通过KRB5CCNAME或JAAS配置去消费这个能力。把续期机制从业务作业中剥离出来才能让任何类型的作业都获得安全保障。6.2 续期不是越频繁越好续期间隔太短比如每1分钟执行一次虽然看起来保险实则有两个问题一是对KDC造成不必要的认证压力二是频繁写ccache文件会增加缓存损坏概率。按我的经验对于默认24小时票据有效期每6小时续期一次就足够了。如果你的票据有效期短低于4小时可能需要每1小时续一次但这种情况我更建议先调整KDC的max_life而不是频繁续期。6.3 让klist成为你的巡检起点最后分享一个日常小技巧每次登录服务器先执行klist -v查看票据的Renew till时间。如果这个时间距离当前时间不足24小时说明KDC的max_renewable_life配置偏小或者自动续期可能已经好几天没有成功执行。理论上一套健康的自动续期系统会让票据的Renew till始终稳定在最大值附近。我在实际维护中已经把systemctl list-timers | grep kerberos加到了日常巡检脚本里把它和磁盘、CPU监控并列。票据续期这件事说大不大但一旦出问题所有Kerberos相关作业会同时间崩盘那种全平台瘫痪的观感会让人记忆深刻。提前用systemd timer和兜底重认证把它自动化是我在多次深夜排障后最想分享给大家的一件事。