Google의 기본 지원 목표는 프로덕션 이슈를 최대한 빨리 해결하는 것입니다. 구성을 파악하고 로그와 측정항목을 분석하고 파트너와 협력하여 이슈를 신속하게 해결할 수 있습니다.
Cloud Customer Care는 지원 요구사항을 충족하기 위해 다양한 서포트 패키지를 제공합니다. 모든 Cloud Customer Care 패키지에는 GKE 및 Google Distributed Cloud 지원이 포함됩니다. 기존 Cloud Customer Care 서포트 패키지가 있다면 이미 GKE 및 Google Distributed Cloud 지원이 있는 것입니다.
자세한 내용은 Cloud Customer Care 허브를 참고하세요.
Google Distributed Cloud 지원 요구사항
비즈니스와 관련해 중요도가 높은 이슈를 효과적으로 해결하려면 다음을 수행해야 합니다.
- 환경이 최신 상태이며 게시된 지원 종료 기간 내에 있는지 확인합니다. 자세한 내용은 버전 지원 정책 섹션을 참고하세요.
- 시스템 구성요소에 Cloud Logging 및 Cloud Monitoring을 사용 설정합니다. 자세한 내용은 다음 지원 도구 섹션을 참고하세요.
지원 도구
Google Distributed Cloud 이슈를 문제 해결하기 위해 Cloud Customer Care는 다음 세 가지 정보를 사용합니다.
환경 구성
지원 케이스를 열 때 다음 명령어를 실행하여 클러스터 설정에 관한 주요 정보를 제공하세요.
모든 클러스터 유형에 대해
bmctl check cluster --snapshot
명령어를 실행하여 Kubernetes 및 노드에 대한 정보를 캡처합니다. 결과로 생성된 tar 파일을 지원 케이스에 연결합니다.관리자, 하이브리드, 독립형 클러스터의 경우
bmctl check cluster
명령어를 실행하여 클러스터와 노드의 상태를 확인합니다. 결과로 생성된 로그를 지원 케이스에 연결합니다. 로그가bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP]
디렉터리에 있어야 합니다.사용자 클러스터의 경우 먼저 클러스터 이름과 네임스페이스로 상태 점검 YAML 파일을 만든 후 파일을 적절한 관리자 클러스터에 적용합니다.
다음
healthcheck
속성을 사용하여 YAML 파일을 만듭니다. 다음은cluster-user1
네임스페이스에 있는user1
이라는 클러스터의 샘플 콘텐츠입니다.apiVersion: baremetal.cluster.gke.io/v1 kind: HealthCheck metadata: generateName: healthcheck- namespace: cluster-user1 spec: clusterName: user1
YAML 파일을 만든 후
kubectl
명령어를 사용하여 사용자 클러스터를 관리하는 관리자 클러스터에 커스텀 리소스를 적용합니다. 다음은 이전 단계에서 만든 YAML 파일을 사용하는 샘플 명령어입니다. 샘플에서ADMIN_KUBECONFIG
변수는 관리자 클러스터의 kubeconfig 파일 경로를 지정합니다.kubectl --kubeconfig ADMIN_KUBECONFIG create -f healthcheck-user1.yaml
이 명령어는 다음 응답을 반환합니다.
healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf created
상태 점검 작업이 완료될 때까지 기다립니다. 이렇게 하려면 상태 점검 작업이 조정되었는지 테스트합니다. 앞의 예시에서 상태 점검 작업 이름은
healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf
입니다. 다음은kubectl
명령어를 사용하는 샘플 테스트로, 상태 점검 작업이 완료될 때까지 30분 동안 기다립니다.kubectl --kubeconfig ADMIN_KUBECONFIG wait healthcheck healthcheck-7c4qf \ -n cluster-user1 --for=condition=Reconciling=False --timeout=30m
상태 점검 작업이 완료되면 위의
kubectl
명령어가 다음을 반환합니다.healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf condition met
상태 점검 작업 결과는 다음 명령어를 사용하여 확인할 수 있습니다.
kubectl --kubeconfig ADMIN_KUBECONFIG get healthcheck healthcheck-7c4qf \ -n cluster-user1
이 명령어는 다음과 같은 결과를 반환합니다.
NAME PASS AGE healthcheck-7c4qf true 17m
kubectl
명령어를 사용하여 상태 점검 작업 포드의 모든 로그를 로컬 파일로 수집합니다. 다음은 이전 샘플 상태 점검 작업을 사용하는 예시입니다.kubectl --kubeconfig ADMIN_KUBECONFIG logs -n cluster-user1 \ -l baremetal.cluster.gke.io/check-name=healthcheck-7c4qf --tail=-1 > \ healthcheck-7c4qf.log
클러스터 로그
새 Google Distributed Cloud 클러스터를 만들면 Cloud Logging 에이전트가 자동으로 사용 설정되고 시스템 수준의 구성요소만으로 범위가 지정됩니다. 그러면 클러스터와 연결된 Google Cloud 프로젝트에 시스템 수준 로그가 복제됩니다. 시스템 수준 로그는 다음 네임스페이스의 Kubernetes 포드에서 가져옵니다.
kube-system
gke-system
gke-connect
istio-system
config-management-system
gatekeeper-system
cnrm-system
knative-serving
로그 탐색기에서 로그를 쿼리할 수 있습니다.
자세한 내용은 로깅 및 모니터링 구성을 참고하세요.
Google Cloud CLI 및 원격 클러스터 액세스
지원 케이스를 접수하면 Cloud Customer Care에서 보다 효과적으로 문제를 진단하고 해결하기 위해 클러스터에 대한 원격 읽기 전용 액세스를 요청할 수 있습니다. Cloud 고객 지원팀이 클러스터 문제를 원격으로 해결할 수 있는 충분한 액세스 권한을 보유하려면 최신 버전의 Google Cloud CLI를 설치하고 업데이트해야 합니다. Cloud Customer Care에 필요한 권한을 부여하려면 Google Cloud CLI 버전이 401.0.0 이상이어야 합니다. Google Cloud CLI를 정기적으로 업데이트하여 추가된 권한 및 기타 개선사항이 적용되도록 하는 것이 좋습니다.
gcloud CLI의 최신 구성요소를 설치하려면 gcloud components update
명령어를 사용합니다.
Cloud Customer Care에 클러스터 원격 읽기 전용 액세스 권한을 부여하는 방법에 대한 자세한 내용은 원격 GKE 클러스터 지원을 참고하세요.
클러스터 측정항목
Cloud Monitoring 에이전트는 로그 외에도 측정항목을 캡처합니다. 그러면 클러스터와 연결된 Google Cloud 프로젝트에 시스템 수준 측정항목이 복제됩니다. 시스템 수준 측정항목은 클러스터 로그 섹션에 나열된 동일한 네임스페이스에서 실행되는 Kubernetes 포드에서 가져옵니다.
자세한 내용은 로깅 및 모니터링 구성을 참고하세요.
환경 문제 해결 방법
다음은 일반적인 지원 이슈의 예시입니다.
클러스터 관리자가 Google Cloud 콘솔에서 Cloud Customer Care와 함께 지원 케이스를 엽니다. 그런 다음 GKE와 Google Distributed Cloud를 각각 카테고리와 구성요소로 선택합니다. 필요한 정보를 입력하고 관련
bmctl
명령어의 출력을 케이스에 첨부합니다.지원 케이스는 Google Distributed Cloud 전문 기술 지원 엔지니어에게 전달됩니다.
지원 엔지니어가 스냅샷의 콘텐츠를 검사하여 환경 컨텍스트를 얻습니다.
지원 엔지니어가 Google Cloud프로젝트의 로그와 측정항목을 검토합니다. 내부적으로 로깅되는 비즈니스 근거로 지원 케이스 ID를 입력합니다.
지원 엔지니어는 지원 기록에 평가 및 권장사항을 작성합니다. 지원 엔지니어와 사용자가 해결 방법을 찾을 때까지 문제를 계속 해결합니다.
Google 지원의 역할은 무엇인가요?
일반적으로 Cloud Customer Care는 Google Distributed Cloud와 Cloud Service Mesh, 정책 컨트롤러, 구성 동기화, 구성 컨트롤러의 일부로 제공되는 모든 소프트웨어 구성요소를 지원합니다. 지원되는 항목과 지원되지 않는 항목의 전체 목록은 아래 표를 참고하세요.
Google Cloud 지원됨 | 지원되지 않음 |
---|---|
Kubernetes 및 컨테이너 런타임 | 고객의 부하 분산기 선택(수동 부하 분산) |
Connect 및 Connect Agent | 고객 코드(개발자 지원 참조) |
Google Cloud 작업, 모니터링, 로깅, 에이전트 | 고객이 선택한 운영체제 |
번들 부하 분산기 | 물리적 또는 가상 서버, 스토리지, 네트워크 |
인그레스 컨트롤러 | 외부 DNS, DHCP, ID 시스템 |
GKE ID 서비스 | |
Cloud Service Mesh | |
정책 컨트롤러 | |
구성 동기화 | |
구성 컨트롤러 |
버전 지원 정책
이 버전 지원 정책의 목표는 비즈니스 요구사항에 맞게 업그레이드 일정을 예약할 수 있는 유연성을 제공하는 동시에 급속하게 발전하고 있는 Kubernetes 및 Google Distributed Cloud의 균형을 맞추는 것입니다.
Google Distributed Cloud 소프트웨어 전용은 Kubernetes 버전 관리 체계 및 출시 주기를 따릅니다. 부 버전은 연간 약 3회 출시됩니다. 지원되는 각 부 버전의 패치는 대략 매월 제공됩니다. Kubernetes와 마찬가지로 Google Distributed Cloud는 최신 부 버전 3개를 동시에 지원합니다.
Google은 나중에 사용할 수 있도록 다음의 각 경우에 Google Distributed Cloud 부 버전을 지원합니다.
- 부 버전의 최초 출시 후 12개월
- 세 번째 후속 부 버전 출시
예를 들어 2025년 9월 2일에 출시된 부 버전 1.33 이 부 버전과 모든 패치는 2026년 9월 2일 또는 부 버전 1.36 출시일 중 늦은 날짜까지 지원됩니다.
제품의 최신 부 출시 버전과 권장 패치 버전을 사용하여 Google Distributed Cloud 환경을 유지하는 것이 좋습니다.
이 버전 지원 정책에는 다음이 포함됩니다.
- Cloud Customer Care의 장애에 대한 지원
- Kubernetes 및 관련 구성요소의 CVE 보안 취약점
- Kubernetes 및 관련 구성요소에 대한 일반 패치
버전이 지원 종료되면 다음 지원을 받기 위해 케이스를 계속 열 수 있습니다.
- 기술 문제 관련 도움말
- 결제 문제 관련 지원
- 문제 해결 및 테스트 지원을 비롯한 제품 사용에 관한 안내
연장 지원은 버전 고정 및 향후 업그레이드 일정 요구사항과 함께 일회성 이벤트로 조건부 승인될 수 있습니다. 자세한 내용은 계정의 리드 고객 엔지니어 또는 계정 관리자에게 문의하세요. 또는 Google Cloud 콘솔을 통해 지원 케이스를 제출할 수 있습니다. 이러한 요청은 계정의 고객 엔지니어링 그룹으로 라우팅됩니다.
지원 기간
다음 표에는 Google Distributed Cloud에서 지원되는 마이너 버전과 가장 빠른 지원 종료 (EOL) 날짜가 나와 있습니다.
Google Distributed Cloud 버전 | 출시일 | 지원 종료일* |
---|---|---|
1.33 | 2025-09-02 | 2026-09-02 또는 1.36 출시일 |
1.32 | 2025-05-06 | 2026-05-06 또는 1.35 출시일 |
1.31 | 2024-12-18 | 2025-12-18 또는 1.34 출시일 |
* 지원 종료(EOL)는 이 두 날짜 중 더 늦은 날짜입니다.
Google Distributed Cloud 및 관련Google Cloud 제품의 버전 호환성에 대해 자세히 알아보려면 버전 및 업그레이드 지원을 참고하세요.
버전 관리 체계
Google Distributed Cloud는 Kubernetes 시맨틱 버전 관리를 사용하여 지원되는 Kubernetes 버전을 참조하지만 GKE 패치 버전을 추가합니다. 이렇게 하면 다음 형식의 버전 번호가 생성됩니다. x.y.z-gke.N
- Kubernetes 주 버전(x)
- 일반적으로 이전 버전과 호환되지 않는 변경사항이 공개 API에 도입되면 주 버전의 숫자가 증가합니다. 주 버전은 Kubernetes 버전을
x.y
에서x+1.y
으로 증가시킵니다. - Kubernetes 부 버전(y)
- Kubernetes는 일 년에 세 번 새로운 부 버전을 출시합니다.
각 출시 주기는 약 15주입니다. 지원 중단된 API는 새 부 버전을 통해 삭제될 수 있습니다. 부 버전은 Kubernetes 버전을
1.y
에서1.y+1
로 증가시킵니다(예: Kubernetes 1). 29는 Kubernetes 1.28 이후의 부 버전입니다. - Google Distributed Cloud 패치 출시 버전(z-gke.N)
- 1.28.300-gke.131과 같은 패치 출시 버전은 패치 버전(z)을 100씩 증가시키고
-gke.N
서픽스를 포함하는데, 이는 빌드를 나타냅니다. 패치 출시에는 보안 업데이트와 버그 수정이 포함됩니다. Google Distributed Cloud 패치 출시 버전은 Kubernetes 패치 버전과 관련이 없습니다.
공유 책임 모델
Google Distributed Cloud에서 비즈니스에 중요한 프로덕션 애플리케이션을 실행하기 위해서는 여러 당사자가 각기 다른 책임을 수행해야 합니다. 전체 목록은 아니지만 다음 섹션에 다양한 당사자의 역할과 책임이 나와 있습니다.
Google의 책임
- Google Distributed Cloud 소프트웨어 패키지의 유지보수 및 배포
Google Distributed Cloud에 사용 가능한 업그레이드를 사용자에게 알리고 이전 버전의 업그레이드 스크립트를 생성합니다.
Google Distributed Cloud는 순차적 클러스터 업그레이드만 지원합니다 (예: 1.31 → 1.32 → 1.33만 가능하고 1.31 → 1.33은 불가능). 노드 풀을 업그레이드할 때 경우에 따라 부 버전을 건너뛸 수 있습니다. 업그레이드 로직에 관한 자세한 내용은 버전 규칙을 참고하세요.
Connect 및 Cloud 운영 서비스 운영
Google에서 제공하는 구성요소와 관련된 문제를 해결하고 해결 방법을 제공하며 문제의 근본 원인을 해결합니다.
사용자의 책임
- 온프레미스 클러스터의 전체 시스템 관리
- 클러스터에 배포된 모든 애플리케이션 워크로드 유지
- 네트워킹, 서버, 운영체제, 스토리지,Google Cloud연결 등 데이터 센터 인프라 실행, 유지, 패치
- 수동 부하 분산기 옵션을 선택한 경우 네트워크 부하 분산기 실행, 유지, 패치
- 정기적인 Google Distributed Cloud 버전 업그레이드
- 클러스터 및 애플리케이션을 모니터링하고 모든 이슈에 대응
- Cloud 운영 에이전트가 클러스터에 배포되었는지 확인
- 문제 해결을 위해 Google에 환경 세부정보 제공
개발자 지원
Google은 애플리케이션 워크로드에 대한 지원을 제공하지 않습니다. 하지만 Google에서는 개발자가 Google Distributed Cloud에서 애플리케이션을 실행할 수 있도록 최선을 다해 개발자를 지원하고 있습니다. Google은 개발 과정에서 초기에 참여할수록 배포 후반에 중요한 이슈를 방지할 수 있다고 믿고 있습니다.
이 최선의 개발자 지원은 모든 유료 서포트 패키지를 사용하는 고객에게 제공되며 출시를 막는 문제의 경우 P3 우선순위로, 일반적인 상담의 경우 P4 우선순위로 처리됩니다. 이 분류에서 우선순위 수준 0이 가장 높은 우선순위입니다.