删除pod时创建的pod数量超过指定数量
我在AWS上的Kubernetes集群中部署了HashiCorp的存储库，使用了Helm图。
部署中的副本数指定为3。
在这3个POD中，1已就绪(1/1)，而其他两个副本POD尚未就绪(0/1)。我杀死了准备就绪的吊舱，虽然预计Kubernetes将部署一个新的吊舱来取代它，但它部署了两个新的吊舱。
现在我有两个准备好的吊舱和两个没有准备好的吊舱。删除其中一个豆荚后，现在库伯内特斯只重新创建一个豆荚。因此我有4而不是3POD用于我的存储库部署。这背后的原因是什么？我们如何防止这一现象？
共有1个答案
由于使用s3存储后端时HA（高可用性）不可用，您的部署无法工作。您将需要HashiCorp的Consult或AWS的DynamoDB或其他后端提供商。如果坚持使用s3后端提供程序,请将副本数更改为1。
至于为什么你看到4个豆荚而不是3个，你需要提供更多的细节。粘贴kubectl get pods-l app=vault以及kubectl description deploy-l app=vault的输出，我将更新这个答案。
我只能为它的价值提供推测。对于部署对象，有一个maxsurg属性，它允许滚动更新扩展到所需的副本数之外。它默认为25%，四舍五入，在您的情况下，这将是一个额外的1豆荚。
最大浪涌
.spec.strategy.rollingupdate.maxsurg是一个可选字段，用于指定可以在所需的POD数上创建的最大POD数。该值可以是绝对数（例如，5)，也可以是所需豆荚的百分比（例如，10%)。如果MaxUnavailable为0，则该值不能为0。绝对数由百分比四舍五入计算。默认值为25%。
例如，当该值设置为30%时，当滚动更新开始时，新的副本集可以立即按比例放大，这样新旧POD的总数不会超过所需POD的130%。一旦旧的pod被杀死，新的副本集可以进一步放大，确保在更新期间任何时间运行的pod总数最多为所需pod的130%。
删除一个running(1/1)pod以及其他pod的NotReady状态，可能会使部署进入“滚动更新”或类似的状态，从而允许部署扩展到其maxsurg设置。
-
我为kubernetes api服务器上的POD创建了如下限制 如果我理解正确，如果pod在创建pod时超出了用户定义的资源限制，kubernetes会拒绝pod。所以，我尝试创建一个新的pod，它通过了资源限制，然后我尝试消耗资源达到最大限制资源，但它对pod没有任何影响。LimitsRange和ResourceQuota插件是否包含在本案例中？如果没有，我如何在创建资源吊舱后限制资源吊舱？
-
当我尝试使用读取此pod的日志时，它不会返回任何内容。如何查看日志以了解状态为“挂起”的原因？
-
Kubernetes中需要考虑三个级别的度量集合—节点、Pod和在Pod中运行的应用程序。 对于节点和应用程序指标，我有非常有效的解决方案，但我仍停留在pod指标上。 我尝试过cAdvisor和Kube状态指标，但它们都没有给我想要的东西。Kube状态指标仅提供已知的信息，例如pod CPU限制和请求。cAdvisor不会将pod标签插入容器名称，因此我无法知道哪个pod行为不端。 给定一个pod
-
我正在运行 jenkins 作业来构建我们的 maven 应用程序并部署到 kubernetes 集群中。为此，我创建了 Pod 容器模板来部署我的模块。 当我运行构建我的jenkins作业时，我的构建失败，出现以下错误， 与此同时，当我检查kubernetes主服务器时，我可以看到pods正在尝试调度，并且在几秒钟后返回到终止状态。 管道脚本 请在下面找到主机配置 kubectl错误日志 你能请
-
当我尝试将部署创建为类型作业时，它不会提取任何图像。 下面是. yaml： 你能在这里引路吗？ 问候，维卡斯