This article all links pdf: https://163.53.94.133/assets/uploads/files/tf-ceg-case3.pdf
Kubernetes namespace is a "virtual" way Kubernetes a built cluster. While there are no people to discuss how to use the namespace and the use of namespaces where, but if no namespace isolation within the scope of the network, Virtual Clusters will not be completed.
Tungsten Fabric Kubernetes CNI plug-in includes support for isolated namespace. Deployed to the application namespace in isolation can not access any Pod outside their namespace, other applications can not access the namespace and its Pod Services.
scenes to be used
A method of deploying Kubernetes, each development team is deploying a separate Kubernetes cluster, in this case, a cluster virtualization and namespace isolation almost no benefit.
However, because the unused capacity is fragmented, which may result in low resource use efficiency. Each cluster has its own available capacity, other applications running in the cluster can not use the available capacity. In addition, as the number of clusters, it introduces operational overhead required to maintain unity. Finally, it takes time to start a new cluster, which may make things slower.
Namespace is a good way to solve these problems, because it helps reduce the number of clusters, sharing spare capacity and can be quickly created. It can also provide a level of isolation, infrastructure team will be responsible for managing the cluster, and each team of developers is to operate in their own namespace.
When processing cluster virtualization, the need to solve three problems:
(1) Who can access the virtual cluster (RBAC);
(2) how much each virtual cluster can use computing resources;
(3) a web application which allows the virtual cluster communication.
Tungsten Fabric CNI plug-in for Kubernetes aimed namespace by this section will be discussed in isolation, and the next section will introduce the network policy to solve the problem (3). From the perspective of regulatory compliance point of view, this is particularly useful. PCI compliance is a good example, because it encourages workload isolation.
When seeking to achieve PCI compliance, one of the areas of focus is narrow. Narrow purpose is to isolate all the system may affect the processing of credit card information, which are called "cardholder data environment" (Cardholder Data Environment, CDE).
Any workload or equipment, can in any way belong to the CDE system interact. Network segment of crucial importance for the required isolation, the system to reduce the number of the PCI compliance considerations.
Kubernetes namespace container base and platform Kubernetes organizer, the container may be provided to reduce the range of PCI workloads calculate the required isolation. Kubernetes also provides an isolated part about storage solutions. However, Kubernetes not currently provide sufficient network isolation or check for this purpose.
Tungsten Fabric CNI plug-in for Kubernetes not only provides Kubernetes namespace-aware network isolation function also enables the management team by controlling network functions virtualization (NFV) to check all instances of traffic entering or leaving the namespace of network traffic. This makes possible the following case is called: the request must be allowed out of the CDE isolated communication type, the data stream to adjust the level of checking.
Let's look at an example Kubernetes namespace to use network isolation. In this case two copies, we will deploy the sample application, deployed to a copy of the default namespace, another deployment to a new isolation namespace. Then, we will see how to isolate network traffic Tungsten Fabric embodiment, as shown below:
Add namespace isolation
Before you begin, it is necessary to quickly browse Kubernetes document page that explains how to use namespaces, including our need to know the command.
After the completion of all, make sure you are on the sandbox control node, log in as root, and in the correct directory:
#确认您是root账户
whoami | grep root || sudo -s
#切换到清单目录
cd /home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml
接下来，创建一个新清单，以描述我们新的隔离命名空间：
这将创建一个名为dev-isolated.yaml的文件，它包括以上内容。请注意annotations部分——这将告诉Tungsten Fabric隔离新的命名空间。
继续创建该命名空间，并向Kubernetes配置文件添加相关内容，以便我们可以访问它：
#创建新的命名空间：
kubectl create -f dev-isolated.yaml
让我们快速浏览一下新的命名空间：
注意Annotations字段；这向Tungsten Fabric CNI插件发出信号，它需要以不同的方式对待此命名空间。
我们可以简单地将此注释添加到现有命名空间以使其隔离吗？不幸的是没有，因为Tungsten必须做很多额外的工作才能设置一个隔离的新命名空间。更具体地说，必须创建一组单独的虚拟网络，此命名空间中的应用程序Pod将连接到该虚拟网络。
这样可以确保将网络隔离保持在底层水平上，而不是简单地通过流量过滤器之类的较弱方法。
将示例应用程序部署到隔离的命名空间中
接下来，我们将示例应用程序部署到已创建的隔离命名空间中：
kubectl create --namespace dev-isolated -f cnawebapp-loadbalancer.yaml
一旦应用程序pod启动，我们应该能够像上面用例1中所描述的那样从Internet访问我们的应用程序。
接下来，我们需要一些东西进行比较和对比；因此，将示例应用程序的另一个副本部署到default命名空间中：
kubectl create -f cnawebapp-loadbalancer.yaml
现在，我们有两个应用程序副本。一个在没有隔离的default命名空间中运行，另一个在dev-isolated命名空间中运行。
我们期望的行为有：
1.非隔离命名空间中的Pod和服务，应该可以从非隔离命名空间中的其他Pod（例如default和kube-system）访问；
2.非隔离命名空间中的服务，应该可以从隔离命名空间中运行的Pod访问；
3.隔离命名空间中的Pod和服务，只能从相同命名空间中的Pod访问；
4.对于以上的情况有个例外：在隔离的命名空间里的LoadBalancer的服务可以被外部世界访问。
我们将逐个验证这些行为。
非隔离命名空间中的Pod应该能够相互通信
我们知道Pod可以与在default命名空间中的服务通信——这就是示例应用程序的工作方式。但是跨命名空间呢？由于我们位于沙箱中，因此可以使用kube-system命名空间中的一个Pod来尝试访问在default非隔离命名空间中运行的应用程序中的Pods和Services ：
#获得kube-system pods里的tiller-deploy的名字：
src_pod=$(kubectl get pods --namespace kube-system | grep tiller | awk '{print $1}')
#找到“default”命名空间里的“yelb-ui”pod的IP：
dst_pod_ip=$(kubectl get pods -o wide | grep yelb-ui | awk '{print $6}')
#让tiller-deploy去ping yelb-ui：
kubectl exec --namespace kube-system -it ${src_pod} ping ${dst_pod_ip}
最后一条命令的输出应类似于：
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
用^ C取消命令。
这确认了非隔离命名空间中的Pod可以相互到达。
隔离的Pod应该能够到达非隔离的服务
#获得运行在“default”命名空间里的“yelb-ui”服务的集群IP地址：
default_yelb_ui_ip=$(kubectl get svc --namespace default -o wide | grep yelb-ui | awk '{print $3'})
#获得"dev-isolated" 命名空间的"yelb-appserver" Pod的名字
src_pod2=$(kubectl get pods --namespace dev-isolated | grep yelb-appserver | awk '{print $1}')
#在“yelb-appserver”运行“curl” ，尝试访问“default”命名空间的服务IP：
kubectl exec -it -n dev-isolated ${src_pod2} -- /usr/bin/curl http://${default_yelb_ui_ip}
我们应该在yelb-ui主页上看到大约10行HTML代码，这表明dev-isolated命名空间中的Pod 可以与非隔离default命名空间中的服务通信。
隔离命名空间中的Pod不能从其他命名空间访问
现在，让我们尝试从同一个tiller-deploy Pod去ping 运行在dev-isolated命名空间的yelb-ui Pod：
#获得位于“dev-isolated”命名空间的“yelb-ui”pod 的IP：
isolated_pod_ip=$(kubectl get pods --namespace dev-isolated -o wide | grep yelb-ui | awk '{print $6}')
#..尝试ping它：
kubectl exec --namespace kube-system -it ${src_pod} ping ${isolated_pod_ip}
您应该看到该命令被“卡住”了，没有显示任何响应，因为这次我们正尝试达到某些无法达到的目的地，Tungsten Fabric正在阻止这一访问。
按^ C取消命令。
再多试一下——尝试从位于default命名空间的yelb Pods去ping隔离的yelb Pods和服务。一切都按预期工作了吗？
隔离命名空间中的LoadBalancer服务应该可以在外部访问
但是，如果我们无法访问它，那么在一个隔离的命名空间中运行应用程序就没有多大意义了。因此，在独立命名空间本dev-isolated的yelb副本应通过LoadBalancer Service yelb-ui 供Internet使用。让我们测试一下：
kubectl get svc --namespace dev-isolated -o wide | grep yelb-ui | awk '{print $4}'
它应该显示类似afd9047c2915911e9b411026463a4a33-777914712.us-west-1.elb.amazonaws.com 的结果；将您的浏览器指向它，看看我们的应用程序是否可被加载！
清理
一旦进行了足够的测试，可以随时清理：
#删除两个“yelb”副本：
kubectl delete -f cnawebapp-loadbalancer.yaml
kubectl delete --namespace dev-isolated -f cnawebapp-loadbalancer.yaml
#删除独立的命名空间和它的清单：
kubectl delete -f dev-isolated.yaml
rm -f dev-isolated.yaml
回顾和下一步
Kubernetes命名空间已被设计为虚拟化Kubernetes集群的一种方式。没有网络，任何虚拟化都是不完整的，而Tungsten Fabric对隔离命名空间的支持提供了此功能。
但是，在您需要在命名空间中实施应用程序网络安全策略时，隔离的命名空间提供的粒度可能较粗。
也有一些更精细的控件，我们将在用例4的文章中进行详细介绍。
Fabric About Tungsten:
Tungsten Fabric project is an open source project agreement, which is based on a standard protocol development, and provides all the components of the network virtualization and network security essential. Components of the project include: SDN controller, virtual router, the analysis engine, to the north of the API release, hardware integration, cloud orchestration software and extensive REST API.
About Chinese community TF:
TF Chinese community spontaneously initiated by China's concern and love SDN group of volunteers, skilled veterans, old and gun market, there are industry experts and experienced users. And China will serve as a bridge connecting the community, dissemination of information, to submit questions, organize activities, unite all forces interested in the Internet cloudy, effectively solve the problem of cloud networking encountered in the process.
Focus on micro letter: TF Chinese community 