Php-fpm
和 nginx
其实都共用 pause
的网络栈。ReplicationController
用来确保容器应用的副本数始终保持在用户定义的副本数。即如果有容器异常退出,会自动创建新的 Pod
来替代,而如果异常多出来的容器也会自动回收。在新版本的 Kubernetes
中建议使用 ReplicaSet
来取代 ReplicationController。
ReplicaSet
跟 ReplicationController
没有本质的不同,只是名字不一样,并且 ReplicaSet
支持集合式的 selector
。
虽然 ReplicaSet
可以独立使用,但一般还是建议使用 Deployment
来自动管理 ReplicaSet
,这样就无需担心跟其他机制的不兼容问题(比如 ReplicaSet
不支持 rolling-update
,但 Deployment
支持)。
RS
不支持滚动更新;Deploy
支持。Deployment
为 Pod
和 ReplicaSet
提供了一个声明式定义(declarative)方法,用来替代以前的 ReplicationController
来方便的管理应用。典型的应用场景包括:
Deployment
来创建 Pod
和 ReplicaSet
。Deployment
。Horizontal Pod Autoscaling
仅适用于 Deployment
和 ReplicaSet
,在 V1
版本中仅支持根据 Pod
的 CPU
利用率扩所容,在 v1alpha
版本中,支持根据内存和用户自定义的 metric
扩缩容。
StatefulSet
是为了解决有状态服务的问题(对应 Deployments
和 ReplicaSets
是为无状态服务而设计)。其应用场景包括:
稳定的持久化存储
,即 Pod
重新调度后还是能访问到相同的持久化数据,基于 PVC
来实现。稳定的网络标志
,即 Pod
重新调度后其 PodName
和 HostName
不变,基于 Headless Service
(即没有 Cluster IP
的 Service
)来实现。有序部署
,有序扩展
,即 Pod
是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行(即从 0 到 N-1
,在下一个 Pod
运行之前所有之前的 Pod
必须都是 Running
和 Ready
状态),基于 init containers
来实现。Pod
中容器的启动顺序。N-1
到 0)。Pod
中容器的删除顺序。DaemonSet
确保全部(或者一些)Node
上运行一个 Pod
的副本。当有 Node
加入集群时,也会为他们新增一个 Pod
。当有 Node
从集群移除时,这些 Pod
也会被回收。删除 DaemonSet
将会删除它创建的所有 Pod
。使用 DaemonSet
的一些典型用法:
Node
上运行 glusterd
、ceph
。Node
上运行日志收集 daemon,例如 fluentd
、logstash
。Node
上运行监控 daemon,例如 Prometheus Node Exporter
。Pod
上运行一个东西,那么就可以用这个。Job
负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个 Pod
成功结束。Cron Job
管理基于时间的 Job
,即:
Service
是通过标签选择器选择到 Pod
的。Service
会有 IP Port
供 Client
访问。传统架构
K8s 架构
K8s
是一个扁平化网络,容器之间是可以互相访问的。Kubernetes 的网络模型假定所有 Pod
都在一个 可以直接连通的扁平的网络空间中
。在 GCE(Google Compute Engine)
中,这是现成的网络模型,Kubernetes假定这个网络已经存在。但是,在私有云中搭建 Kubernetes 集群时,就不能假定这个网络已经存在。我们需要自己实现这个网络假设,将不同节点上的 Docker
容器之间的互相访问先打通,然后运行 Kubernetes。
Pod
内的多个容器之间:lo
[Pause - localhost]
Pod
之间的通讯:Overlay Network
Pod
与 Service
之间的通讯:各节点的 Iptables
规则Flannel
是 CoreOS
团队针对 Kubernetes 设计的一个网络规划服务。简单来说,它的功能是让集群中的不同节点主机创建的 Docker
容器都具有全集群唯一的虚拟 IP
地址。而且它还能在这些 IP
地址之间建立一个覆盖网络(Overlay Network
),通过这个覆盖网络,将数据包原封不动地传递到目标容器内。
IP
不能一致。Pod
如何互相访问。UDP
转发的数据包更快。ETCD
之 Flannel
提供说明:
Flannel
可分配的 IP
地址段资源。ETCD
中每个 Pod
的实际地址,并在内存中建立维护 Pod
节点路由表。ETCD
一定要是最先高可用的。官方已经解决好了它的集群化,天生支持高可用,非常优秀的集群化。同一个 Pod
内部通讯:同一个 Pod
共享同一个网络命名空间,共享同一个 Linux
协议栈 [Localhost 回环网卡通信]
。
Pod1
与 Pod2
不在同一台主机,Pod
的地址是与 docker0
在同一个网段的,但 docker0
网段与宿主机网卡是两个完全不同的 IP
网段。不同 Node
之间的通信只能通过宿主机的物理网卡进行。将 Pod
的 IP
和所在 Node
的 IP
关联起来,通过这个关联让 Pod
可以互相访问。
Pod1
与 Pod2
在同一台机器,由 Docker0
网桥直接转发请求至 Pod2
,不需要经过 Flannel
。
iptables
[最新为 LVS,性能更高]
维护和转发。Pod
向外网发送请求,查找路由表,转发数据包到宿主机的网卡。宿主网卡完成路由选择后, iptables
执行 Masquerade
,把源 IP
更改为宿主网卡的 IP
,然后向外网服务器发送请求。Service
节点网络
。Service
、Pod
是虚拟网络(内部网络)。命令式编程:
声明式编程: