Kubernetes Ingress管理

2022-12-30 15:19:04

概述
Ingress架构及原理
Nginx Ingress配置

概述

Kubernetes暴露服务的方式目前有三种：

LoadBlancer Service
NodePort Service
Ingress

在《kubernetes资源之service》中我们提到，通过NodePort Service和LoadBlancer Service可以将集群内服务对外暴露。但事实上，各自又存在各自的问题：

LoadBalancer Service 通常用于与公有云厂商对接，当然也可以自行实现其接口以完成与企业自建的负载均衡器对接。事实上LoadBanlacer Service的工作机制就是调用外部的负载均衡器以实现服务暴露，这依托于外部的负载均衡器。
NodePort Service 它的实现机制其实就是在每个node节点上都开启一个端口，并通过iptables的dnat方式将这个宿主机端口映射至集群内部的service ip上。nodeport的问题是，当集群当中的服务越来越多的时候，在每个node上开启的端口也越来越多，最终我们要维护大量的端口映射关系，这使得业务管理工作变得非常复杂。

为此，从kubernetes 1.2版本开始，官方引入了ingress。

Ingress架构及原理

针对上述nodeport暴露服务的问题，其实可以有一个解决办法，即使用一个nginx/haproxy这样的负载均衡器，只监听在一个端口上，比如80或443，然后按照域名往后端转发。将这样的负载均衡器以pod的方式运行在集群中，并通过hostNetwork或者nodeport的方式只暴露负载均衡器监听的端口即可。

这里其实有一个问题，就是nginx/haproxy怎么知道什么域名应该转发至什么后端？后端应用的pod如果发生变化，nginx/haproxy又应该如何感知到，并同步更新自己的配置文件然后重载配置？

而这就是ingress的作用。官方的ingress由三部分组成：

Ingress类型的资源：其实就是个规则文件，其定义流量的转发规则
Ingress Controller：通过与kubernetes api交互，动态的去感知集群中ingress规则变化，然后读取它，再按照自己的模板生成一段nginx配置，再写到nginx pod里，最后reload一下nginx
Nginx：真正负责流量转发的负载均衡器

事实上，kubernetes已经将ingress Controller和nginx结合到一起，统称之ingress controller，所以在实际部署中，只需要部署ingress controller即可。

Nginx Ingress配置

ingress-nginx代码托管地址：https://github.com/kubernetes/ingress-nginx

ingress-nginx官方文档地址：https://kubernetes.github.io/ingress-nginx/

1. Ingress Controller部署

官方的Ingress Controller部署文件： https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.26.2/deploy/static/mandatory.yaml

下面是我修改过的部署文件：

...

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:

      # wait up to five minutes for the drain of connections

      terminationGracePeriodSeconds: 300

      serviceAccountName: nginx-ingress-serviceaccount

      hostNetwork: true

      nodeSelector:

        kubernetes.io/os: linux

        ingress-nginx: enable

      tolerations:

        - key: ingress-nginx

          operator: "Exists"

          effect: NoExecute

      containers:

        - name: nginx-ingress-controller

          image: quay.azk8s.cn/kubernetes-ingress-controller/nginx-ingress-controller:0.26.2

          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 -> 101

            runAsUser: 101

          env:

            - name: POD_NAME

              valueFrom:

                fieldRef:

                  fieldPath: metadata.name

            - name: POD_NAMESPACE

              valueFrom:

                fieldRef:

                  fieldPath: metadata.namespace

          ports:

            - name: http

              containerPort: 80

              protocol: TCP

            - name: https

              containerPort: 443

              protocol: TCP

          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

          lifecycle:

            preStop:

              exec:

                command:

                  - /wait-shutdown

...

修改说明：

将nginx监听的端口直接通过host模式监听至宿主机
将ingress controller运行在带有ingress-nginx=enable标签的节点上（所以需要给集群中要运行该ingress controller的节点打上对应的标签）
ingress controller能够容器带有ingress-nginx污点的节点（如果要让ingress controller专机专用，可为相应节点打上ingress-nginx=:NoExecute的污点）

部署：

kubectl create -f mandatory.yaml

为ingress controller创建一个service:

# cat ingress-nginx.svc.yaml

apiVersion: v1

kind: Service

metadata:

  name: ingress-nginx

  namespace: ingress-nginx

spec:

  type: ClusterIP

  ports:

  - port: 80

    name: http

    targetPort: 80

  - port: 443

    name: https

    targetPort: 443

  selector:

    app.kubernetes.io/name: ingress-nginx

    app.kubernetes.io/part-of: ingress-nginx

