upstream connect error or disconnect/reset before headers. reset reason: connection failure - istio

I'm facing this issue upstream connect error or disconnect/reset before headers. reset reason: connection failure here the my deployment and service file
apiVersion: v1
kind: Service
metadata:
name: project
labels:
app: project
service: project
spec:
ports:
- port: 9080
name: http
selector:
app: project
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: project-svc
labels:
account: project
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: project-v1
labels:
app: project
version: v1
spec:
replicas: 1
selector:
matchLabels:
app: project
version: v1
template:
metadata:
labels:
app: project
version: v1
spec:
serviceAccountName: project-svc
containers:
- name: project
image: segullshairbutt/website:admin_project_a_01_cl1_wn1_pod1_c4
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
and here are the Gateway and virtualservice
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: project-gateway
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: projectinfo
spec:
hosts:
- "*"
gateways:
- project-gateway
http:
- match:
- uri:
exact: /productpage
route:
- destination:
host: project
port:
number: 9080
when i visit using minikube-ip:istio-engress i get this error but when I just change the image from my to bookinfo product-page ther nothing this error. I don't know why this is and from where.
Please help me I'll be very thankful to you!

Related

Ingress Nginx giving 503 on digital ocean

I have a simple configuration of a deployment, service and ingress service
app-depl.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-depl
spec:
replicas: 1
selector:
matchLabels:
app: app
template:
metadata:
labels:
app: app
spec:
containers:
- name: app
image: keysoutsourcedocker/app
---
apiVersion: v1
kind: Service
metadata:
name: app-srv
spec:
selector:
app: app
ports:
- name: app
protocol: TCP
port: 3000
targetPort: 3000
ingress-srv.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-service
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/use-regex: 'true'
spec:
rules:
- host: www.keyssoft.xyz
http:
paths:
- path: /?(.*)
pathType: Prefix
backend:
service:
name: app-srv
port:
number: 3000
And my DNS config goes like this
enter image description here
But when i try to access www.keyssoft.xyz i get this 503 error
enter image description here
I've been on this for the past 14 hours. Any help would be appreciated.

Istio traffic routing rules take no effect

I am trying to configure a request routing using Istio and Ingress-nginx but I'm not able to route the requests properly. Basically I have two deployments each as a different subset and implemented a weighted VirtualService.
In Kiali dashboard it shows the request being routed from the ingress-controller to PassthroughCluster even though I can see the correct route mapping using istioctl proxy-config routes command.
Here is the complete configuration:
apiVersion: v1
kind: ServiceAccount
metadata:
name: dummy-app
namespace: my-namespace
---
apiVersion: v1
kind: Service
metadata:
name: dummy-app
namespace: my-namespace
labels:
app: dummy-app
service: dummy-app
spec:
ports:
- port: 8080
targetPort: 8080
name: http-web
selector:
app: dummy-app
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: dummy-app-1
namespace: my-namespace
spec:
replicas: 1
selector:
matchLabels:
app: dummy-app
version: v1
template:
metadata:
annotations:
sidecar.istio.io/inject: "true"
labels:
app: dummy-app
version: v1
spec:
serviceAccountName: dummy-app
containers:
- image: my-img
imagePullPolicy: IfNotPresent
name: dummy-app
env:
- name: X_HTTP_ENV
value: dummy-app-1
ports:
- containerPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: dummy-app-2
namespace: my-namespace
spec:
replicas: 1
selector:
matchLabels:
app: dummy-app
version: v2
template:
metadata:
annotations:
sidecar.istio.io/inject: "true"
labels:
app: dummy-app
version: v2
spec:
serviceAccountName: dummy-app
containers:
- image: my-img
imagePullPolicy: IfNotPresent
name: dummy-app
env:
- name: X_HTTP_ENV
value: dummy-app-2
ports:
- containerPort: 8080
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: dummy-app
namespace: my-namespace
spec:
host: dummy-app
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: dummy-app
namespace: my-namespace
spec:
hosts:
- dummy-app.my-namespace.svc.cluster.local
http:
- match:
- uri:
prefix: "/my-route"
route:
- destination:
host: dummy-app.my-namespace.svc.cluster.local
subset: v1
weight: 0
- destination:
host: dummy-app.my-namespace.svc.cluster.local
subset: v2
weight: 100
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: "my-ingress-class"
nginx.ingress.kubernetes.io/service-upstream: "true"
nginx.ingress.kubernetes.io/upstream-vhost: dummy-app.my-namespace.svc.cluster.local
name: dummy-ingress
namespace: my-namespace
spec:
rules:
- host: myapp.com
http:
paths:
- backend:
service:
name: dummy-app
port:
number: 8080
path: /my-route(.*)
pathType: ImplementationSpecific
Weird thing is I have other applications working in the same namespace and using the same ingress-controller, so I'm not considering there is a problem with ingress-nginx setup.
Istio version:
client version: 1.11.4
control plane version: 1.11.4
data plane version: 1.11.4 (13 proxies), 1.12-dev (15 proxies)
Any ideas on what is the configuration problem or how can I better debug these kind of issues in Istio?
Main issue seems to be with ingress-nginx resource. Based on the above ingress definition, you are trying to bypass istio ingress gateway (where all the proxying rules has been implemented, like gateway,virtual-service and destination rules) and directly pushing the traffic to the application service from ingress. For istio proxy rules to work, you should let traffic pass through istio-ingressgateway (a service under istio-system namespace). So following changes should be made to your ingress resource:
rules:
- host: myapp.com
http:
paths:
- backend:
service:
name: istio-ingressgateway.istio-system
port:
number: 80
path: /my-route(.*)
pathType: ImplementationSpecific

