Firewinds 博客中文翻译（一）

原文：Firewinds Blog

协议：CC BY-NC-SA 4.0

2023 年云原生预测

原文：https://www.fairwinds.com/blog/2023-cloud-native-predictions

当我们总结 2022 年并展望 2023 年时，以下是 Fairwinds 团队对云原生和 Kubernetes 的预测:Bill Ledingham，Andy Suderman，Robert Brennan 和 Kendall Miller。

经济形势使得金融运营成为重中之重

随着越来越多的公司希望了解云消费，FinOps 在 2022 年呈上升趋势。虽然许多组织可能已经涉足 FinOps，但随着组织寻求在 2023 年削减成本以度过经济不确定性，我们将看到对 FinOps 的需求增加。云采用和支出增加的持续趋势要求组织更好地控制云成本。更多的公司将在技术和业务方面组建利益相关者的 FinOps 团队，以推动消费变革。

例如，与直接在 EC2 实例上的花费相比，在 Kubernetes 集群上的花费将会越来越多。这意味着，对于 Kubernetes 用户来说，了解规模合理的机会变得极其重要，这样就可以根据 Kubernetes 的工作负载、命名空间和标签来优化云消费。

左移开发继续采用服务所有权

“一切都向开发者移动”运动，也称为“左移”，将在 2023 年继续占据主导地位。在过去的两年里，我们已经将它视为营销热点，但现实是，越来越多的开发人员被要求做一切事情，即构建应用程序、保护应用程序、适当规模的云使用。实现这一点的唯一方法是将左移工具集成到开发人员已经了解并喜爱的技术中。它将支持“服务所有权”，即开发者“编码、发布、拥有”服务的能力平台工程团队将在 2023 年花费更多时间来选择工具，以帮助实现服务所有权，并腾出时间让他们的团队进行创新。

安全仍然是一个问题

这听起来可能是显而易见的，但安全性将继续是一个问题——它不会变得更好。安全团队和开发团队(即 DevSecOps)之间仍然没有足够的协调来真正改善许多组织的安全状况。

网络安全将变得流行

网络策略落后于其他安全考虑，如容器和配置扫描。在 2023 年，我们认为更多的组织将开始采用网络策略来保护他们的 Kubernetes 环境，并最大限度地减小攻击的爆炸半径。

Kubernetes 护栏成为主流

Kubernetes 的采用趋势将持续到 2023 年，因此，对 Kubernetes 护栏的需求将成为主流。随着使用量的增加，开发运维将需要与企业中其他技术相同的策略级别。实施 Kubernetes guardrails 对于提高应用程序的安全性和可靠性至关重要，同时优化云的使用。

云原生自动化推动改进

不幸的是，一天中没有足够的时间或资源来做所有的事情。到 2023 年，整个原生云将越来越多地采用自动化来提高安全性和成本。自动化将推动改进，因此人们可以在创新活动上花费更多时间，并可能推动工具整合，以控制环境。

此外，自动化将在控制云支出方面发挥重要作用。公司不能继续进行时间密集、成本高昂且高度不准确的手动调整，因此他们将转向自动化来解决某些难题。

公司为 Kubernetes 采用开源安全工具

作为一个开源平台本身，Kubernetes 的使用和相关的开源技术现在在许多企业组织中很流行。虽然开放源码的采用已经变得正常化，但是，安全性在历史上一直是为购买专有软件提供的。2023 年，我们将看到更多的公司采用开源安全工具来保护 Kubernetes。

然而，随着这种使用的增加，我们可能会看到开源供应链攻击的数量增加，因为项目意外地发布了带有漏洞的包。这将是企业需要考虑的一把双刃剑。

云提供商希望锁定 Kubernetes 用户

我们看到云提供商继续将开源集成添加到他们的托管 Kubernetes 产品中。这一趋势将随着更多功能的定期出现而持续下去。终端用户面临的挑战是锁定。在 2023 年，你需要密切关注并谨慎对待你从云提供商那里采用的东西和从第三方提供商那里使用的东西。

2023 年 Kubernetes 基准报告:Kubernetes 工作负载成本状况

原文：https://www.fairwinds.com/blog/2023-kubernetes-benchmark-report-the-state-of-kubernetes-workload-costs

组织继续向云迁移。事实上，根据 Flexera 的 2022 年技术支出脉搏 ，65%的受访者将云和云迁移作为下一年的首要任务。对于大多数人(74%)来说，数字化转型比以往任何时候都更加重要，这一举措正推动着向云迁移的意愿不断增强。然而，管理云和 Kubernetes 成本仍然是大多数组织面临的持续挑战，根据 CNCF 的 FinOps for Kubernetes 报告，“Kubernetes 成本监控不足或不存在导致超支 ”那么，在分析 Kubernetes 工作负载的效率时，这看起来像什么呢？

使用 2022 年的数据，其中包括超过 150，000 个工作负载，Fairwinds 分析了当前趋势以及它们与上一年的比较，从而创建了 2023 年 Kubernetes 基准报告 。虽然 Kubernetes 的采用持续增长，但最佳实践对许多组织来说仍然具有挑战性。不符合最佳实践会导致云成本超支、安全风险增加以及云应用和服务缺乏可靠性。

为了确保您的 Kubernetes 集群尽可能高效，您需要正确地设置资源限制和请求。例如，如果您在应用程序上将内存请求和限制设置得太低，Kubernetes 会因为您的应用程序违反了限制而终止它。另一方面，如果您将限制和请求设置得太高，就会过度分配资源，从而导致更高的云账单。

那么，当谈到 成本效率 时，组织的发展趋势是正确的吗？让我们深入数据找出答案。

CPU 请求和限制

当设置 CPU 请求和限制 时，有一个好消息。基准数据显示，72%的组织仅将 10%的工作负载限制设置得过高。只有 1%的组织有 91=100%的工作负载受到设置过高的 CPU 限制的影响。

就 CPU 限制设置过低而言，94%的组织仅将 0-10%的工作负载限制设置过低。

内存限制太高

类似于 2022 年发布的基准测试报告，对于近 50%的工作负载，组织的 内存限制设置过高 。但是，今年受影响的工作负载百分比有所增加。当我们查看 2021 年收集的数据时，只有 3%的组织有 51-60%的工作负载受到影响。这一数字今年大幅增长。现在，30%的组织至少有 50%的工作负载受到内存限制设置过高的影响。这相当于浪费了大量的云资源。调整这些内存限制，使其与工作负载需求保持一致，这将有助于您进行控制，并减少膨胀的云账单。

内存限制太低

有趣的是，看起来许多组织(67%，比去年的 70%略有下降)仍然对至少 10%的工作负载设置过低的内存限制。虽然受影响的工作负载数量相对较少，但一定要记住，将这些内存限制设置得太低会降低集群的可靠性。同样，你可以 为你的应用调整这些限制 ，以确保它们不会在压力下失败。额外的好处:适当地调整这些可以帮助你确保你没有浪费你的云资源。

发生内存不足错误(OOMKills)。为了减少卵杀死的潜在影响，fair winds Insights包括一个检测和报告卵杀死的工具。这样，你就知道什么时候发生了，这样你就能迅速做出反应。如果您选择将其设置为允许的话，该工具还可以增加内存以避免停机。

内存请求太低

不出所料，应用程序的可靠性变得非常具有挑战性，当内存请求设置得太低时，这种挑战会变得非常快。好消息是，对 59%的组织的工作负载的分析表明，这个问题只影响了他们工作负载的 10%左右，这与 2021 年的数据分析结果相似。

如果您希望避免与设置过高或过低的内存请求相关的效率(和可靠性)问题，请寻找分析使用情况并提出建议的工具，以帮助您适当地调整内存请求。Goldilocks 是一款开源工具，可以帮助你决定你需要做哪些改变。如果您正在跨多个团队运行多个集群，请尝试 Fairwinds Insights 平台。我们的 自由层 非常适合最多 20 个节点、两个集群和一个存储库的环境。

内存请求过高

在这方面，34%的组织对至少 10%的工作负载设置了过高的内存请求。不幸的是，82%的组织现在将工作负载的内存请求设置得过高，这是一个显著的增长。数据分析显示，与前一年相比，更多工作负载受到过高内存限制的影响，这是一种不受欢迎的趋势。

关于 Kubernetes 工作负载成本的要点

虽然大多数与效率相关的 Kubernetes 工作负载设置与上一年相比没有显著变化，但它们并没有像您希望的那样朝着积极的方向发展。2023 年已经成为有趣的一年，重点是更仔细地分析成本，关注在哪里以及如何调整云支出，以最低的支出实现最大的可靠性。随着越来越多的组织将更多的应用和服务转移到云，密切关注工作负载消耗的资源量非常重要。请阅读完整报告，了解有关这些结果的更多信息，并深入了解安全性和可靠性的趋势。

阅读 完成 Kubernetes 基准报告 今天。

2023 年 Kubernetes 基准报告:您的 Kubernetes 工作负载相比如何？

原文：https://www.fairwinds.com/blog/2023-kubernetes-benchmark-report

Kubernetes 的采用正在增长，随着组织越来越多地使用 it 来自动化容器化应用的部署、管理和扩展，更多的团队开始关注其工作负载的可靠性、安全性和成本效益。去年，Fairwinds 基于对超过 100，000 个 Kubernetes 工作负载的评估，创建了一份新的 Kubernetes 基准报告，旨在帮助组织更好地了解他们的容器配置，并将他们的结果与同行的结果进行比较。今年，Fairwinds 根据 2022 年的数据(超过 150，000 个工作负载)更新了 基准报告 ，并与上一年的数据进行了比较，以分析过去一年的情况如何改善(或没有改善)。

2023 年 Kubernetes 最关心的是什么？

Kubernetes 安全性、成本效益和可靠性仍然是 云原生用户 最关心的问题。您的开发团队现在想知道的是，他们如此努力地建立他们的 Kubernetes 环境，并努力正确地配置他们的工作负载，与您在云原生生态系统中的同行相比，您的配置看起来如何。

根据基准数据，人们仍然没有将 Kubernetes 配置为符合 最佳实践 。不幸的是，这转化为不必要的风险、云成本超支，甚至(潜在的)由于糟糕的应用程序性能而失去客户。最新的 Kubernetes 基准测试报告可以帮助您更好地了解将时间和金钱用于改进配置的最佳途径。

DevOps 队寡不敌众

数百家组织正在使用fair winds Insights 平台 ，在 2022 年运行超过 15 万个工作负载。通过根据可靠性、安全性和成本效率指标评估基准测试集群的结果，我们可以看到情况实际上变得更糟，而不是更好。2021 年的数据显示，许多结果只有不到 10%的工作负载受到影响，但今年所有核心问题都发生了变化。为什么会这样呢？

随着 Kubernetes 使用的扩展，DevOps 管理新团队引入的潜在配置风险变得更加困难。换句话说，他们寡不敌众——Kubernetes 的采用速度超过了他们应用必要的策略和控制的能力。我们需要通过自动化 Kubernetes 治理 和 护栏 来帮助他们，而不是依赖手动流程并试图引用和交叉检查策略并强制执行它们。

无论您是在使用云原生技术开发应用和服务，还是在构建基础架构的开发运维团队和平台工程团队中，您都需要一个高性能、安全且经济高效的平台。

我们今年再次将 基准报告 分为三个板块:可靠性、安全性、成本效率。您在哪些方面落后了，如何改进您的 Kubernetes 配置？

可靠性

Kubernetes 的可靠性会受到六个关键配置问题的影响，其中许多问题很难解决。不容易知道为每个应用程序分配什么值，导致没有限制、限制不足，或者在测试期间限制设置得太高且从未纠正。今年，只有大约 17%的组织为超过 90%的工作负载设置了内存请求和限制，与去年的 41%相比大幅下降。同样，许多组织缺少活性和准备就绪探测器，依赖于 Docker 映像 的 缓存版本，并且缺少 CPU 请求和限制。今年新增，我们现在检查只有一个副本的部署，因为副本部署有助于保持容器的稳定性和高可用性。

安全性

我们在今年的报告中评估了九种不同的安全相关 Kubernetes 配置，不仅显示了组织去年的表现，还显示了今年的一些严重波动。2021 年，42%的组织关闭了大部分工作负载的不安全功能，但令人惊讶的是，今年只有 10%的组织关闭了这些功能。最新报告显示，33%的组织有超过 90%的工作负载使用不安全的功能运行。

另一个重要的安全设置是readOnlyRootFilesystem，它防止容器写入其文件系统。在最新的报告中，在安全性方面有另一个重要的转变，这表明组织可能没有意识到需要覆盖 Kubernetes 中不安全的默认设置。该报告还显示了容器特权运行能力的一些令人惊讶的变化。本报告还涵盖了允许容器以 root 用户身份运行、受映像漏洞影响的工作负载、过时的舵图、过时的容器映像和过时的 API 版本。

成本效率

当谈到 成本效率 时，似乎大多数组织在设置 CPU 请求和限制时都做得不错。很少有人将工作负载限制设置得过高，将这些限制设置得过低的人就更少了。在成本效率方面需要改进的地方包括更仔细地设置内存限制-许多人将内存限制设置得太高，30%的组织看到至少 50%的工作负载受到影响，从而浪费了大量的云资源。在某些情况下，相当多的人将内存限制设置得太低，这会降低集群的可靠性，并可能导致应用程序失败。该报告还强调了内存请求设置过低或过高的地方，有多少工作负载受到影响，以及如何将这些请求调整到合适的大小。

Kubernetes 基准测试报告的关键要点

容器和 Kubernetes 技术可以为企业带来巨大的价值，但是如果不了解这些基本配置以及如何适当地设置它们，就很难驾驭 Kubernetes 固有的复杂性。该报告有助于您更好地了解您的集群缺陷，在哪里进行投资，以及如何配置 Kubernetes 以产生积极的业务影响。通过查看这些数据，您可以了解并做出调整，以改进您的 Kubernetes 部署，并确保您的应用程序和服务在未来一年尽可能可靠、安全和经济高效。

阅读 完整的 Kubernetes 基准报告 今天。

Kubernetes 的 22 个基本概念

原文：https://www.fairwinds.com/blog/22-essential-kubernetes-concepts

原生云代表了基础架构部署方式的一种范式转变。如果你是云原生和 Kubernetes 的新手，你需要掌握 22 个基本的 Kubernetes 概念。

工作量

1. 节点-节点可以是虚拟机或物理机，具体取决于群集。每个节点都包含运行 pod 所需的服务，由控制平面管理。
2. 集群——集群是基础。所有容器化的应用程序都运行在集群之上。
3. Pod -工作的基本单位。Pods 是可以在 Kubernetes 中创建和管理的最小可部署计算单元。吊舱几乎从来不会自己被创造出来，相反，吊舱控制器做所有真正的工作。
4. 名称空间——Kubernetes 支持由同一个物理集群支持的多个虚拟集群。这些虚拟集群被称为名称空间。名称空间适用于许多用户分布在多个团队或项目中的环境。

Pod 控制器

5. 部署-在 Kubernetes 上获取应用的最常见方式。为每个部署规范创建一个副本集。
6. 复制集-创建一个稳定的豆荚。你几乎不会直接创建它。
7. daemon set-daemon set 确保所有(或一些)节点运行一个 Pod 的副本。随着节点添加到集群中，单元也会添加到其中。随着节点从集群中移除，这些 pod 将被垃圾收集。删除 DaemonSet 将清理它创建的 pod。常见于 CNI、监控代理、代理等系统进程。
8. StatefulSet - StatefulSet 是用于管理具有持久存储的有状态应用程序的工作负载 API 对象。Pod 名称是永久性的，在重新计划时会保留(app-0、app-1)。与部署不同，pod 有 DNS 名称。与替换吊舱相关的存储停留。删除 pod 后，卷会持续存在。pod 是按顺序单独部署/更新的。
9. horizontalpod auto scaler-Horizontal Pod auto scaler 根据 CPU 利用率等标准指标或请求延迟等自定义指标，自动扩展复制控制器、部署、副本集或有状态集中的 Pod 数量。
10. pod disruption budget——限制升级和其他计划事件期间被中断的 pod 数量的能力，允许更高的可用性，同时允许集群管理员管理集群节点。
11. 作业-作业创建一个或多个 pod，并期望它们成功终止。
12. 按计划创建作业。

配置

13. config maps——一个 API 对象，用于存储键值对中的非机密数据。
14. secrets——允许您存储和管理敏感信息，如密码、OAuth 令牌和 ssh 密钥。

建立工作关系网

15. ingress——一个 API 对象，管理对集群中服务的外部访问，通常是 HTTP。Ingress 可以提供负载平衡、SSL 终止和基于名称的虚拟主机。
16. 服务——将运行在一组 pod 上的应用程序公开为网络服务的抽象方式。
17. 网络策略——一种规范，说明允许多组 pod 如何相互通信以及如何与其他网络端点通信。

安全- RBAC

18. ServiceAccount -为在 Pod 中运行的进程提供标识。
19. 角色-角色是特定名称空间内的一组权限；创建角色时，必须指定它所属的名称空间。
20. ClusterRole - ClusterRole 与角色完全相同，只是它是一个没有命名空间的资源。资源具有不同的名称(Role 和 ClusterRole ),因为 Kubernetes 对象总是必须有命名空间或没有命名空间；不可能两者兼得。
21. Role binding——将角色中定义的权限授予某组用户或服务帐户。它包含一个主题列表(用户、组或服务帐户)，以及对被授予的角色的引用。RoleBinding 授予特定命名空间内的权限。
22. ClusterRoleBinding -授予集群范围的访问权限。

了解更多关于 Kubernetes 架构基础知识 。

一些定义来源于 kubernetes.io 。

永远不要在 Kubernetes 第 4 部分:三个 K8s 效率错误

原文：https://www.fairwinds.com/blog/3-kubernetes-efficiency-mistakes

正如我们在这个系列的第一篇文章中所概述的，有些事情你绝对不应该在 Kubernetes 上做。duck bill Group 的首席云经济学家 Corey Quinn 与 Fairwinds 的总裁 Kendall Miller 和 Fairwinds 的高级站点可靠性工程师 Stevie Caldwell 进行了一次生动的对话，讨论了开发和运营团队如果想从领先的容器编制器中获得最大收益，就不应该在 Kubernetes 中做的一些事情。如果你想最大限度地提高 Kubernetes 的效率，以下是你需要注意的。

(请记住，这是绝对不应该的，所以标题可能看起来有点奇怪，有点明显，甚至令人惊讶！)

1.将工作负载放在德克萨斯大小的房子里

这个 K8s 效率错误和下一个确实密切相关，当将工作负载放在“德克萨斯州大小的房子”中时，它真正归结为爆炸半径，即如果(或当)出现问题时，您正在运行的东西会受到多大影响。如果有几个大型工作负载正在运行，其中一个出现故障，很多事情都会受到影响。因此，虽然您可以将工作负载放在巨大的“房子”中，但您也需要让工作负载意识到这些事情。换句话说，了解如果您的工作负载下降，将会影响什么。另外，不要忘记考虑如果一切都不顺利，需要什么才能让一切恢复正常运行。

当人们在 Kubernetes 上部署工作负载时，他们最头疼的事情之一就是了解他们的应用程序需要什么。决定哪种节点或实例类型最适合它们正在运行的内容是一项挑战，知道发出哪种资源请求以及将哪些资源分配给它们的应用程序也是一项挑战。很多人一开始就分配过多，然后集群中的节点比需要的更多或更大。Kubernetes 根据您的请求来调度您的工作负载，因此，如果您请求 200 毫 core，而您只使用了 8 个，则不会调度任何与此相冲突的其他任务，并且您将拥有远远超过您的应用所需的扩展空间。在这种情况下，您可能能够有效地运行您的应用程序，但是您将失去 Kubernetes 部署的效率。

2.将工作负载放在一个小房子里。

我们经常建议，在您学习和开始使用 Kubernetes 时，从小处着手是一种很好的开发实践。一开始，在受限制的环境中开始构建东西是有意义的，如果需要，您可以随时扩展。重要的是要记住，这是一个拐杖，你应该只需要当你开始；你最终会耗尽这个计划的成长空间。

不过，请记住，从小处着手和将明显需要更多计算能力的东西放在尽可能小的空间中是有区别的。如果你这样做，它将一直以 100%的 CPU 运行，但仍然不会工作。虽然没有一种尺寸适合您要做的所有事情，但您不会因为将工作负载放在无法有效工作的地方而节省资金或感到沮丧。

不要使用太大的房子，否则你会牺牲效率(和$$)也不要使用太小的房子，否则你会过度利用一个节点，由于资源匮乏而导致一连串的故障。

3.忽略自动缩放

有很多人在使用云，使用像 Kubernetes 这样的云原生技术，这使得像扩展这样的事情变得容易。然而，它们不是自动缩放的。这是云计算最大的承诺之一。不要移动到 Kubernetes 并关闭自动缩放。它真的很擅长自动缩放，这是你在使用 Kubernetes 时应该利用的。

人们往往对实现自动扩展非常感兴趣，这很重要，因为当资源需求激增时，它可以让您的应用程序保持在线。不幸的是，人们总是忘记弄清楚如何明智地缩减规模，因为失败的模式就是多花一点钱。然而，在过去的一年中，许多环境的用户流量直线下降，而基础架构成本却保持直线上升。为什么？因为他们从未真正测试过缩小规模，所以没有发生。不要忽略自动缩放，但是也要花时间确保如果有一半的节点消失，您的环境不会爆炸。自动缩放当然可以提高你的效率，所以花时间去实现和测试它，永远不要忽视它。

观看完全娱乐性的点播网上研讨会了解在 Kubernetes 上你还应该做些什么。

每个运营团队都需要 3 个 Kubernetes 护栏

原文：https://www.fairwinds.com/blog/3-kubernetes-guardrails-every-team-needs

在真正的 DevOps 环境中，运营和开发人员共同负责 Kubernetes 环境。运营部门确保核心平台平稳运行，而开发部门负责打包他们的应用程序并将其发送到集群中。

假设运营团队是一个经验丰富的 Kubernetes 工程师团队，那么构建一个安全、高效、可靠的集群并不难。但是一旦您让开发人员与集群进行交互，事情就会变得非常棘手。开发人员通常希望专注于代码和特性，并因此得到回报。基础设施往往是事后才想到的——他们只是想“让它运转起来”

这取决于运营团队将正确的Kubernetes****guardrails放置到位，以引导他们的开发团队走向最佳实践和策略遵从。这不仅防止了安全漏洞和重大停机等关键问题；它还帮助开发团队更快、更自信地交付，知道他们的更改在进入生产之前会被检查是否有问题。

让我们来看看三个主要的 guardrails Ops 团队应该整合到一起，以帮助开发团队在面向 DevOps 的 Kubernetes 环境中取得成功。

RBAC

任何 DevOps 驱动的组织应该实现的第一个护栏是基于角色的访问控制，或 RBAC。RBAC 确切地决定了在您的环境中允许每个用户或进程采取什么操作。

至少，您的组织应该针对不同的角色使用三种独特的角色:

• 集群管理员——这是最高级别的权限，可以对集群进行任何更改。这个角色应该只对少数关键人物开放，并且只在“打碎玻璃”的紧急情况下使用。
• Ops Engineer -该角色应该有广泛的权限来修改集群，而没有什么限制。为了完成他们的工作，操作工程师需要一个在其他人手中可能是危险的访问级别。但是，您可能想要削减权限，比如create pods/exec或get secrets
• 开发者——这个角色应该有最低限度的权限。它通常是一个只读角色，允许开发人员查看其工作负载的日志和状态。角色也可以绑定到特定的名称空间，这样一个开发人员就不能查看另一个团队的日志。

此外，您应该创建一个“应用程序部署”角色，该角色可以在持续部署流程中使用。这将需要比开发人员角色更多的权限(因为它必须进行修改)，但可以被限制做类似修改kube-system名称空间的事情。

RBAC 是实施护栏的良好开端。如果做得好，它可以成功地控制非专家(甚至是疲惫的专家)的一些诚实错误的爆炸半径！)可能会使。但这还不够，开发人员仍然可以自由支配他们的名称空间，并且可以很容易地错误配置他们的工作负载，从而造成安全漏洞、大量资源浪费或非常不可靠的应用程序。

政策

运营团队必须设置防护栏，以确保所有应用程序工作负载都得到正确配置。Kubernetes 提供了很多方法来调整应用程序的安全配置文件、资源使用和弹性，缺省值通常是不够的。

例如，默认情况下，每个工作负载都允许作为根用户运行。在容器化的环境中，这看起来可能是安全的，但是在某些情况下，攻击者能够逃离容器并访问主机。如果容器以根用户身份运行，攻击者就可以以根用户身份访问主机节点，从而造成严重破坏。确保所有应用程序以非 root 用户身份运行是缩小攻击面的一种简单方法。

类似地，Kubernetes 将很乐意允许您部署一个没有内存和 CPU 设置或者没有健康探测的工作负载。但是，如果您想要零停机部署和合理的自动伸缩行为，就必须设置这些选项。

对于面向用户的应用程序，您的组织至少应该实施以下策略:

• 指定内存和 CPU 设置(请求和限制)

• 指定活动和就绪探测器

• 加强安全性:

• 不允许以 root 用户身份运行、以特权身份运行和特权提升

• 不要添加任何额外的 Linux 功能

• 不要设置主机 IPC、主机 PID 或主机网络

您可能还需要一些额外的实施策略，如:

• 具体的标记方案(例如，确保每个工作负载都有一个costCenterCode)
• 放弃所有默认的 Linux 功能
• 确保所有工作负载都有横向 Pod 自动扩展和 Pod 中断预算
• 剔除具有已知 CVE 的容器

这些策略应该作为准入控制器来执行。这将扫描对 Kubernetes 集群的所有修改，并拒绝任何违反策略的修改。您可能还想让运营团队在某些情况下有所例外。

基础设施代码扫描

有一个准入控制器是一个很好的开始，但是很快你会发现开发团队抱怨这降低了他们的速度。这与我们想要的好的 Kubernetes 护栏正好相反！

问题是，开发人员只有在将他们的更改合并到他们的基础设施即代码(IaC)存储库的主要分支之后，才能从准入控制器获得反馈。这意味着，如果出现问题，他们将不得不返回，进行更多的更改，然后再试一次。这个循环会很慢，很累。

