Get the Guide - KUBaM: Kubernetes on Cisco UCS made easy! As you have seen from the Part 1 post, Cisco UCS can bring a lot of value to a Contianer Cluster environment which can prove of immense value as it's crazy to acknowledge, but landing the operating system on bare metal servers in alignment with the required customization, has proven to be none trivial for many years now! So now you have the operating system installed in a consistant fashion, how do you drop on the associated packages, configuration files and clustering technology itself? This is where the UCS integrations prove to be of great value and it's these we will dive into now! If we look at the whole flow including the creation of the web server in Part 1 of this blog, it looks something like the following: Installing Kubernetes on UCS programatically Setting up the web server (this is a manual operation today but we are in the process of automating this part) The UCS Python SDK being used to setup the UCS in a PXEless way Ansible used to customize the CentOS operating system and deploy Kubernetes (which in turn uses Docker) and the contianer networking solution, Contiv. So let's have a further look at some of these components and how the made the whole process easy. Cisco UCS Python SDK The Cisco UCS Python SDK was used extensively in our project as it is fully featured, well documented and supported via a slack community. It provides Python language bindings to interface with Cisco UCSM APIs for CRUD operations.  As every UCS managed object type is abstracted as a python class it offers better code Writing/Reading experience by specifying the objects directly for building out the Kubernetes environment. One valuable feature to point out is the “convert_to_ucs_python” tool which helps in code development by generating python script as it captures operations done within the UI, and converting it to code. Using this tool, relevant code can be generated without being an expert in the UCS API model. The SDK has sample code packaged and auto-generation of API reference documentation which along with the Slack Support assist with the learning curve. For more info follow the link: -https://communities.cisco.com/docs/DOC-64378 and for the code https://github.com/CiscoUcs/ucsmsdk/ Ansible for UCS Much of the Ansible playbooks and Python scripts were hand crafted for our project as the team had the skills to do this and was a straight forward process due to the UCSM API model but it was clear that Cisco provided ansible modules would be appreciated to further simplyfy the process. The good news is these modules are now available and will be used in future iterations of deploying contianer tech on UCS as you can now use Ansible for configuration management, deployment, and orchestration of Cisco UCS servers, storage, fabric, hyperconverged infrastructure and converged infrastructure as well as Nexus switches. The new integration of Cisco UCS Manager and Ansible by Red Hat provides a software-defined approach to the management of the entire hardware and software stack. As a result, you to achieve faster build times, because the entire application stacks can be provisioned automatically. You can also automate UCS Manager policy, resource pool, and resource profile configuration and ongoing management including the ability to detect and remediate unintended changes. Further info can be found here: - https://communities.cisco.com/docs/DOC-73997 UCS Manager API Both the Absible and Python work was made possible to the highly appreciated UCS Manager API which has been around since the begining of the UCS journey. The UCSM was designed and implemented to model all of the UCS h/w aspects in s/w and make this fully programable via the mature and well documented XML based API. Due to this layer of abstration made avaiable for consumption by the API, we were able to effectively treat the h/w platform a Bare Metal as a Service as we could manipulate and consume it programatically thus automating most tasks. The use of a consistent object model and unified API resulted in simplicity writing scripts, and should aid even further when developing tools in a CI/CD process. Because the object model is consistent throughout any UCS deployment, you can learn the API once and apply it as the scope of what you are managing changes. For example, it can be programmed as low as the drive component or as high as the chassis level, and you can apply the investment you have made in learning the API as you move to other areas of infrastructure management. You simply add new objects at each level of infrastructure and scale—without the need to change the data model or software architecture. Its worth noting that the Python SDK takes advantage of this API but most (if not all) the actions could be achived by communicating directly to the API if so desired. With all of the UCSM functionality available via the API (over 2500 functions), which ever route is taken, there is enormous possibility to apply DevOps tools against UCS. For more information: - http://www.cisco.com/c/dam/en/us/products/collateral/servers-unified-computing/ucs-manager/sb-unifiedapi.pdf Contiv Container Networking and Policy Engine Cisco recently announced general availability of an open source project called Contiv and this we used within our project as it offered us a solid flexible networking and policy engine for Kubernetes. It has actually been around for some time now but we recently hardened it and added enterprise features such as LDAP integration and support for muliple contianer cluster managers such as Kuberntes, Docker Swarm and Mesos. Contiv provides both network connectivity and policy creation and enforcment. The connectivity options are impressive as they offer native L2/VLAN, VXLAN, L3 BGP and Cisco ACI topology support thus making it an enterprise option to accommodate most requirements. The policy aspect of Contiv delivers on container orientated use cases such as east-west connectivity and protocol security plus policy to control resource usage such as bandwidth. The policy model is based on Group Based Policy which is being rapidly adopted in the industry as it allows you to empower both the network admins and the developers to either define policy for consumption by others or for the end user to determine the security posture of their contianer based application upon instantiation. For more info: - http://contiv.github.io/ ... View more

