[Kubernetes] 쿠버네티스 설치하기 (1) - Container runtimes

Container runtimes

위의 운영환경의 쿠버네티스 Getting started를 보며 이해와 동시에 설치를 진행해 나가도록 하자!

한국어로도 페이지를 볼 수 있지만 무슨 의미인지 정말 알아먹기 힘들어서 영어로 문서를 봐야겠다..

( low level의 영어실력 양해바람 )

 

---

위의 링크를 들어가보면 아래의 글을 맨처음 만날 수 있다.

---

Container runtimes

You need to install a container runtime into each node in the cluster so that Pods can run there. This page outlines what is involved and describes related tasks for setting up nodes.

This page lists details for using several common container runtimes with Kubernetes, on Linux:

• containerd
• CRI-O
• Docker

---

Pod를 각 node에서 실행시키기 위해서는 container runtime을 설치해야한다고 한다.

그리고 아래의 3개는 container runtime의 종류 3가지인데 당연하게도 난 Docker를 사용할 것이다!!

이 페이지는 node를 세팅하는 방법을 알려준다고 한다.

 

container runtime 이란?

container 들이 실행되어질 수 있는 발판을 마련해주는 소프트웨어라고 보면 될 것 같다.

Docker가 image를 기반으로 container를 실행 시켜 독립적인 환경을 구성하게 해주는것처럼 말이다.

 

그럼 이제 위의 굵은 단어의 뜻을 알아보자.

Kubernetes Components

---

Kubernetes Components

When you deploy Kubernetes, you get a cluster.

A Kubernetes cluster consists of a set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node.

The worker node(s) host the Pods that are the components of the application workload. The control plane manages the worker nodes and the Pods in the cluster. In production environments, the control plane usually runs across multiple computers and a cluster usually runs multiple nodes, providing fault-tolerance and high availability.

---

쿠버네티스 클러스터를 먼저 알아보면, 하나이상의 컨테이너로 구성된 어플리케이션의 모임이라고 한다.

여기서 컨테이너로 구성된 어플리케이션들의 집합, worker machine을 node라고 부르는 것 같다.

그리고 그 node가 Pod를 관리하고 Pod가 실제 Docker를 이용해 띄운 컨테이너들의 집합을 의미하는 것 같다.

또한 여기서 control plane이란 녀석을 언급하는데 control을 보아하니 nodes, Pods 를 관리하는 녀석인 것으로 보인다.

 

아래의 그림을 보자

위에 언급한 Control Plane에 Node들이 연결되어 있는것을 볼 수 있다.

Pod는 보이지 않는데 Node안에서 실행되고 있는 컨테이너들의 집합이라고 생각하겠다.

( 아직 잘 와닿지는 않지만 대략적으로만 이해하고 넘어가자 )

 

---

Node Components

Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.

kubelet

An agent that runs on each node in the cluster. It makes sure that containers are running in a Pod.

The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes.

kube-proxy

kube-proxy is a network proxy that runs on each node in your cluster, implementing part of the Kubernetes Service concept.

kube-proxy maintains network rules on nodes. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster.

kube-proxy uses the operating system packet filtering layer if there is one and it's available. Otherwise, kube-proxy forwards the traffic itself.

Container runtime

The container runtime is the software that is responsible for running containers.

Kubernetes supports several container runtimes: Docker, containerd, CRI-O, and any implementation of the Kubernetes CRI (Container Runtime Interface)

---

조금더 살펴보면 위의 그림안에, Node 부분에 대한 구성요소의 설명이다

kubelet 은 컨테이너들이 Pod에서 돌아가도록 하는 녀석이고, 쿠버네티스에 의해 생성되지 않은 컨테이너는 관리하지 않는다.

kube-proxy 는 Node 안에 Pods들 과의 통신에 사용된다고 하는데 차차 알아가보자 ...

Container runtime 는 위에서 살펴보았다. Docker 같은 컨테이너 형태로 실행되는 소프트웨어

 

