kubernetes 核心数据 （存储于ETCD 有数据变化通知的功能（watch-dog))
kubernetes 设计综述 (中英文对照)(http://www.oschina.net/translate/kubernetes-design-overview?cmp)
先看设计综述 理解POD 的什么东西
/
/registry
/pods
/${PODID}->VALUE
/hosts
/${MACHINE}
/kubelet->VALUE
/controllers
/${CONTROL_ID}->VALUE
/services
/specs
/${SVR_ID}->VALUE
/endpoints
/${SVR_ID}->VALUE
/minions
/${ID}->VALUE
VALUE 对应 kubernetes/pkg/api/types.go 中定义
kubernetes 的系统中进程负责的功能
进程的入口main函数 对应 目录 kubernetes/cmd/ 中
api-server
kubernetes/pkg/registry/中 定义有 pods endpoints bindings controller service minion 这几个资源 提供POST PUT GET DELETE 作为动作 去操作 （熟悉REST API 设计应该理解的)
负责维护以上的树形结构 并提供了select 操作 (以 ETCD 作为一致性的KV存储)
kubecfg
用于控制用户输入( create -> pod service controller )
controller-manager
关注 /registry/controllers
读取 controllers controllers 有 POD 模版 以及 POD 运行数量
根据模版来创建 POD 分配POD (/registry/pods) --> 产生未分配的POD
定期检测 controllers POD 活动数量 少则增加启动 多则 停止删除 ( see scheduler )
关注 /registry/services/specs
读取 services
检测 services 标签下(看下面标签概念) 所有的POD
读取POD的ip和containers的port 生成 endpoints ( see proxy )
services 的作用就是生成代理 由 代理 转发数据到 对应标签下POD内部
scheduler
关注 /registry/pods/ （使用selector 只读取到未分配的POD）
获取未分配的POD
为POD分配机器
写入 /registry/pods/{ID}标记为分配过的。
同时/registry/hosts/{machine}/kubelet ( see kubelet )
kubelet
关注/registry/hosts/{machine}/kubelet
获取pods 并 启动Pod
proxy
关注 /registry/services／specs 变化
关注 /registry/services／endpoints 变化
获取services/specs 生成代理 代理到 specs.ID 对应的 endpoints.ID
( TCP 将每个连接负载均衡到 services ($SVR_ID} 下所有的 endpoints (pod address) )
specs 代表服务的外部PORT endpoints对应容器内部 address
4个进程都是通过apiserver来操作DB以及watch DB的变化 来达到通信的
流程
create POD
1. kubecfg 提交 create a pod
2. apiserver 将该pod 写入 /registry/pods 中 标记为 未分配
3. scheduler 由于关注了 /registry/pods 收到通知 读取未分配的 POD 然后从 kubernetes系统的节点中找到一台机器分配给POD 写入/registry/hosts/{machine}/kubelet 并写回到/registry/pods标记为分配的
4. kubelet 由于关注了/registry/hosts/{machine}/kubelet 读取到分配给自己的POD 然后 用docker 运行该POD中定义的所有容器 写回到 /registry/hosts/{machine}/kubelet 标记运行
create controller
1. kubecfg 提交 create a controller
2. apiserver 将该pod 写入 /registry/controllers
3. controller-manager 关注了 /registry/controllers 读取到新的 controllers
启动定时器定期检测 定期检测 controllers POD 活动数量 少了 会想apiserver 提交一个create pod 多了 则 stop pod
next create POD
services 的作用是分配代理 并不影响POD的启动运行
思考
proxy 的作用 考虑 如下情况
当你通过 kubercfg create a pod 这个Pod 运行在哪个服务器 你不知道 也就是说 你无法接入到你 服务
这个时候你创建一个service提交后 系统内部知道POD运行在那里 会根据service的PROT代理到你的POD中
之后你连接proxy对应的PORT后 proxy会为你转发数据到对应的POD proxy代理对POD来说是透明的（正向代理，但是你知道这事连接的PROXY);
关键概念：标签
pod用标签进行组织。每个pod具备一个key/value键值映射的标签。
通过“标签查询”，用户可以识别一系列的pod集合。这个简单的方法是services和replicationControllers如何工作的关键部分。一个service指向的pod集合由一个标签查询定义。类似的，由replicationController监听的pod的数量同样也是由标签查询定义。
标签查询通常会用于，我们讲，在一个应用程序层次上面识别和分组的pod。同样可以用来识别栈，例如dev、staging或者production。