autoscaler

一、什么是弹性伸缩 Horizontal Pod Autoscaler的操作对象是Replication Controller、ReplicaSet或Deployment对应的Pod，根据观察到的CPU使用量与用户的阈值进行比对，做出是否需要增减实例数量的决策。controller目前使用heapSter来检测CPU使用量，检测周期默认是30秒 二、创建hpa nginx-rc.yaml [root@master hpa]# cat nginx-rc.yaml apiVersion: v1 kind: ReplicationController metadata: name: myweb1 spec: replicas: 2 selector: app: myweb1 template: metadata: labels: app: myweb1 spec: containers: - name: myweb1 image: 192.168.118.18:5000/nginx:1.13 ports: - containerPort: 80 resources: limits: cpu: 100m memory: 50Mi requests: cpu: 100m memory: 50Mi 创建检查 [root@master hpa]# kubectl create -f nginx

serverless 无服务器架构（serverless），则表示代码可以只在需要时运行，在不需要时就停止，从而让你的基础设施能在其他方面自由使用计算资源。 Kaniko Kaniko 是 Google 造的轮子之一，用于在 Kubernetes 上无需特权的构建 docker image，在 github(https://github.com/GoogleContainerTools/kaniko) 中，是这样介绍的。 工作原理 传统的 Docker build 是 Docker daemon 根据 Dockerfile，使用特权用户（root）在宿主机依次执行，并生成镜像的每一层： 而 Kaniko 工作原理和此类似，也是按顺序执行每条命令，每条命令执行完毕后为文件系统做快照(snapshot)。并与上一个快照进行对比，如果发现任何不一致，变回创建一个新的层级，并将任何修改都写入镜像的元数据中。 参考：https://blog.ihypo.net/15487483292659.html 什么是 Knative Knative 的目标是在基于 Kubernetes 之上为整个开发生命周期提供帮助。它的具体实现方式是：首先使你作为开发人员能够以你想要的语言和以你想要的方式来编写代码，其次帮助你构建和打包应用程序，最后帮助你运行和伸缩应用程序。 Knative 主要由 Build

最近闲下来，打算把Knative的核心组件Serving给学习下，会继续采用k8s源码学习的方式，管中窥豹以小击大，学习serving的主要目标: 可观测性基础设施、自动伸缩、流量管理等核心组件的设计与实现，今天先简单臆测下，感兴趣的同学， 一起来学习吧 1. 基于云原生的单体应用构建 大多数公司的服务可能都已经经过单体、SOA演进到了当下流行的微服务架构，微服务给我们带来了独立演进、扩容、协作、数据自治等便利的背景下，也带来了诸如稳定性保障、维护、服务治理等实际的问题，我们今天来一起来回归单体，比如我们要新开一个业务，新上一个小的模块这个场景，在云原生的场景下，是如何玩的 1.1 云原生下的单体应用 云原生有很多大佬有很多的解释，我就简单理解成是基于云构建而来，可以使用云上所有已知的现有的服务，同时享受云所带来的弹性、按需付费、高可用等方面的原生能力 一个基础的单体应用通常会依赖如下几部分：持久化数据存储、高性能缓存、全文索引、消息队列等常见组件， 各家云厂商大多数会包含这些基础的服务，我们只需要引入对应的类库完成我们的应用逻辑即可, 然后程序就完成代码的coding后,下一步就是交付了 1.2 基于k8s的云原生交付 基于k8s的云原生已经成为一个事实上的标准，将代码和应用的数据打包成docker镜像，基于Pod的交付模式，让我们并不需要关注我们是使用IDC里面的实体机

作者 | 声东 阿里云技术专家 <关注公众号，回复 排查 即可下载电子书> 《深入浅出 Kubernetes》一书共汇集 12 篇技术文章，帮助你一次搞懂 6 个核心原理，吃透基础理论，一次学会 6 个典型问题的华丽操作！以下内容节选自本书： 阿里云 K8s 集群的一个重要特性，是集群的节点可以动态的增加或减少。有了这个特性，集群才能在计算资源不足的情况下扩容新的节点，同时也可以在资源利用率降低的时候，释放节点以节省费用。 这篇文章，我们将讨论阿里云 K8s 集群扩容与缩容的实现原理。理解实现原理，在遇到问题的时候，我们就可以高效地排查并定位原因。 虽然我们的讨论是基于1.12.6 版本的，但是理论上后续版本与这篇文章所述集群伸缩原理出入不大。 节点增加原理 阿里云 K8s 集群可以给集群增加节点的方式有，添加已有节点，集群扩容，和自动伸缩。其中，添加已有节点又可分为手动添加已有节点和自动添加已有节点。节点的增加涉及到的组件有，节点准备，弹性伸缩（ESS），管控，Cluster Autoscaler 以及调度器。 手动添加已有节点 节点准备，其实就是把一个普通的 ECS 实例，安装配置成为一个 K8s 集群节点的过程。这个过程仅靠一条命令就可以完成。这条命令使用 curl 下载 attach_node.sh 脚本，然后以 openapi token 为参数，在 ECS 上运行。

CoreDNS解析异常记录 异常情况：集群是用kubespray部署的4个worknode,coredns默认部署2个deployment。今天发现部署了coredns的node上的pod正常解析内部域名，而另外2个未运行coredns的node却无法解析。 配置文件： 下图中我们看到coredns2个pod分别在node1与node2上，只要分配到这2节点上的deployment都可以正常解析。 其他节点无法解析： 处理过程： 正常来说所有的pod都是通过coredns来进行集群内域名解析的，我也搞不清楚为啥其他两个node没有跑coredns则就无法解析后面再研究。所以我临时的解决方法是扩容coredns让每个node都跑。 1、修改 ConfigMap 中的 dns-autoscaler（coredns自动扩容保证高可用） kubectl edit configmap dns-autoscaler --namespace=kube-system 2、修改key：linear coresPerReplica： 按照核心数目来计算副本集（replicas = cores / coresPerReplica） nodesPerReplica：按照节点数目来计算副本集（replicas = nodes / nodesPerReplica） min：最小副本数（默认为2

作者 | 阿里云容器技术专家 莫源 本文整理自莫源于 8 月 31 日 K8s & cloudnative meetup 深圳场 的演讲内容。 关注“阿里巴巴云原生”公众号，回复关键词 “资料”， 即可获得 2019 全年 meetup 活动 PPT 合集及 K8s 最全知识图谱。 导读 ：Serverless 和 Autoscaling 是近些年来广大开发者非常关心的内容。有人说 Serverless 是容器 2.0，终有一天容器会和 Serverless 进行一场决战，分出胜负。实际上，容器和 Serverless 是可以共存并且互补的，特别是在 Autoscaling 相关的场景下，Serverless 可以与容器完美兼容，弥补容器场景在使用简单、速度、成本的缺欠，在本文中将会为大家介绍容器在弹性场景下的原理、方案与挑战，以及 Serverless 是如何帮助容器解决这些问题的。 当我们在谈论"弹性伸缩"的时候 当我们在谈论"弹性伸缩"的时候，我们在谈论什么？"弹性伸缩"对于团队中不同的角色有不同的意义，而这正是弹性伸缩的魅力所在。 从一张资源曲线图讲起 这张图是阐述弹性伸缩问题时经常引用的一张图，表示的是集群的实际资源容量和应用所需容量之间的关系。 其中红色的曲线表示的是应用实际所需的容量，因为应用的资源申请量相比节点而言会小很多，因此曲线相对比较平滑；

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者 | 贤维 阿里巴巴高级技术专家 导读 ：Serverless Kubernetes 是阿里云容器服务团队对未来 Kubernetes 演进方向的一种探索，通过对 Kubernetes 做减法，降低运维管理负担，简化集群管理，让 Kubernetes 从复杂到简单。 背景 Kubernetes 作为通用的容器编排系统，承载了广泛的应用和场景，包括 CI／CD，数据计算，在线应用，AI 等，然而由于其通用性和复杂性，管理一个 Kubernetes 集群对于很多用户而言还是充满挑战的，主要体现在： 学习成本高； 集群运维管理成本高，包括节点管理、容量规划，以及各种节点异常问题的定位； 计算成本在很多场景中没有达到最优，比如对于一个定时运行 Jobs 的集群，长期持有资源池对于用户来说是浪费的行为，资源利用率不高。 对 Kubernetes 集群做减法 无节点管理 我们相信未来用户会更加关注应用的开发，而不是基础设施的维护。体现在 Kubernetes 集群中，我们希望用户能够关注在 pod/service/ingress/job 等应用编排语义上，对底层 node 则可以减少关注。 无需管理节点也可以显著降低集群的运维管理成本，经统计 Kubernetes 常见的异常问题中大多数与节点相关，比如 Node

作者 | 陈俊、张晓宇、徐迪 业界要闻 KubeCon 2019 北美会议召开 业界最隆重的盛会 KubeCon+CloudNativeCon 今年在圣地亚哥举办，超过 12000 名参会者以及 100 多个云原生供应商出席了这次大会。本次大会中阿里巴巴经济体共有 8 个 Topic 亮相。 相关 Topic Fobes 挑选的 10 大最有趣官宣 KubeCon 北美 2019 年 PPT 合集分享 上游重要进展 1. Kubernetes 拟加入对 Cgroup v2 的支持 Kubernetes 的 Kubelet 和 Scheduler 拟加入对 Cgroup v2 的支持。 Cgroup v2 的一个大的特性是可以用非 root 用户操作做资源限制。该 KEP 的实现和下文的 《 使用非 root 权限模式运行 Kubernetes 组件 》KEP 息息相关。 2. 使用非 root 权限模式运行 Kubernetes 组件 目前有众多的厂商尝试使用非 root 的模式去运行 kubelet 组件和 CRI/OCI/CNI，但是因为一些接口需要使用 root 的权限不能实现。此 KEP 着重去改善 kubelet、kube-proxy 对于这方面的限制，同时 CRI/OCI/CNI 也有相关的工作去推进可以使用非 root 模式运行。 3. 提供 Immutable

作者：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或内存触发，以根据需要向上或向下扩展。但是，也可以根据各种外部的和自定义指标

作者 | 陈俊、张晓宇、徐迪 业界要闻 KubeCon 2019 北美会议召开 业界最隆重的盛会 KubeCon+CloudNativeCon 今年在圣地亚哥举办，超过 12000 名参会者以及 100 多个云原生供应商出席了这次大会。本次大会中阿里巴巴经济体共有 8 个 Topic 亮相。 相关 Topic Fobes 挑选的 10 大最有趣官宣 KubeCon 北美 2019 年 PPT 合集分享 上游重要进展 1. Kubernetes 拟加入对 Cgroup v2 的支持 Kubernetes 的 Kubelet 和 Scheduler 拟加入对 Cgroup v2 的支持。 Cgroup v2 的一个大的特性是可以用非 root 用户操作做资源限制。该 KEP 的实现和下文的 《 使用非 root 权限模式运行 Kubernetes 组件 》KEP 息息相关。 2. 使用非 root 权限模式运行 Kubernetes 组件 目前有众多的厂商尝试使用非 root 的模式去运行 kubelet 组件和 CRI/OCI/CNI，但是因为一些接口需要使用 root 的权限不能实现。此 KEP 着重去改善 kubelet、kube-proxy 对于这方面的限制，同时 CRI/OCI/CNI 也有相关的工作去推进可以使用非 root 模式运行。 3. 提供 Immutable