Kubernetes系列-Ingress-Toy模板网

这篇具有很好参考价值的文章主要介绍了Kubernetes系列-Ingress。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

1 Ingress 概述

Kubernetes 对外暴露服务（Service）主要有两种方式：NodePort，LoadBalance，此外 externalIps 也可以使各类 service 对外提供服务，但是当集群服务很多的时候，NodePort方式最大的缺点是会占用很多集群机器的端口；LB方式最大的缺点则是每个Service一个LB又有点浪费和麻烦，并且需要K8s之外的支持；而 Ingress 则只需要一个 NodePort或者一个LB就可以满足所有 Service 对外服务的需求。工作机制大致如下图：

Kubernetes系列-Ingress,kubernetes,容器,云原生

Ingress为Kubernetes集群中的服务提供了入口，可以提供负载均衡、SSL终止和基于名称的虚拟主机，在生产环境中常用的Ingress有Treafik、Nginx、HAProxy、Istio等。

Ingress用于从集群外部到集群内部Service的HTTP和HTTPS路由，流量从Internet到Ingress再到Services最后到Pod上，通常情况下，Ingress部署在所有的Node节点上。

Ingress可以配置提供服务外部访问的URL、负载均衡、终止SSL，并提供基于域名的虚拟主机。但Ingress不会暴露任意端口或协议。

2 为什么需要Ingress资源？

由于K8S集群拥有强大的副本控制能力，Pod随时可能从一个节点上被驱逐到另一个节点上，或者直接销毁再来一个新的。

然而伴随着Pod的销毁和重生，Pod的IP等信息不断地在改变，此时使用K8S提供的Service机制可以解决这一问题，Service通过标签选定指定的Pod作为后端服务，并监听这些Pod的变化。

在对外暴露服务时，使用Service的NodePort是一个方法，但同时也面临以下问题：

1）如何管理端口
当需要对外暴露的服务量比较多的时候，端口管理的问题变会暴露出来。

此时的一个处理方案是使用一个代理服务（例如nginx）根据请求信息将请求转发到不同的服务器上。

2）如何管理转发配置
每当有新服务加入，都需要对该服务的配置进行修改、升级，在服务数量逐渐变多后，该配置项目会变得越来越大，手工修改的风险也会逐渐增高。

那么需要一个工具来简化这一过程，希望可以通过简单的配置动态生成代理中复杂的配置，最好还可以顺手重新加载配置文件。

K8S刚好也提供了此类型资源。

2.1 Pod漂移问题

众所周知 Kubernetes 具有强大的副本控制能力，能保证在任意副本(Pod)挂掉时自动从其他机器启动一个新的，还可以动态扩容等，总之一句话，这个 Pod 可能在任何时刻出现在任何节点上，也可能在任何时刻死在任何节点上；那么自然随着 Pod 的创建和销毁，Pod IP 肯定会动态变化；那么如何把这个动态的 Pod IP 暴露出去？这里借助于 Kubernetes 的 Service 机制，Service 可以以标签的形式选定一组带有指定标签的 Pod，并监控和自动负载他们的 Pod IP，那么我们向外暴露只暴露 Service IP 就行了，这就是 NodePort 模式：即在每个节点上开起一个端口，然后转发到内部 Pod IP 上，如下图所示：

Kubernetes系列-Ingress,kubernetes,容器,云原生

2.2 端口管理问题

采用 NodePort 方式暴露服务面临一个问题是：当服务一旦多起来，NodePort 在每个节点上开启的端口会及其庞大，而且难以维护；这时候引出的思考问题是 “能不能使用 Nginx 啥的只监听一个端口，比如 80，然后按照域名向后转发？” 这思路很好，简单的实现就是使用 DaemonSet 在每个 node 上监听 80，然后写好规则，因为 Nginx 外面绑定了宿主机 80 端口(就像 NodePort)，本身又在集群内，那么向后直接转发到相应 Service IP 就行了，如下图所示：

Kubernetes系列-Ingress,kubernetes,容器,云原生

2.3 域名分配及动态更新问题

从上面的思路，采用 Nginx 似乎已经解决了问题，但是其实这里面有一个很大缺陷：每次有新服务加入怎么改 Nginx 配置？总不能手动改或者来个 Rolling Update 前端 Nginx Pod 吧？这时候 “伟大而又正直勇敢的” Ingress 登场，如果不算上面的 Nginx，Ingress 只有两大组件：Ingress Controller 和 Ingress。

