关于kubernetes:做一个不背锅运维一篇搞定K8s-Ingress

Ingress的呈现

Ingress是一种Kubernetes资源，用于将内部流量路由到Kubernetes集群内的服务。与NodePort相比，它提供了更高级别的路由性能和负载平衡，能够依据HTTP申请的门路、主机名、HTTP办法等来路由流量。

因而，能够说Ingress是为了补救NodePort在流量路由方面的有余而生的。应用NodePort，只能将流量路由到一个具体的Service，并且必须应用Service的端口号来拜访该服务。然而，应用Ingress，就能够应用自定义域名、门路和其余HTTP头来定义路由规定，以便将流量路由到不同的Service。

tantianran@test-b-k8s-master:~$ kubectl api-resources | grep ingressingressclasses                                 networking.k8s.io/v1                   false        IngressClassingresses                         ing          networking.k8s.io/v1                   true         Ingress

此外，Ingress还能够与负载均衡器配合应用，以提供高可用性和程度扩大。这些性能使得Ingress比NodePort更适宜在生产环境中应用。

Ingress和Ingress Controller

「Ingress」Ingress 是 Kubernetes 中的一个形象资源，它提供了一种定义利用裸露入口的办法，能够帮忙管理员在 Kubernetes 集群中治理多个服务的拜访入口，不便用户拜访。Ingress资源对象只是一个规范化的API对象，用于定义流量路由规定和 TLS 设置等信息。它自身不会间接解决或转发流量，而是须要配合一个 Ingress 控制器来实现。

方才提到，Ingress 须要配合 Ingress Controller 应用，须要留神了，不同的 Ingress Controller 可能反对的性能和配置形式不同，须要依据理论状况进行抉择和配置。

「Ingress Controller」Ingress 控制器是一个独立的组件，它会监听 Kubernetes API 中的 Ingress 资源变动，并依据定义的路由规定配置负载均衡器、反向代理或其余网络代理，从而实现内部流量的转发。因而，能够将 Ingress 控制器视为 Ingress 资源的理论执行者。

总之，Kubernetes 的 Ingress 资源对象须要配合 Ingress 控制器能力实现内部流量的转发和路由。Ingress 控制器是 Ingress 资源的理论执行者，负责依据定义的路由规定配置网络代理。

支流的Ingress Controller

在 Kubernetes 中，有很多不同的 Ingress 控制器能够抉择，例如 Nginx、Traefik、HAProxy、Envoy 等等。不同的控制器可能会提供不同的性能、性能和可靠性，能够依据理论需要来抉择适合的控制器。Kubernetes生态系统中有许多不同的Ingress控制器可供选择，其中比拟支流的有：

Nginx Ingress Controller：基于Nginx的Ingress控制器，提供了宽泛的性能和配置选项。
Traefik Ingress Controller：Traefik是一个风行的反向代理和负载均衡器，Traefik Ingress Controller提供了灵便的配置选项和主动发现服务的性能。
Istio Ingress Gateway：Istio是一种服务网格，它提供了基于Envoy代理的Ingress Gateway来治理入站和出站流量。
Contour Ingress Controller：基于Envoy代理的Ingress控制器，具备高度可扩展性和灵便的路由规定。
Kong Ingress Controller：Kong是一个API网关，提供了可扩大的路由和服务治理性能。
Ambassador API Gateway：Ambassador是一个Kubernetes-native API Gateway，提供了自动化的服务发现和路由治理性能。

能够依据理论须要抉择适当的Ingress控制器，并进行相应的配置和部署。

控制器的部署计划

Ingress控制器通常倡议部署在 Kubernetes 集群外部。这样能够确保 Ingress 控制器与 Kubernetes API Server 之间的网络提早较低，并且能够通过 Kubernetes Service 来治理 Ingress 控制器的负载平衡和高可用性。在 Kubernetes 集群外部部署 Ingress 控制器通常有两种形式：

