Kubernetes 1.23发布:下一个前沿

我们很高兴地宣布发布 Kubernetes 1.23,因为这是 2021 年K8s 的最后一个版本!下一个前沿的主题代表了 1.23 中新的功能和渐进的增强、Kubernetes 的星际迷航参考历史以及发布团队中社区成员的成长。Kubernetes 有星际迷航...
继续阅读 »

我们很高兴地宣布发布 Kubernetes 1.23,因为这是 2021 年K8s 的最后一个版本!

3dd207133850fee5c6ea5084898ff205.jpeg

下一个前沿的主题代表了 1.23 中新的功能和渐进的增强、Kubernetes 的星际迷航参考历史以及发布团队中社区成员的成长。


Kubernetes 有星际迷航参考的历史。谷歌内 Kubernetes 的原始代号是 Project 7,参考了《Seven of Nine from Star Trek Voyager》。当然,Borg 是 Kubernetes 前身的名称。“下一个前沿”的主题延续了《星际迷航》的参考资料。“The Next Frontier”是两个星际迷航游戏的融合,《Star Trek V: The Final Frontier and Star Trek the Next Generation》。


“下一个前沿”代表了 SIG 发布章程中的一条线,“确保有一个一致的社区成员小组来支持跨时间的发布过程。” ,对于每个发布团队,我们都会与新的发布团队成员一起发展社区,对于许多人来说,这是他们在开源领域的第一个贡献。




此版本包含 47 项增强功能:11 项增强功能已升级到稳定版,17 项增强功能正在进入测试版,19 项增强功能正在进入 Alpha 版。此外,1 个功能已被弃用。


Kubernetes 1.23主要变化:

  • API 服务器请求的优先级和公平性


Kubernetes 1.23已升级到稳定版的功能:

  • IPv4/IPv6 双栈支持

  • 跳过卷所有权更改

  • 完成控制器后的TTL

  • 在 CSI 驱动程序对象中配置 FSGroup 策略

  • 通用临时内联卷

  • 通过静态分析防御记录Secret

  • 命名空间范围的入口类参数

  • 减少 Kubernetes 构建维护

  • 从 HPA API 到 GA


Kubernetes 1.23有三项值得注意的弃用功能

  • HPA v2beta2 API

  • FlexVolume

  • 针对klog的标志


Kubernetes 1.23两项功能也升级为Beta版

  • PodSecurity—取代了PodSecurityPolicy准入控制器。

  • 结构化日志—来自kubelet和kube-scheduler的大多数日志消息已经过转换,建议用户尝试JSON输出。


Kubernetes 1.23处于Alpha版的新功能

  • Kubernetes 1.23还包括几项现处于alpha版的新功能。这包括:

  • CRD的表达式语言验证—如果启用CustomResourceValidationExpressions,自定义资源将由使用通用表达式语言(CEL)的规则进行验证。

  • 服务器端字段验证—如果启用ServerSideFieldValidation,检测到请求中未知或重复的字段时,用户将收到来自服务器的警告。

  • OpenAPI v3—如果启用OpenAPIV,用户将能够为所有Kubernetes类型请求OpenAPI v3规范。



新版本功能丰富,增强之处超过45项,虽然这些新功能可能不会全部跻身Top 10,但一些功能对使用Kubernetes的人而言可能大有帮助。然而,真正的焦点在于1.23中已升级到正式版(即稳定版)的四个核心功能IPv4/IPv6双栈支持CronJobs(计划任务)临时卷HPA API



IPv4/IPv6双栈支持


有了IPv6/IPv6双栈支持,Kubernetes现在可以在集群中直接支持双栈模式。这意味着你可以将IPv4地址和IPv6地址分配给任何特定的pod或服务。这是使用.spec.ipFamilyPolicy字段来配置的,该字段可设置为以下值之一:


  • SingleStack

  • PreferDualStack

  • RequireDualStack


要使用双栈支持,你需要将.spec.ipFamilyPolicy设置为PreferDualStack或RequireDualStack。该功能在Kubernetes中默认启用,还包括通过IPv4和IPv6地址进行的pod集群外出站路由。



有了CronJobs功能,就可以在Kubernetes集群中运行周期性任务。Kubernetes CronJobs与Linux cron系统非常相似。CronJobs在Kubernetes 1.4问世后就已存在了,自从它在版本1.5中获得CRI支持以来就在生产环境被广泛接受。


CronJob在YAML文件中定义如下:

kind: CronJob


每10分钟输出一次“Hello Newstack”的示例CronJob清单文件可能如下所示:

apiVersion: batch/v1
kind: CronJob
metadata:
name: hello
spec:
schedule: “*/10 * * * *”
jobTemplate:
spec:
template:
spec:
containers:
– name: hello
image: busybox
imagePullPolicy: IfNotPresent
command:
– /bin/sh
– -c
– date; echo Hello Newstack
restartPolicy: OnFailure