相反，作为持续集成(CI)过程的一部分，在准入控制器中实施的相同策略也应该在基础设施即代码上实施。这样，开发人员无论何时发出拉请求，都会得到反馈，在变更合并到主分支之前*。开发人员可以快速修复其分支的任何问题，并自信地合并，因为他们知道如果 CI 管道通过，准入控制器将接受部署。*

幸运的是，许多开源和商业 Kubernetes 策略工具在这方面做得很好。特别是，Fairwinds 开源项目 Polaris 能够针对基础设施即代码文件以及准入控制器运行其策略(内置和自定义策略)。一些口味的 OPA 也能做到这一点。

Kubernetes 护栏助您安全快速移动

对于任何运营 Kubernetes 的组织来说，合适的护栏都是必不可少的。有了正确的 RBAC、准入策略和 IaC 扫描,开发团队可以更快地交付，而运营团队可以确保他们的集群保持安全、高效和可靠。

如果您希望在您的组织中实施 Kubernetes guardrails，请查看 Fairwinds Insights 。它附带了 100 多种内置策略(外加 OPA 和 Polaris 自定义策略),可以在整个开发生命周期中强制执行，它们可以在 IaC 上运行，在准入控制中运行，或者按计划扫描您的实时环境。策略甚至可以定制，并限定于特定的集群、命名空间、标签等。

借助 Fairwinds Insights ，在一个平台中为 免费获取 Kubernetes 安全性、成本分配和规避、合规性和护栏。

无论您是使用开源解决方案还是与商业合作伙伴合作，为您的 Kubernetes 环境设置防护栏都将有助于您的开发人员快速、自信地发布产品。

我学到的关于可转换标签的 3 件事(艰难的方式)

原文：https://www.fairwinds.com/blog/3-things-ive-learned-about-ansible-the-hard-way

Ansible 标记的简单要求使它非常容易上手。总的来说，它工作得非常好，但是一旦你深入一点，有些事情可能会导致不适。以下是我艰难地了解到的关于(或重新了解)的三件事。

标签并不像你预期的那么远

可变标签 是一种限制工作量的有效方法。一般来说，行动手册将贯穿始终，因为您使它们幂等，但有时只针对非常具体的部分也不错。毕竟，当您只是想改变 Nginx 中的设置时，为什么要运行所有与数据库相关的任务呢？

很明显，ansible 标签对于简化工作非常有用，但是它们有一个非常明显的限制。一旦播放器匹配一个标签，它也将运行作为该播放器一部分的每个任务，而不管其他标签。

让我们看一个例子。以下是一个非常简单的顶级玩法:

- include: sub.yml
  tags: top 

那个文件包括下面的 sub.yml:

- hosts: localhost

  tasks:
    - debug: msg="sub and top"
      tags: sub,top

    - debug: msg="sub"
      tags: sub

    - debug: msg="blank" 

运行 ansible-playbook 而没有任何 --tags 产生所有的调试消息(这应该很明显，因为 Ansible 的默认是 --tags all)。运行ansible-playbook``--tags top也会产生所有的输出:

$ ansible-playbook --tags top ./top.yml

PLAY [localhost] ***************************************************************

TASK [setup] *******************************************************************
ok: [localhost]

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "sub and top"
}

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "sub"
}

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "blank"
}

PLAY RECAP *********************************************************************
localhost                  : ok=4    changed=0    unreachable=0    failed=0 

该信息在文档中有所提及，尽管它并没有详细说明这一点:

所有这些都将指定的标签应用到剧本、包含的文件或角色中的每个任务，以便当剧本被相应的标签调用时，这些任务可以选择性地运行

因此，如果您希望在包含的游戏中使用 ansible 标记来继续隔离事物，您将会失望。

通过添加 --skip-tags，可以进一步限制执行时发生的情况:

$ ansible-playbook --tags top --skip-tags sub ./top.yml

PLAY [localhost] ***************************************************************

TASK [setup] *******************************************************************
ok: [localhost]

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "blank"
}

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=0 

在这种情况下，模糊的第一个任务在 sub.yml 中匹配而不匹配。效果是它不运行。

最后，如果跳过顶层，什么都不会发生:

$ ansible-playbook --tags sub --skip-tags top ./top.yml                                 

PLAY [localhost] ***************************************************************

PLAY RECAP ********************************************************************* 

--tags还有很多动力，但是我知道我花了太多时间去弄清楚为什么有些东西会运行或者不运行。根据经验，我尝试将 ansible 标记与 role 和 include 语句一起使用。如果事情需要敏感对待，我一般会设置一个布尔变量，默认为 false或者 no 而不是让事情偶然发生。

除非你踩在上面，否则杂凑就是杂凑

由于 replace(默认)或 merge的散列合并行为，在 Ansible 中使用散列可能会很棘手。

这意味着什么呢？让我们举个例子:

mj:
    name: M Jay
    job: hash merger
    skill: intrepid 

假设我们想要通过向 mj添加另一个位来增加散列:

mj:
  eye_color: blue 

使用 replace的默认行为，您最终将只有 mj的眼睛颜色。在 ansible.cfg 中设置 hash_behaviour = merge 会得到一个散列，它拥有 mj的所有属性。

现在，覆盖配置文件中的设置的问题是，它可能会反咬你一口。如果该文件被篡改或在另一个系统上运行，等等。，你可能会得到一些非常奇怪的效果。Ansible 2 中的变通方法是使用 combine 过滤器来显式合并。

这个题目上的 文献 都不错。对于上面的例子，它看起来像这样:

- hosts: localhost

  vars:
    var1:
      mj:
        name: M Jay
        job: hash merger
        skill: intrepid
    var2:
      mj:
        eye_color: blue

  tasks:
    - debug: var=var1
    - debug: var=var2
    - set_fact:
      combined_var: "{ { var1 \ combine(var2, recursive=True) } }"
    - debug: var=combined_var 

您将得到以下结果:

$ ansible-playbook hash.yml                                                              

PLAY [localhost] ***************************************************************

TASK [setup] *******************************************************************
ok: [localhost]

TASK [debug] *******************************************************************
ok: [localhost] => {
    "var1": {
        "mj": {
            "job": "hash merger",
            "name": "M Jay",
            "skill": "intrepid"
        }
    }
}

TASK [debug] *******************************************************************
ok: [localhost] => {
    "var2": {
        "mj": {
            "eye_color": "blue"
        }
    }
}

TASK [set_fact] ****************************************************************
ok: [localhost]

TASK [debug] *******************************************************************
ok: [localhost] => {
    "combined_var": {
        "mj": {
            "eye_color": "blue",
            "job": "hash merger",
            "name": "M Jay",
            "skill": "intrepid"
        }
    }
}

PLAY RECAP *********************************************************************
localhost                  : ok=5    changed=0    unreachable=0    failed=0 

还是那句话，我的建议:不要改变默认，要学会热爱 combine 滤镜。

set_fact 很粘

Ansible 中设置变量的方式有多种: include_vars， vars:，将它们作为 play 的一部分传递，当然还有 set_fact。需要意识到的是，一旦你使用 set_fact 来设置一个变量，你就不能改变它，除非你再次使用 set_fact 。我认为从技术上来说事实优先更正确，但效果是一样的。举以下例子:

# note that the included play only contains a debug
# statement like the others listed in the example below.

- hosts: localhost

  vars:
    var1: foo

  tasks:
    # produces foo (defined in vars above)
    - debug: msg="original value is "

    # also produces foo
    - include: var_sub.yml

    # produces bar (since it's being passed in)
    - include: var_sub.yml var1=bar

    # produces foo (we're back to the original scope)
    - debug: msg="value after passing to include is "

    # now it get's interesting
    - set_fact:
        var1: baz

    # produces baz
    - debug: msg="value after set_fact is "

    # also produces baz
    - include: var_sub.yml

    # baz again!!! since set_fact carries the precedence
    - include: var_sub.yml var1=bar

    # using set_fact we can change the value
    - set_fact:
        var1: bat

    # the rest all produce bat
    - debug: msg="value after set_fact is "
    - include: var_sub.yml
    - include: var_sub.yml var1=bar 

寓意是，当你看到一些奇怪的行为时，运行 -vvv 或添加 debug 任务是一个好主意。

新事物:将角色作为任务运行！

我很兴奋地得知，有了 Ansible 版，将角色作为任务运行成为可能。这听起来可能不多，但它非常强大，可以节省我以前编写和/或复制的许多奇怪的代码。

魔咒是 包含 _ 角色。

这个新特性非常强大，允许您编写更小的角色，以便于包含。例如，您可以轻松创建一个角色来管理您的数据库表或 Elasticsearch 索引。我遇到过一些用例。有了这个新的重头戏，现在可以做这样的事情:

- include_role: create-db
  with_items:
    - 'test1'
    - 'tester'
    - 'monkey'
    - 'production' 

它太强大了，我简直不敢相信它很久以前就不存在了。

现在，要是我能在 block s 上循环就好了…

关于 FinOps 和 Kubernetes 的 3 件事

原文：https://www.fairwinds.com/blog/3-things-to-know-about-finops-and-kubernetes

最近我参加了 FinOps 基础培训 并获得认证。如果你想拓展你的 FinOps 知识，我强烈推荐你。培训内容广泛，涵盖了 FinOps 框架和原则、利益相关者以及成熟度的不同阶段——通知、优化和运营。

在 Fairwinds，我们专注于容器和 Kubernetes 配置，并通过治理平台支持该技术，包括确保 K8s 得到优化以避免不必要的云成本。在我接受培训时，有三件关于 Kubernetes 的事情让我印象深刻。

1.优化到只使用你需要的东西比听起来要难

云使用优化是 FinOps 基金会概述的核心领域之一。它说，“组织确定并采取行动，将运行的云资源与任何给定时间运行的工作负载的实际需求相匹配…仅当我们需要它们产生业务价值时，才使用正确的资源，这是云的可变使用模式最终允许我们实现业务价值最大化的原因。”

Kubernetes 面临的一个挑战是如何预测并优化您的云支出，以确保您不会过度调配资源，或者在资源上过度支出。使用 Kubernetes，您需要调整应用程序 CPU 和内存的大小，并成功地进行扩展。用户需要为每个工作负载设置特定的资源请求和限制。通过合理和正确的限制和请求，可以最大限度地利用 CPU 和内存。对应用程序设置太低的限制会导致问题。例如，如果内存限制太低，Kubernetes 一定会因为违反其限制而终止应用程序。同时，如果设置过高，资源将被过度分配，导致更高的账单。

虽然 Kubernetes 的最佳实践规定应该一致地设置资源限制和对工作负载的请求，但没有工具，这只是猜测。团队经常根本不设置要求或限制，而其他团队在初始测试时将它们设置得太高，然后永远不会正确。确保扩展操作正常工作的关键是拨入每个 pod 上的资源限制和请求，以便工作负载高效运行。

在实现 FinOps 框架时，一定要考虑可以使用哪些工具来了解 CPU 和内存的使用情况。这将有助于告知(基金会模型的一个阶段)团队如何只使用需要的东西。

有两个工具需要注意: Goldilocks ，这是一个开源项目，它可以帮助适当规模的 Kubernetes 工作负载获得“刚刚好”的结果，还有fair winds Insights，这是一个成本优化工具，也是 FinOps 认证的。

2.把信息放在工程师的路径上

在 FinOps 基金会框架的 运营 阶段，它概述了“组织开始持续评估业务目标和他们针对这些目标所跟踪的指标，以及它们的趋势。”然而，这一阶段的成功取决于战略利益相关者的合作。您需要团队报告结果，讨论结果，并根据早期阶段做出明智的决策。

该培训的一个关键要点是“将信息放在工程师(和其他人)的路径上”，这一点真正引起了 Kubernetes 用户的共鸣:利用仪表盘，在他们工作的地方与他们见面(Slack、Confluence、JIRA、团队)，或者通过产品设计工具

这对于您希望团队采用的所有工具的成功是至关重要的，但是使用 Kubernetes，并不是所有的团队都能够在命令行中工作。您的团队将使用混合的工具来帮助他们“走得更快”——更快地编码和发布。当你在开发生命周期中遇到阻碍时，你会遇到阻力。对 FinOps 模型变得重要的信息需要随时可供所有利益相关者使用和理解。这就是为什么无论你采取什么样的策略，都要放在工程师的道路上，这一点非常重要。

在 Fairwinds，我们确保在fair winds Insights中提供的成本结果提供了避免浪费云资源的建议。这些建议被转化为 Insights 中的行动项目，但我们不会让工程师跳到仪表盘上采取行动。相反，我们通过与吉拉、Slack、Azure DevOps 等的集成来提供这些行动项目。它有助于在 Kubernetes 实现 FinOps 计划。

3.你需要合适的工具

拥有合适的工具来支持您采用 FinOps 是有意义的。有许多工具具有不同程度的功能和价位。该基金会表示，“找到合适的工具，让你以合适的详细程度获得你需要的数据，以达到你的成熟度水平，从而做出你需要做出的实时决策，这一点至关重要。”

对于团队来说，在 Kubernetes 中获得这些“正确的数据”可能是一件非常头疼的事情。首先，这是一个不断变化的短暂环境。你是如何衡量的？你怎么知道一个不再存在的容器用的是什么？当您开始您的 FinOps 之旅时，您是否需要这种程度的细节，或者您只是需要知道如何开始调整应用程序？

Goldilocks 是一款开源工具，可以帮助运营团队调整应用程序的规模，即“让它们恰到好处”这是你拥抱 FinOps 和使用 Kubernetes 的一个很好的跳板。随着集群和节点数量的增长，团队需要更多的数据来做出正确的决策。这就是像 Fairwinds Insights 这样的工具的用处。Insights 让 FinOps 采用过程中的所有利益相关者看到 Kubernetes 和容器消耗了多少资源。它提供了关于如何调整规模和节约成本的建议。此外，对于财务团队和开发团队来说，它很容易消化。这一点尤其重要，因为许多 FinOps 领导者，或者那些开始 FinOps 实践的人，并不总是知道该问 DevOps 团队什么问题。您需要合适的工具，虽然您需要云级别的工具，但随着您采用 cloud native/Kubernetes，您将需要一个工具来弥合 FinOps 和 DevOps 之间的差距。

Kubernetes 可以是 FinOps 的 黑洞，但不一定。通过使用正确的工具，在工程师的道路上，您可以优化您的云原生资源。Fairwinds Insights 可以帮助您采用 FinOps 和服务所有权模型，开发人员和运营团队可以优化成本并与财务部门合作。

如果您正在努力将 FinOps 模型应用到 Kubernetes，请联系我们。我们可以帮忙。

KubeCon EU 值得期待的 3 件事

原文：https://www.fairwinds.com/blog/3-things-to-look-forward-to-at-kubecon-eu

本周，云原生社区将自 2019 年巴塞罗那 KubeCon 以来，首次在西班牙巴伦西亚亲自聚集一堂。作为欧洲和北美许多 KubeCons 的与会者，我很高兴能再次与这个活跃的社区见面。

以下是我本周最期待的三件事:

1.云原生成熟度模型更新简介

2021 年启动的 Cartografos 工作组一直致力于更新云原生成熟度模型。该小组和成熟度模型的目的是为组织提供有效和实用的指导，帮助他们了解云原生生态系统。在周四的会议上，我很高兴与我的合作者和团队成员 Simon Forster、John Forman、Robert Glenn、Annalisa Gennaro、Jonathan Gershater 和 Marcello Testi 一起展示成熟度模型的最新更新。这包括关于业务成果的新部分，因此云原生成熟度模型的用户可以有效地将技术、流程、人员和策略部分映射到业务目标上。

2.社区，社区，社区

自巴塞罗那以来，一直缺少的一件事是有机会与云原生社区在一起，了解我们面临的挑战以及我们如何努力克服这些挑战。我很高兴能与业界建立联系，向云本地用户学习，并在 Fairwinds 付诸实践。

3.做点好事

我们已经与一些伟大的公司联手:buppy、 Civo 、蟑螂实验室、 Pulumi 和 Jetstack 以确保我们做一些好事。对于那些无法亲自参加 KubeCon EU 的人，该组织已经合作向世界中央厨房(WCK)的每个虚拟展位参观者捐赠 2 美元，这是一个致力于为人道主义危机提供膳食的非营利组织。你可以了解更多关于它是如何运作的，以及下面的每家公司。

此外，如果您亲临 Fairwinds 展台，我们还将向世界中央厨房捐赠€2。该组织在乌克兰每天提供近 30 万份膳食。

期待一些精彩的演讲、解决方案展示等！请务必参观 Fairwinds 展台和 Cartografos 工作组，做一些有益的事情，了解云原生成熟度模型和 Kubernetes 治理。

---

好伙伴:如何运作

参与很容易。如果您注册了 KubeCon，只需点击下面的展位链接即可访问我们的虚拟展位。每次访问将算作 2 美元的捐赠，所以如果你访问我们所有人，那就是 12 美元的原因！

当然，参观我们的展位还有很多原因。您会发现大量优秀的云原生资源，包括演示、教程、电子书等等。以下是每个展位的一些亮点。

浮力 Linkerd 的创造者

Buoyant 宣布了一件令人兴奋的事情:引入完全管理的 Linkerd。您可以是第一批查看演示的人之一，并且您还会发现大量的服务网格内容，包括英语和西班牙语的服务网格 101、我们的 mTLS 工程师指南以及关于浮力服务网格学院的详细信息。更多信息，请访问漂浮展台！

Civo —快速、简单、可管理的 Kubernetes

顺便参观一下 Civo 展台，参加关于如何充分利用 Kubernetes 环境的现场会议——包括演示、Civo 市场漫游和深入了解他们如何生活——提供私人区域。你会发现大量的资源和友好的团队成员来回答任何关于 Civo 易于使用的托管 Kubernetes 服务的问题。这是完全 CNCF 认证和 100% Kubernetes 上游兼容。今天来看看 Civo 展台！

蟑螂实验室——建造你梦想的东西

cockoroach db 今年出现在 KubeCon 上，无论是实体的还是虚拟的，主要是慈善性质的。(如果您亲自参加，请务必参观 P16 号展位，在那里，每扫描一个徽章，他们将向黑人女孩代码、女性代码、癌症研究所或联合国儿童基金会乌克兰救济会捐赠 3 美元)。参观他们的展位(或在此预定会议)观看演示和架构概述，了解他们从在 Kubernetes 上构建多区域、托管、分布式 SQL 数据库产品中学到了什么。现在就来看看吧。

Fairwinds — Kubernetes 治理和安全性

Kubernetes 治理领域的领导者 Fairwinds 提供了开发、安全和运营部门之间的统一视图，在他们的虚拟展台 KubeCon 上提供了大量的资源。您可以快速浏览 Fairwinds Insights，了解 Kubernetes 的成本节约、如何实现 Kubernetes 服务所有权、典型的 Kubernetes 安全错误等等。来和一位友好的 Fairwinds 工程师聊天，谈论许多伟大的开源解决方案，包括 Polaris、Goldilocks、Nova 和 Pluto。今天参观 Fairwinds 展台！

pulumi——作为代码的通用基础设施

在 Pulumi 的展台，您将了解他们的云工程平台，该平台通过统一的软件工程流程将基础设施、开发人员和安全团队聚集在一起，降低云复杂性并加速创新。不要错过 Pulumi 的“询问专家”实时会议，直接听取工程团队的意见。无论您是想了解更多关于如何使用通用基础设施作为通用编程和标记语言的代码进行构建，还是只是想了解更多关于路线图的内容，这都是您提问的机会。今天就去参观普鲁米吧！

jet stack——证书管理器的创造者

充分利用 cert-manager，了解 Jetstack Secure 如何消除工作负载错误配置，并提供每个生产集群中每个证书的完整可见性。直接与项目维护人员聊天，学习使用 cert-manager 来保护使用 mTLS 的入口端点和内部工作负载。今天就来看看 Jetstack 展台！

工程领导者启动 FinOps 计划的 3 种方法

原文：https://www.fairwinds.com/blog/3-ways-for-engineering-leaders-to-kickstart-finops

作为一名工程主管，你需要和你的首席财务官成为好朋友。正是这种合作关系让你对业务有了深入的了解，并让你的首席财务官对你的领域战略和决策的驱动因素有了一个看法。

你的首席财务官想要一件事——一个成功的企业。成功看起来像很多事情，学习如何说对方的语言和伙伴是决策的基础，这是战略性的，前瞻性的，是什么让你从一个好的工程领导者变成一个好的领导者。

FinOps 润滑那些轮子。It 鼓励要求伙伴关系、透明度、沟通和责任。它位于人员、流程和技术的中心——这是每一个进入您的 DMs 系统的云顾问的口头禅，以帮助您加速云原生之旅。

要成为一名可靠的 FinOps 领导者，你需要考虑三件大事:

1. 有用和无用的数据

2. 问责文化

3. 行动偏好

1.有用和无用的数据

FinOps 的核心之一是单位测量。只有当您测量正确的单位时，了解单位成本才有价值。

您可以衡量每个客户的成本、每个 Kubernetes 集群的成本、每个收入美元的成本、每个 xxx 的成本。这些都是有趣的单位成本，但并不是所有的都有价值。

我喜欢好的电子表格。它之所以好，部分是因为知道什么时候扔掉一个标签或图表，因为虽然它可能很漂亮，并显示一条线向上和向右(或在成本效率的情况下向下和向右),但非常好。

如何开始:

1. 打开您的云账单，通过几个不同的参数(账户、类型等)获取成本数据

2. 从你的 BFF CFO 那里获取一些业务层面的数据(收入、客户数量、集群数量等)。

3. 如果你正在使用 Fairwinds Insights 来衡量 Kubernetes 的成本，在效率选项卡下获取一些信息。

4. 搞得一团糟——快速而肮脏地解决——计算一下单位成本。你不是在寻找完美，而是在寻找一个信号。

5. 突出那些看起来有价值的事情，并写下原因。如果你不能很快向自己解释为什么这个指标是有价值的…它可能不是。迭代。扔掉垃圾。

6. 基准。最初的几次迭代将会令人困惑，很可能是错误的。但是那里会有一些金块，你可能会想回来拿。保留一个时间点副本，以供将来继续迭代时参考。

7. 继续走。

2.问责文化

在企业组织甚至小型创业公司中可以发展的筒仓需要被粉碎。我们都对企业负责——为了做到这一点，需要清晰和透明。

组织中的每个人都应该了解各个部分是如何组合在一起的。当然，上下文有层次和深度——不是每个人都需要每个决策或行项目的所有细节。但是每个人都应该理解决策背后的商业策略和相关的影响。

构建一个新的环境可能会加速团队的发展，但这是有代价的。每个工程师都应该理解他们决策的成本(和节约)。您的首席财务官或财务合作伙伴需要了解规模经济、推出新功能的速度，或者更广泛的云足迹可以提供的另一个 x 因素。

这让我们回到单位成本——我们的决策如何影响单位成本？只是有这种想法会增加责任感。

3.行动偏好

分散的权力和集中的策略让你保持敏捷(它有很多其他有价值的成果——特别是与领导力发展相关的——但那是另一篇文章)。将决策推到边缘，集中战略，并创建一个框架来确保整个业务的一致性。与过去的长周期采购和财务审批相比，您的云账单能够在瞬间激增，因此能够快速、严格、自主地做出决定(开始和停止)至关重要。

确保你正在观察和衡量正确的事情，并且当事情不正常时有权迅速采取行动——这是最佳时机。你很可能不会出现在门外。继续走。

FinOps 是一种实践，一种伙伴关系。它将推动您的组织走向成熟和发展，并为您提供一个框架，鼓励采用一种精益、灵活和负责任的方法来实现您的业务与云的融合。

如果你想知道 Fairwinds Insights 如何帮助你进行 FinOps 练习:

4 Kubernetes 年的决心:转型的一年

原文：https://www.fairwinds.com/blog/4-kubernetes-resolution-for-2021

我们在 Fairwinds 的团队，包括 Bill Ledingham，Kendall Miller，Andy Suderman，Joe Pelletier 和 Robert Brennan，对我们在 2021 年可以期待的事情做出了的预测。在各种预测中，我们认为，2021 年，公司必须进行数字化转型，以满足客户的需求。云原生技术和 Kubernetes 将继续成为所有组织进行基础设施数字化转型的必要工具。

2021 年特别重要的一个领域是 Kubernetes 的安全和政策执行。不幸的是，我们迟早会看到一家大型企业中被忽视的 Kubernetes 集群导致引人注目的安全漏洞。这就要求企业实现 Kubernetes 策略执行工具，围绕安全性、效率和可靠性为集群构建防护栏。这对于多集群和多租户环境尤为重要。

展望 2021 年，我们不仅想预测 Kubernetes 生态系统将如何变化，还想为工程师、工程领导者和开发者提供一些解决方案。这里有四个决议:

解决方案 1:实施策略以防止安全漏洞

就在上个月，发现了一个新的中等严重度 CVE(CVE-2020-8554)，影响多租户 Kubernetes 星团。不幸的是，在 Kubernetes 的世界里，CVEs 将会增加。解决方案 1 是实施策略，以便在宣布 CVE 时，您可以快速创建策略来确定您是否受到影响，修补漏洞，然后防止它再次进入您的集群。在 2021 年花时间识别和选择 策略执行工具 来帮助你抵御安全漏洞。

决心 2:停止浪费金钱

这个解决方案看起来很容易，但不幸的是，我们看到了很多浪费在资源上的钱，因为用户没有指定 CPU 或内存限制，或者过度配置资源。

25%的 Kubernetes 用户未能指定 CPU 或内存限制，15%的用户过度配置资源。
来源:Fairwinds Insights

适当设置限制以避免过度配置资源可以为您的企业节省资金。它还可以帮助增加您的吊舱的可靠性。问问你自己——你的所有集群都有限制吗？它们是正确的极限吗？考虑 验证您的集群配置 以节省您团队的资金。

解决方案 3:建立 Kubernetes 配置的内部标准

Kubernetes 的一个负面后果是配置漂移，导致复杂性和运营成本增加。随着组织越过 Kubernetes 的 PoC 阶段，他们可能会忽略为 Kube 配置建立内部标准，或者发现自己经常更新这些指南。这可能导致“Kubernetes 蔓延”，使许多容器和 Kubernetes 资源无人管理。组织可能会招致技术债务和复杂性。这增加了升级和修补的成本，使组织暴露于安全漏洞的时间更长，并影响上市时间。解决方案三不是简单地定义，而是强制实施您的 配置最佳实践 和所有集群的合规性规则。

解决方案 4:了解您的集群中发生了什么

不幸的是，随着 Kubernetes 的扩张，你并不总是能看到发生了什么。没有可见性，运营团队就无法查明错误。通过投资 集中式平台 获得可见性，用于运行多个开源工具，提供对安全性、效率和可靠性配置的可见性。

可实现的 Kubernetes 分辨率

与我们可能亲自为自己设定的一些解决方案不同，这些解决方案很容易实现，可以帮助您运行安全、可靠且经济高效的 Kubernetes 应用程序。

根据我们在 Kubernetes SOC 2 合规性方面的经验总结出的 4 条建议

原文：https://www.fairwinds.com/blog/4-tips-from-our-experience-with-kubernetes-soc-2-compliance

如果您在运营或安全领域工作，您可能听说过 SOC 2 合规性，也称为服务组织控制。这套针对第三方服务提供商的合规性要求和审计流程旨在帮助企业确定他们是否可以安全地管理客户的利益和隐私。

虽然在理想的世界中，SOC 2 的旅程应该是无缝的，但事实是对许多企业来说这是一个艰难的过程。从了解您的组织是否需要 SOC 2 到实现这一目标所需的路线图，实现这一自愿级别的合规性就是通过安全性、可用性、保密性、隐私性和处理完整性这五个信任服务类别来管理客户数据。然后，公司可以使用 SOC 2 报告向内部和外部利益相关方证明，他们正在根据最佳实践保护数据。

大多数寻求 SaaS 解决方案的安全意识组织，如我们为 Kubernetes 用户提供的治理和安全软件 Fairwinds Insights，都将 SOC 2 合规性视为最低要求。但是许多提供商并不确定如何实现这些法规遵从性要求，因为它们本质上是模糊的。幸运的是，Fairwinds 已经开始了 SOC 2 合规之旅，我们很高兴分享我们在为客户实现这一里程碑时学到的前四件事。尽管有些人认为 SOC 2 合规性只适用于安全性和运营，但我们发现这是整个公司的努力！

时间上短？观看我们关于该主题的免费网络研讨会！

SOC 2 的世卫组织和原因

处于成长阶段的公司、大中型公司以及快速成长的小型企业都要经历 SOC 2 合规的痛苦。这些强大的报告可用于帮助处理和存储客户数据的软件公司推动和赢得新业务。虽然安全主题仍然是 SOC 2 的重中之重，但评估内部控制的能力以及影响客户信任的因素对成功至关重要。

我们的合规之旅始于 SOC 2 Type 1。这一步只是从设计的角度评估所有与组织相关的控制措施，确保它们得到正确实施。为了让我们开始，我们与 Kintent 的 信任云 合作，它自动生成与我们的业务相关的控制、测试和政策。在 SOC 2 类型 1 分析的这一阶段之后，我们进入了类型 2，这是一个为期六个月的阶段，专门用于监控这些流程并确保它们得到正确遵循。

在这个过程中，我们意识到即使 Kubernetes 是一个较新的架构范例，它实际上在 SOC 2 中也有一些考虑。通过这次练习，我们现在了解了如何帮助我们的客户认识到在 SOC 2 的范围内 Kubernetes 的哪些部分与他们的组织相关。此外，我们正在努力确定 Fairwinds Insights 如何帮助客户确定他们自己的关键标准。

SOC 2 的 4 大技巧

如果你问大多数经历过 SOC 2 合规流程的组织，他们可能都会告诉你同样的事情——我希望有人在我开始之前给我一些提示！本着这种精神，以下是我们 Fairwinds 希望事先知道的四件事，以及我们在经历更大的过程时学到的东西:

1。看看你的系统和你用的东西。 像 Fairwinds 一样，你可能是一个构建软件的初创公司，可能使用几十个供应商，像 GitHub 或 VCS 的 GitLab。您可能有运行您的页面的东西，并且您可能有一个 HR 系统或文档知识库。您的组织中可能有人拥有这些系统中的每一个——可能是公司中的几个不同的人。

首先要做的是创建一份您使用的所有系统以及在这些系统中拥有责任和/或管理员权限的人员的列表。这个小组可以被认为是您最初的“法规遵从性团队”，即使它是组织中的每个人。如果必要的话，现在是整合的时候了，根据职责对系统进行分组，并检查谁在何时做什么。这项工作包括对您的所有系统以及其中的内容进行分类。这些系统里都是什么样的数据？保密程度如何？您如何保存客户数据并对这些不同的类别进行分类？

2。确立你的最佳实践并坚持下去 **。**证明你不仅遵循了这些政策，而且为它们制定了流程。当然，在您的架构和系统管理中，您可能已经坚持了最佳实践，但是您可能没有在所有地方都这样做。可能存在您没有意识到的安全漏洞，或者您忘记了要做的事情。从始至终遵循这些实践，并跟踪哪些是有效的，哪些是无效的。

其中一些步骤需要时间，比如身份验证或单点登录。确保所有可能的东西都与您的单点登录集成在一起，无论是 Google SAML 身份验证还是 Okta 这样的身份提供商。确保您在第一步中确定的所有系统都尽可能地连接到该系统。在这个阶段，我们专注于验证和确定各种实践，比如加密我们所有的数据存储。因此，当建立 RDS 实例或类似的东西时，加密会自动打开，不再是可选的。

3。*记录您的开发和部署流程。*这一步特别适用于开发和 Devops 团队。你的组织有一个关于代码如何从开始到结束进入生产的文档化过程吗？如果开发者提出拉取请求，是如何审核的？谁有权批准，需要多少人批准？作为这一步骤的一部分，您正在进行哪些检查？你在这个级别运行安全扫描吗？他们是因为吵而被忽视吗？

开发和部署过程必须被很好地记录和执行——不仅仅是对某些人，而是对所有人。很可能总会有一个管理员可以合并代码而不遵循流程，这意味着可见性是关键。你需要洞察审计变更和掩盖审计线索的能力。管理员可以进行更改，在生产过程中一直推行这些更改，然后从根本上消除这些更改，就像从未发生过一样。这不是一个好的实践，那么有什么检查来防止它呢？

在 Fairwinds，我们通过实施一个系统来监控我们的生产集群，并在一个松弛通道中发送该集群的变化通知，从而解决了这个问题。通知系统的管理方式与我们的开发工作流是分开的，这意味着没有人可以在不生成单独通知的情况下对产品进行更改。我们有审计追踪来显示我们产品自始至终的完全连续性。

4. Document all your policies, not just those related to infrastructure. Think about things like onboarding and offboarding of employees. How do you take on vendors? How do you evaluate risk for the company? Write it down and follow it. Writing a policy is one thing, but following it is another thing entirely.

FAIRWINDS INSIGHTS 和 SOC 2

当人们经历这些不同的需求时，Fairwinds 可以帮助手动或自动收集证据，缩小最重要的范围。Fairwinds Insights 非常关注安全性和合规性，我们帮助创建政策和护栏，使开发人员能够遵守 SOC 2 合规性所需的程序。但是，当公司增加 Kubernetes 的使用量并需要准确的报告时，我们也可以帮助进行成本优化。

Fairwinds Insights 可供免费使用。你可以在这里报名。

现成的 Fairwinds Insights 可以帮助您围绕这些策略实施控制。我们的解决方案涵盖了整个生产环境中的 CI/CD，并且可以提供对错误配置、容器风险以及任何类型的护栏或策略的可见性，您可以使用这些护栏或策略来指导开发人员将应用程序部署到 Kubernetes 中。我们有多个集成，包括 JIRA，Datadog，Slack，CircleCl 和最近的 PagerDuty。

关于 KINTENT

Kintent 的使命是轻松赢得每一个商业关系中的信任。他们的核心理念是:如果你的客户信任你，他们会想和你做更多的生意。Kintent 的第一个信任用例专注于数据安全和隐私。Kintent 的 信任管理平台 民主化了每家公司快速且经济高效地采用正式的安全和隐私程序的能力，并衡量程序的准确性。此外，通过 Respond 的人工智能生成的答案，回答安全问卷是一种轻松的体验，而 Trust Share 允许您主动&自信地与客户分享您的计划。有了 Kintent，信息安全成为一种习惯，易于理解和实施，并且可持续测试——因此您的客户可以看到您遵守了所有的安全义务。

选择 Kubernetes 时的 5 个关键考虑因素

原文：https://www.fairwinds.com/blog/5-key-considerations-when-choosing-kubernetes

It seems like this should be easy to know where to start, but then you find out there are some significant hurdles in Kubernetes adoption, and even knowing how to explain Kubernetes and where to begin can feel overwhelming.

在全力投入之前，这里有五件事需要考虑。

1。学习你不知道的东西

Kubernetes 是历史上最大的开源项目之一——生态系统是巨大的，项目本身的复杂性令人难以置信，有附加组件、第三方贡献和托管服务。哪些作品是必不可少的？哪些是碎的？你到底听谁的话才知道呢？

In a 2018 CNCF survey, 40% of respondents found Complexity to be one of the biggest challenges to using and deploying containers. Kubernetes can make things easier. But if you don’t know where to get started, it can also add incredible complexity.Similarly, The New Stack found that 78% of companies will attempt Kubernetes adoption on their own, and, consequently, 38% of respondents indicated this has taken longer than originally expected. You need to budget carefully, train your team or hire outside talent, and make sure your people have enough knowledge and comfort to also implement a sane on-call rotation. Some solutions, like Fairwinds ClusterOps, offer Advisory services to help augment you with sound architectural decisions along the way.

2。构建和维护生产级堆栈

一旦你克服了最初的障碍，你将如何为生产做好准备呢？仅仅是启动和运行 Kubernetes 与为生产做准备是不同的。这里有几种选择，所有这些都取决于您选择部署到哪里。

如果您选择部署到公共云，三大主要云提供商都有 托管的 Kubernetes 服务产品。 这些服务专注于为您提供高度可用的控制平面，这意味着您不需要管理 Kubernetes 运行的底层节点或计算。托管的 Kubernetes 服务还将为您提供一个直观的 【点击式】 UI 来创建集群。 不幸的是，每个服务处理补丁、升级甚至自动伸缩的方式都不一样。确保你对第一个 CVE 来袭的时间，或者你期待的黑色星期五交通高峰有个计划。

下一个 ， 你们计划实施哪些附加产品？哪些附加组件使您的基础架构更适合生产，哪些会使您面临新的更复杂的安全问题？大多数插件都是开源的，但在推向生产之前，它们仍然需要大量的时间投资和内部 P o Cs。

投资培训。投资外部帮助。投资第三方来审计你所建立的东西，并确保你有正确的系统，否则它会回来咬你。Kubernetes 是一个不可思议的工具，但如果没有经验丰富的老手，它也可能是危险的。

3。不要忘记基础设施是代码

在 GCP 的 GKE、AWS 的 EKS 和 Azure 的 AKS 之间，甚至是其他地方的 Rancher 你可以在某个地方的 GUI 上登录 ,点击一些按钮，获得 Kubernetes 集群。但是，如果您的生产基础架构是通过点击点–和–构建的，那么您就没有一个可重复的模型来构建-并在将来修改-it。

在一个 worstcase场景中， 你会希望你的每一个设置和配置决策都被记录为代码，以快速备份掉的所有东西。 这就是基础设施作为代码是灾难恢复策略的重要基础的原因。

基础设施作为代码对于 SaaS 公司 或者电子商务公司 来说也是得心应手。像国际扩张或 白色 - 标签 这样的商业机会，出于性能或数据主权的考虑，可能需要 服务 在当地国家运行。将你的整个基础设施定义为代码可以让你相对容易地 制造出你的 环境 的精确复制品。

作为代码的基础设施不仅方便某些用例，也是运营中的最佳实践。 基础设施作为代码给你提供了一致性、版本控制、可测试性、透明性和可审计性，并使你的基础设施可复制。

4。实施全天候运营和监控

有时，您可能会觉得您的基础设施与您的业务无关，但是当基础设施出现故障，您的客户或顾客无法再访问任何东西时，您会意识到 It 对业务的重要性e盟友就是 。实施质量监控对您的 收入 和您的 工程团队有重大影响。

监控 井 很难，你的团队需要在出现问题时醒来，以便修复它们。不幸的是，仅仅给某人一个寻呼机是不够的。质量监控需要到位，这样您就可以实际知道何时发生或将要发生停机，并且您的团队需要有足够的装备，以便能够在出现问题时做出响应。

停机时间将直接影响您公司的收入。

构建良好的基础设施可以自动应对过去运营中的许多常见问题。Kubernetes 内置了许多这样的故障安全机制，但是您需要对它们进行适当的配置。

工程人员的士气和留任受到 监控不力的极大影响。

监控不力会直接影响你的工程幸福感。 确保建立一个合理的随叫随到的时间表，让工程师可以休假，而不会因为意外的生产事故而承受持续的压力。

5。验证您的部署

如果你已经建立了一个工作的生产级基础设施，完全以代码的形式记录和实现，并且它得到了很好的监控，你的团队正在处理随叫随到的轮换…祝贺你，你现在已经成功了 90%！

From here, your engineering team is more empowered than ever to work with Kubernetes and you have CI/CD in place. Now it’s time to validate each of the workloads being deployed to your cluster so you can be sure you stay aligned with best practices. These best practices can be dictated from an ops team, or they can be encoded and enforced with a tool like Fairwinds Polaris.

现在，您的开发人员可以直接看到他们正在部署的工作负载在到达集群之前的运行状况。您的运营团队可以看到 工作负载 在哪里被 不安全或不可靠地配置， 以及如何修复 这些问题 。

结论

借助一点外界的帮助，一些训练，以及放慢速度去思考那些如果你做错了会让你停下来的事情，你就能达到 Kubernetes Zen。如果你决定雇人帮你更快到达那里，Fairwinds 有各种各样的产品可以加速 Kubernetes 的采用 (将时间从几个月缩短到几周，而不是几个月或更长)。

Kubernetes 成本估算策略的 5 个问题

原文：https://www.fairwinds.com/blog/5-problems-with-kubernetes-cost-estimation-strategies

很难估计您在特定的 Kubernetes 工作负载上花费(或浪费)了多少。好消息是，有一些合理的策略可以估算给定工作负载的成本。

在本帖中，我们将讨论影响成本估算的五个主要问题，并在 Fairwinds Insights 成本仪表板中触及我们用来克服这些问题的策略。我们将在即将发布的博客中对正确的规模进行更深入的回顾。

问题#1:箱柜包装

假设我们有一个节点，每月花费 20 美元。假设它有 5GB 的内存和 5 个 CPU，我们可以使用。(注意:这不是一个非常现实的节点，但它使图表和数学变得很好🙂)

这是一个工作负载，需要 2 GB 内存和 2 个 CPU 才能运行:

我们可以在单个节点中安装相当于两个 pod 的工作负载:

但是，如果我们想为工作负载添加第三个 Pod，就没有足够的空间了。因此，我们需要添加一个新节点(并为此付费):

请注意，在我们的第一个节点上有一点点空间被浪费了——我们有 1GB 的内存和 1CPU。我们的第二个节点利用率非常低，只有不到一半的资源得到利用。

这是成本估算的第一个也是首要的问题 : Kubernetes 无法将一个 pod 拆分到多个节点上。因此，如果一个节点容纳不下全部数量的机架，就会浪费一定的容量。

**解决方案:**这里的一个解决方案是“调整”节点的大小。如果我们使用一个具有 4GB 内存和 4CPUs 的节点，我们的工作负载将非常合适，并且不会浪费任何容量:

问题#2:资源不对称

让我们考虑一种不同的工作负载:一种 CPU 密集型的工作负载。它需要 3 个 CPU 来运行，但只有 1GB 的内存。

现在，我们只能将相当于 1 Pod 的工作负载放入单个节点中(使用我们的 4CPU/4GB 示例):

这里浪费了大量未使用的容量——不仅是 1 个 CPU，还有 3 GB 的内存。我们只使用了一半的节点，但如果我们想要启动第二个 Pod，我们将需要第二个节点，浪费量相同！

**解决方案:**同样，我们希望调整节点的大小——云提供商提供 CPU 密集型和内存密集型节点来处理这个问题。

问题#3:成本归属

假设我们的较小节点(4 个 CPU 和 4 GB)每月成本为 16 美元。使用这些数字，我们可以粗略估计出每个 CPU 和每 GB 内存的成本。比方说，在这 16 美元中，8 美元用于 CPU，8 美元用于内存。然后我们可以推断出我们为每 CPU 支付了 2 美元，为每 GB 内存支付了 2 美元。

那么，我们每个 pod 的原始工作负载成本是多少？

根据我们上面的计算，我们会说$2/CPU * 2CPUs + $2/GB * 2GBs = $8.是有道理的——我们可以在一个 16 美元的节点上恰好安装两个这样的工作负载。出于我们将在下面讨论的原因，我们称这种为成本估算的乐观方法。

但是我们的第二个工作负载，CPU 密集型的工作负载呢？

让我们做同样的计算:$2/CPU * 3CPUs + $2/GB * 1GB = $8.所以乐观方法说这个工作负载花费我们 8 美元。但是正如我们在上面看到的，我们只能在每个节点上安装一个。所以在现实中，它的成本是 16 美元/月，而乐观的方法似乎并不那么准确。

有没有另一种成本估算方法可以给我们一个更合理的答案？有！

我们可以不把 CPU 成本和内存成本加在一起，取两者的最大值。这有助于我们考虑内存密集型或 CPU 密集型工作负载，这些工作负载可能会浪费额外的容量。(注意，我们还需要将结果乘以 2，因此我们也要计算丢失的资源。)

因此，数学变得MAX($2/CPU * 3CPUs, $2/GB * 1GB) * 2 = $12.这是一个更接近 16 美元目标的好交易。其余的是完全未使用的节点容量(即，尽管该节点承载 CPU 密集型工作负载，但仍将浪费 1 个 CPU)。

我们称之为保守的估算方法。就 Kubernetes 将工作负载打包到节点上的能力而言，它为最坏的情况做了准备。

对于许多工作负载，保守方法和乐观方法会给出类似的估计，但是对于 CPU 或内存密集型工作负载，它们会有所不同。基本区别在于，乐观方法假设最优装箱，而保守方法假设会有一些浪费。例如，假设我们也在运行一个内存密集型工作负载，它只需要 1 个 CPU，但需要 3 GB 内存:

Kubernetes 非常聪明，它将这些与我们的 CPU 密集型工作负载打包在一起，为我们节省了未使用的容量:

保守的方法会说这些工作负载的每一个成本为 12 美元，总成本为 24 美元。但是 Kubernetes 已经找到了一种方法将它们打包成一个 16 美元的节点！我们已经错过了。这就是为什么它被称为保守派。

乐观方法考虑到了巧妙的装箱，可以说每个工作负载花费 8 美元，总花费 16 美元，这是一个完美的估计，因为它们正好适合一个 16 美元的节点。

解决方案:那么应该用哪个呢？答案是视情况而定。如果您已经花时间优化您的实例类型，或者如果您的节点比您的平均工作负载大得多，那么 Kubernetes 很有可能找到一种以经济高效的方式将工作负载打包在一起的方法，并且您可以安全地选择乐观方法。否则，我们推荐保守方法。

问题 4:资源范围

另一个问题是 Kubernetes 工作负载不仅仅使用固定数量的 CPU 和内存。资源的使用可能会随着时间的推移而变化，并且 pod 可能会因为这些波动而被终止或在节点之间移动。

为了帮助解决这个问题，Kubernetes 配置为工程师提供了两个管理资源的字段:

• requests设置工作负载的最小资源使用量。当一个工作负载在一个节点上被调度时，您可以确保至少有这么多的可用
• limits设置工作负载的最大资源使用量。当一个工作负载的 Pod 尝试使用超过这个数量时，Pod 将被杀死，一个新的 Pod 将启动。

给定工作负载的实际资源使用量将介于这两个数字之间，并且每秒钟都会有很大的波动(只需查看 macbook 上的活动监视器，就可以了解这种变化有多大！).

**解决方案:**估算底线工作负载成本的一种方法是查看波动的数字，然后取一段时间的平均值。估算工作负载成本的另一种方法是查看requests和limits以提供一系列可能性，或者取两者的平均值。

由于 Fairwinds Insights 主要关注的是配置验证，我们选择了第二种策略——我们想告诉你，鉴于你目前的配置，你可以预计这一工作负载的成本。

**## 问题 5:吵闹的邻居

Kubernetes 只能用它得到的信息做到最好。这就是为什么为每一个工作负载指定requests和limits如此重要。

例如，如果您的一个工作负载适时地请求 1GB 的内存，但是同一节点上的另一个工作负载没有设置requests或limits,，那么第二个工作负载很容易就开始吞噬该节点上的所有可用资源。这可能会阻止我们的原始工作负载获得所需的所有内存，从而影响其性能。

因为很难设定这些设置，一些团队从来没有设定过要求或限制，而另一些团队在初始测试时将它们设定得太高，然后就永远不会正确。为了恰当地估计成本，我们需要设置正确的限制和要求。Fairwinds Insights 使用免费开源工具 Goldilocks 来分析实际资源使用情况，并为requests和limits推荐“刚刚好”的设置。

结论

了解您组织的每个应用程序影响的财务成本非常重要，但是当它们都在 Kubernetes 中一起运行时，这可能会非常困难。幸运的是，有一些合理的方法可以解决 Kubernetes 成本估算的每个问题。

通过组合使用合适的规模(更多内容将在后面介绍)、采用正确的方法(例如保守与乐观)以及使用 Fairwinds Insights 和 Goldilocks 等配置验证工具，您可以确保 Kubernetes 部署高效运行。

Fairwinds Insights 可供免费使用。你可以在 这里 报名。

**

云原生护栏帮助您的开发团队交付的 5 种方式

原文：https://www.fairwinds.com/blog/5-ways-cloud-native-guardrails-help-your-development-team-deliver

传统的治理方法，例如为 IT 服务和资产管理创建了一套详细实践的信息技术基础设施库(ITIL)方法，限制过多，最终减慢了开发团队的速度。这种模式在云原生环境中适得其反，平台工程师和开发人员对采用新的治理模式持谨慎态度是可以理解的，他们认为这可能会在快节奏的开发和交付环境中减慢交付速度。

随着组织越来越多地采用 Kubernetes 来快速构建和交付云原生应用，他们了解他们正在部署的技术的战略重要性，以及管理成本和符合整体业务需求的需求。那么，他们如何采用护栏来保持一切顺利运行，而不在他们的开发团队面前设置路障呢？如果云原生治理实际上更像我们在弯曲山路上的护栏会怎么样。您可能永远不需要它们，但它们就在那里，阻止您坠入悬崖——或者在软件开发中，部署带有安全漏洞和错误配置的代码，违反合规性，并可能导致过高的云成本。

Kubernetes 生态系统固有的 治理护栏 使组织能够跨云原生基础架构环境以及其上部署的应用和服务创建、管理、部署和实施策略。通过将 声明性 和自动化治理放在适当的位置，平台工程师可以使开发人员能够自助服务并更容易地满足业务计划。方法如下:

1。敏捷、集成的软件开发和部署

每个人都已经看到敏捷方法是如何加速软件开发和部署的。与 Kubernetes 集成的云原生 护栏 部署在整个 Kubernetes 应用生命周期中，从第 0 天(规划)到第 1 天(部署)再到第 2 天(全面生产)。在这些阶段的每一个阶段都应用并执行不同的策略，因此所采用的任何治理解决方案都必须与 CI/CD 工具相集成。

Kubernetes 和治理解决方案之间的集成为平台工程和 DevOps 团队提供了在整个软件开发生命周期(SDLC)中维护策略合规性的能力，而无需手动干预和频繁的代码审查。策略还可以应用于 基础设施配置 以及直接影响应用程序开发人员的应用程序特定问题。

2。法规合规性

监管可能是一个持续的挑战，因为开发人员要努力确保他们部署的应用程序和服务能够正确处理数据并安全部署。无论一个组织是否必须满足财务法规，如 、萨班斯奥克斯利 或 PCI DSS 、医疗法规( HIPAA )或数据隐私法规(【GDPR)，总有需要满足的要求。云原生防护栏包括许多支持合规性和云配置策略的声明性策略语言。这些护栏还可以自动跟踪政策合规性，使团队更容易遵守不断变化的法规，并跟踪监管机构的合规性。

3。威胁表面的可见性:云、SaaS、PaaS、&(？)aaS

平台和 DevOps 团队可以使用云原生防护栏在云中和内部适当地自动识别 Kubernetes 环境中的 漏洞 和错误配置。这些工具还可以根据需要向开发人员提供补救建议，并识别任何已识别问题的关键程度。这些信息让开发人员能够放心地进行自助服务，因为他们知道护栏已经就位。

从第 0 天到第 2 天，Cloud native guardrails 还可以通过监控所有集群的安全错误配置来自动执行许多安全任务。云原生治理平台可以在扩展到多个集群和团队时持续配置 Kubernetes。这使得平台团队能够自动识别 Kubernetes 生命周期中的错误配置，简化了发现和修复漏洞和错误配置的过程，即使他们的 K8s 环境变得更加复杂。

4。成本效率

管理云和 Kubernetes 成本对大多数组织来说都是一项挑战。CNCF 针对 Kubernetes 的 FinOps 报告“Kubernetes 成本监控不足或不存在导致超支 ”显示，在过去一年中，68%的受访者的 Kubernetes 成本增加，其中一半人的成本增加超过 20%。由于团队难以监控和预测 Kubernetes 的支出，这些不断上升的成本变得更加复杂。Cloud native guardrails 可以持续监控 Kube 集群效率，帮助团队设置适当的请求和限制，以确保团队能够以最低的支出实现最大的可靠性。它还可以自动配置 Kubernetes 并一致地应用策略，以确保即使在团队扩展时，成本效率和优化也能继续得到适当的控制。

5。一致性和可靠性

guardrails 治理方法依赖于将 策略 表示为声明性元数据的能力。当平台工程师使用以公共语言通信的工具和系统构建内部开发平台时，它简化了这种策略的表示和实施。现代声明性策略语言对于支持软件开发人员自助服务是不可或缺的，因为它们在执行组织策略的底层系统和工具的框架内工作。

云原生防护栏帮助平台工程师和开发人员调整应用的大小，以便根据使用情况适当调整云资源请求和限制。正确的解决方案可以帮助团队了解 Kubernetes，不仅可以分配资源，还可以将成本归因于工作负载和团队。这些信息通过优化工作负载的可靠性和可伸缩性，帮助团队达到应用程序的可用性标准。

