Over the last few months I've been writing posts about a simplified manner in which we can automate solutions on UCS called KUBAM. Everything we've done has been open and available on Github to solicit feedback and let the community know what we are doing. We haven't been super vocal about it though as the velocity of how it works has been changing extremely fast. We are, however, now to a point where the groundwork is laid and we can begin to broadcast the awesomeness of KUBAM. Please note that the documentation on the KUBAM website hasn't been updated yet to reflect this. This is a work in progress. If you have questions, want to get involved in helping, or get stuck testing, hit me up on twitter.
KUBAM aims to let your data center dance. We want the process of deploying solutions to UCS to be as simple and painless as possible. We want to remove any friction you may have with deploying a UCS solution. We can do this because of the following:
UCS has the most complete API of any server platform. With this obscene power, we can automate all aspects of it.
Container technologies have become more advanced to allow simple software provisioning and packaging. This means you can install complicated software using containers that work instantly. Dependency hell is not for you. That's for the past.
All solutions on UCS start with deploying an operating system. You might use VMware ESXi, Microsoft Windows, or your favorite distribution of Linux. This is the first problem we need to make painless. Up until now it hasn't been that awesome. It's not just UCS, its every bare metal server on the planet. You rationalize it though, by saying: "Well, we only do it once". But we think it should be different.
When you provision a machine instance on a cloud or virtual environment the process of installing an operating system is painless. It's built in. You go to the cloud providers website or use an API to accomplish this. For many people even this step is becoming unnecessary. As the industry move towards serverless architectures, deploying code on a runtime is the only thing you really care about. This is what we want to accomplish with KUBAM. A seamless experiences using advanced software to make these solutions possible. We're starting with the Operating System.
Last week we finished the first docker compose file that includes a front end web interface and an API. As of this blog post, you can download that, plug it into your environment and deploy CentOS 7.3 with lots more coming.
Here are the requirements to get started:
You have an existing UCS environment that has Fabric Interconnects that is connected to either blades or rack mount servers
You have a VM or machine running somewhere that has docker installed as well as docker-compose that can access the UCS. This can either run on UCS or be stand alone somewhere else in the data center. This will be the KUBAM node.
You have an ISO image of the required Operating system (CentOS Linux, etc) that is required for your solution.
That's basically it. We wanted to make the requirements and the friction as easy as possible. Now what do you do next to get running?
At that point you point your web browser to the IP address of the server you ran the docker compose command on. (You could even run this on your laptop!). The picture below is what KUBAM looks like:
As you can see the first thing it asks you is for the credentials and IP address of your UCS environment. Today KUBAM only handles one UCS domain. Once this is entered there are a few more easy steps.
KUBAM asks for the UCS VLAN that you wish to install over. This is the VLAN the servers will network boot from. This VLAN can have a DHCP server or other services running on it. KUBAM doesn't care. It won't interfere with any of these settings since KUBAM doesn't use DHCP nor mapped MAC addresses to deploy the solutions. KUBAM is a ninja. These networks can even be in production. KUBAM could care less.
In this menu KUBAM wants to know what network settings the newly provisioned operating systems will need. Netmask, DNS, and router information. We recommend DNS point to OpenDNS name servers 188.8.131.52. In this way you get even more security built in!
When all the network settings appear to be in place KUBAM wants to know which servers you would like to be provisioned. Here you select the UCS servers to place in the KUBAM pool. You are then instructed to give each server an IP address, operating system, and role of what solution should be installed on this server. KUBAM knows you hate typing IP addresses and sequential hostnames, so it tries to be intuitive by auto populating hostnames and IP addresses for you. Giddy Up!
Operating System and Deployment
Once the Operating system is extracted and boot images are created, you simply press "Deploy" and KUBAM goes to work. It creates service profiles automatically and maps the installation media using the automated vMedia policies. After waiting several minutes, your machines are ready to carry out your inner most desires. Want to run an app that controls drones? Create an ICO? Invent something entirely new? KUBAM is ok with that. It doesn't give it a single thought. It just does what you want and stays out of the way.
At present time KUBAM is pretty slow. The entire process can take about 25 minutes, including the time taken to download the docker images and deploy. KUBAM knows you don't like to wait. Fortunately for you there's no extra steps. You just hang out, grab coffee, or see if your crypto currency is increasing in value while it does it all for you. Once you press that "Deploy" button you do nothing else but wait. Soon, whether it be an automated ESX VSAN cluster or a brand new Kubernetes cluster it will be ready for you. It is the most simple way you could ever deploy a solution like this in your own datacenter. It is also a process we are constantly looking to further simplify and make life easier for UCS customers.
Under the Hood
KUBAM aims to inject so much lubrication into your data center that you will think you need to strap down your racks to the cage. KUBAM doesn't want you to even care about how it works but just know that it works, and works well. However, KUBAM understands that you are searching for answers and that you can handle the truth. That is one reason KUBAM is open source. KUBAM will give you the truth and not tell you to "stay tuned" nor wait any longer.
State for KUBAM is kept inside a mounted volume in the ~/kubam directory on the server where the containers run. A kubam.yaml file is automatically updated when the API server is called with certain POST requests. In this way, the KUBAM architecture could fit easily into a solution like Cisco Cloud Center, UCS Director, or Cisco Intersight. KUBAM aims to play nice with its fellow Cisco products.
KUBAM is an open source tool made to allow UCS systems to dance. KUBAM only supports UCS because only UCS has the APIs that are powerful enough to automate end to end datacenter solutions. KUBAM is looking to expand to other operating systems as well as other roles. At present KUBAM is working on the Kubernetes setup as well as ESXi with VSAN. ACI integration is on the roadmap as well. While these solutions are currently used by many of our customers today, KUBAM is also looking to deploy more forward looking solutions that might give a public cloud experience in your own UCS datacenter. KUBAM would love your input. Version one is rough and raw. KUBAM is scrappy, but is reacting and responding quickly.
Hello all,I have a quick question regarding BGP routing protocol. In our DataCenter we have Nexus7710 version 8.3(2), with N77-F348XP-23 line cards, and we are currently running OSPF. We would like to enable the BGP feature, in order to create BGP peering...
Design: ACI to physical Alteon LB connected over VPC VPC -Port-channel feature: PCP-ON Control : Fast select hot standby port, Graceful convergence, Suspend individual port Could you please let me know how we can avoid causing a MAC t...
Hi community,1. When using the topology with Cloud ACI using TGW to connect between infra and user VPC, does it mean the version of Cloud ACI has to be 5.x or later? Or does it mean the ACI On-premises it self has to be at version 5.x or later?My guess is...
Thanks for attending our ATXs sessions! Here’s the post-session resources for easy reference.
New to ATXs? An ATXs session, offered at no cost, is an hour of real-time learning led by Cisco experts, who will answer your technology questions through produ...