周一见 | 微服务失败的 11 个原因、金融科技同样偏爱 K8s、CNCF 两个新 Sandbox 项目

作者：Bach（才云）

技术校对：星空下的文仔 （才云）、 bot（才云）

本文共计 3794   字，阅读大约需要  5  分钟

1

CNCF 两个新 Sanbox 项目

近日，通用服务网格 Kuma 与混沌工程工具集 LitmusChaos 被 CNCF 接纳为 Sandbox 项目。

Kuma 诞生于 2019 年 6 月，它是一个现代的通用服务网格控制平面，基于 Envoy 搭建（Envoy 是一个为云原生应用设计的代理软件）。 Kuma 可以在包括 Kubernetes、虚拟机、容器、裸机和传统环境在内的任意平台上运行，以落实整个组织中的云原生体验。

Kuma 提供 Kubernetes 和 Universal 两种模式，以对 Kubernetes 和 VM 工作负载提供支持。在最新发布的 0.6 版本中，Kuma 得到扩展，支持混合通用工作负载，这不仅允许用户跨 Kubernetes 和 VM 工作负载创建不同的服务网格，还可以在同一网格中一起支持它们。

Kuma 地址： github.com/Kong/kuma

LitmusChaos 是一种开源混沌工程框架，用于在 Kubernetes 环境中运行有状态应用。该项目支持用户运行测试套件、捕获日志、生成报告并执行混沌测试。

LitmusChaos 支持运行两类测试：混沌测试和功能测试。 混沌测试主要针对应用的可扩展性，框架中提供了多个预置测试，主要针对容器崩溃、磁盘故障、网络延迟和网络包丢失等预期外行为。功能测试则用于确保达到系统需求，其中包括对应用规模可扩展等需求的测试。

LitmusChaos 地址： litmuschaos.io

2

金融科技同样偏爱 K8s

Kubernetes 现在已经成为金融服务行业创新的新动力，许多世界领先的金融科技公司都是该技术的采用者。 K 8 s 成为金融机构首选技术有以下几个原因：

满足当今金融客户的需求

在过去几年中，金融企业客户的期望迅速提高。每一项新的创新对客户来说都非常值得期待，但它也给企业施加了更大的压力，这要求企业需要更快地创建和部署下一个想法，同时又不能影响安全性或产品质量。当我们准备推广新部署的想法时，K8s 的可扩展性意味着可以立即支持指数级增长的客户群，并在需求高峰时处理客户需求。

支持开发和运营

Kubernetes 允许团队在容器中构建和部署微服务，容器打包了软件，因此可以在不脱机的情况下快速发布和更新。这就是 Kubernetes 的亮点，它允许应用程序自动扩展基础架构，从而扩展应用程序以适应需求，同时降低基础架构成本。

为金融科技奠定坚实的基础

金融科技的信任点取决于应用程序的安全性、健壮性和弹性。停机和安全漏洞都可能会使金融企业丢失客户。K8s 允许开发人员团队在引入所有安全配置的情况下设置集群，因此不必担心应用程序在部署到基础结构上的安全性。

3

K8s 5 种最佳安全实践

在过去的几年里，Kubernetes 获得了迅速的发展，许多公司正在将 Kubernetes 部署到生产中，与此同时，我们应该更加注意安全问题。下面总结了 5 种 Kubernetes 安全实践：

使用基于角色的访问控制（RBAC）

基于角色的访问控制（RBAC）能控制谁可以访问 Kubernetes API 以及它们的相应权限。不过仅启用 RBAC 是不够的，我们还应该管理授权策略并正确使用它们。始终遵循最小特权原则，以确保用户和 Kubernetes 服务帐户具有所需的最少特权集，除非绝对必要，不要给予集群范围的权限，也不要给予任何集群管理员权限。

secret 应该是秘密

secret 包含敏感数据，例如密码、令牌或 ssh 密钥。Kubernetes secret 有助于使用诸如密钥、密码、令牌等来安全地初始化 Pod。Kubernetes 支持静态加密，会对 etcd 中的 secret 资源进行加密。

安全的节点和 Pod

Kube rnetes 节点是一个工作节点，可以是通常运行 Linux 操作系统（OS）的 VM 或物理机。 Pod 就像是豌豆荚，它由一个或者多个容器组成，共享容器存储、网络和容器运行配置项。 加强 和保护节点和 Pod 安全的重要性不言而喻。

消除容器安全风险

应用程序打包为容器镜像，容器镜像被存储并从容器注册表中提取。在为应用程序构建容器时，我们必须在开发过程的开始阶段就将安全性放入设计原则中。

审核、记录和监控至关重要

审核、日志记录和监控是重要的安全方面，可以帮助改善集群的安全状况。Kubernetes 审核日志是对 Kubernetes API 服务器每次调用的详细记录。这些审核日志提供有关集群中发生情况的有用信息，可以用于审核、合规性和安全性分析。

4

微服务失败的 11 个原因

微服务有许多优势，比如更快的开发、更好的可扩展性、更小的独立团队等等， 但是很多团队在微服务上举步维艰，没有很好地利用其优势。 下面总结了使用微服务失败的 11 个原因：

管理层低估开发微服务的复杂性

很多管理层和客户都认为微服务是可以解决他们所有问题的“灵丹妙药”，但实际上，大多数团队和其管理层都低估了微服务开发的复杂性。

要开发微服务，开发人员需要一个高效的本地环境设置。 随着系统中服务数量开始增加，在一台机器上运行应用程序的子集变得越来越困难。 特别是使用消耗较多内存的语言（如  Java）构建应用程序时。 如果组织对微服务开发的复杂性缺乏理解，那么团队速度将会随着时间的推移而下降。

没有将库和工具更新到最新版

很多团队没有确保依赖项是最新版本，也没有将数据库等工具升级到最新版本。因此，有些两年前开始的现代化改造，如今已经背负了长达数月的技术债。我们最好使所有的依赖项版本保持同步。

利用共享服务促进本地开发

由于本地开发状况不佳，许多团队开始依赖于共享环境来获得关键服务。开发人员的第一件事是数据库，但大多数年轻的开发人员还没有意识到基于共享数据库的开发是很危险的。数据库只是共享的一个示例，消息队列、集中缓存或其他服务同样如此。

版本控制托管平台缺乏可见性

曾经有个团队，他们的版本控制系统中有 1000 多个仓库，他们的 5 个产品，每个都由多个微服务组成。当他们想要了解哪些服务和代码库属于某个产品时，发现很难理清。对于这种情况，最好一开始就用某种方式对微服务进行分组，这样就能随时了解产品的生态系统。

服务没有明确定义

究竟是什么构成一个单一的微服务，很多人并不清楚。很多团队为每个集成创建一个微服务。随着集成数量的增加，团队将越来越难以管理这些服务，并且它们通常很小，如果作为单独的进程运行，还会增加更多的开销。

代码重用策略不明确

有些团队会在他们所有基于 Java 的微服务复制多个与特定问题相关的 Java 文件，这会导致如果在该代码中发现 bug 的话，就需要将其修复应用到所有地方，这会非常麻烦。

多语言编程设计

很多团队使用多种编程语言、多种数据库、多种缓存进行工作。在项目初始阶段时，这可能没有什么关系，但进入生产阶段后，问题就会开始显现了。

人员的依赖性

该现象在微服务生态系统中非常普遍。大多数团队只专注于他们的特定服务，所以他们并不了解完整的生态系统。

文档的缺乏

大多数团队都在文档方面都遇到过困难。开发人员和架构师要么不去编写文档，要么编写的文档毫无用处。即使他们想写，他们也不知道应该如何记录他们的架构。

功能超过平台成熟度

微服务要比传统的单体式应用（monolithic application）更为复杂。如果管理层仅关注功能，那注定会失败，因为在薄弱平台上构建的功能是无法提供价值的。

缺乏自动化测试

大多数团队都知道自动化测试对产品的整体质量有多重要，但是他们仍然没有做。如果不进行彻底的自动化测试，那么他们一定会失败。

