---
title: 'Exposing App Inside of Running Kubernetes Pod'
disqus: hackmd
tags: Kubernetes,Infrastructure
---

# Exposing App Inside of Running Kubernetes Pod

:::info
:warning: This article only represent me, an indie software engineer who likes to explore new things. Read it with a grain of salt!
:::

Kubernetes (or k8s) might comes in "handy" for mid to large-scale applications orchestration, but sometimes it can be challenging deploying app when you have limited to none basic or fundamental knowledge of how kubernetes works. You might even have not got the time to learn since there are many topics to cover or you simply can't grasp the idea even after hours of reading.

Either way, rather than spending your time to grasp the concept hollistically with no concrete result, it's better to learn and implement the knowledge little by little. In this article, we'll discuss one of the most basic topic that is exposing your app on running pod for cluster-external access.

## 🏗Kubernetes Architecture
<p style="text-align:center;font-style:italic">
Kubernetes Architecture by <a href="https://aws.plainenglish.io/kubernetes-architecture-c93cb9c798d8" target="_blank">
Yogita Kothadiya</a>
</p>

### Cluster
Kubenertes allows you to have this big and huge ass space of isolated environment where you can architect your own infrastructure, it's called cluster. You may have as many clusters as you need on different places and clusters can communicate with other clusters, but of course with several config and setups.

### Node
Inside cluster, there are nodes which (simply) you can think of as instances of (virtual) server where each of them is assigned a static IP for external access. There is 1 node that works as the control plane called "Master Node" that controls all the worker nodes as well as the "proxy" that does command whenever invoked through kubectl. All worker node must act accordingly to what master node commands them to do.

### Pod
Inside node, there is a basic single excution unit called *pod*, which you can think of as main "container" that contains many of your containerized apps to be run. so, pod is basically collection of containers, that provides network and storage as shared resource to its containers. This gives kind of higher level abstraction to the architecture, therefore giving easier access and maintenance for the system.

Pods are assigned a local IP for intracluster communication and may access different pods on different nodes with additional setup.

### Service (SVC)
Service (svc) is kind of an abstraction that defines logical sets of pods and related policies to access those pods. You can think of service as proxy that handles incoming communication and may continue or drop the incomming communication to the said pods based on rules it defines.

svc is one of the most crucial topics, espcially when we are talking "exposing pod" since it's (i believe) the easiest way you can expose your pod for external-cluster access.

## 🌏Exposing Pod using Node Service (svc)

Service comes in many types, each have its own function.
1. **ClusterIP**: The default type. Exposes the Service on a cluster-internal IP. This type makes the Service only reachable from within the cluster.
2. **NodePort**: Exposes the Service on each Node's IP at a static port. This type allows the Service to be accessed from outside the cluster.
3. **LoadBalancer**: Exposes the Service externally using a cloud provider's load balancer. This type integrates with cloud providers' load balancers to distribute traffic across multiple nodes.
4. **ExternalName**: Maps the Service to a DNS name. This type redirects requests to a DNS name to a specific external DNS name.

Out all of these, the most simple one is NodePort, therefore let's use this as our learning example.

NodePort is a service where you can map node's port on its externally-accessible networking interface to your pod's port on its internally-accessible networking interface, by doing this you can possibly access the node's network interface, and then your communication will be forwarded to the pod's network interface on said ports, therefore your pod is now basically has been exposed to outside of the cluster, pretty neat, huh.

setting up NodePort Service is pretty straightforward, it's similar to pod. you have to have the config of service in yaml file. let's use example.

**pod.yml**

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: test
  labels:
    app: test-pod
spec:
  containers:
  - name: test-container
    image: nvcr.io/nvidia/pytorch:24.03-py3
    command: ["/bin/bash", "-c"]
    args: ["./entrypoint.sh; while true; do sleep 10; done;"]
    workingDir: "/workspace"
    ports:
    - containerPort: 3000
    volumeMounts:
    - mountPath: /workspace
      name: test-pv-storage
  nodeName: dgx1
  restartPolicy: OnFailure
  volumes:
  - name: test-pv-storage
    persistentVolumeClaim:
      claimName: test-pv-claim

**service.yml**

apiVersion: v1
kind: Service
metadata:
  name: test-service
  namespace: test
spec:
  selector:
    app: test-pod
  type: NodePort
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
      nodePort: 32000

>it's important that you give labels to the pod as it function as identifier

On the example above, we are creating NodePort service that defines rule for pod `app: test-pod` where whenever there's incoming TCP connection on port 32000 on node's networking interface (**nodePort**), it will be forwarded to the said pod on port 3000 (**targetPort**). The **port** variable is not mainly used, and will be only used by the svc whenever there's secondary communication to the pod or when the pod is not accessible through **nodePort**

you can then just do `kubectlf --config=/path/to/config apply -f service.yml` to implement the service and now your app running on port 3000 inside the pod should be accessible using connection info `PROTOCOL://NODE_IP:nodePort`

## 📚 Conclusion
We have discussed on how to expose running app inside the pod to external world of cluster using simple NodePort service. This is not the absolute way nor will i claim that this is the right way, you shall explore and analyze which method that suits best to your interests.

Kubernetes might be complex and hard to approach for some of us, We don't have to understand the whole concept hollistically straight "out of the box". It's better to understand a topics little by little and try to implement it while learning along the way