采用云端原生护栏

虽然过去的治理模型阻碍了速度和敏捷性，但是软件开发和技术的新方法需要集成到 Kubernetes 环境中而不降低交付速度的解决方案。保持安全性、合规性和成本一致的云原生防护栏，不会给软件开发人员带来成为 Kubernetes 专家或要求平台工程师充当 Kubernetes 服务台的负担，可以实现这些目标。fair winds Insights为当今的平台工程和软件开发团队提供云原生护栏。尝试一下 免费层 (可用于多达 20 个节点、两个集群和一个 repo 的环境)，看看其内置和定制的 Kubernetes 最佳实践如何在降低风险的同时改善开发人员体验。

提高组织的力量和灵活性的 5 种方法

原文：https://www.fairwinds.com/blog/5-ways-to-boost-the-strength-and-flexibility-of-your-organization

作为一个通过业务而不是传统工程途径获得工程副总裁职位的人，我在许多不同类型的组织中工作过。从非营利组织到企业，我的经历让我在过去的 20 年里实施了数字化转型运动。在我科技职业生涯的早期，它实际上是从纸质转移到数字——将实体小册子转化为网络展示。然后从桌面到更具响应性的体验，现在到了一个基于云的世界，这个世界正在以惊人的速度发展。

迄今为止，我职业生涯中最大的不变就是变化。我的主要目标一直没变——帮助我的同事和客户(还有我自己！)理解并拥抱即将到来的变化。

商业或生活中的巨大变化需要你同时变得强大和灵活。在商业中，从个人贡献者到高管层的人，保持情绪上的弹性和抗脆弱会让你走向成功。它给你力量和空间去弯曲，而不折断。有很多未知，挑战和挫折，改变往往是不舒服的。找到拥抱这种不适的方法，并帮助你的团队感到安全，是解决问题和成长的捷径。

建立团队和实现目标

我们在地平线上看到一个目标，不管它是什么，我们都要为之努力。我们想要到达那里，我们想要快速到达那里。我们制定了时间表和计划。有时，我们放眼全局，可以看到即将到来的变化，但我们还不知道它将如何影响我们的员工和技术。

不管你是否处于领导地位，清晰而现实地想象你的目标——以及阻碍你实现目标的一切——是帮助你实现目标的东西。重新定位和重新思考，改变有利位置——这种灵活性使我们能够推动成果并定义组织结构来支持我们的目标。

积极的结果需要个人、专业和组织的灵活性——无论是个人还是团队。团队有无数种定义。如何定义自己的？你支持哪些人，反之亦然？如果你身居要职，你的工作就是为人们创造展示和超越的空间，给他们尽可能多的信息——关于大局、方向、战略和时间表。这个过程帮助人们找到个人的成功，并更好地理解他们在整个组织的成功中的位置。了解你的业务、它的机会以及它(和你)的局限性是至关重要的。不知道的时候要知道。

许多领导人谈论快速失败。我说，进行下一步。失败得很快，而且是公开的。愿意承认缺点——对我的同事、上司和我支持的人——会在团队中创造弹性，鼓励心理安全，模拟作为一个完整的人运作，并最终创建一个可扩展的组织结构。

在成长中学习和改变

随着我们在 Fairwinds 的不断发展，我们一直在考虑为人们创造机会，让他们走上更高的职位，测试他们的领导技能并推动个人项目——根据他们自己的经验来探索。这些步骤不仅有助于我们建立人们在组织中前进的脚手架，而且它们还致力于编纂一种反脆弱性的态度，在这种态度下，知识和变化通过真正的成长而发生。

客户是我们 Fairwinds 工作的重要组成部分。业内有句谚语:“给我看你的预算，我给你看你的策略。”换句话说，你花钱的方式决定了你组织战略的现实。你如何将客户的观点纳入你的组织结构中？您如何确保您的客户方法保持适应性和响应性？

在某些环境中，客户需要定制的体验；他们需要大量个性化的关注和一致性，以便从产品或服务中获取价值。在其他情况下，客户可以与各种各样的人互动，并对帮助台的体验感到满意。问题是，您的预算是否支持您企业的正确目标？如果不是，需要改变什么？

在 Fairwinds，我们依靠快速响应来帮助我们的客户(以及彼此)获得成功。我们拥抱变化，并据此组织我们的预算。但是这到底意味着什么呢？

以下是我们拥抱未知的五个具体建议:

1. 保持冷静。你承受的压力越大，你就变得越反动。压力和膝跳反应只会导致僵化、恐惧和更多的压力。假设他人和他们的行为是善意的。当评估变化的各种影响时，假设决策的基线来自积极的意图。
2. 赐恩。不管你有多好的意图，人们(包括你！)有时候会把事情搞砸。通过公开失败的意愿给自己和他人以恩惠。为了减少这种打击，通过承认你的错误来“快速失败”，清楚它将如何通知你前进的道路，然后继续前进。
3. 有效沟通。你的意图比你的信息如何传到别人耳朵里更重要。如果人们听不到你想说什么，不管是什么，你需要改变你的沟通方式。从面对面的交谈到提供材料让人们在自己的时间里复习，沟通以多种方式进行。不要只停留在一个上。愿意问别人不会问的问题，大声地、无所畏惧地问——然后倾听。
4. 进行实验。尝试新事物！快速失败，停止，重新评估…不管怎样，学习并继续前进。不要做同样的老决定——而是，问问你自己和你的团队，了解你为什么要做这些事情；为什么你使用你所使用的工具，为什么你以特定的方式互动。滚动基础上的小实验将建立核心的灵活性。
5. 支点。上面提到的一些实验会取得巨大成功，坦白地说，有些不会。你需要做相应的调整。把你的精力和资源投入到成功的元素中，但是要时刻准备好跟随新的机会之路。不要因为执着而去追逐想法。沉没成本就是这样。足够灵活，以便快速失败，然后转向其他地方的未来成功。

完美是完成的敌人

乐于助人是我对成功的理解。我的团队努力将对未知的恐惧转化为对未来的好奇。我们也要记住，“完美”是不存在的。简而言之，完美只是僵化。当然，要严谨并面对重要的挑战——但是在你的努力中要透明和灵活。一旦你这样做了，你可能会发现你已经锁定了最大的目标之一——稳定和强大的创新。

让你的开发团队(使用 Kubernetes)喜欢你的 5 种方法

原文：https://www.fairwinds.com/blog/5-ways-to-make-your-dev-teams-love-you

作为一名工程领导者，你有一个选择:你可以不断地做出让每个人抓狂的决定，或者你可以通过让你的开发人员做他们想做的事情来让他们爱你。

Kendall Miller 和 Rishi Malik 在 PagerDuty 峰会上讨论了如果你正在领导一个使用 Kubernetes 的团队，有五种方法可以让你的开发团队爱上你。以下是外卖。

1.给你的开发人员提供他们实际上想要使用的工具。

你想要给你的开发者他们真正想要使用的工具。作为一名产品人员，如果你正在为其他工程师开发工具，请从这个角度考虑:

工程师们会乐于使用它，还是会觉得使用它是一种折磨？

你给他们的工具越痛苦，他们就会越愤怒，而这些小的刺激会累积成很多挫折。例如，当开发人员想要使用 Slack 时，你是否在使用团队(反之亦然)？当他们只想使用 Git 时，您是强迫他们使用 Subversion，还是让他们在一天结束时只想通过电子邮件发送代码时使用 Git？(虽然在最后一个例子中，你真的应该坚定立场)。

如果某样东西会让你的开发人员更有效率，因为这是他们真正想要使用的东西，那么它的成本差异是值得的。首席财务官可能会看着一个工具说，“嗯，每个工程师要 50 美元。这不值得。”但是通常，这些事情在开发人员的生产力上很快就有了回报。对于首席财务官来说，这可能是一个项目，但对于工程师来说，这是你每天都在做的事情，它会产生很大的影响，值得投资。将您的工程师熟悉的工具放在适当的位置，这样他们就不必花很长时间来准备了。

避免给他们多一个仪表板来登录，或者在开发过程中多走一步，这会变得很痛苦。有时候你不得不这么做是有原因的，但是尽可能地给他们提供他们想要使用的工具，从长远来看，这实际上会为你省钱，即使这在短期内会让你花钱。

2.给你的开发人员时间来解决技术债务(避免一百万次剪纸死亡)

如果你不给你的开发人员时间来解决技术债务，他们将继续在你的部署管道上构建一堆黑客，直到一切都崩溃了，你什么也做不出来。获取这些代码、解决 x 问题、修复事故或满足客户期限的压力总是存在的。有生意要做，有钱要赚，有顾客要满意，但这就是挑战。在某些时候，你必须做得更好。不幸的是，对于大多数公司来说，这不是他们工作的核心驱动力。

当使用 Kubernetes 时，将工具放在适当的位置，以帮助您的开发人员保持一致，并轻松地看到需要清理的内容。使用提供Kubernetes guardrails的工具，如 Insights ，或事件管理如 PagerDuty ，您可以获得一个干净、一致的界面，您的团队可以在整个部署管道中构建一致的界面。这会让团队更开心。

3.使您的开发人员能够解决实际推动商业价值的问题

基于产品的工程师希望致力于提供客户价值的特性。不幸的是，与上述相关，你可以花更多的时间处理工具或围绕技术债务的黑客攻击，因为你没有时间只是重新启动它。但这就是痛苦。团队将花费更多的时间维护平台或工具，而不是向客户交付结果。这是一种耻辱，让人发疯。开发人员没有花足够的时间来构建和发布他们想要的代码。

我们大多数人工作是因为我们需要赚钱，养活自己和家人。当你觉得你的工作有意义时，因为你可以给商业价值划一条线，你(和你的开发人员)会更加投入。要求你的开发人员放弃一些他们知道不重要的东西会让他们士气低落，最终他们会继续前进。

商业价值的另一面是成本。开发人员并不真的想专注于此，但在某些时候，会有财务人员对服务的费用提出质疑，建议“我们不能去做这个新的计划，因为它会花费我们太多。”该成本可能是工程、时间、运营成本(运行虚拟机或容器的成本)。

为开发团队提供工具，让他们能够快速对云、Kubernetes 或容器配置进行小的调整，以便他们能够降低成本或证明他们为什么需要虚拟机/容器运行，这将更好地帮助他们取得成功。

不幸的是，许多人不知道如何降低成本。他们知道他们花费太多，但不知道如何改善，特别是与 Kubernetes，它可以感觉像一个。开发人员需要一种方法来了解正在发生的事情，这样他们就不会在一周内意外损失 50，000 美元，他们知道哪里超支了，哪里应该控制它。

4.通过合理的权衡来解决安全性问题

运营中的一切都是有得有失。正常运行时间与金钱，简单或高质量的 QA，超快速或超安全的应用程序。弄清楚什么样的权衡是有意义的总是运营的一部分，但是安全性尤其重要。

你需要在一定程度上保持安全。当你是一家拥有五个用户的小型初创公司时，你需要以不同于 Clover Networks 和处理支付处理的方式来确保安全。当你处于一个受监管的行业时，你在这些安全权衡中没有选择。你很清楚你需要达到什么样的标准，不管有多痛苦，多悲惨，你都要达到那些标准。

当使用或实现对您的开发团队有意义的安全工具时，就少了一个权衡。有一个安全的基本原理是很重要的，这样就不会简单地锁定所有的东西，导致生产力停止(或者更糟糕的是，团队围绕安全工具工作，所以你最终得到的是不安全的东西)。

如果你在一个 PCI 兼容的环境中工作，总会担心开发人员会绕过安全需求。一旦你把一个新的平台或工具放在适当的位置，你就有可能失去你组织中那些试图做正确事情的人的支持。你可能看不到平台是如何被使用的，因为如果他们在做“变通”，你不知道会发生什么来进行有意识的权衡。

做好安全工作并确保良好的开发者体验的方法是确保你有可见性，并使做正确的事情变得非常容易，做错误的事情变得非常困难。您不希望安全团队是“不”的团队。相反，让开发人员满意的方法是确保您所有的库都是最新的，所有的依赖项都在升级，随着新版本的发布和新漏洞的发现，将这些融入到您的工作中，将可见性融入到您所拥有的工具中，突然之间，您变得更加安全，并且您让开发人员的生活变得更好。这是双赢的局面。

Fairwinds Insights 帮助开发者保护 Kubernetes。了解更多。

5.设定明确的范围和自主权

先说个例子。有一位工程师在工作之外花了 60 个小时为一个业务问题构建解决方案。他非常兴奋地向他的 CTO 展示，但当他展示时，CTO 问“为什么是 Ansible 而不是 Python。”没有分享一些有价值的东西，也没有得到表扬，护栏不清晰，这种阻碍让工程师哭了，最终辞职了。

组织需要建立规则，使它们清晰，并设定范围，这样人们就有解决问题的自主权。但是，当设置这些规则时，设置上下文并解释原因。在上面的例子中，可能是因为 Python 是默认的编程语言，以避免聘请 Python 之外的专家的挑战。

当人们不能询问领导时，让他们做出好的决定，因为领导不能参与每一个决定。设定为什么，设定背景，让人们知道背后的原因，并能做出最好的选择。

人们想要护栏(尤其是在 Kubernetes 的情况下)，这样他们就有足够的自由在安全网到位的情况下解决业务问题(这样事情就不会以悲剧收场)。护栏让每个人都能安心执行。

相反，护栏以一种自主的方式给予自由，当一件事情完成时，它不会带着“你为什么要那样做”的问题而来这会让你的开发人员保持兴奋、投入和热情，也会让人们长期留在工作岗位上。作为一名工程领导者，你的工程师会很高兴的。

总结

公司应该更多地考虑开发者的体验。

1. 实现优秀的工具，这样开发人员可以更快地完成更多工作。

2. 使用让人们生活更美好的工具。

在发展中有很多挑战，但这种方式的思考将推动整个行业向前发展。

---

有很多东西可以让这变得更容易，好的工具，开源。Fairwinds 为 Kubernetes 用户提供开源工具，包括 【北极星】 、检查以确保遵循最佳实践的策略引擎、 【金凤花】 、帮助设置资源请求和限制的 以及许多其他工具 。此外，fair winds Insights提供 Kubernetes 大规模治理，为您的工程师提供指导和安慰，让他们能够在第一时间以正确的方式做他们需要的事情。

2023 年你需要的 6 个 Kubernetes 成本控制策略

原文：https://www.fairwinds.com/blog/6-kubernetes-cost-control-strategies-you-need-for-2023

组织越来越多地采取云迁移计划，从内部数据中心转向采用容器和 Kubernetes 来改变其基础设施并利用这些云原生技术。Kubernetes 本身是复杂的，需要新的技能和不断增加的成熟度水平，从生产前实施转向改善运营和优化环境。使 Kubernetes 采用过程进一步复杂化的是将 Kubernetes 成本控制策略落实到位的挑战。

Kubernetes 和总云成本

计算在云中运行应用和服务的总拥有成本比简单地购买一定数量的计算和存储并将其分配给团队更具挑战性。云计算为组织提供了对计算资源的按需访问，这使得了解单位经济性和整体云支出成为一个更加动态的问题，从而对预测和控制以及云财务管理提出了挑战。

随着时间的推移，托管、集成、运行、管理和保护云工作负载会涉及各种成本，而多云环境会使这些成本进一步复杂化。一些费用与计算消耗、数据传输和存储要求直接相关，而其他费用(如管理和保护工作负载)则在云支出方面引入了更多复杂性。有许多安全和管理工具以及与其他云服务的集成必须是计算总云成本的一部分。虽然云中的灵活性和可扩展性有所提高，但这些因素也会影响总体云支出，从而使云财务管理变得更加困难。

使用容器时，跟踪云支出也可能很困难(大多数组织都是这样)。管理 的成本控制 Kubernetes (容器编排的事实标准)可能会增加云财务管理的挑战，因为多个应用程序可以“打包”并在共享的计算资源上运行。

查看您的云提供商的账单不会提供所需的可见性，无法了解每个 Kubernetes 集群中运行的是哪个团队的工作负载或应用程序，更无法了解如何优化它们。这种缺乏可见性导致 Kubernetes 在云成本管理方面被视为黑洞。

考虑一种 FinOps 方法

为了更好地了解您的云支出，请考虑采用 FinOps 方法。FinOps 基金会将 FinOps 描述为一种使团队能够管理他们的云成本的实践，在这种实践中，每个人都拥有他们对云的使用的所有权。一个集中的最佳实践小组支持 FinOps 实践，您也可以将这些核心原则应用于 Kubernetes。Kubernetes 服务所有权 ，当 DevOps 为开发人员提供他们需要的工具(和护栏)来构建、部署和拥有一个端到端的应用时，需要包括对整体云成本管理的理解，因为配置和自动化在管理 Kubernetes 成本中起着如此关键的作用。

FinOps + Kubernetes 成本控制策略

当团队采用 Kubernetes 的 FinOps /服务所有权模型时，了解工作负载的成本是至关重要的。为了清楚地了解云资源的使用情况，FinOps 团队经常使用一个 Kubernetes 治理 平台。治理平台可以为云环境提供基于策略的控制，这使利益相关者(特别是开发人员)能够更好地理解财务责任，并通过允许他们理解和采用以下六种 Kubernetes 成本控制策略，就 Kubernetes 的财务做出数据驱动的决策:

1。工作量费用分配

如果没有对工作负载分配的深入了解，就很难根据业务环境调整报告。KPI 是什么？团队需要知道什么是折衷吗？通过命名空间或标签对成本估计进行分配和分组，提供了帮助实现持续改进的洞察力。

2。Kubernetes】成本优化

确保您拥有评估应用程序和集群所需的可见性，以帮助您找到提高成本效率和降低云计算成本而不影响性能的方法。

3。精简建议

寻找解决方案，通过监控帮助您最大限度地提高 Kubernetes 工作负载的 CPU 和内存利用率。有效的实时监控解决方案包括关于资源限制和请求的建议，而服务质量建议可以帮助您确保您的应用按预期扩展。

4。库柏成本回归〔T2〕〔T3〕

报告是 Kubernetes 成本控制策略的一个重要方面，因此请确保您可以向财务团队报告您的 Kubernetes 使用成本，并将使用成本分配给开发人员，以便您可以跟踪指标，证明随着时间的推移节省的成本。跨职能团队帮助利益相关者使用指标来制定更好的业务决策并改善财务运营。

5。多集群成本和使用

优化 Kubernetes 成本的最大挑战之一与集群容量和使用有关。确保您可以收集关于有多少成本和使用量花费在闲置容量、共享资源与特定于应用程序的资源上，以及节点扩展的有效性的指标。这些生命周期数据可以帮助您实现成本节约。

6. Cloud billing integration

要获得整个企业基于使用情况的准确成本数据以与采购部门共享，请整合您的云账单和相关定价(如您的 AWS 成本和使用情况报告),以便根据 Kubernetes 集群、命名空间、工作负载和标签来细分云支出。您还可以使用 Azure 的定价计算器 来估算使用 Azure 的每小时或每月成本。其他云提供商，尤其是公共云提供商，提供类似的计算器来更好地了解您的云环境中的使用情况。

K8s 治理平台可以提供这些见解，进而实现 Kubernetes 和 Kubernetes 成本控制战略的云 FinOps 方法。使用基准数据，组织可以更好地了解部署的业务价值，改进关于云支出的决策，并提高云成本优化。

监控&优化 Kubernetes 成本

云支出很复杂，Kubernetes 会使了解总体支出变得更加困难。采用 FinOps 框架可以帮助平台工程领导者显著提高他们对 Kubernetes 支出的可见性。让每个参与者都成为 FinOps 实践者的方法，加上正确的解决方案，可以帮助您的组织了解和检查成本，优化计算和工作负载，执行成本分配，以及设置和审查 CPU 和内存分配，以确保根据实际使用情况正确调配应用。财务团队改善了财务运营，而不是信息真空，因为他们可以看到预算是如何分配和花费的，以及工程团队如何能够发现节约并随着时间的推移使其分配更加高效。采用 FinOps 原则有助于提高可预测性、优化成本并减少孤岛，帮助组织改善其整体云战略并为成功做好准备。

你永远不应该在 Kubernetes 第 3 部分:6 K8s 可靠性错误

原文：https://www.fairwinds.com/blog/6-kubernetes-reliability-mistakes

正如我们在这个系列的第一篇文章中所概述的，有些事情你绝对不应该在 Kubernetes 上做。duck bill Group 的首席云经济学家 Corey Quinn 与 Fairwinds 的总裁 Kendall Miller 和 Fairwinds 的高级站点可靠性工程师 Stevie Caldwell 进行了一次生动的对话，讨论了开发和运营团队如果想从领先的容器协调器中获得最大收益，就不应该在 Kubernetes 中做的事情。如果你想最大限度地提高 Kubernetes 的可靠性，以下是你需要避免的…

(请记住，这是绝对不应该的，所以标题可能看起来有点奇怪，有点明显，甚至令人惊讶！)

1.通过图形用户界面配置所有的东西

通过图形用户界面(GUI)配置一切的问题是，你最终会有一个人 也许 记得他们按下的所有按钮来设置一切。然后，如果他们不记得这个过程，或者如果那个人离开了，就很难通过点击复制你的环境。您当然可以通过 GUI 进行配置，但是如果您选择这样做，您必须在工作簿中写下所有内容，描述如何完成步骤以及单击什么(和哪里)，然后交叉手指，希望您知道在真正需要工作簿时在哪里可以找到它(也许不要这样做)。

假设一切都倒了，你需要进去重新创建你的集群。通过指向和单击来实现这一点是重建集群的最慢方式。也就是说，从最低级到最高级的设置有一个演变过程，所以你可以从使用控制台开始，点击鼠标。然后你会升级到类似于 Terraform 或 CloudFormation (都是作为代码工具的基础设施)。除此之外，您还可以使用更动态的解决方案，比如云开发工具包( CDK )，它允许您使用熟悉的语言定义 Kubernetes 和基础设施组件。最后一步是使用控制台。控制台有一个很棒的用户界面，值得使用，但必须有一些东西来捕捉所做的改变并加以整理。有些提供者会这样做，所以如果你改变了什么，你可以点击一个按钮，它就会给出所有设置的代码。

如果你的供应商不这样做(例如 AWS)控制台记录器是伊恩·麦凯制作和维护的扩展。它位于 Chrome 或 Firefox 中，可以观察你在控制台中所做的一切，然后用你想要的任何语言生成你所做的一切。它还为您刚才所做的事情提供了一个 scope IAM 策略。这是一个非常有用的扩展。

2.让你的 SREs 做 RDD

你应该永远不让你的站点可靠性工程师恢复驱动开发吗(RDD)？如果你的运营团队说他们想使用 XYZ，因为它是最热门的新事物 因为 他们希望能够把它放在他们的简历上，那可能不是决定如何建立你的整个基础设施的最佳方式。这并不是说没有很多有趣的技术，你的团队应该有机会探索它，但是，不要仅仅为了让你的简历成为他们的下一份工作而这样做。探索新技术很重要，但不要为了填写简历而牺牲基础设施的可靠性(总有非生产环境可以利用！).

3.在库贝内特斯的游牧部落上运行 Docker Swarm

光是这个标题就让你觉得，哇，也许我不该那么做？你是对的——不要在 Kubernetes 上运行 Docker Swarm 在 Nomad 之上。这听起来很荒谬，但我们已经看到公司试图做同样复杂的事情；他们使用一种工具来完成编排的一部分，使用另一种工具来完成调度，使用另一种工具来完成其他工作。出于某种原因，增加复杂性对一些人来说很有吸引力。在云原生计算基金会生态系统中，您可以探索许多伟大的解决方案，但目标是降低复杂性和增加可靠性，而不是相反。

4.复活节彩蛋单点故障

当我们说复活节彩蛋单点故障时，我们的意思是知道并隐藏真正有趣的单点故障。你永远都不应该藏起来。最常见的例子是“每个人”都知道的未记录在案的事情——直到你环顾四周，发现所有那些知道的人都在别处工作了。

总会有单点故障，问题只是它在堆栈中的位置。即使你认为你已经摆脱了他们，仍然有一些在那里。诀窍是现实地看待如何关闭你的网站，知道你的失败点是什么，而不是隐藏它们。

5.在伯尼的周末你的活跃度调查

如果你没有在伯尼的看过周末，那是一部人们假装死去的东西还活着的电影。这是你不想用你的活性探针做的事情。不要忽视事物已经死亡的事实，目标是确保您的 do 具有工作的活性探测器，以便您可以相应地做出响应。

对于很多商店来说，他们关注的监控系统是 Twitter 或客户支持台。这是他们知道情况不妙的唯一方法。不要那样做。

6.“暂时”跳过监控

有很多人只是想进入生产阶段，然后决定以后再研究如何监控。您不应该这样做的原因是，您越早开始监控，您就可以越早获得应用程序应该如何运行的基线。这些数据将为你做出的很多决定提供信息，比如你如何扩展，你的流量峰值在哪里，等等。

监控有助于你提高效率。如果你一直在监控，你的基线将帮助你决定如何配置，如何调整大小，以及如何适当地扩大或缩小规模。

观看完全娱乐性的网上研讨会点播，了解你在 Kubernetes 上不应该做的其他事情。

关于 Apache log4j 漏洞的 Fairwinds 安全声明

原文：https://www.fairwinds.com/blog/a-fairwinds-security-statement-on-the-apache-log4j-vulnerability

随着我们进入新的一年，我想分享一些最近关于 log4j 漏洞和我们的 Fairwinds 软件的持续安全性的关注。至关重要的是，我们的客户和开源社区明白我们已经意识到了这个问题，并且没有受到这个新的 log4j 安全问题的影响。

随着企业不断转向云原生应用，以应对其竞争挑战和目标，提高云安全性的需求仍然是重中之重。拜登政府最近已经解决了这一现实，他下令几乎所有联邦机构修补数百个现有的安全漏洞。这是一个迫不及待的举动，正如 note 涉及 log4j 的最新漏洞所证明的那样，log4j 是一个广泛使用的开源组件。

log4j 是什么？

被称为 log4j 的零日漏洞被称为近年来最严重的安全问题之一，它允许攻击者远程执行代码并获得对机器的访问权限。log4j 不仅易于利用，其无处不在的性质意味着它可以很容易地嵌入到大量的应用程序、服务和软件工具中——并被世界各地的坏人所利用。

