Kubernetes之Ingress

　　在Service篇里面介绍了像集群外部的客户端公开服务的两种方法，还有另一种方法---创建Ingress资源。

　　定义Ingress (名词）-进入或进入的行为;进入的权利;进入的手段或地点;入口。

　　接下来解释为什么需要另一种方式从外部访问Kubernetes服务。

　　为什么需要Ingress

　　—个重要的原因是每个LoadBalancer服务都需要自己的负载均衡器，以及独有的公有IP地址，而Ingress只需要一个公网IP就能为许多服务提供访问。当客户端向Ingress发送HTTP请求时，Ingress会根据请求的主机名和路径决定请求转发到的服务，如图5.9所示。

　　Ingress在网络栈（HTTP)的应用层操作，并且可以提供一些服务不能实现的功能，诸如基于cookie的会话亲和性（sessionaffinity)等功能。

　　Ingress控制器是必不可少的

　　在介绍Ingress对象提供的功能之前，必须强调只有Ingress控制器在集群中运行，Ingress资源才能正常工作。不同的Kubernetes环境使用不同的控制器实现，但有些并不提供默认控制器。

　　例如，Google Kubernetes Engine使用 Google Cloud Platform带有的HTTP负载 平衡模块来提供Ingress功能。最初，Minikube没有提供可以立即使用的控制器，但它现在包含一个可以启用的附加组件，可以试用Ingress功能。请根据下面的补充 彳目息里的说明确保Ingress功能己启用。

 

1.安装Ingress

　　Ingress需要安装，一般官方默认的Ingress控制器，其实有很多种分类，如果有遇到，在单独的文章里面记录使用方式。有些云环境已经默认安装了，安装ingress这里就不做演示，可以登录kubernetes官网自己去查找。

 

2.创建Ingress资源

　　己经确认集群中正在运行Ingress控制器，因此现在可以创建一个Ingress资源。 下面的代码清单显示了Ingress的示例YAML:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubia
spec:
  rules:
  - host: kubia.example.com      #ingress将域名kubia.example.com映射到服务
    http:   
      paths:
      - path: /                                          #将所有的请求发送到kubia-nodeport服务的80端口
        backend:
          serviceName: kubia-nodeport
          servicePort: 80

　　定义了一个单一规则的Ingress，确保Ingress控制器收到的所有请求主机kubia.example.com的HTTP请求，将被发送到端口80上的kubia-nodeport服务。

　　注意: 云供应商的Ingress控制器（例如GKE)要求Ingress指向一个NodePort服务。但Kubernetes并没有这样的要求。

 

3.通过Ingress访问服务

　　要通过http://kubia.example.com访问服务，需要确保域名解析为Ingress控制器的IP。

　　获取Ingress的IP地址

　　要查找IP，需要列出Ingress：

$ kubectl get ingresses
NAME      HOSTS               ADDRESS          PORTS     AGE
kubia     kubia.example.com   192.168.99.100   80        29m

　　注意：在云提供商的环境上运行时，地址可能需要一段时间才能显示，因为Ingress控制器在幕后调配负载均衡器。

　　IP在ADDRESS列中显示出来。

　　确保在Ingress中配置的Host指向Ingress的IP地址

　　一旦知道IP地址，通过配置DNS服务器将kubia.example.com解析为此IP地址，或者在/ect/hosts文件中添加下面一行内容:

　　　　　　　　192.168.99.100 kubia.example.com

　　通过Ingress访问pod

　　环境都己经建立完毕，可以通过http://kubia.example.com地址访问服务（使用浏览器或者curl命令）:

$ curl http://kubia.example.com
You've hit kubia-ke823

　　了解Ingress的工作原理

　　图5.10显示了客户端如何通过Ingress控制器连接到其中一个pod。客户端首先对kubia.example.com执行DNS查找，DNS服务器（或本地操作系统）返回了Ingress控制器IP。客户端然后向Ingress控制器发送HTTP请求，并在Host头中指定kubia.example.com。控制器从该头部确定客户端尝试访问哪个服务，通过与该服务关联的Endpoint对象查看pod IP，并将客户端的请求转发给其中一个pod.

　　如你所见，Ingress控制器不会将请求转发给该服务，只用它来选择一个pod。 大多数（即使不是全部）控制器都是这样工作的。

4.通过相同的Ingress暴露多个服务

　　如果仔细查看Ingress规范，则会看到rules和paths都是数组，因此它们可以包含多个条目。一个Ingress可以将多个主机和路径映射到多个服务，我们先来看看paths字段。

　　将不同的服务映射到相同主机的不同路径

　　将不同的服务映射到相同主机的不同paths，以下面的代码清单为例。

#在同一个主机、不同的路径上，ingress暴露出多个服务
- host: kubia.example.com 
  http: 
    paths：
    - path: /kubia              #对kubia.example.com/kubia的请求将会转发至kubia服务
      backend：
        serviceName: kubia  
        servicePort: 80 
    - path: /foo                 #对kubia.example.com/bar的请求将会转发至bar服务
      backend：
        serviceName: bar 
        servicePort: 80

　　在这种情况下，根据请求的URL中的路径，请求将发送到两个不同的服务。因此，客户端可以通过一个IP地址（Ingress控制器的IP地址）访问两种不同的服务。

　　将不同的服务映射到不同的主机上

　　同样，可以使用Ingress根据HTTP请求中的主机而不是（仅）路径映射到不同的服务，如下面的代码清单所示。

  spec:
    rules：
    - host: foo.example.com         #对 foo.example.com 的请求将会转发至foo服务
      http: 
        paths：
        - path:  / 
          backend：
            serviceName: foo 
            servicePort: 80 
    - host: bar.example.com       #对bar.example.com的请求将会转发至 bar服务
      http: 
        paths：
        - path: / 
          backend：
            serviceName: bar 
            servicePort: 80

　　根据请求中的Host头（虚拟主机在网络服务器中处理的方式），控制器收到的请求将被转发到foo服务或bar服务。DNS需要将foo.example.com和bar.example.com域名都指向Ingress控制器的IP地址。

 

5.配置Ingress处理TLS传输

　　己经知道Ingress如何转发HTTP流量。但是HTTPS呢？接下来了解一下如何配置Ingress以支持TLS。

　　为Ingress创建TLS认证

　　当客户端创建到Ingress控制器的TLS连接时，控制器将终止TLS连接。客户端和控制器之间的通信是加密的，而控制器和后端pod之间的通信则不是。运行在pod上的应用程序不需要支持TLS。例如，如果pod运行web服务器，则它只能接收HTTP通信，并让Ingress控制器负责处理与TLS相关的所有内容。要使控制器能够这样做，需要将证书和私钥附加到Ingress。这两个必需资源存储在称Secret的Kubernetes资源中，然后在Ingress manifest中引用它。

　　首先，需要创建私钥和证书：

$ openssl genrsa -out tls.key 2048
$ openssl req -new -x509 -key tls.key -out tls.cert -days 360 -subj /CN=kubia.example.com

　　像下述两个文件一样创建Secret:

$ kubectl create secret tls tls-secret --cert=tls.cert --key=tls.key
secret "tls-secret" created

通过CertificateSigningRequest资源签署证书
可以不通过自己签署证书，是通过创建CertificateSigningRequest (CSR)资源来签署。用户或他们的应用程序可以创建一个常规证书请求，将其放入CSR中，然后由人工操作员或自动化程序批准请求,像这样：
$ kubectl certificate approve <name of the CSR>
然后可以从CSR的status.certificate字段中检索签名的证书。 请注意，证书签署者组件必须在集群中运行，否则创建CertificateSigningRequest 以及批准或拒绝将不起作用

　　私钥和证书现在存储在名为tls-secret的Secret中。现在，可以更新Ingress对象，以便它也接收kubia.example.com的HTTPS请求。Ingress现在看起来应该像下面的代码清单。

#代码5.16 Ingress处理TLS传输：kubia-ingress-tls.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubia
spec:
  tls:                                     #在这个属性下包含了所有的TLS的配置
  - hosts:                        
    - kubia.example.com      #将接收来自kubia.example.cocm主机的TLS连接
    secretName: tls-secret    #从tls-secret中获得之前创立的私钥和证书
  rules:
  - host: kubia.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: kubia-nodeport
          servicePort: 80

　　现在可以使用HTTPS通过Ingress访问服务:

$ curl -k -v https://kubia.example.com/kubia
* About to connect() to kubia.example.com port 443 (#0)
...
* Server certificate:
*   subject: CN=kubia.example.com
...
> GET /kubia HTTP/1.1
> ...
You've hit kubia-xueq1

　　该命令的输出显示应用程序的响应，以及配置的Ingress的证书服务器的响应。

　　注意:对Ingress功能的支持因不同的Ingress控制器实现而异，因此请检查特定实现的文档以确定支持的内容。