Install Calico for Kubernetes in this video walkthrough
In addition to Kubernetes' built-in NetworkPolicy API, there are several plugins to enhance the platform's existing networking capabilities or add new ones. Calico, an open source Container Network Interface plugin, lets admins define network policies in a YAML policy document and apply them across an entire Kubernetes cluster.
Calico is very flexible to install and manage: It can run on a control machine, inside a node within a cluster or even as a separate pod inside a cluster. Although the Kubernetes NetworkPolicy API already has some of these capabilities, Calico adds features such as integration with Istio and Envoy, as well as the ability to set policies for pods, nodes and other host interfaces.
Follow along: Install Calico on Kubernetes
This video demo shows how to install Calico on a cluster running in Google Kubernetes Engine (GKE), define a network policy and then apply that policy to pods running in a cluster.
To follow along with the demo, all you need is a Google Cloud account. The rest of the resources and tools you need can be created or accessed from there.
You can also use other Kubernetes clusters as long as they have the NetworkPolicy API installed. In GKE, you can install that API on an existing cluster or add it as part of a new one with an additional parameter, but these instructions might differ for other cloud providers.
1. Set up a new cluster and configure calicoctl
First, create a new cluster with the NetworkPolicy plugin installed. Once the cluster is ready, set up the Calico command-line tool, calicoctl, on the control machine -- typically where you run kubectl when doing Kubernetes administration tasks such as creating new deployments.
After installing calicoctl, connect it to your Kubernetes data store. The demo video uses Cloud Shell, where this is already configured. If you're using any other configuration, make sure to follow the Calico installation documentation.
Verify your calicoctl installation by running the command calicoctl get nodes and comparing the output with the nodes in your cluster.
2. Set up pods and apply policy documents
Once that's done, you'll need a few pods so that you can write network traffic rules.
In the demo, a namespace with a simple Nginx pod with the default welcome page is set up on port 80, simulating an application. A second pod is set up using the BusyBox image, which has built-in tools such as wget for testing network rules. The BusyBox pod is run with the access label, which is also used in the network policy document as the label selector for allowing ingress traffic.
By default, no rules are set, and both ingress and egress traffic will resolve without any issues. Using a Calico network policy, run the calico create command to apply the policy document to your cluster.
The -f parameter specifies which YAML policy document to apply. It can accept the file path of the document or read it from standard input, as shown in the demo.
3. Destroy your test cluster
If you're following along with the demo, don't forget to destroy your cluster afterward, because clusters can be fairly expensive to run for long periods of time. The calicoctl binary remains on Cloud Shell until it's removed.
Explore Calico's capabilities
This demo shows a simple policy to restrict ingress and egress traffic, but Calico is capable of much more and can be customized for a wide range of use cases and requirements. For more rules, customization options and sample policies, refer to the Calico documentation.
For example, in your own clusters, you could explore use cases such as the following:
- Log traffic to specific pods or nodes.
- Configure DoS prevention with global network policies.
- Enforce zero-trust networking by tightly controlling which ports and routes are open to which pods.
Chris Blackden 00:03
Hello, and welcome to this demo on getting started with the Calico Kubernetes networking tool. So to start out, I'm in Google Cloud. And I'm going to go ahead and create a new Kubernetes cluster for this demo. Let's go ahead.
Chris Blackden 00:18
Let's go ahead and go to the Kubernetes Engine page. And you see I don't have anything right now. So I'm going to go ahead and open my Cloud Shell. And Cloud Shell is primarily where I'll be working for this demo. Let's go ahead and create our Kubernetes cluster. I've got the command saved off here. We're going to create a new cluster called calico-demo-cluster. And we're going to enable the network policy add-on, we'll also make this in us-central1-a, and we'll limit it to just two nodes. I'll go ahead and pause the video here and let this create, and I'll resume once it's done.
Chris Blackden 00:57
All right, we're back here in GKE, and our Kubernetes cluster is up and running. Now, the next thing I have to do is download the calicoctl binary from GitHub. I'm just going to grab the latest release there. Next, I'm going to go ahead and make it executable. And then I will create a symlink to that in my /usr/local/bin directory. So I have access to it on the system path.
Chris Blackden 01:24
So now that that's set up, you can see I've got my calicoctl version here. It's worth noting you don't have to do this on Cloud Shell. You can do this on any control machine that you're managing your Kubernetes cluster from or even install it as a separate pod inside your Kubernetes cluster. It's a pretty versatile installation process. But now that it's on the system path, I can use it to list the nodes in my Kubernetes cluster.
Chris Blackden 01:52
Except there's one catch here. At the time of recording, there is a bug in calicoctl, where you'll get this version mismatch error. I checked on the GitHub issues page, and it's actually only a couple of days old, so it's not going to be resolved for this recording. But depending on when you're watching this video, you may or may not encounter this. That being said, I'm going to add this --allow-version-mismatch flag, because it's not going to affect the demo if we use that.
Chris Blackden 02:22
But now Calico is allowing me to list the nodes in my cluster. And I'll go ahead and verify that by going into the cluster here in my GKE console, go into nodes and then scrolling down. And you can see, those do match the nodes. So we know it's installed. It's connected to my Kubernetes data store. And we're ready to do some work with Calico. So we actually don't need the console for the rest of this demo. I'm going to go ahead and just open it up in a new window here.
Chris Blackden 02:52
So the next thing we're going to do is we're going to create a new Kubernetes deployment that we can use to test the networking policy that we'll create with Calico. So first, I'm going to create a new namespace called calico-policy-ns, or Calico policy namespace. Next, I'll create a deployment to that namespace. And I'll just deploy a simple Nginx server. And then I'll go ahead and expose that Nginx server on port 80.
Chris Blackden 03:19
Now that that's done, I want to create a new pod with BusyBox so that I can run some tools alongside Nginx that I'll use to manage it, or to show the demo here. So there's my prompt. I'm in a BusyBox pod that is alongside my Nginx pod. And I'm going to go ahead and just run a wget on Nginx here. And you see, I am getting the Nginx welcome page back. So I know my ingress rules to the pod are working.
Chris Blackden 03:52
Let's see if I can go out to the public internet and do the same with google.com. So, yep, there we go. That's going to recall this last command, just so you can see it. But I just ran the same command again against Google. And, of course, it returns a lot more than a simple Nginx server. So let's clear the screen. Now that we know that's working, I'm going to open up a new tab here, clear the screen one more time.
Chris Blackden 04:20
So let's take a look at what I've got here. I've got the calicoctl binary, which we installed earlier. And I've got this policy.yaml file, and that is a Calico networking policy document. So what this policy is doing is, it's selecting this access pod, which is the BusyBox pod that we're running all these commands in, and it's going to allow egress from that pod. And you'll remember, this is the command that I went and created the BusyBox pod with, and it's got the access tag right there.
Chris Blackden 04:54
I'm going to take that policy document and pipe it into the calicoctl create command. And I've got the -f parameter. But instead of specifying the file name, I'm going and reading it from standard input. I could just as easily substitute that dash for the name of the file or the path to the policy document. And then I've got the --allow-version-mismatch flag. So let's run that.
Chris Blackden 05:23
Now that that's applied, let's go back to our BusyBox pod and try and run those same commands again. So now my network policy has been applied, and I'm back here in my BusyBox machine. Let's go ahead and try and reach outbound to google.com. See, that still works fine. But now I'm going to try and do the same to the Nginx pod. And that is going to time out, because we do not have a policy that allows that traffic anymore.
Chris Blackden 05:55
So in this video, you learned how to set up a Kubernetes cluster with the network policy add-on, install and configure the calicoctl plugin, and then apply a network policy to restrict traffic. Thank you for watching.