Firewinds-博客中文翻译-一-

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 限制的影响。

Graph showing 72% of organizations are setting up to 10% of their workload limits too high and 94% of organizations are setting 0-10% of workload limits too low

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

内存限制太高

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

内存限制太低

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

Graph showing 67% of organizations are setting memory limits too low on at least 10% of their workloads

发生内存不足错误(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 概念。

工作量

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

Pod 控制器

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

配置

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

建立工作关系网

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

安全- RBAC

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

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

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

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

如何开始:

打开您的云账单，通过几个不同的参数(账户、类型等)获取成本数据
从你的 BFF CFO 那里获取一些业务层面的数据(收入、客户数量、集群数量等)。
如果你正在使用 Fairwinds Insights 来衡量 Kubernetes 的成本，在效率选项卡下获取一些信息。
搞得一团糟——快速而肮脏地解决——计算一下单位成本。你不是在寻找完美，而是在寻找一个信号。
突出那些看起来有价值的事情，并写下原因。如果你不能很快向自己解释为什么这个指标是有价值的…它可能不是。迭代。扔掉垃圾。
基准。最初的几次迭代将会令人困惑，很可能是错误的。但是那里会有一些金块，你可能会想回来拿。保留一个时间点副本，以供将来继续迭代时参考。
继续走。

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

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

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

完美是完成的敌人

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

让你的开发团队(使用 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 的情况下)，这样他们就有足够的自由在安全网到位的情况下解决业务问题(这样事情就不会以悲剧收场)。护栏让每个人都能安心执行。

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

总结

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

实现优秀的工具，这样开发人员可以更快地完成更多工作。
使用让人们生活更美好的工具。

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

有很多东西可以让这变得更容易，好的工具，开源。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 报告它的状态。如果您的活跃度探测器由标准应用程序入口点提供服务，那么如果它的框架失败或者它请求了一个不可用的外部依赖项，它可能会导致不准确的结果。

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

探测器受重启策略影响: 探测器后应用容器重启策略。您的容器必须设置为 restartPolicy: Always (这是默认设置)或 restartPolicy: OnFailure ，以确保 Kubernetes 可以在活性探测失败后重新启动容器。如果使用 Never 策略，则在活动探测失败后，容器将无限期地保持失败状态。
每个容器都不需要探测器: 可以省略那些总是在失败和低优先级服务时终止的简单容器。
不在 pid 1 上运行的作业是一个很好的 pod 受益于活性探测的例子。如果作业失败，我们希望它重新启动，以确保最近的运行是成功的，并且没有正在静默构建的工作队列。
重新评估你的探头: 不要设置了就忘了。应用中的新优化、特性和回归会影响探头性能。确保定期检查探头，并根据需要进行调整。最精确的探测来自于从真实世界的度量中得到的设置。部署后重新访问您的探测器允许您根据历史性能调整您的探测器。

在 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 就可以在亚马逊上买到了。

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

访问控制

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

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

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

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

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

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

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

附加功能

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 个主要环节:

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

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

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

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

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

以下是更详细的步骤:

部署 [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 的内容。参见我的价值观文件此处。
创建 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)展示其调查结果:

Polaris findings in a command line interface (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 个简单的步骤”从代码到产品的路径

过程是这样的:

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

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

前进，制造管道

如果你喜欢我们在 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 方法的示例:

Model Components

方法请求- 定义传入的请求，包括从请求路径、查询字符串和头中提取的任何参数。它还支持为特定方法启用授权。
集成请求- 将请求映射到后端。在这种情况下，我使用 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 网关响应状态

Model Components

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 工具:

A new container in your cluster? I'm in danger. cartoon.

想要一种简单的方法，通过单个代理部署所有这些工具，并帮助对每个报告中的发现进行优先排序？查看 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)构成了工作负载的重要组成部分。直到现在，金凤花都不会对这些类型的工作负载创建的容器提出建议。

image of namespace details - Goldilocks

拉取请求的细节是什么？

第一个拉请求(#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 日参加下一次聚会。加入我们，赢取费尔温德的奖励！

CI/CD 支持:CircleCI vs Jenkins

原文：https://www.fairwinds.com/blog/circleci-vs-jenkins

在 Fairwinds，每当我们开始与一家新公司合作时，我们都会推荐 CircleCI 作为其 CI/CD 渠道。有两个主要原因:

我们的客户选择与我们合作，以降低 Kubernetes 的复杂性并获得专业知识，从而专注于他们的核心业务技术。出于同样原因，我们推荐 CircleCI。
CircleCI 是在其前辈(如 Jenkins)多年反复试验的基础上构建的一个完善的工具。

打磨工具，进化出

TL；詹金斯博士是强大的，但高维护。CircleCI 的 UX 更好，没有保养。

Jenkins 是一个流行的 CI/CD 开源工具。实际上是一场甲骨文之争后哈德森的分叉。Jenkins 是围绕一个插件系统设计的，该系统允许第三方扩展来添加功能。然而，这是一把双刃剑。一方面，它允许用户创建非常独特的功能，甚至尝试一些想法。另一方面，这种额外的功能使得配置和维护变得更加困难，并且产生了不连贯的用户体验(UX)。这可以从彻底改造 Jenkins 用户体验的项目蓝海中看出。使用 Jenkins，公司花费大量时间维护工具本身和插件，占用了核心业务技术的时间和资源。

进入 CircleCI。它创建于 2011 年，因此建立在观察最初 CI/CD 使用案例中哪些可行、哪些不可行的经验之上。它不仅从 Jenkins 那里汲取了思想，还从它之前的其他 CI/CD 工具中汲取了思想。像 Jenkins 这样的工具委托给插件的所有核心 CI/CD 功能都内置在 CircleCI 中，支持更干净的配置和更好的 UX。然而，它并没有止步于此，对于类似插件的功能，CircleCI 提供了与许多服务的集成，如 GitHub，AWS，GCP 和 Kubernetes。另外，CircleCI 有 orb，它们是“您在构建中使用的 CircleCI 配置的可共享包”。在 Fairwinds，我们提供一个名为 rok8s-scripts 的球体😉有了 CircleCI，用户花在维护上的时间更少了，更多的时间用于他们的业务。

维护复杂性降低

TL；詹金斯博士需要安装和维护。这意味着运营团队将有额外的工作。CircleCI 可以在云中运行，几乎不需要维护。

要使用 Jenkins 首先你需要把它安装在某个地方。这意味着您需要在您的 Kubernetes 集群中提供或安装一个服务器。无论哪种方式，这都意味着您需要采取额外的步骤来确保安装是生产就绪的，然后维护它。然而，它并没有停止在这里，安装后您需要配置詹金斯，以满足您的需求。插件将需要安装，配置和维护。最后，做完这一切后，Jenkins 准备好创建管道了。使用 CircleCI，只需注册即可开始创建管道。CircleCI 负责安装和管理。此外，如果用例要求 CircleCI 托管在公司自己的基础设施上，这是可以做到的。运行托管的 CircleCI 当然需要维护，但是设置仍然更简单，您仍然可以从更好的 UX 中受益。

CI/CD 支持

我们的 Fairwinds 团队专注于 Kubernetes 支持。这就是用户需要的帮助，以减少复杂性并实现 Kubernetes 的最佳实践。它有助于用户避免反复试验以节省时间，提供生产级 Kubernetes 基础设施，使用户可以专注于他们的应用，并提供对高技能 sre 的即时访问。

作为我们对 Kubernetes 支持承诺的一部分，我们也致力于推荐最佳的工具。这意味着 CircleCI 支持 CI/CD。

Clover、PagerDuty 和 Fairwinds:在 Kubernetes 上支持开发者

原文：https://www.fairwinds.com/blog/clover-pagerduty-fairwinds-enabling-developers-kubernetes

听听来自 Clover Network 的 Rishi Malik 、来自 PagerDuty 的 Tristan Bates 、来自 Fairwinds 的 Kendall Miller 和来自 Fairwinds 的 Danielle Cook 主持一场关于 Kubernetes 以及为什么开发人员支持/自助服务如此重要的讨论。了解 Fairwinds Insights 如何帮助 Kubernetes 为 PagerDuty 提供安全性和合规性，以及为Clover Networks提供自助服务支持。Insights 与 PagerDuty 的集成有助于确保 Kubernetes 用户最大限度地利用平台来更快地发布应用程序。

阅读文字记录

fair winds 营销副总裁 Danielle Cook:欢迎。今天和我在一起的有三叶草网络的 Rishi、PagerDuty 的 Tristan 和 Fairwinds 的 Kendall。我们在这里讨论 Kubernetes、PagerDuty、Fairwinds 以及我们如何合作。感谢大家的参与。首先，我想请大家告诉我一些关于你的角色以及你在 Kubernetes 和你的组织中所做的事情。

特里斯坦，你想开始吗？

特里斯坦·贝茨，SRE 平台工程经理。我在 PagerDuty 有一个 SRE 平台工程团队的工程经理。SRE 平台团队负责 Kubernetes 的实施。我们提供基于 Kubernetes 的平台，以便我们的工程团队可以专注于构建功能，而不必担心底层基础设施的所有复杂性。

三叶草网络平台工程副总裁 Rishi Malik:谢谢。我在三叶草网络公司负责平台工程。我们是一家销售点公司，可以让中小型企业轻松开展业务。我们和 Kubernetes 合作了很多。这确实是我们下一代平台的基础。与 Tristan 所说的类似，这是一种让我们的应用程序团队快速构建和运行的方式，摆脱了他们传统上必须处理的大量复杂性。太棒了。

肯德尔·米勒，Fairwinds 公司总裁:我是 Fairwinds 公司的肯德尔。Fairwinds 在 Kubernetes 领域已经有 7 年了，6 年半的时间不会太长，在很长一段时间里为很多很多人建设和维护基础设施。今天，我们开发的软件可以把护栏围起来。随着 Kubernetes 变得越来越容易接近，站起来不再是困难的部分。似乎每个人都能做到。一旦有人站起来，每个人都会发现他们有麻烦了。试图在它周围安装护栏。Fairwinds 致力于安全性、效率和可靠性方面的最佳实践。

厨师:牛逼。所以现在我只想问几个问题，让大家踊跃回答。我们来讨论一下。第一件事是关于你需要在 Kubernetes 中监控什么样的事情，你需要在什么事情上得到提醒？

对我们来说，我们监控一切。我们经常收到警报，但更具体地说，我们关心三个不同的方面:我们的平台团队经常收到警报的传统基础架构监控方面。

我们有专门针对每个团队在平台上所做工作的应用程序端。以及根据他们的客户体验，什么对他们有意义。

第三部分实际上是我们用顺风做的。这就是事情的规模。我们通过 Fairwinds 获得了一些应用程序性能类型的警报。但是我们真正关心的一件大事是成本。通过迁移到 Kubernetes，通过集成 Fairwinds，通过将其与我们的 PagerDuty 设置结合，我们所做的很大一部分工作实际上是围绕我们所有应用程序团队的自助服务进行的。这对于工程方面来说非常好，因为他们很快，他们可以跑得很快，对平台团队来说没有瓶颈。

从根本上说，这是我们经营方式的转变。对于我们来说，能够说这个应用程序团队、这个服务、这个产品、这个产品功能有一个特定的成本，并围绕它发出警报，有助于我们了解我们作为一个企业在做什么，我们需要关注什么，我们需要在什么地方改变我们的投资。

Bates: 我们监控的一件大事，也是在组织层面解决的一件重要事情，是每个团队都需要制定的安全性和合规性标准。我们不一定希望团队知道这件事，我们希望在不妨碍生产力的情况下，让做正确的事情变得容易。这就是为什么我们使用 Fairwinds Insights，它的准入控制器和报告来管理 Kubernetes 在 PagerDuty 的安全性和合规性。我们甚至将它集成到整个生命周期中，以提醒团队他们正在做一些超出我们预期的事情。

米勒:我想加上特里斯坦，谢谢你这么做。作为一个 PagerDuty 客户，我很高兴知道你们都保持锁定，并正在调整到像安全警报等东西。这也是我们花时间去做的事情，比如哪里有过时的 API，哪里有过时的插件，以确保我们是最新的。如此多的安全问题来自于运行一个你甚至不知道它存在的过时版本。所以这是很重要的一部分。我真的很高兴从你们两个人那里听到这些事情，感谢 Tristan 作为一个非常依赖你的产品的人让你的产品变得安全。

库克:这很重要:Fairwinds 是 page duty 的客户，page duty 是 Fairwinds 的客户，我们还有来自 Clover 的 Rishi，他同时与 page duty 和 Fairwinds 合作。因此，这里有一群人能够对不同的技术以及它们如何帮助每个人做生意发表评论。我的下一个问题是问你的，Rishi，你真正喜欢 Fairwinds Insight 和 PagerDuty 的哪些功能，以及它们是如何协同工作的？

当然可以。对我来说，这完全是关于自助服务的概念和装备应用程序团队，使他们能够掌握自己的命运。具体到 Fairwinds，我们可以获得成本分析、安全警报，老实说，我们得到的最大的东西之一是控制台，我们的应用程序团队可以轻松登录并查看发生了什么。登录并查看有什么，而不是使用平台团队通常更熟悉的更复杂的工具。易用性、减少摩擦对我们来说绝对是关键，因为这对不一定拥有与平台相同经验的应用团队来说是很大的负担。Fairwinds 使它变得容易和可及。

PagerDuty 这边也差不多。我们得到了基本警报和分页的值。我们看到巨大价值的最大方面是像重复数据删除这样的东西，在这种情况下，一个团队可能有数百台服务器，我们看到在聚合级别上发生的事情——云提供商在其服务的某些方面出现问题——会在每个实例上触发警报。重复数据删除非常庞大，因为这是我们过去必须管理的事情。

这需要时间和精力，但现在我们通过 PagerDuty 集成实现了这一点。同样，我们也获得了更多的自助服务，团队可以在其中定义他们的上报策略。我们的平台团队有一个经过超级验证和严密的平台，应用团队也能够设置对他们和他们的客户有意义的东西。对于不太重要的事情，我们可以采取不同的升级方式。我们获得了可见性，能够说每个人都有一个升级策略，每个人都有一个最低限度的升级策略，然后为团队配备他们需要的任何其他东西。这又回到了自助服务的理念。这两个工具[Fairwinds Insights 和 page duty]都有助于我们在整个组织中推动这一目标。

厨师:太好了。我喜欢它与特里斯坦所说的相呼应——你正在安装护栏。你的开发者甚至不需要知道护栏的细节。由于 Fairwinds Insights 和 PagerDuty，人们可以自助服务，并能够更快地完成工作。

贝茨:是的。我们在这里实践了一个完整的服务所有权模型，但是我们意识到这并不意味着你必须理解所有的东西——你只需要塑造和拥有你的东西。使用像 Fairwinds Insights 这样的工具，当然还有 PagerDuty，让这一切变得更简单，这样用户就可以专注于重要的事情。

Miller: 我想补充一点——在现代 DevOps 世界中，服务所有权就像一个白日梦，直到出现了 Heroku 这样的东西。人们不了解 Heroku 下面发生的所有事情——他们不需要——Heroku 是一个工具，它使开发人员能够按下按钮并交付生产。如今，每个人都在用 Kubernetes 构建自己的版本。但是你不希望让所有的开发人员都了解 Kubernetes。相反，你希望能够在保龄球道上放置保险杠，这样他们就不需要非常擅长避开水槽，他们可以直接把球扔下去而不会有问题。

库克:我认为关键是你可以让你的开发人员花时间成为专家和更新，但这降低了你的产品在应用程序中提供的价值。这是一种平衡，我们需要你们做正确的事情，但我们不需要你们每个人都成为 Kubernetes 的专家，因为这很复杂。

Malik: 我喜欢这种转变——你可以称之为左移，称之为自助服务——无论它是什么——事实上，我们将开发人员的同理心带到了最前沿。肯德尔，你提到了 Heroku，是的，他们让它变得简单和容易，但从根本上说，他们所做的是让它变得友好和美好。这是开发人员关心的问题，开发团队发布代码的经验，这是驱动因素。

随着事情变得越来越复杂，随着云迁移的发生，我觉得我们已经失去了一点点。我们正试图通过装备团队来更快地运行，因为这是大多数组织已经找到的扩展方式。你希望能够雇佣工程师在你所做的事情的收入方面工作。

但我喜欢这样的事实，我喜欢这样，我们可以进行这样的对话，引入工具，讨论我们如何让开发者的生活变得更好。推而广之，这让我们作为一家企业的生活变得更好。这真的是易用性，这种同理心。作为一名工程师，您面临着交付产品和功能以及发布代码的压力。让我们不要让它变得超级困难、复杂或者像过去一样老派。让我们把它变得现代化，让它更容易让人记住你为企业创造了很多价值。让我们尽力帮助你。我喜欢这方面。

除此之外，我想说的是 Fairwinds 非常适合这种心态。我们看了看我们自己构建所有这些功能以及将各种工具、产品和开源代码粘合在一起需要做些什么。我们会将整个项目的预算和路线图用于运行 Kubernetes 和未来基础设施，而不是插入 Fairwinds Insights

并且不需要太多的努力就能处理好。

米勒:崔斯坦，那是一个我可以带走的声音字节。

我认为有趣的是，我在评论中感谢 Tristan 让您的产品变得安全，但我也想到我经常使用三叶草销售点，所以让它也变得安全，如果有的话，可能在某些方面对我有更直接的影响。

说到左移——在任何规模下，平台团队都不可能单独维护安全性或任何标准。当您拥有向左推动的工具时，服务所有者就会真正意识到、停下来、保持警惕、保持更新，无论所有的词是什么，以便事情顺利进行，而不仅仅是平台人员或 DevOps 或 SREs 或组织对他们的称呼，这是一件大事，而且这在规模上确实是不可能的。

Cook: 我们今天做了很多好事，让开发人员更快地发布应用程序，为他们提供合规、安全和使用 Kubernetes 所需的工具。所有这些都很棒，是 PagerDuty 提供的技术和洞察力一起真正改变了组织。感谢大家的参与。

集群运行状况检查:可靠性

原文：https://www.fairwinds.com/blog/cluster-health-checkup-reliability

一个站点可靠性工程师非常关心 Kubernetes 环境中的可靠性，你可能已经从职位名称中猜到了。可靠性对软件组织来说很重要，因为它提供了稳定性和更好的用户体验。此外，它使在组织中工作的操作员和开发人员的工作变得更加容易。

在 Kubernetes 环境中，可靠性可能很容易获得，但是如果配置不正确，它就会成为一个深远的目标。在 Fairwinds，我们做了很多事情来确保我们的 Kubernetes 集群对我们的客户来说是可靠和稳定的。这可能涉及对应用程序更改以及群集配置更改的建议。在接下来的几篇文章中，我将概述其中的一些内容，以及 Fairwinds Insights 可能会有所帮助。

资源请求和限制

对 CPU 和内存的资源请求和限制是 Kubernetes 调度程序能够很好地完成工作的核心。

当调度程序决定应该在哪个节点上调度一个 pod 时，它会查看该 pod 的资源请求，然后将该 pod 放置在将提供它所请求的资源的节点上。这确保了 pod 能够运行它需要运行的任何工作负载。如果未设置资源请求，或者设置不正确，这可能会导致 pod 被放置在资源不足的节点上，并且工作负载不会尽可能高效地运行(或者可能根本不运行)。

限制用于防止 pod 在消耗一个节点上的所有可用资源时干扰其他 pod。这被称为“噪音邻居问题”如果允许单个 pod 消耗所有节点 CPU 和内存，则其他 pod 将没有可用的资源。如果你对一个豆荚能消耗的东西设置限制，那么你就能阻止这种事情发生。

需要关于资源请求和限制的帮助吗？

Fairwinds Insights 可以使用一款名为 Goldilocks 的开源工具来帮助你进行这些设置。Goldilocks 使用由垂直窗格自动缩放器提供的建议，在 Insights 中创建建议新资源请求和限制的行动项目。它通过创建一个 VPA 对象来实现这一点，该对象反过来查看您的工作负载的历史内存和 CPU 使用情况来确定建议。

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

一旦设置好资源请求和限制，就可以开始为应用程序和集群启用自动伸缩了。接下来，我们将讨论 Fairwinds Insights 如何帮助自动缩放。

如何解决 Kubernetes 集群安全问题

原文：https://www.fairwinds.com/blog/cluster-health-checkup-security

构建一个有效、可靠的 Kubernetes 集群是很困难的。安全地构建它更加困难。通常，让事情正常运行的最简单的方法是忽略安全考虑，或者甚至绕过默认的安全配置。对于资源受限的工程团队来说，一个典型的游戏计划是:(1)让它工作，(2)让它安全。遗憾的是，第二步经常被忽视。

如果您正在运行 Kubernetes，那么您需要考虑一些不同的攻击媒介。不存在不可战胜的集群，因此了解权衡利弊以及最大的漏洞在哪里，对于拥有适合您组织需求的安全配置文件至关重要。

拒绝服务

运行云软件时，你将面临的最明显的威胁是拒绝服务(DoS)攻击。请记住，并不是每一次 DoS 攻击都是有意的——有时，只需要一次失控的部署，就可以让您的 API 承受比以前多几个数量级的负载。

您可能认为 Kubernetes 凭借其广泛的自动伸缩特性，可以抵御 DoS 攻击，在一定程度上这是真的。如果您有多余的容量，您的工作负载应该能够扩展以响应流量的激增。如果您正在使用 cluster-autoscaler 之类的项目，您可以在容量开始填满时供应新节点。但是请记住，新的节点是要花钱的，请确保您已经设置了一些硬性限制，以防止成本失控。

你可以采取几个步骤来确保你为意外的流量突发做好准备:

在您的应用以及服务网格或入口控制器中设置速率限制。这将防止任何单个机器使用太多的带宽。例如，nginx-ingress 可以限制每秒或每分钟的请求、有效负载大小以及来自单个 IP 地址的并发连接数。
运行负载测试，了解应用程序的伸缩性。您将希望在一个临时集群上设置您的应用程序，并对其进行流量处理。测试分布式拒绝服务(d DoS)攻击有点困难，因为流量可能同时来自许多不同的 IP，但有一些服务可以帮助解决这一问题。
利用 Cloudflare 等第三方服务来提供 DoS/DDoS 保护

外来威胁

如果您有面向公众的应用程序，外人总有可能找到利用您的应用程序逻辑的方法。即使您的应用程序不是面向公众的，您的云中的一个错误配置的网络策略也会突然打开一个全新的攻击媒介。

不幸的是，Kubernetes 无法为您修复代码。但是它可以减轻应用程序中的安全漏洞造成的损害。有几种方法可以确保一个受损的应用程序不会导致全面违规:

使用网络策略来限制哪些 pods 可以相互通话。如果攻击者获得了对特定 pod 的访问权限，但它与您的集群的其他部分隔离，他们将无法进一步前进。
审核每个工作负载的安全配置。像 Fairwinds Polaris 这样的工具将进行检查，以确保工作负载没有以 root 身份运行，它没有访问主机网络的权限，以及其他潜在的不安全配置。
使用临时基础映像构建您的映像。如果攻击者无法进行系统调用，这个
将留给他们很少的工作。

内部威胁

并非所有威胁都来自组织外部。持有您的群集钥匙的心怀不满的员工可能会窃取数据或导致长时间停机。如果没有适当的控制措施，以前的员工仍然可以访问您的基础架构。即使每个人都有良好的意图，诚实的错误也会带来灾难性的后果。如果您是一个小型组织，采取措施来防止内部威胁可能看起来有些矫枉过正，但是在发展之前建立良好的安全实践是非常重要的。

防止内部威胁的最重要方法是避免共享凭据。如果每个人都使用相同的凭证与您的集群进行交互，一名员工的离开将会扰乱整个组织。此外，您将无法审计谁做了什么，因此集群中的每个操作实际上都是匿名的。

一旦为与集群交互的每个人提供了单独的凭据，遵守最小特权原则就非常重要。Kubernetes 内置了基于角色的访问控制(RBAC)来帮助您管理谁可以做什么。仅授予个人执行工作所需的资源和操作的访问权限。这不仅对恶意员工有帮助，也有助于防止诚实的错误。

主要的 Kubernetes 服务，如谷歌的 GCP 和 AWS 的 EKS，在他们的 IAM 档案和 Kubernetes 证书之间有一个内置的链接。像 rbac-manager 这样的开源项目也可以帮助您保持 rbac 配置的简单和可管理性。

包扎

在为 Kubernetes 实现安全策略时，最重要的是坚持最小特权原则。确保将用户限制在合理的范围内，确保 docker 映像尽可能隔离和精简，并确保您的员工只能访问他们完成工作所需的资源。有了合理的措施，即使是应用程序代码中的安全漏洞也可以被限制在一个很小的爆炸半径内。

想要更多吗？看看这篇文章，它通过一些实际操作的例子进行了更深入的探讨。

实现 Kubernetes 时的常见注意事项和陷阱

原文：https://www.fairwinds.com/blog/common-considerations-and-pitfalls-when-implementing-kubernetes

Kubernetes 是一个全新的世界。许多组织一直在运行他们自己的服务器，并且习惯于能够走过数据中心的地板来拨动开关；或者也许他们已经在云中呆了一段时间，但是他们仍然在处理那些他们像宠物一样对待的实例。但是 Kubernetes 不一样。在你开始之前，有些事情你需要知道。在这里，我们讨论了在实现 Kubernetes 时需要注意的所有陷阱。

做同一件事的许多方法

当我开始使用 Kubernetes 时，让我感到惊讶的是你需要以多么不同的方式来思考它。即使我有几年的 AWS 和云计算经验，Kubernetes 也感觉像一门外语，为了理解它，我需要改变我对计算的想法。

最大的问题是，建立 Kubernetes 集群有这么多不同的方法，而且有这么多不同的插件做着大致相同的工作。在第一次建立集群之前做大量的研究是很重要的；否则，你可能会发现一些约束，要求你拆掉一切，重新开始。

立方“喇叭”

Kubernetes 的困难之一是炒作。有如此多的信息可用，从大型企业分享他们的战争故事，到业余爱好者在地下室的三个树莓派上站成一团，写下 Kubernetes 如何改变世界。

关注那些在生产环境中使用安全、高效和可靠的配置大规模运行工作负载的人的观点非常重要。很难找到真正权威的人，所以要小心你从哪里得到信息。你需要做大量的研究。试着把注意力集中在有意义的地方。

Kubernetes 是短暂的

系统管理员吹嘘服务器有 17 年正常运行时间的日子已经一去不复返了。Kubernetes 世界的一切都是短暂的，意思是短暂的。工作负载本身是短暂的，但是我们甚至鼓励您将集群级别的工作负载视为完全短暂的。您应该能够毫无问题地销毁和重新创建您的集群。

立方 vs ECS，Heroku？

在云中运行工作负载有许多不同的方式。为什么选择 Kubernetes 而不是亚马逊的 ECS 或 Salesforce 的 Heroku？

主要答案是 Kubernetes 是一个开源项目，这意味着您可以免费使用它，修改它以适应您的需求，并且永远不必担心它会过时或被锁定。开源精神培育了一个丰富的 Kubernetes 扩展生态系统；几乎所有安装在 Kubernetes 上的核心插件都是免费和开源的。

此外，Kubernetes 可以在任何主要的云上运行，也可以在本地运行，帮助您避免局限于特定的工作方式或特定的服务提供商。Kubernetes 真的意味着每个人的一切。这是一个非常灵活的框架——现有的模式和附加组件将允许您在 Kubernetes 之上实现一个无服务器架构或类似 Heroku 的平台。它足够灵活，可以做其他 PaaS 解决方案可以做的任何事情，并且通过正确的配置，Kubernetes 可以完全根据您的需求进行定制。

像 ECS 和 Heroku 这样的平台(都是专有的)，你为了简单而牺牲了灵活性。例如，您可能被限制使用特定的操作系统，或者他们希望您以特定的方式设置网络流量。如果您选择 ECS 或 Heroku，开始可能会容易一点，但是您会冒最终超越它们的风险，并且不得不进行痛苦的迁移。

Kubernetes:devo PS 文化的答案？

许多组织希望实施 DevOps 实践，并相信转换到 Kubernetes 将有助于这种转变。虽然 Kubernetes 可以帮助催化 DevOps 转型，但它并不是灵丹妙药。你可以有没有 Kubernetes 的 DevOps 文化，也可以有没有 DevOps 的 Kubernetes。

然而，部署 Kubernetes 可以帮助公司加速向 DevOps 的过渡。因为它充当基础设施和工程师之间的 API 层，Kubernetes 使得在开发人员和操作人员之间建立协作和通信模式变得容易。这允许开发人员对他们的应用程序的部署配置承担更多的责任，并帮助运营团队追溯生产问题到特定的提交。

当开发人员能够编写代码、部署代码、查看代码在生产环境中的运行情况，并了解代码的运行方式时，他们就能了解什么在运行，什么在中断。他们将对运送到生产现场的一切拥有完全的所有权。这是真正的 DevOps 文化。

同样，Kubernetes 可以在 DevOps 中发挥作用，但这只是拼图的一部分。公司仍然需要改变团队相互交流的方式，以成功实施 DevOps 文化。

寻求帮助

Kubernetes 生态系统在过去几年里已经成熟了很多。有一些成熟的模式，比如使用基础设施作为代码，使用管理的附加组件集来做诸如入口或证书管理之类的事情。坚持久经考验的最佳实践是确保你在实施 Kubernetes 时不会遇到任何奇怪的死角的好方法。

找一些在大规模运营 Kubernetes 方面有丰富经验的人，或者找一个能帮你完成旅程的合作伙伴。在实现 Kubernetes 时有很多“未知的未知”，所以找一个以前经历过这些战斗并且有伤疤可以证明的人。

人们对 Kubernetes 赞不绝口，这是有原因的。这是一个非常有益的平台。会不会用错了？是的。如果是新手，在习惯之前是不是很难用？是的。但是一旦你开始运行，它就不会辜负宣传。

如何从一开始就符合 Kubernetes 标准

原文：https://www.fairwinds.com/blog/compliance

如果你已经在云世界生活了一段时间，Kubernetes 正在迅速成为容器化工作负载的黄金标准，你可能听说过被称为服务所有权的运营模式。作为一种增强团队之间协作的方式，很像 DevSecOps 的原则，Kubernetes 服务所有权帮助组织将安全性集成到整个过程中，以按照业务的速度构建和交付高质量的软件。

想了解更多关于服务所有权的信息吗？下载我们的白皮书:KUBERNETES 服务所有权完全指南

但是 Kubernetes 的服务所有权对组织来说不仅仅是在开发生命周期的早期解决安全问题。除了提高效率和生产力之外，这种协作模式还确保满足某些关键指标，如、成本优化、可靠性、可扩展性以及许多企业最关心的问题——合规性。

随着网络攻击变得越来越新颖，合规性要求是负责任的企业需要定期考虑的事情。像 Kubernetes 这样的领先容器编排平台的法规合规性是保证业务连续性、防止声誉受损和确定云原生应用程序风险级别的关键。

想了解更多详情？阅读我们的新白皮书:

优化 KUBERNETES 所有权的 5 种方法

Kubernetes 的所有权带来了广泛的挑战，包括对全面监管合规性的需求，这种姿态严重依赖于强有力的治理和护栏。由于 Kubernetes 提供了一个在云中或数据中心构建基础设施的框架，因此有效的合规性至关重要。当通过应用程序生命周期中的自动化来解决合规性问题时，正如 DevSecOps 和服务所有权原则所建议的那样，大规模构建生产就绪型企业基础将成为现实。

无论组织是否需要遵守 SOC 2、CIS 基准控制或 PCI，当合规性规则被编纂为政策时，适当的治理会推动透明度和问责制(并最大限度地降低风险)。这些特定的业务安全策略可以在 Kubernetes 集群中实施。当治理和策略实施被集中时，如服务所有权模型中所概述的，在动态环境中找到可见性和控制是可能的。

平衡速度和灵活性

在软件开发中，对速度的需求和对法规遵从性的需求总是相互激烈竞争。为了找到平衡，团队需要快速交付软件的策略，同时还要保持合规性——当然，还要保护关键数据和流程。Kubernetes 服务所有权利用了法规遵从性和 DevOps 团队的优势，产生了一个对两者都适用的流程。通过这种方式，服务所有权模型将最佳实践、策略和工具嵌入到软件开发生命周期的每个阶段，从而将遵从性框架的所有关键元素集合在一起。

理想的流程包括定期分析合规性的创新渠道，同时提高整体质量和生产率。为了在速度和合规性之间找到平衡，需要打破和消除开发和运营之间的孤岛。这一思想是 DevSecOps 的核心，也是正确的 Kubernetes 服务所有权的关键要素，因为它确保安全性和合规性的目标被认为与不同团队的目标相协调。

建筑合规

虽然开发团队可能不喜欢承认安全性和遵从性的持续压力，但是组织中的其他人有义务执行它们。服务所有权所支持的开发、安全和运营团队之间的协作可确保合规性要求在设计上得到满足，并自然地集成到日常的容器化工作流中。

许多合规性法规强调需要清晰的业务流程文档，包括如何处理事故。Kubernetes 的完全服务所有权促进了这些工作流的自动化。例如，代替简单地规定在宣布工作完成之前应该运行测试，所述测试的执行可以作为工作流的一部分被自动化。这种从手动合规性的转变建立了更可靠和高效的流程，并且还允许组织在中央系统中跟踪测试结果。

寻找 Fairwinds 见解

fair winds Insights通过简化复杂性和启用 Kubernetes 服务所有权模型，统一开发、安全和运营。它通过集成从 CI/CD 到生产的服务所有权来促进持续改进。为了帮助团队克服文化挑战并接受服务所有权，Insights 允许用户:

通过持续监控所有集群防止安全错误配置，实现安全自动化。通过生产查明 CI/CD 的风险。
通过建立政策和实践来帮助开发者更快地前进。符合 SOC 2 要求。
通过更好地了解您的工作负载来优化成本 。获得对 rightsize 应用程序的推荐。
寻找可靠性 作为服务所有者，使用最佳实践指南配置 Kubernetes 策略，以确保快速、可靠的应用程序以及最少的停机时间。
通过一致配置成功扩展 为 Kubernetes 扩展到多个团队。

Fairwinds Insights 通过提供所有集群的仪表板视图，帮助团队了解导致安全性和合规性风险的错误配置，为开发运维团队提供了对 Kubernetes 环境的可见性。

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

Insights 通过将所有权分配给负责解决这些关键问题的个人或团队，帮助团队解决管理 Kubernetes 的一些更具挑战性的方面。开发人员能够在他们的应用中拥有安全和效率配置，因此这不再仅仅是运营的问题。

Kubernetes 中的配置漂移——它是什么，为什么重要

原文：https://www.fairwinds.com/blog/configuration-drift-kubernetes

大多数组织都是从一个应用程序开始试验的。一旦他们通过了一个成功的试点并接受了 Kubernetes，公司可能会建立几十个集群来支持几十个团队。对于使用 Kubernetes 部署多个应用程序的大中型公司来说，这也意味着开发和运营团队也在采用它，通常是在自助服务模式中。当您在构建和部署许多不同集群的过程中有许多用户时，确保一致、安全地部署应用程序并满足适当的资源需求就变得非常困难。

什么是配置漂移

配置漂移是指在一个环境中，基础设施中运行的集群随着时间的推移变得越来越不同，这通常是由于对单个集群进行手动更改和更新。设置一致的自动化集群供应流程有助于确保集群在创建时是一致的，但不会阻止在该集群或其他集群上发生更改。对配置参数的更改可能由开发团队、运营团队或开发团队完成。

为什么配置漂移很重要

当您开始操作大量手动部署且配置不一致的集群时，几乎可以肯定您的容器和集群之间的配置会有差异。这使得识别不一致并纠正它们变得相当困难；与配置漂移相关的重大负面后果包括:

安全漏洞: 错误配置可能导致权限提升、易受攻击的映像、来自不可信存储库的映像或以 root 身份运行的容器。
效率问题: 当工作负载过度调配或过时的工作负载未得到清理时，成本可能会攀升。
可靠性风险: 扩展不足或扩展过于频繁会导致您的应用或服务停机。

试图手动跟踪配置偏差并修复错误配置非常容易出错，并且会很快导致运营团队花费太多时间来跟踪问题。

跟踪您的指标的工具

为了跟踪基本的指标，大多数公司需要准备好工具，以便了解他们正在运行的 Kubernetes 版本，以及支持 Kubernetes 的关键系统软件的版本，如入口控制器、证书管理、DNS 等等。能够找到并看到所有软件版本信息非常重要，因为这有助于您的组织将所有软件的升级到最新的稳定版本，从而帮助您避免技术债务。你不希望运行旧版本的 Kubernetes，特别是因为旧版本的 Kubernetes 和你正在运行的插件可能不安全，增加了你遭受网络攻击的风险。

*## 不一致的负面后果

配置漂移还会导致许多不一致，这看起来可能没有那么糟糕，但会对您的升级过程产生重大影响。当集群的配置不一致时，随着时间的推移，运行 Kubernetes 会变得更加昂贵，因为这意味着您需要单独研究每个升级路径。这可能会增加升级过程的大量时间，并导致时间和运营资源的大量浪费。当您能够拥有一致的基础架构时，这意味着您可以一次性研究您的升级和修补方案，并在多个环境中统一应用它。

多云环境中的配置漂移

较大的公司开始考虑多云场景，这使他们能够利用不同云提供商的优势。这对于 Kubernetes 来说不成问题，因为 Kubernetes 可以在多个云上使用。Kubernetes 的好处在于，它为跨所有这些云运行基础设施提供了一致的 API。当您试图一致地应用策略并从这些不同的云提供商处获取有关您的集群状态的信息时，挑战就来了。对于 DevOps 团队来说，手动管理和洞察跨多个云和集群的配置漂移极具挑战性。

Fairwinds 的多集群和多云计算管理

Fairwinds Insights 的重要功能之一是它支持多云用例。这有助于工程和开发团队更有效地管理多用户、多集群和多云环境，因为它支持许多组织正在考虑的多云部署，而不会失去全局管理配置的能力。为了保持部署的一致性，即使您跨多个云进行部署，将所有安全性、效率和可靠性信息汇总到一个位置也很重要，这样运营和安全团队就可以从一个视图管理所有配置，并降低配置偏差中固有的风险。

配置验证软件-视频演示

原文：https://www.fairwinds.com/blog/configuration-validation-software-video-demo

Kubernetes 生态系统是建立在伟大的开源之上的。有数百种工具可以帮助提高安全性、效率和可靠性。在安全领域，有 40 多个项目可供选择。但是，了解使用哪些工具，并在多个集群中操作它们，需要大量的时间和资源。

我们亲身经历过这个问题。因此，我们开发了 Fairwinds Insights ，这是一个交钥匙配置验证软件解决方案，用于部署出色的 Kubernetes 开源工具，保护和优化 Kubernetes 工作负载。Fairwinds Insights 增加了协作工作流和工具链集成，以实现从开发到运营的平稳过渡。

通过注册您的电子邮件地址，尝试 Fairwinds Insights 既简单又免费。这里有几个视频，让你看看会发生什么。

Fairwinds Insights 演示:概述(1 分钟)

Fairwinds Insights 演示:安装(2 分钟)

了解如何将 Fairwinds Insights 附加到您现有的集群中。

Fairwinds Insights 演示:行动项目概述(45 秒)

行动项允许工程师和开发人员对发现和修复进行优先排序和跟踪。它提供了宝贵的补救信息，包括 YAML 片段在某些情况下。

【Kubernetes】部署集装箱安检(1:30 分)

了解 Fairwinds Insights 如何评估您的集群的安全状况。在本视频中，您将看到我们如何部署名为 hello-kubernetes 的应用程序。

Kubernetes 集群安全(1 分钟)

除了部署安全和容器图像扫描，Fairwinds Insights 还集成了集群级扫描。了解我们如何提高 Kubernetes 集群的安全性。

【Kubernetes 效率(1 分钟)

当开发人员和 DevOps 工程师快速地让应用程序在 Kubernetes 上运行时，他们可能会忽略设置 CPU 和内存限制。或者更糟的是，他们花了很多时间来计算 CPU 和内存的限制。应用程序会运行，但它们可能没有那么高效。该视频展示了 Fairwinds Insights 如何通过检查该工具可以轻松显示的配置问题来帮助提高资源效率。

Kubernetes 可靠性(1 分钟)

该视频展示了 Fairwinds Insights 如何帮助提高可靠性。就绪性和活性探测是可选的，但支持 Kubernetes 的自我修复能力。标记您的部署是否设置了这些探测器是 Fairwinds Insights 帮助您运行可靠的 Kubernetes 应用程序的方法之一。

您可以尝试 Fairwinds Insights，亲自了解它对 Kubernetes 配置的帮助有多快。永远免费。拿过来。

资源

考虑搬到库伯内特吗？以下是你需要知道的

原文：https://www.fairwinds.com/blog/considering-a-move-to-kubernetes-heres-what-you-need-to-know

因此，您的团队建议您重新开发 Kubernetes 平台，您想知道这样做是否正确？

Kubernetes 是一项令人印象深刻的技术，它将允许您解决许多问题并为您的应用提供未来证明。但是在重新搭建平台之前，有些事情您应该知道。

Kubernetes 比你想象的要难

在 20 世纪 70 年代早期发明了 Pong 的视频游戏先驱诺兰·布什内尔在谈到视频游戏时说，“所有最好的游戏都容易学习，但很难掌握。”布什内尔定律或诺兰定律非常适用于库伯内特。多亏了 GKE、EKS 或阿克什，你很容易就能组建自己的第一个 Kubernetes 集群。在您的 raspberry pi 上运行一个实例也相对简单。然而，开始容易，做好却很难。

概念验证并不代表成功

您可以“在 Kubernetes 上运行您的应用程序”的概念证明并不能真正反映您“在 Kubernetes 上安全、可扩展和可靠地运行您的应用程序”的能力

如果你是一家精益、敏捷的公司，并且你已经让你的专家运行了 Kubernetes POC，他们将能够向你展示该应用程序可以在 Kubernetes 上运行——它连接并且一切正常。挑战在于 POC 不能反映真实的环境。该应用程序没有在生产负载下运行，它没有必要进行压力测试以在正确的“事情”上扩展您和您的团队还不知道它如何与开发工作负载或 CI/CD 管道相联系，也不知道需要采取什么措施来就地替换或升级集群。这只是它的操作方面。

另一方面，你知道你是否在运行正确的软件吗？您是否正确配置了 Kubernetes？您是否知道您放入的工具(在 POC 中几乎不起作用)实际上是您将在生产中使用的工具？您是否具备知识和经验，知道使用某个特定的附加组件是您未来的正确选择？如果您继续使用该附加组件，随着您的基础架构的发展，将来会如何改变这种选择呢？您的团队如何知道他们的 POC 平台“经得起未来考验”？

让 Kubernetes 工作和让它 生产就绪 之间确实有很大的区别。而且，由于如此多的移动部件造成的复杂性，与其他许多技术相比，存在更大的技能差距。

你也需要改进你的应用程序

我见过很多想要采用 Kubernetes 的团队。很多时候，这些团队认为他们可以在不对应用程序做任何事情的情况下完成迁移。这是完全错误的——除非你已经使用 12 因素方法构建了你的应用程序，否则提升和改变是极不可能的。即使这样，虽然你可以把你的应用程序转移到 Kubernetes，但它可能会与你作对。

Kubernetes 不会一开始就让你实现成本优化

相反，当你搬到 Kubernetes，你可能会运行并行系统。随着您运行两个系统并进行迁移，您的成本很可能会在一段时间内上升。

关于 Kubernetes 和成本的另一件事是，它可能会节省你的钱，但它可能不取决于你如何部署它。当您考虑重新构建平台时，您需要权衡平台的诸多优势，包括成本。

Kubernetes 需要时间

你不可能在一个月内推出 Kubernetes。学习、推广、配置和优化 Kubernetes 需要时间。没有规定的时间表来说明你应该在什么时候看到收益。至少在第一年，当你发现新的特性和新的做事方式时，你将优化和调整你的集群以做出改进。所以当你认为你完成了，你没有！

事实上，Kubernetes 发展很快，每个季度都会添加新功能，您将永远有机会进行优化。然而，目标是让你能够用最小的努力做出小的改变，产生大的影响。

那为什么要重新平台到 Kubernetes？

如果您有一个运行良好的旧式体系结构，您没有新的收入目标、可伸缩性目标或成本优化要求，那么就不要重新构建平台。毕竟，如果它没坏，就不要修理它。

也就是说，如果它坏了，你知道你想修复它，那么看看 Kubernetes 能为你做什么。Kubernetes 非常棒，对许多类型的应用程序和工作负载都有意义。Kubernetes 可以帮助您:

避免锁定，完全开源:Kubernetes 可以使用，而不必重新架构您的容器编排策略。该软件是完全开源的，可以重新部署，而不会产生传统的软件许可费用。
高可用性和可伸缩性:Kubernetes 包含内置的高可用性特性，有助于负载平衡和自我修复。自动扩展可确保您的工作负载始终有适量的计算可用。
支持标准:Kubernetes 是一个活跃的社区，具有广泛的模块化、开源扩展，得到了像 CNCF 这样的大公司和机构的支持。数千名开发人员和许多大公司为 Kubernetes 做出了贡献，使其成为现代软件基础设施的首选平台。
部署长期解决方案:鉴于 Kubernetes 的崛起，许多云提供商正在将他们的 R&D 重点转移到在传统选项上扩展他们的托管 Kubernetes 服务。在制定长期 IT 战略时，请考虑 Kubernetes。

虽然 Kubernetes 中没有任何东西是免费的，因为进入的门槛很高，而且没有任何东西是现成的(您总是会添加新的工具和不同的配置)，但 Kubernetes 以一种需要配置更改而不是工程更改的方式提供功能。

配置非工程

你可以安装一个程序，写一个 YAML 文件，你的集群就会自动扩展。您不需要编写传感器和缩放循环——您不需要编写任何代码。Kubernetes 有很多功能，你不需要为它们写任何新东西，因为你写的是配置而不是代码。

为了重新访问您的旧平台，我们可以保证在它的基础上，有很多定制的代码。然而，它非常复杂，难以维护，并且需要大量的内部领域/部落知识。Kubernetes 公开了部落知识，并将工程工作转化为团队的配置。

Kubernetes 改变了专业领域，围绕相同的可伸缩、声明性、API 驱动的技术构建了更大的社区。好处是您的团队现在可以理解一个通用的配置。

例如，如果您有一名新员工，此人可以查看您的配置，看到您正在使用 cluster autoscaler，这是一个有许多合作者的公共开源项目。该团队成员可以使用 google it 将您公司的配置与文档进行比较，并在公共 Slack 频道上提出问题。

减少定制工程

Kubernetes 有助于更好、更快地分享知识，并创建一个更好的整体解决方案，以便您减少围绕 Kubernetes 本身的内部定制解决方案。

因为 Kubernetes 在如此大的社区中如此受欢迎，所以当您重新构建平台时，您是在为您的平台做未来准备。它帮助您避免只有一两个团队成员拥有领域知识的情况，如果该团队成员离开公司，您将处于危险的境地。

帮助缩短 Kubernetes 的价值实现时间

我是 Kubernetes 的超级粉丝，从一开始就使用它，并帮助许多公司重新使用它。当你评估是否要搬家时，我提到的每一件事都必须考虑进去。如果你不确定该做什么，Kubernetes 托管服务可以帮你。Fairwinds 的团队生活和呼吸着 Kubernetes 和使其工作所需的开源技术。如果你想要一些专家的建议，请联系。

容器编排要点

原文：https://www.fairwinds.com/blog/container-orchestration-essentials

因此，您认为 Kubernetes 作为一个容器编排系统是您的应用程序的正确选择。祝贺和欢迎。你做出了正确的决定，加入了许多成功公司的行列，拥有令人印象深刻的应用程序。

您可能知道，容器编排很难。有无数的变量，不同的配置参数和每月的漏洞，这不是在公园散步。一些公司甚至最终陷入了云原生状态，从未真正发布过应用程序。但那不会是你。你来对地方了。

以下是实现 Kubernetes 容器编排系统的一些要点:

集装箱化

你要做的第一件事是确保你的每个应用程序都有一个 Docker 映像。这将使您的代码具有高度的可移植性。如果您有无状态的应用程序，将它们封装在 Docker 映像中应该不会太难。但是，如果您的应用程序跟踪内存或磁盘上的长期状态，您可能需要重新架构。这是困难的部分；将应用程序状态与应用程序逻辑分离开来。

然而，Kubernetes 的供应商可以提供帮助。(有一个专家团队在你这边也无妨。)

定义架构和规则

接下来，您需要设置您的编排架构。这也将是困难的，因为你将不得不盲目地做出一些决定。在这里，您当然应该从经过实战检验的堆栈开始，而不是尝试实施定制的解决方案。请记住，您正在开始走向成功的容器编排之路——您将想要为此进行规划。

您应该为以下方面准备一个策略:

进入
证书管理
网络策略
RBAC
监控和警报
部署
版本和更新

这样，当变量出现时，你就准备好了。

既然您已经将应用程序容器化并部署了集群，那么您将需要定义您的编排规则。这些规则应指定 CPU 和内存要求、入口规则和扩展策略。这应该让您为横向扩展和外部访问集群等变量做好准备。此外，您需要指定访问机密和环境变量的规则。所有这些都可以在 Kubernetes 的 YAML 文件中完成，但你也会想看看舵图。

部署应用程序

接下来，您需要一个部署应用程序的过程。您应该设置一个通过 CD 管道自动部署的策略(每当有人在 GitHub 中标记一个分支时)。最初，每当您想要进行更改时，让运营工程师进行手动部署可能没什么问题，但是随着时间的推移，策略将被证明是值得的。

为了确保一切都很好地啮合并一起工作，您将需要一个容器注册中心来保存容器映像，一个 CI 管道来测试、构建和推送映像，以及一个 CD 过程来将它们部署到您的集群。

监控一切

最后，您需要监控您的应用程序。您的集群是一个不断变化的环境，这意味着您需要密切关注它以确保其健康。设置像 Prometheus 和 Datadog 这样的通知，让您知道您的应用程序是否有伸缩性问题或出现故障。但是，请注意，这些通知需要自己的规则，否则它们会在半夜把你吵醒。这里需要注意的是，Kubernetes 的供应商，比如 Fairwinds，可以为您处理这种监控(以及更多)。

要了解关于容器编排的更多信息，请查看如何在 Kubernetes 中创建、查看和销毁 Pod。

正确的 Kubernetes 配置是提高效率和可靠性的关键

原文：https://www.fairwinds.com/blog/correct-kubernetes-configuration-is-key-to-better-efficiency-and-reliability

尽管容器安全性通常被认为是 Kubernetes 中最紧迫的话题，但它与效率和可靠性问题有着千丝万缕的联系，这是云本地世界中的两个关键要素。为了有效地运行 Kubernetes，组织必须努力确保默认情况下工作负载既可靠又高效。因为即使 Kubernetes 在出现问题时提供了某种程度的自我修复，应用程序也需要适当的设置才能正常工作，并充分利用底层 Kubernetes 平台的内置功能。

当可靠性和效率问题没有通过最佳实践得到妥善解决时，成本优化和性能等关键要素就会受到严重影响。可靠性和效率这两个领域需要被视为一个相互关联的挑战，通过适当的 Kubernetes 配置的单一策略来解决。通过定期检查工作负载的总体可靠性，从业者可以确保他们的组织保持资源效率和成本效益。这样，错误配置就成了可靠性和效率问题的核心，这是运行 happy Kubernetes 集群的两个关键属性。

我们在最新的白皮书“好的，坏的&错误配置】中详细讨论了这个问题，您可以随时免费下载。

结构管理

业内通常称之为配置管理或基础设施代码(IaC)扫描，这个过程在只有几个 Kubernetes 集群的小团队中可以手工完成；然而，随着组织试图扩展，许多开发人员部署到多个集群，这个问题变得更加具有挑战性。如果没有 IaC 扫描或某种类型的配置管理，DevOps 团队以及平台和安全负责人可能会很快失去对正在发生的事情的可见性和控制。这一现实表明需要自动化和策略来加强一致性，并在整个组织中提供适当的防护。

效率

IaC 扫描以多种方式影响 Kubernetes 的效率。首先，它提供了识别时间、金钱和专业知识等资源浪费的可见性。Kubernetes 工作负载的错误配置通常涉及低效的计算资源供应，从而导致云计算的巨额账单。如前所述，为了最大化工作负载的 CPU 效率和内存利用率，团队需要适当地设置资源限制和请求。但是这里有一个问题——知道为流畅的应用程序性能设置正确的限制是非常棘手的。这就是可见度发挥作用的地方。

获得应用程序资源使用情况的可见性可以帮助团队更好地了解他们的应用程序在不同的 CPU 和内存设置下的性能。然后可以对这些进行调整，以改善应用性能或提高 Kubernetes 计算资源的效率，最终帮助组织节省云计算资金和数据中心容量。

可靠性

在 Kubernetes 中，可靠性就是构建一个稳定的平台，这样开发团队就可以简化他们的开发过程，更快地发布应用程序。配置管理(IaC)会影响可靠性，因为它为开发运维团队提供了避免停机和生产事故的方法。平台工程和运营团队负责监控 Kubernetes 集群的运行状况，这是通过一套最佳实践来实现和协调的。平台工程团队必须与开发团队合作，以确保从一开始就可靠地配置工作负载——说实话，Kubernetes 的错误配置经常发生。

Kubernetes 提供了一个框架，在这个框架中，用微服务和容器构建分布式系统，以便可靠地运行应用程序。这种模式意味着不同的团队拥有不同的堆栈层，这是 Kubernetes 服务所有权的一个基本概念，开发人员专门负责通过适当的配置将他们的应用程序下载到 Kubernetes。这种普遍的类似 DevSecOps 的服务所有权模型将运营团队从处理部署配置中解放出来，并允许他们专注于策略实施和可操作的开发人员反馈。

通常在 YAML 文件和舵图中进行的工作负载配置会影响服务的安全性和可靠性，以及集群中工作负载的效率。在组装一个稳定可靠的 Kubernetes 集群时，需要考虑许多因素，包括应用程序更改和集群配置变更的潜在需求。这些考虑事项包括设置资源请求和限制、使用正确的指标自动扩展 pod 以及使用活跃度和就绪性探测器。

正确的配置

IaC 扫描解决方案，如在 Fairwinds Insights 中可用的那些，可以在开发人员提出拉取请求时检查 YAML 和舵配置。与代码扫描解决方案等传统基础设施一样，Insights 会检查安全违规配置，如权限提升。该软件还进一步整合了对平台工程团队的效率和可靠性检查，他们依赖这些检查来运行稳定和可扩展的基础设施。

以下是一些支持正确配置的可靠性检查示例:

必须对资源消耗设置限制，以防止 pods 消耗一个节点上的所有可用内存和 CPU，否则称为“噪音邻居问题”
跨多个节点和可用性区域的容器应该在云中进行调度，以实现高可用性。
应该使用反关联性来约束哪些节点有资格基于 pod 标签而不是基于节点进行调度。
必须通过部署冗余实例来规划容错，以避免单点故障。
应该应用活动和就绪探测来确保服务的可用性并检查集群性能。

因为配置错误非常普遍，所以只有遵循这里概述的最佳实践，才能构建稳定、可靠和安全的集群。这种级别的治理只能通过值得信赖的合作伙伴来实现，他们精通统一团队、简化复杂性和利用 Kubernetes 的专业知识来节省时间、降低风险和放心配置的流程。

专业知识和伙伴关系

Fairwinds Insights 提供这种水平的专业知识和合作关系。作为 Kubernetes 的安全和治理平台，Insights 为 DevOps 团队提供了一个可扩展性、可靠性、资源效率和安全性的安全网，同时也使开发人员能够更快地创新和交付。

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

然后，DevOps 团队可以防止整个 CI/CD 管道中的错误配置，并向开发人员提供补救建议，无需人工干预。借助 Fairwinds Insights，管理整个企业中的多个集群和团队变得更加容易，而且在许多情况下是可能的，因为它将开源工具操作到一个平台中，以实现更好的监督和管理。

要了解更多信息，请查看我们关于 Kubernetes 错误配置的白皮书。你可以随时在这里免费下载。

新冠肺炎黑客马拉松:推销你的疫情应用创意

原文：https://www.fairwinds.com/blog/covid-19-hackathon-pitch-your-pandemic-app-ideas

我们生活在一个前所未有的时代。当我们试图平衡我们独特的环境时，我们的生活被颠倒了。这就是我们 Fairwinds 鼓舞人心的团队发起新冠肺炎黑客马拉松的原因。

虽然我们不在抗击新冠肺炎的前线，但我们希望尽自己的一份力量，通过找到有影响力的解决方案，为共同利益做出贡献。Fairwinds 与 AWS、Datadog 和 GitLab 合作，利用 Kubernetes 工程和开发人员社区中的巨大才能和创新，宣布了一项竞赛，以鼓励创新思想家创建基于 Kubernetes 的 web 应用程序创意来解决疫情问题。

项目建议书

从现在开始到 2020 年 4 月 10 日，美国有想法的人可以提交他们的项目提案供考虑。提案可以是正在进行的项目或全新的想法，但所有参赛作品必须有助于解决以下至少一个问题。

减少新冠肺炎的传播
找到病毒的治疗方法
教育公众了解新冠肺炎
重建经济

黑客马拉松投票和获胜者

来自 Fairwinds、AWS、GitLab 和 Datadog 的代表将对比赛进行评判，并投票选出一个解决方案，该方案将于 2020 年 4 月 15 日公布。应用程序开发将向公众开放后立即开始。赞助公司将向获胜项目提供以下内容，帮助他们从想法转变为切实可行的解决方案:

AWS 将提供六个月的应用托管支持*
GitLab 将是项目所在地
Datadog 将提供六个月的免费监控*
Fairwinds 将提供为期六个月的免费 Kubernetes 托管服务*

通过访问以下 GitLab 链接并遵循提交说明，可以立即提交项目创意:http://covidhack.org/。

*时间框架可能会根据获胜项目的变量进行调整

CVE-2022-0185:如何识别 K8S 集群中有风险的内核版本

原文：https://www.fairwinds.com/blog/cve-2022-0185-how-to-identify-at-risk-kernel-versions-in-your-k8s-cluster

本周公布了 Linux 内核中的一个严重漏洞 CVE-2022-0185。该漏洞使得本地攻击者能够造成拒绝服务(系统崩溃)或执行任意代码。

内核修复于 1 月 18 日发布，并在 1 月 18 日发布的最新 Ubuntu AMIs 中可用。

识别 Kubernetes 集群中的内核版本

如果您是 Fairwinds Insights 用户，您可以使用 OPA 策略检查集群中的内核版本。请注意，这将需要为 OPA 作业添加额外的访问权限，以便能够获取和列出节点。如果你还不是 Fairwinds Insights 的用户，你可以在这里免费注册。我们可以让您使用该软件来帮助解决这一严重漏洞。

见解 OPA 政策

package fairwinds

allowedKernelVersion(elem) {
    v := elem.parameters.kernelVersions[_]
    elem.status.nodeInfo.kernelVersion == v
}

unsupportedKernel[actionItem] {
    not allowedKernelVersion(input)

    actionItem := {
        "title": "Kernel Version is Unsupported ",
        "description": sprintf("kernel version %s is unsupported", [input.status.nodeInfo.kernelVersion]),
        "severity": 0.5,
        "remediation": "Update the base image version.",
        "category": "Security"
    }
}

在你的 YAML 中，列出你将支持的版本。例如，如果在 AWS 中使用 Ubuntu AMI，这个内核版本由使用 AMI 的节点报告: 099720109477/ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-20220118

parameters:
  kernelVersions:
    - 5.11.0-1027-aws
targets:
  - apiGroups:
      - ''
    kinds:
      - Node

您可以使用以下命令检查节点状态中报告的内核版本:

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\n"}{end}'

CVE-2022-3602 和 CVE-2022-3786 OpenSSL 漏洞:扫描容器图像

原文：https://www.fairwinds.com/blog/cve-2022-3602-and-cve-2022-3786-openssl-vulnerabilities-scanning-container-images

2022 年 11 月 1 日，OpenSSL 公布了 OpenSSL 3 . 0 . 0-3 . 0 . 6 版本中的一对高严重性漏洞。该漏洞是一种缓冲区溢出，需要一组非常特殊的环境才能被利用。在某些情况下，有可能远程执行代码。但是，需要注意的是:

这发生在证书链签名验证之后，并且要求 CA 已经对恶意证书进行了签名，或者要求应用程序继续进行证书验证，尽管未能构建到可信颁发者的路径。

由于这需要 OpenSSL 服务器的错误配置或滥用 CA 颁发的证书，因此大多数系统不太可能容易受到这种攻击。此外，许多操作系统中的缓冲区溢出保护将缓解该漏洞。

引用 Rapid7 的博客中的 :

对于这两种情况，这些类型的攻击都不太容易被广泛利用。

我如何发现哪些容器是易受攻击的？

尽管被利用的可能性很低，但建议用户更新到包含该修补程序的容器的最新版本。fair winds Insights，一个 Kubernetes 治理平台可以帮助识别任何容器映像中的漏洞。

确定您在 Fairwinds Insights 中的薄弱环节非常简单:

导航到漏洞页面
单击所有图像选项卡
在搜索框中输入 CVE-2022-3602，然后按回车键
受影响的图像列表将出现在表格中

Fairwinds Insights Vulnerabilities page

如果你有兴趣了解 Fairwinds Insights 如何自动扫描容器漏洞，联系。

决定 Amazon ECS 与 Kubernetes 的容器编排

原文：https://www.fairwinds.com/blog/deciding-on-amazon-ecs-vs-kubernetes-for-container-orchestration

说到容器编排，Kubernetes 已经成为在生产中管理和运行容器化工作负载的事实上的标准。“开放性”是 Kubernetes 超越竞争对手的主要原因之一，主要是受其开源根源的驱动。Kubernetes 带来了一个蓬勃发展的开源生态系统，它利用了该平台的模块化设计。几乎每一个云提供商都将软件集成为本地服务，建立了一个被称为“托管 Kubernetes”的新类别。大玩家包括 AWS Elastic Kubernetes Service(EKS)、Azure Kubernetes Service (AKS)和谷歌云的 Kubernetes Engine (GKE)产品。

然而，像 AWS 这样的一些云提供商提供了额外的容器编排选项。亚马逊的弹性容器服务(ECS)就是一个例子，它是 AWS 平台的原生产品。在本帖中，我们将阐明 ECS、Kubernetes 和推荐方法的优缺点。

了解 AWS ECS 和 AWS Fargate

AWS ECS 有两种风格:由 Fargate 驱动的 ECS 和由 EC2 驱动的 ECS。

由亚马逊 EC2 compute 提供支持的传统 ECS 于 2015 年推出，旨在方便地在云上运行 Docker 容器。传统 ECS 为您的容器提供了对 EC2 计算选项的底层控制。这种灵活性意味着您可以选择运行工作负载的实例类型。它还将您与其他用于监视和记录 EC2 实例活动的 AWS 服务联系起来。

另一方面，Fargate 于 2017 年发布，作为一种无需管理底层 EC2 计算即可运行容器的方法。相反，Fargate 会自动计算所需的 CPU 和内存需求。如果您需要快速启动并运行工作负载，并且不想计算或找出底层计算选项，那么 Fargate 通常是一个不错的选择。

给定这些选项，ECS 在什么情况下有意义？

您的工作负载很小，对其他服务没有太多依赖
您希望您的工作负载是短暂的，只需要运行一段时间。
你看不到显著的架构变化
您有一个容器化的应用程序，需要快速启动并运行

比较这两种服务时，传统的 ECS 提供了最大的灵活性。一种可能的迁移途径是从 Fargate 开始，然后在您需要更高的运营敏捷性时迁移到传统的 ECS。

您是否已经超越了 ECS？

也就是说，在产品路线图和客户需求的驱动下，大多数公司的应用和服务都在增长。在这些情况下，ECS 可能无法满足您的容器编排需求。考虑以下业务情况:

云成本和资源效率变得越来越重要:如果您希望扩展工作负载并让它们持续运行，根据您使用的服务类型，ECS 可能会成为一个昂贵的选择。例如，Fargate 将底层计算抽象化，这意味着您在微调可能正在运行的实例类型方面控制较少。
您正在增加云中运行的应用和服务的数量:随着应用的发展，您的架构也在发展。就高效扩展和运营工作负载所需的资源而言，ECS 可能变得过于有限。

例如，Fargate 服务的启动时间可能会很慢，主要是因为您将计算决策留给了 Amazon，以支持更简化的操作体验。

退出计划

当您有少量服务时，在 ECS 上开始是非常好的，但当您需要灵活性和控制力时，请确保您有一个到另一个 PaaS 的退出计划，如 EKS 或 Kubernetes。

您不希望局限于一家云提供商:有时，您的首席财务官可能会要求您评估其他云提供商的成本节约措施。或者，您可能希望利用 AWS 之外的同类最佳服务。在任何情况下，您可能都希望能够灵活地选择您所选择的云提供商，尤其是随着云计算层随着时间的推移变得更加商品化。根据 2018 年 CNCF 调查，42%的受访者使用云原生技术实现云可移植性。
您希望变得更加敏捷:云原生技术能够实现更高的速度和更快的上市时间。容器有助于传递部分商业价值。然而，如果没有一个健壮的容器编排策略，您将冒着组织中多个团队采用不同模式的风险——这可能会在未来造成复杂性。

如果以上任何一种情况与你有关，那么考虑从 ECS 毕业到更现代的平台如 Kubernetes 的策略。在我们的下一篇文章中，了解更多关于 Kubernetes 的好处和摆脱 ECS 的选择:托管 Kubernetes 与亚马逊 ECS 的好处

演示:用 Astro 监控 Kubernetes 工作负载

原文：https://www.fairwinds.com/blog/demo-monitoring-kubernetes-workloads-astro

我是 Fairwinds 的现场可靠性工程师，我们提供软件和服务产品，帮助我们的客户在 Kubernetes 的世界中取得成功。在我们的最高接触产品中，我们将为您运行集群，并全天候监控该基础架构。在与如此多具有不同需求的集群和客户合作时，有必要使用工具来提高我们(和我们的客户)日常工作的效率。我们创建的许多软件都是开源的，以回馈我们经常利用的开源社区。Astro 是这些开源工具中的一个，也是今天的焦点。

首先，我想告诉你一点我职业生涯中的监测历程。10 年前，我的第一份工作是在一家大型公司，使用裸机服务器和一些虚拟机，但虚拟机主要用于开发和 QA。所做的大多数监控都是针对裸机的。在这一点上，我在监控和警报方面的经验是围绕着静态监控那些不经常改变的机器。我们谈论的是其中一些机器和应用程序的数百小时正常运行时间。

从裸机主机到容器和 Kubernetes 世界的转变要求我们重新思考一些关于监控的事情。在传统的裸机环境中，需要监控的机器数量通常是已知的，每个主机上的进程数量有限。轻松点。您只需在配置计算机时设置一次监视器，并从此依赖它们。

使用 Kubernetes 时，开发团队可以根据需要创建和销毁服务，这意味着您需要监控数量未知的服务。当使用手动定义的传统静态监控时，这就留下了一些需要改进的地方。根据应用程序的 SLA 和 SLO，您可能希望在应用程序行为不当时收到警报。另一方面，一旦服务从集群中删除，您就不需要继续监视它。当然，根据您或您的组织如何管理部署，情况可能并非如此，但不管怎样，让软件来管理这个过程更容易。

使用 Astro 监控 Kubernetes 工作负载

Datadog 的服务非常棒，为我们这些 Kubernetes 运营商免去了很多日常生活中的辛劳。在安装了 datadog-agent 之后，当涉及到度量收集时，大多数事情“只是工作”。我们构建 Astro 来补充 Datadog 服务，以便在 Kubernetes 的动态世界中自动监控工作负载。Astro 是一个在 Kubernetes 集群中运行的工作负载，它将根据工作负载上的注释或包含多个工作负载的名称空间创建一组已定义的监视器。Astro 提供了三个关键要素来大大简化显示器管理:

针对 Kubernetes 中运行的工作负载自动管理 Datadog 监视器的生命周期:给定配置参数，该实用程序将自动管理 Kubernetes 集群中所有相关对象的已定义监视器。随着对象的改变，监视器被更新以反映该状态。
逻辑绑定对象之间的相关性:Astro 能够管理给定名称空间内所有对象的监视器。这确保了显示器配置之间的更大一致性。
将 Kubernetes 对象中的值模板化到托管监视器中:托管 Kubernetes 对象中的任何数据都可以插入到托管监视器中。这使得警报信息更加丰富，并且可以使监视器更加针对具体的环境。

观看 Astro 的演示

副本

在这个演示中，我已经有了 Astro running，它是用我们提供的舵图安装的。我们在我的顶部窗格中跟踪 Astro 的日志，并在 Datadog 前端显示监视器。我们在这个演示中配置了 Astro，为任何部署创建一组监视器，注释为 astro/owner = astro。如果您愿意，可以将这个键值组合配置为其他值。您可以在这里看到，我已经将这个注释添加到我们的 nginx 部署中。我们会看到一条日志消息，提示应该创建监视器。如果我们刷新 Datadog 前端，我们可以看到这是真的！现在让我们删除注释，并验证 Astro 删除了监视器。

另一个值得注意的特性是绑定监视器的概念。在绑定监视器中，配置一组“绑定的”资源类型，比如部署，然后将配置的注释应用到名称空间，在本例中是 astro/admin-bound = astro。一旦应用到名称空间，任何与该名称空间中的绑定类型匹配的资源都将获得一组监视器。这使您能够灵活地监控给定名称空间中的每个部署。目前，Deployment 是添加 DaemonSets 和 StatefulSets 计划中唯一可用的资源类型。

如果我们从名称空间中删除注释，监视器就会消失

Astro 项目还很年轻，还在成长，社区也在随之成长。我们希望在我们的社区 slack 中看到你，甚至可能为 Astro 开一个 PR 来帮助我们使这个项目尽可能有用。

为什么 DevSecOps 只是 Kubernetes 服务所有权的一个花哨的缩写

原文：https://www.fairwinds.com/blog/devsecops-fancy-acronym-kubernetes-service-ownership

是的，软件开发正在成为世界上最突出和最关键的行业之一，但它仍处于自身发展的阵痛中——特别是当它涉及到开发、安全以及对更好的 Kubernetes 服务所有权的需求。DevSecOps 已经成为解决 DevOps 实践中安全性需求的一种方法，但这并不是想象这种文化和实践转变的唯一方法。

如果 DevOps 能够简化 Kubernetes的混乱局面，一个类似的成功秘诀就会出现。DevSecOps 和 Kubernetes 服务所有权都在为同一个最终目标而努力——为 DevOps 团队提供更多的自主权、速度和责任。但仍有大量工作要做。如果我们希望快速安全地交付代码，同时降低风险，DevSecOps 需要成为 Kubernetes 和微服务的安全管理的同义词。

发展警察的崛起

从历史上看，软件开发由几个团队组成，所有团队都朝着一个单一的目标努力——生产优秀的产品。尽管有这种共同的努力，开发过程本身通常采用孤立的方法，其中一个开发团队编写代码，一个质量保证团队测试代码，另一个运营团队将其部署到生产中。如今，安全团队也必须参与进来，以确保软件的质量和安全性符合所有现代标准和治理要求。

然而，这些孤立的小组导致了团队之间的摩擦、文化差异以及对更协作、更有效的工作流的需求。DevOps 曾经作为一种开发方法出现，以提高开发和运营之间的协调水平，DevSecOps 迅速跟进，以确保安全性集成到软件开发生命周期(SDLC)的所有阶段。对 DevSecOps 的这种演进已经在团队之间创建了更紧密的集成，并使从业者能够提高他们的速度，同时也将安全性融入到更大的过程中，而不是作为事后的想法栓上它。

服务所有权的现实

DevSecOps 并不是描述这种新兴问责模式的唯一方式。作为 DevOps“编码、发布、拥有”的理念，Kubernetes 服务所有权要求工程师对他们持有的代码和服务负责，从代码提交到生产再到部署。工程师们不再将代码交给运营部门或依赖可靠性工程(SRE)团队，而是从头到尾对他们创建的代码的安全性和可靠性负责。

随着团队的重组，以促进更快的移动和与客户更密切的关系，他们被期望建立对他们所支持的服务的完全所有权。在这种运营模式中，服务所有权涵盖从软件设计和开发到生产环境中的部署，再到最终管理软件的过时。这个 Kubernetes 所有权模型是高度可伸缩的，因为它允许团队快速交付和响应客户问题。然后，运营团队可以构建一个允许组织扩展的基础。

随着 DevSecOps 价值的增加，在整个开发过程中对安全性的需求也在增加。使用最佳实践，Kubernetes 服务所有权使这种“左移”成为可能，并实现了 DevSecOps 信徒所支持的变革类型——提高可靠性、成本效益和更好的应用安全性。

更好的前进方式

要了解更多有关 Kubernetes 服务所有权的基本要素以及 Fairwinds Insights 如何为您的组织带来更易于管理的体验，请阅读我们的Kubernetes 服务所有权完整指南。

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

Kubernetes Service Ownership@2x

Docker 是一个有价值的 DevOps 工具——值得使用

原文：https://www.fairwinds.com/blog/docker-is-a-valuable-devops-tool-one-thats-worth-using

Docker 是去年人们谈论最多的技术之一，其采用率正在迅速上升——这是有充分理由的。对于一些开发人员和操作工程师来说，Docker 可能看起来令人困惑和难以使用，但我认为它只是被误解了。在这里，我将解释 Docker 是什么，然后介绍为什么它对开发和运营有好处。

Docker 是什么？

Docker 是一个开源项目，可以在隔离的容器中自动开发、部署和运行应用程序。容器允许开发人员将应用程序与它需要的所有部分捆绑在一起，比如库和其他依赖项，并作为一个包运送。

Docker 既是一个守护进程(后台运行的进程)，也是一个客户端命令。它就像一个虚拟机，但在重要方面有所不同。首先，重复较少。每运行一个额外的虚拟机，就会复制 CPU 和内存的虚拟化，并在本地运行时迅速耗尽资源。Docker 非常擅长设置本地开发环境，因为它可以轻松地添加正在运行的进程，而无需复制虚拟化资源。第二，它更加模块化。Docker 使运行同一个程序的多个版本或实例变得容易，而没有配置问题和端口冲突。在虚拟机中尝试一下吧！

你可以使用像 Docker Compose 这样的工具，而不是单个或多个虚拟机。您可以将每个单独的应用程序和支持服务链接成一个单元，轻松地横向扩展单独的服务，而无需虚拟机的开销或每个服务的配置问题。它通过一个单一的描述性 YAML 文件来完成这一切，改善了开发体验，加速了软件交付并提高了性能。

因为 Docker 是一个开放的平台，任何人都可以对它的开发做出贡献，以构建目前还不可用的功能。最棒的是，Docker 提供了版本控制(免费！).

有了 Docker，开发人员可以专注于编写代码，而不用担心代码将在哪个系统上运行。应用程序变得真正可移植。您可以放心地在任何运行 Docker 的机器上重复运行您的应用程序。对于操作人员来说，Docker 是轻量级的，允许在隔离的容器中并行运行和管理具有不同需求的应用程序。这种灵活性可以增加每台服务器的资源使用量，并可以减少所需的系统数量，因为其开销较低，从而降低了成本。

为什么要用 Docker？

Docker 让 Linux 容器化技术变得简单易用。事实上，Docker 非常棒。

使用 Docker 的理由有很多。我将在这里集中讨论三点:一致性、速度和隔离。通过 一致性，我的意思是 Docker 为您的应用程序从开发到生产提供了一个一致的环境——您每次都从同一个起点运行。通过速度，我的意思是你可以在服务器上快速运行一个新进程。因为映像是预配置的，并且安装了您想要运行的进程，所以它消除了运行进程的挑战。所谓隔离，我的意思是默认情况下，每个正在运行的 Docker 容器都与网络、文件系统和其他正在运行的进程隔离开来。

第四个原因是 Docker 的分层文件系统。从基础映像开始，您对容器或映像所做的每个更改都成为文件系统中的一个新层。因此，文件系统层被缓存，减少了 Docker 构建过程中重复步骤的数量，并减少了上传和下载类似映像所需的时间。它还允许您保存容器状态，例如，如果您需要排除容器失败的原因。文件系统层类似于 Git，但是在文件系统级别。每个 Docker 映像都是层的特定组合，就像每个 Git 分支都是提交的特定组合一样。

Docker 使用的一些障碍是什么？

最大的障碍是现有的知识基础。一些开发人员可能没有完全理解 Docker 的实用性或简单性，可能认为它比实际情况更复杂。他们的工具包里可能还会有其他工具，比如(一种本地虚拟化技术)，虚拟服务器或者亚马逊机器镜像 (AMIs)。

按照这些思路，动手实验所需的时间可能很难获得。开发人员通常没有可用的时间或带宽来分配工程周期给新的东西，特别是当他们已经有一个工作解决方案的时候。可以理解，他们宁愿花时间开发他们的产品。

最重要的是，将当前的开发解决方案转化为文档化的开发解决方案需要思维的转变。举个例子，如果你把 Docker 想象成一个虚拟机或者一个无业游民的机器，你可能想往里面塞很多东西(比如服务、监控软件和你的应用)。那将是一个错误。你没有把很多东西放入一个 Docker 映像中；相反，您使用许多 Docker 容器来实现完整的堆栈。

换句话说，对于开发来说，你可以将你的支持服务容器与你的应用程序容器分开，它们可以运行在不同的操作系统和版本上，同时又可以链接在一起。

虽然您可能在实现基于 AMI 的方法方面有丰富的经验，但是您可能对容器本身如何工作和行为没有概念性的理解。Docker 的一个关键原则是图像不会改变。要进行更改，您将创建一个新图像，它可能具有相同的名称和标签。与虚拟机不同，在虚拟机中，您运行的每个命令都可能会改变下一个命令的起点，而 Docker 的映像永远不会改变，因此您每次运行映像时都有一个不变的起点，并且您可以放心，无论您在哪里运行它，它都会做相同的事情。

Docker 实际上并不难使用——而且物有所值

想想一个常见的本地开发工具，如流浪者。vagger 模仿了你的生产服务器，但是你可能会以版本、支持技术或网络差异而告终。当您将应用程序放入容器中时，运行容器的虚拟机变得无关紧要，容器本身就是您的构建工件。

当您将应用程序放在 Docker 容器中时，您可以确保您在本地测试的代码与投入生产的构建工件完全相同。应用程序运行时环境没有变化。这使得 Docker 从开发到生产都是一个出色的工具。

幸运的是，Docker 并不太难学。很好玩，学习曲线也比较小。

那么为什么它看起来很难使用呢？大概是因为你还没有机会尝试吧。在我的下一篇博文中，我将分享一些基本的 Docker 命令，让你越过起跑线。

下一个第二部分——Docker 比你想象的更容易使用！

Docker 比你想象的更容易使用

原文：https://www.fairwinds.com/blog/docker-is-easier-to-use-than-you-think

在我的上一篇博文中，我关注了为什么 Docker 对使用有益，以及为什么它在广泛的用例中提供了重要的价值。在本系列的第二部分中，我将重点讨论为什么使用它没有您想象的那么困难。

下面，我将分享一些基本的命令和例子来告诉你 Docker 是多么容易使用。首先，您需要在您的系统上运行 Docker。转到此处，按照与您的系统相匹配的说明进行操作。准备好了，我们就从最常见的 Docker 函数开始， docker run。

如何运行 Docker

Docker 在隔离的容器中运行进程(在本地或远程主机上运行的进程)。当您执行 docker run 命令时，运行的容器进程是独立的——它有自己的文件系统、自己的网络和自己独立于主机的进程树。

基本的 docker run 命令采用这种形式:

$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]

下面是一个运行 redis 映像的非常简单的示例:

docker run redis

如果您的主机上还没有 redis 映像，它会为您提取映像。看着每个文件系统层被并行下载，然后一个运行 redis 的容器启动。Ctrl-C 并再次运行该命令，您将会看到由于已经下载了映像，后续运行的速度有多快。

下面是另一个更复杂的例子，展示了如何运行一个 Python 3.0 (python3)图像:

docker run -p 8080:8080 python:3 python3 -m http.server 8080

我们来分解一下上面的命令:

docker run: run a docker container
p 8080:8080:将容器内部的端口 8080 映射到容器外部的端口 8080。
python:3:使用标签为 3 的 python 图像。本例中的 image:tag 组合表明该图像正在运行 python3。
python3 -m http.server 8080:在容器内部运行这个命令。

该命令运行 python3 二进制文件，加载 http.server 模块，并创建一个在端口 8080 上可用的 web 服务器。上面的 -p 选项映射了端口，应该允许您访问 http://localhost:8080 并查看运行容器内的目录列表。

如果您还没有在您的开发环境中运行 Python3，那么要执行多少步才能得到这个命令的等价物？

其他常见的 Docker 命令

还有更多的选项和命令，但这些将使您快速开始使用 Docker:

docker images:展示你的主持人是什么形象
docker ps:显示哪些容器
docker ps -a:显示所有正在运行或已经运行但尚未移除的容器
docker stop <container id>:停止正在运行的容器
docker rm <container id>:移除容器
docker rmi <image>:删除图像

有用的 Docker 运行标志

要在分离模式下启动容器，请使用 -d 标志。按照设计，当用于运行容器的根进程退出时，以分离模式启动的容器也会退出。

docker run -d -p 6379:6379 redis

将启动一个 redis 容器，在后台运行它并使其在 localhost:6379可用。

使用 docker ps 查找容器 ID， docker stop 停止它，使用 docker rm 删除它。

要发布或公开端口，请使用 -p 标志。

docker run python:3 python3 -m http.server 8080
http://localhost:8080/
http://localhost:8080/

在上面的第一个示例中，您没有打开容器中的端口(您无法访问正在运行的 Python 服务器)，而第二个示例演示了网络地址转换(您可以访问服务器)。

要绑定挂载卷，请使用 -v 标志。

下面的示例展示了这三个标志的用法:

docker run -d -v /docker/redis/data/:/data/ -p 3306:3306 redis

在这种情况下，容器内的路径'/data '被映射到主机上的 /docker/redis/data 。这是在 docker 运行之间保存状态的一种方式。

如何从 Docker 获取日志

docker logs 命令获取容器的日志。

该命令采用以下形式:

docker logs [OPTIONS] CONTAINER

如何运行 Docker 交互式 Shell

标签 –it 使您能够在运行的容器上交互并打开外壳。它创建了一个交互式的附加终端。

下面的例子展示了如何在 Ubuntu 映像中运行交互式 shell:

docker run -it ubuntu bash

图像、容器和存储库

Docker 映像是文件系统层的集合，相当于一个固定的起点。运行映像时，它会创建一个容器。从初始映像所做的一组更改稍后会成为一个附加的文件系统，并且可以提交容器，此时它会成为一个新的映像。存储库是存储图像的地方。

docker pull 和 docker push 命令将使您能够与您的存储库进行交互，以执行对接拉或对接推。使用 docker pull 将容器映像从注册表下载到本地缓存中，这样您就可以基于映像启动容器。使用 docker push 将您的图像共享到 Docker Hub 注册表或自托管注册表。

如何使用 Dockerfile 构建图像

一个图像通常用一个docker file来定义，它包含了你可以在命令行上调用的所有命令来组装一个图像。每个图像都从一个基础图像开始，比如 ubuntu(一个基础 Ubuntu 图像)。

docker build . -t <whatever you want to name the image>

Docker 通过读取 docker 文件中的指令来构建映像。这一部分很重要:docker 文件中的每个 docker 命令代表一个文件系统层。每次构建映像时，它将使用以前构建的缓存层。docker 文件中的任何一行发生变化都会使其下所有命令(和层)的缓存失效。

那是什么意思？

让我们假设你有一个简单的项目。你要把一个 simple_script.sh 放入 Docker 镜像，而 simple_script.sh 依赖于 telnet。您需要将脚本复制到映像中并安装 telnet。

如果我们的 docker 文件是:

FROM ubuntu
COPY simple_script.sh /
RUN apt-get update
RUN apt-get install -y vim
CMD “bash simple_script.sh”

然后每次更新 simple_script.sh，构建过程都会再次运行 apt-get update 和 apt-get install 。这将很快过时，因此您可以将 docker 文件重组为:

FROM ubuntu
RUN apt-get update && apt-get install -y vim
COPY simple_script.sh /
CMD “bash simple_script.sh”

你已经完成了两件事。首先，通过使用 && 操作符并结合 apt-get update 和 apt-get install 命令，文件系统的层数减少了一层。第二，当你现在更改 simple_script.sh 并运行 docker build 时，apt 命令会被缓存，后续构建只需要添加 simple_script.sh。这加速了发展，让每个人都更开心。

开始使用 Docker

你可能仍然对使用 Docker 犹豫不决。可以理解。要克服任何感觉到的障碍，从小事做起，从简单做起。从简单的流程开始，在有限的范围内使用这些流程——记住，您希望每个容器运行一个流程。

Docker 是一个非常棒的工具。我希望您能尝试一下上面的命令，并决定利用 Docker 提供的所有好处。

码头工人已经死了。Kubernetes 万岁！

原文：https://www.fairwinds.com/blog/docker-swarm-is-dead-long-live-kubernetes

在不久的将来，Docker 将承认 Docker Swarm 已经失败，他们将不得不把发言权让给 Kubernetes。要么这样，要么他们会在失败策略上加倍下注。

【Kubernetes 获胜的原因有很多，但为了简单起见，我在这里将它们精简为几个:

1) Kubernetes 有社区支持

Kubernetes 已经成为历史上最受欢迎的开源项目之一。它就在 Linux 内核、Chromium 和自制软件的上面。考虑到大量的社区参与，该项目正在以惊人的速度进行，不断改进，发布可预测的版本，并向右上方移动。关于提交、提交者、拉请求等....毫无疑问，这是最近历史上最重要的开源项目之一。

部分是由于机构群体的支持:

2) Kubernetes 在技术上更胜一筹

Kubernetes 和 Docker Swarm 都有相同的核心方法。两者都支持服务的声明性定义，这些定义被负载平衡回可变数量的容器，并与容器中安装的配置设置相结合。两者都通过优雅地将服务转移到工作节点或扩展到新节点来处理节点加入和离开群集。

然而，库伯最终胜出的那一天 :

更好的运行状况检查，在 Pod 级别定义了活动和就绪探测器，而不是内置于映像中。
与云服务集成，无缝使用负载平衡器、块存储和实例运行状况。
通过亲和和反亲和、DaemonSets、自动扩展、sidecars、污染和容忍以及部署更新策略，实现更好的容器调度和扩展。
具有基于角色的访问控制的名称空间。
控制服务间进出流量的网络安全策略。
具有运算符和自定义资源定义的可扩展性

3)码头工人群体被错误地激励

作为一家风险投资支持的公司，Docker Swarm 需要为 Docker 赚钱，这意味着最好的功能最终将不得不以高价提供，并被开源社区拒绝。Kubernetes 是由谷歌建造和支持的，谷歌有足够的资金，他们可以让数百名工程师从事这项工作，并且永远不需要对他们建造的任何东西直接收费。

可能曾经有过 Docker Swarm 和 Kubernetes 是同行的世界，但是 Kubernetes 赢了，在市场上继续赢。码头工人已经死了。库伯内特万岁。

不要忘记检查 Kubernetes Pod SecurityContext 中的 readOnlyRootFilesystem

原文：https://www.fairwinds.com/blog/dont-forget-to-check-kubernetes-pod-securitycontext-for-readonlyrootfilesystem

在 Kubernetes 中运行安全的工作负载具有挑战性。Kubernetes 使工程师能够使用 securityContext 字段配置容器的安全特性。使用这个 Kubernetes 安全上下文来保护 pods 可以确保每个资源都拥有它所需要的权限，同时也避免了过度许可的陷阱。安全上下文在粒度级别上定义权限，始终遵循最小特权原则。也就是说，您可以使用安全上下文定义的许多安全规则也可以通过 pod 安全策略来配置，这不是同一个工具。

为什么两者都有？因为安全上下文是 pod 安全策略的替代品，而 pod 安全策略可用于为 Kubernetes 集群中运行的所有 pod 配置权限，所以与可应用于单个 pod 的安全上下文相比，安全上下文提供的控制粒度更小。

安全 Pod 策略

Kubernetes 中的 pod 安全策略是一个集群级资源，它控制 pod 规范的安全敏感方面。这些策略定义了运行系统将接受的 pod 所需的一组条件，以及相关字段的默认值。虽然PodSecurityPolicies通过启用准入控制器来实施，但是如果最初没有授权适当的策略，则不会在集群中创建 pods。

控制容器是否能够写入其文件系统的一个设置是 readOnlyRootFilesystem ，如果可能的话，您肯定希望启用该功能，以便为您的容器化工作负载提供额外的深度防御。如果攻击者或不良分子设法破坏集群， readOnlyRootFilesystem 将防止他们篡改应用程序或将可执行文件写入磁盘。

最佳实践

Kubernetes 安全最佳实践提供了关于如何为 pod 或容器配置 readOnlyRootFilesystem 的指南。是的，这个特性对于 Kubernetes 的安全性至关重要，但是如果用户没有部署一个将 securityContext 设置为 readOnlyRootFilesystem 的 pod，会发生什么呢？在理想的情况下，您的团队能够识别这个问题并应用适当的策略。最糟糕的情况是，您的 pod 被破坏和损害，这意味着需要立即识别未以只读方式运行的 pod。

具有洞察力的自动检查

手动检查每个 pod 的安全上下文有一个问题——很容易出现人为错误，更不用说这非常耗时。使用策略执行工具自动化该过程可以大大降低 Kubernetes 的安全风险。

Fairwinds Insights ，我们的 SaaS 治理平台为 Kubernetes 提供解决方案。作为一个策略驱动的配置验证平台，Insights 帮助负责 Kubernetes 的团队识别何时设置了不正确的安全上下文。Fairwinds Insights 的客户可以在流程的每个阶段实施这些护栏和反馈循环——在拉动请求、部署时，以及针对集群中已部署的工作负载。

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

根据您组织的要求，Fairwinds Insights 会自动扫描集群，以检查缺失的安全上下文。这意味着您的团队可以节省定位特权容器的时间，这些时间可用于修复问题。

安装 Insights 代理后，您将在 10 分钟内收到结果。当security context . readonlyrootfilesystem不为真时，Insights 会给出警告。Fairwinds Insights 还确保在整个部署过程中执行策略，因此为每个 pod 设置了安全上下文。这一举措通过扫描从 CI/CD 到生产的配置，减少了安全事故。Insights 还致力于确保整个企业的所有团队都遵循 Kubernetes 安全最佳实践。

使用 Ansible 在 AWS 上轻松加密根卷

原文：https://www.fairwinds.com/blog/easily-encrypted-root-volumes-on-aws-with-ansible

AWS 上的根卷是否需要加密是一个争论的话题。加密的 AMI 完全是为了保护静态数据。

静态加密针对三种情况提供保护:

包含根卷的磁盘从 AWS 数据中心被盗
亚马逊回收磁盘时没有正确销毁
AWS 基础设施代码中的某种泄漏，允许另一个实体访问您的卷

这三种情况都不太可能发生，但(和生活中的大多数事情一样)没有任何保证。我们的一些客户并不保存需要加密的敏感信息。但是，其他受托管理此类数据并受法规约束的人要求加密。

一度，加密数据卷只是(很容易)可能的。许多人使用这些额外的卷来存储敏感信息，避免写入根卷。然而，在 2015 年末，AWS 宣布了加密的 EBS 引导卷——这是一个很好的功能，弥补了实例加密方面的差距。对于有法规遵从性要求的组织来说，加密 EBS 启动卷不仅仅是一项功能，而是一项必备功能。

创建加密的 EBS 卷简单明了:

找一个你想作为基地的 AMI
将 AMI 复制到您的 AWS 帐户，并选中 Encrypted 框
使用新的加密 AMI 作为实例的引导卷

您可以从这个 AWS 博客中找到如何创建加密 EBS 卷的命令行示例。

在 Fairwinds ，我们喜欢进一步自动化。由于我们使用了 Ansible ，我们将创建加密 AMI 的角色放在一起。除了处理副本之外，这个角色还将帮助您找到一个用于加密 AMI 的基本 AMI。(你可以在我们的 Fairwinds GitHub 页面上找到这个角色。如果您正在进行根卷加密，我们希望这个角色将会证明是有用的。)

简而言之，对于那些有法规要求的人来说，加密是显而易见的。如果你能选中“所有数据都加密”框，许多问题就迎刃而解了。

对于那些持观望态度的人，我将提供这个经验法则:如果您加密您的数据卷，您也应该加密根卷。毕竟，为什么要在前门上三个插销，然后让后门开着呢？

缓解 Kubernetes 开发、安全和运营之间的紧张关系

原文：https://www.fairwinds.com/blog/easing-the-tension-between-kubernetes-development-security-and-operations

随着组织开始在 Kubernetes 中开发任务关键型应用程序，他们需要一种方法来确保配置最佳实践在组织范围内得到一致应用。如果没有一种简单的方法来确保配置的安全性和应用程序对资源的高效利用，组织就有可能失去采用 Kubernetes 所承诺的所有战略收益。

下面是我们看到的组织在企业中实施 Kubernetes 时面临的三个主要挑战。

1。安全。安全团队和开发团队有不同的目标——安全团队希望降低风险，开发团队希望尽快将新功能投入生产。除了有不同的动机，他们也有不同的专业领域——应用程序开发人员不太熟悉潜在的 Kubernetes 安全问题；安全团队不太熟悉应用程序开发。

2。资源效率。应用程序开发人员通常不参与关于他们的应用程序运行成本的具体讨论。因此，在定义工作负载的 CPU 或内存使用限制时，应用程序开发人员通常采用最简单的方法，给每个工作负载设置远远超过实际需要的限制。在整个企业中，这导致应用程序的成本超出了必要的范围。

3。可靠性。安全性和资源定义问题会直接影响应用程序的可靠性，但其他配置问题也是如此，如确保 Kubernetes 健康检查和自我修复功能设置正确。

Kubernetes 配置验证弥合了差距

配置验证平台有助于弥合应用程序开发人员、安全团队和运营团队之间的激励和知识差距，以便他们能够共同努力，确保在整个组织范围内正确管理配置。

集中控制意味着安全团队和平台团队可以看到所有工作负载的配置，轻松发现必要的更改，并与应用程序开发人员交流这些更改。

检查和平衡意味着有人总是在检查配置是否正确完成，减少了出错的风险，促进了团队之间的知识共享。

管理 Kubernetes 配置的安全性、效率和可靠性

了解 Kubernetes 配置验证如何帮助组织构建更安全、更可靠的应用程序，高效利用云资源，包括:

为什么配置验证对于确保组织从 Kubernetes 获得他们期望的敏捷性和效率非常重要
如何确保加快开发速度不会导致安全漏洞
为什么集中了解配置是确保整个组织遵守最佳实践的关键

探索组织控制其配置的各种选择，以及为什么专门构建的平台通常是最佳选择。使用 Fairwinds Insights，在一个平台中免费获得 Kubernetes 安全性、成本分配和规避、合规性和护栏。

使用 Saffire 消除作为 Kubernetes 单点故障的注册表

原文：https://www.fairwinds.com/blog/eliminate-the-registry-as-a-single-point-of-kubernetes-failure-using-saffire

你遇到过这种情况吗？你正在经营一个由法兰绒作为 CNI 的 kops 集群，而 Quay 经历了一整天的停电。突然，你的自动伸缩 Kubernetes 集群这台运转良好的机器嘎然而止。新节点从不加入集群，其他随机服务无法启动。

您已经成为 Kubernetes 集群中为数不多的单点故障的牺牲品:容器注册。这看起来似乎是一件奇怪的事情，要编写一个完整的工具来解决，但在 Fairwinds 这个问题让我们非常头疼，并在我们为客户运行的几十个集群中浪费了时间。如果今天它不是码头和法兰绒，明天它将是另一个集群关键服务。

Saffire 简介

Saffire 是一个在集群中运行的控制器，它会监视在提取底层映像时遇到问题的 pod。当它找到这些窗格时，它将尝试修补拥有该窗格的对象，并用您指定的替换对象替换图像规范。因此，在映像拉取失败后的几秒钟内，您的工作负载就可以在从不同的注册表拉取的映像上愉快地运行了。

它是如何工作的？

Saffire 创建了一个您可以部署的自定义资源定义，它指定了被认为与该名称空间中的映像等效的注册表列表。再加上我的一个朋友兼同事写的一个名为 controller-utils 的包，Saffire 可以找到发生故障的 pod 的顶层控制器，并用新的图像源修补它们。

这难道不需要我做些计划吗？

是的！你将不得不同时把你所有的图像推送到两个存储库。你可能想知道为什么 Fairwinds 选择这种方法，而不是像拉通缓存或镜像我们所有图像的集群内注册表这样的东西。这里有几个原因:

1。我们希望避免运行我们自己的基础架构来解决这个问题。

我们一直在寻找一种 Kubernetes 本地方法，不需要我们运行长寿命、高维护的基础设施。

2。我们希望尽可能利用现有的服务。

Google Container Registry (GCR)、Amazon Elastic Container Registry(ECR)、Quay 和 Docker Hub 都是很棒的服务，它们相对来说很少出现宕机。有了 Saffire，你仍然可以使用这些服务，只是你不再依赖单一的服务。

名字怎么回事？

在 Fairwinds，我们喜欢上了以太空为主题的名字。当我们最初将命名为北极星时，我们陷入了不断困扰库伯内特社区的航海主题。但是北极星让我们在海洋和太空之间架起了一座桥梁。从那以后，我们创造的所有工具都是以太空为主题的。

Saffire 指的是美国宇航局为了测试火在宇宙飞船和空间站上的表现而进行的一系列任务。这似乎是一个合适的名字，一个在我们的 Kubernetes 环境中减轻火灾的工具。

希望你喜欢

前往Saffire的 Github 仓库，如果您有任何问题，请告诉我们！

启用云原生服务所有权

原文：https://www.fairwinds.com/blog/enable-cloud-native-service-ownership

云原生服务所有权的重要性始于消费者，始于满足他们对服务能够简单工作的期望。这意味着无论你提供什么样的服务，都必须可靠、快速，如果有停机时间，也必须尽可能短。拥有全面的服务所有权，团队可以提高责任性、可靠性，并对应用程序和服务进行持续改进，因为任何足够大的组织都无法通过运营团队来控制所有事情。

采用云原生解决方案使 DevOps 团队能够真正拥抱“编码、发布、拥有”的心态，也就是所谓的全面服务所有权。正如opensource.com所写:

全面服务所有权是工程师对他们在生产中创建的代码和服务负责的理念。使用“编码它，运输它，拥有它”的心态意味着接受 DevOps 原则，不再将代码扔向操作系统，也不再依靠站点可靠性工程(SRE)团队来确保服务的可靠性。

在安全圈里所有关于 DevSecOps 和“左移”需求的讨论中，服务所有权是确保这能够实际发生的一种强有力的方式。

服务所有者需要做什么？

服务所有者负责开发、交付给生产，并拥有他们的服务。这意味着很多责任，包括:

确保应用的可靠性和性能
提供新功能
充当安全团队的联系人
修复和修补代码中的错误和漏洞以及容器中的错误配置
计划员工回答问题的时间
保持文档更新
确保可观察性
规划和适应能力

挑战在于，这可能是很难实现的，因此团队很难真正接受服务所有权的思想。一些研究显示，最常见的挑战是文化问题、缺乏工具，以及对基础架构团队向服务所有者移交责任的内容和方式的理解存在差距。

此外，除了编码、运输和拥有之外，当由于安全风险而需要漏洞补丁时，服务所有者是否有责任？安全团队如何知道风险正在被处理？在云原生环境中，开发运维与安全性之间缺乏可见性是一个真正的问题。一个 Splunk 博客说:

虽然在理论上，DevOps 意味着每个人都“拥有”软件交付领域内的一切，但现实是很少有组织能够做到这一点。让每个工程师都掌握代码库或部署的每个部分是不现实的。”

但是，如果有合适的工具来支持开发、运营和安全团队中的每个人，服务所有权是可能的。

重置云原生的服务所有权

John Laban 写道:“如果我们想更快、更安全、风险更小地重新发布代码，我们需要重置 DevOps，使其成为服务所有权的同义词。”这种重置服务所有权的呼吁也是对许多人的一种呼吁，要求他们首先接受它。

当使用容器和 Kubernetes 时，服务所有权可以真正帮助拥有多个团队和多个集群的组织。例如，如果您是一个拥有 40 个集群的组织，并且宣布了一个 CVE，那么谁负责确定修补漏洞的方法，然后检查每个集群配置，以确保应用了补丁，并且您的组织不会因该 CVE 而面临风险？

开发运维团队需要:

建立策略来确定谁获得应用程序的哪些部分的服务所有权
获得服务所有权的可见性，以监控集群中发生的情况
支持跨 Kubernetes 和容器的服务所有权

Fairwinds Insights 支持云原生服务所有权

如果您有多个团队和多个集群，cloud native service ownership可以帮助您更快、更经济高效、风险更低地交付应用。Fairwinds Insights 通过简化复杂性和实现全面的服务所有权，统一了开发、安全和运营。为了帮助团队克服文化挑战并接受服务所有权，Insights 能够:

支持— 通过使用洞察，开发团队可以拥有安全和效率配置—因此这不仅仅是一个运营问题。
可靠性— 借助洞察力，服务所有者可以按照最佳实践配置 Kubernetes，以确保快速、可靠的应用并避免停机。
持续改进— 通过整合从 CI/CD 到生产的服务所有权，Insights 使您的团队能够持续改进 Kubernetes 的使用方式。

Fairwinds Insights 通过提供集群的仪表板视图，使您的 DevOps 团队能够了解您的 Kubernetes 环境；帮助团队理解导致安全和合规风险的错误配置；并减少漏洞管理所需的时间。它还通过识别错误配置和漏洞，并将所有权分配给负责解决这些问题的个人或团队，来帮助团队处理管理文化变化的一些更棘手的方面。

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

了解更多有关 Fairwinds Insights 如何通过票务集成、策略实施、安全性和漏洞管理帮助组织成功采用云原生服务所有权的信息。

环保 Ep.1 |关于 DevOps ft 的未来你应该知道的事。凯尔西·高塔

原文：https://www.fairwinds.com/blog/environmentally-friendly-episode-1-with-kelsey-hightower-34_58

为什么您需要建立更好的 Kubernetes 安全性

原文：https://www.fairwinds.com/blog/establishing-better-kubernetes-security

到目前为止，云原生世界中的大多数人至少知道一些关于成功的 Kubernetes 服务所有权的好处。作为打破孤岛和最小化团队间摩擦的一种方式，Kubernetes 中的服务所有权使当今的组织能够基于云原生技术构建和交付安全、高质量的软件。本博客探讨了与更好的服务所有权相关的五个主要好处，同样重要的是，组织如何通过采用这种运营模式来优化 Kubernetes 的安全性、成本、合规性、可靠性和可扩展性。

在这个列表的顶部徘徊是当今云原生环境中最大的担忧之一，即需要更好的容器安全性。如果您的组织曾经因为 Kubernetes 安全漏洞而推迟应用程序部署，那么您已经对云原生安全性的敏感性有所了解。为了保持容器工作负载(尤其是在生产环境中)的安全性，必须不断解决漏洞和平台依赖性。为了实现这一点，Kubernetes 的最佳实践和真正的服务所有权必须在整个组织中实施。

下载白皮书:更好的 Kubernetes 服务所有权的 5 个好处

建立和启用安全性

今天的容器安全性不仅仅是将 Kubernetes 节点隔离在一个单独的网络上。从对 API 服务器使用第三方身份验证，到启用基于角色的访问控制(RBAC)，再到使用 TLS、防火墙和加密保护 etcd，在 Kubernetes 中促进强大的安全态势都与协调有关。尽管应该为节点配置入口控制器，并设置为仅允许来自主节点的连接通过网络访问控制列表，但事实上并非所有组织都已将这些常规做法编成法典。

为了保持敏捷性并防止容器运行时和应用程序部署中的延迟，云原生环境的安全覆盖需要一致地发生，而不是事后才想到。与 DevSecOps 的应用程序安全方法非常相似，Kubernetes 服务所有权模型使开发人员能够在整个开发生命周期中对他们构建的软件承担责任和“所有权”。当开发团队发现可以更好地控制他们的软件在生产中的运行方式时，运营团队可以不再担心调试，而是专注于核心的 Kubernetes 基础设施。这种责任的重新转移有助于开发、安全和运营团队更有效地协作，同时还改进和实施最佳安全实践。

有效的 Kubernetes 安全性始于构建阶段，从保护容器映像开始，全程关注。Kubernetes 中的云原生和服务所有权建立了一个框架，开发人员通过该框架可以了解配置和应用程序代码中的安全问题。通过这种方式，开发人员能够进行创新，同时将安全性转移到在流程的更早阶段解决和修复问题。这种转变保证了 Kubernetes 的安全性在尽可能早的时间得到解决，这是 DevSecOps 方法的核心主题。

拥抱和模拟变化

在云原生和容器安全的情况下，忽视对不同安全工具的需求通常会导致组织风险和潜在的网络攻击。当企业致力于采用 pod 安全策略时，他们常常苦于没有合适的工具、流程和基准来大规模推出安全的开源系统。是的，容器提供了一种部署应用的全新方法，这极大地改善了整体部署，但开发人员和安全团队并不总是知道迁移到微服务将如何影响他们的 Kubernetes 安全立场。

当我们采用新的工具和流程时，我们也为新的安全盲点和攻击面打开了大门，使得跨容器和集群的可见性越来越难以发现。因此，开发人员不愿意承担这些新的安全挑战的责任是可以理解的，尤其是在没有适当的安全工具、实践和内部支持的情况下。通过 Kubernetes 服务所有权模型，这种转变变得更加容易，因为它为开发团队提供了他们所需要的洞察力，以确保容器安全性在整个软件开发过程中正常进行。

采用服务所有权模型也为基础设施团队带来了变化，允许他们主要关注核心 Kubernetes 框架的安全问题。这些团队能够制定策略和合规性仪表板，以避免错误配置的常见陷阱。相应地，开发人员在构建部署配置时，能够专注于遵守这些 pod 安全标准。

当这些不同的角色和职责通过服务所有权模型被编码时，它们就变成了常规的实践——更少的混淆和更容易实现。通过为基础设施和开发团队配备自助工具，他们能够更高效地协作，同时根据最佳实践对 Kubernetes 安全性进行诊断和分类，从而减少攻击面。

Fairwinds 的治理平台可以提供帮助

Fairwinds 是您在 Kubernetes 安全、政策和治理方面值得信赖的合作伙伴。客户能够以更低的成本和总体风险更快地交付云原生应用。我们通过消除摩擦和简化 Kubernetes 所有权的复杂性来提供团队之间的统一视图。我们的治理软件 Fairwinds Insights 构建于来之不易的 Kubernetes 专业知识之上，集成了我们领先的开源工具，可帮助您的组织在不影响安全性的情况下节省时间和资金。

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

Fairwinds Insights 通过简化复杂性和实现全面的服务所有权，统一了开发、安全和运营。为了帮助团队克服文化挑战并接受服务所有权，Insights 促进了:

支持:开发团队在他们的应用程序中拥有安全和效率配置，所以这不仅仅是一个运营问题。
可靠性:服务所有者可以使用最佳实践指南配置 Kubernetes，确保快速、可靠的应用程序并避免停机。
持续改进:团队可以通过集成从 CI/CD 到生产的服务所有权来持续改进 Kubernetes 的使用方式。

Fairwinds Insights 通过提供所有集群的仪表板视图，帮助团队了解导致安全和合规性风险的错误配置，并通过集成的漏洞扫描减少漏洞管理所需的时间，从而为开发运维团队提供 Kubernetes 环境的可见性。它还通过识别错误配置和漏洞，并将所有权分配给负责解决这些问题的个人或团队，来帮助团队解决管理 Kubernetes 的一些更具挑战性的方面。

行动项目

行动项目是 Fairwinds Insights 的核心。每个审计工具都可以生成一个或多个操作项，这取决于它在集群中找到了什么。当特定的措施项从报告中消失时，它将自动标记为已修复，并将从默认的措施项视图中消失。

准入控制器

Insights 提供了一个用户界面，可以查看准入控制器。这种能力使团队能够一次编写，随处部署。使用策略即代码的最佳实践，在 CI 管道中以及在部署时应用策略来防止错误配置
进入集群是很简单的。

团队访问控制和用户管理

Insights 允许管理员将用户分配到集群中的特定名称空间，从而实现访问控制。将用户添加到现有组织的管理员还可以选择是查看所有集群还是仅查看特定集群。管理员还可以通过用户界面控件管理命名空间访问。

为了帮助分类行动项目，Insights 管理员可以将它们分配给组织中的任何用户，并且可以单独或批量分配它们。用户还可以查看其集群的运行状况得分、按名称空间和报告汇总的行动项目、热门行动项目、成本摘要、分配的行动项目等。

阅读Kubernetes 服务所有权完整指南，了解更多关于 Kubernetes 服务所有权以及 Fairwinds Insights 如何实现这一点的信息。

你现在需要知道的关于 Kubernetes 所有权的一切

原文：https://www.fairwinds.com/blog/everything-you-need-to-know-about-kubernetes-ownership-right-now

今天，Kubernetes 服务所有权是软件交付和运营团队对他们支持的服务拥有完全“所有权”的一种新兴方式。在这个模型中，所有权跨越了从软件设计和开发到生产环境中的部署，并最终管理软件的日落。这种责任的转变极大地提高了应用程序的速度、可靠性、成本和安全性。

也就是说，并不总是清楚什么样的组织需要这种程度的组织转变。随着组织的成长，他们经常发现推动应用程序和服务的交付通过一个操作关口是一项挑战，如果不是不可能的话。但是，随着 DevSecOps 方法的价值不断增长，团队现在正在寻找在他们的工作流中实现这种转变的方法。作为 DevSecOps 的推动者， Kubernetes 服务所有权使这一根本性的变化得以发生。

关于 Kubernetes 服务所有权，我需要了解什么？

了解 Kubernetes 环境的配置哪里不符合行业标准和最佳实践非常重要。以部署为例。它们可能看起来工作得很好，即使没有简单的活性和就绪性探测，或者没有资源请求和限制设置。但事实是，忽略这些配置设置最终会导致灾难。

关于安全性，发现 Kubernetes 部署何时被过度许可至少是一个挑战。事实上，许多团队确实过度使用容器和集群，主要是因为让某些东西工作的最简单的方法是提供 root 访问权限——这意味着完全的管理权限。这样，配置会给 Kubernetes 环境带来重大的安全风险。

另一方面，当适当的治理到位时，Kubernetes 服务所有权可以帮助组织以更低的风险更快地交付代码，尤其是具有多个团队和集群的企业。对于一个运行 40 个集群的公司来说，实现良好的服务所有权可能意味着知道谁负责修补漏洞和安全故障之间的差别。这种所有权的明确指示还确保了正确的团队或开发人员将检查集群配置并在需要时应用补丁。服务所有权可以帮助每个开发团队成功地在 Kubernetes 上获得应用程序。

谁需要这种类型的服务所有权？

尽管服务所有权的好处很有价值，但它不一定是每个企业的正确模式。例如，只有一个应用程序、一个 DevOps 工程师和一个小型开发团队的小型创业公司可能不需要服务所有权。通常，操作仍然可以拥有所有的部署配置，不管它们是否运行在 Kubernetes 上。

但是随着组织的成长，对服务所有权这样的模型的需求也在增长。在运行数十个集群的企业中，运营团队管理每个应用程序的所有部署配置的“所有权”并不罕见。这就是 Kubernetes 服务所有权能够提供真正价值的地方，因为它使开发人员能够在一个集中的团队之外掌控他们的应用程序的配置方式。虽然这通常发生在运行集中式 Kubernetes 平台的大型组织中，但是有效所有权的模型可以应用于许多业务实例。在拥有数百甚至数千个集群的组织中，如果没有某种服务所有权，扩展几乎是不可能的。

一个不太常见的场景包括开发团队获得完整的全栈所有权。虽然这通常发生在小团队中，但是公司本身可以是大的或小的。事实上，65%的公司在生产中使用 Kubernetes。根据最近 2021 年的一项研究，拥有超过 500 名开发人员的企业更有可能(78%)在生产中运行所有(或大多数)容器化的工作负载。

如何启用 Kubernetes 服务所有权？

Fairwinds Insights 通过简化复杂性和实现全面的服务所有权，统一了开发、安全和运营。为了帮助团队克服文化挑战并接受服务所有权，Insights 促进了:

支持 —开发团队可以了解其应用中适当的安全性和效率配置，这不仅仅是一个运营问题，因为开发团队现在知道适当的配置是什么样的。
可靠性 —服务所有者可以使用最佳实践指南配置 Kubernetes，即使他们并不十分了解 Kubernetes，也能确保快速、可靠的应用并避免停机。
持续改进 —团队可以通过从 CI/CD 到生产过程中集成服务所有权来持续改进 Kubernetes 的使用方式，实际上可以从交付到生产过程中阻止中断的部署。

fair winds Insights通过提供所有集群的仪表板视图，帮助团队了解导致安全和合规性风险的错误配置，并通过集成漏洞扫描减少漏洞管理所需的时间，从而为开发运维团队提供对 Kubernetes 环境的可见性。它还通过识别错误配置和漏洞，并将所有权分配给负责解决这些问题的个人或团队，来帮助团队解决管理 Kubernetes 的一些更具挑战性的方面。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

弥合鸿沟:卓越的应用性能需要开发洞察和运营权衡

原文：https://www.fairwinds.com/blog/exceptional-application-performance-requires-dev-insight-and-ops-weigh-in

想象一下这个–运营团队花了几个月的时间来了解来之不易的技术瓶颈和特定于应用的性能问题，却发现在新功能发布从根本上改变了应用的运行方式后，这些知识不再有效。结果呢？减速、错误和崩溃。

这种情况很常见。开发组织面临着以光速发布软件的压力，这使得开发和运营团队之间的对话在最好的情况下似乎是一种奢侈，在最坏的情况下似乎是关键资源的脱轨。

为什么我们不能好好相处呢？

当开发人员和运营人员不沟通时，开发人员可能会发现环境并不适合他们正在构建的产品和功能，这可能会导致应用程序性能和可用性问题，或者许多其他代价高昂的低效问题。反过来，运营团队可能不了解应用程序需求，从而过度调配(或者更糟，调配不足)资源。这种对 IT 环境缺乏可操作的洞察力会导致应用程序运行缓慢或性能不佳，并对组织的底线产生更大的影响。

开发团队希望专注于新版本。运营团队希望留在循环中，并持续评估这些版本的可靠性。在由此产生的脆弱的权力斗争中，老年退休金可能被视为一个路障，促使开发人员寻找绕过老年退休金限制或完全绕过他们的方法。不可避免地，应用程序性能会受到影响。

实现最佳应用性能的途径

筒仓不行，大部分公司都知道。但是消除孤岛并不容易，与此同时，公司会感受到开发与运营之争的痛苦。

应用性能是开发和运营之间的纽带。要了解应用程序性能的好、坏和丑，首先需要了解应用程序代码——它的结构和运行方式——以及基础架构要求，如服务器和数据库大小以及网络带宽。

以下是优化应用性能的五个步骤:

通过确定一个致力于创建和监督计划的拥护者，建立开发和运营部门的认同，并在过程中指出问题，将开发运维最佳实践整合到组织中。许多公司很难靠自己实现这种文化转变，而这正是外部帮助可能最实用的地方。寻找一个客观的观察者，能够回避政治，不会回避艰难的对话——同时尊重所需的金钱和思想份额。
了解发展目标和实现这些目标的策略。一个用 Ruby 编写的 app 不会有和用 Java 编写的 app 一样的需求和问题。从单个服务器开始。它们受 CPU、内存或网络的限制吗？不同的服务如何相互交流，它们需要多少网络带宽，是否有更好的方法来使用这些带宽？
查看应用程序使用的各个服务，并努力了解应用程序如何访问这些服务以及它试图做什么。例如，如果大型数据库调用长时间锁定数据库，应用程序可能会被重新编程以使用较小的调用来减少负载。
传达持续的开发和运营见解，以掌握容量、速度和各种配置变更。尽早并经常发出危险信号，以确保应用在发布前经过充分测试。
迭代。一劳永逸在这里不适用。如果您消除了服务器和数据库之间的网络瓶颈，您可能会发现下一个瓶颈是数据库本身。(例如，它可能缺少响应网络上所有请求所需的内存。)重点是按优先顺序解决瓶颈，这样您可以在以后的故障排除中节省几分钟甚至几小时。

证据就在应用程序的性能中

当开发和运营团队提前合作时，运营团队可以不再是消防员，而开始积极地为开发具有最佳性能的应用程序做出贡献。

要打破孤岛，你需要知道未来会发生什么，并采用更具战略性的工作方式。一个真正的 DevOps 文化鼓励快速周转的设计、可靠性和责任性，使它更多地与人和过程有关，而不是与底层技术有关。简而言之，采用变革性开发运维/SRE 式集成方法的公司会在竞争中胜出。

Fairwinds 的 Astro 帮助管理 Kubernetes 部署中的 Datadog 监视器，以提高工作效率和集群性能

原文：https://www.fairwinds.com/blog/fairwinds-astro-helps-manage-datadog-monitors-in-kubernetes-deployments-for-better-productivity-and-cluster-performance

波士顿- ( 商业资讯 ) -完全托管的云原生基础设施解决方案的领导者 Fairwinds 发布了其开源 Astro 项目。Astro 提供了一个直观的 API，用于理解和管理大型复杂部署中的 Datadog 监视器。Astro 在https://github.com/FairwindsOps/astro/免费提供。

“我们很高兴能与 Fairwinds 合作，并支持他们努力使这一工具惠及整个社区。”

Datadog 监控器为云原生部署收集大量数据。这些监视器通常是手动管理的，效率很低，如果没有持续一致的管理，会影响群集性能。Astro 使用基于 Kubernetes 中定义的模式的规则，自动管理 Datadog 监视器，以发现和防止潜在的性能问题。

“Astro 利用新的 Kubernetes-native 模式，帮助工程师以声明方式管理 Datadog 监视器，以适应这些环境的短暂性，”Datadog 产品管理总监 Michael Gerstenhaber 说。“我们很高兴能与 Fairwinds 合作，并支持他们努力使这一工具惠及整个社区。”

Fairwinds 战略副总裁 Joe Pelletier 表示:“保持显示器同步对于防止停机和减少寻呼机疲劳至关重要。“Datadog 是基础设施监控领域的领导者，我们很高兴能在此次发布中与他们合作。”

Astro 提供了三个关键元素来大大简化 Datadog 监视器管理:

Datadog 监视器的自动化生命周期管理: 给定配置参数，实用程序将自动管理 Kubernetes 集群中所有相关对象的已定义监视器。随着对象的变化，监视器会更新以反映该状态，从而消除了手动配置的需要。
逻辑绑定对象之间的关联: Astro 能够管理给定名称空间内所有对象的监视器。这确保了显示器配置之间的更大一致性。
将 Kubernetes 对象中的值模板化到受管监视器: 受管 Kubernetes 对象中的任何数据都可以插入到受管监视器中。这将生成更多信息性和情境化的警报，从而更容易对问题进行分类。

Fairwinds Astro 新闻包可在这里访问。

关于 Fairwinds
Fairwinds 利用容器和 Kubernetes 提供完全托管的云原生基础设施。我们结合开源软件、最佳实践和专业知识，构建和维护可靠、可扩展且安全的 Kubernetes 集群。该公司总部位于马萨诸塞州波士顿，提供完全远程和分布式的工作环境。

Fairwinds 主办新冠肺炎黑客马拉松；竞争创建解决疫情问题的应用程序

原文：https://www.fairwinds.com/blog/fairwinds-hosts-covid-19-hackathon-competition-to-create-applications-to-address-pandemic

波士顿，2020 年 3 月 31 日(Newswire.com)——Kubernetes 支持公司 Fairwinds 今天宣布联合举办新冠肺炎黑客马拉松。该计划旨在鼓励创新思想家创造基于 Kubernetes 的网络应用程序的想法，以解决疫情。Fairwinds 将与 GitLab、Datadog 和亚马逊网络服务(AWS)合作，提供端到端的基础设施解决方案，以实现中标项目。

从现在开始到 2020 年 4 月 10 日，在美国有想法的人可以在提交他们的项目提案供考虑。提案可以是正在进行的项目或全新的想法，但所有参赛作品必须有助于解决以下至少一个问题:

减少新冠肺炎的传播
找到治愈病毒的方法
教育公众了解新冠肺炎
重建经济

AWS 将提供六个月的应用托管支持*
GitLab 将是项目所在地
Datadog 将提供六个月的免费监控*
Fairwinds 将提供为期六个月的免费 Kubernetes 托管服务*

*时间框架可能会根据获胜项目的变量进行调整

可以通过访问以下 GitLab 链接并遵循提交说明立即提交项目创意:【http://covidhack.org/】T2。

行情

比尔·莱丁汉姆，Fairwinds 首席执行官

“虽然我们不在抗击新冠肺炎的前线，但我们希望尽自己的一份力量，通过找到有影响力的解决方案，为共同利益做出贡献。凭借工程和开发人员社区中的巨大才能和创新，我们很高兴能与 AWS、Datadog 和 GitLab 合作，提供全面的基础设施支持，以实现创意、扩展和移动。我们的目标是以实用的方式解决这种情况，并为我们的工程团队和社区提供一种贡献的方式。”

git lab 联盟副总裁 Brandon Jung

“这个疫情影响着世界每个角落的人们。开发人员能够创新，找到一个同样影响这些人的解决方案，这是一个非常宝贵的机会。我们很高兴能够提供一个简单、安全的平台来实现这个项目，并期待成为其中的一员。”

Ilan Rabinovitch，产品副总裁&社区，数据狗

“Datadog 很自豪能够支持我们的合作伙伴和社区抗击和应对新冠肺炎病毒。我们期待通过可观察性最佳实践和工具来帮助参与项目加速它们的启动和扩展。”

关于顺风

Fairwinds 为创新的开发团队提供了一个 Kubernetes 支持平台。产品包括 ClusterOps，这是一项 24x7 全天候管理服务，旨在扩展您的团队；ClusterOps Advisory 补充您团队的专业知识；Fairwinds Insights 是一款订阅软件，为云原生基础架构和工作负载提供持续监控。Fairwinds 使组织能够运行可靠、可扩展且安全的 Kubernetes 基础设施。

该公司总部位于马萨诸塞州的波士顿，提供完全远程和分布式的工作环境。

Fairwinds Insights 达到 3.0

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

我很高兴地宣布 Fairwinds Insights 的下一个主要版本！

Fairwinds Insights 是 Kubernetes 中的一个政策执行和审计平台。它附带了十几个与开源工具的集成，如【北极星】、 Trivy 和 OPA ，并且可以在 CI 中检查您的基础架构代码，通过准入控制保护您的集群，或者作为集群内代理运行，为您提供对安全性、效率和可靠性问题的持续监控。

Insights 已经抛出了许多关键数据，因此在这个版本中，我们专注于帮助您可视化、导航和分类这些数据的方法。以下是 3.0 中的几个主要特性。

当 Insights 最初构思的时候，我是唯一一个从事这项工作的人。我很快拼凑了一个带有水平导航的 UI，这对于两三个可用的特性来说已经足够了。

两年后，特性集已经发展到我们空间不足的地步！值得庆幸的是，我们现在有一位出色的 UI/UX 设计师与我们合作，他能够从头开始重新想象我们应用程序的信息层次:

顶部允许您切换上下文，在不同的 Kubernetes 集群和基础设施即代码存储库之间移动
中间部分允许您在给定的上下文中导航
在底部，您可以注销、查看不同的组织或找到文档的有用链接

新的导航更接近其他云原生 SaaS 产品，如 Datadog 或谷歌云控制台，所以用户应该感觉更熟悉。如果这些产品是任何指标，新的垂直导航将允许我们在未来几年增长应用程序。

资源监控

Fairwinds Insights 已经有了与成本和资源使用相关的功能，但数据相当粗糙:我们利用来维护每个工作负载的 CPU 和内存使用的运行平均值、最小值和最大值。对于稳定的工作负载，这允许我们提供合理的建议，说明应该在哪里设置限制和请求；但是对于使用高峰的工作负载，我们需要更多的信息。

为了解决这个问题，我们引入了普罗米修斯收集器报告，它每 30 秒捕获一次 CPU 和内存使用情况的信息。我们保留了两周的数据，因此您可以看到您的使用量在一天或一周内的变化。

Fairwinds Insights Memory Actual Usage Screenshot

通过在您当前的请求和限制旁边显示这些信息，您可以很容易地看到它们设置得有多好。例如，在上面的图表中，因为线条大部分在蓝色阴影区域内，我们可以得出结论，我们已经为内存请求和限制选择了好的值；工作负载最多使用大约 75%的内存限制，平均来说至少使用我们所要求的内存。

相比之下，在下图中，线条远低于蓝框，这表明该工作负载已被过度调配，并且我们的成本可能超过了需要:

Fairwinds Insights Memory Actual Usage Visualization to save money and maintain a more stable environment.

有了所有这些额外的数据，加上一些聪明的可视化，我们的用户能够更好地调整他们的工作负载，这使他们既能节省资金，又能维护一个更稳定的环境。

如果您想尝试一下，请登录您的 Insights 帐户，并通过报告中心将 Prometheus Collector 报告添加到您的集群。

自动化规则

我们得到的关于洞察力的最常见的反馈之一是，庞大的数据量可能会让人不知所措。此外，Fairwinds Insights 生成的许多行动项目不是立即可操作的——它们由第三方或核心 Kubernetes 基础架构控制。

为了帮助解决这个问题，我们引入了自动化规则，它允许您基于某些规则自动地对行动项目进行分类。例如，您可能希望忽略在 kube-system 名称空间中出现的任何问题，因为这是由 Kubernetes 本身控制的。为此，您可以编写一些 JavaScript 代码:

if (ActionItem.ResourceNamespace === 'kube-system') {

  ActionItem.Resolution = WILL_NOT_FIX_RESOLUTION;

}

这是开始减少生成的数据量的有效方法，这样您就可以专注于对您的组织最重要的问题。

您还可以使用自动化规则向 Slack 发送通知，如果(例如)您的生产集群中出现了严重的漏洞。我们计划继续扩展这个功能，包括创建 GitHub 和吉拉票，或者发送任意的 HTTP 请求。

要开始使用自动化规则，查看文档。

OPA 政策 UI

虽然我们在 2.0 中增加了对 OPA 策略的支持，但策略管理完全是通过 CLI 控制的。虽然我们仍然认为这应该是主要流程(因为它允许您将策略存储在基础设施即代码存储库中)，但我们已经构建了一个用户界面来帮助您查看和管理策略。

Fairwinds Insights OPA Policy UI

这将帮助用户更快地实现 OPA 策略的价值，并帮助他们实时查看、编辑和启用/禁用他们的策略。

我们还提供了一个不断扩大的策略库，供您克隆和修改:

Fairwinds Insights library of policies screenshot

阅读文档了解更多。

向前移动

我对我们在 Fairwinds Insights 上取得的进展感到非常兴奋。在创建了一个强大的 MVP，能够解决任何人的 Kubernetes 集群的安全性、效率和可靠性问题之后，我们做了大量工作，使这些发现更具可操作性和可理解性。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

在接下来的一个季度，我们将继续完善我们的用户界面，提供更多可视化效果和定制结果的方式，并将继续关注我们可以连接到报告中心的新的有趣的开源工具。敬请期待！

Fairwinds Insights 5.0.0 发行说明

原文：https://www.fairwinds.com/blog/fairwinds-insights-5-0-0-release-notes

在六月和七月，我们都在努力开发我们的 Fairwinds Insights 5.0.0 版本。5.0.0 版本包括与 Kubernetes 安全性、策略和治理相关的新更新。我们还在 6 月份的 4.4.0 中添加了一些很棒的新功能，我在这篇文章中也提到了。其他最近的更新包括一个漏洞用户界面，在吉拉创建票的能力，等等！了解有关我们版本中的新特性和附加功能的更多信息。

如果您需要持续的【Kubernetes】安全 监控、策略执行以及治理合规性和优化成本的能力， 尝试洞察 。

费尔温德见解 5.0.0 版本

SAML 功能-测试版

我们很高兴地宣布，Insights 现在提供了安全断言标记语言(SAML)功能！如果您想试用或在我们的文档中了解更多关于 SAML 功能的信息，请联系我们。

在行动项目表中保存视图

现在，您可以在“行动项目”( action items)表格中保存过滤后的视图。使用表格顶部的星号按钮，并为视图指定一个名称。您以后将能够访问该视图，而无需重新选择过滤选项。

导航滚动条

为了提高 Insights 的可用性，现在在导航栏的存储库和集群选项中有一个滚动条。

改进了 UI 中的错误消息处理

我们改变了 Insights 处理错误消息的方式。现在可以显式取消通知了。Insights 现在还会显示更长时间的错误消息，以便您通读信息。

修复了修复错误

我们的团队解决了一个问题，即 Polaris 行动项目的信息在修复下不显示。

修正了行动项目的错误

有一个超级用户在 kube 系统中看不到行动项目的 bug，现在已经解决了。我们还修复了一个 bug，在这个 bug 中，一些动作项对于非管理员来说是隐藏的。

Fairwinds Insights 4.4.0 版本

更好的报告中心同步

大多数 Insights 用户将他们的 insights-agent 安装编码为基础设施代码，而不是复制和粘贴 Insights UI 中提供的 Helm 安装指令。有了这个更新，如果你在你的头盔安装上做了改变，用户界面会自动合并这些改变。

按票据创建排序/过滤

您现在可以根据票证是否已创建来对操作项进行排序和过滤。

离线报告停止显示准入控制器

准入控制器的修复

我们已经解决了准入控制器中的一些小问题:

重复的行动项目不再触发 400 响应
准入控制器不定期运行，因此无法自动检测它是否离线或只是安静。为解决该潜在问题，您将不再收到准入控制器离线的通知。

尝试最新版本的 Fairwinds Insights

对使用 Fairwinds Insights 感兴趣？免费提供！在这里报名。

要了解如何使用这些功能并了解最新的 Fairwinds Insights，请随时查看最新的发行说明。

你们中的一些人可能已经在使用我们的开源项目了。我们最近推出了一个开源用户组，我们一直希望有更多的人加入我们！在这里注册 Fairwinds 开源用户组，并加入我们九月份的下一次聚会。

Fairwinds Insights 5.2.0 - 5.4.0 发行说明

原文：https://www.fairwinds.com/blog/fairwinds-insights-5.2.0-5.4.0-release-notes

八月份，我们在 Fairwinds Insights 最新版本中修复了一些错误，并添加了新的团队管理功能。5.2.0、5.3.0 和 5.4.0 中的更新包括与 Kubernetes 安全性、策略和治理相关的新更新。我们最近对团队管理的更新有助于您限制对敏感信息的访问，并将正确的信息提供给正确的人。了解有关我们版本中的新特性和附加功能的更多信息。

如果您需要持续的【Kubernetes】安全 监控、策略执行以及治理合规性和优化成本的能力， 尝试洞察 。

Fairwinds Insights 5.4.0 版本

修正了行动项目的错误

我们修复了一个使用“最后一次看到”而不是“第一次看到”来计算固定动作项目的错误。因此，固定行动项目编号现在更加准确。

固定松弛 Bug

我们修复了 Slack 界面中的一个错误，当搜索不同的 Slack 频道时，该界面不会显示之前选择的频道。

修正了删除存储库的能力

我们修复了一个不能删除存储库的错误，所以用户现在可以删除了。

修复 SAML 错误

我们解决了在启用我们最近引入的安全断言标记语言(SAML)功能时发生的一个问题。Fairwinds Insights 支持通过 SAML 身份提供者进行单点登录。了解有关 SAML 集成的更多信息。

Fairwinds Insights 5.3.0 版本

小组管理

我们推出了一个新的界面和 API 来管理您组织内的团队。在一个组织中，您可以创建多个团队，每个团队都可以访问一组特定的集群、名称空间和存储库。这允许您将这些团队的成员分配给特定的角色，从而限制他们可以对这些对象执行的操作。这种新的团队管理功能是限制对敏感信息的访问并在正确的人面前获得正确信息的好方法。阅读关于团队管理的内容。

代理版本 1.14

有一个新版本的 Insights 代理可用！它包括一些小的改进，包括更好地支持 Kubernetes 1.21 和我们插件的最新更新。

Fairwinds Insights 5.2.0 版本

更新的设置

我们的团队对设置进行了一些更改，以改善您使用 Fairwinds Insights 的体验。首先，我们引入了用户设置，现在您可以在这里更新任何个人用户信息或密码。我们还将组织和集群设置整合到一个位置，使其更易于管理。

修复了漏洞标签错误

有一个错误，不允许用户在漏洞页面上创建票证，现在已经解决。

固定烤面包片

我们修复了一个导致用户无法打开费用设置页面的错误。现在，当非管理员用户试图导航到应用程序的该部分时，我们会显示一个祝酒词。

令牌撤销

现在，重新生成、调配和管理令牌变得更加容易。要在将来对令牌进行任何更改，您可以在 Fairwinds Insights 的设置中的令牌下访问此功能。

报告历史错误

以前，重复的报告显示在“报告历史记录”页面上。此错误现已解决。

更新的摘要电子邮件和延期通知

摘要电子邮件和时差通知现已更新，包括图表过期时的警告。

尝试最新版本的 Fairwinds Insights

对使用 Fairwinds Insights 感兴趣吗？免费提供！在这里注册。

了解如何使用这些功能并了解最新的 Fairwinds Insights，随时在此查看最新的发行说明。

你们中的一些人可能已经在使用我们的开源项目了。我们最近推出了一个开源用户组，我们一直希望有更多的人加入我们！在这里注册 Fairwinds 开源用户组，并加入我们在 9 月(23 日)和 12 月(14 日)的下一次聚会。

Fairwinds Insights 基础教程:如何安装集群内代理

原文：https://www.fairwinds.com/blog/fairwinds-insights-basics-tutorial-how-to-install-the-in-cluster-agent

首先，让我们讨论一下fair winds Insights集群内代理，它到底是什么？在 Fairwinds，我们将用于部署它的舵图称为 Fairwinds Insights 代理。该代理使得使用单个 Helm 安装来部署多个开源工具变得容易；我们将与软件集成的工具称为报告。如果您想要添加或删除报告，这个简单的安装过程可以轻松地重新部署 Fairwinds Insights，这有助于工程师避免进行安装和配置每个工具的定制工作。

集群内代理在您的 Kubernetes 集群内运行，并将收集到的数据发送回 Fairwinds Insights，在 fair winds Insights 中，来自每个报告的调查结果被汇总并发布在仪表板视图中，以便于使用、确定优先级和跟踪问题。这为在 Kubernetes 上部署的组织遇到最多配置问题的三个领域提供了一个统一的多集群视图:安全性、成本效率和可靠性。

如何安装集群内代理？

如果您是 Fairwinds Insights 的新手，请查看关于如何开始的这篇文章(尝试我们的免费层，用于多达 20 个节点、两个集群和一个回购的环境)。如果您已经在 Fairwinds Insights 中创建了一个组织，请登录用户界面(UI)。然后，点击左栏中的集群，然后找到右上角的按钮添加集群。输入新的集群名称，然后点击创建集群。这创建了一个端点，允许代理将数据发送回 Insights 平台。

Fairwinds Insights Cluster page - Add a New Cluster

在 Insights 平台中创建集群后，您有很多选项可以选择如何配置它。Insights 允许许多不同的报告与其共享数据，以帮助您更好地了解您的 Kubernetes 集群是如何运行的。这些报告涵盖了 Kubernetes 的许多重要方面，包括:

根据您目前最关注的领域，您可能希望选择一两个这样的报告(或者更多，由您决定)并安装它们。安装后，报告可以开始扫描您的集群并将数据上传到平台。从那里，您还可以创建【吉拉】松弛警报，为治理设置策略，以及其他操作和集成。

现在你已经在 Fairwinds Insights 中创建了集群，让我们看看如何添加【北极星】和新星。Polaris 是一个开源策略引擎，可以验证和修复 Kubernetes 资源，而 Nova 可以帮助您找到集群中运行的过时或不推荐使用的舵图。转到顶部导航栏中的 Install Hub，单击 Polaris 下显示 Available 的按钮，如果您想要定制您的报告节奏和时间表，请做出选择并单击 Update Config Options 。或者，如果您想稍后进行更新，只需点击快速添加。

Available reports to install in Fairwinds Insights, including Polaris, Nova, Trivy and Goldilocks

重要的是要明白，完成这一步实际上并不安装北极星或任何其他报告。它为你生成一个舵图，添加北极星和你选择的配置设置。如果你点击 UI 右上角的按钮准备安装，你可以看到舵图的新值自动生成。

Helm chart values

您可以选择灰色文本，或者单击灰色框左侧的小复制/粘贴图标。

这是 values.yaml 文件的内容，其中还包括允许您向平台进行身份验证的令牌。您可以在代码中看到，Polaris 和 Nova 是您将要启用的两个报告。现在需要创建 values.yaml 文件，粘贴舵图，然后保存。接下来打开你的命令行，运行提供的 helm install 命令。然后你可以复制命令来安装带有那些新值的 Insights。

配置您的集群内代理

可能需要配置的东西很多。有些配置很简单，就像北极星和新星一样。您可以在 Install Hub 中进行更改并重新构建 values.yaml 文件，也可以在命令行中对该文件进行更新。其他报告需要多一点努力才能正确安装。

Trivy 扫描容器中的漏洞，这是一个需要更多配置的报告的好例子。如果您有驻留在私有回购中的容器，比如 AWS 或 GCP 回购，Trivy 将需要访问这些回购的权限。所以您需要在 values.yaml 文件中给它必要的权限。您可以设置许多不同的标志和设置，所以请花一点时间来处理这些报告，使它们适合您的特定需求。

一旦你按照你想要的方式设置了你的配置，是时候通过重新运行提供的舵升级命令来更新舵图设置了。为了检查 pod 的状态，可以在“insights-agent”名称空间中运行“get pods”命令。

仍然查看命令行，您可以看到一切都是按照您计划的方式安装的。如果仔细观察，您会发现代理为 Nova 和 Polaris 设置了许多 cron 作业。根据本例中的设置，它将每三小时运行一次群集扫描。然后，它将这些信息发送回 Insights 平台，您可以在 Insights 仪表盘中看到这些数据变成了行动项目。

Graphs of Action Items in Fairwinds Insights

现在您已经安装了集群内代理，您将看到您的 Insights 仪表板定期更新。您可以回来更改安装了哪些报告以及如何配置它们，这样您就可以专注于使您的 Kubernetes 集群尽可能地安全、经济和可靠。如果遇到困难或有问题，请联系我们。并加入 Fairwinds 社区 Slack 群向 Fairwinds 团队和社区成员提问并获得答案。

观看安装视频: 如何安装 Fairwinds Insights 集群内代理

Fairwinds Insights: CI 渠道保护您的 Kubernetes 集群

原文：https://www.fairwinds.com/blog/fairwinds-insights-continuous-integration-pipeline-to-protect-your-kubernetes-clusters

大约一年前，我们建造了fair winds Insights来让我们的生活更轻松。我们管理着数十个组织的数百个集群，需要一种方法来跟踪这些集群在安全性、效率和可靠性方面的健康程度。因此，我们构建了一个平台来运行不同的 Kubernetes 审计工具，并将结果汇总到一个单一的仪表板中。

鸟瞰我们的集群的健康状况让我们——以及越来越多的客户——获得了自信地运行 Kubernetes 所需的可见性。每当有新的内容需要审计时，它就能够轻松地添加新的报告类型。

但是我们的客户很快指出，洞察力只能在错误发生后捕捉错误！因为它只能分析正在运行的集群，所以它发现的任何问题都已经在影响生产。

理想情况下，我们应该能够在过程的早期发现这些问题，并阻止它们到达一个活动的集群。因此，我们建立了两种新的方式来运行 Fairwinds Insights:持续集成管道，可以在同行评审期间发现基础设施代码中的问题，以及准入控制器，可以防止有问题的资源进入集群。

Fairwinds 对持续集成的见解

捕捉安全漏洞和其他问题的最佳时机是在同行评审中，在它们进入代码库的主要分支之前。当人们编辑 Dockerfiles 和 Kubernetes 清单时，他们可能会无意中安装易受攻击的软件，引入安全缺陷，或者忽略关键的配置部分，如资源请求或健康探测。

其中一些问题可以通过经验丰富的 Kubernetes 专家对代码的彻底检查来发现，但是这个过程可能会很繁琐并且容易出错。Fairwinds Insights 的 CI 集成自动化了许多最重要的检查，以帮助评审人员快速发现问题。

可以对 Insights 进行配置，以便在引入新问题时显示警告，或者只要问题存在，就阻止开发人员合并他们的更改。

Screenshot of Fairwinds Insights checks unsuccessful or checks requiring statuses.

当发现问题时，开发人员可以访问 Fairwinds Insights，了解更多关于问题是什么，以及如何解决这些问题的信息:

Screenshot of Fairwinds Insights of problem description and how to remediate.

目前，Insights 能够使用北极星检查 Kubernetes 清单的配置问题，以及使用 Trivy 扫描已知 CVE 的 Docker 图像。在不久的将来，我们将添加对使用 OPA 构建自定义配置策略的支持，以及使用 Pluto 检测废弃资源的支持。

当然，并不是集群中的每个资源都要经历一个 CI 过程——有些是由 Kubernetes 控制器自动创建的，有时工程师会使用 kubectl 和 Helm 手动创建或编辑资源。这就是为什么有一个准入控制器是重要的。

洞察准入控制器

理想情况下，集群中的一切都可以追溯到版本控制的基础设施即代码 (IaC)。利用 IaC 的团队可以更轻松地审计变更、回滚错误，并了解他们的集群中正在运行什么。

但是总有办法让东西不经过 IaC 审查就进入你的集群。有时你需要热修复，或者一个工程师不小心在错误的上下文中运行了 kubectl apply 。因此，除了 CI 检查之外，有一个后备机制来防止安全性、效率和可靠性问题进入您的集群也是至关重要的。准入控制器是这里的 Kubernetes-native 解决方案。

每当有新资源添加到集群中时，Fairwinds Insights 准入控制器就会运行。如果资源违反了您组织的策略，准入控制器将拒绝它，并通知客户端(通常是运行 kubectl 或 helm 的开发人员)他们需要更改什么。

Example of cat bad-deploy.yaml screenshot

Fairwinds Insights 允许您从一个集中的位置控制每个集群中的准入控制器。如果您想实施一个新的策略，或者创建一个豁免，您只需要接触一个系统，您的更改就会自动联合到各处。您还可以为某些集群配置独特的策略，例如，如果您希望在生产和转移方面更加严格。

左移

当然，Fairwinds Insights 仍然出色地扫描了 Kubernetes 集群中当前运行的所有内容，以发现存在的问题，这将始终是您的基础架构有多安全、高效和可靠的最真实的视图。但是，通过将问题转移到 CI 管道和准入控制中，我们能够在问题进入集群之前预防问题。

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

此外，Fairwinds Insights 能够在您的机群中的每个集群上应用从 CI 到准入到生产的相同策略(或它们的变体)。这样，每个人都遵循相同的标准，并且这些标准在整个开发周期中被一致地应用。

借助新的 CI 和准入控制器功能，运营团队可以高枕无忧，因为他们知道一旦他们的集群进入良好状态，Fairwinds Insights 将确保他们保持这种状态。

资源

Fairwinds Insights 最新发行说明:8.5.0

原文：https://www.fairwinds.com/blog/fairwinds-insights-latest-release-notes-8.5.0

Fairwinds 最近强调了我们对 Insights 的一些增强，有助于进一步统一 DevSecOps 与额外的左移安全功能。我们还深入挖掘了为什么您需要保持第三方图像最新来帮助管理潜在的 Kubernetes 漏洞。除此之外，我们还继续改进我们的 Kubernetes 治理平台，以确保用户能够围绕安全性、可靠性和成本提供保护。

我们最新的发行说明强调了进一步的增强。你可以在 Fairwinds Insights 文档阅读所有发布说明。

8.5.0

自动扫描基础设施代码

Fairwinds 正在升级 GitHub 集成，并向所有客户提供新的基础设施代码扫描功能。自动扫描使使用 GitHub 的组织能够跨多个存储库进行基础设施代码扫描，而不必配置单独的 CI 管道。可以对任何 GitHub repo 上的每个 pull 请求启动扫描，并将使用 Fairwinds Insights SaaS 基础架构来运行检查。

这消除了配置单个 CI 管道的需要，允许组织节省计算资源，并在几分钟内启动“左移”基础架构代码测试。
当然，任何已配置的现有 CI 管道将继续正常运行。如果您认为自动扫描不适合您，没问题—当提示您添加新存储库时，只需选择“手动连接”。这将提供在您自己的基础设施上的 CI 管道中运行扫描的选项，并且不需要 GitHub 权限。

基础设施代码文件的自动发现

现在，使用新的权限，Fairwinds 将自动定位到 GitHub 存储库中可供扫描的 Helm 和 YAML 文件。这避免了在存储库根目录下的 fairwinds-insights.yaml 文件中指定赫尔姆和 YAML 清单的确切位置的需要。

扫描结果发布 GitHub 评论

使用新的权限，Insights 还可以将扫描结果作为 GitHub 评论发布，使开发人员能够专注于他们的工作流程。

增强的存储库用户界面

存储库 UI 已得到增强，支持自动扫描和我们最新的 UX 标准。

所有客户都可以使用这些新功能，并且接受权限是可选的。如果您选择不接受权限，自动扫描将不可用，但用户仍然可以通过将洞察力集成到他们现有的 CI/CD 系统中来采用基础架构代码扫描。

8.2.0

我们的 Insights 代理的 2.0 版本带来了一些小的突破性变化，以提高舵图的可用性。虽然现有的 1.x 安装将按预期继续工作，但在升级到代理 2.0 时，您可能需要更改 values.yaml。当更新到新版本时，准入控制器和 CI 行为也会发生一些微小的变化。这里是一个破坏和行为改变的列表。

错误修复和改进

我们也继续通过修复错误来改进平台。以下是其中一些改进的简要概述:

一些工作负载指标显示不适用
更快地加载集群概览页面
效率页面的用户界面改进
修复了节点容量图表中有时会出现节点重复的问题
节点容量图表中的固定节点名称
修复了内存差异，如果差异过大，则显示 0(不适用)
到行动项目表的链接现在可以工作了
单击下拉列表中的所有集群选项将转到正确的页面
修复了取消分配和取消休眠的动作项目
在行动项目表上选择多个过滤器现在会显示正确的结果
可以创建与以前删除的集群同名的新集群(在 8.1.0 版之前删除的集群)

Fairwinds Insights 现在集成了 PagerDuty

原文：https://www.fairwinds.com/blog/fairwinds-insights-now-integrates-with-pagerduty

在 Fairwinds，我们依靠 PagerDuty 来管理我们的随叫随到和支持我们的客户——我们是他们产品的忠实粉丝，无法想象没有它的生活。相反，PagerDuty 使用我们的 SaaS 产品 Fairwinds Insights 来帮助管理和监控他们的 Kubernetes 集群。

作为 Kubernetes 治理和安全软件， Fairwinds Insights 持续扫描集群，以确保应用程序在规模、可靠性、资源效率和安全性方面得到配置。作为彼此技术的客户，PagerDuty 和 Insights 之间的整合是显而易见的。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

page duty 和 Fairwinds Insights 的客户现在可以针对其 Kubernetes 集群中的关键问题生成和定制 page duty 事件。该功能包括内置于 Fairwinds Insights 的 100 多项检查，包括容器漏洞、不安全的工作负载配置和资源使用情况，以及针对合规性和内部要求的自定义用户定义策略。

为什么 Fairwinds & PagerDuty 整合如此重要？

作为一个组织，PagerDuty 是全服务所有权的巨大倡导者，引用他的话说:

“全面服务所有权意味着在软件/服务生命周期的每个阶段，人们都有责任支持他们交付的软件。这种级别的所有权使开发团队更加接近他们的客户、业务和交付的价值。反过来，这将释放出关键的竞争优势，使当今的数字世界变得与众不同。”

Fairwinds Insights 在 Kubernetes 中启用了这种服务所有权方法，使编码、运输、拥有成为可能。Fairwinds Insights 为 DevOps 团队提供了整个 Kube 环境的可见性，提供了集群的仪表板视图，有助于他们更好地识别与严重的安全性和合规性风险相关的错误配置。我们的平台对这些风险进行优先级排序，最高优先级的项目现在可以被推送到 PagerDuty 中，以确保团队始终掌握 Kubernetes 的错误配置和漏洞。

它是如何工作的

page duty 集成允许您为 Fairwinds Insights 中的任何操作项创建 page duty 事件，包括 CI/CD、准入控制和集群内。

寻呼机工作事件通过 Fairwinds Insights 的自动化规则创建。可以定制您的自动化规则，仅在特定事件时触发，以及具有不同紧急级别的 PagerDuty 事件。您还可以将资源元数据和补救详细信息添加到事件正文中，等等。

用户使用 Fairwinds Insights 的自动化规则创建新的 PagerDuty 事件，当满足特定场景时，该规则会自动触发。例如，一个常见的用户场景是在 Kubernetes 集群中发现新的高严重性安全错误配置时创建一个 PagerDuty 事件。

创建 PagerDuty 事件后，它将出现在 PagerDuty 控制台中指定的特定服务 ID 下。

Screenshot of Insights identified issues and resolved incidents in PagerDuty console

阅读 Insights 文档可以得到一个集成演练。

了解更多关于 Fairwinds 的见解和整合、联系。

Fairwinds Insights 发行说明 10.2-10.6:聚焦工作负载成本分配

原文：https://www.fairwinds.com/blog/fairwinds-insights-release-notes-10.2-10.6-spotlight-on-workload-cost-allocation

本月的fair winds Insights发行说明提供了许多错误修复，以及我们对成本分配功能的最新增强的详细信息。工作负载成本分配允许平台工程经理查看一组工作负载的历史成本，并将支出分配给特定团队，以便公司可以向利益相关方显示成本，并确定可以节省的领域。

借助新的工作负载成本分配功能，平台工程经理可以使用实际的云支出和工作负载使用情况来了解跨多个集群、聚合和自定义时间段发生的历史成本。

New costs page in Fairwinds Insights showing cost by cluster

了解更多关于 Kubernetes 治理平台全部特性的。

新费用页面- Beta

New costs page in Fairwinds Insights showing cost by cluster

Fairwinds 发布了新费用页面的测试版。组织可以使用该页面更好地了解他们的 Kubernetes 集群成本明细。要查看这一新页面，请访问 Insights 中的效率>成本。

错误修复和改进

Cluster overview in Fairwinds Insights

现在，安装中心推荐使用 Insights Agent 2.8
行动项目表格中的新 ID 栏
UI 指示何时删除危险区域中的集群
更改了漏洞中修复版本列的过滤器

Fairwinds Insights 发行说明 10.7-11.1:新见解持续集成(CI)脚本

原文：https://www.fairwinds.com/blog/fairwinds-insights-release-notes-10.7-11.1-new-continuous-integration-script

本月的fair winds Insights发行说明包括几个错误修复和改进，以及一个新的 Insights 持续集成(CI)脚本，以提高持续集成/持续交付(CI/CD)扫描的可靠性。新的 Insights CI script 2.2.0 现在可以更好地处理不同的 Git 签出状态。

借助更新的 Insights CI/CD 脚本，Fairwinds Insights 能够更好地处理各种 Git 检验状态，从而提高 CI/CD 扫描的可靠性。升级到最新版本的 Insights CI/CD 脚本的 Insights 用户将看到更少的错误，如“无法获得合并基础”

使用 Insights 持续集成(CI)脚本的客户现在也可以扫描 Terraform 文件以发现安全缺陷。这使组织能够实现更大的基础设施即代码扫描覆盖率。

请注意，此功能尚不可作为自动扫描的一部分。要获取脚本，请导航至“存储库”>“添加存储库”>“手动连接”。

Image of CI Installation in Fairwinds Insights

错误修复和改进

我们在过去几周进行了大量修复，以确保 Insights 尽可能直观和全面，以便您可以专注于快速发布云原生应用。

自动扫描存储库的状态指示器引导用户扫描日志
固定簇中健康评分卡中行动项目的顺序
添加文件名到仓库中的行动项卡片
增加了更多州对合规报告的检查
通过质控 id 过滤合规报告检查的能力
修正了费用测试页中的高级过滤

有兴趣尝试 Fairwinds 的见解吗？它可免费用于多达 20 个节点、两个群集和一个存储库的环境！点击了解更多见解自由层。要了解如何使用最新的功能并了解最新的fair winds Insights，请在此处查看发行说明。

Fairwinds Insights 发行说明 11.2-11.6:改进的集群概述

原文：https://www.fairwinds.com/blog/fairwinds-insights-release-notes-11.2-11.6-improved-cluster-overview

这个月，fair winds Insights的发行说明包括几个错误修复和改进。我们已经更新了“集群概述”页面，以改变行动项目图表的工作方式。还提供了新的集群数据，因此您可以通过访问此页面快速了解集群的整体状态。

Fairwinds Insights Cluster Vulnerabilities page

通常，在 Kubernetes 网络内部运行的工作负载容器使用基于 HTTP 的入口控制器向外界公开；为了确保安全，您需要向 Kubernetes 集群添加一个基于 SSL/TLS 加密的配置。为了验证您是否已为集群配置了 TLS，Insights 现在还包括针对入口的自动化合规性 TLS。您可以使用 Fairwinds Insights 自动运行该合规性测试。集成到 Insights 中的 Polaris 检查 Kubernetes 集群中的所有入口是否都配置了 TLS。

Fairwinds Insights 现在还使您能够在部署过程的早期发现安全问题。最新的更新包括一个新的 Insights CI 脚本，使您能够扫描 Terraform 文件，自动扫描功能允许您扫描私人图像。有关其工作原理的更多信息，请访问 Insights 文档中的自动扫描页面。

错误修复和改进

我们将继续修复和解决缺陷，以确保您的洞察力经验能够让您更轻松地快速识别和解决可靠性、安全性和成本效益方面的问题。

Fairwinds Insights user settings - time zone

用户现在可以通过访问用户设置>地区页面来选择他们的时区
用户现在可以导航到漏洞页面中受影响的图像
修复了效率页面中未显示的节点容量图表
修正了行动项目列表的表格视图功能的问题
对集群概览页面的小改进
修复创建第三方票流
修复漏洞-某些组织的所有图片页面无法加载
费用页面的改进
修复了自由层升级按钮的重定向
修正了合规报告的编辑
删除了集群概览页面中的设置细节

如果您还没有使用 Fairwinds Insights，请尝试新的层！它可免费用于多达 20 个节点、两个群集和一个存储库的环境。点击了解更多关于洞察自由层的信息。要了解更多有关如何使用最新功能并与 Fairwinds Insights 更新保持同步的详细信息，请查看此处的发行说明。

Fairwinds Insights 发行说明 6.7.0-7.1.0:关注减少 Kubernetes 警报疲劳

原文：https://www.fairwinds.com/blog/fairwinds-insights-release-notes-6.7.0-7.1.0-spotlight-on-reducing-kubernetes-alert-fatigue

我们一直在根据客户反馈为 Fairwinds Insights 开发新功能。我们最近对软件做了几处改动。从错误修复到合规性功能到配置设置，这些发行说明涵盖了我们最近对 Fairwinds Insights 的所有升级，以帮助用户改善他们的 Kubernetes 安全性和治理。

特色聚焦:减少噪音和警报疲劳

使用配置验证解决方案时，有时会出现警报噪音。当用户跨多个集群响应多个配置问题时，“警报疲劳”可能会令人痛苦。Fairwinds Insights 帮助汇总来自各种工具的调查结果，现在包括高级过滤，因此用户可以减少噪音和痛苦的警报疲劳。我们在行动项目中添加了图表，以便团队可以根据严重性、主要问题、命名空间或工作负载轻松查看警报。

Fairwinds Insights 发行说明

6.7.0 许可控制器 Kubernetes 1.22 支持

准入控制器已更新，以支持 Kubernetes 1.22。这意味着在集群上运行 1.22 的用户现在可以在自己的工作负载中使用准入控制器特性。

6.9.0 新的合规特性

此功能允许组织为其 Kubernetes 集群创建合规性报告。客户现在可以通过创建报告和对每次检查进行自我评估来跟踪他们的 SOC 2、、HIPAA 和 ISO 合规性。在自我评估期间，客户可以提供证据证明他们是如何遵守每项检查的。也可以随时下载 PDF 格式的完整报告。

image of compliance reports in Fairwinds Insights

配置准入控制器

用户现在能够通过 Insights 配置准入控制器的设置。准入控制器可以被设置为被动模式，该模式将执行通常的检查，但不会阻止任何准入请求。此外，用户可以选择哪些报告应该阻止准入请求。当组织的所有者访问准入控制器上的安装中心时，他们可以访问这些设置。

6.11.0 行动项目图表

Insights 中的措施项页面现在有图表，这些图表按照严重性、主要问题、主要名称空间和主要工作负载对措施项进行可视化分类。用户还可以通过单击图表中的项目来过滤行动项目表。

错误修复和改进

有关我们最近对 Fairwinds Insights 的错误修复和改进的具体信息，请随时访问我们的发行说明。对于那些已经在使用我们开源项目的人，我们最近启动了一个用户组。加入我们吧！您可以在这里注册 Fairwinds 开源用户组，并考虑参加我们于 2022 年 3 月 23 日举行的下一次会议。

使用 Fairwinds Insights

使用我们的 Kubernetes 安全和治理软件了解更多信息！Fairwinds Insights 是免费的。你可以在这里报名。

Fairwinds Insights 代理 2.0 |发行说明:7.12.0 - 8.1.0

原文：https://www.fairwinds.com/blog/fairwinds-insights-release-notes-7.12.0-8.1.0-insights-agent-2.0

费尔温斯的春天快乐！四月份，我们对 Kubernetes、 Fairwinds Insights、的 SaaS 治理平台的特性和功能进行了大量新的改进。除了常见的错误修复，本月的发行说明将涵盖几项关键升级，包括关注自动化规则日志和围绕 Insights Agent 2.0 新版本的公告。请继续阅读，了解有关 Insights 最新增强功能的更多信息，以及如何充分利用其不断改进的功能。

洞察代理 2.0

我们很高兴地宣布我们的 Insights 代理的 2.0 版本！这个新版本带来了一些小的突破性的变化，以提高舵图的可用性。虽然您现有的 1.x 安装将按预期继续工作，但在升级到这个新版本时，您可能需要更改您的值。在更新到代理 2.0 时，您还可以预期准入控制器和 CI 行为会有一些微小的变化。

image of YAML file

要了解更多关于用户应该如何处理这些配置更改和值. yaml 更新、的信息，请随时访问代理 2.0 发行说明。

功能亮点:7.13.0 自动化规则日志

除了一些错误修复之外，升级 7.13.0 还包括自动化规则页面的新选项卡，用户可以在其中找到自动化规则的日志。这种改进通过添加像 console.log 语句这样的元素——或者查看任何运行时错误，使得调试自动化规则变得更加容易。

作为建议的映像升级的结果，Trivy 现在将在源 repo 中搜索可用的更新，这将解决当前安装的映像中存在的 CVE。用户将在补救文本中找到这些建议，并附有琐碎的行动项目。

注意:您需要更新到最新版本的 Insights Agent (1.17.28)才能利用此功能。

image of Fairwinds Insights Automation Rules tab

7.12.0 阻止团队访问的能力

本月的另一个重要功能升级包括阻止团队访问 Fairwinds Insights 中的特定名称空间和存储库。具有特定访问权限的团队成员将不再能够看到阻止列表中的集群、名称空间和存储库。现在可以使用 Esc 键盘按钮关闭操作项，从而在工作负载页面上进行搜索时提供更好的性能。

image of Fairwinds Insights Team Access functionality

8.1.0 新集群和节点成本

这个新页面允许用户快速查看他们正在使用的资源量与可用资源量的对比。这一升级提供了一个很好的工具，可以帮助客户识别利用率不足或过高的集群。组织中的用户可以比较所有集群之间的资源利用率，并查看与每个集群相关的成本。此外，他们可以了解 Kubernetes 集群中每个节点的资源利用率。关于集群和节点成本的新页面可以在效率>容量下找到。此外，用户现在还可以创建一个与以前删除的集群同名的集群。

Image of cluster and node costs shown in Fairwinds Insights

错误修复和其他改进

7.14.0-8.00 版本主要包括错误调整和修复。有关这些增强功能的更多具体信息，请随时访问我们的发布说明。

Fairwinds Insights 发行说明 7.2 - 7.6:聚焦准入控制器重新设计

原文：https://www.fairwinds.com/blog/fairwinds-insights-release-notes-7.2-7.6-spotlight-on-admission-controller-redesign

我们一直在努力改进我们的安全和治理软件fair winds Insights的功能和界面。这组二月发行说明涵盖了我们最近的所有升级，包括错误修复、暂停行动项目的能力和准入控制器的重新设计。请关注我们，我们将详细介绍本月对我们的策略驱动型配置验证平台 Insights 进行的激动人心的增强。

特色聚焦:7.2.0 准入控制器重新设计

Fairwinds Insights 的用户会注意到准入控制器页面的全新设计。它现在有一个图表，客户可以使用该图表快速访问特定时间范围内 Kubernetes 集群成功和失败的准入请求数量。每个失败的接纳请求的操作项现在将出现在表格格式的右侧。

7.5.0 新的单一登录(SSO)设置页面

组织现在可以通过用户界面设置 SSO 以获得洞察力。设置 SSO 需要有效的元数据 URL 和电子邮件域。这一功能使 Insights 的用户能够直接通过平台强制使用单点登录。

行动项目的打盹

从一个月到一周到一天，Insights 客户现在可以在一段固定的时间内暂停操作项目。然后，此功能将操作项的解决方案设置为暂停。对于需要非优先补救措施的措施项目，用户可以利用此功能。

Insights 还改进了两个小特性。

用户现在可以为所有法规遵从性报告创建名称，以改进整体组织。
工作负载页面中的成本差异颜色已更改，以提供更好的可访问性。

错误修复和改进

有关我们最近对 Fairwinds Insights 的错误修复和改进的具体信息，请随时访问我们的发行说明。

Fairwinds Insights 发行说明 7.7.0 - 7.11.0:聚焦导航改进

原文：https://www.fairwinds.com/blog/fairwinds-insights-release-notes-7.7.0-7.11.0-spotlight-on-navigation-improvements

费尔温斯的你好！像往常一样，我们一直在努力不断升级我们的 Kubernetes 安全和治理软件 Fairwinds Insights 的特性和功能。除了常见的错误修复，本月的发行说明将涵盖我们最近的所有变化，包括状态和效率的新页面，以及其他导航改进。请继续阅读，了解我们的策略驱动型配置验证平台 Insights 的最新增强功能。

功能聚焦:7.9.0 导航改进

此次升级的结果是，Insights 客户将在整个应用程序中体验到清晰一致的导航体验。用户会发现，从组织视图到集群视图的转换现在已经无缝集成到平台中。

新的效率页面现在为工作负载页面提供了一个主页，并为未来的成本优化和报告增强提供了一个占位符。客户还会发现行动项目更容易找到，通过简单的切换功能可以在单个群集中查找行动项目，或者从单个页面中查找整个组织的行动项目。要了解更多信息，请随时观看我们关于导航改进的简短信息视频。

7.11.0 新见解状态页面

通过我们最近的升级，用户现在可以跟踪见解的状态。如果 Fairwinds 遇到广泛的问题，我们将在这里向客户提供信息。现在可以在帮助项目下找到新的状态页面。您可以随时在此处检查当前操作系统状态。

按标签搜索工作负载

此外，Insights 的用户现在可以根据标签搜索工作负载。客户可以使用效率>工作负载页面上的搜索功能来搜索所需的标签。例如:app=myApp。这里还做了一些其他的改进，包括 UI 改进和一个新的描述特性，当动作项被导出到 CSV 时。

错误修复和改进

7.8.0 和 7.10.0 版本都包含了一些调整和升级。有关 Fairwinds Insights 的这些和其他功能的具体信息，请随时访问我们的发行说明。

Fairwinds Insights 发行说明:8.10-9.6

原文：https://www.fairwinds.com/blog/fairwinds-insights-release-notes-8.10-9.6

在过去的一个月里，Fairwinds 开发团队发布了许多 Insights 的更新，包括我们新设计的帮助团队降低风险的漏洞浏览器。

聚焦漏洞浏览器

漏洞资源管理器的更新使团队能够轻松了解高层次的风险，并解决影响最大的问题。(看视频游)。Fairwinds Insights 可识别顶级 CVE、风险最高的工作负载和最易受攻击的容器包。团队还可以选择按图像或漏洞查看数据，从而灵活地关注最相关的上下文。漏洞浏览器通过提供带有预计漏洞减少计数的自动升级建议，进一步支持节省时间。

Insights 发行说明

9.6.0

公共存储库中的 Fairwinds Insights 详细信息链接重定向到新的存储库页面
在添加存储库的手动连接流程中，推荐新的 Insights CI 脚本版本 2.1.0
为注册和支持页面添加了验证码
现在，行动项目表格中的栏可以完全展开
修复了访问用户设置页面时左侧导航中的组织下拉菜单
修正了合规报告中的 ISO 27001 下拉列表
现在建议在安装中心安装 Insights Agent 2.6

9.5.0

重新设计的漏洞页面，使团队能够从高层次理解风险，并解决影响最大的问题。“所有映像”选项卡允许组织查看哪些映像风险较高，而“所有漏洞”选项卡则帮助用户确定他们是否受到了某些漏洞的影响。

准入控制器中的冥王星

冥王星已在准入控制器中启用。如果使用不赞成使用或已删除的 Kubernetes 资源，则准入请求将创建低和中严重性操作项。要了解如何在准入控制器中配置报告，请访问安装中心和策略文档。

错误修复和改进 8.10-9.6

存储库中的设置按钮允许更容易地访问启用/禁用自动扫描
存储库中的“操作项目”表格现在有一个“文件名”列
左上方的集群下拉列表在几个页面上被修复
新用户的密码需要数字、字母和符号
在存储库中选择手动连接时，代码复制现在可以正常工作
修复了图表为空时效率>工作负载页面中的错误
修复了存储库中的自动扫描切换
行动项目表中的事件 ID 现在是事件类型
在“集群概述”页面中，Insights 版本已更改为代理版本
将建议的 Insights 代理版本更新至 2.4
查看者现在可以在自动化中查看日志
修正了吉拉门票的漏洞链接
添加了仅针对一个复制副本的描述和补救是计划操作项
OPA 策略现在有了正确的事件类型
通过洞察提高可访问性
为存储库操作项添加了导出选项
文档的固定链接
集群页面加载改进

点击此处阅读完整发行说明。

Fairwinds Insights 发行说明 8.6-10:聚焦政策和 NSA 强化指南

原文：https://www.fairwinds.com/blog/fairwinds-insights-release-notes-8.6-10

Fairwinds Insights 在过去的一个月中得到了增强，增加了许多新功能和错误修复。Kubernetes 治理平台确保用户可以配置设置，以确保安全风险最小化和成本优化，同时为开发人员提供护栏，以更快地交付应用程序。

聚焦:NSA Kubernetes 强化指南

作为我们的 NSA Kubernetes 强化指南的一部分，我们提供了有关如何使用 Insights 帮助改善 pod 安全性、网络访问、认证和授权、审计日志记录和威胁检测和升级和应用安全实践的信息。现在，Fairwinds Insights 提供了为用户导出报告的功能，以指导集群实现 NSA 强化。该报告将显示 NSA 政策、相关洞察检查以及需要解决的行动项目数量。

聚焦:增强的策略配置

我们重新设计了策略页面，现在显示 Insights 内置的所有策略以及用户添加的任何 OPA 策略的列表。用户现在能够看到每个策略的严重性，以及他们当前是否会阻止准入请求或 CI/CD 管道。在使用 Insights UI 创建新策略时，我们也开始使用 OPA v2。

Insights 发行说明

8.10.0

策略配置器

我们重新设计了 Insights 中的政策页面。策略页面现在将显示作为 Insights 一部分的所有策略以及用户添加的任何 OPA 策略的列表。用户现在能够看到每个策略的严重性，以及他们当前是否会阻止准入请求或 CI/CD 管道。此外，用户现在能够使用 Insights CLI 设置这些值，以根据他们的需求定制策略。

Screenshot of Fairwinds Insights policy configurator

洞察 CI 脚本 2.0

我们的用户可以在 CI/CD 渠道中使用新的 Insights CI 脚本。新的 2.0 Insights CI 脚本现在将根据准入和 CI 策略中设置的值阻止准入请求和 CI/CD 管道。使用自动扫描功能的用户将自动使用这个新的脚本版本。2.0 脚本还默认只阻止严重性为高或严重的操作项目。

8.9.0

使用 OPA v2 在 Insights 中创建新策略

使用 Insights UI 创建新策略时，我们将使用 OPA v2。这里最大的变化是不再需要 YAML 实例。所有 v1 策略将继续工作，并且仍然能够在 Insights web UI 中进行编辑。OPA v2 仅适用于 Insights Agent 2.x 。要了解更多关于 OPA v1 和 v2 之间的差异，请查看 V1 和 V2 洞察 OPA 政策。

8.7.0

NSA 强化指南的 CSV 导出

用户现在可以导出一份报告，指导他们的集群进行 NSA 加固。该报告将显示 NSA 政策、相关洞察检查以及需要解决的行动项目数量。要获取报告，请转到 Action Items 页面，从左上角的下拉列表中选择一个集群，然后单击 Export > Export NSA Report 按钮。

8.6.0-8.10.0

错误修复和改进综述

工作负载现在即使经过过滤也可以导出
修正了显示百分比时准入控制器图表的显示
现在，删除集群需要在确认之前键入集群名称
修复了导出行动项目时缺少的名称字段和重复的名称空间字段
改进了冥王星行动项目的描述和标题
添加了为不同平台设置 CI 集成的说明
删除了节点容量图表中显示为空白的节点
修正了联系表格的问题
更新的 Insights CI 脚本
修复了存储库中主要问题图表的排序
改进了群集概览页面的加载速度
登录页面的新背景
修正了当鼠标停留在首页的热门话题图表上时弹出窗口被切断的问题
一些工作负载指标显示不适用

Fairwinds Insights 发行说明 9.12-10.1:聚焦自动扫描增强功能

原文：https://www.fairwinds.com/blog/fairwinds-insights-release-notes-9.12-10.1-spotlight-on-autoscan-enhancements

本月的fair winds Insights发行说明提供了许多错误修复和对我们的自动扫描功能的增强。Autoscan 专为需要在多个团队中部署基础设施代码扫描的平台工程经理而设计，可自动发现和扫描 GitHub Repos 中的 YAML 文件和掌舵图，并提供自动扫描，无需单独的 CI 管道集成。借助 Autoscan，平台工程团队可以在几分钟内配置基础设施代码扫描，从而创建一个即时反馈循环，以便开发人员可以更快地修复问题。

了解更多关于 Kubernetes 治理平台全部特性的。

10.1.0

自动扫描日志

打开了自动扫描的存储库现在会在其存储库页面底部看到自动扫描日志部分。这将帮助用户更好地调试自动扫描功能的问题。

Autoscan Logs section in Fairwinds Insights

10.0.0

重新运行自动扫描

如果存储库设置了自动扫描，用户现在可以在其分支上重新运行 Insights 扫描。为此，请访问“存储库”页面，选择存储库和分支，然后单击“重新运行自动扫描”按钮。

9.12.0

关闭已修复和已解决行动项目的第三方票证

当某个操作项有关联的 GitHub、Azure DevOps 或吉拉票证，并且该操作项已修复或解决时，第三方票证将自动关闭。

错误修复和改进

加快加载集群页面的改进
打开了自动扫描的存储库现在将具有扫描状态
Insights Agent 2.6.11 中的新版本 Nova 将为过期容器创建操作项
修复了存储库中主要问题图表上的标签
修复了漏洞>所有图像表的导出功能
修正了在 Azure DevOps Scrum 项目上创建标签的问题
无法再对行动项目中的标签列进行排序
SSO 登录流程的改进
更改了漏洞中推荐标记列的过滤器
用户不再能够使用相同的名称创建合规性报告
使用 SSO 链接登录将提示用户输入他们的组织名称
已修复 Azure DevOps 票证在解决或修复行动项目后无法关闭的问题
固定右侧尺寸描述

Fairwinds Insights 发行说明 9.7-9.11:聚焦新报告

原文：https://www.fairwinds.com/blog/fairwinds-insights-release-notes-9.7-9.11

我们一直在根据客户反馈为 Fairwinds Insights 开发新功能。我们最近对软件做了几处改动。从错误修复到新的集成，这些发行说明涵盖了我们最近对 Kubernetes 治理平台 Fairwinds Insights 的所有升级。

这个月，我们向 Azure DevOps 添加了新的集成，并使 AWS Costs、Right-Sizer 和 Falco 报告易于添加到见解中。请继续阅读，了解更多信息。

9.11.0

Right-Sizer、AWS Costs 和 Falco

我们已经将 Right-Sizer、AWS Costs 和 Falco 报告添加到安装中心页面。可以像往常一样使用报告下的快速添加选项添加 Right-Sizer 报告。但是，AWS 成本和 Falco 需要更多配置，快速添加选项不适用于这些报告。相反，您将被带到这些报告的文档页面。

New NamespaceLabels and NamespaceAnnotations in Automation Rules

用户现在可以访问自动化规则中操作项的名称空间标签和名称空间注释。若要访问这些值，请使用 ActionItem。命名空间标签和 action item . namespace annotations

9.7.0

新的 Azure DevOps 集成

新的 Azure DevOps 集成允许组织将其 Azure DevOps 连接到 Insights，并手动或通过自动化规则创建行动项目的票证。要了解有关 Azure DevOps 集成的更多信息，请访问 Azure DevOps 文档。

选择效率页面时，将始终显示所有群集视图
默认情况下，在效率中选择最新的数据
对于“新图像有漏洞”操作项，该图像会在描述下列出
贯穿 Insights 的微小 UI 修复
默认情况下，效率页面中的节点列表现在按角色排序
修复了普罗米修斯收集器文档链接
修正了效率页面中的节点搜索
效率中的节点容量内存图表现在可以正确显示
只有组织所有者能够向 Insights 添加新的存储库
健康分数现在使用新的时间表数据库，所以健康分数可能略有不同
用户将在主页中找到以下新信息:
L30D 的平均节点数(过去 30 天)
自定义策略集的数量
自定义规则集的数量
用户现在可以在效率页面中为群集比较设置不同的比例
修复了存储库页面中存储库名称被截断的问题
“所有存储库”下的“名称”列现在可以展开

Fairwinds Insights:不要错过发行说明汇总- 3.0 到 4.0

原文：https://www.fairwinds.com/blog/fairwinds-insights-release-notes-rollup-3-0-to-4-0

几个月来，我们一直很忙，对 Kubernetes 安全、政策和治理软件 Fairwinds Insights 进行了重大更新。每个版本都有一些很棒的新特性和额外的功能，我们在下面进行了概括。

如果您需要持续的 Kubernetes 安全监控、策略执行以及管理合规性和优化成本的能力，请尝试 Insights 。

4.0.0 新的集群概述 UI - 我们的集群概述页面现在可以更轻松地显示集群中发生的情况。您可以查看集群的运行状况分数、按名称空间和报告汇总的操作项目、热门操作项目、成本摘要、分配的操作项目等。了解更多。
3.4.0 导出 SOC2 报告- Fairwinds Insights 现在支持在 Kubernetes 环境中检查 SOC 2 认证的合规性。Insights 将检查某些资源是否受到漏洞和配置问题的监控，这些问题被映射到特定的 SOC 2 部分。您可以将调查结果导出为 CSV 文件，并发送给您的审计员。
3.2.0 自动化规则 UI - Insights 为 Kubernetes 集群和资源提供了 100 多项检查。这些检查越来越多地在各种环境中运行，如 CI/CD、准入控制和集群内。某些检查可能更适合特定的环境，需要更高的严重性级别，或者触发不同的警报/响应机制。规则允许您修改 Insights 中的现有操作项，并根据您的选择对其进行自定义。您可以在导航栏中的“自动化”下找到自动化规则。有关如何使用自动化规则的灵感，请使用该特性的“从模板创建”部分。有八个预先制定的规则可以帮助你开始。了解更多。
3.0.0 Prometheus 更新 - 我们添加了一个名为 Prometheus Collector 的新报告，它从 Prometheus 安装中收集工作负载指标，以便提供细粒度的资源使用数据。您可以使用此报告来衡量不同工作负载的成本，了解成本趋势，并帮助设置资源请求和限制。阅读更多关于普罗米修斯收藏家的信息。

对使用 Fairwinds Insights 感兴趣吗？免费提供！在此了解更多信息。要了解如何使用这些功能，并了解最新的 Fairwinds Insights，请查看此处的发行说明。

有一种更简单的方法来审计您的 Kubernetes 基础设施；了解更多关于我们新推出的 Fairwinds Insights 自主版本的信息。

新的 Fairwinds Insights 发布:Azure DevOps 集成和秘密加密

原文：https://www.fairwinds.com/blog/fairwinds-insights-releases-azure-devops-integration-secret-encryption

如果你正在管理一个使用 Kubernetes 的开发团队，毫无疑问你会遇到一些扩展问题——不是关于支持终端用户，而是关于能够容易地发现、分类和修复问题。最重要的是，您已经有了现有的工具来帮助开发团队已经在使用(并且很有希望喜欢)的票证或 CI/CD 管道工具，所以您不希望中断任何工作流。

但是你需要确保 Kubernetes 的安全性和成本效益。这就是 Fairwinds Insights 的帮助所在。它为您提供了 Kubernetes 集群的集中视图，帮助您识别应用程序中的安全性、性能和成本错误配置。它在实现所有这些的同时支持 Kubernetes 服务所有权，即开发团队对他们在开发生命周期的每一步交付的产品和服务负责的能力。

开发团队不需要另一个平台

在开发 Kubernetes 平台时，您已经选择了许多工具，所以您可能想知道为什么要在开发团队的道路上放置另一个平台。你不需要担心那个！

Fairwinds Insights 集成了 Kubernetes 社区可用的一些最广泛的工具，包括吉拉、Slack、PagerDuty 等。这种集成意味着，当 Insights 发现一个问题时，就会从 Insights 向您的开发人员已经喜欢的工具推送一个标签或通知。

从 Insights 内部触发工作流简化了将所有权分配给适当团队的流程，节省了时间和访问多个 ui 的次数。

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

最近发布的两个版本引入了从 Insights 平台与第三方提供商交互的新方式。

在 Azure DevOps 中分配工作项目

Azure DevOps 加入吉拉和 GitHub，成为 Insights 中最新的第三方票务集成。用户现在可以从 Insights 操作项手动创建 Azure DevOps 工作项，也可以通过自动化规则自动创建。安装轻而易举，从“设置”页面的“集成”选项卡触发。查看文档。

image of Azure DevOps ticketing integration in Fairwinds Insights

使用 Secrets Encryption 对第三方 API 进行安全的 Webhook 调用

虽然 Insights 有许多现有的集成，但您可能已经使用了一个工具，并希望将其功能扩展到。为此，Insights 使用了自动化规则。此功能使您能够定制工作流，以处理来自 Fairwinds Insights 的新发现。例如，您可以在一个票据系统中创建新的问题，或者触发一个松弛警报。它有助于确保洞察力增加开发生命周期的效率，而不是妨碍它。

自动化规则的一个重要部分是能够安全地访问您发送洞察数据的位置。这就是为什么现在您可以添加和存储加密的秘密扩展现有的自动化规则功能以应对新的用例。使用“sendHTTPRequest”功能，可以上传和加密机密，以便对第三方服务(如票务提供商)进行安全的 webhook 调用。

image of ‘sendHTTPRequest’ function for uploading and encrypting secrets

使用洞察力和开发团队喜欢的工具

借助 Fairwinds Insights，您可以获得以下优势:

集中查看集群和基础架构代码扫描
开发、安全和运营部门的一致性
最重要的优先列表以及如何修复它

借助 Insights 及其交互，您将使开发团队能够在其应用中拥有安全性、性能和成本配置。

Fairwinds Insights v2.0 现已推出

原文：https://www.fairwinds.com/blog/fairwinds-insights-v2.0-now-available

云原生技术正在彻底改变应用程序的开发和交付。它正在帮助企业实现现代化并推动其数字化转型。尤其是，Kubernetes 是运行容器化应用程序的强大平台。它有许多属性—自动扩展、自动恢复等。–这对于在我们当今生活的 24x7 随需应变的世界中运行应用程序至关重要。

作为 Black Duck Software 的 CTO，我亲眼看到了利用云原生技术、敏捷开发技术和 DevOps 实践的好处，因为我们推出了一个新的 SaaS 平台，采用了在 Kubernetes 上运行的容器化微服务。当我们最终将所有东西都部署到生产环境中时，好处是巨大的，当然也有许多挑战。它让我清楚地认识到，要取得成功，需要工具、流程、组织思维和承诺。

虽然 DevOps 意味着开发和运营组织之间的紧密耦合，但实际情况却大不相同。对于许多组织来说，开发和运营之间存在很大的差距，原因在于:

缺少在多个开发团队和生产环境中实施标准和最佳实践的工具
组织中的知识差距
哲学差异和竞争优先权——开发团队希望快速迭代和推出新功能。运营团队希望确保一切都经过适当的测试，并尽可能保持生产环境的稳定。

在 Fairwinds ，我们处于应对这些挑战的独特位置。我们的团队拥有丰富的 Kubernetes 和 DevOps 专业知识，以及通过管理数十家公司的数百个集群获得的经验。简而言之，是人、流程和技术的结合推动了积极的结果。

安全

大多数公司面临的第一个挑战是安全性。由于 Kubernetes 和 containers 代表了一种部署应用程序的新方法，而这种方法对于大多数运营和 infosec 团队来说是陌生的，所以经常被问到的第一个问题是:我的应用程序和数据在这种开发和部署应用程序的新方法下会安全吗？许多传统的安全工具和方法不再适用。同样，开发人员被迫接受一些新的安全挑战——这是一个他们既不习惯又不愿意接受的角色。

围绕应用和平台漏洞的安全考虑、适当的权限、入口/出口控制和证书管理使得安全管理变得复杂(参见我的博客《解决 Kubernetes 安全漏洞与策略实施》)。不幸的是，在当今的环境中，安全是一项永无止境的任务。在 DevOps 领域，由于其重要性以及在整个开发和运营链中实现安全性的需要，现在已经产生了术语“DevSecOps”。

可靠性

在实现了用于发现和修复安全问题的方法和工具之后，DevOps 团队将继续应对管理环境中的其他挑战。保持应用程序全天候可用非常重要。Kubernetes 有许多内置特性来确保应用程序的可靠性。但是，开发人员需要了解这些特性，并实现代码来利用它们。例如，Kubernetes 中运行的每个微服务或应用程序服务都应该设置活跃度和就绪性探测器。这使得 Kubernetes 能够确保服务正常运行，并在服务不正常时自动终止并重启它。

北极星和金发女孩是我们日常管理的 Kubernetes 集群中使用的。我们开始使用开源工具作为基础来构建和提供更深入的配置验证平台，该平台评估部署(应用程序容器)和底层 Kubernetes 基础架构的安全性、可靠性、性能和成本问题，并向开发和运营团队提供实时反馈。

我们心中的一些关键目标是:

提供开发人员支持，同时确保运营视角，即让应用安全、可靠且经济高效地运行。
提供灵活性，使运营部门能够快速行动，并提供快速反馈以尽早发现问题，以便开发人员仍能掌握相关情况，例如，在“拉”请求期间执行检查和分析，以便为开发人员提供有关潜在问题的实时反馈。
住在开发人员和 sre 住的地方，例如，与这些团队日常工作使用的现有工具集成。
监控、发现、优先处理和补救问题。以与现有软件开发生命周期无缝结合的方式来做这件事。
推动开发人员和运营人员之间的通用语言和沟通流程，以形成更紧密的联系和集成。
实施最佳实践，使政策在流程中根深蒂固。

结果

Fairwinds Insights 为组织、优先排序、沟通、报告和补救问题提供了一个通用框架。

我们将 Fairwinds Insights 构建为一个可扩展的平台，集成了多种开源工具(Fairwinds 的 OSS 和同类最佳的第三方开源工具)，以及集成其他商业安全和审计工具的能力。SaaS 平台包括对安全性、可靠性和成本的内置检查。各种集成允许用户在开发人员和 DevOps 工程师日常使用的工具中暴露集群中的问题，例如 Slack、Git、JIRA 等。按照这些思路，Fairwinds Insights 是 data dog 8 月份市场发布的一部分。通过我们的 Datadog 集成，用户可以将所有这些问题呈现在仪表板上，并与 Datadog 的监控和警报功能结合起来。

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

我对我们最新发布的 Fairwinds Insights 更加兴奋，因为它开始实现我们的愿景，即将制衡融入流程，并以自动化的方式弥合开发人员和运营人员之间的差距。在我们的新版本中，我们将提供:

CI/CD 集成–持续集成/持续部署(CI/CD)集成使洞察能够在关键的连接点插入软件开发管道。当开发人员签入新版本的软件时，CI 工具如 CircleCI、Jenkins 等。开始软件的自动化构建和测试。Fairwinds Insights 可以针对这些新版本运行验证检查，并向开发人员提供即时反馈
OPA 支持–fair winds Insights 现在包括一个基于开放策略代理(OPA)开源项目的内置策略引擎。这使得团队能够实现安全性、可靠性、性能、成本等方面的策略。并在从开发到部署的整个 SDLC 中实施这些实践。它提供策略检查、防护和最佳实践的实施，以确保开发团队(应用程序)和操作(基础设施)之间的一致性。
准入控制器–准入控制器提供额外的保护措施，防止有问题的容器被部署到生产集群中。它在部署容器之前对容器运行策略检查。

这些新功能支持开发过程中的“左移”,使开发人员能够更早地看到问题，从而可以更早地解决问题，并提供 DevSecOps 的前提，在 DevSecOps 中，安全性紧密集成在整个过程中。

总结

Fairwinds Insights 是一个强大的平台，可以解决组织在部署云原生技术时面临的许多挑战。随着 Kubernetes 的使用不断增加，它提供了一个框架，在这个框架中，在有多个开发团队和集群的组织中实施标准，确保安全、可靠和经济高效地部署应用程序。

我很高兴我们的团队在过去的一年里在实现这一愿景和目标方面取得了巨大的进步。

资源

fair winds Polaris 1.0-Kubernetes 工作负载的最佳实践

原文：https://www.fairwinds.com/blog/fairwinds-polaris-1.0-best-practices-for-kubernetes-workloads

party popper 我很兴奋地宣布，我们已经发布了北极星 1.0！

We launched Polaris almost a year ago to help Kubernetes users avoid common mistakes when configuring their workloads. Over the course of managing hundreds of clusters for dozens of organizations, the Fairwinds SRE team kept seeing the same mistakes over and over: resource requests and limits going unset, liveness and readiness probes being ignored, and containers requesting completely unnecessary security permissions. These are sure-fire ways to create headaches down the line – from outages, to cost overruns, to security breaches. We saw Polaris as a way to encode all our battle scars into a single configuration validator that could benefit the entire Kubernetes community.

Polaris 最初是一个简单的仪表板，显示集群中所有未达到最佳实践的工作负载。但是我们很快为真正的偏执狂添加了一个验证 Webhook 这将拒绝ku bectl apply任何未通过危险级别检查的工作负载。但是我们的用户仍然不满意——他们想在 CI/CD 中运行 Polaris，这样他们就可以在错误被合并到 master 之前捕获它们。很快北极星也可以运行在 YAML 文件和舵图表。

现在，在 GitHub 上获得了超过 1200 颗星以及来自社区的大量反馈之后，我们已经了解了很多，我们很高兴地宣布 1.0 中的一些令人惊叹的新功能:

使用 JSON 模式的自定义检查
支持所有控制器类型，包括 OpenShift 和自定义资源
为确实需要特殊权限的工作负载检查豁免
简化配置和输出格式

使用 JSON 模式进行自定义检查

这是迄今为止对北极星最大和最现有的改变:你现在可以使用 JSON 模式定义你自己的定制检查。

最初，我们在 Golang 中对支票进行了硬编码。我们将手动检查如下内容:

if cv.Container.LivenessProbe == nil {
    cv.addFailure(
        messages.LivenessProbeFailure,
        conf.HealthChecks.LivenessProbeMissing,
        category,
        id)
} else {
    cv.addSuccess(messages.LivenessProbeSuccess, category, id)
}

从长远来看，这被证明有点麻烦且容易出错。例如，我们最终意识到 Jobs 和 CronJobs 可能应该免于活性探测检查，这涉及到在一些额外的条件中包装上述语句。随着我们发现更多这样的异常，我们的 Go 代码变得相当笨拙。

更重要的是，我们的用户没有简单的方法来添加他们自己的检查——他们需要将它们添加到我们的代码库中，并且不是每个检查都适合每个组织。

So we decided to move towards using a configuration language for checks. After heavily investigating OPA (more on that below), we decided to go with JSON Schema. Now, the check above, plus all of its exceptions and configuration, looks something like this:

successMessage: Liveness probe is configured
failureMessage: Liveness probe should be configured
category: Health Checks
controllers:
  exclude:
  - Job
  - CronJob
containers:
  exclude:
  - initContainer
target: Container
schema:
  '$schema': http://json-schema.org/draft-07/schema
  type: object
  required:
  - livenessProbe
  properties:
    livenessProbe:
      type: object
      not:
        const: null

现在，与特定检查相关的所有配置都位于同一个位置。我们可以调整它应用的控制器、它生成的消息，甚至检查本身的逻辑，只需编辑一些 YAML。

JSON Schema is incredibly powerful - you can force numbers to fall between maxima and minima, force strings and object keys to match particular patterns, set bounds on array lengths, and even combine schemas using allOf, oneOf, or anyOf. We’ve even extended JSON Schema to let you set minima and maxima for CPU and Memory using human readable strings, like 1GB. To help you get started, we’ve provided some sample schemas for things like restricting memory usage and disallowing particular docker registries.

但是等等，OPA 怎么办？

Kubernetes veterans will probably be wondering why we didn’t go with OPA, a heavyweight validation configuration mechanism that has been developed by the community. We looked at the project carefully, but decided ultimately that it was much more complex and powerful than we (or our users) needed. It takes some time and effort to get used to Rego, the DSL that drives OPA policy. JSON Schema is also already an integral part of Kubernetes - it’s used by CRDs and core resources for validation, and is a part of Open API, which drives the Kubernetes API.

新的控制器类型

When we originally built Polaris, it only checked Deployments, arguably the most common controller type in Kubernetes. But soon after launching we had requests for more controller types, like StatefulSets, CronJobs, and DaemonSets. After adding support for half a dozen different controllers (as well as writing a large amount of boilerplate code, thanks to Go’s rigid type system), we realized we’d never be able to keep up with all the controllers out there - in addition to the core Kubernetes controllers, there are non-standard controllers like OpenShift’s DeploymentConfig.So we decided to try a different tack - instead of fetching controllers, we’d fetch the underlying pods that the controllers create. We could then use Owner References to walk up the hierarchy until we hit something without an owner - i.e. the parent controller.

(作为一个有趣的题外话，我们了解到一些工作负载并不属于一个控制器，而是属于ode 本身！在 1.0 仪表板中，您会注意到 kube-system 中的一些几乎重复的条目。)

With this change in place, we’re able to support any controllers out there in the wild, whether or not we’d even heard of them before. So go ahead and build your own controllers! We’ll still bug you about your liveness probes. grinning face with smiling eyes

然而，请注意，我们还不能在验证 Webhook 中捕获这些新的控制器类型——web hook 仍然监视一组固定的控制器类型。我们可能会对此提供支持，但需要注意的是，我们仍然允许工作负载适当地扩展。

检查豁免

有些工作负载确实需要以 root 用户身份运行，或者访问主机网络。对于很多存在于kube-system中的东西来说都是如此，还有一些实用程序比如cert-manager和nginx-ingress。

To help cut down on the noise generated by these workloads, we’ve created a library of exemptions, which will allow particular workloads to ignore particular checks. You can add your own workloads to this configuration, or you can add annotations like polaris.fairwinds.com/exempt=true and polaris.fairwinds.com/cpuRequestsMissing-exempt=true.

我们希望继续构建这个库，所以如果你运行的是 Istio 或 Linkerd 等常用工具，

新的配置和输出格式

我们的配置语法最初看起来是这样的:

 networking:
  hostNetworkSet: warning
  hostPortSet: warning
security:
  runAsPrivileged: error
  capabilities:
    error:
      ifAnyAdded:
        - SYS_ADMIN
        - NET_ADMIN
        - ALL
    warning:
      ifAnyAddedBeyond:
        - CHOWN
        - DAC_OVERRIDE
        - FSETID

困难在于有些检查只是布尔型的，比如 hostNetworkSet, ，而其他的，比如capabilities,需要一些额外的配置。因此，经过大量的内部讨论后，我们决定采用一种有些不一致但很简单的语法。

在 1.0 中，我们已经去掉了所有额外的配置，转而支持 JSON 模式 (见上面的 )。所以现在语法简单多了:

checks:
  # networking
  hostNetworkSet: warning
  hostPortSet: warning
  # security
  dangerousCapabilities: danger
  insecureCapabilities: warning

请注意，我们也改变了

error

到

danger

区分意外错误和检查失败。虽然输出格式也简化了很多，但它并不完全面向用户，所以我们在这里不做深入讨论。但是如果你有兴趣看的话，

here’s an example.

继续到 2.0

So what’s next for Polaris?

首先，我们想增加更多的支票。现在我们已经有了一个可扩展的方法来构建它们，并且社区也有了一个简单的方法来贡献新的，我们想要构建一个大的检查库，用户可以打开和关闭它。我们希望开始检查不仅仅是工作负载——像入口、服务和 RBAC 这样的东西也需要验证。

我们可能还会添加对 OPA 的支持。虽然 JSON Schema 仍将是 Polaris 的首选格式，但 OPA 将吸引那些已经投入时间创建减压阀策略的组织，或者那些想要编写复杂支票的组织。添加 OPA 支持将使 Polaris 成为一个高度灵活的验证框架。

Finally, we will look to build a deeper integration with Fairwinds Insights, our commercial configuration validation platform. Fairwinds Insights allows you to aggregate Polaris results across multiple clusters, track the lifecycle of findings over time, and push the data out to third-parties like Slack and Datadog. Fairwinds Insights also has plugins for other open-source auditing tools, like Trivy, kube-bench, and Goldilocks, so you can be confident you’re covered all the bases from security to efficiency to reliability.If you have some time to try out Polaris, or if you’re already using it, we’d love to hear from you! Reach out on GitHub and Slack, or send an email to opensource@fairwinds.com.

现已发布:fair winds Polaris 4.0—Kubernetes 资源政策

原文：https://www.fairwinds.com/blog/fairwinds-polaris-4.0-policy-kubernetes-resources

Fairwinds Polaris 已经到了 4.0 版本，有一些令人敬畏的新功能！(对于那些保持分数的人来说，由于一些突破性的变化，我们很快跳过了 2.0 和 3.0)。

我们最初编写 Polaris 是为了帮助 Kubernetes 用户在部署工作负载时避免常见的陷阱。在为几十个组织管理数百个集群的过程中，Fairwinds SRE 团队不断看到相同的错误:资源请求和限制未设置，活跃度和就绪性探测被忽略，容器请求完全不必要的安全权限。这些肯定会造成令人头疼的问题——从停机到成本超支，甚至是安全漏洞。我们将 Polaris 视为将我们所有的战斗伤痕编码到一个单一的配置验证器中的一种方式，这将使整个 Kubernetes 社区受益。

随着 Polaris 从仪表板发展为准入控制器(以防止这些资源进入集群)，现在又发展为 CI 工具(以防止它们进入基础架构代码报告)，我们收到了越来越多的实施新检查的请求，例如入口是否使用 TLS，或者部署是否有 PodDisruptionBudget。

为了更好地满足这些需求，我们在自定义检查功能中实现了三个主要的新特性:

检查非工作负载类型的能力，如入口、服务和集群角色
引用模式中其他字段的能力
交叉检查资源的能力，例如，确保部署有相应的 PodDisruptionBudget

支持非工作负载类型

Polaris 最初设计用于检查集群中运行的工作负载，例如，Pods 和任何创建 Pods 的东西，如部署、CronJobs 和 StatefulSets。这是我们看到最痛苦的错误发生的地方，也是一个自然的起点。

然而，当团队开始部署 Polaris 并看到控制工作负载配置的价值时，他们看到了检查其他 Kubernetes 资源的自然潜力。例如，一些公司有关于入口使用 TLS 的内部或监管要求，并希望检查每个入口对象是否启用了 TLS。

添加对新资源类型的支持需要一点重构。最初我们只需要检索一组固定的资源类型，所以我们能够使用类型良好的 client-go 函数，比如Deployments(``""``).List()。但是支持任意类型需要我们利用动态客户端，由于缺乏类型安全，这需要更多的关注。

为了让您开始，我们已经实现了一个检查来确保入口对象正在使用 TLS 。如果您有其他想法，您可以将它们添加到您自己的 Polaris 配置中，或者甚至更好，打开一个 PR 将它们贡献回核心回购！

支持自我参考

JSON Schema 是一种非常直观和强大的验证资源的方法，但是与更具编程性的框架(比如 OPA)相比，它有一个缺点:JSON Schema 更简单，但是它不能做 OPA 能做的一些更复杂的事情。

特别是，北极星 2.0 没有自我参照的方法。例如，您可能想要检查的一件事是app.kubernetes.io/name标签是否与metadata.name字段匹配。OPA 可以很容易地做到这一点:

package fairwinds 

labelMustMatchName[result] { 

  input.metadata.labels["app.kubernetes.io/name"] != metadata.name 

  result := { 

    "description": "label app.kubernetes.io/name must match metadata.name", 

  } 

}

为了在 Polaris 中支持这一点，我们在 JSON 模式支持中添加了一些基本的模板:

successMessage: Label app.kubernetes.io/name matches metadata.name
failureMessage: Label app.kubernetes.io/name must match metadata.name
kinds:
- Deployment
schema:
  '$schema': http://json-schema.org/draft-07/schema
  type: object
  properties:
    metadata:
      type: object
      properties:
        labels:
          type: object
          required: ["app.kubernetes.io/name"]
          properties:
            app.kubernetes.io/name:"{{ metadata.name }}"

虽然这仍然没有给OPA 所提供的所有灵活性，但它允许我们处理 Polaris 2.0 无法解决的大多数用例。

支持跨资源引用

我们收到的第一个也是最常见的请求之一是能够检查部署是否有关联的 PodDisruptionBudget 或 HorizontalPodAutoscaler。这些资源对于确保部署适当扩展至关重要，并且是大多数组织的部署策略的重要组成部分，因此想要检查这些资源是很自然的事情。

这里的挑战是 Polaris 检查是使用 JSON 模式定义的。这对于单个资源来说非常好——我们只是根据检查的模式验证 Kubernetes API 返回的 JSON。但是为了支持交叉引用，我们必须做一些事情:

提供一种访问非控制器资源的方法(上面的✅)
将某些字段模板化，例如，可以在 poddisruptionbudget(上面的✅)中断言部署的名称
提供在同一检查中定义多个模式的语法

事不宜迟，下面是我们创建的检查，以确保 PDB 附加到所有部署，它使用所有三个新功能:

successMessage: A PodDisruptionBudget is attached
failureMessage: Should have a PodDisruptionBudget
kinds:
- Deployment
schema:
  '$schema': http://json-schema.org/draft-07/schema
  type: object
  properties:
    metadata:
      type: object
      properties:
        labels:
          type: object
          required: ["app.kubernetes.io/name"]
          properties:
            app.kubernetes.io/name: \{\{ metadata.name \}\}
additionalSchemas:
  PodDisruptionBudget:
    '$schema': http://json-schema.org/draft-07/schema
    type: object
    properties:
      metadata:
        type: object
        properties:
          name:
            type: string
            const: {{ metadata.name }}-pdb
      spec:
        type: object
        properties:
          selector:
            type: object
            properties:
              matchLabels:
                type: object
                properties:
                  app.kubernetes.io/name:
                    type: string
                    pattern: {{ metadata.name }}

这里需要注意一些事情:

首先，kinds字段告诉 Polaris 将这个检查与哪些资源相关联。也就是说，如果上述检查失败，您将在相关部署旁边看到一个❌(而不是在 PDB 旁边)。

接下来，schema域像往常一样工作，检查主资源。

最后，additionalSchemas字段是从 Kind 到 JSON 模式的映射。在上面的检查中，Polaris 将检查同一名称空间中的所有 pdb，并试图找到一个与模式匹配的 pdb。如果它没有发现任何东西，检查就会失败。

结论

我们对最新发布的北极星和我们增加的新功能感到兴奋。如今，北极星拥有超过 10，000 名用户，涵盖所有行业。如果您有兴趣管理整个集群舰队的北极星，跨团队合作，或随着时间的推移跟踪调查结果，请查看我们的持续 Kubernetes 安全监控和治理平台 Fairwinds Insights 。

我们也希望 Polaris 用户加入我们新的 Fairwinds 开源软件用户组。我们对您对 Polaris 的贡献感到非常兴奋，并共同努力验证和实施 Kubernetes 部署。

“北极星”自动补救的实际应用

原文：https://www.fairwinds.com/blog/fairwinds-polaris-automated-remediation

Fairwinds 的核心任务是让使用 Kubernetes 的团队能够以更低的风险更快地发布应用程序。平台工程领导者处于这一领域的最前沿:他们的工作是为下游应用团队提供获得成功的正确工具。然而，要在多个应用团队和集群中大规模实现这一点，平台工程师必须投资于自动化和 Kubernetes guardrails ，以便向 DevOps 工程师提供关于其配置更改的安全性、成本效益和可靠性的持续反馈。

Polaris 是平台工程团队赖以获得持续反馈和防护的工具之一。它目前以不同的模式运行:

作为集群内控制面板，突出显示工作负载最佳实践或需要改进的领域
作为验证准入控制器，检查请求并确定是否应该部署它们
作为 CI/CD 平台的基础设施代码审计工具

我们很高兴地宣布，我们已经为北极星增加了自动修复功能。更具体地说，Polaris 准入控制器现在包括一个可变的 webhook，它可以修改请求——比如基于特定的策略标准添加、更改或删除对象。了解其工作原理。

变异准入控制器的实际使用案例

变异准入控制器可用于自动将最佳实践应用于每个部署，使团队能够更快地前进。然而，改变准入控制器的一个缺点是潜在的配置漂移，即当 git repo 中的基础设施代码与运行时状态不匹配时。尽管如此，在某些情况下，这种折衷可能是合适的。以下是我们从 Polaris 社区中了解到的三个变异准入控制器的实际用例:

保证 Kubernetes 的最佳实践:例如，在某些情况下，您可能希望确保将图像拉取策略设置为‘Always’。如今，当工程师忽略设置正确的图像拉取策略时，Polaris 可以在拉取请求阶段提醒他们。然而，变异的准入控制器可以保证期望的图像拉取策略，即使工程师忽略了进行改变。
为成本分配应用标签:改变准入控制器还可以确保您的集群工作负载被正确标记，而不会减慢开发人员的速度。例如，fair wind Insights等成本分配解决方案通过标签报告工作负载的成本，因此应用正确的标签是通过相关业务维度了解 Kubernetes 成本的关键。
减轻安全威胁:今天，Polaris 将报告可能被过度许可或以不安全的配置运行的工作负载。然而，一个自动将您的工作负载设置为以非根用户身份运行的突变策略可以帮助平台和安全团队减少像 CVE-2021-25741 这样的漏洞。

最后一件事…

北极星也使得将突变应用于原始 YAML 文件成为可能。这有助于团队在“编码”阶段减少配置偏差——从一开始就自动生成包含特定最佳实践的 Kubernetes YAML。最终，像这样的解决方案可以帮助组织节省时间和金钱——特别是在大规模部署像 Fairwinds Insights 这样的 SaaS 平台时。

资源

Fairwinds 的北极星是什么？Kubernetes 开源配置验证

原文：https://www.fairwinds.com/blog/fairwinds-polaris-kubernetes-open-source-configuration-validation

Kubernetes 是一个非常强大的软件部署平台。它提供的灵活性水平几乎可以适应任何用例，无论多么独特。这就是 Kubernetes 被超过半数的财富 500 强企业采用的原因。根据 Dimensional Research 和 VMware 的一项研究，“Kubernetes 2020 年状态报告”K8s 的采用率从 2018 年的 27%大幅飙升至 2020 年的 48%。

但是和所有工具一样，在动力和安全之间有一个自然的权衡。有数百万种方法可以配置 Kubernetes 及其运行的工作负载，但其中 99%都是危险的。很容易引入安全性、效率或可靠性方面的问题——通常只是因为忘记在 YAML 配置中指定特定字段。

为了解决这个问题，社区提出了一套配置 Kubernetes 工作负载的 Kubernetes 最佳实践。除非你有一个非常好的理由不这样做，否则这些都是应该一直遵循的指导方针。Fairwinds 的 Polaris 项目就是为了帮助定义和实施这些最佳实践而诞生的。

一个例子

这里有一个 Kubernetes 部署的例子，直接取自北极星文档:

YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

你能看出它有什么毛病吗？可能不会，除非你非常熟悉 Kubernetes 的配置。但是还有几个字段没有指定，可能会导致严重的问题。

CPU 和内存设置

首先，告诉 Kubernetes 您的应用程序预计会使用多少内存和 CPU 是很重要的。这使得 Kubernetes 可以有效地将您的工作负载打包到运行它们的底层节点上，并在应用程序出现问题时(例如，由于内存泄漏)为 it 部门提供指导。

一个更好的容器规范应该是这样的:

YAML
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          requests:
            memory: 512MB
            cpu: 500m
          limits:
            memory: 1GB
            cpu: 1000m

健康探针

上面的例子还缺少活性和就绪性探测。这些设置告诉 Kubernetes 如何检查您的应用程序是否正常，是否准备好为流量服务。如果没有活跃度探测器，Kubernetes 将无法在应用程序死机时进行自我修复；如果没有准备就绪探测器，它可能会将流量导向尚未完全准备就绪的 pod。

活性和就绪性探测需要一些特定于应用程序的知识，但通常会轮询特定的 HTTP 端点或运行 Unix 命令来测试应用程序是否正确响应。例如:

YAML
      containers:
        livenessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080

安全措施加强

许多 Kubernetes 的工作负载设置是“默认不安全的”——它们错误地授予应用程序权限来做它可能需要或可能不需要的事情。例如，默认情况下，每个容器都会安装一个可写的根文件系统，这使得攻击者能够替换系统二进制文件或修改配置。

更安全的容器配置如下所示:

YAML
      containers:
      - name: nginx
        image: nginx:1.14.2
        securityContext:
          allowPrivilegeEscalation: false
          privileged: false
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          capabilities:
            drop:
              - ALL

北极星如何提供帮助

北极星检查所有上述问题和更多。它带有 24 个内置检查(截至 2021 年 5 月)。随着用户提交反馈以及社区学习新的和更好的配置工作负载的方法，检查不断被添加到我们的库中。

我们的每个检查都是在 JSON Schema 中定义的——每次运行kubectl来验证添加到集群中的资源时，Kubernetes 都使用相同的模式语言。

最简单的检查只需要几行配置:

YAML
successMessage: Host network is not configured
failureMessage: Host network should not be configured
category: Security
target: Pod
schema:
  '$schema': http://json-schema.org/draft-07/schema
  type: object
  properties:
    hostNetwork:
      not:
        const: true

但是我们也可以利用 JSON Schema 和 Go 模板的全部功能来创建一些非常复杂的检查。您可以查看一下Polaris 文档以了解更多关于如何编写您自己的自定义 Polaris 检查的信息，如果您的组织有自己的内部政策和想要实施的最佳实践，这将非常有帮助。

一旦设置好 Polaris 配置(或者您对我们提供的默认配置感到满意)，Polaris 可以在三种不同的模式下运行:作为仪表板，向您显示集群中哪些资源需要关注；作为准入控制器，阻止有问题的资源进入集群；或者在 CI/CD 中，在签入之前检查基础结构代码。

自信地部署

Kubernetes 是一个非常强大的平台，但是伴随着强大的能力而来的是巨大的责任。在部署到 Kubernetes 时，确保遵循最佳实践是非常重要的。如果您忽视验证您的配置，可能会导致安全漏洞、生产中断或云成本超支。

将 Polaris 添加到您的工作流程中——无论是在 CI/CD、准入控制，还是只是一个被动的仪表板——都可以帮助您充满信心地在这些危险的水域中航行。如果你想在一系列集群中使用 Polaris，或者将它与其他一些优秀的 Kubernetes 审计工具结合使用，例如用于扫描集装箱图像的 Trivy 和用于调整内存大小和 CPU 设置的 Goldilocks ，请查看用于在 Kubernetes 环境中审计和执行策略的平台 Fairwinds Insights 。

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

因此，无论您是经验丰富的 Kubernetes 专家，还是刚刚开始构建您的第一个集群，请确保您已经准备好了一些防护栏！Fairwinds 的北极星和 T2 的洞察力是一个很好的起点。

Fairwinds 发行说明:5.6.0 - 6.1.0

原文：https://www.fairwinds.com/blog/fairwinds-release-notes-5.6.0-6.1.0

我们在费尔温斯一直很忙。今年 10 月，我们升级了软件的许多元素，包括对服务质量工作负载、页面任务集成和导航栏的改进，此外，我们还修复了几个错误。这个博客将涵盖你需要知道的关于新版本 5.6.0-6.1.0 的一切，以及它们的进步将如何影响你的 Kubernetes 所有权的安全性和可靠性。

Fairwinds Insights 旨在确保您的组织继续发现正在进行的 Kubernetes 安全监控、政策执行、合规和成本优化。

5.6.0 工作负载的服务质量

新的 QoS 参数允许用户指出其工作负载的重要性，同时还允许 Insights 根据该参数推荐资源。从重要性最高到最低，这些值是关键的、有保证的、突发的和有限的。此版本中的错误修复包括:

集群的操作项目计数不再包括在组织仪表板中传递它们。
行动项目表现在可以根据解决方案正确过滤。
组织仪表板的用户界面修复已完成。

5.7.0 页面负载集成

组织现在可以设置 PagerDuty 集成，以便从 Insights 自动发送突发事件。团队管理现在在邀请已经是组织成员的用户时显示更好的错误。你可以在这里了解更多关于我们的 PagerDuty 集成。

重命名导航栏项目

一些导航项目已被重命名如下:报告中心以安装中心，Repos 到所有存储库，集群到所有集群。错误修复包括:

主存储库页面不再使用旧的操作项徽章。
准入控制器项目现在在折叠后加载。
“集群概述”页面上历史条形图下的链接将被修复。

6.1.0 新普罗米修斯行动项目

Prometheus Collector 报告现在将根据工作负载指标生成行动项目。组织仪表板中集群表的加载时间现在更快了，并且跨 Insights 进行了各种 UI 改进。

您可以随时在此查看发行说明的完整列表。

你们中的一些人可能已经在使用我们的开源项目了。我们最近推出了一个开源用户组，我们一直希望有更多的人加入我们。在这里注册 Fairwinds 开源用户组，并加入我们 12 月的下一次聚会！

Fairwinds 发行说明:6.3.0-6.6.0

原文：https://www.fairwinds.com/blog/fairwinds-release-notes-6.3.0-6.6.0

我们一直像往常一样忙碌，升级我们的 Fairwinds Insights 软件的各种元素。但在分享这些改进之前，我们想花点时间强调一下我们最近对 AWS 的计费准确性所做的一些更改。

Kubernetes AWS 的计费准确性

Fairwinds Insights 已经包含了 Kubernetes 的成本特性。我们帮助团队调整其应用程序的规模，以确保他们最大限度地利用可用资源，经济高效。我们最新的 Kubernetes 成本分配功能允许 AWS 客户使用他们的实际账单，按照工作负载、名称空间或标签来计算 Kubernetes 成本。这种集成比传统的云成本工具更深入，可以跨多个业务维度提供准确的、基于使用情况的成本数据。DevOps 团队可以满足服务所有者和财务的需求，而无需质疑底层节点定价假设。

阅读更多！ 您现在如何使用您的 AWS 账单在 Kubernetes 上准确测量应用成本

发行说明

在 11 月，我们升级了几个软件元素，包括对 Helm 库的远程扫描的改进和对现有问题的许多错误修复。本博客将涵盖您需要了解的关于新版本 6.3.0-6.6.0 的一切，以及它们的进步将如何影响您的 Kubernetes 所有权的治理和安全性。

fair winds Insights在这里是为了确保您的组织继续发现正在进行的 Kubernetes 安全监控、策略执行、和成本优化。

6.3.0 扫描远程舵库

组织现在可以从远程 helm 存储库中扫描图表来查找问题。通过在 fairwinds-insights.yaml 文件中提供名称、repo 和图表，Fairwinds Insights 现在可以从远程存储库下载图表并运行适当的扫描。

错误修复包括:

现在，修改自动化规则会显示哪个用户更新了它，以及何时更新的。
通过行动项目现在在健康记分卡上可见/可用。

6.4.0 启用和禁用准入控制器被动模式

现在，用户可以通过 API 启用和禁用准入控制器的被动模式。你可以在这里了解更多关于准入控制器被动模式。我们还更新了 Insights 代理，进行了一些小的改进和修复。注意:从这个版本开始，对于任何新的集群，接纳控制器默认设置为被动模式。

6.5.0 准入控制器事件包括部署者的用户名

当用户导航到准入控制器页面时，他们将看到包含进行部署的用户名称的事件。这种可见性有助于支持集群中多个团队/用户的集群管理员更好地了解是谁进行了特定的部署。

图像漏洞行动项目中可用的基本图像信息

Insights 现在可以检测图像漏洞的基础图像层。您可以在映像漏洞的操作项描述中找到此信息，这有助于开发人员快速轻松地识别他们正在运行的基础映像。这允许开发人员检查是否有更新的版本可以修复任何报告的 CVE。

错误修复包括:

加快组织仪表板的加载速度
跨洞察的各种 UI 改进

6.6.0 全新设计的行动项目 UI！

用户现在可以在其组织的导航栏以及特定集群的导航栏下找到新的 Action Items 页面。该页面包括一个完全重新设计的 Action Items 表版本，具有一些新功能，例如隐藏和显示表列。

用“列表”跟踪重要的行动项目

用户可以创建带有行动项目的列表，用于跟踪重要的行动项目以及解决这些项目的任何进展。

更好地管理系统级行动项目的新自动化规则

创建了一个新的自动化规则，以便用“不会修复”解决方案清楚地标记某些名称空间中的操作项。默认情况下，此规则将对现有组织禁用，但对新组织启用。

错误修复包括:

没有实例的策略不再有加载和编辑问题
现在只允许管理员和编辑者集群更改工作负载的 QoS
具有可用修复的漏洞现在可以被正确过滤

您可以随时在此查看发布说明的完整列表。

免费使用 Fairwinds Insights】

如果您正在寻找 Kubernetes 治理和安全软件，Fairwinds Insights 是免费的。今天就开始吧。

你们中的一些人可能已经在使用我们的开源项目了。我们最近推出了一个开源用户组，我们一直希望有更多的人加入我们。在这里注册 Fairwinds 开源用户组，加入我们 12 月的下一次聚会吧！

在 Kubernetes:Pluto 简介中查找不推荐使用和删除的 API

原文：https://www.fairwinds.com/blog/find-deprecated-and-removed-apis

资源:

视频记录:

下面是对我们的开源工具 Pluto 的一个简要概述。

Pluto:查找已弃用和已删除的 API 版本

Pluto 是一个实用程序，它可以帮助您在 Kubernetes 集群中找到不推荐使用和删除的 API 版本。因此，随着时间的推移，Kubernetes 不得不放弃不同的版本，以便我们能够向前发展，只使用最新的版本，而不必随着时间的推移支持一切。因此，有一个过程可以做到这一点，一个 API 版本被弃用，并最终从 API 中实际删除。因此，Pluto 会将您的基础架构视为代码或您的掌舵图，或者您在集群中安装的掌舵图，并告诉您是否有那些最终将被删除的过时版本，以便您可以找到它们并修复它们。

冥王星是如何工作的？

Pluto 是一个命令行工具。您可以用几种不同的方式安装它。所以我们有一个 ASDF 插件。我们可以把 ASDF 接上，加上冥王星。或者我们可以在 Golang 中构建二进制文件并安装它。我们刚刚做了一些更新，所以你现在可以去安装它，如果你熟悉这个命令。或者，您可以从 GitHub 发布页面上获取二进制文件，并将其放在您的路径中的某个位置。这是冥王星双星。我们要做的第一件事是检测文件。因此，在我们的 Pluto 存储库中，我们有一些测试 Pluto 的测试文件，但是您可以针对任何部署到 Kubernetes 的平面 YAML 文件运行这些文件。所以我们要检测文件。我们将在这里获得一些信息，包括对象的名称、对象的种类、对象的当前 API 版本，以及哪个 API 版本取代了过时的版本。我们在这里可以看到它是否被删除，是否被弃用。

因此，我们在这里看到，扩展 v1 beta one 部署在 1.9 版本中被弃用，并在 1.16 版本中被删除。我们可以通过向冥王星传递另一个标志来查看该信息。如果我们知道它在哪个名称空间，它会告诉我们它何时被弃用，何时被删除，它在哪个名称空间。这就是冥王星的核心所在。检查一下你的文件，确保不会有什么东西被否决。我们在这里看到，我们也有一个非零的退出代码。因此，我们可以将它插入到 CI 系统中，如果我们不赞成使用 API，就会导致构建失败，有几个标志可以帮助调整该行为，以便您可以按照自己想要的方式使用它。

冥王星做得很好的第二件事是，它查看位于你的集群内的释放对象中的掌舵清单。因此，如果您正在使用 Helm，并且想要查看您的集群中已经部署了哪些 API 版本，我们可以使用 detect Helm 命令。同样，我将在这里查看宽输出，因为我认为它的信息量更大一些。我们在这里看到，我们有一个头盔版本，其中有一些过时的版本。所以这里有一个政策 v1 beta 的 pod 中断预算。这被政策 v1 所取代。V1 beta one 在 1.21 中被弃用，并将在 1.25 中被删除。所以在我升级到 Kubernetes 1.25 之前，我需要更新这个对象的 API 版本。

现在你可能会问为什么我们只看舵图？Kubernetes 很棒，因为它可以在 API 版本之间进行转换。因此，如果我让 Kubernetes 给我一个部署，它会告诉我我在寻找什么 API 版本，而不管哪个 API 版本被部署到集群。因此，我们必须看一些更明确的东西，解释对象是如何部署到集群的。因此，在这种情况下，Helm 版本对于在部署到集群中时部署的 API 版本非常明确。这就是为什么我们只用头盔。

所有这些信息都可以在我们的文档页面上找到。所以如果你去 pluto.docs.fairwinds.com，你可以看到我们这里有所有这些信息，它讲述了我们为什么建造冥王星，它的用途，库伯内特的弃用政策，以及冥王星的一些不同用法。简而言之，这就是冥王星。谢谢你们的倾听，祝你们一周都过得愉快。

找到你的 Kubernetes 成本盲点

原文：https://www.fairwinds.com/blog/find-kubernetes-cost-blind-spots

在过去的十年里，云基础设施发生了翻天覆地的变化，这几乎令人难以置信。我在技术领域的第一份工作是在一个壁橱里有一个服务器室，我们自己处理一切，从硬件和操作系统到网络，甚至是我们用来更新软件的光驱。今天，我们将越来越多的 it 交给云本身，我们不担心底层的服务器，也不担心网络。没有我们曾经与之互动的物理驱动，因此我们的生活变得更好。

有趣的是，当我们远离所有系统中如此多的有形部分时，我们就更加远离了运行这种基础设施的实际成本。云对于有形硬件就像信用卡对于现金一样，它不会花费更多，只是当我们不动手时，更难说出所有的钱去了哪里。

Kubernetes 仍然是一个新的范例

Kubernetes 把事情带到了一个新的水平。在 Kubernetes 之前，我们可能已经为工作负载提供了自动化，但随着 container orchestrator 成为我们与云基础架构交互的方式，一切都变成了一个更大的黑匣子。

Kubernetes 的美妙之处在于，我们可以交给它一个工作负载，让它担心如何根据需求进行伸缩。负面影响是，如果我们在将工作交给 Kubernetes 之前错误地配置了工作负载，那么很容易出现成本失控的情况，因为 Kubernetes 完全按照我们(错误地)告诉它的那样去做。

Kubernetes 的成本

Kubernetes 本身的运行成本非常低，因为它主要只是一个控制平面，负责协调其他工作负载，但是每个新模式都有相关的成本。在 Kubernetes 中，当资源请求和限制设置不正确时，将导致支出超过您的需要(因为工作负载过度供应，Kubernetes 扩展的内容超过需要)，或者导致性能不佳(因为工作负载耗尽内存或 CPU 受限)。它还会导致工作负载优先级过高或过低，因为 Kubernetes 会尽力理解交给它的工作。

如果没有良好的工具来了解集群的成本或工作负载的成本，开发人员(特别是在高级服务所有权环境中)很容易过度调配资源，平台团队也很难洞察如何解决失控的成本，直到为时已晚，账单已经上涨。

我经常听到这样的故事:一个团队在很久以后才发现——当他们最终收到云账单时——他们的工作负载配置错误，成本飙升。

Fairwinds Insights 提供了控制成本所需的可见性

Kubernetes guardrails 平台 Fairwinds Insights 为您的所有集群提供了一个单一平台，以查看哪些集群和哪些工作负载的成本最高。您还可以跟踪一段时间内的趋势，这样您就可以看到事情失控的地方以及如何解决它们。

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

伟大的工具造就伟大的团队。云的承诺是你的花费实际上可以满足你的需求。在你控制你的 Kubernetes 基础设施之前，不要让事情失去控制。

观看 Clover 如何利用洞察力控制成本。

K8s 教程:用 Nova 查找过时的舵图

原文：https://www.fairwinds.com/blog/find-outdated-helm-charts-with-nova

确保您在 Kubernetes 集群中安装了最新版本的软件，这有助于您避免已知的安全问题，并获得最新的项目功能。如果您使用 Helm 来管理您的版本， Fairwinds Nova 可以帮助您找到在您的集群中运行的过时或废弃的 Helm 图表。您可以从命令行运行 Nova，或者将其集成到您的持续集成过程中，并且从 3.1.0 版本开始，您可以扫描容器。

如何安装

使用 asdf，Homebrew，从源代码或 GitHub 版本安装 Nova。完整的安装说明在 Nova 文档中。在本文中，我们演示了如何从 GitHub 发布页面安装 Nova。

首先，访问版本页面，找到适合您环境的版本。例如，在采用 amd64 处理器的 Linux 机器上，您将需要下载适用于 Linux amd64 的版本。

运行以下命令下载并安装 Nova:

curl -L "https://github.com/FairwindsOps/nova/releases/download/3.2.0/nova_3.2.0_linux_amd64.tar.gz" > nova.tar.gz
tar -xvf nova.tar.gz
sudo mv nova /usr/local/bin/

接下来，通过运行 help 命令检查安装是否正常工作:

nova help

您应该会看到 Nova 命令和选项的列表，如下所示:

fairwinds tool to check for updated chart releases.

Usage:
  nova [flags]
  nova [command]

Available Commands:
  completion      Generate the autocompletion script for the specified shell
  find            Find out-of-date deployed releases.
  generate-config Generate a config file.
  help            Help about any command
  version         Prints the current version.

Flags:
      --alsologtostderr                   log to standard error as well as files (default true)
      --config string                     Config file to use. If empty, flags will be used instead
      --context string                    A context to use in the kubeconfig.
  -d, --desired-versions stringToString   A map of chart=override_version to override the helm repository when checking. (default [])
  -h, --help                              help for nova
  -a, --include-all                       Show all charts even if no latest version is found.
      --logtostderr                       log to standard error instead of files (default true)
      --output-file string                Path on local filesystem to write file output to
      --poll-artifacthub                  When true, polls artifacthub to match against helm releases in the cluster. If false, you must provide a url list via --url/-u. Default is true. (default true)
      --show-old                          Only show charts that are not on the latest version
  -u, --url strings                       URL for a helm chart repo
  -v, --v Level                           number for the log level verbosity
      --wide                              Output chart name and namespace

Use "nova [command] --help" for more information about a command.

使用 Nova 审计舵图版本

运行 Nova 最快的方法是从命令行。要扫描您当前通过身份验证的 Kubernetes 集群中安装的 Helm 图表，请运行命令:

nova find

您将看到您的 Helm 版本列表、集群中安装的 Helm 图表版本、最新可用版本以及您的版本是否过期。

Release Name             Installed    Latest    Old      Deprecated
============             =========    ======    ===      ==========
kube-prometheus-stack    26.1.0       37.3.0    true     false
metrics-server           3.8.0        3.8.2     true     false
vpa                      1.4.0        1.4.0     false    false

有关这些 Helm 版本的更多信息，包括它们在哪个命名空间中运行，请调用以下命令:

nova find –wide

Release Name             Chart Name               Namespace    HelmVersion    Installed    Latest    Old      Deprecated
============             ==========               =========    ===========    =========    ======    ===      ==========
kube-prometheus-stack    kube-prometheus-stack    demo         3              26.1.0       37.3.0    true     false
metrics-server           metrics-server           demo         3              3.8.0        3.8.2     true     false
vpa                      vpa                      demo         3              1.4.0        1.4.0     false    false

要更新您的舵版本，请复制最新版本的海图，并运行“舵升级”命令。在我们的示例中，metrics-server 图表版本已经过时，因此要更新它，我们将运行:

helm upgrade metrics-server metrics-server/metrics-server --version 3.8.2

如果图表被否决，您将看到以下内容:

Release Name    Installed    Latest    Old      Deprecated
============    =========    ======    ===      ==========
kubewatch       3.3.4        3.3.4     false    true

不推荐使用的图表应该得到特别的关注，因为这意味着项目不再被维护，也不会有其他的更新。弃用的软件部署的时间越长，它就变得越脆弱，越容易受到攻击。被弃用的流行项目通常会更改名称或 Helm repos URLs，被弃用图表的文档会为您指出新项目，或提供您应该考虑的替代方案。

注意:在撰写本文时，Nova 在不推荐使用的图表和 artifacthub.io 方面存在一个有趣的问题。为了生成上面显示的输出，我们必须禁用 artifacthub.io 扫描，并直接在 kubewatch 的图表存储库中指向 Nova。用于执行此操作的命令是:

nova find --poll-artifacthub=false --url=https://charts.bitnami.com/bitnami

artifacthub.io 的问题在于，我们不知道已安装的 Helm 版本来自哪个实际的源代码库。这是目前正在积极讨论中的对头盔改进提案【HIP】中头盔的修改。此外，我们正在追踪 Github 中的问题。

使用 Nova 审计容器版本

最近，Nova 增加了一个新的容器扫描功能。通过运行带有`- containers '标志的“nova find”命令，可以看到这一点:

nova find --containers

Container Name                                            Current Version         Old     Latest     Latest Minor            Latest Patch
==============                                            ===============         ===     ======     =============           =============
quay.io/prometheus/alertmanager                           v0.23.0                 true    v0.24.0    v0.23.0                 v0.23.0
quay.io/prometheus-operator/prometheus-config-reloader    v0.53.1                 true    v0.58.0    v0.53.1                 v0.53.1
quay.io/kiwigrid/k8s-sidecar                              1.14.2                  true    1.19.2     1.19.2                  1.14.3
grafana/grafana                                           8.3.3                   true    9.0.4      8.5.9                   8.3.10
k8s.gcr.io/kube-state-metrics/kube-state-metrics          v2.3.0                  true    v2.5.0     v2.5.0                  v2.3.0
quay.io/prometheus-operator/prometheus-operator           v0.53.1                 true    v0.58.0    v0.53.1                 v0.53.1
docker.io/bitnami/kubewatch                               0.1.0-debian-10-r571    true    0.1.0      0.1.0-debian-10-r571    0.1.0
k8s.gcr.io/metrics-server/metrics-server                  v0.6.0                  true    v0.6.1     v0.6.0                  v0.6.1
us.gcr.io/k8s-artifacts-prod/ingress-nginx/controller     v0.34.1                 true    v1.3.0     v0.34.1                 v0.34.1
quay.io/prometheus/prometheus                             v2.32.1                 true    v2.37.0    v2.37.0                 v2.32.1
k8s.gcr.io/autoscaling/vpa-recommender                    0.10.0                  true    0.11.0     0.10.0                  0.10.0
k8s.gcr.io/autoscaling/vpa-updater                        0.10.0                  true    0.11.0     0.10.0                  0.10.0
docker.io/datawire/quote                                  0.4.1                   true    0.5.0      0.4.1                   0.4.1
k8s.gcr.io/coredns/coredns                                v1.8.6                  true    v1.9.3     v1.9.3                  v1.8.6
k8s.gcr.io/etcd                                           3.5.3-0                 true    3.5.4-0    3.5.3-0                 3.5.3-0
k8s.gcr.io/kube-apiserver                                 v1.24.1                 true    v1.24.3    v1.24.3                 v1.24.3
k8s.gcr.io/kube-controller-manager                        v1.24.1                 true    v1.24.3    v1.24.3                 v1.24.3
k8s.gcr.io/kube-proxy                                     v1.24.1                 true    v1.24.3    v1.24.3                 v1.24.3
k8s.gcr.io/kube-scheduler                                 v1.24.1                 true    v1.24.3    v1.24.3                 v1.24.3

定制 Nova

虽然拥有最新的舵图和容器版本是理想的，但是工程团队选择固定特定版本有很多原因。也许团队还没有准备好升级，因为最新版本引入了突破性的变化。Nova 允许您声明自己的版本集，而不是使用最新的可用版本进行比较，从而适应了这一点。您可以通过命令行或文件设置所需的版本。

例如，在我们上面的 Nova 扫描中，我们发现我们目前运行的是 kube-prometheus-stack Helm chart 的 26.1.0 版本，尽管最新版本是 37.3.0。在这种情况下，我们的工程团队需要使用早期版本。

要将所需版本设置为 26.1.0，请运行命令:

nova find --desired-versions='kube-prometheus-stack=26.1.0'

如果您希望在文件中设置所需的版本，请使用以下命令生成配置文件:

nova generate-config --config=nova.yaml

在 Nova 配置文件中，将 kube-prometheus-stack=26.1.0 添加到所需版本列表中，如下所示:

containers: false
context: ""
desired-versions: { 
  kube-prometheus-stack: 26.1.0
}
include-all: false
output-file: ""
poll-artifacthub: true
show-errored-containers: false
show-non-semver: false
show-old: false
url: []
wide: false

大规模应用 Nova 的优势

如果你有多个集群，并希望大规模应用 Nova 的优势，Fairwinds 提供了一个名为 Insights 的平台。用户可以跨集群一致地集中管理 Nova，以确保您的 Helm 发布版本和容器是最新的。Nova 也足够灵活，可以集成到持续集成系统中。

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

资源

在我们新的基准测试报告中了解您的 Kubernetes 工作负载的对比情况

原文：https://www.fairwinds.com/blog/find

经过长时间的艰苦工作，建立了全面有效的 Kubernetes 所有权，并让您的每个开发团队正确配置了他们的工作负载，您是否想过您的容器配置与您在云原生环境中的同行相比如何？好了，不用再想了，因为 Kubernetes 治理和安全的可信合作伙伴 Fairwinds 刚刚发布了 2021 年基准报告，这是一份基于使用 Fairwinds Insights 平台对数百家组织的 100，000 多份工作负载进行扫描的行业比较。

基准报告分为三个部分——可靠性、安全性和效率——对于希望了解其工作负载与其他业务相比如何的 Kubernetes 用户来说，这是一个非常好的工具。众所周知，正确的 Kubernetes 配置对于成功的云原生采用至关重要。没有它，从业者就没有办法提高他们的应用程序的可靠性、安全性和效率。随着组织的发展，开发运维团队以及平台和安全负责人需要了解每个集群中正在发生的事情。

从积极的一面来看，Kubernetes 提供了围绕配置的定制，这允许从业者更多地了解他们独特的环境。但是这种定制带来了风险，主要是因为错误配置很容易导致安全缺陷、停机和资源浪费。让我们来看看这份新报告的内容:

可靠性

基准测试报告强调了围绕 Kubernetes 成功的各种最佳实践，包括缺少 CPU 限制和请求、内存限制以及缺少活动和就绪性探测。确保扩展操作正常工作的关键是在每个 pod 上拨入您的资源限制和请求，以便工作负载正常运行。正确设置这些参数对于在 Kubernetes 集群中成功运行应用程序至关重要。

你知道吗？

安全性

了解有多少组织使用不安全的功能运行其工作负载，以及安全设置如何控制容器是否能够写入其文件系统。当涉及到容器安全性时，团队需要明确确保他们利用了可能的最安全的配置实践。在该基准报告中，您可以深入了解有关可写文件系统、权限提升以及运行特权或 root 如何影响安全环境的信息。

你知道吗？

效率

几乎一半的工作负载的内存限制设置过高，这通常会导致浪费或不必要的资源。您的工作负载的内存限制是否设置得太低？太高了？为了最大限度地利用您的 Kubernetes 集群，了解如何正确设置资源限制和请求是很重要的——设置太高，您最终会浪费资源，设置太低，您的应用程序会崩溃。为了避免因过度分配而浪费资源，您需要更多地了解高效运行所需的工作负载。

如果您希望更多地了解您的组织如何与行业中的其他组织竞争，以及最佳实践模式，请阅读我们最新的基准报告并步入成功拥有 Kubernetes 的轨道！

适用于 Kubernetes 的 FinOps“爬、走、跑”成熟度模型

原文：https://www.fairwinds.com/blog/finops-maturity-model-applied-to-kubernetes

FinOps 已经成为许多组织越来越受欢迎的目标。它有助于将跨组织的财务团队和云运营团队团结在一起，使用同一种语言，了解云成本以及如何优化它们。

FinOps 基金会的成熟度模型描述了一个“爬行、行走、奔跑” 基金会称遵循这种模式“组织[可以]从小规模开始，随着商业价值保证职能活动的成熟，在规模、范围和复杂性上增长。”

爬行、行走、奔跑方式映射到了 Kubernetes 成熟度模型 Fairwinds 加在一起，而 CNCF 在生产云原生成熟度模型时严重依赖。随着用户采用 Kubernetes，他们将对技术、人员、流程和政策采取类似的爬行、行走、运行方式。财务方面也应该是采用的一部分。

爬行

FinOps Foundation 爬行阶段的成熟度级别特征包括很少的报告和工具、基本 KPI、基本流程和策略，并且测量仅提供对成熟 FinOps 功能的益处的洞察。

那么这如何映射到 Kubernetes？对于工程领导者来说，Kubernetes 本身可能是一个很大的未知数。虽然采用 Kubernetes 的决定本身是战略性的，但资源分配如何配置的本质细节可能会产生重大影响。例如，Kubernetes 的一个好处是它的自动伸缩性。但是，如果没有设置资源限制或请求，这种好处可能会很快变成 5 万美元的超支。

在 Kubernetes 的爬行阶段，不太需要采用完整的 FinOps 文化，更多的是组织试图掌握 Kubernetes 中实际发生的事情。大多数组织缺乏对其集群内发生的事情的可见性

爬行阶段最重要的部分是正确设置 CPU 和内存。像 Goldilocks 这样的开源工具有助于确定设置 Kubernetes 资源请求和限制的基线。这在一到三个集群的小型环境中就足够了，在这些环境中，您很可能只有少量的工程师(一两个)管理 Kubernetes。拥有像 Goldilocks 这样的工具非常重要，原因如下:

它有助于提供一些关于资源分配的基本 KPI
它有助于实现一些基本的流程和策略，因为团队可以看到哪些集群具有正确配置的资源请求和限制
它提供了对每个应用程序的资源使用情况的一些测量，并支持应用程序规模调整

当爬行时，不太可能所有这些都被传达给上游的财务团队，但是当您进入行走阶段时，建立一些工程过程和最佳实践是非常重要的。

步行

FinOps 成熟度模型描述了在组织内理解和遵循能力、自动化和过程到位、存在困难的边缘情况并且或者没有解决或者有解决它们的计划的行走阶段。KPI 更加具体地衡量成功。

很可能当您到达 walk 阶段并且正在使用 Kubernetes 时，您正在运行多个集群并且有许多工程师在使用它。这是开源工具不一定要扩展的地方。

Kubernetes 用户需要研究一个平台，以帮助他们了解他们的环境，并在应用程序配置不正确时获得警报。这种理解包括每个工作负载或工作负载组的资源分配–用户应该能够按照集群、名称空间或标签来分配和分组成本估计，从而使报告更容易与业务环境保持一致。这将使工程领导层能够与财务团队合作，了解 Kubernetes 使用的真实成本以及哪里存在闲置或间接成本。此外，它还有助于改善 KPI，因为 Kubernetes 和单个应用程序可以根据它们的总体使用情况和估计的潜在节省进行优先排序，通常有机会在不影响应用程序性能的情况下优化资源使用和降低成本。

当您“行走”时，开发运维团队和平台工程团队正在研究成本问题。当您进入运行阶段时，这种情况会发生变化。

奔跑

FinOps 说，处于运行阶段的组织都是一致的，并且采用了一个健壮的模型。衡量成功的目标/KPI 非常高，自动化是首选。

这就是 Kubernetes 服务所有权映射到 FinOps 成熟度模型的地方。服务所有权是使开发人员能够“编码、发布、拥有”它的能力当到达运行阶段时，开发人员和工程负责人让开发人员能够自己查看集群中每个工作负载的成本以及如何进行改进。这种开发人员支持是通过采用像 Fairwinds Insights 这样的软件实现的，该软件自动扫描集群，以提供跨名称空间、工作负载和标签的集群容量和使用情况的细分。它提供了关于在闲置容量、共享资源和特定于应用程序的资源上花费了多少的信息。

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

运行时，还可以向财务团队提供 Kubernetes 使用成本的反馈报告，向开发团队分配具体的成本，并跟踪一段时间内的节省。像 spot 实例和面向批处理的任务这样的高级概念也可以帮助您更经济高效地运行。

优化库伯内特资源的决策健康

Fairwinds Insights 通过监控资源使用情况来确定可以在不影响性能的情况下降低成本的机会，从而为 Kubernetes 提供成本优化。

Decisio Health 的首席 DevOps 架构师 Glen Zangirolami 说:“云会用账单把你锤死。Fairwinds Insights 的一个主要优势是资源利用和成本优化。我们能够使用 Fairwinds 的资源建议来提供我们利用率的详细信息，并对我们的解决方案进行适当定价。"

“了解我们的集群规模是正确定价我们的解决方案的重要组成部分。使用 Fairwinds Insights，我们能够正确确定每个集群的节点和数据库数量。这种理解帮助我们将每个集群的成本降低了 25%。随着 25 个以上的集群投入生产并不断增长，这一成本节约是显著的。”

Decisio 还在监控其服务使用情况，并根据 Fairwinds 的建议实施 CPU 和内存限制，以避免过度分配或资源匮乏。“这使我们的团队能够在继续加入新医院的同时，调整应用程序限制和请求。”

最后的想法

了解云支出是许多供应商关注的焦点。对在 Kubernetes 上花费的理解通常是缺乏的，或者仅仅是对已经做的事情的附加。当您使用 Kubernetes 时，从为其构建的软件中获得专家的见解可以让您的开发人员真正接受 FinOps 模型。

Gemini:自动备份 Kubernetes 中的持久卷

原文：https://www.fairwinds.com/blog/gemini-automate-backups-of-persistentvolumes-in-kubernetes

持久存储很难

当我第一次开始掌握 Kubernetes 时，我想用它做任何事情。在多年点击 AWS 控制台上的按钮后，拥有一个开源、代码驱动、独立于供应商的云平台的想法非常令人兴奋。因此，当我得知我的同事——我见过的一些最强的 Kubernetes 专家——强烈反对在 Kubernetes 中运行数据库，或将其用于任何类型的持久存储时，我感到很沮丧。他们告诉我坚持使用 S3 和 RDS 来满足我的存储需求。

当然，我没有听。虽然我们(谢天谢地)在设计生产应用程序时采纳了他们的建议，但我已经开始使用 Kubernetes 运行一些个人应用程序，比如照片共享和记笔记。我将所有数据存储在 persistent volumes(PV)上，甚至想出了一个简单的方法将数据备份到 S3。而且效果很好！

直到它没有。在某个时候，当更新我的一个应用程序时，我意外地删除了一个持久卷，却发现我的备份没有正常工作。几周的写作就这样消失了。

寻找解决方案

我没有被吓倒，开始寻找更成熟的备份解决方案。

Velero

似乎是一个社区的最爱，但更多的是重量级的灾难恢复，而不是我需要的有针对性的应用程序备份解决方案。

k8s-snapshots

相当有前途——它直接与 AWS、GCP 和 DigitalOcean APIs 集成，以创建 PVs 基础卷的备份。我让它运行了一段时间，直到我发现恢复被认为是

out-of-scope

为了项目！如果不能将备份重新连接到正在运行的应用程序，这些备份几乎毫无用处。

最后，我了解了

，一个 k8s 原生备份解决方案，从 1.17 开始进入测试版。它代表了一个巨大的进步

VolumeSnapshot API

，这是 Kubernetes 中处理持久存储的官方方法。每个主要的云供应商都提供 CSI 挂钩，允许您使用 Kubernetes-native 接口管理他们云中的卷和备份。

Container Storage Interface (CSI)

这正是我所需要的！但有一个问题:卷快照必须手动创建。最终用户需要决定如何管理他们的快照，不仅要按计划创建新快照，还要淘汰旧快照以防止它们堆积。存储可能很便宜，但是每小时备份一个 1GB 的卷会很快变得昂贵！

创造双子座

我们希望给 VolumeSnapshot API 一个更健壮、用户友好的界面。具体来说，我们认为以下功能是任何生产级备份策略所必需的:

根据可定制的细粒度计划自动备份

自动删除过时的备份
从特定备份中轻松恢复数据的能力
因此，我们决定创建一个新项目 Gemini，以便自动化持久卷的备份和恢复。Gemini 由一个新的 CRD(快照组)和一个根据快照组规范创建、删除和恢复卷快照的操作器组成。它是这样工作的。

我们从快照组定义开始，它看起来像这样:

在这里，我们告诉 Gemini 找到现有的 postgres-data PVC，并安排每 10 分钟备份一次——这可能有点过分，但安全总比后悔好。除了最新的备份，我们还告诉 Gemini 保留最近的三个备份，这样我们至少有 30 分钟的覆盖时间。

apiVersion: gemini.fairwinds.com/v1beta1
kind: SnapshotGroup
metadata:
  name: postgres-backups
spec:
  persistentVolumeClaim:
    claimName: postgres-data
  schedule:
  - every: 10 minutes
    keep: 3

但是我们可以更进一步！我们还可以告诉 Gemini 保持每小时、每天、每周、每月和每年的快照:

Gemini 仍将每 10 分钟运行一次备份，但它将保留额外的备份以满足长期备份计划。

apiVersion: gemini.fairwinds.com/v1beta1
kind: SnapshotGroup
metadata:
  name: postgres-backups
spec:
  persistentVolumeClaim:
    claimName: postgres-data
  schedule:
    - every: 10 minutes
      keep: 3
    - every: hour
      keep: 1
    - every: day
      keep: 1
    - every: week
      keep: 1
    - every: month
      keep: 1
    - every: year
      keep: 1

恢复数据

从卷快照恢复数据可能有点麻烦，因为不幸的是，不停机就不可能完成。我们需要采取以下步骤:

关闭正在使用 PVC 的任何盒

为当前状态的 PVC 创建一次性备份，以防万一
删除现有的 PVC
从所需的卷快照创建新的 PVC
重启我们的 pod，将它们指向新的 PVC
因为更换 PVC 必然会导致停机，所以我们决定不对用户隐藏这个过程。具体来说，用户负责第一步和最后一步，即缩小和备份应用程序。Gemini 负责中间部分，替换掉 PVC。

下面是基本的恢复过程。首先，我们将检查哪些快照可用:

注意时间戳，1585945609 -这是我们的目标还原点:15 分钟前。接下来，我们将缩小应用程序的规模:

$ kubectl get volumesnapshot
NAME                           AGE
postgres-backups-1585945609    15m

由于我们的应用程序处于离线状态，我们现在需要快速移动。要换出 PVC，我们只需用所需的还原点来注释快照组:

kubectl scale all --all --replicas=0

一旦 Gemini 看到此注释，它将触发一次性备份，删除旧 PVC，并使用指定快照中的数据用新 PVC(同名)替换它。恢复应该只需要 30 秒左右。与此同时，我们可以扩大规模，一旦新的 PVC 准备就绪，我们的 pod 就会上线。

kubectl annotate snapshotgroup/postgres-backups --overwrite \
  "gemini.fairwinds.com/restore=1585945609"

不幸的是，恢复数据需要一点停机时间，而且似乎没有任何合理的方法来解决这个问题。如果您对如何改进这一流程有任何想法，请通过提出问题告诉我们！

kubectl scale all --all --replicas=1

同样值得注意的是，您可以从一个备份中启动第二个 PVC，并将其附加到应用程序的一个单独实例中。我使用这种机制来恢复旧照片，而不必将我的整个照片应用程序恢复到特定的时间点。

前进

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restore-pvc
spec:
  dataSource:
    name: postgres-backups-1585945609
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

我对 VolumeSnapshot API 感到非常兴奋，因为它填补了 Kubernetes 生态系统中的一个巨大空白。当与 Gemini 结合使用时，它允许我们在 Kubernetes 中安全地维护持久存储。虽然这里仍然有一些龙(毕竟卷快照仍处于测试阶段)，但我期待有一天 Fairwinds 可以自信地推荐使用独立于供应商的 k8s 原生存储解决方案，如

和

像 S3 和 RDS 这样的服务。

MinIO PostgreSQL-HA

与此同时，我将享受边缘生活，使用 Gemini 和 VolumeSnapshots 管理我的个人数据。

In the meantime, I’ll be enjoying life on the edge, using Gemini and VolumeSnapshots to manage my personal data.

从 Kubernetes 治理平台 Fairwinds Insights(免费层)开始

原文：https://www.fairwinds.com/blog/get-started-with-fairwinds-insights-free-tier

Fairwinds Insights 是一款供 Kubernetes 平台工程师集成到内部开发人员平台的软件，该软件内置和定制的 Kubernetes 最佳实践可改进 DevEx。

它根据 Kubernetes 集群和容器的最佳实践，主动监控、识别和优先排序建议。Insights 现已免费提供，适用于多达 20 个节点、两个集群和一个存储库的环境。一些人喜欢直接进入，而另一些人喜欢提前了解预期的情况。这篇文章正是这样做的，所以请继续阅读，了解如何开始使用 Fairwinds Insights。

如果你想看看 Insights 是什么样子，请查看我们的沙盒环境。你不需要注册任何东西来体验这个平台。如果您确实建立了 Fairwinds Insights 免费层，我们将为您提供全程指导，帮助您了解下一步该做什么——就在应用程序中！

如何开始使用 Fairwinds Insights

只需七分钟，你就可以上手fair winds Insights！这是一个简单的平台，有一个简单的图形用户界面(GUI ),对于平台工程师、开发人员和其他 Kubernetes 用户来说，很容易导航和直观。

您可以使用自己的集群或设置一个测试集群来开始自己的工作。在下面的示例中，我们设置了一个测试 GKE 集群。

第一步:注册账户

第一步是注册 Fairwinds Insights。这用不了一分钟。只需访问注册页面，输入您的电子邮件地址，并创建(并确认)一个安全密码。你还需要输入验证码。

在下一页，只需输入您的姓名，并告诉我们您是如何听说 Fairwinds Insights 的。单击下一步，几分钟后(可能更短)，您将收到一封确认您的电子邮件地址的电子邮件。

You've created a Fairwinds Insights account - confirm email address

第二步:创建一个新的组织

这一步也不到一分钟。您可以请求组织所有者将您添加为组织成员，或者您可以创建一个新组织。让我们假设您正在创建一个新的组织。您可以输入您的公司名称或创建一个测试帐户。( 注意: 你不能在以后更改你的组织名称，所以选择一个你将来会乐意使用的名称)。您的组织名称全部是小写字母，没有空格，但是您可以使用数字和破折号来分隔单词。然后单击“创建组织”进入下一步。

New organization page - create organization

第三步:创建一个集群

接下来，您需要添加一个新的集群。这也很快！添加群集后，您可以选择要为该群集安装的报告。默认情况下，您将从北极星、新星、OPA 和冥王星开始。

Add a new cluster page - create cluster

第四步:用舵安装

是时候安装代理了！我们在下面的截图中建议了一些值。这些建议基于 Kubernetes 的最佳实践，我们认为它们会让你的生活更轻松。您可以稍后定制这个 yaml 文件，以包含更多的报告，这些报告可以在安装中心获得。在 Insights 平台中，很容易将这些代码复制并粘贴到您喜欢的编辑器中，然后保存。

yaml file of best practice values

接下来，用这些值安装舵图(复制/粘贴也很简单):

helm chart install

不使用头盔？下面是安装舵的指南。

第 5 步:查看 Fairwinds Insights 集群概述

安装 Insights 代理后，屏幕将刷新并重定向至集群概述。根据集群的大小，只需要几分钟就可以开始看到您的报告。

Cluster Overview page - Evaluate your findings

集群概述突出显示了集群中运行的报告所确定的操作项，以及这些操作项如何影响集群的整体运行状况。您可以快速查看您的健康得分以及您有多少个严重和高警报。从集群概览中选择行动项目，您将进入行动项目导航中的过滤视图。

行动项目

单击行动项目查看集群中发现的问题。在页面顶部，您可以按集群进行筛选，并按名称空间和工作负载中的严重性和频率查看操作项的分布。

Action items in Fairwinds Insights

Insights 允许您搜索行动项目，按标题、严重性(低、中、高、关键)、类别(效率、可靠性、安全性)、集群、名称、命名空间和容器进行过滤。

补救行动项目

查找要修复的操作项。只需点击问题，即可查看问题描述以及如何补救的信息。

Action items - description of problem and remediation advice

如果您单击类别旁边的三个点(在本例中，这是一个安全问题)，您可以访问一个菜单，该菜单允许您:

创建票证 (Insights 有集成与 Slack、Datadog、PagerDuty、吉拉和 Azure devo PS——你需要点击管理集成设置来安装它们并创建票证)
解决问题(无，按预期工作，不会修复)
贪睡动作项(1 天、1 周、1 个月)
将分配给一个团队成员(如果你是一个更大组织的一部分，你会在这个列表中看到你的团队成员)
见类似物品

如果您需要更多操作项，请转到顶部导航栏中的“安装集线器”并添加更多检查。

安装轮毂

准备就绪后，您可以返回到集群导航内的安装中心添加附加报告，如使用指标和容器漏洞的识别。只需使用图块在 Insights Agent 中添加或删除报告。您还可以通过单击一个单幅图块来更改报告的配置。选择要使用的报告后，单击页面右上角的“准备安装”。您将获得一个 Helm 命令来使用您的新设置安装代理。

Fairwinds Insights Install Hube displaying available reports to install

一些可用的报告包括:

繁琐——扫描你的容器中已知的漏洞
RBAC 记者——跟踪角色和绑定
【Kube】-猎人 -搜寻你的集群内部的安全弱点
普罗米修斯 收集器 -收集指标以提供更准确的成本估算
AWS 成本 -从您的 AWS 成本和使用报告中摄取计费信息

通知集成

通过分享他们已经使用的工具中的问题，授权团队采取行动。访问设置，探索与供应商的可用集成，如【吉拉。

通过 IaC 扫描更快发现问题

通过将 Fairwinds Insights 与持续集成平台连接，您可以使用 fair winds Insights扫描您的基础架构即代码库。在“存储库”选项卡中有两种方法可以做到这一点

连接 GitHub——这是最简单的入门方式。授予 Insights 对特定存储库的访问权限，我们将自动扫描每个新的拉取请求并提交。
手动连接——您需要向现有 CI/CD 管道添加脚本。如果你没有使用 GitHub，我们推荐这种方法。

与你的团队分享发现

在设置>团队管理下管理您的团队。您可以在 Fairwinds Insights 中邀请用户加入您的新组织，将他们分配到一个团队，分配一个角色，并选中复选框以指明他们是否拥有所有者访问权限(添加新用户、管理团队和删除组织的访问权限)。他们将收到一封电子邮件，邀请他们完成前面部分概述的相同用户注册过程，但他们将成为您组织的一部分。

您还可以创建一个新团队，并配置团队对集群、名称空间和存储库的访问。或者，您可以阻止对特定集群、名称空间和存储库的访问。设置好并点击创建团队。

试用 Fairwinds Insights

这些是开始使用 Fairwinds Insights Free Tier 的基本第一步！使用 Fairwinds Insights，您可以发现许多关于您的 Kubernetes 集群和工作区的信息，所以请尝试不同的功能。发现漏洞，提高效率，并查看合规性报告。

如果遇到困难或有疑问，请告诉我们。并查看 Fairwinds 社区 Slack group ，在这里您可以向我们的团队和社区提出问题并获得答案。我们期待着帮助您安装护栏，并使 Kubernetes 治理成为您团队的现实。

Kubernetes 入门:架构基础和定义

原文：https://www.fairwinds.com/blog/getting-started-with-kubernetes-architecture-basics-definitions

本系列面向刚接触库伯内特和 GKE 的工程师。它提供了 Kubernetes 的基本概述、定义以及在 GKE 构建 Kubernetes 集群 和您的第一个 多层 webapp 的快速入门。如果您正在寻找更深入的帮助，请联系。

Kubernetes 入门需要一些基础的架构理解。在这里，我们总结了主节点和工作节点、Kubernetes 架构以及 pod、标签、选择器、部署和服务的定义。

主节点和工作节点

有两种主要类型的机器——主机和工作机——都被称为节点。大多数情况下，当有人提到一个节点时，他们谈论的是一个工作者节点。

主节点做一些事情:

服务 Kubernetes API——无论何时你发出一个 kubectl 命令，你都是在直接和其中一个主人对话。Masters 通常以三个为一组运行，因此如果您丢失一个，您不会有停机时间。
管理调度工作负载——Kubernetes 提供了一种声明式的方法，将工作提交给 API，以便在 worker 节点上进行调度。主节点通过寻找具有足够资源的工作节点来处理这种调度，并告知工作是否可以被调度。
保持工人的状态 -当工作被提交并且可以被调度或不被调度时，该“状态”由主保持。

请注意，如果您使用的是 GKE、EKS、AKS 或其他托管的 Kubernetes 服务，您就不需要担心运行主节点。

你可能也听说过 Kubernetes 的“控制飞机”。这包括主节点，以及运行在 worker 节点上的 kubelet 进程。控制平面:

维护系统中所有 Kubernetes 对象的记录
运行连续的控制循环来管理那些对象的状态。
在任何给定的时间，控制平面的控制回路将响应集群中的变化，并努力使系统中所有对象的实际状态与您提供的期望状态相匹配。

工作节点是完成“工作”的地方，也是你所有应用的所在地。工人:

运行主人安排的工作
可以被分组为子组——您可能想要运行许多不同种类的具有不同资源需求的工作负载。您可以创建具有不同资源配置文件的节点池来满足这些需求。
具有可读的属性，您可以通过 API 访问这些属性——您可能想要在具有特定操作系统或云实例类型的节点上调度工作。您可以从 API 中读取以下信息:
操作系统发行版和版本
资源分配
地区

简化的 Kubernetes 架构示例

来源:数据狗

在中间，你可以看到 Kubernetes 的标志。这表示控制平面。如果您使用的是像 GKE 这样的托管服务，则该控制平面由该服务管理。

API 在控制平面中运行。当发出一个 kubectl 命令时，这就是您将与之对话的内容。当工作负载提交给 API 时，API 将在不同的工作节点上对它们进行调度。

该图还显示了节点 A 和节点 b。每个工作节点都运行一个 kubelet，这是一个守护进程，它与主节点交流可用资源的数量、哪些工作处于挂起状态，以及工作是否可以调度到它所管理的节点。

然后有一些圆荚体的表现。pod 是在节点上调度的一组 Docker 容器。

在节点 A 上，我们有两个不同的单元。在第一个 pod 中，有三个不同的容器。第二个舱里有一个集装箱。
在节点 B 上，我们有一个带有两个容器的 pod。

所有工作都作为这些容器分组或 pod 提交给 Kubernetes API。为了增加弹性，Kubernetes 可以在不同的节点上分发相同 pod 规范的多个副本，因此即使其中一个崩溃，您也有一个备份。

立方定义

当您开始使用 Kubernetes API 时，了解以下词汇和概念是很重要的。

Kubernetes 被组织成一系列对象，用于典型的 CRUD 操作，即通过 API 创建、读取、更新和删除。

Kubernetes 声明由一系列相互关联的对象组成
API 通过对这些对象进行更高级别的抽象来提供额外的功能
对象的声明存储为 YAML 并提交给 API
这些 YAML 文件通常被签入 Git 存储库以进行版本控制

Kubernetes 豆荚

pod 是在作为一个单元的同一物理或虚拟机上调度的一个或多个容器的集合。当您创建 pod 的声明时，您可以用位于 pod 内部的任意数量的容器来定义它。

pod 还在内部共享一个网络——每当在 pod 内的所有容器之间调度一个 pod 时，就共享一个私有网络。他们还可以共享文件系统卷。与 Docker 使用- volumes-from 类似，当在一个 pod 中运行多个容器时，这与 Kubernetes 的概念相同。您可以在 pod 内共享临时或写入时复制样式的存储。

通常，您不会直接创建一个 pod——相反，您将创建一个更高级别的对象，如包含 pod 规范的 Deployment 或 StatefulSet(见下文)。

Kubernetes 部署

部署是对 pod 的抽象。它允许您在 pod 上拥有额外的功能和控制，以说明您希望跨节点运行多少个 pod 实例，或者您是否希望定义滚动更新策略(例如，一次仅滚动一个 pod，中间等待 30 秒)。这使您能够根据自己的需求控制部署，以便在启用新流程和淘汰旧流程时实现零停机。

部署提供以下功能:

提供更高级别的 pod 抽象(定义一组相同的 pod)
可以扩展 pod 的副本以满足需求
负责创建、更新和删除窗格
可以向前或向后滚动

在这里，您可以看到这个部署称为“webapp”。它希望存在两个副本。

它使用标签选择器(设置为“app: webapp”)来查找和管理由其生成的 pod。在它的下面，你可以看到它将产生的豆荚的缩写模板，它将有标签。

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
        - name: webapp
          image: nginx
          ports:
          - containerPort: 8080
            name: http
          env:
          - name: REDIS_HOST
            value: 'redis-master'

不变标签

每个 Kubernetes 对象都为您提供了通过标签附加元数据的机会——一系列附加到对象上的任意键值对。通常，这些是对用户进行声明有意义的标识属性。

标签本质上并不意味着核心系统的语义。这意味着，对于 Kubernetes 系统来说，没有什么功能是你可以从标签中明确获得的。相反，它们被 DevOps 团队用来查询特定的对象集。

标签非常重要，因为它们可以用来编排、附加和识别 Kubernetes 系统中的不同对象。标签可以通过创建或更新操作附着到对象。您可以在创建 pod 时附加标签，也可以将标签应用于已经在更新过程中运行的 pod。

我们期望许多对象具有相同的标签，因为标签不是唯一的。例如，您可能希望将所有与网站前端相关的资源标记为 app=frontend，而所有后端资源都标记为 app=backend。或者你希望它们都是 app = website——你使用标签的方式完全取决于你。

以下是 Kubernetes YAML 定义上下文中的标签片段:

apiVersion: v1
kind: Pod
(...)
metadata:
  labels:
    app: backend
    tier: primary
    release: staging

您可以将标签指定为您想要的任何东西，具有对您有意义的任何种类的语义，因为这些是您的，能够在 Kubernetes 系统中编排不同的事情。

Kubernetes Selectors

选择器使您能够获取 Kubernetes 对象，并将它们与已经应用了标签的不同对象相关联。选择器通过过滤来识别一组对象。被识别和过滤的对象集合具有相关的标签。

空选择器将匹配所有标签。在本例中，部署将应用于标签为“app:redis”的 pod。

kind: Deployment
metadata:
  name: webapp
Spec:
  replicas: 2
  selector:
    matchLabels:
      app: redis
  template:
    spec:
      containers:
  (...)

不间断服务

在容器和元数据的上下文之外，服务是 Kubernetes 的关键。服务是一种网络结构，它定义了访问 pod 的一致方式。如果您向 Kubernetes API 提交一个部署，并且该部署旋转了 web 服务的五个不同的 pods，那么您将需要一种方法将 HTTP 流量路由到这些 pods，使用负载平衡方法，例如循环调度。您将使用一个服务来完成这项工作。

服务:

配置对 pod 的 HTTP 访问
pod 之间的负载平衡流量
可以创建外部云资源，如负载平衡器

服务找到一个 pod 来路由流量:

在集群中，它们提供了 pod 之间的负载平衡
还可以创建外部云资源，例如云负载平衡器

这是一个服务的 YAML 定义的例子。我们有一个名为 webapp 的元数据部分。在第 15 行我们有一个选择器。选择器是 app 的一个键，值为 webapp。这意味着你运行的每一个带有 app 标签和 webapp 价值的 pod 都是相关的。任何访问此服务的流量都将被路由到与该标签匹配的 pod。如果您有五个相关的 pod，但其中一个崩溃，该服务将知道该 pod 不再健康，因此只将流量路由到其余四个，直到另一个 pod 出现。

apiVersion: v1
kind: Service
metadata:
  name: webapp
  labels:
    app: webapp
spec: 
   type: LoadBalancer
   ports:
     - name: http
       protocol: TCP
       port: 80
       targetPort: http
    selector: 
      app: webapp

这同样适用于水平自动缩放。例如，如果您有 10 个资源受限的 pods 在运行，Kubernetes 可以增加 5 个标签相同的 pods 来处理负载。服务有责任了解现在有 15 个 pod，流量必须相应地分配。

在集群中，服务提供了一种在 pod 之间实现负载平衡的方法。服务还可以与外部云提供商对话，并旋转云资源，如云负载平衡器，如应用程序负载平衡器(ALB)、弹性负载平衡器(elb)。这就是 Kubernetes 真正是云原生的原因:系统内置了许多功能，能够与您可能正在工作的任何云提供商集成。

有四种类型的服务。

1。ClusterIP:在内部 IP 上公开服务

这通常用于仅由集群中运行的其他工作负载访问的服务。Redis 就是一个很好的例子。您可能不希望您的 redis 数据存储可以通过公共互联网进行读/写访问。您可以为 Kubernetes 集群中运行的 redis 实现分配一个 ClusterIP 服务，这样它只能被集群中的其他工作负载访问。

2。NodePort:在一个静态端口 上公开每个工作节点 IP 上的服务

假设您有一个在五节点集群中的三台机器上运行的部署。如果您为此分配一个节点端口服务，它将直接在这些虚拟机上静态映射一个端口，并且可以从 IP(不是分配给 pod，而是分配给运行它们的实际节点的 IP)进行访问。

如果您正在运行 daemonsets，并且您有需要可用的监视系统的日志聚合器，这将非常有用。

小心端口冲突或 pod 重新安排。

3。负载平衡器:使用云提供商的负载平衡器对外公开服务

负载平衡器服务使用云提供商的负载平衡器对外公开服务。GCP 提供云负载平衡器，AWS 提供 ALB 和 elb。在您的服务定义中，您可以请求一个负载平衡器类型，它将为您启动一个 ELB 来处理幕后的所有网络。请注意，这可能会导致您的云提供商支付额外费用。

4。ExternalName:通过返回 CNAME 记录的 DNS 提供者将服务映射到外部名称

类似于负载平衡器，尽管 ExternalName 直接与 DNS 提供商交互。

现在有了这样的理解，我们将向您展示如何在 GKE 建立您的第一个 Kubernetes 集群。

Terraform 和 AKS 入门:部署第一个集群的分步指南

原文：https://www.fairwinds.com/blog/getting-started-with-terraform-and-aks-a-step-by-step-guide-to-deploying-your-first-cluster

我们是使用基础设施作为代码来管理 Kubernetes 的主要倡导者。Terraform 是我们管理 Kubernetes 基础设施整个生命周期的首选工具。你可以在这里阅读关于 Terraform 的好处。

这篇博客提供了一个分步指南，介绍如何通过部署第一个以基础设施为代码的集群来开始使用 Terraform 和 AKS。

先决条件

如果您想在 Terraform 中创建自己的 AKS 集群，请遵循以下步骤。

创建 Azure 帐户并登录(有一个免费层)。
创建订阅-确认订阅具有所有者权限

AKS screenshot

步骤

为项目创建一个类似 terraform-aks. 的目录接下来，用这个命令在目录中设置一个 ssh 密钥对: ssh-keygen -t rsa -f ./aks-key. 然后，从命令行运行az login登录到你的 Azure 账户。

我们现在将设置几个 Terraform 文件来包含各种资源配置。第一个文件将被命名为 provider.tf. 创建文件并添加这几行代码:

provider "azurerm" {
  version = "~> 2.5.0"
  features {}
}

provider "azuread" {
  version = "0.9.0"
}

现在，创建一个名为 cluster.tf. 的文件，这将包括我们的虚拟网络、集群和节点池模块。现在我们可以添加一个资源组，这是 Azure 创建资源所需要的。

## Create a resource group to place resources
resource "azurerm_resource_group" "aks" {
  name     = "myakscluster"
  location = "centralus"
}

这段代码将为您的 AKS 集群设置网络，并将其添加到 cluster.tf 中。

## Create the virtual network for an AKS cluster
module "network" {
  source              = "git@github.com:FairwindsOps/azure-terraform-modules.git//virtual_network?ref=virtual_network-v0.6.0"
  region              = "centralus"
  resource_group_name = azurerm_resource_group.aks.name
  name                = "myakscluster"
  network_cidr_prefix = "10.64.0.0"
  network_cidr_suffix = 10
  subnets = [{
    name       = "aks-subnet"
    cidr_block = 16
  }]
}

您会注意到在 source 字段中， network 模块正从我们的 git repo:git @ github . com:FairwindsOps/azure-terraform-modules . git//virtual _ network 中拉出。

如果你浏览那个回购，在 aks_cluster 目录下，你会注意到 aad.tf 文件。这个模块支持 Azure Active Directory 集成，但是我们不会在这里使用它。您还可以看到该模块正在创建的所有其他资源。接下来，将这段代码添加到 AKS 集群本身的 cluster.tf 文件中:

## Create the AKS cluster
module "cluster" {
  source              = "git@github.com:FairwindsOps/azure-terraform-modules.git//aks_cluster?ref=aks_cluster-v0.8.0"
  region              = "centralus"
  cluster_name        = "myakscluster"
  kubernetes_version  = "1.16.10"
  resource_group_name = azurerm_resource_group.aks.name
  node_subnet_id      = module.network.subnet_ids[0] # use the subnet from the module above
  network_plugin      = "azure"
  network_policy      = "calico"
  public_ssh_key_path = "aks-key.pub"
}

注意:这里使用的是 Kubernetes 1.16.10。您可能需要查看 AKS 发行说明，以确认最新支持的版本。

您会注意到某些值，如module.network.subnet_ids[``0``],是从 network 模块中引用的。Terraform 的这一特性使您能够在模块或资源上设置值，并在其他模块或资源上使用它们。最后，将这段代码添加到 cluster.tf 中，以设置包含 AKS 工作节点的节点池:

## Create the node pool
module "node_pool" {
  source         = "git@github.com:FairwindsOps/azure-terraform-modules.git//aks_node_pool?ref=aks_node_pool-v0.4.0"
  name           = "myakspool"
  kubernetes_version  = "1.16.10"
  aks_cluster_id = module.cluster.id
  node_subnet_id = module.network.subnet_ids[0]
}

注意:这里使用的是 Kubernetes 1.16.10。您可能需要查看 AKS 发行说明，以确认最新支持的版本。

就是这样！你的地形文件已经准备好了。

下一步是通过运行 terraform init. 初始化 Terraform，Terraform 会生成一个名为 .terraform 的目录，并下载 cluster.tf. 中声明的各个模块源码

初始化将拉入这些模块所需的任何提供程序，在本例中，它将下载 google 提供程序。如果配置的话，Terraform 还会配置 backend 用于存储状态文件。

terraform init
Initializing modules...
Downloading git@github.com:FairwindsOps/azure-terraform-modules.git for cluster...
- cluster in .terraform/modules/cluster/aks_cluster
Downloading git@github.com:FairwindsOps/azure-terraform-modules.git for network...
- network in .terraform/modules/network/virtual_network
Downloading git@github.com:hashicorp/terraform-cidr-subnets.git?ref=v1.0.0 for network.subnet_addrs...
- network.subnet_addrs in .terraform/modules/network.subnet_addrs
Downloading git@github.com:FairwindsOps/azure-terraform-modules.git for node_pool...
- node_pool in .terraform/modules/node_pool/aks_node_pool

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "azurerm" (hashicorp/azurerm) 2.5.0...
- Downloading plugin for provider "azuread" (hashicorp/azuread) 0.9.0...
- Downloading plugin for provider "kubernetes" (hashicorp/kubernetes) 1.11.3...
- Downloading plugin for provider "null" (hashicorp/null) 2.1.2...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.kubernetes: version = "~> 1.11"
* provider.null: version = "~> 2.1"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

成功初始化 Terraform 后，您应该能够运行 terraform plan. 在允许 Terraform 进行任何更改之前，运行 terraform plan 并检查输出总是一个好主意。

terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

module.cluster.data.azurerm_subscription.current: Refreshing state...

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # azurerm_resource_group.aks will be created
  + resource "azurerm_resource_group" "aks" {
      + id       = (known after apply)
      + location = "centralus"
      + name     = "myakscluster"
    }

  # module.cluster.azurerm_kubernetes_cluster.cluster will be created
  + resource "azurerm_kubernetes_cluster" "cluster" {
      + dns_prefix            = "myakscluster"
      + fqdn                  = (known after apply)
      + id                    = (known after apply)
      + kube_admin_config     = (known after apply)
      + kube_admin_config_raw = (sensitive value)
      + kube_config           = (known after apply)
      + kube_config_raw       = (sensitive value)
      + kubernetes_version    = "1.16.9"
      + location              = "centralus"
      + name                  = "myakscluster"
      + node_resource_group   = (known after apply)
      + private_fqdn          = (known after apply)
      + resource_group_name   = "myakscluster"
      + tags                  = {
          + "cluster-name"  = "myakscluster"
          + "created-by"    = "Terraform"
          + "module-source" = "github.com/FairwindsOps/azure-terraform-modules/aks_cluster"
        }

      + addon_profile {
          + aci_connector_linux {
              + enabled = false
            }

          + azure_policy {
              + enabled = false
            }

          + http_application_routing {
              + enabled                            = false
              + http_application_routing_zone_name = (known after apply)
            }

          + kube_dashboard {
              + enabled = false
            }
        }

      + default_node_pool {
          + availability_zones    = [
              + "1",
              + "2",
              + "3",
            ]
          + enable_auto_scaling   = true
          + enable_node_public_ip = false
          + max_count             = 10
          + max_pods              = 110
          + min_count             = 1
          + name                  = "default"
          + node_count            = 1
          + os_disk_size_gb       = 50
          + type                  = "VirtualMachineScaleSets"
          + vm_size               = "Standard_D2_v2"
          + vnet_subnet_id        = (known after apply)
        }
...
Plan: 4 to add, 0 to change, 0 to destroy.

请注意，这段摘录已经过编辑，以缩减本文的篇幅。

如上例所示，Terraform 将采取行动添加我们的 4 AKS 资源。应用时，Terraform 将创建我们的网络、子网(用于 pod 和服务)、AKS 集群和节点池。

计划通过验证后，通过运行 terraform apply. 进行最后一个验证步骤来应用更改，Terraform 将再次输出计划并在应用前提示确认。完成此步骤大约需要 10 分钟。要与集群进行交互，请在终端中运行此命令。

az aks get-credentials --resource-group myakscluster --name myakscluster --admin

然后，您应该能够 kubectl get nodes ，您将看到您的集群中有两个工作节点！

kubectl get nodes
NAME                                STATUS   ROLES   AGE     VERSION
aks-default-14693408-vmss000000     Ready    agent   8m24s   v1.16.9
aks-myakspool-14693408-vmss000000   Ready    agent   4m31s   v1.16.9

恭喜您，您已经使用 Terraform 成功部署了 Kubernetes AKS 集群！您现在可以开始将您的应用程序部署到 Kubernetes 了！

资源

GitHub Kubernetes 最佳实践徽章是什么意思？

原文：https://www.fairwinds.com/blog/github-kubernetes-best-practices-badge

如果你在 GitHub 领域呆过一段时间，你会对开源项目的各种徽章很熟悉。徽章的存在是为了证明第三方对回购部分质量的验证。我经常看到的包括“Go Report”徽章或 CircleCI 测试通过徽章，它们看起来像这样:

go report A+ PASSED

这些标记的存在给用户一些信心，让他们相信回购中的代码符合公认的标准。这些徽章对贡献者来说很重要，因为它让你感到自信，你正在发布你可以引以为豪的代码。作为一个开源工具的用户，这可能对你也很重要；它提供了一定程度的信心，即该工具已经以某种方式进行了审查，并且没有充满漏洞，或者至少您知道它正在运行或者与某个东西的最新版本兼容(具体兼容什么取决于徽章和开源工具或项目)。

同样，今天我们公开宣布 Kubernetes 最佳实践徽章的可用性，该徽章将应用于包含旨在部署到 Kubernetes 集群中的代码的项目。这可能与您的开源项目的一小部分相关，也可能与整个项目相关。

例如，我们已经将徽章应用于 Fairwinds GitHub repo 中的相关 Kubernetes 开源工具。看起来是这样的:

K8s Best Practices - No issues found

在后端进行验证的工具是fair winds Insights，这是我们用于 Kubernetes 安全性和配置验证的商业工具。当有人点击该徽章时，会将他们带入一个类似这样的 Fairwinds 仪表盘:

Screenshot of FairwindsOps/polaris

通过将 K8s 最佳实践徽章应用到您的开源项目，您向您的用户展示了您的项目已经通过了许多可能领域的最佳实践检查，从已知的常见漏洞和暴露(CVE)到常见的安全错误配置。绝大多数安全问题仍然是错误配置的结果，如果您的项目打算部署到 Kubernetes 集群中，那么您可以对它进行这些检查，并对它进行改进，直到您可以用洞察力来验证它，从而让您的用户放心。

虽然 Fairwinds Insights 是一个用于扫描 Kubernetes 集群和基础设施代码的商业工具，但我们将它永久免费提供给开源项目。我们创建了这个徽章和它背后的工具，因为我们是 Kubernetes 和围绕它的开源技术社区的忠实拥护者。我们基于我们管理数千个集群的经验构建了 Fairwinds 本身和 Insights，创建了许多属于 Insights 的开源工具。例如，Polaris 会进行各种检查，以确保 pod 和控制器的配置符合 Kubernetes 的最佳实践。

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

如果你想知道如何获得我们的徽章，去看看我们的北极星项目上的例子，设置集成，并让我们知道你正在为一个开源项目使用它。当我们收到您的消息时，我们会确保您的许可证将永久免费。

GitOps 最佳实践和您需要遵循的 Kubernetes 护栏

原文：https://www.fairwinds.com/blog/gitops-best-practices-and-the-kubernetes-guardrails-you-need

GitOps 是一个大家都在谈论的流行语，这个词是由 Weaveworks 在 2017 年创造的。它通过拉请求方法使用操作来定义和管理网络、基础设施、应用程序代码和 GitOps 管道。GitOps 是一种管理由 Kubernetes 支持的云原生系统的方法。

什么是 GitOps

Weaveworks 有很多很酷的开源工具，并且已经在 Kubernetes 领域存在了一段时间。根据 Weaveworks 网站上的一个故事，那里的团队投入了大量精力来改善他们的 Kubernetes 运营，方法是创建不同的中转区，设置多个可靠性区域，并创建内置监控和安全性。在 2016 年的某个时候，一名工程师告诉团队，他正在推出一项可能会消除一切的变革。确实如此。但是因为他们拥有 Git 配置文件中描述的一切，所以他们能够在不到 45 分钟的时间内恢复他们的系统。

大量工作投入到构建他们的系统中，以使其能够如此快速地恢复，这使他们能够确定使快速恢复成为可能的因素。就在那时，他们提出了 GitOps 的概念。在开源分布式版本控制系统 Git 中，他们列出了操作他们的 Kubernetes 系统需要遵循的原则——该系统基于系统外部存在的系统模型，使整个系统的操作自动化。

GitOps 在 2018 年被全行业采用，2020 年 11 月，亚马逊、Codefresh、GitHub、微软和 Weaveworks 创建了 GitOps 工作组，该工作组现在是一个开放 CNCF 社区项目。这个小组的目标是定义什么是 GitOps，并使它与供应商无关。

GitOps 的四个主要原则

【GitOps】是陈述性的， 意思是强调事实而不是说明。就像 Kubernetes 一样，你告诉它应该是什么，而不是怎么做。
GitOps 使用 Git 作为真理源 并且 Git 真理源是版本化的和不可变的。这是 GitOps 的好处之一。
GitOps 专注于自动拉取机制。 在我们的标准流程中，您在您的 CI 管道中完成所有的构建和测试；在这里，您可以使用命令将所有内容推送到您的集群。GitOps 的哲学是，你的集群应该是拉动那些变化本身，你不应该去推动它。
你的集群不断被调和 。它利用控制循环来关注事情应该如何发展，并使您的集群保持这种状态，这很像 Kubernetes 本身的内部结构，它完全是关于监视事情状态与您希望事情发展的方式的控制器。

在 Fairwinds，我们在内部使用 GitOps 来管理基础设施的附加组件，如 cert-manager、ingress-nginx 和 external-dns。我们使用 ArgoCD ，这是市面上少数几种不同的 GitOps 工具之一。您在集群中部署 ArgoCD，并将其配置为监视特定的 repo，然后将该 repo 中的内容与特定的一个或多个集群进行协调。它监视集群，然后协调集群以保持这种状态，这在 Git 中。

支持 GitOps 的工具

计算者

Fairwinds 构建和使用的一个开源工具是【计算器】，这是一个命令行助手，用于Helm创建一个声明性语法来管理单个位置的多个发布，并允许从 git 提交/分支/发布安装图表。

清算者允许你在一个 YAML 文件中声明一大堆头盔释放。每个版本都是一个舵图，以及相应的值。在 YAML 文件中，你也可以告诉计算者生成一个 ArgoCD 应用程序清单。ArgoCD 应用程序中可用的大多数选项，如 autosync，在 Reckoner 中也可用。

然后，Reckoner 在 manifest 目录中创建一个文件夹结构，每个应用程序有一个文件夹，还有一个包含所有 ArgoCD 应用程序的文件夹。然后，您可以创建一个应用程序的应用程序，指向该文件夹并同步应用程序。因此，您唯一需要手动管理的是定义您的应用程序的单个 ArgoCD 应用程序清单。

当您创建一个新的应用程序时，它会同步到 ArgoCD 中，然后继续同步该应用程序。模板化到每个文件夹中的清单是应该应用到集群的声明性状态，因此当您对其进行更改时，您可以在 Git pull/merge 请求中看到更改。通过模板化这些清单，您可以在更改进入集群之前获得将要发生的完全不同的确切更改。这种增加的透明度为您提供了您需要的所有信息，而不是您必须在舵图或 ArgoCD 舵应用程序中搜索的更有限的信息。

清单还允许您对 CI/CD 系统中的 YAML 进行静态分析和运行 CI/CD 检查。您还应该创建一个检查来验证计算器模板是否被正确执行。它验证没有 Git 更改，也没有手动修改 YAML。这支持 GitOps 原则，即确保只有一个源，其中没有未跟踪的更改。

立方结构改革

您还需要运行一个kube conform来检查您的模板化清单，因为虽然 Helm 图表可能会产生一些 YAML，但 YAML 可能没有根据 Kubernetes 的模式进行验证。Helm 不会在 Helm 模板上这样做，因为它无权访问集群。Kubeconform 是一个 Kubernetes 清单验证器；它获取所有清单，并根据 Kubernetes 存储库中的模式对它们进行验证。kubeconform 可以做的另一件事是创建一个 JUnit 文件，您可以将它发送到您的 CI/CD 系统，让它显示您的每个单独测试的结果。

北极星

采用 GitOps 时，重要的是将正确的护栏放置到位，并遵循 Kubernetes 的最佳实践，以确保您构建的安全性和稳定性。北极星帮你做到。这是另一个可以在 CI/CD 中运行的 Fairwinds 开源工具。它检查 Kubernetes 最佳实践，特别是与安全性、效率和可靠性相关的最佳实践。Polaris 包括 30 多种内置配置策略，并将验证它们，甚至修复 Kubernetes 资源，以确保遵循配置最佳实践。Polaris 检查整个存储库和清单集的配置问题，这有助于您与 GitOps 最佳实践保持一致。

费尔温德见解

您可以使用fair winds Insights获得完整的存储库报告，该报告将在一个地方向您显示清单目录中发现的所有问题，而不是为每个工具编写单独的检查。它包括:

一份琐碎的报告，显示其发现:漏洞、错误配置、秘密、容器中的软件材料清单、Kubernetes、代码库、云等等。
一份显示配置问题的报告。
APluto关于代码仓库和 Helm 版本中弃用的 Kubernetes API 版本的报告。
AnOpen Policy Agent(OPA)报告，这样您就可以通过减压阀应用您自己的策略，将它们应用到您的 YAML，并将其添加到您的支票中。

您可以打开“自动扫描细节”来自动查看这些报告，并根据调查结果创建票据。您还可以使用吉拉集成为发现创建标签，并将它们分配给需要修复它们的团队。Fairwinds Insights 为多达 20 个节点、两个群集和一个存储库的环境提供了一个免费层。

GitOps +立方结构护栏

通过遵循这些 GitOps 最佳实践，并使用工具来符合 Kubernetes 最佳实践并实现 guardrails，您可以确保您的 GitOps 流程是安全的、可靠的和可维护的。这将帮助您保持 Kubernetes 环境按预期运行，同时确保所做的任何更改都是有效的，不会导致意外问题。

观看网络研讨会，更好地了解 GitOps 如何工作，以及这些开源工具如何帮助您实现符合 GitOps 最佳实践的 Kubernetes 护栏。

什么是金发女孩？(或者如何设置您的 Kubernetes 资源请求)

原文：https://www.fairwinds.com/blog/goldilocks-kubernetes-resource-requests

当我们在 2019 年 10 月开源 Goldilocks 时，我们的目标是提供一个仪表板实用程序，帮助您确定设置 Kubernetes 资源请求和限制的基线。我们将继续完善 Goldilocks ，因为让资源请求和限制恰到好处对大多数组织来说都是一个持续的挑战。

为什么要设置资源配置？

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

正确处理 Kubernetes 资源请求

我们在推荐模式下使用 Kubernetes 垂直窗格自动缩放器 (VPA)来查看我们每个应用程序上的资源请求建议。Goldilocks 为名称空间中的每个部署创建一个 VPA，然后向它们查询信息。虽然 VPA 可以设置资源请求，但 Goldilocks 中的仪表板可以方便地查看所有建议，并根据您对 Kubernetes 环境的了解做出决策。learnk8s.io 上有一个关于在 Kubernetes 中设置正确的要求和限制的好帖子，有很多代码、细节和有趣的类比。

一旦您的 VPA 就绪，Goldilocks 仪表盘中的建议如下所示:

金发女孩如何产生推荐？

Goldilocks 使用 VPA 中的推荐器进行推荐。根据 VPA 的文献:

“启动二进制文件后，recommender 会将运行 pod 的历史记录及其使用情况从 Prometheus 读入模型。然后，它循环运行，并在每一步执行以下操作:

- 使用资源的最新信息更新模型(使用基于观察的列表器)，
- 使用来自 Metrics API 的新使用示例更新模型，
- 为每个 VPA 计算新推荐，
- 将任何更改的建议放入 VPA 资源中。"

Goldilocks 生成的建议基于 pod 在一段时间内的历史使用情况，因此您的决策不仅仅是基于一个时间点。

Goldilocks 在仪表板中显示了两种类型的建议。这些建议基于 Kubernetes 服务质量(QoS)等级。QoS 类别是 Kubernetes 的一个概念，它决定了 pods 被调度和驱逐的顺序，Kubernetes 自己将 QoS 类别分配给 pods。有三种类型的 QoS 类别:保证、突发和尽力而为。具有相同 CPU 和内存限制和请求的 pod 被放入有保证的 QoS 类别。CPU 或内存请求低于其限制的 pod 被赋予突发 QoS 类别。BestEffort QoS 类别适用于由没有任何请求或限制的容器组成的 pod。(我们完全不建议这样做。)

使用 Goldilocks，我们从历史数据中生成两种不同的 QoS 类别的建议:

对于保证的，我们从建议中提取目标字段，并将其设置为该容器的请求和限制。这保证了容器请求的资源在被调度时可用，并且通常产生最稳定的 Kubernetes 集群。
对于 Burstable ，我们将请求设置为 VPA 对象的下限，将限制设置为上限。调度器使用请求将 pod 放在一个节点上，但是它允许 pod 在被终止或限制之前使用更多的资源，直到达到限制。这有助于处理峰值工作负载，但如果使用过多，会很快导致节点过度配置，使其不堪重负。

金发女孩有多准确？

金凤花开源软件完全基于底层的 VPA 项目，特别是推荐者。根据我们的经验，Goldilocks 是设置您的资源请求和限制的良好起点。但是每个环境都是不同的，Goldilocks 不能代替针对您的特定用例调整您的应用程序。

贡献给金发女孩

Goldilocks 是开源的，可以在 GitHub 上获得。我们继续进行大量的改进，提高其处理具有数百个名称空间和 VPA 对象的大型集群的能力。我们还改变了 Goldilocks 的部署方式，所以现在它包括了一个 VPA 子图，你可以用它来安装 VPA 控制器和它的资源。我们和哈里森·卡茨在 SquareSpace 做了很多改变，基于他和团队的宝贵反馈。我们希望不断改进我们的开源项目，并欢迎您的贡献！

Goldilocks 也是我们的 Fairwinds Insights 平台的一部分，该平台提供对您的 Kubernetes 集群的多集群可见性，因此您可以针对规模、可靠性、资源效率和安全性配置您的应用。

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

加入我们的开源小组——参加我们 9 月 23 日或 12 月 14 日的下一次聚会！

GoNoGo 在升级前检查 Kubernetes 附加组件

原文：https://www.fairwinds.com/blog/gonogo-checks-kubernetes-add-ons

在 GKE 或 AKS 这样的服务上部署第一个 Kubernetes 集群非常简单，但是当你想实际使用 Kubernetes 时，附加组件就变得很重要。

附加组件扩展了 Kubernetes 的功能。一些例子包括度量服务器、证书管理器、集群自动缩放器。与任何软件一样，附加组件的挑战在于它们需要升级。

每次需要进行附加升级时，都需要进行大量检查，以确保最新版本与您的集群兼容，并且没有重大更改。这个过程非常耗时，尤其是当您管理多个集群时。

这就是 Fairwinds 发布其最新开源工具 GoNoGo 的原因，该规范可用于定义然后发现与 Helm 一起安装的附加组件是否可以安全升级。

GoNoGo 如何工作

监控附加升级是管理集群的一部分。在本例中，我们将讨论证书管理器的升级。SRE 将意识到即将到来的或新的证书管理器升级。SRE 需要通过查看文档和发行说明来确定是否需要升级。

GoNoGo 依靠用户用 Helm 管理和升级附加组件。一旦您决定要进行升级，您将在一个名为 bundle spec 的 YAML 文件中绘制一些字段。这些字段将用于设置参数，这些参数将根据集群和舵图信息进行评估，以确定该插件的升级可信度。

例如:

您可能有一个只能在 Kubernetes 及以上版本上运行的版本
您可能希望检查集群中的某些 API 是否可用
您可能希望检查您的清单是否指定了适用于您要升级到的版本的 API 版本

所有这些信息将被捆绑在一个 YAML 文件中，并输入到 GoNoGo。

然后运行 GoNoGo，并带有一个指向这个包文件的标志。GoNoGo 会将您的捆绑包规范中的附加组件列表与您的集群中部署的 Helm 版本进行比较，并针对已经成功部署到您的集群的附加组件运行您指定的检查。然后，GoNoGo 将使用图表清单、上游 repo 和集群清单的组合来运行您的包规范中的各种检查。

捆绑包中的 OPA 和 JSON

在您的包中，您还可以设置定制的 OPA 检查，在清单中查找注释和字段之类的东西。GoNoGo 将运行 OPA 检查舵图的单个 YAML 文件，以及您在“resources”键下的包中指定的任何对象。

它还运行 json 模式验证。GoNoGo 可以根据存储在 repo 中的上游 values.schema.json 文件进行验证，或者您可以提供自己的内嵌模式。例如，您的架构可以指定它将检查 imagePullPolicy 是否设置为 Always。

为什么要用 GoNoGo？

虽然您仍然需要监视附加升级、查看文档并签入规范中的更改，但 GoNoGo 可以帮助您节省手动查看集群中所有对象的时间。

例如，如果 cert-manager 不同意一个注释，您将需要查看将要从中提取的上游舵图，并检查舵图是否已经更新了它的清单。你还需要进入你的集群，做一个导航get manifest，逐个查看你所有的清单，确保它们也有正确的注释。GoNoGo 为你做这个。因为 GoNoGo 会自动完成这项工作，所以在升级过程中丢失文件/人为错误的风险更小。

附加升级的最大风险是，因为它们是在集群范围内使用的，如果出现问题，它们可能会对您的集群产生深远的影响。影响范围将取决于附加组件。对于 Metric Server，可能没什么大不了的。但是，如果由于没有正确指定入口类名而错过了 nginx 入口插件，它可能无法传递流量，从而导致不必要的停机。类似地，如果您有一个损坏的 cert-manager 安装，那么当您试图解决这个问题时，您将无法为工作负载生成新的 cert。因此，虽然群集可能没有关闭，但它可能会影响服务。

如果您正在升级附加组件，请查看 GoNoGo 。

资源

为什么治理和护栏是 Kubernetes 所有权的真正基础

原文：https://www.fairwinds.com/blog/governance-guardrails-are-the-real-foundation-of-kubernetes-ownership

你会建造一座没有屋顶的房子吗？没有窗户的主卧怎么样？即使你想这么做，你的承包商肯定会建议你不要这么做，而且理由很充分。你依赖于建筑专业人士的建议，因为…嗯，建造一所房子是困难的，需要对最佳实践的深刻理解。房子需要坚固的地基，用钢筋和其他耐用材料加固。为了将来的服务，它必须正确接线；它需要窗户、门、通风口，甚至楼梯。这个清单还在继续。

同样，Kubernetes 是我们拥有的最接近于在任何地方构建基础架构的框架——在任何云或您自己的数据中心。作为一个开源容器编排平台，Kubernetes 框架也可以被认为是一个基础——一个需要大量专业知识来设置、管理和有效支付的基础。

但与现实生活中会告诉你如何按照规范安全建造屋顶和浴室的承包商不同，Kubernetes 只会给你材料——一袋袋水泥和木梁——来建造框架和地基。Kubernetes 不会给你的是在云原生计算环境中最好地利用这些材料所需的护栏和治理。换句话说，安装卫生间由你决定。

为什么如此关注治理和护栏？

作为一家企业，弄清楚如何为大规模生产做好准备是您必须做的一个关键部分，以建立您的基础。在为您的开发团队标准化随需应变服务(DevOps 的一个关键实践)时，您需要确保部署 Kubernetes 集群的团队遵循某些指导方针。

这一自动化过程通常通过策略管理来实现。即使您只有几个集群，主要由一个团队或个人管理，它们仍然需要同步。这一现实可能会转化为大量的工作，这是集中式策略管理和实施旨在处理的事情。

治理是关于执行的——然而，不同的治理规则是通过不同的框架实现的。作为一套以政策形式编纂的规则，Kubernetes 的适当治理可以控制成本，提高环境的效率、透明度和责任。这是蓝图。对于在生产中具有关键 Kubernetes 工作负载的团队，一个广泛、健壮的治理和运营框架是必要的，以帮助经理们发现对其动态环境的可见性和控制。

我如何设想建立我的 Kubernetes 基金会？

为了为您的组织建立治理框架，需要定义三个关键维度。这些细节将成为你组织的基础——墙壁、窗户和屋顶。问问你自己:

目标:哪些集群、工作负载或实体需要治理？
策略:您希望根据什么规则或标准来验证您的目标？
催化剂:什么时候应该检查保单？在 Kubernetes 部署之前？每 24 小时？

一旦您知道了这些问题的答案，您就需要一种方法来实施它们，以确保法规遵从性和健康治理。手动执行这一步骤肯定会导致不断灭火。使用能够根据您定义的规范自动执行符合性检查过程的工具是实现该框架的最佳方式。

开源工具适合哪里？

尽管治理是至关重要的，但是您不会找到一个单一的综合工具来解决您所有的治理需求。这意味着你将需要混合和匹配，直到你所有的关键领域都包括在内。这里的目标是最小化您需要的治理框架的数量，同时仍然最大化覆盖范围，使您的操作团队的生活更容易。

开源项目可以帮助引导一些护栏，这就是为什么为您的环境选择正确的工具是关键。正如我们所知，容器和 Kubernetes 中的错误配置是一个真正的问题。这类似于不加屋顶，然后意识到在某个时候，雨会来。一旦这家人搬进来，以后再进行改进就困难多了——更不用说，这是一个安全隐患。类似地，Kubernetes 中的安全错误配置将您的组织置于风险之中。

也就是说，Kubernetes 比几年前健康多了。有一个复杂的框架真正推动了稳定。这一努力有助于引导 Kubernetes 所有权周围的一些护栏，包括对更好的配置和管理的需求。

为什么选择 Fairwinds Insights？

我们在 Kubernetes 中为护栏构建软件，这是一个配置验证平台，让您知道您是否构建了没有钢筋的基础。Fairwinds Insights 会告诉你，你是否忘记了浴室，离开了屋顶，以及你是否应该让前门的那个粗略的家伙进入你的安全环境。我们已经构建了许多开源项目来帮助这项工作，包括针对常见错误配置验证问题的 Polaris 。

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

要了解更多关于 Kubernetes 的治理和护栏问题，包括有关 Fairwinds Insights 的信息，请收听我们最近关于该主题的网络研讨会。记住，不要怕用错 Kubernetes 有护栏！

实践 Agones 和 Google 云游戏服务器

原文：https://www.fairwinds.com/blog/hands-on-with-agones-google-cloud-game-servers

我最近有幸探索了 Agones 和 Google 云游戏服务器(GCGS) ，我想分享一下我的经验。

Agones 是一个在 Kubernetes 中运行多人游戏服务器的开源平台。在这次探索中，我从未运行过任何类型的游戏服务器，但是我在 Kubernetes 中处理过实时通信工作负载。我看到了这两种经历之间潜在的相似问题集，并好奇 Agones 将如何解决我在过去看到的问题。

在 Agones 之上，GCGS 是一个多集群管理层，使得跨多个集群部署游戏服务器更加容易。在我更详细地介绍 GCGS 之前，有必要对 Agones 有一个更深入的了解，它是如何安装的，以及它有什么作用。

Agones

安装

关于 Agones，我注意到的第一件事是，它完全是库伯内特斯土著。我是这个的忠实粉丝，因为这些天我在 Kubernetes 上运行一切；有安装与舵指令，我立即跳转。在我的 GKE 集群上的初始 Helm 安装进展顺利，几分钟内我就有了一些自定义资源定义(CRD)和一个控制平面在 agones-system 名称空间中运行。

▶ kubectl get deploy -n agones-system -oname
deployment.extensions/agones-allocator
deployment.extensions/agones-controller
deployment.extensions/agones-ping

▶ kubectl get crd -oname | grep agones
fleetautoscalers.autoscaling.agones.dev
fleets.agones.dev
gameserverallocationpolicies.multicluster.agones.dev
gameservers.agones.dev
gameserversets.agones.dev

创建一个游戏服务器

我有一个控制器、一个分配器、一个 ping 服务器和一些看起来有用的 CRD，但是我现在该做什么呢？遵循文档中的，下一步似乎是创建一个游戏服务器。

所以我按照文档从提供的 yaml 清单中创建了一个游戏服务器。这个游戏服务器使用一个名为 simple-udp 的示例服务来展示 Agones 是如何工作的，这是我们开始了解 Agones 真正在做什么的地方。

如果我看一下 gameserver 规范，我会发现它包含一个容器规范，就像 pod 规范一样。它还通过他们所谓的 portSpecification: 来声明端口

spec:
  ports:
  - name: default
    portPolicy: Dynamic
    containerPort: 7654

这意味着它将使用一个 Dynamic 外部端口，并且容器正在监听端口 7654。很酷，到目前为止很简单。

进一步看，我可以检查 gameserver 以查看分配了哪个端口:

▶ kubectl get gameserver                                                                                            
NAME               STATE   ADDRESS         PORT      AGE    
simple-udp-4pgls   Ready   35.224.97.238   7063

看起来我有一个运行 pod 并监听端口 7063; 的游戏服务器，现在我将尝试使用 netcat 通过 UDP 连接。

▶ nc -u 35.224.97.238 7063   
HI                           
ACK: HI                      
EXIT                         
ACK: EXIT

simple-udp 服务器完成了它的工作，用我发送的任何东西来响应我，然后我给出了退出命令。这个服务器的设置方式是，当它接收到一个 EXIT 命令时，它告诉 Agones 它完成了，然后 Agones 关闭游戏服务器。我们可以在实践中看到这一点:

▶ kubectl get po
NAME               READY   STATUS        RESTARTS   AGE
simple-udp-4pgls   0/2     Terminating   0          30s

▶ kubectl get gameserver
NAME               STATE      ADDRESS         PORT                                  
simple-udp-4pgls   Shutdown   35.224.97.238   7063

pod 终止，游戏服务器状态为 Shutdown.

关于网络和集群创建的简要说明

我第一次尝试连接游戏服务器时，没有任何反应。就我而言，这是因为我没有遵循 Agones 安装指南中所有精彩的文档。我跳过了集群创建部分，因为我认为我已经知道如何创建一个集群。原来这里有一个步骤有点不同寻常。由于这些游戏服务器都需要监听 UDP 端口，我们需要在 GCP 防火墙上打开一组端口。请注意，本例中的端口范围是 udp:7000-8000。此端口范围由 Agones 控制面板安装控制，并且可以通过舵图表中的值进行配置:

▶ gcloud compute firewall-rules create game-server-firewall \
  --allow udp:7000-8000 \
  --target-tags game-server \
  --description "Firewall to allow game server udp traffic"

完成之后，我们需要用 game-server 标记节点，以便应用这个规则。从一开始就遵循集群创建说明要容易得多，这会让您在开始时添加标记并创建防火墙规则。

艾格尼丝建筑

你可能会问自己为什么 gameserver 这个东西很重要，所以我要离开探索一步，谈谈 Agones 实际上在做什么。

游戏服务器在理论上只是一个进程，多个客户端可以连接到这个进程来玩游戏。这有许多不同的实现方式，但是这些服务器必须做几件关键的事情，这会影响它们在 Kubernetes 中的运行方式:

1. Gameservers must remain available during the time that the game is being played.

事实上，gameserver pod 必须在指定的时间内不间断，这意味着我们不能因为自动缩放、耗尽或任何其他原因而杀死 pod。为了解决这个问题，gameserver 以一种部署无法做到的方式管理 pod 生命周期。Agones 为游戏服务器引入了几种状态，游戏代码本身能够通过 Agones API 更新这种状态。Agones 在每个游戏服务器中运行一个 sidecar 来接收流量。

2. Gameservers must accept connections on some specified port from multiple clients.

由于端口耗尽的可能性，当在 Kubernetes 中运行多个游戏服务器时，这也是一个问题。我们需要一种方法来分配游戏服务器可以使用的许多不同的端口。Agones 通过其动态端口分配策略无缝处理这一问题。每个游戏服务器都被分配了一个端口和一个 IP 组合，客户端可以使用它们进行连接。

谷歌云游戏服务器(GCGS)

既然我们已经掌握了 Agones 如何安装和游戏服务器如何运行的基本知识，我们可以开始看看 GCGS 在此基础上提供了什么。我从他们文档中的快速入门指南开始。本指南要求您做的第一件事是创建一个集群并向其部署 Agones。我已经完成了，所以我跳到了创建 GCGS 王国的部分。

领域

GCGS 的领域是一个组织结构。在这个探索过程中，我试图找出将一大群全球集群组织成领域的最佳方式。我最终在 Agones public Slack 和一个谷歌人聊了聊。(有一个 #google-cloud-game-servers 频道在那里)。在这里，我不会太深入地讨论领域组织，但我得到的最佳建议是:

一个很好的经验法则是“从玩家的角度来看，集群组之间的延迟差异无关紧要”

反正我跑题了。一旦您有一个或一组运行 Agones 的集群，为了使用 GCGS，您必须将它们添加到一个领域中。这很简单，用几个 gcloud 命令就可以做到:

▶ gcloud game servers realms create agones-blog --time-zone EST --location us-central1
Create request issued for: [agones-blog]
Waiting for operation [projects/gcp-prime/locations/us-central1/operations/operation-1598980635305-5ae43b0c52589-34a097b6-d0659fc7] to c
omplete...done.
Created realm [agones-blog].

▶ gcloud game servers clusters create agones-blog --realm=agones-blog --gke-cluster locations/us-central1/clusters/agones-blog --namespace=default --location us-central1 --no-dry-run
Create request issued for: [agones-blog]
Waiting for [operation-1598980727087-5ae43b63da1ee-88b19318-22a70d4f] to finish...done.
Created game server cluster: [agones-blog]

第一个命令创建领域，第二个命令将运行 Agones 的集群连接到该领域。

现在我们已经在一个领域中有了一个集群，下一步是创建一个部署。部署基本上是一组配置的容器，这些配置将描述一组游戏服务器。因此，我们创建部署，然后在其中创建配置:

▶ gcloud game servers deployments create agones-blog
Create request issued for: [agones-blog]
Waiting for operation [projects/gcp-prime/locations/global/operations/operation-1598980944523-5ae43c3336ffd-4eb7fce4-fd872d08] to complete...done.
Created deployment [agones-blog].

▶ gcloud game servers configs create config-1 --deployment agones-blog --fleet-configs-file fleet_configs.yaml
Create request issued for: [config-1]
Waiting for operation [projects/gcp-prime/locations/global/operations/operation-1598981023478-5ae43c7e83334-58008b9c-8df141c0] to complete...done.
Created game server config [config-1].

注意，在创建配置时，我指定了一个包含车队规范的 yaml 文件。车队规范看起来很像我们之前部署的 gameserver 规范，但是具有模板和副本字段:

- name: fleet-spec-1
  fleetSpec:
    replicas: 2
    template:
      metadata:
        labels:
          foo: bar
      spec:
        ports:
        - name: default
          portPolicy: Dynamic
          containerPort: 7654
        template:
          spec:
            containers:
            - name: simple-udp
              image: gcr.io/agones-images/udp-server:0.17

这表明我们希望创建两个游戏服务器，并保持副本数量为 2。如果 gameserver 规范类似于 pod 规范，那么舰队就很像 Kubernetes 部署。

最后要做的事情是将该部署部署到领域中的集群。

▶ gcloud game servers deployments update-rollout agones-blog --default-config config-1 --no-dry-run
Update rollout request issued for: [agones-blog]
Waiting for [operation-1598981253616-5ae43d59fd30b-b841d131-f1822e0c] to finish...done.
Updated rollout for: [agones-blog]
createTime: '2020-09-01T17:22:24.587136253Z'
defaultGameServerConfig: projects/gcp-prime/locations/global/gameServerDeployments/agones-blog/configs/config-1
etag: fHXlfY2MivvPraKyPJEseJF5SqjaBfUrnaWMGT1aCb8
name: projects/gcp-prime/locations/global/gameServerDeployments/agones-blog/rollout
updateTime: '2020-09-01T17:22:25.547699385Z'

完成后，我们看到在我们的集群中部署了 agones 车队，配备了我们要求的两台游戏服务器:

▶ kubectl get fleet
NAME                         SCHEDULING   DESIRED   CURRENT
fleet-agones-blog-config-1   Packed       2         2

▶ kubectl get gameserver
NAME                                     STATE   ADDRESS         PORT
fleet-agones-blog-config-1-st55c-8gbd2   Ready   34.123.40.127   7212
fleet-agones-blog-config-1-st55c-rnxjh   Ready   34.123.40.127   7839

为什么使用 GCGS？

到目前为止，看起来你可以使用 Agones CRD 将舰队部署到你的集群，这是完全正确的。GCGS 的真正优势在于这些车队的多集群管理。

在进一步的探索中，我启动了另一个集群，安装了 Agones，并将该集群添加到领域中。当我添加第二个集群时，我看到舰队也被部署到新的集群。这告诉我，集群现在由 GCGS 集中管理。我可以在领域中随意添加和删除集群，并且我的游戏服务器部署保持不变。这是一个非常强大的概念，它将使管理游戏服务器的大规模部署变得更加容易。

游戏服务器分配

到目前为止，我们已经看到了如何使用 Agones + GCGS 将游戏服务器部署到多个集群，但是我们实际上如何使用这些游戏服务器呢？我们知道每个游戏服务器都处于 Ready 状态，并且每个游戏服务器都可以在指定的端口和 IP 地址上接收 UDP 流量。现在让我们探索另一个强大的 Agones 概念:分配。

您可能已经注意到，其中一个控制平面部署名为 agones-allocator. 默认情况下，Helm chart 会部署这个控制平面和一个相应的服务，但是在您可以使用它之前，它需要进一步的配置。分配服务的设置超出了本文的范围，但是在 高级 Agones 文档中有详细介绍。

一旦配置了分配器服务，您就可以使用 mTLS 和 gRPC 向分配器发出请求。该请求可以指定选择器，该选择器将通过标签来限制游戏服务器的选择。您得到的响应是一个 IP 地址和一个游戏服务器的端口。真正酷的部分是这个游戏服务器的状态现在在 Kubernetes API 中变成了 Allocated 。这意味着不允许分配器服务再次分配那个游戏服务器，并且在节点耗尽的情况下，这个游戏服务器不能再被 Kubernetes 关闭。实际上，这种 pod 现在是一种长寿服务，只要它还在使用，Agones 和 Kubernetes 就会努力让它保持活力。

此外，GCGS 还可以设置多集群分配，这样，每当您向领域中的集群发出分配请求时，您都可以被分配到该领域中任何集群中的任何可用游戏服务器。这是涵盖在【GCGS】文档中的。

总之

Agones 是一个开源平台，提供 CRDs 和一个控制器，用于在 Kubernetes 中运行游戏服务器。运行起来很简单，文档也很棒。添加 Google 云游戏服务器可以让你从一个中心点管理多个运行 Agones 的集群，并使跨所有集群部署游戏服务器变得更加简单。

在我探索这些产品的过程中，我越来越对它们让运行游戏服务器变得更容易的潜力感到兴奋。我遇到的障碍很小，Agones public Slack 中的谷歌员工总是乐于助人，提供丰富的信息。我很少探索一个新的谷歌产品(当我第一次遇到它时，它还处于测试阶段)并有这种很好的体验。向在 Agones 工作的团队大声欢呼。

使用插件帮助改进您的 Kubectl 命令

原文：https://www.fairwinds.com/blog/help-improve-your-kubectl-command-with-plugins

您可以使用插件向 kubectl Kubernetes 命令行工具添加特性。创建kubectl子命令来添加定制功能，同时保持与 Kubernetes 的紧密交互。请继续阅读，了解更多关于 kubectl 插件的信息，在哪里与社区共享插件，以及您可能想在自己的 kubectl 中添加哪些新的有用插件。

这些插件是什么？

可以使用 kubectl 插件来扩展kubectl命令，这些插件是路径中以 kubectl- 开头的可执行文件(kubectl 后跟一个破折号)。您可以使用任何编程或脚本语言，并且不需要库或预加载。

插件文件的名称决定了 kubectl 命令。包含破折号(-)表示空格，下划线(_)表示破折号。例如，kubectl hello world子命令将在kubectl-hello-world文件中执行，而kubectl hello world at-night子命令将在kubectl-hello-world-at_night文件中执行。

Kubectl 使用可用时间最长的插件，并将剩余的命令行参数传递给插件。例如，如果您运行命令kubectl gke create regional，kubectl 将首先查找可执行文件kubectl-gke-create-regional，然后是kubectl-gke-create，以此类推。如果第一个可用的插件是kubectl-gke，参数create regional将被传递给插件。

您可以通过创建一个更具体的插件来将命令添加到现有的插件中。使用上面的kube-gke示例，您可以通过创建kubectl-gke-create-zonal来添加kubectl gke create zonal命令，而不是向kubectl-gke插件添加功能。

您不能使用插件来覆盖或添加子命令到内置的 kubectl 命令中。您不能使用kubectl create catastrophe插件，因为create已经是一个 kubectl 命令。

在您的路径中找到的第一个插件将由 kubectl 使用。命令显示所有可用的插件，包括路径中重复插件的警告，或者不可执行的插件。

目前 kubectl shell 自动补全不包括选项卡补全建议中的插件，正如在这个特性请求中提到的。

与他人共享插件

共享 kubectl 插件的两种常见方式是 kubectl-plugin Github 主题和 Krew kubectl 插件管理器。

Kubectl-plugin Github 主题

你可以用主题对 Github 库进行分类，以帮助其他人发现它。 kubectl-plugins Github 主题包含 48 个库，其中一些包含多个 kubectl 插件。每个插件作者都有自己的安装和升级过程，从编译自己的二进制文件到下载一个 shell 脚本。

将你的插件 Github 库添加到这个主题是一个好主意，即使你使用 Krew(如下所述)来共享你的插件。

Krew 插件管理器

Krew 是一个针对 kubectl 插件的插件管理器，旨在简化多个操作系统上的插件发现、安装、升级和移除。您可以通过运行kubectl krew search ...来搜索可用的插件，或者通过运行kubectl krew upgrade来升级所有新安装的插件。

目前不可能将一个插件固定到你的首选版本来防止它被升级。您可以通过从先前提交到 krew-index 存储库中获取清单文件，并对kubectl krew install命令使用--manifest=FileName.yaml选项来安装旧版本的插件。

Krew 已被 Kubernetes SIG-CLI 接受，中央索引可能会演变为类似于 Helm Hub 的目录索引，正如在本提案中所提到的，将 Krew 作为 SIG CLI 子项目。

血液样本呢

安装git，然后遵循 Krew Github 页面上的安装说明。下面是一个使用 Krew 搜索安装 kubectl 插件的例子:

我将使用krew info命令来读取关于资源容量插件的更多信息，然后使用krew install命令来安装它。

这非常简单——我不需要下载、解压存档，或者验证任何校验和。我碰巧安装在 Linux 上，但这个插件也适用于 Mac OS X。现在我可以在我相对较空且无聊的集群上使用资源容量插件:

向 Krew 贡献插件

Krew 命名指南给出了很好的建议，让插件更容易被krew search命令发现，并避免宽泛或过载的术语。例如，命名一个插件kubectl-gke-login或kubectl-gke-ui，而不是更一般的名字kubectl-login或kubectl-ui。

Krew 插件开发者指南描述了如何创建一个插件。与 Krew 一起使用的 zip 或 .tar.gz 文件，以及 plugin.yaml 清单文件，其中包含您所支持的操作系统的信息、校验和以及到您的插件的下载链接。最后一步是创建一个 krew-index pull 请求，将您的 plugin.yaml manifest 文件添加到 krew 索引中——一旦您的 pull 请求被接受，任何使用 Krew 的人都可以使用您的插件。

接受新插件到 krew-index repo 有一些挑战，如这个 tiller-init pull 请求所示。前面提到的 Krew 对 SIG-CLI 的捐赠包括改进插件索引过程的计划。

让插件共享开始

是时候分享你的插件了，不管你是使用 Git 库， Krew ，还是在这样的博客中。说到分享。。。

发现有问题的 Pod 中断预算

显示允许少于一次中断的 pod 中断预算-这些可以防止 Kubernetes 节点在维护期间被耗尽。这个插件需要jq命令。

列出带有池和版本的 Google 容器引擎节点

当 Google Container Engine (GKE)集群正在升级时，用节点池的名称和 Kubernetes Kubelet 的版本列出节点会很有用。

感谢您的阅读

感谢您的阅读！如果你喜欢这篇文章，或者对上面的 kubectl 插件有建议，请联系 Twitter 上的 @IvanFetch 。

以下是今年 KubeCon 上最热门的 4 个话题

原文：https://www.fairwinds.com/blog/here-are-the-4-hottest-topics-to-look-for-at-kubecon-this-year

KubeCon + CloudNativeCon 2021 回来了！云本地计算机基金会的旗舰会议即将于 10 月 13-15 日在加州洛杉矶召开。

在 Fairwinds 这里，我们很高兴能与来自开源和云原生社区的其他采纳者和技术专家讨论 Kubernetes 的所有事情。混合的现场/虚拟活动承诺提供为期四天的主题演讲、跟踪和演示，涵盖 Kubernetes 和其他云原生技术的价值。

众所周知，与传统基础设施相比，这些技术以更低的运营成本促进了更快的软件开发。但是，云原生世界充满了新的未知领域，企业仍在学习如何适应新的计算时代的政策和实践。KubeCon + CloudNativeCon 将有助于为与会者提供这一新兴领域的地图，将从业者和专家社区聚集在一起，分享他们在这一日益突出的数字领域的经验和专业知识。

那么，在 Kubernetes 的世界里，你可以期待听到的四个重要话题是什么？

1.多集群管理

较大的组织倾向于以渐进的方式采用 Kubernetes，由单个团队决定如何以及何时进行转换。组织开始意识到他们有一大群 Kubernetes 集群在他们的云中运行，几乎没有一致性、策略和工具来管理它们。其结果是集群和工作负载无序蔓延的混乱环境，造成冗余工作和资源浪费，无数的治理挑战，以及难以(如果不是不可能的话)妥善保护的软件环境。

在今年的 Kubecon 大会上，我们希望看到有助于大型组织统一管理和了解其 Kubernetes 集群的解决方案。

您知道集群蔓延会对治理、开发和运营产生负面影响吗？你可以很容易地找到更多关于创建为你的组织工作的治理框架的信息。

2。应用开发平台表面

虽然 Kubernetes 可以提供一个坚实的平台基础，但它也很难掌握，尤其是对开发团队而言。虽然您的 SRE 和运营团队确实需要对 Kubernetes 有深入的了解，但其他团队，如 web 和应用程序开发人员，可能不需要学习所有的东西就能提高工作效率。

通过正确的抽象(删除细节以显示必要的功能)，开发人员可以更容易地与 Kubernetes 平台交互，从而减少工作量，加快创新。虽然我们已经看到一些 Kubernetes 开发和部署平台浮出水面，但没有一个平台在复杂性和灵活性之间找到了平衡点——我们希望今年在 Kubecon 上看到这一领域的一些发展。

3.安全基础设施

Kubernetes 现在是寻求访问敏感用户数据和知识产权的网络罪犯的高价值目标。幸运的是，随着攻击者变得越来越老练，用于保护您的环境的工具也越来越多。

在 Kubecon，我们希望看到用于识别和减轻集群中潜在风险的平台激增，以及关于如何更好地保护敏感工作负载的大量建议。最佳解决方案将提供可行的建议，说明如何通过在网络和应用层进行更智能的访问控制，以及实施策略和工作负载隔离来保护您的 Kubernetes 集群。Kubernetes 对集群的持续安全监控降低了风险，并确保遵循最佳实践。

4.政策与合规

随着组织内 Kubernetes 集群数量的增长，对正式政策的需求也在增长。这些策略可以保持环境的安全性、一致性，并符合内部和第三方要求。有越来越多的平台可以帮助你定义并自动执行 Kubernetes 的政策——请密切关注这一领域的更多创新和发展。

来 KubeCon 看我们吧！

无论您是亲自参加还是虚拟参加，都不要错过 Fairwinds 如何帮助您实现 Kubernetes 治理、安全性和成本优化。

亲自参加？下面是你需要知道的:

洛杉矶会议中心:2021 年 10 月 13-15 日(周三-周五)世博馆开放

与我们的 Kubernetes 专家交流，了解为什么我们是 Kubernetes 安全、治理和政策领域值得信赖的合作伙伴(S32 展位)
预订位置观看 Fairwinds Insights 的演示，了解最新的特性和功能
亲自注册，赢取 Linksys Hydra Pro 6E:Tri-Band Mesh WiFi 6E 路由器或 DJI 迷你无人机 2
10 月 14 日星期四上午 11 点，与菲皮和朋友们一起参加巴什海军上将的岛屿冒险活动，并有机会见到包括费尔温德公司的丹妮尔·库克在内的该书作者。先看看这本全新的 CNCF 书籍吧！
我们有数量有限的 20%折扣(最高价值 300 澳元)优惠券，可用于购买完整的会议通行证。回复此邮件即可获得今天的代码

⑩无形中？下面是独家新闻:

Fairwinds 虚拟展台将于 2021 年 10 月 11 日至 15 日周一至周五向参观者开放。即使你不能亲自参加，我们仍然在网上提供同样的体验。

与我们的 Kubernetes 专家交流，了解为什么我们是 Kubernetes 安全、治理和政策领域值得信赖的合作伙伴(银牌赞助商展厅)
预订一个位置，观看 Fairwinds Insights 的演示，在我们的虚拟办公时间内了解最新的特性和功能。(在更接近发布时间的展位列出)
在线注册，赢取 Linksys Hydra Pro 6E:Tri-Band Mesh WiFi 6E 路由器或 DJI 迷你无人机 2
10 月 14 日星期四上午 11 点，与菲皮和朋友一起参加巴什上将的岛屿冒险，并有机会与包括费尔温德公司的丹妮尔·库克在内的该书作者互动。先看看这本全新的 CNCF 书籍吧！
虚拟活动的免费入场券数量有限。回复这封电子邮件获得一个代码的今天！

想了解更多关于 KubeCon 的信息吗？查看官方日程。

Fairwinds 为 Kubernetes 开发的开源项目

原文：https://www.fairwinds.com/blog/here-is-an-overview-of-our-open-source-projects-for-kubernetes

开源软件是 Fairwinds 的核心，为我们的客户和更大的社区提供 Kubernetes 支持。我们努力构建开源项目，帮助我们的客户进行创新，并使用户能够设计正确的 Kubernetes 架构和部署。

开源的快乐

构建应用程序通常需要一些棘手的技术决策。相对于依赖第三方，你自己构建什么？在做出这些决定之前，你需要问自己开源如何帮助你的组织成功——以及你是否愿意投入时间使用开源代码(查看我们关于开源的隐藏成本的论文)。开源软件带来了一些挑战，包括设置、成本、维护、安全性和可靠性。即便如此，社区中仍有大量支持来帮助从业者在没有第三方的情况下实现他们需要的东西。

我们的项目概述

在 Fairwinds，我们努力提供企业需要的开源代码类型，以构建更好的产品和服务。对我们的 Kubernetes 开源项目的快速概述可以让您了解我们的贡献是如何改变现代软件的面貌的。

北极星运行各种检查，以确保使用 Kubernetes 最佳实践配置 pod 和控制器。作为我们最受欢迎的开源项目之一，Polaris 识别 Kubernetes 部署配置中的错误，以帮助用户找到导致安全漏洞、中断、扩展限制等的错误配置。北极星可以在三种不同的模式下运行:

作为审计集群内部运行情况的仪表板
作为准入控制器，自动拒绝不符合策略的工作负载
作为测试 YAML 文件的命令行工具，例如作为 CI/CD 流程的一部分

Kubernetes 安全性的一个重要目标是确保容器以最小权限运行，避免升级，不使用根用户运行容器，尽可能使用只读文件系统。在 pod 和 container 级别的配置都可用的情况下，Polaris 可以对两者进行验证，让您避免潜在的问题，同时通过成熟的策略获得成功。

在 GitHub 中查看北极星 | 查看北极星文档页面

Goldilocks 是一款用于推荐资源请求的开源工具，允许用户在推荐模式下使用 Kubernetesvertical-pod-autoscaler(VPA)查看每个应用程序的建议。Goldilocks 为名称空间中的每个部署创建一个 VPA，并查询它们的信息，同时考虑到您的 pod 的当前资源使用情况，以获得更好的指导。Goldilocks 没有运行水平 pod 自动缩放器(与 VPA 不太匹配)，而是使用 VPA 建议来提供可靠且可行的反馈。

Goldilocks 仪表板提供了 VPA 建议的可视化，因此您可以访问集群中的服务并查看两种类型的建议，具体取决于部署所需的 QoS 等级。QoS 类别指的是可以设置资源请求和限制的不同方式。

查看 GitHub 中的金发女郎 | 查看金发女郎文档页面

Pluto 帮助用户在他们的代码库和 Helm 版本中轻松找到破旧的 Kubernetes API 版本。随着 Kubernetes 生态系统的不断发展，API 也在不断发展，这意味着弃用和删除是不可避免的。如果你已经迁移到 Kubernetes 1.22 或者 OpenShift 4.9，你就知道这种痛苦是真实存在的。如果您正在计划升级，Pluto 是一个完美的开源实用程序，可以帮助您找到已弃用或已删除的 Kubernetes apiVersions。一旦 Pluto 集成到您的 CI/CD 管道中，它就会根据您的目标 Kubernetes 版本扫描资源。

当几个应用程序部署到 Kubernetes 集群时，集群升级可能会中断部署过程，从而可能影响数百个存储库。Pluto 旨在提前提供这些关键信息，以确保在升级发生之前解决部署过程。作为一个开源工具，Pluto 可以用来扫描各种来源的过时版本，包括平面清单文件和使用 Helm 进行部署的集群。

在 GitHub 上查看冥王星 | 查看冥王星文档页面

是一个 Helm 的命令行工具，使用 YAML 语法在一个文件中安装和管理多个 Helm 图表，允许从 git 提交、分支或发布安装图表。你想要使用这个开源工具安装的图表的定义被称为“课程”，它包括告诉 Reckoner 如何使用 Helm 安装你的图表的设置，在哪个名称空间和用什么值。本课程还概述了您可以从哪些远程图表存储库中提取数据，并像管理任何其他基础设施代码一样进行管理。

在 GitHub 中查看计算者 | 查看计算者文档页面

Nova 是一个命令行界面，用于交叉检查 Kubernetes 集群中运行的最新版本的舵图。让您的云原生环境中的一切保持最新是最关键(也是最困难)的任务之一。在新版本发布后未能升级可能会使您的组织暴露于安全漏洞、功能缺陷和潜在违规。

开源工具 Nova 通过让您知道是否有新版本可用，来帮助您确定何时更新。这个功能可以很容易地看到你是否落后于任何已安装的舵图表，节省用户大量的时间和资源。运营商无需监控每个图表的更新，只需运行一条 Nova 命令即可检测旧版本，确保 YAML 文件是最新的，基础设施代码符合这些标准。

在 GitHub 中查看 Nova|查看 Nova 文档页面

Gemini 构建于 Kubernetes-native volume snapshot API 之上，为用户创建一个更加健壮和用户友好的界面。这款开源工具允许按照可定制的细粒度计划进行自动备份，自动删除过时备份，并从特定备份中恢复数据。

Gemini 帮助用户处理 Kubernetes 中的持久存储，从而允许开发人员在其云环境中更好地管理卷和备份。为 Gemini 添加自动化功能意味着卷快照不再需要手动完成，这使得开发人员可以更轻松地确保数据安全。

在 GitHub 中查看双子座

Saffire 通过从各种注册表中提取图像，帮助开发人员和工程团队避免单点故障。这个开源控制器运行在一个 Kubernetes 集群中，监视那些在提取底层映像时遇到问题的 pod。Saffire 使用户能够在主注册中心检测到问题时，例如在停机期间，自动在注册中心之间切换。

在当今高度自动化的 DevOps 环境中，工程师和开发团队不断更新和部署新版本的软件和应用程序。从注册表中提取容器映像对于部署过程至关重要。如果注册中心不可用，部署就会中断，从而导致停机，并给开发人员和业务带来重大问题。Saffire 解决了这个问题。

在 GitHub 中查看 Saffire

Rok8s-scripts 提供了一个用 Docker 和 Kubernetes 构建 GitOps 工作流的框架。将这个开源工具添加到您的 CI/CD 管道中，允许用户在使用一组经过测试的最佳实践的同时构建、推送和部署应用程序。它可以用来验证部署和数据库迁移，处理机密和组织 YAML 文件。

除了构建 Docker 映像并将其部署到 Kubernetes，rok8s-scripts 还处理安全机密管理、特定于环境的配置、Docker 构建缓存等等。Rok8s-scripts 旨在很好地与各种用例及环境一起工作，提供了许多配置 CI 管道的有效方法。

查看 GitHub 中的 Rok8s-scripts|查看 Rok8s-scripts 文档页面

RBAC 管理器通过使用新的定制资源支持 RBAC 的声明式配置，简化了 Kubernetes 中的授权。用户可以指定所需的状态，而不是直接管理角色绑定或服务帐户，RBAC 管理器将确保进行必要的更改来实现这一点。RBAC 管理器通过减少大授权所需的配置工作量和实现 RBAC 配置更新的自动化，提供了一个更易接近和可扩展的解决方案。这个开源工具大大减少了配置所需的时间。

在 GitHub 中查看 RBAC 经理 | 查看 RBAC 经理文档页面

RBAC 查找是一个 CLI，允许从业者容易地找到绑定到服务帐户、组名或单个用户的 Kubernetes 角色和集群角色。"这个用户对这个群集有多少访问权限？"现在更容易回答了。虽然 RBAC 管理器使该过程更容易管理，但 RBAC 查找可以提供对 Kubernetes 授权的可见性，并有助于遵守集群中的最小特权原则..

查看 GitHub 中的 RBAC 查找 | 查看 RBAC 查找文档页面

加入我们的开源社区！

Fairwinds 提供了一个集成的、可信的开源工具平台，可以主动监控 Kubernetes 的配置，并提出改进建议以避免将来出现问题。Fairwinds 开源社区的目标是交流思想，影响开源路线图，并与 Kubernetes 用户建立联系。要参与进来，在 Slack 上与我们聊天或者加入我们的开源用户组！

下一次开源会议将于 2022 年 6 月 22 日东部时间上午 11 点|太平洋时间上午 8 点举行。立即注册！

Heroku Vs. Kubernetes:你应该知道的巨大差异

原文：https://www.fairwinds.com/blog/heroku-vs.-kubernetes-the-big-differences-you-should-know

乍一看，Heroku 和 Kubernetes 的比较似乎很奇怪。它们是截然不同的技术，针对完全不同的群体。一个是为了快速获得代码，而另一个是为了随着您的业务增长而扩展。但是在 Fairwinds，我们经常发现工程团队在应该使用另一个的时候使用了另一个。

为了帮助澄清巨大的差异，让我们从一个高层次来考察 Heroku 和 Kubernetes。

Heroku

Heroku 提供了很好的开发者体验。它简单易用，非常适合那些只想编写代码并交付给 prod 的开发人员。Heroku 简单明了的框架使开发人员能够快速获得代码。

然而，使用 Heroku，您不会得到任何真正的编排。在您的应用程序如何扩展或如何与您可能部署到云的其他应用程序交互方面，没有选项。此外，Heroku 的观点决定了您如何设计您的应用程序，如果不重写代码，任何未来的迁移都是不可能的。

但是对于简单的孤立的应用程序，Heroku 的简单性和观点可以减少操作上的麻烦。如果您的应用程序由单个二进制文件组成，并且只需要根据延迟进行伸缩，Heroku 可能是完美的选择。

库伯内特斯

Kubernetes 在应用程序的伸缩方面更加灵活。此外，Kubernetes 是开源的。如果您围绕 Kubernetes 编写应用程序，您可以在内部部署它，或者部署到 Google、Amazon 和任何其他云提供商。它完全不受供应商限制。

Kubernetes 的功能也足够丰富，可以与您的公司一起成长。Kubernetes 的核心组件可以处理 90%的用例，开放平台允许任何第三方扩展其功能以满足他们的需求。当然，所有这些灵活性都伴随着陡峭的学习曲线，所以准备好投资培训您的工程师，并考虑寻找一个合作伙伴来帮助您找到最适合您组织的配置和工具集。

Heroku 非常适合小型项目...

Heroku 通常是开发者对黑客马拉松的选择。如果你想在周末和几个朋友一起验证概念，Heroku 是完美的原型。您可以简单地推送您的代码，而无需担心配置机器、联网或扩展。

最终，如果你是一个处于创业模式的小团队，只是想在用户面前推出一个 MVP，Heroku 是一个很好的起点。它的简单性和易用性意味着您可以将时间集中在构建一个伟大的产品上。

...但是随着成长，你会想要转换。

如果你有一个快速扩展的业务，需要适应未来，需要随着市场增长，你会很快体验到 Heroku 的局限性。在这些场景中，你会想要一个更成熟的编排平台，比如 Kubernetes。

我们发现从 Heroku 转向 Kubernetes 有两个主要驱动因素:

1。成本

当你的应用程序在用户数量和流量方面达到一定的规模时，你将为 Heroku 支付不再有意义的溢价。在最好的情况下，Heroku 的价格是亚马逊价格的两倍。

例如，在一家拥有数十或数百名用户的早期创业公司，你的云账单几乎不会削减你的预算，尤其是相对于工资单之类的东西。然而，一旦你达到一定的规模水平，你就会开始从你的首席财务官那里听说云成本。

当你一年要花费 1 万到 10 万美元的时候，你应该考虑离开 Heroku——你从转换到另一个云提供商节省下来的钱可以为一个新员工腾出足够的预算！

2。复杂性

最终你的应用会有 Heroku 无法满足的复杂需求。

例如，对于 Heroku 用户来说，过于简单的自动缩放是一个常见的挫折。假设您的应用程序需要根据运行在另一个服务上的消息队列积压的大小进行扩展。Heroku 无法处理这一点，它只能根据请求延迟进行扩展。

对于 Heroku 来说，网络和编排需求也可能很快变得过于复杂，尤其是当您的应用程序由几个独立的子应用程序和微服务组成时。举个例子，考虑网飞的视频流平台:有一个浏览应用程序来浏览他们的视频库；推荐引擎决定哪些视频浮出水面；搜索引擎允许你手动寻找东西；最后，一旦你做出决定，一个视频流媒体服务就开始了。所有这些不同的服务都需要相互对话、独立扩展、适度失败，并最终产生单一的用户体验。这种编排正是 Kubernetes 的闪光点。

如果您预计在不久的将来会达到一定的成本或复杂性水平，那么考虑做出改变是值得的。我们希望这有助于澄清什么时候使用 Heroku 是合适的，什么时候团队应该考虑使用 Kubernetes。

要了解更多关于如何切换到 Kubernetes 的信息，请查看通过 GKE 从 Heroku 迁移到 Kubernetes。

面向 Kubernetes 的云托管服务如何帮助产品取得成功

原文：https://www.fairwinds.com/blog/how-cloud-managed-services-for-kubernetes-enable-products-to-succeed

很久以前，在 Kubernetes 出现之前，我正在管理一个完全在云中构建的早期安全产品。我们使用 SaaS 的商业模式来区别于传统的本地企业。

如今，许多公司为他们的新产品“默认”选择了云。但在当时，这并不是一个显而易见的选择。我们选择云是基于更低的前期成本、更高的安全性和可扩展性——所有这些对我们的产品战略都至关重要。我们公司是云技术的新手，所以在这个过程中，围绕最佳实践和模式有很多学习。

升级到下一个级别

产品的第一年是一段有趣的旅程。我们的使用量增长了 10 倍，发现产品/市场适合非常大的全球企业客户。SaaS 的价值主张正在发挥作用，但我们最不可行的基础设施已经达到了极限。我们为前 10 个客户做出的一些设计决策并不适用于接下来的 100 个客户。我们最初利用 PaaS 服务和一些自主开发的自动化来将软件推向市场，但支持销售和我们雄心勃勃的增长计划意味着将路线图的很大一部分分配给基础设施投资。

我们面临的任务是平衡早期采用者客户的功能需求和可靠高效扩展的内部需求。可靠且可扩展的基础架构是我们客户的基本期望，而运行高效的工作负载是维持高毛利润的必要条件。简而言之，我们无法回避这些基础设施投资；但是，作为产品负责人，我希望尽可能快速、经济地“解决”这个问题，这样我们的工程团队就可以专注于让我们与众不同的新功能。执行风险是我们进入市场和保持竞争力的主要风险因素。

你把时间和资源花在哪里很重要

作为一个产品高管，上面的故事是不是听起来很耳熟？在你的职业生涯中，你面对过多少次这样的挑战？

说到软件，一切都比你最初计划的要花费更长的时间，需要更多的资源。学习最佳实践通常是通过反复试验来完成的，其方式是您不容易预测的。问题是——这个学习过程最终会让你在市场上获得不公平的优势吗？也就是说，你能学到一些新的独特的东西来取悦你的顾客并使你的产品与众不同吗？

公司在迁移到 Kubernetes 时也面临着类似的问题。Kubernetes 是云基础设施的下一个范式转变，使企业能够接受云原生应用程序开发。虽然 Kubernetes 提供了巨大的灵活性，但该技术仍然非常新，学习曲线很陡。

如今，构建 Kubernetes 集群的自动化程度越来越高。从技术上来说，你可以用越来越少的步骤让你的应用程序在 Kubernetes 上运行。这对社区和技术来说是一件好事，但是许多团队低估了概念验证和生产级基础设施之间的区别。

面向 Kubernetes 的云托管服务

托管的 Kubernetes 服务，如 Google Cloud 上的 GKE、AWS 上的 EKS 和 Microsoft Azure 上的 AKS，是生产级 Kubernetes 基础设施的重要组成部分。尽管这些服务的名称中使用了“托管”一词，但产品主管应该明白，这些并不是您可能期望的“完整产品”解决方案。

正如 Gartner 所强调的，许多利用云服务的公司往往低估了共享责任模式的范围。您的团队可以快速吸收路线图时间来处理以下事项:

为 Kubernetes 编写部署文件
构建遵循最佳实践的可靠部署工作流
为安全性和可靠性配置 Kubernetes 部署
优化工作负载以提高效率
配置和调整监视器
对警报做出反应，建立随叫随到的轮换制度，而不会让你的团队精疲力竭
构建内部工具来维护模式和一致性

我希望在我管理早期安全产品时，就有类似于 ClusterOps platform 的云管理服务。云托管服务是降低执行风险的经济高效的方法，因此您的组织可以通过 Kubernetes、容器和持续部署最佳实践取得成功。

Fairwinds Insights 如何帮助您识别 log4j 容器漏洞

原文：https://www.fairwinds.com/blog/how-fairwinds-insights-can-help-you-identify-log4j-container-vulnerabilities

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

随着 2021 年的临近，我们花费了大量时间来确定基础设施是否受到影响。你可以在我们的开源工具和洞察平台这里阅读 Fairwinds 的声明。

识别容器漏洞

如果您是 Kubernetes 用户，并且需要了解您是否存在 log4j 容器漏洞，Fairwinds 可以提供帮助。Fairwinds Insights 是护栏和治理软件，允许负责 Kubernetes 的团队识别容器漏洞并提出补救建议。

Fairwinds Insights 将根据包括 log4j 在内的已知 CVE 扫描您的集装箱。如果集装箱存在风险，Insights 将创建一个行动项目。

您可以看到受影响的容器的详细信息以及严重性——在本例中是严重的。然后，用户可以升级到最新的固定版本。Insights 将持续扫描以识别更多 log4j 漏洞(以及其他漏洞)。

团队领导可以使用 Fairwinds Insights 监控跨团队和多个集群的容器健康状况。

Kubernetes 安全和 Fairwinds 洞察:开始行动

您现在可以使用 Fairwinds Insights 来帮助您的团队识别 log4j 容器漏洞。它可以免费使用——你可以在这里注册。您将确认您的电子邮件，建立一个新的组织，然后能够向该组织添加集群和同事。

有三种方式与 Fairwinds Insights 联系:

持续集成功能可以通过扫描您的基础设施代码来报告拉请求期间的问题
准入控制器阻止有严重问题的资源进入集群
集群内代理报告已经部署到集群的资源的问题

识别 log4j 容器漏洞的最快方法是安装集群内代理。您可以在 Fairwinds Insights 文档中了解更多信息。

不要让你的容器抓住你。使用 Fairwinds Insights 确保 Kubernetes 的安全。

Fairwinds Insights 合规性自我评估如何简化 SOC 2

原文：https://www.fairwinds.com/blog/how-fairwinds-insights-compliance-self-assessment-now-simplifies-soc-2

我们的安全和治理软件,fair winds Insights帮助负责合规的经理自动化、监控和执行政策护栏。今天，我们很高兴地宣布，Fairwinds Insights 为我们的 SaaS 客户提供了更多的服务。我们针对 SOC 2 的最新功能 Fairwinds Insights 合规性自我评估为开发团队提供了 30 多个评估问题，重点关注 Kubernetes 中的 SOC 2 合规性。对于运营团队来说，理解 Kubernetes 和容器的遵从范围可能是一个挑战。利用这一新功能，用户可以跟踪每个控制的合规状态，获得关于如何正确配置 Kubernetes 的建议，自动验证配置和自我认证。

使用 Kubernetes 和容器的受监管行业需要从一开始就遵循法规，在整个过程中纳入可见性和控制。我们解决方案的广度是独一无二的；现在，DevSecOps 团队可以从单一平台上自我评估 SOC 2 合规性和访问安全监控、应用合适的规模、成本优化、策略实施和服务所有权。

关于 SOC 2 的一切

对于那些不知道的人，系统和组织控制(SOC 2)是一个审计流程，用于评估组织安全管理其在开展业务时收集和利用的数据的能力。SaaS 公司可以通过进行 SOC 2 审计来证明其满足安全标准的能力。这一举措为潜在客户提供了他们需要的信息，使他们能够放心地与您的公司共享他们的数据(可能还有客户数据)。

SOC 2 审计涵盖根据组织用于支持五个信托服务标准的信息和系统来评估组织，这五个标准是:

安全性
有效性
完整
机密
隐私

如今，SOC 2 不再仅仅是一个好东西，它对于需要展示客户和合作伙伴信任的现代组织来说是绝对必要的。也就是说，在 SOC 2 审计过程中导航可能是一项艰巨的任务。合规性对于在云原生和 Kubernetes 环境中维护业务连续性和满足 SOC 2 要求至关重要。但是因为容器本质上是短暂的，确定一个环境是否兼容可能是棘手的。Kubernetes 的动态特性也可能在组织试图实现治理和法规遵从性措施时产生问题。

三个新功能

面向 SOC 2 的全新 Fairwinds Insights 合规性自我评估包括三个需要记住的主要特性，所有这些特性都将帮助我们的客户保护和支持开发人员:

通过多集群可见性了解多个集群的状态和合规性标准(HIPAA 和 ISO27001，以及 SOC 2)。
绘制 SOC 2 控制图使用 30 多个与 Kubernetes 相关的 SOC 2 评估问题来证明每个控制的合规性，同时为审计员生成 pdf。
实现并向利益相关方证明符合关于 Kubernetes 配置和法规合规性的建议。

针对 SOC 2 的 Fairwinds Insights 合规性自我评估将包括自动验证，以检测工作负载是否配置正确。这些信息有助于用户满足特定的控制要求，并提供自动化的合规性证据。

提高合规性的步骤

合规流程的具体时间框架很难确定，主要是因为每个组织都是独一无二的。此外，SOC 2 是一个灵活的框架，而不是一套需要遵循的硬性规则。每个企业都有不同的起点，每个企业都会选择以自己的方式解释和应用安全标准。

但是根据我们自己使用 SOC 2 的经验，这个过程的速度取决于几个因素，包括你的组织的规模；您现有流程和政策的成熟度；涉及的人数；你选择纳入的标准，以及高管的认同程度。

想了解更多信息？

了解我们的 Fairwinds 团队如何共同努力获得 SOC 2 认证！

FAIRWINDS SOC 2 报告

来自 LLP Dansa D ' arata Soucia 的官方审计报告对 Fairwinds Insights 软件平台和托管服务的内部控制、政策和流程进行了全面审查。它还审查了 Fairwinds 与风险管理和子服务(供应商)尽职调查有关的流程，以及该公司的整个信息技术基础设施、软件开发生命周期、变更管理、逻辑安全、网络安全、物理和环境安全以及计算机操作。我们发现这个过程很有帮助，也很有启发性；当我们的客户与我们合作提供服务或使用我们的 Fairwinds Insights 平台时，SOC 2 - Type I 报告可以让他们高枕无忧。

Fairwinds Insights 如何帮助您节省云成本

原文：https://www.fairwinds.com/blog/how-fairwinds-insights-helps-you-save

容器技术超越虚拟机的一个原因是，可以在主机上放置更多的容器，从而减少计算实例的总数，并节省基础设施成本。但是，如果您使用带有 Kubernetes 的容器，则可以通过设置合理的 CPU 和内存请求以及对 pods 的限制来进一步提高效率，这将允许您将更多的工作负载打包到工作节点上。

如何启用资源建议

到目前为止，收集 Kubernetes 工作负载效率数据的工具很难安装和使用，但 Fairwinds Insights 让您可以访问我们的工具 Goldilocks，帮助您“恰到好处地”获得 pod 资源请求如果您想查看 Kubernetes 集群的资源建议，请遵循以下说明:

一旦您注册了 Fairwinds Insights 公共测试版计划，请登录insights.fairwinds.com，创建一个新组织，并按照安装说明在您的集群中安装 Fairwinds Insights。
回到您的组织，选择您希望看到哪个集群的金发女孩推荐。
转到“报告”选项卡，在 Goldilocks 旁边，单击“最新报告”。您将看到一个类似于这里的仪表板:https://raw . githubusercontent . com/FairwindsOps/Goldilocks/master/img/screen shot . png

仪表板显示了 Goldilocks 正在评估的名称空间和部署的列表。该工具在推荐模式下使用 Kubernetesvertical-pod-auto scaler，如果您当前设置了 CPU 和内存请求和限制，您将在“当前”列中看到这些值。最有价值的数据在“建议更改”框中，它显示了成功运行 pods 所需设置的最小 CPU 和内存量。我们已经看到，我们的许多客户将其 CPU 和内存请求和限制设置得太高，当他们应用这些建议时，他们能够在更少的 Kubernetes 工作节点上放置更多的 pod。启用 cluster-autoscaler 后，任何多余的节点在未使用时都会被删除，从而为您节省资金。

了解你的工作量平衡

Goldilocks 的另一个好处是，它可以让您知道您的工作负载是 CPU 密集型、内存密集型还是两者之间的平衡。这些数据可以帮助您评估是否为 Kubernetes 工作节点选择了最有效的机器类型。

几个月前，我们为一家客户生成了一份 Golidlocks 报告，我们发现他们的一个部署生成了几乎不使用 CPU 但使用大量内存的 pod。我们最初将他们的 Kubernetes 集群设置为仅使用一种 AWS 实例类型:m5.xlarge。这些机器旨在实现计算、内存和网络资源之间的平衡，但由于它们最大的 pod 部署是内存密集型应用程序，我们寻找一种具有更多内存资源但 vCPUs 较少的 AWS EC2 实例类型。我们最终将他们的一些 worker 节点改为 r5.xlarge 实例。r5.xlarge worker 节点上安装了更多这样的内存密集型 pod，这些实例类型比原来的便宜 36%,为该客户节省了资金，并减小了他们的 Kubernetes 集群的规模。

如果你对机器类型感兴趣，以下是三大云提供商的规格:

总之，我们的 Fairwinds Insights 套件中的工具 Goldilocks 可帮助您和您的团队设置基于数据的 CPU 和内存请求和限制，这最终可以提高您使用云基础架构的效率，减少 Kubernetes 集群的蔓延，并为您节省资金。

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

Kubernetes 如何帮助电子商务公司在黑色星期五和网络星期一保持盈利

原文：https://www.fairwinds.com/blog/how-kubernetes-helps-e-commerce-companies-stay-profitable-on-black-friday-and-cyber-monday

对零售和电子商务公司来说，成功运营黑色星期五和网络星期一是一个重大胜利。对于一些企业来说，这一天产生的交易数量相当于一个月或更长时间的销售额。然而恐怖故事比比皆是。去年，由于网站崩溃， J. Crew 在黑色星期五的销售额中损失了大约 70 万美元。

幸运的是，云计算使电子商务企业能够通过弹性计算和按需供应基础设施资源来满足需求。在本帖中，我们讨论一些不同的架构和技术考虑，电子商务公司可以追求运行一个有效和可靠的黑色星期五/网络星期一活动。

微服务架构

微服务架构为电子商务平台提供了许多好处。通过将应用程序分成更小的部分，开发团队可以逻辑地分割功能——这有助于使开发和测试过程更加高效。从开发的角度来看，团队可以在代码库的不同部分工作，而不会互相影响。例如，产品搜索、产品详情和购物车功能都可以构建为自己的微服务。

从测试的角度来看，微服务强调定义输入和输出。服务通过 API 调用相互交互，为数据和事务如何通过整个系统建立契约。

集装箱

容器是打包微服务并使它们准备好部署在任何计算平台或云上的好方法。这种可移植性很重要，尤其是对于可能需要更换云提供商的电子商务公司。这种避免“供应商锁定”的能力非常重要，尤其是当云提供商可能拥有与电子商务公司直接竞争的子公司或相邻企业时。

容器还提供了运行应用程序的一致方式。通过抽象出底层操作系统，开发人员可以避免故障排除，并调试特定于环境或特定于运行时的问题。

最后，容器是不可变的。容器在运行时不会改变；相反，如果它遇到错误或需要更新，就必须删除它，并部署新的容器来替换它。

您可以想象一个场景，在黑色星期五期间，在产品搜索页面上发现了一个 bug。如果功能在自己的微服务和容器中，工程师可以简单地推出一个新的容器版本，修复错误，而不必关闭整个网站，也不必中断数百或数千个有价值的用户会话。

Kubernetes

Kubernetes 不仅是事实上的容器编排，也是根据需要扩展和缩减计算资源的有效解决方案。Kubernetes 提供了一些不同的自动扩展功能，允许智能复制容器组(称为 pod)，以及增加和减少运行站点所需的计算实例的数量。

虽然 Kubernetes 自动处理许多后台缩放活动，但掌握这些配置需要一个学习过程。有时，工程团队忽略了提供这些配置，当出现不可预测的流量时，会带来停机风险。

Fairwinds 最近推出了一款新的开源工具，名为fair winds Goldilocks，帮助工程师设置正确的资源请求和限制。这些设置通知 Kubernetes 所需的 CPU 和内存范围，帮助 Kubernetes 知道何时向外扩展。

Framebridge，Kubernetes 前后

为了深入了解，我们采访了世界领先的定制镜架零售商和 Fairwinds 的客户, Framebridge 的工程副总裁 Brock Wilcox。

布洛克估计，在黑色星期五和网络星期一期间，网络流量有时会增加两倍。在实施 Kubernetes 之前，团队会通过先发制人的过度供应来解决这个问题，这会使生产成本翻倍。

Brock 注意到的一个关键改进是，他的工程师们能够对应用程序进行改进，为黑色星期五做准备。Framebridge 能够在试运行环境中隔离和测试新功能。不仅部署时间缩短，而且部署完全自动化。如果在部署新功能后出现问题，回滚只需要 60 秒，这样团队就不那么厌恶风险了。

完全托管的 Kubernetes

Kubernetes 提供了可靠和高效生产操作的双重优势。对于像黑色星期五这样的活动，电子商务公司保持“盈利”是很重要的。可靠也很重要。两者兼顾需要团队中有合适的专家。

全面管理的 Kubernetes 产品有助于在一个完整的订阅包中提供专业知识、监控、升级和安全补丁。像黑色星期五和网络星期一这样的事件通常意味着“所有人都在甲板上”，这可能会使开发人员远离有价值的路线图功能和创新。同类最佳的完全受管 Kubernetes 解决方案，如fair winds cluster ops，集成了 24x7 自动分页，因此您的开发人员无需在凌晨 3 点起床查看基础架构警报。

在选择 Kubernetes 时，您还需要考虑让您的工程师使用正确的开源工具。Fairwinds 提供了一套用于管理 Kubernetes 的开源软件——帮助您部署、运营和优化您的基础设施，以实现安全性、可靠性和效率。让我们知道你的想法和 fair winds 如何帮助你！

Kubernetes 如何改变医疗技术的面貌

原文：https://www.fairwinds.com/blog/how-kubernetes-is-changing-the-face-of-medical-technology

如今，医疗保健行业严重依赖软件技术来改善通信、提供更快的服务和降低总体成本。医疗技术(MedTech)是指各种医疗产品，包括用于治疗各种医疗状况和疾病的产品。医疗技术行业总是不断有新的进步和创新，这也是他们的技术基础设施如此重要的原因之一。它们必须可靠，而且必须安全。

医疗技术公司现在正在一个复杂的技术基础设施中操纵服务，该基础设施依赖于大量的应用程序来实现甚至最小的工作。因此，他们进行的任何新的应用程序部署都必须符合他们精心设计的技术环境。输入容器。

了解如何简化 Kubernetes 混沌。

Kubernetes，医疗技术和采用的挑战

医疗技术界以及越来越多的外部组织现在转向 Kubernetes 和 containers 来解决他们的技术复杂性问题。因此，MedTech 越来越依赖 Kubernetes 来正确管理和连接其所有的集装箱化工作负载和服务，并最大限度地减少停机时间。容器和 Kubernetes 的可移植性也支持不同的部署模型，比如 SaaS/多租户或自托管/单租户选项。也就是说，这不一定是一件容易的事情。

虽然 Kubernetes 现在被认为是容器管理的黄金标准，但 MedTech 的很大一部分仍在努力如何有效地实施该平台，这通常是由于资源和合规性问题。但专家表示，如果这些医疗科技公司能够克服 Kubernetes 采用的障碍，他们可能会发现集装箱化实际上可以增加他们的创新，并使他们能够快速安全地建立符合 HIPAA 的医疗保健解决方案。

如果有一个地方更大的开发灵活性和连续性很重要，那就是医疗保健领域。组织面临着越来越大的压力，既要快速创新，保持以客户为中心，又要最大限度地减少任何停机影响的机会。是的，Kubernetes 仍然是一项年轻的技术，但更深入的研究表明，它可以通过提供更好的安全性、更快的应用程序部署、更低的成本和整体可扩展性来帮助医疗技术公司进行创新。

通过自动化应用测试和加快 Kubernetes 的部署，MedTech 可以缩短上市时间，并提高生产管道的透明度。此外，系统管理员可以通过 Kubernetes 平台轻松执行关键操作，比如在应用程序需要更新时克隆容器。通过这种方式，更有效地平衡传入负载意味着 MedTech 可以更好地利用其物理资源。这种技术能力不仅减少了停机时间，而且在许多情况下可以完全消除停机时间。

合规性和安全性问题

尽管容器化应用为医疗技术领导者提供了一系列机会，但在面临大量监管和合规障碍的情况下实施这些应用是很困难的。这可能会让技术团队在增长和创新或安全性和合规性之间做出艰难的选择。但是有了 Kubernetes，医疗技术组织可以一次完成所有这些目标。

恶意软件和操作系统补丁是医疗技术领域的大问题。再加上超级敏感的患者信息，很容易想象他们面临着多少令人头疼的安全问题。由于每次新版本的应用程序发布时，现有的集群都会被销毁(并重新部署新的节点和集群)，因此系统管理员不需要经常检查是否出现了安全补丁、操作系统是否是最新的，以及底层基础架构上是否隐藏了恶意软件。

虽然实施像 Kubernetes 这样的新技术可能会让医疗保健领域的技术领导者望而生畏，但 Kubernetes 可以通过自动化极大地减少人为错误。该平台本身具有自我监控和自我修复功能，这两项功能有助于最大限度地减少操作漏洞。由于 Kubernetes 为数据保护提供了一个安全的框架，容器化应用程序有可能为 MedTech spaces 提供所需的安全性和合规性，以确保患者能够继续获得越来越广泛的个人健康数据。

费尔温德见解

对于医疗保健技术领导者来说，降低风险、确定可靠性差距和提高资源利用率的软件需求至关重要。fair winds Insights是 Kubernetes-native 软件，它持续扫描集群，以确保应用程序快速交付，并根据规模、可靠性、资源效率和安全性进行配置。

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

Insights 平台提供成本优化建议、安全警报、配置护栏和合规性调查结果。DevOps 团队可以识别错误配置，并向开发人员提供补救建议，无需手动识别问题。软件工程师可以自由地开发平台想要的方式——有了安全网。

了解有关 Fairwinds Insights 的更多信息，以及它如何为您的组织带来改变。我们的解决方案建立在 Kubernetes 的专业知识之上，集成了我们领先的开源工具，帮助您节省时间、降低风险并放心部署。

北极星突变:它是如何工作的

原文：https://www.fairwinds.com/blog/how-polaris-kubernetes-mutations-work

在过去的三年里， Polaris 已经允许 Kubernetes 用户审计他们的集群和基础设施作为最佳实践的代码。它带有 20 多个内置检查，并支持使用 JSON 模式的定制检查。它可以查看正在运行的集群内部以查找有问题的资源，作为准入控制器运行以阻止具有高严重性问题的资源，或者作为 CI/CD 过程的一部分运行以扫描基础架构代码。

但是解决北极星发现的问题可能会很乏味。您必须查找修改需要更改的特定属性的语法，并编辑每个需要改进的基础设施代码文件。如果您的代码分布在许多存储库或团队中，这尤其困难。新的 YAML 文件一直在创建，这意味着无论是谁负责实施最佳实践，都会有源源不断的工作要做。

为了帮助解决这个问题，我们在北极星中建立了一个突变的概念。突变精确地指定了需要对 YAML 的一部分做什么来使它符合最佳实践。变异可以在基础设施代码文件上运行，因此可以将更改签入到您的存储库中，或者可以作为变异的 Webhook 运行，在资源进入您的 Kubernetes 集群时对其进行修改。了解实际应用。

突变语法

Polaris 利用 JSON 模式来决定特定资源是否符合最佳实践。例如，确保未配置 hostIPC 的检查如下所示:

successMessage: Host IPC is not configured
failureMessage: Host IPC should not be configured
category: Security
target: PodSpec
schema:
  '$schema': http://json-schema.org/draft-07/schema
  type: object
  properties:
    hostIPC:
      not:
        const: true

要解决 hostIPC 的问题，我们只需从 YAML 中移除该字段。因此，我们可以在上面的 YAML 中添加一个突变模块，如下所示:

mutations:
  - op: remove
    path: /hostIPC

这里的语法是 JSON 补丁，一个用于修改 JSON(或 YAML)数据的 IETF 标准。

值得注意的是，并不是每一个突变都是现成的。例如，活性和就绪性探测需要根据您的应用程序进行定制。但是 Polaris 至少可以做出猜测，让您更容易填写它们，而不必翻遍 Kubernetes 文档。为了明确这一点，Polaris 可以添加一个注释，提示用户进行进一步的修改。下面是向活性探测检查添加注释的语法:

mutations:
  - op: add
    path: /livenessProbe
    value: {"exec": { "command": [ "cat", "/tmp/healthy" ] }, "initialDelaySeconds": 5, "periodSeconds": 5 }
comments:
  - find: "livenessProbe:"
    comment: "TODO: Change livenessProbe setting to reflect your health endpoints"

所有这些语法都可以在 Polaris 自定义检查中找到。因此，如果您已经构建了一个自定义检查库，或者正计划创建一些库，那么您可以在创建时添加一些变化！

在基础设施即代码上运行突变

polaris fix 命令将允许您修改基础设施代码文件，以便它们遵循最佳实践。

例如，如果我们从这个最小配置开始，直接从 Kubernetes 文档复制:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

我们可以运行北极星修复文件路径。/deploy . YAML-checks = runasroot allowed获取:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        securityContext:
          runAsNonRoot: true

请注意，该配置现在有了一个 securityContext ，并被设置为以非 root 身份运行。

或者，如果我们想看看Polaris 能用这个文件做的一切，我们可以运行 polaris fix - files-path。/deploy.yaml - checks=all 获取:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.2
        imagePullPolicy: Always
        livenessProbe: #TODO: Change livenessProbe setting to reflect your health endpoints
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 5
          periodSeconds: 5
        name: nginx
        ports:
        - containerPort: 80
        readinessProbe: #TODO: Change livenessProbe setting to reflect your health endpoints
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 5
          periodSeconds: 5
        resources:
          limits:
            cpu: 100m #TODO: Set this to the amount of CPU you want to reserve for your workload
            memory: 512Mi #TODO: Set this to the amount of Memory you want to reserve for your workload
          requests:
            cpu: 100m #TODO: Set this to the amount of CPU you want to reserve for your workload
            memory: 512Mi #TODO: Set this to the amount of Memory you want to reserve for your workload
        securityContext:
          capabilities:
            drop:
            - ALL
          readOnlyRootFilesystem: true
          runAsNonRoot: true

请注意，北极星加强了安全性，并设置了一些字段，如健康探针和资源设置。如上所述，您可以在一些设置旁边看到注释，这些设置应该由用户进行微调，而不是照原样接受。

启用变异 Webhook

更改所有的基础设施代码文件可能会很乏味，即使有 polaris fix 命令帮助填补空白。当创建新的部署文件时尤其如此——很难跟上！

对于一些突变，当对象进入集群时，简单地修改它们更容易。一个很好的例子是imagePullPolicy——Polaris 建议将此设置为 Always ，如果你这样做，你可以确信不会有任何问题。

要启用变异的 Webhook，你可以通过舵图安装北极星。确保添加以下配置来启用 webhook:

webhook:
  enable: true
  mutate: true

默认情况下，对突变启用的唯一检查是 pullPolicyNotAlways 。如果你想启用其他突变，你可以编辑北极星配置的突变部分:

webhook:
  enableMutation: true
  mutatingRules:
  - cpuLimitsMissing
  - cpuRequestsMissing
  - dangerousCapabilities
  - deploymentMissingReplicas
  - hostIPCSet
  - hostNetworkSet
  - hostPIDSet
  - insecureCapabilities
  - livenessProbeMissing
  - memoryLimitsMissing
  - memoryRequestsMissing
  - notReadOnlyRootFilesystem
  - priorityClassNotSet
  - pullPolicyNotAlways
  - readinessProbeMissing
  - runAsPrivileged
  - runAsRootAllowed

未来的改进

我们对在 Polaris 中实现突变的进展感到非常兴奋，但也有一些限制。在接下来的几个月里，我们将努力从几个方面改进这一功能:

修改头盔模板的能力:目前北极星修正命令只适用于原始的 YAML 文件，不适用于头盔模板。关于如何让北极星修复在更广泛的环境中工作，我们有一些想法。
保留注释和格式:Polaris fix命令反序列化、修改和重新序列化 YAML，一些修饰性的功能在翻译中丢失了。例如，注释被删除，字段顺序可能会改变。我们正在努力改善这种体验。
更多突变:目前并不是每个检查都有突变。当前的 JSON 补丁语法有一些限制，例如在修改数组内容时。我们还希望支持多资源检查的突变，例如，如果不存在 PDB，则创建一个。

如果您尝试一下当前的实现，我们很乐意听到您的反馈！你可以在 Fairwinds 社区 Slack ，我们的开源用户组，或者在 GitHub 上找到我们。

资源

Fairwinds 团队如何合作获得 SOC 2 认证

原文：https://www.fairwinds.com/blog/how-the-fairwinds-team-worked-together-to-receive-soc-2-certification

服务组织控制，通常称为 SOC，有两种类型:SOC 1 和 SOC 2 报告。SOC 1 报告适用于为客户处理财务信息的企业；这些类型的企业被称为服务机构。SOC 1 报告向您的客户保证，您的组织拥有适当的控制措施来保护他们的财务信息。SOC 2 报告处理您的组织与运营和合规性标准相关的控制。

SOC 2 是由美国注册会计师协会(AICPA)开发的服务组织自愿遵守的标准，它规定了组织应该如何管理客户数据。该标准基于以下信任服务标准(TSC):安全性、可用性、处理完整性、机密性和隐私性。I 类报告允许审计员执行风险评估，并让组织知道他们可以执行关键的评估程序。第一类报告描述了一个组织的系统，并测试控制如何在选定的日期实现特定的目标。SOC 2 审计侧重于服务组织的非财务报告控制，因为它们与系统的安全性相关。

Fairwinds 的审计是由 www.darata.com 的 LLP 公司进行的。在此过程中，Fairwinds 始终坚持服务公司最严格、行业公认的审计标准之一。它“通过独立审计师向客户提供额外的保证，即其业务流程、信息技术和风险管理控制措施设计得当。”

我们选择完成 SOC 2 报告的流程，以向我们的客户展示我们有适当的控制措施来降低与我们提供的服务相关的风险。Fairwinds 首席执行官比尔·莱丁汉姆(Bill Ledingham)表示，“我们为客户提供的价值的一个关键部分是为他们提供护栏和治理来简化 Kubernetes 的复杂性。我们也将治理应用到我们的业务运营中，这才是有意义的。”我们的团队努力确保我们符合SOC 2 Type 1，我们将继续保持合规性。

因此，我们已经启动了 SOC 2 Type 2 审核流程，以持续证明其合规性。为了帮助其他人了解我们是如何快速实现合规的，我们分享了我们的一些流程以及我们的团队如何共同努力使一切顺利进行。

安迪·苏德曼，R&D 技术总监

有几个选择使这个过程变得容易得多。我们与 Kintent 合作，这使得回答安全问卷和与客户分享我们的安全和合规计划变得简单。Kintent 还通过使用 API 自动执行程序和测试我们的控制和政策，帮助我们完成了合规性认证。

对 Fairwinds 来说，经历 SOC 2 流程是一个很好的机会，可以将我们已经到位的许多流程进行整理。这对我们来说是一个很好的机会，可以确保这些过程被很好地记录下来以供内部使用。

我们发现了一些需要改进的地方，无论我们是否在进行 SOC 2 认证，其中许多地方都符合最佳实践。我们在 Fairwinds Insights 中推荐的许多最佳实践是我们需要在自己的基础设施中遵循的:

整个过程为我们提供了一个绝佳的机会来审查我们自己的所有内部控制，以及我们继续构建到我们的 Fairwinds Insights 平台中的内部控制。

罗伯特·布伦南，开源软件总监

让我们的应用和开发过程符合 SOC 2 标准需要做大量的工作，但是绝对值得。大部分的变化来自两个大的方面:安全扫描和开发过程。

在安全性方面，我们已经做了相当多的工作——例如，我们使用容器扫描来查找 Docker 映像中的已知 CVE，并使用自动 PRs 来保持我们的依赖关系最新。但是为了完全符合 SOC 2，我们增加了:

静态代码分析——这有助于确保我们不会给 SQL 注入带来机会，甚至有助于我们发现一些未处理错误的地方。
OWASP 扫描-我们现在扫描每一个部署的常见 OWASP 相关问题，如点击劫持或跨站点脚本的漏洞。
渗透测试——我们现在聘请第三方对我们的应用进行年度渗透测试。最初的 pentest 发现了一些有趣的(但谢天谢地是次临界的)发现

但是最有影响的变化是我们的开发过程。虽然我们已经在票务系统中跟踪我们的工作，并通过代码审查进行了所有的更改，但一些更改(例如小的修复)从未进入票务系统。SOC 2 迫使我们将这个过程形式化。现在，每个拉取请求都必须链接到一个票证(由我们的 CI 系统强制执行)，并且从一个版本到另一个版本，对更改进行一致的跟踪、审查和质量保证。

通过 SOC 2 需要做大量的工作，但结果是我们对应用的安全性和稳定性更有信心了。

首席财务官玛丽·亨利

我们的团队通过确保密切合作，非常有效地实现了公司 SOC 2。我们有一个完成工作的小团队，每周召开会议，根据 SOC 2 - Type I 报告的要求跟踪我们的进展。

我们从在过程早期快速识别系统和每组控制的所有权开始。这帮助我们从一开始就建立了正确的团队，所以我们可以加快步伐。我们也很早就确定了长期领先的项目。差距分析本身通常从头到尾需要两到四周的时间，帮助我们确保我们有核心政策、一致的员工背景调查、确保密码复杂性的系统(我们为所有员工推出了一个密码管理器来帮助他们管理复杂的密码)，并确保我们有适当的雇佣协议。我们还更新了员工手册，这是一项意义重大的工作。实现 SOC 2 合规的一个主要经验是，所有政策和程序都需要在整个组织内保持一致。

fair winds SOC 2-I 型报告

我们来自 LLP Dansa D ' arata Soucia 的官方审计报告对 Fairwinds Insights 软件平台和托管服务的内部控制、政策和流程进行了全面审查。它还审查了 Fairwinds 与风险管理和子服务(供应商)尽职调查相关的流程，以及该公司的整个 It 基础设施、软件开发生命周期、变更管理、逻辑安全、网络安全、物理和环境安全以及计算机操作。我们发现这个过程很有帮助，也很有启发性；当我们的客户与我们合作提供服务或使用我们的 Fairwinds Insights 平台时，SOC 2 - Type I 报告可以让他们高枕无忧。

如何在您的 Kubernetes 集群中采用 Istio

原文：https://www.fairwinds.com/blog/how-to-adopt-istio-into-your-kubernetes-clusters

最近，Istio 受到了很多关注。服务网格平台最近达到了 1.0 生产就绪里程碑。谷歌一直在戏弄谷歌云上的托管 Istio 选项。在 Kubernetes 集群中有足够的资源让它运行。

你可能已经经历了科技炒作周期的各个阶段:

什么是服务网格？
哇哦。服务网有点复杂。我真的需要一个吗？
好的。我可以看到一些使用案例。完成这个“Istio Up&15 分钟跑完”演示需要多少天的时间？

现在，您已经实际上为您现有的 Kubernetes 托管应用程序设置了 Istio。那要比 15 分钟长得多。这篇文章将告诉你如何将 Istio 引入你的 Kubernetes 集群。

Istio 到底是什么？

如果没有别的，你可能听说过 Istio 是一个服务网格。“服务网格”是一个奇特的术语，指的是处理一组连接服务之间常见通信挑战的工具。

在现实世界中，Istio 的架构建立在 Kubernetes 的基础上，增加了:

用于服务之间的识别、授权和加密通信的相互 TLS。
使用选择性白名单限制出站流量。
动态流量分布模式，如并发应用程序版本和渐进的金丝雀式部署。
通过断路器、重试处理、故障转移和对“混乱猴子”式故障注入测试的支持来提高弹性。
说明沟通模式和绩效的大量额外指标。

Istio 的架构通过在每个 pod 中运行一个单独的代理 sidecar 容器来实现这一切。一组核心服务在您的集群中运行，并与这些代理边盘通信，以实现上述功能。

电脑:给我安装一个 Istio

Kubernetes 上首选的 Istio 架构安装方法是舵图。请注意， Istio 掌舵图嵌入在 Istio Github 回购中。这是不可通过官方社区舵图表回购。

该图表安装了 Istio 运行所需的一组核心服务。它通过图表值提供了广泛的定制。它还支持升级到新的 Istio 版本。

在开始安装 Istio 之前，请继续阅读，了解一些在 Kubernetes 上安装和运行时特有的优势。

你想如何在你所有的豆荚里安装边车代理？

你所有的豆荚都需要一个边车代理容器。Istio 可以将这个代理容器自动注入到新的 pod 中，而无需对部署进行任何更改。默认情况下该特性是启用的，但是它需要 Kubernetes 或更高版本。

您需要标记名称空间以启用边车注入:

$ kubectl create namespace my-app
$ kubectl label namespace my-app istio-injection=enabled

Istio chart 安装不会影响现有的 pod。在带标签的命名空间中启动的 pod 将接收 sidecar，而在其他命名空间中启动的则不会。这为安装 Istio 的核心服务和有选择地将 pod 转移到网格中提供了一条途径。

您将如何将服务过渡到互助 TLS？

Mutual TLS 是一个有吸引力的安全特性，因为它限制了哪些服务可以相互通信，并且它对通信进行加密。但是，当您在转换服务时，它们需要与网格外部的资源进行通信，这可能会成为绊脚石。

为了简化这种转换，考虑启用许可模式认证策略。许可模式为服务启用明文 HTTP 和 mTLS 流量。该策略可以在网格策略中应用于集群范围，使用默认策略应用于每个命名空间，或者使用更细粒度的策略来针对单个服务。一旦您的应用程序完全迁移到 Istio，您就可以禁用许可模式并强制实施相互 TLS。

另一件要注意的事情是，典型的 Kubernetes HTTP 活跃度和就绪性探测在 mTLS only 模式下不起作用，因为探测来自服务网格之外。这些检查将在许可模式启用的情况下进行。一旦您取消许可模式，您将需要将探头转换为执行检查，以轮询 pod 内部的健康检查，或者在禁用 mTLS 的情况下在单独的端口上建立健康检查端点。

以下是创建网状策略的方法，该策略使整个集群的 MTL 处于许可模式:

cat <<EOF | kubectl apply -f -
apiVersion: “authentication.istio.io/v1alpha1”
kind: “MeshPolicy”
metadata:
  name: “default”
spec:
  peers:
  — mtls:
      mode: PERMISSIVE
 EOF

您想在启用出口筛选的情况下开始吗？

默认情况下，Istio 会限制您的 pod 的出站流量。这意味着，如果您的 pod 与网格外部的服务进行通信，如云提供商 API、第三方 API 或托管数据库，流量将被阻止。然后，您可以使用 ServiceEntries 有选择地启用对外部服务的访问。

从表面上看，出口过滤似乎是一个有吸引力的安全功能。然而，它的实现方式并没有提供真正的安全优势。正如 Istio 的一篇文章中所解释的，没有任何机制可以确保被过滤的 IP 与名称相匹配。这意味着只需在 HTTP 请求中设置一个主机头就可以绕过过滤。

此外，作为现有应用程序的起点，出口过滤可能很困难。或者，您可以使用全局包含入口设置在集群级别禁用出口过滤。通过将此设置为集群的内部 ip 空间，您将绕过 Istio 代理处理所有外部流量。一旦在 Istio 中运行了服务，您就可以识别外部服务，并在打开出口过滤之前构建所需的服务条目。

以下头盔安装将完全禁用所有吊舱的出口过滤。您应该将内部集群 IP CIDR 添加到 includeIPRanges 设置中，以便通过 Istio 将流量从 pod 路由到内部资源，同时完全绕过外部端点。使用这两种配置中的任何一种，您都不需要为访问外部端点定义任何 ServiceEntries。

$ helm upgrade install/kubernetes/helm/istio — install \
  --name istio — namespace istio-system \
  --set global.tag=”1.1.0.snapshot.1" \
  --set global.proxy.includeIPRanges=””

Istio 在设计上并不完全是 Kubernetes 本地的

毫无疑问，Istio 为 Kubernetes 上的部署提供了大量资源。有一个舵图表，其中有一系列子图表，用于安装大量与 CRD 相关的服务。有大量的文档和示例图表配置。然而，Istio 的目标是独立于平台。考虑到这一点，在 Kubernetes 上部署支持 Istio 的应用程序有一些明显的不同。

最有影响力的差异之一在于在 Istio 网格之外公开服务。一个典型的 Kubernetes 应用程序使用一个连接到入口控制器的入口来公开一个外部接口。相反，Istio 依赖于一个网关对象来定义协议设置，比如端口和 TLS。网关对象与虚拟服务对象配对来控制路由细节。

这可能会影响您已经为入口对象(如域名和 TLS 证书管理)建立的模式。外部 dns 项目最近引入了对 Istio 网关对象的支持，使得从入口对象到自动域管理的过渡更加容易。

网关的 TLS 证书故事仍然有些复杂。Istio 的 IngressGateway 不支持与 cert-manager 兼容的多种证书，后者是一种从 Kubernetes 中自动提供和安装 TLS 证书的流行方式。证书更新需要滚动ingress gatewaypod，这使得事情更加复杂。这使得在不按计划手动滚动 pod 的情况下，很难使用短期 Let 加密证书。即使使用静态证书，网关也会在启动时安装所有证书，因此为附加服务添加和删除证书也需要重新启动。共享一个网关的所有服务也可以访问所有其他服务的证书。

目前，在网关下开始使用 TLS 获取外部服务的最简单选项是:

在类似 Amazon 弹性负载平衡器的地方终止网格外部的 TLS，并让 Amazon 的证书管理器管理证书。
避免使用动态证书提供商，比如让我们在 Istio IngressGateway 上加密并安装多域或通配符 TLS 证书。

在 Kubernetes 上找到通往生产级 Istio 的道路

现在您已经了解了 Istio 在 Kubernetes 上的一些优势，您可以继续在您的 Kubernetes 集群中安装 Istio 架构。这个帖子远没有提供生产级的配置。然而，它将使您的工作受到最小的干扰，以便您可以找到自己的工作生产配置之路。

如何在 GKE 建立 Kubernetes 集群

原文：https://www.fairwinds.com/blog/how-to-build-a-kubernetes-cluster-in-gke

本系列面向刚接触库伯内特和 GKE 的工程师。它提供了 Kubernetes 、架构基础和定义的基本概述，以及构建 Kubernetes 集群和构建您的第一个多层 webapp 的快速入门。

本博客将向您展示如何与 GKE 一起启动并运行您的第一个 Kubernetes 集群。

去 console.cloud.google.com 的谷歌云平台。如果你需要注册一个账户，这是非常简单的。谷歌会给你免费的积分。

单击左上角的汉堡，向下滚动到 Kubernetes 引擎，然后单击集群。

Goolge Cloud Platform Kubernetes Engine

您将看到没有创建任何集群，因此您将单击“create cluster”。

Kubernetes clusters create a cluster

对于您的第一个集群来说，默认设置基本上是可以的。因为您可能会使用 Google 提供的免费积分，所以您会希望通过使用我的第一个集群选项来最大限度地降低成本。

在右侧，单击我的第一个集群。

Cluster basics

对于您的第一个集群，只需使用默认设置。随着 Kubernetes 越来越先进，所提供的选项将变得更有意义，比如选择节点的数量和大小。您可以跳到“查看”并单击左下方的“创建”。

My First Cluster

在创建集群时，您会看到一个旋转的轮子——大约需要 3-5 分钟集群才会启动。

如果您曾经从零开始创建过 Kubernetes 集群，那么您会确切地知道需要多少时间。当您创建第一个集群时，Google 会在幕后处理所有这些事情。

Kubernetes cluster-1 screenshot

一旦您的集群准备就绪，您会在集群名称旁边看到一个绿色复选标记。如果您使用上一个屏幕的默认设置，Google 将命名您的集群。在这种情况下是 cluster-1.

启动并运行后，有两种方法可以验证您是否可以连接到集群。最简单的方法是使用谷歌云控制台。

点击右边的连接按钮。您将看到一个可以拷贝 gcloud 命令的地方。这里假设您已经安装了 gcloud 命令行和 kubectl 实用程序。如果你还没有安装这些或者想更快上手，点击按钮 run in cloud shell。

Connect to the cluster

这将在您的浏览器中打开一个云控制台。您可以看到，它自动填充了为我们的 Kubernetes 集群进行身份验证所需的命令。 GKE Shell Terminal

要运行这个命令，只需按回车键。

您可以运行一些快速的 kubectl 命令来验证您可以连接到您的集群。

您可以运行的第一个是kubectl config current-context.,它应该回显我们连接到 Kubernetes 集群的当前上下文。

danielle@cloudshell:~ (trial-275916)$ kubectl config current-context
gke_trial-275916_us-central1-c_cluster-1

在现实世界中，您可能同时连接到任意数量的集群。您可以使用 kubectl config 命令在集群之间切换上下文。如果您使用它在生产集群和开发集群之间切换，请小心。您可以让您的当前上下文指向一个生产集群，并打算在您的开发集群中运行。请随意使用该命令。

您可以看到现在您已经连接到了刚刚创建的 Kubernetes 集群。您可以通过运行 kubectl get nodes. 来验证 Kubernetes 集群是否有工作空间

danielle@cloudshell:~ (trial-275916)$ kubectl get nodes
NAME                                       STATUS   ROLES    AGE   VERSION
gke-cluster-1-default-pool-45c619a9-13l8   Ready       51m   v1.14.10-gke.27
gke-cluster-1-default-pool-45c619a9-hrfr   Ready       51m   v1.14.10-gke.27
gke-cluster-1-default-pool-45c619a9-x7q9   Ready       51m   v1.14.10-gke.27

您可以看到，在 GKE 有一个三节点 Kubernetes 群集。

Kubernetes 最佳实践:如何(正确地)设置资源请求和限制

原文：https://www.fairwinds.com/blog/how-to-correctly-set-resource-requests-and-limits

管理 Kubernetes 时，我最大的烦恼之一就是工作负载没有资源请求和限制。对此我非常沮丧，于是我创建了一个开源项目 Goldilocks，让设置初始资源请求和限制的过程变得更加容易。在这篇博客中，我将讨论 Kubernetes 正确设置资源请求和限制的最佳实践。

Kubernetes 是一个动态系统，可以自动适应您的工作负载的资源利用率。Kubernetes 有两个级别的缩放。每个单独的 Kubernetes 部署都可以使用水平 Pod 自动缩放器(HPA)进行自动缩放，而整个集群则使用集群自动缩放器进行缩放。HPA 监视部署中各个单元的目标指标(通常是 CPU 或内存使用情况)，并根据需要添加或删除单元，以使该指标接近指定的目标。同时，Cluster Autoscaler 处理集群本身的扩展。它会监视无法调度的单元，并向集群添加或删除节点以容纳这些单元。

Kubernetes 支持这两种扩展操作的一个关键特性是能够为您的工作负载设置特定的资源请求和限制。通过对每个 pod 使用多少 CPU 和内存设置合理的限制和请求，您可以最大限度地提高基础架构的利用率，同时确保平稳的应用程序性能。为了最大化 Kubernetes 集群的有效利用率，正确设置资源限制和请求是非常重要的。对应用程序设置太低的限制会导致问题。例如，如果你的内存限制太低，Kubernetes 一定会因为你违反了它的限制而杀死你的应用程序。同时，如果你把你的限制设置得太高，你会因为过度分配而浪费资源，这意味着你最终会有更高的账单。

虽然 Kubernetes 最佳实践规定您应该始终为您的工作负载设置资源限制和请求，但要知道每个应用程序使用什么值并不总是那么容易。结果，一些团队根本没有设置要求或限制，而另一些团队在初始测试时将它们设置得太高，然后永远不会正确。确保扩展操作正常工作的关键是调整每个工作负载的资源限制和请求，以便工作负载高效运行。

设置资源限制和请求是在 Kubernetes 集群上尽可能高效可靠地运行应用程序的关键。

如何设置 Kubernetes 资源

Fairwinds 的开源项目 Goldilocks 帮助团队将资源分配到他们的 Kubernetes 部署中，并正确地校准这些资源。Goldilocks 是一个 Kubernetes 控制器，它收集关于正在运行的 pod 的数据，并就如何设置资源请求和限制提供建议。它可以帮助组织了解资源使用、资源成本和效率方面的最佳实践。金凤花采用了 VPA 的 Kubernetes 垂直吊舱自动缩放器。它会考虑工作负载的历史内存和 CPU 使用情况，以及 pod 的当前资源使用情况，以便建议如何设置资源请求和限制。(虽然 VPA 实际上可以为您设置限制，但通常最好仅使用 VPA 引擎来提供建议。)本质上，该工具为名称空间中的每个部署创建一个 VPA，然后查询该 VPA 以获取信息。

要查看这些建议，您必须使用 kubectl 来查询每个 VPA 对象，这对于大中型部署来说很快就会变得繁琐。这就是仪表板的用武之地。一旦你的 VPA 到位，建议将出现在金发女孩仪表板。

该控制面板根据您希望部署的服务质量(QoS)等级提供两种类型的建议:

保证，这意味着应用程序将被授予比其他工作负载更高的优先级，以保证可用资源。在这个类中，您将您的资源请求和限制设置为完全相同的值，这保证了容器所请求的资源在它被调度时是可用的。这个 QoS 等级通常非常适合最稳定的 Kubernetes 集群。
Burstable ，这意味着应用程序将获得最低水平的资源，但如果可用，将获得更多资源。本质上，您的资源请求低于您的限制。调度程序将使用该请求将 pod 放在一个节点上，但是随后 pod 可以使用更多的资源，直到它被终止或限制为止。当资源不足时，在决定删除哪些工作负载时，此 QoS 类别被授予较低的优先级。

仪表板提供了保证和突发 QoS 类别的建议。在保证类中，我们建议将您的请求和限制设置为 VPA“目标”字段。

注意:第三个 QoS 类别 bestfortion 表示不设置任何请求或限制，并且只有当所有其他请求都得到满足时，才会为应用程序分配资源。不建议使用 BestEffort。

为集群专门化实例组

如果您对优化工作负载运行的实例感兴趣，可以使用不同的实例组类型和节点标签将工作负载导向特定的实例类型。

不同的业务系统通常有不同规模的资源需求，以及专门的硬件需求(如 GPU)。Kubernetes 中节点标签的概念允许您将标签放在所有不同的节点上。同时，可以将 pod 配置为使用特定的“节点选择器”来匹配特定的节点标签，这些标签决定了可以将 pod 调度到哪些节点上。通过利用带有适当标签的不同实例类型的实例组，您可以将您选择的云提供商提供的底层硬件与 Kubernetes 中的工作负载混合搭配。

如果您有不同规模、不同需求的工作负载，那么将这些工作负载放在不同的实例类型上，并使用标签将您的工作负载引导到这些不同的实例类型上，这在战略上和经济上都是有意义的。

Spot 实例与这一想法密切相关。大多数组织都熟悉按需或在固定期限内按保留条款支付实例费用。但是，如果您有可能被中断的工作负载，您可能希望考虑使用 spot 实例。这些实例类型允许您以显著的折扣利用云提供商的剩余容量—当对常规按需实例的需求增加时，所有这些都有实例被终止的风险。

如果您的一些业务工作负载可以承受随机实例终止的风险，那么您可以使用相同的节点标记概念来专门将这些工作负载调度到这些类型的实例组上，从而节省大量成本。

如何启用 Kubernetes 资源推荐

Goldilocks 是 Fairwinds Insights 部署来提供工作负载效率和性能优化的工具之一。借助 Fairwinds Insights，Goldilocks 可以跨多个集群部署，因此团队可以在单一控制台中获得信息。Fairwinds Insights 为 Goldilocks 增加了数据和建议，包括潜在的成本节约。出现的控制面板包括名称空间和部署的列表，以及平均总成本和成本建议。

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

许多组织将其 CPU 和内存请求和限制设置得太高，因此当他们应用 Fairwinds Insights 的建议时，他们能够在更少的 Kubernetes 工作节点上放置更多的 pod。启用集群自动缩放后，任何多余的节点在未使用时都会被删除，从而节省时间和金钱。

使用像 Fairwinds Insights 这样的软件或像 Goldilocks 这样的开源工具，开发人员可以通过自动化推荐过程来消除猜测。反过来，它为您打开了提高集群效率和减少云支出的大门。

如何在 Kubernetes 中创建、查看和销毁 Pod

原文：https://www.fairwinds.com/blog/how-to-create-view-and-destroy-a-pod-in-kubernetes

2023 年 2 月 28 日更新

在我们的 How-to-Kube 系列中，我们想从介绍 pod 基础知识开始。与服务、卷和名称空间一样，pod 是一个基本的 Kubernetes 对象。pod 是在作为一个单元的同一物理或虚拟机上调度的一个或多个容器的集合。当您创建 pod 的声明时，您可以用位于 pod 内部的任意数量的容器来定义它。

通常，您不会直接创建一个 pod——相反，您将创建一个更高级别的对象，如包含 pod 规范的 Deployment 或 StatefulSet(见下文)。

Kubernetes 部署

部署提供以下功能:

提供更高级别的 pod 抽象(定义一组相同的 pod)
可以扩展 pod 的副本以满足需求
负责创建、更新和删除窗格
可以向前或向后滚动

在这里，您可以看到这个部署称为“webapp”。它希望存在两个副本。

在这篇文章中，您将学习如何使用 nginx 图像在 Kubernetes 中创建一个 pod，查看描述 pod 的 YAML，然后删除您创建的 pod。我们将使用 Minikube 工具，使您能够在您的笔记本电脑或计算机上运行单节点 Kubernetes 集群。

要获得更多关于 Kubernetes 入门的帮助，请阅读我们为刚接触 Kubernetes 和 GKE 的工程师准备的系列文章。它提供了 Kubernetes 、架构基础和定义的基本概述，以及构建 Kubernetes 集群和构建您的第一个多层 webapp 的快速入门。

如何在 Kubernetes 中创建 Pod

首先，你需要启动一个 Kubernetes 集群(在 GKE)。一旦您进入了 Kubernetes 沙盒环境，确保您已经连接到了 Kubernetes 集群，方法是在命令行中执行 kubectl get nodes 来查看终端中的集群节点。如果成功了，您就可以创建和运行 pod 了。

要使用 nginx 映像创建 pod，运行命令ku bectl run nginx-image = nginx-restart = Never。这将创建一个名为 nginx 的 pod，与 Docker Hub 上的 nginx 映像一起运行。通过设置标志 - restart=Never 我们告诉 Kubernetes 创建一个单独的 pod，而不是一个部署。

一旦您按下 enter 键，pod 将被创建。您应该看到 pod/nginx 创建的出现在终端中。

如何查看 Pod

您现在可以运行命令 kubectl get pods 来查看您的 pod 的状态。要查看 pod 的整个配置，只需在您的终端中运行 kubectl describe pod nginx 。

终端现在将显示 pod 的 YAML，从名称 nginx、其位置、Minikube 节点、开始时间和当前状态开始。您还将看到关于 nginx 容器的深入信息，包括容器 ID 和图像所在的位置。

如果您一直滚动到终端的底部，您将看到 pod 中发生的事件。在本教程中，您将看到 pod 已经启动、创建，nginx 映像被成功提取并被分配给 Minikube 中的这个节点。

摧毁吊舱

删除 pod 的操作很简单。要删除您创建的 pod，只需运行 kubectl delete pod nginx 。在按 Enter 键之前，请务必确认要删除的 pod 的名称。如果您已经成功完成了删除 pod 的任务， pod nginx deleted 会出现在终端中。

Pods 是理解 Kubernetes 对象模型的重要单元，因为它们代表了应用程序中的流程。在大多数情况下，pod 作为一种间接的方式来管理 Kubernetes 中的容器。在更复杂的用例中，pod 可能包含多个需要共享资源的容器，充当容器管理的中心位置。

要了解更多 Kubernetes 最佳实践，获取本指南。它将带您了解您将面临的许多问题，以及如何配置 Kubernetes 以避免错误。

如何实施 Pod 策略

Kubernetes 的一个大问题是缺乏可见性和跨多个集群和开发团队的一致策略执行。当你开始你的 Kubernetes 之旅时，你应该考虑 Kubernetes 护栏 -你将如何让你的团队安全地使用 Kubernetes？尽早这样做将确保您不会在没有为 Kube 配置建立内部标准的地方引入配置漂移。在您玩游戏时，查看一些 Kubernetes 安全注意事项:

Kubernetes 针对安全性、可靠性和资源请求的最佳实践

正如您应该考虑护栏一样，您也应该考虑 Kubernetes 的最佳实践。通过在学习 Kubernetes 的同时学习最佳实践，您将能够充分评估该平台并对其进行扩展。

开源项目 Polaris 运行各种 Kubernetes 最佳实践检查，以确保 pod 和控制器配置正确。使用这个开源项目，您可以评估 Kubernetes 并避免将来出现问题。

开始使用 Kubernetes 时经常出现的另一个问题是如何确定应用程序的规模。开源项目， Goldilocks ，让你调整你的应用程序，让它“恰到好处”它帮助您确定资源请求和限制的起点。

如何在 Fairwinds Insights 中创建您的第一个 OPA 自定义策略

原文：https://www.fairwinds.com/blog/how-to-create-your-first-opa-custom-policy-in-fairwinds-insights

Fairwinds Polaris 已经到了 4.0 版本，有一些令人敬畏的新功能！(对于那些保持分数的人来说，由于一些突破性的变化，我们很快就跳过了 2.0)。

随着 Polaris 从一个仪表板发展到一个准入控制器(以防止这些资源进入集群)，再到现在的 CI 工具(以防止它们甚至进入代码回购基础设施)，我们收到了越来越多的实施新检查的请求，比如入口是否使用 TLS，或者一个部署是否附带一个 PodDisruptionBudget。

为了更好地满足这些需求，我们在自定义检查功能中实现了三个主要的新特性:

检查非工作负载类型的能力，如入口、服务和集群角色
引用模式中其他字段的能力
交叉检查资源的能力，例如，确保部署有相应的 PodDisruptionBudget

支持非工作负载类型

支持自我参考

package fairwinds

labelMustMatchName[result] { 

  input.metadata.labels["app.kubernetes.io/name"] != metadata.name 

  result := { 

    "description": "label app.kubernetes.io/name must match metadata.name", 

  } 

}

为了在 Polaris 中支持这一点，我们在 JSON 模式支持中添加了一些基本的模板:

successMessage: Label app.kubernetes.io/name matches metadata.name
failureMessage: Label app.kubernetes.io/name must match metadata.name
inds:
- Deployment
schema:
  '$schema': http://json-schema.org/draft-07/schema
  type: object
  properties:
    metadata:
      type: object
      properties:
        labels:
          type: object
          required: ["app.kubernetes.io/name"]
          properties:
            app.kubernetes.io/name: ""

虽然这仍然没有给OPA 所提供的所有灵活性，但它允许我们处理 Polaris 2.0 无法解决的大多数用例。

支持跨资源引用

提供一种访问非控制器资源的方法(上面的✅)
将某些字段模板化，例如，可以在 poddisruptionbudget(上面的✅)中断言部署的名称
提供在同一检查中定义多个模式的语法

事不宜迟，下面是我们创建的检查，以确保 PDB 附加到所有部署，它使用所有三个新功能:

successMessage: A PodDisruptionBudget is attached
failureMessage: Should have a PodDisruptionBudget
kinds:
- Deployment
schema:
  '$schema': http://json-schema.org/draft-07/schema
  type: object
  properties:
    metadata:
      type: object
      properties:
        labels:
          type: object
          required: ["app.kubernetes.io/name"]
          properties:
            app.kubernetes.io/name: 
additionalSchemas:
  PodDisruptionBudget:
    '$schema': http://json-schema.org/draft-07/schema
    type: object
    properties:
      metadata:
        type: object
        properties:
          name:
            type: string
            const: -pdb
      spec:
        type: object
        properties:
          selector:
            type: object
            properties:
              matchLabels:
                type: object
                properties:
                  app.kubernetes.io/name:
                    type: string
                    pattern:

]

这里需要注意一些事情:

首先，kinds字段告诉 Polaris 将这个检查与哪些资源相关联。也就是说，如果上述检查失败，您将在相关部署旁边看到一个❌(而不是在 PDB 旁边)。

接下来，schema域像往常一样工作，检查主资源。

结论

我们也希望北极星用户加入我们新的 Fairwinds 开源软件用户组。我们对您对 Polaris 的贡献感到非常兴奋，并共同努力验证和实施 Kubernetes 部署。

如何用 Kubernetes 部署多层 Web 应用程序

原文：https://www.fairwinds.com/blog/how-to-deploy-multi-tiered-web-application-with-kubernetes

在 Kubernetes 系列的最后一篇介绍中，我们将带您了解如何部署多层 web 应用程序。webapp 是一个带有 Redis 后端的关键值存储和检索服务。(阅读 Kubernetes 解决的问题、架构和定义或在 GKE 建立 K8S 集群)。

下面是我们将部署的内容的简要概述:

Fairwinds Multi-tiered web application with Kubernetes diagram

我们已经准备了一个 GitHub 存储库，您可以用所有库本内特存储库、各种文档和 Fairwinds 用于研讨会的代码进行克隆。

转到 Git >克隆或下载>复制 URL。

Fairwinds GitHub k8s-workshop

你需要一个 Kubernetes 集群。你可以看看我们的博客如何用 GKE 构建一个 Kubernetes 集群。在 GKE，打开您的云 shell 终端窗口，然后运行命令:

git clone [https://github.com/FairwindsOps/k8s-workshop.git](https://github.com/FairwindsOps/k8s-workshop.git)

这是一个相对较小的项目，所以会很快拉下来。

在存储库中，您可以找到自述文件、装配所需文件夹、完整文件夹、图像文件夹和 istio 文件夹。在这篇博客中，除了自述文件和完整的文件夹之外，你可以忽略所有的内容。自述文件中提供了两种途径。我们将把重点放在基本轨道上，但是如果你想深入研究在 Kubernetes 上部署应用程序时可能出现的问题，你可以回头看看 kub assembly required 版本。它为 Kubernetes YAML 提供了更多的细微差别，允许您调试和测试运行 kubectl 命令的能力。

下面是我们将用来部署完整 web 应用程序的步骤。这个博客将部署一个损坏的应用程序，我们将修复 Kubernetes YAML 文档，以使部署成功。

部署到 Redis 数据库

在本次研讨会中，您将:

为您的应用程序部署新的命名空间
将 Redis 服务器部署到新的名称空间中
查看您使用 Kubernetes 部署的对象(部署，pod)
通过 kubectl 从部署的资源中获取日志

您首先需要提供一个名称空间。名称空间是一种分割和存储 Kubernetes API 中提供的对象的方式。您可以通过运行以下命令来检查现有的名称空间:

kubectl get namespace

danielle@cloudshell:~ (trial-275916)$ kubectl get namespace
NAME              STATUS   AGE
default           Active   75m
kube-node-lease   Active   75m
kube-public       Active   75m
kube-system       Active   75m

在 GKE，你可以看到四种现有的名称空间——默认、kube-节点租赁、kube-公共和 kube-系统。我们将创建一个新的名称空间:

kubectl apply -f namespace.yml

-f标志表示您将把一个文件传递给 kubectl ，让它提交给 Kubernetes API。

danielle@cloudshell:~ (trial-275916)$ kubectl apply -f namespace.yml
namespace/k8s-workshop created

您可以运行 get namespace 命令来查看您创建了什么。

danielle@cloudshell:~/k8s-workshop/complete (trial-275916)$ kubectl get namespaces
NAME              STATUS   AGE
default           Active   81m
k8s-workshop      Active   73s
kube-node-lease   Active   81m
kube-public       Active   81m
kube-system       Active   81m

随着学习的深入，您将向 Kubernetes API all in YAML 定义应用和提交对象。我们将使用kubectl命令行工具获取文件，解析它们并提交给 API。

第一层 Web 应用程序:Redis

现在，您将从存储 webapp 状态的有状态后端开始部署 web 应用程序的第一层。kubectl 允许你获取一系列 YAML 文件，把它们放在一个文件夹中，然后对整个文件夹进行操作。它将提供文件夹下定义的所有资源和对象。这允许您创建一组对象和迷你 YAML 文件，而不是用一千行定义一切的单个 YAML 文件。您将首先推出这个多层 web 应用程序的后端层——一个 HA Redis 实现。要四处看看，可以跑ls -l 01_redis/

danielle@cloudshell:~/k8s-workshop/complete (trial-275916)$ ls -1 01_redis/
redis.networkpolicy.yml
redis-primary.deployment.yml
redis-primary.service.yml
redis-replica.deployment.yml
redis-replica.horizontal_pod_autoscaler.yml
redis-replica.service.yml

这下面有一系列文件。

部署文件定义了启动的 pod 的数量(更多信息请参考 Kubernetes 架构基础和定义)。
您将看到定义 clusterIP 服务的服务文件(clusterIP，因为您不想让 Redis 暴露给公共 internet)。
这是一个 HA Redis 实施，因此您将拥有一个复制副本部署文件和一个复制副本水平 pod 自动缩放器(HPA)。autoscaler 允许您根据部署中设置的资源请求自动扩展。
您还拥有一个可用于副本服务器的服务，这样主服务器就可以与副本服务器对话，还拥有一个用于 redis 的网络策略。

您可以查看这些文件，看看定义是什么样子的。在文本编辑器中，打开 redis-primary 部署文件:

vim redis.primary.deployment.yml

您将看到一个 API 版本，一个种类(您在其中指定了您将提交的对象)，元数据，以及一个关于部署应该是什么样子的规范。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: redis-primary
  namespace: k8s-workshop
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: redis
        role: primary
        tier: backend
    spec:
      containers:
      - name: redis
        image: gcr.io/google_containers/redis:e2e  # or just image: redis
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 6379

在这种情况下，您将调配一个副本(即一个单元是部署的一部分)。您将在 template.spec 中模板化您想要的规范。您还可以定义一组容器。在本例中，您将只有一个容器需要旋转。容器的名称是从 Google 容器注册表中提取的 Redis。您还将发出一些附加到容器的资源请求——分配 100 个 CPU 份额、100 MB 内存和网络，以公开 redis 默认的端口 6379。您可以深入研究 YAML 定义，并尝试添加更多的容器或副本。

将 YAML 应用于集群

现在，您将把您的 YAML 定义应用到集群中。运行:

kubectl apply -f 01_redis/

这个命令检查了上面检查的所有文件，并为每个文件创建了对象。

danielle@cloudshell:~/k8s-workshop/complete (trial-275916)$ kubectl apply -f 01_redis/
deployment.extensions/redis-primary created
service/redis-primary created
deployment.extensions/redis-replica created
horizontalpodautoscaler.autoscaling/redis-replica created
service/redis-replica created
networkpolicy.networking.k8s.io/redis created

现在，您需要读取这些对象，并获取正在运行的数据。

kubectl -n k8s-workshop get pod

您将看到有两个 pod 在运行——一个 Redis 主服务器和一个副本服务器。

NAME                             READY   STATUS    RESTARTS   AGE
redis-primary-684c84fc56-57brt   1/1     Running   0          75s
redis-replica-d64bd9565-zn7sg    1/1     Running   0          74s

现在对部署采取相同的步骤:

kubectl -n k8s-workshop get deployments

您将看到有关您的部署的信息—Redis 副本、Redis 主服务器、所需的 1 计数、当前 1、最新、可用内容以及 pod 的年龄。

NAME            READY   UP-TO-DATE   AVAILABLE   AGE
redis-primary   1/1     1            1           2m37s
redis-replica   1/1     1            1           2m36s

如果您正在进行滚动部署，您将在这里看到更多关于应用程序状态的有趣信息。

您还可以通过运行以下命令来查看服务:

kubectl -n k8s-workshop get services

在这里，您可以看到两个服务—主服务和副本服务。

NAME            TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
redis-primary   ClusterIP   10.8.11.78           6379/TCP   5m35s
redis-replica   ClusterIP   10.8.4.228           6379/TCP   5m34s

这两种服务都是集群 IP 服务(即仅在集群内部的 IP 上可用)。您还会看到 IP 和一些关于端口和年龄的信息。如果您想用一个命令进行总结，您可以运行:

kubectl -n k8s-workshop get deployments,pods,services

这允许您在单个图像中显示所有资源。

NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.extensions/redis-primary   1/1     1            1           6m42s
deployment.extensions/redis-replica   1/1     1            1           6m41s
NAME                                 READY   STATUS    RESTARTS   AGE
pod/redis-primary-684c84fc56-57brt   1/1     Running   0          6m42s
pod/redis-replica-d64bd9565-zn7sg    1/1     Running   0          6m41s
NAME                    TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
service/redis-primary   ClusterIP   10.8.11.78           6379/TCP   6m42s
service/redis-replica   ClusterIP   10.8.4.228           6379/TCP   6m41s

通过这些步骤，您现在应该可以在 Kubernetes 的 k8s-workshop namespace 中看到一个健康的 redis 主服务器和副本。

部署 Web App

接下来，您将:

将 web 应用程序部署到 default 名称空间(与我们在上面创建的名称空间不同)
观察云负载平衡器创建对 web 应用程序的外部访问
卷曲新部署的 web 应用程序以进行手动测试
查看 web 应用程序的日志
通过部署到正确的名称空间来修复损坏的 web 应用程序部署
再次卷曲 web 应用程序进行测试

首先列出 webapp 目录 ls -l 02_webapp/ ,看看它有没有类似于 redis 后端的文件。

danielle@cloudshell:~/k8s-workshop/complete (trial-275916)$ ls -1 02_webapp/
app.configmap.yml
app.deployment.yml
app.horizontal_pod_autoscaler.yml
app.networkpolicy.yml
app.secret.yml
app.service.yml

有两种新的对象类型:配置映射和机密。

配置映射提供了将环境变量和静态文件导入 pod 的方法。如果您查看 configmap YAML 文件，您可以深入查看一系列分层的键。
秘密允许您存储和管理敏感信息，如密码、OAuth 令牌和 ssh 密钥。

要部署基本 webapp:

T2kubectl apply -f 02_webapp/

这将部署02_webapp/文件夹中的所有 yaml 定义。注意，我们不是在 YAML 的metadata中定义名称空间，所以它将默认为用kubectl.配置的默认名称空间

danielle@cloudshell:~/k8s-workshop/complete (trial-275916)$ kubectl apply -f 02_webapp/
configmap/webapp created
deployment.extensions/webapp created
horizontalpodautoscaler.autoscaling/webapp created
networkpolicy.networking.k8s.io/app created
secret/webapp created
service/webapp created

您可以通过运行kubectl -n k8s-workshop get configmaps 来查看您创建并在部署中引用的配置图，您将看到没有找到任何资源。

danielle@cloudshell:~/k8s-workshop/complete (trial-275916)$ kubectl -n k8s-workshop get configmaps
No resources found in k8s-workshop namespace.

在这个有意的例子中，您将看到一个参数丢失的实例。每次部署或尝试读回信息时，您都要查看默认名称空间并指定k8s-workshop名称空间。

在这个例子中，02_webapp/实现被部署到默认的名称空间中。要检查这一点，请运行:

kubectl get configmaps

您将看到 webapp configmap 在那里，但是它被部署到了错误的名称空间。

danielle@cloudshell:~/k8s-workshop/complete (trial-275916)$ kubectl get configmaps
NAME     DATA   AGE
webapp   2      4m8s

您需要重新运行 apply 并指定名称空间。原因是如果您查看01_redis主部署，您指定了一个名称空间。如果您查看 webapp 的相同部署，您会看到在元数据下，您没有提供名称空间。

您需要使用 kubectl delete -f 02_webapp/取消最后一次应用，以删除创建的对象并正确部署到 k8s-workshop 名称空间中。

danielle@cloudshell:~/k8s-workshop/complete (trial-275916)$ kubectl delete -f 02_webapp/
configmap "webapp" deleted
deployment.extensions "webapp" deleted
horizontalpodautoscaler.autoscaling "webapp" deleted
networkpolicy.networking.k8s.io "app" deleted
secret "webapp" deleted
service "webapp" deleted

现在，您将在正确的名称空间中应用程序。

kubectl apply -f 02_webapp/ --namespace k8s-workshop

这将覆盖未设置的default名称空间，并将所有 yaml 文件部署到 k8s-workshop 名称空间中。

danielle@cloudshell:~/k8s-workshop/complete (trial-275916)$ kubectl apply -f 02_webapp/ --namespace k8s-workshop
configmap/webapp created
deployment.extensions/webapp created
horizontalpodautoscaler.autoscaling/webapp created
networkpolicy.networking.k8s.io/app created
secret/webapp created
service/webapp created

接下来，运行 kubectl get services --namespace k8s-workshop.

danielle@cloudshell:~/k8s-workshop/complete (trial-275916)$ kubectl get services --namespace k8s-workshop
NAME            TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
redis-primary   ClusterIP      10.8.11.78           6379/TCP       19m
redis-replica   ClusterIP      10.8.4.228           6379/TCP       19m
webapp          LoadBalancer   10.8.7.188   34.72.33.15   80:31550/TCP   48s

您可以看到有一个负载平衡器 IP 挂起。如果你给它几分钟，负载平衡器 IP 将已经改变。

现在，您已经运行了 webapp 的前端层。

访问您的服务

现在，您可以查看可用的服务，看看您实际上是如何访问 webapp 的。

kubectl -n k8s-workshop get services

您可以看到两个服务都连接到 Redis，这是只能从集群内部访问的集群 IP 服务。您还会看到第三个服务 webapp，它是公开的，因为它是一个负载平衡器服务。当您列出服务时，您会获得一个外部 IP。

danielle@cloudshell:~/k8s-workshop/complete (trial-275916)$ kubectl -n k8s-workshop get services
NAME            TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
redis-primary   ClusterIP      10.8.11.78           6379/TCP       20m
redis-replica   ClusterIP      10.8.4.228           6379/TCP       20m
webapp          LoadBalancer   10.8.7.188   34.72.33.15   80:31550/TCP   97s

如果你复制外部 IP，打开一个网络浏览器，你可以看到我们的 webapp 正在服务来自 Kubernetes 的 Hello。

webapp is serving Hello from Kubernetes

要检查这个特定的 pod 和 pod 内的容器是否真的获得了流量，您首先需要获得实际运行的 pod 的名称:kubectl -n k8s-workshop get pods

您将看到有一个 webapp pod 正在运行。复制 pod 的全名。

danielle@cloudshell:~/k8s-workshop/complete (trial-275916)$ kubectl -n k8s-workshop get pods
NAME                             READY   STATUS    RESTARTS   AGE
redis-primary-684c84fc56-57brt   1/1     Running   0          25m
redis-replica-d64bd9565-zn7sg    1/1     Running   0          25m
**webapp-54c7b758f5-sxjgp**          1/1     Running   0          6m43s

运行kubectl -n k8s-workshop logs -f **webapp-54c7b758f5-sxjgp**

您将看到有一个 webapp pod 正在运行。

10.4.0.1 - - [11/May/2020:20:50:11 +0000] "GET / HTTP/1.1" 200 70 0.0030
10.4.0.1 - - [11/May/2020:20:50:14 +0000] "GET / HTTP/1.1" 200 70 0.0029
10.4.0.1 - - [11/May/2020:20:50:17 +0000] "GET / HTTP/1.1" 200 70 0.0045
10.4.0.1 - - [11/May/2020:20:50:18 +0000] "GET / HTTP/1.1" 200 70 0.0029
10.4.0.1 - - [11/May/2020:20:50:20 +0000] "GET / HTTP/1.1" 200 70 0.0030
10.4.0.1 - - [11/May/2020:20:50:23 +0000] "GET / HTTP/1.1" 200 70 0.0030
10.4.0.1 - - [11/May/2020:20:50:26 +0000] "GET / HTTP/1.1" 200 70 0.0030
10.4.0.1 - - [11/May/2020:20:50:28 +0000] "GET / HTTP/1.1" 200 70 0.0030
10.4.0.1 - - [11/May/2020:20:50:29 +0000] "GET / HTTP/1.1" 200 70 0.0035
10.4.0.1 - - [11/May/2020:20:50:32 +0000] "GET / HTTP/1.1" 200 70 0.0030
10.4.0.1 - - [11/May/2020:20:50:35 +0000] "GET / HTTP/1.1" 200 70 0.0031
10.4.0.1 - - [11/May/2020:20:50:38 +0000] "GET / HTTP/1.1" 200 70 0.0029
10.4.0.1 - - [11/May/2020:20:50:38 +0000] "GET / HTTP/1.1" 200 70 0.0044
10.4.0.1 - - [11/May/2020:20:50:41 +0000] "GET / HTTP/1.1" 200 70 0.0032
10.4.0.1 - - [11/May/2020:20:50:44 +0000] "GET / HTTP/1.1" 200 70 0.0031
10.4.0.1 - - [11/May/2020:20:50:47 +0000] "GET / HTTP/1.1" 200 70 0.0030
10.4.0.1 - - [11/May/2020:20:50:48 +0000] "GET / HTTP/1.1" 200 70 0.0027
10.4.0.1 - - [11/May/2020:20:50:50 +0000] "GET / HTTP/1.1" 200 70 0.0031

您可以查看内部运行状况检查请求，以了解 pod 是否处于活动状态。如果您返回浏览器并点击 refresh，您将会看到针对基本 URL 的不同 git 请求通过。您将知道，从公共互联网上，可以访问运行在您的 Kubernetes 集群中的 webapp。

10.4.0.1 - - [11/May/2020:20:51:38 +0000] "GET / HTTP/1.1" 200 70 0.0030
10.4.0.1 - - [11/May/2020:20:51:38 +0000] "GET / HTTP/1.1" 200 70 0.0029
10.4.0.1 - - [11/May/2020:20:51:38 +0000] "GET /favicon.ico HTTP/1.1" 200 37 0.0020
10.128.0.22 - - [11/May/2020:20:51:38 +0000] "GET / HTTP/1.1" 200 70 0.0027
10.128.0.22 - - [11/May/2020:20:51:38 +0000] "GET /favicon.ico HTTP/1.1" 200 37 0.0010
10.128.0.22 - - [11/May/2020:20:51:38 +0000] "GET / HTTP/1.1" 200 70 0.0028
10.128.0.22 - - [11/May/2020:20:51:38 +0000] "GET /favicon.ico HTTP/1.1" 200 37 0.0010
10.128.0.22 - - [11/May/2020:20:51:38 +0000] "GET / HTTP/1.1" 200 70 0.0027
10.4.0.1 - - [11/May/2020:20:51:38 +0000] "GET / HTTP/1.1" 200 70 0.0081
10.128.0.22 - - [11/May/2020:20:51:38 +0000] "GET /favicon.ico HTTP/1.1" 200 37 0.0011
10.128.0.22 - - [11/May/2020:20:51:38 +0000] "GET / HTTP/1.1" 200 70 0.0027
10.128.0.22 - - [11/May/2020:20:51:38 +0000] "GET /favicon.ico HTTP/1.1" 200 37 0.0012
10.4.0.1 - - [11/May/2020:20:51:39 +0000] "GET / HTTP/1.1" 200 70 0.0028
10.4.0.1 - - [11/May/2020:20:51:39 +0000] "GET /favicon.ico HTTP/1.1" 200 37 0.0010
10.4.0.1 - - [11/May/2020:20:51:39 +0000] "GET / HTTP/1.1" 200 70 0.0029
10.4.0.1 - - [11/May/2020:20:51:39 +0000] "GET /favicon.ico HTTP/1.1" 200 37 0.0010
10.128.0.22 - - [11/May/2020:20:51:39 +0000] "GET / HTTP/1.1" 200 70 0.0028
10.128.0.22 - - [11/May/2020:20:51:39 +0000] "GET /favicon.ico HTTP/1.1" 200 37 0.0010
10.128.0.22 - - [11/May/2020:20:51:39 +0000] "GET / HTTP/1.1" 200 70 0.0028
10.128.0.22 - - [11/May/2020:20:51:39 +0000] "GET /favicon.ico HTTP/1.1" 200 37 0.0010
10.4.0.1 - - [11/May/2020:20:51:39 +0000] "GET / HTTP/1.1" 200 70 0.0027
10.4.0.1 - - [11/May/2020:20:51:39 +0000] "GET /favicon.ico HTTP/1.1" 200 37 0.0010
10.4.0.1 - - [11/May/2020:20:51:39 +0000] "GET / HTTP/1.1" 200 70 0.0028
10.4.0.1 - - [11/May/2020:20:51:39 +0000] "GET /favicon.ico HTTP/1.1" 200 37 0.0010
10.4.0.1 - - [11/May/2020:20:51:41 +0000] "GET / HTTP/1.1" 200 70 0.0030

现在，您已经在 Kubernetes 中部署了一个多层 web 应用程序。这只是冰山一角，在 Kubernetes 中有许多方法可以编排工作负载和应用程序。

如何轻松评估 Kubernetes 是否适合你

原文：https://www.fairwinds.com/blog/how-to-easily-evaluate-if-kubernetes-is-right-for-you

在您成功采用 Kubernetes 的过程中，您将经历许多阶段。当您对应用程序容器化感兴趣时，它往往会开始，但随后您会意识到基础架构的管理和您的应用程序将很快变得复杂。Kubernetes 已经迅速成为事实上的容器编排平台——CNCF 报告中超过四分之三的公司表示他们正在以某种形式使用 Kubernetes。您可能最终会在家里玩覆盆子 pi，但最终您会想要评估使用 Kubernetes 作为您的业务应用程序的构建模块的好处。

问题是，评估 Kubernetes 并不总是容易的，原因如下:

存在体系结构、操作、配置和概念上的复杂性
存在应用程序开发的复杂性
这是一个分布式系统
它可以部署在内部或托管的 Kubernetes 云上，如 GKE、EKS 或 AKS
它有一个巨大的代码库，并且在某些领域没有很好的文档记录

已经选择 Kubernetes 或仍在决定重新搭建平台的团队可能会面临冗长的概念验证，以验证云原生技术是否适用于他们的应用或服务。正确采用该平台，并确信它的生产级可能是一个漫长的过程，并且存在第一次就做错的风险。并非所有组织都有时间、预算或团队专业知识来实现这一目标。

Kubernetes 的好处就在那里！

但是不要让上面的事情让你沮丧。Kubernetes 有很多好处。

更快的上市时间，更高的灵活性

Kubernetes 让你专注于你最擅长的事情:发布优秀的应用程序或服务。它负责维护健康基础设施的“繁忙工作”,因此您可以将时间花在强化您的架构、使用开发人员能够理解和使用的 API 改进开发人员工作流程以及发布新功能上。这对客户和企业都有好处。

为您定制的便捷平台即服务

客户希望您的应用程序能够正常运行并具有高性能。作为消费者，我们都有同样高的期望。这要求所有公司构建可扩展的现代应用程序，以战略性地支持业务目标。云原生技术——微服务、容器和 Kubernetes——使您能够在现代动态云环境中构建和运行可扩展的应用程序。它为您提供了 PaaS 的便利，可根据您的需求进行定制。

Kubernetes 社区支持

Kubernetes 是一个容器编排平台，允许您管理运行您的应用程序的容器，并自动进行停机响应。它是开源的，由一个大型开发者社区支持，三大云提供商都提供托管的 Kubernetes - GKE、EKS 和 AKS。

如何评价 Kubernetes: KubeStart

Kubernetes 是容器编排事实上的标准。那么如何在克服上述挑战的同时对其进行评估呢？

Fairwinds 的 KubeStart 可以有所帮助。KubeStart 有助于加快和支持组织对 Kubernetes 的试用和采用。团队通过避免冗长的资源密集型概念证明来节省资金。KubeStart 确保 Kubernetes 的成功采用，并确保安全性、可靠性和效率从一开始就内置其中。

Fairwinds 使用 Terraform 基础设施作为代码，提供了两个开箱即用的生产级集群。这些集群拥有在生产中运行所需的一切，包括 Fairwinds Elements，我们精选的开源插件，用于在 GKE、EKS 或阿拉斯加扩展和管理 Kubernetes。团队可以在几天内(而不是几个月内)获得生产级集群，还可以获得他们所需的培训和支持，以加快决策、概念验证和整体成功采用的速度。使用 KubeStart 获得 Kubernetes 的好处，同时降低无效 POC 或延迟重新移植到 Kubernetes 的风险。

了解更多关于 KubeStart 的信息。

如何解释 Kubernetes

原文：https://www.fairwinds.com/blog/how-to-explain-kubernetes

Fairwinds sent two of us to SCaLE16x in Pasadena last month. Always an entertaining conference, it gave us a chance to have a variety of conversations with folks from all sorts of backgrounds.

对不同的人来说，它意味着不同的事情

在这些对话中出现的一个共同主题是当然每个人都知道 Kubernetes 是什么，都在积极部署它，并彻底理解它——直到会议厅空无一人，下班后的活动开始，真相开始浮出水面。出现的情况很能说明问题；Kubernetes 对不同的人意味着不同的东西，向那些在现实世界中没有遇到过它的人传达它的价值是一种隐喻。

在那些对话中，对于 Kubernetes 究竟是什么出现了许多不同的描述。我特别偏爱的一点是将它描述为跨越多个节点的计算机的内核。"它管理进程间的消息传递，处理排队和资源分配."这种描述的挑战在于，假定你的读者了解操作系统设计并不是世界上最容易接近的事情。

Kubernetes 隐喻中的一个练习

将 Kubernetes 描述为空中交通管制员可能更恰当。一个指挥和控制的中心点，负责安排到达和离开，确保飞机/集装箱不会相互碰撞，造成数百人死亡等。对于我们当中那些极度愤世嫉俗的人来说，你可能会用神经外科的复杂类比来解释 Kubernetes。无论你朝哪个方向走，都没有关系——在这个舞台上，没有人会有足够的自信来明智地质疑你的角色。如果你不能准确地解释某件事，那么用一种复杂到没人敢质疑你的方式来解释——去问任何一家有 3 万个微服务在生产的公司。

最终，你可以用很多方式来描述库伯内特。你越来越不能忽视它。

如何识别 Docker:Kubernetes 集群中的最新标签

原文：https://www.fairwinds.com/blog/how-to-identify-docker-latest-tag-in-kubernetes-clusters

当你的团队用新功能更新一个应用程序或解决错误时，你将把最新的图像推送到你的 Docker 注册表。在 Kubernetes 中，Docker 的最新标签默认应用于没有指定标签的图像。但是，不指定图像的特定版本会导致各种各样的问题:

基础映像可能包含意外的更改，每当提取最新的映像时，这些更改都会破坏您的应用程序。
对图像的多个版本重复使用相同的标签会导致同一集群中的不同节点具有图像的不同版本，即使标签是相同的。
最新的标签很容易被意外覆盖，并可能导致您将开发分支投入生产。

Kubernetes 文档建议:“注意:在生产环境中部署容器时，应该避免使用:latest 标记，因为很难跟踪哪个版本的映像正在运行，也很难正确回滚。”

识别 Docker:Kubernetes 集群中的最新标签

应定期确定哪些集群正在使用 Docker 最新标签，以避免出现问题。使用 Kubernetes 配置验证平台，只要识别出最新的标签，您就会收到警报。然后，您的团队可以轻松地修复清单，帮助避免应用程序出现问题(停机、错误等)。

Fairwinds Insights 社区版永远免费使用。在此注册试用完整版 30 天。在 GKE、阿拉斯加或 EKS 进行测试，或者在测试集群上运行。

Fairwinds Insights 能够在您的整个部署流程中执行 Kubernetes 策略，因此从 CI/CD 到生产，没有默认的最新标签。虽然这篇博客文章讨论了如何识别违规工作负载，但 Fairwinds Insights 也有助于通过扫描 CI 中的基础架构代码，并在 Kubernetes API 前作为准入控制器运行，从一开始就防止这些工作负载进入您的集群。

通过舵图创建账号，创建集群安装代理可以免费试用。一旦安装了 Fairwinds Insights 代理，您将在 5-10 分钟内获得结果。您可以轻松检查 imagePullPolicy 是否设置为 Always 以及其他可靠性问题，如缺少就绪或活动探测器。

如何识别 Kubernetes Pods 是否以 Root 用户身份运行

原文：https://www.fairwinds.com/blog/how-to-identify-kubernetes-pods-running-root

用 root 访问权限过度授权 Kubernetes 部署通常更容易使某些东西正常工作，但不推荐这样做。它会导致安全问题和过度特权用户。虽然这在开发中可能没问题，但在生产中却是个大问题。随着越来越多的 pod 被创建，您可能会不知不觉地以 root 身份运行许多 pod。

如何识别 Kubernetes pods 是否以 root 用户身份运行

让个人贡献者设计他们自己的 Kubernetes 安全配置几乎可以确保不一致和错误。这通常不是有意发生的，通常是因为工程师专注于让容器在 Kubernetes 中运行。不幸的是，许多人在过程中忽略了重新审视配置，导致了安全性和效率的差距。

负责安全的平台团队可以尝试手动检查每个 pod，以检查错误配置的部署。但是许多 DevOps 团队人员不足，没有足够的带宽来手动检查由各种工程团队引入的每个变更。

这就是为什么我们创建了 Fairwinds Insights ，这是一个配置验证平台，它集成了可信的开源工具，以便团队可以自动扫描集群来检查错误配置。它节省了时间，降低了安全风险。

“我们使用 Fairwinds Insights 作为集群的整体监控工具。它将我们所有的警报和安全性整合在一个地方，有助于减少发现问题所需的资源。”Boxed 公司首席开发工程师 Brent Jaworski

阅读案例研究

Fairwinds Insights 为您提供配置验证

Fairwinds Insights 是一个工具，它向您显示您的团队在 Kubernetes 的哪些地方配置错误。然后，它会提出改进建议，并帮助跟踪和确定修复的优先级。

你可以通过创建账号，创建集群安装代理来免费试用。我们提供了两个代理选项:一个 Helm chart(这允许您定制您的安装)或一个 kubectl 命令。

检查集群的安全状况

一旦安装了 Fairwinds Insights 代理，您将在 5-10 分钟内获得结果。现在，您可以轻松检查集群的安全状况。这里有一个关于它如何工作的快速视频。

使用 Fairwinds Insights 将显著降低生产中的安全事故风险。配置验证平台确保在整个组织范围内遵循安全最佳实践。

如何识别 Kubernetes 中缺失的就绪性探针

原文：https://www.fairwinds.com/blog/how-to-identify-missing-readiness-probes-in-kubernetes

Kubernetes 提供了两种类型的健康检查:就绪性探测和活性探测。

准备就绪探测器旨在确保应用程序已达到“就绪”状态。在许多情况下，在 web 服务器进程启动和准备接收流量之间有一段时间。

29%的 Kubernetes 部署缺乏就绪性调查
来源:Fairwinds Insights 对数千个受监控部署的调查结果

如果准备就绪探测器丢失，Kubernetes 不知道您的 pod 是否完全准备好接收流量。pod 可能会在准确处理请求之前收到请求。准备就绪探测可以确保流量在实际准备好接收流量之前不会被发送到 pod。

如何识别缺少就绪性探测的应用

遗漏准备就绪探测可能是应用程序可靠性的一个问题。手动审核这些探测器的所有 pod 可能非常耗时。当用户复制和粘贴 YAML 时，或者如果没有现有的流程来验证就绪性探针，这也是必须重新考虑的事情。

Fairwinds Insights 是一个策略驱动的配置验证平台(社区版本可以免费使用)，它允许负责 Kubernetes 的团队识别缺失的就绪性探针，并确保从开发到生产都设置了活动和就绪性探针。

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

作为一款 SaaS 解决方案，Fairwinds Insights 会自动扫描集群，以检查就绪探测器缺失的部署。您可以将时间花在包含这些探针上，而不是花在识别缺失探针上。

您可以通过创建账户，创建集群安装代理来免费试用 Fairwinds Insights。我们提供了一个舵图表，允许您定制您的安装。

一旦安装了 Fairwinds Insights 代理，您将在 5-10 分钟内获得结果。您可以轻松地检查是否缺少活动探测器以及其他健康检查，如图像拉取策略未设置为“始终”或缺少标记。

防止遗漏就绪或活性探测

通过在您的 CI/CD 流程中使用 Fairwinds Insights，您可以确保您的策略即代码(OPA 策略)与开箱即用检查一起实施，以防止遗漏就绪性或活性探测。您可以使用它:

作为 CI/CD 挂钩，作为代码评审过程的一部分，审计基础设施即代码
作为准入控制器(又名验证 Webhook)，它将阻止有问题的资源进入集群
作为集群内代理，重复扫描有问题的资源

Fairwinds Insights 可以采用相同的 OPA 策略，并将它们联合到所有三个上下文，以及您想要的任意多个集群。

使用 Fairwinds Insights 将显著改善从 CI/CD 到生产的集群运行状况。策略驱动的配置验证平台可确保整个组织都遵循可靠性最佳实践。

如何识别超限集装箱

原文：https://www.fairwinds.com/blog/how-to-identify-over-permissioned-containers

过度许可的容器具有主机的所有根功能。容器可以访问普通容器中无法访问的资源。虽然可能有一些这样的用例，例如在容器中运行守护进程，但是过度许可/特权容器会破坏隔离。容器不是与它正在运行的主机隔离，而是获得对主机的资源和设备的访问。对于大多数容器，您希望避免这种情况，这样容器就不能:

如何识别超限集装箱

识别 Kubernetes 集群中的特权容器需要时间和资源。Fairwinds Insights 是一个策略驱动的配置验证平台(社区版可以免费使用)，它允许负责 Kubernetes 的团队识别特权容器，并从一开始就阻止特权容器的部署。

Fairwinds Insights 社区版永远免费使用。在此注册即可试用完整版 30 天。在 GKE、阿拉斯加或 EKS 进行测试，或者在测试集群上运行。

Fairwinds Insights 是 SaaS 的一个解决方案，它自动扫描集群以检查特权容器。您的团队节省了识别和跟踪特权容器的时间，并能够利用这些时间来补救问题。

通过舵图创建账号，创建集群安装代理可以免费试用。

一旦安装了 Fairwinds Insights 代理，您将在 5-10 分钟内获得结果。您可以轻松检查设置了特权字段的容器，以及其他安全事件，如可写文件系统、作为根用户运行的容器进程和易受攻击的映像。

首先防止特权容器

Fairwinds Insights 是由政策驱动的。通过在整个部署过程中使用它，您可以确保您的策略即代码(OPA 策略)得到实施。您可以使用它:

作为 CI/CD 挂钩，作为代码评审过程的一部分，审计基础设施即代码
作为准入控制器(又名验证 Webhook)，它将阻止有问题的资源进入集群
作为集群内代理，重复扫描进入集群的有问题的资源

Fairwinds Insights 可以采用相同的 OPA 策略，并将它们联合到所有三个上下文，以及您想要的任意多个集群。

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

使用 Fairwinds Insights 可以从 CI/CD 到生产环境扫描您的配置，从而显著降低安全事故的风险。策略驱动的配置验证平台可确保整个组织都遵循安全最佳实践。

如何实施 FinOps 并增加您的 Kubernetes 成本规避

原文：https://www.fairwinds.com/blog/how-to-implement-finops-and-increase-your-kubernetes-cost-avoidance

许多组织最近开始在生产中使用 Kubernetes，并且刚刚开始看到 Kubernetes 和云成本的真实情况。团队发现 Kubernetes 的成本高于预期并不罕见。随着越来越多的工作负载转移到生产中，许多组织发现他们需要控制这些 Kubernetes 成本，或者(至少)了解这些成本。有一些策略和工具可以帮助组织了解他们的 Kubernetes 成本，以及如何实施 Kubernetes 成本规避策略——实施 FinOps 可以帮助实现这些目标。

什么是 FinOps？

FinOps 是一种尝试确定与您的云支出相关的单位成本，并将您组织(尤其是大型组织)中的不同孤岛整合在一起，以持续讨论并更好地了解云成本，以及这些成本如何影响业务决策的实践。使用 Kubernetes 的团队发现这尤其具有挑战性。在这里，我们将讨论 FinOps 基金会确定的 FinOps 的六项核心原则，以及在使用 Kubernetes 时它们之间的关系:

1。团队必须合作

为了拥抱 FinOps，团队必须一起工作。财务团队需要以与 IT 团队相同的速度和粒度前进。工程团队还必须从效率的角度考虑成本，并采用成本作为他们考虑的衡量标准。组织必须不断改进其 FinOps 实践以提高效率和创新，同时定义云和 Kubernetes 治理并实施对云使用的控制

2。采用云使用的所有权模式

当功能和产品团队能够管理他们自己的云使用并根据他们的预算进行衡量时，他们就能够做出更好、更具成本效益的决策。Kubernetes 所有权模型有助于团队提高对跨工作负载的云支出的可见性，并通过在团队级别进行跟踪来提高责任性。

3.集中化推动财务运营

有几种方法可以让团队集中管理和控制云的使用，比如使用承诺使用折扣、保留实例和云提供商的批量/定制折扣。通过使用折扣购买的集中流程，工程团队不再需要考虑价格谈判。云使用的集中方法支持精细的成本分配，因此负责的团队和成本中心可以看到所有成本，无论是直接成本还是分摊成本。

4。及时、可访问的报告

创建一个报告及时且易于访问的环境至关重要，因为它使团队能够及时利用关于支出和效率的反馈。这还可以帮助服务所有者评估资源是过度调配还是调配不足。当资源被自动分配时，它推动了云使用的持续改进。

5。业务驱动的云价值决策

使用趋势和差异分析有助于团队理解成本增加的原因以及他们可以做些什么来避免成本。内部团队也可以使用基准来显示最佳实践的有效使用，并确保这些实践得到执行。使用行业同行的基准测试也可以帮助您的组织了解它与其他组织相比表现如何。

6。利用云的可变成本模型

有许多工具可以帮助您正确地确定实例和服务的规模，这将帮助您的组织确保拥有适当的资源配置级别。了解正确的资源配置水平将有助于您做出更好的决策，因为您可以根据自己的实际需求比较不同服务和资源类型的定价。

FinOps 为什么重要？

现在，随着我们进入潜在的经济衰退，许多组织都在考虑他们的开支。许多组织最近转向了云原生架构，并采用了 Kubernetes。如果你是其中之一，这是一个很好的时机来审视你的工具，你的云足迹的成本，并为 KubernetesT3 采用FinOps 模型。能够理解为什么事情要花费成本，实际成本是多少，单位成本是多少，将有助于您对 Kubernetes 环境做出更好、更明智的决策。有几个不同的指标可以帮助您了解您的支出，为什么成本可能会增加，以及这些增加是否符合您的业务目标。

例如，在 Fairwinds，我们关注我们环境中每个集群的云支出。我们还会查看每位客户的支出，然后以几种方式对数据进行分割。这让我们可以看到我们的总账单是否在上升。如果是，增加的原因是:

我们产品中更大的功能集？
更大的客户足迹？
扩大的客户群？
个人客户现在的足迹更大了？

如果整体账单在上涨，而其他要素持平或下跌，那就是一个需要注意的信号。审查每个客户的云支出是一个持续的过程，可以提供整个组织的云成本的可见性。

FinOps 在 Kubernetes 有什么不同？

云支出和 Kubernetes 支出之间的差异——以及采用 FinOps 方法——实际上源于容器和其他类型的抽象。这种抽象去除了人们熟悉的一些工件。例如，在过去，您可以查看账单并了解实例的成本、实例 ID、您熟悉的卷，或者在您的云环境中查找标签。

Kubernetes 引入了另一层抽象，部分是因为 Kubernetes 中的东西是短命的。今天在这里的节点明天就会消失，当您考虑云成本和共享资源时，这变得很难跟踪。这使得很难将支出分配到每个客户的成本、每个团队的成本或不同环境的成本。这些分配挑战增加了组织的复杂性，因为它们在云 API 和您正在部署和运行的东西之间注入了另一个抽象层。

为什么 FinOps 对容器和 Kubernetes 很重要？

在 Kubernetes，FinOps 面临两个团队难以应对的挑战。第一个是现在集群的分离方式。有一个叫做名称空间的概念，它是集群中的一个隔离结构。它允许您隔离资源，无论它们是应用程序、团队还是不同的环境。你可以把它想象成一个虚拟集群。这个概念很棘手，因为它存在于您在构建中跟踪的不同节点和部分中。你的一对多关系越多，就越难追踪。

另一个挑战是扩展。Kubernetes 的优势之一是，当流量增加时，它会根据您的需要不断添加更多资源，以使环境变得更高可用或更具可扩展性。然而，这种扩展能力推高了成本，因为云中的一切都是计量的。当财务团队询问成本增加的原因时，您需要一种简单的方法来解释每个应用程序的成本。准备好这些信息可以增强组织内部的信心，这也有可能推动向 Kubernetes 的迁移，因为财务团队确信他们了解组织的相关成本。

和你的首席财务官成为好朋友

财务团队通常不知道 Kubernetes 如何工作，Kubernetes 是什么，或者成本是多少。特别是在更大的组织中，旧的财务模型认为，要花钱，你需要做一个业务案例，提交给财务或采购部门，获得批准，然后你就可以花钱了。FinOps 模型迫使业务和工程之间进行对话，财务团队解释他们的约束以及他们预测成本和预算需求所需的信息。组织的工程方面必须能够理解更大的背景。理想情况下，工程团队了解并能够解释他们可以预测什么，他们如何围绕支出创建护栏，以及云模型在扩展产品或扩大客户足迹的能力方面提供的机会。这种方法鼓励整个组织的伙伴关系。

让 FinOps 和工程部门谈谈

你如何和你的工程师谈论管理成本？大多数工程师只想部署东西；他们想写运行的代码，他们不关心成本。对于工程师、用户或开发人员来说，要了解部署基础设施的最重要的事情是所部署内容的影响。如果您没有正确分配资源或过度配置，您的工程师需要了解他们的行为会推动组织的盈利能力。通常，如果您做出不正确的云承诺，实际上可能会比使用按需或按需付费花费更多，这在财务上是危险的。由于不正确地两面下注，你花的钱远远超过了你应该花的。您需要在工程和财务团队之间进行有节奏的对话，以便他们能够一起获得潜在的节约，并了解一些原始成本以及这些决策对组织的业务影响。

如何实现 FinOps？

创建一个持续的流程，在此流程中，您可以回顾员工的工作内容，一起查看数字，并查看单位成本，这有助于您提出重要的问题，例如:

这个费用合理吗？
为什么或为什么不？
为什么会产生这些成本？
如果我们认为有问题，我们能做些什么来降低成本？
缓解成本值得吗？
你会创造出与你所花费的时间和金钱相等或更好的节约吗？

回顾这些事情，并从长期成本和节约的角度考虑它们，将有助于您做出更好的 Kubernetes 成本避免决策。这是一个持续的过程，它将帮助你建立一个 FinOps 实践，使 Kubernetes 成本与商业决策相一致。

工具支持 FinOps 方法

有本地 Kubernetes 工具可以帮助您了解您的成本。 AWS Cost Explorer 是一个很棒的工具，还有来自不同云提供商的其他工具。这些工具有助于您了解云的使用情况以及账单上消费的单个行项目。您可以使用标签和标记来帮助您了解成本。设置名称空间并始终如一地使用它们也将帮助您更好地了解您的成本。

Goldilocks 是一个与垂直 Pod 自动缩放器 (VPA)结合的工具，后者是 Kubernetes 的一个附加组件，允许您自动垂直调整 Pod 的大小(这意味着设置您的资源请求和限制 )。开源工具 Goldilocks 位于 VPA 之上，并根据您的工作负载的历史使用情况提出更改建议。

当您查看单个集群时，很容易部署一个导航图或安装并使用一些工具，然后查看一两个控制面板。当您开始在整个组织中采用 FinOps 方法，并需要在不同的环境中创建标准时，很难大规模地做到这一点。Kubernetes 的政策往往不一致，您可能不了解整个组织的所有成本。在这种情况下，拥有一个统一数据的平台是非常有用的，并且可以更容易地看到整个组织在 Kubernetes 和云成本方面发生了什么。fair winds Insights使用开源工具，包括 Goldilocks，来形成一个平台，帮助您在所有集群中部署工具，自动执行策略，并轻松查看统一数据，以增强控制和可见性。

观看网络研讨会“ Kubernetes 成本规避:实施 FinOps ”,与工程运营副总裁 Elisa Hebert、首席技术官 Andy Suderman 和高级解决方案架构师约翰·哈什姆三世一起了解如何在您的组织中实施 FinOps。

操作指南:KMS 秘密后端

原文：https://www.fairwinds.com/blog/how-to-kube-kms-secrets-backend

在这一部分中，Fairwinds 首席研发工程师 Andy Suderman 演示了如何使用亚马逊提供的 KMS 密钥加密 Kubernetes 集群中的所有秘密。

如何 Kube: KMS 的秘密

原文：https://www.fairwinds.com/blog/how-to-kube-kms-secrets

安全性是网络上所有人最关心的问题，尤其是那些使用 Kubernetes 的人。由于平台上没有任何预先配置的安全设置，因此由您来确保您的节点和集群是安全的。这就是加密在保护您最敏感的数据方面如此重要的原因。

密钥管理服务(KMS)是一种在 Kubernetes 中加密秘密的廉价方式。使用 KMS 可以通过控制加密密钥和元数据的机密性、完整性、可用性和来源验证来确保它们受到保护。

请继续阅读如何设置亚马逊提供的密钥管理服务的分步指南。

构建 AWS 加密提供程序 Docker 容器

首先，前往 Kubernetes sigs AWS 加密提供者存储库。在存储库中，运行“make docker build”来构建 docker 容器。
用您控制的存储库的名称标记 docker 容器，并将其推送到该存储库。这确保了 docker 容器在 Kubernetes 集群上——特别是主节点上——是可用的。
既然 docker 容器被推送到存储库，那么您需要创建一个 KMS 键。

创建一个 KMS 键

要创建 KMS 键，请执行以下操作:
- 打开 AWS 控制台，
- 点击“创建密钥”
- 选择“对称密钥”
- 给它起个你能记住的名字
- 为您的密钥分配默认选项(在此阶段没有必要分配使用权限)。
创建密钥后，在“客户管理的密钥”下找到它，并记录 ARN，以便在后面的步骤中使用。

配置节点策略

接下来，您需要创建一个节点策略，允许主节点使用您刚刚创建的密钥进行加密和解密。
将此策略添加到“附加策略”主部分的 to kops 集群规范中，然后保存文件。
然后，在 kops 集群规范下，添加“encryptionConfig”并将其设置为 true。
最后，您需要添加一个文件资产，在每个主节点上创建一个静态 pod。静态 pod 的清单包括:
- 您之前推送的图像名称
- 您创建的 KMS 键的 ARN
- 您在其中创建密钥的区域

创建加密配置

接下来，您需要创建一个加密配置 yaml 文件。该文件指定应该使用 AWS 加密提供程序在您在 static pod 中创建的 unix 套接字上加密机密。
使用“kops create secret”命令将此加密配置创建为 kops secret。
既然集群配置已经就绪，并且加密配置被保存为一个秘密，那么是时候替换集群 yaml 并输入“kops update cluster - yes”了。
Kops 随后将指示需要滚动重启主设备。继续执行滚动更新。

一旦滚动更新完成，您的集群将被配置为使用密钥管理服务加密所有新创建的秘密！这确保您可以在不暴露主密钥的情况下加密/解密数据，并且您的加密参数总是很强。

关于如何解决 Kubernetes 集群安全性的更多技巧，查看这篇博文。

操作指南:Pod 基础知识

原文：https://www.fairwinds.com/blog/how-to-kube-pod-basics

在这一部分中，Fairwinds SRE 公司的 Kim Schlesinger 将向您展示如何使用 nginx 图像创建 pod、查看 yaml 以及删除 pod。

操作指南:服务

原文：https://www.fairwinds.com/blog/how-to-kube-services

站点可靠性工程师 Ivan Fetch 解释了如何使用服务来公开 pods 并帮助应用程序在 Kubernetes 中进行通信。他将描述三种类型的服务，并演示一个针对多个 pods 的负载平衡器服务。

如何 Kubernetes:使用 Conftest 审计基础设施即代码

原文：https://www.fairwinds.com/blog/how-to-kubernetes-use-conftest-to-audit-infrastructure-as-code

在 Fairwinds，我们在我们的开源产品 Polaris 以及我们的 SaaS 产品fair winds Insights中利用 OPA ( 开放策略代理)。随着我们的开发团队实现这些功能，我开始思考我们可以利用 Fairwinds 的 OPA 来增强我们 Kubernetes 环境的可靠性和安全性的其他方法。

与此同时，我试图想出一种方法来更好地审计我们的许多基础设施即代码库。对于我们的每个客户，都有一个回购协议，我们为该客户所做的一切都会进入回购协议。可以想象，跨客户的标准会逐渐过时，我们需要知道他们什么时候会过时。目前我们有一个基于 Python 的内部解决方案来做这件事，但是它变得有点笨拙和过时了。计划是重写它，但 EJ(我们的前首席技术官)有一个更好的主意:“为什么我们不使用 OPA？”我的回应当然是 facepalm。我怎么没想到呢？因此，我四处查看了 OPA 资料库，重温了我对 rego, 的一点点知识，并整理了一份概念证明。我需要一种运行和测试策略的方法，所以我更新了我的版本conftest，事实证明，它被设计来做我需要做的事情:审计配置文件。

撰写政策

下一步，写保单，是最难的部分。作为一个经常使用 Python 和 Go 等语言进行开发的人，这比我想象的要困难得多。 Rego 不是一种编程语言，而是一种查询语言，这意味着我需要思考这一切的方式与我通常的思考方式不太一样。一旦你进入了它的最佳状态，它就会变得非常强大，但这花了我相当长的时间。我决定从检查我们正在使用的 Terraform 模块的版本开始，并将其与批准的模块列表进行比较。在野外有很好的例子，所以我能够找到这些例子并开始行动。我能写的最基本的策略是这样的:

package terraform

import data

violation[{"msg": msg}] {
    m := input.module[name]
    source := m.source
    not source == "git::https://github.com/FairwindsOps/terraform-vpc.git?ref=v5.0.1"
    msg = sprintf("%s module version %s is out of date", [name, source])
}

第一行， package terraform, 只是允许我将策略分成多个部分。最终，我要用一堆不同的模块来结束，比如 terraform, kops, 和 kubernetes. 当使用此策略与 conftest, 时，我们将使用--namespace=terraform标志来定位 terraform 模块。策略的下一部分读入传递给它的 terraform 数据中的所有模块，并将每个模块与一个静态字符串进行比较。如果有匹配，则返回 msg 作为违规。

这个政策是有作用的，但是并没有完全达到我们想要的效果。我们需要添加针对不同字符串检查不同模块名称的功能。这需要一个映射变量，我们可以用它来指定多个模块名，我们称它为 module_allowlist. ，这给了我们以下内容:

package terraform

import data

module_allowlist = {
    "vpc": "git::https://github.com/FairwindsOps/terraform-vpc.git?ref=v5.0.1",
    "bastion": "git::https://github.com/fairwindsops/terraform-bastion.git//aws?ref=aws-v0.6.0",
}

violation[{"msg": msg}] {
    m := input.module[name]
    source = m.source
    not source == module_allowlist[name]
    msg = sprintf("%s module version %s is out of date", [name, source])
}

这里我们将实际模块源与 module_allowlist 图中的对应源进行比较。这样更好，但是我们有另一个问题:有多个允许版本的模块怎么办？上面的bastion模块就是一个很好的例子；我们期待不同版本的bastion取决于你使用的云提供商。让我们将地图格式更改为 module_name: [list of possible versions]. 新的策略看起来是这样的:

package terraform

import data

module_allowlist = {
    "vpc": ["git::https://github.com/FairwindsOps/terraform-vpc.git?ref=v5.0.1"],
    "bastion": [
        "git::https://github.com/fairwindsops/terraform-bastion.git//aws?ref=aws-v0.6.0",
        "git::https://github.com/fairwindsops/terraform-bastion.git//gcp?ref=gcp-v0.1.1",
    ],
}

violation[{
    "msg": msg,
}] {
    m := input.module[name]
    source = m.source
    not contains(module_allowlist[name], source)
    msg = sprintf("%s module version %s is out of date", [name, source])
}

contains(sources, elem) {
    source := sources[_]
    source == elem
}

现在我们有了一个可能版本的列表，我们引入一个函数 contains 来检查我们的源模块是否在该模块允许的源列表中。这意味着通过用更多的信息填充映射，我们可以检查所有种类的模块版本，而不仅仅是一个。

我们最不希望这个策略在将结果输出为 JSON 时返回更多的数据。我们的目标是能够存储、呈现或分析这些数据，因此它有助于添加更多的细节。幸运的是，机制已经存在，我们只需要利用它。

这个文件的最终产品，叫做 terraform.reg:

package terraform

import data

module_allowlist = {
        "vpc": ["git::https://github.com/FairwindsOps/terraform-vpc.git?ref=v5.0.1"],
        "bastion": [
                "git::https://github.com/fairwindsops/terraform-bastion.git//aws?ref=aws-v0.6.0",
                "git::https://github.com/fairwindsops/terraform-bastion.git//gcp?ref=gcp-v0.1.1",
        ],
}

violation[{
        "msg": msg,
        "family": "terraform",
        "check": "module version",
        "module": name,
}] {
        m := input.module[name]
        source = m.source
        not contains(module_allowlist[name], source)
        msg = sprintf("%s module version %s is out of date", [name, source])
}

contains(sources, elem) {
        source := sources[_]
        source == elem
}

在违例的定义中，我们增加了几条数据:

"msg"——变量 msg中我要返回的消息。这已经到位了
"family" -表示数据来源的字符串，本例中为 terraform
"check"——我希望能够说出我在检查什么。在这里，是 "module version"
"module" -这将通过变量 name设置为触发违规的模块的名称

最终结果是我们现在可以运行:

conftest test <path-to-terraform-file(s)> --policy terraform.rego -ojson --namespace  terraform

得到这样的输出:

[
  {
    "filename": "bastion.tf",
    "namespace": "terraform",
    "successes": 0,
    "failures": [
      {
        "msg": "bastion module version git::https://github.com/fairwindsops/terraform-bastion.git//aws?ref=aws-v0.5.0 is out of date",
        "metadata": {
          "check": "module version",
          "family": "terraform",
          "module": "bastion"
        }
      }
    ] }
]

或者，如果您喜欢在 CLI 上查看结果，请放下 -o json 标志:

FAIL - bastion.tf - terraform - bastion module version git::https://github.com/fairwindsops/terraform-bastion.git//aws?ref=aws-v0.5.0 is out of date

添加测试

rego 还有另一个我想利用的非常棒的功能: 单元测试。这对于制定政策以及长期维护政策来说是非常强大的。为了测试这个功能，我为上一节中的terraform.rego策略编写了一个测试。下面是我新的terraform_test.rego文件:

package terraform

empty(value) {
    count(value) == 0
}

no_violations {
    empty(violation)
}

test_module_source {
    violation[{"check": "module version", "family": "terraform", "module": "bastion", "msg": "bastion module version git::https://github.com/fairwindsops/terraform-bastion.git//aws?ref=aws-v0.0.0 is out of date"}] with input as {"module": {"bastion": {"source": "git::https://github.com/fairwindsops/terraform-bastion.git//aws?ref=aws-v0.0.0"}}}
}

本质上，如果我传入一个名为 bastion 的模块，而这个模块的版本不在我的列表中，我认为会有一个违例。该测试可以使用命令 conftest verify. 运行

结论

现在，我有能力编写一整套审计策略，针对我们所有的基础设施代码运行它，并生成结构化的 JSON 数据，这将允许我分析结果并报告发现。更好的是，由于fair winds Insights支持 OPA，我可以插入这些策略，让 Insights 为我收集和管理这些数据。这可能会成为我们工作流程中不可或缺的一部分，使我们的服务代表能够更好地管理许多客户，并在此过程中收集有用的信息。

如何利用 AWS Lambda 进行开发运维备份和恢复

原文：https://www.fairwinds.com/blog/how-to-leverage-aws-lambda-for-devops-backup-and-recovery

丢失数据可能意味着失去业务，那么您如何确保云不会让您崩溃呢？通过密切跟踪哪些信息发生了更改，谁在何时更改了它。这意味着提前识别所有可能发生的故障或灾难情况及其潜在的业务影响。

这里有三个有用的【亚马逊网络服务(AWS) 工具可以考虑:

I. CloudTrail 是一个 web 服务，为控制台中和通过 API 发生的所有操作提供帐户审计跟踪。监控和警报可以让您知道是否正在进行意外的更改以及由谁进行的更改。
二世。 Config 是一项完全托管的服务，具有 AWS 资源清单、配置历史记录和配置更改通知，可实现安全性和监管。
三。 Lambda 可用于运行备份过程，无需配置或管理服务器。您可以直接利用 AWS API 来操作您的云资源，并自动触发来自其他 AWS 服务的事件。

Lambda 目前在 DevOps 领域特别热门，因为它可扩展且可靠，并且不包含大量开销和成本，此外，您可以使用它来定制您的备份计划，以满足您的业务和基础架构需求。Lambda 值得仔细看看。

Lambda 是一个事件驱动的无服务器计算平台，作为 AWS 的一部分提供。在 AWS 全球云计算大会 AWS re:Invent 2014 上推出的 Lambda 让构建响应事件的按需应用变得更加容易。您可以编写自己的备份过程，而不必维护任何额外的基础结构。这是一个设置全自动备份系统和运行代码的理想计算平台——只要你知道它支持的语言之一( Node.js 、 Java 、 C# 和 Python )。

Lambda 允许您将备份脚本设置为仅在需要时执行。您可以通过将脚本设置为基于时间(每分钟、每 10 分钟或每晚)或操作(例如当有人向 S3 存储桶写入内容时)触发来备份特定数据集。

例如，您可以每天晚上对数据库进行快照，然后触发 Lambda 函数将快照复制到您的备份帐户。如果你一天要写 500，000 张收据到一个 S3 桶，你可以运行你的 Lambda 脚本 500，000 次，并保持一个实时备份。

Lambda 是云原生的，所以你不需要支付一大笔许可费，也不需要投资一个不符合你需求的备份产品。云原生产品支持工具之间的简单通信。如果你正在备份一个 RDS 数据库，你的 Lambda 函数本质上可以直接与它对话，因为它们都生活在亚马逊世界中，说着同样的语言。还可以分配 Lambda 函数来处理安全策略和权限。

进入壁垒

迄今为止，Lambda 没有像更传统的解决方案那样被广泛使用。进入的障碍包括不熟悉平台和使用平台所需的努力程度。有了 Lambda，你必须决定你要备份什么，编写代码，确保代码不会失败，并创建处理异常值的应急计划。笨重、昂贵的备份解决方案看起来更高效，因为它们具有交钥匙性质。

简而言之 AWS Lambda

尽管如此，Lambda 的战略优势仍然大于挑战:

获得一个无需额外基础架构管理的云原生平台。
定制 AWS Lambda 备份以满足您的需求，利用 Python 和Boto 3(Python SDK)编写备份函数。
使用 AWS API 功能复制、备份、更改权限和移动资源。
获得更高的灵活性、可靠性和耐用性，以及更低的成本和自动可伸缩性(从每天几个请求到每秒几千个请求)。

为了充分利用 AWS Lambda 备份功能，您需要打破常规。选择人迹罕至的道路，你会在前进的道路上获得巨大的收益。

如何让你的开发者成为坏蛋

原文：https://www.fairwinds.com/blog/how-to-make-your-developers-badass-with-kubernetes-and-devops-as-a-service

在 上一篇博文 中，我考察了为什么许多公司对拥抱 Kubernetes 犹豫不决，以及它的复杂性实际上如何有利于未来的增长。在这里，我将展示如何利用 Kubernetes 和 Fairwinds 的力量让您的开发人员变得强大。

在 Badass:让用户牛逼 ，Kathy Sierra问为什么一个产品在竞品拥有同等定价、促销和感知质量的情况下销量超过其他产品。答案与用户有关。用户不在乎你，也不在乎你的产品；他们关心的是你的产品是否让他们变得更。

Kubernetes 让开发者可以做以前做不到的牛逼事情。您的工程师不想管理您的基础架构。他们想成为坏蛋。他们很难找到、吸引和留住，所以为什么不给他们想要的呢？您将拥有更快乐的开发人员、更轻松/更快速的部署、更少的停机时间&以及更快的恢复时间。Kubernetes 提供了更好的开发者/用户体验。

获得更灵活的 Heroku 式体验

Heroku 以其极其简单的平台即服务起步而闻名于世。Heroku 的界面并不复杂:没有人认为 Heroku 过分。如果有什么不同的话，大多数对此事有意见的人认为它太局限了。然而在幕后，Heroku 是极其复杂的。他们的成功部分源于用户看不到这种复杂性。

需要明确的是，技术上的权衡并不是在运营复杂的高度复杂的 Kubernetes 环境中，而是在不复杂的情况下拥有出色的开发人员用户体验，以及拥有出色的开发人员用户体验。如果这是一个交易，Kubernetes 就不会存在。 权衡实际上是在 Kubernetes 这样的东西和简单地做错事之间，Kubernetes 使做错事变得困难而做对的事变得容易。

人们很容易被复杂性吓倒。很容易求助于 EC2 或 Docker Swarm ，在那里容易的事情是琐碎的，而困难的事情是不可能的。然而，重要的是要记住一定的复杂性是必不可少的。

选择开发运维即服务，以便有人为您管理复杂性

如果你自己实现 Kubernetes，你需要了解整个 Kubernetes 世界。你是怎么安装的？(Kubernetes 没有安装程序。)应该用什么工具？(有十几种可能的工具，选择哪个安装程序并不容易。)假设您选择了 kops 这样的安装工具，您如何确保您的基础架构是可重复的？在发生灾难时，您如何确保您可以在不丢失任何东西的情况下在其他地方启动您的基础架构？(您需要自动化所有这些工作，以便在必要时可以重新创建集群。)

这种学习非常耗时，对你没有好处，也不会给你的企业增加价值。你会有最糟糕的技术债务(基础设施债务和编程代码债务)，而且你永远也不会还清。

你不需要了解哪些 API 在未来的版本中被弃用，也不需要知道调用哪些 API。你不需要了解库伯内特 YAML 的来龙去脉。作为我们开发运维即服务方法的一部分，我们通过管理大量 Kubernetes YAML、管理所有持续集成/持续交付(CI/CD)并为您提供一个简单的界面，让您远离这种复杂性。Kubernetes 是以 Heroku 建筑为核心的建筑。在 Fairwinds，我们用 Kubernetes 为您做与 Heroku 相同的事情，除了我们定制 Kubernetes 以满足您特定的工作流程要求。

有了合适的团队，Kubernetes 的复杂性就很容易管理。在 Fairwinds，我们通过编写使 Kubernetes 更易于使用的开源工具来实现规模经济和投资回报。 DevOps 即服务是我们的业务，开源的 Kubernetes 工具是我们的业务模式。

我们的目标？照顾与您的架构相关的每一个细节，因此您不必担心它。

本质的复杂性造就了一个糟糕的解决方案

Kubernetes 很复杂。但是当别人为你管理它时，这种复杂性是值得的。选择一个 DevOps 即服务提供商，为您提供您的开发人员想要的强大 Kubernetes 系统，同时消除所有相关的复杂性。

记住，当你不知道自己不知道的事情时，很容易选择走自己的路。开始使用其他编排工具很容易——事实上太容易了，以至于这些工具最终会限制您所能做的事情，就像 Heroku 一样。入门的容易掩盖了复杂性。最终你会发现你错过了什么。当您准备好体验我们基于 Kubernetes 的 DevOps 即服务方法时(在您的第二次或第三次竞技表演后)，您会想知道没有它您是如何生活的。

一旦你开始使用 Kubernetes，前途无量。您可以获得出色的 Kubernetes 用户体验，这也是您想要它的原因，而且您不必担心构建 Kubernetes 基础架构所涉及的无聊问题。

80%的财富 500 强企业使用 Kubernetes，这可能并不奇怪。但是故事并没有就此结束。中型公司使用 Kubernetes。十人创业公司用 Kubernetes。Kubernetes 不仅仅面向企业。对于各种规模的前瞻性公司来说，这是一笔真正的交易。

那么，如何确保 Kubernetes 迁移成功呢？选择合适的伴侣而不是自己动手。

但是不要相信我们的话。听听范多尔的迈克尔·图辛斯基怎么说。正如他所说，“费尔温斯让我们远离了库伯内特的复杂性。我们看到的只是一个愉快的 CI/CD 界面，我们完全不用担心。我们根据具体的业务挑战做出了明智的选择，选择了正确的工具 Kubernetes 和正确的团队合作伙伴 Fairwinds。”

在多集群、多云计算环境中运营 Kubernetes

原文：https://www.fairwinds.com/blog/how-to-operate-kubernetes-in-a-multi-cluster-multi-cloud-world

当跨多个云帐户操作多个 Kubernetes 集群时，如何在最大限度地减少意外更改的同时提高工作效率？在这篇文章中，我将分享一些最佳实践和开源工具，Fairwinds 的团队认为这些对 Kubernetes 从业者很有价值。您还可以观看一个附带视频的来观看解说视频。

库贝特尔

在安装 kubectl 时，Kubernetes 命令行界面为 Bash 或 Zsh 配置 shell 完成。这允许您按 Tab 来完成 kubectl 命令和 Kubernetes 资源名称，比如部署或 pod。确保安装了 bash-completion 先决条件包。上面指向 kubectl 安装文档的链接包括设置其 shell 完成的细节。

laptop:~$ kubectl get pod [tab]app-7f5fd6f95c-[tab twice]
app-7f5fd6f95c-bnkwj app-7f5fd6f95c-lg9pg
laptop:~$ kubectl get pod app-7f5fd6f95c-b[tab]nkwj

上面的例子使用 tab 来帮助完成一个 kubectl get pod 命令。因为两个 pod 共享相同的“7f...5c”字符串，按 tab 键两次会显示两个窗格。然后，我键入“b”作为决胜符，并再次按 tab 来完成我想要的 pod 的名称。

也可以用 tab 键补全我可能会忘记的命令名，比如 kubectl api-resources。

在集群和名称空间之间切换

没有什么比意外地在不同的 Kubernetes 集群中进行更改更能影响您一天的轨迹了——“哦，不，我以为我在 staging 中删除了那个负载平衡器服务！”

kubectl 使用的 Kubernetes 客户机配置将访问参数分组到上下文中。每个上下文都指一个集群、一个用户和当前的默认名称空间。在一个 Kubernetes 客户机配置文件中可能有多个上下文，分别代表不同的临时和生产 Kubernetes 集群。

kubectl 命令可用于在单个 Kubernetes 客户端配置(KubeConfig)文件中定义的多个上下文之间切换，如关于多集群访问的 Kubernetes 文档中所述。然而， kubectx 和 kubens 工具使得在上下文之间切换和设置当前名称空间变得更加容易。对于没有 Bash 或 ZSH 的微软 Windows 用户来说，这些工具直接支持 Windows，并且在 Golang 中进行了相对较新的重写。

分离 Kubernetes 上下文

为每个环境使用单独的 KubeConfig 文件，需要更明确的操作来使用特定的上下文或集群。将 KUBECONFIG 环境变量设置为要使用的 KubeConfig 文件。默认情况下，这可以避免同时访问所有集群。给 Kubernetes contexts 起一个有意义的名字，并在 shell 提示符下显示当前的上下文也是有帮助的——下面将详细介绍。

Extend Kubectl

kubectl 命令可以使用插件来扩展——要了解更多关于如何增强 kubectl 命令行的技巧，请查看我们关于 kubectl 插件和 krew 插件管理器的博文，并查看这些 Krew 插件:

RBAC-查找 -轻松查找与任何用户、服务帐户或组相关的角色和集群角色
谁能显示哪些主题拥有 RBAC 权限
证书管理器 -帮助管理由证书管理器群集附加组件管理的资源

管理不同版本的工具

升级是一种持续的生活方式，您可能有不同版本的 Kubernetes、Helm 或其他基础设施管理工具，如 Terraform。理想情况下，版本的 kubectl 与版本的 Kubernetes API 相匹配，团队中的每个人都使用相同版本的 Helm 来管理集群插件或应用程序。一个版本管理器，如 asdf ，管理命令行工具的多个版本，以及 Python、Node 或 Ruby 等语言。asdf 工具版本文件可以包含在项目或存储库目录的顶部，以便根据当前工作目录配置使用哪个版本的工具。asdf 工具使用插件来支持许多工具和语言。

laptop:~$ asdf plugin add kubectl
laptop:~$ asdf list all kubectl
…..
1.19.2
1.19.3
1.20.0-alpha.1
1.20.0-alpha.2
…..
laptop:~$ asdf install kubectl 1.19.3
Downloading kubectl from https://storage.googleapis.com/kubernetes-release/release/v1.19.3/bin/darwin/amd64/kubectl
laptop:~$ cd /path/to/project/directory
laptop:~$ asdf local kubectl 1.19.3
laptop:~$ cat .tool-versions
kubectl 1.19.3

上面的例子为 kubectl 添加了 asdf 插件，列出了可用的 kubectl 版本，安装了 1.19.3 版本，并配置了一个项目目录以使用该版本的 kubectl。

Asdf 还支持使用环境变量来配置使用哪个版本的工具，如果您的工作流有助于改变您的环境而不是依赖于当前的工作目录。例如，将 ASDF _ 库 ECTL_VERSION 环境变量设置为“1.19.3”。

多个云帐户

有时，有必要检查 Kubernetes 节点的计算实例，这可能跨越多个环境，这些环境可能使用不同的云帐户、项目或订阅。 AWS 、 Google 和 Azure 的云命令行接口支持使用环境变量控制配置。这些环境变量可以使用 direnv 工具基于您当前的工作目录进行更改，该工具在您“cd”到一个目录时设置环境变量。

亚马逊网络服务

使用 aws configure - profile …命令为每个环境配置一个配置文件，并通过- profile 命令行参数或 AWS_PROFILE 环境变量使用该配置文件。

laptop:~$ aws configure --profile production
AWS Access Key ID [None]: xxxxx
AWS Secret Access Key [None]: yyyyy
Default region name [None]: us-east-2
Default output format [None]: text
laptop:~$ aws --profile production s3 ls
…..
laptop:~$ export AWS_PROFILE=production # Use this profile while the variable is set

谷歌云

使用 g cloud config configuration s create 命令为每个环境创建一个单独的配置。使用 gcloud config set 命令来设置 Google 帐户和项目等属性。通过 CLOUDSDK_ACTIVE_CONFIG_NAME 环境变量指定哪个配置是活动的。

laptop:~$ gcloud config configurations create qa
Created [qa].
Activated [qa].
laptop:~$ gcloud config set account ivan@fairwinds.com
Updated property [core/account].
laptop:~$ gcloud config set project qa                
Updated property [core/project].
WARNING: You do not appear to have access to project [qa] or it does not exist.
laptop:~$ export CLOUDSDK_ACTIVE_CONFIG_NAME=qa # Use this configuration while the variable is set
laptop:~$ gcloud auth login
…..
laptop:~$ gcloud auth application-default login # Optional, if using tools like Terraform

蔚蓝色的云

为每个环境的命令行配置文件使用单独的目录。设置 AZURE_CONFIG_DIR 环境变量，然后使用 az login 和 az account set 命令为该环境配置 AZURE 命令行。

laptop:~$ export AZURE_CONFIG_DIR=~/infra/test/.azure
laptop:~$ az account show # demonstrates this is a new config
Please run 'az login' to setup account.
laptop:~$ az login
…..
laptop:~$ az account set --subscription xxxxx

我在哪里？在你的提示中反映事情

快速灵活的 Starship 提示符定制工具可以在您的 shell 提示符中显示 Kubernetes 和云信息，以帮助了解哪个 Kubernetes 集群和云帐户是活动的。 Kubernetes 组件显示当前的上下文，也可以显示 KubeConfig 文件中定义的当前名称空间。还有 AWS 和 gcloud 组件来包含关于那些云的信息。环境变量和定制命令组件可用于提供额外的上下文，包括活动 Azure 订阅。

请看随附的视频，及其示例星舰配置。我们希望这有助于您跨多个云操作 Kubernetes 集群。

如何合理调整您的 Kubernetes 工作负载

原文：https://www.fairwinds.com/blog/how-to-rightsize-your-kubernetes-workloads

是时候对你选择的云进行第一次大的投入了，或者你正准备更新一次投入，并且需要所有的细节来把事情做好。在你签下一大笔钱之前，你要确保你签下的细节是正确的，并且与你实际花费的一致。如果你没有用完，承诺消费没有折扣。事实上，它最终会让你付出更多。所以知道承诺什么很重要。

合理调整和优化

为了使您的云或续订提交尽可能准确，您需要正确调整实例、工作负载和优化计算。对于许多组织来说，云支出是一项巨大的成本，不必要的支出对任何组织来说都是糟糕的选择。与此同时，挖掘应用程序资源和历史使用情况的细节以做出决策可能是一个真正的挑战。大多数组织对其 Kubernetes 环境的效率知之甚少。

缺乏可见性使得在 Kubernetes 这样的动态环境中优化您的计算和工作负载变得非常困难。多个团队、多个集群和巨大的复杂性意味着您需要审查和评估大量信息，以做出最佳决策。

获得恰到好处的工作负载

这就是我们创建 Goldilocks 的原因之一，这是 Fairwinds 的一款开源软件工具，可以帮助您合理调整工作负载。我们在 2019 年 10 月开源了 Goldilocks，以提供一个仪表板实用程序来确定设置 Kubernetes 资源请求和限制的基线。金发女孩(显然)帮助你“恰到好处地”获得那些具有挑战性的设置——所以你正在以正确的方式打包。Goldilocks 包括一个 VPA 子图，你可以用它来安装 VPA 控制器和它的资源，这提高了它处理具有数百个名称空间和 VPA 对象的大型集群的能力。

如果你想要更好、更精细的控制，请查看 Fairwinds Insights 。它提供了对 Kubernetes 集群的多集群可见性，这有助于确保应用程序得到适当的配置。

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

Fairwinds Insights 利用 Goldilocks 以及更高级的逻辑(以及高级的 Prometheus 指标，如果有的话)来分析和审查您的工作负载请求和限制。这种额外的可见性有助于您确信您正在致力于对您的业务最有意义的事情，因此在注册或续订您的云承诺时，您不会得到比您需要的更多(或更少)的东西。

云提交后，继续监控和优化

即使您已经为下一年提交了云，并按照您想要的方式设置了一切，一次性优化也不能替代对 Kubernetes 环境的持续监控。确保您拥有所需的工具，使您的开发人员能够定期监控这些工作负载。作为一名管理人员，借助 Fairwinds Insights，您可以洞察您的支出去向，以及是否以最佳方式使用。配置和优化总是很重要，应该是持续的优先事项，以确保环境的可扩展性、可靠性、资源效率和安全性。

需要很好的工具来使您的团队能够了解您的 Kubernetes 环境。合适的工具可以帮助您合理调整工作负载，使您的服务可用，但不会过度调配。完成您需要的任务，而不需要在云服务上花费过多的资金，并确保您的云承诺符合您未来一年的需求和目标。

如何在 Kubernetes 环境中运行日志条目

原文：https://www.fairwinds.com/blog/how-to-run-logentries-in-a-kubernetes-environment

原木很棒。当你在一个或两个盒子上运行时，它们很容易。然而，当您在一个适度的分布式环境中运行时，它们会变得更加困难，如果您已经采用了微服务和容器，情况就更是如此。我收集了一些关于在 Kubernetes 环境中运行 Logentries 的笔记和想法。

在 Fairwinds ，我们为客户使用Kubernetes。集中式日志对于他们了解其环境以及我们帮助进行故障排除至关重要。有时，客户会有他们希望我们使用的现有日志工具或服务。我当前的客户就是这种情况，他使用日志条目。

让它在 Kubernetes 运行起来并不困难，但有些东西是学来的。因为 Kubernetes 完全是关于容器的，所以 Logentries 的日志收集器也应该作为容器运行是有意义的。Logentries 的人显然也有同样的感觉，并在 docker hub 上提供了log entries/docker-log entries图像。说明书讨论了如何在容器中运行，但仅限于直 docker 环境。Kubernetes 是基于 docker 的，但是你的运行方式确实不同。

启动并运行日志条目

我将 Logentries 收集器作为 DaemonSet 运行在它自己的ServiceAccount``kube-system名称空间下。将它作为 DaemonSet 运行的原因是为了确保我们在每个节点上运行这些容器中的一个。一个专用的 ServiceAccount 不是必须的，而是有助于隔离事物。如果您不想添加到 kube-system中，您也可以使用不同的名称空间，但是它非常适合，因为这是用来记录所有内容的。

Logentries 允许您将日志发送到名为日志集的不同位置。为了让日志显示在日志集中，您需要创建日志集，然后创建一个访问令牌。因为这是一个秘密，我们将这样保存它。下面是一个例子 secret.yml 在 Kubernetes 中创建 logentries_token :

---
apiVersion: v1
data:
  logentries_token: <your token | base64 -w0>
kind: Secret
metadata:
  name: logentries
  namespace: kube-system

用敷此kubectl apply -f secret.yml。接下来我们将创建 ServiceAccount。 serviceaccount.yml 看起来是这样的:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: logentries
  namespace: kube-system

用敷此kubectl apply -f serviceaccount.yml。现在我们已经准备好创建真正的工作马了。 daemonset.yml 看起来是这样的:

---
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: logentries
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: logentries
  template:
    metadata:
      name: logentries
      labels:
        app: logentries
    spec:
      serviceAccount: logentries
      containers:
      - name: logentries
        image: logentries/docker-logentries
        imagePullPolicy: Always
        securityContext:
          privileged: true
        args:
          - "-t $LOGENTRIES_TOKEN"
          - "-j"
          # - "--no-stats"
          # - "--no-logs"
          # - "--no-dockerEvents"
          # - "-a <a special string>"
          # - "--stats-interval <STATSINTERVAL>
          # - "--matchByName REGEXP"
          # - "--matchByImage REGEXP"
          # - "--skipByName REGEXP"
          # - "--skipByImage REGEXP"
        volumeMounts:
        - name: socket
          mountPath: /var/run/docker.sock
        env:
        - name: LOGENTRIES_TOKEN
          valueFrom:
            secretKeyRef:
              name: logentries
              key: logentries_token
      volumes:
        - name: socket
          hostPath:
            path: /var/run/docker.sock

其中你用 kubectl apply -f daemonset.yml。

如果你有一个标准的类型设置，类似于你从 kops 那里得到的，上面的应该可以工作。如果您已经完成了定制安装工作，您可能需要调整一些东西，如插座的位置等。

以上是默认配置，它将把容器日志、容器统计数据和 docker 事件发送到 Logentries。如果您希望通过标志来改变日志记录，我已经以注释的方式添加了它们。关于这些标志的详细信息可以在 docker hub 上找到:log entries/docker-log entries/。

观察

总的来说，它像宣传的那样工作。一旦 DaemonSet 运行，日志就会流动。每个容器或 Pod 的内存利用率都在 100MB 以下，到目前为止 CPU 消耗也不多。

容器生成的日志是 JSON 格式的，而 -j 开关确保事情正常通过。到达的 JSON 看起来干净且功能齐全。

我注意到的第一件事是，查找单个 Deployment的日志可能很棘手。例如，根据图像或容器的命名方式，您可能需要使用正则表达式。简单搜索不会找到子字符串。如果我们用一个名字 pod-staging_nginx-worker 搜索 nginx，它不会返回结果，但 name=/.*nginx.*/ 会。

既然我们只获得了感兴趣的 pod 或 container 的日志，那么还有一个问题，那就是所有的统计数据也是搜索结果的一部分。要将结果减少到仅来自容器本身的日志，您可以添加另一个子句: AND line。记录的每一行都将存储在一个名为 line , 的 JSON 属性中，从而强制搜索也只找到那些我们需要的项目: name=/.*nginx.*/ AND line。

另一个仍在寻找答案的问题是您想要为 application X 和 application Y设置日志的用例。使用直接访问日志文件的经典 Logentries 收集器，您可以配置来自给定文件的日志将进入哪个日志集。在 Kubernetes 环境中，日志是通过 docker API 获取的，这是不可能的。不幸的是，一旦从 docker 接收到日志，Logentries 不提供切片和标记的方法。一种可能的选择是在每个 pod 旁边运行一个 Logentries 容器，并利用 --matchByName 或 --matchByImage 和 --no-stats 和 --no-dockerEvents。显然，这将导致大量的日志容器。我将对此进行更深入的研究，但默认可能是目前唯一合理的方法。

总之，Logentries 完全可用，并且很容易用 Kubernetes 设置。

如何使用 Fairwinds Insights 识别 Kubernetes 集群配置错误

原文：https://www.fairwinds.com/blog/how-to-use-fairwinds-insights-to-identify-kubernetes-cluster-misconfiguration

观看 Fairwinds 首席工程师 Andy Suderman 的视频，了解他如何每天使用 Fairwinds Insights 了解 Kubernetes 集群配置错误。

在该视频中，Andy 重点介绍了测试集群中的过时内容，并展示了他如何通过 Fairwinds Insights 的建议更新 Helm charts，包括 Metrics Server、cert-manager 和 vpa。他还研究了安全操作项，重点关注以 root 用户身份运行的容器。

K8s 教程:使用 Polaris 快速识别集群中的 Kubernetes 安全性、可靠性和效率问题

原文：https://www.fairwinds.com/blog/how-to-use-polaris-to-identify-kubernetes-security

Fairwinds 的站点可靠性工程团队拥有为各种公司管理数百个 Kubernetes 集群的独特经验，他们发现客户经常将资源放入他们的集群，这导致他们的公司在云成本上花费额外的资金，使他们的应用程序不太可用，并使他们的集群容易受到恶意行为者的攻击。作为我们帮助客户缓解这些问题的努力的一部分，Fairwinds 软件工程团队开发了一种自动检查这些问题的方法，并作为名为 Polaris 的开源项目发布了该工具。

Polaris 运行数十项检查，以确保您的 Kubernetes pods 和控制器使用集群安全性、效率和可靠性方面的最佳实践进行配置。北极星是一个强大的工具，因为你可以用三种不同的方式使用它。第一个是作为一个仪表板，可视化集群中当前运行的工作负载的问题。第二个是作为准入控制器，因此您可以自动拒绝不符合组织策略的工作负载。第三种是作为命令行工具，因此您可以在您的计算机上测试本地 YAML 文件，或者作为 CI/CD 过程的一部分。

image of Polaris running checks

在本教程中，我们将向您展示如何安装 Polaris，并开始使用每种方法。

安装和查看北极星仪表板

Polaris dashboard 旨在让您可视化集群中已经运行的有问题的工作负载。

在本教程中，我们将向您展示如何使用 Helm 安装 Polaris，Helm 是 Kubernetes 的软件包管理系统。如果你喜欢用另一种方式安装 Polaris，可以从 GitHub 发布页面安装或者用 T2 自制软件安装。

要安装 Polaris with Helm，首先，将 fairwinds-stable 图表库添加到本地可用的 Helm 图表中:

helm repo add fairwinds-stable https://charts.fairwinds.com/stable

接下来，在一个新的演示命名空间中创建一个名为 polaris 的 Helm 版本:

helm upgrade --install polaris fairwinds-stable/polaris --namespace demo --create-namespace

如果安装成功，您可以通过端口转发 polaris-dashboard 服务来启动仪表板:

kubectl port-forward --namespace demo svc/polaris-dashboard 8080:80

最后，在浏览器中打开 https://localhost:8080 查看 Polaris 仪表盘。

您将看到北极星仪表盘，上面有集群健康状况的概述，包括字母等级、通过检查的百分比分数，以及反映集群状态的天气报告，从“前方有风暴，小心”到“一帆风顺”。

Image of Polaris dashboard

要深入查看结果，您可以只查看标记为警告和危险的检查，或者按名称空间查看结果。

我们将在以后的博客文章中向您展示如何对修复进行优先级排序。

将北极星设置为 Kubernetes 准入控制器

Polaris 可以被配置为一个准入控制器，它将扫描您试图部署的工作负载，并拒绝任何不符合 Polaris 标准的效率、可靠性和安全性。

像安装仪表板的说明一样，本教程将向您展示如何使用 Helm 来安装 Polaris 并将其设置为验证 webhook。

Polaris 验证 Webhook 需要有效的 TLS 证书。如果您的群集中安装了 cert-manager，则下面的安装方法将有效。

如果您不使用 cert-manager，您需要:

用 webhook.caBundle 提供一个 CA 包
使用使用该 CA 的有效证书在集群中创建 TLS 机密
使用 webhook.secretName 参数传递该机密的名称。

首先，将顺风-稳定海图存储库添加到本地可用的舵图中:

helm repo add fairwinds-stable https://charts.fairwinds.com/stable

接下来，在一个新的演示命名空间中创建一个名为 polaris 的 Helm release，启用 webhook 并禁用仪表板:

helm upgrade --install polaris fairwinds-stable/polaris --namespace demo --create-namespace --set webhook.enable=true --set dashboard.enable=false

如果安装成功，您将看到类似以下内容的消息:

Release "polaris" does not exist. Installing it now.
NAME: polaris
LAST DEPLOYED: Thu Jul 28 19:56:21 2022
NAMESPACE: demo
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
** Please be patient while the chart is being deployed **

Enjoy Polaris and smooth sailing!
To view the dashboard execute this command:

kubectl port-forward --namespace demo svc/polaris-dashboard 8080:80

Then open http://localhost:8080 in your browser.

启用 Polaris 准入控制器后，当您尝试部署包含危险级别问题的工作负载时，验证 webhook 将阻止应用部署。

例如，如果开发人员试图部署一个名为 basic-demo 的不带 image 标记的 Helm 版本，他们将会看到一条类似于以下内容的错误消息:

helm upgrade --install -n demo basic-demo fairwinds-incubator/basic-demo --create-namespace --set image.pullPolicy=IfNotPresent
Release "basic-demo" does not exist. Installing it now.

Error: admission webhook "polaris.fairwinds.com" denied the request:
Polaris prevented this deployment due to configuration problems:
- Container basic-demo: Image tag should be specified

当开发人员添加图像标签并再次尝试部署基本演示版时，Polaris 验证 Webhook 不会干扰，他们将会看到来自 Helm 的成功消息:

Release "basic-demo" has been upgraded. Happy Helming!
NAME: app
LAST DEPLOYED: Fri Jul 29 16:07:35 2022
NAMESPACE: demo
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
1\. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace staging-app -l "app.kubernetes.io/name=basic-demo,app.kubernetes.io/instance=app" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:80

在未来的博客文章中，我们将描述如何设置变异的 webhooks，以便在发现问题时自动改变部署。

使用 Polaris CLI 工具审计您的基础设施代码

使用 Polaris 的最后一种方法是使用命令行工具审计存储在 YAML 文件中的本地 Kubernetes 清单。这对于将 Polaris 作为 CI/CD 管道的一部分在您的基础设施代码上运行特别有帮助。

你可以使用自制软件或者从 Github 发布页面安装 Polaris。

首先，访问版本页面，找到适合您环境的版本。例如，在采用 amd64 处理器的 Linux 机器上，您将需要下载适用于 Linux amd64 的版本。

运行以下命令下载并安装 Polaris:

curl -L "https://github.com/FairwindsOps/polaris/releases/download/7.0.1/polaris_linux_amd64.tar.gz" > polaris.tar.gz
tar -xvf polaris.tar.gz
sudo mv polaris /usr/local/bin/

可以使用 Polaris 来审核您计算机上的 Kubernetes yaml 清单。例如，如果要扫描名为 deploy 的目录中的清单，请运行以下命令:

polaris audit --audit-path ./deploy/ --format=pretty

北极星将显示一个分数，并向您显示成功、警告和危险级别问题，如下所示:

Polaris audited Path ./deploy/ at 2022-07-29T16:40:08-05:00
    Nodes: 0 | Namespaces: 0 | Controllers: 1
    Final score: 55

Deployment kube-info-deployment in namespace demo
    deploymentMissingReplicas            🎉 Success
        Reliability - Multiple replicas are scheduled
    hostIPCSet                           🎉 Success
        Security - Host IPC is not configured
    hostNetworkSet                       🎉 Success
        Security - Host network is not configured
    hostPIDSet                           🎉 Success
        Security - Host PID is not configured
  Container kube-info
    runAsPrivileged                      🎉 Success
        Security - Not running as privileged
    cpuLimitsMissing                     😬 Warning
        Efficiency - CPU limits should be set
    livenessProbeMissing                 😬 Warning
        Reliability - Liveness probe should be configured
    memoryLimitsMissing                  😬 Warning
        Efficiency - Memory limits should be set
    memoryRequestsMissing                😬 Warning
        Efficiency - Memory requests should be set
    privilegeEscalationAllowed           ❌ Danger
        Security - Privilege escalation should not be allowed
    readinessProbeMissing                😬 Warning
        Reliability - Readiness probe should be configured
    tagNotSpecified                      🎉 Success
        Reliability - Image tag is specified
    insecureCapabilities                 😬 Warning
        Security - Container should not have insecure capabilities
    runAsRootAllowed                     ❌ Danger
        Security - Should not be allowed to run as root
    cpuRequestsMissing                   😬 Warning
        Efficiency - CPU requests should be set
    dangerousCapabilities                🎉 Success
        Security - Container does not have any dangerous capabilities
    hostPortSet                          🎉 Success
        Security - Host port is not configured
    notReadOnlyRootFilesystem            😬 Warning
        Security - Filesystem should be read only
    pullPolicyNotAlways                  😬 Warning
        Reliability - Image pull policy should be "Always"

Polaris 还可以审计现有集群中的工作负载。确保您已经设置了 KUBECONFIG 文件，然后运行命令

polaris audit --format=pretty

在以后的文章中，我们将向您展示如何在 CI/CD 管道中使用 Polaris。

使用 Polaris 一次审计多个集群

如果你有多个集群，并想用北极星一次性扫描它们，Fairwinds 提供了一个名为 Insights 的平台。用户可以跨集群一致地集中管理 Polaris，以确保您的 Kubernetes 工作负载尽可能高效、可靠和安全。

资源

如何将 Terraform 与 GKE 一起使用:部署第一个集群的分步指南

原文：https://www.fairwinds.com/blog/how-to-use-terraform-with-gke-a-step-by-step-guide-to-deploying-your-first-cluster

为了确保 Kubernetes 在构建基础设施方面的最佳实践，Fairwinds 使用了提供一致性和定制性的通用模式。Terraform 是我们管理基础设施整个生命周期的首选工具，以基础设施作为代码。你可以在之前的博客中了解原因。

本博客提供了如何开始使用 Terraform 在 GKE 建立第一个 Kubernetes 集群的分步指南。

先决条件

如果您想在 Terraform 中创建自己的 GKE 集群，请遵循以下步骤。

在您的 Google Cloud 帐户云控制台中创建一个项目
- 一般会有一个默认创建的项目，你可以使用，或者点击 Google 云平台 logo 旁边的My First Project 下拉菜单，创建一个新项目。

GCP My First Project screenshot

一旦创建了项目，并在下拉列表中选中了它，在左侧找到 Kubernetes Engine → Configuration 并启用 Kubernetes 引擎 API，如下所示。

GCP Kubernetes Engine API Enable Screenshot

步骤

在您的终端中，为您的 Terraform 文件创建一个项目目录，就像terraform-gke.您创建的第一个文件将是 Google Terraform Provider 的文件，它让 Terraform 知道它可以创建什么类型的资源。

您将需要一个文件，其中包含 Terraform 与 Google Cloud API 交互以创建集群和相关网络组件所需的凭据。前往谷歌云控制台导航侧边栏的 IAM &管理部分，选择 Service Accounts. ，创建一个服务帐户:

GCP Screenshot IAM and ADMIN Service Accounts

创建服务帐户后，系统会提示您为其选择一个角色。在本练习中，您可以从Roled下拉菜单中选择 Project: Owner

GCP Service Accounts Role ScreenShot

在下一页，点击 CREATE KEY ，选择一个 JSON 键类型:

GCP Create service account key screnshot

一旦创建，文件将被下载到您的电脑上。将文件移动到 Terraform 项目目录。

接下来，创建一个名为provider.tf,的文件，并添加以下代码行:

 provider "google" {
  credentials = file("./.json")
  project     = ""
  region      = "us-central1"
  version     = "~> 2.5.0"
}

在项目名称中填入您在 GCP 控制台中创建的项目的 ID，在凭证文件名中填入您刚刚下载并移动到项目文件夹中的服务帐户密钥文件的名称。完成后，创建一个名为cluster.tf.的新文件，添加以下代码来设置网络:

 module "network" {
  source = "git@github.com:FairwindsOps/terraform-gcp-vpc-native.git//default?ref=default-v2.1.0"
  // base network parameters
  network_name     = "kube"
  subnetwork_name  = "kube-subnet"
  region           = "us-central1"
  enable_flow_logs = "false"
  // subnetwork primary and secondary CIDRS for IP aliasing
  subnetwork_range    = "10.40.0.0/16"
  subnetwork_pods     = "10.41.0.0/16"
  subnetwork_services = "10.42.0.0/16"
}

您将在source字段中注意到，网络模块是从我们的 git repo 中提取的:https://github . com/FairwindsOps/terra form-GCP-VPC-native/tree/master/default 如果您研究该 repo，尤其是main.tf文件，您将看到该模块负责创建的所有不同的资源和变量，如网络和子网，因此您不必单独创建它们。您可能会注意到，该模块也可以用于创建带有私有节点的云 NAT，但是我们在这里将保持简单。接下来，将这个模块代码添加到集群本身的cluster.tf文件中:

 module "cluster" {
  source                           = "git@github.com:FairwindsOps/terraform-gke.git//vpc-native?ref=vpc-native-v1.2.0"
  region                           = "us-central1"
  name                             = "gke-example"
  project                          = "terraform-module-cluster"
  network_name                     = "kube"
  nodes_subnetwork_name            = module.network.subnetwork
  kubernetes_version               = "1.16.10-gke.8"
  pods_secondary_ip_range_name     = module.network.gke_pods_1
  services_secondary_ip_range_name = module.network.gke_services_1
}

您会注意到某些值，如module.network.network_name,是从网络模块引用的。Terraform 的这一特性使您能够在模块或资源上设置值，并在其他模块或资源上使用它们。最后，将这段代码添加到cluster.tf中，以设置包含 Kubernetes 工作节点的节点池:

 module "node_pool" {
  source             = "git@github.com:/FairwindsOps/terraform-gke//node_pool?ref=node-pool-v3.0.0"
  name               = "gke-example-node-pool"
  region             = module.cluster.region
  gke_cluster_name   = module.cluster.name
  machine_type       = "n1-standard-4"
  min_node_count     = "1"
  max_node_count     = "2"
  kubernetes_version = module.cluster.kubernetes_version
}

就是这样！你的地形文件已经准备好了。下一步是通过运行terraform init.初始化 terra form。terra form 将生成一个名为.terraform的目录，并下载在cluster.tf.中声明的每个模块源。初始化将获取这些模块所需的任何提供程序，在本例中，它将下载google提供程序。如果进行了配置，Terraform 还将配置用于存储状态文件的backend。

 $ terraform init
Initializing modules...
Downloading git@github.com:FairwindsOps/terraform-gke.git?ref=vpc-native-v1.2.0 for cluster...
- cluster in .terraform/modules/cluster/vpc-native
Downloading git@github.com:FairwindsOps/terraform-gcp-vpc-native.git?ref=default-v2.1.0 for network...
- network in .terraform/modules/network/default
Downloading git@github.com:/FairwindsOps/terraform-gke?ref=node-pool-v3.0.0 for node_pool...
- node_pool in .terraform/modules/node_pool/node_pool

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "google" (hashicorp/google) 2.20.3...
- Downloading plugin for provider "random" (hashicorp/random) 2.2.1...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.random: version = "~> 2.2"

Terraform has been successfully initialized!

After Terraform has been successfully initialized, you should be able to run terraform plan. It is always a good idea to run terraform plan and review the output before allowing Terraform to make any changes. 

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # module.cluster.google_container_cluster.cluster will be created
  + resource "google_container_cluster" "cluster" {
      + additional_zones            = (known after apply)
      ....
    }

  # module.network.google_compute_network.network will be created
  + resource "google_compute_network" "network" {
      + auto_create_subnetworks         = false
      ....
    }

  # module.network.google_compute_subnetwork.subnetwork will be created
  + resource "google_compute_subnetwork" "subnetwork" {
      + creation_timestamp       = (known after apply)
      ....
    }

  # module.node_pool.google_container_node_pool.node_pool will be created
  + resource "google_container_node_pool" "node_pool" {
      + cluster             = "gke-example"
      ....
    }

  # module.node_pool.random_id.entropy will be created
  + resource "random_id" "entropy" {
      + b64         = (known after apply)
      ....
    }

Plan: 5 to add, 0 to change, 0 to destroy.

请注意，这个片段已经被稍微编辑过，以减少这篇文章的篇幅。如上例所示，Terraform 将采取措施添加我们的 5 个 GKE 资源。应用后，Terraform 将创建我们的网络、子网(用于 pod 和服务)、GKE 集群和节点池。random_id资源来自节点池模块；它用于跟踪节点池资源的更改。计划通过验证后，通过运行最后一个验证步骤terraform apply.应用更改，Terraform 将再次输出计划，并在应用前提示确认。完成此步骤大约需要 10-15 分钟。

 Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

module.node_pool.random_id.entropy: Creating...
module.node_pool.random_id.entropy: Creation complete after 0s [id=dcY]
module.network.google_compute_network.network: Creating...
module.network.google_compute_network.network: Still creating... [10s elapsed]
module.network.google_compute_network.network: Creation complete after 17s [id=kube]
module.network.google_compute_subnetwork.subnetwork: Creating...
module.network.google_compute_subnetwork.subnetwork: Still creating... [10s elapsed]
...
module.network.google_compute_subnetwork.subnetwork: Creation complete after 37s [id=us-central1/kube-subnet]
module.cluster.google_container_cluster.cluster: Creating...
module.cluster.google_container_cluster.cluster: Still creating... [10s elapsed]
...
module.cluster.google_container_cluster.cluster: Still creating... [7m50s elapsed]
module.cluster.google_container_cluster.cluster: Creation complete after 7m56s [id=gke-example]
module.node_pool.google_container_node_pool.node_pool: Creating...
module.node_pool.google_container_node_pool.node_pool: Still creating... [10s elapsed]
module.node_pool.google_container_node_pool.node_pool: Still creating... [20s elapsed]
...
module.node_pool.google_container_node_pool.node_pool: Still creating... [2m0s elapsed]
module.node_pool.google_container_node_pool.node_pool: Creation complete after 2m7s [id=us-central1/gke-example/gke-example-node-pool-75c6]

Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

请注意，这个片段已经被稍微编辑过，以减少这篇文章的篇幅。现在您的集群已经配置好了，使用 gcloud 来检索kubectl.的集群配置。该命令会将新的集群配置合并到您的KUBECONFIG中，默认为~/.kube/config.

 $ gcloud container clusters get-credentials gke-example --region us-central1
Fetching cluster endpoint and auth data.
kubeconfig entry generated for gke-example.

检索到凭据后，通过运行kubectl get nodes.确认您可以连接

 $ kubectl get nodes
NAME                                                  STATUS   ROLES    AGE   VERSION
gke-gke-example-gke-example-node-pool-953475c5-lrm8   Ready       17m   v1.16.10-gke.8
gke-gke-example-gke-example-node-pool-d9071150-m8mh   Ready       17m   v1.16.10-gke.8
gke-gke-example-gke-example-node-pool-df7578a5-htw9   Ready       17m   v1.16.10-gke.8

恭喜您，您已经使用 Terraform 成功部署了 Kubernetes GKE 集群！您现在可以开始将您的应用程序部署到 Kubernetes 了！

资源

尽管我们很小，但我们如何实现大目标...借助开发运维即服务

原文：https://www.fairwinds.com/blog/how-we-deliver-big-even-though-were-small-with-devops-as-a-service

我经常听到潜在客户说这样的话:“只有 15 个人，你如何为我们的组织提供一个良好、快速、可靠的开发运维即服务解决方案？”

答案有三点:

我们雇佣了经验丰富的高级工程师。

我们带来了大量的自动化。

我们拥有为许多公司大规模运营 Kubernetes 的丰富经验。

我想把这个答案分成三个部分，让大家更好地了解我们的小团队是如何持续不断地交付大成果的。

我们雇佣有丰富经验的高级工程师

作为一个小组织，我们很早就决定只雇佣我们能找到的最优秀的人。我知道很多组织说他们也这么做，但是我们的结果证明了这一点。作为一家小型 DevOps 商店，我们将雇用和留住世界一流的专家工程师作为我们的首要任务，也是我们的主要竞争优势。工程师很难通过我们的招聘渠道。因此，当我们雇佣某人时，他们是出色的工程师。

在聘用具有强大运营背景的工程师时，我们会让工程师在两个重要领域拥有丰富的深度和广度。首先，当我们的一名工程师从头开始重新设计基础架构时，他们了解他们所做决策的含义。而且不仅仅是短期的。他们能够认识到什么时候决策“foo”或“bar”可能在短期内感觉无关紧要，但如果没有以战略和具体的方式进行导航，从长期来看可能会是一个巨大的痛点。

我们不希望您因为规划不足而不得不重新设计基础设施。相反，我们希望今天就构建它。我们雇佣的经验丰富的工程师使这成为可能。

其次，丰富的经验带来了独特的深度故障排除技能。所有的基础设施工程师在钻研一个问题时都会在某个时候碰壁，并且不得不问许多问题来找出问题的根源。工程师越资深，他们的故障排除技能就越深入。他们看到了许多不同类型的问题，因此有许多不同的问题要问来诊断问题。他们会问，“如果不是这件事，那可能是我几年前看到的另一件事。”这个深度使它更难进入死胡同。

我们的员工目睹了基础设施以各种方式出现故障，他们的集体经验帮助我们构建了出色的基础设施，并快速识别和解决了复杂的日常维护问题。

我们带来了大量的自动化工作

当我们创办 Fairwinds 时，我们最初只是做直接咨询。我们的客户告诉我们他们想要做什么，我们尽可能快速有效地帮助他们实现这些目标。然而，我们很快意识到每个人的基本需求大致相同。每个人都想要零停机部署、完全自动化的部署管道、自动扩展、监控、警报、日志记录等等。(这个清单很长，但对大多数人来说，总的清单是相似的。)

一些公司已经通过构建平台即服务来应对这一挑战，但我们不想再构建另一个平台即服务(YAP？).假设你决定雇佣你能找到的最好的站点可靠性工程师。该工程师可能会查看您现有的设置以及可用的最佳工具，然后从头开始构建您的基础架构。我们做同样的事情。我们将用一流的开源软件和 SaaS 工具(从 Kubernetes 到 CircleCI)为您构建一些东西。不同的是，我们已经做了很多次，我们已经自动化了这个过程。借助这种自动化，我们可以提供速度和可靠性。

我们永远不必从零开始。更好的是，我们不断调整和改进流程。这种自动化包括我们使用内部开源工具【五边形】建立 Kubernetes 集群的方式，以及我们如何使用rok8s-scripts与 Kubernetes 集群和 CI 管道进行交互。

我们拥有为许多公司大规模运营 Kubernetes 的丰富经验

建立一个集群并让应用程序在其中运行是一回事。长期支持这些集群完全是另一回事。很少有公司提供我们在 Fairwinds 提供的 Kubernetes 托管服务。这对我们的客户意味着什么？这意味着我们知道什么样的扩展和网络问题会破坏集群。这意味着我们知道如何应对复杂的安全问题。这意味着我们可以强化集群，使其为生产做好准备。

因为我们对 Kubernetes 了如指掌，所以我们知道什么样的事情会出错，以及如何在这些问题出现之前解决它们。在为每个客户维护 Kubernetes 的过程中，我们学到了宝贵的经验，使我们的每个客户受益。换句话说，我们定期将这些经验整合到我们的工具中，以建立新的集群。我们坚实的、有知识支持的流程在不断发展和改进。

例如，假设你有一个 20 人的内部团队。这 20 个人也许能够在 Kubernetes 上勤奋工作，并建立与我们相同水平的专业知识和可重复的、可靠的流程。然而，通过为许多不同类型的客户做这项工作，Fairwinds 在构建基于 Kubernetes 的基础设施并在生产中大规模运行它方面积累了无与伦比的专业知识。

我们可能很小，但我们提供大的

您可以构建、管理自己的平台并排除故障。然而，事实是我们可以更快地构建它，根据您的特定需求定制它，并且比其他任何人都更好地维护它。你的平台不会有大多数内部系统都有的错误。

起初，一些客户不确定我们的小团队如何能完成这么多工作。然而，在我们与客户合作之后，他们就明白了。一旦他们的平台启动并运行，通常的反应是什么？“哇，Fairwinds 只有 15 个人，而您这么快就向我们提供了如此出色的 DevOps 解决方案！”

对于许多公司来说，这就是拥有高级工程师、重要的自动化和大规模运行 Kubernetes 的经验的价值——您可以获得精简、智能、成熟的开发运维即服务解决方案。我们可能很小，但我们提供的很大。

我们如何学会不再担心并爱上集群升级

原文：https://www.fairwinds.com/blog/how-we-learned-to-stop-worrying-and-love-cluster-upgrades

当前进程

有经验的 Kubernetes 集群操作员知道升级可能很棘手。像kops这样的工具试图让这个过程变得更好，但是这还不是一个已经解决的问题。集群升级可能会很可怕，甚至很危险。在 Fairwinds ，我们进行了大量的集群升级，客户依靠我们来确保它们的正确性。当我们说我们做了很多时，我们指的是每个客户至少 2 个集群(通常超过 2 个)，并且我们每年大约更新 4 次。这意味着我们需要大量的滚动更新，这给了我们大量的机会来思考和制定策略。我们想出了一些让这个过程变得更好的技巧，我们把它们整理在这里与你分享。

首先，让我们用 kops 回顾一下当前状态，因为我们的大多数集群都是由 it 管理的。滚动更新策略记录在这里，工作方式如下:

对于每个节点:

1.耗尽节点

2.终止 EC2 实例

3.等待 ASG(自动扩展组)中的替换节点加入群集

4.等待群集得到验证

这种更新策略有几个问题。随着集群变得越来越大，这些问题变得更加棘手:

Screen-Shot-2018-08-24-at-10.45.12-AM

第一个问题涉及到节点排水和周围的吊舱洗牌。当 Kubernetes 在准备删除一个节点时，它必须重新调度正在运行的工作负载。如果你仔细观察上面的例子，你会注意到 pod 经常被移动多次！对于第一个节点，每个重新安排的 Pod 至少需要再移动1 次。随着时间的推移，pod 被多次重新调度的机会越来越大，但这不是一个可行的长期调度策略。这有点傻，因为我们知道哪些节点会提前离开。

其次，等待一个节点被删除，一个新节点启动然后加入群集可能需要 10 分钟。当集群包含 20 个或更多节点时，此过程可能需要几个小时。

如果你的应用程序是有弹性的，并在被要求关闭时礼貌地关闭，这种混乱通常是令人讨厌的。如果你的应用程序不能很好地运行，这可能会产生实际的问题。它放大了升级所需的时间。

更好的方法

在云中，短时间运行额外的实例相对便宜。在 Fairwinds 时，我们打算花费更多我们丰富的计算资源来保留我们最稀缺的资源:时间。

我们从书本开始升级过程:我们对主文档使用滚动更新过程。这将一个接一个地消耗和替换实例。然后，我们把我们的扭曲。

对于每个“节点”实例组:

1.节点数量翻倍

2.封锁旧节点

3.排空旧节点

4.终止那些节点

这比滚动更新快得多。它使节点的启动并行化，因此这一切都是同时发生的。这有一个很好的副作用:它给了你大量的空间来安排你将要消耗的所有能量。然后，所有完成接收流量的节点立即被封锁。这意味着你只需要为你的豆荚找一个家。那很酷。

细节决定成败

最后一部分是关于理论和挥手的大篇幅。你实际上是怎么做的？

一旦母版被更新，这个过程就非常简单了，但是我们已经列出了下面的步骤，这样你就可以避免一些不太明显的问题出现。

1.禁用集群自动缩放器(如果已安装)。这不是可选的。当您的流量预计相对稳定且理想情况下最小时，请进行升级。那是你升级的时候，对吗？:)如果不禁用它，cluster-autoscaler 真的想删除所有新节点，因为它们都是空的。我们发现将集群自动缩放器扩展到 0 个副本就足够了。

2.集群规模翻倍。这有几种方法，但最简单的是编辑自动缩放组(或kops实例组)。新节点将使用新的启动配置进行初始化，新版本的 Kubernetes 运行kubectl get nodes来查看新版本上的所有节点。

3.如果您正在使用 ELBs，在这里花点时间验证您的新节点是 ELB 中的 Healthy 。
这一点很重要，因为标记为SchedulingDisabled的节点被视为不可用，并将从其连接的 ELB 中移除。如果我们在将新节点添加到 ELB 之前封锁所有旧节点，这将导致中断。

4.如果您在您的任何 LoadBalancer -type Services 上使用 externalTrafficPolicy: Local ，在您继续之前临时设置 externalTrafficPolicy: Cluster 是很重要的。
如果我们在一个新节点上的服务单元可用之前封锁所有旧节点，我们保证在 ELB 有 0 个Healthy节点，并且有一个中断。如果暂时设置externalTrafficPolicy: Cluster对您来说不是一个选项，请确保在继续之前让一个 Pod 在一个新节点上运行。

5.封锁所有旧节点。
如果您正在升级版本，使用类似kubectl get nodes | grep <old version> | awk '{print $1}' | xargs kubectl cordon的命令快速定位旧节点。这就是我们如何防止豆荚被重新安排超过一次。

6.引流旧节点。我们发现类似下面这样的东西很有用:kubectl get nodes | grep SchedulingDisabled | awk '{print $1}' | xargs kubectl drain --ignore-daemonsets --delete-local-data --force

7.重新打开集群自动缩放功能！
旧节点空了，我们不再需要它们了。Cluster-autoscaler 可以快速解决这些问题。

PSA:鉴于你的新版本 Kubernetes，这可能是一个很好的时间来验证你安装的所有那些随机的第三方位是否还在工作，你是否还在运行一个合适的版本。

kops 意识到了这一点

kops repo 上有一个公开的 PR 介绍了这个策略以及其他策略，希望在接下来的几个版本中可以使用。在此之前，我们发现所有这些都是有用的，我们希望你也一样！

我们如何管理 Kubernetes RBAC 和我在 GKE 的角色

原文：https://www.fairwinds.com/blog/how-we-manage-kubernetes-rbac-and-iam-roles-on-gke

Google 的托管 Kubernetes 服务一直是我最喜欢的运行 Kubernetes 集群的方式之一。谷歌 Kubernetes 引擎(GKE)提供了一些令人难以置信的功能，使 Kubernetes 更愉快地工作。也就是说，GKE 最好的功能之一是经常被误解的，Google Cloud IAM 和 Kubernetes RBAC 之间的关系。如果配置正确，它们可以为 Kubernetes 授权提供一种简单而强大的方法。

RBAC 建立在 GKE 的基础上

对于 Google Cloud 中的大多数服务，设置授权只需要配置 IAM 角色。虽然这也是 GKE 的一个选项，但是您可能需要添加一些 RBAC 配置，作为有效的 Kubernetes 授权策略的一部分。

本质上，所有 IAM 配置都适用于整个 Google Cloud 项目，以及该项目中的所有集群。Kubernetes RBAC 配置分别应用于每个集群，并支持名称空间级别的细粒度授权。在 GKE 中，这些授权方法并行工作，用户的能力有效地代表了分配给他们的 IAM 和 RBAC 角色的联合。

常见的 IAM 和 RBAC 角色

Google Cloud IAM 和 Kubernetes RBAC 都提供了默认角色，作为任何授权策略的良好起点。

GCP IAM and Kubernetes RBAC have similarly named roles (cluster admin, admin, developer/edit, and viewer)

根据上图，您可能会认为左边的 Google Cloud IAM 角色与右边相应的 Kubernetes RBAC 角色相匹配。虽然这基本上是对的，但是在集群管理员角色方面有很大的不同。

在 Kubernetes RBAC 中，集群管理员角色授予创建、编辑或删除集群中任何资源的完全管理权限。使用 Google Cloud IAM，Kubernetes 引擎集群管理员角色实际上只授予更改集群基础设施的能力，而不是实际访问集群中的任何资源。当然，这两个角色名称在单独使用时是有意义的，但是考虑到 IAM 和 RBAC 的效果之间的重叠，这种命名可能会令人困惑。以下是 IAM 角色与 RBAC 角色实际关联的大概情况:

The GKE Admin role actually matches up more closely with the cluster-admin RBAC role while the GKE developer and viewer roles line up closely with RBAC edit and view roles.

这些 IAM 角色与 RBAC 角色并不完全匹配，但是这些箭头所连接的角色中的功能通常非常接近。还值得注意的是，项目范围的所有者、编辑者和查看者 IAM 角色分别包括 GKE 管理员、开发人员和查看者功能(有几个有趣的例外)。

一起使用 IAM 和 RBAC

有了最小特权原则作为我们的指路明灯，我们可以使用简单的方法与 IAM 和 RBAC 一起实现全面授权。由于 IAM 角色授予对 GCP 项目中所有集群的访问权限，因此应该谨慎使用。例如，授予“Kubernetes Engine Developer”角色将授予对所有名称空间的编辑访问权，包括kube-system允许具有此 IAM 角色的任何人修改核心系统组件。当然，我们仍然需要使用 IAM 授予某种形式的基本访问权限，以使用户能够获得访问集群的凭证。在 GKE 上，如果没有至少一些 IAM 来授予初始集群访问权限，RBAC 是无能为力的。

考虑到这一点，我们通常建议使用“Kubernetes 引擎查看器”IAM 角色来授予只读访问权限。然后，可以使用粒度 RBAC 配置来扩展这种访问，该配置授予对特定名称空间的写和/或管理访问权限。对于 GKE，IAM 是授权的基础，而 RBAC 是建立在基础之上的结构。

实际上，这意味着在名称空间级别向特定用户授予集群中的edit或admin角色，以构建您使用 IAM 授予他们的只读访问权限。一个简单的角色绑定在web名称空间中授予 Jane edit 访问权限，如下所示:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: jane-web
  namespace: web
subjects:
- kind: User
  name: jane@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

像这样定义 RBAC 配置在小范围内工作得相对较好，但是很快会变得难以跨各种名称空间或用户进行管理。当一半的配置位于 Google Cloud IAM，而另一半位于 RBAC 的 Kubernetes 时，也很难获得集群中授权的全貌。在不断遇到这些问题后，我们创建了一些开源工具来帮助解决。

简化 RBAC 管理

在 Fairwinds，我们为各种各样的组织管理集群，这意味着我们亲眼目睹了 RBAC 配置在规模上可以变得多么复杂。更糟糕的是，很难以任何有意义的方式自动化对 RBAC 配置的更改。像许多组织一样，我们尽可能使用 CI/CD 和基础设施作为代码，这对 RBAC 来说确实很难。角色绑定不能更改，而是需要在为用户分配不同角色时删除并重新创建。此外，在任何 CI/CD 工作流中，注意到缺少资源并基于此进行更改变得非常复杂。对于 RBAC，这是一个非常重要的细节。撤销访问需要移除角色绑定，这可能很难跟踪。

我们在构建 rbac 管理器时考虑到了所有这些因素。rbac-manager 是一个定制运营商，可以轻松部署到您的集群中，显著简化您的 rbac 工作流。使用 rbac-manager 的自定义资源(rbac 定义)，我们经常看到 yaml 的数量减少到原始配置的 1/3。重要的是，使用 rbac-manager 更改和撤销角色的工作方式与您预期的一样。如果绑定到用户的角色在 RBAC 定义中发生更改，rbac-manager 会负责删除和重新创建与新角色绑定的关联角色。此外，如果从 RBAC 定义中删除了与用户绑定的角色，则关联的角色绑定也会自动删除。

所有这些改进都相对较小，但是当组合成一个单一的工具时，它们可以使 RBAC 更容易使用。

简化 RBAC(和 IAM)的可见性

借助 GKE 提供的 RBAC 和 IAM 的独特组合，很难全面了解谁有权访问集群。我们创建了 rbac-lookup 来帮助解决这个问题。使用类似于rbac-lookup rob的简单命令，它将输出所有匹配该名称的用户、服务帐户或组，并显示他们在集群中被赋予的 RBAC 角色。

在我们最新的版本中，我们引入了 GKE IAM 集成，这也将在输出中包括与这些用户相关联的容器 IAM 角色。因此，如果您运行rbac-lookup rob --gke，它将包括所有相关的 RBAC 角色，以及与匹配用户的 GKE 访问相关联的所有相关 IAM 角色。

在 Fairwinds，我们相信在您的 Kubernetes 集群上配置和理解授权应该很容易。我们希望 rbac-manager 和 rbac-lookup 都有助于让每个人更容易接近 rbac。

冲下基础设施最佳实践的大山

原文：https://www.fairwinds.com/blog/hurtling-down-the-mountain-of-infrastructure-best-practices

我问肯德尔他对“现代最佳基础设施实践”的快速范式转变有何看法，他的回答很有启发:“我在滑雪坡上。”

怀疑者可能会声称肯德尔在科罗拉多滑雪了一天，但我敢断言，你对肯德尔并不熟悉——他的第一语言是辉煌的隐喻。我越想这句至理名言，就越觉得它有道理。

在 2006 年，最佳实践是考虑将您无尽的裸机机架转换成某种形式的虚拟化。下一步是将应用程序从底层硬件中分离出来——问问任何技术专家。

2012 年，最佳实践是将这些机架转换成某个公共云提供商环境中的实例。将资本支出转化为运营支出是正确的举措——问问任何分析师就知道了。

2015 年，最好的做法是迁移到 DockerDockerDockerDockerDockerDockerDocker——抱歉，我的转录软件卡住了。迁移到容器是最有意义的事情——问问任何一个传道者。

今天，最佳实践是迁移到某种形式的容器编排。能够以编程方式将您的工作负载“调度”到与应用程序无关的基础架构中是前进的方向——问问任何风险投资家吧。

很快，最佳实践将是迁移到“无服务器”技术，但我会在以后的文章中再回到这一点。

今天，问题出现了...如果你错过了一个或多个班次会怎么样？“将您的遗留 Rails 应用程序重写为无状态的东西”听起来像是一个很好的最佳实践，但是孤立来看，这可能是一个为期一年的项目，不会增加任何商业价值。企业的成败取决于市场力量；“他们使用了错误的基础设施技术”很少是市场力量之一。

所以，如果你忽略了宣传列车，如果你不转向容器、功能即服务、微服务架构，让你的公司在飞行杂志上被吹捧，那会怎么样？会有什么后果？

技术必须为企业提供动力，否则就无法生存。“因为它很酷”在第一次互联网泡沫破裂时不再是一个商业案例。但是，我们对基础设施的整体看法的这些结构性转变不仅对我们自己的运营产生了巨大的破坏性，而且还在加速。我们失去了控制——几乎就像我们冲下一座山，却不知道如何停下来。我们无法理解这些变化背后的“为什么”，我们只知道如果我们不去做，我们就失败了。如果你看到这个领域的最新技术，感到完全不知所措，你绝对不是一个人。跟上你“应该”做的事情已经成为一项全职工作。

Fairwinds 的哲学是你不应该担心这些事情。担心你的生意。如果你今天所做的事情能够完成任务——如果你能够有效地招聘，能够稳定地运行你的环境，能够以让客户满意的方式回应他们，那么你就不应该改变任何事情。找到适合你的技术，而不是适合世界其他地方的技术。 Fairwinds 一直致力于推动业务发展，而不是为了技术本身而技术。

但是如果肯德尔不马上上线，我就要派出搜索队了。

IaaM -作为摩托车的基础设施

原文：https://www.fairwinds.com/blog/iaam-infrastructure-as-a-motorcycle

不，IaaM 不是我们的新产品，它只是这篇博文的一个扩展隐喻。如果有人知道如何提供真正的 IaaM…请找我，听起来很棒。总之…

我买了辆摩托车。

我一直在寻找的酒吧就是它能跑，而且确实能跑。尽管在我试图把它从城市的另一头开回家的时候，它死了大约四次。我对摩托车基本上一无所知——我最接近的一辆摩托车是五年前我骑了一年的 150 毫升的小型摩托车。因此，我像所有在科技公司工作的人一样，去找我们的首席技术官寻求摩托车方面的建议，因为他已经骑了很多年了，知道如何让摩托车尽可能安全。他也知道什么样的摩托车天生是好的或糟糕的。

他给了我一些装备建议，我买了一顶头盔、一件夹克和手套。他提出了更多的建议，但我没有采纳他的所有建议，因为我想要用钱可以买到的最便宜的摩托车，而 200 多美元的装备对于一辆 500 美元的摩托车来说只是感觉…错了(即使他是对的)。

摩托车最终还是回到了家。它确实能跑。我已经骑着它在附近跑了几次，还跑了几趟腿，这样我就能更舒服地骑着它了。每辆老式摩托车都会有一些怪癖，这辆也不例外。我花了一点时间来调整油门，弄清楚离合器，并知道如何操纵一台比我以前骑过的大得多的机器。

我发现它没有空气过滤器，甚至没有风箱，我可能永远都会找到需要调整的地方。闪光灯并没有真正像他们应该做的那样工作，而且座位可能会被撞得比预期的稍微重一点。这是一堆垃圾。但它确实会跑。

但事实是，这是我的一个玩具。这对我的生活方式没有任何影响，因为我们有一辆大型家用汽车。我可以骑着我的摩托车去某个地方，如果它在路边熄火了，我不得不乘 Lyft 准时到达我的目的地，一切都会好的。它是一个玩具。

使用 Kubernetes 和 Google 云游戏服务器改善多人游戏体验

原文：https://www.fairwinds.com/blog/improve-multiplayer-gaming-experience-kubernetes-google-cloud-gaming-server

移动游戏市场将在 2020 年爆发。COIVID-19 正在行业中崭露头角。根据 gamesindustry.biz 的数据，仅在今年前三个月，我们就见证了有史以来手机游戏下载量最大的季度，App Store 和 Google Play 的安装量超过了 130 亿次。他们将这一点放在上下文中很有帮助:“这比 2019 年第三季度多了 20 亿次下载。”

在接下来的几年里，预计手机游戏“在下载量方面将比应用程序有更高的增长，随着消费者比以往更多地转向手机，安装量的增长可能会持续下去。”

随着手机游戏的发展，问题是技术是否能跟上并改进？要取得成功，您的手机游戏必须:

全天候高度可用-您的用户需要稳定性和可靠性
同时支持连接全球数千甚至数万玩家的多人游戏体验
支持多达数千个玩家同时配对

您必须拥有支持高可用性、数千个并发连接和实时玩家交互的基础设施。同时，您面临着不可预测的需求，需要能够高效扩展的游戏基础架构。支持位于世界任何地方的多人游戏也特别具有挑战性。现在，游戏开发者稀缺的工程人才更是火上浇油。当你有了一个伟大的团队，你真的希望他们保持基础设施或专注于你的游戏吗？

游戏工作室通过创建大量严重依赖云和连接的专有基础设施解决方案取得了成功。但是延迟和响应速度继续影响着许多游戏的交互性，尤其是多人游戏。可扩展性和边缘计算成为成功的关键。因此，Kubernetes 开始在这个社区站稳脚跟。

为什么选择 Kubernetes 和多人游戏

Kubernetes 是构建复杂工作负载和分布式系统的事实上的开源、通用标准。Kubernetes 为您提供了一个灵活运行分布式系统的框架。它负责应用程序的伸缩和故障转移，提供部署模式等等。Kubernetes 也已经成为边缘计算的一个非常重要的基础。它还允许用户在边缘运行容器，通过降低延迟和互联网流量来最大限度地利用资源，并支持 HA。Canonical 的 Ammar Naqvi 谈到 Kubernetes 和边缘计算:

“由于 Kubernetes 在物理资源(计算、存储和网络)之上提供了一个通用的抽象层，开发人员或 DevOps 工程师可以在任何地方以标准方式部署应用和服务，包括在边缘。”

解决我的基础设施问题

Kubernetes 将提供任何游戏工作室的好处。但它不只是让您的基础架构问题消失。它需要专业知识才能在不中断游戏玩家的情况下启动和运行。这就是为什么谷歌创建了谷歌云游戏服务器(GCGS)，一个更简单的多集群管理和自动扩展解决方案，以提供无缝的多人游戏体验。它利用了运行在 Kubernetes 上的开源、多人专用游戏服务器扩展和编排平台 Agones。但那是很难接受的。已翻译:

您可以将 GCGS 上的 Kubernetes 与 Agones 配合使用，提供更好的多人游戏体验。

对你的游戏工作室来说，这听起来可能很多。毕竟，好处听起来很大，但落实到位需要时间。你希望你的团队创造市场上最好的游戏，而不是最好的基础设施。

Fairwinds 管理 GCGS 和阿戈内斯的 Kubernetes

Fairwinds 与谷歌合作，向游戏工作室提供基于订阅的集成 Kubernetes 托管服务和经过战斗考验的开源软件，以改善您的多人游戏体验。Fairwinds 提供:

Fairwinds 让你的基础设施问题消失，让你专注于制作一个伟大的游戏，而我们处理基础设施。

作为代码的基础设施不应该有单点故障

原文：https://www.fairwinds.com/blog/infrastructure-as-code-should-not-have-a-single-point-of-failure

几个月前，，我在丹佛的一次会议上半开玩笑地谈论了瀑布的荣耀。我谈到授权开发人员部署他们自己的服务是一个多么可怕的、可怕的决定。这个谈话完全是故意挖苦人的。让开发人员拥有服务所有权无疑是对组织的授权 — 这是分布式服务开发的未来。

作为那次谈话的一部分，我开玩笑地提到了一位 DevOps 工程师的全部背景。这个神话般的人物 ( 谁我取名史蒂夫)对底层 基础设施如代码 和部署工作负载了如指掌。没有其他人知道所有这些部件是如何工作的，史蒂夫故意严格保守这个秘密。但是当史蒂夫退出时你会怎么做？

事情发生的比你想象的还要多

我发现这种情况比我讽刺的自己愿意承认的要普遍得多。这些年来，，我们有很多客户在他们的开发工程师 (或团队)离开公司时找到我们，他们陷入了恐慌。 “我们不知道我们的系统如何协同工作，我们已经几个月没有进行部署了。我们需要帮助，我们不希望这再成为单点故障。”

神话世界的伟大基建为代号

Let’s consider for a moment a mythical world where your infrastructure as code isn't proprietary—where you have tools, documentation, and code in place so that multiple people can understand all the pieces individually and working together. Imagine an infrastructure with a well-oiled team of people working together to maintain it, keep it up to date, and push things forward to enable innovation. In this new reality, developers have the tools they need to deploy without operations getting in the way.

如果你部署到一个有据可查的 PaaS (想想 Heroku) ，这个神话世界是可能的。但是，当一家公司对于简单的 PaaS 来说变得太大时，也可以部署到为满足您的需求而定制的记录良好的 PaaS。有了 Kubernetes(定制的 PaaS 构建器)，这是可能的，并且有一个工程师即服务团队在幕后与您的团队一起工作，这变得更加顺畅。

伟大基建为代号不一定要神话

在 Fairwinds，我们可以自动化地快速建造代号为的 基础设施。我们也让团队能够 用优秀的工具实现 DevOps 文化。没有正确的工具，最好的团队永远不会成功。美妙的是，我们的服务从不休假或退出。幕后工程师来来去去 (休假等等)，但是我们能够通过可重复的过程和自动化以稳定的方式维护事物。我们还为我们的客户提供一整个团队的工程师，与 — 冗余、冗余、冗余一起工作。我们构建的东西都不是专有的，尽管有时需要根据特定公司的需求进行定制。

总会有一些东西使您的特定基础架构独一无二，但在我们的帮助下，您可以获得冗余 (我提到过冗余？)，并降低单点故障的风险。我们无法为一个了解 s 您的应用程序堆栈的所有信息的开发人员解决问题，但是我们可以为一个掌握部署关键信息的运营人员解决问题。

徐达

ClusterOps by Fairwinds is managed Kubernetes. And more than that, it's managed managed Kubernetes. Because while anyone can login to a cloud console and deploy a cluster with a managed service, not everyone will understand all the decisions made above and beyond that. How many clusters do you want? How will you separate environments? What is your plan for upgrades? Where will you run your persistent data? What are best practices for security?Our team of experts is here to help—and unlike Steve, we're not going anywhere. To find out more, visit our ClusterOps Page.

介绍 fair winds Insights:Kubernetes 管理工具

原文：https://www.fairwinds.com/blog/insights-kubernetes-management-tool

我在应用安全和数据安全公司担任首席技术官超过 15 年，在此期间，我目睹了许多公司在尝试保护关键数据和基础架构时遇到的挑战。Kubernetes 和 Linux 容器的加速采用为开发、DevOps、信息技术和安全团队带来了许多新的挑战和机遇。

与任何新技术一样，随着 Kubernetes 的采用增加，以及团队学习和掌握保护这些新的 kube 和 Linux 环境所需的方法，会产生许多潜在的差距。有了 Kubernetes 集群和 Docker 容器，它代表了一种全新的软件部署方式。突然开发者需要理解 API、微服务和工作负载；需要跟踪新的指标，了解大量新的功能和配置。软件开发生命周期已经改变，容器化的应用程序越来越成为规范而不是例外。除了这些创新技术带来的挑战之外，许多传统的安全框架和流程不再有效，或者需要进行重大修改来保护这一新领域中的应用程序和数据。

绝不错过一步

作为一个组织，Fairwinds 专注于 Kubernetes 的管理和实施。今天，我非常自豪地宣布fair winds Insights正式上市。这一首次发布标志着我们将 Kubernetes config 多年的专业知识转化为 Kubernetes 管理软件的高潮，该软件有助于验证配置以提高安全性、降低成本、节省时间和运行可靠的工作负载。Fairwinds Insights 通过保护和优化任务关键型应用程序，继续支持 Kubernetes 的成功部署。

我们一直在更新对 Fairwinds 的见解，以改善我们用户的体验，使其更容易成功部署 Kubernetes。我们构建并利用开源软件，如 Prometheus、Polaris、Nova 和Goldilocks，在我们的 Insights 平台中充分利用 Kubernetes 容器编排功能。我们采用的方式使您能够利用您选择的公共云提供商，如 AWS、GCP 和 Azure，以及虚拟机或裸机基础架构，因此您可以以对您的组织最有意义的方式部署您的应用程序和服务。

安全、经济、可靠的工作负载

Fairwinds Insights 旨在解决 Kubernetes 团队面临的三大挑战:安全、经济高效和可靠的工作负载。

一致、安全的基于 Kubernetes 的应用

随着云原生世界的不断成熟，大多数组织以及运行它们和构建云原生应用的人员都了解 Kubernetes 生态系统的优势，以及为什么打破孤岛并最大限度地减少开发、安全和运营团队之间的摩擦非常重要。虽然亚马逊弹性 Kubernetes 服务 (EKS)、 Azure Kubernetes 服务 (AKS)和谷歌 Kubernetes 引擎 (GKE)都提供了自动部署、扩展和管理容器化应用程序的简单方法，但开发、安全和运营团队仍在努力维护一致、安全的基于 Kubernetes 的应用程序。

在某种程度上，这是因为 Kubernetes 环境非常复杂，并且因为围绕 kube 的生态系统不断成熟，带来了新的插件、附加组件和灵活性。Fairwinds Insights 通过创建策略执行自动化来帮助组织自动执行 Kubernetes 最佳实践。通过提供所有 Kubernetes 集群的仪表板视图，Insights 平台增加了 DevOps 团队对 Kubernetes 环境的可见性，这有助于团队了解导致安全和合规性风险的错误配置。

Insights 还减少了漏洞管理所需的时间，因为它提供了内置的漏洞扫描和深入的故障排除信息。它还有助于运行容器的团队识别错误配置和漏洞，因为它集成了命令行界面(CLI)工具，如 kubectl(Kubernetes 的默认 CLI 工具)和开发团队常用的其他工具。洞察有助于向负责解决这些问题的人员或团队发送通知和票证。

试错 CPU 和内存资源使用设置

Kubernetes 自动调整 CPU 和内存资源使用设置，以实现自动伸缩，但许多组织都在努力找出如何设置这些 CPU 和内存资源使用设置。试图找出最佳设置会占用工程时间，并导致过度调配云容量或应用程序性能低下。因此，一些团队在初始测试中根本不设置要求或限制，或者将它们设置得太高，以确保一切正常运行——然后他们再也不会回去调整设置。确保扩展操作按预期工作的关键是根据指标设置每个工作负载的资源限制和请求，以便每个工作负载高效可靠地运行。

我们构建了一个开源项目，【金凤花】，来帮助团队分配资源并获得正确的资源使用设置。该项目建立在洞察力的基础上，它帮助组织了解他们的资源使用、资源成本以及如何围绕效率应用最佳实践。Goldilocks 使用 Kubernetes Vertical Pod auto scaler(VPA)来评估工作负载的历史内存和 CPU 使用情况以及当前使用情况，以便就如何设置您的资源请求和限制提出建议。基本上，Goldilocks 为名称空间中的每个部署创建一个 VPA，查询它，并在仪表板中显示建议。Insights 通过自动化推荐流程来帮助团队消除猜测。无需反复试验，Insights 包括 Goldilocks，因此您可以提高 Kubernetes 集群效率并减少云支出。

监控维护可靠的工作负载

传统的监控工具不能提供主动识别维护可靠的 Kubernetes 工作负载所需的变化所需的一切。虽然配置要简单得多，但学习如何优化 Kubernetes 需要时间，特别是如果您使用的技术早于云原生应用程序和配置管理工具。如果您使用旧的监控解决方案，并在其上部署 Kubernetes 管理工具，那么优化、可靠性和可伸缩性就更难实现。

提高 Kubernetes 可靠性的一个方法是正确设置配置。这说起来容易做起来难。云原生架构的挑战之一是理解并真正拥抱容器和 Kubernetes pods 的短暂本质。一旦您更好地理解了这个生态系统，并且熟悉了供应和容器编排，您就可以分析您的指标，以便在设置 CPU 和内存的请求和限制方面做出更好的决策。这允许 Kubernetes 调度程序完成它的工作。Fairwinds Insights 的内置工具持续审计 CI/CD 管道和运行时环境，以识别甚至纠正 Kubernetes 在软件开发生命周期中出现的错误配置。

从开发、安全和运营方面改进移交

在过去的五个月里，我们对 Fairwinds Insights 进行了测试，有几十个客户积极使用它进行 Kubernetes 管理。我们已经确保 Insights 与部署工具集成，支持不同的开源 Linux 发行版，并且可以扫描容器映像以发现漏洞。Insights 还为各种 Kubernetes 环境提供 Kubernetes 监控，并利用开源 Kubernetes 工具，作为其对云原生计算基金会(CNCF)社区承诺的一部分。我们收到了大量反馈，并对我们解决的问题进行了验证:

对“我这样做对吗？”提供可行的答案面向平台工程师、开发人员和站点可靠性工程师。

随着公司采用 DevOps 来缩短交付新软件和服务的上市时间，现实是该过程永远不会像希望或想象的那样无缝。遗漏的步骤会导致错误配置，从而导致安全漏洞、成本低效率以及不可靠的应用和服务。虽然这种构建和运行应用程序的新方式能够实现更快的配置和自助服务，但它也要求您的监控和可观察性工具和策略发生变化。

我们的 Fairwinds 站点可靠性工程(SRE)团队在整个 Kubernetes 社区中一直看到同样的问题，并希望解决它们。这正是我们创建许多开源项目的原因:

Polaris，一个验证和修复 Kubernetes 资源的开源策略引擎
Goldilocks，一个帮助你获得资源请求和限制的实用程序
Nova ，这是一个 CLI，它可以交叉检查导航图表，以定位您的 Kubernetes 集群中过时和不推荐使用的图表
布鲁托，在基础设施即代码(IaC)存储库和 Helm 版本中定位已弃用的 Kubernetes API 版本，提供在 Kubernetes API 服务器中不可用的版本信息
RBAC 经理，一个支持基于角色的访问控制(RBAC)的声明性配置的操作员，具有新的定制资源，以简化 Kubernetes 中的授权

我们维护这些开源项目，并邀请合作来改进我们的开源工具，并随着需求的变化和 Kubernetes 的不断成熟添加功能。这些工具都是 Insights 提供的价值的一部分，我们将其与其他开源工具相结合，如开源漏洞扫描器 Trivy ，以及提供指标和警报的开源监控解决方案 Prometheus。Insights 使用收集的所有数据来提供一个 Kubernetes 仪表盘，显示 CPU 和内存的总使用情况。

Fairwinds Insights 使用 YAML 文件轻松部署，并贯穿整个开发生命周期。它包括与当今一些最普遍的解决方案的集成，例如:

一个松散的集成，以确保用户得到关于他们的 Kubernetes 集群的关键变化的通知
从 Insights 输入数据的 Datadog 集成，每当发现或修复一个行动项目时，就会创建一个事件，以帮助团队将问题与尝试的修复关联起来。
使用自动化规则为行动项事件创建事件的 PagerDuty 集成
吉拉集成允许 Insights 用户手动或使用自动化规则从行动项目创建吉拉票证
Azure devo PS 集成允许用户从操作项创建工作项

通过将我们的专业知识与值得信赖的开源工具相结合，Fairwinds Insights 发现了开发、安全和运营之间交接过程中遗漏的步骤，并使用自动化来设置护栏，以保持 Kubernetes 平稳高效地运行。借助fair winds Insights，平台工程师、DevOps 团队、开发人员和站点可靠性工程师现在拥有了一个 Kubernetes 管理平台，可以帮助他们以安全、高效和可靠的方式改进他们的云原生工作流。

介绍 fair winds Insights——管理 Kubernetes 配置以实现安全性、效率和可靠性

原文：https://www.fairwinds.com/blog/insights-pre-recorded-webinar

维护安全、高效和可靠的 Kubernetes 应用程序变得越来越复杂和耗时。Fairwinds 工程团队想要一种更好的方法。

Kubernetes 的错误配置会引入安全漏洞，抹杀资源效率收益并影响可靠性。Fairwinds 工程团队创建了 Fairwinds Insights 来帮助优化和保护您的关键 Kubernetes 工作负载。经过几个月的测试，Fairwinds Insights 现已正式发布！

观看 Fairwinds 首席执行官、Black Duck / Synopsys 前工程副总裁 Bill leding ham和战略副总裁 Joe Pelletier****，了解 Fairwinds Insights 如何提高 Kubernetes 的安全性、效率和可靠性。在 30 分钟内了解您如何:

提高安全性: Fairwinds Insights 审计您的工作负载，并验证配置中的弱点和容器漏洞。
降低成本: 了解应用资源使用情况，调整 CPU 和内存设置，进一步优化 Kubernetes 工作负载。
节省时间: 借助内置的协作工具、通知、工作流以及与 Slack 和 DataDog 等工具的集成，缩短周期时间，加快上市速度。

Kubernetes 最佳实践介绍:正确开始 K8s

原文：https://www.fairwinds.com/blog/intro-kubernetes-best-practices

使用 Kubernetes 取得成功没有唯一正确的方法，但是随着云原生生态系统继续快速扩展，许多开始 Kubernetes 之旅的组织不确定该走哪条路。幸运的是，成功部署 K8s 的方法不止一种——主要目标是确保您理解 Kubernetes 的最佳实践，这样您就可以覆盖您的基础并避免常见错误。“一盎司的预防抵得上一磅的治疗”这句谚语是有道理的。如果你能避免做出一个糟糕的决定，并在未来为此付出代价，为什么不呢？

您的业务需求和优先事项是什么？

那么，你怎样才能让你的组织走上正确的道路呢？选择最能解决您的业务的需求和优先级的一个。

您是否在金融或医疗保健行业工作，在这些行业，安全性是不容置疑的？
您是否有一个数据科学家团队或机器学习工作负载，这需要资源效率？
您的应用程序和服务能否承受停机时间，或者 99.99%(或更高)的可靠性是否是重中之重？

回答这些问题(以及许多更多的问题)可以帮助你决定如何实施 Kubernetes，创建流程，并在开始时阐明任务和优先级。一旦您花了必要的时间来了解 Kubernetes 如何实现您的云原生之旅，您就可以开始做出选择并审查可用的最佳实践，并做出适合您组织的选择。

Kubernetes 最佳实践

Fairwinds 团队在部署和调整数百个生产级 Kubernetes 集群方面积累了多年的经验，拥有丰富的 K8s 专业知识。我们的站点可靠性工程师已经帮助许多公司以更快、更具成本效益、更低的安全风险交付云原生应用。Kubernetes 网站提供了 K8s 入门的指南，包括大型集群的注意事项、在多个区域中运行、验证节点设置以及 PKI 证书和要求。我们的 Kubernetes 最佳实践指南侧重于帮助我们的客户安全、高效、可靠地采用云原生基础架构。

Kubernetes 的 5 个关键最佳实践

Kubernetes 安全最佳实践:避免因误解 K8s 默认安全而导致的失误。尽管 Kubernetes 有本地安全控制，但默认情况下它们没有被启用或配置。组织仍然容易受到三种常见的安全威胁:拒绝服务(DoS)攻击、利用应用程序代码和内部威胁。正确配置 Kubernetes，为这些和其他威胁做好准备。
Kubernetes 成本优化最佳实践: Kubernetes 是一个动态系统，可自动适应您的工作负载的资源利用率，允许您设置特定的资源请求和工作负载限制。设置这些限制可以防止云服务提供商不必要的大额账单。
Kubernetes 可靠性最佳实践:实现 Kubernetes 可靠性非常复杂，不正确的配置会对您的应用和服务的可靠性产生重大影响。云原生方法为您提供了调整应用组件通信和扩展方式的机会，并最大限度地提高可靠性。
Kubernetes 策略实施最佳实践:大多数组织都在单一应用程序中试用 Kubernetes，但是在多个应用程序、开发团队和运营团队中采用 Kubernetes 时，管理集群配置就成了一项挑战。不一致的配置很难管理和修改，但是自动执行策略可以最大限度地减少不一致。
监控和警报最佳实践: K8s 环境总是在变化，监控配置是事后才想到的。在 Kubernetes 中优化监控和警报可以为您的开发、运营和安全团队节省大量压力和时间。

Kubernetes 有数百种不同的用例及转换，并且没有单一的“正确”方法来部署集群。Kubernetes 有很大的灵活性，这最终意味着可能没有两个相同的 K8s 环境。我们正在分享我们团队来之不易的专业知识，以帮助您走上正确的道路，这样您就可以利用 Kubernetes 的长期优势。

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

阅读 Kubernetes 最佳实践白皮书,获得关于以适合您和您的组织的方式设置您的 Kubernetes 环境的全面指导。

Kube ingress 简介:在 Kubernetes 裸机中设置 nginx Ingress

原文：https://www.fairwinds.com/blog/intro-to-kubernetes-ingress-set-up-nginx-ingress-in-kubernetes-bare-metal

入口是使流量从外部进入 Kubernetes 集群的资源。这通常是对 HTTP 或 HTTPS 服务。有一些方法可以将非 HTTP 服务映射到入口，但是这种方法不太常见。这个博客将只关注 HTTP 和 HTTPS 流量。

入口资源的一个更有趣的方面是，尽管它是 Kubernetes 附带的基本原语，如 pod、部署、副本集等。实际上，它需要在群集上安装一个称为入口控制器的东西，以便入口资源发挥作用。在没有安装任何一个控制器的情况下创建入口资源将不起作用。

由于入口资源要求控制器运行，因此入口的配置可能有点开放。任何特定于您选择的控制器类型的配置通常都是通过注释入口资源来完成的。

您可以将入口控制器视为 Kubernetes 集群中所有服务的一种 web 服务器。它被配置为将请求路由到适当的服务；这与在裸机服务器上安装 Apache 以将网站暴露给互联网的时代没有什么不同。

您可以看到入口控制器和入口资源是如何构建的:

Nginx Ingress on GCP - Fig 01

来源: 谷歌社区教程

大多数入口控制器都允许你进行基于主机的路由，因此 foo.com 应该路由到 foo 名称空间中的 foo 服务，以及基于路径的路由-foo.com/dashboard 应该路由到 foo-dashboard 服务。

为了简单起见，我将演示一个入口控制器 nginx 入口控制器。这是 Kubernetes 社区中的一个流行选择，但我也希望鼓励您研究现有的各种入口控制器，并决定哪一种最适合您的应用。

让我们看一个例子。

你首先需要安装 nginx 入口控制器，文件在 GitHub 库中。这将启动 pod 和相关资源，为您处理和提供入口资源。 Nginx Ingress 入门页面提供了 Kubernetes 清单，用于在自己的机器、AWS、GCP 或 Azure clouds 上安装 Kubernetes。例如，要在您的机器上运行的 Kubernetes 中安装 Nginx Ingress:

kubectl apply -f 
https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.34.1/deploy/static/provider/baremetal/deploy.yaml

…..
NodePort:                 http  32316/TCP

接下来测试 Kubernetes 服务，它提供对 Nginx 入口控制器 pods 的访问，进而提供对入口对象的访问。在您的机器上运行的 Kubernetes 将配置有 NodePort 服务，云安装配置有 LoadBalancer 服务。要连接到节点端口服务，在您的机器上运行 Kubernetes 的情况下:

$ kubectl describe service -n ingress-nginx ingress-nginx-controller

在这种情况下，连接到您机器上的 localhost:32316。您应该会收到一个显示“404 未找到”的页面，这是入口控制器的默认响应。如果您使用的是云托管的 Kubernetes，请使用上面的“kubectl describe”命令，并连接到负载平衡器的主机名。

现在您将向 Kubernetes 部署一个测试应用程序。

这个应用程序是 httpbin，一个用于从 API 请求和接收回复的简单工具。它提供了 API 和前端，因此非常适合测试。该服务属于 ClusterIP 类型，入口将向该服务的端点(pods)发送流量。现在看一下上面的命令所应用的入口清单。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: httpbin
  namespace: httpbin
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: localhost
    http:
      paths:
      - backend:
          serviceName: httpbin
          servicePort: 80
        path: /

nginx 是我们正在使用的类。控制器查找这个注释，并知道它拥有这个入口。您会注意到，在 rules 部分，我们将主机设置为 localhost。如果您正在启动一个生产部署，这显然会有所不同——它可能是您公司的网站，或者您用于应用程序的任何 url。对于后端，我们指向刚刚启动的 httpbin 服务。现在确保 httpbin pods 正在运行。

$ kubectl get po -n httpbin -w

 NAME                       READY   STATUS    RESTARTS   AGE   IP               NODE       NOMINATED NODE   READINESS GATES
httpbin-675dcdbdbd-w64f7   1/1     Running   0          9s    10.244.120.104   NodeName         none		none

这个应用程序还提供了一个 restful API，JSON。你可以在 localhost: 浏览器里看一下

我们还可以通过访问 Nginx Ingress Controller 服务来查看浏览器中的 API，确保将“localhost”指定为 HTTP 主机头。主机头必须与入口中指定的主机名匹配。例如，将“ServiceHostName”替换为 localhost(如果在您的机器上运行 Kubernetes)或您的云负载平衡器的主机名: curl --header "HOST: localhost" http://ServiceHostName

有更多的入口。我们鼓励您阅读更多文档或试用其他入口控制器。如果你需要帮助，请联系。Fairwinds 提供 Kubernetes 服务，可在您的云原生之旅的任何阶段提供帮助。

附加资源

介绍 Terraform 和托管 Kubernetes 服务

原文：https://www.fairwinds.com/blog/intro-to-terraform-managed-kubernetes

Astro 简介:管理 Kubernetes 部署中的 Datadog 监视器，以提高工作效率和集群性能

原文：https://www.fairwinds.com/blog/introducing-astro-managing-monitors-in-a-dynamic-environment-0

“Astro 利用新的 Kubernetes-native 模式，帮助工程师以声明方式管理 Datadog 监视器，以适应这些环境的短暂性。我们很高兴能与 Fairwinds 合作，并支持他们努力使这一工具惠及整个社区。”

—迈克尔·格斯滕哈伯，Datadog 产品管理总监

Artboard 2

在 Kubernetes 环境中，我们看到的挑战之一是反映集群和工作负载状态的准确监控管理。监控往往是事后才想到的: a s 工作负载变化，很少进行监控更新。现有的工具依赖于手工配置监控状态、，这给 SRE 团队带来了很大的麻烦。它还增加了可用性和性能风险，因为监视器可能不存在或不够准确，无法触发 KPI(关键性能指标)的变化。由于未检测到的问题和/或不正确的监视器设置导致的传呼机噪音，这可能导致 SLA 违约。

To tackle this problem, Fairwinds has introduced a new open source software project called Astro. Astro is a Kubernetes operator that watches objects in your cluster for defined patterns and manages Datadog monitors based on this state.

Astro 提供了三个关键元素来大大简化 Datadog 监视器管理:

Datadog 监视器的自动化生命周期管理:给定配置参数，实用程序将自动管理 Kubernetes 集群中所有相关对象的已定义监视器。随着对象的变化，监视器会更新以反映该状态，从而消除了手动配置的需要。
逻辑绑定对象之间的关联: Astro 能够管理给定名称空间内所有对象的监视器。这确保了显示器配置之间的更大一致性。
将 Kubernetes 对象中的值模板化到受管监视器中:受管 Kubernetes 对象中的任何数据都可以插入到受管监视器中。这将生成更多信息性和情境化的警报，从而更容易对问题进行分类。

入门

您可以通过两个简单的步骤在集群中运行 Astro:配置您想要的监视器，并部署 helm chart。

监视器通过一个或多个 yaml 配置文件进行配置。这些文件可以是本地文件路径或通过 URL 远程访问。这些配置文件会定期重新加载，因此您所做的任何更改最终都会传播到您的显示器上。下面是一个配置示例:

In this example, a monitor would be created for any Kubernetes deployments that have the annotations listed in match_annotations (in this case, astro/owner: astro). This particular monitor will alert you when a deployment has no pods available. Astro uses go templating and you can insert any variables from the Kubernetes object or from the cluster_variables section of your config file into monitors. Specific details about the config file syntax is available in Astro’s readme.Once your config file is in place, you’re ready to deploy with helm! The helm chart is available on GitHub. If you’re installing with Reckoner, a tool to declaratively install and manage multiple Helm chart releases, here’s a snippet to install Astro:
In case you haven’t tried Reckoner, it’s available on GitHub.

欣赏天文

现在，每次使用 astro/owner 注释创建部署时，astro 都会自动为它创建一个 Datadog 监视器，如果它关闭了，我们会收到一个警报。如果没有 Astro，我们将不得不依靠工程团队手动创建这些监视器，这既耗时又容易出错。

Astro 是一个伟大的开源项目，它可以用来保持您的显示器同步，防止因显示器配置错误而中断，并对抗寻呼机疲劳。我们希望您喜欢自动化管理您的 Datadog 监视器！

Goldilocks:一个推荐资源请求的开源工具

原文：https://www.fairwinds.com/blog/introducing-goldilocks-a-tool-for-recommending-resource-requests

Fairwinds 的客户最常向我提出的一个问题是“我们如何知道如何设置我们的资源请求和限制？”今天我们开源了一个工具，希望能在这方面给大家一点帮助。Goldilocks 是一个 Kubernetes 控制器，它提供了一个指示板，给出了关于如何设置资源请求的建议。

为了提供建议，我们使用了垂直吊舱 (VPA)。VPA 控制器堆栈包含一个建议引擎，它会考虑到您的 pod 的当前资源使用情况，以便提供指导。VPA 的主要目标是实际上为你设置这些，但我们目前对它如何做到这一点并不满意；更具体地说，我们喜欢运行水平吊舱自动缩放，这并不适合 VPA。相反，我们只是使用 VPA 提供的推荐引擎，就如何设置您的资源请求和限制向您提供良好的建议。

我们利用 VPA 推荐引擎的方式很简单。我们在集群中运行一个控制器，监视标有 goldilocks.fairwinds.com/enabled=true的名称空间。在这些启用的名称空间中，我们查看每个部署对象并创建相应的 VPA 对象。VPA 设置为 Mode: Off ，并不实际修改您的资源请求和限制；它只是坐在那里，提供一个建议。这本身就很酷，但是为了查看这些推荐，你必须使用 kubectl 来查询每一个 VPA 对象。对于大中型部署，这可能会非常繁琐。这就是仪表板的用武之地。

“金发女孩仪表板”直观地展示了 VPA 建议。现在，您可以访问集群中的服务并查看两种类型的建议，这取决于您希望部署的 QoS 等级。仪表板如下所示:在

Goldilocks Dashboard Preview

如果你现在想自己安装金发女孩，请前往 https://github.com/FairwindsOps/goldilocks寻求指导。否则继续阅读，看看一些常见问题。

我如何安装金发女孩？

安装金发女孩最简单的方法是使用我们的舵轮图。您可以通过运行以下命令来实现:

helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install --name goldilocks --namespace goldilocks --set installVPA=true fairwinds-stable/goldilocks

这将安装 VPA(来自他们的回购)、金发姑娘控制器和金发姑娘仪表板。

现在您可以通过端口转发访问仪表板:

kubectl -n goldilocks port-forward svc/goldilocks-dashboard 8080:80

其他选项可在图表和金发女孩储存库中找到。

如果我想从仪表板中排除容器该怎么办？

这是我们对金发女孩的第一次升级，主要是因为 sidecar 代理模式。我们经常看到每个单元都有一个边车的集群，例如 Istio 或 Linkerd2 边车。您可能不想看到这些容器的资源建议，因为我们可能控制这些值，也可能无法控制这些值。有两种方法可以排除这些容器。

第一种方法是全局的，可以通过运行带有标志 --exclude-containers "istio-proxy,linkerd-proxy"的仪表板来设置。这是在舵图安装中默认设置的。

第二种方法是使用部署本身的标签来排除每个部署的容器: goldilocks.fairwinds.com/exclude-containers=linkerd-proxy,istio-proxy。

这个 QoS 类别是什么？

如果您还不熟悉它，QoS Class 指的是设置资源请求和限制的不同方式。有两个是我们关心的，还有一个几乎不应该使用。你可以在 Kubernetes 文档中阅读关于它们的详细信息，但是我将在这里对它们进行总结。

保证 —这是我最喜欢的 QoS 类别，因为它通常适用于最稳定的 Kubernetes 集群。在这个类中，您将您的资源请求和限制设置为完全相同的值，这保证了容器所请求的资源在它被调度时是可用的。

可突发 —这意味着您的资源请求低于您的限制。本质上，调度程序将使用请求将 pod 放在一个节点上，但是随后 pod 可以使用更多的资源，直到它被终止或限制为止。

BestEffort —不设置任何资源请求或限制。我们不建议你这么做。

Goldilocks 仪表板将为您提供有保证的和可突发的 QoS 类别的建议。这些是由 VPA 建议字段中的不同值生成的。在保证类中，我们建议您将您的请求和限制设置为 VPA“目标”字段。通常，我们将该值与水平 Pod 自动缩放器一起使用，以允许我们的应用程序进行缩放。突发类推荐来自 VPA 下界和上界油田。您可以在他们的回购中了解更多关于来自 VPA 的推荐人的信息。

感谢阅读

如果您有问题(或有如何改进的想法！)我们希望收到您的来信。联系我们的最佳方式是通过 Github 上的请求或问题。感谢阅读！

介绍五角大楼

原文：https://www.fairwinds.com/blog/introducing-pentagon

背景

2015 年，当我创立了 Fairwinds(又名 ReactiveOps)时，我们从一个简单的想法开始:为那些不能或不想自己做这件事的公司带来伟大的基础设施。我们想雇佣优秀的 sre，为解决复杂问题的大团队填补空缺。在此期间，我们与客户合作，如管道交易和改善。我们提供的东西有市场，事情进展很快。

当我们聘用 Justin Mound 时，他认为人们在云基础架构领域的需求大多是相同的。每个人都希望零停机时间和全自动部署、日志记录、指标、警报等…这个列表很长，但感觉每个人的列表基本上都是一样的。因此，我们开始尝试能否以可重复的方式解决这些问题，并通过为一大群对 Heroku 来说太大，但对网飞来说又太小的公司制作复杂的基础设施模板来发展业务。

最初，我们在 AWS 上解决了这个问题，使用 Terraform 构建了一个 VPC，使用 Packer 构建了 ami，然后我们编写了大量的 Ansible 来通过不同的环境将所有东西运送到生产中。我们建造的东西真的令人印象深刻。但是当我们建造这个 Docker 的时候，容器编排系统越来越受欢迎。

当 Kubernetes 在一年多前推出 1.2 版本时，我们(几乎)扔掉了我们写的所有东西，全力投入到 Kubernetes 上。Kubernetes 解决了很多我们之前解决的相同问题，但它做得更好；有了社区的支持和市场的需求，我们知道这是正确的方向。但是 Kubernetes 只解决了上面提到的那一长串中大家想要的一部分。

介绍五角大楼

上周，我们公开采购了五角大楼，这是我们构建基于库本内特斯的基础设施的框架。在您深入讨论之前，我们想谈谈我们在五角大楼所做工作的几点考虑。

五角大楼本身并不是基础设施，而是设计 来建造 基于 Kubernetes 的基础设施。 它不是一个 PaaS ，它只是在你自己的 AWS 账户中以一种自以为是的方式构建一个普通的基于 Kubernetes 的基础设施。
五角大楼严重依赖 Kops 在 AWS 上构建集群(我们有一个 GCP 替代五角大楼，但它还没有准备好见光)。
Pentagon 专为那些拥有比 Heroku(或任何其他“一刀切”的黑盒平台)这样的 PaaS 所能提供的更复杂需求的公司而设计。如果 Heroku 每月花费你 50 美元，不要离开。如果 Heroku 每月花费您 10，000 美元，并且您准备建立自己的基础设施，那么 Pentagon 可能是您的理想选择。我们有客户运行大数据设置，使用 Consul 或 Prometheus 等工具，并有不同寻常的安全需求:五角大楼是为了允许复杂的定制而建造的。
五角大楼是为 Fairwinds 设计的，允许我们快速建立许多复杂的基础设施，并安全和经济地维护它们，并从一个到另一个保持一致。它并没有考虑到您公司的具体需求。但是可以根据贵公司的需求进行定制。

还有更多的话要说，但这应该足够了。我想补充的是，当我们的工程师在 Fairwinds 上船时，他们在如何使用框架方面得到了很好的培训，我确信我们的文档还不足以让一切变得显而易见。所以，如果你选择这样做，就要小心地投入进去，并为大量的摆弄做好准备。当然，我们会不断改进，欢迎回来查看。拉请求，当然是欢迎的；所有代码都是 Apache2 授权的。

Screen Shot 2017-07-18 at 5.28.14 PM.png

你可以用五边形做到这一点。

北极星简介:保持你的 Kubernetes 集群健康

原文：https://www.fairwinds.com/blog/introducing-polaris-keeping-your-kubernetes-clusters-healthy

我很高兴向大家介绍 Polaris ，这是一个开源项目，有助于保持 Kubernetes 集群的健康。我们设计了 Polaris 来自动化我们在 Fairwinds 使用的一些最佳实践，以便为各种各样的客户安全可靠地运行集群。今天我们将它开源。

我们一次又一次地看到，部署配置中看似微小的失误可能会导致更大的问题，最终让您夜不能寐。像忘记配置资源请求这样简单的事情可能会破坏自动伸缩，甚至导致您的工作负载耗尽资源。像这样的小配置问题在过去会导致生产中断，现在使用 Polaris 完全可以避免。

Polaris 可以帮助您避免影响应用程序稳定性、可靠性、可扩展性和安全性的配置问题。它提供了一种简单的方法来识别部署配置中的缺点，并防止将来出现问题。有了 Polaris，您可以高枕无忧，因为您知道您的应用程序是按照一套经过充分测试的标准部署的。

我们开发的北极星包含两个关键组件:

一个控制面板，概述了当前部署在集群中的配置情况。
一个实验性的验证 webhook，可以防止任何不符合配置标准的未来部署。

北极星仪表盘

我们开发了 Polaris dashboard，通过它可以简单直观地了解您的 Kubernetes 部署的当前状态，以及可以改进的地方。该控制面板提供了集群范围的概览，以及按类别、命名空间和部署分类的结果。

1_6utxpDPxV3I85fl5sPFeag

我们在北极星的默认标准相当高，所以如果您的分数低于您的预期，不要感到惊讶。北极星的一个关键目标是设定一个高标准，并在默认情况下追求卓越的配置。如果我们包含的默认值太严格，很容易在部署配置中调整配置，以更好地适应您的工作负载。

作为发布 Polaris 的一部分，我们决定不仅发布该工具，还将发布我们选择包含的检查的完整文档。每个检查包括一个到相应文档的链接，这些文档解释了我们为什么认为它是重要的，并带有到围绕该主题的更多资源的链接。

北极星网钩

仪表板提供了当前部署配置状态的概述，而 webhook 组件则提供了一种方法，可以对集群的所有未来部署实施更高的标准。

一旦您有机会解决仪表板确定的任何问题，您可以部署 Polaris webhook 来确保配置不会再次低于该标准。当部署在您的集群中时，webhook 将阻止任何具有任何“错误”级别配置违规的部署。

虽然我们对这个 webhook 的潜力感到非常兴奋，但在我们准备考虑它的生产就绪之前，我们仍在进行更彻底的测试。这仍然是一个实验性的特性，是一个全新的开源项目的一部分。因为它确实有可能阻止对您的部署进行更新，所以请谨慎使用。

入门指南

希望如果你已经做到这一步，北极星是一个对你有用的工具。如果您想亲自查看结果，可以很容易地将仪表板部署到集群中。这是以最低限度的只读权限部署的，所有数据都由您保管。要使用 kubectl 部署仪表板，运行:

从那里，您可以使用端口转发在端口 8080 上本地访问仪表板:

kubectl apply -f
https://raw.githubusercontent.com/fairwindsops/polaris/master/deploy/dashboard.yaml

当然，还有许多其他方式来使用或部署北极星，包括与头盔。要了解更多信息，请查看 Github 上的北极星回购。

kubectl port-forward --namespace polaris svc/polaris-dashboard 8080:80

这仅仅是开始

我们对已经构建到北极星中的东西感到兴奋，但还有更多的东西要做。我们有各种各样的新检查，我们希望添加以扩大 Polaris 的范围，我们也在努力寻找最佳方式来为我们的验证规则提供名称空间或资源级别的异常。关于我们将要做的更多信息，请查看 Github 上北极星报告中的 路线图。

如果北极星听起来对你有用，请花些时间试一试。无论是问题、反馈、想法还是拉动式请求，我们都希望收到您的反馈。在这里，在 Github 或 Twitter 上开始对话。

If Polaris sounds like something that could be useful for you, please take some time to give it a try. Whether it’s questions, feedback, ideas, or pull requests, we’d love to hear from you. Start the conversation here, on Github, or on Twitter.

介绍 RBAC 经理:简化 Kubernetes RBAC 管理

原文：https://www.fairwinds.com/blog/introducing-rbac-manager-simplifying-kubernetes-rbac-management

在 Fairwinds ，我们用 Kubernetes 帮助一些大公司。与这么多不同的组织合作让我们对大规模维护 Kubernetes 所涉及的一些挑战有了独特的看法。

我们看到组织与 Kubernetes 斗争的最常见领域之一是管理 RBAC。对于许多组织来说，这是如此的困难和令人困惑，以至于 RBAC 经常甚至没有实现，或者只实现了一半。对于设法正确锁定 RBAC 配置的组织来说，他们经常发现配置很难维护。

缺乏适当的 RBAC 配置通常会导致太多的人过多地访问太多的 Kubernetes 集群。

在亲眼目睹了 RBAC 配置在规模上的挑战性之后，我们构建了一个开源的 Kubernetes 操作器来提供帮助。今天我们介绍的是 RBAC 经理。我们希望这个项目能够帮助那些正在努力管理他们当前的 RBAC 配置的组织，并且鼓励更多的组织在他们的 Kubernetes 实现中完全采用 RBAC。

RBAC 管理当前面临的挑战

为了充分理解我们对 RBAC 管理器的目标，有必要花一些时间来理解 RBAC 配置目前如何与 Kubernetes 一起工作。让我们从一个非常简单的单用户例子开始。我们称这个用户为“A”，他们需要 edit 访问集群中的 web 和 api名称空间。为此，我们将创建 2 个新的角色绑定:

 kind: RoleBinding 
apiVersion: rbac.authorization.k8s.io/v1 
metadata: 
    name: example 
    namespace: web 
subjects: 
  - kind: User 
    name: A 
    apiGroup: rbac.authorization.k8s.io 
roleRef: 
    kind: ClusterRole 
    name: edit 
    apiGroup: rbac.authorization.k8s.io 
--- 
kind: RoleBinding 
apiVersion: rbac.authorization.k8s.io/v1 
metadata: 
    name: example 
    namespace: api 
subjects: 
  - kind: 
    User name: A 
    apiGroup: rbac.authorization.k8s.io 
roleRef: 
    kind: ClusterRole 
    name: edit 
    apiGroup: rbac.authorization.k8s.io

当然，这并不特别复杂，但是对于单个用户来说，这是一个非常简单的配置。当我们引入更多的用户、名称空间或集群时，这变得更加复杂。

随着规模的扩大，不可避免地需要所有的 YAML 配置，很快就很难对其进行跟踪。获取用户列表并查看他们每个人在集群中的访问级别是一个令人望而生畏的过程。

此外，如果我们想要在其中一个名称空间中更改该用户的访问级别，这可能不像您希望的那么简单。没有办法把一个 roleRef 换成一个 RoleBinding。该方法包括删除一个 RoleBinding 并代之以用更新的 roleRef创建一个新的。

在越来越多地由自动化驱动的工作流中，作为代码的基础设施通常被视为黄金标准，这并不十分合适。这还不包括在任何规模上管理删除角色绑定会有多困难。你不能只是从回购协议中删除一个 RoleBinding ，然后指望某种自动化任务来为你管理变更。

现在当然可以修改 Kubernetes 角色和集群角色。为了获得最细粒度的结果，可以为每个角色绑定创建唯一的角色和集群角色，然后修改角色，而不是角色绑定。尽管在某些情况下这无疑是一个很好的解决方案，但是在任何规模上管理这些角色都会变得非常复杂。我们的目标是简化 RBAC 管理，因此，我们希望利用 Kubernetes 为我们的工作流提供的优秀默认角色。根据我的经验，在 RBAC 用户管理方面，这些默认的集群角色(查看、编辑、管理和集群管理)涵盖了大多数组织的绝大多数用例。

尝试用 RBAC 管理器简化这一过程

我们对 RBAC 管理器的目标一直是让 RBAC 配置更容易使用。我们想要一种方法，它允许更简单的配置以及更直接的自动化途径。

更简单的配置

RBAC 管理器是一个 Kubernetes 操作员，监视新的或更新的 RBACDefinition 定制资源。为了创建上述场景的两个角色绑定， RBACDefinition 需要大约一半的 YAML 配置:

 apiVersion: rbacmanager.reactiveops.io/v1beta1 
kind: RBACDefinition 
metadata: 
    name: rbac-manager-config 
rbacBindings:
  - name: user-a-example 
    subjects: 
      - kind: User 
        name: A 
    roleBindings: 
      - clusterRole: edit 
        namespace: web 
      - clusterRole: edit 
        namespace: api

随着更多用户、名称空间或集群的加入，配置的减少只会变得更加显著。当然，RBAC 还有比这个例子更多的东西。RBAC 管理器支持在命名空间或集群级别将用户、组或服务帐户绑定到角色或集群角色的任意组合。

根据我们的经验，这种用单个定制资源分配多个角色绑定的能力非常强大。您不再需要寻找跨多个名称空间的角色绑定来理解您的 RBAC 配置的当前状态，取而代之的是它被整齐地总结在一个单一的 RBAC 定义中。

自动化之路

RBAC 管理器的设计理念是，我们希望在 Kubernetes 中实现 RBAC 管理的自动化。手动进行这些更改很容易出错，而且根本无法很好地扩展。不幸的是，这里现有的 Kubernetes 资源不能像部署那样自动更新。

考虑到这一点，RBAC 定义的功能更像是部署，而不是角色绑定。就像部署简化了更新 pod 一样，RBAC 定义旨在简化更新角色绑定和集群角色绑定。对 RBAC 定义的更改会触发其拥有的资源的更改，在本例中是角色绑定和集群角色绑定。如果 RBAC 定义中不再引用角色绑定，RBAC 管理器会将其删除。同样，如果 RBAC 定义中请求的角色发生更改，RBAC 管理器将删除并重新创建适当的角色绑定。最后，如果删除了 RBAC 定义，所有关联的角色绑定和集群角色绑定也将自动删除。

这种新方法打开了自动化的大门，并允许您使用 CI 工作流管理 RBAC 配置。与部署如何简化 CI 工作流中的 pod 更新类似，RBAC 定义可以简化角色绑定和集群角色绑定的更新。

在过去的几个月里，我们发现 RBAC 管理器对我们在 Fairwinds 的工作流程特别有用，我们希望您能像我们一样发现它的帮助。

这是一个完全开源的项目，我们很乐意接受你的任何想法或贡献。欲了解更多技术信息，或安装它，请访问我们的 GitHub 。请继续关注一些后续帖子，内容涉及我们如何使用 RBAC 管理器来管理 AWS 和 GKE 集群上的 RBAC 配置。

介绍 Fairwinds 开源用户组

原文：https://www.fairwinds.com/blog/introducing-the-fairwinds-open-source-user-group

Fairwinds 喜欢开源。我们是 Kubernetes 和围绕它的开源技术社区的忠实拥护者。多年来，我们的团队为客户管理了数千个集群，对需要解决的问题有了一定的了解。我们已经用开源工具解决了其中一些问题，包括:

北极星 运行各种检查，以确保 pod 和控制器使用 Kubernetes 最佳实践进行配置，帮助您避免未来出现问题。
Goldilocks 是一个实用程序，可以帮助您确定资源请求和限制的起点。
Nova 是一个命令行界面，用于交叉检查集群中运行的最新版本的掌舵图
Pluto 帮助用户在他们的基础设施即代码仓库和 Helm 版本中轻松找到不推荐的 Kubernetes API 版本。
RBAC 管理器 是一个支持具有新定制资源的 RBAC 的声明式配置的操作器。您可以指定所需的状态，而不是直接管理角色绑定或服务帐户，RBAC 管理器将进行必要的更改以达到该状态。它简化了 Kubernetes 中的授权。

Fairwinds 开源用户组

对于成千上万的用户，我们希望有一种方法将我们开源项目的用户聚集在一起讨论开发，并给用户一个影响路线图的机会。我很兴奋地宣布新成立的 Fairwinds 开源用户组！成员们可以加入提问小组，分享工作成果，并相互交流。

我们的第一次开源用户组聚会将在美国东部时间 6 月 17 日上午 11 点举行。如果你有兴趣加入，你可以注册加入群，我们会向你发送邀请。

Kubernetes 成熟度模型简介

原文：https://www.fairwinds.com/blog/introducing-the-kubernetes-maturity-model

无论您是 Kubernetes 新手还是有部署经验，Kubernetes 都有您需要克服的复杂性。在 Fairwinds，自 2015 年以来，我们一直在帮助公司建立生产级 Kubernetes 集群。我们已经构建、测试和管理了数百个 Kubernetes 生产实例，重点关注安全、可靠和可扩展的环境。

由于这种端到端的体验，我们处于一个独特的位置。这就是我们创建 Kubernetes 成熟度模型的原因。我们的 Kubernetes SREs 团队花时间考虑整个端到端的旅程，您将经历哪些阶段，以及在每个阶段您需要学习/开展哪些技能和活动。

Kubernetes 成熟度模型旨在帮助您自我识别所处的阶段，了解您环境中的差距，并深入了解如何增强和改进您的 Kubernetes 堆栈。

当您使用成熟度模型时，要知道如果您确实到达了某个阶段，您可能仍然需要重新访问以前的阶段。此外，要明白 Kubernetes 的成熟不会一蹴而就——它需要时间。Kubernetes 成熟度模型应该作为一种工具，帮助您了解在您的云原生之旅中，您需要关注或需要帮助的地方。

这里我们提供了每个阶段的快速总结。

MaturityModel_horz_v2 copy (1)

第 1 阶段准备:您正在考虑 cloud native 和 Kubernetes 将如何帮助您实现业务和技术目标，成本是多少，以及您打算实现什么目标。

第二阶段转型:您正在建立 Kubernetes 基础设施，并将工作负载转移到平台上。你必须转化和改变你现有的思维模式、工作流程和实践。

第 3 阶段部署:您已经对 Kubernetes 的概念有了基本的了解，并且正在通过练习开发、部署、管理和故障排除技能来练习基本概念的使用。您将实现过程、CI/CD、授权开发人员并引入一些监控和可观察性。

第 4 阶段建立信心:您正在建立对自己核心能力的信心，以便成功地定期部署和发布功能。您还对 Kubernetes 有了更深入的了解，使您能够在整个组织中进行定制、试验和部署。

第 5 阶段改善运营:您正在积极地成功地跨业务部署 Kubernetes。现在，您希望提高 Kubernetes 集群的安全性、效率和可靠性。

第 6 阶段测量&控制:您正在了解您想要测量的内容，并实施复杂的监控和警报。您还需要确定在安全性、配置和标准方面需要控制的行为。

第 7 阶段优化&自动化:您正在使用更复杂的工具来消除人为错误和劳动，提高可靠性并最大化效率。

Kubernetes 成熟度模型介绍——如何使用

原文：https://www.fairwinds.com/blog/introduction-kubernetes-maturity-model

Fairwinds 团队在一年前开发了 Kubernetes 成熟度模型，我们将继续更新和完善它，以反映您在 Kubernetes 成熟度之旅中所经历的五个阶段。如果 Kubernetes 成熟度模型对你来说是新的，这是一个关于如何使用它的有用的介绍和指南。

在你做任何事情之前，考虑一下云原生之旅对你和你的组织意味着什么。Kubernetes 并不适合每个人，所以请确保您了解从哪里开始，谁可以信任，以及如何通过拥抱 Kubernetes 来证明价值。

成熟度模型的第一阶段是关于转型，比如建立 Kubernetes 基础设施和转移工作负载。
第二阶段涵盖了实现和部署过程，设置 CI/CD，授权开发人员，以及有限的监控和可观察性。
第三阶段是关于建立对你的 Kubernetes 核心竞争力的信心，因此你可以定期成功地部署和发布特性。
第四阶段包括改善您的操作和控制，特别是集群的安全性、效率和可靠性。
第五阶段是最后一个阶段，实际上是关于控制的。在这最后一个阶段，您将使用复杂的监控来推动策略和控制，从而更深入地了解工作负载。

当然，任何成熟度模型都是一个过程，您可能会在不同阶段之间来回移动，有些阶段会比其他阶段花费更长的时间。即使你已经到了第五阶段，你也将一直致力于持续的优化，消除人为错误和努力，提高可靠性和效率。

现在您已经了解了基础知识，那么您实际上如何使用 Kubernetes 成熟度模型呢？在本帖中，我们将只探索最初的几个阶段来帮助你开始。首先，该模型旨在供任何人使用，无论您是 Kubernetes 的新手还是已经有经验的用户。让我们看一个例子。

示例 1:

您有两个开发人员尝试了 Kubernetes，并希望在您的工程团队中部署它。从准备阶段开始，用它作为检查清单，确保您(和您的组织)在这些关键问题上意见一致:

Kubernetes 要解决的问题
开源软件现在和未来的重要性
该项目符合您的业务目标

进入第 1 阶段:花时间概述你的业务目标，并获得整个组织的认可。现在，您已经准备好开始设置 Kubernetes 基础设施，并计划如何转移工作负载。在此阶段，您需要采取几个关键步骤来真正开始您的 Kubernetes 转型:

确定工作负载的优先级—决定您要从哪些工作负载开始。不要期望一次迁移所有的工作负载；你需要计划一个分阶段的方法。
与 Kubernetes 一起进行概念验证(POC ),以便您了解其中涉及的内容以及如何成功完成。您可能会发现，与 Kubernetes 专家合作，确保您正确地设置了第一个集群，以便它们能够满足您的工作负载需求，会很有帮助。
进行技术改造。这不是一个小任务。当您迁移到 Kubernetes 时，您需要深入研究您现有的堆栈，并确定您的技术需求。您还需要考虑应用容器化、您的云和 Kubernetes 基础设施、YAML 或掌舵图、外部依赖、您的 Git 工作流、您的 CI/CD 管道、测试，以及最终将您的应用推广到生产环境。

准备步骤和进入第一阶段是耗时的步骤，通过这些步骤你会学到很多东西。不要急；这个学习阶段和技术转型步骤对于实现您的总体目标至关重要。

请继续关注本系列的下一篇文章，它将概述第二和第三阶段。我们将在最后一篇文章中讨论第四和第五阶段。与此同时，请阅读我们的参考资料中关于 Kubernetes 成熟度模型的所有内容，或者查看我们的新电子书以了解更多信息。

Kubernetes 是新的闪亮的工程玩具吗？

原文：https://www.fairwinds.com/blog/is-kubernetes-a-new-shiny-engineering-toy

你担心你的工程师只是想摆弄新技术

你的工程师确实想摆弄新技术。现在，理解 Kubernetes 的工程师比不理解的工程师对市场更有吸引力。但是这并不一定是一件坏事，让你的工程师使用被广泛采用和大肆宣传的技术是吸引和留住人才的好方法。

cat with big eyes. ooh... shiny k8s.

Kubernetes 有很多关于它的宣传。我们只是在炒作的开始。Kubernetes 托管产品的三个主要云的采用以及生态系统中工具和公司的激增证明了炒作不只是烟幕和镜子。

是忽必烈过度杀戮吗？

原文：https://www.fairwinds.com/blog/is-kubernetes-overkill

是不是忽必烈过度杀戮？

这是一个很常见的问题，尤其是因为大多数中等规模的 SaaS 网络和电子商务公司总有一天会决定离开 Heroku。( 最终大家都离开了龙。 )决定是这样的——选择 AWS、Docker Swarm 或其他一些“简单”的解决方案，或者大胆地选择 Kubernetes。

从 Heroku 迁移到 AWS、Docker Swarm 或本土解决方案通常会带来可避免的迁移创伤。这是因为这些解决方案看起来比 Kubernetes 简单，但从长远来看，总是更具限制性、更具挑战性且成本更高。Heroku 退出的恐怖故事层出不穷，但许多公司对接受 Kubernetes 犹豫不决。让我们来看看为什么。

Kubernetes:可扩展性故事

中小型公司不选择 Kubernetes 的一个最常见的原因与规模有关。“我只有一个 Rails 应用程序，”CTO 可能会说，“而普通的老 EC2 虚拟机会给我我需要的东西。Kubernetes 是关于规模的。太多了，我不需要无限扩展。”

问题来了。没有基础设施需要从十个节点增加到几千个节点。(但是，您确实需要至少两个节点，因为现实是应用程序可能会崩溃。)这个可伸缩性故事是在转移视线。Kubernetes 不仅仅是关于可伸缩性。

首先，在常规 EC2 实例上运行的应用程序不会自动重启，如果你的 Rails 应用程序耗尽内存并崩溃的话；相反，有人在半夜收到传呼，不得不重启它。另一方面，Kubernetes 具有自动健康检查功能，如果您的 Rails 应用程序由于任何原因(包括内存不足或锁定)无法响应，Kubernetes 会自动重启它。使用 Kubernetes，基于分支的开发环境也很容易，但是使用自主开发的 EC2 自动化，这几乎是不可能的。

考虑一下——通过更高的可用性、自动扩展和更丰富的特性集，您可以实现什么？

偶然与本质复杂性

中小型公司不想使用 Kubernetes 的另一个常见原因？复杂。

事实是 Kubernetes 很复杂。不可否认，启动并运行可能是一个挑战。但是这种复杂性意味着有一个对它有利的论点。

20 世纪 60 年代，弗雷德·布鲁克斯写了一部计算机科学领域的开创性著作，名为 【神话中的人月 。在这篇文章中，他讨论了他的团队为构建 IBM 大型机 OS/360 所做的努力，并描述了两种类型的系统复杂性:偶然的和本质的。偶然是随机引入的那种(坏的那种)，本质是完成一项工作所必需的那种(好的那种)。

ECS 和 Docker Swarm 表面上看起来更简单，但它们都有更多的意外复杂性——而且它们把这种复杂性强加给了你。这种复杂性一开始并不明显。那么偶然复杂性到底是什么样子的呢？首先也是最重要的，你需要补偿系统做不到的。例如，ECS 需要您编写大量代码才能使其可用(有时需要数万行代码)。这些工具的工作方式也有结构上的限制，并且有一个陡峭的学习曲线。

Kubernetes 反过来又具有较低的偶然复杂度和较高的本质复杂度(实现你实际想要实现的事情所需的复杂度)。Kubernetes 的强大之处在于它是 Google 的第三代容器管理，而 Swarm 和 ECS 才刚刚起步。

不变税

一些公司不太担心 Kubernetes 的复杂性，而是担心这种复杂性可能得不偿失。他们担心他们的团队将不得不支付 Kubernetes“税”,并且不会得到足够的价值来证明开销的合理性。

为了避免这种“税收”，他们雇佣了一个聪明的开发团队，看看他们能想出什么。你猜怎么着？如果你允许，他们会建立一个基于 Kubernetes 的平台。如果没有，他们会试图从零开始建立类似 Kube(我们称之为“faux netes”)的东西，这会给公司留下技术债务。(当你自己构建的时候，你总是得到一个满是 bug 的、更贵的 Heroku 版本。这就是云计算基础设施的第十条规则。)

当您的目标是构建产品时，为什么要将有限的开发资源部署到运营任务中？如果你不需要或者没有必要建造自己的 Heroku，为什么要雇佣 DevOps 工程师呢？ 在我们的下期帖子中了解一下: 如何让成为你的开发者的硬汉

Kubernetes 服务所有权是提高容器安全性的关键吗？

原文：https://www.fairwinds.com/blog/is-kubernetes-service-ownership-the-key-to-better-container-security

在软件开发和 Kubernetes 的世界中，服务所有权意味着开发团队在服务生命周期的每一个阶段都有责任支持他们交付的产品。这种模式使开发团队能够更好地控制软件在生产中的运行方式，并使运营团队能够专注于核心基础设施，而不是调试和优化应用。

Kubernetes 目前最热门的话题之一是围绕对更全面的容器安全性的需求——以及如何通过更好的整体服务所有权来促进这一根本变化。

集装箱安全的挑战

Cloud native 和 Kubernetes 服务所有权通过让开发团队对其应用程序代码和配置中的安全问题负责，帮助开发团队提高安全性。Kubernetes 集群的全面服务所有权使这种转变能够在开发过程的早期解决安全问题，这是所有团队都应该考虑纳入常规实践的事情。换句话说，正确的服务所有权是 DevSecOps 中的“Sec ”,现在被认为是软件安全的黄金标准。

许多组织在尝试大规模采用 Kubernetes 时面临挑战，主要是因为他们缺乏适当启动安全容器环境的工具、流程和经验。这可能是一场真正的斗争。由于 Kubernetes 和容器提供了一种部署应用程序的新方法，运营和安全团队质疑当他们采用微服务、容器和 Kubernetes 来开发和部署应用程序时，应用程序和数据是否安全。

为什么？因为许多传统的安全工具和流程不再适用。容器创造了新的安全盲点，以及新的攻击面，使得跨容器和集群的可见性变得更具挑战性。因此，开发人员必须为一些新的安全挑战承担责任，这是他们不习惯也不愿意承担的角色。这就是为什么组织必须学会在开发过程中“向左”转移安全性，给予他们解决安全性问题所需的观点。这种方法位于 DevSecOps 的核心，团队紧密集成，并帮助企业避免与 Kubernetes 所有权相关的五个关键错误。

你知道你可能犯的五个错误吗？

服务所有权解决方案

Kubernetes 提供了一个运行分布式系统的框架，该框架由微服务和容器构建，以弹性地运行应用程序。也就是说，Kubernetes 很复杂，这意味着不同的团队需要拥有不同的堆栈层。

以运营为例。即使拥有完全的服务所有权，运营团队本质上拥有平台层，也就是核心基础设施，确保 Kubernetes 可用并随时可以扩展。寻求成功的运营团队必须拥有多集群可见性和策略执行，这基本上允许他们向开发团队提供可操作的反馈。

在 Kubernetes 中，产品和开发团队在建立强大的安全态势方面也发挥着关键作用。为了取得成功，必须很好地建立服务所有权，以便开发人员确切地知道他们负责什么样的安全实践。

Kubernetes 服务所有权对于基础设施团队和应用程序开发人员来说可能看起来有点不同:基础设施团队应该主要关注核心基础设施的安全性，同时为应用程序配置制定策略和合规性仪表板；开发人员在构建他们的部署配置时，应该专注于遵守这些策略。

因此，基础设施和开发团队需要允许他们进行交流和协作的自助工具。这些可观察性工具使他们能够诊断和分类安全性、效率和可靠性问题。

下载 Kubernetes 服务所有权的完整指南！

Fairwinds Insights 如何支持 Kubernetes 服务所有权

Fairwinds Insights 通过简化复杂性和实现全面的服务所有权，统一了开发、安全和运营。为了帮助团队克服文化挑战并接受服务所有权，Insights 促进了:

支持 —开发团队在他们的应用程序中拥有安全性和效率配置，因此这不仅仅是一个运营问题。
可靠性 —服务所有者可以使用最佳实践指南配置 Kubernetes 策略，确保快速、可靠的应用并避免停机。
持续改进 —团队可以通过整合从 CI/CD 到生产的服务所有权，持续改进 Kubernetes 的使用方式。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

Kubernetes 是否过于复杂？

原文：https://www.fairwinds.com/blog/is-kubernetes-too-complex

人们说 Kubernetes 太复杂，你担心他们是对的。

感觉网上至少有一半的文章都在说 Kubernetes 对于你需要的东西是如何的矫枉过正。当然，你可以配置 Kubernetes，让你的团队过于复杂和难以维护，但这就像说你不应该开车，因为自动车窗可能会打破。自动车窗很好，但如果你需要简单和一个不太复杂的系统来维护，你可以买一辆带曲柄的汽车(见鬼，如果你想，你可以买一辆没有窗户的吉普车)。同样，您可以简单地配置 Kubernetes 您可以在其上运行单个服务，您可以对其进行配置，因此开销非常小。

k8s is overkill change my mind

暂时将 Kubernetes 与 WordPress 进行比较。你可以使用现成的 WordPress，在托管服务上，它非常容易部署，在开始使用的几分钟内就可以发布你的第一篇博客文章。但是你也可以自己托管开源版本，尝试自己保护它，在必要的时候升级它，手动管理 100 个插件(实际上有无穷无尽的 WordPress 插件)。您可以做所有这些事情，但是您可能不应该这样做，因为直接使用它(在某个有很棒的盒子的地方)要容易得多，并且让其他人去担心困难的部分。

Kubernetes 在很多方面都很相似。你可以仔细阅读教程，手工构建所有东西，但是你可能不应该这么做。利用云中的托管服务，让他们处理升级的复杂性，并让一切在底层硬件上运行。利用像 Fairwinds 这样的合作伙伴来帮助使配置顺利并为生产做好准备。寻找一个完整的 Kubernetes 治理平台？Fairwinds Insights 是免费的。今天就开始吧。

嘿，至少 Kubernetes 不是用 PHP 编写的。

您的 Kubernetes 基础架构是生产级的吗？

原文：https://www.fairwinds.com/blog/is-your-kubernetes-infrastructure-production-grade

Kubernetes 是一个强大的管理容器的开源平台，支持声明式配置和自动化。它可以完全定制为您业务所需的平台即服务。这种可扩展性和可定制性是巨大的好处，但是它们也有一些警告。

虽然设置您的第一个 Kubernetes 集群看起来很容易，但是正确配置集群并按照生产级标准构建集群是团队的责任。然而，没有正确的方法来部署 Kubernetes。面对一个充满开源和商业化产品的环境，您是否充分利用了 Kubernetes 提供的所有功能？

现实情况是，团队可能缺乏将 Kubernetes 部署到生产级标准的经验。同时，这些团队可能认为他们做得对，但是对环境缺乏信心。不幸的是，在不增加技术债务的情况下，如何以生产级部署所需的一致性来扩展和维护系统可能存在不确定性。

团队需要一种一致的方法来确保遵循 Kubernetes 在安全性、效率和可靠性方面的最佳实践，这样他们就不会害怕采用该技术并将应用程序构建/迁移到新平台。

Kubernetes 审核并改进

这正是我们创建Kubernetes Audit and Improve的原因:帮助团队满怀信心地建立生产级 Kubernetes 基础设施。

作为服务和软件的结合，Kubernetes Audit and Improve 帮助团队避免不必要的反复试验，防止技术债务，并确保团队实现 Kubernetes 基础设施的全部好处。Audit and Improve 是一项 Fairwinds 服务，它审核您的 Kubernetes 环境，根据既定的最佳实践提供改进计划，并提供持续验证，以增强安全性、效率和可靠性。

我们的 SREs 团队将使用专门构建的自动化功能审核您的环境，提出改进建议，并在实施变更时通过 Slack 为您的团队提供支持。然后，根据这一基准， Fairwinds Insights 提供配置验证软件，以帮助确保生产级环境的持续维护和最佳实践使用。

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

Fairwinds Audit and Improve 不仅能让您的 Kubernetes 基础设施达到生产级别，还能与您的开发人员和工程团队合作，确保您现在和将来都能成功运行 Kubernetes。

是时候看看我们的专家在 Kubernetes 中给出的这 6 个关键预测了

原文：https://www.fairwinds.com/blog/its-time-to-check-out-these-6-key-predictions-in-kubernetes-from-our-experts

当然，没有人真正知道未来会发生什么。在经历了两年出人意料的全球疫情，以及随后的的伟大辞职后，这是一个我们都学会欣赏的现实。我们知道疫情为领先的云提供商带来了更多收入，同时也加速了传统企业技术的转型。因此，企业肯定会继续向云原生应用转移，以应对其竞争挑战和目标。但是对于技术创新和 Kubernetes 的采用，还有什么其他的前景吗？

Predictions are fun, so we asked some of our own experts here at Fairwinds—Kendall Miller, Andy Suderman, Joe Pelletier, Robert Brennan and Ivan Fetch—to share some of their thoughts and perspectives on how Kubernetes technology and service ownership will likely evolve over the next year—and what we can expect to see as a result.

Fairwinds 专家对 Kubernetes 的未来有什么预测？

作为首席执行官和客户联络员，我看到了即将到来的一个重大主题，这个主题肯定会在未来一年引发行动，即不断提高网络安全的需求。关于 CVEs 的话题，有趣的是看到拜登政府最近要求几乎所有联邦机构修补数百个现有的安全漏洞。这是一个迫不及待的举动，正如最近涉及 log4j(一个广泛使用的开源组件)的 note 漏洞所证明的那样。

供应链在 2021 年无疑是一个热门话题，实体供应链的显著中断导致短缺和通胀压力。在软件供应链中，安全性在 2021 年的不同时刻都是一个问题，但随着新的一年的发展，我们肯定会看到更多的关注。目标是让组织改进其方法，以降低风险、避免中断并找到卓越的企业适应性，包括增强强化、弹性和合规性的需求。

肯德尔·米勒，总裁

2022 年将是 eBPF 的全盛之年。将可观察性、跟踪、安全和网络监控的内核级控制视为驱动主题。由于起源于 Linux 内核，eBPF(Extended Berkeley Packet Filter)可以在不改变源代码或加载内核模块的情况下扩展内核的功能。我们可能会看到 Kubernetes 领域的长期参与者取得重大进展，因为术语“eBPF”变得更加熟悉，人们开始了解这项技术的力量。随着 Kubernetes 继续成为容器编排的事实上的标准，以及所有未来云基础设施的基础，持续集成将是实现这一现实的基础。

安迪·苏德曼，研发与技术总监&

作为处理 Kubernetes 集群管理和应用交付的一种方式，GitOps 很可能成为工作流的一种更常见的标准。GitOps 的工作原理是将 Git 作为基础设施和应用程序的单一事实来源。由于 Git 处于交付管道的中心，开发人员可以使用熟悉的工具来发出拉取请求，从而加速和简化 Kubernetes 中的应用程序部署和操作任务。此外，集群生命周期——升级和插件管理——肯定会从第三方解决方案中看到巨大的改进。

乔·佩尔蒂埃，战略副总裁

在最近与销售团队交流后，很明显，更多运行 Kubernetes 的平台工程/运营团队将寻求为开发人员提供反馈和最佳实践。作为全面服务所有权的一个关键原则，消除团队间的摩擦和增强团队间的协作的愿望——推动创新和业务——仍然是我们最关心的问题。随着公司在多个团队中采用 Kubernetes，他们可能会发现需要更有效的护栏和开发人员的反馈回路。

罗伯特·布伦南，开源软件总监

因为开发人员需要了解他们的应用程序如何在 Kubernetes 上运行，所以全面的服务所有权将仍然是 2022 年值得关注的一个重要主题。遵循 DevSecOps 原则，诸如健康检查和资源调整之类的职责将继续向开发团队转移。此外，插件管理很可能会走到前台，因为人们开始在 Kubernetes 中部署更多的第三方工具，如 nginx-ingress、cert-manager、Istio、Kubeflow 和其他工具。

软件工程师 Ivan Fetch

像 Kubernetes 这样的分布式系统的使用越来越多，使得将警报提取为核心发现变得极其重要。例如，“这 100 个应用程序有 15 个容器漏洞”变成了“更新此基础映像以解决影响这 100 个应用程序的这 15 个容器漏洞。”

团队最终将更加关注 Kube 托管应用的运行时分析，这有助于跟踪自上次部署以来的新问题以及由错误配置或网络攻击等原因导致的不良行为。当检测到运行时问题时，团队将考虑使用更多的自动化来减少风险和浪费的时间。

自动化有可能导致新的问题，如在对不必要的行为做出动态反应时无意中影响客户访问。然而，随着新的和不太熟悉的工作负载类型被部署到 Kubernetes，集群操作将需要自动调整一些参数来帮助保持这些工作负载的运行，而这一切都不会牺牲集群或相邻工作负载的稳定性。

你如何为 Kubernetes 的未来做准备？

仅仅理解将要发生的事情是不够的。您需要尽快解决最紧迫的问题，以缩短创新愿景和卓越业务影响力之间的距离。因为有一件事是肯定的，2022 年是大胆和颠覆性的一年。

我们的 Kubernetes 治理和安全平台fair winds Insights，集成了一套可扩展的可信开源审计工具，帮助您的组织在整个开发生命周期(从 CI 到准入到生产)中管理 Kubernetes 的安全性、效率和可靠性。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

使您的 DevOps 团队能够在应用从开发进入生产时发现并防止 Kubernetes 的错误配置。Insights 提供了与 CI/CD 工作流的现成、用于在预部署时强制执行客户策略的 (使用 Polaris 或开放策略代理)以及用于运行 Kubernetes 审计工具的自动化。调查结果和建议存储在一个位置，使运营商能够了解和控制多个集群，跟踪和优先处理问题，并有效监控 Kubernetes 工作负载的安全性和成本。

K8s 诊所:如何安全高效地运行 Kubernetes

原文：https://www.fairwinds.com/blog/k8s-clinic-how-to-run-kubernetes-securely-and-efficiently

为什么组织选择 Kubernetes

随着容器的采用，软件打包越来越左移，这意味着(取决于您的组织)开发人员正在承担应用程序容器化的责任。开发人员也可能负责 Kubernetes 配置的某些部分。随着这一过程的左移，开发人员需要支持来为组织做出正确的决策，以便安全有效地运行 Kubernetes。

许多公司正在采用云原生技术来提高市场速度。对于寻求在当今市场竞争的企业来说，发布新功能并满足客户需求非常重要，而且这些需求越来越多地通过软件来满足。

主要挑战

尽管从云原生技术中获得了很多好处，但是迁移到容器和 Kubernetes 并不是没有潜在的挑战。根据云本地计算基金会(CNCF)最近的一项调查，在这种类型的转型中通常会出现三个关键挑战。

CNCF: What are your challenges in using/deploying containers?

来源: CNCF 调查 2020

并列第一，复杂性和迁移到云原生技术所涉及的文化变革。这些类型的变化通常意味着改变开发过程，并可能将一些责任转移给不同的团队，迫使工程师学习新的概念，并迫使运营工程师适应“一切如代码”的心态。

第三个挑战与云原生技术的安全性考虑有关。我们正在处理改变您对安全性的看法的新概念和技术考虑，特别是当您在云中运行容器和 Kubernetes 技术时，或者如果您在多云或混合云场景中使用它。所有这一切的复杂性导致安全团队后退一步，真正理解云原生技术带来的新威胁形势。

安全部门需要与开发人员和开发运维人员合作，因此他们不仅需要跟上新变化的步伐，还需要了解这些风险可能存在于何处。当涉及到实际的容器技术本身时，出现了新类型的问题，例如了解这些容器中有哪些已知的漏洞(常见漏洞和暴露(CVEs) ，以及了解 Kubernetes 可以被配置为不安全、不可靠或低效的方式。

新的决策点和复杂性

转向 Kubernetes 和 containers 引入了许多新的决策点；去年，一篇文章强调了 69%的 Kubernetes 事件实际上与错误配置有关。为了成功地向市场交付产品，您需要一个协作环境来快速解决配置错误的问题。记住:Kubernetes 中的一切都是配置驱动的，安全性是默认内置的 而不是 。

组织的复杂性是另一个起作用的重要因素。在这个过程中涉及到不同的角色，他们每个人都有不同的问题需要回答，所以让我们站在他们的角度想想:

开发者:有偿编写代码，构建新功能，将应用交付生产。他们需要对 Kubernetes 和 containers 有足够的了解，以便继续做好他们的工作，将应用程序发布给客户。
站点可靠性工程师(SREs): 需要确保应用程序的可靠性和稳定性。sre 还需要确保应用程序使用最佳实践进行配置，并启用运行状况探测和运行状况检查，以便应用程序能够在生产中可靠运行。
安全团队:需要知道组织是否正在运行易受攻击的容器版本，以及应用程序是否被配置为安全的。
工程副总裁: 需要安全可靠的基础设施来支持下一波增长。

在这些环境中，你需要建立流程并设置防护栏，以满足这些不同角色的需求。

安全性和效率的技术含义

对于所有这些团队来说，在他们寻求构建和向市场交付应用程序和服务时，配置是一个需要考虑的因素。对于转向容器和 Kubernetes 的组织来说，什么样的技术含义会影响安全性和效率？堆栈中有几个不同的层，您需要注意其中的错误配置。

容器:将应用程序与操作系统打包在一起的地方。注意被打包的已知漏洞，无论是在操作系统级别还是在被放入容器的应用程序内部。
部署配置:这可能是 Kubernetes YAML 或 Helm 图表。注意这一级的错误配置。确保正在设置 CPU 和内存设置，正在为应用程序设置活动和就绪探测，并且没有向这些部署添加不必要的安全权限。
Kubernetes 集群:可能被错误配置为在互联网上公开访问。确保你有基于角色的访问控制。还有许多附加组件需要保持最新，如入口和证书管理。

政策和治理如何有所帮助

您可以通过使用策略和治理来帮助防止常见的错误配置。实施策略来检查安全错误配置，例如底层 Kubernetes 集群和附加组件中的漏洞。不断扫描和监控基础设施以发现新的漏洞并根据需要修补，这一点很重要。策略和治理还可以通过确保资源使用效率来帮助您优化成本，例如，检查 CPU 和内存设置以确保您的应用程序拥有足够的计算资源，但不会消耗不必要的资源。

当你创建护栏来防止错误被推向生产时，你也可以在适当的时候向开发人员和做出配置决策的服务所有者提供反馈。您可以使用策略来创建护栏的一些方法示例包括:只允许来自可信存储库的映像，确保设置了 CPU 和内存请求，以及要求健康探测。有不同的方法来实现策略和治理并使您的策略坚持下去，您的选择可能取决于您的组织的规模、您的 Kubernetes 环境的成熟度等级以及其他考虑因素。无论您如何进行，您都需要跨团队和集群的可见性，以及有效和一致地管理策略的方法，以便安全和高效地运行 Kubernetes。

K8s 教程:使用 Policy Engine，Polaris 来自动修复

原文：https://www.fairwinds.com/blog/k8s-tutorial-policy-engine-polaris-to-automate-fixes

在之前的一篇博文中，我们向您展示了如何安装 policy engine，Polaris，以及如何使用仪表板、准入控制器和 CLI 工具审计您的 Kubernetes 工作负载。在本教程中，我们不仅仅看到 Kubernetes 的效率、可靠性和安全性问题，还将向您展示如何使用 Polaris 自动修复它发现的任何问题。

使用 Polaris CLI 工具更新您的基础设施代码

Polaris 不仅仅可以从命令行审计文件。使用 polaris fix 命令，它可以自动修改它发现的任何问题的 YAML 清单。例如，要修复部署目录中的任何问题，请运行:

polaris fix --files-path ./deploy/ --checks=all

Polaris 可能会在一些更改(例如，活性和就绪性探针)旁边留下注释，提示用户根据其应用的上下文将它们设置为更合适的内容。

并非所有问题都可以自动修复，目前只有原始 YAML 清单可以变异。舵图仍然需要手动更改(这方面的功能更新即将推出！).

变异 Webhook

默认情况下，Polaris 验证 webhook 将阻止或允许部署，但是您可以将 Polaris 配置为作为变异 webhook 运行，它会在发现问题时自动更改部署，而不是终止操作。

有关如何使用 Helm 安装验证 webhook 的说明，请参见 Polaris 文档。

要启用变异 webhook，您需要将 webhook.mutate 标志设置为 true。完整的命令如下:

helm upgrade --install polaris fairwinds-stable/polaris --namespace demo --create-namespace --set webhook.enable=true --set webhook.mutate=true --set dashboard.enable=false

默认情况下，北极星变异 webhook 将改变的唯一问题是 pullPolicyNotAlways 。如果您想激活其他突变，您可以通过 webhook.mutatingRules 标志来定义它们，或者您可以编辑您的 Polaris 配置的 mutatingRules 部分:

webhook:
  enableMutation: true
  mutatingRules:
  - cpuLimitsMissing
  - cpuRequestsMissing
  - dangerousCapabilities
  - deploymentMissingReplicas
  - hostIPCSet
  - hostNetworkSet
  - hostPIDSet
  - insecureCapabilities
  - livenessProbeMissing
  - memoryLimitsMissing
  - memoryRequestsMissing
  - notReadOnlyRootFilesystem
  - priorityClassNotSet
  - pullPolicyNotAlways

为了更深入地了解这一特性，请查看我们的博客文章 Kubernetes 与北极星的突变:它是如何工作的。

对于手动将工作负载部署到 Kubernetes 集群的人来说, polaris fix 命令和变异的 webhook 是一个很好的选择，但是如果你通过持续集成系统来验证你的代码和基础设施变化，你也可以使用 polaris。

将北极星添加到您的持续集成管道中

Polaris 可以在 GitLab CI、Jenkins、CircleCI 或 CodeShip 等持续集成系统中安装和运行。Polaris 将强制您的部署过程在您设置的任何条件下退出。例如，如果 Polaris 检测到您的基础架构代码 YAML 文件或掌舵图存在某些问题，任何危险级别的问题，或者如果总得分低于 75%，您可以设置退出代码。你可以配置 Polaris 只显示你失败的测试，并漂亮地打印出结果，以便人们更容易阅读。对于这组条件，CI 管道中的 Polaris 配置如下所示:

polaris audit --audit-path ./deploy/ \
  	--set-exit-code-on-danger \
  	--set-exit-code-below-score 75 \
	--only-show-failed-tests true \
	--format=pretty

这种方法不会自动修复 Polaris 发现的问题，但会显示 CI 系统日志中的错误。

也可以使用北极星文档中的说明在 GitHub 操作中设置北极星。

一次在多个集群中使用北极星

资源

用我们新的基准报告踢踢库伯内特 FOMO

原文：https://www.fairwinds.com/blog/kick-kubernetes-fomo-with-our-new-benchmark-report

本周，Fairwinds 发布了我们的 2021 年 Kubernetes 基准报告、博客文章和白皮书，告诉大家 Kubernetes 在安全性、可靠性和效率方面的标准。整个世界都转向了 Kubernetes，感觉和我交谈的每个人都害怕同样的事情——他们做错了。

以下是我经常听到的一些问题…

我需要什么插件来使这个产品准备好？
我如何分离工作负载和团队？
我应该在哪里用名称空间和集群画线？
合适的内部网络流量是什么样的？
Kubernetes 中我需要追求的基本安全态势是什么？高级安全态势如何？
如何配置我的工作负载，这样我就不会在不需要的东西上超支？

几乎所有这些问题都源于 Kubernetes 是一个新兴范例的事实。虽然 Kubernetes 可能已经赢得了容器编排之战，但它确实仍然是一个新的领域。尽管新软件不一定令人生畏，但这种转变肯定需要一段适应期。

我们的基准可以帮助您正确看待您的组织，大致了解您的组织与其他组织相比的情况。你知道你感受到了 FOMO，但你不确定你到底应该感受到 FOMO 的什么。我们的基准报告将帮助您确定自己的表现如何，以及可能的不足之处。

偏爱成功

也就是说，让我们谈谈我们报道中的偏见。我们的数据来自关于客户使用我们的 Fairwinds Insights 软件进行 Kubernetes 政策和治理的匿名统计。这些数据中固有的假设是，我们从其收集数据的公司已经自我认定为实际关心(至少足够花钱)安全、政策和治理。

有趣的是，这意味着我们的数据几乎肯定会偏向前 10%的公司，因为我们从中得出这些标准的企业已经是表现最好的了。毫无疑问，有相当多的公司还没有成熟到考虑 Kubernetes 容器安全的程度。大量使用 Kubernetes 的公司希望关注安全性或政策和治理，但只是没有时间或资源进行相应的投资。

寻找解决方案

我想说的是，看看你的情况。如果您想成为那些通过投资于基于 Kubernetes 的基础设施的安全性、效率和可靠性而获得成功的公司之一，请联系我们 Fairwinds。我们很乐意帮忙。我们的引导式免费试用可以让您强烈感受到您的组织所处的位置，并通过我们的控制面板获得整体健康评分。

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

今天看看 Fairwinds Insights 就知道你的公司在哪里了。也许你会对你的发现感到满意。但是如果你不是，我们有软件可以帮助你在这个 DevSecOps 的世界里达到 Kubernetes 和服务所有权的成熟。

kops 102 -在顺风航道上部署 Kubernetes 的内部观察

原文：https://www.fairwinds.com/blog/kops-an-inside-look-at-deploying-kubernetes-on-aws-the-fairwinds-way

在上一篇 kops 帖子中， kops 101 ，我介绍了 kops 是什么以及为什么它是专业级 Kubernetes 安装的正确选择。这一周，我将介绍如何用 kops 建立 Kubernetes。

我想分享一个在 AWS 上带有 kops 的 Fairwinds 式Kubernetes配置的例子。它包含了一个未记录的特性，DevOps 社区可能会觉得非常有用。在我们谈得太远之前，我还想介绍一下风向方式的想法。一个持续的试错过程使我们的团队能够以一种深思熟虑的、可重复的方式为创建基础设施设定最佳实践。这意味着我们有自己的观点并支持它。

就这样，让我们开始吧。

用 kops the Fairwinds 方法创建 Kubernetes 集群有两个步骤/组件:

使用terra form在亚马逊 Web 服务 (AWS)上创建虚拟私有云(VPC)。
让 kops 处理所有其他事情，这意味着在同一个 VPC 中添加额外的网络资源，启动组成集群的实例并验证它是否工作。

步骤 1:配置您的 VPC

我们使用 Terraform，一款由哈希公司开发的开源基础设施管理和供应工具，来创建我们的基本 VPC 和网络布局。我们总是使用经过测试和验证的相同初始结构。我们创建的 VPC 旨在托管 Kubernetes 和我们可能希望 Kubernetes 与之交互的任何其他基于云的资源，如托管数据库、缓存和消息队列。

简单介绍一下我们的 VPC 能为您带来什么:

多可用性区域(AZ)(通常为 3 个)
每个区域 4 组子网–1 组面向公众，1 组用于管理功能、私人工作和私人生产
每个 AZ 个 AWS 管理的 NAT 网关，私有子网中的资源可以通过该网关访问外部互联网

VPC 足够灵活，几乎可以应对我们范围内的任何情况，而且我们对其进行了精心设计，因此不会出现单点故障。

当然，你可以让 kops 为你创建 VPC。这是默认模式，公平地说，这绝对是一种有吸引力的工作方式，特别是因为我们已经设计了 kop 来自动对您的基础架构做出明智的选择。然而，在 Fairwinds ，我们认识到 Kubernetes 只是高度复杂的生态系统中的一环。因此，我们用 Terraform 搭建舞台，然后让 kops 将 Kubernetes 放在舞台上。

第二步:让 kops 发挥它的魔力

现在我们已经有了 VPC 和基本的网络资源，我们可以进入特定于 Kubernetes 的配置了。

要从我们的 Terraform VPC 设置进入工作集群，请使用以下四个命令:

kops create -f cluster_spec.yml 
kops create secret --name $CLUSTER_NAME sshpublickey admin -i $SSH_KEY_PATH 
kops update cluster $CLUSTER_NAME # Sanity check the output. Make sure that kops is 
only making the changes you expect. 
kops update cluster $CLUSTER_NAME --yes

这真的是我们部署集群所需的全部吗？是也不是。虽然这可能不是您部署第一个集群的方式，但是一旦您浏览了几次，并且了解了集群规范的工作原理，这将是定义和创建集群的一个很好的方式。

因此，让我们花点时间来讨论集群规范。集群规范是 kops 的一个基本概念。不是所有的 Kubernetes 集群都有一个集群规范，但是所有 kops 创建的集群都有。集群规范是 kops 创建的 yaml 文档，它用代码定义了 kops 部署和管理集群所需的一切。它存在于你的州立商店里，对于 AWS 来说是在 S3。如果您有一个集群规范，您就有了创建一个 Kubernetes 集群所必需的蓝图，这就是为什么我们只需要几个命令就可以创建一个 Kubernetes 集群(如上所示)。

如果您有一个使用 kops 构建的工作集群，并且您想要查看或保存集群规范，那么应该这样做:

kops get cluster ${CLUSTER_NAME} -o yaml --full > cluster.yml 
kops get ig nodes -o yaml > nodes.yml 
kops get ig masters -o yaml > master.yml 
… 
Merge the .yml files and put “---” between them into one large cluster_spec.yml See 
cluster_spec-example.yml

与 kop 互动的方式有很多种，但这里我要强调 kop 一个相对不为人知的特性——通过 kops create -f直接创建你的集群。此功能旨在镜像 kubectl create -f，用于创建和配置所有类型的 Kubernetes 资源。在这里，kops 一次性获取整个集群的规范，推断出任何未指定的值，然后创建您的集群。如果您正在编写集群部署的脚本或模板，这将非常有用(参见 cluster_spec-template.yml.j2，了解如何开始考虑开发模板的一些想法)。

用 kops 创建集群的更广为人知的方法是使用一个脚本来包装包含在 deploy.sh中的命令行标志。如果您运行 deploy.sh，它将创建一个基本的集群规范，然后您可以立即部署该规范，或者通过 kops edit cluster进行编辑以定制您的集群配置。最后可以用 kops update cluster部署。但是对于那些习惯于完全自动化的剧本、食谱或其他自动化的基础设施管理方法的人来说，我上面描述的确实是交互式的，并且花费了操作员大量的时间。如果您正在进行任何定制(我们做了很多)，它也引入了出错的机会。那就是模板化和 kops create -f 进来的地方。

对于开发一致的、可重复的基础设施，我的建议是最初手工交互地创建几次集群，并密切关注集群规范如何响应您的更改。到那时，您将有一个满足您需求的基本规范，并且您可以使用它作为构建更多集群的模板。

请注意，我们将集群规范配置为在安全的私有拓扑中启动 Kubernetes，这意味着主节点和节点位于私有子网中。kops 创建了与私有子网 1:1 的“公用”子网。实用程序子网托管 Kubernetes API 服务器的弹性负载平衡器(ELB)、Kubernetes 中启动的任何外部服务的 elb 以及 bastion 主机(如果使用的话)。

对于用 kops 创建的 RO 风格的 Kubernetes 集群，我们更喜欢让 kops 在我们现有的 VPC 中完全管理自己的配置(NAT 网关除外)。我们发现，让 kops 控制网络、安全组和实例，可以让 it 部门优化对基础架构的升级和其他更改的管理。对于 NAT 网关，我们指导 kop 使用我们最初作为 VPC 创建的一部分生成的网关，因为它们是可扩展的和冗余的——并且相当昂贵。即使我们在 VPC 中有多个集群，我们也可以继续获得私有拓扑的好处，而不会增加相关的网络成本。

如果 kops update cluster一切顺利，几分钟之内您就可以运行 kops validate cluster $CLUSTER_NAME ，并且知道您的集群已经准备就绪。

这种配置看起来很复杂。那么，我们为什么要这样工作呢？

简而言之，Terraform 非常擅长打基础。它塑造了景观，并为 Kubernetes 创造了一个休息的地方。反过来，kops 是专门为 Kubernetes 打造的。它是可预测的、快速的，可以处理所有的群集资源调配，并且比任何其他工具都更好地更新和管理群集。当你同时使用 Terraform 和 kops 时，你就拥有了完成手头任务的最佳工具。

以下是示例脚本、程序和规范的链接:【https://github.com/geojaz/ro-intro-to-kops-blog】T2

kops 101-Kubernetes 部署游戏改变者

原文：https://www.fairwinds.com/blog/kops-the-kubernetes-deployment-game-changer

Kubernetes 是一个用于部署、管理和编排容器化应用程序的开源平台。它最初是由 Google 开发的，Google 利用了超过 15 年在容器中大规模运行应用程序的经验。Kubernetes 随后被开源并于 2014 年移交给社区，在过去的两年半时间里，它已经成为分布式架构的首选解决方案之一。它还被每个人广泛采用，从从事小型项目的爱好者和开发人员到每周在数千个协调的虚拟机上运行数十亿个容器的最大企业安装。

Kubernetes 取得了巨大的成功，这在很大程度上是因为它相对容易使用，并能与复杂的分布式系统进行交互。最终用户通过命令行工具与 Kubernetes 进行交互。kubectl(发音为“kube-control”、“kube-C-T-L”，有时甚至是“kube-cuttle”)抽象了极其复杂的任务的实现，并允许管理员以简单明了的声明性语法工作。例如，您可以使用 kubectl 告诉集群需要给定服务的 30 个副本，并让集群计算出如何实现它。这是对以前存在的许多东西的巨大改进，并且 Kubernetes 生态系统继续以令人难以置信的速度扩张。迄今为止，主要项目已经有近 21k GitHub 明星和超过 1k 名贡献者。

这听起来很棒，对吧？让我们都做一些 Kubernetes！

但是作为一名专业的系统管理员，您如何着手准备和部署一个生产就绪、高度可用的 Kubernetes 集群呢？

现在，这个问题的答案是 Kubernetes 和开源家族的新成员: kops 。kops (kubernetes-ops)是从命令行部署 kubernetes 集群的一站式开源解决方案。kops 旨在使在 AWS 上安装安全、高可用的集群变得容易和自动化。(随着项目的发展，对其他云提供商的支持也在不断改进。)kops 目前专注于全周期供应——从联网和安全到在构成集群的实例上安装软件。

kops 与现有 Kubernetes 社区和软件集成的方式之一是，与 kops 的主要交互是通过一个相对容易使用的声明性语法命令行实用程序，这很像 kubectl。在基本层面上，kops 和 kubectl 的区别在于，kubectl 与部署在集群中的应用程序或服务进行交互，而 kops 一次只能与整个集群进行交互。您可以使用几个快速的声明性命令将节点数量扩展到 30 个，而不是像以前那样将应用程序部署扩展到 30 个副本。作为管理员，这意味着您不必负责单独调配所有额外的计算实例，也不必依赖 Chef 或 Ansible 等传统 DevOps 工具来配置它们。如果你在 kops 的范围内给它一项工作，它会完成它，并帮助你选择行业最佳实践。此外，使用 kops 创建和管理 Kubernetes 集群比第一代更通用的 DevOps 工具要快得多。我们说的是在 20 分钟内，在私有网络拓扑中，基本上任何规模的高可用性多主集群。只需要几个选择，kops 就能解决如何完成的细节问题。

从 2016 年 3 月开始，作为一个只有几个核心贡献者的小项目， kops 已经发展到 1100 多个 GitHub 明星和 110 多个贡献者。这是一个真正符合开源理念的社区项目，核心团队积极征求代码库新方向的想法，邀请社区帮助解决 bug 和问题，确保听到所有的声音。社区的热情和活力推动着该计划向前发展。

我是这样和 kops 扯上关系的。几个月来，我一直在 Kubernetes slack 频道(#kops)上撰写和评论问题，我脑海中有一个我们需要在 Fairwinds 上使用的功能。kops 的核心维护者之一，令人敬畏的【克里斯·诺瓦】，在一次早餐会后邀请我和她坐下来，我们花了一个小时研究这个特性的开端。在接下来的几个星期里，我们反复修改代码，她帮助我确保所有的基础都被覆盖了，最后才让这个特性被主代码库接受。现在，作为 kops 核心维护者，我指导项目的新贡献者，就像她指导我一样。我们是一个紧密团结的团队，我们正在努力做一些我们认为重要、有用和非常酷的事情。结果是快速增长和近乎实时的进步。

在 DevOps 合作伙伴中寻找什么

无论你计划使用、kops 还是其他一些工具的组合，选择一个在开源社区有活跃利益的合作伙伴。具体来说，选择一个在您的企业赖以成功的工具方面表现出专业知识的合作伙伴。

找到一个合作伙伴:

对软件的内部工作有真正的理解，对社区是可见的，是社区的一部分，是社区的投资者。
密切关注项目的进展，并以有意义的方式参与推动议程和对话，以便开发和实施支持您的业务需求并为您的业务创造价值的工具、功能和变更。
帮助您找到扩展现有技术的方法，以节省时间和金钱，并将其回馈给社区以促进未来的发展。

选择结合了对云基础架构的行业领先理解的 DevOps 合作伙伴。与其在外面看着，等着某个大公司来修复一个 bug 或者为你创建一个必备的特性，不如选择与一个处于行动中心的团队合作，帮助你从头开始构建那个特性。

下一个kops 102——如何部署 Kubernetes 顺风道！

Kubecost 替代方案:Kubernetes 通过 Fairwinds 进行成本分配和优化

原文：https://www.fairwinds.com/blog/kubecost-alternatives-kubernetes-cost-allocation-and-optimization-by-fairwinds

在今年的 KubeCon 上，有很多关于 Kubernetes 成本优化和分配的讨论；许多与会者都在寻找 Kubecost 的替代方案。本博客并不打算提供 Kubecost 的利弊，而是提供一些理由，说明组织为什么需要 Kubernetes 成本分配和优化解决方案，并提供一些关于 Fairwinds Insights 的信息，fair winds Insights 是一个提供工作负载成本分配和优化的平台，除此之外，它还提供 Kubernetes 的安全和护栏功能。

为什么要添加 Kubernetes 成本分配和优化工具

云原生工具提供了许多优势，如自动伸缩，但也让开发人员和开发者可以按照他们想要的方式进行配置。这意味着在许多情况下，Kubernetes 的限制和请求没有设置，CPU 和内存没有设置，云成本可能会飙升。结果是有许多未知因素的令人惊讶的云账单。随着组织寻求降低开支，这是一个需要关注的领域。

不幸的是，Kubernetes 平台可能成为云消费的黑洞。这就是像 Kubecost 和 Fairwinds 这样的供应商提供解决方案的原因。虽然绝对有一些跟踪云支出的优秀组织在云提供商(如 AWS、Azure、GCP、GKE、AKS 或 EKS)中处于较高水平，即像 CloudHealth 这样的公司，但大多数组织并不提供 Kubernetes 级别的详细信息。随着容器消耗量的增加，这是一个必需的解决方案。

Kubernetes 成本分配很难。Kubernetes 调度的动态特性意味着容器化工作负载的运行位置总是会发生变化。所有这些变化意味着在 Kubernetes 中很难按工作负载分解成本。需要适当的配置，这需要能够监控成本、提出优化建议、提供工作负载成本分配以及提供成本显示的解决方案。

Fairwinds Insights:另一种 Kubernetes 成本监控和管理解决方案

Fairwinds Insights 提供跨 Kubernetes 和 containers 的成本管理，为合适的应用资源提供建议。它提供了一个集中、一致和优化的 Kubernetes 成本视图。FinOps 和 DevOps 团队同样使用洞察来获得对许多人和工作负载的看法，以更好地调整减少支出的机会，或根据实际使用情况提供证据，说明为什么可能需要增加云消耗。

Fairwinds Insights Kubernetes 成本功能的核心功能包括:

工作负载成本分配 -使用实际云支出和工作负载使用情况来了解跨多个集群、聚合和自定义时间段发生的历史成本(长达 13 个月)。
Kubernetes 成本优化 -评估单个应用并寻找机会在不影响应用性能的情况下降低成本。
合理调整建议 -通过对资源请求和限制的监控和建议，最大限度地提高 Kubernetes 工作负载的计算和内存利用率。
Kubernetes 成本反馈 -向财务团队报告 Kubernetes 的使用成本，分配给开发人员，并跟踪一段时间内的节约情况。
多集群成本和使用情况 -获得跨云资源的集群容量和使用情况的明细。了解在闲置容量、共享资源与特定于应用的资源以及有效的节点扩展方面花费了多少。
云计费集成 -使用实际的 AWS 云账单，按工作负载、名称空间或标签计算 Kubernetes 成本。跨多个业务维度提供基于使用情况的准确成本数据。
服务质量控制 -协作调整应用规模，提供专门构建的建议，消除猜测，提高工作负载效率和性能。

Fairwinds Insights 可以像 Kubecost 一样免费试用。用户只需向我们的团队注册，添加代理，并在 Insights 仪表盘中查看建议。

注意:如果你是 CNCF 沙盒开源项目 KubeCost 或 OpenCost 的用户，并想尝试 Fairwinds Insights，你可以使用现有的 Prometheus 安装，或者选择安装 Fairwinds Insights 的预配置 Prometheus 包。取得联系。

Cost 和 Kubernetes 安全和护栏

KubeCon 的一个不足为奇之处是，Kubernetes 用户希望整合供应商，因为组织希望减少支出。随着经济衰退的逼近和云计费的增加，成本成为焦点也就不足为奇了。

Kubernetes 成本优化的核心是配置。这就是为什么该功能是 Fairwinds Insights 平台的一部分。Insights 扫描 Kubernetes 集群，以识别安全性、可靠性和成本效率方面的错误配置。它还实现了 Kubernetes guardrails(或 policy ),以便组织可以为开发人员构建安全、经济且合规的应用程序铺平道路。

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

在一个平台中，用户可以获得使 Kubernetes 与业务目标(即更快地交付应用、可靠地扩展、获得云成本报告等)和安全性保持一致所需的全部内容。开发人员可以使用安全网更智能地工作，而不必担心 Kubernetes 要求的所有安全性、合规性或成本配置。

Insights 针对 Kubernetes 的成本挑战提供了一个更全面的解决方案，不仅解决了一个痛点(如 Kubecost ),而且解决了三个痛点。DevOps 团队可以不再是 Kubernetes 的服务台，也不再花时间试图为财务团队破译云账单和定价。它为 DevOps 团队腾出了时间来做他们想做的创新平台工作——帮助公司留住他们需要的 Kubernetes 人才。

对于那些可能还没有准备好洞察的组织来说，一个开源工具【金凤花是可以尝试的。它有助于组织根据集群指标合理确定工作负载的规模。可以在 GitHub 或者文档上查看。

KubeCrash 回来了！KubeCon 底特律热身

原文：https://www.fairwinds.com/blog/kubecrash-is-back-the-kubecon-detroit-warm-up

我很高兴能成为今年第二届kube crash的一员，为 KubeCon Detroit 做准备。Fairwinds 与其他伟大的开源贡献者——Ambassador Labs、bubbly、Civo、蟑螂实验室和 jet stack——合作，为您带来了一个充满实用的云原生知识和新开发技能的虚拟学习活动。

这个虚拟的、免费的、100%专注于开源的活动将于 10 月 5 日和 6 日在欧洲和美洲友好时区举行。今天退房报名。

为什么要开源

DevOps 团队正在推动构建 Kubernetes 生产环境的技术选择。我们越来越多地看到工程师被免费的开源软件所吸引，以帮助增强平台和降低成本。在某些情况下，在采用企业版之前，开源是一个很好的切入点，而且比闭源解决方案更容易集成和支持。

开源对任何现代技术都至关重要。KubeCrash 旨在帮助工程团队开发所需的技能，以便在他们的生产环境中有效地利用这些技术。在这两个半天的知识分享和虚拟学习会议期间，开发人员、可靠性工程师、云安全专家和平台工程师将直接从一些最受欢迎的开源项目的维护者那里学习。

kube crash 计划

请做好准备，迎接一个由思想领袖和维护生态系统中最受欢迎的开源项目的团队直接提供的精彩内容和可行见解的日程安排。从谢丽尔·洪的主题演讲，到 CNCF 最终用户资源创建者的介绍，再到技术会议和研讨会，以及最终用户案例研究，总有令人惊叹的选择。

第一天:10 月 5 日星期三(欧洲和东美洲友好时区)

欧洲中部时间下午 3 点到 6 点|美国东部时间上午 9 点到 12 点|美国中部时间上午 8 点到 11 点

主题演讲 :即将发布！

灯光演讲:介绍 CNCF 云原生成熟度模型 由 Danielle Cook 主讲，CNCF Cartografos 集团联合主席

到底是谁的证书？如何使用证书管理器 建立 TLS 信任

直奔边缘 由 Civo 创始人迪内什·马杰雷卡和马克·Boost

专使——入场环节

实践研讨会:弗林、Linkerd 团队和使者入口维护人员与 Linkerd 一起观察服务网格

第二天:10 月 6 日星期四(美洲友好时区)

美国东部时间 12 点到下午 3 点|中部时间上午 11 点到下午 2 点|太平洋时间上午 9 点到下午 12 点

主题演讲:基础设施问题 苹果工程经理谢丽尔·洪

灯光对话:CNCF 云原生词汇:可信。简单。社区驱动的 云原生词汇表维护者 Catherine Paganini

Kubernetes Guardrails with Polaris作者 Andy Suderman Goldilocks 的创建者和维护者以及 GoNoGo 的创建者 Stevie Caldwell

终端用户故事

与普鲁米一起动手练习

查看节目页面了解更多详情。

10 月 5 日和 6 日加入我们

在 10 月 5 日和 6 日加入我们，参加一系列特别策划的会议，每个会议由一名项目维护人员主持，从涵盖现代云原生安全性的项目到改善开发人员体验。它将是现场的，互动的，有趣的。今日报名！

KubeCrash:云原生速成班

原文：https://www.fairwinds.com/blog/kubecrash

KubeCrash 是一个新的虚拟 KubeCon 同地活动，面向那些不能亲自参加 KubeCon 或处于“时区-左侧-后方”的人由五家使用 Kubernetes 开源工具的公司创建的 KubeCrash 提供了关于云原生技术的 KubeCon 级课程。没有供应商推介，只有令人敬畏的开源项目内容，如 Linkerd、cert-manager、CockroachDB、Pulumi 和 Fairwinds 的项目、北极星和金发女孩。

Kubernetes 是云托管应用程序开发的新标准，允许 DevOps 团队推动企业级云原生工具的技术选择。免费可用的开源解决方案通常是这些工具决策的主要来源。

KubeCrash 为开发者、可靠性工程师、云安全专员、平台工程师提供半天的知识分享和虚拟学习环境。在这一系列专题讲座和研讨会中，直接向一些最受欢迎的开源项目的维护者学习。

https://www.kubecrash.io/注册

期待什么

虚拟活动提供了一个充满精彩内容的时间表，这些内容来自维护一些云原生生态系统最受欢迎的开源项目的团队。该议程将涵盖以下方面的最新知识:实施可扩展的零信任、扫描工作负载以提高云原生安全性、使用服务网格确保跨多集群基础架构的高可用性，以及为多云部署提供“无服务器”服务。

日程安排

使用 cert-manager 实现 pod 内部通信的零信任身份——Jake Sanders，cert-manager 维护人员

现代云原生架构要求网络不可信，这就是内部工作负载快速推动 mTLS 和私有 PKI 使用的原因。Jetstack 的这个研讨会将演示如何使用 cert-manager 来发布、管理和轮换 mTLS 证书，允许用户在 Kubernetes pods 之间拥有经过严格验证的机器身份——所有这一切都不会让工作负载私钥离开节点内存！将此会话视为实现服务网格解决方案的前奏，使用 cert-manager 建立零信任环境(可能由信任域定义)，并加强点对点流量的安全性。

使用 Linkerd 的多集群故障转移—link erd 维护者 Eliza Weisman

跨集群故障转移是提高 Kubernetes 应用程序整体正常运行时间和可靠性的一个很好的方法。虽然整个集群的故障转移可以在全局入口层完成，但是单个服务的故障转移要稍微困难一些。在本专题讲座中，Linkerd 维护人员 Eliza Weisman 将介绍如何使用 CNCF 毕业的服务网格 Linkerd 来实现跨集群单个服务的流量故障转移。与会者将学习如何使用纯开源技术，以一种连贯和自动化的方式将服务网格指标、流量转移和跨集群通信结合起来，同时保留基本的安全保证，如相互 TLS。

使用 Polaris 和 Goldilocks 优化和保护 Kubernetes 工作负载— Rachel Sweeney、Fairwinds 和 Andy Suderman，Polaris 和 Goldilocks 维护人员

了解如何使用开源工具 Polaris 和 Goldilocks 扫描 Kubernetes 工作负载，以提高资源利用率和安全性。观看 Fairwinds 的 R&D 和技术总监 Andy Suderman 和 SRE 的 Rachel Sweeney 演示如何根据 Kubernetes 的安全性和效率最佳实践正确配置您的集群。

使用 Kubernetes 提供“无服务器”服务——丽莎-玛丽·南菲和吉姆·沃克，蟑螂实验室

在本次演讲中，蟑螂实验室团队成员将分享他们如何利用 Kubernetes 提供“无服务器”体验。无服务器承诺改变我们消费软件的方式。它使我们有可能只为我们使用的东西付费，并通过最大限度地减少资源消耗来帮助降低运营成本。无服务器架构需要对应用程序逻辑及其部署方式有独特的看法，这是逻辑和物理世界的结合。一种架构模式已经出现，在这种模式下，我们可以将短暂的计算与需要持久的服务分开来扩展。

多重云，单一部署:使用 Kubernetes 和 Pulumi 的云工程——亚伦·弗列尔和桂妮维亚·桑格，Pulumi

业务约束和客户请求通常要求团队在多个云提供商之间建立新的 Kubernetes 环境。当跨多个团队进行协调时，计算基础架构中日益增长的复杂性将为组织带来更高的运营成本。普鲁米工程师亚伦·弗列尔和桂妮维亚·桑格将通过使用普鲁米自动化 API 构建一个 CLI 来演示如何建立 Kubernetes 集群、部署应用程序和自动化运营任务。这些工具让每个工程师——从应用程序开发人员到站点可靠性工程师——都能成为云工程师。

5 月 17 日加入我们

任何人都可以加入这个 KubeCon，无论你是留在美洲还是熬夜开会。加入我们，时间为 5 月 17 日星期二，太平洋标准时间上午 9 点/中部标准时间上午 10 点/东部时间下午 12 点。了解由项目维护者领导的开源项目的更多信息，从涵盖现代云原生安全性的项目到改善开发人员体验的项目。今天注册！

Kubernetes 1.18.0 出来了:现在怎么办？

原文：https://www.fairwinds.com/blog/kubernetes-1.18.0-is-out-now-what

最新的 Kubernetes 版本现已上市。你可以在变更日志中找到更新和错误修复的完整列表。发布的主要主题包括deprecations、metrics、node和kubectl。如果你是 Kubernetes 的新手或者正在考虑升级，你可能会想，现在该怎么办？

我们 Fairwinds 团队的存在是为了帮助工程师、开发人员和基础设施团队在 Kubernetes 上取得成功。在这种情况下，大多数时候我们建议客户在最新版本之后运行 N-1 或 N-2。为什么？有几个原因。

你必须在长期稳定性和尖端技术之间取得平衡。采用 Kubernetes 可以让您大规模受益于容器技术。随着您部署越来越多的容器，对 Kubernetes 的需求也会增加。但是对于 Kubernetes 的每个新版本，您都需要确保对服务或操作者的任何升级在您的生产环境中是兼容的和安全的。这仅仅需要发布、测试和修补最新版本。

接下来，如果使用托管的 Kubernetes 服务(GKE、EKS、阿拉斯加)，他们有时会落后，在某些情况下，几周到几个月都不会推出最新版本。他们需要相同的时间来发布、测试和修补。

最后，构建在 Kubernetes 上的云原生应用可能需要更改以支持最新版本。你需要考虑需要做什么改变，以及需要多长时间。您还需要保护您所依赖的关键功能。跳到最新版本可能意味着您会失去一些功能。

先审核，后实施

我们的 Kubernetes 升级到最新版本的最佳实践是给发布时间进行测试(当然，除非你有一个超级酷的创新实验室，在这种情况下，测试它，修复并与开源社区共享！).

我们在客户的整个 Kubernetes 之旅中支持他们的一种方式是，我们的 R&D 团队在向客户的生产环境推出新版本之前审查新版本。这使我们能够了解每个版本的优缺点，以便根据客户的应用、服务和基础设施，在正确的时间进行升级。这也意味着依赖特定功能的公司不会升级，如果该功能不再正常工作，他们会感到恐慌。

我们不害怕升级，相反，我们准备好并热爱升级。当升级的时候，确保你已经检查了版本。如果您没有时间，我们的 SRE 团队随时可以提供帮助。

Kubernetes: 10 个技术改造步骤

原文：https://www.fairwinds.com/blog/kubernetes-10-technical-transformation-steps

Fairwinds 发布了 Kubernetes 成熟度模型工具，帮助人们通过 Kubernetes 自我识别他们的成熟度，了解他们环境中的差距，并深入了解如何增强和改善他们的 Kubernetes 堆栈。

Kubernetes 成熟度模型的第二阶段侧重于转型。在这一阶段，您的重点是将工作负载转移到 Kubernetes 中，包括将您的应用程序容器化(如果它们还没有在容器中运行)。要成功完成这一技术转型，您需要采取 10 个主要步骤。这代表了对每个步骤的高度概括，请记住，您应该准备在此过程的每个步骤上花费大量时间。

深入研究和项目计划 -无论您是在本地、数据中心还是已经迁移到云，您的第一步都是深入研究您的现有堆栈。您需要调查堆栈的所有方面，从底层网络、基础架构、配置、机密管理到您如何部署应用程序及其依赖关系。当您迁移到 Kubernetes 时，您需要确定您的技术需求。这一步可以帮助你避免错过一个重要的需求。基于这种深入研究，您可以制定一个项目计划，作为您的迁移路线图。
应用程序容器化——你的应用程序可能已经被容器化了，在这种情况下，你可以进入第三步。如果不是，你需要根据十二因素应用程序方法来分解你的应用程序。这是至关重要的，因为您将需要您的应用程序经历破坏(您的容器可能随时被杀死)。您需要能够干净地备份您的应用程序和容器。在这一步中，我们建议您从构建工件中提取您的秘密和配置。Kubernetes 是短暂的，因此通过这样做，您将维护您的标准和安全性，并在容器运行时简单地注入秘密和配置。
构建云基础设施 -您需要确定您的云提供商:AWS、GCP、Azure 或托管的 Kubernetes 服务，如 EKS、GKS 或 AKS。如果您选择了托管 Kubernetes 服务，那么在构建 Kubernetes 基础设施时，您的工作量会更少。您需要设置底层的云配置、VPC、安全组、认证和授权等。作为这一步的一部分。
构建 Kubernetes 基础设施 -在第四步中，需要考虑设计因素，以避免做出可能需要耗时的集群重建或网络和成本影响的选择。一些考虑事项包括:在什么区域应该有多少个集群，有多少个可用性区域(az)？需要多少独立的环境、集群和名称空间？服务应该如何相互通信或发现？安全性是在 VPC、集群还是单元级别？你的重点应该是重复性。您将希望利用基础设施即代码(IaC ),以便能够以一种重复的方式构建您的集群。在这一步中，使用第一步中的深入研究/项目计划时，请注意您的配置选项，以确保您不会错过应用程序要求。
写 YAML 或舵图——在 Fairwinds，我们称这一步应用为 Kubernating。这是您定义 Kubernetes 资源的地方，以便将它们加入您的集群。在这里，您可以编写 Kubernetes 资源 YAML 文件，但是现在大多数都使用舵图来将应用程序部署到 Kubernetes 中。你将写 YAML 或舵图表专门为您的集装箱图像，模板配置图，秘密或任何特殊的应用要求。
探测外部云依赖关系 -您的应用程序将具有外部依赖关系，如其密钥库、库、数据库或其他资产。Kubernetes 并不是这些依赖者生活的好地方。您将希望在 Kubernetes 之外管理您的有状态依赖。例如，你可以在 Amazon RDS 这样的工具中建立数据库，然后将其导入 Kubernetes。然后，您的应用程序可以在 Kubernetes 的 pod 中运行，并与这些依赖项对话。
定义 Git 工作流程——Kubernetes 的一个主要优势是能够以可重复的方式部署代码，无需人工干预。您通常通过 Git 将代码提交给源代码，Git 将启动事件并与将这些更改转移到非生产集群的分支合并。然后，您将测试和 QA 您的代码，并将其合并到主文件中。这将把您的代码部署到登台或生产环境中。在这个阶段，你只是简单地定义你的 Git 工作流看起来像什么，也就是说，当开发者推送代码时，Kubernetes 中会发生什么？
建立你的 CI/CD 管道 -一旦你定义了你的 Git 工作流程，你将使用像 Jenkins 或 CircleCI 这样的自动化工具建立你的 CI/CD 平台。这将把您定义的工作流变成一个实际的构建管道。
非生产测试 -在您完成整体应用或微服务架构的步骤 1-8 后，您将部署到非生产环境。在这里，您将使用应用程序来确保它运行，有足够的资源和限制，测试您的秘密是否正确进入，人们是否可以访问该应用程序。你将测试如果你杀死你的豆荚会发生什么。实际上，在进入生产阶段之前，你会踢踢轮胎。如果你正在运行一个 monolith 应用程序，你会更快地通过这个阶段。如果您正在部署微服务应用程序架构，您将为每个服务完成步骤 1-8，并部署到非生产环境。一旦所有的服务都准备好了，您就可以看到它们是如何协同工作的，以确保一旦投入生产，您的应用程序就能正常工作。
生产推广 -最后，一旦您在非生产环境中彻底测试了您的应用程序，并对此感到满意，只要您的生产环境与您的试运行环境相同，您就可以部署应用程序并向其发送流量。在这里，您只需更改您的负载平衡器或 DNS。使用 DNS，如果需要，您可以回切。

在第二阶段，您还将着眼于清理技术债务，围绕工具制定决策，调查生产率的收益与损失，并开始着眼于灵活性与控制。

进一步了解 Kubernetes 成熟度模型的转型阶段，并研究该模型的所有阶段。

关于 Kubernetes 基础知识、工具和更多内容的问答

原文：https://www.fairwinds.com/blog/kubernetes-basics-tooling-and-more

最近我回答了 Kubernetes 社区提交的问题。这里是围绕工具、Kubernetes 基础知识和托管容器服务讨论的问题和答案的快速总结。

Kubernetes 工装

头盔有什么好处，是否需要？

Helm 是 CNCF 的一个孵化器项目，由 Helm 社区维护。Helm Charts 允许您定义、安装和升级 Kubernetes 应用程序。11 月发布的最新版本 Helm 3.0.0 在许多方面都有所改进。虽然不一定需要，但它很受欢迎，因为它使管理 Kubernetes 上的应用程序变得更加容易。

没有 Helm，您将需要模板化您的清单，并跟踪从一个部署到另一个部署的变化。使用 Helm，您可以创建一个图表，然后释放该图表。Helm 会跟踪每个版本的变化。当您单独使用 Helm 进行部署时，如果部署出错，Helm 会提供回滚命令，以便您可以快速返回到工作版本。

Helm 的部分好处是能够使用 nginx-ingress、cert-manager、external-dns 等社区图表。如果您创建了一个图表，您可以与全世界共享它。

除了 Jenkins Blue Ocean 之外，使用 ArgoCD 的人还可以通过哪些方式实施“部署到阶段- >测试- >部署到生产”管道？

CI/CD 遵循类似的过程，与您使用的工具无关。您需要建立实现管道，并需要在 Jenkins vs. GitLab vs. CircleCI 之间做出决定。我们使用 rok8s-scripts ，这是一个开源框架，用于使用 Docker 和 Kubernetes 构建 GitOps 工作流。通过将 rok8s 脚本添加到您的 CI/CD 管道中，您可以使用 Kubernetes 的最佳实践来构建、推送和部署您的应用程序。

是否推荐 Terraform 降低成本，加快开发速度？

当然，Terraform 允许团队像对待代码一样对待他们的基础设施，从而加快了开发速度。Terraform 具有声明性和可读性，降低了准入门槛。它与云无关，支持几十种不同的 API。这允许团队根据他们的应用混合和匹配你的开发。

Kubernetes 基础知识

为什么是库柏人？

虽然我们可能会在这个话题上花上几个小时，但这里有一些主要的好处:

没有供应商锁定
可再现性——您可以将一个应用程序部署到一个经过认证的 Kubernetes 集群，然后将其部署到任何 K8S 集群
这个社区非常庞大，而且还在增长。去年，我们看到了很多成熟和支持。
与自己构建框架相比，它为滚动发布和更新提供了一个通用框架

为了开发目的在本地运行 Kubernetes 有什么好处？

有了本地机器上的 Kubernetes，你可以 a)免费运行它，b)快速测试变化。无论您在本地机器上做什么，您都能够跨集群进行复制。

我的开发人员需要了解 Kubernetes 吗？

虽然理解基础知识很重要，但是如果你在管道中保留尽可能多的跑腿工作，那么你的开发人员将只需要知道基本的kubectl 命令。你维护管道，开发者发布代码。

Kubernetes 对我团队的应用来说太复杂了吗？

像任何新技术一样，Kubernetes 在你第一次看到它时是复杂的。对于组织来说，这可能是一个重大的范式转变。然而，一旦部署和监控流程到位，好处是显而易见的。虽然肯定有一个学习曲线，但克服这个曲线的最好方法是分批使用 Kubernetes。首先建立一个集群，然后部署一个小型应用程序，然后开始构建自动化。你也可以与 Kubernetes 咨询服务公司合作，让你的团队跟上进度。

我想了解 Kubernetes，从哪里开始？

首先，确保您了解如何构建和运行 Docker 容器。一旦你熟悉了，就从 Kubernetes 文档开始。这是一个从零到应用部署的好方法。此外，如果你关心 Kubernetes 的来龙去脉，读一读凯尔西·海塔尔的《艰难的 Kubernetes》。

Kubernetes 和托管集装箱服务

【Kubernetes、微服务和亚马逊 EKS 是什么关系？

微服务在 Kubernetes 内部运行(尽管 Kubernetes 并不专门用于微服务)。Kubernetes 几乎可以在任何地方运行。亚马逊 EKS 是一个托管的 Kubernetes 服务(以及 GKE 和 AKS)。EKS 在创建基本集群方面做得很好。EKS 的好处是亚马逊管理 Kubernetes 控制平面，因此运营商只需担心 EC2 计算实例。为了投入生产，您仍然需要单独管理集群附加组件和监控，不考虑 Kubenetes 托管提供商。

我目前正在 AWS ECS 上运行我的应用程序。采用 Kubernetes 的论据是什么？

如果您正在使用 ECS，并且您的应用程序没有任何问题，请不要移动。但是，如果你在 Kubernetes 中看到一个用 ECS 做不到的功能，那就开始评估吧。

采用 Kubernetes 有两个主要的理由，适用于任何容器服务。首先，如果您希望更好地管理您的服务，其次，如果您希望通过(更)自由地移动您的应用程序来避免供应商(ECS/AWS)锁定。

此外，采用 Kubernetes 的一个主要好处是社区。Kubernetes 在每个服务提供商或本地运行。有了 ECS，你只能在亚马逊上运行你的应用。你没有得到社区清单，舵轮图，K8S 自动化等的好处。

关于 EKS 的 Kubernetes，我需要了解什么？

EKS 抽象了 Kubernetes API 和控制平面，因此运营商不需要太担心维护集群正常运行时间。然而，有一些小的权衡。EKS 不遵循官方的 Kubernetes 发布周期，所以你通常会比最新版本落后几个版本。您也将无法配置控制平面(打开/关闭 Kubernetes API 特性)。所有 Kubernetes 服务提供商(EKS、GKE、AKS 等)都是如此。EKS 非常擅长处理基本的集群部署，但是当您转向生产时，您将不得不管理 Kubernetes 附加组件，如监控、日志记录和入口控制器。这是费尔温斯的面包和黄油。我们帮助 EKS 用户管理他们的基础设施，这样他们就可以专注于运行他们的应用程序。

你可以听我们接下来的问答环节。我们涵盖更多问题，包括:

如果部署在 Kubernetes 上，解决方案是否符合 HIPAA？
Kubernetes 没有解决哪些问题？
您如何从容器中收集指标(应用程序和操作系统)？
您如何处理非生产集群/环境？

Kubernetes 基础教程:确保容器不以 Root 用户身份运行

原文：https://www.fairwinds.com/blog/kubernetes-basics-tutorial-ensure-containers-do-not-run-as-root

容器是一个软件单元，它将代码及其所有依赖项集合在一起，使得在不同的计算环境中快速可靠地运行应用程序成为可能。Docker 容器是独立的轻量级软件包，包含运行应用程序所需的一切，包括代码、系统工具、系统库、运行时和设置。容器映像在运行时成为容器，容器化的软件在任何基础设施中都以同样的方式运行。它们被称为容器，因为它们包含——它们将软件与环境隔离，并且它们被设计成统一运行。当然，Kubernetes 是一个开源的容器编排系统。它自动化了软件部署、扩展和管理。Kubernetes 使用 pod 作为最小的可部署单元，但是每个 pod 必须包含一个或多个容器。换句话说，没有容器你就不能真正拥有 Kubernetes。

*这就是为什么理解容器安全性以及容器的权限如何影响 Kubernetes 工作负载如此重要。美国国家安全局的 Kubernetes 强化指南特别建议组织使用已经构建的容器作为非根用户运行应用程序。通常(默认情况下)，许多容器服务作为特权根用户运行，即使这些应用程序不需要特权执行。当您努力强化 Kube 环境时，您需要花一些时间调查哪些容器以 root 身份运行，然后进行更改以防止 root 执行，这样您就可以限制容器受损的影响。

检测允许作为根运行的容器

北极星是一个验证 Kubernetes 配置的开源项目。它包含一个内置检查，专门用于检测允许以 root 用户身份运行的容器。Polaris 内置于fair winds Insights(如果您尚未使用 Insights，则有一个免费层可用于多达 20 个节点、两个集群和一个 repo 的环境)，这使得 Insights 用户可以确切地看到集群中的哪些工作负载有权以 root 用户身份运行。您也可以在没有洞察力的情况下使用 Polaris，它将帮助您确保您的容器以最小特权运行。Polaris 策略可以帮助您避免权限提升，并确保您尽可能使用只读文件系统。Insights 允许您运行相同的策略来查找允许在 CI/CD 管道中作为 root 运行的容器；这有助于确保基础设施代码的变化不会引入能够以 root 用户身份运行的新资源。

见解行动项目

Insights 从安装的所有报告中收集数据，并将它们一起显示在仪表板中。如果你查看名为 should not be allowed to run as root 的动作项，你可以在截图中看到这是一个安全问题，严重性很高，北极星检测到了该问题。

Insights Action Items showing that containers should not be running as root

在操作项中，Insights 包括关于 Kubernetes 对象类型、名称空间和 Kubernetes 对象名称的信息。您也可以点击标题来查看这些信息。现在，您可以轻松地确定需要更改的资源。Insights 还显示一个描述部分，其中包括对行动项目的简短说明。

补救问题

“补救”部分提供了可用于补救措施项的步骤。对于此操作项，补救步骤要求您设置 security context . runasnonroot = true，并提供了类似的示例。

要添加安全上下文参数，通常需要转到资源定义的源。这可能是存储库中的 Helm 值文件或平面清单文件，具体取决于您在环境中的部署方式。

Remediation step showing you need to set securityContext.runAsNonRoot=true

在穿越视频中，我在本地机器上编辑了一个 pod 定义文件 pod with nonroot.yaml 文件。如修正步骤所示，您可以在 pod 或容器级别添加安全上下文。最好在 pod 级别添加这个安全上下文，因为它将是所有容器的默认上下文。如果您有令人信服的理由不在 pod 级别设置它，您将需要为 pod 中的每个容器设置它。

那么，如果您试图运行一个定义了这个安全上下文键的 pod，会发生什么呢？在视频中，我做了一个 k apply -f pod-with-nonroot.yaml 来部署吊舱。(在我的系统上，我有一个别名为 K 的 kube control。)当我按回车键时，你可以看到它说 pod 已经被创建了。但如果看 pod，状态说， create container config error 。这意味着 pod 实际上没有运行。你可以通过做一个 k describe po pod-run-as-non-root 来找出原因。

在显示的事件中，您可以看到一条消息，上面写着， Error: container has runAsNonRoot and image will run as root 。由于该安全上下文设置，API 服务器将不再启动此 pod。这很好——您没有运行一个过度许可的容器。但是这很糟糕，因为现在你的容器根本不运行了。

你如何修理集装箱？

现在您有了一个不能在集群中运行的容器，您需要知道如何修复它。在 Docker 文件中，您可能希望创建自己的用户和/或组，并在运行入口点或命令参数之前切换到该实体。这将使容器按照 docker 文件中指定的用户运行。

或者，您可以在容器规范中使用 RunAsUser 指令。该键的值必须是用户 ID，并且用户 ID 还必须是容器中存在的用户。请记住，当您以非 Root 用户身份运行您的容器时，您将希望确保您创建的用户拥有在您的容器内运行流程的正确权限。

不管在哪里定义替代非根用户，建议仍然将安全上下文设置为 RunasNonRoot 以增加容器的安全性。

防御以根用户身份运行的工作负载

一旦您更新了您的 pod 和 containers，以确保它们不再能够以 root 身份跨您的工作负载运行，请考虑在 Insights 许可控制器中打开 Polaris。这为在 Kubernetes 环境中以根用户身份运行的工作负载提供了最强有力的防御，能够从一开始就阻止这些工作负载进入您的集群。对于真正需要 root 访问权限的工作负载(不应该有很多)，您可以配置 Insights 来允许特定的豁免。为此使用一个允许列表，并在默认情况下拒绝以 root 用户身份运行，这将有助于确保您的容器尽可能安全地运行。*

Kubernetes 基础教程:如何整合吉拉和费尔温德见解

原文：https://www.fairwinds.com/blog/kubernetes-basics-tutorial-how-to-integrate-jira-and-fairwinds-insights

吉拉是 Atlassian 的问题和项目跟踪解决方案。许多组织使用作为跨团队协作的方式，帮助他们规划项目、分配任务、跟踪进度、报告状态和管理工作——无论你的组织是初创公司还是企业。吉拉是来自 Atlassian 的解决方案，因此它已经与他们的其他解决方案无缝集成，如 Confluence 和 Trello。它通常用于工作管理、It 服务管理以及敏捷和开发运维。因为它已经被敏捷团队用于 bug 跟踪和软件开发，所以使用fair winds Insights来跟踪和分配您在 Kubernetes 环境中发现的问题是很有帮助的。

fair winds Insights 中的行动项目

一旦您安装了洞察代理并从您的审计中获得结果，您可能会看到很多行动项目出现。当你开始的时候，你会希望看到什么样的项目正在出现，并决定你要把精力集中在哪里。通常，团队会查看工作负载配置操作项，以查看是否有需要设置的基本配置设置，包括资源限制和活跃度探测器。Insights 还将识别容器漏洞，这有助于您确定优先修补哪些漏洞，以提高您的容器安全性。成本效率是 Kubernetes 面临的另一个挑战，因为很难发现过度配置或配置不足的工作负载，因此 Insights 将在成本效率方面需要改进的领域也作为行动项目。Insights 平台在一个易于阅读的仪表板中显示行动项目，因此您可以轻松查看行动项目的严重性、主要问题、主要命名空间和主要工作负载。

image of Action Items in Fairwinds Insights

为什么要将吉拉与 Fairwinds Insights 整合在一起？

随着您更多地运行 Insights 并提高开发速度，您将发现越来越多的行动项目。虽然 Insights 可以帮助您将这些问题从低到中到高到关键进行分类，并确定首要问题，但手动将行动项目分配给各个利益相关方并包含快速解决问题所需的信息仍然非常耗时。在 Insights 和吉拉中分别跟踪所有这些项目很快会变得很麻烦，您可能会在不同的团队中失去对优先级和严重性的跟踪。在吉拉和 Fairwinds Insights 之间建立集成可以为您的开发团队和平台工程师实现两者之间的无缝连接，从而快速解决这些问题。

如何整合吉拉和 Fairwinds 的见解

集成很简单。首先，您需要创建一个帐户来使用。我们建议您创建一个“机器人帐户”来连接到您的 Insights 组织。授予该用户在您的所有吉拉项目上创建票据的权限。这样，关联帐户将显示为通过 Insights 创建的任何票证的创建者。

接下来，只需登录您的 Fairwinds Insights 帐户(如果您尚未使用 Insights，则有一个免费层可用于最多 20 个节点、两个集群和一个回购的环境)并导航至左侧导航中的设置。点击顶部导航的集成，您可以看到您可以添加的集成的所有不同选项。

您将在可用集成列表中看到吉拉。点击 添加积分 。这将提示您在 Atlassian 中授权应用程序。完成授权后，返回到集成页面并重新加载它。您可以看到现在已经安装了吉拉集成。

image of installed Jira integration

就这么简单！

为洞察创造吉拉门票

快速手动创建票证的一种方法是，单击操作项，单击您要通过吉拉分配的操作项，导航到附加操作菜单，然后单击创建票证。接下来，您可以选择一个项目，然后在屏幕上单击“创建票据”。现在，您已经在吉拉为该票证创建了一个行动项。您也可以使用自动化规则为行动项自动创建记号。您只能为每个行动项创建一个票证，但是如果您设置了集成，您可以使用CreateTicket函数从任何行动项创建吉拉、GitHub 或 Azure DevOps 问题。该函数有三个参数:字符串、项目和标签。如果与吉拉车票相关联的动作项被标记为Resolved 或Fixed，吉拉车票将自动关闭。

如果您想了解更多关于这个集成的信息，请查看 Insights 文档，特别是在集成下。Fairwinds Insights 还集成了您的团队已经熟悉的其他工具和开源解决方案，包括 Slack、PagerDuty、Travis CI、CircleCI、Jenkins、Datadog、Styra 等等。立即开始洞察为您的 Kubernetes 环境带来秩序和自动化。

Kubernetes 基础教程:为什么&如何将图像拉取策略设置为“总是”

原文：https://www.fairwinds.com/blog/kubernetes-basics-tutorial-how-to-set-image-pull-policy-to-always

Kubernetes 的入门似乎有点让人不知所措，因为虽然它提供了大量的灵活性和可伸缩性，但这些好处也伴随着复杂性。从一些基本的开始 Kubernetes 教程可以帮助确保你不犯一些最常见的错误。我们在 Fairwinds 遵循的 Kubernetes 最佳实践之一是将 imagePullPolicy 设置为“始终”

为什么您需要确保您的 imagePullPolicy 设置为“始终”

使用图像的缓存版本似乎更快更容易。不检查更新版本可以节省时间，并且您可能认为坚持以前的工作方式没有风险。毕竟，图像需要多久更新一次？比你想象的更频繁。漏洞每天都有介绍、发现、披露。您正在使用的图像的缓存版本可能会过期几天、几周甚至几个月。

当您依赖于文档或图像的缓存版本时，这些旧版本会在您的环境中引入安全漏洞，因为 Kubernetes 会自动尝试使用图像的缓存版本，而不验证它来自哪里或是否需要更新。这些漏洞可能来自不安全的库或其他已导入容器映像的依赖项。这些漏洞可能会对您环境的其余部分构成风险。

Kubernetes kube let 命令

Kubelet 是一个在 Kubernetes 集群的每个节点上运行的进程。它根据指示在节点上创建、销毁和更新 pod 及其容器。kubelet 管理由 Kubernetes 创建的容器，并遵循一组 PodSpecs，这是一个描述 pod 的 YAML 或 JSON 对象。基本上，kubelet 确保 PodSpecs 中描述的容器运行正常。当 kubelet 需要创建一个新的容器时，它会引用 PodSpec 来决定如何做。

立方图像提取政策选项

Kubernetes 有三个 imagePullPolicy 选项:

当 imagePullPolicy 设置为 Always 时，Kubernetes 总是从存储库中提取图像
当 imagePullPolicy 设置为 IfNotPresent 时，Kubernetes 仅在图像不存在于节点上时提取图像，但它将运行您放置在节点上的任何图像
当 imagePullPolicy 设置为 Never 时，Kubernetes 不拉图像；但是，如果图像存在于本地，kubelet 将尝试启动容器

对于 Kubernetes 来说，策略选项都是确定您是否想要拉一个策略的有效方法。如果您将 imagePullPolicy 设置为“Always ”,并且 kubelet 在本地缓存了一个具有相同摘要的容器映像，那么它将使用缓存的映像创建一个新的容器。否则，kubelet 下载带有已解析摘要的图像，并使用该图像启动容器。请注意，将 imagePullPolicy 设置为“Always”不会绕过本地容器缓存机制。它只是验证缓存中的图像是否与上游源匹配。这意味着这种配置几乎没有缺点。

如果您试图找出您的集群中正在运行哪些容器以及每个容器正在运行哪些版本， Nova 是一个开源工具，它将向您显示当前安装的版本，无论是旧版本、最新的主版本、最新的次版本还是最新的补丁版本。

了解如何检查 imagePullPolicy 设置的容器

您可能想知道如何辨别您的 imagePullPolicy 设置。

要检查容器的 imagePullPolicy 设置，可以使用 Docker 命令行； run the command docker inspect [container-name]`` ，显示您的集装箱配置
在配置中，您可以看到“ImagePullPolicy”设置，它显示了容器的策略
如果你想改变一个容器的镜像拉取策略，你可以使用 docker run 命令，这允许你在启动容器时设置一个特定的策略

如何将 imagePullPolicy 设置为“始终”

如果您不想检查每个容器的 imagePullPolicy 设置，可以使用 Kubernetes 治理软件，如fair winds Insights来自动检查策略。因为这是一个 Kubernetes 最佳实践，所以它已经内置到见解中，便于您查看。Fairwinds Insights 会在未指定该标签或未将其设置为“Always”时触发警告，以便您可以轻松修复清单。您可以在 Action Items 下的 Insights 中找到有关 imagePullPolicy 设置为 always 的更多信息。

修复 imagePullPolicy 的业务优势

如果您已经阅读了本文，并且看到了能够跨多个集群和团队检查 imagePullPolicy 的技术价值，那么也请考虑一下业务优势。团队需要确保安全。确保您使用的映像没有漏洞，有助于防范不安全和不可靠的应用程序。

浏览快速教程如何使用 Fairwinds Insights 将 imagePullPolicy 设置为“始终”。

Kubernetes 高效利用资源的最佳实践

原文：https://www.fairwinds.com/blog/kubernetes-best-practice-efficient-resource-utilization

我们都知道我们需要有效地管理 Kubernetes。这类似于我们都知道我们需要更高效地驾驶汽车。但是我们不能仅仅通过检查燃油表来做到这一点，我们需要改变我们的驾驶习惯。Kubernetes 也是如此。我们不能简单地监控资源利用率，我们必须改变工作负载的配置方式以提高效率。

Kubernetes 最佳实践:效率最大化

Kubernetes 的资源限制和请求的概念允许有效地利用资源，如果使用得当的话。但是，在为工作负载配置资源限制和请求时，可能很难知道使用什么值。在这篇博文中，我们将向您展示如何使用 Fairwinds 的开源工具 Goldilocks 轻松找到这些值。

设定 Kubernetes 限制并请求正确的方式

对应用程序设置太低的请求和限制会导致问题。例如，如果你的内存限制太低，Kubernetes 一定会因为你违反了它的限制而杀死你的应用程序。

同时，将请求和限制设置得太高会导致资源过度分配。你浪费了资源，最终导致更高的账单。

因为很难设定这些设置，一些团队从来没有设定过要求或限制，而另一些团队在初始测试时将它们设定得太高，然后就永远不会正确。

那么，您如何知道 Kubernetes 集群的适当限制和要求是什么呢？传统上，这需要大量的试验和错误。然而，为了加速这一过程，Fairwinds 开发了金发姑娘。

金发女孩:提高 Kubernetes 效率的开源工具

Goldilocks 是一个免费的开源工具，可以帮助团队将资源分配到他们的 Kubernetes 部署中，并获得正确的资源校准。

Goldilocks 是一个 Kubernetes 控制器，它收集关于正在运行的 pod 的数据，并就如何设置资源请求和限制提供建议。它可以帮助组织了解资源使用情况、资源成本以及围绕使用效率的最佳实践。

Goldilocks 是 Kubernetes 的一个开源工具，它帮助您了解资源使用和成本，以便您可以围绕效率实施 K8S 最佳实践。

点击发微博

Goldilocks 采用 Kubernetes 垂直 Pod 自动定标机(VPA)。它会考虑工作负载的历史内存和 CPU 使用情况，以及 pod 的当前资源使用情况，以便建议如何设置资源请求和限制。(虽然 VPA 实际上可以为您设置限制，但通常最好仅使用 VPA 引擎来提供建议。)本质上，该工具为名称空间中的每个部署创建一个 VPA，然后查询该部署的信息。

如果构建健康、高效的 Kubernetes 部署对您来说是一个挑战，那么一定要看看 Goldilocks。

您可以阅读更多 k8s 效率的最佳实践，了解如何启用资源推荐并更好地了解您的工作负载平衡。

Kubernetes 安全性最佳实践

原文：https://www.fairwinds.com/blog/kubernetes-best-practices-for-security

Kubernetes 是主流的容器编排解决方案。Kubernetes 的天才之处在于它能够为您提供一个框架来灵活地运行分布式系统。然而，它引入了令人难以承受的复杂程度。通过遵循 Kubernetes 在安全性、可靠性、效率和监控方面的最佳实践，团队可以为成功过渡做好准备。在一系列的博客文章中，我们将从安全性开始讨论这些主题。

Kubernetes 最佳实践:安全性

Kubernetes 抽象出足够的基础设施层，以便开发人员可以自由部署，同时运营团队保留对重要治理和风险控制的访问权。挑战在于 Kubernetes 的新开发团队可能会忽略一些关键的安全特性。通常，最简单的工作方式就是降低安全性。

让我们看看三个常见的安全挑战，以及如何克服它们。

好的突发与坏的突发

Kubernetes 能很好地应对交通突发——不管是好是坏。如果你看到一个合法的流量爆发，Kubernetes 将扩大规模，以满足需求的增长。您的应用程序将消耗集群中的更多资源，而不会降低性能。这是一个很大的好处。然而，在拒绝服务(DoS)攻击的情况下，Kubernetes 将做完全相同的事情，而您将为这种流量过载付出代价。

K8S 最佳实践# 1–针对以下方面设定限制:

每个 IP 地址的并发连接数
每个用户每秒、每分钟或每小时可以发出的请求数
请求主体的大小
并为各个主机名和路径调整这些限制

授予安全访问级别

部署新应用程序或供应新用户的最简单方法是放弃管理权限。但这也是最危险的方式——如果攻击者获得了该帐户的访问权限，他们就可以访问所有内容。

K8S 最佳实践# 2–采用基于角色的访问控制(RBAC)来遵守最小特权原则。

RBAC 允许您授予用户对 Kubernetes API 资源的细粒度访问权限。您应该使用Roles或ClusterRoles.定义访问配置文件，使用Roles,您将授予对单个名称空间的访问权限。使用ClusterRoles,，你可以授权访问没有名称空间的资源，比如Nodes和PersistentVolumes以及所有有名称空间的资源。

虽然 RBAC 配置可能会令人困惑和冗长，但像 rbac-manager 这样的工具可以帮助简化语法。这有助于防止错误，并为谁有权访问什么提供更清晰的感觉。

最终结果？通过只授予工作负载完成工作所需的权限，可以限制攻击者对 Kubernetes 环境造成的损害。

保守 Kubernetes 的秘密，秘密

如果您使用的是 Kubernetes 基础设施即代码(IaC)模式，那么拥有一个完全可复制的环境会让您受益匪浅。但是有一个问题——您的基础设施可能包括 Kubernetes Secrets,,它存储和管理敏感信息，比如密码、OAuth 令牌和 ssh 密钥。您不应该将Secrets添加到您的 IaC 存储库中。

将您的 Kubernetes Secrets签入到您的基础设施即代码存储库中，以便您的构建是 100%可重复的，这很有诱惑力。但如果你在乎安全，就不要。一旦签入，您的Secrets将永久地暴露给任何能够访问您的 Git 存储库的人。

K8S 最佳实践# 3——在将秘密签入基础设施存储库之前，对它们进行加密。

解决方案是分割差异:加密你所有的秘密，这样你就可以安全地将它们签入你的存储库，而不用担心暴露它们。然后，您将只需要访问一个加密密钥来“解锁”您的 IaC 存储库，并拥有完全可复制的基础设施。像 Mozilla 的 SOPS 这样的开源工具可以在这方面有所帮助。

您可以通过查看我们如何为客户的托管 Kubernetes 部署实施安全性来阅读更多的 Kubernetes 安全性最佳实践。

您还可以查看 Kubernetes 关于效率的最佳实践。寻找一个完整的 Kubernetes 治理平台？Fairwinds Insights 是免费的。今天开始。

Kubernetes 监控和警报的最佳实践

原文：https://www.fairwinds.com/blog/kubernetes-best-practices-monitoring-alerts

事实是，对大多数人来说，Kubernetes 的正确监控是一种幻想。这是一个在动态的、不断变化的 Kubernetes 环境中被放大的问题。这是一个严重的问题。

虽然组织通常希望获得可用性保险，但很少有人能很好地监控他们的环境，主要原因有两个:

监控很难跟上不断变化的环境。
监控配置通常是事后才想到的——直到出现问题时才进行设置，并且监控更新很少随着工作负载的变化而进行。

当一般组织最终认识到其对应用程序/系统监控的需求时，团队已经不堪重负，只想着保持基础架构和应用程序“正常运行”,而没有能力去发现问题。许多组织甚至无法监控正确的事情来识别应用程序或基础架构日常面临的问题。

事实是，对大多数人来说，Kubernetes 的正确监控是一种幻想。

点击发微博

【Kubernetes 监控不当的后果

如果没有足够的监控，您将面临许多后果(一些是普遍的，另一些在 Kubernetes 中举例说明)。

没有正确的监控，操作可能会中断。
您的 SRE 团队可能无法尽快响应问题(或正确的问题)。
监控管理必须反映集群和工作负载的状态。
手动配置会增加可用性和性能风险，因为监视器可能不存在或不够准确，无法触发关键性能指标(KPI)的变化。
未检测到的问题可能会导致违反 SLA。
不正确的显示器设置可能会导致传呼机发出噪音。

监控不足会带来大量繁重的工作，因为您需要不断地检查系统，以确保它们反映您想要的状态。

Kubernetes 监控和警报的最佳实践

我们需要的是发现未知的未知的监控和警报——也称为可观察性。 Kubernetes 最佳实践认识到监控是关键，需要使用正确的工具来优化您的监控能力。需要监控什么，为什么？这里我们建议一些最佳实践。

1。创建您的监控标准

使用 Kubernetes，您必须构建监控系统和工具来响应环境的动态特性。因此，您需要关注可用性和工作负载性能。一种典型的方法是尽可能收集所有的指标，然后使用这些指标来尝试解决出现的任何问题。这使得运营商的工作变得更加复杂，因为他们需要筛选过多的信息来找到他们真正需要的信息。开源工具如普罗米修斯、 OpenMetrics 和供应商如 Datadog 帮助标准化如何收集和显示指标。我们建议 Kubernetes 监控的最佳实践包括:

没有副本的 Kubernetes 部署
水平 Pod 自动缩放器(HPA)缩放问题
主机磁盘使用情况
高 IO 等待时间
网络错误增加
豆荚粉碎增加
不健康库伯莱
nginx 配置重新加载失败
未就绪的节点
大量未处于运行状态的 pod
外部 DNS 错误注册记录

2。实施监控为代码

Kubernetes 的天才之处在于，您可以将基础设施实现为代码(IaC)——使用配置文件管理 IT 基础设施的过程。在 Fairwinds，通过将监控作为代码来实施，这一点更进了一步。我们使用由我们团队构建的开源软件项目 Astro ，来帮助实现更好的生产力和集群性能。Astro 是为与数据狗一起工作而建造的。Astro 根据定义的模式监视集群中的对象，并根据该状态管理 Datadog 监视器。作为在 Kubernetes 集群中运行的控制器，它订阅集群中的更新。如果在集群中创建了一个新的 Kubernetes 部署或其他对象，Astro 会知道，并根据集群中的状态创建监视器。本质上，它提供了一种以 Datadog 能够理解的方式动态创建和管理警报的机制。

3。识别所有权

由于监控集群工作负载涉及一组不同的利益相关者，您必须从基础设施和工作负载的角度确定谁负责什么。例如，您希望确保在正确的时间提醒正确的人，以限制提醒与您无关的事情的噪音。

4。从一级监控转移到二级监控

监控工具必须足够灵活以满足复杂的需求，同时足够容易快速设置，以便我们可以超越第 1 层监控(例如，它是否工作？").第 2 层监控需要仪表板来揭示安全漏洞在哪里，是否符合合规性标准，以及有针对性的改进方法。

5。定义紧急

影响和紧迫性是必须持续确定和评估的关键标准。关于影响，能够确定警报是否可操作、基于影响的严重性以及已经或将要受到影响的用户或业务服务的数量至关重要。紧迫性也发挥了作用。例如，问题需要立即解决，还是在接下来的一个小时或第二天解决？

很难总是提前知道要监控什么，所以当有人不可避免地在半夜被吵醒并需要将一切恢复正常时，你至少需要足够的背景来找出哪里出了问题。如果没有这种程度的理解，您的团队就无法分析应该监控什么，也无法知道什么时候该咧嘴笑，什么时候该忍着发出警报。

阅读深入见解了解如何在 Kubernetes 环境中优化监控和警报功能。

其他资源:

Kubernetes 可靠性最佳实践

原文：https://www.fairwinds.com/blog/kubernetes-best-practices-reliability

许多 Kubernetes 的采用者试图利用早于云原生应用程序和 Kubernetes 的现有基础设施自动化技术，如 Puppet、Chef、Ansible、Packer 和 Terraform。以非云本机方式使用这些工具不会产生最佳结果。例如，使用配置管理工具来构建容器映像会为您的应用程序部署增加不必要的时间和复杂性，这会影响您的灵活性和恢复能力。

通过正确的配置，Kubernetes 的可靠性变得更加容易实现。随着您采用容器、Kubernetes 和云原生架构，您使用前 Kubernetes 工具的程度和方式可能会发生变化。

Kubernetes 可靠性最佳实践

Kubernetes 环境中的可靠性等同于稳定性、简化的开发和操作以及更好的用户体验。

在 Kubernetes 中，很容易配置错误。部署正确的配置以确保稳定性、简化的开发和操作以及更好的用户体验。

点击发微博

在 Kubernetes 环境中，通过正确的配置，可靠性变得更加容易实现。在这里，我推荐四个 Kubernetes 最佳实践技巧来提高可靠性。你可以在这里阅读我的完整推荐。

秘诀 1:拥抱短暂

使用云原生架构来帮助拥抱容器和 Kubernetes pods(应用程序容器的运行实例)的短暂本质。两个例子包括:

使用服务发现来帮助用户和其他应用程序访问您的应用程序。Kubernetes pods(运行容器)的数量会随着您的应用程序扩展以满足需求而变化，服务发现提供了一种无需知道它们的位置就可以访问这些 pods 的方法。
不要试图修改现有的容器，而是从其容器映像中提取应用程序配置，并通过 CI 管道构建和部署新的容器映像。容器是短暂的，在应用程序容器中运行配置管理软件会增加不必要的复杂性和开销。关于从容器映像中分离应用程序配置的更多信息，请参见我们的 How to Kube 视频。

技巧 2:避免单点故障

Kubernetes 通过提供冗余组件来帮助提高可靠性，并使跨云中多个节点和多个可用性区域(AZs)调度应用程序容器成为可能。使用反亲缘关系或节点选择来帮助将您的应用程序分布在 Kubernetes 集群中，以实现高可用性。

节点选择允许您根据标签定义集群中哪些节点有资格运行您的应用程序。标签通常代表节点特征，如带宽或特殊资源，如 GPU。

反相似性允许您基于标签的存在，进一步约束不允许您的应用程序运行的节点。这使得您的应用程序容器不能在同一节点上运行，或者不能与同一应用程序的其他组件在同一节点上运行。点击阅读更多容错建议。

技巧 3:设置资源请求和限制

对 CPU 和内存的资源请求和限制是 Kubernetes 调度程序完成工作的核心。如果允许单个 pod 消耗所有的节点 CPU 和内存，那么其他 pod 和潜在的 Kubernetes 组件将会缺乏资源。对 pod 消耗设置限制将通过防止 pod 消耗节点上的所有可用资源来增加可靠性(这被称为“噪音邻居问题”)。

技巧 4:使用活跃度和就绪性探测器

默认情况下，Kubernetes 将立即开始向应用程序容器发送流量。通过设置健康检查来提高您的应用程序的健壮性，健康检查会告诉 Kubernetes 您的应用程序 pods 何时准备好接收流量，或者它们是否变得没有响应。参见我对设置这些探头的建议。

如果您想对构建可靠的集群进行更深入的分析，请查看我们的 Kubernetes 最佳实践。您还可以阅读更多关于安全性和效率的最佳实践。

kubernetes:fin ops 的黑洞

原文：https://www.fairwinds.com/blog/kubernetes-blackhole-of-finops

FinOps 最近已经成为云原生生态系统中的另一个时髦词汇。根据 FinOps 基金会的定义，FinOps 是:

FinOps 是一种不断发展的云财务管理规则和文化实践，通过帮助工程、财务、技术和业务团队协作制定数据驱动的支出决策，使组织能够获得最大的商业价值。

FinOps 是我们在云行业使用多年的一个术语。目标是确保财务团队和运营团队保持一致，并对云支出拥有所有权。这需要根据预算、收入目标和业务目标来衡量和跟踪财务(即云)支出。

有许多很好的工具可以用来跟踪云支出，但是容器是一个长期存在的问题。Kubernetes 是容器编排领域不可否认的赢家。我喜欢称之为 FinOps 的“黑洞”。正如云曾经是企业的未知成本一样，今天 Kubernetes 在组织中占据了这一位置。对于那些不了解如何配置 Kubernetes 以确保成本与应用程序性能要求保持一致的组织来说，这尤其是一个“未知数”。

为什么 Kubernetes 是一个成本黑洞？

要理解为什么 Kubernetes 是一个成本黑洞，重要的是要考虑 Kubernetes 如何工作。

Kubernetes 集群部署在云实例上，但它们通常是共享的。Kube 集群可以托管多个工作负载和应用程序，但是您的云提供商的账单在集群内部是不可见的。缺乏对多个团队如何利用或共享基础架构的可见性是“黑洞”。

DevOps 团队正在部署 Kubernetes，作为开发人员开发应用程序的平台，以当今基础设施所需的可靠性将应用程序更快地推向市场(例如，如果我的应用程序流行，我需要我的应用程序自动扩展)。

因此，开发人员正在使用 DevOps 和平台工程团队提供的东西。主要挑战之一是围绕 CPU 和内存设置 Kubernetes 配置。在配置时，开发人员必须决定要进行哪些设置。如果 CPU 和内存设置得太低，应用程序可能会出现性能和可靠性问题。另一方面，如果设置过高，组织可能要为不必要的云资源付费。

觉得这没什么大不了的？在一个例子中，开发人员错误地设置了配置设置，导致 24 小时内超支 50，000 美元。幸运的是，DevOps 团队在一天之内就发现了这个问题，但是如果错过了，对组织来说可能是毁灭性的。

FinOps 是 Kubernetes 的服务所有权

FinOps 基金会称“本质上，FinOps 是一种文化实践。这是团队管理其云成本的方式，在这种方式下，每个人都可以在中央最佳实践小组的支持下掌控自己的云使用情况。”这也适用于 Kubernetes。

我们谈论了很多关于 Kubernetes 服务所有权的问题，即 DevOps 为开发人员提供了从开始到维护构建、部署和拥有应用程序所需的工具和防护。当考虑 Kubernetes 服务所有权如何影响总体成本管理时，适当的配置起着主要作用。服务所有者，即开发人员，需要了解一个应用程序的最终成本，以及该金额是否符合他们的定价标准。在 Kubernetes 之前的过去，企业可以依靠云成本工具来提供对底层云基础架构的可见性。但现在，Kubernetes 在云成本管理方面提供了一个新的模糊层，这是传统云成本监控工具的黑洞。

通过使用 Kubernetes 的 FinOps /服务所有权模型，团队可以了解工作负载的“真实成本”,并在应用程序、产品和团队之间进行适当的成本分配。这种对云资源的清晰程度，通常是通过 Kubernetes 治理平台发现的，允许团队围绕 Kubernetes 的财务做出更好的决策。没有它，组织很难在 Kubernetes 这样的动态环境中优化计算和工作负载。多个团队、多个集群和大量的复杂性转化为大量的信息，以便在尝试做出明智的实时业务决策时进行审查和评估。

我们的一个客户 Clover Network 使用这种 fin ops/服务所有权模型来通知其业务:

“Fairwinds 正在帮助我们转变经营方式。我们可以说，“这个应用程序团队”、“服务”、“产品”、“功能”有一个特定的成本，并围绕它发出警报。它帮助我们了解我们作为一家企业在做什么，我们需要关注哪里，我们需要改变我们的投资。“三叶草工程副总裁 Rishi Malik

Kubernetes 的 FinOps 方法可以被视为另一种适当的成本管理和服务所有权模型。无论您如何称呼它，如果使用 Kubernetes，您需要授权开发团队在生产中拥有和运行他们的应用程序，消除作为交付瓶颈的 Ops，同时还提供他们做出更好决策所需的财务管理细节。

Kubernetes 诊所:了解如何检查您的 Kubernetes 集群健康状况

原文：https://www.fairwinds.com/blog/kubernetes-clinic-check-your-kubernetes-cluster-health

新年伊始，我们都想开始做些事情，让自己更健康、更有效率或更快乐。你的 Kubernetes 集群值得同样的爱！这是确定您的集群是否是您希望进入新的一年的那种集群的好时机。那么，如何检查这一点并做出改变以改善 Kubernetes 集群的健康状况呢？

开源工具

有一些很棒的开源工具可以用来检查 Kubernetes 集群的健康状况。Fairwinds Insights 平台聚集了许多非常酷的开源工具，你可以使用它们在一个地方查看所有这些信息。现在，Insights 推出了免费层，可用于多达 20 个节点、两个集群和一个 repo 的环境，允许您跨多个集群运行所有这些工具，并在一个集中的控制面板中获得结果。

为了让您的集群成为 Insights 生态系统的一部分，以便您可以管理和检查它，您需要安装 Insights 代理。免费的洞察层功能齐全，因此所有报告都可用。当您注册免费等级时，您将收到一封确认电子邮件，其中包含设置页面的链接。在这里，您将能够创建一个组织，然后通过提供所需的集群名称来添加您的第一个集群。然后，您将收到安装 Insights 代理的说明。安装由安装代理的 Helm 命令和控制要安装的组件的 values.yaml 文件组成。您可以调整这些值来改变应用程序的行为或设置。

洞察代理&扫描

默认情况下，免费层会自动安装:

北极星，Kubernetes 的开源策略引擎
开放策略代理 (OPA)，通用策略引擎
Nova ，一个命令行界面，用于查找过时或废弃的舵图
Pluto ，一个在代码仓库和 Helm 版本中发现弃用的 Kubernetes apiVersions 的实用程序

这个设置很容易操作，会给你很多信息。Insights 提供的 values.yaml 文件包括用于标识您的帐户的令牌和启用的开源工具(这些称为报告)。将 values.yaml 文件的内容复制到您自己的本地目录中。运行提供的舵命令；编辑-f 标志，使其指向本地目录中的值文件。该命令声明您将使用的 Insights 版本，并创建一个 insights-agent 名称空间，在其中安装各种组件。

一旦设置完成，您将看到 Insights 代理已经运行了 Pluto、Polaris、OPA 和 Nova 报告。您可以回到 Insights，您将开始在行动项目中看到数据。

Insights showing data in Action Items

很快，您可以看到该报告为您提供了所发现内容的描述以及您可以采取的一些补救措施。它提供了可用于更改部署清单的数据。完成这些更改后，报告将清除这些行动项目。

扫描集装箱和集装箱图像的安全漏洞

从安全角度来看，扫描您的容器和容器图像非常重要

安全漏洞。使用 Insights 免费层也很容易做到这一点——你只需要去安装中心添加 Trivy ，这是一个开源的漏洞扫描器。只需点击可用的按钮并进行配置。

Trivy available in the Install Hub

单击“添加报告”按钮，您将看到一个新版本的 values.yaml 文件，您可以将其复制并粘贴到本地文件上。

Trivy 运行的时间要长一点，因为它遍历并扫描它在集群中找到的每一个图像。完成后，查看一下漏洞，您可以很容易地看到受影响最大的图像、按严重性的细分以及受影响最大的图像。您可以按严重性进行排序，并单击以获取有关已发现漏洞的更多信息。

Top impacted images shown in Vulnerabilities tab in Insights

检查您的 Kubernetes 集群的健康得分

转到 Fairwinds Insights 并选择 Cluster 选项卡。你首先看到的是一个健康评分；这是通过与未通过行动项目的比率，更倾向于关键行动项目。 Health score of "A" in Fairwinds Insights

Action items 是一个单一的位置，在这里您可以查看来自 Polaris、OPA、Nova、Pluto、Trivy 和您安装的任何其他报告的所有信息。如果您查看行动项目表，您可以快速看到一些有趣的摘要信息。

北极星

Polaris 有大约 30 个最佳实践的内置策略。一些与安全相关的策略包括:

在这个平台中，我们有关于以 root 用户身份运行意味着什么的信息。每个行动项目都有参考链接，该平台还解决了补救问题。有相当多的详细信息是关于改变你的容器版本，使之不作为 root 运行，然后在你的 pod 定义中设置你的安全上下文。Insights 提供了尽可能多的上下文，这样您就不会查看操作项，看到某个东西正在以 root 身份运行，然后想知道您可以对此做些什么。Insights 甚至提供了解决该问题所需的一些代码示例。

吉拉整合

您还可以将 Insights 连接到吉拉并点击创建票证，然后将其直接发送给负责该票证的团队，请他们进行修复。如果您知道某个措施项正在按设计运行(即使它被标记为措施项)，您可以解决该措施项。如果您对某个措施项无能为力，您可以将其标记为已解决。这不会修复任何问题，但会删除行动项目。你也可以暂停一件事，这样你就不会在下一周再次想起它，如果它是你知道但不想马上处理的事情。

查看多份报告

如果您想知道某个操作项来自哪个报告，您可以显示报告列，然后过滤到特定的报告。或者你可以按类别来看。

Action Items filtered by reports in Fairwinds Insights

所有行动项目都属于以下三个类别之一:安全性、可靠性或

效率。如果您对集群运行状况的某个特定方面感兴趣，可以深入研究这些特定领域。因此，您可以看到所有可靠性措施项、识别它们的报告以及它们的严重程度。这可以帮助你优先考虑你想关注的行动项目。

自动化规则

设置和运行自动化规则是 Insights 中更强大的功能之一。您可以创建和编辑规则，也可以使用默认规则。本质上，您命名规则(没有空格)并编写描述。您可以设置上下文、报告、集群和操作。然后您可以保存或更新规则。例如，如果你有一个非常高的

名称空间的安全集合，其中该名称空间中的每个漏洞都必须立即得到修复，您可以编写一个操作项，说明如果 Insights 在资源名称空间中发现安全漏洞，您希望提高该操作项的严重性，然后根据该严重性创建票证。这是一个基于 JavaScript 的引擎，所以你可以写一个规则来做任何你想做的事情。

保持 Kubernetes 集群健康

Kubernetes 很复杂，很难掌握所有可能的健康问题。Fairwinds Insights 集成了大量的开源工具，可以轻松检查集群的安全性、可靠性和效率。使用新的免费洞察层，您可以快速开始，这样您就可以在未来一年保持 Kube 集群的健康。

观看在线研讨会的现场演示，了解有关如何检查 Kubernetes 集群运行状况的更多信息。

Kubernetes 诊所聚焦:Brad Geesaman，照亮 Kubernetes 的安全

原文：https://www.fairwinds.com/blog/kubernetes-clinic-spotlight-brad-geesaman-shining-a-light-on-kubernetes-security

Brad Geesaman 已经在 IT 安全和基础设施的交叉领域工作了近二十年。作为 KubeCon 或 BlackHat 的专家，Brad 作为 Darkbit 的联合创始人，运用他的网络安全专业知识和容器编排知识，帮助客户保护其云原生工作负载。Kubernetes 社区的积极贡献者-他与来自社区各个方面的大量不同人群合作- Brad 建议成为 Kubernetes 集体的积极成员，作为将 Kube 产品推向市场的第一步。正是这种社区焦点和边听边学的风格使得 Brad 成为 Kubernetes Clinic: Spotlight 博客系列的完美第一次采访。

我有机会问了 Brad 一些关于安全状况和 Kubernetes 的最紧迫的问题。从需要相信 Kubernetes 是在考虑安全性的情况下开发的，到组织过度依赖少数关键的 Kubernetes 专业人员，到为什么 OSS 社区保持相当低的安全风险，Brad 列出了什么让他紧张，什么让他兴奋。他甚至分享了为什么他认为 Kubernetes 托管服务——如 fair winds——是许多组织开始使用 Kube 的明智之选。

我们很高兴 Brad 与我们坐在一起，回答我们关于 Kubernetes、安全性以及他为 Darkbit 工作带来的价值观类型的问题。为了感谢他抽出时间，Fairwinds 公司以 Darkbit 的名义向“女性安全与隐私”( Women in Security & Privacy，WISP，www.wisporg.com)进行了捐赠。WISP 是 Darkbit 过去捐赠的一个组织，因为该团队希望“继续支持信息安全行业女性的职业发展和思想领导力。”

让我们从布拉德·吉萨曼开始:

首先，你在疫情期间过得怎么样？

总的来说，我们做得很好。谢谢关心！我希望你们现在也尽自己所能做得更好。

你是如何对 Kubernetes 产生兴趣的，具体来说，是在它出现的时候？有什么特别的事件引起了你的兴趣吗？

【2016 年初，在我们被赛门铁克收购约一年后，我们由约 6 名工程师组成的团队正寻求重新设计我们的道德黑客模拟平台，我们曾使用该平台运行从裸机虚拟化到 AWS 的旗帜事件。主要目标是成本效率、更快的目标开发、更快的目标加速、每 4 人一组的专用目标、更好的地理分布以及将一切自动化为代码。大约 9 个月后，我们将在全球范围内接待 1500 名参与者，进行为期 1 周的 24x7 在线活动。自然的想法是利用不同 AWS 区域中的 EC2 实例，但这只能很好地解决其中一些目标。我们的团队已经在利用 Docker 容器进行一些目标开发，我们决定对 Docker Swarm 和 Kubernetes 1.3 进行概念验证。尽管阿尔法没有 RBAC 和卡利科网络政策，但库本内斯可以灵活地按照我们的要求行事。有目的地允许参与者在他们自己的名字空间中的一个或多个容器中获得外壳是我们今天看到的多租户问题的早期形式。我们开始渗透测试我们自己的平台，并牢记这一点，一件一件地锁定。从那时起，Kubernetes 组件的实践安全教育被证明是无价的。

作为 Kubernetes 安全领域的领导者，您是众所周知的。Kubernetes 社区今天需要讨论的最重要的安全话题是什么？

这一切都归结于信任。相信 Kubernetes 的特性是在高度安全的基础上开发的。相信云的默认设置在配置方面是安全的。信任容器映像的来源、它们的依赖关系以及贡献代码的人员的安全性。在整个生态系统中有许多假定的信任，组织需要真正理解它们，以确保它们在所需的安全级别上运行。作为一个社区，我们需要不断地重新审视这些假设，因为用户依赖这些决策来交付他们的产品和服务。

当您深入研究基于 Kubernetes 的基础设施时，您会发现哪些常见的安全隐患？有没有常见的冒险行为或你看到的怪异事情？

我始终看到几件事:从组织的角度来看，过度依赖一两个了解整个系统的关键人物。对于那些试图扩展的团队来说，他们往往是一个瓶颈，并且非常容易精疲力尽。从运营的角度来看，我们看到了撞上“复杂性”墙的征兆。我的意思是，在某个点上，环境、集群和应用程序开始足够好地工作，而添加更严格的安全策略等内容开始破坏这种成功，并需要太多的认知负载。从 DockerHub 运行图像而不进行审查，缺乏 pod 网络分段，以及缺乏用于检测集群内恶意行为的一致策略是其常见的副作用。

Kubernetes 只有几年的历史，但其采用率却一飞冲天(CNCD 2020 报告指出，从 2019 年到 2020 年，生产部署增加了 58%)。你认为这项技术在未来 2-3 年内会发展到什么程度？和今天会有什么不同？

我认为未来 1-2 年将是 Kubernetes 项目的一个真正的转折点，在快速接受一些用户需要的功能和贡献与许多其他用户需要的安全性和稳定性之间取得平衡。一种选择可能是长期支持(LTS)发布方法，这种方法可以为一些组织提供更稳定的目标，并减轻其运营团队的更新压力。

你最近成立了一家名为 Darkbit 的公司，该公司帮助云原生组织高效地评估其 AWS、GCP 和 Kubernetes 环境的安全状况。你对在 Kubernetes 周围开公司的人有什么建议？

有两种方法可以回答这个问题。首先，对于那些已经开始围绕 Kubernetes 产品和服务建立公司的人来说。第二，对于采用 Kubernetes 并寻求安全建议的组织。

对于前者，考虑到项目和周围社区项目的爆炸式增长，社区的新成员可能很容易看到感知到的差距，并尝试立即围绕这一差距开发产品。我强烈建议首先花时间成为社区的一名贡献者，并在 Kubernetes 用户旅程的各个阶段尽可能多地与他们在一起，以真正理解潜在的文化。否则，你的产品和/或服务很可能会遭遇技术和文化的错位。

对于后者，在大多数使用案例中，利用云提供商的托管产品是最佳起点。但是，它们不能提供大多数组织通过开箱即用配置所期望的安全级别。提前花一些时间了解可用的安全相关设置，并尽早、经常地将它们构建到您的基础设施即代码方法中。然后，将精力和资源集中在自动化和保护工作负载上。

从安全的角度来看，像 Kubernetes 这样的完全开放源码软件工具会带来什么样的安全挑战？与大型 OSS 社区合作或在其中合作有什么新的或迫在眉睫的风险吗？

考虑到贡献者的巨大数量，有许多人关注提议的变更和代码审查，因此提交故意恶意代码的风险相当低。然而，当一个项目规模如此之大，包含如此多不断增长的复杂性的移动部分时，巨大的挑战是确保从安全角度理解所有潜在环境中所有组件的任何新功能或变化。此外，随着对组件行为的依赖，新发现的需要对该行为进行根本改变的安全问题由于其惯性变得更加难以解决。毫无疑问，随着项目的继续发展，平衡这些决策将是一个持续的挑战。

Kubernetes sig-release 进展迅速，而受管理的 Kubernetes 提供商在提供对最新 Kube 版本和补丁版本的访问方面似乎落后了。你对 Kubernetes 更新/补丁的状态有什么看法？你是否担心 Kubernetes 的用户群越来越落后，可能无法及时更新安全补丁？

我认为，平台团队可以在上游发布节奏和速度之间取得平衡，发布消费的速度正在放缓，原因是功能复杂性增加，或者是因为该发布正在做他们目前需要的一切。组织降低安全修补的优先级并不是一个新概念，但这肯定会因更短的版本支持生命周期而加剧。在某个时候，会有某种程度的阻力来帮助恢复这种平衡。也就是说，我更担心组织在应对“容器蔓延”时管理其容器映像安全性的能力。

您过去曾与伊恩·科尔德沃特(Ian Coldwater)这样的人就库伯内特的安全问题进行过交谈。对于对安全性及其与 k8s 的交集感兴趣的人来说，除了 Ian 之外，当他们提出问题或担忧时，我们还应该关注和倾听谁？

我非常荣幸能与这个社区的这么多杰出人士合作，与 Ian 合作 RSA2020 以及再次合作 KubeConEU2020 是一次很棒的经历！每当罗里·麦丘恩、达菲·库利、塔比·塞布尔、利兹·赖斯、迈克尔·豪森布拉斯、乔丹·利吉特、安德鲁·马丁、玛雅·卡佐罗夫斯基和许多其他人分享他们的想法(或事迹)时，我都会听。).

Fairwinds 的公司价值观是尊重、包容、同情和善良。我们每天都在努力将这些价值观融入我们的工作以及我们与同事、合作伙伴和客户的关系中。你有什么具体的价值观想带到你的工作中吗？

在 Darkbit，我们的核心价值观是诚信、透明、同理心和学习。我们努力对我们所做的一切保持开放和诚实，不断改进，我们认识到我们是一个更大的社区的一部分，所有人都朝着同一个方向前进。

Kubernetes 诊所聚焦 Liz Fong Jones:观察可观察性

原文：https://www.fairwinds.com/blog/kubernetes-clinic-spotlight-liz-fong-jones-observing-observability

如果您是对可观察性和容器化感兴趣的开发人员或工程师，您可能知道 Liz Fong Jones 这个名字。她的职业生涯专注于解决具有挑战性的重要技术问题，并从技术和道德的角度影响了开发者社区，以至于当她离开谷歌担任目前在 Honeycomb 的职位时，新闻媒体报道了这一举动。

Liz 是大会的常客，她将自己的伟大想法和承诺带到了开发者宣传的前沿和中心。当活动在 2020 年 3 月被搁置时，Liz 寻找一种解决方案来继续了解开发人员的担忧和成功。她的回答使事件民主化，并欢迎人们直接来到她家门口。她的虚拟办公时间已经到达了地球的遥远角落，并确保了那些想要分享他们的想法和听到她的想法的开发人员能够不受预算或旅行的限制。

我很高兴能和 Liz 通一次电话，问她一些关于她作为开发者倡导者的角色和云服务的重要性的问题——看着她挖掘我的一些问题并在更深的层次上回答。在与莉兹的谈话中，我们不可能不考虑得更大一点，更紧迫一点，更清楚地意识到我们是如何尊重彼此的。为了感谢 Liz 与这个社区分享她的想法，Fairwinds 以她的名义向 Trans Lifeline 捐款。

Liz，谢谢你今天抽出时间和我们聊天。我们得先问一下——你这些日子过得怎么样？

幸运的是，那些没有重大新闻的周末是有益的。

云服务已经成为我们所有人的生命线——工人、家庭、学生和运动。我们看到你最近参加了一个小组讨论关于成为一名现场可靠性工程师(SRE)的讨论，而这个世界正指望他们。鉴于云服务的至关重要性，您对现在和未来的 SREs 有什么建议？

我们总是谈论重新审视服务水平目标(SLO)的想法——如果您的服务被更多地依赖，您可能应该增加您的 SLO。如果因为其他事情更重要而突然变得不那么重要，那么你应该放松你的 SLO。这是主要的教训。你的优先事项可能会改变，所以不要试图维持一个不值得维护的系统。如果你的服务现在非常关键，你需要争取更多的资金、更多的资源等等。这样你就能让世界继续运转。

你职业生涯的大部分时间都在谷歌担任各种 SRE 职位。你从那里的经历中学到了什么，让你能够在目前的公司 Honeycomb 倡导 SREs？

我在谷歌的后端和前端团队都工作过。我的简历说，从谷歌云负载平衡器到谷歌航班，这些是完全不同的服务。其中之一是每秒数百万次查询的服务，将每一个请求发送到 Google.com。另一种是相对较低的流量服务，仍然像“嘿，这趟航班多少钱，有哪些路线选择？”我们必须考虑如何用逻辑来解释它。

那次经历告诉我，重要的不仅仅是后端系统。每个系统都有自己的角色，这适用于对组织中 sre 的同理心，尤其是较小的组织。当我加入谷歌航班时，这是一个产品，因为谷歌收购了一家名为 ITA Software 的公司，该公司有数百名员工。结果，这是一个超负荷运作的团队，但他们也不喜欢有人来找他们，说“用谷歌的方式去做”我艰难地认识到，你不能去一个团队，告诉他们如何以不同的方式去做。

几年前引起我们注意的一件事是，你对作为 SRE 进行管理的想法。这还是你认为 SREs 需要掌握的技能吗？在过去的 3-4 年里，情况有所改变吗？

对于包括 SREs 在内的各类工程师来说，掌握它仍然是超级关键的，因为你必须就你的影响进行沟通，并说服其他人接受你的技术想法。特别是对于那些被边缘化的人，他们不得不记录他们在做什么，证明他们在做伟大的事情，因为他们的经理没有关注他们。

仍然专注于 SRE，你在 Monitorama PDX 2019 上发表了题为“通往可观测性之路的权衡”的演讲，谈论了 SRE 的效率和可持续性。你从那次演讲中最大的收获是什么？

从那次谈话中最大的收获是不要重新发明轮子——如果有其他选择，不要自己造。我想说服人们真正地问这个问题“我的组织有什么回报？”是为了建设而建设还是为了影响而建设？许多公司决定组建一个 Kubernetes 团队或一个 observability 团队，并在内部建立一些东西。但是他们最好选择托管服务提供商。你必须问，这是否真的让你与众不同。

蜂巢刚刚发布了关于可观测性的研究。给我们讲讲那个研究。你对这些发现感到惊讶吗？

这实际上是我们在 2019 年做的一个项目，我们试图围绕可观察性建立一个成熟度模型。我们雇佣了一个独立的研究公司去研究可观察性社区，去发现人们在实践什么，下一步是什么？商业成功和可观察性之间有关联吗？

观察市场现状很有趣——目前有多少人在尝试寻找出路，有多少人已经在寻找出路。有很多人想坐上观察列车，但不知道如何去做。我们正准备在 2021 年用同样类型的问题再次做这份报告，这样我们就可以看到基线是什么，以及指针在过去 18 个月里移动到了哪里。这项研究有一点令人惊讶的是，在我进行的对话中，我有选择偏见。我和那些对可观察性研究非常感兴趣的人聊过。当你看到整个市场时，你会意识到还有一群人你还没有接触到，这是最让我吃惊的。

除了极高的采用率之外，你还看到了哪些我们可能需要准备的 Kubernetes 可观测性？这是真正让我感到矛盾的事情，因为很多公司都在推广 Kubernetes 代理。面临的挑战是，当您在原始服务日志层、系统指标层或服务网格层检测服务时，您不会捕获应用程序的细节，而这正是丰富细节所在。你必须结合这些方法。我认为人们需要明白这一点:放一个特工进去不会神奇地给你 100%的可观察性。

随着集装箱化，尤其是 Kubernetes 的持续增长，你认为这些公司如何能够继续关注并最大限度地提高对客户的服务质量？我不确定目标是最大化服务质量。目标是获得足够好的服务质量。

我应该清楚，Honeycomb 不使用 Kubernetes——我们在生产中不使用它。这对我们的用例来说太大了。我们看到人们采用 Kubernetes 的原因甚至不是从可靠性的角度，而是从成本的角度。他们希望将工作负载放在一起。这些工作负载中有许多是子机。我们的工作负载填满了整台机器，甚至更多。我们有自动替换节点的机器。如果一个死了，我们会自动造一个新的。当提到 Kubernetes 时，人们最初采用它是出于成本原因或容器管理原因，因为他们想获得事物的新副本。如果你打算这样做，很多可靠性的好处来自它能够旋转一个新的容器。不幸的是，人们正在用 Kubernetes 做大量持久的工作，这充满了危险。我知道有很多方法可以做到这一点，但是您必须进行测试，并确保您的工作负载能够在重启 pod 后继续存在。人们不习惯这样。我说我们不用 Kubernetes，但是我们用 Kubernetes 的概念。

**你认为二分法对可观察性有什么影响——对于真正重视可观察性的人来说，避开 Kubernetes 或基于容器的编排有意义吗？这是可观察性很重要的部分原因——如果您有更多的服务，因为您不再有运行在单台机器上的 monoliths，这意味着您的日志不会持久；它们会不断地被清除和重新启动，并且您有更多的服务来跟踪执行流程。是的，当它不在单台机器上时，它更复杂，更困难，但这就是为什么你应该采用可观测性。我甚至可以说在这种情况下它更有价值。

你非常开放和热情地在网上举办私人办公时间，让人们谈论 SRE 的可观察性&。在一个我们现在越来越多地远程联系的世界里，虚拟办公时间的想法特别吸引我。那段经历对你有什么影响，它对你和更大社区的人联系有什么帮助？今年 3 月，当我发现我们至少 18 个月内不会开会议时，我开始做虚拟办公时间。那一刻，我意识到，作为一名开发者倡导者，我需要继续做社区拓展，但要有所不同。我需要了解开发人员在想什么，谈论他们正在经历什么问题。过去，我可以去参加一个会议，与人们谈论这个问题，了解他们的服务做得如何，以及他们面临哪些挑战。我意识到，除非我开始邀请人们来我家门口，否则我做不到。事实证明，虚拟办公时间真的很棒——几乎每个大洲的人都向我求助。即使在我们恢复会议的世界里，我也会继续这样做。这太民主了——任何人都可以这样做，而不仅仅是那些能负担得起飞到一个地方然后呆在酒店里看我的人。**

你的推特是创新、倡导和包容的结合。这些也是商业中的重要话题。关于多元化、包容性和创新如何改善他们服务客户的方式，你对公司有什么反馈吗？

有趣的是，对于多样性和包容性有公正的争论，然后还有经济的争论。试图找出如何谈论这些事情真的很难，我不确定我已经掌握了诀窍。至于为什么我选择我的推特是现在这个样子——因为我是一个完整的人。如果你从根本上不尊重我这个人，我不想给你商业建议。我是如何把这个镜头带入我的工作中的，如果你的服务对 99%的人来说很好，但对 1%的人来说很难，那也许是你应该做些什么的事情。你也许应该弄清楚那 1%的人是谁，为什么他们受到的影响很小。他们有共同的特征吗？我能做些什么来纠正这个问题？这是对世界其他地方发展状况的类比。有些群体的服务质量——可以说——不太好，我们应该努力改变这种状况。

库伯内特诊所聚焦塔比莎·赛布尔:帮助人们提高水平

原文：https://www.fairwinds.com/blog/kubernetes-clinic-spotlight-on-tabitha-sable-helping-people-level-up

与塔比莎·赛布尔交谈就像试图将 20 磅的食物塞进一个 5 磅重的袋子里——整个过程充满了洞察力、技术知识和健康的社区支持。无论她是在阅读代码和文档以了解其背后的东西，咀嚼 Kubernetes 的安全性，还是讨论为什么公司需要将雇用高级工程师视为一项战略决策，Tabitha 都很聪明，同样感兴趣和有趣，并且非常投入她的时间和知识。

我们最近有机会拜访了 Tabitha，讨论了广泛的话题，既有与 DevOps 安全相关的，也有与 devo PS 安全无关的。她的朋友说，当她说话时，他们会倾听，这是有原因的——她以有目的的深思熟虑对待她的工作和生活，并致力于我们行业内的合作。

请继续阅读，这将是一场迷人而巧妙的对话，技术和个人因素并重。作为参与此次问答的回报，Fairwinds 以 Tabitha 的名义向“ 女性安全与隐私 ”进行了捐赠。她选择了这个慈善机构，因为她“亲眼目睹了 WISP 如何将人们与改善职业生涯、改变生活和改善行业的机会联系起来。”

首先，在疫情和我们生活和工作方式的彻底转变中，你们做得怎么样？

到目前为止，我非常幸运地穿越了疫情。不过，我想念和人交往！我一直在努力保持我的情绪和身体健康，并利用我的特权来支持我的社区。我们要一起度过难关。

来自 DarkBit 的 Brad Geesaman 是我们第一个“Kubernetes 诊所聚焦”的主角。谢谢你的转发。他说无论何时你有话要说，他都会听。你认为是什么让你和你的观众产生了如此大的共鸣？

我的教育背景是数学和物理，这些学科教会了我很多展示你的作品和拥抱错误的价值。当我分享我对某件事的看法时，尤其是对某个技术问题的看法时，对我来说很重要的一点是要包括原因，这样人们就可以根据他们自己的背景来理解它。我认为，在一个充斥着“摇滚明星”和思想领袖“叔叔”的行业里，人们喜欢听到“为什么”，喜欢听到诚实的“为什么”。

我看到你最近写了一些关于“复杂系统的突现行为”的文章对于这个与你的工作和我们的集体产业相关的话题，你有什么看法？我们应该思考什么？

随着我们的技术体系变得越来越复杂，这自然会鼓励我们进行专业化。专业化有助于保持对我们个人领域的深刻理解，但我认为它也让我们容易忽视被我们的观点所隐藏的互动。为了确保我们能够弥补彼此的不足，我们需要让多面手与专家、破坏者与构建者、开发人员与运营人员一起工作。我们必须保持好奇和外向，因为没有人能完全理解它。我非常喜欢 Ian Coldwater 在 KubeCon NA 2019 年发表的主题演讲“来自另一边的你好:来自 Kubernetes 攻击者的派遣”，其中涉及了这些专门围绕 Kubernetes 安全的想法。

我还认为，我们需要更有意识地优化整个系统。为了在一个复杂的堆栈(如运行在 Kubernetes 上的应用程序)中恰当地平衡特性、安全性和可维护性，我们必须超越单独优化每个组件。跨职能协作有助于形成这种整体愿景。为了更好地理解这些问题，我现在正在研究维斯特曼的“系统工程原理和实践”。我总是在寻找新的阅读材料；请随时在 Twitter 上 ping 我，告诉我您最喜欢的关于系统工程的资源！

你的 GitHub 个人资料上写着，“必须打碎东西才能知道里面是什么。”你是一个专注于容器和 Kubernetes 的黑客。你是如何打碎 Kubernetes 的，你在里面发现了什么？

我对 Kubernetes 的大部分探索都是通过与人交谈和阅读代码来实现的。我喜欢安全研究经常从非常非常仔细地阅读代码或文档开始。有时您会发现规范和实现之间的重要差异，或者以前被忽略的规范的创造性使用！

我在 Kubernetes 中发现的关键是复杂性。因为它很大，有这么多的功能，我总是对 Kubernetes 的可靠性和安全性感到惊讶。这种安全性和可靠性显示了 Kubernetes 社区对质量的关注程度。尽管如此，Kubernetes 的复杂性带来了许多安全问题。CVE-2020-8558 是一个很好的例子:“route _ localnet”sysctl 以我们大多数人都不熟悉的方式改变了 Linux 的行为。第 2 层网络的细节非常模糊，与专注于云的工程师的日常经验相去甚远，因此，许多有才华的工程师忽视设置这些系统如何会导致安全问题也就不足为奇了。

您在 KubeCon NA 2019 上共同创作并共同展示了“攻击和防御 Kubernetes 集群:导游漫游指南”,然后在今年早些时候将其作为一个独立主持的会议提供。你从你的观众那里得到了什么样的参与，有什么有趣的反应吗？

那天房间里的能量是惊人的。所有的座位都满了，人们挤在过道周围或坐在地板上，每个人都很兴奋能在那里。大约十几个来自 Kubernetes 安全社区的人不请自来，帮助支持观众。与会者一起工作，在邻居遇到困难时帮助他们。当超过 400 人说他们第一次逃离了一个集装箱时，有一种实实在在的分享喜悦的感觉。

自从 KubeCon 以来，我最喜欢的反应是当人们说他们将我们的研讨会添加到他们的入职计划中。帮助人们提升自己是一种荣誉！

Kelsey Hightower 在他的集装箱安全峰会上说:“他们说安全不是目的，而是实践。但是没有人练习。”我们很想听听你对此的看法。

很高兴听到 Kelsey 总结了我与 DevOps 的许多安全同事一样的沮丧。有效的安全性一直是一种实践，是一种不断学习的状态，当新信息可用时，我们会重新审视过去的决策。但是我们在 infosec 中有太多的文化问题，这使得我们很难一起生活！我们看不起开发和运营部门的队友。我们将合规性要求视为权威的智慧，而不是有问题的建议。我们的组织试图在项目交付之前“在顶部洒上安全性”。我们有一个根深蒂固的计算机安全产业，它基于“我们对他们”的理念，即安全需要将组织从其他人认为的无能中拯救出来。

这种态度从来没有真正产生过很好的效果，但在 90 年代的本地糖果棒网络(外面松脆，里面耐嚼)通常已经足够好了。如今，随着您的云提供商 IAM 配置取代了您计算机房门上的锁，infosec 再也无法承受如此不正常的运行了。我们必须建立关系，这样我们才能被邀请到设计系统的房间。我们需要充分了解开发和运营同事的需求，以便为他们的安全挑战提出切实可行的解决方案。“说不”的部门必须消失。

你一直在谈论集装箱、Kubernetes 和安全。在过去的 6 - 12 个月中，有没有什么事情真正引起了您的注意，需要我们更加关注或了解？

有很多很酷的先进技术让我感到兴奋，但我们大多数人都有很大的空间来提升我们的运营能力。安全基础仍然非常具有挑战性。组织经常努力了解正在运行的内容，快速轻松地部署补丁或配置更改，以及收集正确的信号来检测安全事件。云原生基础设施为我们提供了比以往任何时候都更好地确定这些基础实践的工具，但它不是自动的。成功需要有意的、深思熟虑的协作，以及对“真正做好运营”的含义有一个整体的共同愿景。回到之前关于“没有人实践”的评论，安全和法规遵从性团队在这方面也有重要贡献。他们处于提供监控和闭环反馈的有利位置。这不是指指点点的安全问题，而是帮助运营部门尽最大努力。结果是更好的安全性、更低的成本、更好的可靠性和更高的速度。每个人都赢了。

我们在今年早些时候看到了您的一条推文，内容涉及不同类型的安全社区，从产品到基础设施，再到攻击性或防御性安全。我们如何帮助产品安全专家像进攻性安全专家一样思考，等等。？为什么它很重要？

作为安全从业者，我认为我们可以通过关注我们的共同责任来帮助用户更加安全。既是目的也是手段。以用户为中心的对话有助于我们使我们的工作更加实际，也给我们提供了一个开始跨团队对话的共享空间。

据我所知，与我们专业之外的人交谈是了解我们的工作如何相互配合的最佳方式。将彼此视为日常关切不同但最终目标相同的个体，有助于减少相互指责，这种指责往往会破坏我们改善安全的努力。基本上就是交朋友，一起争取你的用户。这比单干更有趣，效果也更好。

你的推特上充满了对你的行业同事的赞美，你还和他们中的许多人一起合作讨论。你能告诉我们你的合作方式吗？

我喜欢弗雷德·罗杰斯的名言“寻找帮手”，老实说，这是我的合作方式。作为一名技术人员，我的生活中有很多力量鼓励我花时间独处，所以我试图通过寻求合作来积极应对。有时候，这意味着得到一个令人兴奋的想法，然后赶紧给有共同兴趣的同事分享；其他时候，它意味着大喊“是！”当别人分享他们的挤压。

有目的地建立你的职业关系网可能会让人感觉唯利是图，但真正的意思是“认识其他做着很酷事情的人，并努力记住哪些人有你想要的那种态度。”当你和某人一起做一个项目时，你们会花很多时间在一起，并相互影响。因此，对我来说重要的是关注团队项目，让人们举起并鼓励他们周围的人，因为当我攀爬时举起是我最基本的目标。这形成了一个积极的反馈循环，这就是我们如何改变整个行业的文化:一次一个人，通过互相关心。

你最近做了一次非常精彩的关于你职业道路的采访，引起了包括我在内的许多人的共鸣。有一件事引起了我的注意，我想问的是，对于公司来说，雇佣一名高水平的工程师是一项战略决策。你能从工程师和公司的角度告诉我们更多吗？

一个非常资深的工程师尽自己最大的努力来改变他们周围的组织。通过选择雇佣一个非常高级的工程师，一个组织就选择了它希望如何转型。这是一个重要的战略决策。当在员工工程师候选人面试小组后听取汇报时，我喜欢问这样一个问题:“雇用这个人我们能带来什么样的巨大变化，这些变化是我们想要的吗？”

一个非常高级的工程师转变组织的方法之一是通过指导主要的工程决策过程。一个新手工程师的首要任务是学会解决问题的一种方法。越来越精通的一个重要标志是设想许多备选方案以及每种方案的后果，包括质量、时间表、成本、可维护性、性能等之间的权衡。工作人员或负责人级别的工程师需要这样做，同时从整体上考虑组织的需求，包括从业务和工程的角度考虑短期和长期的问题。这部分是艺术，部分是科学，一个非常资深的工程师对这些问题的判断会对整个组织产生持久的影响。

此外，一个非常资深的工程师是一个榜样，对工程团队文化有着强大的影响。他们在组织结构图中的位置是组织的明确认可。其他人会试图模仿那个工程师的技能、习惯、实践和态度。一个非常资深的工程师自然会涉及到比任何个人能够独立完成的任务多得多的任务。他们是否通过鼓励其他工程师承担具有适当挑战性的任务来建立学习和成长？他们是否提供指导和帮助来确保那些困难的任务成功？他们公平善良吗(这和 nice 不一样！)在他们与其他工程师的互动中？这些问题的答案是推动工程团队文化演进的关键输入。

对于工程师来说，我认为重要的是要记住，作为一名职员或负责人级别的工程师，你的成功取决于对技术进步有一个坚持己见的愿景。这种愿景可以改变组织。你需要能够在组织的各个层面上工作，从高级领导到初级个人贡献者，以使愿景成为现实。你需要这样做，但不要武断；你必须认识到什么时候应该尊重他人，或者将他们的想法与你自己的结合起来，以获得比你们任何一个人单独完成的更好的结果。在我看来，这种平衡就是你在找高级工程职位时所推销的东西。

在同一次面试中，你谈到了科技面试中的“低调的性别歧视”。我认为你在这里的评论——实际上是整个采访——非常周到和重要。在面试中的性别歧视、多样性、公平&包容(DEI)方面，你看到进步了吗？还是我们仍在底线上挣扎？

我认为技术在 DEI 的各个方面都进展缓慢，而且进展分布不均。一些组织做得很好，而另一些却在苦苦挣扎。在一个组织中，通常一些团队做得很好，而另一些团队却在苦苦挣扎。做得更好的人通常有不同的领导。

获胜的组织正在努力工作，以获得能够从全体员工中雇用和留住员工的优势。他们从被边缘化的团队成员那里寻求意见，奖励提供这些意见所需要的努力，并尊重不是每个代表不足的少数群体成员都愿意花时间在 DEI 工作上。那些成功的组织也超越了他们的团队，领导者阅读和学习博客文章和文章，会议演讲，研讨会等等。

整个科技的人口统计数据仍然非常不平衡，所以一个组织可以简单地默认 DEI。如果每个人都来自基本相同的背景，那么很容易忽略你的文化中赶走与你不同的人的方面。这种粗心的结果是你不具备你原本可以拥有的天赋。建立一支多元化的员工队伍除了统计数据之外，还需要努力、意图和对个人的关注。

总的来说，无论是在 Kubernetes 和工程社区，还是在生活中，你一直都是 DEI 的倡导者。我们 Fairwinds 也致力于这些主题。除了基本原则之外，你对像我们这样的公司有什么下一步的建议来继续推进 DEI 计划，使个人和组织都受益？

感觉自己远不是这方面的专家。大多数情况下，我会试着去倾听各种各样有思想的声音。当人们分享他们的生活和技术经历时，倾听是很重要的，而不仅仅是当他们明确谈论多样性时。我从斯蒂芬·奥古斯都、埃里卡·乔伊·贝克、凯尔斯滕·布拉格、利兹·冯·琼斯、爱丽丝·戈德福斯、杰姆·莱奥米、塞奇·夏普和许多其他人的写作、演讲和推特上学到了很多东西。

我可以自信地建议组织支持和接纳来自非传统背景的人，比如转行者、训练营毕业生和拥有看似不相关学位的人。有很多方法可以解决任何特定的工程问题，来自非传统背景的人更有可能提供打破障碍的独特答案。确保你的招聘实践不会意外地将这些候选人拒之门外是很重要的，但同样重要的是，一旦你的团队中有了他们，就要积极地支持和赞助他们。技术是非常惯用的，伟大的想法可能会被忽略，如果它们没有以预期的方式呈现的话。注意这一点，确保你没有错过！

我给个人的自信建议是读读金伯利·克伦肖，这位杰出的作者提出了“交叉性”这个术语。她的作品远比“批判理论”这个词让你相信的更容易理解。如果你正在建立一个更加公正的世界，但还不熟悉克伦肖的作品，它将改变你的生活。

Fairwinds 的公司价值观是尊重、包容、同情和善良。我们每天都在努力将这些价值观融入我们的工作以及我们与同事、合作伙伴和客户的关系中。你有什么具体的价值观想带到你的工作中吗？

在我的工作中，我试图永远记住没有人的技术是没有意义的。在我的生活中，我努力体现交叉女权主义、互助和以身作则的原则。攻击和防御计算机系统自然是令人愉快的，我非常幸运能够以这种方式养活自己。当我这样做的时候，我试着提升我周围的人，成为我希望自己成为的榜样。

人们知道你会问这样一个问题，“我想知道如果我们会发生什么……”你今天会为我们回答这个问题吗？？

要回答这个问题，首先我们要问它！这里有几个例子:

“我想知道，如果我们使用公司内部根 CA 签署所有 Kubernetes 集群 CA 证书，会发生什么情况？”可能没事，也可能是灾难。如果这听起来像你的乐趣，你真的会喜欢我的 KubeCon NA 2020 talk PKI 错误的方式:简单的 TLS 错误和令人惊讶的后果。

“我想知道，如果我们都互相尊重，互相帮助发展我们的最高权力，会发生什么？”我不确定，但是那听起来很棒，我正在尽我最大的努力去发现！

数据狗市场中的 Kubernetes 配置验证

原文：https://www.fairwinds.com/blog/kubernetes-configuration-validation-in-datadog-marketplace

今天，Datadog 宣布了其新的 Marketplace，这是一个第三方应用程序开发平台，为客户提供从 Datadog 的合作伙伴网络访问各种工具、集成和服务的机会。

我们很高兴成为今天 Datadog Marketplace 发布会的一部分！fair winds Insights现已上市，允许用户主动监控他们的 Kubernetes 和容器配置，并获得提高安全性、效率和可靠性的建议。Fairwinds Insights 的发现和建议集成在 Datadog 中，使 DevOps 团队能够更高效地管理 Kubernetes 和应用程序容器。

我们是 Fairwinds 的 Datadog 的忠实粉丝，在我们的许多 Kubernetes 托管服务中使用它来确保可观察性和发现未知未知的能力。我们还有一个开源项目， Astro ，这是一个 Kubernetes 操作器，它可以根据定义的模式监视集群中的对象，并根据这种状态管理 Datadog 监视器。这种集成让更多的 Datadog 客户受益于提高的安全性、降低的成本和节省的时间。

关于 Fairwinds 的见解

Fairwinds Insights 是一个单一配置验证平台中的 5 个以上开源工具，全部与您使用的工具集成在一起。它结合了可信的开源工具、工具链集成和基于数百个成功的 Kubernetes 部署的 SRE 专业知识。

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

如何帮助

Fairwinds Insights 为三类 Kubernetes 配置问题提供了统一的多集群视图，并围绕安全性、效率和可靠性确定了补救措施的优先级。Fairwinds Insights 使得通过单个 helm 安装部署多个开源工具变得很容易。这种一次性安装有助于工程师避免安装和配置每个工具的定制工作。

DATADOG-Main Demo Dashboard

数据狗市场

Datadog Marketplace 现已面向 Datadog 应用内的所有 Datadog 客户开放，在承诺购买之前，任何应用均可免费试用两周。你可以在市场试试 Fairwinds Insights。

Kubernetes 配置验证:了解为什么它不是一个和完成

原文：https://www.fairwinds.com/blog/kubernetes-configuration-validation

如果您在生产中使用 Kubernetes，那么验证每个工作负载的配置是至关重要的。最小的变化或遗漏都可能导致停机、成本超支，甚至更糟的是安全漏洞。那么，对于 Kubernetes 配置验证，您需要寻找什么呢？

具体来说，您至少应该检查:

针对安全问题，包括超权限容器和常见漏洞与暴露(CVEs)
对于效率问题，如未设置 CPU 限制或请求过多内存
对于可靠性问题，例如，不设置活跃度和就绪度探针

**但是在进行代码审查时仅仅寻找这些东西是不够的——您应该在部署生命周期的每一步自动检查它们。如果没有一个完整的程序来验证 Kubernetes 的配置，错误肯定会被遗漏。

要保持集群健康，您需要确保检查配置:

在针对每个拉取请求和合并运行的 CI 流程中
在接纳时，随着新资源进入集群
作为对集群内资源的连续扫描

步骤 1 -通过 CI 保持健康

如果您的公司已经实施了一个成熟的 DevOps 计划，那么您将把所有的配置存储为代码形式的基础架构(IaC)。所以对你的基础设施的每一个改变都(理想地)在 Git 中被跟踪，并且通过一个代码审查过程。

代码审查是捕捉高层次问题的好方法，比如实际上不会实现业务目标的变更，或者会引入微妙的安全问题的变更。但是有很多常见的问题，查找起来很繁琐，而且很容易被忽略，比如错误配置的安全设置或缺少健康探测。

在 CI 中拥有自动化验证是补充代码审查并确保新的变更坚持一致的质量水平的一个很好的方式。通过自动完成代码审查人员的大部分死记硬背的任务，您给了他们挖掘逻辑和深入思考其影响的空间。

步骤 2 -集群的保镖

一旦拉请求(PR)被批准并且测试通过，您就可以安全地部署了。但是，如果部署做的事情与 CI 中测试的略有不同，该怎么办呢？或者更糟糕的是，如果有人通过强制推送到 Git，或者通过直接与您的 Kubernetes 集群交互，从而绕过了审查过程，该怎么办？

添加一个准入控制器是保持集群健康的重要保障。它就像是集群前门的保镖，任何不遵守策略的东西都进不去。

通常，组织会将其准入控制器配置为没有 CI 严格，以便在审查过程中可以对非关键规则进行例外处理。相反，它们只会在准入控制器中实施最严格的策略。

在完美的世界中，问题总是在开发周期的早期被发现，在它们被发送到 Kubernetes API 之前。但是即使是最严密的 DevOps 程序也有漏洞，准入控制器可以堵住。

步骤 3 -当好的工作负载变坏时

所以您的工作负载通过了 CI 流程，准入控制器也让它通过了。您的应用正在生产中运行，每个人都很高兴。你应该完成了，对吗？

不完全是。在一些情况下，以前健康的部署可能会开始恶化:

随着时间的推移，工作负载可能会发生微妙的变化。例如，如果您正在使用一个可变的 image 标记，那么您的工作负载所使用的 docker 映像可能会得到更新，而不会对您的 IaC 存储库或准入控制器进行任何更改。或者像 VerticalPodAutoscaler 这样的 Kubernetes 控制器可能会改变它的配置。
每天都有新的漏洞(CVE)公布。在进入群集之前被认为是健康的映像现在可能存在已知的可利用漏洞。
随着你的成长和成熟，你的团队将采用新的政策。这些策略需要应用于现有的工作负载以及新的工作负载。

扫描 Kubernetes 环境中已经存在的资源是确保集群长期健康的重要一步。这是您最真实地了解群集的运行状况、安全状况和策略合规性的方式。

Kubernetes 充满信心

安装这种护栏可能看起来像是一件苦差事，或者是对生产力的一种风险。我们都知道我们的工作被过分热心的 CI 系统或安全政策拒绝的痛苦。

但是当你知道你不会弄坏东西的时候，快速移动会容易得多。改变 Kubernetes 集群中的资源是很可怕的，简单的错误会导致用户愤怒、收入损失和声誉受损。合适的护栏将帮助您自信地运输，平静地睡觉。

费尔温德见解

如果您正在寻求在整个 Kubernetes 生命周期中实现策略和最佳实践的帮助，请联系我们！ Fairwinds Insights 可以帮助您在 CI、准入控制和实时扫描方面运行 Kubernetes 的最佳开源验证工具。

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

Kubernetes 控制器基础知识

原文：https://www.fairwinds.com/blog/kubernetes-controllers

如果你对 Kubernetes 不熟悉，你首先要熟悉的概念之一就是控制器。大多数 Kubernetes 用户不直接创建 Pods 相反，他们创建一个部署、CronJob、StatefulSet 或其他控制器来为他们管理 pod。

控制器基础知识

首先，这里有一些控制器的基础知识。Kubernetes 文档使用了一个例子，控制器就像你的恒温器。刻度盘的位置是它想要的状态，当前的温度是它的实际状态，恒温器不断地加热或散热以保持两者同步。这就是 Kubernetes 控制器的工作方式——它是一个循环，监视集群的状态，并根据需要进行更改，始终保持您想要的状态。

控制器可以跟踪许多对象，包括:

哪些工作负载正在运行，在哪里运行
这些工作负载可用的资源
围绕工作负载行为的策略(重启、升级、容错)

当控制器注意到实际状态和期望状态之间的差异时，它将向 Kubernetes API 服务器发送消息，以进行任何必要的更改。

控制器的类型

在我们基本的 Kubernetes 概念中，我们强调了许多 Pod 控制器，包括以下内容。然后，我们将深入研究四个最常用的控制器。

replica set——replica set 创建一组稳定的单元，所有单元都运行相同的工作负载。你几乎不会直接创建它。
部署-部署是在 Kubernetes 上获取应用程序的最常见方式。它维护了一个具有所需配置的副本集，以及一些用于管理更新和回滚的附加配置。
stateful set-stateful set 用于管理具有持久存储的有状态应用程序。Pod 名称是永久性的，在重新计划时会保留(app-0、app-1)。存储保持与替换机架相关联，当删除机架时，卷仍然存在。
作业-作业创建一个或多个短期 pod，并期望它们成功终止。
cron job——cron job 按计划创建作业。
daemon set-daemon set 确保所有(或一些)节点运行一个 Pod 的副本。随着节点添加到集群中，单元也会添加到其中。随着节点从集群中移除，这些 pod 将被垃圾收集。常见于 CNI、监控代理、代理等系统进程。

复制集

副本集是一组没有唯一标识的多个相同的 pod。复制集旨在满足两个要求:

容器是短暂的。当他们失败时，我们需要他们的吊舱重新启动。
我们需要运行一定数量的 pod。如果一个被终止或失败，我们需要新的豆荚被激活。

副本集确保指定数量的 Pod 副本在任何给定时间运行。尽管您可能永远不会直接创建副本集，但这是保持 Kubernetes 基础设施正常运行的重要部分。

部署

像复制集一样，部署是一组没有唯一标识的多个相同的 pod。但是，部署比复制集更容易升级和修补。用户可以配置推出新版本部署的策略，从而可以在最短的停机时间内推出变更。

例如，我们可以选择滚动更新策略。然后，当我们更新部署时，将会在现有副本集旁边创建第二个副本集，随着新副本集中更多的 pod 准备就绪，一些副本集将会从旧副本集中删除，直到旧副本集为空并且可以删除。我们甚至可以设置像 maxUnavailable 和 maxSurge 这样的参数来控制这种切换的机制。

状态设置

虽然部署管理无状态应用程序，但有状态集对于需要以下一项或多项功能的应用程序很有价值:

稳定、唯一的网络标识符
稳定、持久的存储
有序、优雅的部署和扩展
有序的自动滚动更新

StatefulSet 为它管理的每个 Pod 保留一个唯一的标识。每当它需要重新安排那些豆荚的时候，它使用相同的身份。

当运行 Cassandra、MongoDB、MySQL、PostgreSQL 或任何其他利用持久存储的工作负载时，建议使用 StatefulSets。它们可以在伸缩和更新事件期间帮助维护状态，对于维护高可用性特别有用。

工作

作业是短期工作负载，可用于执行单个任务。作业将简单地创建一个或多个 pod，并等待这些 pod 成功完成。工作有助于做以下事情:

运行数据库迁移
执行维护任务
旋转原木

作业还可以并行运行多个 pod，为您提供一些额外的吞吐量。

CronJob

CronJobs 只是按照用户定义的计划运行作业。您可以使用 cron 语法提供调度，CronJob 控制器将在每次调度需要时自动创建一个作业。

CronJob 控制器还允许您指定可以并发运行多少个作业，以及保留多少个成功或失败的作业用于日志记录和调试。

总结

Kubernetes 控制器允许您在集群中运行和管理您的应用程序，并且是您需要理解的核心概念之一，以便在 Kubernetes 中获得成功。

当然，在您拥有一个生产就绪的集群之前，您还需要更多。如果您正在寻找创建一个完全可操作的 Kubernetes 集群，您可以查看我们关于主题的博客帖子。或者，如果您正在学习 Kubernetes，请查看我们的 How to Kube 系列，该系列展示了 Kubernetes 在概念、工具、安全性等方面的最佳实践。

Kubernetes 成本分配:Fairwinds Insights 的更新

原文：https://www.fairwinds.com/blog/kubernetes-cost-allocation-updates-to-fairwinds-insights

Kubernetes 工作负载成本分配很难。为了说明这一点，让我们简单地看一下这个问题。

例 1

Image: Node with Application A running inside.

在第一个示例中，您在单个计算实例上运行应用程序 A。理解应用程序 A 的成本是非常简单的，因为我们知道运行它的节点的成本。

例 2

Image: One node running two instances of Application A.

在下一个示例中，您在单个计算实例上运行应用程序 A 的容器化版本。同样，计算实例的成本也很简单，即运行应用程序 a 的成本。

例 3

Image: Kubernetes cluster running 3 nodes. The first node runs two instances of Application A, one of Application B. The second node runs Application A, the third node runs Application A, B and C.

一旦您的许多应用程序被包含，并且您正在运行 Kubernetes 集群，您将在不同的节点上运行不同的工作负载(应用程序)实例。在本例中，您将在一个节点上运行应用程序 A 和 B，在另一个节点上运行应用程序 B，在最后一个节点上运行应用程序 A、B 和 c 的实例。此外，Kubernetes 调度的动态特性意味着容器化工作负载的运行位置随时可能发生变化。

所有这些变化意味着在 Kubernetes 中很难按工作负载分解成本。即使你做了，也不会保持一致。随着 Kubernetes 环境的增长，集群数量和节点数量都在增加，确定成本只会变得更加困难。

传统云工具不懂 Kubernetes

随着 Kubernetes 在组织内的使用范围扩大，如果工作负载没有按照正确的资源请求和限制进行适当配置，开支可能会失控。考虑一下 Fairwinds 博客文章中概述的“吵闹的邻居”问题。因此，必须监控支出以避免浪费资源，尤其是在成本节约措施日益重要的市场中。

虽然存在云成本监控工具(并且有一个庞大的行业围绕着它)，但这些传统工具无法识别 Kubernetes 的多层、动态环境以及它们所运行的工作负载和节点之间的细微差别。

大多数开发运维团队缺乏对集群中实际发生的事情、正确配置的内容以及是否过度配置的了解。如果您的组织采用了 FinOps 模型，其中财务团队与开发人员和开发人员一起工作，许多人甚至可能缺乏诊断 Kubernetes 成本管理问题的知识。

增强的 Kubernetes 工作负载成本分配精确定位云支出

由于 Kubernetes 很复杂，团队缺乏对支出的可见性，Fairwinds 花费了大量时间来增强我们的 Kubernetes 治理软件 Insights 中的成本功能。

平台工程团队需要做两件事的能力:

在与业务相关的环境中分配和显示成本
创建工程反馈循环，以实现服务所有权和成本规避的文化

Fairwinds Insights 的增强功能允许平台工程经理使用实际的云支出和工作负载使用情况来了解跨多个集群、聚合和自定义时间段发生的历史成本。

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

与传统的成本分配解决方案不同，Fairwinds Insights 包括策略执行功能，因此平台工程师可以自动执行成本分配所需的元数据标准。

Kubernetes 工作负载成本分配的用例

最新功能的一些使用案例包括:

累积工作负载成本报告:根据使用情况查看历史工作负载成本，以提供预定义时间段内发生的成本摘要:前一天、前一周或前一月。
跨团队的精确成本分配:将累积的历史工作量分配给不同的团队。成本通常按工作负载和命名空间划分。使用成本分配功能，按节点、共享(例如，一组公共系统名称空间，如 kube-system)和空闲容量，对各个团队和分解成本进行“计费”。
报告跨多个集群的名称空间的开销:报告跨多个集群的名称空间的总开销。例如，要了解 my-app 命名空间在整个企业中的总成本，需要获得该命名空间在临时集群和生产集群中的总成本。

这一最新增强解决了这些使用案例以及更多问题。该软件的用户可以对 Kubernetes 采用 FinOps 方法，并受益于:

多集群:简化工作流程通过利用 Fairwinds 的可扩展 SaaS 架构，在一个位置计算和汇总所有集群的成本数据
多聚合分配:在多个维度上分配成本，比如集群、名称空间、种类等。
合理调整建议:通过调整 CPU 和内存请求来确定成本节约
历史报告:跨自定义时间段报告成本，数据保留期长达 13 个月
云计费集成:集成您的 AWS 成本和使用报告(CUR ),使用您的实际云支出进行准确的成本分配

要了解有关 Fairwinds Insights 的更多信息，请致电我们的团队。

精确的 Kubernetes 成本监控和管理

原文：https://www.fairwinds.com/blog/kubernetes-cost-monitoring

了解云的成本以及云消费的所有子集正成为 DevOps 领导者越来越多的要求。事实上，FinOps 已经成为组织寻求在商定的指标下联合财务和工程团队的关键词。

Kubernetes 属于“子集”范畴。但是 Kubernetes 的成本监控很难。这是一个不断变化的环境和工作负载，需要大量配置。不幸的是，由于这个原因，Kubernetes 的成本监控做得不好的团队并不多。此外，很难理解应用程序实际消耗了哪些资源，以及是应用程序还是应用程序的配置方式过度消耗了云资源。

为什么要在 Kubernetes 中衡量成本？

对于那些采用了容器和 Kubernetes 的组织来说，成本监控很快成为平台工程领导和财务团队的黑洞。关于支出的最大问题是:

成本分配:我要花多少钱？该成本应该如何在团队、应用程序和业务单元之间划分？
服务所有权:我的团队是否能够监控其应用的成本并做出改变以降低成本？
合理调整资源:我的应用程序是否过度调配，使用了过多的计算或内存？

Kubernetes 的分配、优化和管理是理解和了解相关成本。

Kubernetes 成本监控的挑战

对许多人来说，Kubernetes 成本监控的挑战始于其配置方式:

开发人员是否设置了正确的 CPU 和内存？
什么应用程序的成本最高，为什么？
能否按 Kubernetes 分解云成本，然后逐步细化？

作为一家快速发展的初创公司，我们需要一种方法来更好地了解我们微服务的成本，尤其是当客户开始采用 Fairwinds Insights 的各种功能时。第一步实际上还没有测量成本；相反，我们开发了开源工具 Goldilocks ，以确保我们的工作负载配置了正确的 CPU 和内存分配。这一步对于保证我们不会向最常用的微服务过度或不足地调配资源至关重要。

一旦我们设置了我们的请求和限制，我们发现我们的传统云成本工具没有按照 Kubernetes 工作负载、名称空间或标签进行细分。这种认识使得我们很难了解哪些微服务或功能在推动集群中的大部分资源利用率，以及这些功能是否对我们有利。

在我们的客户和社区对话中，我们意识到我们并不孤单。我们在 Fairwinds Insights 中开发了 Kubernetes 成本分配功能，允许我们为为我们的集群供电的节点配置每小时混合价格。有了这些信息，并使用 Prometheus 指标跟踪实际的 pod 和资源利用率，我们就能够生成工作负载的相对成本。这一举措帮助我们跟踪了我们的云支出，同时还确定了哪些功能会影响成本。

平台工程团队，尤其是那些已经接受了 Kubernetes 服务所有权的团队，也被问及单个团队和产品的成本。这些请求最终来自财务主管，他们需要了解运行不同产品的边际成本。服务所有者还可以使用这些信息来做出自己的资源利用决策，并找到节省资源和成本的方法。

在一个地方监控和管理您所有的 Kubernetes 费用

当 Kubernetes 用作多租户/共享计算环境时，准确的 Kubernetes 成本分配变得越来越复杂。不同的团队可能使用不同的节点类型，并且工作负载不断变化，这使得节点的每小时价格成为一个移动的目标。

我们很高兴地宣布，Fairwinds Insights 现在支持 AWS 计费集成，允许团队使用他们的真实云账单来按工作负载、名称空间或标签计算成本。有了标签，平台工程团队可以通过多个业务维度“切割”精确的工作负载成本，满足服务所有者和财务的需求，而无需质疑底层节点定价假设。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

Kubernetes CVE-2020-8554:识别您是否受到影响的说明

原文：https://www.fairwinds.com/blog/kubernetes-cve-2020-8554-instructions-identify-impacted

一个新的中等严重程度的 CVE 被发现(CVE-2020-8554)影响多租户库伯内特星团。如果潜在的攻击者已经可以创建或编辑服务和 pod，那么他们可能能够拦截来自集群中其他 pod(或节点)的流量。关于 CVE 的公告解释说:

能够创建 ClusterIP 服务并设置 spec.externalIPs 字段的攻击者可以拦截到该 IP 的流量。能够修补负载平衡器服务的状态(这被视为特权操作，通常不应授予用户)的攻击者可以将 status.loadBalancer.ingress.ip 设置为类似效果。

这个问题是一个设计缺陷，如果不进行面向用户的更改，就无法缓解。"

与任何 CVE 一样，第一步是确定您是否受到影响。为了帮助 Kubernetes 用户，我们使用我们的配置验证软件fair winds Insights(免费使用 30 天)和 OPA 创建了识别 CVE-2020-8554 的说明。按照这些说明，您不需要以前使用过 OPA。此外，通过使用 Insights 准入控制器，您实际上可以防止这种 CVE 被引入到新部署中。

Fairwinds Insights 是一个策略驱动的平台，可强制执行自定义策略，如识别集群中的 CVE，通过在 CI/CD 阶段或作为准入控制器的开放策略代理(OPA)集成，自动部署护栏和安全最佳实践。

在集群中识别 CVE-2020-8554 的说明

注册 Fairwinds Insights

如果你是 Fairwinds Insights 的新手，你需要注册并安装代理——遵循入门指南。

安装 Insights-cli

遵循 Insights CLI 安装指令。

如果在 mac 上，运行 brew install FairwindsOps/tap/insights
如果不是在 Mac 上，或者没有自制软件，从版本页面下载二进制文件，并将其添加到您的路径中

复制示例策略

下载洞见-插件资源库。在该存储库内的路径 plugins/opa/examples 中，您将找到所有用于 Fairwinds Insights 的模板化 OPA 策略。将 plugins/opa/examples/lb-vuln-cve-2020-8554 复制到你的本地目录。

查看 Fairwinds Insights 文档了解有关 OPA 政策的更多信息。

找到您的管理令牌

登录fair winds Insights，选择您的组织，然后点击菜单栏中的设置。向下滚动到认证令牌部分，并单击 Show Tokens 按钮。复制标题为 admin 的令牌，打开命令提示符，粘贴到: export FAIRWINDS_TOKEN= <token you copied>

运行命令

从您复制策略的目录中，运行以下命令: insights policy sync --organization <Insights org name>

安装 OPA 报告

登录并导航至您想要检查的集群。从那里开始，遵循以下步骤:

screenshot of OPA No reports - Apply custom policies to Kubernetes resources - available

导航至报告中心菜单
添加开放策略代理(OPA)报告
您将在屏幕的右上角看到一个“准备重新安装”链接。单击此链接获取可用于重新安装 Fairwinds Insights 代理的 helm 命令。

大约一分钟后，您应该会在 Fairwinds Insights 的行动项目表中看到任何受影响的资源。

Screen shot of Fairwinds Insights Action Items

借助 Fairwinds Insights，您将能够识别并防止 CVE-2020-8554 成为您团队的问题。您可以永远免费使用 Fairwinds Insights。拿过来这里。

库贝内特斯·CVE，Symlink Exchange:识别作为根运行的容器

原文：https://www.fairwinds.com/blog/kubernetes-cve-symlink-exchange-identify-containers-running-as-root

符号链接交换可以允许主机文件系统访问

在 Kubernetes 中发现了一个严重程度很高的安全问题( CVE-2021-25741 )，用户可以创建一个带有子路径卷装载的容器来访问卷外部的文件和目录，包括主机文件系统上的文件和目录。

虽然此漏洞被评为高严重性，但它需要预先存在的权限和访问权才能被利用。如 CVE 所述，阻止容器以 root 用户身份运行将会降低成功实施 CVE 的影响。

该问题会影响以下 Kubernetes 版本中的 kubelet:

< =v1.19.14

版本 1 . 22 . 0-版本 1.22.1

1.21.0 版-1 . 21 . 4 版

版本 1 . 20 . 0-版本 1.20.10

如果您想在不升级到 Kubernetes 的补丁版本的情况下缓解该问题，可以在引发 Github 问题的中找到缓解步骤。

如何识别 Kubernetes 容器是否以 root 用户身份运行

用户应遵循缓解步骤。此外，识别以 root 身份运行的容器也很重要，因为这不仅仅是 CVE 的问题。

如果你有一两个集群，你可以使用 Fairwinds 的开源工具 Polaris 。这将帮助您确定是否有任何容器在根位置运行，以便您可以做出正确的修复。

如果您有多个包含许多容器的集群，这就变得更加复杂了。人工审计需要时间。使用 Fairwinds Insights ，您可以通过仪表板视图查看跨多个团队的多个集群，了解哪些容器作为根运行。它包括补救建议，因此您的团队可以快速做出这些更改。通过连续扫描这些集群，您将能够看到何时进行了修复。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

Kubernetes DevOps 提示 5:为什么将 imagePullPolicy 设置为 Always 比您想象的更有必要

原文：https://www.fairwinds.com/blog/kubernetes-devops-tip-5-why-setting-imagepullpolicy-to-always-is-more-necessary-than-you-think

这篇博客将讨论围绕 Kubernetes 容器的 Pull 策略的更好实践的需求，该策略是使用 pod 规范中的 imagePullPolicy 字段设置的。当imagepulpolicy设置为 Always 时，用户可以确保每次启动 Kubernetes pod 时都部署最新版本的映像。

依靠缓存版本

依赖缓存版本的 Docker 图像会引入安全漏洞，因为 Kubernetes 会试图使用缓存版本的图像，而不验证它来自哪里。如果攻击者能够替换缓存的图像，并且 imagePullPolicy 被设置为 IfNotPresent ，那么 Kubernetes 将很乐意运行您放在节点上的任何图像。此外，不使用 Always pull 策略会导致每个节点上运行的映像发生变化。

例如，许多项目会发布带有图像标签 1 、 1.2 和 1.2.3 的版本 1.2.3 。关于 Kubernetes 配置，可以指定标签 1.2 ，因此当 1.2.4 发布安全补丁时，它会在下次重新安排或重启 pod 时自动流入。但是，如果用户没有指定imagepulpolicy:Always，那么 Kubernetes 集群将继续使用缓存的 1.2 标签，该标签仍然指向 1.2.3 。

为了解决这个问题，Kubernetes 使用了 imagePullPolicy 。根据 Kubernetes 文档和配置最佳实践，当 imagePullPolicy 设置为 Always 时，kubelet(也称为主“节点代理”)将查询容器映像注册表，以便在每次启动容器时将名称解析为映像摘要。

如果 kubelet 有一个包含本地缓存的精确摘要的容器图像，它就使用它的缓存图像。否则，kubelet 下载(或提取)带有解析摘要的图像，使用该图像启动容器。这里需要注意的是，将 imagePullPolicy 设置为 Always 不会绕过本地容器缓存机制，它只是验证缓存是否与上游源匹配。这意味着这种配置几乎没有缺点。

通过洞察力获得正确的设置

您可以通过确保将imagepulpolicy设置为 Always 来避免图像问题。当然，您的团队可以手动检查这个策略，但是这项工作会占用应用程序开发的时间、精力和资源。相反，您可以使用配置验证软件，如fair winds Insights，来自动检查您的 imagePullPolicy 。

为了解决这个问题，Insights 会在未指定标签时触发警告，或者如果imagepulpolicy未正确设置为 Always 。然后，您的团队可以修复清单，避免应用程序停机、错误等问题。

Fairwinds Insights 还可以贯穿您的整个部署流程，这意味着从 CI/CD 到生产，始终会验证 imagePullPolicy 。

Fairwinds Insights 将通过扫描 CI 中的基础架构代码，并在 Kubernetes API 前作为准入控制器运行，从一开始就阻止这些工作负载进入您的 Kubernetes 集群。

有兴趣尝试见解吗？它可以免费使用。你可以在这里报名。安装 Fairwinds Insights 代理后，您将在 5-10 分钟内找到结果。您可以轻松地检查是否有超过许可的容器，以及其他可靠性问题，如缺少准备就绪或活性探测器。

Kubernetes DevOps 技巧 7:开发与生产中的维修成本

原文：https://www.fairwinds.com/blog/kubernetes-devops-tip-7-cost-of-repair-in-development-vs.-production

Kubernetes 的主要好处之一是该平台能够提高开发速度。通过使用微服务和容器，开发进行得更快。这都是好消息，而且肯定是巨大的好处。但是当你增加开发速度时，一个主要的缺点出现了:修复缺陷的成本。

下面的 Capers Jones 图显示了在开发生命周期的每个阶段引入的缺陷的百分比。更重要的是，它展示了修复所述缺陷的成本如何从编码时的 1 倍增加到生产中的 640 倍以上。

image of Carper Jones graph showing percentage of defects

修复 Kubernetes 的错误配置可能会很昂贵

正如解决代码问题代价高昂一样，Kubernetes 的错误配置也是如此。当启动集群以支持应用程序时，只需要完成并运行一些配置。您需要:

避免以 root 用户身份运行容器，以确保 Kubernetes 的安全性
设置合适的 CPU 和内存来控制云成本
设置活动和就绪探测器，以确保正确的自动缩放

大多数公司在运行 Kubernetes 时都没有考虑到配置最佳实践，这造成了安全性和可靠性问题，增加了技术债务，而且修复起来可能非常昂贵。

修复 Kubernetes 错误配置集群的成本

Kubernetes 配置基准报告给出了每个集群和工作负载的平均结果:

每个集群的平均 Kubernetes 错误配置数- 328
每个 Kubernetes 集群的平均工作负载数- 110
每个工作负载的平均调查结果数- 3

现在考虑一下基于 DevOps 工程师成本的这些数字:

DevOps 工程师每小时收费 100 美元
编码阶段的修复成本(5 分钟)-8.33 美元
修复工作负载的成本 Kubernetes 在 Git 拉取请求时的错误配置——24.85 美元
修复生产中工作负载配置错误的成本-15，903.03 美元。

让我们再读一遍:15903 美元！！！！！！

在考虑如何配置 Kubernetes 时，您必须考虑在生产前环境中正确配置。您需要首先确保错误配置不会渗透到生产中。

如何及早识别 Kubernetes 错误配置

Fairwinds 使组织能够更早地转移配置验证，从而将修复成本降低高达 640 倍。我们通过为您的集群提供连续和自动扫描来获得 Kubernetes 最佳实践。我们的解决方案可以扫描您的开发环境，提醒开发人员错误配置，并向他们展示如何修复问题——这是一项 5 分钟的任务，成本为 8.33 美元！

Fairwinds Insights 准入控制器将拒绝任何 Kubernetes 资源进入您的集群，如果它们不符合您的组织的政策。再次帮助您将生产环境的维修成本从 15，000 美元降至 8-25 美元。

不要因为没有正确配置而失去 Kubernetes 的好处。Fairwinds Insights 可供免费使用。你可以在这里报名。

Kubernetes 已解决:使用 Pluto 很容易找到已弃用的 API 版本

原文：https://www.fairwinds.com/blog/kubernetes-easily-find-deprecated-api-versions-with-pluto

Pluto 是一个开源工具，可以帮助用户在他们的基础设施即代码仓库和 Helm 版本中轻松找到不推荐的 Kubernetes API 版本。

Kubernetes API 版本化方案对开发人员来说非常好。它允许 Kubernetes 团队轻松地向 alpha 和 beta API 路径发布新特性，并在经过实战测试后将它们升级到稳定路径。当这种情况发生时，旧版本被弃用，最终将被删除。这引发了许多围绕 Kubernetes 1.16 升级的讨论，其中删除了多个不赞成使用的Deployment资源版本(除此之外，在这里阅读更多)。找到被否决的版本是很痛苦的，你将被阻止升级到 1.16，直到它们都被更新。我们决定编写一个开源实用程序，冥王星(以废弃的行星命名)，来解决这个问题。

背景

kube-apiserver 非常灵活，不管请求中指定的 API 版本如何，它都会提供关于给定资源类型的相同信息。例如，在运行 Kubernetes 1.15.X 时，您可以运行以下命令来查看各种 API 版本的部署:

$ kubectl get deployments.v1beta1.apps rbac-manager -o yaml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: rbac-manager
...

$ kubectl get deployments.v1beta2.apps rbac-manager -o yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: rbac-manager
...

$ kubectl get deployments.v1.apps rbac-manager -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rbac-manager
...

$ kubectl get deployments.v1beta1.extensions rbac-manager-o yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: rbac-manager
...

您会注意到，所有这些命令都返回相同的对象，但是将apiVersion设置为您在请求中请求的值。这使得无法判断实际部署到服务器上的是哪个版本，从而在升级时导致问题。当您有很多应用程序部署到您的 Kubernetes 集群时(就像我们的许多客户端一样)，集群升级到 1.16 版本可能会中断部署过程，可能会跨越数百个存储库。我们需要一种提前提供这些信息的方法，以便在升级发生之前解决部署过程。

Pluto 识别弃用的 Kubernetes 文件

进入冥王星。您可以使用 Pluto 扫描各种来源的废弃 API 版本，包括平面清单文件、来自helm template命令的 stdout，或者甚至直接与您的集群交互(如果您使用 Helm 进行部署的话)。例如，下面是使用 Helm 3 (Pluto 也支持 Helm 2)部署应用程序的集群扫描:

 $ pluto detect-helm --helm-version 3
KIND          VERSION        DEPRECATED   RESOURCE NAME
StatefulSet   apps/v1beta1   true         audit-dashboard-prod-rabbitmq-ha
Deployment    apps/v1        false        goldilocks-controller
Deployment    apps/v1        false        goldilocks-dashboard

Pluto 告诉你你的audit-dashboard-prod-rabbitmq-ha StatefulSet是通过 Helm 用一个废弃的 API 部署的。现在，在 1.16 上部署之前，可以更容易地在图表存储库中定位和修复这个问题。

在升级到 1.16 之前，您可以使用 Pluto 验证在集群中运行的 Helm 图表、YAML 清单和 Helm 部署，并更新任何不推荐使用的 API。一旦冥王星通过，你就可以迁移到 1.16 版了。

Pluto 现在是开源的，将被更新以包括 Kubernetes 的未来版本和对资源 API 的任何弃用。我们正在努力增加功能，所以请打开问题，加入我们的 Slack 频道，并做出贡献！

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

资源

Kubernetes emptyDir 与 Docker 的 volumes 不同-from

原文：https://www.fairwinds.com/blog/kubernetes-emptydir-not-the-same-as-dockers-volumes-from

我当前的客户有一个与 Nginx 紧密耦合的 Rails 应用程序。这种耦合非常常见，用于避免静态文件由 Rails 堆栈提供服务。在这方面最值得注意的文件是应用程序资产。使用类似 rake assets:precompile的命令将资产创建为应用程序的一部分。那些资产是特定于代码的特定版本的。

我之前使用过 docker 的 --volumes-from 在 sidecar 风格的容器间共享文件，效果相当好。令我惊讶的是，我发现 Kubernetes 没有这个特性的直接模拟。Kubernetes 提供各种类型的卷，其中最接近的是 Kubernetes emptyDir。然而，Kubernetes 中的 emptyDir 并不等同于 docker 的 --volumes-from。

它有什么不同

在 Docker 中， --volumes-from 通过 --volume直接连接到另一个容器共享的空间。确切地说，如果您用 docker run--name app --volume /app/assets <app image>运行一个容器，那么您可以从另一个容器访问 /app/assets中的数据，如下所示 docker run --name nginx --volumes-from app:/app/assets <nginx image>。这将允许 nginx 容器直接访问 app 容器中的资产。库伯内特的 emptyDir 并没有创造出这样的直接联系。相反，它创建了一个空目录(是的，这个名字暗示了这一点)，然后这个目录在容器中变得可用。它看起来是这样的:

---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  labels:
    app: test
  name: test
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: test
    spec:
      # here we set up the empty directory
      volumes:
      - name: shared-assets
        emptyDir: {}
      containers:
      - name: app
        image: app
        volumeMounts:
        - name: shared-assets
          mountPath: /app/assets
      # the nginx container
      - name: nginx
        image: nginx
        volumeMounts:
        - name: shared-assets
          mountPath: /app/assets

从表面上看，这非常相似。事实上，Kubernetes emptyDir 方法似乎有一个额外的好处，即允许挂载位于容器中的不同位置。例如，您可以将 nginx 改为在 /flubble/monkey 中挂载共享资产。这对于 Docker 方法是不可行的。

如果在连接 emptyDir的位置有数据，问题就出现了。假设你已经在 /app/assets中有了要分享的文件。当您创建 emptyDir 并将其附加到 app 容器时，它将具有与在包含数据的目录顶部挂载相同的效果。这与您将在 Linux 命令行上看到的行为相同。实际上，现有文件被屏蔽并隐藏起来。这显然是不可取的。

如何让它工作

绕过这个限制的一个简单方法是将共享文件复制到 emptyDir 位置。上述部署将如下所示:

---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  labels:
    app: test
  name: test
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: test
    spec:
      # here we set up the empty directory
      volumes:
      - name: shared-assets
        emptyDir: {}
      containers:
      - name: app
        image: app
        volumeMounts:
        - name: shared-assets
          ### the new location
          mountPath: /app/shared-assets
      # the nginx container
      - name: nginx
        image: nginx
        volumeMounts:
        - name: shared-assets
          mountPath: /app/assets

这样会将 /app/shared-assets 链接到 app 容器中的 emptyDir ，这样就可见 nginx 容器中的 /app/assets了。这将仍然是空的。要填充这个空间，您需要将 app 容器中的资产从它们自然存在的位置复制到链接到 emptyDir的位置。对此，以下内容就足够了:

cp -r /app/assets/ /app/shared-assets/

潜在的缺点和替代方案

这是创建 sidecar 的一个非常简单的方法，它从另一个容器中访问文件。然而，它确实给容器启动增加了额外的步骤和时间。根据需要复制的空间大小，对于您的用例来说，这可能是也可能不是一种合理的方法。还有其他几种选择。

网络资产可以被转移到另一个服务上，比如 S3(T2)或 T4()的 CDN。这可以完全消除对 nginx 容器的需求，这取决于用例。
可以扩展构建过程，将文件直接放入另一个容器。这将消除部署集装箱边车风格的需要，并开辟了单独扩展每个部分的可能性。

在我的紧耦合用例中，除了用例之外，还需要额外的重写等等，这是最简单的方法。它还为应用程序在 Kubernetes 之外的运行方式提供了很好的对等性。当许多其他重大变化正在发生时，很难夸大这种熟悉的价值。资源消耗也非常低，这使它成为一个简单的选择。我们可能会在未来考虑替代方案，但目前这是一个可靠的方法。

我的 Kubernetes 环境准备好迎接假期了吗？

原文：https://www.fairwinds.com/blog/kubernetes-environment-ready-holiday-season

今年的假日购物者将在网上购物。由于几乎没有去商店的动机，Covid 限制和仍然使这个假期特别的压力，预计电子商务将会飙升。我之前写过为什么 Kubernetes 会对电子商务零售商产生影响；那么那些在过去一两年里采用 Kubernetes 的团队呢？

你的环境准备好迎接购物者的涌入了吗？你能在不破产的情况下自动缩放吗？你有适当的限制吗？安全呢？系统能应对 DDoS 攻击吗？

如果你对以上所有问题的回答都是肯定的，那么恭喜你！Kubernetes 是复杂的，拥有应对日益增长的购物需求的可靠性当然值得一片喝彩。

如果这些问题中的任何一个让你犹豫，那是完全可以理解的。阿迪达斯平台工程师 Daniel Eichten 在之前的 KubeCon 上解释了他的 Kubernetes 之旅，“有时是一种爱的关系，有时只是仇恨，也很随机，很少是什么$%!!"

Kubernetes 围绕持续开发、快速扩展和更高的可靠性创造了许多优势。但是，如果你是 Kubernetes 的新手，刚刚完成了为假期做准备的转变，或者甚至是经验丰富的专业人士，你可能需要一些帮助。

Kubernetes 审核并改进

在你的季节性代码冻结之前，如果你的 Kubernetes 环境被检查以确保你的网站的稳定性，你可能会更有信心。

Fairwinds 创建了 Kubernetes Audit and Improve 来帮助电子商务零售商的 DevOps 团队识别可能导致网站崩溃的弱点。

服务和软件的结合，Kubernetes Audit and Improve审核您的 Kubernetes 环境，根据既定的最佳实践提供改进计划，并提供持续验证，以增强安全性、效率和可靠性。

我们的 Kubernetes 专家团队将使用专门构建的自动化功能，审核您的环境，提出改进建议，并在实施变更时通过 Slack 为您的团队提供支持。

没有时间进行审计？

如果您的代码冻结迫在眉睫，但您仍然希望对您的系统充满信心， Fairwinds Insights 可以根据可靠性配置扫描您的环境。Kubernetes 可靠性的核心是主动识别所需更改的能力，包括设置资源请求和限制，使用代表应用程序负载的指标自动扩展 pod，以及使用活跃度和就绪性探针。Fairwinds Insights 是一款 SaaS 解决方案，位于您的系统之外，审核您的配置并提供带有补救建议的行动项目，以帮助您提高应用程序的可靠性。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

了解更多关于 Fairwinds Audit 和改进和 Fairwinds Insights 的信息，帮助您满足今年假期的需求。

Kubernetes 专家问答预录虚拟会议

原文：https://www.fairwinds.com/blog/kubernetes-expert-qa-pre-recorded-virtual-session

环保的 Ep.2 |为假人设计的 Kubernetes

原文：https://www.fairwinds.com/blog/kubernetes-for-dummies

Kubernetes 治理:什么是 OPA，为什么要关注？

原文：https://www.fairwinds.com/blog/kubernetes-governance-what-is-opa

政策和治理是 Kubernetes 空间中经常出现的术语，但是我们实际上是如何做的呢？这就是开放策略代理(OPA)的用武之地。OPA 是一种工具，它允许我们通过使用减压阀语言将策略定义为代码来设置防护栏。

使用开放策略代理，我们可以创建的策略类型的一些示例包括:

阻止部署到特定的名称空间
限制我们可以从哪些容器库中提取图像
设置部署的最小副本数量以增强可靠性
当主机名太长时，阻止使用重复的主机名进行访问
围绕安全性、可靠性等实施最佳实践

通常，组织会试图通过使用某人创建的遵循 Kubernetes 最佳实践的模板来建立一个松散的策略和治理系统。然后，他们将与团队的其他成员分享它，假设没有人冒险离开这个模板，那么一切都将正常工作。不幸的是，现实情况是部署的东西确实偏离了该模板，如果攻击者由于凭据受损而设法进入集群，您可以肯定他们不会遵守您的模板，因为他们会部署额外的映像或安全配置来允许他们访问更多信息。

Kubernetes 中的准入控制器

OPA 本身实际上不能阻止资源进入 Kubernetes 集群。这就是准入控制器适合的地方。准入控制器是 Kubernetes API 中决定是否允许资源进入集群的最后一项检查。OPA 与准入控制器一起工作，让它知道试图进入集群的资源是否符合我们已经定义的策略。如果是，那么资源将被应用到集群。如果没有，资源就会被阻塞。

示例规则

notInNamespace[actionItem] {
    # List Kubernetes namespaces which are forbidden.
    blockedNamespaces := ["default"]

    namespace := blockedNamespaces[_]
    input.kind == "Pod"
    input.metadata.namespace == namespace

    actionItem := {
        "title": "Creating resources in this namespace is forbidden",
        "description": “This pod is forbidden from the specified namespace”,
        "severity": 0.7,
        "remediation": "Move this resource to a different namespace",
        "category": "Reliability"
    }
}

对于上面的 OPA 策略，我们看到了一个名为 notInNamespace 的规则。notInNamespace 规则有许多条件，所有这些条件都列在花括号中。为了阻止资源进入集群，所有这些条件必须评估为真。让我们来看看它们:

第一个和第二个条件 blockedNamespaces := ["default"]，以及 namespace:= blocked namespaces[_]，定义了我们希望阻止的名称空间列表。在这种情况下，它只是默认的名称空间。
第三个条件 input.kind == "Pod ",检查我们试图应用到集群的资源是否是一个 Pod。如果是，我们将继续评估条件，如果不是，它将通过此策略并自由进入集群。
下一个条件 input . metadata . namespace = = namespace 根据禁止的名称空间列表检查 pod 的名称空间。如果 pod 名称空间不在禁止列表中，那么它将通过该策略，并可以进入集群。如果不是，它将继续评估规则。
这条规则的最后一条只有在前面的所有条件都为真时才会被计算。一个单元正试图进入集群，它希望部署到我们禁止的名称空间。此时，它将创建具有适当描述、标题、严重性、补救和类别的操作项，因为此规则捕获了试图部署到禁止的名称空间的 pod。

从这里开始，准入控制器需要以某种方式进行配置，以知道应该阻止什么。这就是 Fairwinds Insights 和 T2 OPA 合作得很好的地方。在上面列出的操作项示例中，我们使用操作项和严重性的概念来告诉准入控制器在 OPA 的具体实现中应该阻止什么。任何高于 0.7 的严重性都会被阻止，任何低于 0.7 的严重性只会在 Insights 平台中创建一个操作项。

Fairwinds Insights 和 OPA/准入控制器

那么什么是 Insights，它如何连接准入控制器和开放策略代理？

Insights 是一个围绕 Kubernetes 中的安全性、可靠性、效率、成本和节约信息的平台。该平台使用各种插件，大部分是开源的，来收集集群或 CI 管道中的信息。这些操作项可以自动向 Slack 发送信息，在吉拉创建票据，或者向 PagerDuty 发送警报。UI 还提供了一种登录和查看集群和成本信息的方式。

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

在 Insights 中设置准入控制器的方式会导致严重性为 0.7 或更高(高或关键)的操作项被阻止。在上面的规则中，如果 pod 试图部署到禁止的名称空间，我们创建了严重性为 0.7 的操作项，因此在这种情况下，pod 将被拒绝进入集群。

Kubernetes 如何:确保 imagePullPolicy 设置为 Always

原文：https://www.fairwinds.com/blog/kubernetes-how-to-ensure-imagepullpolicy-set-to-always

依赖缓存版本的 Docker 映像可能会成为一个安全漏洞。默认情况下，如果图像尚未缓存在试图运行它的节点上，将会提取该图像。这可能会导致每个节点上运行的映像发生变化，或者可能提供一种无需直接访问 ImagePullSecret 即可访问映像的方法。

例如，您可能会故意覆盖一个特定的标记，并希望您的工作负载引入这些更改。更具体地说，许多项目将发布带有图像标签 1 的版本 1.2.3 、 1.2 和 1.2.3 。在 Kubernetes 配置中，您可以只指定标签 1.2，这样当 1.2.4 发布了一个安全补丁时，它会在下次重新安排或重启 pod 时自动流入。但如果不指定imagepulpolicy:Always，集群将继续使用缓存的 1.2 标签(仍然指向 1.2.3 )。

为了克服这个问题，Kubernetes 使用了 imagePullPolicy 。当设置为 Always(imagepulpolicy:Always)，“每次 ku elet 启动一个容器时，ku elet 都会查询容器映像注册中心，将名称解析为映像摘要。如果 kubelet 有一个容器图像，其中包含本地缓存的精确摘要，则 kubelet 使用其缓存的图像；否则，kubelet 下载(拉取)带有已解析摘要的图像，并使用该图像启动容器。来源: Kubernetes 文档。

确保 imagePullPolicy 设置为“始终”

通过确保将 imagePullPolicy 设置为 Always，避免图像出现问题。您的团队当然可以手动检查该策略，但这需要花费您的应用程序的时间和精力。相反，使用像 Fairwinds Insights 这样的配置验证软件来自动检查你的 imagePullPolicy 。Fairwinds Insights 会在未指定标签或未将 imagePullPolicy 设置为 Always 时触发警告。然后，您的团队可以轻松地修复清单，帮助避免应用程序出现问题(停机、错误等)。

Fairwinds Insights 还可以贯穿您的整个部署流程，因此从 CI/CD 到生产， imagePullPolicy 始终是指定的。虽然这篇博客文章讨论了如何识别违规工作负载，但 Fairwinds Insights 也有助于通过扫描 CI 中的基础架构代码，并在 Kuberenetes API 前作为准入控制器运行，从一开始就防止这些工作负载进入您的集群。

通过舵图创建账号，创建集群安装代理可以免费试用。一旦安装了 Fairwinds Insights 代理，您将在 5-10 分钟内获得结果。您可以轻松检查超过许可的容器以及其他可靠性问题，如缺少就绪或活性探测器。

Kubernetes HPA 使用自定义和外部指标进行自动扩展——使用 GKE 和堆栈驱动指标

原文：https://www.fairwinds.com/blog/kubernetes-hpa-autoscaling-with-custom-and-external-metrics-using-gke-and-stackdriver-metrics

Kubernetes 部署自动扩展更令人兴奋，因为 HorizontalPodAutoscaler 可以根据自定义和外部指标进行扩展，而不是像以前那样简单地扩展 CPU 和内存。

在这篇文章中，我将回顾 HPA 是如何工作的，自定义和外部指标 API 是什么，然后看一个例子，在这个例子中我配置了 Kubernetes deployment 基于外部 Nginx 指标自动扩展应用程序。

背景

卧式吊舱自动缩放器如何工作

**HPA 被实现为控制回路。这个循环每 30 秒向 metrics api 发出一个请求，以获取当前 pod 指标的统计信息。然后，它会计算当前 pod 指标是否超过其任何目标值。如果是这样，它会增加部署对象的数量。我认为这篇关于自动缩放器的自动缩放算法的文档非常值得一读。

实际上，HPA 控制器从三个不同的 API 获得指标:metrics.k8s.io、custom.metrics.k8s.io和external.metrics.k8s.io、。Kubernetes 很棒，因为你可以扩展它的 API，这就是这些度量 API 的设计方式。资源指标，即metrics.k8s.io API，是由指标服务器实现的。对于自定义和外部指标，API 由第三方供应商实施，或者您可以自己编写。目前我所知道的 prometheus 适配器和 custom 和 stackdriver 适配器都实现了自定义和外部度量 API。详情请查看主题上的这些 k8s 文档。

基于外部指标的扩展示例

下面是我创建的一个例子，它使用来自 Stackdriver 的指标来扩展在 GKE 集群上运行的 Kubernetes 部署。然而，我没有使用 Stackdriver 默认拥有的指标，而是将外部指标从 Nginx 指标传送到 Stackdriver，然后使用这些指标来扩展我的应用程序。下面我描述了我实现这个目标的步骤。本回购对此有示例代码。

设置步骤:

创建 GKE 集群(> 1.10 版)
启用 Stackdriver 监控(创建 stackdriver 帐户)

我的目标是添加一个水平 pod 自动缩放器，它将根据 HPA 从 Stackdriver 获得的 Nginx 外部指标来缩放我的部署。

以下是我为此采取的高级步骤:

确认度量服务器正在 Kubernetes 集群中运行。
部署实现定制和外部度量 API 的外部度量服务器。
部署一个 nginx 入口控制器，带有一个 sidecar pod ，它将从 Nginx 中抓取普罗米修斯格式的指标，并将它们发送到 stackdriver。
使用基于 nginx 指标扩展部署的 HPA 部署我的应用程序。

参考资料:

以下是相同步骤的更详细版本:

1.确保度量服务器正在 Kubernetes 集群中运行。在 GKE，默认情况下会启动公制服务器。否则，可以按照公制服务器自述文件上的信息或使用公制服务器导航图启动公制服务。

# check if the metric server is deployed (or heapster if before v1.11)
$ kubectl get deploy --all-namespaces
[...deleted...]      
kube-system   metrics-server-v0.2.1                 1         1 
kube-system   heapster-v1.5.3                       1         1
# make a request to the metrics api to show that its available
$ kubectl get --raw "/apis/metrics.k8s.io/" | jq
{
  "kind": "APIGroup",
  "apiVersion": "v1",
  "name": "metrics.k8s.io",
  "versions": [
    {
      "groupVersion": "metrics.k8s.io/v1beta1",
      "version": "v1beta1"
    }
  ],
  "preferredVersion": {
    "groupVersion": "metrics.k8s.io/v1beta1",
    "version": "v1beta1"
  },
  "serverAddressByClientCIDRs": null
}

您可以看到外部指标 API 和自定义指标 API 还不可用。

$ kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq
Error from server (NotFound): the server could not find the requested resource
$ kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1"
Error from server (NotFound): the server could not find the requested resource

让我们解决这个问题。

按照 google docs 中的步骤，我部署了 stackdriver 适配器:

$ kubectl create clusterrolebinding cluster-admin-binding \ 
 --clusterrole cluster-admin \
 --user "$(gcloud config get-value avvount)"
clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-binding created

$ kubectl create -f
https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml

# confirm it deployed happily
$ kubectl get po --all-namespaces
custom-metrics custom-metrics-stackdriver-adapter-c4d98dc54-xq8bj 1/1 Running 0 51s

检查 Stackdriver 部署是否成功，以及自定义和外部指标 API 现在是否可用:

# confirm it deployed happily
$ kubectl get po --all-namespaces
custom-metrics custom-metrics-stackdriver-adapter-c4d98dc54-xq8bj 1/1 Running 0 51s

# check to see if custom/external metrics api is up now
$ kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" | jq
{
 "kind": "APIResourceList",
 "apiVersion": "v1",
 "groupVersion": "external.metrics.k8s.io/v1beta1",
 "resources": []
}

$ kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq
{
 "kind": "APIResourceList",
 "apiVersion": "v1",
 "groupVersion": "custom.metrics.k8s.io/v1beta1",
 "resources": [
 {
 "name": "*/agent.googleapis.com|agent|api_request_count",
 "singularName": "",
 "namespaced": true,
 "kind": "MetricValueList",
 "verbs": [
 "get"
 ]
 },
[...lots more metrics...]
 {
 "name": "*/vpn.googleapis.com|tunnel_established",
 "singularName": "",
 "namespaced": true,
 "kind": "MetricValueList",
 "verbs": [
 "get"
 ]
 }
 ]
}

有这么多自定义指标可供使用，这真是太酷了。但是，我想使用 Nginx metrics 中的一个外部指标。因此，我需要让 nginx 安装程序将其指标发送给 stackdriver，这样这些指标也将可用。

3.我用官方掌舵图部署了 Nginx 入口控制器。然后配置 Nginx 入口控制器将其指标发送给 stackdriver。幸运的是，nginx 入口控制器在端口10254已经有了一个路由/metrics，它以普罗米修斯格式公开了一堆指标(这里是一个示例 curl请求 Nginx 指标端点查看公开的指标列表)。

此外，stackdriver 支持以普罗米修斯格式上传额外的指标。为了做到这一点，我使用 Nginx 入口控制器部署部署了Prometheus-to-stack driversidecar。这个 sidecar 抓取度量，并把它们发送到 stackdriver。

使用这个如何创建 sidecar 的例子，我将这个prometheus-to-sd容器添加到 nginx-ingress-controller 部署中，用指标的端口和路由配置— source:

 - name: prometheus-to-sd
  image: gcr.io/google-containers/prometheus-to-sd:v0.2.1
  ports:
    - name: profiler
      containerPort: 6060
  command:
    - /monitor
    - --stackdriver-prefix=custom.googleapis.com
    - --source=nginx-ingress-controller:http://localhost:10254/metrics
    - --pod-id=$(POD_NAME)
    - --namespace-id=$(POD_NAMESPACE)
  env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: POD_NAMESPACE
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace

现在，我可以通过导航到 Stackdriver 指标仪表板来检查 Stackdriver 中是否有 nginx 外部指标:

1_GQis3ESiQdZyuUi73_Qjcg

我还可以检查 nginx 指标现在在 kubernetes 外部指标 api 端点上是否可用。比如我可以检索nginx_connections_total的值。

$ kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/default/custom.googleapis.com|nginx-ingress-controller|nginx_connections_total" | jq

{
 "kind": "ExternalMetricValueList",
 "apiVersion": "external.metrics.k8s.io/v1beta1",
 "metadata": {
     "selfLink": "/apis/external.metrics.k8s.io/v1beta1/namespaces/default/custom.googleapis.com%7Cnginx-ingress-controller%7Cnginx_connections_total"
     },
 "items": [
[...removed...]
     {
     "metricName": "custom.googleapis.com|nginx-ingress-controller|nginx_connections_total",
     "metricLabels": {
         "metric.labels.ingress_class": "nginx",
         "metric.labels.namespace": "",
         "metric.labels.state": "active",
         "resource.labels.cluster_name": "example-custom-metrics",
         "resource.labels.container_name": "",
         "resource.labels.instance_id": "gke-example-custom-metri-default-pool-43d79fe3-08rp.c.cluster-health-test.internal",
         "resource.labels.namespace_id": "default",
         "resource.labels.pod_id": "nginx-nginx-ingress-controller-df8dd967f-fvcx9",
         "resource.labels.project_id": "cluster-health-test",
         "resource.labels.zone": "us-central1-a",
         "resource.type": "gke_container"
     },
     "timestamp": "2018-07-22T21:22:48Z",
     "value": "0"
 },

[...removed...]
 ]
}

4.这是我部署的一个样本 nodejs 应用的示例掌舵图。现在可以使用外部和自定义指标了，我可以创建水平 pod autoscaler 来根据任何 nginx 指标扩展我的示例 nodejs 应用程序。例如，假设当有多个活动连接到 nginx 时，我想扩展应用程序。我可以创建一个 HPA，当指标nginx_connections_total增加超过目标值 1 时，它将增加部署example-nodejs-app的副本数量。

# hpa.yaml

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
 name: example-hpa-external-metrics
spec:
 minReplicas: 1
 maxReplicas: 5
 metrics:
 - type: External
     external:
         metricName:  custom.googleapis.com|nginx-ingress-internal-controller|nginx_connections_total
         targetValue: 1
     scaleTargetRef:
         apiVersion: apps/v1
         kind: Deployment
         name: example-nodejs-app

HPA 显示当前有一个到 nginx 的连接，所以副本计数是 1。如果 nginx 连接增加，pod 副本也会增加。虽然 nginx 连接数的扩展可能不是扩展的最佳指标，但这是一个很好的例子，说明了所有这些是如何工作的。

$ kubectl describe hpa example-hpa-external-metrics

Name: example-hpa-external-metrics
Namespace: default
Reference: Deployment/example-nodejs-app
Metrics:
"custom.googleapis.com|nginx-ingress_controller|nginx_connections_total" 
(target value): 1/ 1
Min replicas: 1
Max replicas: 5
Deployment pods: 1 current / 1 desired
Conditions:
 Type Status Reason Message
 ---- ------ ------ -------
 AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale

 ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from external metric custom.googleapis.com|nginx-ingress-controller|nginx_connections_total(nil)

 ScalingLimited False DesiredWithinRange the desired count is within the acceptable range

Events: <none>

资源:

Kubernetes 简介+如何部署多层 Web 应用程序

原文：https://www.fairwinds.com/blog/kubernetes-intro-how-deploy-multi-tiered-web-app

Kubernetes 是新的。新是可怕的。

原文：https://www.fairwinds.com/blog/kubernetes-is-new.-new-is-scary

Kubernetes 还是新的。新是可怕的。

我以前说过，我相信我还会再说一遍，对于其他用户来说，迁移到 Kubernetes 与第一次迁移到 Linux 非常相似。一旦你习惯了 Linux，你会觉得它很神奇(特别是对于开发和服务器)，但是如果你只知道 Windows，它确实是一个全新的范例。

我记得当 Live CDs 成为一件事的时候，你可以把一张 CD 放在一个驱动器里，在一个新的 Linux 发行版上踢轮胎。它改变了一切，你可以看到一个发行版在你当前的计算机上运行得有多好，而不需要经历一个完整的安装过程(对我来说，这总是从重新分区我的硬盘开始)。

We should use Kubernetes

今天你可以通过像 GKE、AKS、EKS 这样的工具或者像 Rancher 这样的第三方发行版用 Kubernetes 踢轮胎。站起来 Kubernetes 不再是困难的部分。

有了像 Fairwinds KubeStart 这样的选项，您可以获得一个配置了最佳实践的集群，并且所有的附加组件都已经包含在您的集群中，因此您可以使用一个实际工作的生产就绪环境。它就像一张现场 CD，但是鼠标、键盘、屏幕和打印机实际上是开箱即用的。

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

新是可怕的。但是一旦你适应了，新也可以变得很棒。去某个地方踢踢轮胎，感受一下这个新世界是如何运作的，你可能会喜欢你所看到的。

Kubernetes 是错误的答案

原文：https://www.fairwinds.com/blog/kubernetes-is-the-wrong-answer

Kubernetes 是惊人的，未来的浪潮除了一个小缺陷，它的秘密是可怕的。

毫无疑问，如果你在过去的八个月里参加过六英里范围内的技术会议，你会意识到，Kubernetes 是一个神奇的工具，来自谷歌的未来/精灵洞穴，现在，今天，在这里为你运行你的容器工作负载，大规模，持久。

所有这些都是真实的，精彩的，准确的。作为开始，简单地以大约 8 名可靠性工程师的团队为例，他们花费大约 200 万美元的工资开支

记录划痕

什么？你身边没有这样的东西吗？嗯，我们发现这家不在旧金山的公司是建立在一大堆希望登月的投资者资金之上的，不是吗？

Kubernetes 的可悲之处在于，它是一个跨越 15 层复杂性的出色抽象层，最终形成了一个简单的用户界面。这对你来说听起来并不悲伤，但是当第八层抽象出现问题时会发生什么呢？你很快发现自己陷入了沼泽。您从哪里开始排除故障呢？

这是一个可以解决的问题，但是今天在内部运行 Kubernetes 需要相当多的专业知识。这不是第一天的问题，而是第二天的问题。"这是一个 Kubernetes 的环境，祝你好运，再见！"听到构建您的环境的团队的消息并不令人放心。Fairwinds 模式的一个显著特点是，你不会被扔给一个你不知道怎么跑的东西，然后像一只抓到了她不知道怎么开的车的狗一样站着(如果她是一只边境牧羊犬，她会弄明白的；其他品种就不会这么幸运了)。

库伯内特。是的，就是这么复杂。

Kubernetes 在电子商务领域发挥了巨大作用

原文：https://www.fairwinds.com/blog/kubernetes-making-difference-e-commerce

2020 年的假日购物季预计将开创长期先例。德勤(Deloitte)和弗雷斯特(Forrester)都预测电子商务销售将在这个假期爆发。我们都面临的疫情限制旅行、聚会和购物正在加速电子商务市场的发展。虽然对大多数实体零售商来说，这是疯狂的一年，但对许多人来说，电子商务是隧道尽头的光明。

我花了一些时间思考我之前发表的一篇关于 Kubernetes 如何帮助电子商务保持盈利的博客文章，我想知道有多少电子商务零售商可以从 Kubernetes 中受益，因为他们正在接近迄今为止最大的在线假日季节之一。

Kubernetes 有所作为

首先，重要的是要承认 Kubernetes 正在为许多零售商带来变化。我看了一下 kubernetes.io 的案例研究，从零售商那里获得了这些信息:

阿迪达斯

就在项目开始后的六个月，阿迪达斯的电子商务网站 100%都在 Kubernetes 上运行。电子商务网站的加载时间减少了一半。从每 4-6 周发布一次到每天 3-4 次。凭借每月 4，000 个 pod、200 个节点和 80，000 次构建，阿迪达斯现在在其云原生平台上运行其 40%的最关键、最有影响力的系统。阿迪达斯平台工程师 Daniel Eichten 在 KubeCon 上发言时说，他和他的团队已经将【Kubernetes】推广到大多数国家，在那里支持高需求销售和高峰周，如圣诞节和网络星期一。阿迪达斯的前端现在是 Kubernetes，正在规模化经营。

诺德斯特龙

为 Nordstrom 构建 Kubernetes 企业平台团队的高级工程师 Dhawal Patel 说，使用 Kubernetes 的开发人员现在部署速度更快，可以“专注于编写应用程序”。此外，该团队还提高了运营效率，根据工作负载将 CPU 利用率从 5 倍提高到 12 倍。“我们运行着数千台虚拟机，但并未有效利用所有这些资源，”Patel 说。“有了 Kubernetes，我们甚至无需努力提高我们的集群效率，目前的速度就提高了 10 倍。”

JD.com

京东首席架构师刘海峰表示:“通过 Kubernetes 平台，我们的数据中心效率更高，资源管理更好，部署更智能。”。部署时间从几小时缩短到几十秒。以 IT 成本衡量，效率提高了 20-30%。随着该团队正在进行的进一步优化，刘认为每年有可能节省数亿美元。但也许最能说明成功的是一年一度的光棍节购物活动，该活动于 2018 年首次在 Kubernetes 平台上举办。在 11 天的时间里，JD.com 的交易额达到了 230 亿美元，“我们的电子商务平台做得非常好，”刘说。“基础设施引领我们为 11.11 做准备。我们采取预测销量、模仿客户行为的方法来提前做准备，并针对故障进行演练。由于 Kubernetes 的可扩展性，我们能够处理极高水平的需求。”

对 Kubernetes 来说太晚了

调查 Kubernetes 并决定重新搭建平台是一个很大的进步，但是如果你已经踏上了这个旅程，你可能会认为为时已晚，你已经在为你的年度代码冻结做准备了。我们知道许多人已经锁定了核心站点架构，并确定了后端基础架构。那些没有增加加载时间和崩溃风险的。

现在重新搭建平台可能为时已晚，但是今年花时间分析一下您现有的架构与 Kubernetes 所能提供的可能性是对时间的一个很好的利用。

例如，考虑代码冻结。大多数零售商在感恩节前一个月实施这些措施。有了 Kubernetes，一切都变了。由于这种体系结构，可以在不破坏环境的情况下进行更改，因为可以很容易地隔离功能。我们的一个客户 Frambridge 是世界领先的定制相框零售商，它可以在黑色星期五之前对其应用程序进行改进。Framebridge 能够在试运行环境中隔离和测试新功能。不仅部署时间缩短，而且部署完全自动化。如果在部署新功能后出现问题，回滚只需要 60 秒，这样团队就不那么厌恶风险了。

另一个需要重点关注的领域是您是否过度调配资源。我们都知道供应不足不是一个选项-我们不希望网站因购物增加而崩溃！但是过度配置会浪费太多的钱。Kubernetes 在自动缩放方面做得很好(如果限制设置正确，请注意)。

Kubernetes 只面向价值十亿美元的公司

我们知道，许多电子商务提供商每年都赚不到数十亿美元。我们也知道开发团队并不总是那么大。对许多人来说，实现 Kubernetes 平台似乎遥不可及，但事实并非如此。Kubernetes 不仅仅面向价值数十亿美元的公司，它可以推广到任何希望从云原生技术中受益的电子商务团队。好处包括更快的发布、易于管理、降低成本、更可靠的系统。所有这些好处都可以给电子商务零售商带来巨大的变化。

挑战来自于如何集中时间和资源。你让你的团队致力于向 Kubernetes 平台移植，还是让你的团队专注于如何赚钱？这就是 Kubernetes 支持服务派上用场的地方。你的团队不需要成为 Kubernetes 专家也能从中获益；您的团队可以与 Kubernetes 专家合作。

利用这个假期考虑 Kubernetes 可以帮助你的电子商务机会的所有方式。然后再联系。我们的 Kubernetes 托管服务套件可以让您在短短几周内享受到好处。我们允许您快速评估 Kubernetes 。

我需要 Kubernetes 托管服务还是专业服务？

原文：https://www.fairwinds.com/blog/kubernetes-managed-service-or-kubernetes-professional-service

在过去的五年里，我们作为一个公司不断迭代，并从“Kubernetes 专业服务”显著转向另一个领域的“Kubernetes 托管服务”，以提供我们的服务(不要与我们的软件产品混淆)。我认为解决两者之间的差异是有意义的，可以帮助那些采用 Kubernetes 的人。

专业性劳务

专业服务(通常称为“咨询”)是指聘请专家来解决问题。这个问题几乎可以是任何类型的问题。需要税务方面的帮助吗？你可以雇一个专业服务机构来帮你做这件事。需要帮助安装和堆叠一大堆服务器吗？有人已经做了很多了。目标是(希望)一个比一般人更好的人帮助你比你自己更快或更好地完成工作。

事实上，对于许多较大的专业服务公司来说，谈话通常以公司说“答案是肯定的，告诉我们问题是什么”开始。然后他们听到你的问题，去找他们认为组织中最有资格解决问题的人。

专业服务是有优势的。有了足够的钱，你可以对完成的事情进行微观管理，或者要求改变，直到你满意为止。天空是你所能找到的极限。当你成功地找到一个合适的人选时，你就不会在这个过程中感到痛苦和心痛——因为这不是他们第一次这么做了。

但是专业服务也有共同的问题。专业服务通常是按小时付费的，这意味着一些机构会尽可能延长工作时间，或者让工作变得过于复杂，这样他们就可以通过更多的工作获得报酬。

有人进来给你做一些看起来很棒、很前沿的东西，这也并不少见。但是当他们离开的时候，整个事情就结束了。具有专业服务能力的人会受到激励，只要完成项目并获得报酬，他就会一直工作下去。他们通常不会考虑他们所建造的东西的长期影响。

举个例子，假设你雇佣了一个人来帮你改造家里的浴室——这是一项专业服务。他们可能铺上最花哨的瓷砖，装上天窗，升级淋浴器，增加蒸汽功能，拥有有史以来最花哨的梳妆台。但是，除非你亲身经历过，否则你可能不知道他们是否使用了正确的防水材料...几年后，你可能会发现地板在你的淋浴下已经腐烂了。很难核实已经完成的工作的质量，而且当出现问题时，最初完成这项工作的人通常已经离开很久了。

那么这与托管服务有什么不同呢？

托管服务

托管服务类似于专业服务，因为通常由专家完成一些前期工作。尽管大多数托管服务公司倾向于更专注于他们的产品。所以与其说“答案是肯定的，问题是什么？”对话变得更多，“这是我们提供的，这是否符合您的需求？”

另一个很大的变化是长期工作的责任。继续前面的浴室示例，您可以将托管服务视为建造浴室的公司，但也对其未来负责。这项服务将修理任何漏水、排水、破损甚至灯泡。托管服务不是构建并离开，而是构建和并长期掌控结果。

在许多方面，这有助于调整需要托管服务的实体和托管服务提供商本身的激励。双方都希望无论建造什么都能快速建成，并且和能够在最少维护需求的情况下持续很长时间。

然而，这种激励组合通常会带来一些折衷。例如，如果客户真的想使用一个众所周知会堵塞的排水管，管理服务提供商可能会推后，或拒绝支持该排水管。

在 Fairwinds，我们提供 Kubernetes 托管服务，原因如下:

在长期运营 Kubernetes 的过程中，我们比大多数人更有经验。
因此，我们相信，我们可以帮助我们的客户比大多数其他解决方案更快地投入生产，并在我们帮助取得持续成果的所有权时取得长期成功。
在多年从事专业服务的过程中，我们经常被要求将我们知道从长远来看是糟糕的决策的东西放在适当的位置，我们希望避免构建在未来很有可能崩溃的东西。
我们关心服务的最基本层面，即人类帮助他人。

有许多公司可以为你建造任何你想要的东西，不管它是好是坏。Kubernetes 托管服务公司会为你建造一些你可以信赖的东西，因为他们也希望它经久耐用。

Kubernetes 正在走向成熟——它正在推动业务转型

原文：https://www.fairwinds.com/blog/kubernetes-maturing-business-transformation

Kubernetes 是许多企业转变业务的核心，也是自动化部署、扩展和管理容器化应用程序的事实标准。与此同时，对于 Kubernetes 来说，这些仍处于早期阶段。这是一项相对年轻的技术，许多组织都在纠结于启动 Kubernetes 采用计划的复杂性。这些挑战需要时间和耐心来克服，但非常值得努力，因为 Kubernetes 可以成为推动您的数字和业务转型计划的驱动力。

在过去的几十年里，我们已经看到了许多技术进步，这些进步大大改变了商业。语音识别和自然语言处理(NLP)就是一个很好的例子。1995 年，我是 SpeechWorks 创始团队的一员，speech works 是一家高级语音技术提供商，于 2001 年成功上市，并被 Scansoft，Inc .收购，即现在的 Nuance Communications。2021 年 4 月，微软宣布将以 197 亿美元收购 Nuance Communications。这项技术从推出到成为今天的日常主流产品只花了 25 年多一点的时间。想想 Siri、Alexa、谷歌助手和 Cortana——你一天使用多少次语音识别和 NLP？我们最初的技术花了 10 到 20 年才被广泛采用并融入日常生活。

技术采用

这种程度的采用是如何发生的？我们的世界在数据中显示了过去一百年左右不同类型技术的采用情况，有些采用的飞跃速度之快令人吃惊。还要注意的是，随着新技术的出现，这些项目也会从列表中消失(看看那些根本没有固定电话的家庭吧！)

资料来源:数据中的我们的世界:美国家庭采用的技术

技术发展速度的提高有许多促成因素。今天的消费者期望更高的连接性和即时通信。这种在世界范围内快速联系和交流的能力意味着新的想法和产品会以令人难以置信的速度传播。允许这一点的基础设施可能对大多数消费者来说是不可见的，但它正在推动技术社区内外的采用。

Kubernetes 和技术变革

Kubernetes 是技术转型故事和技术采用故事的重要组成部分。虽然我们仍处于 Kubernetes 采用的早期阶段，但许多公司都在努力在开发和测试环境中使用 Kubernetes，更多的公司每天都在生产环境中运行它。

来源:VMWare 的Kubernetes 2020 的状态

然而，就像早期的语音识别和 NLP 一样，Kubernetes 仍然处于萌芽阶段。大多数组织都面临着 Kubernetes 的复杂性和缺乏 K8s 专业知识的挑战。他们经常在维护环境、运行和维护 Kubernetes 方面遇到困难。采用 Kubernetes 并将其与敏捷开发流程、DevOps 实践、安全需求和站点可靠性工程(SRE)框架相集成，也会产生一些技术问题。除了技术挑战之外，还有一些与管理复杂性相关的问题，这些复杂性来自与采用 Kubernetes 相关的必要文化变化。

求 K8s 专业知识

当技术仍然如此新时，所有这些组织如何雇用有才华和经验丰富的 DevOps 工程师、高级软件工程师、软件架构师、云工程师和全栈开发人员？就像熟练的安全人员一样，似乎经常没有足够的人具备转向 Kubernetes 生产所需的经验。寻找和培训渴望知识、好奇并参与 Kubernetes 的新功能和挑战的人是填补这些角色的一种方式。

在 Fairwinds，从一开始我们就一直在研究这项技术。多年来，我们雇佣了来自不同技术背景的人来帮助发展 Kubernetes 人才库。我们在 Kubernetes 集群管理方面来之不易的知识，基于通过我们的服务进行的数百次部署，有助于在公司内部创建一种包含学习和教学的文化，无论是 Kubernetes、DevOps、DevSecOps，还是由云本地计算基金会孵化的下一个开源项目。我鼓励任何考虑迁移到 Kubernetes 的组织采取这种方法来培养 Kubernetes 人才，并检查我们的 Kubernetes 成熟度模型。您的团队成员可能已经迫不及待地开始尝试 K8s 了，成熟度模型为采用的每个阶段提供了指南，以及何时寻求帮助的提示。

Kubernetes 的下一步是什么？

挑战是需要时间来克服的，Kubernetes 不可否认是复杂的，但我相信 Kubernetes 的潜力是显而易见的，我完全期待看到它在未来五到十年内被广泛采用。你可能已经在使用自然语言处理、Wi-Fi 连接和机器学习询问你的冰箱你是否没有牛奶或者你需要添加到你的购物车中。你还应该期待，很快，Kubernetes 将为创新技术运行的大部分基础设施提供动力。

为了保持一切顺利运行，您需要了解和控制您的 Kubernetes 环境。在 Fairwinds，我们通过帮助组织建立和运行高效的 Kubernetes 环境来建立公司，并且我们正在创建和贡献有助于提高 Kubernetes 采用率的开源项目，以便用户能够更快、更经济高效、风险更低地交付云原生应用。Fairwinds Insights 平台运营多个开源解决方案，以提供对每个组织的 Kubernetes 配置的多集群可见性，帮助企业弥合开发、安全和运营之间的差距，并构建、发布和维护安全、可靠且经济高效的软件。我们为 Fairwinds 作为值得信赖的 Kubernetes 合作伙伴的角色感到自豪，并敦促您考虑 Kubernetes 的采用如何适应您在业务转型道路上的后续步骤。

Kubernetes 成熟度模型:预期业务成果

原文：https://www.fairwinds.com/blog/kubernetes-maturity-model-expected-business-outcomes

当你搬到 Kubernetes，你必须显示出明确的业务优势。随着时间的推移，预期的业务成果将包括成本节约，因为您可以更好地利用基础架构，通过减少故障点和提高安全性来提高性能。

效率、可靠性和安全性优势可以通过许多不同的方式实现。考虑效率:你的团队可能会更快地发布特性，或者你会停止在过度配置的资源上浪费金钱。你的可靠性可能会提高，因为你可以更容易地扩展-所以当你的应用程序看到强大的需求，没有停机时间。当然，这一切都是以了解您的集群配置为代价的。

几个月前我们发表了 Kubernetes 成熟度模型。由七个阶段组成，每个阶段都着眼于工程师在从 Kubernetes 准备到优化的过程中应该期待什么。

在这里，我们专门讨论你应该期待什么样的业务成果。虽然在几个阶段可能会重复，但在第一阶段花足够的时间概述云原生、容器和 Kubernetes 采用的目标和优势是很重要的。

第一阶段:准备

决定对您的应用或服务采用云原生方法通常是由业务原因驱动的。在第 1 阶段，您的业务成果将是有限的，但绝对必须包括为成功设置试验或迁移。这意味着你应该有文件证明你的商业目标是什么，以及 Kubernetes 如何帮助你实现这些目标。一些例子可能包括:

阶段 2:转换

Kubernetes 成熟的第二阶段主要集中在技术改造上。但是，在此阶段，您的技术团队应该已经完成了一次成功的概念验证。基于那次试验，你应该对 Kubernetes 如何帮助改进你的应用有了一些初步的发现。例如，在开发环境中，您可能会看到:

应用程序使用更少的资源(节省成本)
更快推出新功能(更快上市，从而增加收入)
没有停机时间(提高了客户的可靠性)

第三阶段:部署

一旦您的开发团队将一个应用程序部署到生产环境中，业务成果应该开始显现。你应该使用你记录的业务目标来跟踪 Kubernetes 的进展，但是记住它不会在第一天就立即实现。业务成果可能包括:

减少在应用基础设施上的支出
减少团队对应用基础设施的关注(注意:随着团队对他们的技能越来越有信心，这将在这个阶段随着时间的推移而发生)
提高了应用程序的安全性
提高合规性，因为您可以限制和跟踪对应用程序的访问
加速开发生命周期，因为您实现了 CI/CD 管道，从而更快地向客户提供特性

在这个阶段，检查业务成果并向业务涉众解释是很重要的。这应该是与工程领导、应用程序所有者(财务、营销等)、CEO 甚至董事会的讨论。没有这些讨论和协调，下一个阶段的成熟将会很少被欣赏，甚至可能被怀疑。

第四阶段:树立信心

建立对 Kubernetes 的信心需要经验。在这个阶段，你的业务成果取决于你的团队的经验。他们将尝试新的附加功能来提高安全性、效率和可靠性。随着团队的改进，所有这些都会影响您的服务和应用程序。

随着 Kubernetes 的推出，您的团队可能需要重新考虑之前做出的一些决定。这可能会让您稍有退步，但目标是确保没有功能缺失、没有单点故障或令人失望的性能。

在第四阶段，将实施监测。这将有助于企业获得关于哪些有效、哪些无效的报告。虽然监测可能非常具体，但它也将提供以下方面的见解:

获得对您的 Kubernetes 基础设施是生产级的信心是至关重要的。如果你对自己的进展不确定，Kubernetes 的审计是对照你的业务目标检查你的成就的好方法，这样你就可以改进。

第五阶段:改善运营

Kubernetes 成熟度模型的第五阶段是您应该期望在安全性、效率和可靠性方面获得巨大收益的阶段。到目前为止，你们的团队一直专注于学习 Kubernetes。现在是时候利用这些知识，并将其更彻底地应用到您的业务目标中了。

安全性——如果你的主要目标是提高安全性，那么你将在访问控制上花费时间。
效率——如果降低成本是你的主要目标，在这里你将放置工具来测量 CPU 和内存使用，并记录云使用是如何增加或减少的。在这里，你应该能够证明为你的基线测量提供资金。
可靠性——如果提高性能/减少停机时间是主要目标，在这里您将检查 Kubernetes 的所有功能是否都已实现。您将花时间学习集群配置来解决这个问题。

第六阶段:测量&控制

进入第六阶段将会看到对你所做的更多的衡量。这很重要，因为它将用于展示业务成果。企业应该期望看到:

在 Kubernetes 建立协议和程序
合规标准的策略实施
基于 Kubernetes 与非基于 Kubernetes 的应用对比

在这一阶段，企业应该会收到更多的报告。报告应涵盖合规性、安全性、性能和成本。一个单一仪表板视图进入您的集群可以帮助技术和业务领导看到进展。这些应该很容易与第一阶段建立的业务目标保持一致。

第 7 阶段:优化&自动化

到 Kubernetes 成熟度模型的最后阶段，您应该已经取得了业务成果。你应该有可衡量的结果来展示你的领导团队，从首席执行官到首席财务官和董事会。

与此同时，第七阶段会看到你做进一步的改进。这包括根据更高级的成本和性能指标优化您的 Kubernetes 工作负载。您将永远不会停止优化您的 Kubernetes 集群。在这里，预期的业务成果是跟踪优化如何继续朝着既定目标前进的能力。

你也可以在这一点上重新审视你的目标，根据已经实现的目标和你未来想要实现的目标进行调整。对于一些人来说，在这一点上，您可能开始迁移您的其他应用程序，并对您想要实现的目标有了更好的理解。

同样在第 7 阶段，您将根据 Kubernetes 的最佳实践尽可能多地实现自动化，以消除人为错误，从而避免安全性和性能问题。这种自动化将包括针对您的集群配置实施策略实施。策略执行在成熟的每个阶段都应该考虑，但肯定是在阶段 7。成熟的 Kubernetes 用户知道，错误的配置会导致组织完全偏离他们的业务目标——使他们面临安全漏洞的风险，扩展问题和成本超支。

Kubernetes 成熟度模型

成熟度模型应该用于检查您的技术和业务成果。如果你不确定你是否在每个阶段都取得了进展，或者不知道你的确切位置，请联系我们。我们很高兴在贵公司讨论 Kubernetes。

常见的 Kubernetes 错误配置漏洞

原文：https://www.fairwinds.com/blog/kubernetes-misconfigurations

保护 Kubernetes 中的工作负载是整个集群安全性的一个重要部分。总体目标应该是确保容器以尽可能小的特权运行。这包括避免权限提升、不作为根用户运行容器，以及尽可能使用只读文件系统。

由于疏忽或缺乏经验，安全漏洞可能会溜进生产中。交付的速度与关键的安全保护措施经常是不一致的，因为团队试图平衡工程的速度与安全的反应速度。这种平衡行为会导致混乱的 Kubernetes 配置和不必要的风险。如果开发人员由于缺乏经验或疏忽而错误配置工作负载，就会出现问题。

我们最近的 Kubernetes 配置基准报告告诉我们，并不是所有的组织都已经在 Kubernetes 环境的正确配置上找到了稳定的立足点，他们甚至还没有达到一半。

如果没有被发现和解决，小的错误配置会产生大的安全漏洞。例如，一个常见的漏洞是容器运行时具有比所需更多的安全权限，例如根级别的访问权限。在特定的配置下，容器可以提升它自己的特权。因为配置不是默认建立的，所以有安全意识的团队需要显式地设置它们。

不幸的是，单个应用程序开发人员经常忽略每个工作负载的安全配置。例如，通常更容易过度授权一个具有 root 访问权限的部署来让某些东西工作。强迫个体贡献者设计他们自己的安全配置几乎确保了不一致性和错误。

什么是安全错误配置？

Kubernetes 的安全错误配置经常发生在配置还没有被设置的时候。这通常是因为最快的生产方式是通过设置阶段。一些示例安全配置包括 hostIPCSet、privilegeEscalationAllowed、insecureCapabilities 或 privilegeEscalationAllowed。点击查看完整列表。

避免错误配置部署的提示

避免错误配置需要几样东西。首先，DevOps 团队需要定期扫描 Kubernetes 集群，以确保它们配置正确。通常，组织使用电子表格手动完成这项工作，然后交给开发人员进行修改。不幸的是，这些变化并不总是发生，因此循环不断重复。避免错误配置的首要技巧是从开发到生产自动连续扫描集群。这样做有助于避免这些错误配置进入任何生产环境。

更好的是，使用准入控制器来防止错误配置可以帮助开发人员更好地配置 Kubernetes。准入控制器可以是 CI/CD 过程的一部分，有助于在检查生产中的误配置之前扫描集装箱。任何问题都会在投入生产之前通知开发人员。这有助于开发人员修复他们自己的问题，并解放开发人员，使他们不再像 Kubernetes 服务台那样行事。

常见的 Kubernetes 安全错误配置

那么，如何快速、主动地识别 Kubernetes 的安全错误配置以防止安全风险呢？根据我们的经验，有八种常见的 Kubernetes 安全错误配置会导致易受攻击的部署。

不识别和解决这些安全设置配置可能会产生负面的业务后果。例如，如果一个容器以 root 身份运行，但不一定需要这种级别的访问权限，那么一个恶意容器就有权限窃取数据或对系统造成其他损害。

| 配置 | 严重性 | 描述 |
| security.hostIPCSet | 危险 | 配置 hostIPC 属性时失败。 |
| security.hostPIDSet | 危险 | 配置 hostPID 属性时失败。 |
| security . notreadonlyrootfilesystem | 警告 | 当 security context . readonlyrootfilesystem 不为 true 时失败。 |
| security.privilegeEscalationAllowed | 危险 | 当 security context . allowprivilegescalation 为 true 时失败。 |
| security.runAsRootAllowed | 危险 | 当 securityContext.runAsNonRoot 不为 true 时失败。 |
| security.runAsPrivileged | 危险 | 当 securityContext.privileged 为 true 时失败。 |
| 安全.不安全能力 | 警告 | 当 securityContext.capabilities 包含此处列出的功能之一时失败 |
| 安全.危险能力 | 危险 | 当 securityContext.capabilities 包含此处列出的功能之一时失败 |

为了解决这些常见的 Kubernetes 安全威胁，我们的团队构建了一个开源工具 Polaris ，它可以检查 Kubernetes pods 和容器的 securityContext 属性中的配置。北极星终结的地方就是 Fairwinds Insights 的起点。

Fairwinds Insights 是一款配置验证工具，通过审计工作负载和验证配置的弱点、容器漏洞和错误配置的部署，提供对组织的 Kubernetes 安全状况的可见性。

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

Fairwinds Insights 不仅提供调查结果，还保存所有集群结果的历史记录，并提供补救指导，从而实施北极星检查。Fairwinds Insights 允许您跟踪安全性、效率和可靠性问题并确定其优先级，跨团队协作，并在应用程序从开发进入生产时应用最佳实践。

了解有关 Fairwinds Insights 的更多信息或获取关于如何管理 Kubernetes 配置以提高安全性、效率和可靠性的论文。

Kubernetes 多集群可见性:为什么以及如何获得它

原文：https://www.fairwinds.com/blog/kubernetes-multi-cluster-visibility-why-how-to-get-it

如果您正在使用 Kubernetes 管理一个工程师团队，您如何知道您的集群中到底发生了什么？这是一个我们经常听到的问题。

这是一个不经常解决的问题，但它会导致时间和金钱的浪费以及应用程序的损坏。

Kubernetes 可靠性

我们谈了很多关于活性探测器的重要性。对于大多数工程师来说，他们不会主动设置这些，直到有真正的停机时间(即使那样也可能不是优先事项！).

在我之前的公司，有一天一个应用程序宕机了。开发者只是认为 Kubernetes 坏了，但我们不知道实际发生了什么。几个小时后，我们意识到容器内部的某些东西崩溃了，但这并没有导致整个应用程序崩溃，因为主进程没有死亡，所以 Kubernetes 没有尝试重新启动它。如果设置了活性探测，这种情况就不会发生。虽然工程师可能看不到在没有设置活跃度探测器的情况下修复配置的需要，但是如果您正在管理一个团队，简单地创建一个规定设置活跃度探测器的书面策略不会让您远离麻烦。

在另一个例子中，我从一个同事那里收到一条愤怒的消息，说一个应用程序在本地运行良好，但当放入 Kubernetes 时，性能从半秒响应变成了 20 秒。问题是这个人没有设置任何资源请求，而 pod 运行的节点恰好有一个吵闹的邻居。一旦在 pod 上设置了 CPU 请求，应用程序的性能就固定了。即使您有一个策略，告诉工程师设置资源请求，也很难跟踪谁在遵循它。

工程领导者需要了解哪些集群设置了活性探测器，哪些集群没有设置资源请求，以及哪些集群需要(以及如何)修复。

Kubernetes 效率(我们指的是成本！)

任何公司都浪费不起钱。过度配置集群是非常普遍的。当请求设置得太高时，你将会在不使用的内存或 CPU 上烧钱。我在过去见过这样的例子，过度配置的容器每月在单个工作负载上浪费高达 100 美元。如果这种情况发生在 30 个工作负载上，浪费 3，000 美元很容易发生。我哥哥非常喜欢这样一句话:“注意盎司，体重自然会增加。”大多数集群可能没有浪费那么多资源的工作负载，但是到处都可以进行足够小的更改，累积起来就很多了。

获得多集群对工作负载支出的可见性很困难…非常困难。事实上，即使查看一个工作负载中的一个集群也很困难。因此，提供证据证明你在 Kubernetes 省钱或不浪费钱似乎是不可能的。

管理人员需要了解可以在哪里调整请求以节省资金。它需要能够跨您的所有工作负载。

Kubernetes 安全

我们终于安全了。虽然市场上有大量解决方案可以帮助您识别存在漏洞的映像，但查看一个或所有集群的安全警报通常意味着运行许多不同的工具。即使您将这些工具组合在一起，也可能没有结果的仪表板视图。您需要花时间扫描每个集群，汇总结果，然后解决问题。当集群存在潜在的安全风险时，这需要做大量的工作。

在这里，工程领导需要能够看到他们的集群的安全状态，这样他们才知道他们真正需要担心的是什么。

【Kubernetes 配置验证软件的可见性

我是开发 Kubernetes 配置验证软件 Fairwinds Insights 的团队成员之一。在加入 Fairwinds 之前，我负责管理 Kubernetes 的基础设施。我亲身经历过配置设置不当的问题，也经历过对 Kubernetes 中发生的事情缺乏了解。

Fairwinds Insights 通过将来自不同集群的数据整合在一起，为那些负责管理多个团队和多个集群的人解决了这些挑战。

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

聚类比较

Insights 提供了比较功能。如果您正在管理团队，您可以进入控制面板，比较您的试运行和生产环境之间的不同之处。您可以查看是否有不同的映像，是否存在 CPU 和内存请求，以及是否设置了限制。您还可以确保从准备阶段到生产阶段，集群是彼此的完美镜像。

Cluster Compare screenshot of Fairwinds Insights

Fairwinds Insights screenshot showing compare dashboard

控制面板让您在一个地方就能看到多个集群。如果您没有这些，您的团队将需要:

在命令行中，登录到每个集群
运行 kubectl get all
然后观察这两个列表，或者通过 diff 工具运行这些列表

这将只是一个小的工作量！真的，真的，真的很痛苦。

行动项目

接下来，在仪表板中，您可以查看组织中所有集群的行动项目，并根据您的关注点(可靠性、效率或安全性)进行筛选。

可靠性

在这里，您可以查看哪些集群缺少活动或就绪性探测、映像拉取策略，以及哪些集群的内存请求过低会导致停机。管理人员获得了这种整体视图，同时仍然能够深入了解每个集群。修复配置意味着避免停机，提高性能。

Screenshot of Fairwinds Insights Reliability Action Items

效率

我前面的例子给出了一些大概的数字，而 Fairwinds Insights 给出了精确的数字。借助 Insights，您可以了解自己的实际使用情况，并根据历史数据查看有关使用情况的建议。

当您获得整个集群效率的可见性时，您可以节省资金或向您的经理证明 Kubernetes 正在经济高效地运行。

Screenshot of Cluster Workload with Cost Recommendations

安全

Fairwinds Insights 还会持续监控您的集群，并让您了解所有集群的安全状况。在“行动项目”中，您将看到按严重程度分类的安全警报——危险或警告。另外，当您深入研究每个行动项目时，我们会提供如何解决问题的信息。您将能够比较哪些集群比其他集群更安全，并证明合规性。

Screenshot Fairwinds Insights Security Action Item with Recommendations

多集群可见性

Fairwinds Insights 是一个帮助您更好地运行 Kubernetes 的工具，您将实际了解您的集群内部正在发生什么。

Kubernetes 针对开发人员的策略实施

原文：https://www.fairwinds.com/blog/kubernetes-policy-enforcement-for-developers

政策的存在是有原因的

你知道那种感觉，在接近午夜的时候，你在城外，你把车停在红灯前，停下来开始等待。一开始你不会想太多，但是几秒钟后你意识到这里没有车。没有。没有人从左边过来。没有人从右边过来。事实上，你已经出去 15 分钟了，却没有看到另一个灵魂。然后光线不变。它只是保持红色，而且似乎永远保持红色。

我听说只需要大约 2.5 分钟，就有很大一部分人放弃了，认为灯坏了，然后试图运行它。而你是闯那道光，还是不管花多长时间都耐心等待它改变，大概很大程度上与你的性格和教养有关。

选择闯红灯有点像看是否有人在看，然后进入 Kubernetes 集群中的一个容器进行改变，因为....我发誓，没有人会注意到，也没有人会受到伤害。

老实说，你可能是对的。但是道路政策的存在是有原因的——最大化所有参与者的安全。

政策执行是必要的

我们大多数人(开车的人)都会联想到自己做了一些愚蠢的事情，或者以为没有人在看，甚至只是犯了一个诚实的错误，违反了交通规则——马上就会被一名警察跟踪，他会拦住我们开罚单。我被这些惹恼了，但我也收到了一张我坐在那里点头的罚单，因为——我明白，我知道我不应该那样做。尽管当这些规则应用到我个人身上时，有时会让我恼火，但我通常很高兴别人也遵守了这些规则。

我想让人们待在他们的路边。我希望人们在红灯时等待，这样我就可以在绿灯时继续开车。我希望人们把车停在他们应该停的地方，而不是马路中间。

见鬼，即使当我不开车，只是步行或骑自行车时，我也希望汽车做人们对它们的期望——至少这样我就可以知道发生了什么，并保证自己的安全。知道政策得到执行让我们感到安全。和....这是我“基础设施和相关政策也是如此”的转折点。

Kubernetes 针对开发人员的策略实施

当你的公司只有三个人，而你有五个用户时，你的 CTO 可以 SSH 到一台机器上“热修复”一个问题，然后继续前进。这就像生活在一个在单一十字路口没有停车标志的城镇。很少有足够的事情发生，我们都可能保持安全。但是规模是个问题。

当你有一百个或几千个开发人员，当你有 Kubernetes 集群和服务所有权—现在你需要真正的政策和执行它的方法。有时候，开发人员需要做最后一次修改，这样他们就可以回家过夜，这很烦人。但就像上面的红灯情况一样，虽然大多数时候在纸面上可能是好的，但政策的存在是有原因的。有了良好的防护和政策，开发者就不会很快地将 Log4j 的一个版本投入生产，因为它“可能不会成为问题”。

好的 Kubernetes 护栏和政策有时会导致挫败感。但是大多数时候，这会让你团队中的其他人感到安慰，他们今晚可以睡觉，而不会出现需要页面的生产中断。让领导层感到欣慰的是，他们不会因为巨大的数据泄露而被传唤到法院。策略让您的运营团队确信需要配置的内容，因此可以适当地扩展和缩减。

政策是为开发人员制定的，尽管它是按照他们的方向执行的。就像红灯对于人类一样。有时我们会在红灯时挥舞拳头。但大多数时候，我们可以感谢它带来的平静和理智。

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

别等了。执行 sane Kubernetes 政策带着 Fairwinds 的洞察力走出大门。即使你住在一个像汽车一样跑得飞快的城市，需要定制的政策来覆盖它——我们可以帮助你。

Kubernetes 实施策略以启用 DevSecOps

原文：https://www.fairwinds.com/blog/kubernetes-policy-enforcement-to-enable-devsecops

您正在管理 Kubernetes 用户:您知道您的集群中发生了什么吗？您知道您的群集是安全的、经济高效的还是不可靠的吗？对于许多工程领导者来说，这是一个问题，然而实施 Kubernetes 的政策，然后执行它们可能会有问题，尤其是在没有利益相关者批准的情况下。

Kubernetes 可以成为 DevOps、开发、安全和法规遵从性团队之间的交汇点。这个交汇点为护栏、Kubernetes 治理和执行方面的协调提供了一个机会。获得利益相关者的认同，并在下游用户体验您实施的策略时保持这种认同是至关重要的。没有它，DevSecOps 将举步维艰，团队将失去信心，你将错过“我们在一起”的心态。

【Kubernetes 的政策执行何时有意义？

策略有助于三种类型的所有权模型:

Ops 拥有 all things containers 和 Kubernetes: 虽然这使开发人员能够将 100%的时间集中在应用程序代码上，但一个副作用是 Ops 变得负担过重，需要为数百或数千个他们几乎不了解的工作负载调整和维护配置。管理这种复杂性可以通过对现有问题进行优先排序，以及围绕一组良好的最佳实践应用 Kubernetes guardrails 来解决。
运营和开发部门共享所有权(最常见):在运营所有权和上市时间之间找到恰当的平衡是关键。大多数公司可能会将一些 Kubernetes 和容器配置推给开发人员——只是需要应用程序级上下文的部分——而 Ops 管理其他一切，包括平台级功能，如 DNS、证书管理、入口/出口等。人为错误会导致可避免的错误。应用合理默认值的政策会有所帮助。
由开发人员完成服务所有权:在这种状态下，团队可能会面临开发人员对 Kubernetes 最佳实践了解不够，以及意外引入错误配置而产生合规风险，或消耗过多计算资源的挑战——导致成本增加或容量问题。虽然这可能是许多组织的理想最终状态，但现实是很少有公司能做到这一点。

谁是利益相关者？

利益相关者包括平台工程师、开发人员、开发人员、工程、安全和合规负责人。我们通常会遇到这些利益相关者:

操作
安全性和合规性
软件开发

利益相关者如何受益

实施策略实施后，每个利益相关方都将受益:

运营: Kubernetes 运营商受到激励，尽可能实现自动化，以降低停机、复杂性和凌晨 3 点页面的风险。例如，要求所有应用程序都有正确标签的部署策略是一种在团队之间加强一致性的常用方法。
安全&合规:安全团队致力于确保容器运行时没有严重漏洞，确保 Kubernetes 配置具有正确的安全环境，并保持企业范围内对基础设施风险的可见性。借助策略，尤其是那些现成的策略，安全团队可以降低风险并以更低的成本保持合规性。此外，它还帮助安全团队向平台工程团队建议在集群级别应用和实施安全策略。它有助于确保安全是首要考虑的问题，并且符合法规要求。
软件开发:开发人员通过编写代码和发布路线图功能获得报酬。他们没有时间去学习所有错综复杂的库伯内特。这里的挑战是，当实现策略时，开发人员可能必须细化他们完成工作所采取的某些步骤。例如，不授予特权访问。策略可以在 CI/CD 流程中提前推出，这样开发人员就可以获得与其特定应用相关的配置反馈。随着他们对策略的体验，配置需求将成为他们的第二天性。

下游发生了什么

当实现任何护栏时，您的下游用户将受到影响，因为您开始检查一组最佳实践的部署。通过获得利益相关者的认同，每个团队领导将能够交流为什么要进行这些检查。这将有助于克服下游的任何异议。

从哪里开始

我们已经帮助许多公司建立和管理他们的 Kubernetes 基础设施。许多人面临的挑战是让多个应用程序团队加入 Kubernetes，并与开发人员、开发人员和安全人员进行交流。一个问题领域是如何根据每个团队的需求审计集群。

我们注意到，如果没有验证集群的方法，团队将会看到配置漂移、Kubernetes 蔓延和风险(由于工程的速度)。我们需要一种方法来实施 guardrails，以消除人为错误，并使平台工程、开发和安全团队在应用迁移到云原生基础架构时更容易合作。

为了解决这个问题，我们建立了 Fairwinds Insights 。它根据各种最佳实践领域审计 Kubernetes 集群，包括安全性、工作负载效率、集群可靠性和定制策略。它有助于在一个集中的仪表板中跨工作负载执行 Kubernetes 策略。

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

Fairwinds Insights 让组织中的利益相关者对安全性、合规性和成本感兴趣，并为所有团队领导提供所需的视图。安全性得到加强，合规性得到保证，成本降至最低。

Kubernetes 策略引擎，北极星:新检查的一般预览

原文：https://www.fairwinds.com/blog/kubernetes-policy-engine-polaris-a-general-preview-of-new-checks

Polaris 是 Kubernetes 的开源策略引擎，用于验证和修复 Kubernetes 资源。它包括 30 多种内置配置策略，并能够使用直观的 JSON 语法编写定制策略。

我们已经为 Kubernetes 策略引擎添加了额外的检查。我将简要地预览一下新的内置 Polaris 检查，它确定了人类或工作负载可能会过多访问 Kubernetes 的五个领域。在以后的博客文章中，我将深入总结这五种新检查。

1.ServiceAccount 令牌会自动装载

集群中运行的工作负载也可以访问与人类交互的相同的 Kubernetes API。工作负载可以被授予 Kubernetes 权限，允许检查不相关的 Kubernetes 资源，特别是如果它们共享一个 Kubernetes ServiceAccount。该检查检测自动拥有可用于访问集群的凭据的工作负载。这对于帮助防止对群集的未授权访问非常重要。

2.伴随网络策略

使用 Kubernetes NetworkPolicy 资源以及支持的容器网络接口(CNI)可以在工作负载和退出 Kubernetes 集群之间建立防火墙流量。这种访问控制有助于确保容器可以与所需的网络资源通信，并且不能到达其他网络。该检查确保每个工作负载都有一个命名空间 Kubernetes 网络策略。这一点很重要，因为防火墙工作负载内部通信提高了安全性。

3.强化 Linux 工作负载

默认情况下，工作负载可能比运行其应用程序所需的能力更强。调整这些权限可以最大限度地降低容器危害的范围、速度和影响。该检查确保工作负载使用 AppArmor、dropping Linux 功能、SELinux 或 seccomp 配置文件来授予工作负载运行所需的最低权限。这一点很重要，因为最小化工作负载的权限也会最小化攻击者获得其他工作负载或集群访问权限的能力。

4.执行或连接到 Pod

通过在现有容器内运行命令，可以执行额外的代码，从而允许对工作负载或集群进行更深入的访问。在生产集群中限制使用像“kubectl exec”或“kubectl debug”这样的命令是一个很好的做法。该检查检测允许执行或附加到容器的基于角色的访问控制(RBAC)。这一点很重要，因为限制运行其他命令的能力可以保护您的工作负载免受未经授权的访问或泄漏。

5.群集管理权限

授予对 Kubernetes 集群的管理访问权有助于您的团队在开始时更快地行动，但是这个决定扩大了潜在攻击者的机会和范围。通过检测允许集群管理权限的基于角色的访问控制(RBAC ),该检查有助于实现最低权限的安全原则。这一点很重要，因为应该谨慎授予集群管理权限，并在破碎玻璃的情况下使用。

如果这些新的北极星检查引起了你的兴趣，也许作为你的 NSA Kubernetes 强化之旅的一部分，请留意未来的博客帖子，这些帖子将深入研究每一项检查。

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

Kubernetes 问题解决

原文：https://www.fairwinds.com/blog/kubernetes-problem-solving

毫无疑问，运行 Kubernetes 时，你会花大量的时间来解决问题。我们的团队在许多不同的 Kubernetes 部署中解决了很多问题。以下是一些常见问题以及我们如何解决它们。

1.卵死亡荚

在 Kubernetes 集群中，内存的底层资源是有限的，当内存不足时，底层操作系统可以终止容器。根据进程对饥饿内存资源的使用是否超过请求以及优先级，对进程的终止进行排序。

为了避免问题，您需要设置内存请求和限制，以适应应用程序在其生命周期中的使用。如果您的内存限制太低，您将熟悉 OOMKilled 作为一种状态，它显示您的 Pod 因使用太多内存而被终止！但是如果你把你的限制设得太高，你会因为过度分配而浪费金钱。

理想情况下，您希望将内存请求和限制设置在“刚好够用”的最佳位置。您将需要检查所有 pod 以检查内存请求和限制。手动执行此操作会花费大量时间，并且容易出现人为错误。我们通过使用 Goldilocks 来解决这个问题，这是一个开源工具，可以帮助团队将资源分配给他们的 Kubernetes 部署，并正确地校准这些资源。

降低成本是 Kubernetes 的众多好处之一，您应该对预期成本有所了解。如果到了月底，你的账单显示费用飞涨，那么你可能会有问题。

2. Higher than expected costs

要解决这个问题，您必须将建议成本与实际成本进行比较。许多组织将其 CPU 和内存请求和限制设置得太高，但不知道从哪里进行更改。如上所述，我们使用 Goldilocks 来审查请求和限额。不过，对于成本分析，我们使用fair winds Insights，它吸收金发女孩数据，帮助我们区分哪些工作负载需要调整请求和限制。我们还使用 Cluster Autoscaler 来确保任何多余的节点在未使用时被删除，从而节省时间和金钱。

3。知道什么时候更新头盔

修补 Kubernetes 附加组件通常并不困难。另一方面，跟踪何时更新可能很困难。虽然 Kubernetes 定期按季度更新，但掌舵图的更新难以监控和预测。我们的 Fairwinds 团队使用 Nova ，这是一个开源的命令行界面，用于交叉检查您集群中运行的最新版本的舵图。Nova 会让您知道您运行的图表是否过期或被弃用，因此您可以确保您始终了解更新。如果使用 Fairwinds Insights，该工具可以接收 Nova 数据，并在有新更新时提供警报，而不必定期运行 Nova。

4。处理突发流量

无论你是突然被病毒感染还是遭到 DoS 攻击，Kubernetes 都提供自动缩放功能，因此你的应用不会失败。虽然这对于病毒式传播来说是件好事，但如果发生 DoS 攻击，那就非常糟糕了。

在您的应用以及服务网格或入口控制器中设置速率限制。这将防止任何单个机器使用太多的带宽。例如，nginx-ingress 可以限制每秒或每分钟的请求、有效负载大小以及来自单个 IP 地址的并发连接数。

运行负载测试，了解应用程序的伸缩性。您将希望在一个临时集群上设置您的应用程序，并对其进行流量处理。测试分布式 DoS 攻击有点困难，因为流量可能同时来自许多不同的 IP，但是有一些服务可以帮助解决这个问题。
利用 Cloudflare 等第三方服务来提供 DoS/DDoS 保护。
回到第一点，您需要确保您有正确的限制请求，以确保您的常规流量能够到达您的服务。

5.缺少标签

容器注册通常允许您在推送容器时覆盖标签。这种情况的一个常见例子是最近的标签，它甚至可以自动设置为匹配最后推送的标签。在生产中使用这个标签是一种危险的做法，因为它可能会出现这样的情况:您不知道您的容器中正在运行什么代码，并且最终可能会无意中在生产中运行多个版本的代码。为了帮助跟踪这样的问题，我们使用了北极星、另一个开源工具，它支持许多与 pods 指定的图像相关的检查。使用时，如果标签丢失，北极星将显示 `images.tagNotSpecified` 或 `images.pullPolicyNotAlways.`

对于那些没有资源来处理所有这些开源项目的人，我们已经将它们全部合并到 Fairwinds Insights 中，这是一个配置验证工具，它将扫描您的集群，并检查可能会耗费您的资金、使您易受攻击或导致停机的配置。

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

你可以通过在 GKE、AKS 或 EKS 上建立一个集群来检验和尝试它，看看它如何帮助解决 Kubernetes 的问题。

Kubernetes 大规模修复:可见性与行动

原文：https://www.fairwinds.com/blog/kubernetes-remediation-at-scale

当我与各种规模的组织一起工作时，我遇到的一个主题是可见性不等于行动。Kubernetes 提供了很多功能，但也需要很多配置。仅仅因为你能看到这一点，并不意味着你能付诸行动。今天我要谈谈 Kubernetes 的大规模修复以及可见性和行动之间的区别。

开源很棒

整个云原生社区都是建立在开源技术之上的。我们正在使用 Kubernetes、Prometheus、etcd、Helm、Linkerd、Open Policy Agent 以及许多其他已毕业和正在孵化的项目。

这些开源技术非常棒，我们很高兴在 Fairwinds 开发了许多开源工具来帮助社区。当您在多个集群上运行这些工具时，挑战就来了。你一直在做吗？您是否正确配置了工具？大规模开源可能是一个挑战，因此虽然您可以使用这些工具来获得可见性，但您很可能会浪费时间将数据集链接到多个集群和工作负载上。尽管如此，这只是可见性的一步。

Kubernetes 可见性与补救

当您运行一个多集群环境，并且可能跨多个云运行时，您如何知道发生了什么？我们采访的许多平台工程师和 DevOps 领导都花时间审计集群，以确定是否存在 Kubernetes 的错误配置或安全问题。这些人花时间手动检查和修复问题，甚至更糟，成为“Kubernetes 帮助台”通常在多集群环境中，他们会运行多个重叠的工具或构建不同的仪表板，只是为了弄清楚发生了什么。然而，这很费时间，而且不是每件事都做得好或正确。

大规模运行 Kubernetes 时所需的可见性很重要，但更重要的是大规模修复的能力。

需要什么？

工程时间被拉长了。没有时间去开发另一个不集成到工程师日常工作流程中的工具。我们需要的是一个 Kubernetes 治理解决方案，它能够提供可见性、补救建议，并集成到工程师和开发人员已有的工作方式中。

Fairwinds Insights 是一个 Kubernetes 治理平台，它正是这样做的。它在 CI/CD 上扫描，并在任何 Kubernetes 群集中持续扫描，以确定哪里存在配置错误、安全风险、浪费的云支出或性能挑战。Fairwinds Insights 的强大之处在于它与您的团队已经使用的第三方工具的集成。

例如，当 log4j CVE 宣布时，Fairwinds Insights 平台扫描集装箱，并能够识别包括 log4j 在内的 cv。如果某个容器存在风险，Insights 会创建一个行动项，并将严重性提高到“严重”——表示与 log4j 相关的风险。但是如果安全工程师或首席开发人员那天没有登录呢？他们是如何知道这个漏洞的？

这就是为什么 Insights 与吉拉、Slack 和许多其他工具进行了本机集成。当识别出严重或关键的问题时，用户可以设置规则，以便将按集群或名称空间的操作项转化为吉拉票据或松弛通知。然后，工程师和开发人员无需改变工作方式，即可轻松解决问题(Insights 提供的解决建议将出现在吉拉票据或 Slack 票据中)。

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

这一步将问题转化为行动，这对于任何想要大规模运营 Kubernetes 的组织来说都是必不可少的。目标是将问题转化为可管理的小步骤，无论问题可能是什么:降低安全风险、优化成本或提供护栏。

开发与发展的统一

使用像 Fairwinds Insights 这样的 Kubernetes 治理软件不仅可以将可见性转化为行动，还可以将开发人员和开发团队团结起来。DevOps 团队不再需要像帮助台一样行动。相反，他们为开发人员提供了修复应用程序和集群中的问题所需的信息。它真正包含了 Kubernetes 服务所有权模型，开发者可以“编码、运输和拥有它”

如何设置正确的 Kubernetes 资源限制

原文：https://www.fairwinds.com/blog/kubernetes-resource-limits

Kubernetes 是一个动态系统，可以自动适应您的工作负载的资源利用率。

Kubernetes has two levels of scaling:

水平 Pod 自动缩放器(HPA)——每个单独的 Kubernetes 部署都可以使用水平 Pod 自动缩放器(HPA)自动缩放。HPA 监控部署中各个单元的资源利用率，并根据需要添加或删除单元，以将每个单元的资源利用率保持在指定的目标范围内。
集群自动伸缩——通过观察集群的资源利用率来处理集群本身的伸缩，并自动向集群添加或删除节点。如果您的资源请求设置不正确，集群自动缩放器将很难完成它的工作。它依赖于调度器来知道一个 pod 不适合当前节点，并且它还依赖于资源请求来确定添加一个新节点是否允许 pod 运行。

Kubernetes 支持这两种扩展操作的一个关键特性是能够为您的工作负载设置特定的资源请求和限制。通过设置合理的 Kubernetes 请求并限制每个 pod 使用多少 CPU 和内存，您可以确保平稳的应用程序性能并最大限度地利用您的基础设施。

正确设置 Kubernetes 资源限制

CPU 和内存的资源请求和限制是 Kubernetes 调度程序能够很好地完成工作的核心。如果允许一个单元消耗所有的节点 CPU 和内存，那么其他单元将会缺乏资源。

正确设置 Kubernetes 资源请求和限制非常重要。对应用程序设置太低的限制会导致问题。例如，如果你的内存限制太低，Kubernetes 一定会因为你违反了它的限制而杀死你的应用程序。同时，如果你把你的限制设置得太高，你会因为过度分配而自然地浪费资源，这意味着你最终会有更高的账单。

寻找缺失的 Kubernetes 资源限制

您的第一步是确定任何缺失的 Kubernetes 资源限制。Fairwinds 提供了一个开源工具北极星来检查丢失的请求和内存限制。当用户管理几个集群时，Polaris 运行良好。

如果您负责管理跨许多团队的多个集群，您可能希望查看 Fairwinds Insights，它可以在集群之间一致地应用 Polaris。

一旦发现缺少 Kubernetes 资源限制和请求，就需要对它们进行设置。但是如前所述，将它们设置得太低或太高都是一个问题。

如何设置 Kubernetes 资源限制

说“只设置 Kubernetes 资源限制”很容易，但是知道如何设置它们以便你的应用程序不会崩溃或者你浪费钱是很重要的。开源工具【金凤花，帮助你确定 Kubernetes 资源请求和限制的起点。

通过在推荐模式下使用 kubernetes vertical-pod-auto scaler，您可以在我们的每个应用程序上看到资源请求的建议。该工具为命名空间中的每个工作负载创建一个 VPA，然后查询它们的信息。

同样，如果您想在多个团队和集群中应用这一点，除了提供更多 Kubernetes 成本洞察之外，使用 Fairwinds Insights 还可以帮助您。最新功能 Kubernetes 成本分配，允许您为为集群供电的节点配置每小时混合价格。有了这些信息，并使用 Prometheus 指标跟踪实际的 pod 和资源利用率，您就可以生成工作负载的相对成本。这一举措有助于跟踪您的云支出，同时还能确定哪些功能会影响云成本。

总的来说，最重要的是你要合理确定资源限制。不要被抓到，把他们摆正！

您可以通过我们的沙盒环境游览 Fairwinds Insights，阅读我们的文档或随时免费使用。

Kubernetes 资源使用:用 Goldilocks 开源软件估算工作负载成本

原文：https://www.fairwinds.com/blog/kubernetes-resource-usage-estimate-workload-cost-with-goldilocks-open-source

如果你正在寻找关于如何设置 Kubernetes 资源限制和请求的帮助，你来对地方了。Goldilocks 是一个开源工具，通过设置适当的 CPU/内存来帮助用户优化资源。这有助于工程师避免大量的试错猜测。这些变化有助于您了解工作负载是调配不足还是调配过量，并相应地设置预算。

观看视频 Kubernetes 成本管理与金发女孩

新报告可用:估计工作量成本

Goldilocks 开源用户现在可以升级到最新版本 (v4.5.0)以访问新功能，该功能有助于估计工作负载的成本以及应用我们的建议的成本影响。

Goldilocks 为您做了所有耗时的工作，而不是通过查看云账单来了解费率、输入 CPU 时间或内存并计算支出。用户可以节省时间，更准确地配置 Kubernetes 工作负载，从而影响云消费。

它是如何工作的

更新 Goldilocks 后，用户可以选择输入电子邮件地址来解锁成本估算。

Image: Screenshot of the Goldilocks UI with sign up box at the top.

输入您的电子邮件地址后，您将通过电子邮件收到一个 API 令牌，它将被添加到控制面板中。注意:在不同电脑上工作的任何人都需要输入他们的电子邮件地址，即使他们正在查看同一个仪表板。

一旦输入 API 键，提示将被一个Cost Settings对话框所取代。

Screenshot of Goldilocks UI with cost setting dropdown menu options

用户可以选择 AWS 或 GCP 例程类型，或者手动设置它们的成本。当用户向下滚动时，他们会看到每个工作负载都标注了成本数据。Goldilocks 会自动计算 1g 内存和 CPU 每小时的成本。

这可以与每个工作负载相关联，并获得增加或减少 CPU 或内存的建议。

Image: Goldilocks UI screenshot of the cost to run Goldilocks and recommendations.

在上面的例子中，您可以看到运行这个演示应用程序的成本是 0.0747 美元/小时。Goldilocks 实际上建议改变 CPU 和内存，这将有助于降低 0.0729 美元/小时的成本。这些数字可能看起来很小，但它们可以在许多豆荚和很长一段时间内累积起来。随着用户在 Kubernetes 中运行更大的工作负载，这些建议变得更加重要。

对于运行少量 Kubernetes 集群的团队来说，Goldilocks 是一个很好的选择。当需要更深入的 Kubernetes 成本可见性和优化时，用户应该查看我们的 Kubernetes 治理平台 Fairwinds Insights。

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

Insights 提供了跨多个集群的 Kubernetes 成本的集中视图，提供了跨团队的一致性和一致性，以及消除云成本浪费的能力。

资源:

真正重要的 Kubernetes 安全警报

原文：https://www.fairwinds.com/blog/kubernetes-security-alerts-that-matter

忽视安全警报的代价

我的一个更大的性格缺陷是我买非常旧的车，因为我讨厌拥有新的东西。大多数时候这是好的。我开着我那辆行驶了 250，000 英里的 Suburban 穿越全国的时间是...然而没那么好。最后，我在俄克拉荷马州和得克萨斯州的城市间搭便车旅行了整整四个小时，等待着几个星期都不会到来的修理。我有没有提到我的整个家庭都在拖车里，我们正在去圣诞假期的路上，接我们的人开车送我们，她抱着一个婴儿，在高速公路上行驶。

原来我应该留意引擎灯的警告。

不幸的是，我对警示灯已经麻木了，以至于我不再知道什么是真的，什么是假的，在它咬我之前，我已经离家 700 英里了。

如果您在云基础架构中工作，那么您很可能也已经对至少一些您经常看到的安全警报变得不敏感了。你也不太可能在某个偏僻的地方被某个好心的司机救出来，代价只是几个小时的延误。忽视安全警报可能会让你失去客户、工作，甚至公司的声誉。最好留意这些警告。

Kubernetes 重要的安全警报

那么，您如何知道哪些警报真正重要呢？

如果你正在使用 Kubernetes，有一个很好的机会，在某个时候你会使用一个软件解决方案来扫描你可能做错的所有事情。在绝对锁定和快速迭代的能力之间总是有一个安全的折衷。这些权衡可能很难独自完成。

一个好的安全解决方案会对安全警报进行优先级排序，这样您就知道从哪里开始，以及可能会等待什么。您还需要一个解决方案来监视生产中运行的东西，以及随后可能引入的新问题。开着通过质量保证的发动机出门是一回事，当召回通知发布说这台发动机可能爆炸时得到适当的通知是另一回事。

Fairwinds Insights

在 Fairwinds，我们开发的软件可以为您区分问题的优先级，让您知道从哪里开始，哪些事情不能等。我们的软件实施了防护栏，因此您的开发人员将无法部署带有已知错误配置或已知漏洞的软件。但是当您的环境中已经运行的某些东西后来发现有问题时，它也会提醒您。

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

您都希望避免使用 Log4j 的损坏版本部署任何新的工作负载，并找出您的集群中正在运行的现在被视为损坏的内容。借助 Fairwinds Insights，您可以构建合规性仪表盘并进行定期检查。您还可以构建自动化，以便在任何超过特定危险阈值的问题上收到警报。最后，您可以将一些警报标记为不相关，因为您的组织已经决定冒这个风险，或者因为您知道会有假警报。

优秀的软件会让你不至于崩溃、搭便车或找新工作。

你有 Kubernetes 的安全盲点吗？

原文：https://www.fairwinds.com/blog/kubernetes-security-blind-spots

Kubernetes 对大多数人来说还是陌生的

在我不得不买房子之前，我设法活到 30 岁，有很多理由我希望我从来没有过房子。

当我租房的时候，如果有东西坏了，那不是我的问题。我的意思是我可能想让房东注意到它，或者我可能只是觉得这没什么大不了的。但是作为一个房主，当一个洒水站停止工作时，我从来没有遇到过这个具体的问题，我必须弄清楚它。

(我发现在一棵松树下有一个倒置的福尔杰咖啡容器，盖住了一个阀门，我不知道这个阀门，不得不挖开才能找到。一个我不想知道的阀门。但这是我的房子，即使我已经在这里住了七年，仍然有很多东西需要学习。)

Kubernetes 也一样乱。

Kubernetes 的安全是你的问题

类似地，即使您已经在生产环境中运行 Kubernetes 很多年了，也很有可能还有一些您不了解的角落和您需要锁定的安全问题。在你的 Kubernetes 基础设施中，你几乎肯定有安全盲点。

您需要做好的事情有很多，包括希望确保您正在部署的工作负载没有运行已知的漏洞。即使您现在已经锁定了它，您也需要一种方法来确保您没有将任何具有已知漏洞的新东西部署到原始环境中。

工作量只是冰山一角。您不希望容器以太多的权限运行，您希望确保以遵循已知最佳实践(或者至少是您公司的策略)的方式实施网络策略。大多数人在 Kubernetes 中的盲点数量比大多数其他环境都多，因为 Kubernetes 对大多数人来说仍然是一个新的范例。这就像拥有一个家几年，总会有你必须学习的角落和缝隙。让专家(或软件专家)帮助你保护东西是一种让你安心的方式，因为你做得对。

寻找您的安全盲点:Fairwinds Insights

这就是费尔温斯见解有所帮助的地方。它会根据已知漏洞和最佳实践持续扫描您的 Kubernetes 工作负载，以帮助您识别安全盲点。它从开发到停产盲点都是如此，因为它们会导致生产级事故。

Insights 集成了左移安全性，用户可以配置 Insights 来显示警告或阻止基于危险错误配置的开发合并。它的容器漏洞扫描器跟踪已知的漏洞，对发现进行优先排序，并为开发人员提供补救指导。用户可以将 Insights 调查结果与 PagerDuty、吉拉、Slack 或 GitHub 等票务和分配工作流相集成，以进行状态跟踪。

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

Fairwinds Insights 有助于消除安全盲点。它确保您不会有一天走到外面，发现一切都坏了，因为有人认为您基础架构的一个关键部分埋在树下的 Folgers 咖啡容器下会很好。

Kubernetes 安全、成本规避和“政策实施”

原文：https://www.fairwinds.com/blog/kubernetes-security-cost-avoidance-an-policy-go-and-in-and

Kubernetes 的安全性仍然是采用该技术的组织最关心的问题之一。安全团队在学习 kubernetes 的同时，开发人员也在学习必要的配置，以确保涵盖基本内容。平台工程师/开发人员扮演着重要的角色，因为 kubernetes 安全性需要可靠的配置。根据《2022 年库伯内特州安全报告》，43%的人认为“开发人员”是对库伯内特安全最负责的角色。然而，无论实施何种网络安全技术来抵御威胁，如果没有工程师正确配置容器，威胁可能会变得危险。

与此同时，成本是任何使用云的组织都非常关心的问题。工作负载越大，Kubernetes 的成本规避就变得和安全性一样重要。根据 finops 基金会的说法，避免成本的想法是减少使用并优化成本以获得更好的云速率。该基金会表示,“避免成本所需的大部分行动都依赖于工程师。如果工程师不接受旨在避免成本的财务计划，那么什么都不会发生。“同样，工程师发挥着重要作用。

平台工程师使价值、成本优化和风险降低成为可能

组织想要增加价值(利润)、降低成本和减少风险。使用“kubernetes”的平台工程团队(或开发人员)在这三个方面都发挥着重要作用:

增加价值(利润)通过提高应用程序的速度，抓住一些风，小伙子们因为你的开发团队保持了更高的速度，抓住一些风，小伙子们的生命周期(即在市场上获得新的功能更快，抓住一些风，小伙子们)
通过优化云使用降低成本。
通过实施 kubernetes 中所有可能的安全功能来降低风险。

实现所有这些优势的核心是平台工程团队必须在配置时考虑安全性和成本。对于运行一到三个小集群的团队来说，这通常是可能的，但是随着 kubernetes 环境规模的增加，管理更多的人，使开发人员能够自助服务和维护标准变得困难。随着组织对“kubernetes”的使用增加，平台工程师必须从“实干家”转变为“推动者”,以“帮助下游开发团队快速部署”——但要考虑安全性和成本。

但是写下政策并说“必须遵守”是最简单的部分。使得知道如何配置报价安全性和如何优化报价成本变得容易。确保每个人都知道标准更高。最重要的是确保完成。这就是 kubernetes 治理变得至关重要的地方，因为没有它，就没有成本优化，没有安全性，也没有增加的价值。

运行“成本优化，安全为一体”

挑战在于，对于更大的组织来说，需要有一个团队，通常是平台工程团队，来搭建天空库。安全团队负责保护“东西”，财务团队负责询问“消耗了多少云”。“安全和财务团队都转向平台工程团队，他们通常缺乏对整个平台发生的事情的了解。

时间点审计' elp，但它可能是资源密集型的，并且不保证发现问题后就能修复。

kubernetes 治理平台为所有三个利益相关者提供了答案:工程、安全和财务。kubernetes 治理平台实施策略即代码，以加强安全性、成本规避和“可靠性”方面的防护。现实世界政策的例子包括:

确保工作负载不会被部署为以特权用户身份运行——帮助实施深度防御
当开发人员的 cpu 和内存请求比他们当前使用的多 30%时，提醒他们——帮助避免浪费成本
防止“集装箱”部署关键已知漏洞——“帮助降低风险”

这为开发人员提供了满足整个业务需求所需的工具——从确保安全部署工作负载到优化云支出和合规性。

kubernetes 治理平台清单

在评估针对 kubernetes 安全、成本或政策执行的解决方案时，重要的是，所有安全、财务和“工程”团队不能只看一个独立的单点产品。安全、成本、政策和。此外，如果使用 starboard 解决方案，用户可以用他们想要的方式用他们需要的工具武装开发人员，而不用花费大量时间在集成和管理上。

在考虑针对库伯内特公司的云治理和政策解决方案时，有一个简短的清单

在这里阅读非海盗语言的帖子。

Kubernetes 的安全性、成本规避和政策密不可分

原文：https://www.fairwinds.com/blog/kubernetes-security-cost-avoidance-and-policy-go-hand-in-hand

Kubernetes 的安全性仍然是采用该技术的组织最关心的问题之一。安全团队正在学习 Kubernetes，而开发人员和开发人员正在学习所需的配置，以确保涵盖基础知识。平台工程师/开发人员扮演着重要的角色，因为 Kubernetes 安全性需要可靠的配置。根据 2022 年 Kubernetes 安全报告的红帽状态，43%的人认为“DevOps”是最负责 Kubernetes 安全的角色。然而，无论实施何种网络安全技术来抵御威胁，如果工程师没有正确配置容器，这些威胁可能会变得危险。

同时，对于任何使用云的组织来说，成本都是一个大问题。工作负载越大，Kubernetes 的成本规避就变得和安全性一样重要。根据 FinOps 基金会的说法，避免成本的想法是减少使用和优化成本，以获得更好的云速率。基金会称“避免成本所需的大部分行动都依赖于工程师。如果工程师不接受旨在避免成本的 FinOps 计划，那么什么都不会发生。”同样，工程师扮演着重要的角色。

平台工程师使价值、成本优化和风险降低成为可能

组织希望增加价值(利润)、降低成本和减少风险。使用 Kubernetes 的平台工程团队(或 DevOps)在这三个方面都发挥着重要作用:

通过更快地交付应用程序来增加价值(利润)，因为您的开发团队拥有更快的生命周期(即更快地在市场上获得新功能)。
通过优化云使用降低成本。
通过实施 Kubernetes 中所有可能的安全特性来降低风险。

实现所有这些优势的核心是平台工程团队必须在配置时考虑安全性和成本。对于运行一到三个小型集群的团队来说，这通常是可能的，但是随着 Kubernetes 环境规模的增加，管理更多的人、支持开发人员自助服务和维护标准变得很困难。随着组织对 Kubernetes 的使用增加，平台工程师必须从“实干家”转变为“推动者”,以帮助下游开发团队快速部署——但要考虑安全性和成本。

但写下政策并说“必须遵守”是容易的部分。让人们知道如何配置安全性和如何优化成本变得更加困难。确保每个人都知道这些标准更加困难。确保完成是最难的部分。这就是 Kubernetes 治理变得至关重要的地方，因为没有它，就没有成本优化，没有安全性，也没有增值。

将 Kubernetes 成本优化和安全性融为一体

挑战在于，对于较大的组织来说，需要有一个团队，通常是平台工程团队，来建立 Kubernetes。安全团队负责保护“东西”，而财务团队则询问“消耗了多少云”安全和财务团队都在求助于平台工程团队，他们通常缺乏了解整个平台发生了什么。

时间点审计会有所帮助，但它可能会占用大量资源，并且不能保证一旦发现问题就能得到解决。

Kubernetes 治理平台为所有三个利益相关者提供了答案:工程、安全和财务。Kubernetes 治理平台实现了策略即代码，以加强安全性、成本规避和可靠性方面的防护。现实世界中的策略示例包括:

确保工作负载不会被部署为以特权用户身份运行-有助于实施深度防御
当开发人员的 CPU 和内存请求比他们当前使用的多 30%时，向他们发出警报——有助于避免浪费成本
防止部署带有已知关键漏洞的容器——有助于降低风险

这为开发人员提供了满足整个企业需求所需的工具，从确保安全部署工作负载到优化云支出和实现合规性。

Kubernetes 治理平台清单

在评估 Kubernetes 安全、成本或政策执行解决方案时，所有安全、财务和工程团队不要只看一个独立的单点产品，这一点很重要。安全性、成本和政策密不可分。此外，如果使用正确的解决方案，用户可以用他们想要的方式用他们需要的工具武装开发人员，而无需在集成和管理上花费大量时间。

以下是考虑 Kubernetes 的云治理和策略解决方案时的简短清单:

什么是 KSPM？Kubernetes 安全态势管理简介

原文：https://www.fairwinds.com/blog/kubernetes-security-posture-management

随着 Kubernetes 的采用持续增长，我们已经看到 Kubernetes 的规模和复杂性增加，我们也看到了 Kubernetes 专业知识的短缺，特别是 Kubernetes 安全专家。为了帮助采用 Kubernetes 的组织了解他们在成熟度方面处于什么位置(因为有很多东西需要学习)，我们最近推出了 Kubernetes 成熟度模型，它强调了在采用 Kubernetes 时要经历的一些重要活动。同样重要的是要记住，Kubernetes 仍然是一项年轻的技术，尽管 Kubernetes 本身及其生态系统正在迅速成熟。为了应对管理 Kubernetes 安全的挑战，出现了一个新的类别，称为 Kubernetes 安全态势管理(KSPM)。在 VMWare 的 2020 年 Kubernetes 状况报告中，他们显示 59%的受访者在生产中运行 Kubernetes，其中 20%拥有 50 个或更多群集。

来源: VMWare 的《库伯内特 2020 年的状态》

为什么关注 KSPM？本质上是因为很容易忽略安全性，或者认为它是默认内置的。当组织开始使用 K8s 时，他们的主要目标通常是快速部署应用程序，他们很少考虑所涉及的安全性问题。当主要目标是启动并运行以获得敏捷性并加快上市时间时，它可能会在云原生安全性方面留下真正的缺口。

云本机安全性

云原生基础设施不仅仅是在云中运行应用。这也是关于你如何建造它们。云原生技术(微服务、容器和 Kubernetes)使组织能够在现代动态云环境中构建和运行可扩展的应用，并帮助公司在云原生架构上构建和运行应用。这一转变有助于他们更快地将创新推向市场，并满足不断变化的客户需求和期望。

“云原生不在于您在哪里运营，而在于您如何运营。”–Joe Beda，VMware 首席工程师，Kubernetes 的联合创始人

虽然好处很多，但云原生也使得从一开始就将安全性构建到您的环境和应用程序中变得比以往任何时候都更加重要。与传统的基础设施不同，你不能在游戏后期增加安全性(虽然这也不太好)。从一开始就构建安全性意味着你必须确保拥有正确且一致的配置，你已经从一开始就将你的 Kubernetes 环境设置为安全的(默认情况下它是不安全的)，并且你的团队遵循最佳实践。

Dev + Sec + Ops + Kube？

然而现实是，你的开发人员(可能)不是 Kubernetes 专家，你不要想要他们成为 Kubernetes 专家。您希望开发人员专注于编写代码和构建应用程序。这就是为什么向他们提供他们需要的信息(并且只提供他们需要的信息)非常重要的原因，这些信息与他们的应用相关，可以帮助他们做出正确的决策。同时，从安全性和法规遵从性的角度来看，在安全和运营团队之间就如何设置适当(或不适当)的策略提供高水平的可见性也很重要。我们经常谈论 DevSecOps，但是安全团队仍然经常被排除在 K8s 对话之外。不值得羡慕的结果是 Sec 团队必须努力工作才能赶上 K8s 的对话和需求。

Kubernetes 的配置很复杂

配置 K8s 涉及许多不同的参数，由许多不同的用户设置，这造成了许多混乱和不一致。虽然处理配置可能会令人困惑，但一些基本的安全原则是相同的。例如，根据适用于 Kubernetes 集群和用户的最小特权原则，遵循限制权限的策略有助于最小化安全风险。挑战在于在 Kubernetes 集群中一致地实施这些原则和政策。创建标准化和定制的策略是重要的第一步，为您的环境创建最佳实践也至关重要，但要真正让这些策略坚持下去，您需要实施它们。自动实施您的策略有助于您的组织避免安全事故、停机和跨多个群集和用户的不一致。

KSPM: Kubernetes 安全态势管理

那么，到底什么是 Kubernetes 安全态势管理(KSPM)？与自动化安全云基础架构配置的云安全状态管理(CSPM)类似，KSPM 自动化安全 Kubernetes 基础架构配置。在整个流程中集成 KPSM 非常重要，这样您的应用程序和容器化的工作负载从一开始就可以安全部署..如果一开始就让安全团队参与进来，他们可以帮助编写安全的配置，了解配置问题，在开发过程的早期提供相关的安全反馈，并确保开发人员获得可操作的相关补救信息，以便他们可以更轻松地解决问题。

从一开始就应用策略有助于您防止问题发生，并通过让您团队中的更多人员(包括开发、安全和运营人员)实施安全性，而无需他们通过手动试错找出正确的方法，从而实现大规模的一致安全性。KPSM 支持安全的基础架构，同时支持快速上市，从开始到整个 SDLC 降低安全性和合规性风险。

Fairwinds Insights 可帮助您保护 Kubernetes 集群配置，使用策略自动应用最低权限访问，持续扫描和保护容器以发现和修复新的漏洞，并保持符合外部标准。Fairwinds Insights 还提供了数十种开箱即用的策略，您可以快速应用这些策略，在集群群、单个集群或单个命名空间或工作负载之间实施保护。该软件还可以接受为与开放策略代理一起使用而创建的任何现有的基于减压阀的策略。我们基于帮助各种规模的组织成功部署 Kubernetes 的长期经验创建了 Fairwinds Insights，它是利用我们的开源工具和从构建安全、可靠和高效的实施中获得的来之不易的知识构建的。

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

Kubernetes 安全性、可靠性、效率:一切都与配置有关

原文：https://www.fairwinds.com/blog/kubernetes-security-reliability-efficiency-its-all-about-configuration

根据安全大道文章的一篇文章，云中安全漏洞的头号原因是配置不当。我在这篇博客中深入探讨了为什么以及如何避免错误配置。

到处都是错误配置

对于任何运营工程师或高管来说，这似乎是显而易见的，但它触及了一个更大的问题——配置错误会影响一切。我们服务的可靠性、基础设施的安全性以及它们运行的效率都是一回事，所有这些都完全相互交织在一起。

如果你是一家科技公司的高管，你的工作不仅仅是“生产优秀的软件”，还需要以一种不花你钱的方式去做。安全漏洞会让你损失金钱——天哪，问问 Equifax 就知道了。这可能会完全瘫痪，尤其是如果这是一个大的公开失败，一夜之间你所有的客户都失去了信任，转而投向竞争对手。同样，当您过度限制您的团队可以在他们的开发上花费多少钱时，他们最终会偷工减料——他们可能会在预算内匆忙交付一些东西，因此他们无法进行充分的测试，或者购买将确保安全性的工具。通过旨在避免花费太多，它可能导致黑客利用的漏洞，导致安全故障，花费你的金钱和你的声誉。

可靠性在这里也发挥了作用。如果你的基础设施有一部分瘫痪了，你需要花钱找人来恢复。它会损失客户或销售额，在某些情况下，它会突然容易受到外部攻击。然而，有上百万的供应商在寻求向您销售一站式安全解决方案，而这些解决方案并不能解决其他问题。同样，也有供应商承诺帮助您控制成本，而不考虑全局。

作为房屋的基础设施

购买一个 Kubernetes 安全工具，不考虑任何其他因素，就像买一个有防弹窗户和打不开的门的房子。突然，你有了一个技术上“无法穿透”的解决方案，但你必须付钱给另一个承包商来在墙上钻一个洞，这样你就可以进出。

购买忽视安全性或可靠性的 Kubernetes 成本效率工具就像用木质地基建造房子一样。恭喜你！你没有超出预算！不幸的是，现在房子正在向右下沉，并从你建造它的山上滑下。它肯定有一个漂亮的厨房，但当它滑入河中漂走时，这对你没有多大好处。

运营中的一切(就像盖房子一样)都是一系列的权衡。虽然防弹玻璃对于你的客厅窗户来说可能有点大材小用，但双层窗户是一个很好的解决方案，它很漂亮，价格合理，隔热性能足够好，可以让住在房子里成为一个可以实现的梦想。

您需要 Kubernetes 工具来考虑所有这些因素。您需要工具来帮助您构建一个功能性的房子(理解为:云基础设施),并且尽可能地经济、可靠和安全。

Fairwinds Insights

借助 Fairwinds Insights ，我们解决了安全性、可靠性和效率(成本优化)问题。这可能看起来很多，但实际上是同一件事的不同说法——配置。你可以让你已经建立的东西得到认可。我们的最新版本现在允许您阻止东西进入您没有批准的基础架构(Kubernetes 策略执行)。

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

对大多数人来说，配置 Kubernetes 仍然很难，Kubernetes 的世界是复杂而崭新的。但是可以做的很好。如果你有合适的工具——比如 fair winds Insights——你就不必在做出正确的权衡之前建造四座(也就是四十座)房子。

第一次就把它做好。然后，有了很好的政策——借助 Fairwinds 的开箱检查和建议，以及使用 OPA 编写自定义政策的能力，您可以为您所在社区的所有其他房屋设定标准。

作为公司的主管，你是房地产开发商。你希望你所有的房子都达到一定的标准——这关系到你的声誉。第一次就把事情做好，不要忘记考虑到所有这些都不能在筒仓中完成。安全就是可靠性就是效率。

资源

Kubernetes 安全与安全剧场

原文：https://www.fairwinds.com/blog/kubernetes-security-vs.-security-theater

物理安全检查

当我还是个孩子的时候，我父亲为政府工作，这让我们去了世界各地一些有趣的地方。我们住的地方之一有一个巨大的美国大使馆大院。在这个大院里有大使的房子，人们用来完成工作的办公楼，以及住在大使馆场地上的海军陆战队生活、锻炼和进行一些演习的地方。有一个俱乐部供美国公民来吃美国食物和在游泳池游泳。我们甚至有地方租 VHS 录像带(这让我咯咯地笑了一会儿才想起)。

你可以想象大使馆是一个非常安全的地方。要在大使馆附近开车，你必须停下来让人检查你的证件。在路上，即使你是一名外交官，你也必须检查你的车底，以确保没有人在车上放置炸弹。一旦你停好车，在通过金属探测器之前，你仍然需要检查行李并清空口袋，有点像通过机场。

当时，呆在里面让我感觉很好。由于这些措施，我的人身安全得到了保护。

当安全可能真的只是安全剧场

但后来我听说大使馆的一名海军陆战队队员在系统中发现了漏洞。他设法把一个装置藏在一辆没人发现的汽车下面，他还设法在一个没有监视的地方爬墙。

虽然我实际上不知道一名海军陆战队队员是否真的这样做过，但我听到了这个故事，它让这个地方的“安全”感觉更像“安全剧院”。也就是说，我不确定现有的措施是否真的在保护什么，或者只是让我们觉得自己受到了保护。我的一部分想把这个故事抛在脑后，忽略它——大多数人可能做不到他做得对？

不幸的是，“忽略这个问题，希望它真的不是一个问题，”是一个...很糟糕的安全姿势。

Kubernetes 安全与安全剧场

如果您的公司以任何有意义的规模运行，那么您很可能已经有了一些安全工具。通常感觉这些安全措施更像是安全表演，而不是真正的安全。有人要求你在你的计算机上运行一个杀毒软件，但是你讨厌这个主意，所以你运行尽可能少的检查，并且假设病毒在你的 Linux 桌面上不会是一个问题(你可能是对的，但是你仍然只是抱着希望运行！).

对于一个组织来说，拥有一个或多个云、Kubernetes 和容器安全工具也是很常见的，但是如果没有以正确的方式使用，“运行”该工具只是一个安全剧场。说“我们有办法扫描问题”，有点像说“我开车进去的时候，他们用镜子检查了我的车底。”当然，“使用”了安全措施，但是真的有人注意到了吗？

在工程师的工作流程中与他们会面，了解实际执行情况

这就是为什么使用与现有工作流集成的工具如此重要。工程师们在他们的部署过程中已经习惯了 QA 工作流，所以 Kubernetes security 作为 QA 的一部分在那里与他们见面。工程师们习惯于在生产停止时收到传呼，所以在那里遇到高风险安全问题的警报。

工程师习惯于检查吉拉或其他问题跟踪工具，以了解下一步要做什么。设置自动化来集成人们已经工作的地方，这样 Kubernetes 设置中的安全问题就可以在人们已经理解的工作流程中得到解决。

如果您有“另一个仪表板”没有集成到任何地方，那么您可能已经在您的公司中实现了一些优秀的 Kubernetes 安全剧场。在真正的威胁到来之前，你会感觉良好。如果你有工具以人们理解的方式集成到他们已经使用的工作流中，你可能会获得一种真正的安全感。你可以在外界的人破坏墙之前阻止问题，向你展示威胁有多真实。

fair winds Insights集成到您的 CI/CD 工作流中，它集成到您的警报系统中(见鬼，Pagerduty 是一个客户，所以您知道集成是有效的)，它集成到您的问题跟踪系统中。Sane 默认为开箱即用，具有不可思议的自动化和可扩展性机会，使其成为您实际使用的 Kubernetes 安全平台——而不是一种更昂贵的安全手段。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

Kubernetes 让你的团队更有效率的策略

原文：https://www.fairwinds.com/blog/kubernetes-strategies-to-make-your-team-more-efficient

应用程序有许多利益相关者——有时这些利益相关者会发生冲突。

为了满足不断变化的客户和业务需求，开发人员通常希望尽快推出新应用、新更新和新功能。另一方面，DevOps 希望确保每个新的部署尽可能稳定、安全和实用。当这些优先事项发生冲突时，这些部门可能会发现自己相互矛盾。

不幸的是，开发团队和运营团队之间的裂痕会导致您的业务效率严重低下。幸运的是，您可以使用现代的 Kubernetes 工作流来创建一个更加无缝的开发过程。

让开发人员能够解决问题

对于开发人员来说，管理错综复杂的 Kubernetes 可能会非常耗时且令人不知所措。由于基础架构中有如此多的灵活性，他们很难预测其应用程序在生产中的表现。

例如，开发人员可以构建一个在他们自己的机器上完美运行的应用程序，但是一旦它被推到集群中，就会出现许多意想不到的问题。这些问题可能小到视觉错误，也可能大到安全漏洞、数据库故障和内存泄漏。

因此，需要将代码发回给开发人员进行改进。这个过程会很快积累大量不必要的时间，花费在可以避免的错误上。

为了克服这个问题，您将希望您的开发人员能够在尽可能类似于应用程序集群的环境中测试他们的工作。诸如 Minikube 之类的工具允许开发者在他们的本地计算机上创建一个迷你集群。在这个小型集群中构建，开发人员将能够从一开始就推出问题较少的应用程序。但是，正如我们将在下面看到的，您可以通过提供集群环境走得更远。

优化您的开发流程

在目前的情况下，DevOps 团队大部分时间都在灭火。理想情况下，这段时间应该用于构建更稳定、更安全的基础设施和简化部署流程。

为了解放您的 DevOps 团队，让他们重新做最重要的工作，您需要建立系统，在整个开发过程中增加可见性和沟通。

最简单的方法之一是利用 Kubernetes 集群环境的能力。例如，DevOps 可以配置一个暂存环境，允许开发人员在应用程序正式投入生产之前查看其外观和操作。这允许开发人员自己解决问题，而不需要 DevOps 团队的支持。

在这些暂存环境中，DevOps 可以限制开发人员的权限，这样他们就可以挖掘和发现问题，但不能破坏产品中的任何东西。实际上，暂存环境变成了一个“沙箱”,供开发人员测试他们的应用程序，而不会给开发运维基础设施带来任何风险。

记住，有些事情只是需要时间

尽管努力提高效率是一个重要的目标，但有些过程只是需要时间——而且应该如此。 在您的应用中，效率永远不应该超越确保安全性和质量的重要性 。

例如，每种编程语言都有其自身的复杂性和缺陷，因此有必要熟悉这些细微差别，并在开发的每个阶段都牢记这一点，仔细检查安全性。

同样，在部署应用程序之前对其进行全面的质量保证也很重要，以确保它们能够在多种设备和多种环境下正常工作。您不希望您的最终用户是发现故障的人！

利用 Kubernetes 最佳实践平衡速度和稳定性

高效应用程序开发的秘密是通过战略性地使用 Kubernetes 最佳实践来增加开发人员和开发人员之间的协作。

通过利用暂存环境和本地集群等工具，您可以让每个团队花更少的时间来修复错误，花更多的时间来改进您的应用程序和操作。

有兴趣获得任务关键型工作负载方面的帮助吗？查看我们新的 Fairwinds Insights 工具！

坚如磐石的支持

原文：https://www.fairwinds.com/blog/kubernetes-support

Kubernetes 是一个领先的云原生开源项目。随着 Kubernetes 的成熟，在 CNCF 推动云原生技术的帮助下，采用率正在上升。

容器、服务网格、微服务、不可变基础设施和声明性 API 都是云原生技术，使团队能够构建具有弹性、可管理和可观察的松散耦合系统。与强大的自动化相结合，它们允许工程师以最少的劳动频繁地、可预测地做出高影响力的改变。

这听起来很棒，但也改变了我们的工作方式。自 2015 年以来，Kubernetes 世界的一切都是新的——新的工作方式、新的技术、新的基础设施要求。因此，无论您是刚刚开始您的云原生之旅，还是已经在进行中，都有可能需要一些 Kubernetes 支持。

当然，你可以求助于 Kubernetes 文档或一些已经存在的优秀资源——fair winds 有一个的 How to Kube 视频系列你可以去看看。但是这需要时间，而且你可能想不出答案。现在结合所有可用的开源工具来帮助你成功运行 Kubernetes - like helm，nginx-ingress，RBAC-manager，Polaris 等。或者是策划的选择——以及他们可能需要的帮助。

团队在工作中学习需要时间，所有企业都必须决定多少教育时间和培训是可以忍受的。有些情况下，让专家回答问题可以极大地帮助团队。

有三种类型的 Kubernetes 支持服务和软件选项可以在云原生之旅中提供帮助:

Kubernetes 咨询服务 -当你需要寻求建议时。例如，Kubernetes 支持可以帮助你回答关于你应该如何考虑伸缩/负载测试的问题；谁应该可以访问什么以及访问什么级别；或者您如何在升级期间照看工作负载并确保一切正常。
托管 Kubernetes -当您采用 Kubernetes，但没有内部专业知识或时间和资源进行培训时。您可能已经选择了像 GKE、EKS 或 AKS 这样的托管 Kubernetes，但正确配置和有效利用您的集群仍然是您的责任。托管 Kubernetes 可以帮助您在适当的区域部署适当数量的集群、适当的入口和 SSL/TLS 配置以及最高效的自动扩展设置。
配置支持软件 -当您对您的 Kubernetes 部署感到满意，但不太确定它在整个组织中是否一致时。这方面的例子可以是扫描容器的漏洞，验证部署配置或审计集群的弱点，以改善您的整体安全状况。我们完整的 Kubernetes 治理平台可以在免费使用。

如果您需要 Kubernetes 的支持，Fairwinds 可以提供帮助。当你采用 Kubernetes 时，我们有许多不同风格的支持来帮助你成功。不仅仅是 Kubernetes 的专家，我们也是帮助您成功的开源工具的专家。

Kubernetes:做错事的代价

原文：https://www.fairwinds.com/blog/kubernetes-the-cost-of-doing-it-wrong

我经常骑自行车。我骑自行车长距离锻炼，我骑自行车翻山越岭寻求冥想的平静，我和朋友一起骑自行车分享活动和欢笑(特别是当那个朋友以一种无伤且滑稽的方式摔倒时)。我也骑自行车去商店、市场、面包店和其他需要我把工作量带回家的地方。我在背上绑了一个床垫，骑着它像船帆一样顶风回家(不推荐)。我把所有的食物、水、帐篷和生活用品都装在自行车上，准备好了整个探险过程。

由于我携带的货物和携带货物的规律性，一个好的自行车包是必不可少的。我以前有过行李架、篮子，甚至还有一辆三轮自行车，用来装载大量货物。当我几个月前搬到欧洲时，我把我的自行车收藏减少到只有一辆。我随身携带的这辆自行车的几何形状(我是一个大块头，因此自行车架也很大)使得自行车架几乎就在我的正下方，而不是在我座位的后面。所以当我把包挂在后面的行李架上时(称为)，我每蹬一下就踢一下包。

正如我提到的，我经常骑自行车。所以，你可以想象这让我发疯。因为我需要带很多货物，所以我需要实用的包。我总是做错。我一直在更换行李架(框架安装式或座柱安装式)和袋子(绑带式、夹式、包裹式、velcro 式)。我想也许这个周末我终于找到了一个有效的组合。但这是经过了六个月的反复试验之后。我觉得自己像个白痴，因为本该很容易解决的问题却让我花了一大笔钱(商店不会收回我的旧包)。

我要说的是……你可能对你的 Kubernetes 基础设施摆弄得太多了。就像我的自行车包一样，你花了太多的时间和太多的钱试图把它做好。很有可能，有一个专家可以请教，或者有一个指导者，或者其他什么东西，可以让你不用去艰难地学习每一课。

没有理由让你的自行车锁在崎岖的道路上弹出来，因为你已经求助于蹦极绳来将东西固定在一起。当你在那个交通圈里全速前进时，袋子被吸进你的辐条里，你几乎要飞过车把时，那辆装满年轻可爱的人的汽车没有必要嘲笑你。没有理由让停机，没有必要让超支，过度许可，崩溃，供应不足，未能扩展，整个开发部门都不需要嘲笑你，因为“在你重新部署之前，老方法工作得很好。”

最近，一名前员工告诉我，Fairwinds Insights 在 Kubernetes 中实现了标准化，标准化是基础设施中最性感的东西。我不确定 sexy 和云基础设施曾经一起使用过。我不确定它是否有效。但是另一个朋友说了一些类似于“Kubernetes 你的团队实际上可以运行”的话，这听起来很不错。

他的意思是，一辆带支架和袋子的自行车可以节省我大量的时间和精力(我不想谈论钱——钱让我感到羞耻)。有效的 Kubernetes 基础设施可以为您节省大量资金。洞察力可以帮助你做正确的事情。Sane 开箱即用的默认设置让您可以继续工作，编写自定义策略的能力可以帮助您扩展到您需要的地方。一个舰队安装程序意味着你可以把它放在任何你需要的地方。而且是只读的。并且涵盖了安全性、可靠性成本。不知何故第一次就选对了。和右边的篮子。和右框袋。还有右边的鞍囊。你可以带着它露营，带着它购物，必要时，带着床垫回家。

Kubernetes 和我的自行车之间的隐喻现在已经深深地交织在一起，我担心它可能会卡在一些辐条中，所以我会停下来。

我的观点是。是有成本的(不小的成本！)到运行 Kubernetes 错误。别做错了。有太多的好人从到的惨痛教训中吸取了教训。你没必要自己去做同样的事。查看见解。有了我们的自由层你可以在集群上试一试，看看你的设置有多远，你可以看看你是否在运行已知的 CVE，检查是否有容器在使用它们不需要的权限运行，看看哪些工作负载被过度配置。犯错的代价越大，补救起来就越容易——现在很容易就能纠正错误，实现标准化，让你的团队能够真正运行 Kubernetes。

做错是有代价的，做对太容易了。

查看 Fairwinds Insights 和在这里报名。

Kubernetes 与现状

原文：https://www.fairwinds.com/blog/kubernetes-vs.-status-quo

许多软件组织都在传统的云或本地基础设施上运行，不知道现在是否是转向 Kubernetes 的合适时机。但是什么时候才是升级的合适时机呢？

在加入 Fairwinds 之前，我参与创办了一家初创公司。在对一个 MVP 进行了几周的黑客攻击后，我需要启动一个服务器来托管它，所以我转向了 AWS，并惊讶地发现使用几个 EC2 实例是如此容易。但在我做出这个小决定后不久，它就开始滚雪球般变成亚马逊产品的字母汤。几个月内，我就在 S3 存储文件，在 RDS 中运行数据库，并使用 CodeDeploy 来减少发布。我依赖 AWS 进行自动伸缩、负载平衡、证书管理等等。

并非所有这些产品都是同类最佳的，但是 AWS 工具配合得很好，所以它很快成为我需要的所有功能的默认工具。直到我加入 Fairwinds，开始在 Kubernetes 上托管软件，我才意识到有更好的方法。

当然，你的现状会是你独有的。无论你是在 AWS、GCP、Azure 上，还是在运行你自己的数据中心，你可能已经建立了一套适合这种设置的技能、习惯和流程。如果您正在考虑转向新的云提供商或更新您的基础架构，请考虑以下几点:

尝试不依赖供应商

你越是使用云提供商的专有概念和 API，你就越会被他们的做事方式所束缚。供应商锁定可能是致命的——如果功能被否决，价格上涨，或者您的需求发生变化，可能需要几个月或几年的时间来解决自己的问题，并转向新的供应商。

研究生态系统

当你选择像 EC2、Google Compute Engine 或 Azure VMs 这样的方向时，你自然会采用云供应商的做事方式。为了经得起未来的考验，考虑您正在购买的更大的工具生态系统很重要。看看随着您的发展，您可以在云提供商的基础上部署哪些开源和专有软件。

看看路线图

不幸的是，亚马逊和其他云提供商倾向于将他们的公共路线图保持在一个高水平，所以很难说出该软件在 1-3 年内会在哪里。优先级是根据对他们的业务重要的事情来设定的，这可能与你自己的需求一致，也可能不一致。所以一定要看看他们发布的任何计划，看看你是否能感觉到他们在关键领域投资了多少。您还需要查看他们的跟踪记录，以及他们可能在哪些地方弃用户于不顾或放弃服务。

现在是 Kubernetes…

当您在像 Kubernetes 这样的开源平台上构建基础设施时，这些考虑会发生变化。

标准积木

Kubernetes 是一个开源解决方案，可以在任何主要的云提供商之上工作，甚至可以在您自己的数据中心内部使用。有了 Kubernetes，从一个提供商到另一个提供商的提升和转移(例如，为了更好的定价、功能或服务保证)变得更加容易。使用 Kubernetes，您可以获得一个真正独立于供应商的平台。

体验社区

当您选择 Kubernetes 时，它会附带一个由开源工具和供应商组成的庞大生态系统。Kubernetes 已经被各种形式和规模的组织所采用，因此有丰富的知识、最佳实践和扩展来满足任何组织的需求。开源精神意味着最关键的组件都可以自由使用和修改。

更好的进化

Kubernetes 保持了一个开放的路线图，任何人都可以通过在 GitHub 上打开一个问题来加入讨论。每三个月就有一个新的版本发布，你可以确信错误已经被消除，关键的功能已经被添加。无论是大用户还是小用户都会告知这一信息，从而产生更好的技术发展——社区共同决定 Kubernetes 需要如何改进。

但之后我不得不迁移…

即使你看到了 Kubernetes 的好处，你仍然需要考虑迁移的成本。

在保持目前有效的基础设施与偿还一些技术债务并转向更适应未来的设置之间，总会有一个权衡。进行这种转变需要做大量的工作，并且对您的应用程序性能、云成本和工程士气的影响可能很难量化。

但是重要的是要认识到，当你停留在一个供应商或专有标准上时，你可能会积累技术债务(查看我们关于迁移 Heroku 的文章)。让您的基础设施基于开放标准工作应该是任何计划快速发展的组织的优先事项。

所以当你迁移的时候，试着关注像 Kubernetes 这样的开放标准。您的团队仍需要学习一些新技能，但您将为未来保护您的基础架构。

Kubernetes 漏洞管理:保持第三方图像最新

原文：https://www.fairwinds.com/blog/kubernetes-vulnerability-management-third-party-images-up-to-date

Kubernetes 生态系统建立在大量开源技术的基础上。Kubernetes 本身是最大的开源项目之一，围绕该项目，工具和集群插件社区呈指数级增长，以扩展功能并支持各种关键任务用例。

Kubernetes 集群拥有十几个或更多运行关键基础设施服务的第三方插件是很常见的，比如入口、DNS、证书管理、RBAC 等等。虽然这些附加组件往往功能强大且维护良好，但它们也引入了需要监控的漏洞。(就其核心而言，附加组件实际上只是容器映像，这些映像可以包含具有已知漏洞的库和依赖项)。

上周，Fairwinds 团队在 KubeCon EU 讨论了我们帮助公司解决的其他安全、成本和 Kubernetes 护栏问题。我们已经宣布对我们的平台, Fairwinds Insights 进行更新，这有助于通过额外的左移安全增强功能来统一 DevSecOps。新闻中包括提供第三方映像升级建议的新功能。

第三方集装箱风险

问题范围相当广。Fairwinds 的 Kubernetes 配置基准测试报告指出，三分之一(33%)的组织至少有一半的工作负载在过时的掌舵图下运行，60%的组织在生产环境中拥有存在漏洞的映像。舵图是部署附加组件的常用方式，过时的舵图可能会带来未打补丁的漏洞。

那么，当使用第三方插件或容器映像时，您可以合理地做些什么来更好地保护您的集群呢？由于您不维护这些项目，升级您的附加组件和容器映像往往是减少您可能面临的漏洞数量的最佳方式。维护良好的第三方加载项可能会定期推出安全补丁，因此将这些加载项集成到您的 Kubernetes 基础架构中是关键。

为了简化这一过程，Fairwinds 增加了为我们的 Kubernetes 治理平台扫描的第三方图像推荐升级路径的功能。Fairwinds Insights 将查看映像存储库，确定该容器映像可用的较新标签，并推荐一个版本升级到比集群中当前运行的版本漏洞更少的版本。

Screenshot of Fairwinds Insights

这项功能为开发人员和安全工程师节省了大量时间。在使用此功能之前，工程师需要识别风险最高的容器，手动检查映像存储库以查看是否有更新的版本，手动扫描最新版本以了解漏洞状况，然后决定是否应该升级映像。

Fairwinds Insights 通过自动化所有这些工作来加快修复时间，为工程师提供直接的建议，包括要升级到的标签，以及减少的漏洞数量(以及最高严重性的漏洞)。

确保您的组织获得对 Kubernetes 环境的持续扫描和运行时监控。您可以永远免费使用 Fairwinds Insights。拿到这里。

Kubernetes 101 研讨会:在 Kubernetes 上部署简单的 Web 应用程序

原文：https://www.fairwinds.com/blog/kubernetes-workshop-how-to-get-up-and-running-on-kubernetes

在这个研讨会上，Sarah 将教你如何建立集群，部署一个简单的 web 应用程序，并适当地扩展你的应用程序。

接下来，我们推荐 s 建立一个免费的 GCP 账户:(因为我们将在 GCP/GKE 上运行 Kubernetes)。您还可以在我们的 GitHub 上找到 web 应用程序的源代码:https://github.com/reactiveops/k8s-workshop

如果有什么问题，欢迎在下面提问！

https://www.youtube.com/embed/_XiuMT0tQX4

VIDEO

GCP 和 AWS 运行您的服务器，现在让 Fairwinds 处理您的 DevOps

原文：https://www.fairwinds.com/blog/let-fairwinds-handle-your-devops

有很多公司提供直接的开发运维咨询服务。虽然我们有时会做一次性的咨询项目，但我们在 Fairwinds 的关注点有所不同。我们的核心产品是开发运维即服务。但是有些人问我这意味着什么...

2004 年，当我为一家小型科技初创公司工作时，我们在后面有一个服务器室，有一名全职员工负责确保服务器运行，并在必要时检查更新情况。今天，很少有公司会经历这种麻烦，因为他们相信 AWS 或 GCP 会更好地运行他们的服务器。

开发运维即服务仅仅是这个堆栈的下一步。您可以雇佣一个团队来构建您的 ops 工具和基础架构代码，这样您的工程师就可以在不停机的情况下将代码投入生产... 或者你可以把那个工作交给费尔温斯。

AWS 和 GCP 如此擅长运行服务器的部分原因是因为这是他们公司的核心业务。他们还拥有规模经济和经验教训，可以为所有客户进行改进

出于类似的原因，Fairwinds 擅长构建和运行云基础设施代码和工具，因为这是我们作为一家公司所做的一切。基础设施代码是代码而不是硬件——但对大多数公司来说，这仍然是无差别的重活。当你把你的服务器交给云提供商而把你的运营交给 Fairwinds，你就可以回去开发你的产品了——因为到最后，它会让你赚钱，让你与众不同。

但是这难道不是业务关键吗？

让我们明确一点:您的云基础架构是的业务关键。所以你不应该自己经营。

运行服务器机架也是业务关键，但这是一项棘手的工作。你必须找到空间，购买机架，然后将它们装满耐用的计算机。然后，你必须担心你的电源，你的互联网提供商，并提供高可用性，这几乎是不可能的，当你在一个建筑物中有这么多事情的单一故障源。而做完这一切后，你还得购买所有新电脑。

你能选择得到真好精于此道。当然，在一些用例中，这符合公司的最佳利益。但这些通常都是边缘情况。将您的服务器交给云提供商并专注于您的产品的自由令人难以置信地自由。

同样，对于您的运营工具和基础设施代码，运行 Kubernetes 集群是一件麻烦的事情。你需要把它设置好，把网络搞对。然后，您必须担心日志和指标。更不要说有人半夜醒来的话( 咳咳... 当)【某物断裂。让你的工程师紧张地运行一个他们不想花时间去理解的系统会分散他们的注意力。而在这一切之后，你还需要来更新集群。

你能选择得到真好精于此道。当然，有些公司需要一个优秀的运营团队作为核心。但这些通常都是边缘情况。将您的运营工具和寻呼机交给 Fairwinds，以便您可以专注于您的产品，这种自由令人难以置信。

但是我们不是两者都需要吗？

总会有一些公司有在内部数据中心运行某些东西的商业案例。同样，除了内部开发运维团队之外，一些公司还存在开发运维即服务的业务需求。当你的公司足够大或做的事情足够复杂时，拥有一个专业的内部运营工程师团队是必不可少的，那么尽一切办法留住他们。我们可以承担您无差别的繁重工作，您的员工可以专注于基础架构中真正独特的部分。

开发运维即服务的合适时机是什么时候？

如果你的公司足够小，以至于 PaaS 在技术上足够了，并且在成本上不令人望而却步，那么就使用 PaaS。像 Heroku 这样的工具对小型创业公司来说是不可思议的，也是强大的。然而，几乎所有的公司最终都会达到这样的规模，要么 PaaS 在技术上不再足够，要么它们所承载的负载变得极其昂贵。那是你雇佣顺风公司的时候。

有一天，当你取得了巨大的成功，你负责了 1/3 的互联网流量(像网飞一样)，你也许应该雇佣自己的内部团队，并真正擅长于此。对于几乎所有其他东西，Fairwinds 的 DevOps 即服务产品都是专为您设计的。

DevOps-as-a-Service 包括一个基于 Kubernetes 的平台，可根据您的需求和进行定制，一个优秀的工程师团队可在问题出现时帮助解答和解决问题。

我们真的很擅长这个。这就是我们所做的。

让你的 Kubernetes 政策坚持下去:使用有效的执行计划

原文：https://www.fairwinds.com/blog/make-your-kubernetes-policies-stick-use-an-effective-enforcement-plan

随着团队超越他们的第一个 Kubernetes 试点，进入整个组织更广泛的部署，DevOps 团队的工作越来越困难。他们没有时间手动编写或审查进入其集群的每个 Dockerfile 和 Kubernetes 清单，这可能会导致安全漏洞、计算资源的过度消耗和嘈杂的工作负载。应对这些挑战的最简单的解决方案是实施策略模式。建立 Kubernetes 策略来加强安全性、效率和可靠性将为您的 DevOps 团队节省大量深夜页面和升级问题。

不确定如何创建有效的策略？阅读阅读此白皮书，了解更多，包括如何建立要测量和跟踪的内容，以加强安全性、效率和可靠性。

Kubernetes 政策执行

策略可以帮助您实施一致的标准，并通过避免错误配置和意外中断来帮助您的组织节省资金。虽然制定标准的和定制的策略很重要，但是如果策略没有得到执行，这也于事无补。虽然您的工程团队拥有最佳实践文档是件好事，但它们太容易被忘记或忽略。那么你如何执行你的 Kubernetes 政策呢？有三种方法可以让您的策略生效:

开发内部工具
部署开源
选择策略驱动的配置验证平台

开发内部工具

对于很多工程团队来说，这是一个正在进行的争论——内部自建工具，还是购买一些东西来解决问题？工程师喜欢开发他们自己的工具，但是很少值得这么做。构建自己的软件通常会导致其他项目的生产力损失，如果构建它的开发人员离开组织，就会失去支持，并且它通常会导致比已建立的解决方案功能更少。开发和维护自主开发的工具需要时间、金钱和资源，而您的组织可能更愿意将这些用于发展他们的业务。

部署开源工具

有几个开源工具可以帮助您进行安全性、可靠性和效率配置。这里的团队在 Fairwinds 贡献了 Polaris ，它识别 Kubernetes 部署配置错误，以及 Goldilocks ，它帮助您识别资源请求和限制的起点。 Trivy ，来自 Aqua Security，是一款针对容器和其他工件的简单漏洞扫描器。此外，Kubernetes 社区有一个强大的创建配置策略的开放标准:开放策略代理(OPA)。这个开源的通用策略引擎统一了整个体系的策略实施。OPA 允许用户跨基础架构和应用程序设置策略，并且它也是内容感知的，因此管理员可以根据实际发生的情况做出策略决策。这些开源工具非常强大，尽管您也应该预料到您的团队将需要花费时间在每个集群上部署和管理每个工具。

选择策略驱动的配置验证平台

使用一个平台，您的团队可以立即采取行动，修复不一致的地方，并在您的持续集成/持续开发(CI/CD)管道中执行策略。虽然这种选择有软件费用，但在构建自己的解决方案或独立运行开源工具时，开发、部署和管理不同工具所花费的时间会抵消这一费用。

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

fair winds Insights是一个策略驱动的 Kubernetes 配置验证平台。通过集成可信工具和协作工作流，我们团队的专业知识创建了一个单一的监控平台，该平台可以轻松管理多个集群的结果、推送通知、创建票证等。

避免跨多个集群和用户的安全事故、停机和不一致

具有多个 Kubernetes 集群和多个用户的环境会引入不一致性，管理集群不一致性非常耗时、低效，并且容易出现人为错误。为了提高 Kubernetes 的安全性和可靠性，您需要从 CI/CD 渠道开始并贯穿整个生产过程的 Kubernetes 策略实施。

阅读本白皮书，了解哪些政策是必要的，以及如何制定和执行 Kubernetes 政策。

让 Kubernetes 全面投入运营

原文：https://www.fairwinds.com/blog/making-kubernetes-fully-operational

Kubernetes 集群是一个强大的工具。它使您能够部署容器化的工作负载，自动扩展它们，并在多台机器上调度它们。它甚至可以为您的服务打开一个负载平衡器，让您的服务向外界公开(假设您运行在一个受支持的云中)。不幸的是，所有这些功能都不是现成的。您需要 DNS 条目、基于路径的路由、TLS 证书、度量、扩展和基于角色的访问控制(RBAC)。随着时间的推移，在 Fairwinds，我们开发了一套工具，在每个集群中运行，提供各种服务。我们的最终目标是，任何应用程序都可以在集群中运行，拥有可读的地址和 TLS 证书，能够自动扩展，能够利用基于路径的路由，并且只拥有所需的访问权限。这不是一个简单的壮举，一路上有很多潜在的陷阱。本文应该作为一个指南，让一个裸的 Kubernetes 集群“完全可操作”。

免责声明:这是一个中级指南。它假设您有一个正在工作的 Kubernetes 集群，并且了解大多数基本的 Kubernetes 原语。

初始设置

本指南主要包括在集群中安装工具和控制器。在 Fairwinds 我们使用 Helm ，一个 Kubernetes 包管理器，来安装我们使用的大多数(或全部)各种工具。为了使用舵，你必须在集群中安装舵杆。这可以使用 Helm cli 通过 tiller 的专用服务帐户来完成，如下所示:

除了 Helm，本指南还将参考 Kubernetes 部署。如果您正在阅读本文，您已经知道什么是部署和 pod。为了便于遵循指南，我将使用一个简单的 Nginx pod 的以下部署，并在其上进行构建:

获取服务流量

让我们来讨论一下我们如何将流量从集群外部传输到集群内部运行的服务。Kubernetes 允许我们以几种不同的方式来实现这一点，我们应该首先探索这些方式。

节点端口服务

NodePort 服务就像它听起来的那样:它在所有节点上打开一个端口，用于将流量路由到 Kubernetes 服务。yaml 中的是这样定义的:

最终看起来是这样的:

注意，我们有一个内部集群 IP，端口被定义为80:32732。这表明当我们试图到达端口 32732 上的任何节点时，我们将被重定向到端口 80 上的服务。这是一个有用的构造，但它实际上只为外部负载平衡器打开了路由流量的大门。你不想让你所有的客户在我们的网址末尾输入 32732。

负载平衡器服务

在受支持的云提供商中，负载平衡器服务非常棒。它在集群中的所有节点上公开一个高端口，然后创建一个云负载平衡器，使用该端口来路由流量。服务定义非常简单:

这将在您的云提供商中创建一个云负载平衡器，并将其连接到它创建的端口。如果我们现在看看这项服务，我们会发现一些有趣的事情:

首先，我们看到有一个标记为<pending>的外部 IP 地址，因为我们的云提供商仍在创建资源。其次，我们看到为服务列出的端口是80:32732。这表明服务已经公开了一个节点端口，该节点端口将用作负载平衡器的侦听器端口。

LoadBalancer 服务功能强大，可通过云提供商特定的注释进行高度配置，但它们有一些限制。最大的问题是，您公开的每个服务都会创建一个单独的负载平衡器。在一个有数十或数百个微服务的世界里，这就增加了大量的云负载平衡器。负载平衡器服务也没有为基于路径的路由提供机会。同样，在微服务(甚至是常规服务)的世界里，这可能是行不通的。

入口

鉴于 NodePort 和 LoadBalancer 服务的局限性，我们需要更强大的服务。Kubernetes 开发人员预见到了这种需求，并创建了 Ingress 对象。入侵要求您在集群中运行一个控制器来处理它们，并且一开始就运行它们有点困难，但是回报是巨大的。

如前所述，为了使用入口，我们需要一个控制器。外面有好几个控制者，比如孔和哈普洛克西。在 Fairwinds ，我们发现 ingress-nginx，一种基于 nginx 的控制器，是最容易使用的，也是最完整的解决方案之一。有许多方法可以安装它，但我们更喜欢使用头盔:

这将创建 Nginx 控制器，并使用现在熟悉的 LoadBalancer 服务公开它:

该服务指向一组运行 Nginx 的控制器单元。现在，我们可以在 Kubernetes 中创建名为 Ingresses 的对象，该对象将配置 Nginx 将流量路由到集群内部的服务。

您部署的每个需要在集群外部公开的服务现在都将包含一个入口定义。入口定义也非常简单，类似于下面的代码片段:

请注意，它路由到我们创建的服务。这告诉 Nginx，当流量以匹配的主机名进入集群时，将流量路由到该服务。这就是我们如何获得基于路径和名称的路由。如果我们深入研究入口控制器盒，查看 Nginx 的配置，我们会看到一个非常熟悉的 Nginx 服务器模块，它对应于我们的新入口。

像 LoadBalancer 服务一样，Ingresses 可以使用注释合并非常详细的配置。这些注释是 Nginx 特有的，可以在控制器中配置不同的选项。

所有这些意味着我们现在有办法在一个 Nginx 代理(或一组代理)后面运行数十或数百个服务，并且这些代理是使用易于部署的 Kubernetes 对象配置的。我们甚至可以用它来创建 TLS 证书和 DNS，我们将在后面看到。现在，我们有一个单一的云负载平衡器来处理到控制器的 TCP 流量，并且我们从集群内部处理路由。这里有一个小图表来把所有这些联系在一起:

Ingress Traffic Diagram

DNS 条目创建

因为我们使用基于路径和名称的路由，所以我们需要创建 DNS 条目。本着使用控制器和其他 Kubernetes 本地构造的精神， Fairwinds 使用了一个名为外部 dns 的项目。该控制器将监视注释和某些类型的对象，并基于它们创建 DNS 条目。它还配有头盔:

请注意，还需要指定您的 DNS 提供商的凭证，这取决于您正在使用的 DNS 提供商。详见 此处。

现在，当我们使用 dns 名称创建入口时，外部 DNS 控制器将使用入口控制器的 IP 地址更新我们的 DNS 提供商。

使用 TLS 加密服务

既然我们的服务有了 HTTP 流量和容易访问的名称，我们想保护它们。HTTPS 已经成为事实上的标准，因为搜索引擎已经为它进行了优化，如果它不在那里，浏览器会给出难看的警告。传统上，这一直是运营团队的痛点。当时，我们必须生成证书并进行验证(有时通过手动门户)，然后仍然必须部署证书。根据应用程序的不同，我们必须更新应用程序代码或重启 web 服务器。在现代，我们有几种不同的选择。

云提供商证书存储

亚马逊提供亚马逊证书管理器(ACM)。结合负载平衡器服务和特殊注释，我们可以利用 ACM 证书在 TLS 到达集群之前终止它。如果您使用 Route53 DNS 生成证书，ACM 会自动续订证书。以类似的方式，入口控制器可以将通配符 ACM 证书与其负载平衡器合并。这意味着我们创建的任何在通配符中使用域的入口都可以免费获得 TLS。只要您习惯使用通配符，这对于少数服务来说是一个好的选择。一些安全策略不允许这样做，有时您需要不止一个子域。对于另一个自动验证选项，我们看得更远。

让我们加密

随着云计算和隐私问题的兴起， Let's Encrypt 着手创建一个任何人都可以免费使用的全自动认证机构。它们有一个特定的协议，允许您以编程方式自动验证和生成证书。该协议的许多实现已经完成，但我们在 Fairwinds 专注于 cert-manager 。这个工具利用 Kubernetes 内部的一个定制控制器来请求和维护来自 Let's Encrypt 的证书。这与监视新的入口对象并自动为它们生成证书的 shim 相结合。

这意味着您可以部署 cert-manager，再也不用担心 TLS 证书了。当然，它比这要复杂一点，但是一旦部署，它可以无缝地管理证书。

为了部署 cert-manager，我们再次使用 Helm:

一旦控制器开始运行，还有几个部分需要设置。有两种方法可以对证书进行域验证。我们倾向于在顺风时尽可能使用 DNS01。为此，您的群集节点(或证书管理器)必须有权修改 DNS 提供商的记录。这超出了本文的范围，但是可以通过云提供商中的节点角色来完成。另一个选项是创建一个服务帐户，您将在下面的步骤中使用它。

接下来，您将创建一个 Issuer 或 ClusterIssuer，它负责配置您的 Let's Encrypt 帐户并设置您将使用的验证方法。在本指南中，我将使用 ClusterIssuer 并将其连接到 Let's Encrypt。这是通过创建另一个 Kubernetes 资源来实现的:

这里发生了一些事情:

它使用谷歌云域名系统进行验证
它使用服务帐户获取更新 DNS 的权限。服务帐户凭证存储在一个名为dns-gcloud-config的秘密中
该电子邮件地址将成为您的加密帐户名称。续订电子邮件警告将放在这里
这指向加密生产端点，因此它将生成有效的证书

一旦您应用此资源，证书管理器控制器将尝试设置您的加密帐户。如果你做了一个kubectl describe clusterissuer letsencrypt-prod，你会在输出的底部看到这样几行，表明你的账户已经注册:

现在您有了一个颁发者，我们有了入口控制器，我们可以重新部署我们的入口对象来利用 cert-manager:

请注意，除了入口底部的 TLS 块之外，注释还指定了 ssl 重定向和要使用的 ClusterIssuer。还指定了一个秘密名称，cert-manager 将使用它作为证书的名称。我们可以验证所有这些都是这样创建的:

现在，我们有了一个功能性入口，自动 TLS 加密将流量路由到我们的集群。为了在 Kubernetes 提供完全可操作的服务，这就留下了一个难题。

使用指标扩展应用程序

我将把可扩展性和指标放在一起，因为如果没有某种可扩展的指标，我们就无法扩展应用程序，而且它们可以快速轻松地一起配置。Kubernetes 有一个内置机制，称为水平 pod 自动缩放器，可用于根据指标维护部署中的副本数量。为了做到这一点，我们必须向 Kubernetes API 公开指标。除非您在 GKE 上，这将自动为您提供，否则获取指标的最简单方法是将指标服务器部署到集群中。使用 Helm 非常简单:

一旦控制器启动并且填充了指标，我们应该能够看到 pod 和节点的资源利用率，如下所示:

有了度量标准，我们可以为我们的部署创建一个水平机架自动缩放器 (HPA)。HPA 被定义为另一个对象，如下所示:

几分钟后，您可以查看 HPA 并了解当前状态:

此设置将监视单元的 CPU 使用情况，并根据部署中设置的 CPU 限制(请参见原始部署)尝试将它们的利用率保持在 80%或以下。如果利用率过高，HPA 将扩大，如果利用率下降一段时间，它将缩小。这种行为可以通过自定义指标提供者更改为使用任何指标。对此进行正确的调整将允许您的部署处理许多不同的流量和负载问题。

扩展集群

水平扩展 pod 很好，并允许动态流量处理，但它不能控制群集中有多少节点。随着我们添加越来越多的单元，我们将需要更多的节点来处理所有单元。当你看到一堆豆荚处于Pending状态时，这一点会变得很明显；当您执行kubectl describe pod <pod-name>时，您会看到一条关于无法安排 pod 的消息。我们通过利用集群自动伸缩来处理这个问题。如果无法安排新的 pods，集群自动缩放项目将扩大规模，它将密切关注节点利用率，如果发现机会，将缩小规模。

根据您使用的云提供商的不同，安装看起来会有很大的不同，但是我将简要介绍 AWS 和 GKE 安装。

GKE

这个真的很简单。如果您在节点池中打开自动缩放，默认情况下，GKE 会运行群集自动缩放。您可以在控制台中完成此操作，或者使用您用来设置集群的任何代码:

GKE Node Pool Autoscaling Menu

AWS

这再次取决于你如何创建你的集群，但是在顺风我们使用 kops 。无论您如何构建集群(不包括 EKS)，您仍然需要安装集群自动缩放器。我们使用 Helm 通过自动发现节点来安装自动缩放器。

这需要修改 kops 集群和实例组定义。这超出了本文的范围，但是这里有很好的记录。

权限— RBAC

在 Kubernetes 中管理 RBAC(基于角色的访问控制)是困难的。您构建的集群很可能默认启用了它，而您可能根本没有配置它。本教程已经在我们部署的舵图中使用了 RBAC。

开箱即用，您可以定义许多资源:

服务帐户
clusterrolebindings
角色绑定
角色
集群角色

保持这些直线是令人困惑的，修改权限通常需要多组定义。 Fairwinds 利用了一个我们编写的控制器来简化它，这个控制器叫做 rbac-manager 。我们可以用(你猜对了)Helm 安装它:

我们现在可以创建一个名为 rbacdefinition 的对象来管理我们的权限和服务帐户。让我们继续创建一个供我们的 CI/CD 系统使用:

应用它将创建一个名为ci的服务帐户，并将其绑定到集群角色cluster-admin。将来，我们可以使用该服务帐户为 ci 系统生成一个 kubeconfig 文件。接下来，我们可以添加这一功能，以便更好地控制群集中用户和服务帐户的所有权限。

那已经很多了

您刚刚在集群中安装了大量工具，并添加了许多功能。我们刚刚加了什么？

入口控制器—用于路由和 TLS 终端进入集群
外部 DNS —管理您的入口的 DNS 记录
证书管理器—为入口生成和维护 TLS 证书
度量服务器—支持使用水平 Pod 自动缩放器
集群自动缩放—用于基于 pod 管理集群大小
RBAC 管理器—用于管理您的集群权限

所有这些都需要一个或多个舵图表来安装，并且可能需要不同的值，这取决于您想要进行的定制。运行这些命令并维护这些值文件可能会令人沮丧，尤其是在管理多个集群的情况下。Fairwinds 利用一个名为 Autohelm 的自制工具来管理所有这些图表。它允许您维护一个文件来定义您想要使用的所有图表。在 examples.md 中有所有不同图表的例子。

一些责任重大的事情

现在，您拥有了“完全运行”的 Kubernetes 集群的强大功能。向前迈进，部署自动扩展、高可用性和 TLS 加密的服务。请给我打电话 @sudermanjr 对未来的话题提出意见或要求。

利用 Fairwinds Insights 了解 Kubernetes

原文：https://www.fairwinds.com/blog/making-sense-of-kubernetes-with-fairwinds-insights

当我开始与 Kubernetes 合作时，我认为这是一个相当简单的转变。我在 AWS 工作了很多年，在那之前我也在 Linux 上工作了很多年。我知道如何构建容器、配置虚拟机、联网、管理内存和 CPU，以及在云中运行工作负载所需的一切。在谷歌，我甚至与 Kubernetes 的前任博格共事过。学习另一个计算框架有多难？

事实证明，非常困难。尽管我已经在一家专门从事 Kubernetes 支持的公司工作了一年多，但我仍然每天都在学习。Kubernetes 不仅仅是一种新的语法——它是一种全新的思考分布式计算的方式。

到目前为止，最困难的是生态系统的深度。核心项目有超过 200 万行代码，并附带了大量文档。再加上几十个 SIG 和数百个第三方插件，既有开源的也有专有的，很容易让人不知所措。

这种复杂性使得 Kubernetes 成为一个非常强大和灵活的计算管理平台，这也是为什么超过一半的财富 500 强企业采用了它。但是随着建立一个集群的方法的爆炸式增长，错误几乎是不可避免的。保持 Kubernetes 集群的安全性、高效性和可靠性需要大量的知识和经验。

社区已经建立了一些令人惊讶的开源工具来审计 Kubernetes 基础设施，这有可能极大地缓解这些问题。但是审计生态系统是复杂的、支离破碎的，并且是不断变化的。因此，我们在一套开源审计工具的基础上构建了一个抽象层, Fairwinds Insights 。Fairwinds Insights 帮助组织轻松了解他们做得对的地方，以及他们需要关注的地方。

一个庞大的开源生态系统

我很幸运能在老兵面前了解到 Kubernetes。我们有一个出色的 sre 团队，他们已经为几十个组织管理了数百个集群。他们已经看到 Kubernetes 在各种可能的情况下出错，我非常幸运能够从他们的经验中学习，而不是从我自己的错误中学习(尽管也有很多这样的错误！)

甚至在我到达之前，他们已经开始组装一个名为 Polaris 的开源仪表板，用来扫描 Kubernetes 的工作负载，查找常见的配置错误。它检查从安全性(比如以 root 用户身份运行容器)、效率(比如不请求特定数量的内存/CPU)到可靠性(比如无法设置活性和就绪性探测)的各种问题。如果没有像 Polaris 这样的项目来告诉我我错过了什么，我在将工作负载部署到 Kubernetes 时可能需要更多的指导。

该团队还指出，开源社区已经建立了几十个类似的工具。集装箱扫描有繁琐； kube-bench 用于测试您与 CIS 基准的对准情况；或者我们自己的 Goldilocks 来调整 CPU 和内存设置。我们最终仅编目了 30 多种开源安全工具！

外界审计工具的数量和种类之多很快就让人应接不暇。这些工具有些运行在集群中，有些运行在本地机器上。其中一些查看正在运行的工作负载，另一些查看上游的 YAML 文件。它们都不能跨多个集群核对数据，随着时间的推移跟踪结果，或者在新问题出现时发出警报。它们都有不同的输出格式，用不同的方式表示严重性和工作负载身份。

我们无法继续手动运行所有这些审核，从这些审核中寻找新的发现，并手动创建票证。我们需要一种方法来操作所有这些数据。

构建解决方案

为了让我们的生活——以及我们的客户的生活——更轻松，我们创建了一个基于插件的系统来整理和跟踪审计数据。这包括四个主要部分:

后端存储
翻译层
集群内代理
图形用户界面仪表板

后端

首先，我们构建了一些公共基础设施——即 JSON 存储和 PostgreSQL 数据库——任何报告工具都可以链接到其中。每个单独报告的输出在 S3 保存为 JSON，更多的结构化数据被提取并存储在数据库中。

我们数据库模式的核心是一个被称为行动项目的概念——由任何审计生成的发现——它捕获安全性、效率或可靠性的潜在问题。

翻译层

在此基础上，我们构建了一个瘦翻译层:基本上，一些 Go 代码将每个报告的独特输出转换成行动项目。在这里，我们提取资源名称、严重性级别、人类可读的描述和补救建议。其中一些包含在基础报告中，而一些我们需要用自己的知识和研究来补充。

翻译层是代码库中最难维护的部分，因为每当报告添加新功能或更改其输出结构时，都需要对其进行更新。但是它非常有价值。他们可以利用洞察力以一种格式自动查看所有审计数据，而不是每个组织都试图在许多不同的审计工具上构建自己的抽象。

代理人

接下来，我们构建了一个代理来运行每一个开源审计——目前总共有 9 个——并将结果发送回我们的服务器，在那里它们被转换成操作项。这些报告都按照可配置的时间表运行，通常每小时一次，因此我们始终可以了解集群内部的最新情况。当某个问题得到解决时，我们也会选择它，并且可以自动关闭相应的行动项。

这比典型的方法要简单和健壮得多，典型的方法是在特定的基础上手动运行每个工具，而不参考以前的运行。

仪表板

最后，我们在insights.fairwinds.com建立了一个用户界面，用户可以登录并查看他们的结果。我们有一个用于查看所有行动项目的单一表格，以及一些用于深入研究单个报告的定制界面。这使得我们的用户可以享受两个世界的精华——他们可以看到统一格式的所有内容，或者进入一个专为他们当前工作定制的视图。

作用于数据

现在我们把所有的数据都放在一个地方，我们可以做很多令人惊奇的事情！

我们做的第一件事是建立一些基本的跟踪。我们希望能够将行动项分配给特定的人，并查看行动项何时被发现或修复。还有一些误报(例如，kube 系统工作负载确实需要 root 访问权限)，我们开始将其标记为“不会修复”或“按预期工作”。

更好的是，我们开始将标准化的数据推到我们花费时间的不同地方。我们已经将它链接到 Datadog，因此团队可以跟踪一段时间的趋势，并在资源使用和正常运行时间等核心指标上覆盖行动项目事件。我们已经开始向 Slack 发送警报——包括实时的和每日摘要的，以确保团队对任何意想不到的变化保持警惕。沿着这条线，我们正在研究 GitHub 和吉拉的集成，以确保适当的团队能够修复他们引入的任何问题。

不过，我最感兴趣的是 CI/CD 集成。目前，我们的代理只是查看集群中已经存在的内容——但是，如果我们能够在问题合并到主代理之前就检测到它们，会怎么样呢？只有部分报告能够在 CI 环境中运行，但是能够阻止引入新漏洞的 PR，或者将操作项追溯到特定的基础架构代码文件，将会节省我们大量的时间、痛苦，最重要的是，降低风险。

你验证 Kubernetes 配置的策略是什么？

如果您已经在审计您的 Kubernetes 基础设施的安全性、效率和可靠性问题，我们很想听听您正在使用什么工具以及您最关心的问题在哪里。我们正在积极寻求对 Fairwinds Insights 的反馈，它是免费的！拿到这里。

一致地管理开放策略代理(OPA)

原文：https://www.fairwinds.com/blog/manage-open-policy-agent-opa-consistently

上周，CNCF 宣布开放策略代理(OPA)的毕业，这是一个开源的通用策略引擎，能够在整个堆栈中实施统一的上下文感知策略。这是一个超级令人兴奋的项目，它帮助任何负责团队、合规性和安全性的人在 Kubernetes 中应用它。

而且正在被利用！在一项针对 150 多家组织的 OPA 用户调查中，91%的组织表示他们在从 QA 到生产的 OPA 采用阶段使用 OPA。超过一半的人表示他们至少在两种情况下使用 OPA。OPA 最常见的用例是配置授权(比如 Kubernetes 准入控制)和 API 授权。

在 Kubernetes 中实施政策

OPA 的势头证明，我们需要对 Kubernetes 集群中发生的事情进行更多的控制和了解。因此，虽然 OPA 在 Kubernetes 策略执行方面提供了大量的功能，但它也需要技术知识和时间来跨多个团队和多集群应用策略。

最新的 CNCF 调查显示，大多数人在生产中运行 2-5 个集群。然而，有更多的团队在运行。

Graph of the average production clusters showing that on average 2-5 clusters are deployed

如果您负责管理 10 个或 20 个集群，您如何确保您的 OPA 策略在所有集群中保持一致？你需要多少时间和资源以及你愿意接受的人为错误来管理这个令人头痛的问题？

持续管理 OPA

当 OPA 得到一致应用时，通过允许您围绕用户访问、子网出口流量许可、工作负载部署、可下载的注册表二进制文件或基于一天中的时间的系统访问设置定制策略，OPA 将使您的应用和 Kubernetes 基础设施受益。您将能够创建和实施对您的业务非常重要的策略。

仍然需要的是一种一致地实施 OPA 的方法，尤其是如果您正在管理一个团队或者需要证明合规性/安全性的话。

这就是 Fairwinds Insights 要解决的问题。我们在 Fairwinds Insights 的每个部分都增加了对 OPA 策略的支持，包括 CI/CD 管道、准入控制器和集群内代理。

fair winds Insights是一款针对安全性、效率和可靠性检查来检查集群配置的软件。它将许多开源项目的智能，包括 OPA、Polaris、Goldilocks、Trivy 等等，结合到一个集中的仪表板中。如果你负责确保 Kubernetes 的配置是正确和一致的，你将能够在任何时间点看到什么需要修复。

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

当与 OPA 一起使用时，Fairwinds Insights 可帮助您确保在所有集群中应用相同的策略，并且如果您希望某些策略仅应用于某些工作负载(例如，仅在 prod 集群上运行)，则可提供一定的灵活性。它还允许您在 CI/CD、准入控制和集群内扫描中运行相同的策略，因此您可以在整个开发和部署过程中一致地应用策略。

Insights 可以采用相同的 OPA 策略，并将它们联合到所有三个上下文，以及您想要的任意多个集群。您将受益于跨集群一致地自动化、管理和执行 Kubernetes 策略的能力。

您可以阅读更多内容并查看一些截图，了解如何使用 Fairwinds Insights 管理 OPA 政策。

环保 Ep。3 |与微软的 Emily Freeman 一起管理 Kubernetes

原文：https://www.fairwinds.com/blog/managed-kubernetes-with-microsofts-emily-freeman

利用 Fairwinds Insights 管理 OPA 政策

原文：https://www.fairwinds.com/blog/managing-opa-policies-with-fairwinds-insights

在 Fairwinds，我们已经在几十个组织中管理了数百个 Kubernetes 集群。在我们保持客户环境安全、高效和可靠运行的努力中，我们发现利用各种开源审计工具有很多好处，如 Trivy(用于容器扫描)和 kube-hunter(用于网络嗅探)，以及我们自己的贡献，如 Polaris(用于配置验证)和 Goldilocks(用于审计资源请求和限制)。我们建立了 Fairwinds Insights 作为一种管理、跟踪和分类这些工具的所有不同发现的方式，这是一个很大的帮助。

但是这些工具通常是通用的——它们检查运行 Kubernetes 的每个人应该关心的事情。例如，Polaris 对“最佳实践”进行了一系列检查，比如确保你已经为每个工作负载设置了内存限制。

许多组织有更具体的要求。例如，他们可能:

非常注意安全，希望每个容器都放弃所有 Linux 功能
对 Docker 注册表中断保持敏感，并希望确保从内部注册表中提取每个映像
有一个他们想要实施的内部命名方案
希望每个工作负载都有特定的标签，如成本中心代码
需要每个部署都连接一个垂直或水平的 pod-autoscaler

虽然组织可以使用 Polaris 的自定义检查语法来执行这些策略，但 Kubernetes 社区已经确定了一个用于创建配置策略的强大的开放标准:开放策略代理，或 OPA。我们很高兴地宣布，我们已经为 Fairwinds Insights 的每个部分添加了对 OPA 策略的支持，包括 CI/CD 管道、准入控制器和集群内代理。

通过将 Fairwinds Insights 和 OPA 结合使用，组织可以主动将其 Kubernetes 集群与最佳实践和内部策略保持一致。此外，在开发和部署流程的每个步骤中运行 OPA 的能力有助于在问题进入集群之前尽早发现问题，从而更容易地在开发和运营之间进行交接。

什么是 OPA？

OPA 是一个验证结构化数据的框架。它促使用户编写策略即代码，扩展了社区对基础设施即代码的成功推动。虽然 OPA 可以验证任何类型的结构化数据，包括 Terraform、HTTP 请求和 often 文件，但它最常被认为是与 Kubernetes 清单结合使用。

负责开放策略代理的人维护着一整套用于配置验证的工具，但核心技术是一种被称为减压阀的特定领域语言。

screenshot of domain-specific language known as Rego

一开始，减压阀可能有点令人生畏，因为它的语法不像典型的编程语言，但就像任何优秀的特定领域语言(DSL)一样，一旦你掌握了它，它就会变得非常强大。这篇文章对如何在减压阀开始思考提供了一个很好的概述。

OPA 和 Fairwinds Insights

我们通过三种主要方式将 OPA 集成到 Fairwinds Insights 中:

作为 CI/CD 挂钩，作为代码评审过程的一部分，审计基础设施即代码
作为准入控制器(又名验证 Webhook)，它将阻止有问题的资源进入集群
作为集群内代理，重复扫描有问题的资源

更好的是，Insights 可以采用相同的 OPA 策略，并将它们联合到所有三个上下文，以及您想要的任意多个集群！

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

持续集成

OPA 并不总是必须在集群中运行——它也可以在签入您的基础设施即代码库中的 YAML 上运行。这是在过程早期检测问题的好方法，因为工程师仍然在微调他们的代码。

screenshot of Fairwinds Insights CI detecting problems early

如果您只是通过集群内代理和准入控制器运行 OPA，而没有利用持续集成特性，您可能会让一些开发人员感到沮丧。他们将他们的变更合并到主分支中，却发现部署过程已经中断，因为接纳控制器拒绝了他们的变更。或者，几周后，一名操作工程师来敲门，因为集群内代理发现了一些由他们的更改引起的新操作项。但是如果团队将相同的 OPA 策略合并到他们的 CI 过程中，他们将被阻止合并他们的变更，直到问题被修复。

入场控制器

在 Kubernetes 中，准入控制器(或验证 Webhook)监听 Kubernetes API 以发现进入集群的新资源。每当用户、bot 或集群中的操作者想要创建或更新资源时，准入控制器就有机会首先检查它。如果资源违反了准入控制器的策略，它可以拒绝 API 请求，并将任何详细信息报告给调用者。

Example of cat bad-deploy.yaml screenshot

这是一个实施强硬政策的好地方。例如，如果您希望确保集群中的没有工作负载从 quay.io 和 Docker Hub 中提取映像，准入控制是实施该策略的绝佳场所。当然，如果需要，管理员可以对特定的资源和名称空间进行豁免。

集群内代理

Fairwinds Insights 可以在正在运行的 Kubernetes 集群内将 OPA 作为 CronJob 运行。在这种情况下，代理将在集群中搜索与您的策略匹配的任何资源，并将在 Fairwinds Insights 仪表板中创建一个操作项。

Screenshot of Fairwinds Insights dashboard with Action Item example

对于每个 OPA 策略，您可以在 Insights UI 中自定义以下字段:

严重
种类
标题
描述
补救

这是开始使用 OPA 的一个很好的非侵入性方法。您可以让策略在现有资源上被动运行，看看它们可能会产生什么影响，而不是强制实施您尚未调优的策略。这也是运行“最好有”策略的好方法——这些策略不一定会阻止部署，但是您仍然希望关注它们。

为什么不坚持开源呢？

开放策略代理团队为在各种环境下运行减压阀策略提供了一些很棒的开源解决方案，比如 Gatekeeper(他们的准入控制器)和 Conftest(用于检查 YAML 文件的 CLI)。但是像 Fairwinds Insights 这样的 SaaS 平台可以为大规模管理 OPA 提供更加无缝、统一的体验。

一个主要优势是能够将您的 OPA 策略联合到您的机群中的每个集群。有了开源工具，你需要将每一个新策略应用到每一个集群上。如果您有几个集群，这可能不是太大的压力，但对于有几十到几百个集群的组织来说，这可能会成为一场噩梦。您如何确定他们都在运行每个策略的最新版本？借助 Fairwinds Insights，您只需通过 API 上传您的策略，它就会自动分发到您车队中的每个集群。

另一个优势是能够在不同的上下文中运行相同的策略。OPA 套件中不同的开源工具期望不同的输入格式，因此很难在 CI 中重用您在准入控制中使用的相同策略。但是 Fairwinds Insights 将其 OPA 集成设计为在所有环境中保持一致，因此如果您的 CI 检查通过，您可以确保准入控制员不会抱怨。

下一步是什么？

我们不断对 Insights 平台进行迭代，以提供新功能，对于如何在未来几个月改善我们的 OPA 集成，我们已经有了一些很好的想法，特别是在仪表板和警报方面。

我对 Fairwinds Insights 整合 OPA 的方向感到非常兴奋。它重申了我们对开放标准和 Kubernetes 社区的承诺，并极大地扩展了我们产品的功能。当与 Fairwinds Insights 结合使用时，OPA 将使集群管理员确信他们的内部策略在整个开发和部署过程中都得到了执行。

资源

5 月发行说明汇总-从 4.1.0 到 4.3.0 的所有内容

原文：https://www.fairwinds.com/blog/may-release-notes-rollup-everything-from-4.1.0-to-4.3.0

我们度过了忙碌的五月，向 Fairwinds Insights 、Kubernetes 安全、政策和治理软件添加了新功能。这个月的每个版本都有一些很棒的新特性和额外的功能，我们在下面大致介绍了一下。

如果您需要持续的 Kubernetes 安全监控、策略执行以及管理合规性和优化成本的能力，请尝试 Insights 。

fair winds Insights4 . 1 . 0-4 . 3 . 0 包含一些出色的新功能，包括:

4.3.0 使用自动化规则的自定义通知 - Fairwinds Insights 现在允许您添加自定义 Slack webhook URLs，以便向您选择的 Slack 环境发送自定义消息。了解更多。
4.2.0 漏洞 UI - 这一新的 UI 可帮助您挖掘集群中运行的易受攻击的映像。要使用此功能，请单击导航栏中的漏洞选项卡。现在，在创建自动化规则时，您还可以基于资源标签和注释来检查和编写规则。此版本还向 CI 脚本添加了 SHA 哈希，在我们的 CI/CD 指令中实现了完整性检查。请更新您的 Insights CI/CD 功能。
4.1.0 自托管安装代码(测试版) - Insights 现已可供您在自己的基础设施上托管。如果你想尝试一下，请联系我们。了解更多关于自主见解的信息。4 . 1 . 0 版本现在还允许您使用“行动项目”表格顶部的“创建票证”按钮在吉拉创建票证。了解更多关于此功能的信息。您还可以使用单个 helm install 命令在大型集群中轻松安装 Insights 代理。

如果你想了解更多关于自托管的 Fairwinds Insights 的信息，这是一种审计你的 Kubernetes 基础设施的更简单的方法，我们在这篇文章中有更多的信息。

对使用 Fairwinds Insights 感兴趣？免费提供！在这里报名。

要了解如何使用这些功能，并了解最新的 Fairwinds Insights，请查看此处的发行说明。

如果您已经是 Insights 用户，您可能还在使用我们的一些开源项目。我们很高兴地宣布我们有了新的社区资源！加入 Fairwinds 开源用户组，了解我们在 Kubernetes 的开源项目。在这里注册。

在 AWS 上从 Heroku 迁徙到 Kubernetes

原文：https://www.fairwinds.com/blog/migrating-from-heroku-to-kubernetes-on-aws

利用平台即服务(PaaS)是快速构建、创新和部署新产品或服务的好方法。通过利用 PaaS 供应商的服务器、负载平衡、应用程序扩展和第三方集成，您的工程团队可以专注于构建面向客户的功能，为您的业务增加价值。

*然而，有一点是，许多组织已经无法满足其一刀切的平台即服务的需求。一些常见的原因包括:

表演
成本效率
控制
可靠性
平台限制

我们最近在 AWS 上为一个这样的客户端完成了从Heroku到Kubernetes的迁移。

该客户经历了惊人的增长，并在真正的 PaaS 中遇到了一些限制和性能问题。此外，他们需要运行与其正常应用程序工作负载完全隔离的敏感工作负载，而 PaaS 提供商无法满足这一需求。

他们之前的架构将 Heroku 用于面向客户端的网站和 API，并在领先的托管服务提供商上使用单独的实例来处理他们的安全交易。必须管理两个基础架构堆栈以及独立的日志记录、监控和部署管道，这减缓了他们的开发过程。

最后，他们正在将几个整体应用程序分解成一组微服务。这些微服务将增加代码重用并降低应用程序的复杂性。我们的客户知道微服务将复杂性从应用转移到基础设施，并希望实施能够提供关键功能，如服务发现、流量路由和秘密管理。

目标

除了依赖我们完全托管的开发运维即服务之外，我们客户的技术要求是拥有一个现代化的云架构，包括:

使用 AWS 等弹性云平台整合基础设施
支持微服务架构的编排系统
两个独立的集群:生产/暂存和安全
集中式应用程序日志记录、指标和警报
应用 CI/CD 管道
与生产紧密匹配的本地开发环境

在对现有基础设施和遗留应用程序以及他们的 CTO 对下一代应用程序的愿景进行彻底评估后，我们的团队提出了一个基于部署到 Amazon Web Services 的开源Kubernetes容器编排引擎的解决方案。

库伯内特的现代建筑

如果你以前没有听说过 Kubernetes，停止阅读，去访问项目网站。

然后阅读为什么 Kubernetes 可以加冕集装箱管理之王。而 Google Kubernetes 则是开源软件的热门。

回来了？这些流行语不是谎言。

总结一下:

“Kubernetes 是一个用于自动化部署、扩展和管理容器化应用的开源系统。”

从应用程序开发人员的角度来看，Kubernetes 提供了一种健壮的机制来轻松部署应用程序(就像您使用 PaaS 一样)，而没有实际 PaaS 的约束和供应商限制。这正是我们的客户所寻求的，并且是一个完美的功能匹配。

开箱即用，Kubernetes 为现代云架构提供了许多基本特性:

AWS Azure的部署方法
容器调度和编排
服务发现和负载平衡
机密和配置管理
自动滚动部署(和回滚！)
水平应用程序自动缩放
应用程序日志收集

但是，Kubernetes 有几项电池以外的操作功能:

一致的 AWS 部署
构建环境(CI/CD)
码头注册
监控和警报
外部日志记录

生产就绪部署

我们在使用工具和 SaaS 平台处理 Kubernetes 没有的功能方面已经有了丰富的经验。我们根据该客户已经在其他地方使用的服务，以及哪些服务在特性和功能方面提供了最佳价值，为他们提出了我们的建议。

完成的部署包括:

亚马逊网络服务
应用程序日志记录使用logspout&paper trail
使用DatadogT5PagerDuty进行应用和容器监控和报警
- Datadog 有一个很棒的工具，可以为您的 Kubernetes 集群生成 DaemonSet
- 对于这个特殊的客户，我们正在处理二级传呼机的职责。
使用 CircleCI 进行持续集成和持续部署
- PRs 的构建/测试，主部署到“准备阶段”， GitHub 发货到生产
管理集群生命周期的工具集
- 集群创建、删除、状态备份和导入
Quay.io 的优秀 Docker 注册表
- 集成漏洞扫描与克莱尔
- 可定制的 RBAC 访问，包括 Kubernetes & CircleCI 的“机器人”帐户。
本地开发工作流使用 minikube

图片中的星团

1feJ-shgyfsY3GQQvG2ltig

我们的客户已经试运行他们的新基础设施几个月了，并且已经开始生产过渡。通过与他们的工程团队合作，我们已经实现了向 Kubernetes 基础设施部署新微服务的流程自动化。过去，开发人员需要几个小时甚至一天才能侵入他们的旧基础设施，现在只需要不到 20 分钟——而且该平台提供了完成这项工作的所有功能右。

未来的工作

随着我们扩大他们的生产工作负载，我们发现了一些新的需求，并将其纳入到 Fairwinds DevOps 即服务产品中:

ChatOps 管理 Kubernetes 集群和应用程序部署生命周期的状态
改进的 Kubernetes 部署系统，包括 HA etcd 和 master
增强型秘密管理系统
预先配置的 Kibana，用于内置于 Kubernetes 的 ElasticSearch-Logstash 系统*

经由 GKE 从 Heroku 迁徙到 Kubernetes

原文：https://www.fairwinds.com/blog/migrating-from-heroku-to-kubernetes-via-gke

利用平台即服务(PaaS)是快速构建、创新和部署新产品或服务的好方法。通过利用 PaaS 供应商的服务器、负载平衡、应用程序扩展和第三方集成，您的工程团队可以专注于构建面向客户的功能，从而为您的业务增加价值。

然而，有一点是，许多组织已经无法满足其一刀切的平台即服务的需求。一些常见的原因包括:

性价比
控件和自定义
平台限制和可用技术

在 Fairwinds，我们经常被问到“我们如何从 Heroku 转移，但仍然支持我们最喜爱的平台功能？”

这是一个很好的问题，也是 Heroku 的一些优势的核心:

简单、标准化的滚动部署方法
自动化 SSL 证书管理和基础设施扩展
机密/配置管理
独立的测试环境
轻松访问应用程序日志输出

从团队速度的角度来看，这些特性是非常可取的，并且是我们在客户询问交换机时看到的最常见的问题。

迁移的目标

让我们深入了解 Kubernetes 如何帮助实现这些特性，以及解决在一刀切的 PaaS 中工作的一些限制。对于这个例子，我们将利用谷歌云平台(GCP)，因为其中一些功能需要云平台的支持才能实现。在 Fairwinds，我们专门从事云迁移和集成，以帮助您在迁移基础架构时获得最大回报。

标准化部署和秘密管理

当利用 Fairwinds 的 ClusterOps 服务时，我们会帮助您建立一套基于标准的 Google Kubernetes 引擎(GKE)集群，在此基础上安排您的集装箱化工作负载。我们的一些板载功能包括帮助将您的应用程序放入容器中，以便它可以很好地在 Kubernetes 生态系统中运行。

标准部署由 Helm 和 Reckoner 等工具支持，以支持部署您的工作负载以及 Kubernetes 中的核心基础设施工具。

Kubernetes 本身支持滚动部署，并为您提供了合理的缺省值来定制您想要的滚动策略。除此之外，Kubernetes 还支持 12 因素应用程序，能够将秘密和配置挂载到环境变量(如果需要，还可以挂载到文件)，因此您可以将应用程序配置作为部署资源的一部分进行管理。这一核心工具与 GitOps 相结合，可以帮助您获得更符合您的业务交付需求的 CI/CD 工作流。

Kubernetes 强大的 RBAC 还可以用来在集群中保护您的秘密和凭证的安全。虽然 RBAC 有时很复杂，但是你可以利用另一个叫做 RBAC 管理器的工具来帮助减轻这些复杂性。我们的 ClusterOps on-boarding 还设置了一个核心，通过它可以扩展您的访问策略，允许您的开发人员访问 Kubernetes 以及 CI/CD 等自动化系统。

基础设施管理和 SSL 证书管理

您可能知道，当您的应用程序开始被大量使用时，您需要开始增加您的辅助组件，如负载平衡器和数据库。Kubernetes via GKE 进行了深度集成，能够为单个服务自动供应云负载平衡器，并在“入口控制器”下进行统一管理，以便您可以在适应增长时根据需要分割应用的流量。

Nginx-ingress-controller 是我们最常用的工具之一，它允许您将流量路由到集群中的不同容器。如果您正在拆分整体或测试新服务的想法，这可能会特别有帮助。

与 web 服务器负载平衡携手而来的是安全性和加密。如果您从事过运营工作，您可能会经历过客户端面临证书过期的恐慌，以及必须使用正确的凭据更新未知数量的服务器，以便您的客户端不会在其浏览器中显示“站点不安全”消息。Kubernetes 生态系统拥有强大的工具，可以自动为您提供证书，并使用 Let's Encrypt 自动旋转它们，因此您不必担心这一点。这减轻了运营负担，同时保证了您的流量安全。

无论您目前是基于微服务、事件总线还是 monolith(或者三者都是！)，Kubernetes 可以在您成长和变化时提供一些可靠的默认设置，帮助您减轻负担。

独立的测试环境

Kubernetes 具有可爱的特性和功能，使您能够分离工作负载，并为您的应用程序提供服务发现上下文。我们最常见的使用情形是在一个群集中同时容纳一个开发环境和一个试运行/生产前环境。这是由 Kubernetes 名称空间实现的。名称空间是分组权限和发现的逻辑边界，有助于减少应用程序配置中的配置差异，并在工作负载之间提供安全隔离。我们的一些 ClusterOps 客户端也有定制的解决方案，允许它们利用特性分支，这些特性分支可以将您的拉请求部署到单独名称空间中的应用程序。

访问日志和输出

过渡平台时最大的问题之一是如何访问我调试产品所需的应用程序数据。没有人希望迁移到一个新的系统，并感觉自己失去了对服务于客户端流量的应用程序的可见性。

GKE 上的 Kubernetes 通过自动集成谷歌的日志聚合工具 StackDriver 来提供帮助，所以你不会错过任何这些消息。StackDriver 还支持结构化日志，因此您可以在日志中获得更好的索引和搜索能力。

所有这些日志都可以通过 Kubernetes API 获得，因此您可以从一个端点同时实时传输来自多个容器的日志。

临时演员

一旦你在 Kubernetes 中感觉到自己的进步，通常会开始考虑自动扩展工作负载和集群的一些额外功能。幸运的是，GKE 的 Kubernetes 使您能够进行集群节点扩展和工作负载扩展！HorizontalPodAutoscaling 可以帮助您根据所有容器的总负载来扩展您的应用程序，一旦您的集群达到其 CPU 或内存限制，它还可以添加额外的计算节点来帮助您的应用程序在其界限内扩展，但不会在系统负载较低时浪费节点。

成本呢？

我们上面概述的很多东西听起来很贵，或者可能会产生一些其他的隐性成本。事实是，由于 Kubernetes 是一种迁移，而不是替代，所以您的一些流程和程序可能会发生变化。需要考虑的一些事情包括使用 Terraform 这样的工具学习基础设施作为代码实践，以及建立对新的自动化交付管道的信心以可靠地交付代码。Fairwinds ClusterOps 是一个坚实的基础和后盾，有助于减轻一些压力，利用行业资深人士和经验来帮助您保持速度和增长。

当您一对一地比较您的平台即服务(PaaS)的资源成本和来自 GCP(和其他地方)的云提供商托管资源时，还可以实现额外的成本节约。我们经常看到每月节省 2 到 5 倍！这再加上更多的灵活性和定制选项，为我们的客户讲述了最好的故事。

云提供商可以通过将 CloudSQL 用于数据库或者将 MemoryStore 用于 Redis 服务器来帮助您避免运营负担。这使您能够专注于不断增长的客户和数据集，而不是专注于数据库管理。

摘要

我们希望这篇文章为缓解您从 PaaS 迁移到 Kubernetes 的担忧提供了一个跳板。要了解更多信息，请下载我们的完整指南 : “从 Heroku 迁移到 Kubernetes”

我们随时可以在 sales@fairwinds.com 或 twitter (@fairwindsops)上发表更多意见。归根结底，我们都需要可靠、可重复的技术解决方案来推动您的业务发展，并且不会增加开销。这些是我们支持并与客户一起创造的解决方案。

利用漏洞浏览器降低 Kubernetes 的风险

原文：https://www.fairwinds.com/blog/mitigate-kubernetes-risk-with-vulnerabilities-explorer

对于 DevOps 安全负责人来说，了解 Kubernetes 集群中存在哪些漏洞至关重要，但这只是问题的一部分。一旦确定了风险，就需要一个行动计划来降低风险。根据红帽公司的 2022 年 Kubernetes 安全状况报告，43%的组织认为 DevOps 是对 Kubernetes 安全最负责的角色。随着公司转向使用更多的云原生技术，开发运维成为保护应用的最重要因素之一。

优先级是漏洞管理的一个重要部分。清点正在运行的映像并了解它们的相对风险状况正迅速成为一种基本期望。除此之外，开发运维团队还面临其他问题，例如:

这是第一方还是第三方的形象？
这个形象是哪个团队负责的？
是否有漏洞更少的新版映像？
我们需要升级映像中的任何包吗？
下次我们如何在这些问题进入生产之前发现它们？

Fairwinds 增加漏洞浏览器以降低 Kubernetes 的风险

fair winds Insights为漏洞浏览器添加了新的功能和设计，使团队能够轻松了解高层次的风险，并解决影响最大的问题。(观看下面的视频游览)。

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

Insights 可识别顶级 CVE、风险最高的工作负载和最易受攻击的容器包。团队还可以选择按图像或漏洞查看数据，从而灵活地关注最相关的上下文。漏洞浏览器通过向自动升级建议提供预计的漏洞减少计数，进一步支持节省时间。

图像概述

Teams get an overview of images with vulnerabilities, as well as details on impacted workloads and risk reduction recommendations.

受影响工作负载的详细信息和风险降低建议

Teams get an overview of images with vulnerabilities, as well as details on impacted workloads and risk reduction recommendations.

查看漏洞并确定影响

借助 Fairwinds Insights，DevOps 领导者可以加快 DevSecOps 的采用，并使团队能够修复他们所拥有的映像的漏洞，最终缩短修复时间并加快上市速度。

受监控的基础设施并不好玩...但这很关键

原文：https://www.fairwinds.com/blog/monitored-infrastructure-is-not-fun-but-its-critical

缩放和自动化只有在详细监控到位时才起作用。监控是至关重要的，但是很多公司都没有时间去做。监控可能很复杂，考虑风险管理很困难(也不好玩)。

什么会出错？很多。这个想法会让人不知所措。

奠定基础

一个建议是从小处着手。要有一个适当监控的基础设施，从基线开始会有所帮助，然后每当发生一些事情时，您可以根据需要添加一个新的监控端点。例如， AWS 停运，就是一次很好的监控演练。每当一家公司或该公司的客户注意到应用程序存在问题时，就有机会将未来的监控端点整合到基础架构中。

对于服务器实例，您可以做一些基本的检查:

我的实例启动了吗？( Kubernetes 可以为你监控服务器状态。)
我的实例/服务器是否有足够的资源——磁盘空间、CPU 使用率和 RAM 使用率。(Kubernetes 也可以帮你监控这些资源。)
我的所有集群节点可以互相通信吗？

能够区分基础设施问题和应用程序问题非常重要。因此，您需要网络和应用程序监控。将服务器日志和集群日志放在一个集中的日志记录位置，这与记录应用程序出现的所有错误一样重要。

基础设施建设得当

虽然自动化和监控的重要性已经得到了很好的理解，但是并不总是能够实现足够的自动化和监控。另一方面，扩展是大多数公司都会犯的错误。因为他们不明白如何适当地扩展，所以公司经常用硬件来解决问题。这样的解决方案既不便宜也不高效。

将注意力转向 Kubernetes 的公司很快了解到它的扩展能力以及充分利用资源带来的相关节约。这些都是很大的卖点。Kubernetes 可以更快地运行您的应用程序，并且易于部署，但它还有其他功能:它可以帮助您以最有利的方式安排和使用您的资源。

集装箱化，尤其是 Kubernetes，吸引了许多公司。但是，如果这些公司试图在内部实现 Kubernetes，他们往往最终会雇用人员，并让这些资源承担学习复杂新技术的耗时任务。(然后他们希望这些人会留下来。)这就是有经验的 DevOps 合作伙伴的用武之地，他们可以帮您减轻负担，降低成本。

总之，Kubernetes 可以为您照顾您的基础设施自动化和监控需求。合适的 DevOps 合作伙伴可以实施战略解决方案，以确保您的扩展、自动化和监控完全按照预期方式运行。在合作伙伴的帮助下，您可以确保您的 Kubernetes 基础设施运行正常。

监控和记录

原文：https://www.fairwinds.com/blog/monitoring-and-logging

在我的运营生涯中，我有过很多关于监控和日志记录的争论。许多争论都集中在我想监控和记录“太多”的想法上。这不一定是错误的，但我一直认为它更像是“监控和记录一切”

原因很简单。当(不是“如果”)出现问题时，您将需要数据来帮助理解和排除故障。如果你不监控和记录所有的事情，那么你将永远至少部分地处于黑暗中。我确信哲学上的争论是关于永远不能真正监控一切…但我认为重点是明确的。

关于关键绩效指标的问题

也就是说，并不是你收集的每个数据点都是关键绩效指标(KPI ),你也不需要为每个数据点设置警报。您也不需要将所有数据保留 30 年。如果有意义，保留你的 KPI 更长时间。举例来说，你的应用程序的平均响应时间可能在一年后仍然有用，但是 web 服务器的磁盘利用率可能就没那么有用了。

我们还经常被要求推荐和实施监控。这很简单。使用类似于 datadog 和 loggly 的服务。

监控和日志服务

除非您的核心业务是监控/日志记录，否则您应该将此成本汇的管理工作留给真正关心它的人，因为这是他们的业务。你永远不会从监控中赚钱，与其转移你的宝贵资源，不如利用这些资源来创收。

有一个例外，那就是规模。当您运行大量系统时，许多监控和日志记录服务会变得非常昂贵。在这种情况下，规模经济可能有利于整合定制解决方案。

与古老的 Nagios 和它的 forks 相比， Sensu 是一个很好的警报工具，在有短暂机器的云环境中工作得更好。最大的原因是基于订阅的客户端监控和比 Nagios 更容易分配负载的能力。与 Nagios 非常相似，Sensu 没有提供跟踪和绘制收集的数据点的方法。也喜欢 Nagios，不难补充。一个不错的选择就是InfluxDB搭配 Grafana 。石墨是代替 InfluxDB 的另一种选择，但是更难设置和维护。

在伐木方面，最大的打击者是麋鹿栈。没有太多的大惊小怪，你可以聚集你所有的日志，并通过搜索和可视化处理它。还有一个非常好的社区可以帮助解析和分析日志格式。

最后

最终归结为成本。有许多设备要监控，许多日志要汇总，您可能会考虑自己运行。随着规模的扩大，服务成本会迅速增加。只是一定要记住，虽然你可以免费运行一些非常好的工具，但设置和维护仍然需要进行。如果你有员工和技能，让这不成问题的去做吧。否则，您将更好地专注于您的产品并创造收入，而不是冒险进入监控、日志记录和指标收集的兔子洞。

我们使用的最有帮助的 Kubernetes 开源项目

原文：https://www.fairwinds.com/blog/most-helpful-kubernetes-open-source-projects

Kubernetes 本身就是最好的开源贡献之一——这就是为什么我们 Fairwinds 的团队 100%致力于这个项目和社区。

我们的 SREs 团队致力于帮助企业最大限度地受益于 Kubernetes。我们使用许多开源工具，并贡献项目，以确保组织能够运行安全、可靠和可扩展的 Kubernetes 基础设施。

我们询问了我们的销售代表他们最喜欢的开源项目。在这里，我们列出来，以帮助您的 Kubernetes 之旅。

nginx-ingress+cert-manager+外部 dns 的组合

ingress-nginx 是 Kubernetes 的入口控制器，使用 nginx 作为反向代理和负载平衡器。

cert-manager 是 Kubernetes 的一个附加组件，用于自动管理和发布来自各种发布源的 TLS 证书。它将确保证书有效并定期更新，并尝试在到期前的适当时间续订证书。

ExternalDNS 将公开的 Kubernetes 服务和入口与 DNS 提供商同步。它使得 Kubernetes 资源可以通过公共 DNS 服务器被发现。像 KubeDNS 一样，它检索资源列表(服务、入口等)。)来确定所需的 DNS 记录列表。然而，与 KubeDNS 不同，它本身不是 DNS 服务器，而只是相应地配置其他 DNS 提供商——例如 AWS Route 53 或 Google Cloud DNS。

nginx-ingress+cert-manager+external-DNS 的组合允许系统管理员自动完成一些历史上最困难或最烦人的任务。

舵

Helm 帮助您管理 Kubernetes 应用程序——Helm 图表帮助您定义、安装和升级最复杂的 Kubernetes 应用程序。

我们使用 Helm 安装内部应用程序和第三方应用程序，但真正喜欢它安装第三方应用程序。

清算者+舵手

计算者是由费尔温德 SRE 团队创建的 helm 命令行助手。该实用程序以多种方式增加了 Helm 的功能:

创建声明性语法，以便在一个位置管理多个版本
允许从 git 提交/分支/发布安装图表

计算者为 Kubernetes 团队节省时间和头痛。

kubectl-ns

kubectl-ns 允许你通过 kubectl 快速查看或更改当前名称空间。它非常具体，每次使用只节省一点时间。但是因为我们的团队每天使用它很多次，所以这是一个巨大的努力与价值的比率。库贝克斯和库本斯是你可以使用的类似工具。

kubetails

kubetails 是 bash 脚本，它使您能够将来自多个 pod 的日志聚合(跟踪)到一个流中。这与运行“kubectl logs -f”是一样的，只是针对多个 pod。

船尾

船尾允许你在 Kubernetes 上跟踪多个吊舱和吊舱中的多个集装箱。每个结果都用颜色编码，以便更快地调试。该查询是一个正则表达式，因此可以很容易地过滤 pod 名称，并且您不需要指定确切的 id(例如省略部署 id)。如果一个 pod 被删除，它将从尾部移除，如果添加一个新的 pod，它将自动添加尾部。当一个 pod 包含多个容器时，Stern 也可以对所有容器进行尾部处理，而不必对每个容器进行手动处理。只需指定容器标志来限制要显示的容器。默认情况下，所有容器都会被监听。

kube-capacity

kube-capacity 是一个简单的 CLI，它提供了 Kubernetes 集群中资源请求、限制和利用率的概述。它试图将 kubectl top 和 kubectl describe 输出的最佳部分结合到一个易于使用的集中于集群资源的 CLI 中。

金发女孩

Fairwinds 的开源工具 Goldilocks 是一个 Kubernetes 控制器，它提供了一个仪表盘，给出了如何设置资源请求的建议。为了提供建议，我们使用垂直 Pod 自动缩放器 (VPA)。VPA 控制器堆栈包含一个建议引擎，它会考虑到您的 pod 的当前资源使用情况，以便提供指导。VPA 的主要目标是实际上为你设置这些，但我们目前对它如何做到这一点并不满意；更具体地说，我们喜欢运行水平吊舱自动缩放，这并不适合 VPA。相反，我们只是使用 VPA 提供的推荐引擎，就如何设置您的资源请求和限制向您提供良好的建议。你可以在我们的博客上了解更多关于金发女孩的信息。

作为我们对 Kubernetes 社区承诺的一部分，Fairwinds 的 SREs 团队已经开发了许多开源工具。

永远不要在库伯内特斯:#1 做 k8 的艰苦方式

原文：https://www.fairwinds.com/blog/never-should-you-ever-in-kubernetes-1-do-k8s-the-hard-way

不管你是 Kubernetes 新手还是有经验，有些事情你绝对不应该在 Kubernetes 做。【Corey Quinn】云中尖叫创始人兼鸭嘴集团首席云经济学家，与 Fairwinds 总裁 Kendall Miller 和 Fairwinds 高级站点可靠性工程师 Stevie Caldwell 一起讨论开发和运营团队如果想充分利用领先的容器编制器，就不应该在 Kubernetes 中做什么。这里有一些 Kubernetes 的基本技巧，让你开始。

(请记住，这是你永远不应该做的事情，所以对某些人来说，标题可能有点不对！)

(为您的生产基础架构)做好 K8s

许多站点可靠性工程师绝对吃过 Kubernetes 的亏——从头开始学习如何设置和运行 Kubernetes 环境。不可否认，这可能是一个非常有趣的旅程，你会学到很多东西。知道幕后发生了什么是很好的，所以当你遇到复杂的问题时，你会有一些关于如何处理它们的想法。所以作为一个学习的过程，它是非常有价值的。

然而，当你试图快速启动并运行时，从一些基础开始，并从已经学会如何构建可重复框架的人那里获得帮助和建议，真的很有帮助。大多数公司都面临着同样的基础设施问题，因此，虽然你可能会学到很多东西，试图自己找出 Kubernetes 中所有的移动部分，但要找出你需要跟踪和管理的所有东西可能有点令人难以置信。艰难地学习 Kubernetes 对学习来说很好，但你可能希望你的生产基础设施建立在更健壮的东西上。

假设 Kubernetes 适合您的简单博客

如果你一直在旋转和关闭集群，也许在 Kubernetes 上写博客并不觉得多余。但即使在那种情况下，这也是一种延伸。当你学习像 Kubernetes 这样的东西时，你可能想在 Kubernetes 上运行一个“hello world”博客，作为你培训过程的一部分，因为大多数人很容易理解博客的目的和功能。从各种地方抓取一个博客应用程序并试用它是很容易的。当人们认为他们应该在 Kubernetes 上运行他们的博客时，问题就来了。

问问你自己，为什么要用非常复杂的东西来代替本质上非常简单的东西？以下是你可能不想在简单的博客中使用 K8s 的几个原因:

运行生产级 Kubernetes 集群的复杂性与成本不相称，成本可能会高得多。
为了获得最大的正常运行时间，您需要运行高可用性集群，这进一步增加了部署的复杂性。
为了一些容易以另一种方式运行的东西，不值得花费脑力去解决不正常的事情。

如果你在问自己，我应该自己建造这个吗？我应该在本地托管 WordPress 吗？我应该建立一个 Kubernetes 集群吗？答案是:可以，但不需要。选择你的战斗，保存你的能量以备不时之需。

将控制平面作为定点实例运行

你的主节点，主要是 etcd 组件，是你不想在没有你控制的情况下消失的东西。如果您的控制平面节点消失，您的工作负载仍将运行，这没什么，但您需要考虑仲裁。如果你以某种方式手动操作你的控制平面，在一些节点退出后重新启动 etcd 是一个非常痛苦的手动过程。

AWS 上的 Spot 实例或其他提供者上的抢占式实例实际上是未使用的容量，其成本要低得多，但它可以随时被取走。如果你能正确地平衡它，你可以节省大量的钱，而且在大多数情况下，你的网站还能保持运行。在 Kubernetes 环境中，控制平面在您的节点帐户中所占的比例并不大。所以，你为了节省一点控制面板的费用而遇到的麻烦是不值得的。当它坏了，需要有人来修理的时候，你可能会毁了某人的一天(或一夜)。

在控制平面上运行工作负载

基本上，在控制平面上运行核心服务不是好的做法。您不希望在负责保持集群运行的节点上运行资源密集型 pod。如果您的资源在控制平面上失去控制，这将真正影响您的部署。您希望保持控制平面的稳定，并将需要大量资源的工作负载分开。

观看整个网上研讨会点播了解你在 Kubernetes 还应该做什么。

永远不要在 Kubernetes 第 2 部分:Kubernetes 安全错误

原文：https://www.fairwinds.com/blog/never-should-you-ever-in-kubernetes-part-2-kubernetes-security-mistakes

正如我们在这个系列的第一篇文章中所概述的，有些事情你绝对不应该在 Kubernetes 上做。 Corey Quinn ，云中尖叫的创始人和鸭嘴集团的首席云经济学家，与 Fairwinds 的总裁 Kendall Miller 和 Fairwinds 的高级站点可靠性工程师 Stevie Caldwell 谈论了一些事情，如果他们想从领先的容器编排器中获得最大收益，开发和运营团队永远不应该在 Kubernetes 中做这些事情。以下是一些需要记住的基本 Kubernetes 安全信息。

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

以 root 用户身份运行容器

这实际上在我们的网上研讨会中引发了比你预期的更多的对话。许多人不知道你可以不用根来运行容器。以 root 用户身份运行是一种非常常见的做法，因为出于实际原因，许多容器默认以 root 用户身份运行。这是因为它允许更容易的调试，但是最好还是避免以 root 用户身份运行。以 root 用户身份运行的容器通常拥有比其工作负载所需更多的权限，如果您的容器受到威胁，这可能会帮助攻击者。这似乎是显而易见的，但是放弃对任何东西的特权访问会导致集群中的特权行为。我们强烈建议您不要以 root 用户身份运行您的容器。

与 CTO 共享您的证书颁发机构密钥

您是否应该与 CTO 共享您的证书颁发机构(CA)密钥？有一种观点认为，在绝对必要的情况下，给予首席技术官“打破玻璃的权限”是非常重要的。那是有价值的。您希望不要让个别系统管理员挟持公司。然而，从另一方面来说，如果他们碰不到东西，这意味着他们很难打破它，所以他们被迫间接地去做。允许访问这样的东西通常不值得做，不是因为他们会做任何邪恶的事情，而是因为如果出了问题，谁可能会对问题负责。很有可能，您的 CTO 不需要 CA 密钥。如果出现问题，让一个较小的小组来控制 CA 密钥会更容易，这样您就知道谁可以快速检查问题并解决它。

在 Github 中明文存储你所有的秘密

我们来谈谈在 Github 中用明文存储你所有的秘密。你永远不应该那样做。那是因为坏演员找的都是在 Github 存储凭证的人。如果您将未加密的凭证签入存储库，即使是在受约束的测试环境中，其他人也会发现这些凭证，可能会启动 Kubernetes 集群，然后让它挖掘比特币。

将您的 Kubernetes 秘密签入您的基础设施即代码存储库是很诱人的，这样您的构建是可复制的。但是如果你关心安全，就不要。一旦签入，您的秘密就会永久地暴露给任何能够访问您的 Git 存储库的人。

硬核 ips _ 忽略内部 dns)

让我们谈谈对入侵防御系统进行硬编码并忽略内部域名系统。你永远不应该那样做。为什么不呢？我们在 Fairwinds 见过这种情况——一个客户拿着 Excel 电子表格中的 IP 地址列表来找我们。他们在应用程序中嵌入了硬编码的集群 IPs。大多数人都知道，有些人不知道，您的 pod IPs 发生了变化，您的集群 IPs 也发生了变化。你不能指望这个，Kubernetes 内置了这些东西，让你的生活更轻松。它内置了域名系统，所以使用服务的域名系统名称。operations中的一切都是一种交易，只要你知道你在做什么，所有这些事情你都可以在库本内斯做。把事情搞砸真的很容易。

新的 Fairwinds Insights 发布:地形扫描

原文：https://www.fairwinds.com/blog/new-fairwinds-insights-release-terraform-scanning

说到安全问题，时间是至关重要的。平台工程团队需要能够在部署过程中尽早发现问题，同时能够立即采取行动。

通过 Terraform 扫描更快地检测安全问题

最近的一个版本扩展了 Fairwinds Insights 的“基础设施即代码(IaC)”功能和通过地形扫描向左移动的安全思维。Insights 用户现在可以使用 IaC 扫描来检查 Terraform 文件中的配置问题，这些问题可能会使您的工作负载和云基础架构面临风险。

Terraform 扫描会根据一系列最佳实践检查您的文件，然后生成操作项目，例如:

配置您的亚马逊网络服务(AWS) EKS 集群来加密 Kubernetes 静态秘密数据。这可以防止访问 Kubernetes etcd 数据库的人访问 Kubernetes 的秘密数据。
将您的谷歌云平台(GCP) GKE 集群配置为自动修复节点。这将自动替换停止响应或磁盘空间不足的 Kubernetes 节点。
确保您的 AWS 或 GCP 存储桶不允许公众访问对象。这验证了 S3 或 GCS 存储桶不允许对其文件的自由访问。

通过在拉动请求阶段进行整合——无论是通过 Fairwinds 的GitHub integration还是在您最喜欢的 CI 平台——交付团队都会受益于即时反馈循环，因此他们可以更快地解决问题。此外，领导者可以使用策略执行来根据扫描结果控制管道或合并请求。

对于已经使用了 IaC 扫描的 Insights 用户来说，利用 Terraform 扫描很容易！要启用与 CI 集成的 Terraform 扫描，只需将 CI 脚本升级到最新版本。那些使用自动扫描不需要采取任何进一步的行动；此功能已经启用。

还没有使用 Fairwinds Insights？试用我们的免费层,适用于多达 20 个节点、两个集群和一个存储库的环境。

金发女孩 3.0.0 的新功能

原文：https://www.fairwinds.com/blog/new-in-goldilocks

我们最近发布了 Goldilocks 的 3.0.0 版本，有很多非常大的变化。我想花一点时间展示哈里森·卡茨在过去几个月里为实现这一目标所做的辛勤工作。

什么是金发女孩？

如果你正在阅读这篇文章，而你还没有听说过 Goldilocks ，它是一个工具，允许你查看关于设置 Kubernetes 部署的资源请求和限制的建议。它通过管理垂直 pod 自动缩放器(VPA)的控制器来实现这一点，并提供一个总结这些 VPA 中包含的建议的仪表板。 GitHub

什么变了？

我使用的大多数集群都在 10-50 个节点的范围内，只有十几个名称空间。这意味着，在最初测试和实现 Goldilocks 时，我没有大量的数据来筛选，然后将它们呈现给仪表板。Harrison 发现，在拥有数百个名称空间和数百个垂直 Pod 自动缩放(VPA)对象的大型集群中，仪表板将需要很长时间才能加载，有时甚至根本无法加载。

为了解决这个问题，金发姑娘不得不经历许多变化。最值得注意的是，从事物的前端来看，您现在只看到一个名称空间列表。您可以一次查看所有名称空间，也可以深入查看各个名称空间。

我们在 3.0.0 中做的最后一个重大改变不是金发女孩本身，而是我们部署金发女孩的方式。在旧图表中，vertical-pod-auto scaler(VPA)可以通过钩子安装，这些钩子调用 VPA repo hack 目录中的 bash 脚本。这导致了许多不同的问题，并且没有选项来配置垂直 pod 自动缩放器。对于这个版本，我们创建了一个 VPA 图表，你可以使用它来安装 VPA 控制器和必要的资源。该图表允许定制您的 VPA 安装。

流程

Goldilocks 是我用 Go 编写的第一个大项目。因此，当我回头看代码时，我会质疑我做某些事情的方式以及许多代码的组织方式。我最初写它是为了让我自己的生活变得更容易，当金发女孩得到如此多的反馈和采纳时，我真的很惊讶。

因此，当 Harrison 找到我们，告诉我们他和他的同事们已经解决了围绕大型集群的许多主要问题时，我欣喜若狂。然后，我们开始了一长串的拉式请求、审查、修改和相互等待。总的来说，对我们的一个开源项目做出如此大的外部贡献是一次美妙的经历。很高兴看到公司给他们的工程师时间和空间来为他们认为有价值的开源项目做贡献。

结论

Goldilocks 3.0 在具有大量名称空间的大型集群中表现更好，可以查看单个名称空间的资源建议，并且安装 VPA 更加简单。

Goldilocks 代码库中正在发生大量伟大的事情，我很高兴看到它的未来走向。再次感谢哈里森的辛勤工作和耐心。

资源

Nova 开源工具——监控新版本

原文：https://www.fairwinds.com/blog/nova-monitor-helm-for-new-releases

在运行生产 Kubernetes 集群时，最重要(也是最繁重)的任务之一是保持所有内容都是最新的。Kubernetes 本身削减了季度发布，这很快就失去了支持——如果您无法升级，您可能会面临安全漏洞和错误的功能。幸运的是，每季度一次的节奏至少让这些发布变得可预测:你甚至可以每三个月提醒一次。

Cyber warfare cartoon "First we inundate them with quarterly Kubernetes releases."

来源:https://gravitational.com/blog/kubernetes-release-cycle/

但是在 Kubernetes 之上，你可能有半打的附加组件在你的集群中运行，很可能通过 Helm 安装了。nginx-ingress、cert-manager 和 linkerd 等辅助组件通常对运行生产级集群至关重要。对于 PostgreSQL 或 Wordpress 等常见应用程序，您甚至可以使用 k8s 特定的部署。这些工具都有自己的发布节奏，一些更新可能会附带重要的安全补丁。

安装一个新的补丁通常并不困难——通常它只是意味着重新运行一个 helm install, 命令，或者更新你的基础设施即代码库中的一行代码。但是你怎么知道什么时候该更新了呢？与 Kubernetes 本身不同，掌舵图的更新难以监控和预测。

观察并报告

Nova_bfw_color

进入 Nova ，Fairwinds 的开源工具。

Nova 是一个命令行界面，用于交叉检查集群中运行的最新版本的舵图。点击发微博

Nova 是一个命令行界面，用于交叉检查集群中运行的最新版本的舵图。Nova 会让您知道您运行的图表是否过期或被弃用，因此您可以确保您始终了解更新。

Release Name      Installed    Latest     Old     Deprecated
cert-manager      v0.11.0      v0.15.2    true    false
insights-agent    0.21.1       0.21.1     false   false
grafana           2.1.3        3.1.1      true    false
metrics-server    2.8.8        2.11.1     true    false
nginx-ingress     1.25.0       1.40.3     true    false

这很容易看出你在任何已安装的舵图上落后多少。在上面的例子中，我们已经获得了最新版本的 insights-agent, ，但是对于一些核心基础设施还有一些小的更新，包括 cert-manager, nginx-ingress, 和metrics-server.``grafana也有了新的主要版本，所以我们可能会错过一些很酷的新功能！

挑战

这是一个比预期更难的问题。

第一个问题是同时支持头盔 2 和头盔 3。Helm 2 使用 ConfigMaps 存储图表元数据，这非常容易解析。但是圣盔 3 使用了秘密，以及一些拜占庭式的编码实践。在来自Pluto 团队的一些帮助下，我们构建了对两个版本的支持，以及从两个版本自动检测图表的能力。您可以通过指定 --helm-version=auto. 来使用该功能

更具挑战性的是将安装的图表与上游源进行匹配。不幸的是，Helm 没有在图表元数据中存储关于上游存储库的信息，这使得精确匹配变得不可能。我们所要做的只是名称，它可能会在不同的存储库中重复。比如很多的位图最近从核心图回购中迁移出来，但是保留了相同的名称。

为了找到匹配，我们必须在所有已知的库中查找具有匹配名称的图表，然后使用类似图表的 version, home, description, 和 maintainers 的试探法来找到一个好的匹配。到目前为止，这种策略有 100%的成功率，但感觉有点像黑客。如果你知道一个更好的解决方案来找到一个已安装的舵图的上游存储库，请告诉我们！

付诸实践

Nova 为任何希望保持图表最新的人节省了大量的时间和精力。运营商现在可以运行一个 CLI 来检测集群中运行的旧版本，而不必监控每个图表的更新。但是您仍然需要记住运行 CLI！

当管理数百个集群时，忘记在特定集群上运行 Nova、误读输出或未能根据结果采取行动的可能性几乎是确定无疑的。此外，一些组织需要在给定工具的旧版本上(特别是， cert-manager 已经定期引入突破性的变化)。所以我们需要一种方法来大规模操作 Nova。

最简单的方法就是使用费尔温斯洞察。Insights 可以定期自动运行 Nova(以及其他 Kubernetes 审计工具)，默认情况下每小时运行一次，并使用结果创建行动项目。这些行动项目作为更新你的舵轮图的提醒，并且可以通过管道传送到 Slack、Datadog 或你的工程师居住的任何地方。

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

在内部，我们还维护了一个 YAML 文件，其中包含一组标准，即我们希望客户运行的每个附加组件的特定版本。我们使用 Nova 来确保 YAML 文件保持最新版本，并使我们的基础设施即代码符合这些标准。

下一步是什么

自动检查舵图的更新解决了我们 Fairwinds 以及整个 Kubernetes 社区的一个大问题。但是生态系统发展迅速，我们需要掌握更多的软件和基础设施。我们希望构建自动化检查的其他内容有:

受管理的 Kubernetes 提供商(如 GKE、EKS 和 AKS)支持 k8s 版本
码头标签(至少在使用 semver 标签的地方)
Docker 基本图像

这些检查是否适合 Nova，或者是否将证明创建一个单独的项目是合理的，还有待观察。

在任何领域，保持最新版本是一个大而可怕的问题。我们希望 Nova 能够帮助 Kubernetes 社区保持集群的可靠性和安全性。

NSA 强化指南:Fairwinds Insights 如何加强您的身份验证和授权实践？

原文：https://www.fairwinds.com/blog/nsa-hardening-guide-how-can-fairwinds-insights-strengthen-your-authentication-authorization-practices

如果你还没有翻阅美国国家安全局最近的 Kubernetes 强化指南来了解更多关于当今 Kubernetes 和云原生技术的最佳实践，不要担心——我们已经覆盖了你。在关于这些新兴标准的五篇系列文章的第三部分中，我们将讨论认证和授权的所有内容，包括如何fair winds Insights，我们的 Kubernetes 治理平台，它可以帮助您的组织满足 NSA 的严格建议。

ICYMI : NSA 加固指南: 利用 Fairwinds Insights 锁定网络访问

ICYMI: NSA 加固指南: 三种方式的 Fairwinds 见解可以根除糟糕的 Pod 安全性

认证的重要性

作为限制访问群集资源的主要机制，身份验证和授权的最佳实践至关重要。如果 Kubernetes 集群配置错误(这种情况经常发生),坏人可以(而且确实会)扫描众所周知的 Kubernetes 端口，访问集群的数据库或在没有身份验证的情况下进行 API 调用。是的，支持多种用户身份验证机制，但默认情况下不启用。

NSA 已经就登录程序、特定政策的制定和强身份认证的需求提出了几项重要建议，所有这些都通过 Fairwinds Insights 的功能得到了具体解决。请关注我们，我们将概述我们的 Kubernetes 治理软件可以帮助您的组织遵守这些现代实践的不同方式，这些实践现在被认为是 Kubernetes 所有权的黄金标准。

NSA 对认证和授权有什么建议？

NSA:禁用匿名登录 。匿名请求是指不会被其他已配置的身份验证方法拒绝的请求，并且不会绑定到任何个人用户或 Pod。启用匿名请求可能会允许网络参与者在未经身份验证的情况下访问群集资源。

Kubernetes 为用户提供了多种向集群进行身份验证的方法，并且有内置的用户，如 system:unauthenticated 和角色，如system:public-info-viewer，它们允许公共访问健康和版本 API 等内容。

在自管理集群上，可以通过-anonymous-auth标志禁用匿名登录。该流程可以像 GKE 一样更多地参与托管服务。

Fairwinds Insights 可以通过其 kube-bench 集成，帮助确保在您的集群上设置 - anonymous-auth 标志。具体来说，check 4.2.1 将确保此标志设置为 false，如果不是，则引发一个操作项。

想一下子得到所有 NSA 的推荐？下载我们的白皮书: 满足 NSA Kubernetes 强化指南的步骤

NSA:使用强用户认证 。管理员必须实施认证方法或将认证委托给第三方服务。Kubernetes 假设独立于集群的服务管理用户认证。

获得正确的集群身份认证对于安全性和必须与集群交互的工程师的日常工作效率都至关重要。Kubernetes 在这里提供了许多不同的选项。如果您正在使用 GKE 或 EKS 等托管 Kubernetes 提供商，我们建议您使用云提供商的内置身份和访问管理(IAM)。例如，Kubernetes 团队提供了aws-iam-authenticator，用于通过现有的 AWS 组和角色管理集群访问。

如果您没有使用托管的 Kubernetes 提供商，或者如果 IAM 不是一个选项，我们建议您使用 OpenID Connect (OIDC)以及像 Google Workspace 这样的 SSO 提供商。

NSA:创建具有独特角色的 RBAC 政策。基于角色的访问控制(RBAC)，默认启用，是一种基于组织内个人角色来控制对集群资源访问的方法。RBAC 可用于限制用户帐户和服务帐户的访问。

一旦用户能够使用上述身份验证方法连接到集群，您将需要设置 RBAC，以确保他们拥有完成工作所需的权限，同时仍然遵循最小权限原则。

我们强烈建议设置与贵公司具体工作描述相关的角色和集群角色。例如，您可能有一个开发人员角色，可以查看日志和状态；允许在应用程序命名空间中进行更改的 SRE 角色；和被授予广泛访问权限的管理员角色。

RBAC 经理可以帮助用更友好的语法创建 RBAC 配置文件，而 Fairwinds Insights 提供了一个仪表板，用于审计 RBAC 配置，显示具有高级访问权限的角色和集群角色。

更好认证的步骤&授权

如果您想了解有关 Fairwinds Insights 如何帮助您的企业遵守 NSA 最新准则的更多信息，请阅读我们最新的白皮书，满足 NSA Kubernetes 强化准则的步骤。

我们的 NSA 白皮书还提供了关于满足所有 NSA 建议的信息，而不仅仅是那些与身份验证和授权相关的信息。该白皮书详细讨论了其他领域，如 pod 安全、网络访问、审计日志、威胁检测和其他应用程序安全实践。

NSA 强化指南:利用 Fairwinds Insights 锁定网络访问

原文：https://www.fairwinds.com/blog/nsa-hardening-guide-locking-down-network-access-with-fairwinds-insights

在我们的第二篇博客中，涵盖了 NSA Kubernetes 强化指南，我们将讨论无数种方式fair winds Insights——以及开源和云原生技术——可以帮助您的组织遵守这些重要的建议。虽然我们的第一篇文章介绍了 Insights 增强和支持 pod 安全性的功能，这是云环境中所有企业都应该关注的问题，但我们的第二篇文章将重点关注网络分离和强化。

想要立刻得到所有美国国家安全局的建议？下载我们最新的白皮书

满足 NSA Kubernetes 硬化准则的步骤。

寻址网络

集群网络是 Kubernetes 概念的核心。必须考虑吊舱、容器和外部服务之间的通信。默认情况下，Kubernetes 资源不是孤立的，如果集群受到威胁，就无法防止横向移动或升级。资源分离和加密是限制数字攻击者在 Kubernetes 集群内活动和升级的有效方法。

总体而言，美国国家安全局建议使用网络政策和防火墙来分离和隔离资源，保护控制平面，以及加密流量和静态敏感数据。让我们看看我们的 Kubernetes 治理软件解决这些关键领域的不同方法，包括遵守所有措施的最佳方法。

围绕网络分离，NSA 有哪些建议？

NSA:使用防火墙锁定对控制平面节点的访问。控制平面是 Kubernetes 的核心，允许用户在集群中查看容器、安排新的 pod、读取机密和执行命令。由于这些敏感功能，控制平面应该受到高度保护。Kubernetes API 服务器不应该暴露给互联网或不可信的网络。

保护控制平面访问的最简单方法是使用托管的 Kubernetes 服务，如 GKE 或 EKS。这些解决方案抽象出控制平面，防止其配置错误。

如果您必须管理自己的控制平面节点，请使用 VPC 和网络访问控制列表(NACL)来控制对节点的访问。我们建议通过与您的控制平面节点位于同一 VPC 中的 SSH 堡垒来控制对控制平面的访问。

NSA:使用 RBAC 锁定对控制平面节点的访问。默认情况下启用，RBAC 是一种用于根据组织内个人的角色来控制对集群资源的访问的方法。RBAC 可用于限制对用户和服务帐户的访问。

在库伯内特，RBAC 是一个棘手的概念。Fairwinds 提供了两个开源项目来帮助管理 RBAC:

【RBAC】管理器提供了一个更简单的权限调配接口。
RBAC 查找允许用户精确地确定谁有权访问什么。

虽然每个组织都有不同的需求，并对如何配置 RBAC 做出不同的设计决策，但利用角色和集群角色为不同的角色提供不同的访问级别是势在必行的。这有助于遵守最小特权原则，还有防止诚实错误的额外好处。

Fairwinds Insights 提供了一个界面，用于审核每个集群中的 RBAC，显示特别危险的角色和集群角色。

NSA:对控制平面组件和节点使用单独的网络。 管理员应主动限制攻击面，将工作节点与不需要与工作节点或 Kubernetes 服务通信的其他网段分开。

网络分段是限制攻击爆炸半径的一个很好的方法。特别是，将面向用户的应用程序与控制平面分开非常重要，这样可以防止攻击者逃离应用程序环境并获得对整个集群的访问权限。

我们建议在您的 VPC 中为不同类型的工作节点使用不同的子网，特别是将需要控制平面访问的 nginx-ingress 或 cert- manager 等工具从面向用户的应用程序中分离出来。像 AWS 的安全组这样的概念可以用来限制节点组之间的通信。

借助 Fairwinds Insights，您可以在 Kubernetes 集群中运行 kube-hunter，以更好地了解哪些节点可以访问控制平面。为了了解这些节点对控制平面的访问权限，我们建议将 kube-hunter 配置为在应用程序节点上运行。

NSA:配置控制平面组件，以使用 TLS 进行经过认证的加密通信。etcd 后端数据库存储状态信息和集群机密。它是一个关键的控制面板组件，获得 etcd 的写访问权限可以让 cyber actor 获得整个集群的 root 访问权限。

默认情况下，大多数 Kubernetes 部署都会加密网络流量。无论您是使用 EKS 或 GKE 这样的托管 Kubernetes 服务，还是使用 kOps 这样的工具来管理自己的控制平面，默认配置都将使用 TLS 来加密与控制平面的通信。

与往常一样，确保你使用的是最新版本的 Kubernetes 和 kOps 之类的工具。

NSA:静态加密 etcd，使用单独的 TLS 证书。etcd 后端数据库是一个关键的控制平面组件，也是控制平面中最重要的安全部分。

同样，通过使用 GKE 或 EKS 这样的托管 Kubernetes 服务，您可以避免担心您的控制平面配置。但是，如果您确实需要管理控制平面节点，请确保加密底层卷，并设置唯一的 TLS 证书，以便与 etcd 进行通信。

Fairwinds Insights 可以在您的每个集群中运行 kube-bench，它会根据 CIS 基准运行许多自动检查。其中一个检查(检查 2.1)将确保您已经用适当的证书文件和密钥文件配置了 etcd。如果没有，Fairwinds Insights 将创建一个行动项目来解决问题。

NSA:设置网络策略隔离资源。 网络策略控制 pod、名称空间和外部 IP 地址之间的流量。默认情况下，没有网络策略应用于 pod 或命名空间，导致 pod 网络中的进出流量不受限制。

虽然 Kubernetes 提供了内置的网络策略资源，但它的范围相当有限。它只能在 L3/L4 限制流量，例如基于 IP 地址，这使得它在实践中很难使用。

我们建议使用像 Linkerd 这样的开源服务网格。该服务可以捕获 L7 语义，允许更具可读性、可维护性和细粒度的网络策略。Linkerd 还在 Pod 级别而不是 CNI 级别执行其策略，这更接近于“零信任”的理想状态。

网络加固的后续步骤

如果您有兴趣了解更多有关见解如何帮助您的组织实现新的 NSA 准则的其他基准，包括如何创建明确的拒绝网络策略并将所有敏感信息加密到 Kubernetes Secrets 中，请阅读我们的新白皮书，满足 NSA Kubernetes 强化准则的步骤。此外，这些信息将告诉您如何在部署期间避免错误配置并实施推荐的措施和缓解措施。

我们的 NSA 白皮书还提供了关于满足所有 NSA 建议的信息，而不仅仅是 pod 安全性和网络加固。它包括对其他领域的详细讨论，如身份验证和授权、审计日志、威胁检测和其他应用程序安全实践。随着集装箱化世界的不断发展，越来越明显的是，强大的纵深防御方法是最小化风险、最大化效率和创新的最佳方式。

NSA Kubernetes 强化指南:审计日志和威胁检测概述

原文：https://www.fairwinds.com/blog/nsa-kubernetes-hardening-guide-audit-logging-and-threat-detection-overview

在我们的 NSA Kubernetes 强化指南系列中，我们已经了解了 pod 安全、网络访问和认证和授权。今天，我们来看看审计日志和威胁检测部分，并提供一些关于合规性的建议。

NSA Kubernetes 强化指南概述了一种强大的深度防御方法，以最大限度地降低违规的可能性，并确保如果攻击者渗透到您的集群，爆炸半径将尽可能小。审计日志和威胁检测是 Kubernetes 安全性的重要组成部分。

Kubernetes 审计日志记录和威胁检测

启用审核日志记录

审计日志捕获集群中的归属活动。有效的日志解决方案和日志审查是必要的，这不仅是为了确保服务按预期运行和配置，也是为了确保系统的安全性。

Kubernetes 审计日志在完全启用时会生成大量信息。最起码，您应该启用审计日志，并确保它们存储在一个可以在紧急情况下查看的地方。当其他更容易理解的遥测技术出现故障时，审计日志可以帮助您找到安全漏洞或中断的根源。

保存日志以确保可用性，并聚合集群外部的日志

应该在环境的所有级别执行日志记录，包括主机、应用程序、容器、容器引擎、映像注册表、api 服务器和云(如果适用)。捕获后，这些日志应全部聚合到一个服务中，以便为安全审计员、网络维护者和事件响应者提供整个环境中所采取措施的完整视图。

我们建议将所有审计、节点和应用程序日志以及任何其他相关日志发送给第三方服务，如 Datadog 。这一举措有助于确保日志在发生攻击或中断时仍然存在。它还用于整理不同来源的日志，因此可以通过单一控制台调查事件。

Kubernetes 治理平台 Fairwinds Insights 可以将事件和指标导出到 Datadog，允许您用与 Kubernetes 环境变化相关的附加信息来注释图表和增强日志。

在整个环境中配置日志记录

在 Kubernetes 中运行应用程序的系统管理员应该为他们的环境建立一个有效的日志记录和监控系统。仅仅记录 Kubernetes 事件不足以提供系统上发生的动作的全貌。应在环境的所有级别执行日志记录，包括主机、应用程序、容器、容器引擎、映像注册表、api 服务器和云(如果适用)。

确保您完全了解堆栈的每个级别对于集群的安全性和可靠性至关重要。这可能很难手动配置。

我们建议利用第三方软件(如 Datadog)来聚合日志，并将它们保存到外部环境中。Datadog 代理通过运行 DaemonSet(在集群中的每个节点上放置一个 Pod)自动从集群中的每个工作负载获取节点和应用程序日志。

NSA 还建议在审计模式下利用 seccomp 进行一些低级别的日志记录，以记录主机节点上的系统调用。我们推荐使用 Falco ，这是一个云原生运行时安全开源项目，它增加了匹配特定系统调用集(包括网络流量模式)以标记可疑行为的额外好处。Falco 提供了大量的内置模式，组织可以定义更多的模式。

Fairwinds Insights 可用于接收 Falco 调查结果，并在可疑事件发生时发送警报。

实施针对组织的日志监控和警报系统

Kubernetes 本身不支持警报；但是，一些具有警报功能的监控工具与 Kubernetes 兼容。如果 Kubernetes 管理员选择配置一个警报工具在 Kubernetes 环境中工作，管理员可以使用几个指标来监控和配置警报。

日志本身可以很好地用于审计目的，但是如果没有设置监控和警报，它的用处是有限的。

一些组织依赖开源解决方案，通常是 Prometheus 和 Grafana 的组合。虽然这种解决方案在某些情况下已经足够好了，但是自托管您的监控和警报很困难，并且容易出现级联故障。

我们建议结合使用 Datadog 和page duty来配置监控和警报。Datadog 可以基于原始指标和日志内容创建微调的警报，并可以向 PagerDuty、Slack 或您的工程师可能希望获得警报的任何其他地方发送警报。PagerDuty 可以帮助您管理工程师之间的寻呼机轮换，因此您可以避免单点故障并防止精疲力竭。

Fairwinds Insights 还具有内置警报功能，并与 Datadog 和 Pagerduty 进行本机连接，因此您可以就环境中出现的任何安全性、可靠性或效率问题发出警报。

Kubernetes 治理和安全平台 Fairwinds Insights 可以帮助完成 NSA 的许多最重要的指导方针。利用 Fairwinds Insights，结合其他同类最佳的商业和开源软件，可以帮助组织遵守 NSA 的建议。Fairwinds Insights 可供免费使用。你可以在这里报名。

NSA Kubernetes 强化指南:升级和应用安全

原文：https://www.fairwinds.com/blog/nsa-kubernetes-hardening-guide-upgrade-and-application-security

我们的 NSA Kubernetes 强化指南系列已经查看了 pod 安全、网络访问、认证和授权、审计日志记录和威胁检测。在本系列的最后一部分中，我们将讨论升级和应用程序安全实践。

NSA Kubernetes 强化指南旨在帮助组织加强其容器和 Kubernetes 的安全性，以最大限度地降低违规的可能性，并确保如果攻击者确实渗透到您的集群，爆炸半径将尽可能小。在这里，我们将讨论安全补丁和更新、漏洞扫描以及删除集群中未使用的组件。

及时应用安全补丁和更新

安全是一个持续的过程，及时安装补丁、更新和升级至关重要。具体的软件组件因具体的配置而异，但整个系统的每一部分都必须尽可能保持安全。这包括更新 Kubernetes、虚拟机管理程序、虚拟化软件、插件、运行环境的操作系统、运行在服务器上的应用程序、组织的持续集成/持续交付(CI/CD)管道的所有元素以及环境中托管的任何其他软件。

保持 Kubernetes 和所有底层组件和容器映像最新可能是一项全职工作(甚至是多项全职工作)。拥有合适的工具有助于减少相关的劳动和工程工作。

Fairwinds Insights 是一个帮助实施安全护栏的 Kubernetes 治理平台，它提供了两种服务:

Nova 扫描环境中任何过时或废弃的头盔版本。它将为每个有可用更新的版本显示一个操作项。
Trivy 扫描环境中每个容器的漏洞(无论是操作系统还是安装在上面的软件),并在有补丁可用时推荐升级。

此外，确保 Kubernetes 本身保持最新也很重要，因为每个版本的支持期只有一年左右。

执行定期漏洞扫描和渗透测试

管理员应定期检查，以确保其系统的安全性符合当前的网络安全最佳实践。应对各种系统组件执行定期漏洞扫描和渗透测试，以主动寻找不安全的配置和零日漏洞。

Kubernetes 集群不是一个静态的基础设施。这是一个不断发展的生态系统，每天都会自动应用新的应用程序和更新。组织必须结合使用自动化和手动渗透测试来定期扫描他们的 Kubernetes 环境中的漏洞。

默认情况下， Fairwinds Insights 每小时运行一次其组件，并且可以配置为每分钟运行一次。此功能确保在发现新漏洞时尽快提出问题。

除了上面列出的 Trivy、 Polaris 和 kube-bench 集成之外，Insights 还提供了 kube-hunter 集成，它可以自动探测集群的网络漏洞和攻击者可能利用的其他安全问题。

从环境中卸载并删除未使用的组件

当管理员部署更新时，他们还应该从环境和部署管道中卸载任何旧的、未使用的组件。这种做法将有助于减少攻击面，并降低未使用的工具留在系统中以及过时的风险。

确保陈旧和未使用的部署不会停留在您的 Kubernetes 环境中，这对于安全性和一般卫生都很重要。不幸的是，Kubernetes 没有一种通用的方法来检查集群中资源的陈旧性。有一个未解决的问题，尽管有些事情可以逐案检查。

Fairwinds Insights 有两个可定制的 OPA 策略，用于检测已有一定天数未更新的导航图和部署，这极大地帮助了检测陈旧资源所涉及的辛劳和手动工作。

Kubernetes 治理和安全平台 Fairwinds Insights 可以帮助完成 NSA 的许多最重要的指导方针。利用 Fairwinds Insights，结合其他同类最佳的商业和开源软件，可以帮助组织遵守 NSA 的建议。

NSA Kubernetes 强化指南概述

原文：https://www.fairwinds.com/blog/nsa-kubernetes-hardening-guide

本月早些时候，美国国家安全局(NSA)和网络安全与基础设施安全局(CISA)在 2021 年 8 月发布了 1.0 版本的 Kubernetes 硬化指南，并在 2022 年 3 月根据行业反馈对其进行了更新(1.1 版本)。Kubernetes 硬化指南的最新版本于 2022 年 8 月发布，其中包含一些更正和澄清。1.2 版本概述了对硬化 Kubernetes 集群的若干建议。该指南概述了一种强大的纵深防御方法，以确保当攻击者危及您的集群时，爆炸半径尽可能小。NSA Kubernetes 强化指南包括以下建议:

扫描 Linux 容器映像和容器，查找漏洞或错误配置。
以尽可能低的权限运行容器和单元。使用为以非根用户身份运行应用程序而构建的容器。如果可能的话，运行具有不可变文件系统的容器。
使用技术控制来实施最低安全级别，例如防止特权容器、拒绝经常被利用来突破的容器功能(hostPID、hostIPC、hostNetwork、allowedHostPath)、拒绝作为根用户执行的容器(或允许提升到根用户)、强化应用程序以防止利用。
使用网络隔离和加固来控制危害可能造成的损失。这包括锁定对控制平面节点的访问，并为控制平面组件和节点使用单独的网络，限制对 Kubernetes etcd 服务器的访问(etcd 应通过 API 服务器进行管理)，配置控制平面组件以使用传输层安全(TLS)证书来确保经过身份验证的加密通信，对静态 etcd 进行加密，设置网络策略以隔离资源，创建明确的拒绝访问策略，并将凭证和敏感信息加密到 Kubernetes Secrets 中。
使用防火墙来限制不必要的网络连接和加密，以保护机密性。不要将 Kubernetes API 服务器暴露给互联网或不可信的网络。
使用强认证和授权来限制用户和管理员的访问，以及限制攻击面。确保禁用匿名登录，并为基础架构团队、服务帐户、开发人员、用户和管理员创建基于角色的访问控制(【RBAC】)策略。
使用日志审计，以便管理员可以监控活动并对潜在的恶意活动发出警报。启用审核日志记录，并确保在节点、发布或容器失败时日志可用。在环境中配置日志记录，包括集群度量日志、集群应用程序接口(API)审计事件日志、Pod seccomp 日志、应用程序日志和存储库审计日志。将日志聚集在群集外部的位置，并实施日志监控和警报系统。
您的安全策略应该要求您定期检查所有 Kubernetes 设置，并使用漏洞扫描来帮助确保适当考虑风险并应用安全补丁。遵循应用程序安全最佳实践，包括按需升级、及时应用安全补丁和更新、定期执行漏洞扫描和渗透测试，以及从环境中删除未使用的组件。

为什么 NSA 强化指南对 Kubernetes 社区很重要？

组织正在采用 Kubernetes 并交付云原生应用程序，在亚马逊网络服务(AWS)、Azure 和谷歌云平台等云提供商上部署应用程序和服务。Kubernetes 开箱即用并不安全。默认情况下，部署到集群的所有设备都能够与其他设备进行通信。Pod 安全性非常重要，因为 pod 可以以 root 用户身份运行，即使您禁用了特权模式，群集中的攻击者仍然可以启用大量 pod 设置来获得底层节点的 root 用户访问权限。

不幸的是，有一个非常标准的过程来攻击你花了这么多时间的集群。考虑许多可能的攻击媒介:使用泄漏的 kubeconfig 或泄漏的云凭证、供应链攻击、暴露的仪表板或利用已知的安全漏洞。然后，攻击者可以在您的集群中执行他们自己的一些代码，提升权限，然后掩盖他们的踪迹。所有这些行为发生的同时，也创造了一个持久的立足点，使攻击者能够窃取机密和数据，消耗计算资源以获取经济利益，或实现任何数量的其他结果。

随着架构变得越来越复杂，保护您的微服务免受攻击变得越来越困难。您知道您的 Kubernetes 集群中的每个 pod 是否都禁用了主机路径吗？通过您的集群的网络流量如何 pods 能够与控制平面组件或相邻的名称空间通信吗？这些小细节是将攻击的爆炸半径限制在单个容器内、让您的集群受到威胁、甚至让您的整个云环境受到威胁之间的区别。如果攻击者逃离 pod，使用节点的云凭据获得对您帐户的访问权限，并找到更多方法来提升权限，就会发生这种情况。

从内部威胁的角度来看， RBAC 对于确保有权访问您的集群的每个人和应用程序都拥有适当级别的权限至关重要。管理 RBAC 配置文件，甚至了解配置的内容，都是一项艰巨的任务。在集群内部活动的恶意内部人员可以使用现有权限或通过利用已知漏洞来提升其权限，这就是为什么管理 RBAC、监控和修补容器中的已知漏洞以及审查服务的安全权限至关重要。

我如何实施美国国家安全局/CISA·库伯内特公司强化指南中的建议？

云本地计算基金会继续为 Kubernetes、Prometheus 和 Grafana 等项目提供开源中心。使用开源软件，如 Fairwinds 的【北极星】，是检查服务配置的第一步。借助 Polaris，您将获得 Kubernetes 安全状况的即时快照。Polaris 还提供了其他最佳实践建议，帮助您发现 Kubernetes 的错误配置并避免问题。

虽然 Polaris 改进了 Kubernetes 的部署，但 NSA 加固指南提倡采用更持续的方法来保护 Kubernetes 的安全。幸运的是，这些建议中有几个可以使用fair winds Insights来实现，它将 Polaris 与其他开源工具相结合，提供了一个简化 Kubernetes 复杂性并降低风险的平台。

借助 Fairwinds Insights，DevOps 团队将能够持续运行 Polaris，并集成从 CI/CD 到生产的多种开源安全工具。Fairwinds Insights 补充道:

【RBAC】监控: 标记任意高度宽松的配置文件
配置扫描: 确保部署的工作负载和 pod 没有过度使用 Kubernetes 的安全特性
策略实施和防护: 在 CI/CD 和准入控制器环境中建立您的最低安全要求。这将自动防止使用集群的下游团队的安全错误配置
运行时容器漏洞扫描: 识别哪些部署了容器的容器出现高严重性 CVEs，或者最近变得易受攻击

如果您有兴趣了解更多信息，请点击试试 fair winds Insights看看它如何帮助您强化 Kubernetes 环境。

最初发布于 2021 年 8 月 10 日，更新于 2023 年 1 月 23 日

OPA 替代方案:Kubernetes 政策执行的分步方法

原文：https://www.fairwinds.com/blog/opa-alternative-polaris-stepped-approach-to-kubernetes-policy-enforcement

最近，我们围绕开放策略代理(OPA)进行了多次对话，Kubernetes 用户对此很感兴趣，并希望使用它，但他们试图找出最佳的初始策略，以及是否有一种不需要编写减压阀的更简单的方法。为了帮助解决这个问题，我们在这里讨论了更多关于 OPA 和一个替代的开源项目，它可以帮助您执行 Kubernetes 策略。

OPA 背景

开放策略代理(OPA)是一个开源的通用策略引擎，它在整个体系中统一策略实施。它提供了一种高级声明性语言，允许您将策略指定为代码，并使用简单的 API 从您的软件中卸载策略决策。OPA 使您能够在微服务、Kubernetes、CI/CD 管道、API 网关等方面实施策略。您可以在 OPA 文档中了解更多信息。

正如其创始人之一所解释的,“OPA 为策略提供了自己的生命周期和工具集，因此策略可以与应用策略的底层系统分开管理...OPA 提供本地执行，是为了比硬编码的服务逻辑或特定领域语言更高的可用性、更好的性能、更大的灵活性和更强的表达能力。”

OPA 的优势

OPA 允许用户跨基础设施和应用程序设置策略。一些例子包括定义:

哪些用户可以访问哪些资源。
允许哪些子网的出口流量。
工作负载必须部署到哪些集群。
可以从哪些注册表下载二进制文件。
容器可以执行哪些操作系统功能。
一天中的哪些时间可以访问系统。

OPA 还具有上下文感知能力，因此管理员可以根据正在发生的事情(当前中断、新漏洞发布等)做出策略决策。

逐步实施政策的方法

OPA 提供了很多好处，但是它可能是重量级的，因此一些用户可能需要轻松地执行策略。作为 Kubernetes 策略执行的一个分步方法，我们使用了一个开源项目 Polaris 。今年早些时候发布了 1.0 版本，该项目正在走向成熟，并被用于多个产品，包括 Insights 和 Starboard 。

Polaris 通过运行十几种不同的检查来识别 Kubernetes 部署错误配置，以帮助用户发现经常导致安全暴露、中断、扩展限制等的 Kubernetes 配置。

北极星寻找的一些示例检查包括:

是否为 pod 配置了就绪或活动探测器
当图像标签或者未指定或者 latest.
当 hostNetwork 或 hostpath 属性被配置时。
当 resources.requests.cpu, resources.requests.memory, resources.limits.cpu 或 resources.limits.memory 属性未配置时。
当 securityContext.privileged 为真或者当 securityContext.readOnlyRootFilesystem 不为真时(在多个其他安全配置检查中)

Polaris 允许您检查常见的错误配置，而无需构建自己的策略。如果您想添加自己的定制策略和检查，您可以使用简单的基于 JSON 模式的语法来编写自己的策略和检查。当您知道需要执行策略，但不需要 OPA 提供的所有灵活性时，这是一个很好的起点。

北极星可以在三种不同的模式下运行:

作为一个仪表板，这样您就可以审计集群中正在运行的内容。
作为一个验证性的 webhook，您可以自动拒绝不符合组织策略的工作负载。
作为命令行工具，因此您可以测试本地 YAML 文件，例如作为 CI/CD 过程的一部分。

你可以在 GitHub 上查看快速入门。

在 Fairwinds，我们正致力于通过 Fairwinds Insights 简化 OPA 的使用。Fairwinds Insights 可供免费使用。你可以在这里报名。

开源项目:NOVA 3.1.0，不再仅仅面向 Helm 用户！

原文：https://www.fairwinds.com/blog/open-source-project-nova-not-just-for-helm-users-anymore

到目前为止， Fairwinds Nova 只是一个释放头盔的工具。虽然这在过去几年对我们和其他用户非常有用，但我们认识到并不是每个人都使用 Helm (gasp)！因此，我们开始为 Kubernetes 用户提供额外的功能来检测他们集群中的过期版本。

容器更新建议

从 Nova 3.1.0 开始，您现在可以使用名为 containers 的新标志运行这个开源工具。该特性将检查 Kubernetes 集群中的所有容器映像，并在有新版本可用时通知您。

此外，新的 Nova 将向您展示三种不同的更新图像的方法。我们提供绝对最新版本、最新次要版本和最新补丁版本。让我们来看看它的实际应用:

$ nova 查找-容器

容器名称当前版本旧最新最新次要最新补丁

============== =============== === ====== ============= =============

quay.io/jetstack/cert-manager-controller 1 . 5 . 0 版真实版 1.8.0 版 1.8.0 版 1.5.5 版

quay.io/jetstack/cert-manager-cainjector 1 . 5 . 0 版真实版 1.8.0 版 1.8.0 版 1.5.5 版

quay.io/jetstack/cert-manager-webhook 1 . 5 . 0 版真实版 1.8.0 版 1.8.0 版 1.5.5 版

坞站. io/bitnami/外部 DNS 0 . 10 . 2-debian-10-r0 true 0 . 11 . 1 0 . 10 . 2-debian-10-r0 . 10 . 2

这里，我们运行的是 cert-manager v1.5.0，我们有多个更新选项。如果我们只想更新最新的补丁版本，我们可以转到 1.5.5 版。如果我们想要完整的最新版本，也可以使用 1.8.0 版。

已知限制

试图寻找容器图像的新版本的最大问题是，并不是所有的容器都在它们的图像标签中使用实际的 semver 版本。容器图像标签在技术上可以包含任何东西，有些模式非常常见。

例如，如果您有一个基于 alpine 的映像和一个基于 ubuntu 的映像，您可以用 v0.0.0-alpine 来表示它们。当试图比较版本时，这个决定会导致一些真正的问题。有了这个新功能，我们尽最大努力让版本参与进来，我们不能保证什么。所以，一定要小心！

开源与商业软件:为什么你不能(总是)负担得起免费

原文：https://www.fairwinds.com/blog/open-source-vs-commercial-software-why-you-cant-always-afford-free

当构建一个应用程序时，通常最重要的技术决策归结为自己构建什么，以及在哪里依赖第三方。由于充满活力的开源生态系统，现代团队可以专注于提供让用户满意的功能，并使他们的产品从竞争中脱颖而出，依靠第三方来完成他们应用程序中乏味的样板部分。

但是，一旦您决定为应用程序的某些关键任务部分采用第三方软件，比如数据库、身份验证机制、安全审计或计算基础设施，您仍然需要做出重大决定:

你想收养一些免费的东西，并依靠你的智慧和一群志愿者来支持你吗？或者你愿意付钱给一个合作伙伴来帮助确保你的成功？

您可能会倾向于“免费”，在某些情况下，这确实是有意义的，尤其是对于较小的、约束良好的问题。但是在很多情况下,“免费”带有一个大大的星号——你会倾向于用比金钱更昂贵的东西来购买免费软件:你的时间。您将失去商业合作伙伴所能提供的大量安全保障。

十多年来，我一直在开发商业软件，从 FAANG 企业到两个人的创业公司。我注意到早期的架构决策——通常是为了发布 MVP 而仓促做出的——通常会产生巨大的后果。我的偏见通常倾向于快速实现价值的自由软件，在某些情况下，这种偏见给我、我的团队和我公司的底线带来了真正的痛苦。

让我们深入了解自由软件的一些隐性成本。

成本#1 -设置

总成本:固定的工程周数

用开源解决一个复杂的问题可能是困难的、乏味的，并且容易出错。需要做出艰难的决定:您需要决定使用哪些包，如何将它们集成到您的堆栈中，以及如何根据您的需要对它们进行最佳配置。

你需要从深入理解软件开始，但是仅仅复制/粘贴快速启动说明是在自找麻烦(参见成本#3)。如果软件足够复杂，您可能希望指定一个或多个团队成员成为您的常驻专家。

你还需要弄清楚如何在软件上培训更大的组织。这可能很棘手，尤其是当软件影响到许多不同的角色时(例如，sre、开发人员和经理)。新员工可能不熟悉该软件或您的特定实例，因此您需要一个过程来让他们在未来入职。

您可能还需要提供一些额外的基础设施来运行软件。像 Kubernetes 这样的计算平台，当与一个包管理器结合时，可以极大地简化这个过程；但是不管怎样，要准备好在您的环境中引入更多的复杂性。

最后，您可能需要花时间调整您的设置，以适应您组织的环境和需求。在这里很难判断什么时候你已经“完成”了——仅仅因为软件在工作并不意味着它是稳定的或安全的。

有了商业合作伙伴，许多设置成本就消失了。您的合作伙伴将拥有一个完整的专家团队，他们可以为您的环境提供最佳设置建议。他们将有一个专注于创造快速“价值实现时间”的产品团队，并将提供软件和服务的组合来帮助您快速启动和运行。如果是在 SaaS，你完全不用担心基础设施的复杂性。

成本#2 -维护

总成本:每月不可预测的工程周数

一旦你部署了一个新软件，维护成本很难估计或预测，但它们往往分为两类:维护和扩展。

在维护方面，至少，你需要确保定期下载和应用更新。这不仅仅是为了获得最新的特性——它还确保了错误和安全漏洞在被发现后很快得到修复。

您还需要为使用软件时出现的自发问题做好准备。您的环境在不断发展，工程师可能会开始以新的和意想不到的方式使用软件。如果软件开始变慢、崩溃或占用计算资源，你就需要改变优先级，立即投入一些工程时间来处理这个问题。

但是大部分的维护成本将来自于扩张。通常，现成的开源软件可以很好地解决单一环境中的小而简单的问题。但是对于跨越多个应用程序、集群或云环境的更大问题，现成的解决方案根本行不通。

在这些情况下，您需要投入大量精力来扩展和维护开源解决方案——随着您的团队的成长和应用程序的发展，您的需求也将随之发展。您可能需要与其他软件集成，或者启用其他安全功能(例如，满足 SOC2 或 HIPAA 等合规性标准)。如果你的团队或客户需要一个新的特性，你需要找时间来开发它；如果软件影响了大量不同的角色或利益相关者，这可能会成为一个巨大的负担。

有了商业合作伙伴，90%的维护成本就消失了。商业合作伙伴尤其受到激励，以帮助具有复杂环境的大客户，确保软件在基础设施复杂性和组织规模方面高度可伸缩。

对于 SaaS 平台，更新将自动应用；但即使在自主托管的情况下，您的合作伙伴也会为您提供清晰的升级路径，并让您知道哪些升级至关重要，哪些可以推迟。如果出现任何自发的问题，整个团队都会迅速行动起来，尽快解决问题。

此外，您的合作伙伴将根据客户反馈定期开发新功能。他们的产品将非常适合各种环境。作为合作伙伴，您将对路线图施加一些影响。

成本#3 -安全性和可靠性

总成本:无限

除了操作自由软件所涉及的劳动负担之外，你还得担心潜在的灾难。为了避免重大失败，你应该问几个问题:

如果失败，后果会是什么样？
它能在多大程度上与我们的环境相适应？
一切都安全配置了吗？
我们是否备份了任何相关数据？
我们如何确保一切按预期继续工作？
我们有监控和警报吗？

根据您具体部署的内容，您可能会遇到更多“未知的未知”。但是一般来说，有三种主要的故障模式你应该担心:

安全性 -如果服务配置错误，攻击者会做什么？
数据丢失 -如果底层数据被擦除，您能轻松恢复吗？
停机时间 -如果服务停止工作，会对您的客户或团队产生怎样的影响？

这里的关键词是风险。开源软件通常按原样发布，这意味着理解软件的来龙去脉取决于您。即使您的团队已经搜索了文档，也有很大的机会让未记录的行为或无意的错误咬您一口。

再一次，有了商业伙伴，这些顾虑几乎都消失了。您的合作伙伴受到激励，每天都在确保他们的产品安全可靠。商业合作伙伴对他们的软件承担全部责任，承担你自己承担的风险。任何问题都比你的问题更有可能影响他们的底线。

案例研究- Fairwinds Insights

在 Fairwinds，我们建立了一个审计 Kubernetes 集群的商业平台- Fairwinds Insights 。我们的很多插件都是开源的，比如 OPA ，Aqua 的 Trivy 或者我们自己的 Polaris ，所以我们在销售过程中经常会遇到的一个问题是:

“为什么我不能自己免费部署所有这些工具？”

当然，答案是你可以自己部署开源软件，但它肯定不会是免费的。我们已经花费了超过 10，000 个工程师小时来操作这些工具——设计一个通用的报告模式和转换层，构建仪表板，集成 GitHub 和 Slack 等工具，并设计工程师友好的工作流。由于这项工作，Fairwinds Insights 用户在第一天就可以获得有关其 Kubernetes 集群的宝贵信息，并可以继续轻松扩展其使用。

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

假设你选择自己做所有这些，让我们看看隐藏的(和不那么隐藏的)成本在哪里。

设置

总费用:每份报告大约 1 个工程师周

审计 Kubernetes 基础设施最困难的部分就是简单地确定使用哪些工具。我们在野外发现了几十种开源审计工具，并花了几个月的时间逐一查看，以便为每种类型的审计找到最佳选择。在我们还没有找到好的解决方案的地方，我们已经建立了自己的解决方案。借助 Fairwinds Insights，我们精心打造了一个强大的、经过充分研究的、不断发展的审计工具组合，可以满足任何组织的需求。

我们还构建了一个安装程序，将所有这些审计插件打包在一个单独的舵图中，并以统一的方式运行它们。这听起来可能很简单，但以 Trivy 为例:默认情况下，Trivy 运行在命令行上，可以检查单个容器图像中的 CVE。为了完全实现 Trivy，我们构建了一个 CronJob:

按照可配置的计划运行 CLI(通常每小时一次)
使用 Kubernetes API 收集集群中运行的映像列表
汇总结果，消除不同映像之间共享的重复漏洞
维护最近扫描过的图像列表
利用该列表确定新扫描的优先级

我们产品组合中的每个审计工具都有一个类似的包装器来完全操作它。我们已经投入了数百个工程师小时来构建和维护一个高度可配置的单行安装程序，它可以在您的 Kubernetes 集群中以一致的方式运行多达 12 种不同的工具。

最后，我们花了几周时间研究每一个工具，并对如何推广它们形成了强烈的意见。例如，有许多不同的方法来部署 OPA 来审计 Kubernetes。但是在研究了最佳实践和实际实施后，我们选定了一个解决方案:

将策略存储在策略代码库中
将这些策略与远程服务器同步
将策略联合到您机群中的每个集群
允许您在 CI、准入控制和集群内审计中运行相同的策略
允许您根据上下文打开和关闭特定的策略

自主开发的解决方案可能会错过这些最佳实践中的一些或大部分。

Fairwinds Insights 社区版永远免费使用。在此注册试用完整版 30 天。在 GKE、阿拉斯加或 EKS 进行测试，或者在测试集群上运行。

维护

总成本:每月 0.5-2 个工程师周

我们的每个审计工具都相当简单，可以临时运行，以获得集群的时间点快照。例如，您可以运行 polaris dashboard 来查看您的每个工作负载的列表以及如何改进它们。

但是，如果您关心安全性和合规性，浏览临时报告是不够的。您需要定期运行审计，将结果存储在某个地方，并跟踪随时间的变化。这将涉及提供存储(存储结果)、一些脚本(区分不同的审计)以及一些第三方集成(当新问题出现时发送警报)。您需要确保定期更新您正在使用的审计工具。而且，当这些工具中的一个更新可用时，您将需要相应地重写所有附加的基础结构。

因此，仅仅为了让定期审计运行并得到持久的结果，就必须维护大量额外的代码和基础设施。这是在您的安全、开发和运营团队开始要求额外的功能之前——当他们想要将项目分配给特定的人时会发生什么？在空闲时获得提醒？看历史趋势？在 GitHub 中制造问题？

Fairwinds Insights 团队不断与客户交流，构建出最受欢迎的功能。我们构建了用户界面来帮助:

运营团队了解哪些资源不符合他们的策略
当他们的 CI 渠道发现配置问题时，开发人员会深入研究
工程经理一眼就能了解他们的集群有多安全、高效和可靠

安全性和可靠性

总成本:无界

如果你只是在运行免费的开源工具，那就要由你来确保它们真的在运行。如果其中一个审计开始失败，或者悄悄地跳过了基础设施的某个部分，您可能会以覆盖范围的缺口而告终。无意中的失误可能会使您不符合规定，或者更糟，导致安全违规。

如果您正在持久地存储审计数据(您应该这样做！)，丢失这些数据会有什么后果？你需要确保它得到适当的备份。

此外，虽然这些工具背后的开源维护者可能愿意帮助你解决出现的问题，但他们没有义务或动机这样做。他们是志愿者，经常会超负荷工作。如果您遇到了麻烦，您的团队可能需要深入研究其他人的源代码来试图发现问题。

Insights 团队围绕应用程序建立了全天候监控和警报，任何停机都会得到即时响应。当客户有问题时，我们通过电子邮件、zoom 和 Slack 提供支持。我们受到强烈的激励，以确保我们的用户从产品中获得价值，并确保他们的数据安全。

你负担不起免费的

总而言之，使用现成的开放源码来解决一个任务关键型问题是有很大成本的。您的团队将:

花大量的时间学习和部署软件
专注于修复、升级和增强您的部署
总是面临停机、数据丢失和安全漏洞的风险

如果让我用一个词来概括部署关键任务开源软件时选择商业合作伙伴的原因，那就是:信任。

开源软件按原样提供，由志愿者维护；虽然有些人会尽力帮忙，但他们没有义务或动机来教育你，回答你的问题，或支持你的特殊需求。

为软件付费恰好符合激励机制。不要把许可证看作是为“额外的特性”付费——把它看作是一种合作关系。商业许可证为您使用软件提供了固定的、可预测的、可衡量的价格，取代了自助服务的隐藏的、可变的成本。商业伙伴关系还带来了额外的好处，如对路线图的影响，以及当您有问题或疑问时的快速支持。

最重要的是，您的工程师可以自由地专注于重要的事情——为您的用户提供有价值的功能。

开源漏洞扫描

原文：https://www.fairwinds.com/blog/open-source-vulnerability-scanning

开源漏洞扫描器用于检测软件应用程序中的开源组件。一些扫描器被称为软件组合分析(SCA)工具，它基本上是一个自动化的过程，可以识别任何代码库中存在的所有开源组件，无论是开源还是商业应用程序。

这篇文章探讨了:

开源漏洞扫描的工作原理
开源组件中的漏洞
使用开源漏洞扫描器的好处
如果您使用 Kubernetes，为什么需要漏洞扫描器
开源漏洞扫描的推荐工具

开源漏洞扫描是如何工作的？

软件组合分析是一个开源漏洞扫描解决方案，它执行评估安全性、开源许可证合规性和代码质量的分析。通过检查包管理器、清单文件、源代码、二进制文件、容器图像和其他类型的文件来识别开源组件，这些工具创建应用程序中所有开源组件的列表(有时称为开源材料清单)。然后，开放源代码漏洞扫描解决方案将已识别的开放源代码列表与各种数据库进行比较，例如来自国家标准和技术研究所(NIST)的数据库、国家漏洞数据库 (NVD)。NVD 是美国政府基于标准的漏洞管理数据的存储库，它包括安全清单参考、安全相关软件缺陷、错误配置、产品名称和影响度量的数据库。

开源组件中的漏洞

NVD 使用通用漏洞评分系统(CVSS)，这是一个开放式框架，用于交流软件漏洞的特征和严重性。通用漏洞和暴露(CVE)系统为众所周知的信息安全漏洞分配唯一的通用标识符，CVE 由 CVE 编码机构(CNA)分配。CVE 号码分配有三种主要类型:

作为编辑和主要 CNA 的 Mitre 公司
一些 CNA 为他们自己的产品分配 CVE 号码，例如微软、甲骨文、惠普、红帽等等
第三方协调人，如认证协调中心，可以为其他 CNA 未涵盖的产品分配 CVE 号码

CVEs 确保对漏洞有一致的描述，信息技术和网络安全专业人员依靠 CVE 记录来优先处理和解决漏洞。CVE 为任何特定的漏洞或暴露提供了一个标准化的标识符，这有助于您使用多个来源来评估有关问题的信息，并且 CVSS 基于各种因素来分配分数。

来源: 常见漏洞评分系统 3.1 版计算器

这些分数基于可利用性和影响的基本指标；他们称之为时间度量组，包括漏洞代码成熟度、补救级别和报告置信度；以及环境度量组，它包括修改的基本度量以及机密性、完整性和可用性要求。当然，CVSS 分数不是唯一的考虑因素。您还需要考虑该漏洞可能对应用程序机密性、完整性、可用性 (CIA)造成的影响，以及攻击者利用该漏洞的难度。

已知的开源漏洞很受攻击者的欢迎，因为通常存在已知的漏洞，这使得黑帽黑客能够尝试对多个目标进行攻击。他们需要的只是找到一些没有修补漏洞的漏洞，允许不必要的访问进入您的系统。

使用开源漏洞扫描器的好处

今天，开源软件是大多数应用程序的重要组成部分。今天的开发人员使用开源有很多原因:

开源鼓励合作
开源允许您重用公共代码，因此您可以专注于自己的优势
开源允许其他人采用你的项目并在其上构建
开源鼓励创新

包括 Fairwinds 在内的一些公司使用开源来提供 Kubernetes 支持，并帮助社区构建正确的 Kubernetes 架构和部署环境。我们的北极星提供运行检查，以找到错误配置并帮助解决它们，而 RBAC 经理帮助角色管理和授权。开源项目和解决方案提供了大量的价值，但也存在一些风险。开源漏洞扫描器通过在您的代码库中找到开源代码，并将其与开源漏洞数据库进行比较，以确定您的代码中是否有任何易受攻击的组件，从而帮助组织降低风险。了解您的开源漏洞有助于您保持应用程序的安全，这是组织面临不断变化的风险时的一个重要考虑因素。

如果您使用 Kubernetes，为什么需要漏洞扫描器

使用漏洞扫描器扫描开源漏洞对于任何组织来说都是必不可少的，对于采用 Kubernetes 的组织来说当然也是必要的。大多数应用软件依赖于开源包、库和其他第三方组件，运行在 Kubernetes 上的应用程序也不例外。为了提高 Kubernetes 应用程序的安全性，您需要考虑漏洞扫描，包括扫描容器图像以发现开源漏洞。

在软件开发生命周期的早期自动扫描并持续扫描您的容器和 Kubernetes 有助于您发现风险并确定风险优先级，以及在发现漏洞时进行补救。如果没有持续扫描，您的组织就会面临风险，因为新的简历会定期被发现和披露。网络攻击者不断寻找窃取数据、篡改部署和造成伤害的方法。

Kubernetes 是容器编排的事实上的标准，它本身是一个开源项目。Kubernetes 是云原生运动的核心，云应用的增加意味着这一趋势可能会继续。Linux 容器是任何 Kubernetes 部署中不可或缺的一部分，因此扫描这些容器中的开源安全漏洞对于维护安全环境至关重要。容器映像有多种来源，比如 Docker Hub 和其他公共存储库，并且基于不同的 Linux 发行版，比如 Ubuntu、Amazon Linux、Debian 和 Alpine。选择正确的漏洞扫描解决方案意味着选择一个参考 NVD 和特定于发行版的安全公告、支持您组织中使用的软件包管理器，并为您的应用程序中使用的任何特定于语言的依赖项和库提供语言支持的解决方案。自动化和集成的漏洞扫描可确保您及时了解所有漏洞，无论您的应用程序是否已部署。

漏洞扫描的推荐工具

有几种可用的漏洞评估或漏洞扫描工具，包括商业的、免费的和开源的解决方案。无论您选择哪种工具，都要确保您获得了从开发到部署跟踪代码中的开源代码所需的信息。了解更多关于一些可用选项的信息:

黑鸭子

Synopsys 的黑鸭软件组成分析为应用程序和容器创建精确的物料清单(BOM)，通过依赖关系分析、代码打印分析、二进制分析和代码片段分析来检测开源。这种类型的漏洞评估还允许您为开源使用、安全风险和许可证合规性定义策略，并自动执行策略和 DevOps 集成。

蛛形纲动物

Arachni 是一个免费的 web 应用安全扫描器框架，用 Ruby 开发。它的源代码是公开的，可供审查。Arachni 支持所有主要的操作系统:微软 Windows、Mac OS X 和 Linux。它通过便携包分发，并为现代 web 应用技术提供漏洞检测。Arachni 对大多数用例都是免费的，包括扫描开源项目。

锚

Anchore Engine 是一款开源 Docker 容器策略合规性和静态分析解决方案。它自动对容器中的代码进行图像检查、分析和评估。Anchor 还为每个映像提供策略评估，与容器注册表和 CI/CD 工具集成，并发现容器中的已知漏洞。

OpenVAS

OpenVAS 是一款开放式漏洞评估扫描器，提供未认证和认证测试、高级和低级互联网和工业协议、针对大规模扫描的性能调优，以及实现任何类型漏洞测试的内部编程语言。

Trivy

Trivy 是来自 Aqua Security 的开源漏洞评估工具，可以检测开源软件中的漏洞。Triivy 还提供了对风险的简短解释，这有助于开发人员决定他们想要使用哪些组件。Trivy 将漏洞扫描并入集成开发环境(IDE)。开源贡献者继续为 Trivy 创建集成和附加组件，包括用于提取漏洞度量的 Prometheus exporter，以及用于将 Trivy 安装到 Kubernetes 集群中的 Helm chart。 Fairwinds Insights 将 Trivy 集成到其平台中，以支持整个开发生命周期中的开源扫描。

扫描开源漏洞

无论您使用何种工具来保护您的软件，进行漏洞评估以扫描开源漏洞都是保护您的应用程序的重要步骤。开源漏洞会给 Kubernetes 环境带来巨大的风险，在整个开发生命周期中使用漏洞评估工具扫描漏洞可以帮助您尽早发现风险，并快速修复新发现的漏洞。Fairwinds Insights 与您的 CI/CD 渠道紧密集成，帮助您的开发团队更轻松地防止错误配置和修复漏洞。

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

了解 Fairwinds 如何帮助您自信地部署在 Kubernetes 环境中运行的应用和服务，内置的漏洞评估工具可帮助您快速找到开源漏洞和错误配置问题。

优化开发运营以解决员工流动问题

原文：https://www.fairwinds.com/blog/optimizing-development-operations-to-overcome-employee-turnover

marten-bjork-6dW3xyQvcYE-unsplash-1

当 DevOps 主管离开您的公司时，他们带走了他们对您的开发运营基础设施的知识。如果您的 DevOps 基础设施不是为连续性而设计的，这可能会使填补他们的角色的过程变得复杂，并给开发团队带来灾难。

令人欣慰的是，实现可扩展的 DevOps 基础架构是可能的，它可以确保人员变动期间的连续性，即使是在最高级别。

避免知识集中

如果您的 DevOps 主管已经使用定制代码或定制的工具组合构建了您的基础架构，那么他们是唯一知道在出现重大问题时如何对该系统进行故障排除的人。换句话说，不是让你的整个 DevOps 团队解决问题， 一个非标准化的系统让整个团队依赖你的主管来解决系统性问题。

对于接管核心 DevOps 角色的新员工来说，这必然会使过渡变得复杂。不具备系统关键知识的新员工将不得不 浪费时间破解您的基础设施，然后才能帮助解决问题。 如果在新成员熟悉你的系统的过程中出现重大问题，这会让整个开发团队陷入停顿。

定制的操作基础设施也为成长中的开发团队带来了连续性问题。 一个定制的基础设施 是不可能扩展的，因为它依赖于仅仅几个团队成员内化的知识。随着时间的推移，这种知识会被大规模稀释或丢失。从本质上来说，即使你目前的系统现在有效，它也不会永远有效。

随着开发团队的成长，一个标准化的系统允许新的团队成员利用现有的知识，减少培训时间，并帮助筛选合格的申请人。这就是为什么尽早开发标准化的基础设施对组织来说如此重要，以帮助开发运营与公司的长期目标保持一致。

员工过渡的标准化解决方案

利用 Kubernetes 的标准化 DevOps 基础设施，为开发人员和 DevOps 专家提供了一种通用语言。任何了解的团队成员都将能够在高水平上解决问题。

此外，这些经过验证的平台允许您的团队依靠更广泛的社区来获得技术支持，帮助减轻您的主管提供所有解决方案的压力。

端到端的连续性还确保了开发和部署之间的反馈，有助于提高应用程序的整体质量。由于花费在平台问题上的时间和预算更少，开发人员可以自由地将时间花在产品创新和缩短开发周期上。从长远来看，这有助于减轻因基础设施损坏或有问题而导致的开发人员流动的风险。

外卖

对于所有阶段和规模的公司，实施以 DevOps 为重点的标准化基础架构是一项值得的投资。一个非标准化的系统不能利用你的 DevOps 团队的全部能力，因为它过于依赖集中的知识。

通过员工过渡和公司扩展，标准化的 DevOps 基础架构允许您的团队快速解决问题并保持一致。

从长远来看，标准化系统有助于缩短应用部署周期、提高应用质量并减少平台问题上花费的时间，从而使您的开发运维与公司的长期目标保持一致。

我们如何创建一个由我们在 Fairwinds 的目标和价值观驱动的组织

原文：https://www.fairwinds.com/blog/organization-driven-goals-values-fairwinds

在决定我的 MBA 重点时，有一刻我认为我应该向人力资源倾斜。我对人类如何工作的着迷不亚于对技术如何工作的着迷。最终，我选择了通才路线，因为让我对工作感到兴奋的是我们如何制造一台创造机会的机器——无论是在我们销售的产品方面还是在我们运营组织的方式方面。在 Fairwinds，这是我们所做的一切的核心，以创建一个由我们的目标和价值观驱动的组织。

套用(和混搭)克里斯托弗·基尔默(我在那里度过了非常美好的五年)和鲍勃·布伦南(Fairwinds 董事会主席)的话:我的目标是建立一个组织，让我们每个人都能实现对我们来说重要的事情...提供财务、教育/发展和社交机会。其中一部分是我们的图灵奖学金计划，这是我们如何将多样性、平等和包容付诸行动的方式，即专门为黑人、土著和有色人种学生提供奖学金(BIPOC)。

改变技术的面貌

在 Fairwinds，我们相信我们工作的一部分就是参与改变整个技术的面貌。我们对未被充分代表的人才进行深度投资，并为他们创造机会——特别是通过我们的实习项目，为 folx 刚刚起步的技术人才。如果我们想在高管团队和董事会里看到不同的面孔，我们有责任掀起一股浪潮。

为此，我们必须创造一个高绩效、心理安全、目标和价值观驱动的工作环境。在 Fairwinds，我们以几种方式实现这一目标:

我们的工程组织的领导理念是公开的，我们互相遵守。
我们有一个学习的方向，相信我们都有东西可以教，有很多东西可以学。
我们对自己和彼此都负有责任。我们对卓越的样子有很高的期望，我们每天都在彼此和自己身上寻找它。
我们深深地关心着彼此，这也显示了——我们像对待完整的人类一样对待彼此。我们一起庆祝，一起努力。我们互相检查。
我们的工程领导团队(技术负责人、工程经理、主管等)随时为您解答任何问题。在 Fairwinds，可用和可访问的是台桩。

我们怎么知道它是否有效？

创造和维护文化是困难的；这是最好的团队为了成功而积极努力的事情。在一个以远程为主、员工遍布全球的组织中，这可能是一个更大的挑战。再加上全球疫情，当我们失去了面对面交流的能力，继续发展团队，并在工作环境中面临不同寻常的挑战——这并不容易。今天，Fairwinds 文化比以往任何时候都更加强大，我们可以看到它以重要的方式发挥作用:

我们有定期的学习堵塞，向任何人开放运行。一个健康的组织有很多话题和演讲者，他们乐于互相教授。
我们看到彼此的响应时间至少和我们的外部响应时间一样好。当有人需要帮助时，会有快速的呼叫和响应。Folx 不害怕说他们不知道，并且在他们提供帮助的过程中非常自卑。
人们提出了好的——也是困难的——问题。领导能力和彼此的能力。他们投身于这项事业，并为其成功投资。
最后，工作中的感觉如何？这是主观的，但却是显而易见的。互动有没有轻松感？小组会议有笑声吗？在闲暇时，folx 是否会参与一些不太具体的工作对话。(例如，最近的一个每日话题:你会带哪五种调味品去荒岛？这个问题得到了一些非常有趣的回应。)**

*## 我们如何实践我们的价值观？

很高兴听到和看到我们的团队如何欢迎每个人参与我们的谈话，这意味着每个人——从实习生到承包商到 sre 到 CEO——都是 Fairwinds 教学和学习的一部分。

我们以前的一位奖学金获得者 Cyndee 在 Fairwinds 担任带薪实习生，这是她的图灵奖学金以及 Fairwinds 与黑人在图灵的合作关系的直接结果，图灵是该校黑人学生和校友的亲和团体。在实习期间，Cyndee 获得了软件工程师的全职工作；Cyndee 在我们团队的工作帮助她获得了实践经验，并将新技能付诸实践。Fairwinds 将继续与图灵软件和设计学院合作，我们刚刚宣布了最新的 Fairwinds 奖学金获得者:

Lourdes 正在改变职业以追求她对软件开发的兴趣。
Marla 热衷于技术和舞蹈的交叉，并希望支持社区艺术和文化复原力的建设。
Natalia 离开了她在当地公共卫生部门的青少年个案工作者的职业，开始从事软件开发。

正如我在 2020 年加入 Fairwinds 之前所说的那样，“如果你是一个戴着鼻环、梳着粉色小辫的黑人女性，能够破解一些代码，或者帮助我们最大限度地提高运营效率，并且能够让我们的利益相关者在这么做的时候对你赞不绝口，那么我们想见见你。面试的时候不用把耳洞拿出来。”

Fairwinds 把钱用在了为黑人、土著和有色人种提供的学术和生活补助奖学金(BIPOC)上，他们在软件开发领域接受教育。我们将带薪实习计划的重点放在未被充分代表的人才上，这是我们在 Fairwinds 将目标和价值观付诸行动的另一种切实方式。

对于那些对软件开发充满热情并希望加入致力于国家和技术领域公正和公平的团队的人，我们正在招聘。

过度供应和过度许可的容器& Kubernetes

原文：https://www.fairwinds.com/blog/over-provisioned-and-over-permissioned-containers-kubernetes

如果你生活在运营中，你就会知道每一个决定都只是一系列看似永无止境的权衡中的一个。“最容易使用的系统”完全可以被任何地方的任何人访问，但这些系统也是最不安全的。你可以把某样东西的刻度盘调到 11，但结果是你只是把别的东西的刻度盘调到 1，总会有一个权衡。

如果每一个决策都有一个显而易见的解决方案，那么帮助人们权衡利弊的专家们的报酬就会少很多。然而，通常没有明显的“一刀切”，因为每个组织的需求对于特定的地点、时间和用例都是独特的。

在我们的环境中，我们经常倾向于过于自由地偏向，但是把事情做对是值得努力的。这种做法适用于整个 IT 世界，并且是容器和 Kubernetes 的一个实际问题。这些动态环境千变万化，错综复杂。定期保持对已配置或已许可更改的了解。配置可能会浪费金钱或带来风险。

过度供应

我有一个朋友在一家公司工作，该公司奉行“如果你建造了它，你就拥有它”的强硬路线。这意味着:如果你没有在生产的整个过程中拥有一个服务或功能的想法，包括寻呼机和下班后对任何问题的响应，就不要想出这个想法。我问这个政策是否曾经阻止人们开发一些伟大的东西，因为他们不想在工作时间之外管理它，我确信这可能已经发生了。

如果我是一个开发人员，有一个很好的想法，但维护起来很昂贵，我不会想拥有一个管理起来很费钱的东西。因此，我要么不构建，要么即使构建，我也会过度配置 h*ck。我会分配更多的资源，更多的实例，内存，计算等等...并确保该服务有足够的规模和流量，永远不会下降。

作为所有者，我的工作是确保它正常运行，虽然我必须请求许可来报销 50 美元的书，这将有助于我更好地完成工作，但我不需要请求任何许可来在我们的生产基础架构中增加价值 200，000 美元的额外实例(如果您的组织像那里的许多组织一样)。我要去做让我最舒服的事情，并确保我不惜一切代价建立起来的东西(字面上)。

从字面上看，这就是过度配置的定义。我是否会审核我的日志和使用情况报告，看看我是否可以将支出削减一半，并且仍然有一个舒适的缓冲？可能不会，因为我没有工具来帮助我这样做——而且我也没有这样做的动机。

这就是导致过度配置成为许多地方的默认配置的原因。

过度许可

在我们的默认设置中过于自由的问题不仅仅出现在供应方面，它也可能出现在许可方面。

有趣的是，当人们被授予权限时，我发现这种情况很少发生(由于运营/IT 团队中某个人的旧 HR 伤疤，人们往往在组织中受到过度限制)，但当涉及计算机时，这种情况会多得多。不管出于什么原因，我们让我们组织中的高级领导几乎没有访问权限变得非常普遍(通常他们不需要这种访问权限，不要误会我的意思)——但我们给了我们的应用程序、容器、实例和网络所有我们可以访问的权限。

很容易想到，“访问它应该不难，所以让它开放吧。”这导致了我们在服务配置中看到的最常见的情况之一——容器在集群中以惊人的速度作为根运行。问题是，如果一个坏人发现您的基础设施中有一个部分被过度许可，他们就可以得到任何其他地方。您可能已经完全锁定了您的数据库，但是如果可以访问该数据库的服务具有任何人都可以进入的权限，那么您的数据库就相当于受到了威胁。

过度许可的计算机是导致安全事故的超级常见的单点故障。

好事过头反成坏事

要完成任何事情，你都需要资源和许可。但是像任何事情一样，正确的工具可以走很长的路。想象一下在院子里挖沟渠系统来安装洒水系统——用铲子挖沟渠比用手容易得多。更好的是拥有一台定制的挖沟机器。另一方面，给每个你认识的人一台反铲挖土机，并相信他们会把它弄到需要的地方，并为洒水系统挖大小合适的洞，这可能不是一个好主意。

有一个合适的尺寸。许可权的宽大。

找到正确的平衡

如果没有合适的软件告诉你哪里做错了，找到平衡会很难。

Fairwinds Insights 让您轻松了解自己在哪些地方过度配置和过度许可。它还会收集一段时间内的数据，这样你就可以看到与上个月相比，你今天的表现如何。获得正确的设置。为了避免花费大量金钱，无论是今天的过度配置，还是未来由于过度许可而导致的大规模安全事故。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

五角大楼更新:构建基于 Kubernetes 的基础设施的框架

原文：https://www.fairwinds.com/blog/pentagon-a-framework-for-building-kubernetes-based-infrastructure

Pentagon 是一款开源工具，可以显著减少创建基础设施所需的手动步骤。它节省了时间，减少了错误，极大地提高了标准化和一致性。最棒的是，T2 组织之外的工程师可以使用它。

那么五边形到底是什么？

简而言之， Pentagon 是 ReactiveOps 的开源框架，用于以 Kubernetes 代码的形式构建可重复的基于云的基础设施。五角大楼在自己的 AWS 账户中以自以为是的方式创建香草 Kubernetes 基础设施，为 Terraform、Ansible 和 kops (在 AWS 中管理基础设施和创建 Kubernetes 集群的 ops 工具)生成配置文件。这些配置文件允许您创建一个 Kubernetes 集群，包括一个新的 VPC 和一个 VPN。

为什么我们在顺风处使用五边形

我们创建了五角大楼，因为我们想要一种快速建立统一基础设施的方法。当我们管理客户的基础设施时，他们所有的代码都是一样的，工具也是一样的。因此，出现意外、陷阱和偏离最佳实践的情况会更少。

我们以 AWS 为例。在几个月内从 AWS 进入生产准备状态几乎是不可能的，尤其是当你从零开始的时候。如果你想自己建立一个像五角大楼那样的基础框架，需要几个月的时间。有了五角大楼，你可以加快整个过程。

五角大楼如何运作

简而言之，五角大楼生成配置文件。如果你想为你的基础设施定制五边形，你所需要做的就是改变配置文件或者添加新的配置文件到你的 Terraform 或者 Ansible。你可以把五边形工具创建的目录变成你想要的样子。

健壮的默认特性集

使用五边形，您会得到一个具有以下默认特征的集群网络:

隔离多个开发/非生产环境
基于 VPN 的访问控制
跨多个可用性区域构建的高可用性配置

Pentagon 的最新版本包含了组件的概念，并且 Pentagon 本身现在可以用定义的组件类进行扩展。这意味着你可以将任意代码带入五角大楼框架，生成你希望你的组件生成的任何一组文件 Fairwinds 。

【Fairwinds 为何开源五角大楼

Fairwinds 是服务公司，不是产品公司。我们的核心竞争力是我们管理基础设施的能力，以及我们对云基础设施和 Kubernetes 基础设施的集体知识。我们已经在代码中定义了我们的最佳实践，并开源了我们的工具，我们的客户可以根据存储库中的代码看到这些最佳实践。

使用标准最佳实践意味着我们不必为每个新客户重新设计车轮。五角大楼使我们能够重复这一过程，以大大减少我们的管理工作。它还允许我们专注于更高价值的任务，而不是自动化的任务。

为什么你应该使用五边形

为什么用它

对于具有一定水平的运营知识，但不想自己编写 Terraform VPC 模块或自己解决 VPN 问题的人来说，这是一个很好的起点。五边形包括电池。

当这些工具按照我们给你的步骤以特定的顺序运行时，结果就是 AWS 中的 VPC 和 VPN 以及 Kubernetes 集群。虽然 Pentagon 的设计是可定制的，但它包括适合大多数软件基础设施需求的默认设置。

为什么过去五角大楼很难用

当我们最初开源它的时候，五角大楼的文档是分散的，难以理解。它不是为开源用户量身定制的；相反，它是为 Fairwinds 的领域知识专家量身定制的，这些专家接受了内部培训，并且可以访问非开源的极其详细的文档。这为我们组织之外的工程师带来了巨大的学习曲线。

为什么五角大楼今天更用户友好

我们的目标是让那些在顺风之外、没有领域知识的人更容易开始使用五角大楼来创建伟大的基础设施。我们一直在努力让 Pentagon 对开源社区更加友好，现在 Pentagon 已经有了很好的文档记录。如今，对闭源文档的引用已经不复存在，我们已经定义并最小化了创建 Kubernetes 集群所需的步骤。

鉴于第一代五边形涉及高度手动的过程，现在你可以从最初的五边形开始-项目命令来配置五边形结构范围内的一切。从创建 Kubernetes 集群开始，整个过程都是自动化的。只需两个命令，您就可以到达运行 VPN 的 VPC。从那里，您可以编写一个 Python 模块来扩展 Pentagon 程序的功能。

用于启动和运行集群的命令

附加细节

需要注意的一点是，Pentagon 是一个生成目录的 Python 程序。五角大楼本身不是目录；相反，它是一个已定义目录结构的生成器。很像 Ruby on Rails 是一个生成器。该目录定义了 Ansible、Terraform 和 kops 的一组基本配置。

还需要注意的是，Pentagon 不会自动创建 Kubernetes 集群。虽然创建 Kubernetes 集群所需的准备过程只需要两个命令，但是创建 Kubernetes 集群的过程本身要详细得多(并且需要大量的文档和 DevOps 和 Kubernetes 专业知识 )。

创建五边形项目的具体命令

---
> pentagon start-project <project-name> --aws-access-key <aws-access-key> 
--aws-secret-key <aws-secret-key> --aws-default-region <aws-default-region>
> cd <project-name>-infrastructure
> make all

GitHub

反应行动/五角大楼

你可以在这里了解更多五边形 入门知识。

五角大楼的未来

我们很高兴在 AWS 中发布了 kops/Kubernetes 集群的模板化和自动化创建。 Fairwinds 也在致力于改善谷歌云平台上的谷歌容器引擎(GKE)支持。此外，我们正在开发一个流程，通过该流程，我们可以在一个五角大楼的存储库中使用多个项目和多个帐户。我们的目标是扩展我们在 kops 集群中可以做的事情，并自动启用 Kubernetes 中的关键功能。

五角大楼旨在让我们的团队快速构建许多复杂的基础设施，并安全、经济、一致地维护它们。它使我们能够从现有的代码基础开始。它允许复杂的定制，我们可以根据需要定制。 同样重要的是，你也可以。

有了 Pentagon，我们的团队简化了集群的创建——如果您选择利用 Pentagon 提供的所有功能，您会发现您可以为您的团队节省大量时间，并减少挫折。

北极星，开源配置验证，现在在 ValidKube

原文：https://www.fairwinds.com/blog/polaris-open-source-configuration-validation-now-in-validkube

Fairwinds 的开源项目北极星，帮助用户配置工作负载，确保遵循 Kubernetes 的最佳实践。为开源和 Kubernetes 社区做贡献是 Fairwinds 的核心价值观。这是我们感到兴奋的原因之一，我们在 Komodor 的朋友现在已经将北极星整合到 ValidKube 中。

ValidKube 结合了最好的开源工具，有助于确保 Kubernetes YAML 的最佳实践、卫生和安全。用户可以验证 Kubernetes 配置文件，清除清单中的混乱，扫描漏洞，现在使用 Polaris，检查 YAML 中的最佳实践和潜在安全问题。

Polaris 运行一系列检查来审计 YAML 清单并识别配置问题，如果您使用它来审计 ValidKube 中的 YAML，就会发生这种情况。

Screenshot of ValidKube

在 ValidKube 之外，Polaris 可以作为仪表板、准入控制器或命令行工具运行。准入控制器可以设置为拒绝未通过特定标准的工作负载。

如果你有兴趣了解更多，你可以注册加入 Fairwinds 的开源用户组。下一次会议是在本周三，2022 年 3 月 30 日。注册接收邀请。

北极星对库贝林特

原文：https://www.fairwinds.com/blog/polaris-vs-kubelinter

识别 Kubernetes 的错误配置可以帮助您确保您的集群是安全、高效和可靠的。Fairwinds 的【Polaris】是我们团队创建的开源工具，用于帮助我们管理客户的数百个生产工作负载。它运行各种检查，以确保 Kubernetes pods 和控制器使用 Kubernetes 最佳实践进行配置，从而帮助避免工作负载配置问题。

您可以在每个集群中安装 Polaris 来识别错误配置。如果您需要多集群可见性，我们有一条升级到 Fairwinds Insights 的路径，其中不仅包含北极星，还包含其他开源工具，包括:

冥王星 (识别弃用的 K8S 资源)
Nova (查找过时或弃用的舵图)
Trivy (针对容器的漏洞扫描器)
(建议资源请求和限制)

这不仅允许您跨多个集群、团队和环境管理 Kubernetes 的错误配置，还可以识别问题、提醒团队(通过仪表板或 Slack 集成)并建议补救措施。

KubeLinter 是 2020 年末推出的新开源工具。KubeLinter 分析 Kubernetes YAML 文件和舵图，并对照各种最佳实践进行检查，重点是生产就绪性和安全性。

如果你正在比较北极星和库伯林特，这里有一个快速的检查纲要。(截至 2011 年 2 月 23 日的对比)

| 北极星 | 库贝林特 | 描述 |
| 安全 | | |
| 是 | 不 | security context . allowprivilegescalation |
| 是 | 不 | 缺少 TLS 设置 |
| 是 | 不 | 主机端口属性已配置 |
| 是 | 不 | PID 属性已配置 |
| 是 | 不 | 主机网络已配置 |
| 是 | 不 | 主机 IPC 已配置 |
| 是 | 不 | 【危险能力(此处阅读列表) |
| 是 | 不 | 不安全的功能包括 |
| 是 | 是 | 不删除 NET_RAW 功能的容器 |
| 是 | 是 | 以特权身份运行的容器 |
| 是 | 是 | 未运行 readOnlyRootFilesystem 的容器 |
| 是 | 是 | 容器设置为 runAsNonRoot |
| 不 | 是 | 对象使用环境变量中的机密 |
| 不 | 是 | 没有“电子邮件”注释但有有效电子邮件的对象 |
| 不 | 是 | 缺少“所有者”标签 |
| 不 | 是 | 将主机路径装载为可写的容器 |
| 不 | 是 | 公开端口 22 的部署，通常保留用于 SSH 访问 |
| 不 | 是 | Pods 使用默认服务帐户 |
| 效率 | 是 | 是 |
| 缺少内存请求和限制 | 是 | 是 |
| 缺少 CPU 请求和限制 | 可靠性 | 是 |
| 不 | 图像标签未指定或最新 | 是 |
| 不 | 映像获取策略未设置为“始终” | 是 |
| 不 | 没有为 pod 设置 PriorityClassName | 是 |
| 不 | 只有一个副本集用于部署 | 是 |
| 是 | 缺少活性探测 | 是 |
| 是 | 缺少就绪探测 | 没有；冥王星手柄 |
| 是 | 在扩展 v1beta 下使用不推荐使用的 API 版本的对象 | 不 |
| 是 | 未指定单元间反关联性的多个副本，以确保 orchestrator 尝试在不同的 | 不 |
| 是 | 引用未找到的服务帐户的窗格 | 不 |
| 是 | 选择器与 pod 模板标签不匹配 | 不 |
| 是 | 没有匹配部署的服务 | 不 |
| 是 | 部署使用不推荐使用的 serviceAccount 字段 |

|
| No | Yes | Deployments use deprecated serviceAccount field |

糟糕的 Kubernetes 配置会以令人惊讶的方式影响集群的安全性

原文：https://www.fairwinds.com/blog/poor-kubernetes-configuration-can-impact-the-security-of-your-clusters-in-surprising-ways

在 Kubernetes 的世界里，错误的配置经常发生。这是一个大问题，因为不正确的配置会影响容器安全性、效率和可靠性等重要因素。这三个高级构造与成功的 Kubernetes 部署有着千丝万缕的联系——值得注意的是，它们也是受错误配置影响的三个主要方面。当围绕安全性、效率和可靠性的问题没有有意识地用最佳实践来解决时，Kubernetes 所有权的关键要素，如成本效率、用户体验和整体性能，都会受到严重影响。

好消息是，所有这三个重要领域都可以通过关注正确的配置来不断改进和管理。这是运行快乐和安全的 Kubernetes 集群的关键。

阅读我们最新的白皮书: 好的，坏的&配置不当的

消除 Kubernetes 的错误配置，以降低风险并提高可靠性和云效率。

配置情况

事实上，大多数组织还没有想出如何维护有效的 Kubernetes 配置。我们最近的 Kubernetes 基准测试报告中的数字告诉我们，只有 35%的企业使用活跃度和就绪性探测等最佳实践成功配置了工作负载。这些运行状况探测器是可靠工作负载的关键需求。没有它们，Kubernetes 就无法有效地自我修复或执行零停机部署。在没有这些探测器的情况下工作会产生各种各样的可靠性问题——这都是不良配置实践的结果。

Kubernetes 的核心特性之一是能够根据需求自动增加或减少资源。然而，在没有提示一个应用程序将使用多少 CPU 和内存的情况下，Kubernetes 被迫对如何扩展应用程序做出无知的猜测。设置计算资源的请求和限制在技术上是可选的(Kubernetes 会很乐意接受没有这些设置的工作负载)，但忽视它们会导致可靠性问题或令人痛苦的超支。

此外，如果不能快速有效地解决，即使是很小的配置错误也会造成很大的安全漏洞。例如，以超出需要的安全特权运行的容器，如根级访问，已经成为一个常见的漏洞。在某些配置下，容器可能能够访问主机节点，从而允许它们访问甚至修改集群中的其他应用程序。因为这些配置不是默认设置的，所以它们必须由安全团队作为策略来建立。

最糟糕的是，随着时间的推移，配置问题变得越来越棘手，耗费大量时间并增加安全风险。起初，看似一些小问题很快变成了 Kubernetes 的全面混乱，表现为安全漏洞、可靠性问题和资金浪费。

寻找解决方案

配置验证，也称为基础架构代码(IaC)扫描，可以由运行一个或两个 Kubernetes 集群的小团队通过手动代码审查来完成。但是当组织变大时，问题就出现了，大量的开发团队被部署到多个集群。平台和安全领导者以及 DevOps 团队可能会很快失去对 Kubernetes 集群中发生的事情的可见性和控制。这一现实表明，需要自动化和策略来加强一致性，并在整个企业中提供适当的防护。

如何最小化错误配置在某种程度上取决于组织的规模。大型企业可能会发现很难手动检查每个安全配置来评估风险，而较小的企业可能不会。由于 Kubernetes 中的默认设置往往是自然开放且不安全的，因此在所有安全问题(以及它们如何影响整体风险承受能力)都很容易理解之前，避免使用这些默认设置非常重要。

在针对 Kubernetes 软件的各种客观的、共识驱动的安全指南(如 CIS 基准)中，可以找到用于强化环境的有用指导和有用框架。当这些最佳实践与集成到 CI/CD 管道中的基于风险的策略相结合时，容器安全性会大大提高。提交或者不满足最低安全需求的构建可以被停止。

依靠洞察力

在运行时保护 Kubernetes 集群和工作负载，以确保安全性、效率和可靠性，需要使用深度防御的多管齐下的方法。该解决方案的一部分来自于找到一个 SaaS 治理服务所有权平台，如fair winds Insights，能够建立有效的护栏治理，简化开发和运营，并提供更好(和更安全)的用户体验。

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

由于错误配置经常发生，只有遵循行业最佳实践，才能构建稳定、可靠和安全的集群。这种级别的治理只能通过值得信赖的合作伙伴来实现，他们精通统一团队、简化复杂性的流程，并利用 Kubernetes 的专业知识来节省时间、降低风险和自信地进行配置。

工程领导者在不确定时期在家工作的实用技巧

原文：https://www.fairwinds.com/blog/practical-tips-from-engineering-leaders-for-working-from-home-during-uncertain-times

随着新冠肺炎在全球的扩展，许多组织已经要求非关键员工在家工作，我们中的许多人正在适应新的经营方式，在这里我们也过着自己的生活。

作为远程优先的工作场所，Fairwinds 在帮助员工成功在家工作方面拥有丰富的经验。我们最近举办了一场名为“您的工程团队的远程提示&之旅的小组讨论，这对任何在家工作的人都有很大的启发。

转向在家工作

这是不确定的时代。我们都有很多悬而未决的问题，再加上建立一个新的工作环境，即使是最镇定的队友也会不知所措。小组主持人、Fairwinds 公司总裁肯德尔·米勒(Kendall Miller)说:“认识到这种情况对那些可能已经安装了在家工作的系统的人造成的情绪影响是很重要的。

现在，由于许多学校停课，我们中的许多人在工作时间里忙于照顾孩子。此外，对于我们这些有居家伴侣的人来说，我们正在弄清楚谁在什么时候工作，试图安排彼此的通话，并努力耐心地每周 7 天、每天 24 小时见面。

雇主和雇员都需要考虑舒适度。坐在或站在一个新的工作站(包括厨房桌子)上可能会有影响。注意你的身体在告诉你什么，如果你需要人体工程学的支持，和你的经理谈谈。而且，听起来很简单，为你一天的家庭工作设定常规和模式是很重要的。Zapier 的工程总监 Kristina Kemmer 指出:“我确保每天都洗澡，并穿好衣服去上班，因为我需要感受家庭生活和工作生活的分离。我尽量不去看下班后的空闲时间，我认为减少工作时间真的很好。”

创造——或融入——一种遥远的文化

你可能无法为远程员工提供免费午餐或按摩，但你可以帮助他们专注于创造一种适合办公室以外团队的文化。

“已经远程工作了一段时间的人们已经建立了沟通模式——他们用来表达他们正在工作的短语，代表某些事情的表情符号，等等。如果你还没有远程团队/劳动力，坐下来想想存在什么，以及如何让新成员进入这些模式，”Fairwinds 的工程副总裁萨拉·泽列科斯基说。无论这些模式是人们可以随时加入的站立缩放房间，还是帮助人们感到联系的“水冷却器”视频聊天，不要忘记关注文化。

过度沟通

当我们在办公室里时，很容易忽视我们之间的交流，即使是在不知不觉中。当我们分散时，我们必须确保记住分享可能重要的微小细节。

GitLab 联盟副总裁布兰登·荣格(Brandon Jung)说:“如果你领导人们，最重要的是要记住过度沟通。不要忘记事情被写下来有多重要。伸出手去与人接触，尤其是在这些变化的情况下。”

Zelchoski 附和了这一观点，指出对所有员工来说，“沟通、开放和地位必须完全不同。你必须更加透明。否则，你会躲在自己的角落里做事；你会感到孤立，人们不会把你融入交流的道路。”

完成工作–实用要点

远程团队必须考虑独特的因素，例如不同时区的团队。“我曾经同时与来自 APAC、北美和欧洲时区的人共事过，在这三个时区同时安排会议几乎是不可能的。Stripe 的工程经理 Kate Taggard 说:“有人会在午夜醒来。她的解决方案？限制经理从三个时区中的两个选择团队成员，以使计划和合作更容易。

为此，向远程工作人员过渡意味着是时候让协作和通信工具为您服务了。他们不仅帮助你完成你的工作，而且确保你的团队互相沟通，协同工作。Cloud Foundry Foundation 社区高级总监 Swarna Podila 分享道:“有一种结对文化，来自不同地区和时区的工程师结对在一起。他们使用 Zoom calls 和其他有用的工具，比如白板。我本人不写白板——我有很棒的纸，我在上面画画，它会同步到我的 Google Drive，它已经在一个共享文件夹中了。”

小组成员都有工程背景，他们还建议创建记录和交流的流程，以便所有团队成员都知道他们是什么。在此基础上，小组提出了他们最喜欢的工具，包括:

Krisp.ai ，在通话过程中屏蔽背景噪音
Retrium ，允许远程团队轻松进行追溯
用于 DevOps 的 GitLab

我们作为远程团队工作的时间可能会比最初预期的要长。现在努力帮助团队取得成功是值得的——无论是对人还是对底线。查看整个面板，“为您的工程团队提供远程提示&行程”此外，请务必将您喜爱的远程作业工具添加到我们的列表中。

利用 Fairwinds 和 Datadog 防范风险并监控 Kubernetes

原文：https://www.fairwinds.com/blog/prevent-risk-monitor-kubernetes-fairwinds-datadog

获得云应用的可见性可能是一项挑战。有如此多的数据点分布在与服务器、容器、数据库和其他第三方服务相关的环境中。所有这些数据都需要监控。那么，你如何让你的技术栈变得引人注目呢？在 Fairwinds，我们建议我们所有的 Kubernetes 托管服务客户使用 Datadog 来监控应用和基础架构，以使您的堆栈完全可见，从而帮助 DevOps 团队避免停机、解决性能问题并改善用户体验。当您了解实际发生的情况时，就有可能对任何问题做出快速反应并解决它们，从而提高可靠性。

这就是为什么我们努力加深与 Datadog 的关系，使fair winds Insights—Kubernetes 合规、安全和政策软件——在 Datadog 市场上销售。通过这样做，Fairwinds 防止问题进入集群，而 Datadog 在运行时识别问题。

Datadog 是做什么的？

Datadog 无缝聚合整个 DevOps 堆栈中的指标和事件，因此您可以在一个地方看到您需要的所有信息。通过深入了解系统、应用和服务中发生的情况，您的 DevOps 团队能够根据实时信息快速采取行动。Datadog 通过 450 多个内置集成提供这种可观察性。

所有这些集成使您的团队能够全面了解现代应用程序，Datadog 用户使用这些应用程序来提高性能、发现问题和分析日志。如果测量的内容得到管理是真的(我认为是真的),那么很明显，Datadog 可以帮助您监控、排除故障、优化以及管理应用程序的性能。

Fairwinds Insights 增加了主动观察能力

虽然 Datadog 已经提供了对 Kubernetes 环境的运行状况和性能的可见性，但当您将 Fairwinds Insights 集成添加到您的 Datadog 部署中时，它会增加对您的 Kubernetes 集群的关注，并帮助您在问题变成警报之前在您的 Datadog 仪表板中发现它们。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

Insights 集成到 CI/CD 管道中，在安全性、效率和可靠性错误配置进入您的生产环境之前发现它们。Insights 还可以应用 Kubernetes 最佳实践策略和实施合规性策略，帮助您构建和维护一个更加安全、高效和可靠的 Kubernetes 部署，甚至在您将应用程序转移到现场并开始使用 Datadog 进行监控之前。

为什么选择 Datadog 和 Fairwinds Insights

Datadog 帮助您监控正在发生的事情，提供对现代应用程序的全面了解，并帮助您分析上下文中的日志数据和监控用户体验(等等)。Datadog 为系统问题的反应提供了强大的实时监控和可观察性，因此您可以知道什么时候出现了问题。从本质上讲，它就像一个火警，提醒你现在出了什么问题，并帮助你快速解决问题，让你的客户满意。

将 Fairwinds Insights 添加到组合中有助于您发现哪些配置存在风险或浪费资源。通过将洞察力集成到 Datadog 中，您可以在预生产阶段发现并防止安全和合规性风险，并识别可能会破坏您的构建的错误配置。因此，Insights integration 的作用更像一个家庭检查员——它不能防止火警响起，但它可以通过在流程的早期解决问题来降低发生火警的可能性。

添加 Insights 集成以获得:

针对 Kubernetes 环境和云应用的端到端持续监控
更可靠、更高效的应用
您已经生活在其中的单一控制台(Datadog 仪表板)包括 Fairwinds Insights 警报、警告和成本分析

资源

RBAC-Lookup:Kubernetes 授权的反向查找

原文：https://www.fairwinds.com/blog/rbac-lookup-reverse-lookup-for-kubernetes-authorization

如果您曾经使用过 Kubernetes authorization，那么您可能想知道一个非常简单的问题的答案。"这个用户对这个群集有多少访问权限？"不幸的是，这个问题总是很难回答。所有相关的 Kubernetes APIs 都允许您列出角色绑定和集群角色绑定，但是从来没有像什么角色绑定到用户这样简单的事情。

考虑到这一点，我们构建了一个简单的 Go CLI， rbac-lookup ，来帮助回答这个问题。要开始，您可以直接从 GitHub 下载最新版本，或者用 Homebrew 安装它:

brew install reactiveops/tap/rbac-lookup

在那里，您可以使用 rbac-lookup 来轻松查看谁可以访问哪些角色。这里有一个简单的例子:

rbac-lookup rob

SUBJECT                   SCOPE             ROLE
rob@example.com           cluster-wide      ClusterRole/view
rob@example.com           nginx-ingress     ClusterRole/edit

这表明“rob@example.com”除了在 nginx-ingress 名称空间中具有编辑权限之外，还具有集群范围的查看权限。为了获得这个结果，rbac-lookup 遍历集群中的所有 RoleBindings 和 ClusterRoleBindings，并返回主题(用户、服务帐户或组)名称与查询匹配的任何结果。

作为一个更完整的示例，您可以使用“wide”输出标志运行更广泛的查询:

rbac-lookup ro -owide

SUBJECT                   SCOPE             ROLE                SOURCE
User/rob@example.com      cluster-wide      ClusterRole/view    ClusterRoleBinding/rob-cluster-view
User/rob@example.com      nginx-ingress     ClusterRole/edit    RoleBinding/rob-edit
User/ross@example.com     cluster-wide      ClusterRole/admin   ClusterRoleBinding/ross-admin
User/ron@example.com      web               ClusterRole/edit    RoleBinding/ron-edit
ServiceAccount/rops       infra             ClusterRole/admin   RoleBinding/rops-admin

在这种情况下，我们看到有许多用户甚至一个服务帐户与“ro”查询相匹配。这个广泛的输出为我们提供了额外的信息，比如主题的类型和授予访问权限的特定源(RoleBinding 或 ClusterRoleBinding)。

希望这个工具对你和我们一样有用。你可以在 GitHub 上找到这个项目。如果你有任何问题，请直接在 Twitter 或 Kubernetes Slack (@robertjscott)上联系我。

如果你已经走了这么远，你可能真的很喜欢库伯内特和 RBAC。如果是这样，你可能想看看我们的相关项目， rbac-manager ，一个旨在简化 rbac 管理的操作器。

重新平台化很吓人。值得吗？

原文：https://www.fairwinds.com/blog/re-platforming-is-scary.-is-it-worth-it

重新平台化很可怕。值得吗？

如果你是一个技术领导者，除非有很高的投资回报率，否则你不会想重新搭建平台。我们看到人们搬到 Kubernetes 的两个主要原因是:

他们使用平台即服务，而平台即服务已经变得过于昂贵。
他们需要 Kubernetes 提供的灵活性和精细控制。

如果您的成本较低，并且您对粒度控制的需求较低，请保持现状。如果您的基础架构完全符合您的需求，那么就没有理由为了移动而移动。

但是，如果您现在想要重新构建平台，因为您预计会出现大规模增长，您希望您的支出非常接近您的使用量，或者您知道您有技术需求需要在粒度级别上解决，那么 Kubernetes 就是您的平台。

cartoon. First box keep using whats working. Second box move to a new platform. Third box person sweating.

采用 Kubernetes 是对未来的保障。

随着 Kubernetes 应用的增加，支持它的工具也会增加。未来 5-10 年内，云的一切都将建立在 Kubernetes 之上，无论这对于用户来说是否模糊不清。

Kubernetes 是未来。你可以上船而不必害怕。如果您需要帮助和进一步的安心——fair winds 拥有专业知识、软件和支持来帮助您安心地进入 Kubernetes 生产。

Fairwinds 现在提供面对面的 Kubernetes 培训和咨询

原文：https://www.fairwinds.com/blog/reactiveops-now-offering-in-person-kubernetes-trainings-and-advisory

当三年半前 Fairwinds 成立时，我们是一个由工程师和销售人员组成的小团队，试图雇佣那些大公司因为地理位置而不愿意雇佣的人才。我们从一开始就宣传我们不仅仅是一家远程友好型公司，我们只是远程公司。作为其中的一部分，我们几乎从未要求我们的工程师出差。

迄今为止，我们的大部分工作都是完全远程交付的，多亏了 Slack 和 Zoom 等工具，这不仅仅是可行的，我们还能够为我们能够远程提供的服务水平感到自豪。然而，总有一个地方让人们亲自出现并帮助解决具体问题，我们的员工越来越对有机会亲自来与您的团队坐在一起感到兴奋。

有一件事看起来更适合亲自参加，那就是培训。

一年多来，我们一直与谷歌合作，在旧金山、纽约、奥斯汀、丹佛、西雅图等地免费提供 Kuberentes 101 培训课程。在接下来的几个月里，我们将在波士顿、芝加哥、洛杉矶扩展和提供这些服务，并在纽约和旧金山推出更多服务。我们甚至与 AWS 合作，并在上周提供了我们的第一次 EKS 培训。

大多数公司建立一个 Kubernetes 集群(或一组集群)一次——或者可能几次——然后努力让它们保持运行。我们一直在为新客户建立集群，我们维护的基于 Kuberentes 的基础设施比其他任何人都多。因此，我们的工程师在构建和维护基于 Kubernetes 的基础设施方面拥有丰富的知识。

我们已经对它进行了几个月的测试，但我很高兴地告诉大家，我们现在为工程师提供了一些服务，让他们飞过来亲自与您的团队坐在一起，用白板演示新的想法，处理复杂和独特的问题，并通过我们的开源工具和其他工具提供帮助，我们称之为“内部顾问”我们还提供培训，在您开始涉足 Kubernetes 世界或开始使用 Istio 等产品时，我们可以到现场培训您的员工。我们可以为您构建和维护整个基础架构，但无论我们是否这样做，为您的员工了解幕后发生的事情打下良好的基础总是很有帮助的。

因此，无论您是第一次使用 Kubernetes，还是在 101 中需要帮助，您已经使用它多年，并且正在遇到复杂的问题，或者您已经决定现在是时候在 Istio 上全押，我们都可以为您和您的团队量身定制培训或面对面咨询。

通往云原生的道路有很多，我们为几乎所有希望到达那里的人提供服务，其中一个恰好包括通过物理云坐在飞机上的人，他与你坐在同一房间，并帮助你找到你的路。

反应行动像顺风一样重新启动

原文：https://www.fairwinds.com/blog/reactiveops-relaunches-as-fairwinds

本文由 Brian Dowling 撰写，原载于 x economy。

从很多角度来看，这个商业机会看起来很难错过。待售的技术业务是:第一，自筹资金，不受堆积如山的外部股权的拖累；二、盈利且不断增长；第三，在混乱但蓬勃发展的企业软件基础设施世界中。

对于接管这家重新崛起的公司的三位波士顿科技高管——前 Veracode 董事长兼首席执行官鲍勃·布伦南(Bob Brennan)、前黑鸭软件首席技术官比尔·莱丁汉姆(Bill Ledingham)和意志资本(Volition Capital)创始合伙人罗布·凯特森(Rob Ketterson)——来说，有足够的“机会”来策划一项天使投资者资助的交易，以收购该公司，并看看它会变成什么样。

截至今天，这家公司的前身是 ReactiveOps，名为 Fairwinds。它带着数百万的流动资金起飞了，莱丁汉姆是首席执行官，布伦南是主席，凯特森也是董事会成员。前 IBM 高管 Jun Ho Son 是 Fairwinds 的首席财务官，前 Veracode 产品总监 Joe Pelletier 是该公司的战略主管，前 Veracode 销售总监 Brian Levin 负责销售。

莱丁厄姆没有透露收购 ReactiveOps 花费了多少资金，但他说，天使投资者现在正投入数百万美元作为营运资金。

Fairwinds 在技术领域的邮政编码将其放在云计算基础设施中。更具体地说，该公司与“容器”合作，这是一种计算技术，通过创建一种迷你虚拟计算机来帮助公司更有效地使用云服务，这种计算机可以在需要时出现，只占用手头任务所需的资源，然后在工作完成后消失。虽然目前只有不到 30%的全球组织以这种方式运行他们的云计算，但据估计到 2022 年，75%的组织将使用容器。

Fairwinds 背后的商业计划专注于帮助公司采用容器技术——这是一项繁重的任务，莱丁汉姆在黑鸭软件公司工作时就很清楚。

莱丁汉姆说，他领导该公司通过 Kubernetes 平台采用容器，这是目前使用的主要平台，也是 Fairwinds 关注的重点。

“我们很快发现，围绕如何操作该技术以确保其可靠、安全、配置合理和资源高效的问题，需要做出许多技术决策，”莱丁汉姆告诉 Xconomy。“在决定(如何)让它在生产环境中启动和运行方面，有许多细节需要考虑。”

莱丁汉姆说，黑鸭公司总共花了 9 到 12 个月的时间和一个工程团队让它开始运行。Fairwinds 公司承诺在几周内开始运营集装箱业务。

鉴于 Fairwinds 的业务完全局限在由亚马逊(纳斯达克: AMZN )、谷歌(纳斯达克: GOOGL )、IBM(纽约证券交易所: IBM )和微软(纳斯达克: MSFT )等大型科技主导的云计算世界中，这些公司决定承担莱丁汉姆和他的同胞们已经确定的痛点存在一些风险

莱丁厄姆承认存在风险，但表示，对于这些科技巨头来说，在探索如何部署容器时，很难建立某种东西来解决每个企业面临的所有具体而复杂的采用问题。

“我确实看到云提供商继续进入这个领域，随着时间的推移，这变得更加容易，”他说。“话虽如此，平台层仍需要大量特定于应用的配置。他们无法提供这些服务。”

莱丁汉姆说，该公司的目标是为企业提供一种服务，有效地管理他们向 Kubernetes 平台的过渡。

他说，目前还不清楚该公司是否需要额外的外部资本，或者它是否能以目前的利润继续保持增长。莱丁汉姆说，到目前为止，Fairwinds 仅利润一项就能每年增长 50%。

Fairwinds 现在有 50 名员工，大部分都是远程操作的。该公司的总部设在波士顿 Fort Point 附近的一家工厂里。

布莱恩·道林是波士顿 Xconomy 的高级编辑。你可以在 bdowling@xconomy.com 的联系到他，或者在推特的上关注他

在保护您的 Kubernetes 工作负载时，请记住这些关键实践

原文：https://www.fairwinds.com/blog/remember-these-key-practices-when-securing-your-kubernetes-workloads

为了真正理解和评估 Kubernetes 集群中的潜在风险，您需要一套强大的保护敏感工作负载的最佳实践。除了简单地遵循可行的建议之外，企业还必须找到访问控制可变性、安全监控和审计考虑事项等内容的方法。事实是，Kubernetes 的成功之路没有对错之分。没错，无效和潜在危险的路径是存在的，但也有一些好的路径。你决定走的路应该是能够解决你的业务需求和优先级的路。

问自己几个问题:

我是否身处金融或医疗保健等安全性不容置疑的行业？
我是否有一个繁忙的团队或机器学习工作负载，需要以最高的资源效率运行？
我的应用和服务能承受任何停机时间吗？还是 99.99%或更高的可靠性才是最重要的因素？

一旦你有了答案，可能还有更多答案，你就有了决定实施 Kubernetes 的最佳方式所需要的信息，创建一个过程并阐明任务和优先级。因此，您将能够更好地探索可供选择的目录和最佳实践。

安全第一

今天，组织仍然面临三大最常见(也是最危险)的威胁:

拒绝服务(DoS)攻击意味着停机、延迟和可能过高的计算成本。
外部威胁可以利用应用程序代码来访问内部资源。
内部威胁意味着组织中的个人可以访问其工作范围之外的资源和数据。

尽管云原生技术和 Kubernetes 的世界仍然相对较新，但基本的核心业务挑战依然如故。组织必须找出如何加快开发速度，同时保持健壮的安全实践。这两个业务目标仍然在容器领域争夺同等的关注。

阅读: Kubernetes 最佳实践:综合白皮书

最佳实践

显然，保护集群的最佳方式是将人们(及其危险行为)完全排除在库伯内特集群之外。但是考虑到工程师需要与集群本身进行交互——客户需要与集群运行的应用程序进行交互——优化 Kubernetes 的安全性并不容易。

Kubernetes 不会保护您的应用程序代码。它也不能阻止你的开发人员引入导致安全问题的错误和缺陷。Kubernetes 能做的是限制攻击的爆炸半径。这意味着适当的安全控制可以限制不良行为者一旦进入您的集群后能走多远。如果您有正确的安全策略，这个攻击者将被卡住，无法访问容器、应用程序或更大的集群。但是如果容器以根用户身份运行，可以访问主机的文件系统，或者有其他安全缺陷，那么集群就很好……你知道。这就是为什么一个配置良好的 Kubernetes 部署提供了一个额外的急需的安全层。

让我们来看看目前针对 Kubernetes 用户的最佳安全实践:

DoS 保护:设置限制！

搞垮一个网站最简单的方法就是用 DoS 攻击让它超载。有时这是有意的，有时不是——很难从内心分辨。Kubernetes 的一个主要优点是，它允许应用程序根据这些流量波动进行伸缩。这意味着一个设计良好的入口策略，一个被配置为设置用户可以消耗多少流量的限制的策略，增加了一个额外的安全层来减轻这些风险。

更新和补丁:保持最新并定期测试！

保持你的 Kubernetes 版本最新是至关重要的，因为旧版本可能会变得陈旧并充满安全漏洞。安装在集群中的附加组件可以增强功能，但也会增加攻击面。及时更新错误修复和新版本是关键。每当一个新的版本发布时，都需要在内部集群和临时集群上进行测试。缓慢地推出更新，同时监控可能的问题，并在此过程中进行修正。并且不要忘记为你所有的应用程序保持底层 Docker 镜像的最新。基本映像也会过时，需要定期更新。

RBAC:设置好！

提供管理权限是一件大事，因为它允许个人或应用程序做基本上任何事情，包括删除整个 Kubernetes 部署。不需要控制集群的应用程序不需要管理员权限。Kubernetes 提供 RBAC 来管理对不同集群资源的访问。通过仔细管理您的权限并依靠最小特权原则来降低潜在的风险。

网络策略:编写和管理有效的策略！

网络策略不像 RBAC 那样管理对集群资源的访问，而是关注集群内部的通信。虽然给定的工作负载可能需要与一个数据库和一些微服务对话，但工作负载本身不需要访问集群中的所有其他应用程序。确保编写严格的网络策略，将通信限制在群集的不必要部分，并管理群集的入口和出口。有了这些规则，潜在风险就大大降低了。

工作负载身份:用一把钥匙管理访问！

您可以通过工作负载识别将 RBAC 与云提供商的认证机制联系起来。Kubernetes 中内置的身份验证机制，用于管理对集群外资源(如数据库)的访问，符合要求。工作负载身份是安全性的关键，因为它使用短期凭证在幕后处理所有许可。无需管理和暴露访问密钥。

秘诀:依靠加密！

Kubernetes 通过以 YAML、Terraform 和其他配置格式对所有基础设施选择进行编码来增强 IaC 工作流。这可以确保您的基础架构 100%可复制，即使一个集群在一夜之间消失。请记住，应用程序需要访问机密，如凭证、API 密钥、管理员密码和其他一些敏感信息才能正常工作。不要试图将这些凭证签入 IaC 存储库，因为这会将它们暴露给任何能够访问 Git 存储库的人。相反，加密您的秘密，并将其安全地签入您的存储库，这样您就可以使用一把钥匙来解锁您的 IaC 呼吸系统，并拥有一个完全可复制的基础架构。

外卖食品

底线是，应用程序在不断变化，这意味着安全性也在不断变化。Kubernetes 让您能够根据最佳实践优化安全设置，从而减轻了攻击的严重性。这意味着你可能犯的最大的安全错误就是没有遵循它们！

fair winds Insights，我们的安全和治理平台，可以提供帮助。它大规模自动化安全，集成左移策略并降低风险以支持创新。免费提供！拿过来。要了解有关这些最佳实践的更多信息，请阅读我们关于该主题的全面白皮书。

为您的工程团队提供远程工作提示和技巧:小组讨论

原文：https://www.fairwinds.com/blog/remote-work-tips-and-tricks-for-your-engineering-team-panel-discussion

发言人:

kate 凯特·塔加特(他们/他们)
工程经理，Stripe 凯特管理过各种团队，从共处一地到部分和完全远程，甚至分布在不同的大洲。Kate 的技术经验涵盖从电网弹性到金融科技到基础设施和监控软件的多个领域。 Brandon Jung(他/他)****
VP Alliances，GitLab |董事会 Linux Foundation

在加入 GitLab 之前，Brandon 创立并构建了谷歌云生态系统，其中包括 Red Hat、Docker、Cloudera、Pivotal 和 Tableau 等各种技术公司，以及拥有深厚云专业知识的公司，如 Cloud Technology Partners、Agosto、CI & T、埃森哲和麦肯锡。在工作之外的时间里，Brandon 可以和他的妻子和三个孩子在科罗拉多州丹佛市享受户外活动的乐趣，并作为 Linux 基金会的董事会成员支持开源软件的发展。他是一个相当邪恶的高尔夫球手，并对全球人道主义努力怀有真正的热情。

Sarah Zelechoski(她/她) fair winds 工程副总裁

Sarah 在开发运营和基础设施方面的独特背景使她能够过渡到 Kubernetes 生态系统。如今，她的团队通过结合开源技术、自动化、最佳实践和专业知识，帮助企业构建和维护可靠、可扩展且安全的 Kubernetes 集群。

Swarna

Swarna Podila (她/她) Cloud Foundry Foundation 社区高级总监

Swarna 在 Cloud Foundry Foundation 领导社区工作，促进协作，倡导友善。她将人置于技术之上，专注于发现和放大云铸造社区中人们不为人知的故事和鲜为人知的创新。

Kristina Kemmer(她/她)
工程总监 Zapier

Kristina 是一名工程领导者，15 年来一直致力于建立和授权团队为客户创造价值。她目前在 Zapier 领导产品工程团队开发消费产品。她与妻子、三个女儿和两条狗住在西阿尔瓦达。

为您的工程团队提供远程工作提示和技巧:预先录制的小组讨论

原文：https://www.fairwinds.com/blog/remote-work-tips-and-tricks-for-your-engineering-team-pre-recorded-panel-discussion

关于安全高效运行 Kubernetes 的五大问题

原文：https://www.fairwinds.com/blog/running-kubernetes-securely-efficiently

由于 Kubernetes 仍然相对较新，组织内通常没有太多的专业知识。这意味着在许多组织中，有许多关于实施、保护和优化 Kubernetes 的问题。最近，我们举办了一场网络研讨会，讨论如何安全高效地运行 K8s，我们在最后回答了一些很棒的问题。通常，我们在网上研讨会中收到的问题也是许多其他人遇到的问题，所以我们在这里分享我们在网上研讨会中遇到的五大问题。

1)在 Kubernetes 中有什么好的工具来估计或测量合理的资源限制吗？

我们实际上有一个开源项目叫做 Goldilocks 来帮助解决这个问题，这个项目可以在 GitHub 上找到。如果您想获得正确的资源建议，Goldilocks 会根据您设置的资源限制和请求来监控您的实际应用程序内存和 CPU 使用情况。然后它会推荐更接近你实际使用的东西。通过在推荐模式下使用 Kubernetes vertical-pod-scaler(VPA ),我们能够在每个应用程序上看到资源请求的建议。Goldilocks 为名称空间中的每个部署创建一个 VPA，然后向它们查询信息。

在 Fairwinds，我们还将 Goldilocks 整合到 Fairwinds Insights 中。我们在 Insights 中的产品也使用 Prometheus 来生成更细粒度的资源使用数据，这对于峰值工作负载特别有帮助。Goldilocks 和其他更简单的解决方案适用于内存和 CPU 使用率非常一致的工作负载，但对于不太容易预测的工作负载，使用 Insights 提供的细粒度数据会很有帮助。

2)有没有一个推荐的发行版可以用于容器映像，这个发行版的已知 CVE 最少？

这是一个非常好的问题。一般的经验法则是菜越小越好。举例来说，我不推荐使用 Ubuntu 作为你的基本图像。阿尔卑斯山通常是我们内部的形象。该映像中的内容足以让您完成最基本的任务。它有一个外壳和一个包管理器，允许你添加包，如 curl 或类似的，如果你需要在你的容器里。

最好的办法，也是我们尽可能做到的，是从头开始构建您的图像。如果你没有任何类型的基础发行版，你需要在容器中添加你可能需要的所有东西。这可能会有点痛苦，因为你需要在很多基础包上加层。好处是当你从头开始构建时，真的没有任何额外的东西，所以它们就像你构建 Docker 映像一样被削减了。图像中的内容越少，您可能遇到的 cv 就越少。

3)演示中提到的一些安全风险是否由服务提供商或托管服务预先处理？

我们在网上研讨会中谈到的安全问题不是由像谷歌 Kubernetes 引擎( GKE )这样的服务提供商处理的。

Where Security and Efficiency Challenges Emerge

我们主要关注前两栏，容器漏洞和部署配置。GKE，亚马逊弹性 Kubernetes 服务(亚马逊 EKS)，以及 Azure Kubernetes 服务 (AKS)在右手栏确实可以帮你解决安全风险。他们负责 Kubernetes API 本身的许多配置，并可以帮助 Kubernetes 的基本配置，以确保您以安全的方式做事。默认情况下，他们内置了许多安全功能，但是在该专栏中，他们不会帮助您解决其他一些问题，包括有风险的基于角色的访问控制(RBAC)配置文件。当你在 GKE 上运行时，你仍然要对 RBAC 负责，你仍然要对附加组件负责，包括 NGINX 入口和证书管理。因此，是的，他们确实涵盖了一些风险，但除了这些提供商提供的现成内容之外，您还需要做很多事情。

Insights 是否适用于无法从公共互联网访问的空气间隙集群？

目前，我们需要某种允许列表来允许集群向 Fairwinds Insights 报告。我们有一个自托管版本，您可以在内部安装。我们可以和你合作，让它在有空气间隙的环境中工作。我们的大多数客户在软件即服务环境中使用 Fairwinds Insights，但是自托管的内部环境可以帮助您满足其中一些要求。

5)您对入口控制器的 TLS 切换和使用服务网格的 MTLS 有何看法？

这里有一个权衡，实际上是在简单性和安全性之间。如果您使用 MTLS 构建一个服务网格，您将获得额外的安全级别和额外的控制级别，以控制哪些应用程序可以相互通信。Kubernetes 的开箱即用配置允许集群中的每个工作负载与其他每个工作负载进行对话，而有一个服务网格可以让您稍微减少这种情况。这也可能让您的开发团队感到头疼，因为它会影响与正确的服务对话的能力。他们必须配置这些东西。

这取决于您组织对安全风险的偏好，以及您组织的成熟度。如果你刚刚开始使用 Kubernetes，并且你是一个小的创业公司，你可能只需要一个“香草”入口就可以了。如果您在企业中使用 Kubernetes，我建议走服务网格路线，特别是如果您有一个多租户集群。当你有许多团队去同一个集群时，他们不需要互相交流，在那里用 MTLS 获得一个服务网将对你有帮助。

安全高效地运行 Kubernetes

随着应用程序开发流程的左移，开发人员需要支持来为组织做出正确的决策，以便安全高效地运行 Kubernetes。如果您缺乏内部专业知识，并且您仍然要跟上 Kubernetes 最佳实践的速度，那么这将是一个挑战。我们这里有网上研讨会的概述，希望观众提出的这些问题能帮助回答你一直想知道的一些问题。如果您还有其他问题，请联系！

运行 Kubernetes 版？可能是时候升级了

原文：https://www.fairwinds.com/blog/running-kubernetes-v1-15-upgrade

最近，亚马逊网络服务(AWS)分享了一篇关于计划用亚马逊弹性 Kubernetes 服务(亚马逊 EKS)升级 Kubernetes的帖子，部分原因是他们停止支持 Kubernetes 1.15，而在 2 月份，亚马逊 EKS 发布了对 Kubernetes 1.15 的支持。Kubernetes 继续更新——最新版本于 4 月 19 日发布，即1.21。(之前的版本是 1.20 版，发布于 2020 年 12 月 8 日——这是“最热门的版本”)

总而言之，Kubernetes 进展很快——这是一个复杂的开源项目，正在迅速成熟。我们自己的开源项目也与 K8s 密切相关，并且它们是活跃的和持续更新的。我们最近成立了一个开源用户组，因此我们可以邀请更多来自更广泛的开源社区的贡献者来贡献想法和改进。

没有版本是永恒的...

预计将停止对任何软件的旧版本的支持；不可能一直支持所有发布的软件版本。旧产品的停产只是产品生命周期的一部分，它使公司能够继续开发和支持其产品的活动(和更安全)版本。不过，如果你还没有准备好，转换到新版本会很难，有时甚至很难知道你正在使用的软件产品的版本。

你的集群里有什么？

如果你正在使用亚马逊 EKS，但你不确定你是否在使用 1.15 版，我们可以通过我们的北极星、洞察或 Nova 开源项目来帮助你解决这个问题。弄清楚你正在使用什么以及你是否需要很快升级是很重要的，因为如果你仍然在 AWS EKS 上使用 K8s v.1.15，你将无法再创建这个版本的新集群。根据亚马逊的说法，最终所有集群都将更新到 1.16 版。

使用较新的(受支持的)Kubernetes 版本总是一个好主意，因为旧的、不受支持的版本不会获得安全性、稳定性或特性补丁。特别是对于从 1.15 到 1.16 的过渡，引入了一些您需要了解的 API 弃用。最好是对升级进行规划，以便在上线之前有时间测试任何更改，并确保您的应用程序和服务仍能正常工作。

规划您的升级

亚马逊分享的帖子中有很多有用的信息，关于计划用亚马逊 EKS 升级 Kubernetes，包括与 1.16 中的 API 弃用相关的信息，以及可以帮助你检查升级到 1.16 后会崩溃的东西的开源工具。我们创建了我们的开源项目， Pluto ，以帮助用户在他们的基础设施即代码仓库和 Helm 版本中找到不推荐的 Kubernetes API 版本。如果您在升级过程中需要更具体的帮助，或者您对一个跨团队和集群提供一致性的平台感兴趣，以简化您的 Kubernetes 部署，联系 —我们很乐意提供帮助。

在 Kubernetes 中运行有状态应用程序工作负载

原文：https://www.fairwinds.com/blog/running-stateful-application-workloads-in-kubernetes

我们从客户和潜在客户那里得到的最常见的问题之一是，“你会在 Kubernetes 上运行我们的数据库吗？”通常我们的答案是“不，你可能也不应该”，但在某些情况下，如果你愿意承担额外的工作和复杂性，运行数据库等有状态应用程序工作负载可能是正确的选择。

你从哪里开始？

有很多原因(有些好，有些不好)让你希望在 Kubernetes 上运行数据库。除非这是一个真正的绿地项目，否则您可能已经在云提供商或数据中心愉快地运行了一个或多个数据库实例。

让我们检查一下你可能有的一些可能的原因，更重要的是，Kubernetes 是可能有帮助还是有伤害。

也许你有一些 Terraform 或其他配置管理代码，允许你配置你的 MySQL 副本或你的 Elasticsearch 集群，但并不十分满意。或者您对它很满意，但是您希望集中在 Kubernetes 基础设施部署工作流上，这使得运行 helm install mongodb 变得非常诱人。也许你读过一篇文章，作者在 Kubernetes 上不到 10 分钟就创建了一个 Wordpress 实例。您可能一直在尝试手动管理 PostgreSQL 实例，但它并不可靠，而且您听说 Kubernetes 有助于提高应用程序的可靠性！也许您希望尽可能多地重用您的应用程序部署自动化，并且希望以与您的应用程序相同的方式部署您的 Kafka 实例。

所有这些场景有什么共同点？在 Kubernetes 集群上运行数据库与在 metal 或 VMs 上运行相同的数据库相比，工作量几乎相同或更少。抱歉，事实并非如此。复杂性是附加的。你仍然需要理解底层的数据库配置，如何优化它以及如何在 Kubernetes 上运行它。 生产数据商店可不好办。Kubernetes 可能会很棘手，使用 Kubernetes 的数据持久性可能会非常棘手。

考虑云中 Kubernetes 中的持久数据:

自 PetSets 时代以来，Kubernetes 中的 StatefulSets 已经走过了漫长的道路，但是旧名称表明了 Kubernetes 早期版本管理状态的意图。它把【牛不是宠物】的想法精确到了豆荚级。如果丢失一个实例(或者本例中的 pod ),不管它恢复得多快，对您来说都是一个问题，那么在 Kubernetes 上管理它将是一个挑战。当它由于某种原因没有自动返回时，它会加倍。

当 PersistentVolume EBS 卷因为无法重新连接到集群中的某个节点(以及许多其他不幸事件)而被孤立时，Fairwinds 已经有了相当多的午夜页面。值得庆幸的是，Kubernetes 核心已经取得了很大进步，像 Rook 和 Portworx 这样的新解决方案已经大大改善了 Kubernetes 的状态(只要你知道如何正确运行它们)。也就是说，在选择一个可以在 Kubernetes 上运行并保持健康的数据库时，有几件事你应该考虑。

Kubernetes擅长什么？

服务发现和负载平衡
存储编排
自动化推出和回滚
箱型包装
自愈
机密和配置管理

这描绘了一个负载平衡连接的平台，可以在负载下水平扩展，自动在负载平衡器中发现新的工作负载实例，并替换失败的实例。对于无状态工作负载来说，这是编排的圣杯，但对于 MySQL 等传统数据库技术来说，这有点麻烦。看这张图，在 Kubernetes 上运行的最好的数据库类型是:

分布式的并且能够有多个副本，并且在丢失一些副本时仍然起作用，
短暂的，像缓存或开发环境。

不用担心，我正在使用< 插入分片多对多复制数据存储 >！

太好了，您正在 Kubernetes 上找到一个合理的数据库解决方案！假设:

您已经完成了所有的设置和调整，使其能够满足您的用例
您有一个可重复的部署方法。
社区掌舵图适合你，或者你有自己的专业知识来写。

你剩下要做的就是让它在 Kubernetes 上运行良好:考虑限制/资源、网络政策、Pod 中断预算、自动扩展，并考虑在 Kubernetes 上运行任何应用程序的所有其他复杂因素

你需要多区吗？多地区？多云？如果您需要多区域或多云，很有可能您需要添加一个服务网格，如 linkerd 或 Istio 或添加到列表中，并且您需要解决延迟问题。您的 PodDisruptionBudgets 配置好了吗？在升级和停机期间，您能承受多少副本丢失？您是否正确配置了亲缘关系，以确保每个副本都位于不同的节点上？在 AWS 上，您的持久卷是否跨区域分布，然后当在没有持久卷的区域中调度实例时会发生什么？ 生产数据商店可不好办。Kubernetes 可能会很棘手，而 Kubernetes 的数据持久性可能会格外棘手

我的数据库不能牛怎么办？

它是短暂的吗？如果不是这样，你仍然可以在 Kubernetes 上用一个副本在 StatefulSet 中运行 MySQL，就像你在大多数例子中看到的简单情况和你在设置 Wordpress 之类的东西时发现的情况一样，但是这样做你会削弱 Kubernetes 提供比运行“老学校”方式更高级别的服务的能力。如果没有负载平衡的副本，每当工作负载在节点之间移动时，您都会遇到服务中断。

如果它是短暂的，非生产性的，或者任何其他你可以在一段时间内不拥有它的情况，摇滚吧。

你要去哪里？

在 Fairwinds，我与一些组织进行了几次对话，他们希望摆脱数据专家，让他们的平台团队在 Kubernetes 上运行他们的数据存储，认为这将消除管理数据库的复杂性。现在你应该看到，在 Kubernetes 上运行你的数据库并没有消除复杂性，它 增加了 的复杂性。复杂性可以带来更高的服务质量，但这肯定不是灵丹妙药，而且做错的方法比做对的方法多。

好吧，那你推荐什么？

您应该以适合您的方式和位置运行您的生产数据库。如果您和您的团队愿意投入大量精力来充分理解这样做的含义和要求，那么在 Kubernetes 上运行它会是一个很好的选择。 生产数据存储可能有些棘手。Kubernetes 可能会很棘手，而 Kubernetes 的数据持久性可能会特别棘手。
如果您选择这样做，我强烈建议不要在上运行与其他高可伸缩性工作负载混合在一起的有状态应用程序；使用单独的节点池或群集。针对快速扩展而优化的集群/节点池，在装载和卸载云卷以及移动副本时，您的持久状态更有可能出现问题。 生产数据商店可不好办。Kubernetes 可能会很棘手，而 Kubernetes 的数据持久性可能会特别棘手。
不要解雇你的数据库管理员！Kubernetes 上的数据库仍然需要数据库专家。这也需要 Kubernetes 的专家。 生产数据存储可能有些棘手。Kubernetes 可能会很棘手，而 Kubernetes 的数据持久性可能会特别棘手。
短暂的缓存和开发环境是可以的。如果您丢失了一个 pod，重新装载卷或重新填充缓存需要大约 90 秒的时间，这种可能性很大。 这不是生产数据存储。

您的里程可能会有所不同。需要进一步帮助吗？

如何扩展 Kubernetes，而不忽略安全性和卓越运营

原文：https://www.fairwinds.com/blog/scale-kubernetes-without-leaving-security-and-operational-excellence-behind

Techstrong Research 在 2022 年对其社区进行了民意调查，向 DevOps、云原生网络安全以及数字化转型读者和观众询问了他们的 Kubernetes 环境。我们最近邀请了 Techstrong Group 首席战略官兼 Techstrong Research 总经理 Mike Rothman 来讨论这些结果。有一点非常清楚:Kubernetes 的使用正在激增。只有 25%的受访者没有在 Kubernetes 环境中运行任何生产应用程序，但更多人(31%)在生产环境中运行六个或更多应用程序。

Graph titled "Kubernetes Use is Exploding" showing 31% of respondents are running 6 or more production apps on Kubernetes

虽然 Kubernetes 的采用是不可否认的，但公司规模在我们看到的数据中起着重要作用。例如，小公司可能总共没有六个应用程序(部署在 Kubernetes 中或不部署)，而较大的组织可能有更多。随着明年 K8s 采用率的增加，类似这样的报告可能会变得更加精细，因此我们可以按公司规模跟踪采用情况，并显示关于有多少应用或服务正在生产中运行的更详细信息。

采用 Kubernetes 很难做对

在过去八年左右的时间里，我们已经看到 K8s 的采用稳步增长(最初发布的是 2014 年 9 月 9 日)，许多组织已经开始缓慢地行动，首先是测试 Kubernetes，并学习如何将其投入运营以将其引入他们的环境。与此同时，其他公司已经完全接受了它。在这段时间里，社区成长了，Kubernetes 成长了，在开源工具方面也有了很多进步。所有这些都有助于 Kubernetes 和 Kube 生态系统的成熟，这使得在生产 K8s 环境中更容易获得更多的团队和应用程序，并帮助开发团队更快地发货。但是，从两三个应用程序迁移到两百个应用程序迁移到云会带来新的挑战。

实施 Kubernetes

虽然许多团队已经能够在 Kube 中可靠一致地运行单个容器，但当组织试图在明年将数百个应用和服务迁移到 K8s 时，管理起来会变得更加困难。最大的挑战之一是实现一致性基线。策略实施已经成为组织采取更规范的方法来实现一致性和最佳实践的一种方式，而不是为每个团队创建一次性环境并手动调整每个设置。

Kubernetes 提供了很大的灵活性和许多选项，默认设置不一定是最安全、最可靠或最经济的。为了加速采用，它有助于消除一些复杂性并自动实施最佳实践，同时还确保它与您的 CI/CD 集成，以帮助开发人员在需要的地方获得他们需要的信息。

Graph titled "Operationalizing Kubernetes is the Biggest Challenge to Scale" - shows challenges in security, cost, application deployment, and troubleshooting

Techstrong Research的 PulseMeter 报告显示了团队在寻求运营 Kubernetes 时遇到的最大挑战。不出所料，24%的人认为最大的挑战与安全问题和担忧有关。在这个复杂的环境中，开发和运营团队担心配置错误和安全漏洞是可以理解的。

在 Kubernetes 中，故障排除也是一个严峻的挑战——开发人员通常不是 Kubernetes 专家，因此他们求助于平台工程师作为 Kubernetes 帮助台。故障排除通常非常耗时，并且会对其他关键工作造成大量干扰，从而降低所有工作的速度。另外两大挑战相互关联:应用程序部署的延迟和解决云成本。这很有趣，因为安全问题和故障排除都会导致部署延迟。

另一方面，云成本是我认为组织在未来一年将更加关注的一个问题。我认为有几个原因:

今年的经济很难预测，许多组织都在寻找更多控制成本的方法
不足或不存在是导致组织超支的原因，根据 CNCF 的 FinOps for Kubernetes 报告
快速增加的采用率很容易导致失控的云支出

根据 CNCF 的报告，68%的受访者认为 2022 年 Kubernetes 的成本会增加。调查显示，大多数人可以通过 Kubernetes 更积极、更细致的成本监控策略来减少开支。一种 FinOps 方法，这是一种识别与组织内各个孤岛的云支出相关的单位成本的实践，可以帮助组织了解其支出并实施 Kubernetes 成本规避策略。

自动化促进经营规模

在 Kubernetes 中，配置是一个严峻的挑战，因为查看单个 YAML 文件并找到配置问题很容易。当您处于像 Kubernetes 这样的复杂分布式环境中时，它位于云提供商及其配置之上，需要考虑的不仅仅是一个文件。需要注意的挑战有很多:错误配置、已知漏洞、过期的 Docker 映像、异常活动、基于角色的访问控制、法规遵从性以及可靠的应用和服务。

简单地手动完成所有这些在规模上是不可能的。您需要在开发、安全和运营部门之间创建一个共享框架，以实现这种可见性，并推动对不同类型调查结果的所有权。为您的组织创建策略并自动执行策略可以帮助您创建与各个团队的反馈循环，以便他们可以快速了解问题所在，了解如何修复它们，并知道哪些问题存在最大的风险。这将帮助您更快地移动和部署更多的应用程序，同时在 Kubernetes 环境中保持高水平的可见性。 Graph showing Kubernetes management activities that take too much manual effort or time

TechPulse 调查的受访者几乎同样关注这五个问题，并担心他们需要多少手动工作或时间:

部署软件时的配置复杂性(20%)
追踪成本和超支(19%)
检查和修复漏洞(18%)
保持合规(16%)
收集和报告合规证据(14%)

通过安全和卓越运营加速 Kubernetes 的采用

虽然仍然有很多关于采用的宣传，但 Kubernetes 仍然是一项新兴技术。许多组织正在增加采用率，并在来年将越来越多的工作负载投入生产。随着这种采用的增加，认真实施 Kubernetes 和其他云原生技术的组织需要研究和实施云原生解决方案，这些解决方案提供护栏来帮助开发人员快速部署应用和服务，而不必担心无意中发布易受攻击的代码、不满足监管合规性要求或增加不必要的云支出。

观看 DevOps.com 网络研讨会: 扩展 Kubernetes 而不影响安全性和卓越运营

第一个 Kubernetes 集群的安全基础

原文：https://www.fairwinds.com/blog/security-basics-for-your-first-kubernetes-cluster

所以你建立了一个集群。也许你已经部署了一些应用程序。你对库伯内特的事情很感兴趣。现在你做什么？

接下来可以做的事情很多。你可以安装一堆工具来让你的生活变得更轻松(无耻地塞给我的上一篇文章)。您可以开始部署应用程序并在生产中运行它们。或者，你可能在想“我到底要如何保护我刚刚放在云中的这个庞大复杂的东西呢?!？！?"这是一个有效的问题，我将尝试通过一系列易于遵循的实用步骤来回答这个问题。

*免责声明:我并没有写一个关于保护集群安全的完整指南，也没有声称这些信息是完美的。这是一个起点，一种让大脑活跃起来的方式，一种开启全面安全计划之门的方式。

GKE

我完全在 AWS 中开始了我的 Kubernetes 之旅，并认为它是 Bees Knees。然后，我发现了 GKE(谷歌 Kubernetes 引擎)，并迅速改变了我的想法。这两个平台都很棒，也有各自的缺点，但如果你刚刚起步，GKE 是一个很好的地方。

GKE 最新的默认设置相当不错，而且还在不断改进，但是在设置集群时，您应该选择一些设置，这样您以后就能够做一些安全的事情。

VPC 本地集群

首先要做的是打开 VPC 本地网络配置。这在 GKE 是相对较新的，很快将成为默认设置。它将集群放在 VPC 中，就像在 AWS 中一样。只差一个复选框，完全值得一试:

GKE VPC-Native Option

集群访问

完成后，我将浏览一组与集群网络相关的复选框。第一个在这里:

GKE Enable Master Authorized Networks

当你看到这里时，你可能会想“这个家伙不久前不是告诉我们 IP 白名单不是一种安全形式，我们应该停止这样做吗？”你在这一点上基本上是对的，我倾向于认为这一步基本上是不必要的。然而，作为更大的安全态势的一部分，这个设置可能是一个好主意。该设置将对主节点(和 Kubernetes API)的访问限制在一组特定的 IP 地址。这并不意味着这些 IP 地址上的任何人都可以神奇地访问您的 API，因为他们仍然需要通过 Kubernetes 进行身份验证才能做任何事情。它让你安心，如果 Kubernetes(见CVE-2018–1002105)出现严重漏洞，你有一点喘息的机会来修复它。这自然会对公共 CI/CD 工具和远程工作人员的可用性产生影响，但是如果您的集群的所有预期流量都来自单个网络内部，那么请务必打开“启用主授权网络”并将其设置为该 IP CIDR 块。

网络策略

我们要考虑的第三个复选框是启用网络策略:

GKE Enable Network Policy

这个盒子听起来很棒，事实也的确如此。它支持名为“Calico”的网络策略实现，允许您创建 Kubernetes 网络策略。反过来，这提供了严格限制集群中哪些东西可以与其他东西对话的能力。它并没有带来很多现成的好处，但它打开了通往安全世界的大门。如果你计划做高级网络策略，那么在开始的时候选中这个框会省去你一些麻烦。

禁用旧身份验证

最后一组框控制 Kubernetes API 的身份验证:

GKE Settings Security Section — Auth

很快，默认选项就足够了，但在此之前，您需要取消选中启用遗留认证、发布客户端证书和启用遗留授权。这将禁用基本身份验证，并强制所有用户使用 GCP 身份验证来访问群集。此外，Google 默认启用 RBAC，以便我们可以控制谁可以访问群集中的内容。稍后我将更详细地介绍这一点。

AWS (kops)

默认情况下，kops 在 VPC 内部创建一个集群，其中节点位于专用子网中，主节点位于公共子网中，ELB 用于 API 访问，ssh 仅在内部可用。总的来说，这是一个很棒的网络配置，不需要太多改变。在这一点上向 kops 开发者脱帽致敬。但是，在创建集群时需要添加一些设置，以最大限度地提高安全性。

集群访问

首先，您可以启用一个可以访问主服务器的 IP 白名单(参见 GKE 部分了解我对此的想法)。您可以在 kops 集群 yaml 中通过添加这个珍闻并替换您的 IP CIDR 块来做到这一点:

spec:
 kubernetesApiAccess:
 - 203.0.113.0/24

禁用匿名身份验证

您可以做的另一个简单的改变是关闭 kubelet 的匿名认证。从 Kops 安全:

spec:
 kubelet:
 anonymousAuth: false

网络策略

如果您想启用网络策略，可以通过更改网络覆盖来实现。Calico 或 Canal 都是支持网络政策的好选择。我不会在这里详细介绍它，但是 kops 有关于这个主题的大量文档。

启用 RBAC

接下来，您需要确保在集群中启用了 RBAC。这是新 kops 集群中的默认设置，但是值得检查一下集群规范:

spec:
 authorization:
 rbac: {}

启用审核日志记录

您想要的最后一个设置是打开审计日志记录。GKE 默认给你这个，但是在 kops 中我们必须自己添加。在 Fairwinds 时，我们使用来自 Kubernetes 文档的以下配置:

集群安全性

一旦您使用所有这些选项构建了集群，您还可以做更多的事情来增强您的安全状况。

使用 RBAC

现在启用了，就用吧。内置策略可能有用，但您也应该考虑自己的策略。此外，无论何时安装舵图，都要确保非常常见的rbac.enabled: true设置处于开启状态。这将创建特定于该应用程序的 RBAC 对象。去看看他们，看看他们做了什么。

使用 RBAC 管理器简化角色绑定和集群角色绑定的创建。这将使您能够创建一个简单的 CRD，将用户/组/服务帐户绑定到角色/集群角色。

最后，当你深入 RBAC 的杂草中，无论如何也想不出为什么有人能或不能接触到某样东西时，使用 RBAC 查找来查找。

Brief Demo of rbac-lookup — https://asciinema.org/a/222327

自由使用名称空间

引用一位同事的话，“名称空间很便宜。”使用它们来分离基础设施工具和应用程序之类的东西。这允许您使用 RBAC 轻松限制访问，并限制应用程序的范围。当您决定创建网络策略时，我也会让它变得更容易。

集装箱安全

最后，我们需要保护我们在集群中运行的工作负载，因为这些工作负载将暴露给我们的(潜在的敌对)用户。在 Kubernetes 中运行容器时，有许多默认或常见的东西提供了不太理想的安全性。这里有一个你可以开始做的事情的非详尽列表。

不要在每个容器中运行多个进程

Docker 通用最佳实践建议每个容器使用一个进程，这仅仅是出于可用性和大小的原因，实际上这也是一个很好的安全实践。它使您的攻击面保持较小，并限制了潜在漏洞的数量。

不要以特权身份运行容器

以特权身份运行容器或 pod 使其能够对主机进行修改。这是一个很大的安全问题，只要不去做就很容易缓解。

不要以根用户的身份运行容器

默认情况下，容器作为 root 用户在容器内运行。这很容易避免使用 pod 规范来设置高编号的 UID。

spec:
 securityContext:
 runAsUser: 10324

不要使用默认的功能列表

默认情况下，Docker 运行具有大量 Linux 功能的容器，其中许多功能您的应用程序可能并不需要。你可以在源代码中看到它们。默认情况下，以下配置将删除所有 Linux 功能，允许您只添加应用程序实际需要的特定功能:

spec:
 containers:
 - name: foo
 securityContext:
 capabilities:
 drop:
 - ALL

扫描容器中的漏洞

已知漏洞占违规的很大一部分。使用工具来扫描您的容器，然后缓解它们。 Anchore 、 Clair 和 Quay 是我最喜欢的工具，但是还有其他的。

看看 KUBSEC。超正析象管(Image Orthicon)

这个工具将分析您的部署 yaml，并告诉您应该进行哪些更改，以提高这些 pod 的安全性。它甚至给你一个分数，你可以用它来建立一个最低标准。该分数包含了我上面概述的所有最佳实践，以及其他一些最佳实践。

下面是一个得分为 9 的部署示例:apiVersion: apps/v1

不要停在这里

一直都有关于 Kubernetes 和安全的新东西出现。去读一读，试一试。就在最近，我在 CNCF 博客上读到了一篇文章，这篇文章很好地概述了安全最佳实践，并提醒了我一些我们应该做得更好的事情。安全是一个复杂的多层网络，不能用一种工具来解决，它永远不会“完成”，所以请不要在阅读本文后停止关心它。*

安全性是服务所有者的问题，不仅仅是您的 CISO 的问题

原文：https://www.fairwinds.com/blog/security-is-a-service-owner-problem-its-not-just-for-your-ciso

安全性可能过于自上而下

安全通常感觉像是自上而下的倡议——安装一个防病毒软件，做这个培训,这样你就知道如何避免被网络钓鱼——诸如此类的事情。但是良好的安全性是自下而上开始的，组织实现服务所有权需要将它下推到开发者/服务所有者的层次。

但是...有一个问题

大多数开发人员不知道如何拥有他们服务的安全性；他们提交一个应用程序，或者像现在常见的那样，提交一个容器，他们希望由 Ops 来处理和保护。结果，运营团队突然要负责部署的服务数量之多让他们感到不知所措。任何规模的运营或“平台”团队都可能是组织中对问题负责的唯一实体，这对于他们来说太难单独管理了。

普通开发人员一生都在担心他们交付的服务是否符合组织设定的 API 标准，或者是否给用户提供了他们想要的结果。开发人员希望发布他们需要发布的功能，他们希望确保服务正常运行，不会在压力下崩溃。他们不关心安全性，因为他们希望组织中的其他人更好地理解这个问题，并知道如何解决它。

那么，如何在开发人员层面上让这些问题变得可见呢？真正的服务所有权需要工具，使开发人员能够发挥他们的作用，帮助您的组织维护其安全态势。

解决方案—优秀的工具

重要的是，您选择现代工具，使您的开发人员能够理解他们需要修复什么以及如何着手修复它。这包括扫描代码的工具，或者可以在部署投入生产之前停止部署，因为它具有过度许可的设置。

幸运的是，开源社区中有很棒的工具来做诸如容器扫描、检查已知 CVE 之类的事情。但是该解决方案受到部署过程中每一步的限制:

代码部署在哪里？
默认的云设置是什么？
开发人员了解正在部署的每一部分吗？
开发人员了解每个底层部分是如何处理安全状态的吗？

平台团队可以实现开源解决方案，帮助您的组织维护其安全状态，并向开发人员展示这些工具，以便每个服务都可以完全拥有。这不仅有助于您的开发人员发布所需的功能并确保服务可靠运行，还能维护必要的安全状态。

费尔温德见解

当您部署到一个统一的地方时——比如基于 Kubernetes 的基础设施——您需要确保人们按照最佳实践做事。 Fairwinds Insights 通过以开发人员已经熟悉的方式集成到 CI/CD 管道中，使这变得容易。他们可以在部署包含安全问题时及早发现，远在投入生产之前。这种可见性对于开发人员来说至关重要——没有这种可见性，他们就看不到他们所做的事情如何融入大局，也不知道他们做的是否正确。

在大学里，我有一份工作，我的工作是用吹叶机清扫大学校园的大部分。我记得我的老板来过一次，告诉我我做错了，结果他必须再做一次。他没有告诉我哪里做错了或者如何改进——他只是告诉我这是错的。我记得我对他说了一些类似于“我想做好这份工作，但你没有给我任何培训，我不知道你想要的结果是什么，除了‘干净的人行道’。”“换句话说，他没有给我成功之路。

不要这样对待你的开发者。通过提供集群的仪表板视图并自动执行合规性要求，帮助他们了解您的 Kubernetes 环境。这种可见性和控制有助于您的团队了解他们正在做的事情如何适应更大的图景(一条干净的人行道)，因此他们了解错误配置如何导致安全和法规遵从性风险。Insights 帮助开发人员了解如何将所有权分配给合适的人或团队来解决这些问题。目标不是让你的 CISO 独自管理安全；管理好安全性需要开发、安全和运营团队将安全性作为服务所有者的责任——这种变化需要您组织中的工具和文化转变，但最终会使您的服务更加安全。

K8s 教程:使用 Goldilocks 设置和调整 Kubernetes 工作负载

原文：https://www.fairwinds.com/blog/setting-rightsizing-kubernetes-workloads

优化 Kubernetes 集群的一个标准建议是确保在每个容器上设置 CPU 和内存请求和限制。这看起来很简单，但是您如何知道选择哪些值呢？

Fairwinds Goldilocks 是一个开源实用程序，可以帮助您确定资源请求和限制的起点。像 Goldilocks 和 Three Bears 一样，这个工具可以帮助您确保在集群中为容器提供的空间不要太多，也不要太少，从而为您节省资金并防止潜在的应用程序中断。

在本教程中，我们将向您展示如何安装 Goldilocks 并利用它的建议。

先决条件

kubectl
舵
度量-服务器
垂直 Pod 自动缩放器
goldilocks-demo 命名空间中的 pod

安装先决条件

Goldilocks 要求您安装 metrics-server 和垂直 Pod Autoscaler。这些说明将指导您如何使用 Helm(Kubernetes 的软件包管理系统)安装 metrics-server 和 Vertical Pod Autoscaler。可以使用 Kubernetes yaml 清单来安装这些工作负载，您可以在度量-服务器文档和 VPA 文档中找到如何安装的指导。

安装度量标准-服务器

将 metrics-server 图表存储库添加到本地可用的 Helm 图表中:

helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/

接下来，在新的 vpa 名称空间中创建一个名为 my-metrics-server 的 Helm 版本:

helm install my-metrics-server metrics-server/metrics-server --namespace vpa --create-namespace

安装 vpn

将顺风-稳定海图库添加到您本地可用的舵图中:

helm repo add fairwinds-stable https://charts.fairwinds.com/stable

接下来，在 vpa 命名空间中创建名为 my-vpa 的 Helm 版本:

helm install -n vpa --create-namespace my-vpa fairwinds-stable/vpa

谷歌 Kubernetes 引擎(GKE)用户注意:

VPA 在自动驾驶集群中默认启用，但在标准集群中必须手动启用。您可以像这样启用它:

 gcloud container clusters update [CLUSTER-NAME] --enable-vertical-pod-autoscaling {--region [REGION-NAME] | --zone [ZONE-NAME]}

配置金发女孩

现在你已经设置好了先决条件，是时候使用 Helm 安装 Goldilocks 了。可以使用 Kubernetes 清单安装 Goldilocks，你可以在 Goldilocks docs 中找到如何安装的说明。

安装金发女孩

创建一个名为 my-goldilocks 的头盔版本:

 helm install -n goldilocks --create-namespace my-goldilocks fairwinds-stable/goldilocks

标记金发女孩将监视的名称空间

在本例中，我们希望监控 goldilocks-demo 名称空间中的任何部署。我们必须标记名称空间，以便 Goldilocks 可以为名称空间中的每个部署创建一个 VPA，然后查询它们的信息。

kubectl label ns goldilocks-demo goldilocks.fairwinds.com/enabled=true

打开金发女孩仪表板

端口转发金发女孩服务:

kubectl -n goldilocks port-forward svc/my-goldilocks-dashboard 8080:80

打开浏览器到http://localhost:8080查看仪表盘。您可能需要几分钟才能看到金发女孩的推荐。刷新浏览器可能会有所帮助。

检查金发女孩的发现

在这个例子中，我们在 goldilocks-demo 名称空间中有两个部署，每个部署都有一个相应的容器，echo-service 和 quote-service。

View of the Goldilocks Dashboard analysis and recommendation for the echo-service.

查看 Goldilocks 仪表盘分析和 echo-service 建议。

Goldilocks 向我们展示了对于有保证的服务质量*，echo-service 容器当前具有过高的 CPU 请求和限制，但是内存请求和限制刚刚好。在分析的下面是一个 yaml 片段，其中包含 CPU 和内存请求和限制的推荐值，您可以将其复制并粘贴到您的部署清单中。

View of the Goldilocks Dashboard analysis and recommendation for the quote-service

查看 Goldilocks 仪表盘分析和报价服务建议。

对于报价部署容器，Goldilocks 向我们展示了没有设置 CPU 或内存请求或限制。这是很危险的，因为容器可能会占用一个节点上的所有资源，挤走其他 pods，使工作节点对 Kubernetes 控制平面不可用。建议的资源设置在分析下方。

更新您的集装箱请求和限额

复制并粘贴建议的资源请求和限制后，您应该更新您的部署并刷新 Goldilocks 仪表板。您将看到 Goldilocks 指出您当前的 CPU 和内存请求和限制符合建议。祝贺您使您的资源请求恰到好处！

View of the Goldilocks Dashboard analysis for the echo-service where the current resource requests are in line with the recommendations.

echo 服务的 Goldilocks 仪表板分析视图，其中当前资源请求符合建议。

View of the Goldilocks Dashboard analysis for the quote-service where the current resource requests are in line with the recommendations 当前资源请求符合建议的报价服务的 Goldilocks 仪表板分析视图。

您的 pod 存在的时间越长，VPA 收集的数据就越多，所以一定要随时查看 Goldilocks 仪表板，因为建议可能会发生变化。

大规模应用金发女孩的优势

如果你有多个集群和用户，并希望大规模应用金发女孩的优势，Fairwinds 提供了一个名为 Insights 的平台。用户可以跨集群一致地集中管理 Goldilocks，以确保有效地设置 CPU 和内存请求和限制。Fairwinds Insights 通过提供Kubernetes的成本优化建议而更进一步。

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

资源

*“QoS(服务质量)等级是基于其资源请求和限制分配给 pod 的名称。Kubernetes 使用 QoS 等级来决定调度和驱逐 pod。 Kubernetes 文档:为 Pods 配置服务质量

Kubernetes 与 Fairwinds Insights 的 SOC 2 合规性

原文：https://www.fairwinds.com/blog/soc-2-compliance-for-kubernetes

如果你处理客户数据，你可能听说过 SOC 2。也许你已经要求供应商提供 SOC 2 报告，或者你已经自己进行了审计。

什么是 SOC 2，为什么它很重要？

SOC 2 审计报告关注服务组织的非财务报告控制，因为它们与系统的安全性相关。基于 AICPA 的信任服务标准，SOC 2 旨在为用户提供评估和解决与服务提供商相关的风险所需的信息。它有助于确保客户数据的安全，并确保组织遵守最新的网络安全标准。

采用像 containers 和 Kubernetes 这样的云原生技术会带来新的 SOC 2 合规性挑战。因为容器是短暂的(容器可以被停止和破坏，然后用绝对最少的设置和配置来重建和替换)，所以很难首先识别您是否符合，或者何时容器不再符合。

Fairwinds Insights 是一款用于监控、自动化和执行 Kubernetes 最佳实践的软件。企业使用 Fairwinds Insights 的安全性、合规性和治理控制来解决特定于容器和 Kubernetes 的 SOC 2 范围。Fairwinds Insights 提供多集群可见性和策略执行，因此您可以从 CI/CD 到生产全程管理 Kubernetes 的 SOC 2 合规性。这使您能够在开发过程的早期实现控制，而不仅仅是在生产中——因此您总是知道您最新的遵从状态。

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

以下是 Fairwinds Insights 如何帮助组织实现 SOC 2 的一些示例。

CC 6.1:针对受保护信息资产的逻辑访问安全软件、基础架构和体系结构，以保护它们免受安全事件的影响。

CC 6.1 的一个组件专注于标准化您的基础设施配置。

借助 Fairwinds Insights，Kubernetes 管理员可以运行多个自动化漏洞扫描工具来检测是否存在明显的安全漏洞，以及集群是否符合行业标准——如 CIS Kubernetes 基准。

此外，策略控制可以内置到 Fairwinds Insights 中，将护栏应用于集群配置。通过设置策略，可以防止从不受信任的来源部署容器。Fairwinds 围绕 Kubernetes 最佳实践带来了 100 多种开箱即用的检查，例如识别作为特权或根运行的容器。此外，该软件包括一个预建的自定义检查库，用于管理合规性和运营风险，例如要求在部署上贴标签。这意味着将客户数据转移到生产中的容器不会不符合要求。

CC 6.6:防止来自系统边界之外的威胁的逻辑访问安全措施。

CC 6.6 的一部分处理基础设施和应用程序容器的漏洞扫描。Kubernetes 是一种开源技术，这意味着许多运行核心 Kubernetes 工作负载的包和容器可能会引入已知的漏洞。拥有检查这些集装箱库存风险的流程成为实现 SOC 2 合规性的关键部分。

Fairwinds Insights 提供运行时容器扫描，以及 CI/CD 流程中的集成。跟踪容器中的已知漏洞是管理 SOC 2 合规性的重要部分，这两层使组织能够轻松建立漏洞管理计划来满足 SOC 2 要求。Fairwinds Insights 更进了一步，根据严重性对发现进行优先排序，为开发人员和合规团队提供了关于首先关注哪些方面的重要指导。

CC 6.8:防止或检测未经授权或恶意软件的引入并采取相应措施以实现实体目标的控制措施。

监控恶意软件和对基础设施的更改是 CC 6.8 的关键部分。在 Kubernetes 的情况下，这包括诸如监视谁可以访问集群、锁定 RBAC 和网络策略，以及利用部署策略来防止来自不可信来源的容器运行等活动。

Fairwinds Insights 可以通过运行时容器扫描和持续监控 RBAC 设置来帮助解决 CC 6.8 的问题。具体到 RBAC，Fairwinds Insights 将识别可能过于宽松的配置文件，例如那些能够查看机密或提升权限的配置文件。此外，您可以通过可定制的策略维护可信注册表的“允许列表”,从而防止容器从不可信的来源运行。

CC 7.1:检测和监控程序，用于识别(1)导致引入新漏洞的配置更改，以及(2)对新发现漏洞的易感性。

Fairwinds Insights 可以帮助您实现许多针对 CC 7.1 的特定控制，包括配置审计和漏洞管理等领域。Fairwinds Insights 的核心是提供漏洞管理功能，用于从单个控制平面跟踪配置缺陷和 CVE。该软件提供了一个审计线索，记录首次/最后一次发现问题的时间，以及服务所有者是否已经解决或减轻了这些问题。

开放策略代理(OPA)策略使您能够定义配置标准，从而防止错误配置传播到生产中。Fairwinds 提供了一些现成的策略，例如拒绝启用权限提升的部署。虽然 Fairwinds 默认采用明智的最佳实践，但可以定制策略来满足您的组织需求或允许例外。

与其他控制标准一样，Fairwinds 在运行时环境和 CI/CD 中集成了容器漏洞扫描。此外，Fairwinds 可以运行其他工具来查找集群本身的配置和漏洞相关问题。

CC 7.2:监控系统组件和这些组件的运行，以发现表明恶意行为、自然灾害和影响实体实现其目标能力的错误的异常情况；分析异常以确定它们是否代表安全事件。

CC 7.2 侧重于对系统的持续监控，以确保任何异常活动或行为浮出水面。借助 Fairwinds Insights，可以在集群中持续监控配置和漏洞信息，并在发现新发现时向下游系统发送警报。

可以在软件中跟踪调查结果，并保存审计跟踪记录和解决方案以备将来参考。

聚焦 Karpenter、Goldilocks 和开源集群自动扩展

原文：https://www.fairwinds.com/blog/spotlight-on-goldilocks-karpenter-and-autoscaling-with-open-source

在 Fairwinds，我们致力于增强我们的开源社区。通过我们自己的工具，我们努力工作来回馈这个有价值的群体，为容器化的未来构建高质量的开源项目。在开放的环境中进行精心的组装也使我们能够与 Kubernetes 社区中的人们进行交流，从业余爱好者到企业，从而使工具更加强大、可靠和功能丰富。因此，这种开源软件使我们的客户和社区能够在 Kubernetes 生命周期的每个阶段做出更好的决策。

即便如此，在 Kubernetes 采用和实施的道路上，某些挑战仍然存在，包括需要“恰到好处地”获得资源请求和限制，在利用集群自动伸缩的集群中提供稳定性和效率。

定义的聚类自动缩放

使用 Kubernetes 的好处之一是能够根据用户需求动态扩展基础设施。集群自动缩放是一个增加或减少 Kubernetes 集群大小的组件。这是通过添加或删除工作节点来实现的，具体取决于挂起 pod 的存在。迄今为止，Kubernetes 中最常用的自动缩放器是 Kubernetes 集群自动缩放器。

如果您有太多的资源，集群自动缩放器(CA)可以删除工作节点并节省资金。根据您的组织需求，将您的集群规模降至零也是可能的。CA 是一个行业采用的、开源的、厂商中立的工具。它是 Kubernetes 项目的一部分，由大多数主要的 Kubernetes 云提供商实施。最近，Karpenter 项目进入了这个领域，其目标是解决集群自动缩放器的一些限制。

在考虑 CA 和 Karpenter 之间的区别之前，了解一下弹性 Kubernetes 服务(EKS)是很重要的，这是亚马逊在 AWS 云中对 Kubernetes 的实现。集群由一个“控制平面”和一组称为节点的机器组成。在 EKS 中创建集群时，会创建一个控制平面和一个自动扩展组。自动缩放组中的 EC2 实例使用预定义的映像，启动脚本将实例加入集群。最近几个月，AWS 还引入了托管节点组的概念，AWS 将自动管理自动扩展组。

见见卡本特

寻找有效自动缩放的人们将很快有更多的工作要做。Karpenter 是一款开源软件，现在已经获得了 Apache License 2.0 的许可。作为设计用于在 AWS 中运行的 Kubernetes 集群的软件，Karpenter 观察未调度 pod 的聚合资源请求，并做出启动和终止节点的决策，以最大限度地减少调度延迟和基础设施成本。

Karpenter 在合适的时间用合适的节点简化了 Kubernetes 的基础设施。作为一种能力，这种“适用于任何 Kubernetes 集群的即时节点”是有价值的，因为它启动了理想的计算资源来处理集群的应用程序。通过这种方式，Karpenter 旨在让您通过快速简单的 K8s 集群计算资源调配来充分利用云。卡本特也:

通过快速、自动地响应应用程序负载、时间安排和资源需求的变化，提高应用程序可用性。这种能力将新的工作负载置于各种可用的计算资源上。

最大限度地减少运营开销在单个声明式供应器资源中提供一组自以为是的默认值，可轻松定制；不需要额外的配置！

在集群中安装 Karpenter 后，可以观察 Kubernetes 集群中的事件，并将命令发送到底层云提供商的计算机服务，如 Amazon EC2。这意味着 Karpenter 可以观察未调度 pod 的聚合资源请求，并启动新节点(或终止它们)以减少调度延迟和基础架构成本。

Karpenter 的一个主要区别是它能够直接对 EC2 进行 api 调用。Karpenter 可以做出所有最优的 EC2 实例选择来满足所有常量，而不是利用需要一组预定义实例类型的自动缩放组。只需 60 秒就可以配置一个新节点。如果您删除了一个节点，Karpenter 会很好地处理所有的节点退役，包括封锁和清空节点以及关闭相应的实例。

还在迷茫？看看这个关于 Karpenter 如何工作的高度可视化的解释！

让金发女孩“恰到好处”

当使用像 Karpenter 这样的自动缩放器时，获得正确的资源请求和限制变得更加重要。如果您的请求太高，Karpenter autoscaler 可能会添加远远超过您在集群中实际需要的节点，这将导致更高的成本。如果它们太低，那么您可能会在较小的节点上遇到资源争用问题。

Goldilocks 为调整您的资源请求和限制提供了一个解决方案。作为我们在 Fairwinds Insights 中用来优化 Kubernetes 工作负载的开源项目，Goldilocks 消除了对 Kubernetes 生产部署中运行的应用程序设置资源请求和限制的猜测。它帮助工程师确定资源请求和限制的起点，同时确保应用程序正确运行。

要查看每个应用程序的资源请求建议，垂直窗格自动缩放器(VPA)效果很好。Goldilocks 为名称空间中的每个部署创建一个 VPA，然后向它们查询信息。虽然 VPA 可以设置资源请求，但 Goldilocks 中的仪表板可以方便地查看所有建议，并根据您组织的 Kubernetes 环境做出决策。

Goldilocks 使用 VPA 中的推荐器生成推荐。事实上，金凤花开源软件完全基于底层的 VPA 项目，特别是推荐者。我们发现 Goldilocks 是设置您的资源请求和限制的一个很好的起点。但是鉴于每个环境都是不同的，Goldilocks 不应该被视为针对特定用例调整应用程序的替代品。

贡献给金发女孩

Goldilocks 是开源的，可以在 GitHub 上获得。我们继续进行大量的改进，提高其处理具有数百个名称空间和 VPA 对象的大型集群的能力。我们还改变了 Goldilocks 的部署方式，所以现在它包括了一个 VPA 子图表，你可以用它来安装 VPA 控制器和它的资源。

我们在 SquareSpace 与哈里森·卡茨一起做了很多改变，这是基于他和那里的团队的宝贵反馈。我们希望不断改进我们的开源项目，并欢迎您的贡献！

Goldilocks 也是我们的 Fairwinds Insights 平台的一部分，该平台提供对您的 Kubernetes 集群的多集群可见性，因此您可以针对规模、可靠性、资源效率和安全性配置您的应用。Fairwinds Insights 可供免费使用。可以在这里报名。

AKS、EKS 和 GKE 的优势和劣势

原文：https://www.fairwinds.com/blog/strengths-and-weaknesses-of-aks-eks-and-gke

在选择 AKS、EKS 或 GKE 这样的托管 Kubernetes 服务时，最好了解它们各自的优势和劣势。所有这些服务都解决了如何轻松部署 Kubernetes 的问题，但在如何正确配置集群或有效利用服务方面有所不同。通过了解这些优点和缺点，您可以为您的应用程序选择合适的服务，还可以节省学习多种服务及其具体细节的时间。

作为免责声明，如果有人问我用什么，我会反过来问你的应用程序在做什么，它依赖什么服务。Kubernetes 并不是您的应用程序唯一需要的东西，因此您需要考虑需求——例如安全性、额外的云服务和节点定制。在这篇博客中没有深入探讨，这里有一个高层次的总结。如果您确实想讨论您的具体应用，请随时联系。

TL；大卫:如果你是 Windows 或者。网店或者已经在用 Azure 如果你需要高水平的定制，EKS 是不错的选择；GKE 易于上手和使用。

所有被管理的库伯内的优势

选择阿克苏、EKS 或 GKE 可以让你不用担心维护 Kubernetes 州或其 API。每个托管服务从视图中抽象出控制平面。运营商只需担心选择合适的服务器类型来运行其工作负载。
每个托管的 Kubernetes 服务都完全支持其底层云提供商。这使得 Kubernetes 能够代表您创建云资源——比如负载平衡器或持久存储。虽然你可以从头开始运行 Kubernetes，但在 Azure/AWS/GCP 上运行同时与云服务无缝交互可能是一个挑战。
所有的提供者都支持私有节点和私有 API。从 Kubernetes 安全性的角度来看，这些产品非常相似。然而，有时容器工作负载需要许可才能与云提供商 API 进行交互。每个提供者都有自己的服务帐户和 IAM 层次结构。无论选择哪家提供商，您都需要了解其安全术语和最佳实践。

所有 Kubernetes 服务的弱点

所有供应商都依赖上游 Kubernetes 的开发。Kubernetes 的发展速度越来越快。每个服务提供商必须跟上发展的步伐，特别是因为 Kubernetes 只是修补了最近的三个周期。如果你还在 1.15 版本，不要指望任何补丁支持。
对于每项服务，您都无法配置控制平面。这限制了操作员打开/关闭 Kubernetes API 功能的能力。例如，如果有您的 Kubernetes 版本支持的 alpha 特性或配置标志——它不能在托管服务提供商上启用。
对所有提供商来说，在集群内外自动扩展服务器都是一项挑战。每个服务都利用一个叫做集群自动缩放器的工具。虽然集群自动伸缩功能做得很好，但它的功能确实有限。了解这些限制并能够在您选择的云提供商上解释这些限制非常重要。例如，集群自动缩放不支持分区。如果节点池跨越多个可用性区域，这可能会导致节点不平衡。由于这一限制，您可能希望为每个可用性分区运行单个节点池或自动扩展组。
最后，虽然所有三个提供商都已被认证为 CNCF Kubernetes 一致性，但没有一个是直接从源代码运行的-它们是预打包的，并引入了额外的功能。这并不是一个真正的弱点，但是在比较托管服务和 Kubernetes 代码库时，您可能会遇到一些不一致的地方。

AK、EKS、GKE 的优势和劣势

按字母顺序，这里是一个快速总结 AK，EKS 和 GKE。这不是一个详尽的列表，可以作为一些优势或劣势进行讨论，您可能会将其视为您的个人应用程序的优势。

AK 强项

如果你是. NET 或者微软的店家，AKS 对 Windows 有一流的支持。
配置虚拟网络和子网很简单。
使用 az cli 提供强大的命令行支持。
集成日志和监控解决方案。
Azure Active Directory 集成用于集群身份验证。

AKS 弱点

与 GKE 和 EKS 相比，AKS 相对较新。因此，许多功能仍处于测试阶段。
在 Fairwinds，我们支持将基础设施作为代码，大量使用 Terraform。Azure Terraform provider 并不完全支持所有的 Azure APIs，所以有一些问题。az 命令行工具可以用来补充 Terraform。
您对可以运行的底层操作系统的选择是有限的。唯一的选择就是 Linux (Ubuntu)和 Windows Server。虚拟机不直接支持定制，也无法提供云初始化或用户数据脚本。
部署群集时，您必须运行默认节点池，它必须始终存在，并且一旦部署，您就不能更改服务器类型。
对多节点池的支持是一项预览功能。
与 GKE 自动更新相比，节点更新不是自动的。
与 GKE 自动恢复相比，节点不会从 kubelet 故障中自动恢复。

EKS 的强项

AWS 非常成熟，像 Terraform 这样的工具集成得很好。亚马逊已经发布并维护了一套非常健壮的 EKS Terraform 模块，具有许多特性。如果你只需要和 EKS 交互，有一个官方的命令行工具， eksctl 。
EKS 节点更加可定制。您可以使用自己的机器映像(ami)。这允许您定制您的操作系统，并根据您的具体需求配置服务器。您仍然可以选择使用预设的 AMI，但有时由于安全合规性规定，这些 AMI 不可行。
AWS 是使用最广泛的，并提供许多额外的云服务。大多数 Kubernetes 工具(DNS 管理、证书管理等。)完全支持 AWS 集成。AWS 上的 Kubernetes 被广泛记录，并提供了一个庞大的用户社区。

EKS 的弱点

虽然创建 EKS 集群很简单，但添加和自定义节点池可能会很复杂。
与 GKE 自动更新相比，节点更新不是自动的。
与 GKE 自动恢复相比，节点不会从 kubelet 故障中自动恢复。
基于实例类型和子网大小的 Pod 密度和 CNI 限制。

GKE 的强项

GKE 让部署 Kubernetes 集群变得非常容易。命令行工具和 web 控制台都非常友好。
更新群集版本和节点池是一个简单的单击过程。也可以将版本设置为在可能的情况下自动更新。
节点池可以配置为自我修复，防止在底层 kubelet 出现问题时进行手动干预。
GKE·切里挑出 bug，CVE 修复到他们发布的 Kubernetes 版本中。这样做的缺点是，如果用户运行的是 GKE 版本的 1.15.9，并且他们想查看 Kubernetes 代码，他们不能完全确定代码没有被修改。

GKE 的弱点

您不能自定义您的服务器配置。你必须使用他们提供的两种服务器类型之一:Container OS 或 Ubuntu。您不能选择版本或内核版本。如果你想在底层硬件上进行更深层次的定制，你不能用 GKE 来实现。
GKE 运行的托管集群插件(kube-dns、ip-masq-agent 等)对于最终用户来说并不是可配置的。它们不能被修改以使用节点选择器或容错。对这些插件所做的任何更改都将被还原。
虽然不是一个巨大的弱点，GKE 有区域集群的概念。默认情况下，群集的控制平面(主)和节点都在您创建群集时指定的单个计算区域中运行。创建集群后，这一点无法更改。如果您需要一个生产就绪的 GKE 集群，请确保创建一个区域集群。

Fairwinds + EKS、GKE 或 AKS

利用托管的 Kubernetes 服务并不等同于有效地使用 Kubernetes。Fairwinds 帮助使用 AKS、EKS 或 GKE 的公司正确配置集群，并有效利用该服务。

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

了解更多关于 Fairwinds 对 AKS、EKS 或 GKE 的贡献。

技术对话:kops、AWS 和 Kubernetes 的未来

原文：https://www.fairwinds.com/blog/tech-talk-the-future-of-kops-aws-and-kubernetes

随着 AWS EKS(托管 Kubernetes 服务)的发布，kops 维护者 Chris Love 和 Eric Hole 讨论了对 Kubernetes 生态系统的影响。

如果有什么问题，欢迎在下面提问！

Terraform 和 EKS:部署第一个集群的分步指南

原文：https://www.fairwinds.com/blog/terraform-and-eks-a-step-by-step-guide-to-deploying-your-first-cluster

在一个由四部分组成的系列中，我们讨论了 Terraform 及其重要性，并通过AK和 GKE 提供了 Terraform 的分步指南。现在我们穿越 EKS。

使用基础设施作为代码来管理 Kubernetes 允许您在配置文件中声明基础设施组件，然后用于在各种云提供商中提供、调整和拆除基础设施。Terraform 是我们管理 Kubernetes 基础设施整个生命周期的首选工具。你可以在这里阅读关于 Terraform 的好处。

这篇博客提供了一步一步的指导，告诉你如何通过部署你的第一个以基础设施为代码的集群来开始使用 Terraform 和 EKS。

先决条件

具有管理员权限的 AWS 帐户
- 创建访问密钥
- 下载密钥文件
安装以下组件

步骤

为项目创建一个类似 terraform-eks. 的目录接下来，用这个命令在目录中建立一个 ssh 密钥对: ssh-keygen -t rsa -f ./eks-key.

我们现在将设置几个 Terraform 文件来包含各种资源配置。第一个文件将被命名为 provider.tf。创建该文件并添加以下代码行:

provider "aws" {
  version = "~> 2.57.0"
  region  = "us-east-1"
}

现在，创建一个名为 cluster.tf. 的文件，这将包括我们的虚拟网络、集群和节点池模块。首先，我们将添加一个局部变量块，其中包含一个可在不同模块中使用的集群名称变量:

locals {
  cluster_name = "my-eks-cluster"
}

接下来，我们将使用 Fairwinds 的 AWS VPC 模块为集群设置网络。请注意，该模块被硬编码到一个/16 cidr 块和一个带有/21 cidr 块的子网。你可以在回购处了解更多关于该模块的信息:https://github.com/FairwindsOps/terraform-vpc。

module "vpc" {
  source = "git::https://git@github.com/reactiveops/terraform-vpc.git?ref=v5.0.1"

  aws_region = "us-east-1"
  az_count   = 3
  aws_azs    = "us-east-1a, us-east-1b, us-east-1c"

  global_tags = {
    "kubernetes.io/cluster/${local.cluster_name}" = "shared"
  }
}

最后，我们将为集群本身添加模块。我们将实际使用一个社区支持的 Terraform AWS 模块:

module "eks" {
  source       = "git::https://github.com/terraform-aws-modules/terraform-aws-eks.git?ref=v12.1.0"
  cluster_name = local.cluster_name
  vpc_id       = module.vpc.aws_vpc_id
  subnets      = module.vpc.aws_subnet_private_prod_ids

  node_groups = {
    eks_nodes = {
      desired_capacity = 3
      max_capacity     = 3
      min_capaicty     = 3

      instance_type = "t2.small"
    }
  }

  manage_aws_auth = false
}

一旦 cluster.tf 文件完成，通过运行 terraform init. 初始化 Terraform，Terraform 将生成一个名为 .terraform 的目录，并下载在cluster.tf.中声明的每个模块源。初始化将拉入这些模块所需的任何提供程序，在本例中，它将下载 aws 提供程序。如果进行了配置，Terraform 还将配置后端来存储状态文件。输出将如下所示:

$  terraform init
Initializing modules...

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "local" (hashicorp/local) 1.4.0...
- Downloading plugin for provider "null" (hashicorp/null) 2.1.2...
- Downloading plugin for provider "template" (hashicorp/template) 2.1.2...
- Downloading plugin for provider "random" (hashicorp/random) 2.3.0...
- Downloading plugin for provider "kubernetes" (hashicorp/kubernetes) 1.11.3...

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

成功初始化 Terraform 后，运行 terraform plan 查看将创建的内容:

$  terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

module.eks.data.aws_partition.current: Refreshing state...
module.eks.data.aws_caller_identity.current: Refreshing state...
module.eks.data.aws_iam_policy_document.cluster_assume_role_policy: Refreshing state...
module.eks.data.aws_ami.eks_worker: Refreshing state...
module.eks.data.aws_ami.eks_worker_windows: Refreshing state...
module.eks.data.aws_iam_policy_document.workers_assume_role_policy: Refreshing state...

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create
 <= read (data resources)

Terraform will perform the following actions:

  # module.eks.data.null_data_source.node_groups[0] will be read during apply
  # (config refers to values not yet known)
 <= data "null_data_source" "node_groups"  {
      + has_computed_default = (known after apply)
      + id                   = (known after apply)
      + inputs               = {
          + "aws_auth"        = ""
          + "cluster_name"    = "my-eks-cluster"
          + "role_CNI_Policy" = (known after apply)
          + "role_Container"  = (known after apply)
          + "role_NodePolicy" = (known after apply)
        }
      + outputs              = (known after apply)
      + random               = (known after apply)
    }

...

Plan: 59 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

请注意，这段摘录已经过编辑，以缩减本文的篇幅。

如上例所示，Terraform 将添加 59 项资源，包括一个网络、子网(用于 pod 和服务)、EKS 集群和一个受管节点组。

计划通过验证后，通过运行 terraform apply. 进行最后一个验证步骤来应用更改，Terraform 将再次输出计划并在应用前提示确认。完成此步骤大约需要 15-20 分钟。

要与集群交互，请在终端中运行以下命令:

aws eks --region us-east-1 update-kubeconfig --name my-eks-cluster

接下来，运行 kubectl get nodes ，您将看到集群中的两个工作节点！

$  kubectl get nodes
NAME                           STATUS   ROLES    AGE     VERSION
ip-10-20-66-245.ec2.internal   Ready       3m16s   v1.16.8-eks-fd1ea7
ip-10-20-75-77.ec2.internal    Ready       3m16s   v1.16.8-eks-fd1ea7
ip-10-20-85-109.ec2.internal   Ready       3m15s   v1.16.8-eks-fd1ea7

这就是我们关于使用 Terraform 在多个云提供商中设置 Kubernetes 集群的系列文章。如果不需要您的集群，请运行 terraform destroy。继续您的 Kubernetes 之旅，祝您愉快！

资源

托管 Kubernetes 与 Amazon ECS 的优势

原文：https://www.fairwinds.com/blog/the-benefits-of-managed-kubernetes-vs-amazon-ecs

在之前的一篇文章中，我们讨论了 AWS 弹性容器服务(ECS)等容器编排解决方案的优缺点。截至 2019 年，Kubernetes 已成为生产中运行容器的前端和中心解决方案。对于使用 AWS ECS 的客户来说，这迫使他们围绕 Kubernetes 的业务优势做出决定。

2018 年 CNCF 调查显示，83%的组织使用 Kubernetes 作为其容器编排解决方案，而 24%的组织使用 ECS。AWS 在 2018 年增加了弹性 Kubernetes 服务(EKS)，以应对客户在 AWS 上使用 Kubernetes 的增长。Kubernetes 还使公司能够在内部和云环境之间转移工作负载，支持该技术的新用例，但也增加了额外的运营开销。EKS 的目标是简化其中的一些任务，使 AWS 成为不断增长的托管 Kubernetes 市场的主要参与者。

【Kubernetes 可以提供帮助:

无锁定，完全开源: Kubernetes 既可以在内部使用，也可以在云中使用，无需重新构建您的容器编排策略。该软件是完全开源的，可以重新部署，而不会产生传统的软件许可费用。
强大的灵活性:此外，如果您有一个重要的创收应用程序，Kubernetes 是满足高可用性要求的一个很好的方式，而不会牺牲对效率和可伸缩性的需求。借助 Kubernetes，您可以精确控制工作负载的扩展方式。这允许您在需要切换到更强大的平台时，避免受 ECS 或其他容器服务供应商的限制。
高可用性和可伸缩性: Kubernetes 包含内置的高可用性特性，有助于负载平衡和自我修复。自动扩展可确保您的工作负载始终有适量的计算可用。
充满活力的社区 : Kubernetes 是一个活跃的社区，拥有广泛的模块化开源扩展，得到了像 CNCF 这样的大公司和机构的支持。数千名开发人员和许多大公司为 Kubernetes 做出了贡献，使其成为现代软件基础设施的首选平台。
长期解决方案:鉴于 Kubernetes 的崛起，许多云提供商正在将他们的研发重点转移到扩展他们的托管 Kubernetes 服务，而不是传统选项。在制定长期 IT 战略时，请考虑 Kubernetes。

采用 Kubernetes 的主要考虑事项

Kubernetes 确实有一个学习曲线。现有的托管 Kubernetes 服务，如谷歌 Kubernetes 引擎(GKE)、Azure Kubernetes 服务(AKS)和 AWS Elastic Kubernetes 服务(EKS)，在保持 Kubernetes 控制平面可用方面做得很好，但仍需要运营团队做出一系列技术决策。例如，运营部门仍然必须添加监控、日志记录、审计、部署验证、DNS 和入口功能等等。除此之外，运营团队还能及时了解配置、升级和修补每个附加组件的最新最佳实践。所有这些对平台工程团队来说都是沉重的负担，因为他们要兼顾多个基础设施和开发运维优先级。

Fairwinds ClusterOps 通过利用容器和 Kubernetes 提供专业管理的云原生基础设施，为平台工程和 DevOps 团队解决了这一问题。ClusterOps 是一个完全托管的 Kubernetes 平台，提供由站点可靠性工程师团队全天候管理的生产级集群。ClusterOps 在云基础设施层和客户工作负载之间运行，集成了 Fairwinds 的工程专业知识以及我们的开源软件和自动化产品。它提供了所有必要的服务和管理控制，以确保部署持续优化、高度可用且安全。

如果您对 Fairwinds ClusterOps 感兴趣，请务必下载解决方案表以了解更多信息。

在 Google 容器引擎上运行 Kubernetes 的好处

原文：https://www.fairwinds.com/blog/the-benefits-of-running-kubernetes-on-google-container-engine

所有迹象都表明 Kubernetes 正在成为容器编排平台的事实标准。假设您已经完成了研究，并且您知道您想要使用【Kubernetes】作为您的容器管理系统。一切都好。你也知道你有两个主要的云托管选项: 亚马逊网络服务(AWS) 和谷歌云平台(GCP) 。亚马逊是显而易见的选择，因为许多开发人员对 GCP 和谷歌容器引擎(GKE) 的接触和经验有限。

然而，如果你想在 AWS 上运行 Kubernetes，你还有很多工作要做。如果你正在寻找基于容器的工作流，GCP 将使 Kubernetes 更容易管理和更新。自从谷歌创建了 Kubernetes，GKE 基本上给你一个开箱即用的 Kubernetes 集群。换句话说，比起在 AWS 上建立 Kubernetes，有一个更好的选择:让建立 Kubernetes 的人也托管它。

GKE vs. AWS 上的 kubernetes on gke vs . aws

让我们从在 GCP 上运行 Kubernetes 比在 AWS 上运行更好这个前提出发。一个合理的问题是为什么——有什么不同？

最简单的答案是，谷歌参与了 Kubernetes 的开发，因此谷歌自动支持 Kubernetes 的新功能，并且比其他云提供商更快——有时快得多。谷歌容器引擎(GKE)比其他云提供商更快地支持最新和最好的 Kubernetes 版本。

如果你知道你想使用 Kubernetes，那么你在 Google 上设置它的时间和金钱可能会比在 AWS 上少。让我们看看这实际上意味着什么。

封闭 vs 开源
亚马逊 EC2 容器服务(ECS) 基本上是亚马逊打造容器集群的尝试。它完全是闭源的，而 Kubernetes 是完全开源的。你可以看到谁在开发 Kubernetes(以及他们在开发什么)，并且你不会被一个云提供商(AWS 或 Google)所束缚。

不常见的与常见的范例
亚马逊已经自制了他们自己的容器集群软件，使用 ECS 时您需要构建的技能与其他平台上使用的不同。ECS 基本上是亚马逊其他服务的大杂烩，这意味着它既不健壮，也不是以一种易于在生产工作负载上使用的方式构建的。

您使用 Kubernetes 开发的技能可以应用于许多其他产品和系统，而您使用 ECS 构建的技能非常专业，不适用于您所做的大多数其他工作。因此，在 AWS 上运行 ECS 或 Kubernetes 将需要大量的人工工作，并且您需要经历相当多的考验。

自动化与人工努力
按照这些思路，如果你想使用 Kubernetes，GKE 大大缩短了学习曲线，因为谷歌为你设置了基线功能。使用 GKE，您可以在 10 分钟内启动并运行 Kubernetes 集群，而在 AWS 上，您必须做大量的工作来了解如何设置集群，使用什么工具以及如何在准备就绪时构建新的集群。您还必须对出现的任何问题进行故障排除，然后能够评估集群是否已经启动并按照您期望的方式运行。

GKE 消除了这些耗时的步骤。只要告诉 GKE 一些关于你的集群的基本情况，它就会自动引导你的集群。在实际创建集群的过程中，GKE 节省了大量的麻烦和时间，而且您实际上可以快速地在集群上部署应用程序，而无需一开始就保持集群运行的开销。

简单与复杂集成
AWS 没有像 GKE 那样的托管 Kubernetes 安装。另一方面，GKE 有谷歌的支持，并集成了谷歌的所有其他工具。它在主机和容器级别都有内置的日志记录、日志管理和监控功能。与 AWS 不同，它可以为您提供自动缩放、自动硬件管理和自动版本更新。与在 AWS 上手工构建相比，它通常为您提供一个包含更多电池的生产就绪型集群。

AWS/GCP 的决定是你的

集装箱化集群的社区支持正在库贝内特斯周边固化。因为 Kubernetes 和 GKE 都是在谷歌内部开发的，谷歌工程师比其他云服务更快(更好)地支持所有 Kubernetes 功能。亚马逊没有付钱给他们的工程师让 Kubernetes 在亚马逊上运行得更好。

通过 GKE，您可以获得一个生产就绪的 Kubernetes 集群，其中包含所有必要的工具，以及确保您的软件包和版本保持最新所需的持续支持。GKE 为你处理安全默认设置，并与其他谷歌服务整合。这种组合需要更少的集群管理开销，并使其在长期使用中更加无缝。

需要明确的是， Fairwinds 可以处理 AWS 和 GCP 上的 Kubernetes。这两种解决方案对我们来说都很好。然而，如果你有政治资本和选择的能力(例如，如果你还没有一家亚马逊商店)，GKE 会让你的生活更轻松。

简单来说，Kubernetes 在 GKE 上比在 AWS 上更好。在 GCP 上运行 Kubernetes 将会节省你的时间和金钱，并给你一个更短的学习曲线，更多的协同作用和更好的体验。

Kubernetes 的商业价值

原文：https://www.fairwinds.com/blog/the-business-value-of-kubernetes

你好！我是科里·奎恩。你可能是从我上周在 AWS 的简讯中认识我的。这可能会让你们中的一些人感到惊讶，但搜索大型云提供商(虽然个人很享受)并不是我花费大部分时间的方式。我做很多事情——其中之一是给做有趣事情的公司当顾问。其中一家公司是 Fairwinds。

如果你以前没有听说过它们，它们解决了公司的运营问题——通常是通过将 Kubernetes 应用于任何保持足够长时间不动的东西——今天。 Fairwinds 将 Kubernetes 视为改变软件交付和运行方式的手段；他们不认为这是目的本身。

最近,“Kubernetes”这个词出现在地球上每一家大型企业、时尚基础设施初创公司、天使投资人、分析公司、早餐麦片盒和肉毒杆菌诊所的嘴边。“太棒了，我很高兴像一个喝醉的水手在岸上度假一样拿着你花的钱”，这是许多在这一领域创新的公司的态度，但我没有看到讨论太多的是一个危险的问题，“部署 Kubernetes 对你有什么商业价值？”

不要误会我的意思——我并不是说一头扎进一项你既不会拼写也不会发音的前沿技术本质上是一件坏事，但是 2001 年网络泡沫的破灭已经离我们远去，我们可能正在失去那个令人兴奋的时代的教训。最值得注意的是，“因为它很酷”不是在真空中构建东西的可行理由。

对于那些没有屏息细读 Gartner 幻方图、容器编排公司新闻稿或没有为各种希腊神话术语设置 Google Alerts 的人来说，Kubernetes 是一个管理容器的系统。它通常被缩写为“K8S ”,这是硅谷坚持寻找新的和创新的方式来强烈骚扰大量人的一部分。

“我有一个由 web 服务器、应用服务器和数据库组成的应用程序”现在可以放在非常简单的文件中，Kubernetes 负责管理保持应用程序运行的重担。如果一个网络服务器死机，Kubernetes 会重启它。如果有一个工作队列正在积压，Kubernetes 就会调动更多的工人来处理它。如果您有 10 台 web 服务器，Kubernetes 会注意不要将其中的 8 台放在同一个物理节点上。

这个游丝般的梦与现实的铁栏杆相遇的地方，就在于一些严酷的事实。

您的应用程序必须支持在容器化的世界中运行。
在许多情况下，代码从开发环境进入生产环境的方式必须进行重大改变。
这需要大量的工作。

为了部署 Kubernetes 而部署 Kubernetes 并不符合业务价值，这是一种错误的看待方式。相反，其支持者所看到的价值来自于加速新特性的部署、提高基础设施的持久性以及将构建、运行和维护生产环境的大量“繁忙工作”交给软件而不是人的能力。Kubernetes 让您的开发人员更容易、更高效地使用和维护，这让您的开发人员有更多时间专注于他们的产品。提高功能速度相当于加快上市时间，而提高耐用性相当于减少花费在消防上的时间，并有助于阻止反复中断造成的客户信誉下降。询问你的医生 Kubernetes 是否适合你。

在接下来的几周里，我们将探索更多的这些主题；我希望你能加入我。

Fairwinds 对黑人生活的承诺-更新

原文：https://www.fairwinds.com/blog/the-fairwinds-commitment-to-black-live-an-update

乔治·弗洛伊德被谋杀后的三个月已经证明，重视和保护黑人的生命仍然是必要的。本周，另一名黑人雅各布·布莱克(Jacob Blake)在他的三个孩子面前被警察枪杀，导致他瘫痪，威斯康辛州社区受到震动，这让我们想起了这个国家赤裸裸的种族不公正。在 Fairwinds，我们仍然致力于黑人生活运动，我们将继续在全国和技术领域内影响正义和公平。

7 月，我们发表了一份关于我们承诺的声明。在过去的一个月里，我们一直在努力实施我们概述的倡议。以下是最新消息:

制定行动计划，在我们的董事会和高管团队中增加并保持黑人领导

我们已经建立了一个强大的黑人董事渠道。在 Fairwinds 的下一轮融资中，我们将有机会从不同的候选人中引入一名新的董事会成员。我们还为未来的执行领导职位建立了一个黑人候选人管道，随着公司的不断发展，将需要这些候选人。此外，本月早些时候，Fairwinds 承诺与更广泛的技术社区合作，签署了 MassTLC 多样性和包容性倡议。

提供一项为期 3-6 个月的黑人企业后端基础设施支持

我们与Tech for Black Founders合作，为一家黑人企业提供一套为期 3-6 个月的免费服务和软件。如果你知道黑人创业者会觉得这很有用，请与他们分享这一资源，并鼓励他们通过链接或电子邮件black-founders@fairwinds.com申请。

为有抱负的黑人青年设立奖学金

我们与图灵软件与设计学院合作，为即将入学和正在攻读 BIPOC 并在技术领域寻求职业发展的学生设立一项新的奖学金。此外，我们还与他们的黑人学生协会合作，提升社交和就业机会，因为我们认识到这些机会更加有限。Fairwinds 还将与我们的团队一起，通过直接联网和工作准备策略来支持 BSA。

围绕招聘和使用少数人所有/领导的供应商和销售商制定流程

我们已经收集了所有供应商和相关支出的清单。我们为业务往来最多的前 20 家供应商准备了一份多元化调查问卷，并已发送给他们。结果将确立我们的起点，然后我们将努力确定我们的目标。与此同时，我们还将此调查问卷用于我们正在招募的任何新供应商，并致力于建立更加多样化的渠道。

我们不会放慢努力，解决我们国家根深蒂固的种族主义问题。Fairwinds 团队将继续致力于康复和正义，并继续致力于长期的多元化和包容性。请在今年晚些时候关注我们的最新进展。

Fairwinds 对黑人生活的承诺

原文：https://www.fairwinds.com/blog/the-fairwinds-commitment-to-black-lives

我们谴责乔治·弗洛伊德、艾哈迈德·阿贝里和布里奥纳·泰勒的可怕谋杀，以及全国各地警察和白人至上主义团体对黑人的其他不公正谋杀。我们承认，每有一个像乔治·弗洛伊德这样的人受到媒体关注，就有更多的人没有受到关注。

我们也承认，这些杀戮只是更大的冰山一角；即我们国家根深蒂固的种族主义和白人至上主义。这种意识形态是严重影响黑人的暴力社会状况的核心。

自从最近这波起义开始的那一刻起，我们想做的不仅仅是发表一份新闻声明。我们一起走向绘图板，决定我们作为一个公司，如何才能摆脱沉默的共谋，尽我们的一份力量来帮助实现愈合和正义。

因此，我们承诺在公司、全国和全球范围内支持黑人生活:

在接下来的 30 天里，我们将制定一项行动计划，在我们的董事会和执行团队中增加并维持黑人领导，不仅仅是象征性的，而是作为在各个层面影响我们公司的人。
我们将通过提供 3-6 个月的黑人自有企业后端基础设施支持，解决系统性种族主义造成的代际财富差距。
我们将与合作伙伴共同努力，为有抱负的黑人青年设立奖学金，帮助他们成为工程师、创办公司并在技术社区找到工作。
作为 Kubernetes 社区的一部分，我们将围绕招聘和使用少数民族所有/领导的供应商和销售商制定一个流程。

我们将不断更新我们在这些领域的进展。同时，该去工作了。

顺风队

不要让云拖垮你:云服务器备份的重要性

原文：https://www.fairwinds.com/blog/the-importance-of-cloud-server-backups

我们都熟悉最常见的威胁媒介——黑客或其他不良分子获得对您的云基础架构的访问权，以利用系统漏洞。一个较少被提及的威胁媒介是有意或无意地删除内部数据。不管怎样，这种威胁迟早会成为现实。那么，当那个时刻到来时，你该如何准备呢？

为了确保高可用性和灾难恢复功能，从而提高可管理性并实现业务连续性，您首先需要确定您想要保护的内容—静态基础架构、动态基础架构、持久数据和依赖关系—然后创建涵盖关键基础架构和数据的灾难恢复计划。

静态基础设施

静态基础设施包括不经常改变的基础设施，包括网络基础设施、防火墙和 VPN 设备，以及平台状态文件。例如，在Kubernetes世界中，静态基础设施可能包括集群配置和主/从用户数据。

像terra form或AWS cloud formation这样的工具可以用于静态基础设施配置管理(CM)。确保定期进行代码审查和工程审查，并保留版本变更历史。考虑将您的静态基础架构配置应用到您的云平台上的多个区域，这将为您提供一个二级灾难恢复站点，而无需太多额外成本。

动态基础设施

动态基础结构包括应用程序堆栈的各个部分，这些部分可能会在应用程序的生命周期中发生变化，例如服务器配置、安全组、启动配置、自动伸缩组和负载平衡器。

Ansible 是一款常用的 DevOps 工具，用于自动化应用部署和协调基础设施变更。无论您使用什么工具，您都需要跟踪所有动态的基础结构变化。CM、版本控制和工程评审非常重要，如果应用程序堆栈遭到破坏或损害，完全重建应用程序堆栈的能力也非常重要。

假设一个坏人获得了对您的基础设施的访问权。如果您始终如一地维护和监控您的安全策略、实例配置和资源供应的单一真实来源，您的应用程序堆栈可以在不同的区域快速启动和运行。

不变数据

持久数据是您公司的命脉。它是存储用户信息、应用程序配置和逻辑的地方。大多数云存储资源允许您出于备份目的定期对数据进行快照。为防止丢失，请确保快照被镜像到辅助区域或帐户。一些可以考虑的工具:

亚马逊关系数据库服务(RDS) 允许您的数据库的定期时间点快照。快照可用于恢复实例，并可轻松复制到其他区域和帐户。
亚马逊弹性块存储(EBS) 卷在每个可用性区域保存数据，并定期拍摄快照。可以修改快照以授予其他 AWS 账户访问权限，并且可以在地区和账户之间复制。
elastic cache是一个用于缓存存储或键值存储的亚马逊 web 服务。如果您计划使用该工具维护状态，请确保设置自动快照，并像处理数据库一样传送备份。
S3是亚马逊面向互联网的云存储。S3 存储桶中的所有数据都应复制到另一个帐户或地区。“一次写入，永不删除”存储桶策略和对象版本控制允许您保留多个版本，以防数据被覆盖或删除。

考虑维护一个仅用于备份的单独云帐户。例如，创建一个严格用于备份的 AWS 帐户，将其设置为“一次写入，永不删除”以维护永久的备份历史，定期同步持久数据，并限制可以访问该数据的用户数量。然后，如果你的主 AWS 账户出了什么问题，你仍然有你的备份账户。

属国

您的工作负载中存在应用程序和基础架构级别的依赖关系。如果这些依赖关系发生问题，您可能无法在灾难后重建基础设施。一些可以考虑的工具:

亚马逊机器映像(AMIs) 是作为磁盘映像保存的已配置操作系统的快照。您的应用程序堆栈可能依赖于定制的基础映像，因此请确保备份 AMI 快照，以防您需要重建。如果主区域受损或停机时间延长，将 AMI 快照发送到辅助区域可以实现灾难恢复。
Route 53 是亚马逊 DNS web 服务。早在 10 月，一次 DDoS 攻击导致一家主要的 DNS 提供商瘫痪，并导致东海岸大部分地区的互联网瘫痪。如果您使用 53 号路由进行 DNS，您需要一个备用计划。这样，如果 AWS 出现重大故障，您可以将您的区域备份带到另一个 DNS 提供商，并快速恢复在线。

结束语

你如何确保云不会让你失望？通过密切跟踪哪些信息发生了更改，谁在何时更改了它。

最重要的是，您了解您的基础架构备份需求，然后为您的业务制定正确的定制备份和恢复战略。

以正确的方式扩展基础架构的重要性

原文：https://www.fairwinds.com/blog/the-importance-of-scaling-infrastructure-the-right-way

大多数企业都会随着时间的推移而发展壮大，你今天的企业不会是六个月后的企业，更不用说一年、三年或五年后的企业了。增长和业务浪潮(高潮和低潮)是以正确的方式扩展云基础架构非常重要的主要原因。目标是确保您的基础架构在任何特定时刻都能满足您的需求。借助当今的技术，这种灵活性是可以内置的。

缩放类型

在我们深入探讨之前，我们应该澄清一些关于可用扩展类型的事情，水平的和垂直的。 水平扩展 是指您将硬件实例添加到您的资源池中，以便增加您可以同时运行的应用实例的数量。 垂直扩展 意味着您要为自己管理的现有硬件实例增加更多的能力(CPU 和 RAM)。在第一种情况下，你有更多的实例；在第二种情况下，你有更大的实例。

许多公司在日常运营中没有区分这两者，也没有为此进行优化。

许多公司规模不正确，或者至少效率低下

例如，一个应用程序可能是单线程和 CPU 受限的(意味着它不能利用一个以上的 CPU 内核)，并且需要相当大的内存量。要扩展这个应用程序，您需要运行它的更多实例。您可以在每个硬件实例上运行更多的应用程序实例(垂直扩展)，也可以继续在每台机器上运行一个应用程序实例，但产生更多的硬件实例来支持它们(水平扩展)。如果您选择水平伸缩(我看到的最常见的方法)，那么您就会遇到实例大小的问题。由于云提供商提供了一套实例大小，您必须选择足够大的大小来提供您的应用程序所需的 RAM 量，这意味着您经常会有 CPU 资源处于闲置状态。结果，你最终购买了昂贵的硬件，但只使用了其中的一半(或不到一半)。这种类型的扩展也很慢，因为它需要时间来启动每个实例，这妨碍了您对流量激增的响应能力。

假设您创建了一堆实例，因为您决定运行一个超级碗广告或推广一个重要的黑色星期五活动。在那一天，您最终会花费大量资金来支持您的基础架构需求，而在其他大多数日子里，这些资源可能会闲置或利用不足。如果你在黑色星期五的基础设施和你在三月的一个普通星期二的基础设施是一样的，你会有不同的性能和浪费金钱。

进入集装箱化

幸运的是，还有另一种方法。容器化使您能够管理由受控数量的集群主机节点组成的更集中的基础架构，而不是拥有一个使用了一半的大型实例的基础架构。在Kubernetes世界中，你有一个公共的节点资源池——CPU 和 RAM。因为在这种情况下，您的应用程序是容器化的，不像以前那样受制于硬件限制，所以您可以将它的多个副本放入集群。您可以在同一台机器上堆叠一堆应用程序副本，而不是为每个应用程序实例安装一台新机器。Kubernetes 甚至允许您指定非常小的 CPU 和 RAM 度量单位(例如千分之一的 CPU 或 KiB 的 RAM)，因此您可以准确地指定您的应用程序需要什么。这种资源分配的精确程度是非常强大的。

这对您的企业意味着什么？

随着您的业务增长，您的基础架构和应用程序也可以随之增长。随着您的成长，您可以发展容器的限制和要求，而不必重新部署您的基础设施。换句话说，随着应用程序的不断变化，您可以更加灵活地决定基础架构如何响应。你也会浪费更少的钱，因为你会充分利用你所有的资源。

想象一下，一家公司运行数百个实例来满足需求。因为他们的应用程序没有容器化，不能以集群/并行方式运行，所以他们每个月要在基础架构上花费数千美元。通过将他们的应用程序容器化，并迁移到像 Kubernetes 这样的容器平台，他们可以显著减少物理实例的数量，并完全使用资源池，从而实现巨大的节约。

一个集中且灵活的基础设施意味着一个更加可移植的集群

最后，一个集中、灵活的基础设施也是一个更易移植的集群。在 2017 年 2 月 28 日 AWS 停机期间，整个 us-east-1 区域数据中心失去了产生新实例的能力。对于依赖水平实例扩展的公司来说，这是极其困难的。此外，同一次停电导致了几个关键 AWS 服务的级联故障。想象一下，如果该地区没有恢复，而上面假设的公司不得不将其基础架构转移到不同的地区或云提供商，以快速恢复在线，这将是一项艰巨的任务。适当的资源管理和扩展云基础设施将使更集中的实例集群具有更快、更简单的可移植性。

这是一个重要的话题。如果你想了解更多，这里有一个有用的演示: “你曾经想知道的关于资源调度的一切……差不多” (由蒂姆·霍金在谷歌创建)。

下一个第 2 部分-为什么自动化很重要，它如何节省时间！

从 Heroku 到 Kubernetes 的五步之旅

原文：https://www.fairwinds.com/blog/the-journey-from-heroku-to-kubernetes-in-5-steps

使用 Heroku 就像和一个 HOA 人住在一个豪华的住宅区；它安全、可预测、结构化，而且价格不菲。

Heroku 拥有直观的仪表盘、清晰的用户防护栏和结构化的开发流程。对于许多公司，尤其是那些刚刚起步的公司，这种类型的基础设施是物有所值的。然而，随着公司规模的扩大及其开发需求变得更加复杂，Heroku 变得限制性和昂贵。

对于符合后一种情况的公司，可能是时候开始迁移到 Kubernetes 了。但是在他们做出决定之前，他们应该考虑些什么呢？

你会想念 Heroku 的什么？

Heroku 的一个主要好处是，总的来说，它是 非常简单。这一点在其:

易于使用的开关和仪表板
精致的用户界面
托管 web 代理和 NGINX 配置和路由
合规保证

在 Kubernetes 中，许多操作功能并不是固有地内置于平台中的。因此，Heroku 上的大多数公司可能没有专门的 DevOps 资源。如果这些公司选择开始迁移到 Kubernetes，他们将需要深入了解他们当前的 Heroku 运营结构，注意他们喜欢什么和不喜欢什么，并准备在 Kubernetes 中实现这些结构。对许多人来说，这意味着雇佣或培训某人成为专门的 DevOps 资源。

你有什么选择？

对于大多数开发团队来说，总有一天你需要比 Heroku 所能提供的更多的灵活性。重温一下住房开发的比喻，你可能真的想给你的房子加一层楼，但 HOA 说“不”，因为它与社区不匹配。同样，你在 Heroku 上的应用程序可能服务于如此大的流量，是时候扩展了，但是 Heroku 不允许这样做，因为操作限制和增加的费用。

这就是 Kubernetes 如此令人兴奋的原因；实际上，它有能力成为 定制的 PaaS 构建者。这里没有 HOA 告诉你该做什么；都是你。但这并不意味着你是一个人。有很多针对 Kubernetes 用户的众包社区支持，包括专门的 Kubernetes 管理服务提供商。

Kubernetes 提供什么？

比什么都重要。Kubernetes 提供定制的开发基础设施。这意味着您可以在您的新基础设施中模拟 Heroku 的最佳部分，同时放弃您发现有限制或不重要的部分。随着您继续使用该平台，您可以不断完善这一过程，以确保您的开发高效、安全地扩展。

从战术角度来看，Kubernetes 还允许您扩展应用程序以响应任意事件(不像 Heroku，它只依赖于延迟指标)。您还可以创建自定义部署策略，例如执行蓝绿色部署或保留实验。

Kubernetes 还帮助您回答一些关键问题，例如:

您的应用程序运行效率如何？
您是否过度调配或调配不足内存和 CPU 资源？
您的应用程序伸缩性如何？

最终，您会从 Kubernetes 获得您所投入的东西，所以不要吝啬为您的团队准备和实现弹性基础设施。

迁移是如何进行的？

如果你准备好了，你会很高兴地发现 Kubernetes(大部分)是云不可知论者。Kubernetes 与亚马逊、谷歌和微软云服务兼容，这意味着大多数公司可以在转换期间将数据保存在同一个地方。

在开始迁移到 Kubernetes 之前，您会希望诊断出在 Kubernetes 中配置开发基础设施的哪些区域是最重要的。这里有一些问题会给你指明正确的方向:

我目前如何管理配置？
我目前如何管理机密？
我希望如何利用 CI/CD 管道？
我想如何处理应用程序发布和生命周期管理？

这些问题的答案将确定您需要用 Kubernetes 基础设施解决的最重要的领域。

我如何迁移并保持同样出色的体验？

成功迁移的关键是准备、准备和更多的准备。如果你习惯于拥有一个非常结构化的、自以为是的基础设施，Kubernetes 的完全自由可能是压倒性的。

对于许多公司来说，雇佣一家 Kubernetes 管理公司来帮助迁移比自己做所有的事情更容易。这些公司将评估您当前的开发流程和需求，并创建一个计划来反映您的新 Kubernetes 基础架构中的这些优先事项。

此外，这些公司可以在构建过程中部署自动化，以帮助将迁移时间从 6 个月 缩短到仅 6 周。 而且，通过大量的初步测试和 DNS 切换的使用，与迁移相关的实际停机时间可能只有 60 秒。

想了解更多关于 Kubernetes 迁移过程的信息吗？点击下面的按钮查看我们的网络研讨会:

准备好转换了吗？了解 Fairwinds 如何帮助回答您关于潜在迁移的问题！

云不可知论的神话

原文：https://www.fairwinds.com/blog/the-myth-of-cloud-agnosticism

Kubernetes gets you further down the road to a cloud adoption strategy and being able to abstract away which public cloud vendor you choose than any technology in recent memory (Docker is so three years ago). The ability to instantiate workloads between providers in something close to realtime is powerful-- you can arbitrage workloads between providers and locations, letting you move compute to wherever the prices are right, on a minute-to-minute basis.

除...之外

不知何故，事情从来都不是那样的。令人费解的是，工作负载变得与特定位置的特定提供商紧密相关。“每小时节省 20 英镑的计算成本”的数学公式在语句以“结束”结束时就失效了...并花费 2000 美元将数据转移到该提供商，这样那些稍微便宜的容器就有东西可吃了。”数据重力意味着您的数据所在的位置总是您的基础架构的其余部分所基于的位置。

云不可知论的真实成本

大约在 2012 年，保持一层云不可知论是有意义的。谁将是主要参与者，未来的经济状况如何，以及数据迁移会变得多么痛苦，这些都还不清楚。五年后，我们已经找到了这些问题的答案。无一例外，我有幸工作过的每一个环境都是以巨大的成本达到提供商不可知论的——无论是实际成本、技术开销还是操作复杂性。维护提供者不可知论的成本与在需要时实际完成提供者迁移的工作量相比微不足道——这种情况很少发生！对于能够从一个云提供商迁移到另一个云提供商的所有口头承诺，很少有公司真正这样做了——那些发现他们的故事被接收提供商在屋顶上呼喊的公司。

关注你的需求

如果您的基础设施设计原则要求能够将工作负载部署到多个提供商，那么您将受限于这些提供商之间的通用功能。这并不完全是一件坏事——每个著名的提供商都提供了一个 VM 实例、一个负载平衡器、一个托管数据库，以及(如果 AWS 继续发布他们所宣布的内容的话！)Kubernetes 供品。假设您的应用程序符合“传统的”架构模型，那么这将使您达到您需要的大部分目的。

你放弃的是提供商竞相部署的差异化服务。谷歌的 Cloud Spanner 在其他供应商中没有对手；如果您需要一个符合 ACID 的全球关系数据库，您可以使用 Spanner，或者您也可以构建自己的数据库。“听起来不难。我可以在一个周末内完成！”是的，黑客新闻。我看见你了。

这对未来意味着什么？

不断增长的无服务器技术套件仍然高度依赖于构建它们的云提供商。调用函数的事件、那些函数是如何编写的、围绕它们的约束(语言选择、资源限制、并发选项)都是不同的；虽然 Fairwinds 在我们说话的时候正在这个领域大步前进，但是多云无服务器仍然是一个神话。

最后，位于数据湖之上的机器学习工具需要靠近这些数据。如果你正在建立你自己的(立即停止！)您正在重复提供商为使这些系统尽可能可访问而投入的大量工作；那是你想花费你的创新能量的地方吗？针对不同供应商的不同硬件产品的培训模型是我所能想象的对昂贵的工程时间的最糟糕的利用；不要走这条路！

2018 年，没有明确的“不惜一切代价避免”云提供商。GCP、AWS、Azure——它们都是非常值得尊敬的选择，没有人会因为你的选择而责怪你。他们提供广泛的服务，他们了解不同规模的企业是如何运作的，在这篇文章发表之前，他们可能不会倒闭。挑一个没错。在我看来，错误在于试图把它们都挑出来。

新堆栈:建立采用 Kubernetes 的最佳实践

原文：https://www.fairwinds.com/blog/the-new-stack-podcast-establishing-best-practices-for-adopting-kubernetes

在本期中，新的 Stack Makers 、J ustin Mound 和Eric Hole与 Benjamin Ball 谈论 Fairwinds (又名 ReactiveOps)根据与采用和利用该平台的客户的互动，认为围绕 Kubernetes 出现了最佳实践。虽然这些最佳实践中的许多在 Kubernetes 社区中得到了巩固，但是仍然有许多棘手的问题，比如存储持久性和秘密管理。本次演讲的重点是 ReactiveOps 如何解决这些问题，以及随着 Kubernetes 生态系统中工具的发展，哪些问题有望得到解决。在这里找到原播客，或者听下面。

运行可伸缩的 Kubernetes 集群的秘密就在这里

原文：https://www.fairwinds.com/blog/the-secret-to-running-scalable-kubernetes-clusters-is-here

在过去的几周里，我们已经就成功拥有 Kubernetes 服务的五个关键因素撰写了一系列博客。从安全性到合规性到成本优化可靠性，一个组织内有效的所有权模式可以带来数不清的宝贵利益。在所有这些优化领域中，最不受重视的领域之一是 可扩展性、 业务增长的关键因素。在 Kubernetes 中，可扩展性是指集群在保持一定服务水平的同时继续增长的能力。使用 Kubernetes 创建可伸缩和容错的应用程序来自于所有这些领域的优化，可伸缩性也不例外。

强大的服务所有权如何影响可伸缩性？

安全性、合规性、成本、可靠性——这些都是 Kubernetes 正确服务所有权的理想结果。此外，这些好处都在某种程度上有助于组织有效扩展的能力，特别是当随着时间的推移融入最佳实践过程时。例如，通过正确的应用规模(CPU 和内存请求和限制)，应用可以有效地扩展。有了适当的安全配置，容器中的漏洞就不是问题了。实施策略后，应用程序可以在保持合规性的同时进行扩展。通过这种方式，所有这些好处交织在一起，创造了全面和高度成功的 Kubernetes 所有权的结构。

对于使用 Kubernetes 开源软件来开发和运行应用程序的从业者来说，为适当的部署和管理进行伸缩是至关重要的。随着可伸缩性和可靠性的提高，您可以通过使用 Kubernetes 从更高的整体效率中受益，这使用户能够在更大的规模上获得对开发和部署的更多控制。通过在同一应用程序上将多个容器组合在一起，该过程可以实现自动化。Kubernetes 然后自动分配资源，管理服务发现，分析集群的整体健康状况，并执行其他必要的任务，以确保无痛部署。

随着应用架构继续从难以管理的整体式或三层模式发展到互连的微服务和 Kubernetes，考虑未来的道路以及 SaaS 配置解决方案如何发挥作用非常重要。因为如果管理不当，Kubernetes 既复杂又昂贵，所以通过一个健壮的运营模型来简化流程是没有商量余地的。服务所有权允许团队不断克服文化和技术挑战，同时采用更具协作性和创新性的方法。

Fairwinds Insights 如何帮助实现可扩展性？

我们的安全和治理软件解决方案fair winds Insights通过简化复杂性和启用 Kubernetes 服务所有权模型，统一了开发、安全和运营。它通过集成从 CI/CD 到生产的服务所有权来促进持续改进。为了帮助团队克服文化挑战并接受服务所有权，Insights 允许用户:

通过持续监控所有集群的安全错误配置并查明从 CI/CD 到生产的风险，实现安全自动化。
通过建立政策和实践来加强保护，帮助开发人员在遵守 SOC 2 要求的同时更快地行动。
通过更好地了解您的工作负载来优化成本，并获得适当规模应用的建议。
通过基于最佳实践的策略找到可靠性，以确保快速、可靠的应用程序以及最少的停机时间。
随着 Kubernetes 扩展到多个团队，通过一致配置成功扩展。

fair winds Insights通过提供所有集群的仪表板视图并帮助团队了解导致安全和合规性风险的 Kubernetes 错误配置，为开发运维团队提供了对 Kubernetes 环境的可见性。该软件通过将所有权分配给负责解决这些关键问题的个人或团队，帮助团队解决管理 Kubernetes 的一些更具挑战性的方面。开发人员能够在他们的应用中拥有安全和效率配置，因此这不再仅仅是运营的问题。

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

基于云的基础设施的第十条规则

原文：https://www.fairwinds.com/blog/the-tenth-rule-of-cloud-based-infrastructure

我想我想分享一些关于 Fairwinds(又名反应性操作)起源的想法——关于我们做什么以及为什么要做。我先讲一点历史。

回到大学，我创办了一家两人科技创业公司，我身兼数职——程序员、系统管理员、数据库管理员。早期，我学会了欣赏伟大的基础设施的商业价值。

毕业后，我做了一名程序员，获得了 MBA 学位，随后成为了许多使用 Heroku 的初创公司的首席技术官，Heroku 是一种无需人工干预的云平台即服务基础设施。像许多已经迁移到云的公司一样，这些初创公司使用 Heroku，因为它有一个很好的 web 界面，无需管理服务器，以及良好的 DUX(开发者用户体验)。基础设施是具有挑战性的东西，Heroku 提供了许多人力难以替代的服务。然而，最终 Heroku 的成本超过了收益，我们将遇到该平台一刀切的限制。

公司往往希望在自己的平台上运行类似 Heroku 的环境，我创办的创业公司也不例外。在每种情况下，我们都会用内部的 DevOps 工程师替换 Heroku。它总是变成一个昂贵的烂摊子。

也许你熟悉互联网先驱菲利普·格林斯潘的第十条编程规则:“任何足够复杂的 C 或 Fortran 程序都包含一个临时的、非正式指定的、错误百出的、缓慢的普通 Lisp 的一半的实现。”换句话说，Common Lisp 的灵活性和可扩展性使它成为衡量其他编程语言的标准。

我有我自己的第十条规则(我没有其他规则)——任何足够复杂的基于云的基础设施都包含一个特别的、非正式指定的、充满 bug 的、缓慢的(并且更昂贵的)Heroku 实现。

80/20 甜蜜点

在像 Ruby on Rails 这样的开源框架出现之前，公司构建了大量与业务运营无关的代码。这与选择模板语言或数据库库没有什么不同——虽然重要，但这些活动通常与核心业务挑战无关。

Ruby on Rails 采用了许多它的创造者大卫·海涅迈尔·汉森(DHH)没有自己创造的惯例和技术(MVC，ActiveRecord)。他的战略性集成方法得到了回报，今天，不使用 Ruby on Rails 这样的成熟框架从头开始开发 web 或 SaaS 应用程序是不可想象的——尤其是因为 Ruby on Rails 有一个 80/20 的最佳点，这意味着它对大多数应用程序都很有效。既然 Ruby on Rails 已经存在，为什么还要构建自己的 Ruby on Rails 呢？

2015 年，ReactiveOps 诞生了

良好的基础设施是优秀应用程序和优秀 DUX 的先决条件，但是，像 Ruby on Rails 一样，大多数公司不需要拥有自己的基础设施架构和代码。

当我大约两年前开始 ReactiveOps 时，我们着手为云上的 AWS 创建一个类似 Ruby on Rails 的框架——将最好的开源组件缝合在一起，并尽可能少地编写我们自己的代码，从而提供比其各部分之和更大的东西。我们的目标是为中小型公司提供该基础架构，使他们能够利用该平台，而不是雇佣内部开发团队并构建自己的团队。

因此，我们构建了 Omnia，一种不可变的基于基础设施的方法，它使用不同的技术，如 Ansible 、 Terraform 和Packer来创建按钮式环境。我们的客户获得了他们需要的基础设施，没有 Heroku 的限制，也没有雇佣内部 DevOps 员工的麻烦和成本。

虽然我们的客户使用 Omnia 取得了成功，但它不可伸缩，也没有很好的 DUX。例如，如果我们客户的工程师想要升级 Ruby，他们必须学习所有的工具或者让我们来处理。没有我们的帮助，这些开发人员无法部署应用程序。

就在那时，我们了解到一个改变一切的工具…

进入 Kubernetes

在我们开始 ReactiveOps 大约一年后，我们重新评估了一个名为 Kubernetes 的工具，这是一个开源平台，用于跨主机集群自动部署、扩展和管理应用容器。Kubernetes 的基础设施承诺让公司能够大规模快速部署应用程序，轻松推出新功能，同时只使用所需的资源。

起初我们持怀疑态度。虽然我们的团队在实现基于 Amazon 机器映像(AMI)的可靠方法方面有几十年的经验，但我们缺乏对容器的概念性理解。让事情更加复杂的是，容器的工作和行为方式在很大程度上没有定义。码头化和集装箱化真的对大多数公司有利吗？

2016 年 4 月发布的 Kubernetes 1.2 包含了更多面向通用用途的功能。它被吹捧为下一个大事件，我们决定对它进行测试。我们很快发现 Kubernetes 是一个优雅的、结构化的、现实世界的大规模集装箱化解决方案，它解决了其他技术没有解决的关键挑战。它有 1000 多名贡献者的 160 多万行代码——它的功能比我们能构建的要多得多。我们没有切实可行的方法与之竞争。

就在那时，我们做出了艰难但具有战略意义的决定，用 Kubernetes 取代 Omnia。

Kubernetes 是未来

Kubernetes 是一个非凡的下一代框架，可以运行任何工作负载。它提供了很好的 DUX，创新的速度正在加快，它背后有谷歌的承诺，所以它不会去任何地方。借助 Kubernetes，我们的客户可以在自己的 Google cloud、AWS 或本地环境中运行自己的 Heroku。他们甚至可以在没有我们帮助的情况下将自己的应用程序部署到 it 中。

像 Ruby on Rails 一样，Kubernetes 包含了许多智能的架构决策，有助于在容器化中构建应用程序。许多事情仍在你的掌控之中。例如，您可以决定如何设置、维护和监控不同的 Kubernetes 集群，以及如何将这些集群集成到其余的基于云的基础设施中。

我们最擅长什么

我们的一些竞争对手已经建立了自己的基础设施来与 Kubernetes 竞争，就像我们过去做的那样。其他人构建了他们自己的 Kubernetes 专有发行版，然后出售企业支持许可证。还有一些是定制的试错式操作商店，它们努力以艰难的方式解决单个客户端的挑战，而不是首先从一组旨在协同工作的工具和库开始。

我们用 Kubernetes。虽然放弃 Omnia 的决定并不容易，但我们并没有坚持自己的实现。因为我们不对外部投资者负责，我们有在正确的时间做出正确的商业决策的自由。

我们如何工作

我们从为期 1-2 周的深度基础设施审计开始，我们查看客户的系统和应用程序，以确定他们的应用程序是否能在 Kubernetes 中工作。如果是这样，我们将推出可扩展的、基于结果的实施方案。传统上，我们会在 2-4 个月内让我们的客户在 Kubernetes 上运行起来。

我们专注的方法是构建一个以 Kubernetes 为核心的平台即服务解决方案。我们的解决方案基于标准技术，因此您可以获得经过深思熟虑的商业现成工具。我们提供的商业价值是我们卓越的 DevOps 服务和专业知识。

我们的工作是为客户提供优秀的基础设施。Kubernetes 使我们能够做我们最擅长的事情，这使我们的客户能够专注于他们最擅长的事情。

2023 年你需要的三大 Kubernetes 安全策略

原文：https://www.fairwinds.com/blog/the-top-three-kubernetes-security-strategies-you-need-for-2023

整个世界都在试图搬到库伯内特。同时，每个人都害怕自己会做错事。他们害怕发布配置糟糕、过度配置或过度许可的应用和服务。这种担心是可以理解的，但并不需要如此。你可以更安全地采用 Kubernetes，通过制定计划来帮助你准备和防止与错误配置、供应和许可相关的问题——换句话说，你可以从本帖中讨论的三个 Kubernetes 安全策略开始。

您何时需要 Kubernetes 安全策略？

每个组织或安全团队都害怕对您的应用程序、数据、与客户的互动以及声誉造成意外影响的可能性。无论是违规、应用程序能够以您意想不到的方式相互通信，还是通过第三方扩大攻击范围，如果攻击者突破了边界，他们将能够访问系统和服务，并可能造成相当大的损失。

实现 Kubernetes 安全性的最佳方法是尽早制定计划，因为安全性很难追溯。如果你的公司已经成立五年了，你的应用和服务已经建立起来了。那时你可能有一个复杂的技术栈，并且你可能有大量的技术债务。实现您需要的那种安全控制比您预先做的要困难得多。

为什么您需要 Kubernetes 安全策略？

当您转移到 Kubernetes 时，一个实质性的区别是您将更多的控制权交给了单个开发团队，让他们在 Kubernetes 中为自己提供基础设施。伴随着额外的权力而来的是责任。突然间，那些开发者可以做各种他们以前不能做的事情；过去，他们必须通过 DevOps 工程师为他们创建 EC2 实例。在 Kubernetes 中—根据配置，他们可以:

运行一个命令，让一个应用程序在集群内部运行
以 root 用户身份运行应用程序
访问主机节点上的文件
访问集群中的秘密
运行易损容器

如果您试图保护和管理您的 Kubernetes 环境，您可能希望阻止他们做这些事情。单个开发团队所拥有的额外能力使得 Kubernetes 的安全性与传统的基础设施平台大相径庭。另一件要记住的事情是，虽然 Kubernetes 是短暂的，但这并不能保护你的应用和服务免受安全风险。

您的 Kubernetes 安全策略应该涵盖哪些内容

您的 Kubernetes 安全策略需要涵盖三个基本要素:

不允许人们做超过他们应该做的事情
不允许可避免的已知错误
按角色划分您的人员和团队

让我们更深入地探讨这些话题。

1。不允许人们做超过他们应该做的事情

从最低权限的原则开始——将访问权限限制为用户完成工作所需的权限。也不仅仅是为了人。最低特权访问也适用于应用程序、系统和进程。以下是如何应用于 Kubernetes 的例子。

没有安全感的能力

当你运行一个 Docker 容器时，你可以传递它的配置信息，这些信息表明它对运行它的机器有什么权限。您可以做的事情之一是向容器添加功能，以提供对主机的更多访问。除非您的应用程序将网络或基线工具作为基础设施的一部分来处理，否则您不需要允许这些不安全的功能。您的普通应用程序不需要任何特殊的权限或功能。然而，Kubernetes 确实使您能够添加这些功能，所以要确保大多数团队在大多数情况下都没有添加这些功能。

权限升级允许

特权提升意味着容器可以提升到拥有更多特权。在容器的安全上下文中，必须设置allowPrivilegeEscalation=false。如果有人利用漏洞逃离容器，这有助于减轻威胁。将其设置为 false 意味着攻击者将无法升级到在运行容器的主机上拥有 root 或管理权限。该容器运行在 Kubernetes 节点上，其他容器甚至不同类型数据的不同应用程序也在该节点上运行，因此您希望确保它只拥有所需的特权，并且不能提升这些特权。

以根权限运行

这是不安全功能和权限提升的结合。禁用以 root 用户身份运行的能力，以便潜在的容器转义具有更少的权限，可以造成更少的损害。如果向容器授予额外的权限，可能会影响主机节点，并可能影响该节点上的其他容器。禁用该功能会增加一层额外的保护，防止容器以 root 用户身份运行。要做到这一点，您可能需要在您的应用程序中做一些重新架构的工作。这是 Kubernetes 安全性的最佳实践。

2。不允许可避免的已知错误

这听起来像是一个容易遵循的安全策略，但是在您开始时很难避免已知的错误。一个有经验的 Kubernetes 工程师可以帮助你避免所有的节点错误或你可能犯的其他错误，但是也有很多开源工具和其他第三方工具可用。这些之所以存在，是因为 Kubernetes 的一名工程师坐下来编写软件，帮助人们避免犯下那些的十大错误。考虑看看这个软件或者请一位 Kubernetes 专家，因为这将为你节省大量的时间和压力。

镜像漏洞

您在 Kubernetes 集群中运行的每个容器都从一个基本映像开始。这个基础映像可以是一个普通的操作系统，比如 Ubuntu 或 Alpine，也可以附带一些额外的软件，比如 Python 或 NodeJS..然后你在上面安装其他东西。您需要确保您的基本映像中的软件以及您在其上安装的东西是最新的，并且没有漏洞。漏洞可能在您部署应用程序时发生，但也可能在以后被发现或披露。您需要不断地评估您的集群中有漏洞的映像。然后，您需要解决这些漏洞，并重建和重新部署您的应用程序和服务，以便它所在的容器映像不包含这些漏洞。

每天都有个新漏洞被披露。有时，这些漏洞存在于已经在您的环境中运行了(非常)长时间的代码中。减轻这种风险的一种方法是尽量减少在容器映像中安装不必要的东西。放入工具来帮助您在容器映像内部进行调试(万一有一天您需要它们)或者在非生产环境中有用的其他工具可能很有诱惑力。然后，当您将同一个映像提升到生产环境中时，您会得到一个包含应用程序运行所不需要的元素的映像，这增加了生产环境中映像漏洞的风险。相反，使用 kubectl debug 之类的命令来启动 (一个临时容器 )与您的工作负载一起进行调试。

3。按角色划分您的人员或团队

Kubernetes 有一个基于角色的访问控制的概念(【RBAC】)。您可以使用基于角色的访问控制向需要与 Kubernetes 交互的人授予特权。当您第一次建立一个集群时，很容易接受 Kubernetes 包含的主要管理角色，并将该角色赋予您的小公司中的所有人，因为它可以帮助您快速移动。不要那样做。

不是所有人都可以自由管理访问，而是使用您自己的集群角色和用户角色来授予特权，使用被认为是安全最佳实践的最小特权模型。授予最少的必要特权。一些容器映像要求它们以 root 用户身份启动，然后放弃权限，这意味着您必须以 root 用户身份运行一段时间，然后确保权限发生变化。确保您在角色的约束下工作，但不要关闭约束。

审计日志与 RBAC 相关，可以通过提供一组按时间顺序排列的集群中的操作序列来帮助您。当您围绕 Kubernetes 构建集群并运行您的团队时，请研究审计日志记录、如何查看这些日志，以及如何对它们进行调优以最大限度地减少干扰。审计日志显示谁在采取措施，以及这些措施与角色的关系，以及您为每个角色启用的访问权限。

支持 Kubernetes 安全策略的开源工具

我们收集跨组织的统计数据，了解他们在 Kubernetes 环境中做对了什么，做错了什么。在整个组织中，我们看到 54%的组织将其一半以上的工作负载开放给权限提升，因此存在安全漏洞。值得看看您在自己的集群中实现了什么，以确保您的工作负载不会受到权限提升的影响。幸运的是，有一些开源工具可以帮助您实施这些 Kubernetes 安全策略。

北极星带有 30 多个基于 Kubernetes 最佳实践的内置检查，并支持自定义策略。使用 Polaris，您可以编写 JSON 模式来运行 Kubernetes 集群中的任何资源，并创建您自己的检查。当您获得了广泛的最佳实践并开始将特定于您组织的策略落实到位时，自定义策略就开始发挥作用了。北极星可以帮助你确保你不允许人们做他们不应该做的事情——这是本帖中概述的第一个 Kubernetes 安全策略。

Nova 提醒您集群中部署的舵图有可用更新。更新通常与修补的安全漏洞或新的可用功能有关，因此 Nova 可以帮助您提高 Kubernetes 的安全状况。冥王星提供已弃用的Kubernetes API的高级警告。随着 Kubernetes 更新了新的特性或改进了的实现选项，Kubernetes APIs 也会随之改变。有时候 API 的弃用和移除会让 Kubernetes 用户大吃一惊；Pluto 帮助您定期检查您的资源和集群中不推荐使用的 API，这些 API 可能会在 Kubernetes 的未来版本中被删除。 Trivy 既有开放的扫描器，又有开放的数据库，它可以在能发现问题的地方寻找安全问题和目标。Trivy 可以扫描的目标包括容器映像、文件系统、Git 存储库(远程)、虚拟机映像、Kubernetes 和 AWS。这些开源工具可以帮助您避免已知的错误，让您的 Kubernetes 集群保持运行。

对于基于角色的访问控制，我们还开发了一个叫做 RBAC 管理器的开源工具。它可以帮助您简化创建集群角色所需编写的代码量，并将新角色绑定到用户或用户组。

实施您的 Kubernetes 安全策略

在单个集群上安装开源项目并使项目保持最新是相当简单的，然而，在数十或数百个集群上这样做更具挑战性。在大型 Kubernetes 环境中，考虑采用治理软件来帮助您从 CI/CD 到生产操作这些 Kubernetes 安全策略。fair winds Insights帮助您提高安全性和合规性风险的可见性，优化成本，并为策略和安全性设置防护栏。

随着 2022 年接近尾声，你如何看待 2023 年的 Kubernetes 安全？我们知道 DevOps 团队对于确保 Kubernetes 的安全至关重要，但是您准备好迎接 2023 年 Kubernetes 安全策略的发展了吗？这三个策略会让你在新的一年里有一个稳固的基础，并且比过去更接近发展战略。

观看网络研讨会Kubernetes 2023 年安全战略立即点播，了解有关 Kubernetes 安全战略、治理和护栏的更多信息。

正确配置的真相将拯救您的 Kubernetes 安全计划

原文：https://www.fairwinds.com/blog/the-truth-about-proper-configuration-will-save-your-kubernetes-security-plan

谈到云原生和 Kubernetes 环境，安全性是现代从业者最关心的问题之一。除了可靠性和效率，Kubernetes 的安全性必须始终放在首位，尤其是考虑到容器化的工作负载在默认情况下是不安全的。希望降低安全风险的企业必须谨慎行事，时刻牢记应用程序如何需要正确的设置才能安全成功地运行。通过这种方式，容器安全性与集群的管理和维护方式直接相关，这种现实与正确的 Kubernetes 配置直接相关。

如果组织没有围绕其 Kubernetes 工作负载建立一套清晰的最佳实践和有效治理，其他关键领域(如性能、成本、可靠性和效率)都会受到负面影响。这些问题都是相互关联的——同样，直接受到配置管理的影响。在 Kubernetes 中，错误配置经常发生，这意味着用户必须对他们的集群进行大量检查，以确保它们以最佳性能运行——可靠、高效和安全。

管理配置

我们最近的 Kubernetes 配置基准测试报告显示，所有组织中还不到一半的组织在这方面有稳固的基础。我们知道运行状况检查是 Kubernetes 安全性的关键，但只有 35%的企业成功地为 90%以上的容器化工作负载配置了活性和就绪性探测。配置验证，也称为基础设施代码(IaC)扫描，提供了一些帮助，但可伸缩性对大多数人来说仍然是个问题。稍后将详细介绍 IaC 扫描…

平台和安全领导者以及 DevOps 团队很容易失去对其 Kubernetes 集群的可见性和控制。这个问题提醒我们需要自动化和旨在加强一致性的策略，提供正确的组织护栏。正确的 Kubernetes 配置对于云本地采用的成功至关重要。在没有 IaC 扫描的情况下识别安全漏洞几乎是一项不可能完成的任务，也是一条通往数字入侵的必经之路。

保护容器

容器化的工作负载非常棒，因为它们本质上是自包含的软件，拥有生产中运行所需的一切。开发和运营团队依靠这一特性使软件的交付更加容易和快速。随着组织越来越适应 Kubernetes 和云原生环境，他们需要意识到自己缺乏经验和可能的疏忽。单个 Kubernetes 工作负载可能需要大量配置，以确保应用程序更加稳定和可伸缩。再加上组织挑战和技术债务，即使是最有知识的 Kubernetes 用户也会承认他们很难避免错误配置。

在所有的 Kubernetes 安全威胁中，人为错误是最大的。当默认配置(看起来对开发人员友好，但实际上并不安全)与人工监管混在一起时，容器的安全性就会受到威胁。虽然 Kubernetes 配置管理有所帮助，但由于其复杂性，它给用户带来了独特的挑战。许多工具可用于容器图像的漏洞扫描，但是正确的配置和监督需要特别注意。从业者可能理解避免部署 Kubernetes 仪表板的需要，但是配置 pod 安全内容或实现 RBAC 也是具有挑战性的领域。

了解 IaC 扫描

回到 IaC 扫描。它指的是使用代码管理和供应基础设施的技术和流程。IaC 扫描帮助 DevOps 团队处理诸如版本控制、同行评审、自动化测试、标记以及持续集成和交付之类的事情。

每个框架都有自己的语法和约定，但是 IaC 扫描通常由资源声明、输入变量、输出值、配置设置和其他参数组成。大多数情况下，IaC 基于 JSON、HCL 或 YAML，包含启动基础架构所需的所有配置:计算、网络、存储、安全、身份访问管理(IAM)等。由于 IaC 扫描使用代码来确定启动和运行资源需要什么，因此它允许自动化和扩展云配置的能力，并具有更好的可重复性。

融合 IaC 和安全性

使用通用、统一的语言在不同的环境和云中调配云资源，开发人员和运营团队可以保持协作，以确保云原生应用的安全。将安全检查直接添加到构建和发布管道中是一个复杂且资源密集的过程。智能编排和有效的 IaC 扫描可以将安全漏洞隔离到与当前漏洞集成的专用管道中。因此，团队可以使用 IaC 在软件生命周期的早期实施云安全，以降低风险并保持法规遵从性。

为了效率而自动化，这种类型的 IaC 安全性通过将安全性“向左”移动并自动化来提高开发人员的生产力和整体效率。工程团队还被授权实施 IaC 安全最佳实践，将安全作为代码，从而在源头形成一个代码化的过程。此外，IaC security 通过直接嵌入开发人员工作流来简化工作流，从而在运行和构建时保持云洞察力。想想 DevSecOps 的原理。它教会了团队如何通过将容器安全嵌入到 DevOps 生命周期中来自动化容器安全。尽管在利用 DevSecOps 实现云安全时仍然存在许多挑战，IaC 仍然使这一切成为可能。

寻找 Fairwinds 见解

Kubernetes 和其他云原生技术可能是新的，但核心业务挑战是相同的。企业需要学习如何加快软件开发速度，同时保持有效的安全实践，这两种实践仍然在 Kubernetes 的世界中争夺同等的地位。

Fairwinds Insights 提供这种水平的专业知识和合作关系。作为 Kubernetes 的安全和治理平台，Insights 为 DevOps 团队提供了一个可扩展性、可靠性、资源效率和安全性的安全网，同时也使开发人员能够更快地创新和交付。然后，DevOps 团队可以防止整个 CI/CD 管道中的错误配置，并向开发人员提供补救建议，无需人工干预。

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

借助 Fairwinds Insights，管理整个企业中的多个集群和团队变得更加容易，而且在许多情况下是可能的，因为它将开源工具操作到一个平台中，以实现更好的监督和管理。

点击这里阅读我们最新的关于 Kubernetes 配置的 WP。

点击这里阅读我们最新的关于 Kubernetes 配置的 WP。

简化 Kubernetes 多集群管理的三个步骤

原文：https://www.fairwinds.com/blog/three-steps-to-streamlining-kubernetes-multi-cluster-management

Kubernetes 作为一项技术，使组织能够跨不同的云基础设施和分布大规模运行容器化的应用程序。it 部门(目前)无法做到的是以合规、可靠的方式集中管理大量现成的集群。这一现实使得跨不同集群交付治理和标准化变得困难，更不用说抑制创新了。但是，随着新集群的不断增加，找到简化多集群管理的新方法将成为云成功的金戒指。

多集群管理

有效的多集群管理意味着减少两件事—冗余工作和运营开销。它还包括建立正确的框架来发展您现有的治理模型，以减少跨集群生命周期管理中的开销和冗余工作。但是，如果您在一个集群数量不断增加的企业环境中运营，所有集群都是独立管理的，很少有统一性，简化这一管理流程的复杂性可能会成为企业成功的巨大障碍。

随着 Kubernetes 集群数量的增长，从业者被迫花费越来越多的时间进行管理，而用于生产的时间越来越少。他们需要的是一种在发现不同集群时集中查看、管理和整合这些集群的方法，以便能够适当地优化资源和处理问题，而不会浪费宝贵的时间。

寻找更多提示？阅读我们的 Kubernetes 最佳实践白皮书！

简化集群的步骤

如果您组织中的团队正在努力应对多集群 Kubernetes，不要惊慌——您并不孤单。这里有三个基本步骤，您可以立即采取，以减少一次管理多个集群所花费的时间和资源。

1。采用零信任方法。这种安全模型假设网络中以及网络之间的所有系统、服务和用户都不会自动受到信任并被授予访问权限。Kubernetes 包括实现对机群中每个集群的这种级别的控制访问所需的所有挂钩，利用了诸如认证、授权、加密和配置验证等技术。对 Kubernetes 环境应用零信任原则意味着控制对 API 服务器的访问，这是每个集群的 Kubernetes 控制平面的核心。因为 API 调用用于查询名称空间、pod 和配置图等对象，所以控制对 API 使用的访问是保护您的工作负载和实现 Kubernetes 零信任的关键。

零信任最佳实践允许组织创建一个安全的环境，在这个环境中，所有单个元素都得到正确配置和协调。当这种安全模式在多集群环境中实施时，可以大规模运行多个集群，而且风险更低。

2。启用多集群部署。在多云、多集群 Kubernetes 环境中，频繁的应用程序和基础架构更新是常态。团队经常需要同时部署到多个 Kubernetes 集群，这使得几乎不可能避免漂移，这是集群之间的不一致和错误配置，通常会导致停机或更糟。

由于 GitOps 可以通过将熟悉的工具引入基础设施管理和持续部署(CD)来帮助解决这些挑战，因此它经常被寻求更好的整体标准化、安全性和工作效率的组织所使用。当对存储库进行更改时，代码会从您的集群中回滚，以快速可靠地实现部署自动化。尽管可以使用标准的 Git 工具实现 GitOps 工作流，但要享受全部好处，还需要额外的工具，包括确认所需状态维护的能力。

被动或短期调整可能会迷失在集群的海洋中。这里有一些工具可以帮助您发现车队中的意外偏差。

Fairwinds Polaris 提供集群内工作负载的仪表板视图，以及它们与最佳实践的关系。
Fairwinds Goldilocks 通过在推荐模式下使用垂直 pod-autoscaler，帮助您“恰到好处”地获得 Pod 资源请求和限制，在仪表板中可视化。
Fairwinds RBAC Lookup 是一个命令行工具，可以方便地找到与用户、组或向 Kubernetes 认证的服务帐户相关的角色。

3。简化生命周期管理。正如我们所知，Kubernetes 环境随着时间的推移而增长，许多云服务，如亚马逊 EKS 和 Azure AKS，提供了有益的覆盖。尽管在本质上是相似的，但是所有这些类型的 Kubernetes 都有不同的管理工具，这意味着在每个环境中部署和更新集群可能看起来非常不同。

这里的最佳解决方案是围绕单一类型的 Kubernetes 实现组织标准化，这种 Kubernetes 可以对整个车队进行生命周期管理。也就是说，这个目标很难实现，因为现有的工具很少能同时涵盖流行的 Kubernetes 发行版和云服务。简化生命周期管理的最佳实践是找到一家 SaaS 服务提供商，如 Fairwinds Insights 、，它允许用户从单一控制台部署、管理和升级所有集群，这是一个提高可见性、可靠性和一致性的仪表板。

费尔温德见解

如今，组织需要跨集群安装和配置多种工具，以确保安全性、资源优化和可靠性检查。如果没有对正在发生的事情的集中了解，时间和资源就会被浪费。这就是我们创建 Kubernetes 治理平台fair winds Insights的原因。

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

Insights 将优秀的开源工具(包括这里描述的工具)的结果聚集到一个视图中，这允许您跨多个集群评估和实施您的标准。Insights 使用 Polaris 和开放策略代理为您的部分或全部集群提供集中策略管理。

NSA 强化指南:Fairwinds Insights 根除不良 Pod 安全性的三种方式

原文：https://www.fairwinds.com/blog/three-ways-fairwinds-insights-can-root-out-poor-pod-security

美国国家安全局发布了一套严格的准则来强化您的 Kubernetes 集群。这份 66 页的文档概述了一种强大的深度防御方法，以最大限度地降低违规的可能性，并确保在攻击者设法渗透到您的 Kubernetes 集群的情况下，爆炸半径保持尽可能小。但更棘手的部分是学习如何这些准则，现在被认为是行业最佳实践的黄金标准，可以通过使用类似fair winds Insights的 SaaS 解决方案、开源工具和其他云原生技术来实现。

这个致力于 pod 安全的博客开启了一个由五部分组成的系列，重点关注新的 NSA Kubernetes 强化指南，包括如何在任何运行容器化工作负载的组织中优化网络隔离、身份验证、授权、审计日志记录和威胁检测等关键安全领域。

作为遵守 NSA 最佳实践的实用指南，本博客系列将讨论从业者如何利用 Fairwinds Insights，结合其他同类最佳的商业和开源软件，有效且经济地遵守 NSA 的严格建议。

想要立刻得到所有美国国家安全局的建议？下载我们最新的白皮书，满足 NSA Kubernetes 强化准则的步骤。

围绕 pod 安全，NSA 有哪些建议？

NSA:以非根用户身份使用构建的容器运行应用。 具体来说，NSA 建议使用为非根用户运行应用程序而构建的容器。默认情况下，许多容器服务作为特权根用户运行，这意味着应用程序经常作为根用户在容器内执行，尽管不需要特权执行。通过使用非根容器或无根容器引擎来防止根执行限制了容器危害的影响。

Fairwinds Insights 与北极星集成，后者是一个用于验证 Kubernetes 配置的流行开源项目。这个开源工具带有一个内置的检查，用于检测允许以 root 用户身份运行的容器。通过采用北极星 via Fairwinds Insights，用户可以精确地看到集群中的哪些工作负载有权以 root 用户身份运行。此外，您可以使用 Insights 在 CI/CD 管道中运行相同的策略，确保基础架构代码更改不会引入能够以 root 身份运行的新资源。

一旦您锁定了在所有适用工作负载中以 root 用户身份运行的能力，我们建议您在 Insights 许可控制器中打开 Polaris，它可以为以 root 用户身份运行的工作负载提供最强的防御。

对于真正需要 root 访问权限的工作负载，可以配置 Insights 以允许特定豁免。为此，我们强烈建议使用允许列表，并在默认情况下拒绝以 root 用户身份运行。您可以根据名称空间、标签、注释、集群名称等来调整洞察力以做出决策。

NSA:用不可变的文件系统运行容器。 默认情况下，容器被允许在它们自己的上下文中不受限制地执行。在容器中获得执行权限的攻击者可以在容器中创建文件、下载脚本和修改应用程序。Kubernetes 可以锁定容器的文件系统，从而防止许多利用后的活动。

同样，Polaris 通过对可写文件系统的内置检查解决了这一问题，该检查集成到 Fairwinds Insights 中，其方式与上述对以 root 身份运行的容器的检查相同。在 Insights 集群内代理中启用这一开源工具，用户可以检测哪些工作负载当前能够写入本地文件系统，哪些已经锁定。Insights CI/CD 插件还有助于防止任何允许工作负载修改文件系统的代码更改。

准入控制器功能提供了强有力的防御，防止违反此策略的任何新资源被添加到集群中。如果某些特定的工作负载确实需要修改文件系统的能力，Insights 应该配置一个允许列表，默认情况下拒绝可写文件系统。这些允许列表可以基于名称空间、标签、注释、集群名称等等来构建。

NSA:扫描集装箱图像寻找可能的漏洞。 除了使用可信存储库来构建容器，图像扫描也是确保部署的容器安全的关键。在整个容器构建工作流程中，应扫描图像以识别已知的漏洞。

Insights 还与 Trivy 集成，这是另一个扫描所有容器图像以发现已知漏洞的开源工具。Trivy 检查图像，将其与大型 CVE 数据库进行比较，并按照严重程度列出所有问题。Insights 在构建时(即 CI/CD 期间)和运行时扫描容器。这一点很重要，因为通常在映像被扫描并部署到您的环境后会宣布，这意味着成功通过 CI 和准入步骤的容器现在正在您的集群中运行，并且已知易受攻击。Insights Agent 可以检测这些情况，并向您的安全和运营团队发出警报。

NSA 还建议实施一套“可信存储库”,以防止工作负载部署不可信的容器。Fairwinds Insights 与 OPA 集成，允许用户创建自定义策略，精确指定允许哪些存储库。这些 OPA 策略可在 CI/CD 和 Insights 准入控制器中实施，并可用于使用集群内代理扫描所有现有资源的违规情况。

点击这里阅读我们所有的开源项目！

免费使用 Fairwinds 洞见

不要相信我们的话——今天就使用的见解 ,了解您的组织如何以更少的恶化和总体成本达到 pod 安全的黄金标准。免费提供！点击此处了解详情。

应用基础设施的二级监控

原文：https://www.fairwinds.com/blog/tier-2-monitoring

只要有软件在服务器上运行，就有某种监控来确保它在运行。即使最初的版本只是从别人的计算机上运行的 ping 命令。问题是，即使是早期版本的监控都是关于反应能力的。

监控就是检查房子是否着火。如果它没着火，没人会太担心。当它着火的时候，让我们用所有正确的方法监控它，知道火是从哪里开始的，如何扑灭，以及将来在哪里重建房子。也许我们知道下一步我们不应该把窗帘直接放在煤气炉上面。但仅此而已。我们看到房子在燃烧，我们做出了反应，并因火灾而转向。

这里的比喻应该有点可笑，因为我们今天思考监控的方式不仅仅是有点可笑。如果监控更加主动会怎么样？如果我们可以看到，当房子没有着火，门没有锁，我们到处都是易燃材料，我们所有的火警都在屋顶上，所以它们不会响，直到整个事情将要坍塌。

用具体的术语来说，远离隐喻…监控我们的基础设施是否正常运行，我们的应用程序和数据库是否响应请求，这一点非常重要。让我们不要停止做那件事。但是现在是时候让二级监控成为常态了。

在 2 级监控中，我们应该知道:

我们的部署有多健康？
我们在房子里放易燃的东西吗？
我们是否积极运行安全检查
我们的门窗锁了吗？
有人能从邻居家溜进来吗？
我们是否在检查我们使用的实例大小是否合适
当我们的居民是成年人时，我们有没有放婴儿床？
我们为 2 口之家安装了 12 间浴室吗？
我们是否在对照已知 CVE 列表检查我们正在运行的软件，
房子还在使用被召回的煤气炉吗？
我们使用的是用已知密码打开的数字门锁吗？

大多数人回避 2 级监控的原因是，收集所有这些数据需要太多难以安装的工具，并且没有查看信息的单一仪表板。

我们已经用 Fairwinds Insights 解决了这个问题。立即免费使用亲自探索 2 级监控。

12 大 Kubernetes 资源:学习并保持更新

原文：https://www.fairwinds.com/blog/top-12-kubernetes-resources

云原生社区的蓬勃发展与 Kubernetes 有很大关系。作为一个开源社区，成员们致力于该主题的教育和支持。

无论您的目标是从整体上了解更多的技术，了解最新的新闻，还是贡献您作为从业者的智慧，都有大量的机会访问内容并参与其中。但是并不是每个人都在相同的地方以相同的方式学习。

被所有的选择淹没了？我们提供了 12 大 Kubernetes 资源的完整列表，以帮助您的旅程。无论是开车回家时听的播客，还是让你开怀大笑的社交媒体帖子，甚至是将 Kubernetes 离线带入现实世界，我们都可以满足你的需求。

听

来自 Google 的每周播客，介绍来自 Kubernetes 社区的嘉宾观点，以及该领域的新闻和更新。

对于那些对高级策略感兴趣的人，本播客由 Kubernetes 社区(DoKC)上的数据指导，“一个由好奇且经验丰富的操作员和工程师组成的开放管理和自组织的团体，他们关心在 Kubernetes 上运行数据密集型工作负载。”奖金，每周有 2-3 个播客发布。

这个标题可爱的播客邀请了各种各样的嘉宾来关注 Kubernetes，但也邀请了创建和使用它的人。

拥有 35，000 名成员的 Software Engineering 是整个社交音频应用程序中最大的技术小组之一，每周三下午 5 点加入并收听现场对话，如最近的“Kubernetes 与 CALICO 联网”！

看

虽然有很多专门针对 Kubernetes 教育的在线课程，但本课程免费向用户提供 Kubernetes 基础知识。已经有 56，362 名学生利用了这一优势，你也可以利用这一优势。

如果你已经在 GitHub 呆了大半天了，为什么还要离开呢？和我们这里的列表一样，这个 Kubernetes 培训材料的汇编由 Ramit Surana 定期更新和添加，有几十个针对初学者和专家的深入文档的链接。

不认为 Instagram 是 Kubernetes 知识的来源？再想想- @CloudComputingHub 最近报道了一些概念，比如亚马逊 ECS 的容器和编排工具的好处，这些都在 DevSecOps、SRE 和云的焦点主题下。

Kubernetes Twitter 是一个非常活跃的空间——尽管这里可以包括无数其他人,@ learnk8s(Kubernetes 咨询和教育公司 learn k8s 的 Twitter 账号，不到 280 个字符)，Kelsey Hightower (Google 的多产工程师、开发者倡导者和演讲者，通常专注于 OSS 和 Kube)和编译主题云计算(一个关于云计算和相关技术的公司、评论员和趋势故事的大杂烩)值得您关注。

从事

结合实用建议、提问/开始讨论的机会以及大量幽默，这些子主题持续活跃，每天都有来自(合计)31.25 万订户的数十条帖子。

这些 Discord 服务器，每个都有 1000 多名成员，定期活跃在围绕最佳实践、Kubernetes 新闻和连接从业者的讨论中，无论是专业还是个人。

像许多 Slack workspaces 一样，这里有几乎所有事情的频道——在 CNCF 的#events 频道关注即将到来的会议；在 DevOpsChat 的#介绍中与 DevOps、SRE、云、平台、工程和更多空间的同事联系；并在我们的 OSS 社区中讨论 Fairwinds OSS 项目。

厌倦了看屏幕？不要担心——如果你正在寻找一群行业同事、有类似兴趣的技术人员，或者任何其他同样关注 Kubernetes & technology 的人，MeetUp 在世界各地都有活动。Cloud Native London 每月聚会一次，而 DevOps NYC & Kubernetes Boston 在过去一年举办了多次在线活动后，正在慢慢过渡回现场活动-看看您附近的团体吧！

如果您对 Kubernetes 在安全性、成本优化和护栏方面来之不易的专业知识感兴趣，您还可以查看 Fairwinds 资源库，我们在其中提供了多种类型的内容，包括:

2023 年你需要的四大 Kubernetes 开源工具

原文：https://www.fairwinds.com/blog/top-4-kubernetes-open-source-tools-you-need-in-2023

认为 2022 年即将过去，而我们中的许多人正在为 2023 年的下一步做准备，这是很疯狂的。新年快到了，是时候考虑一下 2023 年你需要哪些 Kubernetes 开源工具了。

Gartner 预测，到 2027 年，超过 50%的企业将使用行业云平台来加速其业务计划。随着我们迈向 2023 年，我们将通过采用云原生技术、容器和 Kubernetes 来体验这种加速。对于那些采用 Kubernetes(或加速其使用)的团队，有四个开源工具可以帮助您创建和管理治理策略，使您的集群更稳定、更安全、更高效。

北极星:开源策略引擎

北极星是 Kubernetes 的一个开源策略引擎，安装简单，可以作为仪表板、命令行界面(CLI)工具或准入控制器运行。北极星可以给你显示一个分数，这个分数与通过和未通过检查的数量有关。您可以快速查看错误、可能对集群健康有危险的事情、警告和通过检查。Polaris 会根据 Kubernetes 的最佳实践给你一个总分和相应的等级。

Cluster overview in Polaris showing checks and cluster health

你可以查看不同的支票。例如，Polaris 表明您应该为您的部署制定一个 pod 中断预算。如果您不确定这是什么意思，您可以单击问号并转到文档页面获取更多信息。当您点击时，您可以看到缺少分销预算描述的窗格。

我们在 Polaris 中内置了许多这样的检查，记录在可靠性、效率和安全性下。这些检查都是 Kubernetes 的最佳实践，Fairwinds 团队已经学习、遵循了这些实践，现在向我们所有的客户推荐这些实践。您还可以向 Polaris 添加自定义检查，以查找与您的环境或其他组织需求相关的特定内容。

在配置部分，您可以看到检查列表及其严重程度。

有三种不同的级别可供选择:

忽略:这些甚至不会显示在仪表板上
警告:在仪表板中显示为警告
危险:这些也显示在仪表板上，但也可以被我们的验证准入网络挂钩阻止

一旦你在 Polaris 中完成了检查，修复了所有的警告并加入了豁免，你就可以开始阻止违反这些规则的东西进入你的集群。您可以将它们标记为“危险”，并在准入请求级别阻止它们。查看完整教程。

自定义策略示例:图像注册表的自定义检查。

如果您想要求所有图像都来自特定的注册表列表，您可以在 Polaris 中编写一个策略来强制执行。Polaris 策略是用 JSON 模式编写的。如果你进入 Polaris 库，你可以看到所有的默认检查都在 YAML 文件的 checks 文件夹中。如果您查看容器的 image 属性，您可以指出它必须匹配这些字符串模式匹配中的任何一个。如果其中任何一项不匹配，就会在 Polaris 仪表盘上弹出警告。

北极星:吊舱破坏预算中的豁免

cert manager 的 pod 中断预算就是一个很好的例子。证书管理器是此群集中的单个 pod 控制器。它不需要运行多次，因为它是作为协调循环运行的。如果它下降或消失了一点点，它会回来处理它的业务。您可以通过转到“控制器名称”并设置规则来为 cert manager 添加豁免，使其不受缺少 pod 中断预算规则的约束。保存后，重新运行引用该值文件的 Helm 安装程序，并在该名称空间中更新 Polaris。那么证书管理器将不再触发北极星警告。

金发女孩:确定资源需求和限制

Polaris 发送关于设置资源请求和限制的报告。使用 Kubernetes 的每个人都意识到需要遵循最佳实践来设置 CPU、内存和工作负载的资源请求和限制。然而，这样做可能是一个挑战，因为要正确地做它，你需要大量的信息，包括指标(在合理的时间跨度内收集的)、你的高低点的流量信息，以及更多的数据点。这需要手动完成大量工作，这也是 Fairwinds 创造了金发女孩来帮你完成这些工作的原因。

开源工具 Goldilocks 通过设置适当的 CPU/内存来帮助用户优化 Kubernetes 的资源。它需要你安装一个公制服务器和垂直 Pod 自动缩放器，这两个都是标配。(大多数人已经在他们的集群中安装了它们。)垂直 Pod 自动缩放器有三个组件:推荐器、更新器和准入控制器。您可以使用他们的舵图安装公制服务器，以便安装垂直 Pod 自动缩放器；我们也有 VPA 的舵手图，因为没有官方的。默认情况下，我们的舵图只安装推荐器和更新器。

建议程序从度量服务器获取度量，然后使用这些度量向 VPA 对象提出建议，这些对象是为您附加到 VPA 的部署创建的。Goldilocks 使用这些价值来提出建议，或者根据 VPA 向你展示这些价值。你可以在这里阅读调整 Kubernetes 工作负载的完整教程。

如何将金发女孩与您的工作负载联系起来

如果您希望 Goldilocks 为您的工作负载创建 VPA 对象，您需要用一个特定的标签来标记名称空间。如果您从一个纯普通的安装开始，有一小段文本告诉您需要运行哪个命令来手动标记您的名称空间。一旦标记了名称空间，就需要刷新仪表板。这就是向 Goldilocks 添加工作负载是多么容易。现在部署在该演示命名空间中的所有内容都将被提取，并有一个与之关联的 VPA。

使用垂直 Pod 自动缩放器，如果您安装了更新程序，更新程序可以根据来自推荐者的信息垂直缩放您的 Pod 上的资源。如果将这些设置为禁用，它不会自动为您缩放。您可以向您的名称空间传递另一个标签，以将更新模式设置为 auto。

建议

来自推荐者的推荐在我们如何推荐 Kubernetes 的资源限制和 Goldilocks 中的请求方面起着作用。类似于你在北极星中看到的，金发女孩感觉到有一个名称空间。基于此，它向您展示:

Namespace details - CPU and memory requests and limits

您可以看到当前的设置，以及对于保证服务质量和突发服务质量的建议。对于这些打印出一些 YAML，然后你可以复制并粘贴到你的舵图表。

Goldilocks 包括一个术语表，解释了有保证的服务质量、可突发的服务质量之间的区别，以及 Kubernetes 在面临资源压力时如何处理您的工作负载。Goldilocks 建议是设置资源请求和限制的起点，您可以根据它们在流量模式方面的工作方式进行测试和调整。

Nova:查找过时或废弃的头盔图

Nova 帮你找到过时或弃用的舵图。它会扫描您的集群以获取 Helm 图表的更新，如果您没有使用 Helm，还会扫描容器图像。这对于跟踪您希望尽可能保持最新的加载项、证书管理器和外部 DNS 非常有用。有许多安全修补程序和稳定性修补程序需要保持更新，以维护集群的安全性和稳定性。如果没有 Nova 这样的工具，跟踪这一点可能会非常困难。

Nova 使用起来很简单。默认情况下，Nova 将以 JSON 格式输出。如果你传递了 format table 标志，它会给你一个小表，显示你的版本名图表，名称，命名空间，和 Helm 版本。

Nova report of Helm charts

如果你看上面的截图，你可以看到 Nova 给你的信息:

Install 是集群中的图表版本
最新版本是 Nova 已知的最新图表版本
Old 是一个布尔值，表示您的版本是否是旧的
弃用是一个标志，可以设置为弃用，以指示将来不应使用舵图

Nova 通过拉动工件中枢来获得关于图表的不同版本以及它们是否被否决的信息。要记住的一件事是，你可以分叉图表，有时这些分叉图表会出现在工件中心。Nova 无法看到您的版本来自哪个上游图表。记住这一点很重要。Fairwinds 做了一些匹配和评分，试图减轻这种情况，但 Nova 引用的可能是不同于您正在使用的分叉。

你可以在这里阅读一篇完整 Nova 教程。

Nova 扫描集装箱图像

Nova 还可以找到并扫描集群中运行的容器。扫描将向您显示当前(已安装)的版本，无论它是旧的，最新的主要版本，最新的次要版本，以及最新的补丁版本。这为您提供了有关更新内容的更多信息。

Nova container images report

例如，您可能不担心将您的附加组件更新到最新的补丁版本，甚至是最新的次要版本。使用 Nova，您可以线性或精细地决定如何处理插件修补和升级。Nova 还提供了更多的配置选项供您尝试。

Pluto:查找废弃的资源

当我们在 Kubernetes 1.16 升级中遇到挑战时，Fairwinds 的团队编写了冥王星。Pluto 可以帮助您在 Kubernetes 集群中找到不推荐的和删除的 API 版本。1.16 中删除了所有旧的部署扩展 V1、Beta1、API 版本，因此，如果您周围有许多旧的 YAML，或者您正在部署旧的舵图，其中包含不赞成使用的 API 版本，那么更新这些版本将非常困难。我们需要一种方法来告诉我们的客户他们正在使用的东西已经被弃用或删除。

Kubernetes API 服务器自动将 API 版本从一个版本转换到下一个版本。这使得就地升级变得容易，但是在完成升级后，它会破坏您部署到集群的能力。我们希望我们的客户明白，与其简单地阻止他们更新集群，

Pluto 是另一个 CLI 工具，所以当我们运行 Pluto 时，它会给出一个表格输出，其中包括:

对象列表
它们是什么种类的
版本
API 版本
替换它的 API 版本
它是否已被删除
是否已被弃用

观看冥王星的视频概述(附文字稿)。 Pluto table output showing API versions

冥王星探测 API 资源命令

感谢一位社区贡献者，我们现在有了 detect API resources 命令，该命令查找 Kubernetes 添加到一些资源中的注释，该注释包含上次应用的 YAML 的字符串副本。如果将 CTL 应用于 YAMLs，那么注释就会被设置。Pluto 可以检测您不赞成使用的 API 版本，您可以在 CI 中使用它来阻止构建或使构建失败，如果人们试图部署不赞成使用或删除的东西，

Kubernetes 为您的云原生之旅提供开源工具

如果您运行所有这四个 Kubernetes 开源工具，修复它们找到的所有东西，并遵循它们提供的建议，您应该在 Kubernetes 之旅中处于一个更好的位置。如果你不想安装所有这些工具，自己运行它们，编写自己的 CI/CD 代码，部署到你所有的集群中，fair winds Insights就是我们的商业 SaaS 平台。它结合了这四个开源工具以及更多的工具，并添加了更多的功能，将操作项报告到一个仪表板中。

你可以免费使用 Fairwinds Insights，永远在这里了解更多。

洞察可以帮助您将 Kubernetes 的安全性、成本、合规性和防护措施落实到位，以确保 Kubernetes 为您的组织正常工作。

观看网上研讨会点播，获得关于这四个 Kubernetes 开源工具如何工作的演示。

发现你(可能)犯的五大 Kubernetes 安全错误

原文：https://www.fairwinds.com/blog/top-5-kubernetes-security-mistakes

毫不夸张地说，云原生技术正在彻底改变组织开发和交付应用的方式。随着组织越来越多地采用微服务和容器，许多组织转向 Kubernetes 进行容器编排。Kubernetes 控制云应用和微服务的资源分配和流量管理，为全天候运行应用提供关键能力。K8s 支持自动扩展、自动恢复等功能。虽然 Kubernetes 的好处令人印象深刻，但许多组织都在为五个常见的 Kubernetes 安全错误而努力。你的组织知道吗？

Kubernetes 对组织的挑战

Kubernetes 很复杂，在团队对他们的 Kubernetes 环境获得信心之前，需要大量的学习和实践。如果你刚刚起步，你可能缺乏成功启动安全 Kubernetes 环境所必需的工具、流程和经验。不仅如此，在开发、运营和安全团队中必须进行相当大的文化变革，因为 Kubernetes 和 containers 提供了一种部署应用程序的新方法。这些变化意味着，当组织采用微服务、容器和 Kubernetes 来开发和部署应用程序时，运营和安全团队会质疑应用程序和数据是否安全。

云环境中的安全性

在云原生模型中，许多传统的安全工具和流程不再是正确的选择，同时，容器会产生新的盲点和攻击面。获得您需要的跨容器和集群的可见性带来了额外的挑战。在新的范例中，开发人员可能会发现现在有必要对一些新的安全挑战负责，这是大多数开发人员不习惯并且可能不愿意承担的角色。

那么大多数组织最常犯的 Kubernetes 安全错误是什么呢？

授予对主机节点的访问权限— 授予应用程序管理员级别的访问权限很容易，但这会增加您遭受攻击的风险。
假设运营团队与安全团队保持一致— Kubernetes 提供了许多配置选项，这些选项提供了安全团队需要理解的大量灵活性 — 和复杂性 — 。
运行具有已知漏洞的容器— Kubernetes 使用容器来交付应用程序，但许多团队并不知道这些容器中可能暴露的已知漏洞。
期望使用本地控件实现默认安全— 虽然 Kubernetes 确实提供了本地安全特性，但许多特性在默认情况下并未启用。

这五个错误可以通过在开发和生产环境中持续扫描集群来避免。识别他们是成功的一半。学习如何识别错误并补救它们。要开始提高 Kubernetes 的安全性，请详细了解您可能犯的五大错误，并获取修复它们所需的信息。阅读白皮书。

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

为什么是现在，为什么是自由？试试 Fairwinds Insights，Kubernetes Governance Today

原文：https://www.fairwinds.com/blog/try-fairwinds-insights-kubernetes-governance-free-tier

我们很高兴从今年开始提供免费的 Kubernetes 治理软件fair winds Insights。许多组织刚刚开始使用 K8s，而其他组织开始扩大 Kubernetes 的使用规模，一些组织在采用 Kube 方面已经相当成熟。当您刚刚起步时，您仍在学习如何确保云原生和 Kubernetes 的采用有助于您实现业务和技术目标。同时，您希望确保您的集群能够满足您的开发工作负载的需求，而不会让您的组织面临风险或浪费云资源。

重要的是将 Kubernetes guardrails 放在适当的位置，以确保开发人员可以更快地发布云原生应用程序，而不用担心犯与安全性、资源利用和可靠性相关的错误。免费的洞察层非常适合刚刚起步的团队，以及小团队和个人用户。

SaaS 平台中的 Kubernetes 治理

Insights 是一个易于使用的 SaaS 平台。免费层是 Fairwinds Insights 软件的全功能版本，为多达 20 个节点、两个群集和一个存储库的环境提供可见性和控制。这一层还包括不限用户数量的访问和 30 天的成本指标保留。

每个 Insights 用户都可以将现有的 Fairwinds 开源工具无缝连接到免费层，包括:

北极星，一个用于 Kubernetes 的开源策略引擎，它验证并修复 Kubernetes 资源，以确保您遵循配置最佳实践
Nova ，这是一个开源项目，可以发现在您的集群中运行的过时或不推荐的掌舵图，以及过时的容器图像
布鲁托，一个开源实用程序，帮助用户在他们的代码库中找到弃用的 Kubernetes API versions和 Helm releases

用户还可以在注册免费帐户的几分钟内激活诸如基础设施代码扫描、自动化售票和集装箱成本分摊等功能。免费层包括 Fairwinds Insights 平台中的所有功能，因此所有用户都可以充分利用该平台，并开始在其 Kubernetes 环境中围绕安全性、成本和合规性设置防护栏。

这些护栏是我们 Kubernetes 治理平台的一部分，帮助平台工程团队管理与多租户集群相关的复杂性。使用 Fairwinds Insights，平台工程师可以在开发过程的每个阶段应用这些护栏。自由层使平台工程师能够轻松实现最佳实践的自动化，并培养一种服务所有权和成本规避的文化。新的洞察分级定价使他们能够以对其组织有意义的定价水平完成所有这些工作，而不会减慢应用团队的速度。

授权开源社区

Fairwinds 继续向开源社区贡献项目和代码，并将其 Insights 平台与其他开源工具相集成，为用户提供最佳体验。基于维护和优化 Kubernetes 环境的经验开发工具是 Fairwinds 公司的一个重要组成部分。

向云原生社区提供免费的 Fairwinds Insights 是我们的自然发展，因为自 2015 年成立以来，我们一直在构建工具和提供服务，以帮助组织采用云原生技术和 Kubernetes。如今，这些组织(以及更多组织)正在成长，需要能够确保他们能够了解他们的 Kubernetes 集群，并自动确保它们得到一致的部署。

Fairwinds 首席执行官 Bill Ledingham 表示:“对于整个云原生社区而言，我们帮助企业以始终如一地应用 Kubernetes 最佳实践和支持服务所有权的方式实施同类最佳开源技术非常重要。“通过提供免费层，团队可以在 Kubernetes 之旅中受益于 Fairwinds Insights 的广泛功能。”

今天就试试 Fairwinds Insights 吧——在这里注册并挑选免费版本。它非常适合非常小的团队和个人用户，但是您也可以使用它来体验一下软件的外观，即使您的组织要大得多。您无需输入信用卡即可开始使用，因此无需记得回来取消订阅。如果您超出了免费层的限制，但希望继续使用它，请检查团队级别，这对单一产品团队和中型组织来说是非常棒的。

注册后，您将被引导完成简单的安装过程。您可以设置松弛集成并立即创建您的第一个 Kubernetes 治理策略，看看它是如何工作的。我们还有一个 Fairwinds 社区 Slack 群组，在这里您可以提出问题并从我们的团队和社区获得答案。我们期待您加入该社区，帮助云原生社区共同成长。

在运行 Kubernetes 时理解文化和授权的关键性质

原文：https://www.fairwinds.com/blog/understanding-the-critical-nature-of-culture-and-enablement-when-running-kubernetes

谈到 Kubernetes 服务所有权，有很多话要说。一旦您的组织理解了全面服务所有权的最终目标，正如最近的文章中所概述的，就有可能建立保持软件开发平稳运行且没有延迟所需的健壮的【安全性】和责任。

但是为了涵盖 Kubernetes 服务所有权的所有关键基础，了解一点文化和支持是很重要的。更具体地说，这种向更具协作性和更有效所有权的转变如何在任何组织中形成。您如何启用它？同样重要的是— 您为什么要关心？

实现的方式和原因

更大的开发者独立性是实现更好的服务所有权的主要原因之一。当他们拥有了这一块拼图，以及部署、运营和监控他们的堆栈时，创新和安全性的许多障碍都消失了。云原生环境的弹性允许开发人员轻松管理其基础架构，而无需依赖传统的运营团队。

对基础设施、计算能力和服务器资源的轻松访问增强了开发人员的能力，使他们能够使用各种工具来配置基础设施和大规模运行服务器。开发人员可以更有效地配置部署环境，同时还可以使用 Docker 和 Helm charts 打包、维护和配置微服务。

有效服务所有权的另一个目标是确保不同的团队能够很好地合作。运营团队为开发和 DevOps 人员提供足够的关于他们的应用程序如何运行的上下文，以便他们可以在不损失速度的情况下获得成功，保持快速的开发和部署速度。当团队像这样一起工作来构建、部署和运行他们的应用程序和服务时，他们有更大的自主权，较少移交给其他部门。

这种转变创造了一种完整的体验，通过这种体验，客户发现他们与拥有他们编码的软件的商业价值的组织有了更密切的关系。这种关系有助于防止各种问题，主要是因为团队更好地了解客户想要什么和需要什么。

文化的重要性

在当今以云为先的世界中，这种变化——或者说团队所有权的转移——很大程度上是文化上的。从定义上来说，文化变化缓慢，并且总是伴随着某些挑战。Kubernetes 全服务所有权也不例外。当将范式从“运营拥有一切”转变为“运营支持服务所有权”时，执行团队的组织支持对于推进这种转变是必要的。打破孤岛已经很难了，这意味着如果没有领导来宣传新“所有权”的优势，它就不太可能在组织中扎根。

当开发团队感觉得到支持并有权为他们自己的自助服务模型选择正确的工具时，他们通常是成功的——当他们能够看到他们的应用程序并成功运行它们时。但是这种文化转变不仅仅是关于开发团队的。运营人员也在努力应对一致性的挑战。对他们来说，成功意味着拥有多集群可见性和集成工具，以向开发人员提供反馈。

正确的问题

围绕共享工具创建工作流可以帮助组织找到这种级别的一致性，并增强跨团队的协作。更高的一致性降低了复杂性，提高了生产率，并降低了运行 Kubernetes 平台的总成本。

你学会如何简化 Kubernetes 混沌了吗？

为了全面了解您的 Kubernetes 环境，您需要提出正确的问题:

代码部署在哪里？
默认的云设置是什么？
开发人员了解正在部署的每一部分吗？
开发人员了解每个底层部分是如何处理特定的安全状态的吗？

顺风解决方案

fair winds Insights通过降低复杂性和实现全方位服务所有权，统一开发、安全和运营。为了帮助团队克服这些固有的文化挑战并接受这种新模型，Insights 促进开发团队拥有安全性和配置。Insights 平台还通过允许服务所有者使用最佳实践指南进行配置来提高可靠性，这是一种发现 Kubernetes 所有权持续改进的可靠方法。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

关于 Pluto 的更新，以及这个开源项目如何识别 Kubernetes 1.22 中被否决的 API

原文：https://www.fairwinds.com/blog/update-on-pluto-and-how-this-open-source-project-can-identify-deprecated-apis-in-kubernetes-1.22

在 Fairwinds，我们依靠我们的开源项目来帮助客户和我们的社区为他们的组织构建合适的 Kubernetes 架构。我们最受欢迎的开源项目之一， Pluto ，允许用户在他们的基础设施即代码存储库和 Helm 版本中轻松找到已弃用的 Kubernetes API 版本。我们的开源项目 Pluto 以最初被弃用的矮行星命名，它识别 Kubernetes 对象中过时的 API，因为它们被更稳定的 API 所取代。

折旧政策

虽然废弃的 API 版本很容易修复，但诀窍是找到所有您可能使用过在下一次升级中将会过时的版本的地方。让 Kubernetes API 服务器为您识别它们可能会有问题。如果您要求 API 服务器为您提供 deployments.v1.apps，并且部署最初创建为 deployments.v1beta1.extensions，服务器将转换 API 版本并返回一个包含 apps/v1 的清单。这意味着，至少可以说，定位被否决的 API 被使用的位置是一个挑战。关于冥王星最初为什么被创造的更多信息可以在冥王星文档中找到。

Pluto 通过检查一些可能运行废弃版本的不同地方来解决这个问题。在基础设施即代码存储库中，Pluto 可以检查旧 API 版本的静态清单和图表。在实时 Helm 版本中，Pluto 可以确认在集群中运行的 Helm 版本不包含废弃版本。Pluto 区分简单地被否决的 API 版本和从 Kubernetes API 中完全删除的版本。

冥王星升级

CircleCI 以“orbs”的形式引入了可重用配置的概念，这是一个可重用的 YAML 配置包，它将重复的配置压缩到一行代码中。这些球体是可重复使用的代码片段，可以帮助组织:

加速项目设置
自动化重复的流程
简化第三方集成
节省项目配置时间
提高组织效率
使与第三方工具的集成更加容易

从 Pluto v5.2.0 开始，Fairwinds 发布了一个名为 fairwinds/pluto 的球体，以便在 CircleCI 内部提供更简单的配置。我们要感谢我们的开源社区对这个项目的贡献。

我们最近也开始用 cosign 为我们的容器签名，将它们推到一个新的位置:us-docker.pkg.dev/fairwinds-ops/oss/pluto.用户现在可以运行 cosign verify—keyhttps://artifacts.fairwinds.com/cosign.pub来检查签名。这是一个供应链安全措施，帮助从业者验证他们正在运行 Fairwinds 发布的实际 Pluto 容器。

最后，鉴于 Kubernetes v1.22 中的许多弃用和删除，我们已经确保用最新的可用信息更新我们的版本列表。如果您确实在 Pluto 报告的版本中发现错误或更新，请通过提交 Github 问题让我们知道。

我们的开源社区

在 Fairwinds，我们是 Kubernetes 和围绕它的开源技术社区的忠实拥护者。多年来，我们的团队已经为客户管理了数百个集群，我们已经了解了很多关于运行 Kubernetes 所涉及的问题和陷阱。事实上，我们坚信开源软件为更具竞争力的商业模式铺平了道路。

即使我们的开源社区中有成千上万的用户，我们也一直在寻找方法将人们聚集在这些项目周围，讨论开发并给实践者一个影响正在进行的路线图的机会。这就是为什么我们在去年建立了我们的 Fairwinds 开源用户组——给成员一个提问、解决问题、与其他用户交流和分享他们环境中工作的机会。

我们的下一次开源社区会议将于 2022 年 6 月 22 日美国东部时间上午 11 点|太平洋时间上午 8 点举行。如果你有兴趣加入我们，请注册群，我们将向你发出正式邀请。如果您参加我们的下一次开源会议，您将获得一些优秀的 Fairwinds 奖品！

费尔温德见解

如果您有兴趣在多个集群中运行 Pluto，随着时间的推移跟踪结果，与 Slack、Datadog 和吉拉集成，或者解锁其他功能，请查看我们在 Kubernetes 集群中用于审计和执行策略的平台fair winds Insights。

升级证书管理器-这是值得的！

原文：https://www.fairwinds.com/blog/upgrade-cert-manager-its-worth-it

cert-manager 项目通过 Kubernetes 中的 TLS 证书管理自动提供和更新。它支持使用您自己的证书颁发机构、自签名证书、由 Hashicorp Vault PKI 管理的证书，当然还有由 Let's Encrypt 发布的免费证书。如果你想在 0.5 版本之前使用 Helm 升级 cert-manager，而不需要重新创建或重新发布证书，请继续阅读。

如果您还没有使用证书管理器来管理证书，让我们在 Kubernetes 用 Ingresses 加密证书，请看入门和 ACME 发卡行教程证书管理器文档。

升级证书管理器的原因

以前版本的 cert-manager 可能会淹没 Let's Encrypt API。这在 cert-manager 0.6.0 中有了很大的改进:

Kubernetes 为证书订单和验证挑战提供了新的定制资源，通过 Let's Encrypt 简化了流程，并为 Kubernetes 中的调试提供了更多详细信息。您可以通过变更建议阅读更多关于新订单流程的信息。下面的升级演练包含旧证书对象与新订单和质询对象中可用信息的示例。
一个新的验证 webhook 在提交给 Kubernetes API 时检查新证书资源的错误配置，然后再提交给 Let's Encrypt。这样可以更快地捕捉错误，而不会浪费对 Let's Encrypt API 的调用。
与 Let's Encrypt 通信的 ACME 客户端有 Prometheus 指标。在达到加密速率限制之前，您可以使用 ACME APIs 来检测证书管理器的使用情况，以检测问题并了解行为。

如 cert-manager 0.6.0 发行说明中所述:

经过广泛的测试，我们发现在最极端的情况下，ACME API 客户端调用减少了 100 倍。这是一个巨大的差异，有助于减少 cert-manager 实例对 Let's Encrypt 等服务的负载。因此，我们强烈建议所有用户尽快升级到 v0.6 版本！

头盔升级移除证书对象

在 Fairwinds，我们使用稳定舵图表来部署 cert-manager。如果您还没有使用 Helm，它可以帮助您管理多个 Kubernetes 对象的期望状态。当通过计算器使用时，Helm 更加强大，它使用 YAML 语法一次安装多个 Helm 版本，并允许从 git 存储库中安装图表。

cert-manager Helm chart 在版本 0.5.0 中停止管理自定义资源定义(CRD ),现在应该在安装版本 0.5 以上的 chart 之前手动安装 CRD。这意味着一个典型的helm upgrade ...cert-manager 将会从 Kubernetes 中删除你的证书对象。由 cert-manager 填充的机密不会被删除，但是这些机密永远不会被更新，因为没有 cert-manager 证书可以续订。

我原以为重新安装 cert-manager 后，由带注释的入口对象创建的证书最终会被重新创建，但我无法在不停机的情况下做到这一点。

如果你不得不重新创建和重新颁发你的证书，让我们加密有一个每周每个注册域 50 个证书的速率限制。

执行升级

我将介绍 cert-manager 从 0.4.1 到 0.6.2 的升级，演示新的顺序和挑战资源。我的 cert-manager 0.4.1 安装在 kube-system 名称空间中，但是我将把 cert-manager 0.6 安装在它自己的 cert-manager 名称空间中。使用一个专用的名称空间是一个好主意，这个决定是由 cert-manager 在使用新的 cert-manager webhook 时禁用其名称空间验证的要求进一步推动的。

查看现有证书

我有一个“神奇应用”的有效证书，另一个证书未能通过验证。

cert-manager 0.4.1 的证书对象的基本列表不显示证书是否有效:

$ kubectl get certificate --all-namespaces
NAMESPACE NAME AGE
default wonder-app-cert 9m
test ivan-test-cert 9m

在测试名称空间中描述 ivan-test 证书，显示其验证失败，因为我没有为 Let's Encrypt ClusterIssuer 正确配置 DNS 验证(在状态中注明。输出底部的消息字段):

$ kubectl describe certificate -n test ivan-test
Name: ivan-test-cert
Namespace: test
Labels: <none>
Annotations: <none>
API Version: certmanager.k8s.io/v1alpha1
Kind: Certificate
Metadata:
 Creation Timestamp: 2019-02-28T05:53:09Z
 Generation: 1
 Owner References:
 API Version: extensions/v1beta1
 Block Owner Deletion: true
 Controller: true
 Kind: Ingress
 Name: test-ingress
 UID: 202bc781-3b1d-11e9-9fb0-02096e167e86
 Resource Version: 17919
 Self Link: /apis/certmanager.k8s.io/v1alpha1/namespaces/test/
certificates/ivan-test-cert
 UID: 203105f3-3b1d-11e9-9fb0-02096e167e86
Spec:
 Acme:
 Config:
 Dns 01:
 Provider: clouddns
 Domains:
 ivan-test.example.com
 Common Name: 
 Dns Names:
 ivan-test.example.com
 Issuer Ref:
 Kind: ClusterIssuer
 Name: letsencrypt-prod
 Secret Name: ivan-test-cert
Status:
 Acme:
 Order:
 URL: https://acme-v02.api.letsencrypt.org/acme/order/xxxxxxxx/
yyyyyyyyy
 Conditions:
 Last Transition Time: 2019-02-28T05:53:12Z
 Message: ACME server does not allow selected challenge type or no 
provider is configured for domain "ivan-test.example.com"
 Reason: InvalidConfig
 Status: False
 Type: Ready
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal CreateOrder 10m cert-manager Created new ACME order, 
attempting validation...

为证书管理器创建新的命名空间

如果使用 Kubernetes 1.12 或更早版本，新的 cert-manager web 挂钩要求在其名称空间上禁用验证，以避免有关 ValidatingWebhookConfiguration 资源的 CABundle 字段的错误。cert-manager 将安装在自己的命名空间中，而不是禁用与其他事物共享的命名空间上的验证。如果没有完成这一步，cert-manager 将无法正确地为其新的 webhook 提供证书，从而导致鸡生蛋的局面。有关需要禁用验证的 webhook 的更多详细信息，请参见本期CABundle Kubernetes。

$ kubectl create namespace cert-manager

$ kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true

将机密复制到新的名称空间

cert-manager 为其发行者使用的任何 Kubernetes 秘密都需要存在于新的 cert-manager 名称空间中。这个不涉及到持有入侵者使用的 SSL 证书的秘密！

您可能希望复制到新命名空间的机密包括:

ClusterIssuer 对象的 issuer.acme.dns01.providers 字段下配置的 DNS 提供程序引用的任何机密。这些秘密提供了对云服务帐户的访问，该帐户用于注册临时 DNS 条目以验证 Let's Encrypt 证书。DNS 可用于验证加密服务器无法访问的私有入口的证书。
(可选)由 ClusterIssuer 对象中的 issuer . ACME . privatekeysecretref 引用的 ACME 帐户私钥机密。对于 Let's Encrypt ClusterIssuers，cert-manager 将创建一个新的私钥，并将其存储在一个新的 Secret 中(如果尚不存在的话),到目前为止，这还没有影响到 Let's Encrypt 的现有证书。我不能代表其他发行者使用的秘密——您可能应该将它们复制到新的名称空间。

对于本例，我将从名为 letsencrypt-prod 的 ClusterIssuer 复制私钥秘密名称。首先从集群发布者处获取机密的名称:

$ kubectl get clusterissuer letsencrypt-prod -o jsonpath='{.spec.acme.privateKeySecretRef.name}'

这将返回秘密名称 cert-manager-setup-production-private-key。我的秘密是在名称中包含“cert-manager-setup ”,因为我们使用舵图来配置我们的集群发布者。

在jq命令的帮助下，将这个秘密复制到 cert-manager 名称空间。

$ kubectl get secret -o json -n kube-system cert-manager-setup-production-private-key

| jq 'del(.metadata.namespace)' | kubectl create -f - -n cert-manager

稍后将删除 kube-system 名称空间中与证书管理器相关的机密。

记住还要复制集群发行者可能用于 DNS 验证的任何机密！

备份相关对象

在使用 Helm 升级的过程中删除自定义资源定义(CRD)时，Issuer、ClusterIssuer 和 Certificate 对象将会消失。安装新版本的 cert-manager 及其附带的 CRD 后，将还原此备份。

`$ kubectl get -o yaml \

  --all-namespaces \

  issuer,clusterissuer,certificates > cert-manager-backup.yaml`

请注意，由 Kubernetes Ingresses 使用的 cert-manager 填充的机密不会被触及，也不需要备份。

删除旧的证书管理器

此步骤还将删除 CRD 及其对象。不会触及由 Kubernetes Ingresses 使用的 cert-manager 填充的机密。安格斯将继续响应 HTTPS。

$ helm delete --purge cert-manager

现在列出证书会返回此错误，因为 CRD 及其对象已经不存在了

$ kubectl get certificates
Error from server (NotFound): Unable to list "certmanager.k8s.io/v1alpha1, 
Resource=certificates": the server could not find the requested resource (get 
certificates.certmanager.k8s.io)

安装新的自定义资源定义

自定义资源定义(CRD)不再在 Helm chart 中管理，应该在该图表的 0.5+版本之前安装。以下命令适用于 0.6.X 版的证书管理器。

$ kubectl apply \
 -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.6/deploy/
manifests/00-crds.yaml
customresourcedefinition.apiextensions.k8s.io/certificates.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/issuers.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/clusterissuers.certmanager.k8s.io 
created
customresourcedefinition.apiextensions.k8s.io/orders.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/challenges.certmanager.k8s.io created

但是，被重新安装的 CRDs 不会恢复证书对象，但是它们将在以后的步骤中从备份中恢复。

$ kubectl get certificates --all-namespaces
No resources found.

安装证书管理器

使用 Helm 或类似 Reckoner 的辅助工具安装 0.6 版的 cert-manager。这使用 0.6.6 版的 Helm chart，它安装 0.6.2 版的 cert-manager。

使用舵安装

$ helm install stable/cert-manager -n cert-manager --namespace cert-manager 
--version 0.6.6
..... Helm output omitted .....

使用计算器安装

下面是安装 cert-manager 的计算器的 YAML 代码片段，包括安装 CRDs 和禁用新安装的名称空间验证的预安装挂钩(上面已经完成了):

# Use this course.yml file with reckoner to deploy cert-manager,
# For example: reckoner plot course.yml --heading cert-manager
#
# Replace this context with your own.
context: your_actual_kubernetes_context # Get with kubectl config current-context
repositories:
 incubator:
 url: https://kubernetes-charts-incubator.storage.googleapis.com
 stable:
 url: https://kubernetes-charts.storage.googleapis.com
minimum_versions:
 helm: 2.12.3
 reckoner: 1.0.1
charts:
 cert-manager:
 version: "v0.6.6"
 namespace: cert-manager
 set-values:
 # You can place chart values here. . .
 resources:
 requests.cpu: 10m
 requests.memory: 50Mi
 limits.cpu: 15m
 limits.memory: 100Mi
 hooks:
 pre_install:
 - kubectl get namespace cert-manager >/dev/null 2>&1 || kubectl create 
namespace cert-manager
 # The next line is only required with Kubernetes 1.12 or earlier.
 - kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=
true --overwrite=true
 - kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/
release-0.6/deploy/manifests/00-crds.yaml

还原对象备份

恢复 Certificate、Issuer 和 ClusterIssuer 对象的备份——这些对象已被 Helm 与以前版本的 cert-manager 发行版一起删除。

$ kubectl apply -f cert-manager-backup.yaml
clusterissuer.certmanager.k8s.io/letsencrypt-prod created
clusterissuer.certmanager.k8s.io/letsencrypt-staging created
certificate.certmanager.k8s.io/wonder-app-cert created
certificate.certmanager.k8s.io/ivan-test-cert created

还原对象时的潜在错误

如果您收到类似下面的错误，cert-manager web hook 尚未准备好，可能是因为它仍在创建自己的证书，或者是因为上面没有安装 CRDs。如果舵图在 CRDs 完全应用之前安装得太快，网络挂钩可能无法创建其证书。要解决这个问题，请删除 cert-manager-webhook-xxxxxx pod，这样它将重新启动并实现它的证书。再次恢复备份，应该不会出现错误。

更多背景信息见安装升级文档。

Error from server (InternalError): Internal error occurred: failed calling admission 
webhook "clusterissuers.admission.certmanager.k8s.io": the server is currently unable 
to handle the request

Error from server (InternalError): Internal error occurred: failed calling admission
webhook "certificates.admission.certmanager.k8s.io": the server is currently unable
to handle the request

检查证书管理器对象并验证快乐

证书对象现在有一个名为“ready”的字段，对于 wonder-app 证书为真，对于 ivan-test 证书为假，反映了它们在 cert-manager 升级之前的状态。

查看颁发者和证书，我们看到 cert-manager webhook 使用的新证书，以及以前的 ClusterIssuer 和 Certificate 对象:

$ kubectl get clusterissuer,issuer,certificates --all-namespaces
NAME AGE
clusterissuer.certmanager.k8s.io/letsencrypt-prod 3m
clusterissuer.certmanager.k8s.io/letsencrypt-staging 3m

NAMESPACE NAME AGE
cert-manager issuer.certmanager.k8s.io/cert-manager-webhook-ca 13m
cert-manager issuer.certmanager.k8s.io/cert-manager-webhook-selfsign 13m

NAMESPACE NAME 
cert-manager certificate.certmanager.k8s.io/cert-manager-webhook-ca 
cert-manager certificate.certmanager.k8s.io/cert-manager-webhook-webhook-tls 
default certificate.certmanager.k8s.io/wonder-app-cert 
test certificate.certmanager.k8s.io/ivan-test-cert 
READY SECRET AGE
True cert-manager-webhook-ca 13m
True cert-manager-webhook-webhook-tls 13m
True wonder-app-cert 3m
False ivan-test-cert 3m

查看证书过期时间

描述一个证书现在会在详细信息的底部显示到期时间——下面是一个片段:

Status:
 Conditions:
 Last Transition Time: 2019-02-28T06:54:46Z
 Message: Certificate is up to date and has not expired
 Reason: Ready
 Status: True
 Type: Ready
 Not After: 2019-05-29T04:52:06Z
Events: <none>

证书验证失败

在 cert-manager 升级之后，失败的 ivan-test 证书没有而不是提供关于 cert-manager 对象中验证失败的足够信息。我必须查看 cert-manager pod 的日志，以发现我没有配置 DNS 验证，这导致无法尝试验证:

$ kubectl describe certificate -n test ivan-test-cert 
Name: ivan-test-cert
Namespace: test
Labels: <none>
Annotations: <none>
API Version: certmanager.k8s.io/v1alpha1
Kind: Certificate
Metadata:
 Creation Timestamp: 2019-02-28T07:20:43Z
 Generation: 1
 Owner References:
 API Version: extensions/v1beta1
 Block Owner Deletion: true
 Controller: true
 Kind: Ingress
 Name: test-ingress
 UID: 4ea85e58-3b29-11e9-9fb0-02096e167e86
 Resource Version: 26973
 Self Link: /apis/certmanager.k8s.io/v1alpha1/namespaces/test/
certificates/ivan-test-cert
 UID: 5c06841a-3b29-11e9-9fb0-02096e167e86
Spec:
 Acme:
 Config:
 Dns 01:
 Provider: clouddns
 Domains:
 ivan-test.example.com
 Dns Names:
 ivan-test.example.com
 Issuer Ref:
 Kind: ClusterIssuer
 Name: letsencrypt-prod
 Secret Name: ivan-test-cert
Status:
 Conditions:
 Last Transition Time: 2019-02-28T07:20:43Z
 Message: Certificate does not exist
 Reason: NotFound
 Status: False
 Type: Ready
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal OrderCreated 115s cert-manager Created Order resource 
"ivan-test-cert-4093320200"

我希望 Order 对象说明一下为什么没有进行验证，但是唯一的细节是它是待定的:

$ kubectl describe order -n test ivan-test-cert-4093320200 
Name: ivan-test-cert-4093320200
Namespace: test
Labels: acme.cert-manager.io/certificate-name=ivan-test-cert
Annotations: <none>
API Version: certmanager.k8s.io/v1alpha1
Kind: Order
Metadata:
 Creation Timestamp: 2019-02-28T07:20:43Z
 Generation: 1
 Owner References:
 API Version: certmanager.k8s.io/v1alpha1
 Block Owner Deletion: true
 Controller: true
 Kind: Certificate
 Name: ivan-test-cert
 UID: 5c06841a-3b29-11e9-9fb0-02096e167e86
 Resource Version: 26975
 Self Link: /apis/certmanager.k8s.io/v1alpha1/namespaces/test/orders/
ivan-test-cert-4093320200
 UID: 5c084dcc-3b29-11e9-9fb0-02096e167e86
Spec:
 Config:
 Dns 01:
 Provider: clouddns
 Domains:
 ivan-test.example.com
 Csr: actual CSR omitted
 Dns Names:
 ivan-test.example.com
 Issuer Ref:
 Kind: ClusterIssuer
 Name: letsencrypt-prod
Status:
 Certificate: <nil>
 Finalize URL: https://acme-v02.api.letsencrypt.org/acme/finalize/xxxxxxxx/
yyyyyyyyy
 Reason: 
 State: pending
 URL: https://acme-v02.api.letsencrypt.org/acme/order/xxxxxxxx/yyyyyyyyy
Events: <none>

此证书没有质询对象，因为没有配置 DNS 提供程序，所以没有尝试验证。

$ kubectl get challenge -n test
No resources found.

在这种情况下，我没有看到失败的原因(DNS 验证配置不正确)反映在上述任何对象中，正如我在以前版本的 cert-manager 中所做的那样。不过，cert-manager pod 日志确实反映了这一点:

cert-manager-6874795dc8-b76kk cert-manager E0228 07:10:22.018889 
1 controller.go:185] orders controller: Re-queuing item 
"test/ivan-test-cert-4093320200" due to error processing: Error constructing 
Challenge resource for Authorization: ACME server does not allow selected 
challenge type or no provider is configured for domain "ivan-test.example.com"

清理

删除先前从 kube 系统复制到 cert-manager 名称空间的机密。对于这个例子:

T2$ kubectl delete secret -n kube-system cert-manager-setup-production-private-key

从 kube-system 名称空间中删除您可能已经复制到新名称空间的任何其他机密，例如用于 DNS 证书验证的机密。

享受证书管理器

享受您的 cert-manager 的升级安装，在它自己的名称空间，以及未来的升级可能会更少的麻烦。

感谢您的阅读！如果你喜欢这篇文章，或者有什么建议，请随时在 Twitter 上联系@IvanFetch。

升级到 Istio 1。

原文：https://www.fairwinds.com/blog/upgrading-to-istio-1.1

Istio 最近发布了其流行服务 mesh 的 1.1.1 版本，进行了一些更改和改进。毫无疑问，您应该从早期版本升级，以利用 Kubernetes 集群中的这些改进。但是升级并不简单——Istio 的服务网几乎影响了集群通信的每个方面！除了升级 Istio 的控制面板，每个边车都必须升级。在接下来的部分中，我将概述一些应该计划的主要变化，以及在集群中升级 Istio 可以采取的步骤。

有什么变化

如果你是一个 helm 用户，需要注意的最大变化是 CRD(自定义资源定义)现在由一个名为istio-init的单独的 helm 图表安装。这个新图表应该在控制面板升级之前安装，否则升级可能会失败。为了简化安装，添加了配置文件，它们是用于不同需求的舵值文件。

活性和准备就绪探测

在以前的版本中，当启用 mTLS 时，就绪性和活性探测一直是一个棘手的问题，因为 kubelet 没有 istio 颁发的证书来与服务通信。这使得使用 http 和 tcp 检查变得不可能。版本 1.1 引入了一个探针重写，可以将活跃度探针请求重定向到引导代理。然后，pilot 代理将请求重定向到 pod，允许 kubelet 在没有 istio 颁发的证书的情况下发送请求。换句话说，您可以再次使用 http/tcp 活跃度和就绪性探测！

mTLS

如果您正在使用注释来覆盖 mTLS 策略，我很抱歉地说，这将不会继续下去。这已被一种用身份验证策略和目标规则替代的新方法所取代。使用策略和 DestinationRule 对象提供了更多的灵活性，但是在升级过程中您需要记住这一点。 ****

边车

在过去，很难配置超出开箱即用配置的代理边车。引入了一个新的 sidecar 资源，允许您配置代理将接受来自(入口和出口)的流量的端口和协议。该资源是动态的，您可以在一个名称空间中指定工作负载的子集来应用配置。

入口

在我看来最令人兴奋的变化是对 istio ingress 的弃用。这为更多的本地 Kubernetes 支持铺平了道路，随着这一变化，您可以使用 Kubernetes ingress 的可选支持。这允许您使用入口对象来定义入口点，并且您可以使用一个新的控制器来动态加载和旋转外部证书，包括 LetsEncrypt。在 Istio 1.1 发行说明页面上可以详细查看这些变更以及其他一长串变更。

升级过程

升级通常是通过备份 istio CRDs，安装新的istio-init舵图，用舵升级控制平面，然后升级所有的边车来完成的。

备份您的 CRD！

备份现有的 CRDs 是必要的，以防安装过程中出现问题。Kubectl 让这变得非常简单:

安装 Istio 初始化器图表

一旦备份了 CRDs，就该开始安装 istio 图表了。这些都可以在 Istio repo 中获得，所以我们需要首先使用下面的命令将其克隆到我们的工作站。所有适用的舵图都将在这个 repo 的install/kubernetes/helm子目录中。

如果你正在使用计算者，你很幸运，因为它可以从 git repo 安装图表。计算者是一个由费尔温德开发的舵的命令行助手，它使用 YAML 语法在一个文件中安装和管理多个舵图表。

我们需要安装的第一个图表是名为istio-init的 Istio 初始化器图表。它管理 istio 需要的所有 CRD。将这个图表安装到您已经安装了 Istio 的同一个名称空间是一个很好的做法。在这个例子中，我们在istio-system名称空间中有 Istio。

helm install install/kubernetes/helm/istio-init --name istio-init --namespaceistio-system

如果您正在使用 Reckoner，可以将此片段添加到您的课程中。yml:

然后，可以用命令reckoner plot course.yml --heading istio-init安装图表。

安装图表后，运行几个作业来创建 CRD。在继续之前，您需要确保它们都已完成。您可以通过watch和kubectl : watch -d "kubectl get job -n istio-system | grep istio-init-crd"来监控状态

升级控制平面流程的下一步是升级 Istio 控制平面。在你继续之前，有几个新的舵图表值需要注意:

一旦您的图表值配置完毕，您就可以使用 helm: helm upgrade istio install/kubernetes/helm/istio --namespace istio-system -f <path-to-values>.yml升级版本了

这里有一个例子片段，你可以用它来升级 Istio。可以使用命令
reckoner plot course.yml --heading istio升级图表。

升级边车

升级控制面板后，所有使用 istio 的应用程序仍将使用旧版本的 sidecar 代理。随着豆荚被重新装载，他们将得到更新的边车。通过自然的 pod 重启来接收更新是完全可以接受的，但是您可能想要考虑触发所有部署的滚动更新，以使它们都在相同的 sidecar 版本上。Istio 建议通过编辑每个启用了 istio 的部署规范中的普通字段来触发更新。这个代码片段通过向每个部署添加注释来实现这一点:

祝你好运！

享受升级后的 Istio 安装，它改进了对活性/就绪性探测的支持，更新了证书处理，并在 Kubernetes 生态系统中提供了更大的灵活性！

操作指南:使用 Helm 管理应用程序

原文：https://www.fairwinds.com/blog/using-helm-to-manage-applications

在这一部分中，费尔温德 use 的伊万·费奇将向您展示如何使用 helm 来管理 Kubernetes 中的应用程序。他还演示了北极星网钩。

使用 rok8s 脚本自动化您的部署工作流程

原文：https://www.fairwinds.com/blog/using-rok8s-scripts-to-automate-your-deployment-workflow

rok8s 脚本是 Kubernetes 脚本，通过持续集成环境帮助管理应用程序到 Kubernetes 的部署。rok8s-scripts 是由罗斯·库库林斯基创建的原 k8s 知识库的 Fairwinds 分支。

在这里，我将提供更多关于 rok8s 脚本是什么、它们做什么以及为什么你应该考虑使用它们的上下文。

rok8s 脚本概述

Kubernetes 部署涉及大量文件。例如，您必须安装 Kubernetes 命令行实用程序，将该实用程序授权给您正在使用的集群，并添加决定您的部署配置的所有文件。

自动化部署遵循类似的模式，这些模式已经被集成到高效的脚本中，从而有助于部署到 Kubernetes 中。开源 rok8s 脚本使得管理应用程序开发和部署生命周期以及从持续集成环境中部署到 Kubernetes 变得容易。(rok8s 脚本与 CircleCI 和 Jenkins 一起工作。Docker 1.10 或更高版本目前不支持缓存，但在不久的将来会支持。)

rok8s 脚本做什么

rok8s 脚本可用于验证部署、验证数据库迁移、处理机密和组织 YAML 文件。

部署验证
使用 Kubernetes，您可以描述您想要部署的映像，并为 Kubernetes 如何将该部署部署到 Kubernetes 集群中设置参数。因为 Kubernetes 没有内置的方法来通知您代码部署是否失败，所以 rok8s 脚本可以用来验证部署。

数据库迁移
当您部署代码时，代码和数据库模式需要对齐。rok8s 脚本包括一个包装 Kubernetes 作业(一次性可执行代码集)的包装器，称为阻塞作业。阻塞作业会将作业部署到集群中，并提供验证。如果迁移成功，您可以推出部署。如果失败，部署将在您的代码被放入 Kubernetes 之前停止，并给您解决问题的机会。该过程允许自动检入、检查和应用迁移代码。

Kubernetes Secrets
应用程序需要运行大量敏感信息，比如数据库的密码和其他服务的 API 密匙。当这些信息与您的源代码一起签入时，您实际上是在让其他人轻松访问利用您的系统所需的敏感凭据。rok8s 脚本包括 Kubernetes 秘密的包装器，允许在亚马逊 S3 中存储秘密，并对文件设置适当的权限。当您在 CircleCI 或 Jenkins 中构建部署时，您从 S3 下载秘密，将它们放入 Kubernetes 所需的文件格式，然后将它们推入 Kubernetes。这样，秘密的改变可以被同步，而不需要在源代码中保留秘密。

YAML 文件
单个应用程序部署涉及多个 YAML 文件的情况并不少见，因此目标之一就是在存储库中组织这些文件。rok8s 脚本可以帮助管理部署(如何将代码放入 Kubernetes)、服务和入口(如何部署 Kubernetes 中的应用程序)以及 ConfigMap(如何将配置推入 Kubernetes，以便部署在不同环境中保持不变)。

为什么应该考虑使用 rok8s 脚本

设置 Kubernetes 很简单，但是管理 Kubernetes 可能很复杂。(关于概述，请查看kops 101-Kubernetes 部署游戏规则改变者。)

通过自动化标准工作流和简化常见任务，rok8s 脚本为部署到 Kubernetes 中的应用程序提供了一个固执的指导方针，确保所有部署遵循相同的模式并快速跟踪常见功能。虽然 rok8s 脚本不会取代 Kubernetes 和 kops 中的专业知识，但它们将大大减少快速有效地部署到 Kubernetes 所需遵循的步骤。

利用 Fairwinds Insights 验证集装箱安全性

原文：https://www.fairwinds.com/blog/validating-container-security

概述:什么是容器安全性？

容器安全性保护容器的完整性，包括容器中的应用程序和它们所依赖的基础设施。容器使得为不同的环境和部署目标构建、打包和部署应用程序和服务变得容易。 Docker 是一种流行的容器化技术，因此了解 Docker 映像是漏洞进入集群的最简单方式之一非常重要。

为什么集装箱安全很重要

容器由文件层组成，这些文件层称为容器映像。基本映像对于安全性至关重要，因为它是 Linux 容器的起点。如果您的基础映像中存在漏洞，那么包含该基础映像的每个容器中都会存在该漏洞。这就是为什么找到可靠的基础映像来源非常重要。请记住，当您添加应用程序和进行配置更改时，这些更改会引入新的变量。

“根据 451 Research 的 2020 年调查，在 12 个月的时间里，94%的组织报告了 K8s 和容器环境中的严重安全事件。”

集装箱安全风险

Docker 容器使开发更加高效和可预测，消除了一些重复的配置任务。此外，与直接在主机上运行应用程序相比，使用 Docker 可以提高安全级别。开放 Web 应用安全项目(OWASP)提供了 12 条规则来帮助您防止常见的安全错误，并应用最佳实践来帮助您保护 Docker 容器，包括保持最新的补丁，确保您不会暴露 Docker 守护进程套接字，限制功能等等。遵循这些规则将有助于您的组织降低与集装箱安全相关的风险，但您将需要额外的工具来扫描图像和检测错误配置。

集装箱安全挑战

要看到一个容器的内部并理解你的容器内部使用的是什么开源并不容易。Docker 容器是一个虚拟化的运行时环境，Docker 映像是 Docker 容器在特定时间点的记录，其中包含所有应用程序代码、工具、库、依赖项和运行应用程序所必需的附加文件——这太多了！Docker 图像也有多个层，每个层都基于前一个层，但也有所不同。Docker 图像可以重复使用，但也不能更改。因此，如果出现问题，您需要修复漏洞并构建新的容器映像。

请记住，即使您定期扫描容器映像作为 CI/CD 或注册表的一部分，常见漏洞和暴露 (CVEs)也可能随时出现。这意味着即使您的实际环境中的映像也可能包含新发现的 CVE，因此您必须主动扫描您的环境中运行的映像。

Kubernetes 的集装箱安全

云从根本上改变了基础设施安全发生的方式，这意味着对大多数组织来说，重新思考安全性，以规划容器安全性和 Kubernetes 安全性考虑。Kubernetes 是容器编排的事实上的标准，因此将容器安全性视为您的 Kubernetes 安全性最佳实践的组成部分是至关重要的。Kubernetes 虽然在默认情况下不安全，但确实提供了几个内置的安全特性，包括 Kubernetes 基于角色的访问控制( RBAC )、网络策略和准入控制器。

Kubernetes 中容器安全性的额外考虑是额外的复杂性。这几乎是一个等式，你必须考虑工程师的数量，乘以云帐户、微服务、API 等的数量。本质上，这意味着你处在一个不断变化的环境中。有很多东西需要跟上，尤其是一项成熟的技术，有限的安全人才资源，以及不断增加的合规性要求。在 Kubernetes 中找到获得容器安全性可见性的方法是必不可少的，自动化策略执行是维护持续安全性和治理的要求。 Datadog 报道称一半运行容器的组织使用 Kubernetes ，并且几乎 90%的容器被编排为自动化容器部署和维护，使得容器安全成为 Kubernetes 安全的重要组成部分。

什么是集装箱扫描？

容器扫描，也称为容器图像扫描，是扫描容器及其所有组件以识别安全漏洞的过程或方法。对于任何致力于保护容器化开发工作流的团队来说，容器扫描是容器安全的一个重要组成部分。

容器图像来源广泛，包括公共存储库，这可能会增加潜在的危害风险。来自不可信来源的映像可能包含漏洞或恶意组件，并且可能没有正确配置以满足合规性标准。由于图像来源的多样性，保持对容器图像的信任尤为重要，容器扫描可以帮助您更好地理解图像或容器中的组件。为了提高整个应用程序生命周期的安全性，您的团队应该在三个方面利用容器安全性。

将图像扫描集成到 CI/CD 管道中:最好在构建容器时扫描组件。如果您构建时存在漏洞，它们将成为您的容器和映像的一部分—您需要修复漏洞并重建容器和映像。集成图像扫描以在代码进入管道之前检测和阻止漏洞，有助于您将安全性向左转移，从而改进您的 DevSecOps 实践。
扫描您的容器注册表:容器注册表是您存储所有应用程序映像的地方，它可能包含成百上千个从不同来源构建的映像，包括第三方位置。一个漏洞或不安全的配置可能导致对您的注册表和应用程序的威胁。自动持续扫描注册表中漏洞状态的任何变化，并确保扫描每张图像，以识别和防止潜在的外来威胁。
运行时的开源漏洞扫描:要实现最优的容器安全性，不能只扫描注册表——需要自动进行持续扫描，以便在发现新的 CVE 时立即识别它们。持续的自动扫描有助于您检测新的漏洞，向您的安全团队报告发现的问题，并快速修复它们。因为您的环境可能包含多个应用程序和集群，所以最好能够了解跨环境的容器漏洞，以便您可以确定补救工作的优先级。

持续的容器扫描至关重要

根据最近的 451 Research 调查，69%的受访者经历过错误配置事件，27%的受访者在运行时经历过安全事件，24%的受访者报告他们有重大漏洞需要修复。容器安全问题影响了许多组织，由于安全问题而延迟了应用程序的部署。延迟部署会影响您的组织向市场交付应用程序和服务的能力，并可能影响您的底线。

集装箱安全验证

Fairwinds Insights 支持 Kubernetes-native 安全、策略和治理，通过为您的 Kubernetes 环境提供持续扫描和运行时监控，帮助您的组织降低跨多个团队和集群的风险。Insights 使用 Trivy 定位集装箱风险，Trivy 是一种开源的集装箱扫描解决方案。然后，它会为任何具有已知漏洞的映像创建操作项，以便您了解漏洞所在，并计划补救步骤。

对使用 Fairwinds Insights 感兴趣吗？免费提供！点击此处了解更多信息。

当您在 Kubernetes 环境中部署应用程序和服务时，您将拥有多个团队、多个集群和许多正在运行的容器。重要的是要有一个单一的控制面板来显示跨环境的信息，以最大限度地了解复杂的环境，大规模自动化您的安全，并集成左移安全以更快地降低风险。Fairwinds Insights 验证容器安全性和 Kubernetes 安全性最佳实践，帮助您专注于您的应用程序，而不仅仅是维护您的容器和 Kubernetes 环境的安全性。

阅读这份白皮书，了解如何验证容器安全性并采用 Kubernetes 最佳实践。

为什么 VPE 需要关注 Kubernetes 配置审计

原文：https://www.fairwinds.com/blog/vpes-kubernetes-configuration-audits

作为工程副总裁(VPE)，你的工作很重要。您有责任通过发展和管理工程团队、花费时间确保团队按时交付产品、执行产品路线图和优化内部流程来实现公司的愿景。根据组织的规模，您还可以管理跨职能团队，如设计、QA、前端和后端开发团队。要做好这一切，您必须平衡上市速度和安全基础设施，因为今天安全基础设施是维持品牌信任的重要组成部分。安全性可帮助您确保您的组织不会让客户失望，并实现对各种法规和要求的遵从。

随着公司的发展，法规遵从性越来越成为您工作中的重要组成部分，因为法规遵从性使您能够扩大规模，并帮助您将公司定位为安全服务，这是成功发展的重要组成部分。法规遵从性意味着您需要能够审核您的部署环境，并返回易于理解和可操作的结果。随着组织越来越多地采用 Kubernetes，许多 VPE 不考虑 k8s 安全性，使他们暴露于新的安全和审计问题，并影响工程团队内部和公司其他部门的信任，如果发生影响最终用户的事件，可能还会影响客户。那么，如何将 Kubernetes 和集群配置审计构建到您的整体安全性和遵从性框架中呢？

寻找合适的 Kubernetes 配置审计工具

好消息是有很多现有的工具；这些开源工具可以很好地测试整个 Kubernetes 配置审计的不同部分，但是很难使用多个不同的工具进行扩展，尤其是当您试图审计多个不同的集群时。也很难找到和雇佣合适的人，因为 Kubernetes 市场严重缺乏专业知识。技术还年轻，资源匮乏。集安全和 Kubernetes 才能于一身的专家就更难找到了。在内部拼凑合适的解决方案来构建有效的集群配置工具可能会耗费团队的时间，并妨碍您实现其他紧迫的业务目标。

创建 Kubernetes 和云原生安全性

您的组织可能已经开始在云中运行应用程序，或者您正计划很快迁移到云中。云原生技术(微服务、容器和 Kubernetes)使您能够在现代动态云环境中构建和运行可扩展的应用，并在云原生架构上构建和运行应用。虽然这一变化有助于您更快地将创新推向市场并满足不断变化的客户期望，但这也意味着在一开始就将安全性构建到您的环境和应用中，并确保您拥有正确且一致的 Kubernetes 配置。能够审核您的环境并确保连续可用性，以及了解哪些问题需要立即缓解，哪些问题需要以后解决，这一点非常重要。为您的 Kubernetes 环境设置正确的策略来管理最佳实践，将加快上市速度，并确保在开发过程的早期提供相关的、可操作的反馈。

有效审计的力量

审计对于发现和解决安全问题非常有帮助，并且是您用来确保一切顺利运行的工具的重要部分。正确的审计工具还可以帮助您提高可靠性和效率。Kubernetes 是一项复杂的技术，当您试图:

设置可靠的应用程序
确保应用程序使用正确的资源自动重启
适当扩展应用程序
配置应用程序以满足需求，而不会过度配置和浪费资源

正确的审计工具，即帮助您自动执行 Kubernetes 策略的工具，可以帮助您管理您的 Kubernetes 安全状况，并审计您部署的应用程序及其运行的集群的效率和可靠性。这些能力对于团队和负责配置的服务所有者来说非常重要。对有效审计发现的问题的早期反馈有助于降低修复错误或错误配置问题的成本。

准时、安全地发货

作为 VPE，您需要平衡指标、上市速度，并确保基础架构的安全性。您在确保合规性的同时注重满足客户要求，这有助于提高客户满意度和销售额，从而增加您组织的成功。通过确定您正在遵循云和 Kubernetes 最佳实践并运行安全基础设施，您的销售团队可以将您的公司定位为安全服务。

审计您的 Kubernetes 基础设施可以让您持续了解您的风险，确保您不仅了解任何问题，而且知道如何解决它们。Kubernetes 的复杂性可能会让许多组织对理解和确保其 Kubernetes 集群的安全性毫无准备。作为 VPE，您需要审核您的 Kubernetes 配置以最大化您对跨多个集群的问题的可见性，并控制配置以确保它们符合您为保护您的公司而设置的策略。保持对 Kubernetes 环境的可见性和控制有助于您更快地交付安全的产品，并满足您的业务目标。

我们调查了几十家公司的工程代表。以下是我们的发现...

原文：https://www.fairwinds.com/blog/we-surveyed-engineering-reps-from-dozens-of-companies-heres-what-we-found-out

欢迎来到冥王星，开源开发的起点

原文：https://www.fairwinds.com/blog/welcome-to-pluto-the-starting-place-for-open-source-development

来自冥王星的你好，开源价值大的小行星。冥王星曾经被认为是宇宙中一个全尺寸的球体，当它不再符合现代标准时，在 2006 年被降级为矮行星。事实证明，Kubernetes APIs 并没有太大的不同——它们也会随着旧代码在代码库中失去价值而变得过时，通常是因为它已经被新代码所取代。

Pluto，Fairwinds 开源项目，以废弃的星球命名，因为它可以帮助用户轻松地在他们的代码库和 Helm 版本中找到破旧的 Kubernetes API 版本。

等等，Kubernetes 的弃用政策是什么？

众所周知，Kubernetes 的采用允许用户大规模受益于容器技术。让容器如此流行的是它们提供资源抽象和隔离的能力。这意味着一个独立的容器映像足以让您在系统上运行应用程序，而无需安装任何额外的包。

不要与 2013 年推出的开源容器化平台 docker 混淆，Kubernetes 有助于管理这样的工作负载和微服务。随着越来越多的集装箱被部署，对 Kubernetes 维护的要求也在增加。对于每个新版本，对服务或操作的任何升级都必须在生产环境中兼容和安全。这意味着最新版本发布后，必须进行测试和修补。

作为一个拥有许多组件和贡献者的大型开源系统，Kubernetes 自然会随着时间的推移而发展。因为 Kubernetes 是 API 驱动的，API 逐渐演变以反映对问题空间的理解的变化。有时某些特性需要被删除，包括 API、标志甚至整个特性。为了避免破坏现有用户，Kubernetes 对计划删除的系统部分采用折旧政策。

Kubernetes 的给定版本可以支持任意数量的 API 组和版本。以下是管理 API 元素弃用的三个主要规则:

API 元素只能通过增加 API 组的版本来删除。
API 项目必须能够在给定版本的 API 版本之间往返而不丢失数据——除了某些版本中不存在的整个 REST 资源。
给定轨道中的 API 版本可能不被弃用，直到类似稳定的新 API 版本被发布。

告诉我更多关于这些 API 版本的信息...

除非从业者明确地使用仅在较新版本中可用的特性，否则他们必须能够升级到 Kubernetes 的新版本，并回滚到以前的版本，而不会对新的 API 版本做任何改动或遭受破坏。因此，Kubernetes API 版本控制方案对于开发人员来说是一个非常好的工具，因为它允许 Kubernetes 团队向 alpha 和 beta API 路径发布新特性，并在经过测试和验证后将它们升级到稳定路径。旧版本被弃用并最终被删除。

这个过程引发了一些关于 Kubernetes 升级的讨论，最引人注目的是 1.16 版本，其中删除了部署资源的多个过时版本。为什么？因为找到所有已经部署了不推荐使用的 API 版本的地方是很痛苦的。这就是访问冥王星可以解决问题的地方。

冥王星解决什么问题？

作为一个通过 Fairwinds 建立的开源实用程序， Pluto 帮助用户轻松识别他们的代码库和 Helm 版本中不赞成使用的 Kubernetes API 版本。随着 Kubernetes APIs 的发展，它们会定期重组或升级。当这种情况发生时，旧的 API 被认为是过时的，并最终被删除。Kubernetes API 服务器是灵活的，将提供关于给定资源类型的相同信息，而不管请求中指定的 API 版本。此功能使得无法区分实际部署到服务器的是哪个版本，从而导致升级过程中出现问题。

当有大量应用程序部署到 Kubernetes 集群时，集群升级可能会中断部署过程——可能会影响数百个存储库。创建 Pluto 是为了提前提供这些信息，因此可以在升级发生之前解决部署过程。

Pluto 可以用来扫描各种来源的废弃 API 版本，包括平面清单文件，甚至可以在使用 Helm 进行部署时直接与集群进行交互。

尽管 Helm 2 已被弃用，但下面是一个使用 Helm 3 部署应用程序的集群示例:

image of a cluster using Helm 3

Pluto 表示“audit-dashboard-prod-rabbit MQ-ha Stateful set”是通过 Helm 用一个不推荐的 API 部署的。现在，在部署之前定位和修复图表存储库变得容易多了。Pluto 将被更新，以包括 Kubernetes 的未来版本和对资源 API 的任何弃用。我们正在努力增加功能，所以请公开问题，加入 Fairwinds Slack 频道并投稿！

我如何获得 Fairwinds 的见解？

如果您有兴趣在多个集群中运行 Pluto，随着时间的推移跟踪结果，与 Slack、Datadog 和吉拉集成，或者解锁其他功能，请查看 Fairwinds Insights ，这是一个用于在 Kubernetes 集群中审计和执行策略的平台。免费提供！在此了解更多信息。

什么是 Kubernetes 护栏？

原文：https://www.fairwinds.com/blog/what-are-kubernetes-guardrails

如果你曾经和小孩子一起去打保龄球，你会很容易想象出一条保险杠朝上的保龄球道。目的:让保龄球到达球瓶，而没有落入沟中的危险。

Kubernetes guardrails 具有类似的目的:允许开发人员安全、合规且经济高效地使用 Kubernetes，这样他们的代码就可以进入生产阶段，而不会陷入常见的陷阱。Guardrails 有助于在平台级别实施策略，因此开发人员甚至不需要考虑需要完成哪些 Kubernetes 配置。相反，他们用安全网构建和部署代码。

护栏被定义为“路边或高速公路中间的坚固栅栏，旨在降低严重事故的风险。/防止人掉下来或被东西砸到的栏杆。”

Kubernetes guardrails 也是围绕平台的一道坚固屏障，防止开发人员意外引入风险、浪费云资源或出现应用程序性能问题。

Kubernetes 护栏在规模上很重要

大规模运行 Kubernetes 的组织需要考虑有多少人在该平台上工作，有多少集群在生产中，有多少附加组件在使用中。如果 DevOps 团队和平台工程师不得不手动审核 Kubernetes 配置，问题的规模可能会很快失控。根据 Kubernetes 的最佳实践检查每个集群可能会花费大量时间，不幸的是，一些组织没有带宽来审计平台，或者即使他们有，也没有办法确保在下一次审计之前做出更改。

DevOps 团队设置的护栏有助于消除这一挑战。Kubernetes guardrails 允许团队在平台级别制定政策，并在整个组织中一致地应用，而不是在推向生产和/或生产中进行手动审查。更好的是，当与准入控制器一起使用时，guardrails 允许 DevOps 团队知道任何没有通过检查的东西都不会进入生产。

利用 Fairwinds Insights 实施 Kubernetes 护栏

Fairwinds Insights 的 DevOps 平台允许用户自动应用 Kubernetes 最佳实践护栏，并跨集群一致地设置定制策略。对于领导者来说，这意味着消除人工审查，避免成为 Kubernetes 的服务台。它还使开发人员能够更好地理解 Kubernetes，在代码签入之前进行更改，而无需了解一切。结果是一个更有效率和效果的开发团队和 DevOps 团队可以专注于他们自己的冲刺和日常目标。

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

PagerDuty 的 Tristan Bates 说:“我们监控的一件大事，也是在组织层面解决的一件重要事情，是每个团队都需要制定的安全性和合规性标准。我们不一定希望团队知道这件事，我们希望在不妨碍生产力的情况下，让做正确的事情变得容易。这就是为什么我们使用 Fairwinds Insights，它的准入控制器和报告来管理 Kubernetes 在 PagerDuty 的安全性和合规性。我们甚至将它集成到整个生命周期中，以提醒团队他们正在做一些超出我们预期的事情。”

另一个客户， Variant ，完全能够消除它的手动审查过程，每次开发人员推向生产时，至少节省了 DevOps 团队一周的时间。这不仅导致了更快的开发生命周期，还提高了 DevOps 团队和开发人员的工作满意度，因为他们可以专注于自己的工作，而不必被延迟。

如果你正在大规模地使用云原生技术做任何事情——无论是多个集群还是多个团队，Kubernetes guardrails 都是需要的。

什么是开源 Kubernetes 策略引擎？为什么你需要一个&如何挑选

原文：https://www.fairwinds.com/blog/what-are-open-source-kubernetes-policy-engines

Kubernetes 政策背后的想法是，如果您为您的开发团队安装护栏，确保他们遵守 Kubernetes 最佳实践，您将会更加成功。创建策略可以帮助你确保你的开发人员没有在 Kubernetes 中做任何非常不安全、低效或不可靠的事情。一旦您决定了您的策略，您可能希望查看开源 Kubernetes 策略引擎，以确保您的开发人员根据您组织的标准部署所有东西。

开源策略引擎允许您在整个组织的高层次上执行您的所有策略。策略引擎可以在被动模式下运行，在这种模式下，您可以审核您的环境或作为代码审核您的基础架构，以查看您的合规性。您可以看到您采用了多少这样的策略，以及哪些团队不合规。您还可以以更主动的模式运行策略引擎，这样您就可以阻止不符合特定级别的预定义要求的内容。

Kubernetes 上下文中的策略引擎关注应用程序配置。它可以做得更多，但这是关键的使用案例。随着基础设施作为代码的出现，以及开发人员对运营的影响越来越大，配置已经成为开发过程的核心部分，尤其是在让应用程序在 Kubernetes 上运行的时候。策略引擎在配置清单上运行，无论是在 YAML、赫尔姆还是 Terraform 中。

为什么需要策略引擎？

组织正在利用云和容器，以便他们可以更快地进入市场，更快地交付应用和服务；Kubernetes 使得在云中运行和管理容器变得很容易。策略引擎非常重要，因为它使得管理如何部署到 Kubernetes 和一致地执行策略变得更加容易。

多个团队遵循不同的实践

部署到 Kubernetes 的团队通常是应用程序团队和开发团队，他们的主要工作是编写代码和特性。一个策略引擎帮助您确保那些团队能够可靠且一致地交付。它可以建立一个反馈循环，告诉开发人员如何改进他们的应用程序配置。它还可以识别当前配置中可能导致负面业务影响的问题，例如潜在的停机时间。例如，如果您没有以某种方式配置 Kubernetes，来自策略引擎的信息可能指示需要一个活跃度或就绪性探测器或标记一个符合性问题。

最重要的是，策略引擎可以通过确保 Kubernetes 环境不被分割、每个应用程序在生产环境中不是唯一配置的，来支持快速移动和更快交付应用程序的目标。它使您的团队能够可靠地运行他们的应用程序，而不会带来不必要的风险。

您的所有集群需要保持一致，以降低维护成本

Kubernetes 是一个复杂的生态系统，有很多东西需要学习。你不能指望每个开发人员都是 K8s 专家，或者每个开发团队都有 Kubernetes 专家。当您迁移过去只有一个或两个集群的部署时，您需要一些护栏来帮助开发团队确保他们发布的代码不会导致不可靠的应用程序、不安全的部署或成本超支。

Kubernetes 的多租户部署需要对共享资源进行治理

从 Kubernetes 的概念验证阶段发展到扩展到多租户 Kubernetes 战略的公司可能正在向一个环境发展，在这个环境中，他们有多个应用程序或多个团队部署在一个集群上。确保集群中的共享资源在各个应用团队配置其工作负载时不会受到负面影响需要治理。您需要确保您已经实施了适当的策略，以便集群正常运行，并且一个团队不会影响另一个团队。

由于不同的团队和不同的公司追求多租户战略，您可能还会发现您的各个团队在 Kubernetes 中处于不同的成熟度水平。一个团队可能遵循不同于另一个团队的实践。有时这是因为配置在团队之间被复制和粘贴，这可能意味着团队在不同的工作负载之间传播许多错误。策略引擎可以帮助您从“拉”请求阶段一直到生产阶段防止这些问题。

在开源策略引擎中寻找什么

最重要的是找到一个策略引擎，它可以随着您的组织对 Kubernetes 部署的成熟而成长。以下是你应该记住的三个基本要求:

它必须易于采用，尤其是在开始阶段。
寻找一个语法简单的引擎，或者一些可以立即实施的现成策略。
寻找支持定制策略的策略引擎；您不希望在六个月内超出您的策略引擎。

有各种不同类型的策略引擎，没有一个对所有组织都是完美的。

设计一个好的策略引擎和一个在整个组织中部署这些策略的好策略需要做很多工作。首先要考虑的是你要评价什么。是否存在安全问题、责任问题、一致性问题、成本问题？需要是 SOC2 兼容还是 PCI-DSS 兼容？您可能有针对这些用例的特定策略。

What to look for in an open source policy engineWhat to look for in an open source policy engine - policy, scope, integration points, automation

看看哪些策略引擎附带了您需要的内置策略。哪些将支持您想要应用的策略？一旦你对你想要应用的政策有了很好的认识，弄清楚在哪里和什么时候应用就显得尤为重要。

** 您是否有需要在生产环境中应用但不需要在开发和试运行环境中应用的策略？

您是否希望将这些策略作为代码应用于基础设施，而不是在每个生产环境中强制实施？
这些策略需要应用于系统级工作负载还是应用程序级工作负载？
您是否有仅适用于资源组的策略？例如，应用团队与集群附加组件。

策略引擎集成&自动化

您还需要考虑在集成点方面您需要什么。集成点在开发过程中尽早给开发者和 DevOps 工程师提供与政策问题相关的反馈。一个优秀的策略引擎解决方案将从拉请求一直集成到运行时和准入控制。您甚至可以使用策略引擎来更改文件或将配置从一种配置更改为另一种配置。

最后，你要考虑自动化。一旦策略违规或策略被触发，您希望如何处理？一旦这些策略中的一个被触发，您可能想要向 Slack 发送一个警报，打开一个吉拉票证，或者打开一个page duty警报，如果它是一个关键漏洞。您的策略引擎的集成点和自动化可以让您的工程师很容易地找到他们已经注意到的地方，并确保他们可以看到什么时候出现问题并采取行动。

开源策略引擎选项

有一些著名的开源策略引擎可用，比如 Polaris、OPA 和 Kyverno。这三个项目都让 Kubernetes 用户更容易理解政策。它们都是维护良好的项目，选择哪一个取决于用例以及您的组织。

开源策略引擎对比

Open Source Policy Engine Comparison

在您考虑的任何策略引擎中，确保它可以编写自定义策略。找一个有公共策略库的，因为你不想从头开始写每一个策略。每一个主要的引擎要么已经内置了一些策略，要么已经有一个社区编写并向 GitHub 推送策略，所以你可以将它们放入你的环境中。

寻找一个支持准入控制概念的策略引擎。您不想要一个只显示符合和不符合策略的引擎，而是一个可以在允许时阻止甚至可以在允许时改变它们以符合您的策略的引擎。一个变异准入控制器，它可以修改资源以确保它们符合您的策略，是一个很好的附加特性。

北极星让你轻松了解集群安装中的问题。它提供了一个仪表板，多个团队可以通过它查看未解决的问题。它还允许您尽可能向左移动，并自动修复底层 YAML 代码。很少有人意识到有一些通用的策略和实践需要在每个组织中强制执行，并根据业务需求进行调整。Polaris 预载了每个人都会犯错误的基准策略和最佳实践，从而使 Kubernetes 部署变得可靠、安全且经济高效。北极星是fair winds Insights平台的一部分，该平台为较小的集群提供了一个免费层。

【开放策略代理(OPA) 是一个不专属于 Kubernetes 的广义策略引擎；它可用于 Kubernetes、Envoy、Terraform、Kafka、SQL 和 Linux。它为云原生环境提供基于策略的控制。OPA 有一个声明性的策略语言，，你需要用它来写策略。OPA 是一个已经毕业的云本地计算基金会(CNCF) 项目。OPA 包含在 Fairwinds Insights 平台中，因为它是人们喜欢利用的标准。

Kyverno 是 Kubernetes 特有的；它在 CNCF 是一个孵化项目。在 Kyverno，策略作为 Kubernetes 资源进行管理。这意味着您可以使用 kubectl、git 和 kustomize 等工具来管理策略。

从开源 Kubernetes 策略引擎开始

组织需要一个易于使用的策略引擎，一个可以快速启动并运行的引擎，一个可以在 Kubernetes 成熟的不同阶段应用的引擎。为您的组织选择策略引擎时，请寻找可以在左移环境中运行的策略，以便您可以在开发的最早阶段扫描策略。策略引擎可以帮助您的组织应用并符合 Kubernetes 的最佳实践，因此您的部署是安全、经济和可靠的。

观看网上技术交流讲座“Kubernetes 的最佳开源策略引擎 ”以了解有关不同策略引擎、您可能想要开始使用的策略等更多信息。

高可用性对您意味着什么？

原文：https://www.fairwinds.com/blog/what-does-high-availability-mean-to-you

高可用性是对系统在相当长的一段时间内持续运行的期望。例如，一年中有 8，760 个小时，99%的可用性表示每月停机时间超过 7 小时，全年停机时间超过 88 小时。反过来，99.9%的可用性(即“三个九”)意味着超过八个小时的计划外停机时间，而 99.99%(即四个九)意味着不到一个小时。

谈到可用性，许多公司都关注单节点故障的可能性。此类故障的常见解决方法是运行主动/主动系统，这是一个由独立处理节点组成的网络，其中每个节点都可以访问复制的数据库，因此所有节点都参与到一个公共应用程序中。另一种解决方法是一个主动/被动高可用性集群，如果第一个节点出现故障，则使用第二个“备用”节点。

所选择的可用性策略通常取决于所讨论的堆栈的层。在两个 web 服务器上以主动/主动方式运行相同的内容是相当容易的，而主动/被动集群更常用于数据库，因为管理多个主动数据库主机可能是一个挑战。无论如何，要实现高可用性，系统应该通过适量的冗余来适应故障。

简而言之，如果你的系统不起作用，你就没有赚钱。当然，目标是保持正常运行。目标看起来很简单，但现实要复杂得多。

什么会出错？一切。

首先，确定系统的所有部分至关重要——一台机器、一个数据中心、一个位置的一个网络、一个云提供商——这些部分可能会出现故障，并且如前所述，将适当的冗余放置到位。

单机故障通常不需要太多的保护，并且可以快速恢复。为了提高可用性，您可以部署到多个可用性区域中的数据中心，其中几个服务器被分组到多个不同的位置。在单独的可用性区域中启动实例可以保护应用程序免受单点故障的影响。上面的可用性区域是区域，数据中心位于不同的地理区域，如东海岸和西海岸。对于多个区域，一个海岸的故障通常不会影响可用性。

一家中型公司的战略可能是这样的:

使用亚马逊关系数据库服务管理数据库可用性。
将数据库复制到多个可用性区域，以增加正常运行时间。
将应用程序部署到多个可用性区域。
确保所有应用程序都部署到至少两个节点上。

你需要几个 9？

这才是真正的问题。答案取决于你的要求。虽然一些组织将目标放在 100%的可用性上，但是大多数系统不需要达到这样的高度。核反应堆、导弹防御系统和股票交易所的故障成本很高，需要高可靠性，但 web 应用程序可能不需要这么高。

大多数小型企业不需要投资于高水平的容错，这可能需要大量的硬件和工程资源。每增加一个 9，成本就会成倍增加。

两个重要问题:

每小时停机时间的美元价值是多少？与解决问题的成本相比，这一成本如何？
您的系统实际需要多大的可用性？你需要五个九吗？三个九？99%够吗？

从小处着手，聪明成长

公司通常从一个可用性区域中的几个节点开始，然后发展到两个或三个可用性区域。随着停机成本的增加，公司开始寻找更昂贵的方案来提高可用性，例如多个地区和多个云提供商。

只有通过风险分析，你才能做出明智的投资决策，在成本、业务需求和风险承受能力之间取得平衡。关键是要评估失败的风险和相关成本，然后确定您的企业和您的客户需要的可用性。

修复 Kubernetes 集群的实际成本是多少？

原文：https://www.fairwinds.com/blog/what-does-it-really-cost-to-fix-your-kubernetes-clusters

采用 Kubernetes 来提高软件开发速度的组织总是遇到同样的问题——修复缺陷和配置问题的高昂成本。正如修复代码问题代价高昂一样，Kubernetes 的错误配置也是如此。

平均而言，企业每月花费大约 30-40 小时的工程审计时间，这是一项密集且耗时的工作。这项工作主要集中在识别所有的 pod 和容器，将错误的配置输入到电子表格中，并将这些信息传播给开发人员进行补救。

利用 Fairwinds Insights 节省资金

修复 Kubernetes 错误配置的成本不一定很高。借助我们的 Kubernetes 治理平台fair winds Insights，组织可以将配置验证流程转移到开发生命周期的早期，从而增强安全性、优化性能并使开发人员能够更快地创新和交付软件。

有兴趣了解利用洞察力可以节省多少钱吗？填写此登记表，获得您自己定制的成本节约分析。我们的团队将为您的企业提供潜在节约分析！

为了更清楚地了解洞察如何在避免风险的同时节省您的时间和金钱，请考虑一位 DevOps 工程师，他的年薪为 152，000 美元，日薪为 576 美元。在这种规模下，每月四天的工程审计每年需要 27，000 美元。随着团队和 Kubernetes 集群的增长，这个数字将会显著增加。如果一个团队每个月花 10 天时间进行工程审计，那么企业很容易每年花费 69，000 美元来手工审计他们的 Kubernetes。

Insights 平台通过生产力特性解决了这些成本问题，并且随着时间的推移，通过自动化手动任务减少了工程团队的手动工作，包括:

自动化审计，而不是手动执行审计
对问题进行优先排序，而不是要求用户筛选电子表格
自动化工作流，而不是手动创建票证或警报
为应用程序所有者提供自助服务，而不是要求开发人员修复所有问题

优化 Kubernetes 的资源

虽然许多组织声称过度调配 15-30%的 Kubernetes 集群，但我们知道合理调整您的容器化工作负载可以大幅减少这一数字。例如，Fairwinds Insights 的客户 Decisio Health 能够调整每个集群的节点和数据库数量。Decisio Health 的首席 DevOps 架构师 Glen Zangirolami 说得好:“这种理解帮助我们将每个集群的成本降低了 25%。随着 25 个或更多的 Kubernetes 集群投入生产并不断增长，这一成本节约是显著的。”

阅读我们最近的案例研究，了解 Decisio Health 如何利用 Fairwinds Insights 将每集群成本降低 25%。

更概括地说，一个团队每年为 10 个集群花费 20，000 美元，并且将所述集群超额配置了 20%,那么借助 Insights，该团队每年可以节省大约 40，000 美元。随着 Kubernetes 集群的增长，Insights 提供的节省也在增长。企业口袋里的钱越多，就意味着未来投资的钱越多。

确保 Kubernetes 的安全

假设宣布了一个新的 CVE。您的组织如何处理审计以确保您的 Kubernetes 基础设施不被破坏？事实是，团队每月花费三到五天(平均)来审计他们的 Kubernetes 集群。

Insights 平台会持续监控您的集群，防范安全威胁，因此您不必担心。当一个新的 CVE 出现时，您可以在 Insights 中构建一个自定义策略，以便更容易地了解您的容器是如何(以及是否)受到影响的。团队每年可以花费超过 38，000 美元，在四个工程日内，针对仅仅 12 个 CVE 审计 10 个集群。尽管这一数字随着集群和无处不在的 CVE 不断增长，但 Insights 可以通过自动化和报告来降低这一成本和暴露风险。

了解 Kubernetes 错误配置的修复成本

一般来说，维修成本的经验法则是 1:10:100。如果在需求和设计中修复一个缺陷花费 1 美元，那么在系统或验收测试中修复它将花费 10 美元——而在生产中修复将花费 100 多美元。

节省大量的时间和金钱意味着投资工具，使您的团队能够在开发过程的早期解决问题。团队发现 80%的问题在试运行中，20%的问题在生产中，他们会发现自己花费超过 25，000 美元来修复仅仅 20 个高优先级的问题。或者，使用 Fairwinds Insights，团队可以通过修复开发中 89%的问题和阶段中 20%的问题来减少大量支出。如果问题在生产前得到解决，团队可以节省大部分的维修成本。凭借洞察力，每年可以节省高达 10 万美元或更多。

完成此注册表格，获得您自己定制的成本节约分析。我们的团队将为您的企业提供更多潜在节约信息。

请注意:本文中概述的节约只是示例。关于潜在成本节约的详细分类，基于您组织的独特使用案例和环境，请联系您的 Fairwinds 销售代表或向我们发送消息了解更多信息。

伟大的辞职和 Kubernetes 有什么关系？

原文：https://www.fairwinds.com/blog/what-does-the-great-resignation-have-to-do-with-kubernetes

2021 年春天，单月辞职的工人数量打破了美国历史纪录。研究这种情况的经济学家称之为“大辞职”，并很快意识到情况只会越来越糟。到了夏天，各种不同行业的更多专业人士辞职去寻找更好的工作。

大辞职正在影响技术世界。领先的学习管理系统和招聘平台 TalentLMS 最近进行的一项研究预测，未来一年，企业可能会失去十分之七的科技员工。换句话说，美国 72% 的科技工作者目前正考虑在未来 12 个月内辞职。实际上，这种潜在的就业混乱意味着组织在建立、管理和扩展他们的 Kubernetes 所有权的过程中需要磨练一个关键的东西——即一致性。

一致性的价值是什么？

根据设计，现代云原生应用由许多更小的应用服务组成，这些服务被恰当地称为微服务。这样看来，Kubernetes 本质上是一个搭建平台的平台。

Kubernetes 可以在每个组织中进行不同的设置、配置和管理。一个工程师在一个组织中以一种方式配置的东西，另一个工程师在其他地方会以不同的方式配置。虽然它有利于整个行业，因为有一些标准化和一致性，但在一个组织内也可能有许多 Kubernetes 未知。

虽然这个过程是有效的，但它会使一致性成为 Kubernetes 的一个挑战。当考虑到未来 12 个月内一些从业者可能会离开你的组织，你是如何准备的？

建立 Kubernetes 护栏

实现一致性的第一步是建立你的 Kubernetes 护栏或政策。不幸的是，经常发生的情况是，政策被写在纸上，却没有办法执行。当使用 Kubernetes 时，这意味着错误配置的集群，而当错误配置时，您可能会面临安全风险、停机或资源浪费。当你的团队已经存在一段时间时，这是一个很难解决的问题，现在再加上人员流动、培训和人工执行，你已经很头疼了。

开发团队的领导者必须为他们的团队设置可以自动化和强制执行的护栏。通过这种方式，可以建立策略、设置护栏并避免错误配置的负面后果。

持续维护 Kubernetes

大辞职背后的一个主要动机似乎是对正在做的工作普遍缺乏支持。就技术而言(更具体地说，是 Kubernetes)，缺乏合适的 IT 工具正在打击高级专业人员的士气。该行业的许多工作人员表示，数字化转型的优先事项应该更少地关注金钱上的成功，而更多地关注如何让工作人员和开发人员能够构建和部署安全、高质量的软件。

当策略和工作流在微服务和设置的防护栏内被很好地建立时，开发者被授权以更多的所有权更快地开发。操作员可以通过对集群的了解来确定他们的团队是一致的，并且符合既定的业务需求。

当考虑大辞职时，如果一个开发人员突然离开，那么如何有效地管理多个集群、工作负载和团队就有了明确的基础。

通往一致性的道路

Fairwinds 为 DevOps 领导者和平台工程师提供其 Insights 平台，以帮助他们在开发生命周期的每个阶段应用 Kubernetes guardrails——CI/CD 期间、准入时和生产中。Fairwinds Insights 使领导者能够了解 Kubernetes 上的强制护栏并与之保持一致。

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

使用 Fairwinds Insights 的团队可以让开发人员使用一致的防护栏快速开发，从而增强他们的能力。它帮助团队更快地发布应用程序，而不必手动检查集群以查看它们是如何配置的以及是否进行了修复。

团队不再怀疑他们的 Kubernetes 集群是否安全、可伸缩、可靠或具有成本效益。相反，他们可以了解 Kubernetes，从而获得云原生开发的优势。

posted @ 2024-10-31 16:53 绝不原创的飞龙阅读(0) 评论(0) 编辑收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

Firewinds-博客中文翻译-一-

Firewinds 博客中文翻译（一）

2023 年云原生预测

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

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

安全仍然是一个问题

网络安全将变得流行

Kubernetes 护栏成为主流

云原生自动化推动改进

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

云提供商希望锁定 Kubernetes 用户

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

CPU 请求和限制

内存限制太高

内存限制太低

内存请求太低

内存请求过高

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

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

2023 年 Kubernetes 最关心的是什么？

DevOps 队寡不敌众

可靠性

安全性

成本效率

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

Kubernetes 的 22 个基本概念

工作量

Pod 控制器

配置

建立工作关系网

安全- RBAC

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

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

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

3.忽略自动缩放

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

RBAC

政策

基础设施代码扫描

Kubernetes 护栏助您安全快速移动

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

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

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

set_fact 很粘

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

关于 FinOps 和 Kubernetes 的 3 件事

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

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

3.你需要合适的工具

KubeCon EU 值得期待的 3 件事

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

2.社区，社区，社区

3.做点好事

好伙伴:如何运作

浮力 Linkerd 的创造者

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

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

Fairwinds — Kubernetes 治理和安全性

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

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

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

1.有用和无用的数据

2.问责文化

3.行动偏好

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

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

决心 2:停止浪费金钱

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

可实现的 Kubernetes 分辨率

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

SOC 2 的世卫组织和原因

SOC 2 的 4 大技巧

FAIRWINDS INSIGHTS 和 SOC 2

关于 KINTENT

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

1。学习你不知道的东西

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

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

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