1.pod概念
我这里分为两种:
-
自主Pod(不是被管理的pod): 容器死了就死了
-
控制器管理的Pod(被管理的pod)
只要有pod 就会启动pause容器 ,在根据数量启动其他的容器 ,
1、 其他的容器会共用pause 网络栈 容器之间的端口不能冲突
2、 其他的容器会共用pause 存储卷
控制器控制的pod:
1、Replicationcontroller&replicaset&deployment
replicationcontroller:用来确保容器应用的副本数始终保持在用户定义的副本,即如果有容器异常退出 , 会自动创建新的pod来替代;而如果异常多出来的容器也会自动回收在新版本的kubernetes中建议使用replicaset来取代replicationcontroller
replicaset:跟replicationcontroller没有本质的不同 , 只是名字不一样 , 并且replicaset支持集合式的selector
虽然replicaset可以独立使用 , 但一般还是建议使用deployment来自动管理replicaset , 这样就无需担心跟其他机制的不兼容问题 (比如replicaset不支持rolling-update 但是deployment支持)
HPA(Horizontal pod autoscaling): 仅适用于deployment和replicaset ,在v1版本中仅支持根据pod的cpu利用率扩容 , 在vlalpha版本中, 支持根据内存和用户自定义的metric扩缩容
指定监控指标如cpu>80% , 定义pod最大数量(max),定义pod最小数量(min)
2、Statefulset 是为了解决有状态服务的问题(对应deployments和replicasets是为无状态服务而设计的),其应用场景包括
statefulset实现垂直扩展
-
稳定的持久化存储, 即pod重新调度后还是能访问相同的持久化数据 , 基于pvc来实现
-
稳定的网络标志,即pod重新调度后其podname和hostname不变, 基于headless service(即没有cluster IP的service)来实现
-
有序部署 , 有序扩展 , 即pod是有顺序的 , 在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0到N-1 , 在下一个pod运行之前所有的pod必须都是running和ready状态),基于init contaiers来实现
-
有序收缩 , 有序删除(即从N-1到0)
3、daemonset 确保全部(或者一些)node上运行的pod副本 , 当有node加入集群时 , 也会为他们新增一个pod , 当有node从集群移除时 , 这些pod 也会被回收,删除daemonset 将会删除它创建的所有pod
使用deemonset的一些典型用法:
-
运行集群存储daemon,例如在每个node上运行glusterd ,ceph。
-
在每个node上运行日志搜集 daemon , 例如fluentd ,logstash
-
在每个node上运行监控daemon, 例如prometheus node exporter
4、job
job负责批处理任务 , 即仅执行一次的任务 , 它保证屁处理任务的一个或多个pod成功结束(判断脚本没有正常退出会重复执行)
5、Cron job 管理基于时间的job ,即:
- 在给定时间点只运行一次
周期性的在给定时间点运行
6.服务发现
Service 收集pod 是通过标签
服务发现是通过轮询(RR)
2.网络通讯方式
Kubernetes 的网络模型假定了所有pod都在一个可以直接连通的扁平的网络空间中, 这在GCE(google compute engine)里面是现场的网络模型 , kubernetes假定这个网络已经存在 ,而在私有云里搭建kubernetes集群 ,就不能假定这个网络已经存在了 , 我们需要自己实现这个网络假定 ,将不同节点上的docker容器之间的互相访问先打通, 然后运行kubetnetes
同一个pod内的多个容器之间:lo(同一个pod共用pause)
各pod之间的通行:overlay network
pod与service之间的通行:各节点的iptables规则
Flannel :是coreOS团队针对kubernetes设计的一个网路规划服务 , 简单来说 , 他的功能是让集群的不同节点主机创建的docker容器都具有全局唯一的虚拟IP地址 , 而且他还能再这些IP地址之间建立一个覆盖网络(overlay network),通过这个覆盖网络, 将数据包原封不动地传递到目标容器内
ETCD之Flannel提供说明:
存储管理Flannel 可分配的IP动作资源
监控ETCD中每个pod的实际地址 , 并在内存中建立维护pod节点路由表
总结:
同一个Pod内部通行:同一个pod共享一个网路命名空间 , 共享同一个linux协议栈
Pod1至Pod2
》pod1与pod2不在同一台主机, pod的地址是与doker0在同一个网段的 , 但dokcer0网段的宿主机网卡是两个完全不同的IP网段, 并且不同node之间的通信智能通过宿主机的物理网卡进行 。 将pod的IP和所有node的IP关联起来 , 通过这个关联让pod可以互相访问
》pod1与pod2在同一台机器 , 由docker0网桥直接转发请求至pod2 , 不需要经过flannel
pod至service的网络:目前基于性能考虑 , 全部为iptables维护和转发(新版可以通过lvs转发)
pod到外网:pod向外网发送请求 , 查找路由表 , 转发数据包到宿主机的网卡 , 宿主机网卡完成路由选择后 , iptables执行masquerade 把源IP更改为宿主机网卡的IP , 然后向外网服务器发送请求
外网访问pod:service (Nodeport)
本机之间完成
三层网络(是虚拟的网络 ,只有节点网络才是对的, 只要一个物理网卡就好了)