I am running k3s version 1.25.5 and I would like to define traefik as an ingress for one of the services defined through an external helm chart. I am struggling to find the right ingress definition. I tried with the below yaml file but that gives an error stating
error: resource mapping not found for name: "c8-ingress" namespace: "" from "zeebe-traefik.yaml": no matches for kind "Ingress" in version "extensions/v1beta1"
ensure CRDs are installed first
This seems to be because of the an old apiVersion used in the yaml file. How to do it the right way?
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: c8-ingress
annotations:
kubernetes.io/ingress.class: "traefik"
spec:
rules:
- http:
paths:
- path: "/"
backend:
serviceName: dev-zeebe-gateway
servicePort: 26500
Thanks.
Your example is using an outdated Ingress definition. In v1.25.x you need to use the stable networking.k8s.io/v1 API, as described here.
It is also recommended to provide the fitting namespace. This is useful for documentation, but also required for resource backends. It will also avoid adding -n YOURNAMESPACE to every kubectl apply.
In your case, this may look something like:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: c8-ingress
namespace: YOURNAMESPACE
spec:
rules:
- http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: dev-zeebe-gateway
port:
number: 26500
I hope this helps to solve your issue.
In many cases, you can run kubectl explain RESOURCE to get useful links and resources for a given api-resource.
Related
I am trying to deploy Jaeger all-in-one image in a kubernetes cluster.
Jaeger is not in the root of the url, meaning it's accessible through https://somedomain.com/xyz/jaeger
I have an ingress rule which seems to be pointing correctly to a Service which is also referencing fine the pod in a deployment (I can see all this in Rancher UI).
But somehow when I try to access, nginx is throwing a 502 Bad Gateway error.
This is how the ingress rule looks like
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
namespace: my-namespace
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
rules:
- host: somedomain.com
http:
# Jaeger
- path: /xyz/jaeger(/|$)(.*)
pathType: Prefix
backend:
service:
name: jaeger
port:
number: 16868
Then in the pod definition I tried using the QUERY_BASE_PATH env var setting it to /xyz/jaeger but that made no difference at all.
The problem was an incorrect port being specified.
16868 instead of 16686
error: resource mapping not found for name: "ingress-srv" namespace: "" from "ingress-srv.yaml": no matches for kind "Ingress" in version "networking.k8s.io/v1beta1"
ensure CRDs are installed first
I am new to Kubernetes, I was setting up ingress nginx on minikube and it installed successfully but when I try to run using kubectl apply -f filename it gives above error
here is the code
filename: ingress-srv.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ingress-srv
annotations:
kubernetes.io/ingress.class: nginx
spec:
rules:
- host: posts.com
http:
paths:
- path: /posts
pathType: Prefix
backend:
serviceName: posts-clusterip-srv
servicePort: 4000
The resource type specified in your manifest, networking.k8s.io/v1beta1 Ingress, was removed in Kubernetes v1.22 and replaced by networking.k8s.io/v1 Ingress (see the deprecation guide for details). If your cluster's Kubernetes server version is 1.22 or higher (which I suspect it is) trying to create an Ingress resource from your manifest will result in exactly the error you're getting.
You can check your cluster's Kubernetes server version (as Kamol Hasan points out) using the command kubectl version --short.
If the version is indeed 1.22 or higher, you'll need to modify your YAML file so that its format is valid in the new version of the API. This pull request summarises the format differences. In your case, ingress-srv.yaml needs to be changed to:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-srv
annotations:
kubernetes.io/ingress.class: nginx
spec:
rules:
- host: posts.com
http:
paths:
- path: /posts
pathType: Prefix
backend:
service:
name: posts-clusterip-srv
port:
number: 4000
When I am trying to create an ingress resource for my Kubernetes cluster(ingress controller is already created), Ingress resource/rules are creating and I am able to see in the kubectl get ing.
But when I do kubectl describe, I am seeing a error:
Default backend: default-http-backend:80 (<error: endpoints
“default-http-backend” not found>)
Is this expected?? I am not even able to connect to my application using the DNS name (hotel.example.com) which I defined in Ingress resource. Is it due to this http-backend error?
If not, any suggestions to make the application connect!!
[dockuser#hostname]$ kubectl describe ing hotel-ingress -n hotel
Name: hotel-ingress
Namespace: hotel
Address:
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
Host Path Backends
---- ---- --------
hotel.example.com
/ hotel-svc:80 (10.36.0.2:80,10.44.0.2:80)
Annotations:
Events:
deployment files:
namespaces.yaml
apiVersion: v1
kind: Namespace
metadata:
name: hotel
ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: hotel-ingress
namespace: hotel
spec:
rules:
- host: hotel.example.com
http:
paths:
- path: /
backend:
serviceName: hotel-svc
servicePort: 80
deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: hotel
namespace: hotel
spec:
replicas: 2
selector:
matchLabels:
app: hotel
template:
metadata:
labels:
app: hotel
spec:
containers:
- name: hotel
image: nginxdemos/hello:plain-text
ports:
- containerPort: 80
service.yaml
apiVersion: v1
kind: Service
metadata:
name: hotel-svc
namespace: hotel
spec:
selector:
app: hotel
ports:
- port: 80
targetPort: 80
You may want add defaultBackend as a part of your Ingress definition like so
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: default-backend-ingress-example
spec:
defaultBackend:
service:
name: hotel-svc
port:
number: 80
Environment
minikube version: v1.21.0
kubectl version: v1.20.7
I realize this was answered (adding for posterity,) however in my case I had already ran
minikube addons enable ingress
but system was still missing default-http-backend.
I suspect that at the time there had been a conflicting use of a port or some such and the default-http-backend silently failed to be created.
After many attempts to correct the issue I finally discovered that executing the following commands fixed the issue for me:
[update 2021-12-15]
original resources no longer available, sorry
If I had to do this again today I would probably try to apply a deployment directly from the ingress-nginx project:
kubectl apply -f https://github.com/kubernetes/ingress-nginx/tree/main/deploy/static/provider/baremetal/deploy.yaml
(not tested)
PS: Note that there already were configmaps present for nginx-load-balancer-conf so I didn't add those.
PPS: Secondly, this was just for education on a local laptop so take its trustworthiness with a grain of salt.
If you are using Minikube, it may be because you haven't enabled ingress.
Please try the command below:
minikube addons enable ingress
or
minikube addons enable ingress --alsologtostderr
The answer in my case was found here, which is that the ingress rule needs to be created in the same namespace as the service rule(s) its referencing. Or else, as discussed in the same thread, one must find a way to include the namespace as part of the reference to that service.
Instead of creating the ingress your-ingress-name in ingress-nginx namespace you should create it in the namespace where you have the service...
Possible solution if you're getting this result:
kubectl describe ingress your-ingress-name
...
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
I tried following this doc steps and it worked fine:
https://kubernetes.io/docs/tasks/access-application-cluster/ingress-minikube/
I think missing default backend can be ignored. At least it is not required for Openshift-style routes with load-balancing work under k8s, as described in this answer.
Create default-http-backend service in kube-system namespace and error will be gone.
See more: ngress-nginx-troubleshooting.
I have installed Harbor as follows:
helm install hub harbor/harbor \
--version 1.3.2 \
--namespace tool \
--set expose.ingress.hosts.core=hub.service.example.io \
--set expose.ingress.annotations.'kubernetes\.io/ingress\.class'=istio \
--set expose.ingress.annotations.'cert-manager\.io/cluster-issuer'=letsencrypt-prod \
--set externalURL=https://hub.service.example.io \
--set notary.enabled=false \
--set secretkey=secret \
--set harborAdminPassword=pw
Everything is up and running but the page is not reachable via https://hub.service.example.io. The same problem occurs here Why css and png are not accessible? but how to set wildcard * in Helm?
Update
Istio supports ingress gateway. This for example works without Gateway and VirtualService definition:
apiVersion: v1
kind: Service
metadata:
name: hello-kubernetes-first
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 8080
selector:
app: hello-kubernetes-first
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-kubernetes-first
spec:
replicas: 3
selector:
matchLabels:
app: hello-kubernetes-first
template:
metadata:
labels:
app: hello-kubernetes-first
spec:
containers:
- name: hello-kubernetes
image: paulbouwer/hello-kubernetes:1.8
ports:
- containerPort: 8080
env:
- name: MESSAGE
value: Hello from the first deployment!
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: istio
name: helloworld-ingress
spec:
rules:
- host: "hw.service.example.io"
http:
paths:
- path: "/*"
backend:
serviceName: hello-kubernetes-first
servicePort: 80
---
I would say it won't work with ingress and istio.
As mentioned here
Simple ingress specifications, with host, TLS, and exact path based matches will work out of the box without the need for route rules. However, note that the path used in the ingress resource should not have any . characters.
For example, the following ingress resource matches requests for the example.com host, with /helloworld as the URL.
$ kubectl create -f - <<EOF
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: simple-ingress
annotations:
kubernetes.io/ingress.class: istio
spec:
rules:
- host: example.com
http:
paths:
- path: /helloworld
backend:
serviceName: myservice
servicePort: grpc
EOF
However, the following rules will not work because they use regular expressions in the path and ingress.kubernetes.io annotations:
$ kubectl create -f - <<EOF
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: this-will-not-work
annotations:
kubernetes.io/ingress.class: istio
# Ingress annotations other than ingress class will not be honored
ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: example.com
http:
paths:
- path: /hello(.*?)world/
backend:
serviceName: myservice
servicePort: grpc
EOF
I assume your hello-world is working because of just 1 annotation which is ingress class.
If you take a look at annotations of harbor here, it might be the problem when you want to use ingress with istio.
but how to set wildcard * in Helm?
Wildcard have nothing to do here. As I mentioned in this answer you can use either wildcard or additional paths, which is done well. Take a look at the ingress paths here.
https://github.com/goharbor/harbor-helm/blob/master/templates/ingress/ingress.yaml#L5
If you look here, they have the path hardcoded to a couple ingress options. Envoy/istio isn't one of them. However, you may be in luck- expose.ingress.controller set to "gce" seems to set the paths the way you need them to be. (I've never used gce, maybe they even use istio?)
Edit- original answer is below. Apparently there is an ingress controller you can enable in istio. There are absolutely no docs on it, but what should I expect?
In your case though, helm is not your problem. istio doesn't use ingress objects, it uses 'Gateways' and 'VirtualServices'. You can't configure an app to use the istio ingress system using kubernetes.io/ingress.class annotations.
(at least, that has been my experience, and I can't find anything to contradict that in their docs, but it is completely possible there is an istio ingress controller tha
I am trying to add multiple Ingresses which should share the same host.
One Ingress should handle requests to www.example.de/some and the one all other requests.
Here is a snipped with the Ingress configurations
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: some-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: "www.example.de"
http:
paths:
- path: "/some"
backend:
serviceName: some-svc
servicePort: 8585
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: other-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: "www.example.de"
http:
paths:
- backend:
serviceName: other-svc
servicePort: 8080
As an ingress-controller I installed the nginx-stable/nginx-ingress via Helm
helm install my-ingress nginx-stable/nginx-ingress
When attempting to create the two Ingresses from above only one is working when trying to access www.example.de (this is mapped to 127.0.0.1 in my /etc/hosts).
In the nginx-ingress log is see the following warnings:
2020/01/08 09:33:51 [warn] 560#560: conflicting server name "www.example.de" on 0.0.0.0:80, ignored
2020/01/08 09:33:51 [warn] 560#560: conflicting server name "www.example.de" on 0.0.0.0:443, ignored
Turns out that I was using the wrong nginx-ingress controller. The nginxinc/kubernetes-ingress controller does not support merging Ingress rules with the same host (only via Mergeable Ingresses).
Instead the kubernetes/ingress-nginx should be used.
The differences between these controllers are listed here.
Deleting the old controller and installing kubernetes/ingress-nginx instead using the following command fixed the problem.
helm install my-nginx stable/nginx-ingress
See https://kubernetes.github.io/ingress-nginx/deploy/#using-helm
Just to compliment Brass' reply by referring to the docs:
If multiple Ingresses define different paths for the same host, the ingress controller will merge the definitions.