VPS에 Kubernetes 설치 및 설정 가이드

작년 겨울 한밤중에 고객이 저에게 전화를 걸었습니다. 앱이 다운되어 모든 사용자가 접속할 수 없게 되었다는 것이었습니다. 서버 하나만 다운되었고, 앱 트래픽이 다른 곳으로 전송된 것도 아니었습니다.

그날 밤 사건을 계기로 쿠버네티스에 관심을 갖게 되었습니다. VPS에 전체 설정을 다시 구축했더니 같은 오류가 발생해도 앱이 다시는 오프라인 상태가 되지 않았습니다.

그 이후로 저희 팀은 VPS 서버에 쿠버네티스를 여러 번 구축해 왔습니다. 소규모 스타트업을 위해서도, 저희 자체 도구를 위해서도 구축해 왔죠.

이 가이드에서는 제가 하는 모든 단계를 알려드리겠습니다. 

VPS 서버를 활용하여 복사 붙여넣기 가능한 실제 명령어를 사용하여 쿠버네티스를 설정하는 방법을 설명해 드렸습니다. 

시작하자.

PowerShell에 명령어를 입력하기 전에, 초보자도 이해할 수 있도록 이 도구에 대해 간단히 설명드리겠습니다.

쿠버네티스란? 

쿠버네티스는 컨테이너라고 불리는 작은 상자 안에서 애플리케이션을 실행하는 시스템입니다. 쿠버네티스는 컨테이너(즉, 애플리케이션을 구성하는 코드가 저장되는 공간)를 여러 서버에 걸쳐 동시에 활성화 상태로 유지합니다.

그것을 스마트하다고 생각해 보세요 manager. 실행하고 싶은 항목을 지정하면, 여러 개의 정상적인 복사본이 24시간 내내 실행되도록 보장합니다. 

제가 본 것 중 하나는 개발자들이 쿠버네티스를 K8s라고 쓰는 경우가 많다는 겁니다. 여기서 8은 K와 s 사이에 있는 여덟 글자를 의미합니다. 같은 도구인데 이름을 더 짧게 부르는 거죠.

서버 하나에 문제가 생기면 Kubernetes는 애플리케이션을 정상적으로 작동하는 다른 서버로 이동시켜 줍니다. VPS에 Kubernetes를 설치한 덕분에 그날 밤 제 고객은 문제를 해결할 수 있었습니다.

앱이 24시간 내내 중단 없이 안전하게 실행된다는 안전성이 바로 제가 보통 쿠버네티스를 VPS와 함께 사용하는 가장 큰 이유입니다. 

이 조합이 왜 그렇게 훌륭한지 보여드리겠습니다.

VPS에서 Kubernetes를 실행해야 하는 이유는 무엇일까요?

많은 고객들이 제게 왜 VPS에서 Kubernetes를 실행하는지 묻습니다. 이를 이해하려면 VPS가 무엇인지 알아야 합니다. 

VPS(가상 사설 서버)는 실제 물리적 서버의 일부를 분할한 것입니다. 가상화 기술을 사용하여 대형 물리적 서버를 여러 개의 VPS 서버로 나누고, 각 가상 머신은 자체적인 전용 서버를 갖습니다. RAM, CPU 코어 및 NVMe 스토리지. 

또한 루트 권한 전체를 얻을 수 있습니다(를 통해). SSH (키)를 통해 VPS에 안전하게 연결할 수 있습니다. 또한 고정된 전력량과 완벽한 제어 권한을 얻을 수 있습니다.

한 가지 더! 왜 VPS를 쓰나요? 왜 대규모 전용 ​​서버를 쓰지 않나요 ? 보세요! 대형 클라우드 서버에서 Kubernetes를 실행하는 것은 비용이 많이 듭니다. 물리적 서버에는 Kubernetes를 실행하여 시작 앱을 운영할 때 유휴 상태로 남아 있는 리소스가 많습니다.

이렇게 하면 결국 돈을 낭비하게 됩니다. 

• VPS는 비용을 일정하고 투명하게 유지해주기 때문에 저희 팀은 중소 규모 프로젝트에 매우 적합합니다.
• 이렇게 하면 훨씬 더 많은 것을 배울 수 있습니다. VPS에 Kubernetes를 직접 구축하면 마법의 버튼을 클릭하는 대신 모든 단계를 직접 확인할 수 있습니다.
• 그리고 여러분은 전체 스택(Kubernetes가 실행되는 전체 VPS 서버)을 소유하게 됩니다. manage 앱 코드가 저장되는 컨테이너입니다. 
• VPS는 전용 리소스를 제공하며, 다른 서버와 리소스를 공유하지 않으므로(VPS의 운영자가 됨) 트래픽이 급증하는 날에도 제한 없이 사용할 수 있습니다.

