pod 结构
pod 相当于一个容器，pod 有独立的 ip 地址，也有自己的 hostname，利用 namespace 进行资源隔离，相当于一个独立沙箱环境。
pod 内部封装的是容器，可以封装一个，或者多个容器（通常是一组相关的容器）
pod 网络
pod 有自己独立的 IP 地址
pod 内部的容器之间是通过 localhost 进行访问
pod 如何对外提供访问
首先 pod 有自己的 IP 和 hostname，但 pod 是虚拟的资源对象 (在计算机中表现为进程)，没有对应实体 (物理机，物理网卡) 与之对应，所以是无法直接对外提供服务访问的。
因此如果 pod 想对外提供服务，必须绑定物理机端口 (即在物理机上开启端口，让这个端口和 pod 的端口进行映射)，这样就可以通过物理机进行数据包的转发。
下面以一台 Linux 系统的机器为例子
pod 的负载均衡
很关键的一个问题：一组相关的 pod 副本，如何实现访问负载均衡？就如当请求达到，请求转发给哪个 pod 比较好？
一个想法就是用 pod 再部署一个 Nginx。
举例：如下图，注意下图右边的 Node 里面有两个是 支付 服务，与订单服务的是不同类型的 pod。如果一个请求订单的服务发来上面那个 Nginx，那这个 pod 可以有 4 条转发路线，可以想到用 hash 呀什么的把不同请求映射到不同的 pod 去转发。但能不能这么做呢？
思考：pod 是一个进程，是有生命周期的，一旦宕机、版本更新都会创建新的 pod（ IP 地址会变化，hostname 会变化），此时再使用 Nginx 做负载均衡不太合适，因为它不知道 pod 发生了改变，那请求就不能被接受了。所以服务发生了变化它根本不知道，Nginx 无法发现服务，不能用 Nginx 做负载均衡。那该如何实现呢？使用 Service 资源对象。
什么是 Service 资源对象
- POD IP：pod 的 IP 地址
- NODE IP：物理机的 IP 地址
- cluster IP：虚拟 IP，是由 kubernetes 抽象出的 service 对象，这个 service 对象就是一个 VIP (virtual IP, VIP) 的资源对象
service 如何实现负载均衡
例如现在要负载均衡地访问一组相同的服务副本——订单，这时就要去做一个 service，对外表现出是一个进程或资源对象，有虚拟的 IP (VIP) 和端口。请求会访问 service，然后 service 自己会 负载均衡 地发送给相应服务的 POD，也就是下图中 4 个相同的 pod。
深入 service VIP
- service 和 pod 都是一个进程，都是虚拟的，因此实际上 service 也不能对外网提供服务
- service 和 pod 之间可以直接进行通信，它们的通信属于局域网通信
- 负载策略：把请求交给 service 后，service 使用 iptables，ipvs 来实现数据包的分发
而要对外网提供服务，首先需要和之前一样 在物理机上也绑定一个端口 来接受访问请求，然后把请求转发给 service，service 再把数据包分发给相应的 POD。访问流程如下图所示：
思考 1：那 service 对象是如何和 pod 进行关联的呢？它们之间的关联利用的 还是标签选择器 selector。且 service 只能对 一组相同的副本 提供服务，不能跨组提供服务。如果有另一组，需要再创建一个 service。因此不同的业务会有不同的 service。
举例：service 和 一组 pod 副本是通过标签选择器进行关联的，相同的副本的标签是一样的。
selector：app = x 选择一组订单的服务的 pod，创建一个 service；app = y 选择了一组支付的服务的 pod。通过一个 endpoints 属性存储这组 pod 的 IP 地址，这样就有了映射关系了 (关联起来)。
思考 2：pod 宕机或发布新版本了，service 是如何发现 pod 已经发生变化的？通过 k8s 中的一个组件 —— kube-proxy (第 1 篇有提到过)，每个 NODE 里都运行着这个服务。它需要做的工作如下图右侧：
service 实现服务的发现：kube-proxy 监控 pod，一旦发现 pod 服务变化，将会把新的 ip 地址更新到 service。
注意：endpoints 那些都是存储在 etcd 里的 (也是第 1 篇提到过的)，所以 kube-proxy 更新的存储在 etcd 里的映射关系。
