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:
- Network communications between Pods through Services;
- Network communications between the outside world and externally-facing Services; and
- Network policies that provide fine-grained control over what network communication flows are allowed.
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:
- Deploy a CloudFormation template into your AWS account;
- Connect to an EC2 instance in AWS with an SSH client and SSH private key;
- Deploy applications to Kubernetes using
- Use Linux CLI/terminal tools, like
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-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.
For our exercises, we will need to have the following in place:
- Access to our Kubernetes cluster with Tungsten Fabric through Kubernetes’
kubectlCLI tool; and
- A copy of yelb
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/
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: