k8a 对外服务（ingress）详解（定义，暴露，代理，重写，）

服务发现： Service允许其他应用在集群内发现并访问特定的Pod，即使Pod的IP地址会随着时间的变化而改变，Service提供了一个稳定的虚拟IP和DNS名称，使得其他应用能够持续地与服务通信。
负载均衡： 当一个Service代表多个Pod时，它可以在这些Pod之间进行负载均衡，确保请求被均匀地分发到各个Pod上，从而提高应用程序的可用性和性能。

在 Kubernetes 中，Pod 的 IP 地址和 Service 的 ClusterIP 只能在集群内部网络中访问。这意味着，对于集群外部的应用来说，这些地址是不可见的。

外部访问方案

NodePort：通过在每个节点上开放一个端口（NodePort），可以将service服务暴露给外部网络。Kube-Proxy 负责在服务网络、Pod 网络和节点网络之间进行通信。这种方式在测试环境中适用，但在生产环境中，当服务数量众多时，端口管理会变得复杂，因为每个端口只能对应一种服务，且端口范围有限（通常为 30000-32767）。
LoadBalancer：这种方式通过云服务提供商的负载均衡器（LoadBalancer）来暴露服务。这通常在公有云平台上使用，但受限于云平台的支持，并且可能需要额外的费用。
externalIPs：Service 可以被分配一个或多个外部 IP 地址。如果这些 IP 地址能够路由到集群中的一个或多个节点，那么服务就会通过这些 IP 地址暴露。流量通过这些外部 IP 进入集群后，会被路由到 Service 的 Endpoint。
Ingress：Ingress 提供了一种更为高效的方式，它允许使用一个或少量的公网 IP 地址和负载均衡器（LB）来同时暴露多个 HTTP 服务。Ingress 可以看作是 Service 的进一步抽象，它基于域名和 URL 路径来定义规则，将用户的请求转发到一个或多个 Service。

适用场景和限制

NodePort：
适用场景：在小型集群或测试环境中，NodePort 是一个简单且易于设置的选项。它允许直接通过节点的 IP 地址和特定端口访问服务。
限制：在生产环境中，由于端口范围有限（30000-32767），并且每个端口只能映射到一个服务，这可能导致端口资源耗尽和管理复杂性增加。
LoadBalancer：
适用场景：在云服务提供商（如 AWS、Azure、Google Cloud 等）的环境中，LoadBalancer 是最常使用的方案。它提供了自动的负载均衡和扩展能力，适合需要高可用性和可扩展性的生产环境。
成本：使用 LoadBalancer 可能会产生额外的费用，因为它通常涉及云服务提供商的负载均衡服务。
externalIPs：
适用场景：当集群部署在具有固定公网 IP 地址的环境中，或者需要直接使用外部 IP 地址时，externalIPs 是一个合适的选择。这在私有云或混合云部署中较为常见。
限制：需要确保外部 IP 地址能够正确路由到集群节点，并且可能需要额外的网络配置。
Ingress：
适用场景：Ingress 是最灵活的方案，它允许通过一个或少量的公网 IP 地址来暴露多个服务。这在需要管理大量服务的复杂应用场景中非常有用，尤其是在需要基于域名和路径进行细粒度流量控制时。
优势：Ingress 提供了更高级的功能，如 SSL/TLS 终端、HTTP 重写、负载均衡、虚拟主机等。它也支持更复杂的路由规则，如基于路径的路由和重定向。
在实际部署中，Ingress 由于其灵活性和高级功能，通常被认为是最常使用的方案，尤其是在生产环境中。它允许开发者和运维人员以声明式的方式管理入口流量，而无需关心底层的网络实现细节。此外，Ingress 控制器（如 nginx-ingress 或 traefik）的流行也促进了 Ingress 的广泛采用。

ingress如何实现对外服务

在Kubernetes中，LB（负载均衡器）和Ingress一起使用时，LB通常指的是负载均衡器服务，而Ingress是一种资源，用于定义应用程序的外部入口。LB通过将外部流量路由到Kubernetes集群内的Ingress Controller来实现对多个服务的管理。Ingress Controller会根据Ingress规则将请求路由到相应的服务，为应用提供统一的入口。这组合提供了高级别的路由和负载平衡功能，使得在Kubernetes环境中更灵活地管理服务的访问。

LB和Ingress结合起来实现对外服务的过程大致如下：

LB配置： 负载均衡器（Load Balancer）通过配置将外部流量引导到Kubernetes集群。这可能涉及到云服务商的负载均衡器设置或其他物理设备。
Ingress Controller部署： 在Kubernetes集群中部署Ingress Controller，它负责管理Ingress资源并根据其规则处理请求。
Ingress资源定义： Kubernetes用户通过创建Ingress资源定义外部访问规则，包括路径、主机等信息。这些规则描述了如何将外部请求路由到集群内的服务。
Ingress Controller监听： Ingress Controller会监听集群中的Ingress资源的变化，并根据定义的规则更新其配置。
请求路由： 当外部请求到达负载均衡器时，LB将请求转发到Ingress Controller。Ingress Controller根据Ingress规则将请求路由到相应的服务。
服务响应： 被选中的服务接收请求并提供相应的响应。这使得在Kubernetes环境中，可以更加灵活地管理多个服务的对外访问。

这整个过程的目标是实现集中化的入口管理，允许动态调整路由规则而无需修改底层服务。

ingress 概念

定义

