Hello,
Running ServiceMesh by an largely based on ‘learn-counsul-get-started’ and ‘learn-consul-api-gateways’ GitHub repos as references.
I’m trying to do a blue/green or versioned deployment of services. I have created the following Router/resolver entries for v1 and v2 of echo service. (Using K8s crd’s to define them).
apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceRouter
metadata:
name: echo-1
namespace: default
spec:
routes:
- match:
http:
pathPrefix: /echov1
destination:
service: echo-1
serviceSubset: v1
- match:
http:
pathPrefix: /echov2
destination:
service: echo-1
serviceSubset: v2
- match:
http:
pathPrefix: /echo
destination:
service: error-1
- match:
http:
pathPrefix: /
destination:
service: error-1
---
apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceResolver
metadata:
name: echo-1
spec:
defaultSubset: v1
subsets:
v1:
#filter: 'Service.Tags contains v1'
#filter: 'Service.Meta.version == 1'
filter: 'Service.Meta.version == 1'
v2:
#filter: 'Service.Tags contains v2'
filter: 'Service.Meta.version == 2'
From another POD in the mesh, it all works /echov1 and /echov2 go to correct versions of service and anything else gets an error.
This service is meant to be exposed as REST service so I have created a consul API gateway, which has the following definition:
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: httproute-echo
namespace: default
spec:
parentRefs:
- name: api-gateway
namespace: consul
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- name: echo-1
kind: Service
This does not work all api calls go to V1 (the default) regardless of path specified.
In the consul UI this is the service route diagram:
The last route appears to be the problem, this is the default route that is added on pod creation and this appears to be the only route used when the service is called by API gateway.
The pods are created pretty simply, and I cannot find an annotation that will shut off this default route.
---
apiVersion: apps/v1
kind: Deployment
metadata:
#labels:
# app: echo-1
name: echo-1-v2
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: echo-1
version: v2
template:
metadata:
labels:
app: echo-1
version: v2
annotations:
'consul.hashicorp.com/connect-inject': 'true'
'consul.hashicorp.com/service-tags': 'v2'
'consul.hashicorp.com/service-meta-version': '2'
spec:
serviceAccountName: echo-1
containers:
- image: k8s.gcr.io/ingressconformance/echoserver:v0.0.1
name: echo-1
env:
- name: SERVICE_NAME
value: echo-1-v2
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
ports:
- containerPort: 3000
In one of the Hashi Learn-Counsul-* repos, they have avoided this issue by having API gateway route to an nginx pod, that then routes into the service mesh, but this seems wrong to me.
Is there a way to have an HTTPRoute to API gateway follow service routing and resolving patterns, or to remove the ‘default route’?
Thanks,
Steve Dillon