5

11 种让 K8s 更易用的工具

Kubernetes 已成为大规模部署容器化应用程序的标准方法，这里介绍了 11 种 Kubernetes 相关工具，以改善监视、命令行操作、多集群管理等。

Goldpinger：可视化 Kubernetes 集群。 Goldpinger 工具很简单，它在 Kubernetes 集群中运行，并显示节点之间关系的交互式地图。健康的节点显示为绿色，不健康的节点显示为红色。我们只需单击一个节点就可以获取详细信息。另外，它可以使用 Swagger 自定义 API，以引入其他报告、指标或其他集成。

K9s：全屏Kubernetes CLI UI。 K9s 是 Kubernetes 集群的全屏 CLI UI。它可以快速查看正在运行的 Pod、日志和部署的视图，并可以快速访问 Shell。

Kops：Kubernetes 集群的命令行操作。 Kops 让命令行管理 Kubernetes 集群。除了自动进行设置和拆卸过程外，Kops 还可以帮助进行其他类型的自动化。例如，它可以生成 Terraform 配置，以允许使用 Terraform 重新部署集群。

Kubebox：Kubernetes 的终端控制台。 Kubebox 是 Kubernetes 的高级终端控制台，不仅为 Kubernetes 及其 API 提供了 shell，还提供内存和 CPU 利用率、窗格列表、运行日志和配置编辑器的交互式显示。

Kube-applier。 Kube-applier 作为 Kubernetes 服务运行，它从 Git 存储库中获取 Kubernetes 集群的声明性配置文件，并将其应用于集群中的 Pod。每当对定义文件进行更改时，都会将它们从存储库中提取并应用于相关的广告连播。

Kube-ps1：Kubernetes 命令提示符。 Kube-ps1 可在提示中显示当前的 Kubernetes 上下文和名称空间。

Kube-prompt：交互式 Kubernetes 客户端。 Kube-prompt 允许输入相当于与 Kubernetes 客户端的交互式命令会话的内容，并为每个命令提供带有上下文信息的自动完成功能。

Kubespy：Kubernetes 资源的实时监控。 Kubespy 是一种诊断工具，可实时跟踪对 Kubernetes 资源的更改，从而提供了一种实时的文本视图仪表板。

Kubeval：验证 Kubernetes 配置。 Kubeval 在本地使用或集成到 CI/CD 流水线中，接受 Kubernetes YAML 配置定义并报告其有效性。

Kube-ops-view：多个 Kubernetes 集群的仪表板。 Kube-ops-view 提供了以图形方式呈现的多个 Kubernetes 集群的概览视图，可以一目了然地看到集群中整个 CPU 和内存使用率以及 Pod 的状态。

Rio：Kubernetes 的应用程序部署引擎。 Rio 在 Kubernetes 中实现了常见的应用程序部署模式，从而有助于管理 DNS、HTTPS 和服务网格等。

6

本周 K8s 开源项目推荐

k8s-image-availability-exporter

• 这是一个小型工具，可以连续检查 Kubernetes 对象中定义的所有容器镜像是否可用。

• github.com/flant/k8s-image-availability-exporter

awesome-kubernetes

• 这个项目包含了大量 Kubernetes 相关的文章和实践案例，建议在有一定基础知识后选择性学习。

• github.com/ramitsurana/awesome-kubernetes

Kubermatic

• Kubermatic 是一个开源的 Kubernetes 集群管理自动化平台。

• github.com/Kubermatic/Kubermatic

Polaris

• 这是一款通过分析部署配置，发现集群中存在的问题的健康检查组件，也提供问题的解决方案，确保集群处于健康状态。

• github.com/FairwindsOps/polaris

xlskubectl

• 它可以用 Excel 表格控制 kubernetes 集群。

• github.com/learnk8s/xlskubectl

cilium

• 这是一个用于提供并透明地保护应用程序工作负载之间的网络连接和负载均衡。

• github.com/cilium/cilium

推荐阅读：

在看点一下