Pulumi Blog: Kubernetes Fundamentals Series

Kubernetes Fundamentals: Part Two

Kat Cosgrove — Thu, 02 Sep 2021 12:54:53 -0500

Kubernetes is everywhere now, but it’s primarily been the domain of people working on the ops side of infrastructure. What about devs, though? You benefit from knowing what Kubernetes is and how to use it, too—otherwise, we’re still putting teams in silos. In this blog, we’re going to build off part one by learning about managed Kubernetes services: what they are, when they’re useful, and how you can try deploying to one yourself, starting with Google’s Kubernetes Engine (GKE).

What is a managed Kubernetes service?

Essentially, a managed Kubernetes service just means that someone else is responsible for some of the work involved in standing up and maintaining Kubernetes. It varies from provider to provider, but services can be pretty bare-bones or include everything under the sun, handing you a pre-configured environment and a dedicated support team to help you.

What makes this option useful?

Kubernetes is very powerful, but also very complicated. The flexibility of the platform means that there’s a lot of configuration you have to do just to get off the ground, and a managed service takes some of that off your plate. Some configurations are abstracted away, and some decisions are made for you. Things you would otherwise have to set up yourself, like load balancing, monitoring, and updates, are covered by the vendor. It’s less effort to get started and less effort to maintain. Scaling is painless since you can just provision more resources. For most people, a managed service is flat-out more reliable.

Okay, I want to try it for myself.

First things first, we need Pulumi, Node.js, and npm installed.

We’re going to do this on Google Cloud Product (GCP), so you’ll also need the Google Cloud SDK set up. From there, log in with gcloud:

$ gcloud auth login
$ gcloud config set project <YOUR_GCP_PROJECT_HERE>
$ gcloud auth application-default login

Creating a Cluster with Google Kubernetes Engine

Next, we need a cluster. Start by creating a new directory, navigating into it, and initializing a new Pulumi project using TypeScript.

mkdir gke-hello-world && cd gke-hello-world && pulumi new typescript

We also need to install some dependencies, and set some required configuration values.

npm install --save @pulumi/pulumi @pulumi/gcp @pulumi/kubernetes
pulumi config set gcp:project <YOUR_GCP_PROJECT_HERE>
pulumi config set gcp:zone us-west1-a // any valid GCP Zone here

Now, in index.ts, add the following code:

import * as k8s from "@pulumi/kubernetes";
import * as pulumi from "@pulumi/pulumi";
import * as gcp from "@pulumi/gcp";

const name = "helloworld";

// Create a GKE cluster. We start with two nodes, each running an n1-standard-1 machine, which provides the best balance of price for performance ratio for the most common workloads. Replicas of our application will be distributed across these two nodes, ensuring that if one node goes down, our application remains up in the other node.

const engineVersion = gcp.container.getEngineVersions().then(v => v.latestMasterVersion);
const cluster = new gcp.container.Cluster(name, {
 initialNodeCount: 2,
 minMasterVersion: engineVersion,
 nodeVersion: engineVersion,
 nodeConfig: {
 machineType: "n1-standard-1",
 oauthScopes: [
 "https://www.googleapis.com/auth/compute",
 "https://www.googleapis.com/auth/devstorage.read_only",
 "https://www.googleapis.com/auth/logging.write",
 "https://www.googleapis.com/auth/monitoring"
 ],
 },
});

// Export the Cluster name
export const clusterName = cluster.name;

// Manufacture a GKE-style kubeconfig. Note that this is slightly "different"
// because of the way GKE requires gcloud to be in the picture for cluster
// authentication (rather than using the client cert/key directly).
export const kubeconfig = pulumi.
 all([ cluster.name, cluster.endpoint, cluster.masterAuth ]).
 apply(([ name, endpoint, masterAuth ]) => {
 const context = `${gcp.config.project}_${gcp.config.zone}_${name}`;
 return `apiVersion: v1
clusters:
- cluster:
 certificate-authority-data: ${masterAuth.clusterCaCertificate}
 server: https://${endpoint}
 name: ${context}
contexts:
- context:
 cluster: ${context}
 user: ${context}
 name: ${context}
current-context: ${context}
kind: Config
preferences: {}
users:
- name: ${context}
 user:
 auth-provider:
 config:
 cmd-args: config config-helper --format=json
 cmd-path: gcloud
 expiry-key: '{.credential.token_expiry}'
 token-key: '{.credential.access_token}'
 name: gcp
`;
 });

// Create a Kubernetes provider instance that uses our cluster from above.
const clusterProvider = new k8s.Provider(name, {
 kubeconfig: kubeconfig,
});

This code is the entrypoint for our program and is what’s setting up the cluster for us. We’re defining the resources we want, the kubeconfig that’ll be used to access the cluster, and also the Kubernetes provider so that we can deploy resources to it next.

Now just run pulumi up to preview the changes, select yes when prompted, and watch the cluster stand up! You’ll see some work happening in your terminal as well as in your Pulumi account, and when it’s all done, you can look at your GCP dashboard and see the cluster there, too.

