abcee2dccd
* Update localization guidelines for language labels
Continuing work
Continuing work
Continuing work
More work in progress
Add local OWNERS folders
Add an OWNERS file to Chinese
Remove shortcode for repos
Add Japanese
Alphabetize languages, change weights accordingly
More updates
Add Korean in Korean
Add English to languageName
Feedback from gochist
Move Chinese content from cn/ to zh/
Move OWNERS from cn/ to zh/
Resolve merge conflicts by updating from master
Add files back in to prep for resolution
After rebase on upstream/master, remove files
Review and update localization guidelines
Feedback from gochist, tnir, cstoku
Add a trailing newline to content/ja/OWNERS
Add a trailing newline to content/zh/OWNERS
Drop requirement for GH repo project
Clarify language about forks/branches
Edits and typos
Remove a shortcode specific to a multi-repo language setup
Update aliases and owners
Add explicit OWNERS for content/en
Migrate content from Chinese repo, update regex in config.toml
Remove untranslated strings
Add trailing newline to content/en/OWNERS
Add trailing newlines to OWNERS files
add Jaguar project description (#10433)
* add Jaguar project description
[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight.
Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.
* Minor newline tweak
blog post for azure vmss (#10538)
Add microk8s to pick-right-solution.md (#10542)
* Add microk8s to pick-right-solution.md
Microk8s is a single-command installation of upstream Kubernetes on any Linux and should be included in the list of local-machine solutions.
* capitalized Istio
Add microk8s to foundational.md (#10543)
* Add microk8s to foundational.md
Adding microk8s as credible and stable alternative to get started with Kubernetes on a local machine. This is especially attractive for those not wanting to incur the overhead of running a VM for a local cluster.
* Update foundational.md
Thank you for your suggestions! LMK if this works now?
* Rewrote first paragraph
And included a bullet list of features of microk8s
* Copyedit
fix typo (#10545)
Fix the kubectl subcommands links. (#10550)
Signed-off-by: William Zhang <warmchang@outlook.com>
Fix command issue (#10515)
Signed-off-by: mooncake <xcoder@tenxcloud.com>
remove imported community files per issue 10184 (#10501)
networking.md: Markdown fix (#10498)
Fix front matter, federation command-line tools (#10500)
Clean up glossary entry (#10399)
update slack link (#10536)
typo in StatefulSet docs (#10558)
fix discription about horizontal pod autoscale (#10557)
Remove redundant symbols (#10556)
Fix issue #10520 (#10554)
Signed-off-by: William Zhang <warmchang@outlook.com>
Update api-concepts.md (#10534)
Revert "Fix command issue (#10515)"
This reverts commit c02a7fb9f9.
Update memory-constraint-namespace.md (#10530)
update memory request to 100MiB corresponding the yaml content
Blog: Introducing Volume Snapshot Alpha for Kubernetes (#10562)
* blog post for azure vmss
* snapshot blog post
Resolve merge conflicts in OWNERS*
Minor typo fix (#10567)
Not sure what's supposed to be here, proposing removing it.
* Feedback from gochist
Tweaks to feedback
* Feedback from ClaudiaJKang
4.2 KiB
4.2 KiB
approvers, title
| approvers | title | ||||
|---|---|---|---|---|---|
|
管理Service Accounts |
这是一篇针对service accounts(服务账户)的集群管理员指南。 它呈现了 User Guide to Service Accounts中的信息。
对授权和用户账户的支持已在规划中,当前并不完备,为了更好地描述service accounts,有时这些不完善的特性也会被提及。
用户账户与服务账户
Kubernetes 区分用户账户和服务账户的概念主要基于以下原因:
- 用户账户是针对人而言的。 服务账户是针对运行在pod中的进程而言的。
- 用户账户是全局性的。 其名称在集群各namespace中都是全局唯一的,未来的用户资源不会做namespace隔离, 服务账户是namespace隔离的。
- 通常情况下,集群的用户账户可能会从企业数据库进行同步,其创建需要特殊权限,并且涉及到复杂的业务流程。 服务账户创建的目的是为了更轻量,允许集群用户为了具体的任务创建服务账户 (即权限最小化原则)。
- 对人员和服务账户审计所考虑的因素可能不同。
- 针对复杂系统的配置可能包含系统组件相关的各种服务账户的定义。 因为服务账户可以定制化地创建,并且有namespace级别的名称,这种配置是很轻量的。
服务账户的自动化
三个独立组件协作完成服务账户相关的自动化:
- 服务账户准入控制器(Service account admission controller)
- Token控制器(Token controller)
- 服务账户控制器(Service account controller)
服务账户准入控制器
对pod的改动通过一个被称为Admission Controller的插件来实现。它是apiserver的一部分。 当pod被创建或更新时,它会同步地修改pod。 当该插件处于激活状态(在大多数发行版中都是默认的),当pod被创建或更新时它会进行以下动作:
- 如果该pod没有
ServiceAccount设置,将其ServiceAccount设为default。 - 保证pod所关联的
ServiceAccount存在,否则拒绝该pod。 - 如果pod不包含
ImagePullSecrets设置,那么 将ServiceAccount中的ImagePullSecrets信息添加到pod中。 - 将一个包含用于API访问的token的
volume添加到pod中。 - 将挂载于
/var/run/secrets/kubernetes.io/serviceaccount的volumeSource添加到pod下的每个容器中。
Token管理器
Token管理器是controller-manager的一部分。 以异步的形式工作:
- 检测服务账户的创建,并且创建相应的Secret以支持API访问。
- 检测服务账户的删除,并且删除所有相应的服务账户Token Secret。
- 检测Secret的增加,保证相应的服务账户存在,如有需要,为Secret增加token。
- 检测Secret的删除,如有需要,从相应的服务账户中移除引用。
你需要通过 --service-account-private-key-file 参数项传入一个服务账户私钥文件至Token管理器。 私钥用于为生成的服务账户token签名。
同样地,你需要通过 --service-account-key-file 参数将对应的公钥传入kube-apiserver。 公钥用于认证过程中的token校验。
创建额外的 API tokens
控制器中有专门的循环来保证每个服务账户中都存在API token对应的Secret。 当需要为服务账户创建额外的API token时,创建一个类型为 ServiceAccountToken 的Secret,并在annotation中引用服务账户,控制器会生成token并更新:
secret.json:
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {
"name": "mysecretname",
"annotations": {
"kubernetes.io/service-account.name": "myserviceaccount"
}
},
"type": "kubernetes.io/service-account-token"
}
kubectl create -f ./secret.json
kubectl describe secret mysecretname
删除/失效 服务账户token
kubectl delete secret mysecretname
服务账户管理器
服务账户管理器管理各命名空间下的服务账户,并且保证每个活跃的命名空间下存在一个名为 "default" 的服务账户