kubernetes clusterip类型的服务，nginx反向代理tomcat，可以在nginx和tomcat之间创建一个clusterip类型的服务，只要kubernetes集群一直是稳定可靠的，那么这个clusterip类型的svc就会存在，并且会动态地将后端pod的变化更新到自己的负载均衡规则里面去。这样就达到了一种相对稳定的状态：
上层是nginx反向代理服务器，upstream 变量名区域写上server $clusterip; nginx的server区域location部分，写上proxy_pass http://变量名; 然后就是ClusterIP类型的service，把请求转发到后端真实服务器的pod，并且动态更新后端pod状态到自己的负载均衡策略的规则里面。后端真实服务器pod的副本数量，依靠副本控制器去实现副本控制，副本数量和控制器spec的期望值保持一致。
ClusterIP类型的服务自动分配一个仅在集群内部可以访问的虚拟IP（VIP）。
验证: telnet $ClusterIP_VIP $Port
NodePort 类型：在ClusterIP类型的基础上，为每台服务器绑定一个端口，这样我们就可以通过当前节点的IP
service类型是ClusterIP类型的服务，提供的是扁平化的虚拟IP，外部的用户是直接访问不到的。
NodePort是节点的端口，每个节点都有对应的网卡的网口，比如ens33。当我们创建了NodePort类型的服务service，它就会在当前的物理网卡上绑定一个端口，这个端口一般大于3万。NodePort类型的服务，默认端口范围是30000-32767。这个端口范围可以在启动对应的kube-apiserver的时候，去修改这个端口范围，默认是3万以上。好比30001，那这个30001的物理网卡的物理端口，绑定到ipvs集群，那这个物理IP和物理端口就成为了ipvs集群的虚拟IPVIP。也就是物理IP是集群的VIP，它的真实服务器就可以指向到当前的nginx反向代理的pod上。NodePort类型的服务上也需要有标签，标签选择器要匹配的标签，是nginx反向代理pod中标签的子集。标签很重要，很多的机制都是通过标签label关联起来的。
用户只需要访问物理网卡的物理端口，就可以被ipvs负载到内部的nginx反向代理的pod，nginx这个反向代理pod再通过子集的7层负载均衡，访问到我们的四层负载均衡，也就是服务类型为ClusterIP的服务。四层负载均衡再分发请求到后端对应的真实服务器，也就是后端pod上。
请求经过NodePort 四层负载均衡和Nginx 反向代理pod七层负载均衡，最后到达ClusterIP类型的四层负载均衡器，再分发给后端的真实服务器。中间多了一层负载均衡集群，每个负载均衡器都有背后的意义。最外层的一个四层负载均衡（NodePort类型服务）的作用是：把外部的流量引入集群内部。Nginx七层负载均衡的作用是反向代理服务和解析静态资源。ClusterIP类型服务的这个四层负载均衡的作用是：给nginx提供一个tomcat相对稳定的接口。有了NodePort类型的服务以后，我们可以把集群内部的服务暴露出集群以外，NodePort是在当前kubernetes集群的所有节点上的所有物理网卡存在物理端口。
验证方法：
telnet $NodeIP $NodePort（集群中任何一个Node节点IP）
没有什么问题，是中间件解决不了的。如果有，就再加一层中间件。
LoadBalancer是一种以云为载体的工作模式。负载均衡集群的功能，相当于keepalived+Nginx组合具有的IP漂移功能。负载均衡功能相当于在各个节点之前添加了一层ipvs+keepalived的负载均衡集群，keepalived去实现两台ipvs之间的心跳同步。用户直接访问负载均衡集群的VIP地址，然后负载均衡器再把流量转发到每个节点上的nodePort 类型服务打开的节点端口，这样的架构解决每个节点的单点故障问题。service是一种对象概念，把NodePort类型的工作模式再变成服务，实现更高性能的高可用。
可以在自己的IDC机房或者私有云上用nginx+keepalived构建负载均衡集群，实现NodePort类型服务的高可用，如果放入其他云厂商就有负载均衡即服务的负载均衡产品，是LAAS，也就是LoadBalancer As A Service。负载均衡是一个服务，放到云环境里是负载均衡即服务。负载均衡即服务也是云服务概念的一种体现。我们只需要向官方的LB接口发起创建负载均衡的请求，它会自动帮我们创建一个负载均衡器，与后端的真实服务器去关联。不再需要手动搭建ipvs，ipvs+keepalived放入云中的环境就是一个LB。这个LB甚至可以由kubernetes集群内部的kube-apiserver向它的接口发起创建。比如一个云服务提供商Cloud Provider CP，这个云服务供应商有自己的接口API，我们叫应用程序接口。kubernetes集群内部的kube-apiserver，可以向云服务供应商CP提供的API去发出请求，本质上是应该放在每个阶段的kube-proxy去调用。由kubernetes集群向云服务提供商CP的API发起调用，调用完成以后，云服务提供商CP就创建出来一个负载均衡集群，让我们达到一个理想的状态。如果非运营环境下，没有云服务商CP给我们提供LaaS服务，那么这种类型的工作就做不了。在传统的环境中，我们可以手动搭建ipvs去实现。只不过第三种方式，也就LoadBalancer的工作模式它能够更简化地帮我们去实现在NodePort基础上再加上一步，高可用化。
Service的第四种类型是ExternalName，是把集群外部的服务引入集群内部，而且没有被任何代理所创建。在kubernetes v1.7或者具有更高版本的kube dns才支持，当然core DNS也是没有问题的。
以容器运行数据库服务是否合适还存在争议，但是未来一定是云原生数据库。
估计的话语：君不密，则失臣；臣不密，则失身；几事不密，则成害！