arrow_back

从 Cloud Shell 部署 GKE Autopilot 集群

登录 加入
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

从 Cloud Shell 部署 GKE Autopilot 集群

Lab 1 小时 universal_currency_alt 1 个积分 show_chart 入门级
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

概览

在此实验中，您将使用命令行构建 GKE 集群。您还将检查 kubeconfig 文件，并使用 kubectl 对集群执行操作。

目标

在本实验中，您将学习如何执行以下任务：

  • 使用 kubectl 构建 GKE 集群并对其执行操作
  • 使用 kubectl 和配置文件来部署 Pod
  • 使用 Container Registry 来存储和部署容器

实验设置

访问 Qwiklabs

对于每个实验，您都会免费获得一个新的 Google Cloud 项目及一组资源，它们都有固定的使用时限。

  1. 请使用无痕式窗口登录 Qwiklabs。

  2. 留意实验的访问时限（例如 1:15:00）并确保能在相应时间段内完成实验。
    系统不提供暂停功能。如有需要，您可以重新开始实验，不过必须从头开始。

  3. 准备就绪时，点击开始实验。

  4. 请记好您的实验凭据（用户名和密码）。您需要使用这组凭据来登录 Google Cloud 控制台。

  5. 点击打开 Google 控制台。

  6. 点击使用其他帐号，然后将此实验的凭据复制并粘贴到相应提示框中。
    如果您使用其他凭据，将会收到错误消息或产生费用。

  7. 接受条款并跳过恢复资源页面。

完成初始登录步骤后，系统会显示项目信息中心。

项目信息中心标签页

打开 Cloud Shell

您将在 Cloud Shell 中完成大部分操作。Cloud Shell 是在 Google Cloud 中运行的一个命令行环境。这个基于 Debian 的虚拟机上已加载您需要的所有管理工具（例如 docker、gcloud、gsutil 和 kubectl），并提供永久性的 5 GB 主目录。

  1. 在 Google Cloud 控制台标题栏中，点击激活 Cloud Shell (“激活 Cloud Shell”图标)。
  2. 点击继续。

预配将快速完成，然后 Cloud Shell 中将显示提示：

Cloud Shell 中显示了以下提示消息：Welcome to Cloud Shell!Type "help" to get started.

任务 1. 部署 GKE 集群

在此任务中，您将使用 Cloud Shell 部署 GKE 集群。

  1. 在 Cloud Shell 中输入以下命令，为可用区和集群名称设置环境变量：
export my_region={{{project_0.default_region|Region}}} export my_cluster=autopilot-cluster-1
  1. 在 Cloud Shell 中，输入以下命令以创建 Kubernetes 集群：
gcloud container clusters create-auto $my_cluster --region $my_region

这种形式的命令会将大部分选项设置为其默认值。如需查看所有可能的选项，请参阅 gcloud container clusters create 参考文档。

您将看到多个警告，提醒您 GKE 已升级到更高的 Kubernetes 版本，默认 GKE 集群设置因此而发生了变化。

注意：您需要等待几分钟，让集群部署完成。

部署完成后，Google Cloud 控制台 Kubernetes Engine > 集群页面将如以下屏幕截图所示：

Kubernetes 集群页面，显示了 autopilot-cluster-1 的位置、集群大小、核心总数和内存总量等详细信息

点击检查我的进度以验证是否完成了以下目标。 部署 GKE 集群

任务 2. 连接到 GKE 集群

在此任务中，您将使用 Cloud Shell 向 GKE 集群进行身份验证，然后检查 kubectl 配置文件。

通过在主实例上运行的 kube-APIserver 从外部客户端与集群通信时，或者集群容器与集群内部或外部通信时，都需要进行 Kubernetes 身份验证。

在 Kubernetes 中，身份验证可以有多种形式。对于 GKE，身份验证一般用 OAuth2 令牌处理，并通过 Cloud Identity and Access Management 在项目级别进行管理；或者通过“基于角色的访问控制”进行管理，可在每个集群中分别定义和配置。

