从零开始的云计算生活——第五十五天，黑云压城，kubernetes模块之网络组件和CoreDNS组件

apiVersion: v1
kind: Pod
metadata:
  name: flannel
  namespace: kube-system
spec:
  containers:
  - name: flannel
    image: quay.io/coreos/flannel:v0.14.0
    args: [ "--ip-masq", "--kube-subnet-mgr=kube-subnet" ]

使用场景： Flannel适合用于小型集群和开发环境。

例子： 假设一个小型开发团队正在开发一个Web应用，使用Flannel可以快速配置一个K8s集群，使得开发人员能够专注于编码，而无需担心网络设置。

2. Calico

Calico 是一种更复杂的网络插件，它不仅提供覆盖网络功能，还实现了网络策略和安全功能。

实现原理： Calico使用BGP（边界网关协议）来动态路由流量。它允许每个Pod有一个唯一的IP地址，并可以根据用户定义的网络策略控制流量。

YAML示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-access
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: backend

使用场景： 适合需要严格网络安全控制的生产环境。

例子： 假设一家医院的应用程序，需要确保患者数据的安全。运维团队可以使用Calico设置网络策略，限制只有特定的服务能够访问敏感数据，确保数据的隐私和安全。配置示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
  namespace: my-namespace
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

在这个例子中，只有app=backend标签的Pod可以访问app=frontend标签的Pod。

3. Weave Net

Weave Net 是另一个流行的K8s网络插件，提供简单的安装和良好的可视化功能。

实现原理： Weave Net使用Overlay Network技术，通过在每个节点上创建一个虚拟网络，并通过加密和可视化工具来增强网络安全性和监控。

YAML示例：

apiVersion: v1
kind: Pod
metadata:
  name: weave
  namespace: kube-system
spec:
  containers:
  - name: weave
    image: weaveworks/weave-kube:latest

使用场景： 适合需要高可用性和可扩展性的场景。

例子： 一家在线商店，随着用户的增加，流量不断增长。使用Weave Net，开发者可以轻松地扩展服务并保持网络连接稳定。可以通过Weave提供的命令行工具监控网络状态：

weave status

Ingress的使用

Ingress 是K8s中用于管理外部访问集群服务的一种API对象。它提供了HTTP和HTTPS路由到服务的能力。

Ingress的实现原理

Ingress通过一个或多个Ingress Controller（控制器）来工作，这些控制器负责接收外部请求并将其路由到相应的服务。Ingress Controller通常运行在集群内部，并使用负载均衡、SSL终止等技术来处理流量。

配套使用：Ingress通常与LoadBalancer服务类型和DNS服务一起使用。LoadBalancer服务为Ingress Controller提供一个外部IP地址，而DNS可以将域名解析到这个IP地址。

Ingress的YAML示例

以下是一个简单的Ingress配置示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

使用场景

Ingress适合需要通过域名访问多个服务的情况。

例子：假设你有多个微服务，如用户服务和订单服务，你可以使用Ingress将所有流量路由到这些服务，而不需要在每个服务上暴露一个外部IP。用户可以通过myapp.example.com来访问这些服务，而Ingress Controller会根据配置将请求转发到相应的服务。

查看所用网络组件

要查看K8s集群中使用的网络组件，可以使用以下命令：

kubectl get pods -n kube-system

这将列出在kube-system命名空间中运行的所有Pod，你可以查找与网络相关的Pod（如Flannel、Calico等）以确认所用的网络插件。

不单独配置网络组件的影响

如果不单独配置网络组件，K8s集群仍然可以正常运行，但可能会面临一些影响和限制：

默认网络模式： 使用K8s默认的网络配置可能不支持高级功能，如网络策略、流量监控等。这可能会导致安全性降低，尤其是在生产环境中。

性能问题： 默认网络模式可能无法满足高负载或高可用性需求，影响应用的性能。

可扩展性： 在缺少合适网络插件的情况下，集群的可扩展性和灵活性可能受到限制。

配置网络组件的好处

安全性： 网络插件（如Calico）允许实现细粒度的网络策略，从而提高集群的安全性。

性能优化： 专业的网络插件提供了更高的性能和更低的延迟，适合处理高负载的应用。

可视化和监控： 一些网络组件提供流量监控和可视化工具，便于运维团队了解流量状况和网络健康。

功能丰富： 使用专用网络插件可以访问更丰富的功能，如负载均衡、故障恢复和流量控制。

类似组件

除了Ingress之外，还有一些其他组件也可以用于处理K8s中的外部访问：

1. Service

K8s的Service是一个基本的资源，用于定义如何访问一组Pod。Service可以创建不同类型的访问方式，包括ClusterIP（集群内部访问）、NodePort（节点IP访问）和LoadBalancer（负载均衡器）。

使用场景： Service通常用于需要直接访问某个Pod或服务的情况。

2. API Gateway

API Gateway是一个更高级的解决方案，通常用于微服务架构中。它可以提供更多的功能，如请求路由、负载均衡、安全认证和API版本管理。

使用场景： 适合大型微服务架构，尤其是需要多种功能集成的场景。

选择合适的网络插件和Ingress配置

在选择K8s网络插件和Ingress配置时，需要考虑几个因素：

集群规模： 小型集群可以选择Flannel，而大型或复杂的集群可能需要Calico或Weave Net。

安全需求： 如果你的应用对网络安全有较高要求，Calico是一个不错的选择。

外部访问方式： 根据应用的外部访问需求选择Ingress或API Gateway。

网络性能： 不同的网络插件在性能上有所不同，建议在正式环境前进行测试。

总结

理解 Kubernetes 的网络架构及其插件是成功使用K8s的关键。

Flannel 适合小型集群和开发环境；

Calico 适合需要严格网络安全控制的生产环境；

Weave Net 适合需要高可用性和可扩展性的场景。

Ingress 适合需要通过域名访问多个服务的情况。

三. 网络组件 Calico

1. calico 概述

1.1、calico 介绍

Calico 是一套开源的网络和网络安全方案，用于容器、虚拟机、宿主机之前的网络连接，可以用在kubernetes、OpenShift（红帽的容器编排工具）、DockerEE、OpenStack等PaaS或IaaS平台上。

1.2、calico 的优点

endpoints组成的网络是单纯的三层网络，报文的流向完全通过路由规则控制，没有overlay等额外开销；
calico的endpoint可以漂移，并且实现了acl。

1.3、calico的缺点

路由的数目与容器数目相同，非常容易超过路由器、三层交换、甚至node的处理能力，从而限制了整个网络的扩张；
calico的每个node上会设置大量（海量)的iptables规则、路由；运维、排障难度大；
calico的原理决定了它不可能支持VPC，容器只能从calico设置的网段中获取ip；
calico目前的实现没有流量控制的功能，会出现少数容器抢占node多数带宽的情况；
calico的网络规模受到BGP网络规模的限制。

1.4、calico 优势

更优的资源利用：二层网络通讯需要依赖广播消息机制，广播消息的开销与host的数量成指数级增长，calico使用的三层路由方法，则完全抑制了二层广播，减少了资源开销。另外二层网络使用VLAN隔离技术，天生有4096个规格的限制，即便可以使用vxlan解决，单vxlan又带来了隧道开销的新问题，而calico不使用VLAN或者vxlan，资源利用率更高；
可扩展性：Calico使用与Internet类似的方案，Internet的网络比任何数据中心都大，Calico同样天然具有可扩展性；
更简单的容器调试：没有隧道，workloads之间的路径更短更简单，配置更少，在host上使用容器进行debug调试；
更少依赖：Calico仅依赖三层路由可达；
可适配性：较少的依赖使它能适配所有的VM、Container、白盒（程序源代码）或者混合环境场景；

2. Calico结构组成

Calico不使用重叠网络比如flannel和libnetwork重叠网络驱动，它是一个纯三层的方法，使用虚拟路由代替虚拟交换，每一台虚拟路由通过BGP协议传播可达信息（路由）到其他数据中心；Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息向整个Calico网络内传播——小规模部署可以直接互联，大规模下可通过指定的BGP route reflector来完成。

2.1 架构

Felix：calico的核心组件，运行在每个节点上。主要的功能有接口管理、路由规则、ACL规则和状态报告
- 接口管理：Felix为内核编写一些接口信息，以便让内核能正确的处理主机endpoint的流量。特别是主机之间的ARP请求和处理ip转发。
- 路由规则：Felix负责主机之间路由信息写到linux内核的FIB（Forwarding Information Base）转发信息库，保证数据包可以在主机之间相互转发。

ACL规则：Felix负责将ACL策略写入到linux内核中，保证主机endpoint的为有效流量不能绕过calico的安全措施。

状态报告：Felix负责提供关于网络健康状况的数据。特别是，它报告配置主机时出现的错误和问题。这些数据被写入etcd，使其对网络的其他组件和操作人员可见。

Etcd：保证数据一致性的数据库，存储集群中节点的所有路由信息。为保证数据的可靠和容错建议至少三个以上etcd节点。
Orchestrator plugin：协调器插件负责允许kubernetes（容器）或OpenStack（虚拟机）等原生云平台方便管理Calico，可以通过各自的API来配置Calico网络实现无缝集成。如kubernetes的cni网络插件。
Bird：BGP客户端，Calico在每个节点上的都会部署一个BGP客户端，它的作用是将Felix的路由信息读入内核，并通过BGP协议在集群中分发。当Felix将路由插入到Linux内核FIB中时，BGP客户端将获取这些路由并将它们分发到部署中的其他节点。这可以确保在部署时有效地路由流量。
BGP Router Reflector：大型网络仅仅使用 BGP client 形成 mesh 全网互联的方案就会导致规模限制，所有节点需要 N^2 个连接，为了解决这个规模问题，可以采用 BGP 的 Router Reflector 的方法，使所有 BGP Client 仅与特定 RR 节点互联并做路由同步，从而大大减少连接数。
Calicoctl： calico 命令行管理工具。

2.2 名词解释

名词	作用
endpoint	接入到calico网络中的网卡称为endpoint

最低0.47元/天解锁文章