Istio spec/hosts don't work in non-default namespace

I have the following for stg namespace:
apiVersion: v1
kind: Service
metadata:
name: nginx
namespace: stg
labels:
app: nginx
spec:
ports:
- port: 80
name: http
selector:
app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: stg
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: gateway
namespace: stg
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- '*'
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: nginx-1
namespace: stg
spec:
hosts:
- "*"
gateways:
- gateway
http:
- route:
- destination:
host: nginx
port:
number: 80
I need spec/hosts to be app1.my.domain instead of *
It works fine in default namespace but not in stg namespace
stg namespace has istio-injection=enabled
Any ideas why it doesn't work and how to fix it?

Allow service-level-access only from IstioGateway/Virtual Service

We have an api service which should be accessible only by a particular Istio gateway/virtual service.
Can this be achieved by istio's AuthorizationPolicy?
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-all
namespace: selfserviceportal
spec:
{}
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: api-server-svc
namespace: selfserviceportal
spec:
rules:
- from:
- source:
# How do I reference the istio gateway/virtual service here?
to:
- operation:
methods:
- GET
selector:
matchLabels:
app: api-server-svc
This is the gateway which should be allowed:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: api-server-gateway
spec:
selector:
istio: ingressgateway # use Istio default gateway implementation
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "ssp-api-server.internalroot.net"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: api-server-vservice
spec:
hosts:
- "ssp-api-server.internalroot.net"
gateways:
- api-server-gateway
http:
- match:
- uri:
prefix: /api
route:
- destination:
port:
number: 8000
host: api-server-svc

istio route rule error: "json: cannot unmarshal string into Go value"

I'm new to Istio and I'm going through some uses cases with my simple app.
I deployed 2 simple services on minikube running on Windows 10 Pro with VirtualBox 5.2.6, with istio 0.6.0
Version v1 of service1 and v1 & v2 of service2.
service1 responds to /hello and service2 responds to /world. Everything working fine so far and both services are responsding and as of service2, the round robin is working.
Now I want to apply 2 route rules, one to route to v2 of service2 based on a header and the rest to v1 of service2, but when I try to do that I get an error:
Error: cannot parse proto message: YAML decoding error: destination:
name: service2
match:
request:
headers:
Foo: bar
precedence: 2
route:
- labels:
version: v2
json: cannot unmarshal string into Go value of type map[string]json.RawMessage
Please find below my app and route rules config.
What's wrong with this config?
Please notice that when I omit the "match" part it's OK, but of course this is not what I want.
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
name: service2-route
spec:
destination:
name: service2
precedence: 2
match:
request:
headers:
Foo: bar
route:
- labels:
version: v2
---
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
name: service2-default
spec:
destination:
name: service2
precedence: 1
route:
- labels:
version: v1
weight: 100
and the my services deployment yaml:
###########################################################################
# Service 1
##########################################################################
apiVersion: v1
kind: Service
metadata:
name: service1
labels:
app: service1
spec:
ports:
- port: 8080
name: http
selector:
app: service1
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: service1-v1
spec:
replicas: 1
template:
metadata:
labels:
app: service1
version: v1
spec:
containers:
- name: service1
image: myrepo/sampleapp-service1:latest
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
---
###########################################################################
# Service 2
##########################################################################
apiVersion: v1
kind: Service
metadata:
name: service2
labels:
app: service2
spec:
ports:
- port: 8081
name: http
selector:
app: service2
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: service2-v1
spec:
replicas: 1
template:
metadata:
labels:
app: service2
version: v1
spec:
containers:
- name: service2
image: myrepo/sampleapp-service2:latest
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8081
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: service2-v2
spec:
replicas: 1
template:
metadata:
labels:
app: service2
version: v2
spec:
containers:
- name: service2
image: myrepo/sampleapp-service2:latest
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8081
---
###########################################################################
# Ingress resource (gateway)
##########################################################################
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: gateway
annotations:
kubernetes.io/ingress.class: "istio"
spec:
rules:
- http:
paths:
- path: /hello
backend:
serviceName: service1
servicePort: 8080
- path: /world
backend:
serviceName: service2
servicePort: 8081
---
The problem here is pretty simple, you have to say how do you want to match your header. In your example, I can assume that you want an exact match, so the following syntax:
match:
request:
headers:
Foo:
exact: bar
Here you can find more available options.
Also I would recommend to use quotes if your header value contains any special characters.