Nats streaming visible on GCP web preview but not from Nats service - kubernetes

I have configured a Nats deployment as below on GCP
apiVersion: apps/v1
kind: Deployment
metadata:
name: nats-depl
spec:
replicas: 1
selector:
matchLabels:
app: nats
template:
metadata:
labels:
app: nats
spec:
containers:
- name: nats
image: nats-streaming:0.17.0
args: [
'-p',
'4222',
'-m',
'8222',
'-hbi',
'5s',
'-hbt',
'5s',
'-hbf',
'2',
'-SD',
'-cid',
'BPB_MEAN_FRAMEWORK'
]
---
apiVersion: v1
kind: Service
metadata:
name: nats-srv
spec:
selector:
app: nats
ports:
- name: client
protocol: TCP
port: 4222
targetPort: 4222
- name: monitoring
protocol: TCP
port: 8222
targetPort: 8222
My ingress yaml looks like below
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-service
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/use-regex: 'true'
spec:
rules:
- host: blog.dev
http:
paths:
- path: /api/users/?(.*)
backend:
serviceName: auth-srv
servicePort: 3100
- path: /nats/?(.*)
backend:
serviceName: nats-srv
servicePort: 4222
- path: /api/posts/?(.*)
backend:
serviceName: posts-srv
servicePort: 3100
- path: /?(.*)
backend:
serviceName: client-srv
servicePort: 80
I have followed the steps mentioned below to setup an ingress NGINX
Steps for setting up Ingress-NGINX
Create a project blog-dev
Create cluster blog-dev with 3 N1-g1 small instances in us-central1-c zone
Navigate to https://kubernetes.github.io/ingress-nginx/deploy/#gce-gke
On the Google cloud account, open the cloud shell and navigate to BPB_MEAN_Framework directory in terminal
Execute the command gcloud init, reinitialize the cluster, select the account, project and the region
Execute the command gcloud container clusters get-credentials blog-dev
Execute the command kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.3/deploy/static/provider/cloud/deploy.yaml to configure ingress-nginx
Go to Network Services -> Load Balancing and check that the Load Balancer has got created. Note the ip of the Load Balancer
Open the hosts.ini file and update as shown below
130.211.113.34 blog.dev
8.1) Type the command
"kubectl create secret generic jwt-secret --from-literal=JWT_KEY=asdf"
Run scaffold dev
I do a
kubectl get pods
kubectl port-forward pod-name 8222:8222
After the configuration of the cluster, I try to open http://nats-srv:8222 in browser and it gives me a page not displayed.
When I try to do a web preview, I get the NATS landing page as shown below
NATS using web preview
Please let me know how I get this to display using something like http://nats-srv:8222 where
'nats-srv' is my service which is currently a cluster-IP service.

Related

K3s traefik ingress returns gateway timeout

