文章目录
2.1 Pod概念
2.1.1 Pod类型
自主式Pod
控制器管理的Pod
因此
- 在同一个pod中,容器端口不能冲突
2.1.2 Pod控制器类型
1.ReplicationController & ReplicaSet
-
ReplicationController
用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退出,会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收。在新版本的Kubernetes 中建议使用ReplicaSet 来取代ReplicationControlle -
ReplicaSet
跟ReplicationController 没有本质的不同,只是名字不一样,并且ReplicaSet 支持集合式的selector -
虽然ReplicaSet 可以独立使用,但一般还是建议使用
Deployment
来自动管理ReplicaSet ,这样就无需担心跟其他机制的不兼容问题(比如ReplicaSet 不支持rolling-update 但Deployment 支持)
2.Deployment
Deployment 为Pod 和ReplicaSet 提供了一个声明式定义(declarative) 方法,用来替代以前的ReplicationController
来方便的管理应用。典型的应用场景包括:
-
定义Deployment 来创建Pod 和ReplicaSet
-
滚动升级和回滚应用
-
扩容和缩容
-
暂停和继续Deployment
Deployment运行原理图解
- 更新时先建立副本RS-1,再逐步将RS运行的容器v1移至RS-1,并且停用RS
- 可进行回滚,是因为RS并没有被删除,而是停用!
3.HPA(HorizontalPodAutoScale)
Horizontal Pod Autoscaling 仅适用于Deployment 和ReplicaSet ,在V1 版本中仅支持根据Pod 的CPU 利用率扩所容,在v1alpha 版本中,支持根据内存和用户自定义的metric
扩缩容
4.StatefullSet
Docker是无状态服务:不需要进行实时数据分析存储
StatefulSet是为了解决有状态服务的问题(对应Deployments 和ReplicaSets是为无状态服务而设计),其应用场景包括:
-
稳定的持久化存储,即Pod 重新调度后还是能访问到相同的持久化数据,基于PVC 来实现
-
稳定的网络标志,即Pod 重新调度后其PodName和HostName不变,基于Headless Service (即没有Cluster IP 的Service )来实现
-
有序部署,有序扩展,即Pod 是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0 到N-1,在下一个Pod 运行之前所有之前的Pod 必须都是Running 和Ready 状态),基于init containers 来实现
-
有序收缩,有序删除(即从N-1 到0)
5.DaemonSet
DaemonSet 确保全部(或者一些)Node 上运行一个Pod 的副本。当有Node 加入集群时,也会为他们新增一个Pod 。当有Node 从集群移除时,这些Pod 也会被回收。删除DaemonSet 将会删除它创建的所有Pod
使用DaemonSet 的一些典型用法:
-
运行集群存储daemon,例如在每个Node 上运行glusterd、ceph。
-
在每个Node 上运行日志收集daemon,例如fluentd、logstash。
-
在每个Node 上运行监控daemon,例如Prometheus Node Exporter
6.Job,Cronjob
Job 负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod
成功结束
Cron Job管理基于时间的Job,即:
- 在给定时间点只运行一次
- 周期性地在给定时间点运行
2.1.3 服务发现
可以延申的概念:
pod与pod直接的通讯方案
2.2 网络通信方式
2.2.1 网络通讯模式
Kubernetes 的网络模型假定了所有Pod 都在一个可以直接连通的扁平的网络空间中,这在GCE(Google Compute Engine)里面是现成的网络模型,Kubernetes 假定这个网络已经存在。而在私有云里搭建Kubernetes 集群,就不能假定这个网络已经存在了。我们需要自己实现这个网络假设,将不同节点上的Docker 容器之间的互相访问先打通,然后运行Kubernetes
-
同一个Pod 内的多个容器之间:lo
-
各Pod 之间的通讯:Overlay Network(全平台网络)
-
Pod 与Service 之间的通讯:各节点的Iptables 规则
2.2.2 网络解决方案Kubernetes + Flannel -1
Flannel 是CoreOS 团队针对Kubernetes 设计的一个网络规划服务,简单来说,它的功能是
让集群中的不同节点主机创建的Docker 容器都具有全集群唯一的虚拟IP地址。而且它还能在
这些IP 地址之间建立一个覆盖网络(Overlay Network),通过这个覆盖网络,将数据包原封
不动地传递到目标容器内
- 跨主机还想要通过ip进行通讯
- 二次封装、二次解封
ETCD 之 Flannel 提供说明:
> 存储管理Flannel 可分配的IP 地址段资源
> 监控ETCD 中每个 Pod 的实际地址,并在内存中建立维护 Pod 节点路由表
2.2.3 不同情况下网络通信方式
- 同一个Pod 内部通讯:同一个Pod 共享同一个网络命名空间,共享同一个Linux 协议栈
- Pod1 至Pod2
-
- Pod1 与Pod2 不在同一台主机,Pod的地址是与docker0在同一个网段的,但docker0网段与宿主机网卡是两个完全不同的IP网段,并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来,通过这个关联让Pod可以互相访问
- Pod1 与Pod2 在同一台机器,由Docker0 网桥直接转发请求至Pod2,不需要经过Flannel
-
Pod 至 Service的网络:目前基于性能考虑,全部为iptables 维护和转发
-
Pod 到外网:Pod 向外网发送请求,查找路由表, 转发数据包到宿主机的网卡,宿主网卡完成路由选择后,iptables执行Masquerade,把源IP 更改为宿主网卡的IP,然后向外网服务器发送请求
-
外网访问Pod:Service