Firewinds-博客中文翻译-二-

Firewinds 博客中文翻译（二）

原文：Firewinds Blog

协议：CC BY-NC-SA 4.0

什么是 Kubernetes 治理？

原文：https://www.fairwinds.com/blog/what-is-kubernetes-governance

Kubernetes 治理是组织用来定义如何管理和维护 Kubernetes 的一套政策和程序，它是企业如何规模化生产的重要组成部分。Kubernetes 治理包括管理 Kubernetes 资源、调度、升级和基于角色的访问控制。它还包括关于 Kubernetes 的决策过程，比如如何管理安全问题、错误修复和特性请求。

Kubernetes 提供了一个可移植的开源平台，使组织能够管理容器化的工作负载和服务。它提高了各种规模的公司交付可伸缩和可扩展的云原生应用程序的能力，以及开发团队承担 Kubernetes 服务所有权 的能力。使用 Kubernetes，内部团队可以更容易地开发系统和部署应用程序和服务。虽然 Kubernetes 提供了许多重要的好处，但它也为开发、运营和安全团队引入了新技术和不同的复杂性。随着 Kubernetes 部署的规模和范围的增长，缺乏治理框架会导致问题。管理单个 Kubernetes 集群是一个不可忽视的学习曲线，但是一旦一个组织开始管理多个集群，特别是跨不同云提供商的混合云或多个云，这将成为一个更大的挑战。一些挑战包括:

• 缺乏对 Kubernetes 集群活动和增长的了解

• 管理组织内的多个软件版本并进行故障排除

• 在多个团队和环境中定义用户角色、职责和权限变得很难跟踪

• 识别角色违规、执行合规检查和评估治理风险非常耗时

• 管理政策和程序很难跨团队实施

Kubernetes 治理确保您的组织创建流程、明确任务并设置优先级，以成功实施和运行 Kubernetes。Kubernetes 治理计划帮助您确保这个复杂的环境满足您组织的政策要求，遵循最佳实践，并满足您所在行业的法规要求。

为什么 Kubernetes 治理如此重要？

Kubernetes 治理框架为组织提供了许多好处，包括帮助确保 Kubernetes 环境的安全性、合规性和优化性。它有助于组织遵循最佳实践并遵守公司政策和法规。它还创造了一个团队可以轻松协作和管理工作负载的环境。这有助于确保环境稳定、安全和高效。

Kubernetes 的一致性

大规模运行 Kubernetes 基础设施几乎保证了广泛的组件和配置，以及您的组织中具有稍微不同的基础设施需求的多个团队。Kubernetes 提供了许多使用命令行和用户界面来启动和配置组件的功能。多个人和团队调整单个组件以满足这些需求不可避免地导致缺乏一致性，这使得 Kubernetes 更加难以管理。

配置漂移

配置漂移 是指在一个基础设施中运行 Kubernetes 集群时，随着时间的推移，配置会变得越来越不同，这通常是因为对单个集群进行了手动更改和更新。最终，这种差异存在于存储在 git 中的内容和运行在生产环境中的内容之间。有时，开发团队可能会从其他团队“复制和粘贴”示例配置，这样他们就可以快速启动并运行。然而，这也可能导致团队继承不好的实践。配置偏差不仅意味着底层配置的差异，还可能意味着应用于工作负载的不同标准。

如果您设置了一个流程来确保一致的自动化资源调配，那么您的集群在创建时将是一致的。不幸的是，由于开发团队、运营团队或 DevOps 团队对配置参数的更新，在该集群或其他集群上进行资源调配后可能会发生更改。当您的组织运行大量手动部署的集群并且现在配置不一致时，Docker 容器和 Kubernetes 集群之间的配置将不可避免地存在差异。这些差异可能难以识别和纠正。与配置漂移相关的一些负面结果包括:

• 安全漏洞: 错误配置可能导致权限提升、易受攻击的映像、来自不受信任的存储库的映像或以 root 或特权身份运行的容器

• 低效的资源利用: 当工作负载过度调配或过时的工作负载未得到审查和纠正时，成本可能会慢慢增加。

• 停机和可靠性风险: 应用或服务扩展不足或扩展过于频繁可能导致停机或降低可靠性。

运营成本

手动跟踪配置漂移和修复错误配置是一项具有挑战性、易出错且持续进行的任务。这增加了运营团队的成本，因为跟踪和解决问题需要花费大量时间。配置漂移可能会导致更多的不一致性，这会对升级过程产生负面影响，因为每个升级路径都需要进行独特的研究，以确保升级后一切仍然正常。这会增加流程的时间，浪费时间和运营资源。一致的基础架构可以帮助您一次性研究升级和修补方案，然后将其应用于多个环境。

Kubernetes 服务所有权

在 Kubernetes 和软件开发领域，服务所有权被定义为开发团队在整个服务生命周期中负责支持他们交付的产品和服务的方式。这种服务所有权模型让开发团队能够更好地控制他们的软件和服务在生产环境中的运行方式。它还允许运营团队将更多的精力放在维护和改进核心基础设施上，而不是跟踪错误和优化应用程序。

启用自助服务

在自助服务模式中，DevOps 和基础设施领导者允许许多用户跨许多不同的 Kubernetes 集群进行开发和部署。随着越来越多的团队将 Kubernetes 部署到生产环境中，DevOps 团队越来越难以手动编写或审查部署到集群中的每个 Dockerfile 和 Kubernetes 清单。创建一组 Kubernetes guardrails 并自动执行它们允许开发人员自助服务，并防止意外引入安全风险、低效的云资源使用和应用程序性能问题。

赋能开发者行动

使用这些防护栏并在平台级别实施这些策略，可以在整个组织中应用一致性，让开发人员放心，他们不会无意中部署可能会将他们的公司甚至工作置于风险之中的应用程序或服务。开发团队也有权构建应用程序和服务，并运行集群，而不必担心破坏其他东西。这样，他们可以更专注于编写和部署，而不是担心出错。

*服务所有者负责开发、运输和拥有他们的服务，这比他们过去能够承担的责任多得多。他们现在必须确保应用程序可靠且性能良好，提供新功能，修补代码中的错误和漏洞，解决 Docker 容器中的错误配置，维护文档等等。正确的开源工具(通常在 GitHub 上可用)可以支持这些服务所有者承担新的责任，并确保更具成本效益和更安全的应用程序和服务。

飞船应用程序更快

服务所有权还允许所有者通过支持自助服务和使开发人员能够比以往更快地开发、测试和部署应用程序，从而更快地交付应用程序。当 DevOps 团队围绕谁拥有应用程序不同部分的服务所有权并对这些所有者有足够的了解时，他们可以监控 Kubernetes 集群中发生的事情，并洞察谁在修补哪个漏洞，在哪里，什么时候，而不是想知道谁负责采取行动。

提高 Kubernetes 的安全性

Kubernetes 治理模型通过建立一种策略来提高 Kubernetes 的安全性，以确保对 Kubernetes 环境的更大可见性，更好地理解可能导致安全性和合规性风险的错误配置，并减少漏洞管理所需的时间。Kubernetes 安全性有几个重要的方面必须纳入到任何 Kubernetes 治理模型中。

Kubernetes 默认不安全

许多 Kubernetes 工作负载设置实际上是“默认不安全的”——它们授予应用程序权限来做它可能需要或可能不需要的事情。这里的权衡意味着开发人员可以快速启动并运行应用程序，但没有安全最佳实践。例如，默认情况下，每个容器都安装有一个可写的根文件系统。这可以为攻击者提供替换系统二进制文件或修改配置所需的权限。Kubernetes 确实提供了许多内置的安全特性，比如 Kubernetes 基于角色的访问控制()、 网络策略，以及准入控制器。Kubernetes 治理必须考虑这些默认配置，并为 Kubernetes 部署包含安全第一的思想。对于任何采用 Kubernetes 的组织来说，审查安全策略都是至关重要的一步。

左移工装

在 DevOps 中，左移方法将以前发生在软件开发生命周期(SDLC)后期的任务“左移”到早期阶段。将测试转移到 SDLC 的早期可以在开发过程的早期发现设计或代码问题，从而加快开发和发布周期。在 Kubernetes 中，应用程序和服务的部署比传统环境中要快得多，因此采用支持和实施左移方法的工具对于尽可能快速和安全地部署应用程序和服务至关重要。

降低合规成本

容器和 Kubernetes 等云原生技术为合规性带来了新的挑战。当在容器化的工作负载中部署时，开发团队必须从设计和开发阶段开始，尽可能地将安全性和合规性转移到左边。它还需要从开发到生产的整个过程中对应用和服务的可见性和控制。设置与 SOC 2 控制、HIPAA、ISO27001 和其他法规相对应的护栏，有助于组织了解合规性状态，以满足日益增长的合规性需求。

Kubernetes 治理原则

以下五个原则为构建您的 Kubernetes 治理模型提供了一个极好的起点:

1. 与业务目标保持一致 — Kubernetes 战略应该是整体业务和 IT 战略不可或缺的一部分。所有 Kubernetes 系统和政策都必须支持业务目标。

2. 协作—Kubernetes 基础设施所有者和其他利益相关方之间必须有明确的协议，以确保 Kubernetes 得到适当和有效的使用。

3. 变更管理 —必须根据 Kubernetes 最佳实践 一致地实施对 Kubernetes 环境的所有变更，并与适当的组织控制保持一致。

4. 动态响应 —Kubernetes 治理应该依靠监控、工具和策略自动化来有效地管理 Kubernetes 环境。

5. 政策和标准合规— Kubernetes 的使用标准必须符合贵组织内部和行业内其他人使用的相关法规和合规标准。

如何设计和实现 Kubernetes 治理

Kubernetes 治理是制定政策、标准和程序的过程，这些政策、标准和程序起到护栏的作用，以确保组织内 Kubernetes 的安全性、合规性和成本效益。

要开始 Kubernetes 治理项目的设计和实现，请从以下方面着手:

1. 创建 Kubernetes 治理团队 :召集一支了解 Kubernetes 和组织需求的专家团队，包括来自开发、运营、安全和合规团队的成员。

2. 建立政策和标准: 建立使用 Kubernetes 的政策和标准，特别是安全性、合规性和成本效益。

3. 制定流程和指导方针: 制定流程和指导方针，以验证治理策略和标准已成功实施，包括批准和沟通流程。

4. 监控和执行策略: 监控和执行策略和标准，以确保它们被遵循；实施工具化和自动化来实施 Kubernetes 护栏 减少了复杂 Kubernetes 环境中固有的挑战。

5. 审查和更新: 定期审查和更新政策、标准和流程，以确认它们随着时间的推移仍然满足组织的需求。

Kubernetes 部署最佳实践

Kubernetes 使组织能够提高容器的可用性和生产率，并构建云原生应用程序。为了最大限度地发挥 Kubernetes 实施的优势，必须遵循以下五个 Kubernetes 最佳实践:

1. 安全 配置在 Kubernetes 中默认不设置；这些是您的安全团队必须建立并实施的设置，最好是通过自动化和可靠的策略。

2. 成本优化 要求您设置资源请求和工作负载限制，以最大限度地提高基础设施利用率，同时确保最佳应用性能。

3. 可靠性 在 Kubernetes 中，这是一项复杂的任务，但 IaC 通过减少人为错误、增加一致性、提高可审核性和简化灾难恢复使之变得更加容易。

4. 策略执行 一旦 Kubernetes 部署增加到单个应用程序之外，策略执行就变得至关重要。通过工具和自动化实施策略有助于防止常见的错误配置，实现 IT 合规性，并促进服务所有权模式，因为用户知道有护栏来实施策略。 开放策略代理 (OPA)是一款面向云原生环境的开源工具，提供基于策略的控制。

5. 监控和警报 帮助确保您的基础设施和应用程序正常运行。这需要工具来优化监控，确定需要监控的内容和原因，并在部署之前发现错误配置。

【Kubernetes 政策入门

集群范围策略

一般来说，组织可以部署集群范围和特定于名称空间(或特定于应用程序)的策略。集群范围的策略往往适用于所有工作负载，可能涵盖安全性、效率和可靠性类别。这些是一般的经验法则，平台和安全团队可以根据具体情况批准例外。

以下是几个例子:

• 应设置存储器请求

• 应设置 CPU 请求

• 应设置活性探针

• 应设置就绪探测器

• 图像拉取策略应该是“始终”

• 集装箱不应具有危险能力

命名空间策略

特定于命名空间的策略用于为特定的应用团队或服务强制实施标准，以提高安全性、效率或可靠性。例如，您可以使用名称空间在一个共享的 Kubernetes 集群中创建不同的“租户”,供团队申请。您希望这些团队遵守一组通用的最佳实践，避免对其他集群租户造成破坏，例如资源耗尽或违反安全。

一些例子可能包括:

• 容器不应具有不安全的功能

• 不应配置主机 IPC

• 不应配置主机 PID

• 不应允许权限提升

• 不应以特权身份运行

• 应该指定图像标签。

• 应设置名称空间配额

执法点

这些策略的实施可以分多个阶段进行。最终，Kubernetes 治理的“执行”功能就是在工程师需要的时候，用他们使用的工具向他们提供反馈。

如果您有一个运行生产工作负载的现有集群，您可以首先选择根据这些集群范围和命名空间策略对您的集群进行基准审核。这将有助于提高问题的可见性，从而实现更大的服务所有权。

接下来，您可以在 CI/CD 阶段(使用左移工具)和部署时(使用准入控制器)集成这些策略。您可以选择让这些策略“警告”用户，但实际上并不阻止管道或部署——这有助于在流程的早期带来更多可见性，并在问题发布之前捕捉到它们。

最后，推行策略实施的最后一个阶段是实际实施。此时，策略处于“活动”状态，并在发现问题时阻止管道或部署。流程中的这一步通常是在团队对需要修复的配置类型感到满意时进行的。

理想情况下，第一次将容器迁移到 Kubernetes 的组织应该从一开始就集成实施。这提高了 Kubernetes 治理的标准，并通过确保工作负载从一开始就正确运行，使团队能够更快地迁移工作负载。

Kubernetes 成本和效率

费用分配