Ingress 是 Kubernetes 中的一个 API 对象，它允许你定义一组规则，这些规则控制着外部访问你的集群内服务的方式。Ingress 可以被看作是集群的入口点，它提供了一种机制来管理外部访问到集群内部服务的 HTTP 和 HTTPS 流量。Ingress 规则基于域名和 URL 路径，将用户的请求转发到一个或多个后端服务。

Ingress并不直接处理或转发流量，它需要与Ingress Controller一起使用。Ingress Controller是一个实际处理流量的组件，它根据Ingress资源中定义的规则，将请求路由到正确的服务。这种组合使得在Kubernetes环境中能够方便地管理多个服务的访问入口。

组成

Ingress 资源对象：这是通过 YAML 文件配置的，它定义了请求如何转发到服务的规则。Ingress 对象可以包含多个规则，每个规则可以指定不同的域名、路径和后端服务。
Ingress 控制器（Ingress Controller）：这是一个运行在 Kubernetes 集群中的组件，它负责实现 Ingress 资源对象中定义的规则。Ingress 控制器通常是一个反向代理服务器，如 Nginx 或 Traefik，它根据 Ingress 规则来处理进入集群的流量。

一般，ingress-controller的形式都是一个pod，里面跑着daemon程序和反向代理程序。daemon负责不断监控集群的变化，根据 ingress对象生成配置并应用新配置到反向代理，比如ingress-nginx就是动态生成nginx配置，动态更新upstream，并在需要的时候reload程序应用新配置。为了方便，后面的例子都以k8s官方维护的ingress-nginx为例。

Ingress-Nginx github 地址：https://github.com/kubernetes/ingress-nginx

Ingress-Nginx 官方网站：https://kubernetes.github.io/ingress-nginx/

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

工作原理

Ingress 控制器通过与 Kubernetes API Server 交互，动态感知集群中 Ingress 规则的变化。
控制器读取这些规则，并根据自定义的规则生成相应的配置（例如 Nginx 配置），而规则就是写明了哪个域名对应哪个service。
控制器将这些配置应用到其运行的反向代理服务中，例如将配置写入 Nginx 的配置文件，并重新加载服务以使配置生效。也就是写到nginx-ingress-controller的pod里，这个ingress-controller的pod里运行着一个Nginx服务，控制器会把生成的 nginx配置写入 /etc/nginx.conf文件中。
reload后配置生效

总结

Ingress作为请求入口：
Ingress确实是Kubernetes集群的入口点，它允许外部流量进入集群内部。Ingress提供了一种机制，可以根据定义的规则将外部HTTP和HTTPS请求路由到集群内的多个服务。
Ingress资源对象与Ingress Controller：
Ingress资源对象定义了路由规则，包括URL路径、主机名、重定向、负载均衡等。
Ingress Controller是一个运行在集群中的组件，它负责实现Ingress资源对象中定义的规则。Ingress-Nginx是Kubernetes社区原生支持的一种Ingress Controller实现，它使用Nginx作为反向代理服务器。
Ingress Controller的选择：
根据具体的需求，可以选择不同的Ingress Controller。除了Ingress-Nginx，还有其他实现，如Traefik、HAProxy等。每种实现都有其特点和优势，选择合适的Ingress Controller可以提高集群的灵活性和性能。
Ingress的暴露方式：
Ingress可以通过多种方式暴露服务，包括NodePort、LoadBalancer、IngressClass等。
NodePort在集群节点上为服务提供一个静态端口，外部流量可以通过这个端口访问服务。
LoadBalancer通常用于云环境，它创建一个负载均衡器，为服务提供一个外部可访问的IP地址。
IngressClass提供了一种更灵活的方式来定义Ingress资源的行为，允许管理员定义不同的Ingress策略。

二、部署 nginx-ingress-controller

创建 ingress-controller pod及相关资源

创建目录：

mkdir /opt/ingress
cd /opt/ingress

下载配置文件

官方下载地址：
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.25.0/deploy/static/mandatory.yaml

由于官方下载地址可能无法下载，可以使用国内的Gitee镜像来下载所需的YAML配置文件。这里有两个版本的配置文件，一个是nginx-0.25.0，另一个是nginx-0.30.0。可以选择一个版本进行下载。

对于nginx-0.25.0版本：

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

对于nginx-0.30.0版本：

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

确保下载的是最新版本的配置文件，因为新版本可能包含了安全更新和功能改进。如果不确定哪个版本更适合你，可以查看官方文档或者社区讨论来决定。

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

修改集群角色(ClusterRole) 资源配置

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

这份 YAML 文件是对 Kubernetes 中的 ClusterRole 资源进行配置的，ClusterRole 用于定义对集群中资源的权限。下面是对该文件中各部分的详细解析：

apiVersion：指定 Kubernetes API 的版本，此处使用的是 rbac.authorization.k8s.io/v1beta1 版本，但注释中提到从 1.17 版本开始应改用 rbac.authorization.k8s.io/v1，而 v1beta1 版本将在 1.22 版本后弃用。
kind：指定资源的类型，这里是 ClusterRole，表示集群级别的角色。
metadata：指定资源的元数据，包括名称和标签等信息。
rules：定义了针对不同资源的访问规则。在这里，包含了多个规则，每个规则指定了对一类资源的访问权限。
第一个规则指定了对 ConfigMaps、Endpoints、Nodes、Pods 和 Secrets 等资源的 list 和 watch 权限。
第二个规则指定了对 Nodes 资源的 get 权限。
第三个规则指定了对 Services 资源的 get、list 和 watch 权限。
第四个规则指定了对 Ingress 资源的 get、list 和 watch 权限，其中包括了对 "extensions" 和 "networking.k8s.io" API 组的 Ingress 资源的权限。
第五个规则指定了对 Events 资源的 create 和 patch 权限。
最后一个规则指定了对 Ingress 资源状态的 update 权限，同样包括了 "extensions" 和 "networking.k8s.io" API 组的 Ingress 资源。

