본문 바로가기

DevOps/Kubernetes

[Kubernetes] HAProxy와 Keepalived를 활용한 Kubernetes API 클러스터 HA 구현 - 2편

0. 들어가며

 지난 포스팅에 이어 바로 2편을 작성하지 않고, 먼저 Kubernetes Cluster 구축 방법에 대한 내용으로 포스팅을 진행했습니다. 이유는, 단일 Control Plane(이전에는 Master 노드라고 이야기 해였습니다. 'Master'가 주종관계를 나타내는 단어라 앞으로는 Control Plane으로 사용하기로 하겠습니다. 여기서 또 PC가...)으로 Kunbernetes 환경을 구성하는 방법을 알아야 그 다음에 2대 이상으로 이루어진 멀티 Control Plane 구성이 가능하기 때문입니다. 그리고... 사실 제가 바쁘기도 했고 또, Home Lab 환경에 큰 변화가 있었던 것도 그 이유 중에 하나입니다. (그래서, IP 주소도 변화가 있었습니다.) 최대한 내용이 이어질 수 있도록 포스팅을 진행 하도록 하겠습니다. 너른 양해 부탁드립니다.

 

1. 멀티 노드로 Kubernetes Control Plane 구성하기

 우선, 이전에 했던 포스팅을 한번 살펴 보셨으면 합니다.

 

[Kubernetes] HAProxy와 Keepalived를 활용한 Kubernetes API 클러스터 HA 구현 - 1편

0. 들어가며 Kubernetes 클러스터는 크게 Master 노드(Control Plane 역할)와 Worker 노드(워크로드 구동 역할)로 나뉩니다. 프로덕션 환경에서는 고가용성(HA) 및 로드 밸런싱을 위해 Master 노드를 여러대로

tech-recipe.tistory.com

 지난 포스팅에서는 HAProxy와 Keepalived를 통해 가상 IP 주소에 대한 HA 기능을 구현해 보았습니다. 이 가상 IP를 앞으로 구성하게 될 Kubernetes API Server의 End-Point로 활용할 것입니다. 그리고 한 가지 더 구성해야 할 것이 있는데 바로 멀티 Control Plane을 가진 Kubernetes Cluster입니다. 이는 아래 포스팅을 통해 확인할 수 있습니다.

 

[Ubuntu 22.04] Kubernetes Cluster 구축 - 2편

0. 들어가며 [Ubuntu 22.04] Kubernetes Cluster 구축 - 1편에서 이어지는 내용으로 전편을 참고한 후 해당 포스팅을 보는 것을 추천드린다. [Ubuntu 22.04] Kubernetes Cluster 구축 - 1편 0. 들어가며 Kubernetes 강의를

tech-recipe.tistory.com

 해당 포스팅도 1편부터 보시는걸 추천드리지만, 만약 VM으로 Ubuntu 설치가 어렵지 않으시다면 2편부터 보셔도 무방합니다. 링크된 포스팅의 중반부 '5) Kubeadm을 통한 Kubernetes 클러스터 구성'에 보시면 아래와 같은 명령어를 실행합니다.

sudo kubeadm init --apiserver-advertise-address=192.168.0.150
#sudo kubeadm init --apiserver-advertise-address=[Kubernetes Cluster의 Control Plane 노드의 IP 주소]

 단일 Control Plane으로 Kubernetes Cluster를 구성할 시에는 위와 같은 명령어를 사용하면 되지만, 멀티 Control Plane 노드를 통해 Cluster 형식으로 Kubernetes API Server를 구축할 때는 명령어가 달라집니다. 여러 대의 Control Plane 노드 중 하나에 아래와 같은 명령어를 사용하시면 됩니다.(이전 포스팅 기준으로, Kubernetes Master 01인 172.16.11.151번 IP를 가진 노드에서 해당 명령어를 실행해 주었습니다.)

sudo kubeadm init --control-plane-endpoint "172.16.11.150:6443" --upload-certs
#sudo kubeadm init --control-plane-endpoint "[가상 IP 주소:포트번호]" --upload-certs

 참고로, 이전 포스팅에서 가상 IP 주소를 172.16.11.150으로 사용하기로 했기 때문에, 위 명령어의 IP 주소가 172.16.11.150이 되었습니다. 구성하시는 환경에 맞도록 해당 IP 주소를 바꿔주면 됩니다. 포트번호는 Control Plane의 API 서버가 사용하는 번호를 사용했는데 다른 것으로 바꾸셔도 무방합니다. 그러면 아래와 비슷한 문구가 출력되는 것을 확인할 수 있습니다.