Kubernetes 的支出与部署应用和服务的集群数量以及配置方式成正比。报告多租户集群的成本并将成本分配给正确的所有者是一项挑战。Kubernetes 部署依赖共享和外部资源的瞬时工作负载。使用是以秒为单位来衡量的，跟踪一个工作负载所使用的 Kubernetes 资源可能很困难。随着 Kubernetes 环境的增长，集群和节点的数量也在增长。必须监督支出，以避免浪费 Kubernetes 的资源；因此，平台工程团队必须能够在业务相关的环境中分配和显示成本，并与工程团队一起创建反馈循环，以实现服务所有权文化。

资源标注

将成本映射到 Kubernetes 组件，比如名称空间或标签，有助于将成本恰当地分配到各个业务单元。Kubernetes 垂直 Pod 自动缩放器(VPA)使用工作负载的历史内存和 CPU 使用情况以及 Pod 的当前使用情况来生成资源请求和限制的建议。Kubernetes 中的节点标签允许您标记您的节点。您可以将 pod 配置为使用与特定节点标签相匹配的特定“节点选择器”，这些标签决定了可以将 pod 调度到哪些节点上。使用经过适当标记的不同实例类型的实例组，可以使您选择的公共云或私有云提供商提供的底层硬件与您的 Kubernetes 工作负载相匹配。如果没有资源标签，就很难恰当地分配成本，并就成本、优化和云支出做出明智的决策。

成本规避与优化

根据 FinOps 基金会的说法，成本规避意味着减少使用和优化成本，以获得更好的云速率。避免成本所需的大多数行动都依赖于工程师。平台工程团队可以使用 Kubernetes 更快速地交付应用程序，通过优化云使用降低成本，并通过实施 Kubernetes 安全功能降低风险，从而避免成本并提高优化。Kubernetes 治理可以通过自动执行考虑到安全性和成本的策略来避免成本并提高优化。

Kubernetes 安全

基建照码扫描

基础设施即代码(IaC)支持使用配置语言来配置和管理基础设施。这将现代软件开发的可重复性、透明性和测试应用于基础设施管理。IaC 的主要目标是减少误差和配置漂移，使工程师能够专注于更高价值的任务。使用 IaC 为 Kubernetes 用户、提供了显著的、优势，例如减少人为错误、可重复性和一致性、改进变更跟踪和灾难恢复。基础设施即代码扫描是根据一组策略和 Kubernetes 最佳实践扫描 IaC 文件的能力，这有助于组织确保符合 Kubernetes 的治理目标，如应用程序安全性、可靠性和成本。

集装箱图像扫描

容器使开发团队能够为不同的环境和部署目标构建、打包和部署应用程序和服务，因此保护容器的完整性对于在云原生环境中构建和部署的组织来说至关重要。容器构建在基本映像上，这是 Linux 容器的起点。基础映像中的漏洞将存在于包含该基础映像的每个容器中。为您的基本映像找到一个可靠的来源，保持修补程序的最新状态，控制权限，并限制使用部署到生产环境中不需要的其他映像，这些都有助于提高容器映像的安全性。 扫描图像 和 检测错误配置 仍然很关键，因为 常见的漏洞和暴露 (CVEs)可以随时引入。扫描容器及其所有组件以识别安全漏洞是容器安全的关键组成部分，因此也是 Kubernetes 治理的一个重要方面。

Kubernetes 可靠性

弃用的 API

随着时间的推移，Kubernetes 弃用不同版本的 API，以减少对旧 API 的维护，并确保组织使用更安全的最新版本。如果您的应用程序或服务包含 已弃用或已移除的 API 版本 ，找到它们并将其更新到最新的稳定版本非常重要。

升级插件

附加组件 扩展 Kubernetes 功能。像其他软件一样，加载项需要升级，但首先您必须验证最新版本是否与您的群集兼容。这个过程可能非常耗时，尤其是对于管理多个集群的团队。除非有工具可以自动检测附加组件的变化，否则监控更新和升级会很慢且很困难，但不这样做可能会对服务产生负面影响。

立方遵约

政策执行与护栏

在拥有多个 Kubernetes 集群、开发人员团队和服务所有权模型的组织中，拥有定义的策略和执行这些策略的自动化方法是至关重要的。部署防护栏和策略可以让开发、安全、运营和领导团队高枕无忧，因为自动执行策略和防护栏可以防止最后一刻的更改，这些更改可能会破坏生产环境、导致数据泄露或导致配置无法正常扩展。Kubernetes 策略实施支持自动化、监控和实施 Kubernetes 的护栏和最佳实践。

自动化合规分析

向云原生技术(如 Docker containers 和 Kubernetes)的转变带来了与合规性相关的新挑战。大多数组织都需要遵守安全和隐私法规，包括 SOC 2、HIPAA、GDPR ISO27001、PIPEDA 等等。使用已定义的 Kubernetes 合规性需求策略并在所有集群中自动实施这些策略是至关重要的，自动化合规性分析以确保满足不断变化的需求的能力也是如此。

Kubernetes 护栏和治理

传统的治理模式减缓了团队的速度，并成为有效实现目标的障碍。Kubernetes 治理提供了一种与云原生计算战略相一致的新模式。组织可以自动应用护栏来实施和执行策略，而不是增加官僚主义。通过创建流程，明确任务，并在一开始就设置优先级，您可以创建策略来帮助您成功地实现和运行 Kubernetes。最重要的是，Kubernetes governance 将帮助您最大限度地提高平台投资，同时满足您组织的政策要求，坚持最佳实践，并满足相关法规要求，而不会减缓应用程序和服务的开发和部署。

*

什么是 Kubernetes 政策代码？

原文：https://www.fairwinds.com/blog/what-is-kubernetes-policy-as-code

从基础设施代码到政策代码

不久前，人们开始将基础设施视为代码。部分原因是云原生空间中的技术成熟的速度有多快。不久前，基础架构还只是有形的基础架构，您必须在数据中心走动，按下物理机的按钮，移动机架，调整电线以改变基础架构，因此 IaC 是一个令人兴奋的飞跃，只是在最近云的出现才成为可能。 基础设施作为代码与 Kubernetes 一起减少人为错误，加强可重复性和一致性，提高跟踪和可审计性，并帮助进行灾难恢复

人们已经看到了基础设施作为代码存在的好处，因此它正在成为更广泛采用的云最佳实践。

在这个日益云化的世界中，下一个合乎逻辑的步骤是 Kubernetes 的政策即代码(PaC)。在 IaC 的类似历程中，不久前(在某些情况下仍然如此),许多公司的政策都是由以下机构强制执行的:

• 大楼门口的保安人员检查人们的包，检查哪些东西可以带进或带出

• 经理们在办公室里走来走去，越过人们的肩膀，确保他们在做正确的事情

• 长长的“政策文件”,公司真的只是交叉手指，希望人们会遵循

什么是政策代码

定义:作为代码的策略是通过机器可读的定义文件，而不是最佳实践文档或交互式配置工具(带有可点击按钮的 GUI)来管理和提供策略实施工具的过程。

策略的自动化可以通过几种不同的工具来完成，但其中许多工具都涉及到一个大型复杂的图形用户界面(GUI ),一个人可以点击一系列按钮，直到他们实施控制来满足公司标准(桌面合规性、基础架构等)。).但是自动化是不够的，因为它可能会产生单点故障——例如一个人记得在 GUI 中按下所有按钮——当他们离开公司时会发生什么？。

因此，以代码形式记录和存储的策略正在成为行业标准。在 Kubernetes 中，策略作为代码的美妙之处在于它允许您:

• 跟踪策略随时间的变化

• 包括策略实施的“为什么”的信息

• 编写本身成为文档形式的代码，以消除单点故障

Kubernetes 政策的未来代码

正如基础设施即代码已经成为广泛采用的标准一样，Kubernetes 的策略即代码也朝着同样的方向发展，因此定义基础设施的代码以及定义如何使用基础设施的代码都可以存储在一个可跟踪的存储库中。成熟的云组织会发现，保持“最佳实践文档”，同时交叉手指并真正希望他们的员工遵守规则，在规模上是不够的。虽然大规模自动化这一过程的工具是必不可少的，但仅此还不够。

团队将寻找一种方法来存储指令，以便大规模实施策略自动化。

在 2021 年的云原生世界中，预计将会看到作为代码的策略像过去几年 Kubernetes 一样成为热门词汇。

下一步是什么？

对作为代码的策略感兴趣？查看 Fairwinds Insights ,其中包括大量的 Kubernetes 现成的政策代码。

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

它利用了 Kubernetes 在安全性、效率和可靠性方面的最佳实践中的同类最佳开源工具，并支持开放策略代理来编写您自己的自定义策略，并强制实施在您的集群中部署的内容。

费尔温德见解。Kubernetes 开箱即用中的策略代码。

什么是 Terraform，为什么它很重要

原文：https://www.fairwinds.com/blog/what-is-terraform-and-why-is-it-important

运行任何规模的基础设施几乎总是会带来令人眼花缭乱的组件和配置。更复杂的是，一个组织中的不同团队可能需要相似的基础设施，只是略有不同。该基础架构可能分布在多个拓扑结构上，从内部部署到一个或多个云供应商。

虽然可以使用基础设施提供商的用户或命令行界面一次启动和配置一个组件，但最终结果通常很难以简单明了的方式组织和维护。

在 Fairwinds，我们为客户构建可扩展、安全可靠的 Kubernetes 基础设施。除了使用 Kubernetes 运行应用程序，我们的工作还包括配置网络、计算资源、存储以及监控等支持组件。为了确保为我们所有的客户维护构建基础设施的最佳实践，我们为我们的客户使用通用模式，在需要的地方提供一致性和定制。

Terraform 是我们管理基础设施整个生命周期的首选工具，使用基础设施作为代码。这意味着在配置文件中声明基础设施组件，然后 Terraform 使用这些组件在各种云提供商中提供、调整和拆除基础设施。

例如，假设您正在 AWS 中工作，并且想要旋转几个特定类型的 EC2 实例。您将在配置文件中定义实例的类型和数量，Terraform 将使用它与 AWS API 通信来创建这些实例。然后可以使用同一个文件来调整配置，例如增加或减少实例的数量。

因为基础架构通常包括比计算实例多得多的组件，所以我们使用称为模块的 Terraform 功能将多个基础架构组件组合成大型、可重用和可共享的块。

在由四部分组成的博客系列中，我们将展示如何使用 Terraform 模块在三个云提供商中轻松建立一个基本的 VPC 和 Kubernetes 集群: AWS 、 GCP 和 AKS 。

Terraform 核心元素

在这篇文章的剩余部分，我们将深入了解 Terraform 的一些核心元素。如果你从未使用过 Terraform，并且正在寻找更多的实践经验，Hashicorp 网站上的教程会很有用。

让我们来谈谈平台提供商。Terraform 服务的云提供商超过 100 家。在 Fairwinds，我们将 Terraform 用于三种 AWS-、、【GCP】、 Azure 。提供者支持与特定 API 的接口，并公开您定义的任何资源。HCL 或 HashiCorp 语言是用于定义资源的通用语言，不管使用什么提供者。

在任何使用 Terraform 的项目中，需要定义的第一个资源是提供者，因为这是您访问 API 的途径，您将与 API 交互以创建资源。一旦配置和验证了提供者，现在就可以创建大量的资源了。每个云提供商都有自己的一套资源；几个例子是一个aws_vpc,``google_dns_record_set,和一个 azuread_application. 资源，根据 Terraform，是“Terraform 语言中最重要的元素”。这是您描述要创建的基础设施的地方；这可以从计算实例到定义特定权限等等。

在大多数情况下，您将需要比 Terraform 文档中显示的基本示例更多的配置，用于 AWS 的 terraform vpc 资源详细提供了必需和可选的参数参考；以及您可以访问该资源中的哪些属性。通过使用这些文档，你可以利用 Terraform 获得许多资源，这些资源可能会满足你的所有需求。

既然我们已经概述了 Terraform 如何与各种提供者交互来创建和管理资源，那么让我们来谈谈维护和组织项目的最佳实践。

模块:打包和重用代码

Terraform 提供了一种很好的方式来以模块的形式封装和重用公共代码。Terraform 模块相当于脚本或编程语言中的函数或方法。它们通过提供输入和返回输出来提供创建资源的标准接口。模块还通过增加可读性和允许团队在逻辑块中组织基础设施来简化项目。模块可以很容易地共享，并提供给任何 Terraform 项目。

模块通常用作创建和管理多种资源的简单界面。这大大减少了项目中重复代码的数量。复制和粘贴代码片段，同时只更改几个参数，这可能会很乏味。例如，如果任务是为不同的环境创建多个 VPC，那么可以多次调用单个 VPC 模块，而不是为一个完整运行的 VPC 创建每个必要的资源。

输入变量用于定制模块的行为，以及潜在的资源命名方式。有些模块可以非常灵活地决定如何以及是否创建资源。例如，我们的谷歌云 VPC 模块可以根据声明的输入改变行为。如果用户设置了 enable_cloud_nat = true ，该模块将创建额外的云 NAT 资源。查看官方文档了解更多关于输入变量的信息。

与函数类似，Terraform 模块也可以返回输出。这个输出可以用作另一个模块或资源的输入。

状态管理

状态管理是任何长期地形项目的关键组成部分。Terraform 状态文件跟踪环境中的所有变化。状态文件也可以作为数据源，由其他 Terraform 项目导入。默认情况下，状态文件存储在文件系统中。然而，保持状态文件的安全、可靠和备份是很重要的——这通常意味着将它保存在高度可用的对象存储中。通过利用这种远程存储，团队可以安全地共享和交互始终最新的单一状态。如需更多信息，请查看远程状态的 Terraform 文档，此处为。

如何使用 Terraform 构建 Kubernetes 基础设施

在接下来的博客中，我们将深入探讨这些话题，展示如何使用 Terraform 在不同的云提供商中构建 Kubernetes 基础设施。查看我们针对主要云提供商的入门指南:

资源

Kubernetes 和应用程序安全性的共同点是什么

原文：https://www.fairwinds.com/blog/what-kubernetes-and-application-security-have-in-common

在过去的八年里，我花了大量时间帮助企业构建应用程序安全程序和开发安全产品，使开发人员和安全团队能够更轻松地完成共同的使命。

我通常将我过去的经验称为“测试左边的一切”，这意味着它主要集中在开发人员工具和持续集成(CI)上。也许你称之为 DevSecOps 的“DevSec”部分。然而，现在我已经加入了 Fairwinds ，我已经涉足了无所不包的持续部署(CD)和运营。我的新偏见受到了 Fairwinds 的核心使命的影响——帮助企业成功过渡到像 containers 和 Kubernetes 这样的云原生技术。

