云原生之旅 - 8)云原生时代的网关 Ingress Nginx
前言
当我们在Kubernetes部署的服务需要暴露给外部用户使用时,有三种选择:LoadBalancer,NodePort, Ingress。
LoadBalancer类型得结合各个Cloud Provider提供的LB来使用,如果需要暴露的service很多,需要很多LB以及公网IP,比较浪费cost。
NodePort 方式一个端口只能一个服务使用,根据端口划分服务,可用端口范围:30000~32767, 同样如果在暴露的servicie很多的情况下会导致节点要开的端口越来越多,不好管理,平时测试可以用用。
Ingress是自kubernetes1.1版本后引入的资源类型,在这个资源中我们可以去配置我们的服务路由规则,但是要真正去实现识别这个 Ingress 并提供代理路由功能,还需要安装一个对应的控制器Ingress controller才能实现。Ingress nginx controller 本质上就是kubernetes 部署的pod 里面有一个 Nginx container,只不过它能根据 Ingress 资源的定义动态生成 Nginx 的配置文件,然后动态 Reload。可以理解成 Ingress controller是由Kubernetes管理的负载均衡器。
Ingress controller是以一种插件的形式提供,有多种实现,有基于 Nginx 的,也有基于 HAProxy的,还有现在很流行的Envoy,详见:https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/, 我后面文章也会介绍基于 Envoy的 Ingress controller。
本文使用Kubernetes 社区推出的 Ingress Controller: Ingress-nginx (github.com/kubernetes/ingress-nginx) 它是基于Nginx 的扩展版 OpenResty 及诸多第三方模块构建的,其基于 OpenResty 的 Lua 嵌入式编程能力,扩展了 Nginx 的功能,并基于 balancer_by_lua 模块实现了 Pod 变化的动态变更功能。
要注意区分另外一个名字相近由Nginx公司推出的Nginx ingress controller (github.com/nginxinc/kubernetes-ingress)。Nginx 官方版本提供其基于Go语言开发的 Ingress 控制器,并与 Nginx 集成分为 Nginx 开源版和 Nginx Plus 版,开源版仅基于 Nginx 的原始功能,不支持 Pod 变化的动态变更。Nginx Plus 版则提供了诸多完善的商业功能,其支持 Nginx 原生配置指令、JWT 验证、Pod 变化的动态配置及主动健康检查等功能。
安装
测试环境
- Kubernetes 1.22(GKE)
- Ingress Nginx 1.3.0
- Kustomize 3.10.0
安装及使用
安装方式有多种,我这里介绍使用Kustomize 安装, Kustomize入门可以参考我这篇文章【云原生之旅 - 6)不能错过的一款 Kubernetes 应用编排管理神器 Kustomize】
k8s manifests 参考 my repo
根据需要修改自己所需,这里的例子是为 atlantis namespace 下面的 atlantis serivce 配置一个Ingress
由于Ingress controller 和 Ingress 均安装在dmz namespace, 和 atlantis 不在同一个namespace下面,我们需要为atlantis serivce 加了一个 ExternalName 类型的service 相当于别名。
这样dmz namespace 下面 Ingress 就指向 -> ExternalName 类型的service -> 指向 atlantis ns 下面 atlantis svc。
(Optional)Ingress 和 atlantis 放在同一个namespace 下面,就不需要多一个 ExernalName service了。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: sre-ingress-resource annotations: nginx.ingress.kubernetes.io/proxy-connect-timeout: "300" nginx.ingress.kubernetes.io/proxy-send-timeout: "300" nginx.ingress.kubernetes.io/proxy-read-timeout: "300" nginx.ingress.kubernetes.io/proxy-body-size: 100m nginx.ingress.kubernetes.io/proxy-buffer-size: 512k nginx.ingress.kubernetes.io/client-body-buffer-size: 512k ingress.kubernetes.io/ssl-redirect: "true" ingress.kubernetes.io/force-ssl-redirect: "true" spec: ingressClassName: nginx rules: - host: atlantis-demo.wadexu.cloud http: paths: - path: / pathType: Prefix backend: service: name: atlantis-demo-ext-svc port: number: 8080 tls: - hosts: - atlantis-demo.wadexu.cloud secretName: wade-tls-secret
--- apiVersion: v1 kind: Service metadata: name: atlantis-demo-ext-svc spec: type: ExternalName externalName: atlantis.atlantis.svc.cluster.local ports: - name: http port: 8080 targetPort: 4141 protocol: TCP
build and apply
kustomize build ingress-nginx-public/sre-mgmt-dev/ > ~/deploy.yaml kubectl apply -f ~/deploy.yaml
因为用了 https ,所以需要加一个tls-secret
kubectl create secret -n dmz tls wade-tls-secret \ --key ./xxx.key \ --cert ./xxx.pem
多个 Ingress Nginx Controller 部署
同一个cluster 如果要安装另一个ingress nginx controller,比如作为内部API网关,该怎么实现呢?
为了避免多个ingress controller 以一种困惑的方式同时争抢更新 ingress status字段,需要使用IngressClasses 官方文档
另外还要注意资源重名的情况,需要改name,否则后部署的Ingress controller 会覆盖前者, 比如 ClusterRoleBinding
参考 my manifests 部署在app namespace的internal Ingress nginx 针对以上资源的修改。
如不了解 Kustomize build,请先参考入门文档【云原生之旅 - 6)不能错过的一款 Kubernetes 应用编排管理神器 Kustomize】
apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: nginx spec: controller: k8s.io/internal-ingress-nginx
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: app commonLabels: app.kubernetes.io/name: internal-ingress-nginx app.kubernetes.io/instance: internal-ingress-nginx resources: - ../../base patchesStrategicMerge: - ingress-class-patch.yaml patches: - target: kind: IngressClass name: nginx patch: |- - op: replace path: /metadata/name value: internal-nginx - target: kind: Deployment name: ingress-nginx-controller patch: |- - op: replace path: /metadata/name value: internal-ingress-nginx-controller - op: replace path: /spec/template/spec/containers/0/args/3 value: "--controller-class=k8s.io/internal-ingress-nginx" - op: replace path: /spec/template/spec/containers/0/args/4 value: "--ingress-class=internal-nginx" - target: kind: ClusterRoleBinding name: ingress-nginx patch: |- - op: replace path: /metadata/name value: internal-ingress-nginx - target: kind: ClusterRoleBinding name: ingress-nginx-admission patch: |- - op: replace path: /metadata/name value: internal-ingress-nginx-admission - target: kind: ValidatingWebhookConfiguration name: ingress-nginx-admission patch: |- - op: replace path: /metadata/name value: internal-ingress-nginx-admission
总结
一般来说,Ingress nginx 足以应付大部分场景了,除非你想用到一些高阶功能,比如流量管理,熔断等等。那么我会推荐 后起之秀基于Enovy的那些Ingress controller,比如Ambassador 现在叫Emissary, CNCF的incubating 项目。
感谢阅读,如果您觉得本文的内容对您的学习有所帮助,您可以打赏和推荐,您的鼓励是我创作的动力。