Fairwinds 有没有受到 log4j 的影响？

不。作为 Fairwinds 的首席执行官和客户联络员，我想向我们的客户和开源社区保证，我们已经意识到最近在操作系统 Apache 项目 log4j 中披露的漏洞，在 CVE-2021-44228 和 CVE-2021-45046 下引用。

Fairwinds 已经审查了我们维护的所有开源项目，没有发现 log4j 漏洞或上述 CVEs 的任何存在:

• 北极星
• 金发姑娘
• 普路托
• 新星
• 计算者
• （关于）星球的；（关于）太空的
• 双子星座
• Saffire
• RBAC-经理

此外，我们希望向客户确认, Fairwinds Insights 没有受到 log4j 漏洞的影响。

这里的教训是什么？

这个新的漏洞应该成为业内人士和开源软件用户的一个重要提醒，随着 Kubernetes 和虚拟机的不断升温，将安全放在首位将是重中之重。疫情将全球推向远程工作，迫使组织迅速向云转移。这一现实点燃了对 Kubernetes、容器即服务和虚拟机市场的需求，但它也通过打开一个新的攻击面的世界而产生了合理的安全担忧。

因此，托管服务提供商(MSP)需要积极主动，能够以安全第一的方式提供服务，展示他们提供真正保护的能力。提供适当咨询和资源的 MSP 可能会成为希望扩展其工具套件并紧跟行业趋势的客户的值得信赖的合作伙伴。

理解 Kubernetes 活性探针最佳实践的指南

原文：https://www.fairwinds.com/blog/a-guide-to-understanding-kubernetes-liveness-probes-best-practices

Kubernetes 最初发布于 2014 年，是一个开源的容器编排系统，在 Apache License 2.0 下发布，用编程语言 Go 编写。谷歌最初创建了它，但今天它由 云本地计算基金会 (CNCF)维护。Kubernetes 提供了令人难以置信的灵活性，允许组织轻松地部署、扩展和管理生产级的容器化工作负载。这种灵活性伴随着巨大的复杂性和许多团队难以理解的不熟悉的术语和技术。活性探测器和就绪探测器 是在 Kubernetes 上部署成熟应用程序时应该知道的两个术语。在本指南中，我们将讨论在 Kubernetes 集群中运行活性探测，作为一种健康检查来确定容器是否仍在运行和响应。

探针在库伯内特中的重要性

您希望您的应用程序是可靠的，但是有时…他们不是。它们可能由于配置错误、应用程序错误或临时连接问题而失败。虽然应用程序变得不可靠的原因很重要，但知道问题已经发生或正在发生同样重要。探测器可以通过监控应用程序的问题来帮助开发人员排除故障，还可以通过指示应用程序何时出现资源争用来帮助他们规划和 管理资源 。

探测是监视应用程序运行状况的定期检查，通常使用命令行客户端或 YAML 部署模板进行配置。开发人员可以使用任何一种方法来配置探测器。K8s 中有三种类型的探头:

• 启动探测器: 这些探测器验证容器内的应用程序是否已经启动。它仅在启动时执行，如果一个容器未能通过此探测，该容器将被终止，并按照 restartPolicy 进行处理。您可以在 pod 配置的 spec.containers.startupProbe 属性中配置启动探测器。启动探测器的一个主要动机是，一些遗留应用程序在首次初始化时需要额外的启动时间，这使得设置活跃度探测器参数变得棘手。当配置一个 startupProbe， 使用与应用相同的协议，并确保 failureThreshold * periodSeconds 足以覆盖最坏的启动时间。

• 准备就绪探测器: 这些探测器持续验证 Docker 容器是否准备好服务请求。如果探测器返回失败状态，Kubernetes 会从所有服务的端点中删除 pod 的 IP 地址。准备就绪探测器使开发人员能够指示 Kubernetes，在其他任务完成之前，正在运行的容器不应该接收流量，例如加载文件、预热缓存和建立网络连接。您可以在 pod 配置的 spec.containers.readinessProbe 属性中配置就绪探测器。这些探测器按照 periodSeconds 属性的定义定期运行。

• 活性探测器: 这些探测器帮助您评估在容器中运行的应用程序是否处于健康状态。如果没有，Kubernetes 会终止容器并尝试重新部署它。当您想要确保您的应用程序没有死锁或无声无响应时，这些是有用的。您可以在 pod 配置的 spec.containers.livenessProbe代码> 属性中配置活性探针。像准备就绪探测器一样，活性探测器也定期运行。我们将在下面查看它们的详细信息和配置选项。

Kubernetes 中有哪些活性探针？

根据设计，Kubernetes 在 pod 的整个生命周期中自动监控它们，当它检测到进程 ID 1 ( pid 1)，即负责启动和关闭系统的 init 进程出现故障时，就会重新启动它们。当您的应用程序崩溃时，这非常有用，因为 Kubernetes 会终止它的进程并发出一个非零的访问代码。不幸的是，并非所有的应用程序都是一样的，Kubernetes 也不总是能检测到故障。例如，如果您的应用程序失去了其数据库连接，或者如果您的应用程序在与第三方服务连接时遇到超时，它可能无法自行恢复。在这种情况下，pod 在kube let看来可以按预期运行，但最终用户将无法访问应用程序。

这些类型的问题可能很难调试，因为在容器级别，一切都按预期运行。活性探测器解决了这个问题，因为它们将关于 pod 内部状态的信息传递给 Kubernetes，这意味着您的集群将处理这个问题，而不需要人工监控和干预。活性探测减轻了您的维护负担，并确保您的应用程序不会无声无息地失败。

活性探针的类型

下面是 Kubernetes 中可用的活跃度探测器类型的详细信息。选择与您的应用程序架构最接近并准确公开您的应用程序内部状态的活跃度探测器类型，对于成功地将工作负载部署到 Kubernetes 至关重要。

1。命令执行活跃度探测器: 该探测器在容器内部运行命令或脚本。如果命令以 0 作为退出代码终止，这意味着容器正在按预期运行。

2。HTTP GET 活跃度探测器: 该探测器向容器中的 URL 发送 HTTP GET 请求。如果容器的响应包含 200-399 范围内的 HTTP 状态代码，则意味着探测成功。 您可以在 httpGet 上为您的 HTTP 探测器设置这些附加字段:

• • 主机: 要连接的主机名称。默认为 pod IP 相反，您可能希望在 httpHeaders 中设置“Host”。

  • 方案: 用于连接主机(HTTP 或 HTTPS)的方案；默认为 HTTP。

  • *路径:*HTTP 服务器上访问的路径；默认为/。

  • httpHeaders: 您可以在请求中设置的自定义标头；HTTP 允许重复的头。

  • 港口: 集装箱上要访问的港口的名称或编号；该数字必须在 1 到 65535 的范围内。

3。TCP 套接字活跃度探测器: 该探测器试图连接到容器内部的特定 TCP 端口。如果指定的端口打开，则认为探测成功。

4。gRPC: 使用 gRPC 的应用程序可以使用 gRCP 健康检查探测器 。这种类型的探测器从 Kubernetes v1.23 开始就可用了。如果实现了 gRPC 健康检查协议，您可以配置 kubelet 使用它进行应用程序活性检查。您需要启用GRPCContainerProbe特征门 来配置依赖 gRPC 的检查。您必须将端口配置为使用 gRPC 探测，如果健康端点配置在非默认服务上，您还需要指定该服务。

在 Kubernetes 中配置活跃度探测器

在生产环境中，将活跃度探测作为应用程序部署模板的一部分被认为是最佳实践。这样，您可以在类似的应用程序中模板化和重用您的活跃度探测器配置。

开始时，最好在与您计划在生产中使用的应用程序类似的应用程序中部署旨在测试和演示您的活跃度探测配置的应用程序。为了说明这一点，下面我们将从 registry.k8s.io/busybox 的中选取一个示例图像，并使用命令执行方法部署一个带有活跃度探测器的静态 pod。

**### 活性探针配置的示例

在您的集群中应用这个 yaml 将部署一个示例 pod，它将在前 40 秒内成功，然后故意进入一个失败状态，在这个状态下，活性探测将失败，kubelet 将重新启动容器以恢复服务。

T2apiVersion: v1

T2kind: Pod

T2metadata:

T2labels:

T2test: liveness

T2name: liveness-example

T2spec:

T2containers:

T2- name: liveness

T2image: registry.k8s.io/busybox

T2args:

T2- /bin/sh

T2- -c

T2- touch /tmp/healthz; sleep 40; rm -f /tmp/healthz; sleep 700

T2livenessProbe:

T2exec:

T2command:

T2- cat

T2- /tmp/healthz

initialDelaySeconds: 6

T2periodSeconds: 6

了解活跃度探头设置

在上例中，Pod 只有一个容器。livenessProbe 属性下的字段和命令指定您希望 kubelet 如何执行健康检查:

• **initialDelaySeconds:**该字段指示 kubelet 在执行第一次探测之前等待的秒数；默认值为 0 秒，最小值为 0。在不影响应用程序性能的情况下，该值应设置得尽可能低。

• **period seconds:**该字段指定 kubelet 执行活跃度探测的频率，以秒为单位；默认值为 10 秒，最小值为 1。

• 超时秒数 :探头超时的秒数；默认值为 1 秒，最小值为 1。

• 成功阈值: 在一次探测失败后，这是一次探测被认为成功所需的最小连续成功次数；默认值为 1，最小值为 1，对于活跃度和启动探测，该值必须为 1。

• 失败阈值: 如果至少有这个数量的探测失败，Kubernetes 确定应用程序不正常，并触发该容器的重启(启动或活动探测)。kubelet 使用该容器的设置 terminationGracePeriodSeconds 作为该阈值的一部分。

• **terminationgraceperiodes:**在触发关闭失败的容器和强制容器运行时停止该容器之间，kubelet 必须等待的时间。默认情况下，它继承 terminationGracePeriodSeconds 的 Pod 级别值。如果未指定，默认值为 30 秒，最小值为 1。

• **/tmp/healthy:**kube let 执行命令 cat /tmp/healthz 在目标容器中执行探测。在容器生命周期的前 40 秒，该命令返回一个成功代码。之后，它返回一个失败代码。

对于 HTTP 和 TCP 探测，可以使用命名端口。一个例子是port: http.注意 gRPC 探测器不支持命名端口或定制主机。

在 Kubernetes 中使用活性探测器的最佳实践

成功的活动探测不会影响集群的健康状况。被探测的容器保持运行，并且在periodSeconds延迟之后安排新的探测。但是，如果探针运行过于频繁，会浪费您的 资源 ，还会对应用程序性能产生负面影响。另一方面，如果您的探测不够频繁，您的容器可能会在被处理之前长时间处于不健康的状态。

使用上面概述的字段和命令，根据您的应用对探头进行微调。一旦您知道您的活性探测器的命令、API 请求或 gRPC 调用需要多长时间才能完成，您就可以在您的timeoutSeconds中使用这些值(同时，考虑添加一个小的缓冲期)。对于简单、短期运行的探测，尽可能使用最小值。密集或长时间运行的命令可能要求您在重复之前等待更长时间，因此您将无法获得容器运行状况的最新视图。

还要确保探测命令或 HTTP 请求的目标独立于您的主应用程序。这确保了即使您的主应用程序失败了，它也可以向 kubelet 报告它的状态。如果您的活跃度探测器由标准应用程序入口点提供服务，那么如果它的框架失败或者它请求了一个不可用的外部依赖项，它可能会导致不准确的结果。

其他几个活跃度探针最佳实践:

1. 探测器受重启策略影响: 探测器后应用容器重启策略。您的容器必须设置为 restartPolicy: Always (这是默认设置)或 restartPolicy: OnFailure ，以确保 Kubernetes 可以在活性探测失败后重新启动容器。如果使用 Never 策略，则在活动探测失败后，容器将无限期地保持失败状态。

2. 每个容器都不需要探测器: 可以省略那些总是在失败和低优先级服务时终止的简单容器。

3. 不在 pid 1 上运行的作业是一个很好的 pod 受益于活性探测的例子。如果作业失败，我们希望它重新启动，以确保最近的运行是成功的，并且没有正在静默构建的工作队列。

4. 重新评估你的探头: 不要设置了就忘了。应用中的新优化、特性和回归会影响探头性能。确保定期检查探头，并根据需要进行调整。最精确的探测来自于从真实世界的度量中得到的设置。部署后重新访问您的探测器允许您根据历史性能调整您的探测器。

在 Kubernetes 中使用活性探针的优势

在 Kube 中使用活跃度探测器可以帮助您提高应用程序的可用性，因为它们可以让您持续了解容器中应用程序的健康状况。在某些方面，Kubernetes 可能会造成断开，因为虽然你的 pod 可能看起来很健康，但你的用户可能实际上无法访问你的应用和服务。活性探测帮助您验证您的应用程序、容器和 pod 是否都按照设计运行，并确保 K8s 在容器变得不健康时重新启动容器。

您可以使用开源工具，如 【北极星】 ，应用自动化来审计和修订 YAML 清单中发现的任何问题。在活性探针和就绪探针的情况下，Polaris 可能会留下注释，以提示用户根据其应用程序的上下文做出适当的更改。下面是我在 上演示一些基本示例的视频，使用fair winds Insights跨集群设置活性探测器 以确保可靠性，您可以使用它开始学习。

不同类型的健康检查可以帮助您在 Kubernetes 中执行活性检查和就绪检查。活性探测、就绪探测和启动探测都可以帮助您确保您的 Kubernetes 服务建立在良好的基础上，以便您的 DevOps 团队可以为您的应用和服务提供更好的可靠性和更长的正常运行时间。如果你开始有困难，在 Kubernetes 网站 上查看这个 教程。

Fairwinds Insights 使您的开发人员能够快速识别潜在问题，并主动预防 Kubernetes 中的停机或中断。 今天就试试免费等级吧！

**

Kubernetes 的一份概述称，正确的配置是省钱的关键

原文：https://www.fairwinds.com/blog/a-kubernetes-overview-says-proper-configuration-is-key-to-saving-money

在我们最近的白皮书《优化 Kubernetes 所有权的 5 种方法》中，我们讨论了与强大的服务所有权模型相关的众多好处。除了授权开发人员对其应用的质量负责，Kubernetes 服务所有权模型还优化了业务成功的五个关键因素，包括安全性、合规性、可靠性、可扩展性，当然还有成本优化。

当你停下来考虑 Kubernetes 服务所有权如何影响整体成本管理时，你必须考虑配置。它们之间有着千丝万缕的联系，因为 Kubernetes 的正确配置在组织花费的金额中起着重要作用。错误配置会导致额外的、完全可以避免的成本。这就是为什么服务所有者在建立资源分配之前必须了解应用程序的最终成本。然后他们必须确定金额是否符合他们的预算。

阅读我们最新的白皮书:

优化 Kubernetes 所有权的 5 种方法

分配成本

那么，Kubernetes 工作负载的实际成本是多少？答案不是特别简单。事实上，这可能非常困难，因为节点(您最终为其付费的对象)并不完全对应于您运行它们的工作负载。

首先，节点是短暂的，可以随着集群规模的扩大和缩小而创建和销毁，也可以在升级或出现故障时更换。为了增加复杂性，Kubernetes bin 根据它认为最有效地利用这些资源的方式将工作负载打包到节点中，就像俄罗斯方块游戏一样。因此，将特定的工作负载映射到特定的计算实例仍然具有挑战性。Kubernetes 中的高效 bin 打包是一个很好的成本节约方法，但是当一个给定节点上的资源被许多应用程序共享时，很难找到一个好的方法来分配成本。

合理调整资源

当团队将他们的应用程序部署到 Kubernetes 时，他们负责精确地设置应该为他们的应用程序分配多少内存和 CPU。这是经常出错的地方——团队要么没有指定这些设置，要么将它们设置得太高。

开发人员的工作是编写代码并快速发布，所以当他们面对可选的配置时——比如 CPU 和内存请求和限制——他们通常会简单地忽略它。这可能会导致可靠性问题，包括延迟增加甚至停机。此外，即使他们花时间指定内存和 CPU 设置，他们也倾向于分配过多的数量，因为他们知道自己的应用程序在有额外资源的情况下也能正常运行。从开发人员的角度来看，计算越多越好。

如果没有 Kubernetes 的成本控制和可见性，以及将这些信息提供给开发团队的可靠的反馈回路，Kubernetes 将只是尊重开发人员的 CPU 和内存设置，您会发现自己面临着一大笔云计算账单。尽管 Kubernetes 会通过以优化资源的方式将所有工作负载放在一起，尽最大努力与所有工作负载“玩俄罗斯方块”，但当团队不告诉它需要多少内存和 CPU，或者要求太多时，它只能做这么多。就像打败俄罗斯方块游戏一样，你需要做出明智的、充分知情的选择才能获胜。

看腻了？

观看我们的网络研讨会，了解 Kubernetes 中最常见的错误配置以及如何避免它们！

解决过去的问题

在 Kubernetes 之前，组织可以依靠云成本工具来提供对底层云基础架构的可见性。如今，Kubernetes 提供了一个新的云资源管理层，几乎就像传统云成本监控工具的一个黑匣子。因此，组织需要在 Kubernetes 的“引擎盖”下找到一种方法，在应用程序、产品和团队之间进行适当的成本分配。

云资源的这种清晰程度，通常是通过成本监控解决方案发现的，允许团队围绕 Kubernetes 所有权的财务做出更好的决策。没有它，组织很难在 Kubernetes 这样的动态环境中优化计算和工作负载。当试图做出明智的实时业务决策时，多个团队、多个集群和大量的复杂性会转化为大量的信息来审查和评估。

授权团队

采用服务所有权模型的组织使开发团队能够在生产中拥有和运行他们的应用程序，从而使 Ops 能够专注于构建一个出色的平台。这种转变要求团队在继续实施最佳实践时做出有效的决策。Kubernetes 服务所有权通过自动化、警报、主动建议和工具链集成等方式直接向工程团队提供必要的反馈，从而有助于提高效率和可靠性。

寻找一个完整的 Kubernetes 治理平台？Fairwinds Insights 是免费的。今天就开始吧。

这不仅仅是提高运输速度和降低风险。优化 Kubernetes 配置，使集群具有正确的 CPU 和内存请求和限制，有助于确保应用程序高效运行和扩展，从而避免资金浪费。

当团队可以构建、部署和运行他们的应用程序和服务时，他们拥有更大的自主权，与其他团队的交接更少。服务所有权带来的完整体验有助于开发团队更深入地理解他们编写的软件的客户影响和操作开销。服务所有权极大地改善了成本管理和协作，同时也降低了运行 Kubernetes 的复杂性。

为什么你需要 Kubernetes 安全政策的执行

原文：https://www.fairwinds.com/blog/addressing-kubernetes-security-vulnerabilities-with-policy-enforcement

保护 Kubernetes 是一个大话题，许多供应商都在解决这个问题。我们看到的安全挑战之一不仅仅是漏洞，而是执行策略来防范漏洞和其他安全问题。容器或底层 Kubernetes 基础设施中的错误配置可能会产生问题。

考虑一下我们看到的一些安全挑战，以及为什么需要执行 Kubernetes 策略。

应用程序漏洞

根据 DZone 的调查，78%的公司现在在 OSS 上运行部分或全部业务(2010 年上升到 42%)。而建立在开源项目上的 Kubernetes 社区肯定更高。问题是这些开源工具中的已知漏洞可能会被无意中注入到应用程序或容器中。

工程团队需要扫描容器的能力，以识别具有已知漏洞的 CVEs 和/或 OSS 组件/版本。然后，开发人员需要升级或修补这些组件来解决漏洞。

如果存在已知的漏洞，制定策略来防范这些漏洞是非常重要的。然而，执行是许多团队失败的地方。如何确保在不断变化的动态环境中应用所有容器策略？使用策略驱动的配置验证可以帮助识别哪里存在可能暴露 CVE 的错误配置。

平台漏洞

同样，底层 Kubernetes 集群和附加组件中也可能存在漏洞。需要不断地扫描和监控基础设施以发现新的漏洞，并根据需要修补以解决问题。

适当的权限

黑客使用的一种常见攻击手段是利用能够访问超出他们实际需要的系统资源的用户或服务，例如利用权限提升、“根”访问等。基于角色的访问控制(RBAC)可以强制实施最小特权的概念，即只授予对用户或服务所需资源的访问权，而不是更多。然而，要知道 Kubernetes 部署是否被超级用户过度许可，需要负责安全的团队手动检查每个 pod，以检查错误配置的部署。这个过程受益于贯穿整个开发生命周期的自动检查，以确保授予正确的特权。

入口/出口控制

当应用程序服务与应用程序内部或外部的其他资源进行通信时，还必须采取适当的安全措施来管理入站和出站通信。策略决定了允许哪些数据到达哪里，以及允许哪些服务相互通信。与 RBAC 类似，最佳实践是为网络和权限建立一个“零信任模型”,使通信只在需要的地方发生。这些政策必须实施。在 Kubernetes 中，策略即代码是最好的选择，但是面临的挑战是如何检查策略是否已经应用到每个集群。同样，如果没有自动化，这是一个耗时且容易出错的过程。

证书管理

SSL 证书用于加密网络流量，以保护传输的数据。这些证书需要轮换/更新/管理，以确保数据得到正确加密。

在 Kubernetes 中，cert-manager 作为一系列部署资源在集群中运行。它利用 CustomResourceDefinitions 来配置认证机构和请求证书。这种定制应该对照策略进行检查，以确保 CustomResource 具有从特权到能力等所有正确的安全检查。

Kubernetes 通过 Fairwinds Insights 实施安全策略

为了应对 Kubernetes 政策执行方面的挑战，我们开发了 Fairwinds Insights 。Fairwinds Insights 基于我们的开源工具，包括北极星，是一个策略驱动的 Kubernetes 配置验证平台。它确保在整个开发生命周期中，根据安全策略和其他最佳实践检查容器和 pod。这意味着用户不会意外地将群集暴露给 CVE，权限与策略一致，并且整个环境遵守策略。Fairwinds Insights 不仅使用 Kubernetes 策略执行来提高安全性，还为用户提供了效率和可靠性优势，以便集群能够适当扩展以避免停机，并控制成本。

您可以在自己的集群中免费体验 Fairwinds Insights！点击了解更多。

害怕 Kubernetes？以下是原因和应对措施。

原文：https://www.fairwinds.com/blog/afraid-of-kubernetes-heres-why-and-what-to-do-about-it

你仍然害怕 Kubernetes，这是为什么，以及该怎么办。

Fairwinds 总裁肯德尔·米勒(Kendall Miller)解释了为什么 Kubernetes 是新的、令人兴奋的，而且在这个系列中没有什么可怕的。从肯德尔·米勒的办公桌上，阅读为什么:

审计 Kubernetes 基础设施的更简单方法:自托管的 Fairwinds Insights

原文：https://www.fairwinds.com/blog/an-easier-way-to-audit-your-kubernetes-infrastructure-self-hosted-fairwinds-insights

我们很高兴地宣布，Fairwinds Insights 的自主发布现已进入测试阶段！

大约两年前，我们启动了 Polaris ，这是一个帮助团队将政策和最佳实践应用于 Kubernetes 资源的项目。该项目已经被 Kubernetes 社区迅速采用，我们似乎找到了一个很多组织都在纠结的痛点。来自成千上万用户的社区反馈导致了 Polaris 的大量改进，但也有要求更多企业友好的功能，这将违反 Polaris 的“做好一件事”的哲学；这些特性包括随着时间的推移跟踪调查结果、将行动项目分配给合适的工程师，以及将数据映射到 Slack、GitHub、Datadog 或他们的工程团队可能居住的任何地方。

为了满足这些需求，我们建立了一个 SaaS 产品， Fairwinds Insights 。Fairwinds Insights 可以从 Polaris 以及近十几个其他 Kubernetes 审计机构(如 Trivy、Goldilocks 和 kube-bench)获取数据，并将所有结果放在单一窗口中。到目前为止，Fairwinds Insights 已经帮助 200 多个组织更好地了解和强化了他们的 Kubernetes 环境，使他们更加安全、高效和可靠。

然而，我们发现一些 Polaris 用户的业务需求使其难以升级。他们喜欢 Polaris 完全在他们自己的环境中运行——不需要担心将数据发送给第三方。这种担忧在医疗保健和金融等数据敏感行业的企业中尤为普遍。

Fairwinds Insights 只能在 Polaris 之上增加价值，因此我们在过去几个月中努力构建了一个可以完全在客户环境中运行的 Insights 版本。更棒的是，我们已经免费提供了前 30 天！

它是如何工作的

要在您自己的环境中尝试 Fairwinds 的见解，您只需helm install:

(注意-目前，您需要与我们的团队联系以获得安装代码)

helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install fairwinds-insights fairwinds-stable/fairwinds-insights \
  --set installationCode=xyz

如果您已经在使用 Polaris，您也可以使用polaris.config参数传递一个现有的 Polaris 配置。如果您已经构建了一些自定义检查或配置了自定义严重性和豁免，这将很有帮助。

部署运行后，您可以通过运行以下命令来访问控制面板:

kubectl port-forward -n fairwinds-insights svc/fairwinds-insights-dashboard 8080:80

参见文档了解如何建立一个更永久的入口的细节，以及其他好的加固实践。

请注意，您仍然需要注册一个帐户-该应用程序将与我们的 SaaS 共享以下详细信息，以便跟踪您的试用持续时间和您的环境规模:

但就是这样！所有与安全性相关的数据，以及潜在的敏感信息，如命名空间名称、RBAC 角色和映像 sha，都是您环境的私有信息。

利弊

当然，托管自己的软件也会带来一些麻烦。虽然在您的环境中运行 Fairwinds Insights 很容易，但是如果您打算长期使用它，您可能需要花一些时间来强化您的安装。

赞成的意见

自托管部署的最大优点之一是安全风险。将漏洞数据发送给第三方可能会让安全团队不寒而栗，并且可能会阻止您以 SaaS 的身份尝试 Fairwinds Insights。它还有助于满足合规性要求，比如将数据集中存放在特定区域。

这带来了另一个好处——自托管安装更容易在内部销售。一些人告诉我们，在试用 SaaS 之前，他们必须通过安全审查，但他们可以立即开始使用自托管安装。我们希望这个选项可以减少对 Fairwinds Insights 提供的内容感兴趣的人之间的摩擦。

