Kubernetes 集群的云原生最佳实践：在 AWS、Azure 和 GCP 上的实现指南 (kubernetes怎么读)

---

Kilo 使用教程

本文将详细介绍如何在云原生环境中使用Kilo进行WireGuard的应用，尤其是针对Kubernetes集群的组网。 对于WireGuard新手，建议按照特定顺序阅读相关教程，以便更好地理解。 云原生领域中，Kilo主要用于CNI，可以与Flannel、Wormhole结合提供加密，或者单独作为组网工具。 对于组网需求，推荐使用Kilo，尤其是当需要在AWS、Azure、GCP和阿里云的云主机之间构建一个无缝的k3s集群，且允许跨设备访问Pod和Service IP时。 实现这一目标分为两步：首先，通过Kilo调整k3s集群节点间的容器网络，取消默认CNI；重启服务器后，可以选择Kilo作为CNI。 Kilo支持三种网络拓扑：逻辑分组互联、全互联和混合模式，具体操作需要根据节点的特定情况进行调整。 以全互联模式为例，部署Kilo需要拷贝kubeconfig、修改API地址、添加节点注解并克隆Kilo官方仓库进行配置。 部署成功后，节点将新增网络接口，用于实现跨云容器通信。 接下来，需要创建新的网络接口wg0，以本地网络访问云上的Pod和Service IP。 通过wg-gen-web管理WireGuard配置，并根据每个节点的需要调整，以实现跨设备访问。 最后，通过本地运行WireGuard，你将能够轻松地在云主机的Kubernetes集群中自由穿梭。 本文已涵盖Kilo的部署和基本网络配置，对于进一步优化如通过CoreDNS访问服务名称，读者可自行探索。 最后，欢迎访问获取Kubernetes离线安装包和sealos的最新特性，以及加入钉钉群获取更多实时信息。

云原生是什么？（入门科普）

云原生，这一概念近年来在科技圈内颇为流行，但它对于非专业人士来说，往往显得有些晦涩难懂。 本文旨在以较为通俗的语言，提供一个云原生的入门级科普，帮助你理解这一术语的基本含义及其核心理念。 云原生，直译自“Cloud Native”，指的是设计与构建旨在云环境中运行的应用与服务，这一概念的核心在于利用云计算资源的弹性和灵活性，以实现应用的高效部署、管理和扩展。 云计算，作为云原生的基础，提供了一种基于互联网的计算资源服务模式。 通过云计算，用户可以租用各种基础设施，如服务器、存储和网络资源等，实现高效资源利用和成本节约。 云计算服务商，如AWS、Azure、阿里云、谷歌云、IBM云、腾讯云、华为云等，通过统一管理大量基础设施，实现资源的动态分配，支持按需使用，备份与恢复简便，以及快速部署与集成。 云原生技术集合了容器、服务网格、微服务、不可变基础设施和声明式API等关键概念，旨在构建容错性好、易于管理且便于观察的松耦合系统，通过可靠的自动化手段，实现应用的频繁和可预测的重大变更。 微服务是云原生架构中的核心概念，它将应用拆分为一系列松散耦合的组件，每个组件负责特定功能，通过容器技术实现独立部署和扩展，从而提高了系统的灵活性和可维护性。 容器技术，如Docker，为微服务提供了统一的运行环境，使得应用能够在不同环境中轻松部署。 Kubernetes（K8s）作为容器编排平台的代表，简化了容器化的微服务管理，支持大规模部署和自动伸缩。 服务网格，通过解决微服务间的网络相关问题，如通信、安全和监控，进一步优化了微服务架构的协作效率。 不可变基础设施强调应用运行环境的稳定性和一致性，避免了手动配置和维护的复杂性，促进了一键部署的实现。 声明式API的使用，简化了代码编写和管理，使得应用状态的调整更加直观和高效。 自动化交付方法，如持续集成/持续部署（CI/CD）或DevOps，与云原生技术紧密结合，提高了应用开发和部署的效率。 云原生技术并非适用于所有场景，它在需要快速迭代、灵活扩展的应用场景中表现出色，但在对数据安全、隐私和可持续服务有严格要求的场景中，需要进行谨慎评估。 通过本文的介绍，希望你能够对云原生的概念有了一定的理解，并认识到其在现代应用开发和部署中的重要性和潜力。 如果你对云原生技术有更多疑问或感兴趣的话题，欢迎进一步探讨。

Nocalhost - 让云原生时代的开发更高效

