Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to analyze the Network Control of k8s Cluster Canal

2025-03-30 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)05/31 Report--

How to analyze the network control of k8s cluster Canal, many novices are not very clear about this. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

1 introduction

Canal is the combination of calico and flannel, because Calico can not only provide good network performance, but also have network rule control, but we often use Flannel network, its disadvantage is that there is no network control can only provide network services, so Canal was born to provide network control for Falanel.

Network policy controls outbound: egress controls inbound: ingress can define rules in ip address blocks, based on namespace rules, and on pod

2 deploy Canal

Curl\ https://docs.projectcalico.org/v3.6/getting-started/kubernetes/installation/hosted/canal/canal.yaml\-Okubectl apply-f canal.yaml1) the default control of canal is 10.244.0.0 pod 16, if you are installing the K8s cluster, it is set up not this network. Then you need to modify the configuration file 2) the way we use to create and view the pod# kubectl get pods-n kube-system NAME READY STATUS RESTARTS AGEcanal-9lmw8 2 4m50scanal-ln6kg 2 Running 0 4m50scanal-ln6kg 2 Running that we use to share the Running with the k8s cluster 0 4m50scanal-mx6tn 2/2 Running 0 4m50scoredns-fb8b8dccf-lfbkh 1/1 Running 2 10dcoredns-fb8b8dccf-t2kdz 1/1 Running 2 10detcd-master-1 1/1 Running 2 10dkube-apiserver-master -1 1 Running 2 10dkube-controller-manager-master-1 1 Running 2 10dkube-flannel-ds-amd64-df7gk 1 Running 3 9dkube-flannel-ds-amd64-dzxfd 1 9dkube-flannel-ds-amd64-dzxfd 1 Running 3 9dkube-flannel-ds-amd64-mgw2m 1 Running 2 9dkube-proxy-47d6q 1 10dkube-scheduler-master-1 1 Running 2 10dkube-proxy-jztrs 1 Running 3 10dkube-proxy-rt4xx 1 Running 3 10dkube-scheduler-master-1 1 Running 2 10dkubernetes- Dashboard-5f7b999d65-8h79h 1bat 1 Running 0 21h

3 create a space for two experiments

Kubectl create namespace shengchankubectl create namespace test

4 create a network rule test

Default ingress and engress can be used together When these two rules exist at the same time, then use policyTypes as a specific rule to point to, for example: create a policy to reject all inbound rules in space shengchan by default # cat ingress-deny.yamlapiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: deny-all-ingress namespace: shengchanspec: podSelector: {} policyTypes:-Ingresskubectl apply ingress-deny.yaml create a set of pod# cat pod-networkpolicy1.yaml apiVersion: v1kind: Podmetadata: name that belongs to shengchan space : pod-testspec: containers:-name: pod-test-policy image: nginx:1.10kubectl apply-f pod-networkpolicy1.yaml-n shengchan create a group of podkubectl apply-f pod-networkpolicy1.yaml-n test belonging to test space to view the IP addresses of the two groups of pod # kubectl get pods-o wide-n shengchanNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESpod-test 1max 1 Running 0 16s 10.244.1.2 node2 [root@master-1 ~] # kubectl get pods-o wide-n testNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESpod-test 1 Running 09s 10.244.2.2 node1 ping these two ip# ping 10.244.1.2-c 1PING 10 respectively on the host .244.1.2 (10.244.1.2) 56 (84) bytes of data ^ C-10.244.1.2 ping statistics-1 packets transmitted 0 received, 100% packet loss, time 0ms# ping 10.244.2.2-c 1PING 10.244.2.2 (10.244.2.2) 56 (84) bytes of data.64 bytes from 10.244.2.2: icmp_seq=1 ttl=63 time=0.660 ms--- 10.244.2.2 ping statistics-1 packets transmitted, 1 received, 0 packet loss Time 0msrtt min/avg/max/mdev = 0.660 ms. At this time, it is found that the pod belonging to shengchan space is denied access. Normal access to pod belonging to test space at this time we are based on the inbound network access policy at the namespace level

5 release the above default reject policy

Modify the configuration file apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: deny-all-ingress namespace: shengchanspec: podSelector: {} ingress:-{} policyTypes:-Ingresskubectl apply-f ingress-deny.yaml

Test 10.244.1.2 again

[root@master-1] # curl-I 10.244.1.2HTTP/1.1 200 OKServer: nginx/1.10.3Date: Sat, 27 Apr 2019 16:58:04 GMTContent-Type: text/htmlContent-Length: 612Last-Modified: Tue, 31 Jan 2017 15:01:11 GMTConnection: keep-aliveETag: "5890a6b7-2017" Accept-Ranges: bytes [root @ master-1 ~] # curl-I 10.244.2.2HTTP/1.1 200 OKServer: nginx/1.10.3Date: Sat 27 Apr 2019 16:58:07 GMTContent-Type: text/htmlContent-Length: 612Last-Modified: Tue, 31 Jan 2017 15:01:11 GMTConnection: keep-aliveETag: "5890a6b7-264" Accept-Ranges: bytes indicates that our network strategy has been released successfully

6 release specific inbound

Divide whether pod inbound rules are released in the form of tags

1) reply to reject all [root@master-1 ~] # cat ingress-deny.yaml apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: deny-all-ingress namespace: shengchanspec: podSelector: {} policyTypes:-Ingresskubectl apply-f ingress-deny.yaml2) label shengchan pod kubectl label pods pod-test app=hello-n shengchan3) create a new rule # vim ingress-allow.yml apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: allow -hello-ingress namespace: shengchanspec: podSelector: matchLabels: app: hello ingress:-from:-ipBlock: cidr: 10.244.0.0 except 16 except:-10.244.2.2 32 ports:-protocol: TCP port: 80 explanation: we have redefined a policy Define ingres rules by matching tags to our existing pod (our existing pod denies all access) If it is not defined by from, by default, all network segments can access the pod with this tag. In order to test, we use from to reject 10.244.0.0 but will release 10.244.2.2 because we have this ip pod to create ten thousand ports. Ports is to specify a specific open port. 4) access testing before creation # kubectl get pods-n shengchan-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESpod-test 1 Running 0 62m 10.244.1.2 node2 # curl 10.244.1.2 5) Test kubectl apply-f ingress-allow.yml [root@master-1 ~] # curl-I 10.244.1.2HTTP/1.1 200 OKServer: nginx/1.10.3Date: Sat after creation 27 Apr 2019 17:32:15 GMTContent-Type: text/htmlContent-Length: 612Last-Modified: Tue, 31 Jan 2017 15:01:11 GMTConnection: keep-aliveETag: "5890a6b7-2017" Accept-Ranges: bytes indicates that it has been released. If you are interested in the restriction of 10.244.0.0 network segment, you can test it.

6 egress outbound rules

1) set a deny all outbound policycat egress.ymlapiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: deny-all-egress namespace: testspec: podSelector: {} policyTypes:-Egresskubectl apply-f egress.yml2) create a podskubectl apply-f pod-networkpolicy1.yaml-n test3 under the test namespace) View podIP and enter the container to test ping a normal podip [root @ master-1 ~] # kubectl get pods-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnet-test-5764c456cb-2c9df 1 Running 24 24 24 10.244.2.22 node1 net-test-5764c456cb-ng6vh 1 Running 46 6d5h 10.244.1.21 node2 [root@master-1] # kubectl get pods-o wide-n testNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESpod-test 1 Running 086m 10.244.2.2 node1 kubectl exec-it pod-test-n test-/ bin/bashroot@pod-test:/# ping 10.244.1.21PING 10.244.1.21 (10.244.1.21): 56 data bytes ^ C-- 10.244.1.21 ping statistics-3 packets transmitted 0 packets received 100% packet loss indicates that the policy has been applied at this time. 4) modify the configuration file to release all outbound # cat egress.yml apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: deny-all-egress namespace: podSelector: {} egress:-{} policyTypes:-Egresskubectl apply-f egress.yml Test: root@pod-test:/# ping 10.244.1.21-c 1PING 10.244.1.21 (10.244.1.21) ): 56 data bytes64 bytes from 10.244.1.21: icmp_seq=0 ttl=62 time=0.939 ms--- 10.244.1.21 ping statistics-1 packets transmitted 1 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.939 packet lossround-trip min/avg/max/stddev 0.939 Universe 0.000 ms means the release has been successful.

7 more complex policy rules need to be explored in depth according to different environmental plans, all of which are reflected in the configuration file

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report