创建service：

kubectl apply -f ingress-nginx.svc.yaml

创建service之后，集群内部可直接通过这个service的ip访问到相应的应用（需要加header头）

还需要说明的是，ingress-nginx部署完成以后，默认提供两个location，一个是/healthz，用于健康检查，返回状态码200，另外一个是/，默认返回404

2. 配置Ingress资源以实现流量接入

前面我们说到Ingress其实就是个规则，指定哪个域名转发到哪个service，所以说首先得有个service。不过service的具体配置这里不作说明。我们就以kubernetes-dashboard和kibana为例：

kubectl get svc kubernetes-dashboard --namespace=kube-system

NAME                   CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE

kubernetes-dashboard   10.254.213.109   <none>        80/TCP    13d

kibana                 10.254.213.110   <none>        5601/TCP    13d

创建一个dashboard-kibana-ingress.yml如下：

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: dashboard-kibana-ingress

  namespace: kube-system

spec:

  rules:

  - host: dashboard.dz11.com

    http:

      paths:

      - path: /

        backend:

          serviceName: kubernetes-dashboard

          servicePort: 80

  - host: kibana.dz11.com

    http:

      paths:

      - backend:

          serviceName: kibana

          servicePort: 5601

部署：

kubectl create -f dashboard-kibana-ingress.yml

3. 配置Ingress TLS

默认情况下，ingress只提供了http服务，而没有https服务，要部署一个https服务，首先得有https证书。证书的生成，这里不做说明。

创建secret

假定，我们现在已经有了一个ca.crt的证书文件和一个server.key的密钥文件。我们需要创建一个secret。在创建secret之前，先要把证书及密钥内容通过base64编码。如下：

cat ca.crt | base64 -w 0

cat server.key|base64 -w 0

创建ingress-secret.yml文件，内容如下：

apiVersion: v1

kind: Secret

metadata:

  name: ingress-secret

  namespace: default

type: kubernetes.io/tls

data:

  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpNSUlIWlRDQ0JrMmdBd0lCQWdJTUxQbnRoUStHZlJJOTNHd0dNQTBHQ1NxR1NJYjNEUUVCQ3dVQU1HQXhDekFKDQpCZ05WQkFZVEFrSkZNUmt3RndZRFZRUUtFeEJIYkc5aVlXeFRhV2R1SUc1MkxYTmhNVFl3TkFZRFZRUURFeTFIDQpiRzlpWVd4VGFXZHVJRVJ2YldGcGJpQldZV3hwWkdGMGFXOXVJRU5CSUMwZ1UwaEJNalUySUMwZ1J6SXdIaGNODQpNVGN3TlRJMU1EWTBNRFEyV2hjTk1UZ3hNVEk0TWpNMU9UVTVXakE0TVNFd0h3WURWUVFMRXhoRWIyMWhhVzRnDQpRMjl1ZEhKdmJDQldZV3hwWkdGMFpXUXhFekFSQmdOVkJBTU1DaW91WkhveE1TNWpiMjB3Z2dFaU1BMEdDU3FHDQpTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDaTA5bjg0WGdhWGo0YStvaERyQXJONWVLeEpYbXV0QmJNDQpqNVFJdEZDa2l0dUg3OWxtNmtMcThSL2E0ZHdEc1h6czZXVWNRRHBjbUlqNzdOYlBQYzJrZVZlcDMxeVZLSUpKDQpkYWhFd2V5NlVFBQeWwwS2xOeFdMODhETGtMZUFvby8rNVNBaUIzUktsUUswMXREWnIrem4rYkxZVUQ4YzU4DQ

  tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBb3RQWi9PRjRHbDQrR3ZxSVE2d0t6ZVhpc1NWNXJyUVd6SStVQ0xSUXBJcmJoKy9aClp1cEM2dkVmMnVIY0E3Rjg3T2xsSEVBNlhKaUkrK3pXenozTnBIbFhxZDljbFNpQ1NYV29STUhzdWtKL1RFbUcKRUhsOTI3M1BFZU1QclhqSUpEeC85K1ZQRUlFRnlHc3hYamFaR2FtZnJYNmJvMVVFaExlMlEySVpWMDh1UU1EMQpUTVArb0VyZHY1MkUzZlAyxxxxxNBSjNUNWtrUm5IaE5TWDFIankySnFBcHNDYW5pKzI4MmV2NGlYYkwwCks1NVA4N3BqdGw4WGtWTGZDbXJYTSt6dEs4aGNkQ3ZCOHU0NkpNRWQ2R1JjeXpBWHJ6b1dYM3RxUGVDdGxrazgKcEVMRXVFSmJpV2hYRjZEVUtlK1NpeHIyMTJHdm5JcncreTBxendJREFRQUJBb0lCQVFDTFhTSWQ1R2xrd0RjTgo1bE1OQU1xNmtrRmw5N3BmZ25wbEdack5uRy9OZGFBU2lJS2VLSEdnSDBOeGw1RTFoQXQxeHdvb2xQeWUxbHVnCnJJVHJHbTNSa1o0cm9pYmU

