VPA

： 你填了吗？10人将获赠CNCF商店$100美元礼券！ 来参与2020年CNCF中国云原生调查 问卷链接（ https://www.wjx.cn/jq/97146486.aspx ） 配置 readiness、liveness 和 startup 探针可以处理不健康的 Pod，本文介绍了三种类型的探针、最佳实践和有关工具，以检测可能存在的配置问题。 作者：Yitaek Hwang 翻译：Bach（才云） 校对：木子（才云） 分 布式系统和微服务体系结构的挑战之一是自动检测不正常的应用程序，并将请求（request）重新路由到其他可用系统，恢复损坏的组件。健康检查是应对该挑战的一种可靠方法。 使用 Kubernetes，可以通过探针配置运行状况检查，以确定每个 Pod 的状态。 默认情况下，Kubernetes 会观察 Pod 生命周期，并在容器从挂起（pending）状态转移到成功（succeeded）状态时，将流量路由到 Pod。Kubelet 会监控崩溃的应用程序，并重新启动 Pod 进行恢复。许多开发人员认为这样的基本设置就足够了，尤其是当 Pod 内的应用程序还配置了守护进程管理器（例如 Node.js 的 PM2）时。 但有一种意外情况，当 Kubernetes 在所有容器启动后，认为 Pod 是健康且可以接受请求时，但应用程序在实际准备就绪之前就已收到流量

[TOC] 转载请注明出处，文章转自 FingerLiu 0x0 pre 弹性伸缩这种功能，不是很多系统都已经实现了，我们直接用就行了吗，为什么还需要个指南呢。 因为。。。。我们先来看看都有哪些相关知识点吧。。。 弹性伸缩涉及到各种软硬件，各色调度平台，策略和系统，其本身就是一个较复杂的课题。此外，kubernetes 不单单是一个容器调度平台，而是一个活跃，庞大的生态系统。 kubernetes 弹性伸缩 这个课题涉及了诸多知识点，主要如下： - 水平(Horizontal)伸缩 - 垂直(Vertical)伸缩 - 定时(Scheduled)伸缩 - 预测(Predictive)性伸缩 - 服务画像 - node - service - CA - cloudprovider - VPA - HPA - HPA controller - metric - metric server - heapster - metric state - prometheus - CRD - custom metric api - prometheus adapter - cronhpa controller - cloud controller manager 在刚开始调研这个课题的时候，一上来看到这么多名词和术语，肯定会一脸懵逼的。终于， 在知识的海洋中遨游了好一阵后，终于了摸索出一条路

作者：Kim Wuestkamp 翻译： Bach （才云） 校对： bot （才云）、 星空下的文仔 （才云） 在生产环境中使用 Kubernetes 之前，我们应该了解 K8s 的资源管理，资源管理的核心就是 Kubernetes 调度器处理资源请求和限制。 K8sMeetup Pod 资源 在 K8s 中，一个 Pod 可以包含一个或多个容器，这些容器通常由 Docker 运行。 Pod 可以看做是容器的外包装，这二者会在同一台机器或节点上运行。一般来说，总的 Pod 资源就等于容器资源的总和。 资源请求和限制 为每个容器制定资源请求和限制，例如： 请求是保证得到的资源，其他 Pod 不可以使用这些资源。限制是允许使用比请求更多的资源。如果容器达到规定的限制，会被 CPU 超售并驱逐出内存。 K8sMeetup 调度器 K8s 调度器负责确定 Pod 可以在哪个节点上运行，它通过查看各种配置（例如亲和度、taints、tolerations）来实现。这里我们仅关注主要配置：闲置资源（free resources）。当调度器做出有关“闲置资源”的决定时，它会查看两个数据：Node Allocatable 和 Node Requests。 节点的 Allocatable 与容量 调度器会查看节点的 Allocatable，它是整个节点减去 Kubelet 的保留资源。

format long %设置为小数点后 知9位 format short %设置为小数点后4位 vpa(pi,200) %设置pi为小数点后200位 来源： oschina 链接： https://my.oschina.net/u/4314546/blog/4256647

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Author: xidianwangtao@gmail.com 摘要：Kubernetes的资源编排调度使用的是静态调度，将Pod Request Resource与Node Allocatable Resource进行比较来决定Node是否有足够资源容纳该Pod。静态调度带来的问题是，集群资源很快被业务容器分配完，但是集群的整体负载非常低，各个节点的负载也不均衡。本文将介绍优化Kubernetes集群负载的多种技术方案。 Kubernetes为什么使用静态调度 静态调度，是指根据容器请求的资源进行装箱调度，而不考虑节点的实际负载。静态调度最大的优点就是调度简单高效、集群资源管理方便，最大的缺点也很明显，就是不管节点实际负载，极容易导致集群负载不高。 Kubernetes为什么会使用静态调度呢？因为要做好通用的动态调度几乎是不可能的，对，是通用的动态调度很难都满足不同企业不同业务的诉求，结果可能适得其反。那是不是我们就没必要去往动态调度做技术尝试呢？未必！平台根据托管的业务属性，可以适当的通过scheduler extender的方式扩展Kubernetes Scheduler来做一定权重的动态调度决策。 集群资源构成 以cpu资源为例，一个大规模Kubernetes集群的资源组成结构大致如下：

