35. SyncPods
pods
pod nodeName
pod nodeName
新版 kubelet
schedulerscheduler APIServerAPIServer
POST /binding
pod node list
RunKubelet
Pods with pod.host == nodeName
watch (三种源)
startKubeletstartKubelet
Pods
statusManagerstatusManager
Pod.status
Pod
SyncPods
Container
Manager,
Cadvisor
…
Container
Manager,
Cadvisor
…
managePod
Loop
managePod
Loop
managePod
Loop
managePod
Loop
managePod
Loop
managePod
LoopWorker
update
Pod
Pods 合法
性检查
Pod
Pod
V1.0V1.0
SyncPod : Pod vs 现有 Pod
1.创建 Pod 数据目录
2.创建 API 实体
3.mount Volume
4.更新 status
DockerManager
1.遍历 Pod 中的
Containers
2.pull 镜像
3.生成 Docker 参数
4.启动容器
37. 如何访问 Pod ?
• Service :
– Portal ,提供访问 Pod 的固定入口( portal_ip :
port )
– 多个副本 Pod 的动态 Load Balancer
– 适合强依赖于 IP 的业务
NAME SELECTOR IP PORT
…
service-nginx name=nginx 11.1.1.88 800111.1.1.88:800111.1.1.88:8001
Label:
name=nginx
Pod A-1
Label:
name=nginx
Pod A-1
Label:
name=nginx
Pod A-2
Label:
name=nginx
Pod A-2
Label:
name=nginx
Pod A-3
Label:
name=nginx
Pod A-3
Endpoint
41. 如何控制 Service ?
• Controller Manager
– Service Controller :使用真实状态更新 Service
– 检测循环:
• 遍历所有 Service
– 根据 label ,查询出 Pod 列表(真实状态)
– 该 Service 持有的 Endpoint 列表(期望状态)
– Diff
– 有差异:
删除多余的 Endpoint
或者检查实际状态列表的资源版本号
等于 0 ,真实 Pod 并没有出现在 Endpoint 列表中,
创建该 Endpoint
不等于 0 ,更新该 Endpoint
42. Pod 网络:单 Pod 单 IP 模型
pausepause
Container AContainer A Container BContainer B
--net=container:pause
/proc/{pid}/ns/net -> net:[4026532483]
• 网络容器( infra 容器)
– 使用 docker0 网桥作为默认网关,并且被分配该网桥上的一个 IP
地址作为所有容器共享的 IP 地址
43. Kubernetes 的网络假设
1. 容器之间可以跨主机通信,无需经过 NAT
2. 所有主机与容器之间可以直接通信,无需
经过 NAT
3. 容器本身看到的自己的 IP 地址与其他容器
看它的 IP 地址是一样的
但是, Kubernetes 本身对上述假设不做任何
实现
e.g. Flannel SocketPlane Calico OVS macvlan ipvlan ...
44. 典型的网络实现
• 两条基本原则
– 绝大部分 Docker 跨主网络方案均可以满足上述“网络假设”
– 可以随意更改 Daemon 的配置、启动参数,但是 Kubernetes 目前必须使
用标准 Docker API
• docker run … √
• my_tool run … ×
• API 不一致,使用 Powerstrip 进行转义 :
https://github.com/ClusterHQ/powerstrip
kubeletkubelet
PowerstripPowerstrip
docker run
my_tool run
46. Kubernetes VS 小伙伴们
• 祖师: Borg
– 专注于支撑成规模的企业服务并且最大程度地提高资
源利用率
• Kubernetes
– 典型的容器集群管理工具(类似 Swarm ),但基本单
位是 Pod
– 暂时不关注资源抢占和任务混部,以及资源利用率提
升
– K8S 大量借鉴了 Borg 的优秀思想、架构、甚至代码实
现,但并不能说就是 Borg 的开源实现
– Goal :” run your container workload at scale”
47. Kubernetes VS 小伙伴们
• Mesos
– 专注于 Scheduling 和资源抽象,需要同上层框架协作
– 良好的 framework 支持,适合作为基础依赖
– 适合大数据场景,非原生针对容器集群管理设计
– Goal: “I already have a Layer 1 (business or platform layer), but I need
Layer 0 (infrastructure layer) to run it on cluster“
• Flynn Deis Marathon + Mesos Cloud Foundry OpenShift
– 更类似 PaaS
– “ 从代码,到可运行制品,再到运行实体”
– 低用户自由度,高自动化程度
• Compose + Swarm
– 最 Docker 友好的容器集群管理工具
– 最原生的 Docker 支持 = vendor lock in
– 缺乏成规模集群管理的 vision