作者：MeshCloud脉时云公有云架构师 陈博文
一、前言
谷歌凭借几十年大规模容器应用的丰富经验，投入大量人力、财力开源并主导了 Kubernetes 这个重要的开源项目。所以相比于其它平台google云对于Kubernetes的使用可以说是更进一步的
Kubernetes作为最主流的当前最主流的容器编排方案，在Google Cloud Platform也有着自己的一套解决方案Google Kubernetes Engine
本篇文章介绍配合GCP（google cloud platform）GLB(google LoadBalancer)使用的GKEingress
二、GKE Ingress 简介
Google Kubernetes Engine (GKE) 提供了一个名为 GKE Ingress 的代管式内置 Ingress 控制器。此控制器将 Ingress 资源实现为 Google Cloud 负载均衡器，用于 GKE 中的 HTTP(S) 工作负载，暴露您的后端应用
这种原生负载均衡的优势在于：、更高的可见性和更多的功能
1、更快速的响应：
由于容器原生负载均衡器直接与 Pod 进行通信，而且连接的网络跃点较少，因此延迟时间和吞吐量均得到了改善。
2、提升了可见性：
利用容器原生负载均衡，您可以了解从 HTTP(S) 负载均衡器到 Pod 的延迟时间。从 HTTP(S) 负载均衡器到每个 Pod 的延迟时间都是可见的，这些延迟时间通过节点 IP 基础容器原生负载均衡进行了汇总。这样，可以更轻松地在 NEG 级层排查服务问题。
3、更多的功能：
对高级负载均衡功能的支持容器原生负载均衡在 GKE 中提供对于多种 HTTP(S) 负载均衡功能的原生支持，例如与 Google Cloud Armor、Cloud CDN、Identity-Aware Proxy 等 Google Cloud 服务的集成。此外，还具有负载均衡算法，可实现准确的流量分发。
三、适用于 HTTP(S) 负载均衡的 GKE Ingress
在GKE集群中可以直接使用yaml文件来创建ingress，它会自动生成Google LoadBalancer用于负载均衡，比较像Kubernetes中SVC的type:LoadBalancer
Ingress：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
spec:
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: test-svc
port:
number: 80
创建
kubectl apply -f ingress.yaml检查:
kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
test-ingress <none> * 34.107.253.195 80 4m39s负载均衡界面就会创建好一个带公网ip的lb暴露后端的nginx服务
通常会有5-10分钟的延迟
通过浏览器打开看一下，已经可以通过lb的公网进行后端服务的访问了
四、修改配置
*修改配置需要等待5-10分钟，建议删除重建，不要用apply进行更新
原因：主要是配置的改动需要在全球所有网络节点生效的原因。第三方云用的大多数是开源的Ingress，比如集群内部署的nginx ingress，就不需要这么长的生效时间。这样就利用不了云厂商原生负载均衡的好处了，比如全球单一IP，客户端就近接入等。
五、一些限制
- 在使用的版本低于 1.16 的集群中，命名空间和 Ingress 名称的总长度不得超过 40 个字符。如果不遵守该规则，可能会导致 GKE Ingress 控制器发生异常。
- 不支持将多个 Ingress 资源合并到单个 Google Cloud 负载均衡器中。
- 如需使 GKE Ingress 控制器使用 readinessProbes 作为健康检查，在创建 Ingress 时必须存在 Ingress 的 Pod。如果您的副本调节至 0，则系统会应用默认的健康检查。