在 GKE 中，集群容器可使用服务账号向外部资源进行身份验证，并访问这些外部资源。

注意：在早于 1.12 的 Kubernetes 版本中，默认情况下未停用客户端证书和基本身份验证。这两种身份验证方法的安全性较低，应该停用以提升集群安全性。（对于版本 1.12 及更高版本，这两个方法都已默认停用。）
  1. 若要使用当前用户的凭据创建 kubeconfig 文件（以允许身份验证），并提供特定集群的端点详细信息（以允许通过 kubectl 命令行工具与集群通信），请执行以下命令：
gcloud container clusters get-credentials $my_cluster --region $my_region

如果您的主目录中还没有 .kube 目录，此命令将会创建。如果 .kube 目录中还没有名为 config 的文件，此命令将会创建，用于存储身份验证和配置信息。该 config 文件一般称为 kubeconfig 文件。

  1. 用 nano 文本编辑器打开 kubeconfig 文件。
nano ~/.kube/config

您现在可以检查存储在该文件中的所有身份验证和端点配置数据。您应该会看到该集群的相关信息。这些信息是在集群创建期间填充的。

  1. 按 CTRL+X 组合键，退出 nano 编辑器。
注意：kubeconfig 文件可包含多个集群的信息。当前活跃上下文（kubectl 命令操作的集群）由 current-context 属性指示。

对于在同一上下文（同一环境中的同一用户）中创建的集群，您不需要运行 gcloud container clusters get-credentials 命令来填充 kubeconfig 文件，因为在创建这些集群时已填充其详细信息。

但若要连接到由其他用户创建或在其他环境中创建的集群，则必须运行该命令。该命令也是将活跃上下文切换为其他集群的一种简单方式。

任务 3. 使用 kubectl 检查 GKE 集群

在此任务中，您将使用 Cloud Shell 和 kubectl 来检查 GKE 集群。

填充 kubeconfig 文件并将活跃上下文设置为特定集群后，可以使用 kubectl 命令行工具来针对该集群执行命令。此类命令最终大都会触发针对主 API 服务器的 REST API 调用，进而触发相关操作。

  1. 在 Cloud Shell 中执行以下命令，以显示 kubeconfig 文件的内容：
kubectl config view

敏感证书数据已替换为 DATA+OMITTED。

  1. 在 Cloud Shell 中执行以下命令，以显示活跃上下文的集群信息：
kubectl cluster-info

输出内容将描述活跃上下文集群。

输出：

Kubernetes control plane is running at https://34.133.211.75 GLBCDefaultBackend is running at https://34.133.211.75/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy KubeDNS is running at https://34.133.211.75/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy KubeDNSUpstream is running at https://34.133.211.75/api/v1/namespaces/kube-system/services/kube-dns-upstream:dns/proxy Metrics-server is running at https://34.133.211.75/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy 若要进一步调试和诊断集群问题，请使用“kubectl cluster-info dump”。
  1. 在 Cloud Shell 中执行以下命令，以显示活跃上下文：
kubectl config current-context

您将看到一行输出内容，其中指明了活跃上下文集群。

输出：

gke_{{{project_0.project_id|Project_ID}}}_{{{project_0.default_region|Region}}}_autopilot-cluster-1

PROJECT_ID 是您的项目 ID。此信息与 kubeconfig 文件 current-context 属性中的信息相同。

  1. 在 Cloud Shell 中执行以下命令，以显示 kubeconfig 文件中所有集群上下文的部分详细信息。
kubectl config get-contexts

您将看到几行输出内容，其中提供了您所创建集群的相关详细信息，并指明了哪一个是活跃上下文集群。一般来说，此命令会列出用户 kubeconfig 文件中的集群的一些详细信息，这些集群包括由该用户创建的任何其他集群，以及手动添加到 kubeconfig 文件的任何其他集群。

  1. 在 Cloud Shell 中执行以下命令，以更改活跃上下文：