部署一个独立的 Ingress 控制器 Pod：能够通过将 Ingress 控制器部署为一个独立的 Pod，应用 Kubernetes Service 对其进行负载平衡和裸露服务。
部署一个 DaemonSet 类型的 Ingress 控制器：能够通过部署一个 DaemonSet 类型的 Ingress 控制器，使每个节点上都运行一个 Ingress 控制器 Pod，并通过 Kubernetes Service 对其进行负载平衡和裸露服务。

无论是哪种形式，Ingress 控制器都应该被部署在 Kubernetes 集群外部，以便与 Kubernetes API Server 进行通信，并与 Kubernetes 资源（如 Service、Pod、Endpoints 等）进行交互。

装置Nginx Ingress

Nginx 是一个高性能的 Web 服务器和反向代理服务器，能够提供动态内容的疾速响应，同时也能够通过反向代理将申请转发到后端应用程序。

Nginx Ingress 是基于 Nginx 的 Kubernetes Ingress 控制器，它能够在 Kubernetes 集群中提供负载平衡、路由和 TLS 终止等性能。它将 Kubernetes Ingress API 对象转换为 Nginx 配置，并将其利用于 Nginx 服务器。通过 Nginx Ingress，能够轻松地将 HTTP(S) 流量路由到 Kubernetes 中的不同服务。

https://kubernetes.github.io/ingress-nginx/ https://github.com/kubernetes/ingress-nginx/

装置 Nginx Ingress Controller 的形式有多种，以下是其中的一些：

Helm 装置：应用 Helm 工具，能够在 Kubernetes 集群上轻松装置和降级 Nginx Ingress Controller。
Kubernetes YAML 装置：应用 Kubernetes YAML 配置文件，能够在 Kubernetes 集群上装置 Nginx Ingress Controller。
Docker 装置：能够通过 Docker 容器运行 Nginx Ingress Controller。
Bare-metal 装置：能够在没有 Kubernetes 集群的裸机上安装 Nginx Ingress Controller。
Cloud 装置：在某些云平台上，能够应用托管服务的模式装置 Nginx Ingress Controller，例如 Google Cloud Platform 上的 GKE。

无论抉择哪种形式，都须要依据理论状况进行调整和配置，以确保 Nginx Ingress Controller 可能失常工作。

装置Nginx Ingress Controller

应用Helm装置：

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginxhelm repo updatekubectl create namespace ingress-nginxhelm install ingress-nginx ingress-nginx/ingress-nginx \--namespace ingress-nginx \--set controller.publishService.enabled=truekubectl get pods -n ingress-nginxkubectl get svc -n ingress-nginx

下面的命令将在命名空间中装置控制器，如果该命名空间尚不存在，则创立该命名空间ingress-nginx。此命令是幂等的：

如果未装置入口控制器，它将装置它，
如果已装置入口控制器，它将对其进行降级。

应用YAML装置：

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.6.4/deploy/static/provider/cloud/deploy.yamlmv deploy.yaml ingress-nginx-controller.yaml kubectl apply -f ingress-nginx-controller.yaml# 或者间接kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.6.4/deploy/static/provider/cloud/deploy.yaml

留神，可能会应网络问题无奈拉取相干镜像，能够批改ingress-nginx-controller.yaml文件里image字段的仓库地址，我曾经把镜像传到我的Docker Hub仓库中：

tantianran/ingress-controller:v1.6.4
tantianran/kube-webhook-certgen:v20220916-gd32f8c343

例如，批改后：

tantianran@test-b-k8s-master:~$ egrep "image" ingress-nginx-controller.yaml | grep -v imagePullPolicy        image: tantianran/ingress-controller:v1.6.4        image: tantianran/kube-webhook-certgen:v20220916-gd32f8c343        image: tantianran/kube-webhook-certgen:v20220916-gd32f8c343

装置后查看pod

tantianran@test-b-k8s-master:~$ kubectl get pod -n ingress-nginxNAME                                        READY   STATUS      RESTARTS      AGEingress-nginx-admission-create-z4hlb        0/1     Completed   0             47hingress-nginx-admission-patch-ffbwz         0/1     Completed   0             47hingress-nginx-controller-5f4c9fdd9b-l55ch   1/1     Running     1 (10m ago)   47h

