티스토리 뷰

| mac os 기준 쿠버네티스 설치하기

 

쿠버네티스를 사용하기 위해 가장 먼저 해야 할 일은 클러스터를 구성해야 합니다.

 

클러스터란(cluster) control plane과 node들의 집합니다. 즉, 쿠버네티스 운영의 가장 큰 단위입니다.

 

클러스터 구성

 

쿠버네티스의 클러스터는 크게 두 가지 영역으로 나누어져 있다고 볼 수 있습니다.

 

1. 제어영역의 Control Plane (Master Node) 

 

- 제어영역이라고도 불리우며 클러스터의 관리 역할을 담당합니다.

- 상태 관리 및 명령어 처리를 합니다.

 

제어 영역은 위 사진에서 (Ctrl Plane - 1,2...n 부분) 마스터 노드가 1개부터 n개 (보통 홀수개)로 구성 됩니다.

각각의 마스터 노드가 etcd, controller manager, scheduler, kube api server 구성요소를 갖고 있습니다.

 

위 그림에서

 

kubectl 명령어를 실행하면 그 명령어를 실행하는 server가 바로 kube api server 입니다.

 

조금 더 자세하게 살펴보겠습니다.

 

 

API Server

- Client의 요청을 처리하는 전통적인 Server 역할 수행

- 쿠버네티스의 리소스와 클러스터 관리를 위한 API 제공

- etcd를 데이터 저장소로 사용

 

Scheduler

- API와 서버와 통신하면서 각각의 노드가 자원을 얼만큼 사용하고 있는지 상태를 관리하며 새로운 워크로드를 띄워야할 때 

어디 노드에 해당 컨테이너를 띄워야하는지 배포를 관리합니다.

 

 

Controller Manager

앞서 설명에서는 Controller Manager가 1가지 밖에 안 보였는데 실제로는

Kube Controller Manager 와 Cloud Controller Manager로 나누어집니다.

 

- 쿠버네티스를 이해하는 데 굉장한 핵심 요소.

- 여러 컨트롤러 프로세스를 관리한다고 해서 컨트롤러 매니저로 통합되었습니다.

- 실질적으로는 Kube와 Cloud로 나누어져있습니다(위 사진 참고)

- 본인이 서비스를 운영하고자 하는 클라우드 프로바이더 환경이 있을텐데(예를들어 AWS,GCP,Azure) 각각의 환경에 맞춰 해당 AWS Provider와 통신하며 해당 클라우드 프로바이더의 종속적인 기능들을 수행하는 역할을 합니다

인그레스를 이용하여 AWS의 ALC OR 스토리지 클래스를 이용하여 EBS를 관리할 때 Cloud Controller Manager가 쓰입니다.

- 각각의 쿠버네티스 API Resources 들(Pod,Depolyment,Service, Secret 등) 을 관리하는 컨트롤러들이 존재하는데 API Server와 통신하며 각각의 리소스들을 감시하며 변경사항이 있는지 주시합니다. etcd에 저장되어있는 상태와 비교했을 때 변경 사항이 있다면 클러스터에 반영합니다.

 

이 과정을 reconcile 이라고 합니다.

 

etcd

- 보통 마스터 노드에 내장되어 있는 경우가 많습니다. (따로 분기해서 관리도 가능함)

- 분산 Key - Value 저장소로 클러스터에 상태 저장. (보안 처리 때문에)

나중에 쿠버네티스 클러스터를 백업 및 복구하는 작업이 필요하다면 etcd만 백업 / 복구하면 됩니다.

 

 

 

 

 

2.Node(Worker Node === Data plane)  

- 보통 노드라고 부르며 어플리케이션 컨테이너를 실행합니다.

 

각각의 노드에 동일한 컴포넌트로 구성되어있는데 Container Runtime위에 Pods가 실행되는 형태입니다.

그 외 시스템 형태로 kubelet, kube-proxy,CRI 등이 있습니다.

 

 

핵심 컴포넌트 : kubelet 과 proxy

 

Kubelet

- 모든 노드에 설치되는 컴포넌트

- API Server와 통신하며 노드의 리소스 관리 (보고 역할도 수행 CPU 수, 메모리 수 등)

- 컨테이너 런타임(Container Runtime)통신하며 컨테이너 라이프사이클을 관리합니다.

 

CRI(Container Runtime Interface)

- 쿠버네티스가 도커로부터 dependency를 없애고 여러 컨테이너 런타임을 지원(밑에서 설명할 Docker나 containerd, cri-o등) 하기 위한 interface입니다.

- kubelet이 컨테이너 런타임(Container Runtime) 과 통신할 때 사용되는 interface입니다.

- 쿠버네티스는 Docker, containerd, cri-o 컨테이너 런타임을 지원합니다.

 

 

kube-proxy

- 각 노드에 띄워짐

- 클러스터상에 오버레이 네트워크 구성

- 네트워크 프록시 및 내부 로드밸런서 역할 수행

 

일반적으로 각각의 서비스 운영은 각각의 클러스터를 구축하여 운영하는 것이 일반적입니다.

 

 

 

 

Kubectl 설치

 

 

먼저 kubectl이라는 녀석을 설치해줍시다.

 

왜 이놈을 설치하냐? 이 녀석이 바로 쿠버네티스의 API 서버와 통신하여 다양한 object들의 상태 확인 또는 사용자 명령을 전달할 수 있는 CLI 도구이기 때문이죠.

 

 

docker desktop에는 kubectl이 내장되어 있다. 

근데 왜 설치를 하냐?

-> 최신 버전을 유지하기 위함이다.

 

이 과정에서 충돌이 일어난다면 최신 version으로 덮어써야 한다.

 

