From e878924c172b714511de03dfc34bbbe0eb5d2d2d Mon Sep 17 00:00:00 2001 From: Michael Date: Sat, 28 Jan 2023 10:17:52 +0800 Subject: [PATCH] [zh] sync manage-deployment.md --- .../manage-deployment.md | 282 +++++++++++------- 1 file changed, 173 insertions(+), 109 deletions(-) diff --git a/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md b/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md index 37ddd62048..6d0681ace1 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md @@ -14,7 +14,11 @@ weight: 40 你已经部署了应用并通过服务暴露它。然后呢？ Kubernetes 提供了一些工具来帮助管理你的应用部署，包括扩缩容和更新。 @@ -27,7 +31,9 @@ Kubernetes 提供了一些工具来帮助管理你的应用部署，包括扩缩 ## 组织资源配置 {#organizing-resource-config} @@ -46,13 +52,15 @@ Multiple resources can be created the same way as a single resource: kubectl apply -f https://k8s.io/examples/application/nginx-app.yaml ``` -``` +```none service/my-nginx-svc created deployment.apps/my-nginx created ``` 资源将按照它们在文件中的顺序创建。 因此，最好先指定服务，这样在控制器（例如 Deployment）创建 Pod 时能够 @@ -64,13 +72,18 @@ The resources will be created in the order they appear in the file. Therefore, i `kubectl apply` 也接受多个 `-f` 参数： ```shell -kubectl apply -f https://k8s.io/examples/application/nginx/nginx-svc.yaml -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml +kubectl apply -f https://k8s.io/examples/application/nginx/nginx-svc.yaml \ + -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml ``` 建议的做法是，将同一个微服务或同一应用层相关的资源放到同一个文件中， 将同一个应用相关的所有文件按组存放到同一个目录中。 @@ -79,17 +92,19 @@ A URL can also be specified as a configuration source, which is handy for deploy 还可以使用 URL 作为配置源，便于直接使用已经提交到 GitHub 上的配置文件进行部署： ```shell -kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/application/nginx/nginx-deployment.yaml +kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml ``` -``` +```none deployment.apps/my-nginx created ``` ## kubectl 中的批量操作 {#bulk-operations-in-kubectl} @@ -101,13 +116,14 @@ Resource creation isn't the only operation that `kubectl` can perform in bulk. I kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml ``` -``` +```none deployment.apps "my-nginx" deleted service "my-nginx-svc" deleted ``` 在仅有两种资源的情况下，你可以使用"资源类型/资源名"的语法在命令行中 同时指定这两个资源： @@ -117,7 +133,8 @@ kubectl delete deployments/my-nginx services/my-nginx-svc ``` 对于资源数目较大的情况，你会发现使用 `-l` 或 `--selector` 指定筛选器（标签查询）能很容易根据标签筛选资源： @@ -126,13 +143,14 @@ For larger numbers of resources, you'll find it easier to specify the selector ( kubectl delete deployment,services -l app=nginx ``` -``` +```none deployment.apps "my-nginx" deleted service "my-nginx-svc" deleted ``` 由于 `kubectl` 用来输出资源名称的语法与其所接受的资源名称语法相同， 你可以使用 `$()` 或 `xargs` 进行链式操作： @@ -142,32 +160,37 @@ kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o n kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service | xargs -i kubectl get {} ``` -``` +```none NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx-svc LoadBalancer 10.0.0.208 80/TCP 0s ``` 上面的命令中，我们首先使用 `examples/application/nginx/` 下的配置文件创建资源， 并使用 `-o name` 的输出格式（以"资源/名称"的形式打印每个资源）打印所创建的资源。 然后，我们通过 `grep` 来过滤 "service"，最后再打印 `kubectl get` 的内容。 如果你碰巧在某个路径下的多个子路径中组织资源，那么也可以递归地在所有子路径上 执行操作，方法是在 `--filename,-f` 后面指定 `--recursive` 或者 `-R`。 例如，假设有一个目录路径为 `project/k8s/development`，它保存开发环境所需的 所有{{< glossary_tooltip text="清单" term_id="manifest" >}}，并按资源类型组织： -``` +```none project/k8s/development ├── configmap │   └── my-configmap.yaml @@ -178,7 +201,9 @@ project/k8s/development ``` 默认情况下，对 `project/k8s/development` 执行的批量操作将停止在目录的第一级， 而不是处理所有子目录。 @@ -188,7 +213,7 @@ By default, performing a bulk operation on `project/k8s/development` will stop a kubectl apply -f project/k8s/development ``` -``` +```none error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin) ``` @@ -201,14 +226,15 @@ Instead, specify the `--recursive` or `-R` flag with the `--filename,-f` flag as kubectl apply -f project/k8s/development --recursive ``` -``` +```none configmap/my-config created deployment.apps/my-deployment created persistentvolumeclaim/my-pvc created ``` @@ -221,7 +247,7 @@ The `--recursive` flag also works when multiple `-f` arguments are provided: kubectl apply -f project/k8s/namespaces -f project/k8s/development --recursive ``` -``` +```none namespace/development created namespace/staging created configmap/my-config created @@ -230,15 +256,16 @@ persistentvolumeclaim/my-pvc created ``` -如果你有兴趣进一步学习关于 `kubectl` 的内容，请阅读 -[命令行工具（kubectl）](/zh-cn/docs/reference/kubectl/)。 +如果你有兴趣进一步学习关于 `kubectl` 的内容，请阅读[命令行工具（kubectl）](/zh-cn/docs/reference/kubectl/)。 ## 有效地使用标签 {#using-labels-effectively} @@ -246,7 +273,9 @@ The examples we've used so far apply at most a single label to any resource. The 在许多情况下，应使用多个标签来区分集合。 例如，不同的应用可能会为 `app` 标签设置不同的值。 但是，类似 [guestbook 示例](https://github.com/kubernetes/examples/tree/master/guestbook/) @@ -259,7 +288,8 @@ For instance, different applications would use different values for the `app` la ``` Redis 的主节点和从节点会有不同的 `tier` 标签，甚至还有一个额外的 `role` 标签： @@ -292,7 +322,7 @@ kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml kubectl get pods -Lapp -Ltier -Lrole ``` -``` +```none NAME READY STATUS RESTARTS AGE APP TIER ROLE guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend @@ -308,7 +338,7 @@ my-nginx-o0ef1 1/1 Running 0 29m nginx kubectl get pods -lapp=guestbook,role=slave ``` -``` +```none NAME READY STATUS RESTARTS AGE guestbook-redis-slave-2q2yf 1/1 Running 0 3m guestbook-redis-slave-qgazl 1/1 Running 0 3m @@ -317,7 +347,11 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m ## 金丝雀部署（Canary Deployments） {#canary-deployments} @@ -335,51 +369,56 @@ The primary, stable release would have a `track` label with value as `stable`: 主要稳定的发行版将有一个 `track` 标签，其值为 `stable`： -```yaml - name: frontend - replicas: 3 - ... - labels: - app: guestbook - tier: frontend - track: stable - ... - image: gb-frontend:v3 +```none +name: frontend +replicas: 3 +... +labels: + app: guestbook + tier: frontend + track: stable +... +image: gb-frontend:v3 ``` 然后，你可以创建 guestbook 前端的新版本，让这些版本的 `track` 标签带有不同的值 （即 `canary`），以便两组 Pod 不会重叠： -```yaml - name: frontend-canary - replicas: 1 - ... - labels: - app: guestbook - tier: frontend - track: canary - ... - image: gb-frontend:v4 +```none +name: frontend-canary +replicas: 1 +... +labels: + app: guestbook + tier: frontend + track: canary +... +image: gb-frontend:v4 ``` 前端服务通过选择标签的公共子集（即忽略 `track` 标签）来覆盖两组副本， 以便流量可以转发到两个应用： ```yaml - selector: - app: guestbook - tier: frontend +selector: + app: guestbook + tier: frontend ``` 你可以调整 `stable` 和 `canary` 版本的副本数量，以确定每个版本将接收 实时生产流量的比例（在本例中为 3:1）。 @@ -387,7 +426,8 @@ Once you're confident, you can update the stable track to the new application re `canary` 替换为 `stable`，并且将老版本应用删除。 想要了解更具体的示例，请查看 [Ghost 部署教程](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary)。 @@ -395,7 +435,8 @@ For a more concrete example, check the [tutorial of deploying Ghost](https://git ## 更新标签 {#updating-labels} @@ -408,7 +449,7 @@ For example, if you want to label all your nginx pods as frontend tier, run: kubectl label pods -l app=nginx tier=fe ``` -``` +```none pod/my-nginx-2035384211-j5fhi labeled pod/my-nginx-2035384211-u2c7e labeled pod/my-nginx-2035384211-u3t6x labeled @@ -425,7 +466,7 @@ To see the pods you labeled, run: kubectl get pods -l app=nginx -L tier ``` -``` +```none NAME READY STATUS RESTARTS AGE TIER my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe @@ -433,22 +474,25 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe ``` 这将输出所有 "app=nginx" 的 Pod，并有一个额外的描述 Pod 的 tier 的标签列 （用参数 `-L` 或者 `--label-columns` 标明）。 -想要了解更多信息，请参考 -[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/) 和 +想要了解更多信息，请参考[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)和 [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands/#label) 命令文档。 ## 更新注解 {#updating-annotations} @@ -460,7 +504,7 @@ kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx' kubectl get pods my-nginx-v4-9gw19 -o yaml ``` -``` +```shell apiVersion: v1 kind: pod metadata: @@ -470,17 +514,18 @@ metadata: ``` -想要了解更多信息，请参考 -[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)和 +想要了解更多信息，请参考[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)和 [`kubectl annotate`](/docs/reference/generated/kubectl/kubectl-commands/#annotate) 命令文档。 ## 扩缩你的应用 {#scaling-your-app} @@ -491,7 +536,7 @@ When load on your application grows or shrinks, use `kubectl` to scale your appl kubectl scale deployment/my-nginx --replicas=1 ``` -``` +```none deployment.apps/my-nginx scaled ``` @@ -504,13 +549,14 @@ Now you only have one pod managed by the deployment. kubectl get pods -l app=nginx ``` -``` +```none NAME READY STATUS RESTARTS AGE my-nginx-2035384211-j5fhi 1/1 Running 0 30m ``` 想要让系统自动选择需要 nginx 副本的数量，范围从 1 到 3，请执行以下操作： @@ -518,21 +564,23 @@ To have the system automatically choose the number of nginx replicas as needed, kubectl autoscale deployment/my-nginx --min=1 --max=3 ``` -``` +```none horizontalpodautoscaler.autoscaling/my-nginx autoscaled ``` 现在，你的 nginx 副本将根据需要自动地增加或者减少。 想要了解更多信息，请参考 [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)命令文档、 -[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 命令文档和 -[水平 Pod 自动伸缩](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。 +[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) +命令文档和[水平 Pod 自动伸缩](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)文档。 建议在源代码管理中维护一组配置文件 （参见[配置即代码](https://martinfowler.com/bliki/InfrastructureAsCode.html)）， @@ -558,25 +607,36 @@ Then, you can use [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-co 将配置变更应用到集群中。 这个命令将会把推送的版本与以前的版本进行比较，并应用你所做的更改， 但是不会自动覆盖任何你没有指定更改的属性。 ```shell kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml +``` + +```none deployment.apps/my-nginx configured ``` 注意，`kubectl apply` 将为资源增加一个额外的注解，以确定自上次调用以来对配置的更改。 执行时，`kubectl apply` 会在以前的配置、提供的输入和资源的当前配置之间 找出三方差异，以确定如何修改资源。 目前，新创建的资源是没有这个注解的，所以，第一次调用 `kubectl apply` 时 将使用提供的输入和资源的当前配置双方之间差异进行比较。 @@ -584,19 +644,14 @@ Currently, resources are created without this annotation, so the first invocatio 因此，kubectl 不会删除它们。 所有后续的 `kubectl apply` 操作以及其他修改配置的命令，如 `kubectl replace` 和 `kubectl edit`，都将更新注解，并允许随后调用的 `kubectl apply` 使用三方差异进行检查和执行删除。 -{{< note >}} - -想要使用 apply，请始终使用 `kubectl apply` 或 `kubectl create --save-config` 创建资源。 -{{< /note >}} - ### kubectl edit 这相当于首先 `get` 资源，在文本编辑器中编辑它，然后用更新的版本 `apply` 资源： @@ -625,7 +681,8 @@ rm /tmp/nginx.yaml ``` @@ -645,15 +702,17 @@ and [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch). --> 你可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch、 -JSON merge patch、以及 strategic merge patch。 请参考 -[使用 kubectl patch 更新 API 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) -和 -[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch). +JSON merge patch、以及 strategic merge patch。 +请参考[使用 kubectl patch 更新 API 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)和 +[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch)。 ## 破坏性的更新 {#disruptive-updates} @@ -665,7 +724,7 @@ In some cases, you may need to update resource fields that cannot be updated onc kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force ``` -``` +```none deployment.apps/my-nginx deleted deployment.apps/my-nginx replaced ``` @@ -676,7 +735,9 @@ deployment.apps/my-nginx replaced ## 在不中断服务的情况下更新应用 {#updating-your-app-without-a-service-outage} 在某些时候，你最终需要更新已部署的应用，通常都是通过指定新的镜像或镜像标签， 如上面的金丝雀发布的场景中所示。`kubectl` 支持几种更新操作， @@ -696,26 +757,26 @@ Let's say you were running version 1.14.2 of nginx: kubectl create deployment my-nginx --image=nginx:1.14.2 ``` -``` +```none deployment.apps/my-nginx created ``` - 运行 3 个副本（这样新旧版本可以同时存在） ```shell kubectl scale deployment my-nginx --current-replicas=1 --replicas=3 ``` -``` +```none deployment.apps/my-nginx scaled ``` 要更新到 1.16.1 版本，只需使用我们前面学到的 kubectl 命令将 `.spec.template.spec.containers[0].image` 从 `nginx:1.14.2` 修改为 `nginx:1.16.1`。 @@ -725,7 +786,10 @@ kubectl edit deployment/my-nginx ``` 没错，就是这样！Deployment 将在后台逐步更新已经部署的 nginx 应用。 它确保在更新过程中，只有一定数量的旧副本被开闭，并且只有一定基于所需 Pod 数量的新副本被创建。