I have defined my service app running on port 9000. It is not web/http server it is simply just a service application running as windows service on that port to which other apps connect to (outside the container).
So I have defined Port 9000 in my service definition and in my config map definition. We are using NGINX as a proxy for accessing from outside and everything works.
Nginx Service:
- name: 9000-tcp
nodePort: 30758
port: 9000
protocol: TCP
targetPort: 9000
Config Map:
apiVersion: v1
data:
"9000": default/frontarena-ads-aks-test:9000
kind: ConfigMap
Service definition:
apiVersion: v1
kind: Service
metadata:
name: frontarena-ads-aks-test
spec:
type: ClusterIP
ports:
- protocol: TCP
port: 9000
selector:
app: frontarena-ads-aks-test
Ingress definition:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ads-ingress
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
rules:
- http:
paths:
- path: /
backend:
serviceName: frontarena-ads-aks-test
servicePort: 9000
As mentioned everything works. I know that TCP is used for L4 layer and HTTP for L7 Application Layer.
I need to access my app from another app solely by its hostname and port. Without any HTTP Url.
So basically does it mean that I do NOT need actually my Ingress Controller definition at all?
I do not need to deploy it at all?
I would only need it if I need HTTP access with some URL for example: hostname:port/pathA or hostname:port/pathB
Is that correct? For regular TCP connection we do not need at all our Ingress YAML definition? Thank you
Yes, you don't need ingress at all in this case. According to kubernetes official doc, Ingress is:
An API object that manages external access to the services in a cluster, typically HTTP.
So, if you don't need any external access via http, you can omit ingress.
Ref: https://kubernetes.io/docs/concepts/services-networking/ingress/
Related
I am trying to setup a Kubernetes cluster using Kubeadm in GCE. I was able to access the deployment using a Nodeport service from the external IP. I am trying to set up an ingress that maps to a domain name but was not able to do it. So far what I have done:
Created a baremetal nginx ingress controller (I am using kubeadm)
Created a Nodeport service on the deployment (was able to connect it from the outside of the cluster)
Created an ingress resource using the configuration below:
and the command kubectl describe ingress my-ingress returns
my-ingress <none> sample.com 10.160.15.210 80, 443 32h which is the internal IP
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
ingressClassName: nginx
spec:
tls:
- hosts:
- sample.com
secretName: sample-tls
rules:
- host: sample.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: sample # the nodeport service name of the deployment
port:
number: 8000 # nodeport target port
I cannot access the deployment using sample.com . I double checked the DNS name, using the command dig sample.com and it returns the external IP.
If you created your cluster using GCP, you should have used GCE-GKE installation instructions.
Important difference is that GCE-GKE installation creates LoadBalancer instead of NodePort
I'd like to split incoming traffic in Kubernetes Nginx in the following way:
Client --> Nginx --> {Service A, Service B}
The problem I am facing is Service A is an internal service and does not support HTTPS therefore SSL should be terminated for Service A. On the other hand, Service B is an external service (hosted on example.com) and only works over HTTPS.
I cannot manage to get this work easily with Kubernetes Nginx. Here is what I have come with:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-proxy
annotations:
nginx.ingress.kubernetes.io/backend-protocol: HTTPS
nginx.ingress.kubernetes.io/upstream-vhost: example.com
spec:
tls:
- hosts:
- proxy.com
secretName: secret
rules:
- host: proxy.com
http:
paths:
- path: /api/v1/endpoint
backend:
serviceName: service-a
servicePort: 8080
- path: /
backend:
serviceName: service-b
servicePort: 443
kind: Service
apiVersion: v1
metadata:
name: service-b
namespace: default
spec:
type: ExternalName
externalName: service-b.external
ports:
- port: 443
I have got a route for service-b.external:443 to point to example.com.
This solution only works if service-b is over HTTPS, but in my case, I cannot change to HTTPS for this service because of some other internal dependencies.
My problem is the backend-protocol annotation works for the whole kind and I cannot define it per path.
P.S: I am using AWS provider
Following the suggested solution and question from comments.
Yes, like mentioned below it is possible to have two ingress items. In your case
only one should have backend-protocol in it.
According to nginx ingress documentation:
Basic usage - host based routing¶
ingress-nginx can be used for many use cases, inside various cloud provider and supports a lot of configurations. In this section you can find a common usage scenario where a single load balancer powered by ingress-nginx will route traffic to 2 different HTTP backend services based on the host name.
First of all follow the instructions to install ingress-nginx. Then imagine that you need to expose 2 HTTP services already installed: myServiceA, myServiceB. Let's say that you want to expose the first at myServiceA.foo.org and the second at myServiceB.foo.org. One possible solution is to create two ingress resources:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ingress-myservicea
annotations:
# use the shared ingress-nginx
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: myservicea.foo.org
http:
paths:
- path: /
backend:
serviceName: myservicea
servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ingress-myserviceb
annotations:
# use the shared ingress-nginx
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: myserviceb.foo.org
http:
paths:
- path: /
backend:
serviceName: myserviceb
servicePort: 80
When you apply this yaml, 2 ingress resources will be created managed by the ingress-nginx instance. Nginx is configured to automatically discover all ingress with the kubernetes.io/ingress.class: "nginx" annotation. Please note that the ingress resource should be placed inside the same namespace of the backend resource.
On many cloud providers ingress-nginx will also create the corresponding Load Balancer resource. All you have to do is get the external IP and add a DNS A record inside your DNS provider that point myServiceA.foo.org and myServiceB.foo.org to the nginx external IP. Get the external IP by running:
kubectl get services -n ingress-nginx
It is also possible to have separate nginx classes as mentioned here.
In kubernetes I have a deployment of 3 pods in charge of the sockets.
I wish to load balance the traffic between the pods of the deployment. To do it, I'm using the NGINX Ingress controller installed via Helm using the chart stable/nginx-ingress.
The problem is that the clients always connect to the same pod. There is no balancing.
To test the load balancing, I'm using sevaral phones using the data (2-6 phones). Each of them opening a socket connection.
I have 2 ingress rules. For the sockets I'm using:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-socket-service
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/websocket-services: "node-socket-service"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/upstream-hash-by: "$host"
spec:
tls:
- hosts:
- example.com
rules:
- host: example.com
http:
paths:
- path: /socket.io/
backend:
servicePort: 4000
serviceName: node-socket-service
Service:
apiVersion: v1
kind: Service
metadata:
name: node-socket-service
spec:
type: ClusterIP
selector:
component: node-socket
ports:
- port: 4000
targetPort: 4000
I tried to change the value of upstream-hash-by with : $binary_remote_addr $remote_addr $host ewma $request_uri, unsuccessful...
I'm wondering if the way that I'm doing my test is good. May be the load balancing is working well but it needs to have more clients.
I am assuming you are using the following architecture to reach your pod:
Ingress controller ---> kubernetes service ---> kubernetes deployment (POD)
If this is the case, then you are using load balancing with a statistical round robin policy already. For which I would conclude that your deployment only has one replica. Check the amount of replicas by running kubectl describe deployment $YOUR_DEPLOYMENT. Increase the amount of replicas by running kubectl scale deployment --replicas=5.
In case you are using a different architecture I would need to check it in order to verify why load balancing is not working. Most likely you are not using a Deployment bud a Pod to deploy your container.
Try nginx.ingress.kubernetes.io/upstream-hash-by: $arg_token instead of $host
I'm using kubernetes ingress-nginx and this is my Ingress spec. http://example.com works fine as expected. But when I go to https://example.com it still works, but pointing to default-backend with Fake Ingress Controller certificate. How can I disable this behaviour? I want to disable listening on https at all on this particular ingress, since there is no TLS configured.
kind: Ingress
apiVersion: extensions/v1beta1
metadata:
name: http-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: example.com
http:
paths:
- backend:
serviceName: my-deployment
servicePort: 80
I've tried this nginx.ingress.kubernetes.io/ssl-redirect: "false" annotation. However this has no effect.
I'm not aware of an ingress-nginx configmap value or ingress annotation to easily disable TLS.
You could remove port 443 from your ingress controllers service definition.
Remove the https entry from the spec.ports array
apiVersion: v1
kind: Service
metadata:
name: mingress-nginx-ingress-controller
spec:
ports:
- name: https
nodePort: NNNNN
port: 443
protocol: TCP
targetPort: https
nginx will still be listening on a TLS port, but no clients outside the cluster will be able to connect to it.
Redirection is not involved in your problem.
ingress-controller is listening on both port, 80 and 443. When you configure an ingress with only 80 port, if you reach the 443 port you are redirected to the default backend, which is expected behaviour.
A solution is to add an other nginx-controller, that will only listen on 80 port. And then you can configure your ingresses with kubernetes.io/ingress.class: myingress.
When creating the new nginx-controller, change the command --ingress-class=myingress of the daemonset. It will then handle only ingress annotated with this class.
If you use helm to deploy it, simply override the controller.ingressClass value.
I'm trying to connect have NGINX direct traffic to different parts of my app through the config file, but I can't figure it out for the life of me. Here is my current setup:
http-service (loadbalancer)
NGINX (port 80)
website-service (10.27.246.107, port 8000, targetPort 8000, selector 'run: website')
website (label 'run: website', containerPort 8000)
NGINX Conf
upstream website{
server 10.27.246.107:8000
}
This is a normal nginx pod using containerPort 80 at the moment.
Am I going about this the right way?
The best way to rout traffic to different part of your application is using Ingress. In Ingress, you can describe all your paths into all parts of your application. It will look like:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test
annotations:
ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: foo.bar.com
http:
paths:
- path: /foo
backend:
serviceName: website1
servicePort: 80
- path: /bar
backend:
serviceName: website2
servicePort: 3368
Actually, Ingress-controller is based on Nginx, but anyway you can choose another engine, for example, HAproxy.
Ingress was designed for using in Kubernetes and it has more features in Kubernetes. For example, your website upstream should be described as a service in Kubernetes:
kind: Service
apiVersion: v1
metadata:
name: website1
spec:
selector:
app: python-web-site
ports:
- protocol: TCP
port: 80
targetPort: 8080
Anyway, you can route traffic by Nginx and expose it to the world, but the best practice is to uses Ingress in Kubernetes.