k3s로 쿠버네티스 클러스터 구축하기

쿠버네티스 도구

쿠버네티스를 처음 구성할 때 사용할 수 있는 도구는 어떤 것들이 있는지 살펴보자. 쿠버네티스는 용도에 따라 선택 가능한 도구가 여러 가지이고, 각 도구별로 설치 방법이나 구성 방법이 다르기 때문에 어떤 도구를 선택할지 판단하는 것은 아주 중요한 작업이다.

• Minikube
  로컬 시스템에 쉽게 설치할 수 있고 쿠버네티스가 제공하는 대부분의 기능을 활용할 수 있다. 개발 도구들과 연계해서 사용할 수 있어 편리하다. 하지만 로컬에 설치되어 단일 노드만 지원하기 때문에 다중 노드를 구성할 수 없고 노드를 가상화된 형태로 생성하기 때문에 가상화 도구가 추가로 필요하다.

• k3s
  단일 파일로 이루어진 k3s 실행 파일을 통해 서버와 에이전트만 구동하면 쿠버네티스의 각 구성 요소가 간편하게 설치되면서 쿠버네티스 클러스터를 쉽게 구성할 수 있다. 구성 요소가 매우 단순하기 때문에 학습용이나 가벼운 환경을 구성하는데 적합하다.

• Rancher
  k3s와 마찬가지로 Rancher Labs에서 만들었다. 대규모 클러스터 및 기업용 환경에도 적합한 쿠버네티스 관리 플랫폼이다. 랜처는 무료로 사용할 수 있는 오픈소스 버전과 더불어 기술 지원을 받을 수 있는 상용 버전을 함께 제공하고 있다. 쿠버네티스 클러스터뿐 아니라 운영에 필요한 모니터링, 보안 관련 기능을 쉽게 설치할 수 있다. 또한 랜처의 관리 도구를 사용해서 새로운 쿠버네티스 클러스터를 쉽게 생성하고 여러 클러스터를 한곳에서 관리할 수 있다. 다만 랜처는 대규모 시스템 관리까지 염두에 둔 플랫폼이므로 자체적인 구성 요소가 많이 포함되어 있으며 이로 인하여 다른 도구에 비해 조금 더 무거운 면이 있다.

• Kubeadm
  기본적인 상태의 쿠버네티스를 시스템상에 구성해 주는 도구이다. 사용자가 기본적인 쿠버네티스 클러스터 구성 이외에 운영에 필요한 서비스, 스토리지, 모니터링 등의 세부 구성 요소를 직접 설정해야 한다. 그렇기 때문에 처음 쿠버네티스를 접하는 분들은 kubeadm을 통해서 쿠버네티스 환경을 구축하는 것이 조금 어려울 수 있다. 하지만 세부적인 설정을 할 수 있는 전문적인 사용자라면 자신의 환경에 맞는 쿠버네티스 클러스터를 설정할 수 있다.

• Goldpinger
  쿠버네티스 클러스터 내에서 실행되면서 노드 간 관계를 인터랙티브한 지도로 표시하는 간단한 툴이다.

• k9s
  쿠버네티스 클러스터를 위핸 전체 화면 CLI UI다. 실행 중인 파드, 로그, 배포를 한눈에 확인하고 쉘에 빠르게 접근할 수 있다.

 

다 기재하진 못했지만 위 도구들 뿐만 아니라 훨씬 더 많은 쿠버네티스 도구들이 존재하고 이 중에서 나는 k3s를 사용하여 쿠버네티스 클러스터를 구성해볼 것이다.

k3s 란

k3s는 경량화 된 버전의 쿠버네티스로 Lightweight Kubernetes라고도 불린다. 일단 설치가 간편하다. 또한 기존의 k8s에서 메모리 사용량을 절반으로 줄였고, 모든 구성 요소를 100MB 이하의 binary로 제공한다. 쿠버네티스와 완전히 호환되며 쿠버네티스의 유용한 기능들은 사용하되 큰 아키텍처가 아닌 경우에 선택하기에 적합하다. k8s(맨앞의 k와 맨뒤의 s사이의 8글자 , 총 10자)로 표기되는 쿠버네티스의 절반의 크기라는 의미로 10자의 반절인 5자로 표현하여 k3s라는 형태가 되었다.

Kubernetes에는 수 많은 기능들이 포함되어 있고, 또한 수많은 플러그인들이 따로 존재한다. 하지만, k3s는 이를 단순화 시켜, 잘 사용하지 않는 기능들이나, 각종 실험적인 기능들을 제거 했고, 또한 몇가지 꼭 필요한 플러그인들을 기본적으로 포함시켜서 배포하고 있기 때문에, 단순히 설치하는 것만으로도 어렵지 않게 쿠버네티스를 운영해 볼 수 있도록 해 두었다.

k3s의 주요 특징으로는 단일 파일로 이루어진 k3s 실행 파일을 통해 서버와 에이전트만 구동하면 쿠버네티스의 각 구성 요소가 간편하게 설치되면서 쿠버네티스 클러스터를 쉽게 구성할 수 있다는 점이다. 특히 내장 구성 요소 중 쿠버네티스의 각종 환경 정보를 저장하는 ETCD는 경량의 내장 데이터베이스인 SQLite로 대체되어 매우 가볍게 동작한다. 그래서 k3s는 사물인터넷(IoT) 용도 혹은 라즈베리파이 같은 학습용 초소형 컴퓨터에도 사용할 수 있다는 장점이 있다.

물론 높은 쿠버네티스 호환성을 제공하기 때문에 단순 학습 용도를 넘어 소규모의 운영 환경에도 적용할 수 있다. 그렇지만 대부분의 구성 요소가 매우 단순화되어 있어 높은 성능과 안정성을 요구하는 시스템에는 부적합할 수 있다.

k3s에 대해서도 요약하자면 아래와 같다.

• 용도 : 쿠버네티스와 완전히 호환되는 가벼운 배포판
• 장점 : 설치가 쉽고 시스템 리소스를 적게 사용하면서 높은 쿠버네티스 호환성을 보장함
• 단점 : 구조가 매우 단순하므로 높은 성능과 안정성을 요구하는 시스템에는 부적합할 수 있음

K3S의 구조

k3S 설치

curl -sfL https://get.k3s.io | sh -
# curl이 세부 정보를 화면에 표시하고, sh가 실행 결과를 추가적으로 출력
curl -sfL https://get.k3s.io | sh -s -
# curl의 세부 정보가 억제되고, sh가 실행 결과를 출력 (조용한 실행)
curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 644
# kubeconfig 파일의 퍼미션을 지정
# kubeconfig 파일에는 Kubernetes 클러스터에 대한 접근 권한이 포함되어 있다.
# kubectl 명령어를 사용하기 위해선 kubeconfig 파일에 접근할 수 있는 권한이 있어야 한다 (미설정 시 600)

Kubernetes를 관리하기 위해선 kubectl 이라는 프로그램을 추가로 설치해야한다. 하지만 k3s를 설치하면 kubectl 뿐만 아니라 crictl, ctr, k3s-killall.sh 및 k3s-uninstall.sh를 포함한 추가 유틸리티가 자동으로 설치된다. 사실 k3s를 설치하는 명령어 한줄이면 single node cluster kubernetes를 구축할 수 있다. 쿠버네티스는 관리를 위한 master와 실제 서비스가 동작하는 worker로 이루어진다. Single node cluster(컴퓨터 1대로 만드는 클러스터)의 경우, 한 대의 컴퓨터가 master와 worker의 역할을 모두 하는 것이고, multi node cluster(컴퓨터를 여러개 묶어서 만드는 클러스터)의 경우, master와 worker가 분리되어 있는 형태다. master가 worker를 조종하는 역할이므로, master가 1대만 있고, 그 1대가 죽어버리면 쿠버네티스 클러스터 전체가 동작하지 않을테니 보통 3대를 둔다.

모든 테스트가 끝나면 깔끔하게 삭제하고 싶을 것이다. 아래의 명령을 이용하면 k3s를 삭제하면서 kubernetes의 모든 것들을 삭제할 수 있다.

/usr/local/bin/k3s-uninstall.sh

kubectl

그렇다면 kubectl이 뭘까? kubectl은 쿠버네티스 클러스터에 명령을 내리는 CLI(command line interface)이다. 쿠버네티스의 상태를 확인하고, 원하는 상태를 요청할 수 있고, 컨테이너 로그도 확인할 수 있고, 원격으로 접속할 수도 있다.

• kubectl apply -f [파일명 또는 URL]
  원하는 리소스의 상태를 YAML로 작성하고 apply 명령어로 선언

• kubectl get [TYPE]
  쿠버네티스에 선언된 리소스를 확인

• kubectl describe [TYPE]/[NAME] 또는 [TYPE] [NAME]
  쿠버네티스에 선언된 리소스의 상세한 상태를 확인

• kubectl delete [TYPE]/[NAME] 또는 [TYPE] [NAME]
  쿠버네티스에 선언된 리소스를 제거

• kubectl logs [POD_NAME]
  컨테이너의 로그를 확인
  실시간 로그를 보고 싶다면 -f 옵션을 이용하고 하나의 Pod에 여러 개의 컨테이너가 있는 경우는 -c 옵션으로 컨테이너를 지정

