通俗理解 Kubernetes 中的服务，搞懂后真“有趣”
2021-11-11 15:25:50
1. 复习 pod 相关核心结构
1.1 pod 结构
- pod 相当于一个容器，pod 有独立的 ip 地址，也有自己的 hostname，利用 namespace 进行资源隔离，相当于一个独立沙箱环境。
- pod 内部封装的是容器，可以封装一个，或者多个容器（通常是一组相关的容器）
1.2 pod 网络
2. pod 如何对外提供访问
首先 pod 有自己的 IP 和 hostname，但 pod 是虚拟的资源对象 (在计算机中表现为进程)，没有对应实体 (物理机，物理网卡) 与之对应，所以是无法直接对外提供服务访问的。因此如果 pod 想对外提供服务，必须绑定物理机端口 (即在物理机上开启端口，让这个端口和 pod 的端口进行映射)，这样就可以通过物理机进行数据包的转发。下面以一台 Linux 系统的机器为例子（ logstash 是做日志收集用的）
3. pod 的负载均衡
很关键的一个问题：一组相关的 pod 副本，如何实现访问负载均衡？就如当请求达到，请求转发给哪个 pod 比较好？举例：如下图，注意下图右边的 Node 里面有两个是 支付 服务，与订单服务的是不同类型的 pod。如果一个请求订单的服务发来上面那个 Nginx，那这个 pod 可以有 4 条转发路线，可以想到用 hash 呀什么的把不同请求映射到不同的 pod 去转发。但能不能这么做呢？
思考：pod 是一个进程，是有生命周期的，一旦宕机、版本更新都会创建新的 pod（ IP 地址会变化，hostname 会变化），此时再使用 Nginx 做负载均衡不太合适，因为它不知道 pod 发生了改变，那请求就不能被接受了。所以服务发生了变化它根本不知道，Nginx 无法发现服务，不能用 Nginx 做负载均衡。那该如何实现呢？使用 Service 资源对象。3.1 什么是 Service 资源对象
- cluster IP：虚拟 IP，是由 kubernetes 抽象出的 service 对象，这个 service 对象就是一个 VIP (virtual IP, VIP) 的资源对象
3.2 service 如何实现负载均衡
例如现在要负载均衡地访问一组相同的服务副本——订单，这时就要去做一个 service，对外表现出是一个进程或资源对象，有虚拟的 IP (VIP) 和端口。请求会访问 service，然后 service 自己会 负载均衡 地发送给相应服务的 POD，也就是下图中 4 个相同的 pod。
3.3 深入 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 里的映射关系。来源：https://blog.csdn.net/qq_43280818/article/details/107164860
