Rancher K3s: Proxmox 컨테이너의 Kubernetes

Rancher K3s: Proxmox 컨테이너의 Kubernetes

 

LXD 컨테이너 및 K3를 사용하여 NGINX 인그레스 컨트롤러로 K8 클러스터 스핀업

오랫동안 저는 캘린더, 연락처, 이메일, 클라우드 파일 저장소, 웹사이트 등 대부분의 온라인 서비스를 자체 호스팅했습니다. 내 설정의 현재 반복은 다양한 애플리케이션을 모두 설치하고 사용하도록 구성하는 일련의 Ansible 플레이북에 의존합니다.

이것은 정말 안정적이었고 저에게 꽤 효과적이었습니다. 저는 뛰어난 관리 인터페이스를 갖춘 무료 오픈 소스 하이퍼바이저인 Proxmox의 LXD 컨테이너 세트(경량 Linux VM)에 애플리케이션을 배포합니다.

그러나 최근에 Docker와 컨테이너를 사용하여 애플리케이션을 배포할 때의 이점을 다시 배웠습니다. 그 중 일부는 다음과 같습니다.

• 보장되고 재현 가능한 환경. 애플리케이션은 실행할 준비가 된 종속성과 함께 제공됩니다.
• 휴대성. 환경이 컨테이너 런타임을 지원한다고 가정하면 애플리케이션을 지원합니다.
• 코드로서의 인프라. Ansible 플레이북과 마찬가지로 Docker는 추적 및 버전 관리가 가능한 코드를 사용하여 컨테이너 환경을 관리하는 데 적합합니다.

그래서 저는 베어 Linux Ansible 플레이북을 Kubernetes 배포 세트로 전환하는 여정을 시작하기로 결정했습니다.

그러나 Proxmox에 대해 여전히 포기하고 싶지 않은 몇 가지가 있습니다. 하나는 쉽게 컨테이너화할 수 없는 물리적 시스템(예: 라우터 또는 액세스 포인트 관리 포털)을 가상화하는 기능입니다. 호스트에서 유지 관리를 수행해야 할 때 서버 간에 "물리적" OS 설치를 마이그레이션하는 기능은 매우 유용합니다.

따라서 Proxmox에 Kubernetes를 설치하고 LXD 컨테이너에 설치하려고 합니다.

저는 LXD 컨테이너 위에 Rancher의 K3s 배포판을 사용하여 Kubernetes 클러스터를 배포할 것입니다.

K3s는 기본적으로 DNS, 네트워킹 및 기타 도구가 미리 구성된 상태로 제공되어 설정 프로세스를 간소화하는 가벼운 프로덕션 등급 Kubernetes 배포입니다. 또한 K3를 사용하면 새 작업자를 클러스터에 가입하는 것이 상당히 수월해집니다. 이것은 상대적으로 소규모 배포와 결합되어 매우 쉽게 선택할 수 있습니다.

반면에 LXD 컨테이너는 약간 이상한 선택으로 보일 수 있습니다. Proxmox에 K8을 배포하는 다른 기사는 거의 모두 컨테이너가 아닌 완전 지방 가상 머신을 사용하여 배포했습니다. 이것은 물리적 호스트에 설치하는 것과 절차상 동일하기 때문에 확실히 마찰이 적은 경로입니다. 두 가지 주요 이유로 LXD 컨테이너를 사용했습니다.

1. LXD 컨테이너는 빠른. 거의 베어 메탈만큼 빠릅니다. LXD 컨테이너는 커널 수준에서 가상화되기 때문에 기존 VM보다 훨씬 가볍습니다. 따라서 거의 즉시 부팅되고 호스트 커널과 거의 동일한 속도로 실행되며 더 많은 RAM/디스크 공간/CPU 코어로 즉석에서 재구성하기가 훨씬 쉽습니다.
2. LXD 컨테이너는 더 작습니다. 컨테이너는 호스트의 커널에서 실행되기 때문에 훨씬 더 작은 패키지 세트를 포함해야 합니다. 따라서 기본적으로 훨씬 적은 디스크 공간이 필요합니다(따라서 마이그레이션이 더 쉬워짐).

따라서 시작하기 위해 2개의 컨테이너(제어 노드 1개와 작업자 노드 1개)를 만들겠습니다.

(1) Proxmox 서버가 실행 중이고, (2) Proxmox에서 사용할 수 있는 컨테이너 템플릿이 있고, (3) 일종의 NFS 파일 서버가 있다고 가정하겠습니다.

컨테이너에 비교적 적은 양의 디스크 공간을 제공할 것이기 때문에 마지막 것은 중요합니다. 따라서 Kubernetes 포드에 필요한 모든 볼륨은 NFS 마운트로 생성할 수 있습니다.

당신은 또한 설정하고 싶을 것입니다 kubectl 그리고 helm 로컬 컴퓨터의 도구.

