Skip to content

Files

Latest commit

 

History

History
592 lines (445 loc) · 32.2 KB

09.md

File metadata and controls

592 lines (445 loc) · 32.2 KB

九、部署您的第一个应用

在前面的章节中，我们介绍了 Kubernetes 的关键操作原理和 Windows/Linux 混合集群的部署策略。现在是时候更专注于部署和使用 Kubernetes 应用了。为了演示 Kubernetes 应用的基本操作，我们将使用我们在第 8 章、中创建的 AKS Engine 混合 Kubernetes 集群部署混合 Azure Kubernetes 服务引擎集群。您也可以使用内部混合集群，但是您应该期望有限的功能；例如，负载平衡器类型的服务将不可用。

本章涵盖以下主题:

  • 强制部署应用
  • 使用 Kubernetes 清单文件
  • 在窗口节点上调度 Pods
  • 访问您的应用
  • 扩展应用

技术要求

对于本章，您将需要以下内容:

  • 安装了 Windows 10 专业版、企业版或教育版(1903 版或更高版本，64 位)
  • 蔚蓝账户
  • 使用 AKS 引擎部署的 Windows/Linux Kubernetes 集群

接下来，您将需要自己的 Azure 帐户来为 Kubernetes 集群创建 Azure 资源。如果您还没有创建前几章的帐户，您可以在这里阅读更多关于如何获得个人使用的有限免费帐户的信息:https://azure.microsoft.com/en-us/free/。

使用 AKS 引擎部署 Kubernetes 集群已经在第 8 章、中介绍了部署混合 Azure Kubernetes 服务引擎集群。

您可以从官方 GitHub 资源库下载本章的最新代码示例:https://GitHub . com/PacktPublishing/hand-Kubernetes-On-Windows/tree/master/chapter 09。

强制部署应用

在 Kubernetes 世界中，在管理应用时，您可以从两种方法中进行选择:命令式管理和声明式管理。命令式方法包括执行命令式 kubectl 命令，如kubectl run或kubectl expose，以及命令式对象配置管理，其中您使用命令，如kubectl create或kubectl replace。简而言之，您可以通过执行修改 Kubernetes 对象并导致集群所需状态发生变化的临时命令来管理集群，有时，您甚至不知道在执行命令后所需状态到底发生了什么变化。相比之下，在声明性方法中，您可以修改对象配置(清单文件)，并使用kubectl apply命令在集群中创建或更新它们(或者，您可以使用 Kustomization 文件)。

一般来说，使用声明式管理更接近 Kubernetes 的精神——整个体系结构专注于持久化所需的集群状态，并不断执行将当前集群状态更改为所需状态的操作。一般的经验法则是，在生产环境中，您应该始终使用声明式管理，或者使用标准清单文件，或者使用 Kustomization 文件。您可以轻松地为对象配置提供源代码控制，并将其集成到连续的集成/部署管道中。强制管理对于开发和概念验证场景非常有用—操作直接在实时集群上执行。

Remember that, for this approach, you will not have an easy way of knowing the history of the previous configurations!

现在，让我们首先尝试部署简单 web 应用的强制方法。我们将执行以下操作:

  1. 创建单个裸 Pod 或复制控制器。
  2. 使用服务(负载平衡器类型)公开它。

要强制创建一个 POD 或复制控制器，我们将使用kubectl run命令。此命令允许您使用生成器创建不同的容器管理对象。您可以在官方文档中找到完整的生成器列表:https://Kubernetes . io/docs/reference/kube CTL/convents/# generators—从 Kubernetes 1.12 开始，除run-pod/v1之外的所有生成器都被弃用。其主要原因是kubectl run命令相对较高的复杂性，以及鼓励对高级场景采用适当的声明性方法。