这些规则定义了该 ClusterRole 在集群中对各种资源的访问权限，以及允许的操作。这样配置的 ClusterRole 可以被绑定到用户、服务账户或者其他身份上，以控制它们对集群资源的访问权限。

暴露ingress服务

暴露的三种方式

方式一：Deployment+LoadBalancer 模式的 Service
这种方式适用于在公有云环境中部署 Ingress。首先使用 Deployment 来部署 ingress-controller。
然后创建一个 type 为 LoadBalancer 的 Service，这个 Service 会与 ingress-controller 的 Pod 关联。
大多数公有云服务提供商会为 LoadBalancer 类型的 Service 自动创建一个负载均衡器，并分配一个公网 IP 地址。
只需要将域名解析到这个公网 IP 地址，就可以实现服务的外部访问。
方式二：DaemonSet+HostNetwork+nodeSelector
使用 DaemonSet 部署 ingress-controller，这样可以确保在每个节点上都运行一个 ingress-controller 的 Pod。
通过设置 hostNetwork: true，使得 Pod 直接使用宿主机的网络命名空间，这样 Pod 就可以直接使用宿主机的 IP 地址和端口。
使用 nodeSelector 可以选择特定的节点来部署 ingress-controller。
这种方式下，Ingress 控制器所在的节点就像传统的边缘节点，例如机房入口的 Nginx 服务器。
这种方式的优点是请求链路简单，性能较好。但缺点是每个节点只能部署一个 ingress-controller Pod，因为它们直接使用了宿主机的网络和端口。
方式三：Deployment+NodePort模式的 Service
同样使用 Deployment 来部署 ingress-controller。
创建一个 type 为 NodePort 的 Service，这样 Ingress 会暴露在集群节点的 IP 地址上的一个特定端口。
NodePort 模式会为每个节点分配一个随机端口，通常你会在前面设置一个负载均衡器来转发请求到这些端口。
这种方式适用于宿主机 IP 地址相对固定且不会变化的场景。
虽然 NodePort 方式简单方便，但由于多了一层网络地址转换（NAT），在高并发情况下可能会对性能产生影响。

三、采用DaemonSet+HostNetwork+nodeSelector暴露服务

先指定控制器运行在node02节点上

为节点添加标签

kubectl label node node02 ingress=true

查看节点标签

kubectl get nodes --show-labels

这个命令会列出所有节点及其标签。可以在输出中查找 node02 节点，确认 ingress=true 标签已经被成功添加。

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

4、修改 Deployment 为 DaemonSet ，指定节点运行，并开启 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
......

要将 nginx-ingress-controller 的部署方式从 Deployment 修改为 DaemonSet，并且指定它在具有特定标签的节点上运行，同时开启 hostNetwork 模式，你需要对 mandatory.yaml 文件进行以下修改：

修改 kind 为 DaemonSet：将 kind: Deployment 更改为 kind: DaemonSet。
删除 replicas 字段： DaemonSet 不需要 replicas 字段，因为它会确保 Pod 在每个选定的节点上运行一个实例。
添加 hostNetwork: true：在 spec.template.spec 下添加 hostNetwork: true，这将使 Pod 使用宿主机的网络命名空间。
添加 nodeSelector：在 spec.template.spec 下添加 nodeSelector 字段，并设置 ingress: "true"，以便 Pod 只在带有 ingress=true 标签的节点上运行。

在所有 node 节点上传 nginx-ingress-controller 镜像压缩包 ingree.contro.tar.gz 到 /opt/ingress 目录，并解压和加载镜像

上传镜像压缩包：首先，需要将 ingree.contro.tar.gz 文件上传到所有节点的 /opt/ingress 目录。这可以通过 SSH 或其他文件传输方法完成。如果你有多个节点，你可以使用如 scp 或 rsync 这样的工具来批量传输文件。
解压镜像压缩包：通过 SSH 登录到每个节点，然后导航到 /opt/ingress 目录并解压镜像文件。

cd /opt/ingress
tar zxvf ingree.contro.tar.gz

加载 Docker 镜像：解压后，可以使用 docker load 命令来加载镜像。确保已经切换到了包含解压后的 Docker 镜像文件的目录。然后执行：

docker load -i ingree.contro.tar

这个命令会将镜像文件加载到 Docker 的镜像列表中。加载完成后，可以使用 docker images 命令来验证镜像是否已经被成功加载。

请注意，如果你的 Kubernetes 集群使用的是 Containerd 或其他容器运行时，而不是 Docker，那么加载镜像的命令可能会有所不同。在这种情况下，可能需要使用相应的工具来导入镜像。

启动 nginx-ingress-controller

nginx-ingress-controller 已经在 node02 节点上成功运行，并且配置了 hostNetwork，这意味着 nginx 直接在宿主机上监听了 80、443 和 8181 端口。这样，任何对这些端口的请求都会被转发到 nginx-ingress-controller。

现在，为了确保 nginx-ingress-controller 能够正常工作并对外提供服务，需要执行以下步骤：

验证 Pod 状态

确保 nginx-ingress-controller Pod 的状态是 Running，并且 READY 列显示为 1/1，这表示 Pod 已经准备好接收流量。

