kubeadm으로 클러스터 생성하기

kubeadm으로 클러스터 생성하기 (Creating a cluster with kubeadm)

kubeadm을 사용하면 모범 사례를 따르는 최소한의 실행 가능한 Kubernetes 클러스터를 만들 수 있어요. 실제로 kubeadm을 사용해 Kubernetes 적합성 테스트를 통과할 클러스터를 설정할 수 있어요. kubeadm은 또한 부트스트랩 토큰과 클러스터 업그레이드 같은 다른 클러스터 수명주기 기능도 지원해요.

kubeadm 도구는 다음이 필요할 때 좋아요:

  • Kubernetes를 (어쩌면 처음으로) 간단하게 시험해 볼 수 있는 방법.
  • 기존 사용자가 클러스터 설정을 자동화하고 애플리케이션을 테스트할 수 있는 방법.
  • 더 큰 범위의 다른 생태계 및/또는 설치 도구의 구성 요소.

kubeadm을 여러 머신(노트북, 클라우드 서버 집합, Raspberry Pi 등)에 설치하고 사용할 수 있어요. 클라우드든 온프레미스든 배포하든 kubeadm을 Ansible이나 Terraform 같은 프로비저닝 시스템에 통합할 수 있어요.

출처: 문서

본문

시작하기 전에 (Before you begin)

이 가이드를 따르려면 다음이 필요해요:

  • deb/rpm 호환 Linux OS를 실행하는 하나 이상의 머신; 예: Ubuntu 또는 CentOS.
  • 머신당 2 GiB 이상의 RAM—그보다 적으면 앱을 위한 공간이 거의 없어요.
  • 컨트롤 플레인 노드로 사용하는 머신에 최소 2개의 CPU.
  • 클러스터의 모든 머신 사이의 완전한 네트워크 연결. 공개 또는 비공개 네트워크를 사용할 수 있어요.

또한 새 클러스터에서 사용하려는 Kubernetes 버전을 배포할 수 있는 kubeadm 버전을 사용해야 해요.

Kubernetes의 버전 및 버전 스큐 지원 정책은 Kubernetes 전체뿐 아니라 kubeadm에도 적용돼요. 지원되는 Kubernetes와 kubeadm 버전이 무엇인지 배우려면 그 정책을 확인해요. 이 페이지는 Kubernetes v1.37용으로 작성됐어요.

kubeadm 도구의 전체 기능 상태는 GA(일반 가용성)예요. 일부 하위 기능은 여전히 활발히 개발 중이에요. 클러스터 생성 구현은 도구가 발전함에 따라 약간 변경될 수 있지만 전체 구현은 꽤 안정적이어야 해요. 운영은 어떤 kubeadm 하위 명령의 상태도 보증하지 않아요.

목표 (Objectives)

  • 단일 컨트롤 플레인 Kubernetes 클러스터 설치
  • 파드가 서로 통신할 수 있도록 클러스터에 Pod 네트워크 설치

지침 (Instructions)

호스트 준비 (Preparing the hosts)

