ServiceAccount 為 Pod 中運行的進程提供了一個身份，Pod 內的進程可以使用其關聯服務賬號的身份，向集群的 APIServer 進行身份認證。
當創建 Pod 的時候規范下面有一個 spec.serviceAccount 的屬性用來指定該 Pod 使用哪個 ServiceAccount，如果沒有指定的話則默認使用 default 這個 sa。然后通過投射卷，在 Pod 的目錄 /run/secrets/kubernetes.io/serviceaccount/ 下有一個 token 令牌文件。我們通過 RBAC 對該 sa 授予了什么權限，那么容器里的應用拿著這個 token 后，就具備了對應的權限。
但是需要注意的是不同的 K8s 版本對該 token 文件的使用是不一樣的，所以我們這里分別進行下簡單說明。
<=1.20 版本
使用 kind 快速創建一個小于等于 v1.20 版本的集群：
? ? kind create cluster --name kind120 --image kindest/node:v1.20.15
? ? kubectl get nodes
NAME STATUS ROLES AGE VERSION
kind120-control-plane Ready control-plane,master 33s v1.20.15
我們先創建一個字為 sa-demo 的 ServiceAccount 對象：
? ? kubectl create sa sa-demo
? ? kubectl get sa
NAME SECRETS AGE
default 1 43s
sa-demo 1 6s
? ? kubectl get secret
NAME TYPE DATA AGE
default-token-dv78w kubernetes.io/service-account-token 3 46s
sa-demo-token-4gvbw kubernetes.io/service-account-token 3 8s
我們可以看到創建 sa 后自動生成了一個 secret，格式為 <saname>-token-xxxx，比如我們創建了一個名字為 sa-demo 的 sa 之后，系統自動創建了一個名字為 sa-demo-token-4gvbw 的 secret，這個 secret 里就包含了一個 token。
? ? kubectl describe secrets sa-demo-token-4gvbw
Name: sa-demo-token-4gvbw
Namespace: default
Labels: <none>
Annotations: kubernetes.io/service-account.name: sa-demo
kubernetes.io/service-account.uid: 1ae8eea9-acc6-4e3d-b378-07feb9146ac4
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1066 bytes
namespace: 7 bytes
token: eyJhbGciOiJSUzI1NiIsImtpZCI6ImhQNmFMNjAyaDZ5OElyMmtTNGdPUWxRdHVDU1A4aGFfVkJiNHdHMkZjQlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNhLWRlbW8tdG9rZW4tNGd2YnciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoic2EtZGVtbyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjFhZThlZWE5LWFjYzYtNGUzZC1iMzc4LTA3ZmViOTE0NmFjNCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OnNhLWRlbW8ifQ.j0DQmzTeSfagKYGc2dMUuzhYqVQh2puJAoQS0EMKeiAKD6rC4bUHWXWBrCu5Ttvpch6ZTEYwyCdRof1lDGWiLa3pJ1R1RwUNVQTCmVTZPs7tTuoGLRW0KGfEd0jyi4LU6uw4kA_6kwEsz4q2quWcB_fiH_Z3iKVfh1JolYTVAWTBMWnVn6gBvIrlXV5ny2oyvcPQeVfIek8aPQqhbsct_qOxrjqpZY8mpBz0ETR_EELjmcZxVVPLvomOdCqEqbV-FF5KRiFxizB3Xoh6NHz3EcsxpCZNRYdand-UFHaBQC9IPwJKzxhANGmuZuWJUCqCVGGRZTo9c6eoyVz831sZ0A
可以看到自動生成的這個 secret 對象里面包含一個 token，我們也可以通過下面的命令來獲?。?/p>
? ? kubectl get secrets sa-demo-token-4gvbw -o jsnotallow='{.data.token}' | base64 -d這個 token 是 JWT 結構的，我們可以把這個 token 復制到 jwt.io 網站進行解碼。
右側部分顯示了 token 被解碼之后的內容，其中 PAYLOAD 部分是 token 里包含的 sa-demo 的信息，可以看到里面沒有過期時間，也說明了該 token 是永不過期的。
現在我們使用上面我們創建的 sa 來運行一個 Pod：
# demo-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: demo
spec:
serviceAccount: sa-demo
containers:
- name: demo
image: nginx:1.7.9
ports:
- containerPort: 80
直接創建該 Pod 即可：
? ? kubectl apply -f demo-pod.yaml
? ? kubectl get pods
NAME READY STATUS RESTARTS AGE
demo 1/1 Running 0 81s
? ? kubectl get pod demo -oyaml
apiVersion: v1
kind: Pod
metadata:
name: demo
namespace: default
spec:
containers:
- image: nginx:1.7.9
imagePullPolicy: IfNotPresent
name: demo
# ......
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: sa-demo-token-4gvbw
readOnly: true
# ......
volumes:
- name: sa-demo-token-4gvbw
secret:
defaultMode: 420
secretName: sa-demo-token-4gvbw
Pod 創建后我們可以看到會自動將指定 sa 對應的 secret 掛載到容器的 /var/run/secrets/kubernetes.io/serviceaccount 目錄下去，所以現在該目錄下面肯定包含對應的 token 文件，我們可以查看該值來驗證下：
? ? kubectl exec -it demo -- cat /run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6ImhQNmFMNjAyaDZ5OElyMmtTNGdPUWxRdHVDU1A4aGFfVkJiNHdHMkZjQlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNhLWRlbW8tdG9rZW4tNGd2YnciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoic2EtZGVtbyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjFhZThlZWE5LWFjYzYtNGUzZC1iMzc4LTA3ZmViOTE0NmFjNCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OnNhLWRlbW8ifQ.j0DQmzTeSfagKYGc2dMUuzhYqVQh2puJAoQS0EMKeiAKD6rC4bUHWXWBrCu5Ttvpch6ZTEYwyCdRof1lDGWiLa3pJ1R1RwUNVQTCmVTZPs7tTuoGLRW0KGfEd0jyi4LU6uw4kA_6kwEsz4q2quWcB_fiH_Z3iKVfh1JolYTVAWTBMWnVn6gBvIrlXV5ny2oyvcPQeVfIek8aPQqhbsct_qOxrjqpZY8mpBz0ETR_EELjmcZxVVPLvomOdCqEqbV-FF5KRiFxizB3Xoh6NHz3EcsxpCZNRYdand-UFHaBQC9IPwJKzxhANGmuZuWJUCqCVGGRZTo9c6eoyVz831sZ0A
可以看到 Pod 里通過投射卷所掛載的 token 跟 sa-demo 對應的 secret 包含的 token 是模一樣的，這個 token 是永不過期的，所以即使刪除了 Pod 之后重新創建，Pod 里的 token 仍然是不變的，因為 secret 對象里面的 token 數據并沒有變化。
如果需要在 Pod 中去訪問 K8s 集群的資源對象，現在就可以為使用的 sa 綁定上相應的權限，然后在 Pod 應用中使用該對應的 token 去和 APIServer 進行通信就可以了，這個時候的 token 就能識別到對應的權限了。
>=1.21 版本 && <= 1.23 版本
接下來我們基于 >= 1.21 && <= 1.23 版本的 K8s 集群進行測試。
這里我們使用 kind 快速創建一個 v1.22.15 版本的集群：
? ? kind create cluster --name kind122 --image kindest/node:v1.22.15
? ? kubectl get nodes
NAME STATUS ROLES AGE VERSION
kind122-control-plane Ready control-plane,master 115s v1.22.15
同樣首先創建一個名為 sa-demo 的 ServiceAccount 對象：
? ? kubectl create sa sa-demo
? ? kubectl get sa
NAME SECRETS AGE
default 1 43s
sa-demo 1 6s
? ? kubectl get secret
NAME TYPE DATA AGE
default-token-9w9bp kubernetes.io/service-account-token 3 116s
sa-demo-token-g7d2g kubernetes.io/service-account-token 3 8s
同樣可以看到創建 sa 后系統也自動創建了一個對應的 secret 對象，和以前版本沒什么區別，我們也可以通過下面的命令來獲得該 secret 對象里面包含的 token 值：
? ? kubectl get secrets sa-demo-token-g7d2g -o jsnotallow='{.data.token}' | base64 -d
eyJhbGciOiJSUzI1NiIsImtpZCI6Im1ERkhnQ3Y3b1oxUmNHbWVhN210SDEwNXY2dVNkc0QzdXJjTkhsY21FRVEifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNhLWRlbW8tdG9rZW4tZzdkMmciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoic2EtZGVtbyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjI3ZGI0M2FjLTdjYjItNDQ2Yi05N2Q1LWU0MGUzOWRjZTg4YyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OnNhLWRlbW8ifQ.fnSaqrZKolTfz2pi9t32X38Er60WSzUoRHArte6qVmQ1NTaMis4F6rESWekeJvGW26szTJdll6vK8KtL_IRO2m6sp_fEAYfNMQMXL4CuaRByXeAavDqLgMHhodf4k4Yg-Mj4LCQ3aHOxojbAbPT1i_h17Ewivc39fmzp-dAXbHhhWhCW2Vl_CkM-F-UtzLyDwThvJedkeetrfyOOjE7K6HpzWfqIQyMUdCJog3WnFO_4kHXacFCgYg_gNPMYyViQAsTsxB8FplGdEzRuWKnQO9cDE55V4l55IxmE0er-dSSdG8085PzxaM_lMCtRI8YtjRjxcbxS5QkTm5R_ps0IsA同樣將該 token 值拷貝到 jwt.io 網站進行解碼。
從解碼后的值可以看到該 token 值里面同樣不包含任何過期時間，也說明了我們創建 sa 之后，所對應的 token 是永不過期的。
同樣我們再次使用上面的 sa 來創建一個 Pod，如下所示：
# demo-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: demo
spec:
serviceAccount: sa-demo
containers:
- name: demo
image: nginx:1.7.9
ports:
- containerPort: 80
直接創建該 Pod：
? ? kubectl apply -f demo-pod.yaml
? ? kubectl get pods
NAME READY STATUS RESTARTS AGE
demo 1/1 Running 0 81s
? ? kubectl get pod demo -oyaml
apiVersion: v1
kind: Pod
metadata:
name: demo
namespace: default
spec:
containers:
- image: nginx:1.7.9
imagePullPolicy: IfNotPresent
name: demo
ports:
- containerPort: 80
protocol: TCP
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: kube-api-access-6wmfb
readOnly: true
# ......
volumes:
- name: kube-api-access-6wmfb
projected:
defaultMode: 420
sources:
- serviceAccountToken:
expirationSeconds: 3607
path: token
- configMap:
items:
- key: ca.crt
path: ca.crt
name: kube-root-ca.crt
- downwardAPI:
items:
- fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
path: namespace
當 Pod 創建后查看對應的資源對象，可以看到和之前的版本已經有一個很大的區別了，并不是將上面自動創建的 secret 掛載到容器的 /var/run/secrets/kubernetes.io/serviceaccount 目錄。我們可以查看下 Pod 中的 token 值來和 secret 包含的 token 值進行對比：
? ? kubectl exec -it demo -- cat /run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6Im1ERkhnQ3Y3b1oxUmNHbWVhN210SDEwNXY2dVNkc0QzdXJjTkhsY21FRVEifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNzA1MDI1NDU4LCJpYXQiOjE2NzM0ODk0NTgsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0IiwicG9kIjp7Im5hbWUiOiJkZW1vIiwidWlkIjoiNzY1ODRmODAtZjU1My00Mzk2LWIxOTUtMDEwOTBhMzM4MWYyIn0sInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJzYS1kZW1vIiwidWlkIjoiMjdkYjQzYWMtN2NiMi00NDZiLTk3ZDUtZTQwZTM5ZGNlODhjIn0sIndhcm5hZnRlciI6MTY3MzQ5MzA2NX0sIm5iZiI6MTY3MzQ4OTQ1OCwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmRlZmF1bHQ6c2EtZGVtbyJ9.TAoe1eCHCXUoHh6oM4uySp8kzRaLQ44GZdU02Ir8m_dzYpdFSw4nwsNyqPggrZdDL3BMH4zceudBEdQuyxiSsrpVDeQKww2wTGhXAr2hWujrJq4ycmu6aMywyv2iRX9Vn-Las1giWK_bFuzCxiR10Lcgyd5N7VjB2WcT7K8rN7dAeUWgiH2s9lMOzoaIorUDXzlnSTcmxkhz1h7RXYKVGaqZBbd5wJsRnINZPGxqsS-wi21Aw2FFmIeeK8GGlnAqnS0f3VS1N2jm03gKPii-sMt0GARse4HsmhGAhyJnt9za6ZNpBgcybd7uEBjgIVrRFTkqBJOjPrAnMvRucVtwww
可以很明顯看到現在 Pod 中的 token 值和自動創建 secret 的 token 值不一樣了，同樣在 jwt.io 解碼該 token 值。
可以看到該 token 值解碼后的 PAYLOAD 數據中包含了很多不同的數據，其中的 exp 字段表示該 token 的過期時間，可以看到過期時間是 1 年。
這里我們可以總結下在 v1.21 到 v1.23 版本的 K8s 集群，當創建 ServiceAccount 對象后，系統仍然會自動創建一個 secret 對象，該 secret 對象里面包含的 token 仍然是永不過期的，但是 Pod 里面并不會使用該 secret 的 token 值了。
從上面查看創建后的 Pod 資源清單可以看出，現在創建 Pod 后，Kubernetes 控制平面會自動添加一個投射卷到 Pod，此卷包括了訪問 Kubernetes API 的 token，該清單片段定義了由三個數據源組成的投射卷，這三個數據源是：
- serviceAccountToken 數據源：包含 kubelet 從 kube-apiserver 獲取的令牌，kubelet 使用 TokenRequest API 獲取有時間限制的令牌。為 TokenRequest 服務的這個令牌會在 Pod 被刪除或定義的生命周期（默認為 1 小時）結束之后過期。該令牌綁定到特定的 Pod， 并將其 audience（受眾）設置為與 kube-apiserver 的 audience 相匹配。 這種機制取代了之前基于 Secret 添加卷的機制，之前 Secret 代表了針對 Pod 的 ServiceAccount 但不會過期。
- configMap 數據源：ConfigMap 包含一組證書頒發機構數據，Pod 可以使用這些證書來確保自己連接到集群的 kube-apiserver（而不是連接到中間件或意外配置錯誤的對等點上）。
- downwardAPI 數據源：用于查找包含 Pod 的名字空間的名稱，并使該名稱信息可用于在 Pod 內運行的應用程序代碼。
所以我們應該要指定現在版本的 K8s 集群創建的 Pod 里面包含的 token 不是使用 ServiceAccount 自動關聯的 secret 對象里面的 token 了，而是 kubelet 會向 TokenRequest API? 發送一個請求，申請一個新的 token 放在 Pod 的 /run/secrets/kubernetes.io/serviceaccount/token 里。這個 token 會在 1 個小時后由 kubelet 重新去申領一個新的 token，所以 1 小時之后再次查看這個 token 的話會發現 token 的內容是變化的，如果刪除此 Pod 重新創建的話，則會重新申領 token，被刪除 Pod 里的 token 會立即過期。
而且我們還可以手動使用 kubectl create token <sa> 命令來請求 ServiceAccount 的 token，可以指定有效期等：
? ? kubectl create token -h
Request a service account token.
Examples:
# Request a token to authenticate to the kube-apiserver as the service account "myapp" in the current namespace
kubectl create token myapp
# Request a token for a service account in a custom namespace
kubectl create token myapp --namespace myns
# Request a token with a custom expiration
kubectl create token myapp --duration 10m
# Request a token with a custom audience
kubectl create token myapp --audience https://example.com
# Request a token bound to an instance of a Secret object
kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret
# Request a token bound to an instance of a Secret object with a specific uid
kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret --bound-object-uid
0d4691ed-659b-4935-a832-355f77ee47cc
Options:
# ......
?>=?1.24 版本
現在我們再來看下 v1.24 版本以上的 K8s 集群中的 ServiceAccount token 是如何工作的。這里我們使用 kind 快速創建一個 v1.25.3 版本的集群：
? ? kind create cluster --name kind125 --image kindest/node:v1.25.3
? ? kubectl get nodes
NAME STATUS ROLES AGE VERSION
kind125-control-plane Ready control-plane,master 115s v1.25.3
同樣創建一個名為 sa-demo 的 ServiceAccount：
? ? kubectl create sa sa-demo
? ? kubectl get sa
NAME SECRETS AGE
default 0 39d
sa-demo 0 5s
? ? kubectl get secrets
No resources found in ns1 namespace
我們可以看到該 ServiceAccount 創建后并沒有創建對應的 Secret 對象。同樣接下來創建一個如下所示的 Pod：
# demo-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: demo
spec:
serviceAccount: sa-demo
containers:
- name: demo
image: nginx:1.7.9
ports:
- containerPort: 80
創建上面的 Pod 后查看詳情：
? ? kubectl apply -f demo-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: demo
namespace: default
spec:
containers:
- image: nginx:1.7.9
imagePullPolicy: IfNotPresent
name: demo
ports:
- containerPort: 80
protocol: TCP
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: kube-api-access-pftqd
readOnly: true
# ......
volumes:
- name: kube-api-access-pftqd
projected:
defaultMode: 420
sources:
- serviceAccountToken:
expirationSeconds: 3607
path: token
- configMap:
items:
- key: ca.crt
path: ca.crt
name: kube-root-ca.crt
- downwardAPI:
items:
- fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
path: namespace
可以看到創建 Pod 后同樣會自動添加一個投射卷到 Pod，此卷包括了訪問 Kubernetes API 的令牌，和 >=1.21 版本 && <= 1.23 版本 表現是一致的。同樣我們可以下查看 Pod 中的 token 值來進行驗證：
? ? kubectl exec -it demo -- cat /run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6IndnazJLZENQTktiZkxVejhnMnhmTHJYRTlkZ2ZnOHJGQmgwVW4td3BWd0kifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNzA0ODg0MDg0LCJpYXQiOjE2NzMzNDgwODQsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0IiwicG9kIjp7Im5hbWUiOiJkZW1vIiwidWlkIjoiMTY0ZTIwZTYtYjNjMi00ZmQ5LWI3ZTUtMDZjYTExZWIyOWM4In0sInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJzYS1kZW1vIiwidWlkIjoiYjJlNWM3ZmYtNjlhNy00NzYyLTkxMDctM2UxNzZhYmQ3NTdiIn0sIndhcm5hZnRlciI6MTY3MzM1MTY5MX0sIm5iZiI6MTY3MzM0ODA4NCwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmRlZmF1bHQ6c2EtZGVtbyJ9.lhYscyn_d9Y3GZSipSqGj4Jtsu8qsIyz34L18lv37HxjjGU_bQmUFCXYf_CRom8DfadHppmlaskZS18KmyTV1Z09BeujJd8viUnnYCWb9K6VJB5uPBYWLB0FETfgQy7Kqu8Gvk8qBKLjdCkl8U2vr2Oqd2qSEDyvqhNBQXnckQRH6wyypBUc7EXSGAJf6dPVE3c6XqnbXMJ7SRZb5svE-hv0lZKmJrouz9Ia4qxUXUtpzDlMPnHOym2x9d1TSSZ1Lp7BOsqTnxlUQVueh9w869jAajrP1G9e5zhZwZBfzRfARqCVqoLid_hOQP-mo4MLfHbn61SWItlCBd75nl2WLQ
我們可以把上面輸出的 token 值拷貝到 jwt.io 里進行解碼。
從上面的數據可以看到這里的 token 的有效期也為 1 年，這個 token 在 Pod 里也是每 1 小時會更新一次，如果 Pod 被刪除重建，那么會重新申領一個新的 token，被刪除 Pod 里的 token 立即過期。
需要注意的沒有特定的機制使通過 TokenRequest 簽發的令牌無效，如果你不再信任為某個 Pod 綁定的 ServiceAccount 令牌，你可以刪除該 Pod，刪除 Pod 將使其綁定的令牌過期。
總結
我們可以簡單總結下不同版本的 K8s 集群下面的 ServiceAccount Token 是如何工作的。
- 1.20（含 1.20）之前的版本，在創建 sa 時會自動創建一個 secret，然后這個會把這個 secret 通過投射卷掛載到 pod 里，該 secret 里面包含的 token 是永久有效的。
- 1.21~1.23 版本，在創建 sa 時也會自動創建 secret，但是在 pod 里并不會使用 secret 里的 token，而是由 kubelet 到 TokenRequest API 去申請一個 token，該 token 默認有效期為一年，但是 pod 每一個小時會更新一次 token。
- 1.24 版本及以上，在創建 sa 時不再自動創建 secret 了，只保留由 kubelet 到 TokenRequest API 去申請 token。
當然我們仍然可以手動創建 Secret 來保存 ServiceAccount 令牌，例如在你需要一個永不過期的令牌的時候。一旦手動創建一個 Secret 并將其關聯到 ServiceAccount，Kubernetes 控制平面就會自動將令牌填充到該 Secret 中。
盡管存在手動創建長久 ServiceAccount 令牌的機制，但還是推薦使用 TokenRequest 獲得短期的 API 訪問令牌。