对于那些不知道cron语法的人来说,它就像这样:MINUTE(分钟) HOUR(小时) DAY OF MONTH(月日) MONTH(月) DAY OF WEEK(星期几)如果你不确定如何创建 cronjob,强烈建议从Crontab Guru(https://crontab.guru/)开始入手,该编辑器让你可以将值插入到cronjob,看看它们到底生成了什么。


临时卷


自Kubernetes 1.19以来,临时卷就已存在,让你可以为特定的pod创建卷,pod终止后删除临时卷。换句话说,这些是临时卷。


Kubernetes支持四种类型的临时卷,它们是:


  • emptyDir—Pod启动时可用的空卷,使用来自kubelet基本目录或内存中的存储空间。

  • configMap、downdownAPI、secret—将不同类别的Kubernetes数据注入到指定的Pod中。

  • CSI临时卷—类似其他类型的卷,但由特殊的CSI驱动程序提供。

  • 通用临时卷—由所有存储驱动程序提供(支持持久存储)


使用临时存储的示例清单文件可能如下所示:

kind: Pod
apiVersion: v1
metadata:
name: sample-storage-app
spec:
containers:
– name: storage-frontend
image: busybox
volumeMounts:
– mountPath: “/storage”
name: sample-storage-app-vol
command: [ “sleep”, “1000000” ]
volumes:
– name: sample-storage-app-vol
csi:
driver: inline.storage.kubernetes.io
volumeAttributes:





HPA API


Horizontal Pod Autoscaleer API对Kubernetes来说并不陌生。实际上,它在2016年就首次引入了。该功能负责自动扩展复制控制器、部署、副本集或状态集中的Pod数量。基于以下类型的指标来加以扩展:


  • 资源使用情况—当Pod超过内存或CPU使用情况的阈值时。

    这可以表示为原始值或百分比。

  • 自定义指标—这基于Kubernetes报告的指标(即每秒客户端请求率)。

  • 外部指标—这基于外部应用程序或服务提供的指标。


Autosaclers使用控制循环来运行,周期则由–horizontal-pod-autoscaler-sync-period标志来控制。默认值是15秒。在控制循环期间,控制器根据HorizontalPodAutoscaler定义中配置的指标来查询Pod的资源使用情况。




有关kubernetes1.23版本更新的更多细节,请查阅完整的发布说明:

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md
https://kubernetes.io/blog/2021/12/07/kubernetes-1-23-release-announcement/



收起阅读 »

谷歌 DevOps 2021 报告:总结SRE 的四个关键要点(附45页PDF下载)

SRE 和 DevOps 一起使用时可提供最佳价值。文化是避免精疲力竭的关键。您比以往任何时候都更需要云。这些是 Google Cloud 最新的Accelerate State of DevOps 报告的主要内容,该报告研究了公司如何使用 DevOps 实践...
继续阅读 »

SRE 和 DevOps 一起使用时可提供最佳价值。文化是避免精疲力竭的关键。您比以往任何时候都更需要云。
fba25f94842e5a6a88f4d5a775e80a24.jpg
这些是 Google Cloud 最新的Accelerate State of DevOps 报告的主要内容,该报告研究了公司如何使用 DevOps 实践。由 DevOps 研究和评估 (DORA) 编制的 2021 年报告部分基于对 32,000 名专业人士的调查,确定了 DevOps 和 SRE 团队今天可以用来实现卓越运营的最佳实践。

该报告全文长达45页。有空的话值得一读。但如果你不能,我们已经为 SRE 提取了最重要的要点——他们可以从 DORA 的发现中学到很多东西,即使报告的官方重点是 DevOps 而不是SRE 。


您不需要 SRE或DevOps;你需要 SRE和DevOps

1a43be0f5087ea32de4636402581db5f.jpg
最重要的发现可能是 DevOps 和 SRE 不是一个非此即彼的命题。尽管有些人将这些领域混为一谈,或者认为一个比另一个更重要,但 Google 表示现代组织需要 SRE 和 DevOps。

"SRE 和 DevOps 是高度互补的,我们的研究证明了它们的一致性,”报告补充说,“SRE 推动了 DevOps 的成功。”

诚然,Google 的报告强调 SRE 的重要性并不奇怪。谷歌是发明 SRE 并出版了一系列书籍来帮助普及这个概念的公司。谷歌鼓励企业接受 SRE 是有道理的。

另一方面,报告并不认为 SRE比 DevOps更重要。它说企业需要两种类型的角色。您可以将此解释为 Google 承认仅靠 SRE 并不能解决问题——这是一件大事。

安全推动可靠性


在某些方面,SRE 和 security 之间存在紧张关系。最大的可靠性并不总是转化为最大的安全性。

然而,有趣的是,2021 年 DevOps 状态报告得出的结论是,当组织将安全性融入其可靠性流程时,可靠性结果要好得多。谷歌报告说“达到或超过其可靠性目标的精英执行者在其软件开发过程中集成安全性的可能性是其两倍”。

这里的教训是,协调可靠性与安全性和 DevSecOps 变得比以往任何时候都更加重要。您不能尝试优先考虑其中一个。寻找通过通用流程实现这两者的方法会导致系统尽可能可靠和安全。


多云和混合云增强可靠性


SRE 可能不会将云战略视为其工作职责的核心部分。这是一项更常见于云架构师的任务。

但根据 DevOps 报告,简单地鼓励他们的组织利用更可靠的云架构可能是提高可靠性的一种方法。虽然增强的可靠性并不是越来越多的组织现在扩展到多云和混合云架构的唯一原因,但在谷歌调查的专业人士中,提高可用性是采用这些策略之一的第二个最常见的原因。

该报告还指出,拥有多云或混合云架构的组织达到或超过其性能目标的可能性是其 1.6 倍。

SRE 的要点是,尽管需要管理更多的云在某些方面会带来新的可靠性挑战,但数据清楚地表明,从长远来看,多云和混合云会带来更好的可靠性结果。是时候放弃你的单一云了。

文化应鼓励合理的风险


该报告对文化及其在塑造组织成功方面的作用进行了大量讨论。尽管该报告没有明确将文化与 SRE 联系起来,但一项令 SRE 感兴趣的发现是“高绩效组织更有可能拥有一种文化,鼓励员工承担有计划的和适度的风险,而不用担心负面后果。”

SRE 可以做很多事情来帮助他们的公司建立这种类型的文化。他们可以鼓励无过错的事后分析。它们还可以最大限度地提高可维护性,以确保在有人出错时快速恢复。

因此,考虑您作为 SRE 的角色的一种方法是设计方法来鼓励您的整个组织作为一个整体来承担适度的、经过计算的风险,而不必担心如果出现问题,世界就会结束。

结论


同样,我们鼓励您有空时查看完整的 DevOps 2021 状态报告。但与此同时,请考虑 SRE 如何与 DevOps 和安全团队集成,鼓励云创新并建立风险容忍文化,以此为公司带来更大的价值。

报告下载链接:谷歌DevOps2021报告

参考链接:

1、https://cloud.google.com/blog/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report

2、https://cloud.google.com/devops/state-of-devops/

3、https://rootly.com/blog/google-s-state-of-devops-2021-report-what-sres-need-to-know 收起阅读 »

如何为 Kubernetes 集群设计和实现全局负载均衡器

介绍在多集群(可能是混合云)部署中使用 Kubernetes 或 OpenShift 时,需要考虑的问题之一是如何将流量定向到跨这些集群部署的应用程序。为了解决这个问题,我们需要一个全局负载均衡器。上图描绘了一个名为“ app”的应用程序,部署到两个 Kube...
继续阅读 »

介绍

在多集群(可能是混合云)部署中使用 Kubernetes 或 OpenShift 时,需要考虑的问题之一是如何将流量定向到跨这些集群部署的应用程序。为了解决这个问题,我们需要一个全局负载均衡器。
cb7581539484fbe190a021e050d72b66.png
上图描绘了一个名为“ app”的应用程序,部署到两个 Kubernetes 集群,可通过Ingress 或网关 API 资源(为简单起见,以下称为Ingress)访问,这些资源又由两个本地负载均衡器 (LLB) 公开,可通过两个虚拟 IP(VIP)访问): VIP1 和VIP2。全局负载均衡器位于 LLB 之上,并将消费者引导至任一集群。消费者引用单个全局FQDN (在本例中为app.globaldomain.io)来访问应用程序。

实际上,Kubernetes 社区内还没有明确的方向来说明如何为 Kubernetes 集群设计和实现全局负载均衡器。只尝试了小的孤立的努力。

在本文中,我们将讨论正确构建全局负载均衡器解决方案需要什么,以及基于 Kubernetes 集群中运行的工作负载自动化配置需要什么。


在继续进行特定的架构选项之前,我们将回顾全局负载均衡器应该具有的共同特征。

全局负载均衡器要求


Kubernetes 集群的全局负载均衡器负责确定与在单个 Kubernetes 集群中运行的实例相关的服务连接应该路由到哪里。这些集群可以在地理上分布或驻留在同一都市区域内。

Kubernetes 为传入流量进入集群提供了两种主要方法:Ingresses(Ingress、Gateway API 和OpenShift Routes)和LoadBalancer Services。

我们的全球负载均衡器需要同时支持两者。值得注意的是,在 Ingresses(一个 L7 反向代理)的情况下,我们经常有一个本地负载均衡器暴露多个应用程序共享的 VIP。

此外,除了循环之外,全局负载均衡器还应提供复杂的负载均衡策略。特别是,经常请求的策略是能够根据某些指标(延迟、地理距离等)返回最接近尝试连接的消费者的端点。在地理分布的场景中,此策略允许消费者以最低延迟连接到端点。在城域场景中,这允许在同一数据中心内路由源自数据中心的连接。

另一种常用的策略是加权路由,它通过一次仅将所有权重分配给一个集群来帮助实现主动/被动配置。

最后,全局负载均衡器应该能够识别应用程序何时变得不可用,并且应该只将流量引导到健康的端点。这通常通过配置健康检查来完成。

总而言之,以下是我们在全局负载均衡器中寻找的要求:

  1. 能够通过 LoadBalancer 服务和 Ingress 进行负载平衡
  2. 复杂的负载均衡策略
  3. 支持健康检查和从负载均衡池中删除不健康端点的能力


介绍全局负载均衡器架构选项

根据我们的经验,有两种设计全局负载均衡器的架构方法:
  1. 基于 DNS。
  2. 基于任播(也称选播)。
让我们分别检查它们。

基于 DNS 的方法


8c113360ce05c08a41dabbc85aa7b970.png

在基于 DNS 的方法中,负载平衡决策由 DNS 服务器做出。

从上图中我们可以看出,服务消费者向 DNS 服务器查询app.globaldomain.io ,DNS 服务器以两个集群的地址之一进行响应。

基于 DNS 的负载平衡具有相对容易实施的优势,因为 DNS 服务器是任何网络基础设施的一部分。然而,简单性带来了一系列限制:

1、客户端会将 DNS 响应缓存一段时间(通常根据 TTL,但不能保证)。

如果缓存中的位置发生中断,客户端可能无法运行,直到该位置的问题得到解决或 DNS 缓存刷新。

2、当 DNS 服务器配置为返回多个 IP 值时,客户端将负责选择它将连接到的特定端点,从而导致潜在的不平衡流量模式。

即使 DNS 服务器随机化返回 IP 的顺序也是如此。

这是因为 DNS 规范中没有任何内容要求在响应遍历 DNS 服务器层次结构时必须保留 IP 的顺序,或者服务消费者必须遵守该顺序。

除了上述限制之外,典型的 DNS 服务器不支持复杂的负载平衡策略,也不支持后端健康检查。

但是,有几种高级 DNS 实现确实支持这些功能,包括:

  • 网络设备,例如F5 BigIP 和Citrix ADC,常见于本地数据中心
  • DNS 托管解决方案,例如Infoblox 和CloudFlare
  • 主要公有云提供商的DNS服务:AWS Route53、Azure Traffic Manager

请注意,在实施这些全局负载平衡器方法时,如果使用入口(入口v1、v2或OpenShift路由)将流量路由到应用程序,则入口中配置的主机名必须与消费者在查询DNS服务器时使用的全局FQDN相同。此主机名将不同于应用程序的默认地址,该地址通常是特定于群集的,必须显式设置。

概括
8f7b719198fb72c3fdad955e9e3544ca.png

任播的方法