核心任务继续

随着 DevSecOps 的发展，最大的收获是看到了核心业务挑战的延续:加速开发速度，同时保持可靠性、可伸缩性和安全性。

即使在 Kubernetes 和 containers 的世界中，这两个业务目标仍然处于紧张状态。Kubernetes 正在通过技术采用生命周期，并开始成为主流解决方案。主流意味着取得平衡——提取足够的基础设施层，这样开发人员可以自由部署，而不会失去重要的治理和风险控制。

应用程序安全性比 Kubernetes 走得更远。我们知道这一点，因为它已经成为任何企业开发过程的重要部分。基于 SaaS 的平台已经成为将测试集成到 CI/CD 管道中的事实上的方法，而且还提供了 AppSec 项目所需的集中治理和报告。这种基于云的自助式完全集成方法使安全团队能够在不影响可见性的情况下与开发人员会面。

历史重演

Kubernetes 部署——管理无状态微服务如何在集群中运行——仍然会给开发、安全和运营带来麻烦。虽然开发团队创建集群和集成监控工具变得更加容易，但是配置和管理部署的过程仍然很复杂。

对于不熟悉 Kubernetes 甚至基础设施即代码的开发团队来说，很容易忽略部署配置的一些关键部分。例如，在没有准备就绪和活动探测的情况下，或者在没有资源请求和限制的情况下，部署可能看起来工作得很好。从安全的角度来看，当部署被授予超级用户访问权限时，这并不明显。

幸运的是，可以从应用程序安全领域学到一些经验。

Fairwinds 最近推出了两个开源项目——fair winds Polaris和fair winds Goldilocks——来应对这一挑战。Fairwinds Polaris 帮助工程师保持其部署清单符合最佳实践，检测与安全、网络、容器图像等相关的问题。Fairwinds Goldilocks 通过为 Kubernetes 部署推荐资源请求和限制(主要是 CPU 和内存设置)来节省工程时间。这两个开源工具都非常适合从开发到生产的交接，在发布之前为开发人员提供了一个反馈循环。

我们的 SaaS 平台fair winds Insights，旨在为企业解决“单一平台”需求。我们认为 Fairwinds Insights 是一种提供 Kubernetes 集群和部署配置可见性的重要方式，因此可以在多个团队之间轻松地对改进进行优先排序和规划。

Kubernetes 部署验证的新时代使开发团队能够快速行动，同时避免生产中代价高昂的安全性或可靠性问题。确保应用程序不仅安全地构建，而且安全地部署，这就是 DevSecOps 对于云原生应用程序开发如此重要的原因。让我知道你的经历和你的想法！

Kubernetes 即服务对 DevOps 意味着什么

原文：https://www.fairwinds.com/blog/what-kubernetes-as-a-service-means-for-devops

微软最近开始用 AKS (Azure 容器服务)提供 Kubernetes 即服务，就像谷歌用 GKE(谷歌 Kubernetes 引擎)一样。在不久的将来，亚马逊很可能会步他们的后尘。亚马逊进入 Kubernetes 即服务领域的预期很重要，原因有很多，其中一个重要的事实是，它标志着 Kubernetes 全面支持的可能性。

带着这个想法，我想更深入地了解一下 Kubernetes 云服务正在发生的事情，以及这些发展对行业意味着什么。

Kubernetes 即服务符合云服务范式

建立一个 Kubernetes 集群曾经很困难。真的很难。虽然所有的概念和组件都存在，但 Kubernetes 最初是一个自己动手的项目，有许多手工步骤。涉及到许多复杂的决策——您必须生成证书，使用正确的角色和权限启动虚拟机，运行 etcd 集群，选择 CNI 提供商，安装软件包，然后使用云提供商设置、IP 地址、DNS 条目等构建配置文件。除此之外，事实上并不是所有的东西都像预期的那样工作，所以业内许多人一开始对使用 Kubernetes 犹豫不决也就不足为奇了。

随着 kops 和 kubeadm 等工具的迅速成熟，获得一个高可用、安全的 Kubernetes 集群变得越来越容易，但“即服务”是任何流行技术的自然发展。构建定制服务器已经让位于相同硬件的机架，拥有硬件已经让位于使用硬件，运行虚拟机管理程序已经让位于使用虚拟机管理程序，安装软件已经让位于使用软件。随着 GKE 的引入，Google 成为了第一个将 Kubernetes 集群作为工具而不是项目来提供的主要参与者。亚马逊的跟进证实了这种转变正在全面展开。

工具简化流程却不解决问题

客观地说，拥有一把可靠的、制造出来的、不会折断的锤子比为每颗钉子制造一把新的定制锤子要好。使用 Kubernetes 即服务消除了手动执行一些可重复的前端核心流程的需要。

在 Fairwinds ，我们的核心竞争力是管理云基础设施。 我们定义了标准的最佳实践和中间工具，并且开源了我们的工具 ，这些工具利用云服务来创建有凝聚力的、可靠的解决方案。出于同样的原因，我们依赖 Google Cloud SQL 或 Amazon RDS 作为关系数据库，CircleCI 用于持续集成和部署，PagerDuty 用于警报和响应组织，我们采用 Kubernetes 即服务实现，如 GKE，作为另一个优秀的工具来帮助我们可靠地解决 DevOps 问题。

然而，就像你不能单靠一把锤子盖房子一样，没有一个云工具可以独自解决你所有的业务问题。例如， 监控和理解问题，并在应用程序无法正常工作时做出反应，这些都是非常重要的任务，需要专业知识 。Kubernetes 可以帮助你监控你的应用，但它不会为你设置监控和警报，也不知道 Kubernetes 以外的其他基础设施。

像任何工具一样，正确使用 Kubernetes 也需要来之不易的专业知识，因为 Kubernetes 有其深奥的流程和元素。这就是为什么设置 Kubernetes 只是 DevOps 即服务团队工作的一小部分。你必须能够让你的应用程序进入 Kubernetes，自动扩展它，并在零宕机的情况下更新它。你必须能够按照预期的方式使用工具，这样你就不会敲螺丝或锯钉子了。

提醒一句

亚马逊即将发布的产品对整个社区来说是一件好事，我们在 Fairwinds 对拥有更好的 AWS 工具的可能性感到兴奋。不过，重要的是要记住，这种转变不一定是一帆风顺的。一段时间以来，亚马逊的 ECS 容器服务一直在尝试做 Kubernetes 所做的一些事情，并取得了成功。到目前为止，ECS 的使用给开发运维团队带来了巨大的挑战。除此之外，那些不熟悉 Kubernetes 的人并不总是知道要注意什么问题。

目前，AKS 没有 GKE 强大，亚马逊的产品很可能也没有。(我相信这并不奇怪，因为 Kubernetes 是谷歌的技术，他们最了解它。)在 Fairwinds ，我们不仅知道如何支持 GKE，还知道如何支持 AKS 和亚马逊。我们已经在亚马逊和谷歌上运行 Kubernetes 很长时间了。我们知道从 Kubernetes 服务产品中可以期待什么。这种专业知识使我们能够做出关键决策，以支持技术和使用技术的团队。更重要的是，我们的工具和专业知识能够并将会弥补亚马逊 Kubernetes 产品中没有内置的任何功能，同时还会优化所包含的功能。

开发即服务的持续演进

过去，fair windsdevo PS 使用各种不同的工具工作。随着 Kubernetes 的迅速成熟，我们认识到它的非凡能力。今天，我们所有的 DevOps 流程都利用了 Kubernetes 提供的功能。然而，事实是技术和工具在未来可能会改变。当它们出现时，您仍然需要将代码可靠地投入生产，并在生产过程中对其进行监控。这就是开发运维即服务合作伙伴的用武之地。

随着 GKE 和 AKS 的出现以及亚马逊的工具即将推出，开发运维即服务将扮演比以往更加重要的角色。虽然您可能不需要您的 DevOps 合作伙伴来支持 Kubernetes，但在当今快节奏的市场中，您可以通过与一个合作伙伴合作来获得实质性的好处，该合作伙伴可以将您的应用程序迁移到 Kubernetes，管理在 Kubernetes 中部署应用程序的复杂性，并监控持续集成和部署。

【Kubernetes 服务在自动化基础集群设置方面做得越好，我们在 Fairwinds 要解决的业务问题就越复杂。这意味着每个人都赢了。

成为谷歌云平台合作伙伴对我们的客户意味着什么

原文：https://www.fairwinds.com/blog/what-our-being-a-google-cloud-platform-partner-means-for-our-clients

成立一年多后，Fairwinds 专门为 AWS 提供 DevOps 咨询服务。然后在 2016 年 3 月，我们朝着 Kubernetes 的方向做了一个大的转变。那次转变后的几个月，我在工作之外遇到了一个人，我们聊了起来。当被问及他以什么为生时，他说:“我可以告诉你，但这可能对你来说毫无意义。”我告诉他，“嘿，我就是这么跟人说的！”

原来他是美国 Google Cloud Partnerships 的负责人，听说 我们在做 Kubernetes 的工作 他很激动。他告诉我谷歌 Kubernetes 的起源，然后谈到谷歌对 谷歌云平台(GCP) 的巨额投资，并问我们是否有兴趣成为合作伙伴。一开始我很犹豫。我们与 AWS 合作已经有一段时间了，他们似乎不知道我们的存在。我觉得合伙没有任何真正的价值。

我错了。事实证明，谷歌在 Kubernetes 上投入很大，并严重依赖他们的合作伙伴来帮助发展 GCP。我们成为他们在Kubernetes . io上的首批五个服务合作伙伴之一，从那时起，谷歌就要求我们在三个城市的谷歌办事处向他们的潜在客户和销售团队成员介绍 Kubernetes。

我们与谷歌的合作如何惠及我们的客户

谷歌合作伙伴关系为我们的客户带来了四大优势:

1. 我们的客户高度信任我们的工作。他们知道我们不仅仅称自己为专家。他们知道我们有经验做后盾。
2. 当客户考虑云迁移时，我们的密切关系使我们能够将 Google 带到谈判桌前。谷歌的代表努力工作，以确保他们为我们的客户竭尽所能。毫无疑问，谷歌已经准备好——并且渴望——提供帮助。
3. 谷歌的人愿意想办法分享他们即将推出的新功能的路线图。一个潜在的客户可能会问这样的问题，“我在 AWS 上运行 X，我不认为你在 GCP 上有那个，是真的吗？”一次又一次，谷歌与我们的客户密切合作，分享 NDA 保护的信息，这些信息对客户的决策过程至关重要。
4. 我们的合作伙伴关系使我们能够帮助较小的初创公司在 GCP 申请云信用，其中一些已经获得了大量信用。谷歌甚至愿意补贴 GCP 的成本，直到云迁移完成(生产工作负载在谷歌的云上运行)，甚至直接为 Fairwinds 在将客户迁移到 GCP 时提供的服务付费。

谷歌合作为我们的客户带来巨大回报

一年多前，我们成为了 GCP 的合伙人，我们一如既往地对成为谷歌的合伙人感到兴奋。如果你正在考虑在云中运行基于 Kubernetes 的基础设施，我们不能说太多关于谷歌容器引擎(GKE) 的好东西。

Betting big on the cloud is paying off for Google, and they’ve shown that they’re willing to work with our customers in just about any way they can to enable them to make the move to Google Cloud. Through this partnership, we’re ready to help you leverage Google’s investment in their cloud offering – and their investment in your success.

Kubernetes 解决什么问题？

原文：https://www.fairwinds.com/blog/what-problems-does-kubernetes-solve

本系列面向刚接触库伯内特和 GKE 的工程师。它提供了 Kubernetes 的基本概述、定义和在 GKE 构建 Kubernetes 集群的快速入门，以及构建您的第一个多层 webapp 的研讨会。如果您正在寻找更深入的 Kubernetes 最佳实践和帮助，请联系。

在我们开始构建您的第一个 GKE 集群之前，了解一些关于 Kubernetes 的事情很重要。

什么是 Kubernetes？

Kubernetes(K8s)是一个开源系统，用于自动化部署、扩展和管理容器化的应用程序。来源: Kubernetes.io

Kubernetes 是如何产生的？

2005 年，谷歌推出了博格系统。它开始是一个两三个人一起工作的小项目。这是一个大规模集群管理和资源调度系统，它引入了:

• 准入控制——允许在集群中调度什么工作
• 过度承诺的装箱——我们如何让多个系统和流程在单个节点上运行，而没有干扰
• 流程级资源隔离——如果在单个节点上调度一个容器，如何确保流程需求不会干扰另一个节点的流程需求

Kubernetes 把所有这些都变成了宣言。这意味着您可以获取需要调度的工作负载，在 YAML 文件中定义它们，将它们提交给 API，API 会告诉您它是否能够调度工作。

我们今天所知道的库伯内特人

2014 年，谷歌推出了 Kubernetes 作为 Borg 系统的开源版本。2015 年，谷歌与 Linux 基金会联合成立了云原生计算基金会 (CNCF)。同年举行了第一届 KubeCon 活动，CNCF 开始了 Kubernetes 的季度发布周期。

【Kubernetes 解决什么问题？

用户期望应用和服务全天候可用

当您使用像 Kubernetes 这样的容器 orchestrator 时，您可以跨多台机器在不同时间调度节点或流程。这允许您丢失一个节点或进程，而不会中断服务的正常运行时间。

开发人员希望在一天内多次部署代码而不停机

如果您是系统操作员，开发人员希望您给他们一天多次部署代码的机会。Kubernetes 允许您在不停机的情况下实现滚动更新的智能流程和方案。

企业渴望更高效地利用云资源

您可以在一个节点上调度多个进程，而不是在一个全天候付费的云节点上运行一个进程。您的云节点还可以识别何时无法调度新流程并因此需要新资源，或者何时资源空闲并需要关闭。Kubernetes 提供了切换这种弹性的简单方法。

容错和自愈基础设施提高可靠性

Kubernetes 提供可靠性。如果一个容器或整个节点出现故障，Kubernetes 将在一个健康的节点上重新调度资源或单个进程。

在节点和容器(pod)范围内自动水平缩放

Kubernetes 允许您创建新的节点，并自动将它们添加到集群中。如果单个服务受到资源限制，Kubernetes 会检测到这一点，并调用新的实例来处理额外的负载。

在 Kubernetes 测量和控制什么

原文：https://www.fairwinds.com/blog/what-to-measure-and-control-in-kubernetes

