笔记摘自视频章节：第四章-p30
主题
service 基本概念
笔记
service功能
服务发现：管理的pod的ip地址，对外nginx暴露的是svc的地址。pod地址变化不会影响外部冯文 负载均衡：默认只提供4层负载均衡能力。如果要7层，需要增加Ingress组件
Kubernetes Service定义了这样一种抽象:一个Pod的逻辑分组，一种可以访问它们的策略--通常称为微服务。这一组Pod能够被Service 访问到，通常是通过Label Selector
Service类型
- ClusterIP: 默认类型，提供一个集群内部可以访问的虚拟IP。集群内的其他Pod通过这个IP访问到svc，svc再通过rr策略来进行负载均衡，把请求发送到计算pod中。 svc和计算pod间一般通过label来进行匹配，而计算pod通过deployment进行期望控制。
- NodePort: 在ClusterIP基础上，为service在每个Node上绑定一个端口，并对外映射暴露一个端口（每个Node的暴露端口相同）。达到外部可以通过NodeIP:NodePort的方式访问service，然后service再通过rr策略分发请求。典型应用场景是使用nginx做负载均衡，如下，service在node内使用80，对外暴露30001端口：
- LoadBalancer：在NodePort的基础上,借助cloud provider（云供应商）创建一个外部负载均衡器,开将请求转发NodeIP:Port。实际上就是把Node的service信息注册到云供应商，一般需要收费
- ExternalName：跟前三种不同，这种类型是把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建,这只有kubernetes 1.7或更高版本的kube-dns才支持
svc实现流程
- 信息更新
- apiserver向kube-proxy监听Service和Endpoints
- kube-proxy: 通过label查看匹配到的pod信息，把规则写入到iptables中，以及更更新信息到svc对应的endpoint中。（endpoint也是一种资源类型）
- client访问流程
- client访问，通过iptables转发流量
- kube-proxy转发到对应pod
