Ingress介绍

• Kubernetes 集群中，服务（Service）是一种抽象，它定义了一种访问 Pod 的方式，无论这些 Pod 如何变化，服务都保持不变。服务可以被映射到一个静态的 IP 地址（ClusterIP）、一个 NodePort（在集群的每个节点上的特定端口）、一个 LoadBalancer（通过云服务提供商的负载均衡器）或一个外部 IP。

• Service的两种服务暴露方式，NodePort 和 LoadBalancer，确存在一些局限性：

  • NodePort：当一个服务被配置为 NodePort 类型时，它会在集群的所有节点上的一个静态端口上暴露服务。这种方式的缺点是，如果集群中有大量的服务，那么就需要占用大量的端口，而这些端口资源是有限的。

  • LoadBalancer：这种方式通过云服务提供商的负载均衡器来暴露服务。虽然它解决了 NodePort 方式中端口资源有限的问题，但是每个服务都需要一个单独的负载均衡器，这不仅增加了成本，而且管理起来也相对复杂。

• 为了解决这些问题，Kubernetes 引入了 Ingress 资源对象：

  • Ingress 是一种 API 对象，它管理外部访问到集群内服务的 HTTP 和 HTTPS 路由。它提供了一种规则，允许你将外部 HTTP/HTTPS 路由到集群内的多个服务。

  • Ingress 可以提供单一的 IP 地址，通过不同的 URL 路径或不同的端口来路由到不同的服务。

  • 它只需要一个 NodePort 或者一个 LoadBalancer，就可以将多个服务暴露给外部网络，这样做既节省了资源，又简化了配置。

  • Ingress 还支持 SSL/TLS 终止，可以为不同的服务配置 SSL 证书。

  • 它允许更复杂的路由规则，比如基于路径、主机名或 HTTP 头部的路由。

部署ingress-nginx： 

我的K8S集群版本为1.21，使用的是ingress-nginx-controller-v1.10.1

[root@K8s-master-01 ~]# wget -c https://gitee.com/kong-xiangyuxcz/svn/releases/download/ingress-nginx-controller-v1.10.1/deploy.yaml

[root@k8s-master-01 ~]# sed -i 's#registry.k8s.io/ingress-nginx/controller:v1.10.1.*#registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:v1.10.1#' deploy.yaml 

[root@k8s-master-01 ~]# sed -i 's#registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.4.1.*#registry.cn-hangzhou.aliyuncs.com/google_containers/kube-webhook-certgen:v1.4.1#g' deploy.yaml

[root@k8s-master-01 ~]# sed -i '345 a \
  annotations: \
    lb.kubesphere.io/v1alpha1: openelb \
    protocol.openelb.kubesphere.io/v1alpha1: layer2 \
    eip.openelb.kubesphere.io/v1alpha2: eip-pool' deploy.yaml

在kubectl apply -f deploy.yaml的时候，ingress-nginx-controller-bd9c85589-2pvt9 一直在重启拉取不成功，如下图：

通过查看pod日志：

显示80和443端口被占用

[root@k8s-master ~]# kubectl logs ingress-nginx-controller-794b68c644-b9lfm -n ingress-nginx
-------------------------------------------------------------------------------
NGINX Ingress controller
  Release:       v1.10.1
  Build:         4fb5aac1dd3669daa3a14d9de3e3cdb371b4c518
  Repository:    https://github.com/kubernetes/ingress-nginx
  nginx version: nginx/1.25.3

-------------------------------------------------------------------------------

F0312 07:56:50.801445       6 main.go:64] port 443 is already in use. Please check the flag --https-port
[root@k8s-master ~]# kubectl logs ingress-nginx-controller-bd9c85589-59tm4 -n ingress-nginx
F0312 07:47:09.798016       7 main.go:64] port 80 is already in use. Please check the flag --http-port
-------------------------------------------------------------------------------
NGINX Ingress controller
  Release:       v1.10.1
  Build:         4fb5aac1dd3669daa3a14d9de3e3cdb371b4c518
  Repository:    https://github.com/kubernetes/ingress-nginx
  nginx version: nginx/1.25.3

-------------------------------------------------------------------------------

 但是通过netstat命令查看之后并没有80和443端口被占用的情况：

[root@k8s-master ~]# netstat -lntp | grep 80
tcp        0      0 127.0.0.1:8001          0.0.0.0:*               LISTEN      815833/kubectl      
tcp        0      0 192.168.9.128:2380      0.0.0.0:*               LISTEN      1826/etcd 

  [root@k8s-master ~]# sudo netstat -tuln | grep :443

  还有一种情况，在Kubernetes节点上，有其他Pod（可能来自之前的部署）占用了宿主机的443端口，但使用的是LoadBalancer服务类型，通常不会直接绑定节点端口，除非指定了externalIPs或特定配置。用户的服务配置中，ingress-nginx-controller服务的类型是LoadBalancer，通常这会分配一个外部IP，并映射端口。但443端口在LoadBalancer服务中映射到容器的443端口，这本身没有问题，除非在节点上有其他进程在使用443。

解决方法： 

修改Deployment配置：

# deploy.yaml中容器的args部分添加：
- --http-port=8080
- --https-port=844  # 避免与Webhook的8443端口冲突，改为8444

 更新Service配置：

两个service部分都修改

# 在Service的ports部分修改：
- appProtocol: http
  name: http
  port: 80
  protocol: TCP
  targetPort: 8080  # 指向控制器的HTTP端口8080
- appProtocol: https
  name: https
  port: 443
  protocol: TCP
  targetPort: 8444  # 指向控制器的HTTPS端口8444

重新启动配置：

[root@k8s-master ~]# kubectl delete  -f deploy.yaml 
[root@k8s-master ~]# kubectl apply -f deploy.yaml

检查pod状态：

[root@k8s-master ~]# kubectl get pods -n ingress-nginx -w
NAME                                        READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-4wkp5        0/1     Completed   0          8s
ingress-nginx-admission-patch-j946c         0/1     Completed   0          8s
ingress-nginx-controller-86f894bcd8-4rwnk   0/1     Running     0          8s
ingress-nginx-controller-86f894bcd8-4rwnk   1/1     Running     0          20s