在Kubernetes集群中,ALB Ingress对集群服务(Service)中外部可访问的API对象进行管理,提供七层负载均衡能力。本文介绍如何在ACS集群中使用ALB Ingress将来自不同域名或URL路径的请求转发给不同的后端服务器组、将HTTP访问重定向至HTTPS以及实现灰度发布等功能。
前提条件
已创建ACS集群。具体操作,请参见创建ACS集群。
已创建AlbConfig。具体操作,请参见ALB Ingress快速入门。
基于域名转发请求
通过创建一个简单的Ingress,根据指定的正常域名或空域名转发请求,示例如下。
基于正常域名转发请求
部署以下模板,分别创建Service、Deployment和Ingress,将访问请求通过Ingress的域名转发至Service。
apiVersion: v1 kind: Service metadata: name: demo-service namespace: default spec: ports: - name: port1 port: 80 protocol: TCP targetPort: 8080 selector: app: demo sessionAffinity: None type: ClusterIP --- apiVersion: apps/v1 kind: Deployment metadata: name: demo namespace: default spec: replicas: 1 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1 imagePullPolicy: IfNotPresent name: demo ports: - containerPort: 8080 protocol: TCP --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo namespace: default spec: ingressClassName: alb rules: - host: demo.domain.ingress.top http: paths: - backend: service: name: demo-service port: number: 80 path: /hello pathType: ImplementationSpecific
执行以下命令,通过指定的正常域名访问服务。
替换ADDRESS为ALB实例对应的域名地址,可通过
kubectl get ing
获取。curl -H "host: demo.domain.ingress.top" <ADDRESS>/hello
预期输出:
{"hello":"coffee"}
基于空域名转发请求
部署以下模板,创建Ingress。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo namespace: default spec: ingressClassName: alb rules: - host: "" http: paths: - backend: service: name: demo-service port: number: 80 path: /hello
执行以下命令,通过域名访问服务。
替换ADDRESS为ALB实例对应的域名地址,可通过
kubectl get ing
获取。curl <ADDRESS>/hello
预期输出:
{"hello":"coffee"}
基于URL路径转发请求
ALB Ingress支持按照URL转发请求,可以通过匹配规则(pathType
)字段设置不同的URL匹配策略。pathType
支持完整匹配(Exact)、默认(ImplementationSpecific)和前缀匹配(Prefix)三种匹配方式。
URL匹配策略可能存在冲突的情况,此时将会按照转发规则优先级进行排序,然后再转发请求,详情请参见配置转发规则优先级。
匹配方式 | 规则路径 | 请求路径 | 路径和请求路径是否匹配 |
Prefix | / | (所有路径) | 是 |
Prefix | /foo |
| 是 |
Prefix | /foo/ |
| 是 |
Prefix | /aaa/bb | /aaa/bbb | 否 |
Prefix | /aaa/bbb | /aaa/bbb | 是 |
Prefix | /aaa/bbb/ | /aaa/bbb | 是,请求路径忽略规则路径的尾部斜线 |
Prefix | /aaa/bbb | /aaa/bbb/ | 是,规则路径匹配请求路径的尾部斜线 |
Prefix | /aaa/bbb | /aaa/bbb/ccc | 是,规则路径匹配请求路径的子路径 |
Prefix | 同时设置两个规则路径:
| /aaa/ccc | 是,请求路径匹配规则路径的 |
Prefix | 同时设置两个规则路径:
| /aaa/ccc | 是,请求路径匹配规则路径的 |
Prefix | 同时设置两个规则路径:
| /ccc | 是,请求路径匹配规则路径的 |
Prefix | /aaa | /ccc | 否,未匹配前缀 |
Exact或ImplementationSpecific | /foo | /foo | 是 |
Exact或ImplementationSpecific | /foo | /bar | 否 |
Exact或ImplementationSpecific | /foo | /foo/ | 否 |
Exact或ImplementationSpecific | /foo/ | /foo | 否 |
三种匹配方式的示例如下:
Exact
部署以下模板,创建Ingress。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo-path namespace: default spec: ingressClassName: alb rules: - http: paths: - path: /hello backend: service: name: demo-service port: number: 80 pathType: Exact
执行以下命令,访问服务。
替换ADDRESS为ALB实例对应的域名地址,可通过
kubectl get ing
获取。curl <ADDRESS>/hello
预期输出:
{"hello":"coffee"}
(默认)ImplementationSpecific
在ALB Ingress中与Exact
做相同处理。
部署以下模板,创建Ingress。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo-path namespace: default spec: ingressClassName: alb rules: - http: paths: - path: /hello backend: service: name: demo-service port: number: 80 pathType: ImplementationSpecific
执行以下命令,访问服务。
替换ADDRESS为ALB实例对应的域名地址,可通过
kubectl get ing
获取。curl <ADDRESS>/hello
预期输出:
{"hello":"coffee"}
Prefix
以/
分隔的URL路径进行前缀匹配。匹配区分大小写,并且对路径中的元素逐个完成匹配。
部署以下模板,创建Ingress。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo-path-prefix namespace: default spec: ingressClassName: alb rules: - http: paths: - path: / backend: service: name: demo-service port: number: 80 pathType: Prefix
执行以下命令,访问服务。
替换ADDRESS为ALB实例对应的域名地址,可通过
kubectl get ing
获取。curl <ADDRESS>/hello
预期输出:
{"hello":"coffee"}
配置健康检查
ALB Ingress支持配置健康检查,可以通过设置以下注解来实现。
配置健康检查的YAML示例如下所示:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/healthcheck-enabled: "true"
alb.ingress.kubernetes.io/healthcheck-path: "/"
alb.ingress.kubernetes.io/healthcheck-protocol: "HTTP"
alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
alb.ingress.kubernetes.io/healthcheck-httpcode: "http_2xx"
alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
alb.ingress.kubernetes.io/healthcheck-interval-seconds: "2"
alb.ingress.kubernetes.io/healthy-threshold-count: "3"
alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
spec:
ingressClassName: alb
rules:
- http:
paths:
# 配置Context Path
- path: /tea
backend:
service:
name: tea-svc
port:
number: 80
# 配置Context Path
- path: /coffee
backend:
service:
name: coffee-svc
port:
number: 80
相关参数解释如下表所示。
参数 | 说明 |
alb.ingress.kubernetes.io/healthcheck-enabled | (可选)表示是否开启健康检查。默认开启(true)。 |
alb.ingress.kubernetes.io/healthcheck-path | (可选)表示健康检查路径。默认/。
|
alb.ingress.kubernetes.io/healthcheck-protocol | (可选)表示健康检查协议。
|
alb.ingress.kubernetes.io/healthcheck-method | (可选)选择一种健康检查方法。
|
alb.ingress.kubernetes.io/healthcheck-httpcode | 设置健康检查正常的状态码。 可以选择http_2xx(默认)、http_3xx、http_4xx和http_5xx。 |
alb.ingress.kubernetes.io/healthcheck-timeout-seconds | 表示接收健康检查的响应需要等待的时间。如果后端ECS在指定的时间内没有正确响应,则判定为健康检查失败。取值范围为[1, 300],单位为秒,默认值为5。 |
alb.ingress.kubernetes.io/healthcheck-interval-seconds | 健康检查的时间间隔。取值范围1~50秒,默认为2秒。 |
alb.ingress.kubernetes.io/healthy-threshold-count | 表示健康检查连续成功所设置的次数后会将后端服务器的健康检查状态由失败判定为成功。取值范围2~10,默认为3次。 |
alb.ingress.kubernetes.io/unhealthy-threshold-count | 表示健康检查连续失败所设置的次数后会将后端服务器的健康检查状态由成功判定为失败。取值范围2~10,默认为3次。 |
配置HTTP重定向至HTTPS
ALB Ingress通过设置注解alb.ingress.kubernetes.io/ssl-redirect: "true"
,可以将HTTP请求重定向到HTTPS 443端口。
ALB不支持直接在Ingress中创建新的监听。为确保Ingress能够正常工作,您需要先在Albconfig中创建所需的监听端口和协议,然后在Ingress中将这些监听与服务关联起来。关于如何创建ALB监听,请参见通过ALBConfig配置ALB监听。
配置示例如下:
apiVersion: v1
kind: Service
metadata:
name: demo-service-ssl
namespace: default
spec:
ports:
- name: port1
port: 80
protocol: TCP
targetPort: 8080
selector:
app: demo-ssl
sessionAffinity: None
type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-ssl
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: demo-ssl
template:
metadata:
labels:
app: demo-ssl
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
imagePullPolicy: IfNotPresent
name: demo-ssl
ports:
- containerPort: 8080
protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/ssl-redirect: "true"
name: demo-ssl
namespace: default
spec:
ingressClassName: alb
tls:
- hosts:
- ssl.alb.ingress.top
rules:
- host: ssl.alb.ingress.top
http:
paths:
- backend:
service:
name: demo-service-ssl
port:
number: 80
path: /
pathType: Prefix
支持后端HTTPS和gRPC协议
当前ALB后端协议支持HTTPS和gRPC协议,通过ALB Ingress只需要在注解中配置alb.ingress.kubernetes.io/backend-protocol: "grpc"
或alb.ingress.kubernetes.io/backend-protocol: "https"
即可。使用Ingress转发gRPC服务需要对应域名拥有SSL证书,使用TLS协议进行通信。配置gRPC协议的示例如下:
后端协议不支持修改,如果您需要变更协议,请删除重建Ingress。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/backend-protocol: "grpc"
name: lxd-grpc-ingress
spec:
ingressClassName: alb
tls:
- hosts:
- demo.alb.ingress.top
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: grpc-demo-svc
port:
number: 9080
配置正则表达
自定义转发条件中配置,需要用户自己在path
路径上编写正则表达式。配置示例如下:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/use-regex: "true" # 允许path字段使用正则表达式。
alb.ingress.kubernetes.io/conditions.service-a: | # 该注解中的服务为集群中已存在的服务,且服务名称必须和rule字段backend下的服务名称保持一致。
[{
"type": "Path",
"pathConfig": {
"values": [
"~*^/pathvalue1", # 正则表达式前需要添加~*作为正则标志,~*后的内容为实际生效的正则表达式。
"/pathvalue2" # 精确匹配前无需添加~*。
]
}
}]
name: ingress-example
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /test
pathType: Prefix
backend:
service:
name: service-a
port:
number: 88
支持Rewrite重写
当前ALB支持Rewrite重写,通过ALB Ingress只需要在注解中配置alb.ingress.kubernetes.io/rewrite-target: /path/${2}
即可。规则如下:
在
rewrite-target
注解中,${number}
类型的变量需要在路径为Prefix类型的path
上配置。path
默认无法配置正则符号,例如*
、?
等,您需要通过配置rewrite-target
注解使用正则符号。path
必须以/
开头。
ALB的Rewrite重写支持正则表达式替换,规则如下:
您可以在Ingress的
path
中写入一个或多个正则表达式,支持写入多个()
,但是rewrite-target
注解中重写路径最多可以配置${1}
、${2}
和${3}
变量中的一个或多个,最多可获取三个变量。Rewrite重写支持正则表达式匹配的结果作为参数自由组合,自由拼接出您想要的重写规则。
Rewrite重写通过正则表达式替换的逻辑是:客户端的请求匹配到正则表达式,正则表达式中有多个
()
,且rewrite-target
注解含有${1}
、${2}
和${3}
变量中的一个或多个。
例如Ingress的path
配置为/sys/(.*)/(.*)/aaa
,rewrite-target
注解配置为/${1}/${2}
。当客户端发送请求的路径为/sys/ccc/bbb/aaa
时,path
会匹配到/sys/(.*)/(.*)/aaa
,rewrite-target
注解生效会把${1}
替换为ccc
,${2}
替换为bbb
,最终后端服务器接收到的请求路径为/ccc/bbb
。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/use-regex: "true" # 允许path字段使用正则表达式。
alb.ingress.kubernetes.io/rewrite-target: /path/${2} # 该注解支持正则表达式替换。
name: rewrite-ingress
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /something(/|$)(.*)
pathType: Prefix
backend:
service:
name: rewrite-svc
port:
number: 9080
配置自定义监听端口
当前支持Ingress配置自定义监听端口。通过该方式,可以将服务同时暴露80端口和443端口,配置示例如下:
ALB不支持直接在Ingress中创建新的监听。为确保Ingress能够正常工作,您需要先在Albconfig中创建所需的监听端口和协议,然后在Ingress中将这些监听与服务关联起来。关于如何创建ALB监听,请参见通过ALBConfig配置ALB监听。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
spec:
ingressClassName: alb
tls:
- hosts:
- demo.alb.ingress.top
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /tea
pathType: ImplementationSpecific
backend:
service:
name: tea-svc
port:
number: 80
配置转发规则优先级
默认情况下,Ingress按照以下规则进行ALB转发规则优先级排序:
不同Ingress按照
namespace/name
的字典顺序优先级进行排列,字典顺序小的优先级高。同一个Ingress按照
rule
字段先后顺序进行排序,配置在上面的优先级高。
如果您不想修改Ingress的namespace/name
字段,可以配置以下Ingress注解定义ALB转发规则优先级:
同一个监听内规则优先级必须唯一。您可以使用alb.ingress.kubernetes.io/order
标识Ingress之间的优先级顺序,取值范围为1~1000,值越小表示优先级越高。Ingress默认标识为数字10,如果您想优先级更高,您可以调小数字。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/order: "2"
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /tea
pathType: ImplementationSpecific
backend:
service:
name: tea-svc
port:
number: 80
通过注解实现灰度发布
ALB提供复杂路由处理能力,支持基于Header、Cookie以及权重的灰度发布功能。灰度发布功能可以通过设置注解来实现,为了启用灰度发布功能,需要设置注解alb.ingress.kubernetes.io/canary: "true"
,通过不同注解可以实现不同的灰度发布功能:
灰度优先级顺序:基于Header>基于Cookie>基于权重(从高到低)。
灰度过程中不能删除原有的规则,否则会导致服务异常。待灰度验证无误后,将原有Ingress中的后端服务Service更新为新的Service,最后将灰度的Ingress删除。
alb.ingress.kubernetes.io/canary-by-header
和alb.ingress.kubernetes.io/canary-by-header-value
:匹配的Request Header的值,该规则允许您自定义Request Header的值,但必须与alb.ingress.kubernetes.io/canary-by-header
一起使用。当请求中的
header
和header-value
与设置的值匹配时,请求流量会被分配到灰度服务入口。对于其他
header
值,将会忽略header
,并通过灰度优先级将请求流量分配到其他规则设置的灰度服务。
当请求Header为
location: hz
时将访问灰度服务;其他Header将根据灰度权重将流量分配给灰度服务。配置示例如下:apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: alb.ingress.kubernetes.io/order: "1" alb.ingress.kubernetes.io/canary: "true" alb.ingress.kubernetes.io/canary-by-header: "location" alb.ingress.kubernetes.io/canary-by-header-value: "hz" name: demo-canary namespace: default spec: ingressClassName: alb rules: - http: paths: - backend: service: name: demo-service-hello port: number: 80 path: /hello pathType: ImplementationSpecific
alb.ingress.kubernetes.io/canary-by-cookie
:基于Cookie的流量切分。当配置的
cookie
值为always
时,请求流量将被分配到灰度服务入口。当配置的
cookie
值为never
时,请求流量将不会分配到灰度服务入口。
说明基于Cookie的灰度不支持设置自定义,只有
always
和never
。请求的Cookie为
demo=always
时将访问灰度服务。配置示例如下:apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: alb.ingress.kubernetes.io/order: "2" alb.ingress.kubernetes.io/canary: "true" alb.ingress.kubernetes.io/canary-by-cookie: "demo" name: demo-canary-cookie namespace: default spec: ingressClassName: alb rules: - http: paths: - backend: service: name: demo-service-hello port: number: 80 path: /hello pathType: ImplementationSpecific
alb.ingress.kubernetes.io/canary-weight
:设置请求到指定服务的百分比(值为0~100的整数)。配置灰度服务的权重为50%,示例如下:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: alb.ingress.kubernetes.io/order: "3" alb.ingress.kubernetes.io/canary: "true" alb.ingress.kubernetes.io/canary-weight: "50" name: demo-canary-weight namespace: default spec: ingressClassName: alb rules: - http: paths: - backend: service: name: demo-service-hello port: number: 80 path: /hello pathType: ImplementationSpecific
通过注解实现会话保持
ALB Ingress支持通过注解实现会话保持:
alb.ingress.kubernetes.io/sticky-session
:是否启用会话保持。取值:true
或false
;默认值:false
。alb.ingress.kubernetes.io/sticky-session-type
:Cookie的处理方式。取值:Insert
或Server
;默认值:Insert
。Insert
:植入Cookie。客户端第一次访问时,负载均衡会在返回请求中植入Cookie(即在HTTP或HTTPS响应报文中插入SERVERID),下次客户端携带此Cookie访问时,负载均衡服务会将请求定向转发给之前记录到的后端服务器。Server
:重写Cookie。负载均衡发现用户自定义了Cookie,将会对原来的Cookie进行重写,下次客户端携带新的Cookie访问时,负载均衡服务会将请求定向转发给之前记录到的后端服务器。
说明当前服务器组
StickySessionEnabled
为true
时,该参数生效。alb.ingress.kubernetes.io/cookie-timeout
:Cookie超时时间。单位:秒;取值:1~86400;默认值:1000
。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress-v3
annotations:
alb.ingress.kubernetes.io/sticky-session: "true"
alb.ingress.kubernetes.io/sticky-session-type: "Insert"
alb.ingress.kubernetes.io/cookie-timeout: "1800"
spec:
ingressClassName: alb
rules:
- http:
paths:
#配置Context Path。
- path: /tea2
backend:
service:
name: tea-svc
port:
number: 80
# 配置Context Path。
- path: /coffee2
backend:
service:
name: coffee-svc
port:
number: 80
指定服务器组负载均衡算法
ALB Ingress支持通过设置Ingress注解alb.ingress.kubernetes.io/backend-scheduler
指定服务器组负载均衡算法。配置示例如下(目前集群版本默认高于1.19):
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/backend-scheduler: "uch" # 此处的uch可按需配置为wrr、sch和wlc。
alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # 仅负载均衡算法为uch时,需要配置此参数。当调度算法为wrr、sch或wlc均无需配置此参数。
name: cafe-ingress
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /tea
pathType: ImplementationSpecific
backend:
service:
name: tea-svc
port:
number: 80
调度算法alb.ingress.kubernetes.io/backend-scheduler
取值说明:
wrr
:默认值,权重值越高的后端服务器,被轮询到的概率也越高。wlc
:根据每台后端服务器设定的权重值和后端服务器的实际负载(即连接数)进行轮询。当权重值相同时,当前连接数越小的后端服务器被轮询到的概率越高。sch
:源IP一致性Hash。uch
:URL参数一致性Hash。ALB Ingress支持服务器组负载均衡算法为uch
时,通过注解alb.ingress.kubernetes.io/backend-scheduler-uch-value
指定URL参数进行一致性Hash。
跨域配置
当前ALB Ingress支持跨域配置示例如下:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: alb-ingress
annotations:
alb.ingress.kubernetes.io/enable-cors: "true"
alb.ingress.kubernetes.io/cors-expose-headers: ""
alb.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
alb.ingress.kubernetes.io/cors-allow-credentials: "true"
alb.ingress.kubernetes.io/cors-max-age: "600"
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: cloud-nodeport
port:
number: 80
参数 | 说明 |
| 允许通过浏览器访问服务器资源的站点。站点之间使用英文半角逗号(,)分割。 单个value值必须以http://或者https://开头后跟一个正确域名,或者一级的泛域名。 默认值: |
| 允许跨域方法,不区分大小写。跨域方法之间使用英文半角逗号(,)分割。 默认值: |
| 允许跨域传播的请求头,只能输入字母、数字、下划线(_)和短划线(-)。请求头之间使用英文半角逗号(,)分割。 默认值: |
| 允许暴露的Header列表,允许输入字母、数字、下划线(_)、短划线(-)和星号(*)。Header之间使用英文半角逗号(,)分割。 默认值: |
| 设置跨域访问时是否允许携带凭证信息。 默认值: |
| 对于非简单请求,设置OPTIONS预检请求在浏览器的最大缓存时间(秒),取值范围[-1,172800]。 默认值: |
后端长连接
传统的负载均衡会采用短链接的方式访问后端服务器组,每一条请求都需要经历TCP层面的建立连接和断开连接,使网络连接成为这类高性能系统的瓶颈,通过负载均衡的后端长连接支持,极大地减少了处理连接层面的资源消耗,以此大幅度提高处理性能。当前在ALB Ingress中可以通过注解alb.ingress.kubernetes.io/backend-keepalive
开启后端长连接。参考示例如下:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: alb-ingress
annotations:
alb.ingress.kubernetes.io/backend-keepalive: "true"
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: cloud-nodeport
port:
number: 80
支持QPS限速
ALB本身支持转发规则的QPS限速功能,限速值要求在1~100000之间。当前在ALB Ingress只需要设置alb.ingress.kubernetes.io/traffic-limit-qps
注解即可。参考示例如下:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/traffic-limit-qps: "50"
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /tea
pathType: ImplementationSpecific
backend:
service:
name: tea-svc
port:
number: 80
- path: /coffee
pathType: ImplementationSpecific
backend:
service:
name: coffee-svc
port:
number: 80