6.k8s-service

一、定义

Service的概念

kubernetes service定义了这样一种抽象： 一个pod的逻辑分组， 一种可以访问它们的策略--通常称为微服务。 这一组pod能够被service访问到， 通常是通过Label Selector

image-20210103112941385

Service 能够提供负载均衡的能力， 但是在使用上有以下限制：

  • 只提供4层负载均衡能力， 而没有7层功能呢， 但有时我们可能需要更多的匹配规则来转发请求， 这点上4层负载均衡是不支持的

二、代理模式分类

Service的类型

service在k8s中有以下四种类型

  • Clusterlp：默认类型， 自动分配一个仅Cluster内部访问的虚拟Ip

  • NodePort： 在ClusterIP基础上为Service在每台机器上绑定一个端口， 这样就可以通过:NodePort来访问该服务

  • LoadBalancer: 在NodePort的基础上， 借助cloud provider创建一个外部负载均衡， 并将请求转发到:NodePort （这里需要引入云供应商的负载均衡）

  • ExternalName: 把集群外部的服务引入到集群内部来， 在集群内部直接使用。 没有任何类型代理被创建，这只有kubernetes1.7或更高版本的kube-dns才支持

    image-20210103114309922

流程： client访问到节点是通过iptables 转发的，iptables 规则是通过kube-proxy写入的 ，apiserver通过监控kube-proxy进行服务和端点信息的发现 ，kube-proxy会通过标签去判断端点是否写入到svc的端点中去 ，

VIP和Service代理

在kubernetes集群中， 每个Node运行一个kube-proxy进程。kube-proxy负责为service实现了一种VIP（虚拟IP）的形式，而不是externalName的形式。 在kubernetesv1.0版本， 代理完全在userpace。 在kubernetes1.1版本中 ， 新增了iptales代理， 但并部署默认的运行模式。 从kubernetesv1.2 起， 默认就是iptalbes代理， 在kubernetesv1.8.0-beta.0中， 添加了ipvs代理

在kubernetes1.14版本开始默认使用ipvs代理

在kubernetesv1.4版本开始默认使用ipvs代理

在kubernetesv1.9 版本， service是4层（tcp/udp over ip）的概念。 在kubernetesv1.1版本中， 新增了Ingress API（beta版）， 用来表示7层（http）服务

！为何不使用round-robin DNS？ 因为在客户端进行缓存，并没有清楚缓存

代理模式的分类

  1. userspace代理模式

    image-20210103115329247

  2. iptables代理模式

    image-20210103115450563

  3. ipvs代理模式

    这种模式， kube-proxy会监控kubernetes Service对象和endpoints， 调用netlink接口以相应地创建ipvs规则并定期kubernetes service对象和endpoints对象同步ipvs规则， 以确保ipvs状态与期望一致 。 访问服务时 ， 流量将被重定向到其中一个后端Pod

    与iptables类似， ipvs与netfilter的hook功能， 但使用哈希表作为底层数据结构并在内核空间中工作。 这意味着ipvs可以更快地重定向流量， 并且在同步代理规则时具有更好的性能。 此外， ipvs为负载均衡算法提供了更多选项， 例如：

    • rr: 轮训调度

    • lc：最小连接数

    • dh：目标哈希

    • sh：源哈希

    • sed：最短期望延迟

    • nq：不排队调度

      image-20210103120311944

ClusterIP

clusterIP主要在每个node节点使用iptables， 将发向clusterIP对应端口的数据， 转发到kube-proxy中， 然后kube-proxy自己内部实现有负载均衡的方法，并可以查询到这个service下对应pod的地址和端口， 进而把数据转发给对应的pod的地址和端口

image-20210103120739292

为了实现图上的功能， 主要需要以下几个组件的协同工作：

  • apiserver用户通过kubectl命令向ipaserver发送创建service的命令， ipaserver接收到请求后将数据存储到etcd中
  • Kube-proxy kubernetes的每个节点中都有一个叫做kube-proxy的进程， 这个进程负责感知service， pod变化， 并将变化的信息写入本地的iptables规则中
  • iptables使用NAT等技术将virtuallP的流量转发值endpoint中

