service type 允许指定过一个需要的类型的service
ClusterIP 通过集群的内部ip暴漏服务，只能在集群内部访问，这也是默认的servicetype
NodePort 通过node上的ip和静态端口（nodeport）暴露服务，nodeport服务会路由到clusterip服务，这个clusterip服务会自动创建，通过请求，可以从集群外部访问一个nodeport服务。外部端口
LoadBalancer
使用云提供商的负载均衡器，可以下给外部暴露服务，外部的负载均衡器可以路由到NodePort服务和ClusterIP服务
service
Kubernetes中一个应用服务会有一个或多个实例（Pod,Pod可以通过rs进行多复本的建立）,每个实例（Pod）的IP地址由网络插件动态随机分配（Pod重启后IP地址会改变）。为屏蔽这些后端实例的动态变化和对多实例的负载均衡，引入了Service这个资源对象，如下所示:
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
labels:
app: nginx
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 80
selector: #service通过selector和pod建立关联
app: nginx
NodePort：除了使用Cluster IP之外，还通过将service的port映射到集群内每个节点的相同一个端口，实现通过nodeIP:nodePort从集群外访问服务。
· targetPort
containerPort，targetPort是pod上的端口，从port和nodePort上到来的数据最终经过kube-proxy流入到后端pod的targetPort上进入容器。
· nodePort
nodeIP:nodePort 是提供给从集群外部访问kubernetes服务的入口。
总的来说，port和nodePort都是service的端口，前者暴露给从集群内访问服务，后者暴露给从集群外访问服务。从这两个端口到来的数据都需要经过反向代理kube-proxy流入后端具体pod的targetPort，从而进入到pod上的容器内。
· ClusterIP
Pod IP 地址是实际存在于某个网卡(可以是虚拟设备)上的，但clusterIP就不一样了，没有网络设备承载这个地址。它是一个虚拟地址，由kube-proxy使用iptables规则重新定向到其本地端口，再均衡到后端Pod。当kube-proxy发现一个新的service后，它会在本地节点打开一个任意端口，创建相应的iptables规则，重定向服务的clusterIP和port到这个新建的端口，开始接受到达这个服务的连接。
· Pod IP
Pod的IP，每个Pod启动时，会自动创建一个镜像为gcr.io/google_containers/pause的容器，Pod内部其他容器的网络模式使用container模式，并指定为pause容器的ID，即：network_mode: "container:pause容器ID"，使得Pod内所有容器共享pause容器的网络，与外部的通信经由此容器代理，pause容器的IP也可以称为Pod IP。
· 节点IP
Node-IP，service对象在Cluster IP range池中分配到的IP只能在内部访问，如果服务作为一个应用程序内部的层次，还是很合适的。如果这个service作为前端服务，准备为集群外的客户提供业务，我们就需要给这个服务提供公共IP了。指定service的spec.type=NodePort，这个类型的service，系统会给它在集群的各个代理节点上分配一个节点级别的端口，能访问到代理节点的客户端都能访问这个端口，从而访问到服务。
iptables这种模式，kube-proxy 会监视 Kubernetes master 对 Service 对象和 Endpoints 对象的添加和移除。对每个 Service，它会安装 iptables 规则，从而捕获到达该 Service 的 clusterIP（虚拟 IP）和端口的请求，进而将请求重定向到 Service 的一组 backend 中的某个上面。对于每个 Endpoints 对象，它也会安装 iptables 规则，这个规则会选择一个 backend Pod。
默认的策略是，随机选择一个 backend。实现基于客户端 IP 的会话亲和性，可以将 service.spec.sessionAffinity 的值设置为 "ClientIP" （默认值为 "None"）。
和 userspace 代理类似，网络返回的结果是，任何到达 Service 的 IP:Port 的请求，都会被代理到一个合适的 backend，不需要客户端知道关于 Kubernetes、Service、或 Pod 的任何信息。这应该比 userspace 代理更快、更可靠。然而，不像 userspace 代理，如果初始选择的 Pod 没有响应，iptables 代理不能自动地重试另一个 Pod，所以它需要依赖 readliness probes
ipvs模式假定在运行kube-proxy之前在节点上都已经安装了IPVS内核模块。当kube-proxy以ipvs代理模式启动时，kube-proxy将验证节点上是否安装了IPVS模块，如果未安装，则kube-proxy将回退到iptables代理模式。
Ingress 为弥补 NodePort不足
nodeport存在的不足：
一个端口只能一个服务使用，端口需要提前规划
只支持4层负载
iptables
iptables 是 Linux 防火墙工作在用户空间的管理工具，是 netfilter/iptablesIP 信息包过滤系统的一部分，用来设置、维护和检查 Linux 内核的 IP 数据包过滤规则。它是免费的，可以代替昂贵的商业防火墙解决方案，完成封包过滤、封包重定向和网络地址转换（NAT）等功能。
还记得刚接触 Linux 系统，需要在上面部署 tomcat, 部署好之后却发现在浏览器上怎么也访问不了，折腾一会之后才知道端口没有放开，网上搜了开放端口的命令 iptables -I INPUT -p tcp --dport 8080 -j ACCEPT，试了试发现果然有效。
构建防火墙规则
防攻击，比如流量控制
多理解，必然能做到胸有成竹！
