【云原生Kubernetes】二进制搭建Kubernetes集群(中)——部署node节点(3)

简介: 上一篇中已部署了etcd分布式数据库、master01节点,本文将部署Kubernetes集群中的 worker node 节点和 CNI 网络插件。

K8S 中 Pod 网络通信:

(1)Pod 内容器与容器之间的通信

在同一个 Pod 内的容器(Pod 内的容器是不会跨宿主机的)共享同一个网络命令空间,相当于它们在同一台机器上一样,可以用 localhost 地址访问彼此的端口。

(2)同一个 Node 内 Pod 之间的通信

每个 Pod 都有一个真实的全局 IP 地址,同一个 Node 内的不同 Pod 之间可以直接采用对方 Pod 的 IP 地址进行通信,Pod1 与 Pod2 都是通过 Veth 连接到同一个 docker0 网桥,网段相同,所以它们之间可以直接通信。

(3)不同 Node 上 Pod 之间的通信

Pod 地址与 docker0 在同一网段,docker0 网段与宿主机网卡是两个不同的网段,且不同 Node 之间的通信只能通过宿主机的物理网卡进行。

要想实现不同 Node 上 Pod 之间的通信,就必须想办法通过主机的物理网卡 IP 地址进行寻址和通信。因此要满足两个条件:Pod 的 IP 不能冲突;将 Pod 的 IP 和所在的 Node 的 IP 关联起来,通过这个关联让不同 Node 上 Pod 之间直接通过内网 IP 地址通信。

Overlay Network:

叠加网络,在二层或者三层基础网络上叠加的一种虚拟网络技术模式,该网络中的主机通过虚拟链路隧道连接起来(类似于VPN)。

VXLAN:

将源数据包封装到UDP中,并使用基础网络的IP/MAC作为外层报文头进行封装,然后在以太网上传输,到达目的地后由隧道端点解封装并将数据发送给目标地址。

5.2 Flannel 插件

Flannel 的功能是让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟 IP 地址。

Flannel 是 Overlay 网络的一种,也是将 TCP 源数据包封装在另一种网络包里面进行路由转发和通信,目前支持 udp、vxlan、 host-GW 3种数据转发方式。

  • UDP(默认方式,基于应用转发,配置简单,性能最差)
  • VXLAN(基于内核转发)
  • Host-gw(性能最好、配置麻烦)

5.2.1 Flannel UDP 模式(端口8285)

udp模式的工作原理:(基于应用进行转发,Flannel提供路由表,Flannel封装、解封装)

数据从 node01 上 Pod 的源容器中发出后,经由所在主机的 docker0 虚拟网卡转发到 flannel.1 虚拟网卡,flanneld 服务监听在 flannel.1 虚拟网卡的另外一端。

Flannel 通过 Etcd 服务维护了一张节点间的路由表。源主机 node01 的 flanneld 服务将原本的数据内容封装到 UDP 中后根据自己的路由表通过物理网卡投递给目的节点 node02 的 flanneld 服务,数据到达以后被解包,然后直接进入目的节点的 flannel.1 虚拟网卡,之后被转发到目的主机的 docker0 虚拟网卡,最后就像本机容器通信一样由 docker0 转发到目标容器。

网络异常,图片无法展示
|


网络异常,图片无法展示
|


ETCD 之 Flannel 提供说明:

  • 存储管理Flannel可分配的IP地址段资源
  • 监控 ETCD 中每个 Pod 的实际地址,并在内存中建立维护 Pod 节点路由表

5.2.2 vxlan 模式(端口4789)

vxlan 是一种overlay(虚拟隧道通信)技术,通过三层网络搭建虚拟的二层网络,跟 udp 模式具体实现不太一样:

(1)udp模式是在用户态实现的,数据会先经过tun网卡,到应用程序,应用程序再做隧道封装,再进一次内核协议栈,而vxlan是在内核当中实现的,只经过一次协议栈,在协议栈内就把vxlan包组装好。

(2)udp模式的tun网卡是三层转发,使用tun是在物理网络之上构建三层网络,属于ip in udp,vxlan模式是二层实现, overlay是二层帧,属于mac in udp。

(3)vxlan由于采用mac in udp的方式,所以实现起来会涉及mac地址学习,arp广播等二层知识,udp模式主要关注路由

Flannel VXLAN模式跨主机的工作原理:(Flannel提供路由表,由内核封装、解封装)

1、数据帧从主机A上Pod的源容器中发出后,经由所在主机的docker0/cni0 网络接口转发到flannel.1 接口

2、flannel.1 收到数据帧后添加VXLAN 头部,封装在UDP报文中

3、主机A通过物理网卡发送封包到主机B的物理网卡中

4、主机B的物理网卡再通过VXLAN 默认端口4789转发到flannel.1 接口进行解封装

5、解封装以后,内核将数据帧发送到Cni0, 最后由Cni0 发送到桥接到此接口的容器B中。

网络异常,图片无法展示
|