创建myapp-deployment.yaml文件

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      release: stabel
  template:
    metadata:
      labels:
        app: myapp
        release: stabel
        env: test
    spec:
      containers:
      - name: myapp
        image: hub.syuee.com/library/syuee-nginx:v2
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80
        readinessProbe:
          httpGet:
            port: 80
            path: /api/server
          initialDelaySeconds: 1
          periodSeconds: 2
        livenessProbe:
          httpGet:
            port: 80
            path: /
          initialDelaySeconds: 1
          periodSeconds: 3
          timeoutSeconds: 4
      initContainers:
      - name: init-myapp
        image: busybox
        command: ['sh','-c','until nslookup syuee-web-svc; do echo waiting for syuee-web-svc; sleep 2; done;']

创建Service信息vim myapp-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: myapp
    release: stabel
  ports:
  - name: http
    port: 80
    targetPort: 80

Headless Service

有时不需要或不想要负载均衡， 以及单独的Service IP。 遇到这种情况， 可以通过指定Cluster IP(spec.clusterIP)的值“Node”来创建Headless Service。 这类Service 并不会分配Cluster IP， kube-proxy不会处理它们， 而且平台也不会为它们进行负载均衡和路由

Vim myapp-headless.yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp-headless
  namespace: default
spec:
  selector:
    app: myapp
  clusterIP: "None"
  ports:
  - port: 80
    targetPort: 80

查看coreDNS的IP地址
kubectl get pod -n kube-system -o wide
需要安装dig命令: yum install bind-utils
dig -t A myapp-headless.default.svc.cluster.local. @10.244.4.4

Node Port

nodePort的原理在于node上开了一个端口， 将向该端口的流量导入到kube-proxy, 然后由kube-proxy进一步给对应的pod

apiVersion: v1
kind: Service
metadata:
  name: myapp-node
  namespace: default
spec:
  type: NodePort
  selector:
    app: myapp
    release: stabel
  ports:
  - name: http
    port: 80
    targetPort: 80

查询流程

iptables -t nat -nvL
	KUBE-NODEPORTS 
	
ipvsadm -Ln

LoadBalancer

loadBalancer和nodePort其实是同一种方式。 区别在于loadBalancer和nodePort多了一步， 就是可以调用cloud provider去创建LB来向节点导流

image-20210103145815293

ExternalName

这种类型的Service通过返回CANME和它的值， 可以将服务映射到externalName字段的内容（例如：hub.atguigu.com)。ExternalName Service是Service的特例， 它没有selector， 也没有定义任何的端口和Endpoint ，相反的，对于运行在集群外部的服务， 它通过返回该外部服务的别名这种方式来提供服务。

apiVersion: v1
kind: Service
metadata:
  name: my-service-1
  namespace: default
spec:
  type: ExternalName
  externalName: my.detabase.example.com

当查询主机my-service.default.svc.cluster.local(SVC_NAME.NAMESPACE.svc.cluster.local)时， 集群的DNS服务将返回一个值my.database.example.com的CNAME记录，访问这个服务的工作方式和其他的相同， 唯一不同的是重定向发生在DNS层， 而且不会进行代理或转发

lngress-Niginx github 地址：http://github.com/kubernetes/ingress-nginx

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

image-20210103151026305

image-20210103151052112

下载镜像及版本

pollyduan/ingress-nginx-controller:v0.35.0
jettech/kube-webhook-certgen:v1.2.2

上传到自己的本地仓库Registry

### hub.syuee.com本地仓库IP地址
### 为镜像打个tag
# docker tag pollyduan/ingress-nginx-controller:v0.35.0 hub.syuee.com/library/ingress-nginx-controller:v0.35.0
# docker tag jettech/kube-webhook-certgen:v1.2.2 hub.syuee.com/library/kube-webhook-certgen:v1.2.2
### 推送到本地仓库
# docker push hub.syuee.com/library/ingress-nginx-controller:v0.35.0
# docker push hub.syuee.com/library/kube-webhook-certgen:v1.2.2
### 查看镜像
# docker images | grep ingress

