Calico

Kubernetes的故障排查一直困扰众多运维团队或DevOps，除了Kubernetes本身的复杂性之外，还有Kubernetes的工作负载是动态的原因。本文将介绍1个工具可以帮助你可视化K8S的网络和流量，以提升你的故障排查效率。 本文来自 Rancher Labs 作为领先的多集群Kubernetes管理平台，Rancher使运维团队可以部署、管理和保护企业的Kubernetes集群。Rancher还为用户提供了一系列容器网络接口（CNI）选项可供选择，包括开源项目Calico（ https://www.projectcalico.org/）。Calico为Kubernetes Pod提供了原生Layer3路由功能，从而简化了网络架构，提高了网络性能，并提供了丰富的网络策略模型，可以轻松地阻止通信。因此，只有你指定的流量才能流动。 在部署Kubernetes过程一个常见的问题是获取对集群环境的可见性，以有效监控网络和安全问题并进行故障排除。可见性和故障排查（ https://www.tigera.io/tigera-products/visibility-and-troubleshooting/ ）是我们在Tigera上看到的3大Kubernetes用例之一。这在生产部署中尤其重要，因为宕机时间十分宝贵并且分布式应用很难进行故障排查。如果你是平台团队的一员

Kubernetes CNI网络最强对比：Flannel、Calico、Canal和Weave http: // dockone.io/article/8722 【编者的话】本文将在介绍技术原理和相应术语的基础上，再集中探索与详细对比目前最流行的CNI插件：Flannel、Calico、Weave和Canal，对比介绍它们的原理、使用方法、适用场景和优缺点等。 介绍 网络架构是Kubernetes中较为复杂、让很多用户头疼的方面之一。Kubernetes网络模型本身对某些特定的网络功能有一定要求，但在实现方面也具有一定的灵活性。因此，业界已有不少不同的网络方案，来满足特定的环境和要求。 CNI意为容器网络接口，它是一种标准的设计，为了让用户在容器创建或销毁时都能够更容易地配置容器网络。在本文中，我们将集中探索与对比目前最流行的CNI插件：Flannel、Calico、Weave和Canal（技术上是多个插件的组合）。这些插件既可以确保满足Kubernetes的网络要求，又能为Kubernetes集群管理员提供他们所需的某些特定的网络功能。 背景 容器网络是容器选择连接到其他容器、主机和外部网络（如Internet）的机制。容器的Runtime提供了各种网络模式，每种模式都会产生不同的体验。例如，Docker默认情况下可以为容器配置以下网络： none

Kubernetes软件网络-Weave安装和配置 本文来源， https://www.weave.works/docs/net/latest/kubernetes/kube-addon/ The following topics are discussed: Installation Upgrading Kubernetes to version 1.6 Upgrading the Daemon Sets CPU and Memory Requirements Pod Eviction Features Pod Network Network Policy Troubleshooting Troubleshooting Blocked Connections Things to watch out for Changing Configuration Options Installation Weave Net can be installed onto your CNI-enabled Kubernetes cluster with a single command: $ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')

一、 概述 随着数据中心网络技术的革新，并伴随容器的落地，如何在数据中心内部构建一个合理可用的网络架构，以满足不同形态的业务部署模式，成为一个网络人员越来越需要注重和考虑的方向。 二、 业务背景 在互联网公司的数据中心，通常你会越来越多的看到容器(k8s)作为业务/服务的载体，各业务/服务之间(pod间)彼此调用，以下从pod间调用、容器网络选型、容器网络架构、网络隔离几个方面进行阐述。 三、 pod间调用 同一node内pod间调用 pod间通过容器网络纯内部交互，这时外部网络无感知。 不通node的pod间调用 pod间需要经过容器网络→外部网络进行交互，交互过程可提前将pod ip或cluster ip暴露到外网，具体依据业务需求和网络模型而定。 四、 容器网络选型 容器网络选型通常参照以下几点： 业务实现方式； 网络资源调配； 网络扩展及灵活性； 对底层物理网络的依赖度； 网络资源的收放要求； 开源容器网络组件按照网络覆盖类型大致可分为：overlay和underlay，underlay相比overlay在传输效率、部署实现及维护等方面更有优势( 详细的各种容器网络组件横向比较，可自行查询学习，此处不详细展开 )。 以calico为例，作为underlay的容器网络解决方案，依靠动态路由协议bgp实现网络互通，并通过原生的network policy解决容器间网络隔离。

