k8s网络之设计与实现

k8s网络主题系列:

一、k8s网络之设计与实现

二、k8s网络之Flannel网络

三、k8s网络之Calico网络

K8s网络设计与实现是在学习k8s网络过程中总结的内容。在学习k8s网络各种插件之前我觉得有必要先搞清楚其设计思路是怎样的,在知道其规范的情况下肯定能跟深刻理解k8s网络的各种插件。就像拥有指南针的船,才不会跑偏。

一、K8s网络设计

1.每个Pod都拥有一个独立IP地址,Pod内所有容器共享一个网络命名空间

2.集群内所有Pod都在一个直接连通的扁平网络中,可通过IP直接访问

(1) 所有容器之间无需NAT就可以直接互相访问

(2) 所有Node和所有容器之间无需NAT就可以直接互相访问

(3) 容器自己看到的IP跟其他容器看到的一样

二、K8s网络要求

K8s对网络的要求总的来讲主要有两个最基本的要求,分别是:

  1. 要能够为每一个Node上的Pod分配互相不冲突的IP地址;
  2. 要所有Pod之间能够互相访问;

三、K8s网络规范

CNI是由CoreOS提出的一个容器网络规范。已采纳规范的包括Apache Mesos, Cloud Foundry, Kubernetes, Kurma 和 rkt。另外 Contiv Networking, Project Calico 和 Weave这些项目也为CNI提供插件。

CNI 的规范比较小巧。它规定了一个容器runtime和网络插件之间的简单的契约。这个契约通过JSON的语法定义了CNI插件所需要提供的输入和输出。一个容器可以被加入到被不同插件所驱动的多个网络之中。一个网络有自己对应的插件和唯一的名称。CNI 插件需要提供两个命令:一个用来将网络接口加入到指定网络,另一个用来将其移除。这两个接口分别在容器被创建和销毁的时候被调用。

容器runtime首先需要分配一个网络命名空间以及一个容器ID。然后连同一些CNI配置参数传给网络驱动。接着网络驱动会将该容器连接到网络并将分配的IP地址以JSON的格式返回给容器runtime。

四、K8s网络实现

隧道方案

隧道方案在IaaS层的网络中应用也比较多,将pod分布在一个大二层的网络规模下。网络拓扑简单,但随着节点规模的增长复杂度会提升。

Weave:UDP广播,本机建立新的BR,通过PCAP互通

Open vSwitch(OVS):基于VxLan和GRE协议,但是性能方面损失比较严重

Flannel:UDP广播,VxLan

Racher:IPsec

路由方案

路由方案一般是从3层或者2层实现隔离和跨主机容器互通的,出了问题也很容易排查。

Calico:基于BGP协议的路由方案,支持很细致的ACL控制,对混合云亲和度比较高。

Macvlan:从逻辑和Kernel层来看隔离性和性能最优的方案,基于二层隔离,所以需要二层路由器支持,大多数云服务商不支持,所以混合云上比较难以实现。

五、K8s Pod的网络创建流程

1.每个Pod除了创建时指定的容器外,都有一个kubelet启动时指定的基础容器

2.kubelet创建基础容器,生成network namespace

3.kubelet调用网络CNI driver,由它根据配置调用具体的CNI 插件

4.CNI 插件给基础容器配置网络

5.Pod 中其他的容器共享使用基础容器的网络

 

以上内容主要来自博客文章。

原文地址:https://www.cnblogs.com/goldsunshine/p/10740090.html

时间: 2024-10-04 07:08:22

k8s网络之设计与实现的相关文章

k8s网络之Flannel网络

k8s网络主题系列: 一.k8s网络之设计与实现 二.k8s网络之Flannel网络 三.k8s网络之Calico网络 简介 Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务,简单来说,它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址. 在默认的Docker配置中,每个节点上的Docker服务会分别负责所在节点容器的IP分配.这样导致的一个问题是,不同节点上容器可能获得相同的内外IP地址.并使这些容器之间能够之间通过IP地址相互找

网络协议设计

一篇文章: 要解决的重点在于1 防止发送的消息丢失(1)接收方收到则应答(2)发送发发送后,过一段时间未收到应答,则重发:重发多次仍无应答,则退出2 防止应答丢失(1)应答丢失,则发送方会重发.接收方需判断收到的消息是否重复(帧中加入序列号)3 身份确认(1)用地址确认身份4 传递效率(1)限制每条消息的大小 上面的很基础.转自:http://blog.csdn.net/ybdesire/article/details/6859582 一篇文章: 实时游戏的网络协议设计 类似于SLG这类游戏,对

