Question

我有一个运行在Google Kubernetes引擎上的Kubernetes集群。

我有一个部署，我手动（通过编辑hpa对象）将其从100个副本扩展到300个副本，以进行一些负载测试。当我通过向服务发送HTTP请求来对部署进行负载测试时，似乎并不是所有的Pod都获得了相同的流量，只有大约100个Pod显示正在处理流量（通过查看其CPU负载，我们的自定义指标）。因此，我怀疑该服务没有在所有Pod之间平均地平衡请求的负载。

如果我检查了deployment，则可以看到所有300个副本已经准备就绪。

$ k get deploy my-app --show-labels
NAME                DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE       LABELS
my-app              300       300       300          300         21d       app=my-app

另一方面，当我检查service时，我看到了：

$ k describe svc my-app
Name:              my-app
Namespace:         production
Labels:            app=my-app
Selector:          app=my-app
Type:              ClusterIP
IP:                10.40.9.201
Port:              http  80/TCP
TargetPort:        http/TCP
Endpoints:         10.36.0.5:80,10.36.1.5:80,10.36.100.5:80 + 114 more...
Port:              https  443/TCP
TargetPort:        https/TCP
Endpoints:         10.36.0.5:443,10.36.1.5:443,10.36.100.5:443 + 114 more...
Session Affinity:  None
Events:            <none>

对我来说奇怪的是这部分

Endpoints:         10.36.0.5:80,10.36.1.5:80,10.36.100.5:80 + 114 more...

我原本希望在那里看到300个端点，这个假设正确吗？

（我也发现了this post，这与一个类似的问题有关，但是在此之前，作者仅经历了几分钟的延迟，直到端点被更新为止，但是对我来说，即使在半个小时内也没有变化）

如何解决出现的问题？我读到这是由Endpoints控制器完成的，但是我找不到有关在哪里检查其日志的任何信息。

更新：我们设法重现了几次。有时情况不太严重，例如381个端点而不是445个端点。我们注意到的一件有趣的事情是，如果我们检索了端点的详细信息，则：

$ k describe endpoints my-app
Name:         my-app
Namespace:    production
Labels:       app=my-app
Annotations:  <none>
Subsets:
  Addresses:          10.36.0.5,10.36.1.5,10.36.10.5,...
  NotReadyAddresses:  10.36.199.5,10.36.209.5,10.36.239.2,...

然后，一堆IP被“卡住”在NotReadyAddresses状态下（如果我将Addresses和{{ 1}}，这仍然少于准备就绪的广告连播的总数。尽管我根本不知道这是否相关，但是我无法在线找到有关此NotReadyAddresses字段的太多信息。

Answer 1

原来，这是由于在我们的节点池中使用抢占式VM引起的，如果节点不是premétible，则不会发生。
我们无法找到更多根本原因的详细信息，但是无论如何都没有将prememibles用作节点，因此我们切换到常规VM。

Answer 2

我指的是您第一次尝试300个豆荚。

我会检查以下内容：

kubectl get po -l app=my-app，查看是否有300个项目列表。您的服务表明您有300个可用吊舱，这使您的问题分析起来非常有趣。
您的广告连播/部署清单是否定义了限制和请求资源。这样可以更好地帮助调度程序。
您的某些节点是否有与您的pod /部署清单不兼容的污渍
您的pod /部署清单是否有活动和准备就绪探针（请发布）
是否定义了一些resourceQuota对象，该对象限制了吊舱/部署的创建

Answer 3

如果运行状况/就绪性探针失败，则可以将

Pod IP添加到NotReadyAddresses。反过来，这会导致Pod IP无法自动添加到端点，这意味着kubernetes服务无法连接到Pod。

如何解决服务中的端点为何不更新的问题？

3 个答案: