Cisco Debuts Its Own Kubernetes Container Platform

Cisco is getting deeper into the container world with the announcement on Jan. 31 that the company is building its own Cisco Container platform. The new platform is based on the open-source upstream Kubernetes container orchestration platform.

The Cisco Container Platform will initially be available in April for Cisco’s Hyperflex server system architecture, with a plan to add support for bare metal set to follow. The Cisco Container Platform adds Cisco’s own control plane services on top of Kubernetes to enable what the company aims to be a turnkey deployment model.

Sanjeev Rampal, Principal Engineer at Cisco, explained to ServerWatch that the plan is to have the Cisco Container Platform follow the upstream Kubernetes releases in an “N-1” cadence. The current most recent release of Kubernetes is version 1.9, with a 1.10 update expected to debut by March.

“We’re aiming to have one new release per quarter, ” Rampal said.

Kubernetes deployments tend to default to using the Docker container runtime, but thanks to the recently released Container Runtime Interface (CRI) support in Kubernetes, there are other choices now as well. Rampal said Cisco will be running with some of the same technology choices Google has made for its own Kubernetes deployment.

“Canonical produces a version of Ubuntu for Google and we will be using that same version,” Rampal said. “We’ll be using the Docker runtime and will follow the Canonical timeline for any engine change.”

A core part of a production Kubernetes deployment is also having some mechanism to easily deploy applications. Among the most common approaches today is to use Helm charts, but that’s not necessarily the only direction Cisco will be taking.

Cisco has its own Cloud Center technology that will be integrated with a future Cisco Container platform update. Jeremy Oakey, Director of Product Management at Cisco, explained that with Cisco Cloud Center an organization can model a cloud workload once and then deploy it anywhere.

“Cloud Center has the concept of application repositories and governance capabilities,” Oakey said.

Rampal added that Cisco will also integrate its Contiv networking and hyperflex storage capabilities with its container platform.

Role-Based Access Control Integration

Another core area that typically requires configuration in Kubernetes is Role-Based Access Control (RBAC) integration as well as secrets management for service tokens and passwords.

“We are initially starting off with an un-opinionated Kubernetes cluster,” Rampal said. “So for example, we’ll have RBAC on the control plane but we don’t initially enforce any RBAC on the data plane.”

Rampal explained that the plan is to get some feedback from an initial set of users to see how much RBAC configuration is needed. For secrets management, the initial release will use the standard default Kubernetes secrets management capability. Rampal added that Cisco is looking at other options for future releases, including the open-source Vault technology that is being developed by Hashicorp.

In terms of analytics and monitoring, the initial release will make use of the open-source Prometheus project, which, like Kubernetes, is also run as a Cloud Native Computing Foundation (CNCF) project. Oakey added that Cisco will also enable its AppDynamics technology to help support application performance monitoring on Kubernetes.

Vs. Docker

Cisco’s new Container Platform is not the company’s first foray into the world of containers. In March 2017, Cisco entered into a strategic alliance with Docker Inc that includes sales and engineering support for running Docker on Cisco’s server hardware.

The new Cisco Container Platform is not seen by Cisco as an attempt to displace Docker.

“We view this as an extension to the other container relationships we have,” David Cope, Senior Director, Cloud Products and Solutions Market Development at Cisco, told ServerWatch

Sean Michael Kerner is a senior editor at ServerWatch and InternetNews.com. Follow him on Twitter @TechJournalist.