[Kubernetes] Kubernetes 기본 구성하기

앞에서 대시보드 구성을 먼저 쓰게된거같은데, 실제로는 클러스터 구성 후에 진행했던 내용이긴 하다.

어쩌다보니 베어메탈 위에 직접 kubernetes 클러스터를 구성하게 되었었다.

기존 클라우드를 이용해 구성했을때에 비해 그렇게 어려웠던 부분은 없었던거같지만

추억보정이 들어가있을 수 있으므로 한번 정리해보기로 했다.

 

쿠버네티스 클러스터를 구성하는 건 기본적으로 

Installing kubeadm | Kubernetes

Installing kubeadm

쿠버네티스 공식 페이지를 참고해서 진행했다.

 

sudo apt update && apt install -y apt-transport-https curl # 설치에 필요한 curl 설치
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - # gpg 키 추가

cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF # sources.list 파일에 kubernetes 저장소 추가

sudo apt install -y kubelet kubeadm kubectl # 필요한 kube관련 패키지 설치
apt-mark hold kubelet kubeadm kubectl # 버전 고정.

 

구성은 1개의 마스터노드와 두개의 워커노드로 구성하였다.

마스터노드에는

sudo kubeadm init # kubernetes init
sudo swapoff -a # swap 기능 off
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab  # swapoff를 재부팅시에도 적용되도록

swap은 비활성해야한다.

swap이란, 현재 메모리의 용량이 부족할 때, 사용량이 적거나 한 특정 프로세스를 swap partition으로 잠시 보냈다가 필요한경우 메모리 영역으로 불러들여 사용하는 기능이다.

그러나 kubernetes의 경우, 각 Pod별로 필요한 만큼 리소스를 할당받아 사용하는 상황이기에 이러한 상황이 없는 것이 옳다.

kubelet은 이러한 swap의 경우를 고려하지 않고 설계되어있기도 하고, swap으로 인한 성능 저하가 있을 수도 있기에 off한다.

초기에는 swap이 켜져있으면 kube 자체가 동작하지 않았으나 현재는 설정해주면 켜줄 수 있다고 한다.

 

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

이후 kube/config 파일을 생성해주고

 

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d 
'\n')"

위 명령어로 network policy를 적용한다. 여기서는 weave를 사용했으나, 다른것도 있으니 원하는대로 설정하면 된다.

 - 네트워크 폴리시란, 말 그대로 일종의 정책이다.

 - 간단히 설명하자면 방화벽같은 존재로, Pod간 통신이나 외부/내부의 통신을 위한 방화벽 설정으로 보면 된다.

 - Inbound와 관련된 Ingress / Outbound와 관련된 Egress 설정이 있는데, 이의 적용 여부는 사용하는 CNI(Container Network Interface)에 따라 다르다.

 

CNI?

 - CNCF에서 정한? 표준으로, 컨테이너간의 네트워킹 플러그인을 의미한다.

 - 왜 필요한가?? - 단순히 생각해보면 다음과 같다

    : 여러대의 노드에 나뉘어있는 파드간 통신을 진행하기 위해서는 서로간의 네트워크가 구성되어있어야 한다. 

    : 우리는 docker를 기반으로 kubernetes를 구성하고 있기 때문에, docker network도 구성해주어야되고, 서로 다른 두 노드에 위치한 컨테이너끼리 통신을 위해서는 외부 IP가 필요하다.

    : 이러한 일련의 과정들 (네트워크 대역 나누기, 라우팅 테이블 작성하기 등등)을 해주는 것이 CNI.

 - 이러한 CNI에는 다양한 것들이 있고, 그 중 하나가 weave-net 인 것. 각 CNI 별로 설정과 지원하는 기능이 다르기 때문에 확인해보고 필요한걸 사용하면 된다.

 - kubernets에는 kubenet이라는 기본 CNI 플러그인이 있긴 하다. 그런데 제공하는 기능이 매우 한정적이기 때문에, 다양한 기능을 제공하는 서드파티 CNI를 사용하는 것.

 

 - 아무튼 여기서는 weave-net의 CNI를 사용할 것인데, 이를 직접 한땀한땀 적용하기보다는 weave-net에서 제공하는 networkpolicy 파일을 가져와서 그대로 적용하는 것.

 - 기본적으로 kubernetes에는 어떠환 networkPolicy도 없기 때문에, 위 내용을 적용하지 않고 join이나 여타 과정들을 진행하면 방화벽 설정 등에 따라 다양한 에러가 발생하는것은 물론, 정상적으로 동작하지 않을 수도 있다.

 

NetworkPolicy에는 기본적으로 특정 label을 지닌 pod A,B로부터의 트래픽은 특정 Pod C로만 전송이 되게 하는 식의 ingress 라던지 특정 ip 대역만 접근이 가능한다던지하는 방화벽같은 기능이 있다!

 

위의 명령어가 잘 실행되면, kube-system 이라는 namespace에 weave-net~ 으로 시작하는 pod들이 노드마다 생성되게 된다. 그러면 제대로 적용된 것.

 

ps. networkPolicy 자체를 지원하지 않는 CNI도 있다. 주의할것. 

아 그리고, 실제로는 calico가 가장 사용률도 높고 다양한 기능이 있다고 하니, 다음번에는 calico를 써봐야겠다.

 

 

 

그런데 이 과정중에, init 단계에서 에러가 발생할 수 있다.

The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get "http://localhost:10248/healthz": dial tcp [::1]:10248: connect: connection refused.

 

이런 에러(healthz)가 발생할 수 있는데, 이는 container runtime을 미리 구성해주었어야 했는데 이를 설정하지 않았기 때문.

지금은 docker를 사용하고 있으므로

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"
}
EOF  # 필요한 파일 작성
 
sudo systemctl enable docker
sudo systemctl daemon-reload
sudo systemctl restart docker # 도커 설정 반영 및 재시작


kubeadm reset
kubeadm init  # kuberenets 리셋하고 다시 init

이렇게 작성해주면 된다.

 

여기까지 성공하면 끝

반면 워커노드에서는 init 이전의 설치단계까지만 진행한 후에, 앞선 master 노드의 init이 완료될 때 출력된 kubeadm join 커맨드를 복사해서 실행하면 된다.

마찬가지로 healthz 문제가 발생하면 위와 동일하게 진행.

 

여기까지 하면 kubernetes 클러스터는 우선 구성이 되었다.

kubectl get nodes를 치면 이런식으로 결과가 나오면 완성

kubectl get pods -A로 확인해보면 이런저런 pod들이 잔뜩 있을건데 대부분 kubernetes 관리를 위한 기본 pod들이다.

 

추가로, cat <<EOF | 로 시작하는 부분들은 한 파일 내에 내용을 작성하는 리눅스의 방법 중 하나.

kubernetes 하면서 자주 사용했던 것 같다. 다시한번 확인해두자.

 

이후에는

OCI registry, chartmuseum, ingress controller, rook-ceph를 구성하는 방법을 하나씩 작성해보고자 한다.

글이 길어지면 읽을때 어려우니까 하나씩하나씩.