当我们逐渐向着微服务、云原生迈进的时候，传统静态的、相对简单的网络安全策略开始显得吃力。 Kubernetes 的 Network Policy 特性正是来解决这个问题的。在刚刚出炉不久的/R97OVqc

为了简单起见，我们会直接使用 default namespace。如果你在一个现有的环境里面， 可以将以下的命令在一个独立的 namespace 里面运行。

现在我们还没有做任何的限制，所以 Kubernetes 缺省情况是所有 Pod 都是开放的。

上面的 Wget 命令是在 BusyBox 这个 Pod 里面执行的。-q 和 -O - 的组合会使这个命令在命令行输出 nginx 的缺省首页，这表明我们的验证是成功的。用 Ctl-D 退出容器。

接下来我们就要加入限制了。我们的做法是先限制对所有 Pod 的访问，然后建立白名单。 kubectl apply下面的 YAML 文件就可以限制所有访问：

我们再试着用之前的 BusyBox 的方式来访问一下：

这此我们设置了 5 秒的超时。因为访问被拒接，所以确实会超时：

好，我们的第一个 Network Policy 已经生效了。然而，限制对所有 Pod 的访问显然是没有意义的。接下来我们建立一个白名单 . apply 下面的 YAML 文件：

接下来我们试试看能否成功地访问了：

我们依然会看到熟悉的 Nginx 缺省首页。如果我们运行一个不符合上述 selector 的 Pod，就无法访问。这个留给有兴趣的同学自己回去验证。

正式的 API 和之前的 API 区别有：

这里细节很多，我们只需要关注这几点：

Calico 使用 conntrack 来优化。就是说，一旦一个连接已经建立，之后的packet都会直接被允许通过。比如：

A：两者在 iptables 层面上的实现原理是一样的。都用了-m

Q：Calico 结合 Kubernetes 怎么实现多租户，比如网络隔离之类的？

A：各有各的市场 :-)。

Q：NPC 必须用 iptables 实现吗？在某些情况下，Pod 出向流量并不会由主机协议栈，这样 iptables 就用不了，这种情况下 NPC 怎么实现呢 ？

本次培训围绕基于Docker的CI/CD实战展开，具体内容包括：持续集成与持续交付（CI/CD）概览；持续集成系统介绍；客户端与服务端的 CI/CD 实践；开发流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及实践经验分享等。点击识别下方二维码加微信好友了解 。

Calico 是一种容器之间互通的网络方案。在虚拟化平台中，比如 OpenStack、Docker 等都需要实现 workloads 之间互连，但同时也需要对容器做隔离控制，就像在 Internet 中的服务仅开放80端口、公有云的多租户一样，提供隔离和管控机制。而在多数的虚拟化平台实现中，通常都使用二层隔离技术来实现容器的网络，这些二层的技术有一些弊端，比如需要依赖 VLAN、bridge 和隧道等技术，其中 bridge 带来了复杂性，vlan 隔离和 tunnel 隧道则消耗更多的资源并对物理环境有要求，随着网络规模的增大，整体会变得越加复杂。我们尝试把 Host 当作 Internet 中的路由器，同样使用 BGP 同步路由，并使用 iptables 来做安全访问策略，最终设计出了 Calico 方案。

设计思想：Calico 不使用隧道或 NAT 来实现转发，而是巧妙的把所有二三层流量转换成三层流量，并通过 host 上路由配置完成跨 Host 转发

- calicoctl 默认会读取 ~/.kube/下文件加载认证信息,也可以通过配置文件指定认证信息位置

第2种方式 以kubectl插件方式运行

示例2:修改BGP网络

#获取现有配置在此基础上修改
 
#在来看路由信息 已经没有之前的tunl0 直接从节点网络出去

• 到目前为止 如果是小规模的集群 比如50台以下 就可以直接使用了
• 如果是大规模集群 部署reflector路由反射器，避免过多的路由表更新 减轻AIP-SERVER压力

• 配置所有节点与reflector节点通信