1431人阅读
Docker（90）
flannel（4）
etcd（12）
一、这个问题困扰了好几天，单个节点的pod之间通信没问题，但是当涉及到多个节点之间的通信就不行。最后问题锁定在flannel打通不同节点之间的网络的问题。
二、实验环境
1、ubuntu-14.04、k8s-1.4、flannel-0.5.5、etcd-2.3、docker-1.12.3
2、k8s集群总共有三个节点，一个master（192.168.110.151，同时作为私有registry仓库），minion1（192.168.110.152），minion2（192.168.110.154）
三、实验过程
1、配置集群相关软件
（1）master的etcd（放在/home/docker/xu/etcd目录下）
root@master:/home/docker/xu/etcd# tree
├── etcd
├── etcd0.etcd
│ & └── member
│ & & & ├── snap
│ & & & │ & ├── 005c-3889.snap
│ & & & │ & ├── a.snap
│ & & & │ & ├── 00bc-86ab.snap
│ & & & │ & ├── 00bf-adbc.snap
│ & & & │ & └── 00bf-d4cd.snap
│ & & & └── wal
│ & & & & & ├── .wal
│ & & & & & └── .wal
├── etcdctl
└── run.sh
其中run.sh是启动脚本，内容如下：
killall -9 etcd
-name etcd0 \
-data-dir etcd0.etcd \
-initial-advertise-peer-urls http://master:2380 \
-listen-peer-urls http://master:2380 \
-listen-client-urls http://master:2379,http://127.0.0.1:2379 \
-advertise-client-urls http://master:2379 \
-initial-cluster-token etcd-cluster \
-initial-cluster etcd0=http://master:2380,etcd1=http://dockertest4:2380,etcd2=http://dockertest5:2380 \
-initial-cluster-state new
（2）minion1的etch配置（放在/home/docker/xu/etcd目录下）
root@dockertest4:/home/docker/xu/etcd# tree
├── etcd
├── etcd1.etcd
│ & └── member
│ & & & ├── snap
│ & & & │ & ├── 005c-3888.snap
│ & & & │ & ├── .snap
│ & & & │ & ├── 00bc-86aa.snap
│ & & & │ & ├── 00bf-adbb.snap
│ & & & │ & └── 00bf-d4cd.snap
│ & & & └── wal
│ & & & & & ├── .wal
│ & & & & & └── .wal
├── etcdctl
└── run.sh
其中run.sh是启动脚本，内容如下：
killall -9 etcd
-name etcd1 \
-data-dir etcd1.etcd \
-initial-advertise-peer-urls http://dockertest4:2380 \
-listen-peer-urls http://dockertest4:2380 \
-listen-client-urls http://dockertest4:2379,http://127.0.0.1:2379 \
-advertise-client-urls http://dockertest4:2379 \
-initial-cluster-token etcd-cluster \
-initial-cluster etcd0=http://master:2380,etcd1=http://dockertest4:2380,etcd2=http://dockertest5:2380 \
-initial-cluster-state new
（3）minion2的etcd配置（放在/home/docker/xu/etcd目录下）
root@dockertest5:/home/docker/xu/etcd# tree
├── etcd
├── etcd2.etcd
│ & └── member
│ & & & ├── snap
│ & & & │ & ├── 005c-3889.snap
│ & & & │ & ├── a.snap
│ & & & │ & ├── 00bc-86ab.snap
│ & & & │ & ├── 00bf-adbc.snap
│ & & & │ & └── 00bf-d4cd.snap
│ & & & └── wal
│ & & & & & ├── .wal
│ & & & & & └── .wal
├── etcdctl
└── run.sh
run.sh是启动配置文件，文件内容如下
killall -9 etcd
-name etcd2 \
-data-dir etcd2.etcd \
-initial-advertise-peer-urls http://dockertest5:2380 \
-listen-peer-urls http://dockertest5:2380 \
-listen-client-urls http://dockertest5:2379,http://127.0.0.1:2379 \
-advertise-client-urls http://dockertest5:2379 \
-initial-cluster-token etcd-cluster \
-initial-cluster etcd0=http://master:2380,etcd1=http://dockertest4:2380,etcd2=http://dockertest5:2380 \
-initial-cluster-state new
（4）master的k8s的配置（kube-apiserver、kube-controller-manager，kube-scheduler，他们所在的目录是/home/docker/xu/ku/kubernetes/server/bin）
root@master:/home/docker/xu/kubernetes/server/bin# tree
├── hyperkube
├── kube-apiserver
├── kube-apiserver.docker_tag
├── kube-controller-manager
├── kube-controller-manager.docker_tag
├── kubectl
├── kube-dns
├── kubelet
├── kubemark
├── kube-proxy
├── kube-proxy.docker_tag
├── kube-scheduler
├── kube-scheduler.docker_tag
├── run-apiserver.sh
├── run-controller-manager.sh
└── run-scheduler.sh
其中run-apiserver.sh、run-controller-manager.sh和run-scheduler.sh分别是启动脚本，脚本内容分别如下：
./kube-apiserver --address=0.0.0.0
--insecure-port=8080 --service-cluster-ip-range='192.168.110.0/24' --kubelet_port=10250 --v=0 --logtostderr=true --etcd_servers=http://192.168.110.151:2379 --allow_privileged=false
&& /opt/k8s/kube-apiserver.log 2&&1 &
./kube-controller-manager
--v=0 --logtostderr=false --log_dir=/opt/k8s/kube --master=192.168.110.151:8080 && /opt/k8s/kube-controller-manager.log 2&&1 &
./kube-scheduler
--master='192.168.110.151:8080' --v=0
--log_dir=/opt/k8s/kube
&& /opt/k8s/kube-scheduler.log 2&&1 &
（5）minion1的k8s的配置（kube-proxy、kubelet他们所在的目录是/home/docker/xu/kubernetes/server/bin）
root@dockertest4:/home/docker/xu/kubernetes/server/bin# tree
├── hyperkube
├── kube-apiserver
├── kube-apiserver.docker_tag
├── kube-controller-manager
├── kube-controller-manager.docker_tag
├── kubectl
├── kube-dns
├── kubelet
├── kubemark
├── kube-proxy
├── kube-proxy.docker_tag
├── kube-scheduler
├── kube-scheduler.docker_tag
├── run-let.sh
└── run-proxy.sh
其中run-proxy.sh和run-let.sh分别是启动脚本，内容分别如下
./kube-proxy
--logtostderr=true --v=0 --master=http://192.168.110.151:8080 --hostname_override=192.168.110.152
&& /opt/k8s/kube-proxy.log
--logtostderr=true --v=0 --allow-privileged=false
--log_dir=/opt/k8s/kube
--address=0.0.0.0
--port=10250
--hostname_override=192.168.110.152
--api_servers=http://192.168.110.151:8080
&& /opt/k8s/kube-kubelet.log
（6）minion2的k8s的配置（kube-proxy、kubelet他们所在的目录是/home/docker/xu/k8s/server/bin）
root@dockertest5:/home/docker/xu/k8s/server/bin# tree
├── hyperkube
├── kube-apiserver
├── kube-apiserver.docker_tag
├── kube-controller-manager
├── kube-controller-manager.docker_tag
├── kubectl
├── kube-dns
├── kubelet
├── kubemark
├── kube-proxy
├── kube-proxy.docker_tag
├── kube-scheduler
├── kube-scheduler.docker_tag
├── run-let.sh
└── run-proxy.sh
其中run-proxy.sh和run-let.sh分别是启动脚本，内容分别如下./kube-proxy
--logtostderr=true --v=0 --master=http://192.168.110.151:8080 --hostname_override=192.168.110.154
&& /opt/k8s/kube-proxy.log
--logtostderr=true --v=0 --allow-privileged=false
--log_dir=/opt/k8s/kube
--address=0.0.0.0
--port=10250
--hostname_override=192.168.110.154
--api_servers=http://192.168.110.151:8080
&& /opt/k8s/kube-kubelet.log
2、启动相关软件
1、master节点的etcd，在master节点的etcd所在目录下执行./run.sh
2、minion1节点的etcd，在master节点的etcd所在目录下执行./run.sh
3、minion2节点的etcd，在master节点的etcd所在目录下执行./run.sh
4、验证etcd是否启动成功
在master节点的etcd所在目录下执行./etcdctl member list，看见下面的输出，说明etcd集群启动成功
root@master:/home/docker/xu/etcd# ./etcdctl member list
35eca4f: name=etcd1 peerURLs=http://dockertest4:2380 clientURLs=http://dockertest4:2379 isLeader=true
c1a5: name=etcd0 peerURLs=http://master:2380 clientURLs=http://master:2379 isLeader=false
835aada27b736086: name=etcd2 peerURLs=http://dockertest5:2380 clientURLs=http://dockertest5:2379 isLeader=false
5、在master节点的flannel，在flannel所在目录下执行如下命令./flanneld -etcd-endpoints http://192.168.110.151:2379其中，http://192.168.110.151:2379 是etcd的地址
6、minion1的flannel，在flannel所在目录下执行如下命令：
./flanneld -etcd-endpoints http://192.168.110.151:23797、minion2的flannel，在flannel所在目录下执行如下命令：
./flanneld -etcd-endpoints http://192.168.110.151:23798、在master节点的etcd目录下执行如下命令：
etcdctl set //network/config '{ &Network&: &10.1.0.0/16& }'9、在master节点的etcd所在目录执行如下命令，确认上一步命令是否成功
root@master:/home/docker/xu/etcd# ./etcdctl ls //network/subnets
//network/subnets/10.1.44.0-24
//network/subnets/10.1.54.0-24
//network/subnets/10.1.60.0-24
10、然后分别在每个节点下执行如下命令
（1）mk-docker-opts.sh -i
（2）source /run/flannel/subnet.env
（3）ifconfig docker0 ${FLANNEL_SUBNET}
（4）sudo service docker stop
（5）&dockerd -dns 8.8.8.8 --dns 8.8.4.4 --insecure-registry 192.168.110.151:5000 -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock --bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU}
11、查看每个节点的路由信息，确认flannel是否打通网络
root@master:/home/docker/xu/flannel# route -n
内核 IP 路由表
192.168.110.2
255.255.0.0
0 flannel0
255.255.255.0
192.168.110.0
255.255.255.0
注意：如果打通网络 flannel0和docker0的目标地址应该在一个大网路里面
12、master节点的k8s，在k8s所在目录下执行如下命令
./run-apiserver.sh
./run-controller-manager.sh
./run-scheduler.sh
13、分别在minion1和minion2的节点上执行如下命令
./run-proxy.sh
./run-let.sh
14、执行如下命令，看见相应输出，说明k8s启动成功
root@master:/home/docker/xu/flannel# kubectl get cs
controller-manager
{&health&: &true&}
root@master:/home/docker/xu/flannel# kubectl get nodes
192.168.110.152
192.168.110.154
3、验证环境
（1）本实验是javaweb程序链接mysq数据库，其中在minion2上运行1个mysql &pod，然后分别在minion1和minion2上运行一个tomcat（镜像里面包含看wen应用测试代码）。
（2）如果minion1上的tomcat也能访问到mysql数据库，说明两个节点的网络已经打通
（3）mysql.ysml和tomcat.yaml的文件内容分别如下
apiVersion: v1
kind: Service
name: mysql
- port: 3306
app: mysql_pod
apiVersion: v1
kind: ReplicationController
name: mysql-deployment
replicas: 1
app: mysql_pod
containers:
- name: mysql
image: 192.168.110.151:5000/mysql
imagePullPolicy: IfNotPresent
- containerPort: 3306
- name: MYSQL_ROOT_PASSWORD
value: &123456&
apiVersion: v1
kind: Service
name: hpe-java-web
type: NodePort
- port: 8080
nodePort: 31002
app: hpe_java_web_pod
apiVersion: v1
kind: ReplicationController
name: hpe-java-web-deployement
replicas: 2
app: hpe_java_web_pod
containers:
- name: myweb
image: 192.168.110.151:5000/tomact8
imagePullPolicy: IfNotPresent
- containerPort: 8080
（4）分别启动mysql和tomcat容器
kubectl create -f mysql.yaml
kubectl create -f tomcat.ysml
（5）验证启动状态
root@master:/home/docker/xu/test# kubectl get pods
hpe-java-web-deployement-4oeax
hpe-java-web-deployement-kqkv8
mysql-deployment-bk5v1
root@master:/home/docker/xu/test# kubectl get service
CLUSTER-IP
EXTERNAL-IP
hpe-java-web
192.168.110.63
kubernetes
192.168.110.1
192.168.110.220
（5）javaweb的实验代码如下：
&%@ page language=&java& contentType=&text/ charset=UTF-8& pageEncoding=&UTF-8&%&
&%@page import=&java.sql.*& %&
&meta http-equiv=&Content-Type& content=&text/ charset=UTF-8&&
&title&Insert title here&/title&
&table border=&1& align=&center&&
&td&卡号&/td&
String driverClass=&com.mysql.jdbc.Driver&;
String ip=System.getenv(&MYSQL_SERVICE_HOST&);
String port=System.getenv(&MYSQL_SERVICE_PORT&);
System.out.println(port+&asasdfasdfasdfasdfasd&);
//String ip = &localhost&;
//String port = &3306&;
Class.forName(driverClass);
conn = java.sql.DriverManager.getConnection(&jdbc:mysql://&+ip+&:&+port+&/bms&, &root&,&123456&);
Statement stmt=conn.createStatement();
String sql=&select * from bms_appuser&;
ResultSet rs=stmt.executeQuery(sql);
while(rs.next()){
&td&&%=rs.getString(3) %&&/td&
catch(Exception ex){
ex.printStackTrace();
&/html&（6）javaweb的工程名称是K8S，为了简单只是含有上述一个jsp页面，index.jsp。数据库、数据库表可以根据自己方便随便创建。
（7）分别在minion1、minion2和除了集群以为的其他机器上访问http://192.168.110.151:31002/K8S/inedex.jsp，如果多能访问到自己的数据，说明实验成功。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：177241次
积分：3347
积分：3347
排名：第10491名
原创：132篇
转载：219篇
评论：13条
(8)(3)(3)(10)(11)(13)(4)(14)(10)(26)(19)(17)(5)(11)(13)(15)(10)(14)(21)(13)(22)(18)(13)(18)(7)(18)(15)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'容器周边开源工具新秀：Sysdig和Calico
我的图书馆
容器周边开源工具新秀：Sysdig和Calico
伴随着容器技术的普及和落地，许多围绕在容器与微服务生态圈周边的开源工具也逐渐获得社区的关注和投入。其中有许多工具的名字已经广为人知，比如服务发现工具Etcd和Consul，日志收集工具组合Elasticsearch、Logstash和Kibana，任务编排工具Fleet、Kubernetes和Mesos等。这些工具之所以出名，一方面是由于它们解决了实际生产中遇到的问题，另一方面则是由于项目主导者和参与者的大力宣传。与此相对的，在社区中同样存在着许多十分优秀但出镜率并不高的开源项目。在今年CoreOS Fest大会接近尾声的时候，会场上出现了两个值得关注的话题，演讲者分别展示了Sysdig和Calico在CoreOS系统中的运用，这两个产品都是与容器密切相关的开源工具，它们分别补充了现有容器技术在特定功能领域方面的不足。即使是在CoreOS Fest已经过去几个月的现在看来，在Sysdig和Calico各自所处的领域内，它们都依然是无可替代的选择。本文将从安装和使用两个方面分别介绍这两个工具的使用场景。容器监控器SysdigSysdig【1】是Sysdig Cloud公司开发的一款开源的系统运行信息和网络流监控软件，早先在网络上的一些文章也对它有所介绍，但几乎都只关注于它对主机的监控和管理功能。而Sysdig之所以能够出现在CoreOS Fest上，一个重要的原因，就是它在近期的版本中【2】将容器的监控纳入了其首位支持的特性。通过Sysdig工具，用户能够很方便地查看到主机上所有应用程序的CPU、文件I/O、网络访问状况，这个工具最初的产生就是为了取代传统服务器上的一系列系统检测工具如strace、tcpdump、htop、iftop、lsof等。它的Logo被设计为一个铲子的轮廓，寓意着Sysdig对系统信息的强大挖掘能力。新版本的Sysdig在设计上充分运用了容器技术的成果，这主要体现在两个方面。一方面是Sysdig提供了可以快速运行的Docker容器镜像，这使得用户能够很方便地在任何安装了Docker的Linux环境中快速使用它进行系统数据的收集和分析。另一方面是Sysdig专门提供了容器级别的信息采集命令，支持查看指定容器之间的网络流量、查看特定容器的CPU使用量等。对于大多数的Linux发行版，都可以通过下面这个命令直接安装Sysdig工具。$ curl -s //stable/install-sysdig| sudo bash或者通过以下命令，用Docker快速启动一个包含有Sysdig命令的控制台【3】。$ docker run -i -t --name sysdig --privileged -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro sysdig/sysdig安装完Sysdig后，下面介绍一下它的使用。Sysdig令的默认作用域是整个主机，用户需要通过“container.name”参数将作用域限定为指定容器，我们将重点讨论这种情况的应用场景。首先运行一交互模式的Ubuntu容器，命名为ubuntu01，它将作为被监控的容器$ docker run -it --rm --name ubuntu01 ubuntu /bin/bash在接下来的所有命令中，都会使用“container.name=ubuntu01”参数，这样就将监控的作用域限定在这个容器相关的系统资源上。不加其他参数的sysdig命令的作用相当于tcpdump，它将打印出指定容器中所有的网络数据到控制台上，可以使用-w将捕获的数据写入指定的文件中。保存的抓包文件除了通过专用软件如wireshark进行分析，也可以直接用sysdig的-r参数读取出来再打印到控制台。$ sysdig container.name=ubuntu01默认情况下，这个命令的输出显示的是容器中运行的进程在主机上的实际PID号。使用-p参数可以改变输出内容的格式，给命令加上-pcontainer参数（可简写为-pc），就会额外打印出进程所处的容器名称，以及在容器中的PID信息。此外，使用-c参数可以指定监控的操作类型，Sysdig提供了几十种客供查看和监控的系统数据。包括CPU使用率、文件I/O、网络流量、系统错误、系统日志、性能瓶颈甚至监控指定用户的行为。例如，在Sysdig的Shell输入：$ sysdig -pc -c topprocs_cpu container.name=ubuntu01Sysdig将显示属于ubuntu01容器中的所有进程的CPU使用情况，并以CPU使用率排序。显示内容举例如下：CPU% Process Host_pid Container_pid container.name--------------------------------------------------------------------------------0.00% bash 3997 1 ubuntu01此时如果在ubuntu01容器中开始“apt-getupdate”的操作，同时在Sysdig的Shell输入：$ sysdig -pc -c topprocs_net container.name=ubuntu01就能够看到容器中所有进程的网络使用情况了。显示内容举例如下：Bytes Process Host_pid Container_pid container.name--------------------------------------------------------------------------------62.58KB http 4491 22 ubuntu01Sysdig还支持一些复杂的数据过滤操作，例如下面这个命令能够监控ubuntu01容器中所有由cat进程发起的“open”系统调用。$ sysdig -pc proc.name=cat and evt.type=open and container.name=ubuntu01在Sysdig提供的命令中，有个十分有趣的“spy_users”功能，可以实时监控指定容器的用户输入内容。例如，在Sysdig的Shell输入以下命令：$ sysdig -pc -c spy_users container.name=ubuntu01回到ubuntu01容器中，执行一个“ ls —color=auto”命令，然后就会看到刚刚输入命令实时的回显在了Sysdig的Shell里面。显示内容举例如下：:19 root@ubuntu01) ls --color=auto这些示例仅仅是展示了Sysdig能力的冰山一角，在目前的其他系统监控类工具中，笔者还没有看到像Sysdig这样功能如此强大、而又对容器支持这样好的。所以，对于经常使用容器作为产品运行方式的用户，这是一款值得深入了解的“故障排查神器”。容器级防火墙Calico在传统的服务应用架构设计中，通常会将各种服务模块按照功能类型进行分层，例如Web应用服务、核心业务服务、数据库服务等，在层与层之间通过防火墙限定上层服务对下层服务的访问规则。如图1所示。图1 传统应用架构通用的分层设计而对于容器化的服务场景，许多用户往往倾向于构建由大量可横向扩展的、独立的小单元组成的微服务式架构。在这样的架构中，主机节点的个数和IP地址都是快速变化的，且在业务服务单元之间存在很多相互调用的情况，也需要进行访问的安全控制，这使得分层防火墙的思路不再可行。Calico【4】是Metaswitch Networks公司提供的一种容器级路由和防火墙工具，它能够在容器级别上为每个容器实例或Kubernetes的Pod实例指定访问规则，达到服务间可控的访问。从原理上说，Calico是通过修改每个主机节点上的iptables和路由表规则实现容器间数据路由和访问控制，并通过Etcd协调节点配置信息的。因此Calico服务本身和许多分布式服务一样，需要运行在集群的每一个节点上。Calico的Logo被设计成一只玩毛线球的斑点猫，仿佛说明它能够将乱如毛线团的容器网络通信整理得规规整整。由于不同的容器调度框架对网络结构和容器调度单元的实现上并不一致，Calico针对许多主流的应用场景分别进行了定制，例如直接用于Docker、直接用于Rkt、作为libnetwork插件、作为Kubernetes插件、作为Mesos插件等场景。与Kubernetes结合使用时，它还能够替代其他网络规划工具，例如Flannel，直接接管集群不同节点间的网络通信路由功能。下面重点介绍Calico直接用于Docker的场景，它是Calico最基本、也最具代表性的一种使用方法。Calico的安装可以通过它的控制客户端工具完成，这个命令行工具可以从Calico的Github仓库直接下载。下面的命令将其放到系统的/opt/bin/目录中，以方便使用：$ wget -O /opt/bin/calicoctl /projectcalico/calico-docker/releases/download/v0.6.0/calicoctl$ chmod +x /opt/bin/calicoctl为了演示Calico提供的跨节点路由功能，下面将在两个主机节点上分别启动Calico服务。启动的命令为“calicoctl node”，这个命令会在当前节点通过Docker启动一个部署有Calico服务的容器，并在后台保持运行。$ hostnamecore-01$ sudo calicoctl nodeNo IP provided. Using detected IP: 10.0.2.15Calico node is running with id: …$ docker psCONTAINER ID
NAMESd0388bcdca86
calico/node:v0.6.0
'/sbin/my_init'
calico-node在另一个节点也将Calico服务启动起来。$ hostnamecore-02$ sudo calicoctl nodeNo IP provided. Using detected IP: 10.0.2.16Calico node is running with id: …在每个节点上分别运行两个Docker容器，并将网络模式设置为none，然后通过“calicoctlcontaineradd”命令将容器添加到Calico服务的管理之下，首先是节点core-01：$ hostnamecore-01$ docker run --net=none --name docker-01-A -tid ubuntu:15.10$ docker run --net=none --name docker-01-B -tid ubuntu:15.10$ sudo calicoctl container add docker-01-A 192.168.0.1$ sudo calicoctl container add docker-01-B 192.168.0.2然后在节点core-02做相同操作，注意容器的命名差异。$ hostnamecore-02$ docker run --net=none --name docker-02-A -tid ubuntu:15.10$ docker run --net=none --name docker-02-B -tid ubuntu:15.10$ sudo calicoctl container add docker-02-A 192.168.0.3$ sudo calicoctl container add docker-02-B 192.168.0.4由于目前还未在Calico中添加任何规则，这四个容器之间是无法ping通的。接下来，先创建两个访问组“GROUP_A”和“GROUP_01”，这个操作可以在任意的一个节点上完成。$ calicoctl profile add GROUP_ACreated profile GROUP_A$ calicoctl profile add GROUP_01Created profile GROUP_01最后将容器docker-01-A和docker-02-A添加到访问组GROUP_A中，将容器docker-01-A和docker-01-B添加到访问中GROUP_01中。注意“calicoctl container”命令必须在运行有指定容器的主机上运行，首先是主机core-01。$ hostnamecore-01$ calicoctl container docker-01-A profile append GROUP_AProfiles GROUP_A appended$ calicoctl container docker-01-A profile append GROUP_01Profiles GROUP_01 appended$ calicoctl container docker-01-B profile append GROUP_01Profiles GROUP_01 appended然后是主机core-02。$ hostnamecore-02$ calicoctl container docker-02-A profile append GROUP_AProfiles GROUP_A appended图2 示例配置形成的网络结构以上配置形成的网络结构如图2所示。若使用ping命令验证容器两两之间的可访问性，可以发现只要同属一个访问组的两个容器之间，不论它们是否处在相同物理节点，相互访问都是成功，反之则无法连接。容器docker-01-A能够同时和docker-02-A和docker-01-B通信容器docker-01-B和docker-02-A都只能与docker-01-A通信容器docker-02-B与其他任何容器之间都不能通信上面这个案例很好的解释了“容器级防火墙”的含义。实际上，对于比较大型的服务集群，手工修改每一个容器的IP地址和访问规则是不现实的，Calico内置了对常见的容器扩展库（例如libnetwork）和调度框架（例如Kubernetes和Mesos）的插件方式支持，其底层工作原理与上面演示的直接用于Docker的情况基本一致，同时利用这些扩展和框架的功能简化了访问规则的配置方法。比如将Calico与Kubernetes进行集成时，仅需要安装Kubernetes的Calico插件，并在启动Kubernetes Node节点的kubelet进程时，添加network_plugin参数指定Calico作为其网络层的地址分配工具即可。Calico将允许用户在创建Pod和Service描述文件时，使用Kubernetes内置的标签功能和特殊的“projectcalico.org/policy”属性【5】设置基于标签过滤数据的防火墙访问规则。这样就很容易将防火墙规则通过Pod和Service描述文件的方式固化起来，从而免去每次手工配置，达到基础实施即代码（InfrastructureasCode）的作用。小结任何一项趋于成熟的技术领域，总是伴随着生态圈周边众多工具的支持。目前，容器技术领域已经形成了围绕集群编排、服务部署、监控管理等方面的一整套体系。组成这个体系的设施，除了Docker、Rkt、Intel Clear这些核心容器组件，还有包括许多的辅助工具。它们有些作为独当一面的系统工具形式存在，例如Sysdig，有些则主要以其他核心组件的插件形式存在，例如Calico。这篇文章中介绍的两种容器辅助工具虽然仅仅是这一庞大生态圈中的冰山一角，然而它们很好地扩扩展了容器技术在监控和安全方面的能力，在实际生产中的作用不容小觑。参考资料【2】准确地说是日发布的0.1.98版本【3】在比较特殊的CoreOS系统中，由于系统目录是只读的，必须使用这种方法运行Sysdig【5】/projectcalico/calico-docker/blob/master/docs/kubernetes/KubernetesPolicy.md作者简介林帆，生在80后尾巴的IT攻城狮，ThoughtWorks成都办公室CloudOps小组成员，平时喜欢在业余时间研究DevOps相关的应用，目前在备考AWS认证和推广Docker相关技术。（责编/周建丁 zhoujd at csdn dot net）本文选自程序员电子版2015年11月A刊，该期更多文章请查看这里。2000年创刊至今所有文章目录请查看程序员封面秀。欢迎订阅程序员电子版（含iPad版、Android版、PDF版）。
TA的最新馆藏[转]&
喜欢该文的人也喜欢