pod에 대한 고찰 그리고 sandbox pod와 pause container
지난 글에서 폐쇄 환경의 kubernets에 application을 설치하면서 sandbox pod, pause container 와의 만남에 대해 언급을 했었는데, 이러한 키워드는 pod를 알게되면서 (적어도 pause container만큼은)살펴봤던 내용임에도 이후 만날 일이 없어 기억 저편으로 묻어버리고 말았던 것이다.
때문에 오랜만에 그러한 것들과 재회(?)한 기념으로 위의 키워드를 포함해 pod에 대해 더 알아보고자 한다.
(pod안의 container, 더 나아가서는 system isolation이란 무엇인가는 언급하지 않겠다.)
pod
개요
kubernetes를 경험해보았다는 분들과 이야기를 하면서 pod는 무엇인가요? container 와는 무슨 관계인가요? 라는 질문을 했을때, 시원하게 대답을 하지 못하는 분들을 종종 만날 수 있었다.
당장 나부터도 이러한 질문을 받았을때 잘 대답할 수 있었을까? 라는 생각이 들었다.
Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.
Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. - https://kubernetes.io/docs/concepts/workloads/pods/
pod는 관련 공식 문서를 살펴봤을때 아래와 같이 정리할 수 있었다.
- pod는 kubernetes에서 배포되는 가장 작은 단위의 computing unit이다.
- pod는 service를 제공하기 위해 multiple container를 지원할 수 있도록 구성(디자인) 되어있다.
- pod안에서 container들은 인프라 리소스를 공유한다.
왜 deployable unit이 pod일까?
위에서 pod의 개념을 마주했을때, 왜 k8s에서 배포될 수 있는 computing unit이 container가 아니고 pod일까 라는 생각이 들었다.
이러한 것은 kubernete blog의 The Distributed System ToolKit: Patterns for Composite Containers 글에서 어느 정도 해소할 수 있었다.
이러한 내용을 요약해보자면 아래와 같다.
1. 지난 몇(?) 년간 container는 점점 code를 패키징하고 배포하는 것에 대한 가장 주요한 방법 중 하나로 떠올랐다.
2. Micro-Service-Architecture 처럼 container도 modular로 구현하도록 권장해야하며, 재사용등 여러 이점을 가져다준다.
3. 이러한 modular container들은 서비스 제공을 위해 결합될 수 있으며
4. 이러한 관점에서 서비스는 하나의 컨테이너가 아니라, 여러 기능적 container가 결합된 그룹이다.
5. k8s에서 이러한 '서비스'라는 것은 pod로 구현된다.
추가로, 일반적인 pod 구성에 대해서 아래와 같은 세 가지 예제도 위 글에서 언급하고 있다.
1. Sidecar containers
2. Ambassador containers
3. Adapter containers
sandbox pod
개요
pod에 대해서 살펴보았으니, 지난번 마주했던 sandbox pod에서도 알아보자.
wiki pedia에서는 sandbox는 아래와 같이 정의하고 있다.
A sandbox is a testing environment that isolates untested code changes and outright experimentation from the production environment or repository, in the context of software development including Web development, Automation and revision control.
sandbox 'pod'는 아니지만, redhat에서는 sandbox container에 대해 아래와 같이 말한다.
A sandbox is a tightly controlled environment where an application runs. Sandboxed environments impose permanent restrictions on resources and are often used to isolate and execute untested or untrusted programs without risking harm to the host machine or operating system.
이 두 가지 내용에서 공통점은 sandbox라는 것은 untested, untrusted한 program으로부터의 리스크를
방지하기 위한 격리된 환경을 의미하는 듯 하다.
그렇다는 것은 pod도 생성 시, 이러한 sandbox 환경을 만들어 host와 분리하고 그 위에 container를 불러들이고 있는 것 일까?
이러한 sandbox는 kubernetes 안에서 어떻게 사용되고 있는 것 일까?
2016년 포스팅된 kubenetes blog의 Introducing Container Runtime Interface (CRI) in Kubernetes에서는 pod의 생성과 삭제 과정에 대해 가볍게 언급을 하고 있는데, 여기서 관련 내용을 찾아볼 수 있었다.
A Pod is composed of a group of application containers in an isolated environment with resource constraints. In CRI, this environment is called PodSandbox.
Before starting a pod, kubelet calls RuntimeService.RunPodSandbox to create the environment.
This includes setting up networking for a pod (e.g., allocating an IP).
어떠한, 리소스가 격리된 환경 위에 Pod가 실행되는데 이러한 격리 환경을 PodSandbox라고 하는 듯 하다.
(container infra setting이라고 해야할까?)
PodSandbox가 생성이 된 후 일어나는 일에 대한 workflow는 아래와 같이 되어있다.
isolated environment 생성 후, Network 설정 등을 한 후 application container를 생성하는 듯 하다.
Kubelet KubeletGenericRuntimeManager RemoteRuntime
+ + +
| | |
+---------SyncPod------------->+ |
| | |
| +---- Create PodSandbox ------->+
| +<------------------------------+
| | |
| XXXXXXXXXXXX |
| | X |
| | NetworkPlugin. |
| | SetupPod |
| | X |
| XXXXXXXXXXXX |
| | |
| +<------------------------------+
| +---- Pull image1 -------->+
| +<------------------------------+
| +---- Create container1 ------->+
| +<------------------------------+
| +---- Start container1 -------->+
| +<------------------------------+
| | |
| +<------------------------------+
| +---- Pull image2 -------->+
| +<------------------------------+
| +---- Create container2 ------->+
| +<------------------------------+
| +---- Start container2 -------->+
| +<------------------------------+
| | |
| <-------Success--------------+ |
| | |
+ + +즉, 이전 글에서 말한 FailedCreatePodSandBox는 격리 환경 생성에 실패했다는 의미가 되는 것이다.
pause container
앞서 언급한 pod~PodSandbox의 내용을 아래와 같이 정리해볼 수 있는데
- 여러 container들이 결합하여 pod를 이루고, 이때 container들은 pod의 인프라 리소스를 공유한다.
- pod 생성 과정은 sandbox를 container infra setting(특히 network namespace) 등을 진행 후 container들을 생성한다.
이때 infra setting 후 등장하는 것이 pause container이다.
pause container는 각 pod에 존재하며 이것은 infra, parents ,template container라고도 불리는 것 같은데, 이것은 container가 실행이 되면 sleep 상태에 빠져 infra resource를 붙잡고(hold)있을 뿐이다.
https://www.ithands-on.com/2020/11/kubernetes-101-pause-containers.html
이러한 pause container 덕에 pod 안의 application container가 crush 되더라도 infra namespace는 무너지지 않고 유지되어, 다시 container가 살아났을때 기존 resource를 다시 그대로 공유받을 수 있는 것이다.
https://www.ithands-on.com/2020/11/kubernetes-101-pause-containers.html
이전 FailedCreatePodSandBox 현상에서 원인이 failed to pull and unpack image(pause)이었는데 이것은 sandbox 생성을 마무리하기위해 pause container 생성을 시도했으나, image를 가져오지 못해 ContainerCreating 단계에서 더 나아가지 못했던 것이다.
마무리
정리를 하면서 느낀 것은, 내가 뭘 배울때 document를 꼼꼼히 읽어보지 않는구나 라는 생각이 들었다.
pod에 대한 document를 보면서 이런 내용이 있었구나... 싶었는데 부끄러울 따름이다.
또한 kubernetes를 경험하고는 있지만, container 대해서도 조금 더 deep하게 공부할 수 있어야 겠다 싶었다. openstack을 할때도 마찬가지였지만 그 근원이 되는 linux 기술에 대해서 아는 것이 적으니 이해하는데 상당한 시간이 걸렸던 것 같다.
음... 이상.. 호다닥
참고
- https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/
- https://github.com/kubernetes/design-proposals-archive/blob/8da1442ea29adccea40693357d04727127e045ed/node/runtime-client-server.md#proposed-design
- https://blog.devgenius.io/k8s-pause-container-f7abd1e9b488
- https://www.ithands-on.com/2020/11/kubernetes-101-pause-containers.html
- https://www.redhat.com/en/topics/containers/what-is-kubernetes-pod
좋은 글 감사합니다!