在转向 Kubernetes 部署后，我们团队在开发过程中遇到了挑战，寻求在云原生环境中无缝联调本地和开发环境的解决方案。 以往的开发流程有两套模式，这导致了本地编码效率低下：2分钟编码后，需要5分钟在环境中验证，严重影响了工作效率。 为了解决这一问题，我们寻求一种简单易学、基于配置、团队统一的解决方案。 经过研究，Telepresence和Bridge to Kubernetes这两款工具进入了我们的视野。 Telepresence通过在Pod中部署网络代理，让本地进程与Kubernetes环境无缝对接，而Bridge to Kubernetes则专注于在开发计算机和集群间双向通信，但其IDE插件支持有限。 最终，我们选择Nocalhost，一款基于IDE的云原生开发工具。 Nocalhost不仅具备Telepresence和Bridge to Kubernetes的功能，还提供了更全面的开发环境管理，如与VSCode、IntelliJ IDEA深度集成，一键部署和远程调试。 它通过单个CLI和IDE插件，利用KubeConfig与集群通信，实时同步代码并在编码时自动同步到K8s容器，显著提升开发效率。 与其他工具相比，Nocalhost在特性、支持IDE插件和用户体验上表现出色，特别是在大型团队和复杂环境中构建云原生应用方面。 它在Kubernetes集群中开发的应用场景广泛，且无需团队成员成为Kubernetes专家，简化了协作流程。 安装Nocalhost的过程简单，无论使用JetBrains系列还是VSCode，都能便捷集成。 只需要在项目根目录创建文件夹并配置，定义本地与远程环境的同步规则。 对于Python和Golang项目，Nocalhost提供了热加载功能，实时更新代码并自动重新执行命令。 总之，Nocalhost以其全面的功能、易用性和高度集成的优势，成为我们团队在云原生时代提升开发效率的理想选择。 通过Nocalhost，开发和联调变得更加高效，极大降低了本地环境搭建和配置的时间，优化了团队协作流程。

云原生体系下Serverless弹性探索与实践

简介：SAE通过对弹性组件和应用全生命周期的不断优化以达到秒级弹性，并在弹性能力，场景丰富度，稳定性上具备核心竞争力，是传统应用0改造上Serverless的最佳选择。

Serverless时代的来临

Serverless顾名思义，是一种“无服务器”架构，因为屏蔽了服务器的各种运维复杂度，让开发人员可以将更多精力用于业务逻辑设计与实现。 在Serverless架构下，开发者只需要关注于上层应用逻辑的开发，而诸如资源申请，环境搭建，负载均衡，扩缩容等等服务器相关的复杂操作都由平台来进行维护。 在云原生架构白皮书中，对Serverless的特性有以下概括：

全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作；

通用性，能够支撑云上所有重要类型的应用；

自动的弹性伸缩，让用户无需为资源使用提前进行容量规划；

按量计费，让企业使用成本得有效降低，无需为闲置资源付费。

回顾整个Serverless的发展历程，我们可以看到从2012年首次提出Serverless概念为起点，再到AWS推出Lambda云产品的这段时间内，人们对Serverless的关注度出现了爆发式的增长，对无服务器的期待和畅想逐渐引爆整个行业，但Serverless的推广和生产落地的过程却不容乐观，Serverless理念与实操生产的过程中存在Gap，挑战着人们固有的使用体验和习惯。

阿里云坚信Serverless将作为云原生之后确定性的发展方向，相继推出了FC,SAE等多款云产品来覆盖不同领域，不同类型的应用负载来使用Serverless技术，并且不断在推进整个Serverless理念的普及与发展。

就当前Serverless整个市场格局而言，阿里云已经做到了Serverless产品能力中国第一，全球领先，在去年Forrester评测魔力象限中可以明显的看到阿里云在Serverless领域已经与AWS不相上下，于此同时，阿里云Serverless用户占比中国第一，在2020年中国云原生用户调研报告中整个阿里云Serverless用户占比已经达到了66%，而在Serverless技术采用情况的调研中表明，已经有越来越多的开发者和企业用户将Serverless技术应用于核心业务或者将要应用于核心业务之中。

Serverless弹性探索

弹性能力作为云的核心能力之一，所关注的问题是容量规划与实际集群负载间的矛盾，通过两幅图的对比可以看到，如果采用预先规划的方式进行资源安排，会由于资源准备量和资源需求量的不匹配导致资源浪费或者资源不足的情况，进而导致成本上的过多开销甚至业务受损，而我们期望极致弹性能力，是准备的资源和实际需求的资源几乎匹配，这样使得应用整体的资源利用率较高，成本也随业务的增减和相应的增减，同时不会出现因容量问题影响应用可用性的情况，这就是弹性的价值。

弹性其实现上分为可伸缩性和故障容忍性,可伸缩性意味着底层资源可以参照指标的变化有一定的自适应能力，而故障容忍性则是通过弹性自愈确保服务中的应用或实例处于健康的状态。 上述能力带来的价值收益在于降成本的同时提升应用可用性，一方面，资源使用量贴合应用实际消耗量，另一方面，提升峰值的应用可用性，进而灵活适应市场的不断发展与变化。

下面将对当前较为普遍的三种弹性伸缩模式进行阐述和分析。

首先是IaaS弹性伸缩，其代表产品是各云厂商云服务器弹性伸缩，如阿里云ess,可以通过配置云监控的告警规则来触发相应的ECS增减操作，同时支持动态增减Slb后端服务器和Rds白名单来保证可用性，通过健康检查功能实现弹性自愈能力。 ESS定义了伸缩组的概念，即弹性伸缩的基本单位，为相同应用场景的ECS实例的集合及关联Slb,Rds,同时支持多种伸缩规则，如简单规则，进步规则，目标追踪规则，预测规则等，用户的使用流程为创建伸缩组和伸缩配置，创建伸缩规则，监控查看弹性执行情况。

Kubernetes弹性伸缩，这里主要关注于水平弹性hpa，其代表产品为K8s以及其所对应的托管云产品，如阿里云容器服务，K8s做为面向应用运维的基础设施和PlatformforPlatform,提供的内置能力主要是围绕着容器级别的管理和编排来展开的,而弹性能力聚焦于对底层Pod的动态水平伸缩，K8shpa通过轮询Pod的监控数据并将它与目标期望值比较进行，通过算法实时计算来产生期望的副本数，进而对Workload的副本数进行增减操作，用户在实际使用上需要创建并配置对应的指标源和弹性规则以及对应的Workload，可以通过事件来查看弹性的执行情况。

最后介绍一下应用画像弹性伸缩，其主要用于互联网公司内部，如阿里ASI容量平台。 容量平台提供容量预测服务和容量变更决策服务，指导底层容量变更组件如AHPA/VPA实现容量弹性伸缩，并根据弹性结果修正容量画像。 以画像驱动为主+指标驱动为辅实现弹性伸缩能力，通过提前伸缩+实时修正来降低弹性伸缩风险。 整个弹性伸缩会借助odps和机器学习能力对实例监控等数据进行处理并产生应用画像，如基准画像，弹性画像，大促画像等，并借助容量平台来完成画像注入，变更管控和故障熔断等操作。 用户使用流程为应用接入，基于历史数据/经验生成对应的容量画像，实时监控指标修正画像，并监控查看弹性执行情况。

从对比可以看出各产品弹性伸缩功能模式上从抽象来讲基本相同，均由触发源，弹性决策和触发动作组成，触发源一般依赖外部监控系统，对节点指标，应用指标进行采集处理，弹性决策一般基于周期性轮询并算法决策，有部分基于历史数据分析预测以及用户定义的定时策略，而触发动作为对实例进行水平扩缩，并提供变更记录与对外通知。 各个产品在此基础上做场景丰富度，效率，稳定性的竞争力，并通过可观测能力提升弹性系统的透明度，便于问题排查和指导弹性优化，同时提升用户使用体验与粘性。

各产品弹性伸缩模型也存在这一定的差异，对于IaaS弹性伸缩，其作为老牌弹性伸缩能力，沉淀时间长，功能强大且丰富，云厂商间能力趋于同质化。 弹性效率相较容器受限，且强绑定各自底层Iaas资源。 Kubernetes作为开源产品，通过社区力量不断优化迭代弹性能力和最佳实践，更符合绝大部分开发运维人员诉求。 对弹性行为和api进行高度抽象，但其可扩展性不强，无法支持自定义需求。 而应用画像弹性伸缩具有集团内部特色，根据集团应用现状和弹性诉求进行设计，且更聚焦于资源池预算成本优化，缩容风险，复杂度等痛点。 不易拷贝扩展，特别对于外部中小客户不适用。

从终态目标上，可以看出公有云与互联网企业方向的不同：

互联网企业往往由于其内部应用具有显著流量特征，应用启动依赖多，速度慢，且对整体资源池容量水位，库存财务管理，离在线混部有组织上的诸多诉求，因而更多的是以容量画像提前弹性扩容为主，基于Metrics计算的容量数据作为实时修正，其目标是容量画像足够精准以至于资源利用率达到预期目标。

公有云厂商服务于外部客户，提供更为通用，普适的能力，并通过可拓展性满足不同用户的差异化需求。 尤其在Serverless场景，更强调应用应对突发流量的能力，其目标在于无需容量规划，通过指标监控配合极致弹性能力实现应用资源的近乎按需使用且整个过程服务可用。

Serverless弹性落地

Serverless作为云计算的最佳实践、云原生发展的方向和未来演进趋势，其核心价值在于快速交付、智能弹性、更低成本。

在时代背景下，SAE应运而生，SAE是一款面向应用的ServerlessPaaS平台，支持SpringCloud、Dubbo等主流开发框架，用户可以零代码改造直接将应用部署到SAE，并且按需使用，按量计费，可以充分发挥Serverless的优势为客户节省闲置资源成本，同时体验上采用全托管，免运维的方式，用户只需聚焦于核心业务开发，而应用生命周期管理，微服务管理，日志，监控等功能交由SAE完成。

弹性的竞争力主要在于场景丰富度，效率，稳定性的竞争力，先讲一下SAE在弹性效率上的优化。

通过对SAE应用的整个生命周期进行数据统计和可视化分析，其包含调度，initcontainer创建，拉取用户镜像，创建用户容器，启动用户容器&应用这几个阶段，示意图中对其耗时的占比进行了简化。 我们可以看到整个应用生命周期耗时集中于调度，拉取用户镜像，应用冷启动这几个阶段。 针对于调度阶段，其耗时主要在于SAE当前会执行打通用户VPC操作，由于该步骤强耦合于调度，本身耗时较长，且存在创建长尾超时，失败重试等情况，导致调度链路整体耗时较长。

