我觉得k8s的架构介绍最好不要一一细数，因为他的架构是看起来有点复杂，所以更倾向于从需要实现的功能开始推导到这个架构, 更方便记忆
Q-两个抉择:最小部署单位为Pod/Container A-希望多个相似的应用能部署到一起，比如说同时有两个应用这两个应用向外提供一项功能，但是这两个应用所依赖的环境，希望他们是咋隔开的，这些应用可能有不同的更新软件开发更新周期。加入的Pod这一个抽象以后我们就可以去批量管理Pod，而不是批量去管理container(抽象化, 批量管理, 就像函数一样).
Q-为什么Pod中是共享网络地址和文件系统, 而不是完全隔离. A-两个应用有一定耦合性
从上面我们已经知道了，说这个Pod就是一个最小单位，我们可以把这个pod看成是一个服务的实例. 然后这个服务实例必须有东西来管理，比如说我们后台同学用的一个容器管理平台，我们可以去控制他有多少个服务
K8s的设计是比这种普通的容器管理平台更多一级的，就相当于一个的多个服务的控制平台。这样的话他就相当于两组服务，比如他去同时管理MySQL服务+同时也去管理的读写服务，然后这是两组实例需要不同的管理方式, 比如实例数目/实例状态的要求, k8s在这里给了个Controller的概念, 种类有Deployment/StatefulSet/DaemonSet等
刚才说了Controller是维护Pod集群的, 或者我应该说Pod Repicas. 但这堆Pods的IP是volatile的, 需要有一个抽象对外提供稳定的访问接口, 就像网关一样, Pod之间的网关就是service了, service的实现是通过kube-proxy来做的, 会提供几种形式iptables/ipvs等
TODO
API
