‘3.2 쿠버네티스 클러스터 생성’ 에서 Ubuntu Server가 설치된 노드를 기반으로 쿠버네티스 클러스터를 구축하는 과정을 소개하였습니다. 예를 들어, RKE2를 사용하여 쿠버네티스 클러스터를 구축할 경우, 먼저 Ubuntu Server가 설치된 노드에서 패키지를 최신으로 업데이트하고, 스왑 파티션을 비활성화하며, RKE2를 설치 및 설정하는 과정이 필요합니다. 클러스터의 노드 수가 많아질수록 이러한 과정을 모두 수동으로 하는 것은 매우 비효율적입니다.
Ansible은 서버 구성을 자동화하고 선언적으로 관리하기 위한 도구입니다. Ubuntu Server의 초기 설정부터 쿠버네티스 설정까지 Ansible을 사용하면, 노드가 증가하더라도 Ansible을 실행함으로써 자동으로 구성이 완료됩니다. 이를 통해 시스템 관리자는 대규모 클러스터의 구성과 관리에 걸리는 시간과 노력을 줄일 수 있습니다.
<그림 3-14>의 Ansible 구조에서 각 구성 요소는 다음과 같은 역활을 합니다:
제어 노드 (Control node)
Ansible이 설치된 시스템입니다. 제어 노드에서 ansible 또는 ansible-inventory와 같은 Ansible 명령을 실행합니다. 우리는 로컬 환경을 제어 노드로 사용 합니다.
관리 노드 (Managed node)
Ansible이 제어하는 원격 시스템 또는 호스트입니다. 쿠버네티스 클러스터 설정 자동화에는 컨트롤 플레인 노드, 워커 노드가 관리 노드가 됩니다.
인벤토리 (Inventory)
논리적으로 구성된 관리되는 노드의 목록입니다. 제어 노드에서 인벤토리를 생성하여 Ansible에 대한 호스트 배포를 설명합니다.
Ansible 설치 및 연결
Python pip 패키지 관리자로 Ansible 패키지를 설치하면, Ansible이 설치 됩니다.
각 워커 노드의 RKE2 에이전트 설정 파일에는 컨트롤 플레인의 IP 주소와 RKE2 토큰이 필요합니다. vars.yml 파일을 생성하여 이를 Ansible 변수로 추가 하였습니다. 이렇게 작성한 playbook YAML 파일로 Ansible playbook을 실행하면, 관리 노드들에 RKE2 설치 및 설정이 자동화되어 쿠버네티스 클러스터가 생성 됩니다.
$ ansible-playbook playbook.yml -K
BECOME password: <sudo 계정 비밀번호 입력>
이렇게 Ansible playbook 파일을 작성해 놓으면, 노드 대수와 관계 없이 Ubuntu Server 22.04가 기본 설치된 노드에서 1) Ansible 연결을 위해 sudo 계정 SSH 공용키를 추가하고, 2) 인벤토리 파일에 노드의 IP 주소를 추가해서, 3) ansible-playbook 커맨드만 실행하면 자동 설정되어 편리합니다.
Ansible playbook 파일의 크기가 커질수록 파일을 논리적인 단위로 분할하는 것이 좋습니다. Ansible은 이를 위해 Role 단위로 playbook 파일을 분리할 수 있습니다. 예를 들어, 쿠버네티스 클러스터 생성을 위해 common, control_plane, worker_node 세 개의 Role로 분할할 수 있습니다. 이렇게 분할하면 코드 관리와 유지보수가 용이해지며, 코드 재사용성도 높아집니다.
Helm은 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하도록 설계된 오픈소스 컨테이너 오케스트레이션 플랫폼인 쿠버네티스용 패키지 관리자로 널리 사용되고 있습니다. Helm은 리소스, 구성 및 서비스를 패키징, 공유 및 배포하는 효율적인 방법을 제공함으로써 쿠버네티스 애플리케이션 관리 프로세스를 간소화합니다. Helm은 "Chart"라는 패키징 형식을 사용하는데, 이는 본질적으로 관련 쿠버네티스 리소스 집합을 설명하는 파일 모음입니다. 개발자와 운영자는 이러한 차트를 사용하여 가장 복잡한 쿠버네티스 애플리케이션도 일관되고 유지 관리 가능한 방식으로 정의, 설치 및 업그레이드할 수 있습니다.
Helm은 Chart 관리 외에도 사용자가 변수와 함수를 사용하여 배포를 사용자 정의할 수 있는 강력한 템플릿 엔진을 제공합니다. 이러한 유연성 덕분에 다양한 환경이나 구성에서 Chart를 쉽게 재사용할 수 있어 배포 프로세스가 간소화되고 오류 발생 가능성이 줄어듭니다. Helm에는 Chart 및 릴리스 관리를 간소화하는 강력한 명령줄 인터페이스(CLI)와 Tiller(Helm v2에서 사용) 또는 간단히 Helm(Helm v3에서 사용)이라는 서버 측 구성 요소가 탑재되어 있습니다. 이 구성 요소는 쿠버네티스 API 서버와 상호 작용하여 쿠버네티스 리소스를 설치, 업그레이드, 쿼리 및 제거합니다.
💡
패키지 관리 도구들
Ubuntu/Debian: apt
MacOS: brew
쿠버네티스: helm
Helm 설치
get_helm.sh 스크립트로 설치하거나 MacOS 환경은 brew 로 helm을 설치 할 수 있습니다.
NAME CHART VERSION APP VERSION DESCRIPTION
bitnami/airflow 14.1.1 2.5.3 Apache Airflow is a tool to express and execute...
bitnami/apache 9.5.2 2.4.57 Apache HTTP Server is an open-source HTTP serve...
bitnami/appsmith 0.2.1 1.9.17 Appsmith is an open source platform for buildin...
bitnami/argo-cd 4.6.2 2.6.7 Argo CD is a continuous delivery tool for Kuber...
bitnami/argo-workflows 5.1.14 3.4.7 Argo Workflows is meant to orchestrate Kubernet...
bitnami/aspnet-core 4.0.11 7.0.5 ASP.NET Core is an open-source framework for we...
bitnami/cassandra 10.2.1 4.1.1 Apache Cassandra is an open source distributed ...
bitnami/cert-manager 0.9.6 1.11.1 cert-manager is a Kubernetes add-on to automate...
(...이하 생략)
Helm 기본 사용법
Helm Chart 설치는 helm install 커맨드로 할 수 있습니다.
$ helm repo update # 저장소의 최신 차트 목록으로 갱신 합니다.
$ helm install mysql bitnami/mysql
NAME: mysql
LAST DEPLOYED: Wed May 3 00:42:11 2023
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: mysql
CHART VERSION: 9.8.2
APP VERSION: 8.0.33
(...이하 생략)
helm install 커맨드의 포맷은 다음과 같습니다.
$ helm install <Release 이름> <저장소/Chart>
Helm 사용시 특정 네임스페이스에 Chart를 설치하려면 helm install -n <Namepsace>또는 helm install --namespace <Namespace> 로 네임스페이스 옵션을 추가 하시면 됩니다.
ArgoCD는 오픈 소스, 쿠버네티스 네이티브 지속적 배포(CD) 도구로, 쿠버네티스 클러스터 내에서 애플리케이션의 배포, 모니터링, 관리를 간소화합니다. 대표적인 GitOps 도구인 ArgoCD는 Git 리포지토리에 정의된 대로 원하는 애플리케이션 상태를 쿠버네티스 환경에서 실행되는 실제 상태와 동기화하는 작업을 자동화합니다. 이 접근 방식은 전체 애플리케이션 수명 주기를 버전 제어 및 추적할 수 있도록 보장하여 신속한 롤백, 손쉬운 감사, 팀원 간의 향상된 협업을 촉진합니다. ArgoCD는 Helm, Kustomize, Jsonnet과 같은 광범위한 구성 관리 도구를 지원하므로 개발자가 선호하는 방법을 사용하여 쿠버네티스 리소스를 정의할 수 있습니다.
ArgoCD의 핵심 강점은 애플리케이션 리소스의 실시간 시각화 및 상태 모니터링 기능을 제공하여 사용자가 원하는 상태와 실제 상태 간의 불일치를 신속하게 식별하고 수정할 수 있다는 점입니다. 직관적인 사용자 인터페이스는 명령줄 및 API 옵션과 함께 개발자와 운영자 모두에게 원활한 경험을 제공합니다. 또한 ArgoCD는 Jenkins, GitLab, CircleCI 등 널리 사용되는 지속적 통합(CI) 도구와 쉽게 통합하여 완벽한 CI/CD 파이프라인을 구축할 수 있습니다. 역할 기반 액세스 제어(RBAC) 및 싱글 사인온(SSO)과 같은 기본 제공 보안 기능을 통해 권한이 부여된 사용자만 애플리케이션 리소스를 변경할 수 있으므로 배포 프로세스 전반에 걸쳐 높은 수준의 보안을 유지할 수 있습니다.
ℹ️
GitOps
GitOps는 선언적 인프라 및 애플리케이션 코드에 대한 신뢰할 수 있는 단일 소스로 Git을 사용하는 애플리케이션 개발 및 운영에 대한 최신 접근 방식입니다. 이 방법론은 Git 리포지토리를 애플리케이션 및 인프라의 원하는 상태에 대한 변경 사항을 저장, 버전 관리 및 추적하는 중앙 허브로 취급하여 애플리케이션의 배포, 관리 및 모니터링을 간소화합니다. GitOps는 Git의 강력한 버전 제어 기능과 DevOps의 원칙을 결합하여 전체 소프트웨어 개발 라이프사이클에서 협업, 투명성 및 효율성을 개선할 수 있습니다.
GitOps 워크플로에서 DevOps 엔지니어는 인프라의 원하는 상태를 코드로 선언하여 Git 리포지토리에 저장합니다. 그런 다음 CI(지속적 통합) 및 CD(지속적 배포) 파이프라인을 설정하여 배포 환경에서 실행 중인 실제 상태를 리포지토리에 정의된 상태와 동기화합니다. 이 접근 방식은 인프라 또는 애플리케이션에 대한 모든 변경 사항을 버전 제어, 감사 및 추적할 수 있도록 보장합니다. GitOps는 자동화 향상, 장애로부터의 빠른 복구, Pull Request 검토 및 액세스 제어를 통한 보안 강화, 팀원 간의 보다 쉬운 협업 등 여러 가지 이점을 제공합니다. GitOps 접근 방식을 용이하게 하는 인기 있는 도구로는 쿠버네티스 및 기타 클라우드 네이티브 기술과 원활하게 작동하도록 설계된 ArgoCD, Flux, Jenkins X 등이 있습니다.
그림 3-15. GitOps CI/CD 워크플로우
ArgoCD 설치
쿠버네티스 클러스터에 ArgoCD를 Helm을 사용해서 설치하겠습니다. (공식 가이드 문서에 따라 install.yaml 파일로 설치하셔도 됩니다.)
deployment.apps/argocd-applicationset-controller condition met
deployment.apps/argocd-dex-server condition met
deployment.apps/argocd-notifications-controller condition met
deployment.apps/argocd-redis condition met
deployment.apps/argocd-repo-server condition met
deployment.apps/argocd-server condition met
로컬 호스트의 8080 포트로 포워딩을 해서 ArgoCD 웹 UI로 접속합니다. 초기 접속 계정 ID는 Username은 admin , 비밀번호는 argocd-initial-admin-secret Secret에 저장되어 있습니다. 아래 커맨드로 Secret에 저장된 비밀번호를 확인 할 수 있습니다.
REFRESH: Git 저장소의 최신 어플리케이션 설정 값을 ArgoCD에 읽어 옵니다. (Git Repo → ArgoCD)
DELETE: ArgoCD 어플리케이션을 삭제 합니다.
SYNC 버튼을 클릭하여 ArgoCD와 쿠버네티스간의 동기화가 완료되면 어플리케이션 Status 값이 Healthy, Synced 로 변경 됩니다.
kubectl 로 guestbook 어플리케이션이 배포되었는지 확인해 보겠습니다.
$ kubectl get all
NAME READY STATUS RESTARTS AGE
pod/guest-book-helm-guestbook-6dcf44954d-v2fpf 1/1 Running 0 9m45s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/guest-book-helm-guestbook ClusterIP 10.96.208.65 <none> 80/TCP 9m45s
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 20d
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/guest-book-helm-guestbook 1/1 1 1 9m45s
NAME DESIRED CURRENT READY AGE
replicaset.apps/guest-book-helm-guestbook-6dcf44954d 1 1 1 9m45s
guestbook 관련 리소스가 모두 배포되어 있네요! 앞서 ArgoCD 어플리케이션을 추가할때 설정했던 각 항목들에 대한 내용은 다음과 같습니다.
GENERAL: 일반적인 설정 항목들
Application Name: 어플리케이션 이름
Project Name: 프로젝트 이름. 임의 기입은 되지 않고, ArgoCD에 존재하는 프로젝트에서 선택해야 합니다. 새로운 프로젝트 추가는 Settings → Projects 메뉴에서 추가 합니다.
SYNC POLICY: 동기화 방식
Manual 은 배포 담당자가 직접 SYNC를 해야 하며, 주로 Production 환경 배포에 사용
Automatic 은 ArgoCD가 변경점 감지시 자동 배포. 주로 Develop 환경 배포에 사용
SOURCE: 환경 저장소 관련 설정
Repository URL: Git 원격 저장소 URL. Private 저장소는 Settings → Repositories 메뉴에서 추가 및 설정이 필요합니다.
Revision: Git의 Revsion (HEAD 혹은 main 등의 브랜치 이름도 사용 가능)
Path: Git 원격 저장소내 어플리케이션 설정 파일의 위치
DESTINATION: 배포 대상(k8s) 관련 설정
Cluster URL: 배포할 쿠버네티스 클러스터 URL. https://kubernetes.default.svc 는 현재 ArgoCD가 설치된 쿠버네티스 (즉, in-cluster)를 의미 합니다. 배포 대상이 다른 쿠버네티스 클러스터이면 argocd CLI로 클러스터를 추가해야 합니다.
Terraform은 해시코프에서 개발한 오픈소스 IaC (Infrastructure as Code) 도구로, 사용자가 HCL (HashiCorp Configuration Language)이라는 선언형 언어를 통해 클라우드 인프라를 자동화하고 관리할 수 있게 해줍니다. Terraform은 코드를 사용하여 인프라 리소스를 정의하고 프로비저닝함으로써 일관되고 반복 가능한 배포를 가능하게 하여 인적 오류를 줄이고 전반적인 효율성을 개선합니다. 이 도구는 모듈식 공급자 시스템을 통해 AWS, Azure, Google Cloud 등 여러 클라우드 플랫폼을 지원하므로 확장성이 뛰어나고 다양한 인프라 요구 사항에 맞게 조정할 수 있습니다. Terraform의 협업 및 버전 제어 접근 방식은 개발, 스테이징 및 프로덕션 환경 전반의 인프라를 관리하기 위한 DevOps 실무자들 사이에서 인기 있는 선택이 되었습니다.
이 시리즈에서 설명하는 MLOps 도구는 주로 온프레미스 환경을 대상으로 하므로 Terraform을 활용하지 않습니다. 하지만 인프라 관리 도구로서 Terraform의 중요성을 고려할 때, IaC와 그 대표적인 도구인 Terraform을 언급하는 것은 필수적입니다. 게다가 실제 프로젝트에서는 클라우드와 온프레미스가 결합된 하이브리드 클라우드 환경이 널리 사용되고 있습니다. 따라서 Terraform 사용의 기본 사항을 간략히 살펴보는 것이 좋습니다.
💡
쿠버네티스와 IaC 도구들
IaC는 인프라를 코드로 관리하는 것이 핵심입니다. 대표적인 IaC 도구인 Terraform과 Ansible을 사용하여 쿠버네티스 클러스터 생성하려면 다음과 같이 합니다:
Terraform으로 클러스터 노드를 프로비저닝 하고, (노드 생성)
Ansible로 각 노드를 설정하여 쿠버네티스 클러스터를 만든다. (노드 설정)
공용 클라우드 서비스는 EKS, GKE, AKS등의 관리형 쿠버네티스 환경을 Terraform에서 직접 프로비저닝하므로 Ansible이 필요 없습니다. 하지만, OpenStack등을 사용하는 사설 클라우드 환경에는 위와 같이 Terraform과 Ansible을 조합하여 쿠버네티스 클러스터를 생성합니다. 여기에 ArgoCD나 Flux같은 GitOps 도구까지 추가하면 코드로 대부분의 인프라 리소스를 관리할 수 있습니다.
Terraform 설치
Terraform이라고 하면 terraform 이라는 CLI 도구를 의미 합니다. brew 나 apt 패키지 관리자로 설치 할 수 있습니다.
brew (MacOS)
$ brew tap hashicorp/tap
$ brew install hashicorp/tap/terraform
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# aws_instance.app_server will be created
+ resource "aws_instance" "app_server" {
+ ami = "ami-830c94e3"
+ arn = (known after apply)
+ associate_public_ip_address = (known after apply)
+ availability_zone = (known after apply)
+ cpu_core_count = (known after apply)
+ cpu_threads_per_core = (known after apply)
+ disable_api_stop = (known after apply)
+ disable_api_termination = (known after apply)
+ ebs_optimized = (known after apply)
(...이하 생략)
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
aws_instance.app_server: Creating...
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]
aws_instance.app_server: Still creating... [30s elapsed]
aws_instance.app_server: Still creating... [40s elapsed]
aws_instance.app_server: Still creating... [50s elapsed]
aws_instance.app_server: Still creating... [1m0s elapsed]
aws_instance.app_server: Creation complete after 1m5s [id=i-07c4ba04f5ff58673]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
terraform apply 가 완료된 이후 AWS 웹 콘솔에 접속하여 EC2 서비스 us-west-2 리즌을 확인해보면, HCL 파일에 정의한 EC2 인스턴스가 생성되어 있습니다.
그림 3-18 AWS 콘솔의 EC2 메뉴
Terraform은 HCL 파일을 적용할 때 terraform.tfstate 파일에 인프라 관련 내용들을 모두 기입합니다. 실제 Terraform 동작은 .tf 파일들에서 인프라 관련 자세한 설정이 있는 terraform.tfstate 파일을 생성하고, terraform.tfstate 파일 내용에서 실제 인프라를 생성 및 삭제합니다. terraform.tfstate 파일에는 인프라에 관련된 민감한 내용이 종종 포함되어 있으므로, 관리에 유의해야 합니다. (GitHub과 같은 Git 저장소에 올리지 마세요!)
생성된 인프라를 삭제하는 것은 terraform destroy 커맨드로 할 수 있습니다. terraform.tfstate 파일에 기입된 인프라 리소스를 제거하고 해당 파일 내용을 갱신합니다.
$ terraform destroy
aws_instance.app_server: Refreshing state... [id=i-07c4ba04f5ff58673]
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the
following symbols:
- destroy
Terraform will perform the following actions:
# aws_instance.app_server will be destroyed
- resource "aws_instance" "app_server" {
- ami = "ami-830c94e3" -> null
- arn = "arn:aws:ec2:us-west-2:915194574876:instance/i-07c4ba04f5ff58673" -> null
- associate_public_ip_address = true -> null
- availability_zone = "us-west-2a" -> null
- cpu_core_count = 1 -> null
- cpu_threads_per_core = 1 -> null
- disable_api_stop = false -> null
- disable_api_termination = false -> null
- ebs_optimized = false -> null
- get_password_data = false -> null
- hibernation = false -> null
(...이하 생략)
Plan: 0 to add, 0 to change, 1 to destroy.
Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value: yes
aws_instance.app_server: Destroying... [id=i-07c4ba04f5ff58673]
aws_instance.app_server: Still destroying... [id=i-07c4ba04f5ff58673, 10s elapsed]
aws_instance.app_server: Still destroying... [id=i-07c4ba04f5ff58673, 20s elapsed]
aws_instance.app_server: Still destroying... [id=i-07c4ba04f5ff58673, 30s elapsed]
aws_instance.app_server: Destruction complete after 32s
Destroy complete! Resources: 1 destroyed.
AWS 콘솔을 확인해보면, 앞서 생성한 EC2 인스턴스가 삭제되어 있습니다.
Terraform에 대한 좀 더 많은 정보는 Terraform 문서를 참고하시기 바랍니다.
Python으로 인프라를 생성하는 CDKTF(CDK for Terraform)에 대한 내용은 여기에 있습니다.
3.4 요약
이번 장에는 쿠버네티스 클러스터를 구축하고, 인프라 관리 도구들을 설치 및 설정을 하였습니다. 3장에서 했던 작업들을 정리하였습니다 (MacOS 환경):