해당 명령어를 실행해주자. (충돌이 있는 사람만)

 

 

Kustomize 설치

 

 

kustomize 란 녀석도 설치해줍니다.

 

얜 또 뭐냐 ?

 

 

쿠버네티스의 manifest.json 파일을 효율적으로 관리할 수 있도록 도와주는 도구입니다.

그러니 설치해 줍시다.. (설치하는 게 많죠?)

 

설치 후 확인 제대로 설치 됐다.

 

끝난 줄 아셨죠 ?

 

한 놈 또 있습니다.

 

 

minikube 설치

 

 

클러스터를 구축하는 방법에는 여러 가지가 존재합니다.

 

그중 local 환경에서 가장 쉽게 클러스터를 구축할 수 있게 해 주는 도구 "minikube"입니다.

 

minikube는 단일노드(master와 worker노드 함께 사용)입니다.

 

minikube는 여러 driver를 제공해주는데, 이 driver를 선택해서 쿠버네티스 node를 어떤 환경으로 구성할지 선택할 수 있습니다.

ex) vm 웨어, 가상 머신 기반 클러스터 구성 등

 

저희는 도커 드라이버로 도커 컨테이너 기반 쿠버네티스 클러스터 노드 역할을 수행하도록 해서 싱글 노드로 구성하게 만들어주는 것입니다.

 

위와 비슷한 방법으로 K3S OR MicroK8s 등이 존재합니다.

 

왼쪽 Azure의 AKS Google의 GKE AWS의 EKS라는 쿠버네티스 클러스터를 제공해주고 있습니다.

 

Red hat 같은 경우 쿠버네티스를 매핑하여 쿠버네티스 기반 플랫폼을 제공해주기도 합니다.

 

 

다양한 로컬 쿠버네티스 배포판 종류

 

 

 

왜 로컬 쿠버네티스 배포판을 선택했나?

 

- 로컬 쿠버네티스는 단일 노드에 빠르게 쿠버네티스 구성 및 테스트가 가능합니다.

 

- 쿠버네티스는 멀티 노드로 구성되는 클러스터에서 컨테이너를 관리하는 오케스트레이션 system이기 때문에 기본적으로 멀티노드 환경에서 운영이 되어야 하지만, 간단한 테스트를 하기 위한 목적에서 클러스터를 구성하는 게 복잡하기 때문에 로컬 쿠버네티스 배포판을 이용하는 것입니다. (단, 일부 기능들이 제한받습니다.)

 

- 클라우드 플랫폼에서만 사용 가능한 기능 : ALB(application 로드밸런서), NLB(네트워크 로드밸런서), EBS in AWS (스토리지 서비스 관리)

 

- 여러 노드 환경에서 사용 가능한 리소스 불가능

ex: DaemonSet, Affinity / Taint / Toleration / Node Selector 등

 

 

운영용 쿠버네티스 환경 구축(배포) 3가지 방법

               주의!              

 

운영 환경에서의 쿠버네티스 버전 선택이 중요합니다.

 

AWS의 EKS 최신 버전과 쿠버네티스의 최신 버전을 항상 확인하셔야 하고, 운영 환경에서 쿠버네티스를 관리한다면,

 

- Major 버전 업데이트의 ChangeLog와 Breaking Changes를 꼼꼼히 검토해야 합니다.

 

- API Resources Deprecation Schedile 역시 검토해야 합니다.

쿠버네티스의 스케쥴 관리표

위의 표는 쿠버네티스의 버전별 업데이트 스케줄 관리 현황입니다. 이전 버전에 대해 지원을 중단하는 게 아닌 지원 기간을 가져가고 있습니다.

따라서 항상 가장 최신의 버전을 사용하기보다는 검증하기 전까지 지켜보다가 업데이트를 하는 것이 옳다고 생각합니다.

 

 

 

 

자 그럼 설치해 봅시다!

 

 

minikube 설치

 

주의사항은 minikube를 설치 전 반드시 설치하여야 합니다.

 

쉽게 말해 cluster를 쉽게 구축해주는 도구입니다.

모두 다 설치되었으면 이제 클러스터를 구성해보겠습니다.

 

 

docker driver를 이용하여 minikube(미니 쿠베)로 쿠버네티스 클러스터를 구성합니다.

 

$ minikube start —driver=docker

 

minikube v1.25.1과  Kubernetes 1.23.1.로 설치되었습니다.

 

 

config 파일 확인

 


kubernetes cluster와 kubectl의 연결을 위한 정보가 담긴 config 파일

 

minikube와 관련된 설정 파일입니다.

클러스터 user current-context 확인이 가능합니다.

 

현재 쿠버네티스의 클러스터 상태 확인

 

 

현재 쿠버네티스의 클러스터 정보 확인

 

 

 

기타 명령어

 

클러스터 일시정지

 

$ minikube pause

 

클러스터 재가동

 

$ minikube unpause

 

클러스터 종료

 

$ minikube stop

 

kubernetes cluster를 위해 구동되었던 minikube docker container가 종료되며 cluster가 종료되게 된다.
또한 cluster와 kubectl의 연결을 위해 사용되었던 ~/.kube/config 파일의 내용도 모두 사라진다.

 

 

 

클러스터 삭제

 

$ minikube delete

 

stop을 통한 cluster의 종료는 저장되어 있는 생성된 리소스들의 정보를 삭제하지 않아 다시 시작할 때 복원을 해주지만, delete를 통해 cluster를 종료한다면 이러한 정보들까지 모두 삭제한다.


따라서 delete 후 다음번 minikube를 시작 시 완벽히 초기 상태로 시작이 된다.