• kubectl exec [-it] [POD_NAME] -- [COMMAND]
  컨테이너에 접속하는 명령어
  쉘로 접속하여 컨테이너 상태를 확인하는 경우에 -it 옵션을 사용하고 여러 개의 컨테이너가 있는 경우엔 -c 옵션으로 컨테이너를 지정

• kubectl config current-context
  현재 어떤 컨텍스트로 설정되어 있는지 확인

• kubectl config use-context [컨텍스트]
  컨텍스트 설정

kubectl은 여러 개의 쿠버네티스 클러스터를 컨텍스트(context)로 설정하고 필요에 따라 선택할 수 있다.

kubectl 명령어가 은근 오타가 잘나기 때문에 다음 명령으로 예약어를 지정해 두고 사용할 수 있다.

echo "alias k='kubectl'" >> ~/.bashrc
source ~/.bashrc

쿠버네티스 앱 배포

쿠버네티스를 통해 애플리케이션을 배포하기 위해서는 세 가지 영역을 설정해야 한다. 클러스터의 desired state를 기술한 Deployment, 이를 네트워크 서비스로 노출시키는 Service, 그리고 클러스터 외부에서 클러스터 내부의 서비스로 접근할 수 있게 만들어주는 Ingress, 이 세 가지를 각각 설정해줘야 한다. Ingress를 작성하지 않더라도 서비스 자체를 띄우고 포트 포워딩을 통해 서비스에 접속할 수는 있다. 하지만 프로덕션 단계에서는 클러스터 외부에서도 서비스에 접속이 가능해야하기 때문에 이때 Ingress 설정이 필요하다.

인그레스(Ingress)

쿠버네티스 인그레스는 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 및 리소스이다. 인그레스를 사용하면 여러 서비스를 동일한 IP 주소 및 포트에서 공개할 수 있다. 이는 클러스터 외부에서 내부 서비스에 대한 경로 및 규칙을 정의하는 데 사용된다.

인그레스 컨트롤러가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다. ingress-nginx 등 여러 인그레스 컨트롤러 중에서 선택하여 배포할 수 있다. 모든 인그레스 컨트롤러는 참조 사양이 맞아야 한다. 실제로, 다양한 인그레스 컨트롤러는 조금 다르게 작동한다.

인그레스 컨트롤러는 이러한 인그레스 리소스를 처리하고, 클러스터 외부에서 내부 서비스로의 트래픽을 효과적으로 관리한다. 이를 통해 개발자는 복잡한 네트워킹 설정 없이도 서비스를 외부에 공개하고, 효율적으로 트래픽을 관리할 수 있다.

다음은 인그레스가 모든 트래픽을 하나의 서비스로 보내는 간단한 예시이다.

인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통 Service.Type=NodePort 또는 Service.Type=LoadBalancer 유형의 서비스를 사용한다.

k3s에서도 쿠버네티스 인그레스 개념을 지원하고 유사하게 동작한다. 사용자는 인그레스 리소스를 정의하여 서비스의 외부 액세스를 구성할 수 있다. 이 인그래스 리소스는 특정 경로나 호스트에 따라 어떤 서비스로 트래픽을 라우팅해야 하는지를 정의한다.

다음은 간단한 k3s 인그레스 리소스의 예시이다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /app
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 80

이 인그레스 리소스는 example.com/app 경로로 들어오는 HTTP 트래픽을 app-service라는 서비스로 라우팅한다. metadata 섹션에서 네임스페이스가 명시적으로 지정되지 않았으므로, 인그레스 리소스는 자동으로 default 네임스페이스에 배치된다.

k3s는 이러한 인그레스 리소스를 처리하고, 클러스터의 인그레스 컨트롤러를 통해 외부로의 트래픽을 효과적으로 관리한다. 이를 통해 사용자는 k3s 클러스터에서 간단하게 인그레스 설정하여 서비스를 외부에 노출하고, 효과적으로 트래픽을 관리할 수 있다.

만약 k3s에서 별도의 인그레스 컨트롤러가 지정되지 않으면 기본적으로 traefik이라는 인그레스 컨트롤러가 사용된다. k3s는 경량화된 쿠버네티스 배포를 지향하기 때문에 기본적으로 traefik을 내장하고 있어서 따로 설정하지 않아도 traefik을 통해 인그레스 리소스를 처리할 수 있다.

Reference

• https://k3s.io/
• https://docs.k3s.io/
• https://blog.ggaman.com/1018
• https://www.samsungsds.com/kr/insights/kubernetes-2.html
• https://subicura.com/k8s/guide/kubectl.html#kubectl-%E1%84%86%E1%85%A7%E1%86%BC%E1%84%85%E1%85%A7%E1%86%BC%E1%84%8B%E1%85%A5
• https://kubernetes.io/ko/docs/concepts/services-networking/ingress/
• https://velog.io/@rhee519/deployment-service-ingress