kubectl config use-context gke_${DEVSHELL_PROJECT_ID}_{{{project_0.default_region|Region}}}_autopilot-cluster-1

在本例中，您只有一个集群，所以此命令并未做任何更改。

但在将来，您可能在一个项目中拥有多个集群。如果您的 kubeconfig 文件包含多个集群的凭据和配置，您可以使用这种方法来切换活跃上下文。这种方法需要集群的全名，包括 gke 前缀、项目 ID、位置和显示名称，它们都用下划线串联在一起。

  1. 在 Cloud Shell 中执行以下命令，以启用 kubectl 的 bash 自动补全功能：
source <(kubectl completion bash)

此命令没有任何输出。

  1. 在 Cloud Shell 中，输入 kubectl 后跟空格，并按两次 Tab 键。

shell 将输出所有可能的命令：

Cloud Shell 显示所有可能的命令

  1. 在 Cloud Shell 中，输入 kubectl co 并按两次 Tab 键。

shell 将输出以“co”（或者您输入的任何其他文本）开头的所有命令。

Cloud Shell 显示以 co 开头的所有命令，例如 completion、convert、config 和 cordon

任务 4. 将 Pod 部署到 GKE 集群

在此任务中，您将使用 Cloud Shell 将 Pod 部署到 GKE 集群。

使用 kubectl 将 Pod 部署到 GKE

Kubernetes 引入了 Pod 的抽象概念，将一个或多个相关容器组合为单个实体，以便作为一个单元在同一节点上调度和部署。您可以部署由基于单个容器映像的单个容器构成的 Pod。一个 Pod 也可包含基于多个容器映像的多个容器。

  1. 在 Cloud Shell 中执行以下命令，以将 nginx 部署为一个名为 nginx-1 的 Pod：
kubectl create deployment --image nginx nginx-1

此命令将创建一个名为 nginx-1 的 Pod，其中包含一个运行 nginx 映像的容器。如果未指定仓库，默认行为是尝试在本地或 Docker 公共注册表中查找该映像。在本例中，该映像拉取自 Docker 公共注册表。

  1. 在 Cloud Shell 中执行以下命令，以查看活跃上下文集群中已部署的所有 Pod：
kubectl get pods

输出内容应如下例所示，但 Pod 名称略有不同。

注意：如果您看到一条消息，指出服务器目前无法处理请求，请等待部署完成并准备就绪。

输出：

NAME READY STATUS RESTARTS AGE nginx-1-74c7bbdb84-nvwsc 1/1 Running 0 2m52s
  1. 在 Cloud Shell 中执行以下命令，以查看集群各节点的资源使用情况：
kubectl top nodes

输出内容应如下例所示。

输出：

NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% gk3-autopilot-cluster-1-pool-2-7246ae0e-4q7s 1971m 102% 1803Mi 30%

另一个 top 命令 (kubectl top pods) 会显示集群中所有已部署的 Pod 的类似信息。

  1. 现在，您要将此 Pod 名称输入到一个变量中，我们在这个实验中将一直使用该变量。使用这样的变量有助于尽量减少输入长名称时的人为错误。您必须输入 Pod 的唯一名称来代替 [your_pod_name]：
export my_nginx_pod=[your_pod_name]

示例：

export my_nginx_pod=nginx-1-74c7bbdb84-nvwsc
  1. 让 shell 回显这个值，以确认您已成功设置此环境变量：
echo $my_nginx_pod

输出：

nginx-1-74c7bbdb84-nvwsc
  1. 在 Cloud Shell 中执行以下命令，以查看您刚刚创建的 Pod 的完整详细信息：
kubectl describe pod $my_nginx_pod

输出内容应如下例所示。屏幕上会显示 Pod 的详细信息及其状态和使用情况，以及其生命周期中的事件。

输出：

Image: nginx Image: nginx Image: nginx Image ID: docker.io/library/nginx@sha256:480868e8c8c797794257e2abd88d0f9a8809b2fe956cbfbc05dcc0bca1f7cd43 Port: Host Port: State: Running Started: Wed, 17 May 2023 10:47:04 +0000 Ready: True Restart Count: 0 Limits: cpu: 500m ephemeral-storage: 1Gi memory: 2Gi Requests: cpu: 500m ephemeral-storage: 1Gi memory: 2Gi Environment: Mounts: /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-ksxxr (ro) Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: kube-api-access-ksxxr: Type: Projected (a volume that contains injected data from multiple sources) TokenExpirationSeconds: 3607 ConfigMapName: kube-root-ca.crt ConfigMapOptional: DownwardAPI: true QoS Class: Guaranteed Node-Selectors: Tolerations: kubernetes.io/arch=amd64:NoSchedule node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 5m42s gke.io/optimize-utilization-scheduler 0/2 nodes are available: 2 Insufficient cpu, 2 Insufficient memory. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod. Normal Scheduled 4m15s gke.io/optimize-utilization-scheduler Successfully assigned default/nginx-1-6b7bff9fc7-t7fzk to gk3-autopilot-cluster-1-pool-1-242a3a6a-j9rh Normal TriggeredScaleUp 5m34s cluster-autoscaler pod triggered scale-up: [{https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-02-92c260add90a/zones/{{{project_0.default_zone|Zone}}}/instanceGroups/gk3-autopilot-cluster-1-pool-1-242a3a6a-grp 0->1 (max: 1000)}] Normal Pulling 3m30s kubelet Pulling image "nginx" Normal Pulled 3m16s kubelet Successfully pulled image "nginx" in 13.843394735s (13.843643782s including waiting) Normal Created 3m16s kubelet Created container nginx Normal Started 3m15s kubelet Started container nginx

将文件推送到容器中

为了能够通过 nginx Web 服务器传送静态内容，您必须创建文件并将其放置到容器中。

  1. 在 Cloud Shell 中，输入以下命令以在 nano 文件编辑器中打开名为 test.html 的文件：
nano ~/test.html
  1. 将以下文本（shell 脚本）添加到空的 test.html 文件中：
This is title Hello World

  1. 按下 CTRL+X 键，然后按 Y 键和 Enter 键以保存文件并退出 nano 编辑器。

  2. 在 Cloud Shell 中执行以下命令，以将文件放置到 nginx Pod 中 nginx 容器内的适当位置，作为要传送的静态文件：

kubectl cp ~/test.html $my_nginx_pod:/usr/share/nginx/html/test.html

此命令会将 test.html 文件从本地主目录复制到 nginx Pod 中第一个容器的 /usr/share/nginx/html 目录。如需指定多容器 Pod 中的其他容器，您可以使用 -c 选项后跟所需容器的名称。

公开 Pod 以便测试

为了向集群外的客户端公开 Pod，您需要使用一个 Service。我们在本课程的其他部分探讨了 Service，它们广泛用于其他实验。您可以使用一个简单的命令来创建 Service 以公开 Pod。

  1. 在 Cloud Shell 中执行以下命令，来创建 Service 以向外部公开我们的 nginx Pod：
kubectl expose pod $my_nginx_pod --port 80 --type LoadBalancer

此命令将创建 LoadBalancer Service，它允许从集群外部的互联网地址访问 nginx Pod。

  1. 在 Cloud Shell 中执行以下命令，以查看有关集群中 Service 的详细信息：
kubectl get services

输出内容应如下例所示。您将在下一步中使用该外部 IP 地址。

注意：您可能需要重复运行该命令几次，等待新服务获得其外部 IP。

输出：

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.11.240.1 443/TCP 1h nginx-1-7...wsc LoadBalancer 10.11.240.87 80:31695/TCP 3s

该 Kubernetes Service 是集群创建或使用的默认 Service 之一。您创建的 nginx Service 也显示在输出内容中。

您可能需要重新运行此命令几次，才能显示出外部 IP 地址。