kubectl get pod -n ingress-nginx -o wide

检查 ConfigMaps 和 DaemonSet：

确保所有相关的 ConfigMaps 和 DaemonSet 都已经创建，并且状态正常。

kubectl get cm,daemonset -n ingress-nginx -o wide

在node02节点检查

检查网络监听：

在 node02 节点上运行 netstat 命令来验证 nginx 是否在预期的端口上监听。 netstat 的输出，显示了 nginx 在 80、443 和 8181 端口上的监听。

netstat -lntp | grep nginx

其中 8181 是 nginx-controller 默认配置的一个 default backend（Ingress 资源没有匹配的 rule 对象时，流量就会被导向这个 default backend）。

这样，只要访问 node 主机有公网 IP，就可以直接映射域名来对外网暴露服务了。如果要 nginx 高可用的话，可以在多个 node上部署，并在前面再搭建一套 LVS+keepalived 做负载均衡。

创建 ingress 规则

创建一个deploy的业务pod和svc

vim service-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
spec:
  replicas: 2
  selector:
    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
    port: 80
    targetPort: 80
  selector:
    app: nginx

在应用这个配置文件之前，请确保已经有一个名为 ingress-nginx 的命名空间，因为 Ingress 控制器通常在这个命名空间中运行。如果还没有这个命名空间，可以创建它：

kubectl create namespace ingress-nginx

然后，应用 service-nginx.yaml 文件来创建 Deployment 和 Service：

kubectl apply -f service-nginx.yaml -n ingress-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.test.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.test.com
    http:
      paths:
      - path: /
        pathType: Prefix     
        backend:
          service:
            name: nginx-app-svc
            port:
              number: 80

现在，已经准备好应用 Ingress 规则。在应用 Ingress 规则之前，请确保域名 www.test.com 已经正确解析到了运行 nginx-ingress-controller 的节点的公网 IP 地址。如果域名解析还没有设置好，Ingress 规则将无法正常工作，因为外部请求无法正确路由到你的服务。

接下来，可以应用 Ingress 规则：

kubectl apply -f ingress-app.yaml -n ingress-nginx

这将创建一个名为 nginx-app-ingress 的 Ingress 资源，它将所有到 www.test.com 的 HTTP 请求路由到 nginx-app-svc 服务的 80 端口。

应用 Ingress 规则后，可以检查 Ingress 资源的状态：

kubectl get ingress -n ingress-nginx

应该会看到 nginx-app-ingress 已经创建，并且有一个与 www.test.com 关联的地址和端口。

最后，可以检查 Pod 的状态，确保 nginx-app 的 Pod 正在运行：

kubectl get pods -n ingress-nginx

如果一切正常，应该看到 nginx-app 的 Pod 状态为 Running，并且 READY 列显示为 1/1。

现在，当访问 www.test.com 时，请求应该会被 nginx-ingress-controller 接收，并转发到 nginx-app-svc 服务。因为 nginx-ingress-controller 配置了 hostNetwork，那么它将直接在节点的 80 端口上监听，并将流量转发到相应的服务。如果遇到问题，可以查看 nginx-ingress-controller 的日志来帮助诊断问题。

测试访问

添加host域名解析

vim /etc/hosts
192.168.41.31 master
192.168.41.33 node01
192.168.41.34 node02
192.168.41.34 www.test.com

curl www.test.com

查看controller的pod状态，并在pod内部查看ingress规则是否被正确配置

查看 `nginx-ingress-controller` Pod 状态：

kubectl get pod -n ingress-nginx -o wide

这个命令显示了 nginx-ingress-controller Pod 的详细信息，包括它的 IP 地址、所在的节点等。

进入 `nginx-ingress-controller` Pod 的 Bash shell：

kubectl exec -it nginx-ingress-controller-99h72 -n ingress-nginx /bin/bash

这个命令允许以交互模式进入 Pod 的内部。

查看 Nginx 配置文件：

# more /etc/nginx/nginx.conf

在 Pod 的 Bash shell 中，可以使用 more 或 cat 命令来查看 Nginx 的配置文件。你应该能够看到 www.test.com 的配置，这表明 Ingress 规则已经被正确地应用到了 Nginx 的配置中。

如果看到了 www.test.com 的配置，这意味着 nginx-ingress-controller 已经根据你创建的 Ingress 规则更新了 Nginx 的配置。现在，当外部请求到达 node02 节点的 80 端口时，它们将被正确地路由到 nginx-app-svc 服务。

如果需要查看更详细的 Nginx 配置，或者需要调试 Ingress 规则，可以查看 nginx-ingress-controller Pod 的日志：

kubectl logs nginx-ingress-controller-99h72 -n ingress-nginx

这将显示 Pod 的日志输出，其中可能包含有关 Ingress 规则处理的详细信息。

四、采用Deployment+NodePort模式的Service暴露服务

创建目录并下载配置文件：

创建一个新的目录 /opt/ingress-nodeport，然后下载 nginx-ingress-controller 的配置文件和 NodePort 服务的配置文件。

mkdir /opt/ingress-nodeport
cd /opt/ingress-nodeport

官方下载地址：
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml

国内 gitee 资源地址：
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml

所有节点上传并加载 Docker 镜像：

将 ingress-controller-0.30.0.tar 镜像包上传到所有节点的 /opt/ingress-nodeport 目录，并使用 docker load 命令加载镜像。

# 假设你已经有了 ingress-controller-0.30.0.tar 文件
# 将文件上传到所有节点的 /opt/ingress-nodeport 目录
# 然后加载镜像
docker load -i ingress-controller-0.30.0.tar

