2. OpenShift集群访问与自动化入口
在OpenShift平台上做自动化，第一步不是写脚本，而是让脚本“合法地说话”。OpenShift的每一次资源操作，最终都会落到API Server上，而API Server只认经过认证、授权并绑定到某个上下文的请求。理解oc CLI、kubeconfig、ServiceAccount、Token、OAuth这五个对象之间的关系，是自动化脚本能够稳定运行的前提。
一、从一次oc命令看访问链路
当执行 oc get pods -n demo 时，oc CLI 并不是直接连接某个节点，而是读取本地 kubeconfig 文件，从中取出当前 context 对应的集群地址、用户身份和命名空间，然后向 API Server 发起 HTTPS 请求。API Server 先做认证，确认“你是谁”；再做授权，确认“你能不能在这个命名空间里列 Pod”；最后才返回结果。自动化脚本要复现这个过程，就必须把 kubeconfig 中的关键要素显式化。
kubeconfig 通常由三部分组成：clusters 描述 API Server 地址和 CA 证书；users 描述身份凭据，可以是客户端证书、Token 或用户名密码；contexts 把 cluster、user 和 namespace 绑定在一起。当前使用的 context 由 current-context 字段指定。切换上下文本质上就是切换“访问哪个集群、以谁的身份、默认操作哪个命名空间”。
二、ServiceAccount与Token：自动化脚本的首选身份
用户通过 oc login 走的是 OAuth 流程，浏览器或命令行交互获取 Token，适合人工操作。但自动化脚本不能依赖交互，因此更常用 ServiceAccount。ServiceAccount 是命名空间级别的身份对象，Pod 内的进程默认会挂载一个 SA Token，外部脚本也可以显式创建 SA 并为其生成 Token。
在 OpenShift 4.x 中，推荐使用 oc create token 为 SA 签发短期 Token，例如：
oc create serviceaccount automation-sa -n demo
oc create token automation-sa -n demo --duration=24h
该命令返回一个 JWT 格式的 Token，可直接作为 Bearer Token 使用。相比旧版通过 Secret 获取长期 Token 的方式，短期 Token 更符合安全实践。拿到 Token 后，可以把它写入 kubeconfig：
oc config set-credentials automation-sa --token=<TOKEN>
oc config set-context automation-ctx \
--cluster=api.example.com:6443 \
--user=automation-sa \
--namespace=demo
oc config use-context automation-ctx
这样，后续所有 oc 命令或调用 client-go 的脚本都会以 automation-sa 的身份访问 demo 命名空间。需要注意的是，SA 默认没有任何权限，必须通过 RoleBinding 或 ClusterRoleBinding 授予最小必要权限。例如只允许读取 Pod：
oc create role pod-reader -n demo \
--verb=get,list,watch --resource=pods
oc create rolebinding automation-sa-pod-reader \
-n demo --role=pod-reader \
--serviceaccount=demo:automation-sa
三、OAuth与API Server的交互方式
OpenShift 的 OAuth 服务器是 API Server 的认证扩展。用户执行 oc login 时，oc 会向 OAuth 服务器发起请求，获取访问 Token，并写入 kubeconfig。OAuth Token 默认有效期较短，但 oc 会自动刷新。对于自动化场景，如果必须使用用户身份，可以通过 oc login --token= 直接传入已有 Token，跳过交互。
无论使用 SA Token 还是 OAuth Token，最终都是通过 HTTPS 请求的 Authorization: Bearer <token> 头传递给 API Server。API Server 验证 Token 签名和有效期后，解析出用户身份和所属组，再交给 RBAC 判断权限。因此，排查自动化脚本认证失败时，可以按以下顺序检查：Token 是否过期、kubeconfig 中 cluster 地址是否正确、CA 证书是否匹配、RBAC 是否授予了对应动词和资源。
KUBECONFIG 环境变量指向该文件。任务结束后立即删除临时文件，避免凭据泄露。
四、上下文切换的常见操作与判断
多集群、多命名空间场景下，上下文切换是自动化脚本的常见动作。可以用 oc config get-contexts 查看所有上下文，用 oc config current-context 确认当前上下文。脚本中建议不要依赖全局 current-context，而是通过 --context 参数显式指定，例如：
oc --context=automation-ctx get pods -n demo
oc --kubeconfig=/tmp/ci-kubeconfig --context=prod-ctx get nodes
判断上下文是否生效，可以观察 oc whoami 返回的身份和 oc project 返回的命名空间。如果 oc whoami 返回 system:serviceaccount:demo:automation-sa，说明当前使用的是 SA 身份；如果返回用户名，则说明使用的是 OAuth 用户身份。两者在 RBAC 中的主体名称不同，授权时不能混用。
| 对象 | 作用 | 自动化中的典型用法 |
|---|---|---|
| oc CLI | 命令行客户端，读取 kubeconfig 并调用 API Server | 脚本中直接调用，配合 --context 和 --kubeconfig |
| kubeconfig | 保存集群、用户、上下文信息 | 为每个环境生成独立文件，通过 KUBECONFIG 切换 |
| ServiceAccount | 命名空间内的服务身份 | 为自动化任务创建专用 SA，绑定最小权限 Role |
| Token | 身份凭据，Bearer 形式传递 | 短期 Token 写入 kubeconfig，避免长期凭据 |
| OAuth | 用户认证入口，签发用户 Token | 人工登录使用；自动化优先改用 SA Token |
掌握这些对象之后，自动化脚本的认证与上下文切换就有了清晰的落点：用 ServiceAccount 建立稳定身份，用 Token 完成认证，用 kubeconfig 管理多环境上下文，用 oc CLI 或 client-go 与 API Server 交互。下一步才是围绕具体资源编写自动化逻辑。