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

All relevant links to this article pdf: https://163.53.94.133/assets/uploads/files/tf-ceg-case3.pdf

The Kubernetes namespace is a built-in way to "virtualize" Kubernetes clusters. Although no one has yet discussed how and where to use namespaces, cluster virtualization cannot be completed without network-wide namespace isolation.

The Tungsten Fabric Kubernetes CNI plug-in includes support for isolated namespaces. An application deployed in an isolated namespace cannot access any Pod outside its namespace, and applications in other namespaces cannot access its Pod and Services.

Working with scen

One way to deploy Kubernetes is for each development team to deploy a separate Kubernetes cluster, in which case cluster virtualization and namespace isolation have little benefit.

However, because the unused capacity is fragmented, this method can lead to inefficient use of resources. Each cluster has its own available capacity, which cannot be used by applications running in other clusters. In addition, as the number of clusters increases, it introduces the operational overhead needed to maintain unity. Finally, it takes time to start a new cluster, which may slow things down.

Namespaces are a good way to solve these problems because they help reduce the number of clusters, share spare capacity, and can be created quickly. This also provides a level of isolation where the infrastructure team is responsible for managing the cluster while each developer team operates in its own namespace.

There are three issues that need to be addressed when dealing with cluster virtualization:

(1) who can access the virtual cluster (RBAC)

(2) how many computing resources can be used by each virtual cluster

(3) which network communications are allowed by the applications in the virtual cluster.

The Tungsten Fabric CNI plug-in for Kubernetes is designed to solve the problem (3) through the namespace isolation discussed in this section and the network policies described in the next section. This is particularly useful from a compliance perspective. PCI compliance is a good example because it encourages workload isolation.

When looking to achieve PCI compliance, one of the areas of focus is narrowing. The purpose of the narrowing is to isolate all systems that may affect the processing of credit card information, known as the Cardholder data Environment (Cardholder Data Environment,CDE).

Any workload or device can interact with a system that belongs to CDE in any way. Network segmentation is critical to achieving the isolation required to reduce the number of systems considered for PCI compliance.

The Kubernetes namespace and the underlying containerized platform Kubernetes choreographer provide the compute isolation required to reduce the PCI scope of containerized workloads. Kubernetes also provides part of the solution for storage isolation. However, Kubernetes currently does not provide sufficient network isolation or inspection for this purpose.

The Tungsten Fabric CNI plug-in for Kubernetes not only provides network isolation for Kubernetes-aware namespaces, but also enables the management team to inspect all network traffic entering or leaving the namespace by controlling the traffic of Network functional Virtualization (NFV) instances. This makes it possible to adjust the level of data flow inspection according to the requirements of the type of traffic that must be allowed in and out of the quarantined CDE.

Let's look at an example of network isolation using the Kubernetes namespace. In this use case, we will deploy two copies of the sample application, one in the default namespace and the other in a new isolated namespace. Then we will see how Tungsten Fabric implements network traffic isolation, as shown in the following figure:

Add isolated namespaces

Before we begin, it is necessary to take a quick look at the Kubernetes documentation page, which explains how to use namespaces, including the commands we need to know.

When all is done, make sure that you are on the sandbox control node, logged in as root, and in the correct directory:

# confirm that you are a root account

Whoami | grep root | | sudo-s

# switch to inventory directory

Cd / home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml

Next, create a new listing to describe our new isolation namespace:

This creates a file called dev-isolated.yaml, which includes the above. Note the annotations section-- this will tell Tungsten Fabric to isolate the new namespace.

Continue to create the namespace and add relevant content to the Kubernetes configuration file so that we can access it:

# create a new namespace:

Kubectl create-f dev-isolated.yaml

Let's take a quick look at the new namespace:

Note the Annotations field; this signals to the Tungsten Fabric CNI plug-in that it needs to treat this namespace differently.

Can we simply add this comment to the existing namespace to isolate it? Unfortunately not, because Tungsten has to do a lot of extra work to set up a new isolated namespace. More specifically, a separate set of virtual networks must be created to which the application Pod in this namespace will connect.

This ensures that network isolation is maintained at the underlying level, rather than simply through weaker methods such as traffic filters.

Deploy the sample application to an isolated namespace

Next, we deploy the sample application to the isolation namespace that we have created:

Kubectl create-- namespace dev-isolated-f cnawebapp-loadbalancer.yaml

Once the application pod starts, we should be able to access our application from Internet as described in use case 1 above.

Next, we need something to compare and compare; therefore, deploy another copy of the sample application to the default namespace:

Kubectl create-f cnawebapp-loadbalancer.yaml

Now, we have two copies of the application. One runs in the unisolated default namespace and the other runs in the dev-isolated namespace.

The behaviors we expect are:

1. Pod and services in non-isolated namespaces should be accessible from other Pod in non-isolated namespaces, such as default and kube-system

two。 Services in non-isolated namespaces should be accessible from Pod running in isolated namespaces

3. Isolates Pod and services in the namespace and can only be accessed from Pod in the same namespace

4. There is an exception to the above: LoadBalancer's services in an isolated namespace can be accessed by the outside world.

