Kubernetes之Ingress

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

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

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

  为什么需要Ingress

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

Kubernetes之Ingress

  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
Youve 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。 大多数(即使不是全部)控制器都是这样工作的。

Kubernetes之Ingress

 

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现在看起来应该像下面的代码清单。

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
>    ...
Youve hit kubia-xueq1

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

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

Kubernetes之Ingress

上一篇:JSR 310规范


下一篇:上传项目到githug