基于任播的方法是指一种架构模式,其中许多服务器通告相同的 IP,路由器可以通过不同的网络路径将数据包路由到这些位置。


有两种方法可以实现这种架构:

  • 基于 IP/BGP 的任播服务:明确设计和利用 IP/BGP 技术来实现任播负载平衡功能。
  • 使用任播/CDN 云服务:利用现有的支持任播的网络(例如提供以任播为中心的负载平衡和 CDN 服务的特殊公共云任播服务)。
此类云服务的示例包括Google Cloud Network Load balancer、AWS Global Accelerator 以及来自其他提供商的类似全球负载平衡服务。BGP/任播功能在本地数据中心并不总是可用。鉴于 BGP 在 L3/4 级别运行,它不直接支持独立故障转移共享同一 VIP 的多个应用程序的能力。

基于 IP/BGP 的方法


我们首先来看一个基于 IP/BGP 的任播设计。这可以通过 IPv4 的BGP 和ECMP或通过对 IPv6 中任播的本机支持来实现。

由此产生的架构可以类似于以下描述:

93f8e79c973af9ad7c793bc5162706e1.png

该图显示了部署在两个集群内并通过LoadBalancer服务公开的应用程序。两种负载平衡器服务的VIP是相同的(图中VIP Global中的VIP为VIP)。通过BGP对路由器进行编程,为VIPG的两条路径(ECMP)分配相等的成本,从而实现主动选播负载均衡器解决方案。备用BGP指标(如不等成本和本地偏好)也可用于实施额外的负载平衡策略,包括主动备用。


特别是,可以通过让一个集群发布比另一个集群更好的路由度量来实现主备,这样,在正常情况下,所有到特定 VIP 的流量都路由到该集群,而不管与客户端的 IP 跳距如何。当灾难发生时,会选择不太理想的路线,因为它成为唯一可行的选择。

这种方法的优点是故障转移不依赖于客户端并由路由器管理,与基于 DNS 的解决方案相比,故障转移速度更快(毫秒级)。

为了获得最佳故障转移体验,路由器需要使用 3 元组或 5 元组散列以及一致散列(有时称为弹性散列)来执行流量感知多路径负载平衡。如果没有此功能,故障转移性能和可用性可能会受到影响,因为大量 TCP 会话可能会在网络故障事件时重置,从而导致会话从一个后端重新散列和重新路由到另一个后端。现代路由器通常支持这些功能;但是,有必要确保正确配置它们以实现一致的散列。

这种方法有以下限制:

  • BGP/任播功能在本地数据中心并不总是可用。
  • 鉴于 BGP 在 L3/4 级别运行,它不直接支持独立故障转移共享同一 VIP 的多个应用程序的能力。


Kubernetes 参考实现

实现上述方法的一种选择是在 BGP 模式下使用MetalLB 来实现 Kubernetes LoadBalancer 服务,并将集群节点连接到支持 BGP 的物理网络。拓扑类似于上图,其中部署到每个集群节点的 MetalLB 代理将与外部 BGP 网络对等,以通过多个集群的多个节点通告同一 VIP 的可达性:

149865fc759cc99bac9351f976d61b9d.png

请注意,不需要使用 BGP 路由进行集群内 pod-to-pod 网络的 CNI 插件来实现此解决方案。BGP 仅由 MetalLB 用于向外部网络通告 LoadBalancer VIP。MetalLB 遵循 Kubernetes 服务规范的 LoadBalancer API,因此可用于没有可用云提供商或云提供商不遵循LoadBalancer Service API 的场景。

为了让全局负载均衡器正常工作,需要配置多个集群,为实现相同应用程序的 Kubernetes 服务使用相同的 VIP。

还可以实施额外的自动化以确保跨集群的此配置同步,例如,发现需要全局化的 LoadBalancer 服务或强制它们具有相同的 LoadBalancer VIP。也可以通过中央自动化协调对 BGP 路由度量标准的支持,例如本地优先级,以便可以为一个集群提供优先于另一个集群的优先级。

请注意,自 4.8 起,OpenShift 目前不支持 MetalLB,但它是未来包含在产品中的路线图上的一个项目,包括对 BGP 模式的支持。

基于任播负载均衡云服务的方法


许多公共云提供商支持将全局负载平衡作为一种服务来实现任播方法,因为租户可以使用单个静态全局 IP 地址,并且可以将其用作多集群多区域服务的前端。

此类服务的示例包括Google Cloud Network Load Balancer、AWS Global Accelerator、 Fastly Anycast和CloudFlare Anycast。这些云服务通常与 CDN 和/或 API 网关功能相结合,但在大多数情况下,也可以用作纯粹的全局任播负载平衡服务,而不必使用其他功能。

这些服务通常使用一组边缘云位置来实现,所有这些位置都宣传全局静态 VIP。发往全球 VIP 的流量从请求者定向到最近的边缘云位置,然后在那里进行负载平衡,并在云提供商的网络内部路由到后端实例。

云提供商用于实施此类服务的确切技术对最终用户是隐藏的,但通常涉及基于 IP/BGP 的任播与弹性 ECMP的内部组合 。云提供商能够利用他们的私有网络额外提供高级负载平衡策略和流量控制,尽管这些功能在一个提供商和另一个提供商之间可能并不总是一致的。
86eee4bba8f41f39d0814db43a2c72b8.png

每个任播云服务提供的功能各不相同,包括是否允许客户为此类服务带来自己的 IP,或者全局 IP 是面向内部还是面向外部。

概括
8c657f5301bcd8baa25717de4f250718.png

自动化全局负载均衡器配置


到目前为止,我们已经研究了几种构建全局负载均衡器的方法。但是,让我们想象一个场景,其中我们选择了一种方法,我们需要对部署到多个集群的数百个应用程序进行全局负载平衡。拥有某种形式的自动化来帮助为这些应用程序创建全局负载平衡配置肯定会有所帮助。

可以使用传统的自动化工具来自动化网络配置,但在 Kubernetes 上下文中,主流方法是使用Operator。

全局负载均衡器Operator需要监控多个集群的配置,并根据在这些集群中找到的状态来配置全局负载均衡器。这个领域的一个复杂问题是,当今构建Operator的工具生态系统都专注于仅在单个集群上运行的构建Operator。因此,正在开发的大多数Operator都是集群绑定的。


部分出于这个原因,部分出于可用于实现全局负载均衡器Operator的多种方式,Kubernetes 社区中似乎没有针对此类Operator的官方实现。然而,正如我们在介绍中所说,我们知道有两个举措:k8gb 和global-loadbalancer-operator。


K8GB


K8gb 是一个基于 DNS 的全球负载均衡器运营商。k8gb 有趣的部分是 DNS 服务器是作为CoreDNS pod集群实现的,它是自托管的,并分布在它将服务的 Kubernetes 集群中。这提供了固有的灾难恢复能力以及独立于外部网络功能的能力。
9669b9c53eff6970eb624acf85b3b129.png

k8gb 的一个限制是它对高级负载平衡策略的支持有限。正在努力通过使用 CoreDNS 插件来减轻这些缺点。请参阅最近添加的geoip 负载平衡策略 ,以获取正在进行的一些工作的示例。


全局负载均衡器Operator


global-loadbalancer-operator 是一个设计用于在控制集群中运行并配置为监视多个受控集群的Operator,它将为其构建全局负载均衡器配置。

可以用来配置external-dnsOperator支持的任何DNS服务器 ,实现基本的基于DNS的全局负载均衡。

它旨在解决基于 DNS 和基于云任播的全局负载平衡。在公共云中运行时,还可以使用高级配置选项。

截至本文发布之日,AWS Route53、Azure 流量管理器和即将推出的 Google 全球 IP 作为提供者提供支持,这些提供商具有更高级的功能,例如不同的负载平衡策略和运行状况检查。

控制集群的使用和仅在 OpenShift 中支持部署是 global-loadbalancer-operator 的两个限制。

结论

在本文中,我们研究了在 Kubernetes 集群前构建全局负载均衡器的几种方法。我们看到有几种适用于不同场景的选项,但从自动化的角度来看,我们还处于早期阶段。可以说,应用程序团队自助服务全局负载均衡的能力是阻碍跨多个集群部署应用程序以实现主动/主动架构的障碍之一。

我们希望这篇文章能够重振社区的兴趣,并推动对 Kubernetes 中此类流量管理的更广泛接受的解决方案的研究。


参考链接:Global Load Balancer Approaches

收起阅读 »

使用 Helm 的 13 个最佳实践

Helm是将应用程序部署到Kubernetes集群不可或缺的工具。但只有遵循最佳实践,您才能真正获得Helm的好处。这里有13个最佳实践,可帮助您使用Helm创建、操作和升级应用程序。将你的Helm提升到一个新的水平Helm是Kubernetes的包管理器。由...
继续阅读 »

Helm是将应用程序部署到Kubernetes集群不可或缺的工具。但只有遵循最佳实践,您才能真正获得Helm的好处。这里有13个最佳实践,可帮助您使用Helm创建、操作和升级应用程序。


03801f55ad1cd55e6e18bfcc55148a26.png


将你的Helm提升到一个新的水平

Helm是Kubernetes的包管理器。由于其模板方法和可重用和生产就绪包(也称为Helm图表)的丰富生态系统,它减少了部署复杂应用程序的工作量。使用Helm,将打包的应用程序部署为一组版本化、预配置的Kubernetes资源。



假设您正在使用Kubernetes部署一个数据库——包括多个Deployment、containers、secrets,volumes和services。Helm允许您使用单个命令和一组值安装相同的数据库。其声明性和幂等性命令使Helm成为持续交付(CD)的理想工具。


Helm是一个CloudNativeComputingFoundation(CNCF)项目,创建于2015年,2020年4月毕业。随着Helm3的最新版本,它更加融入了Kubernetes生态系统。


本文介绍了创建Helm图表以管理在Kubernetes中运行的应用程序的13个最佳实践。


1、利用Helm生态系统

Helm使您可以获取丰富的社区专业知识——这也许是该工具的最大好处。它从世界各地的开发人员那里收集Charts图表,然后通过图表存储库共享。您可以检查ArtifactHub以获取可用的Helm图表存储库。


找到图表存储库后,您可以将其添加到本地设置中,如下所示:

$helmrepoaddbitnamihttps://charts.bitnami.com/bitnami

然后就可以搜索图表了,比如MySQL:

$helmsearchhubmysql
URLCHARTVERSIONAPPVERSIONDESCRIPTIONhttps://hub.helm.sh/charts/bitnami/mysql8.6.38.0.25CharttocreateaHighlyavailableMySQLcluster


2. 使用subcharts来管理你的依赖

由于部署到Kubernetes的应用程序由细粒度、相互依赖的部分组成,因此它们的Helm图表具有各种资源模板和依赖项。例如,假设您的后端依赖于一个数据库和一个消息队列。数据库和消息队列已经是独立的应用程序(例如PostgreSQL和RabbitMQ)。因此,建议为独立应用程序创建或使用单独的图表并将它们添加到父图表(parentcharts)。依赖的应用程序在此处被命名为子图(subchart)。


创建和配置子图表有三个基本要素:


1.图表结构

文件夹结构应按以下顺序排列:

backend-chart-Chart.yaml-charts-message-queue-Chart.yaml-templates-values.yaml-database-Chart.yaml-templates-values.yaml-values.yaml


2.chart.yaml

此外,父图表中的chart.yaml应列出所有依赖项和条件:

apiVersion:v2name:backend-chartdescription:AHelmchartforbackend...dependencies:-name:message-queuecondition:message-queue.enabled-name:databasecondition:database.enabled


3.values.yaml

最后,您可以使用以下values.yaml文件设置或覆盖父图表中子图表的值:

message-queue:enabled:trueimage:repository:acme/rabbitmqtag:latestdatabase:enabled:false


创建和使用子图在父应用程序和依赖应用程序之间建立了一个抽象层。这些单独的图表使在Kubernetes中部署、调试和更新应用程序及其单独的值和升级生命周期变得容易。您可以在像bitnami/wordpress这样的示例图表中浏览文件夹结构、依赖项和值文件。


3、使用标签轻松查找资源

标签对于Kubernetes的内部运营和Kubernetes运维人员的日常工作至关重要。Kubernetes中的几乎每个资源都为不同的目的提供标签,例如分组、资源分配、负载平衡或调度。

单个Helm命令将允许您安装多个资源。但了解这些资源的来源至关重要。标签使您能够快速找到由Helm版本创建的资源。


最常用的方法是在helpers.tpl中定义标签,如下所示:

{{/*Commonlabels*/}}
{{-define"="">common.labels"="">-}}app.kubernetes.io/instance:{{.Release.Name}}app.kubernetes.io/managed-by:{{.Release.Service}}{{-end-}}


然后,您需要在资源模板中使用带有标签的“include”函数:

apiVersion:apps/v1kind:Deploymentmetadata:name:my-queuelabels:{{include"="">common.labels"="">.|indent4}}...


现在您应该能够使用标签选择器列出所有资源。例如,您可以使用该kubectlgetpods-lapp.kubernetes.io/instance=[NameoftheHelmRelease]命令列出my-queue部署的所有pod。这一步对于定位和调试Helm管理的资源至关重要。


4、记录你的图表

文档对于确保可维护的Helm图表至关重要。在资源模板和README中添加注释可帮助团队开发和使用Helm图表。


您应该使用以下三个选项来记录您的图表:


  • 注释:模板和值文件是YAML文件。您可以添加注释并提供有关YAML文件中字段的有用信息。

  • README:图表的README是一个Markdown文件,解释了如何使用图表。您可以使用以下命令检查README文件的内容:helmshowreadme[NameoftheChart]

  • NOTES.txt:这是一个位于的特殊文件templates/NOTES.txt,提供有关版本部署的有用信息。NOTES.txt文件的内容也可以使用类似于资源模板的函数和值进行模板化:

Youhavedeployedthefollowingrelease:{{.Release.Name}}.Togetfurtherinformation,youcanrunthecommands:$helmstatus{{.Release.Name}}$helmgetall{{.Release.Name}}


在helminstall或helmupgrade命令结束时,Helm会打印出NOTES.txt的内容,如下所示:

RESOURCES:==>v1/SecretNAMETYPEDATAAGEmy-secretOpaque10s
==>v1/ConfigMapNAMEDATAAGEdb-configmap30s
NOTES:Youhavedeployedthefollowingrelease:precious-db.Togetfurtherinformation,youcanrunthecommands:$helmstatusprecious-db$helmgetallprecious-db

5、测试你的图表


Helmcharts由多个要部署到集群的资源组成。必须检查是否在集群中创建的所有资源都具有正确的值。例如,在部署数据库时,您应该检查数据库密码设置是否正确。


幸运的是,Helm提供了一个在集群中运行一些容器以验证应用程序的测试功能。例如,注解的资源模板"="">helm.sh/hook":test-success由Helm作为测试用例运行。="">


假设您正在使用MariaDB数据库部署WordPress。Bitnami维护的Helmchart有一个pod来验证数据库连接,定义如下:

...apiVersion:v1kind:Podmetadata:name:"="">{{.Release.Name}}-credentials-test"="">annotations:"="">helm.sh/hook"="">:test-success...env:-name:MARIADB\_HOSTvalue:{{include"="">wordpress.databaseHost"="">.|quote}}-name:MARIADB\_PORTvalue:"="">3306"="">-name:WORDPRESS\_DATABASE\_NAMEvalue:{{default"="">"="">.Values.mariadb.auth.database|quote}}-name:WORDPRESS\_DATABASE\_USERvalue:{{default"="">"="">.Values.mariadb.auth.username|quote}}-name:WORDPRESS\_DATABASE\_PASSWORDvalueFrom:secretKeyRef:name:{{include"="">wordpress.databaseSecretName"="">.}}key:mariadb-passwordcommand:-/bin/bash--ec-|mysql--host=$MARIADB\_HOST--port=$MARIADB\_PORT--user=$WORDPRESS\_DATABASE\_USER--password=$WORDPRESS\_DATABASE\_PASSWORDrestartPolicy:Never{{-end}}...



建议为您的图表编写测试并在安装后运行它们。例如,您可以使用helmtest命令运行测试。这些测试是用于验证和发现使用Helm安装的应用程序中的问题的宝贵资产。


6、确保Secrests安全

敏感数据(例如密钥或密码)作为secrets存储在Kubernetes中。尽管可以在Kubernetes端保护secrets,但它们大多作为Helm模板和值的一部分存储为文本文件。


在Helm,secrets插件提供secrets的管理和保护您的重要信息。它将secrets加密委托给MozillaSOPS,后者支持AWSKMS、GCP上的CloudKMS、AzureKeyVault和PGP。

假设您已将敏感数据收集在名为secrets.yaml的文件中,如下所示:


postgresql:postgresqlUsername:postgrespostgresqlPassword:WoZpCAlBsgpostgresqlDatabase:wp


您可以使用插件加密文件:

$helmsecretsencsecrets.yamlEncryptingsecrets.yamlEncryptedsecrets.yaml


现在,文件将被更新并且所有值都将被加密:

postgresql:postgresqlUsername:ENC\[AES256\_GCM,data:D14/CcA3WjY=,iv...==,type:str\]postgresqlPassword:ENC\[AES256\_GCM,data:Wd7VEKSoqV...,type:str\]postgresqlDatabase:ENC\[AES256\_GCM,data:8ur9pqDxUA==,iv:R...,type:str\]sops:...


上面secrets.yaml中的数据并不安全,helm-secrets解决了将敏感数据存储为Helmcharts的问题。



">">">

7. 使用模板函数使您的Helm图表可重用

Helm支持60多个可在模板中使用的函数。这些函数在Go模板语言和Sprig模板库中定义。模板文件中的函数显著简化了Helm操作。


我们以下面的模板文件为例:

apiVersion:v1kind:ConfigMapmetadata:name:{{.Release.Name}}-configmapdata:environment:{{.Values.environment|default"="">dev"="">|quote}}region:{{.Values.region|upper|quote}}


当没有提供环境值时,模板函数会默认。当您检查区域字段时,您会看到模板中没有定义默认值。但是,该字段具有另一个称为upper的函数,用于将提供的值转换为大写。


另一个重要且有用的功能是required.它使您能够根据模板渲染的需要设置一个值。例如,假设您需要使用以下模板为ConfigMap命名:

...metadata:name:{{required"="">Nameisrequired"="">.Values.configName}}...


如果该条目为空,则模板渲染将失败并显示错误Nameisrequired。创建Helm图表时,模板函数非常有用。它们可以改进模板、减少代码重复,并可用于在将应用程序部署到Kubernetes之前验证值。


8. 当 ConfigMaps 或 Secrets 改变时更新你的部署

将ConfigMaps或secrets安装到容器是很常见的。尽管部署和容器镜像会随着新版本而变化,但ConfigMap或secrets不会经常更改。以下注释可以在ConfigMap更改时滚动更新部署:

kind:Deploymentspec:template:metadata:annotations:checksum/config:{{include(print$.Template.BasePath"="">/configmap.yaml"="">).|sha256sum}}...


ConfigMap中的任何更改都将计算sha256sum新的部署版本并创建新版本。这确保部署中的容器将使用新的ConfigMap重新启动。


9. 使用资源策略选择退出资源删除

在典型的设置中,安装Helmchart后,Helm将在集群中创建多个资源。然后,您可以通过更改值以及添加或删除资源来升级它。一旦您不再需要该应用程序,您可以将其删除,这会从集群中移除所有资源。但是,即使在运行Helm卸载之后,某些资源也应保留在集群中。假设您已经使用PersistentVolumeClaim部署了一个数据库,并且即使您要删除数据库版本也希望存储卷。对于此类资源,您需要使用资源策略注释,如下所示:

kind:Secretmetadata:annotations:"="">helm.sh/resource-policy"="">:keep...


Helm命令(例如卸载、升级或回滚)会导致删除上述Secrets。但是通过使用如图所示的资源策略,Helm将跳过Secrets的删除并允许它成为孤立的。因此,应该非常小心地使用注释,并且仅用于在HelmReleases被删除后所需的资源。


10. 调试 Helm Chart 的有用命令

Helm模板文件带有许多不同的功能和用于创建Kubernetes资源的多个值来源。了解部署到集群的内容是用户的基本职责。因此,您需要学习如何调试模板和验证Helm图表。有四个基本命令可用于调试:


  • helmlint:linter工具进行一系列测试以确保您的图表正确形成。

  • helminstall--dry-run--debug:此函数呈现模板并显示生成的资源清单。您还可以在部署之前检查所有资源,并确保设置了值并且模板功能按预期工作。


  • helmgetmanifest:此命令检索安装到集群的资源的清单。如果发布未按预期运行,这应该是您用来找出集群中正在运行的内容的第一个命令。


  • helmgetvalues:此命令用于检索安装到集群的版本值。如果您对计算值或默认值有任何疑问,这绝对应该在您的工具带中。


11.使用查找功能避免Secrets再生

Helm函数用于生成随机数据,例如密码、密钥和证书。随机生成会在每次部署和升级时创建新的任意值并更新集群中的资源。例如,它可以在每次版本升级时替换集群中的数据库密码。这会导致客户端在更改密码后无法连接到数据库。


为了解决这个问题,建议随机生成值并覆盖集群中已有的值。例如:

{{-$rootPasswordValue:=(randAlpha16)|b64enc|quote}}{{-$secret:=(lookup"="">v1"="">"="">Secret"="">.Release.Namespace"="">db-keys"="">)}}{{-if$secret}}{{-$rootPasswordValue=index$secret.data"="">root-password"="">}}{{-end-}}apiVersion:v1kind:Secretmetadata:name:db-keysnamespace:{{.Release.Namespace}}type:Opaquedata:root-password:{{$rootPasswordValue}}


上面的模板首先创建一个16个字符的randAlpha值,然后检查集群中的Secrets及其对应的字段。如果找到,它会覆盖并重用rootPasswordValue作为root-password。


12. 迁移到 Helm 3 以获得更简单、更安全的 Kubernetes 应用程序

最新的Helm版本Helm3提供了许多新功能,使其成为更轻巧、更精简的工具。推荐使用Helmv3,因为它增强了安全性和简单性。这包括:


删除Tiller:Tiller是Helm服务器端组件,但由于在早期版本中对集群进行更改所需的详尽权限已从v3中删除。这也造成了安全风险,因为任何获得Tiller访问权限的人都会对您的集群拥有过多的权限。


改进的图表升级策略:Helmv2依赖于双向策略合并补丁。它将新版本与ConfigMap存储中的版本进行比较并应用更改。相反,Helmv3比较旧清单、集群中的状态和新版本。因此,在升级Helm版本时,您的手动更改不会丢失。这简化了升级过程并增强了应用程序的可靠性。

有一个helm-2to3插件,您可以使用以下命令安装升级它:


$helm3plugininstallhttps://github.com/helm/helm-2to3


这是一个小而有用的插件,带有清理、转换和移动命令,可帮助您迁移和清理v2配置并为v3创建版本。


13. 保持持续交付管道的幂等性

Kubernetes资源是声明性的,因为它们的规范和状态存储在集群中。同样,Helm需要创建声明性模板和发布。因此,您需要在使用Helm时将持续交付和发布管理设计为幂等的。幂等操作是您可以多次应用而不改变第一次运行后的结果的操作。


有两个基本规则需要遵循:

  1. 始终使用该helmupgrade--install命令。如果图表尚未安装,它会安装图表。如果它们已经安装,它会升级它们。


  2. 使用--atomic标志在helm升级期间操作失败时回滚更改。这确保Helm版本不会停留在失败状态。


总结

Helm是将应用程序部署到Kubernetes集群不可或缺的工具。但只有遵循最佳实践,您才能真正获得Helm的好处。


本文中介绍的最佳实践将帮助您的团队创建、操作和升级生产级分布式应用程序。从开发方面来看,您的Helm图表将更易于维护和保护。在操作方面,您将享受自动更新的部署、从删除中节省资源,并学习如何测试和调试。


Helm的官方主题指南是检查Helm命令和理解其设计理念的另一个很好的资源。有了这些资源以及本文章中概述的最佳实践和示例,您一定会武装并准备好创建和管理在Kubernetes上运行的生产级Helm应用程序。


收起阅读 »

Kubernetes 容量规划:如何调整集群请求的大小

Kubernetes 容量规划是基础架构工程师必须面对的主要挑战之一,因为了解 Kubernetes 的资源要求和限制并非易事。您可能预留了更多的资源,以确保容器不会用完内存或受到 CPU 限制。如果您处于这种情况,那么即使不使用这些资源,也要向云厂商付费,这...
继续阅读 »

Kubernetes 容量规划是基础架构工程师必须面对的主要挑战之一,因为了解 Kubernetes 的资源要求和限制并非易事。

您可能预留了更多的资源,以确保容器不会用完内存或受到 CPU 限制。如果您处于这种情况,那么即使不使用这些资源,也要向云厂商付费,这也将使调度变得更加困难。这就是为什么 Kubernetes 容量规划始终是集群的稳定性和可靠性与正确使用资源之间的平衡。

在本文中,您将学习如何识别未使用的资源以及如何合理分配群集的容量。

不要成为贪婪的开发者

在某些情况下,容器需要的资源超出了限制。如果只是一个容器,它可能不会对您的账户产生重大影响。但是,如果所有容器中都发生这种情况,则在大型群集中将产生几笔额外费用。

更不用说 Pod 占用资源太大,这可能需要你会花费更多的精力来发现占用资源过多的问题。毕竟,对于 Kubernetes 来说,占用资源过多的 Pod 调度起来相对困难。