启动 `nginx-ingress-controller`

使用 kubectl apply 命令应用 mandatory.yaml 和 service-nodeport.yaml 配置文件来启动 nginx-ingress-controller。

kubectl apply -f mandatory.yaml
kubectl apply -f service-nodeport.yaml

这将创建 nginx-ingress-controller 的 Deployment 和相关的 RBAC 配置，以及一个 NodePort 类型的 Service，该 Service 将暴露 80 和 443 端口，允许外部流量通过这些端口访问 Ingress 控制器。

如果 Kubernetes Pod 调度失败，并且 kubectl describe pod 命令的输出显示了 "0/2 nodes are available: 2 node(s) didn't match node selector" 的警告时，这意味着 Pod 的调度请求无法找到符合其节点选择器（nodeSelector）的节点。这通常发生在 Pod 定义中指定了特定的节点选择器，但是集群中没有节点带有相应的标签。

要解决这个问题，有两个选择：

给需要调度的节点添加标签：如果 Pod 需要在特定的节点上运行，需要确保这些节点有正确的标签。可以使用 kubectl label nodes 命令来给节点添加标签。例如，如果 Pod 需要在操作系统为 Linux 的节点上运行

kubectl label nodes <node_name> kubernetes.io/os=linux

将 <node_name> 替换为实际的节点名称。

删除或修改 Pod 定义中的节点选择器：如果 Pod 不需要在特定的节点上运行，可以从 Pod 的定义中删除节点选择器。这通常在 Pod 的 YAML 文件中进行。例如，如果你的 Pod 定义如下：

spec:
  nodeSelector:
    kubernetes.io/os: linux

可以删除 nodeSelector 字段，或者将其设置为一个空对象：

spec:
  nodeSelector: {}

然后重新应用 Pod 的 YAML 文件：

kubectl apply -f <pod_definition.yaml>

请确保在修改 Pod 定义后重新应用配置，以便更改生效。

查看状态

kubectl get pod,svc -n ingress-nginx

从输出来看，nginx-ingress-controller Pod 正在 ingress-nginx 命名空间中正常运行，状态为 Running。同时，ingress-nginx 服务是 NodePort 类型，这意味着它在集群的每个节点上都开放了特定的端口（80 端口映射到 32383 端口，443 端口映射到 32133 端口）以供外部访问。

五、 Ingress HTTP 代理访问

环境准备：

进入Kubernetes集群中的Ingress相关的目录：/opt/ingress-nodeport。

cd /opt/ingress-nodeport

创建资源：

使用vim编辑器创建一个名为ingress-nginx.yaml的YAML文件，该文件包含以下资源的定义：
- Deployment：名为nginx-app，包含两个Nginx容器副本，监听容器端口80。
- Service：名为nginx-svc，类型为ClusterIP，端口80，选择器为name=nginx。
- Ingress：名为nginx-test，配置了一个规则，将访问www.gzb.com域名的流量转发到nginx-svc服务的端口80。

vim ingress-nginx.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
spec:
  replicas: 2
  selector:
    matchLabels:
      name: nginx
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    name: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-test
spec:
  rules:
  - host: www.gzb.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service: 
            name: nginx-svc
            port:
              number: 80

应用配置：

使用kubectl apply -f ingress-nginx.yaml命令应用上述YAML文件中的配置。

kubectl apply -f ingress-nginx.yaml

验证部署：

使用kubectl get svc,pods -o wide命令查看服务和Pod的状态。输出显示nginx-svc服务已创建，但没有外部IP，两个Nginx Pod正在运行。

kubectl get svc,pods -o wide

为了使外部流量能够访问到这个服务，需要确保：

Ingress Controller已正确安装并运行。
域名www.gzb.com已正确解析到Ingress Controller的外部IP地址。
如果在云服务提供商上部署，可能需要配置负载均衡器或网络策略。

测试服务

进入Pod并修改HTML文件：

使用kubectl exec命令进入名为nginx-app-65d7b99f6b-l4g65的Pod，并在/usr/share/nginx/html/目录下创建或修改index.html文件，添加内容this is web1

kubectl exec -it pod/nginx-app-65d7b99f6b-l4g65 bash
 # cd /usr/share/nginx/html/
 # echo 'this is web1' >> index.html

对另一个名为nginx-app-65d7b99f6b-zcqgp的Pod执行相同的操作，添加内容this is web2。

kubectl exec -it pod/nginx-app-65d7b99f6b-zcqgp bash
 # cd /usr/share/nginx/html/
 # echo 'this is web2' >> index.html

获取Service信息：

使用kubectl get svc -n ingress-nginx命令获取名为ingress-nginx的Service信息。该Service配置了NodePort类型，监听端口80和443，并且有对应的NodePort（例如，80端口对应的NodePort为32383）。

kubectl get svc -n ingress-nginx

添加本地域名解析：

vim /etc/hosts
192.168.41.31 master
192.168.41.33 node01
192.168.41.34 node02
192.168.41.34 www.test.com www.gzb.com

外部访问测试：

使用curl命令尝试通过外部域名www.gzb.com和NodePort32383访问服务。

curl http://www.gzb.com:32383

六、 Ingress HTTP 代理访问虚拟主机

前期准备

mkdir /opt/ingress-nodeport/vhost
cd /opt/ingress-nodeport/vhost