쿠버네티스를 설정하기 전에 알아두면 좋을 부분들을 먼저 설명드리겠습니다. 그래야만 쿠버네티스 설정이 어렵게 느껴지지 않을 것입니다.

YouStable VPS는 쿠버네티스를 위한 스마트 홈입니다.

모든 명령은 서버에서 처리됩니다. 성능이 떨어지는 VPS는 각 단계의 속도를 저하시키므로, 사용하는 VPS 서버의 성능이 매우 중요합니다.

저희 팀은 Kubernetes를 실행합니다. YouStable VPS 그리고 우리가 왜 그렇게 하는지를 공유하고 싶습니다.

우선, YouStable VPS는 모든 요금제에서 루트 권한 전체를 제공합니다. Kubernetes는 시스템에 대한 100% 제어 권한이 필요하며, 루트 권한 전체는 바로 그러한 제어 권한을 제공합니다.

둘째로, 로그인 정보는 안전하게 보호됩니다. SSH 키 액세스. 당신은 다음을 얻게 됩니다. SSH 이 키를 사용하면 VPS 서버에 안전하게 로그인할 수 있습니다. 취약한 비밀번호 대신 키를 사용하여 로그인하면 작업 환경에 대한 접근을 어렵게 만들 수 있습니다.

서버는 NVMe SSD 스토리지와 KVM 가상화 환경에서 실행됩니다. 빠른 디스크 덕분에 클러스터 사용량이 많을 때에도 Pod 시작 속도가 빠르고 명령 실행 속도도 신속합니다.

노드를 인도, 미국 또는 네덜란드에 배치할 수 있습니다. 사용자와 가까운 서버를 사용하면 지연 시간을 줄일 수 있으며, 저희 팀은 이 점을 많이 활용하고 있습니다.

고객 지원팀은 24시간 내내 답변을 제공합니다. 새벽 2시에 시스템에 문제가 발생하면, 미리 준비된 스크립트가 아닌 실제 담당자가 직접 도와드립니다.

쿠버네티스 환경의 노드를 단 몇 분 만에 구축할 수 있습니다. 아래 링크에서 향후 확장이 가능한 요금제를 선택하세요.

여기에서 시작하세요: https://www.youstable.com/vps-hosting/

강력한 서버 덕분에 이제 다시 빌드 작업을 진행하겠습니다. 클러스터 브레인을 가동할 시간입니다.

클러스터의 각 부분은 어떤 역할을 하나요?

쿠버네티스 클러스터는 몇 가지 핵심 구성 요소로 이루어져 있습니다. 이러한 구성 요소를 이해하면 이 가이드의 모든 명령어가 쉽게 이해될 것입니다.

• 컨트롤 플레인은 최고 책임자입니다. 어떤 프로세스가 어디에서 실행될지 결정하고, 상태를 추적하며, 클러스터의 나머지 부분에 명령을 내립니다.
• 워커 노드는 핵심적인 역할을 담당합니다. 실제 애플리케이션을 실행하고 하루 종일 컨트롤 플레인에 보고합니다.
• Pod는 가장 작은 단위입니다. Pod는 하나 이상의 컨테이너를 포함하며, Kubernetes는 Pod를 시작하고, 이동하고, 복구합니다.
• 배포는 여러분의 희망 목록과 같습니다. 보관할 복사본 수를 지정하면 Kubernetes가 해당 숫자를 그대로 유지하고 관리합니다.
• kubectl은 당신의 목소리입니다. 당신이 입력하는 모든 요청은 kubectl을 통해 제어 평면으로 전달되고, 제어 평면은 당신의 말에 따라 동작합니다.
• 파드가 종료되면 Kubernetes는 몇 초 만에 이를 감지하고 즉시 새 복사본을 생성합니다. 따라서 사용자는 거의 장애를 느끼지 못합니다.

자, 배경 설명은 이쯤 하고, 첫 번째 명령어를 실행하기 전에 정확히 무엇이 필요한지 단계별로 설명해 드리겠습니다.

