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

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

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

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

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

「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 资源的理论执行者，负责依据定义的路由规定配置网络代理。

在 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 是一个高性能的 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-nginx
helm repo update

kubectl create namespace ingress-nginx

helm install ingress-nginx ingress-nginx/ingress-nginx \
--namespace ingress-nginx \
--set controller.publishService.enabled=true

kubectl get pods -n ingress-nginx
kubectl 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.yaml
mv 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-nginx
NAME                                        READY   STATUS      RESTARTS      AGE
ingress-nginx-admission-create-z4hlb        0/1     Completed   0             47h
ingress-nginx-admission-patch-ffbwz         0/1     Completed   0             47h
ingress-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-nginx
NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.106.241.48   <pending>     80:30806/TCP,443:30178/TCP   2d
ingress-nginx-controller-admission   ClusterIP      10.109.39.65    <none>        443/TCP                      2d
tantianran@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 中。

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

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: test-goweb
  name: test-goweb
spec:
  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: v1
kind: Service
metadata:
  labels:
    app: test-goweb
  name: test-goweb
spec:
  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 svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   120d
test-goweb   ClusterIP   10.105.248.32   <none>        80/TCP    81m # 这个等会是要用到的，Service 名称为 test-goweb，端口为 80
tantianran@test-b-k8s-master:~$

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

tantianran@test-b-k8s-master:~$ kubectl get ingressclass
NAME    CONTROLLER             PARAMETERS   AGE
nginx   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/v1
kind: Ingress
metadata:
  name: test-goweb
spec:
  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 ingress
NAME         CLASS   HOSTS                   ADDRESS         PORTS   AGE
test-goweb   nginx   test.noblameops.local   10.105.254.90   80      9m32s
tantianran@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 秒前。

当应用 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-nginx
NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.106.241.48   <pending>     80:30806/TCP,443:30178/TCP   2d6h
ingress-nginx-controller-admission   ClusterIP      10.109.39.65    <none>        443/TCP                      2d6h
tantianran@test-b-k8s-master:~$

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

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

apiVersion: v1
kind: Service
metadata:
  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-nginx
spec:
  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.yaml
kubectl create -f ingress-nginx-controller.yaml

tantianran@test-b-k8s-master:~$ kubectl get svc -n ingress-nginx
NAME                                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-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                      9s

tantianran@test-b-k8s-master:~$ kubectl get pod -n ingress-nginx -o wide
NAME                                        READY   STATUS      RESTARTS   AGE   IP              NODE                NOMINATED NODE   READINESS GATES
ingress-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

上面应用 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 cfssl
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo

chmod +x cfssl cfssljson cfssl-certinfo
mv 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.pem
kubectl get secret

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

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-goweb
spec:
  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

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

Ingress 的呈现

Ingress 和 Ingress Controller

支流的 Ingress Controller

控制器的部署计划

装置 Nginx Ingress

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

Ingress Controller 的裸露形式

Https 配置

Just My Socks（注册教程内含优惠码）

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

Ingress 的呈现

Ingress 和 Ingress Controller

支流的 Ingress Controller

控制器的部署计划

装置 Nginx Ingress

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

Ingress Controller 的裸露形式

Https 配置

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）