ON THIS PAGE
使用 CSRX Contrail 服务链
服务链是以特定顺序通过多个网络实体转发信息流的概念,而每个网络实体则执行特定功能,如防火墙、IPS、NAT、LB 等。执行服务链的传统方式是使用独立硬件设备,但这使得服务链变得不太灵活、成本高昂且延长设置时间。在动态服务链中,网络功能部署为虚拟机或容器,可按逻辑方式自动链接。例如,Figure 1使用 Contrail 来在两个不同网络中的两个盒之间进行服务链,使用– cSRX 容器级别4级别7防火墙来保护它们之间的流量。
此处的左和右网络仅用于简单性’,用于按从左到右的顺序,但您可以使用自己的课程名称。在将盒附加到之前,请确保先配置网络,否则不会创建 pod。
启动客户端和 CSRX 箱
让’s 使用此 YAML 文件创建两个虚拟网络:
Verify using Kubectl:
’良好的实践是确认这两个网络现在是否在 Contrail 中,然后再继续。在 Contrail UI 中,选择配置 > 网络 > 网络 > 默认域 > k8s 默认值如Figure 2所示(重点介绍左侧网络)。
如果在网络的 YAML 文件中使用默认命名空间,它将在域默认域和项目 k8s 中创建它。
创建客户端箱
现在,’让 s 创建两个 Ubuntu 箱,每个网络使用以下注释对象:
#left-ubuntu-sc.yaml apiVersion: v1 kind: Pod metadata: name: left-ubuntu-sc labels: app: webapp-sc annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "vn-left" }]' spec: containers: - name: ubuntu-left-pod-sc image: contrailk8sdayone/ubuntu securityContext: privileged: true capabilities: add: - NET_ADMIN #right-ubuntu-sc.yaml apiVersion: v1 kind: Pod metadata: name: right-ubuntu-sc labels: app: webapp-sc annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "vn-right" }]' spec: containers: - name: ubuntu-right-pod-sc image: contrailk8sdayone/ubuntu securityContext: privileged: true capabilities: add: - NET_ADMIN # kubectl create -f right-ubuntu-sc.yaml # kubectl create -f left- ubuntu-sc.yaml # kubectl get pod NAME READY STATUS RESTARTS AGE left-ubuntu-sc 1/1 Running 0 25h right-ubuntu-sc 1/1 Running 0 25h # kubectl describe pod Name: left-ubuntu-sc Namespace: default Priority: 0 PriorityClassName: <none> Node: cent22/10.85.188.17 Start Time: Thu, 13 Jun 2019 03:40:20 -0400 Labels: app=webapp-sc Annotations: k8s.v1.cni.cncf.io/ network-status: [ { "ips": "10.10.10.1", "mac": "02:7d:b1:09:00:8d", "name": "vn-left" }, { "ips": "10.47.255.249", "mac": "02:7d:99:ff:62:8d", "name": "cluster-wide-default" } ] k8s.v1.cni.cncf.io/networks: [ { "name": "vn-left" }] Status: Running IP: 10.47.255.249 Containers: ubuntu-left-pod-sc: Container ID: docker://2f9a22568d844c68a1c4a45de4a81478958233052e 08d4473742827482b244cd Image: contrailk8sdayone/ubuntu Image ID: docker-pullable://contrailk8sdayone/ubuntu@sha256:fa2930cb8f4b766e5b335dfa42de510ecd30af6433ceada14cdaae8de9065d2a ...<snipped>... Name: right-ubuntu-sc Namespace: default Priority: 0 PriorityClassName: <none> Node: cent22/10.85.188.17 Start Time: Thu, 13 Jun 2019 04:09:18 -0400 Labels: app=webapp-sc Annotations: k8s.v1.cni.cncf.io/ network-status: [ { "ips": "10.20.20.1", "mac": "02:89:cc:86:48:8d", "name": "vn-right" }, { "ips": "10.47.255.252", "mac": "02:89:b0:8e:98:8d", "name": "cluster-wide-default" } ] k8s.v1.cni.cncf.io/networks: [ { "name": "vn-right" }] Status: Running IP: 10.47.255.252 Containers: ubuntu-right-pod-sc: Container ID: docker://4e0b6fa085905be984517a11c3774517d01f481fa 43aadd76a633ef15c58cbfe Image: contrailk8sdayone/ubuntu Image ID: docker-pullable://contrailk8sdayone/ubuntu@sha256:fa2930cb8f4b766e5b335dfa42de510ecd30af6433ceada14cdaae8de9065d2a ...<snipped>...
创建 cSRX 盒
现在使用此 YAML 文件创建一个 Juniper cSRX 容器,在左侧网络上有一个接口,右网络上有一个接口:
确认接口放置在正确的网络中:
# kubectl describe pod csrx1-sc Name: csrx1-sc Namespace: default Priority: 0 PriorityClassName: <none> Node: cent22/10.85.188.17 Start Time: Thu, 13 Jun 2019 03:40:31 -0400 Labels: app=webapp-sc Annotations: k8s.v1.cni.cncf.io/ network-status: [ { "ips": "10.10.10.2", "mac": "02:84:71:f4:f2:8d", "name": "vn-left" }, { "ips": "10.20.20.2", "mac": "02:84:8b:4c:18:8d", "name": "vn-right" }, { "ips": "10.47.255.248", "mac": "02:84:59:7e:54:8d", "name": "cluster-wide-default" } ] k8s.v1.cni.cncf.io/networks: [ { "name": "vn-left" }, { "name": "vn-right" } ] Status: Running IP: 10.47.255.248 Containers: csrx1-sc: Container ID: docker://82b7605172d937895269d76850d083b6dc6e278e41cb45b4cb8cee21283e4f17 Image: contrailk8sdayone/csrx Image ID: docker://sha256:329e805012bdf081f4a15322f994e5e3116b31c90f108a19123cf52710c7617e ...<snipped>...
不管注释对象的使用是什么,每个容器都有一个属于群集范围默认网络的接口,因为上面的注释对象创建完毕,并在特定网络中放入一个额外接口。
验证 PodIP
要验证 podIP,请登录左侧 pord、右 Pod 和 cSRX 以确认 IP/MAC 地址:
# kubectl exec -it left-ubuntu-sc bash root@left-ubuntu-sc:/# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 13: eth0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:7d:99:ff:62:8d brd ff:ff:ff:ff:ff:ff inet 10.47.255.249/12 scope global eth0 valid_lft forever preferred_lft forever 15: eth1@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:7d:b1:09:00:8d brd ff:ff:ff:ff:ff:ff inet 10.10.10.1/24 scope global eth1 valid_lft forever preferred_lft forever # kubectl exec -it right-ubuntu-sc bash root@right-ubuntu-sc:/# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 23: eth0@if24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:89:b0:8e:98:8d brd ff:ff:ff:ff:ff:ff inet 10.47.255.252/12 scope global eth0 valid_lft forever preferred_lft forever 25: eth1@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:89:cc:86:48:8d brd ff:ff:ff:ff:ff:ff inet 10.20.20.1/24 scope global eth1 valid_lft forever preferred_lft forever # kubectl exec - it csrx1-sc cli root@csrx1-sc> root@csrx1-sc> show interfaces Physical interface: ge-0/0/1, Enabled, Physical link is Up Interface index: 100 Link-level type: Ethernet, MTU: 1514 Current address: 02:84:71:f4:f2:8d, Hardware address: 02:84:71:f4:f2:8d Physical interface: ge-0/0/0, Enabled, Physical link is Up Interface index: 200 Link-level type: Ethernet, MTU: 1514 Current address: 02:84:8b:4c:18:8d, Hardware address: 02:84:8b:4c:18:8d
与其他盒不同,cSRX’未使用 DHCP 获取 IP,并且从出厂默认配置开始,因此需要对其进行配置。
默认情况下,cSRX eth0 仅在外壳中可见,用于管理。连接网络时,第一个连接的网络将映射到 eth1,后者为 GE-0/0/1,而附加的第二个则映射到 eth2,后者为 GE-0/0/0。
配置 cSRX IP
在 cSRX 上配置此基本设置。要分配正确的 IP 地址,请使用 kubectl 中的 MAC/IP 地址映射说明 pod 命令输出,以及配置默认安全策略以允许所有操作:
set interfaces ge-0/0/1 unit 0 family inet address 10.10.10.2/24 set interfaces ge-0/0/0 unit 0 family inet address 10.20.20.2/24
set security zones security-zone trust interfaces ge-0/0/0 set security zones security-zone untrust interfaces ge-0/0/1 set security policies default-policy permit-all commit
验证 cSRX 上分配的 IP 地址:
root@csrx1-sc> show interfaces Physical interface: ge-0/0/1, Enabled, Physical link is Up Interface index: 100 Link-level type: Ethernet, MTU: 1514 Current address: 02:84:71:f4:f2:8d, Hardware address: 02:84:71:f4:f2:8d
Logical interface ge- 0/0/1.0 (Index 100) Flags: Encapsulation: ENET2 Protocol inet Destination: 10.10.10.0/24, Local: 10.10.10.2
Physical interface: ge-0/0/0, Enabled, Physical link is Up Interface index: 200 Link-level type: Ethernet, MTU: 1514 Current address: 02:84:8b:4c:18:8d, Hardware address: 02:84:8b:4c:18:8d
Logical interface ge- 0/0/0.0 (Index 200) Flags: Encapsulation: ENET2 Protocol inet Destination: 10.20.20.0/24, Local: 10.20.20.2
左侧 pod 上的 ping 测试将失败,因为没有路由:
在左侧和右侧的盒中添加静态路由,然后再次尝试 ping:
Ping 仍发生故障,因为我们’未创建服务链,也会负责路由。让’我们来看到我们的数据包发生了什么变化:
’在 cSRX 没有会话。要排除 ping 问题,请登录承载此容器的计算节点 cent22,以使用 TShark 转储流量并检查路由。要获取链接容器的接口:
[root@cent22 ~]# vif -l Vrouter Interface Table Flags: P=Policy, X=Cross Connect, S=Service Chain, Mr=Receive Mirror Mt=Transmit Mirror, Tc=Transmit Checksum Offload, L3=Layer 3, L2=Layer 2 D=DHCP, Vp=Vhost Physical, Pr=Promiscuous, Vnt=Native Vlan Tagged Mnp=No MAC Proxy, Dpdk=DPDK PMD Interface, Rfl=Receive Filtering Offload, Mon=Interface is Monitored Uuf=Unknown Unicast Flood, Vof=VLAN insert/strip offload, Df=Drop New Flows, L=MAC Learning Enabled Proxy=MAC Requests Proxied Always, Er=Etree Root, Mn=Mirror without Vlan Tag, Ig=Igmp Trap Enabled ...<snipped>... vif0/3 OS: tapeth0-89a4e2 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.47.255.252 Vrf:3 Mcast Vrf:3 Flags:PL3DEr QOS:-1 Ref:6 RX packets:10760 bytes:452800 errors:0 TX packets:14239 bytes:598366 errors:0 Drops:10744 vif0/4 OS: tapeth1-89a4e2 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.20.20.1 Vrf:5 Mcast Vrf:5 Flags:PL3DEr QOS:-1 Ref:6 RX packets:13002 bytes:867603 errors:0 TX packets:16435 bytes:1046981 errors:0 Drops:10805 vif0/5 OS: tapeth0-7d8e06 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.47.255.249 Vrf:3 Mcast Vrf:3 Flags:PL3DEr QOS:-1 Ref:6 RX packets:10933 bytes:459186 errors:0 TX packets: 14536 bytes:610512 errors:0 Drops:10933 vif0/6 OS: tapeth1-7d8e06 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.10.10.1 Vrf:6 Mcast Vrf:6 Flags:PL3DEr QOS:-1 Ref:6 RX packets:12625 bytes:1102433 errors:0 TX packets:15651 bytes:810689 errors:0 Drops:10957 vif0/7 OS: tapeth0-844f1c Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.47.255.248 Vrf:3 Mcast Vrf:3 Flags:PL3DEr QOS:-1 Ref:6 RX packets:20996 bytes:1230688 errors:0 TX packets:27205 bytes:1142610 errors:0 Drops:21226 vif0/8 OS: tapeth1-844f1c Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.10.10.2 Vrf:6 Mcast Vrf:6 Flags:PL3DEr QOS:-1 Ref:6 RX packets:13908 bytes:742243 errors:0 TX packets:29023 bytes:1790589 errors:0 Drops:10514 vif0/9 OS: tapeth2-844f1c Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.20.20.2 Vrf:5 Mcast Vrf:5 Flags:PL3DEr QOS:-1 Ref:6 RX packets:16590 bytes:1053659 errors:0 TX packets:31321 bytes:1635153 errors:0 Drops:10421 ...<snipped>...
请注意,vif0/3 和 vif0/4 与右侧 pod 绑定,分别链接到 tapeth0-89a4e2 和 tapeth1-89a4e2。Vif0/5 和 Vif0/6 的左盒的相同之处,Vif0/7、vif 0/8 和 Vif0/9 与 cSRX1 绑定在一起。从中,您还可以看到击中接口的数据包/字节的数量,以及 VRF。VRF 3 适用于默认集群-网络,而 VRF 6 则适用于左网络,而 VRF 5 则适用于正确的网络。在图10.3 中,您可以从所有视角(容器、Linux、vr 代理)中看到接口映射。
让’我们再次尝试从左盒向右盒上 ping,并使用右盒的分路界面上的 TShark 进行进一步检测:
看起来 ping’根本没有到达右侧的 pod,让我们’检查 cSRX’的左网络路界面:
我们可以看到数据包,但 cSRX 安全中没有希望丢弃此数据包的任何内容
通过记录到计算节点中 vrouter_vrouter agent_1 容器,检查左网络 VRF 的路由表:
[root@cent22 ~]# docker ps | grep vrouter 9a737df53abe ci-repo.englab.juniper.net:5000/contrail-vrouter-agent:master-latest "/entrypoint.sh /usr…" 2 weeks ago Up 47 hou rs vrouter_vrouter-agent_1 e25f1467403d ci-repo.englab.juniper.net:5000/contrail-nodemgr:master-latest "/entrypoint.sh /bin…" 2 weeks ago Up 47 hou rs vrouter_nodemgr_1 [root@cent22 ~]# docker exec -it vrouter_vrouter-agent_1 bash (vrouter-agent)[root@cent22 /]$ (vrouter-agent)[root@cent22 /]$ rt --dump 6 | grep 10.20.20. (vrouter- agent)[root@cent22 /]$
请注意,6是左侧网络的路由表 VRF;正确的网络 VRF 路由表也是如此,但缺少路由:
因此,即使所有的箱都托管在相同的计算节点上,它们也’无法相互连接。如果这些箱托管在某些不同的计算节点上,您就有了更大的问题要解决。服务链’不仅仅是调整容器上的路由,还应在计算节点之间的 vRouter 之间交换路由,而不考虑盒的位置(以及在将盒式移动到其他计算节点时自动调整)。在 labbing 服务链允许我’解决不属于这种 CLI 故障排除…的网络管理员的重要问题之前,您可以使用 Contrail 控制器 GUI 执行相同的故障排除。
在 Contrail 控制器 UI 中,选择监控 > 基础架构 > 虚拟路由器,然后选择承载该 pod 的节点,在我们的本例中为 cent22,如下一个屏幕捕获中所示,Figure 4。
Figure 4显示了 "接口" 选项卡,它等效于在 vrouter_vrouter 代理-1 容器上运行 vif-l 命令,但显示的信息更详细。请注意实例 ID 和分路接口命名之间的映射,实例 ID 的前六个字符将始终在分路接口命名中反映出来。
我们是 GUI cowboys。让’我们检查每个 VRF 的路由表,方法是移动到路由选项卡并选择要查看的 VRF,如Figure 5中所示。
选择左网络。名称较长,因为它包含域(和项目)。您可以确认没有来自正确网络的 10.20.20.0/24 前缀。您也可通过选择 L2 (相当于 rt--dump 6--系列桥接命令),检查在左网络中了解的 MAC 地址。
服务链
现在让’我们使用 CONTRAIL 命令 GUI 利用 cSRX 服务链。服务链包含四个需要按顺序完成的步骤:
- 创建服务模板;
- 根据已完成的服务模板创建服务实例;
- 创建网络策略并选择以前创建的服务实例;
- 将此网络策略应用到网络。
由于 Contrail 命令 GUI 是为所有环境提供单点管理的最佳解决方案,因此我们将使用它来构建服务变化。您仍然可以使用常规 Contrail 控制器 GUI 来构建服务链。
首先,’让 s 登录 CONTRAIL 命令 GUI (在我们的设置 https://10.85.188.16:9091/中),如Figure 7中所示,然后选择服务 > 目录 > Create,如Figure 8所示。
在此处插入服务模板的名称,在此处 myweb-cSRX-CS,然后选择 v2 和虚拟机作为服务模式。选择 "网络中" 和 "防火墙" 作为服务类型,如Figure 9所示。
下一步选择管理,从左到右,然后单击创建。
现在,选择部署,然后单击 Create 按钮创建服务实例,如Figure 11所示。
命名此服务实例,然后从下拉菜单中选择您创建的模板的名称,以便从 cSRX 成为将执行服务链的实例(在该情况下为容器)中选择正确的网络。单击端口元组以将其展开,如Figure 12所示。然后,这三个接口中的每一个都绑定 cSRX 的一个接口,然后单击 Create。
虚拟机接口’的名称未显示在下拉菜单中,而是’实例 ID。您可以根据我们之前提到的方式来识别点击接口名称。换句话说,您只需了解属于该容器的任何接口的前六个字符。给定实例(VM 或容器)中的所有接口共享相同的首字符。
继续之前,请确保三个接口的状态正常,并且显示的是 cSRX 实例的正确 IP 地址,如Figure 13所示。
要创建网络策略,请转到叠加 > 网络策略 > 创建,如Figure 14所示。
为您的网络策略命名,然后在第一个规则中,将左网络添加为源网络,将右侧网络作为目标提供给 pass 操作。
选择 advanced 选项并将服务实例连接到以前创建的,然后单击创建按钮。
要将此网络策略附加到网络,请在最左侧列中单击虚拟网络,然后选择左网络和编辑。
在网络策略中,从下拉菜单列表中选择您刚创建的网络策略,然后单击 Save。对正确的网络执行相同操作。
验证服务链
现在让’我们来验证此服务的影响是否在路由上更改。从 Contrail 控制器模块控制节点(http://10.85.188.16:8143 在我们的设置中),选择监控 > 基础架构 > 虚拟路由器然后选择承载该 pod 的节点,在本例中为 Cent22. local,然后选择路由选项卡并选择左 VRF。
在这种情况下,您可以看到正确的网络主机路由已泄漏到左侧网络(10.20.20.1/32、10.20.20.2/32)。
现在,’让我们从左箱向右盒 ping,以查看 cSRX 上创建的会话:
安全策略
在 cSRX 上创建安全策略,以便仅允许 HTTP 和 HTTPS:
由于 cSRX 上的策略下降,ping 失败:
root@csrx1-sc> show log syslog | last 20 Jun 14 23:04:01 csrx1-sc flowd-0x2[374]: RT_FLOW: RT_FLOW_SESSION_DENY: session denied 10.10.10.1/8- >10.20.20.1/575 0x0 icmp 1(8) deny-ping trust untrust UNKNOWN UNKNOWN N/A(N/A) ge-0/0/1.0 No policy reject 5394 N/A N/A -1 Jun 14 23:04:02 csrx1-sc flowd-0x2[374]: RT_FLOW: RT_FLOW_SESSION_DENY: session denied 10.10.10.1/9- >10.20.20.1/575 0x0 icmp 1(8) deny-ping trust untrust UNKNOWN UNKNOWN N/A(N/A) ge-0/0/1.0 No policy reject 5395 N/A N/A -1 Try to send http traffic from the left to the right POD and verify the session status on the CSRX root@left-ubuntu-sc:/# wget 10.20.20.1 --2019-06-14 23:07:34-- http://10.20.20.1/ Connecting to 10.20.20.1:80... connected. HTTP request sent, awaiting response... 200 OK Length: 11510 (11K) [text/html] Saving to: 'index.html.4' 100%[============================= =========>] 11,510 --.-K/s in 0s 2019-06-14 23:07:34 (278 MB/s) - 'index.html.4' saved [11510/11510]
在 cSRX 我们可以看到会话创建:
root@csrx1-sc> show log syslog | last 20 Jun 14 23:07:31 csrx1-sc flowd-0x2[374]: csrx_l3_add_new_resolved_unicast_ nexthop: Adding resolved unicast NH. dest: 10.20.20.1, proto v4 (peer initiated) Jun 14 23:07:31 csrx1-sc flowd-0x2[374]: csrx_l3_add_new_resolved_unicast_ nexthop: Sending resolve request for stale ARP entry (b). NH: 5507 dest: 10.20.20.1 Jun 14 23:07:34 csrx1-sc flowd-0x2[374]: RT_FLOW: RT_FLOW_SESSION_CREATE: session created 10.10.10.1/47190->10.20.20.1/80 0x0 junos- http 10.10.10.1/47190->10.20.20.1/80 0x0 N/A N/A N/A N/A 6 only-http-s trust untrust 5434 N/A(N/A) ge- 0/0/1.0 UNKNOWN UNKNOWN UNKNOWN N/A N/A -1 Jun 14 23:07:35 csrx1-sc flowd-0x2[374]: RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP FIN: 10.10.10.1/47190- >10.20.20.1/80 0x0 junos-http 10.10.10.1/47190->10.20.20.1/80 0x0 N/A N/A N/A N/A 6 only- http-s trust untrust 5434 14(940) 12(12452) 2 UNKNOWN UNKNOWN N/A(N/A) ge- 0/0/1.0 UNKNOWN N/A N/A -1