시작하기 전에 필요한 것은 무엇일까요?

저는 이 설정을 새 서버에서 수백 번 실행해 봤습니다. 아래 목록은 저희 팀이 모든 빌드에서 사용하는 정확한 시작점입니다.

진정한 클러스터를 구성하려면 최소 두 대의 서버가 필요합니다. 하나는 컨트롤 플레인이라고 불리는 총괄 서버 역할을 하고, 나머지 두 대는 워커 노드로서 애플리케이션을 실행합니다.

연습 삼아 단일 노드 클러스터를 운영해 볼 수도 있습니다. 하지만 저는 항상 두 개의 노드를 사용하는 것을 권장합니다. 그래야 실제 환경과 더 비슷하게 느껴질 테니까요.

본격적인 작업에 앞서 전체 로드맵을 보여드리겠습니다. 이 표를 새 탭에 열어두고 체크리스트처럼 활용하세요.

설치 계획 개요

저희 팀은 전체 작업을 10단계로 나누었습니다. 각 단계는 이전 단계를 기반으로 하므로 순서대로 따라하시면 ​​매끄럽고 안정적으로 진행하실 수 있습니다.

열 단계라고 하면 많아 보일 수 있지만, 요령을 터득하면 대부분 1분도 채 걸리지 않습니다. 자, 그럼 시작해 볼까요?

VPS에 Kubernetes를 설정하는 방법은 무엇인가요?

아래에 VPS에 Kubernetes를 설정하는 데 필요한 정확한 단계를 설명했습니다. 먼저 신뢰할 수 있는 VPS 제공업체에서 VPS를 구매해야 하며, 제공업체는 VPS 로그인 자격 증명을 제공할 것입니다. SSHVPS에 로그인한 후에는 제가 했던 것처럼 다음 단계를 정확히 따라야 합니다.

1단계: 모든 서버 준비

이 첫 번째 단계는 컨트롤 플레인 서버와 워커 서버 모두에서 실행해야 합니다. 이렇게 하면 나중에 문제가 발생하지 않도록 기반을 마련할 수 있습니다.

각 서버에 명확한 이름을 지정하세요. 모든 터미널 창이 똑같이 보이기 때문에 어떤 컴퓨터에 접속했는지 쉽게 알 수 있습니다.

sudo hostnamectl set-hostname control-plane   # on the bosssudo hostnamectl set-hostname worker-1        # on a worker

이제 각 서버의 이름과 개인 IP 주소를 hosts 파일에 추가하세요. 이렇게 하면 서버들이 번호가 아닌 이름으로 서로를 찾을 수 있습니다.

sudo nano /etc/hosts# add lines like these, with your own real IPs10.0.0.10 control-plane10.0.0.11 worker-1

그런 다음 모든 서버에서 패키지를 업데이트하십시오. 최신 패키지를 사용하면 버그가 줄어들고 설치 중 예상치 못한 문제가 발생할 가능성이 줄어듭니다.

sudo apt update && sudo apt upgrade -y

이름도 정하고 패키지도 새로 설치했는데, 이제 거의 모든 초보자가 어려워하는 설정 단계에 도달했습니다.

2단계: 스왑 기능 끄기

스왑은 여분의 디스크 공간으로, 마치 추가 메모리처럼 작동합니다. 쿠버네티스는 실제 메모리를 올바르게 읽기 위해 스왑 영역을 비활성화해야 합니다.

두 개의 간단한 명령어로 스왑 기능을 끌 수 있습니다. 첫 번째 명령어는 스왑 기능을 즉시 중지하고, 두 번째 명령어는 재부팅 후에도 스왑 기능이 꺼진 상태를 유지합니다.

sudo swapoff -asudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

모든 서버에서 이 명령을 실행하십시오. 이 단계를 건너뛰면 클러스터가 복잡하고 이해하기 어려운 오류와 함께 시작되지 않을 수 있습니다.

다음으로 리눅스 커널에 파드가 사용할 네트워크 트래픽을 허용하도록 지시합니다.

3단계: 커널 모듈 및 네트워크 설정 로드

Pod는 서버 간에 트래픽을 전송해야 합니다. 두 개의 작은 커널 모듈이 이를 가능하게 하므로, 제가 해당 모듈을 활성화해 드리겠습니다.

overlay 및 br_netfilter 모듈은 컨테이너가 네트워크를 공유하는 방식을 처리합니다. 아래의 간단한 코드 블록을 사용하여 해당 모듈을 로드하세요.

