[Kubernetes] 쿠버네티스 POD 란?

by Posted on

[Kubernetes] 쿠버네티스 POD 란?

안녕하세요? 정리하는 개발자 워니즈 입니다. 이번시간에는 쿠버네티스 에서 가장 기본적인 개념인 POD에 대해서 알아보는 시간을 갖도록 하겠습니다.

지난 글들은 아래를 참고 해주시면 됩니다.

Pod는 쿠버네티스 에서 이용되는 Container의 관리단위로 생성/관리/배포가능한 가장작은 단위의 유닛이며 Cluster내에서 실제 Application 구동되는 Object입니다.

실질적으로 도커를 공부하신 분들이면 컨테이너의 개념을 알것입니다. 그런데 이 POD라는 개념이 조금은 다른게, 여러개의 컨테이너들을 담을 수 있고 심지어 Volume도 내부 컨테이너끼리 공유해서 사용할 수 있습니다.

따라서 Pod는 하나 이상의 Container로 구성되며, 동일한 Pod 내에서는 storage/network를 공유 할 수 있습니다.
Kubernetes에서는 Docker가 가장 많이 쓰이는 Container Runtime 모듈이지만, 다른 Container Runtime 모듈도 지원합니다.

POD 의 생김새

1. POD 네트워킹

Docker에서는 Container들과의 통신을 위해 동일한 Network상에 구성해야 하나 Pod은 개별 IP를 가지며, Pod내의 Container는 동일한 IP를 가집니다. 즉, 내부적으로 할당 받은 IP는 컨테이너로 분산되어 들어갑니다.

하지만 Pod은 언제든지 Scale Out/In이 가능하고, 삭제/복제가 가능하므로 자체IP를 가지고 있음에도 불구하고 다른 Pod들과의 통신을 위해서는 반드시 Service Object를 통해 통신해야 합니다.

1-1. 도커 VS 쿠버네티스 컨테이너 네트워크

  • Docker Container Network

  • Kubernetes POD Network

차이가 보이시나요? 도커에서의 컨테이너는 각 개별로 IP를 할당받아서 내부적으로 사용을 하지만, 쿠버네티스 같은 경우는 POD라는 개념으로 한번 wrapping이 되어서 상위에 IP가 할당이 됩니다.

2. POD Template

Pod는 위에서 보았듯이 Pod Object안에 여러개의 Container를 담을 수 잇는 구조로 되어 있습니다. Yaml 파일도 그에 맞게 Pod의 스펙으로 여러개의 Container를 Spec으로 구성할 수 있도록 되어 있습니다.

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: my-nginx
  name: my-nginx
  namespace: default        
spec:
  containers:
  - image: nginx:1.14.1
    imagePullPolicy: Always
    name: my-nginx
    ports:
    - containerPort: 80
      protocol: TCP

3. Pod Lifecycle

이번에는 Kubernetes에서 Pod를 배포한 이후의 Pod의 라이프사이클에 대해 알아봅시다. Kubernetes에서 Pod를 배포하고 kubectl get pod 명령어를 통해 배포된 결과를 조회하면 아래와 같이 Pod의 상태를 볼수 있는 필드를 볼 수 있습니다.

root@master:~# kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-589ffc477-22xvz   1/1     Running   0          42s
my-nginx-589ffc477-4947h   1/1     Running   0          31s
my-nginx-589ffc477-8ll5t   1/1     Running   0          36s
my-nginx-589ffc477-md2l4   1/1     Running   0          48s

아래는 주요한 Pod의 상태는 Pod의 배포결과를 표시하는 필드로 아래와 같은 상태를 가집니다.

Value Description
Pending Pod 배포명령을 내린 직후 Pod의 상태를 조회해보면 Pending이라는 상태를 확인 할 수 있습니다. 이 상태를 Pod내의 Container 이미지가 다운로드되기전의 대기 상태를 뜻합니다.
Running Pod의 Container가 Node에 정상적으로 생성되어 그 안의 프로세스가 정상적으로 동작하고 있는 상태로일반적인 Pod의 경우 정상적으로 Pod가 배포되면 Running상태가 됩니다.
Succeeded 주로 Job과 같은 Pod리소스에서 확인할 수 있는 형태로 Pod의 Containers 컨테이너가 생성되어 프로세스를 실행하고 정상적으로 종료된 상태입니다.
Failed Pod안의 모든 Containers가 종료되었으나 한개 이상의 Container가 정상적으로 종료되지 않은 상태입니다.
Unknown Pod의 상태를 확인할 수 없는 상태로, 주로 Host 머신과의 통신에 문제가 발생했을때 표시됩니다.

