《Kubernetes生态架构图》
https://mp.weixin.qq.com/s/VwXe52A2gf1rpV2FZsTLtQ
https://gitbook.curiouser.top/
《Kubernetes多集群架构探索》
https://mp.weixin.qq.com/s/8__b9qPYVecC3661UlMtbw
《浅谈 Kubernetes 在生产环境中的架构》
https://mp.weixin.qq.com/s/K_RgxLG38QYqANMbp1QS5g
高可用方面:
《Kubernetes 高可用方案》
https://mp.weixin.qq.com/s/lwkDxKP3CxW-e-9EQ9WeVQ
《与 Kubernetes 共存:集群升级的4种方式》
https://mp.weixin.qq.com/s/9kkFVdff7dUnPhJjAtyOJQ
《Kubernetes应用之道:让Kubernetes落地的“三板斧”》
https://zhuanlan.zhihu.com/p/82666719
落地的“三板斧”
基础
Above Kubernetes,这种落地方式很好理解,就是你把原生的、标准的、无任何接触和侵入改动的社区版本的Kubernetes拿来,直接部署运行起来即可,完全在Kubernetes之上构建自己的应用,通过标准的Kubernetes API来访问集群。你可以完全跟着社区升级演进你的Kubernetes,保持与社区同步,完全借助于社区的力量维护你的Kubernetes。这种落地方式无疑是最理想的,你不必考虑与社区和业界的主流脱离,同时也降低了管理和运维的成本。
RBAC:基于角色的权限控制
Kubernetes 中所有的 API 对象,都保存在 Etcd 里。可是,对这些 API 对象的操作,却一定都是通过访问 kube-apiserver 实现的。其中一个非常重要的原因,就是你需要 APIServer 来帮助你做授权工作。
而在 Kubernetes 项目中,负责完成授权(Authorization)工作的机制,就是 RBAC:基于角色的访问控制(Role-Based Access Control)。
重要概念
Role:角色,它其实是一组规则,定义了一组对 Kubernetes API 对象的操作权限。
Subject:被作用者,既可以是“人”,也可以是“机器”,也可以是你在 Kubernetes 里定义的“用户”。
RoleBinding:定义了“被作用者”和“角色”的绑定关系。
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: mynamespace
name: example-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
这个 Role 对象的 rules 字段,就是它所定义的权限规则。在上面的例子里,这条规则的含义就是:允许“被作用者”,对 mynamespace 下面的 Pod 对象,进行 GET、WATCH 和 LIST 操作。
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-rolebinding
namespace: mynamespace
subjects:
- kind: User
name: example-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: example-role
apiGroup: rbac.authorization.k8s.io
这个RoleBinding 对象里定义了一个 subjects 字段,即“被作用者”。它的类型是 User,即 Kubernetes 里的用户。这个用户的名字是 example-user。
我们会看到一个 roleRef 字段。正是通过这个字段,RoleBinding 对象就可以直接通过名字,来引用我们前面定义的 Role 对象(example-role),从而定义了“被作用者(Subject)”和“角色(Role)”之间的绑定关系。
注意:
Role 和 RoleBinding 对象都是 Namespaced 对象(Namespaced Object),它们对权限的限制规则仅在它们自己的 Namespace 内有效,roleRef 也只能引用当前 Namespace 里的 Role 对象。
在大多数时候,我们其实都不太使用“用户”这个功能,而是直接使用 Kubernetes 里的“内置用户”。这个由 Kubernetes 负责管理的“内置用户”,正是我们前面曾经提到过的:ServiceAccount。
apiVersion: v1
kind: ServiceAccount
metadata:
namespace: mynamespace
name: example-sa
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-rolebinding
namespace: mynamespace
subjects:
- kind: ServiceAccount
name: example-sa
namespace: mynamespace
roleRef:
kind: Role
name: example-role
apiGroup: rbac.authorization.k8s.io
在这个 RoleBinding 对象里,subjects 字段的类型(kind),不再是一个 User,而是一个名叫 example-sa 的 ServiceAccount。
而 roleRef 引用的 Role 对象,依然名叫 example-role