如何为 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




收起阅读 »

eBPF 成立独立基金会

Facebook、谷歌、Isovalent、微软和 Netflix 已联手在Linux 基金会的保护伞下创建了 eBPF基金会,为 eBPF 项目提供了一个中立的家,用于其未来的努力。该扩展Berkeley包过滤器(eBPF)在2014年最初创建,实际上起初在...
继续阅读 »

Facebook、谷歌、Isovalent、微软和 Netflix 已联手在Linux 基金会的保护伞下创建了 eBPF基金会,为 eBPF 项目提供了一个中立的家,用于其未来的努力。

4d455651a16562bd4253a16b2ff1e87e.png


该扩展Berkeley包过滤器(eBPF)在2014年最初创建,实际上起初在1992年创建,最早的名字原来称为Berkeley包过滤器(BPF),eBPF实际上扩展了原来的功能。eBPF 是一个完全独立的项目,提供对 BPF 的向后兼容性,被称为“Linux 最新的超级大国”。eBPF 为 Linux 内核提供了一种使用即时 (JIT) 编译器代表用户执行自定义操作的方法,同时还提供了一个完全沙盒化的环境。本质上,eBPF 允许您扩展 Linux 内核而无需实际更改它


“eBPF 始于 2014 年,原因很简单:Linux 内核社区不再能够就每一个变化达成一致。像谷歌和 Facebook 这样的公司进来了,他们要求进行某些改变,而且再也不可能在每个人之间达成共识,即这种改变对所有感兴趣的各方都有意义。因此,需要某些方面的可编程性。eBPF 就是解决这个问题的答案” 


Cilium背后的公司Isovalent 的联合创始人兼首席技术官Thomas Graf解释说:“现在,不必让整个 Linux 内核社区相信您的更改对每个人都很重要,您可以加载 eBPF 程序,这与 Web 开发人员不再需要说服每个浏览器供应商带来新功能的方式非常相似,而是可以编写 JavaScript 代码。”


Graf 解释说,这样的功能以前只适用于可以雇用内核团队来分叉 Linux 内核并维护自己的分支的公司,或者使用 Linux 内核模块的公司。虽然第一个选项成本过高,但 Linux 内核模块带来了另一个问题——任何错误都可能使 Linux 内核完全崩溃,最终,许多云提供商甚至不再允许在某些发行版中使用它们。


Graf 说“除非您可以托管、维护和雇用自己的内核团队,否则您会被发行版的 Linux 内核提供的功能所困。eBPF 改变了这一点。这是现在的第三种选择。你可以进行自己的更改,可以维护自己的更改,但不必维护下游分叉。”


Graf 将 eBPF 与 JavaScript 环境进行比较,因为它提供了沙盒环境和 JIT 编译器,这也意味着更改不需要重新编译内核,而是可以立即运行。对于那些使用 eBPF 构建应用程序的人,有一个 API,并且 SDK 可用于 C++、Go、Python 和 Rust。


9588215c937952c546e1da61b3eb79a4.png


近年来,eBPF 有了相当大的增长,该项目为网络、安全、应用程序分析/跟踪和性能故障排除领域的各种工具奠定了基础。最近,微软也开始将eBPF移植到“ Windows”,其中eBPF for Windows将把这个功能带到 Windows 10 和 Windows Server 2016,Graf 说 BSD 的移植也在工作中。Graf 说,最近的这种兴趣是成立 eBPF 基金会的部分原因。


https://github.com/microsoft/ebpf-for-windows


Graf 说:“eBPF 基金会将所有人聚集在一起,并创建了一个治理结构,允许所有人之间进行安全的创新,eBPF 变得非常流行,所以有更多的人想要控制它,就像我们在许多其他开源技术中看到的那样。该基金会确保治理、运行诸如事件之类的事情、做出技术决策、定义成为 eBPF 认证运行时的要求——所有这些决策都是由各方、工程师或创建 eBPF 的人。让每个人都感到可以安全地做出贡献是很重要的。这就是目标。”


在启动时,eBPF 基金会将从一些已建立的项目和库开始,包括一些新兴用例,该基金会还将成为未来开源 eBPF 项目和技术的所在地。该基金会还将帮助举办社区活动和峰会,最近的下周于 8 月 18 日至 19 日举行的免费虚拟eBPF 峰会。


https://ebpf.io/summit-2021/



收起阅读 »