ingress-nginx-controller是Ingress-nginx的控制器组件，它负责监督Kubernetes API server上的Ingress对象，并依据配置动静地更新Nginx配置文件，实现HTTP(S)的负载平衡和路由。
ingress-nginx-admission-create和ingress-nginx-admission-patch都是Kubernetes Admission Controller，它们不是始终处于运行状态的容器，而是依据须要动静地生成和销毁。这些Admission Controller在Kubernetes中以Deployment的形式进行部署，因而，它们的Pod将依据正本数创立多个正本，并依据负载和须要动静地生成和销毁。
- ingress-nginx-admission-create是一个Kubernetes Admission Controller，它能够拦挡Kubernetes集群内的Ingress对象的创立操作，并在Ingress对象创立之前，对其进行一些额定的验证和解决。
- ingress-nginx-admission-patch也是一个Kubernetes Admission Controller，它能够在Ingress对象更新之前，对其进行额定的验证和解决，相似于ingress-nginx-admission-create。

「有没有留神到nginx-admission-create和ingress-nginx-admission-patch这两个pod的状态是Completed？」 当这两个Pod被创立时，它将开始运行容器，执行必要的初始化和验证操作，而后尝试解决Kubernetes API server发送的申请。如果申请曾经被处理完毕，容器将失常终止，并将Pod的状态设置为Completed。因而，Pod处于Completed状态并不示意有任何问题或谬误，而是示意容器曾经实现了它须要实现的工作并终止了运行。

须要留神的是，如果在Pod终止之前呈现谬误或异样，Pod的状态将会被设置为Failed，这可能须要进行进一步的故障排除和修复。

装置后查看Service

tantianran@test-b-k8s-master:~$ kubectl get svc -n ingress-nginxNAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGEingress-nginx-controller             LoadBalancer   10.106.241.48   <pending>     80:30806/TCP,443:30178/TCP   2dingress-nginx-controller-admission   ClusterIP      10.109.39.65    <none>        443/TCP                      2dtantianran@test-b-k8s-master:~$

ingress-nginx-controller Service：这个Service负责将申请转发到ingress-nginx-controller Pods。它通常会将流量散发到ingress-nginx-controller的多个正本中，并确保正本集的负载平衡。这个Service能够被配置为应用NodePort、LoadBalancer或ClusterIP类型，依据须要进行裸露。

ingress-nginx-controller-admission Service：这个Service是用于 Kubernetes Admission Webhooks 的，容许在创立、更新或删除资源时，对其进行校验或批改。它提供了一个API Endpoint，用于与 Kubernetes API Server 进行通信，以便进行这些校验或批改。该Service也能够被配置为应用NodePort、LoadBalancer或ClusterIP类型，依据须要进行裸露。

通常状况下，ingress-nginx-controller和ingress-nginx-controller-admission都是在同一个Deployment中运行的，以确保它们始终具备雷同的标签。这些标签容许其余Kubernetes对象（例如Ingress）能够辨认哪些Pods是由ingress-nginx-controller和ingress-nginx-controller-admission负责的，并将申请路由到正确的Pods中。

创立测试利用和ingress资源对象

创立测试利用的Deployment和Services，编辑test-goweb.yaml：

apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: test-goweb  name: test-gowebspec:  replicas: 6  selector:    matchLabels:      app: test-goweb  template:    metadata:      labels:        app: test-goweb    spec:      containers:      - image: 192.168.11.247/web-demo/goweb-demo:20221229v3        name: goweb-demo        ports:        - containerPort: 8090          protocol: TCP---apiVersion: v1kind: Servicemetadata:  labels:    app: test-goweb  name: test-gowebspec:  ports:  - name: 80-8090    port: 80    protocol: TCP    targetPort: 8090  selector:    app: test-goweb  type: ClusterIP

在下面的Yaml配置文件中，采纳的Service类型是ClusterIP类型，ClusterIP类型的Service只能从K8S集群外部拜访，因而须要将其与Ingress Controller联合应用，以便内部客户端能够拜访集群中的应用程序。当客户端申请达到Ingress时，Ingress Controller会将申请路由到相应的Service，而后Service再将申请路由到Pod中运行的容器。

