实用至极，我从Kubernetes中学习到的5个架构经验

正文

请到「今天看啥」查看全文

而 Kubernetes 通过声明式方式实现的 Controller，则比较优雅的解决了这个问题。每个组件都只需要和 Etcd 这样的状态中心交互，完成自己的任务后把状态更新到 ETCD 中即可。如果失败则反复重试，直到失败条件解除。虽然任务的完成时间不可控，但可达到最终一致。

如果想进一步了解可以深入学习 Kubernetes 的 Pod，Service，ReplicaSet，Deployment，Autoscaling 不同组件之间的关系以及 Controller 的实现。

当然，申明式设计并不适合所有的系统，可以思考下哪些场景下比较适合这种设计。

思考：为什么 Kubernetes 一直没提供重启 Pod 的接口？大家普遍的概念里，一个部署系统，重启应用程序是一个必备功能。

参看这个从 2015 年开始讨论的 Issue:

https://github.com/kubernetes/kubernetes/issues/13488

如何设计出通用的 IAM 机制？

IAM（Identity and Access Management） 是所有企业级应用服务平台必须要考虑的功能之一。本想通过和各公有云的 IAM 机制的比较，来解析 Kubernetes 对安全认证机制的抽象和实现，学习和思考如何在自己的系统中设计出通用的 IAM 机制，但这里受限于篇幅，就简单分析下。

IAM 要解决的关键问题是：

1. 身份认证：通过什么凭证来证明自己的身份，比如 用户名密码，Token，证书等。

2. 访问权限控制：有哪些资源，不同的资源有什么操作（对应权限），如何定义权限集合，又如何和用户关联。

为了方便定义权限集合，一般需要引入 Role 的概念，一个 Role 对应一个权限集合，另外为了方便批量操作，会引入 Group 的概念把用户做一个集合。这个大体就是 Kubernetes RBAC（Role-based access control）的设计思路。

IAM 需要解决的另外一个问题是服务器端调用的身份认证问题。终端用户使用时，可以通过通用的身份凭证来校验用户，但如果两个系统之间需要互相调用呢？一种办法是创建一些系统账号，给比较高的权限，系统之前调用也是使用和终端用户一样的认证机制。带来的问题是这些账号的维护以及凭证的管理，密码等凭证泄露可能带来安全隐患。参考最近的某酒店拖库事件，最直接的原因是数据库地址以及账号密码被误提交到 GitHub，但根本原因是服务之间互相认证的凭证管理问题。

请到「今天看啥」查看全文