k8s中Ingress使用

k8s暴漏服务的方式2

通常k8s中的服务对外暴漏会使用Ingress,那么为什么不使用NodePort的方式呢？

这篇文章用来探讨下面的这几个问题

• 为什么NodePort这种暴露服务的方式不适合用来给服务做域名解析
• 怎么使用Ingress暴露Web服务
• 生产集群Ingress怎么做高可用

为什么NodePort不适合做域名解析

NodePort 类型的Service 是向集群外暴露服务的最原始方式，也是最好让人理解的。NodePort，顾名思义，会在所有节点（宿主机或者是VM）上打开一个特定的端口，发送到这个端口的任何流量都会转发给Service。

NodePort Service 的原理可以用下面这个图表示

上图我们顺着流量的流向箭头从下往上看，流量通过NodeIP+NodePort的方式进入集群，上图三个节点的8080上的流量都会转发给Service，再由Service给到后端端点Pod。

NodePort Service的优点是简单，好理解，通过IP+端口的方式就能访问，但是它的缺点也很明显，比如：

• 每向外暴露一个服务都要占用所有Node的一个端口，如果多了难以管理。
• NodePort的端口区间固定，只能使用30000–32767间的端口。
• 如果Node的IP发生改变，负载均衡代理需要跟着改后端端点IP才行。

怎么使用Ingress暴露Web服务

在K8S的这些组件中Ingress 不是一种Service。相反，它位于多个Service的前端，给这些Service充当“路由代理”或集群的入口点（entrypoint）。

在Service前面加上Ingress，集群中需要有Ingress-Controller才行。如果是自建K8S集群，通常使用nginx-ingress作为控制器，它使用NGINX服务器作为反向代理来把流量路由给后面的Service。

通过Ingress可以对后端Service进行基于域名和URL路径的路由。例如，您可以将 foo.yourdomain.com 上的所有内容发送到 foo Service，将 yourdomain.com/bar/ 路径下的所有内容发送到 bar Service。

我们可以把这张图和上面NodePort原理图做一个比较，看看两者的区别。上面这个示意图对应的Ingress资源声明文件差不多应该长这个样子：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend: 
    serviceName: other
    servicePort: 8080
  rules:
  - host: foo.mydomain.com
    http:
      paths:
      - backend:
          serviceName: foo
          servicePort: 8080
  - host: mydomain.com
    http:
      paths:
      - path: /bar/
        backend:
          serviceName: bar
          servicePort: 8080

生产集群Ingress怎么做高可用

在生产集群里Ingress是怎么做高可用的呢？域名解析应该怎么绑定呢?

正常的生产环境，因为Ingress是公网的流量入口，所以压力比较大肯定需要多机部署。一般会在集群里单独出几台Node，只用来跑Ingress-Controller，可以使用deamonSet的让节点创建时就安装上Ingress-Controller，在这些Node上层再做一层负载均衡，把域名的DNS解析到负载均衡IP上。

考虑到多业务线服务相互不影响的话，还需要让不同的业务线的转发规则注入到不同的Ingress里，这个通过我们上面声明Ingress时的注解annotations:kubernetes.io/ingress.class就能实现。