介绍两个开源工具来帮助您进行 Kubernetes 的容量规划:

  • kube-state-metrics:一个附加代理,用于生成和公开集群级别的指标。
  • CAdvisor:容器的资源使用分析器。

c31f07625f2cbfc30fb7248f40ed1c48.png

通过在群集中运行这些工具,您将能够避免资源利用不足并调整群集资源占用的大小。

如何检测未充分利用的资源

CPU

CPU 资源占用是最难调整的阈值之一,如果调整的太小可能限制服务的计算能力,如果调整的太大又会造成该节点多数计算资源处于空闲状态。

41a73f0a9c422bed60245a0c2086c74e.png

检测空闲 CPU 资源

利用给出的container_cpu_usage_seconds_total、kube_pod_container_resource_requests参数,可以检测到 CPU 核心利用情况。

sum((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[30m]) - on (namespace,pod,container) group_left avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="cpu"})) * -1 >0)

0278a55c97a615a180654b634b3dac83.png

在上面的示例中,您可以看到在~7.10 和~7.85 之间没有使用内核。

如何识别那些命名空间浪费了更多的 CPU 内核

通过使用 PromQL 按名称空间汇总过去的查询,您可以获得更细粒度的使用情况。通过这些信息,使您能够向超大命名空间而且不充分利用资源的部门算账。

sum by (namespace)((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[30m]) - on (namespace,pod,container) group_left avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="cpu"})) * -1 >0)

3c0c891f4695b46745ca887fe53e9f10.png

查找 CPU 占用前 10 的容器

正如我们在 PromQL 入门指南中介绍的那样,您可以使用该 topk 函数轻松获取 PromQL 查询的最佳结果。像这样:

topk(10,sum by (namespace,pod,container)((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[30m]) - on (namespace,pod,container) group_left avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="cpu"})) * -1 >0))

3ea73f272a6cfc4d9097692615132d7c.png

内存

正确进行内存规划至关重要。如果您内存使用率过高,则该节点将在内存不足时开始逐出 Pod。但是内存也是有限的,因此设置越好,每个节点可以容纳的 Pod 就越多。

74084074e9281b1d217661a3c00a31b6.png

检测未使用的内存

您可以使用container_memory_usage_bytes、kube_pod_container_resource_requests查看您浪费了多少内存。

sum((container_memory_usage_bytes{container!="POD",container!=""} - on (namespace,pod,container) avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="memory"})) * -1 >0 ) / (1024*1024*1024)

7221576015dd26af94debea24f8eeff4.png

在上面的示例中,您可以看到可以为该集群节省 0.8gb 的成本。

如何识别哪些命名空间浪费了更多的内存

就像我们使用 CPU 一样,我们可以按命名空间进行聚合。

sum by (namespace)((container_memory_usage_bytes{container!="POD",container!=""} - on (namespace,pod,container) avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="memory"})) * -1 >0 ) / (1024*1024*1024)

1262367558eb49c2086b2c4ed4bf8ca0.png

查找内存过大的前 10 个容器

同样,使用该 topk 函数,我们可以确定在每个命名空间内浪费更多内存的前 10 个容器。

topk(10,sum by (namespace,pod,container)((container_memory_usage_bytes{container!="POD",container!=""} - on (namespace,pod,container) avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="memory"})) * -1 >0 ) / (1024*1024*1024))

cf9e9d1aa798848168966f6e6307d17a.png

如何对容器的资源利用进行优化


f1d1e4b629957e1256226a79e8bfa186.png

在 Kubernetes 容量规划中,要保留足够的计算资源,您需要分析容器的当前资源使用情况。为此,您可以使用此 PromQL 查询来计算属于同一工作负载的所有容器的平均 CPU 利用率。将工作负载理解为Deployment、StatefulSet、DaemonSet

avg by (namespace,owner_name,container)((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[5m])) * on(namespace,pod) group_left(owner_name) avg by (namespace,pod,owner_name)(kube_pod_owner{owner_kind=~"DaemonSet|StatefulSet|Deployment"}))

6b911f62fcafd193ab8d3751a2e52705.png

在上图中,您可以看到每个容器的平均 CPU 利用率。根据经验,可以将容器的 Request 设置为 CPU 或内存平均使用率的 85%到 115%之间的值。

如何衡量优化的影响

2737ae1a6453d8a8fc54a522920991b4.png

在执行了一些 Kubernetes 容量规划操作之后,您需要检查更改对基础架构的影响。为此,您可以将未充分利用的 CPU 内核现在与一周前的值进行比较,以评估优化后的影响。

sum((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[30m]) - on (namespace,pod,container) group_left avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="cpu"})) * -1 >0) - sum((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[30m] offset 1w) - on (namespace,pod,container) group_left avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="cpu"} offset 1w )) * -1 >0)

df791151e1ec1fe9f88ce803a74817c3.png

在上图中,您可以看到优化之后,集群中未使用的 CPU 更少了。

总结

现在您知道了贪婪的开发者的后果以及如何检测平台资源的过度分配。此外,您还学习了如何对容器的请求进行容量设置以及如何衡量优化的影响。

ebd861133a060cba97ff2d4d23eed7c6.png

这些技巧应该是构建全面的 Kubernetes 容量规划仪表板的良好起点,并获得包含优化平台资源所需的单一面板。


原文链接:Kubernetes capacity planning: How to rightsize the requests of your cluster

收起阅读 »

Rook v1.7 发布了!

Rook v1.7 存储增强Rook v1.7 发布了!此版本是另一个功能丰富的版本,用于改进 Kubernetes 的存储。与往常一样,感谢社区在此过程中提供的所有大力支持,以支持生产中的存储工作负载。自 4 月份 v1.6 发布以来,统计数据继续显示 Ro...
继续阅读 »


Rook v1.7 存储增强

607ba69075caf845d5fadf10df725185.png

Rook v1.7 发布了!此版本是另一个功能丰富的版本,用于改进 Kubernetes 的存储。与往常一样,感谢社区在此过程中提供的所有大力支持,以支持生产中的存储工作负载。


自 4 月份 v1.6 发布以来,统计数据继续显示 Rook 社区的增长:

「8K 到 8.8K Github 星数」

「216M 到 236M 容器下载」

「5.7K 到 6.0K 的Twitter关注者」

「4.2K 到 4.5K Slack 成员」

在v1.7 版本中,虽然许多改进是针对内部实现或 CI 自动化的,但我们也有一些主要针对 Ceph 存储提供商的新功能,我们希望您会对此感到兴奋!


Ceph 集群helm

很久以前,在 v1.0 中,Rook 发布了 Ceph operator helm chart。从那以后,有很多关于创建一个 helm chart 来安装其他 Ceph 资源的讨论。所以我们很高兴终于宣布 Ceph Cluster helm的到来!此helm将允许您配置以下资源:

「CephCluster CR」:创建核心存储集群「CephBlockPool」:创建一个Ceph rbd池和一个存储类,用于在池中创建PV(一般为RWO)「CephFilesystem」:创建一个Ceph 文件系统(CephFS)和一个用于创建 PV 的存储类(通常是 RWX)「CephObjectStore」:创建一个Ceph 对象存储(RGW) 和一个用于配置存储桶的存储类 工具箱:启动工具箱 pod以执行 ceph 命令 如果您不想使用 helm chart 进行部署,当然仍然可以使用示例 manifests创建相同的资源。

Ceph 文件系统镜像

与块镜像类似,文件镜像现在可以通过最新版本的 Ceph Pacific 实现。当无法扩展集群时,远距离镜像数据特别有用。Rook 现在支持自动配置远程对等点以启用镜像。将自动添加对等点,同时可以在每个文件系统的基础上选择镜像。与块镜像不同,文件镜像仅支持具有快照计划和保留的基于快照的镜像。

请记住,Ceph 中的 Ceph 文件系统镜像功能相对较新。您不会冒任何数据丢失的风险,但镜像本身仍在测试中。

资源保护不被删除

当 CephCluster 被删除时,Rook 会进行一些安全检查,以确保集群中仍有数据时不会删除该集群。我们采取了更进一步的措施来保护您的集群免受意外资源删除。现在,Rook 将拒绝删除 CephCluster 资源,直到从集群中删除所有子自定义资源「CephBlockPool、CephFilesystem、CephObjectStore、CephRBDMirror、CephNFS」

同样,如果找到任何桶或 「CephObjectStoreUsers」,将阻止删除 C「ephObjectStore」

Ceph 镜像移至 quay.io

上个月,Ceph 团队开始将官方 Ceph 容器镜像发布到quay.io而不是hub.docker.com。迁移到 Quay 有助于避免Docker 团队去年引入的镜像拉取率限制。hub.docker.com上的现有标签将继续工作,但新的 Ceph 版本只会发布到quay.io。实际上,这意味着要安装最新的 Ceph 版本,只需更新CephCluster CR 中的Ceph 镜像,如示例清单所示。