Ingress 简单的理解就是：原来要改 Nginx 配置，然后配置各种域名对应哪个 Service，现在把这个动作抽象出来，变成一个 Ingress 对象，可以用 yml 创建，每次不要去改 Nginx 了，直接改 yml 然后创建/更新就行了；那么问题来了：”Nginx 怎么办？”

Ingress Controller 这东西就是解决 “Nginx 怎么动态调整”的；Ingress Controoler 通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取，按照根据ingress规则模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最后 reload 一下，工作流程如下图：

Kubernetes系列-Ingress,kubernetes,容器,云原生

当然在实际应用中，最新版本 Kubernetes 已经将 Nginx 与 Ingress Controller 合并为一个组件，所以 Nginx 无需单独部署，只需要部署 Ingress Controller 即可 。

3 Ingress的工作方式

Ingress 工作原理
（1）ingress-controller通过和 kubernetes APIServer 交互，动态的去感知集群中ingress规则变化；
（2）然后读取ingress规则，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置；
（3）将nginx配置写到nginx-ingress-controller的pod里，这个ingress-controller的pod里运行着一个Nginx服务，控制器会把生成的 nginx配置写入 /etc/nginx.conf文件中；
（4）然后reload一下使配置生效。以此达到域名区分配置和动态更新的作用。

在使用普通的Service时，集群中每个节点的kube-proxy在监听到Service和Endpoints的变化时，会动态的修改相关的iptables的转发规则。客户端在访问时通过iptables设置的规则进行路由转发达到访问服务的目的。

而Ingress则跳过了kube-proxy这一层，通过Ingress Controller中的代理配置进行路由转发达到访问目标服务的目的。
Kubernetes系列-Ingress,kubernetes,容器,云原生

实际上可以把IngressController看做一个拥有默认处理后端的代理，根据Ingress资源的配置动态修改代理的配置文件，以实现按照规则转发请求的功能。

4 ingress源码配置结构

type Ingress struct {
    metav1.TypeMeta `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`
 
    // Ingess配置。
    Spec IngressSpec `json:"spec,omitempty"`
 
    // Ingress资源当前状态。
    Status IngressStatus `json:"status,omitempty"`
}
type IngressSpec struct {
    // 默认的后端服务，当不匹配所有的Ingress规则的时候使用。
    // 一般情况默认后端都在Ingress控制器中配置，该字段不进行声明配置。
    // 如果没有主机或路径与 Ingress 对象中的 HTTP 请求匹配，则流量将路由到您的默认后端。
    Backend *IngressBackend `json:"backend,omitempty"`
 
    // TLS配置。目前Ingress只支持443一种TLS端口。
    // 如果列表中有多个不同的hosts，将会在ingress controller支持SNI的情况下,
    // 通过使用SNI TLS扩展中声明的主机名，在同个端口下使用多路复用。
    TLS []IngressTLS `json:"tls,omitempty"`
 
    // Ingress的规则。未匹配到规则列表中规则的请求将会被转发到默认后端上。
    Rules []IngressRule `json:"rules,omitempty"`
}
type IngressBackend struct {
    // 服务名。
    ServiceName string `json:"serviceName"`
 
    // 服务的端口。
    ServicePort intstr.IntOrString `json:"servicePort"`
}
type IngressRule struct {
    // 域名。
    // 不能使用IP地址，不能使用端口。对HTTP服务使用80端口，HTTPS服务使用443端口。
    Host string `json:"host,omitempty"`
 
    // 域名下的具体转发规则。
    // 未定义的情况下会将请求转发至默认后端。
    IngressRuleValue `json:",inline,omitempty"`
}
type IngressRuleValue struct {
    HTTP *HTTPIngressRuleValue `json:"http,omitempty"`
}
type HTTPIngressRuleValue struct {
    Paths []HTTPIngressPath `json:"paths"`
}
type HTTPIngressPath struct {
    // 匹配的路径，必须以/为开头。
    // 未定义的情况下会将请求转发至默认后端。
    Path string `json:"path,omitempty"`
 
    // 处理请求的后端服务。
    Backend IngressBackend `json:"backend"`
}

5 部署使用Ingress

5.1 部署 nginx-ingress-controller

5.1.1 部署ingress-controller pod及相关资源

[root@k8s-master opt]# mkdir /opt/ingress
[root@k8s-master opt]# cd ingress/
[root@k8s-master ingress]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.25.0/deploy/static/mandatory.yaml
--2022-08-09 17:07:00--  https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.25.0/deploy/static/mandatory.yaml
正在解析主机 raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.111.133, 185.199.110.133, 185.199.108.133, ...
正在连接 raw.githubusercontent.com (raw.githubusercontent.com)|185.199.111.133|:443... 已连接。
已发出 HTTP 请求，正在等待回应... 200 OK
长度：5976 (5.8K) [text/plain]
正在保存至: “mandatory.yaml”
 
100%[===================================================================>] 5,976       --.-K/s 用时 0s      
 
2022-08-09 17:07:00 (99.1 MB/s) - 已保存 “mandatory.yaml” [5976/5976])
 
[root@k8s-master ingress]# ll
总用量 8
-rw-r--r--. 1 root root 5976 8月   9 17:07 mandatory.yaml

官方下载地址：

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

上面的下载地址可能无法下载，可用国内的Gitee地址

wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.25.0/deploy/static/mandatory.yaml
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml

# mandatory.yaml文件中包含了很多资源的创建，包括namespace、ConfigMap、role，ServiceAccount等等所有部署ingress-controller需要的资源。

5.2 修改ClusterRole资源配置

vim mandatory.yaml
......
apiVersion: rbac.authorization.k8s.io/v1beta1
#RBAC相关资源从1.17版本开始改用rbac.authorization.k8s.io/v1，rbac.authorization.k8s.io/v1beta1在1.22版本即将弃用
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"    # （0.25版本）增加 networking.k8s.io Ingress 资源的 api 
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"   # （0.25版本）增加 networking.k8s.io/v1 Ingress 资源的 api 
    resources:
      - ingresses/status
    verbs:
      - update

5.3 ingress 暴露服务的方式

方式一：Deployment+LoadBalancer 模式的 Service

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

方式二：DaemonSet+HostNetwork+nodeSelector

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

方式三：Deployment+NodePort模式的Service

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

采用方式二：DaemonSet+HostNetwork+nodeSelector

5.4 指定 nginx-ingress-controller 运行在node02 节点

[root@k8s-master ingress]# kubectl get nodes
NAME         STATUS   ROLES                  AGE    VERSION
k8s-master   Ready    control-plane,master   7d1h   v1.21.3
k8s-node01   Ready    <none>                 7d1h   v1.21.3
k8s-node02   Ready    <none>                 7d1h   v1.21.3
[root@k8s-master ingress]# kubectl label node k8s-node02 ingress=true
node/k8s-node02 labeled
[root@k8s-master ingress]# kubectl get nodes --show-labels
NAME         STATUS   ROLES                  AGE    VERSION   LABELS
k8s-master   Ready    control-plane,master   7d1h   v1.21.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
k8s-node01   Ready    <none>                 7d1h   v1.21.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node01,kubernetes.io/os=linux
k8s-node02   Ready    <none>                 7d1h   v1.21.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,ingress=true,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node02,kubernetes.io/os=linux

5.5 修改Deployment 为 DaemoSet,指定节点运行，并开启hostNetwork网络

vim mandatory.yaml
...
apiVersion: apps/v1
# 修改 kind
# kind: Deployment
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:
      # 使用主机网络
      hostNetwork: true
      # 选择节点运行
      nodeSelector:
        ingress: "true"
      serviceAccountName: nginx-ingress-serviceaccount
......

5.6 在所有node节点上传nginx-ingress-controller 镜像压缩包

ingree.contro.tar.gz 到 /opt/ingress 目录，并解压和加载镜像
cd /opt/ingress
tar zxvf ingree.contro.tar.gz
docker load -i ingree.contro.tar
或者使用docker pull拉取镜像
[root@k8s-master ingress]# docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:0.30.0

5.7 启动nginx-ingress-controller

[root@k8s-master ingress]# kubectl apply -f mandatory.yaml
namespace/ingress-nginx unchanged
configmap/nginx-configuration unchanged
configmap/tcp-services unchanged
configmap/udp-services unchanged
serviceaccount/nginx-ingress-serviceaccount unchanged
Warning: rbac.authorization.k8s.io/v1beta1 ClusterRole is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRole
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole unchanged
Warning: rbac.authorization.k8s.io/v1beta1 Role is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 Role
role.rbac.authorization.k8s.io/nginx-ingress-role unchanged
Warning: rbac.authorization.k8s.io/v1beta1 RoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 RoleBinding
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding unchanged
Warning: rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding unchanged
daemonset.apps/nginx-ingress-controller unchanged
[root@k8s-master ingress]# kubectl get pod -n ingress-nginx -o wide
//nginx-ingress-controller 已经运行 node02 节点
NAME                             READY   STATUS    RESTARTS   AGE   IP               NODE         NOMINATED NODE   READINESS GATES
nginx-ingress-controller-nhsxt   1/1     Running   0          50m   192.168.161.18   k8s-node02   <none>           <none>
[root@k8s-master ingress]# kubectl get cm,daemonset -n ingress-nginx -o wide
NAME                                        DATA   AGE
configmap/ingress-controller-leader-nginx   0      45m
configmap/kube-root-ca.crt                  1      67m
configmap/nginx-configuration               0      67m
configmap/tcp-services                      0      67m
configmap/udp-services                      0      67m
 
