Kubernetes:Pod

lastmod 2026-02-23created 2021-06-294 edits

Unlike other container orchestration tools, Kubernetes does not run containers directly. Instead, it manages pods, which group and structure one or more containers. Containers in the same pod share the network, IPC, volumes, and so on. Containers in a pod are placed on a single physical node, which makes sharing these resources and communicating easy. Multiple pods can be placed on one node, and these pods are completely isolated from other pods.

Example

Applying with a spec file:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-instance
  labels:
    app: simple-http
spec:
  containers:
    - name: nginx-app
      image: nginx

Run with the kubectl:apply command:

$ kubectl apply -f ./test.yml
pod/nginx-instance created

Check with the kubectl:get command:

$ kubectl get pods
NAME             READY   STATUS    RESTARTS   AGE
nginx-instance   1/1     Running   0          82s

Check the logs (standard output) with the kubectl:logs command:

$ kubectl logs nginx-instance
$ kubectl logs -f nginx-instance  ## --follow 옵션. 출력상태를 계속 유지

Run a process in the Pod with the kubectl:exec command.

$ kubectl exec -it nginx-instance -- bash
root@nginx-instance:/# ...

Remove with the kubectl:delete command.

$ kubectl delete -f ./test.yml
pod "nginx-instance" deleted

Container health monitoring

• Configure Liveness, Readiness and Startup Probes | Kubernetes

There is a slight difference between creating a container and the service actually being ready. When you start a server, you cannot connect right away; it needs initialization time of a few seconds at the shortest and several minutes at the longest Java, I'm shaking with rage, and the service can be said to be ready when you can actually connect.

Kubernetes provides options to check that a container has been created and the service is ready, so it can prevent the service from being served during initialization.

livenessProbe

Checks whether the container is working properly, and if it is not, restarts the container to resolve the problem.

Being healthy can be checked in several ways; here we use the method of sending an http get request.

piVersion: v1
kind: Pod
metadata:
  name: echo-lp
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      livenessProbe:
        httpGet:
          path: /not/exist
          port: 8080
        initialDelaySeconds: 5
        timeoutSeconds: 2 # Default 1
        periodSeconds: 5 # Defaults 10
        failureThreshold: 1 # Defaults 3

A nonexistent path (/not/exist) and port (8080) were entered on purpose.

Check the status:

NAME      READY   STATUS             RESTARTS      AGE
echo-lp   0/1     CrashLoopBackOff   4 (15s ago)   60s

Because it did not respond properly, the Pod was restarted several times and changed to the CrashLoopBackOff state.

readinessProbe

Checks whether the container is ready, and if it is not properly ready, excludes requests coming into the Pod.

The difference from livenessProbe is that even if there is a problem, it does not restart the Pod and only excludes requests.

apiVersion: v1
kind: Pod
metadata:
  name: echo-rp
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      readinessProbe:
        httpGet:
          path: /not/exist
          port: 8080
        initialDelaySeconds: 5
        timeoutSeconds: 2 # Default 1
        periodSeconds: 5 # Defaults 10
        failureThreshold: 1 # Defaults 3

Check the status

NAME      READY   STATUS    RESTARTS   AGE
echo-rp   0/1     Running   0          14s

You can see that the READY state is 0/1.

livenessProbe + readinessProbe

Usually livenessProbe and readinessProbe are applied together. Adjust the detailed settings appropriately for the application environment.

apiVersion: v1
kind: Pod
metadata:
  name: echo-health
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      livenessProbe:
        httpGet:
          path: /
          port: 3000
      readinessProbe:
        httpGet:
          path: /
          port: 3000

Because port 3000 and the / path are healthy, you can see that the Pod was created without errors.

Multiple containers

Mostly 1 Pod = 1 container, but having multiple containers is also quite common.

Containers belonging to one Pod share the network with each other via localhost and can share the same directory.

apiVersion: v1
kind: Pod
metadata:
  name: counter
  labels:
    app: counter
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/counter:latest
      env:
        - name: REDIS_HOST
          value: "localhost"
    - name: db
      image: redis

Creates a simple web application that stores the request count in redis, as multiple containers.

A Pod with multiple containers looks like this.

Because the containers were created in the same Pod, the counter app can access redis as localhost.

We haven't learned about Service yet, so testing in a browser is difficult; let's connect to the container directly and test.

# Pod 생성
kubectl apply -f counter-pod-redis.yml

# Pod 목록 조회
kubectl get pod

# Pod 로그 확인
kubectl logs counter # 오류 발생 (컨테이너 지정 필요)
kubectl logs counter app
kubectl logs counter db

# Pod의 app컨테이너 접속
kubectl exec -it counter -c app -- sh
# curl localhost:3000
# curl localhost:3000
# telnet localhost 6379
  dbsize
  KEYS *
  GET count
  quit

# Pod 제거
kubectl delete -f counter-pod-redis.yml

See also

• Kubernetes
• Kubernetes:Basic

Favorite site

• Joinc - Kubernetes Pod
• Pod | Kubernetes Guide