Virtual Machine으로 Kubernetes Cluster 구성하기 (2)

안녕하세요. HYEN입니다.

지난 글에 이어서 Virtual Machine으로 Kubernetes Cluster를 구성하는 테스트를 다뤄보도록 하겠습니다. 

(지난 글 : https://with-cloud.tistory.com/25)

Virtual Machine으로 Kubernetes Cluster 구성하기 (1)

---

Contents

 

3. Control Plane 구성

3.1 kubeadm init

Kubernetes Cluster용 [가상 머신] 모두에게 설치해야 할 것들을 모두 설치하였습니다.

지금부터는 Control Plane에서 kubeadm init 명령어를 사용하여 본격적으로 Kubernetes Cluster를 구성해 보도록 하겠습니다.

 

※ kubeadm init 명령어는 반드시 Control Plane에서만 설치하여야 합니다.※

 

• kubeadm init 명령어를 실행합니다.
  • 만약 pod cidr 대역이 기본값과 다르다면 (default : 192.168.0.0/16) --pod-network-cidr flag를 사용하여 사용할 pod의 cidr 대역을 직접 명시해 주어야 합니다.
  • (본 테스트에서는 default cidr 대역을 그대로 사용하기 때문에 kubeadm init 명령어만 사용하였습니다.)

 

• 테스트 중 발생했던 Preflight Error에 대한 Trouble Shooting 내역을 정리해 보았습니다.

 

저는 하기와 같은 에러가 발생했는데요. ☠️

4개의 에러를 해결해야 kubeadm init이 정상적으로 실행되게 됩니다.

 

• socket not found in system path라는 문구가 출력되어 있으므로 socket을 설치합니다.
  해당 문구는 Warning이기 때문에 설치하지 않으셔도 무방합니다.
  • sudo apt-get update && sudo apt-get install -y socat

 

• conntrack not found in system path라는 문구가 출력되어 있으므로 conntrack을 설치합니다.
  • sudo apt-get update && sudo apt-get install -y conntrack

 

• /proc/sys/net/bridge/bridge-nf-call-iptables does not exist라는 문구가 출력되어 있으므로 echo 명령어를 사용하여 1을 해당 파일에 넣어 줍니다.
  • echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
    
    
  • 만약 상기 명령어를 입력했을 때 에러가 발생한다면 modprobe br_netfilter 라는 명령어를 실행합니다.
    해당 명령어는 CNI 플러그인이 작동하기 위한 요구사항인 modprobe br_netfilter 모듈을 설치하는 명령어입니다.
    
    
  • 이 모듈은 Bridge를 통과하는 네트워크 패킷을 필터링하는 역할을 하는데요.
    Kubernetes Cluster에서 Network Policy를 구현하고 트래픽을 관리하는데 도움이 되는 커널 모듈이라고 보시면 됩니다.
    
    
  • modprobe br_netfilter 명령어를 실행한 후 다시 echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables 명령어를 입력하면 됩니다.

 

• /proc/sys/net/ipv4/ip_forward contents are not set to 1이라는 문구가 출력되어 있으므로 echo 명령어를 사용하여 1을 해당 파일에 넣어 줍니다.
  • echo 1 > /proc/sys/net/ipv4/ip_forward

 

 

모든 preflight error를 해결하고 난 후 kubeadm init 명령어를 다시 실행하면 정상적으로 초기화가 진행됩니다.

명령어가 성공적으로 실행되면 2가지를 수행해야 합니다.

 

• 첫 번째로 하기 명령어를 모든 가상 머신에서 실행하는 것입니다. 

  

  • 만약 Node Server에서 상기 명령어가 제대로 작동하지 않을 경우 Control Plane에서 해당 명령어를 먼저 실행한 후 scp 명령어를 통해 해당 파일을 $HOME/.kube (없으면 mkdir -p $HOME/.kube 명령어로 먼저 생성)에 붙여 넣습니다. 

 

• 두 번째로 kubeadm join으로 시작하는 명령어를 Nodes에서 각각 실행합니다. (root 계정으로 실행해야 합니다.)

  

  • node-hyein-01에서 상기 명령어 수행 결과

    

  • node-hyein-02에서 상기 명령어 수행 결과

    

 

• join 작업이 완료된 후 Control Plane에서 kubectl get nodes 명령어를 입력하면 하기와 같이 Kubernetes Cluster를 이루는 3 대의 가상 머신이 보이게 됩니다.

  

 

3.2 Conatiner Network Interface(CNI) 설치

Kubernetes Cluster 내 pod 통신을 위해서는 CNI(Container Network Interface)가 필요합니다.

CNI는 또 무엇일까요?? 🫠

 

Container Network Interface인 CNI는 container 기술에서 network interface를 정의하는 표준 스펙으로, 이를 통해 container가 호스트 및 다른 container, 외부 시스템과 통신할 수 있도록 지원합니다.

CNI는 다양한 network plugin을 통해 구현될 수 있으며 이러한 plugin은 Kubernetes와 같은 orchestration tool에서 사용됩니다.

 

좀 더 쉽게 정의하자면,

CNI는 container 간 네트워킹에 필요한 plugin에 대한 표준이라고 생각하시면 될 것 같습니다.

 

이러한 CNI plugin에는 Calico, Weave, Flannel 등 여러 가지 종류의 3rd party plugin이 존재하는데요.

여러 CNI 중 이번 테스트에서는 Calico를 사용해 보도록 하겠습니다.

 

※ CNI는 반드시 Control Plane에서만 설치하여야 합니다.※

 

하기 공식 문서를 참고하여 Calico를 설치하면 됩니다. (Manifest 사용)

(https://docs.tigera.io/calico/latest/getting-started/kubernetes/self-managed-onprem/onpremises)

 

• Kubernetes API datastore에 Calico Networking manifest를 다운로드합니다.
  curl <https://raw.githubusercontent.com/projectcalico/calico/v3.27.2/manifests/calico.yaml> -O

  

 

• pod cidr를 변경하였다면 yaml file에서 해당 부분을 변경해 주어야 하지만 본 테스트에서는 기본값을 사용하기 때문에 생략하겠습니다.

 

• manifest를 적용하기 위해 kubectl apply -f calico.yaml 명령어를 입력합니다.

  

• 생성을 완료한 후 kubectl get nodes를 해보면 하기 스크린샷과 같이 STATUS가 Ready로 변경되어 있는 것을 확인할 수 있습니다.

  

 

3.3 Node Labeling (Optional)

kubectl get nodes를 했을 때 ROLES 부분에 Control Plane은 control-plane이라고 되어 있지만 Node들은 <none>이라고 표기가 되어 있는데요.

 

저는 이 부분이 마음에 들지 않기 때문에 Labeling을 통해서 각 Node에 node라는 역할을 부여해 보도록 하겠습니다.

 

• kubectl label nodes node-hyein-01 node-role.kubernetes.io/node= 명령어를 실행합니다.

  

  • node-hyein-01 Node의 ROLES column에 node라는 역할이 제대로 부여된 것을 확인할 수 있습니다.

 

• 이어서 node-hyein-02 Node도 동일하게 진행해 줍니다.

  

---

이렇게 VM 상에 Kubernetes Cluster를 구성하는 과정을 마쳐 보았습니다.

다음 글에서는 지금까지 구성한 Kubernetes Cluster의 ETCD에 저장되는 Secret Data에 대한 암호화에 대해 다뤄보겠습니다.