5.2.3 UDP和VXLAN的区别

由于UDP模式是在用户态做转发(即基于应用进行转发,由应用程序进行封装和解封装),会多一次报文隧道封装,因此性能上会比在内核态做转发的VXLAN模式差。

UDP和VXLAN的区别:

  1. UDP基于应用程序进行转发,由应用程序进行封装和解封装;VXLAN由内核进行封装和解封装,内核效率比应用程序要高,所以VXLAN比UDP要快。
  2. UDP是数据包,VXLAN是数据帧。
  3. UDP的网卡Flannel0,VXLAN的网卡Flannel.1。


5.3 Calico 插件

5.3.1 k8s组网方案对比

1)flannel 方案:

需要在每个节点_上把发向容器的数据包进行封装后,再用隧道将封装后的数据包发送到运行着目标Pod的node节点上。目标node节点再负责去掉封装,将去除封装的数据包发送到目标Pod上。数据通信性能则大受影响。

2)calico方案:

Calico不使用隧道或NAT来实现转发,而是把Host当作Internet中的路由器,使用BGP同步路由,并使用iptables来做安全访问策略,完成跨Host转发来。

采用直接路由的方式,这种方式性能损耗最低,不需要修改报文数据,但是如果网络比较复杂场景下,路由表会很复杂,对运维同事提出了较高的要求。

5.3.2 Calico的组成和工作原理

基于三层路由表进行转发,不需要封装和解封装。

Calico主要由三个部分组成:

  • Calico CNI插件:主要负责与kubernetes对接,供kubelet 调用使用。
  • Felix:负责维护宿主机上的路由规则、FIB转发信息库等。
  • BIRD:负责分发路由规则,类似路由器。
  • Confd:配置管理组件。

Calico工作原理:

  1. Calico是通过路由表来维护每个pod的通信。
  2. Calico 的CNI插件会为每个容器设置一个 veth pair设备,然后把另一端接入到宿主机网络空间,由于没有网桥,CNI插件还需要在宿主机上为每个容器的veth pair设备配置一条路由规则,用于接收传入的IP包。
  3. 有了这样的veth pair设备以后,容器发出的IP包就会通过veth pair设备到达宿主机,然后宿主机根据路由规则的下一跳地址,发送给正确的网关,然后到达目标宿主机,再到达目标容器
  4. 这些路由规则都是Felix 维护配置的,而路由信息则是Calico BIRD 组件基于BGP(动态路由协议,可以选路)分发而来。
  5. calico实际上是将集群里所有的节点都当做边界路由器来处理,他们一起组成了一个全互联的网络,彼此之间通过BGP交换路由,这些节点我们叫做BGP Peer。

网络异常,图片无法展示
|


5.4 flannel和calico对比

flannel

  • 配置方便,功能简单,是基于overlay叠加网络实现的(在原有数据包中再封装一层),由于要进行封装和解封装的过程对性能会有一定的影响,同时不具备网络策略配置能力。
  • 三种模式:UDP、 VXLAN、HOST-GW
  • 默认网段是:10.244.0.0/16

calico

  • 功能强大,基于路由表进行转发,没有封装和解封装的过程,对性能影响较小,具有网络策略配置能力,但是路由表维护起来较为复杂。
  • 模式:BGP、IPIP
  • 默认网段192 .168.0.0/16

目前比较常用的CNI网络组件是flannel和calico,flannel的功能比较简单,不具备复杂的网络策略配置能力,calico是比较出色的网络管理插件,但具备复杂网络配置能力的同时,往往意味着本身的配置比较复杂,所以相对而言,比较小而简单的集群使用flannel,考虑到日后扩容,未来网络可能需要加入更多设备,配置更多网络策略,则使用calico更好。

(flannel在封装和解封装的过程中,会有性能损耗。calico没有封装解封装过程,没有性能损耗)

总结

1、node安装步骤:

  • 准备kubeconfig文件
  • 启动kubelet,发送csr请求证书
  • 启动kube-proxy
  • 安装CNI 网络插件,实现 pod 跨主机的通信
  • 安装CoreDNS 插件,可以实现 service 名称解析到clusterIP

2、vxlan与vlan区别:

1)vxlan支持更多的二层网络

vlan使用12位bit表示vlan ID,因此最多支持2^12=4096个vlan(可用数量为4094)

vxlan使用的ID使用24位bit,最多可以支持2^24个

2)vxlan对已有的网络路径利用效率更高

vlan使用STP(spanning tree protocol)避免环路,会将一半的网络路径阻塞。

vxlan的数据包封装成UDP通过网络层传输,可以使用所有的网络路径。

3)vxlan可以防止物理交换机Mac表耗尽

vlan需要在交换机的Mac表中记录Mac物理地址。

vxlan采用隧道机制,Mac物理地址不需记录在交换机。

4)VXLAN在一定程度上可以实现逻辑网络拓扑和物理网络拓扑的解耦