由此产生的疑问是可否优化调度速度？可否跳过调度阶段?而对于拉取用户镜像，其包含拉取镜像与解压镜像的时长，特别是在大容量镜像部署的情况下尤为突出。 优化的思路在于拉取镜像是否可以优化使用缓存，解压镜像是否可以优化。 而对于应用冷启动，SAE存在大量单体和微服务的JAVA应用，JAVA类型应用往往启动依赖多，加载配置慢，初始化过程长，导致冷启动速往往达到分钟级。 优化的方向在于可否避免冷启动流程并使用户尽量无感，应用无改造。

首先SAE采用了原地升级能力，SAE起初使用了K8s原生的Deployment滚动升级策略进行发布流程，会先创建新版本Pod，再销毁旧版本Pod进行升级，而所谓原地升级，即只更新Pod中某一个或多个容器版本、而不影响整个Pod对象、其余容器的升级。 其原理是通过K8spatch能力，实现原地升级Container，通过K8sreadinessGates能力，实现升级过程中流量无损。

原地升级给SAE带来了诸多价值，其中最重要的是避免重调度，避免Sidecar容器（ARMS,SLS,AHAS）重建,使得整个部署耗时从消耗整个Pod生命周期到只需要拉取和创建业务容器，于此同时因为无需调度，可以预先在Node上缓存新镜像，提高弹性效率。 SAE采用阿里开源Openkruise项目提供的Cloneset作为新的应用负载，借助其提供的原地升级能力，使得整个弹性效率提升42%。

同时SAE采用了镜像预热能力，其包含两种预热形式：调度前预热，SAE会对通用的基础镜像进行全节点缓存，以避免其频繁的从远端进行拉取。 与此同时对于分批的场景支持调度中预热，借助Cloneset原地升级能力，在升级的过程中可以感知到实例的节点分布情况，这样就可以在第一批部署新版本镜像的同时，对后面批次的实例所在节点进行镜像预拉取，进而实现调度与拉取用户镜像并行。 通过这项技术，SAE弹性效率提升了30%。

刚才讲述的优化点在于拉取镜像部分，而对于解压镜像，传统容器运行需要将全量镜像数据下载后再解包，然而容器启动可能仅使用其中部分的内容，导致容器启动耗时长。 SAE通过镜像加速技术，将原有标准镜像格式自动转化为支持随机读取的加速镜像，可以实现镜像数据免全量下载和在线解压，大幅提升应用分发效率，同时利用Acree提供的P2P分发能力也可以有效减少镜像分发的时间。

对于Java应用冷启动较慢的痛点，SAE联合Dragonwell11提供了增强的AppCDS启动加速策略，AppCDS即ApplicationClassDataSharing，通过这项技术可以获取应用启动时的Classlist并Dump其中的共享的类文件，当应用再次启动时可以使用共享文件来启动应用，进而有效减少冷启动耗时。 映射到SAE的部署场景，应用启动后会生成对应的缓存文件在共享的nas中，而在进行下一次发布的过程中就可以使用缓存文件进行启动。 整体冷启动效率提升45%。

除了对整个应用生命周期的效率进行优化外，SAE也对弹性伸缩进行了优化，整个弹性伸缩流程包括弹性指标获取，指标决策以及执行弹性扩缩操作三部分。 对于弹性指标获取，基础监控指标数据已经达到了秒级获取，而对于七层的应用监控指标，SAE正在规划采用流量透明拦截的方案保证指标获取的实时性。 而弹性决策阶段，弹性组件启用了多队列并发进行Reconcile，并实时监控队列堆积，延时情况。

SAE弹性伸缩包括强大的指标矩阵，丰富的策略配置，完善的通知告警机制及全方位可观测能力,支持多种数据源：原生的MetricsServer，MetricsAdapter，Prometheus，云产品SLS,CMS,SLB以及外部的网关路由等，支持多种指标类型：CPU、MEM、QPS、RT、TCP连接数，出入字节数，磁盘使用率，Java线程数，GC数还有自定义指标。 对指标的抓取和预处理后，可以自定义配置弹性策略来适配应用的具体场景：快扩快缩，快扩慢缩，只扩不缩，只缩不扩，DRYRUN，自适应扩缩等。

同时可以进行更为精细化的弹性参数配置,如实例上下限，指标区间，步长比例范围，冷却、预热时间，指标采集周期和聚和逻辑，CORN表达式，后续也会支持事件驱动的能力。 弹性触发后会进行对应的扩缩容操作，并通过切流保证流量无损，并且可以借助完善的通知告警能力（钉钉，webhook,电话，邮件，短信）来实时触达告知用户。 弹性伸缩提供了全方位的可观测能力，对弹性的决策时间，决策上下文进行清晰化展现，并且做到实例状态可回溯，实例SLA可监控。

SAE弹性能力在场景丰富度上也有着相应的竞争力，这里重点介绍一下SAE当前支持的四种场景：