kubectl apply -f test-goweb.yaml

查看Service资源

tantianran@test-b-k8s-master:~$ kubectl get svcNAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGEkubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   120dtest-goweb   ClusterIP   10.105.248.32   <none>        80/TCP    81m # 这个等会是要用到的，Service名称为test-goweb，端口为80tantianran@test-b-k8s-master:~$

查看以后集群中定义的所有IngressClass对象

tantianran@test-b-k8s-master:~$ kubectl get ingressclassNAME    CONTROLLER             PARAMETERS   AGEnginx   k8s.io/ingress-nginx   <none>       2d2h # 这个nginx控制器就是咱们等会要用的tantianran@test-b-k8s-master:~$

在k8s中，Ingress 资源对象能够用来裸露服务，将内部流量路由到外部集群服务。然而，在一个集群中，可能须要应用不同的 Ingress 控制器来满足不同的需要，而每个控制器都须要应用不同的配置和规定。这就是 IngressClass 的作用。通过定义不同的 IngressClass，能够为不同的 Ingress 控制器指定不同的配置和规定，从而更好地治理 Ingress 资源对象。

定义Ingress资源的YAML文件，用于创立Ingress资源对象，编辑test-goweb-ingress.yaml：

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: test-gowebspec:  ingressClassName: nginx  rules:  - host: "test.noblameops.local"    http:      paths:      - path: /login        pathType: Prefix        backend:          service:            name: test-goweb            port:              number: 80      - path: /home        pathType: Prefix        backend:          service:            name: test-goweb            port:              number: 80      - path: /        pathType: Prefix        backend:          service:            name: test-goweb            port:              number: 80

这个 Ingress 配置了3个门路，后端为同一个Services，上面仅拿门路"/"做解说：

在 metadata 字段中，name 字段指定了创立的 Ingress 资源的名称。
在 spec 字段中，ingressClassName 字段指定了要应用的 Ingress 控制器。在这里应用了名为 nginx 的 Ingress 类别。
rules 字段指定了 Ingress 的规定列表。在这里只有一个规定，即当内部流量通过 HTTP 拜访 Ingress 时，应该应用上面的配置：
path 字段指定了应该匹配的 URL 门路。在这里，所有门路都匹配 /。
pathType 字段指定了门路匹配形式，这里应用了 Prefix 类型，示意只有门路以 / 结尾，就匹配胜利。
backend 字段指定了要将匹配的流量转发到哪个后端（Service）。在这里抉择了名为 test-goweb 的 Service（ClusterIP类型），该 Service 中的 80 端口将接管流量。

开始创立

kubectl apply -f test-goweb-ingress.yaml

创立ingress资源对象后查看

tantianran@test-b-k8s-master:~$ kubectl get ingressNAME         CLASS   HOSTS                   ADDRESS         PORTS   AGEtest-goweb   nginx   test.noblameops.local   10.105.254.90   80      9m32stantianran@test-b-k8s-master:~$

这条命令输入了一个名为 test-goweb 的 Ingress 资源，它将路由到 test.noblameops.local 这个主机名，并在端口 80 上监听申请。咱们来看看输入字段的意义：

NAME: Ingress 资源的名称是 test-goweb。
CLASS: Ingress 资源应用的 Ingress 类别为 nginx。
HOSTS: Ingress 资源配置的主机名为 test.noblameops.local。这表明所有申请都将被路由到这个主机名。
ADDRESS: 没有指定 IP 地址，这意味着 Ingress 控制器将为 Ingress 资源分配一个 IP 地址。
PORTS: Ingress 资源将监听端口 80 上的申请。
AGE: Ingress 资源的创立工夫是 9 秒前。

Ingress Controller的裸露形式

当应用K8S中的Ingress资源对象来裸露利用时，用户拜访利用的入口是 Ingress Controller 的地址。Ingress Controller 会依据 Ingress 规定将申请路由到相应的服务，并将服务的响应返回给客户端。这时候就要把Ingress Controller裸露进来，裸露形式有以下几种：