拉取安装yaml 文件 这里部署的是0.35.0

https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.35.0/deploy/static/provider/cloud/deploy.yaml

修改所有的image

image: k8s.gcr.io/ingress-nginx/controller:v0.35.0@sha256:fc4979d8b8443a831c9789b5155cded454cb7de737a8b727bc2ba0106d2eae8b
---> image: hub.syuee.com/library/ingress-nginx-controller:v0.35.0

image: docker.io/jettech/kube-webhook-certgen:v1.2.2
---> image: hub.syuee.com/library/kube-webhook-certgen:v1.2.2

部署Ingress-Nginx

kubectl apply -f deploy.yaml

查看执行结果

kubectl get pods -n ingress-nginx

创建ingress 规则

编写ingress-app.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: wwww1.syuee.com
    http:
      paths:
      -  path: /
         backend:
           serviceName: nginx-svc
           servicePort: 80

执行文件和查看结果

# kubectl apply -f ingress-app.yml
 
# kubectl get ingress -A

修改主机域名解析

这里以Windows为例，在C:\Windows\System32\drivers\etc目录下，打开hosts文件进行编辑，在最末一行添加：

192.168.31.74 www1.syuee.com

如遇到无法访问

2 修改kube-proxy配置参数。追加：

--proxy-mode=ipvs --masquerade-all=true

3 如果以上均正常还是无法访问，则查看 ingress-nginx pod被调度到的node宿主机。

kubectl get pods  -n ingress-nginx -o wide

则hosts中dns配置中使用其中一个ingress-nginx pod的node ip 域名  
/windows/system32/drivers/etc/hosts

三、lngress

部署Ingress-Nginx

kubectl apply -f deploy.yaml

Ingress HTTP代理访问

deployment，Service，Ingress Yaml文件

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-dm
spec:
  replicas: 2
  selector:
    matchLabels:
      name: nginx-dm
  template:
    metadata:
      labels:
        name: nginx-dm
    spec:
      containers:
        - name: nginx-dm
          image: hub.syuee.com/library/syuee-nginx:v2
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

            
---           
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    name: nginx-dm
    
---    
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-mynginx
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: www1.syuee.com
    http:
      paths:
      - path: #路径 如/ /index
        backend:
          serviceName: nginx-svc
          servicePort: 80

多个域名

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-mynginx1
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: www1.syuee.com
    http:
      paths:
      - path: #路径 如/ /index
        backend:
          serviceName: nginx-svc1
          servicePort: 80      
 ---
 apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-mynginx2
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: www2.syuee.com
    http:
      paths:
      - path: #路径 如/ /index
        backend:
          serviceName: nginx-svc2
          servicePort: 80

如遇到无法访问

2 修改kube-proxy配置参数。

--proxy-mode=ipvs --masquerade-all=true

3 如果以上均正常还是无法访问，则查看 ingress-nginx pod被调度到的node宿主机。

kubectl get pods  -n ingress-nginx -o wide

则hosts中dns配置中使用其中一个ingress-nginx pod的node ip 域名  

/windows/system32/drivers/etc/hosts
/etc/hosts

Ingress HTTPS代理访问

创建证书， 以及cert 存储方式

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=NGINXSVC/o=NGINXSVC"
kubectl create secret tls tls-secret --key tls.key --cert tls.crt

Deployment，Service， Ingress Yaml文件

apiVersion: exensions/v1beta1
kind: Ingress
metadata:
  name: nginx-test
spec:
  tls:
    - hosts:
      - foo.bar.com
      secretName: tls-secret
  rules:
    - host: foo.bar.com
      http:
        paths:
        - path: /
          backend:
            serviceName: nginx-svc
            servicePort: 80

Nginx 进行BasicAuth

