我正在尝试向内部负载均衡器添加入口规则。根据扩展坞,它可以重定向到服务。它的工作原理只要服务是“ClusterIP”,但在其“LoadBalancer”时进入无限重定向
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: demo-ingress
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
tls:
- hosts:
- demo.azure.com
secretName: aks-ingress-tls
rules:
- host: demo.azure.com
http:
paths:
- path: /
backend:
serviceName: aks-helloworld
servicePort: 80
- path: /demo
backend:
serviceName: demo-backend
servicePort: 80
https://demo.azure.com工作,但https://demo.azure.com/demo没有。差异是aks-helloworld是一个ClusterIP但是demo-backend是一个LoadBalancer
13:33 $ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
aks-helloworld ClusterIP 10.0.204.168 <none> 80/TCP 15m
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 16h
demo-backend LoadBalancer 10.0.198.251 23.99.128.86 80:30332/TCP 15h
对于您的问题,我不认为这是一个类型为clusterIP而另一个类型为LoadBalancer的问题。当流量通过两种方式进入时,它们都将重定向到服务,在您的情况下,演示后端。
看看我身边的测试结果:
从互联网访问:
我没有添加TLS,但我认为无论是否有TLS,流量都将重定向到服务。当我通过helm安装第二个应用程序时,我只需用--set serviceType="LoadBalancer"
更改命令。因此,您可以检查您的步骤是否有问题。
但我不认为将这两种方式的流量路由到一个服务是一种好方法。如果你通过Ingress使用TLS,那么当有同时使用LoadBalancer的方式时它将不安全。因为流量将通过LoadBalancer绕过TLS。
更新
根据您的评论,我认为您需要为您的应用程序创建一个部署,然后使用它创建一个服务,文件如下:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 1
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: yourImage
ports:
- containerPort: 80
name: myapp
---
apiVersion: v1
kind: Service
metadata:
name: demo-backend
labels:
app: myapp
spec:
type: ClusterIP
selector:
app: myapp
ports:
- port: 80
name: http
部署是应用程序的基础,服务只接受pod的流量。所以我猜你错过了部署,以便你可以访问你的应用程序。
如果您使用Ingress作为资源,为什么要将服务公开为类型“LoadBalancer”?您实际上是在进入入口负载均衡器然后命中另一个服务负载均衡器,这可能导致此重定向问题。
问题是由于引擎控制器添加了以下标头。
X-FORWARDED-PROTO: https
X-FORWARDED-PORT: 443