Project Calico Now Fully Supports Kubernetes
On Friday, Project Calico, an open source virtual networking stack, released its 1.0 version plugin for Kubernetes – a signal that the plugin been well-tested and ready for production, according to Andy Randall, the project’s lead evangelist.
“We’re seeing a lot of momentum around Kubernetes. So getting this 1.0 release out is going to signal that people can move from proofs of concept into deployment. It’s important for Project Calico, but the industry as a whole is just starting to adopt these solutions as more than just an experimental technology,” said Randall, who also is general manager of the networking business unit at sponsor company Metaswitch.
Project Calico aims to simply network at scale. A LAN-like (layer 2) approach that has been traditionally deployed uses an overlay network of bridging and tunneling to configure multiple workloads – a situation that turns into a rat’s nest at scale. It can require networking knowledge that application developers and data center operators may not have.
Project Calico took inspiration from the Internet itself – what it calls an L3 approach – making each server function as a router for the containers it hosts. The Linux kernel acts as an IP traffic-forwarding mechanism and an agent on each container monitors any changes in the network map and re-examines policies associated with it before the next connection.
The new plug-in uses Container Network Interface (CNI), the open standard for configuring container networking, and continues to support experimental annotation-based policy.
With the Calico 1.0 release last August, it announced full integration with OpenStack Neutron and proof-of-concept integrations with Docker, Kubernetes, and others. It supports IPv4 and IPv6 traffic and integrates with cloud orchestration systems to enable secure IP communication between virtual machines, containers, or bare metal workloads.
It also provides a flexible security policy using whitelists for permitted traffic and ‘bookended’ access control lists. It announced integration with CoreOS Tectonic clusters in December.
Randall said creating the Kubernetes plug-in addressed a number of issues:
“There’s been evolution within Kubernetes. it’s moved from 1.0 to 1.1 release, so it’s been about supporting the interface as that evolved. The other thing is that Kubernetes as been steadily increasing the scale targets. The first release was just targeting 100 nodes. [Version] 1.1 significantly increased that to several hundred, and really we’re seeing that going up to 1,000-plus.
“So at that point, it’s very much production scale for a very broad number of enterprises. A lot of what we’ve been doing is driving our testing to that scale. It’s one thing so show, yeah, we can fire up a few containers, and you can ping from one to another, but actually doing it at scale with real workloads, with real churn — tearing down containers, adding new containers — that’s what puts load on the orchestration system and the network. That’s been a lot of the emphasis we’ve been doing,” Randall said.
Packet, a New York-based cloud provider on bare metal, is among its customers. Large financial companies initially were its primary customers, though that since has expanded to large SaaS vendors, public cloud providers and retail customers, Randall said without naming them.
Security policy will be a major theme at Project Calico going forward, he said.
“We’re working to get security policy integrated with Kubernetes. The current release has it in an experimental mode. There’s a lot of discussion in the Kubernetes around what that interface and that framework should look like. So that’s something we’re keen to take forward.
“The security angle of what we’re doing is really going to be the big push over the next year. It’s increasingly what’s driving interest – the ability for the application developer and the network or data center operator to define security policy. For the application developer to say, ‘Here is my microservice, and it needs the following network services. It needs to talk to these containers.’ And for that to be enforced within the network fabric,” he said.
“That’s the sort of thing where Calico’s going. Not just enforcing it, but reporting on what’s happening. So when you see a potentially malicious workload – whether it’s a compromised container or someone just made a programming error – you’re seeing traffic that shouldn’t happen, you detect it, you block it, you report it, you stop doing packet capture on those workloads. You sandbox them. Those are the kinds of advanced capabilities that people want beyond just networking,” he said.
“I say it’s really simple. All we have to do is get packets from A to B, then stop packets from getting from A to B. Traditionally, that’s been treated as two completely separate problems. You put your virtual network in place, then you put firewalls in place. We think it’s better to describe the entirety of the network you want to achieve, both how I want things to be connected, but also the rules I want in place as to who can talk to whom, and implement them in one place — and that’s what we do.”
Feature Image: “Bangkok Traffic” by Mark Fischer by CC BY-SA 2.0.