cat <<EOF | sudo tee /etc/modules-load.d/k8s.confoverlaybr_netfilterEOF sudo modprobe overlaysudo modprobe br_netfilter

이제 파드 간 트래픽이 올바른 방향으로 흐르도록 몇 가지 네트워크 규칙을 설정하세요. Kubernetes는 설정 과정에서 이러한 규칙을 확인합니다.

cat <<EOF | sudo tee /etc/sysctl.d/k8s.confnet.bridge.bridge-nf-call-iptables  = 1net.bridge.bridge-nf-call-ip6tables = 1net.ipv4.ip_forward                 = 1EOF sudo sysctl --system

이 코드들은 좀 무서워 보이지만, 사실은 한 서버가 다른 서버로 파드 트래픽을 전달하고 절대 드롭하지 않도록 하는 코드입니다. 모든 노드에서 실행해야 합니다.

이제 컨테이너를 작동시키는 실제 엔진을 내부에 설치합니다.

4단계: 컨테이너 런타임인 containerd를 설치합니다.

컨테이너 런타임은 실제로 컨테이너를 시작하고 중지하는 프로그램입니다. Kubernetes에는 런타임이 필요하며, 저희 팀은 containerd를 런타임으로 신뢰합니다.

Docker가 예전에는 이 역할을 담당했습니다. 하지만 Kubernetes가 오래전에 그 방식을 포기했기 때문에 이제는 containerd를 단독으로 사용합니다.

sudo apt install -y containerd

다음으로 기본 설정 파일을 생성합니다. 이렇게 하면 containerd가 깔끔한 기본 환경에서 작동할 수 있습니다.

sudo mkdir -p /etc/containerdcontainerd config default | sudo tee /etc/containerd/config.toml > /dev/null

한 가지 설정이 매우 중요합니다. SystemdCgroup을 true로 설정하여 containerd와 Kubernetes가 리소스를 추적하는 방식을 일치시키세요.

sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' \  /etc/containerd/config.tomlsudo systemctl restart containerdsudo systemctl enable containerd

그 플래그 하나를 놓치면 나중에 파드가 무한 루프에 빠져 충돌하게 됩니다. 저희 팀은 이 문제를 셀 수 없이 많이 디버깅했습니다.

엔진 준비가 완료되면 전체 작업을 구동하는 세 가지 도구를 가져옵니다.

5단계: kubeadm, kubelet 및 kubectl을 설치합니다.

이 세 가지 도구가 핵심적인 역할을 합니다. 설치하기 전에 각 도구의 기능에 대해 설명해 드리겠습니다.

kubeadm은 클러스터를 구축합니다. kubelet은 모든 노드에서 실행되어 파드를 활성 상태로 유지합니다. kubectl은 이 모든 것을 제어하는 ​​데 사용하는 명령어입니다.

먼저 공식 Kubernetes 패키지 소스를 추가합니다. 이 블록은 현재 v1.36 릴리스의 서명 키를 가져옵니다.

sudo apt install -y apt-transport-https ca-certificates curl gpgsudo mkdir -p -m 755 /etc/apt/keyringscurl -fsSL https://pkgs.k8s.io/core:/stable:/v1.36/deb/Release.key \  | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

이제 apt를 해당 소스로 지정하고 세 가지 도구를 한 번에 설치하세요.

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] \  https://pkgs.k8s.io/core:/stable:/v1.36/deb/ /' \  | sudo tee /etc/apt/sources.list.d/kubernetes.listsudo apt updatesudo apt install -y kubelet kubeadm kubectl

그런 다음 버전을 고정합니다. 이렇게 하면 일반적인 패치 작업 중에 임의 업데이트로 인해 클러스터가 손상되는 것을 방지할 수 있습니다.

sudo apt-mark hold kubelet kubeadm kubectl

지금까지 진행한 모든 단계를 모든 서버에서 실행해 보세요. 클러스터 브레인을 시작하기 전에, 이 모든 과정이 얼마나 원활하게 진행되는지를 결정하는 요소에 대해 잠시 짚고 넘어가겠습니다.

6단계: 제어 평면을 시작합니다

이 단계는 제어 평면에서만 실행됩니다. 이 단계를 통해 보스 서버가 전체 클러스터의 두뇌 역할을 하게 됩니다.