要基于mcr.microsoft.com/dotnet/core/samples:aspnetapp Docker 映像部署示例应用，请执行以下步骤:

  1. 打开一个 PowerShell 窗口，并确保您正在使用kubeconfig文件，该文件允许您连接到您的 AKS Engine 混合集群。
  2. 确定集群中的节点上可用的 Windows Server 操作系统版本。例如，对于 Windows Server 2019 Datacenter 节点，您需要使用基础层版本为 1809 的容器映像。这意味着我们必须在示例中使用mcr.microsoft.com/dotnet/core/samples:aspnetapp-nanoserver-1809 Docker 映像:
kubectl get nodes -o wide
  1. 使用run-pod/v1生成器执行kubectl run命令，运行单个 podwindows-example，对于nodeSelector设置为节点和操作系统类型的示例应用，windows:
kubectl run `
 --generator=run-pod/v1 `
 --image=mcr.microsoft.com/dotnet/core/samples:aspnetapp-nanoserver-1809 `
 --overrides='{\"apiVersion\": \"v1\", \"spec\": {\"nodeSelector\": { \"beta.kubernetes.io/os\": \"windows\" }}}' `
 windows-example
  1. 将在其中一个窗口节点上计划 pod，您可以使用以下命令监控 pod 创建的进度:
PS C:\src> kubectl get pods -w
NAME              READY   STATUS              RESTARTS   AGE
windows-example   0/1     ContainerCreating   0          7s
  1. 当容器将其状态更改为Running时，您可以使用负载平衡器服务继续暴露容器:
kubectl expose pod windows-example `
 --name windows-example-service `
 --type LoadBalancer `
 --port 8080 `
 --target-port 80
  1. 等待服务的EXTERNAL-IP可用:
PS C:\src> kubectl get service -w
NAME                      TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)          AGE
kubernetes                ClusterIP      10.0.0.1       <none>           443/TCP          24h
windows-example-service   LoadBalancer   10.0.192.180   213.199.135.14   8080:30746/TCP   5m10s
  1. 现在，您可以使用服务的外部 IP 和端口8080来访问 pod 中运行的应用。例如，在网络浏览器中，导航至http://213.199.135.14:8080/。

或者，上述过程可以只在一个kubectl run命令中执行，该命令将创建 pod 并使用负载平衡器服务立即公开它:

kubectl run `
 --generator=run-pod/v1 `
 --image=mcr.microsoft.com/dotnet/core/samples:aspnetapp-nanoserver-1809 `
 --overrides='{\"apiVersion\": \"v1\", \"spec\": {\"nodeSelector\": { \"beta.kubernetes.io/os\": \"windows\" }}}' `
 --expose `
 --port 80 `
 --service-overrides='{ \"spec\": { \"type\": \"LoadBalancer\" }}' `
 windows-example

Note that this command exposes the service using port 80, not 8080. Using service port 80 and target port 8080 requires another layer of complexity in the --service-overrides flag.

为了完整起见，让我们在 Kubernetes ReplicationController 对象后面运行我们的mcr.microsoft.com/dotnet/core/samples:aspnetapp-nanoserver-1809容器。您可以在第 4 章、 Kubernetes 概念和 Windows 支持中了解更多关于复制控制器、复制集和部署的信息—一般来说，不建议在集群中运行裸 Pods 您应该始终至少使用复制集或部署来管理 Pods。在 Kubernetes 1.17 中，仍然可以使用kubectl run创建一个复制控制器——生成器已被弃用，但尚未删除。创建复制控制器迫切需要使用不同的--generator标志，其值为run/v1:

kubectl run `
 --generator=run/v1 `
 --image=mcr.microsoft.com/dotnet/core/samples:aspnetapp-nanoserver-1809 `
 --overrides='{\"apiVersion\": \"v1\", \"spec\": {\"nodeSelector\": { \"beta.kubernetes.io/os\": \"windows\" }}}' `
 --expose `
 --port 80 `
 --service-overrides='{ \"spec\": { \"type\": \"LoadBalancer\" }}' `
 windows-example