创建目录：
使用mkdir命令创建一个新的目录/opt/ingress-nodeport/vhost。这个目录用于存放虚拟主机的配置文件，如SSL证书、密钥、以及其他与虚拟主机相关的文件。
切换目录：
使用cd命令切换到新创建的vhost目录。这通常是为了在该目录下进行后续的操作，比如编辑配置文件或者添加其他必要的文件。
这些步骤是配置Ingress资源的前期准备工作。

创建虚拟主机1的资源

在Kubernetes集群中创建一个名为deployment1的Deployment和一个名为svc-1的Service。

创建Deployment资源：

vim deployment1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment1
spec:
  replicas: 2
  selector:
    matchLabels:
      name: nginx1
  template:
    metadata:
      labels:
        name: nginx1
    spec:
      containers:
        - name: nginx1
          image: soscscs/myapp:v1
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: svc-1
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    name: nginx1


kubectl apply -f deployment1.yaml

在该文件中定义了一个Deployment，名为deployment1，它包含两个Nginx容器的副本，这些容器使用标签name: nginx1进行选择。
容器使用的镜像是soscscs/myapp:v1，并且监听容器端口80。

创建Service资源：

在同一个YAML文件中定义了一个Service，名为svc-1。
该Service配置了一个端口80，用于将外部流量转发到选择器name: nginx1匹配的Pod的80端口。
Service类型默认为ClusterIP，这意味着它只能在集群内部访问。

应用配置：

使用kubectl apply -f deployment1.yaml命令将这些配置应用到Kubernetes集群中。
这些资源的创建将允许在集群内部通过svc-1服务访问名为nginx1的Deployment中的Nginx容器。

创建虚拟主机2的资源

在Kubernetes集群中创建第二个虚拟主机资源，包括一个名为deployment2的Deployment和一个名为svc-2的Service

创建Deployment资源：

vim deployment2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment2
spec:
  replicas: 2
  selector:
    matchLabels:
      name: nginx2
  template:
    metadata:
      labels:
        name: nginx2
    spec:
      containers:
        - name: nginx2
          image: soscscs/myapp:v2
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: svc-2
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    name: nginx2


kubectl apply -f deployment2.yaml

在该文件中定义了一个Deployment，名为deployment2，它包含两个Nginx容器的副本，这些容器使用标签name: nginx2进行选择。
容器使用的镜像是soscscs/myapp:v2，并且监听容器端口80。

创建Service资源：

在同一个YAML文件中定义了一个Service，名为svc-2。
该Service配置了一个端口80，用于将外部流量转发到选择器name: nginx2匹配的Pod的80端口。
Service类型默认为ClusterIP，这意味着它只能在集群内部访问。

应用配置：

使用kubectl apply -f deployment2.yaml命令将这些配置应用到Kubernetes集群中。

这些资源的创建将允许在集群内部通过svc-2服务访问名为nginx2的Deployment中的Nginx容器。与之前创建的deployment1和svc-1类似，deployment2和svc-2也是内部服务，需要通过Ingress资源来实现外部访问。

创建ingress资源

vim ingress-nginx.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress1
spec:
  rules:
    - host: www1.gzb.com
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service: 
              name: svc-1
              port:
                number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress2
spec:
  rules:
    - host: www2.gzb.com
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service: 
              name: svc-2
              port:
                number: 80


kubectl apply -f ingress-nginx.yaml

创建Ingress资源：

在该文件中定义了两个Ingress资源，ingress1和ingress2。
ingress1配置了一个规则，当访问www1.gzb.com时，流量将被路由到名为svc-1的服务的端口80。
ingress2配置了一个规则，当访问www2.gzb.com时，流量将被路由到名为svc-2的服务的端口80。

应用：

使用kubectl apply -f ingress-nginx.yaml命令将这些Ingress配置应用到Kubernetes集群中。

这些配置已经在集群中安装并配置了Ingress Controller，例如Nginx Ingress Controller。Ingress Controller将根据这些规则处理进入集群的HTTP流量，并将请求根据主机名转发到相应的后端服务。

测试访问

成功通过Ingress资源配置了两个虚拟主机后，在集群内部通过curl命令测试了它们的访问。

获取Ingress Controller的Service信息

使用kubectl get svc -n ingress-nginx命令查看Ingress Controller的Service信息。会看到了ingress-nginx服务，它是一个NodePort类型的服务，没有外部IP地址，但有一个内部的ClusterIP，并且配置了两个端口：80和443，分别映射到NodePort的32383和32133。

kubectl get svc -n ingress-nginx

测试虚拟主机访问：

使用curl命令尝试从集群内部访问两个不同的虚拟主机www1.gzb.com和www2.gzb.com。由于在集群内部执行这些命令，您可以直接使用NodePort（32383）来访问这些服务。
会收到了两个不同的响应，每个响应都显示了相应的应用版本（v1和v2），这表明Ingress规则正确地将请求路由到了对应的后端服务。

curl www1.gzb.com:32383
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

curl www2.gzb.com:32383
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

七、 Ingress HTTPS 代理访问

在Kubernetes集群中配置HTTPS代理访问通常涉及以下步骤：

获取或生成SSL/TLS证书和私钥。
将证书和私钥文件放置在集群节点可以访问的位置，例如您刚刚创建的https目录。
创建Ingress资源的YAML配置文件，指定SSL/TLS证书和私钥的位置，以及需要启用HTTPS的虚拟主机规则。

一旦这些步骤完成，就可以使用kubectl apply命令应用Ingress配置，从而启用HTTPS代理访问。这将允许外部用户通过安全的HTTPS连接访问您的服务。