Stretch Clusters 进入稳定版本

「Ceph Stretch Cluster」功能最初在 v1.5 中作为实验性发布,现在宣布稳定,基于最新的 Ceph Pacific v16.2.5 版本。Github Actions 上的 CI 我们已经完成了从 Jenkins CI 到 Github Actions 的过渡。Github 操作提供了更大的灵活性以及自动化测试和提供稳定版本的能力。尽管 Jenkins 帮助我们到达了现在的位置,但现在是告别的时候了。

Rook 现在需要在 Golang 1.16 上构建以利用几个新功能和改进的依赖管理。展望未来,我们计划在 1.17 发布后支持最新的两个版本的 Golang。

已弃用类型的更新

正如任何operator所预期的那样,我们需要更新以支持 Kubernetes 中的新版本。

Cassandra 和 NFS operator的 CRD 从 v1beta1 更新到 v1,以提供更彻底的架构验证。

operator内部生成的几个资源从 v1beta1 更新到了 v1:「CronJobs、PodDisruptionBudgets 和 CSIDrivers」

计划中v1.8 弃用的内容

最后,我们希望给您足够的时间来提前计划在 2021 年 11 月时间范围内 v1.8 中的一些变化:

Kubernetes 支持的最低版本将从 K8s 1.11 提升到 K8s 1.16。

对 Ceph Nautilus 的支持将被移除,让我们能够专注于对 Octopus 和 Pacific 的持续支持。

flex 驱动程序将从 Rook 中删除。现在预计 Rook 中的所有卷都将使用 CSI 驱动程序创建。如果您有任何 Rook flex 卷或 in-tree rbd 或 cephfs 卷,请继续关注帮助您将它们迁移到 CSI 的工具。

下一步是什么?

我们将继续为 Kubernetes 开发可靠存储的operator,我们期待您的持续反馈。只有与社区一起,才有可能延续这种奇妙的势头。

无论是作为用户还是开发人员,都有许多不同的方式可以参与到 Rook 项目中。请加入我们,帮助该项目在超越 v1.7 里程碑的过程中继续发展!

参考链接:https://blog.rook.io/rook-v1-7-storage-enhancements-6ae647aa5d97



收起阅读 »

KEDA 2.4.0 有哪些新变化?