VXLAN技术通过隧道技术在物理的三层网络中虚拟二层网络,处于VXL AN网络的终端无法察觉到VXL AN的通信过程,这样也就使得逻辑网络拓扑和物理网络拓扑实现了一定程度的解耦,网络拓扑的配置对于物理设备的配置的依赖程度有所降低,配置更灵活更方便。

5)VXLAN技术还具有多租户支持的特性

VLAN技术仅仅解决了二层网络广播域分割的问题,而VXL AN技术还具有多租户支持的特性,通过VXLAN分割,各个租户可以独立组网、通信,地址分配方面和多个租户之间地址冲突的问题也得到了解决。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
18天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker和Kubernetes入门
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术成为企业提升敏捷性和效率的关键。本篇文章将引导读者了解如何利用Docker进行容器化打包及部署,以及Kubernetes集群管理的基础操作,帮助初学者快速入门云原生的世界。通过实际案例分析,我们将深入探讨这些技术在现代IT架构中的应用与影响。
60 2
|
14天前
|
Kubernetes Cloud Native 开发者
云原生入门:Kubernetes的简易指南
【10月更文挑战第41天】本文将带你进入云原生的世界,特别是Kubernetes——一个强大的容器编排平台。我们将一起探索它的基本概念和操作,让你能够轻松管理和部署应用。无论你是新手还是有经验的开发者,这篇文章都能让你对Kubernetes有更深入的理解。
|
18天前
|
Kubernetes 监控 负载均衡
深入云原生:Kubernetes 集群部署与管理实践
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其弹性、可扩展性成为企业IT架构的首选。本文将引导你了解如何部署和管理一个Kubernetes集群,包括环境准备、安装步骤和日常维护技巧。我们将通过实际代码示例,探索云原生世界的秘密,并分享如何高效运用这一技术以适应快速变化的业务需求。
52 1
|
22天前
|
运维 Kubernetes Cloud Native
Kubernetes云原生架构深度解析与实践指南####
本文深入探讨了Kubernetes作为领先的云原生应用编排平台,其设计理念、核心组件及高级特性。通过剖析Kubernetes的工作原理,结合具体案例分析,为读者呈现如何在实际项目中高效部署、管理和扩展容器化应用的策略与技巧。文章还涵盖了服务发现、负载均衡、配置管理、自动化伸缩等关键议题,旨在帮助开发者和运维人员掌握利用Kubernetes构建健壮、可伸缩的云原生生态系统的能力。 ####
|
23天前
|
存储 运维 Kubernetes
云原生之旅:Kubernetes的弹性与可扩展性探索
【10月更文挑战第32天】在云计算的浪潮中,云原生技术以其独特的魅力成为开发者的新宠。本文将深入探讨Kubernetes如何通过其弹性和可扩展性,助力应用在复杂环境中稳健运行。我们将从基础架构出发,逐步揭示Kubernetes集群管理、服务发现、存储机制及自动扩缩容等核心功能,旨在为读者呈现一个全景式的云原生平台视图。
29 1
|
28天前
|
Kubernetes 负载均衡 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第27天】Kubernetes(简称K8s)是云原生应用的核心容器编排平台,提供自动化、扩展和管理容器化应用的能力。本文介绍Kubernetes的基本概念、安装配置、核心组件(如Pod和Deployment)、服务发现与负载均衡、网络配置及安全性挑战,帮助读者理解和实践Kubernetes在容器编排中的应用。
72 4
|
29天前
|
Kubernetes 监控 Cloud Native
云原生应用:Kubernetes在容器编排中的实践与挑战
【10月更文挑战第26天】随着云计算技术的发展,容器化成为现代应用部署的核心趋势。Kubernetes(K8s)作为容器编排领域的佼佼者,以其强大的可扩展性和自动化能力,为开发者提供了高效管理和部署容器化应用的平台。本文将详细介绍Kubernetes的基本概念、核心组件、实践过程及面临的挑战,帮助读者更好地理解和应用这一技术。
62 3
|
16天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
18天前
|
运维 Kubernetes Cloud Native
云原生技术:容器化与微服务架构的完美结合
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其灵活性和高效性成为企业的新宠。本文将深入探讨云原生的核心概念,包括容器化技术和微服务架构,以及它们如何共同推动现代应用的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务,揭示云原生技术的强大能力和未来潜力。
|
19天前
|
消息中间件 存储 Cloud Native
云原生架构下的数据一致性挑战与应对策略####
本文探讨了在云原生环境中,面对微服务架构的广泛应用,数据一致性问题成为系统设计的核心挑战之一。通过分析云原生环境的特点,阐述了数据不一致性的常见场景及其对业务的影响,并深入讨论了解决这些问题的策略,包括采用分布式事务、事件驱动架构、补偿机制以及利用云平台提供的托管服务等。文章旨在为开发者提供一套系统性的解决方案框架,以应对在动态、分布式的云原生应用中保持数据一致性的复杂性。 ####