You can now join any number of control-plane node by running the following command on each as a root:
    kubeadm join 172.16.11.150:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
#위 명령어를 꼭 확인할 것! 해당 명령어를 다른 Control Plane 노드에 입력해 주어야 함.
#kubeadm join [가상 IP 주소:포트번호] --token [출력된 토큰 값] --discovery-token-ca-cert-hash sha256:[출력된 해시 값]

Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.

Then you can join any number of worker nodes by running the following on each as root:
    kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866

 위에서 보는 것과 같이, 멀티 노드로 Control Plane을 구성하게 되면 기존의 단일 노드로 Control Plane을 구성할 때와는 다른 명령어를 하나 확인할 수 있습니다. 바로 Control Plane으로 구성될 노드에 입력해야할 명령어입니다. 해당 명령어를 다른 노드에 입력하면 됩니다.

sudo kubeadm join 172.16.11.150:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
#Master 02와 Master 03에 위 명령어를 각각 입력해 줍니다. 이때 토큰 값과 해시 값은 다를 것이기 때문에 실제 화면에 출력된 값을 복사해서 입력해 줍니다.

 일반 사용자 계정이기 때문에, root 권한으로 명령어를 실행하기 위해 앞에 sudo를 붙여 주는 것을 잊지 않아야 합니다. 위 명령어를 각각 남아 있는 Control Plane 노드에 입력해주면 그 뒤 내용은 동일합니다. Worker 노드를 Join 시켜주면 클러스터 구성이 마무리됩니다.

 

2. API End-Point를 통해 Kubernetes Cluster 제어하기

 위와 같은 방식으로 Kubernetes Cluster 구성이 마무리되었으면 이제 외부에서 API 서버를 제어할 Console이 필요할 것입니다. 아래 그림과 같은 형식이 될 것인데요.

[그림 1] Kubernetes Cluster와 외부 Console

 이렇게 구성하는 것이 타당해 보입니다. 우선 가상 IP 주소를 통해 API Server를 조작하기 때문에 로드밸런서의 기능도 활용하게 되고, 직접적으로 Control Plane 노드에 접속하지 않기 때문에 보안상 이점도 가져갈 수 있습니다.

 

 콘솔은 kubectl이 설치된 Linux 계열의 호스트라면 어떤 것이든 상관이 없습니다. 이제 Control Plane에서 Kubernetes Cluster에 대한 Context만 가져오면 됩니다. Control Plane 노드에서 아래와 같은 내용을 조회합니다.

cat ~/.kube/config
#Kubernetes Cluster에 대한 Context를 조회 합니다.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: [암호화된 값이 출력됨]
    server: https://172.16.11.150:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: [암호화된 값이 출력됨]
    client-key-data: [암호화된 값이 출력됨]

[사진 1] 실제로는 위와 같이 암호화된 문자열이 길게 출력

 이 부분에 대해서는 Kubernetes의 인증과 인가에 따로 다루는 포스팅을 게시하도록 하겠습니다. 현재는 우선 Kubernetes Cluster에 대한 모든 권한을 가진 admin 권한의 Context를 사용하는 방법을에 대해서 알려드립니다.

 위 명령어로 ~/.kube/config 파일의 위치를 확인했다면, 해당 경로에 위치한 config 파일의 내용을 복사하여 Console에 같은 위치로 같은 이름의 파일명을 통해 해당 내용을 붙여 넣어도 좋고, 아니면 파일 자체를 복사해도 됩니다. 그리고 Console에서 kubectl 명령어를 실행하면 구성된 Kubernetes Cluster를 제어할 수 있음을 확인할 수 있습니다.

 

3. 마무리

 두 편의 걸친 포스팅과, Kubernetes Cluster 구성에 관한 포스팅을 통해 Kubernetes API Server의 Cluster 구성과, HA, LB 기능에 대해 알아보았습니다. 물론 현업에서는 퍼블릭 클라우드에서 제공하는 Kubernetes 서비스와 같이 제품화된 서비스를 사용하는 경우가 많아 위와 같은 구성을 직접 할 경우는 적겠지만, 해당 내용을 통해 Kubernetes에 대한 이해가 한층 더 높아졌기를 바랍니다. 감사합니다.

 

 마지막으로, 관련 내용에 대한 Kubernetes 공식 문서 링크도 남겨 드립니다. 학습에 참고가 되길 바랍니다.

 

Creating Highly Available Clusters with kubeadm

This page explains two different approaches to setting up a highly available Kubernetes cluster using kubeadm: With stacked control plane nodes. This approach requires less infrastructure. The etcd members and control plane nodes are co-located. With an ex

kubernetes.io