Ambassador链路失效及Pod崩溃排查：权限不足问题

问题根源分析 #

从你提供的日志能直接定位到两个核心权限故障：

1. system:serviceaccount:platform-ns:ambassador 账号没有权限读取default命名空间的namespaces资源（返回403 Forbidden）
2. 该账号缺少集群范围的权限，无法列出getambassador.io API组下的mappings资源

你之前执行的命令都是针对tiller服务账号的权限配置，和Ambassador的问题完全不相关，所以自然无法解决当前故障。

解决方案：为Ambassador配置正确的RBAC权限 #

步骤1：创建包含所需权限的集群角色

创建一个名为ambassador-cluster-role的集群角色，覆盖Ambassador运行需要的核心权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ambassador-cluster-role
rules:
# 解决读取namespaces的权限问题
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get"]
# 解决集群范围list mappings的权限问题
- apiGroups: ["getambassador.io"]
  resources: ["mappings"]
  verbs: ["list", "get", "watch"]
# 可选：添加Ambassador运行所需的其他常见权限（如服务、端点、密钥等）
- apiGroups: [""]
  resources: ["services", "endpoints", "secrets"]
  verbs: ["get", "list", "watch"]

把上述内容保存为ambassador-cluster-role.yaml，然后执行：

kubectl apply -f ambassador-cluster-role.yaml

步骤2：绑定集群角色到Ambassador的服务账号

将创建好的集群角色绑定到platform-ns命名空间下的ambassador服务账号：

kubectl create clusterrolebinding ambassador-cluster-binding \
  --clusterrole=ambassador-cluster-role \
  --serviceaccount=platform-ns:ambassador

步骤3：验证权限并重启Ambassador

执行以下命令验证权限配置是否生效：

kubectl auth can-i get namespaces/default --as=system:serviceaccount:platform-ns:ambassador
kubectl auth can-i list mappings.getambassador.io --as=system:serviceaccount:platform-ns:ambassador --all-namespaces

如果两个命令都返回yes，说明权限配置正确。最后重启Ambassador部署让权限生效：

kubectl rollout restart deployment ambassador -n platform-ns

额外说明 #

如果后续Ambassador还出现其他权限相关错误，可以根据日志提示，在集群角色中添加对应的资源和动词权限。Ambassador官方推荐的RBAC配置会包含更全面的权限，你可以根据实际业务需求调整上述集群角色的规则。

内容的提问来源于stack exchange，提问作者Sumana