Kubernetes学习之路（十五）之Ingress和Ingress Controller

目录

• 1、什么是Ingress？
  • 一、Pod 漂移问题
  • 二、端口管理问题
  • 三、域名分配及动态更新问题
• 2、如何建立Ingress资源
• 3、Ingress资源类型
  • 一、单Service资源型Ingress
• 4、Ingress Nginx部署
  • 一、部署Ingress controller
  • 二、部署后端服务
  • 三、部署ingress-nginx service
  • 四、部署ingress
• 4、增长tomcat服务
• 4、构建TLS站点

1、什么是Ingress？

从前面的学习，咱们能够了解到Kubernetes暴露服务的方式目前只有三种：LoadBlancer Service、ExternalName、NodePort Service、Ingress；而咱们须要将集群内服务提供外界访问就会产生如下几个问题：

一、Pod 漂移问题

Kubernetes 具备强大的副本控制能力，能保证在任意副本（Pod）挂掉时自动从其余机器启动一个新的，还能够动态扩容等，通俗地说，这个 Pod 可能在任什么时候刻出如今任何节点上，也可能在任什么时候刻死在任何节点上；那么天然随着 Pod 的建立和销毁，Pod IP 确定会动态变化；那么如何把这个动态的 Pod IP 暴露出去？这里借助于 Kubernetes 的 Service 机制，Service 能够以标签的形式选定一组带有指定标签的 Pod，并监控和自动负载他们的 Pod IP，那么咱们向外暴露只暴露 Service IP 就好了；这就是 NodePort 模式：即在每一个节点上开起一个端口，而后转发到内部 Pod IP 上，以下图所示：
此时的访问方式：http://nodeip:nodeport/

二、端口管理问题

采用 NodePort 方式暴露服务面临问题是，服务一旦多起来，NodePort 在每一个节点上开启的端口会及其庞大，并且难以维护；这时，咱们能够可否使用一个Nginx直接对内进行转发呢？众所周知的是，Pod与Pod之间是能够互相通讯的，而Pod是能够共享宿主机的网络名称空间的，也就是说当在共享网络名称空间时，Pod上所监听的就是Node上的端口。那么这又该如何实现呢？简单的实现就是使用 DaemonSet 在每一个 Node 上监听 80，而后写好规则，由于 Nginx 外面绑定了宿主机 80 端口（就像 NodePort），自己又在集群内，那么向后直接转发到相应 Service IP 就好了，以下图所示：

三、域名分配及动态更新问题

从上面的方法，采用 Nginx-Pod 彷佛已经解决了问题，可是其实这里面有一个很大缺陷：当每次有新服务加入又该如何修改 Nginx 配置呢？？咱们知道使用Nginx能够经过虚拟主机域名进行区分不一样的服务，而每一个服务经过upstream进行定义不一样的负载均衡池，再加上location进行负载均衡的反向代理，在平常使用中只须要修改nginx.conf便可实现，那在K8S中又该如何实现这种方式的调度呢？？？

假设后端的服务初始服务只有ecshop，后面增长了bbs和member服务，那么又该如何将这2个服务加入到Nginx-Pod进行调度呢？总不能每次手动改或者Rolling Update 前端 Nginx Pod 吧！！此时 Ingress 出现了，若是不算上面的Nginx，Ingress 包含两大组件：Ingress Controller 和 Ingress。

Ingress 简单的理解就是你原来须要改 Nginx 配置，而后配置各类域名对应哪一个 Service，如今把这个动做抽象出来，变成一个 Ingress 对象，你能够用 yaml 建立，每次不要去改 Nginx 了，直接改 yaml 而后建立/更新就好了；那么问题来了：”Nginx 该怎么处理？”

Ingress Controller 这东西就是解决 “Nginx 的处理方式” 的；Ingress Controoler 经过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，而后读取他，按照他本身模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最后 reload 一下，工做流程以下图：

实际上Ingress也是Kubernetes API的标准资源类型之一，它其实就是一组基于DNS名称（host）或URL路径把请求转发到指定的Service资源的规则。用于将集群外部的请求流量转发到集群内部完成的服务发布。咱们须要明白的是，Ingress资源自身不能进行“流量穿透”，仅仅是一组规则的集合，这些集合规则还须要其余功能的辅助，好比监听某套接字，而后根据这些规则的匹配进行路由转发，这些可以为Ingress资源监听套接字并将流量转发的组件就是Ingress Controller。

PS：Ingress 控制器不一样于Deployment 控制器的是，Ingress控制器不直接运行为kube-controller-manager的一部分，它仅仅是Kubernetes集群的一个附件，相似于CoreDNS，须要在集群上单独部署。

2、如何建立Ingress资源

Ingress资源时基于HTTP虚拟主机或URL的转发规则，须要强调的是，这是一条转发规则。它在资源配置清单中的spec字段中嵌套了rules、backend和tls等字段进行定义。以下示例中定义了一个Ingress资源，其包含了一个转发规则：将发往myapp.magedu.com的请求，代理给一个名字为myapp的Service资源。

apiVersion: extensions/v1beta1      
kind: Ingress       
metadata:           
  name: ingress-myapp   
  namespace: default     
  annotations:          
    kubernetes.io/ingress.class: "nginx"
spec:     
  rules:   
  - host: myapp.magedu.com   
    http:
      paths:       
      - path:       
        backend:    
          serviceName: myapp
          servicePort: 80

Ingress 中的spec字段是Ingress资源的核心组成部分，主要包含如下3个字段：

• rules