LXD 컨테이너는 Docker 컨테이너 자체를 실행할 수 있어야 하므로 적절한 권한을 부여하기 위해 약간의 추가 구성을 즉시 수행해야 합니다.

2개의 컨테이너를 설정하는 프로세스는 거의 동일하므로 한 번만 진행하겠습니다.

Proxmox UI에서 "CT 만들기"를 클릭합니다. 고급 설정을 표시하려면 확인란을 선택해야 합니다.

"권한 없는 컨테이너"의 선택을 취소해야 합니다.

컨테이너의 세부 정보를 입력합니다. "권한 없는 컨테이너" 확인란의 선택을 취소해야 합니다. 다음 화면에서 원하는 템플릿을 선택합니다. Rocky Linux 8 이미지를 사용하고 있습니다.

각 컨테이너에 16GiB의 루트 디스크 크기를 제공하기로 결정했습니다. 이는 디스크 자체에 볼륨을 넣지 않는 한 OS와 K3가 실행하기에 충분합니다.

CPU 및 메모리 값은 실제로 호스트에서 사용할 수 있는 모든 것과 K8 클러스터에서 실행하려는 워크로드에 달려 있습니다. 필자의 경우 컨테이너당 4개의 vCPU 코어와 4GiB의 RAM을 제공했습니다.

네트워크 구성의 경우 각 노드에 대해 고정 IP 주소를 설정해야 합니다. 또한 특정 내부 DNS 서버를 사용하는 경우(이를 적극 권장합니다!) 다음 페이지에서 구성해야 합니다.

마지막으로 마지막 페이지에서 "생성 후 시작" 확인란의 선택을 취소하고 완료를 클릭합니다. Proxmox는 컨테이너를 생성합니다.

이제 컨테이너에 적절한 권한을 부여하기 위해 몇 가지 사항을 내부적으로 조정해야 합니다. Proxmox 호스트에 SSH로 연결해야 합니다. root 사용자가 이러한 명령을 실행할 수 있습니다.

에서 /etc/pve/lxc 디렉토리에서 다음과 같은 파일을 찾을 수 있습니다. XXX.conf어디 XXX 방금 만든 컨테이너의 ID 번호입니다. 선택한 텍스트 편집기를 사용하여 생성한 컨테이너의 파일을 편집하여 다음 줄을 추가합니다.

lxc.apparmor.profile: unconfined
lxc.cgroup.devices.allow: a
lxc.cap.drop:
lxc.mount.auto: "proc:rw sys:rw"

참고: 파일을 편집하려고 할 때 컨테이너를 중지하는 것이 중요합니다. 그렇지 않으면 Proxmox의 네트워크 파일 시스템에서 파일을 저장할 수 없습니다.

순서대로 이러한 옵션은 (1) AppArmor를 비활성화하고, (2) 컨테이너의 cgroup이 모든 장치에 액세스할 수 있도록 허용하고, (3) 컨테이너에 대한 기능을 삭제하는 것을 방지하고, (4) 마운트합니다. /proc 그리고 /sys 컨테이너에서 읽기-쓰기로.

다음으로 커널 부트 구성을 컨테이너에 게시해야 합니다. 일반적으로 이것은 호스트의 커널을 사용하여 실행되기 때문에 컨테이너에 필요하지 않지만 Kubelet은 구성을 사용하여 런타임에 대한 다양한 설정을 결정하므로 컨테이너에 복사해야 합니다. 이렇게 하려면 먼저 Proxmox 웹 UI를 사용하여 컨테이너를 시작한 후 Proxmox 호스트에서 다음 명령을 실행합니다.

pct push /boot/config-$(uname -r) /boot/config-$(uname -r)

드디어, 각각의 용기에우리는 다음을 확인해야 합니다 /dev/kmsg 존재합니다. Kubelet은 이것을 일부 로깅 기능에 사용하며 기본적으로 컨테이너에 존재하지 않습니다. 우리의 목적을 위해 우리는 그것을 별칭으로 지정할 것입니다. /dev/console. 각 컨테이너에서 파일 생성 /usr/local/bin/conf-kmsg.sh 다음 내용으로:

#!/bin/sh -e
if [ ! -e /dev/kmsg ]; then
ln -s /dev/console /dev/kmsg
fimount --make-rshared /

이 스크립트는 심볼릭 링크 /dev/console ~처럼 /dev/kmsg 후자가 존재하지 않는 경우. 마지막으로 컨테이너가 SystemD 원샷 서비스로 시작될 때 실행되도록 구성합니다. 파일 생성 /etc/systemd/system/conf-kmsg.service 다음 내용으로:

[Unit]
Description=Make sure /dev/kmsg exists[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/usr/local/bin/conf-kmsg.sh
TimeoutStartSec=0[Install]
WantedBy=default.target

마지막으로 다음을 실행하여 서비스를 활성화합니다.

chmod +x /usr/local/bin/conf-kmsg.sh
systemctl daemon-reload
systemctl enable --now conf-kmsg

이제 컨테이너를 설정하고 실행했으므로 여기에 Rancher K3를 설정할 것입니다. 운 좋게도 Rancher는 의도적으로 이것을 매우 쉽게 만듭니다.

제어 노드에서 시작다음 명령을 실행하여 K3를 설정합니다.

curl -fsL https://get.k3s.io | sh -s - --disable traefik --node-name control.k8s

몇 가지 참고 사항:

• K3s는 기본적으로 Traefik 수신 컨트롤러와 함께 제공됩니다. 이것은 잘 작동하지만 대신 업계 표준 NGINX 수신 컨트롤러를 사용하는 것을 선호하므로 수동으로 설정하겠습니다.
• 다음을 사용하여 수동으로 노드 이름을 지정했습니다. --node-name 깃발. 이것은 필요하지 않을 수도 있지만 과거에 K3가 IP 주소에서 호스트 이름을 역조회하는 데 문제가 있어서 클러스터를 다시 시작할 때마다 노드 이름이 달라졌습니다. 이름을 명시적으로 지정하면 해당 문제를 피할 수 있습니다.

모든 것이 잘 진행되면 다음과 유사한 출력이 표시되어야 합니다.

이 작업이 완료되면 복사할 수 있습니다. /etc/rancher/k3s/k3s.yaml ~처럼 ~/.kube/config 로컬 머신에서 다음을 사용하여 새(단일 노드임) 클러스터를 볼 수 있어야 합니다. kubectl get nodes!

참고: 구성 파일에서 클러스터 주소를 조정해야 할 수도 있습니다. 127.0.0.1 제어 노드의 실제 IP/도메인 이름으로.

이제 작업자 노드를 K3s 클러스터에 조인해야 합니다. 이것도 매우 간단하지만 노드에 가입하려면 클러스터 토큰이 필요합니다.

다음 명령을 실행하여 찾을 수 있습니다. 제어 노드에서:

cat /var/lib/rancher/k3s/server/node-token

지금, 작업자 노드에서 다음 명령을 실행하여 K3를 설정하고 기존 클러스터에 가입합니다.

curl -fsL https://get.k3s.io | K3S_URL=https://:6443 K3S_TOKEN= sh -s - --node-name worker-1.k8s

다시 말하지만, 노드 이름을 명시적으로 지정했습니다. 이 프로세스가 완료되면 이제 작업자 노드가 kubectl get nodes:

나중에 클러스터에 가입하려는 추가 작업자 노드에 대해 이 프로세스를 반복할 수 있습니다.

이 시점에서 기능적인 Kubernetes 클러스터가 있지만 Traefik을 비활성화했기 때문에 수신 컨트롤러가 없습니다. 자, 이제 설정해 보겠습니다.

나는 사용했다 ingress-nginx/ingress-nginx NGINX 수신 컨트롤러를 설정하기 위한 Helm 차트입니다. 이를 위해 repo를 추가하고 repo의 메타데이터를 로드한 다음 차트를 설치합니다.

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install nginx-ingress ingress-nginx/ingress-nginx --set controller.publishService.enabled=true

여기서, controller.publishService.enabled 설정은 컨트롤러에 수신 서비스 IP 주소를 수신 리소스에 게시하도록 지시합니다.

차트가 완료되면 다양한 리소스가 에 표시되어야 합니다. kubectl get all 산출. (컨트롤러가 온라인 상태가 되고 로드 밸런서에 IP 주소를 할당하는 데 몇 분 정도 걸릴 수 있습니다.)

웹 브라우저에서 노드 주소로 이동하여 컨트롤러가 작동하고 실행 중인지 테스트할 수 있습니다.

이 경우 NGINX를 통해 수신할 서비스를 구성하지 않았기 때문에 404가 표시될 것으로 예상됩니다. 중요한 것은 NGINX에서 제공하는 페이지가 있다는 것입니다.

이제 완전한 기능을 갖춘 Rancher K3s Kubernetes 클러스터와 NGINX 수신 컨트롤러가 구성되어 사용할 준비가 되었습니다.

이 클러스터는 유지 관리 및 확장이 정말 쉽습니다. 노드를 더 추가해야 하는 경우 다른 LXD 컨테이너(다른 물리적 호스트에 있을 수도 있고 아닐 수도 있음)를 가동하고 이 섹션을 반복하여 작업자를 클러스터에 연결합니다.

Kubernetes를 배우고 전환하는 여정을 기록으로 몇 가지 더 작성할 계획이므로 이와 같은 내용을 계속 지켜봐 주시기 바랍니다. 이 프로세스의 다음 단계는 Let's Encrypt SSL 인증서를 자동으로 생성하고 클러스터에 간단한 애플리케이션을 배포하도록 cert-manager를 구성하는 것입니다.

이 게시물은 원래 내 블로그(여기)에 나타났습니다.