Kubernetes 1.22发布:你应该知道的一切

K8s
今天,我们兴奋地向大家宣布,Kubernetes在2021年内的第二个版本、即1.22版本已经正式来临!新版本包含53项增强功能:其中13项功能已升级至稳定版,24项功能顺利步入beta阶段,16项功能刚刚开始alpha阶段。另有3项功能被彻底弃用。今年4月,...
继续阅读 »


9da9b50060ef78aa8ba85f8dc7fef35a.jpeg


今天,我们兴奋地向大家宣布,Kubernetes在2021年内的第二个版本、即1.22版本已经正式来临!
新版本包含53项增强功能:其中13项功能已升级至稳定版,24项功能顺利步入beta阶段,16项功能刚刚开始alpha阶段。另有3项功能被彻底弃用。


今年4月,Kubernetes的发布周期已经正式由每年4次调整为每年3次。而1.22版本正是调整之后的首个长周期发布版本。随着Kubernetes的逐渐成熟,每个发布周期中包含的增强功能数量一直在持续增加。这意味着贡献者社区及发布工程团队需要在两个版本之间完成更多开发工作,而新版本中的大量全新功能也会给最终用户社区带来一定的学习压力。


有鉴于此,Kubernetes的发布节奏由一年四次调整为一年三次能够带来更好的均衡效果,包括贡献与版本管理、社区规划升级并为用户提供更舒适的更新上手体验。


版本要点


Server-side Apply迎来GA通用版本
Server-side Apply[1]是一种面向Kubernetes API服务器的全新字段所有权及对象合并算法。Server-side Apply通过声明式配置帮助用户及控制器管理其资源,包括以声明方式创建及/或修改对象、发送明确指定的意图等等。经过数个版本的测试之后,Server-side Apply现已正式进入GA通用版阶段。


外部凭证提供程序迎来稳定版
自1.11版本以来,对Kubernetes客户端凭证插件的支持就一直处于测试阶段。而随着Kubernetes 1.22的推出,这项功能逐步趋于稳定。其中的GA功能集现在包括对交互式登录流程插件提供更好的支持,同时修复了多项bug。感兴趣的插件作者可以参考sample-exec-plugin[2]以了解更多详细信息。


etcd更新至3.5.0
Kubernetes的默认后端存储etcd获得了3.5.0新版本。新版本改进了安全性、性能、监控以及开发者体验,修复了多项bug,同时带来了迁移为结构化日志记录与内置日志轮替等重要新功能。3.5.0版本还提出详尽的后续发展路线图,探索如何更好地解决流量过载问题。感兴趣的朋友可以参考3.5.0发布公告中的完整变更清单。


用于内存资源的Quality of Service(QoS)
最初,Kubernetes使用的是v1 cgroups API。通过这种设计,Pod的QoS类将仅可用于CPU资源(例如cpu_shares)。如今,Kubernetes 1.22版以alpha测试的形式使用cgroups v2 API控制内存分配与隔离,希望在内存资源发生争用时提高工作负载与节点的可用性、改善容器生命周期的可预测性。


节点系统交换支持
每一位系统管理员或Kubernetes用户在设置和使用Kubernetes时,都会不约而同地禁用掉交换空间。随着Kubernetes 1.22版本的发布,新的alpha功能已可支持运行具有交换内存的节点。这项变更使得管理员能够选择在Linux节点上配置交换,并将一部分块存储视为额外的虚拟内存。


Windows增强与功能
SIG Windows继续为不断发展壮大的开发者社区提供支持,并在1.22新版本中发布了自己的开发环境。这些新工具支持多种CNI提供程序并能够在多个平台上顺畅运行。通过编译Windows kubelet与kube-proxy,再配合日常构建的其他Kubernetes组件,新版本为用户带来一种从零开始使用全新Windows功能的新方法。


CSI对Windows节点的支持也在1.22版本中达到GA通用阶段。另外,Kubernetes 1.22迎来了新的alpha功能——Windows特权容器。为了在Windows节点上使用CSI存储,CSIProxy允许我们将CSI节点插件部署为非特权Pod,并使用代理在节点上执行特权存储操作。


seccomp默认配置
Kubelet以alpha功能的形式提供默认seccomp配置功能,同时附带新的命令行标志与配置。在使用时,这项新功能可提供集群范围内的seccomp默认值,并使用RuntimeDefault seccompt配置取代默认情况下的Unconfined,从而大大增强了Kubernetes部署的默认安全性。凭借更出色的默认工作负载安全效果,管理员们终于可以睡个好常见了。若需了解这项功能的更多详细信息,请参阅官方seccomp教程[3]。


