Chapter 10. Kubernetes Engine:

managed Kubernetes clusters

Kubernetes Engine:

• What containers, Docker, and Kubernetes do

• How Kubernetes Engine works and when it’s a good fit

• Setting up a managed Kubernetes cluster using Kubernetes Engine

• Upgrading cluster nodes and resizing a cluster

Packaging of all your hard work into something that’s easy to work with

in a production setting. 

Final packaging and deployment are often as difficult and complex as the

original development.

Tools are available to address this problem, one of which relies on the concept

of a container for your software.

10.1. What are containers?

Infrastructural tool aimed at solving the software deployment problem by making

it easy to package your application.

Unit of isolation, so you don’t have to worry about competing for limited computing

resources.

10.1.1. Configuration

Deploy your application and realized you had a lot more dependencies than you thought.

Containers solve this problem by making it easy to set up a clean system, describe

how you want it to look, and keep a snapshot of it once it looks exactly right. 

You can boot a container and have it look exactly as you described.

10.1.2. Standardization

If you wanted to send a table and some chairs across the ocean from England

to the United States, you had to take everything to a ship and figure out how to fit it

inside.

The shipping industry decided that this way of packing things was silly and started

exploring the idea of containerization. 

Using big metal boxes (containers) before they even get to a boat. 

The boat crew only ever deals with these standard-sized containers.

Reducing the time it took to load boats.

Shipping industry could build boats that were good at holding containers .

Devise tools that were good at loading and unloading containers.

Charge prices based on the number of containers.

Software containers do for your code what big metal boxes did for shipping.

Standard format representing your software .

Tools to run and manage that environment.

System understands containers.

Deploy your code there, it’ll work. 

Focus specifically on getting your code into a container.

10.1.3. Isolation

You might want to take a large machine and chop it into two pieces: one for a web

server and another for a database. 

If the database were to get tons of SQL queries, the web server would have far fewer

CPU cycles to handle web requests.

Two separate containers makes this problem go away. 

Software containers run in a virtual environment with similar walls that allow you to

decide exactly how to allocate the underlying resources.

Applications running on the same virtual machine may share the same libraries and

operating system.

Applications running on the same system require different versions of shared libraries,

reconciling these demands can become quite complicated. By containerizing the

application, shared libraries aren’t shared anymore, meaning your dependencies are

isolated to a single application (figure 10.3).

10.2. What is Docker?

Docker is a tool for running containers.

Docker handles the lower-level virtualization; it takes the definitions of container

images and executes the environment and code that the containers define.

Docker also has become the standard for how you define container images,

using a format called a Dockerfile. 

Define a container using a bunch of commands that do anything from running a

simple shell command. 

RUN echo "Hello World!

Complex things like exposing a single port outside the container (EXPOSE 8080).

Inheriting from another predefined container (FROM node:8).

10.3. What is Kubernetes?

Split things up based on what they’re responsible for

creating a traditional web application.

You might have a container that handles web requests (for example, a web app server

that handles browser-based requests)handles caching frequently accessed data.

Generating fancy reports, shrinking pictures down to thumbnail size, or sending emails

to your users.

All of the web app servers to have Memcached running on the same physical (or virtual)

machine so you can talk to Memcached over localhost rather than a public IP. As a result, there a bunch of systems that try to fix this problem,

one of which is Kubernetes.

Kubernetes is a system that manages your containers and allows you to break things into

chunks that make sense for your application.

Allows you to express more complex relationships.

Run it on any cloud provider.

Kubernetes builds on the concept of a container as a fundamental unit.

Zoom in on the four key concepts: clusters, nodes, pods, and services.

10.3.1. Clusters

Clusters tend to line up with a single application,

When you’re talking about the deployment for all of the pieces of an application,

you’d say that they all run as part of its Kubernetes cluster. 

10.3.2. Nodes

Nodes live inside a cluster and correspond to a single machine (for example, a VM in GCE)

capable of running your code. 

Each cluster usually will contain several nodes, which are collectively responsible for

handling the overall work needed to run your application.

10.3.3. Pods

Pods are groups of containers that act as discrete units of functionality that any given node

will run. 

The containers that make up a pod will all be kept together on one node and will

share the same IP address and port space. 

Think of this stack in terms of containers and pods, you might rearrange things a bit,

but the important idea to note is leaving VMs (and nodes) out of the picture entirely. 

One pod responsible for serving the web app (which would be running Apache and

Memcached, each in its own container), and another pod responsible for storing data

(with a container running MySQL)

The idea of using pods is that you can focus on what should be grouped together,

rather than how it should be laid out on specific hardware (whether that’s virtual or

physical).

Perspective of the To-Do List app, you had two different pods: the To-Do List web app

pod and the report-generation pod.

10.3.4. Services

A service is the abstract concept you use to keep track of where the various pods are running.

Service to keep track of the various pieces of your application (for example, in the

To-Do List, you have the pod that handles web requests), you never worry about

where the pod happens to be running.

Service is a way to help route you to the right pod and that a pod is a group of containers

with a particular purpose.

10.4. What is Kubernetes Engine?

To create clusters and pods and have requests routed to the right nodes, you have to

install, run, and manage the Kubernetes system yourself. 

Same tools that you would if you were running Kubernetes yourself, but you can take

care of the administrative operations (such as creating a cluster and the nodes inside it)

using the Kubernetes Engine API.

10.5. Interacting with Kubernetes Engine

To see how this all works, you can define a simple Kubernetes application and then see

how you can deploy it to Kubernetes Engine.

Create a Dockerfile, 

A start-up script for a VM.

10.5.2. Running your container locally

Need to install the Docker runtime. 

Docker is a tool that understands how to run containers that you define using the

Dockerfile format. 

Tell it to run your Dockerfile and you should see your little web app running.

To run your image, you have to take your Dockerfile that describes a container and

build it into a container image. This is a bit like compiling source code into a runnable

binary when you’re writing code in a compile language like C++ or Java.

Make sure the contents of your Dockerfile are in a file called Dockerfile.

Looking for the publicly available base container.

 Then it’ll set up your work directory

This is only building the container, not running it, so the container itself is in a state

that’s ready to run but isn’t running at the moment.

If you want to test out that things worked as expected, you can use the docker run command with some special flags:

Here, the -dflag tells Docker to run this container image in the background, and the -p 8080:8080 tells Docker to take anything on your machine that tries to talk to port 8080 and

forward it onto your container’s port 8080.

The following line shows the result of running your container image:

a unique ID that you can use to address that particular image (after all,

you might have lots of the same image running at the same time).

To check that your image is running, you can use the docker ps command, and you should see the hello-node image in the list:

10.5.3. Deploying to your container registry

Built and run a container locally, but if you want to deploy it, you’ll need it to

exist on Google Cloud. You need to upload your container to run it on

Kubernetes Engine. To allow you to do this, Google offers a private per-project container

registry that acts as storage for all of your various containers.

10.5.4. Setting up your Kubernetes Engine cluster

Need to set up a Kubernetes cluster if you want to deploy your containers to

Kubernetes Engine.

Cloud Console, choose Kubernetes Engine from the left-side navigation of the

Cloud Console. 

Create a new Kubernetes cluster. 

You can leave everything set to the defaults.

 You’ll use the us-central1-a zone, a single vCPU per machine, and a size of three VMs for the whole cluster

Pick a name for your cluster in this example, like first-cluster. 

click the Create button,  Google Kubernetes Engine (GKE) actually creates the VMs

and configures Kubernetes on the new cluster of machines.

Can verify that it’s working properly by listing your VMs. Remember that a GKE

cluster relies on Compute Engine VMs under the hood, so you can look at them like

any other VM running:

You have a cluster running and can see that three VMs that make up the cluster are running. 

10.5.5. Deploying your application

Communicate with and deploy things to your cluster.

Cluster is made up of machines running Kubernetes under the hood, you can use the

existing tools for talking to Kubernetes to talk to your Kubernetes Engine cluster.

Google Cloud offers a fast installation of kubectl using the gcloud command-line tool.

10.5.7. Using the Kubernetes UI

Kubernetes comes with a built-in UI, and because Kubernetes Engine is just a managed

Kubernetes cluster, you can view the Kubernetes UI for your Kubernetes Engine cluster

the same way you would any other Kubernetes deployment. To do so, you can use the

kubectl command-line tool to open up a tunnel between your local machine and the Kubernetes

master (figure 10.12). That will allow you to talk to, say, http://localhost:8001, and a local proxy will securely

route your request to the Kubernetes master (rather than a server on your local machine):

