1.3 Cluster API 구성 요소 업그레이드

업그레이드 시기

일반적으로 버그 수정, 새로운 기능 및 향상된 기능을 사용하려면 최신 버전의 Cluster API로 업그레이드하는 것이 좋다.

고려 사항

다른 API 버전 간에 이동하는 경우 완료해야 하는 추가 작업이 있을 수 있다. v1alpha2와 v1alpha3 간에 이동하는 지침은 아래를 참조한다.

Cluster API 버전이 관리 클러스터의 Kubernetes 버전과 호환되는지 확인한다.

0.3.x의 최신 버전으로 업그레이드

Clusterctl을 사용하여 Cluster API 0.3.x 버전 간에 업그레이드하는 것이 좋다.

Cluster API v1alpha2(0.2.x)에서 Cluster API v1alpha3(0.3.x)로 업그레이드

clusterctl init 명령을 사용하여 기존 관리 클러스터를 v1alpha2에서 v1alpha3으로 업그레이드한다.

v1alpha2에서 v1alpha3으로의 변경에 대한 자세한 내용은 v1alpha3과 비교한 클러스터 API v1alpha2 섹션을 참조한다.

전제조건

v1alpha2 구성 요소가 설치된 관리 클러스터에서 clusterctl init을 실행하려면 몇 가지 예비 단계가 필요하다.

cabpk-system 네임스페이스 삭제

cabpk-system 네임스페이스 삭제 실행:

kubectl delete namespace cabpk-system

핵심 및 인프라 제공자 controller-manager 배포 삭제

capi-system 네임스페이스에서 capi-controller-manager 배포를 삭제한다.

kubectl delete deployment capi-controller-manager -n capi-system

인프라 공급자에 따라 controller-manager 배포를 삭제합니다.

예를 들어 AWS 제공자를 사용하는 경우 capa-system 네임스페이스에서 capa-controller-manager 배포를 삭제한다.

kubectl delete deployment capa-controller-manager -n capa-system

옵션: 인프라 제공자 CRD 규격에 대해 perserveUnknownFields가 ‘false’로 설정되어 있는지 확인

변환 웹 후크를 사용하는 모든 인프라 제공자가 v1alpha2에서 v1alpha3으로 업그레이드할 수 있는 경우가 이에 해당해야 한다.

이는 모든 인프라 공급업체 CRD를 위한 kubectl get crd <crd name>.infrastructure.cluster.x-k8s.io -o yaml를 실행하여 확인할 수 있습니다.

clusterctl을 사용하여 Cluster API 구성 요소 업그레이드

관련 인프라 플래그를 사용하여 clusterctl init을 실행한다. AWS 공급자의 경우 다음을 실행한다.

clusterctl init --infrastructure aws

KubeadmControlPlane 관리에 기존 시스템 채택

클러스터에 cluster.x-k8s.io/control-plane,라는 레이블이 지정된 기존 시스템이 있는 경우 새 KubeadmControlPlane 개체를 생성하고 관련 클러스터 개체의 controlPlaneRef를 다음과 같이 업데이트하여 해당 시스템의 관리를 선택할 수 있다.

---
apiVersion: "cluster.x-k8s.io/v1alpha3"
kind: Cluster
...
spec:
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1alpha3
    kind: KubeadmControlPlane
    name: controlplane
    namespace: default
...

주의 사항:

• KCP 컨트롤러는 kubeadm 부트스트래퍼로 부트스트랩되지 않은 콘트롤 플레인의 채택을 거부한다.
• KCP 컨트롤러가 최신 버전이 아닌 경우 채택 후 시스템 업그레이드를 즉시 시작할 수 있다.
• KCP 컨트롤러는 기존 시스템을 채택할 때 지능적으로 동작하려고 시도하지만, 부트스트래핑 프로세스가 시스템의 KubeadmConfig에 다양한 필드를 설정하기 때문에 원래 사용자가 제공한 KubeadmConfig가 해당 시스템에 사용되었을 것이라는 것을 항상 알 수는 없다. 컨트롤러는 불필요하게 기계를 교체하지 않기 위해 이러한 의도를 추측하려고 하므로 잘못 추측하면 KCP 컨트롤러가 현재 구성으로 “업그레이드”되는 결과를 초래한다.
• 클러스터의 PKI 자료가 초기 KubeadmConfig 조정에 의해 생성되었다면 해당 기계에 바인딩된 KubeadmConfig에 의해 소유될 것이다. 채택 프로세스는 이러한 리소스를 KCP에 다시 결합하므로 업그레이드 중에 손실되지 않는다. 하지만 KCP 사후 채택을 삭제하면 해당 자료가 폐기된다.
• 클러스터 구성은 워크로드 클러스터 구성 맵과 부분적으로만 조정되며 kubeadm은 구성 맵을 권한 있는 것으로 간주한다. 조정된 필드는 다음과 같습니다.
  • kubeadmConfigSpec.clusterConfiguration.etcd.local.imageRepository
  • kubeadmConfigSpec.clusterConfiguration.etcd.local.imageTag
  • kubeadmConfigSpec.clusterConfiguration.dns.imageRepository
  • kubeadmConfigSpec.clusterConfiguration.dns.imageTag
  • 자세한 정보는 issue 2083에서 찾을 수 있다.