定时弹性：在已知应用流量负载周期的情况下进行配置，应用实例数可以按照时间，星期，日期周期进行规律化扩缩，如在早8点到晚8点的时间段保持10个实例数应对白天流量，而在其余时间由于流量较低则维持在2个实例数甚至缩0。 适用于资源使用率有周期性规律的应用场景，多用于证券、医疗、政府和教育等行业。

指标弹性：可以配置期望的监控指标规则，SAE会时应用的指标稳定在所配置的指标规则内，并且默认采用快扩慢缩的模式来保证稳定性。 如将应用的cpu指标目标值设置为60%，QPS设置为1000，实例数范围为2-50。 这种适用于突发流量和典型周期性流量的应用场景，多用于互联网、游戏和社交平台等行业。

混合弹性：将定时弹性与指标弹性相结合，可以配置不同时间，星期，日期下的指标规则，进而更加灵活的应对复杂场景的需求。 如早8点到晚8点的时间段CPU指标目标值设置为60%，实例数范围为10-50，而其余时间则将实例数范围降为2-5，适用于兼备资源使用率有周期性规律和有突发流量、典型周期性流量的应用场景，多用于互联网、教育和餐饮等行业。

自适应弹性：SAE针对流量突增场景进行了优化，借助流量激增窗口，计算当前指标在这个时刻上是否出现了流量激增问题，并会根据流量激增的强烈程度在计算扩容所需的实例时会增加一部分的冗余，并且在激增模式下，不允许缩容。

稳定性是SAE弹性能力建设的过程中非常重要的一环，保证用户应用在弹性过程中按照预期行为进行扩缩，并保证整个过程的可用性是关注的重点。 SAE弹性伸缩整体遵循快扩慢缩的原则，通过多级平滑防抖保证执行稳定性，同时对于指标激增场景，借助自适应能力提前扩容。 SAE当前支持四级弹性平滑配置保证稳定性：

一级平滑：对指标获取周期，单次指标获取的时间窗口，指标计算聚和逻辑进行配置

二级平滑：对指标数值容忍度，区间弹性进行配置

三级平滑：对单位时间扩缩步长，百分比，上下限进行配置

四级平滑：对扩缩冷却窗口，实例预热时间进行配置

Serverless弹性最佳实践

SAE弹性伸缩可以有效解决瞬时流量波峰到来时应用自动扩容，波峰结束后自动缩容。 高可靠性、免运维、低成本的保障应用平稳运行，在使用的过程中建议遵循以下最佳实践进行弹性配置。

配置健康检查和生命周期管理

建议对应用健康检查进行配置，以保证弹性扩缩过程中的应用整体可用性，确保您的应用仅在启动、运行并且准备好接受流量时才接收流量同时建议配置生命周期管理Prestop，以确保缩容时按照预期优雅下线您的应用。

采用指数重试机制

为避免因弹性不及时，应用启动不及时或者应用没有优雅上下线导致的服务调用异常，建议调用方采用指数重试机制进行服务调用。

应用启动速度优化

为提升弹性效率，建议您优化应用的创建速度，可以从以下方面考虑优化：

软件包优化：优化应用启动时间，减少因类加载、缓存等外部依赖导致的应用启动过长

镜像优化：精简镜像大小，减少创建实例时镜像拉取耗时，可借助开源工具Dive，分析镜像层信息，有针对性的精简变更

Java应用启动优化：借助SAE联合Dragonwell11，为Java11用户提供了应用启动加速功能

弹性伸缩指标配置

弹性伸缩指标配置，SAE支持基础监控，应用监控多指标组合配置，您可以根据当前应用的属性（CPU敏感/内存敏感/io敏感）进行灵活选择。

可以通过对基础监控和应用监控对应指标历史数据（如过去6h,12h,1天,7天峰值，P99,P95数值）进行查看并预估指标目标值，可借助PTS等压测工具进行压测，了解应用可以应对的并发请求数量、需要的CPU和内存数量，以及高负载状态下的应用响应方式，以评估应用容量峰值大小。

指标目标值需要权衡可用性与成本进行策略选择，如

可用性优化策略配置指标值为40%

可用性成本平衡策略配置指标值为50%

成本优化策略配置指标值为70%

同时弹性配置应考虑梳理上下游，中间件，db等相关依赖，配置对应的弹性规则或者限流降级手段，确保扩容时全链路可以保证可用性。

在配置弹性规则后，通过不断监视和调整弹性规则以使容量更加接近应用实际负载。

内存指标配置

关于内存指标，考虑部分应用类型采用动态内存管理进行内存分配（如Javajvm内存管理，GlibcMalloc和Free操作），应用闲置内存并没有及时释放给操作系统，实例消耗的物理内存并不会及时减少且新增实例并不能减少平均内存消耗，进而无法触发缩容，针对于该类应用不建议采用内存指标。

Java应用运行时优化：释放物理内存，增强内存指标与业务关联性