即使这种方法很快，不需要任何配置文件，您也可以清楚地看到，将kubectl run用于除简单操作之外的任何操作变得越来越复杂和容易出错。在大多数情况下，您将使用命令进行以下操作:

  • 在您的开发集群中快速创建 Pods
  • 为调试目的创建特殊的交互式 Pods
  • 可预见地删除 Kubernetes 资源—下一节将详细介绍这一点

现在让我们通过使用 Kubernetes 清单文件和声明性管理方法来执行类似的部署。

使用 Kubernetes 清单文件

Kubernetes 对象的声明式管理更接近于 Kubernetes 的精神——您专注于告诉 Kubernetes 您想要什么(描述期望的状态)，而不是直接告诉它要做什么。随着应用的增长和组件的增多，使用命令式命令管理集群变得不可能。更好的方法是使用命令进行只读操作，如kubectl describe、kubectl get和kubectl logs，并使用kubectl apply命令和 Kubernetes 对象配置文件(也称为清单文件)对集群所需的状态执行所有修改。

使用清单文件时，有几个推荐的做法:

More best practices regarding manifest files can be found in the official documentation: https://kubernetes.io/docs/concepts/configuration/overview/.

现在，让我们通过部署一个类似于上一节中的应用来尝试演示这种方法。这一次，我们将使用部署和服务对象，它们将在单独的清单文件中定义——在现实场景中，您将把这两个清单文件组合成一个文件，但是出于演示的目的，将它们分开是有意义的。按照以下步骤部署应用:

  1. 打开一个 PowerShell 窗口。
  2. 确保您的集群没有运行上一节中的资源—您可以使用kubectl get all命令检查并使用kubectl delete命令删除它们。
  3. 为您的清单文件创建一个目录，例如declarative-demo:
md .\declarative-demo
cd .\declarative-demo
  1. 创建windows-example-deployment.yaml清单文件，其中包含部署定义:
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: windows-example
  labels:
    app: sample
spec:
  replicas: 1
  selector:
    matchLabels:
      app: windows-example
  template:
    metadata:
      name: windows-example
      labels:
        app: windows-example
    spec:
      nodeSelector:
        "beta.kubernetes.io/os": windows
      containers:
      - name: windows-example
        image: mcr.microsoft.com/dotnet/core/samples:aspnetapp-nanoserver-1809
        ports:
          - containerPort: 80
  1. 创建windows-example-service.yaml清单文件，其中包含负载平衡器服务定义:
---
apiVersion: v1
kind: Service
metadata:
  name: windows-example
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 80
  selector:
    app: windows-example
  1. 使用kubectl apply命令应用当前目录中的清单文件。请注意，如果您有多级目录层次结构，您可以使用-R标志进行递归处理:
PS C:\src\declarative-demo> kubectl apply -f .\
deployment.apps/windows-example created
service/windows-example created
  1. 使用以下命令等待服务的外部 IP 可用:
PS C:\src\declarative-demo> kubectl get service -w
NAME              TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
kubernetes        ClusterIP      10.0.0.1      <none>        443/TCP          44h
windows-example   LoadBalancer   10.0.63.175   51.144.36.7   8080:30568/TCP   3m28s
  1. 使用您的网络浏览器导航至外部 IP 和端口8080。

现在，让我们看看如何使用声明性方法对应用进行简单的更改——我们希望将负载平衡器端口更改为9090:

  1. 打开windows-example-service.yaml清单文件。

  2. 将spec.ports[0].port值修改为9090。

  3. 保存清单文件。

  4. (可选但推荐)使用kubectl diff命令验证您的更改。请记住，您需要在$env:KUBECTL_EXTERNAL_DIFF环境变量中安装并定义一个合适的差异工具；您可以在第 6 章、与 Kubernetes 集群互动中了解更多信息:

kubectl diff -f .\
  1. 再次应用清单文件:
PS C:\src\declarative-demo> kubectl apply -f .\
deployment.apps/windows-example unchanged
service/windows-example configured
  1. 请注意，只有service/windows-example被检测为在所需配置中发生了变化。
  2. 现在，您可以在网络浏览器中导航到外部 IP 地址和端口9090来验证更改。
  3. 如果要删除当前目录中清单文件创建的所有资源，可以使用以下命令:
kubectl delete -f .\

就这样！正如您所看到的，声明式管理可能需要更多的样板配置，但是最终，使用这种方法管理应用更容易预测和跟踪。

When managing complex applications running in multiple environments, consider using Kustomization files (which can be used with the kubectl apply command) or Helm Charts. For example, with Kustomization files, you can organize the configuration files in a convention-friendly directory structure: https://kubectl.docs.kubernetes.io/pages/app_composition_and_deployment/structure_directories.html.

在下一节中，我们将快速了解有关在 Windows 节点上调度 Pods 的推荐做法。

在窗口节点上调度 Pods

要在具有特定属性的节点上调度 Pods，Kubernetes 提供了几个可能的选项:

  • 使用 Pod 规范中的nodeName。这是在给定节点上静态调度 Pods 的最简单形式，通常不推荐使用。
  • 使用 POD 规格中的nodeSelector。这使您可以仅在具有特定标签值的节点上调度 pod。在前一节中，我们已经使用了这种方法。
  • 节点相似性和反相似性:这些概念扩展了nodeSelector方法，并提供了更丰富的语言来定义哪些节点是您的 pod 首选或避免的。你可以在官方文档中读到更多的可能性:https://kubernetes . io/docs/concepts/configuration/assign-pod-node/# affinity-and-anti-affinity。
  • 节点污点和 pod 容忍性:它们提供了与节点相似性相反的功能——您将污点应用于给定的节点(描述了某种限制)，并且 pod 必须定义特定的容忍性，以便可以在被污染的节点上进行调度。

在混合 Windows/Linux 集群中调度 Pods 至少需要使用nodeSelector或节点污点与nodeSelector的组合。默认情况下，每个 Kubernetes 节点都带有一组标签，包括以下内容:

  • kubernetes.io/arch，描述节点的处理器架构，例如amd64或arm:这也定义为beta.kubernetes.io/arch。
  • kubernetes.io/os，值为linux或windows:也定义为beta.kubernetes.io/os。

您可以使用以下命令检查 AKS 引擎集群中的 Windows 节点(例如，7001k8s011)的默认标签:

PS C:\src> kubectl describe node 7001k8s011
Name:               7001k8s011
Roles:              agent
Labels:             agentpool=windowspool2
 beta.kubernetes.io/arch=amd64
 beta.kubernetes.io/instance-type=Standard_D2_v3
 beta.kubernetes.io/os=windows
 failure-domain.beta.kubernetes.io/region=westeurope
 failure-domain.beta.kubernetes.io/zone=0
 kubernetes.azure.com/cluster=aks-engine-windows-resource-group
 kubernetes.azure.com/role=agent
 kubernetes.io/arch=amd64
 kubernetes.io/hostname=7001k8s011
 kubernetes.io/os=windows
 kubernetes.io/role=agent
 node-role.kubernetes.io/agent=
 storageprofile=managed
 storagetier=Standard_LRS

如果您的 pod 在规范中不包含nodeSelector，它可以在 Windows 和 Linux 节点上进行调度——这是一个问题，因为 Windows 容器不会在 Linux 节点上启动，反之亦然。推荐的做法是使用nodeSelector为视窗和 Linux 容器可预测地安排您的 Pods。例如，在部署定义中，pod 模板可能包含以下内容:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: windows-example
spec:
...
  template:
...
    spec:
      nodeSelector:
        "beta.kubernetes.io/os": windows
...

或者，您可以在最新版本的 Kubernetes 中使用"kubernetes.io/os": windows选择器。对于 Linux 容器，需要指定"beta.kubernetes.io/os": linux或者"kubernetes.io/os": linux。