安装http服务器这里需要http支持
yum -y install httpd
新建目录
mkdir basic-auth
创建认证文件 文件名为auth 用户名foo
htpasswd -c auth foo
kubectl create secret generic basic-auth --from-file=auth

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-with-auth
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
    nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - foo'
spec:
  rules:
  - host: www4.syuee.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-svc
          servicePort: 80

Nginx 进行重写

名称 描述 值
nginx-ingress.kubernetes.io/rewrite-target 必须重定向流量的目标URL 串
Nginx-ingress.kubernetes.io/ssl-redirect 指示位置部分是否仅可访问SSL（当ingress包含证书时默认True） 布尔
nginx.ingress.kubernetes.io/force-ssl-redirect 即便ingress未启用TLS， 也强制重定向到HTTPS 布尔
nginx.ingress.kubernetes.io/app-root 定义Controller必须重定向的应用程序根， 如果它在‘/s'上下文中 串
nginx.ingress.kubernetes.io/use-regex 指示ingress上定义的路径是否使用正则表达式 布尔 
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-test
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: http://foo.bar.com:31795/hostname.html
spec:
  rules:
  - host: foo10.bar.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-svc
          servicePort: 80

四、endpoint

endpoint是k8s集群中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址。service配置selector，endpoint controller才会自动创建对应的endpoint对象；否则，不会生成endpoint对象.

例如，k8s集群中创建一个名为hello的service，就会生成一个同名的endpoint对象，ENDPOINTS就是service关联的pod的ip地址和端口。

一个 Service 由一组 backend Pod 组成。这些 Pod 通过 endpoints 暴露出来。 Service Selector 将持续评估，结果被 POST 到一个名称为 Service-hello 的 Endpoint 对象上。 当 Pod 终止后，它会自动从 Endpoint 中移除，新的能够匹配上 Service Selector 的 Pod 将自动地被添加到 Endpoint 中。 检查该 Endpoint，注意到 IP 地址与创建的 Pod 是相同的。现在，能够从集群中任意节点上使用 curl 命令请求 hello Service <CLUSTER-IP>:<PORT> 。 注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇，可以阅读更多关于 服务代理 的内容。

Endpoints是实现实际服务的端点集合。

Kubernetes在创建Service时，根据Service的标签选择器（Label Selector）来查找Pod，据此创建与Service同名的EndPoints对象。当Pod的地址发生变化时，EndPoints也随之变化。Service接收到请求时，就能通过EndPoints找到请求转发的目标地址。

Service不仅可以代理Pod，还可以代理任意其他后端，比如运行在Kubernetes外部Mysql、Oracle等。这是通过定义两个同名的service和endPoints来实现的。

在实际的生产环境使用中，通过分布式存储来实现的磁盘在mysql这种IO密集性应用中，性能问题会显得非常突出。所以在实际应用中，一般不会把mysql这种应用直接放入kubernetes中管理，而是使用专用的服务器来独立部署。而像web这种无状态应用依然会运行在kubernetes当中，这个时候web服务器要连接kubernetes管理之外的数据库，有两种方式：一是直接连接数据库所在物理服务器IP，另一种方式就是借助kubernetes的Endpoints直接将外部服务器映射为kubernetes内部的一个服务。

　　简单认为：动态存储pod名字与pod ip对应关系的list，并提供将请求转发到实际pod上的能力

[root@k8s-master ~]# pwd
/root
[root@k8s-master ~]# cat deployment-hello.yaml 
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 4
  template:
    metadata:
      labels:
        run: hello
    spec:
      containers:
       - name: hello
         image: tomcat:8 #确保node节点上有该镜像且可正常运行，注意是node节点机器上，不是master机器
         imagePullPolicy: IfNotPresent ##Always,IfNotPresent,Never
         ports:
         - name: http
           containerPort: 8080

[root@k8s-master ~]# cat service-hello.yaml 
apiVersion: v1
kind: Service
metadata:
  name: service-hello
  labels:
  name: service-hello
