Hier finden Sie nützliche Informationen zur Fehlerbehebung mit Anthos Clusters on AWS (GKE on AWS).
Überblick
Dieses Thema ist in folgende Abschnitte unterteilt:
- Informationen zum Cluster abrufen, um die Vorgänge Ihrer Anthos Clusters on AWS-Installation zu verstehen.
- Schritte zur Fehlerbehebung für häufige Probleme.
- Snapshot Ihres Clusterstatus, um Informationen für den Google Cloud-Support bereitzustellen.
Informationen zum Cluster abrufen
In diesem Abschnitt wird erläutert, wie Sie Informationen zu Ihrer Anthos Clusters on AWS-Installation zur Fehlerbehebung abrufen.
Informationen vom Verwaltungscluster abrufen
Sie können Ihren Verwaltungsdienst nach Informationen zu Ihren Nutzerclustern abfragen.
Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.cd anthos-aws anthos-gke aws management get-credentials
Verwenden Sie
kubectl get
, um die grundlegenden Statusinformationen eines Clusters abzurufen.env HTTPS_PROXY=http://localhost:8118 \ kubectl get AWSCluster
Die Ausgabe enthält den Namen, den aktuellen Status, das Alter, die Version und den Endpunkt jedes Clusters.
NAME STATE AGE VERSION ENDPOINT cluster-0 Provisioning 2m41s 1.25.5-gke.2100 gke-<var>endpoint</var>.elb.us-east-1.amazonaws.com
Mit kubectl describe
können Sie weitere Informationen zu einem Cluster abrufen.
env HTTPS_PROXY=http://localhost:8118 \
kubectl describe AWSCluster cluster-0
Diese Ausgabe enthält drei Hauptabschnitte:
Spec
listet die anfängliche deklarative Konfiguration des Clusters auf.Status
enthält den Status des Clusters und die vom Verwaltungsdienst erstellten AWS-Ressourcen.Events
enthält alle kürzlich erfolgten Aktionen oder Fehler. Dieses Log ist für das Debugging des Clusters von unschätzbarem Wert.
Die Ausgabe sollte so aussehen.
Name: cluster-0
Namespace: default
Kind: AWSCluster
Metadata:
Creation Timestamp: 0000-00-00T00:00:00Z
...
Spec:
Control Plane:
Etcd:
Main Volume:
Size GiB: 10
Iam Instance Profile: gke-node
Instance Type: t2.medium
Key Name: gke-key
Root Volume:
Size GiB: 10
Subnet IDs:
subnet-0000
Version: 0.00.0-gke.00
Networking:
Pod Address CIDR Blocks:
0.0.0.0/0
...
Status:
Admin Cert Secret Name: gke-0000-admin-cert
API DNS Name: gke-0000-controlplane-0000.elb.region.amazonaws.com
Control Plane Security Group ID: sg-0000
Gke Hub Membership Name: projects/global/memberships/gke-0000-cluster
Listener ARN: arn:aws:elasticloadbalancing:region:0000:listener/net/gke-0000
Load Balancer Name: gke-0000-controlplane
Node Pool Security Group ID: sg-0000
Provisioning Info:
Addons Installed: false
Gke Hub Membership Installed: false
Target Version: 0.00.0-gke.0
Replica Status:
Auto Scaling Group Name: gke-0000-controlplane-0
Etcd Main Volume ID: vol-0000
Launch Template Name: gke-0000-controlplane-0-0.00.0-gke.0
Network Interface ID: eni-0000
Private IP Address: 0.0.0.0
Replica: 0
...
Root CA Secret Name: gke-0000-root-ca
State: Provisioning
Target Group Name: gke-0000-controlplane
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal CreatedSecurityGroup 1m36s cluster-operator Created security group named "gke-0000"
Normal CreatedEtcdVolume 1m35s cluster-operator Created etcd volume on replica 0
Normal CreatedEtcdVolume 1m35s cluster-operator Created etcd volume on replica 2
Normal CreatedEtcdVolume 1m35s cluster-operator Created etcd volume on replica 1
Normal CreatedNetworkLoadBalancer 1m34s cluster-operator Created network load balancer named "gke-0000-controlplane"
Normal CreatedTargetGroup 1m34s cluster-operator Created target group named "gke-0000-controlplane"
Normal CreatedRootCASecret 1m34s cluster-operator Created root CA secret named "default/gke-0000-root-ca"
Normal CreatedGKEHubMembership 1m33s cluster-operator Created GKE Hub membership named "projects/global/memberships/gke-0000-cluster"
Normal CreatedNetworkInterface 1m30s cluster-operator Created network interface on replica 2
Nutzercluster-IDs abrufen
Für die Konfiguration bestimmter Anthos Clusters on AWS-Features benötigen Sie möglicherweise Ihre Nutzercluster-IDs.
Führen Sie die folgenden Schritte aus, um Ihre Anthos Clusters on AWS-Nutzercluster-ID abzurufen:
Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.cd anthos-aws anthos-gke aws management get-credentials
Verwenden Sie
kubectl get awscluster
, um Ihre Cluster-IDs abzurufen.env HTTPS_PROXY=http://localhost:8118 \ kubectl get awscluster -o jsonpath={.items..status.clusterID}
Die Ausgabe enthält Ihre Cluster-IDs.
Ereignisse
Ein Ereignis ist eine Nachricht, die an ein Kubernetes-Objekt angehängt ist. Ereignisse beschreiben Aktionen, die sich auf den Status der Ressource auswirken. Der Verwaltungsdienst hängt Ereignisse an die Objekte AWSCluster
und AWSNodePool
an. Ereignisse bieten ein Log der Schritte zum Erstellen, Aktualisieren, Ändern der Größe oder Löschen des Clusters. Verwenden Sie kubectl get
events
, um Ereignisse aufzulisten.
env HTTPS_PROXY=http://localhost:8118 \
kubectl get events
Beispielausgabe
LAST SEEN TYPE REASON OBJECT MESSAGE
27s Normal CreatingCluster awscluster/cluster-0 Cluster version 1.25.5-gke.2100 is being created
24s Normal CreatedSecurityGroup awscluster/cluster-0 Created security group named "gke-123456a7-controlplane"
24s Normal CreatedSecurityGroup awscluster/cluster-0 Created security group named "gke-123456a7-nodepool"
23s Normal CreatedEtcdVolume awscluster/cluster-0 Created etcd volume on replica 0
23s Normal CreatedEtcdVolume awscluster/cluster-0 Created etcd volume on replica 1
23s Normal CreatedEtcdVolume awscluster/cluster-0 Created etcd volume on replica 2
23s Normal CreatedNetworkLoadBalancer awscluster/cluster-0 Created network load balancer named "gke-123456a7-controlplane"
23s Normal CreatedTargetGroup awscluster/cluster-0 Created target group named "gke-123456a7-controlplane"
23s Normal CreatedRootCASecret awscluster/cluster-0 Created root CA secret named "default/gke-123456a7-api-server-ca"
22s Normal CreatedGKEHubMembership awscluster/cluster-0 Created GKE Hub membership named "projects/global/memberships/gke-123456a7-cluster"
20s Normal CreatedNetworkInterface awscluster/cluster-0 Created network interface on replica 0
20s Normal CreatedNetworkInterface awscluster/cluster-0 Created network interface on replica 1
20s Normal CreatedNetworkInterface awscluster/cluster-0 Created network interface on replica 2
20s Normal CreatedAdminCertSecret awscluster/cluster-0 Created admin certificate secret named "default/gke-123456a7-admin-cert"
27s Normal StartedNodePoolProvisioning awsnodepool/pool-0 Started node pool provisioning
13s Normal CreatedAutoScalingGroup awsnodepool/pool-0 Created auto scaling group named "gke-123456a7-nodepool-8b269fb0"
Operatorlogs
Ereignisse listet die vom Operator durchgeführten übergeordneten Aktionen auf. Möglicherweise müssen Sie untergeordnete Aktivitäten wie Stacktraces beobachten. Der Verwaltungsdienst führt einen statischen Pod namens gke-aws-cluster-operator
aus. Diese Anwendung ist ein Operator, der die zentrale Clusterverwaltungslogik enthält.
In den folgenden Schritten verwenden Sie das Tool crictl
, um Logs aus dem gke-aws-cluster-operator
zu untersuchen.
Wechseln Sie in das Verzeichnis mit Ihrer Anthos Clusters on AWS-Konfiguration. Sie haben dieses Verzeichnis bei der Installation des Verwaltungsdienstes erstellt.
cd anthos-aws
Suchen Sie das DNS der Management-EC2-Instanz. Wählen Sie Ihre Terraform-Version aus und führen Sie dann die folgenden Befehle aus:
Terraform 0.12, 0.13
export CLUSTER_ID=$(terraform output cluster_id) export MANAGEMENT_IP=$(aws ec2 describe-instances \ --filters "Name=tag:Name,Values=$CLUSTER_ID-management-0" \ --query "Reservations[*].Instances[*].PrivateIpAddress" \ --output text)
Terraform 0.14.3+
export CLUSTER_ID=$(terraform output -raw cluster_id) export MANAGEMENT_IP=$(aws ec2 describe-instances \ --filters "Name=tag:Name,Values=$CLUSTER_ID-management-0" \ --query "Reservations[*].Instances[*].PrivateIpAddress" \ --output text)
Wenn Sie einen Bastion Host verwenden, suchen Sie das DNS des Bastion Hosts.
Terraform 0.12, 0.13
export BASTION_DNS=$(terraform output bastion_dns_name)
Terraform 0.14.3+
export BASTION_DNS=$(terraform output -raw bastion_dns_name)
Stellen Sie eine SSH-Verbindung zur Verwaltungsinstanz her. Wählen Sie aus, ob Sie eine direkte Verbindung haben oder einen Bastion Host verwenden.
Direkte Verbindung
ssh -i ~/.ssh/anthos-gke ubuntu@$MANAGEMENT_IP
Bastion
ssh -i ~/.ssh/anthos-gke -J ubuntu@$BASTION_DNS ubuntu@$MANAGEMENT_IP
Rufen Sie die Container-ID des Pods
gke-aws-cluster-operator
ab.export POD_ID=$(sudo crictl pods --name gke-aws-cluster-operator --quiet) export CONTAINER_ID=$(sudo crictl ps --pod $POD_ID --latest --quiet)
Drucken Sie die Logs des Pods aus.
sudo crictl logs $CONTAINER_ID
Terraform
Der Befehl anthos-gke
gibt Terraform aus, um einen Verwaltungsdienst bereitzustellen.
Mit dem Befehl terraform state
können Sie die Infrastruktur auflisten, die im Status von Terraform verwaltet wird.
terraform state list
Beispielausgabe
module.gke_dedicated_vpc.module.gke_bastion.aws_security_group.this
module.gke_dedicated_vpc.module.gke_bastion_security_group_rules.aws_security_group_rule.allow_http_outbound
module.gke_dedicated_vpc.module.gke_bastion_security_group_rules.aws_security_group_rule.allow_https_outbound
module.gke_dedicated_vpc.module.gke_bastion_security_group_rules.aws_security_group_rule.allow_ssh_inbound
module.gke_dedicated_vpc.module.gke_bastion_security_group_rules.aws_security_group_rule.allow_ssh_outbound
module.gke_dedicated_vpc.module.gke_controlplane_iam_policies.data.aws_iam_policy_document.this
module.gke_dedicated_vpc.module.gke_controlplane_iam_policies.aws_iam_role_policy.this
module.gke_dedicated_vpc.module.gke_controlplane_iam_role.data.aws_iam_policy_document.assume_role_policy
module.gke_dedicated_vpc.module.gke_controlplane_iam_role.aws_iam_instance_profile.this
module.gke_dedicated_vpc.module.gke_controlplane_iam_role.aws_iam_role.this
module.gke_dedicated_vpc.module.gke_management.data.aws_ami.this
module.gke_dedicated_vpc.module.gke_management.data.aws_iam_policy_document.assume_role_policy
module.gke_dedicated_vpc.module.gke_management.data.aws_subnet.this[0]
module.gke_dedicated_vpc.module.gke_management.aws_autoscaling_group.this[0]
module.gke_dedicated_vpc.module.gke_management.aws_ebs_volume.main[0]
module.gke_dedicated_vpc.module.gke_management.aws_iam_instance_profile.this
module.gke_dedicated_vpc.module.gke_management.aws_iam_role.this
module.gke_dedicated_vpc.module.gke_management.aws_launch_template.this[0]
module.gke_dedicated_vpc.module.gke_management.aws_lb.this
module.gke_dedicated_vpc.module.gke_management.aws_lb_listener.this
module.gke_dedicated_vpc.module.gke_management.aws_lb_target_group.this
module.gke_dedicated_vpc.module.gke_management.aws_security_group.this
module.gke_dedicated_vpc.module.gke_management_iam_policies.data.aws_iam_policy_document.this
module.gke_dedicated_vpc.module.gke_management_iam_policies.aws_iam_role_policy.this
module.gke_dedicated_vpc.module.gke_management_security_group_rules.aws_security_group_rule.allow_cidr_https_inbound[0]
module.gke_dedicated_vpc.module.gke_management_security_group_rules.aws_security_group_rule.allow_http_outbound
module.gke_dedicated_vpc.module.gke_management_security_group_rules.aws_security_group_rule.allow_https_inbound[0]
module.gke_dedicated_vpc.module.gke_management_security_group_rules.aws_security_group_rule.allow_https_outbound
module.gke_dedicated_vpc.module.gke_management_security_group_rules.aws_security_group_rule.allow_ssh_inbound[0]
module.gke_dedicated_vpc.module.gke_nodepool_iam_policies.data.aws_iam_policy_document.this
module.gke_dedicated_vpc.module.gke_nodepool_iam_policies.aws_iam_role_policy.this
module.gke_dedicated_vpc.module.gke_nodepool_iam_role.data.aws_iam_policy_document.assume_role_policy
module.gke_dedicated_vpc.module.gke_nodepool_iam_role.aws_iam_instance_profile.this
module.gke_dedicated_vpc.module.gke_nodepool_iam_role.aws_iam_role.this
module.gke_dedicated_vpc.module.gke_vpc.aws_eip.nat[0]
module.gke_dedicated_vpc.module.gke_vpc.aws_internet_gateway.this
module.gke_dedicated_vpc.module.gke_vpc.aws_nat_gateway.this[0]
module.gke_dedicated_vpc.module.gke_vpc.aws_route.private_nat_gateway[0]
module.gke_dedicated_vpc.module.gke_vpc.aws_route.public_internet_gateway
module.gke_dedicated_vpc.module.gke_vpc.aws_route_table.private[0]
module.gke_dedicated_vpc.module.gke_vpc.aws_route_table.public
module.gke_dedicated_vpc.module.gke_vpc.aws_route_table_association.private[0]
module.gke_dedicated_vpc.module.gke_vpc.aws_route_table_association.public[0]
module.gke_dedicated_vpc.module.gke_vpc.aws_subnet.private[0]
module.gke_dedicated_vpc.module.gke_vpc.aws_subnet.public[0]
module.gke_dedicated_vpc.module.gke_vpc.aws_vpc.this
Mit dem Befehl terraform state show
können Sie jede Ressource genauer untersuchen.
Sehen wir uns beispielsweise den Load-Balancer vor dem Verwaltungsdienst an.
terraform state show module.gke_dedicated_vpc.module.gke_management.aws_lb.this
Beispielausgabe
resource "aws_lb" "this" {
arn = "arn:aws:elasticloadbalancing:aws-region:aws-account:loadbalancer/net/gke-12345678-management/arn-id"
arn_suffix = "net/gke-12345678-management/abcde1234"
dns_name = "exampledns.elb.ca-central-1.amazonaws.com"
enable_cross_zone_load_balancing = true
enable_deletion_protection = false
id = "arn:aws:elasticloadbalancing:aws-region:aws-account:loadbalancer/net/gke-12345678-management/arn-id"
internal = true
ip_address_type = "ipv4"
load_balancer_type = "network"
name = "gke-12345678-management"
security_groups = []
subnets = [
"subnet-0f77f5a97beb42e6d",
]
vpc_id = "vpc-0a123456789b"
zone_id = "Z2EPGBW3API2WT"
access_logs {
enabled = false
}
subnet_mapping {
subnet_id = "subnet-0f77f5a97beb42e6d"
}
}
Schritte zur Fehlerbehebung
In diesem Abschnitt werden spezifische Schritte zur Fehlerbehebung aufgeführt, die bei Anthos Clusters on AWS auftreten können.
Terraform-Fehler
In diesem Abschnitt werden Fehler aufgeführt, die möglicherweise bei der Einrichtung Ihres Verwaltungsdiensts mit den anthos-gke
- und terraform
-Befehlszeilentools auftreten.
NoCredentialProviders
Wenn der folgende Fehler angezeigt wird, prüfen Sie, ob Sie eine Version von Terraform höher als v0.12.28 haben. Wenn Sie keine kompatible Version von Terraform haben, laden Sie sie herunter und installieren Sie sie.
Error: cannot determine availability zones: NoCredentialProviders: no valid providers in chain. Deprecated. For verbose messaging see aws.Config.CredentialsChainVerboseErrors
Verfügbare Anbieter konnten nicht abgefragt werden
Wenn der folgende Fehler angezeigt wird, haben Sie möglicherweise Ihre Version von Terraform aktualisiert.
exit status 1: Error: Failed to query available provider packages
Could not retrieve the list of available versions for provider hashicorp/aws:
locked provider registry.terraform.io/hashicorp/aws 2.70.0 does not match
configured version constraint 3.26.0; must use terraform init -upgrade to
allow selection of new versions
Löschen Sie die Datei .terraform.lock.hcl
aus dem Verzeichnis anthos-aws
, um diesen Fehler zu beheben.
Unbekanntes Token
Wenn bei der Erstellung eines Verwaltungsdiensts der folgende Fehler auftritt:
Error: error running 'terraform init -input=false -no-color' exit status 1:
There are some problems with the configuration, described below.
The Terraform configuration must be valid before initialization so that
Terraform can determine which modules and providers need to be installed.
Error: Error parsing /home/user/aws/main.tf: At 15:12: Unknown token:
15:12 IDENT var.region
Prüfen Sie, ob Sie eine Version von Terraform höher als v0.12.28 haben. Wenn Sie keine kompatible Version von Terraform haben, laden Sie sie herunter und installieren Sie sie.
Ungültige Adresse für den alten Anbieter
Wenn der folgende Fehler ausgegeben wird, müssen Sie Ihre Terraform-Binärdatei über jede Nebenversion aktualisieren.
Error: error running 'terraform init -input=false -no-color'.
exit status 1: Error: Invalid legacy provider address
This configuration or its associated state refers to the unqualified provider
"aws".
You must complete the Terraform 0.13 upgrade process before upgrading to later
versions.
Wenn Sie beispielsweise Terraform von v0.12.x auf Version 0.14.x aktualisieren möchten, müssen Sie v0.13.x vorübergehend installieren. Führen Sie nach der Installation von Version 0.13.x anthos-gke aws
management init
und anthos-gke aws management apply
aus. Anschließend können Sie ein Upgrade auf Version 0.14.x durchführen.
Verbindung zum Bastion Host kann nicht hergestellt werden
Wenn Sie beim Versuch, eine Verbindung zum Bastion Host herzustellen, die Fehlermeldung bind [::1]:8118: Cannot assign requested address
erhalten, können Sie möglicherweise keine Verbindung über IPv4 herstellen. Erzwingen Sie mit dem folgenden Befehl eine IPv4-Verbindung:
./bastion-tunnel.sh -N -4
Serververbindung kann nicht hergestellt werden
Wenn Sie beim Versuch, in Ihrem Nutzercluster einen kubectl
-Befehl auszuführen, die Fehlermeldung Unable to connect to the server
erhalten, prüfen Sie Folgendes:
- Alle privaten Subnetze haben Routen untereinander.
- Ihre privaten Subnetze haben Zugriff auf ein AWS-NAT-Gateway.
- Wenn Sie
kubectl
1.21 verwenden, ändern Sie die VariableHTTP_PROXY
inHTTPS_PROXY
.
Connect kann nicht auf das Projekt zugreifen
Während einiger Connect-Vorgänge beim Registrieren Ihres Clusters tritt möglicherweise ein ähnlicher Fehler wie der folgende auf:
ERROR: (gcloud.container.hub.memberships.register) failed to initialize Default Feature "authorizer", the fleet service account (service-PROJECT_NUMBER@gcp-sa-gkehub.iam.gserviceaccount.com) may not have access to your project
Weitere Informationen finden Sie unter Multi-Cluster-Verwaltung-Fehlerbehebung im Eintrag Flotte kann nicht auf das Projekt zugreifen.
Berechtigungsfehler
Wenn Sie bei der Verwendung des anthos-gke
-Befehlszeilentools einen Authentifizierungsfehler erhalten, z. B.:
oauth2: cannot fetch token: 400 Bad Request
Authentifizieren Sie Ihre Installation von Google Cloud CLI noch einmal mit gcloud auth application-default login
.
kubectl
kann keine Verbindung zu Ihrem Cluster herstellen.
Wenn beim Versuch, eine Verbindung zu Ihrem Cluster mit kubectl
herzustellen, der folgende Fehler angezeigt wird:
Error: could not get token: NoCredentialProviders: no valid providers in chain. Deprecated.
For verbose messaging see aws.Config.CredentialsChainVerboseErrors
Lösung
Ihre Anmeldedaten für die AWS-Befehlszeile sind möglicherweise abgelaufen. Prüfen Sie, ob die Anmeldedaten bei aws ec2 describe instances
gültig sind.
Erstellen Sie Ihre Anmeldedaten bei aws configure
noch einmal. Wenn Sie die Multi-Faktor-Authentifizierung (MFA) verwenden, erstellen Sie Ihr AWS MFA-Token neu.
Ein AWSCluster
bleibt im Status Provisioning
Wenn ein Clusters in kubectl get awsclusters
oder kubectl describe AWSCluster cluster-name
im Status Provisioning
bleibt, prüfen Sie den Wert des Felds spec.controlPlane.hub.membershipName
Ihres AWSCluster
s. Der Wert dieses Felds muss eindeutig sein.
kubectl get awsclusters
NAME STATE AGE VERSION ENDPOINT
awscluster.multicloud.cluster.gke.io/cluster-0 Provisioning 8h 1.25.5-gke.2100 gke-123456a7-controlplane-abcdefg12345.elb.us-east-1.amazonaws.com
Lösungen
Führen Sie die folgenden Schritte aus, um das Problem zu beheben:
- Vergewissern Sie sich, dass Sie eine unterstützte Terraform-Version ausführen.
- Wenn Sie in Ihrem AWS-Konto mehrere Nutzercluster erstellt haben, bearbeiten Sie Ihre AWSCluster-Definition.
Ändern Sie
spec.controlPlane.hub.membershipName
in einen eindeutigen Wert. Wenden Sie die Änderung mitkubectl
an.
TLS-Fehler beim Herstellen einer Verbindung zum Cluster
Wenn beim Verbinden mit Ihrem Cluster der folgende Fehler angezeigt wird:
error dialing backend: remote error: tls: internal error
Achten Sie darauf, dass die festgelegten DHCP-Optionen Ihrer AWS-VPC keinen benutzerdefinierten Wert für domain-name
haben. Wenn eine benutzerdefinierte Domain eingerichtet wurde, können Anthos Clusters on AWS keine Anfrage zur Zertifikatssignierung generieren.
Lösung
Führen Sie einen der folgenden Schritte aus, um das Problem zu beheben:
Legen Sie für
enableDnsHostnames
in Ihrer VPC „false” fest: Wenn Sie eine dedizierte AWS-VPC mitanthos-gke
erstellen, können Sie diesen Wert in der Datei.terraform/modules/gke_vpc/modules/gke-vpc/main.tf
festlegen.Aktualisieren Sie den Wert von
domain-name
auf den Standardwert.
Steuerungsebene neu starten
Wenn die Steuerungsebene nicht mehr reagiert, können Sie ihre Instanzen neu starten. Falls Sie Instanzen der Steuerungsebene neu starten, bleibt Ihre Konfiguration erhalten, da der Status auf nichtflüchtigen Speichern gespeichert wird.
- Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.cd anthos-aws anthos-gke aws management get-credentials
Nutzen Sie
kubectl
, um die AWS EC2-Zielgruppe Ihrer Steuerungsebene von Ihrem AWSCluster abzurufen.env HTTPS_PROXY=http://localhost:8118 \ kubectl get awscluster cluster-name \ -o jsonpath='{.status.targetGroupName}{"\n"}'
Die Ausgabe enthält den Namen der EC2-Zielgruppe Ihrer Steuerungsebene. Beispiel:
gke-123456a7-controlplane
Öffnen Sie die AWS EC2-Konsole. Wählen Sie im linken Bereich Zielgruppen aus.
Klicken Sie auf die Suchleiste und suchen Sie Ihre Zielgruppe. Klicken Sie auf den Namen Ihrer Zielgruppe und dann auf Ziele. Die Liste der Instanzen Ihrer Steuerungsebene wird angezeigt.
Führen Sie für jede Instanz in der Zielgruppe die folgenden Schritte aus:
Klicken Sie auf die Instanz-ID der Instanz. Die Konsole der AWS EC2-Instanzen wird angezeigt.
Klicken Sie auf die Instanz-ID.
Wählen Sie Aktionen -> Instanzstatus -> Beenden aus, um die Instanz zu entfernen. EC2 erstellt automatisch eine neue Instanz mit demselben EBS-Volume.
Kehren Sie zur Seite „Zielgruppen” zurück.
Nachdem Sie alle Instanzen in der Gruppe beendet haben, kehren Sie zur Seite "Zielgruppen" zurück.
Suchen Sie im Abschnitt Registrierte Ziele der Spalte die Spalte Status. Der Status Ihrer Instanzen sollte für Healthy (Status) Healthy (Fehlerfrei) lauten. Wenn eine der Instanzen fehlerfrei ist, warten Sie einige Minuten und klicken Sie auf das Symbol "Aktualisieren" (
).Wenn alle Instanzen in der Zielgruppe fehlerfrei sind, fahren Sie mit dem nächsten Schritt fort.
Subnetze taggen
Anthos Clusters on AWS erfordert Tags für Subnetze, die Endpunkte des Load-Balancers enthalten. Anthos Clusters on AWS kennzeichnet automatisch alle Subnetze im Feld spec.Networking.ServiceLoadBalancerSubnetIDs
der Ressource AWSCluster
mit Tags.
Wenn Sie Ihrem Nutzercluster weitere Subnetze hinzufügen oder Tags auf vorhandene Subnetze anwenden möchten, führen Sie die folgenden Schritte aus:
Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.cd anthos-aws anthos-gke aws management get-credentials
Rufen Sie die ID der AWS-VPC des Clusters mit
kubectl
ab und speichern Sie sie als Variable.export VPC_ID=$(\ env HTTPS_PROXY=http://localhost:8118 \ kubectl get awscluster cluster-0 -o jsonpath='{.spec.networking.vpcID}')
Prüfen Sie den Inhalt der Variablen mit
echo
. Die Ausgabe ähneltvpc-12345678abcdef0
.echo $VPC_ID
Speichern Sie die Cluster-ID in einer Umgebungsvariablen.
export CLUSTER_ID=$(\ env HTTPS_PROXY=http://localhost:8118 \ kubectl get awscluster cluster-0 -o jsonpath='{.status.clusterID}')
Sie können die Variable mit
echo
prüfen:echo $CLUSTER_ID
Die Antwort enthält Ihre Cluster-ID.
gke-12345678
Wenn Sie Anthos-Cluster auf AWS in einer dedizierten VPC installiert haben, können Sie mit dem
aws
-Befehlszeilentool die Subnetz-ID abrufen.Folgende Optionen sind verfügbar:
- Öffentlich, wenn Sie Dienste in Ihrem öffentlichen Subnetz verfügbar machen möchten.
- Privat, wenn Sie Dienste in Ihrem privaten Subnetz verfügbar machen möchten.
Mehrere Subnetze, wenn Sie Dienste in mehreren Subnetzen verfügbar machen möchten.
Öffentlich
export SUBNET_ID=$(aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=$VPC_ID" "Name=tag:Name,Values=*public*" \ --query "Subnets[*].SubnetId" \ --output text)
Die Ausgabe ist ein Objekt, das Ihre Subnetz-ID enthält. Sie ähnelt
subnet-1234abcdefg
. Sie können die Variable mitecho
prüfen:echo $SUBNET_ID
Die Antwort enthält Ihre Subnetz-ID.
subnet-012345678abcdef
Privat
export SUBNET_ID=$(aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=$VPC_ID" "Name=tag:Name,Values=*private*" \ --query "Subnets[*].SubnetId" \ --output text)
Die Ausgabe ist ein Objekt, das Ihre Subnetz-ID enthält. Sie ähnelt
subnet-1234abcdefg
. Sie können die Variable mitecho
prüfen:echo $SUBNET_ID
Die Antwort enthält Ihre Subnetz-ID.
subnet-012345678abcdef
Mehrere Subnetze
Wenn Sie mehrere Subnetze für Ihre AWSNodePools nutzen, z. B. wenn Sie mehrere Verfügbarkeitszonen verwenden, müssen Sie Ihre Subnetz-IDs einzeln taggen.
Rufen Sie die Liste der Subnetz-IDs mit
aws ec2 describe-subnets
ab.Führen Sie den folgenden Befehl aus, um eine Liste aller öffentlichen Subnetze abzurufen:
aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=$VPC_ID" "Name=tag:Name,Values=*public*" \ --query "Subnets[*].SubnetId" \ --output text
Führen Sie den folgenden Befehl aus, um eine Liste aller privaten Subnetze abzurufen:
aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=$VPC_ID" "Name=tag:Name,Values=*private*" \ --query "Subnets[*].SubnetId" \ --output text
Die Antwort enthält Ihre Subnetz-IDs.
subnet-012345678abcdef subnet-abcdef123456789 subnet-123456789abcdef
Taggen Sie das Subnetz mit Ihrer Cluster-ID. Wenn Sie mehrere Subnetze haben, wählen Sie die Methode für mehrere Subnetze aus.
Einzelnes Subnetz
aws ec2 create-tags \ --resources $SUBNET_ID \ --tags Key=kubernetes.io/cluster/$CLUSTER_ID,Value=shared
Mehrere Subnetze
Führen Sie für jedes Ihrer Subnetze den folgenden Befehl aus:
aws ec2 create-tags \ --resources subnet-ids \ --tags Key=kubernetes.io/cluster/$CLUSTER_ID,Value=shared
Ersetzen Sie subnet-ids durch die durch Leerzeichen getrennte Liste der Subnetz-IDs. Beispiel:
subnet-012345678abcdef subnet-abcdef123456789 subnet-123456789abcdef
Fehler beim Löschen der Cluster
Wenn kubectl
beim Löschen eines Nutzerclusters nicht reagiert, rufen Sie die Ereignisse Ihres Clusters ab. Möglicherweise sehen Sie das folgende Ereignis.
Could not delete security group: resource SECURITY_GROUP_ID has a dependent object.
Lösung
Löschen Sie alle AWS Elastic File System-Bereitstellungsziele in SECURITY_GROUP_ID.
API-Fehler
Mit Kubernetes 1.22 werden mehrere APIs verworfen und ersetzt. Wenn Sie Ihren Cluster auf Version 1.22 oder höher aktualisiert haben, schlagen alle Aufrufe Ihrer Anwendung an eine der verworfenen APIs fehl.
Lösung
Führen Sie ein Upgrade Ihrer Anwendung durch, um Aufrufe von verworfenen APIs durch Aufrufe der neueren Gegenstücke zu ersetzen.
Snapshots
Das anthos-gke
-Tool unterstützt das Erstellen von Snapshots Ihrer Anthos Clusters on AWS-Umgebung. Ein Snapshot enthält Informationen, die dem Google Cloud-Support helfen, Probleme offline zu reproduzieren und Fehler zu beheben.
Das Tool anthos-gke
kann einen Snapshot von einem Verwaltungsdienst oder von Nutzerclustern generieren. Standardmäßig enthält ein Snapshot CRDs, Ereignisse, Clusterinformationen, Clusterlogs, Instanzlogs und Instanzdateien. Sie können die in einer Konfigurationsdatei enthaltenen Informationen anpassen. Das Bundle enthält außerdem ein index.html
mit Links zu den enthaltenen Dateien.
Wenn Sie Probleme mit Ihrer Anthos Clusters on AWS-Installation beheben möchten, bevor Sie den Google Cloud-Support kontaktieren, fahren Sie mit dem nächsten Abschnitt fort.
Snapshot erstellen
In diesem Abschnitt wird gezeigt, wie Sie einen Snapshot von einem Verwaltungs- oder Nutzercluster mit der Standardkonfiguration oder einer benutzerdefinierten Konfiguration erstellen.
Hinweis
Führen Sie die folgenden Schritte aus, um eine Verbindung zu Ihren Anthos Clusters on AWS-Ressourcen herzustellen. Wählen Sie aus, ob Sie eine bestehende AWS-VPC (oder eine direkte Verbindung zu Ihrer VPC) verwenden oder beim Erstellen Ihres Verwaltungsdienstes eine dedizierte VPC angelegt haben.
Vorhandene VPC
Wenn Sie eine direkte Verbindung oder eine VPN-Verbindung zu einer vorhandenen VPC verwenden, lassen Sie die Zeile env HTTP_PROXY=http://localhost:8118
in den Befehlen in diesem Thema weg.
Dedizierte VPC
Wenn Sie einen Verwaltungsdienst in einer dedizierten VPC erstellen, enthält Anthos-Cluster auf AWS einen Bastion-Host in einem öffentlichen Subnetz.
So stellen Sie eine Verbindung zu Ihrem Verwaltungsdienst her:
Wechseln Sie in das Verzeichnis mit Ihrer Anthos-Cluster auf AWS-Konfiguration. Sie haben dieses Verzeichnis bei der Installation des Verwaltungsdienstes erstellt.
cd anthos-aws
Führen Sie das Skript
bastion-tunnel.sh
aus, um den Tunnel zu öffnen. Über den Tunnel erfolgt eine Weiterleitung zulocalhost:8118
.Führen Sie den folgenden Befehl aus, um einen Tunnel zum Bastion Host zu öffnen:
./bastion-tunnel.sh -N
In diesem Fenster werden Nachrichten aus dem SSH-Tunnel angezeigt. Wenn Sie bereit sind, die Verbindung zu trennen, beenden Sie den Vorgang mit Strg+C oder schließen Sie das Fenster.
Öffnen Sie ein neues Terminal und wechseln Sie in das Verzeichnis
anthos-aws
:cd anthos-aws
Prüfen Sie, ob Sie mit
kubectl
eine Verbindung zum Cluster herstellen können.env HTTPS_PROXY=http://localhost:8118 \ kubectl cluster-info
Die Ausgabe enthält die URL für den API-Server des Verwaltungsdiensts.
Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.cd anthos-aws anthos-gke aws management get-credentials
Snapshot eines Verwaltungsdienstes erstellen
Verwenden Sie anthos-gke aws management diagnose snapshot
, um einen Snapshot eines Verwaltungsdienstes zu erstellen.
env HTTPS_PROXY=http://localhost:8118 \
anthos-gke aws management diagnose snapshot \
--ssh-key-path ssh-key-path \
--workspace workspace
Ersetzen Sie:
- ssh-key-path durch den Pfad zu Ihrem Anthos Clusters on AWS-SSH-Schlüssel.
Standardmäßig wird die Datei unter
.ssh/anthos-gke
erstellt. - workspace durch den Pfad zum Verzeichnis, in dem Sie Ihre Anthos Clusters on AWS-Bereitstellung erstellt haben. Wenn ein Bastion Host im Rahmen einer dedizierten VPC-Installation erstellt wurde, verwendet Anthos Clusters on AWS die Bastion, um eine Verbindung mit Ihrem Verwaltungsdienst herzustellen.
Die Ausgabe enthält das Aktionslog und den Namen der Snapshot-Datei:
2020/06/15 15:39:48 Found bastion instance in tfworkspace. IP: bastion-ip.aws-zone.compute.amazonaws.com
writing file: /tmp/kubeconfig-mgmt679794004/kubeconfig.conf
snapshot: 2020/06/15 15:39:50 Getting snapshot of controlPlane...
snapshot: 2020/06/15 15:39:50 Getting snapshot of kubectl command...
snapshot: 2020/06/15 15:39:52 Getting snapshot of control plane managed aws resources
...
ip-10-0-1-44/commands/ip_route_list_table_all.out
/tmp/tmp.Z26niLmVfU/snapshot.tar.gz
2020/06/15 15:40:04 Snapshot saved in snapshot-1592260783.tar.gz.
Snapshot eines Nutzerclusters erstellen
Verwenden Sie anthos-gke aws clusters diagnose snapshot
, um einen Snapshot eines Nutzerclusters zu erstellen.
env HTTPS_PROXY=http://localhost:8118 \
anthos-gke aws clusters diagnose snapshot user-cluster-name \
--ssh-key-path ssh-key-path --workspace terraform-workspace
Ersetzen Sie:
- user-cluster-name ist der Name Ihres Nutzerclusters. Standardmäßig erhält der erste Nutzercluster den Namen
cluster-0
. - ssh-key-path durch den Pfad zu Ihrem Anthos Clusters on AWS-SSH-Schlüssel.
Standardmäßig wird die Datei unter
.ssh/anthos-gke
erstellt. - terraform-workspace durch den Pfad zum Terraform-Arbeitsbereich, in dem Sie Ihre Anthos Clusters on AWS-Bereitstellung erstellt haben.
Die Ausgabe enthält das Aktionslog und den Namen der Snapshot-Datei:
2020/06/15 15:43:37 Found bastion instance in tfworkspace. IP: bastion-ip.aws-zone.compute.amazonaws.com
writing file: /tmp/kubeconfig-mgmt616204648/kubeconfig.conf
snapshot: 2020/06/15 15:43:40 Getting snapshot of controlPlane...
snapshot: 2020/06/15 15:43:40 Getting snapshot of kubectl command...
writing file: /tmp/kubeconfig-clustercluster-0620691367/kubeconfig.conf
snapshot: 2020/06/15 15:43:43 Getting snapshot of cluster default/cluster-0
snapshot: 2020/06/15 15:43:43 Getting snapshot of controlPlane...
snapshot: 2020/06/15 15:43:43 Getting snapshot of kubectl command...
snapshot: 2020/06/15 15:43:46 Getting snapshot of control plane managed aws resources
...
snapshot: 2020/06/15 15:43:48 Getting snapshot of node pools
snapshot: 2020/06/15 15:43:48 Getting snapshot of node pool default/pool-0
snapshot: 2020/06/15 15:43:48 Getting snapshot of node pool managed aws resources
...
2020/06/15 15:44:00 Snapshot saved in snapshot-1592261012.tar.gz.
Snapshot-Konfiguration ändern
Wenn Sie die Standardkonfiguration von Snapshots ändern möchten, verwenden Sie zuerst anthos-gke
mit der Option --dry-run
und speichern Sie die Ausgabe in einer Datei. Bearbeiten Sie dann Ihre Konfiguration und führen Sie anthos-gke
mit der neuen Konfiguration noch einmal aus.
Konfigurationsdatei für den Verwaltungsdienst erstellen
Verwenden Sie
anthos-gke
mit der Option--dry-run
und leiten Sie die Ausgabe an eine Datei namens management-config.yaml weiter.env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws management diagnose snapshot --ssh-key-path ssh-key-path \ --workspace workspace --dry-run > management-config.yaml 2>&1
Ersetzen Sie:
- ssh-key-path durch den Pfad zu Ihrem Anthos Clusters on AWS-SSH-Schlüssel.
Standardmäßig wird die Datei unter
~/.ssh/anthos-gke
erstellt. - workspace durch den Pfad zum Verzeichnis, in dem Sie Ihre Anthos Clusters on AWS-Bereitstellung erstellt haben.
- ssh-key-path durch den Pfad zu Ihrem Anthos Clusters on AWS-SSH-Schlüssel.
Standardmäßig wird die Datei unter
Bearbeiten Sie die Datei
management-config.yaml
in einem Texteditor. Die Datei enthält zwei Abschnitte. Der erste Abschnitt ist ein mit Zeitstempel versehenes Log vonanthos-gke
, das in etwa so aussieht:2020/06/15 15:26:51 Found bastion instance in tfworkspace. IP: bastion-ip.aws-zone.compute.amazonaws.com 2020/06/15 15:26:51 Running in dry-run mode... ...
Löschen Sie den Logabschnitt. Behalten Sie die Konfiguration nach der Zeile
The snapshot configuration is:
bei.Der verbleibende Inhalt der Datei ist eine YAML-Konfiguration, die in etwa so aussieht:
mgmtCluster:
instanceCommands:
- dmesg
- sudo crictl ps a
- systemctl status -l containerd
- journalctl --since '1 hour ago' --utc -u containerd
- systemctl status -l kubelet
- journalctl --since '1 hour ago' --utc -u kubelet
- journalctl --since '1 hour ago' --utc --boot --dmesg
- uptime
- df --all --inodes
- ip addr
- sudo iptables-save --counters
- mount
- ip route list table all
- top -bn1
- ps -edF
- ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
- chronyc sources -v
- journalctl --since '1 hour ago' --utc -u chrony
instanceFiles:
- /etc/kubernetes/manifests/
- /proc/sys/fs/file-nr
- /proc/sys/net/nf_conntrack_max
- /var/log/startup.log
- /var/log/cloud-init-output.log
- /var/log/containers
kubectlCommands:
- commands:
- kubectl get events
- kubectl version
- kubectl cluster-info
- kubectl get clusterroles -o wide
- kubectl get clusterrolebindings -o wide
- kubectl get crd -o wide
- kubectl describe clusterroles
- kubectl describe clusterrolebindings
- kubectl describe crd
- kubectl get all -o yaml
- kubectl describe all
managedAWSResources: true
numOfThreads: 10
truncate: 2000
Entfernen Sie alle Befehle, die Ihrer Meinung nach vertrauliche Daten preisgeben.
Führen Sie den Befehl
anthos-gke
mit der Option--snapshot-config
undmanagement-config.yaml
aus.env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws management diagnose snapshot --ssh-key-path ssh-key-path \ --snapshot-config management-config.yaml --workspace terraform-workspace
Ersetzen Sie:
- ssh-key-path durch den Pfad zu Ihrem Anthos Clusters on AWS-SSH-Schlüssel.
Standardmäßig wird die Datei unter
.ssh/anthos-gke
erstellt. - terraform-workspace durch den Pfad zum Terraform-Arbeitsbereich, in dem Sie Ihre Anthos Clusters on AWS-Bereitstellung erstellt haben.
- ssh-key-path durch den Pfad zu Ihrem Anthos Clusters on AWS-SSH-Schlüssel.
Standardmäßig wird die Datei unter
Konfigurationsdatei für einen Nutzercluster erstellen
Verwenden Sie
anthos-gke
mit der Option--dry-run
und leiten Sie die Ausgabe an eine Datei mit dem Namen "user-config.yaml" weiter.env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters diagnose snapshot user-cluster-name \ --ssh-key-path ssh-key-path --snapshot-config snapshot-config-path \ --workspace workspace --dry-run > user-config.yaml 2>&1
Ersetzen Sie:
- user-cluster-name ist der Name Ihres Nutzerclusters. Standardmäßig erhält der erste Cluster den Namen
cluster-0
. - ssh-key-path durch den Pfad zu Ihrem Anthos Clusters on AWS-SSH-Schlüssel.
Standardmäßig wird die Datei unter
~/.ssh/anthos-gke
erstellt. - workspace durch den Pfad zum Verzeichnis, in dem Sie Ihre Anthos Clusters on AWS-Bereitstellung erstellt haben.
- user-cluster-name ist der Name Ihres Nutzerclusters. Standardmäßig erhält der erste Cluster den Namen
Bearbeiten Sie die Datei
management-config.yaml
in einem Texteditor. Die Datei enthält zwei Abschnitte. Der erste Abschnitt ist ein mit Zeitstempel versehenes Log vonanthos-gke
, das in etwa so aussieht:2020/06/15 15:26:51 Found bastion instance in tfworkspace. IP: bastion-ip.aws-zone.compute.amazonaws.com 2020/06/15 15:26:51 Running in dry-run mode... ...
Löschen Sie den Logabschnitt. Behalten Sie die Konfiguration nach der Zeile
The snapshot configuration is:
bei.Der verbleibende Inhalt der Datei ist eine YAML-Konfiguration, die in etwa so aussieht:
clusters:
- clusterName: cluster-0
controlPlane:
instanceCommands:
- dmesg
- sudo crictl ps a
- systemctl status -l containerd
- journalctl --since '1 hour ago' --utc -u containerd
- systemctl status -l kubelet
- journalctl --since '1 hour ago' --utc -u kubelet
- journalctl --since '1 hour ago' --utc --boot --dmesg
- 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
instanceFiles:
- /etc/kubernetes/manifests/
- /proc/sys/fs/file-nr
- /proc/sys/net/nf_conntrack_max
- /var/log/startup.log
- /var/log/cloud-init-output.log
- /var/log/containers
kubectlCommands:
- commands:
- kubectl get events
- kubectl version
- kubectl cluster-info
- kubectl get clusterroles -o wide
- kubectl get clusterrolebindings -o wide
- kubectl get crd -o wide
- kubectl describe clusterroles
- kubectl describe clusterrolebindings
- kubectl describe crd
- kubectl get all -o yaml
- kubectl describe all
- kubectl logs --namespace=kube-system -l k8s-app=aws-ebs-csi-driver-node --all-containers
- kubectl logs --namespace=kube-system -l k8s-app=aws-efs-csi-driver-node --all-containers
- kubectl logs --namespace=kube-system -l k8s-app=calico-node --all-containers
- kubectl logs --namespace=kube-system -l k8s-app=node-local-dns --all-containers
- kubectl logs --namespace=kube-system -l k8s-app=kube-proxy --all-containers
- kubectl describe nodes
managedAWSResources: true
nodePools:
- NodePoolName: ""
instanceCommands:
- dmesg
- sudo crictl ps a
- systemctl status -l containerd
- journalctl --since '1 hour ago' --utc -u containerd
- systemctl status -l kubelet
- journalctl --since '1 hour ago' --utc -u kubelet
- journalctl --since '1 hour ago' --utc --boot --dmesg
- 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
instanceFiles:
- /etc/kubernetes/manifests/
- /proc/sys/fs/file-nr
- /proc/sys/net/nf_conntrack_max
- /var/log/startup.log
- /var/log/cloud-init-output.log
- /var/log/containers
managedAWSResources: true
mgmtCluster:
kubectlCommands:
- commands:
- kubectl get awscluster -oyaml
numOfThreads: 10
truncate: 2000
Entfernen Sie alle Befehle, die Ihrer Meinung nach vertrauliche Daten preisgeben.
Führen Sie den Befehl
anthos-gke
mit der Option--snapshot-config
unduser-config.yaml
aus.env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters diagnose snapshot user-cluster-name --ssh-key-path <ssh-key-path> \ --snapshot-config user-config.yaml --workspace <terraform-workspace>
Ersetzen Sie:
- user-cluster-name ist der Name Ihres Nutzerclusters. Standardmäßig erhält der erste Cluster den Namen
cluster-0
. - ssh-key-path durch den Pfad zu Ihrem Anthos Clusters on AWS-SSH-Schlüssel.
Standardmäßig wird die Datei unter
.ssh/anthos-gke
erstellt. - terraform-workspace durch den Pfad zum Terraform-Arbeitsbereich, in dem Sie Ihre Anthos Clusters on AWS-Bereitstellung erstellt haben.
- user-cluster-name ist der Name Ihres Nutzerclusters. Standardmäßig erhält der erste Cluster den Namen
Standardinhalt des Snapshots
Einführung
Dieser Abschnitt zeigt Beispieldateistrukturen, die im Standard-Snapshot für einen Verwaltungsdienst und einen Nutzercluster enthalten sind.
Verwaltungsdienst
Die folgende Struktur ist ein Beispiel für die Dateien in einem Snapshot für einen Verwaltungscluster.
.
├── index.html
├── mgmt_cluster
│ ├── controlplane-0-10.0.1.44
│ │ └── ip-10-0-1-44
│ │ ├── commands
│ │ │ ├── df_--all_--inodes.out
│ │ │ ├── dmesg.out
│ │ │ ├── ip_addr.out
│ │ │ ├── ip_route_list_table_all.out
│ │ │ ├── journalctl_--since__1_hour_ago__--utc_--boot_--dmesg.out
│ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_containerd.out
│ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_kubelet.out
│ │ │ ├── mount.out
│ │ │ ├── ps_-edF.out
│ │ │ ├── ps_-eo_pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup.out
│ │ │ ├── sudo_crictl_ps_a.out
│ │ │ ├── sudo_docker_ps_-a.err
│ │ │ ├── sudo_docker_ps_-a.out
│ │ │ ├── sudo_iptables-save_--counters.out
│ │ │ ├── systemctl_status_-l_containerd.out
│ │ │ ├── systemctl_status_-l_kubelet.out
│ │ │ ├── top_-bn1.out
│ │ │ └── uptime.out
│ │ └── files
│ │ ├── etc
│ │ │ └── kubernetes
│ │ │ └── manifests
│ │ │ ├── etcd.yaml
│ │ │ ├── gke-aws-cluster-operator.yaml
│ │ │ ├── kube-apiserver.yaml
│ │ │ └── kube-controller-manager.yaml
│ │ ├── proc
│ │ │ └── sys
│ │ │ ├── fs
│ │ │ │ └── file-nr
│ │ │ └── net
│ │ │ └── nf_conntrack_max
│ │ └── var
│ │ └── log
│ │ ├── cloud-init-output.log
│ │ ├── containers
│ │ │ ├── etcd-ip-10-0-1-44.ap-southeast-2.compute.internal_kube-system_kube-etcd-149e96d0b0da2250505a6b41603e57f42a5386701fa0033840e8f3b211b49733.log
│ │ │ ├── gke-aws-cluster-operator-ip-10-0-1-44.ap-southeast-2.compute.internal_kube-system_gke-aws-cluster-operator-d423d3191ce1a8c65c4a0f30f1d7598a8739c0aba65784355b28dee0d694626a.log
│ │ │ ├── kube-apiserver-ip-10-0-1-44.ap-southeast-2.compute.internal_kube-system_kube-apiserver-48061659a4b77f4b50eed5819dbfab5586dc9086fa24217cc16486bd852dfbf6.log
│ │ │ ├── kube-apiserver-ip-10-0-1-44.ap-southeast-2.compute.internal_kube-system_kube-apiserver-baf60859cd807e9325295fde7a8d3cd16c3d5e73abca87acc107cee5e08f4c1c.log
│ │ │ └── kube-controller-manager-ip-10-0-1-44.ap-southeast-2.compute.internal_kube-system_kube-controller-manager-af9b4ffb40ada3383630090948ec8133ca0e3e54c232dd3f068b3bd8bbee8f92.log
│ │ └── startup.log
│ ├── kubectl
│ │ ├── kubectl_cluster-info_--kubeconfig_.tmp.kubeconfig-mgmt609381529.kubeconfig.conf.out
│ │ ├── kubectl_describe_all_--kubeconfig_.tmp.kubeconfig-mgmt609381529.kubeconfig.conf.out
│ │ ├── kubectl_describe_clusterrolebindings_--kubeconfig_.tmp.kubeconfig-mgmt609381529.kubeconfig.conf.out
│ │ ├── kubectl_describe_clusterroles_--kubeconfig_.tmp.kubeconfig-mgmt609381529.kubeconfig.conf.out
│ │ ├── kubectl_describe_crd_--kubeconfig_.tmp.kubeconfig-mgmt609381529.kubeconfig.conf.out
│ │ ├── kubectl_get_all_-o_yaml_--kubeconfig_.tmp.kubeconfig-mgmt609381529.kubeconfig.conf.out
│ │ ├── kubectl_get_clusterrolebindings_-o_wide_--kubeconfig_.tmp.kubeconfig-mgmt609381529.kubeconfig.conf.out
│ │ ├── kubectl_get_clusterroles_-o_wide_--kubeconfig_.tmp.kubeconfig-mgmt609381529.kubeconfig.conf.out
│ │ ├── kubectl_get_crd_-o_wide_--kubeconfig_.tmp.kubeconfig-mgmt609381529.kubeconfig.conf.out
│ │ ├── kubectl_get_events_--kubeconfig_.tmp.kubeconfig-mgmt609381529.kubeconfig.conf.out
│ │ └── kubectl_version_--kubeconfig_.tmp.kubeconfig-mgmt609381529.kubeconfig.conf.out
│ └── managed_resources
│ ├── controlplane-0
│ │ ├── asg.out
│ │ └── instance-0.out
│ ├── elb.out
│ └── target_group.out
├── snapshot.config
└── snapshot.log
Nutzercluster
Die folgende Struktur ist ein Beispiel für die Dateien in einem Snapshot für einen Nutzercluster namens cluster-0
.
.
├── cluster
│ └── cluster-0
│ ├── control_plane
│ │ ├── controlplane-0-10.0.1.7
│ │ │ └── ip-10-0-1-7
│ │ │ ├── commands
│ │ │ │ ├── df_--all_--inodes.out
│ │ │ │ ├── dmesg.out
│ │ │ │ ├── ip_addr.out
│ │ │ │ ├── ip_route_list_table_all.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_--boot_--dmesg.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_containerd.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_kubelet.out
│ │ │ │ ├── mount.out
│ │ │ │ ├── ps_-edF.out
│ │ │ │ ├── ps_-eo_pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup.out
│ │ │ │ ├── sudo_crictl_ps_a.out
│ │ │ │ ├── sudo_docker_ps_-a.err
│ │ │ │ ├── sudo_docker_ps_-a.out
│ │ │ │ ├── sudo_iptables-save_--counters.out
│ │ │ │ ├── systemctl_status_-l_containerd.out
│ │ │ │ ├── systemctl_status_-l_kubelet.out
│ │ │ │ ├── top_-bn1.out
│ │ │ │ └── uptime.out
│ │ │ └── files
│ │ │ ├── etc
│ │ │ │ └── kubernetes
│ │ │ │ └── manifests
│ │ │ │ ├── aws-ebs-csi-driver-controller.yaml
│ │ │ │ ├── aws-encryption-provider.yaml
│ │ │ │ ├── cluster-autoscaler.yaml
│ │ │ │ ├── etcd-events.yaml
│ │ │ │ ├── etcd.yaml
│ │ │ │ ├── kube-apiserver.yaml
│ │ │ │ ├── kube-controller-manager.yaml
│ │ │ │ └── kube-scheduler.yaml
│ │ │ ├── proc
│ │ │ │ └── sys
│ │ │ │ ├── fs
│ │ │ │ │ └── file-nr
│ │ │ │ └── net
│ │ │ │ └── nf_conntrack_max
│ │ │ └── var
│ │ │ └── log
│ │ │ ├── cloud-init-output.log
│ │ │ ├── containers
│ │ │ │ ├── aws-ebs-csi-driver-controller-ip-10-0-1-7.ap-southeast-2.compute.internal_kube-system_csi-attacher-218b7834cda8b4ae0f6687e06b33426ca39669a6c2652948e17746d49ed4c7c9.log
│ │ │ │ ├── aws-ebs-csi-driver-controller-ip-10-0-1-7.ap-southeast-2.compute.internal_kube-system_csi-provisioner-ff1ba1960712a00065db1e036e1aaf5aeaca0979c833d020ad1cafdea05a76c7.log
│ │ │ │ ├── aws-ebs-csi-driver-controller-ip-10-0-1-7.ap-southeast-2.compute.internal_kube-system_ebs-plugin-697389a6c73bdb4a0370a644a28617b3b8a12862341b91ca2d640aa66724affd.log
│ │ │ │ ├── aws-encryption-provider-ip-10-0-1-7.ap-southeast-2.compute.internal_kube-system_aws-encryption-provider-b08216cbca004f71e68145b9a38b931276dd9ef92d26c53b85275587ce28f3ca.log
│ │ │ │ ├── cluster-autoscaler-ip-10-0-1-7.ap-southeast-2.compute.internal_kube-system_cluster-autoscaler-57f9ca6abec10a76b42449dababea6c963853b1aa30f1db2b87d963311d03629.log
│ │ │ │ ├── cluster-autoscaler-ip-10-0-1-7.ap-southeast-2.compute.internal_kube-system_cluster-autoscaler-9c09937ddbe3220c896f857a8b8c02c84062f13092b39ebac3ab1ce26f13b317.log
│ │ │ │ ├── etcd-events-ip-10-0-1-7.ap-southeast-2.compute.internal_kube-system_kube-etcd-events-4e79334e69f670a3a4637c20635944abb71ed93d6e802407ef5881478ee78dc1.log
│ │ │ │ ├── etcd-ip-10-0-1-7.ap-southeast-2.compute.internal_kube-system_kube-etcd-e6dbe39ef969fb2f049292d4f3a66a41d22f963b40f72f5f91ad6acd9e9cde77.log
│ │ │ │ ├── kube-apiserver-ip-10-0-1-7.ap-southeast-2.compute.internal_kube-system_kube-apiserver-e61770a46518313306e1668c34e4efbdb3ed81b7f451dc3278a00a40fee09e0d.log
│ │ │ │ ├── kube-controller-manager-ip-10-0-1-7.ap-southeast-2.compute.internal_kube-system_kube-controller-manager-3b33df6a4d4cca8fd63f90d4fcbee65595e71c0390a5c29c81670d0232b98edc.log
│ │ │ │ └── kube-scheduler-ip-10-0-1-7.ap-southeast-2.compute.internal_kube-system_kube-scheduler-0aae214e17741189db8d3608275e71551f62f43619e07a37a11017b88a611970.log
│ │ │ └── startup.log
│ │ ├── controlplane-1-10.0.1.61
│ │ │ └── ip-10-0-1-61
│ │ │ ├── commands
│ │ │ │ ├── df_--all_--inodes.out
│ │ │ │ ├── dmesg.out
│ │ │ │ ├── ip_addr.out
│ │ │ │ ├── ip_route_list_table_all.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_--boot_--dmesg.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_containerd.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_kubelet.out
│ │ │ │ ├── mount.out
│ │ │ │ ├── ps_-edF.out
│ │ │ │ ├── ps_-eo_pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup.out
│ │ │ │ ├── sudo_crictl_ps_a.out
│ │ │ │ ├── sudo_docker_ps_-a.err
│ │ │ │ ├── sudo_docker_ps_-a.out
│ │ │ │ ├── sudo_iptables-save_--counters.out
│ │ │ │ ├── systemctl_status_-l_containerd.out
│ │ │ │ ├── systemctl_status_-l_kubelet.out
│ │ │ │ ├── top_-bn1.out
│ │ │ │ └── uptime.out
│ │ │ └── files
│ │ │ ├── etc
│ │ │ │ └── kubernetes
│ │ │ │ └── manifests
│ │ │ │ ├── aws-ebs-csi-driver-controller.yaml
│ │ │ │ ├── aws-encryption-provider.yaml
│ │ │ │ ├── cluster-autoscaler.yaml
│ │ │ │ ├── etcd-events.yaml
│ │ │ │ ├── etcd.yaml
│ │ │ │ ├── kube-apiserver.yaml
│ │ │ │ ├── kube-controller-manager.yaml
│ │ │ │ └── kube-scheduler.yaml
│ │ │ ├── proc
│ │ │ │ └── sys
│ │ │ │ ├── fs
│ │ │ │ │ └── file-nr
│ │ │ │ └── net
│ │ │ │ └── nf_conntrack_max
│ │ │ └── var
│ │ │ └── log
│ │ │ ├── cloud-init-output.log
│ │ │ ├── containers
│ │ │ │ ├── aws-ebs-csi-driver-controller-ip-10-0-1-61.ap-southeast-2.compute.internal_kube-system_csi-attacher-63345efd65ea584c35f4b0d2de443bf42e83e65324e899be27335a25fe07a72c.log
│ │ │ │ ├── aws-ebs-csi-driver-controller-ip-10-0-1-61.ap-southeast-2.compute.internal_kube-system_csi-provisioner-6f66e7479c319fbcbcaf53f9b5398cd8e53bcd646fa9788afbc25a69fc9291fe.log
│ │ │ │ ├── aws-ebs-csi-driver-controller-ip-10-0-1-61.ap-southeast-2.compute.internal_kube-system_ebs-plugin-2ee649206dd099e29b8bb3cbf27bef499b851682c07590a34c2e08d9545ca51b.log
│ │ │ │ ├── aws-encryption-provider-ip-10-0-1-61.ap-southeast-2.compute.internal_kube-system_aws-encryption-provider-3d2b5c28b7389e1303d2e36dd510ec40cef99f2ea63823901ea9806869def8fa.log
│ │ │ │ ├── cluster-autoscaler-ip-10-0-1-61.ap-southeast-2.compute.internal_kube-system_cluster-autoscaler-ebc572523516845d023884810f721865c2f0a76e34aaf92babdffacf4c95f75b.log
│ │ │ │ ├── cluster-autoscaler-ip-10-0-1-61.ap-southeast-2.compute.internal_kube-system_cluster-autoscaler-f7a7480c9adb08077b9a07d2f14e2b14dda7b4d50027cf105d90f37c63945bfa.log
│ │ │ │ ├── etcd-events-ip-10-0-1-61.ap-southeast-2.compute.internal_kube-system_kube-etcd-events-60301eef32b7c10d0aea3de19549bfdcc3e4152cf3ca8ca7d5e10785e2e232fd.log
│ │ │ │ ├── etcd-ip-10-0-1-61.ap-southeast-2.compute.internal_kube-system_kube-etcd-25a369f08d0d2bbc9f8f83337724e14c9878a1a0249cc5e9c7c63cae3d3657a1.log
│ │ │ │ ├── kube-apiserver-ip-10-0-1-61.ap-southeast-2.compute.internal_kube-system_kube-apiserver-13a276422964d2674f16d971bafcd25555eee3eb10b6a6f60686e8b8810a5def.log
│ │ │ │ ├── kube-controller-manager-ip-10-0-1-61.ap-southeast-2.compute.internal_kube-system_kube-controller-manager-18625e69e9604fbacbe82aebc6dc18dd4427269941a25a9bdef3fc0e5a4dfb9e.log
│ │ │ │ └── kube-scheduler-ip-10-0-1-61.ap-southeast-2.compute.internal_kube-system_kube-scheduler-12f48aad99ecc18b450ebcda85ffb7f138bbb6bc261fb06e75ae1548647eaa45.log
│ │ │ └── startup.log
│ │ ├── controlplane-2-10.0.1.161
│ │ │ └── ip-10-0-1-161
│ │ │ ├── commands
│ │ │ │ ├── df_--all_--inodes.out
│ │ │ │ ├── dmesg.out
│ │ │ │ ├── ip_addr.out
│ │ │ │ ├── ip_route_list_table_all.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_--boot_--dmesg.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_containerd.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_kubelet.out
│ │ │ │ ├── mount.out
│ │ │ │ ├── ps_-edF.out
│ │ │ │ ├── ps_-eo_pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup.out
│ │ │ │ ├── sudo_crictl_ps_a.out
│ │ │ │ ├── sudo_docker_ps_-a.err
│ │ │ │ ├── sudo_docker_ps_-a.out
│ │ │ │ ├── sudo_iptables-save_--counters.out
│ │ │ │ ├── systemctl_status_-l_containerd.out
│ │ │ │ ├── systemctl_status_-l_kubelet.out
│ │ │ │ ├── top_-bn1.out
│ │ │ │ └── uptime.out
│ │ │ └── files
│ │ │ ├── etc
│ │ │ │ └── kubernetes
│ │ │ │ └── manifests
│ │ │ │ ├── aws-ebs-csi-driver-controller.yaml
│ │ │ │ ├── aws-encryption-provider.yaml
│ │ │ │ ├── cluster-autoscaler.yaml
│ │ │ │ ├── etcd-events.yaml
│ │ │ │ ├── etcd.yaml
│ │ │ │ ├── kube-apiserver.yaml
│ │ │ │ ├── kube-controller-manager.yaml
│ │ │ │ └── kube-scheduler.yaml
│ │ │ ├── proc
│ │ │ │ └── sys
│ │ │ │ ├── fs
│ │ │ │ │ └── file-nr
│ │ │ │ └── net
│ │ │ │ └── nf_conntrack_max
│ │ │ └── var
│ │ │ └── log
│ │ │ ├── cloud-init-output.log
│ │ │ ├── containers
│ │ │ │ ├── aws-ebs-csi-driver-controller-ip-10-0-1-161.ap-southeast-2.compute.internal_kube-system_csi-attacher-0d66d0e6d7ead9a0af3ee2b9ea7769669a33636639549571ed10eaacf7ddd85b.log
│ │ │ │ ├── aws-ebs-csi-driver-controller-ip-10-0-1-161.ap-southeast-2.compute.internal_kube-system_csi-provisioner-c68d3acbdf8f319fe1d700eb3584fd07016d7a8b507e05261b1596fb96ca7598.log
│ │ │ │ ├── aws-ebs-csi-driver-controller-ip-10-0-1-161.ap-southeast-2.compute.internal_kube-system_ebs-plugin-66c248fc6c21021355ad5aa20ec98894b3370d1b58d86d3bf4b794bfb971eaef.log
│ │ │ │ ├── aws-encryption-provider-ip-10-0-1-161.ap-southeast-2.compute.internal_kube-system_aws-encryption-provider-f79e0367f399331652f7beb9145e97eefe95a635a3101ffb73bb8c29d449304e.log
│ │ │ │ ├── cluster-autoscaler-ip-10-0-1-161.ap-southeast-2.compute.internal_kube-system_cluster-autoscaler-4ce584e9f04e3c545168a01a84b4a697a199e4ff536477d8cb884f89ab65872c.log
│ │ │ │ ├── cluster-autoscaler-ip-10-0-1-161.ap-southeast-2.compute.internal_kube-system_cluster-autoscaler-a384f6202e6b7f0a3d5918adc87a8acf158a4e5d13401825a129188663cf32d7.log
│ │ │ │ ├── etcd-events-ip-10-0-1-161.ap-southeast-2.compute.internal_kube-system_kube-etcd-events-4975f4f7ea692237be1016e2c03e024ca58cc78745b482ca41fe80481c425f28.log
│ │ │ │ ├── etcd-ip-10-0-1-161.ap-southeast-2.compute.internal_kube-system_kube-etcd-92a56adf23ce887f032335ccc2ebd48e39de6ddd600302fe985d3b088e8d4eea.log
│ │ │ │ ├── kube-apiserver-ip-10-0-1-161.ap-southeast-2.compute.internal_kube-system_kube-apiserver-76551958905114e0eaa056c0e3eb7cc0af7d9f6291af9efe49bbab95250500ce.log
│ │ │ │ ├── kube-controller-manager-ip-10-0-1-161.ap-southeast-2.compute.internal_kube-system_kube-controller-manager-d50c38a03f5e01ca438508db11091e9421fa8eb7231f484303a350a7b0538439.log
│ │ │ │ └── kube-scheduler-ip-10-0-1-161.ap-southeast-2.compute.internal_kube-system_kube-scheduler-7ebaccccbf67c06d379b1541f1970e4e987de138556542469cc24aacea1c9213.log
│ │ │ └── startup.log
│ │ ├── kubectl
│ │ │ ├── kubectl_cluster-info_--kubeconfig_.tmp.kubeconfig-clustercluster-0904143419.kubeconfig.conf.out
│ │ │ ├── kubectl_describe_all_--kubeconfig_.tmp.kubeconfig-clustercluster-0904143419.kubeconfig.conf.out
│ │ │ ├── kubectl_describe_clusterrolebindings_--kubeconfig_.tmp.kubeconfig-clustercluster-0904143419.kubeconfig.conf.out
│ │ │ ├── kubectl_describe_clusterroles_--kubeconfig_.tmp.kubeconfig-clustercluster-0904143419.kubeconfig.conf.out
│ │ │ ├── kubectl_describe_crd_--kubeconfig_.tmp.kubeconfig-clustercluster-0904143419.kubeconfig.conf.out
│ │ │ ├── kubectl_get_all_-o_yaml_--kubeconfig_.tmp.kubeconfig-clustercluster-0904143419.kubeconfig.conf.out
│ │ │ ├── kubectl_get_clusterrolebindings_-o_wide_--kubeconfig_.tmp.kubeconfig-clustercluster-0904143419.kubeconfig.conf.out
│ │ │ ├── kubectl_get_clusterroles_-o_wide_--kubeconfig_.tmp.kubeconfig-clustercluster-0904143419.kubeconfig.conf.out
│ │ │ ├── kubectl_get_crd_-o_wide_--kubeconfig_.tmp.kubeconfig-clustercluster-0904143419.kubeconfig.conf.out
│ │ │ ├── kubectl_get_events_--kubeconfig_.tmp.kubeconfig-clustercluster-0904143419.kubeconfig.conf.out
│ │ │ └── kubectl_version_--kubeconfig_.tmp.kubeconfig-clustercluster-0904143419.kubeconfig.conf.out
│ │ └── managed_resources
│ │ ├── controlplane-0
│ │ │ ├── asg.out
│ │ │ ├── eni.out
│ │ │ ├── etcd.out
│ │ │ └── instance-0.out
│ │ ├── controlplane-1
│ │ │ ├── asg.out
│ │ │ ├── eni.out
│ │ │ ├── etcd.out
│ │ │ └── instance-0.out
│ │ ├── controlplane-2
│ │ │ ├── asg.out
│ │ │ ├── eni.out
│ │ │ ├── etcd.out
│ │ │ └── instance-0.out
│ │ ├── elb.out
│ │ └── target_group.out
│ └── nodepools
│ ├── default
│ │ └── pool-0
│ │ ├── i-03a23df438ac8278e
│ │ │ └── ip-10-0-1-53
│ │ │ ├── commands
│ │ │ │ ├── df_--all_--inodes.out
│ │ │ │ ├── dmesg.out
│ │ │ │ ├── ip_addr.out
│ │ │ │ ├── ip_route_list_table_all.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_--boot_--dmesg.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_containerd.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_kubelet.out
│ │ │ │ ├── mount.out
│ │ │ │ ├── ps_-edF.out
│ │ │ │ ├── ps_-eo_pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup.out
│ │ │ │ ├── sudo_crictl_ps_a.out
│ │ │ │ ├── sudo_docker_ps_-a.err
│ │ │ │ ├── sudo_docker_ps_-a.out
│ │ │ │ ├── sudo_iptables-save_--counters.out
│ │ │ │ ├── systemctl_status_-l_containerd.out
│ │ │ │ ├── systemctl_status_-l_kubelet.out
│ │ │ │ ├── top_-bn1.out
│ │ │ │ └── uptime.out
│ │ │ └── files
│ │ │ ├── proc
│ │ │ │ └── sys
│ │ │ │ ├── fs
│ │ │ │ │ └── file-nr
│ │ │ │ └── net
│ │ │ │ └── nf_conntrack_max
│ │ │ └── var
│ │ │ └── log
│ │ │ ├── cloud-init-output.log
│ │ │ ├── containers
│ │ │ │ ├── aws-ebs-csi-driver-node-mwxhs_kube-system_ebs-plugin-696201b4997d5cc72d85e6b005faa544ab2311571b50d2b1402b6e967a9364f0.log
│ │ │ │ ├── aws-ebs-csi-driver-node-mwxhs_kube-system_node-driver-registrar-fcde7a18980aee3c690a84953f44341df9755e28ada6a42a6aea4c1b9d6cdd8e.log
│ │ │ │ ├── calico-node-2g6zt_kube-system_calico-node-f6c22e30079cff40bef7deafbdfa2a97d0c3a4a95e7b68499c917adb1aa24b09.log
│ │ │ │ ├── calico-node-2g6zt_kube-system_flexvol-driver-9c6e02ad10d342a91e2c3c3d924f747cfab756e719ffc580c073c6e3640b7515.log
│ │ │ │ ├── calico-node-2g6zt_kube-system_install-cni-3649827b98cb5b2f79f8e9204b07247ca8d2768e4d13b1a8a1359278741ed156.log
│ │ │ │ ├── calico-node-2g6zt_kube-system_upgrade-ipam-3a2fe7afee90bfe4e09b0939300be89f4795bc7a57e8085a57cb714e015092f6.log
│ │ │ │ ├── coredns-88cd756b8-thm49_kube-system_coredns-6485d1e189c7b11fdc6249316ab6082360737c67edb77ab0d426eb26dba261ee.log
│ │ │ │ ├── gke-connect-agent-20200605-02-00-8647455579-jh2r2_gke-connect_gke-connect-agent-20200605-02-00-369a43ce1bccb57bf3abfd503b9b25c81dbcd73d60a8642b68c0bb89b1b8e9fd.log
│ │ │ │ └── kube-proxy-sg5nr_kube-system_kube-proxy-44f9171a644c8d7d0497900f361faa22fc673adc8336608ced096e655ccde762.log
│ │ │ └── startup.log
│ │ ├── i-0569a9f23d49f59ea
│ │ │ └── ip-10-0-1-137
│ │ │ ├── commands
│ │ │ │ ├── df_--all_--inodes.out
│ │ │ │ ├── dmesg.out
│ │ │ │ ├── ip_addr.out
│ │ │ │ ├── ip_route_list_table_all.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_--boot_--dmesg.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_containerd.out
│ │ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_kubelet.out
│ │ │ │ ├── mount.out
│ │ │ │ ├── ps_-edF.out
│ │ │ │ ├── ps_-eo_pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup.out
│ │ │ │ ├── sudo_crictl_ps_a.out
│ │ │ │ ├── sudo_docker_ps_-a.err
│ │ │ │ ├── sudo_docker_ps_-a.out
│ │ │ │ ├── sudo_iptables-save_--counters.out
│ │ │ │ ├── systemctl_status_-l_containerd.out
│ │ │ │ ├── systemctl_status_-l_kubelet.out
│ │ │ │ ├── top_-bn1.out
│ │ │ │ └── uptime.out
│ │ │ └── files
│ │ │ ├── proc
│ │ │ │ └── sys
│ │ │ │ ├── fs
│ │ │ │ │ └── file-nr
│ │ │ │ └── net
│ │ │ │ └── nf_conntrack_max
│ │ │ └── var
│ │ │ └── log
│ │ │ ├── cloud-init-output.log
│ │ │ ├── containers
│ │ │ │ ├── aws-ebs-csi-driver-node-zxxqg_kube-system_ebs-plugin-da9a84b2e45e2ad18d08cbab5260d4cee17636d868a645ab7343f50c25c64ece.log
│ │ │ │ ├── aws-ebs-csi-driver-node-zxxqg_kube-system_node-driver-registrar-f96a7dbf1bac95c41e022b2ede129c664caafa6eff37caa52f6763c1e737be1a.log
│ │ │ │ ├── calico-kube-controllers-56cd854695-mjfwx_kube-system_calico-kube-controllers-0ed4316450f5f2e6c4abfb5cc430ed18e2d530525e2ab0ed69a150eed5b3c860.log
│ │ │ │ ├── calico-node-n5klf_kube-system_calico-node-36101112d423636164c236eacca76d6814c167203cfaf89754984cd79f3b6bbf.log
│ │ │ │ ├── calico-node-n5klf_kube-system_flexvol-driver-5837e2ba75d549373ca0a3032d1be0c75c0dd442d2e25e286e9006e604794da2.log
│ │ │ │ ├── calico-node-n5klf_kube-system_install-cni-0e19cfa737dcaaf8fbc40ee2e68460ea8888829b7fab4b8733d5322c339cf838.log
│ │ │ │ ├── calico-node-n5klf_kube-system_upgrade-ipam-10c94c2fa5f67a69ad9ebeedf9764bbf566c99b50ef60f2f268d484bd028eb76.log
│ │ │ │ └── kube-proxy-pzh87_kube-system_kube-proxy-5df6d54f9ff2dd036687e064186bcfc2b7c0536fd88586b5cac9e140ffa16658.log
│ │ │ └── startup.log
│ │ └── i-05bfb8fc961337cc7
│ │ └── ip-10-0-1-167
│ │ ├── commands
│ │ │ ├── df_--all_--inodes.out
│ │ │ ├── dmesg.out
│ │ │ ├── ip_addr.out
│ │ │ ├── ip_route_list_table_all.out
│ │ │ ├── journalctl_--since__1_hour_ago__--utc_--boot_--dmesg.out
│ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_containerd.out
│ │ │ ├── journalctl_--since__1_hour_ago__--utc_-u_kubelet.out
│ │ │ ├── mount.out
│ │ │ ├── ps_-edF.out
│ │ │ ├── ps_-eo_pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup.out
│ │ │ ├── sudo_crictl_ps_a.out
│ │ │ ├── sudo_docker_ps_-a.err
│ │ │ ├── sudo_docker_ps_-a.out
│ │ │ ├── sudo_iptables-save_--counters.out
│ │ │ ├── systemctl_status_-l_containerd.out
│ │ │ ├── systemctl_status_-l_kubelet.out
│ │ │ ├── top_-bn1.out
│ │ │ └── uptime.out
│ │ └── files
│ │ ├── proc
│ │ │ └── sys
│ │ │ ├── fs
│ │ │ │ └── file-nr
│ │ │ └── net
│ │ │ └── nf_conntrack_max
│ │ └── var
│ │ └── log
│ │ ├── cloud-init-output.log
│ │ ├── containers
│ │ │ ├── aws-ebs-csi-driver-node-kdghk_kube-system_ebs-plugin-3e107a145cc86ac24014b1bf4670b26cb9372fd8022bc0698ca68b27e79a9bfe.log
│ │ │ ├── aws-ebs-csi-driver-node-kdghk_kube-system_node-driver-registrar-25874dd7063db875a27f170e13e74267749c0d9846781ac8ab7568ac5f940a11.log
│ │ │ ├── calico-node-b98tq_kube-system_calico-node-1dd735ce87fe6f0f73761d2d97c07ea6f908d0cd088e23f6b916b13b6805f828.log
│ │ │ ├── calico-node-b98tq_kube-system_flexvol-driver-e9951b1a3de0ed9426de260c5591b4c161b4917873f2eaaf1cbdbd3926c9f933.log
│ │ │ ├── calico-node-b98tq_kube-system_install-cni-58a2f1a5bfb16951a4b012b5ed30751d24c3380f489011274e3ca8de7eb1e1aa.log
│ │ │ ├── calico-node-b98tq_kube-system_upgrade-ipam-f9804f2eef0d18122219dbb2843880a392f55493dab0edc16bce2dc5e186fa2a.log
│ │ │ ├── kube-proxy-pf7sv_kube-system_kube-proxy-473ffafc30368b1cb370cd5cbbe4b20e77dfc383da04386d3ec02948f04bc97d.log
│ │ │ ├── metrics-server-v0.3.3-85dfcbb78-fmklb_kube-system_metrics-server-4570fa1bd82d238d0ab11fc4256e5cc9fa97accece05f7f0c02d5edab884468e.log
│ │ │ └── metrics-server-v0.3.3-85dfcbb78-fmklb_kube-system_metrics-server-nanny-71eeba81fb3cf128066ca965aabc5bfdf8e045790a46a9ec7e56e73ad3859218.log
│ │ └── startup.log
│ └── managed_resources
│ ├── asg.out
│ ├── instance-0.out
│ ├── instance-1.out
│ └── instance-2.out
├── index.html
├── mgmt_cluster
│ └── kubectl
│ └── kubectl_get_awscluster_-oyaml_--kubeconfig_.tmp.kubeconfig-mgmt786666316.kubeconfig.conf.out
├── snapshot.config
└── snapshot.log