Kubernetes 成熟度模型 包括七个阶段，你将通过这七个阶段达到完全成熟。第六阶段，我们讨论 测控 。

刚接触 Kubernetes 的时候，你会经历一些基本的东西——准备、部署、改进。最终你会获得信心，现在会想要完善已经设置好的东西。这是走向成熟的一步，在这一步中，您确定需要围绕五个关键领域衡量什么:

1. 安全性 -您将测量您的容器或集群中存在多少和哪些漏洞，以及您修补工作负载、集群或附加组件的频率/时间。

2. 审计 -您将创建一个审计跟踪，以了解谁最近执行了哪些操作，以及工作负载在您的集群中执行了哪些操作。您将能够识别是否发生了未经授权的访问或操作。

3. 漂移 -您将能够识别哪些工作负载不符合您的标准，哪些版本的依赖项/集群附加组件正在运行，以及工作负载是否与 Kubernetes 的未来版本兼容。

4. 效率 -您将测量跟踪工作负载的典型或标准资源使用情况，以及集群中节点的典型容量/使用情况。您还将知道集群扩展的频率。

5. 速度 -你将测量提高你的发展速度。这将包括了解部署的发货频率、有多少用户访问您的集群以及在您的集群中最常见的操作。

一旦您开始收集这些关键领域的数据，您可能会注意到一些问题。工作负载可能杂乱无章，影响其他工作负载。可能有太多来自工作负载的访问导致安全问题。可能存在可靠性或可伸缩性问题(伸缩性不够或伸缩过于频繁)。由于使用了太多的资源或者工作负载没有清理干净，成本可能会攀升得太高。

为了克服这一点，你需要把控制放在适当的位置。这里你需要回答一些基于数据的基本问题来建立一套 Kubernetes 护栏。您需要回答有关安全性、配置和工作负载的问题:

安全

Kubernetes 的工作负载安全性至关重要。您将如何控制以下方面的群集权限:

• 谁有权访问集群？

• 用户可以在集群中采取什么行动？

• 工作负载可以在集群中采取哪些措施？

• 工作负载在集群中拥有什么级别的权限？

• 您的集群中工作负载之间的网络策略是什么？

配置

坚固的 Kubernetes 环境将有一致性的配置标准。您应该对以下方面进行控制:

• Kubernetes 资源的分布和定义？

• 发生了什么变化，何时发生？

• 你对资源的代码审查过程是怎样的？

• 什么类型的资源可以部署在您的集群中？

• 哪些名称空间可供哪些用户使用？

• 将工作负载部署到哪些名称空间？

• 如何设置工作负载或名称空间的可用资源量？

• 您的工作负载/部署的通用标准/默认值是什么？

工作流程

同样，您将为如何部署工作负载和服务、晋升途径和职责建立工作流:

• 谁可以向您的集群部署工作负载和服务？

• 如何将工作负载和服务部署到您的集群？

• 环境之间的晋升路径是怎样的？

• 谁负责您环境的哪些方面？

一旦回答了这些问题，您将有一组策略来开始在集群中实现配置更改。这就是 Kubernetes 策略执行变得重要的地方。仅仅写下政策并期望你的团队遵循是不够的。您需要一种跨集群实施策略的方法。

有许多开源工具，如 Polaris 、OPA、Goldilocks 和 Trivy，可以帮助检查 Kubernetes 最佳实践和定制策略的配置。这仍然需要您的团队在每个集群中应用每个工具。如果您要管理多个人员和集群，这会变得很麻烦。

使用像 Fairwinds Insights 这样的软件将经过审查的开源工具合并到一个单一的仪表板视图中。它使您能够测量集群配置，并根据这些数据建立和实施策略。您可以了解与安全性、可靠性和效率相关的严重或中等问题。

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

在 Kubernetes 成熟的这个阶段，您将需要选项来为您提供度量和控制。Fairwinds Insights 是一款能够帮助您测量和实施护栏的软件。它具有跨工程团队的影响。

何时使用 Kubernetes 托管服务与内部招聘

原文：https://www.fairwinds.com/blog/when-to-use-a-kubernetes-managed-service-vs.-hiring-internally

在 Fairwinds 担任领导的这些年里，我参与了聘用内部人才或使用托管服务的决策。在很多情况下，我们会雇佣外部人员。例如，工资公司、福利管理公司或营销公司——有些很好，有些则更痛苦。当我们的核心工作与我们需要做的事情紧密交织在一起时，我几乎总是选择让内部的人来做。

然而，在外部服务提供商中存在着局限性和巨大的差异。例如，有一家网站设计公司为我们建立了一个网站，让我们的在线观众惊叹不已。但是，对于我们的营销团队来说，作为一个不断增长和不断变化的平台，它的功能并不太好。这是美丽的，迷人的，但完全不灵活。后来，我们利用了另一家供应商，一家托管服务提供商，该提供商大力鼓励我们的交互高度自动化。体验是完全不同的。

经验法则

谈到推动您业务发展的技术，请遵循一些经验法则:

1. 对于你公司的核心竞争力，尽可能把它带到公司内部。
2. 对于任何已经解决的问题，利用现有的解决方案或专家，不要浪费时间重新发明轮子。
3. 当你有一天像苹果一样大的时候，把所有东西都带回家。在此之前，找到明智的地方来利用外部服务。
4. 托管服务总是比咨询服务有更好的激励机制(长期成功)(顺道拜访，做些漂亮的东西，然后离开)。

如何利用云基础设施

云基础设施的世界就像录音室，乐队利用混音专业化来创作音乐。也就是说，对于几乎每个乐队来说，他们的音乐都是独一无二的，是他们实际销售的东西。录音设备、录音室空间、混音和母带工具对于乐队录制音乐来说是绝对必要的。但是真正擅长设计工作室，或者混合/掌握他们的音乐会分散注意力。这些人知道什么让他们赚钱，他们擅长什么，他们想花时间成为世界上最好的音乐家。考虑到这一点，他们花了一生的时间一起练习，做出一些新的和独特的东西，然后像他们之前的许多乐队一样利用同一个工作室，并相信那些人会做他们最擅长的事情。

同样，云基础设施也不是让大多数公司赚钱的东西。他们需要强大的云基础设施，否则就赚不到钱。但是，成为建造世界上最迷人的云基础设施的高手会分散他们对产品和服务的注意力——那些真正为他们赚钱的东西。

举一个具体的例子，你可以雇佣一群世界上最好的数据库管理员，或者利用一个非常棒的托管数据库服务，比如 AWS RDS 或 Google CloudSQL。在某些情况下，您可能两者都需要，但是对于一般的公司来说，选择有支持的服务可以让您省去很多麻烦:

• 云公司的专家
• 凭借多年来除了运行数据库服务什么都不做的经验
• 凭着多年的经验，打破东西并把它们做好
• 根据大规模的经验，你可能永远不会有。

内部团队很难胜任备份、扩展、分片等工作....你可以在这方面做得很好，但是这可能会分散你的注意力，并且不能最好地利用资源。

---

在 Fairwinds，我们提供 托管 Kubernetes 服务 ，因为 Kubernetes 就是我们所做的一切。我们的产品是我们的软件和服务，让 Kubernetes 的成功成为他人的现实。把我们当成你的混音和母带制作专家。您已经同意从其中一个云中租用您的工作室空间，现在利用 Fairwinds 为您的应用程序获得最佳基础架构，为您节省时间、金钱和伤疤(哦，伤疤是我们辛苦挣来的...)，并确保您的 长期成功，因为我们会与您的团队 并肩作战。

Fairwinds 可以加快您对云的采用，您对云原生技术的采用，并使您的团队能够重新制作优秀的音乐(希望也能制作出令人惊叹的产品！).

你为什么不遵循这 5 个 Kubernetes 最佳实践？

原文：https://www.fairwinds.com/blog/why-arent-you-following-these-5-kubernetes-best-practices

随着容器成为开发和部署云原生应用程序的标准方法，许多组织正在采用 Kubernetes 作为他们用于容器编排的解决方案。最近的云本地计算基金会(CNCF)调查显示，96%的受访者正在使用或评估 Kubernetes，93%的受访者正在生产环境中使用 Linux 容器。换句话说，容器和 Kubernetes 正在变得流行，特别是在非洲等新兴技术中心，那里许多人正在寻求 Kubernetes 部署，其中 73%已投入生产。不仅新兴公司采用这些技术，大公司也是如此——通常比小公司更多。但是这是否意味着这些公司正在遵循 Kubernetes 最佳实践的基础呢？有时候…

很多时候，组织在没有完全理解成功部署 Kubernetes 所固有的复杂性的情况下就急于采用它。许多团队刚刚开始理解控制平面，调度器做什么，Kubernetes 中的节点如何工作，kubelet 做什么，daemonsets 是什么，Kube 如何改变软件开发生命周期。理解 Kubernetes 集群，使用 Kube instrumentation 跟踪哪些指标以及如何进行跟踪，以及进行故障排除以发现问题的根本原因，这些对于大多数组织来说仍然是一个挑战。

无论您是否仍在考虑何时以及如何实施 Kubernetes 来部署 SaaS 解决方案和其他应用程序和服务，或者您已经有了 K8s，通过采用监控系统和建立监控指标来应用 Kube 最佳实践来帮助您创建流程、明确任务和设置优先级都不会太晚。CNCF 指导许多开源项目，使其易于采用 Kube 和优化云原生架构。

Prometheus 是一个开源的系统监控解决方案，它以时间序列数据的形式收集和存储指标，并提供警报。监控工具和监控解决方案对于帮助开发运维团队解决分布式系统中的问题至关重要。所以，让我们后退一步，看看今天你需要关注的五大 Kubernetes 实践，以帮助你最大化 K8s 可以提供的长期价值。

1。Kubernetes 安全-最佳实践

安全性始终是技术的重要组成部分，Kubernetes 也不例外。人们的一个常见误解是认为 K8s 在默认情况下是安全的。这听起来很棒，但事实并非如此。Kubernetes 通过平衡速度和弹性来管理无状态微服务在集群中的运行方式，这可以使开发人员在部署软件时更加灵活。然而，如果您在 Kubernetes 部署中没有适当的治理和风险控制，这些好处就不会没有安全风险。

当您的 K8s 部署顺利运行时，您可能会认为一切都配置正确。不幸的是，过度许可是一种简单的方法，可以让你正在努力解决的事情发挥作用。授予 root 访问权限可以解决许多难题，但同时也会使您的组织面临拒绝服务(DoS)攻击或安全漏洞。事实上，错误配置是 Kubernetes 环境中最具挑战性的概念之一。即使是很小的错误配置，特别是以根级别访问运行的容器，也越来越成为网络攻击者寻找的漏洞。这些安全配置在 Kubernetes 中不是默认设置的，它们是您的安全团队必须建立的设置，然后通过自动化和策略来实施。

2。Kubernetes 成本优化-最佳实践

大多数组织采用 Docker 容器和容器编排解决方案，因为它们在基础设施利用方面天生高效。很简单，容器化环境允许您在每台主机上运行多个应用程序——每个应用程序都在自己的 Docker 容器中。这有助于您减少所需的计算实例总数，从而降低基础架构成本，而不会牺牲功能或应用程序性能。

Kubernetes 动态适应您的工作负载的资源利用率，并允许自动扩展(使用 水平 Pod 自动缩放器或 HPA )和集群扩展(使用集群自动缩放器)以提供可伸缩性。Kubernetes 允许您设置资源请求和工作负载限制，以便您可以最大限度地提高基础设施利用率，同时确保您的应用程序性能平稳。听起来很棒，对吧？只有在正确设置 Kubernetes 资源限制和请求的情况下。如果您的内存限制太低，K8s 会因为违反限制而终止您的应用程序，但是如果您将限制设置得太高，您会过度分配资源——换句话说，您会付出比您需要的更多的代价。弄清楚 正确的资源限制和要求 是具有挑战性的，对于 Kubernetes 的新采用者和已经使用 Kube 多年的组织都是如此。

3。Kubernetes 可靠性-最佳实践

可靠性永远是目标，但实现 Kubernetes 可靠性 是一项复杂的任务。优化 Kubernetes 需要技巧，特别是如果您使用的技术早于云原生应用程序和配置管理工具，它们并不总是提供最可靠的云原生体验。许多组织继续使用旧的解决方案，并在此基础上构建 Kubernetes，但这使得优化、可靠性和可伸缩性更难实现，尤其是当您的业务扩展时。确保集群可靠性的一个很好的方法是转而使用 基础设施作为代码 (IaC)，这有助于减少人为错误，提高一致性和可重复性，提高可审计性，并使灾难恢复更容易。它还可以帮助您解决 Kubernetes 工作负载中的性能问题。

4。Kubernetes 政策执行-最佳实践

采用 Kubernetes 的一个常见方法是用一个应用程序进行试验，这是一个很好的开始方式。但是，一旦您的组织承诺在多个应用程序、开发团队和操作团队中使用 Kube，那么为部署不一致的工作负载管理集群配置就变得非常困难。当您的团队没有关于如何部署应用程序和服务的护栏时，您会很快发现您的容器和集群之间的配置存在差异。这些差异很难识别、纠正和保持一致。手动识别这些错误配置非常困难。

要管理多集群环境，您需要建立 Kubernetes 策略 来实施一致的安全性、效率和可靠性配置。虽然策略可以实现全面的最佳实践，但有些策略可能特定于您的组织或环境。最佳实践文档似乎是管理这些策略的好方法，但是它可能很快就半途而废了。采用 Kubernetes 策略实施工具 可以帮助您防止常见的错误配置被发布，实现 IT 合规性，并使您的团队能够充满信心地交付——因为他们知道有护栏来实施您的策略。

5。Kubernetes 监控&警报-最佳实践

Kubernetes 监控配置通常是事后才想到的——许多组织直到出现问题时才考虑设置它们。但是优化 Kubernetes 监控和警报可以帮助您确保您的基础设施和应用程序正常运行，这需要您使用正确的工具来优化您的监控功能。可观察性与监控密切相关，因为实时观察系统的能力有助于您关联数据以报告系统的健康状况，监控关键指标，调试生产环境，并提前预防停机。Kubernetes 监控工具，特别是那些提供 Kubernetes 仪表板的工具，可以跟踪 Kubernetes pods、Kubernetes 节点和 Kubernetes 服务，是全面监控策略的一部分。在 Kubernetes 平台中需要跟踪的几个关键 Kubernetes 指标包括:

• 内存使用量

• 名称空间

• 资源指标

• 资源使用量

• 资源利用率

• 内存分配

• CPU 使用率

像Grafana这样的工具可以帮助您可视化应用指标和应用性能。使用开源工具可以帮助您避免局限于单一云提供商，如 AWS、Azure、Google Cloud Platform 等。集成可以帮助最终用户提高 kube 使用率，减少延迟，从而优化可扩展性，最大限度地减少重启，并改善用户体验。监控 Kubernetes API 服务器使团队能够了解集群组件之间的通信。

对于大多数团队来说，这意味着您需要考虑需要监控什么以及为什么要监控——确定 Kubernetes 监控最佳实践对您的组织来说是什么样的。了解哪些配置存在风险或浪费资源，尽早发现安全性和合规性风险，并在部署前发现错误配置，可以帮助您尽早解决问题并防止许多可能的问题。

你今天应该做的 5 个 Kubernetes 最佳实践

安全性、成本优化、可靠性、策略执行以及 Kubernetes 监控和警报都很复杂。虽然 Kubernetes 提供了许多组织越来越多地采用和利用的功能，但它们也要求您的部署在部署级别和集群级别都能很好地工作。对于许多采用 Kube 的团队来说，甚至对于那些已经有了 Kube 的团队来说，在实现这些 Kubernetes 最佳实践时，都很难知道从哪里开始。

Kubernetes 可以让您的组织提高容器的效用和生产率，并构建可以在任何地方运行的云原生应用程序。为了最大化您的 Kubernetes 实现，确保您遵循这五个 Kubernetes 最佳实践是至关重要的。有了正确的技术和 Kubernetes guardrails，您将能够实现构建可扩展、高效的云原生应用的承诺，这些应用可以在任何地方可靠、安全地运行，而不受特定于云的要求的影响。

深入了解 Kubernetes 最佳实践的细节——立即阅读这份白皮书。

为什么自动化基础架构至关重要，以及它如何节省时间

原文：https://www.fairwinds.com/blog/why-automated-infrastructure-is-key-and-how-it-saves-time

你需要有经验的人来支持你的基础设施和解决复杂的问题。也就是说，雇佣内部专家只是简单地按下相同的按钮来进行日常升级和按需扩展您的基础架构是没有意义的。如果有一天那些内部专家决定离开，会发生什么？

这就是自动化基础设施至关重要的原因。这是为了节省时间，同时减少依赖性。让我们更详细地研究三个方面:配置管理、部署自动化和自动扩展。

配置管理

配置管理曾经侧重于应用程序，但今天您的基础架构需要处于配置管理之下，以便您可以内置容错功能。以 AWS 为例，如果您的基础架构处于配置管理之下，并且您可以以标准、自动化的方式运行它，那么您只需决定在另一个地区(比如美国西部)重建您的基础架构，您的基础架构就会自动重建。

如果您的基础设施发生变化，您的应用程序可能会崩溃，反之亦然。在过去，系统操作员会对服务器进行更改，然后开发人员可能会部署不起作用的代码。当基础设施不在配置管理之下时，代码并不总是随着基础设施的改变而被测试。

同样的原则也适用于 DevOps，这里的一切每天都在变化。没有什么是一成不变的，所以最好留在前线。如果没有自动化，您需要手动升级，这可能每天需要 30-40 分钟，并且会极大地消耗您的资源。

部署自动化

如果您的集群处于配置管理下，并且您使用类似于kops(kubernetes-ops，用于从命令行部署 Kubernetes 集群的一站式开源解决方案)的工具，那么升级是自动的，可以节省大量时间，并减少人为错误。

这给我们带来了一个关于部署自动化的更大的讨论。

您的应用程序和基础架构必须融合，这就是 DevOps 的用武之地。自动化您的应用程序部署增强了您的基础设施。如果应用程序代码被容器化，并且每次都以相同的方式部署到您选择的环境中，那么您就不必担心哪里出了问题。自动化为您提供了一条清晰的道路，如果您遵循这条道路，您将快速识别问题并追踪问题的根源。

自动化部署还节省了新开发人员的入职时间。开发人员过去常常编写应用程序，测试它们，将它们加载到服务器上，配置它们，运行它们，然后在它们被破坏时修复它们。这是一个耗时的过程。现在开发人员可以处理代码，剩下的就交给自动化了。

自动缩放

自动伸缩有助于确保拥有正确数量的实例来处理应用程序的负载。您可以在自动缩放组中指定最小和最大实例数(或特定的实例数)，自动缩放会自动确保您的组符合这些标准。

假设您将所有应用程序容器放在一个集群中，完全填满了集群。如果添加新资源的过程不是自动化的，操作员必须启动群集中的另一个节点，然后您才能开始使用这些资源。这个手动过程需要时间。如果这个过程是自动化的，您可以用一堆容器填充您的集群，当它们不再适合时，集群知道需要更多的资源，并将自动启动新的节点。

Kubernetes 可以在容器级别自动扩展您的基础设施。假设您在一个群集中有 10 个节点，您通常只需要运行应用程序的 10 个副本。你的广告刚刚在《早安美国》播出，突然之间，你的网站访问量一飞冲天。您的应用程序的这 10 个容器已经不够用了，但是在您的 10 节点集群上仍然有足够的空间(资源)可用。Kubernetes 可以在 15-30 秒内扩展一个容器，而不是扩展一个可能需要 5-7 分钟的新实例。您可以根据需要扩展您的基础架构，它所做的只是在集群中放置更多的容器。只要你有足够的空间，它替你处理你的成长需求。

容错

如前所述，容错也很重要。如果操作人员没有注意到某些东西，会发生什么情况？如果你不知道有一个交通高峰即将到来，你当然不能超越它。像 Kubernetes 这样的自动化容器集群会为您注意到行为的变化。

假设您在某个应用程序容器上收到大量请求，它开始耗尽内存并死亡。如果这种情况发生在常规的服务器实例上，您的应用程序也会死亡。如果您有自动化的集群，那么您也有自动化的容错能力。如果您的容器不堪重负，耗尽了内存并死亡，集群会注意到(它知道观察这种情况)，它会自动旋转一个新的副本。

Kubernetes 可以在实例级别做同样的事情。假设您有一个很大的硬件资源池，AWS 终止了一个实例。如果没有自动化，如果服务器停止运行，而有一堆容器在上面运行，那么必须有人首先注意到，然后想出该做什么(启动一个新的集群节点并重新调度容器)。通过自动化，Kubernetes 将识别问题，抢先启动新的集群并转移资源。Kubernetes 还将等待集群是否恢复，如果恢复，它将取消节点扩展，以免浪费资源。这种自我修复意味着许多问题都可以高效、经济地解决，无需人工干预。

此外，Kubernetes 有一个称为 的 Kubernetes 集群联盟，它使用户能够将不同地区的多个集群组合成一个逻辑计算联盟。这种联合简化了高可用性、地理上分布的服务的部署。如果整个地区都瘫痪了，那么你所有的流量都会转移到其他地区。

接下来是第 3 部分—受监控的基础设施并不好玩…但它很重要！

为什么选择 Kubernetes？

原文：https://www.fairwinds.com/blog/why-choose-kubernetes

如果您正在第一次将工作负载迁移到云，您可能会遇到容器化和微服务的话题。松散耦合的微服务中的容器化应用程序在很大程度上已经成为将工作负载部署到云的标准，并为处理与您的服务相关的操作提供了主要优势，因为它们允许您独立管理每个组件。您可以将软件架构的各个部分作为模块化部件进行部署、更新、扩展和移除。

这种将应用程序作为容器中的独立组件来管理的方法非常普遍。然而，实际协调它们并将其转化为完整的基础设施的任务可能会令人望而生畏。一些云提供商，比如 Amazon Web Services 和 Azure，提供了部署容器的托管解决方案(比如 ECS、Fargate 和容器实例)。这些类型的托管容器编排工具在复杂性和所需知识方面有所不同，但是它们都从为您做繁重工作的相同角度出发。

你可能听说过库伯内特斯

您可能听说过 Kubernetes——容器编排领域的庞然大物，它在很大程度上已经成为标准工具。与特定于供应商的托管工具(如 Fargate、ECS 或 Container Instances)不同，Kubernetes 是开源的，可以在您选择的任何云上运行。作为一个决定使用容器编排工具的新手，您可以将托管的特定于供应商的服务(ECS、Fargate、容器实例等等)想象成 Microsoft Windows 或 MacOS，而将 Kubernetes 想象成 GNU/Linux。特定于供应商的托管服务有时可以提供一些额外的改进和更少的开销，但这是以供应商锁定和所有必要的成本为代价的，包括无法轻松地切换供应商，无法根据您的特定需求调整平台，以及无法对项目本身做出贡献。

Kubernetes 提供了灵活性

总之，Kubernetes 提供了灵活性。你可以改变运行 Kubernetes 的底层平台。您可以更换在集群上运行的集群服务。您可以使用您喜欢的任何种类的插件，甚至可以向您的集群添加自定义资源。如果你愿意，你甚至可以为 Kubernetes 项目做出贡献，并在你认为合适的时候帮助改进它。Kubernetes 的这种全面的灵活性在许多方面反映了 GNU/Linux 的灵活性，这也是 Kubernetes 成为标准容器编排工具的原因，就像 GNU/Linux 成为许多数据中心的标准操作系统一样。

随着时间的推移，Kubernetes 的灵活性和开放性将继续巩固其竞争优势，因为越来越多的公司和项目将其作为事实上的选择。选择 Kubernetes 作为您的容器编排工具，您将获得这一活跃生态系统的所有好处，并能够根据需求的变化灵活地调整您的云基础架构。

当然，使用一个提供如此大灵活性的系统会带来特殊的挑战。在 Fairwinds，我们在这里帮助您完成迁移到 Kubernetes 的每一步。

为什么修复 Kubernetes 配置不一致对于多租户和多集群环境至关重要

原文：https://www.fairwinds.com/blog/why-fixing-kubernetes-configuration-inconsistencies-is-critical-for-multi-tenant-and-multi-cluster-environments

在大多数情况下，组织用一个应用程序来试验 Kubernetes。一旦成功，这些组织将致力于跨多个应用、开发和运营团队的 Kubernetes。通常是自助服务模式，开发运维人员和基础架构负责人会让许多用户跨许多不同的集群进行构建和部署。

虽然自助服务模式消除了应用程序团队和基础架构之间的障碍，但由于工作负载可能配置不一致或需要手动部署，因此管理群集配置变得非常困难。如果没有护栏，集装箱和集群之间的配置可能会有差异，这对于识别、纠正和保持一致性是一个挑战。当用户从在线示例(如 StackOverflow 或其他开发团队)中复制并粘贴 YAML 配置时，工作负载被过度配置以“让事情正常工作”，或者如果没有现有的流程来验证配置，就会发生这种错误配置。

63%的部署允许其工作负载作为 根用户
来源:Fairwinds Insights 对数百个生产级集群的调查结果

配置不一致的负面后果非常重要，不容忽视:

• 安全漏洞:错误配置会导致权限提升、易受攻击的映像、来自不可信存储库或容器的映像以 root 用户身份运行。69%的公司由于 Kubernetes 的错误配置发生过安全事故。来源:企业项目。

• 效率:由于使用了太多的资源或者陈旧的工作负载没有得到清理，成本可能会攀升得太高。45%的容器使用<30% of requested Memory (inefficiency). Source: DataDog 容器报告。

• 可靠性:可能存在围绕活动或就绪性调查的可靠性问题，或者可扩展性问题(由于缺乏 PodDisruptionBudgets 或 HorizontalPodAutoscalers，扩展不够或扩展过于频繁)导致您的应用程序或服务停机。

29%的部署缺乏就绪性调查
来源:Fairwinds Insights 对数百个生产级集群的调查结果

手动识别这些错误配置非常容易出错，并且会很快让运营团队不堪代码审查的重负。

技术影响

• 未解决的容器漏洞

• 过度许可的部署

• 缺少健康探测器

• 不适当的资源请求和限制

业务影响

• 安全风险增加

• 应用停机时间

• 云成本超支

• 不合规

为什么实施一致的配置模式对 Kubernetes 至关重要

随着团队在整个组织中部署 Kubernetes，DevOps 团队不可能手动编写或审查进入集群的每个 docker 文件和 Kubernetes 清单。这就是实施配置模式对 Kubernetes 的成功至关重要的地方。如果没有一套一致的标准，工程团队将不可避免地产生安全漏洞，过度消耗计算资源，并引入嘈杂的工作负载。然后，DevOps 团队很快耗尽精力来响应页面和灭火，几乎没有时间对基础架构进行实质性改进。升级也可能成为一个主要问题。组织在可避免的错误配置和意外中断上浪费金钱。

如何加强与 Kubernetes 政策的一致性

当与一个工程师团队管理多集群环境时，创建一致性需要您建立 Kubernetes 策略来加强安全性、效率和可靠性。那么，如何加强一致性呢？实现一致配置的一个关键工具是 Kubernetes 策略。策略和策略实施工具允许您定义部署的操作防护，以及特定的法规遵从性和安全性要求。这些策略通常被称为策略即代码，使平台工程和运营团队能够围绕一组通用的规则、模式和最佳实践与其他利益相关方协作，以供 IT 和工程团队遵循。

我们撰写了一篇论文，概述了在 Kubernetes 中执行政策所面临的挑战以及不执行政策的负面后果。它详细介绍了哪些策略是必不可少的以及如何创建它们，并提供了如何实施策略的信息。

本白皮书非常适合管理多用户、集群和租赁环境的工程和 DevOps 领导者。

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

为什么基础设施是代码和 Kubernetes

原文：https://www.fairwinds.com/blog/why-infrastructure-as-code-kubernetes

基础设施即代码是使用配置语言供应和管理基础设施的能力。基础设施即代码(IAC)将现代软件开发的可重复性、透明性和测试引入到网络、负载平衡器、虚拟机、Kubernetes 集群和监控等基础设施的管理中。IAC 的主要目标是减少误差和配置漂移，同时允许工程师将时间花在更高价值的任务上。IAC 定义了您的基础设施的最终状态，而不是定义一系列要执行的步骤——像 Terraform 这样的 IAC 工具可以针对您的基础设施运行多次，产生相同的预期结果。

