Welcome to the Tungsten Fabric Carbide Evaluation Guide (CEG)

What is this Guide for?

This guide is designed for application developer or a compute infrastructure platform engineer considering their options for Kubernetes networking, with specific focus on Tungsten Fabric Carbide.

Kubernetes Cluster Networking functions are central to applications running on top of Kubernetes. These functions include:

To do the above, Kubernetes cluster must have a Container Network Interface (“CNI”) plugin installed. Kubernetes documentation web site lists a number of options, Tungsten Fabric being the one we cover in this document.

We will use a sample 3-tier application to go through the three main function areas listed above, and explain what Tungsten Fabric does in each of the cases. Where Tungsten Fabric provides extra functionality beyond Kubernetes baseline, we will also say so.

To follow along with our use cases, you should deploy your own copy of a Quick Start of Tungsten Fabric (“TF”) Carbide with Kubernetes (“K8s”) on AWS.


This guide assumes that you are comfortable with how to:

Introduction to our sample app

To demonstrate how Tungsten Fabric can help us get an application running, accessible from the Internet, and then secured, we will use the mock application called “yelb”. It was written and is maintained by one of the Developer Advocates at AWS. The reason for choosing this application is that it is simple, well-documented, and is ready to run on Kubernetes.

Please see the “Yelb Architecture” link for more detail, but at the high level it looks like this:


(Original image URL: https://github.com/mreferre/yelb/raw/master/yelb-architecture.png)

The application is made of four Deployments:yelb-ui, yelb-appserver, yelb-db and yelb-cache. Each Deployment is fronted by a respective Kubernetes Service. The yelb-ui Service can also be fronted by Kubernetes Ingress, providing you with L7 HTTP routing.

Getting ready

For our exercises, we will need to have the following in place:

Access our Kubernetes cluster

If you followed the steps in Tungsten Fabric Carbide Quick Start on AWS guide, you should be able to log in into your QuickStart sandbox control node as described in the Accessing the Cluster section of the guide. To find out the public DNS host name of your sandbox control node, look in the Outputs tab of the AWS CloudFormation UI for the template you used to deploy Kubernetes with Tungsten Fabric Carbide:


Once on the sandbox control node, run:

sudo -s
kubectl get nodes

which should display output similar to:

NAME                                         STATUS     ROLES     AGE       VERSION
ip-172-25-1-105.us-west-1.compute.internal   NotReady   master    1m        v1.9.2
ip-172-25-1-146.us-west-1.compute.internal   Ready      <none>    1m        v1.9.2
ip-172-25-1-202.us-west-1.compute.internal   Ready      <none>    1m        v1.9.2

Get a copy of yelb application

After you’ve successfully connected to the sandbox control node and verified that your kubectl works correctly, use the following commands to get a copy of yelb and change your working directory to the one with its Kubernetes manifests (while running as root):

# Install git
yum -y install git

# Clone the Yelb repo and checkout the branch we used for this guide
git clone https://github.com/mreferre/yelb
cd yelb
git checkout 9cba442 # to make sure our examples keep working as yelb evolves

# Change to the manifests directory
cd deployments/platformdeployment/Kubernetes/yaml/

What’s next

At this point, you have a functional sandbox Kubernetes cluster with 2 compute nodes and an application that you can use to play around. The rest of this document will walk you through examples of how to deal with a few common scenarios around networking and network security that you can encounter when developing and operating an application that runs on Kubernetes.

Each use case is stand-alone, and does not require you to complete any other use cases in this document.

Feel free to jump to any one as you see fit:

  1. Basic app connectivity through Kubernetes’ Services
  2. Advanced external app connectivity through Kubernetes’ Ingress
  3. Coarse application isolation through Kubernetes Namespaces
  4. Application micro-segmentation through Kubernetes Network Policies