Motivation
맥북을 개발용 컴퓨터로 두고 나니 쿠버네티스를 돌리기에는 컴퓨터 사양이 너무 부족했습니다. 그래서 몇 달 전 10만원 언저리로 쿠버네티스용 윈도우 컴퓨터를 구매 후 kubeadm 통해 가상 머신 위에서 멀티 노트 클러스터를 구축하여 이래저래 잘 사용해왔습니다만 그만 클러스터가 복구 불가능할 정도로 망가져버리고 말았습니다.
virtualbox로 가상머신 3대를 통해 노드 3대를 만들었는데, 가상 머신 이미지도 맛이 가버린 상황에서 다시 처음부터 설치를 하려니 도저히 손이 안가더라구요. 이럴꺼면 잘 좀 정리해놓을껄 싶은 순간이였습니다.
그런데 여기서 생각해보니, 굳이 여러 노드로 돌려야 하는지는 의문이 들더군요. 물론 업무를 한다면 여러 노드를 돌리는게 재현성이 훨씬 좋겠지만, 제가 쿠버네티스를 윈도우에서 돌리는 이유는 결국 학습이니까요. 학습을 위해서라면 단일 노드 환경도 문제가 없겠다는 판단하에, minikube와 docker-desktop을 활용해야겠다는 결론을 내렸고 그 중에서 docker-desktop을 통해 상호작용이 가능한 docker-desktop 버전의 쿠버네티스를 사용해야겠다고 최종적인 방향을 정했습니다.
Docker Desktop 설치
먼저 Docker Desktop을 설치해야겠죠. Docker Desktop은 다음의 웹페이지에서 쉽게 설치가 가능합니다.
https://www.docker.com/products/docker-desktop
설치가 완료됐다면 이후 로그인 완료하시고 접속해주시면 되겠습니다.
Docker 실행 후 1시 방향의 톱니바퀴를 눌러주시면 Kubernetes 메뉴가 옆에 있습니다. Enable Kuberntes를 체크하고 Apply & Restart를 누르면 Kubernetes 설치가 진행됩니다.
설치하는데 생각보다 시간이 많이 걸리니 (제 경우 10분 걸렸습니다) 차분하게 완료가 될때까지 기다려주세요. 이후 정상적으로 설치가 완료되었다면 다음과 같이 쿠버네티스 아이콘이 활성화됩니다.
쿠버네티스 사용하기
쿠버네티스는 kubectl이라는 cli 명령어 인터페이스로 관리가 됩니다. 말 나온김에 쿠버네티스 구조를 살펴보면 다음과 같습니다.
일반적으로 고가용성을 보장하는 쿠버네티스는 Multi-node 환경으로 구성이 되어 있습니다. 그림에서 볼 수 있는 것처럼 Master가 중앙에서 각 Worker들에게 명령을 내리는 구조이구요. 이때 kubectl은 Master에게 kubeapi server와 통신하며 본인의 요구사항을 전달하는 매개가 됩니다.
쿠버네티스 구조를 설명하는 글은 아니기 때문에 해당 주제는 여기서 줄이도록 하고 계속해서 클러스터를 살펴보도록 하겠습니다.
간단히 몇 가지 명령어를 실행해보겠습니다.
# kubectl 의 버전 확인
# Client 및 Server 의 버전을 확인할 수 있습니다.
$> kubectl version --short
Client Version: v1.25.4
Kustomize Version: v4.5.7
Server Version: v1.25.4
# 클러스터 정보 확인
# k8s의 컨트롤 패널의 정보를 가져올 수 있는 endpoint를 알려줍니다.
# kubernetes.docker.internal 은 k8s 설치시 hosts 파일에 자동으로 등록된 정보입니다. 127.0.0.1 kubernetes.docker.internal
$> kubectl cluster-info
Kubernetes control plane is running at https://kubernetes.docker.internal:6443
CoreDNS is running at https://kubernetes.docker.internal:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
# 노드 정보 확인
$> kubectl get nodes
NAME STATUS ROLES AGE VERSION
docker-desktop Ready control-plane 9m10s v1.25.4
만약 kubectl의 서버가 뜨지 않았다면, 가장 먼저 root 유저로 해당 명령어를 입력하지는 않았는지 확인해주시기 바랍니다. kubectl config 파일을 별도로 root 유저 쪽에도 설정해주지 않으셨다면, kubectl을 root 유저에서 실행해도 server에 요청이 전달이 되지 않았습니다.
그럼에도 문제가 된다면 Docker Desktop의 쿠버네티스가 정상적으로 설치되지 않았을 확률이 높습니다. 다양한 경우의 수가 있지만, 계속해서 문제가 된다면 대신 minikube를 활용해보시는 것을 추천드립니다.
Kubernetes Dashboard 설치
물론 CLI만을 활용해서 쿠버네티스를 다루는 것도 좋지만, GUI를 통해서도 접근이 가능하다면 훨씬 훌륭하겠죠.
해당 글에서는 쿠버네티스 공식 문서에서 제공하는 웹 대시보드를 설치해보려고 합니다.
https://kubernetes.io/ko/docs/tasks/access-application-cluster/web-ui-dashboard/
설치는 쿠버네티스 공식 github에서 제공하는 yaml을 사용합니다.
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml
설치가 완료되었다면 다음의 명령어를 통해 확인해줍니다.
$> kubectl get deployment -n kubernetes-dashboard
NAME READY UP-TO-DATE AVAILABLE AGE
dashboard-metrics-scraper 1/1 1 1 44s
kubernetes-dashboard 1/1 1 1 45s
설치가 완료되었지만 대시보드에 접속하기 위해서는 proxy 설정이 필요합니다.
$> kubectl proxy
혹 쿠버네티스의 proxy가 생소하신 분들은 쿠버네티스의 공식 문서을 참조해보시는 것을 추천드립니다.
해당 문서에서는 다양한 쿠버네티스에서 활용되는 다양한 proxy를 설명하고 있으며, 우리가 활용하고자 하는 kubectl proxy에 대한 특징을 다음과 같이 설명합니다.
✅ 사용자의 데스크탑이나 파드 안에서 실행한다.
✅ 로컬 호스트 주소에서 쿠버네티스의 API 서버로 프락시한다.
✅ 클라이언트로 프락시는 HTTP를 사용한다.
✅ API 서버로 프락시는 HTTPS를 사용한다.
✅ API 서버를 찾는다.인증 헤더를 추가한다.
로컬 호스트의 주소를 쿠버네티스의 적절한 파드로 넘겨준다 정도로 이해하고 넘어가주시면 되겠습니다.
성공적으로 proxy가 동작한다면 다음의 주소로 접속해봅시다.
http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login
문제가 없다면 다음과 같이 정상적으로 접속이 가능한 것을 확인할 수 있습니다.
대시보드가 성공적으로 동작하지만, 아쉽게도 대시보드가 쿠버네티스를 자동으로 추적하지는 못합니다. 때문에 추가적인 인증 과정을 거쳐 대시보드에 쿠버네티스를 등록해주는 과정이 필요합니다.
해당글에서는 토큰을 기반으로 하는 인증을 수행할 예정입니다. 이러한 인증 과정은 Bearer Authentication이라고 불리기도 합니다.
쿠버네티스에서 Bearer 토큰을 발급하기 위해서는 다음의 과정을 거쳐야 합니다.
먼저, 해당 토큰을 발급할 주체인 Service Account를 생성해줍시다.
생성을 위해서는 아래의 텍스트를 yaml 파일로 저장합니다.
apiVersion: v1
kind: ServiceAccount
metadata:
name: dashboard-admin
namespace: kubernetes-dashboard
이후 적용하여 생성합니다. 파일 이름의 경우 유동적으로 설정해주시면 됩니다.
$> kubectl apply -f 0.svc.yaml
serviceaccount/admin-user created
생성이 완료되었다면, 앞서 생성한 Service Account에 권한을 부여해줘야 합니다.
쿠버네티스에서는 권한을 Role로 관리해주게 되는데, 이러한 Role을 부여해주는 행위를 Role Binding이라고 합니다.
아래의 yaml 파일은 쿠버네티스 클러스터에 대한 권한을 Service Account에게 부여해주는 스크립트입니다. 쿠버네티스에는 기본적으로 제공하는 여러 Role이 있으며 그중에서 Cluster Role은 Cluster에 대한 권한을 의미하는 특별한 의미의 Role 입니다. 그 중에서 우리는 cluster-admin이라는 역할을 앞서 생성한 Service Account에 부여해주려고 합니다.
마찬가지로 파일로 먼저 생성한 이후에 적용하여 생성해줍시다.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: dashboard-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: dashboard-admin.yaml
namespace: kubernetes-dashboard
$> kubectl apply -f 1.cluster-role-binding.yaml
clusterrolebinding.rbac.authorization.k8s.io/dashboard-admin created
최종적으로 다음의 명령을 통해 Bearer Token을 발급받을 수 있습니다.
$> kubectl -n kubernetes-dashboard create token dashboard-admin
토큰이 발급되었다면 콘솔창에 출력된 긴 문자를 복사 후에 아까 띄워두었던 웹페이지에 붙여넣어 줍니다. 이후 아래의 화면이 띄게 되면 모든 설정이 완료되게 됩니다.
아직은 클러스터 내에 아무런 앱이 떠 있지 않기 때문에 볼 수 있는게 없지만 배포 이후에는 다음의 대시보드 형태를 통해 클러스터 내의 리소스를 GUI 형태로 모니터링할 수 있게 됩니다.
k9s 설치하기
마지막으로 kubectl 대신 kubenetes를 더욱 쉽게 관리하도록 도와주는 k9s를 설치하고 해당 글을 마무리하려고 합니다.
설치 자체는 간단합니다.
제가 작업하는 리눅스(wsl)의 경우에는 다음의 명령을 통해 설치합니다. 명령어가 복잡해보이지만 사실 설치하고 압축 해제하는 것 말고는 없습니다.
curl -s -L https://github.com/derailed/k9s/releases/download/v0.26.7/k9s_Linux_x8
6_64.tar.gz -o k9s && tar -xvf k9s && chmod 755 k9s && rm LICENSE README.md && sudo mv k9s /usr/local/bin
맥에서는 더욱 간단합니다. 패키지 관리자인 brew에 이미 k9s가 포함되어 있기 때문에 바로 설치가 가능합니다.
brew install k9s
최종적으로 설치가 완료되었다면 k9s를 실행해봅시다. 주의할 점은 root가 아닌 쿠버네티스 context가 존재하는 user에서 실행해주셔야 합니다.
다음의 명령어를 통해 실행해주시면 아래와 같은 텍스트 기반 GUI를 확인하실 수 있습니다.
k9s
'DevOps' 카테고리의 다른 글
gchr.io를 활용한 도커 이미지 관리 (1) | 2023.05.22 |
---|---|
[Kubeflow] pipeline (0) | 2023.04.07 |
[Kubeflow] MLOps 개발환경 설정 (0) | 2023.04.07 |
error: parsing file '/var/lib/dpkg/updates/0001' near line 0: newline in field name `#padding' (0) | 2023.03.23 |
Could not get lock /var/lib/dpkg/lock-frontend (0) | 2023.03.23 |