Skip to Content
Infra & DevOpskubeadm 1.13.1 클러스터 구성 순서와 확인 항목
☁️ Infra & DevOps2018년 12월 17일

kubeadm 1.13.1 클러스터 구성 순서와 확인 항목

#kubernetes#docker#infra-devops#centos#flannel#cluster-setup
kubeadm 클러스터 구성과 버전 업그레이드1 / 4
Kubernetes 1.13 당시 문서를 바탕으로 호스트 준비, kubeadm 초기화, Pod 네트워크와 워커 연결의 역할을 정리합니다.

Kubernetes 1.13.1을 기준으로 클러스터 구성 순서를 정리한 글입니다. 당시 설치 문서와 현재 문서의 명령을 섞으면 패키지 저장소와 런타임 설정부터 달라질 수 있어 버전을 구분했습니다.

여기서는 호스트 준비, control plane 초기화, Pod 네트워크와 워커 연결을 나눠 살펴봅니다. 현재 새 클러스터를 만들 때는 지원하는 Kubernetes 버전의 설치 문서를 사용해야 합니다.

호스트와 패키지 준비

당시 문서는 CentOS 7 등의 호스트에서 네트워크 연결과 노드 식별 정보, 필요한 포트를 확인하도록 안내했습니다. kubelet의 기본 구성에서는 swap 비활성화도 요구했습니다.

확인할 항목은 다음처럼 나눌 수 있습니다.

항목확인할 내용
노드 정보호스트 이름·MAC·product UUID의 중복 여부
네트워크노드 간 통신, API 서버 주소와 CNI가 사용하는 포트
런타임해당 Kubernetes 버전과 호환되는 런타임·cgroup 설정
패키지kubeadm·kubelet·kubectl의 버전과 설치 출처
이미지초기화와 네트워크 플러그인에 필요한 이미지 접근

방화벽을 모두 끄거나 SELinux 설정을 일괄 변경하는 스크립트를 모든 환경의 공통 절차로 사용할 수는 없습니다. 당시 문서의 전제와 실제 호스트의 정책을 함께 확인해야 합니다.

Control Plane 초기화

런타임과 패키지 준비 후 control plane 노드에서 kubeadm init을 실행합니다. 다음은 주소와 Pod 대역을 지정하는 형식의 예시입니다.

bash
kubeadm init --kubernetes-version=v1.13.1 \ --apiserver-advertise-address=192.0.2.10 \ --pod-network-cidr=10.244.0.0/16

192.0.2.10은 설명용 주소이므로 실제 노드 주소로 바꿔야 합니다. Pod 대역도 호스트·서비스 네트워크와 충돌하지 않아야 하며, 사용할 네트워크 플러그인 설정과 맞춰야 합니다. Flannel을 사용한다고 모든 환경에서 이 대역을 강제하는 것은 아닙니다.

초기화 중 오류가 나면 preflight 결과와 kubelet 로그부터 확인합니다. 원인을 확인하지 않고 kubeadm reset이나 설정 디렉터리 삭제를 기본 해결책으로 삼지는 않아야 합니다.

kubectl 자격 증명

초기화 결과에 따라 관리할 사용자의 kubeconfig를 준비합니다. 당시 안내의 기본 형식은 다음과 같습니다.

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

이 파일에는 클러스터 접근 자격 증명이 들어갑니다. 애플리케이션 설정 파일처럼 저장소에 넣어 공유할 대상은 아닙니다.

Pod 네트워크와 워커 연결

Pod 네트워크 플러그인은 별도로 설치합니다. Flannel을 사용한다면 해당 Kubernetes 버전과 맞는 매니페스트를 준비하고 Pod 대역·인터페이스·이미지 주소를 확인한 뒤 적용합니다.

bash
kubectl apply -f kube-flannel.yaml

이 명령의 파일은 미리 검토한 로컬 매니페스트를 뜻합니다. 오래된 클러스터에 현재 master 브랜치의 파일을 그대로 적용하는 예시는 사용하지 않았습니다.

워커 노드에서는 초기화 결과에 안내된 kubeadm join 명령을 사용합니다. 대상 주소와 토큰, CA 확인 정보를 실제 클러스터의 값으로 맞춰야 합니다.

구성 후 확인

bash
kubectl get nodes -o wide kubectl get pods -n kube-system -o wide

노드가 Ready인지 확인한 뒤 DNS와 노드 간 Pod 통신, 실제 워크로드의 요청까지 이어서 확인합니다. 노드 상태 하나만으로 모든 네트워크와 저장소 구성이 끝났다고 판단하기는 어렵습니다.

참고 자료

Last updated on