サポートを受ける

Google の主要なサポート目標は、本番環境でのインシデントをできるだけ迅速に解決することです。お客様の構成を把握し、ログと指標を分析して、パートナーと協力することにより、インシデントを迅速に解決します。

Google Cloud は、さまざまなサポート パッケージを備えており、お客様のサポートニーズにお応えします。すべての Google Cloud サポート パッケージには、Google Kubernetes Engine（GKE）Enterprise エディションと Google Distributed Cloud のサポートが含まれています。既存の Google Cloud サポート パッケージをご利用の場合は、GKE Enterprise と Google Distributed Cloud のサポートがすでに含まれています。

詳細については、Google Cloud サポートのドキュメントをご覧ください。

Google Distributed Cloud サポートの要件

ビジネス クリティカルなインシデントを効果的にトラブルシューティングするには:

• ご利用の環境が現行バージョンで、公開されているサポート期間内であることを確認します。詳細については、バージョン サポート ポリシーをご覧ください。
• システム コンポーネントに対する Cloud Logging と Cloud Monitoring を有効にします。詳しくは、次のサポートツール セクションをご覧ください。

サポートツール

Google Distributed Cloud インシデントのトラブルシューティングでは、Google Cloud サポートで、次の 3 つの情報を使用します。

• 環境の構成
• クラスタからのログ
• クラスタからの指標

環境の構成

サポートケースを登録するにあたり、次のコマンドを実行するとクラスタの設定に関する重要な情報を取得できます。

• すべてのクラスタタイプで、bmctl check cluster --snapshot コマンドを実行して Kubernetes とノードに関する情報を取得します。作成された tar ファイルをサポートケースに添付してください。

• 管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタの場合は、bmctl check cluster コマンドを実行してクラスタとノードのステータスを確認します。生成されたログをサポートケースに添付してください。ログは bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP] ディレクトリの下にあります。

• ユーザー クラスタの場合は、まずクラスタ名と Namespace を含むヘルスチェック YAML ファイルを作成し、次に適切な管理クラスタにファイルを適用します。

  1. 次の healthcheck プロパティが記述された YAML ファイルを作成します。cluster-user1 Namespace の user1 という名前のクラスタに対する記述例を、次に示します。

     apiVersion: baremetal.cluster.gke.io/v1
     kind: HealthCheck
     metadata:
       generateName: healthcheck-
       namespace: cluster-user1
     spec:
       clusterName: user1
     

  2. YAML ファイルを作成したら、kubectl コマンドを使用して、ユーザー クラスタを管理する管理クラスタにその YAML ファイルを適用します。前の手順で作成した YAML ファイルを使用したコマンドの例を次に示します。この例では、ADMIN_KUBECONFIG 変数は管理クラスタの kubeconfig ファイルのパスを指定します。

     kubectl --kubeconfig ADMIN_KUBECONFIG create -f healthcheck-user1.yaml
     

     このコマンドは、次のレスポンスを返します。

     healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf created
     

  3. ヘルスチェック ジョブの調整が終了したかどうかを確認するテストを実施し、ヘルスチェック ジョブが完了するのを待ちます。前述の例では、ヘルスチェック ジョブの名前は 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
     

     完了すると、このコマンドは次の情報を返します。

     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
     

  4. kubectl コマンドを使用して、ヘルスチェック ジョブの Pod のログをすべてローカル ファイルに収集します。前述のサンプル ヘルスチェック ジョブを使用した例を次に示します。

     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 プロジェクトにシステムレベルのログが複製されます。システムレベルのログは、次の Namespace にある Kubernetes Pod から取得されます。

• kube-system
• gke-system
• gke-connect
• istio-system
• config-management-system
• gatekeeper-system
• cnrm-system
• knative-serving

ログに対するクエリは、Cloud Logging コンソールから実行できます。

注: Cloud Logging が無効になっている場合、サポートはベスト エフォート ベースでのみ提供され、現場のエンジニアリング チームにかなりの追加作業が必要になることがあります。

詳細については、Logging と Monitoring をご覧ください。

Google Cloud CLI とリモートでのクラスタ アクセス

サポートケースを開くと、Cloud カスタマーケアから、問題をより効果的に診断して解決するために、クラスタへのリモートによる読み取り専用アクセス権が求められることがあります。サポートチームがクラスタの問題をリモートでトラブルシューティングするのに十分なアクセス権を得るには、Google Cloud CLI の最新バージョンがインストールされていることを確認してください。Cloud カスタマーケアに必要な権限を付与するには、Google Cloud CLI がバージョン 401.0.0 以上である必要があります。Google Cloud CLI を定期的に更新して、追加された権限やその他の機能強化を利用できるようにしておくことをおすすめします。

gcloud CLI の最新コンポーネントをインストールするには、gcloud components update コマンドを使用します。クラスタへのリモート読み取り専用アクセスを Cloud カスタマーケアに付与する方法については、登録済みクラスタの Google Cloud サポートをご覧ください。

クラスタ指標

ログに加えて、Cloud Monitoring エージェントは指標もキャプチャします。これにより、クラスタに関連付けられた Google Cloud プロジェクトにシステムレベルの指標が複製されます。システムレベルの指標は、ログに記載されているものと同じ Namespace で実行されている Kubernetes Pod から取得されます。