【Kubernetes】K8S 网络隔离 方案

参考资料: K8S-网络隔离参考 OpenContrail is an open source network virtualization platform for the cloud. – Kube-O-Contrail – get your hands dirty with Kubernetes and OpenContrail OpenContrail is an open source network virtualization platform for the cloud. Ope

浅谈企业网络架构设计

本人工作已有10年有余,工作换了无数,从计算机的售后支持到系统集成项目经理,其间还做过几年网络技术老师.后来厌倦了上课(主要是太理论化了),转投到企业作IDC运维. 不管是在甲方还是在乙方,我们都是和网络打交道.在乙方时,每个项目,几乎都牵涉到网络架构设计.有的比较简单,有的也很复杂.但大多数情况下,都是采用老一套的方法,满足用户基本需求就ok了.很少真正深入用户企业,去探究企业实际需求和现实状况.大多都是按照自己对企业的理解,认为这样比较合理,又是站在甲方的立场,这样可以多赚点钱,或者这个设备

Java EE 架构设计——基于okhttp3 的网络框架设计

转载请注明出处:http://blog.csdn.net/smartbetter/article/details/77893903 本篇文章带大家设计一套满意业务需求.代码健壮高效(高内聚低耦合)并且可拓展的网络框架.以最新的okhttp3为基础设计出高效可靠的网络缓存.多线程文件下载等架构模块.从此不局限于使用别人的框架,而步入了设计框架,让自己可以走的更远,我觉得这才是一名合格开发者所应该具备的能力.在开发中,选择一个开源框架的标准有很多,例如学习成本.文档是否齐全.github星数量.现在

k8s网络

一.概述 k8s从Docker网络模型(NAT方式的网络模型)中独立出来形成一套新的网络模型.该网络模型的目标是:        每一个Pod都拥有一个扁平化共享网络命名空间的IP,称为PodIP,通过PodIP, Pod能够跨网络与其他物理机和Pod进行通信.一个Pod 一个IP的(IP-Per-Pod) 模型创建了一个干净.反向兼容的模型.    在该模型中,从端口分配,网络,域名解析,服务发现,负载均衡,应用配置和迁移等角度,Pod都能够被看成虚拟机或物理机,这样应用就能够平滑地从非容器环

《转》禅意设计:网络简洁设计的缘起和未来

自从苹果的设计旷世惊奇地重新回归了点.线.面这种基础视觉元素后,远在太平洋彼岸的日本,以无印良品设计风潮的兴起为标志,也掀起了一场设计简单化.生活质朴化运动.而地处北纬55度以北,寒冷严酷的北欧,不甘落后地兴起了回归人性.回归自然的设计生活方式,其中以B&O.宜家家具为典型代表. 无简洁.不设计,在20世纪末21世纪初风靡全球,形成了一股继包浩斯时代以来的最大规模的简约设计风潮. 如果说现代设计中,有一个词是所有设计师都推崇标榜的,那非“简洁”二字莫属了.正如中西方绘画最终不约而同地走向写意,世

K8S网络NAT问题分析与处理

在K8S环境中(集群环境为自建),node节点上的pod网络互联互通是采用网络插件结合etcd实现的. 默认情况下pod访问集群外部的网络(例如:访问百度)走的是对应node节点的nat规则. 最近收到研发反馈的需求,由于我们mysql这种公共服务并没有放到k8s集群内(对照生产环境使用的也是RDS这种云服务),所以从mysql的information_schema.processlist这张表查询到的客户端连接地址全部都是node节点的ip,而一个node节点上又跑了许多的微服务,这就给研发人

k8s的架构设计和节点组成

ETCd nodes:-1 etcd用于存储Kubernetes cluster中所有的pods / nodes状态的key/value信息,同时提供高可用cluster的特性,生产环境一般提供3到5个etcd nodes以保证一致性协调服务: etcd集群内部通过Raft一致性算法,类似于ZooKeeper,状态的更改需要超过半数的节点回复确认,因此即使出现脑裂网络分割,节点数较少的分组也无法自行修改状态,从而保证cluster nodes上的信息要么是最新的,要么是过去已经确认过的: 通过e