带部署的 Kubernetes 入口更新
Kubernetes ingress update with deployment
我们目前正在设置一个 kubernetes 集群来部署我们的生产工作负载(主要是 http rest 服务)。
在这个集群中,我们设置了 nginx 入口控制器来将流量从外部世界路由到我们的服务。由于入口控制器将主要用于路径路由,我确实有以下问题:
- 问题一:动态后端路由
是否可以将流量路由到后端,而无需在入口规范中特别指定后端名称?例如,我有以下入口:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
paths:
- path: /apple
backend:
serviceName: apple-service
servicePort: 8080
有没有可能 /apple 请求被路由到 apple-service 而没有在 serviceName 中特别指定?所以/apple自动路由到apple-service服务,/orange自动路由到orange服务,没有显式指定后端名称?
- 问题编号 2
如果第一个没有解决方案,我们可以根据一些约定进行部署,那么现在的问题是如何以自动化方式管理入口。
由于服务将由自动化 CI/CD 管道部署,并且随着服务添加到集群可能会添加新路径,因此 ci/cd 编排器(例如 jenkins)如何在应用程序部署了吗?这样我们就可以确定,不需要对集群进行手动干预,并且每个路由都与相应的服务一起部署?
我希望所提供的信息足以理解问题。
非常感谢您的支持。
只需在您的 ci/cd 管道中执行一个步骤,检查当前入口是什么以及是否需要更新某种参数。
高级步骤...
kubectl get ingress example-ingress -o yaml > ex-ingress.yaml
您可以将该输出写入文件并读取、更新、验证等等。
然后将其与您的部署一起推送到集群
kubectl replace -f ex-ingress.yaml
https://kubernetes.io/docs/concepts/services-networking/ingress/
Question 1: Dynamic backend routing
每个入口规则应包含一个路径列表,每个路径都有一个用 serviceName
和 servicePort
定义的关联后端。后端是 Service doc 中描述的服务和端口名称的组合。
没有规则的 Ingress 将所有流量发送到单个默认后端。默认后端通常是 Ingress 控制器的配置选项,未在您的 Ingress 资源中指定。
如果 none 的主机或路径与 Ingress 对象中的 HTTP 请求匹配,流量将路由到您的默认后端。
还有很多额外的Ingress controllers。我是其中一些支持这样的功能。
Question Number 2
我同意大卫沃尔顿的观点。在 CI/CD 管道中增加额外的步骤可能是这里的最佳选择。
第 2 点的解决方案最终是每个服务部署都可以与每个自己的入口一起部署,因此不需要第 1 点。也就是说,您可以部署多个入口规则。
我的解决方案是为每个环境(k8s 命名空间)的入口部署设置单独的 helm chart。在 values 中,我有一个我的应用程序列表,它可以在 apply/update helm chart 部署期间重新定义。 Helm 图表模板有一个循环来为列表中的每个元素添加规则。
在 jenkins 作业上,我 运行 kubectl 获取命名空间中当前服务的列表,并将此列表作为此 helm 图表的输入变量。
每次部署应用程序后,都会触发此“alb-update-rules”作业。如果我用多个服务部署整个环境,我只是在最后触发这个工作。
效果很好,在这种情况下可能就足够了。
我们目前正在设置一个 kubernetes 集群来部署我们的生产工作负载(主要是 http rest 服务)。 在这个集群中,我们设置了 nginx 入口控制器来将流量从外部世界路由到我们的服务。由于入口控制器将主要用于路径路由,我确实有以下问题:
- 问题一:动态后端路由
是否可以将流量路由到后端,而无需在入口规范中特别指定后端名称?例如,我有以下入口:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
paths:
- path: /apple
backend:
serviceName: apple-service
servicePort: 8080
有没有可能 /apple 请求被路由到 apple-service 而没有在 serviceName 中特别指定?所以/apple自动路由到apple-service服务,/orange自动路由到orange服务,没有显式指定后端名称?
- 问题编号 2
如果第一个没有解决方案,我们可以根据一些约定进行部署,那么现在的问题是如何以自动化方式管理入口。 由于服务将由自动化 CI/CD 管道部署,并且随着服务添加到集群可能会添加新路径,因此 ci/cd 编排器(例如 jenkins)如何在应用程序部署了吗?这样我们就可以确定,不需要对集群进行手动干预,并且每个路由都与相应的服务一起部署?
我希望所提供的信息足以理解问题。 非常感谢您的支持。
只需在您的 ci/cd 管道中执行一个步骤,检查当前入口是什么以及是否需要更新某种参数。
高级步骤...
kubectl get ingress example-ingress -o yaml > ex-ingress.yaml
您可以将该输出写入文件并读取、更新、验证等等。
然后将其与您的部署一起推送到集群
kubectl replace -f ex-ingress.yaml
https://kubernetes.io/docs/concepts/services-networking/ingress/
Question 1: Dynamic backend routing
每个入口规则应包含一个路径列表,每个路径都有一个用 serviceName
和 servicePort
定义的关联后端。后端是 Service doc 中描述的服务和端口名称的组合。
没有规则的 Ingress 将所有流量发送到单个默认后端。默认后端通常是 Ingress 控制器的配置选项,未在您的 Ingress 资源中指定。
如果 none 的主机或路径与 Ingress 对象中的 HTTP 请求匹配,流量将路由到您的默认后端。
还有很多额外的Ingress controllers。我是其中一些支持这样的功能。
Question Number 2
我同意大卫沃尔顿的观点。在 CI/CD 管道中增加额外的步骤可能是这里的最佳选择。
第 2 点的解决方案最终是每个服务部署都可以与每个自己的入口一起部署,因此不需要第 1 点。也就是说,您可以部署多个入口规则。
我的解决方案是为每个环境(k8s 命名空间)的入口部署设置单独的 helm chart。在 values 中,我有一个我的应用程序列表,它可以在 apply/update helm chart 部署期间重新定义。 Helm 图表模板有一个循环来为列表中的每个元素添加规则。
在 jenkins 作业上,我 运行 kubectl 获取命名空间中当前服务的列表,并将此列表作为此 helm 图表的输入变量。 每次部署应用程序后,都会触发此“alb-update-rules”作业。如果我用多个服务部署整个环境,我只是在最后触发这个工作。
效果很好,在这种情况下可能就足够了。