使用云用户界面创建托管 Kubernetes 集群是一个相对简单的过程，但是使用基础设施作为代码有助于标准化集群配置和管理附加组件，如网络策略、维护窗口以及集群节点和工作负载的身份和访问管理(IAM)。

【Kubernetes 代码基础设施的优势

通过使用 Kubernetes 将基础设施作为代码，您将在四个方面受益:

1。减少人为错误，增加机构知识

用可复制、版本化、可跟踪的表示法取代点击式基础架构配置流程，该表示法还记录了基础架构的重要细微差别。更多的机构知识可以留在您的公司，即使员工没有，IaC 可以帮助新员工更快地了解您的基础架构。

IaC 和自动化减少了人为错误，创造了可预测的结果。您可以创建新环境来测试更改，而不会影响您的生产环境。当使用代码跨多个环境更新基础设施时，与执行重复的手动任务相比，对细节的关注较少。

在培训新工程师时，基础设施代码和注释可以提供关于设计考虑事项的见解，并减少向主题专家咨询背景知识的需要。

2。重复性和一致性

IaC 的可重复性对于利用云的弹性是一个相当大的贡献。它可以帮助您创建一致的基础架构，以便更快地测试或扩展到其他地区，从而腾出时间来应对下一系列挑战，例如在多个地区之间路由应用流量。使用代码表示基础设施可以最大限度地减少某些环境中独特的“雪花”配置，以及通常由手动配置中的无意差异或未清理的故障排除导致的配置漂移。

3。改进的变更跟踪和可审计性

IaC 还有助于审计和跟踪基础设施的变化。当基础设施在版本化的存储库中表示时，比如 Git，对 Git 存储库的提交可以反映谁、何时以及为什么进行了更改。您的代码记录了环境是如何构建和发展的。其他团队成员可以审查代码的变更，增加对基础设施变更的共识和认识。在问你的首席工程师“你还记得为什么我们改变了我们的 whosit 来通过欧洲发送 whats 吗？”

4。灾难恢复

一场灾难会造成恐慌，降低精神敏锐度，并给单一的知识和经验带来压力。灾难恢复(DR)不是任何人都想回忆过去几年中配置的重要细微差别，或者盯着用户界面进行比较以手动创建新基础架构的时候。应用程序的可靠性受到转换能力和重新部署速度的影响。作为代码的基础设施可以帮助您了解恢复过程是什么样的，并更经常地实践该过程。

fair winds 的基础设施代码和 Kubernetes

在 Fairwinds，我们 100%关注 Kubernetes，并使用基础设施作为代码，以确保我们管理的 Kubernetes 客户实现上述所有好处。我们将 IaC 用于必备的云资源，如网络、Kubernetes 集群、监控和警报，以及运行在 Kubernetes 之上的工具，以管理 DNS 记录、HTTP 路由和 SSL 证书。

为什么基础设施代码扫描对 Kubernetes 配置很重要

原文：https://www.fairwinds.com/blog/why-infrastructure-as-code-scanning-matters-for-kubernetes-configuration

基础设施即代码(IaC)是使用配置语言供应和管理基础设施的能力。它为网络、负载平衡器、虚拟机、Kubernetes 集群和监控等基础设施的管理提供了现代软件开发的可重复性、透明性和测试。其主要目标是减少错误和配置偏差，同时允许工程师将时间花在更高价值的任务上。IaC 是 Kubernetes 用户 的一大 福利。

但是随着每一项技术的发展，它也会带来一些问题。Kubernetes 基础设施作为代码扫描是帮助进一步减少错误或 K8s 错误配置的下一步。这在安全和成本领域尤为重要-防范风险，避免浪费开支。

作为代码扫描的基础设施是根据一组策略和 Kubernetes 最佳实践扫描 IaC 文件的能力。虽然有些人可能只使用 IaC 来寻找漏洞，但它是一个更强大的工具。它有助于确保围绕应用程序安全性、可靠性和成本进行适当的 Kubernetes 配置。

谁需要 IaC 扫描？

在拥有一个或两个 Kubernetes 集群的小型团队中，基础设施即代码(IaC)扫描可能是手动完成的，但是随着组织随着众多开发团队部署到多个集群而扩展，这个问题变得越来越具有挑战性。开发运维团队以及平台和安全负责人可能会很快失去对正在发生的事情的了解和控制。这一现实表明，对于在多租户集群中部署应用的下游开发团队来说，需要自动化和策略来加强一致性和防护。

作为代码安全扫描的基础设施

人为错误是安全漏洞最常被提及的原因。当开发人员友好的(不安全的)默认配置与人工监督相结合时，容器的安全性就悬而未决。此外，配置管理对 Kubernetes 用户来说是一个独特的挑战，因为它需要更多的考虑。虽然有许多工具可用于容器映像的漏洞扫描，但从一开始就确保正确的配置也同样重要。

IaC 扫描可以检查 Kubernetes 的安全策略，以在安全漏洞全面爆发之前主动识别它们。策略可以包括检查安全上下文(权限提升、root 访问等)、主机设置或危险功能。

IaC 扫描成本分配和资源优化问题

Kubernetes 工作负载的错误配置通常涉及低效的计算资源配置，从而导致过高的账单。如前所述，为了最大化工作负载的 CPU 效率和内存利用率，团队需要适当地设置资源限制和请求。但是这里有一个问题——知道为流畅的应用程序性能设置正确的限制是非常棘手的。

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

较大的组织可能会采用 FinOps 计划，这需要容器成本的精细分配。为了便于报告，IaC 扫描可用于强制执行有关所需标签的策略，确保团队在部署工作负载之前正确标记和识别工作负载。

作为代码可靠性扫描的基础设施

IaC 扫描可靠性策略有助于避免应用程序停机和生产事故。在 Kubernetes 中，可靠性就是构建一个稳定的平台，这样开发团队就可以简化他们的开发过程，更快地发布应用程序。

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

IaC 扫描解决方案

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

有兴趣使用公平风洞察？它是免费的！在这里了解更多。

为什么要执行 Kubernetes 政策

原文：https://www.fairwinds.com/blog/why-kubernetes-policy-enforcement

一旦你克服了部署 Kubernetes、迁移和/或启动你的应用程序的障碍，现在你必须管理 Kubernetes。这本身就是一个不小的问题。随着集群、大量用户甚至组织内多个部门的蔓延，您如何确保遵循您的策略？

我们都知道，要符合任何行业法规和组织指导原则，我们不能简单地写下政策，并将其留给个人。例如，政策执行已经成为安全和网络访问的规范。这也必须成为 Kubernetes 的标准。

谁负责 Kubernetes 的政策执行？

不幸的是，在管理 Kubernetes 的开发团队和运营团队之间存在差距。运营团队需要制定策略来维护标准和合规性。开发团队必须有开发新特性和功能并进行更新的自由。这两个领域经常互相矛盾。Kubernetes 的政策执行可以弥合这一差距。软件可以帮助运营团队建立 Kubernetes 政策，制定规则，然后自动执行这些政策。如果应用于整个 CI/CD 管道和生产中，开发人员可以避免生产中的问题，并在生命周期的每个阶段拥有自己的服务。运营团队可以了解实际发生的情况，并根据他们的开发团队调整策略。

什么是 Kubernetes 政策执行？

Kubernetes 策略执行是自动化、监控和执行安全和计算资源方面的防护和最佳实践的能力。更具体地说，它允许您了解多个集群，并检查新的和现有的集群是否符合策略，以便您的团队不会引入安全漏洞或在过度调配的资源上浪费资金。需要实施策略来确保集群的一致性。

何时实施 Kubernetes 策略？

对于 Kubernetes 来说，停留在“只是让它运行起来”是完全正常的。但是经常停留在那里并没有考虑保持安全所需的设置。作为采用 Kubernetes 的准备工作的一部分，考虑应用策略。随着您和您的团队经历 Kubernetes 成熟度 ，您将希望在 CI/CD 渠道中包括策略执行。这样做意味着你不会在生产中引入问题。

为什么要执行 Kubernetes 政策？

Kubernetes 的政策执行是确保 Kubernetes 做得正确的保证。没有它，就有许多问题。

1. 缺乏可见性和跨多个集群和开发团队的最佳实践的一致实施导致生产扩展的延迟。如果没有这种可见性，运营团队就无法查明导致安全和合规性事件、停机以及在计算资源上花费过多的错误。

2. Kubernetes 在默认情况下是不安全的，需要团队监控和修补基础设施和应用程序中的安全漏洞。应用程序和 Kubernetes 基础设施中未经管理的安全漏洞会导致攻击者访问敏感数据和资源。如果没有监控 Kubernetes 安全性的流程，组织可能会无意中将自己暴露在违反法规的风险之下，这可能会损害客户信任、品牌，并招致经济处罚。

3. Kubernetes 的一个主要优点是可伸缩性，但是，开发人员经常忽略正确设置资源需求。这可能会带来可靠性问题，消耗数据中心的容量，并经常浪费大量资金。

4. 如果组织忽视为 Kubernetes 配置建立内部标准，或者发现自己频繁地更新这些指南，就会出现配置漂移，导致不必要的技术债务和复杂性。这增加了升级和修补的成本，使组织暴露于安全漏洞的时间更长，并影响上市时间。

5. 开发人员熟悉检查代码的软件，但是当前的工具缺乏针对 Kubernetes 的上下文推荐。开发人员经常忽略遵循最佳实践，因为替代方法是通过反复试验来浪费时间(例如，设置 CPU 和内存请求和限制)。如果没有可操作的建议，开发人员会默认传播配置错误，从而导致过度配置和安全过度许可。策略实施有助于监控使用情况，以便应用最佳实践。

如何执行 Kubernetes 的政策？

Fairwinds Insights 是一款配置验证软件，可以自动化、监控和执行 Kubernetes 最佳实践 。它为多个 Kubernetes 工具提供了开箱即用的预构建集成，可在单个平台中解决安全性、工作负载效率和可靠性方面的配置错误。集中式多集群控制面板聚合并增强了调查结果，从而实现了无缝的优先排序和补救。

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

fair winds Insights在开发生命周期的每一点——CI/CD 期间、准入时和生产中——为容器和 Kubernetes 配置提供持续的安全审计。它添加了历史使用数据和成本影响估计，以提供精确的 pod 级 CPU 和内存建议。借助 Insights，您可以获得预构建的策略和直观的用户界面，从而在您的组织中跨多个集群应用护栏时节省时间并降低复杂性。

Fairwinds Insights 可以免费试用。您也可以查看我们的 入门概述 ，它提供了更多关于您将从行动项目中看到的内容的信息。

为什么受管理的 Kubernetes 能够帮助团队取得成功

原文：https://www.fairwinds.com/blog/why-managed-kubernetes-enables-team-success

当过渡到 Kubernetes 时，您自然需要内部专家。从长远来看，这可能是真的。但是 Kubernetes 是管理基础设施的新范例，拥有专业知识是件好事。

航海托管服务

打个比方，假设你经营一家旅游公司，让人们去划皮划艇、玩滑板和漂流。沿途的某个地方，你决定你也想提供游艇航行。你有几个选择来实现这个转变。你可以出去买一艘小帆船，学习航海的基础知识，然后升级到一艘越来越大的船，在你通过反复试验学习如何航行的同时，教沿途的人。最终你会在一艘非常大的船上感到舒适，你会有驾驶这艘船的员工和专业知识。但是要达到你的商业目标需要很长时间。

另一个选择是出去买一艘游艇，并雇佣一群有驾驶经验的人。现在，您可以立即开始将客户送上游艇旅行，并相信即使在长途旅行和暴风雨中，您的客人也会得到安全保障。随着时间的推移，你会让你的人和你雇佣的船员一起工作，这样他们就能掌握诀窍，直到你对自己的人驾驶这艘船充满信心。

托管 Kubernetes 服务

现在把这个比作 Kubernetes。你可以出去买一个树莓派(或者一套)然后旋转 Kubernetes 集群。在这个过程中，你会学到基础知识。但是在一组小型计算机上运行 Kubernetes 与在背后有关键任务基础设施的生产环境中运行它是非常不同的。要实现这一点，您需要开始在云环境中(在本地或通过云提供商)做一些事情，尝试一些小的服务，直到您对迁移生产环境感到满意为止。

最终你会取得越来越大的进步，并且对航行感到非常舒适。但是，当你没有经历过的事情出现时，会发生什么呢？一根绳子断了，或者你需要不停地修补船帆？在海上修补船体呢？更可怕的是，如果有一天出现了你不熟悉的风暴。在一场大风暴中保持一切正常运转成为了当务之急，而你身边却没有专家来帮助你。谷歌“我如何驾驶帆船在巨浪中航行？”远不如在甲板上有一个知道如何驾驶飞船的人来的安心。

专业知识不是获取信息的途径，而是经验。让有经验的人在身边，让专业知识唾手可得，这是很有价值的，直到你自己成为一名航海大师。有一个人在身边帮助你学习，你会更快成为一名优秀的水手。

支持和知识传授

我们在 Fairwinds 传达的信息是，我们是一家 Kubernetes 支持公司。我们有几种方法来实现这一点。

一是您可以为我们的托管服务 ClusterOps 付费。我们可以为你造一艘船，让它今天就为你启航——让它一直漂浮着，直到你准备好慢慢接管它。

已经在海上了？我们有一个名为 Kubernetes Advisory 的支持服务，可以在您掌舵时回答您的问题。

最后，有些人有他们不能与其他人分享的船，这就是为什么我们有软件- Fairwinds Insights -帮助你一路成功-想象一个平台，告诉你在哪里以及如何移动和系紧帆，或者准确地揭示你的船需要什么维护才能保持航行？

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

知识转移是我们流程的正常部分。在那里看着我们的人带你穿过一个又一个风暴会导致缓慢的知识转移，即使你并不追求它。

有很多方法可以开始这个过程，而且有很多很好的理由现在就登上游艇。在学习一个全新范式的过程中，在别人的帮助下尽早实现目标会让事情变得更加顺利。

你可能会说这就像顺风顺水。

为什么我的 IP 不是我的密码

原文：https://www.fairwinds.com/blog/why-my-ip-is-not-my-password

我的 IP 不是我的密码

在过去的几年里，我看到了数量惊人的请求来实现一个系统，在这个系统中，我们允许基于用户的 IP 地址进行访问。根据我的经验，这产生了一种虚假的安全感，并导致了大量的痛苦，尤其是在云环境中。但在我继续之前，先简要回顾一下互联网和安全的历史。

