Question

我在AWS上安装了istio的EKS集群是第一次安装istio，我使用了一个m3.large EC2实例，并且我有一些istio服务处于待处理状态，入口网关Pod状态显示为待处理。

我描述了Pod，发现CPU不足的错误。...我将EC2实例增加到m5.large，每个Pod开始运行。.

我们实际上正在分期进行，并且尚未投入使用，我们的支出几乎是初始成本的3倍。

有人可以推荐一个可以方便地启动和运行istio的EC2实例，让我们看看bookinfo示例应用程序。

Type     Reason            Age                   From               Message
  ----     ------            ----                  ----               -------
  Warning  FailedScheduling  2m33s (x60 over 12m)  default-scheduler  0/1 nodes are available: 1 Insufficient cpu.

设置2个m5.large实例似乎可以很好地工作，但这会产生更多的成本。每个m5.large实例的成本为0.107 USD /小时，即77 USD /月。

拥有两个m5.large实例将确保仅运行15个Pod（5个自定义Pod）的成本更高

Non-terminated Pods:         (15 in total)

Answer 1

如果您查看AWS instance types listing，则m5.large实例非常小：它只有2个CPU内核。另一方面，如果您查看kubectl get pods --all-namespaces清单，则可以看到运行核心Kubernetes系统涉及很多pod（在多节点安装中的每个节点上都复制了其中的几个）

如果2个核心不够用，可以尝试选择更大的实例大小；如果2倍m5.large可以工作，那么1倍m5.2xlarge会更好一点，并且成本不变。如果您只在运行这样的演示应用程序，则“ c”系列的内存只有一半（每个内核2 GiB），并且价格便宜一些，因此您可以尝试使用c5.2xlarge。

对于中等规模的工作负载，我建议弄清您的集群总需求（基于Pod的资源请求或Prometheus之类的工具的实际统计信息）；将其划分为一定数量的工作程序节点，这样就不会丢失一个重要问题（可能是7个或9个）；然后选择适合的实例大小。在更少，更大的节点上运行比在更大，更小的节点上运行更容易（一个需要8 GB RAM的Pod可以容纳更多的位置）。

（我通常需要为诸如Docker Desktop for Mac或kind之类的桌面环境分配4-8 GB的内存，但仍然发现局促； CPU通常不是我的限制，但我可以轻易相信2核并且仅8 GiB的RAM是不够的。）

（是的，AWS对于个人项目来说是相当昂贵的，没有附加明显的收入来源。如果您愿意预先支付该金额，则可以每年约$ 500的价格购买m5.large实例，但是仍然可以可以玩很多东西。）

Answer 2

部署由不同数量的组件组成。一些作为试点，它们对内存和CPU的影响很大，因此建议您的计算机中大约有8GB的内存和4个CPU 簇。显然，所有组件都要求定义资源，因此，如果您没有足够的容量，则会看到豆荚无法启动。

在使用 M5大的地方

m5.large    2 CPU   8 Memory    EBS-Only

因此，在上述要求的基础上，您需要

m5.xlarge   4 CPU   16 Memory   EBS-Only

如果您的应用程序需要大量计算，则可以尝试计算优化实例。

计算优化的实例是计算绑定应用程序的理想选择   受益于高性能处理器。它们非常适合   用于以下应用：

批处理工作量

媒体转码

高性能Web服务器

高性能计算（HPC）

科学建模

专用游戏服务器和广告服务引擎

机器学习推理和其他计算密集型应用

compute-optimized-instances

deploying-istio on AWS and azure recommendation

可能会帮助您

https://aws.amazon.com/blogs/opensource/getting-started-istio-eks/

Answer 3

TL; DR对于许多要求，Istio中的默认请求非常贪婪。您需要使用自己的values.yaml（假设您正在使用Helm）来更改它们，并监视Istio实际使用了多少资源。使用越来越大的实例类型是一个不好的解决方案（除非您确实确实消耗了默认请求，或者您喜欢将钱花在墙上）。

问题在于Istio在使用默认配置文件时会发出一些非常大的 Requests 。这意味着即使您有足够的可用资源，kubernetes也会拒绝调度许多Istio控制平面组件。

[我假设您熟悉kubernetes的请求。如果不是，这些是pod yaml中的声明，“此pod需要x cpu和y内存才能舒适地运行”。然后，Kubernetes Pod调度程序将确保将Pod调度到具有足够资源的节点上。问题是，许多人把手伸向空中，并为“确定”投入了巨大的价值。但这意味着，如果吊舱实际上并不需要该资源 ]

，则会浪费大量可用资源。

此外，每个侧斗车也会根据压力施加较大的请求。

这就是为什么您看到吊舱卡在待处理状态的原因。

我不是100％相信Istio团队设置的默认请求实际上是合理的[edit：对于bookinfo，当然不是。我怀疑甚至为数千个节点设置了默认值]。我建议在增加实例大小（进而增加成本）之前，请考虑减少Istio控件和数据平面的请求。

如果您随后发现自己的Istio组件经常被淘汰，那您就太过分了。

示例：使用提供的Helm values.yaml文件here，我们为每个小车都准备好了

：

  requests:
    cpu: 100m
    memory: 128Mi

（第155-157行）。

更令人担忧的是，default memory request for Pilot是2Gb！这意味着您将要放弃大量的Node（或者可能是整个Node）。那只适合飞行员-同一家商店适用于Galley，Citadel，Telemetry等，等等。

您需要监视正在运行的群集，并且是否可以确定可以减少这些值。例如，我有一个相当繁忙的集群（比可怜的bookinfo复杂得多），指标服务器告诉我Pilot的cpu是8millicore（！）和内存62Mi。因此，如果我盲目地坚持默认设置（大多数人都会这样做），那我将浪费近2Gb的内存和一半的CPU。

在这里查看我的输出：我强调这是来自长期运行的生产标准集群：

[ec2-user@ip-172-31-33-8 ~]$ kubectl top pod -n istio-system
NAME                                      CPU(cores)   MEMORY(bytes)
istio-citadel-546575dc4b-crnlj            1m           14Mi
istio-galley-6679f66459-4rlrk             19m          17Mi
istio-ingressgateway-b9f65784b-k64th      1m           22Mi
istio-pilot-67bfb94df4-j7vld              8m           62Mi
istio-policy-598b768ddc-cvs2b             5m           39Mi
istio-sidecar-injector-578bc4cc74-n5v6w   11m          7Mi
istio-telemetry-cd6fddc4b-lt8rl           27m          57Mi
prometheus-6ccfbc78c-w4dd6                25m          497Mi

A more readable guide to the defaults is here.。运行整个控制平面的请求，并添加所需的cpu和内存。有很多资源。

这是一项艰苦的工作，但是您需要坐下来确定每个组件的真正需求，设置自己的values.yaml并为Istio生成自己的yaml。 Istio提供的演示yaml并不合理，尤其是对于像bookinfo这样的米老鼠应用程序而言，应将它们从后门取出，避免其痛苦。请记住，Istio最初是与大规模的数千个节点群集一起开发的。

Istio bookinfo示例应用程序推荐的EC2实例是什么？

3 个答案: