k8s-ingress原理及ingressnginx部署测试

jiezi

5 年前

前篇文章说了 service，这篇文章来折腾下 ingress 这个玩意。

上篇文章介绍 service 时有说了暴露了 service 的三种方式 ClusterIP、NodePort 与 LoadBalance，这几种方式都是在 service 的维度提供的，service 的作用体现在两个方面，对集群内部，它不断跟踪 pod 的变化，更新 endpoint 中对应 pod 的对象，提供了 ip 不断变化的 pod 的服务发现机制，对集群外部，他类似负载均衡器，可以在集群内外部对 pod 进行访问。但是，单独用 service 暴露服务的方式，在实际生产环境中不太合适：
ClusterIP 的方式只能在集群内部访问。
NodePort 方式的话，测试环境使用还行，当有几十上百的服务在集群中运行时，NodePort 的端口管理是灾难。
LoadBalance 方式受限于云平台，且通常在云平台部署 ELB 还需要额外的费用。

所幸 k8s 还提供了一种集群维度暴露服务的方式，也就是 ingress。ingress 可以简单理解为 service 的 service，他通过独立的 ingress 对象来制定请求转发的规则，把请求路由到一个或多个 service 中。这样就把服务与请求规则解耦了，可以从业务维度统一考虑业务的暴露，而不用为每个 service 单独考虑。
举个例子，现在集群有 api、文件存储、前端 3 个 service，可以通过一个 ingress 对象来实现图中的请求转发：

ingress 规则是很灵活的，可以根据不同域名、不同 path 转发请求到不同的 service，并且支持 https/http。

要理解 ingress，需要区分两个概念，ingress 和 ingress-controller：

ingress 对象：
指的是 k8s 中的一个 api 对象，一般用 yaml 配置。作用是定义请求如何转发到 service 的规则，可以理解为配置模板。
ingress-controller：
具体实现反向代理及负载均衡的程序，对 ingress 定义的规则进行解析，根据配置的规则来实现请求转发。

简单来说，ingress-controller 才是负责具体转发的组件，通过各种方式将它暴露在集群入口，外部对集群的请求流量会先到 ingress-controller，而 ingress 对象是用来告诉 ingress-controller 该如何转发请求，比如哪些域名哪些 path 要转发到哪些服务等等。

ingress-controller 并不是 k8s 自带的组件，实际上 ingress-controller 只是一个统称，用户可以选择不同的 ingress-controller 实现，目前，由 k8s 维护的 ingress-controller 只有 google 云的 GCE 与 ingress-nginx 两个，其他还有很多第三方维护的 ingress-controller，具体可以参考官方文档。但是不管哪一种 ingress-controller，实现的机制都大同小异，只是在具体配置上有差异。一般来说，ingress-controller 的形式都是一个 pod，里面跑着 daemon 程序和反向代理程序。daemon 负责不断监控集群的变化，根据 ingress 对象生成配置并应用新配置到反向代理，比如 nginx-ingress 就是动态生成 nginx 配置，动态更新 upstream，并在需要的时候 reload 程序应用新配置。为了方便，后面的例子都以 k8s 官方维护的 nginx-ingress 为例。