We will verify these behaviors one by one.

Pod in non-isolated namespaces should be able to communicate with each other

We know that Pod can communicate with services in the default namespace-- that's how the sample application works. But what about across namespaces?

Because we are in a sandbox, we can use a Pod in the kube-system namespace to try to access Pods and Services in applications running in the default non-isolated namespace:

# get the name of tiller-deploy in kube-system pods:

Src_pod=$ (kubectl get pods-- namespace kube-system | grep tiller | awk'{print $1}')

# find the IP of "yelb-ui" pod in the "default" namespace:

Dst_pod_ip=$ (kubectl get pods-o wide | grep yelb-ui | awk'{print $6}')

# Let tiller-deploy go to ping yelb-ui:

Kubectl exec-- namespace kube-system-it ${src_pod} ping ${dst_pod_ip}

The output of the last command should look like this:

PING 10.47.255.246 (10.47.255.246): 56 data bytes

64 bytes from 10.47.255.246: seq=0 ttl=63 time=1.291 ms

64 bytes from 10.47.255.246: seq=1 ttl=63 time=0.576 ms

Cancel the command with ^ C.

This confirms that Pod in non-isolated namespaces can reach each other.

Quarantined Pod should be able to reach non-quarantined services

# get the cluster IP address of the "yelb-ui" service running in the "default" namespace:

Default_yelb_ui_ip=$ (kubectl get svc-- namespace default-o wide | grep yelb-ui | awk'{print $3'})

# get the name of the "yelb-appserver" Pod of the "dev-isolated" namespace

Src_pod2=$ (kubectl get pods-- namespace dev-isolated | grep yelb-appserver | awk'{print $1}')

# run "curl" in "yelb-appserver" and try to access the service IP of the "default" namespace:

Kubectl exec-it-n dev-isolated ${src_pod2}-/ usr/bin/curl http://${default_yelb_ui_ip}

We should see about 10 lines of HTML code on the yelb-ui home page, indicating that Pod in the dev-isolated namespace can communicate with services in the unisolated default namespace.

Pod in isolated namespaces cannot be accessed from other namespaces

Now, let's try to ping the yelb-ui Pod running in the dev-isolated namespace from the same tiller-deploy Pod:

# get the IP of the "yelb-ui" pod in the "dev-isolated" namespace:

Isolated_pod_ip=$ (kubectl get pods-- namespace dev-isolated-o wide | grep yelb-ui | awk'{print $6}')

#.. Try ping it:

Kubectl exec-- namespace kube-system-it ${src_pod} ping ${isolated_pod_ip}

You should see that the command is "stuck" and does not show any response, because this time we are trying to reach some unreachable destinations, and Tungsten Fabric is blocking this access.

Press ^ C to cancel the command.

Try again-- try to ping isolated yelb Pods and services from yelb Pods in the default namespace. Is everything working as expected?

LoadBalancer services in the isolated namespace should be externally accessible

However, if we can't access it, it doesn't make much sense to run the application in an isolated namespace. Therefore, a yelb copy of this dev-isolated in a separate namespace should be made available to Internet through LoadBalancer Service yelb-ui. Let's test it:

Kubectl get svc-- namespace dev-isolated-o wide | grep yelb-ui | awk'{print $4}'

It should display results similar to afd9047c2915911e9b411026463a4a33-777914712.us-west-1.elb.amazonaws.com; point your browser to it and see if our application can be loaded!

Clear

Once you have done enough testing, you can clean up at any time:

# Delete two "yelb" copies:

Kubectl delete-f cnawebapp-loadbalancer.yaml

Kubectl delete-- namespace dev-isolated-f cnawebapp-loadbalancer.yaml

# Delete an independent namespace and its manifest:

Kubectl delete-f dev-isolated.yaml

Rm-f dev-isolated.yaml

Review and next step

The Kubernetes namespace has been designed as a way to virtualize Kubernetes clusters. Without the network, no virtualization is complete, and Tungsten Fabric's support for isolated namespaces provides this capability.

However, when you need to enforce application network security policies in namespaces, isolated namespaces may provide coarse granularity.

There are also some more elaborate controls, which we will cover in detail in the article in use case 4.

(the official account of "TF Chinese Community" will release other Carbide assessment guide articles one after another.)

END

MORE more TF+K8s 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

About Tungsten Fabric: the Tungsten Fabric project is an open source project protocol that is developed based on standard protocols and provides all the components necessary for network virtualization and network security. The components of the project include: SDN controller, virtual router, analysis engine, northbound API release, hardware integration functions, cloud orchestration software and extensive REST API.

About TF Chinese Community: TF Chinese Community is initiated spontaneously by a group of Chinese volunteers who pay attention to and love SDN. There are technical veterans, market veterans, industry experts and experienced users. It will serve as a bridge between the community and China, disseminate information, submit questions, organize activities, and unite all forces interested in the multi-cloud Internet to effectively solve the problems encountered in the process of cloud network construction.

Follow Wechat: TF Chinese Community

Mailbox: tfzw001@163.com

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.