But we should actually put something in the cluster, shouldn’t we?

A Deployment for the Cluster

Let’s work on that Kubernetes Provider. Using a Kubernetes Provider allows us to abstract away some of the specifics of operating a cluster on one cloud provider or another. That way, your experience from here on out is fairly consistent regardless of where you’re hosting this.

In the same index.ts file from before, add this to the end:

// Create a Kubernetes Namespace
const ns = new k8s.core.v1.Namespace(name, {}, { provider: clusterProvider });

// Export the Namespace name
export const namespaceName = ns.metadata.apply(m => m.name);

// Create a NGINX Deployment
const appLabels = { appClass: name };
const deployment = new k8s.apps.v1.Deployment(name,
 {
 metadata: {
 namespace: namespaceName,
 labels: appLabels,
 },
 spec: {
 replicas: 1,
 selector: { matchLabels: appLabels },
 template: {
 metadata: {
 labels: appLabels,
 },
 spec: {
 containers: [
 {
 name: name,
 image: "nginx:latest",
 ports: [{ name: "http", containerPort: 80 }]
 }
 ],
 }
 }
 },
 },
 {
 provider: clusterProvider,
 }
);

// Export the Deployment name
export const deploymentName = deployment.metadata.apply(m => m.name);

// Create a LoadBalancer Service for the NGINX Deployment
const service = new k8s.core.v1.Service(name,
 {
 metadata: {
 labels: appLabels,
 namespace: namespaceName,
 },
 spec: {
 type: "LoadBalancer",
 ports: [{ port: 80, targetPort: "http" }],
 selector: appLabels,
 },
 },
 {
 provider: clusterProvider,
 }
);

// Export the Service name and public LoadBalancer endpoint
export const serviceName = service.metadata.apply(m => m.name);
export const servicePublicIP = service.status.apply(s => s.loadBalancer.ingress[0].ip)

Here, we’re creating a namespace and adding an NGINX deployment with an accompanying LoadBalancer service and exporting everything we need to run it. Run pulumi up once again, double-check the preview, and select yes to update the deployment. Now everything’s up and running on a managed Kubernetes service that you didn’t have to stand up by hand, and won’t have to expend as much effort maintaining.

Talking to the Cluster

In case you’re curious, you can still interact with the cluster using kubectl when running on a managed provider, just like when you’re running everything locally. Run this command to have Pulumi export your kubeconfig with its secrets:

pulumi stack output kubeconfig --show-secrets > kubeconfig

Then just export it:

export KUBECONFIG=$PWD/kubeconfig

At that point, regular kubectl commands will work. If you followed along, make sure you run pulumi destroy to tear down this stack and all of its resources so you don’t run up a bill!

Coming Up Next

So, that was pretty quick. But I only talked about GKE. What about other cloud providers? Yeah, those work, too. And yes, it’s also fairly quick. Now that I’ve explained the basics of Kubernetes and what managed Kubernetes is, things will get more practical—tune in next time for deploying to EKS!

Kubernetes Fundamentals: Part One

Kat Cosgrove — Fri, 23 Jul 2021 12:54:53 -0500

Kubernetes is everywhere now, but it’s primarily been the domain of people working on the Ops side of infrastructure. What about devs, though? You benefit from knowing what Kubernetes is and how to use it, too – otherwise, we’re still putting teams in silos. In this tutorial, we’re going to define Kubernetes at a high level, talk about the anatomy of a cluster, and learn not just why you should care but how to try it for yourself. We’ll start with local deployments using YAML before getting a little help from infrastructure as code with Pulumi to stand up everything right inside our sample application in a programming language you’re already writing!

What is Kubernetes?

Kubernetes is a container orchestration tool. If we think of it in the context of an actual container ship, then Kubernetes is the person who determines how many shipping containers of particular goods go on the ship and where they should be in relation to each other. It makes deploying containerized workloads a bit less painful to maintain.

Anatomy of a Cluster

Let’s talk about what Kubernetes looks like. Inside a cluster, there is a master node responsible for the overall maintenance of the cluster and several worker nodes where our containers and other workloads live. There are other pieces here, but generally, that’s the high level. You end up with something that looks like a big box containing many smaller boxes, which, in turn, contain more boxes.

So, the master node takes care of the worker nodes, and the worker nodes house our containers, which may be running application code, or a database, or volume storage, or some other service. Instead of managing each of these individual components yourself, you tell Kubernetes how to manage them and let it deal with that for you.

Deployment

There are a few ways to do this. We can use kubectl in the terminal by pointing it at config files written in a format called YAML, or we can use an infrastructure as code tool like Pulumi to help. For now, we’ll use YAML and let kubectl handle it for us.

Kubernetes is useful because it scales your application without quite as much work. Below is an example of the deployment YAML for a small containerized demo application with two replicas. If you want to follow along with an application of your own, you will need Minikube and kubectl installed.

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
 name: demo-deployment
 labels:
 app: hello-kubernetes