到目前为止,云原生软件的新迭代有很多,因为 CNCF 保护伞下的另一个工具获得了最新更新。此新更新中有许多更改、错误修复以及新功能和增强功能。我们将在本文中讨论所有这些。但是,让我们先来了解一下KEDA吧!什么是KADAKEDA 是一个云原生计算基金会 (CN...
继续阅读 »


到目前为止,云原生软件的新迭代有很多,因为 CNCF 保护伞下的另一个工具获得了最新更新。此新更新中有许多更改、错误修复以及新功能和增强功能。我们将在本文中讨论所有这些。但是,让我们先来了解一下KEDA吧!

480e4b6452a06cc04d0ea709b910ab3c.png

什么是KADA

KEDA 是一个云原生计算基金会 (CNCF) 沙箱项目,它允许对事件驱动的 Kubernetes 工作负载进行细粒度的自动缩放(包括到/从零)。KEDA 以作为 Kubernetes 指标服务器而闻名,它将使用户能够使用专用的 Kubernetes 自定义资源定义来定义自动缩放规则。KEDA 既可以在云端运行,也可以在边缘运行。它还与 Kubernetes 组件(例如 Horizontal Pod Autoscaler)本地集成,并且没有外部依赖项。


所以,我们将看看新的更新带来了什么。开始吧。


2.4.0亮点



新版本有很多值得一提的亮点功能。在 2.4.0 版本中,我们看到了新的 Solace PubSub + Event Broker 缩放器的引入。同样,我们可以看到引入了新的 Selenium Grid 缩放器和新的 Kubernetes 工作负载缩放器。此版本还附带重要版本的回退功能空闲副本模式您可以通过阅读本文了解如何部署 Keda 。

https://keda.sh/docs/2.4/deploy/


新特性



我们在突出显示部分看到的所有功能都是新功能。除此之外,我们还可以看到此新更新的另一个基本功能:ScaledJob。从现在开始,此新功能将支持用于待处理作业计数计算的 pod 条件。

改进

在新版本中,我们可以通过使用单个 HTTP 请求获取所有主题偏移量来查看 Kafka 缩放器的优化。此外,我们还看到了指定 Kafka Broker 版本的添加能力。版本 2.4.0 支持在 RabbitMQ 缩放器中自定义指标名称。它现在还支持使用正则表达式来选择RabbitMQ缩放器中的队列。


另一项重大改进来自Azure Monitor 缩放器的扩展,以支持自定义指标。此外,谈到 Azure,还有一些更多的修改,例如在Azure 服务总线缩放器中支持非公共云环境。另一个 Azure 改进,例如支持Azure 存储队列和Azure 存储 Blob 缩放器中的非公共云环境,现在将变得可见。


新的更新伴随着 InfluxDB 缩放器的调整,它将支持返回整数的查询以及返回浮点数的查询。它现在将允许从(集群)TriggerAuthentication获取 InfluxDB authTokenserverURL和组织名称。IBM MQ 缩放器密码处理修复等重要改进将使 Keda 性能更好。


Metrics APIServer 的另一项重大改进,现在将添加速率限制参数来覆盖客户端。新更新还修复了 ScaledJob 的 READY 和 ACTIVE 字段,以在我们运行kubectl get sj 时显示状态。它还在使用 kubectl get ta 或kubectl get cta 时指示 HashiCorp Vault 地址。新版本带来了特定的改进,当 HashiCorp Vault 路径不存在时,我们不必惊慌。




重大变化



与此新更新一起出现的重大更改是keda-system-auth-delegatorClusterRoleBinding名称的修复。升级可能会留下一个带有旧名称的KADA ClusterRoleBinding keda:system:auth-delegator

其它变化



我们在 2.4.0 版中看到的唯一其他更改是使用scaled[object/job].keda.sh/前缀作为 KEDA 相关标签。

结论



在整篇文章中,我们已经看到了此新更新带来的改进和新功能。这一切都使 KEDA 更易于处理,并增加了用户参与度。您还可以通过单击此处尝试这种令人敬畏的功能并获取最新更新。

https://github.com/kedacore/keda/releases





收起阅读 »

Prometheus v2.29.0 来了

Prometheus 是一个Cloud Native Computing Foundation项目,我们可以将其定义为服务监控系统。它以给定的时间间隔从配置的目标收集指标,评估规则表达式,显示结果,并可以在我们观察到指定条件时触发警报。 Prometheu...
继续阅读 »

Prometheus 是一个Cloud Native Computing Foundation项目,我们可以将其定义为服务监控系统。它以给定的时间间隔从配置的目标收集指标,评估规则表达式,显示结果,并可以在我们观察到指定条件时触发警报。




43314aaef43414982336f8a77abca63e.jpeg


Prometheus v2.29.0 发布了许多新功能。我们也可以看到许多增强功能和一些错误修复。我们将在本文中查看所有这些项目。


Prometheus 是一个Cloud Native Computing Foundation项目,我们可以将其定义为服务监控系统。它以给定的时间间隔从配置的目标收集指标,评估规则表达式,显示结果,并可以在我们观察到指定条件时触发警报。


变化

Prometheus v2.29.0 发布了许多新功能。我们也可以看到许多增强功能和一些错误修复。我们将在本文中查看所有这些项目。


aca1b09b05ab3987a2d279d2392e4dea.png

新特性

新版本带来了几个新功能。我们可以看到一个新功能,比如添加了Kuma服务发现。还添加了另一个新功能,其中包括present_over_timePromQL功能。同样,我们可以看到另一个新功能,例如通过文件配置示例存储并使其可重新加载。UI 的另一个独特功能是允许通过鼠标拖动选择时间范围。对于promtool,我们可以看到新功能,例如添加了标志等功能标志,—enable-feature并且还添加了file_sd文件验证。




a98eee6f92915dc4b9af03ef49fe7768.png


增强功能

新版本带来了许多与先前版本相关的新增强功能。我们可以看到减少了从系列垃圾收集中发出的远程写入请求的阻塞。我们也可以看到write-ahead-log解码性能的提升。此外,新版本通过减少互斥锁的使用改进了TSDB 中的附加性能。新的增强功能允许配置maxsamples_per_send远程写入元数据。

1d041896339d2373e98dab64310ac16d.png


有一些增强功能,例如添加__meta_gce_interface_ipv4元标签到GCE发现和添加meta_ec2_availability_zone_id元标签到EC2发现。此外,我们可以将metaazure_machine_computer_name元标签添加到Azure 发现中作为增强功能。__meta_hetzner_hcloud_labelpresent对 Hetzner 发现还有额外的元标签增强。

promtool 的增强为 promtool tsdb 分析报告带来了压缩效率,并允许通过 —max-block-duration 标志配置回填的最大块持续时间。对于用户界面的增强,我们可以观察到标志页面的排序和过滤的添加。同样对于 UI,新的更新还改进了警报页面,这将提升渲染性能。

Bug修复


随着 2.29.0 版的发布,我们看到了 Prometheus 的几个错误修复。首先,我们可以看到当总符号大小超过 2^32 字节时的日志记录,导致压缩失败并跳过压缩。同样,我们可以看到修复了不正确的trget_limit 重新加载零值。还修复了 head GC 和挂起的读取竞争条件。

a4aaf171eca0cf039b7f7a7eae2ccaef.png

我们可以看到的另一个基本修复是修复 OpenMetrics 解析器中的时间戳处理。其他修复(例如在指定多个匹配器时修复 /federate 端点中潜在的重复指标以及修复服务器配置和通过客户端证书进行身份验证的验证)在新版本中立即生效。最新版本现在允许作为 PromQL 查询中的标签名称再次开始和结束。在早期版本中,自从引入 @timestamp 功能以来,开发人员已经禁止它们。

结论


在整篇文章中,我们已经看到了这个新版本带来的各种变化和增强。此外,我们还讨论了几个错误修复和 2.29.0 版新功能的引入。我知道你们也迫不及待地想试试这个新的普罗米修斯。为此,您可以通过文末的下载链接更新至最新版本。

参考链接:https://prometheus.io/download/

收起阅读 »

服务网格 Istio 1.11 重磅发布

这是 Istio 在 2021 年的第三个版本,我们要感谢整个 Istio 社区,特别是来自红帽的发布经理 John Wendell、来自 Solo.io 的 Ryan King 和来自英特尔的 Steve Zhang,感谢他们帮助 Istio 1.11.0 ...
继续阅读 »

这是 Istio 在 2021 年的第三个版本,我们要感谢整个 Istio 社区,特别是来自红帽的发布经理 John Wendell、来自 Solo.io 的 Ryan King 和来自英特尔的 Steve Zhang,感谢他们帮助 Istio 1.11.0 发布。该版本正式支持 Kubernetes 1.18.0 到 1.22.x。下面是该版本的一些亮点。

d5590f441442a554875aae921a5ffea4.jpeg

CNI 插件(Beta)

默认情况下,Istio 会在部署在网格的 pod 中注入一个 init 容器 [2]istio-init 容器使用 iptables 设置 pod 网络流量重定向到(来自)Istio sidecar 代理。这需要网格中部署 pod 的用户或服务账户有足够的权限来部署具有 NET_ADMIN 和 NET_RAW 功能的容器 [3]。要求 Istio 用户拥有较高的 Kubernetes 权限,对于组织内的安全合规性来说是有问题的。Istio CNI 插件是 istio-init 容器的替代品,它执行相同的网络功能,但不要求 Istio 用户启用更高的 Kubernetes 权限。

CNI 插件可以与其他插件同时使用,并支持大多数托管的 Kubernetes 实现。

在这个版本中,我们通过改进文档和测试,将 CNI 插件功能提升为 Beta 版,以确保用户能够在生产中安全地启用这一功能。了解如何用 CNI 插件安装 Istio[4]

外部控制平面(Beta)

去年,我们为 Istio 引入了一种新的部署模式 [5],即集群的控制平面是在该集群之外管理的。这就解决了这样一个问题 —— 将管理控制平面的 Mesh 所有者和在 Mesh 中部署和配置服务的 Mesh 用户之间分离。运行在独立集群中的外部控制平面可以控制单个数据平面集群或多集群网格的多个集群。

在 1.11 版本中,该功能已被提升为 Beta 版。了解如何设置带有外部控制平面的网格 [6]

网关注入

Istio 提供了网关作为与外部世界连接的方式。你可以部署入口网关 [7] 和 出口网关 [8],前者用于接收来自集群外的流量,后者用于从你的应用程序向集群外部署的服务输出流量。

在过去,Istio 版本会将网关部署为一个 Deployment,它的代理配置与集群中所有其他的 Sidecar 代理完全分开。这使得网关的管理和升级变得复杂,特别是当集群中部署了多个网关时。一个常见的问题是,从控制平面传到 sidecar 代理的设置和网关可能会漂移,导致意外的问题。

网关注入将对网关的管理变得与一般的 sidecar 代理相同。在代理上设置的全局配置将适用于网关,以前不可能的复杂配置(例如,将网关作为 DaemonSet 运行)现在很容易。在集群升级后,你也可以简单地通过重启 pod 将网关更新到最新版本。

除了这些变化之外,我们还发布了新的安装网关 [9] 文档,其中包括安装、管理和升级网关的最佳做法。

对修订和标签部署的更新

在 Istio 1.6 中,我们增加了对同时运行多个控制平面的支持,这使得你可以对新的 Istio 版本进行金丝雀式部署 [10]。在 1.10 版本中,我们引入了 修订标签(revision tag)[11],这让你可以将一个修订版标记为 production 或 testing,并在升级时将出错的机会降到最低。

istioctl tag 命令在 1.11 中已经不再是实验性了。你现在也可以为控制平面指定一个默认的修订版。这有助于进一步简化从无修订版的控制平面到新版本的金丝雀升级。

我们还修复了一个关于升级的悬而未决的问题 [12] —— 你可以安全地对你的控制平面进行金丝雀升级,不管它是否使用修订版安装。

为了改善 sidecar 的注入体验,引入了 istio-injection 和 sidecar.istio.io/inject 标签。我们建议你使用注入标签,因为比注入注解的性能更好。我们打算在未来的版本中弃用注入注解。

支持 Kubernetes 多集群服务(MCS)(实验性)

Kubernetes 项目正在建立一个多集群服务 API[13],允许服务所有者或网格管理员控制整个网格的服务及其端点的输出。

Istio 1.11 增加了对多集群服务的实验性支持。一旦启用,服务端点的可发现性将由客户端位置和服务是否被导出决定。驻留在与客户端相同的集群中的端点将总是可被发现。然而,在不同集群内的端点,只有当它们被导出到网格时,才会被客户端发现。

注意,Istio 还不支持 MCS 规范所定义的 cluster.local 和 clusterset.local 主机的行为。客户应该继续使用 cluster.local 或 svc.namespace 来称呼服务。

这是我们支持 MCS 计划 [14] 第一阶段。请继续关注!

预告:新的 API

Istio 的一些功能只能通过 EnvoyFilter[15] 来配置,它允许你设置代理配置。我们正在为常见的用例开发新的 API—— 比如配置遥测和 WebAssembly(Wasm)扩展部署,在 1.12 版本中你可以看到这些功能。如果你有兴趣帮助我们测试这些实现, 请加入工作组会议 [16]

加入 Istio 社区

你也可以在 Discuss Istio[17] 加入讨论,或者加入我们的 Slack[18]

你想参与吗?寻找并加入我们的一个工作组 [19],帮助改进 Istio。

Istio 1.11 升级调查

如果你已经完成了对 Istio 1.11 的升级,我们想听听你的意见请花几分钟时间回复我们的简短调查 [20],告诉我们我们的工作情况。

参考链接:https://istio.io/latest/news/releases/1.11.x/announcing-1.11/

收起阅读 »

用于 Kubernetes OpenID Connect 身份验证的 kubectl 插件

这是一个用于Kubernetes OpenID Connect (OIDC) 身份验证的 kubectl 插件,也称为kubectl oidc-login.以下是使用 Google Identity Platform 进行 Kubernetes 身份验证的示例...
继续阅读 »



这是一个用于Kubernetes OpenID Connect (OIDC) 身份验证的 kubectl 插件,也称为kubectl oidc-login.

以下是使用 Google Identity Platform 进行 Kubernetes 身份验证的示例:


8f28c4c7cd31c95e98a42ab2e45646c7.gif




Kubelogin 旨在作为client-go 凭证插件运行当您运行 kubectl 时,kubelogin 会打开浏览器,您可以登录提供程序。然后 kubelogin 从提供者处获取令牌,kubectl 使用该令牌访问 Kubernetes API。看一下图表:



0bc296b9eda5096cf09793c45fc75969.png




收起阅读 »

咨询在线客服

1156141327

服务热线

13720071711

咨询时间 9:00 - 18:00

扫一扫联系我们

扫一扫联系我们