아래 명령어는 클러스터를 시작하고 포드 네트워크 범위를 설정합니다. 저희 팀은 이 범위를 다음에 추가할 네트워크 도구인 Calico와 연결합니다.

# run on the control plane onlysudo kubeadm init --pod-network-cidr=192.168.0.0/16

이 과정은 몇 분 정도 소요됩니다. 완료되면 kubeadm join 명령어가 출력됩니다. 해당 명령어 전체를 복사하여 안전한 곳에 저장해 두세요.

해당 참여 링크는 나중에 작업자를 추가할 수 있는 티켓입니다. 이 링크에는 24시간 후에 만료되는 토큰이 저장되어 있으므로 분실하지 않도록 주의하십시오.

클러스터 브레인은 살아있습니다. 이제 제가 여러분에게 그것과 소통할 수 있는 열쇠를 드리겠습니다.

7단계: kubectl 접근 권한 설정

현재는 루트 사용자만 클러스터에 접근할 수 있습니다. 다음 세 줄의 명령어를 추가하면 일반 사용자도 매번 sudo를 입력하지 않고 kubectl을 실행할 수 있습니다.

루트 권한이 아닌 일반 사용자 권한으로 컨트롤 플레인에서 실행하십시오.

mkdir -p $HOME/.kubesudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/configsudo chown $(id -u):$(id -g) $HOME/.kube/config

바로 테스트해 보세요. 이 명령은 클러스터에 노드 목록을 요청합니다.

kubectl get nodes

컨트롤 플레인이 '준비 안 됨'으로 표시되는 것을 보실 수 있습니다. 지금은 괜찮습니다. 다음에 포드 네트워크를 추가할 때까지 이 상태를 유지합니다.

NotReady 상태가 바로 우리가 해야 할 일입니다. 클러스터가 파드 간 통신을 할 수 있도록 방법이 필요하니, 제가 하나 설치해 보겠습니다.

8단계: Pod 네트워크 설치

Pod들은 CNI라고 하는 네트워크 계층을 추가하기 전까지는 서로 통신할 수 없습니다. 저희 팀은 안정적이고 간단한 Calico를 사용합니다.

컨트롤 플레인에서 단 하나의 명령으로 설치할 수 있습니다. Calico 프로젝트에서 미리 만들어진 파일을 바로 읽어옵니다.

# run on the control plane onlykubectl apply -f https://raw.githubusercontent.com/projectcalico/\calico/v3.28.0/manifests/calico.yaml

1~2분 정도 기다려 안정시킨 후 노드를 다시 한번 확인하세요.

kubectl get nodes

이제 컨트롤 플레인에 "준비됨(Ready)"이라는 표시가 나타나야 합니다. 이 단어 하나는 네트워크가 활성화되었고 클러스터가 정상 상태임을 의미합니다.

클러스터는 실행 중이지만 아직 워커 서버가 없습니다. 애플리케이션 서버를 클러스터에 추가해 드리겠습니다.

9단계: 작업자 노드를 참여시키세요

이제 6단계에서 저장해 둔 kubeadm join 명령어를 가져오세요. 이 명령어는 컨트롤 플레인이 아니라 각 워커에서 실행해야 합니다.

아래와 같은 형식으로 작성하되, 본인의 IP 주소와 토큰을 입력하세요. 맨 앞에 sudo를 추가하면 됩니다.

# run on each worker nodesudo kubeadm join 10.0.0.10:6443 --token abcdef.0123456789abcdef \  --discovery-token-ca-cert-hash sha256:1234...yourhash

토큰을 잃어버리셨나요? 괜찮습니다. 컨트롤 플레인에서 이 명령을 실행하면 새로운 가입 명령이 출력됩니다.

kubeadm token create --print-join-command

각 워커가 접속한 후, 컨트롤 플레인으로 돌아가 노드 목록을 확인하세요. 노드들이 하나씩 '준비' 상태로 바뀌는 것을 볼 수 있습니다.

kubectl get nodes

모든 노드에 '준비됨'이라고 표시되는 걸 보면 정말 기분이 좋습니다. 우리 팀원들은 몇 년이 지난 지금도 그 화면을 보면 미소를 짓곤 합니다.

아무것도 실행되지 않는 클러스터는 그저 껍데기에 불과합니다. 실제 앱을 배포하여 제대로 작동하는지 증명해 보이겠습니다.

10단계: 실제 앱으로 클러스터 테스트