ingress 是一个 API 对象，和其他对象一样，通过 yaml 文件来配置。ingress 通过 http 或 https 暴露集群内部 service，给 service 提供外部 URL、负载均衡、SSL/TLS 能力以及基于 host 的方向代理。ingress 要依靠 ingress-controller 来具体实现以上功能。前一小节的图如果用 ingress 来表示，大概就是如下配置：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: abc-ingress
  annotations: 
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  tls:
  - hosts:
    - api.abc.com
    secretName: abc-tls
  rules:
  - host: api.abc.com
    http:
      paths:
      - backend:
          serviceName: apiserver
          servicePort: 80
  - host: www.abc.com
    http:
      paths:
      - path: /image/*
        backend:
          serviceName: fileserver
          servicePort: 80
  - host: www.abc.com
    http:
      paths:
      - backend:
          serviceName: feserver
          servicePort: 8080

与其他 k8s 对象一样，ingress 配置也包含了 apiVersion、kind、metadata、spec 等关键字段。有几个关注的在 spec 字段中，tls 用于定义 https 密钥、证书。rule 用于指定请求路由规则。这里值得关注的是 metadata.annotations 字段。在 ingress 配置中，annotations 很重要。前面有说 ingress-controller 有很多不同的实现，而不同的 ingress-controller 就可以根据 ”kubernetes.io/ingress.class:” 来判断要使用哪些 ingress 配置，同时，不同的 ingress-controller 也有对应的 annotations 配置，用于自定义一些参数。列如上面配置的 ’nginx.ingress.kubernetes.io/use-regex: “true”‘, 最终是在生成 nginx 配置中，会采用 location ~ 来表示正则匹配。

ingress 的部署，需要考虑两个方面：

ingress-controller 是作为 pod 来运行的，以什么方式部署比较好
ingress 解决了把如何请求路由到集群内部，那它自己怎么暴露给外部比较好

下面列举一些目前常见的部署和暴露方式，具体使用哪种方式还是得根据实际需求来考虑决定。

如果要把 ingress 部署在公有云，那用这种方式比较合适。用 Deployment 部署 ingress-controller，创建一个 type 为 LoadBalancer 的 service 关联这组 pod。大部分公有云，都会为 LoadBalancer 的 service 自动创建一个负载均衡器，通常还绑定了公网地址。只要把域名解析指向该地址，就实现了集群服务的对外暴露。

同样用 deployment 模式部署 ingress-controller，并创建对应的服务，但是 type 为 NodePort。这样，ingress 就会暴露在集群节点 ip 的特定端口上。由于 nodeport 暴露的端口是随机端口，一般会在前面再搭建一套负载均衡器来转发请求。该方式一般用于宿主机是相对固定的环境 ip 地址不变的场景。
NodePort 方式暴露 ingress 虽然简单方便，但是 NodePort 多了一层 NAT，在请求量级很大时可能对性能会有一定影响。

用 DaemonSet 结合 nodeselector 来部署 ingress-controller 到特定的 node 上，然后使用 HostNetwork 直接把该 pod 与宿主机 node 的网络打通，直接使用宿主机的 80/433 端口就能访问服务。这时，ingress-controller 所在的 node 机器就很类似传统架构的边缘节点，比如机房入口的 nginx 服务器。该方式整个请求链路最简单，性能相对 NodePort 模式更好。缺点是由于直接利用宿主机节点的网络和端口，一个 node 只能部署一个 ingress-controller pod。比较适合大并发的生产环境使用。

我们来实际部署和简单测试一下 ingress。测试集群中已经部署有 2 个服务 gowebhost 与 gowebip，每次请求能返回容器 hostname 与 ip。测试搭建一个 ingress 来实现通过域名的不同 path 来访问这两个服务：

测试 ingress 使用 k8s 社区的 ingress-nginx，部署方式用 DaemonSet+HostNetwork。

官方文档中，部署只要简单的执行一个 yaml

https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml

mandatory.yaml 这一个 yaml 中包含了很多资源的创建，包括 namespace、ConfigMap、role，ServiceAccount 等等所有部署 ingress-controller 需要的资源，配置太多就不粘出来了，我们重点看下 deployment 部分：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.0
          args:
            - /nginx-ingress-controller
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 33
            runAsUser: 33
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
            - name: https
              containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10

可以看到主要使用了“quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.0”这个镜像，指定了一些启动参数。同时开放了 80 与 443 两个端口，并在 10254 端口做了健康检查。
我们需要使用 daemonset 部署到特定 node，需要修改部分配置：先给要部署 nginx-ingress 的 node 打上特定标签, 这里测试部署在 ”node-1″ 这个节点。

$ kubectl  label   node  node-1 isIngress="true"

然后修改上面 mandatory.yaml 的 deployment 部分配置为：

# 修改 api 版本及 kind
# apiVersion: apps/v1
# kind: Deployment
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
# 删除 Replicas
# replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      serviceAccountName: nginx-ingress-serviceaccount
      # 选择对应标签的 node
      nodeSelector:
        isIngress: "true"
      # 使用 hostNetwork 暴露服务
      hostNetwork: true
      containers:
        - name: nginx-ingress-controller
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.0
          args:
            - /nginx-ingress-controller
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 33
            runAsUser: 33
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
            - name: https
              containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10

修改完后执行 apply, 并检查服务

$ kubectl apply -f mandatory.yaml

namespace/ingress-nginx created
configmap/nginx-configuration created
configmap/tcp-services created
configmap/udp-services created
serviceaccount/nginx-ingress-serviceaccount created
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
role.rbac.authorization.k8s.io/nginx-ingress-role created
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created
daemonset.extensions/nginx-ingress-controller created
# 检查部署情况
$ kubectl get daemonset -n ingress-nginx
NAME                       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR    AGE
nginx-ingress-controller   1         1         1       1            1           isIngress=true   101s
$ kubectl get po -n ingress-nginx -o wide
NAME                             READY   STATUS    RESTARTS   AGE    IP               NODE     NOMINATED NODE   READINESS GATES
nginx-ingress-controller-fxx68   1/1     Running   0          117s   172.16.201.108   node-1   <none>           <none>

可以看到，nginx-controller 的 pod 已经部署在在 node- 1 上了。

到 node- 1 上看下本地端口：

[root@node-1 ~]#  netstat -lntup | grep nginx
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2654/nginx: master  
tcp        0      0 0.0.0.0:8181            0.0.0.0:*               LISTEN      2654/nginx: master  
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      2654/nginx: master  
tcp6       0      0 :::10254                :::*                    LISTEN      2632/nginx-ingress- 
tcp6       0      0 :::80                   :::*                    LISTEN      2654/nginx: master  
tcp6       0      0 :::8181                 :::*                    LISTEN      2654/nginx: master  
tcp6       0      0 :::443                  :::*                    LISTEN      2654/nginx: master

由于配置了 hostnetwork，nginx 已经在 node 主机本地监听 80/443/8181 端口。其中 8181 是 nginx-controller 默认配置的一个 default backend。这样，只要访问 node 主机有公网 IP，就可以直接映射域名来对外网暴露服务了。如果要 nginx 高可用的话，可以在多个 node
上部署，并在前面再搭建一套 LVS+keepalive 做负载均衡。用 hostnetwork 的另一个好处是，如果 lvs 用 DR 模式的话，是不支持端口映射的，这时候如果用 nodeport，暴露非标准的端口，管理起来会很麻烦。

部署完 ingress-controller，接下来就按照测试的需求来创建 ingress 资源。

# ingresstest.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-test
  annotations:
    kubernetes.io/ingress.class: "nginx"
    # 开启 use-regex，启用 path 的正则匹配 
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  rules:
    # 定义域名
    - host: test.ingress.com
      http:
        paths:
        # 不同 path 转发到不同端口
          - path: /ip
            backend:
              serviceName: gowebip-svc
              servicePort: 80
          - path: /host
            backend:
              serviceName: gowebhost-svc
              servicePort: 80

部署资源

$ kubectl apply -f ingresstest.yaml

部署好以后，做一条本地 host 来模拟解析 test.ingress.com 到 node 的 ip 地址。测试访问

可以看到，请求不同的 path 已经按照需求请求到不同服务了。
由于没有配置默认后端，所以访问其他 path 会提示 404：

关于 ingress-nginx 多说几句，上面测试的例子是非常简单的，实际 ingress-nginx 的有非常多的配置，都可以单独开几篇文章来讨论了。但本文主要想说明 ingress，所以不过多涉及。具体可以参考 ingress-nginx 的官方文档。同时，在生产环境使用 ingress-nginx 还有很多要考虑的地方，这篇文章写得很好，总结了不少最佳实践，值得参考。

ingress 是 k8s 集群的请求入口，可以理解为对多个 service 的再次抽象
通常说的 ingress 一般包括 ingress 资源对象及 ingress-controller 两部分组成
ingress-controller 有多种实现，社区原生的是 ingress-nginx，根据具体需求选择
ingress 自身的暴露有多种方式，需要根据基础环境及业务类型选择合适的方式

Kubernetes Document
NGINX Ingress Controller Document
Kubernetes Ingress Controller 的使用介绍及高可用落地
通俗理解 Kubernetes 中 Service、Ingress 与 Ingress Controller 的作用与关系

k8s-ingress原理及ingressnginx部署测试

ingress 是啥东东

ingress 与 ingress-controller

ingress-controller

ingress

ingress 的部署

Deployment+LoadBalancer 模式的 Service

Deployment+NodePort 模式的 Service

DaemonSet+HostNetwork+nodeSelector

ingress 测试

部署 ingress-controller

部署 ingress-controller pod 及相关资源

暴露 nginx-controller

配置 ingress 资源

测试访问

关于 ingress-nginx

最后

参考