本文摘要：作者：人月神话，新浪博客同名简介：多年SOA计划建设，私有云PaaS平台架构设计履历，恒久从事一线项目实践由于最近在进一步整理和学习云原生解决方案的相关质料，原来一直没太明白清楚的就是kurbernetes中的网络和服务袒露方式。

作者：人月神话，新浪博客同名简介：多年SOA计划建设，私有云PaaS平台架构设计履历，恒久从事一线项目实践由于最近在进一步整理和学习云原生解决方案的相关质料，原来一直没太明白清楚的就是kurbernetes中的网络和服务袒露方式。最近又查找资料进一步学习了下。业务场景说明在前面谈DevOps解决方案的时候就谈到，一个完整的DevOps连续集成和交付历程，需要和容器云集成，来实现自动化部署，动态弹性伸缩，情况迁移等能力。

一个DevOps支撑平台离不开和容器化PaaS平台的集成，即最终的编译构建完成的内容形成镜像并放到镜像堆栈，后续部署，情况迁移，资源扩展基于镜像堆栈举行快速的拷贝和复制。对于Docker容器一般会和K8S联合来实现资源的动态调理，集群治理能力。

在原来谈的时候仅仅谈到通过K8s来完成部署和资源动态扩展的时候会今后一个VIP虚拟地址提供应应用模块会见使用，而这里没有举行展开，今天主要是联合场景进一步展开说明。场景说明：我们以整个应用实际有两个微服务模块来举例，一个是UserMgr微服务，一个是OrderMgr订单治理微服务，这个两个微服务都通过k8s自动化部署到容器云情况。同时我们假设，每个微服务都动态扩展了2个副本Pod，即形成了三个Pod节点。

在这种情况下，我们不行能直接去会见Pod IP，一个是Pod IP自己就会动态变化，一个是集群扩展后自己同一个微服务已经存在多个副本Pod IP。因此我们需要通过Service来会见。Kubernetes Service 界说了这样一种抽象：一个 Pod 的逻辑分组，一种可以会见它们的计谋 —— 通常称为微服务。这一组 Pod 能够被 Service 会见到，通常是通过 Label Selector实现的。

好比上面的UserMgr微服务，我们可以给它打一个UserMgr的标签，然后相同的标签自动聚合到一个Service逻辑分组上面。内部模块间服务会见-ClusterIP适才我们谈到，整个业务场景内里有UserMgr和OrderMgr两个微服务，那么这两个微服务之间的会见属于Kurbernetes集群内部的会见。在这种集群内部会见场景下，即通过Service的ClusterIP即可。

注意ClusterIP自己是一个虚拟IP，无法Ping通，对于该IP的会见请求实际是基于IPTables路由表和KubeProxy最终路由到详细的Pod实例节点上面。即：Request-》ClusterIP-》IPTables+KubeProxy-》Pod Instance如下图：在iptables署理模式下，对每个Service，它会安装iptables规则，从而捕捉到达该Service的clusterIP（虚拟IP）和端口的请求，进而将请求重定向到Service的一组backend中某个上面。

对于每个Endpoints工具，它也会安装iptables规则，这个规则会选择一个backend Pod。默认的计谋是，随机选择一个backend。

对外提供服务-NodePort方式如果需要对外提供服务，实际上有NodePort，LoadBalancer和Ingress多种方式。下面划分来对这几种方式做下说明。NodePort方式主要通过每个节点IP加端口的形式袒露端口，会见任意一个node ip都可以会见到（前提没有指定node调理计谋），其中端口可以通过apiserver的设置文件可以看到端口袒露规模。

好比还是上面的两个微服务模块部署下去后，对于8001端口可以设置为会见UserMgr这个微服务模块。即：10.0.0.1:8001， 10.0.0.1:8002，10.0.0.1:8003。对于NodePort这种模式，实际上仍然是将请求转发到Service上面，再通过Service路由到详细的Pod实例节点上面。唯一差异在于NodeIP是可以会见到的IP地址。

这三个地址都可以会见到用户治理这个微服务。注意一个port端口映射到一个微服务上面，好比8001映射到UserMgr微服务，8002映射到8002微服务。上面三个地址都可以外部会见到，如果客户端要统一会见，统一接入到类似Ngnix反向署理就可以了。可是这种方式存在问题即如果新增加了Node节点，我们需要在集群或负载平衡上新增加设置信息，其次就是Node自己是隶属在虚拟机上面，如果整个IaaS情况的虚拟机重启后IP地址可能发生变化，那么这个时候又需要手工举行设置。

对外提供服务-LoadBalancer方式这种方式主要是使用其他第三方的LB袒露服务的，阿里云或者亚马逊的LB等等。在这种方式下注意对于每一个微服务都市消耗一个IP，因此可能带来公有云用度的问题。

其次，也不容易形成了要给统一的服务会见出口。在这种方式下，来自外部负载平衡器的流量将直接到达 backend Pod 上，不外实际它们是如何事情的，这要依赖于云提供商。在这些情况下，将凭据用户设置的 loadBalancerIP 来建立负载平衡器。对外提供服务-Ingress方式Ingress资源工具，用于将差别URL的会见请求转发到后端差别的Service,以实现HTTP层的业务路由机制。

Kubernetes使用一个Ingress计谋界说和一个详细的Ingress Controller,两者联合并实现了一个完整的Ingress负载平衡器。Ingress Controller将基于Ingress规则。

返回首页