输出：

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.11.240.1 443/TCP 1h nginx-1-7...wsc LoadBalancer 10.11.240.87 104.154.177.46 80:31695/TCP 1m

点击检查我的进度以验证是否完成了以下目标。 将 Pod 部署到 GKE 集群

  1. 在 Cloud Shell 中执行以下命令，以验证 nginx 容器正在传送您复制的 HTML 文件。

将 [EXTERNAL_IP] 替换为您的 Service 的外部 IP 地址（从上一步的输出中获得）。

curl http://[EXTERNAL_IP]/test.html

文件内容显示在输出中。您可以在浏览器中前往同一地址，查看以 HTML 形式呈现的文件。

示例：

curl http://104.154.177.46/test.html This is title Hello world
  1. 在 Cloud Shell 中执行以下命令，以查看 nginx Pod 使用的资源：
kubectl top pods

输出：

NAME CPU(cores) MEMORY(bytes) nginx-1-74c7bbdb84-nvwsc 0m 2Mi

任务 5. 自查 GKE Pod

在此任务中，您将连接到一个 Pod 以调整设置、修改文件，并对 Pod 进行其他实时更改。

注意：只有在进行问题排查或实验时，才应使用此流程。由于您的更改不是对 Pod 的来源映像进行的，因此不会影响到其他副本。

准备好环境

最好通过配置文件（有时称为清单文件）向 Kubernetes 部署 Pod 和其他资源。配置文件一般用 YAML 语法写成，指定了资源的详细信息。利用配置文件，您可以更轻松地指定复杂选项，而无需使用很长的一行命令行参数。

YAML 语法与 JSON 语法类似但更为简洁，并支持对象和属性的同种分层构造。实验的源代码库包含为您准备好的示例 YAML 文件。

  1. 在 Cloud Shell 中输入以下命令，以将代码库克隆到实验 Cloud Shell：
git clone https://github.com/GoogleCloudPlatform/training-data-analyst
  1. 创建软链接作为工作目录的快捷方式：
ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s
  1. 切换到包含此实验示例文件的目录：
cd ~/ak8s/GKE_Shell/

其中为您提供了名为 new-nginx-pod.yaml 的 Pod 示例清单 YAML 文件：

apiVersion: v1 kind: Pod metadata: name: new-nginx labels: name: new-nginx spec: containers: - name: new-nginx image: nginx ports: - containerPort: 80
  1. 如需部署此清单，请执行以下命令：
kubectl apply -f ./new-nginx-pod.yaml

点击检查我的进度以验证是否完成了以下目标。 使用 Yaml 文件部署新的 pod

  1. 如需查看 Pod 清单，请执行以下命令：
kubectl get pods

输出内容应如下例所示。

输出：

NAME READY STATUS RESTARTS AGE new-nginx 1/1 Running 0 9s nginx-1-74c7bbdb84-nvwsc 1/1 Running 0 55m

您可以看到新的 nginx Pod 以及我们此前在实验中创建的 Pod。

使用 shell 重定向连接到 Pod

某些容器映像包含您可以启动的 shell 环境。使用此 shell 环境可能比通过 kubectl 执行单独的命令更方便。例如，nginx 映像包含 bash shell。在此任务中，您将在新的 nginx Pod 中使用 shell 重定向连接到 bash shell，以执行一系列操作。

  1. 在 Cloud Shell 中执行以下命令，以便在 nginx 容器中启动互动式 bash shell：
kubectl exec -it new-nginx -- /bin/bash

此时将显示一个新的 shell 提示。

输出：

root@new-nginx:/#

您在 new-nginx Pod 的容器中启动了互动式 bash shell。如果 Pod 有多个容器，您可以通过 -c 选项按名称指定其中一个容器。

由于 nginx 容器映像默认没有文本编辑工具，因此您需要安装文本编辑工具。

  1. 在 Cloud Shell 中，在 nginx bash shell 中执行以下命令以安装 nano 文本编辑器：
