"Cluster API 퀵스타트"의 두 판 사이의 차이

9번째 줄: 9번째 줄:


==설치==
==설치==
두 가지 주요 빠른시작 경로가 있습니다. clusterctl 또는 Cluster API Operator를 사용하는 것입니다.
이 글에서는 clusterctl CLI 도구를 사용하여 클러스터 API 관리 클러스터의 수명주기를 처리하는 경로를 설명합니다.
clusterctl 명령줄 인터페이스는 간단한 "1일차 경험"과 Cluster API를 통한 빠른 시작을 제공하기 위해 특별히 설계되었습니다. 제공자 구성요소를 정의하는 YAML 파일을 가져오고 설치하는 작업을 자동화합니다.
추가적으로 사용자가 잘못 설정하는 것을 방지하거나 업그레이드와 같은 2일차 작업을 관리하는 데 도움이 되는 제공자 관리에 대한 일련의 모범사례를 나타냅니다.
Cluster API Operator는 clusterctl을 기반으로 구축된 Kubernetes Operator이며 클러스터 관리자가 선언적 접근방식을 사용하여 관리 클러스터 내에서 Cluster API 제공자의 수명주기를 처리할 수 있도록 설계되었습니다. Cluster API 배포 및 관리에 대한 사용자 경험을 개선하여 GitOps를 통해 일상적인 작업을 더 쉽게 처리하고 워크플로우를 자동화하는 것을 목표로 합니다. 이 도구를 실험해 보려면, [[Cluster API Operator 빠른시작|CAPI Operator 빠른시작]]을 보세요.
===공통 전제조건===
===공통 전제조건===
* 로컬 환경에 [[kubectl 설치]] 및 셋업
* 로컬 환경에 [[kubectl 설치]] 및 셋업

2024년 5월 2일 (목) 14:16 판

1 개요

Quick Start
퀵스타트

이 튜토리얼에서는 Cluster API를 사용하여 하나 이상의 Kubernetes 클러스터를 생성하는 방법에 대한 기본사항을 다룹니다.

경고

아직 v1beta1 또는 v1alpha4를 지원하지 않는 제공자를 사용하는 경우, 대신 릴리스 0.3 또는 릴리스 0.4 퀵스타트 지침을 따르세요.

2 설치

두 가지 주요 빠른시작 경로가 있습니다. clusterctl 또는 Cluster API Operator를 사용하는 것입니다.

이 글에서는 clusterctl CLI 도구를 사용하여 클러스터 API 관리 클러스터의 수명주기를 처리하는 경로를 설명합니다.

clusterctl 명령줄 인터페이스는 간단한 "1일차 경험"과 Cluster API를 통한 빠른 시작을 제공하기 위해 특별히 설계되었습니다. 제공자 구성요소를 정의하는 YAML 파일을 가져오고 설치하는 작업을 자동화합니다.

추가적으로 사용자가 잘못 설정하는 것을 방지하거나 업그레이드와 같은 2일차 작업을 관리하는 데 도움이 되는 제공자 관리에 대한 일련의 모범사례를 나타냅니다.

Cluster API Operator는 clusterctl을 기반으로 구축된 Kubernetes Operator이며 클러스터 관리자가 선언적 접근방식을 사용하여 관리 클러스터 내에서 Cluster API 제공자의 수명주기를 처리할 수 있도록 설계되었습니다. Cluster API 배포 및 관리에 대한 사용자 경험을 개선하여 GitOps를 통해 일상적인 작업을 더 쉽게 처리하고 워크플로우를 자동화하는 것을 목표로 합니다. 이 도구를 실험해 보려면, CAPI Operator 빠른시작을 보세요.

2.1 공통 전제조건

2.2 설치 및 Kubernetes 클러스터 설정

2.2.1 Kind 클러스터 생성

2.2.2 Calico CNI 설치

2.3 clusterctl 설치

2.4 관리 클러스터 초기화

2.4.1 기능 게이트 활성화하기

2.4.2 공통 제공자를 위한 초기화

2.5 첫번째 워크로드 클러스터 생성

2.5.1 워크로드 클러스터 설정 준비하기

2.5.2 공통 제공자를 위한 필수 설정

