8.1 Service存在的意义
-
防止Pod失联（服务发现）
-
定义一组Pod的访问策略（负载均衡）
8.2 为什么要使用Service
Kubernetes Pod`是平凡的，由`Deployment`等控制器管理的`Pod`对象都是有生命周期的，它们会被创建，也会意外挂掉。虽然它们可以由控制器自动重建或者滚动更新，但是重建或更新之后的`Pod`对象的IP地址等都会发生新的变化。这样就会导致一个问题，如果一组`Pod`（称为`backend`）为其它`Pod`（称为 `frontend`）提供服务，那么那些`frontend`该如何发现，并连接到这组`Pod`中的哪些`backend`呢？ 这时候就用到了：`Service
示例说明为什么要使用Service
资源来解决此类问题。
8.3 Service实现原理
直接处理并响应一样。
协议栈的传输层。
对象会自动创建。
8.4 虚拟IP和服务代理
规则上。
之上的调度规则。
的原因之一。
。因userspace传输效率太低，不推荐使用，在1.1版本之前是默认转发策略，现在默认是iptables。
8.5 iptables代理模式
）。
对象之上。
Iptables：
-
灵活，功能强大
-
规则遍历匹配和更新，呈线性时延
8.6 ipvs代理模式
等。
IPVS：
-
工作在内核态，有更好的性能
-
调度算法丰富：rr，wrr，lc，wlc，ip hash...
8.7 Pod与Service的关系
-
通过label-selector相关联
-
通过Service实现Pod的负载均衡（ TCP/UDP 4层）
8.8 Service三种类型
类型。
pod ---> ClusterIP:ServicePort --> (iptables、ipvs)DNAT --> PodIP:containePort
：在每个节点上启用一个端口来暴露服务，可以在集群外部访问。也会分配一个稳定内部集群IP地址。
clietn --> <NodeIp>:<NodePort> --> (iptables、ipvs)DNAT --> <PodIP>:<ContainerPort>。
：与NodePort类似，在每个节点上启用一个端口来暴露服务。除此之外，Kubernetes会请求底层云平台上的负载均衡器，将每个Node（[NodeIP]:[NodePort]）作为后端添加进去。
8.9 将service代理模式改为IPVS
[root@k8s-admin ~]# kubectl get pod -n kube-system -o wide
[root@k8s-admin ~]# kubectl get pod -n kube-system -o wide
# grep ipvs /var/log/messages
[root@k8s-admin ~]# kubectl get deploy,pod,svc,ep -o wide
......
8.10 Service DNS名称
DNS服务监视Kubernetes API，为每一个Service创建DNS记录用于域名解析。
.svc.cluster.local
示例：my-svc.my-namespace.svc.cluster.local
apiVersion: v1
kind: Pod
metadata:
labels:
run: busybox
name: busybox
namespace: default
spec:
containers:
- image: busybox:1.28.4
name: bs
command:
- "ping"
- "baidu.com"