이정도로 대략적인 이미지를 머리속에 넣고, 나머지는 나중에 찾아보도록 하겠다.

 

---

Cgroup drivers

Control groups are used to constrain resources that are allocated to processes.

When systemd is chosen as the init system for a Linux distribution, the init process generates and consumes a root control group (cgroup) and acts as a cgroup manager. Systemd has a tight integration with cgroups and allocates a cgroup per systemd unit. It's possible to configure your container runtime and the kubelet to use cgroupfs. Using cgroupfs alongside systemd means that there will be two different cgroup managers.

A single cgroup manager simplifies the view of what resources are being allocated and will by default have a more consistent view of the available and in-use resources. When there are two cgroup managers on a system, you end up with two views of those resources. In the field, people have reported cases where nodes that are configured to use cgroupfs for the kubelet and Docker, but systemd for the rest of the processes, become unstable under resource pressure.

Changing the settings such that your container runtime and kubelet use systemd as the cgroup driver stabilized the system. To configure this for Docker, set native.cgroupdriver=systemd.

---

다음 문단으로는 Cgroup drivers 에 대해서 설명하고있다.

깊게는 잘 모르겠고 대략적인 의미는, Cgroup, control group 이란, 프로세스에 할당된 자원들을 관리하는데 시스템이다.

위의 이야기는, 이미 리눅스에서는 systemd 시스템을 쓰고 있는데, 우리가 구성할 쿠버네티스의 Node에는 kubelet나 Docker가 리소스 관리하기위해 cgroupfs 라는걸 쓰고 있어서 자원을 관리하는 시스템이 2개가 되어버린다는거다.

그러면 자원을 관리하는데 불안정해질 수 있으니 cgroupdriver로 systemd 를 쓰자라는 이야기이다.

 

또한 주의사항으로 이미 쿠버네티스 클러스터안에 구성되어있는 Node의 cgroup driver를 바꾸지말라고 한다.

systemd로 쓰고 있다가 running중에 cgroupfs 로 바꿔버리면 뭐가 꼬여도 꼬일꺼 같으니 따르도록 해야할 것 같다.

 

---

자 이제 Docker를 설치하는 단계로 넘어왔다.

Container runtimes

# (Install Docker CE)
## Set up the repository
### Install required packages
sudo yum install -y yum-utils device-mapper-persistent-data lvm2

• yum-utils : yum-config-manager 를 사용하여 repo 구성파일을 아주 쉽게 생성하기 위해서 설치
• device-mapper-persistent-data 과 lvm2 (logical volumn manager) 는 devicemapper를 사용하기위해서 설치

devicemapper 란?   

도커 공식 문서(docs.docker.com/storage/storagedriver/device-mapper-driver/)를 보면 Device Mapper 에 대해 잘 나와있다.

---

Use the Device Mapper storage driver

Device Mapper is a kernel-based framework that underpins many advanced volume management technologies on Linux. Docker’s devicemapper storage driver leverages the thin provisioning and snapshotting capabilities of this framework for image and container management. This article refers to the Device Mapper storage driver as devicemapper, and the kernel framework as Device Mapper.

For the systems where it is supported, devicemapper support is included in the Linux kernel. However, specific configuration is required to use it with Docker.

The devicemapper driver uses block devices dedicated to Docker and operates at the block level, rather than the file level. These devices can be extended by adding physical storage to your Docker host, and they perform better than using a filesystem at the operating system (OS) level.

---

Device Mapper 란 리눅스 상에서 volume (저장장치)를 관리하는 커널 기반의 프레임워크라고 한다.

Docker가 devicemapper storage driver를 이용해서 image 와 container 의 관리를 한다고 한다.

볼륨의 관리나 볼륨을 스냅샷 찍는 뭐 그런 용도로 사용하게 되는 것 같다.

 

devicemapper 는 리눅스 커널에 포함되어있지만 Docker가 이를 이용하려면 따로 특정설정을 해주어야 한다고 한다.

 

또한 devicemapper 는 file 단위가아닌 block 단위로 조작을 한다고 한다.

 

