[k8s] kind 활용, Local PC에서 Kubernetes 설치

기존의 회사에서는 AWS EKS 플랫폼을 이용해 회사 서비스를 올리고, 운영을 하고 있었다.

그렇기 때문에 Control Plane 관리에 대해서는 AWS에 일임하였기 때문에 관심대상이 아니였으나

최근에 IDC 환경에 직접 서버에 Kubernetes를 운영하는 회사로 이직을 하였다.

그래서 공부하기 위해서 Local PC에 Kubernets 환경 조성이 필요했고, 간단한 환경 조성 방법에 대해 알아보자.

---

Kubernetes란?

많은 회사에서 EKS, ECS, GKE 또는 직접 Kubernetes를 운영하고 있다.

Kubernetes는 컨테이너화 된 애플리케이션을 배포하고, 확장하고, 운영할 수 있도록 설계된 오픈소스이다.

최초 Google에서 개발되었으나, 현재는 CNCF에서 관리하고 있다.

즉, 다시 말하면 여러개의 컨테이너를 효율적으로 관리할 수 있도록 다양한 개념을 제공하는 플랫폼이다.

 

Kubernetes에는 여러개의 Node로 구성되어 있고 역할에 따라 Control Plane, Worker Node로 구분한다.

그리고 Control Plane에는 kube-apiserver, etcd, kube-scheduler, kube-controller-manager 컴포넌트가 존재하고 Worker Node에는 kubelet, kube-proxy 컴포넌트가 존재한다.

 

각 컴포넌트에 대한 역할과 동작 방법에 대해서는 더 자세하게 공부하고 별도 게시물로 작성하도록 하겠다.

 

Kubernets Local 환경 구성

Local PC에 Kubernetes 환경을 구성하는 방법은 다양하게 존재한다.

Docker App에서 K8s 옵션을 활성화할 수도 있고, Kind(kubernetes in Docker), Minikube 등의 방법도 존재한다.

Kubernetes 공부하는 게시물을 보면 Minikube로 구성하는 게시물이 많으나, 나는 Kind의 방법으로 구성을 했다.

Kind란?

Kind는 Docker 컨테이너 위에서 Kubernetes 클러스터를 실행할 수 있도록 도와주는 경량 Kubernetes 오케스트레이션 툴이다.

즉, Docker 컨테이너를 개별 Kubernetes 노드처럼 사용하는 것이다.

그래서 Control Plane, Worker Node가 Docker 컨테이너로 뜨게 된다.

 

설치 방법

Mac을 사용한다는 가정하에 설치하는 방법은 brew를 이용하면 쉽게 Kind를 설치한다.

brew install kind

Mac Brew Kind

 

그리고 kind 문법에 맞춰서 Cluster kind yaml을 만든 다음에 kind create를 하면 된다.

kind create cluster --config ./local_k8s.yaml
---
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: local-test-k8s
nodes:
- role: control-plane
- role: control-plane
- role: control-plane
- role: worker
- role: worker
- role: worker
networking:
  podSubnet: "10.244.0.0/16"
  serviceSubnet: "10.96.0.0/12"
  kubeProxyMode: "iptables"

 

기본적으로 Control-Plane 3개 이상으로 HA 구성하는걸 권고하기 때문에 Control Plane 3개, Workfer Node 3개를 생성했다.

• 각 컴포넌트 노드는 상황에 따라서 달라지기 때문에 맞춰서 그 수를 수정하면 된다.

kind create cluster

 

Controle, Worker 노드 3개씩 총 6개의 도커 컨테이너가 실행되는것을 볼 수 있다.

• 앞서 kind는 kubernetes Node 컴포넌트를 도커 컨테이너로 실행해서 클러스터를 구성해주는 도구라고 설명했다.
• kind로 설정하면 kubectl config context도 자동으로 등록된다.

 

그리고 알고있는것처럼 Worker와 Control Plane 노드는 역할이 다르기 때문에 실행되어 있는 프로세스도 다르다.

Node Component

kind로 클러스터를 구성했을때는 Control-Plane 노드에서도 kubelet과 kube-proxy가 존재한다.(일반적으로는 존재하지 않는)

이는 Control Plane을 결국 Docker 컨테이너로 실행하기 때문에 kubelet이 필요하다.

특수하게 Control Plane에서도 Pod을 띄울수 있도록 구성되어 있기 때문에 kubelet과 kube-proxy 프로세스가 실행된다.

 

kind를 이용하면 아주 쉽게 Local에서 Kubernetes 환경을 구성할 수 있다.

그리고 다중 노드 구성이 가능하고, Kubernetes 공식 프로젝트이기때문에 신뢰성도 높은편이다.

 

하지만, 아무래도 Docker Container 기반으로 Kubernetes 노드를 띄우기 때문에 실제 물리를 이용해서 노드 구성을 하는것보다 성능이 떨어진다.

그렇기 때문에 kind는 보통 Local에서 테스트 목적으로만 운영하기 때문에 만약에 실제 운영 서비스에 적용하고자 한다면 다른 대안을 찾는걸 권장한다.

---

오늘은 간단하게 Local 환경에서 직접 Kubernetes를 구성하는 것을 확인해보았다.

이전 회사에서는 AWS EKS를 사용했기 때문에 소흘하게 공부하였던 Control Plane에 대해서 이제는 조금 더 깊게 공부해볼 생각이다.

각 컴포넌트에서는 자세하게 어떤 정보를 관리하는지, Kubernetes API를 실행할 때 흐름은 어떻게 되는지

특히 Control Plane 노드 일부가 Down 되었을때는 어떻게 HA를 보장해야하는지..

 

기존에는 Worker 노드에 오픈소스를 배포하여, 양질의 오픈소스를 사용해서 효과적으로 서비스 배포를 지원하였다면

이제는 Control Plane, Worker 노드를 어떻게 잘 운영하고 관리해야하는지로 업무의 깊이가 달라졌다.

끝!