[置顶]kubernetes资源类型--Service

cxin

　　为了适应快速的业务需求，微服务架构已经逐渐成为主流，微服务架构的应用需要有非常好的服务编排支持。K8S中的核心要素Service便提供了一套简化的服务代理和发现机制，天然适应微服务架构。
实现原理
　　Service是一种抽象概念，定义了一个Pod逻辑集合以及访问它们的策略。目标是提供一个代理服务器，作为Pod的访问入口，它会为访问者提供一个固定访问地址，用于在访问时重定向到相应的后端pod。K8S分配给Service的一个固定IP，称为Cluster IP。
　　在K8S中，Pod IP会随着pod的变化（增加、减少、重建等）而变化的，这对于Pod的访问者来说是不可接受的，而Service会及时更新。对于访问者来说，通过Service进行访问，无需直接感知Pod。
　　默认的负载均衡策略是轮训或者随机（有kube-proxy的模式决定）。同时，Service上通过yaml文件设置sessionAffinity=ClientIP，来实现基于源IP地址的会话保持。
　　需要注意，Cluster IP是一个虚拟IP，并不是一个真实的IP，在外部是无法寻址的。
service的端口
port
　　service暴露在clusterip上的端口，<cluster ip>:port 是提供给集群内部客户访问service的入口。
nodePort
　　nodePort是K8S提供给集群外部客户访问service入口的一种方式，<nodeIP>:nodePort 是提供给集群外部客户访问service的入口。
targetPort
　　targetPort是pod上的端口，从port和nodePort上到来的数据最终经过kube-proxy流入到后端pod的targetPort上进入容器。
port、nodePort总结
　　总的来说，port和nodePort都是service的端口，前者暴露给集群内客户访问服务，后者暴露给集群外客户访问服务。从这两个端口到来的数据都需要经过反向代理kube-proxy流入后端pod的targetPod，从而到达pod上的容器内。
外部访问service的四种方法
　　但有些服务又需要被外部访问到，例如web前段。这时候就需要加一层网络转发，即外网到内网的转发。K8S提供了四种方案让外部访问service：
　　ClusterIP:提供一个集群内部的虚拟IP以供Pod访问。
　　NodePort:在每个Node上打开一个端口以供外部访问。
　　LoadBalancer:通过外部的负载均衡器来访问。
　　Ingress
　　具体请见http://blog.csdn.net/liyingke112/article/details/76022267
代理外部服务
　　Service不仅可以代理Pod，还可以代理任意其他后端，比如运行在K8S外部MySQL、Oracle等。这是通过定义两个同名的service和endPoints来实现的。
　　具体请见http://blog.csdn.net/liyingke112/article/details/76204038
服务发现
　　K8S主要支持两种服务发现机制：环境变量和DNS。
环境变量方式
　　K8S创建Pod时会自动添加所有可用的service环境变量到该Pod中。需要注意的是，环境变量的注入只发送在Pod创建时，且不会被自动更新。这个特点暗含了service和访问该service的Pod的创建时间的先后顺序，即任何想要访问service的pod都需要在service已经存在后创建，否则与service相关的环境变量就无法注入该Pod的容器中，这样先创建的容器就无法发现后创建的service。
DNS方式-SkyDNS
　　K8S官方提供的。
　　在kubernetes1.2之前，采用skydns+kube2dns+etcd的方式来部署dns。而从1.3开始，则部署方式有了一点儿变化，将skydns和kube2dns封装到了一个容器镜像中，放弃了etcd，而将dns解析直接放入到了内存之中，同时引入了dnsmasq，进一步利用其缓存。