NodePort：应用 NodePort 服务类型来裸露 Ingress Controller，这种形式能够将 Ingress Controller 裸露到 Kubernetes 集群的所有节点上，通过节点的 IP 地址和 NodePort 能够拜访到 Ingress Controller。NodePort形式将Ingress Controller的端口映射到节点的一个随机端口上，这种形式的长处是比较简单，易于配置和治理。然而，它的毛病是须要裸露每个节点的端口，这可能会导致端口号不够用，或者在平安方面存在一些隐患。

![图片]()

HostNetwork（共享宿主机网络）：应用 HostNetwork 字段来裸露 Ingress Controller，这种形式能够将 Ingress Controller 间接裸露到节点的网络命名空间中，从而能够间接应用节点的 IP 地址来拜访 Ingress Controller。HostNetwork形式将Ingress Controller的容器间接绑定到主机的网络上，这种形式的长处是能够间接应用主机的网络资源，性能较好，并且能够防止NodePort形式中的安全隐患。毛病是如果Ingress Controller容器解体，它会影响主机上的其余容器。

![图片]()

LoadBalancer：应用 LoadBalancer 服务类型来裸露 Ingress Controller，这种形式能够将 Ingress Controller 裸露到云服务提供商的负载均衡器上，从而能够通过负载均衡器的 IP 地址来拜访 Ingress Controller。能够实现更好的负载平衡和高可用性。这种形式的长处是能够主动创立负载均衡器，能够动静地调配IP地址，易于治理和扩大。然而，它的毛病是须要依赖云厂商提供的负载均衡器服务，对于一些不反对负载均衡器服务的云平台或者本地环境不太实用。
ExternalIPs：应用 ExternalIPs 字段来指定内部 IP 地址来裸露 Ingress Controller，这种形式须要手动配置内部 IP 地址，并且只实用于具备动态 IP 地址的环境。

接下来的场景，咱们采纳NodePort形式来裸露Ingress Controller。

查看ingress controller的Service

从上面的查问后果能够看到，ingress-nginx-controller的Service类型默认是LoadBalancer，该类型能够通过云提供商的负载均衡器（如 AWS ELB、Google Cloud Load Balancer 等）来公开服务。

tantianran@test-b-k8s-master:~$ kubectl get svc -n ingress-nginxNAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGEingress-nginx-controller             LoadBalancer   10.106.241.48   <pending>     80:30806/TCP,443:30178/TCP   2d6hingress-nginx-controller-admission   ClusterIP      10.109.39.65    <none>        443/TCP                      2d6htantianran@test-b-k8s-master:~$

我的环境是本地的K8S环境，我只是须要在本地 K8S 环境中进行测试和开发而已，所以能够将其批改为 NodePort 类型，以便将服务公开到集群内的所有节点。NodePort 类型的 Service 能够将服务公开到 K8S 集群中的所有节点的固定端口，这种形式就是实用于本地测试和开发环境。

批改成NodePort的形式：在下载回来的ingress-nginx-controller.yaml配置文件里找到ingress-nginx-controller的Service

apiVersion: v1kind: Servicemetadata:  labels:    app.kubernetes.io/component: controller    app.kubernetes.io/instance: ingress-nginx    app.kubernetes.io/name: ingress-nginx    app.kubernetes.io/part-of: ingress-nginx    app.kubernetes.io/version: 1.6.4  name: ingress-nginx-controller  namespace: ingress-nginxspec:  externalTrafficPolicy: Local  ipFamilies:  - IPv4  ipFamilyPolicy: SingleStack  ports:  - appProtocol: http    name: http    port: 80    protocol: TCP    targetPort: http    nodePort: 30080 # 减少此处  - appProtocol: https    name: https    port: 443    protocol: TCP    targetPort: https    nodePort: 30443 # 减少此处  selector:    app.kubernetes.io/component: controller    app.kubernetes.io/instance: ingress-nginx    app.kubernetes.io/name: ingress-nginx  type: NodePort # 批改此处