使用kubeadm提升控制平面安全
这项新的alpha功能允许我们以非root用户身份运行kubeadm控制平面组件。长久以来,kubeadm一直要求采取这样一种安全措施。要实际体验,你需要在kubeadm中启用特定的RootlessControlPlane feature gate。在使用这项alpha功能部署集群时,你的控制平面将以较低权限运行。


对于kubeadm,Kubernetes 1.22还带来了新的v1beta3配置API。此次迭代带来了多项社区期待已久的功能,同时弃用了部分现有功能。v1beta3将成为目前的首选API版本;但v1beta2 API仍然正常可用,并未在1.22版中被淘汰。


主要变化


删除了几个已弃用的beta API
1.22版本中删除了许多已经弃用的beta API,并发布这些API的GA通用版本。全部现有对象均可通过稳定的API进行交互。此次删除涉及 Ingress,IngressClass,Lease,APIService,ValidatingWebhookConfiguration,MutatingWebhookConfiguration,CustomResourceDefinition,TokenReview,SubjectAccessReview以及 CertificateSigningRequest API的beta版本。


临时容器的API变更与改进
用于创建临时容器的API在1.22版本中也发生了变化。临时容器功能现为alpha版且默认禁用,新的API也不再响应客户端对旧有API的使用请求。


在稳定功能方面,kubectl工具遵循Kubernetes版本倾斜策略,但kubectl v1.21及更早版本无法支持临时容器的新API。如果你打算使用kubectl debug创建临时容器,且你的集群运行有Kubernetes 1.22,则无法使用kubectl v1.21或更早版本完成这项操作。如果你希望将kubectl debug与多个集群版本混合使用,请务必将kubectl更新至1.22。


其他更新


更新至稳定版
  • 限定服务账户令牌数量

  • CSI服务账户令牌

  • Windows对CSI插件的支持

  • 对于在操作中使用已弃用API的警告机制

  • 清退PodDisruptionBudget


重要功能更新
  • 引入新的PodSecurity准入alpha功能,用以替代原有PodSecurityPolicy

  • The Momory Manager进入beta阶段

  • 推出新的alpha功能,用于实现API Server Tracing

  • kubeadm配置格式迎来新的v1beta3版本

  • 用于PersistentVolumes的通用数据填充器已提供alpha版

  • Kubernetes控制平面现可始终使用CronJobs v2控制器

  • 作为alpha功能,所有Kubernetes节点组件(包括kubelet、kube-proxy与容器运行时)都能够以非root用户身份运行


发布说明


请点击此处[6]查看1.22版本的完整发布说明信息。


发布时间


Kubernetes 1.22现已开放下载[7]并正式登陆GitHub[8]。


版本徽标


12e1eb96972cf0e04071b0e3f725137f.png


面对新冠疫情、自然灾害与倦怠情绪的重重挑战,Kubernetes 1.22仍然拿出了53项增强功能,这也使其成为迄今为止更新量最大的Kubernetes版本。这样辉煌的成就,离不开发布团队成员们的辛勤努力、热情奉献以及Kubernetes生态系统中杰出贡献者们的不懈支持。1.22版本发布徽标提醒我们要不断突破新的极限、创造新的纪录。谨以此标,献给每一位发布团队成员、攀登者与前瞻者!


徽标由Boris Zotkin设计。作为MathWorks的Mac/Linux管理员,Boris热爱生活中平淡简单的一切,喜欢与家人共度时光。这里再次感谢这位乐观技术人贡献的精美作品!


相关链接:
  1. https://kubernetes.io/docs/reference/using-api/server-side-apply/

  2. https://github.com/ankeesler/sample-exec-plugin

  3. https://kubernetes.io/docs/tutorials/clusters/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads

  4. https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22

  5. https://blog.k8s.io/2021/07/14/upcoming-changes-in-kubernetes-1-22/

  6. https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md

  7. https://kubernetes.io/releases/download/

  8. https://github.com/kubernetes/kubernetes/releases/tag/v1.22.0

收起阅读 »

咨询在线客服

1156141327

服务热线

13720071711

咨询时间 9:00 - 18:00

扫一扫联系我们

扫一扫联系我们