Once the proxy is running, connecting to http://localhost:8001/ui/ will show the full

Kubernetes UI, which provides lots of helpful management features for your cluster

(figure 10.13).

10.8. When should I use Kubernetes Engine?

You may be wondering specifically how Kubernetes Engine stacks up against other

computing environments, primarily Compute Engine. Let’s use the standard scorecard

for computing to see how Kubernetes Engine compares to the others (figure 10.19).

Figure 10.19. Kubernetes Engine scorecard

10.8.1. Flexibility

Similar to Compute Engine, Kubernetes Engine is quite flexible, but it’s not the same as

having a general-purpose set of VMs that run whatever you want. For example, you’re

required to specify your environment using container images (with Dockerfiles), rather

than custom start-up scripts or GCE disk images. Although this is technically a limitation

that reduces flexibility, it isn’t a bad thing to formalize how you define your application in

terms of a container. Although Kubernetes Engine is slightly more restrictive, that might be a

good thing.

Kubernetes Engine has other limitations as well, such as the requirement that your cluster nodes’

Kubernetes version be compatible with the version of your master node, or the fact that you lose

your boot disk data when you upgrade your nodes. 

Kubernetes Engine isn’t any less flexible than Compute Engine

Ability to scale both nodes and pods up and down.

Kubernetes Engine is pretty free of major restrictions when you compare it with Compute Engine.

10.8.2. Complexity

Kubernetes Engine  has a great capacity for complexity, but benefiting from that complexity involves

high initial learning costs. 

Wanted to deploy a large cluster of API servers to handle huge spikes of traffic, it’d probably be

worth the effort to understand Kubernetes and maybe rely on Kubernetes Engine to manage your

Kubernetes cluster.

10.8.3. Performance

Unlike using raw VMs like Compute Engine, Kubernetes has a few layers of abstraction between

the application code and the actual hardware executing that code. As a result, the overall

performance can’t be as good as a plain old VM, and certainly not as good as a nonvirtualized system.

Kubernetes Engine’s performance won’t be as efficient as something like Compute Engine, but efficiency

isn’t everything. Scalability is another aspect of performance that can have a real effect.

Although you might need more nodes in your cluster to get the same performance as using

nonvirtualized hardware, you can more easily change the overall performance capacity of your system with

Kubernetes Engine than you can with Compute Engine or nonvirtualized machines. As a result, if you know

your performance requirements exactly, and you’re sure they’ll stay exactly the same over time, using Kubernetes

Engine would be providing you with scalability that you don’t need. On the other hand, if you’re unsure of how

much power you need and want the ability to change your mind whenever you want, Kubernetes Engine makes

that easy, with a slight reduction in overall efficiency.

Because this efficiency difference is so slight, it should only be an issue when you have an enormous deployment

of hundreds of machines (where the slight differences add up to become meaningful differences). If your system

is relatively small, you shouldn’t even notice the efficiency differences.

10.8.5. Overall

How do you choose between Computer Engine and Kubernetes Engine, given that

they’re both flexible, perform similarly, and are priced similarly, but using Kubernetes

Engine requires you to learn and understand Kubernetes, which is pretty complex?

Although this is all true, the distinguishing factor tends to be how large your overall

system will be and how much you want your deployment configuration to be represented

as code. The benefits of using Kubernetes Engine over other computing platforms

aren’t about the cost or the infrastructure but about the benefits of Kubernetes as a way

of keeping your deployment procedure clear and well documented.

As a result, the general rule is to use Kubernetes Engine when you have a large system

that you (and your team) will need to maintain over a long period of time. On the other

hand, if you need a few VMs to do some computation and plan to turn them off after a

little while, relying on Compute Engine might be easier. To make this more concrete,

let’s walk through the three example applications that I’ve discussed and see which

makes more sense to deploy using Kubernetes Engine.

Summary

• A container is an infrastructural tool that makes it easy to package up code along with all dependencies down to the operating system.

• Docker is the most common way of defining a container, using a format called a Dockerfile.

• Kubernetes is an open source system for orchestrating containers, helping them act as a cohesive application.

• Kubernetes Engine is a hosted and fully managed deployment of Kubernetes, minimizing the overhead of running your own Kubernetes cluster.

• You can manage your Kubernetes Engine cluster like any other Kubernetes cluster, using kubectl.