spec:
  type: NodePort      #这里代表是NodePort类型的,另外还有ingress,LoadBalancer
  ports:
  - port: 80          #这里的端口和clusterIP(kubectl describe service service-hello中的IP的port)对应，即在集群中所有机器上curl 10.98.166.242:80可访问发布的应用服务。
    targetPort: 8080  #端口一定要和container暴露出来的端口对应，nodejs暴露出来的端口是8081，所以这里也应是8081
    protocol: TCP
    nodePort: 31111   # 所有的节点都会开放此端口30000--32767，此端口供外部调用。
  selector:
    run: hello         #这里选择器一定要选择容器的标签，之前写name:kube-node是错的。
[root@k8s-master ~]# pwd
/root
[root@k8s-master ~]#

[root@k8s-master ~]# kubectl create -f service-hello.yaml 
service/service-hello created

[root@k8s-master ~]# kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 4h24m
service-hello NodePort 10.98.166.242 <none> 80:31111/TCP 42s
[root@k8s-master ~]#

root@k8s-master ~]# kubectl get services -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 4h25m <none>
service-hello NodePort 10.98.166.242 <none> 80:31111/TCP 104s run=hello

[root@k8s-master ~]# kubectl describe service service-hello
Name:                     service-hello
Namespace:                default
Labels:                   <none>
Annotations:              <none>
Selector:                 run=hello
Type:                     NodePort
IP:                       10.98.166.242
Port:                     <unset>  80/TCP
TargetPort:               8080/TCP
NodePort:                 <unset>  31111/TCP
Endpoints:                10.244.1.22:8080,10.244.1.23:8080,10.244.1.24:8080 + 1 more...
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>
[root@k8s-master ~]#

[root@k8s-master ~]# kubectl get endpoints
NAME            ENDPOINTS                                                        AGE
kubernetes      192.168.111.130:6443                                             20h
service-hello   10.244.1.22:8080,10.244.1.23:8080,10.244.1.24:8080 + 1 more...   15h
[root@k8s-master ~]# kubectl describe endpoint service-hello
error: the server doesn't have a resource type "endpoint"
[root@k8s-master ~]# kubectl describe endpoints service-hello
Name:         service-hello
Namespace:    default
Labels:       <none>
Annotations:  endpoints.kubernetes.io/last-change-trigger-time: 2019-04-03T02:18:57Z
Subsets:
  Addresses:          10.244.1.22,10.244.1.23,10.244.1.24,10.244.1.25
  NotReadyAddresses:  <none>
  Ports:
    Name     Port  Protocol
    ----     ----  --------
    <unset>  8080  TCP

Events:
  Type     Reason                  Age                From                 Message
  ----     ------                  ----               ----                 -------
  Warning  FailedToUpdateEndpoint  48m (x2 over 69m)  endpoint-controller  Failed to update endpoint default/service-hello: Operation cannot be fulfilled on endpoints "service-hello": the object has been modified; please apply your changes to the latest version and try again
[root@k8s-master ~]#

Endpoints是指一个服务的端点，当你的服务需要访问外部资源时，而你又不想把外部地址配置到代码里，这时，你可以在k8s里建立一个kind为Endpoints的服务，它可以帮助你的程序解析这个外部地址。

  • 声明一个elasticsearch-1的服务，它映射到一个外部的地址192.168.11.13的9200端口
kind: Service
apiVersion: v1
metadata:
  name: elasticsearch-1
spec:
  clusterIP: None
---
kind: Endpoints
apiVersion: v1
metadata:
  name: elasticsearch-1
subsets:
  - addresses:
      - ip: 192.168.11.13
    ports:
      - port: 9200
  • 而如果你的外部服务也是一个k8s服务，这时也可以通过ExternalName类型也实现这种映射关系，比如在跨namespace访问资源时，你就可以通过ExternalName来实现一种类似快捷方式的功能。

例如，以下 Service 定义将 prod 名称空间中的 my-service 服务映射到 my.database.example.com

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