spec:
 replicas: 2
 selector:
 matchLabels:
 app: hello-kubernetes
 template:
 metadata:
 labels:
 app: hello-kubernetes
 spec:
 containers:
 - name: flask
 image: dockerhub.io/katcosgrove/fake-container:latest
 ports:
 - containerPort: 5000

This deployment YAML describes what I want to happen:

the name of the pod and application,
the number of replicas I want,
the image to run,
and the port I need.

The Flask application uses port 5000, so the deployment spec does, too. The image isn’t real, but if it were, it would be in a repository called fake-container on my Dockerhub account.

If you were to deploy this with kubectl apply -f deployment.yaml and then run kubectl get pods, you would see the Deployment created two pods for our application.

What if you decide you need more replicas, though? Go back to your deployment configuration, bump the number of replicas to 5, and apply it again with kubectl apply -f deployment.yaml. Run kubectl get pods, and you’ll see three more pods coming online!

Exposing the Application

We probably want to SEE our app, though. The quick and dirty way to do that is port forwarding within the cluster, like this:

kubectl port-forward deployment/demo-deployment 5000:5000

Here, we’re using kubectl to forward the demo-deployment’s port 5000 to our local port 5000. If you go to localhost:5000 in a browser, you’ll see your application.

That’s not very convenient, though, and it doesn’t offer much in the way of customization or control. We need to add an ingress controller. NGINX-ingress is popular, and minikube already has an addon, but there are many other options.

Install it by running minikube addons enable ingress.

To confirm that the pods are up, run kubectl get pods -n kube-system and look for pods that start with “ingress-nginx”. Note that other Kubernetes environments will put these in the “ingress-nginx” namespace instead. Now let’s add a ClusterIP service. That’s what exposes your deployment within the cluster.

service.yaml

apiVersion: v1
kind: Service
metadata:
 name: demo-service
spec:
 ports:
 - port: 8080
 protocol: TCP
 targetPort: 5000
 selector:
 app: demo-deployment
 type: ClusterIP

Like always, we have metadata like a name, we tell it which ports to target (remember our Flask app is targeting port 5000), and we give the name of the deployment.

The last thing we need to do is define the ingress resource. It’s the final piece that allows our application to be this is what exposes your application to the outside world.

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: demo-ingress
spec:
 rules:
 - http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: demo-service
 port:
 Number: 8080

Like with all of our other config files, we’re giving it metadata and telling it what to target. In this case, it’s the service we defined and the service’s port.

As before, apply it with kubectl apply -f ingress.yaml

Now, if you run kubectl get ingress, you’ll get an IP address. Go there in a browser, and there’s your app, deployed on Kubernetes!

Python instead of YAML

Okay, but this all feels very Ops-centric still – we’re writing YAML, not a programming language, and I promised you a familiar programming language. Let’s use Pulumi to do it with Python instead.

Before, we had a ton of YAML, now infrastructure as code tools lets us cut a window from the Ops silo to the Dev silo, so we can share stuff, talk a bit more, and work together. You can stand up the infrastructure to deploy your application on Kubernetes right there in the application code! Fortunately, Pulumi has a bunch of different examples of how to do this.

First, you need Pulumi installed. Then, you need to configure Kubernetes for Pulumi. From here, we can deploy to Kubernetes without touching a shred of YAML directly.

Below is an example of the code required to deploy NGINX to Kubernetes, with two replicas, but this time, in more familiar Python instead of YAML.

import pulumi
from pulumi_kubernetes.apps.v1 import Deployment, DeploymentSpecArgs
from pulumi_kubernetes.core.v1 import ContainerArgs, ContainerPortArgs, PodSpecArgs, PodTemplateSpecArgs
from pulumi_kubernetes.meta.v1 import LabelSelectorArgs, ObjectMetaArgs

config = pulumi.Config()
nginxLabels = {"app": "nginx"}
nginxDeployment = Deployment(
 "nginx-deployment",
 spec=DeploymentSpecArgs(
 selector=LabelSelectorArgs(match_labels=nginxLabels),
 replicas=2 if config.get_int("replicas") is None else config.get_int("replicas"),
 template=PodTemplateSpecArgs(
 metadata=ObjectMetaArgs(labels=nginxLabels),
 spec=PodSpecArgs(
 containers=[ContainerArgs(
 name="nginx",
 image="nginx:1.7.9",
 ports=[ContainerPortArgs(container_port=80)],
 )],
 ),
 ),
 ))

pulumi.export("nginx", nginxDeployment.metadata.apply(lambda m: m.name))

In just 25 lines and one file, we’ve set up a deployment with two replicas of a containerized application and exposed it. It’s happening in a language you’re familiar with, and it can live right alongside your application code, rather than keeping everything in silos. If you want to increase the number of replicas, it requires no more effort than it did when using YAML.

Keeping the Dev team and the Ops team isolated from one another leads to misunderstandings, confusion, and a slower release cycle. At the very least, both parties need to understand each other, which means Devs need to learn a bit more about Kubernetes. Pulumi can help you speak Kubernetes in your favorite language.

This example is all local, though, and you might not be running Kubernetes on-prem. What if you want to abstract things away even further? Tune in next time for Kubernetes on cloud providers!