apt-get update apt-get install nano

当出现 Do you want to continue (Y/n) [是否继续 (Y/n)] 提示时，按 Y 键确认。

您需要在 nginx 容器上静态传送的目录中创建 test.html 文件。

  1. 在 Cloud Shell 中，在 nginx bash shell 中执行以下命令，以切换到静态文件目录并创建 test.html 文件：
cd /usr/share/nginx/html nano test.html
  1. 在 Cloud Shell 中，在 nginx bash shell nano 会话中输入以下文本：
This is title Hello World
  1. 按下 CTRL+X 键，然后按 Y 键和 Enter 键以保存文件并退出 nano 编辑器。
  2. 在 Cloud Shell 中，在 nginx bash shell 中执行以下命令以退出 nginx bash shell：
exit

如需连接到（包含新的静态 HTML 文件的）nginx 容器并对其进行测试，您可以创建一个 Service。更简单的方式是使用端口转发，从 Cloud Shell 直接连接到 Pod。

  1. 在 Cloud Shell 中执行以下命令，设置从 Cloud Shell 到 nginx Pod 的端口转发（从 Cloud Shell 虚拟机的端口 10081 到 nginx 容器的端口 80）：
kubectl port-forward new-nginx 10081:80

输出内容应如下例所示。

输出：

Forwarding from 127.0.0.1:10081 -> 80 Forwarding from [::1]:10081 -> 80

这是一个前台进程，因此您需要打开另一个 Cloud Shell 实例以进行测试。

  1. 在 Cloud Shell 菜单栏中，点击加号 (+) 图标以启动新的 Cloud Shell 会话。

Cloud Shell 菜单栏，其中突出显示了 (+) 图标

您的 Cloud Shell 窗口中将显示另一个 Cloud Shell 会话。您可以点击菜单栏中的标题，在会话之间切换。

  1. 在第二个 Cloud Shell 会话中执行以下命令，以便通过端口转发测试经修改的 nginx 容器：
curl http://127.0.0.1:10081/test.html

此时将显示您放置到 test.html 文件中的 HTML 文本。

This is title Hello World

查看 Pod 的日志

  1. 在 Cloud Shell 菜单栏中，点击加号 (+) 图标以启动另一个新的 Cloud Shell 会话。

您的 Cloud Shell 窗口中将显示第三个 Cloud Shell 会话。像之前一样，您可以通过点击菜单栏中的会话来进行切换。

  1. 在第三个 Cloud Shell 窗口中执行以下命令，以显示 new-nginx Pod 的日志，并在新日志到达时流式提取它们（并加入时间戳）：
kubectl logs new-nginx -f --timestamps
  1. 您将看到日志显示在此新窗口中。
  2. 返回第二个 Cloud Shell 窗口并重新运行 curl 命令，以便在此 Pod 上生成一些流量。
  3. 在新的日志消息显示在第三个 Cloud Shell 窗口时，对其进行审核。

第三个 Cloud Shell 窗口，其中显示了新的日志消息

  1. 关闭第三个 Cloud Shell 窗口以停止显示日志消息。
  2. 关闭最初的 Cloud Shell 窗口以停止端口转发进程。

结束实验

完成实验后，请点击结束实验。Google Cloud Skills Boost 会移除您使用过的资源并为您清理帐号。

系统会提示您为实验体验评分。请选择相应的星级数，输入评论，然后点击提交。

星级数的含义如下：

  • 1 颗星 = 非常不满意
  • 2 颗星 = 不满意
  • 3 颗星 = 一般
  • 4 颗星 = 满意
  • 5 颗星 = 非常满意

如果您不想提供反馈，可以关闭该对话框。

如果要留言反馈、提出建议或做出更正，请使用支持标签页。

版权所有 2020 Google LLC 保留所有权利。Google 和 Google 徽标是 Google LLC 的商标。其他所有公司名和产品名可能是其各自相关公司的商标。