互联网简史

• 1983 年 — Vint 和 Bob 创建了 TCP/IP V4 并在 ARPANET 中实现
• 1985 年，人们开始囤积 IPv4 CIDR 块
• 1999 —云计算成为现实
• 2002 年——静态 IP 受到限制，并开始频繁变化

安全简史

• 1988 — 人们意识到静态 IPv4 地址是一个东西
• 1990 — 公司使用白名单根据这些 IPv4 地址允许流量
• 1991 — 公司认为这是一个好主意

我可能漏掉了一些东西。你明白了。IP 白名单成为多年来每个网络管理员部署的第一个安全实现。更频繁地(也更可怕地)，他们就停在那里。

这有什么不好？

让我们来谈谈将 IPs 作为您唯一的安全措施的含义。第一，IP 恶搞是个东西。当然这不允许双向攻击，但是它可以用于 DOS 攻击。其次，BGP 劫持可以用来攻击这些类型的防御。

这些都是相当复杂的攻击，需要一个认真的攻击者，但是它们很好地解释了为什么这不应该是您唯一的安全机制。

IP 过滤的一个更大的问题是，云计算的现代使用使得这种类型的安全措施完全站不住脚。默认情况下，大多数云实例不使用静态 IP 地址。云提供商只有有限的 IP 空间，他们不会把它分给每个人。更常见的情况是，每次创建资源时，它都会获得一个随机的新 IP，或者更好的情况是，它会获得一个内部地址，并隐藏在某种形式的网关后面。云提供商有充分的理由敦促人们使用消耗更少 IP 地址的模式。

这意味着我们需要停止依赖静态 IP 地址作为安全机制。

不是聊胜于无吗？

在技术领域，我们经常说“有总比没有好”来谈论安全性你真的无法反驳这种说法，因为它是多么模糊和明显。我想鼓励每一个从事技术工作的人停止说这种话，而是开始问“我们如何实现足够好的安全性？”这个问题鼓励我们重新考虑我们的整个战略，并决定它是否足以保护我们企业的价值。策略可能包括大规模的 IP 黑名单，以避免来自已知危险角色的流量，或者可能包括任何数量的其他措施，这些措施本身是不充分的，但放在一起可以提供良好的安全性。让我们摆脱“聊胜于无”的失败主义态度，专注于“足够好”的安全性。

请注意，文章中的日期几乎完全是虚构的，不应视为事实

AWS 文档特别声明 IPv4 地址很少。https://docs . AWS . Amazon . com/AWS ec2/latest/user guide/elastic-IP-addresses-EIP . html # using-instance-addressing-limit

为什么您应该将您的平台视为一个记录良好的 API

原文：https://www.fairwinds.com/blog/why-your-paas-is-really-a-well

这是技术组织领导之间的一个常见话题...

SRE 应该成为一门独立的学科吗？

我应该雇佣 DevOps 的人吗？

我团队的其他成员应该管理所有的基础设施吗？

这是有道理的。DevOps 是一个流行了很多年的词。所以，组织纠结于他们做的是否正确的观念是有意义的。

我坚信，伟大的组织应该像对待任何其他服务一样对待他们的平台——也就是说，平台应该是一个记录良好的 API。

这个想法如何应用于不同的业务？

这对于不同的舞台公司来说会有所不同，但在很多方面，这个概念应该始终保持不变。如果你是一个刚刚起步的小组织，使用众所周知的平台即服务(PaaS ),如 Heroku 或由云提供商运营的平台。为什么？因为这正是一个伟大的 PaaS 的本质——一个记录良好的 API。

随着组织的发展，您可能需要有人来构建和维护您自己定制的 PaaS。我仍然相信凯尔西·海塔尔最近在推特上的话:

“我确信大多数管理基础设施的人只是想要一个平台即服务。唯一的要求是:它必须由他们来建造。”

在任何显著的规模或范围内，一个组织都会想要构建自己的平台。组织越来越多地采用服务所有权，而不是拥有一个独立于开发团队的运营团队，该团队需要保持每项服务的正常运行(这是一种旧的做事方式，很难扩展)。这一概念表明，从事服务开发的工程师应该对整个生产过程负责，包括应对特定服务的停机时间。

平台团队没有理由与这种模式不同。

你能举个例子吗？

让我们考虑一个非常简单的电子商务组织，它有两项服务:在线店面和购物车服务。两者都由不同的团队维护。在小型组织中，他们可能只是使用 Heroku 之类的东西来解决所有的基础架构部分。但是随着组织的成长，它必须决定是否需要对扩展、内部网络等进行更细粒度的控制，因此，它决定采用 Kubernetes 之类的东西。让两个不是基础设施专家的团队(更不用说 Kubernetes)来构建和维护基础设施，就像让 Kubernetes 的工程师维护 Haskell 服务一样是错误的。

相反，雇佣几个工程师去构建一个基础设施的良好记录的 API 定制的 PaaS——可能更有意义。这需要时间，也需要努力去维护。但是基础设施团队不应该比购物车团队更负责店面服务。同样，购物车团队不应该比店面团队对基础设施承担更多的责任。每个人对输入应该是什么样的、输出是什么样的以及成功是什么样的都有明确的期望。

什么是最佳实践？

不要再花时间担心是否应该建立一个 SRE 组织、一个平台团队、一个 DevOps 团队，或者是否应该让所有的应用工程师来构建和维护东西。取而代之的是，用你考虑组织中任何服务的方式来考虑你的平台。该平台应该是一个记录良好的 API，使其他人能够将事情传递给它，当出现问题时提供良好的错误消息，并成功地解决如何改进问题。

伟大的工具使这一切成为现实。像 Fairwinds Insights 这样的工具可以帮助您的软件工程师了解他们可以在 Kubernetes 中部署什么，以及什么样的配置是合适的。作为一种解决方案，Insights 可以停止运行过度许可或过度调配工作负载的部署，并且关于如何正确行事的文档就内置在该平台中。

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

像构建软件团队一样构建平台团队。对于服务、应用程序(无论大小)和基础设施来说，记录良好的 API 都是黄金标准。如果您正在使用 Kubernetes，请利用 Fairwinds Insights 使其变得简单。

你可以建立可靠的 Kubernetes 集群而不会失眠

原文：https://www.fairwinds.com/blog/you-can-establish-reliable-kubernetes-clusters-without-losing-sleep

Kubernetes 的完全服务所有权，就像 DevSecOps 的原则一样，是一个编纂过程，所有团队通过这个过程保持对其产品和服务的完全控制。从软件设计到产品部署，再到开发生命周期的结束，强大的服务所有权模型提供了无数的好处。它不仅让开发人员能够为他们的创新负责，而且还优化了业务成功的五个关键促成因素:合规性成本 、可伸缩性，以及最后一个人们不常考虑的方面——可靠性。

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

KUBERNETES 服务所有权完全指南

对于拥有数十、数百甚至数千个集群的组织来说，提高可靠性领域的整体效率和生产力至关重要。服务所有权全面优化了可靠性，特别是在促进最佳实践和扩展能力方面。当服务所有者使用这些指南和防护栏配置 Kubernetes 策略时，可靠性出现，以确保快速和一致的应用性能，几乎没有停机时间。

阅读我们关于如何优化 Kubernetes 的最新白皮书:

优化你的 KUBERNETES 所有权的 5 种方法

服务的可靠性

当 Kubernetes 环境体验到稳定性、简化的开发和运营，以及云原生基础架构的增强用户体验时，您应该感谢可靠性。一个健壮的应用程序表现良好，甚至在突发事件时也是如此。Kubernetes 的可靠性确保了集群的健康，尤其是在通过一系列最佳实践实现和协调时。是的，建立服务所有权模型是重中之重。

也就是说，可靠性有一个弱点。没有适当的配置，它根本无法成功。Kubernetes 中的错误配置是迄今为止最大的问题之一，也影响了基础设施的安全性和整体效率。 在组装一个稳定可靠的 Kubernetes 集群时，有很多因素需要考虑，包括应用程序更改和集群配置变更的潜在需求。这些考虑因素包括对适当的资源请求和限制的需求，使用正确的指标自动扩展 pod，以及使用活跃度和就绪性探测器。

您可能想知道，“配置管理呢？”使用这项技术，增强可靠性的挑战很简单，但解决方案却很复杂。配置管理，也称为“基础设施即代码(IaC)”，并不直接适合云原生容器生态系统。IaC 是使用配置文件管理 IT 基础设施的过程。IaC 的优势包括:

人为失误少……

这通过可预测的结果发生。 您可以创建新的环境来测试基础设施升级，以验证变更而不影响生产。如果您想在多个环境中应用更改，使用代码可以减少错误，因为对细节的关注较少受到重复性手工工作的影响。

重复性和一致性……

IaC 的可重复性有助于更快地在其他地区创建一致的基础设施，从而腾出时间应对下一个挑战。

灾难恢复……

如果您在危机中使用手动流程或复杂的工具链来重建容器映像，那么灾难恢复将需要更长的时间。应用程序的可靠性受到转换能力和重新部署速度的影响。请确保您了解该流程，包括如何建立正确的实践、工具和底层流程，以确保成功部署。

提高了可审核性……

IaC 还有助于跟踪审计基础设施的变化。因为您的基础设施是用代码表示的，所以对 Git 存储库的提交反映了谁、何时以及为什么进行了更改。您将能够查看代码并了解环境是如何构建的，发生了什么以及为什么。

需要明确的是，Kubernetes 不能仅仅建立在现有流程之上。相反，云原生方法提供了调整应用程序组件如何通信和扩展的机会。

分布式工作的可靠性

Kubernetes 提供了一个分布式系统运行的框架，使用微服务和容器来弹性运行应用程序。不同的团队拥有不同的堆栈层，这是服务所有权的一个关键原则。开发人员专门负责将他们的应用程序下载到 Kubernetes，并确保它们配置正确。

为了让这种模式发挥作用，开发运维团队需要将主要精力放在发现应用层的可见性上。他们还必须拥有自助工具来帮助他们监控应用程序，例如诊断可靠性问题的可观察性工具。Kubernetes 的完全服务所有权将运营团队从拥有所有部署配置中解放出来，转而让他们负责策略执行和为开发人员提供可操作的反馈，从而促进了这一领域的成功。

好方案的可靠性

在 Kubernetes 环境中引入过多的复杂性是有可能的。目标是在构建稳定可靠的集群时保持简单。这个目标可以通过几种不同的方式来实现，当与 SaaS 平台结合使用来保护和管理 Kubernetes 环境时，这个目标是最可行的。当你进入 IaC、容器、云原生应用和 Kubernetes 的世界时，考虑改变你的方法。考虑将现有工具和流程放在哪里，以及托管服务如何帮助您的组织充分利用容器化工作负载的诸多优势。

fair winds Insights，我们的安全和治理平台，可以提供帮助。 事实上，在您的集群中安装和配置了多种工具，以确保安全性、资源优化和可靠性检查。如果不能集中了解正在发生的事情，时间和资源就会被浪费，甚至更糟。不仅仅是安全软件，不仅仅是成本软件，不仅仅是政策软件，Fairwinds 提供了一个包含所有这些需求的单一平台。在一个控制面板视图中，团队可以评估安全性、控制应用规模和成本优化、实施策略并实现服务所有权。开发运维团队不再需要选择多个供应商来解决每个特定问题。

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

借助 Fairwinds Insights 大规模运营 Kubernetes 开源工具

原文：https://www.fairwinds.com/blog/you-can-operationalize-kubernetes-open-source-tools-at-scale-with-fairwinds-insights

在 Fairwinds，我们在管理数十个组织的数百个 Kubernetes 集群方面有着悠久的历史。为了管理这种复杂性并让我们的客户保持在线和正常运营，我们需要一种方法来跟踪这些群集的健康状况，特别是在安全性、效率和可靠性方面。所以我们建立了 Fairwinds Insights 平台，这个平台可以运行不同的 Kubernetes 审计工具，并将结果汇总到一个仪表板中。

Fairwinds Insights 通过将一组可扩展的可信开源审计工具集成到一个平台中，提供了对 Kubernetes 环境的多集群可见性。Fairwinds Insights 贯穿整个开发生命周期，从持续集成(CI)到进入生产阶段。

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

连续累计

对我们来说很重要的一点是，Insights 在开发过程的早期就发现了问题，因此我们可以阻止问题进入一个活跃的集群。因此，我们的第一步是将见解集成到基础设施即代码的持续集成(CI)流程中。当您将 Fairwinds 的见解添加到 CI 流程中时，您可以在开发流程的早期发现映像漏洞和 Kubernetes 错误配置。

Insights 可以扫描每个拉取请求中的更改，因此只要有安全、效率或可靠性问题，您就可以通知开发人员或阻止合并。为了找到这些问题，Insights 在 CI 中运行以下报告类型:

• Polaris :最佳实践的配置验证
• Trivy :扫描 Docker 镜像寻找漏洞
• 开放策略代理:(又名 OPA)运行定制策略
• 冥王星:检测废弃的资源

将 Insights 连接到您的 GitHub 存储库将帮助您充分利用 CI 集成，但是您仍然可以在没有 GitHub 的情况下使用 CI 特性。(如果您正在使用 Gitlab、Bitbucket 或其他 Git 主机，请告诉我们！)在我们的文档中了解关于配置的更多信息。

准入控制器

Fairwinds Insights 还可以作为准入控制器运行。这将拒绝任何 Kubernetes 资源进入您的集群，如果他们不符合您的组织的政策。准入控制器增加了一层额外的保护，以防 CI 流程中出现问题，或者有人在没有使用基础设施即代码存储库的情况下向集群添加资源。Fairwinds 还通过自动化规则为准入控制器的细粒度定制提供了强大、灵活的解决方案。

洞察代理

最后，Insights 还提供了一个集群内代理来扫描集群内部已经存在的问题。代理每小时生成报告，并将数据发送回 Fairwinds Insights。用户可以启用或禁用几种不同的开源报告工具(如 Polaris、Trivy、 Prometheus Collector 和 Goldilocks )，并可以使用报告中心独立配置它们。

调查结果和建议存储在一个位置，使运营商能够了解和控制多个 Kubernetes 集群，跟踪和优先处理问题，并监控 Kubernetes 工作负载的安全性和成本。

OPA 和 Fairwinds 的见解

我们通过三种主要方式将 OPA 集成到 Fairwinds Insights 中:

1. 作为 CI/CD 挂钩，作为代码评审过程的一部分，审计基础设施即代码
2. 作为准入控制器(又名验证 Webhook)，它将阻止有问题的资源进入集群
3. 作为集群内代理，重复扫描有问题的资源

通过将 Fairwinds Insights 和 OPA 结合使用，组织可以主动将其 Kubernetes 集群与最佳实践和内部策略保持一致。此外，在开发和部署流程的每个步骤中运行 OPA 的能力有助于在问题进入集群之前尽早发现问题，从而更容易地在开发和运营之间进行交接。更好的是，Insights 可以采用相同的 OPA 策略，并将它们联合到所有三个上下文，以及您想要的任意多个集群。

最小化复杂性

Insights 平台使 DevOps 团队能够在应用从开发进入生产时发现并防止配置问题。通过与这些工具集成，Insights 帮助团队大规模运营开源。您可以通过阅读 Insights 文档或免费使用它来了解更多信息！拿过来。

你永远不应该在 Kubernetes 第 5 部分:你的 4 大常见问题

原文：https://www.fairwinds.com/blog/your-top-4-kubernetes-faqs

正如我们在本系列中所讨论的，有些事情你绝对不应该在 Kubernetes 中做。云中尖叫创始人兼鸭嘴集团首席云经济学家 Corey Quinn 、Fairwinds 总裁 Kendall Miller 和 Fairwinds 技术负责人(CRE 团队)Stevie Caldwell 就他们看到的一些基本错误，以及他们在过去几年帮助客户部署 Kubernetes 时遇到的一些最常见的 Kubernetes 安全性、可靠性和效率问题进行了精彩对话。在网上研讨会期间，与会者向我们提出了许多问题，我们很乐意与您分享。让我们来看看你的四个常见问题，如果开发和运营团队想从领先的容器编制器中获得最大收益，他们绝对不应该在 Kubernetes 中做什么。

1.我们可以(或者应该)运行工作平面和控制平面的组合节点吗？

答案是否定的。最好缩小控制平面的节点大小，称之为好。这又回到了“不要在你的控制平面上运行工作负载”这一条。这是因为最好的做法是将它们分开。通常这类事情是出于成本考虑，但是有其他更好、更安全的方式来运行集群并控制成本，而不是试图将所有节点组合成一个。通过让您的etcd集群也与控制平面位于同一位置，您已经采取了一种中间立场。(一些 Kubernetes 专业人士说，您应该从控制平面外部运行etcd。)如果您减小控制平面节点的大小，您可以调整工作节点的资源大小，这样您就不会使用太多资源，并且您应该利用自动缩放来缩小您的集群。你可以做各种各样的事情来节省运行 Kubernetes 的成本，但不要运行工人和控制平面节点。

2.我应该在 Kube 中运行数据库吗？

数据存储应该在 API 的后面，驱动数据存储的实际上是一个实现问题。如果您打算在 Kubernetes 上运行数据库，您需要有一个关于卷、持久性、备份、恢复等等的计划。虽然这个想法并不荒谬，但你确实需要为它设计架构。考虑一下，如果一个容器消失了，并且在一段时间内没有被替换，而这就是你的数据库运行的地方，会发生什么？

如果您正在运行的环境中提供了托管解决方案，那就值得一看。例如，如果您在 AWS 上运行您的工作负载，使用他们的数据存储产品，如 Aurora 或 RDS，比运行您自己的要容易得多。这将增加很多复杂性，所以如果没有必要，为什么要这样做呢？Kubernetes 建立的前提之一是所有数据都是短暂的。这就是为什么事物像它们一样自由地移动，为什么你失去一两个节点也没有关系。但是，当我们开始遇到持续的数据问题时，就像您处理数据库一样，那么您就必须相应地进行规划:

• 你把数据存储在哪里？
• 当运行您的数据库的 pod 需要去别的地方时会发生什么？
• 然后，pod 会被安排在另一个可用性区域中的节点上吗？
• 如果将它移动到另一个可用性分区，它正在写入的卷是否不再对它可用？
• 是否必须设置持久卷并设置区域关联或节点关联？

当你在 Kube 中运行一个数据库时，它变得非常复杂。所以你需要考虑这样做会有什么收获。这可能会增加一些事情的灵活性，但对于其他事情来说没有意义，所以请仔细考虑您的用例，因为在 Kubernetes 中运行您的数据库会增加很多复杂性。

3.K8s 计费有没有成本细分的解决方案？

例如，如果每个客户端有一个名称空间，并且想要计算每个名称空间的每月和班级，该如何做呢？我们有一个工具, Fairwinds Insights ,可以计算相对每日成本，并按服务进行细分。它还告诉您这些东西在哪个名称空间中，并帮助您优化您的资源请求，确定您正在请求什么和您可能会请求什么。Fairwinds Insights 还提供数据，向您展示随着时间的推移您将节省多少。

还有其他工具可以做类似的事情。 CloudZero 比如云成本智能平台。 Kubecost 专门关注 Kubernetes 的成本。 VMware 收购了另一家公司 CloudHealth ，该公司提供了一些跨云环境优化成本和使用的功能。来自 Apptio 的云能力帮助团队优化云资源的速度、成本和质量。

关心 Kubernetes 工作负载的人通常有两个很难找到好答案的问题。一个是跟踪共享资源；对于必须存在的事物，你如何分配和归属它们？另一个问题与数据传输有关，目前还没有很好的工具选项。例如，如果您正在使用 AWS，并且您有两个相互通信的服务，则数据传输要么是免费的，要么如果出于持久性目的，它们位于两个可用性区域中，则每千兆字节的成本为 2 美分。当我们谈论 Pb 级工作负载时，这是一大笔钱。

4.可以在 prem 上使用 Fairwinds Insights 吗？

简而言之，答案是肯定的——我们现在有了一个独立的 Fairwinds Insights 版本。Fairwinds Insights 从 Polaris 以及近十几个其他 Kubernetes 审计机构(如 Trivy 、 Goldilocks 和 kube-bench )获取数据，并将所有结果放在单一窗口中。自从推出我们的 SaaS 产品以来，我们发现一些北极星用户担心将数据发送给第三方，特别是医疗保健和金融等数据敏感行业的企业。为了解决这些问题，我们在过去几个月中努力构建了一个可以完全在客户环境中运行的 Insights 版本。我们最近发布了一篇文章介绍我们新的自托管 Fairwinds Insights ，其中解释了它的工作原理以及使用本地版本的利弊。如果您有兴趣查看 Fairwinds Insights，请查看 Fairwinds Insights 演示。

你没有监督 Kubernetes 的成本，你应该这样做

原文：https://www.fairwinds.com/blog/youre-not-monitoring-kubernetes-cost-and-you-should-be

当我得到第一份(真正的)工作，在一家冰激凌和三明治店洗碗时，我花光了最初几份薪水中的每一分钱。然后我爸建议我开始存点钱。我记得听到这个建议时想，“嗯，是的，我想这是有道理的。”关注这些钱在做什么，并有意为之，这似乎是显而易见的，但我以前从未停下来考虑过。

似乎所有给个人的财务建议都包含两点:

1)尽快开始存钱，哪怕只是一点点

2)创建预算

舒适地步入成年通常需要这两类中至少一类的技能。

令我着迷的是，大多数公司虽然有预算意识，但在谈到云基础架构的成本时，似乎都有 盲点 。事实上， CNCF 最近发布了一份关于 FinOps 和 Kubernetes 的白皮书，其标题字面意思是，“Kubernetes 成本监控不足或不存在导致超支。”报告的标题集中在很多人没有在 Kubernetes 上做成本监控。一点也不。

我已经经历了足够多的公司预算规划会议，相信预算可能是非常普遍的。但我也知道许多公司只是接受云成本的增加，而不会问任何关于钱去了哪里的问题。了解云支出的工程师之间经常开玩笑说，他们会有人问他们关于一次零散的 Twix 购买(这真的是出于商业原因吗？)，但是他们可以在他们公司的虚拟专用云(VPC)中旋转几个 10，000 美元/实例，甚至没有人会注意到。

该报告显示，就 Kubernetes 而言，按集群、命名空间或工作负载划分的成本去向更不明确。在这份报告中，68%的公司表示他们的成本在增加。

我不得不相信，如果你自己的个人预算逐年增加，你会想知道这些钱去了哪里。管理 Kubernetes 花费的软件已经存在，根据你的云花费，你很有可能通过购买和使用它来省钱。事实上，当您要求您的基础设施团队使用软件来管理他们的 Kube 支出时，他们的反应可能是“嗯，是的，我想这是有道理的。”

这份报告值得花些时间仔细研究。你可能是许多忽视你的 Kubernetes 费用的人之一。也许你团队中的某个人告诉你这个问题太难监控了——由于 Kubernetes 的细微差别，你自己很难建立这种逻辑——但这也是像fair winds Insights这样的软件可以解决的问题。

没有理由在不了解云支出去向的情况下开展业务。适用于我 16 岁时的经验仍然适用于你的生意。不一定很难！我们可以帮助简化这一过程——我们的 免费层 是一个低摩擦选项，您可以使用它来快速了解您的 Kubernetes 支出，并进入“嗯，是的，我想这是有道理的”阶段。

想了解 Kubernetes 对云消费的贡献吗？阅读【Kubernetes 成本优化指南】

从零到 SRE:初级工程师的第一天

原文：https://www.fairwinds.com/blog/zero-to-sre-day-one-for-your-junior-engineer

这将是一个由三部分组成的博客系列，介绍如何为塑造公司文化的组织领导培养初级工程师，如首席技术官、工程副总裁和团队领导。它来自 Fairwinds 的现场可靠性工程师 Kim Schlesinger。在成为 SRE 之前，Kim 是位于科罗拉多州丹佛市的一所代码学校“激励”的讲师、Web 开发人员和课程设计人员。她活跃于科罗拉多州教育公平领导分会，是一家致力于让科技行业更加公平的公司 diversity 的联合创始人。

第一天:初级工程师学习计划

所以你创造了一种重视团队、重视冒险和学习的文化。你雇了一名初级工程师。这是第一天，他们将接受标准的入职培训。但是不要等太久来融入你的新员工。为他们提供一份清晰的、可衡量的期望清单，描述在他们受雇的角色中对他们的期望。

也许你应该在第一天为你的初级工程师准备的最重要的事情是一个与你的工程团队正在做的日常工作相一致的技术学习计划。互联网上有很多学习计划，很多很棒的内容，但是你想创造一条看起来像你的工程师所做的工作的道路。虽然你可以从一个模板开始，但你要调整学习计划，使其反映你的下属已经具备或不具备的技能。

当我开始在 Fairwinds 工作时，在工作的头两个小时内，有人递给我一份学习计划。这很神奇，因为它反映了我的技能，也显示了我需要学习的东西。这些主题包括:Linux 命令、用 AWS 构建虚拟私有云以及用 Docker 和 Kubernetes 实现编排的容器化。因此，当你的初级工程师在学习计划中工作时，他们应该参与并独立完成作为该计划一部分的大大小小的项目。

当你考虑学习计划时，确保你为你的初级工程师建立了支持和责任体系。和新员工一起设定最后期限。他们不必真的认真，可以感动。但是说，“让我们试着在 x 日期前完成你学习计划的第一部分”，并确保你有一个过程，初级工程师可以很容易地寻求帮助。最后，你需要建立定期的检查机制来讨论学习计划，这样他们就可以快速地完成。

如果你对学习计划的样子感到好奇，我已经在我们的 GitHub 组织中发布了 Fairwinds 学习计划。

不过，在第一天，开始把新员工带进你的团队。您希望他们尽快成为您团队的重要成员。在第一天，把这个人介绍给他们的团队，安排他们定期参加团队会议，让他们的队友开始向他们展示诀窍，即使只是登录你的福利平台。最后，在第一天，明确你什么时候希望你的下级对不起，贡献他们的第一个独立的拉请求——与你的代码库或客户有关的东西。

我在反应行动的第一天就有了学习计划。我经历了所有的入职培训。最后，我要去见我们的首席运营官，肯德尔·米勒。他坐下来对我说，“嘿，金，我们很高兴你能来。你知道，我们以前从来没有真正雇佣和训练过一个新人。所以我们是第一次学习这个。我们知道你从未做过现场可靠性工程，所以你有很多东西要学。”

鉴于所有这些，他告诉我，他不希望我在六个月内为我们的代码库做出贡献。所以六个月有点长。我的贡献比那要早得多。但肯德尔在那一刻向我展示的是，公司承诺给我时间来学习我需要知道的东西，以便真正为他们工作。因此，要清楚你的工程师的预期时间表，并真正致力于它们。我们已经雇佣了你，我们会给你时间和支持，让你通过给他们时间表来学习和展示。

这就是第一天需要发生的事情。接下来:走进未来。

零到 SRE:如何投资初级工程师

原文：https://www.fairwinds.com/blog/zero-to-sre-how-to-invest-in-junior-engineers

在软件领域寻找、招募和雇佣高级工程师并不容易。如果你成功了，这是一项昂贵的事业；高级工程师薪水很高。建立你的高级水平的一个更有效和包容的方法是投资于将初级工程师转变为优秀的中级工程师，然后是高级工程师的过程。这是任何公司的竞争优势。不幸的是，如果你的公司以前没有招聘过初级员工，你就需要做出改变，以便创造一个他们可以茁壮成长的环境。

这将是一个由三部分组成的博客系列，介绍如何为塑造公司文化的组织领导培养初级工程师，如首席技术官、工程副总裁和团队领导。它来自 Fairwinds 的现场可靠性工程师 Kim Schlesinger。在成为 SRE 之前，Kim 是位于科罗拉多州丹佛市的一所代码学校“激励”的讲师、Web 开发人员和课程设计人员。她活跃于科罗拉多州教育公平领导分会，是一家致力于让科技行业更加公平的公司 diversity 的联合创始人。

第一部分:创造成长文化

1982 年，当间谍机构还在交易代码时，两位名叫特伦斯·迪尔(Terrence Deal)和艾伦·肯尼迪(Allan Kennedy)的学者开始定义企业文化。他们的定义非常简单。文化是“这里做事的方式”在你培养初级工程师之前，你需要仔细看看“这里的事情是怎么做的”培养一种文化，在这种文化中，你将为他们提供个性化的资源和持续的支持，帮助他们成长为你的中级 和高级工程师。