环境准备

创建HTTPS配置目录：

使用mkdir命令在/opt/ingress-nodeport路径下创建一个新的目录，命名为https。这个目录将用于存放与HTTPS相关的配置文件，如SSL/TLS证书和密钥。

mkdir /opt/ingress-nodeport/https

切换到HTTPS配置目录：

使用cd命令切换到新创建的https目录。这通常是为了在该目录下进行后续的操作，比如添加SSL/TLS证书和密钥文件，或者创建Ingress资源的YAML配置文件。

cd /opt/ingress-nodeport/https

创建SSL证书：

使用openssl req命令创建一个新的自签名SSL证书（tls.crt）和私钥（tls.key）。
证书的主题（-subj）被设置为/CN=nginxsvc/O=nginxsvc，这通常代表证书的通用名称（Common Name）和组织名称（Organization）。
证书有效期设置为365天，使用2048位的RSA密钥。

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc"

创建Secret资源：

使用kubectl create secret tls命令创建一个新的Kubernetes Secret资源，名为tls-secret。
该Secret资源包含您之前创建的tls.key（私钥）和tls.crt（证书）文件。

kubectl create secret tls tls-secret --key tls.key --cert tls.crt

获取Secret资源信息：

使用kubectl get secret命令查看当前命名空间（默认为default）中的Secret资源列表。
可以看到了名为tls-secret的Secret资源，它包含TLS类型的数据。

kubectl get secret

查看Secret资源：

使用kubectl describe secret tls-secret命令获取tls-secret的详细信息。
可以看到了Secret资源的类型为kubernetes.io/tls，并且包含了证书和私钥的数据。

kubectl describe secret tls-secret

现在，可以在创建Ingress资源时引用这个Secret，以便为Ingress Controller配置HTTPS支持。这将允许Ingress Controller使用这个SSL证书来终止外部HTTPS请求。

创建 deployment、Service、Ingress Yaml 资源

创建YAML配置文件：

在该文件中定义一个Deployment（nginx-app），它包含两个Nginx容器的副本。
定义一个Service（nginx-svc），它将端口80的流量转发到标签为name: nginx的Pod。
定义一个Ingress资源（nginx-https），它配置了HTTPS支持，使用之前创建的tls-secret证书和私钥。
Ingress资源中定义了一个规则，当访问www3.gzb.com时，流量将被路由到nginx-svc服务的端口80。

vim ingress-https.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
spec:
  replicas: 2
  selector:
    matchLabels:
      name: nginx
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    name: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-https
spec:
  tls:
    - hosts:
      - www3.gzb.com
      secretName: tls-secret
  rules:
    - host: www3.gzb.com
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service: 
              name: nginx-svc
              port:
                number: 80


kubectl apply -f ingress-https.yaml

应用配置：

使用kubectl apply -f ingress-https.yaml命令将这些配置应用到Kubernetes集群中。

查看Service信息：

使用kubectl get svc -n ingress-nginx命令获取Ingress Controller的Service信息。会看到了ingress-nginx服务，它是一个NodePort类型的服务，监听端口80和443，但没有外部IP地址。

kubectl get svc -n ingress-nginx

现在，已经为www3.gzb.com配置了HTTPS代理访问。

访问测试

使用本地的hosts文件来解析域名www3.gzb.com到一个特定的IP地址

编辑本地`hosts`文件：

在Windows系统的C:\Windows\System32\drivers\etc\目录下，编辑hosts文件。
添加一行记录，将IP地址192.168.41.36映射到域名www3.gzb.com。这样，当计算机尝试访问www3.gzb.com时，它将被解析到192.168.41.36。

访问HTTPS服务：

使用谷歌浏览器（或其他浏览器）访问https://www3.gzb.com:32133。这里，32133是Ingress Controller的NodePort端口号，用于HTTPS流量。

请注意，由于使用的是NodePort而不是外部IP地址，这种访问方式通常只适用于集群内部或者在知道NodePort端口号的情况下。对于外部用户，他们需要通过域名解析到Ingress Controller的外部IP地址，并且Ingress Controller需要配置为使用您创建的TLS证书来处理HTTPS请求。

八、 Nginx 进行 HTTP身份验证（BasicAuth）

在Kubernetes集群中配置Nginx Ingress Controller以实现基本的HTTP身份验证（BasicAuth）

环境准备

创建基本认证目录：

使用mkdir命令创建一个新的目录/opt/ingress-nodeport/basic-auth。
使用cd命令切换到该目录。

mkdir /opt/ingress-nodeport/basic-auth
cd　/opt/ingress-nodeport/basic-auth

生成用户密码认证文件：

使用yum -y install httpd命令安装httpd软件包，这是为了使用htpasswd工具。
使用htpasswd -c auth zhangsan命令创建一个名为auth的用户认证文件，其中zhangsan是用户名。这将提示您输入密码。

yum -y install httpd
htpasswd -c auth zhangsan            #认证文件名必须为 auth

创建Secret资源：

使用kubectl create secret generic basic-auth --from-file=auth命令创建一个新的Kubernetes Secret资源，名为basic-auth，并将之前生成的auth文件作为数据。

kubectl create secret generic basic-auth --from-file=auth

创建Ingress资源：

使用vim编辑器创建一个名为ingress-auth.yaml的YAML文件。
在该文件中定义了一个Ingress资源，名为ingress-auth，它包含了基本认证的配置。
使用注解设置了认证类型（basic）、认证使用的Secret资源名称（basic-auth）以及认证窗口提示信息。
定义了一个规则，当访问auth.gzb.com时，流量将被路由到nginx-svc服务的端口80。