I am currently playing around with a rpi based k3s cluster and I am observing a weird phenomenon.
I deployed two applications.
The first one is nginx which I can reach on the url http://external-ip/foo based on the following ingress rule:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: foo
namespace: foo
annotations:
kubernetes.io/ingress.class: traefik
traefik.ingress.kubernetes.io/rule-type: "PathPrefixStrip"
traefik.ingress.kubernetes.io/rewrite-target: "/"
spec:
rules:
- http:
paths:
- path: /foo
backend:
serviceName: foo-service
servicePort: 8081
And the other one is grafana which I cannot reach on the url http://external-ip/grafana based on the below ingress rule:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: grafana
namespace: grafana
annotations:
kubernetes.io/ingress.class: traefik
traefik.ingress.kubernetes.io/rule-type: "PathPrefixStrip"
traefik.ingress.kubernetes.io/rewrite-target: "/"
spec:
rules:
- http:
paths:
- path: /grafana
backend:
serviceName: grafana-service
servicePort: 3000
When I do a port-forward directly on the pod I can reach the grafana app, when I use the port-forward on the grafana service it also works.
However as soon as I try to reach it through the subpath I will get a gateway timeout.
Does anyone have a guess what I am missing?
Here the deployment and service for the grafana deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: grafana
namespace: grafana
labels:
app: grafana
tier: frontend
service: monitoring
spec:
selector:
matchLabels:
app: grafana
tier: frontend
template:
metadata:
labels:
app: grafana
tier: frontend
service: monitoring
spec:
containers:
- image: grafana
imagePullPolicy: IfNotPresent
name: grafana
envFrom:
- configMapRef:
name: grafana-config
ports:
- name: frontend
containerPort: 3000
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
name: grafana-service
namespace: grafana
labels:
app: grafana
tier: frontend
service: monitoring
spec:
selector:
app: grafana
tier: frontend
type: NodePort
ports:
- name: frontend
port: 3000
protocol: TCP
targetPort: 3000
Solution
I had to add the following two parameters to my configmap to make it work:
GF_SERVER_ROOT_URL=http://localhost:3000/grafana/
GF_SERVER_FROM_SUB_PATH=true
As I mentioned in comments grafana is not listening on / like default nginx.
There is related github issue about this, and if you want to make it work you should specify root_url
grafana.ini:
server:
root_url: https://subdomain.example.com/grafana
Specifically take a look at this and this comment.
#tehemaroo add his own solution which include changing root url and sub_path in configmap
I had to add the following two parameters to my configmap to make it work:
GF_SERVER_ROOT_URL=http://localhost:3000/grafana/
GF_SERVER_FROM_SUB_PATH=true
And related documentation about that
To serve Grafana behind a sub path:
Include the sub path at the end of the root_url.
Set serve_from_sub_path to true.
[server]
domain = example.com
root_url = %(protocol)s://%(domain)s:%(http_port)s/grafana/
serve_from_sub_path = true

Why isn't my ingress controller route traffic from my external IP to the service in my cluster?

I have a cluster on Digital Ocean. 1 master with 2 nodes.
I'm using the Nginx Controller with the Digital Ocean Load Balancer.
Three Items in my Ingress Service Work fine. The fourth where I use Nginx Doesn't.
Does anyone know why?
Here are the configs. I left out the Ingress Services for the 1st through 3rd Deployments that are working. I can add them if needed.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: hello-kubernetes-ingress
annotations:
kubernetes.io/ingress.class: nginx
spec:
rules:
- host: hw1.example.com
http:
paths:
- backend:
serviceName: hello-kubernetes-first
servicePort: 80
- host: hw2.example.com
http:
paths:
- backend:
serviceName: hello-kubernetes-second
servicePort: 80
- host: hw3.example.com
http:
paths:
- backend:
serviceName: hello-kubernetes-third
servicePort: 80
- host: hw4.example.com
http:
paths:
- backend:
serviceName: hello-kubernetes-fourth
servicePort: 80
apiVersion: v1
kind: Service
metadata:
name: hello-kubernetes-fourth
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 8080
selector:
app: hello-kubernetes-fourth
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-kubernetes-fourth
spec:
replicas: 3
selector:
matchLabels:
app: hello-kubernetes-fourth
template:
metadata:
labels:
app: hello-kubernetes-fourth
spec:
containers:
- name: nginx
image: nginx:1.8
ports:
- containerPort: 8080
First of all ,if you use the nginx image, the container Port should be the one exposed by the Dockerfile of the image.
For the nginx image the ContainerPort should be port 80
https://hub.docker.com/layers/nginx/library/nginx/stable/images/sha256-cab8e4374e1e32bac58a8c7ae96c252cadcb1049545ed4bb3e3bfd5d087983b9
Now you should test if the nginx is available by accessing the podip:containerPort from the minikube node:
kubectl get po -o wide
hello-kubernetes-fourth-cb4fb668c-7tkd4 1/1 Running 0 25m 172.17.0.12
curl 172.17.0.12
After this, you should modify the ports of the service : targetPort should match the containerPort (80) and port 8080
Now access the Nginx by service URL:
kubectl describe svc hello-kubernetes-fourth
curl ClusterIP:8080
If OK, modify also the servicePort of the ingress to match the Service Port. Don't forget to enable the ingress, as it is disabled by default on minikube:
minikube addons enable ingress
* ingress was successfully enabled
after ingress pod is up, and adding in your host machine the MINIKUBEIP hw4.example.com in your /etc/hosts, you should be able to curl from the host machine:
curl hw4.example.com
The deployment configuration is incorrect. update the YAMLs as shown below
apiVersion: v1
kind: Service
metadata:
name: hello-kubernetes-fourth
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 80
selector:
app: hello-kubernetes-fourth
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-kubernetes-fourth
spec:
replicas: 3
selector:
matchLabels:
app: hello-kubernetes-fourth
template:
metadata:
labels:
app: hello-kubernetes-fourth
spec:
containers:
- name: nginx
image: nginx:1.8
ports:
- containerPort: 80
get inside nginx pod and verify that you are able to reach the service and getting the response
curl http://hello-kubernetes-fourth
Then you should be able to reach the service from ingress.

