This chapter contains an explanation of container orchestration, including its benefits, use cases, and popular implementations. We'll also review Kubernetes briefly, including a layout of the architectural components, and a primer on authorization, authentication, and general communication with Kubernetes. By the end of this chapter, you'll know how to authenticate and communicate with the Kubernetes API.

In this chapter, we will cover the following topics:

• A container orchestration primer
• Kubernetes' architecture
• Authentication and authorization on Kubernetes
• Using kubectl and YAML files

In order to run the commands detailed in this chapter, you will need a computer running Linux, macOS, or Windows. This chapter will teach you how to install the kubectl command-line tool that you will use in all later chapters.

The code used in this chapter can be found in the book's GitHub repository at the following link:

https://github.com/PacktPublishing/Cloud-Native-with-Kubernetes/tree/master/Chapter1

We cannot talk about Kubernetes without an introduction of its purpose. Kubernetes is a container orchestration framework, so let's review what that means in the context of this book.

What is container orchestration?

Container orchestration is a popular pattern for running modern applications both in the cloud and the data center. By using containers – preconfigured application units with bundled dependencies – as a base, developers can run many instances of an application in parallel.

Benefits of container orchestration

There are quite a few benefits that container orchestration offers, but we will highlight the main ones. First, it allows developers to easily build high-availability applications. By having multiple instances of an application running, a container orchestration system can be configured in a way that means it will automatically replace any failed instances of the application with new ones.

This...

Kubernetes is an orchestration tool that can run on cloud VMs, on VMs running in your data center, or on bare metal servers. In general, Kubernetes runs on a set of nodes, each of which can each be a VM or a physical machine.

Kubernetes node types

Kubernetes nodes can be many different things – from a VM, to a bare metal host, to a Raspberry Pi. Kubernetes nodes are split into two distinct categories: first, the master nodes, which run the Kubernetes control plane applications; second, the worker nodes, which run the applications that you deploy onto Kubernetes.

In general, for high availability, a production deployment of Kubernetes should have a minimum of three master nodes and three worker nodes, though most large deployments have many more workers than masters.

The Kubernetes control plane

The Kubernetes control plane is a suite of applications and services that run on the master nodes. There are several highly specialized services...

Namespaces are an extremely important concept in Kubernetes, and since they can affect API access as well as authorization, we'll cover them now.

Namespaces

A namespace in Kubernetes is a construct that allows you to group Kubernetes resources in your cluster. They are a method of separation with many possible uses. For instance, you could have a namespace in your cluster for each environment – dev, staging, and production.

By default, Kubernetes will create the default namespace, the kube-system namespace, and the kube-public namespace. Resources created without a specified namespace will be created in the default namespace. kube-system contains the cluster services such as etcd, the scheduler, and any resource created by Kubernetes itself and not users. kube-public is readable by all users by default and can be used for public resources.

Users

There are two types of users in Kubernetes – regular users...

kubectl is the officially supported command-line tool for accessing the Kubernetes API. It can be installed on Linux, macOS, or Windows.

Setting up kubectl and kubeconfig

To install the newest release of kubectl, you can use the installation instructions at https://kubernetes.io/docs/tasks/tools/install-kubectl/.

Once kubectl is installed, it needs to be set up to authenticate with one or more clusters. This is done using the kubeconfig file, which looks like this:

Example-kubeconfig

apiVersion: v1
kind: Config
preferences: {}
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
users:
- name: alex
  user:
    password: mypass
    username: alex
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer...

In this chapter, we learned the background behind container orchestration, an architectural overview of a Kubernetes cluster, how a cluster authenticates and authorizes API calls, and how to communicate with the API via imperative and declarative patterns using kubectl, the officially supported command-line tool for Kubernetes.

In the next chapter, we'll learn several ways to get started with a test cluster, and master harnessing the kubectl commands you've learned so far.

1. What is container orchestration?
2. What are the constituent parts of the Kubernetes control plane, and what do they do?
3. How would you start the Kubernetes API server in ABAC authorization mode?
4. Why is it important to have more than one master node for a production Kubernetes cluster?
5. What is the difference between kubectl apply and kubectl create?
6. How would you switch between contexts using kubectl?
7. What are the downsides of creating a Kubernetes resource declaratively and then editing it imperatively?

• The official Kubernetes documentation: https://kubernetes.io/docs/home/
• Kubernetes The Hard Way: https://github.com/kelseyhightower/kubernetes-the-hard-way