Kubernetes pod 自动缩放与实例组自动缩放不同步
Kubernetes pod autoscaling out of sync with Instance Group autoscaling
我有一个简单的 wordpress 站点，由下面的 ReplicationController 和 Service 定义。部署应用程序并 运行 愉快地完成后，我通过转到 GCE 控制台并使用相同的设置（最大 5，cpu 10）启用 Kubernetes 创建的实例组的自动缩放。
Autoscaling 实例和 pods 似乎工作得很好，只是它们彼此不同步。 RC 自动缩放从 CE 实例中删除 pods 但实例没有任何反应，因此它们开始失败请求，直到 LB 健康检查失败并删除它们。
有没有办法让 kubernetes 扩展 pods 以及扩展它们 运行 的实例，这样就不会发生这种情况？或者有没有办法让它们保持同步？
我的流程如下：
创建集群
$ gcloud container clusters create wordpress -z us-central1-c -m f1-micro
创建 rc
$ kubectl create -f rc.yml
创建服务
$ kubectl create -f service.yml
自动缩放 rc
$ kubectl autoscale rc frontend --max 5 --cpu-percent=10
然后我在控制台中启用了自动缩放并给服务器加载以使其缩放。
rc.yml
apiVersion: v1
kind: ReplicationController
metadata:
name: frontend
spec:
replicas: 1
template:
metadata:
labels:
app: wordpress
spec:
containers:
- image: custom-wordpress-image
name: wordpress
ports:
- containerPort: 80
hostPort: 80
service.yml
apiVersion: v1
kind: Service
metadata:
labels:
name: frontend
name: frontend
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
name: wordpress
更新以获取更多信息
如果我不使用 kubernetes autoscaler 而是将副本设置为与实例组 autoscaler 最大实例数相同的数量，我似乎得到了想要的结果。当实例被添加到实例组时，kubernetes 会配置它们，因为它们会被删除，kubernetes 会相应地更新。在这一点上，我想知道 Kubernetes autoscaler 的目的是什么。
据我了解，kubernetes autoscaler 功能主要用于 RC 和部署为其子项定义了 cpu 限制的情况。您可以使用 pods 的最小和最大数量以及 pods 的目标 CPU 用法定义自动缩放器，它将根据这些限制在集群中缩放 pods不管集群大小。如果 pods 没有限制，那么您可能希望扩展集群并为每个额外的节点安排一个额外的 pod，尽管我不确定这是否符合容器化服务的最佳实践，因为集群中的任何节点 运行可以控制一个无限的 pod，这可能会对其他 pods 的能力产生不利限制 运行。是比较难以预测的。
TLDR;
在您的用例中，kubernetes 只会给您带来开销。您在实例组中的每个实例上都有 运行 1 个 pod（docker 容器）。您还可以将 Docker 容器部署到 App Engine 灵活（以前的托管 VM）https://cloud.google.com/appengine/docs/flexible/custom-runtimes/ 并让实例组的自动缩放处理它。
更长的答案
不可能（还）link 实例扩展到 k8s 中的 pod 扩展。这是因为它们是两个不同的问题。 k8s 的 HPA 旨在具有（小）pods 扩展以将负载分散到集群（大型机器）上，因此它们将随着负载的增加而扩展。
如果您没有定义任何限制（每台机器 1 个 pod），您可以将 pods 的最大数量设置为集群的最大扩展有效地设置所有这些 pods 在 pending 状态，直到另一个实例启动。
如果您希望 pods 让您的节点扩展，那么最好的方法（我们发现）是让它们 'overcrowd' 一个实例，这样实例组扩展就会开始。我们通过为我们的 pods 和高限制设置相当低的 memory/cpu 要求来做到这一点，有效地允许它们突破实例的总可用 CPU/memory。
resources:
requests:
cpu: 400m
memory: 100Mi
limits:
cpu: 1000m
memory: 1000Mi
随着 Kubernetes 1.3 autoscaling 的新增功能，我现在可以让 Kubernetes 自动缩放我的集群和我的 pods。
使用 GCP's create command 我现在可以使用 --enable-autoscaling 结合 --min-nodes、--max-nodes 和 --num-nodes 轻松添加自动缩放集群。
我有一个简单的 wordpress 站点，由下面的 ReplicationController 和 Service 定义。部署应用程序并 运行 愉快地完成后，我通过转到 GCE 控制台并使用相同的设置（最大 5，cpu 10）启用 Kubernetes 创建的实例组的自动缩放。
Autoscaling 实例和 pods 似乎工作得很好，只是它们彼此不同步。 RC 自动缩放从 CE 实例中删除 pods 但实例没有任何反应，因此它们开始失败请求，直到 LB 健康检查失败并删除它们。
有没有办法让 kubernetes 扩展 pods 以及扩展它们 运行 的实例，这样就不会发生这种情况？或者有没有办法让它们保持同步？
我的流程如下：
创建集群
$ gcloud container clusters create wordpress -z us-central1-c -m f1-micro
创建 rc
$ kubectl create -f rc.yml
创建服务
$ kubectl create -f service.yml
自动缩放 rc
$ kubectl autoscale rc frontend --max 5 --cpu-percent=10
然后我在控制台中启用了自动缩放并给服务器加载以使其缩放。
rc.yml
apiVersion: v1
kind: ReplicationController
metadata:
name: frontend
spec:
replicas: 1
template:
metadata:
labels:
app: wordpress
spec:
containers:
- image: custom-wordpress-image
name: wordpress
ports:
- containerPort: 80
hostPort: 80
service.yml
apiVersion: v1
kind: Service
metadata:
labels:
name: frontend
name: frontend
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
name: wordpress
更新以获取更多信息
如果我不使用 kubernetes autoscaler 而是将副本设置为与实例组 autoscaler 最大实例数相同的数量，我似乎得到了想要的结果。当实例被添加到实例组时，kubernetes 会配置它们，因为它们会被删除，kubernetes 会相应地更新。在这一点上，我想知道 Kubernetes autoscaler 的目的是什么。
据我了解，kubernetes autoscaler 功能主要用于 RC 和部署为其子项定义了 cpu 限制的情况。您可以使用 pods 的最小和最大数量以及 pods 的目标 CPU 用法定义自动缩放器，它将根据这些限制在集群中缩放 pods不管集群大小。如果 pods 没有限制，那么您可能希望扩展集群并为每个额外的节点安排一个额外的 pod，尽管我不确定这是否符合容器化服务的最佳实践，因为集群中的任何节点 运行可以控制一个无限的 pod，这可能会对其他 pods 的能力产生不利限制 运行。是比较难以预测的。
TLDR;
在您的用例中，kubernetes 只会给您带来开销。您在实例组中的每个实例上都有 运行 1 个 pod（docker 容器）。您还可以将 Docker 容器部署到 App Engine 灵活（以前的托管 VM）https://cloud.google.com/appengine/docs/flexible/custom-runtimes/ 并让实例组的自动缩放处理它。
更长的答案
不可能（还）link 实例扩展到 k8s 中的 pod 扩展。这是因为它们是两个不同的问题。 k8s 的 HPA 旨在具有（小）pods 扩展以将负载分散到集群（大型机器）上，因此它们将随着负载的增加而扩展。
如果您没有定义任何限制（每台机器 1 个 pod），您可以将 pods 的最大数量设置为集群的最大扩展有效地设置所有这些 pods 在 pending 状态，直到另一个实例启动。
如果您希望 pods 让您的节点扩展，那么最好的方法（我们发现）是让它们 'overcrowd' 一个实例，这样实例组扩展就会开始。我们通过为我们的 pods 和高限制设置相当低的 memory/cpu 要求来做到这一点，有效地允许它们突破实例的总可用 CPU/memory。
resources:
requests:
cpu: 400m
memory: 100Mi
limits:
cpu: 1000m
memory: 1000Mi
随着 Kubernetes 1.3 autoscaling 的新增功能，我现在可以让 Kubernetes 自动缩放我的集群和我的 pods。
使用 GCP's create command 我现在可以使用 --enable-autoscaling 结合 --min-nodes、--max-nodes 和 --num-nodes 轻松添加自动缩放集群。