最后，通过自托管安装，您可以更好地控制升级到 Insights 新版本的方式和时间。我们只通过 SaaS 提供最新版本，所以如果你想确保用户界面永远不变，或者你不需要升级代理，自托管安装可能是有吸引力的。

骗局

自托管任何软件的最大缺点是，您现在要对运行它的基础设施负责。

首先，你需要确保一切都是安全的。幸运的是，Insights 会自我扫描，并提醒您由于配置错误或部署过时而可能出现的任何漏洞。

其次，可靠性可能会成为一个问题。Kubernetes 可以很好地自我修复，但您可能无法获得与使用 SaaS 时相同的正常运行时间。

最后，你需要有一个好的数据存储和备份计划。虽然 Insights 附带了 Postgres 和 Minio 的短暂实例，但您可能希望设置一个 RDS 实例和一个 S3 存储桶来进行更持久的存储和定期备份。

试试吧！

Fairwinds Insights 可供免费使用。你可以在这里报名。我们也很乐意听到您的体验反馈！如果你想取得联系，请随时联系我们的 Slack 社区或发电子邮件给 insights@fairwinds.com。

Flatfile 关于为什么 Fairwinds Insights: Kubernetes 配置验证的采访

原文：https://www.fairwinds.com/blog/an-interview-with-flatfile-on-why-fairwinds-insights-kubernetes-configuration-validation

Kubernetes 最大的优点之一是每个使用它的公司都在改变他们的业务。我们的客户之一 Flatfile 将在 2021 年实现巨大增长，因为他们投资解决与海量数据相关的问题——这一类别被称为数据入职。正如 VentureBeat 所描述的，“Flatfile 扮演的基本角色是数据看门人，这有点不光彩。”

该团队开发了一个 API，可以帮助公司在几个小时内导入数据(而不是几天、几周或几个月)。当然，支持公司的目标需要可扩展和安全的基础设施。

我们最近虚拟地会见了 Flatfile 的基础设施主管 Robert Trencheny，询问了一些关于他的职业生涯、Kubernetes 和 Fairwinds Insights 的问题。

您是如何进入基础设施运营并最终进入 Flatfile 的？

高中一毕业，我就在东海岸的一家大型数码公司找到了一份工作。我在 2010 年建立并维护了海斯曼奖杯网站。那是他们第一次决定在网站上宣布获胜者，同时亲自颁发奖杯。那时我开始关注基础设施，因为看着 1000 万人同时访问一个网站，显然所有的东西都会立即失效，这真是太疯狂了。在那之后，我共同创立了 Hackbright Academy，向女性教授 Python，帮助她们在这个行业找到好工作。我们在 2016 年卖掉了它，那时我已经去了其他创业公司和项目。

让我真正进入基础设施领域的项目是 Gyroscope，这是一家健康数据初创公司，我在那里建立了他们最初的数据基础设施。他们开始时只有几百个用户，但每天有数十亿个数据点。你必须通过一个巨大的数据管道来处理它，以建立一个完美的系统。在那之后，我继续建立了 Campuswire，一个大学交流平台。在那里担任首席工程师几年后，我继续与人共同创立了 BloomJoy，该公司与社交媒体有影响力的人合作，帮助他们通过编写品牌内容来实现受众货币化。我们为这些有影响力的人建立了网站，其中一些进入了 Alexa 前 50 名的排名，这显然带来了大量的挑战。

然后我去了 Flatfile，因为我认识这位首席执行官和其他团队成员并与之共事多年。我是基础设施的负责人，也是内部工具和 IT 的负责人。我们正在 招聘 在 2021 年使我们能够快速增长。

如你所说，你不仅要负责 Flatfile 的基础设施，还要负责内部工具和 IT。你如何看待 Kubernetes 和 containers 作为 Flatfile 未来增长的一部分？

容器才有意义。这是新的常态，让事情变得简单多了。例如，我们正在与几家公司合作，他们构建了自己的工具集来帮助客户将数据吸收到现有的应用程序中。我们无法为他们进行传统的内部部署，而且由于合规性问题，他们也无法使用我们的云产品。容器允许我们在两个或三个环境变量中为客户提供原始的 Docker 图像。十年前，这是不可能的——你要给出 60 个不同的 bash 脚本，希望能把一切都设置好。

特别是对于 Kubernetes，我们仅仅触及了表面——基本上是用它作为 Heroku 的替代品。我们的工程目标是启用用户驱动的数据管道，以允许用户实际编写功能代码来控制数据应该如何变异或转换。这意味着我需要让代码运行在不可信的环境中，大规模地运行它，并在从 500 字节到 5 TB 的文件上运行它。

能够配合 AWS 工具将数据发送到正确的位置，有一个中央平面来监控一切，并确保我们没有任何安全问题，这将是 Kubernetes 对我们的强大支持。这是实现这一规模的关键基础。

我们还将采用多区域和私有云。容器使它变得更容易，因为我们可以设置一个容器，并且可以很容易地跨多个区域复制。我们使用 Terraform 完成所有的配置，因此拥有一组简单的 Terraform 文件就可以将容器部署到 Kubernetes 集群，这是非常强大的。

今天，作为 Kubernetes 和 containers 持续管理的一部分，您开始利用哪些有趣的开源工具？

现在，我们正努力保持与 Kubernetes 最佳实践的紧密联系。但有一件事不一定是最前沿的，但我每天都要感谢的是运营商。具体来说，我们喜欢使用 Prometheus 操作符，因为它只负责我们的监控堆栈，而不需要我们自己动手做任何事情。我们希望扩大运营商和云连接器的使用。

今年，你将为 Flatfile 增加许多工程师和团队。请告诉我更多关于你在基础设施、容器和 Kubernetes 上看到的问题，以及你将如何解决它们？

这是我们成长的一年。我们正转向使用集装箱来运营整个公司。我们将在 Docker 上运行的 bs 代码上实现标准化，在 Kubernetes 上实现标准化，并拥有系统，以便我们的工程师能够快速理解它们。

我最担心的事情，也是让我夜不能寐的事情是合规。我需要确保只有某些人拥有集群和代码的最低权限。出门前，我需要确定每样东西都经过了双重和三重检查。我们处理敏感数据，因此合规性是我们业务的一大要求。我们符合 HIPAA、GDPR 和 SOC 2 标准，但随着我们越来越多地进入美国联邦政府，将会有更多的要求。

规模和安全性问题已经解决，但确保您有一个集中的方法来监控并确保没有恶意行为发生，并且能够在发生违规时做出响应，这是一个巨大的问题。

这是赛格威对 Fairwinds 洞察的一次伟大尝试。自我们推出以来，您一直是早期采用者。Fairwinds Insights 帮助您解决的关键业务问题是什么？

Fairwinds Insights 是一套帮助我晚上睡得更好的产品。我不必主动监控洞察力，但我知道如果出了问题，我会得到通知。因为 Fairwinds 在不断改进产品，所以我不用担心不断地调整和调整东西。我知道你会为我留意最好的情况。

老实说，Fairwinds Insights 给了我内心的平静。松弛通知会提醒我，如果我们发现问题，我们会快速修复它。这太棒了，因为这意味着我们现在每周要接收数亿行数据。我还没有雇佣全职安全工程师。对我们来说，Fairwinds 就像是等式的一半，而另一半是 Sqreen。拥有这个有效的安全毯对我们来说意义重大。

根据您对 Fairwinds 的见解，今天的进展如何？

在仪表盘中，当我点击一个警报时，你不会只是给我一个简单的解释，然后期望我自己想出如何修复它。你实际上告诉我这是你解决它的方法或者至少尽可能接近它。仪表板对我来说真的很重要——它是一个很容易使用的工具，而且直觉很快。

你提到 Fairwinds Insights 和 Sqreen 等其他产品帮助你获得了内心的平静。与该领域的其他产品相比，您如何看待 Insights？

我对此没有做过大量的市场调查，因为我被 Insights 所做的一切以及它对 Kubernetes 的绝对关注所震惊。

fair winds 如何帮助您解决合规问题？

我们正在与一家大型企业客户签约。我们正处于独立委员会三次审查中的第二次。我可以对他们说，我们有一个持续的监控解决方案，可以确保平面文件基础设施按照最佳实践运行，并且一切运行良好——这是一个巨大的增值。如果没有 Fairwinds，我将需要依赖团队中的基础设施工程师或不是为 Kubernetes 构建的技术。

洞察力在你的 CI/CD 渠道中有什么价值？

我们还不可能使用它，但是它的价值是巨大的。能够确保我们在投入生产时不会遇到任何不应该出现的问题，这具有巨大的价值。我喜欢这个工作流程。

让你安心的洞察力的确切功能是什么？

它知道，如果出现问题，我会得到一个宽松的通知。当我今天早上醒来时，我做的第一件事就是查看我们的基础架构警报频道，我在那里看到了五个新的见解警报。我的一个基础设施团队成员点击了进来，只需一个拉取请求就很快解决了问题。通知对我们很重要。

Fairwinds Insights 公开测试计划宣布

原文：https://www.fairwinds.com/blog/announcing-fairwinds-insights-public-beta-program

我们很高兴地宣布，我们的新 SaaS 平台 Fairwinds Insights 已经推出了免费的公共测试程序！Fairwinds Insights 是一个开源的服务平台，面向管理多个 Kubernetes 集群并需要了解潜在问题的 DevOps 团队。

这个基于云的平台有一个可扩展的框架，可以为 Kubernetes 插入优秀的开源审计工具。我们的免费测试层推出了一套精心策划的开源安全、可靠性和审计工具:Fairwinds Polaris、Fairwinds Goldilocks 和 Aqua Security 的 Kube-hunter 都是开箱即用的集成。

【Fairwinds Insights 解决了什么问题

Fairwinds Insights 解决了运行 Kubernetes 的 DevOps 团队面临的一些问题:

• 首先，它消除了研究、学习和部署优秀的 Kubernetes 审计工具的耗时过程。
• 其次，它自动组织和标准化来自每个工具的数据，因此工程师可以在所有集群中获得优先推荐。例如，beta 程序中包含的每个工具都专注于一个特定的领域。调查结果按照问题的类型和严重性进行了组织，这样就很容易看出什么是最重要的。
• 最后，它使开发运维团队能够主动管理从开发到生产的移交。

在过去的几个月里，我们一直在与早期采用者密切合作，以塑造产品愿景和方向。我们现在扩大了对任何目前运行 Kubernetes 并希望进一步了解安全性和可靠性改进的 DevOps 团队的访问。

报名测试

在测试期间，早期采用者将有机会提交反馈，并与 Fairwinds 产品团队密切合作。测试程序仅限于七天的数据历史，最多两个集群。在正式发布时，该平台将提供一个免费层(beta 用户将过渡到该层)，以及一个具有额外企业功能的商业层。

注册很快，并提供即时访问平台-查看fairwinds.com/insights了解更多详情。我们期待与您合作！

宣布北极星快照

原文：https://www.fairwinds.com/blog/announcing-polaris-snapshot

Two months ago at Fairwinds (formerly ReactiveOps), we launched Polaris, an open source dashboard for auditing Kubernetes workload configuration. We saw a great response from the community, and have been hard at work keeping up with all the interesting ideas and use cases that have come in since launch.

例如，一个常见的反馈是，虽然 Polaris 非常擅长审计实时集群中的工作负载，但许多人希望能够在问题被签入他们的基础架构即代码存储库之前发现问题。所以我们修改了 Polaris 来审计本地 YAML 文件，并添加了几个新的标志来简化 CI/CD。现在您可以在您的 CI/CD 管道中运行这样的东西:

polaris --audit-path ./deploy --set-exit-code-on-error -set-exit-code-below-score 90

如果 Polaris 检测到任何错误级别的问题，或者如果您的 Polaris 得分下降到 90%以下，管道将会失败。

However, there was one useful feature we found difficult to implement: an easier way to share Polaris reports. To help address this need, we’re excited to announce a new service: Polaris Snapshot. Polaris Snapshot will let you generate a report, hosted at polaris.fairwinds.com, that you can share with your team. We see this as a great way for teams to sync on how to make their Kubernetes workloads more stable, efficient, and secure.

为什么是北极星？

在 Fairwinds，我们与几十个开发团队合作，将数百个应用程序发布到 Kubernetes 集群中。通常，我们承担与集群本身相关的工作 (例如 处理集群升级，维护工具，如入口和证书管理，响应中断)，而开发团队负责需要应用上下文的一切 (例如 编写部署配置，设置 CI/CD)。但是对于不完全熟悉 Kubernetes 的开发人员来说，很容易忽略应用程序的 Kubernetes 配置的一些关键部分。

例如，您的部署在没有准备就绪和活动探测的情况下，或者在没有资源请求和限制的情况下，可能看起来工作得很好。但是如果没有这种配置，Kubernetes 就很难做它最擅长的事情——确保您的应用程序保持健康并高效地伸缩。我们帮助团队应对的许多中断和性能下降都是由一些问题引起的，这些问题可以通过构建更坚固的应用程序配置来轻松避免。

北极星旨在缓解平台工程团队和应用开发团队之间的这种交接。 我们专门针对可能导致扩展性、稳定性、效率和安全性问题的应用配置问题。Polaris 得分每增加一分，您经历停机、安全漏洞或性能下降的机会就会减少一分。

为什么要拍北极星快照？

一旦我们完成了 Polaris，是时候在我们客户的集群中实际运行它了。在会议前设置一个临时仪表板很容易，但是我们不想让一个不必要的流程在每个客户的环境中运行，不管它有多小和多便宜。并且报告会根据新的部署而改变的事实可能会导致误解。

我们需要的是一种生成一次性报告的方式，即特定时间点的集群状态快照。这份报告可以被保存、传阅和讨论，因为我们制定了一个计划来优先处理 Polaris 发现的问题。

不幸的是，在 Kubernetes 中安全地维护持久状态 c 可能会很复杂，所以像这样的特性似乎超出了开源项目的范围。我们尝试简单地将仪表板保存为 PDF 格式，并展开每个警报。结果还可以，但是对于一些客户来说，导致报告长达几十页，很难浏览。

最后，我们选择了北极星快照作为发布北极星报告的方式。这不仅解决了我们眼前的问题——它还推进了 Fairwinds 的使命，使组织能够轻松地操作生产级 Kubernetes 集群。

它是怎么工作的？

北极星快照运行于(注: 您需要输入您的电子邮件地址以 生成报告。虽然我们不能为您提供免费午餐，但我们承诺尊重您的收件箱)。当您到达时，Snapshot 将为您生成一个新的会话，它是一个长的、唯一的 ID。然后你会看到一个kubectl命令运行，类似于:

kubectl apply -f https://polaris.fairwinds.com/session/e0475993dc407007418319ca468d25ff/yaml

该命令将下载北极星，运行一次，将结果发送回，然后自行卸载。我们建议在将 YAML 文件传递给ku bectl apply之前检查它——您会看到 Polaris 只需要最低限度的 RBAC 权限，并且在一个临时的、唯一的名称空间中运行。

一旦审计完成并且 Polaris 从您的集群中卸载，您的报告结果将自动出现在 https://polaris.fairwinds.com/session/YOUR_SESSION_ID。您可以与您的队友分享此链接，以帮助协调和优先考虑补救工作。该网址将在 90 天内保持有效，之后我们将完全删除您的数据。您也可以随时手动删除数据。

未来工作

We’ve got big plans for Polaris in the future. We’ve just published the Q3 Roadmap, which includes a few exciting new features:

• 我们将开始检查更多类型的资源，而不仅仅是部署——我们将支持 StatefulSets、Jobs、CronJobs 和 DaemonSets。
• 我们将添加对豁免的支持，这将允许您指定，例如，您的一个部署确实需要以 root 用户身份运行。如果你给它一个豁免，这将不再影响你的北极星分数。
• 我们将在 探讨让你创建 自己定制北极星支票的方法

We’re also quite interested in expanding Polaris Snapshot to include features that are difficult to implement as part of an open source project - things like saving report history, multi-cluster management, and email/Slack alerts for degradations. If you’re interested in Polaris and would like to help us plot the course forward, reach out to opensource@fairwinds.com or get in touch on GitHub!

再看亚马逊弹性搜索服务

原文：https://www.fairwinds.com/blog/another-look-at-amazon-elasticsearch-service

亚马逊弹性搜索服务 是一项托管服务，旨在简化 AWS 云中弹性搜索集群的部署、操作和扩展。当亚马逊 Elasticsearch 服务于 2015 年 10 月日 发布后不久，我们第一次看到它时，我们并没有留下很深的印象。Amazon Elasticsearch 服务的几个方面和功能当时没有满足我们或我们客户的需求，其中主要的是提供的相当过时的版本和有限的访问控制。

我最近又看了一下，许多观察结果令人惊讶(这些观察结果是基于运行 Kubernetes 5.1.1 的集群)。下面，我将重点介绍一些观察结果，包括支持的版本、访问控制和更多专用的主选择，以及一些附加功能。

支持的版本

总的来说，Elasticsearch 现在比它第一次发布时更流行。 AWS 现在提供三个版本的 Elasticsearch，这是我注意到的最大变化。亚马逊 Elasticsearch 服务目前支持 elastic search 1.5、2.3 和 5.1 版本。需要 1.x 版本的用户可以使用 1.5 版本。如果支持最新的 1.x 版本(1.7)就好了，但至少它支持软件的遗留版本。也就是说，让我们面对现实吧——即使是 Elastic 也不再支持那个版本了，所以升级是明智的。

2.3 版是 2.x 系列的发行版。同样，它不是最新的(2.4 是撰写本文时的最新版本)，但它比 1.x 更接近当前版本。我怀疑亚马逊会将该版本升级到 2.4，该版本最初于 2016 年 8 月发布，最近的补丁来自当年 11 月。

大多数努力都集中在 5.1 版(2016 年 12 月)上。5.2 版本于 2017 年 1 月发布。我认为，用不了多久，5.2 就可以在亚马逊上买到了。

对于许多用例来说，这些版本可能就足够了。

访问控制

在访问控制方面，变化不大。你有三个选择:

1. 用户访问(选择 IAM 或 AWS 用户/角色)
2. 基于 IP 地址的白名单
3. 签名的请求

关于用户的文档写得很巧妙。它明确指出您需要一个 AWS 帐户(即 root)或一个 IAM 用户。我尝试了一个我们用于实例的 IAM 角色，虽然我能够指定角色，但是访问不起作用。处理这个问题的最好方法可能是让特定的 IAM 用户用于特定的目的，然后使用密码。

使用 IP 地址白名单的访问非常有效。这是让事情运转的最简单的方法。需要注意的一点是，Elasticsearch 实例并不在您的 VPC 中，因此流量总是会到达外部地址。这感觉有点难看，但很实用。请注意不要向任何地方开放白名单的警告。如果您的实例在 VPC 中是私有的，那么将 NAT 网关的 IP 地址列入白名单就很好了。

签名请求可能是最强大的，但也是最难实现的。我不会在这里详细说明，只是说对于我们的用例来说，这意味着大量修改我们客户的代码，这是我们通常不做的事情。还有，卷发也不行。

一旦您限制了谁可以访问，就他们可以访问的内容而言，您还可以做更多的事情。Amazon 允许您限制 URI 路径、HTTP 方法等等。所有这些能力可能对用户访问或签名请求最有用。

最终，签署的请求将使您获得最大的控制权，但是它们需要一些努力。

更多专业主选择

Amazon 还增强了关于专用主节点的设置，用于提高集群的稳定性。现在可以指定实例数量和类型了。这是一个很好的功能。拥有三个 t2.small.elasticsearch 实例可以降低成本，并在试图避免大脑分裂时提高信心。

附加功能

Elasticsearch 的 AWS 控制台非常不透明，不能让你看到引擎罩下的一切。似乎当您使用相同的设置更新集群时，它仍然会更新内容。这似乎包括更换引擎盖下的所有实例。这有点沉重，但是我在测试中没有发现实际更新的问题。

对集群进行更改似乎需要一段时间。至少需要 10 分钟，这也适用于访问权限的更改。然而，这些变化似乎没有问题。我测试了增加和减少实例数量，使用不同的实例类型(主节点和节点)以及添加和删除 EBS 卷。所有这些行为都干净利落地发生了(尽管，同样，并不迅速)。一个很好的特性是，如果您正在减少实例数量或存储大小，AWS 将检查以确保您有足够的空间。虽然我没有对这个特性进行广泛的测试，但它确实阻止了我在几次测试中试图将太多的数据塞入太少的空间。

也就是说，当我更改 IP 白名单时，发生了一件奇怪的事情。有一段时间，我在收到拒绝许可的错误和成功之间交替，这表明 Amazon 正在使用保守的方法来替换实例。换句话说，在删除现有实例之前，会完全添加新实例。我猜这种方法是从现有资源中适当地腾出数据。这是一个很好的接触。

摘要

总体而言，亚马逊 Elasticsearch 服务已经取得了长足的进步。它仍然没有包括几个令人高兴的功能，包括在 VPC 中运行 Elasticsearch 域的能力和 IAM 的完全集成。尽管如此，这是一个非常可靠的系统，可能非常适用于许多用途。

你对 Kubernetes 有这 5 个不同意见吗？你应该害怕！

原文：https://www.fairwinds.com/blog/are-you-having-these-5-disagreements-about-kubernetes

随着我们迈向 2023 年，这是一个思考如何使用技术堆栈的好时机，尤其是 Kubernetes。许多组织在 2020 年加入了 Kubernetes，促使全球疫情更多地采用云。如果你是他们中的一员，在将更多的应用程序迁移到云上之前，你可能已经从一个试验项目开始了，并且你可能已经不再回头了。现在事情已经稍微稳定下来，这是一个更仔细地思考你如何使用 Kubernetes 的好时机，并对你在匆忙中可能错过的这五个分歧(或讨论)进行一些思考。

1.让您的 CEO 访问您的 Kubernetes 环境

如果你有一个人的组织，或者如果你是自由职业者，并且是一个 Kubernetes 顾问，你可能应该能够访问你的 Kubernetes 环境。在几乎所有其他情况下，这可能是个坏主意。

尤其是在小型创业公司中，权限可能是一个非常敏感的话题。您可能已经开始与公司中的每个人一起构建应用程序或服务，并部署到 Kubernetes。但从长远来看，这是不可持续的。也许你的首席执行官是前首席技术官，喜欢插手这个游戏，但随着公司的发展，这真的不太理想。作为首席执行官，你不需要插手基础设施的每一个细节，包括 Kubernetes。许多 CTO 也不需要这种级别的访问权限。

另一方面，您的开发人员确实需要了解他们正在部署的环境以及它是如何工作的。您的开发团队对 Kubernetes 的理解越好，他们在编写部署到该环境中的代码时就会做得越好。这将帮助他们部署更稳定的应用程序。它还可以帮助您的团队将 Kubernetes 安全性整合到开发过程中，并将其进一步左移，使您的应用程序更加安全。由于您的开发人员了解应用实际运行的环境，这将改善他们的编码方式，并支持一种 Kubernetes 服务所有权 方法。就谁应该——谁不应该——访问您的 Kubernetes 环境(以及为什么)进行深思熟虑的讨论，是在您的组织中提高 Kubernetes 成熟度 的重要一步。

2.将所有服务部署到您的 Kubernetes 环境中

一些组织采取的方法是只使用内部构建的服务和工具，然后他们可能希望将所有这些东西放入 Kubernetes。这在一些大型组织中可能行得通，比如网飞或谷歌，他们的工作产生了很多开源工具，这对开源社区来说非常好。然而，一般来说，使用最适合这项工作的工具是最有意义的。如果服务或工具不是你的核心竞争力，不是让你的公司赚钱的东西，你可能不应该花很多时间自己构建、维护和运行它。那会分散你的注意力，而你应该做的是让你的组织更加成功。

已经有很多解决方案来运行您的数据库、队列和电子邮件服务。他们有经验丰富的大型团队作为后盾。你可能应该使用那些专门构建的服务，因为它们有效。例如，在 Kubernetes 集群中运行的 MySQL 和 Amazon 使用【RDS】运行关系数据库的方式有很大的不同，因为这是该团队专注于做好的事情——快速、轻松地在云中设置、操作和扩展关系数据库。如果您发现自己正在解决新的问题，这样您就可以构建它，以便它更好地为您试图构建的东西工作，那么将该服务部署到您的 Kubernetes 环境中可能是合适的。对于绝大多数公司来说，尤其是中小型公司，这很少有意义。

3.让您的开发人员负责所有事情 —一直到生产

当你雇佣一个新的开发者时，你要做的第一件事不是让他们访问 所有的 ，希望如此。让开发人员对他们的应用程序、工作负载服务等拥有所有权肯定有好处。实际上，您的开发人员最了解需要如何配置，代码如何工作，以及部署后它们将如何工作。但是为了让开发人员更有效率，你还需要额外的工具来帮助他们完成这个过程。

众所周知，Kubernetes 可能是一个复杂的环境，它需要大量的培训来帮助开发人员快速高效地使用它，或者您需要使用工具来帮助他们。工具可以将 正确的护栏放置在 的位置，以便开发人员在将服务部署到 Kubernetes 时能够遵循 的最佳实践。

如果你雇佣一个什么都能做的工程师——他们知道 Kubernetes、observability、CI/CD、前端和后端开发以及数据库，并让他们拥有从生产到销售的所有东西——那将是相当不寻常的。但是，如果你有一个人，每个人都去找他们，作为唯一知道如何解决(所有)问题的人，他们将很难做好每一件事。相反，如果你 让你的开发人员 部署并拥有他们自己的服务，直到生产，他们可以负责他们真正理解的所有部分，而其他人可以负责以合理和负责的方式帮助他们做到这一点。

4.让您的 CTO 保留对各个容器中 SSH 的访问

如果你让你的 CTO SSH 进入生产中的单个容器，请停止。在生产环境中，应该没有人能够执行容器。Kubernetes 的目标是创建不可变的基础设施，其中组件被替换而不是改变。如果你是:

• 编写发行版或从头开始的安全容器
• 部署不臃肿的容器
• 在您的集群中使用良好的工具来实现可观察性
• 将您的日志运送到某个地方

那么您根本不需要 SSH 到生产容器中。