NAME                                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS                 IMAGES                                                                  SELECTOR
daemonset.apps/nginx-ingress-controller   1         1         1       1            1           ingress=true    67m   nginx-ingress-controller   quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.0   app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/part-of=ingress-nginx

到 node02 节点查看

[root@k8s-node02 ingress]# netstat -lntp | grep nginx
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      117191/nginx: maste 
tcp        0      0 0.0.0.0:8181            0.0.0.0:*               LISTEN      117191/nginx: maste 
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      117191/nginx: maste 
tcp6       0      0 :::10254                :::*                    LISTEN      117165/nginx-ingres 
tcp6       0      0 :::80                   :::*                    LISTEN      117191/nginx: maste 
tcp6       0      0 :::8181                 :::*                    LISTEN      117191/nginx: maste 
tcp6       0      0 :::443                  :::*                    LISTEN      117191/nginx: maste

由于配置了 hostnetwork，nginx 已经在 node 主机本地监听 80/443/8181 端口。其中 8181 是 nginx-controller 默认配置的一个 default backend（Ingress 资源没有匹配的 rule 对象时，流量就会被导向这个 default backend）。
这样，只要访问 node 主机有公网 IP，就可以直接映射域名来对外网暴露服务了。如果要 nginx 高可用的话，可以在多个 node上部署，并在前面再搭建一套 LVS+keepalived 做负载均衡

5.8 创建ingress规则

创建一个deploy和svc

[root@k8s-master ingress]# vim service-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
spec:
  replicas: 2
  seleector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-app-svc
spec:
  type: ClusterIP
  ports:
  - protocol: TCP
    prot: 80
    targetPort:
  selector:
    app: nginx

创建ingress

#方法一：（extensions/v1beta1 Ingress 在1.22版本即将弃用）
vim ingress-app.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-app-ingress
spec:
  rules:
  - host: www.liang.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-app-svc
          servicePort: 80
 
#方法二：
vim ingress-app.yaml	  
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-app-ingress
spec:
  rules:
  - host: www.liang.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-app-svc
            port:
              number: 80

[root@k8s-master ingress]# kubectl apply -f service-nginx.yaml
deployment.apps/nginx-app unchanged
service/nginx-app-svc created
[root@k8s-master ingress]# kubectl apply -f ingress-app.yaml 
ingress.networking.k8s.io/nginx-app-ingress created
[root@k8s-master ingress]# kubectl get pods
NAME                                      READY   STATUS              RESTARTS   AGE
nginx-app-845d4d9dff-4m44r                0/1     Running             0          15m
nginx-app-845d4d9dff-cvxrz                0/1     Running             0          15m
[root@k8s-master ingress]# kubectl get ingress
NAME                CLASS    HOSTS           ADDRESS   PORTS   AGE
nginx-app-ingress   <none>   www.liang.com             80      15m

5.9 测试访问

本地host添加域名解析

[root@k8s-master ingress]# vim /etc/hosts
 
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.161.16 k8s-master
192.168.161.17 k8s-node01
192.168.161.18 k8s-node02
192.168.161.18 www.liang.com
[root@k8s-master ingress]# curl www.liang.com

5.10 查看 nginx-ingress-controller

[root@k8s-master ingress]# kubectl get pod -n ingress-nginx -o wide
NAME                             READY   STATUS    RESTARTS   AGE    IP               NODE         NOMINATED NODE   READINESS GATES
nginx-ingress-controller-nhsxt   1/1     Running   0          123m   192.168.161.18   k8s-node02   <none>           <none>
[root@k8s-master ingress]# kubectl exec -it nginx-ingress-controller-nhsxt -n ingress-nginx /bin/bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
www-data@k8s-node02:/etc/nginx$ more /etc/nginx/nginx.conf
可以看到从 start server www.liang.com 到 end server www.liang.com 之间包含了此域名用于反向代理的配置

文章来源地址https://www.toymoban.com/news/detail-623437.html

到了这里，关于Kubernetes系列-Ingress的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！