容器是一种新的虚拟化技术,每一个容器都是一个逻辑上独立的网络环境。Linux 上提供了软件虚拟出来的二层交换机 Bridge 可以解决同一个宿主机上多个容器之间互连的问题,但这是不够的。二层交换无法解决容器和宿主机外部网络的互通。
由于路由冲突,所以要么修改docker服务的网络配置,要么停止docker服务并删除对应的路由信息。这里以停止docker服务,删除docker服务,删除对应的路由信息为例解决。
如今服务器虚拟化技术已经发展到了深水区。现在业界已经有很多公司都迁移到容器上了。我们的开发写出来的代码大概率是要运行在容器上的。因此深刻理解容器网络的工作原理非常的重要。只有这样将来遇到问题的时候才知道该如何下手处理。
计算、存储和网络是云时代的三大基础服务,作为新一代基础架构的 Kubernetes 也不例外。而这三者之中,网络又是一个最难掌握和最容易出问题的服务;本文通过对Kubernetes网络流量模型进行简单梳理,希望对初学者能够提供一定思路。先看一下kubernetes 总体模型:
Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务,简单来说,它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。
此专栏是为了“补货”一些官网没有的操作文档,大家走过路过,可以留言告诉我,哪里写的不清不楚的地方,洒家给它整明白了、
在现代微服务架构中, Service Mesh 作为基础设施层为服务间通信提供了强大支持,其中透明代理是一项关键技术,这篇文章做了一个比较细致的分析,彻底弄懂 TPROXY 透明代理/REDIRECT 的技术细节,涉及到下面这些内容:
在《21天精通IPv4 to IPv6》系列的第九天,我们将探讨在云服务和容器技术中实现IPv6的策略。本文将为你详细介绍云服务中的IPv6实施、容器与IPv6的结合,实际配置案例以及操作命令,旨在帮助读者有效地在云和容器环境中部署IPv6。这篇博客包含重要的关键词,如云计算IPv6、容器IPv6配置、云服务网络升级,确保读者能够轻松掌握在云端和容器中实现IPv4到IPv6的过渡。
今天来聊聊 Flannel,Flannel 是 Kubernetes 默认网络组件,再聊 Flannel 时,我们得先明白一个叫 CNI 东东,CNI 是什么?能有什么用?下文会做出解释。
在上一篇文章中我们概括了k8s集群网络大致包含哪些方面,包括服务在网络中的负载均衡方式(iptable和ipvs),以及underlay和overlay的组网。在这里我们介绍宿主内的容器网络,当然我们还是以docker环境为例,介绍docker宿主环境中的容器网络。
在Kubernetes中要保证容器之间网络互通,网络至关重要。而Kubernetes本身并没有自己实现容器网络,而是通过插件化的方式自由接入进来。在容器网络接入进来需要满足如下基本原则:
Kubernetes是用于大规模管理容器化应用程序出色的编排工具。但是,您可能知道,使用kubernetes并非易事,尤其是后端网络实现。我在网络中遇到了许多问题,花了我很多时间弄清楚它是如何工作的。
如果大家已经使用了 kubernetes技术,并运行了一些测试或生产的服务,可能已经能体会到 K8s 技术带来的革命性变化,如果还没有用过的小伙伴,我建议尽快入坑,毕竟这是技术趋势。
云原生(Cloud Native)可以认为是一套技术体系或生态,它包含2大部分:云(Cloud)和原生(Native)。云(Cloud)表示应用程序位于云中,而不是传统的数据中心;原生(Native)表示应用程序从设计之初即考虑到云的环境,原生为云而设计,在云上以最佳状态运行,充分利用和发挥云平台的弹性和分布式优势。
host-gw模式就是将每个Flannel子网的下一跳设置成该子网对应宿主机的IP地址,该主机会充当容器通信路径里的网关。
Kubernetes网络模型设计的一个基础原则是:每个Pod都拥有一个独立的IP地址,并假定所有Pod都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个Node(宿主机)中,都要求它们可以直接通过对方的IP进行访问。设计这个原则的原因是,用户不需要额外考虑如何建立Pod之间的连接,也不需要考虑如何将容器端口映射到主机端口等问题。
我们一定听过容器的基础原理,namespace做隔离,Cgroups做限制,rootfs做文件系统,容器本质上是linux的一个进程,那么为什么大多数场景下,容器不直接使用宿主机上的网络,而要是通过network namespace隔离出一组专属的网络空间呢?(容器的基础原理,可参考:https://coolshell.cn/articles/17010.html)
容器的跨主机通信主要有两种方式:封包模式和路由模式。上一篇文章演示了使用VXLAN协议的封包模式,这篇将介绍另一种方式,利用三层网络的路由转发实现容器的跨主机通信。
为什么要写Linux|聊聊Linux系统中的路由策略这篇文章呢,主要为了今天这篇做铺垫。
上一篇说到在k8s里使用underlay网络有一个弊端,使用了underlay网络的pod无法访问serviceIP,这一点可能通过修改修改业务应用的chart来解决,主要解决方法是:
这个Pod IP被该Pod内的所有容器共享,并且其它所有Pod都可以路由到该Pod。你可曾注意到,你的Kubernetes节点上运行着一些"pause"容器?它们被称作“沙盒容器(sandbox containers)",其唯一任务是保留并持有一个网络命名空间(netns),该命名空间被Pod内所有容器共享。通过这种方式,即使一个容器死掉,新的容器创建出来代替这个容器,Pod IP也不会改变。这种IP-per-pod模型的巨大优势是,Pod和底层主机不会有IP或者端口冲突。我们不用担心应用使用了什么端口。
刚开始接触容器集群的人会发现,与在单节点上使用容器相比,容器集群一个很复杂的领域就是网络。Kubernetes 作为容器编排领域的事实标准,对容器集群的网络进行了合理抽象,并开放了容器网络标准 CNI,供各公司根据自身应用场景和底层基础设施选用开源方案或者自行实现一套网络插件。本文主要介绍腾讯云容器平台针对私有化不同场景的一些网络方案实践。
Docker是服务于应用的,Docker网络就是解决容器中应用的网络通信问题,让容器中的应用就像在一台独立的主机上运行一般。
前面介绍Flannel的三层网络解决方案是host-gw,其实还有一个非常出名的单独的三层网络解决方案Calico,它的工作模式和host-gw基本一致,也是会在每台宿主机上添加如下格式的路由规则:
docker技术依赖于linux内核虚拟化技术的发展,对linux内核特性有很强依赖。docker用到的linux技术包括:
从ArkUI组件树层级上来看,原先由Router管理的page在页面栈管理节点stage的下面。Navigation作为导航容器组件,可以挂载在单个page节点下,也可以叠加、嵌套。Navigation管理了标题栏、内容区和工具栏,内容区用于显示用户自定义页面的内容,并支持页面的路由能力。Navigation的这种设计上有如下优势:
Calico 是一套开源的网络和网络安全方案,用于容器、虚拟机、宿主机之前的网络连接,可以用在kubernetes、OpenShift、DockerEE、OpenStrack等PaaS或IaaS平台上。
在上一篇文章中我们结合实际例子来查看了docker宿主环境中的容器网络,在这里我们主要介绍集群内的负载均衡。对于k8s集群中的服务是需要相互访问的,一般我们都会为之创建相应的service,对于集群内部的service类型我们一般设置成cluster ip。对于一个cluster ip后面会关联多个endpoints,也就是实际的pod。对于cluster ip的访问,也就是实现了对cluster ip关联的多个endpoints访问。关于cluster ip和endpoints的流量负载均衡,一般有iptable方式和ipvs方式,在以前文章里有所介绍。这里我们主要以实际例子来介绍iptable的实现方式。另外cluster ip是虚拟ip,言外之意就是这个ip没有和任何device绑定,所以当你对这个ip进行例如ping或者traceroute命令的时候是不会得到应答的。
Docker的技术依赖于Linux内核的虚拟化技术的发展,Docker使用到的网络技术有Network Namespace、Veth设备对、Iptables/Netfilter、网桥、路由等。接下来,我将以Docker容器网络实现的基础技术来分别阐述,在到真正的容器篇章节之前,能形成一个稳固的基础知识网。
Calico 是一个纯三层的数据中心网络方案,而且无缝集成像 OpenStack 这种 Iaas 云架构,能够提供可控的 VM、容器、裸机之间的 IP 通信。为什么说它是纯三层呢?因为所有的数据包都是通过路由的形式找到对应的主机和容器的,然后通过 BGP 协议来将所有路由同步到所有的机器或数据中心,从而完成整个网络的互联。
之前我们解决了跨主机间容器间通信的问题,但是这也只能说我们铺好了路,村里通路了,但是其实作为 k8s 来说,还有好多其他的问题等待着我们解决。今天我们就通过这些问题来看看 k8s 的 CNI 的设计。CNI 到底究竟是个什么东西,到底是不是和你想的一样那么困难。
问题:Pod是K8S最小调度单元,一个Pod由一个容器或多个容器组成,当多个容器时,怎么都用这一个Pod IP?
接上文,容器内web程序一般会绑定到http://0.0.0.0:{某监听端口}或http://+:{某监听端口},以确保使用容器IP可以访问到web应用。
我们知道docker官方并没有提供多主机的容器通信方案,单机网络的模式主要有host,container,brige,none。
分布式系统中的可靠性和一致性是无法同时保证的,因为我们必须允许网络错误的发生。tair 采用复制技术来提高可靠性,并且为了提高效率做了一些优化。事实上在没有错误发生的时候,tair 提供的是一种强一致性,但是在有data server发生故障的时候,客户有可能在一定时间窗口内读不到最新的数据,甚至发生最新数据丢失的情况。
上篇文章介绍了容器网络的单主机网络,本文将进一步介绍多主机网络,也就是跨主机的网络。总结下来,多主机网络解决方案包括但不限于以下几种:overlay、macvlan、flannel、weave、cacico 等,下面将分别一一介绍这几种网络, PS:本文仅从原理上对几种网络进行简单的对比总结,不涉及太多的细节。 overlay 俗称隧道网络,它是基于 VxLAN 协议来将二层数据包封装到 UDP 中进行传输的,目的是扩展二层网段,因为 VLAN 使用 12bit 标记 VLAN ID,最多支持 4094 个
k8s的网络模型假定了所有的Pod都在一个可以直接连通的扁平的网络空间中, 这在GCE(Google Compute Engine)里面是线程的网络模型, Kubernetes假定这个网络已经存在. 而在私有云里搭建Kubernetes集群, 就不能假定这个网络已经存在了. 我们需要自己实现这个网络假设, 将不同节点上的Docker容器之间的互相访问先打通, 然后运行Kubernetes.
在文章《特洛伊木马-图解VXLAN容器网络通信方案》里,二哥画了下面这张鸟瞰大图。它把基于Flannel VXLAN模式实现的K8s Overlay网络模型所需要的各类网路设备放在了一起,主要突出的是这些设备之间的数据流向。但那篇文章有些许缺点(凡尔赛一下):
Docker官方推荐我们通过端口映射的方式把Docker容器的服务提供给宿主机或者局域网其他容器使用。一般过程是:
大家好,我是二哥。今天这期是一篇关于VPC和三种K8s网络模型的汇总性文章。也是春节前最后一篇文章,发完二哥就准备进入过年模式了。提前祝大家虎年虎虎生威,万事如意。
Calico 作为一种常用的 Kubernetes 网络插件,使用 BGP 协议对各节点的容器网络进行路由交换。本文是《Calico BGP 功能介绍》系列的第一篇,介绍 Calico 所使用的 BGP 软件路由器——BIRD。
容器的本质就是一个进程,只不过对它进行了Linux Namesapce隔离,让它看不到外面的世界,用Cgroups限制了它能使用的资源,同时利用系统调用pivot_root或chroot切换了进程的根目录,把容器镜像挂载为根文件系统rootfs。rootfs中不仅有要运行的应用程序,还包含了应用的所有依赖库,以及操作系统的目录和文件。rootfs打包了应用运行的完整环境,这样就保证了在开发、测试、线上等多个场景的一致性。
云上越来越多业务部署在容器环境,腾讯云容器环境TKE如何现有网络互通呢?最近和Z客户容器新网段和现有网络集成案例进行小结,让云上用户更好的TKE网络集成各种姿势。
Vue Router是Vue.js官方的路由管理器。路由就是一个路径,当我们访问指定路径时就会跳转到指定页面。我们项目的路由都是在src/router/index.js文件中定义的,举个例子,比如我们的商品列表页面路由定义如下。
路由是沟通任何双边关系的基础,比如现实世界中的邮路,网络世界中的路由,都是用来连接任何需要联系的双方实体。
领取专属 10元无门槛券
手把手带您无忧上云