클러스터에 간단한 웹 애플리케이션을 설치해 보겠습니다. 이를 통해 파드가 정상적으로 시작되고, 분산되고, 트래픽에 응답하는 것을 확인할 수 있습니다.

컨트롤 플레인에서 이 코드를 실행하세요. 그러면 아주 작은 파일이 생성됩니다. Nginx 보안을 위해 웹 서버에 두 개의 복사본이 있습니다.

kubectl create deployment web --image=nginx --replicas=2kubectl expose deployment web --port=80 --type=NodePort

두 개의 파드 모두 실행 중인지 확인하십시오. 다음 명령은 파드와 각 파드가 실행된 노드를 나열합니다.

kubectl get pods -o wide

워커 노드에 두 개의 웹 파드가 분산되어 있는 것을 볼 수 있을 것입니다. 이는 Kubernetes가 노드 하나가 다운되더라도 애플리케이션이 계속 실행되도록 유지하는 기능입니다.

브라우저에서 NodePort를 열어 확인하세요. Nginx 환영 페이지입니다. 이 라이브 페이지는 클러스터가 이제 실제 트래픽을 처리하고 있음을 보여주는 증거입니다.

이제 작동하는 클러스터를 확보하셨습니다. 축하하기 전에, 저희 팀이 초반에 빠졌던 함정에서 당신을 구해드리겠습니다.

초보자들이 흔히 저지르는 실수

저는 지난 몇 년 동안 깨진 꽃송이들을 많이 손봤습니다. 이런 작은 실수 몇 가지가 대부분의 문제를 일으키니 주의하세요.

• 스왑 레프트 온이 가장 큰 원인입니다. 컨트롤 플레인뿐만 아니라 모든 노드에서 스왑 레프트 온을 껐는지 다시 한번 확인하세요.
• 다음은 SystemdCgroup 플래그가 누락된 경우입니다. containerd와 Kubernetes가 리소스 추적에 대해 의견이 일치하지 않으면 Pod가 무한 루프에 빠져 충돌합니다.
• 만료된 토큰은 많은 연결을 차단합니다. 토큰은 24시간 후에 소멸되므로, 워커가 연결을 거부할 경우 새 토큰을 생성해야 합니다.
• 방화벽 포트가 닫혀 있으면 오류 발생 시 아무런 알림이 없습니다. 관리자와 작업자가 자유롭게 소통할 수 있도록 노드에 필요한 포트를 열어주세요.

포트 이야기가 나온 김에 말씀드리자면, 저희 팀에서 노드 간에 여는 포트는 다음과 같습니다. 새 클러스터가 제대로 작동하지 않을 때 이 포트들을 먼저 설정해 두세요.

노드 간에 이러한 포트를 열면 가장 흔한 네트워크 문제를 피할 수 있습니다. 저희 팀은 항상 이 목록을 먼저 확인합니다.

전체 빌드와 일반적인 수정 사항이 포함되어 있습니다. 이제 저희 팀이 VPS에서 Kubernetes에 대해 가장 많이 듣는 질문에 답변해 드리겠습니다.

자주 묻는 질문

맺음말

처음에는 텅 빈 서버와 약간의 의심으로 시작했지만, 이제는 노드 장애 발생 시 자체 복구되는 진정한 쿠버네티스 환경을 VPS 클러스터에서 운영하고 있습니다.

우리가 함께 과정을 진행했어요. 서버를 준비하고, 스왑을 끄고, 네트워크를 설정하고, 핵심 도구와 함께 containerd를 설치했죠.

그런 다음 컨트롤 플레인을 구축하고, 포드 네트워크를 추가하고, 워커를 참여시키고, 클러스터 전체에 라이브 앱을 배포했습니다.

저희 팀은 실제 프로젝트에서 이와 똑같은 프로세스를 사용하고 있으며, 이제 여러분도 사용할 수 있습니다. 이 가이드를 가까이 두고 새 클러스터를 만들 때마다 다시 실행하세요.

다음 단계는 간단합니다. 확장성이 좋은 안정적인 VPS를 확보하고, 터미널 세 개를 열어 오늘 바로 첫 번째 클러스터를 구축해 보세요. 당신은 할 수 있습니다.

루트 권한이 완전히 부여된 Kubernetes 지원 노드를 시작합니다. SSH 키 로그인 및 NVMe 속도: https://www.youstable.com/vps-hosting/