借助Dragonwell运行时环境，通过增加JVM参数开启ElasticHeap能力，支持Java堆内存的动态弹性伸缩，节约Java进程实际使用的物理内存占用。

最小实例数配置

配置弹性伸缩最小实例数建议大于等于2，且配置多可用区VSwitch，防止因底层节点异常导致实例驱逐或可用区无可用实例时应用停止工作，保证应用整体高可用。

最大实例数配置

配置弹性伸缩最大实例数时，应考虑可用区IP数是否充足，防止无法新增实例。 可以在控制台VSwitch处查看当前应用可用IP，若可用IP较少考虑替换或新增VSwitch。

弹性到达最大值

可以通过应用概览查看当前开启弹性伸缩配置的应用，并及时发现当前实例数已经到达峰值的应用，进行重新评估其弹性伸缩最大值配置是否合理。若期望最大实例数超过产品限制（当前限制单应用50实例数，可提工单反馈提高上限）

可用区再均衡

弹性伸缩触发缩容后可能会导致可用区分配不均，可以在实例列表中查看实例所属可用区，若可用区不均衡可以通过重启应用操作实现再均衡。

自动恢复弹性配置

当进行应用部署等变更单操作时，SAE会停止当前应用的弹性伸缩配置避免两种操作冲突，若期望变更单完成后恢复弹性配置，可以在部署时勾选系统自动恢复。

弹性历史记录

SAE弹性生效行为当前可通过事件进行查看扩缩时间，扩缩动作，以及实时，历史决策记录和决策上下文可视化功能，以便衡量弹性伸缩策略的有效性，并在必要时进行调整。

弹性事件通知

结合钉钉，Webhook,短信电话等多种通知渠道，便于及时了解弹性触发状况。

最后分享一个采用SAE弹性伸缩功能的客户案例，在2020新冠疫情期间，某在线教育客户业务流量暴涨7-8倍，硬件成本和业务稳定性面临巨大风险。 如果此时采用传统的ECS架构，客户就需要在非常短的时间内做基础设施的架构升级，这对用户的成本及精力都是非常大的挑战。 但如果采用SAE，用户0改造成本即可享受Serverless带来的技术红利，结合SAE的多场景弹性策略配置，弹性自适应和实时可观测能力，保障了用户应用在高峰期的业务SLA，并且通过极致弹性效率，节省硬件成本达到35%。

综上，弹性发展方向上，尤其是在Serverless场景，更强调应对突发流量的能力，其目标在于无需容量规划，通过指标监控配合极致弹性能力实现应用资源的近乎按需使用且整个过程服务可用。 SAE通过对弹性组件和应用全生命周期的不断优化以达到秒级弹性，并在弹性能力，场景丰富度，稳定性上具备核心竞争力，是传统应用0改造上Serverless的最佳选择。

分布式文件存储服务器之Minio对象存储技术参考指南

Minio对象存储技术

MinIO是一种高性能对象存储解决方案，原生支持Kubernetes部署。 MinIO提供与AmazonWebServicesS3兼容的API并支持所有核心S3功能。 MinIO是在GNUAffero通用公共许可证v3.0下发布的。

也许提起对象存储技术，我们都经历过Fastdfs长时间的拉锯战，即使现在大部分都在使用云服务厂商提供的OSS对象存储服务，但是其所花费的经济成本也是递增的，而且数据都存储在别人的服务器上，从一定程度上来说，对于文件资源的把控粒度是极其不可控制，公网数据是何其的没有隐私可言。 虽然，对于开发层面上来说，只需要整合对应的SDK，对其使用已经是开箱即用。 但是，对于选择自研对象存储技术来说，Minio何尝不失为一大利器。 其搭建过程与整合方面，几乎已经没有什么瓶颈可言。 不论是从传统服务器的安装，还是基于Docker以及Kubernetes的部署，简直简单得不要不要的。

基本概述

,MinIO’ssoftware-definedsuiterunsseamlesslyinthepubliccloud,,MinIOcandeliverarangeofusecasesfromAI/ML,analytics,backup/restoreandmodernwebandmobileapps.

MinIO在最大数量的环境中支持最广泛的用例。 自云原生以来，MinIO的软件定义套件在公共云、私有云和边缘无缝运行——使其成为混合云的领导者。 凭借行业领先的性能和可扩展性，MinIO可以提供一系列用例，包括AI/ML、分析、备份/恢复以及现代Web和移动应用程序。

HybridCloud：混合云

Borncloudnative：云原生

MinIOispioneeringhighperformanceobjectstorage：高性能对象存储的先驱

Builtontheprinciplesofwebscale：建立在网络规模的原则上

The#.开源对象存储，并且最适合企业

ThedefactostandardforAmazonS3compatibility：AmazonS3兼容性的事实标准

Simplypowerful：简单强大[极简主义]

基本特点

MinIO的企业级特性代表了对象存储空间的标准。 从AWSS3API到S3Select以及我们对内联擦除编码和安全性的实施，我们的代码广受赞誉，并经常被一些技术和商业领域的大腕复制。

ErasureCoding：纠错码