간단하게 devicemapper는 저장공간을 자유자재로 지지고 볶고할 수 있는 storage driver 이다. ( Docker는 overlay2 라는 storage driver를 사용한다 ) 다양한 종류가 있는데 도커 공식문서(docs.docker.com/storage/storagedriver/select-storage-driver/)를 참조하자

 

여기서 내가 알아야할 것은 그럼 storage drivers 가 Docker 에서 어떻게 사용되어지고 있는지 이다.

이는 도커 공식문서 (docs.docker.com/storage/storagedriver/)에 아주 잘 나와있다.

 

ps. 도커가 storagedriver를 이용하여 어떻게 이미지를 생성하는지에 대해서는 빠른 시일내에 위의 공식문서를 보면서 글을 작성해야겠다.

 

## Add the Docker repository
sudo yum-config-manager --add-repo \
  https://download.docker.com/linux/centos/docker-ce.repo

yum-config-manager 를 이용하여 docker-ce를 다운로드하기 위한 레포지토리 설정 (Docker Engine Package)

 

# Install Docker CE
sudo yum update -y && sudo yum install -y \
  containerd.io-1.2.13 \
  docker-ce-19.03.11 \
  docker-ce-cli-19.03.11

Docker 설치 ( 도커는 서버, 클라이언트로 나누어져 있다 ), containerd.io는 컨테이너 입출력을 위한 데몬 패키지 같군

 

## Create /etc/docker
sudo mkdir /etc/docker

# Set up the Docker daemon
cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2",
  "storage-opts": [
    "overlay2.override_kernel_check=true"
  ]
}
EOF

Docker를 설정없이 그대로 시작하면 daemon.json이 없을 것이다.

도커데몬은 위의 /etc/docker/daemon.json 설정파일을 읽어서 시작한다고 한다.

여기서 위에 cgroupdriver를 cgroupfs -> systemd 로 변경하고 storage-driver는 default storagedriver는 overlay2 지만 명시적으로 적도록 하자.

overlay2.override_kernel_check 옵션은 리눅스 커널 버전을 체크하는 옵션인데, 도커 컨테이너가 특정한 일을 하는데 overlay2를 사용하는데, 커널이 이를 지원하는지 체크하고 도커데몬을 실행시키기위한 옵션이다.

지원하지 않으면 실행 시 fail 난다고 한다. 그땐 커널을 update 하자.

 

도커 데몬에 대한 옵션값들은 여기 다 정리되어 있다!! (docs.docker.com/engine/reference/commandline/dockerd/)

 

# Create /etc/systemd/system/docker.service.d
sudo mkdir -p /etc/systemd/system/docker.service.d​

control group을 systemd로 변경을 하였으니 docker를 systemd 로 옮겨주기 위해 디렉토리를 먼저 생성

# Restart Docker
sudo systemctl daemon-reload
sudo systemctl restart docker

daemon-reload는 도커데몬의 cgroup을 systemd로 사용하기로 했으니 이를 systemd에게 알리기 위해 systemd가 도커데몬의 설정을 알아내기위해 하는 작업으로 보인다... ( 아니면 댓글을 부탁드립니다 넘나 어렵 )

daemon.json 설정파일 읽어서 재시작!

 

sudo systemctl enable docker

boot와 동시에 docker가 실행되길 원한다면 위의 커맨드를 입력하자.

 

docker info

도커 서버 정보를 보면

Storage Driver를 overlay2를 쓴다고 되어있고, 위에서 봤던 Cgroup Driver 로는 cgroupfs를 사용한다고 되어있다.

 

---

이렇게 쿠버네티스를 설치하기 전 필요한 환경과 용어들을 알아보았다.

다음 챕터로는

Installing Kubernetes with deployment tools

여러 개발툴 중 kubeadm을 이용하여 설치를 진행해 보겠다.

kubeadm을 선택한 이유는 공식 문서에 단계별로 잘 만들어져 있는거 같아서 이다.

 

그럼 끝!