当您使用 Helm Charts 或 Kubernetes Operators 将 Windows 节点添加到现有的大型仅限 Linux 的集群中时，这种方法可能会导致问题，因为此类工作负载可能没有开箱即用的 Linux 节点选择器。为了解决这个问题，您可以使用污点和容忍:用特定的NoSchedule污点标记您的窗口节点，并为您的 Pods 使用匹配的容忍。为此，我们将使用带有os键和Win1809值的污点。

要污染窗口节点，有两种可能:

  • 使用 kubelet 的--register-with-taints='os=Win1809:NoSchedule'标志在注册级别污染节点。请注意，这种方法目前在 AKS Engine 中不可用，因为--register-with-taints不是用户可配置的，您可以在文档中阅读更多内容:https://github . com/Azure/AKS-Engine/blob/master/docs/topics/cluster definitions . MD # kubleconfig。
  • 使用 kubectl 污染节点。您可以使用以下命令添加污点:kubectl taint nodes <nodeName> os=Win1809:NoSchedule并使用kubectl taint nodes 7001k8s011 os:NoSchedule-移除污点。

然后，您的部署定义必须为 Windows 和污点容忍指定适当的 pod 节点选择器，这允许在 Windows 节点上进行调度:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: windows-example
spec:
...
  template:
...
    spec:
      nodeSelector:
        "beta.kubernetes.io/os": windows
      tolerations:
      - key: "os"
        operator: "Equal"
        value: "Win1809"
        effect: "NoSchedule"
...

在这种方法中，对于 Linux 容器，您不需要指定任何节点选择器或污点容忍。但是，如果可能的话，建议使用没有节点污点的节点选择器方法，尤其是在构建新集群的情况下。

在下一节中，我们将了解如何访问您的应用。

访问您的应用

对于访问在 pod 中运行的应用，根据您的场景，您有几种可能性。在调试和测试场景中，可以通过以下简单方式访问应用:

  • 使用kubectl exec创建一个特别的交互式窗格。我们在前面的章节中使用了这种方法。
  • 使用kubectl proxy访问任何服务类型。这种方法只适用于 HTTP(S)端点，因为它使用了 Kubernetes API Server 提供的代理功能。
  • 使用kubectl port-forward。您可以使用这种方法来访问部署中或服务后运行的单个 Pods 或 Pods。

如果您希望在生产中向最终用户公开应用，可以使用以下方法:

  • 负载平衡器或节点端口类型的服务对象:我们已经在上一节中演示了如何使用负载平衡器服务。
  • 将入口控制器与集群 IP 类型的服务结合使用:这种方法减少了使用的云负载平衡器的数量(从而降低了运营成本)，并在 Kubernetes 集群内执行负载平衡和路由。请注意，这种方法使用 L7 负载平衡，因此它只能用于公开 HTTP(S)端点。

您可以在第 5 章、Kubernetes 网络中详细了解服务和入口控制器。在本节的后面，我们将演示如何将入口控制器用于演示应用。

You can read more about accessing applications running in the cluster in various scenarios in the official documentation: https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-services/#accessing-services-running-on-the-cluster.

我们先演示一下如何使用kubectl proxy和kubectl port-forward。请执行以下步骤:

  1. 打开 Powershell 窗口。
  2. 确保部署了前面章节中的演示应用，并且在集群中部署了端口为8080的windows-example服务。
  3. 运行kubectl proxy命令:
PS C:\src\declarative-demo> kubectl proxy
Starting to serve on 127.0.0.1:8001
  1. 这将在端口8001上向远程 Kubernetes 应用编程接口服务器公开本地主机上的一个简单代理服务器。您可以使用此端点自由使用应用编程接口，而无需额外的身份验证。请注意，使用不带代理的原始应用编程接口也是可能的，但是您必须自己处理身份验证。
  2. 您的服务将在http://<proxyEndpoint>/api/v1/namespaces/<namespaceName>/services/[https:]<serviceName>[:portName]/proxy提供。在我们的案例中，导航至http://127.0.0.1:8001/api/v1/namespaces/default/services/windows-example/proxy/。这种方法适用于任何服务类型，包括内部集群 IP。
  3. 终止kubectl proxy流程。
  4. 现在，执行以下kubectl port-forward命令:
PS C:\src\declarative-demo> kubectl port-forward service/windows-example 5000:8080
Forwarding from 127.0.0.1:5000 -> 80
Forwarding from [::1]:5000 -> 80
  1. 这将把任何来自本地主机5000端口的网络流量转发到windows-example服务上的8080。例如，您可以在网络浏览器中导航至http://127.0.0.1:5000/。请注意，这种方法也适用于不同于 HTTP 的协议。
  2. 终止kubectl port-forward流程。

现在，让我们看看如何使用入口控制器来访问演示应用。使用入口是高度可定制的，并且有多个入口控制器可用——我们将演示使用ingress-nginx(https://www . nginx . com/products/nginx/kubernetes-入口控制器)在 AKS Engine 混合集群上启动和运行的最快方法。请注意，这种方法将入口控制器的部署仅限于 Linux 节点—您将能够为运行在 Windows 节点上的服务创建入口对象，但所有负载平衡都将在 Linux 节点上执行。请遵循以下步骤:

  1. 修改windows-example-service.yaml清单文件，使其有type: ClusterIP、port: 80，无targetPort:
apiVersion: v1
kind: Service
metadata:
  name: windows-example
spec:
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 80
  selector:
    app: windows-example
  1. 将您的修改应用到集群:
kubectl apply -f .\
  1. 为 ingress-nginx 应用官方通用清单文件，该文件创建一个部署，其中一个副本运行在 Linux 节点上:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml
  1. 为 ingress-nginx 应用官方云特定清单文件。这将创建一个负载平衡器类型的服务，用于入口控制器:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/cloud-generic.yaml
  1. 等待入口控制器服务接收外部 IP 地址。外部 IP 地址104.40.133.125将用于配置为在此入口控制器后面运行的所有服务:
PS C:\src\declarative-demo> kubectl get service -n ingress-nginx -w
NAME            TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)                      AGE
ingress-nginx   LoadBalancer   10.0.110.35   104.40.133.125   80:32090/TCP,443:32215/TCP   16m
  1. 创建windows-example-ingress.yaml清单文件并定义入口对象。我们申请的windows-example服务将在<ingressLoadBalancerIp>/windows-example路径下注册:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: windows-example-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - http:
      paths:
      - path: /windows-example(/|$)(.*)
        backend:
          serviceName: windows-example
          servicePort: 80
  1. 应用更改:
kubectl apply -f .\
  1. 导航至http://104.40.133.125/windows-example测试入口定义。

当然，您可以为不同的服务创建多个具有复杂规则的入口对象。一般的经验法则是，您应该尽可能使用入口控制器来公开您的 HTTP(S)端点，并为其他协议使用专用的负载平衡器服务。

现在，让我们看看如何扩展您的应用！

扩展应用

在生产场景中，您肯定需要扩展您的应用——这是 Kubernetes 强大的地方；您可以手动缩放应用，也可以使用自动缩放。让我们先来看看如何执行部署的手动扩展。您可以强制执行，也可以声明执行。要在 PowerShell 中使用命令执行扩展，请执行以下步骤:

  1. 执行kubectl scale命令，将windows-example部署扩展到三个副本:
PS C:\src\declarative-demo> kubectl scale deployment/windows-example --replicas=3
deployment.extensions/windows-example scaled
  1. 现在，请观看如何将 Pods 添加到您的部署中:
PS C:\src\declarative-demo> kubectl get pods -w
NAME READY STATUS RESTARTS AGE
windows-example-5cb7456474-5ndrm 0/1 ContainerCreating 0 8s
windows-example-5cb7456474-v7k84 1/1 Running 0 23m
windows-example-5cb7456474-xqp86 1/1 Running 0 8s