4. Service Accounts for Pods

Kubernetes에서는 계정 및 권한을 관리함에 있어 User Account와 Service Account 두가지로 구분하여 관리되어 집니다. 예를 들어kubectl 등의 명령어로 Cluster에 접근할때 Apiserver를 통해 특정 User Account로 인증과정을 거치게 되고,(별도의 설정을 하지 않는다면admin계정) Container안의 Process들은 Apiserver에 접근할 수 있는데, 이때 특정 Service Account로 인증을 받습니다.

여기서는 Pod에서 실행되는 프로세스가 Kubernetes API 접근시 사용되는 Service Account에 대해 살펴보겠습니다.

4-1.Use the Default Service Account to access the API server.

Pod가 생성될때, Service Account를 명세하지 않았다면 자동으로 default 계정을 할당받아 Pod 내부에서 API로 접근할 수 있습니다.(default 계정의 권한은 클러스터 관리자가 설정할 수 있으므로 설정여부에 따라 권한 및 역할이 다를 수 있습니다.)

root@master:/lab/service/clusterip# kubectl get pod my-nginx-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
...
spec:
  containers:
  - image: nginx
 ...
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
...

# kubectl get serviceAccounts
NAME      SECRETS   AGE
default   1         25h

이렇게 생성된 Service Account는 Pod안에서 특정위치에 자동으로 마운트되어 Api 접속시 사용되어 집니다.

# kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml

# kubectl exec -it redis -- /bin/bash

# root@redis:/var/run/secrets/kubernetes.io# tree
.
`-- serviceaccount
    |-- ca.crt -> ..data/ca.crt
    |-- namespace -> ..data/namespace
    `-- token -> ..data/token

5. 컨테이너

5-1. 이미지 변경

Kubernetes에서 Image배포시 Kubelet에서는 기본설정값으로 배포하려는 Images가 Node에 존재할 경우 이미지 다운로드를 skip합니다. 이러한 설정값은 Pod의 container spec에 imagePullPolicy 설정 값으로 정의 할 수 있으며, 아래와 같이 설정이 가능합니다.

5-2. 이미지 정책

  • Always : 배포시마다 레지스트리에서 이미지를 다운로드 받습니다.
  • Never : 배포시 레지스트리에서 이미지를 다운로드 받지 않고 Node에 존재하는 이미지를 사용합니다. 만약 Node에 Image가 존재하지 않는다면 에러가 발생합니다.
  • IfNotPresent : Default설정값으로 배포하려는 Images가 Node에 존재할 경우 이미지 다운로드를 skip합니다.

5-3. Private Registry

사내 ReDii와 같은 Private Registry를 이용하기 위해서는 다운로드 권한이 저장된 Secret을 생성하여 Container Image Spec에 해당 Key를 ImagePullSecrets 항목으로 설정해주어야 합니다.

apiVersion: v1
kind: Pod
metadata:
  name: private-reg
spec:
  containers:
  - name: private-reg-container
    image: 
  imagePullSecrets:
  - name: regcred

Kubernetes Cluster에서 아래 명령어로 Secret을 생성해주면 됩니다.

kubectl create secret docker-registry regcred --docker-server= --docker-username= --docker-password= --docker-email=
  • ` is your Private Docker Registry FQDN.
  • is your Docker username.
  • is your Docker password.
  • is your Docker email.

6. 마치며..

쿠버네티스에서 가장 기본이 되는 개념입니다. POD 의 개념을 먼저 이해하고 나서 Service라는 개념에 대해서 알아보도록 하겠습니다. 모두들 위의 글을 읽고 이해하셨나요?

도커를 처음 공부할때 Container의 개념이 너무 재밌고, 신기했습니다. 그런데 이러한 컨테이너들을 클러스터링 해주고, 관리를 해주는 쿠버네티스 가 있다는 것에 대해서 놀랐습니다. 구글은 수년간 이것을 내부적으로 사용해 왔다고 합니다.

쿠버네티스의 걸음마 단계로 다음시간에는 Service 에 대해서 알아보는 시간을 갖도록 하겠습니다.

워니즈 블로그
워니즈 깃헙

Published by 워니

One Reply to “[Kubernetes] 쿠버네티스 POD 란?”

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다