批改实现后干掉原来的再从新创立：

kubectl delete -f ingress-nginx-controller.yamlkubectl create -f ingress-nginx-controller.yamltantianran@test-b-k8s-master:~$ kubectl get svc -n ingress-nginxNAME                                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGEingress-nginx-controller             NodePort    10.100.117.82   <none>        80:30080/TCP,443:30443/TCP   9s # 胜利批改为NodePort类型ingress-nginx-controller-admission   ClusterIP   10.101.46.195   <none>        443/TCP                      9stantianran@test-b-k8s-master:~$ kubectl get pod -n ingress-nginx -o wideNAME                                        READY   STATUS      RESTARTS   AGE   IP              NODE                NOMINATED NODE   READINESS GATESingress-nginx-admission-create-ftntz        0/1     Completed   0          10m   10.244.240.43   test-b-k8s-node01   <none>           <none>ingress-nginx-admission-patch-9xvhv         0/1     Completed   1          10m   10.244.240.49   test-b-k8s-node01   <none>           <none>ingress-nginx-controller-55cbbdbf87-dq558   1/1     Running     0          10m   10.244.240.23   test-b-k8s-node01   <none>           <none>tantianran@test-b-k8s-master:~$

拜访

ingress-nginx-controller的POD只设置了1个，且以后是运行在 test-b-k8s-node01 节点上，该节点的宿主机IP就能够作为入口了，而后在零碎hosts增加域名映射：

192.168.11.14 test.noblameops.local

Https配置

上面应用cfssl工具给域名test.noblameops.local生成自签名证书，并在k8s中应用nginx ingress以https的形式裸露。

装置cfssl相干工具

curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfsslcurl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljsoncurl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfochmod +x cfssl cfssljson cfssl-certinfomv cfssl cfssljson cfssl-certinfo /usr/local/bin/

创立证书配置文件创立一个证书配置文件，例如cert.json，蕴含以下内容：

cat > cert.json <<EOF{  "hosts": [    "test.noblameops.local"  ],  "key": {    "algo": "rsa",    "size": 2048  },  "names": [    {      "C": "CN",      "ST": "GuangDong",      "L": "GuangZhou",      "O": "Noblameops",      "OU": "Noblameops",      "CN": "test.noblameops.local"    }  ]}EOF

其中，"hosts"字段指定要蕴含在证书中的主机名或IP地址，这里只蕴含了"test.noblameops.local"；"key"字段指定应用RSA算法和2048位密钥生成证书；"names"字段指定证书中的各种名称和标识，包含组织、部门和通用名称（CN）。

生成证书和密钥

cfssl gencert -initca cert.json | cfssljson -bare test.noblameops.local

这将生成三个文件：test.noblameops.local.csr、test.noblameops.local-key.pem和test.noblameops.local.pem。其中，test.noblameops.local.pem是证书文件，test.noblameops.local-key.pem是证书私钥文件。

创立k8s secret对象将生成的证书和密钥文件打包成一个k8s secret对象。能够应用以下命令创立该对象

kubectl create secret tls test-noblameops-local-tls --key test.noblameops.local-key.pem --cert test.noblameops.local.pemkubectl get secret

其中，test-noblameops-local-tls是secret对象的名称，--key参数指定私钥文件的门路，--cert参数指定证书文件的门路。

创立nginx ingress资源创立一个nginx ingress资源，将证书配置和TLS配置增加到该资源中

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: test-gowebspec:  ingressClassName: nginx  tls:  - hosts:    - test.noblameops.local    secretName: test-noblameops-local-tls  rules:  - host: "test.noblameops.local"    http:      paths:      - path: /login        pathType: Prefix        backend:          service:            name: test-goweb            port:              number: 80      - path: /home        pathType: Prefix        backend:          service:            name: test-goweb            port:              number: 80      - path: /        pathType: Prefix        backend:          service:            name: test-goweb            port:              number: 80

https拜访

本文转载于WX公众号：不背锅运维（喜爱的盆友关注咱们）：https://mp.weixin.qq.com/s/2pBiTgnLgSQLrIi4yGHEew