kubernets之Ingress资源

一 Ingress集中式的kubernets服务转发控制器

　　1.1 认识Ingress的工作原理

注意：图片来源于kubernets in action一书，如若觉得侵权，请第一时间联系博主进行删除

客户端向Ingress服务挂载的IP地址进行发起连接请求
Ingress在收到服务之后会根据请求的主机名和路径转发到相应的服务
服务收到请求之后会去查找它相关的Endpoints列表
之后随机的向Endpoints列表的任一pod进行连接

　　1.2 创建一个Ingress定义

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubia
spec:
  rules:
  - host: ex.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: kubia-nodeport
          servicePort: 80

只对spec的内容作出相关的解释和说明，其余的apiversion，kind，以及metadata很显而易见
spec有个rules的字段，里面是一个数组，可以纵向的为Ingress添加主机以及路径对应的关联服务以及端口
接着主机下面的path也是一个列表，同样支持同一台主机下面不同路径的关联服务的横向扩展

　　1.3 向Ingress以多主机的形式横向扩展服务，服务资源定义如下所示

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubia-mulit-host
spec:
  rules:
  - host: foo.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: foo
          servicePort: 80
  - host: bar.example.com
    http:
       paths: /
       - path:
         backend:
           serviceName: bar
           servicePort: 80

该定义下的Ingress，会将foo.example.com以及bar.example.com的流量分别导向集群内部相关的服务

　　1.4 向Ingress以单主机多path的形式横向扩展服务，服务资源定义如下所示

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubia-mulit-path
spec:
  - host: foo.example.com
    http:
       paths:
       - path: /bar
         backend:
             serviceName: bar
             servicePort: 80
       - path: /foo
         backend:
            serviceName: foo
            servicePort: foo

该定义下的Ingress当匹配到主机之后还会继续匹配路径，当匹配到路径bar会将流量转发到bar相关的服务，同理匹配到foo路径会将流量转发到foo相关的服务

　　1.5 以上两种情况可以同时出现在一个Ingress上面

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubia-mulit-path-host
spec:
  - host: foo.example.com
    http:
       paths:
       - path: /bar
         backend:
             serviceName: bar
             servicePort: 80
       - path: /foo
         backend:
            serviceName: foo
            servicePort: 80
  - host: bar.example.com
    http:
       paths:
       - path: /bar
         backend:
             serviceName: sub_bar
             servicePort: 80
       - path: /foo
         backend:
            serviceName: sub_foo
            servicePort: 80

这里是上面两种情况的综合表现，并且在现实的生产环境中，往往都是以这种形式出现，需要各位读者细细品觉

二配置ingress的TLS传输

　　2.1 我们已经知道了HTTP请求是如何转发的，但是对于HTTPS的请求呢？

　　　　当客户端创建到Ingress控制器的TLS连接时，控制器将终于TLS连接，客户端和控制器之间的通信是加密的，但是控制器到后端的通信

则不需要配置，也不需要支持TLS。例如运行web服务的pod不需要支持TLS，可以让Ingress控制器来处理TLS请求，这么做的前提需要将证书和私钥添加到Ingress资源里面

这种资源kubernets里面提供Secret加以存储

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: EX-ingress-TLS
spec:
  tls:
  - hosts:
    - kubia.example.com
    secretName: tls-secret
  rules:
  - host: kubia.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: kubia-nodeport
          servicePort: 80

如此该Ingress就支持了HTTPS的连接形式