Kubernetes之服务发现ingress & ingress controller

Service虽然解决了服务发现和负载均衡的问题，但它在使用上还是有一些限制：

• 只支持4层负载均衡，没有7层功能
• 对外访问时，NodePort类型需要在外部搭建额外的负载均衡，而LoadBalancer要求kubernetes必须跑在支持的cloud provider上

一、ingress引入历程

我们已经了解到Kubernetes暴露服务的方式目前只有三种：LoadBalancer Service、ExternalName、NodePort Service；那还有没有更好的方式呢？我们先来了解一下以下几个问题：

1、Pod漂移问题

我们知道Pod是有生命周期的，Pod宕机之后，其IP必然会改变，那我们如何把这个动态的Pod IP暴露出去呢？总所周知，我们可以借助Kubernetes的Service机制，在Service中以标签的形式选定一组带有指定标签的Pod，并监控和自动负载到它们的Pod IP，那么我们向外只需要暴露Service IP就行了，这就是我们常使用的NodePort模式：即在每个节点上开启一个端口，然后转发到内部的Pod IP上。此时的访问方式为：http: //nodeip:nodeport/

2、端口管理问题

采用NodePort方式暴露服务面临的问题是：服务一旦躲起来，NodePort在每个节点上开启的端口会极其庞大，而且难以维护。想一想，鉴于nginx的能力，我们能够使用一个nginx直接对内进行转发呢？由于Pod与Pod之间是可以互相通信的，而Pod是可以共享宿主机的网络名称空间的，此时Pod上所监听的就是Node上的端口。那这又该如何实现呢？简单的实现就是使用DaemonSet在每个Node上监听80端口，然后写好规则，因为nginx外面绑定了宿主机80端口(就像NodePort)，本身又在集群内，那么向后直接转发到相应Service IP就行了

3. 域名分配及动态更新问题

用上面的方法，我们采用nginx Pod似乎已经解决了问题，但是当每次有新服务加入又该如何修改nginx配置呢？nginx可以通过虚拟主机域名区分不同的服务，而每个服务通过upstream进行定义不同的负载均衡池，再加上location进行负载均衡的反向代理，在日常使用中只需要修改nginx.conf即可实现，但是在k8s中又该如何实现这种方式调度呢？
假设后端的服务开始只有ecshop，后面增加了bbs和member服务，那么又该如何将这2个服务加入到nginx Pod进行调度呢？总不能每次手动改后者Rolling update前端nginx pod吧！所以k8s引入了ingress，ingress就是为了解决这些问题而生的，ingress包含两大组件：ingress controller和ingress。

• ingress
  简单理解就是你原来需要修改nginx配置，然后配置各种域名对应哪个Service，现在把这个动作抽象出来，变成一个Ingress对象，你可以用yaml创建，每次不要去修改nginx了，直接改yaml然后创建/更新就行了，那么问题又来了：nginx该如何处理呢？
• ingress controller
  这个东西就是解决nginx如何处理这个问题的，ingress controller通过与kubernetes API交互，动态的去感知集群中Ingress规则变化，然后读取它，按照它自己的模板生成一段nginx配置，再写到nginx Pod中，最后reload以下，工作流程如下图
  
  图表说明：
  首先我们有一个外部的负载均衡器externalLB把请求调度到一个nodePort类型的Service(ingress-nginx)上，然后nodePort类型的Service(ingress-nginx)又把它调度到内部的叫做ingressController的Pod上，ingressCtroller根据ingress中的定义(虚拟主机还是URL)，每一组主机名或者URL都对应后端的Pod资源，并且用Service分组(图中的<service>site1/<service>site2只是用来做分组用的)

二、Ingress Nginx部署

使用Ingress功能步骤：

1. 安装部署ingressCtroller Pod

2. 部署ingress-nginx service

3. 部署后端服务

4. 部署ingress
   从前面的描述我们知道，Ingress可以使用yaml的方式进行创建，从而得知Ingress也是标准的K8S资源，其定义的方式也可以使用kubectl explain进行查看：

    [root@master manifests]# kubectl explain ingress
    KIND:     Ingress
    VERSION:  extensions/v1beta1
   
    DESCRIPTION:
    Ingress is a collection of rules that allow inbound connections to reach
    the endpoints defined by a backend. An Ingress can be configured to give
    services externally-reachable urls, load balance traffic, terminate SSL,
    offer name based virtual hosting etc.
   
    FIELDS:
    apiVersion	<string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#resources
   
    kind	<string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelC