这两者之间有哪些实际区别?何时应该选择其中之一?
例如,如果我想让我的项目开发人员只能查看一个 Pod 的日志,似乎可以通过 RoleBinding 为 service account 或 context 分配这些权限。
这两者之间有哪些实际区别?何时应该选择其中之一?
例如,如果我想让我的项目开发人员只能查看一个 Pod 的日志,似乎可以通过 RoleBinding 为 service account 或 context 分配这些权限。
什么是Service Account?
来自文档
用户账户用于人员身份验证,Service Account则用于运行在Pod中的进程。
用户账户旨在全局使用...而Service Account只限于特定命名空间。
上下文
context
与kubeconfig
文件(~/.kube/config
)相关。如您所知,kubeconfig
文件是一个yaml文件,其中的context
部分包含了您的user/token
和cluster
引用。当您有多个集群时,context
非常有用,您可以在单个kubeconfig
文件中定义所有的cluster
和user
s,然后借助上下文进行切换 (例如:kubectl config --kubeconfig=config-demo use-context dev-frontend
)。
来自文档
apiVersion: v1
clusters:
- cluster:
certificate-authority: fake-ca-file
server: https://1.2.3.4
name: development
- cluster:
insecure-skip-tls-verify: true
server: https://5.6.7.8
name: scratch
contexts:
- context:
cluster: development
namespace: frontend
user: developer
name: dev-frontend
- context:
cluster: development
namespace: storage
user: developer
name: dev-storage
- context:
cluster: scratch
namespace: default
user: experimenter
name: exp-scratch
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
user:
client-certificate: fake-cert-file
client-key: fake-key-file
- name: experimenter
user:
password: some-password
username: exp
cluster
和user
的引用。service account
、Role
(或ClusterRole
)、RoleBinding
(或ClusterRoleBinding
)并生成包含服务帐户token
的kubeconfig
文件,并将其提供给您的开发人员。kubconfig
文件的脚本,需要传入服务帐户名称参数。随意查看。Role
和RoleBinding
,可能会有所帮助。kubectl
配置相关的抽象,其中上下文可以关联到服务账户。context
只是另一种身份验证方法。