【2021年4月版本】Kubernetes导航第二部分：网络服务相关

2 年 ago
雅, 悟
2 minutes

Kubernetes 导航服务

在这个系列中，我们大致介绍了构成Kubernetes集群的各种组件和技术。

    • 【2021年４月版】Kubernetes ナビ その１: ディストリいろいろ

 

    • 【2021年４月版】Kubernetes ナビ その２: ネットワーク・サービス関連

 

    • 【2021年４月版】Kubernetes ナビ その３: ストレージ関連

 

    • 【2021年４月版】Kubernetes ナビ その４: コンテナ関連

 

    【2021年４月版】Kubernetes ナビ その５: Serverless

这次将是第二次。

关于Kubernetes网络服务相关的组件概述。

k8s 的网络服务相关组件可以粗略地分为以下分类。

    1. LB/Ingress是接收集群外通信并将其转发到集群内的层。特别是LB通常位于”集群外”，通常与K8S分开部署。或者Ingress组件也可以兼具LB的功能。

 

    1. DNS/服务发现负责解析和监视集群内Pod和容器的命名。它是集群内交通管理的角色。在K8S中，通常是作为DNS和服务发现组件一起使用，而不是独立的DNS。

 

    1. CNI是支持容器之间通信隧道的容器网络接口（CNI）兼容组件。

 

    服务网格是将上述任一或多个组件结合起来，综合性地统一管理Pod集合和服务的机制。

那么，下面我将介绍各个分类的代表性组件。

LB / Ingress 是一个组件系列。

关于K8s的云服务

首先，正如之前所提到的，LB是连接集群外部和内部的关键组件，因此在提供作为云服务的k8s服务的情况下，各公司会提供各自独有的LB/Ingress作为专用组件或服务，用于连接其自有基础设施网络和集群。

我将列出以下三家公司的帮助页面。

    • Google GKE … GKE Ingress

AWS EKS … AWS Network Load Balancer (NLB), Classic Load Balancer (CLB)

Azure AKS … パブリック Standard Load Balancer

这个问题是有一定程度的情理的，因为LB的设置是位于集群最外层的服务终点，而不同的云服务提供商对此有严格的规定。但在使用k8s进行运营时，这个问题却意外地成为一个麻烦，需要注意。因为不同云服务提供商对服务和LB的配置要求非常严格，这样一来，根据Pod的配置，可能完全无法将应用迁移至其他云服务商。对于多云集群管理来说，这是一个相当麻烦的问题。

负载均衡器 (LB)

我在比较语言领域找到了以下博客文章，附上链接和比较表。感谢您。

    Comparing Open Source k8s Load Balancers

本文对MetalLB、PureLB和Porter进行了比较。

MetalLBPureLBPorterIPAMintegratedintegrated & externalintegratedUses Linux network SubsystemnoyesnoLocal AddressesyesyesincompleteRouted addressesyesyesyesProtocol SupportBGPany (BGP,OSPF,ISIS,RIP)BGP partialIPv4 & IPv6noyesnoIntegration with routed CNIDifficulteasypossibleConfig using CRDnoyesyesRedundancy & failovergoodgoodpoor

由于Porter是2020年夏天加入CNCF的新项目，所以我们对它的期望还很高。

入口控制器

Kubernetes 标准的 Ingress 控制器有两个选项：GCE 和 nginx。

以下是追加的Ingress控制器的相当多的列表，转载自官方网站。

    Kubernetes: Ingressコントローラー

AKS Application Gateway Ingress Controller是一个使用Azure Application Gateway在AKS集群中执行Ingress的Ingress控制器。

Ambassador API Gateway是基于Envoy的Ingress控制器，由Datawire提供社区版和商业版的支持。

在AppsCode Inc.，我们提供最广泛使用的基于HAProxy的Ingress控制器Voyager的支持和维护。

AWS ALB Ingress Controller使用AWS Application Load Balancer启用Ingress。

Contour是由VMware提供和支持的基于Envoy的Ingress控制器。

Citrix为裸机和云部署提供了硬件(MPX)、虚拟化(VPX)和自由容器化(CPX) ADC的Ingress控制器。

F5 Networks提供了对于Kubernetes的F5 BIG-IP Container Ingress Services的支持和维护。

Gloo是基于Envoy的开源Ingress控制器，通过solo.io提供企业支持并提供API Gateway功能。

HAProxy Ingress是一个高度可定制的面向HAProxy的社区驱动的Ingress控制器。

HAProxy Technologies提供了对于Kubernetes的HAProxy Ingress Controller的支持和维护，请参阅官方文档。

基于Istio的Ingress控制器可以控制Ingress流量。

Kong提供了对于Kubernetes的Kong Ingress Controller的社区版和商业版的支持和维护。

NGINX, Inc.提供了对于Kubernetes的NGINX Ingress Controller的支持和维护。

Skipper是一个为构建自定义代理而设计的库，它包括Kubernetes Ingress等服务配置的HTTP路由器和反向代理的用例。

Traefik是一个具有完整功能（Let’s Encrypt，secrets，http2，websocket）的Ingress控制器，也有Containous提供的商业支持。

这是Ingress控制器的数量。因为它同时兼具L4/L7负载均衡和反向代理的功能，所以很多方面都是不同的。
我认为可以根据您对该产品的帮助页面菜单的熟悉程度来决定。因为帮助页面不易阅读的产品就不那么好用了。尽管如此，个人而言，如果在Nginx中遇到困难，我会倾向于使用Traefik，所以我对Traefik的帮助页面很熟悉。我并没有说Traefik很容易使用。

DNS/Service Discovery/Service Mesh

DNS/服务发现/服务网格

DNS/服务发现单一的开源软件项目目前似乎只有CoreDNS一种选择。或者说，大多数情况下，服务发现和服务网格开发都作为一个整体项目进行。因此，在这里介绍了服务网格的开源软件，但是我还有一篇更值得感谢的文章，以下是链接。非常感谢。

    サービスメッシュについて調査してみた件

请查看上文的文章以了解更详细的内容。以下只提供文章中所介绍的项目列表和相关链接。

Istio是一个开源的服务网格（Service Mesh）平台。

使者

林克德

领事

CNI（容器网络接口）

CNI本身也是CNCF旗下的项目。

在此页面上列举了第三方插件。

项目 Calico – 第三层虚拟网络
Weave – 多主机 Docker 网络
Contiv Networking – 适用于各种用例的策略网络
SR-IOV
Cilium – 用于容器的 BPF 和 XDP
Infoblox – 用于容器的企业级 IP 地址管理
Multus – 多插件
Romana – 支持网络策略的第三层 CNI 插件
CNI-Genie – 通用的 CNI 网络插件
Nuage CNI – Nuage Networks SDN 插件，用于支持 Kubernetes 的网络策略
Silk – 专为 Cloud Foundry 设计的 CNI 插件
Linen – 适用于使用 Open vSwitch 进行叠加网络的 CNI 插件，适用于 SDN/OpenFlow 网络环境
Vhostuser – 数据平面网络插件 – 支持 OVS-DPDK 和 VPP
Amazon ECS CNI 插件 – 一组 CNI 插件，用于配置使用 Amazon EC2 弹性网络接口 (ENI) 的容器
Bonding CNI – 链接聚合插件，用于故障转移和高可用网络
ovn-kubernetes – 构建在 Open vSwitch (OVS) 和 Open Virtual Networking (OVN) 上的容器网络插件，支持 Linux 和 Windows

Juniper Contrail / TungstenFabric – 提供叠加 SDN 解决方案，提供多云网络、混合云网络、同时支持叠加-底层网络、网络策略执行、网络隔离、服务链和灵活负载均衡
Knitter – 支持 Kubernetes 的 CNI 插件，支持多种网络
DANM – 用于在 Kubernetes 上运行的电信工作负载的符合 CNI 标准的网络解决方案
VMware NSX – 可实现自动化的 NSX L2/L3 网络和 L4/L7 负载均衡；在 pod、节点和集群级别上进行网络隔离；以及为您的 Kubernetes 集群提供零信任安全策略的 CNI 插件。
cni-route-override – 覆盖路由信息的元 CNI 插件
Terway – 基于阿里巴巴云 VPC/ECS 网络产品的一组 CNI 插件
Cisco ACI CNI – 用于本地和云端容器网络的统一策略和安全模型的 CNI 插件。
Kube-OVN – 基于 OVN/OVS 的 CNI 插件，提供子网、静态 IP、ACL、QoS 等高级功能。
Project Antrea – 基于 Open vSwitch 的 Kubernetes CNI
OVN4NFV-K8S-Plugin – 基于 OVN 的 CNI 控制器插件，提供云原生的服务功能链 (SFC)、多个 OVN 叠加网络
Azure CNI – 一种原生扩展 Azure 虚拟网络到容器的 CNI 插件。

不，挺多的呢… 在这里我找到了一张比较老旧的CNI幻灯片，以下是介绍。

    Kubernetes CNI 結局どれを使えばいいのか / Kubernetes CNI Which Should We Choose

在这里，我们正在比较 flannel、Cilium、Calico、Contiv、TungstenFabric 这五个选项。

嗯，虽然有点旧了，但希望能对你有所帮助。

那么，这次就先告辞了。

✖
广告
将在 10 秒后关闭
bannerAds