《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:定义了“被作用者”和“角色”的绑定关系。

  1. kind: Role
  2. apiVersion: rbac.authorization.k8s.io/v1
  3. metadata:
  4. namespace: mynamespace
  5. name: example-role
  6. rules:
  7. - apiGroups: [""]
  8. resources: ["pods"]
  9. verbs: ["get", "watch", "list"]

这个 Role 对象的 rules 字段,就是它所定义的权限规则。在上面的例子里,这条规则的含义就是:允许“被作用者”,对 mynamespace 下面的 Pod 对象,进行 GET、WATCH 和 LIST 操作。

  1. kind: RoleBinding
  2. apiVersion: rbac.authorization.k8s.io/v1
  3. metadata:
  4. name: example-rolebinding
  5. namespace: mynamespace
  6. subjects:
  7. - kind: User
  8. name: example-user
  9. apiGroup: rbac.authorization.k8s.io
  10. roleRef:
  11. kind: Role
  12. name: example-role
  13. 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。

  1. apiVersion: v1
  2. kind: ServiceAccount
  3. metadata:
  4. namespace: mynamespace
  5. name: example-sa
  1. kind: RoleBinding
  2. apiVersion: rbac.authorization.k8s.io/v1
  3. metadata:
  4. name: example-rolebinding
  5. namespace: mynamespace
  6. subjects:
  7. - kind: ServiceAccount
  8. name: example-sa
  9. namespace: mynamespace
  10. roleRef:
  11. kind: Role
  12. name: example-role
  13. apiGroup: rbac.authorization.k8s.io

在这个 RoleBinding 对象里,subjects 字段的类型(kind),不再是一个 User,而是一个名叫 example-sa 的 ServiceAccount。
而 roleRef 引用的 Role 对象,依然名叫 example-role

Operator