kubernetes 概览

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。