2.5.3 클러스터 설정 생성

2.5.4 워크로드 클러스터 apply

2.5.5 워크로드 클러스터 접근하기

2.6 클라우드 제공자 설치

Kubernetes 트리 내 클라우드 제공자 구현은 외부 클라우드 제공자를 위해 제거됩니다("트리 외부"라고도 함). 이를 위해서는 이전에 kube-controller-manager에서 구동되었던 모든 클라우드 관련 컨트롤러를 실행하는 역할을 담당하는 cloud-controller-manager라는 새로운 구성요소를 배포해야 합니다. 자세한 내용은 이 블로그 게시물을 참조하세요.

Azure

워크로드 클러스터에 공식 cloud-provider-azure 헬름 차트를 설치합니다.

helm install --kubeconfig=./capi-quickstart.kubeconfig --repo https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo cloud-provider-azure --generate-name --set infra.clusterName=capi-quickstart --set cloudControllerManager.clusterCIDR="192.168.0.0/16"

자세한 내용은 CAPZ 책을 참조하세요.

OpenStack

OpenStack 외부 클라우드 제공자를 배포하기 전에, OpenStack 환경과의 통합을 위해 cloud.conf 파일을 설정하십시오.

cat > cloud.conf <<EOF
[Global]
auth-url=<your_auth_url>
application-credential-id=<your_credential_id>
application-credential-secret=<your_credential_secret>
region=<your_region>
domain-name=<your_domain_name>
EOF

cloud.conf 파일 설성에 대한 자세한 내용은, OpenStack Cloud Controller Manager 문서를 참조하세요.

다음으로, 이 설정을 사용하여 Kubernetes Secret을 생성하여 클라우드 환경 세부정보를 안전하게 저장하세요. 예를 들어 다음을 사용하여 이 Secret을 만들 수 있습니다.

kubectl -n kube-system create secret generic cloud-config --from-file=cloud.conf

이제, 외부 클라우드 제공자를 배포할 준비가 되었습니다!

kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-openstack/master/manifests/controller-manager/cloud-controller-manager-roles.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-openstack/master/manifests/controller-manager/cloud-controller-manager-role-bindings.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-openstack/master/manifests/controller-manager/openstack-cloud-controller-manager-ds.yaml

다른 방법으로는, 헬름 차트를 참조하세요.

2.7 CNI 솔루션 배포

여기서는 Calico를 예시로 사용했습니다.

Azure

워크로드 클러스터에 공식 Calico Helm 차트를 설치합니다.

helm repo add projectcalico https://docs.tigera.io/calico/charts --kubeconfig=./capi-quickstart.kubeconfig && \
helm install calico projectcalico/tigera-operator --kubeconfig=./capi-quickstart.kubeconfig -f https://raw.githubusercontent.com/kubernetes-sigs/cluster-api-provider-azure/main/templates/addons/calico/values.yaml --namespace tigera-operator --create-namespace

잠시 후, 노드가 구동되고 준비 상태에 있어야 합니다. kubectl get node를 사용하여 상태를 확인합니다.

kubectl --kubeconfig=./capi-quickstart.kubeconfig get nodes
vcluster
KubeVirt
다른 제공자...

2.8 클린업

워크로드 클러스터 삭제.

kubectl delete cluster capi-quickstart

중요: 인프라를 적절하게 클린업하려면 항상 클러스터 객체를 삭제해야 합니다. 전체 클러스터 템플릿을 kubectl delete -f capi-quickstart.yaml으로 삭제하면 보류 중(pending)인 리소스가 수동으로 클린업될 수 있습니다.

관리 클러스터 삭제

kind delete cluster

3 다음 단계

  • 두 번째 워크로드 클러스터를 만듭니다. 위에 설명된 단계를 따르세요. 단, 두 번째 워크로드 클러스터에는 다른 이름을 제공해야 합니다.
  • 워크로드 클러스터에 애플리케이션을 배포합니다. 포인터에 대해 CNI 배포 단계를 사용하세요 .
  • clusterctl 지원 작업에 대한 자세한 내용은 clusterctl 설명서를 참조하세요 .

4 참고

문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}