Get the Guide - KUBaM: Kubernetes on Cisco UCS made easy! During a recent deployment of a Kuberenetes environment on Cisco UCS we noted that certain features of the UCS technology which provided unique server management abilities. These allowed us to consume the underlying infrastructure in a programmatic and abstracted fashion to deliver Bare Metal as a Service! It's probably worth sharing these with a wider audience so I will split these into two blog posts as we have so much to share! This first post will focus on the UCS Service Profile aspects with the following post (part 2) expanding on some of the UCS integrations such as the Python and Ansible SDKs plus accompanying container networking technology, Contiv. Cisco UCS Service Profiles Kubernetes is ultimately a cluster and with this comes the need to assure all of the cluster members are configured identically. UCS uses the concept of the Service Profile where a template of predefined configurations of components such as the network cards, storage connectivity setup, bios settings and many other elements are defined to provide a logical representation of a server. This ‘profile’ can be applied to multiple servers repeatedly thus assuring that the h/w configuration is consistent across the cluster and can be applied in a programmatic fashion. This facilitaes a DevOps methodology for provisioning and consuming the underlying cluster platform in an 'Infrastructure as Code' way. Consistant Device Naming One important requirement Container Clusters have is the need for Consistent Device Naming of the network connection configurations within all of the cluster hosts. When there is no mechanism for the base Operating System to label Ethernet interfaces in a consistent manner, it becomes difficult to manage network connections across the cluster and this aspect is crucial when assuring traceable connectivity during the cluster configuration stage and potential network troubleshooting. When Consistent Device Naming (CDN) functionality was introduced in Cisco UCS Manager Release 2.2(4), it allowed Ethernet Interfaces to be named in a persistent manner along with predicable nic placement and ordering within the target host Operating Systems which is key for cluster technologies to be robust. Kubernetes Networking needs all of the servers in the cluster to have consistent placement and naming and the Service Profile using CDN assures this and can be configured as per the image below using the UCSM GUI, or using the UCS Python SDK: Figure 1: KUBaM Consisyant Device Naming Setup Storage Profile To allow flexibility in defining the number of storage disks, roles and usage of these disks, plus other storage parameters, you can create Storage Profiles within UCS Manager. A storage profile encapsulates the storage requirements and is used for one or more service profiles as it specifies all of the storage requirements of a service profile. This feature allowed us to define a consistent storage configuration and was consumed via the service profile throughout the cluster giving us a known state in a programmatic fashion. It worth noting, without this feature it would take manual intervention of going into the raid tool of each server and verify the settings individually which is a tedious and time consuming job. Another advantage this storage profile approach gives us is we can see from a central management place, UCS Manager, where the storage profile has been applied successfully which greatly helps in the troubleshooting process. We use the storage profile to configure the following characteristics via storage policies: LUN count and size Raid level of the LUN Figure 2: KUBaM Storage Profile Setup Configure the number, type and role of disks in the disk group (via a defined Disk Group Configuration Policy) Figure 2: KUBaM Storage Policy Setup Once created, we associate the storage profile with a service profile template. This was achieved within the Python scripts constructed from the UCS Python SDK, and when the service profile is associated to a physical server, the logical LUNs are deployed as physical LUNs. vMedia duel Image/ISO loading capabilities PXE technologies are prevalent and successful throughout many enterprises but there are still considerations that will prevent an organization from adopting PXE for bare metal server deployment such as security concerns or network architectures. For these reasons, the unique ability of UCS to load multiple virtual media images to both deploy and customize the provisioning bare metal server may prove to be very appealing to many sys admins as they can now avoid the consequences of implementing PXE in their networks. The approach we took for this implementation was to create a pre-boot Linux environment as an ISO file, and supplement this with an image file containing the Linux kickstart file for defining the unique custom setting such as IP address and Hostname per server. This can (and will) be improved upon over time by automatically generating the kickstart files but this initial approach overcomes the need for PXE in the network which has great value. In order to consume these virtual configuration media artifacts, we use the vMedia capability in UCS Manager and the Service Profile as the mechanism to attach these images to the host servers as they cycle through the build process and all of this is done programmatically thanks to the rich UCS Python SDK. Figure 3: vMedia Policy Note: A web server for hosting the ISO and image files is required but the alignment of this this with the Service Profile is automated during the Python server build process to assure the correct configuration. If you would like to know more about our work around many of these aspects, check out KuBAM! OK, part 1 completed so onto part 2......... ... View more

Hi all, I'm running 3.1.1 hotfix 1(0) and trying to create a new VDC and I'm getting a failure when it tires to create a new Resource Pool in vCenter. The error message in CPO is : - 9027 New-ResourcePool  The operation is not supported on the object. Failure because the return code was none zero It's ESX and vSphere 5.1 Any thoughts please? Cheers md            ... View more