注: Cloud Monitoring が無効になっている場合、サポートはベスト エフォート ベースでのみ提供され、現場のエンジニアリング チームにかなりの追加作業が必要になることがあります。

詳細については、Logging と Monitoring をご覧ください。

環境のトラブルシューティング方法

一般的なサポート インシデントの例を次に示します。

1. クラスタ管理者が Google Cloud コンソールまたは Google Cloud サポート センターでサポートケースを開き、Google Kubernetes Engine（GKE）Enterprise エディションと Google Distributed Cloud をそれぞれカテゴリとコンポーネントとして選択します。必要な情報を入力し、関連する bmctl コマンドの出力をケースに添付します。

2. サポートケースは、Google Distributed Cloud を専門とするテクニカル サポート エンジニアに転送されます。

3. サポート エンジニアはスナップショットの内容を調べ、環境のコンテキストを取得します。

4. サポート エンジニアは、Google Cloud プロジェクトのログと指標を調べて、業務上の正当な理由としてサポートケース ID を入力します。これは、内部でログに記録されます。

5. サポート エンジニアは、ケースに評価と推奨事項を返信します。サポート エンジニアとユーザーは、解決するまでトラブルシューティングを続けます。

Google のサポート範囲

通常、Cloud サポートチームは、Google Distributed Cloud および Cloud Service Mesh の一部としてリリースされるすべてのソフトウェア コンポーネント、Policy Controller、Config Sync、Config Controller をサポートしています。次の表に、サポートされている機能とサポートされていない機能の詳細なリストを示します。

Google Cloud のサポート対象	サポート対象外
Kubernetes とコンテナ ランタイム	お客様が選択したロードバランサ（手動負荷分散）
Connect と Connect Agent	お客様コード（デベロッパー サポートを参照）
Google Cloud Operations、Monitoring、Logging、エージェント	お客様が選択したオペレーティング システム
バンドルされたロードバランサ	物理サーバー、仮想サーバー、ストレージ、ネットワーク
Ingress コントローラ	外部の DNS、DHCP、ID システム
GKE Identity Service
Cloud Service Mesh
Policy Controller
Config Sync
Config Controller

バージョンのサポート ポリシー

Google Distributed Cloud のサポートは、GKE Enterprise サポート ポリシーに従って提供されます。Google は、以下のいずれか長いほうの期間にわたって、Google Distributed Cloud の各マイナー バージョンをサポートします。

• マイナー バージョンの最初のリリースから 12 か月間。
• 3 番目のマイナー バージョンのリリース。

GKE Enterprise の最新のマイナー リリース日と、最も早いサポート終了日については、GKE Enterprise のサポート期間をご覧ください。

サポートされている Google Distributed Cloud バージョンとサポートされていないバージョンのリストについては、バージョニングをご覧ください。

クラスタのアップグレードに関連するバージョン情報については、アップグレードのバージョン ルールをご覧ください。

共有責任モデル

Google Distributed Cloud でビジネス クリティカルな本番環境アプリケーションを実行するには、複数の当事者がそれぞれの責任を果たす必要があります。完全なリストではありませんが、以下のセクションで一部の役割と責任について説明します。

Google の責任

• Google Distributed Cloud ソフトウェア パッケージのメンテナンスと配布。
• Google Distributed Cloud の利用可能なアップグレードについてユーザーに通知し、以前のバージョンのアップグレード スクリプトを作成します。Google Distributed Cloud は、順次アップグレードのみをサポートします（例: 1.2 → 1.3 → 1.4 がサポートされ、1.2 → 1.4 はサポートされません）。
• Connect サービスと Cloud Operations サービスの運用
• Google 提供のコンポーネントに関連するトラブルシューティング、回避策の提供、問題の根本原因の修正。

ユーザーの責任

• オンプレミス クラスタの全体的なシステム管理。
• クラスタにデプロイされたアプリケーション ワークロードのメンテナンス。
• データセンター インフラストラクチャ（ネットワーク、サーバー、オペレーティング システム、ストレージ、Google Cloud への接続など）の実行、保守、パッチ適用。
• 手動のロードバランサ オプションが採用されている場合、ネットワーク ロードバランサの実行、保守、パッチ適用。
• Google Distributed Cloud のバージョンを定期的にアップグレードします。
• クラスタとアプリケーションのモニタリング、およびインシデントへの対応。
• Cloud Operations エージェントのクラスタへの確実なデプロイ。
• トラブルシューティング目的での、Google への環境の詳細の提供。

デベロッパー サポート

Google は、デベロッパーのアプリケーション ワークロードに特化したサポートは提供していません。ただし、デベロッパーが Google Distributed Cloud でアプリケーションを簡単に実行できるように、ベスト エフォート型のデベロッパー サポートを提供しています。開発の段階での早期の取り組みにより、後のデプロイの段階での重大なインシデントを防ぐことができると Google は考えています。

このベスト エフォートのデベロッパー サポートは、有料サポート パッケージをご利用のすべてのお客様に提供されます。また、リリースに支障が生じる問題を優先度 P3、一般的な問い合わせを優先度 P4 として取り扱います。この分類では、優先度 0 が最高の優先度です。