externally access the application using hostname/subdomain in ingress resource

Need to access the application from external using Ingress hostname/sub-domain for the application that is specified in the below code. eg. test-app.dev-cluster-poc.company.domain.
cat app-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
name: app-ingress
spec:
rules:
- host: test-app.dev-cluster-poc.company.domain
http:
paths:
- backend:
serviceName: appsvc1
servicePort: 80
path: /app1
- backend:
serviceName: appsvc2
servicePort: 80
path: /app2
While troubleshooting using steps in the url, I found that there is no ADDRESS in the "kubectl get ingress" output. expecting an ip address like below.
but, I am seeing like below, 3rd column is empty.
what are the necessary configuration required to externally access the application like registering the hostname(test-app.dev-cluster-poc.company.domain) or adding A-record or running any dns service in the kubernetes cluster.
what is causing the ADDRESS column empty in "kubectl get ingress" command.
[EDIT]
apiVersion: v1
kind: Service
metadata:
name: appsvc1
namespace: ingress
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: app1
Nginx controller service like below.
cat nginx-ingress-controller-service.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-ingress
namespace: ingress
spec:
type: NodePort
ports:
- port: 80
nodePort: 30000
name: http
- port: 18080
nodePort: 32000
name: http-mgmt
selector:
app: nginx-ingress-lb
1.you can deploy an ingress deployment
2.expose your ingress deployment through port 80
kubectl expose deploy your-deployment-name --port 80
source
3.you can add ingressClassName in your deploy
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-ingress
namespace: ingress
spec:
ingressClassName: nginx
ingress configuration sample

Botpress behind a Nginx reverse proxy

I am thinking of setting up multiple chatbots as in a containerized platform lets say docker or Kubernetes, and I would want to be able to access these chatbots through a reverse proxy such as Nginx. any help is appreciated.
My example scenario
I have a multiple chatbots, lets call them Bravo, Charlie, Delta
Bravo's IP address and port is 10.0.0.2:8080
Charlie's IP : 10.0.0.3:8080
Delta's IP :10.0.0.4:8080
All of these bots are living in containers behind a nginx proxy.
Now if I want to access these chatbots, I am able to get to the browser with 10.0.0.2:8080 and use the chatbots,
If I could setup a domain (alpha,org) and want to access these chatbots as alpha,com/bravo , or alpha,com/charlie and alpha,com/delta how would I be able to achieve this.?
The Proxy pass directive works only for the index_html and the chatbot application seems to have some kind of base url path that I am unable to figure out.
nginx returns a blank page if I inspect the traffic. Help me debug this.
You can use nginx-ingress controller with this ingress definition: (But first you need to deploy nginx-ingress controller on your cluster, you can use this link)
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: alpha-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: alpha.com
http:
paths:
- path: /bravo
backend:
serviceName: BravoService
servicePort: 80
- path: /charlie
backend:
serviceName: CharlieService
servicePort: 80
- path: /delta
backend:
serviceName: DeltaService
servicePort: 80 # You could also use named ports if you already named the port in the service like bravo-http-port
This expects that you have already defined and deployed your services with associated deployments. for Ex:
apiVersion: v1
kind: Service
metadata:
name: BravoService
labels:
app: bravo
spec:
type: NodePort
selector:
app: bravo
ports:
- name: bravo-http-port
protocol: TCP
port: 80
targetPort: bravo-port
nodePort: 8080
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: bravo-deployment
labels:
app: bravo
spec:
# init with 3 replicas
replicas: 1
selector:
matchLabels:
app: bravo
template:
metadata:
labels:
app: bravo
spec:
containers:
- name: bravo-container
image: my-docker-repo/project:1.0
ports:
- name: bravo-port
containerPort: 8080
If you have more questions on this please don't hesitate.