请记住，Kubernetes 并不是让一台机器永远健康地运行。在 Kubernetes 中，你可以使用 Kube control 登录或杀死一个 pod 并旋转另一个 pod。你没有理由担心每个单独的容器。这是 Kubernetes 促成的范式转变的一个非常重要的部分。在过去，太多的故障排除过程都涉及到将一台机器 关闭再打开 。嗯，Kubernetes 会自动为您做这些，以保持事情顺利运行。在一些组织中，由于组织的规模以及您自己独特的部署和环境，您可能需要能够 SSH，这就是为什么这是一个重要的讨论或争论。然而，对于大多数组织来说，您不需要 CTO 来保持对单个容器的 SSH 访问。

5.忘记您的云成本

传统观点认为，你不需要担心你的云成本，声称它总是比拥有自己的基础设施便宜。你可能处于这样一个位置:你的销售非常好，你的应用和服务根据需要进行扩展，并且你的云成本随着你的收入一起上升是可以接受的。但是，了解您的云支出成本仍然很重要。

了解您的足迹的单位成本(无论是按集群、按客户、按收入还是其他衡量标准)非常重要。虽然很难达到这样的粒度级别，尤其是在共享的多租户环境中，但是您需要知道单位成本何时增加，以及增加的速度是否合适。

云的魅力在于它很容易增加新的工作负载，但获得可见性却不容易。您能判断您是否有流氓工作负载吗？有人黑进去启动 bitminer 了吗？获得一个可以显示您的 Kubernetes 集群、工作负载、名称空间等的成本的工具，对于帮助您了解您的支出以及您如何 在 Kubernetes 中支出(并帮助您调整集群规模)至关重要。

解决 Kubernetes 挑战

无论您是 Kubernetes 新手还是已经使用了很长时间，您都知道这是一个提供了很多灵活性和可伸缩性的复杂软件。尽管如此，还是很容易忘记停下来想想你是如何设置的，或者谁可以访问什么。您应该进行我在这篇文章中概述的讨论，因为 Kubernetes 的使用和部署很少是非黑即白的。几乎任何事情都没有正确或错误的答案。因为它与您的 Kubernetes 环境有关，无论这项技术有多热门，它被广泛采用，每个人都在使用 Kubernetes，请记住，并不是 Kubernetes 中的所有东西总是一个好主意。

观看网上研讨会 关于 Kubernetes 你应该有的 5 个分歧以及如何解决 欣赏比尔·莱丁汉姆(CEO)、肯德尔·米勒(技术布道者)、伊莉莎·赫伯特(工程运营副总裁)和安迪·苏德曼(首席技术官)之间有趣的讨论。

使用 letsencrypt 和 cert-manager 为 Kubernetes 提供自动 SSL 证书

原文：https://www.fairwinds.com/blog/automated-ssl-certs-for-kubernetes-with-letsencrypt-and-cert-manager