说明： ExternalName 接受 IPv4 地址字符串，但作为包含数字的 DNS 名称，而不是 IP 地址。 类似于 IPv4 地址的外部名称不能由 CoreDNS 或 ingress-nginx 解析，因为外部名称旨在指定规范的 DNS 名称。 要对 IP 地址进行硬编码，请考虑使用 headless Services。

并不是service暴露一个外部ip，而是service转发外部ip+port，做法如下：

apiVersion: v1
kind: Endpoints
metadata:
  name: http
  namespace: default
subsets:
- addresses:
  - ip: 10.2.1.1
  ports:
  - name: http
    port: 8080
    protocol: TCP

其中10.2.1.1:8080是外部服务。

其次，创建service，其中名字一定要和endpoint的一致：

apiVersion: v1
kind: Service
metadata:
  name: http
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80

然后访问service自动生成的虚拟ip加port即可。

FAQ

1）ingress-controller起不来

通过kubectl describe查看pod，有这样一句报错：port 80 is already in use. Please check the flag --http-port

解决方法：

通过# netstat -antp | grep 80，找到了占用端口的应用，然后停掉就可以了。2）ingress-controller起不来

查看官方文档有这么一句提示

img

所以，在执行ingress-controller.yml后，执行以下如下命令：

kubectl wait --namespace ingress-nginx \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/component=controller \
  --timeout=120s

3）浏览器直接输入域名无法访问，后台curl时报错：[root@node1 ~]# curl http://example.ingressdemo.com
curl: (6) Could not resolve host: ingress-nginx-controller-admission.ingress-nginx.svc; Unknown error

解决方法：

[root@node1]# kubectl get ValidatingWebhookConfiguration/ingress-nginx-admission -n ingress-nginx
NAME                      WEBHOOKS   AGE
ingress-nginx-admission   1          7d1h
[root@test ~]# kubectl edit ValidatingWebhookConfiguration/ingress-nginx-admission -n ingress-nginx
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission edited
######下面是edit界面中的某一段
webhooks:
- admissionReviewVersions:
- v1beta1
clientConfig:
  caBundle: BDRVJUSUZJQ0FURS0tLS0LS0tLS1CRUdJTitCk1JSURUNBaEJOUUROWnBJcXR3JPRENCM3FBREFnTTJzaDg3YVVrSlpNQW9HQ0NxR1NNNDlCQU1DWUjBUQVFIL0TUFBd0lCNxR1NNNDRTVNVEl3TlRJMVdoZ1BNakV5TURBME1qVXhNakExTWpWYU1BQXdXVEZ3dOakFPQmdOVkFUQmdjcWhrak9QUUlCQmdncQpoa2pPUFFNY04KTWpBd05UQkJ3TkNBQVRDcWRWOWdVTm5yelYSs3NlBUQVBRSm9KS30Umg5NlIxYkl6R3lzQjE3UHJzc21CNDBGQjRPYU5jJHYVpaTHNtN1MR28yMGwzCdzblJva2FRcWpMOBrYW96hROEJBZjhFQkFNQ0FnUXcKRXdZRFZSMGxCQXd3Q2dZSUt3WUJCUVVIQXdFCL3pBS0JnZ3Foa2pPUFFRRApBZ05KQURCR0FpRUE4K1A1WGlyOFgzREJEK1IvN2lIVWxzNXg3TW1UdjVMN1VzQzBd0R3WURJBVXdBd0VQ0lRQ2JS1FTkQgQ0VSVSMUNpCWG50RmdDblJLRkxjUVkxeWJ6bDVwTnlyZkZnPkVOdGSUNBVEUtLS0tLQoEJ6N21CNU9KT0KLS0tLEl=
  service:
    name: ingress-nginx-controller-admission
    namespace: ingress-nginx
    path: /extensions/v1beta1/ingresses
    port: 443
failurePolicy: Fail             ################## 改成：Ignore
matchPolicy: Exact
name: validate.nginx.ingress.kubernetes.io
posted @ 2021-07-25 15:28  白色的番茄  阅读(302)  评论(0)  编辑  收藏  举报