Authentication Process is not triggered when using IBM App ID in IBM Cloud Kubernetes Service

I'm trying to use this feature: https://cloud.ibm.com/docs/services/appid?topic=appid-kube-auth#kube-auth
I've followed the steps in the documentation, but the authentication process is not triggered. Unfortunately I don't see any errors and don't know what else to do.
Here is my sample service (nginx.yaml):
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
strategy:
type: Recreate
selector:
matchLabels:
app: nginx
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx
namespace: default
labels:
app: nginx
spec:
ports:
- name: http
port: 80
protocol: TCP
selector:
app: nginx
type: NodePort
Here is my sample service (ingress.yaml). Replace 'niklas-heidloff-4' with your cluster name and 'niklas-heidloff-appid' with the name of your App ID service instance.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-with-app-id
annotations:
ingress.bluemix.net/appid-auth: "bindSecret=binding-niklas-heidloff-appid namespace=default requestType=web"
spec:
tls:
- hosts:
- niklas.niklas-heidloff-4.us-south.containers.appdomain.cloud
secretName: niklas-heidloff-4
rules:
- host: niklas.niklas-heidloff-4.us-south.containers.appdomain.cloud
http:
paths:
- path: /
backend:
serviceName: nginx
servicePort: 80
Here are the steps to reproduce the sample:
First create a new cluster with at least two worker nodes in Dallas as described in the documentation. Note that it can take some extra time to get a public IP for your cluster.
Then create a App ID service instance.
Then invoke the following commands (replace 'niklas-heidloff-4' with your cluster name):
$ ibmcloud login -a https://api.ng.bluemix.net
$ ibmcloud ks region-set us-south
$ ibmcloud ks cluster-config niklas-heidloff-4 (and execute export....)
$ ibmcloud ks cluster-service-bind --cluster niklas-heidloff-4 --namespace default --service niklas-heidloff-appid
$ kubectl apply -f nginx.yaml
$ kubectl apply -f ingress.yaml
After this I could open 'https://niklas.niklas-heidloff-4.us-south.containers.appdomain.cloud/' but the authentication process is not triggered and the page opens without authentication.
I tried the steps mentioned in the link and this is how it worked for me.
ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: myingress
annotations:
ingress.bluemix.net/appid-auth: "bindSecret=binding-appid-ks namespace=default requestType=web serviceName=nginx idToken=false"
spec:
tls:
- hosts:
- test.vidya-think-cluster.us-south.containers.appdomain.cloud
secretName: vidya-think-cluster
rules:
- host: test.vidya-think-cluster.us-south.containers.appdomain.cloud
http:
paths:
- path: /
backend:
serviceName: nginx
servicePort: 80
I added the following web redirect URL in the authentication settings of App ID service - http://test.vidya-think-cluster.us-south.containers.appdomain.cloud/appid_callback.
Now, when you try accessing the app at http://test.vidya-think-cluster.us-south.containers.appdomain.cloud/ you should see the redirection to App ID
Looks like idToken=false is a mandatory parameter as there is an error when you run kubectl describe myingress
Error: Failed to apply ingress.bluemix.net/appid-auth annotation. Error annotation format error : One of the mandatory fields not valid/missing for annotation ingress.bluemix.net/appid-auth