There are a variety of reasons that a chief information officer might want to move his IT infrastructure to containers. Moving to smaller granularity makes it easier to build microservices. Layered software pieces are easier to swap out. And containers offer scale-out of resources based on demand. But perhaps the biggest reason is that Kubernetes provides a pre-defined container management system.

“With containers the interesting part is not the container itself, it’s the Kubernetes that comes with it,” said Nicolas Thomas, a systems engineer at Fortinet. “Kubernetes was initiated by Google. It comes with an operational model. People, if they know Kubernetes, can operate any workload.”

This is especially helpful to eliminate a lot of the friction between developers and operators. “Developers only need to come up with the model for the container,” said Thomas. “And they don’t have to care about how it’s managed, upgraded, scaled. Both teams love that. Then developers just have to focus on their functions, and operators will understand how to operate them because they have a model.”

But there are still obstacles to plunging headfirst into containers. Jonathan Bryce, executive director with the OpenStack Foundation, recently explained one major issue to SDxCentral. “To date, most containers are running in VMs,” said Bryce. “In a lot of cases there’s a desire to have higher levels of isolation and security that virtualization can provide.”

Thomas agreed that containers lack isolation. He said, ideally, applications will be developed for containers from the get-go. “It’s a lot of engineering of the application to take all the benefits of moving to Kubernetes and containers,” he said. “The important part is to architect the application to benefit from the scalability of Kubernetes.”

Apparently, some customers have been asking Fortinet to provide them with the firewalls they’re accustomed to, but as a container. “That is not a good idea today,” said Thomas. “My job as a firewall is to protect. You have no isolation.” Fortinet does however provide a web application firewall in a container. “We address that from the network because we have APIs and understand Kubernetes,” he said.

The Kata Containers open source project is working to bridge the security gaps between VMs and containers. The platform provides greater isolation for containers by running a dedicated kernel within each container as opposed to the standard container practice of sharing a kernel between multiple containers. Kata Containers may provide security vendors like Fortinet with the isolation it needs.

Recently, a panel of service providers discussed the implementation of management and network orchestration (MANO) software into their networks. And one of the panelists suggested that a cloud-native, container-based architecture orchestrated by Kubernetes had the potential to negate the need for MANO.

“It’s controversial and remains to be seen,” said Bryce Mitchell, the director of NFV at Canadian service provider Telus. “But there’s an argument that if you have good integrated CI/CD and something like Kubernetes to orchestrate it, you may not need MANO.”

Thomas was taken aback by that idea. “The cloud by design is multi-tenant,” he said. “The Kubernetes environment, by definition, is one user. You would need to containerize everything and rely on the LSO. When we started ETSI NFV, they saw it as a huge orchestrator for all networks and all the different elements. Whereas a model with Kubernetes would be completely different. There is some fundamental mismatch.”