Kubenetes Load Balancer is not accessible - kubernetes

Question

I am trying to host the below (deployment frontend) Kubernetes deployment in the AWS EKS cluster, after deploying deployment and created service and ingress, everything gets successfully deployed and created but when i try to access the Load Balancer DNS from outside then this LoadBalancer is not accessible.
Can someone please point the reason?
**Below code (deployment-2048) is working and Load Balancer is accessible but not in the case of (deployment frontend) **.
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
creationTimestamp: "2021-03-09T14:08:45Z"
generation: 2
name: frontend
namespace: default
resourceVersion: "2864"
uid: a7682f3b-dffa-498f-be47-b231cce0720a
spec:
minReadySeconds: 20
progressDeadlineSeconds: 600
replicas: 4
revisionHistoryLimit: 10
selector:
matchLabels:
name: webapp
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
name: webapp
spec:
containers:
- image: kodekloud/webapp-color:v2
imagePullPolicy: IfNotPresent
name: simple-webapp
ports:
- containerPort: 80
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
status:
availableReplicas: 4
observedGeneration: 2
readyReplicas: 4
replicas: 4
updatedReplicas: 4
---
apiVersion: v1
kind: Service
metadata:
namespace: default
name: service-1
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: LoadBalancer
selector:
name: webapp
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: default
name: ingress-1
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
rules:
- http:
paths:
- path: /*
backend:
serviceName: service-1
servicePort: 80
---
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
---
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: alexwhen/docker-2048
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: LoadBalancer
selector:
app.kubernetes.io/name: app-2048
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
rules:
- http:
paths:
- path: /*
backend:
serviceName: service-2048
servicePort: 80

Answer 1

In your original question (without edits and additional information), in frontend deployment you have port values misconfigured.
Port exposes the Kubernetes service on the specified port within the cluster. Other pods within the cluster can communicate with this server on the specified port.
TargetPort is the port on which the service will send requests to, that your pod will be listening on. Your application in the container will need to be listening on this port also.
ContainerPort defines the port on which app can be reached out inside the container.
In short story, containerPort from deployment must have the same value as targetPort in Service.
User #herbertgoto had good idea, but unfortunately didn't specify exactly what should be done. When you have changed containerPort from 8080 to 80 it should work but I guess there was issue with repopulating this change in all resources (recreate ingress resource, redeploying pod).
One of the first troubleshooting steps should be to check if your container is listening on the proper port. That's why I requested to $ netstat output.
Useful command to check is to use $ kubectl get ep to check service endpoints.
Note
If you will skip targetPort in service and have only port, Kubernetes automatically assign targetPort value based on port.
When i kept only containerPort and TargetPort to 8080. and the others to 80. Why it worked like this.
Default port port for service is 80. So when you create service with port 80, you don't need to specify any additional things. When you have set port in service to 8080 you also need to specify it.
I've created service with port 8080 no my GKE cluster.
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.104.0.1 <none> 443/TCP 153m
my-nginx LoadBalancer 10.104.14.137 34.91.230.207 8080:31311/TCP 9m39s
$ curl 34.91.230.207
curl: (7) Failed to connect to 34.91.230.207 port 80: Connection timed out
$ curl 34.91.230.207:8080
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
...
Responses from Browser:
Only externalIP
ExternalIP:8080
As you see I needed to specify port 8080 in browser and curl command when I didn't use default 80 port.
Conclusions:
Deployment containerPort and Service targetPort must have the same value. When you are using service with port different than 80 you need to specify it by adding :<portNubmer>. That's why in almost all guides in the internet yo can see service port with value 80.

Answer 2

containerPort is set to 8080 and service targetPort is 80