kubernetes ingress controller and resource using nginx - nginx

Question

Can anybody provide me a complete example about how running insecure (without TLS) ingress controller and resource with nginx to have remote access to services running inside kubernetes cluster ? i did not find something useful.
PS: my kubernetes cluster is running on bare metal, not on a cloud provider.
the next may be useful information about what i did:
$kubectl get svc
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
attachmentservice 10.254.111.232 <none> 80/TCP 3d
financeservice 10.254.38.228 <none> 80/TCP 3d
gatewayservice 10.254.38.182 nodes 80/TCP 3d
hrservice 10.254.61.196 <none> 80/TCP 3d
kubernetes 10.254.0.1 <none> 443/TCP 31d
messageservice 10.254.149.125 <none> 80/TCP 3d
redis-service 10.254.201.241 <none> 6379/TCP 15d
settingservice 10.254.157.155 <none> 80/TCP 3d
trainingservice 10.254.166.92 <none> 80/TCP 3d
nginx-ingress-rc.yml
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx-ingress-rc
labels:
app: nginx-ingress
spec:
replicas: 1
selector:
app: nginx-ingress
template:
metadata:
labels:
app: nginx-ingress
spec:
containers:
- image: nginxdemos/nginx-ingress:0.6.0
imagePullPolicy: Always
name: nginx-ingress
ports:
- containerPort: 80
hostPort: 80
services-ingress.yml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: services-ingress
spec:
rules:
- host: ctc-cicd2
http:
paths:
- path: /gateway
backend:
serviceName: gatewayservice
servicePort: 80
- path: /training
backend:
serviceName: trainingservice
servicePort: 80
- path: /attachment
backend:
serviceName: attachmentservice
servicePort: 80
- path: /hr
backend:
serviceName: hrservice
servicePort: 80
- path: /message
backend:
serviceName: messageservice
servicePort: 80
- path: /settings
backend:
serviceName: settingservice
servicePort: 80
- path: /finance
backend:
serviceName: financeservice
servicePort: 80
nginx.conf new content
upstream default-services-ingress-ctc-cicd2-trainingservice {
server 12.16.64.5:8190;
server 12.16.65.6:8190;
}
upstream default-services-ingress-ctc-cicd2-attachmentservice {
server 12.16.64.2:8095;
}
upstream default-services-ingress-ctc-cicd2-hrservice {
server 12.16.64.7:8077;
}
upstream default-services-ingress-ctc-cicd2-messageservice {
server 12.16.64.9:8065;
}
upstream default-services-ingress-ctc-cicd2-settingservice {
server 12.16.64.10:8098;
server 12.16.65.4:8098;
}
upstream default-services-ingress-ctc-cicd2-financeservice {
server 12.16.64.4:8092;
}
upstream default-services-ingress-ctc-cicd2-gatewayservice {
server 12.16.64.6:8090;
server 12.16.65.7:8090;
}`
server {
listen 80;
server_name ctc-cicd2;
location /gateway {
proxy_http_version 1.1;
proxy_connect_timeout 60s;
proxy_read_timeout 60s;
client_max_body_size 1m;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering on;
proxy_pass http://default-services-ingress-ctc-cicd2-gatewayservice;
}
location /training {
proxy_http_version 1.1;
proxy_connect_timeout 60s;
proxy_read_timeout 60s;
client_max_body_size 1m;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering on;
proxy_pass http://default-services-ingress-ctc-cicd2-trainingservice;
}
location /attachment {
proxy_http_version 1.1;
proxy_connect_timeout 60s;
proxy_read_timeout 60s;
client_max_body_size 1m;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering on;
proxy_pass http://default-services-ingress-ctc-cicd2-attachmentservice;
}
location /hr {
proxy_http_version 1.1;
proxy_connect_timeout 60s;
proxy_read_timeout 60s;
client_max_body_size 1m;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering on;
proxy_pass http://default-services-ingress-ctc-cicd2-hrservice;
}
location /message {
proxy_http_version 1.1;
proxy_connect_timeout 60s;
proxy_read_timeout 60s;
client_max_body_size 1m;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering on;
proxy_pass http://default-services-ingress-ctc-cicd2-messageservice;
}
location /settings {
proxy_http_version 1.1;
proxy_connect_timeout 60s;
proxy_read_timeout 60s;
client_max_body_size 1m;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering on;
proxy_pass http://default-services-ingress-ctc-cicd2-settingservice;
}
location /finance {
proxy_http_version 1.1;
proxy_connect_timeout 60s;
proxy_read_timeout 60s;
client_max_body_size 1m;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering on;
proxy_pass http://default-services-ingress-ctc-cicd2-financeservice;
}
}

Answer 1

According to the Kubernetes ingress documentation, Ingress is a collection of rules that allow inbound connections to reach the cluster services. This, of course requires that you have an ingress controller deployed in your cluster. While there are many many ways you can implement an ingress controller, a simple one that will help you understand the concept can be found here. This one is written in golang and basically listens to the kubeapi for new ingress resources. When it gets a new incoming ingress resource, it will recreate a new nginx conf based off that config and reload the nginx container that makes up your ingress controller:
const (
nginxConf = `
events {
worker_connections 1024;
}
http {
# http://nginx.org/en/docs/http/ngx_http_core_module.html
types_hash_max_size 2048;
server_names_hash_max_size 512;
server_names_hash_bucket_size 64;
{{range $ing := .Items}}
{{range $rule := $ing.Spec.Rules}}
server {
listen 80;
server_name {{$rule.Host}};
{{ range $path := $rule.HTTP.Paths }}
location {{$path.Path}} {
proxy_set_header Host $host;
proxy_pass http://{{$path.Backend.ServiceName}}.{{$ing.Namespace}}.svc.cluster.local:{{$path.Backend.ServicePort}};
}{{end}}
}{{end}}{{end}}
}`
)
What this allows for is one single entry point into your cluster that proxy traffic to all of the services inside of your Kubernetes cluster.
Say you have a service named foo inside the namespace bar. Kube-DNS allows us to reach that service from inside a kubernetes cluster form the DNS address foo.bar.svc.cluster.local. This is basically what Ingress does for us. We specify a path in which we want to use to reach the service and then the ingress controller proxies that path to the service foo in your cluster.