このドキュメントでは、gkectl diagnose
を使用してクラスタの問題を診断する方法について説明します。
概要
gkectl
ツールには、クラスタの問題を解決するために 2 つのコマンド(gkectl diagnose cluster
と gkectl diagnose snapshot
)が用意されています。これらのコマンドは、管理者クラスタとユーザー クラスタの両方で機能します。
gkectl diagnose cluster
クラスタでヘルスチェックを実行し、エラーを報告します。次のコンポーネントでヘルスチェックを実行します。
- VCenter
- 認証情報
- DRS
- アンチ アフィニティ グループ
- ネットワーク
- バージョン
- データセンター
- データストア
- リソースプール
- フォルダ
- ネットワーク
- ロードバランサ(F5、Seesaw、手動)
- ユーザー クラスタとノードプール
- クラスタ オブジェクト
- ユーザー クラスタの Konnectivity サーバーの準備状況
- マシン オブジェクトと対応するクラスタノード
- kube-system と gke-system の Namespace にある Pod
- コントロール プレーン
- クラスタ内の vSphere 永続ボリューム
- ユーザーおよび管理クラスタの vCPU(仮想 CPU)とメモリの競合シグナル
- ユーザーおよび管理クラスタの ESXi のホスト CPU 使用率とメモリ使用量の事前構成アラーム。
- 1 日のうちの時間(TOD)
- Dataplane V2 が有効になっているクラスタのノード ネットワーク ポリシー
- Dataplane V2 ノード エージェントの全体的な健全性
gkectl diagnose snapshot
このコマンドは、クラスタのステータス、構成、ログを tarball ファイルに圧縮します。gkectl diagnose snapshot
を実行すると、そのコマンドはプロセスの一環として gkectl diagnose cluster
を自動的に実行し、/diagnose-report
というスナップショット内の新しいフォルダに出力ファイルが配置されます。
この gkectl diagnose snapshot
コマンドのデフォルト構成では、クラスタに関する次の情報も取得されます。
Kubernetes のバージョン
kube-system と gke-system Namespace 内の Kubernetes リソースのステータス: クラスタ、マシン、ノード、Service、Endpoint、ConfigMap、ReplicaSet、CronJob、Pod とそのオーナー(Deployment、DaemonSet、StatefulSet を含む)
コントロール プレーンのステータス
各ノードの構成の詳細(IP アドレス、iptables ルール、マウント ポイント、ファイル システム、ネットワーク接続、実行中のプロセスなど)
管理クラスタのコントロール プレーン ノードからのコンテナログ(Kubernetes API が使用できない場合)
リソースプールに基づいた vSphere 情報(VM オブジェクトとそれらのイベントなど)。VM に関連付けられたデータセンター、クラスタ、ネットワーク、Datastore の各オブジェクトも含まれます。
仮想サーバー、仮想アドレス、プール、ノード、モニターなどの F5 BIG-IP ロードバランサ情報
gkectl diagnose snapshot
コマンドのログプリフライト ジョブのログ
シナリオに基づいた Namespace 内のコンテナのログ
スナップショット ファイル
/nodes/<admin_master_node_name>/sudo_kubeadm_certs_check-expiration
にある管理クラスタの Kubernetes 証明書の有効期限に関する情報スナップショット内のすべてのファイルの HTML インデックス ファイル
必要に応じて、
--config
フラグを指定してクラスタのインストールとアップグレードに使用する管理クラスタ構成ファイル。
認証情報(vSphere と F5 の認証情報など)は、tarball が作成される前に削除されます。
サポートが必要な場合
使用できるコマンドのヘルプを表示するには、次のコマンドを実行します。
gkectl diagnose --help
管理クラスタの診断
管理クラスタを診断するには、次のコマンドを実行します。
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
ADMIN_CLUSTER_KUBECONFIG は、管理クラスタ kubeconfig ファイルのパスに置き換えます。
出力の例:
Preparing for the diagnose tool... Diagnosing the cluster......DONE - Validation Category: Admin Cluster Connectivity Checking VMs TOD (availability)...SUCCESS Checking Konnectivity Server (readiness)...SUCCESS - Validation Category: Admin Cluster F5 BIG-IP Checking f5 (credentials, partition)...SUCCESS - Validation Category: Admin Cluster VCenter Checking Credentials...SUCCESS Checking DRS enabled...SUCCESS Checking Hosts for AntiAffinityGroups...SUCCESS Checking Version...SUCCESS Checking Datacenter...SUCCESS Checking Datastore...SUCCESS Checking Resource pool...SUCCESS Checking Folder...SUCCESS Checking Network...SUCCESS - Validation Category: Admin Cluster Checking cluster object...SUCCESS Checking machine deployment...SUCCESS Checking machineset...SUCCESS Checking machine objects...SUCCESS Checking kube-system pods...SUCCESS Checking anthos-identity-service pods...SUCCESS Checking storage...SUCCESS Checking resource...SUCCESS Checking virtual machine resource contention...SUCCESS Checking host resource contention...SUCCESS All validation results were SUCCESS. Cluster is healthy!
ターゲット クラスタの仮想 IP アドレス(VIP)に問題がある場合は、--config
フラグを使用して管理クラスタの構成ファイルを指定します。これにより、より詳細なデバッグ情報が得られます。
gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG
CLUSTER_CONFIG は、管理クラスタまたはユーザー クラスタの構成ファイルのパスに置き換えます。
出力例:
Failed to access the api server via LB VIP "...": ... Try to use the admin master IP instead of problematic VIP... Reading config with version "[CONFIG_VERSION]" Finding the admin master VM... Fetching the VMs in the resource pool "[RESOURCE_POOL_NAME]"... Found the "[ADMIN_MASTER_VM_NAME]" is the admin master VM. Diagnosing admin|user cluster "[TARGET_CLUSTER_NAME]"... ...
ユーザー クラスタの診断
ユーザー クラスタの名前を取得するには、次のコマンドを実行します。
kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG
USER_CLUSTER_KUBECONFIG は、ユーザー クラスタ kubeconfig ファイルのパスに置き換えます。
ユーザー クラスタを診断するには、次のコマンドを実行します。
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME
USER_CLUSTER_NAME を、ユーザー クラスタの名前に置き換えます。
出力例:
Preparing for the diagnose tool... Diagnosing the cluster......DONE Diagnose result is saved successfully in- Validation Category: User Cluster Connectivity Checking Node Network Policy...SUCCESS Checking VMs TOD (availability)...SUCCESS Checking Dataplane-V2...Success - Validation Category: User Cluster F5 BIG-IP Checking f5 (credentials, partition)...SUCCESS - Validation Category: User Cluster VCenter Checking Credentials...SUCCESS Checking DRS enabled...SUCCESS Checking Hosts for AntiAffinityGroups...SUCCESS Checking VSphere CSI Driver...SUCCESS Checking Version...SUCCESS Checking Datacenter...SUCCESS Checking Datastore...SUCCESS Checking Resource pool...SUCCESS Checking Folder...SUCCESS Checking Network...SUCCESS - Validation Category: User Cluster Checking user cluster and node pools...SUCCESS Checking cluster object...SUCCESS Checking machine deployment...SUCCESS Checking machineset...SUCCESS Checking machine objects...SUCCESS Checking control plane pods...SUCCESS Checking kube-system pods...SUCCESS Checking gke-system pods...SUCCESS Checking gke-connect pods...SUCCESS Checeking anthos-identity-service pods...SUCCESS Checking storage...SUCCESS Checking resource...SUCCESS Checking virtual machine resource contention...SUCCESS Checking host resource contention...SUCCESS All validation results were SUCCESS. Cluster is healthy!
原因が判明しているクラスタの問題のトラブルシューティング
gkectl diagnose cluster
の実行時に次のような問題が発生した場合の解決策を以下に示します。
事象 | 考えられる原因 | 解決策 |
---|---|---|
管理クラスタおよびユーザー クラスタのどちらからも Kubernetes API サーバーにアクセスできない。 | 仮想マシンの OOB(すぐに使用できる)メモリ レイテンシ グラフを確認します。理想的なメモリ レイテンシはゼロに近いことです。また、メモリの競合により、CPU の競合が発生する可能性もあります。さらに、CPU readiness グラフは、スワップの増加に伴って急増する場合があります。 | 物理メモリを増やします。その他のオプションについては、VMware のトラブルシューティング ヒントをご覧ください。 |
ノードプールの作成でタイムアウトが発生する。 | VMDK の読み取りと書き込みのレイテンシが高くなっています。仮想ディスクの読み取りと書き込みレイテンシの VM ヘルス OOB を確認します。VMware によると、レイテンシの合計が 20 ミリ秒を上回ると、問題が発生していることを意味します。 | ディスク パフォーマンスの問題が発生した場合の VMware の解決策をご覧ください。 |
クラスタの状態のキャプチャ
gkectl diagnose cluster
がエラーを見つけた場合、クラスタの状態をキャプチャし、Google に情報を提供する必要があります。そのためには、gkectl diagnose snapshot
コマンドを使用します。
gkectl diagnose snapshot
にはオプションのフラグ --config
があります。このフラグは、クラスタに関する情報の収集に加えて、クラスタの作成またはアップグレードに使用された GKE on VMware 構成ファイルを収集します。
管理クラスタの状態のキャプチャ
管理クラスタの状態をキャプチャするには、次のコマンドを実行します。ここで、--config
はオプションです。
gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] --config
出力には、ファイルの一覧と tarball ファイルの名前が含まれます。
Taking snapshot of admin cluster "[ADMIN_CLUSTER_NAME]"... Using default snapshot configuration... Setting up "[ADMIN_CLUSTER_NAME]" ssh key file...DONE Taking snapshots... commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system ... nodes/[ADMIN_CLUSTER_NODE]/commands/journalctl_-u_kubelet nodes/[ADMIN_CLUSTER_NODE]/files/var/log/startup.log ... Snapshot succeeded. Output saved in [TARBALL_FILE_NAME].tar.gz.tarball ファイルをディレクトリに抽出するには、次のコマンドを実行します。
tar -zxf TARBALL_FILE_NAME --directory EXTRACTION_DIRECTORY_NAME
スナップショットにより生成されたファイルのリストを表示するには、次のコマンドを実行します。
cd EXTRACTION_DIRECTORY_NAME/EXTRACTED_SNAPSHOT_DIRECTORY ls kubectlCommands ls nodes/NODE_NAME/commands ls nodes/NODE_NAME/files
特定の操作の詳細を確認するには、表示されたファイルのいずれかを開きます。
管理クラスタの SSH 認証鍵の指定
管理クラスタのスナップショットを取得すると、gkectl
は管理クラスタの秘密 SSH 認証鍵を自動的に検索します。--admin-ssh-key-path
パラメータを使用して、鍵を明示的に指定することもできます。
SSH を使用してクラスタノードに接続するの手順に沿って、SSH 認証鍵をダウンロードします。
次に、gkectl diagnose snapshot
コマンドで、--admin-ssh-key-path
をデコードされた鍵ファイルパスに設定します。
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --admin-ssh-key-path=PATH_TO_DECODED_KEY
ユーザー クラスタの状態のキャプチャ
ユーザー クラスタの状態をキャプチャするには、次のコマンドを実行します。
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME
出力には、ファイルの一覧と tarball ファイルの名前が含まれます。
Taking snapshot of user cluster "[USER_CLUSTER_NAME]"... Using default snapshot configuration... Setting up "[USER_CLUSTER_NAME]" ssh key file...DONE commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user ... commands/kubectl_get_pods_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system commands/kubectl_get_deployments_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system ... nodes/[USER_CLUSTER_NODE]/commands/journalctl_-u_kubelet nodes/[USER_CLUSTER_NODE]/files/var/log/startup.log ... Snapshot succeeded. Output saved in [FILENAME].tar.gz.
スナップショットのシナリオ
gkectl diagnose snapshot
コマンドは、ユーザー クラスタの 2 つのシナリオをサポートします。シナリオを指定するには、--scenario
フラグを使用します。使用できる値は、次のリストのとおりです。
システム(デフォルト): サポートされているシステム名前空間のログを含むスナップショットを収集します。
すべて: ユーザー定義の名前空間をはじめとするすべての名前空間のログを含むスナップショットを収集します
いくつかの方法を、次に例として示します。
管理クラスタのスナップショットを作成する場合は、シナリオを指定する必要はありません。
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
system
シナリオを使用して、ユーザー クラスタのスナップショットを作成する場合:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --scenario=system
all
シナリオを使用して、ユーザー クラスタのスナップショットを作成する場合:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --scenario=all
--log-since
を使用してスナップショットを制限する
--log-since
フラグを使用してログ収集を最近の期間に制限できます。たとえば、過去 2 日間または過去 3 時間のログのみを収集できます。デフォルトでは、diagnose snapshot
はすべてのログを収集します。
ログの収集期間を制限するには:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=CLUSTER_NAME \ --scenario=system \ --log-since=DURATION
DURATION は、120m
や 48h
などの値に置き換えます。
注:
--log-since
フラグは、kubectl
ログとjournalctl
ログでのみサポートされます。- カスタマイズされたスナップショット構成では、
--log-since
などのコマンドフラグは使用できません。
スナップショットのドライランの実行
--dry-run
フラグを使用して、実行するアクションとスナップショット構成を表示できます。
管理クラスタでドライランを実行するには、次のコマンドを入力します。
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=ADMIN_CLUSTER_NAME \ --dry-run
ユーザー クラスタでドライランを実行するには、次のコマンドを入力します。
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --dry-run
スナップショット構成の使用
これら 2 つのシナリオ(--scenario system
または all
)がニーズに合わない場合は、--snapshot-config
フラグを使用してスナップショット構成ファイルを渡すことで、カスタマイズされたスナップショットを作成できます。
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --snapshot-config=SNAPSHOT_CONFIG_FILE
スナップショット構成の生成
特定のシナリオのスナップショット構成を生成するには、--scenario
フラグと --dry-run
フラグを渡します。たとえば、ユーザー クラスタのデフォルトのシナリオ(system
)のスナップショット構成を表示するには、次のコマンドを入力します。
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --scenario=system --dry-run
出力は次のようになります。
numOfParallelThreads: 10 excludeWords: - password kubectlCommands: - commands: - kubectl get clusters -o wide - kubectl get machines -o wide - kubectl get clusters -o yaml - kubectl get machines -o yaml - kubectl describe clusters - kubectl describe machines namespaces: - default - commands: - kubectl version - kubectl cluster-info - kubectl get nodes -o wide - kubectl get nodes -o yaml - kubectl describe nodes namespaces: [] - commands: - kubectl get pods -o wide - kubectl get deployments -o wide - kubectl get daemonsets -o wide - kubectl get statefulsets -o wide - kubectl get replicasets -o wide - kubectl get services -o wide - kubectl get jobs -o wide - kubectl get cronjobs -o wide - kubectl get endpoints -o wide - kubectl get configmaps -o wide - kubectl get pods -o yaml - kubectl get deployments -o yaml - kubectl get daemonsets -o yaml - kubectl get statefulsets -o yaml - kubectl get replicasets -o yaml - kubectl get services -o yaml - kubectl get jobs -o yaml - kubectl get cronjobs -o yaml - kubectl get endpoints -o yaml - kubectl get configmaps -o yaml - kubectl describe pods - kubectl describe deployments - kubectl describe daemonsets - kubectl describe statefulsets - kubectl describe replicasets - kubectl describe services - kubectl describe jobs - kubectl describe cronjobs - kubectl describe endpoints - kubectl describe configmaps namespaces: - kube-system - gke-system - gke-connect.* prometheusRequests: [] nodeCommands: - nodes: [] commands: - uptime - df --all --inodes - ip addr - sudo iptables-save --counters - mount - ip route list table all - top -bn1 - sudo docker ps -a - ps -edF - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup - sudo conntrack --count nodeFiles: - nodes: [] files: - /proc/sys/fs/file-nr - /proc/sys/net/nf_conntrack_max seesawCommands: [] seesawFiles: [] nodeCollectors: - nodes: [] f5: enabled: true vCenter: enabled: true
numOfParallelThreads
: スナップショットの作成に使用される並列スレッドの数。excludeWords
: スナップショットから除外する単語のリスト(大文字と小文字は区別されません)。これらの単語を含む行はスナップショットの結果から削除されます。指定したかどうかにかかわらず、「パスワード」は常に除外されます。kubectlCommands
: 実行する kubectl コマンドのリスト。結果は保存されます。コマンドは、対応する Namespace に対して実行されます。kubectl logs
コマンドの場合、対応する Namespace 内のすべての Pod とコンテナが自動的に追加されます。正規表現が、Namespace の指定に使用されます。Namespace を指定しない場合は、default
Namespace が使用されます。nodeCommands
: 対応するノードで実行するコマンドのリスト。結果は保存されます。ノードが指定されていない場合、ターゲット クラスタ内のすべてのノードが考慮されます。nodeFiles
: 対応するノードから収集されるファイルのリスト。ファイルは保存されます。ノードが指定されていない場合、ターゲット クラスタ内のすべてのノードが考慮されます。seesawCommands
: Seesaw ロードバランサの情報を収集するために実行するコマンドのリスト。クラスタで Seesaw ロードバランサが使用されている場合は、結果が保存されます。seesawFiles
: Seesaw ロードバランサに関して収集されるファイルのリスト。nodeCollectors
: Cilium ノードで eBPF 情報を収集するために実行されるコレクタ。f5
: F5 BIG-IP ロードバランサに関する情報の収集を有効にするフラグ。vCenter
: vCenter に関する情報の収集を有効にするフラグ。prometheusRequests
: Prometheus リクエストのリスト。結果は保存されます。
スナップショットを Cloud Storage バケットにアップロードする
特定のクラスタのすべてのスナップショットを Cloud Storage バケットにアップロードすると、レコードの保持、分析、保存が容易になります。これは、Cloud カスタマーケアのサポートが必要な場合に特に役立ちます。
コマンドを実行する前に、これらの設定要件を満たしていることを確認してください。
フリートホスト プロジェクトで
storage.googleapis.com
を有効にします。別のプロジェクトを使用することもできますが、フリートホスト プロジェクトをおすすめします。gcloud services enable --project=FLEET_HOST_PROJECT_ID storage.googleapis.com
親プロジェクトのサービス アカウントに
roles/storage.admin
を付与し、--service-account-key-file
パラメータを使用してサービス アカウントの JSON キーファイルを渡します。任意のサービス アカウントを使用できますが、connect register サービス アカウントをおすすめします。詳細については、サービス アカウントをご覧ください。gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \ --member "serviceAccount:CONNECT_REGISTER_SERVICE_ACCOUNT" \ --role "roles/storage.admin"
CONNECT_REGISTER_SERVICE_ACCOUNT は、connect register サービス アカウントに置き換えます。
これらの要件を満たしたら、次のコマンドでスナップショットをアップロードできます。
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name CLUSTER_NAME \ --upload \ --share-with GOOGLE_SUPPORT_SERVICE_ACCOUNT
--share-with
フラグには、サービス アカウント名のリストを指定できます。GOOGLE_SUPPORT_SERVICE_ACCOUNT を、Google サポートが提供する他のサービス アカウントとともに、Google サポートが提供する Google サポート サービス アカウントに置き換えます。 --upload
フラグを使用すると、「anthos-snapshot-
」で始まる名前のストレージ バケットをプロジェクトで検索します。このようなバケットが存在すると、コマンドによって、そのバケットにスナップショットがアップロードされます。名前が一致するバケットが見つからない場合、このコマンドによって anthos-snapshot-UUID
という名前の新しいバケットが作成されます。ここで、UUID
は 32 桁の汎用一意識別子です。
--share-with
フラグを使用する場合、手動で Google Cloud サポートとバケットへのアクセスを共有する必要はありません。
出力例:
Using "system" snapshot configuration... Taking snapshot of user cluster CLUSTER_NAME... Setting up CLUSTER_NAME ssh key...DONE Using the gke-connect register service account key... Setting up Google Cloud Storage bucket for uploading the snapshot...DONE Taking snapshots in 10 thread(s)... ... Snapshot succeeded. Snapshots saved in "SNAPSHOT_FILE_PATH". Uploading snapshot to Google Cloud Storage...... DONE Uploaded the snapshot successfully to gs://anthos-snapshot-a4b17874-7979-4b6a-a76d-e49446290282/xSNAPSHOT_FILE_NAME. Shared successfully with service accounts: GOOGLE_SUPPORT_SERVICE_ACCOUNT
既知の問題
エラー BundleUnexpectedDiff
件
GKE on VMware バンドルによって管理される Kubernetes Cluster API リソースは、誤って変更され、システム コンポーネントやクラスタのアップグレードや更新の失敗を引き起こす可能性があります。
GKE on VMware バージョン 1.13 から、onprem-user-cluster-controller
はオブジェクトのステータスを定期的にチェックし、ログとイベントを使用して望ましい状態からの予期しない違いを報告します。これらのオブジェクトには、ユーザー クラスタ コントロール プレーンとアドオン(Service や DaemonSet など)が含まれます。
イベントの例を次に示します。
Type Reason Age From Message ---- ------ ---- ---- ------- Warning BundleUnexpectedDiff 13m onpremusercluster/ci-bundle-diff Detected unexpected difference of user control plane objects: [ConfigMap/istio], please check onprem-user-cluster-controller logs for more details.
onprem-user-cluster-controller
によって生成されたログの例を次に示します。
2022-08-06T02:54:42.701352295Z W0806 02:54:42.701252 1 update.go:206] Detected unexpected difference of user addon object(ConfigMap/istio), Diff: map[string]string{ 2022-08-06T02:54:42.701376406Z - "mesh": ( 2022-08-06T02:54:42.701381190Z - """ 2022-08-06T02:54:42.701385438Z - defaultConfig: 2022-08-06T02:54:42.701389350Z - discoveryAddress: istiod.gke-system.svc:15012 ... 2022-08-06T02:54:42.701449954Z - """ 2022-08-06T02:54:42.701453099Z - ), 2022-08-06T02:54:42.701456286Z - "meshNetworks": "networks: {}", 2022-08-06T02:54:42.701459304Z + "test-key": "test-data", 2022-08-06T02:54:42.701462434Z }
イベントとログがクラスタのオペレーションをブロックすることはありません。望ましい状態からの予期しない違いがあるオブジェクトは、次のクラスタ アップグレードで上書きされます。