作者：Juan Ignacio Giro 译者：段访 审校：罗广明 原文： https://caylent.com/kubernetes-autoscaling 编者按 许多Kubernetes用户，特别是那些企业级用户，很快就遇到了对环境自动缩放的需求。幸运的是，Kubernetes Horizontal Pod Autoscaler（HPA）允许您将部署配置为以多种方式水平扩展。使用Kubernetes Autoscaling的最大优势之一是您的集群可以跟踪现有Pod的负载能力，并计算是否需要更多的Pod。 Kubernetes Autoscaling 通过协调内置的两层可扩展性，可以充分利用高效的Kubernetes Autoscaling： Pod级别的自动缩放：包括Horizontal Pod Autoscaler（HPA）和Vertical Pod Autoscaler（VPA）; 两者都可以扩展容器的可用资源。 集群级别的自动缩放：集群自动调节器（CA）通过在必要时向上或向下扩展集群内的节点数来管理这种可扩展性平面。 Kubernetes Autoscaling 详情 Horizontal Pod Autoscaler（HPA） HPA会在集群中缩放Pod副本的数量。该操作由CPU或内存触发，以根据需要向上或向下扩展。但是，也可以根据各种外部的和自定义指标

Author: xidianwangtao@gmail.com 摘要：Kubernetes的资源编排调度使用的是静态调度，将Pod Request Resource与Node Allocatable Resource进行比较来决定Node是否有足够资源容纳该Pod。静态调度带来的问题是，集群资源很快被业务容器分配完，但是集群的整体负载非常低，各个节点的负载也不均衡。本文将介绍优化Kubernetes集群负载的多种技术方案。 Kubernetes为什么使用静态调度 静态调度，是指根据容器请求的资源进行装箱调度，而不考虑节点的实际负载。静态调度最大的优点就是调度简单高效、集群资源管理方便，最大的缺点也很明显，就是不管节点实际负载，极容易导致集群负载不高。 Kubernetes为什么会使用静态调度呢？因为要做好通用的动态调度几乎是不可能的，对，是通用的动态调度很难都满足不同企业不同业务的诉求，结果可能适得其反。那是不是我们就没必要去往动态调度做技术尝试呢？未必！平台根据托管的业务属性，可以适当的通过scheduler extender的方式扩展Kubernetes Scheduler来做一定权重的动态调度决策。 集群资源构成 以cpu资源为例，一个大规模Kubernetes集群的资源组成结构大致如下： 由以下几部分组成： 每个节点的预留资源，对应kubelet的system

作者<br />阿里云容器平台技术专家 王程<br />阿里云容器平台技术专家 张晓宇（衷源） <a name="Ga22a"></a> 引子 不知道大家有没有过这样的经历，当我们拥有了一套 Kubernetes 集群，然后开始部署应用的时候，我们应该给容器分配多少资源呢？很难说。由于 Kubernetes 自己的机制，我们可以理解容器的资源实质上是一个静态的配置。如果我发发现资源不足，为了分配给容器更多资源，我们需要重建 Pod。如果分配冗余的资源，那么我们的 worker node 节点似乎又部署不了多少容器。试问，我们能做到容器资源的按需分配吗？这个问题的答案，我们可以在本次分享中和大家一起进行探讨。 首先允许我们根据我们的实际情况抛出我们实际生产环境的挑战。或许大家还记的，2018 的天猫双 11，一天的总成交额达到了 2135 亿。由此一斑可窥全豹，能够支撑如此庞大规模的交易量背后的系统，其应用种类和数量应该是怎样的一种规模。在这种规模下，我们常常听到的容器调度，如：容器编排，负载均衡，集群扩缩容，集群升级，应用发布，应用灰度等等这些词，在被超大规模集群这个词修饰后，都不再是件容易处理的事情。规模本身也就是我们最大的挑战。如何运营和管理好这么一个庞大的系统，并遵循业界 dev-ops 宣传的那样效果，犹如让大象去跳舞。但是马老师说过，大象就该干大象该干的事情