您可以以声明的方式执行类似的操作，这通常是推荐的。让我们将应用进一步扩展到四个副本:

  1. 编辑windows-example-deployment.yaml清单文件并将replicas修改为4。
  2. 保存清单文件并应用更改:
PS C:\src\declarative-demo> kubectl apply -f .\
deployment.apps/windows-example configured
ingress.networking.k8s.io/windows-example-ingress unchanged
service/windows-example unchanged
  1. 再次，使用kubectl get pods -w命令观察应用如何放大。

Kubernetes 的真正力量来自自动缩放。我们将在 第 11 章中更详细地介绍自动缩放，将应用配置为使用 Kubernetes 特性，因此在本节中，我们将只给出如何使用命令式命令进行自动缩放的简短概述:

  1. 首先，您需要在部署中为 pod 模板配置 CPU 资源限制，将其设置为一个小值，例如100m。如果没有 CPU 资源限制，自动缩放将无法正确应用缩放策略:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: windows-example
...
spec:
...
    spec:
...
      containers:
      - name: windows-example
...
        resources:
          limits:
            cpu: 100m
          requests:
            cpu: 100m
  1. 应用修改:
kubectl apply -f .\
  1. 执行以下kubectl autoscale命令:
kubectl autoscale deployment/windows-example --cpu-percent=15 --min=1 --max=5
  1. 这将在集群中创建一个水平 POD 自动缩放器 ( HPA )对象，该对象具有默认算法、最少 1 个副本、最多 5 个副本以及基于 15%限制的目标 CPU 使用率的配置。
  2. 使用以下命令检查 HPA 的状态:
kubectl describe hpa windows-example

  1. 通过频繁刷新应用网页，您可以尝试给 Pods 增加一些 CPU 负载。请注意，如果您正在使用入口，您将会命中入口控制器的缓存，因此在这种情况下，CPU 使用率可能不会增加。

  2. 一段时间后，您将看到自动缩放开始生效，并添加更多副本。当您减少负载时，部署将缩小。您可以使用kubectl describe命令检查时间线:

PS C:\src\declarative-demo> kubectl describe hpa windows-example
...
 Normal   SuccessfulRescale             11m                horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
 Normal   SuccessfulRescale             4m17s              horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
  1. 使用以下命令删除 HPA 对象以关闭自动缩放:
kubectl delete hpa windows-example

For managed AKS instances, it is possible to leverage the node-level autoscaling feature (https://docs.microsoft.com/en-us/azure/aks/cluster-autoscaler), which brings another dimension of scalability for your workloads. Additionally, you can consider using AKS workloads with Azure Container Instances (https://docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/scale-using-aks-with-aci).

恭喜你！您已经成功地在 AKS Engine 混合 Kubernetes 集群上部署并自动缩放了您的第一个应用。

摘要

本章简要介绍了如何部署和管理在 AKS Engine 混合集群上运行的 Windows 容器应用。您学习了集群配置的命令式管理和声明式管理之间的区别，以及何时使用它们。我们使用了这两种方法来部署一个演示应用——现在您知道了，推荐的声明式方法比使用命令式命令更容易，也更不容易出错。接下来，您学习了如何在 Windows 节点上可预测地调度 Pods，以及如何将 Windows 容器工作负载添加到现有的 Kubernetes 集群中。最后，我们展示了如何为最终用户和开发人员访问在 Kubernetes 中运行的应用，以及如何手动和自动扩展应用。

在下一章中，我们将利用所有这些新知识来部署一个真正的。NET 框架应用到我们的 Kubernetes 集群！

问题

  1. Kubernetes 对象的命令式管理和声明式管理有什么区别？
  2. 建议何时使用命令式命令？
  3. 如何查看本地清单文件和当前集群状态之间的变化？
  4. 在混合集群中调度 Pods 的推荐做法是什么？
  5. kubectl proxy和kubectl port-forward命令有什么区别？
  6. 什么时候可以使用入口控制器？
  7. 如何手动扩展部署？

你可以在本书的评估中找到这些问题的答案。

进一步阅读