Shulou(Shulou.com)06/01 Report--

Author: Wu Mingmi

Hi! Welcome to the Tungsten Fabric and Kubernetes integration guide series, which describes the five steps you typically take to create a virtual network.

The Tungsten Fabric and K8s integration guide series, presented by the TF Chinese community, is designed to help you understand the basics of Tungsten Fabric and K8s integration. If you have any experience or problems in the relevant deployment, please feel free to contact us.

After you have deployed the architecture and confirmed that there are no problems with the initial state of the Tungsten Fabric and Kubernetes (K8s) clusters, you are ready to try to create a virtual network.

Step 1: create a new namespace

In K8s, most resources belong to one namespace, so you need to create a new namespace first, and then create the corresponding pod,service, as well as the virtual network. Create two new namespaces here, test-ns1 and test-ns2, and log in to the master node of K8s and execute the following command:

After the creation is successful, you can see the corresponding project created, k8s-test-ns1 and k8s-test-ns2 in the Tungsten Fabric management interface.

Step 2: create a new IPAM

You need to create an IP address management (IPAM) for your project, based on which to create a virtual network.

Select "Configure > Networking > IP Address Management" in the Tungsten Fabric administration interface, select project-k8s-test-ns1, and then click the create button.

Name and Subnet Method are required, and there are two ways for Subnet Method. User Defined specifies the subnet network segment manually when the network is bound, and Flat creates the subnet network segment directly. The difference between the two is that User Defined can specify the range of the IP pool, while Flat uses the entire subnet network segment directly. The default is to use Flat.

Step 3: create a new virtual network

Select Configure > Networking > Networks in the Tungsten Fabric administration interface, select k8s-test-ns1, and then click the create button.

As shown in the figure above, you have completed the creation of a virtual network, and then create another network k8s-ns1-pod-net2 in the same way (10.10.20.0) in order to facilitate testing.

Step 4: create a pod

First, create a pod on the namespace named test-ns1, specify the network as k8s-ns1-pod-net01, and configure it as follows:

Then create a pod based on the virtual network k8s-ns1-pod-net02, configured as follows:

After executing the create command of kubectl, both pod are created successfully, and the IP address of the container is:

Pod 10.10.10.1 that belongs to the virtual network k8s-ns1-pod-net01 (10.10.10.0.0)

Pod 10.10.20.1 belonging to the virtual network k8s-ns1-pod-net02 (10.10.20.0)

Step 5: network connectivity verification

1. Verify the network connectivity between pod networks that are not connected to the same namespace

First, mutual ping is performed to verify connectivity. The test results are as follows. Under the same namespace, the two networks cannot communicate by default.

If you need to communicate, you must add a router to Tungsten Fabric to connect the network k8s-ns1-pod-net01 and k8s-ns1-pod-net02, as follows:

After the router is created, the connectivity of the two networks is verified, and the result is that the two pod can communicate with each other.

2. Verify the network connectivity between pod and service under the same namespace.

By default, virtual networks other than k8s-default-pod-network cannot connect to the service network of K8s. Verify by requesting the coredns service in kube-system, and the command is nslookup kube-dns.kube-system. Because the domain name is resolved across namespaces, you need to add the namespace name suffix to the domain name (if pod is in kube-system, then nslookup kube-dns can be executed). The specific verification is as follows:

If you need to allow the pod of the k8s-ns1-pod-net01 network segment to access the service network of K8s, you need to add a Policies-k8s-default-service-np under the TF policy,k8s-default project. The specific policy rule is shown in the figure below, which means that all networks with this rule can have unlimited access to all ports of the service network of K8s.

Now you need to add the k8s-default-service-np policy to the network k8s-ns1-pod-net01 so that it can access the service network of K8s.

Configure-- > Networking-- > Networks, select the k8s-test-ns1 project, edit network k8s-ns1-pod-net01, and append a Network Policy-- k8s-default-service-np. The details are as follows:

Verify the network connectivity between pod and service again. At this time, pod nginx01-ns1-net01 (10.10.10.1) in network k8s-ns1-pod-net01 can resolve the domain name directly by requesting ClusterIP:PORT (coredns service) of service, while k8s-ns1-pod-net02 does not have k8s-default-service-np attached, so pod nginx01-ns1-net02 (10.10.20.1) still cannot access the coredns service in service.

3. Verify the network connectivity between pod under different namespaces.

The communication between two networks in the same namespace is different from that between two networks in different namespaces, because in the case of different namespaces, it is impossible to connect the two networks through the new TF Router, so the interworking between the two networks in different namespaces must be realized through TF Policy.

Two namespaces (test-ns1 and test-ns2) have been created in the previous steps, and there are already two networks in test-ns1, so you need to create a new network in test-ns2. The new network is k8s-ns2-pod-net01 (20.10.10.0.0).

By default, k8s-ns2-pod-net01 (20.10.10. 0) and k8s-ns1-pod-net01 (10.10.10. 0) and k8s-ns1-pod-net02 (10. 10. 20. 0) cannot communicate, so you now need to create two new pod in the network k8s-ns2-pod-net01 (20. 10. 10. 0. 0. 2).

Verify the network connectivity of pod nginx01-ns1-net01 and nginx01-ns2-net01. The two are in different namespaces and different network. The verification result is unable to communicate. For more information, please see the screenshot below:

If you need to enable the pod of these two different namespaces and different network to communicate with each other, you need to add the following TF Policies:

After the Contrial Network Policy is created, attach it to the network k8s-ns1-pod-net01 and k8s-ns2-pod-net01, respectively.

Verify again that two pod with different namespaces and different network have been able to communicate with each other.

(the writer is from Shenzhen Tianyuan Jingyun Technology Co., Ltd.)

Series of Tungsten Fabric+K8s Integration Guide articles--

Part 1: deployment preparation and initial state

Tungsten Fabric+K8s easy to use series of articles

Part I: TF Carbide Evaluation Guide-preparation

Part 2: basic application connections through Kubernetes services

Part 3: advanced external application connections through Kubernetes Ingress

Part IV: preliminary application isolation through Kubernetes namespaces

Part V: application differential Segmentation through Kubernetes Network Strategy

Follow Wechat: TF Chinese Community

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.