Fleet을 사용하도록 VMware용 Knative serving을 마이그레이션하여 Anthos 버전 1.8로 업그레이드하는 방법을 알아봅니다.
Knative serving은 이제 관리되는 Cloud Run 제품과 별개의 환경이며, 클러스터의 Fleet 구성요소로 제공됩니다. VMware용 Knative serving 기능을 Fleet의 구성요소로 설치하면 다른 Fleet 구성요소와 독립적으로 설치를 관리하고 업그레이드할 수 있습니다.
개략적으로 VMware용 Knative serving 설치를 마이그레이션하여 Fleet을 사용하려면 다음을 수행해야 합니다.
- Fleet 요구사항을 충족하도록 VMware용 Knative serving 설치를 구성합니다.
- Fleet에서 Knative serving 기능 구성요소를 사용 설정합니다.
이 마이그레이션 중에는 Kubernetes API 서버가 영향을 받지 않습니다.
새 VMware용 Knative serving 새 설치를 수행하는 방법에 대한 자세한 내용은 VMware용 Knative serving 설치를 참조하세요.
시작하기 전에
다음 요구사항을 충족해야 합니다.
이러한 단계를 수행하려면 VMware용 Knative serving 클러스터가 GKE Enterprise에 등록되어 있어야 합니다.
클러스터 등록 방법 알아보기
VMware용 Knative serving 설치가 Anthos 버전 1.7 이하를 실행하는 클러스터에 있어야 합니다.
Istio는 더 이상 Anthos 1.8에서 지원되지 않습니다. Cloud Service Mesh 버전 1.18이 Fleet에 설치되어 있어야 하고 클러스터를 버전 1.8로 업그레이드하기 전 Knative serving 설치를 구성해야 합니다.
VMware용 GKE에 설치에 대한 자세한 내용은 Cloud Service Mesh 안내를 참조하세요.
Cloud Service Mesh를 사용하려면 클러스터에서
e2-standard-4와 같이 vCPU가 4개 이상 포함된 머신 유형이 사용되어야 합니다. 클러스터의 머신 유형을 변경하려면 다른 머신 유형으로 워크로드 마이그레이션을 참조하세요.Knative serving을 Cloud Service Mesh로 마이그레이션하는 옵션에는 두 가지가 있습니다. 다음 중 하나를 선택할 수 있습니다.
부하 분산기를 구성할 새로운 외부 IP 주소를 가져옵니다.
기존 부하 분산기 IP 주소를 다시 사용합니다.
Fleet로 마이그레이션
Anthos를 버전 1.8로 업그레이드하려면 먼저 다음 단계에 따라 기존 VMware용 Knative serving 설치가 Fleet 구성요소 사용으로 마이그레이션되도록 해야 합니다.
관리자 클러스터에 액세스
관리자 클러스터 kubeconfig 파일의 경로와 파일 이름을 가져온 후 ADMIN_KUBECONFIG 환경 변수를 만듭니다.
export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]
[ADMIN_CLUSTER_KUBECONFIG]를 관리자 클러스터의 kubeconfig 파일에 대한 경로 및 파일 이름으로 바꿉니다.
각 사용자 클러스터 구성
사용자 클러스터에 다음 로컬 환경 변수를 만듭니다.
사용자 클러스터의 kubeconfig 파일 경로로
USER_KUBECONFIG환경 변수를 만듭니다.export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG][USER_CLUSTER_KUBECONFIG]를 사용자 클러스터의 kubeconfig 파일에 대한 경로 및 파일 이름으로 바꿉니다.
다음 구성에 대한 환경 변수를 만듭니다.
- Google Cloud 프로젝트의 ID입니다.
- Google Cloud 리소스의 위치입니다.
- 사용자 클러스터의 이름입니다.
export PROJECT_ID=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-project-id']}") export CLUSTER_LOCATION=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-gcp-location']}") export CLUSTER_NAME=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-cluster-name']}")
사용자 클러스터의
OnPremUserCluster커스텀 리소스에서cloudrun구성을 삭제합니다.cloudRun이OnPremUserCluster에 설정되어 있는지 확인합니다.$ kubectl get onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --output=jsonpath="{.spec.cloudRun}"결과:
{"enabled":true}OnPremUserCluster에서cloudRun을 삭제합니다.kubectl patch onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --type="merge" \ --patch '{"spec": {"cloudRun": null}}'동일한
get명령어를 실행하고 구성이 반환되지 않는지 확인하여cloudRun이OnPremUserCluster에서 성공적으로 삭제되었는지 확인합니다.kubectl get onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --output=jsonpath="{.spec.cloudRun}"터미널에 출력이 없어야 합니다.
사용자 클러스터의 create-config 보안 비밀을 업데이트합니다.
create-config 파일의 로컬 YAML 복사본을 만듭니다.
kubectl get secret create-config \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace "${CLUSTER_NAME}" \ --output=jsonpath={.data.cfg} \ | base64 -d > "${CLUSTER_NAME}_create_secret.yaml"바로 전에 만든
${CLUSTER_NAME}_create_secret.yaml파일을 편집기에서 열고cloudrun필드를spec아래에서 삭제합니다.${CLUSTER_NAME}_cluster_create_secret.yaml파일을.b64파일로 Base64로 인코딩합니다.cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"편집기에서 방금 만든 로컬
.b64파일을 연 후 다음 단계에서 사용할data.cfg속성 아래에서 문자열을 복사합니다.cfg속성의 콘텐츠만 복사해야 합니다. 예를 들어 줄바꿈(\n)은 포함하지 않습니다.다음 명령어를 실행하여 사용자 클러스터에서 보안 비밀을 수정합니다.
kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace "${CLUSTER_NAME}"열린 편집기에서
data[cfg]필드를 로컬.b64파일에서 복사한 문자열로 바꾼 다음 변경사항을 저장합니다.변경사항이 사용자 클러스터에 배포되었고
cloudrun속성이create-config보안 비밀에서 성공적으로 삭제되었는지 확인합니다.kubectl get secret create-config \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace ${CLUSTER_NAME} \ --output=jsonpath={.data.cfg} \ | base64 -d
사용자 클러스터에
knative-serving네임스페이스를 만듭니다.knative-serving네임스페이스에서cloudrun-operator연산자를 삭제합니다.kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operatorknative-serving네임스페이스에서config-networkconfigmap을 패치합니다.kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'
VMware용 GKE 설치의 사용자 클러스터 구성 파일
user-config.yaml에서cloudrun.enabled구성을 삭제합니다.user-config.yaml파일 내에서 다음 속성을 삭제해야 합니다.cloudRun: enabled: trueAnthos 버전 1.8로 클러스터 업그레이드를 수행하면 이 구성 변경사항이 배포됩니다.
여러 사용자 클러스터가 있는 경우 각 사용자 클러스터에 대해 이 '각 사용자 클러스터 구성' 섹션의 모든 단계를 반복해야 합니다.
Fleet 구성요소 구성
Fleet에서 Knative serving 구성요소를 사용 설정합니다.
gcloud container fleet cloudrun enable --project=$PROJECT_ID자세한 내용과 추가 옵션은 gcloud container fleet cloudrun enable 참조를 확인하세요.
(선택사항) Knative serving 기능 구성요소가 사용 설정되어 있는지 확인합니다.
콘솔
Google Cloud 콘솔에서 Knative serving 구성요소가 사용 설정되어 있는지 확인합니다.
명령줄
appdevexperience상태가ENABLED인지 확인합니다.gcloud container fleet features list --project=$PROJECT_ID자세한 내용과 추가 옵션은 gcloud container fleet features list 참조를 확인하세요.
결과:
NAME STATE appdevexperience ENABLEDCloudRun커스텀 리소스를 배포하여 사용자 클러스터마다 VMware용 Knative serving을 설치합니다. 기본적으로 Knative serving의latest버전이 배포됩니다.다음
kubectl apply명령어를 실행하여CloudRun커스텀 리소스의 기본 구성을 배포합니다.cat <<EOF | kubectl apply -f - apiVersion: operator.run.cloud.google.com/v1alpha1 kind: CloudRun metadata: name: cloud-run spec: metricscollector: stackdriver: projectid: $PROJECT_ID gcpzone: $CLUSTER_LOCATION clustername: $CLUSTER_NAME secretname: "stackdriver-service-account-key" secretkey: "key.json" EOF
Cloud Service Mesh 구성
사용자 클러스터마다 Cloud Service Mesh 부하 분산기를 구성합니다.
새 외부 IP 주소를 구성하거나 기존 IP 주소를 다시 사용하여 Cloud Service Mesh의 인그레스 게이트웨이를 구성할 수 있습니다.
가져온 새 외부 IP 주소를 사용하여 Cloud Service Mesh 문서의 단계에 따라 부하 분산기를 구성합니다.
이 옵션을 사용하면 Knative serving 서비스가 중단 없이 다시 시작됩니다.
또는 다음 단계에 따라 Cloud Service Mesh 부하 분산기를 기존 IP 주소로 구성합니다.
다음 명령어를 실행하여 서비스의 게이트웨이를 Cloud Service Mesh로 구성합니다.
export CURRENT_INGRESS_IP=$(kubectl get service --namespace gke-system istio-ingress --output jsonpath='{.spec.loadBalancerIP}') kubectl patch service --namespace istio-system istio-ingressgateway --patch "{\"spec\":{\"loadBalancerIP\": \"$CURRENT_INGRESS_IP\"}}" kubectl patch service --namespace gke-system istio-ingress --patch "{\"spec\":{\"loadBalancerIP\": null}}"현재 Istio 구성 설정을 삭제합니다.
kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"local-gateway.cluster-local-gateway": null}}' kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"gateway.gke-system-gateway": null}}'
마이그레이션 확인
appdevexperience-operator가 실행 중인지 확인하여 VMware용 Knative serving이 Fleet으로 성공적으로 마이그레이션되었는지 확인할 수 있습니다.
각 사용자 클러스터에서 다음 명령어를 실행합니다.
kubectl get deployment -n appdevexperience appdevexperience-operator
appdevexperience-operator 연산자는 1/1을 준비됨으로 표시해야 합니다. 예를 들면 다음과 같습니다.
NAME READY UP-TO-DATE AVAILABLE AGE
appdevexperience-operator 1/1 1 1 1h
운영자가 준비 상태를 달성하지 못하면 Google Cloud 콘솔에서 클러스터 워크로드 페이지를 확인하여 리소스 문제를 식별할 수 있습니다.
Google Kubernetes Engine 워크로드로 이동
클러스터 업그레이드
이제 Fleet 구성요소를 사용하도록 VMware용 Knative serving 설치를 마이그레이션했으므로 클러스터를 Anthos 버전 1.8로 업그레이드할 수 있습니다. GKE On-Prem 업그레이드의 자세한 안내를 따르세요.
문제 해결
- 사용자 클러스터의 업그레이드 프로세스가 완료되지 못함
gke-system네임스페이스의cluster-local-gateway포드는 사용자 클러스터가 Anthos 버전 1.8로 업그레이드되지 못하게 할 수 있습니다.cluster-local-gateway포드는 더 이상 필요하지 않으므로 안전하게 삭제할 수 있습니다.업그레이드 프로세스를 수동으로 지원하려면 배포 복제본을
0으로 축소하여cluster-local-gatewaypod를 수동으로 삭제할 수 있습니다. 예를 들면 다음과 같습니다.cluster-local-gateway를 축소합니다.kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-systemgke-system네임스페이스의cluster-local-gateway포드와knative-serving네임스페이스의 모든 워크로드가 삭제됩니다.업그레이드가 완료될 때까지 기다립니다.