MinIO使用以汇编代码编写的每个对象内联擦除编码来保护数据，以提供尽可能高的性能。 MinIO使用Reed-Solomon代码将对象条带化为具有用户可配置冗余级别的数据和奇偶校验块。 MinIO的ErasureCoding在对象级别执行修复，可以独立修复多个对象。

在N/2的最大奇偶校验下，MinIO的实现可以确保在部署中仅使用((N/2)+1)个操作驱动器进行不间断的读写操作。 例如，在12个驱动器的设置中，MinIO将对象分片到6个数据和6个奇偶校验驱动器，并且可以可靠地写入新对象或重建现有对象，而部署中仅剩下7个驱动器。

BitrotProtection：Bitrot保护

静默数据损坏或bitrot是磁盘驱动器面临的严重问题，导致数据在用户不知情的情况下损坏。 原因是多方面的（驱动器老化、电流峰值、磁盘固件中的错误、幻像写入、读取/写入方向错误、驱动程序错误、意外覆盖），但结果是一样的-数据受损。

MinIO对HighwayHash算法的优化实现确保它永远不会读取损坏的数据-它即时捕获和修复损坏的对象。 通过在READ上计算散列并在从应用程序、网络到内存/驱动器的WRITE上对其进行验证来确保端到端的完整性。 该实现专为速度而设计，可以在IntelCPU的单核上实现超过10GB/秒的散列速度。

Encryption：加密处理

在飞行中加密数据是一回事；保护静态数据是另一回事。 MinIO支持多种复杂的服务器端加密方案来保护数据——无论数据在哪里。 MinIO的方法以可忽略的性能开销确保机密性、完整性和真实性。 使用AES-256-GCM、ChaCha20-Poly1305和AES-CBC支持服务器端和客户端加密。

加密对象使用AEAD服务器端加密进行防篡改。 此外，MinIO与所有常用的密钥管理解决方案（例如HashiCorpVault）兼容并经过测试。 MinIO使用密钥管理系统(KMS)来支持SSE-S3。

如果客户端请求SSE-S3或启用自动加密，则MinIO服务器使用唯一的对象密钥加密每个对象，该对象密钥受KMS管理的主密钥保护。 鉴于极低的开销，可以为每个应用程序和实例打开自动加密。

IdentityManagement：身份管理

MinIO支持身份管理中最先进的标准，与OpenID连接兼容提供商以及关键的外部IDP供应商集成。 这意味着访问是集中的，密码是临时的和轮换的，而不是存储在配置文件和数据库中。 此外，访问策略是细粒度和高度可配置的，这意味着支持多租户和多实例部署变得简单。

ContinuousReplication：连续复制

传统复制方法的挑战在于，它们无法有效扩展超过数百TB。 话虽如此，每个人都需要一个复制策略来支持灾难恢复，并且该策略需要跨越地域、数据中心和云。

MinIO的持续复制专为大规模、跨数据中心部署而设计。 通过利用Lambda计算通知和对象元数据，它可以高效快速地计算增量。 Lambda通知确保更改立即传播，而不是传统的批处理模式。

连续复制意味着如果发生故障，即使面对高度动态的数据集，数据丢失也将保持在最低限度。 最后，与MinIO所做的一样，持续复制是多供应商的，这意味着您的备份位置可以是从NAS到公共云的任何位置。

GlobalFederation：全球联合会

现代企业到处都有数据。 MinIO允许将这些不同的实例组合起来形成一个统一的全局命名空间。 具体来说，可以将任意数量的MinIO服务器组合成一个分布式模式集，多个分布式模式集可以组合成一个MinIO服务器联合。 每个MinIOServerFederation都提供统一的管理和命名空间。

MinIO联合服务器支持无限数量的分布式模式集。 这种方法的影响是对象存储可以为大型、地理分布的企业大规模扩展，同时保留从单个控制台容纳各种应用程序（Splunk、Teradata、Spark、Hive、Presto、TensorFlow、H20）的能力。

Multi-CloudGateway：多云网关

所有企业都在采用多云战略。 这也包括私有云。 因此，您的裸机虚拟化容器和公共云服务（包括Google、Microsoft和阿里巴巴等非S3提供商）必须看起来相同。 虽然现代应用程序具有高度可移植性，但支持这些应用程序的数据却不是。

让这些数据无论位于何处都可用，是MinIO解决的主要挑战。 MinIO在裸机、网络附加存储和每个公共云上运行。 更重要的是，MinIO通过AmazonS3API确保您从应用程序和管理的角度来看这些数据的视图看起来完全相同。

MinIO可以走得更远，使您现有的存储基础设施与AmazonS3兼容。 影响是深远的。 现在，组织可以真正统一他们的数据基础设施——从文件到块，所有这些都显示为可通过AmazonS3API访问的对象，而无需迁移。

WORM：WORM对象锁定

启用WORM后，MinIO会禁用所有可能改变对象数据和元数据的API。 这意味着一旦写入的数据就可以防篡改。 这对于许多不同的监管要求具有实际应用。

基本架构