vim ingress-auth.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-auth
  annotations:
    #设置认证类型basic
    nginx.ingress.kubernetes.io/auth-type: basic
    #设置secret资源名称basic-auth
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
    #设置认证窗口提示信息
    nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - zhangsan'
spec:
  rules:
  - host: auth.gzb.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service: 
            name: nginx-svc
            port:
              number: 80

具体详细设置方法可参考官网 https://kubernetes.github.io/ingress-nginx/examples/auth/basic/

应用Ingress配置：

使用kubectl apply -f ingress-auth.yaml命令将Ingress配置应用到Kubernetes集群中。

kubectl apply -f ingress-auth.yaml

完成这些步骤后，当用户尝试访问auth.gzb.com时，他们将被提示输入用户名和密码。只有输入正确的凭据后，才能访问该域名下的服务。

访问测试

获取Ingress Controller的Service信息：

使用kubectl get svc -n ingress-nginx命令查看Ingress Controller的Service信息。可以看到了ingress-nginx服务，它是一个NodePort类型的服务，监听端口80和443，没有外部IP地址。

kubectl get svc -n ingress-nginx

修改本地`hosts`文件：

将一行记录添加到/etc/hosts文件中，将IP地址192.168.41.36映射到域名auth.gzb.com。这样，当您的计算机尝试访问auth.gzb.com时，它将被解析到192.168.41.36。

echo '192.168.41.36 auth.gzb.com' >> /etc/hosts

浏览器访问：

使用浏览器尝试访问http://auth.gzb.com:32383。这里，32383是Ingress Controller的NodePort端口号。

浏览器访问：http://auth.gzb.com:32383

九、配置nginx实现URL重写

在Kubernetes集群中配置Nginx Ingress Controller以实现URL重写。

Nginx Ingress Controller的注解配置说明

这些注解用于定制Ingress的行为。以下是每个注解的详细说明：

nginx.ingress.kubernetes.io/rewrite-target：
这个注解用于指定重定向流量的目标URI。当希望请求被重写到不同的路径或主机时使用。例如，如果有一个旧的URL路径需要更新，可以使用这个注解来自动重定向用户到新的路径。
nginx.ingress.kubernetes.io/ssl-redirect：
这个注解是一个布尔值，用于指示是否仅通过SSL（HTTPS）重定向到Ingress。当Ingress包含证书时，默认值为true。这意味着，如果启用了SSL，所有HTTP请求都会被重定向到HTTPS。
nginx.ingress.kubernetes.io/force-ssl-redirect：
这也是一个布尔值，用于强制所有流量通过HTTPS，即使Ingress没有配置TLS证书。这可以用于确保所有流量都是安全的，即使在某些情况下可能还没有准备好SSL证书。
nginx.ingress.kubernetes.io/app-root：
这个注解定义了Ingress Controller必须重定向的应用程序根。如果应用程序的根路径不是'/'，可以使用这个注解来指定正确的根路径。
nginx.ingress.kubernetes.io/use-regex：
这个注解也是一个布尔值，用于指示Ingress上定义的路径是否使用正则表达式。如果设置为true，路径匹配将使用正则表达式，这允许更复杂的匹配逻辑，例如捕获路径中的特定部分。

这些注解提供了对Ingress Controller行为的细粒度控制，使得可以根据具体的应用需求来配置Ingress资源。在创建Ingress资源的YAML文件时，可以在metadata.annotations部分添加这些注解来实现所需的功能。

创建重写Ingress资源：

使用vim编辑器创建一个名为ingress-rewrite.yaml的YAML文件。
在该文件中定义了一个Ingress资源，名为nginx-rewrite，它包含了URL重写的注解配置。
注解nginx.ingress.kubernetes.io/rewrite-target设置为http://www1.gzb.com:32383，这意味着所有发送到re.gzb.com的流量都将被重定向到这个目标URI。

vim ingress-rewrite.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-rewrite
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: http://www1.gzb.com:32383
spec:
  rules:
  - host: re.gzb.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          #由于re.gzb.com只是用于跳转不需要真实站点存在，因此svc资源名称可随意定义
          service: 
            name: nginx-svc
            port:
              number: 80

应用Ingress配置：

使用kubectl apply -f ingress-rewrite.yaml命令将Ingress配置应用到Kubernetes集群中。

kubectl apply -f ingress-rewrite.yaml

修改本地`hosts`文件：

将一行记录添加到/etc/hosts文件中，将IP地址192.168.41.36映射到域名re.gzb.com。

echo '192.168.41.36 re.gzb.com' >> /etc/hosts

浏览器访问：

使用浏览器尝试访问http://re.gzb.com:32383。这里，32383是Ingress Controller的NodePort端口号。

浏览器访问：http://re.gzb.com:32383

木合杉

关注

21
点赞
踩
24

收藏

觉得还不错? 一键收藏
0
评论
k8a 对外服务（ingress）详解（定义，暴露，代理，重写，）

Ingress 是 Kubernetes 中的一个 API 对象，它允许你定义一组规则，这些规则控制着外部访问你的集群内服务的方式。Ingress 可以被看作是集群的入口点，它提供了一种机制来管理外部访问到集群内部服务的 HTTP 和 HTTPS 流量。Ingress 规则基于域名和 URL 路径，将用户的请求转发到一个或多个后端服务。Ingress并不直接处理或转发流量，它需要与Ingress Controller一起使用。
复制链接

扫一扫