1.Service网络三种类型

① ClusterIp

默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP，适用于cluster内部网络访问Service。k8s会自动分配一个IP地址赋予Service。

② NodePort

在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过: NodePort来访问该服务。

③ LoadBalancer

在NodePort的基础上，借助Cloud Provider创建一个外部负载均衡器，并将请求转发到NodePort

2.实例测试 

ClusterIp

① v1 是 Service 的 apiVersion。

② 指明当前资源的类型为 Service。

③ Service 的名字为 httpd-svc。

④ selector 指明挑选那些 label 为 run: httpd 的 Pod 作为 Service 的后端。

⑤ 将 Service 的 8080 端口映射到 Pod 的 80 端口，使用 TCP 协议。

执行 kubectl apply 创建 Service httpd-svc。kubectl apply -f http-svc.yml

 此时名为httpd-svc的Service启动，分配到的地址 CLUSTER-IP 为10.99.229.179，访问端口为8080。

在任意节点都可以访问成功。

通过 kubectl describe 可以查看 httpd-svc 与 Pod 的对应关系。

 Endpoints 罗列了三个 Pod 的 IP 和端口。我们知道 Pod 的 IP 是在容器中配置的。实际上是通过iptables实现的。

Service Cluster IP 是一个虚拟 IP，是由 Kubernetes 节点上的 iptables 规则管理的。

可以通过 iptables-save 命令打印出当前节点的 iptables 规则，因为输出较多，这里只截取与 httpd-svc Cluster IP 10.99.229.179 相关的信息：

这两条规则的含义是：

1. 如果 Cluster 内的 Pod（源地址来自 10.244.0.0/16）要访问 httpd-svc，则允许。

2. 源地址访问 httpd-svc，跳转到规则 KUBE-SVC-RL3JAE4GN7VOGDGP。

KUBE-SVC-RL3JAE4GN7VOGDGP 规则如下：

1. 1/3 的概率跳转到规则 KUBE-SEP-C5KB52P4BBJQ35PH。

2. 1/3 的概率（剩下 2/3 的一半）跳转到规则 KUBE-SEP-HGVKQQZZCF7RV4IT。

3. 1/3 的概率跳转到规则 KUBE-SEP-XE25WGVXLHEIRVO5。

上面三个跳转的规则如下：

即将请求分别转发到后端的三个 Pod。通过上面的分析，我们得到如下结论：

iptables 将访问 Service 的流量转发到后端 Pod，而且使用类似轮询的负载均衡策略。

另外需要补充一点：Cluster 的每一个节点都配置了相同的 iptables 规则，这样就确保了整个 Cluster 都能够通过 Service 的 Cluster IP 访问 Service。

NodePort

添加 type: NodePort，重新创建 httpd-svc。

Kubernetes 依然会为 httpd-svc 分配一个 ClusterIP，不同的是：

1. EXTERNAL-IP 为 nodes，表示可通过 Cluster 每个节点自身的 IP 访问 Service。

2. PORT(S) 为 8080:32312。8080 是 ClusterIP 监听的端口，32312 则是节点上监听的端口。Kubernetes 会从 30000-32767 中分配一个可用的端口，每个节点都会监听此端口并将请求转发给 Service。

与 ClusterIP 一样，也是借助了 iptables。

NodePort 默认是的随机选择，不过我们可以用 nodePort 指定某个特定端口。

注意端口辨别，80是pod端口，8080是Service端口，30000是Node1端口！！！

LoadBalancer

LoadBalancer这里不做过多解释，本质就是在NodePort基础上多了一步硬件级负载均衡，可以查看文章开头的三涨图片。