结构如下:
Pod 相当于一个容器,Pod 有独立 IP 地址,也有自己的 Hostname,利用 Namespace 进行资源隔离,独立沙箱环境。
Pod 内部封装的是容器,可以封装一个,或者多个容器(通常是一组相关的容器)。
具体如下:
Pod 有自己独立的 IP 地址。
Pod 内部容器之间访问采用 Localhost 访问。
Pod 内部容器访问是 Localhost,Pod 之间的通信属于远程访问。
Pod 是虚拟的资源对象(进程),没有对应实体(物理机,物理网卡)与之对应,无法直接对外提供服务访问。
那么该如何解决这个问题呢?Pod 如果想要对外提供服务,必须绑定物理机端口。
也就是说在物理机上开启端口,让这个端口和 Pod 的端口进行映射,这样就可以通过物理机进行数据包的转发。
概括来说:先通过物理机 IP+Port 进行访问,再进行数据包转发。
我们先明确一个概念,Pod 是一个进程,是有生命周期的。宕机、版本更新,都会创建新的 Pod。
这时候 IP 地址会发生变化,Hostname 会发生变化,使用 Nginx 做负载均衡就不太合适了。
所以我们需要依赖 Service 的能力。
简单来说,Service 资源对象包括如下三部分:
Pod IP:Pod 的 IP 地址。
Node IP:物理机 IP 地址。
Cluster IP:虚拟 IP ,是由 K8s 抽象出的 Service 对象,这个 Service 对象就是一个 VIP 的资源对象。
具体如下:
Service 和 Pod 都是一个进程,Service 也不能对外网提供服务。
Service 和 Pod 之间可以直接进行通信,它们的通信属于局域网通信。
把请求交给 Service 后,Service 使用 iptable,ipvs 做数据包的分发。
具体如下:
不同的业务有不同的 Service。
Service 和 Pod 通过标签选择器进行关联。
selector: app=x 选择一组订单的服务 pod ,创建一个 service; 通过 endpoints 存放一组 pod ip;
Service 通过标签选择器选择一组相关的副本,然后创建一个 Service。
每个 Pod 中都有 Kube-Proxy,监听所有 Pod。如果发现 Pod 有变化,就动态更新(etcd 中存储)对应的 IP 映射关系。