作者 | 溪恒 阿里巴巴高级技术专家 本文整理自《CNCF x Alibaba 云原生技术公开课》第 26 讲， 点击直达课程页面 。 关注“阿里巴巴云原生”公众号，回复关键词**“入门”**，即可下载从零入门 K8s 系列文章 PPT。 导读 ：网络架构是 K8s 中较为复杂的方面之一。K8s 网络模型本身对某些特定的网络功能有着一定的要求，因此，业界已经有了不少的网络方案来满足特定的环境和要求。CNI 意为容器网络的 API 接口，为了让用户在容器创建或销毁时都能够更容易地配置容器网络。在本文中，作者将带领大家理解典型网络插件地工作原理、掌握 CNI 插件的使用。 一、CNI 是什么 首先我们介绍一下什么是 CNI，它的全称是 Container Network Interface，即容器网络的 API 接口。 它是 K8s 中标准的一个调用网络实现的接口。Kubelet 通过这个标准的 API 来调用不同的网络插件以实现不同的网络配置方式，实现了这个接口的就是 CNI 插件，它实现了一系列的 CNI API 接口。常见的 CNI 插件包括 Calico、flannel、Terway、Weave Net 以及 Contiv。 二、Kubernetes 中如何使用 CNI K8s 通过 CNI 配置文件来决定使用什么 CNI。 基本的使用方法为： 首先在每个结点上配置 CNI

作者 | 阿里巴巴高级技术专家 叶磊 一、Kubernetes 基本网络模型 本文来介绍一下 Kubernetes 对网络模型的一些想法。大家知道 Kubernetes 对于网络具体实现方案，没有什么限制，也没有给出特别好的参考案例。Kubernetes 对一个容器网络是否合格做出了限制，也就是 Kubernetes 的容器网络模型。可以把它归结为约法三章和四大目标。 约法三章的意思是：在评价一个容器网络或者设计容器网络的时候，它的准入条件。它需要满足哪三条？ 才能认为它是一个合格的网络方案。 四大目标意思是在设计这个网络的拓扑，设计网络的具体功能的实现的时候，要去想清楚，能不能达成连通性等这几大指标。 约法三章 先来看下约法三章： 第一条：任意两个 pod 之间其实是可以直接通信的，无需经过显式地使用 NAT 来接收数据和地址的转换； 第二条：node 与 pod 之间是可以直接通信的，无需使用明显的地址转换； 第三条：pod 看到自己的 IP 跟别人看见它所用的IP是一样的，中间不能经过转换。 后文中会讲一下我个人的理解，为什么 Kubernetes 对容器网络会有一些看起来武断的模型和要求。 四大目标 四大目标其实是在设计一个 K8s 的系统为外部世界提供服务的时候，从网络的角度要想清楚，外部世界如何一步一步连接到容器内部的应用？ **外部世界和 service

Kubernetes无疑是当前最火热的容器编排工具，网络是kubernetes中非常重要的一环， 本文主要介绍一些相应的网络原理及术语，以及kubernetes中的网络方案和对比。 Kubernetes本身并不提供网络功能，只是把网络接口开放出来，通过插件的形式实现。为了满足不同的网络功能及需求，使容器在创建或销毁时能够容易地配置容器网络， CNI（Container Network Interface） 应运而生， CNI旨在定义运行时和插件之间的接口，在kubernetes中，CNI连接kubelet和网络插件来为容器配置对应的网络设置。 1 背景 容器网络是容器选择连接到其他容器、主机和外部网络的机制。在kubernetes网络模型设计中，往往需要每个Pod都拥有一个独立的IP地址，而且假定所有的pod都在一个可以直接连通的、扁平的网络空间中。用户不需要额外考虑如何建立Pod之间的连接，也不需要考虑将容器端口映射到主机端口等问题。所有节点都可在不用NAT的方式下同所有容器通讯，容器的地址和别人看到的地址是同一个地址。 2 技术术语 IPAM： IP地址管理；这个IP地址管理并不是容器所特有的，传统的网络比如说DHCP其实也是一种IPAM，到了容器时代我们谈IPAM，主流的两种方法：基于CIDR的IP地址段分配地或者精确为每一个容器分配IP。但总之一旦形成一个容器主机集群之后

参考 https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/ 使用阿里源： cat << EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg EOF # 将 SELinux 设置为 permissive 模式（相当于将其禁用） setenforce 0 sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config yum install -y kubelet kubeadm kubectl -

Kubernetes网络模型本身对某些特定的网络功能有一定要求，但在实现方面也具有一定的灵活性。业界已经有不少不同的网络方案，来满足特定的环境和要求。 CNI（container network interface）是容器网络接口，它是一种标准设计和库，为了让用户在容器创建或者销毁时都能够更容易的配置容器网络。 目前比较流行的CNI插件：Flannel、Calico、Weave、Canal（技术上是多个插件的组合）。这些插件即可以确保满足Kubernetes的网络要求，又能为kubernetes集群管理员提供他们所需的某些特定的网络功能。 背景 容器网络 是容器选择连接到其他容器、主机和外部网络（如Internet）的机制。容器的runtime提供了各种网络模式，每种模式都会产生不同的效果。例如，Docker默认情况下可以为容器配置以下网络： none：将容器添加到一个容器专门的网络堆栈中，没有对外连接。 host：将容器添加到主机的网络堆栈中，没有隔离。 default bridge：默认网络模式。每个容器可以通过IP地址互相连接。 自定义网桥：用户定义的网桥，具有更多的灵活性、隔离性和其他便利功能。 Docker还可以让用户通过其他驱动程序和插件，来配置更高级的网络（包括多主机覆盖网络）。 CNI（ https://github.com/containernetworking