컴포넌트 설치 (#component-installation)

모든 호스트에 컨테이너 런타임과 kubeadm을 설치해요. 상세 지침과 다른 전제 조건은 kubeadm 설치를 참고해요.

이미 kubeadm을 설치했다면 Linux 노드 업그레이드 문서의 처음 두 단계를 참고해 kubeadm을 업그레이드하는 방법을 알아봐요.

업그레이드할 때 kubelet은 kubeadm이 무엇을 해야 하는지 알려줄 때까지 crashloop에서 기다리면서 몇 초마다 재시작해요. 이 crashloop는 예상되고 정상적인 것이에요. 컨트롤 플레인을 초기화한 후 kubelet은 정상적으로 실행돼요.

네트워크 설정 (#network-setup)

kubeadm은 다른 Kubernetes 컴포넌트와 유사하게 호스트의 기본 게이트웨이와 연관된 네트워크 인터페이스에서 사용 가능한 IP를 찾으려고 시도해요. 그런 IP가 컴포넌트가 수행하는 광고 및/또는 수신에 사용돼요.

Linux 호스트에서 이 IP가 무엇인지 알아내려면 다음을 사용할 수 있어요:

ip route show # Look for a line starting with "default via"

Kubernetes 컴포넌트는 사용자 지정 네트워크 인터페이스를 옵션으로 받아들이지 않으므로, 그러한 사용자 지정 구성을 필요로 하는 모든 컴포넌트 인스턴스에 사용자 지정 IP 주소를 플래그로 전달해야 해요.

init과 join으로 모두 생성된 컨트롤 플레인 노드에 대해 API 서버 광고 주소를 구성하려면 --apiserver-advertise-address 플래그를 사용할 수 있어요. 이 옵션은 kubeadm API(/docs/reference/config-api/kubeadm-config.v1beta4/)에서 InitConfiguration.localAPIEndpoint와 JoinConfiguration.controlPlane.localAPIEndpoint로 설정하는 것이 좋아요.

모든 노드의 kubelet에 대해 --node-ip 옵션을 kubeadm 구성 파일(InitConfiguration 또는 JoinConfiguration) 내부의 .nodeRegistration.kubeletExtraArgs에 전달할 수 있어요.

듀얼 스택에 대해서는 kubeadm으로 듀얼 스택 지원을 참고해요.

컨트롤 플레인 컴포넌트에 할당하는 IP 주소는 그들의 X.509 인증서의 주체 대체 이름 필드의 일부가 돼요. 이 IP 주소를 변경하려면 새 인증서에 서명하고 영향을 받는 컴포넌트를 재시작해야 하므로 인증서 파일의 변경이 반영돼요. 이 주제에 대한 자세한 내용은 수동 인증서 갱신을 참고해요.

필요한 컨테이너 이미지 준비 (#preparing-the-required-container-images)

이 단계는 선택 사항이며 registry.k8s.io에 호스팅된 기본 컨테이너 이미지를 kubeadm init과 kubeadm join이 다운로드하지 않기를 바랄 때만 적용돼요.

Kubeadm에는 노드에 인터넷 연결 없이 클러스터를 만들 때 필요한 이미지를 미리 가져오는 데 도움이 되는 명령이 있어요. 자세한 내용은 인터넷 연결 없이 kubeadm 실행을 참고해요.

Kubeadm은 필요한 이미지에 커스텀 이미지 리포지토리를 사용하게 해줘요. 자세한 내용은 커스텀 이미지 사용을 참고해요.

컨트롤 플레인 노드 초기화 (#initializing-your-control-plane-node)

컨트롤 플레인 노드는 etcd(/docs/tasks/administer-cluster/configure-upgrade-etcd/)(클러스터 데이터베이스)와 kubectl(/docs/reference/kubectl/) 명령줄 도구가 통신하는 API 서버(/docs/concepts/architecture/#kube-apiserver)를 포함한 컨트롤 플레인 컴포넌트가 실행되는 머신이에요.

  • (권장) 이 단일 컨트롤 플레인 kubeadm 클러스터를 고가용성으로 업그레이드할 계획이 있다면 --control-plane-endpoint를 지정해 모든 컨트롤 플레인 노드의 공유 엔드포인트를 설정해야 해요. 그러한 엔드포인트는 DNS 이름 또는 로드 밸런서의 IP 주소일 수 있어요.
  • Pod 네트워크 애드온을 선택하고 kubeadm init에 전달해야 할 인자가 있는지 확인해요. 선택한 서드파티 프로바이더에 따라 --pod-network-cidr을 프로바이더별 값으로 설정해야 할 수도 있어요. Pod 네트워크 애드온 설치(#pod-network)를 참고해요.
  • (선택) kubeadm은 잘 알려진 엔드포인트 목록을 사용해 컨테이너 런타임을 감지하려고 해요. 다른 컨테이너 런타임을 사용하거나 프로비저닝된 노드에 둘 이상 설치된 경우 --cri-socket 인자를 kubeadm에 지정해요. 런타임 설치를 참고해요.

컨트롤 플레인 노드를 초기화하려면 실행해요:

kubeadm init <args>

apiserver-advertise-address와 ControlPlaneEndpoint에 대한 고려 사항 (#considerations-about-apiserver-advertise-address-and-controlplaneendpoint)

--apiserver-advertise-address를 사용해 이 특정 컨트롤 플레인 노드의 API 서버에 대한 광고 주소를 설정할 수 있는 반면, --control-plane-endpoint를 사용해 모든 컨트롤 플레인 노드의 공유 엔드포인트를 설정할 수 있어요.

--control-plane-endpoint는 IP 주소와 IP 주소에 매핑할 수 있는 DNS 이름을 모두 허용해요. 그러한 매핑과 관련한 가능한 해결책을 평가하려면 네트워크 관리자에게 문의해주세요.

다음은 매핑 예시예요:

192.168.0.102 cluster-endpoint

여기서 192.168.0.102는 이 노드의 IP 주소이고 cluster-endpoint는 이 IP에 매핑되는 커스텀 DNS 이름이에요. 이것은 kubeadm init에 --control-plane-endpoint=cluster-endpoint를 전달하고 kubeadm join에도 같은 DNS 이름을 전달할 수 있게 해줘요. 나중에 고가용성 시나리오에서 cluster-endpoint를 수정해 로드 밸런서의 주소를 가리키게 할 수 있어요.

--control-plane-endpoint 없이 만든 단일 컨트롤 플레인 클러스터를 고가용성 클러스터로 바꾸는 것은 kubeadm이 지원하지 않아요.

더 많은 정보 (#more-information)

kubeadm init 인자에 대한 더 많은 정보는 kubeadm 참조 가이드를 참고해요.

구성 파일로 kubeadm init을 구성하려면 구성 파일로 kubeadm init 사용을 참고해요.

컨트롤 플레인 컴포넌트(컨트롤 플레인 컴포넌트와 etcd 서버의 liveness probe에 대한 선택적 IPv6 할당 포함)를 커스터마이즈하려면 커스텀 인자에 문서화된 대로 각 컴포넌트에 추가 인자를 제공해요.

이미 생성된 클러스터를 재구성하려면 kubeadm 클러스터 재구성을 참고해요.

kubeadm init을 다시 실행하려면 먼저 클러스터를 분해해야 해요(#tear-down).

다른 아키텍처의 노드를 클러스터에 조인한다면 배포된 DaemonSet이 그 아키텍처에 대한 컨테이너 이미지 지원을 가지고 있는지 확인해요.

kubeadm init은 먼저 머신이 Kubernetes를 실행할 준비가 되었는지 확인하기 위해 일련의 사전 검사를 실행해요. 이 사전 검사는 경고를 노출하고 오류에서 종료해요. 그런 다음 kubeadm init이 클러스터 컨트롤 플레인 컴포넌트를 다운로드하고 설치해요. 이것은 몇 분이 걸릴 수 있어요. 끝난 후 다음을 볼 수 있어요:

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

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

You should now deploy a Pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  /docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>

비루트 사용자가 kubectl을 작동시키려면 이러한 명령을 실행해요. 이것은 또한 kubeadm init 출력의 일부예요:

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

대안으로 루트 사용자라면 실행할 수 있어요:

export KUBECONFIG=/etc/kubernetes/admin.conf

kubeadm init이 생성하는 kubeconfig 파일 admin.conf에는 Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin인 인증서가 포함돼 있어요. 그룹 kubeadm:cluster-admins는 내장 cluster-admin ClusterRole에 바인딩돼 있어요. admin.conf 파일을 누구와도 공유하지 마세요.

kubeadm init은 Subject: O = system:masters, CN = kubernetes-super-admin인 인증서를 포함하는 또 다른 kubeconfig 파일 super-admin.conf를 생성해요. system:masters는 인가 계층(예: RBAC)을 우회하는 break-glass 슈퍼 사용자 그룹이에요. super-admin.conf 파일을 누구와도 공유하지 마세요. 파일을 안전한 위치로 옮기는 것이 좋아요.

kubeadm kubeconfig user를 사용해 추가 사용자용 kubeconfig 파일을 생성하는 방법은 추가 사용자용 kubeconfig 파일 생성을 참고해요.

kubeadm init이 출력하는 kubeadm join 명령을 기록해 두어요. 클러스터에 노드를 조인하려면(#join-nodes) 이 명령이 필요해요.

토큰은 컨트롤 플레인 노드와 조인하는 노드 사이의 상호 인증에 사용돼요. 여기에 포함된 토큰은 비밀값이에요. 이 토큰을 가진 누구나 인증된 노드를 클러스터에 추가할 수 있으므로 안전하게 보관해요. 이 토큰들은 kubeadm token 명령으로 나열, 생성, 삭제할 수 있어요. kubeadm 참조 가이드를 참고해요.

Pod 네트워크 애드온 설치 (#pod-network)

이 섹션에는 네트워킹 설정과 배포 순서에 대한 중요한 정보가 있어요. 계속하기 전에 이 조언을 모두 신중히 읽어요.

파드가 서로 통신할 수 있도록 Container Network Interface(CNI) 기반 Pod 네트워크 애드온을 배포해야 해요. 네트워크가 설치되기 전에는 클러스터 DNS(CoreDNS)가 시작되지 않아요.

  • 파드 네트워크가 호스트 네트워크 중 하나와 겹치지 않도록 주의해요: 겹침이 있으면 문제가 보일 가능성이 높아요. (네트워크 플러그인의 선호하는 Pod 네트워크와 일부 호스트 네트워크 사이의 충돌을 발견하면 그 대신 사용할 적절한 CIDR 블록을 생각하고, kubeadm init에서 --pod-network-cidr로 그리고 네트워크 플러그인의 YAML에서 대체로 그것을 사용해요.)
  • 기본적으로 kubeadm은 클러스터가 RBAC(/docs/reference/access-authn-authz/rbac/)(역할 기반 접근 제어)를 사용하고 강제하도록 설정해요. Pod 네트워크 플러그인이 RBAC를 지원하는지, 그리고 그것을 배포하는 데 사용하는 모든 매니페스트도 지원하는지 확인해요.
  • 클러스터에 IPv6(듀얼 스택 또는 단일 스택 IPv6 전용 네트워킹)를 사용하려면 Pod 네트워크 플러그인이 IPv6를 지원하는지 확인해요. IPv6 지원은 CNI v0.6.0(https://github.com/containernetworking/cni/releases/tag/v0.6.0)에서 추가됐어요.

여러 외부 프로젝트가 CNI를 사용해 Kubernetes Pod 네트워크를 제공하며, 그중 일부는 Network Policy도 지원해요.

Kubernetes 네트워킹 모델을 구현하는 애드온 목록을 참고해요.

Kubernetes가 지원하는 네트워킹 애드온의 포괄적이지 않은 목록은 애드온 설치 페이지를 참고해주세요.

컨트롤 플레인 노드 또는 kubeconfig 자격 증명이 있는 노드에서 다음 명령으로 Pod 네트워크 애드온을 설치할 수 있어요:

kubectl apply -f <add-on.yaml>

클러스터당 하나의 Pod 네트워크만 설치할 수 있어요.

Pod 네트워크가 설치되면 kubectl get pods --all-namespaces의 출력에서 CoreDNS Pod가 Running인지 확인해 동작하는지 확인할 수 있어요. CoreDNS Pod가 실행되면 노드를 조인해 계속할 수 있어요.

네트워크가 동작하지 않거나 CoreDNS가 Running 상태가 아니면 kubeadm용 문제 해결 가이드를 확인해요.

관리되는 노드 레이블 (#managed-node-labels)

기본적으로 kubeadm은 노드 등록 시 kubelet이 자체 적용할 수 있는 레이블을 제한하는 NodeRestriction(/docs/reference/access-authn-authz/admission-controllers/#noderestriction) admission 컨트롤러를 활성화해요. admission 컨트롤러 문서는 kubelet --node-labels 옵션과 함께 사용이 허용되는 레이블을 다뤄요.

NodeRestriction admission 컨트롤러 때문에 초기화 중에 kubelet --node-labels 플래그로 제한된 레이블(예: node-role.kubernetes.io/*)을 적용할 수 없어요. 이 kubelet 플래그로 제한된 레이블을 추가하려 시도하면 노드가 API 서버에 등록하지 못해요.

이 레이블을 수동으로 적용하려면 노드가 클러스터에 조인한 후 kubectl label을 사용해야 해요. kubeadm이 관리하는 /etc/kubernetes/admin.conf 같은 권한 있는 kubeconfig를 사용하고 있는지 확인해요.

컨트롤 플레인 노드 격리 (#control-plane-node-isolation)

기본적으로 클러스터는 보안상의 이유로 컨트롤 플레인 노드에 파드를 스케줄링하지 않아요. 컨트롤 플레인 노드에 파드를 스케줄링할 수 있기를 원한다면, 예를 들어 단일 머신 Kubernetes 클러스터의 경우, 실행해요:

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

출력은 다음과 같을 거예요:

node "test-01" untainted
...

이것은 컨트롤 플레인 노드를 포함해 그것을 가진 모든 노드에서 node-role.kubernetes.io/control-plane:NoSchedule 테인트를 제거할 거예요. 즉 스케줄러가 모든 곳에 파드를 스케줄링할 수 있게 된다는 뜻이에요.

또한 다음 명령을 실행해 컨트롤 플레인 노드에서 node.kubernetes.io/exclude-from-external-load-balancers(/docs/reference/labels-annotations-taints/#node-kubernetes-io-exclude-from-external-load-balancers) 레이블을 제거할 수 있으며, 이것은 백엔드 서버 목록에서 제외해요:

kubectl label nodes --all node.kubernetes.io/exclude-from-external-load-balancers-

더 많은 컨트롤 플레인 노드 추가 (#adding-more-control-plane-nodes)

더 많은 컨트롤 플레인 노드를 추가해 고가용성 kubeadm 클러스터를 만드는 단계는 kubeadm으로 고가용성 클러스터 생성을 참고해요.

워커 노드 추가 (#join-nodes)

워커 노드는 워크로드가 실행되는 곳이에요.

다음 페이지는 kubeadm join 명령을 사용해 Linux와 Windows 워커 노드를 클러스터에 추가하는 방법을 보여줘요:

(선택) 컨트롤 플레인 노드가 아닌 머신에서 클러스터 제어하기 (#optional-controlling-your-cluster-from-machines-other-than-the-control-plane-node)

다른 컴퓨터(예: 노트북)의 kubectl이 클러스터와 통신하게 하려면 관리자 kubeconfig 파일을 컨트롤 플레인 노드에서 워크스테이션으로 이렇게 복사해야 해요:

scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes

위 예시는 root에 대한 SSH 접근이 활성화되어 있다고 가정해요. 그렇지 않으면 admin.conf 파일을 다른 사용자가 접근할 수 있도록 복사하고 scp에 그 다른 사용자를 대신 사용할 수 있어요.

admin.conf 파일은 사용자에게 클러스터에 대한 슈퍼유저 권한을 부여해요. 이 파일은 드물게 사용해야 해요. 일반 사용자의 경우 권한을 부여하는 고유한 자격 증명을 생성하는 것이 좋아요. kubeadm kubeconfig user --client-name <CN> 명령으로 할 수 있어요. 그 명령은 파일에 저장하고 사용자에게 배포해야 하는 KubeConfig 파일을 STDOUT으로 출력해요. 그 후 kubectl create (cluster)rolebinding을 사용해 권한을 부여해요.

(선택) API 서버를 localhost로 프록시하기 (#optional-proxying-api-server-to-localhost)

클러스터 외부에서 API 서버에 연결하려면 kubectl proxy를 사용할 수 있어요:

scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf proxy

이제 http://localhost:8001/api/v1에서 로컬로 API 서버에 접근할 수 있어요.

정리 (Clean up)

테스트용으로 폐기 가능한 서버를 클러스터에 사용했다면 그것을 끄고 더 이상 정리하지 않아도 돼요. kubectl config delete-cluster를 사용해 클러스터에 대한 로컬 참조를 삭제할 수 있어요.

하지만 클러스터를 더 깨끗하게 해제하고 싶다면 먼저 노드를 drain(/docs/reference/generated/kubectl/kubectl-commands#drain)하고 노드가 비어 있는지 확인한 다음 노드를 구성 해제해야 해요.

노드 제거 (#remove-the-node)

적절한 자격 증명으로 컨트롤 플레인 노드와 통신하며 실행해요:

kubectl drain <node name> --delete-emptydir-data --force --ignore-daemonsets

노드를 제거하기 전에 kubeadm이 설치한 상태를 재설정해요:

kubeadm reset

reset 과정은 iptables 규칙이나 IPVS 테이블을 재설정하거나 정리하지 않아요. iptables를 재설정하려면 수동으로 해야 해요:

iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X

IPVS 테이블을 재설정하려면 다음 명령을 실행해야 해요:

ipvsadm -C

이제 노드를 제거해요:

kubectl delete node <node name>

다시 시작하려면 적절한 인자로 kubeadm init 또는 kubeadm join을 실행해요.

컨트롤 플레인 정리 (#clean-up-the-control-plane)

컨트롤 플레인 호스트에서 kubeadm reset을 사용해 최선의 노력 정리를 트리거할 수 있어요. 이 하위 명령과 그 옵션에 대한 더 많은 정보는 kubeadm reset(/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 참조 문서를 참고해요.

버전 스큐 정책 (Version skew policy)

kubeadm이 관리하는 일부 컴포넌트에 대한 버전 스큐를 허용하는 동안, kubeadm 버전을 컨트롤 플레인 컴포넌트, kube-proxy, kubelet의 버전과 일치시키는 것이 권장돼요.

Kubernetes 버전에 대한 kubeadm의 스큐 (#kubeadm-s-skew-against-the-kubernetes-version)

kubeadm은 kubeadm과 같은 버전이거나 한 버전 오래된 Kubernetes 컴포넌트와 함께 사용될 수 있어요. Kubernetes 버전은 --config를 사용할 때 kubeadm init의 --kubernetes-version 플래그 또는 ClusterConfiguration.kubernetesVersion(/docs/reference/config-api/kubeadm-config.v1beta4/) 필드로 kubeadm에 지정할 수 있어요. 이 옵션은 kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy의 버전을 제어해요.

예:

  • kubeadm이 1.37에 있음
  • kubernetesVersion은 1.37 또는 1.36이어야 함

kubelet에 대한 kubeadm의 스큐 (#kubeadm-s-skew-against-the-kubelet)

Kubernetes 버전과 유사하게 kubeadm은 kubeadm과 같은 버전이거나 세 버전 오래된 kubelet 버전과 함께 사용될 수 있어요.

예:

  • kubeadm이 1.37에 있음
  • 호스트의 kubelet은 1.37, 1.36, 1.35 또는 1.34여야 함

kubeadm에 대한 kubeadm의 스큐 (#kubeadm-s-skew-against-kubeadm)

kubeadm 명령이 kubeadm이 관리하는 기존 노드나 전체 클러스터에 대해 동작할 수 있는 방법에는 특정 제한이 있어요.

새 노드가 클러스터에 조인되면 kubeadm join에 사용되는 kubeadm 바이너리가 kubeadm init으로 클러스터를 만들거나 kubeadm upgrade로 같은 노드를 업그레이드하는 데 사용된 마지막 kubeadm 버전과 일치해야 해요. kubeadm upgrade를 제외한 나머지 kubeadm 명령에도 유사한 규칙이 적용돼요.

kubeadm join 예시:

  • kubeadm 버전 1.37이 kubeadm init으로 클러스터를 만드는 데 사용됨
  • 조인하는 노드는 버전 1.37의 kubeadm 바이너리를 사용해야 함

업그레이드되는 노드는 노드 관리를 위해 사용된 kubeadm 버전과 같은 MINOR 버전이거나 한 MINOR 버전 더 새로운 kubeadm 버전을 사용해야 해요.

kubeadm upgrade 예시:

  • kubeadm 버전 1.36이 노드를 만들거나 업그레이드하는 데 사용됨
  • 노드 업그레이드에 사용되는 kubeadm 버전은 1.36 또는 1.37이어야 함

다른 Kubernetes 컴포넌트 사이의 버전 스큐에 대해 더 배우려면 버전 스큐 정책을 참고해요.

제한 사항 (Limitations)

클러스터 복원력 (#resilience)

여기서 만든 클러스터는 그 위에서 실행되는 단일 etcd 데이터베이스가 있는 단일 컨트롤 플레인 노드를 가져요. 즉 컨트롤 플레인 노드가 실패하면 클러스터가 데이터를 잃을 수 있고 처음부터 다시 생성해야 할 수도 있어요.

우회 방법:

  • etcd를 정기적으로 백업해요(https://etcd.io/docs/v3.5/op-guide/recovery/). kubeadm이 구성한 etcd 데이터 디렉터리는 컨트롤 플레인 노드의 /var/lib/etcd에 있어요.
  • 여러 컨트롤 플레인 노드를 사용해요. 고가용성(/docs/setup/production-environment/tools/kubeadm/high-availability/)을 제공하는 클러스터 토폴로지를 선택하려면 고가용성 토폴로지 옵션을 읽을 수 있어요.

플랫폼 호환성 (#multi-platform)

kubeadm deb/rpm 패키지와 바이너리는 멀티플랫폼 제안(https://git.k8s.io/design-proposals-archive/multi-platform.md)에 따라 amd64, arm(32-bit), arm64, ppc64le, s390x용으로 빌드돼요.

컨트롤 플레인과 애드온용 멀티플랫폼 컨테이너 이미지도 v1.12부터 지원돼요.

네트워크 프로바이더 중 일부만 모든 플랫폼에 대한 솔루션을 제공해요. 프로바이더가 선택한 플랫폼을 지원하는지 알아보려면 위의 네트워크 프로바이더 목록 또는 각 프로바이더의 문서를 참고해주세요.

문제 해결 (Troubleshooting)

kubeadm에 어려움을 겪고 있다면 문제 해결 문서를 참고해주세요.

다음 단계 (What's next)

피드백 (#feedback)

더 알아보기 (Learn more)