MinIO被设计为云原生，可以作为由外部编排服务（如Kubernetes）管理的轻量级容器运行。 整个服务器是一个约40MB的静态二进制文件，并且在使用CPU和内存资源方面非常高效-即使在高负载下也是如此。 结果是您可以在共享硬件上共同托管大量租户。

MinIO在带有本地连接驱动器(JBOD/JBOF)的商用服务器上运行。 集群中的所有服务器的能力相同（完全对称架构）。 没有名称节点或元数据服务器。

MinIO将数据和元数据作为对象一起写入，无需元数据数据库。 此外，MinIO将所有功能（擦除代码、bitrot检查、加密）作为内联、严格一致的操作执行。 结果是MinIO非常有弹性。

每个MinIO集群是一组分布式MinIO服务器，每个节点一个进程。 MinIO作为单个进程在用户空间运行，并使用轻量级协程来实现高并发。 驱动器被分组到擦除集（默认情况下每组16个驱动器），并且使用确定性散列算法将对象放置在这些集上。

MinIO专为大规模、多数据中心的云存储服务而设计。 每个租户运行自己的MinIO集群，与其他租户完全隔离，使他们能够保护他们免受升级、更新和安全事件的任何中断。 每个租户通过跨地域联合集群来独立扩展。

MinIO服务器功能

MinIO的企业级特性代表了对象存储空间的标准。 从AWSS3API到S3Select以及我们对内联擦除编码和安全性的实施，我们的代码广受赞誉，并经常被一些技术和商业领域的大腕复制。

MinIO对象保留

默认情况下，对唯一对象名称的每次新写入操作都会导致覆盖该对象。 您可以将MinIO配置为创建每个对象突变的版本，从而保留该对象的完整历史记录。 MinIO还支持一次写入多次读取(WORM)锁定版本化对象，以确保在指定的持续时间内或直到显式解除锁定为止的完全不变性。

版本控制和对象锁定功能仅适用于分布式MinIO部署：

BucketVersioning：存储桶版本控制

MinIO支持在单个存储桶中保存对象的多个“版本”。 通常会覆盖现有对象的写入操作会导致创建新的版本化对象。 MinIO版本控制可防止意外覆盖和删除，同时支持“撤消”写入操作。 存储桶版本控制是配置对象锁定和保留规则的先决条件。

对于版本化存储桶，任何改变对象的写入操作都会导致该对象的新版本具有唯一的版本ID。 MinIO标记客户端默认检索的对象的“最新”版本。 然后，客户端可以明确选择列出、检索或删除特定对象版本。

其中：

具有单一版本的对象：MinIO为每个对象添加一个唯一的版本ID作为写入操作的一部分。

2.具有多个版本的对象：MinIO保留对象的所有版本，并将最新版本标记为“最新”。

3.检索最新的对象版本

4.检索特定对象版本

WORM：对象锁定

MinIO对象锁定（“对象保留”）强制执行一次写入多次读取(WORM)不变性以保护版本化对象不被删除。 MinIO支持基于持续时间的对象保留和无限期合法保留保留。

MinIO对象锁定提供关键数据保留合规性，并符合CohassetAssociates的SEC17a-4(f)、FINRA4511(C)和CFTC1.31(c)-(d)要求。

其中：

不带锁的桶：MinIO版本控制保留了对象突变的完整历史。 但是，应用程序可以明确删除特定的对象版本。

带锁的桶：对存储桶中的对象应用默认的30天WORM锁定可确保所有对象版本的最短保留期和保护期。

3.锁定桶中的删除操作：删除操作遵循版本化存储桶中的正常行为，其中MinIODeleteMarker为对象创建一个。 但是，对象的非删除标记版本仍受保留规则约束，并且不会受到任何特定删除或覆盖尝试的影响。

4.锁定存储桶中的版本化删除操作：MinIO会阻止任何删除在WORM锁定下持有的特定对象版本的尝试。 客户端可以删除版本的最早可能时间是锁定到期时。

Minio部署和管理

MinIO是一个软件定义的高性能分布式对象存储服务器。 您可以在消费级或企业级硬件以及各种操作系统和架构上运行MinIO。

MinIO支持两种部署模式：独立和分布式：

独立部署：具有单个存储卷或文件夹的单个MinIO服务器。 独立部署最适合使用MinIO进行对象存储的应用程序的评估和初始开发，或为单个存储卷提供S3访问层。 独立部署不提供对全套MinIO高级S3特性和功能的访问。

分布式部署：一台或多台MinIO服务器，所有服务器上至少有四个总存储卷。 分布式部署最适合生产环境和工作负载，并支持MinIO的所有核心和高级S3特性和功能。 对于生产环境，MinIO建议使用4个节点和4个驱动器的基线拓扑。

---

---

相关标签： 集群的云原生最佳实践、 上的实现指南、 Kubernetes、 kubernetes怎么读、 在、 和、 Azure、 GCP、 AWS、

上一篇：sethcexeWindows辅助工具，揭开其鲜为人知的

下一篇：Kubernetes集群的安全性保护免受网络威胁恶