执行创建：

kubect create -f ingress-secret.yml

也可以通过命令行的方式直接创建一个secret:

kubectl create secret tls ingress-secret --key server.key --cert ca.crt

修改ingress，开启tls

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: dashboard-kibana-ingress

  namespace: kube-system

spec:

  tls:

  - hosts:

    - dashboard.dz11.com

    - kibana.dz11.com

    secretName: ingress-secret

  rules:

  - host: dashboard.dz11.com

    http:

      paths:

      - path: /

        backend:

          serviceName: kubernetes-dashboard

          servicePort: 80

  - host: kibana.dz11.com

    http:

      paths:

      - path: /

        backend:

          serviceName: kibana

          servicePort: 5601

注意：一个 Ingress 只能使用一个 secret(secretName 段只能有一个)，也就是说只能用一个证书，更直白的说就是如果你在一个 Ingress 中配置了多个域名，那么使用 TLS 的话必须保证证书支持该 Ingress 下所有域名；并且这个 secretName 一定要放在上面域名列表最后位置，否则会报错 did not find expected key 无法创建；同时上面的 hosts 段下域名必须跟下面的 rules 中完全匹配

更需要注意一点：Kubernetes Ingress默认情况下，当你不配置证书时，会默认给你一个 TLS 证书的，也就是说你 Ingress 中配置错了，比如写了2个 secretName、或者 hosts 段中缺了某个域名，那么对于写了多个 secretName 的情况，所有域名全会走默认证书；对于 hosts 缺了某个域名的情况，缺失的域名将会走默认证书，部署时一定要验证一下证书，不能 “有了就行”；更新 Ingress 证书可能需要等一段时间才会生效

一旦部署了https，默认请求的http会自动跳转到https，所以在同时需要https和http并存的应用场景，也需要注意

最后重新部署下ingress即可：

kubectl delete -f dashboard-kibana-ingress.yml

kubectl create -f dashboard-kibana-ingress.yml

4. 通过ingress暴露tcp服务

通过ingress暴露tcp服务，我们需要先定义一个nginx-tcp-ingress-configmap.yaml的configmap，示例如下：

apiVersion: v1

kind: ConfigMap

metadata:

  name: tcp-configmap-example

data:

  9000: "default/redis:6379"

以上表示暴露 default namespace 下服务名为 redis，端口为 6379 的服务到 nginx-ingress-lb 所在节点的 9000 端口。

5. 通过configmap修改nginx controller的全局变量

通过上面启动nginx controller的yaml文件，其实我们可以看出来，在启动controller的时候，向启动命令传递了一大堆参数，包括--default-backend-service以及--apiserver-host等。更多的参数，可以直接参考这里

我们知道，nginx controller本质上就是一个nginx代理，这个代理使用了一大堆nginx默认参数启动。而在某些特定场景下，这些我们需要定制这些参数以更适用于我们的需求。在controller启动的时候，提供了一个--configmap的参数，我们可以将需要定制的参数保存到一个configmap中，并在controller启动的时候，来读取这个configmap，获取其值，应用到controller中。具体哪些值可以通过configmap来传递，可以直接参考这里

下面是一个简单的示例：

定义一个名为nginx-controller-configmap的yaml内容如下：

apiVersion: v1

kind: ConfigMap

metadata:

  name: nginx-ingress-configmap

  namespace: default

data:

  proxy-body-size: 1024m

这个configmap定义了一个proxy-body-size的大小为1024m，即nginx中client_max_body_size的参数为1024m。

然后我们通过kubectl exec -it <podname> /bin/sh的方式登录到新的pod，查看/etc/nginx/nginx.conf文件，以确认相应配置是否生效

码农公寓

概述