你是否梦想过有一天，当一项新服务出现时，会自动创建并更新免费的 TLS 证书？那一天已经到来。如果你已经跳上了酷车，正在生产 Kubernetes，那么 [cert-manager](https://github.com/jetstack/cert-manager) 是必须拥有的。 cert-manager 是一个在 Kubernetes 中自动创建和管理 TLS 证书的服务，它就像它的声音一样酷。

这里有一个 kubernetes 证书管理器教程，可以帮助您启动和运行。

设置证书管理器概述

要在 kubernetes 集群中实现这一设置，有 3 个主要环节:

1. cert-manager 服务确保 TLS 证书有效、最新，并在需要时更新。
2. 定义要使用的证书颁发机构的 clusterIssuer 资源
3. 定义应该创建的证书的证书资源

以下步骤假设 nginx-ingress 控制器 正在 kubernetes 集群中运行，并且有一种创建 DNS 记录的方法。另外，假设 舵 已安装。

这里是一个 Kubernetes **cert-manger** 教程，帮助您在 Kubernetes 集群中启动和运行。

1. 从 官方掌舵图启动证书管理器
2. 创建一个 lets encrypt CAcluster issuerk8s 资源
3. 在 kubernetes 集群中启动一个应用程序(带有入口),以便在 TLS 端点进行访问。
4. 创建一个 证书 对象，描述如何为测试应用程序创建 TLS 证书

设置证书管理器的详细信息

以下是更详细的步骤:

1. 部署 [cert-manager](https://github.com/kubernetes/charts/tree/master/stable/cert-manager) 舵图。创建values . YAML文件然后运行: helm-install --name my-release -f cert-manager-values.yaml cert-manager。cert-manager 可以配置为通过 Ingresss 上的批注自动为 Ingres 资源提供 TLS 证书。这就是我如何设置 cert-manager 的，因此，我在 values.yaml 文件中添加了两个设置ingressShim.defaultIssuerName 和 ingressShim.defaultIssuerKind。点击阅读更多关于Ingres shim 的内容。参见我的价值观文件 此处。
2. 创建 letsencrypt CA 集群发布者 。在这里，我使用 letsencrypt staging ACME 服务器只是为了测试，一旦成功，我将切换到 letsencrypt 生产服务器。我通过运行创建了以下文件: kubectl create -f letsencryp-clusterissuer-staging.yaml 。

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    # The ACME server URL
    server: [https://acme-staging.api.letsencrypt.org/directory](https://acme-staging.api.letsencrypt.org/directory)
    # Email address used for ACME registration
    email: [myemail@gmail.com](mailto:myemail@gmail.com)
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
    name: letsencrypt-staging
    # Enable the HTTP-01 challenge provider
    http01: {} 

3。创建一个配置了 TLS 的测试应用程序。创建 kubernetes 清单文件(我在这里创建了一个掌舵图)包括一个 部署服务 ，以及 入口 。入口需要 注释 来告诉 cert-manager 使用什么 CA 来创建 TLS 证书。域 example-nodejs.mydomain.com 必须有一个 DNS 记录，该记录被配置为向 nginx 入口控制器负载平衡器发送流量。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt-staging
spec:
  tls:
  - hosts:
    - example-nodejs.mydomain.com
    secretName: example-nodejs-crt
rules:
- host: example-nodejs.mydomain.com
  http:
    paths:
    - path: /
      backend:
        serviceName: example-nodejs
        servicePort: 8080 

4.创建 [certificate](https://github.com/JessicaGreben/example-nodejs/blob/master/deploy/charts/example-nodejs/templates/certificate.yaml) 资源，并配置 极致 http 挑战 。

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: example-nodejs-crt
spec:
  secretName: example-nodejs-crt
  dnsNames:
  - example-nodejs.mydomain.com
  acme:
    config:
    - http01:
        ingressClass: nginx
      domains:
      - example-nodejs.mydomain.com
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer

创建此资源后，应该会创建一个 tls 证书。如果没有，请检查 cert-manger 服务的日志中是否有错误。

一旦所有这些部分都设置好了，当您试图在浏览器中访问应用程序时，仍然会得到一个错误，因为证书是使用 临时 letsencrypt 服务器 创建的，但是这仍然显示证书 已成功创建 。

一旦设置成功，则创建一个 生产集群发布者 ，并用集群发布者替换对 letsencrypt-staging 集群发布者的所有引用。

有趣的额外背景信息:

什么是 letsencrypt？ Letsencrypt 是一个颁发免费 TLS 证书的认证机构。它于 2016 年推出，其目的是通过使使用 TLS 变得更容易和更便宜，来尝试建立一个更安全的互联网。

什么是 极致协议 ？ ACME 代表自动化证书管理环境。它是一种用于自动化 认证机构 及其用户的 web 服务器之间的交互的协议，允许以非常低的成本自动化部署 公钥基础设施 。它是由 互联网安全研究小组 (ISRG)为他们的 让我们加密 服务而设计的。

资源:

AWS Karpenter 就绪性:确保您为迁移做好准备的 6 种方法

原文：https://www.fairwinds.com/blog/aws-karpenter-readiness-6-ways-to-make-sure-youre-ready-for-the-move

对于熟悉 Kubernetes 的人来说，您已经知道它有许多可用的配置，要么是可扩展的，要么是性能更好的。过去，大多数组织使用 Kubernetes 的 集群自动缩放器来帮助他们根据工作负载需求自动扩展 EKS 集群节点池。根据您为节点池指定的最小和最大大小，群集自动缩放器会在需求高时添加节点，在需求低时将节点减少到最小大小。AWS kar penter是由亚马逊网络服务(AWS)打造的开源集群自动缩放器，旨在根据 AWS 环境中的应用工作负载，帮助提高应用可用性和集群效率。

AWS Karpenter 比 Cluster Autoscaler 好吗？

Cluster autoscaler 和 Karpenter 基于对更多容量的需求添加节点的方式类似。Cluster autoscaler 依靠用户做出更多决策来动态调整其集群的计算能力。使用 cluster autoscaler 时，您需要评估不同集群和节点中所需的容量类型，并决定需要调配哪些类型的实例。最初做出这些决定并不容易，因为你不知道这些答案，你需要花费大量的时间和精力来做出这些决定并更新它们。

AWS Karpenter 是 AWS 自带的 cluster autoscaler 的一个更智能的版本，它消除了使用 Cluster Autoscaler 时的一些猜测。kar penter 网站 将其描述为“任何 Kubernetes 集群的即时节点”Karpenter 的设计目的是根据集群的应用程序自动启动合适的计算机资源，而不是要求操作员预先做出大量决定。这有助于使用 Kubernetes 的组织做出更有效的决策。但是真的那么容易吗？您和您的应用程序准备好迁移到 AWS Karpenter 了吗？以下是你搬到 Karpenter 之前需要了解的六件事。

1.整合节点

作为一个自动缩放器，Karpenter 通过注释、节点选择器和其他配置选项为您提供了灵活性，从而可以轻松地进行缩放。需要注意的一点是，如果 Karpenter 发现有机会根据价格、节点数量或其他考虑因素创建更好的节点配置，它可以整合到更少的节点。这意味着 Karpenter 可能一直在摆脱节点。

您希望 Karpenter 能够整合您的 pods，因此您不希望设置注释，使应用程序不会被逐出节点，因为您担心如果您丢失 pods，应用程序会崩溃。如果 Karpenter 检测到您有太多的节点，它将开始驱逐 pod，试图将它们从它确定您不再需要的特定节点上移走。但是如果您设置了 do-not-evict-true 注释集，它将阻止 Karpenter 缩小该节点。

您可以使用开源工具，如 北极星 ，以确保您遵循 Kubernetes 和 Karpenter 中的最佳配置实践，从而确保您应用的设置不会干扰 Karpenter 有效整合节点的能力。

2.管理集群拓扑

使用 Karpenter，您可以表明您只想为应用程序使用特定的节点类型。这可能会改变集群的拓扑结构，因为如果集群中运行多个应用程序，并且一个应用程序需要一种节点类型，而另一个应用程序需要不同的类型，则 Karpenter 必须同时运行这两种类型。如果你在十个不同的团队中这样做，这可能会成为一个问题。使用您的置备程序，您可以限制希望允许的节点类型的数量，或者使用 Polaris 禁止选择特定的节点类型。

3。与云承诺模型保持一致

如果您的组织决定从云服务提供商处预订或购买节省计划，您希望确保您在 承诺模式 上利用的资金得到有效利用。Karpenter 可以根据运营团队为您的组织所做的决策，帮助您确保资源得到充分利用。Karpenter 是 Kubernetes-native，这使得您的用户更容易:

4.设置资源请求和限制

您希望 Karpenter 高效，并使用正确的节点组合构建您的集群。但是，因为您仍然依赖 Kubernetes 调度的底层机制来完成这项工作，所以您需要设置资源请求和限制。Polaris 将任何没有资源请求和限制的事情标记为您需要解决的问题。当您在整体上对 CPU 数量和内存量设置限制时，您可以设置集群的最大值，因此您知道它永远不会超过某个成本。

Goldilocks 是一个开源工具，它使用 垂直 Pod Autoscaler 的 推荐引擎来提供基本级别的资源请求和限制推荐。它会检查 pod 的使用情况，并针对您的资源请求和限制设置提出建议。如果您不确定设置这些请求和限制是什么(或者如果您根本没有设置它们)，这是一个很好的开始方式。随着时间的推移，您可以定期重新评估它们，并相应地更新您的资源请求和限制。

5.尊重你的分离舱破坏预算

Karpenter 在缩减节点规模和驱逐单元时会考虑单元中断预算。如果你没有所有应用的 pod 中断预算，你可能会失去大量的 pod。这可能是因为您的服务无法处理移除了那么多 pod 的标准流量。

你需要意识到这些限制，这是北极星帮助的另一件事。Polaris 中的默认检查之一是确保 pod 中断预算附加到您的部署中。Pod 中断预算是所有 Kubernetes 集群的标准最佳实践，当您以稍微更积极或更智能的自动伸缩形式(如 Karpenter)引入节点流失时，您需要确保它到位。

6.准备好活性和就绪性探测

如果您的单元正在服务流量，并且您经常上下扩展单元，那么您需要对节点变动具有弹性。在准备好为流量提供服务之前，pod 必须启动、连接到数据库并执行其他几项任务。如果您想在 Karpenter 引入的节点变动中保持弹性，那么您需要准备好活跃度和就绪性探测器。Polaris 包括对活性和就绪性探针的检查，甚至允许您编写需要特定范围的资源请求和限制的策略。

你准备好了吗？

卡本特的好坏取决于你给它的信息。您可以向 Karpenter 提供的信息越多，提供的约束越少，Karpenter 对您的组织就越有伸缩性和灵活性。Kubernetes 本身包括许多可以调整的旋钮——添加 Karpenter 会增加更多旋钮。这导致更多潜在的复杂性，因此您需要一个策略或治理解决方案来正确管理所有这些旋钮。Polaris 收集了久经考验的 Kubernetes 最佳实践，通过帮助您设置与 Karpenter 一致的检查和警报来提高您的 Karpenter 就绪性，从而通过为 K8s 集群提供快速简单的计算资源调配来利用云

如何选择:使用 Goldilocks 与 Fairwinds Insights 的优势

原文：https://www.fairwinds.com/blog/benefits-of-using-goldilocks-vs.-fairwinds-insights

在 Fairwinds ，我们在过去几年中为几十个组织管理了数百个集群，这让我们对大多数组织在其 Kubernetes 环境中遇到的问题有了相当多的了解和见解。我们反复看到相同的问题，其中大部分与获得正确的资源请求和限制有关，所以我们创建了金发女孩来帮助确定设置资源请求和限制的基线。我们在构建和使用 Goldilocks 中获得的经验使我们能够为 Fairwinds Insights 构建功能，从而提供更多的资源优化。

金发女孩和设置资源配置

您可以在 pod 中的每个容器上设置两种类型的资源配置:请求和限制。资源请求定义了容器需要的最小资源，而限制定义了容器可以使用的最大资源量。设置这些限制很重要，因为它们有助于防止您过度使用资源(同时也为其他部署节省资源)。请求会影响 Kubernetes 中 pods 的计划方式；基本上，调度程序读取 pod 中每个容器的请求，并找到适合该 pod 的最佳节点。Kubernetes 使用这些信息来优化您的资源利用。

设置正确的 Kubernetes 资源请求很重要，但是如果您不知道您的环境中发生了什么，这将是一个真正的挑战。我们的开源项目金凤花(Goldilocks)在推荐模式下使用垂直 Pod 自动缩放器 (VPA)来查看每个应用上的资源请求建议。Goldilocks 为名称空间中的每个部署创建一个 VPA，然后向它们查询信息。Goldilocks 提供了一个很好的起点，可以很容易地查看所有建议，并决定如何设置您的资源请求和限制，以便根据您自己独特的用例更好地调整您的应用程序。

Goldilocks 仪表板资源建议示例

但是对于许多组织来说，金发女孩并不能满足他们所有的需求。为了更好地服务于我们的用户，我们为有以下需求的组织构建了 Fairwinds Insights :

• 对资源请求和限制的多集群洞察
• 通过单一窗口查看其他最佳实践建议
• 访问其他资源指标

Fairwinds Insights 平台还可以轻松估算 Kubernetes 工作负载的支出和节省。

多集群洞察

Fairwinds Insights 提供了提高 Kubernetes 计算资源效率的建议，并且提供了 Goldilocks 所不具备的多集群功能。对于运行多个集群的企业，Insights 提供了可见性，以确定您可以在哪些方面节省资金。如果需要，它还可以帮助您证明您的 Kubernetes 环境正在经济高效地运行。

Fairwinds Insights 可供免费使用。你可以在这里报名。

Insights 使您更容易研究应用程序资源和历史使用情况，因此您可以调整设置，帮助您提高 Kubernetes 环境的效率。您还可以评估单个应用程序，以发现在不影响应用程序性能的情况下降低成本的机会。

虽然在 Goldilocks 中跟踪资源请求和限制对于单个集群来说很容易，但是随着您的组织发展到多个团队和多个集群，这将变得更具挑战性。Fairwinds Insights 使您能够更好地:

• 查看历史 CPU 和内存使用情况
• 获取关于跨集群的资源限制和请求的建议
• 提高工作负载的 CPU 和内存利用率
• 按名称空间或标签分配和分组成本估算

这种跨多个集群的可见性有助于您做出关于资源设置的正确决策，并创建和共享报告，展示您与业务目标的一致性。

一个工具(金发女孩)与多个工具(费尔温德见解)

Goldilocks 在为设置 Kubernetes 资源请求和限制提供基线方面做得很好。它可以方便地查看来自 VPA 的所有建议，并根据 pod 在一段时间内的历史使用情况做出决策。

Insights 提供了许多附加功能。例如，任何开源工具都可以链接到 Insights，使数据作为一个整体规范化变得简单，通过将来自多个来源的数据整合到一个视图中来提高对 Kubernetes 部署的可见性。它将所有来自其他工具的发现放在 Goldilocks 旁边，所以你可以更好地决定如何设置你的要求和限制。

Insights 是使用多种开源工具构建的，这些工具提供了 Goldilocks 无法单独提供的功能，包括:

Insights 还提供了我们从 Prometheus 获取的额外资源指标。Fairwinds Insights 可以在多个集群和团队中应用 Goldilocks 和其他优秀工具的优势，在整个组织中保持一致。

不是哪个，是什么时候

金发女孩在这方面做得很好。它帮助您获得设置 Kubernetes 资源请求和限制的基线，并获得关于您可以做出更改的地方的建议。我们继续对 Goldilocks 进行更新，我们鼓励加入我们的开源用户组，帮助我们确定项目的方向。

Fairwinds Insights 是一个跨多个集群提供可见性的平台，因为它合并了多个开源项目，所以它为您的 Kubernetes 环境的整体效率和可靠性提供了更多有用和可操作的信息。我们在 Insights 平台中的集成使您可以轻松查看您的金发女孩结果以及其他审计工具和资源指标。

Goldilocks 和 Insights 都可以帮助您评估您的资源请求和限制，而 Insights 还可以帮助您识别和修复 Kubernetes 中的安全性、效率和可靠性问题。处于 Kubernetes 之旅早期的组织可能希望从 Goldilocks 开始，但是一旦您在多个团队中运行多个集群，Fairwinds Insights 可以帮助提供一致性和治理，以最大限度地降低风险，并保持集群高效、可靠和经济高效地运行。

如何选择:使用北极星与 Fairwinds Insights 的优势？

原文：https://www.fairwinds.com/blog/benefits-polaris-fairwinds-insights

Fairwinds 的团队已经为几十个组织管理了数百个集群，这让我们对大多数组织在其 Kubernetes 环境中遇到的问题有了独特的见解。我们一次又一次地看到同样的问题，其中大多数都围绕着安全性、效率和可靠性。我们想给我们的客户一种识别和修复这些问题的方法，所以我们建造了 Polaris 。

Polaris 是一款开源工具，我们将继续使用它来帮助我们为我们的客户管理数百个生产工作负载。它运行各种检查，以确保您已经使用 Kubernetes 最佳实践配置了 Kubernetes pods 和控制器，帮助您避免工作负载配置问题。

但是对于许多组织来说，北极星并不能满足他们所有的需求。为了更好地服务我们的用户，我们为需要以下服务的组织构建了 Fairwinds Insights :

• 随着时间的推移跟踪调查结果
• 跨多个集群和团队进行协调
• 想要与 Slack 、 Datadog 和 GitHub 集成
• 希望北极星数据与其他审计工具的数据进行对比

Fairwinds Insights 平台通过提供跨团队和集群的一致性来识别和补救 Kubernetes 安全风险，从而弥合了开发、安全和运营部门之间的差距。

一个工具(北极星)对多个工具(费尔温德见解)

北极星有一点做得非常好:配置验证。它运行二十多项检查，帮助用户发现 Kubernetes 的错误配置。这是一个很好的开源项目，Polaris 可以帮助您避免配置问题，并确保您的组织遵循 Kubernetes 的最佳实践。

另一方面，Insights 是一个提供更多功能的平台。任何开源工具都可以链接到 Insights，使标准化数据变得简单，并在一个地方获得所有数据，通过将多个来源的数据集中到一个视图中，提高您对 Kubernetes 部署的可见性。

您可以永远免费使用 Fairwinds Insights。拿到这里。

Insights 提供了比 Polaris 更多的好处；它使用多种开源工具构建，为用户提供了许多功能，包括:

Fairwinds Insights 可以在多个集群和协作团队中应用 Polaris 和这些其他优秀工具的优势，在整个组织中保持一致。

数据持久性

北极星提供即时快照，这是一个快速了解你在做什么的好方法。

然而，北极星开源项目不包括数据库，所以这些快照中的变化不会被跟踪。Insights 跟踪随时间的变化，因此您可以看到调查结果的整个生命周期。例如，如果您修复了一个问题，然后它又出现了，您可以看到它何时再次出现，并且更容易发现它是如何发生的。你也可以看到你的北极星健康总分是上升还是下降。

Insights 还可以让您很容易看到何时引入新的变化，以及它们如何影响您的 Kubernetes 环境。

多集群支持

Polaris 在单个集群上运行得非常好，可以帮助您使用 Kubernetes 最佳实践来配置 Kubernetes pods 和控制器，但是如果您想在大型机群的每个集群上运行它，该怎么办呢？您需要运行几十个仪表盘来查看所有集群配置。

虽然我们只设计了 Polaris 来提供单个集群的快照，但 Insights 是为多集群部署而设计的。Insights 可以轻松地在您的整个车队中安装 Polaris 和其他工具，将您的所有发现放在一个单一的窗格中。这有助于您根据发现的问题所在的集群来确定优先级或降低优先级，因此，如果您在生产集群中发现问题，您知道快速解决该问题比解决开发集群中发现的配置问题更重要。这可以节省时间，帮助你专注于最重要的问题。

第三方集成

Polaris 通过仪表板或命令行界面(CLI)展示其调查结果:

这种方法工作得很好，但是通常您希望将这些发现发送到外部平台，以增加可见性并确保工程师得到通知。

当 Fairwinds Insights 发现问题时，它可以自动创建 GitHub 和吉拉票证，或者向您的团队发送 Slack 消息。Insights 还可以更容易地看到 Datadog 中的趋势，汇总来自每个插件的发现，并在高度可定制的视图中呈现它们。

不是哪个，是什么时候

北极星在这方面做得很好。它可以帮助您验证您的配置，并使您可以轻松地创建用于验证的自定义策略。我们继续对 Polaris 进行更新，我们鼓励参与我们的开源用户组，帮助我们确定项目的方向。

Fairwinds Insights 是一个跨多个集群提供可见性的平台，因为它合并了多个开源项目，所以它为您的 Kubernetes 环境的整体安全性和合规性提供了大量有用且可操作的信息。我们在 Insights 平台中的集成使您可以轻松查看 Polaris 结果以及其他审计工具，跟踪随时间的变化，并将数据推送到其他位置，帮助您弥合开发、安全和运营团队之间的差距。

Polaris 和 Insights 都可以帮助您识别和修复 Kubernetes 中的安全性、效率和可靠性问题。处于 Kubernetes 之旅早期的组织可能希望从 Polaris 开始，但一旦您在多个团队中运行多个集群，Fairwinds Insights 可以帮助提供一致性和治理，以最大限度地降低风险，并保持集群平稳运行。

来自 KubeCon 2020 的最佳行业见解

原文：https://www.fairwinds.com/blog/best-industry-insights-from-kubecon-2020

上周，包括银级赞助商 Fairwinds 在内的云本土产业齐聚 KubeCon。通过许多精彩的演讲，这里是我们遇到的一些最佳行业见解的概要。

“Kubernetes 的通用、可插拔的特性使它非常适合苹果的团队，[苹果软件工程师 Alena Prokharchyk 说。”Prokharchyk 说:“选择存储、运行时和网络等核心组件的供应商不再是生死攸关的决定。她说，与使用 Mesos 不同，Kubernetes 中的插件选择可以在不重构整个系统的情况下重新评估。 信息周

云本地计算基金会(CNCF)公布了一项对 1，324 名 IT 专业人员的全球调查结果，发现 92%的受访者现在在生产环境中运行容器，83%的人报告说他们也在这些环境中使用 Kubernetes。相比之下，去年的结果显示，84%在生产环境中运行容器，78%在生产环境中运行 Kubernetes。 集装箱期刊

丹尼尔·汤姆森(Daniel Thomson)是用户认证供应商 Stytch 的软件工程师，在 9 月份之前是 Intuit 的高级软件工程师，他说:“最终，行业还没有找到 Kubernetes 配置管理的理想方法，特别是对于 GitOps…理想情况下，他希望看到一个 UI 辅助的配置管理工具，该工具将引导开发人员编辑 YAML 文件，洞察他们的更改的效果，并能够强制实施组织标准和最佳实践。” 搜索操作

“显然一切都可以改进，我认为让开发人员更高效是一个永无止境的旅程，”美国空军首席软件官 Nicolas Chaillan 指出。“也就是说，你还必须注意供应商锁定…这样我们就不会完全依赖这些工具，尤其是在它们不开放的情况下。”…Chaillan 说，现在国防部(DoD)的所有 DevSecOps 团队都必须将他们的工作建立在开源和 Kubernetes 和 Istio service mesh 等项目的基础上。 SDX 中部

美国国家安全局 DevOps 安全主管 Emily Fox 将 DevSecOps 描述为“组织用来确保其 DevOps 方法具有安全第一思想的术语。”对她来说，这意味着将安全自动化置于工作负载环境中…组织如何激励采用 DevSecOps？对 Fox 来说，这是关于“让安全性对开发者透明”您希望开发人员能够快速构建和部署安全的应用程序，而不需要密集的网络安全培训。因此，工具和过程必须尽可能透明和可用。“如果你把它变成第二天性”，她说。DevOps.com

万事达卡公司软件开发工程副总裁肯·欧文斯说:“[自动化]是真正帮助你摆脱生产环境中的一些麻烦和劳累的基础之一，在生产环境中，你总是试图找出哪里出了问题。”

苹果软件工程师 Alena Prokharchyk 说，如此大规模的技术变革也意味着组织的变革。“你需要改变一切和所有人，从财务经理到开发团队，”她说。"这是一条漫长的道路，伴随着许多成长的烦恼."Prokharchyk 说，例如，苹果的安全团队承担了额外的责任，包括确保多租户集群安全的复杂任务。 信息周

---

Fairwinds 是 Kubernetes 支持公司。我们提供托管 Kubernetes 服务和配置验证软件，以确保用户充分利用该平台。我们帮助组织转变其技术和组织，将安全性置于平台的核心，并确保配置的一致性。

通过查看我们的 Kubernetes 成熟度模型，了解更多关于 Kubernetes 的信息。它将帮助任何 Kubernetes 用户——无论是新用户还是有部署经验的用户——找到资源来充分利用云原生技术。

在 Kubernetes 实施 CI/CD 管道的最佳实践

原文：https://www.fairwinds.com/blog/best-practices-for-implementing-ci-cd-pipelines-in-kubernetes

在 Fairwinds，我们对如何在 Kubernetes 和 Docker 中实现 CI/CD 管道采取了固执己见的方法。在以下部分，我将概述我们观点的指导原则，然后根据 Kubernetes 最佳实践展示我们使用的典型 CI/CD 工作流程。我还将分享一些代码，如果您愿意，可以尝试一下。

这些原则没有一个是全新的或惊天动地的，但它们的结合在 Kubernetes 中创造了一个可重复的、可持续的、安全的 CI/CD 管道，受到了我们许多客户的喜爱。

CI/CD 指导原则

容器应该是不可变的

Docker 允许你在推送容器时重写标签。一个常见的例子是最新的标签。这是一种危险的做法，因为它可能会出现您不知道容器中正在运行什么代码的情况。相反，我们采用所有标签都是不可变的方法，因此我们将它们绑定到一个不可变的唯一值上，这个值可以在我们的代码库中找到——提交 ID。这直接将容器与构建它的代码联系起来，消除了我们确切知道容器中有什么的疑问。

释放被测试的容器

根据第一个原则，我们已经部署到一个 staging/dev/QA 环境中，然后经过测试(希望如此)的不可变容器应该与部署到生产环境中的容器完全相同。这消除了在部署到生产环境中时可能会发生变化的顾虑。我们通过使用 git 标签触发产品发布并使用标签的提交 ID 发布容器来处理这个问题。

将秘密和配置放在容器之外

因为容器应该被认为是我们构建过程中不可变的工件，所以配置永远不应该被“烘焙”配置应该存储在 Kubernetes 集群中的一个 configmap 中，而秘密应该存储在 Kubernetes 秘密中，你猜对了。这允许在不改变容器本身的情况下，根据环境配置容器的部署。

带舵展开

在 Fairwinds，我们使用 Helm 模板化所有部署到 Kubernetes 的 yaml。这允许多个环境及其配置的简单配置。此外，它使得跟踪逻辑分组或“发布”变得更加容易

使用基于 Git 的工作流

所有 CI/CD 管道都应该由 Git 操作触发。这符合正常的开发人员工作流程，并使开发人员更容易访问管道。此外，它可以很好地与前面的不变性概念(与提交 ID 相关联)一起工作。

在 Docker 内部构建

我们强烈反对使用一位前同事所称的“手工制作的机器”,这种机器包含各种随机的依赖项和工具。如果你在容器中构建*，你可以控制代码中所有的依赖项和工具，永远不用担心哪个“构建者”在运行你的管道。Docker 的多级构建使这一点变得容易，同时也使您部署的运行时映像尽可能小。*

利用缓存

Docker 图像可以被缓存和重用。我们建议尽可能多地使用这个特性，以便将构建时间保持在最短。应该将缓存映像推送到存储库，或者应该使用 CI/CD 系统的缓存功能来最大限度地提高效率。

奖励:做 Kubernetes 安全和配置扫描

您的 CI/CD 管道是捕捉容器和部署代码中的安全和配置问题的绝佳机会。我们使用 Fairwinds Insights 在我们的管道中执行几种不同的检查，如北极星一个由 Fairwinds 和 Trivy 开发的开源项目。

对使用 Fairwinds Insights 感兴趣吗？免费提供！ 在此了解更多 。

CI/CD 管道示例

我将一步一步地展示我们将为客户建立的正常渠道。它考虑了前一节中的所有原则，并将提供一条“用 X 个简单的步骤”从代码到产品的路径

过程是这样的:

1. 制作一个特征分支
2. 推动那个分支并打开一个 PR——它被构建并部署到一个短暂的名称空间，您可以用它来测试变更。迭代直到它准备就绪
3. 将功能分支合并到主功能——这将触发一个构建和一个到临时环境的部署
4. 一旦试运行环境达到生产就绪状态，标记发布
5. 使用为试运行而构建的相同容器，将标签部署到生产中，但是使用生产配置

在这个过程中，我们可以看到几个“循环”这些是反馈循环，可用于提高质量、测试代码等。我们的目标是使这些变得小而快，这样我们就可以发布可测试和可管理的代码。

前进，制造管道

如果你喜欢我们在 Fairwinds 做 CI/CD 的方式，你可以像我们一样拥有自己的管道！我们使用一组 bash 脚本来完成所有这些工作。我们只需要创建一些配置文件，我们得到的设置与本文中的非常相似。回购被称为 rok8s-scripts (读作“火箭脚本”)，和往常一样，PRs 被接受。

最初发布于 2019 年 3 月 6 日下午 1:02:00，更新于 2021 年 2 月 23 日

用 AWS Lambda 和 API 网关服务构建一个无服务器的 URL 缩短器

原文：https://www.fairwinds.com/blog/build-a-serverless-url-shortener-with-aws-lambda-and-api-gateway-services

几个月来，我一直在关注亚马逊的和 API 网关 服务。运行 web 应用程序而没有维护服务器的成本或麻烦是有吸引力的。当然，没有一个平台是没有权衡的。因此，为了让自己熟悉无服务器应用程序的优点，我决定启动一个简单的项目:弄清楚如何建立一个网址缩短器

通过几个小时的工作和每月几美元的花费，我得到了一个不错的原型，能够每月处理数百万个请求。这篇文章介绍了我遇到的一些问题。还有一个 附带的代码回购 ，你可以用它来自己尝试一下，并学习如何构建一个 url 缩短器。

项目概述

以下是该项目的基本要求:

• 一个 HTTP 端点接受一个 JSON POST 包含一个短令牌和目的地 URL。这些值需要存储在某个地方。
• 第二个 HTTP 端点通过 GET获取一个短令牌，查找相应的目的 URL，并返回 301 重定向。
• 重定向端点应该无需认证即可访问，而 POST 应该需要认证。
• 尽可能通过代码来定义一切，以使其可重复。
• 将服务放在自定义域中。

为此，我需要一些组件:

• 接受 HTTP 请求的前端。
• 后端处理请求并生成响应。
• 保存所有相关短令牌和目标 URL 的数据存储。

前端:亚马逊 API 网关

一开始，我不确定 Amazon API Gateway 会处理前端所需的一切。它需要支持 application/json 和 text/html 内容以及设置自定义响应代码和标题。支持不同的内容类型。并且在 2015 年底增加了对 Lambda 函数结果映射到响应头的支持。API Gateway 看起来符合要求。

创建 API

API 网关服务由资源和方法组成。资源本质上是 URL 端点。方法对应的 HTTP 方法有 GET、 POST、 PUT等。

URL 缩写程序的端点受到限制。有一个 GET 将提供的短 URL 转换成重定向。和一个 POST 来接受短令牌和目的地 URL 关联进行存储。

方法组件

每个 API 网关方法都有四个组件。这是接受令牌并返回重定向的 /{token} 端点 GET 方法的示例:

• 方法请求- 定义传入的请求，包括从请求路径、查询字符串和头中提取的任何参数。它还支持为特定方法启用授权。
• 集成请求- 将请求映射到后端。在这种情况下，我使用 Lambda 函数，但它也支持代理到另一个 HTTP 服务或出于开发目的模拟响应。在这里，您可以选择哪个 Lambda 函数来处理单个请求，并将请求参数映射到后端数据负载。
• 方法响应- 定义您的服务支持的响应状态代码和头的集合。
• 集成响应- 将 Lambda 函数执行的返回数据映射到适当的响应代码。这可以使用正则表达式匹配器来完成。更多细节请关注。它还允许您设置自定义响应头和设置模板来转换 Lambda 结果。

URL shortener 的神奇之处在于将 Lambda 函数的结果映射到一个响应头。我需要将 Location 头设置为 Lambda 函数基于短令牌查找提供的目的地 URL。

下面是集成响应设置为 /{token} 端点 GET 的方法。注意 Location 头映射到 Lambda 函数的 return JSON 中的一个值。

需要认证

网址缩写者的 POST 方法需要认证来控制谁可以张贴条目。API Gateway 提供的身份验证选项之一是 API 密钥。可以生成 API 密钥并将其与应用程序相关联。在方法上启用时，对该方法的所有请求都必须包含有效的 API 键头才能执行:

x-api-key: bkayZOMvuy8aZOhIgxq94K9Oe7Y70Hw55

这种方法允许我在 URL POST 上要求认证，并将 GET端点向世界开放。

将 API 作为代码管理

我的目标之一是用代码管理这个项目，而不是通过亚马逊控制面板点击。API Gateway 提供了以 Swagger 格式导出和导入应用程序配置的能力。

Swagger 是一个旨在以 JSON 或 YAML 格式描述和记录 RESTful API 的规范。各种服务可以使用 Swagger 文件来可视化、测试或实现 API 服务。

我不得不承认，使用基于网络的控制面板，开始使用亚马逊的 API 网关服务要容易得多。我最终能够将服务定义导出到一个 YAML 文件中。我还能够使用亚马逊提供的AWS-API gateway-importer工具应用更改并克隆 API。

综上所述，我首先通过点击 web 面板来创建服务。它极大地帮助了我理解 API 网关应用程序是如何构造的。我建议使用 web 面板作为起点。

后端:亚马逊 Lambda

Lambda 支持 Java 、 JavaScript 、Python等语言。Lambda 还支持上传和执行二进制文件，因此其他语言也是可能的。我最熟悉 JavaScript，所以我从那里开始。

功能输入和输出

Lambda 函数按需执行。与 EC2 不同，无论何时执行函数，AWS 都会确保计算环境。无需维护服务器，容量可按需扩展。

每个函数都可以以参数的形式获取数据，执行函数并返回数据。函数可以导入外部库，比如连接到其他 AWS 服务。

Lambda 处理函数在调用时接收两个参数: event 和 context。当由 API 网关 event 执行时，包括从传入请求翻译的参数。在令牌查找的情况下，来自 URL 的令牌值被映射到一个名为 token的 JSON 属性。 context 参数提供关于函数执行环境的运行时信息。

URL 缩写函数

redir_lookup_token 接受一个令牌值并返回一个相应的目的 URL。

redir_post_token 取一个短 URL 和目的 URL 的关联并存储。

使用 API 网关处理错误

Lambda 函数的 context 参数还包括生成响应的方法。它提供了 succeed、 fail和 done 方法。最后一个方法是前两个方法的辅助包装器。它有两个参数，如果第一个参数不是 null ，它就会触发一个 fail。

API Gateway 提供正则表达式模式匹配，用于将失败错误消息映射到适当的响应状态代码。这允许将后端故障转换成有意义的客户端响应。可以定义各种响应状态代码，并将其与正则表达式模式相关联。如果 Lambda 函数返回与其中一个模式匹配的错误消息，客户端响应将返回匹配的状态代码。

每个响应代码都有自己的模板映射。这允许响应内容根据每个响应条件单独定制。对于短 URL 查找，301 是成功请求的默认响应代码。如果有人试图查找一个不存在的令牌，那么应该返回 404。

下面显示了令牌查找 Lambda 函数中的错误情况(第 7 行)以及来自 API 网关的相应 404 消息响应。

API 网关响应状态

Lambda 函数错误结果处理

使用 Apex 管理 Lambda 函数

Lambda 函数可以直接在 AWS web 面板中创建，也可以通过 zip 文件包上传。有一些框架可以从本地开发环境中帮助管理 Lambda 应用程序的编码和部署。

我考虑过 无服务器，一个用 Lambda 和 API Gateway 构建应用程序的扩展框架。我还看了一下 Apex ，一个最小的 Lambda 函数管理器。

Apex 为组织功能代码和元数据提供了一个轻量级结构。它提供了一个 CLI 命令来部署和执行 Lambda 函数。对于这个项目，我决定采用更简单的 Apex 方法。对于 Apex，每个函数都由一个目录表示，该目录包含一个 JSON 元数据文件和一个包含函数代码的 JavaScript 文件。

在编写代码时，您可以使用 apex deploy 命令来部署变更。

> apex deploy
   • deploying                 function=post_token
   • deploying                 function=lookup_token
   • created build (1.1 kB)    function=lookup_token
   • created build (1.2 kB)    function=post_token
   • config unchanged          function=post_token
   • code unchanged            function=post_token
   • config unchanged          function=lookup_token
   • code unchanged            function=lookup_token 

上传后，您可以使用 apex invoke 命令从您的笔记本电脑执行样本输入功能。

对于小项目，Apex 的结构很容易快速工作，而且不会碍事。该项目提到了在未来包含 API 网关管理的计划。

数据存储:DynamoDB

为了与无服务器主题保持一致， DynamoDB 非常适合存储短 URL 和目的地 URL。使用 DynamoDB，您可以指定 的读写容量，而不是建立一个服务器。Amazon 确保分配的读写能力可用。您可以根据需要增加或减少容量单位。

DynamoDB 表是无模式的。主索引可以是单个值，也可以是两个字段的组合。组合键的一个重要限制是它们是分层的。这意味着第二个字段在主字段的上下文中是可选的。单独选择它会导致昂贵的表扫描。由于 URL shortener 主索引是一个单一的短令牌字符串，这不是一个问题。

这要花多少钱？

那么这一切要花多少钱？以下示例假设一个月内大约有 100 万次点击的工作示例。价格不包括数据传输费用，该费用会有所不同。

桌子

服务	说明	费用
API 网关	每月每 100 万次请求	$3.50
Lamba	(命中典型执行秒)(内存/1024) * $.00001667	$1.04
DynamoDB	每秒 1 次读取，1 次写入	$0.58
	总计	每月 5.12 美元

有哪些陷阱？

• API 网关响应时间可能会有很大差异。支持响应缓存，这极大地改善了延迟。
• 从 Swagger 导入 API 网关不会创建所需的 Lambda 权限。我必须通过 web 面板手动重新选择每个 Lambda 函数，以便为从 Swagger 新克隆的服务应用适当的权限。
• API Gateway Swagger 导出似乎不包含您创建的任何模型模式。如果您没有模型，web 面板似乎会显示一条错误消息。
• API 网关自定义域需要 SSL。此时与 Route 53 的 AWS 证书管理器没有连接。证书必须手动过账。
• 自定义域使用 CNAME 记录指向 API 网关。这意味着使用一个不适合短 URL 的子域。

我可以安全地使用 Kubernetes 吗？

原文：https://www.fairwinds.com/blog/can-i-use-kubernetes-securely

你担心你缺乏安全使用 Kubernetes 的能力

当你有了一个新的范例，你必须学习一种新的思考安全的方式。没有理由重新发明轮子，有很好的工具可以帮助您轻松实现安全的基础架构。你不会因为在健身房使用储物柜而感到恐慌，也不会去健身房，你会买一个工具——一把锁——然后用它，这样你就不用担心了。

如果您不确定从哪里开始使用 Kubernetes security，请查看以下 OSS 工具:

想要一种简单的方法，通过单个代理部署所有这些工具，并帮助对每个报告中的发现进行优先排序？查看 Fairwinds Insights ，我们汇总安全调查结果，揭示错误配置，并提供解决问题的建议。

使用 Fairwinds Insights，在一个平台中免费获得 Kubernetes 安全性、成本分配和规避、合规性和护栏。

验证你所建立的是正确的，你可以在晚上睡个好觉。新的范例就是这样，它们本质上并不可怕。如果您在刚接触 Kubernetes 时缺乏保护它的专业知识和经验，有一个很好的工具可以帮助您快速理解。

一把大锁对心灵的平静有奇效。

迎接 Kubernetes 多集群管理的挑战

原文：https://www.fairwinds.com/blog/challenges-kubernetes-multi-cluster-management

无论您是希望分离安全边界、隔离可怕的配置更改的影响、扩展更接近客户的应用程序、实现数据主权，还是追求多云梦想，您的生活中都可能有多个 Kubernetes 集群。在这篇文章中，我将描述一些有助于成功管理多个集群的特征和工具。

对标准和流程的依赖

随着 Kubernetes 集群的增加，遵循标准和拥有可重复的流程对于产生一致的行为和维护秩序变得更加重要。

这种标准的一个例子是安装了相同版本的入口或 DNS 控制器的所有集群。附带的流程记录或编纂了休息良好的工程师关于如何安全升级这些控制器的多种观点。

标准和流程将随着您的基础架构的扩展而调整，您需要支持云、并非在所有地区都可用的服务或新架构之间的差异。有时会觉得维护标准和流程的额外负担阻碍了进步，但是一旦您达到逃逸速度，这些习惯会帮助您的基础架构发展得更快更远。保持标准的一部分包括适应变化。

• Fairwinds 开源工具 Pluto 帮助您检测 Kubernetes API 版本何时被否决或不再可用。例如，升级到 Kubernetes 1.16 可能会破坏您升级应用程序的能力，如果那些应用程序的清单没有提前升级的话— Pluto 帮助您了解您的 Kubernetes 清单或舵图需要如何与 Kubernetes API 一起发展。
• 类似地，Fairwinds Nova 是一个开源工具，它将舵版本与已知的舵库进行比较，并在您安装了过时的图表或过期版本时通知您。

政策

策略有助于防止对您的 Kubernetes 集群和工作负载进行非标准的更改。在开发或工程工作流的早期，策略的实施应该在必要的地方提供防护栏。例如，如果由于不安全的配置而不允许 Kubernetes 部署，理想情况下，它应该在持续集成期间失败，而不是在应用程序被部署到 Kubernetes 时失败。

• Fairwinds Polaris 是一款开源工具，通过 CI/CD 集成和 Kubernetes 准入控制器将您的 Kubernetes 工作负载与最佳实践进行比较。准入控制器在 API 级别阻止资源部署到 Kubernetes 集群。Polaris 允许使用 JSON Schema 定义自己的标准，这与 Kubernetes API 规范相匹配。自定义 Polaris 检查的示例包括不允许从非标准注册表中提取图像，或者要求 Kubernetes 部署还伴随有 Pod 中断预算。

使用开放策略代理或类似工具可以实现更具体的策略。例如，Kubernetes 资源的标签标准可以帮助您跟踪您的平台是如何被消费的，并简化功能分支的部署和清理。标签可用于指示 CI/CD 应在何处部署应用程序、开发人员访问开发环境所需的 RBACBindings、网络访问或何时清理短暂的开发环境。标签只有到处存在才可靠。通过用减压阀语言(开放策略代理使用的语言)编写更具表达性的策略，策略可以强制将特定标签设置为一定范围的值。

能见度

被动或短期调整可能会迷失在集群的海洋中。这里有一些工具可以帮助您发现车队中的意外偏差。

• Fairwinds Polaris 提供集群内工作负载的仪表板视图，以及它们与最佳实践的关系。
• Fairwinds Goldilocks 通过在建议模式下使用 vertical-pod-autoscaler，帮助您获得“恰到好处”的 Pod 资源请求和限制，在仪表板中可视化。
• Fairwinds RBAC Lookup 是一个命令行工具，它可以方便地找到向 Kubernetes 认证的用户、组或服务帐户的角色。

帮助管理多个仪表板，并提供一个统一的地方来管理来自这些优秀工具的结果…有一个应用程序可以解决这个问题。😃

费尔温德见解

Insights 将包括上述工具在内的优秀开源工具的结果聚集到一个视图中，这允许您跨多个集群评估和实施您的标准。Insights 使用 Polaris 和开放策略代理为您的部分或全部集群提供集中策略管理。无论您是希望针对 Insights 提出的问题发出松弛警报还是创建故障单，您的工程师都可以跟踪他们的修复情况，而无需经常返回 Insights 仪表盘。

Fairwinds Insights 可供免费使用。你可以在 这里 报名。

跨团队和云管理多个 Kubernetes 集群不可避免地会引入不一致性，这会导致错误并耗费时间和生产力。我们的开源工具解决了其中的许多挑战，但是为了更大的规模和更好的管理，请查看 Fairwinds Insights。

检查 Kubernetes Pod SecurityContext 中的 readOnlyRootFilesystem

原文：https://www.fairwinds.com/blog/check-kubernetes-pod-securitycontext-for-readonlyrootfilesystem

Kubernetes pod 安全策略支持围绕 pod 创建和更新的细粒度控制。 [securityContext](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) 定义了一组 pod 运行时的约束条件。

readOnlyRootFilesystem是一个控制容器是否能够写入其文件系统的设置。这是在发生黑客攻击时最希望启用的功能——如果攻击者进入，他们将无法篡改应用程序或将外来可执行文件写入磁盘。

Kubernetes 安全最佳实践 提供关于配置 pod 或集装箱的 ReadOnlyRootFilesystem 的指导。因此，虽然该功能对于 Kubernetes 安全性至关重要，但如果您的用户没有部署将securityContext设置为 readOnlyRootFilesystem? 的 pod，那么会发生什么呢？最好的情况是，您的团队发现了这一点并应用了策略，最坏的情况是您的 pod 被黑客攻击。可能最好识别那些没有以只读方式运行的 pod。

自动检查 notReadOnlyRootFilesystem

手动检查每个 pod 的 securityContext 容易出现人为错误且耗时。使用策略执行工具自动化这一过程有助于降低 Kubernetes 的安全风险。

Fairwinds Insights 是一个策略驱动的配置验证平台(社区版免费使用)，允许负责 Kubernetes 的团队识别何时设置了不正确的安全上下文。

Fairwinds Insights 永远免费使用。搞定这里的。

Fairwinds Insights 是一款 SaaS 解决方案，它会根据您的要求自动扫描集群，以检查缺失的安全上下文。您的团队节省了识别和跟踪特权容器的时间，并能够利用这些时间来补救问题。

一旦安装了 Fairwinds Insights 代理，您将在 5-10 分钟内获得结果。当 securityContext.readOnlyRootFilesystem 不真实时，Fairwinds 的见解会提供警告。您还可以使用 Fairwinds Insights 来确保在整个部署过程中执行策略，以便为每个 pod 设置安全上下文。这样，通过从 CI/CD 到生产扫描您的配置，您将降低安全事故的风险。策略驱动的配置验证平台确保 Kubernetes 安全最佳实践在组织范围内得到遵循。

查看我们新的金发女孩升级的细节

原文：https://www.fairwinds.com/blog/check-out-the-specifics-of-our-new-goldilocks-upgrade

我们开源项目 Goldilocks 的最初目标是提供一个仪表板工具，用于识别 Kubernetes 资源请求和限制的基线。为了提供建议，我们使用垂直 Pod 自动缩放器 (VPA)，这是一个控制器堆栈，包含一个评估您的 Pod 当前资源使用情况的建议引擎，以便提供指导。

Goldilocks dashboard 提供了 VPA 建议的可视化，因此您可以访问集群中的服务并查看两种类型的建议，具体取决于您部署所需的服务质量等级。QoS 类别是 Kubernetes 的一个概念，它决定了 pods 被调度和驱逐的顺序，Kubernetes 本身将 QoS 类别分配给 pods。

因为对大多数组织来说，获得正确的资源请求和限制是一个持续的挑战，所以我们继续定期改进 Goldilocks，提供我们的变化的定期更新。我们最近对 Goldilocks 进行了一些重大升级，并很高兴与我们的开源社区分享这些改进。

了解更多关于 Fairwinds 的开源项目这里。

金发姑娘有什么新鲜事？

拉请求 #373 和 #376 为金发女孩带来了多控制器支持。在此更新之前，Goldilocks 只能为部署创建 VPA 对象。但是，有了这些新的“拉”请求，Goldilocks 现在可以支持为使用标准 pod 模板规范(spec.template.spec.containers)的任何更高级别的工作负载控制器创建 VPA 对象。这一变化大大扩展了 Goldilocks 可以报告的工作负载数量，从而为您的集群中的工作负载资源提供了更多建议。

Kubernetes 集群很少会只有通过部署创建的 pod。DaemonSets(以及在较小程度上的 StatefulSets)构成了工作负载的重要组成部分。直到现在，金凤花都不会对这些类型的工作负载创建的容器提出建议。

拉取请求的细节是什么？

第一个拉请求(#373)是后端更改，它更新控制器以监视 pod 创建，并确定该 pod 的父工作负载。然后，如果该父对象具有适当的注释(或者在 goldilocks 寻找的具有适当标签的名称空间中)，将创建 VPA。

这个功能彻底颠覆了以前的方法，因为以前我们只关注已创建的部署。通过观察 pod，然后推断父控制器，我们可以涵盖更多的控制器类型，包括那些还没有人想到的控制器。也就是说，假设它们遵循上面提到的 pod 模板规范。

提到的两个 PR 中的第二个(#376)确保 Goldilocks 的仪表板部分实际显示建议，因为一些代码只查找部署。

你如何为金发女孩做贡献？

Goldilocks 是开源的，可以在 GitHub 上获得。我们致力于提高其处理具有数百个名称空间和 VPA 对象的大型集群的能力。在 2021 年夏天，我们还改变了 Goldilocks 的部署方式，增加了一个 VPA 子图，你可以用它来安装 VPA 控制器和资源。在这方面，我们计划继续改进我们所有的开源项目，并欢迎您的贡献！

Goldilocks 也是我们的 Fairwinds Insights 平台的一部分，该平台提供对您的 Kubernetes 集群的多集群可见性，因此您可以针对规模、可靠性、资源效率和容器安全性配置您的应用。对使用 Fairwinds Insights 感兴趣吗？免费提供！在此了解更多信息。

加入我们的开源社区并在 2021 年 12 月 14 日参加下一次聚会。加入我们，赢取费尔温德的奖励！