关于后端:我们为何选择-Cilium-作为-Kubernetes-的网络接口

文本翻译自: https://blog.palark.com/why-cilium-for-kubernetes-networking/

原文作者是 Palark 平台工程师 Anton Kuliashov，其阐明了抉择 Cilium 作为 Kubernetes 网络接口的起因以及青睐 Cilium 的中央。

多亏了 CNI（容器网络接口），Kubernetes 提供了大量选项来满足您的网络需要。在多年依赖简略的解决方案之后，咱们面临着对高级性能日益增长的客户需要。Cilium 将咱们 K8s 平台中的网络晋升到了一个新的程度。

咱们为不同行业、规模和技术堆栈的公司构建和保护基础设施。他们的应用程序部署到公有云和公共云以及裸机服务器。他们对容错性、可扩展性、财务费用、安全性等方面有不同的要求。在提供咱们的服务时，咱们须要满足所有这些冀望，同时足够高效以应答新兴的与基础设施相干的多样性。

多年前，当咱们构建基于 Kubernetes 的晚期平台时，咱们着手实现基于牢靠开源组件的生产就绪、简略、牢靠的解决方案。为实现这一指标，咱们的 CNI 插件的自然选择仿佛是 Flannel（与 kube-proxy 一起应用）。

过后最受欢迎的抉择是 Flannel 和 Weave Net。Flannel 更成熟，依赖性最小，并且易于装置。咱们的基准测试也证实它的性能很高。因而，咱们抉择了它，并最终对咱们的抉择感到称心。

同时，咱们深信有一天会达到极限。

随着工夫的推移，咱们取得了更多的客户、更多的 Kubernetes 集群以及对平台的更具体的要求。咱们遇到了对更好的安全性、性能和可观测性的日益增长的需要。这些需要实用于各种基础设施元素，而网络显然是其中之一。最终，咱们意识到是时候转向更高级的 CNI 插件了。

许多问题促使咱们跳到下一阶段：

一家金融机构执行了严格的“默认禁止所有”规定。
一个宽泛应用的门户网站的集群有大量的服务，这对 kube-proxy 产生了压倒性的影响。
PCI DSS 合规性要求另一个客户施行灵便而弱小的网络策略管理，并在其之上具备良好的可观测性。
在 Flannel 应用的 iptables 和 netfilter 中，遇到大量传入流量的多个其余应用程序面临性能问题。

咱们不能再受现有限度的妨碍，因而决定在咱们的 Kubernetes 平台中寻找另一个 CNI —— 一个能够应答所有新挑战的 CNI。

明天有很多可用的 CNI 选项。咱们想保持应用 eBPF，它被证实是一项弱小的技术，在可观测性、安全性等方面提供了许多益处。思考到这一点，当您想到 CNI 插件时，会呈现两个驰名的我的项目：Cilium 和 Calico。

总的来说，他们两个都十分棒。然而，咱们依然须要抉择其中之一。Cilium 仿佛在社区中失去了更宽泛的应用和探讨：更好的 GitHub 统计数据（例如 stars、forks 和 contributors）能够作为证实其价值的某种论据。它也是一个 CNCF 我的项目。尽管它不能保障太多，但这依然是一个无效的观点，所有事件都是平等的。

在浏览了对于 Cilium 的各种文章后，咱们决定尝试一下，并在几个不同的 K8s 集群上进行了各种测试。事实证明，这是一次纯正的踊跃体验，揭示了比咱们预期更多的性能和益处。

在思考是否应用 Cilium 来解决咱们遇到的上述问题时，咱们喜爱 Cilium 的中央如下：

应用 bpfilter（而不是 iptables）进行路由意味着将过滤工作转移到内核空间，这会产生令人印象粗浅的性能晋升。这正是我的项目设计、大量文章和第三方基准测试所承诺的。咱们本人的测试证实，与咱们之前应用的 Flannel + kube-proxy 相比，解决流量速度有显着晋升。

eBPF host-routing compared to using iptables. source:“CNI Benchmark: Understanding Cilium Network Performance”

无关此主题的有用材料包含：

Why is the kernel community replacing iptables with BPF?
BPF, eBPF, XDP and Bpfilter… What are These Things and What do They Mean for the Enterprise?
kube-proxy Hybrid Modes

CiliumNetworkPolicy CRD 扩大了 Kubernetes NetworkPolicy API。它带来了 L7（而不仅仅是 L3/L4）网络策略反对网络策略中的 ingress 和 egress 以及 port ranges 标准等性能。

正如 Cilium 开发人员所说：“现实状况下，所有性能都将合并到规范资源格局中，并且不再须要此 CRD。”

借助 CiliumClusterwideNetworkPolicy，您能够管制节点间流量。这些策略实用于整个集群（非命名空间），并为您提供将节点指定为源和指标的办法。它使过滤不同节点组之间的流量变得不便。

易于应用的策略执行模式让生存变得更加轻松。default 模式适宜大多数状况：没有初始限度，但一旦容许某些内容，其余所有内容都会受到限制。Always* 模式 —— 当对所有端点执行策略时 —— 对于具备更高平安要求的环境很有帮忙。

Hubble 是一个真正杰出的网络和服务可观测性以及视觉渲染工具。具体来说，就是对流量进行监控，实时更新服务交互图。您能够轻松查看正在解决的申请、相干 IP、如何利用网络策略等。

当初举几个例子，阐明如何在我的 Kubernetes 沙箱中应用 Hubble。首先，这里咱们有带有 Ingress-NGINX 控制器的命名空间。咱们能够看到一个内部用户通过 Dex 受权后进入了 Hubble UI。会是谁呢？…

当初，这里有一个更乏味的例子：Hubble 花了大概一分钟的工夫可视化 Prometheus 命名空间如何与集群的其余部分通信。您能够看到 Prometheus 从泛滥服务中抓取了指标。如许棒的性能！在您破费数小时为您的我的项目绘制所有这些根底架构图之前，您应该曾经晓得了！

此在线服务提供易于应用、鼠标敌对的 UI 来创立规定并获取相应的 YAML 配置以利用它们。我在这里惟一须要埋怨的是短少对现有配置进行反向可视化的性能。

再此阐明，这个列表远非残缺的 Cilium 功能集。这只是我依据咱们的须要和咱们最感兴趣的内容做出的有偏见的抉择。

让咱们回顾一下咱们的客户遇到的具体问题，这些问题促使咱们开始对在 Kubernetes 平台中应用 Cilium 产生趣味。

第一种状况下的“默认禁止所有”规定是应用上述策略执行形式实现的。通常，咱们会通过指定此特定环境中容许的内容的残缺列表并禁止其余所有内容来依赖 default 模式。

以下是一些可能对其他人有帮忙的相当简略的策略示例。您很可能会有几十个或数百个这样的策略。

容许任何 Pod 拜访 Istio 端点：

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: all-pods-to-istio-internal-access
spec:
  egress:
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: infra-istio
    toPorts:
    - ports:
      - port: "8443"
        protocol: TCP
  endpointSelector: {}

容许给定命名空间内的所有流量：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-ingress-egress-within-namespace
spec:
  egress:
  - toEndpoints:
    - {}
  endpointSelector: {}
  ingress:
  - fromEndpoints:
    - {}

容许 VictoriaMetrics 抓取给定命名空间中的所有 Pod：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: vmagent-allow-desired-namespace
spec:
  egress:
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: desired-namespace
  endpointSelector:
    matchLabels:
      k8s:io.cilium.k8s.policy.serviceaccount: victoria-metrics-agent-usr
      k8s:io.kubernetes.pod.namespace: vmagent-system

容许 Kubernetes Metrics Server 拜访 kubelet 端口：

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: host-firewall-allow-metrics-server-to-kubelet
spec:
  ingress:
  - fromEndpoints:
    - matchLabels:
        k8s:io.cilium.k8s.policy.serviceaccount: metrics-server
        k8s:io.kubernetes.pod.namespace: my-metrics-namespace
    toPorts:
    - ports:
      - port: "10250"
        protocol: TCP
  nodeSelector:
    matchLabels: {}

至于其余问题，咱们最后遇到的挑战是：

案例 #2 和 #4，因为基于 iptables 的网络堆栈性能不佳。咱们提到的基准和咱们执行的测试在实际操作中证实了本人。
Hubble 提供了足够程度的可观测性，这在案例 #3 中是必须的。

总结这次教训，咱们胜利解决了与 Kubernetes 网络相干的所有痛点。

对于 Cilium 的总体将来，咱们能说些什么？尽管它目前是一个孵化的 CNCF 我的项目，但它已于去年年底申请毕业。这须要一些工夫能力实现，但这个我的项目正朝着一个十分明确的方向后退。最近，在 2023 年 2 月，Cilium 发表通过了两次平安审计，这是进一步毕业的重要一步。

咱们正在关注该项目标路线图，并期待一些性能和相干工具的施行或变得足够成熟。（没错，Tetragon 将会很棒！）

例如，尽管咱们在高流量集群中应用 Kubernetes EndpointSlice CRD，但相干的 Cilium 性能目前处于 beta 阶段 —— 因而，咱们正在期待其稳固公布。咱们正在期待稳固的另一个测试版性能是本地重定向策略，它将 Pod 流量本地重定向到节点内的另一个后端 Pod，而不是整个集群内的随机后端 Pod。

在生产环境中确定了咱们新的网络基础设施并评估了它的性能和新性能之后，咱们很快乐决定采纳 Cilium，因为它的益处是不言而喻的。对于多样化且一直变动的云原生世界来说，这可能不是灵丹妙药，而且绝不是最容易上手的技术。然而，如果你有能源、常识和一点冒险欲望，那么它 100% 值得尝试，而且很可能会失去多方面的回报。

关于后端:我们为何选择-Cilium-作为-Kubernetes-的网络接口

背景

随着需要的增长

为什么抉择 Cilium

咱们喜爱的 Cilium 的次要性能

1. 性能

2. 更好的网络策略

3. 节点间流量管制

4. 策略执行模式

5. Hubble 及其 UI

6. 可视化策略编辑器

Cilium 为咱们做了什么

下一步是什么？

后记