在第一次设置 Kubernetes 时,你可能会面临的一个网络挑战,是如何安全地授予外部客户机对集群的访问权。默认情况下,集群中的 pod 可以与所有其他 pod 和服务通信。你应该限制对该组之外的任何访问。
在这篇文章中,我们将详细介绍如何使用Kuma[2]来监控和观察 Kubernetes 流量,Kuma 是一种现代分布式控制平面,集成了 Envoy Proxy。
作为独立容器运行的应用程序堆栈,需要与其他应用程序和外部客户端通信。为了协调支持此类平台所需的所有需求(包括安全性、路由和负载平衡),服务网格的概念应运而生。服务网格的目标,是为网络上的任何服务提供无缝管理。因此,当入口控制器处理传入流量的行为时,服务网格负责监督网络的所有方面,比如监控和配置网络。
Kuma 是服务网格的一个例子。它是一个开放源码项目,可以跨各种环境工作,包括 Kubernetes 和虚拟机,并支持多区域部署。Kuma 由创建了Kong[3]的同一个团队支持,Kong 是一个简化网络通信的流行 API 网关。
除了提供细粒度的流量控制功能,Kuma 还提供快速度量和可观察性分析。能够保护你的网络访问只是解决方案的一部分。由于 Kuma 集成了用于原生数据收集的 Prometheus,以及用于绘制和查看数据的 Grafana,因此你将能够准确地看到负载平衡和客户端路由的行为。
安装 Kuma 是件轻而易举的事。首先,你可以像这样下载并运行安装程序:
curl -L https://kuma.io/installer.sh | sh -
然后,进入安装目录:
cd kuma-1.1.2/bin
从这里开始,你可以在多区域模式,或独立模式下(如果 Kuma 只是在一个 Kubernetes 集群中),运行 Kuma。下面的命令将在单个区域配置中部署 Kuma,是默认方式:
./kumactl install control-plane | kubectl apply -f -
对于其他环境,请参阅有关的部署文档[4]。
有几种与 Kuma 互动的方式。
要访问 GUI,首先需要转发 API 服务端口:
$ kubectl port-forward svc/kuma-control-plane -n kuma-system 5681:5681
之后,你可以浏览http://127.0.0.1:5681/gui。
在继续之前,有必要介绍一个关于配置的小问题,它有重要的含义。
Kubernetes 使用容器网络接口(CNI)标准[5]为容器配置网络。这意味着无论你如何设计与 CNI 兼容的工具,它都应该能够依赖于相同的协议集。Kubernetes 提供了一个 API,入口控制器可以使用它来设置和管理网络策略。为了响应企业级安全性和易用性需求,多个基于 CNI 的项目已经涌现出来。例如,Calico[6]就是这样一个项目。
根据你的需求,选择更可定制的服务网格,如 Kuma,可以帮助你实现特定的目标。例如,尽管 Calico 遵守 Kubernetes 提供的网络策略[7],但它制定流量规则的格式却比 Kuma 不透明。Kuma 提供了一种与 Kubernetes 提供的一流 API 并行运行的网络策略配置方法。Kuma 也与 CNI 兼容,这应该不足为奇。这意味着你可以轻松地交换 Calico 定义的任何网络策略,或者为 Kuma 的流量规则使用基于 CNI 的协议的任何项目。这类项目之间的主要区别在于特性。例如,Kuma 可以集服务网格、可观察平台和网络策略管理器于一体。其他项目可能有不同的优先级,开发人员有责任确保它们能够相互正确交互。
在 Kubernetes 上设置并运行 Kuma 后,让我们看看如何建立流量规则来管理访问。
想象以下场景:一个电子商务平台依赖于两个微服务,它们通过通信来满足业务需求——我们将它们称为服务 backend1 和 backend2。第三个微服务充当公共 API,对该服务的任何传入请求都会私下查询另外两个。我们希望将 API 暴露给公众,但保持其他两个微服务与外部网络隔离。
实现此目的的纯入口方法是设置网络策略[8]。然而,Kuma 使用易于理解的 YAML DSL 极大地简化了这个过程。你可以定义流量权限策略[9],该策略显式地标识哪些源服务可以与特定的目标服务通信。
cat <<EOF | kumactl apply -f -
type: TrafficPermission
name: api-to-backends
mesh: default
sources:
- match:
service: 'publicAPI'
destinations:
- match:
service: 'backend1'
- match:
service: 'backend2'
EOF
在此清单中,Traffic Permission 策略允许前台向后端发送流量。该策略将拒绝任何其他来源。
Traffic Permission 只是 Kuma 提供的策略之一。在其他功能中,还可以设置运行状况检查策略[10]来跟踪每个数据平面代理的运行状况。这也利用了熟悉的源和目标匹配:
cat <<EOF | kumactl apply -f -
apiVersion: kuma.io/v1alpha1
kind: HealthCheck
mesh: default
metadata:
name: web-to-backend-check
spec:
sources:
- match:
service: 'publicAPI'
destinations:
- match:
service: 'backend1'
- match:
service: 'backend2'
conf:
interval: 10s
timeout: 2s
unhealthyThreshold: 3
healthyThreshold: 1
tcp:
send: Zm9v
receive:
- YmFy
- YmF6
EOF
任何服务网格的目标,都是提供一个位置来配置网络在整个集群中的行为。服务网格可以简化不同服务之间的通信。选择限制更严格的网络安全通常比选择对任何连接开放的网络安全更好。使用 Kuma 实现零信任安全策略[11]是一流的特性,而不是事后才想到的。
如果你想了解更多关于正确访问配置的信息,可以查看Kubernetes 关于控制访问的文档[12]或他们在pod 安全方面的最佳实践[13]。Kuma 的安全访问模式[14]还提供了一些关于如何定义常用网络策略的指导方针。
我希望这些关于 Kubernetes 流量政策的信息对你有帮助。通过Kuma 社区[15],或以下资源了解更多利用 Kuma 来满足你的连接需求:
[1]
Kong 博客: https://konghq.com/blog/traffic-policies-kubernetes/
[2]
Kuma: https://kuma.io/
[3]
Kong: https://github.com/Kong/kong
[4]
部署文档: https://kuma.io/docs/1.1.2/documentation/deployments/
[5]
容器网络接口(CNI)标准: https://github.com/containernetworking/cni
[6]
Calico: https://www.projectcalico.org/
[7]
网络策略: https://kubernetes.io/docs/concepts/services-networking/network-policies/
[8]
网络策略: https://kubernetes.io/docs/concepts/services-networking/network-policies/
[9]
流量权限策略: https://kuma.io/docs/1.1.4/policies/traffic-permissions/
[10]
运行状况检查策略: https://kuma.io/docs/1.1.4/policies/health-check/#usage
[11]
零信任安全策略: https://kuma.io/docs/1.1.6/policies/mutual-tls/
[12]
Kubernetes 关于控制访问的文档: https://kubernetes.io/docs/concepts/security/controlling-access/
[13]
pod 安全方面的最佳实践: https://kubernetes.io/docs/concepts/security/pod-security-standards/
[14]
Kuma 的安全访问模式: https://kuma.io/docs/1.1.4/security/certificates/
[15]
Kuma 社区: https://kuma.io/community/
[16]
Kuma 服务网格入门: https://konghq.com/blog/getting-started-kuma-service-mesh/
[17]
通过 OPA 和 Kuma 授权微服务 API: https://konghq.com/blog/authorize-api-opa-kuma
[18]
使用 Kuma 实现服务网格可观察性自动化: https://konghq.com/blog/service-mesh-observability
点击【阅读原文】阅读网站原文。
中国 KubeCon + CloudNativeCon + Open Source Summit 虚拟大会