Linux的Namespace[1]机制提供了一种资源隔离的解决方案，而目前Linux内核里面实现且支持的Namespace有7种，如下表：
熟悉 Linux 技术的人都知道，容器只是利用名字空间进行隔离的进程而已，Docker 在容器实现上也是利用了 Linux 自身的技术。
自从上次我们研究 Linux 命名空间以来已经有一段时间了。我们的系列缺少了一篇，现在补上：网络命名空间。顾名思义，网络命名空间将网络设备、地址、端口、路由、防火墙规则等的使用划分在不同的盒子，基本上是在一个单独运行的内核实例中虚拟化网络。网络命名空间在 2.6.24 版进入内核，约 5 年前；大概一年后，它们才进入黄金时段。从那以后，它们似乎在很大程度上被开发人员忽略了。
起因 今天看到一个做docker开发工程师写的如何实现docker网络隔离的方案，总的来说就是找到docker容器对应的主机虚拟网卡，然后使用wondershaper或traffic control对虚拟网卡进行流量控制。这个方案还是比较简单的，不过看了下他给出的如何找容器对应的主机虚拟网卡的步骤，觉得还是过于麻烦，而且还依赖于nsenter与ethtool命令，这个感觉不太好，就想着要进行一下这个过程。 改进 因为以前看到pipework的源码，对如何操作容器网络还是比较了解的，于是写了个简单脚本完成上述
Kubernetes 中的 Service 就是一组同 label 类型 Pod 的服务抽象，为服务提供了负载均衡和反向代理能力，在集群中表示一个微服务的概念。kube-proxy 组件则是 Service 的具体实现，了解了 kube-proxy 的工作原理，才能洞悉服务之间的通信流程，再遇到网络不通时也不会一脸懵逼。
很早以前就听说过pipework，据说面对一些复杂的网络配置场景，docker自带的网络模式就有些力不从心了，很多人都在用pipework。今天终于能够抽出时间研究一下它。 docker默认支持的网络模式 除了overlay网络外，docker默认支持4种网络模式，如下： host模式，使用–net=host指定，容器和宿主机共用一个Network Namespace。 container模式，使用–net=container:NAME_or_ID指定，容器和已经存在的一个容器共享一个Network Nam
本文通过 IP 命令操作来简单介绍 network namespace 的基本概念和用法。深入了解可以看看我之前写的两篇文章 Docker 基础技术之 Linux namespace 详解 和 Docker 基础技术之 Linux namespace 源码分析。
最近遇到一个测试场景：要在一个Nginx Docker容器内进行网络联通测试。常用的网络调试工具很多，如cURL、dig、nslookup等等。而在Nginx镜像里一般不会自带这些工具，当然，可以通过Dockerfile打造属于你的“瑞士军刀”版本的Nginx镜像。其实，Docker所在的Linux主机上一般都会自带这些工具了。那么有没有一种方法，可以直接利用Linux主机上的这些命令行工具，在容器内执行相关命令呢？
PS：通过linux做的个实验跟通过docker创建的容器的是类似的，只是用linux的方式模拟了docker容器的方式。其实docker容器的原理就是围绕这linux底层的网络命名空间的原理实现的。
我们一定听过容器的基础原理，namespace做隔离，Cgroups做限制，rootfs做文件系统，容器本质上是linux的一个进程，那么为什么大多数场景下，容器不直接使用宿主机上的网络，而要是通过network namespace隔离出一组专属的网络空间呢？（容器的基础原理，可参考：https://coolshell.cn/articles/17010.html）
这个Pod IP被该Pod内的所有容器共享，并且其它所有Pod都可以路由到该Pod。你可曾注意到，你的Kubernetes节点上运行着一些"pause"容器？它们被称作“沙盒容器（sandbox containers）"，其唯一任务是保留并持有一个网络命名空间（netns），该命名空间被Pod内所有容器共享。通过这种方式，即使一个容器死掉，新的容器创建出来代替这个容器，Pod IP也不会改变。这种IP-per-pod模型的巨大优势是，Pod和底层主机不会有IP或者端口冲突。我们不用担心应用使用了什么端口。
Vagrant是一个构建和管理虚拟机的工具，使用Vagrant可以非常方便的构建、启动、关闭或者复制多个相同的虚拟机环境
使用容器总是感觉像使用魔法一样。对于那些理解底层原理的人来说容器很好用，但是对于不理解的人来说就是个噩梦。很幸运的是，我们已经研究容器技术很久了，甚至成功揭秘容器只是隔离并受限的 Linux 进程，运行容器并不需要镜像，以及另一个方面，构建镜像需要运行一些容器。
容器的本质就是一个进程，只不过对它进行了Linux Namesapce隔离，让它看不到外面的世界，用Cgroups限制了它能使用的资源，同时利用系统调用pivot_root或chroot切换了进程的根目录，把容器镜像挂载为根文件系统rootfs。rootfs中不仅有要运行的应用程序，还包含了应用的所有依赖库，以及操作系统的目录和文件。rootfs打包了应用运行的完整环境，这样就保证了在开发、测试、线上等多个场景的一致性。
此时执行ifconfig，可以明确的看到显示的IP不是主机的IP，而是这个容器的IP 172.17.0.2。如果想设置一些其它的东西，那就很开心了。
4. 有多个网口时，可以将两对网口直连，配置同网段ip，执行ping操作，验证隔离网口ip配置是否成功：
不必太纠结于当下，也不必太忧虑未来，当你经历过一些事情的时候，眼前的风景已经和从前不一样了。——村上春树
前言 上一章介绍了GNS3的使用以及OVN系统的架构，搭建了实验环境，阐述了OVN各个进程的用途、彼此之间的关系，以及产生的日志（OVN实战一之GNS3操作指南及OVN入门，http://www.sd
在上图中，父进程可以被认为是一个活动的shell会话，子进程可以被认为是在shell中运行的任何命令，例如：ls、pwd。现在，当运行新命令时，会创建一个新进程。这是由父进程通过调用函数来完成的fork。当它创建一个新的独立进程时，它将子进程的进程 ID (PID) 返回给调用该函数的父进程fork。在适当的时候，父母和孩子都可以继续执行他们的任务并终止。子PID对于父进程跟踪新创建的进程很重要。
在IPVS: How Kubernetes Services Direct Traffic to Pods一文中，作者给出了一个简单的组网(如下)来模拟kubernetes是如何使用IPVS进行通信的。
使用容器总感觉像变模式一样。对那些了解其内部原理的人来说，他是一种很好的方式；而对于那些不了解其内部原理的人来说，这是一种可怕的方式。
上一篇文章我演示了docker bridge网络模型的实验，这次我将展示如何利用Overlay 网络实现跨主机容器的通信。
一直以来，网络都是容器中令人头疼的问题。本文的主要目的是带你解决容器网络问题，让你不再对它恐惧。
Docker在安装后自动提供3种网络，可以使用docker network ls命令查看
即使是对于具备一定虚拟网络和路由知识的人来说，Kubernetes 集群的网络也是个颇为麻烦的事情。本文[1]尝试帮助读者理解 Kubernetes 网络的基础知识。初期目标是根据一个发往 Kubernetes 集群 Service 的 HTTP 请求的路线，来理解 Kubernetes 网络的复杂性。这中间会涉及到命名空间、CNI 以及 Calico。第一篇会从 Linux 网络开始，后续章节会涉及到其他主题。
本文通过docker的网络介绍容器网络的原理以及一些实践，通过实践一遍相信大家会对网络底层的原理有个更深的理解，最后给出对接ovs的教程，这对下一篇k8s对接ovn的原理理解打下一个基础。
通过上篇文章的学习，我们已经知道 Macvlan 四种模式的工作原理，其中最常用的就是 Bridge 模式，本文我们将通过实验来验证 Macvlan Bridge 模式的连通性。
本文将带大家了解 Kubernetes 的 kube-proxy 组件如何使用 iptables 将 service 流量随机发送到 Pod，目的是实现 service 所需的 iptables 规则。
Mininet作为一个轻量级的SDN仿真工具，在其系统实现架构中充分利用了Linux命名空间内核技术，其中Linux Network Namespace机制更是Mininet软件架构的基石，对网络资源
Kubernetes 集群中的网络可能会令人感到有点困惑，即便是对于拥有虚拟网络和路由实践经验的工程师来说也是如此。本系列文章将分为 4 个部分，帮助你理解基本的 Kubernetes 网络，本文属于第一部分。
对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对大众理想的懦弱回归，是随波逐流，是对内心的恐惧 ——赫尔曼·黑塞《德米安》
url:http://172.17.0.200:8500/ui/#/dc1/kv/docker/nodes/
Docker 在安装后自动提供 3 种网络，可以使用 docker network ls 命令查看
可以借助ip netns命令来完成对 Network Namespace 的各种操作。ip netns命令来自于iproute安装包，一般系统会默认安装，如果没有的话，请自行安装。
即使是对于具备一定虚拟网络和路由知识的人来说，Kubernetes 集群的网络也是个颇为麻烦的事情。本文尝试帮助读者理解 Kubernetes 网络的基础知识。初期目标是根据一个发往 Kubernetes 集群 Service 的 HTTP 请求的路线，来理解 Kubernetes 网络的复杂性。这中间会涉及到命名空间、CNI 以及 Calico。第一篇会从 Linux 网络开始，后续章节会涉及到其他主题。
如果你使用过 Docker 和 Kubernetes，那么可能应该听说过 network namespace（网络命名空间），最近在我们的 《Kubernetes 网络训练营》课程中学习到了 Linux 下面的 ip 命令的使用，本文我将演示如何使用命令通过一对 veth 接口连接不同子网中的网络命名空间的进程。
通过之前的文章，我们知道 tun 是一个网络层的设备，也被叫做点对点设备，之所以叫这个名字，是因为 tun 常常被用来做隧道通信（tunnel）。
1、先查看容器端口映射情况 [root@master ~]# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ba9b9a977c02 nginx "/docker-entrypoint.…" About a minute ago Up About
在开发Kata/remote-hypervisor(也称为peer-pods)方案时，我遇到了一个问题，即Kubernetes pod IP在工作节点上无法访问。在本博客中，我将描述Kubernetes网络故障排查过程，希望对读者有帮助。
我的回答基本上是一句废话，因为只要你知道点网络的基础知识，肯定知道这种情况要走三层路由。
但是，当我们和业务RD确认之后，发现业务容器状态正常，业务进程也正运行着。嗯，问题不简单。
对于刚接触k8s的人来说，最令人懵逼的应该就是k8s的网络了，如何访问部署在k8s的应用，service的几种类型有什么区别，各有什么使用场景，服务的负载均衡是如何实现的，与haproxy/nginx转发有什么区别，网络策略为什么不用限制serviceIP等等
我们使用 Kubernetes 时难免发生一些网络问题，往往需要进入容器的网络命名空间 (netns) 中，进行一些网络调试来定位问题，本文介绍如何进入容器的 netns。
Kubernetes网络模型设计的一个基础原则是：每个Pod都拥有一个独立的IP地址，并假定所有Pod都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个Node（宿主机）中，都要求它们可以直接通过对方的IP进行访问。设计这个原则的原因是，用户不需要额外考虑如何建立Pod之间的连接，也不需要考虑如何将容器端口映射到主机端口等问题。
在过去的几十年里，互联网发展得非常快。许多新兴技术迅速崛起，也有不少曾经的主流技术被淘汰。然而，有些技术因为其基础性和核心地位，一直在不断进步中保持着重要作用。计算机网络就是其中之一。虽然网络架构和传输协议在不断更新，但其核心概念和原理一直都在发挥着关键作用，支撑着全球的信息交换。在这些技术中，网卡作为计算机连接网络的桥梁，起到了至关重要的作用。
前面的文章讲过了几种 Linux 虚拟网络设备：tap/tun、veth-pair、bridge，它们本质上是 Linux 系统 提供的网络虚拟化解决方案，今天要讲的 macvlan 也是其中的一种，准确说这是一种网卡虚拟化的解决方案。因为 macvlan 这种技术能将 一块物理网卡虚拟成多块虚拟网卡 ，相当于物理网卡施展了 多重影分身之术 ，由一个变多个。
> 扩展 kubernetes 分为三种模式 webhook，binary 二进制，controller
本文编写于 205 天前，最后修改于 153 天前，其中某些信息可能已经过时。 1.环境：Centos7 2.运行一个容器 [root@idc ~]# docker run -it --rm --name=mynetwork --net=none centos:latest /bin/bash #--net=none：docker不对容器进行网络配置，无网络配置 #--rm：容器停止后会清空容器，对容器的设置都将被清除 #容器运行后，再克隆一个会话进行下面的步骤 3.创建容器的网络命名空间 [root@id
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
