Defining the Deployment Target (Kubernetes Manifests)

Goal: To explain the three .yaml manifest files (Deployment, Service, and Ingress) that are stored in your Git repository. These files are the "instructions" that tell Google Kubernetes Engine (GKE) exactly how to run, network, and expose your application.

File 1: Deployment.yaml (The Application Blueprint)

This file describes the desired state for your application's Pods. A Pod is the smallest deployable unit in Kubernetes and holds your running application container (the Tomcat image). The Deployment's job is to make sure the correct number of Pods are always running with the correct image.
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: IMAGE_NAME
        ports:
        - containerPort: 8080



Key Points Explanation:

Key Purpose
kind: Deployment Tells Kubernetes to create a Deployment resource.
replicas: 1 Instructs Kubernetes to always run one copy of your application Pod. If the Pod crashes, the Deployment will automatically start a new one.
selector: matchLabels This is how the Deployment finds its Pods. It looks for Pods with the label app: myapp.
template: ... This is the blueprint for the Pods themselves. Note that template.metadata.labels (app: myapp) must match the selector above.
image: IMAGE_NAME This is the critical placeholder. The Jenkins pipeline will automatically replace this string with the real image name it built (e.g., .../hcl-rbd2:1.0.1) during the deployment stage.
containerPort: 8080 This tells Kubernetes that your Tomcat container inside the Pod is listening on port 8080 (Tomcat's default port).

File 2: service.yaml (The Internal Network)

This file creates a Service, which provides a stable, internal network endpoint for your Pods. Pods can be destroyed and recreated with new IPs, but the Service's internal address will not change. This gives other parts of the cluster a reliable way to find your application.

---
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
  namespace: default
  labels:
    app: myapp
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
    - name: http
      port: 80       # Port exposed by the Service
      targetPort: 8080 # Your app's containerPort
      protocol: TCP



Key Points Explanation:

Key Purpose
kind: Service Tells Kubernetes to create a Service resource.
selector: app: myapp This is the most important link. The Service will find all Pods with the label app: myapp (created by your Deployment) and send traffic to them.
ports: ... This rule defines the port mapping. It says: "Any traffic that hits this Service on its port 80 should be forwarded to port 8080 (the targetPort) on one of the matching Pods."

Important Note on type: LoadBalancer:

  • In your configuration, the Ingress (File 3) is the main entry point and creates an L7 (HTTP) Google Cloud Load Balancer.
  • Setting type: LoadBalancer on the Service as well tells GKE to create a second L4 (TCP) Google Cloud Load Balancer.
  • While this setup is functional, the Ingress will route traffic to the Service's internal ClusterIP, not its external L4 Load Balancer. This means the L4 Load Balancer created by this Service is likely unused and incurring extra cost.
  • For a production setup that uses an Ingress, this is typically set to type: NodePort or type: ClusterIP to avoid creating the redundant L4 load balancer.

File 3: ingress.yaml (The External URL)

This file creates an Ingress, which manages all traffic from outside the cluster. It creates a powerful Google Cloud L7 (HTTP/S) Load Balancer and configures it to route traffic based on a public URL.
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  ingressClassName: gce
  rules:
  - host: egldeployment.hcl-software.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-svc
            port:
              number: 80



Key Points Explanation:

Key Purpose
kind: Ingress Tells Kubernetes to create an Ingress resource.
ingressClassName: gce This is a critical line for GKE. It specifically commands GKE to use its native Google Cloud Load Balancer controller.
host: egldeployment... This is the public DNS name. The Ingress will watch for traffic with this "Host" header. (You must point this DNS record to the Ingress's external IP).
backend: service: name This is the final link in the chain. It says: "Any traffic that matches this host (egldeployment...) and path (/) should be sent to the Service named myapp-svc."
port: number: 80 This specifies which port on myapp-svc to send the traffic to. This matches the port: 80 defined in your service.yaml.

How They All Connect (The Traffic Flow)

This is the complete path your user's request will take:

  1. A user navigates to http://egldeployment.hcl-software.com.
  2. DNS points the user to the L7 Google Cloud Load Balancer (created by your Ingress.yaml).
  3. The Ingress sees the request for this host and forwards it to the internal Service myapp-svc (defined in your service.yaml) on port 80.
  4. The Service uses its selector to find a healthy Pod with the label app: myapp (managed by your Deployment.yaml).
  5. The Service forwards the request to that Pod's targetPort, which is 8080.
  6. The Tomcat Container running in the Pod receives the request on port 8080 and serves the EGL application.